[syslinux] PXELinux and serial number

[Michael_E_Brown at Dell.com]

I built an (unreleased, non-oss) identical thing to what you describe
below for internal use here a while back. 

It isn't that hard. I would say that you don't even need PXElinux
support to get the serial number. What my system did is boot the system
into a stripped-down Linux that grabbed the system serial number and
applicable hardware config, then registered itself with a master server.
At this point, the master server knows the MAC address and can set up
PXElinux config files based on MAC address.
--
Michael

> -----Original Message-----
> From: syslinux-bounces at zytor.com 
> [mailto:syslinux-bounces at zytor.com] On Behalf Of Scott Mewett
> Sent: Friday, March 18, 2005 10:18 PM
> To: H. Peter Anvin
> Cc: syslinux at zytor.com
> Subject: Re: [syslinux] PXELinux and serial number
> 
> 
> Very cool.
> 
> Were in the design stage of our project right now. I should 
> know in the next few weeks if it gets approved to build out a 
> working concept. If that happens then I'll try and get some 
> hardware or $$ donation for your effort.
> 
> The general idea of the project is to build a managed pxe 
> system. External applications would register with a database 
> backed system to setup boot choices for a particular serial 
> number. The backend system would control the creation of the 
> tftp config files for pxelinux. For example a sysadmin would 
> go through a web page and create a profile for a server to be 
> kickstarted. The backend would create an appropriate pxelinux 
> config file for that serial number or mac address. The the 
> server would pxe boot using the config for that server.
> 
> For that scenario you don't need a back end db, but we want 
> to expand it way beyond that, so that you can boot systems 
> for example without a config, go to a web page to show 
> unprovisioned servers and then create your config from there. 
> Once you finish your config on the web page the system would 
> take care of rebooting the box automatically so that the 
> install could start. We are also thinking of having systems 
> always pxe boot, even though the system may tell it to boot 
> of the hard disk. There may also be systems that will boot 
> and run over the network without using an OS on a hard disk. 
> We want all that controlled by the db backend. All of the 
> config files in the tftpboot dir could be recreated at will 
> using the data in the db.
> 
> There are commercial systems that do some of this. But none 
> that really do everything we want or are too closed a system 
> to expand and do additional things.
> 
> Is anyone aware of any open source systems that already do 
> some of this? Sorry if this is a little of topic. But since I 
> want to base it on pxelinux, I figured this would be a good 
> audience to bring it up with.
> 
> It is my intention, if I get support from my employer, to 
> open source this system as well. I've been successful with 
> that on a couple other project I've done.
> 
> Needless to say, pxelinux rocks. :-)
> 
> Thanks
> Scott
> 
> 
> On Fri, 2005-03-18 at 18:03 -0800, H. Peter Anvin wrote:
> > Scott Mewett wrote:
> > > 
> > > Since there is only the serial number that we are looking 
> for, being 
> > > able to read all the table structures would not be necessary.
> > > 
> > > What do you think?
> > > 
> > 
> > Doesn't look too bad.  Find the _DMI_ header in the BIOS ROM area, 
> > then
> > it's just a linked list of tables, and the serial number is 
> in table 1. 
> >   Get the index, and scan past the requisite number of 
> nulls, to find 
> > the appropriate string; if there is no _DMI_ header, if 
> table 1 doesn't 
> > exist or is less than 8 bytes long, the string number is zero, or 
> > finding double-null during the scan is an error, meaning no data is 
> > available.
> > 
> > This should be doable.
> > 
> > 	-hpa
> 
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX at zytor.com
> Unsubscribe or set options at: 
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>