Thread: [Mon-devel] Re: Best way to contribute
Brought to you by:
trockij
From: David N. <vit...@cm...> - 2004-06-29 13:46:58
|
--On Tuesday, June 29, 2004 5:26 AM -0700 Jim Trocki <tr...@tr...> wrote: > On Tue, 29 Jun 2004, Peter Wirdemo (MO/EMW) wrote: > >> Hello all! >> >> What is the best way to contribute, now when mon is moving over to >> sourceforge. My intreset in contributing is most in monitors, not so >> much in mon itself..... > > i've made the "mon...@li..." mailing list for this > purpose: > > http://lists.sourceforge.net/mailman/listinfo/mon-devel > > (it'll take a little bit for it to show up) > Oh good, you did it. Thanks. I assume you've subscribed, so I won't cc you on this response. :) To address the original question, I think we should take advantage of the sourceforge CVS features and move the contrib stuff into sourceforge. Then we can grant individuals the ability to commit new versions there. Thoughts? -David David Nolan <*> vit...@cm... curses: May you be forced to grep the termcap of an unclean yacc while a herd of rogue emacs fsck your troff and vgrind your pathalias! |
From: Jim T. <tr...@tr...> - 2004-06-29 15:22:07
|
> To address the original question, I think we should take advantage of the > sourceforge CVS features and move the contrib stuff into sourceforge. Then > we can grant individuals the ability to commit new versions there. > Thoughts? > > -David yeah, making a "contrib" module in cvs might be ok for the sake of it, but some of the more substantial items should be moved into the main mon distribution. i've already done this for snmpvar.monitor, and mon.cgi should also go in there. i don't recall much activity from the people who've contributed the rest of them, however. |
From: David N. <vit...@cm...> - 2004-06-29 15:38:09
|
--On Tuesday, June 29, 2004 8:21 AM -0700 Jim Trocki <tr...@tr...> wrote: >> To address the original question, I think we should take advantage of the >> sourceforge CVS features and move the contrib stuff into sourceforge. >> Then we can grant individuals the ability to commit new versions there. >> Thoughts? >> >> -David > > yeah, making a "contrib" module in cvs might be ok for the sake of it, > but some of the more substantial items should be moved into the main mon > distribution. i've already done this for snmpvar.monitor, and mon.cgi > should also go in there. i don't recall much activity from the people > who've contributed the rest of them, however. > > We could also grant additional people cvs access to just the mon.d directory. At some point soon I'll go through my set of monitor scripts and figure out which ones are interesting enough to add to CVS. The only issue is I'll have to figure out is what to do about ripping out some of our local code. We've updated every monitor script that has some piece of 'secret' configuration data (passwords, snmp strings, etc) to use a common config file to get that data. That way we don't have to put the passwords into the config file (i.e. in the database, and more importantly visible through the web interface) or the monitor script itself (which would put the passwords into CVS). While I think those changes are useful, I'm not sure they're interesting to anyone else. -David David Nolan <*> vit...@cm... curses: May you be forced to grep the termcap of an unclean yacc while a herd of rogue emacs fsck your troff and vgrind your pathalias! |
From: Tim K. <tkp...@ti...> - 2004-07-01 14:00:13
|
>The only issue is I'll have to figure out is what to do about >ripping out some of our local code. We've updated every monitor >script that has some piece of 'secret' configuration data >(passwords, snmp strings, etc) to use a common config file to get >that data. That way we don't have to put the passwords into the >config file (i.e. in the database, and more importantly visible >through the web interface) or the monitor script itself (which would >put the passwords into CVS). > >While I think those changes are useful, I'm not sure they're >interesting to anyone else. > >-David David, I don't know about any other site-specific mods you may have made, but the one you describe above certainly sounds to be of general interest. Tim |
From: David N. <vit...@cm...> - 2004-07-01 15:44:02
|
--On Thursday, July 01, 2004 8:59 AM -0500 Tim Klein <tkp...@ti...> wrote: > > I don't know about any other site-specific mods you may have made, > but the one you describe above certainly sounds to be of general > interest. Ok. In the interest of figuring out our solution is reasonable for other people I'll give some more details. The config file contains arbitrary variables, that can either apply to specific hostgroups, services, hostgroup & service pairs, or be default values. In certain cases we even can provide per-machine settings. Examples of settings we use this for are: snmp community strings, database users & passwords, username & password for testing kerberos servers, paths to keytab files, etc. Here's an example of the way it works. The mon script has a block of code like this: my %communities; my $group=$ENV{MON_GROUP}; my $service=$ENV{MON_SERVICE}; my $cf; $community ||= $opt{'community'}; if ($cf = new IO::File "</home/mon/etc/monitor-auth.cf") { while (<$cf>) { chomp; if (/^(\S+):readcommunity\s*=\s*(\S+)$/) { $communities{$1}=$2; } } $community ||= $communities{"$group:$service"}; $community ||= $communities{"$group:*"}; $community ||= $communities{"*:$service"}; $community ||= $communities{"*:*"}; } $community ||= 'public'; Then monitor-auth.cf contains entries like this: hostgroup-x:*:readcommunity=foobar hostgroup-y:*:readcommunity=qux *:service-x:readcommunity=baz hostgroup-y:service-x:readcommunity=abc *:*:readcommunity=asdf -David David Nolan <*> vit...@cm... curses: May you be forced to grep the termcap of an unclean yacc while a herd of rogue emacs fsck your troff and vgrind your pathalias! |