There are some HOWTOs out there in the net which describe some automatic network based install via PXE-booting a machine from a server which has a specific FreeBSD release in the PXE-booting area and a non-interactive config for sysinstall to install this FreeBSD version on the machine which PXE-boots this.
The setup of this is completely manual and only allows to netboot one FreeBSD version. The server-side setup for the clients is also completely manual (and only allows to install one client at a time, it seems). This is not very user-friendly, and far away from the power of Jumpstart/JET for Solaris where you create a template (maybe from another template with automatic value (IP, name, MAC) replacement) and can specify different OS releases for different clients and then just run a command to generate a good config for this.
I thought a little bit how it could be done and decided to write down all the stuff (so far 160 lines, 830 words) to not forget some details. All in all I think this could be done (at least a sensible subset) in a week or two (fulltime) if you have the hardware, motivation, and time. As always, the problems are within the details, so I may be off with my estimation a little bit (also depends upon the knowledge-level (shell, tftp, dhcpd, install–software) of the person doing this).
Unfortunately I do not know if I have the hardware at home to do something like this. I have some unused harddisks which could be used in a machine which is used temporary as a test-install-client (normally I use this machines as my Desktop… if I do not use my little Netbook instead, as I do not do much at home currently), but I’ve never checked if this machine is PXE-booting-capable (VIA KT133 chipset with a 3Com 3c905C-TX Fast Etherlink XL). I also do not have the time to do this (with the current rate of free time I would expect to need about a year), except maybe someone would call my boss and negotiate something.
I can not remember any request to have something 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 nearly nobody is interested in something like this, or are the current possibilities enough for your needs? Do you work at a place where this would be welcome (= directly used when it would be done)? If you use a simple solution to make a net-install, what is your experience with this (pros/cons)?
GD Star Rating
GD Star Rating
Tags: 3c905c tx
, 3com 3c905c
, freebsd release
, freebsd version
, knowledge level
, os releases
This WE I was told that FreeNAS seems to want to move from FreeBSD to Linux (since then it seems there could be a linux and a FreeBSD version). One of the reasons seems to be a missing sensors framework.
As I was committing a port of the OpenBSD sensors framework (produced as part of the Google Summer of Code 2007) to FreeBSD and had to remove it afterwards because one committer complained very loudly, I was asked what the status of this is.
The short status is: Nobody is doing something about it.
Before I explain the long status, I give a short overview what this sensors framework is:
- a kernel API which allows to add sensors
- an interface for the userland to query the sensor data
- some basic userland code to show and log the sensor info
The API and the query interface are more or less independent. For the userland code it was more a logging infrastructure than a real monitoring solution. The reason was the real monitoring solutions already exist (Nagios, snmpd, …) and can be adapted to query the sensors. Ideally a query in userland should be handled by a library instead of directly accessing the sysctl interface, this way the kernel<->userland interface would be abstracted away (and could b replaced as needs arise). This was not done, it was something to be done later (Rome was not build in a day).
The userland interface also only cared about dumb sensors (those which you need to query manually to get the information), smart sensors (those which are able to send events themself) where not taken care about in the sense of really sending sensor-triggered events, but the kernel API allowed to add such sensors. The sysctl interface has no way of sending events, but FreeBSD already has an event interface (devd is taking care about it). It would have been not a problem to send events via this channel and let an userland library take care about the delivery together with other sensor-data in userland.
And now the long status is:
PHK complained loudly about it. First he said he did not look at it but he complained that is not good regardless. After a lot of nagging from me he had a look at it and was not happy about the time stuff in it (short: the FreeBSD timecounter code is better). This was not a problem in my opinion, we could have disabled this part without problems. After such an offer from me, he complained that the sensors framework uses the sysctl interface instead of an entry in /dev.
At this point in time already several userland utilities used the sysctl framework to query for status data in the kernel. So there was already precedence for such an use of it. Later some more such uses where added too (e.g. the procstat stuff by core team member Robert Watson).
I saved some of the corresponding mails (to public mailing lists) in a mbox file, read the mess yourself if you want.
The bottom line is: Several committers (even some which we could call high profile committers) told me that they do not see a problem in the use of the sysctl interface. They do not seem to want to tell it in public (nobody of them voiced their opinion in the thread, so do not ask me who those people are). I am not interested in investing more of my spare time into fighting windmills (it looks like this to me).
So, if someone is intersted in the code, r172631 has it. In the perforce repository 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 recent FreeBSD, please drop me a note if it just applies fine, or a patch (or an URL to it) if it needs some modifications. Who knows, maybe in a future project it may be useful for me.
If there is enough interest by several people, I can even put up a wiki page where those people can coordinate, but that is most probably all I am willing to invest further into this (at least in my unpaid time).
GD Star Rating
GD Star Rating
, freebsd version
, kernel api
, query interface
, sensor data
, short overview
, smart sensors
, sysctl interface