Jumstart/JET for FreeB­SD (brain­storm­ing)

There are some HOW­TOs out there in the net which describe some auto­mat­ic net­work based install via PXE-booting a machine from a serv­er which has a spe­cif­ic FreeB­SD release in the PXE-booting area and a non-interactive con­fig for sysin­stall to install this FreeB­SD ver­sion on the machine which PXE-boots this.

The set­up of this is com­plete­ly man­u­al and only allows to net­boot one FreeB­SD ver­sion. The server-side set­up for the clients is also com­plete­ly man­u­al (and only allows to install one client at a time, it seems). This is not very user-friendly, and far away from the pow­er of Jumpstart/JET for Solaris where you cre­ate a tem­plate (maybe from anoth­er tem­plate with auto­mat­ic val­ue (IP, name, MAC) replace­ment) and can spec­i­fy dif­fer­ent OS releas­es for dif­fer­ent clients and then just run a com­mand to gen­er­ate a good con­fig for this.

I thought a lit­tle bit how it could be done and decid­ed to write down all the stuff (so far 160 lines, 830 words) to not for­get some details. All in all I think this could be done (at least a sen­si­ble sub­set) in a week or two (full­time) if you have the hard­ware, moti­va­tion, and time. As always, the prob­lems are with­in the details, so I may be off with my esti­ma­tion a lit­tle bit (also depends upon the knowledge-level (shell, tftp, dhcpd, install-software) of the per­son doing this).

Unfor­tu­nate­ly I do not know if I have the hard­ware at home to do some­thing like this. I have some unused hard­disks which could be used in a machine which is used tem­po­rary as a test-install-client (nor­mal­ly I use this machines as my Desk­top… if I do not use my lit­tle Net­book instead, as I do not do much at home cur­rent­ly), but I’ve nev­er checked if this machine is PXE-booting-capable (VIA KT133 chipset with a 3Com 3c905C-TX Fast Ether­link XL). I also do not have the time to do this (with the cur­rent rate of free time I would expect to need about a year), except maybe some­one would call my boss and nego­ti­ate something.

I can not remem­ber any request to have some­thing like this on the freebsd-current, freebsd-arch or freebsd-hackers list since I read them (and that is since about at least 3.0‑RELEASE). Is this because near­ly nobody is inter­est­ed in some­thing like this, or are the cur­rent pos­si­bil­i­ties enough for your needs? Do you work at a place where this would be wel­come (= direct­ly used when it would be done)? If you use a sim­ple solu­tion to make a net-install, what is your expe­ri­ence with this (pros/cons)?

FreeNAS & Sen­sors for FreeBSD

This WE I was told that FreeNAS seems to want to move from FreeB­SD to Lin­ux (since then it seems there could be a lin­ux and a FreeB­SD ver­sion). One of the rea­sons seems to be a miss­ing sen­sors framework.

As I was com­mit­ting a port of the OpenB­SD sen­sors frame­work (pro­duced as part of the Google Sum­mer of Code 2007) to FreeB­SD and had to remove it after­wards because one com­mit­ter com­plained very loud­ly, I was asked what the sta­tus of this is.

The short sta­tus is: Nobody is doing some­thing about it.

Before I explain the long sta­tus, I give  a short overview what this sen­sors frame­work is:

  • a ker­nel API which allows to add sensors
  • an inter­face for the user­land to query the sen­sor data
  • some basic user­land code to show and log the sen­sor info

The API and the query inter­face are more or less inde­pen­dent. For the user­land code it was more a log­ging infra­struc­ture than a real mon­i­tor­ing solu­tion. The rea­son was the real mon­i­tor­ing solu­tions already exist (Nagios, snm­pd, …) and can be adapt­ed to query the sen­sors. Ide­al­ly a query in user­land should be han­dled by a library instead of direct­ly access­ing the sysctl inter­face, this way the kernel<->userland inter­face would be abstract­ed away (and could b replaced as needs arise). This was not done, it was some­thing to be done lat­er (Rome was not build in a day).

The user­land inter­face also only cared about dumb sen­sors (those which you need to query man­u­al­ly to get the infor­ma­tion), smart sen­sors (those which are able to send events them­self) where not tak­en care about in the sense of real­ly send­ing sensor-triggered events, but the ker­nel API allowed to add such sen­sors. The sysctl inter­face has no way of send­ing events, but FreeB­SD already has an event inter­face (devd is tak­ing care about it). It would have been not a prob­lem to send events via this chan­nel and let an user­land library take care about the deliv­ery togeth­er with oth­er sensor-data in userland.

And now the long sta­tus is:

PHK com­plained loud­ly about it. First he said he did not look at it but he com­plained that is not good regard­less. After a lot of nag­ging from me he had a look at it and was not hap­py about the time stuff in it (short: the FreeB­SD time­counter code is bet­ter). This was not a prob­lem in my opin­ion, we could have dis­abled this part with­out prob­lems. After such an offer from me, he com­plained that the sen­sors frame­work uses the sysctl inter­face instead of an entry in /dev.

At this point in time already sev­er­al user­land util­i­ties used the sysctl frame­work to query for sta­tus data in the ker­nel. So there was already prece­dence for such an use of it. Lat­er some more such uses where added too (e.g. the proc­stat stuff by core team mem­ber Robert Watson).

I saved some of the cor­re­spond­ing mails (to pub­lic mail­ing lists) in a mbox file, read the mess your­self if you want.

The bot­tom line is: Sev­er­al com­mit­ters (even some which we could call high pro­file com­mit­ters) told me that they do not see a prob­lem in the use of the sysctl inter­face. They do not seem to want to tell it in pub­lic (nobody of them voiced their opin­ion in the thread, so do not ask me who those peo­ple are). I am not inter­est­ed in invest­ing more of my spare time into fight­ing wind­mills (it looks like this to me).

So, if some­one is inter­st­ed in the code, r172631 has it. In the per­force repos­i­to­ry you can maybe find some sen­sors. I think most of it can still be used with­out much changes.

If some­one tries it with a more recent FreeB­SD, please drop me a note if it just applies fine, or a patch (or an URL to it) if it needs some mod­i­fi­ca­tions. Who knows, maybe in a future project it may be use­ful for me.

If there is enough inter­est by sev­er­al peo­ple, I can even put up a wiki page where those peo­ple can coor­di­nate, but that is most prob­a­bly all I am will­ing to invest fur­ther into this (at least in my unpaid time).