[hobbit] Feature request: OS support for GNU/kFreeBSD

Axel Beckert beckert at phys.ethz.ch
Mon Jan 28 15:43:19 CET 2008


Hi,

first thanks for your prompt reply and patch.

On Mon, Jan 28, 2008 at 12:29:02PM +0100, Henrik Stoerner wrote:
> > 2008-01-25 22:41:09 No client backend for OS 'gnu/kfreebsd' sent by [...]
> 
> As I would expect it to do.

Yeah, when I saw the switch statement on constants in the source code,
I knew this error message was on purpose and that I have to write a
mail instead of solely patching a little bit. :-)

> >   14/0/0 root at c-metisse:pts/ttyp3 22:49:51 [~] # uname -o
> >   GNU/kFreeBSD
> 
> Hobbit actually uses "uname -s". On my Linux system this gives "Linux",
> whereas "uname -o" returns "GNU/Linux".

Ack, while on GNU/kFreeBSD both report the same value, which is why I
haven't cross-checked them on Linux.

> > The solution suggested by the GNU/kFreeBSD developers for this problem
> > is to replace all slashes in the output of "uname -o" with
> > underscores
> 
> This is easily fixed by changing the "tr" command in client/runclient.sh,
> client/hobbitclient.sh and the various build/*.sh scripts to do this
> conversion.

Ack.

> > Hernik: How do you think that problem is solved best from your view as
> > hobbit developer?
> 
> The uname output isn't used that much in Hobbit. In most of the code 
> it is immediately transformed into an enumerated value - OS_LINUX,
> OS_FREEBSD etc. - and that is what Hobbit uses throughout all of the
> server-side code.

Ok, so there's no / to _ conversion necessary in the server code.

> I'll send You a patch does this,

Will have a look at during the next days, thanks!

> and also creates a basic client inter- preter which assumes that the
> data looks like the Linux data.

It should. I also used all the Linux script versions on the client
side. Debian GNU/kFreeBSD has -- with only very few exceptions
(e.g. ifconfig) -- the same userland and C library as Debian
GNU/Linux.

> You need to modify the hobbitd/client/gnukfreebsd.c file to make it
> work with the data you get from your client. There are also some -
> probably slight - modifications needed for the
> hobbitd/rrd/do_{if,net,vm}stat.rrd files to recognize data from
> OS_GNUKFREEBSD labeled hosts,

I'll have a look. Thanks for the pointers.

> and of course the client-side script is missing.

I've got that one running, at least without error messages in the log.

> The patch is on top of the current snapshot. Please send me whatever
> modifications you do to make Hobbit work on this platform.

Ok, I'll see if it fits on top of 4.2.0 from Debian. Otherwise I'll
try the snapshot from Debian Experimental.

> PS: I know RMS is keen on the "GNU/whatever" thing, but personally I've
> always found the use of filesystem special characters in such names to 
> be a major design blunder.

Hehe.

I just use the GNU/ in front of kFreeBSD to stress that it's not a
FreeBSD -- the k looks like a typo to some people. With Linux or Hurd
it's more or less(*) clear that it has a GNU (or GNU like if in the
embedded wordl) userland.

(*) Aside from theoretical discussions about building a Linux userland
without any GPL programs, the only guys currently really experimenting
(haven't seen anything running yet) with BSD userland on Linux and
Hurd are the MirOS[1] people (mostly known for their MirBSD).

  [1] http://www.mirbsd.org/

> But now it's here, so we have to live with it.

Hmmm, reading the man page of uname on a Linux or GNU/kFreeBSD system,
I would expect uname -s to output only "kFreeBSD" or "FreeBSD" and
uname -o "GNU/kFreeBSD":

       -s, --kernel-name
              print the kernel name

       -o, --operating-system
              print the operating system

OTOH, uname -s giving "FreeBSD" output would cause breakage here,
since we couldn't distingush GNU/kFreeBSD from FreeBSD. And since
GNU/kFreeBSD uses a slightly modified FreeBSD kernel, kFreeBSD also
would point out that difference.

But uname -o wouldn't help, since at least FreeBSD's uname just
doesn't know a -o option...

Well, I think, it could be worse. :-)

		Kind regards, Axel Beckert
-- 
Axel Beckert <beckert at phys.ethz.ch>       support: +41 44 633 2668
IT Support Group, HPR E 86.1              voice:   +41 44 633 4189
Departement Physik, ETH Zurich            fax:     +41 44 633 1239
CH-8093 Zurich, Switzerland		  http://nic.phys.ethz.ch/



More information about the Xymon mailing list