Shire: update 🔗 link

-----Original Message-----
From: Galen Johnson [mailto:user-d2ff723b6cb6@xymon.invalid] Sent: Monday, July 31, 2006 11:57 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: [hobbit] Shire: update

Just wanted to give everyone a heads up on the new monitor site that is being set up (theshire.sf.net)...Sourceforge accepted it late last night

( around midnight EDT).   I want to work with Henrik a bit to make sure that our visions converge on this.  I also need to set up the categories

(at a minimum) before turning everyone loose...I would prefer there to be some structure in place beforehand.  Please be patient...I really appreciate everyone's enthusiasm for this project and I hope to have everything going in the next few days.  It's also been a LONG time since

I've done anything on SF and need to refresh my memory about things (and

become familiar with some of the new tools).

=G=

Galen Johnson wrote:

Just wanted to give everyone a heads up on the new monitor site that is being set up (theshire.sf.net)...Sourceforge accepted it late last night ( around midnight EDT).   I want to work with Henrik a bit to make sure that our visions converge on this.  I also need to set up the categories (at a minimum) before turning everyone loose...I would prefer there to be some structure in place beforehand.  Please be patient...I really appreciate everyone's enthusiasm for this project and I hope to have everything going in the next few days.  It's also been a LONG time since I've done anything on SF and need to refresh my memory about things (and become familiar with some of the new tools).

=G=

From: Galen Johnson [mailto:user-d2ff723b6cb6@xymon.invalid] Sent: Monday, July 31, 2006 10:44 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Shire: update

Galen Johnson wrote:

Just wanted to give everyone a heads up on the new monitor site that is being set up (theshire.sf.net)...Sourceforge accepted it late last night ( around midnight EDT).   I want to work with Henrik a bit to make sure that our visions converge on this.  I also need to set up the categories (at a minimum) before turning everyone loose...I would prefer there to be some structure in place beforehand.  Please be patient...I really appreciate everyone's enthusiasm for this project and I hope to have everything going in the next few days.  It's also been a LONG time since I've done anything on SF and need to refresh my

memory about things (and become familiar with some of the new tools).

=G=

OK...we're getting to the point to where we need to consider the categories...personally, I think deadcat has too many.  I'd like to keep

the categories as straightforward as possible.  I'm open to ideas as to what the basic categories should be...I'm also going to see how many times I can use the word categories in this email...

I'm hoping the the BBWin folks will consider using this area as well.  I'm not going to prompt with the list of categories I have in mind as I'd rather hear what other users think first.

I'd also like to provide a tutorial on writing monitoring scripts complete with the graphing and alerting.  Henrik has provided some basic

framework for a basic client and server script.  I should probably go back through the archives to see what already exists as well (if you know of something, by all means, please point me to it).

I have a developers list and announcement list set up.  I still need to flesh the details out a bit more.   I'd like to set up a job that automatically sends a daily report to the announce list if new/updated monitors are added but I'm going to have to figure that out later.  (I can see why Henrik hasn't found the time to tackle this :-) )

=G=

On 8/1/06, Brodie, Kent <user-8fbf1c81e97c@xymon.invalid> wrote:

One category I'd like to see is a place for user-created config files to
go as examples.  For example, sample bb-hosts files, hobbit-clients.cfg,
hobbit-alerts.cfg, etc.    I had a wee bit of struggling to get the
behavior of some of the alerting rules right, for example.

As far as categories in general, I agree deadcat has too many.....

My $0.02:

Network
Disk
Email
Databases
HTTP
Config Examples
Environment
Security

At least to start with- perhaps a few more.    I think most items can be
lumped in here somewhere.

From: Ralph Mitchell [mailto:user-00a5e44c48c0@xymon.invalid] 
Sent: Tuesday, August 01, 2006 9:16 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Shire: update

On 8/1/06, Brodie, Kent <user-8fbf1c81e97c@xymon.invalid> wrote:

One category I'd like to see is a place for user-created config files
to
go as examples.  For example, sample bb-hosts files,
hobbit-clients.cfg,
hobbit-alerts.cfg, etc.    I had a wee bit of struggling to get the
behavior of some of the alerting rules right, for example.

As far as categories in general, I agree deadcat has too many.....

My $0.02:

Network
Disk
Email
Databases
HTTP
Config Examples
Environment
Security

At least to start with- perhaps a few more.    I think most items can
be
lumped in here somewhere.

How about "OS" - or System Health??  Your Disk category could be a
subset of that.  It would include stuff like the Sparc/Solaris
temperature monitor from Deadcat.  Or would that be part of
Environment?

Ralph Mitchell

Agreed- "OS" would include disk ,cpu ,etc.   "Environment" is for
external monitors for things like, temp, water, fire, etc.   Some sites
use these things heavily.

-----Original Message-----
From: Andreas Kunberger [mailto:user-6b0b54288086@xymon.invalid] 
Sent: Tuesday, August 01, 2006 9:31 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Shire: update

Am Dienstag, 1. August 2006 16:23 schrieb Brodie, Kent:

Agreed- "OS" would include disk ,cpu ,etc.   "Environment" is for
external monitors for things like, temp, water, fire, etc.   Some
sites
use these things heavily.

What about UPS?

Andreas Kunberger

--
DITF Denkendorf

From: Charles Goyard [mailto:user-98f9625a7a59@xymon.invalid] 
Sent: Tuesday, August 01, 2006 9:56 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Shire: update

Hi,

talking about categories, one thing that deadcat misses is the display
(and search) of the column name generated. People sometime use really
generic names, such as "files", "size", "modules" or "test" (you bet)
for very application-specific matters. It can also prevent name clashes.

Just a idea.

-- 
Charles Goyard - user-98f9625a7a59@xymon.invalid - (+33) 1 45 38 01 31

I am considering moving to Hobbit from BB for our
web/database/applications development group at UCLA and have lots of
questions. I would greatly appreciate if someone could go section by
section and answer what they can. If there is somewhere that I can
search the mailing list archives, definitely point me there first as I
am sure many of these questions have been answered in the past.

First, after reading through whatever I could find on the website I am
still a little bit confused about configuration and setup. With BB, you
install and configure each client and server on the local machine,
except for the universal bb-hosts. Is this the same on Hobbit, or does
Hobbit use a central configuration file that is modified only on the
server to configure clients? I am trying to figure out the difference
between installing, maintaining and configuring BB and Hobbit setups.
Hobbit looks alot more complex to setup, but once I get my feet wet is
it any harder than BB?

Second is performance. I know this list may be biased toward Hobbit, but
is it actually faster? We have about 50-100 clients on BB and I did not
notice any performance issues. Hobbit looks like it is very complex, so
does this mean it uses a lot of resources on the client and server? What
speed/ram server is usually the minimum recommended for a dedicated
Hobbit server? Would something like a dual Pentium II 266mhz have any
performance issues as a server, if it does nothing else? What about for
clients? We have still have some testing, stating and production servers
left that are singe chip Pentium III 700-850 mhz, and even a couple
Pentium II's. Just need to make sure all the resources used for things
like graphs are taken from the server and not each client.

Third is plugins. Are BB plugins compatible with Hobbit? Also how hard
are plugins to write for Hobbit? I don't know if these even exist for
bb, but I ultimately would like to integrate plugins that 1) monitor
legato tape backup, 2) run nmap to see what ports are open/can be seen
from an external machine, 3) run 'lshw -html' to show a list of all the
hardware on the system, 4) monitor uptime, 5) monitor OS and kernel
versions (uname -a and head -n 1 /etc/issue), 6) maybe some more
router/network monitoring stuff and 7) maybe some kind of LVS
monitoring. I am not a programmer, but many of these can be done with
either existing commands or can be done on BB with existing plugins and
some (like lshw -html) are mostly static.

Fourth is relay. By this I mean monitoring systems on a private
subnetwork that are only accessible to the Hobbit server by going
through an intermediate server. Is this possible with Hobbit and is it
any more difficult to do than on BB?

Fifth is portability. BB is very portable, I can make a 'model' client
for say Red Hat and tar it and distribute it very easily to every server
I have using only a few commands. Is Hobbit the same, or are there
client dependencies or other things that may make this more difficult.

Sixth is development. How active is the development of Hobbit, how big
is the community, etc? How many people can attest to having fully
functional hobbit setups, how long has it been around and how often are
new releases usually made? Also I saw something this morning about a
Windows client -- how stable is that? How stable is the Solaris version?
Is there a client for Mac OSX? Is Hobbit like BB in the sense that you
can change paths to system binaries like grep and sed to allow easy use
on other UNIXes like OSX? When will 4.2 be officially released as a
production version? Since we have a working BB setup for now, I need to
decide if I should try to start migrating now or if I should wait some
time for Hobbit to develop more before I migrate from BB.

That's all for now. Sorry about so many questions, but I need as much
clarification and background knowledge as possible before I start trying
to convince my boss why we should dedicate the time and effort to try
out and ultimately move to Hobbit when BB "just works" without giving us
any problems. If we do adopt hobbit, I will definitely reciprocate with
help to newbies as I learn Hobbit better and will recommend it to many
other people on campus as I have previously done with BB.


Cordially,
Jordan Mendler
Systems Analyst, UCLA

First, after reading through whatever I could find on the website I am
still a little bit confused about configuration and setup. With BB, you
install and configure each client and server on the local machine,
except for the universal bb-hosts. Is this the same on Hobbit, or does
Hobbit use a central configuration file that is modified only on the
server to configure clients? I am trying to figure out the difference
between installing, maintaining and configuring BB and Hobbit setups.
Hobbit looks alot more complex to setup, but once I get my feet wet is
it any harder than BB?

Second is performance. I know this list may be biased toward Hobbit, but
is it actually faster? We have about 50-100 clients on BB and I did not
notice any performance issues. Hobbit looks like it is very complex, so
does this mean it uses a lot of resources on the client and server? What
speed/ram server is usually the minimum recommended for a dedicated
Hobbit server? Would something like a dual Pentium II 266mhz have any
performance issues as a server, if it does nothing else? What about for
clients? We have still have some testing, stating and production servers
left that are singe chip Pentium III 700-850 mhz, and even a couple
Pentium II's. Just need to make sure all the resources used for things
like graphs are taken from the server and not each client.

Third is plugins. Are BB plugins compatible with Hobbit? Also how hard
are plugins to write for Hobbit? I don't know if these even exist for
bb, but I ultimately would like to integrate plugins that 1) monitor
legato tape backup, 2) run nmap to see what ports are open/can be seen
from an external machine, 3) run 'lshw -html' to show a list of all the
hardware on the system, 4) monitor uptime, 5) monitor OS and kernel
versions (uname -a and head -n 1 /etc/issue), 6) maybe some more
router/network monitoring stuff and 7) maybe some kind of LVS
monitoring. I am not a programmer, but many of these can be done with
either existing commands or can be done on BB with existing plugins and
some (like lshw -html) are mostly static.

Fourth is relay. By this I mean monitoring systems on a private
subnetwork that are only accessible to the Hobbit server by going
through an intermediate server. Is this possible with Hobbit and is it
any more difficult to do than on BB?

Fifth is portability. BB is very portable, I can make a 'model' client
for say Red Hat and tar it and distribute it very easily to every server
I have using only a few commands. Is Hobbit the same, or are there
client dependencies or other things that may make this more difficult.

Sixth is development. How active is the development of Hobbit, how big
is the community, etc? How many people can attest to having fully
functional hobbit setups, how long has it been around and how often are
new releases usually made? Also I saw something this morning about a
Windows client -- how stable is that? How stable is the Solaris version?
Is there a client for Mac OSX? Is Hobbit like BB in the sense that you
can change paths to system binaries like grep and sed to allow easy use
on other UNIXes like OSX? When will 4.2 be officially released as a
production version? Since we have a working BB setup for now, I need to
decide if I should try to start migrating now or if I should wait some
time for Hobbit to develop more before I migrate from BB.

On Tue, Aug 01, 2006 at 12:36:29PM -0700, Jordan Mendler wrote:

First, after reading through whatever I could find on the website I am
still a little bit confused about configuration and setup. With BB, you
install and configure each client and server on the local machine,
except for the universal bb-hosts. Is this the same on Hobbit, or does
Hobbit use a central configuration file that is modified only on the
server to configure clients? I am trying to figure out the difference
between installing, maintaining and configuring BB and Hobbit setups.

Hobbit looks alot more complex to setup, but once I get my feet wet is
it any harder than BB?

Second is performance. I know this list may be biased toward Hobbit, but
is it actually faster? We have about 50-100 clients on BB and I did not
notice any performance issues.

Hobbit looks like it is very complex, so does this mean it uses a lot 
of resources on the client and server? What speed/ram server is usually 
the minimum recommended for a dedicated Hobbit server? Would something 
like a dual Pentium II 266mhz have any performance issues as a server, 
if it does nothing else? What about for clients? We have still have 
some testing, stating and production servers left that are singe chip 
Pentium III 700-850 mhz, and even a couple Pentium II's. Just need to 
make sure all the resources used for things like graphs are taken from 
the server and not each client.

I don't know if these even exist for
bb, but I ultimately would like to integrate plugins that 1) monitor
legato tape backup, 

2) run nmap to see what ports are open/can be seen from an external 
machine, 

Fourth is relay. By this I mean monitoring systems on a private
subnetwork that are only accessible to the Hobbit server by going
through an intermediate server. Is this possible with Hobbit and is it
any more difficult to do than on BB?

Fifth is portability. BB is very portable, I can make a 'model' client
for say Red Hat and tar it and distribute it very easily to every server
I have using only a few commands. Is Hobbit the same, or are there
client dependencies or other things that may make this more difficult.

Sixth is development. How active is the development of Hobbit, how big
is the community, etc? How many people can attest to having fully
functional hobbit setups, how long has it been around and how often are
new releases usually made? 

Also I saw something this morning about a Windows client -- how 
stable is that? 

Is Hobbit like BB in the sense that you can change paths to system 
binaries like grep and sed to allow easy use on other UNIXes like OSX? 

Since we have a working BB setup for now, I need to
decide if I should try to start migrating now or if I should wait some
time for Hobbit to develop more before I migrate from BB.

On 8/1/06, Henrik Stoerner <user-ce4a2c883f75@xymon.invalid> wrote:

First, let me stress that Hobbit is fully compatible with your existing
BB clients. You can keep your current client setup and just switch to
Hobbit on the server side, and all of your clients will continue to
work as they do with BB as the server. So you can migrate the server
side first, and then migrate clients when you find that it is convenient
to do so - or you want to take advantage of some of the new stuff that
is in Hobbit.

Also I saw something this morning about a Windows client -- how
stable is that?

From what I hear it should be usable. But you can stick with the
current BBNT client until it reaches version 1.0.

Since we have a working BB setup for now, I need to
decide if I should try to start migrating now or if I should wait some
time for Hobbit to develop more before I migrate from BB.

I don't think you have to wait. But it's for You to decide.

-----Original Message-----
From: Gary B. [mailto:user-33b796116d5f@xymon.invalid] 
Sent: Tuesday, August 01, 2006 3:55 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Hobbit newbie from BB: differences and what may I

First, after reading through whatever I could find on the website I am
still a little bit confused about configuration and
setup........................

-----Original Message-----
From: Brodie, Kent [mailto:user-8fbf1c81e97c@xymon.invalid] 
Sent: Tuesday, August 01, 2006 4:37 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: RE: [hobbit] Hobbit newbie from BB: differences and what may I
lose from migrating?

Most of the comments have addressed specific concerns.   I will however,
add my two cents worth, having just upgraded from a pure BB situation.

First off, I was never aware of Hobbit.  I got introduced to it when I
was playing with my BB setup at Usenix, and someone basically said
"cool, but have you seen THIS?".   

As soon as I got home, I fired up Hobbit on a test server, and began to
play.

Here's my observations, all of which I hope you can appreciate:

* Building, installation:  Much better, and cleaner than BB.    In fact,
the BB clients insisted you configured the local (client) bb-hosts file
with "itself".   Not necessary with Hobbit.  Cool part:  Once you get a
particular client built (say, for Solaris 2.8/2.9), you can tar it up
and untar it on the remote clients.   Set up a hobbit user id, set up
the init.d script, and voila.   I had to deploy this across 140 servers.
I got to the point where I could set up a new client in about a minute
and 30 seconds.

* Configuration:  As said, most of the stuff is configured ON THE
SERVER.  This is just *so* much better than BB.   All of my tests,
alarms, etc, are on the server.   Only exception are client-based EXT
scripts.  I grabbed one for Oracle monitoring (bb-moracle) and it worked
with hobbit just great.

* Performance:  I am monitoring 140 servers from a single-processor P4
server.   Barely uses any resources.   The network tests work much
faster than how BB handled it.     My average system load is 0.2.
Woooof.

* RRD: This is what sold me.  The built-in trend graphs are well....
just far too cool for words.   Trend graphs for cpu use.. disk...
memory, etc.   We had a huge ORCA installation that I trashed when I saw
this.

* Remote enable, disable:  Very very cool.   

Yes, there's a bit of a learning curve for things like the
hobbit-alerts.cfg file, or hobbit-clients.cfg file, but these come with
time after playing, and we'll help you out.

Overall, since I fired this up in lieu of BB, I haven't looked back and
am *VERY* impressed with what I have seen.   And I used BB a lot.

And, development is active and the community is growing.  The "old" BB
is basically dead from what I can see.


-----Original Message-----
From: Gary B. [mailto:user-33b796116d5f@xymon.invalid] 
Sent: Tuesday, August 01, 2006 3:55 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Hobbit newbie from BB: differences and what may I
lose from migrating?

First, after reading through whatever I could find on the website I am
still a little bit confused about configuration and
setup........................ 

On Tue, 2006-08-01 at 23:12 +0200, Henrik Stoerner wrote:

6) maybe some more router/network monitoring stuff and 

Hobbit comes with built-in network service monitoring. There is also
an SNMP add-on which can be used for monitoring devices such as routers.

From: Smith, Jim [mailto:user-dc30f243a817@xymon.invalid] 
Sent: Tuesday, August 01, 2006 4:49 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: RE: [hobbit] Hobbit newbie from BB: differences and what may I
lose from migrating?

I have to second everything that Kent said.  I am still in the process
of switching from BB to Hobbit, but I've had it set up and running since
January.  I really, really like it.

I'm going to continue using BB for a while to send messages and alerts
to the help desk folks, since I want to filter out a lot of things that
they might panic about but aren't really critical issues.  Hobbit will
be the main monitoring system for the rest of the technical staff.

Jim Smith

-----Original Message-----
From: Brodie, Kent [mailto:user-8fbf1c81e97c@xymon.invalid] 
Sent: Tuesday, August 01, 2006 5:03 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: RE: [hobbit] Hobbit newbie from BB: differences and what may I
lose from migrating?

Like Jim, I was originally going to keep parallel installations going
for some time (BB, and then Hobbit).    After only 1 day of seeing what
hobbit could do for me, my reaction was "why bother"?

I imported the bb-hosts file from BB into hobbit, turned BB off, and
went to town.    

Kent C. Brodie - user-da7f7d5174c0@xymon.invalid
Department of Physiology
Medical College of Wisconsin
(XXX) XXX-XXXX


-----Original Message-----
From: Smith, Jim [mailto:user-dc30f243a817@xymon.invalid] 
Sent: Tuesday, August 01, 2006 4:49 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: RE: [hobbit] Hobbit newbie from BB: differences and what may I
lose from migrating?

I have to second everything that Kent said.  I am still in the process
of switching from BB to Hobbit, but I've had it set up and running since
January.  I really, really like it.

I'm going to continue using BB for a while to send messages and alerts
to the help desk folks, since I want to filter out a lot of things that
they might panic about but aren't really critical issues.  Hobbit will
be the main monitoring system for the rest of the technical staff.

Jim Smith


NOTICE: This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer system.

I am considering moving to Hobbit from BB for our
web/database/applications development group at UCLA and have lots of
questions. I would greatly appreciate if someone could go section by
section and answer what they can. If there is somewhere that I can
search the mailing list archives, definitely point me there first as I
am sure many of these questions have been answered in the past.

First, after reading through whatever I could find on the website I am
still a little bit confused about configuration and setup. With BB, you
install and configure each client and server on the local machine,
except for the universal bb-hosts. Is this the same on Hobbit, or does
Hobbit use a central configuration file that is modified only on the
server to configure clients? I am trying to figure out the difference
between installing, maintaining and configuring BB and Hobbit setups.
Hobbit looks alot more complex to setup, but once I get my feet wet is
it any harder than BB?

Second is performance. I know this list may be biased toward Hobbit,
but
is it actually faster? We have about 50-100 clients on BB and I did not
notice any performance issues. Hobbit looks like it is very complex, so
does this mean it uses a lot of resources on the client and server?

What

speed/ram server is usually the minimum recommended for a dedicated
Hobbit server? Would something like a dual Pentium II 266mhz have any
performance issues as a server, if it does nothing else? What about for
clients? We have still have some testing, stating and production
servers
left that are singe chip Pentium III 700-850 mhz, and even a couple
Pentium II's. Just need to make sure all the resources used for things
like graphs are taken from the server and not each client.

Third is plugins. Are BB plugins compatible with Hobbit? Also how hard
are plugins to write for Hobbit? I don't know if these even exist for
bb, but I ultimately would like to integrate plugins that 1) monitor
legato tape backup, 2) run nmap to see what ports are open/can be seen
from an external machine, 3) run 'lshw -html' to show a list of all the
hardware on the system, 4) monitor uptime, 5) monitor OS and kernel
versions (uname -a and head -n 1 /etc/issue), 6) maybe some more
router/network monitoring stuff and 7) maybe some kind of LVS
monitoring. I am not a programmer, but many of these can be done with
either existing commands or can be done on BB with existing plugins and
some (like lshw -html) are mostly static.

Fourth is relay. By this I mean monitoring systems on a private
subnetwork that are only accessible to the Hobbit server by going
through an intermediate server. Is this possible with Hobbit and is it
any more difficult to do than on BB?

Fifth is portability. BB is very portable, I can make a 'model' client
for say Red Hat and tar it and distribute it very easily to every
server
I have using only a few commands. Is Hobbit the same, or are there
client dependencies or other things that may make this more difficult.

Sixth is development. How active is the development of Hobbit, how big
is the community, etc? How many people can attest to having fully
functional hobbit setups, how long has it been around and how often are
new releases usually made? Also I saw something this morning about a
Windows client -- how stable is that? How stable is the Solaris
version?
Is there a client for Mac OSX? Is Hobbit like BB in the sense that you
can change paths to system binaries like grep and sed to allow easy use
on other UNIXes like OSX? When will 4.2 be officially released as a
production version? Since we have a working BB setup for now, I need to
decide if I should try to start migrating now or if I should wait some
time for Hobbit to develop more before I migrate from BB.

That's all for now. Sorry about so many questions, but I need as much
clarification and background knowledge as possible before I start
trying
to convince my boss why we should dedicate the time and effort to try
out and ultimately move to Hobbit when BB "just works" without giving
us
any problems. If we do adopt hobbit, I will definitely reciprocate with
help to newbies as I learn Hobbit better and will recommend it to many
other people on campus as I have previously done with BB.

On Tue, 2006-08-01 at 23:12 +0200, Henrik Stoerner wrote:

Hi Jordan,

I'll try to answer your questions. Since I also develop Hobbit I am
probably slightly biased when it comes to the "is-this-more-difficult-
to-do-than-with-BB" type of questions, but I am sure others will
voice their opinions on that.

On Tue, Aug 01, 2006 at 12:36:29PM -0700, Jordan Mendler wrote:

First, after reading through whatever I could find on the website I am
still a little bit confused about configuration and setup. With BB, you
install and configure each client and server on the local machine,
except for the universal bb-hosts. Is this the same on Hobbit, or does

Hobbit use a central configuration file that is modified only on the
server to configure clients? I am trying to figure out the difference
between installing, maintaining and configuring BB and Hobbit setups.

First, let me stress that Hobbit is fully compatible with your existing
BB clients. You can keep your current client setup and just switch to
Hobbit on the server side, and all of your clients will continue to work as they do with BB as the server. So you can migrate the server
side first, and then migrate clients when you find that it is convenient
to do so - or you want to take advantage of some of the new stuff that
is in Hobbit.

The Hobbit client configuration is maintained on the Hobbit server. Clients in Hobbit are designed to be *really* dumb; they just collect
data, and all of the configuration of what to monitor, what thresholds
to use for e.g. disk utilisation and so on is configured only on the
Hobbit server.

This is a major difference between Hobbit and BB. With BB you have
delegated the client administration to whoever manages each server.
Hobbit centralizes the monitoring configuration, so you will probably
have a group of people who take more control of the monitoring setup.

Hobbit looks alot more complex to setup, but once I get my feet wet is
it any harder than BB?

I think it is easier, once you get used to the Hobbit way of doing
things. But as I said, I am biased.

Second is performance. I know this list may be biased toward Hobbit, but
is it actually faster? We have about 50-100 clients on BB and I did not
notice any performance issues.

With that number of systems monitored, you probably will not see a huge
difference. BB works quite well for a small number of systems, but when
you move beyond a couple of hundred boxes the overhead of generating webpages through shell scripts becomes very noticeable. On my setup,
the servers were simply choking on the disk I/O caused by BB saving
every status in a separate file, and from the huge number of small
cut-grep-awk-sed etc. commands that ran to generate webpages.

Hobbit looks like it is very complex, so does this mean it uses a lot > of resources on the client and server? What speed/ram server is usually > the minimum recommended for a dedicated Hobbit server? Would something > like a dual Pentium II 266mhz have any performance issues as a server, > if it does nothing else? What about for clients? We have still have > some testing, stating and production servers left that are singe chip > Pentium III 700-850 mhz, and even a couple Pentium II's. Just need to > make sure all the resources used for things like graphs are taken from > the server and not each client.

The Hobbit server uses fewer ressources than the BB server. The main
ressource usage is memory; Hobbit keeps everything in memory except the history logs and the RRD files used for graphs. That doesn't mean
a whole lot, though: Here's a ps listing of the Hobbit processes running on my main monitoring system - it handles about 2500 hosts:

$ ps vax|cut -c1-100|egrep "PID|hobbit"
  PID TTY      STAT   TIME  MAJFL   TRS   DRS  RSS %MEM COMMAND
  732 ?        Ss     1:24      0   101  1802  696  0.0 hobbitlaunch
  735 ?        S    2434:37     1   162 31357 29784  2.8 hobbitd
 1470 ?        S     14:50      0    99  2332 1088  0.1 hobbitd_channel --channel=stachg
 1471 ?        S     25:18      0   108  2515 1048  0.1 hobbitd_history
 1472 ?        S    964:26      0    99  2332 1264  0.1 hobbitd_channel --channel=page
 1473 ?        S    1227:34     0   154  5661 3912  0.3 hobbitd_alert
 1474 ?        S    4090:05     0    99  2332 1264  0.1 hobbitd_channel --channel=status
 1475 ?        D    2962:15     0   178  7381 4392  0.4 hobbitd_rrd
 1476 ?        S    259:55      0    99  2332 1208  0.1 hobbitd_channel --channel=data
 1477 ?        S    494:13      0   178  5141 2128  0.2 hobbitd_rrd
 1478 ?        S    126:20      0    99  2844 1832  0.1 hobbitd_channel --channel=client
 1480 ?        S    291:20      0   146  4485 2792  0.2 hobbitd_client
 5552 ?        S      0:00      0   669  2002 1352  0.1 sh -c vmstat 300 2 1>/usr/lib/hobbit/client/

As you can see, the biggest chunk of memory goes to the "hobbitd"
process which is the one that keeps all state information. It's
currently using some 31 MB of memory. (This box has 1 GB RAM).

A rough estimate of how much memory Hobbit needs would be the size of
your bbvar/logs/ directory, plus 30 MB.

As for CPU usage, your PII/266 should be adequate for 50-100 servers.
The box I'm running on is an old (7-8 years) Solaris server with a 900 MHz UltraSparc II processor. That's roughly comparable to a PII
running at 1.2 GHz. And it handles 25 times as many hosts as you are
aiming for.

Third is plugins. Are BB plugins compatible with Hobbit?

Yes.

Also how hard are plugins to write for Hobbit? 

Plugins that run on the monitored client systems are as easy to write
as for BB, since it is basically the same thing.

Hobbit also allows you to write plugins for the Hobbit server, which
receive events from the Hobbit server daemon. This is used by the core Hobbit tools - e.g. the hobbitd_rrd processes you see in the
ps-listing above are a plugin that handle updating of the RRD files
from the status- and data-messages that are sent to Hobbit. There
aren't any third-party plugins that use this yet (at least, I don't know of any), but writing them is fairly simple since it basically involves reading data from a pipe and processing it in
whatever way you want.

I don't know if these even exist for
bb, but I ultimately would like to integrate plugins that 1) monitor
legato tape backup, 

Dont know about this.

2) run nmap to see what ports are open/can be seen from an external > machine, 

The Hobbit client in version 4.2 (about to be released soon) reports
details about the network services running on a host. So you can check
for which ports are open/listening for connections, and trigger alerts
if any unwanted ports show up.

3) run 'lshw -html' to show a list of all the hardware on the system, 

This would typically be a client-side test.

4) monitor uptime, 

This is standard.

5) monitor OS and kernel versions (uname -a and head -n 1 /etc/issue), 

This data is collected by the Hobbit client.

6) maybe some more router/network monitoring stuff and 

Hobbit comes with built-in network service monitoring. There is also
an SNMP add-on which can be used for monitoring devices such as routers.

Fourth is relay. By this I mean monitoring systems on a private
subnetwork that are only accessible to the Hobbit server by going
through an intermediate server. Is this possible with Hobbit and is it
any more difficult to do than on BB?

Two ways of doing that. First, there is a proxy utility which is used
to forward Hobbit messages from one network to another. This is used if
your client systems on the private subnet are allowed to make outgoing
connections to the proxy, and the proxy can connect to the real Hobbit
server.

Second, Hobbit 4.2 includes a set of tools where it's the server that
contacts clients to pick up the data they have collected (i.e. the
traffic is initiated by the server, where the normal BB setup is for the client to initiate the connection). Useful for DMZ style setups
where clients are not allowed to generate outbound connections.

Fifth is portability. BB is very portable, I can make a 'model' client
for say Red Hat and tar it and distribute it very easily to every server
I have using only a few commands. Is Hobbit the same, or are there
client dependencies or other things that may make this more difficult.

The Hobbit client uses only the system libraries and standard utilities found on your client systems. You will need at least one system where
you can compile the client binaries (that's similar to the BB
requirements), since a few of the client-side tools are written in C.

Once you have a client compiled for an OS, it is as portable as any
binary that is dynamically linked on your platform. I.e. you can just copy it over as long as the same run-time libraries are available.

So far, we haven't managed to find any unix-like system that couldn't
run the Hobbit client. Including some rather odd ones. The current list
of client-side data collectors are

hobbitclient-aix.sh    hobbitclient-darwin.sh  hobbitclient-freebsd.sh
hobbitclient-hp-ux.sh  hobbitclient-irix.sh    hobbitclient-linux.sh
hobbitclient-netbsd.sh hobbitclient-openbsd.sh hobbitclient-osf1.sh
hobbitclient-sunos.sh

Sixth is development. How active is the development of Hobbit, how big
is the community, etc? How many people can attest to having fully
functional hobbit setups, how long has it been around and how often are
new releases usually made? 

Hobbit started back in late 2002 when it was called the "bbgen toolkit".
It was renamed to Hobbit in March 2005 when it had developed into a complete replacement for BB. More details in the hobbit(7) man-page
available online at http://www.hswn.dk/hobbit/help/manpages/

It is actively being developed by me, but people on this list have
made contributions of code. Some have picked up special projects
like the Windows client and run that completely on their own.
I'd say Hobbit currently has a very active user community, and
the development community is slowly growing beyond just myself.

There are currently 433 subscribers to the Hobbit mailing list.
According to the Sourceforge download statistics, it is downloaded
about 1000 times per month.
http://sourceforge.net/project/stats/?group_id=128058&ugn=hobbitmon&type=&mode=year

There was a thread on the mailing list back in May about who uses
Hobbit. The results were summarized here:
http://en.wikibooks.org/wiki/System_Monitoring_with_Hobbit/User_Guide#Who_use_Hobbit_.3F

New releases have usually happened frequently - 2-4 times a year.
The current interval between the 4.1.2 release and version 4.2 is unusually long - a whole year. I don't expect that to happen again.

Also I saw something this morning about a Windows client -- how > stable is that? 
From what I hear it should be usable. But you can stick with the
current BBNT client until it reaches version 1.0.

How stable is the Solaris version?

Rock-solid.

Is there a client for Mac OSX? 

Yes. It will run the Hobbit server also, if you want to.

Is Hobbit like BB in the sense that you can change paths to system > binaries like grep and sed to allow easy use on other UNIXes like OSX? 

Adding a client for a new OS will require implementing both a
client-side script to collect whatever data is interesting for this
system, and implementing the data parsing on the Hobbit server-side.
So it is somewhat more challenging. But since Hobbit already supports
all of the common Unix systems, I doubt that you will need to worry about that. If you do have a system which is not on the list, I will
help you with adding support for it.

When will 4.2 be officially released as a production version? 

Probably by the end of this week.

Since we have a working BB setup for now, I need to
decide if I should try to start migrating now or if I should wait some
time for Hobbit to develop more before I migrate from BB.

I don't think you have to wait. But it's for You to decide.


Regards,
Henrik

-----Original Message-----
From: Jordan Mendler [mailto:user-d91c99e0e5c6@xymon.invalid] 
Sent: Wednesday, 2 August 2006 9:00 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Hobbit newbie from BB: differences and what may I
lose from migrating?

Awesome guys, no doubt I am gonna try it out when I get some free time.
I think the fact that I got all my questions answered a few different
times in a very short period says something about the community.

So if I use the existing BB clients with a new Hobbit server, what
functionally will be lost until I have a chance to upgrade all the
clients to hobbit?

Thanks so much,
Jordan

 
-----Original Message-----
From: Everett, Vernon [mailto:user-36f80bd657a9@xymon.invalid] 
Sent: Tuesday, August 01, 2006 8:31 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: RE: [hobbit] Hobbit newbie from BB: differences and what may I
lose from migrating?

 
You will lose nothing.

I did exactly that. 

We had a third party monitoring our systems with BB when I joined my

previous company.

I changed the BB scripts to send to my Hobbit server as well as their BB

server. (Duplicated the bb command line with the IP address of my Hobbit

server instead of $BBDISPLAY)

This meant the third party had a BB server running, and I had a Hobbit

server, and they weren't even aware that the Hobbit server existed.

(Yes, both were running in parallel, giving the same results)

 
When I had suffiently impressed my PHB that Hobbit is better than BB,

because it could do more, we told the third party where to get off, and

all monitoring was done internally.

(OK, there was far more politics involved in dumping the third party

than just Hobbit/BB, but it helped having the ability to monitor our own

systems as well, if not better than they were.)

I then moved all our systems to the Hobbit client as and when I had

time.

 
Now stop with the questions. Just do it. You will never look back. :-)

 
Cheers

    Vernon

 
-----Original Message-----

From: Jordan Mendler [mailto:user-d91c99e0e5c6@xymon.invalid] 

Sent: Wednesday, 2 August 2006 9:00 AM

To: user-ae9b8668bcde@xymon.invalid

Subject: Re: [hobbit] Hobbit newbie from BB: differences and what may I

lose from migrating?

 
Awesome guys, no doubt I am gonna try it out when I get some free time.

I think the fact that I got all my questions answered a few different

times in a very short period says something about the community.

 
So if I use the existing BB clients with a new Hobbit server, what

functionally will be lost until I have a chance to upgrade all the

clients to hobbit?

 
Thanks so much,

Jordan

 
NOTICE: This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer system.

On Wed, 2006-08-02 at 09:30 +0800, Everett, Vernon wrote:

You will lose nothing.
I did exactly that. 
We had a third party monitoring our systems with BB when I joined my
previous company.
I changed the BB scripts to send to my Hobbit server as well as their BB
server. (Duplicated the bb command line with the IP address of my Hobbit
server instead of $BBDISPLAY)
This meant the third party had a BB server running, and I had a Hobbit
server, and they weren't even aware that the Hobbit server existed.
(Yes, both were running in parallel, giving the same results)

When I had suffiently impressed my PHB that Hobbit is better than BB,
because it could do more, we told the third party where to get off, and
all monitoring was done internally.
(OK, there was far more politics involved in dumping the third party
than just Hobbit/BB, but it helped having the ability to monitor our own
systems as well, if not better than they were.)
I then moved all our systems to the Hobbit client as and when I had
time.

Now stop with the questions. Just do it. You will never look back. :-)

Cheers
    Vernon

-----Original Message-----
From: Jordan Mendler [mailto:user-d91c99e0e5c6@xymon.invalid] 
Sent: Wednesday, 2 August 2006 9:00 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Hobbit newbie from BB: differences and what may I
lose from migrating?

Awesome guys, no doubt I am gonna try it out when I get some free time.
I think the fact that I got all my questions answered a few different
times in a very short period says something about the community.

So if I use the existing BB clients with a new Hobbit server, what
functionally will be lost until I have a chance to upgrade all the
clients to hobbit?

Thanks so much,
Jordan

Brodie, Kent wrote:

One category I'd like to see is a place for user-created config files to
go as examples.  For example, sample bb-hosts files, hobbit-clients.cfg,
hobbit-alerts.cfg, etc.    I had a wee bit of struggling to get the
behavior of some of the alerting rules right, for example.

As far as categories in general, I agree deadcat has too many.....

My $0.02:

Network
Disk
Email
Databases
HTTP
Config Examples
Environment
Security

At least to start with- perhaps a few more.    I think most items can be
lumped in here somewhere.

Kent C. Brodie - user-da7f7d5174c0@xymon.invalid
Department of Physiology
Medical College of Wisconsin
(XXX) XXX-XXXX
-----Original Message-----
From: Galen Johnson [mailto:user-d2ff723b6cb6@xymon.invalid] Sent: Monday, July 31, 2006 10:44 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Shire: update

Galen Johnson wrote:

 

Just wanted to give everyone a heads up on the new monitor site that is being set up (theshire.sf.net)...Sourceforge accepted it late last night ( around midnight EDT).   I want to work with Henrik a bit to make sure that our visions converge on this.  I also need to set up the categories (at a minimum) before turning everyone loose...I would prefer there to be some structure in place beforehand.  Please be patient...I really appreciate everyone's enthusiasm for this project and I hope to have everything going in the next few days.  It's also been a LONG time since I've done anything on SF and need to refresh my
   

memory about things (and become familiar with some of the new tools).

=G=

OK...we're getting to the point to where we need to consider the categories...personally, I think deadcat has too many.  I'd like to keep

the categories as straightforward as possible.  I'm open to ideas as to what the basic categories should be...I'm also going to see how many times I can use the word categories in this email...

I'm hoping the the BBWin folks will consider using this area as well.  I'm not going to prompt with the list of categories I have in mind as I'd rather hear what other users think first.

I'd also like to provide a tutorial on writing monitoring scripts complete with the graphing and alerting.  Henrik has provided some basic

framework for a basic client and server script.  I should probably go back through the archives to see what already exists as well (if you know of something, by all means, please point me to it).

I have a developers list and announcement list set up.  I still need to flesh the details out a bit more.   I'd like to set up a job that automatically sends a daily report to the announce list if new/updated monitors are added but I'm going to have to figure that out later.  (I can see why Henrik hasn't found the time to tackle this :-) )

=G=

 

Brodie, Kent wrote :

So long as we can "search" on the module or item description(s), we
should be fine.     

-----Original Message-----
From: Charles Goyard [mailto:user-98f9625a7a59@xymon.invalid] 
Sent: Tuesday, August 01, 2006 9:56 AM

talking about categories, one thing that deadcat misses is the display
(and search) of the column name generated. People sometime use really
generic names, such as "files", "size", "modules" or "test" (you bet)
for very application-specific matters. It can also prevent name clashes.

-- 
Charles Goyard - user-98f9625a7a59@xymon.invalid - (+33) 1 45 38 01 31

-----Original Message-----
From: Henrik Stoerner [mailto:user-ce4a2c883f75@xymon.invalid] 
Sent: Tuesday, August 01, 2006 5:13 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Hobbit newbie from BB: differences and what may I
lose from migrating?

Hi Jordan,

I'll try to answer your questions. Since I also develop Hobbit I am
probably slightly biased when it comes to the "is-this-more-difficult-
to-do-than-with-BB" type of questions, but I am sure others will
voice their opinions on that.

On Tue, Aug 01, 2006 at 12:36:29PM -0700, Jordan Mendler wrote:

First, after reading through whatever I could find on the website I am
still a little bit confused about configuration and setup. With BB,
you
install and configure each client and server on the local machine,
except for the universal bb-hosts. Is this the same on Hobbit, or does
Hobbit use a central configuration file that is modified only on the
server to configure clients? I am trying to figure out the difference
between installing, maintaining and configuring BB and Hobbit setups.

First, let me stress that Hobbit is fully compatible with your existing
BB clients. You can keep your current client setup and just switch to
Hobbit on the server side, and all of your clients will continue to 
work as they do with BB as the server. So you can migrate the server
side first, and then migrate clients when you find that it is convenient
to do so - or you want to take advantage of some of the new stuff that
is in Hobbit.

The Hobbit client configuration is maintained on the Hobbit server. 
Clients in Hobbit are designed to be *really* dumb; they just collect
data, and all of the configuration of what to monitor, what thresholds
to use for e.g. disk utilisation and so on is configured only on the
Hobbit server.

This is a major difference between Hobbit and BB. With BB you have
delegated the client administration to whoever manages each server.
Hobbit centralizes the monitoring configuration, so you will probably
have a group of people who take more control of the monitoring setup.

Hobbit looks alot more complex to setup, but once I get my feet wet is
it any harder than BB?

I think it is easier, once you get used to the Hobbit way of doing
things. But as I said, I am biased.

Second is performance. I know this list may be biased toward Hobbit,
but
is it actually faster? We have about 50-100 clients on BB and I did
not
notice any performance issues.

With that number of systems monitored, you probably will not see a huge
difference. BB works quite well for a small number of systems, but when
you move beyond a couple of hundred boxes the overhead of generating 
webpages through shell scripts becomes very noticeable. On my setup,
the servers were simply choking on the disk I/O caused by BB saving
every status in a separate file, and from the huge number of small
cut-grep-awk-sed etc. commands that ran to generate webpages.

Hobbit looks like it is very complex, so does this mean it uses a lot 
of resources on the client and server? What speed/ram server is
usually 
the minimum recommended for a dedicated Hobbit server? Would something

like a dual Pentium II 266mhz have any performance issues as a server,

if it does nothing else? What about for clients? We have still have 
some testing, stating and production servers left that are singe chip 
Pentium III 700-850 mhz, and even a couple Pentium II's. Just need to 
make sure all the resources used for things like graphs are taken from

the server and not each client.

The Hobbit server uses fewer ressources than the BB server. The main
ressource usage is memory; Hobbit keeps everything in memory except 
the history logs and the RRD files used for graphs. That doesn't mean
a whole lot, though: Here's a ps listing of the Hobbit processes running

on my main monitoring system - it handles about 2500 hosts:

$ ps vax|cut -c1-100|egrep "PID|hobbit"
  PID TTY      STAT   TIME  MAJFL   TRS   DRS  RSS %MEM COMMAND
  732 ?        Ss     1:24      0   101  1802  696  0.0 hobbitlaunch
  735 ?        S    2434:37     1   162 31357 29784  2.8 hobbitd
 1470 ?        S     14:50      0    99  2332 1088  0.1 hobbitd_channel
--channel=stachg
 1471 ?        S     25:18      0   108  2515 1048  0.1 hobbitd_history
 1472 ?        S    964:26      0    99  2332 1264  0.1 hobbitd_channel
--channel=page
 1473 ?        S    1227:34     0   154  5661 3912  0.3 hobbitd_alert
 1474 ?        S    4090:05     0    99  2332 1264  0.1 hobbitd_channel
--channel=status
 1475 ?        D    2962:15     0   178  7381 4392  0.4 hobbitd_rrd
 1476 ?        S    259:55      0    99  2332 1208  0.1 hobbitd_channel
--channel=data
 1477 ?        S    494:13      0   178  5141 2128  0.2 hobbitd_rrd
 1478 ?        S    126:20      0    99  2844 1832  0.1 hobbitd_channel
--channel=client
 1480 ?        S    291:20      0   146  4485 2792  0.2 hobbitd_client
 5552 ?        S      0:00      0   669  2002 1352  0.1 sh -c vmstat 300
2 1>/usr/lib/hobbit/client/

As you can see, the biggest chunk of memory goes to the "hobbitd"
process which is the one that keeps all state information. It's
currently using some 31 MB of memory. (This box has 1 GB RAM).

A rough estimate of how much memory Hobbit needs would be the size of
your bbvar/logs/ directory, plus 30 MB.

As for CPU usage, your PII/266 should be adequate for 50-100 servers.
The box I'm running on is an old (7-8 years) Solaris server with a 
900 MHz UltraSparc II processor. That's roughly comparable to a PII
running at 1.2 GHz. And it handles 25 times as many hosts as you are
aiming for.

Third is plugins. Are BB plugins compatible with Hobbit?

Yes.

Also how hard are plugins to write for Hobbit? 

Plugins that run on the monitored client systems are as easy to write
as for BB, since it is basically the same thing.

Hobbit also allows you to write plugins for the Hobbit server, which
receive events from the Hobbit server daemon. This is used by the 
core Hobbit tools - e.g. the hobbitd_rrd processes you see in the
ps-listing above are a plugin that handle updating of the RRD files
from the status- and data-messages that are sent to Hobbit. There
aren't any third-party plugins that use this yet (at least, I 
don't know of any), but writing them is fairly simple since it 
basically involves reading data from a pipe and processing it in
whatever way you want.

I don't know if these even exist for
bb, but I ultimately would like to integrate plugins that 1) monitor
legato tape backup, 

Dont know about this.

2) run nmap to see what ports are open/can be seen from an external 
machine, 

The Hobbit client in version 4.2 (about to be released soon) reports
details about the network services running on a host. So you can check
for which ports are open/listening for connections, and trigger alerts
if any unwanted ports show up.

3) run 'lshw -html' to show a list of all the hardware on the system, 

This would typically be a client-side test.

4) monitor uptime, 

This is standard.

5) monitor OS and kernel versions (uname -a and head -n 1 /etc/issue),

This data is collected by the Hobbit client.

6) maybe some more router/network monitoring stuff and 

Hobbit comes with built-in network service monitoring. There is also
an SNMP add-on which can be used for monitoring devices such as routers.

Fourth is relay. By this I mean monitoring systems on a private
subnetwork that are only accessible to the Hobbit server by going
through an intermediate server. Is this possible with Hobbit and is it
any more difficult to do than on BB?

Two ways of doing that. First, there is a proxy utility which is used
to forward Hobbit messages from one network to another. This is used if
your client systems on the private subnet are allowed to make outgoing
connections to the proxy, and the proxy can connect to the real Hobbit
server.

Second, Hobbit 4.2 includes a set of tools where it's the server that
contacts clients to pick up the data they have collected (i.e. the
traffic is initiated by the server, where the normal BB setup is for 
the client to initiate the connection). Useful for DMZ style setups
where clients are not allowed to generate outbound connections.

Fifth is portability. BB is very portable, I can make a 'model' client
for say Red Hat and tar it and distribute it very easily to every
server
I have using only a few commands. Is Hobbit the same, or are there
client dependencies or other things that may make this more difficult.

The Hobbit client uses only the system libraries and standard utilities 
found on your client systems. You will need at least one system where
you can compile the client binaries (that's similar to the BB
requirements), since a few of the client-side tools are written in C.

Once you have a client compiled for an OS, it is as portable as any
binary that is dynamically linked on your platform. I.e. you can 
just copy it over as long as the same run-time libraries are available.

So far, we haven't managed to find any unix-like system that couldn't
run the Hobbit client. Including some rather odd ones. The current list
of client-side data collectors are

hobbitclient-aix.sh    hobbitclient-darwin.sh  hobbitclient-freebsd.sh
hobbitclient-hp-ux.sh  hobbitclient-irix.sh    hobbitclient-linux.sh
hobbitclient-netbsd.sh hobbitclient-openbsd.sh hobbitclient-osf1.sh
hobbitclient-sunos.sh

Sixth is development. How active is the development of Hobbit, how big
is the community, etc? How many people can attest to having fully
functional hobbit setups, how long has it been around and how often
are
new releases usually made? 

Hobbit started back in late 2002 when it was called the "bbgen toolkit".
It was renamed to Hobbit in March 2005 when it had developed into a 
complete replacement for BB. More details in the hobbit(7) man-page
available online at http://www.hswn.dk/hobbit/help/manpages/

It is actively being developed by me, but people on this list have
made contributions of code. Some have picked up special projects
like the Windows client and run that completely on their own.
I'd say Hobbit currently has a very active user community, and
the development community is slowly growing beyond just myself.

There are currently 433 subscribers to the Hobbit mailing list.
According to the Sourceforge download statistics, it is downloaded
about 1000 times per month.

There was a thread on the mailing list back in May about who uses
Hobbit. The results were summarized here:

New releases have usually happened frequently - 2-4 times a year.
The current interval between the 4.1.2 release and version 4.2 is 
unusually long - a whole year. I don't expect that to happen again.

Also I saw something this morning about a Windows client -- how 
stable is that? 

From what I hear it should be usable. But you can stick with the
current BBNT client until it reaches version 1.0.

How stable is the Solaris version?

Rock-solid.

Is there a client for Mac OSX? 

Yes. It will run the Hobbit server also, if you want to.

Is Hobbit like BB in the sense that you can change paths to system 
binaries like grep and sed to allow easy use on other UNIXes like OSX?

Adding a client for a new OS will require implementing both a
client-side script to collect whatever data is interesting for this
system, and implementing the data parsing on the Hobbit server-side.
So it is somewhat more challenging. But since Hobbit already supports
all of the common Unix systems, I doubt that you will need to worry 
about that. If you do have a system which is not on the list, I will
help you with adding support for it.

When will 4.2 be officially released as a production version? 

Probably by the end of this week.

Since we have a working BB setup for now, I need to
decide if I should try to start migrating now or if I should wait some
time for Hobbit to develop more before I migrate from BB.

I don't think you have to wait. But it's for You to decide.


Regards,
Henrik

Charles Goyard wrote:

Hi,

you missed my point. I mean it should be nice to have a listing of
already picked-up test names. Think of it as an equivalent to the IANA's
tcp ports list. Deadcat has a search feature, but _nobody_ states "this
plugin reports a foo column" in descriptions.

(I also admit I have not been very clear :).

Regards,

Brodie, Kent wrote :
 

So long as we can "search" on the module or item description(s), we
should be fine.     

-----Original Message-----
From: Charles Goyard [mailto:user-98f9625a7a59@xymon.invalid] 
Sent: Tuesday, August 01, 2006 9:56 AM

talking about categories, one thing that deadcat misses is the display
(and search) of the column name generated. People sometime use really
generic names, such as "files", "size", "modules" or "test" (you bet)
for very application-specific matters. It can also prevent name clashes.
   

From: "Camp, Neil D. (ManTech) CTR" <user-22a6a1b96d9d@xymon.invalid>
Reply-To: user-ae9b8668bcde@xymon.invalid
To: <user-ae9b8668bcde@xymon.invalid>
Subject: RE: [hobbit] Hobbit newbie from BB: differences and what may I 
lose from migrating?

This is an awesome write up. Maybe you should consider adding it to your
webpage?

On Wed, 2006-08-02 at 07:37 -0400, Camp, Neil D. (ManTech) CTR wrote:

This is an awesome write up. Maybe you should consider adding it to your
webpage? 
-----Original Message-----
From: Henrik Stoerner [mailto:user-ce4a2c883f75@xymon.invalid] Sent: Tuesday, August 01, 2006 5:13 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Hobbit newbie from BB: differences and what may I
lose from migrating?

Hi Jordan,

I'll try to answer your questions. Since I also develop Hobbit I am
probably slightly biased when it comes to the "is-this-more-difficult-
to-do-than-with-BB" type of questions, but I am sure others will
voice their opinions on that.

On Tue, Aug 01, 2006 at 12:36:29PM -0700, Jordan Mendler wrote:

First, after reading through whatever I could find on the website I am
still a little bit confused about configuration and setup. With BB,
you
install and configure each client and server on the local machine,
except for the universal bb-hosts. Is this the same on Hobbit, or does

Hobbit use a central configuration file that is modified only on the
server to configure clients? I am trying to figure out the difference
between installing, maintaining and configuring BB and Hobbit setups.

First, let me stress that Hobbit is fully compatible with your existing
BB clients. You can keep your current client setup and just switch to
Hobbit on the server side, and all of your clients will continue to work as they do with BB as the server. So you can migrate the server
side first, and then migrate clients when you find that it is convenient
to do so - or you want to take advantage of some of the new stuff that
is in Hobbit.

The Hobbit client configuration is maintained on the Hobbit server. Clients in Hobbit are designed to be *really* dumb; they just collect
data, and all of the configuration of what to monitor, what thresholds
to use for e.g. disk utilisation and so on is configured only on the
Hobbit server.

This is a major difference between Hobbit and BB. With BB you have
delegated the client administration to whoever manages each server.
Hobbit centralizes the monitoring configuration, so you will probably
have a group of people who take more control of the monitoring setup.

Hobbit looks alot more complex to setup, but once I get my feet wet is
it any harder than BB?

I think it is easier, once you get used to the Hobbit way of doing
things. But as I said, I am biased.

Second is performance. I know this list may be biased toward Hobbit,
but
is it actually faster? We have about 50-100 clients on BB and I did
not
notice any performance issues.

With that number of systems monitored, you probably will not see a huge
difference. BB works quite well for a small number of systems, but when
you move beyond a couple of hundred boxes the overhead of generating webpages through shell scripts becomes very noticeable. On my setup,
the servers were simply choking on the disk I/O caused by BB saving
every status in a separate file, and from the huge number of small
cut-grep-awk-sed etc. commands that ran to generate webpages.

Hobbit looks like it is very complex, so does this mean it uses a lot > of resources on the client and server? What speed/ram server is
usually > the minimum recommended for a dedicated Hobbit server? Would something

like a dual Pentium II 266mhz have any performance issues as a server,

if it does nothing else? What about for clients? We have still have > some testing, stating and production servers left that are singe chip > Pentium III 700-850 mhz, and even a couple Pentium II's. Just need to > make sure all the resources used for things like graphs are taken from

the server and not each client.

The Hobbit server uses fewer ressources than the BB server. The main
ressource usage is memory; Hobbit keeps everything in memory except the history logs and the RRD files used for graphs. That doesn't mean
a whole lot, though: Here's a ps listing of the Hobbit processes running

on my main monitoring system - it handles about 2500 hosts:

$ ps vax|cut -c1-100|egrep "PID|hobbit"
  PID TTY      STAT   TIME  MAJFL   TRS   DRS  RSS %MEM COMMAND
  732 ?        Ss     1:24      0   101  1802  696  0.0 hobbitlaunch
  735 ?        S    2434:37     1   162 31357 29784  2.8 hobbitd
 1470 ?        S     14:50      0    99  2332 1088  0.1 hobbitd_channel
--channel=stachg
 1471 ?        S     25:18      0   108  2515 1048  0.1 hobbitd_history
 1472 ?        S    964:26      0    99  2332 1264  0.1 hobbitd_channel
--channel=page
 1473 ?        S    1227:34     0   154  5661 3912  0.3 hobbitd_alert
 1474 ?        S    4090:05     0    99  2332 1264  0.1 hobbitd_channel
--channel=status
 1475 ?        D    2962:15     0   178  7381 4392  0.4 hobbitd_rrd
 1476 ?        S    259:55      0    99  2332 1208  0.1 hobbitd_channel
--channel=data
 1477 ?        S    494:13      0   178  5141 2128  0.2 hobbitd_rrd
 1478 ?        S    126:20      0    99  2844 1832  0.1 hobbitd_channel
--channel=client
 1480 ?        S    291:20      0   146  4485 2792  0.2 hobbitd_client
 5552 ?        S      0:00      0   669  2002 1352  0.1 sh -c vmstat 300
2 1>/usr/lib/hobbit/client/

As you can see, the biggest chunk of memory goes to the "hobbitd"
process which is the one that keeps all state information. It's
currently using some 31 MB of memory. (This box has 1 GB RAM).

A rough estimate of how much memory Hobbit needs would be the size of
your bbvar/logs/ directory, plus 30 MB.

As for CPU usage, your PII/266 should be adequate for 50-100 servers.
The box I'm running on is an old (7-8 years) Solaris server with a 900 MHz UltraSparc II processor. That's roughly comparable to a PII
running at 1.2 GHz. And it handles 25 times as many hosts as you are
aiming for.

Third is plugins. Are BB plugins compatible with Hobbit?

Yes.

Also how hard are plugins to write for Hobbit? 

Plugins that run on the monitored client systems are as easy to write
as for BB, since it is basically the same thing.

Hobbit also allows you to write plugins for the Hobbit server, which
receive events from the Hobbit server daemon. This is used by the core Hobbit tools - e.g. the hobbitd_rrd processes you see in the
ps-listing above are a plugin that handle updating of the RRD files
from the status- and data-messages that are sent to Hobbit. There
aren't any third-party plugins that use this yet (at least, I don't know of any), but writing them is fairly simple since it basically involves reading data from a pipe and processing it in
whatever way you want.

I don't know if these even exist for
bb, but I ultimately would like to integrate plugins that 1) monitor
legato tape backup, 

Dont know about this.

2) run nmap to see what ports are open/can be seen from an external > machine, 

The Hobbit client in version 4.2 (about to be released soon) reports
details about the network services running on a host. So you can check
for which ports are open/listening for connections, and trigger alerts
if any unwanted ports show up.

3) run 'lshw -html' to show a list of all the hardware on the system, 

This would typically be a client-side test.

4) monitor uptime, 

This is standard.

5) monitor OS and kernel versions (uname -a and head -n 1 /etc/issue),

This data is collected by the Hobbit client.

6) maybe some more router/network monitoring stuff and 

Hobbit comes with built-in network service monitoring. There is also
an SNMP add-on which can be used for monitoring devices such as routers.

Fourth is relay. By this I mean monitoring systems on a private
subnetwork that are only accessible to the Hobbit server by going
through an intermediate server. Is this possible with Hobbit and is it
any more difficult to do than on BB?

Two ways of doing that. First, there is a proxy utility which is used
to forward Hobbit messages from one network to another. This is used if
your client systems on the private subnet are allowed to make outgoing
connections to the proxy, and the proxy can connect to the real Hobbit
server.

Second, Hobbit 4.2 includes a set of tools where it's the server that
contacts clients to pick up the data they have collected (i.e. the
traffic is initiated by the server, where the normal BB setup is for the client to initiate the connection). Useful for DMZ style setups
where clients are not allowed to generate outbound connections.

Fifth is portability. BB is very portable, I can make a 'model' client
for say Red Hat and tar it and distribute it very easily to every
server
I have using only a few commands. Is Hobbit the same, or are there
client dependencies or other things that may make this more difficult.

The Hobbit client uses only the system libraries and standard utilities found on your client systems. You will need at least one system where
you can compile the client binaries (that's similar to the BB
requirements), since a few of the client-side tools are written in C.

Once you have a client compiled for an OS, it is as portable as any
binary that is dynamically linked on your platform. I.e. you can just copy it over as long as the same run-time libraries are available.

So far, we haven't managed to find any unix-like system that couldn't
run the Hobbit client. Including some rather odd ones. The current list
of client-side data collectors are

hobbitclient-aix.sh    hobbitclient-darwin.sh  hobbitclient-freebsd.sh
hobbitclient-hp-ux.sh  hobbitclient-irix.sh    hobbitclient-linux.sh
hobbitclient-netbsd.sh hobbitclient-openbsd.sh hobbitclient-osf1.sh
hobbitclient-sunos.sh

Sixth is development. How active is the development of Hobbit, how big
is the community, etc? How many people can attest to having fully
functional hobbit setups, how long has it been around and how often
are
new releases usually made? 

Hobbit started back in late 2002 when it was called the "bbgen toolkit".
It was renamed to Hobbit in March 2005 when it had developed into a complete replacement for BB. More details in the hobbit(7) man-page
available online at http://www.hswn.dk/hobbit/help/manpages/

It is actively being developed by me, but people on this list have
made contributions of code. Some have picked up special projects
like the Windows client and run that completely on their own.
I'd say Hobbit currently has a very active user community, and
the development community is slowly growing beyond just myself.

There are currently 433 subscribers to the Hobbit mailing list.
According to the Sourceforge download statistics, it is downloaded
about 1000 times per month.
http://sourceforge.net/project/stats/?group_id=128058&ugn=hobbitmon&type
=&mode=year

There was a thread on the mailing list back in May about who uses
Hobbit. The results were summarized here:
http://en.wikibooks.org/wiki/System_Monitoring_with_Hobbit/User_Guide#Wh
o_use_Hobbit_.3F

New releases have usually happened frequently - 2-4 times a year.
The current interval between the 4.1.2 release and version 4.2 is unusually long - a whole year. I don't expect that to happen again.

Also I saw something this morning about a Windows client -- how > stable is that? 
From what I hear it should be usable. But you can stick with the
current BBNT client until it reaches version 1.0.

How stable is the Solaris version?

Rock-solid.

Is there a client for Mac OSX? 

Yes. It will run the Hobbit server also, if you want to.

Is Hobbit like BB in the sense that you can change paths to system > binaries like grep and sed to allow easy use on other UNIXes like OSX?

Adding a client for a new OS will require implementing both a
client-side script to collect whatever data is interesting for this
system, and implementing the data parsing on the Hobbit server-side.
So it is somewhat more challenging. But since Hobbit already supports
all of the common Unix systems, I doubt that you will need to worry about that. If you do have a system which is not on the list, I will
help you with adding support for it.

When will 4.2 be officially released as a production version? 

Probably by the end of this week.

Since we have a working BB setup for now, I need to
decide if I should try to start migrating now or if I should wait some
time for Hobbit to develop more before I migrate from BB.

I don't think you have to wait. But it's for You to decide.


Regards,
Henrik

From: Jordan Mendler <user-d91c99e0e5c6@xymon.invalid>
Reply-To: user-ae9b8668bcde@xymon.invalid
To: user-ae9b8668bcde@xymon.invalid
Subject: RE: [hobbit] Hobbit newbie from BB: differences and what may Ilose 

I was thinking the same thing. To add some it to the FAQ or other parts
of the website.

On Wed, 2006-08-02 at 07:37 -0400, Camp, Neil D. (ManTech) CTR wrote:

This is an awesome write up. Maybe you should consider adding it to your
webpage?

-----Original Message-----
From: Henrik Stoerner [mailto:user-ce4a2c883f75@xymon.invalid]
Sent: Tuesday, August 01, 2006 5:13 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Hobbit newbie from BB: differences and what may I
lose from migrating?

Hi Jordan,

I'll try to answer your questions. Since I also develop Hobbit I am
probably slightly biased when it comes to the "is-this-more-difficult-
to-do-than-with-BB" type of questions, but I am sure others will
voice their opinions on that.

On Tue, Aug 01, 2006 at 12:36:29PM -0700, Jordan Mendler wrote:

First, after reading through whatever I could find on the website I am
still a little bit confused about configuration and setup. With BB,
you
install and configure each client and server on the local machine,
except for the universal bb-hosts. Is this the same on Hobbit, or does
Hobbit use a central configuration file that is modified only on the
server to configure clients? I am trying to figure out the difference
between installing, maintaining and configuring BB and Hobbit setups.

First, let me stress that Hobbit is fully compatible with your existing
BB clients. You can keep your current client setup and just switch to
Hobbit on the server side, and all of your clients will continue to
work as they do with BB as the server. So you can migrate the server
side first, and then migrate clients when you find that it is convenient
to do so - or you want to take advantage of some of the new stuff that
is in Hobbit.

The Hobbit client configuration is maintained on the Hobbit server.
Clients in Hobbit are designed to be *really* dumb; they just collect
data, and all of the configuration of what to monitor, what thresholds
to use for e.g. disk utilisation and so on is configured only on the
Hobbit server.

This is a major difference between Hobbit and BB. With BB you have
delegated the client administration to whoever manages each server.
Hobbit centralizes the monitoring configuration, so you will probably
have a group of people who take more control of the monitoring setup.

Hobbit looks alot more complex to setup, but once I get my feet wet is
it any harder than BB?

I think it is easier, once you get used to the Hobbit way of doing
things. But as I said, I am biased.

Second is performance. I know this list may be biased toward Hobbit,
but
is it actually faster? We have about 50-100 clients on BB and I did
not
notice any performance issues.

With that number of systems monitored, you probably will not see a huge
difference. BB works quite well for a small number of systems, but when
you move beyond a couple of hundred boxes the overhead of generating
webpages through shell scripts becomes very noticeable. On my setup,
the servers were simply choking on the disk I/O caused by BB saving
every status in a separate file, and from the huge number of small
cut-grep-awk-sed etc. commands that ran to generate webpages.

Hobbit looks like it is very complex, so does this mean it uses a lot
of resources on the client and server? What speed/ram server is
usually
the minimum recommended for a dedicated Hobbit server? Would something

like a dual Pentium II 266mhz have any performance issues as a server,

if it does nothing else? What about for clients? We have still have
some testing, stating and production servers left that are singe chip
Pentium III 700-850 mhz, and even a couple Pentium II's. Just need to
make sure all the resources used for things like graphs are taken from

the server and not each client.

The Hobbit server uses fewer ressources than the BB server. The main
ressource usage is memory; Hobbit keeps everything in memory except
the history logs and the RRD files used for graphs. That doesn't mean
a whole lot, though: Here's a ps listing of the Hobbit processes running

on my main monitoring system - it handles about 2500 hosts:

$ ps vax|cut -c1-100|egrep "PID|hobbit"
  PID TTY      STAT   TIME  MAJFL   TRS   DRS  RSS %MEM COMMAND
  732 ?        Ss     1:24      0   101  1802  696  0.0 hobbitlaunch
  735 ?        S    2434:37     1   162 31357 29784  2.8 hobbitd
 1470 ?        S     14:50      0    99  2332 1088  0.1 hobbitd_channel
--channel=stachg
 1471 ?        S     25:18      0   108  2515 1048  0.1 hobbitd_history
 1472 ?        S    964:26      0    99  2332 1264  0.1 hobbitd_channel
--channel=page
 1473 ?        S    1227:34     0   154  5661 3912  0.3 hobbitd_alert
 1474 ?        S    4090:05     0    99  2332 1264  0.1 hobbitd_channel
--channel=status
 1475 ?        D    2962:15     0   178  7381 4392  0.4 hobbitd_rrd
 1476 ?        S    259:55      0    99  2332 1208  0.1 hobbitd_channel
--channel=data
 1477 ?        S    494:13      0   178  5141 2128  0.2 hobbitd_rrd
 1478 ?        S    126:20      0    99  2844 1832  0.1 hobbitd_channel
--channel=client
 1480 ?        S    291:20      0   146  4485 2792  0.2 hobbitd_client
 5552 ?        S      0:00      0   669  2002 1352  0.1 sh -c vmstat 300
2 1>/usr/lib/hobbit/client/

As you can see, the biggest chunk of memory goes to the "hobbitd"
process which is the one that keeps all state information. It's
currently using some 31 MB of memory. (This box has 1 GB RAM).

A rough estimate of how much memory Hobbit needs would be the size of
your bbvar/logs/ directory, plus 30 MB.

As for CPU usage, your PII/266 should be adequate for 50-100 servers.
The box I'm running on is an old (7-8 years) Solaris server with a
900 MHz UltraSparc II processor. That's roughly comparable to a PII
running at 1.2 GHz. And it handles 25 times as many hosts as you are
aiming for.

Third is plugins. Are BB plugins compatible with Hobbit?

Yes.

Also how hard are plugins to write for Hobbit?

Plugins that run on the monitored client systems are as easy to write
as for BB, since it is basically the same thing.

Hobbit also allows you to write plugins for the Hobbit server, which
receive events from the Hobbit server daemon. This is used by the
core Hobbit tools - e.g. the hobbitd_rrd processes you see in the
ps-listing above are a plugin that handle updating of the RRD files
from the status- and data-messages that are sent to Hobbit. There
aren't any third-party plugins that use this yet (at least, I
don't know of any), but writing them is fairly simple since it
basically involves reading data from a pipe and processing it in
whatever way you want.

I don't know if these even exist for
bb, but I ultimately would like to integrate plugins that 1) monitor
legato tape backup,

Dont know about this.

2) run nmap to see what ports are open/can be seen from an external
machine,

The Hobbit client in version 4.2 (about to be released soon) reports
details about the network services running on a host. So you can check
for which ports are open/listening for connections, and trigger alerts
if any unwanted ports show up.

3) run 'lshw -html' to show a list of all the hardware on the system,

This would typically be a client-side test.

4) monitor uptime,

This is standard.

5) monitor OS and kernel versions (uname -a and head -n 1 /etc/issue),

This data is collected by the Hobbit client.

6) maybe some more router/network monitoring stuff and

Hobbit comes with built-in network service monitoring. There is also
an SNMP add-on which can be used for monitoring devices such as routers.

Fourth is relay. By this I mean monitoring systems on a private
subnetwork that are only accessible to the Hobbit server by going
through an intermediate server. Is this possible with Hobbit and is it
any more difficult to do than on BB?

Two ways of doing that. First, there is a proxy utility which is used
to forward Hobbit messages from one network to another. This is used if
your client systems on the private subnet are allowed to make outgoing
connections to the proxy, and the proxy can connect to the real Hobbit
server.

Second, Hobbit 4.2 includes a set of tools where it's the server that
contacts clients to pick up the data they have collected (i.e. the
traffic is initiated by the server, where the normal BB setup is for
the client to initiate the connection). Useful for DMZ style setups
where clients are not allowed to generate outbound connections.

Fifth is portability. BB is very portable, I can make a 'model' client
for say Red Hat and tar it and distribute it very easily to every
server
I have using only a few commands. Is Hobbit the same, or are there
client dependencies or other things that may make this more difficult.

The Hobbit client uses only the system libraries and standard utilities
found on your client systems. You will need at least one system where
you can compile the client binaries (that's similar to the BB
requirements), since a few of the client-side tools are written in C.

Once you have a client compiled for an OS, it is as portable as any
binary that is dynamically linked on your platform. I.e. you can
just copy it over as long as the same run-time libraries are available.

So far, we haven't managed to find any unix-like system that couldn't
run the Hobbit client. Including some rather odd ones. The current list
of client-side data collectors are

hobbitclient-aix.sh    hobbitclient-darwin.sh  hobbitclient-freebsd.sh
hobbitclient-hp-ux.sh  hobbitclient-irix.sh    hobbitclient-linux.sh
hobbitclient-netbsd.sh hobbitclient-openbsd.sh hobbitclient-osf1.sh
hobbitclient-sunos.sh

Sixth is development. How active is the development of Hobbit, how big
is the community, etc? How many people can attest to having fully
functional hobbit setups, how long has it been around and how often
are
new releases usually made?

Hobbit started back in late 2002 when it was called the "bbgen toolkit".
It was renamed to Hobbit in March 2005 when it had developed into a
complete replacement for BB. More details in the hobbit(7) man-page
available online at http://www.hswn.dk/hobbit/help/manpages/

It is actively being developed by me, but people on this list have
made contributions of code. Some have picked up special projects
like the Windows client and run that completely on their own.
I'd say Hobbit currently has a very active user community, and
the development community is slowly growing beyond just myself.

There are currently 433 subscribers to the Hobbit mailing list.
According to the Sourceforge download statistics, it is downloaded
about 1000 times per month.
http://sourceforge.net/project/stats/?group_id=128058&ugn=hobbitmon&type
=&mode=year

There was a thread on the mailing list back in May about who uses
Hobbit. The results were summarized here:
http://en.wikibooks.org/wiki/System_Monitoring_with_Hobbit/User_Guide#Wh
o_use_Hobbit_.3F

New releases have usually happened frequently - 2-4 times a year.
The current interval between the 4.1.2 release and version 4.2 is
unusually long - a whole year. I don't expect that to happen again.

Also I saw something this morning about a Windows client -- how
stable is that?

From what I hear it should be usable. But you can stick with the
current BBNT client until it reaches version 1.0.

How stable is the Solaris version?

Rock-solid.

Is there a client for Mac OSX?

Yes. It will run the Hobbit server also, if you want to.

Is Hobbit like BB in the sense that you can change paths to system
binaries like grep and sed to allow easy use on other UNIXes like OSX?

Adding a client for a new OS will require implementing both a
client-side script to collect whatever data is interesting for this
system, and implementing the data parsing on the Hobbit server-side.
So it is somewhat more challenging. But since Hobbit already supports
all of the common Unix systems, I doubt that you will need to worry
about that. If you do have a system which is not on the list, I will
help you with adding support for it.

When will 4.2 be officially released as a production version?

Probably by the end of this week.

Since we have a working BB setup for now, I need to
decide if I should try to start migrating now or if I should wait some
time for Hobbit to develop more before I migrate from BB.

I don't think you have to wait. But it's for You to decide.


Regards,
Henrik

On Tuesday 01 August 2006 05:44, Galen Johnson wrote:

Galen Johnson wrote:

Just wanted to give everyone a heads up on the new monitor site that
is being set up (theshire.sf.net)...Sourceforge accepted it late last
night ( around midnight EDT).   I want to work with Henrik a bit to
make sure that our visions converge on this.  I also need to set up
the categories (at a minimum) before turning everyone loose...I would
prefer there to be some structure in place beforehand.  Please be
patient...I really appreciate everyone's enthusiasm for this project
and I hope to have everything going in the next few days.  It's also
been a LONG time since I've done anything on SF and need to refresh my
memory about things (and become familiar with some of the new tools).

=G=

OK...we're getting to the point to where we need to consider the
categories...personally, I think deadcat has too many.

Buchan Milne wrote:

On Tuesday 01 August 2006 05:44, Galen Johnson wrote:
 

Galen Johnson wrote:
   

Just wanted to give everyone a heads up on the new monitor site that
is being set up (theshire.sf.net)...Sourceforge accepted it late last
night ( around midnight EDT).   I want to work with Henrik a bit to
make sure that our visions converge on this.  I also need to set up
the categories (at a minimum) before turning everyone loose...I would
prefer there to be some structure in place beforehand.  Please be
patient...I really appreciate everyone's enthusiasm for this project
and I hope to have everything going in the next few days.  It's also
been a LONG time since I've done anything on SF and need to refresh my
memory about things (and become familiar with some of the new tools).

=G=

OK...we're getting to the point to where we need to consider the
categories...personally, I think deadcat has too many.
   

My initial reaction to this is that I don't think a site with a collection of categories and random scripts uploaded to the categories is the best solution. I don't think the deadcat site should be the model. (If it isn't, and you've meant something else by "categories", ignore the rest).

Speaking from a software packaging point-of-view (I maintain ~ 60 packages in Mandriva, most in contrib - including hobbit - but a few in the main distribution, and also maintain roughly 50 packages that we use internally, some of them being the ones I maintain for Mandriva), it's not convenient to have to download, test, understand, debug each extension script (or plugin for a web application).

I would much prefer to work toward a realease strategy, where there may be a release of all the "supported" extensions (maybe one release for client extensions, and one for server extensions).

This would also hopefully lead to having a more consistent set of extensions, and instead of duplicating extensions when an author has not been contributing to their extension anymore, it would be moved to maintenance.

Then, it would also be practical to package the extensions, and hopefully all that would be required to use the extension would be to enable it (eg, each extension should be shipped with a .cfg file suitable for placement in a directory configured as an "include" directory in hobbitlaunch.cfg) and add the necessary tags to the bb-hosts file.

BTW, this is more or less what I have done with the 2 extension scripts I have written for hobbit (one server extensions for performance/replication monitoring of OpenLDAP, one client extension for checking updates from RHN for RH boxen).

Regards,
Buchan

On Thursday 03 August 2006 19:09, Galen Johnson wrote:

Buchan Milne wrote:

On Tuesday 01 August 2006 05:44, Galen Johnson wrote:

Galen Johnson wrote:

Just wanted to give everyone a heads up on the new monitor site that
is being set up (theshire.sf.net)...Sourceforge accepted it late last
night ( around midnight EDT).   I want to work with Henrik a bit to
make sure that our visions converge on this.  I also need to set up
the categories (at a minimum) before turning everyone loose...I would
prefer there to be some structure in place beforehand.  Please be
patient...I really appreciate everyone's enthusiasm for this project
and I hope to have everything going in the next few days.  It's also
been a LONG time since I've done anything on SF and need to refresh my
memory about things (and become familiar with some of the new tools).

=G=

OK...we're getting to the point to where we need to consider the
categories...personally, I think deadcat has too many.

My initial reaction to this is that I don't think a site with a collection
of categories and random scripts uploaded to the categories is the best
solution. I don't think the deadcat site should be the model. (If it
isn't, and you've meant something else by "categories", ignore the rest).

Speaking from a software packaging point-of-view (I maintain ~ 60 packages
in Mandriva, most in contrib - including hobbit - but a few in the main
distribution, and also maintain roughly 50 packages that we use
internally, some of them being the ones I maintain for Mandriva), it's
not convenient to have to download, test, understand, debug each
extension script (or plugin for a web application).

I would much prefer to work toward a realease strategy, where there may be
a release of all the "supported" extensions (maybe one release for client
extensions, and one for server extensions).

This would also hopefully lead to having a more consistent set of
extensions, and instead of duplicating extensions when an author has not
been contributing to their extension anymore, it would be moved to
maintenance.

Then, it would also be practical to package the extensions, and hopefully
all that would be required to use the extension would be to enable it
(eg, each extension should be shipped with a .cfg file suitable for
placement in a directory configured as an "include" directory in
hobbitlaunch.cfg) and add the necessary tags to the bb-hosts file.

BTW, this is more or less what I have done with the 2 extension scripts I
have written for hobbit (one server extensions for
performance/replication monitoring of OpenLDAP, one client extension for
checking updates from RHN for RH boxen).

Regards,
Buchan

Interesting idea...funny you should bring this up as I was actually
toying with the possibility of creating something that would allow you
to select multiple monitors and bundle them together into a single
download.   Regardless of the method used, there still needs to be
something that tells people what they do, how they are to be set up, a
way to upload them and a search function for people to find a monitor
they are looking for (even if it's bundled with all the others, it may
not be named what is expected).

I, personally, like the way you're doing it.  It makes a lot of sense
and I can see how it could be used with a package manager to only
install the monitors you want to deploy (maybe even a spec file that can
be modified by those admins who don't want to clutter their install with
a bunch of unused monitors).

As a sys admin, I tend to only want to 
install what I need (I don't select the "Install Everything" option,
it's anathema to my nature.

Of course, working towards a release strategy means only a select few
would be allowed to upload or commit a monitoring script.  This would
have the benefit of ensuring that monitors meet a certain standard and
that duplicate monitors aren't commited but there's the administrative
overhead of ensuring that every new release is tested with the monitors
that are available to ensure compatibility (again, less of a community
effort and more of an individual/committee effort).  I'd like to ensure
that the monitors released meet a certain criteria...maybe have an
"officially supported" area and a "I feel lucky" area.

I'm still hoping someone will pony up a full tutorial...if this method
ends up being the accepted method, we'll definitely need the
tutorial/guideline available.

Buchan Milne wrote:

On Thursday 03 August 2006 19:09, Galen Johnson wrote:
 

Buchan Milne wrote:
   

On Tuesday 01 August 2006 05:44, Galen Johnson wrote:
     

Galen Johnson wrote:
       

Just wanted to give everyone a heads up on the new monitor site that
is being set up (theshire.sf.net)...Sourceforge accepted it late last
night ( around midnight EDT).   I want to work with Henrik a bit to
make sure that our visions converge on this.  I also need to set up
the categories (at a minimum) before turning everyone loose...I would
prefer there to be some structure in place beforehand.  Please be
patient...I really appreciate everyone's enthusiasm for this project
and I hope to have everything going in the next few days.  It's also
been a LONG time since I've done anything on SF and need to refresh my
memory about things (and become familiar with some of the new tools).

=G=

OK...we're getting to the point to where we need to consider the
categories...personally, I think deadcat has too many.
       

My initial reaction to this is that I don't think a site with a collection
of categories and random scripts uploaded to the categories is the best
solution. I don't think the deadcat site should be the model. (If it
isn't, and you've meant something else by "categories", ignore the rest).

Speaking from a software packaging point-of-view (I maintain ~ 60 packages
in Mandriva, most in contrib - including hobbit - but a few in the main
distribution, and also maintain roughly 50 packages that we use
internally, some of them being the ones I maintain for Mandriva), it's
not convenient to have to download, test, understand, debug each
extension script (or plugin for a web application).

I would much prefer to work toward a realease strategy, where there may be
a release of all the "supported" extensions (maybe one release for client
extensions, and one for server extensions).

This would also hopefully lead to having a more consistent set of
extensions, and instead of duplicating extensions when an author has not
been contributing to their extension anymore, it would be moved to
maintenance.

Then, it would also be practical to package the extensions, and hopefully
all that would be required to use the extension would be to enable it
(eg, each extension should be shipped with a .cfg file suitable for
placement in a directory configured as an "include" directory in
hobbitlaunch.cfg) and add the necessary tags to the bb-hosts file.

BTW, this is more or less what I have done with the 2 extension scripts I
have written for hobbit (one server extensions for
performance/replication monitoring of OpenLDAP, one client extension for
checking updates from RHN for RH boxen).

Regards,
Buchan
     

Interesting idea...funny you should bring this up as I was actually
toying with the possibility of creating something that would allow you
to select multiple monitors and bundle them together into a single
download.   Regardless of the method used, there still needs to be
something that tells people what they do, how they are to be set up, a
way to upload them and a search function for people to find a monitor
they are looking for (even if it's bundled with all the others, it may
not be named what is expected).
   

Indeed. I agree there needs to be an easy way to discover extensions. However, 
that should not dictate the primary distribution means.

 

I, personally, like the way you're doing it.  It makes a lot of sense
and I can see how it could be used with a package manager to only
install the monitors you want to deploy (maybe even a spec file that can
be modified by those admins who don't want to clutter their install with
a bunch of unused monitors).
   

Multiple subpackages could be created from one spec file, so distributing 
the "source" and installing the extensions don't necessarily need to be 
inter-dependant.

 

As a sys admin, I tend to only want to 
install what I need (I don't select the "Install Everything" option,
it's anathema to my nature.
   

We have the same mentality here, which is why we have some tools to specify 
exactly which packages get deployed on which machines, depending on their 
role, their hardware type, etc etc.

 

Of course, working towards a release strategy means only a select few
would be allowed to upload or commit a monitoring script.  This would
have the benefit of ensuring that monitors meet a certain standard and
that duplicate monitors aren't commited but there's the administrative
overhead of ensuring that every new release is tested with the monitors
that are available to ensure compatibility (again, less of a community
effort and more of an individual/committee effort).  I'd like to ensure
that the monitors released meet a certain criteria...maybe have an
"officially supported" area and a "I feel lucky" area.
   

Makes sense.

Note also that in some projects, that while only certain users may be able to 
commit, other contributors are often welcomed, and their contributions 
handled by contributors who have commit access, until they are trusted 
enough. Community shouldn't be lost in the effort to provide a consistent set 
of extensions, it should be leveraged but adhere to standards/guidelines (so 
as to not surprise the admin by doing something differently to other 
extensions for no reason).

 

I'm still hoping someone will pony up a full tutorial...if this method
ends up being the accepted method, we'll definitely need the
tutorial/guideline available.
   

I would be happy to contribute (at least in draft form) based on what I have 
implemented myself so far, subject to the constraints of real work ...