Feature request: OS support for GNU/kFreeBSD 🔗 link

Hi,

I tried to get hobbit compiling and running on Debian
GNU/kFreeBSD[1]. Getting it to compile was quite easy, getting it run,
too, but getting it work isn't[2].

  [1] http://www.debian.org/ports/kfreebsd-gnu/
  [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458417

Getting the client run needed some more files to exist. Now I've got
an ugly but running client sending data to my hobbit
server. Unfortunately the server drops it with the message

2008-01-25 22:41:09 No client backend for OS 'gnu/kfreebsd' sent by [...]

In noticed that the reason for this is an OS switch() in
hobbitd/hobbitd_client.c line 1763 ff.

Back to the client:

Adding a new OS in general isn't difficult with hobbit on the client
side, you just copy some shell script, perhaps edit it and it
works. With GNU/kFreeBSD it
looks a little bit different:

  14/0/0 root at c-metisse:pts/ttyp3 22:49:51 [~] # uname -o
  GNU/kFreeBSD
  15/0/0 root at c-metisse:pts/ttyp3 22:49:54 [~] # 

There is a slash in the OS name. So all my workarounds are quite ugly
since they all involve the creation of directories to allow filenames
like

  hobbitclient-gnu/kfreebsd.sh

Not nice, but works.

The solution suggested by the GNU/kFreeBSD developers for this problem
is to replace all slashes in the output of "uname -o" with
underscores (written in Perlish: s(/)(_)g) so that the above example
would look like this:

  hobbitclient-gnu_kfreebsd.sh

Hernik: How do you think that problem is solved best from your view as
hobbit developer? You probably have more an idea which code may need
to be patch. I've lost the overview at the moment, since hobbit seems
to use the output of "uname -o" in a lot of places. Do you think, you
can generate a patch I can test? If not: with a few pointers to most
of the places in the source, I probably also can try to create a patch
on my own... Alternatively I should be able to get you an account on a
Test machine running Debian GNU/kFreeBSD. (I'm currently testing
inside a virtual machine using QEMU/KVM.)

P.S.: No, it's not for the job this time, it's for my own boxes and
those of friends. :-)

		Kind regards, Axel Beckert
-- 
Axel Beckert <user-96d9963fe797@xymon.invalid>       support: +41 44 633 2668
IT Support Group, HPR E 86.1              voice:   +41 44 633 4189
Departement Physik, ETH Zurich            fax:     +XX XX XXX XXXX
CH-8093 Zurich, Switzerland		  http://nic.phys.ethz.ch/

Axel Beckert a écrit :

this is because there is no script hobbitclient-gnu/kfreebsd.sh  in the 
~hobbit/client/bin directory.

as written in the hobbitclient.sh script, you can define you own 
bbosscript with the $BBOSSCRIPT.

/if test "$BBOSSCRIPT" = ""; then
        BBOSSCRIPT="hobbitclient-`uname -s | tr '[A-Z]' '[a-z]'`.sh"
fi
/
the difficulty is that the uname -o output contains a / character.

I already created a custom script for a freebsd based distro, and simply 
creating
the client script was enough.

hope this'll help.

Hi,

what a start in the new week. *grmbl*

On Mon, Jan 28, 2008 at 08:43:52AM +0100, pkc_mls wrote:

No this is wrong. I already tested it and have a script at appropriate
location in the ~hobbit/client/bin directory and it still happens,
because the real reason is -- as I already wrote (see below) -- this
snippet of C code inside hobbitd/hobbitd_client.c:

   1757 os = get_ostype(clientos);
   [...]
   1763 switch (os) {
   1764   case OS_FREEBSD: 
   1765         handle_freebsd_client(hostname, clientclass, os, hinfo, sender, timestamp, restofmsg);
   1766         break;
   1767 
   [...]
   1812   case OS_UNKNOWN:
   1813         errprintf("No client backend for OS '%s' sent by %s\n", clientos, sender);
   1814         break;
   1815 }

I know. I thought I wrote that:

Yeah, indeed. Did you read the mail you're replying too?

With 4.2.0, FreeBSD seems already supported, at least the scripts
exist. I found them when debugging why GNU/kFreeBSD doesn't work.

hope this'll help.

Not really much (except maybe the part where one of the appropriate tr
is and that uname -s instead of uname -o is used) since I already have
my client running on GNU/kFreeBSD, but the server's C code also needs
patching:

... and the core of my mail is to offer Henrik (and fellow developers)
(hopefully) everything they need for upstream support, ask them for
their opinion on how the best way to handle the "/" issue and finally
ask for the official upstream inclusion of the GNU/kFreeBSD support:

		Kind regards, Axel Beckert
-- 
Axel Beckert <user-96d9963fe797@xymon.invalid>       support: +41 44 633 2668
IT Support Group, HPR E 86.1              voice:   +41 44 633 4189
Departement Physik, ETH Zurich            fax:     +XX XX XXX XXXX
CH-8093 Zurich, Switzerland		  http://nic.phys.ethz.ch/

On Fri, Jan 25, 2008 at 11:23:45PM +0100, Axel Beckert wrote:

As I would expect it to do. The Hobbit server needs to know how the data
sent by the GNU/kFreeBSD client is formatted, in order for it to extract
the information it uses to check the client state against the
configuration thresholds.

Hobbit actually uses "uname -s". On my Linux system this gives "Linux",
whereas "uname -o" returns "GNU/Linux".

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.

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. This transformation happens in the lib/misc.c code.
The few places - shell scripts - that uses uname output directly can
be modified as per your developer recommendation.

I'll send You a patch does this, and also creates a basic client inter-
preter which assumes that the data looks like the Linux data. 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, and of course the
client-side script is missing.

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


Regards,
Henrik

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. But now it's here, so we have to live with
it.

Hi,

first thanks for your prompt reply and patch.

On Mon, Jan 28, 2008 at 12:29:02PM +0100, Henrik Stoerner wrote:

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. :-)

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

Ack.

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!

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.

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.

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

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 <user-96d9963fe797@xymon.invalid>       support: +41 44 633 2668
IT Support Group, HPR E 86.1              voice:   +41 44 633 4189
Departement Physik, ETH Zurich            fax:     +XX XX XXX XXXX
CH-8093 Zurich, Switzerland		  http://nic.phys.ethz.ch/