mon-devel Mailing List for mon (Page 7)
Brought to you by:
trockij
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(13) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
(27) |
Mar
|
Apr
(9) |
May
(11) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(15) |
2006 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
(14) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
(4) |
Dec
(8) |
2008 |
Jan
(6) |
Feb
(4) |
Mar
(7) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2009 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2010 |
Jan
(11) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(7) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
2013 |
Jan
|
Feb
(3) |
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: David N. <vit...@cm...> - 2005-02-17 20:53:15
|
--On Thursday, February 17, 2005 3:30 PM -0500 Ed Ravin <er...@pa...> wrote: > And the "ACK" command is still misbehaving, but I can see the problem > is limited to my old mon.cgi - apparently the 'ack' field, instead of just > being a 1 if the watch was ack'd, is now the ctime of the ack. > Oh yeah, I forgot that had changed. That was done with the intent of eventually displaying the timestamp of the ack, and having ack's timeout after configurable periods of time. > So that leaves me with the warning in Mon::Client. I've figured that out > too: I only get it when the service description is null AND the Perl > program calling Mon::Client uses the "-w" option. This is a bug. Here > is a possible fix: Ah, the wonder and curse of -w. It finds certain classes of bugs, and actually helps you avoid exercising certain memory leaks in perl, but it also whines about many things. I'll commit that fix. -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: Ed R. <er...@pa...> - 2005-02-17 20:30:27
|
On Thu, Feb 17, 2005 at 02:14:11PM -0500, David Nolan wrote: > > > --On Thursday, February 17, 2005 1:35 PM -0500 Ed Ravin <er...@pa...> > wrote: > > > webserver: connection20refused > > > >Also, the failure details are listed in mon.cgi as "0a" when there are no > >details rather than the usual "<Not Specified>". > > > >Furthermore - ack doesn't work in mon.cgi. The CGI responds that the > >service was ACK'd successfully, but further inspection shows that it > >wasn't. > > > >The display problems go away when I stop using mod_perl (argh!) for > >mon.cgi. But ACK is still broken. > > > > > This sounds like you've got two versions of Mon::Client installed, the old > one and the new one. The newer code escapes space characters, and it > sounds like your client isn't unescaping them. That's exactly what was happening. I've removed the old version of Mon::Client and restarted Apache. I don't have the "20" problem anymore, but I'm still getting the warnings about un_esc_str() in Mon::Client. And the "ACK" command is still misbehaving, but I can see the problem is limited to my old mon.cgi - apparently the 'ack' field, instead of just being a 1 if the watch was ack'd, is now the ctime of the ack. So that leaves me with the warning in Mon::Client. I've figured that out too: I only get it when the service description is null AND the Perl program calling Mon::Client uses the "-w" option. This is a bug. Here is a possible fix: --- /usr/local/lib/site_perl/Mon/Client.pm 2004-06-18 10:25:16.000000000 -0400 +++ /new-version-of/Client.pm 2005-02-17 15:27:29.000000000 -0500 @@ -1673,6 +1673,8 @@ sub _un_esc_str { my $str = shift; + return "" unless defined($str); + $str =~ s{\\([0-9a-f]{2})}{chr(hex($1))}eg; $str; |
From: David N. <vit...@cm...> - 2005-02-17 19:14:19
|
--On Thursday, February 17, 2005 1:35 PM -0500 Ed Ravin <er...@pa...> wrote: > webserver: connection20refused > > Also, the failure details are listed in mon.cgi as "0a" when there are no > details rather than the usual "<Not Specified>". > > Furthermore - ack doesn't work in mon.cgi. The CGI responds that the > service was ACK'd successfully, but further inspection shows that it > wasn't. > > The display problems go away when I stop using mod_perl (argh!) for > mon.cgi. But ACK is still broken. > This sounds like you've got two versions of Mon::Client installed, the old one and the new one. The newer code escapes space characters, and it sounds like your client isn't unescaping them. Maybe mod_perl is finding a different version, or has a version compiled in memory all ready. (Have you restarted apache?) -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: Ed R. <er...@pa...> - 2005-02-17 18:35:36
|
I'm having some weird problems with my Mon upgrade attempt. I'm using Mon 1.1.0pre1, Mon::Client-1.000, an older mon-cgi (1.5?), and perl5.005, When I start up, there are a lot of error messages in my test environment. All of the error messages displayed by mon.cgi in the browser interface have their white space warped into "20", like this: webserver: connection20refused Also, the failure details are listed in mon.cgi as "0a" when there are no details rather than the usual "<Not Specified>". Furthermore - ack doesn't work in mon.cgi. The CGI responds that the service was ACK'd successfully, but further inspection shows that it wasn't. The display problems go away when I stop using mod_perl (argh!) for mon.cgi. But ACK is still broken. I'll upgrade to the current mon.cgi soon and see how it compares. Meanwhile, when I run one of my custom client apps, I get warning messages when running certain Mon::Client functions. Here's a walkback of one of them: Use of uninitialized value at /usr/local/lib/site_perl/Mon/Client.pm line 1676, <GEN0> chunk 162. Mon::Client::_un_esc_str() called at /usr/local/lib/site_perl/Mon/Client.pm line 596 Mon::Client::list_descriptions('Mon::Client=HASH(0x32d3d4)') called at /usr/local/mon/monocle line 192 When I try my client again under Perl 5.6.1, I get this additional message Use of uninitialized value in substitution (s///) at /usr/local/lib/site_perl/Mon/Client.pm line 1676, <GEN0> line 163. The offending code in Mon::Client is: 1673 sub _un_esc_str { 1674 my $str = shift; 1675 1676 $str =~ s{\\([0-9a-f]{2})}{chr(hex($1))}eg; 1677 1678 $str; I suspect these things are related (as the 20 stuff in my CGI output is clearly an escaping problem), but I'm at a loss to say how. |
From: Ed R. <er...@pa...> - 2005-02-17 15:41:52
|
On Thu, Feb 17, 2005 at 09:09:13AM -0500, David Nolan wrote: > >This is a feature I added to allow the user to define a different path > >for the M4 processor. I'm probably the only person who needs this, so > >it doesn't need to go into 1.0: > > > >- if (!open (CFG, "m4 $CF |")); > >+ if (!open (CFG, > >+ (exists($ENV{'MON_M4'}) ? $ENV{'MON_M4'} : "m4") > >. " $CF |") ); > > > > > > I like Peter's solution to this better, especially since Mon is not > currently directly using any other environment variables that are passed in > to it. I like Peter's solution better too - that was what I originally wanted to do, until I realized that... > ... it changes the semantics of -M, in that it now requires the m4 > path argument. Getopt::Std doesn't provide an option with optional > argument, as far as I can tell. And we also lose the abilility to test for command-line option errors (zero return status from getopt() ). Not that we're using it now, but it would be nice to have Mon refuse to run when given bad options. Conversion to Getopt::Long sounds much more sensible. |
From: David N. <vit...@cm...> - 2005-02-17 15:35:31
|
--On Thursday, February 17, 2005 3:47 PM +0100 "Peter Wirdemo (MO/EMW)" <pet...@er...> wrote: > If you dont use -M, but the file =~ /\.m4$/ "m4" is executed > If you use -M, "m4" is executed > If you use -M/usr/local/bin/nroff, "/usr/local/bin/nroff" is executed > > So -M does NOT require path... > The problem is that getopts will eat the next component of the command line, even if it should have been the next switch. i.e. 'mon -M -f' would result in $opt{M} == '-f'. I tested it before I decided I didn't like doing it that way: --- test.pl #!/usr/bin/perl use Getopt::Std; use Data::Dumper; getopts( "ab:c", \%opts,); print Data::Dumper->Dump([$opts{a}, $opts{b}, $opts{c}], [qw/a b c/]); --- % ./test.pl -a -b -c $a = 1; $b = '-c'; $c = undef; But with Getopt::Long you can do this: --- test2.pl #!/usr/bin/perl use Getopt::Long; use Data::Dumper; GetOptions( \%opts, "a", "b:s", "c"); print Data::Dumper->Dump([$opts{a}, $opts{b}, $opts{c}], [qw/a b c/]); --- % ./test2.pl -a -b -c $a = 1; $b = ''; $c = 1; Besides... I like the result of replacing this: getopts ("fhMSvda:A:b:B:c:D:i:l:L:m:O:o:p:P:r:s:t:", \%opt); with this: GetOptions(\%opt, qw/ A|authfile=s B|cfbasedir=s D|statedir=s L|logdir=s M|m4:s O|syslogfacility=s P|pidfile=s S|stopped a|alertdir=s b|basedir=s c|configfile=s d|debug f|fork h|help i|sleep=i k|maxkeep=i l|loadstate:s m|maxprocs=i p|port=i r|randstart=s s|scriptdir=s t|trapport=i v|version /); The call is much easier to understand. -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: Peter W. (MO/EMW) <pet...@er...> - 2005-02-17 14:48:44
|
If you dont use -M, but the file =~ /\.m4$/ "m4" is executed If you use -M, "m4" is executed If you use -M/usr/local/bin/nroff, "/usr/local/bin/nroff" is executed So -M does NOT require path... if ( exists($opt{"M"}) || $CF =~ /\.m4$/) { my($m4) = $opt{"M"} || "m4"; return "could not open m4 pipe of cf file: $CF: $!" if (!open (CFG, "$m4 $CF |")); } else { return "could not open cf file: $CF: $!" if (!open (CFG, $CF)); } /Peter > -----Original Message----- > From: mon...@li... > [mailto:mon...@li...]On Behalf Of David Nolan > Sent: den 17 februari 2005 15:09 > To: mon...@li... > Subject: Re: [Mon-devel] Today's Mon 1.1 nits > > > > > --On Wednesday, February 16, 2005 7:41 PM -0500 Ed Ravin > <er...@pa...> > wrote: > > > This is a problem in Mon 1.0 also - that extra backslash > shouldn't be > > there: > > > > -if ($^O eq "linux" || $^O =~ /^(open|free|net)bsd\$/ || > $^O eq "aix") > > +if ($^O eq "linux" || $^O =~ /^(open|free|net)bsd$/ || > $^O eq "aix") > > > > Without this fix syslog goes to UDP (and therefore gets > lost) on the BSDs. > > > > I'll commit that fix shortly... > > > > ------------------------ > > > > This is a feature I added to allow the user to define a > different path > > for the M4 processor. I'm probably the only person who > needs this, so > > it doesn't need to go into 1.0: > > > > - if (!open (CFG, "m4 $CF |")); > > + if (!open (CFG, > > + (exists($ENV{'MON_M4'}) ? > $ENV{'MON_M4'} : "m4") > > . " $CF |") ); > > > > > > I like Peter's solution to this better, especially since Mon is not > currently directly using any other environment variables that > are passed in > to it. But it changes the semantics of -M, in that it now > requires the m4 > path argument. Getopt::Std doesn't provide an option with optional > argument, as far as I can tell. If I convert mon to using > Getopt::Long > then we can make the argument to -M optional. I'm doing that > now... Ooh, > and I found a couple errors in the process. -k was > documented but not > processed, and -O and -o were processed but not used. I've > add -k, fixed > -O, and purged -o. > > Committing now... > > -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! > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Mon-devel mailing list > Mon...@li... > https://lists.sourceforge.net/lists/listinfo/mon-devel > |
From: David N. <vit...@cm...> - 2005-02-17 14:07:51
|
--On Wednesday, February 16, 2005 7:41 PM -0500 Ed Ravin <er...@pa...> wrote: > This is a problem in Mon 1.0 also - that extra backslash shouldn't be > there: > > -if ($^O eq "linux" || $^O =~ /^(open|free|net)bsd\$/ || $^O eq "aix") > +if ($^O eq "linux" || $^O =~ /^(open|free|net)bsd$/ || $^O eq "aix") > > Without this fix syslog goes to UDP (and therefore gets lost) on the BSDs. > I'll commit that fix shortly... > ------------------------ > > This is a feature I added to allow the user to define a different path > for the M4 processor. I'm probably the only person who needs this, so > it doesn't need to go into 1.0: > > - if (!open (CFG, "m4 $CF |")); > + if (!open (CFG, > + (exists($ENV{'MON_M4'}) ? $ENV{'MON_M4'} : "m4") > . " $CF |") ); > > I like Peter's solution to this better, especially since Mon is not currently directly using any other environment variables that are passed in to it. But it changes the semantics of -M, in that it now requires the m4 path argument. Getopt::Std doesn't provide an option with optional argument, as far as I can tell. If I convert mon to using Getopt::Long then we can make the argument to -M optional. I'm doing that now... Ooh, and I found a couple errors in the process. -k was documented but not processed, and -O and -o were processed but not used. I've add -k, fixed -O, and purged -o. Committing now... -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: Peter W. (MO/EMW) <pet...@er...> - 2005-02-17 10:45:14
|
Would it not be nice to use the -M options to specify which preprocessor to use... # diff mon mon.new 201c201 < getopts ("fhlMSvda:A:b:B:c:D:i:L:m:O:o:p:P:r:s:t:", \%opt); --- > getopts ("fhlM:Svda:A:b:B:c:D:i:L:m:O:o:p:P:r:s:t:", \%opt); 818c818 < if ($opt{"M"} || $CF =~ /\.m4$/) --- > if ( exists($opt{"M"}) || $CF =~ /\.m4$/) 819a820 > my($m4) = $opt{"M"} || "m4"; 821c822 < if (!open (CFG, "m4 $CF |")); --- > if (!open (CFG, "$m4 $CF |")); /Peter (sorry about the duplicate Ed) > -----Original Message----- > From: mon...@li... > [mailto:mon...@li...] > Sent: den 17 februari 2005 01:41 > To: mon...@li... > Subject: [Mon-devel] Today's Mon 1.1 nits > > > This is a problem in Mon 1.0 also - that extra backslash > shouldn't be there: > > -if ($^O eq "linux" || $^O =~ /^(open|free|net)bsd\$/ || > $^O eq "aix") > +if ($^O eq "linux" || $^O =~ /^(open|free|net)bsd$/ || $^O > eq "aix") > > Without this fix syslog goes to UDP (and therefore gets lost) > on the BSDs. > > ------------------------ > > This is a feature I added to allow the user to define a different path > for the M4 processor. I'm probably the only person who needs this, so > it doesn't need to go into 1.0: > > - if (!open (CFG, "m4 $CF |")); > + if (!open (CFG, > + (exists($ENV{'MON_M4'}) ? > $ENV{'MON_M4'} : "m4") . " > $CF |") ); > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Mon-devel mailing list > Mon...@li... > https://lists.sourceforge.net/lists/listinfo/mon-devel > |
From: Ed R. <er...@pa...> - 2005-02-17 00:41:07
|
This is a problem in Mon 1.0 also - that extra backslash shouldn't be there: -if ($^O eq "linux" || $^O =~ /^(open|free|net)bsd\$/ || $^O eq "aix") +if ($^O eq "linux" || $^O =~ /^(open|free|net)bsd$/ || $^O eq "aix") Without this fix syslog goes to UDP (and therefore gets lost) on the BSDs. ------------------------ This is a feature I added to allow the user to define a different path for the M4 processor. I'm probably the only person who needs this, so it doesn't need to go into 1.0: - if (!open (CFG, "m4 $CF |")); + if (!open (CFG, + (exists($ENV{'MON_M4'}) ? $ENV{'MON_M4'} : "m4") . " $CF |") ); |
From: Jim T. <tr...@tr...> - 2005-02-16 23:55:55
|
On Wed, 16 Feb 2005, David Nolan wrote: > We should put together a tarball of 1.1.0pre1 and update both sites. Jim, > can you take care of that? will do. > I think the answer is nobody. I think moving contrib into sourceforge is a > fine idea. Are you volunteering to help maintain it? yes, i guess sourceforge will let me make another module for the contrib stuff, and i can add ed and you to the access list. there are some modules i'd like to put there, too. this brings up the issue of what modules go into the "contrib" and what go into the mon distribution. i've made an attempt at incorporating the more popular and useful ones from the contrib into 1.0, but there are some more which probably should get in there. i've been deciding which ones make it largely if it seems useful to people, and if they're stable or at least actively maintained. i'm sure there are some which i've missed. at this point there are about 30 or so total contrib monitors and alerts. i'm ok with one or a few to maintain the "contrib" area, and then eventually incorporating the better ones into the main mon tarball, unless someone comes up with a better idea. |
From: David N. <vit...@cm...> - 2005-02-16 23:22:08
|
--On Wednesday, February 16, 2005 6:03 PM -0500 Ed Ravin <er...@pa...> wrote: > On Wed, Feb 16, 2005 at 05:56:14PM -0500, David Nolan wrote: > >> > * What do you think of starting a new tree with the contrib stuff in >> > the main CVS? >> > >> >> I think the answer is nobody. I think moving contrib into sourceforge >> is a fine idea. Are you volunteering to help maintain it? > > I thought I heard a noise. Sure, at least until I get all my patches in > :-) My Sourceforge ID is "eravin". Jim will need to create the tree and grant you access, assuming he doesn't have any objections. I'll even add some of my local monitors to the contrib tree once its all in CVS. -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: Ed R. <er...@pa...> - 2005-02-16 23:03:51
|
On Wed, Feb 16, 2005 at 05:56:14PM -0500, David Nolan wrote: > >* What do you think of starting a new tree with the contrib stuff in the > >main CVS? > > > > I think the answer is nobody. I think moving contrib into sourceforge is a > fine idea. Are you volunteering to help maintain it? I thought I heard a noise. Sure, at least until I get all my patches in :-) My Sourceforge ID is "eravin". |
From: David N. <vit...@cm...> - 2005-02-16 22:55:31
|
--On Wednesday, February 16, 2005 5:40 PM -0500 Ed Ravin <er...@pa...> wrote: > Just some random thoughts that occured to me while I was working on > upgrading my site to 1.1.0pre1: > > * I noticed that Sourceforge shows 1.0pre4 as the latest release, but > kernel.org has 1.0pre5. > We should put together a tarball of 1.1.0pre1 and update both sites. Jim, can you take care of that? > * who's maintaining the contrib archive these days? I thought it > was Andrew Ryan, but he seems to have Vanished Mysteriously. > > * What do you think of starting a new tree with the contrib stuff in the > main CVS? > I think the answer is nobody. I think moving contrib into sourceforge is a fine idea. Are you volunteering to help maintain it? -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: Ed R. <er...@pa...> - 2005-02-16 22:40:38
|
Just some random thoughts that occured to me while I was working on upgrading my site to 1.1.0pre1: * I noticed that Sourceforge shows 1.0pre4 as the latest release, but kernel.org has 1.0pre5. * who's maintaining the contrib archive these days? I thought it was Andrew Ryan, but he seems to have Vanished Mysteriously. * What do you think of starting a new tree with the contrib stuff in the main CVS? -- Ed |
From: Jim T. <tr...@tr...> - 2005-02-15 16:01:58
|
On Tue, 15 Feb 2005, David Nolan wrote: > > > --On Monday, February 14, 2005 5:54 PM -0500 Jim Trocki > <tr...@tr...> wrote: > > >> sorry, you're correct, no objection to that tag. one thing i need to do >> is port >> a change i did in a recent -devel which makes a unified routine for >> handling >> both failures and traps (called "process_event"), and significantly >> simplifying >> the handling of both by removing lots of redundant code. it also made me >> feel better :) >> >> > > > I already imported those changes into the head, they're in the code that I > tagged as 1.1.0pre1. hot damn! |
From: David N. <vit...@cm...> - 2005-02-15 15:57:00
|
--On Monday, February 14, 2005 5:54 PM -0500 Jim Trocki <tr...@tr...> wrote: > sorry, you're correct, no objection to that tag. one thing i need to do > is port > a change i did in a recent -devel which makes a unified routine for > handling > both failures and traps (called "process_event"), and significantly > simplifying > the handling of both by removing lots of redundant code. it also made me > feel better :) > > I already imported those changes into the head, they're in the code that I tagged as 1.1.0pre1. -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...> - 2005-02-14 23:25:26
|
On Mon, 14 Feb 2005, David Nolan wrote: > > > --On Friday, February 11, 2005 8:52 PM -0500 Ed Ravin <er...@pa...> > wrote: > > >> Is there any chance the anti-gas fork code will be brought into 1.0? >> If not, is the code currently in the CVS head usable? Any reason >> why 1.1 isn't tagged yet or 1.0 not released yet? >> >> -- Ed > > Ed, > > About a week ago I asked on the list, and in email to Jim, if he had any > objections to my tagging the HEAD as 1.1.0pre1. I got no response, so I > guess I'll assume he has no objections. I've tagged the current CVS head as > mon-1-1-0pre1. I did not tag mon-client, as there are no changes from the > 1.0 version. sorry, you're correct, no objection to that tag. one thing i need to do is port a change i did in a recent -devel which makes a unified routine for handling both failures and traps (called "process_event"), and significantly simplifying the handling of both by removing lots of redundant code. it also made me feel better :) |
From: Jim T. <tr...@tr...> - 2005-02-14 23:13:10
|
On Mon, 14 Feb 2005, Jim Trocki wrote: > in requiring another module for it. if you want i can give you some of > my own code from another tool i have which does this junk. see attached |
From: Jim T. <tr...@tr...> - 2005-02-14 23:12:09
|
On Mon, 14 Feb 2005, Ed Ravin wrote: > On Mon, Feb 14, 2005 at 05:54:48PM -0500, Jim Trocki wrote: >> sorry, you're correct, no objection to that tag. one thing i need to do is >> port >> a change i did in a recent -devel which makes a unified routine for handling >> both failures and traps (called "process_event"), and significantly >> simplifying >> the handling of both by removing lots of redundant code. it also made me >> feel better :) > > Speaking of making people feel better, I'd like to replace the ugly > "clientallow" regular expression to control IP access (what was I thinking, > other than programmer laziness, when I submitted that?) with a netmask-aware > version of same. I noticed a Perl module for parsing netmasks - does anyone > mind if we require Yet One More module in Mon for it to run? that's not a good idea. the code to do that is so tiny, there's no sense in requiring another module for it. if you want i can give you some of my own code from another tool i have which does this junk. |
From: Ed R. <er...@pa...> - 2005-02-14 23:05:53
|
On Mon, Feb 14, 2005 at 05:54:48PM -0500, Jim Trocki wrote: > sorry, you're correct, no objection to that tag. one thing i need to do is > port > a change i did in a recent -devel which makes a unified routine for handling > both failures and traps (called "process_event"), and significantly > simplifying > the handling of both by removing lots of redundant code. it also made me > feel better :) Speaking of making people feel better, I'd like to replace the ugly "clientallow" regular expression to control IP access (what was I thinking, other than programmer laziness, when I submitted that?) with a netmask-aware version of same. I noticed a Perl module for parsing netmasks - does anyone mind if we require Yet One More module in Mon for it to run? |
From: David N. <vit...@cm...> - 2005-02-14 14:51:57
|
--On Friday, February 11, 2005 8:52 PM -0500 Ed Ravin <er...@pa...> wrote: > Is there any chance the anti-gas fork code will be brought into 1.0? > If not, is the code currently in the CVS head usable? Any reason > why 1.1 isn't tagged yet or 1.0 not released yet? > > -- Ed Ed, About a week ago I asked on the list, and in email to Jim, if he had any objections to my tagging the HEAD as 1.1.0pre1. I got no response, so I guess I'll assume he has no objections. I've tagged the current CVS head as mon-1-1-0pre1. I did not tag mon-client, as there are no changes from the 1.0 version. Other then a few documentation updates, I think 1.1.0 is pretty much ready. Any feedback you can provide would be appreciated. -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: Peter W. <pe...@wi...> - 2005-02-13 15:46:10
|
Hello I have recently released my infocon.monitor. In time I will release my snort.monitor (http://www.snort.org/). Both these monitors are security related, so new catagory: security /Peter |
From: Peter W. <pe...@wi...> - 2005-02-13 00:28:42
|
################################################################################ # Monitor infocon alert level # # The Internet Storm Center (http://isc.sans.org) has a file(infocon.txt), # describing the current level of malicious traffic on the internet. # # from isc... # # +----------------------------------------------------------------------------- # ! The intent of the 'Infocon' is to reflect changes in malicious traffic # ! and the possibility of disrupted connectivity. In particular important # ! is the concept of "Change". Every host connected to the Internet is subject # ! to some amount of traffic caused by worms and viruses. However, once a worm # ! has been identified and the number of infected machines is no longer # ! increasing, this traffic is not likely to cause any disruptions. # ! # ! The Infocon is intended to apply to the condition of the Internet # ! infrastructure. We do not monitor particular nations or companies. # +----------------------------------------------------------------------------- # # This script monitors the content of the file http://isc.sans.org/infocon.txt # # infocon definition: # # green: Everything is normal. No significant new threat known. # # yellow: We are currently tracking a significant new threat. # The impact is either unknown or expected to be minor # to the infrastructure. However, local impact could be # significant. Users are adviced to take immediate specific # action to contain the impact. Example: 'MSBlaster' worm outbreak. # # orange: A major disruption in connectivity is imminent or in progress. # Examples: Code Red on its return, and SQL Slammer worm during # its first half day # # red: Loss of connectivity across a large part of the internet. # ################################################################################ # # Usage : infocon.monitor [options] # # Requirements: LWP::UserAgent; # #------------------------------------------------------------------------------- # # --agent <agentname> # Example: --agent infocon # # To set the agent name (UserAgent->agent method). # Defaults to "libwww-perl/#.##" # #------------------------------------------------------------------------------- # # --timeout <n> # Example: --timeout 30 # # Set the timeout for the http request (UserAgent->timeout method). # Defaults to 180s # #------------------------------------------------------------------------------- # # --proxy <http proxy> # Example: --proxy http://www-proxy.com:8080 # # Set the http proxy (UserAgent->proxy('http','.....') # Default to use *_proxy environment variables. (UserAgent->env_proxy method). # #------------------------------------------------------------------------------- # # --silent # Example: --silent # # Don't print anything on stdout (i.e disable a mon monitor behaviour), # only return the status to the OS # #------------------------------------------------------------------------------- # # --url <url> # Example: --url http://my.mirror.com/infocon.txt # # Set the url to retreive and parse # Defaults to http://isc.sans.org/infocon.txt # #------------------------------------------------------------------------------- # # --version # # Prints the version and exits # ################################################################################ # # Return values # # 0 -> Infocon is green # 1 -> Infocon is unavailable or some other communication or data error # 2 -> Infocon is yellow # 3 -> Infocon is orange # 4 -> Infocon is red # # Mon usage example # +------------------------------------------- # !hostgroup infocon # ! # !watch infocon # ! service infocon.txt # ! interval 1h # ! monitor infocon.monitor # ! allow_empty_group # ! period wd {Sun-Sat} # ! alert exit=1 mail.alert... # ! alert exit=2 sms.alert yellow ... # ! alert exit=3 sms.alert orange ... # ! alert exit=4 sms.alert red ... # ! upalert sms.alert ... # ! upalert mail.alert ... # ! alertevery 8h # +------------------------------------------- # ################################################################################ # # Copyright (C) 2005, Peter Wirdemo # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License. # ################################################################################ |
From: Ed R. <er...@pa...> - 2005-02-12 01:52:52
|
On Tue, Aug 03, 2004 at 09:24:04AM -0700, Jim Trocki wrote: > the latest pre-1.0.0 release is available from: > > ftp://ftp.kernel.org/pub/software/admin/mon/devel/ > > 1.0.0 is getting close now. in fact, we've never been closer. out of > all the pre-1.0.0 releases, this has been the closest. the closeness of > this release to 1.0.0 surpasses all previous releases. Actually, I see there's an even closer one released in November. But it still doesn't have the one fix that I really need, which is the ability to fork on alerts so that a stuck alert does gag up the rest of Mon. I see this feature is in the CVS head, still not yet tagged as 1.1 Is there any chance the anti-gas fork code will be brought into 1.0? If not, is the code currently in the CVS head usable? Any reason why 1.1 isn't tagged yet or 1.0 not released yet? -- Ed |