[hobbit] Future of Hobbit
Axel Beckert
beckert at phys.ethz.ch
Thu Jan 24 20:34:01 CET 2008
Hi,
On Wed, Jan 23, 2008 at 04:09:35PM -0700, Charles Jones wrote:
> One of the things that I brought up was the need to get Hobbit
> included into popular Linux distributions. [...]
Ack. BSD ports (especially FreeBSD, but also NetBSD and OpenBSD) and
MacOS X packages are also important. There seem to be some FreeBSD
ports ready at [1], but according to FreshPorts[2], they're not (yet)
officially in the FreeBSD ports collection.
[1] http://people.freebsd.org/~dinoex/ports/
[2] http://www.freshports.org/
We will at least have a look at them, since we also have to monitor
some FreeBSD servers.
What about Windows? As far as I heard, the only current Windows client
for hobbit is BBWin.
> That being said, I was stunned today to see someone (Axel Beckert)
> mention that they found Hobbit as a Debian package!
Hehe. The official Debian packages are btw. based on Henrik's, just
with different menus (CSS instead of JS) and non-animated icons as
default skin.
> I have recently done a search and could not find it as part of any
> distros.
Well, as I wrote, the hobbit packages came to Debian only several
weeks ago. I really noticed them _because_ they were new packages. The
aptitude package manager always shows you new packages separately...
I'm working (together with the Debian maintainer) on getting hobbit
also run and packaged for Debian GNU/kFreeBSD, too. One of my
coworkers also managed to install the Debian packages also run on
Ubuntu, so I would expect that the Debian packages will find there way
into Ubuntu and derivatives.
> I will be grabbing those packages to examine them as I'm itching to
> see what the "apt and lib plugins" are :)
Those two plugins are really cool:
The apt plugin gets red on not yet installed security updates and
yellow on not yet installed other updates or if there hasn't been
looked for updates for more than a few days.
The libs plugin may be helpful also for other distros: It checks if
there are processes running linked to library files which have been
updated after the start of the process. A really useful plugin!
> All that being said, I'm probably getting close to the "too long
> didn't read" limit on this post,
Good posts can be as long as they need to be. ;-)
> 1. Getting Hobbit added to major linux distributions (apparently someone
> has already made it happen for Debian: http://packages.debian.org/hobbit).
> Whoever did this, please let us know so we can thank you!
Christoph Berg <myon at debian.org> packaged it -- as far as I know as
part of his job. Myon, do you read this list? ;-)
(If not, I'll point him to the archives. :-)
> 2. Moving away from "legacy" filenames and variables. While in many
> ways compatible with BigBrother, Hobbit is a totally standalone,
> different, and superior product.
I can back this only partially.
Of course those bb* filenames are probably very irritating for hobbit
beginners who just don't now BB or BigSister (never tried it btw.)...
OTOH I'm very happy that Hobbit is backwards compatible in many ways
so that it's easy to migrate away from BB. I think this backwards
compatibility is quite important for the success of hobbit and should
be kept.
> We should phase out the bb-* config files and have them become
> hobbit-* files, perhaps retaining symlinks so that any existing
> user-made scripts that might have the names hard-coded will still
> work).
Same counts for variables like especially BBHOME resp. HOBBITHOME.
> 3. Encryption of Hobbit data transmissions. I get this seemingly every time
> that I am explaining Hobbit..."is the data encrypted?" When I say no its
> *gasp!* "But it is sending sensitive information, process lists, logfile
> entries...over the network!".
Full Ack!
> Of course there are user-end ways of handling
> this including using ssh to tunnel the port 1984 traffic, but this is hard
> to manage
I made it work today for all my private hosts (as announced in my last
mail). stunnel was setup easily:
+----------------+ +----------------+
| Client | | Server |
+----------------+ +----------------+
| hobbit-client | | hobbit |
| v | | ^ |
| localhost:1984 | | localhost:1984 |
| v | | ^ |
| stunnel ------ Port 1983 ------> stunnel |
+----------------+ +----------------+
I couldn't resist using port 1983 for it, although I'm not sure if
the idea "before 1984" can be fitted onto the novel or scenarios. :-)
I could also have taken port 2008, but that would only work for
Germans[3].
[3] http://www.vorratsdatenspeicherung.de/?lang=en
> and doesn't scale well.
Haven't used it in the big scale at work yet, so I can't say anything
about that.
But there's another problem with all those wrapping and tunneling
solutions: All messages appear to being sent from localhost. A hobbit
internal SSL would help here, too.
> I would suggest a "simple" (heh its
> always simple to the person who doesn't have to code it eh?) implementation
> of libssl to encrypt the port 1984 traffic. That would make a lot of folks
> (Infosec, Managment, Sysadmins) happy
Ack, but be warned that (at least AFAIK) if you want to link GNU GPL
licensed software with OpenSSL, you do need the explicit allowance of
the OpenSSL authors. But in general I'm one of those sysadmins who
would be happy. :-)
> 4. Maybe a new website?
Would help, yes. Doesn't need to be fancy, just informative. Read only
or webbased access to the source code repository also would be
fine. The one at SF seems to be out of date.
On Thu, Jan 24, 2008 at 07:50:11AM +0100, Henrik Stoerner wrote:
> > 2. Moving away from "legacy" filenames and variables.
>
> The bb-hosts file is about the only one left. My intention has been to
> keep that name until Hobbit moved away from the file format in bb-hosts;
> something which I've been wanting to do for a while. The bb-hosts format
> is getting rather overloaded, and I really don't like the way it mixes
> the host configuration with the web page layout definitions. So this is
> going to change sometime.
Ah, ok. I don't know how many potential switch BB installations are
out there. But if there is quite a bunch of, a converting helper
wouldn't be bad.
BB (and hobbit) really has a few nice advantages over Nagios (which is
probably the most popular free Monitoring system), so there must be a
few out there.
Well, I'm really curios about the number of installations. Google
helps a little bit:
A search for the title string of a default BB server[4] has about
152 hits, although not all are really BB installation, but OTOH there
may be people like us who block search engines out of their BB via
robots.txt and others who changed the templates so the title is
different. So I would guess that there are probably still a few
hundred BB installations out there.
[4] http://www.google.com/search?q=allintitle:%22Big+Brother+-+Status%22
OTOH the same search for hobbit[4] gives already 84 hits, with some
paleoanthropology in between.
[5] http://www.google.com/search?q=allintitle:%22Hobbit+-+Status%22
The same kind of search for Nagios[6] counts about 44600 hits, but
since the product name isn't in the title and adding them also only
looks in the title for it, this number is probably way off.
[6] http://www.google.com/search?q=allintitle:%22Current+Network+-+Status%22
There are two other more recent competitors: Pandora FMS[7] and
Zenoss[8], but if you search for the text on Pandora FMS' login
page[9], you only get one single hit: Their demo site[10].
[7] http://pandora.sourceforge.net/
[8] http://www.zenoss.com/
[9] http://www.google.com/search?q=%22Welcome+to+Pandora+FMS+Web+Console%22
[10] http://artica.homelinux.com/pandora/
And Zenoss doesn't seem to have a public demo, so counting that way
doesn't work since I don't know for what to search.
> > 3. Encryption of Hobbit data transmissions. I get this seemingly every time
> > that I am explaining Hobbit..."is the data encrypted?" When I say no its
> > *gasp!* "But it is sending sensitive information, process lists, logfile
> > entries...over the network!".
>
> Yeah ... well, I should add some SSL support to the protocol.
A STARTTLS command as with many other protocols would be cool, so no
new port would be needed. (OTOH, it makes debugging less easier...)
Mit freundlichem Gruss, 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