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?

Actually, I find Hobbit easier to setup than BB. It is especially easier to maintain and manage, since all configuration of hosts is maintained on just the server. No need to update the individual clients when changing monitoring aspects. As far as adding hosts, you add hosts to the bb-hosts file on Hobbit with almost identical syntax as BB. I think you could even take the bb-hosts file from BB, put it as-in in Hobbit, and it will just work. I haven't done this, though, and have preferred to just create a new bb-hosts.

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.

At home, I have the Hobbit server running on a dual P2-350 Mhz without any issues. At work, we have now about 150 or so clients being monitored on a high-end P3, which also serves several other functions. Hobbit runs very well on this, and I would say your dual P2 266 won't have any issues. Since Hobbit is written as a compiled C program, its performance is very good. Think of Hobbit as BB, only easier to maintain, more features, and native-compiled performance.

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.

I believe most of the existing BB plugins (such as those available from deadcat) will work "out of the box" with Hobbit. In fact, Hobbit is essentially based on BB's functionality and configuration. As with question 1 above, I would say that Hobbit is easier to write plugins / external scripts than with BB.

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?

Hobbit uses port 1984 just like BB, and essentially the same protocol. If you can set up an SSH tunnel or other relay with BB, it will work with Hobbit.

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.

It will work the same. In fact, we have done just that.

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.

Hobbit development is very active. There are nightly snapshots, and it is the most developed piece of software I've been using. Most of the beta versions are more stable than a lot of production software I've used.

On 8/1/06, Henrik Stoerner <henrik at hswn.dk> 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.

From personal experience I can say that this works as advertised :) I've got a network of some 30-40 hosts that started with BB and I've been slowly migrating to Hobbit. The only "problem" is that the hobbit client is more fully featured than the BB one, so I'm under pressure to complete the migration sooner than planned :)

...

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.

I've been using it since 0.5. Release 0.6 has been pretty solid, 0.7 has a better feature set, but the developer has reported a memory leak problem (though the only box I've been running it on had a hard disk failure, so I can't say). The latest (0.8) is looking good.

I've been running 0.6 on some production servers to replace the BBNT client without any problems.

...

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.

Well, my experience is that there's no pain in migrating the server to Hobbit. Once you've done that it's easy to upgrade each client at the time that's right for you.

Of course, YMMV :-)

-- Please keep list traffic on the list.

Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche

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

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=&mo...

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_us...

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

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

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=

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

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.

=G=

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=

To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

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 agree...just making sure that we have a way to surface the info for users.

...

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.

D'oh...there's a duh moment...how many rpms have I built that do just that...

...

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

Absolutely, the intention was never to exclude the community as a whole...

...

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

Thanks...I have exactly the same problem :-).

=G=