A funny thing happened this week. I was talking with a coworker about the "future of Hobbit", in other words, things that would help Hobbit gain more acceptance and grow the community. One of the things that I brought up was the need to get Hobbit included into popular Linux distributions. I am not sure of the policies or procedures for submitting and maintaining a new package into "Linux Distro X".
I decided that I would make a post to the mailing list of some items that I thought would be good to grow Hobbit awareness and usage. Here's the funny part (to me anyway). I purposefully held off on posting, planning to do some research first, because I have discovered I have a "habit" of posting a question or comment to the mailing list, and seemingly moments after I hit send, I figure out the answer or find some tidbit of information that nullifies my comment :)
That being said, I was stunned today to see someone (Axel Beckert) mention that they found Hobbit as a Debian package! I have recently done a search and could not find it as part of any distros. Most of the servers that I admin are RedHat (EL, CentOS, Fedora), so I'm not as active in the Debian community. I will be grabbing those packages to examine them as I'm itching to see what the "apt and lib plugins" are :)
All that being said, I'm probably getting close to the "too long didn't read" limit on this post, so here is a list, totally off the top of my head, that I think could help Hobbit in the future. I don't know whether to call them suggestions or feature requests, I'm just thinking out loud. Feel free to quash my ideas, or add your own.
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! Lets get it added to Fedora, Centos Plus, SunFreeware, etc.
Moving away from "legacy" filenames and variables. While in many ways compatible with BigBrother, Hobbit is a totally standalone, different, and superior product. 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). Everytime I am "teaching" someone how to use Hobbit, they ask "why is it called bb-hosts and not hobbit-hosts?", which then leads to a quick history lesson on how Hobbit was born :) Note that I realize you can override this with the BBHOSTS variable in hobbitserver.cfg, but the default name is still confusing for newbies.
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!". 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 and doesn't scale well. 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
Maybe a new website? The main hobbit website (http://www.hobbitmon.com) honestly looks fine to me, but others tell me that it looks more like a demo site (which it also happens to be), and the location of the information on what Hobbit is and does is not that apparent. I know Henrik has said in the past that he is not a web or UI designer, so perhaps we can find volunteers to spruce things up.
I'd write more but I'm already way past the long-post limit, so I will wait and see if anyone is interested in discussing this topic.
What is wrong with the source? I understand that packages make things easier but with the exception of my one stupid PEBKAC Henrik identified in minutes I have compiled it on several machines very quickly and easily. Managing sources (to my knowledge) is a pretty time consuming task. While I agree having the packages there with the release are definitely a plus, getting the source to package will cost someones time in packaging and support.
I have one host on the BB client that is going to be migrated here soon so I don't care either which way ;)
No shit! I agree completely! It's like FTP and telnet and stuff...
I'm a black and white text guy myself. I like the current page - informative and a great layout.
The biggest thing here is that this extra work costs extra time (and money?). Who is willing to invest their time to do these tasks?
On 1/23/08, Charles Jones <jonescr at cisco.com> wrote:
A funny thing happened this week. I was talking with a coworker about the "future of Hobbit", in other words, things that would help Hobbit gain more acceptance and grow the community. One of the things that I brought up was the need to get Hobbit included into popular Linux distributions. I am not sure of the policies or procedures for submitting and maintaining a new package into "Linux Distro X".
I decided that I would make a post to the mailing list of some items that I thought would be good to grow Hobbit awareness and usage. Here's the funny part (to me anyway). I purposefully held off on posting, planning to do some research first, because I have discovered I have a "habit" of posting a question or comment to the mailing list, and seemingly moments after I hit send, I figure out the answer or find some tidbit of information that nullifies my comment :)
That being said, I was stunned today to see someone (Axel Beckert) mention that they found Hobbit as a Debian package! I have recently done a search and could not find it as part of any distros. Most of the servers that I admin are RedHat (EL, CentOS, Fedora), so I'm not as active in the Debian community. I will be grabbing those packages to examine them as I'm itching to see what the "apt and lib plugins" are :)
All that being said, I'm probably getting close to the "too long didn't read" limit on this post, so here is a list, totally off the top of my head, that I think could help Hobbit in the future. I don't know whether to call them suggestions or feature requests, I'm just thinking out loud. Feel free to quash my ideas, or add your own.
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! Lets get it added to Fedora, Centos Plus, SunFreeware, etc.
Moving away from "legacy" filenames and variables. While in many ways compatible with BigBrother, Hobbit is a totally standalone, different, and superior product. 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). Everytime I am "teaching" someone how to use Hobbit, they ask "why is it called bb-hosts and not hobbit-hosts?", which then leads to a quick history lesson on how Hobbit was born :) Note that I realize you can override this with the BBHOSTS variable in hobbitserver.cfg, but the default name is still confusing for newbies.
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!". 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 and doesn't scale well. 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
Maybe a new website? The main hobbit website (http://www.hobbitmon.com) honestly looks fine to me, but others tell me that it looks more like a demo site (which it also happens to be), and the location of the information on what Hobbit is and does is not that apparent. I know Henrik has said in the past that he is not a web or UI designer, so perhaps we can find volunteers to spruce things up.
I'd write more but I'm already way past the long-post limit, so I will wait and see if anyone is interested in discussing this topic.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
Those who don't understand UNIX are condemned to reinvent it, poorly. --- Henry Spencer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I tryed to setup the bbwin client to also log maped drives. At the manual of bbwin is written, I just need to set "true" the
~ <!-- If true, the agent will check remote drives --> ~ <setting name="remote" value="false" />
entry at the bbwin.cfg. But I cannot see any maped drives from my windows server.
Did I something wrong or forget something at the configuration?
Thanks for your help!
Maik
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHl9Fjr4r+EhimPOURAq3aAJ0WgWraqLyA5l+1x9sbSYx6LJNBgQCgl3+A UKimqCp9pf99bW8FHNL3Kl8= =Pax9 -----END PGP SIGNATURE-----
On Jan 23, 2008 11:44 PM, Maik Heinelt <maik at vegasystems.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I tryed to setup the bbwin client to also log maped drives. At the manual of bbwin is written, I just need to set "true" the
~ <!-- If true, the agent will check remote drives --> ~ <setting name="remote" value="false" />
entry at the bbwin.cfg. But I cannot see any maped drives from my windows server.
Did I something wrong or forget something at the configuration?
Remember that drives are mapped on a per-user basis. So, to see mapped drives you'll need to have them mapped as the user that's running bbwin.
-- Please keep list traffic on the list.
Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche
On Thursday 24 January 2008, Rob MacGregor wrote:
Remember that drives are mapped on a per-user basis. So, to see mapped drives you'll need to have them mapped as the user that's running bbwin.
The exception to that, at least under win2003, is to setup a drive mapping via the "Scheduled Tasks". Under Scheduled Tasks, set the job to run as System without a password and to run at startup. This will create a Disconnected Drive mapping, that any logged on user can access. When users access this drive, their credentials are used, not the local system account.
I had to write a simple vbscript to perform the drive mapping.. needed a 60 second sleep command before drive mapping. Seems that sometimes, system startup is abit too soon to make drive mappings, hence the sleep.
There are some known issue with mapping to a samba share, haven't fully figured that out yet.
Just figured this tidbit of information may be of use to others. It took me some time to figure it out. One of my legacy apps does use UNC, and hence why this was needed.
I suggested to Henrik that he get on the SLES distribution and spoke to some folks that I knew at SuSE (now Novell) on how to do that and sent it to him.
Charles Jones wrote:
A funny thing happened this week. I was talking with a coworker about the "future of Hobbit", in other words, things that would help Hobbit gain more acceptance and grow the community. One of the things that I brought up was the need to get Hobbit included into popular Linux distributions. I am not sure of the policies or procedures for submitting and maintaining a new package into "Linux Distro X".
I decided that I would make a post to the mailing list of some items that I thought would be good to grow Hobbit awareness and usage. Here's the funny part (to me anyway). I purposefully held off on posting, planning to do some research first, because I have discovered I have a "habit" of posting a question or comment to the mailing list, and seemingly moments after I hit send, I figure out the answer or find some tidbit of information that nullifies my comment :)
That being said, I was stunned today to see someone (Axel Beckert) mention that they found Hobbit as a Debian package! I have recently done a search and could not find it as part of any distros. Most of the servers that I admin are RedHat (EL, CentOS, Fedora), so I'm not as active in the Debian community. I will be grabbing those packages to examine them as I'm itching to see what the "apt and lib plugins" are :)
All that being said, I'm probably getting close to the "too long didn't read" limit on this post, so here is a list, totally off the top of my head, that I think could help Hobbit in the future. I don't know whether to call them suggestions or feature requests, I'm just thinking out loud. Feel free to quash my ideas, or add your own.
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! Lets get it added to Fedora, Centos Plus, SunFreeware, etc.
Moving away from "legacy" filenames and variables. While in many ways compatible with BigBrother, Hobbit is a totally standalone, different, and superior product. 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). Everytime I am "teaching" someone how to use Hobbit, they ask "why is it called bb-hosts and not hobbit-hosts?", which then leads to a quick history lesson on how Hobbit was born :) Note that I realize you can override this with the BBHOSTS variable in hobbitserver.cfg, but the default name is still confusing for newbies.
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!". 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 and doesn't scale well. 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
Maybe a new website? The main hobbit website (http://www.hobbitmon.com) honestly looks fine to me, but others tell me that it looks more like a demo site (which it also happens to be), and the location of the information on what Hobbit is and does is not that apparent. I know Henrik has said in the past that he is not a web or UI designer, so perhaps we can find volunteers to spruce things up.
I'd write more but I'm already way past the long-post limit, so I will wait and see if anyone is interested in discussing this topic.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina
Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
On Wed, Jan 23, 2008 at 04:09:35PM -0700, Charles Jones wrote:
- Getting Hobbit added to major linux distributions
Would be nice. This is one area of Hobbit work where everyone on this list can make a contribution. Hobbit includes a "hobbit.spec" file for building rpm packages, and the Debian folks already have .deb's, so for most distro's it would be very little work to add Hobbit,
- 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.
- 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.
- Maybe a new website? [...] I know Henrik has said in the past that he is not a web or UI designer, so perhaps we can find volunteers to spruce things up.
Yes - please!
Regards, Henrik
On Thu, 2008-01-24 at 07:50 +0100, Henrik Stoerner wrote:
On Wed, Jan 23, 2008 at 04:09:35PM -0700, Charles Jones wrote:
- Getting Hobbit added to major linux distributions
Would be nice. This is one area of Hobbit work where everyone on this list can make a contribution. Hobbit includes a "hobbit.spec" file for building rpm packages, and the Debian folks already have .deb's, so for most distro's it would be very little work to add Hobbit,
1)Ideally, the spec file should be in the top-level directory, so that 'rpm -ta hobbit-4.2.0.tar.gz' works.
2)IMHO, the current spec file sucks ...
3)Hobbit has been in Mandriva for a long time, and the SRPMs build and run fine on all versions of RHEL I have tried them on (2.1AS, 3, 4, 5). I cleaned the spec file up a lot for the Mandriva package (so there are no conflicts between the client and server subpackage etc.):
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/hobbit/current/SP...
- 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.
Please consider an extensible format, by which I mean, a means for external checks (dbcheck, devmon, extension scripts) to retrieve their configuration from a standard set of directives.
- 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!".
And SNMPv2?
Yeah ... well, I should add some SSL support to the protocol.
A START_TLS command would be great ...
Regards, Buchan
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. ;-)
- 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. :-)
- 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.
- 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. :-)
- 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:
- 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.
- 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/
On Thu, Jan 24, 2008 at 08:34:01PM +0100, Axel Beckert wrote:
What about Windows? As far as I heard, the only current Windows client for hobbit is BBWin.
Correct. I've been contacted by a fellow who was interesting in doing a Windows port of the Hobbit server. I've encouraged him to look into it, but also made it clear that I cannot help with Windows programming.
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 believe the Ubuntu folks have picked up the Debian package for inclusion into the next release, "Hardy" 2008.04. https://launchpad.net/ubuntu/hardy/+source/hobbit
[encryption]
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.
Ok, ok - I get it :-)
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.
Actually, it's the other way around. If you look at the Hobbit README, it says this:
Hobbit is Open Source software, made available under the
GNU General Public License (GPL) version 2, with the explicit
exemption that linking with the OpenSSL libraries is permitted.That last sentence is copied almost verbatim from the OpenSSL FAQ http://www.openssl.org/support/faq.html#LEGAL2:
2. Can I use OpenSSL with GPL software ?
If you develop open source software that uses OpenSSL, you may
find it useful to choose an other license than the GPL, or state
explicitly that "This program is released under the GPL with the
additional exemption that compiling, linking, and/or using
OpenSSL is allowed." 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:
Another interesting number is that Hobbit is downloaded about 1500 times per month from Sourceforge. That number has been pretty constant over the past 12 months. http://sourceforge.net/project/stats/detail.php?group_id=128058&ugn=hobbitmo...
Nagios has about 32.000 downloads/month: http://sourceforge.net/project/stats/detail.php?group_id=26589&ugn=nagios&ty...
So Nagios is still ahead of Hobbit, but I am actually quite pleased that Hobbit has a 5% market share :-)
A STARTTLS command as with many other protocols would be cool, so no new port would be needed. (OTOH, it makes debugging less easier...)
No, STARTTLS is the "right" way of doing it, and the one I have been looking at.
Regards, Henrik
On Thu, Jan 24, 2008 at 08:34:01PM +0100, Axel Beckert wrote:
What about Windows? As far as I heard, the only current Windows
client
for hobbit is BBWin.
Correct. I've been contacted by a fellow who was interesting in doing a Windows port of the Hobbit server. I've encouraged him to look into it, but also made it clear that I cannot help with Windows programming.
...
First, thankyou Henrik for such a great product.
A Windows port of Hobbit Server would be fantastic for us. We are almost purely a Windows shop and it's just not going to change. I settled on BB purely because it was the only one I found that had a Windows port, did what we wanted (at the time) and we could run it free under the BTF licence. I discovered Hobbit purely by accident fairly recently. It gave enough advantages (mainly ongoing support and development) that the "main" server is now a Hobbit/Ubuntu/VMWare Virtual Server running on one of the Windows boxes. This is our only Linux install. I chose Ubuntu because of it reputation for ease of use for us non Linux people. The clients are still BB though I have started to modify our custom scripts to enable us to use BBWin. I will be using BB for a long time because I have 7 sites non of them could really be called a main site. Each site has it own BB server and is stand alone forwarding the information to the Hobbit server. Since Hobbit cant forward and display at the same time I cant use it. The capability to run another virtual machine is also questionable at some sites.
The next best thing to a windows port would be a MS and/or VMWare virtual server image with everything needed, loaded and going including a GUI and a easy to use GUI text editor.
I know this is almost heresy for those whose professional lives have been heavily devoted to open source and Linux but it is the reality for us and I'm sure we are not alone.
Kind Regards Graeme
Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Early Childhood Development.
Shea, Graeme A wrote:
I know this is almost heresy for those whose professional lives have been heavily devoted to open source and Linux but it is the reality for us and I'm sure we are not alone.
meh. windoze. I don't understand the hype, I just really don't.
At any rate, I understand that there is some sort of monitoring program for microsoft windows, called "mom", have you looked into it?
Regards,
Joe
Hobbit doesn't have a problem forwarding and displaying at the same time. Just run bbproxy and make one of the forwarding addresses another port on the same machine, set hobbitd to listen on that port.
Thanks, Larry Barber
On Jan 24, 2008 10:10 PM, Joe Sloan <joe at tmsusa.com> wrote:
Shea, Graeme A wrote:
I know this is almost heresy for those whose professional lives have been heavily devoted to open source and Linux but it is the reality for us and I'm sure we are not alone.
meh. windoze. I don't understand the hype, I just really don't.
At any rate, I understand that there is some sort of monitoring program for microsoft windows, called "mom", have you looked into it?
Regards,
Joe
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
On Friday 25 January 2008 02:18:37 Shea, Graeme A wrote:
First, thankyou Henrik for such a great product.
A Windows port of Hobbit Server would be fantastic for us. We are almost purely a Windows shop and it's just not going to change. I settled on BB purely because it was the only one I found that had a Windows port, did what we wanted (at the time) and we could run it free under the BTF licence. I discovered Hobbit purely by accident fairly recently. It gave enough advantages (mainly ongoing support and development) that the "main" server is now a Hobbit/Ubuntu/VMWare Virtual Server running on one of the Windows boxes. This is our only Linux install. I chose Ubuntu because of it reputation for ease of use for us non Linux people. The clients are still BB though I have started to modify our custom scripts to enable us to use BBWin. I will be using BB for a long time because I have 7 sites non of them could really be called a main site. Each site has it own BB server and is stand alone forwarding the information to the Hobbit server. Since Hobbit cant forward and display at the same time I cant use it. The capability to run another virtual machine is also questionable at some sites.
The next best thing to a windows port would be a MS and/or VMWare virtual server image with everything needed, loaded and going including a GUI and a easy to use GUI text editor.
We run a mostly Unix shop. However, an other group in our company approached us because they needed to monitor about 100 network devices, and didn't have a budget for any software. However, they had bought a PC for management purposes.
I installed Mandriva 2008.0, the included Hobbit and devmon packages, and a backported cacti (for the weathermap plugin which is not in the 2008.0 package), and (even though they didn't use it) a TACACS+ server (tac_plus) and rancid (also shipped in Mandriva 2008.0 contrib).
I added shortcuts on the desktop (e.g. one to run 'sudo kate /etc/hobbit/bb-hosts'), and they had a comprehensive monitoring and management station in 45 minutes work start-to-finish.
I know this is almost heresy for those whose professional lives have been heavily devoted to open source and Linux but it is the reality for us and I'm sure we are not alone.
Maybe there is more benefit to you finding what *other* tools will run on a Unix machine in your environment ...
Regards, Buchan
On Fri, Jan 25, 2008 at 11:18:37AM +1100, Shea, Graeme A wrote:
A Windows port of Hobbit Server would be fantastic for us. [...] The next best thing to a windows port would be a MS and/or VMWare virtual server image with everything needed, loaded and going including a GUI and a easy to use GUI text editor.
There is a VMware image on the Hobbit sourceforge page. I suppose it could easily be enhanced so the Hobbit configuration file directory was exported as a Windows fileshare, then you can edit the config files with notepad.exe <yuk...>
Regards, Henrik
Henrik Stoerner wrote:
Someone in this thread wrote that he was thinking of implementing a new web front-end. That would be fantastic! I would gladly drop support for the old static HTML files generated by bbgen in favor of a modernized web interface. And the web U/I is fairly independent from the rest of Hobbit, so it is easy to change.
I took a look at this a bit. The hardest part about this as I see it, would be pulling information from multiple data sources. For report data I could use bb commands (hobbitdxboard, or others), but then I would need to parse the server's bb-host file for page layouting. Which isn't a huge problem, just adds complication.
Also, I know you had talked about moving away from the bb-hosts file. So seems wasteful to move on this if it will be changed in the near future.
It would be intersting if the hobbitdxboard provided the data with the layout included too. But again this may add un-necessary complication.
<Page> <Name>root</Name> <Status>green</Status> <LastChanged>Wed Jan 30 07:36:10 EST 2008</LastChanged> <Title> <Name>windows servers</Name> </Title> <Page> <Name>WinServers</Name> <Status>green</Status> <LastChanged>Wed Jan 30 07:30:10 EST 2008</LastChanged> <Group> <Name>OldHardware</Name> <ServerStatus> <Name>Server1</Name>
Above is just a sample idea. Not sure if XML is the best vehicle to feed this data. But if you would like to support 3rd party GUIs (web or other) not only should the server statuses be available, but also the layout. XML is nice because a XSLT GUI can be done pretty easily.. putting a template over the XML. Though I am not a huge XML fan.. not sure what would be the best way to quickly export this data.
~Steve
On Wed, Jan 30, 2008 at 07:48:49AM -0500, s_aiello at comcast.net wrote:
Henrik Stoerner wrote:
Someone in this thread wrote that he was thinking of implementing a new web front-end. That would be fantastic! I would gladly drop support for the old static HTML files generated by bbgen in favor of a modernized web interface. And the web U/I is fairly independent from the rest of Hobbit, so it is easy to change.
I took a look at this a bit. The hardest part about this as I see it, would be pulling information from multiple data sources. For report data I could use bb commands (hobbitdxboard, or others), but then I would need to parse the server's bb-host file for page layouting. Which isn't a huge problem, just adds complication.
This assumes you want to keep on using bb-hosts as the source of your layout - I don't think that is a good idea. I would much rather have all of the webpage layout stuff moved somewhere separate, so you can generate multiple different sets of webpages from the same monitoring data. So there would be one XML file describing how the webpages are laid out, which hosts goes on what pages etc - and another XML file you get from the hobbitdxboard command that fills in the current data on those pages.
Regards, Henrik
On Wednesday 30 January 2008, Henrik Stoerner wrote:
On Wed, Jan 30, 2008 at 07:48:49AM -0500, s_aiello at comcast.net wrote:
Henrik Stoerner wrote:
Someone in this thread wrote that he was thinking of implementing a new web front-end. That would be fantastic! I would gladly drop support for the old static HTML files generated by bbgen in favor of a modernized web interface. And the web U/I is fairly independent from the rest of Hobbit, so it is easy to change.
I took a look at this a bit. The hardest part about this as I see it, would be pulling information from multiple data sources. For report data I could use bb commands (hobbitdxboard, or others), but then I would need to parse the server's bb-host file for page layouting. Which isn't a huge problem, just adds complication.
This assumes you want to keep on using bb-hosts as the source of your layout - I don't think that is a good idea. I would much rather have all of the webpage layout stuff moved somewhere separate, so you can generate multiple different sets of webpages from the same monitoring data. So there would be one XML file describing how the webpages are laid out, which hosts goes on what pages etc - and another XML file you get from the hobbitdxboard command that fills in the current data on those pages.
The only reason I would assume the need to continue to use the bb-host file as the source of layout, is because the Hobbit alert & threshold 'PAGE=' specifications do. Thats why I mentioned that I thought you had stateted the need to move away from the bb-hosts config file. GUI Layout seems to be an integral part of Hobbit (i.e. alert & threshold definitions based on layout). And again, I am not a huge fan of XML, but it seems that it would be a good option to migrate toward (from bb-hosts). That way if people did want to write a new GUI for Hobbit it would not be difficult. It would also be possible to add new fields, without affecting core Hobbit functionality. i.e. writing a version of BBMap for hobbit.
But again, I remember in a previous post your (and other maillist members) reluctance to use XML for any configuration. So it almost seems like a catch22. So as I see it, ideally need a layout config that:
- Simple to define layout.
- Open to custom field definiton additions.
- Open to allow for 3rd party GUI development.
- Doesn't break core hobbit functionality.
I maybe stating the obvious, just figure I would flush out my thoughts. ~Steve
Damian Conway in "Perl Best Practices" (published by O'Reilly) says "Don't use XML as your configuration file format. It may be human-readable, but it's almost never human-comprehensible, and the ratio of mark-up to content is vastly too high." He goes on to argue that configuration files should use a format that is much more like what Henrik has implemented in the non-Big-Brother-legacy-format, and suggests several CPAN modules that Perl programmers can use to parse these formats in their programs.
I fully agree with this notion -- let's keep Hobbit "XML-free"!
GLH
-----Original Message----- From: s_aiello at comcast.net [mailto:s_aiello at comcast.net] Sent: Wednesday, January 30, 2008 9:06 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Future of Hobbit
On Wednesday 30 January 2008, Henrik Stoerner wrote:
On Wed, Jan 30, 2008 at 07:48:49AM -0500, s_aiello at comcast.net wrote:
Henrik Stoerner wrote:
Someone in this thread wrote that he was thinking of implementing a new web front-end. That would be fantastic! I would gladly drop support for the old static HTML files generated by bbgen in favor of a modernized web interface. And the web U/I is fairly independent from the rest of Hobbit, so it is easy to change.
I took a look at this a bit. The hardest part about this as I see it, would be pulling information from multiple data sources. For report data I could use bb commands (hobbitdxboard, or others), but then I would need to parse the server's bb-host file for page layouting. Which isn't a huge problem, just adds complication.
This assumes you want to keep on using bb-hosts as the source of your layout - I don't think that is a good idea. I would much rather have all of the webpage layout stuff moved somewhere separate, so you can generate multiple different sets of webpages from the same monitoring data. So there would be one XML file describing how the webpages are laid out, which hosts goes on what pages etc - and another XML file you get from the hobbitdxboard command that fills in the current data on those pages.
The only reason I would assume the need to continue to use the bb-host file as the source of layout, is because the Hobbit alert & threshold 'PAGE=' specifications do. Thats why I mentioned that I thought you had stateted the need to move away from the bb-hosts config file. GUI Layout seems to be an integral part of Hobbit (i.e. alert & threshold definitions based on layout). And again, I am not a huge fan of XML, but it seems that it would be a good option to migrate toward (from bb-hosts). That way if people did want to write a new GUI for Hobbit it would not be difficult. It would also be possible to add new fields, without affecting core Hobbit functionality. i.e. writing a version of BBMap for hobbit.
But again, I remember in a previous post your (and other maillist members) reluctance to use XML for any configuration. So it almost seems like a catch22. So as I see it, ideally need a layout config that:
- Simple to define layout.
- Open to custom field definiton additions.
- Open to allow for 3rd party GUI development.
- Doesn't break core hobbit functionality.
I maybe stating the obvious, just figure I would flush out my thoughts. ~Steve
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
All,
Does anyone have a script that will install all necessary files for a Solaris 10 client?
don't know, where the relation is to the subject
but anyhow
http://www.blastwave.org/packages.php/hobbit_client
cheers, martin
On Wed, 30 Jan 2008, Snyder, Howard wrote:
All,
Does anyone have a script that will install all necessary files for a Solaris 10 client?
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
#!/bin/sh cd <srcdir> ./configure && make && make install
=G=
-----Original Message----- From: Snyder, Howard [mailto:HS3082 at att.com] Sent: Wednesday, January 30, 2008 12:47 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Future of Hobbit
All,
Does anyone have a script that will install all necessary files for a Solaris 10 client?
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Can I assume that the srcdir needs to have the following:
Hobbit Gcc
Anything else?
Thank you,
Howard Snyder
hs3082 at att.com
SR Network Control Engineer
Network Services
404-531-5325
This email, and any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of Cingular Wireless and its Affiliates. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, any attachments thereto, and any use of the information contained is strictly prohibited. If you have received this email in error, please notify me at 404.531.5325 and permanently delete the original and any copy thereof.
For login requests and password resets, you will need to open a request on the "My Logins" website:
https://nslogins.edc.cingular.net/login.cfm?CFID=13246&CFTOKEN=41726264
For OSS problems: DL-MNOC-OSS Adjunct DL-MNOC-OSS Siemens DL-MNOC-OSS Nortel DL-MNOC-OSS Nokia DL-MNOC-OSS Lucent DL-MNOC-OSS Ericsson
-----Original Message----- From: Galen Johnson [mailto:Galen.Johnson at sas.com] Sent: Wednesday, January 30, 2008 1:07 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Future of Hobbit
#!/bin/sh cd <srcdir> ./configure && make && make install
=G=
-----Original Message----- From: Snyder, Howard [mailto:HS3082 at att.com] Sent: Wednesday, January 30, 2008 12:47 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Future of Hobbit
All,
Does anyone have a script that will install all necessary files for a Solaris 10 client?
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Few other libraries...
Read this: http://hobbitmon.sourceforge.net/docs/install.html
Josh
On 1/30/08, Snyder, Howard <HS3082 at att.com> wrote:
Can I assume that the srcdir needs to have the following:
Hobbit Gcc
Anything else?
Thank you, Howard Snyder hs3082 at att.com SR Network Control Engineer Network Services 404-531-5325
This email, and any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of Cingular Wireless and its Affiliates. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, any attachments thereto, and any use of the information contained is strictly prohibited. If you have received this email in error, please notify me at 404.531.5325 and permanently delete the original and any copy thereof.
For login requests and password resets, you will need to open a request on the "My Logins" website:
https://nslogins.edc.cingular.net/login.cfm?CFID=13246&CFTOKEN=41726264
For OSS problems: DL-MNOC-OSS Adjunct DL-MNOC-OSS Siemens DL-MNOC-OSS Nortel DL-MNOC-OSS Nokia DL-MNOC-OSS Lucent DL-MNOC-OSS Ericsson
-----Original Message----- From: Galen Johnson [mailto:Galen.Johnson at sas.com] Sent: Wednesday, January 30, 2008 1:07 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Future of Hobbit
#!/bin/sh cd <srcdir> ./configure && make && make install
=G=
-----Original Message----- From: Snyder, Howard [mailto:HS3082 at att.com] Sent: Wednesday, January 30, 2008 12:47 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Future of Hobbit
All,
Does anyone have a script that will install all necessary files for a Solaris 10 client?
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
Those who don't understand UNIX are condemned to reinvent it, poorly. --- Henry Spencer
On Wednesday 30 January 2008, Hubbard, Greg L wrote:
Damian Conway in "Perl Best Practices" (published by O'Reilly) says "Don't use XML as your configuration file format. It may be human-readable, but it's almost never human-comprehensible, and the ratio of mark-up to content is vastly too high." He goes on to argue that configuration files should use a format that is much more like what Henrik has implemented in the non-Big-Brother-legacy-format, and suggests several CPAN modules that Perl programmers can use to parse these formats in their programs.
I fully agree with this notion -- let's keep Hobbit "XML-free"! I recently used the ini format. Very easy to read and change. There is also a nice perl module to process the files. I'm sure there are C libraries as well.
Stef
On Wed, Jan 30, 2008 at 10:06:09AM -0500, s_aiello at comcast.net wrote:
On Wednesday 30 January 2008, Henrik Stoerner wrote:
This assumes you want to keep on using bb-hosts as the source of your layout - I don't think that is a good idea.
The only reason I would assume the need to continue to use the bb-host file as the source of layout, is because the Hobbit alert & threshold 'PAGE=' specifications do.
Correct, but the PAGE setting for alerts and client-thresholds does not have to be obtained from bb-hosts ... It is really just a way to classify a group of hosts as having "something" in common, and this can easily be done in a different configuration file format.
Off the top of my head, it might even make sense to turn this entire concept upside-down: Instead of using a layout-definition to group hosts together in the alert/client config, we could use a *host* classification to define which hosts should be put on a given webpage.
And again, I am not a huge fan of XML, but it seems that it would be a good option to migrate toward (from bb-hosts). That way if people did want to write a new GUI for Hobbit it would not be difficult. It would also be possible to add new fields, without affecting core Hobbit functionality. i.e. writing a version of BBMap for hobbit.
But again, I remember in a previous post your (and other maillist members) reluctance to use XML for any configuration. So it almost seems like a catch22.
Well, I never said it would be easy :-) You are right, there are inherent conflicts between the different goals here. I am not a big fan for of XML configuration files (Hobbit doesn't have any, because I haven't bothered to go find a decent XML parsing library), but is IS a de-facto standard and there are lots of tools for handling such files. But I'd still like to weigh the pros and cons of using XML. Right now, I am not convinced.
So as I see it, ideally need a layout config that:
- Simple to define layout.
- Open to custom field definiton additions.
- Open to allow for 3rd party GUI development.
These 3 I agree with.
- Doesn't break core hobbit functionality.
This is something we can control ourselves. So don't let that stop you.
I maybe stating the obvious, just figure I would flush out my thoughts.
It often helps to discuss things that seem obvious. Often, they are not.
Regards, Henrik
Thanks for the reply, I did check out the image but (from memory) the HD was very small and there was no GUI and not much else. Being a newbie and coming from windows a GUI and GUI based text editor was important. I realize for an experienced Linux sysadmin they are superfluous but pretty much essential for me.
Yes sharing the folder and using a windows machine to edit the files is ugly and fraught with danger in not getting the LF/CR bit right. Any GUI text editor I have tried meets the criteria of "easy to use". Sorry VI whilst very powerful doesn't (IMHO).
Regards Graeme
-----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Wednesday, 30 January 2008 10:17 PM To: hobbit at hswn.dk Subject: Re: [hobbit] Future of Hobbit
On Fri, Jan 25, 2008 at 11:18:37AM +1100, Shea, Graeme A wrote:
A Windows port of Hobbit Server would be fantastic for us. [...] The next best thing to a windows port would be a MS and/or VMWare virtual server image with everything needed, loaded and going including a GUI and a easy to use GUI text editor.
There is a VMware image on the Hobbit sourceforge page. I suppose it could easily be enhanced so the Hobbit configuration file directory was exported as a Windows fileshare, then you can edit the config files with notepad.exe <yuk...>
Regards, Henrik
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Early Childhood Development.
Our windows users have shown a fondness for nedit. It's apparently more like notepad (I've never actually used it) and it's completely gui based...I prefer vim but then I've been a unix admin for about 15 years.
=G=
-----Original Message----- From: Shea, Graeme A [mailto:Shea.Graeme.A at edumail.vic.gov.au] Sent: Wed 1/30/2008 6:16 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Future of Hobbit
Thanks for the reply, I did check out the image but (from memory) the HD was very small and there was no GUI and not much else. Being a newbie and coming from windows a GUI and GUI based text editor was important. I realize for an experienced Linux sysadmin they are superfluous but pretty much essential for me.
Yes sharing the folder and using a windows machine to edit the files is ugly and fraught with danger in not getting the LF/CR bit right. Any GUI text editor I have tried meets the criteria of "easy to use". Sorry VI whilst very powerful doesn't (IMHO).
Regards Graeme
-----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Wednesday, 30 January 2008 10:17 PM To: hobbit at hswn.dk Subject: Re: [hobbit] Future of Hobbit
On Fri, Jan 25, 2008 at 11:18:37AM +1100, Shea, Graeme A wrote:
A Windows port of Hobbit Server would be fantastic for us. [...] The next best thing to a windows port would be a MS and/or VMWare virtual server image with everything needed, loaded and going including a GUI and a easy to use GUI text editor.
There is a VMware image on the Hobbit sourceforge page. I suppose it could easily be enhanced so the Hobbit configuration file directory was exported as a Windows fileshare, then you can edit the config files with notepad.exe <yuk...>
Regards, Henrik
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Early Childhood Development.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
I love VIM myself, though I have to admit sometimes it's easier to use notepad.
If you're familiar with MS Edit then you should have no problems with nano or pico. I've been noticing these two are being phased out, but you should still be able to get one or the other.
On 1/30/08, Galen Johnson <Galen.Johnson at sas.com> wrote:
Our windows users have shown a fondness for nedit. It's apparently more like notepad (I've never actually used it) and it's completely gui based...I prefer vim but then I've been a unix admin for about 15 years.
=G=
-----Original Message----- From: Shea, Graeme A [mailto:Shea.Graeme.A at edumail.vic.gov.au] Sent: Wed 1/30/2008 6:16 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Future of Hobbit
Thanks for the reply, I did check out the image but (from memory) the HD was very small and there was no GUI and not much else. Being a newbie and coming from windows a GUI and GUI based text editor was important. I realize for an experienced Linux sysadmin they are superfluous but pretty much essential for me.
Yes sharing the folder and using a windows machine to edit the files is ugly and fraught with danger in not getting the LF/CR bit right. Any GUI text editor I have tried meets the criteria of "easy to use". Sorry VI whilst very powerful doesn't (IMHO).
Regards Graeme
-----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Wednesday, 30 January 2008 10:17 PM To: hobbit at hswn.dk Subject: Re: [hobbit] Future of Hobbit
On Fri, Jan 25, 2008 at 11:18:37AM +1100, Shea, Graeme A wrote:
A Windows port of Hobbit Server would be fantastic for us. [...] The next best thing to a windows port would be a MS and/or VMWare virtual server image with everything needed, loaded and going including a GUI and a easy to use GUI text editor.
There is a VMware image on the Hobbit sourceforge page. I suppose it could easily be enhanced so the Hobbit configuration file directory was exported as a Windows fileshare, then you can edit the config files with notepad.exe <yuk...>
Regards, Henrik
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Early Childhood Development.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
Those who don't understand UNIX are condemned to reinvent it, poorly. --- Henry Spencer
Hi,
On Thu, Jan 24, 2008 at 11:06:50PM +0100, Henrik Stoerner wrote:
What about Windows? As far as I heard, the only current Windows client for hobbit is BBWin.
Correct. I've been contacted by a fellow who was interesting in doing a Windows port of the Hobbit server. I've encouraged him to look into it, but also made it clear that I cannot help with Windows programming.
Ok. For us, a working Windows XP and Vista client is important, but there seem to be a few around.
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 believe the Ubuntu folks have picked up the Debian package for inclusion into the next release, "Hardy" 2008.04. https://launchpad.net/ubuntu/hardy/+source/hobbit
Yeah, the package version number looks a lot like the original Debian package. Cool!
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.
Actually, it's the other way around. If you look at the Hobbit README, it says this:
Hobbit is Open Source software, made available under the GNU General Public License (GPL) version 2, with the explicit exemption that linking with the OpenSSL libraries is permitted.
Ok, forgot, that you already use OpenSSL for the HTTPS and other SSL-using tests. :-)
That last sentence is copied almost verbatim from the OpenSSL FAQ http://www.openssl.org/support/faq.html#LEGAL2:
2. Can I use OpenSSL with GPL software ? If you develop open source software that uses OpenSSL, you may find it useful to choose an other license than the GPL, or state explicitly that "This program is released under the GPL with the additional exemption that compiling, linking, and/or using OpenSSL is allowed."
Ok, I really remembered it the other way 'round. Thanks for clarification! :-)
[Statistics]
So Nagios is still ahead of Hobbit, but I am actually quite pleased that Hobbit has a 5% market share :-)
Ack!
For Debian and Ubuntu, there are the popcon (popularity contest) statistics:
http://qa.debian.org/popcon.php?package=hobbit http://qa.debian.org/popcon.php?package=hobbit-client http://qa.debian.org/popcon.php?package=hobbit-plugins
I haven't found any per-package statistics page for Ubuntu, but you can easily extract the relevant data from what is offered on the website:
GET http://popcon.ubuntu.com/by_inst.gz | zcat | egrep '^#rank|hobbit' #rank name inst vote old recent no-files (maintainer) 34301 hobbit 8 4 4 0 0 (Unknown) 35099 hobbit-client 7 3 4 0 0 (Unknown) 53687 hobbit-plugins 1 0 0 0 1 (Unknown)
GET http://popcon.debian.org/by_inst.gz | zcat | egrep '^#rank|hobbit' #rank name inst vote old recent no-files (maintainer) 16769 hobbit-client 70 62 3 5 0 (Christoph Berg) 21642 hobbit 33 31 1 0 1 (Christoph Berg) 23141 hobbit-plugins 26 1 0 0 25 (Christoph Berg) 83984 wmaker-hobbit-.-theme 1 0 0 0 1 (Not in sid)
So you have about 70 client and 33 server installations on Debian (of which probably 4 servers and about 20 clients and plugin packages and are ours :-) and 7 in Ubuntu.
Interestingly there are more Ubuntu hobbit servers than clients although at least in Debian the hobbit server depends on the hobbit client and can be installed without. Strange. Maybe some not official packages.
Well, I guess the Debian hobbit-client statistics will shoot up when we start deploying the hobbit client to our about 170 Debian workstations and a bunch of servers. :-) Currently one of my coworkers is preparing the new hobbit server...
A STARTTLS command as with many other protocols would be cool, so no new port would be needed. (OTOH, it makes debugging less easier...)
No, STARTTLS is the "right" way of doing it, and the one I have been looking at.
Perfect! :-)
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
On Thu, Jan 24, 2008 at 11:06:50PM +0100, Henrik Stoerner wrote:
What about Windows? As far as I heard, the only current Windows client for hobbit is BBWin.
Correct. I've been contacted by a fellow who was interesting in doing a Windows port of the Hobbit server. I've encouraged him to look into it, but also made it clear that I cannot help with Windows programming.
Ok. For us, a working Windows XP and Vista client is important, but there seem to be a few around.
Why not use BBWIN? I have it running on several XP systems and a few Vista. Sure it is XML only, but once you right one config, it is practically cut and paste for the rest.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
Maybe a silly question, but how many people are developing the core hobbit?
Also, has anyone "released" a hobbit central?
Tim
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
On 1/25/08 10:20 AM, "Henrik Stoerner" <henrik at hswn.dk> wrote:
On Fri, Jan 25, 2008 at 08:18:54AM -0600, Tim Rotunda wrote:
Maybe a silly question, but how many people are developing the core hobbit?
One - me. Is this by choice or just no one has offered to contribute?
Also, has anyone "released" a hobbit central?
Don't think so ...
To answer Axel's what is it question.....its a Hobbit version of BB-Central, which runs on a central server like hobbit does. It reaches out to the clients via ssh (or whatever) and collects data. I did a shell script version a few years ago and it worked good until the client count topped 25-30. Then I migrated it to C and it would handle 60+ nodes pretty well. Then I migrated that to a multi-threaded C process and it really smoked. I never did reach the limit with that version. I think they are still using it and adding nodes to the client list, which is prob over 250 or so.
I was going to put it out to the community but my company would not allow it (idiots) so I couldn't. I now work only 40 hours a week so now I have some time to myself and was thinking about rewriting it from memory and putting it out there. I would put out the one that is threaded and it would prob just be for x86 Linux, which should build on Solaris, HP-UX, etc.
Henrik
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
I think Henriks stance on having the server collect data via ssh connections just doesn't scale. Sure it works fine for a few dozen hosts, but let's say you have 2000 servers...now you are expecting be able to make 2000 trouble-free ssh connections before the next polling cycle begins. This introduces many problems:
- How many ssh sessions can you run at the same time without spiking the load on the hobbit server?
- What happens when an ssh session hangs (could hang the hobbit server, or make the poll cycle take too long)
You do know about the "pulldata" option? It allows the Hobbit server to do a "pull" instead of waiting for client "push". This works fairly well, and I am using it in a production environment. I can see how it would not scale to well either though, for a really large number of hosts.
To picture the scalability, imagine a server that only has to receive updates from hobbit clients. All it has to do is listen on port 1984, and using relatively little CPU it can probably handle a constant flow of client updates.
Now imagine a server that has to go and fetch the client data itself.
There is a LOT more overhead and processing involved in launching an
outgoing ssh connection, running a remote client data-gathering command,
waiting for the output, etc. Imagine 2000 of those firing off every 5
minutes. How many simultaneous ssh sessions can your server handle?
I've seen a server brought to its knees by a script that ran amok and
was doing 50 simulataneous scp commands :) Some time saving is done by
using msgcache (no waiting for the data-gathering), but there is still
the overhead of ssh itself, and having key-based ssh ability could be
deemed a security risk (anyone who hacks into the hobbit server could
then ssh to all of your client machines without a password).
A good solution would be an ssl-encrypted, bi-directional protocol. This would allow secure transfer of client data, either push or pull, without the overhead, management, and security risks of using ssh.
In the meantime, definitely check out the pulldata+msgcache option, as it sounds like it will do what you want.
-Charles
Tim Rotunda wrote:
To answer Axel's what is it question.....its a Hobbit version of BB-Central, which runs on a central server like hobbit does. It reaches out to the clients via ssh (or whatever) and collects data. I did a shell script version a few years ago and it worked good until the client count topped 25-30. Then I migrated it to C and it would handle 60+ nodes pretty well. Then I migrated that to a multi-threaded C process and it really smoked. I never did reach the limit with that version. I think they are still using it and adding nodes to the client list, which is prob over 250 or so.
I was going to put it out to the community but my company would not allow it (idiots) so I couldn't. I now work only 40 hours a week so now I have some time to myself and was thinking about rewriting it from memory and putting it out there. I would put out the one that is threaded and it would prob just be for x86 Linux, which should build on Solaris, HP-UX, etc.
I too have been victim of the rampant recreation of scp. It makes things very irritating to work with. If you've used Windows as a desktop and things slow down it has a similar feel to it - nice and laggy.
I like the idea of SSL, good one Charles =)
On 1/25/08, Charles Jones <jonescr at cisco.com> wrote:
I think Henriks stance on having the server collect data via ssh connections just doesn't scale. Sure it works fine for a few dozen hosts, but let's say you have 2000 servers...now you are expecting be able to make 2000 trouble-free ssh connections before the next polling cycle begins. This introduces many problems:
- How many ssh sessions can you run at the same time without spiking the load on the hobbit server?
- What happens when an ssh session hangs (could hang the hobbit server, or make the poll cycle take too long)
You do know about the "pulldata" option? It allows the Hobbit server to do a "pull" instead of waiting for client "push". This works fairly well, and I am using it in a production environment. I can see how it would not scale to well either though, for a really large number of hosts.
To picture the scalability, imagine a server that only has to receive updates from hobbit clients. All it has to do is listen on port 1984, and using relatively little CPU it can probably handle a constant flow of client updates.
Now imagine a server that has to go and fetch the client data itself. There is a LOT more overhead and processing involved in launching an outgoing ssh connection, running a remote client data-gathering command, waiting for the output, etc. Imagine 2000 of those firing off every 5 minutes. How many simultaneous ssh sessions can your server handle? I've seen a server brought to its knees by a script that ran amok and was doing 50 simulataneous scp commands :) Some time saving is done by using msgcache (no waiting for the data-gathering), but there is still the overhead of ssh itself, and having key-based ssh ability could be deemed a security risk (anyone who hacks into the hobbit server could then ssh to all of your client machines without a password).
A good solution would be an ssl-encrypted, bi-directional protocol. This would allow secure transfer of client data, either push or pull, without the overhead, management, and security risks of using ssh.
In the meantime, definitely check out the pulldata+msgcache option, as it sounds like it will do what you want.
-Charles
Tim Rotunda wrote:
To answer Axel's what is it question.....its a Hobbit version of BB-Central, which runs on a central server like hobbit does. It reaches out to the clients via ssh (or whatever) and collects data. I did a shell script version a few years ago and it worked good until the client count topped 25-30. Then I migrated it to C and it would handle 60+ nodes pretty well. Then I migrated that to a multi-threaded C process and it really smoked. I never did reach the limit with that version. I think they are still using it and adding nodes to the client list, which is prob over 250 or so.
I was going to put it out to the community but my company would not allow it (idiots) so I couldn't. I now work only 40 hours a week so now I have some time to myself and was thinking about rewriting it from memory and putting it out there. I would put out the one that is threaded and it would prob just be for x86 Linux, which should build on Solaris, HP-UX, etc.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
Those who don't understand UNIX are condemned to reinvent it, poorly. --- Henry Spencer
On Fri, January 25, 2008 14:43, Charles Jones wrote:
I think Henriks stance on having the server collect data via ssh connections just doesn't scale. Sure it works fine for a few dozen hosts, but let's say you have 2000 servers...now you are expecting be able to make 2000 trouble-free ssh connections before the next polling cycle begins. This introduces many problems:
I don't recall Henrik advocating this as a Good Thing. In fact, I suggested building the ssh capability into Hobbit a while back, and he explained why it was not the Right Thing to Do.
A good solution would be an ssl-encrypted, bi-directional protocol. This would allow secure transfer of client data, either push or pull, without the overhead, management, and security risks of using ssh.
Sounds rather like what Henrik said he'd pursue at some point in future, when he demurred on the ssh-integration suggestion. In lieu of it, I generally have the Hobbit server push an ssh-based port forward for tcp 1984 to each client with such a need and let the clients happily report to localhost. High port, doesn't have to be a privileged user, and you can limit the user via .ssh/authorized_keys. Autossh makes it persistent. You have the tunnel overhead, but not the constant setup/teardown of the connection. Just another way to skin the cat, has its trade-offs too.
Hobbit User in Richmond wrote:
On Fri, January 25, 2008 14:43, Charles Jones wrote:
I think Henriks stance on having the server collect data via ssh connections just doesn't scale. Sure it works fine for a few dozen hosts, but let's say you have 2000 servers...now you are expecting be able to make 2000 trouble-free ssh connections before the next polling cycle begins. This introduces many problems:
I don't recall Henrik advocating this as a Good Thing. In fact, I suggested building the ssh capability into Hobbit a while back, and he explained why it was not the Right Thing to Do.
I think I worded what I said wrong..I meant to say that Henriks stance "was that using ssh does not scale". Sorry for the confusion!
A good solution would be an ssl-encrypted, bi-directional protocol. This would allow secure transfer of client data, either push or pull, without the overhead, management, and security risks of using ssh.
Sounds rather like what Henrik said he'd pursue at some point in future, when he demurred on the ssh-integration suggestion. In lieu of it, I generally have the Hobbit server push an ssh-based port forward for tcp 1984 to each client with such a need and let the clients happily report to localhost. High port, doesn't have to be a privileged user, and you can limit the user via .ssh/authorized_keys. Autossh makes it persistent. You have the tunnel overhead, but not the constant setup/teardown of the connection. Just another way to skin the cat, has its trade-offs too.
Yeah I think he has planned to implement SSL, just hasn't gotten around to it, and since he is the only coder, we have to wait...or do we? If someone out there is good at C++, why not help Henrik out and do some of the coding for him? I've had the fact that Hobbit "only has one coder/author" raised as a red flag when I was advocating Hobbit...people ask what will happen if Henrik leaves the scene for any reason.
<i>people ask what will happen if Henrik leaves the scene for any reason.</i>
Henrik's code is very clean, any competent C programmer should be able to maintain it.
Thanks, Larry Barber
On Jan 25, 2008 2:38 PM, Charles Jones <jonescr at cisco.com> wrote:
Hobbit User in Richmond wrote:
On Fri, January 25, 2008 14:43, Charles Jones wrote:
I think Henriks stance on having the server collect data via ssh connections just doesn't scale. Sure it works fine for a few dozen hosts, but let's say you have 2000 servers...now you are expecting be able to make 2000 trouble-free ssh connections before the next polling cycle begins. This introduces many problems:
I don't recall Henrik advocating this as a Good Thing. In fact, I suggested building the ssh capability into Hobbit a while back, and he explained why it was not the Right Thing to Do.
I think I worded what I said wrong..I meant to say that Henriks stance "was that using ssh does not scale". Sorry for the confusion!
A good solution would be an ssl-encrypted, bi-directional protocol. This would allow secure transfer of client data, either push or pull, without the overhead, management, and security risks of using ssh.
Sounds rather like what Henrik said he'd pursue at some point in future, when he demurred on the ssh-integration suggestion. In lieu of it, I generally have the Hobbit server push an ssh-based port forward for tcp 1984 to each client with such a need and let the clients happily report to localhost. High port, doesn't have to be a privileged user, and you can limit the user via .ssh/authorized_keys. Autossh makes it persistent. You have the tunnel overhead, but not the constant setup/teardown of the connection. Just another way to skin the cat, has its trade-offs too.
Yeah I think he has planned to implement SSL, just hasn't gotten around to it, and since he is the only coder, we have to wait...or do we? If someone out there is good at C++, why not help Henrik out and do some of the coding for him? I've had the fact that Hobbit "only has one coder/author" raised as a red flag when I was advocating Hobbit...people ask what will happen if Henrik leaves the scene for any reason.
Larry Barber wrote:
<i>people ask what will happen if Henrik leaves the scene for any reason.</i>
Henrik's code is very clean, any competent C programmer should be able to maintain it.
Agreed. Along that line, people should be able to help him out too (unless he doesn't want it) :)
-Charles
Yeah I think he has planned to implement SSL, just hasn't gotten around to it, and since he is the only coder, we have to wait...or do we? If
I think SSL encrypted channel has higher priority over snmp query(which is also good). for some reason henrik is implementing snmp feature now.
someone out there is good at C++, why not help Henrik out and do some
No C++ skill is needed. The source code it is pure C.
of the coding for him? I've had the fact that Hobbit "only has one coder/author" raised as a red flag when I was advocating Hobbit...people ask what will happen if Henrik leaves the scene for any reason.
When reading the hobbit source code, there are other names(for patching/bug fixing) in there also.
Looks like Henrik prefer current one-man project approach. more developers more communication efforts needed. It will add another burden to him(with a full time job), I think.
I wanna do a lot stuffs with hobbit but only have limited free time and talent.
This wiki book also need contribution http://en.wikibooks.org/wiki/System_Monitoring_with_Hobbit I am putting my notes whenever I can, Hope others do the same.
tj
Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/
On Fri, Jan 25, 2008 at 03:06:20PM -0600, T.J. Yang wrote:
Yeah I think he has planned to implement SSL, just hasn't gotten around to it, and since he is the only coder, we have to wait...or do we? If
I think SSL encrypted channel has higher priority over snmp query (which is also good). for some reason henrik is implementing snmp feature now.
Features have a tendency to get implemented in the sequence that a developer needs them. I really don't need SSL-encrypted Hobbit traffic, but I do need the SNMP support.
If someone else needs the SSL stuff badly, try implementing it and send it to me for inclusion.
of the coding for him? I've had the fact that Hobbit "only has one coder/author" raised as a red flag when I was advocating Hobbit...people ask what will happen if Henrik leaves the scene for any reason.
When reading the hobbit source code, there are other names (for patching/bug fixing) in there also.
The only reason for my leaving the project would be an untimely accident. But that can happen, and the only guarantee I can give you is that the source code will always be available so someone else can take over if I am no longer around.
Looks like Henrik prefer current one-man project approach. more developers more communication efforts needed. It will add another burden to him(with a full time job), I think.
Coordination certainly is easier on one-man projects.
Realistically, Hobbit has grown to a size where there is too much to do for one person. So I wouldn't mind som help with the coding - I just haven't seen anyone step forward yet who is willing to take over part of that effort. Also, it would have to be someone whom I trust to be competent at what they're doing, and who is willing to maintain their code.
(It's not quite true that there are no other developers. Etienne does a very fine job of handling all of the Windows client code in BBWin - had he not been around, Hobbit would have a serious problem in handling Windows-based systems. This is an excellent example of how a specific module can be implemented separately).
This is a classic problem with Open Source software, by the way.
Someone in this thread wrote that he was thinking of implementing a new web front-end. That would be fantastic! I would gladly drop support for the old static HTML files generated by bbgen in favor of a modernized web interface. And the web U/I is fairly independent from the rest of Hobbit, so it is easy to change.
Regards, Henrik
On Monday 28 January 2008 16:42:52 Henrik Stoerner wrote:
Realistically, Hobbit has grown to a size where there is too much to do for one person. So I wouldn't mind som help with the coding - I just haven't seen anyone step forward yet who is willing to take over part of that effort. Also, it would have to be someone whom I trust to be competent at what they're doing, and who is willing to maintain their code.
I for one may have found time up to now, but I don't have time to download a snapshot every day in case I might find an hour to work on something (with limited connectivity). Having an accessible sourcecode repository (svn or better) might encourage people to contribute, and reduce the effort (svn diff is much easier than tracking down what you changed later), without impacting your development habits too much.
(It's not quite true that there are no other developers. Etienne does a very fine job of handling all of the Windows client code in BBWin - had he not been around, Hobbit would have a serious problem in handling Windows-based systems. This is an excellent example of how a specific module can be implemented separately).
There are also 3rd-party patches to Hobbit (specifically for adding new rrd collectors). I haven't seen any evidence of them being integrated. Since I just completed one for devmon (http://devmon.svn.sourceforge.net/viewvc/devmon/trunk/extras/do_devmon.c?vie...), this is relevant ... because I don't know how to ship a patch (http://devmon.svn.sourceforge.net/viewvc/devmon/trunk/extras/hobbit-4.2.0-de...), assuming other patches (e.g. the dbcheck one) applied, or not?
Someone in this thread wrote that he was thinking of implementing a new web front-end. That would be fantastic! I would gladly drop support for the old static HTML files generated by bbgen in favor of a modernized web interface. And the web U/I is fairly independent from the rest of Hobbit, so it is easy to change.
Right, I would like to implement this, but I have more pressing needs (shipping a devmon release so I can log a change to move it to production, and I think encryption may become a requirement very soon, plus many other projects that are behind ...).
Regards, Buchan
On 1/25/08 1:43 PM, "Charles Jones" <jonescr at cisco.com> wrote:
I think Henriks stance on having the server collect data via ssh connections just doesn't scale. Sure it works fine for a few dozen hosts, but let's say you have 2000 servers...now you are expecting be able to make 2000 trouble-free ssh connections before the next polling cycle begins. This introduces many problems:
- How many ssh sessions can you run at the same time without spiking the load on the hobbit server? The latest revision is threaded. The thread count is a parameter and is easily changed. If I remember correctly, we had 11 threads finishing all the nodes in under 90 seconds. Also, going to a threaded architecture brought cpu util from 80% to 5%. I was astonished. So we figured you could have 100's of threads running on the HP rx1600 single socket node we were using for hobbit.
- What happens when an ssh session hangs (could hang the hobbit server, or make the poll cycle take too long) Since there were many threads, a hung thread would hardly be noticed if it weren't for the purple that node would turn.
You do know about the "pulldata" option? It allows the Hobbit server to do a "pull" instead of waiting for client "push". This works fairly well, and I am using it in a production environment. I can see how it would not scale to well either though, for a really large number of hosts.
To picture the scalability, imagine a server that only has to receive updates from hobbit clients. All it has to do is listen on port 1984, and using relatively little CPU it can probably handle a constant flow of client updates.
Now imagine a server that has to go and fetch the client data itself. There is a LOT more overhead and processing involved in launching an outgoing ssh connection, running a remote client data-gathering command, waiting for the output, etc. Imagine 2000 of those firing off every 5 minutes. How many simultaneous ssh sessions can your server handle? I've seen a server brought to its knees by a script that ran amok and was doing 50 simulataneous scp commands :) Some time saving is done by using msgcache (no waiting for the data-gathering), but there is still the overhead of ssh itself, and having key-based ssh ability could be deemed a security risk (anyone who hacks into the hobbit server could then ssh to all of your client machines without a password). I don't know how you secure your servers, but nobody is getting into my hobbit/hobcen servers with out authorization. Believe it or not, there are ways to prevent unauthorized access. The caveat here is that I don't put mine on a public IP. :-)
A good solution would be an ssl-encrypted, bi-directional protocol. This would allow secure transfer of client data, either push or pull, without the overhead, management, and security risks of using ssh.
In the meantime, definitely check out the pulldata+msgcache option, as it sounds like it will do what you want. I have not looked at the option you note, however, there are times where deploying clients is not an option. I suspect that is why bb-central was born and why I developed hobcen. Like I said, it started as a shell script, morphed into a C application and then a POSIX-threaded C application. This was all based on shared ssh keys, but after coming from a stint in a DC with 60,000+ nodes on 3 acres of raised floor, I learned very quickly how to use ssh pw auth for batch communications that is fast. :-)
We all have issues to resolve and like UNIX, there are 10 different ways to solve any one of them.
Cheers,
Tim
-Charles
Tim Rotunda wrote:
To answer Axel's what is it question.....its a Hobbit version of BB-Central, which runs on a central server like hobbit does. It reaches out to the clients via ssh (or whatever) and collects data. I did a shell script version a few years ago and it worked good until the client count topped 25-30. Then I migrated it to C and it would handle 60+ nodes pretty well. Then I migrated that to a multi-threaded C process and it really smoked. I never did reach the limit with that version. I think they are still using it and adding nodes to the client list, which is prob over 250 or so.
I was going to put it out to the community but my company would not allow it (idiots) so I couldn't. I now work only 40 hours a week so now I have some time to myself and was thinking about rewriting it from memory and putting it out there. I would put out the one that is threaded and it would prob just be for x86 Linux, which should build on Solaris, HP-UX, etc.
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Tim Rotunda wrote:
I have not looked at the option you note, however, there are times where deploying clients is not an option. I suspect that is why bb-central was born and why I developed hobcen. Like I said, it started as a shell script, morphed into a C application and then a POSIX-threaded C application. This was all based on shared ssh keys, but after coming from a stint in a DC with 60,000+ nodes on 3 acres of raised floor, I learned very quickly how to use ssh pw auth for batch communications that is fast. :-)
We all have issues to resolve and like UNIX, there are 10 different ways to solve any one of them.
The pulldata option was added some time ago. You use the keyword in bb-hosts for the hosts you want to pull client data from instead of waiting for a push:
---man page snippet--- pulldata[=[IP][:port]] This option is recognized by the hobbitfetch(8) utility, and causes it to poll the host for client data. The optional IP-address and port-number can be used if the client-side msgcache(8) daemon is listening on a non-standard IP-address or port-number.
As noted it also requires activating the "msgcache" option in the clients clientlaunch.cfg. Basically what happens is the client reports the client-data to "itself", a buffer of sorts, which the Hobbit client then comes along and grabs.
You may find it useful except in the cases you mention where the installation of a client is not possible at all, although I'm not sure why you would be able to run all the commands that the normal client runs, but yet not able to run the normal client?
This is the first I have heard of hobcen...It sounds like it could be useful for some folks until Henrik provides a better solution. Have you submitted it to TheShire?
-Charles
Thanks for the info.
I can think of a myriad of reasons why clients aren¹t allowed on remote nodes, but in the case that spawned hobcen, it was because the boss said no.
I wrote the hobcen script in early 06 and the p-threaded app came along in mid 06. I was a busy IT Manager back then so it was a get it done and move on kinda thing. I just checked and it is still in production at this time.
After 20 years, I gave up on politics so I could hold onto my technical skills. As it turns out, a 40 hour work week is pretty dang nice. So I thought I would drop the group a note and see what kind of interest there is. Nothing has been submitted as yet.
Cheers,
Tim
On 1/25/08 3:35 PM, "Charles Jones" <jonescr at cisco.com> wrote:
Tim Rotunda wrote:
I have not looked at the option you note, however, there are times where deploying clients is not an option. I suspect that is why bb-central was born and why I developed hobcen. Like I said, it started as a shell script, morphed into a C application and then a POSIX-threaded C application. This was all based on shared ssh keys, but after coming from a stint in a DC with 60,000+ nodes on 3 acres of raised floor, I learned very quickly how to use ssh pw auth for batch communications that is fast. :-)
We all have issues to resolve and like UNIX, there are 10 different ways to solve any one of them.
The pulldata option was added some time ago. You use the keyword in bb-hosts for the hosts you want to pull client data from instead of waiting for a push:
---man page snippet--- pulldata[=[IP][:port]] This option is recognized by the hobbitfetch(8) utility, and causes it to poll the host for client data. The optional IP-address and port-number can be used if the client-side msgcache(8) daemon is listening on a non-standard IP-address or port-number.
As noted it also requires activating the "msgcache" option in the clients clientlaunch.cfg. Basically what happens is the client reports the client-data to "itself", a buffer of sorts, which the Hobbit client then comes along and grabs.
You may find it useful except in the cases you mention where the installation of a client is not possible at all, although I'm not sure why you would be able to run all the commands that the normal client runs, but yet not able to run the normal client?
This is the first I have heard of hobcen...It sounds like it could be useful for some folks until Henrik provides a better solution. Have you submitted it to TheShire?
-Charles
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
On Fri, Jan 25, 2008 at 08:18:54AM -0600, Tim Rotunda wrote:
Also, has anyone "released" a hobbit central?
Just being curious, but what is or should be a "hobbit central"?
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/
David Gilmore a écrit :
Why not use BBWIN? I have it running on several XP systems and a few Vista. Sure it is XML only, but once you right one config, it is practically cut and paste for the rest.
Hi
with BBwin 0.10, you can even use the centralized mode of Hobbit (the author of BBwin provides patches for 4.2.0 and the snapshot) :
"Using BBWin with Hobbit Centralized mode
To use the centralized hobbit mode of BBWin, you have to follow the following steps : You should use at least BBWin 0.10 or upper
With Hobbit stable release (4.2)
* Get the hobbit stable release on Hobbit download webpage
<http://www.hswn.dk/hobbitsw/>
* Apply the all-in-one patch <http://www.hswn.dk/hobbitsw/patches/>
* Get the bbwin patch for hobbit
<http://bbwin.sourceforge.net/download/bbwin_4.2.patch>
* Apply the bbwin patch using GNU patch. "cd" to the hobbit-4.2.0
directory, then run "patch -p0 <bbwin_4.2.patch".
* Build and install hobbit as usual"--
Frédéric Mangeant
Steria EDC Sophia Antipolis
On Thu, 24 Jan 2008, Axel Beckert wrote:
What about Windows? As far as I heard, the only current Windows client for hobbit is BBWin.
Mr Big: http://mrbig.365-24.se/
As far as I know, there are no Hobbit-specific Windows clients. There are three clients that I know of: the original Big Brother client, BBwin and Mr Big. These all use the Big Brother protocol.
Ulric
Hi Ulric,
On Fri, Jan 25, 2008 at 09:05:00AM +0100, Ulric Eriksson wrote:
What about Windows? As far as I heard, the only current Windows client for hobbit is BBWin.
Mr Big: http://mrbig.365-24.se/
As far as I know, there are no Hobbit-specific Windows clients. There are three clients that I know of: the original Big Brother client, BBwin and Mr Big. These all use the Big Brother protocol.
Thanks for the information, we'll have a look at that one, too.
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 Wed, 2008-01-23 at 16:09 -0700, Charles Jones wrote:
That being said, I was stunned today to see someone (Axel Beckert) mention that they found Hobbit as a Debian package! I have recently done a search and could not find it as part of any distros.
How did you do this search ??? http://www.rpmfind.net/linux/rpm2html/search.php?query=hobbit&submit=Search+... shows my packages for Mandriva 2008.0 and "cooker", however Hobbit has been available in Mandriva since Mandriva 2007.0.
Most of the servers that I admin are RedHat (EL, CentOS, Fedora),
My Mandriva SRPMS in Mandriva contrib (for Hobbit and devmon) rebuild fine on every version of RHEL I've tried. I would consider making them available in my existing package repo (http://staff.telkomsa.net/packages).
Since "Extras" now get shipped for RHEL ... I might be motivated to maintain the packages in Fedora as well (in parallel).
so I'm not as active in the Debian community. I will be grabbing those packages to examine them as I'm itching to see what the "apt and lib plugins" are :)
Well, I've got a trivial rhn check (only for RHEL4 and older, will add a yum one for RHEL5 shortly).
All that being said, I'm probably getting close to the "too long didn't read" limit on this post, so here is a list, totally off the top of my head, that I think could help Hobbit in the future. I don't know whether to call them suggestions or feature requests, I'm just thinking out loud. Feel free to quash my ideas, or add your own.
- 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! Lets get it added to Fedora, Centos Plus, SunFreeware, etc.
Already in Mandriva. Blastwave (a much better option than SunFreeware IMHO ... but still not at the level most linux distributions are at regarding bug trackers etc.) has packages of Hobbit and Devmon for Solaris 8 and later.
[...]
- New web interface ? I've been wondering about writing a new web interface for Hobbit (so it is possible to run without bbgen, and with no static html files), based on Catalyst (http://catalyst.perl.org/), supporting more flexible access control, supporting more configuration, discovery etc.
Regards, Buchan
- Maybe a new website? [...] I know Henrik has said in the past that he is not a web or UI designer, so perhaps we can find volunteers to spruce things up.
Yes - please!
Are we talking about the website that hosting hobbit or the hobbit web GUI ?
I think both areas have rooms for enhancements. Followings are my ideas.
Hobbit website. Gains for using Trac 1.1 Trac 1.1.1 ticket system 1.1.2 A wiki system 1.1.3 Roadmap 1.1.4 SCM(using subversion until mercurial backend is stable.)
Example: http://trac.edgewall.org/
1.2 Mercurial, lets use distributed SCM solution please.
- hobbit web GUI 2.1 switching to YUI-EXT 2.0 as web GUI. Example: http://extjs.com/ 2.2 Need to have capacity to enclose custom logos/banner for your site.
tj
On Thursday 24 January 2008 14:16:25 T.J. Yang wrote:
- Maybe a new website? [...] I know Henrik has said in the past that he is not a web or UI designer, so perhaps we can find volunteers to spruce things up.
Yes - please!
Are we talking about the website that hosting hobbit or the hobbit web GUI ?
I think both areas have rooms for enhancements. Followings are my ideas.
Hobbit website. Gains for using Trac 1.1 Trac 1.1.1 ticket system 1.1.2 A wiki system 1.1.3 Roadmap 1.1.4 SCM(using subversion until mercurial backend is stable.)
Example: http://trac.edgewall.org/1.2 Mercurial, lets use distributed SCM solution please.
Sourceforge provides all of this already 1.1 already.
Regards, Buchan
- Maybe a new website? [...] I know Henrik has said in the past that he is not a web or UI designer, so perhaps we can find volunteers to spruce things up.
Yes - please!
Are we talking about the website that hosting hobbit or the hobbit web GUI ?
I think both areas have rooms for enhancements. Followings are my ideas.
Hobbit website. Gains for using Trac 1.1 Trac 1.1.1 ticket system 1.1.2 A wiki system 1.1.3 Roadmap 1.1.4 SCM(using subversion until mercurial backend is stable.)
Example: http://trac.edgewall.org/
1.2 Mercurial, lets use distributed SCM solution please.
- hobbit web GUI 2.1 switching to YUI-EXT 2.0 as web GUI. Example: http://extjs.com/ 2.2 Need to have capacity to enclose custom logos/banner for your site.
tj
So how will all of that translate to all of the platforms that Hobbit supports today?
GLH
-----Original Message----- From: T.J. Yang [mailto:tj_yang at hotmail.com] Sent: Thursday, January 24, 2008 6:16 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Future of Hobbit
- Maybe a new website? [...] I know Henrik has said in the past that he is not a web or UI designer, so perhaps we can find volunteers to spruce things up.
Yes - please!
Are we talking about the website that hosting hobbit or the hobbit web GUI ?
I think both areas have rooms for enhancements. Followings are my ideas.
Hobbit website. Gains for using Trac 1.1 Trac 1.1.1 ticket system 1.1.2 A wiki system 1.1.3 Roadmap 1.1.4 SCM(using subversion until mercurial backend is stable.)
Example: http://trac.edgewall.org/
1.2 Mercurial, lets use distributed SCM solution please.
- hobbit web GUI 2.1 switching to YUI-EXT 2.0 as web GUI. Example: http://extjs.com/ 2.2 Need to have capacity to enclose custom logos/banner for your site.
tj
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
From: "Hubbard, Greg L" <greg.hubbard at eds.com> Sent: Thursday, January 24, 2008 7:26 AM To: <hobbit at hswn.dk> Subject: RE: [hobbit] Future of Hobbit
So how will all of that translate to all of the platforms that Hobbit supports today?
Greg
I don't quite understand your question, please explain more.
tj
GLH
-----Original Message----- From: T.J. Yang [mailto:tj_yang at hotmail.com] Sent: Thursday, January 24, 2008 6:16 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Future of Hobbit
- Maybe a new website? [...] I know Henrik has said in the past that he is not a web or UI designer, so perhaps we can find volunteers to spruce things up.
Yes - please!
Are we talking about the website that hosting hobbit or the hobbit web GUI ?
I think both areas have rooms for enhancements. Followings are my ideas.
Hobbit website. Gains for using Trac 1.1 Trac 1.1.1 ticket system 1.1.2 A wiki system 1.1.3 Roadmap 1.1.4 SCM(using subversion until mercurial backend is stable.)
Example: http://trac.edgewall.org/1.2 Mercurial, lets use distributed SCM solution please.
- hobbit web GUI 2.1 switching to YUI-EXT 2.0 as web GUI. Example: http://extjs.com/ 2.2 Need to have capacity to enclose custom logos/banner for your site.
tj
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
A lot of Hobbit users are using Linux-based packages. Some of us use "commercial" systems, so we have to compile from source. I think Hobbit would be hobbled if it were to become a Linux-oriented package, which could happen if it were to start depending on a lot of extras that are not easy to port to other operating systems. People use Hobbit for all sorts of reasons, and in all sorts of environments.
GLH
-----Original Message----- From: T.J. Yang [mailto:tj_yang at hotmail.com] Sent: Thursday, January 24, 2008 7:32 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Future of Hobbit
From: "Hubbard, Greg L" <greg.hubbard at eds.com> Sent: Thursday, January 24, 2008 7:26 AM To: <hobbit at hswn.dk> Subject: RE: [hobbit] Future of Hobbit
So how will all of that translate to all of the platforms that Hobbit supports today?
Greg
I don't quite understand your question, please explain more.
tj
GLH
-----Original Message----- From: T.J. Yang [mailto:tj_yang at hotmail.com] Sent: Thursday, January 24, 2008 6:16 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Future of Hobbit
- Maybe a new website? [...] I know Henrik has said in the past that he is not a web or UI designer, so perhaps we can find volunteers to spruce things up.
Yes - please!
Are we talking about the website that hosting hobbit or the hobbit web
GUI ?
I think both areas have rooms for enhancements. Followings are my ideas.
Hobbit website. Gains for using Trac 1.1 Trac 1.1.1 ticket system 1.1.2 A wiki system 1.1.3 Roadmap 1.1.4 SCM(using subversion until mercurial backend is stable.)
Example: http://trac.edgewall.org/1.2 Mercurial, lets use distributed SCM solution please.
- hobbit web GUI 2.1 switching to YUI-EXT 2.0 as web GUI. Example: http://extjs.com/ 2.2 Need to have capacity to enclose custom logos/banner for your site.
tj
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
No one is advocating eliminating the capability of being able to compile from source, far from it.
We wish to, hopefully, add to the user base by including Hobbit in major distributions like SLES, RHEL and others.
Hubbard, Greg L wrote:
A lot of Hobbit users are using Linux-based packages. Some of us use "commercial" systems, so we have to compile from source. I think Hobbit would be hobbled if it were to become a Linux-oriented package, which could happen if it were to start depending on a lot of extras that are not easy to port to other operating systems. People use Hobbit for all sorts of reasons, and in all sorts of environments.
GLH
-- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina
Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Rich,
I "heard that." And you probably know the "pain of porting."
-----Original Message----- From: Rich Smrcina [mailto:rsmrcina at wi.rr.com] Sent: Thursday, January 24, 2008 8:32 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Future of Hobbit
No one is advocating eliminating the capability of being able to compile from source, far from it.
We wish to, hopefully, add to the user base by including Hobbit in major distributions like SLES, RHEL and others.
Hubbard, Greg L wrote:
A lot of Hobbit users are using Linux-based packages. Some of us use "commercial" systems, so we have to compile from source. I think Hobbit would be hobbled if it were to become a Linux-oriented package,
which could happen if it were to start depending on a lot of extras that are not easy to port to other operating systems. People use Hobbit for all sorts of reasons, and in all sorts of environments.
GLH
-- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina
Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
The thing I see packages being beneficial is if there are a lot of users that need an "easier" installation. If it costs more support time to make packages then to drill down the problems with compiling then I could see a reason to make packages and update them.
Pretty sure it is understood the source isn't disappearing among everyone here. I'm sure it will be a cold day in hell when that happens ;)
On 1/24/08, Rich Smrcina <rsmrcina at wi.rr.com> wrote:
No one is advocating eliminating the capability of being able to compile from source, far from it.
We wish to, hopefully, add to the user base by including Hobbit in major distributions like SLES, RHEL and others.
Hubbard, Greg L wrote:
A lot of Hobbit users are using Linux-based packages. Some of us use "commercial" systems, so we have to compile from source. I think Hobbit would be hobbled if it were to become a Linux-oriented package, which could happen if it were to start depending on a lot of extras that are not easy to port to other operating systems. People use Hobbit for all sorts of reasons, and in all sorts of environments.
GLH
-- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina
Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
Those who don't understand UNIX are condemned to reinvent it, poorly. --- Henry Spencer
Hi,
On Thu, Jan 24, 2008 at 09:49:30AM -0500, Josh Luthman wrote:
The thing I see packages being beneficial is if there are a lot of users that need an "easier" installation. If it costs more support time to make packages then to drill down the problems with compiling then I could see a reason to make packages and update them.
Distribution packages are usually not made by the authors of the software (often called "upstream", at least in Debian slang :-) but by package maintainers of the distribution.
In the Debian case, Henrik is the upstream author and Christoph Berg the package maintainer. No additional work for Henrik, except maybe more bugreports from more users and OTOH a much easier installation for a lot of users.
So unless the C code runs on all Unices, nobody has to fear a Linuxification or more work, but Linux administrators will have less work installing and especially also maintaining hobbit: no manual security updates by reinstalling necessary.
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 (23)
-
beckert＠phys.ethz.ch
-
bgmilne＠staff.telkomsa.net
-
david＠stenhouseconsulting.com
-
frederic.mangeant＠steria.com
-
Galen.Johnson＠sas.com
-
greg.hubbard＠eds.com
-
henrik＠hswn.dk
-
hobbit＠epperson.homelinux.net
-
HS3082＠att.com
-
joe＠tmsusa.com
-
jonescr＠cisco.com
-
josh＠imaginenetworksllc.com
-
lebarber＠gmail.com
-
maik＠vegasystems.com
-
martin.flemming＠desy.de
-
rob.macgregor＠gmail.com
-
rsmrcina＠wi.rr.com
-
s_aiello＠comcast.net
-
Shea.Graeme.A＠edumail.vic.gov.au
-
stef.coene＠docum.org
-
tim.rotunda＠twcable.com
-
tj_yang＠hotmail.com
-
ulric＠siag.nu