Feature request: OS support for GNU/kFreeBSD
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 <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/
Axel Beckert a écrit :
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 [...]
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.
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
Hi,
what a start in the new week. *grmbl*
On Mon, Jan 28, 2008 at 08:43:52AM +0100, pkc_mls wrote:
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 [...]
this is because there is no script hobbitclient-gnu/kfreebsd.sh in the ~hobbit/client/bin directory.
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 }
as written in the hobbitclient.sh script, you can define you own bbosscript with the $BBOSSCRIPT.
I know. I thought I wrote that:
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.
/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.
Yeah, indeed. Did you read the mail you're replying too?
There is a slash in the OS name.
I already created a custom script for a freebsd based distro, and simply creating the client script was enough.
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:
In noticed that the reason for this is an OS switch() in hobbitd/hobbitd_client.c line 1763 ff.
... 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:
Hernik: How do you think that problem is solved best from your view as hobbit developer?
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/
On Fri, Jan 25, 2008 at 11:23:45PM +0100, Axel Beckert wrote:
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 [...]
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.
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
Hobbit actually uses "uname -s". On my Linux system this gives "Linux", whereas "uname -o" returns "GNU/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.
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. 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:
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).
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 systemOTOH, 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/
participants (3)
-
beckert＠phys.ethz.ch
-
henrik＠hswn.dk
-
pkc_mls＠yahoo.fr