Jumstart/​JET for FreeBSD (brain­storm­ing)

There are some HOW­TOs out there in the net which de­scribe some auto­mat­ic net­work based in­stall via PXE-​booting a ma­chine from a serv­er which has a spe­cif­ic FreeBSD re­lease in the PXE-​booting area and a non-​interactive con­fig for sys­in­stall to in­stall this FreeBSD ver­sion on the ma­chine which PXE-​boots this.

The setup of this is com­pletely manu­al and only al­lows to net­boot one FreeBSD ver­sion. The server-​side setup for the cli­ents is also com­pletely manu­al (and only al­lows to in­stall one cli­ent at a time, it seems). This is not very user-​friendly, and far away from the power of Jumpstart/​JET for Sol­ar­is where you cre­ate a tem­plate (maybe from an­oth­er tem­plate with auto­mat­ic value (IP, name, MAC) re­place­ment) and can spe­cify dif­fer­ent OS re­leases for dif­fer­ent cli­ents and then just run a com­mand to gen­er­ate a good con­fig for this.

I thought a little bit how it could be done and de­cided to write down all the stuff (so far 160 lines, 830 words) to not for­get some de­tails. All in all I think this could be done (at least a sens­ible sub­set) in a week or two (full­time) if you have the hard­ware, mo­tiv­a­tion, and time. As al­ways, the prob­lems are with­in the de­tails, so I may be off with my es­tim­a­tion a little bit (also de­pends upon the knowledge-​level (shell, tftp, dh­cpd, in­stall–soft­ware) of the per­son do­ing this).

Un­for­tu­nately I do not know if I have the hard­ware at home to do some­thing like this. I have some un­used hard­disks which could be used in a ma­chine which is used tem­por­ary as a test-​install-​client (nor­mally I use this ma­chines as my Desktop… if I do not use my little Net­book in­stead, as I do not do much at home cur­rently), but I’ve nev­er checked if this ma­chine is PXE-​booting-​capable (VIA KT133 chip­set with a 3Com 3c905C-​TX Fast Eth­er­link XL). I also do not have the time to do this (with the cur­rent rate of free time I would ex­pect to need about a year), ex­cept maybe someone would call my boss and ne­go­ti­ate some­thing.

I can not re­mem­ber any re­quest 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 be­cause nearly nobody is in­ter­ested in some­thing like this, or are the cur­rent pos­sib­il­it­ies enough for your needs? Do you work at a place where this would be wel­come (= dir­ectly used when it would be done)? If you use a simple solu­tion to make a net-​install, what is your ex­per­i­ence with this (pros/​cons)?

FreeN­AS & Sensors for FreeBSD

This WE I was told that FreeN­AS seems to want to move from FreeBSD to Linux (since then it seems there could be a linux and a FreeBSD ver­sion). One of the reas­ons seems to be a miss­ing sensors frame­work.

As I was com­mit­ting a port of the OpenBSD sensors frame­work (pro­duced as part of the Google Sum­mer of Code 2007) to FreeBSD and had to re­move it af­ter­wards be­cause one com­mit­ter com­plained very loudly, I was asked what the status of this is.

The short status is: Nobody is do­ing some­thing about it.

Be­fore I ex­plain the long status, I give  a short over­view what this sensors frame­work is:

  • a ker­nel API which al­lows to add sensors
  • an in­ter­face for the user­land to query the sensor data
  • some ba­sic user­land code to show and log the sensor info

The API and the query in­ter­face are more or less in­de­pend­ent. For the user­land code it was more a log­ging in­fra­struc­ture than a real mon­it­or­ing solu­tion. The reas­on was the real mon­it­or­ing solu­tions already ex­ist (Nagios, sn­m­pd, …) and can be ad­ap­ted to query the sensors. Ideally a query in user­land should be handled by a lib­rary in­stead of dir­ectly ac­cess­ing the sy­sctl in­ter­face, this way the ker­nel<->user­land in­ter­face would be ab­strac­ted away (and could b re­placed as needs arise). This was not done, it was some­thing to be done later (Rome was not build in a day).

The user­land in­ter­face also only cared about dumb sensors (those which you need to query manu­ally to get the in­form­a­tion), smart sensors (those which are able to send events them­self) where not taken care about in the sense of really send­ing sensor-​triggered events, but the ker­nel API al­lowed to add such sensors. The sy­sctl in­ter­face has no way of send­ing events, but FreeBSD already has an event in­ter­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 lib­rary take care about the de­liv­ery to­geth­er with oth­er sensor-​data in user­land.

And now the long status is:

PHK com­plained loudly about it. First he said he did not look at it but he com­plained that is not good re­gard­less. After a lot of nag­ging from me he had a look at it and was not happy about the time stuff in it (short: the FreeBSD time­counter code is bet­ter). This was not a prob­lem in my opin­ion, we could have dis­abled this part without prob­lems. After such an of­fer from me, he com­plained that the sensors frame­work uses the sy­sctl in­ter­face in­stead of an entry in /​dev.

At this point in time already sev­er­al user­land util­it­ies used the sy­sctl frame­work to query for status data in the ker­nel. So there was already pre­ced­ence for such an use of it. Later some more such uses where ad­ded too (e.g. the proc­stat stuff by core team mem­ber Robert Wat­son).

I saved some of the cor­res­pond­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 sy­sctl in­ter­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 people are). I am not in­ter­ested in in­vest­ing more of my spare time in­to fight­ing wind­mills (it looks like this to me).

So, if someone is in­tersted in the code, r172631 has it. In the per­force re­pos­it­ory you can maybe find some sensors. I think most of it can still be used without much changes.

If someone tries it with a more re­cent FreeBSD, please drop me a note if it just ap­plies fine, or a patch (or an URL to it) if it needs some modi­fic­a­tions. Who knows, maybe in a fu­ture pro­ject it may be use­ful for me.

If there is enough in­terest by sev­er­al people, I can even put up a wiki page where those people can co­ordin­ate, but that is most prob­ably all I am will­ing to in­vest fur­ther in­to this (at least in my un­paid time).