From druzicka at cube1.cubit.at Sat Feb 1 14:38:33 2003 From: druzicka at cube1.cubit.at (Dietmar Ruzicka) Date: Sat Feb 1 14:38:33 2003 Subject: [Nagiosplug-devel] new oracle plugins Message-ID: Hi all, I did an nagios project. Therefore it was necessary to implement some new oracle plugins. I wrote them by using perl DBI. check_oracle_sql: connects to an instance executes "select user from dual" to check if an instance is up and running. check_oracle_tablespace_status: checks if a tablesspace is online by using DBA_TABLESPACES check_oracle_tablespace: checks the usage off a tablespace by using SM$TS_AVAIL SM$TS_FREE SM$TS_USED check_oracle_cache_hit_ratio: calculates the cache hit ratio by using V_$SYSSTAT (see Oracle8i Designing and Tuning for Performance, 19 Tuning Memory Allocation) The plugins should meet the Nagios plug-in development guidelines. You can add them if you want to. best regards Dietmar -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_plugins.tgz Type: application/x-gtar Size: 2684 bytes Desc: URL: From druzicka at cube1.cubit.at Sat Feb 1 15:27:24 2003 From: druzicka at cube1.cubit.at (Dietmar Ruzicka) Date: Sat Feb 1 15:27:24 2003 Subject: [Nagiosplug-devel] new oracle plugins Message-ID: Hi, sorry I sent an old version of check_oracle_cache_hit_ratio! the ratio should be > than the threshold. Dietmar -------------- next part -------------- #!/usr/bin/perl -w use DBI; use strict; use Getopt::Long; &Getopt::Long::config('bundling'); my $PROGNAME = "check_oracle_cache_hit_ratio"; my $status; # # parameters my $hostname; my $instance; my $user; my $password; my $warning; my $critical; my $opt_h; my $opt_V; my $dbh; my @db_block_gets; my @consistent_gets; my @physical_reads; my $stmt_db_block_gets; my $stmt_consistent_gets; my $stmt_physical_reads; my $result; my %ERRORS=('OK'=>0,'WARNING'=>1,'CRITICAL'=>2,'UNKNOWN'=>3,'DEPENDENT'=>4); $status = GetOptions( "V" => \$opt_V, "version" => \$opt_V, "h" => \$opt_h, "help" => \$opt_h, "u=s" =>\$user, "user=s" => \$user, "p=s" =>\$password, "password=s",\$password, "i=s" =>\$instance, "instance=s" => \$instance, "H=s" => \$hostname, "hostname=s" => \$hostname, "w=i" =>\$warning, "warning=i" => \$warning, "c=i" =>\$critical, "critical=i" => \$critical ); if ($status == 0) { print_help(); exit $ERRORS{'OK'}; } if ($opt_V) { print "$PROGNAME, Revision: 0.2\n"; exit $ERRORS{'OK'}; } if ($opt_h) { print_help(); exit $ERRORS{'OK'}; } if (!defined($hostname)){ usage(); exit $ERRORS{"UNKNOWN"}; } if (!defined($instance)){ usage(); exit $ERRORS{"UNKNOWN"}; } if (!defined($user)){ usage(); exit $ERRORS{"UNKNOWN"}; } if (!defined($password)){ usage(); exit $ERRORS{"UNKNOWN"}; } if (!defined($warning)){ usage(); exit $ERRORS{"UNKNOWN"}; } if (!defined($critical)){ usage(); exit $ERRORS{"UNKNOWN"}; } if ($warning > $critical) { print "Error: Warning Value greater than Critical Value! $warning% > $critical%!\n"; exit $ERRORS{"UNKNOWN"}; } # # sql select-statements $stmt_db_block_gets="select value from sys.v_\$sysstat where name in(\'db block gets\')"; $stmt_consistent_gets="select value from sys.v_\$sysstat where name in(\'consistent gets\')"; $stmt_physical_reads="select value from sys.v_\$sysstat where name in(\'physical reads\')"; # # connecting to database $dbh = DBI->connect("dbi:Oracle:host=".$hostname.";sid=".$instance, $user, $password); if (!defined($dbh)) { print "Critical: Cannot connect to Oracle! $DBI::errstr\n"; exit $ERRORS{"CRITICAL"}; } # # executing query @db_block_gets = $dbh->selectrow_array($stmt_db_block_gets); if (defined $DBI::err) { print "Error: $DBI::errstr\n"; $dbh->disconnect; exit $ERRORS{"CRITICAL"}; } @consistent_gets = $dbh->selectrow_array($stmt_consistent_gets); if (defined $DBI::err) { print "Error: $DBI::errstr\n"; $dbh->disconnect; exit $ERRORS{"CRITICAL"}; } @physical_reads = $dbh->selectrow_array($stmt_physical_reads); if (defined $DBI::err) { print "Error: $DBI::errstr\n"; $dbh->disconnect; exit $ERRORS{"CRITICAL"}; } # # disconnect; $dbh->disconnect; # # calculating result if ((!defined($physical_reads[0])) || (!defined($consistent_gets[0])) || (!defined($db_block_gets[0]))) { print "Unknown: Value missing!\n"; exit $ERRORS{"UNKNOWN"}; } $result = (1 - $physical_reads[0] / ($db_block_gets[0] + $consistent_gets[0])) * 100; # cut to dd.d $result = int ($result*10); $result = $result / 10; # # critical if result < required if ($result < $critical) { print "Critical: cache hit ratio: $result % warning: $warning critical: $critical \n"; exit $ERRORS{"CRITICAL"}; } # # warning if result < required if ($result < $warning) { print "Warning: cache hit ratio: $result % warning: $warning critical: $critical\n"; exit $ERRORS{"WARNING"}; } # # ok if result => required print "Information: cache hit ratio: $result % warning: $warning critical: $critical\n"; exit $ERRORS{"OK"}; sub usage { print "\nMissing arguments!\n"; print "\n"; print "usage: \n"; print "$PROGNAME -H -i -u -p -w -c \n"; print "Copyright (C) 2002 Dietmar Ruzicka druzicka\@cubit.at\n"; print "$PROGNAME comes with ABSOLUTELY NO WARRANTY\n"; print "This programm is licensed under the terms of the "; print "GNU General Public License\n"; print "\n\n"; exit $ERRORS{"UNKNOWN"}; } sub print_help { print "$PROGNAME plugin for Nagios monitors current\n"; print "cache hit ratio\n"; printf "\nrequires an oracle user with the following properties:\n"; printf "\tcreate user nagios identified by nagios;\n"; printf "\tgrant connect to nagios;\n"; printf "\tgrant select on V_\$SYSSTAT to nagios;\n"; print "\nUsage:\n"; print " -H (--hostname) Hostname to query - (required)\n"; print " -i (--instance) Oracle Instance - (required)\n"; print " -u (--user) Oracle user - (required)\n"; print " -p (--password) Oracle user password - (required)\n"; print " -w (--warning) Warning threshold for cache hit ratio - (required)\n"; print " -c (--critical) Warning threshold for cache hit ratio - (required)\n"; print " -V (--version) Plugin version\n"; print " -h (--help) usage help \n\n"; print "$PROGNAME, Revision: 0.2\n"; exit $ERRORS{"UNKNOWN"}; } From druzicka at cube1.cubit.at Sat Feb 1 15:32:06 2003 From: druzicka at cube1.cubit.at (Dietmar Ruzicka) Date: Sat Feb 1 15:32:06 2003 Subject: [Nagiosplug-devel] new oracle plugins Message-ID: Hi, sorry I sent an old version of check_oracle_cache_hit_ratio! the ratio should be > than the threshold. Dietmar -------------- next part -------------- #!/usr/bin/perl -w use DBI; use strict; use Getopt::Long; &Getopt::Long::config('bundling'); my $PROGNAME = "check_oracle_cache_hit_ratio"; my $status; # # parameters my $hostname; my $instance; my $user; my $password; my $warning; my $critical; my $opt_h; my $opt_V; my $dbh; my @db_block_gets; my @consistent_gets; my @physical_reads; my $stmt_db_block_gets; my $stmt_consistent_gets; my $stmt_physical_reads; my $result; my %ERRORS=('OK'=>0,'WARNING'=>1,'CRITICAL'=>2,'UNKNOWN'=>3,'DEPENDENT'=>4); $status = GetOptions( "V" => \$opt_V, "version" => \$opt_V, "h" => \$opt_h, "help" => \$opt_h, "u=s" =>\$user, "user=s" => \$user, "p=s" =>\$password, "password=s",\$password, "i=s" =>\$instance, "instance=s" => \$instance, "H=s" => \$hostname, "hostname=s" => \$hostname, "w=i" =>\$warning, "warning=i" => \$warning, "c=i" =>\$critical, "critical=i" => \$critical ); if ($status == 0) { print_help(); exit $ERRORS{'OK'}; } if ($opt_V) { print "$PROGNAME, Revision: 0.2\n"; exit $ERRORS{'OK'}; } if ($opt_h) { print_help(); exit $ERRORS{'OK'}; } if (!defined($hostname)){ usage(); exit $ERRORS{"UNKNOWN"}; } if (!defined($instance)){ usage(); exit $ERRORS{"UNKNOWN"}; } if (!defined($user)){ usage(); exit $ERRORS{"UNKNOWN"}; } if (!defined($password)){ usage(); exit $ERRORS{"UNKNOWN"}; } if (!defined($warning)){ usage(); exit $ERRORS{"UNKNOWN"}; } if (!defined($critical)){ usage(); exit $ERRORS{"UNKNOWN"}; } if ($warning < $critical) { print "Error: Warning Value greater than Critical Value! $warning% < $critical%!\n"; exit $ERRORS{"UNKNOWN"}; } # # sql select-statements $stmt_db_block_gets="select value from sys.v_\$sysstat where name in(\'db block gets\')"; $stmt_consistent_gets="select value from sys.v_\$sysstat where name in(\'consistent gets\')"; $stmt_physical_reads="select value from sys.v_\$sysstat where name in(\'physical reads\')"; # # connecting to database $dbh = DBI->connect("dbi:Oracle:host=".$hostname.";sid=".$instance, $user, $password); if (!defined($dbh)) { print "Critical: Cannot connect to Oracle! $DBI::errstr\n"; exit $ERRORS{"CRITICAL"}; } # # executing query @db_block_gets = $dbh->selectrow_array($stmt_db_block_gets); if (defined $DBI::err) { print "Error: $DBI::errstr\n"; $dbh->disconnect; exit $ERRORS{"CRITICAL"}; } @consistent_gets = $dbh->selectrow_array($stmt_consistent_gets); if (defined $DBI::err) { print "Error: $DBI::errstr\n"; $dbh->disconnect; exit $ERRORS{"CRITICAL"}; } @physical_reads = $dbh->selectrow_array($stmt_physical_reads); if (defined $DBI::err) { print "Error: $DBI::errstr\n"; $dbh->disconnect; exit $ERRORS{"CRITICAL"}; } # # disconnect; $dbh->disconnect; # # calculating result if ((!defined($physical_reads[0])) || (!defined($consistent_gets[0])) || (!defined($db_block_gets[0]))) { print "Unknown: Value missing!\n"; exit $ERRORS{"UNKNOWN"}; } $result = (1 - $physical_reads[0] / ($db_block_gets[0] + $consistent_gets[0])) * 100; # cut to dd.d $result = int ($result*10); $result = $result / 10; # # critical if result < required if ($result < $critical) { print "Critical: cache hit ratio: $result % warning: $warning critical: $critical \n"; exit $ERRORS{"CRITICAL"}; } # # warning if result < required if ($result < $warning) { print "Warning: cache hit ratio: $result % warning: $warning critical: $critical\n"; exit $ERRORS{"WARNING"}; } # # ok if result <= required print "Information: cache hit ratio: $result % warning: $warning critical: $critical\n"; exit $ERRORS{"OK"}; sub usage { print "\nMissing arguments!\n"; print "\n"; print "usage: \n"; print "$PROGNAME -H -i -u -p -w -c \n"; print "Copyright (C) 2002 Dietmar Ruzicka druzicka\@cubit.at\n"; print "$PROGNAME comes with ABSOLUTELY NO WARRANTY\n"; print "This programm is licensed under the terms of the "; print "GNU General Public License\n"; print "\n\n"; exit $ERRORS{"UNKNOWN"}; } sub print_help { print "$PROGNAME plugin for Nagios monitors current\n"; print "cache hit ratio\n"; printf "\nrequires an oracle user with the following properties:\n"; printf "\tcreate user nagios identified by nagios;\n"; printf "\tgrant connect to nagios;\n"; printf "\tgrant select on V_\$SYSSTAT to nagios;\n"; print "\nUsage:\n"; print " -H (--hostname) Hostname to query - (required)\n"; print " -i (--instance) Oracle Instance - (required)\n"; print " -u (--user) Oracle user - (required)\n"; print " -p (--password) Oracle user password - (required)\n"; print " -w (--warning) Warning threshold for cache hit ratio - (required)\n"; print " -c (--critical) Warning threshold for cache hit ratio - (required)\n"; print " -V (--version) Plugin version\n"; print " -h (--help) usage help \n\n"; print "$PROGNAME, Revision: 0.2\n"; exit $ERRORS{"UNKNOWN"}; } From noreply at sourceforge.net Mon Feb 3 08:02:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 3 08:02:55 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-679321 ] ICA Plugin Message-ID: Support Requests item #679321, was opened at 2003-02-02 21:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=679321&group_id=29880 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ICA Plugin Initial Comment: Has anyone written a plugin to check the status of Citrix ICA servers? (TCP 1494) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=679321&group_id=29880 From noreply at sourceforge.net Mon Feb 3 08:02:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 3 08:02:56 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-679400 ] check_snmp : avoid core dump Message-ID: Patches item #679400, was opened at 2003-02-03 11:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=679400&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mathieu Masseboeuf (mathieuma) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp : avoid core dump Initial Comment: Check_snmp dump core when an invalid data (ie : empty or inexistant oid) is checked against numerical values. This just check that the pointer is not null before doing the numeric comparision, else exits with STATE_UNKNOWN ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=679400&group_id=29880 From noreply at sourceforge.net Mon Feb 3 08:02:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 3 08:02:57 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-679403 ] check_snmp : STRING tag parsing Message-ID: Patches item #679403, was opened at 2003-02-03 11:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=679403&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mathieu Masseboeuf (mathieuma) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp : STRING tag parsing Initial Comment: STRING tag parsing, usefull for example when you check 2 oids : an error flag and the corresponding error message (which is a string). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=679403&group_id=29880 From Jeremy.Bouse at UnderGrid.net Mon Feb 3 10:04:43 2003 From: Jeremy.Bouse at UnderGrid.net (Jeremy T. Bouse) Date: Mon Feb 3 10:04:43 2003 Subject: [Nagiosplug-devel] Problems with building from CVS? Message-ID: <20030203175426.GB25270@UnderGrid.net> Is anyone else having any problems with building from CVS at the moment? I am attachign a log of some of the things I'm seeing with runnin the tools/setup and running configure as well as the version output on all the auto dev tools I received this against... Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: nagiosplug.log.gz Type: application/octet-stream Size: 1027 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From noreply at sourceforge.net Mon Feb 3 10:56:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 3 10:56:15 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-679703 ] plugins-scripts/Makefile.am: sets correct user:group for "ma Message-ID: Patches item #679703, was opened at 2003-02-03 19:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=679703&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Detlef B?hm (dboehm) Assigned to: Nobody/Anonymous (nobody) Summary: plugins-scripts/Makefile.am: sets correct user:group for "ma Initial Comment: "make install" fails to set user:group for scripts from source directory "plugins-scripts" to the values specified with "configure" options. This patch fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=679703&group_id=29880 From sghosh at sghosh.org Mon Feb 3 11:03:41 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Feb 3 11:03:41 2003 Subject: [Nagiosplug-devel] Problems with building from CVS? In-Reply-To: <20030203175426.GB25270@UnderGrid.net> Message-ID: On Mon, 3 Feb 2003, Jeremy T. Bouse wrote: > Is anyone else having any problems with building from CVS at > the moment? I am attachign a log of some of the things I'm seeing with > runnin the tools/setup and running configure as well as the version > output on all the auto dev tools I received this against... > > Jeremy > Yes the errors are due to the version for autotools. use autoconf 2.13/automake 1.4/1.5 autoconf 2.5x introduces a number of template/format changes that hhave not been integrated. -- -sg From karl at debisschop.net Tue Feb 4 04:08:06 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Tue Feb 4 04:08:06 2003 Subject: [Nagiosplug-devel] Problems with building from CVS? In-Reply-To: References: Message-ID: <1044360391.19831.4.camel@localhost.localdomain> On Mon, 2003-02-03 at 13:54, Subhendu Ghosh wrote: > On Mon, 3 Feb 2003, Jeremy T. Bouse wrote: > > > Is anyone else having any problems with building from CVS at > > the moment? I am attachign a log of some of the things I'm seeing with > > runnin the tools/setup and running configure as well as the version > > output on all the auto dev tools I received this against... > > > > Jeremy > > > > Yes the errors are due to the version for autotools. > > use autoconf 2.13/automake 1.4/1.5 > > autoconf 2.5x introduces a number of template/format changes that hhave > not been integrated. Actually, only the warns are from the AC changes. It will build. Copy getlaodavg.c up one level from plsugins as a quick fix -- I think that will work. -- Karl From renders at cknxradio.com Tue Feb 4 05:43:03 2003 From: renders at cknxradio.com (Rob Enders) Date: Tue Feb 4 05:43:03 2003 Subject: [Nagiosplug-devel] Here's a cool plugin idea! Message-ID: Came across this project.. It is basically a sound based monitor. Might be fun to add this to a nagios system. Rob \www.auralizer.com From dviner at yahoo-inc.com Tue Feb 4 09:03:02 2003 From: dviner at yahoo-inc.com (Dave Viner) Date: Tue Feb 4 09:03:02 2003 Subject: [Nagiosplug-devel] check_http minimum size patch In-Reply-To: Message-ID: Hi, I just wanted to see if there were any reactions to this patch (posted on Jan 22 2003). I haven't heard anything and I think this is really useful functionality. Thanks dave -----Original Message----- From: nagiosplug-devel-admin at lists.sourceforge.net [mailto:nagiosplug-devel-admin at lists.sourceforge.net]On Behalf Of Dave Viner Sent: Wednesday, January 22, 2003 9:57 AM To: nagiosplug-devel at lists.sourceforge.net Subject: [Nagiosplug-devel] check_http minimum size patch Hi, Here's a patch to check_http that allows the user to specify a minimum size required for the page requested. It implements a -m (--min) option to obtain the information from the command line. It checks the size of the page (not HTTP headers) against the specified size. Let me know what you think. Thanks Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: http.patch Type: application/octet-stream Size: 2753 bytes Desc: not available URL: From noreply at sourceforge.net Tue Feb 4 09:20:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 4 09:20:01 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-680330 ] 1.3.0-beta2 check_ntp Message-ID: Bugs item #680330, was opened at 2003-02-04 09:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=680330&group_id=29880 Category: None Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 1.3.0-beta2 check_ntp Initial Comment: check_ntp plugin can't check NTP at Cisco boxes with ntpdc (v4.1.1b): Example: # ./check_ntp -v -H cisco.box server 192.168.255.10, stratum 2, offset -0.012081, delay 0.02586 ntperr = 0 5 Feb 02:59:00 ntpdate[26053]: adjust time server 192.168.255.10 offset -0.012081 sec ntperr = 0 ***Warning changing the request packet size from 160 to 48 ***Incorrect item size returned by remote host (36 should be 32) UNKNOWN: Dispersion too high Last two warnings(***) coming from ntpdc: # ntpdc -s cisco.my.lan ***Warning changing the request packet size from 160 to 48 ***Incorrect item size returned by remote host (36 should be 32) But linux NTP-daemon (4.1.1b) check is succesfull: [root at stone plugins]# ./check_ntp.old -v -H 192.168.200.1 server 192.168.200.1, stratum 3, offset 0.000001, delay 0.02567 ntperr = 0 5 Feb 03:08:19 ntpdate[27302]: adjust time server 192.168.200.1 offset 0.000001 sec ntperr = 0 remote local st poll reach delay offset disp ======================================================================= LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.00092 *core1.lan 192.168.200.1 2 64 377 0.00031 -0.010346 0.00093 .sql3.lan 192.168.200.1 2 64 377 0.00113 0.006602 0.00092 OK: Time difference 0.000001 seconds ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=680330&group_id=29880 From Ton.Voon at egg.com Tue Feb 4 10:04:02 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Tue Feb 4 10:04:02 2003 Subject: [Nagiosplug-devel] check_http minimum size patch Message-ID: <53104E20A25CD411B556009027E50636064D5257@pnnemp02.pn.egg.com> Dave, Can you submit the patch to http://sourceforge.net/tracker/?group_id=29880&atid=397599. That way it won't get missed. Ton > -----Original Message----- > From: Dave Viner [SMTP:dviner at yahoo-inc.com] > Sent: Tuesday, February 04, 2003 5:02 PM > To: nagiosplug-devel at lists.sourceforge.net > Subject: RE: [Nagiosplug-devel] check_http minimum size patch > > Hi, > I just wanted to see if there were any reactions to this patch > (posted on > Jan 22 2003). I haven't heard anything and I think this is really useful > functionality. > > > Thanks > dave > > > -----Original Message----- > From: nagiosplug-devel-admin at lists.sourceforge.net > [mailto:nagiosplug-devel-admin at lists.sourceforge.net]On Behalf Of Dave > Viner > Sent: Wednesday, January 22, 2003 9:57 AM > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] check_http minimum size patch > > > Hi, > Here's a patch to check_http that allows the user to specify a > minimum size > required for the page requested. It implements a -m (--min) option to > obtain the information from the command line. It checks the size of the > page (not HTTP headers) against the specified size. Let me know what you > think. > > Thanks > Dave << File: http.patch >> This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From dviner at yahoo-inc.com Tue Feb 4 13:08:04 2003 From: dviner at yahoo-inc.com (Dave Viner) Date: Tue Feb 4 13:08:04 2003 Subject: [Nagiosplug-devel] check_http minimum size patch In-Reply-To: <53104E20A25CD411B556009027E50636064D5257@pnnemp02.pn.egg.com> Message-ID: done... thanks dave -----Original Message----- From: nagiosplug-devel-admin at lists.sourceforge.net [mailto:nagiosplug-devel-admin at lists.sourceforge.net]On Behalf Of Voon, Ton Sent: Tuesday, February 04, 2003 10:02 AM To: 'Dave Viner'; nagiosplug-devel at lists.sourceforge.net Subject: RE: [Nagiosplug-devel] check_http minimum size patch Dave, Can you submit the patch to http://sourceforge.net/tracker/?group_id=29880&atid=397599. That way it won't get missed. Ton > -----Original Message----- > From: Dave Viner [SMTP:dviner at yahoo-inc.com] > Sent: Tuesday, February 04, 2003 5:02 PM > To: nagiosplug-devel at lists.sourceforge.net > Subject: RE: [Nagiosplug-devel] check_http minimum size patch > > Hi, > I just wanted to see if there were any reactions to this patch > (posted on > Jan 22 2003). I haven't heard anything and I think this is really useful > functionality. > > > Thanks > dave > > > -----Original Message----- > From: nagiosplug-devel-admin at lists.sourceforge.net > [mailto:nagiosplug-devel-admin at lists.sourceforge.net]On Behalf Of Dave > Viner > Sent: Wednesday, January 22, 2003 9:57 AM > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] check_http minimum size patch > > > Hi, > Here's a patch to check_http that allows the user to specify a > minimum size > required for the page requested. It implements a -m (--min) option to > obtain the information from the command line. It checks the size of the > page (not HTTP headers) against the specified size. Let me know what you > think. > > Thanks > Dave << File: http.patch >> This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Nagiosplug-devel mailing list Nagiosplug-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel From noreply at sourceforge.net Tue Feb 4 13:13:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 4 13:13:06 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-680467 ] check_http min size patch Message-ID: Patches item #680467, was opened at 2003-02-04 13:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=680467&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dave Viner (dviner) Assigned to: Nobody/Anonymous (nobody) Summary: check_http min size patch Initial Comment: Here's a patch to check_http that allows the user to specify a minimum size required for the page requested. It implements a -m (-- min) option to obtain the information from the command line. It checks the size of the page (not HTTP headers) against the specified size. dave ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=680467&group_id=29880 From r1p6os402 at sneakemail.com Tue Feb 4 15:12:04 2003 From: r1p6os402 at sneakemail.com (Steve Bonds) Date: Tue Feb 4 15:12:04 2003 Subject: [Nagiosplug-devel] check_mrtgtraf.c Description incorrect (patch) Message-ID: <25342-20327@sneakemail.com> The description in check_mrtgtraf.c seems to have been borrowed from check_ups.c. The attached short patch provides a better description. -- Steve -------------- next part -------------- Index: check_mrtgtraf.c =================================================================== RCS file: /cvsroot/nagiosplug/nagiosplug/plugins/check_mrtgtraf.c,v retrieving revision 1.4 diff -u -r1.4 check_mrtgtraf.c --- check_mrtgtraf.c 29 Jan 2003 20:57:09 -0000 1.4 +++ check_mrtgtraf.c 4 Feb 2003 23:10:03 -0000 @@ -358,7 +358,7 @@ print_revision (progname, "$Revision: 1.4 $"); printf ("Copyright (c) 2000 Tom Shields/Karl DeBisschop\n\n" - "This plugin tests the UPS service on the specified host.\n\n"); + "This plugin checks local MRTG files for high bandwidth usage.\n\n"); print_usage (); printf ("\nOptions:\n" From r1p6os402 at sneakemail.com Tue Feb 4 16:29:03 2003 From: r1p6os402 at sneakemail.com (Steve Bonds) Date: Tue Feb 4 16:29:03 2003 Subject: [Nagiosplug-devel] check_dns.c: Requires DNS server (patch) Message-ID: <23754-24923@sneakemail.com> The help text for the check_dns.c plugin says that the DNS server is optional, yet the program logic found on line 366 of the current CVS version requires the server to be specified. ---- if (dns_server[0] == 0) { if (is_host (argv[c]) == FALSE) { printf ("Invalid name/address: %s\n\n", argv[c]); return ERROR; } ----- (If unspecified, dns_server is null at that point, triggering an "Invalid name/address". It's better than the last beta version at least, as that one coredumps on me from utils.c. ;-) The attached patch corrects the documentation so that it says the server is required. -- Steve From karl at debisschop.net Tue Feb 4 16:57:07 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Tue Feb 4 16:57:07 2003 Subject: [Nagiosplug-devel] check_http minimum size patch In-Reply-To: References: Message-ID: <1044406536.19831.21.camel@localhost.localdomain> On Tue, 2003-02-04 at 16:07, Dave Viner wrote: > done... thanks > > dave Keep in mind, we're trying to make a feature freeze stick here. It will probably be a couple of weeks before we want to add new fetures. The other developers can comment on my timeline here. -- Karl From sghosh at sghosh.org Tue Feb 4 17:37:08 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Tue Feb 4 17:37:08 2003 Subject: [Nagiosplug-devel] check_dns.c: Requires DNS server (patch) In-Reply-To: <23754-24923@sneakemail.com> Message-ID: attached patch??? ;) On Tue, 4 Feb 2003, Steve Bonds wrote: > The help text for the check_dns.c plugin says that the DNS server is > optional, yet the program logic found on line 366 of the current CVS > version requires the server to be specified. > > ---- > if (dns_server[0] == 0) { > if (is_host (argv[c]) == FALSE) { > printf ("Invalid name/address: %s\n\n", argv[c]); > return ERROR; > } > ----- > > (If unspecified, dns_server is null at that point, triggering an "Invalid > name/address". It's better than the last beta version at least, as that > one coredumps on me from utils.c. ;-) > > The attached patch corrects the documentation so that it says the server > is required. > > -- Steve > -- From sghosh at sghosh.org Tue Feb 4 17:43:02 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Tue Feb 4 17:43:02 2003 Subject: [Nagiosplug-devel] check_http minimum size patch In-Reply-To: <1044406536.19831.21.camel@localhost.localdomain> Message-ID: Just to remind everybody a feature freeze is in effect for the standard plugins until the 1.3 release. Patches for new features should be announce on the list and posted on SourceForge, but they won't get integrated till post-1.3 I believe we are targeting 1.3 to be released this month. -sg On 4 Feb 2003, Karl DeBisschop wrote: > On Tue, 2003-02-04 at 16:07, Dave Viner wrote: > > done... thanks > > > > dave > > Keep in mind, we're trying to make a feature freeze stick here. It will > probably be a couple of weeks before we want to add new fetures. The > other developers can comment on my timeline here. > > -- > Karl -- From r1p6os402 at sneakemail.com Tue Feb 4 18:02:04 2003 From: r1p6os402 at sneakemail.com (Steve Bonds) Date: Tue Feb 4 18:02:04 2003 Subject: [Nagiosplug-devel] check_dns.c: Requires DNS server (patch) In-Reply-To: Message-ID: <26298-81419@sneakemail.com> I hate it when I do that. ;-) It's REALLY attached this time. -- Steve On Tue, 4 Feb 2003, Subhendu Ghosh sghosh-at-sghosh.org |Nagios| wrote: > > attached patch??? ;) > > On Tue, 4 Feb 2003, Steve Bonds wrote: > > > The attached patch corrects the documentation so that it says the server > > is required. -------------- next part -------------- Index: check_dns.c =================================================================== RCS file: /cvsroot/nagiosplug/nagiosplug/plugins/check_dns.c,v retrieving revision 1.6 diff -u -r1.6 check_dns.c --- check_dns.c 13 Jan 2003 12:15:15 -0000 1.6 +++ check_dns.c 5 Feb 2003 00:21:38 -0000 @@ -354,7 +354,7 @@ c = optind; if (query_address[0] == 0) { if (is_host (argv[c]) == FALSE) { - printf ("Invalid name/address: %s\n\n", argv[c]); + printf ("Invalid host name/address: %s\n\n", argv[c]); return ERROR; } if (strlen (argv[c]) >= ADDRESS_LENGTH) @@ -364,7 +364,7 @@ if (dns_server[0] == 0) { if (is_host (argv[c]) == FALSE) { - printf ("Invalid name/address: %s\n\n", argv[c]); + printf ("Invalid DNS server name/address: %s\n\n", argv[c]); return ERROR; } if (strlen (argv[c]) >= ADDRESS_LENGTH) @@ -387,7 +387,7 @@ void print_usage (void) { - printf ("Usage: %s -H host [-s server] [-a expected-address] [-t timeout]\n" " %s --help\n" + printf ("Usage: %s -H host -s server [-a expected-address] [-t timeout]\n" " %s --help\n" " %s --version\n", progname, progname, progname); } @@ -402,7 +402,7 @@ "-H, --hostname=HOST\n" " The name or address you want to query\n" "-s, --server=HOST\n" - " Optional DNS server you want to use for the lookup\n" + " DNS server you want to use for the lookup\n" "-a, --expected-address=IP-ADDRESS\n" " Optional IP address you expect the DNS server to return\n" "-t, --timeout=INTEGER\n" @@ -413,7 +413,6 @@ " Print version numbers and license information\n" "\n" "This plugin uses the nslookup program to obtain the IP address\n" - "for the given host/domain query. A optional DNS server to use may\n" - "be specified. If no DNS server is specified, the default server(s)\n" - "specified in /etc/resolv.conf will be used.\n", DEFAULT_SOCKET_TIMEOUT); + "for the given host/domain query from the given server." + "\n", DEFAULT_SOCKET_TIMEOUT); } From sghosh at sghosh.org Tue Feb 4 18:23:02 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Tue Feb 4 18:23:02 2003 Subject: [Nagiosplug-devel] check_http: Socket timeout after 10 seconds (but webserver is up! ) In-Reply-To: Message-ID: Are these virtual webs hosted on smae if and host headers or different ip and host headers. You might want to try using both -H and -I -sg On Sun, 26 Jan 2003, Christoph Stotz wrote: > Hello, > > I am experiencing a strange behaviour regarding check_http. I am trying to > check multiple virtual Webs being hosted on the same machine. It seems, that > first web (I call it first, because it has the lowest IP even if that does > not should really matter) is checked without any problems, but any following > times out. > > <---cut here---><---cut here---><---cut here---><---cut here---><---cut > here---> > spaehfix:/usr/local/nagios # ./libexec/check_http -H A.B.C.D > HTTP ok: HTTP/1.1 200 OK - 0.212 second response time |time= 0.212 > spaehfix:/usr/local/nagios # ./libexec/check_http -H E.F.G.H > Socket timeout after 10 seconds > spaehfix:/usr/local/nagios # ./libexec/check_http -H I.J.K.L > Socket timeout after 10 seconds > <---cut here---><---cut here---><---cut here---><---cut here---><---cut > here---> > > and so on. All webs are on the very same server within the same identical > IIS instance (if "use Apache" pops up in your mind: I have the same problem > with an Apache Web as well :o). The difference seems to be the way a request > like the following one is served: > > <---cut here---><---cut here---><---cut here---><---cut here---><---cut > here---> > spaehfix:/usr/local/nagios # telnet A.B.C.D 80 > Trying A.B.C.D... > Connected to A.B.C.D. > Escape character is '^]'. > GET / HTTP/1.0 > [CR+LF][CR+LF] > <---cut here---><---cut here---><---cut here---><---cut here---><---cut > here---> > > On the first Web, this request returns the whole HTML Header- and > Content-blabla for the "/"-Page. On all the others this request just returns > nothing within 10 (or more) seconds. I believe this is caused by sending an > "mixed-old-style" HTTP-Request. Infact on the Apache I get a proper error > message logged, saying that my request does not conform to RFC2616 section > 14.23. Not that section talks about specifying the host within the request. > > Error Message in Apache (so other people may find this article): > > <---cut here---><---cut here---><---cut here---><---cut here---><---cut > here---> > [Sun Jan 26 20:45:51 2003] [error] [client A.B.C.D] client sent HTTP/1.1 > request without hostname (see RFC2616 section 14.23): / > <---cut here---><---cut here---><---cut here---><---cut here---><---cut > here---> > > in IIS I only see > > <---cut here---><---cut here---><---cut here---><---cut here---><---cut > here---><---cut here---> > 2003-01-26 21:34:21 A.B.C.D - E.F.G.H GET /Default.htm - 200 0 18 206718 80 > HTTP/1.0 - - - > <---cut here---><---cut here---><---cut here---><---cut here---><---cut > here---><---cut here---> > (even if this looks like the check_http succeeded - it did not. It timed > out). > > So this whole situation makes me believe, that there is something either > wrong in check_http or unsupported. The fact, that the very first web on the > IIS works fine and all the other does not makes me believe, that this is up > to handling virtual hosts in the http-Request (FYI: all those Web own their > own IP-Address). > > I also tried out running the check_http using the "--verbose" option. This > does not make any difference: > > <---cut here---><---cut here---><---cut here---><---cut here---><---cut > here---><---cut here---> > spaehfix:/usr/local/nagios/libexec # ./check_http --verbose -H E.F.G.H > Socket timeout after 10 seconds > <---cut here---><---cut here---><---cut here---><---cut here---><---cut > here---><---cut here---> > > And if you think, that this might be a network problem, have a look to > tcpdump's output: > > > <---cut here---><---cut here---><---cut here---><---cut here---><---cut > here---><---cut here---> > spaehfix:~ # tcpdump src E.F.G.H or dst E.F.G.H -i eth0.3128 > tcpdump: listening on eth0.3128 > 22:47:26.527226 E.F.G.H.42125 > A.B.C.D.http: S 4032238030:4032238030(0) win > 5840 (DF) > 22:47:26.527399 A.B.C.D.http > E.F.G.H.42125: S 702361681:702361681(0) ack > 4032238031 win 8760 (DF) > 22:47:26.527432 E.F.G.H.42125 > A.B.C.D.http: . ack 1 win 5840 (DF) > 22:47:26.527654 E.F.G.H.42125 > A.B.C.D.http: P 1:17(16) ack 1 win 5840 (DF) > 22:47:26.703234 A.B.C.D.http > E.F.G.H.42125: . ack 17 win 8744 (DF) > 22:47:26.703270 E.F.G.H.42125 > A.B.C.D.http: P 17:102(85) ack 1 win 5840 > (DF) > 22:47:27.240061 E.F.G.H.42125 > A.B.C.D.http: P 17:102(85) ack 1 win 5840 > (DF) > 22:47:27.241273 A.B.C.D.http > E.F.G.H.42125: . ack 102 win 8659 (DF) > 22:47:36.520323 E.F.G.H.42125 > A.B.C.D.http: F 102:102(0) ack 1 win 5840 > (DF) > 22:47:36.520495 A.B.C.D.http > E.F.G.H.42125: . ack 103 win 8659 (DF) > <---cut here---><---cut here---><---cut here---><---cut here---><---cut > here---><---cut here---> > > I believe this means, that there is no problem in allocating the network > socket. > > So, is there somebody around experiencing the very same problem and maybe > has an idea on how to solve it (other then by using the check_tcp only) ? > > > Thanks a lot for your help! > > > Christoph Stotz > logo: GmbH > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > -- From karl at debisschop.net Tue Feb 4 20:23:01 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Tue Feb 4 20:23:01 2003 Subject: [Nagiosplug-devel] check_dns.c: Requires DNS server (patch) In-Reply-To: <26298-81419@sneakemail.com> References: <26298-81419@sneakemail.com> Message-ID: <1044418851.19831.230.camel@localhost.localdomain> On Tue, 2003-02-04 at 21:01, Steve Bonds wrote: > I hate it when I do that. ;-) > > It's REALLY attached this time. > > -- Steve > > On Tue, 4 Feb 2003, Subhendu Ghosh sghosh-at-sghosh.org |Nagios| wrote: > > > > > attached patch??? ;) > > > > On Tue, 4 Feb 2003, Steve Bonds wrote: > > > > > The attached patch corrects the documentation so that it says the server > > > is required. Thanks for the report. My response to the origianl report was to really allow operation without specifying a dns server. Unless there is an objection, I'd prefer to commit that fix, once I've tested it. -- Karl From stotz at logo.de Wed Feb 5 01:55:03 2003 From: stotz at logo.de (Christoph Stotz) Date: Wed Feb 5 01:55:03 2003 Subject: [Nagiosplug-devel] check_http: Socket timeout after 10 second s (but webserver is up! ) Message-ID: Hello, I already tried that. It does not make any difference. In the meantime I found out something new: I compiled the same identical plugin-sourcetree on two different machines. The first machine is the one I was referring to in my previous posting. That machine has those problems. The second machine is a quite old RedHat Box. It works fine there. So my current guess is, that eventually this problem is caused by an incompatibility. The differences between the two servers are quite big. Basically nothing is the same. So I am now trying to find out the problem by replacing bits&pieces and see when it stops working. My current guess is, that it might be caused by the fact, that I am using VLAN support on the machine that causes trouble. As soon as I solve I'll let you know. As soon as somebody else runs into this problem it would be nice to get informed. Thanks a lot! Christoph > -----Original Message----- > From: Subhendu Ghosh [mailto:sghosh at sghosh.org] > Sent: Mittwoch, 5. Februar 2003 03:22 > To: Christoph Stotz > Cc: 'nagiosplug-devel at lists.sourceforge.net' > Subject: Re: [Nagiosplug-devel] check_http: Socket timeout > after 10 seconds (but webserver is up! ) > > > > Are these virtual webs hosted on smae if and host headers or > different ip > and host headers. > > You might want to try using both -H and -I > > -sg > > > On Sun, 26 Jan 2003, Christoph Stotz wrote: > > > Hello, > > > > I am experiencing a strange behaviour regarding check_http. > I am trying to > > check multiple virtual Webs being hosted on the same > machine. It seems, that > > first web (I call it first, because it has the lowest IP > even if that does > > not should really matter) is checked without any problems, > but any following > > times out. > > > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > > here---> > > spaehfix:/usr/local/nagios # ./libexec/check_http -H A.B.C.D > > HTTP ok: HTTP/1.1 200 OK - 0.212 second response time > |time= 0.212 > > spaehfix:/usr/local/nagios # ./libexec/check_http -H E.F.G.H > > Socket timeout after 10 seconds > > spaehfix:/usr/local/nagios # ./libexec/check_http -H I.J.K.L > > Socket timeout after 10 seconds > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > > here---> > > > > and so on. All webs are on the very same server within the > same identical > > IIS instance (if "use Apache" pops up in your mind: I have > the same problem > > with an Apache Web as well :o). The difference seems to be > the way a request > > like the following one is served: > > > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > > here---> > > spaehfix:/usr/local/nagios # telnet A.B.C.D 80 > > Trying A.B.C.D... > > Connected to A.B.C.D. > > Escape character is '^]'. > > GET / HTTP/1.0 > > [CR+LF][CR+LF] > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > > here---> > > > > On the first Web, this request returns the whole HTML Header- and > > Content-blabla for the "/"-Page. On all the others this > request just returns > > nothing within 10 (or more) seconds. I believe this is > caused by sending an > > "mixed-old-style" HTTP-Request. Infact on the Apache I get > a proper error > > message logged, saying that my request does not conform to > RFC2616 section > > 14.23. Not that section talks about specifying the host > within the request. > > > > Error Message in Apache (so other people may find this article): > > > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > > here---> > > [Sun Jan 26 20:45:51 2003] [error] [client A.B.C.D] client > sent HTTP/1.1 > > request without hostname (see RFC2616 section 14.23): / > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > > here---> > > > > in IIS I only see > > > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > > here---><---cut here---> > > 2003-01-26 21:34:21 A.B.C.D - E.F.G.H GET /Default.htm - > 200 0 18 206718 80 > > HTTP/1.0 - - - > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > > here---><---cut here---> > > (even if this looks like the check_http succeeded - it did > not. It timed > > out). > > > > So this whole situation makes me believe, that there is > something either > > wrong in check_http or unsupported. The fact, that the very > first web on the > > IIS works fine and all the other does not makes me believe, > that this is up > > to handling virtual hosts in the http-Request (FYI: all > those Web own their > > own IP-Address). > > > > I also tried out running the check_http using the > "--verbose" option. This > > does not make any difference: > > > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > > here---><---cut here---> > > spaehfix:/usr/local/nagios/libexec # ./check_http --verbose > -H E.F.G.H > > Socket timeout after 10 seconds > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > > here---><---cut here---> > > > > And if you think, that this might be a network problem, > have a look to > > tcpdump's output: > > > > > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > > here---><---cut here---> > > spaehfix:~ # tcpdump src E.F.G.H or dst E.F.G.H -i eth0.3128 > > tcpdump: listening on eth0.3128 > > 22:47:26.527226 E.F.G.H.42125 > A.B.C.D.http: S > 4032238030:4032238030(0) win > > 5840 (DF) > > 22:47:26.527399 A.B.C.D.http > E.F.G.H.42125: S > 702361681:702361681(0) ack > > 4032238031 win 8760 (DF) > > 22:47:26.527432 E.F.G.H.42125 > A.B.C.D.http: . ack 1 win 5840 (DF) > > 22:47:26.527654 E.F.G.H.42125 > A.B.C.D.http: P 1:17(16) > ack 1 win 5840 (DF) > > 22:47:26.703234 A.B.C.D.http > E.F.G.H.42125: . ack 17 win 8744 (DF) > > 22:47:26.703270 E.F.G.H.42125 > A.B.C.D.http: P 17:102(85) > ack 1 win 5840 > > (DF) > > 22:47:27.240061 E.F.G.H.42125 > A.B.C.D.http: P 17:102(85) > ack 1 win 5840 > > (DF) > > 22:47:27.241273 A.B.C.D.http > E.F.G.H.42125: . ack 102 win > 8659 (DF) > > 22:47:36.520323 E.F.G.H.42125 > A.B.C.D.http: F 102:102(0) > ack 1 win 5840 > > (DF) > > 22:47:36.520495 A.B.C.D.http > E.F.G.H.42125: . ack 103 win > 8659 (DF) > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > > here---><---cut here---> > > > > I believe this means, that there is no problem in > allocating the network > > socket. > > > > So, is there somebody around experiencing the very same > problem and maybe > > has an idea on how to solve it (other then by using the > check_tcp only) ? > > > > > > Thanks a lot for your help! > > > > > > Christoph Stotz > > logo: GmbH > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Nagiosplug-devel mailing list > > Nagiosplug-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > > > -- > > From mikko.kaipila at nic.fi Wed Feb 5 04:32:02 2003 From: mikko.kaipila at nic.fi (Mikko Kaipila) Date: Wed Feb 5 04:32:02 2003 Subject: [Nagiosplug-devel] Nagios_Check_nwstat Message-ID: <1044445560.4647.15.camel@tyly> Hi there! How can I get information of the Netware server's memory state? The MRTGEXT.NLM agent gives only amount of the cache buffers. So, that doesn't help me very much. But I think there is a some means to detect e.g the server's free memory with the help of these "cache variables"...? Or is there some other means? Thanks in advance! From jeremy+nagios at UnderGrid.net Wed Feb 5 06:22:08 2003 From: jeremy+nagios at UnderGrid.net (Jeremy T. Bouse) Date: Wed Feb 5 06:22:08 2003 Subject: [Nagiosplug-devel] check_dns.c: Requires DNS server (patch) In-Reply-To: <1044418851.19831.230.camel@localhost.localdomain> References: <26298-81419@sneakemail.com> <1044418851.19831.230.camel@localhost.localdomain> Message-ID: <20030205142025.GA6410@UnderGrid.net> On Tue, Feb 04, 2003 at 11:20:52PM -0500, Karl DeBisschop wrote: > On Tue, 2003-02-04 at 21:01, Steve Bonds wrote: > > I hate it when I do that. ;-) > > > > It's REALLY attached this time. > > > > -- Steve > > > > On Tue, 4 Feb 2003, Subhendu Ghosh sghosh-at-sghosh.org |Nagios| wrote: > > > > > > > > attached patch??? ;) > > > > > > On Tue, 4 Feb 2003, Steve Bonds wrote: > > > > > > > The attached patch corrects the documentation so that it says the server > > > > is required. > > Thanks for the report. My response to the origianl report was to really > allow operation without specifying a dns server. > > Unless there is an objection, I'd prefer to commit that fix, once I've > tested it. > I would concur Karl... I think it would be best to have the default behavior be to use the systems default server settings if none is provided rather than require the server be specified... One situation I could see here is you have multiple DNS servers (you are a good network operator and run your primary and secondary on seperate machines right?), if you specify only one and it goes down DNS could still be available but not from that server and would thus give you a false impression of the network... I actually have 6 seperate DNS servers on 2 networks consisting of 3 physical locations... Jeremy From noreply at sourceforge.net Wed Feb 5 07:26:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 5 07:26:09 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-680892 ] New plugin: check_cpu (by Dave Winer) Message-ID: Patches item #680892, was opened at 2003-02-05 13:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=680892&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 2 Submitted By: Ton Voon (tonvoon) Assigned to: Ton Voon (tonvoon) Summary: New plugin: check_cpu (by Dave Winer) Initial Comment: This is a new plugin, written by Dave Winer, to check cpu usage on processes. Priority lowered as it is new functionality. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=680892&group_id=29880 From sghosh at sghosh.org Wed Feb 5 07:47:06 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Wed Feb 5 07:47:06 2003 Subject: [Nagiosplug-devel] Nagios_Check_nwstat In-Reply-To: <1044445560.4647.15.camel@tyly> Message-ID: On 5 Feb 2003, Mikko Kaipila wrote: > > Hi there! > > How can I get information of the Netware server's memory state? > > The MRTGEXT.NLM agent gives only amount of the cache buffers. So, that > doesn't help me very much. But I think there is a some means to detect > e.g the server's free memory with the help of these "cache > variables"...? > > Or is there some other means? > > Thanks in advance! > > If you have SNMP - in the HOST-RESOURCES-MIB hrStorageTable find the row containing hrStorageType=hrStorageRam and check the hrStoragesize vs hrStorageUsed -- -sg From noreply at sourceforge.net Thu Feb 6 06:36:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 6 06:36:04 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-681623 ] Patch to return performance data Message-ID: Patches item #681623, was opened at 2003-02-06 12:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=681623&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Edwin Eefting (drpsycho) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to return performance data Initial Comment: Now returns performance data, following the official guidelines. (when checking mulitple disks it returns totals) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=681623&group_id=29880 From noreply at sourceforge.net Thu Feb 6 06:36:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 6 06:36:04 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-681625 ] check_load performance data Message-ID: Patches item #681625, was opened at 2003-02-06 12:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=681625&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Edwin Eefting (drpsycho) Assigned to: Nobody/Anonymous (nobody) Summary: check_load performance data Initial Comment: now returns the official performance data format ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=681625&group_id=29880 From noreply at sourceforge.net Thu Feb 6 06:36:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 6 06:36:05 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-681627 ] check_ping performance data patch Message-ID: Patches item #681627, was opened at 2003-02-06 12:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=681627&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Edwin Eefting (drpsycho) Assigned to: Nobody/Anonymous (nobody) Summary: check_ping performance data patch Initial Comment: returns official performance data ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=681627&group_id=29880 From noreply at sourceforge.net Thu Feb 6 06:36:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 6 06:36:05 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-681679 ] check_procs problem Message-ID: Support Requests item #681679, was opened at 2003-02-06 15:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=681679&group_id=29880 Category: None Group: None Status: Open Priority: 5 Submitted By: Klavs Klavsen (klavs) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs problem Initial Comment: the check_procs command keeps outputting: System call sent warnings to stderr Why is that? IMHO it must be a bug? Thank you for any help removing this annoying message. Best regards, Klavs Klavsen Denmark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=681679&group_id=29880 From pb at bateauknowledge.nl Fri Feb 7 01:47:05 2003 From: pb at bateauknowledge.nl (Paul Boot - Bateau Knowledge) Date: Fri Feb 7 01:47:05 2003 Subject: [Nagiosplug-devel] RE: check_http: Socket timeout after 10 second s (but webserver is up! ) Message-ID: <003801c2ce8d$c6aecbd0$0e01a8c0@wdlft3> I think you have the same problem as I did. Some embedded HTTP servers in wireless-access points (Sitecom WL-006) and print-servers do not respond to HTTP GET requests sent over multiple TCP packets. (or TCP fragments) Here is the bug report I just entered: http://sourceforge.net/tracker/index.php?func=detail&aid=682203&group_id=29880&atid=397597 I have a quick and very dirty work arround. Kind regards, PBO. > Can you try the same command with the -I flag instead of -H. > Still just a guess here, but remember the '-H' sets the hostname, > whereas '-I' does not. The server should either be successful > or give a > 400, so it's for from a sure thing. But maybe worth a try. Ok, I tried that: <---cut here---><---cut here---><---cut here---><---cut here---><---cut here---><---cut here---> spaehfix:/usr/local/nagios # ./libexec/check_http --verbose -H A.B.C.D Socket timeout after 10 seconds spaehfix:/usr/local/nagios # ./libexec/check_http --verbose -I A.B.C.D Socket timeout after 10 seconds spaehfix:/usr/local/nagios # ./libexec/check_http --verbose -I Socket timeout after 10 seconds spaehfix:/usr/local/nagios # ./libexec/check_http --verbose -H Socket timeout after 10 seconds <---cut here---><---cut here---><---cut here---><---cut here---><---cut here---><---cut here---> and again - on the "first Web" on that host, all combinations of IP/FQDN, -H/-I is working without giving any problems. Any further ideas ? Kind Regards, Christoph Stotz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Paul Boot.vcf Type: text/x-vcard Size: 400 bytes Desc: not available URL: From noreply at sourceforge.net Fri Feb 7 20:14:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 7 20:14:01 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-681906 ] check_oracle -h doesn't work Message-ID: Bugs item #681906, was opened at 2003-02-06 12:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=681906&group_id=29880 Category: Argument proccessing Group: v1.0 (example) Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: check_oracle -h doesn't work Initial Comment: check_oracle -h does not display the buildin help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=681906&group_id=29880 From noreply at sourceforge.net Fri Feb 7 20:14:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 7 20:14:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-682203 ] check_http faillure to some embedded HTTP servers Message-ID: Bugs item #682203, was opened at 2003-02-07 01:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=682203&group_id=29880 Category: Interface (example) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: check_http faillure to some embedded HTTP servers Initial Comment: The chech_http plug-in sends an HTTP GET/POST request spread over several TCP datagrams. The socket output buffer is send after the GET / HTTP/1.0 in the header after is send again after the Agent-type and is send again after the Host: part etc.. (multiple socket send () function calls) This results under Linux in several TCP datagrams (packets) per HTTP GET request. Although this is HTTP protocol compliant and works fine with most HTTP servers it fails with some simple embedded HTTP servers found in wireless accesspoints etc. Most browsers and programs like wget send the complete HTTP GET command in one TCP datagram and the simple embedded HTTP servers will handle that fine. (and it's less traffic on the network, better resource usage, better response times etc....) Since I am not a programmer I can not fix this program the correct way. I just hacked my check_http to get it working with loosing some functionality. (which is not what I want to summit to the nagios community) Who can help me fix the check_http plug-in? Kind regards, PBO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=682203&group_id=29880 From noreply at sourceforge.net Fri Feb 7 20:14:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 7 20:14:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-682641 ] make failure solaris 2.6 gnumake 3.80 Message-ID: Bugs item #682641, was opened at 2003-02-07 17:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=682641&group_id=29880 Category: None Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Marc Thompson (botazefa) Assigned to: Nobody/Anonymous (nobody) Summary: make failure solaris 2.6 gnumake 3.80 Initial Comment: nagios-plugins-1.3.0-beta2 I am trying to compile the plugins on a solaris 2.6 Sparc system. I get the following error when running make all. I looked through the bug reports and couldn't find an answer. I presume that this is user error, but would appreciate any help. Thank you. # make -v GNU Make 3.80 # make all Making all in plugins make[1]: Entering directory `/usr/local/src/nagios- plugins-1.3.0-beta2/plugins' gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -I. -I. -I. -I. - I/usr/local/include -g -O2 -c check_disk.c In file included from check_disk.c:34: common.h:104: parse error before `va_list' make[1]: *** [check_disk.o] Error 1 make[1]: Leaving directory `/usr/local/src/nagios-plugins- 1.3.0-beta2/plugins' make: *** [all-recursive] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=682641&group_id=29880 From karl at debisschop.net Fri Feb 7 21:42:03 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Fri Feb 7 21:42:03 2003 Subject: [Nagiosplug-devel] RE: check_http: Socket timeout after 10 second s (but webserver is up! ) In-Reply-To: <003801c2ce8d$c6aecbd0$0e01a8c0@wdlft3> References: <003801c2ce8d$c6aecbd0$0e01a8c0@wdlft3> Message-ID: <1044682827.19429.3.camel@localhost.localdomain> On Fri, 2003-02-07 at 04:46, Paul Boot - Bateau Knowledge wrote: > I think you have the same problem as I did. Some embedded HTTP servers > in wireless-access points (Sitecom WL-006) and print-servers do not > respond to HTTP GET requests sent over multiple TCP packets. (or TCP > fragments) I have just commited a fix which places transfers the request in one send (which does not assure that it will be one packet). Can you test to see if this solves your problems? (use snapshot at www.debisschop.net/src/nagios if you do not have CVS tree) -- Karl > Here is the bug report I just entered: > > http://sourceforge.net/tracker/index.php?func=detail&aid=682203&group_id=29880&atid=397597 > > I have a quick and very dirty work arround. > > Kind regards, > > PBO. > > > > > > Can you try the same command with the -I flag instead of -H. > > Still just a guess here, but remember the '-H' sets the hostname, > > whereas '-I' does not. The server should either be successful > > or give a > > 400, so it's for from a sure thing. But maybe worth a try. > > Ok, I tried that: > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > here---><---cut here---> > spaehfix:/usr/local/nagios # ./libexec/check_http --verbose -H A.B.C.D > Socket timeout after 10 seconds > spaehfix:/usr/local/nagios # ./libexec/check_http --verbose -I A.B.C.D > Socket timeout after 10 seconds > spaehfix:/usr/local/nagios # ./libexec/check_http --verbose -I > > Socket timeout after 10 seconds > spaehfix:/usr/local/nagios # ./libexec/check_http --verbose -H > > Socket timeout after 10 seconds > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > here---><---cut here---> > > and again - on the "first Web" on that host, all combinations of > IP/FQDN, > -H/-I is working without giving any problems. > > Any further ideas ? > > > Kind Regards, > > Christoph Stotz From kdebisschop at alert.infoplease.com Fri Feb 7 22:45:02 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Fri Feb 7 22:45:02 2003 Subject: [Nagiosplug-devel] Looking for debian package maintainer Message-ID: <1044686616.19429.8.camel@localhost.localdomain> I was scanning the debian download tree to find the plugins and see if there were patches in the .deb that should be merged. To my surpirse, I did not see the plugins listed. Is there a current debian maintainer for the plugins? -- Karl DeBisschop Director of Software Development, Infoplease/Pearson Education From pb at bateauknowledge.nl Sat Feb 8 03:18:05 2003 From: pb at bateauknowledge.nl (Paul Boot - Bateau Knowledge) Date: Sat Feb 8 03:18:05 2003 Subject: [Nagiosplug-devel] RE: check_http: Socket timeout after 10 second s (but webserver is up! ) Message-ID: <004e01c2cf63$aea13e70$0e01a8c0@wdlft3> The new check_http "$Revision: 1.21 $" has solved the multiple TCP segments problem and the double cr lf at the end of the GET request. It monitors my humble wireless access-point beautifully! Kind regards, Paul Boot. -------------------------------------------------------------------------- On Fri, 2003-02-07 at 04:46, Paul Boot - Bateau Knowledge wrote: > I think you have the same problem as I did. Some embedded HTTP servers > in wireless-access points (Sitecom WL-006) and print-servers do not > respond to HTTP GET requests sent over multiple TCP packets. (or TCP > fragments) I have just commited a fix which places transfers the request in one send (which does not assure that it will be one packet). Can you test to see if this solves your problems? (use snapshot at http://www.debisschop.net/src/nagios if you do not have CVS tree) -- Karl > Here is the bug report I just entered: > > http://sourceforge.net/tracker/index.php?func=detail&aid=682203&group_id=29880&atid=397597 > > I have a quick and very dirty work arround. > > Kind regards, > > PBO. > > > > > > Can you try the same command with the -I flag instead of -H. > > Still just a guess here, but remember the '-H' sets the hostname, > > whereas '-I' does not. The server should either be successful > > or give a > > 400, so it's for from a sure thing. But maybe worth a try. > > Ok, I tried that: > > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > here---><---cut here---> > spaehfix:/usr/local/nagios # ./libexec/check_http --verbose -H A.B.C.D > Socket timeout after 10 seconds > spaehfix:/usr/local/nagios # ./libexec/check_http --verbose -I A.B.C.D > Socket timeout after 10 seconds > spaehfix:/usr/local/nagios # ./libexec/check_http --verbose -I > > Socket timeout after 10 seconds > spaehfix:/usr/local/nagios # ./libexec/check_http --verbose -H > > Socket timeout after 10 seconds > <---cut here---><---cut here---><---cut here---><---cut > here---><---cut > here---><---cut here---> > > and again - on the "first Web" on that host, all combinations of > IP/FQDN, > -H/-I is working without giving any problems. > > Any further ideas ? > > > Kind Regards, > > Christoph Stotz -------------- next part -------------- An HTML attachment was scrubbed... URL: From stotz at logo.de Sat Feb 8 08:00:03 2003 From: stotz at logo.de (Christoph Stotz) Date: Sat Feb 8 08:00:03 2003 Subject: [Nagiosplug-devel] check_http: Socket timeout after 10 second s (but webserver is up! ) Message-ID: Hello, first of all thank you very much for trying to help. Unfortunately I found out right know, that the problem I am experiencing is not directly caused by the check_http plugin. The whole trouble is caused by the VLAN (802.1q) feature I am using on the monitoring server. For those of you who do not know what that is, you might want to have a look to the following two links. There it's explained quite well: ftp://ftp.netlab.ohio-state.edu/pub/jain/courses/cis788-97/virtual_lans/inde x.htm http://www.candelatech.com/~greear/vlan.html The short version of the explanation is: using VLAN "tagging" you are able to have several "virtual" ethernet devices connected by a single physical ethernet device (of course sharing the available bandwidth). In my case this allows me to monitor different trunks of my network directly without having to pass by a firewall or router. The alternative to that is to mount multiple NIC's (in my case multiple quad-NICs). If you go and have a look to the second link I just posted in this message, you will read "MTU problems exist for many ethernet drivers. Other than that, things seem fairly stable! " Well - that is exactly what I am experiencing. The whole thing is stable, but I am experiencing a MTU-Problem. As soon as the webserver I want to check with check_http is located on a VLAN trunk and returning more than 1476 bytes of data to the check_http, the packet gets either malformed or fragmented. Due to an issue with the ethernet kernel driver, those returning fragments are not put together properly and therefore check_http times out with a Socket error. So, this is an issue for the VLAN mailing list rather than the nagiosplug-devel mailing list. If you experience this problem, the VLAN mailing list located at http://www.wanfear.com/mailman/listinfo/vlan might be a good point to start. By the way I am using a 3c905C-TX/TX-M [Tornado] rev 78 NIC with the 3c59x module version LK1.1.16 (19 July 2001). If I solve the issue, I will let you know how. Thanks again. Kind Regards Christoph Stotz From pb at bateauknowledge.nl Sat Feb 8 10:13:01 2003 From: pb at bateauknowledge.nl (Paul Boot - Bateau Knowledge) Date: Sat Feb 8 10:13:01 2003 Subject: [Nagiosplug-devel] check_http: Socket timeout after 10 seconds (but webserver is up! ) References: Message-ID: <008f01c2cf9d$8bf7c080$0e01a8c0@wdlft3> Non Nagios related but people can benefit from this: I did some test with Linux VLAN tagging with a modified 3com905 ethernet driver and a Cisco 2924XL switch. You have to modify your ethernet driver because the VLAN tagging adds 4 extra bytes to each ethernet PDU.(thus allowing oversize ethernet packets) Recompile the driver as a kernel module or include it in your kernel. You can test if it works with a simple ping. I will send Christoph a word document with all Linux VLAN related documentation I could find. Kind regards, Paul Boot. ----- Original Message ----- From: "Christoph Stotz" To: "'Subhendu Ghosh'" ; ; Cc: Sent: Saturday, February 08, 2003 4:56 PM Subject: RE: [Nagiosplug-devel] check_http: Socket timeout after 10 seconds (but webserver is up! ) > Hello, > > first of all thank you very much for trying to help. Unfortunately I found > out right know, that the problem I am experiencing is not directly caused by > the check_http plugin. The whole trouble is caused by the VLAN (802.1q) > feature I am using on the monitoring server. For those of you who do not > know what that is, you might want to have a look to the following two links. > There it's explained quite well: > > ftp://ftp.netlab.ohio-state.edu/pub/jain/courses/cis788-97/virtual_lans/inde > x.htm > http://www.candelatech.com/~greear/vlan.html > > The short version of the explanation is: using VLAN "tagging" you are able > to have several "virtual" ethernet devices connected by a single physical > ethernet device (of course sharing the available bandwidth). In my case this > allows me to monitor different trunks of my network directly without having > to pass by a firewall or router. The alternative to that is to mount > multiple NIC's (in my case multiple quad-NICs). > > If you go and have a look to the second link I just posted in this message, > you will read > > "MTU problems exist for many ethernet drivers. Other than that, things seem > fairly stable! " > > Well - that is exactly what I am experiencing. The whole thing is stable, > but I am experiencing a MTU-Problem. As soon as the webserver I want to > check with check_http is located on a VLAN trunk and returning more than > 1476 bytes of data to the check_http, the packet gets either malformed or > fragmented. Due to an issue with the ethernet kernel driver, those returning > fragments are not put together properly and therefore check_http times out > with a Socket error. > > So, this is an issue for the VLAN mailing list rather than the > nagiosplug-devel mailing list. If you experience this problem, the VLAN > mailing list located at > > http://www.wanfear.com/mailman/listinfo/vlan > > might be a good point to start. By the way I am using a 3c905C-TX/TX-M > [Tornado] rev 78 NIC with the 3c59x module version LK1.1.16 (19 July 2001). > > > If I solve the issue, I will let you know how. > > > Thanks again. > > > Kind Regards > > Christoph Stotz > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > From stotz at logo.de Sat Feb 8 13:57:04 2003 From: stotz at logo.de (Christoph Stotz) Date: Sat Feb 8 13:57:04 2003 Subject: [Nagiosplug-devel] check_http: Socket timeout after 10 second s (but webserver is up! ) Message-ID: Hello again, thanks to Pauls great help, everything is working now. I used the patch located at http://www.myipv6.de/patches/vlan/3c59x.c-8021q.patch In order to be able to apply it I removed some comment lines. Then the patch worked perfectly. Thanks again & cheers! Christoph > -----Original Message----- > From: Christoph Stotz > Sent: Samstag, 8. Februar 2003 16:56 > To: 'Subhendu Ghosh'; 'pb at bateauknowledge.nl'; 'karl at debisschop.net' > Cc: 'nagiosplug-devel at lists.sourceforge.net' > Subject: RE: [Nagiosplug-devel] check_http: Socket timeout > after 10 seconds (but webserver is up! ) > > > Hello, > > first of all thank you very much for trying to help. > Unfortunately I found out right know, that the problem I am > experiencing is not directly caused by the check_http plugin. > The whole trouble is caused by the VLAN (802.1q) feature I am > using on the monitoring server. For those of you who do not > know what that is, you might want to have a look to the > following two links. There it's explained quite well: > ftp://ftp.netlab.ohio-state.edu/pub/jain/courses/cis788-97/virtual_lans/inde x.htm http://www.candelatech.com/~greear/vlan.html The short version of the explanation is: using VLAN "tagging" you are able to have several "virtual" ethernet devices connected by a single physical ethernet device (of course sharing the available bandwidth). In my case this allows me to monitor different trunks of my network directly without having to pass by a firewall or router. The alternative to that is to mount multiple NIC's (in my case multiple quad-NICs). If you go and have a look to the second link I just posted in this message, you will read "MTU problems exist for many ethernet drivers. Other than that, things seem fairly stable! " Well - that is exactly what I am experiencing. The whole thing is stable, but I am experiencing a MTU-Problem. As soon as the webserver I want to check with check_http is located on a VLAN trunk and returning more than 1476 bytes of data to the check_http, the packet gets either malformed or fragmented. Due to an issue with the ethernet kernel driver, those returning fragments are not put together properly and therefore check_http times out with a Socket error. So, this is an issue for the VLAN mailing list rather than the nagiosplug-devel mailing list. If you experience this problem, the VLAN mailing list located at http://www.wanfear.com/mailman/listinfo/vlan might be a good point to start. By the way I am using a 3c905C-TX/TX-M [Tornado] rev 78 NIC with the 3c59x module version LK1.1.16 (19 July 2001). If I solve the issue, I will let you know how. Thanks again. Kind Regards Christoph Stotz From noreply at sourceforge.net Sun Feb 9 03:13:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 9 03:13:08 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-683235 ] check_snmp doesn't pass -t argument Message-ID: Bugs item #683235, was opened at 2003-02-08 19:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=683235&group_id=29880 Category: Argument proccessing Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp doesn't pass -t argument Initial Comment: The check_snmp plugin doesn't pass the -t (timeout) argument to snmpget. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=683235&group_id=29880 From sghosh at sghosh.org Sun Feb 9 03:30:04 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Sun Feb 9 03:30:04 2003 Subject: [Nagiosplug-devel] test message Message-ID: Test message for new footer :) -- From kdebisschop at alert.infoplease.com Sun Feb 9 04:09:05 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Sun Feb 9 04:09:05 2003 Subject: [Nagiosplug-devel] Nearly time for next (last) beta? Message-ID: <1044792443.25166.7.camel@localhost.localdomain> I'd like to propose a beta for release on 18-19 Feb 2003. My reasoning is a) we are near ready b) some of us in the US will have that day off, making a few more hands available for bug fixes, etc (Sorry to be parochial, but it does mean I will have more time available than I usually do) Is that a reasonable schedule to shoot for? I would further suggest that will be the last beta, and if we don't turn up many issues, I'd tentatively expect a release candidate about a week later. -- Karl DeBisschop Director of Software Development, Infoplease/Pearson Education From sghosh at sghosh.org Sun Feb 9 04:44:09 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Sun Feb 9 04:44:09 2003 Subject: [Nagiosplug-devel] Nearly time for next (last) beta? In-Reply-To: <1044792443.25166.7.camel@localhost.localdomain> Message-ID: Good target date. I have a couple of more issues to check on check_snmp. There is a configure issue with swap on HP-UX that I am investigating - will see if that fix going for 1.3 or waits for a post 1.3 release. -sg On 9 Feb 2003, Karl DeBisschop wrote: > I'd like to propose a beta for release on 18-19 Feb 2003. > > My reasoning is > > a) we are near ready > > b) some of us in the US will have that day off, making a few more hands > available for bug fixes, etc (Sorry to be parochial, but it does mean I > will have more time available than I usually do) > > Is that a reasonable schedule to shoot for? > > I would further suggest that will be the last beta, and if we don't turn > up many issues, I'd tentatively expect a release candidate about a week > later. > > -- From sghosh at sghosh.org Sun Feb 9 06:48:03 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Sun Feb 9 06:48:03 2003 Subject: [Nagiosplug-devel] install directory structure... Message-ID: Looking at the post 1.3 releases, I was thinking of adding a "lib" and a "tmp" subdir to the default plugins install dir. lib - would contain any common files - util.pm, utils.sh, some of the proposed perl modules. tmp - would provide some temporary cach space for plugins that want to maintain their own state between invocations. Any thought/comments. -- -sg From Ton.Voon at egg.com Sun Feb 9 08:00:04 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Sun Feb 9 08:00:04 2003 Subject: [Nagiosplug-devel] Nearly time for next (last) beta? Message-ID: <53104E20A25CD411B556009027E50636064D5295@pnnemp02.pn.egg.com> I've had a couple of reports re: compiling on Tru64 and Open Unix 8.0 which I think are down to getopt_long. I was thinking of changing the automake files for using the getopt_long library by mimicking how gnutar does it. My worries are: 1) breaking it 2) should it be left till 1.4 For (1), I've found out about sourceforge's compile farm where they have about 6 different OSes available to compile against, so I can verify the changes there before commiting. Any advice? -----Original Message----- From: Subhendu Ghosh [mailto:sghosh at sghosh.org] Sent: Sunday, February 09, 2003 12:42 PM To: nagiosplug-devel at lists.sourceforge.net Subject: Re: [Nagiosplug-devel] Nearly time for next (last) beta? Good target date. I have a couple of more issues to check on check_snmp. There is a configure issue with swap on HP-UX that I am investigating - will see if that fix going for 1.3 or waits for a post 1.3 release. -sg On 9 Feb 2003, Karl DeBisschop wrote: > I'd like to propose a beta for release on 18-19 Feb 2003. > > My reasoning is > > a) we are near ready > > b) some of us in the US will have that day off, making a few more hands > available for bug fixes, etc (Sorry to be parochial, but it does mean I > will have more time available than I usually do) > > Is that a reasonable schedule to shoot for? > > I would further suggest that will be the last beta, and if we don't turn > up many issues, I'd tentatively expect a release candidate about a week > later. > > -- ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Nagiosplug-devel mailing list Nagiosplug-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From pb at bateauknowledge.nl Sun Feb 9 12:40:07 2003 From: pb at bateauknowledge.nl (Paul Boot - Bateau Knowledge) Date: Sun Feb 9 12:40:07 2003 Subject: [Nagiosplug-devel] Nearly time for next (last) beta? References: <1044792443.25166.7.camel@localhost.localdomain> Message-ID: <004101c2d07b$6405ed20$0e01a8c0@wdlft3> I could do some more testing. Are there any plug-ins that need more specific testing? Kind regards, Paul Boot. ----- Original Message ----- From: "Karl DeBisschop" To: Sent: Sunday, February 09, 2003 1:07 PM Subject: [Nagiosplug-devel] Nearly time for next (last) beta? > I'd like to propose a beta for release on 18-19 Feb 2003. > > My reasoning is > > a) we are near ready > > b) some of us in the US will have that day off, making a few more hands > available for bug fixes, etc (Sorry to be parochial, but it does mean I > will have more time available than I usually do) > > Is that a reasonable schedule to shoot for? > > I would further suggest that will be the last beta, and if we don't turn > up many issues, I'd tentatively expect a release candidate about a week > later. > > -- > Karl DeBisschop > Director of Software Development, Infoplease/Pearson Education > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > From karl at debisschop.net Sun Feb 9 21:47:02 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Sun Feb 9 21:47:02 2003 Subject: [Nagiosplug-devel] Nearly time for next (last) beta? In-Reply-To: <53104E20A25CD411B556009027E50636064D5295@pnnemp02.pn.egg.com> References: <53104E20A25CD411B556009027E50636064D5295@pnnemp02.pn.egg.com> Message-ID: <1044855882.2943.17.camel@localhost.localdomain> On Sun, 2003-02-09 at 10:59, Voon, Ton wrote: > I've had a couple of reports re: compiling on Tru64 and Open Unix 8.0 which > I think are down to getopt_long. I was thinking of changing the automake > files for using the getopt_long library by mimicking how gnutar does it. My > worries are: > 1) breaking it > 2) should it be left till 1.4 > > For (1), I've found out about sourceforge's compile farm where they have > about 6 different OSes available to compile against, so I can verify the > changes there before commiting. > > Any advice? If you think you can make it work right, let's go for it. Give a heads up when you commit, and I'll make sure I test it as well as I can. -- Karl From russell at quadrix.com Mon Feb 10 10:49:05 2003 From: russell at quadrix.com (Russell Scibetti) Date: Mon Feb 10 10:49:05 2003 Subject: [Nagiosplug-devel] Plugins patches Message-ID: <3E47F3D1.8030607@quadrix.com> I sent these to the list a while ago and haven't seen anything checked in. Please take a look at these. They are based on the 1.3b2 release. check_tcp: Fixed problem with the plugin not checking the default expect strings for various service types. Also changed the check_pop expect string to "+OK". It was "220", which means nothing for POP. You need to get a +OK to know POP is responding. check_dns: Fixed a problem where the plugin was trying to read more args from the argv array without first checking to see if there were anymore (caused segfault). This whole section, designed to allow users to pass the hostname to lookup and the dns server to use without using the proper -H and -s tags, should probably be removed. Force the users to stick to the plugin-defined structure and standards. Hope these help! Let me know if there is anything else I can do to help the project. I have mentioned previously about doing work for Solaris build (2.6 and 8). We are almost done setting up development environments for both OS's here, so if you need help in that area, please just let me know. Thanks. Russell Scibetti -- Russell Scibetti Quadrix Solutions, Inc. http://www.quadrix.com (732) 235-2335, ext. 7038 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: checktcp-diff.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: checkdns_diff.patch URL: From sghosh at sghosh.org Mon Feb 10 11:15:03 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Feb 10 11:15:03 2003 Subject: [Nagiosplug-devel] Plugins patches In-Reply-To: <3E47F3D1.8030607@quadrix.com> Message-ID: I'll work on these.. I think some of it may already be in. use the sourceforge patch list next time.. ;) -sg On Mon, 10 Feb 2003, Russell Scibetti wrote: > I sent these to the list a while ago and haven't seen anything checked > in. Please take a look at these. They are based on the 1.3b2 release. > > check_tcp: > > Fixed problem with the plugin not checking the default expect strings > for various service types. Also changed the check_pop expect string to > "+OK". It was "220", which means nothing for POP. You need to get a > +OK to know POP is responding. > > check_dns: > > Fixed a problem where the plugin was trying to read more args from the > argv array without first checking to see if there were anymore (caused > segfault). This whole section, designed to allow users to pass the > hostname to lookup and the dns server to use without using the proper -H > and -s tags, should probably be removed. Force the users to stick to > the plugin-defined structure and standards. > > Hope these help! Let me know if there is anything else I can do to help > the project. I have mentioned previously about doing work for Solaris > build (2.6 and 8). We are almost done setting up development > environments for both OS's here, so if you need help in that area, > please just let me know. Thanks. > > Russell Scibetti > > -- From jeremy+nagios at UnderGrid.net Mon Feb 10 11:38:04 2003 From: jeremy+nagios at UnderGrid.net (Jeremy T. Bouse) Date: Mon Feb 10 11:38:04 2003 Subject: [Nagiosplug-devel] Standard output from plugins Message-ID: <20030210193628.GB7105@UnderGrid.net> I've been looking through the plugin documentation on the web site trying to determine the way responses should be as I find a lot of the plugins do not give a standardized reply back... I find some just give back the reply as the output from the error: $ ./check_pop -H some.host.domain <- host isn't runnin POP Connection refused by host $ ./check_dns www.yakoo.com <- Use any non-exist host CRITICAL - Plugin timed out after 10 seconds I also find subtle differences like "ok" or "ok:" rather than "OK"... Using mixed capitals for OK or UNKNOWN but using lowercase for critical or warning... Also those that just list the state vs. others that identify the plugin then the state: CRITICAL - Plugin timed out after 10 seconds vs. HTTP OK HTTP/1.1 200 OK - 0.268 second response time |time=0.268 I've been looking through and trying to work to make the plugins all give some standardized reply back but can't really find any clear cut verdict as to what should be standard... I've also found a few plugins which don't actually return the proper return code (check_ssh was one I've fixed) as they always returned STATE_OK no matter what the actual output from the plugin stated... Although this is only cosmetic really I think it would be a good idea to get this cleaned up now rather than later if there isn't any valid reason to not do so... I'm even willing to spend my time doing so rather than task it out to someone else... Jeremy From sean.knox at sbcglobal.net Mon Feb 10 12:05:24 2003 From: sean.knox at sbcglobal.net (Sean Knox) Date: Mon Feb 10 12:05:24 2003 Subject: [Nagiosplug-devel] Looking for debian package maintainer In-Reply-To: <1044686616.19429.8.camel@localhost.localdomain> References: <1044686616.19429.8.camel@localhost.localdomain> Message-ID: <3E48057C.6070604@sbcglobal.net> Hi Karl, I don't know if you ever got a response. The Debian package maintainer is Turbo Fredriksson (turbo at debian.org). You can always view the maintainer of a particular package by visiting http://packages.debian.org and searching for the package. Sean Karl DeBisschop wrote: >I was scanning the debian download tree to find the plugins and see if >there were patches in the .deb that should be merged. To my surpirse, I >did not see the plugins listed. > >Is there a current debian maintainer for the plugins? > > > From kdebisschop at alert.infoplease.com Mon Feb 10 12:12:14 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Mon Feb 10 12:12:14 2003 Subject: [Nagiosplug-devel] Looking for debian package maintainer In-Reply-To: <3E48057C.6070604@sbcglobal.net> References: <1044686616.19429.8.camel@localhost.localdomain> <3E48057C.6070604@sbcglobal.net> Message-ID: <1044907848.11871.32.camel@nh--1614-2.nh.pearsoned.com> On Mon, 2003-02-10 at 15:03, Sean Knox wrote: > Hi Karl, I don't know if you ever got a response. The Debian package > maintainer is Turbo Fredriksson (turbo at debian.org). You can always view > the maintainer of a particular package by visiting > http://packages.debian.org and searching for the package. No, I hadn't gotten one. Thanks. -- Karl DeBisschop Pearson Education/Information Please From jeremy+nagios at UnderGrid.net Mon Feb 10 13:44:04 2003 From: jeremy+nagios at UnderGrid.net (Jeremy T. Bouse) Date: Mon Feb 10 13:44:04 2003 Subject: [Nagiosplug-devel] Looking for debian package maintainer In-Reply-To: <1044907848.11871.32.camel@nh--1614-2.nh.pearsoned.com> References: <1044686616.19429.8.camel@localhost.localdomain> <3E48057C.6070604@sbcglobal.net> <1044907848.11871.32.camel@nh--1614-2.nh.pearsoned.com> Message-ID: <20030210214211.GA9967@UnderGrid.net> I thought I had sent you a message privately Karl regarding the information I had received from Turbo... I had been in contact with him for awhile to inquire about his progress on both the nagios and plugin packages awhile back... His main thing was that he hadn't seen any stable release specific to nagios yet so he was still pointing people to the netsaint plugin package and had set the dependency for nagios to use the netsaint-plugin package... Jeremy On Mon, Feb 10, 2003 at 03:10:48PM -0500, Karl DeBisschop wrote: > On Mon, 2003-02-10 at 15:03, Sean Knox wrote: > > Hi Karl, I don't know if you ever got a response. The Debian package > > maintainer is Turbo Fredriksson (turbo at debian.org). You can always view > > the maintainer of a particular package by visiting > > http://packages.debian.org and searching for the package. > > No, I hadn't gotten one. > > Thanks. > > -- > Karl DeBisschop > Pearson Education/Information Please > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From sghosh at sghosh.org Mon Feb 10 13:58:14 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Feb 10 13:58:14 2003 Subject: [Nagiosplug-devel] Standard output from plugins In-Reply-To: <20030210193628.GB7105@UnderGrid.net> Message-ID: my 2 centimes Prefix all output with "STATE:" preferably in uppercase. I'd rather not append the plugin "type" (eg. HTTP/SNMP/etc) as a general rule. But it is useful for some. "Plugin timed out after 10 seconds" << some of this is from Nagios For the timeout within the plugins follow above. On Mon, 10 Feb 2003, Jeremy T. Bouse wrote: > I've been looking through the plugin documentation on the web > site trying to determine the way responses should be as I find a lot of > the plugins do not give a standardized reply back... I find some just > give back the reply as the output from the error: > > $ ./check_pop -H some.host.domain <- host isn't runnin POP > Connection refused by host > > $ ./check_dns www.yakoo.com <- Use any non-exist host > CRITICAL - Plugin timed out after 10 seconds > > I also find subtle differences like "ok" or "ok:" rather than > "OK"... Using mixed capitals for OK or UNKNOWN but using lowercase for > critical or warning... Also those that just list the state vs. others > that identify the plugin then the state: > > CRITICAL - Plugin timed out after 10 seconds > > vs. > > HTTP OK HTTP/1.1 200 OK - 0.268 second response time |time=0.268 > > I've been looking through and trying to work to make the > plugins all give some standardized reply back but can't really find any > clear cut verdict as to what should be standard... I've also found a few > plugins which don't actually return the proper return code (check_ssh > was one I've fixed) as they always returned STATE_OK no matter what the > actual output from the plugin stated... > > Although this is only cosmetic really I think it would be a > good idea to get this cleaned up now rather than later if there isn't > any valid reason to not do so... I'm even willing to spend my time doing > so rather than task it out to someone else... > > Jeremy > > -- From tonvoon at mac.com Mon Feb 10 15:24:04 2003 From: tonvoon at mac.com (Ton Voon) Date: Mon Feb 10 15:24:04 2003 Subject: [Nagiosplug-devel] Changes to build for getopts Message-ID: <69229E9A-3D4E-11D7-A4AD-000A27E41300@mac.com> Just to warn that I am about to commit changes to CVS for the change to building getopt, so it is more like gnutar. I've also updated the getopt files from the latest stable gnu libraries. I've tested it on my Mac OS X box, and also tested it on sourceforge's compile farm of Linux 2.4 (Debian 2.2 & Redhat 7.3), Linux 2.2 (Debian 3.0), FreeBSD 4.7 and Sun Solaris 8, and they all work with no compile errors. (There is a: check_http.c: In function `connect_SSL': check_http.c:869: warning: passing arg 1 of `asprintf' from incompatible pointer type but I assume it is not me!) There should be no need to have ifdefs for HAVE_GETOPT_H anymore as it will always be available. Let me know if you hit any problems. From karl at debisschop.net Mon Feb 10 20:58:04 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Mon Feb 10 20:58:04 2003 Subject: [Nagiosplug-devel] Plugins patches In-Reply-To: References: Message-ID: <1044939371.6329.4.camel@localhost.localdomain> On Mon, 2003-02-10 at 14:13, Subhendu Ghosh wrote: > I'll work on these.. I think some of it may already be in. I hope you will find they are all in. I do recall implementing them. If they are not all in, then I goofed. -- Karl > use the sourceforge patch list next time.. ;) > > -sg > > On Mon, 10 Feb 2003, Russell Scibetti wrote: > > > I sent these to the list a while ago and haven't seen anything checked > > in. Please take a look at these. They are based on the 1.3b2 release. > > > > check_tcp: > > > > Fixed problem with the plugin not checking the default expect strings > > for various service types. Also changed the check_pop expect string to > > "+OK". It was "220", which means nothing for POP. You need to get a > > +OK to know POP is responding. > > > > check_dns: > > > > Fixed a problem where the plugin was trying to read more args from the > > argv array without first checking to see if there were anymore (caused > > segfault). This whole section, designed to allow users to pass the > > hostname to lookup and the dns server to use without using the proper -H > > and -s tags, should probably be removed. Force the users to stick to > > the plugin-defined structure and standards. > > > > Hope these help! Let me know if there is anything else I can do to help > > the project. I have mentioned previously about doing work for Solaris > > build (2.6 and 8). We are almost done setting up development > > environments for both OS's here, so if you need help in that area, > > please just let me know. Thanks. > > > > Russell Scibetti > > > > From karl at debisschop.net Mon Feb 10 21:00:04 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Mon Feb 10 21:00:04 2003 Subject: [Nagiosplug-devel] Standard output from plugins In-Reply-To: <20030210193628.GB7105@UnderGrid.net> References: <20030210193628.GB7105@UnderGrid.net> Message-ID: <1044939496.6329.7.camel@localhost.localdomain> On Mon, 2003-02-10 at 14:36, Jeremy T. Bouse wrote: > I've been looking through the plugin documentation on the web > site trying to determine the way responses should be as I find a lot of > the plugins do not give a standardized reply back... I find some just > give back the reply as the output from the error: > > $ ./check_pop -H some.host.domain <- host isn't runnin POP > Connection refused by host > > $ ./check_dns www.yakoo.com <- Use any non-exist host > CRITICAL - Plugin timed out after 10 seconds > > I also find subtle differences like "ok" or "ok:" rather than > "OK"... Using mixed capitals for OK or UNKNOWN but using lowercase for > critical or warning... Also those that just list the state vs. others > that identify the plugin then the state: > > CRITICAL - Plugin timed out after 10 seconds > > vs. > > HTTP OK HTTP/1.1 200 OK - 0.268 second response time |time=0.268 > > I've been looking through and trying to work to make the > plugins all give some standardized reply back but can't really find any > clear cut verdict as to what should be standard... I've also found a few > plugins which don't actually return the proper return code (check_ssh > was one I've fixed) as they always returned STATE_OK no matter what the > actual output from the plugin stated... > > Although this is only cosmetic really I think it would be a > good idea to get this cleaned up now rather than later if there isn't > any valid reason to not do so... I'm even willing to spend my time doing > so rather than task it out to someone else... If it's cosmetic, should we do it during a feature freeze before what we hope will be our last beta? -- Karl From sghosh at sghosh.org Mon Feb 10 21:02:07 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Feb 10 21:02:07 2003 Subject: [Nagiosplug-devel] Plugins patches In-Reply-To: <1044939371.6329.4.camel@localhost.localdomain> Message-ID: They are all in place... no goofs :) -sg On 10 Feb 2003, Karl DeBisschop wrote: > On Mon, 2003-02-10 at 14:13, Subhendu Ghosh wrote: > > I'll work on these.. I think some of it may already be in. > > I hope you will find they are all in. I do recall implementing them. If > they are not all in, then I goofed. > > -- > Karl > > > use the sourceforge patch list next time.. ;) > > > > -sg > > > > On Mon, 10 Feb 2003, Russell Scibetti wrote: > > > > > I sent these to the list a while ago and haven't seen anything checked > > > in. Please take a look at these. They are based on the 1.3b2 release. > > > > > > check_tcp: > > > > > > Fixed problem with the plugin not checking the default expect strings > > > for various service types. Also changed the check_pop expect string to > > > "+OK". It was "220", which means nothing for POP. You need to get a > > > +OK to know POP is responding. > > > > > > check_dns: > > > > > > Fixed a problem where the plugin was trying to read more args from the > > > argv array without first checking to see if there were anymore (caused > > > segfault). This whole section, designed to allow users to pass the > > > hostname to lookup and the dns server to use without using the proper -H > > > and -s tags, should probably be removed. Force the users to stick to > > > the plugin-defined structure and standards. > > > > > > Hope these help! Let me know if there is anything else I can do to help > > > the project. I have mentioned previously about doing work for Solaris > > > build (2.6 and 8). We are almost done setting up development > > > environments for both OS's here, so if you need help in that area, > > > please just let me know. Thanks. > > > > > > Russell Scibetti > > > > > > > -- From sghosh at sghosh.org Mon Feb 10 21:08:06 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Feb 10 21:08:06 2003 Subject: [Nagiosplug-devel] Standard output from plugins In-Reply-To: <1044939496.6329.7.camel@localhost.localdomain> Message-ID: On 10 Feb 2003, Karl DeBisschop wrote: > On Mon, 2003-02-10 at 14:36, Jeremy T. Bouse wrote: > > I've been looking through the plugin documentation on the web > > site trying to determine the way responses should be as I find a lot of > > the plugins do not give a standardized reply back... I find some just > > give back the reply as the output from the error: > > > > $ ./check_pop -H some.host.domain <- host isn't runnin POP > > Connection refused by host > > > > $ ./check_dns www.yakoo.com <- Use any non-exist host > > CRITICAL - Plugin timed out after 10 seconds > > > > I also find subtle differences like "ok" or "ok:" rather than > > "OK"... Using mixed capitals for OK or UNKNOWN but using lowercase for > > critical or warning... Also those that just list the state vs. others > > that identify the plugin then the state: > > > > CRITICAL - Plugin timed out after 10 seconds > > > > vs. > > > > HTTP OK HTTP/1.1 200 OK - 0.268 second response time |time=0.268 > > > > I've been looking through and trying to work to make the > > plugins all give some standardized reply back but can't really find any > > clear cut verdict as to what should be standard... I've also found a few > > plugins which don't actually return the proper return code (check_ssh > > was one I've fixed) as they always returned STATE_OK no matter what the > > actual output from the plugin stated... > > > > Although this is only cosmetic really I think it would be a > > good idea to get this cleaned up now rather than later if there isn't > > any valid reason to not do so... I'm even willing to spend my time doing > > so rather than task it out to someone else... > > > If it's cosmetic, should we do it during a feature freeze before what we > hope will be our last beta? > Didn't we already freeze? -- -sg From karl at debisschop.net Mon Feb 10 21:14:07 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Mon Feb 10 21:14:07 2003 Subject: [Nagiosplug-devel] Looking for debian package maintainer In-Reply-To: <20030210214211.GA9967@UnderGrid.net> References: <1044686616.19429.8.camel@localhost.localdomain> <3E48057C.6070604@sbcglobal.net> <1044907848.11871.32.camel@nh--1614-2.nh.pearsoned.com> <20030210214211.GA9967@UnderGrid.net> Message-ID: <1044940339.6329.20.camel@localhost.localdomain> On Mon, 2003-02-10 at 16:42, Jeremy T. Bouse wrote: > I thought I had sent you a message privately Karl regarding the > information I had received from Turbo... I had been in contact with him > for awhile to inquire about his progress on both the nagios and plugin > packages awhile back... His main thing was that he hadn't seen any > stable release specific to nagios yet so he was still pointing people to > the netsaint plugin package and had set the dependency for nagios to use > the netsaint-plugin package... Ah. Yes you had. I had forgotten all except the tickle in the back of my head that I needed to close that loop. That also explains why all my searches on 'nagios plugin' come up empty. Thanks. -- Karl > Jeremy > > On Mon, Feb 10, 2003 at 03:10:48PM -0500, Karl DeBisschop wrote: > > On Mon, 2003-02-10 at 15:03, Sean Knox wrote: > > > Hi Karl, I don't know if you ever got a response. The Debian package > > > maintainer is Turbo Fredriksson (turbo at debian.org). You can always view > > > the maintainer of a particular package by visiting > > > http://packages.debian.org and searching for the package. > > > > No, I hadn't gotten one. > > > > Thanks. > > > > -- > > Karl DeBisschop > > Pearson Education/Information Please > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Nagiosplug-devel mailing list > > Nagiosplug-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > ::: Please include plugins version (-v) and OS when reporting any issue. > > ::: Messages without supporting info will risk being sent to /dev/null > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From noreply at sourceforge.net Tue Feb 11 06:29:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 11 06:29:07 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-684574 ] check_dns Segmentation fault Debian Message-ID: Bugs item #684574, was opened at 2003-02-11 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=684574&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eduardo Diaz (ediaz) Assigned to: Nobody/Anonymous (nobody) Summary: check_dns Segmentation fault Debian Initial Comment: this is the trace, is a debian woodie 3.0 and 2.4.20 kernel ervidor1:/programas/nagios/src/nagios-plugins- 1.3.0-beta2/plugins# strace ./check_dns -H localhost execve("./check_dns", ["./check_dns", "-H", "localhost"], [/* 13 vars */]) = 0 uname({sys="Linux", node="servidor1", ...}) = 0 brk(0) = 0x804ccc8 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=34789, ...}) = 0 old_mmap(NULL, 34789, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000 close(3) = 0 open("/lib/libutil.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\16"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0644, st_size=7600, ...}) = 0 old_mmap(NULL, 10568, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001d000 mprotect(0x4001f000, 2376, PROT_NONE) = 0 old_mmap(0x4001f000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x4001f000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\30\222"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0 old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40020000 mprotect(0x40133000, 40160, PROT_NONE) = 0 old_mmap(0x40133000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x113000) = 0x40133000 old_mmap(0x40139000, 15584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40139000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4013d000 munmap(0x40014000, 34789) = 0 rt_sigaction(SIGALRM, {0x804a678, [ALRM], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ servidor1:/programas/nagios/src/nagios-plugins-1.3.0- beta2/plugins# ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=684574&group_id=29880 From noreply at sourceforge.net Tue Feb 11 10:51:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 11 10:51:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-684818 ] check_ntp regex for ntpq fails for stratum1 peer Message-ID: Patches item #684818, was opened at 2003-02-11 13:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=684818&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Subhendu Ghosh (sghosh) Assigned to: Subhendu Ghosh (sghosh) Summary: check_ntp regex for ntpq fails for stratum1 peer Initial Comment: Check_ntp (v1.12) fails to recognize the refid of a Stratum 1 peer. Need top patch line 254 to recognize WWV/PPS/GPS in addition to ip addresses. >From - "Michael Jewett" > ./check_ntp -H xxx.xxx.xxx.xxx -v > server xxx.xxx.xxx.xxx, stratum 2, offset 0.005577, delay 0.02592 > ntperr = 0 > 11 Feb 14:06:39 ntpdate[11392]: adjust time server 131.202.3.20 offset > 0.005577 sec > ntperr = 0 > remote refid st t when poll reach delay offset > jitter > ============================================================================ > == > 192.68.54.20 0.0.0.0 16 - - 1024 0 0.000 0.000 > 16000.0 > 198.164.163.107 0.0.0.0 16 - - 1024 0 0.000 0.000 > 16000.0 > x128.118.46.3 .WWV. 1 u 510 1024 377 79.120 -36.329 > 1.130 > +128.118.25.3 192.5.41.209 2 u 470 1024 377 79.150 -0.815 > 0.980 > Candiate count= 1 > 129.116.3.5 0.0.0.0 16 - - 1024 0 0.000 0.000 > 16000.0 > yyy.yyy.yyy.yyy 0.0.0.0 16 - - 1024 0 0.000 0.000 > 16000.0 > 132.246.168.80 0.0.0.0 16 - - 1024 0 0.000 0.000 > 16000.0 > +132.246.168.2 .PPS. 1 u 851 1024 377 25.010 -0.283 > 0.200 > Candiate count= 2 > *132.246.168.3 .PPS. 1 u 216 1024 377 24.980 -0.554 > 0.240 > Candiate count= 3 > Use of uninitialized value at ./check_ntp line 297. > UNKNOWN: Jitter too high ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=684818&group_id=29880 From noreply at sourceforge.net Tue Feb 11 14:40:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 11 14:40:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-684948 ] check_mysql segfaults on RedHat 8.0 Message-ID: Bugs item #684948, was opened at 2003-02-11 14:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=684948&group_id=29880 Category: None Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: check_mysql segfaults on RedHat 8.0 Initial Comment: Using nagios-plugins-1.3.0-beta2 on RedHat 8.0 (kernel 2.4.18-14smp) Plugins configured with: --with-openssl --with-mysql-lib=/usr/lib/mysql --with-mysql-inc=/usr/include/mysql MySQL-3.23.49a-1, MySQL-client-3.23.49a-1, MySQL- devel-3.23.49a-1 rpms installed (binary packages provided by MySQL AB) strace of check_mysql attached. Submitted by mcp AT vindigo.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=684948&group_id=29880 From Brian.Ipsen at andebakken.dk Wed Feb 12 10:05:06 2003 From: Brian.Ipsen at andebakken.dk (Brian Ipsen) Date: Wed Feb 12 10:05:06 2003 Subject: [Nagiosplug-devel] Daily Snapshot ? Message-ID: Hi! What happened to the snapshot normally available at http://nagiosplug.sourceforge.net/snapshot/ ?? Another thing is, that I tried to do a checkout via CVS of the nagiosplug sources - but the configure file is not present (or is it generated from configure.in by running automake or any other tools) ?? Regards, /Brian From Brian.Ipsen at andebakken.dk Wed Feb 12 10:54:06 2003 From: Brian.Ipsen at andebakken.dk (Brian Ipsen) Date: Wed Feb 12 10:54:06 2003 Subject: [Nagiosplug-devel] Daily Snapshot ? In-Reply-To: Message-ID: Hi, > What happened to the snapshot normally available at > http://nagiosplug.sourceforge.net/snapshot/ ?? Another thing is, that I > tried to do a checkout via CVS of the nagiosplug sources - but > the configure file is not present (or is it generated from > configure.in by running automake or any other tools) ?? Found the solution: aclocal autoconf autoheader automake That gives me configure and (maybe) all other needed files. But how should the nagios-plugins.spec.in file be translated into nagios-plugins.spec ?? Regards, /Brian From kdebisschop at mail.debisschop.net Wed Feb 12 13:25:07 2003 From: kdebisschop at mail.debisschop.net (Karl DeBisschop) Date: Wed Feb 12 13:25:07 2003 Subject: [Nagiosplug-devel] Re: Daily Snapshot ? In-Reply-To: References: Message-ID: Brian Ipsen writes: > Hi, > >> What happened to the snapshot normally available at >> http://nagiosplug.sourceforge.net/snapshot/ ?? Another thing is, that I >> tried to do a checkout via CVS of the nagiosplug sources - but >> the configure file is not present (or is it generated from >> configure.in by running automake or any other tools) ?? > > Found the solution: > > aclocal > autoconf > autoheader > automake Also known as ./tools/setup and described in step 0 of INSTALL > > That gives me configure and (maybe) all other needed files. But how should > the nagios-plugins.spec.in file be translated into nagios-plugins.spec ?? see step 1 -- ./configure > Regards, > > /Brian > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From mcp at jawfish.com Wed Feb 12 14:46:09 2003 From: mcp at jawfish.com (Marc C. Poulin) Date: Wed Feb 12 14:46:09 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-684818 ] check_ntp regex for ntpq fails for stratum1 peer In-Reply-To: References: Message-ID: <62751.208.185.41.103.1045089924.squirrel@www.jawfish.com> I also see refids of .USNO. (tick.usno.navy.mil) and .ACTS. (time-b.nist.gov) for stratum 1 servers (- these should probably be added to the regex. Thanks, Marc SourceForge.net said: > Patches item #684818, was opened at 2003-02-11 13:54 > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=397599&aid=684818&group_id=29880 > > Category: None > Group: None > Status: Open > Resolution: None > Priority: 7 > Submitted By: Subhendu Ghosh (sghosh) > Assigned to: Subhendu Ghosh (sghosh) > Summary: check_ntp regex for ntpq fails for stratum1 peer > > Initial Comment: > Check_ntp (v1.12) fails to recognize the refid of a > Stratum 1 peer. > > Need top patch line 254 to recognize WWV/PPS/GPS in > addition to ip addresses. > > > >>From - "Michael Jewett" > >> ./check_ntp -H xxx.xxx.xxx.xxx -v >> server xxx.xxx.xxx.xxx, stratum 2, offset 0.005577, > delay 0.02592 >> ntperr = 0 >> 11 Feb 14:06:39 ntpdate[11392]: adjust time server > 131.202.3.20 offset >> 0.005577 sec >> ntperr = 0 >> remote refid st t when poll reach > delay offset >> jitter >> > ============================================================================ >> == >> 192.68.54.20 0.0.0.0 16 - - 1024 0 > 0.000 0.000 >> 16000.0 >> 198.164.163.107 0.0.0.0 16 - - 1024 0 > 0.000 0.000 >> 16000.0 >> x128.118.46.3 .WWV. 1 u 510 1024 377 > 79.120 -36.329 >> 1.130 >> +128.118.25.3 192.5.41.209 2 u 470 1024 377 > 79.150 -0.815 >> 0.980 >> Candiate count= 1 >> 129.116.3.5 0.0.0.0 16 - - 1024 0 > 0.000 0.000 >> 16000.0 >> yyy.yyy.yyy.yyy 0.0.0.0 16 - - 1024 > 0 0.000 0.000 >> 16000.0 >> 132.246.168.80 0.0.0.0 16 - - 1024 0 > 0.000 0.000 >> 16000.0 >> +132.246.168.2 .PPS. 1 u 851 1024 377 > 25.010 -0.283 >> 0.200 >> Candiate count= 2 >> *132.246.168.3 .PPS. 1 u 216 1024 377 > 24.980 -0.554 >> 0.240 >> Candiate count= 3 >> Use of uninitialized value at ./check_ntp line 297. >> UNKNOWN: Jitter too high > > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=397599&aid=684818&group_id=29880 > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From sghosh at sghosh.org Wed Feb 12 15:01:14 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Wed Feb 12 15:01:14 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-684818 ] check_ntp regex for ntpq fails for stratum1 peer In-Reply-To: <62751.208.185.41.103.1045089924.squirrel@www.jawfish.com> Message-ID: reopened the patch entry. Thanks. -sg On Wed, 12 Feb 2003, Marc C. Poulin wrote: > I also see refids of .USNO. (tick.usno.navy.mil) and .ACTS. > (time-b.nist.gov) for stratum 1 servers (- these should probably be added > to the regex. > Thanks, > Marc > > > SourceForge.net said: > > Patches item #684818, was opened at 2003-02-11 13:54 > > You can respond by visiting: > > https://sourceforge.net/tracker/?func=detail&atid=397599&aid=684818&group_id=29880 > > > > Category: None > > Group: None > > Status: Open > > Resolution: None > > Priority: 7 > > Submitted By: Subhendu Ghosh (sghosh) > > Assigned to: Subhendu Ghosh (sghosh) > > Summary: check_ntp regex for ntpq fails for stratum1 peer > > > > Initial Comment: > > Check_ntp (v1.12) fails to recognize the refid of a > > Stratum 1 peer. > > > > Need top patch line 254 to recognize WWV/PPS/GPS in > > addition to ip addresses. > > > > > > > >>From - "Michael Jewett" > > > >> ./check_ntp -H xxx.xxx.xxx.xxx -v > >> server xxx.xxx.xxx.xxx, stratum 2, offset 0.005577, > > delay 0.02592 > >> ntperr = 0 > >> 11 Feb 14:06:39 ntpdate[11392]: adjust time server > > 131.202.3.20 offset > >> 0.005577 sec > >> ntperr = 0 > >> remote refid st t when poll reach > > delay offset > >> jitter > >> > > ============================================================================ > >> == > >> 192.68.54.20 0.0.0.0 16 - - 1024 0 > > 0.000 0.000 > >> 16000.0 > >> 198.164.163.107 0.0.0.0 16 - - 1024 0 > > 0.000 0.000 > >> 16000.0 > >> x128.118.46.3 .WWV. 1 u 510 1024 377 > > 79.120 -36.329 > >> 1.130 > >> +128.118.25.3 192.5.41.209 2 u 470 1024 377 > > 79.150 -0.815 > >> 0.980 > >> Candiate count= 1 > >> 129.116.3.5 0.0.0.0 16 - - 1024 0 > > 0.000 0.000 > >> 16000.0 > >> yyy.yyy.yyy.yyy 0.0.0.0 16 - - 1024 > > 0 0.000 0.000 > >> 16000.0 > >> 132.246.168.80 0.0.0.0 16 - - 1024 0 > > 0.000 0.000 > >> 16000.0 > >> +132.246.168.2 .PPS. 1 u 851 1024 377 > > 25.010 -0.283 > >> 0.200 > >> Candiate count= 2 > >> *132.246.168.3 .PPS. 1 u 216 1024 377 > > 24.980 -0.554 > >> 0.240 > >> Candiate count= 3 > >> Use of uninitialized value at ./check_ntp line 297. > >> UNKNOWN: Jitter too high > > > > > > ---------------------------------------------------------------------- > > > > You can respond by visiting: > > https://sourceforge.net/tracker/?func=detail&atid=397599&aid=684818&group_id=29880 > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Nagiosplug-devel mailing list > > Nagiosplug-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > ::: Please include plugins version (-v) and OS when reporting any issue. > > ::: Messages without supporting info will risk being sent to /dev/null > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -- From jeremy+nagios at UnderGrid.net Wed Feb 12 15:22:10 2003 From: jeremy+nagios at UnderGrid.net (Jeremy T. Bouse) Date: Wed Feb 12 15:22:10 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-684818 ] check_ntp regex for ntpq fails for stratum1 peer In-Reply-To: References: <62751.208.185.41.103.1045089924.squirrel@www.jawfish.com> Message-ID: <20030212232043.GA877@UnderGrid.net> I also made some more comments on the patch entry as I found .PCS. being used by tick.usno.navy.mil and .ACTS. from time-C.timefreq.bldrdoc.gov... I would also make the [lumb] [lumb-] as I get the following on one of my NTP servers... remote refid st t when poll reach delay offset jitter ============================================================================== 255.255.255.255 0.0.0.0 16 u - 64 0 0.000 0.000 16000.0 *204.123.2.5 .GPS. 1 - 422 1024 377 6.710 1.106 0.290 +209.81.9.7 .GPS. 1 - 521 1024 377 2.240 -2.015 0.210 192.5.5.250 0.0.0.0 16 - - 1024 0 0.000 0.000 16000.0 Which as written has caused it to error when executing the plugin as is... Jeremy On Wed, Feb 12, 2003 at 06:00:26PM -0500, Subhendu Ghosh wrote: > reopened the patch entry. Thanks. > > -sg > > > On Wed, 12 Feb 2003, Marc C. Poulin wrote: > > > I also see refids of .USNO. (tick.usno.navy.mil) and .ACTS. > > (time-b.nist.gov) for stratum 1 servers (- these should probably be added > > to the regex. > > Thanks, > > Marc > > > > > > SourceForge.net said: > > > Patches item #684818, was opened at 2003-02-11 13:54 > > > You can respond by visiting: > > > https://sourceforge.net/tracker/?func=detail&atid=397599&aid=684818&group_id=29880 > > > > > > Category: None > > > Group: None > > > Status: Open > > > Resolution: None > > > Priority: 7 > > > Submitted By: Subhendu Ghosh (sghosh) > > > Assigned to: Subhendu Ghosh (sghosh) > > > Summary: check_ntp regex for ntpq fails for stratum1 peer > > > > > > Initial Comment: > > > Check_ntp (v1.12) fails to recognize the refid of a > > > Stratum 1 peer. > > > > > > Need top patch line 254 to recognize WWV/PPS/GPS in > > > addition to ip addresses. > > > > > > > > > > > >>From - "Michael Jewett" > > > > > >> ./check_ntp -H xxx.xxx.xxx.xxx -v > > >> server xxx.xxx.xxx.xxx, stratum 2, offset 0.005577, > > > delay 0.02592 > > >> ntperr = 0 > > >> 11 Feb 14:06:39 ntpdate[11392]: adjust time server > > > 131.202.3.20 offset > > >> 0.005577 sec > > >> ntperr = 0 > > >> remote refid st t when poll reach > > > delay offset > > >> jitter > > >> > > > ============================================================================ > > >> == > > >> 192.68.54.20 0.0.0.0 16 - - 1024 0 > > > 0.000 0.000 > > >> 16000.0 > > >> 198.164.163.107 0.0.0.0 16 - - 1024 0 > > > 0.000 0.000 > > >> 16000.0 > > >> x128.118.46.3 .WWV. 1 u 510 1024 377 > > > 79.120 -36.329 > > >> 1.130 > > >> +128.118.25.3 192.5.41.209 2 u 470 1024 377 > > > 79.150 -0.815 > > >> 0.980 > > >> Candiate count= 1 > > >> 129.116.3.5 0.0.0.0 16 - - 1024 0 > > > 0.000 0.000 > > >> 16000.0 > > >> yyy.yyy.yyy.yyy 0.0.0.0 16 - - 1024 > > > 0 0.000 0.000 > > >> 16000.0 > > >> 132.246.168.80 0.0.0.0 16 - - 1024 0 > > > 0.000 0.000 > > >> 16000.0 > > >> +132.246.168.2 .PPS. 1 u 851 1024 377 > > > 25.010 -0.283 > > >> 0.200 > > >> Candiate count= 2 > > >> *132.246.168.3 .PPS. 1 u 216 1024 377 > > > 24.980 -0.554 > > >> 0.240 > > >> Candiate count= 3 > > >> Use of uninitialized value at ./check_ntp line 297. > > >> UNKNOWN: Jitter too high > > > > > > > > > ---------------------------------------------------------------------- > > > > > > You can respond by visiting: > > > https://sourceforge.net/tracker/?func=detail&atid=397599&aid=684818&group_id=29880 > > > > > > > > > ------------------------------------------------------- > > > This SF.NET email is sponsored by: > > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > > http://www.vasoftware.com > > > _______________________________________________ > > > Nagiosplug-devel mailing list > > > Nagiosplug-devel at lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > > ::: Please include plugins version (-v) and OS when reporting any issue. > > > ::: Messages without supporting info will risk being sent to /dev/null > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Nagiosplug-devel mailing list > > Nagiosplug-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > ::: Please include plugins version (-v) and OS when reporting any issue. > > ::: Messages without supporting info will risk being sent to /dev/null > > > > -- > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From pankaj at magnum.barc.ernet.in Thu Feb 13 03:38:03 2003 From: pankaj at magnum.barc.ernet.in (Pankaj Saksena) Date: Thu Feb 13 03:38:03 2003 Subject: [Nagiosplug-devel] problems in inserting my own programs in nagios software Message-ID: dear sir, i have installed nagios software in my 32 node linux based p4 machines. i am trying to insert my own programs for reading certain parameters from machines. but unable to do so. i am not able tolay my hands on any doc for it. i downloaded folowing from the site ::sourceforge.net/project nagios-plugins-1.3.0-beta2.i386.rpm nagios-plugins-1.3.0-beta2.tar.gz the first rpm just installed the plugins. the second program gave me source code of the plugins. do i have to modify one of those files or insert my new programs in that and again make/compile it. please guide me. regards, pankaj From kolisko at penguin.cz Thu Feb 13 05:16:09 2003 From: kolisko at penguin.cz (- = k o l i s k o = -) Date: Thu Feb 13 05:16:09 2003 Subject: [Nagiosplug-devel] i would like to create a new plugin Message-ID: <1045142134.4204.21.camel@kolisko> Hi all, I would like to create a new plugin which will check a qmail queue status. like this: 0 root at mx1:plugins# cat check_queue.sh #!/bin/bash if [ "$#" = "1" ] then limit=$1 pocet=`qmail-qread|grep -v done|wc -l` email="mkolesar at broadnet.cz" if [ "$pocet" -gt "$limit" ] then echo "warning: Limit prekrocen!!! $pocet/$limit" exit 2 else echo "queue ok - Limit OK $pocet/$limit" exit 0 fi else echo -e "syntax error!!!\n\tusage: $0 limit" fi But i dont know how to add it to the nagios server. I have a nagios server which check lot of serveres. One of that servers is a mail server with qmail. On the mailserver is running debian and nagios-statd-server package. So port 1040 is activated. I have the check_queue.sh script on the mailserver. And i dont know how to use this script from the nagios server. Can you help me please? tx kolisko -- --- Michal Koles?r kolisko at penguin.cz http://kolisko.penguin.cz +420.777.225.297 Don't send me any attachment in Micro$oft (.DOC, .PPT) format please Read http://www.fsf.org/philosophy/no-word-attachments.html Preferable attachments: .PDF, .HTML, .TXT Thanx for adding this text to Your signature From kdebisschop at mail.debisschop.net Thu Feb 13 08:50:20 2003 From: kdebisschop at mail.debisschop.net (Karl DeBisschop) Date: Thu Feb 13 08:50:20 2003 Subject: [Nagiosplug-devel] Re: Nagios plugin translation in French In-Reply-To: <3E4BC633.2050805@ifsic.univ-rennes1.fr> References: <3E4BC633.2050805@ifsic.univ-rennes1.fr> Message-ID: Pierre-Antoine Angelini writes: > Hi Karl > > I'm working on Nagios translation (French) , and Chris told me that you > were interested. H'es quite busy actually, so I'll try to give a hand. > > I gave a look at the plugin, but couln't find any documentation , apart of > the builtin help That's more or less correct > Could you tell me exactly what you wish concerning this topic ? > Do you want to make a separate documentation ( and we'll translate it > them) > > Do you wish to include the on-line help into the plugin (with some kinds > of internationalization ?) I think what we'd like to do is internationalize the existing plugins, including their online help. I don't have any experience with internationalization, so I don't know how hard that would be, or if there are reasons to avoid that approach. -- Karl From mcp at jawfish.com Fri Feb 14 08:38:02 2003 From: mcp at jawfish.com (Marc C. Poulin) Date: Fri Feb 14 08:38:02 2003 Subject: [Nagiosplug-devel] segfault in check_nt Message-ID: <62139.208.185.41.103.1045240615.squirrel@www.jawfish.com> When running check_nt (latest cvs version) against a server that doesn't have nsclient installed, check_nt dies with a segfault on line 380, because output_message never gets initialized if all the if/else vars_to_check comparisons fall through. There should be a terminal else that assigns a string to output_message. Thanks, Marc From noreply at sourceforge.net Fri Feb 14 20:49:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 14 20:49:03 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-686476 ] pre compiler barfs on include path for system openssl Message-ID: Patches item #686476, was opened at 2003-02-14 11:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=686476&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lutz Behnke (cypherfox) Assigned to: Nobody/Anonymous (nobody) Summary: pre compiler barfs on include path for system openssl Initial Comment: On Linux, the cpp prints a warning to stderr if a system include path is reset on the command line. The configure script takes this to mean that an error occored. The following patch checks if defining a new '-I' for the openssl include path is nessecary (it is not if openssl was installed as part of the system as for SuSE. mfg lutz --- nagios-plugins-1.3.0-beta2/configure.in 2002-11-22 03:46:49.000000000 +0100 +++ src/nagios-plugins-1.3.0-beta2/configure.in 2003-02-14 11:34:38.000000000 +0100 @@ -222,7 +222,10 @@ dnl Check for OpenSSL header files _SAVEDCPPFLAGS="$CPPFLAGS" FOUNDINCLUDE=yes -CPPFLAGS="-I$OPENSSL/include" +if test "$OPENSSL" != "/usr" ; then + CPPFLAGS="-I$OPENSSL/include" +fi + AC_CHECK_HEADERS(openssl/x509.h openssl/ssl.h openssl/rsa.h openssl/pem.h openssl/crypto.h openssl/err.h,SSLINCLUDE="-I$OPENSSL/include",FOUNDINCLUDE=no) if test "$FOUNDINCLUDE" = "no"; then FOUNDINCLUDE=yes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=686476&group_id=29880 From noreply at sourceforge.net Fri Feb 14 20:49:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 14 20:49:04 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-686522 ] check_disk_smb can't access $ shares Message-ID: Bugs item #686522, was opened at 2003-02-14 04:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=686522&group_id=29880 Category: Argument proccessing Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk_smb can't access $ shares Initial Comment: When i trie to access $ shares (e.g. \server\c$) with check_disk_smb the $-sign gets lost and check_disk_smb tries to access \server\c. Escaping the $-sign in the shell etc. does not solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=686522&group_id=29880 From Brian.Ipsen at andebakken.dk Sat Feb 15 05:54:04 2003 From: Brian.Ipsen at andebakken.dk (Brian Ipsen) Date: Sat Feb 15 05:54:04 2003 Subject: [Nagiosplug-devel] RE: Daily Snapshot ? In-Reply-To: Message-ID: Hi, > > Found the solution: > > > > aclocal > > autoconf > > autoheader > > automake > > Also known as ./tools/setup and described in step 0 of INSTALL > > > > That gives me configure and (maybe) all other needed files. But > > how should the nagios-plugins.spec.in file be translated into > > nagios-plugins.spec ?? > > see step 1 -- ./configure I have done the ./configure step on a CVS snapshot - and I don't get a file named nagios-plugins.spec ... Any other ideas ?? Regards, /Brian From karl at debisschop.net Sat Feb 15 07:06:15 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Sat Feb 15 07:06:15 2003 Subject: [Nagiosplug-devel] RE: Daily Snapshot ? In-Reply-To: References: Message-ID: <1045321430.21451.1.camel@miles.debisschop.net> On Sat, 2003-02-15 at 08:53, Brian Ipsen wrote: > Hi, > > > > Found the solution: > > > > > > aclocal > > > autoconf > > > autoheader > > > automake > > > > Also known as ./tools/setup and described in step 0 of INSTALL > > > > > > That gives me configure and (maybe) all other needed files. But > > > how should the nagios-plugins.spec.in file be translated into > > > nagios-plugins.spec ?? > > > > see step 1 -- ./configure > > I have done the ./configure step on a CVS snapshot - and I don't > get a file named nagios-plugins.spec ... Any other ideas ?? My bad. It changed recently. make dist you will get a tarball with the spec in it. -- Karl From Jeremy.Bouse at UnderGrid.net Sat Feb 15 11:08:09 2003 From: Jeremy.Bouse at UnderGrid.net (Jeremy T. Bouse) Date: Sat Feb 15 11:08:09 2003 Subject: [Nagiosplug-devel] RE: Daily Snapshot ? In-Reply-To: <1045321430.21451.1.camel@miles.debisschop.net> References: <1045321430.21451.1.camel@miles.debisschop.net> Message-ID: <20030215190653.GB10479@UnderGrid.net> Karl, Is there any reason why it shouldn't be generated at the same time the configure script is ran? That just seems to make more sense to me, but then again I don't run RedHat or any RPM based distro... Just ignore my slight bias towards Debian :) Jeremy On Sat, Feb 15, 2003 at 10:03:51AM -0500, Karl DeBisschop wrote: > My bad. > > It changed recently. > > make dist > > you will get a tarball with the spec in it. > > -- > Karl > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From sghosh at sghosh.org Sat Feb 15 18:26:07 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Sat Feb 15 18:26:07 2003 Subject: [Nagiosplug-devel] patch-623270/bug-656924 Message-ID: Ton Are you working on the above patch? The above bug in my queue is related. -- -sg From jeremy+nagios at UnderGrid.net Sun Feb 16 11:05:06 2003 From: jeremy+nagios at UnderGrid.net (Jeremy T. Bouse) Date: Sun Feb 16 11:05:06 2003 Subject: [Nagiosplug-devel] Bug report 684574 Message-ID: <20030216190324.GA5145@UnderGrid.net> Anyone else been able to reproduce the above mentioned bug? I've tried the current CVS version against both Debian 2.2 and 3.0 and have not seen it reproduced. I'm not sure if it might have been related to any changes ton made with regards to 652468 but want to make sure no one else was seeing this before I considered it fixed... Jeremy From karl at debisschop.net Sun Feb 16 16:35:02 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Sun Feb 16 16:35:02 2003 Subject: [Nagiosplug-devel] RE: Daily Snapshot ? In-Reply-To: <20030215190653.GB10479@UnderGrid.net> References: <1045321430.21451.1.camel@miles.debisschop.net> <20030215190653.GB10479@UnderGrid.net> Message-ID: <1045441970.31485.1.camel@miles.debisschop.net> On Sat, 2003-02-15 at 14:06, Jeremy T. Bouse wrote: > Karl, > > Is there any reason why it shouldn't be generated at the same > time the configure script is ran? That just seems to make more sense to > me, but then again I don't run RedHat or any RPM based distro... Just > ignore my slight bias towards Debian :) It used to be that way. In practice, it turns out that autmake handles it much more reliably this way. But I will look into making it better than it is now - I agree this is not 100% intuitive. -- Karl > Jeremy > > On Sat, Feb 15, 2003 at 10:03:51AM -0500, Karl DeBisschop wrote: > > My bad. > > > > It changed recently. > > > > make dist > > > > you will get a tarball with the spec in it. > > > > -- > > Karl > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Nagiosplug-devel mailing list > > Nagiosplug-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > ::: Please include plugins version (-v) and OS when reporting any issue. > > ::: Messages without supporting info will risk being sent to /dev/null > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From kdebisschop at alert.infoplease.com Mon Feb 17 12:28:27 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Mon Feb 17 12:28:27 2003 Subject: [Nagiosplug-devel] beta Message-ID: <1045513596.1090.35.camel@miles.debisschop.net> I'm trying to work out the issues I have open still. Are there any things I should wait on from the CVS committers before starting to roll a beta? (I don't expect to start before late tonight [EST], but I figured I'd ask the question now to give people a chance to respond) -- Karl DeBisschop From sghosh at sghosh.org Mon Feb 17 16:52:04 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Feb 17 16:52:04 2003 Subject: [Nagiosplug-devel] beta In-Reply-To: <1045513596.1090.35.camel@miles.debisschop.net> Message-ID: yes - a patch for configure.in and check_swap.c fro HPUX. testing right now after speding the day digning myself out of the snow :) -sg On 17 Feb 2003, Karl DeBisschop wrote: > I'm trying to work out the issues I have open still. Are there any > things I should wait on from the CVS committers before starting to roll > a beta? > > (I don't expect to start before late tonight [EST], but I figured I'd > ask the question now to give people a chance to respond) > > -- From sghosh at sghosh.org Mon Feb 17 20:09:11 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Feb 17 20:09:11 2003 Subject: [Nagiosplug-devel] check HP-UX? Message-ID: I am done patching for swapinfo on HPUX If anybody can take a quick stab at testing it... Only changes were in configure.in -- -sg From Ton.Voon at egg.com Tue Feb 18 01:36:05 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Tue Feb 18 01:36:05 2003 Subject: [Nagiosplug-devel] segfault in check_nt Message-ID: <53104E20A25CD411B556009027E50636064D52F0@pnnemp02.pn.egg.com> Thanks Marc. Have updated check_nt so that it insists on a -v variable parameter. > -----Original Message----- > From: Marc C. Poulin [SMTP:mcp at jawfish.com] > Sent: Friday, February 14, 2003 4:37 PM > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] segfault in check_nt > > When running check_nt (latest cvs version) against a server that doesn't > have nsclient installed, check_nt dies with a segfault on line 380, > because output_message never gets initialized if all the if/else > vars_to_check comparisons fall through. There should be a terminal else > that assigns a string to output_message. > Thanks, > Marc > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From Ton.Voon at egg.com Tue Feb 18 02:43:12 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Tue Feb 18 02:43:12 2003 Subject: [Nagiosplug-devel] Bug report 684574 Message-ID: <53104E20A25CD411B556009027E50636064D52F2@pnnemp02.pn.egg.com> I haven't done any work on 652468 because I'm not getting responses about how to recreate. I was going to close this call. On a related note, I notice that new calls raised are copied to this mailing list. Is it possible for call updates to be sent to this mailing list as well? I'd like to keep tracking calls through sourceforge, but let the mailing list have visibility on what is happening. > -----Original Message----- > From: Jeremy T. Bouse [SMTP:jeremy+nagios at UnderGrid.net] > Sent: Sunday, February 16, 2003 7:03 PM > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] Bug report 684574 > > Anyone else been able to reproduce the above mentioned bug? > I've tried the current CVS version against both Debian 2.2 and 3.0 and > have not seen it reproduced. I'm not sure if it might have been related > to any changes ton made with regards to 652468 but want to make sure no > one else was seeing this before I considered it fixed... > > Jeremy > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From noreply at sourceforge.net Tue Feb 18 06:50:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 18 06:50:06 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-688474 ] check_udp hangs Message-ID: Bugs item #688474, was opened at 2003-02-17 22:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=688474&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erik Carlseen (ecarlseen) Assigned to: Nobody/Anonymous (nobody) Summary: check_udp hangs Initial Comment: check_udp hangs when run from the shell prompt (haven't tried it through Nagios yet). I've given it an hour to timeout, exit, etc., but have always been forced to kill it manually. Someone else reported the same problem on the Nagios Users mailing list (see http://sourceforge.net/mailarchive/forum.php?thread_id=1618392&forum_id=1873 ). I'm running RedHat 8.0 on x86, the poster on the mailing list is running RedHat 7.3. There are no firewalls, iptables filters, etc. blocking these packets on my systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=688474&group_id=29880 From noreply at sourceforge.net Tue Feb 18 06:50:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 18 06:50:08 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-688646 ] check_udp don`t work, is stack Message-ID: Bugs item #688646, was opened at 2003-02-18 05:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=688646&group_id=29880 Category: None Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: check_udp don`t work, is stack Initial Comment: w3:~/dalis/nagios/nagios-plugins-1.3.0-beta2/plugins # strace ./check_udp -H 10.10.0.1 -p 53 execve("./check_udp", ["./check_udp", "-H", "10.10.0.1", "-p", "53"], [/* 42 vars */]) = 0 uname({sys="Linux", node="w3", ...}) = 0 brk(0) = 0x804c52c old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=30643, ...}) = 0 old_mmap(NULL, 30643, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000 close(3) = 0 open("/lib/libnsl.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0B\0\000"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=91150, ...}) = 0 old_mmap(NULL, 87196, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001e000 mprotect(0x40030000, 13468, PROT_NONE) = 0 old_mmap(0x40030000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x11000) = 0x40030000 old_mmap(0x40032000, 5276, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40032000 close(3) = 0 open("/lib/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240*\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=66718, ...}) = 0 old_mmap(NULL, 69920, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40034000 mprotect(0x40042000, 12576, PROT_NONE) = 0 old_mmap(0x40042000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xd000) = 0x40042000 old_mmap(0x40043000, 8480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40043000 close(3) = 0 open("/lib/libutil.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\17\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=11551, ...}) = 0 old_mmap(NULL, 10772, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40046000 mprotect(0x40048000, 2580, PROT_NONE) = 0 old_mmap(0x40048000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x40048000 close(3) open("/usr/lib/libelf.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\31\0\000"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=65190, ...}) = 0 old_mmap(NULL, 56232, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40049000 mprotect(0x40056000, 2984, PROT_NONE) = 0 old_mmap(0x40056000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xc000) = 0x40056000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\330"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1384040, ...}) = 0 old_mmap(NULL, 1201860, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40057000 mprotect(0x40172000, 42692, PROT_NONE) = 0 old_mmap(0x40172000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x11a000) = 0x40172000 old_mmap(0x40179000, 14020, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40179000 close(3) = 0 munmap(0x40016000, 30643) = 0 And that`s all your i386 have the same problem ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=688646&group_id=29880 From sghosh at sghosh.org Tue Feb 18 07:06:13 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Tue Feb 18 07:06:13 2003 Subject: [Nagiosplug-devel] Bug report 684574 In-Reply-To: <53104E20A25CD411B556009027E50636064D52F2@pnnemp02.pn.egg.com> Message-ID: If everybody is for it, I'd like to be able to do that. The only issue preventing this right now is that there is a SF bug on email generated from all Tracker items (bugs/patches/etc). The email has an implicit destination and Mailman doesn't like implicit destinations. So an admin message is generated and the message must be approved manually. I posted a bug report with SF on this. http://sourceforge.net/tracker/?func=detail&aid=630798&group_id=1&atid=200001 -sg On Tue, 18 Feb 2003, Voon, Ton wrote: > I haven't done any work on 652468 because I'm not getting responses about > how to recreate. I was going to close this call. > > On a related note, I notice that new calls raised are copied to this mailing > list. Is it possible for call updates to be sent to this mailing list as > well? I'd like to keep tracking calls through sourceforge, but let the > mailing list have visibility on what is happening. > > > -----Original Message----- > > From: Jeremy T. Bouse [SMTP:jeremy+nagios at UnderGrid.net] > > Sent: Sunday, February 16, 2003 7:03 PM > > To: nagiosplug-devel at lists.sourceforge.net > > Subject: [Nagiosplug-devel] Bug report 684574 > > > > Anyone else been able to reproduce the above mentioned bug? > > I've tried the current CVS version against both Debian 2.2 and 3.0 and > > have not seen it reproduced. I'm not sure if it might have been related > > to any changes ton made with regards to 652468 but want to make sure no > > one else was seeing this before I considered it fixed... > > > > Jeremy > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Nagiosplug-devel mailing list > > Nagiosplug-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > ::: Please include plugins version (-v) and OS when reporting any issue. > > ::: Messages without supporting info will risk being sent to /dev/null > > > This private and confidential e-mail has been sent to you by Egg. > The Egg group of companies includes Egg Banking plc > (registered no. 2999842), Egg Financial Products Ltd (registered > no. 3319027) and Egg Investments Ltd (registered no. 3403963) which > carries out investment business on behalf of Egg and is regulated > by the Financial Services Authority. > Registered in England and Wales. Registered offices: 1 Waterhouse Square, > 138-142 Holborn, London EC1N 2NA. > If you are not the intended recipient of this e-mail and have > received it in error, please notify the sender by replying with > 'received in error' as the subject and then delete it from your > mailbox. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -- From Ton.Voon at egg.com Tue Feb 18 08:02:19 2003 From: Ton.Voon at egg.com (Voon, Ton) Date: Tue Feb 18 08:02:19 2003 Subject: [Nagiosplug-devel] Bug in check_http v1.22 Message-ID: <53104E20A25CD411B556009027E50636064D52FA@pnnemp02.pn.egg.com> Can't see where this bug is, but should be fixed before the next beta: snail $ ./check_http --version check_http (nagios-plugins 200302181100-snapshot) 1.22 The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute copies of the plugins under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. snail $ ./check_http -H new.egg.com HTTP ok: HTTP/1.1 302 Moved Temporarily - 0.030 second response time |time= 0.030 snail $ ./check_http -H new.egg.com --onredirect=follow HTTP UNKNOWN: could not allocate server_urlsnail $ snail $ ./check_http -H new.egg.com --onredirect=follow -u / HTTP ok: HTTP/1.1 200 OK - 0.384 second response time |time= 0.384 snail $ Looks like if --onredirect is set to follow, then the default url is lost. Ton This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From karl at debisschop.net Tue Feb 18 14:20:10 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Tue Feb 18 14:20:10 2003 Subject: [Nagiosplug-devel] Re: [Nagiosplug-checkins] CVS: nagiosplug Makefile.am,1.6,1.7 In-Reply-To: References: Message-ID: <1045606706.15264.88.camel@miles.debisschop.net> On Tue, 2003-02-18 at 16:58, Ton Voon wrote: > Update of /cvsroot/nagiosplug/nagiosplug > In directory sc8-pr-cvs1:/tmp/cvs-serv5780 > > Modified Files: > Makefile.am > Log Message: > Add SUPPORT file to distribution > > > Index: Makefile.am > =================================================================== > RCS file: /cvsroot/nagiosplug/nagiosplug/Makefile.am,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -C2 -r1.6 -r1.7 > *** Makefile.am 10 Feb 2003 23:24:35 -0000 1.6 > --- Makefile.am 18 Feb 2003 21:58:01 -0000 1.7 > *************** > *** 3,7 **** > SUBDIRS = lib plugins plugins-scripts > > ! EXTRA_DIST = REQUIREMENTS acconfig.h subst.in subst.sh Helper.pm \ > contrib nagios-plugins.spec.in getloadavg.m4 > > --- 3,7 ---- > SUBDIRS = lib plugins plugins-scripts > > ! EXTRA_DIST = REQUIREMENTS SUPPORT acconfig.h subst.in subst.sh Helper.pm \ > contrib nagios-plugins.spec.in getloadavg.m4 You did the getopt changes, right? Should we put getloadavg.c into lib as well? If so, do you ahve a few moments to implement it? It should be the actual move plus mods to where AM/AC call getloadavg.m4 -- Karl From russell at quadrix.com Tue Feb 18 14:23:02 2003 From: russell at quadrix.com (Russell Scibetti) Date: Tue Feb 18 14:23:02 2003 Subject: [Nagiosplug-devel] Perf Data Message-ID: <3E52B1DD.9030503@quadrix.com> Are the plugins in the 1.3b3 release going to have more built-in perfdata output? For example, check_disk can return the amount of space used, check_load can return the 3 load values, check_snmp can return the response in both the output and the perfdata (maybe if a cmd-line arg is given), etc. I'm just trying to figure out if I need to write additions to the b2 plugins for perfdata or not. We are looking to start dumping all performance related information into RRD. Thanks. Russell -- Russell Scibetti Quadrix Solutions, Inc. http://www.quadrix.com (732) 235-2335, ext. 7038 From karl at debisschop.net Tue Feb 18 14:38:15 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Tue Feb 18 14:38:15 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: <3E52B1DD.9030503@quadrix.com> References: <3E52B1DD.9030503@quadrix.com> Message-ID: <1045607821.15264.92.camel@miles.debisschop.net> On Tue, 2003-02-18 at 17:21, Russell Scibetti wrote: > Are the plugins in the 1.3b3 release going to have more built-in > perfdata output? For example, check_disk can return the amount of space > used, check_load can return the 3 load values, check_snmp can return the > response in both the output and the perfdata (maybe if a cmd-line arg is > given), etc. > > I'm just trying to figure out if I need to write additions to the b2 > plugins for perfdata or not. We are looking to start dumping all > performance related information into RRD. Thanks. > > Russell Those will go in immediately after the release. So hopefully in less than 2 weeks. If you track the CVS with your changes, and provide patches against the individual plugins at that time, you have a very high likelihood of having them accepted almost as fast as you submit them. Even if you don't, I expect the perf data to happen very quickly after the release. -- Karl From russell at quadrix.com Tue Feb 18 15:06:02 2003 From: russell at quadrix.com (Russell Scibetti) Date: Tue Feb 18 15:06:02 2003 Subject: [Nagiosplug-devel] Perf Data References: <3E52B1DD.9030503@quadrix.com> <1045607821.15264.92.camel@miles.debisschop.net> Message-ID: <3E52BBEF.1050909@quadrix.com> If it would be helpful, this is something I can work on in parallel and submit a patch as I add to each plugin. Would it better to have the plugins output perfdata by default, or require a cmdline arg? I want to be as consistent between plugins as possible. Russell Karl DeBisschop wrote: >On Tue, 2003-02-18 at 17:21, Russell Scibetti wrote: > >>Are the plugins in the 1.3b3 release going to have more built-in >>perfdata output? For example, check_disk can return the amount of space >>used, check_load can return the 3 load values, check_snmp can return the >>response in both the output and the perfdata (maybe if a cmd-line arg is >>given), etc. >> >>I'm just trying to figure out if I need to write additions to the b2 >>plugins for perfdata or not. We are looking to start dumping all >>performance related information into RRD. Thanks. >> >>Russell >> > >Those will go in immediately after the release. So hopefully in less >than 2 weeks. > >If you track the CVS with your changes, and provide patches against the >individual plugins at that time, you have a very high likelihood of >having them accepted almost as fast as you submit them. > >Even if you don't, I expect the perf data to happen very quickly after >the release. > >-- >Karl > > > -- Russell Scibetti Quadrix Solutions, Inc. http://www.quadrix.com (732) 235-2335, ext. 7038 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy+nagios at UnderGrid.net Tue Feb 18 15:38:15 2003 From: jeremy+nagios at UnderGrid.net (Jeremy T. Bouse) Date: Tue Feb 18 15:38:15 2003 Subject: [Nagiosplug-devel] Re: [Nagiosplug-checkins] CVS: nagiosplug Makefile.am,1.6,1.7 In-Reply-To: <1045606706.15264.88.camel@miles.debisschop.net> References: <1045606706.15264.88.camel@miles.debisschop.net> Message-ID: <20030218233634.GB29937@UnderGrid.net> I was gonna ask this myself as it made sense to keep the getopt and getloadavg implementations in lib/ together... Jeremy On Tue, Feb 18, 2003 at 05:18:26PM -0500, Karl DeBisschop wrote: > You did the getopt changes, right? > > Should we put getloadavg.c into lib as well? > > If so, do you ahve a few moments to implement it? It should be the > actual move plus mods to where AM/AC call getloadavg.m4 > From noreply at sourceforge.net Tue Feb 18 16:14:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 18 16:14:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-688729 ] check_swap doesn't say 'ok' Message-ID: Bugs item #688729, was opened at 2003-02-18 08:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=688729&group_id=29880 Category: Parsing problem Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: check_swap doesn't say 'ok' Initial Comment: The check_swap produceses WARNING or CRITICAL if needed. But... it does NOT say OK if the values ar fine. Suggested modification: check_load.c Linenumber: 142: printf ("\n"); change to Linenumber: 142: printf (" OK\n"); Thanx. Jayjay. jayjay at twek.nl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=688729&group_id=29880 From karl at debisschop.net Tue Feb 18 16:40:07 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Tue Feb 18 16:40:07 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: <3E52BBEF.1050909@quadrix.com> References: <3E52B1DD.9030503@quadrix.com> <1045607821.15264.92.camel@miles.debisschop.net> <3E52BBEF.1050909@quadrix.com> Message-ID: <1045615087.15264.102.camel@miles.debisschop.net> On Tue, 2003-02-18 at 18:04, Russell Scibetti wrote: > If it would be helpful, this is something I can work on in parallel > and submit a patch as I add to each plugin. It would be very helpful, but in no case are we adding perf data before the release. We are in feature freeze. > Would it better to have the plugins output perfdata by default, or > require a cmdline arg? I want to be as consistent between plugins as > possible. So far, it has been enabled by default. Not sure if that is the right decision, however. If there were not size limits on the nagios data pipe, I'd send it by default. But I'd hate to deserialize the pipe for an added few bytes of perf data that wasn't even wanted. Thoughts anyone? > Russell > > Karl DeBisschop wrote: > > On Tue, 2003-02-18 at 17:21, Russell Scibetti wrote: > > > > > Are the plugins in the 1.3b3 release going to have more built-in > > > perfdata output? For example, check_disk can return the amount of space > > > used, check_load can return the 3 load values, check_snmp can return the > > > response in both the output and the perfdata (maybe if a cmd-line arg is > > > given), etc. > > > > > > I'm just trying to figure out if I need to write additions to the b2 > > > plugins for perfdata or not. We are looking to start dumping all > > > performance related information into RRD. Thanks. > > > > > > Russell > > > > > > > Those will go in immediately after the release. So hopefully in less > > than 2 weeks. > > > > If you track the CVS with your changes, and provide patches against the > > individual plugins at that time, you have a very high likelihood of > > having them accepted almost as fast as you submit them. > > > > Even if you don't, I expect the perf data to happen very quickly after > > the release. > > > > -- > > Karl > > > > > > > > > > > -- > Russell Scibetti > Quadrix Solutions, Inc. > http://www.quadrix.com > (732) 235-2335, ext. 7038 From sghosh at sghosh.org Tue Feb 18 16:43:02 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Tue Feb 18 16:43:02 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: <3E52BBEF.1050909@quadrix.com> Message-ID: Perfdata should be generated by default I think. There have been no discussion to the contrary. The only discussion that needs to take place is the formatting of the data and ensuring sequence of perfdata matches sequence of argumets (eg. oid in check_snmp) or natural order (eg. disks in check_disk) -sg On Tue, 18 Feb 2003, Russell Scibetti wrote: > If it would be helpful, this is something I can work on in parallel and > submit a patch as I add to each plugin. > > Would it better to have the plugins output perfdata by default, or > require a cmdline arg? I want to be as consistent between plugins as > possible. > > Russell > > Karl DeBisschop wrote: > > >On Tue, 2003-02-18 at 17:21, Russell Scibetti wrote: > > > >>Are the plugins in the 1.3b3 release going to have more built-in > >>perfdata output? For example, check_disk can return the amount of space > >>used, check_load can return the 3 load values, check_snmp can return the > >>response in both the output and the perfdata (maybe if a cmd-line arg is > >>given), etc. > >> > >>I'm just trying to figure out if I need to write additions to the b2 > >>plugins for perfdata or not. We are looking to start dumping all > >>performance related information into RRD. Thanks. > >> > >>Russell > >> > > > >Those will go in immediately after the release. So hopefully in less > >than 2 weeks. > > > >If you track the CVS with your changes, and provide patches against the > >individual plugins at that time, you have a very high likelihood of > >having them accepted almost as fast as you submit them. > > > >Even if you don't, I expect the perf data to happen very quickly after > >the release. > > > >-- > >Karl > > > > > > > > -- From karl at debisschop.net Tue Feb 18 16:47:03 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Tue Feb 18 16:47:03 2003 Subject: [Nagiosplug-devel] Re: [Nagiosplug-checkins] CVS: nagiosplug Makefile.am,1.6,1.7 In-Reply-To: <20030218233634.GB29937@UnderGrid.net> References: <1045606706.15264.88.camel@miles.debisschop.net> <20030218233634.GB29937@UnderGrid.net> Message-ID: <1045615435.15269.108.camel@miles.debisschop.net> On Tue, 2003-02-18 at 18:36, Jeremy T. Bouse wrote: > I was gonna ask this myself as it made sense to keep the getopt > and getloadavg implementations in lib/ together... > > Jeremy > > On Tue, Feb 18, 2003 at 05:18:26PM -0500, Karl DeBisschop wrote: > > You did the getopt changes, right? > > > > Should we put getloadavg.c into lib as well? > > > > If so, do you ahve a few moments to implement it? It should be the > > actual move plus mods to where AM/AC call getloadavg.m4 More importantly, there was a bug that bears on this reported today: I did run into an issue compiling the CVS plugins. It kept telling me it could not find getloadavg.c. However getloadavg.c was in the plugins directory. I dont know if this is right or not, probably not since I am not a developer, but I opened configure and set the following from: ac_config_libobj_dir=. to: ac_config_libobj_dir=./plugins and it works now. If there were bugs against snprintf, we could move that. But in feature freeze, I sort of feel we should move where we have bugs, leave it be where we don't. Any of us could handle it, I think. I thought Von had made lib in the first place (but my memory could be off) and I thought it would be just a little easier for the person who last messed with lib.Makefile.am -- Karl From sghosh at sghosh.org Tue Feb 18 16:54:06 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Tue Feb 18 16:54:06 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: <1045615087.15264.102.camel@miles.debisschop.net> Message-ID: On 18 Feb 2003, Karl DeBisschop wrote: > On Tue, 2003-02-18 at 18:04, Russell Scibetti wrote: > > If it would be helpful, this is something I can work on in parallel > > and submit a patch as I add to each plugin. > > It would be very helpful, but in no case are we adding perf data before > the release. We are in feature freeze. > > > Would it better to have the plugins output perfdata by default, or > > require a cmdline arg? I want to be as consistent between plugins as > > possible. > > So far, it has been enabled by default. > > Not sure if that is the right decision, however. > > If there were not size limits on the nagios data pipe, I'd send it by > default. But I'd hate to deserialize the pipe for an added few bytes of > perf data that wasn't even wanted. > > Thoughts anyone? I think Russell raised this question earlier about the pipe msg size. If Nagios is spawning a separate process and doing a spopen - then the pipe for each plugin invocation should be distinct. Perhaps we need to confirm this as a feature with Ethan. The impact would be on passive checks where the results are submitted through the named pipe. If there is another way to do the passive checks I'd be interested. > > > Russell > > > > Karl DeBisschop wrote: > > > On Tue, 2003-02-18 at 17:21, Russell Scibetti wrote: > > > > > > > Are the plugins in the 1.3b3 release going to have more built-in > > > > perfdata output? For example, check_disk can return the amount of space > > > > used, check_load can return the 3 load values, check_snmp can return the > > > > response in both the output and the perfdata (maybe if a cmd-line arg is > > > > given), etc. > > > > > > > > I'm just trying to figure out if I need to write additions to the b2 > > > > plugins for perfdata or not. We are looking to start dumping all > > > > performance related information into RRD. Thanks. > > > > > > > > Russell > > > > > > > > > > Those will go in immediately after the release. So hopefully in less > > > than 2 weeks. > > > > > > If you track the CVS with your changes, and provide patches against the > > > individual plugins at that time, you have a very high likelihood of > > > having them accepted almost as fast as you submit them. > > > > > > Even if you don't, I expect the perf data to happen very quickly after > > > the release. -- -sg From nagios at nagios.org Tue Feb 18 17:08:32 2003 From: nagios at nagios.org (Ethan Galstad) Date: Tue Feb 18 17:08:32 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: <1045615087.15264.102.camel@miles.debisschop.net> References: <3E52BBEF.1050909@quadrix.com> Message-ID: <3E52843B.3813.7531AC@localhost> On 18 Feb 2003 at 19:38, Karl DeBisschop wrote: > On Tue, 2003-02-18 at 18:04, Russell Scibetti wrote: > > If it would be helpful, this is something I can work on in parallel > > and submit a patch as I add to each plugin. > > It would be very helpful, but in no case are we adding perf data before > the release. We are in feature freeze. > > > Would it better to have the plugins output perfdata by default, or > > require a cmdline arg? I want to be as consistent between plugins as > > possible. > > So far, it has been enabled by default. > > Not sure if that is the right decision, however. > > If there were not size limits on the nagios data pipe, I'd send it by > default. But I'd hate to deserialize the pipe for an added few bytes of > perf data that wasn't even wanted. > > Thoughts anyone? > [snip] There might be a few problems if there are several targets that have perfdata returned (i.e. in check_snmp or check_disk, as Subhendu mentioned), but in general I would think most plugin output+perfdata can fit easily into the 350 character limit. In the worst case, the perf data would simply get snipped off at the 350 char limit by the child process before it got piped back to the parent process. If truncation becomes a real issue, I'll have to look at modifying the way the IPC is handled. I guess that's a long way of saying I think perfdata should be enabled by default. :-) Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From nagios at nagios.org Tue Feb 18 17:16:10 2003 From: nagios at nagios.org (Ethan Galstad) Date: Tue Feb 18 17:16:10 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: References: <1045615087.15264.102.camel@miles.debisschop.net> Message-ID: <3E528604.8444.7C29F3@localhost> On 18 Feb 2003 at 19:53, Subhendu Ghosh wrote: > On 18 Feb 2003, Karl DeBisschop wrote: > > > On Tue, 2003-02-18 at 18:04, Russell Scibetti wrote: > > > If it would be helpful, this is something I can work on in parallel > > > and submit a patch as I add to each plugin. > > > > It would be very helpful, but in no case are we adding perf data before > > the release. We are in feature freeze. > > > > > Would it better to have the plugins output perfdata by default, or > > > require a cmdline arg? I want to be as consistent between plugins as > > > possible. > > > > So far, it has been enabled by default. > > > > Not sure if that is the right decision, however. > > > > If there were not size limits on the nagios data pipe, I'd send it by > > default. But I'd hate to deserialize the pipe for an added few bytes of > > perf data that wasn't even wanted. > > > > Thoughts anyone? > > I think Russell raised this question earlier about the pipe msg size. If > Nagios is spawning a separate process and doing a spopen - then the pipe > for each plugin invocation should be distinct. > > Perhaps we need to confirm this as a feature with Ethan. > > The impact would be on passive checks where the results are submitted > through the named pipe. If there is another way to do the passive checks > I'd be interested. > There are two pipes of interest. One is the external command file, which is implemented as a FIFO and is restricted by the PIPE_BUF limit (512 bytes minimum for POSIX). Passive checks have to deal with this limit, but not active checks. The other pipe is used for IPC between the main (parent) Nagios process and the child processes. Each child writes the results of a plugin check (along with host/service name) to the pipe, at which point the parent reads it and process it. This pipe is also restricted by the PIPE_BUF limit. With host/service name overhead, you're left with about 350 bytes useable for plugin output+perfdata. It should be noted that *both* active and passive checks have results sent through this pipe. Passive checks enter through the FIFO and then get dumped into this pipe. If the size of the pipe becomes a real issue, we can probably break with POSIX compliance on most systems. The POSIX standard states a minimum of 512 bytes, but Linux has a 4K atomic write limit, while Solaris may have an 8K limit (I don't recall offhand). I guess I'll have to deal with it if and when it comes up. Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From sghosh at sghosh.org Tue Feb 18 17:42:13 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Tue Feb 18 17:42:13 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: <3E528604.8444.7C29F3@localhost> Message-ID: On Tue, 18 Feb 2003, Ethan Galstad wrote: > > There are two pipes of interest. One is the external command file, > which is implemented as a FIFO and is restricted by the PIPE_BUF > limit (512 bytes minimum for POSIX). Passive checks have to deal > with this limit, but not active checks. > > The other pipe is used for IPC between the main (parent) Nagios > process and the child processes. Each child writes the results of a > plugin check (along with host/service name) to the pipe, at which > point the parent reads it and process it. This pipe is also > restricted by the PIPE_BUF limit. With host/service name overhead, > you're left with about 350 bytes useable for plugin output+perfdata. > It should be noted that *both* active and passive checks have results > sent through this pipe. Passive checks enter through the FIFO and > then get dumped into this pipe. > > If the size of the pipe becomes a real issue, we can probably break > with POSIX compliance on most systems. The POSIX standard states a > minimum of 512 bytes, but Linux has a 4K atomic write limit, while > Solaris may have an 8K limit (I don't recall offhand). I guess I'll > have to deal with it if and when it comes up. > The second pipe - is that a single pipe per running install from the temp_file var in the config file? -- -sg From nagios at nagios.org Tue Feb 18 17:47:08 2003 From: nagios at nagios.org (Ethan Galstad) Date: Tue Feb 18 17:47:08 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: References: <3E528604.8444.7C29F3@localhost> Message-ID: <3E528D54.9225.98B8F2@localhost> On 18 Feb 2003 at 20:40, Subhendu Ghosh wrote: > On Tue, 18 Feb 2003, Ethan Galstad wrote: > > > > > There are two pipes of interest. One is the external command file, > > which is implemented as a FIFO and is restricted by the PIPE_BUF > > limit (512 bytes minimum for POSIX). Passive checks have to deal > > with this limit, but not active checks. > > > > The other pipe is used for IPC between the main (parent) Nagios > > process and the child processes. Each child writes the results of a > > plugin check (along with host/service name) to the pipe, at which > > point the parent reads it and process it. This pipe is also > > restricted by the PIPE_BUF limit. With host/service name overhead, > > you're left with about 350 bytes useable for plugin output+perfdata. > > It should be noted that *both* active and passive checks have results > > sent through this pipe. Passive checks enter through the FIFO and > > then get dumped into this pipe. > > > > If the size of the pipe becomes a real issue, we can probably break > > with POSIX compliance on most systems. The POSIX standard states a > > minimum of 512 bytes, but Linux has a 4K atomic write limit, while > > Solaris may have an 8K limit (I don't recall offhand). I guess I'll > > have to deal with it if and when it comes up. > > > > The second pipe - is that a single pipe per running install from the > temp_file var in the config file? > Its a single pipe, although its not implemented as a FIFO, so it doesn't exist anywhere in the filesystem - just in memory. You can think of it as a very limited type of socket that you would read/write from/to for network apps. It has one reader (the parent process) and multiple writers (the child processes). Its implemented with a call to pipe(2). Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From rcolley at cardaccess.com.au Tue Feb 18 18:17:11 2003 From: rcolley at cardaccess.com.au (Richard Colley) Date: Tue Feb 18 18:17:11 2003 Subject: [Nagiosplug-devel] Perf Data Message-ID: It would seem to me that relying on something like atomic write sizes is something of a hack. Maybe it is time to wrap the named external command pipe with an API that serialises messages into the pipe. Also, a simpler way of fixing this issue for the internal non-named pipes from Nagios to children would be to have one pipe per child. Given the number of children that would normally be active simultaneously, this shouldn't be a major issue. Richard -----Original Message----- From: Ethan Galstad [mailto:nagios at nagios.org] Sent: Wednesday, 19 February 2003 12:45 PM To: nagiosPlug Devel Subject: Re: [Nagiosplug-devel] Perf Data On 18 Feb 2003 at 20:40, Subhendu Ghosh wrote: > On Tue, 18 Feb 2003, Ethan Galstad wrote: > > > > > There are two pipes of interest. One is the external command file, > > which is implemented as a FIFO and is restricted by the PIPE_BUF > > limit (512 bytes minimum for POSIX). Passive checks have to deal > > with this limit, but not active checks. > > > > The other pipe is used for IPC between the main (parent) Nagios > > process and the child processes. Each child writes the results of a > > plugin check (along with host/service name) to the pipe, at which > > point the parent reads it and process it. This pipe is also > > restricted by the PIPE_BUF limit. With host/service name overhead, > > you're left with about 350 bytes useable for plugin output+perfdata. > > It should be noted that *both* active and passive checks have results > > sent through this pipe. Passive checks enter through the FIFO and > > then get dumped into this pipe. > > > > If the size of the pipe becomes a real issue, we can probably break > > with POSIX compliance on most systems. The POSIX standard states a > > minimum of 512 bytes, but Linux has a 4K atomic write limit, while > > Solaris may have an 8K limit (I don't recall offhand). I guess I'll > > have to deal with it if and when it comes up. > > > > The second pipe - is that a single pipe per running install from the > temp_file var in the config file? > Its a single pipe, although its not implemented as a FIFO, so it doesn't exist anywhere in the filesystem - just in memory. You can think of it as a very limited type of socket that you would read/write from/to for network apps. It has one reader (the parent process) and multiple writers (the child processes). Its implemented with a call to pipe(2). Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Nagiosplug-devel mailing list Nagiosplug-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 From karl at debisschop.net Wed Feb 19 00:28:04 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Wed Feb 19 00:28:04 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: References: Message-ID: <1045643194.15269.195.camel@miles.debisschop.net> On Tue, 2003-02-18 at 21:16, Richard Colley wrote: > It would seem to me that relying on something like atomic write sizes is > something of a hack. Practically speaking, the output has to be viewed on a web page. From that point of view, 300 characters is pretty long anyway, unless you are urlizing with a fairly long host name. So I'm willing to have the restriction imposed. However if we do not plan to change the pipes, then I'd want to code for it. At least in urlize where truncation can cause html syntax errors. Therein lies the rub. I don't think the plugin can code for it - it does not know the length of the host/service name. So at best, that can only be a guess. And if my quick scan of objects.h is correct, the hostname/service can be arbitrarily long. On this basis, I'm a little concerned. It has not been a big problem so far. And we can take more care to ensure that output length is less than about 350 bytes when --verbose is not specified. In the long run, I guess I don't like trusting to chance. Either hostname/servicename should be limited in length so a dependable output length calculation is possible, or we should implement something that is more completely robust. I don't want this to be too complex. I'd be quite happy to limit overhead from name lengths. -- Karl > Maybe it is time to wrap the named external command pipe with an API that > serialises messages into the pipe. > > Also, a simpler way of fixing this issue for the internal non-named pipes > from Nagios to children would be to have one pipe per child. Given the > number of children that would normally be active simultaneously, this > shouldn't be a major issue. > > Richard > > > -----Original Message----- > From: Ethan Galstad [mailto:nagios at nagios.org] > Sent: Wednesday, 19 February 2003 12:45 PM > To: nagiosPlug Devel > Subject: Re: [Nagiosplug-devel] Perf Data > > > On 18 Feb 2003 at 20:40, Subhendu Ghosh wrote: > > > On Tue, 18 Feb 2003, Ethan Galstad wrote: > > > > > > > > There are two pipes of interest. One is the external command file, > > > which is implemented as a FIFO and is restricted by the PIPE_BUF > > > limit (512 bytes minimum for POSIX). Passive checks have to deal > > > with this limit, but not active checks. > > > > > > The other pipe is used for IPC between the main (parent) Nagios > > > process and the child processes. Each child writes the results of a > > > plugin check (along with host/service name) to the pipe, at which > > > point the parent reads it and process it. This pipe is also > > > restricted by the PIPE_BUF limit. With host/service name overhead, > > > you're left with about 350 bytes useable for plugin output+perfdata. > > > It should be noted that *both* active and passive checks have results > > > sent through this pipe. Passive checks enter through the FIFO and > > > then get dumped into this pipe. > > > > > > If the size of the pipe becomes a real issue, we can probably break > > > with POSIX compliance on most systems. The POSIX standard states a > > > minimum of 512 bytes, but Linux has a 4K atomic write limit, while > > > Solaris may have an 8K limit (I don't recall offhand). I guess I'll > > > have to deal with it if and when it comes up. > > > > > > > The second pipe - is that a single pipe per running install from the > > temp_file var in the config file? > > > > Its a single pipe, although its not implemented as a FIFO, so it > doesn't exist anywhere in the filesystem - just in memory. You can > think of it as a very limited type of socket that you would > read/write from/to for network apps. It has one reader (the parent > process) and multiple writers (the child processes). Its implemented > with a call to pipe(2). > > > > Ethan Galstad, > Nagios Developer > --- > Email: nagios at nagios.org > Website: http://www.nagios.org > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From tonvoon at mac.com Wed Feb 19 03:22:04 2003 From: tonvoon at mac.com (Ton Voon) Date: Wed Feb 19 03:22:04 2003 Subject: [Nagiosplug-devel] Re: [Nagiosplug-checkins] CVS: nagiosplug Makefile.am,1.6,1.7 Message-ID: <469894.1045653676170.JavaMail.tonvoon@mac.com> Sorry, keep forgetting to reply-all - copying onto nagiosplug-devel list. I thought the m4 stuff does extra bits, such as check for other dependant libraries? Ton On Wednesday, February 19, 2003, at 08:33AM, Karl DeBisschop wrote: >My solution is to remove getloadavg.m4 and make a few mods to >configure.in. > >Specifically, all getloadavg.m4 does is allow you to put getloadavg.c >someplace other than in the top srcdir. So I redefine srcdir to look in >lib, then run AC_FUNC_GETLOADAVG, then reset srcdir: > >######################### >saved_srcdir=$srcdir >srcdir=$srcdir/lib >test -f $srcdir/getloadavg.c \ > || AC_MSG_ERROR([getloadavg.c is not in $srcdir]) >AC_FUNC_GETLOADAVG >srcdir=$saved_srcdir >######################## > >I agree that the old method was broken -- we've had one or two reports >on not finding getloadavg.c, in fact. This should fix that, I think. > >I sort of suspect that with this working, we may turn up different >issues on those systems where problems were prviously found. But I also >think we've made progress with this set of changes. > >-- >Karl > >On Tue, 2003-02-18 at 20:28, Ton Voon wrote: >> On Tuesday, February 18, 2003, at 10:18 pm, Karl DeBisschop wrote: >> >> > On Tue, 2003-02-18 at 16:58, Ton Voon wrote: >> >> Update of /cvsroot/nagiosplug/nagiosplug >> >> In directory sc8-pr-cvs1:/tmp/cvs-serv5780 >> >> >> >> Modified Files: >> >> Makefile.am >> >> Log Message: >> >> Add SUPPORT file to distribution >> >> >> >> >> >> Index: Makefile.am >> >> =================================================================== >> >> RCS file: /cvsroot/nagiosplug/nagiosplug/Makefile.am,v >> >> retrieving revision 1.6 >> >> retrieving revision 1.7 >> >> diff -C2 -r1.6 -r1.7 >> >> *** Makefile.am 10 Feb 2003 23:24:35 -0000 1.6 >> >> --- Makefile.am 18 Feb 2003 21:58:01 -0000 1.7 >> >> *************** >> >> *** 3,7 **** >> >> SUBDIRS = lib plugins plugins-scripts >> >> >> >> ! EXTRA_DIST = REQUIREMENTS acconfig.h subst.in subst.sh Helper.pm \ >> >> contrib nagios-plugins.spec.in getloadavg.m4 >> >> >> >> --- 3,7 ---- >> >> SUBDIRS = lib plugins plugins-scripts >> >> >> >> ! EXTRA_DIST = REQUIREMENTS SUPPORT acconfig.h subst.in subst.sh >> >> Helper.pm \ >> >> contrib nagios-plugins.spec.in getloadavg.m4 >> > >> > You did the getopt changes, right? >> > >> > Should we put getloadavg.c into lib as well? >> > >> > If so, do you ahve a few moments to implement it? It should be the >> > actual move plus mods to where AM/AC call getloadavg.m4 >> > >> >> Well, I've made the changes, and they work on my MacOSX system with: >> >> $ aclocal -I lib >> $ autoheader >> $ autoconf >> $ automake >> >> However, I think I have broken something as I get failures when running >> autoheader on a Linux 2.4 system: >> >> $ aclocal -I lib >> $ autoheader >> /usr/bin/autoheader2.13: eval: line 16: unexpected EOF while looking >> for matching ``' >> /usr/bin/autoheader2.13: eval: line 621: syntax error: unexpected end >> of file >> >> My MacOSX system is at autoconf is 2.52 and automake 1.6.1. The Linux >> system is at autoconf 2.13 and automake 1.4. >> >> There is no problem if you ignore getloadavg.m4: >> >> $ aclocal >> $ grep getload aclocal.m4 >> $ autoheader >> $ autoconf >> $ automake >> >> getloadavg.m4 is exactly the same as the one previously, which makes me >> think that it never included the file correctly before. This would >> introduce a dependency on autoconf and automake. >> >> What do you want to do? I think we should maybe revisit this for 1.4, >> but revert back for now. >> >> Ton, needing some sleep now... > > > From noreply at sourceforge.net Wed Feb 19 09:12:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 19 09:12:10 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-689351 ] check_mysql Message-ID: Feature Requests item #689351, was opened at 2003-02-19 08:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=689351&group_id=29880 Category: Interface Improvements (example) Group: Next Release (example) Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: check_mysql Initial Comment: in saint there was check_mysql feature where you could setup a netsaint client in mysql and it would login to database to check if mysql was up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=689351&group_id=29880 From kdebisschop at mail.debisschop.net Wed Feb 19 10:41:33 2003 From: kdebisschop at mail.debisschop.net (Karl DeBisschop) Date: Wed Feb 19 10:41:33 2003 Subject: [Nagiosplug-devel] Re: CVS: nagiosplug Makefile.am,1.6,1.7 In-Reply-To: <469894.1045653676170.JavaMail.tonvoon@mac.com> References: <469894.1045653676170.JavaMail.tonvoon@mac.com> Message-ID: Ton Voon writes: > Sorry, keep forgetting to reply-all - copying onto nagiosplug-devel list. > > I thought the m4 stuff does extra bits, such as check for other dependant libraries? Sort of. AFAICT, the comment in its header was correct- it is the same as comes with autoconf FOR SOME GIVEN VERSION. I don't know exactly which one. But that is why it only worked with specific versions of autoconf. Over time, the autoconf code changes (hopefully improves). But it is not always cross compatible, thus our problems. My little hack into the $srcdir value is a cheap way to try and surmount that version dependence. But we give up some imporvements that might otherwise be part of the autoconf that I make the snapshot from. -- Karl From noreply at sourceforge.net Wed Feb 19 12:29:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 19 12:29:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-689563 ] check_dns -a fails on FreeBSD Message-ID: Bugs item #689563, was opened at 2003-02-19 21:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=689563&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Simon L. Nielsen (nitro) Assigned to: Nobody/Anonymous (nobody) Summary: check_dns -a fails on FreeBSD Initial Comment: When using the -a option to check_dns on FreeBSD it fails since nslookup on FreeBSD apparently prints the address with more whitespace than check_dns expects. Example : /tmp/nagios-plugins-1.3.0-beta2/plugins/check_dns -H www.nitro.dk -a 212.242.113.79 -s 192.168.3.2 DNS CRITICAL - expected 212.242.113.79 but got 212.242.113.79 The following fix (it should also be attached) strips spaces before the IP. http://simon.nitro.dk/patch/nagios/check_dns_freebsd.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=689563&group_id=29880 From noreply at sourceforge.net Wed Feb 19 16:17:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 19 16:17:16 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-689679 ] New plugin: check_oracle_tbs Message-ID: Patches item #689679, was opened at 2003-02-19 16:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=689679&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Koyle (koiler) Assigned to: Nobody/Anonymous (nobody) Summary: New plugin: check_oracle_tbs Initial Comment: This is a simple plugin to connect to an oracle database and check for tablespaces that are nearly full. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=689679&group_id=29880 From kdebisschop at alert.infoplease.com Wed Feb 19 20:36:19 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Wed Feb 19 20:36:19 2003 Subject: [Nagiosplug-devel] Plugins v1.3.0 Beta 3 released Message-ID: <1045715719.1111.7.camel@miles.debisschop.net> Uploaded to sourceforge earlier tonight. -- Karl DeBisschop From kdebisschop at alert.infoplease.com Wed Feb 19 20:42:14 2003 From: kdebisschop at alert.infoplease.com (Karl DeBisschop) Date: Wed Feb 19 20:42:14 2003 Subject: [Nagiosplug-devel] Changes to tracker status Message-ID: <1045716073.1111.14.camel@miles.debisschop.net> In trying to close out tickets for this beta, I noticed I spent too much time waiting on a peeople to comment on whether anonymous tickets had been resolved. It's annoying. So I changed setting on all the tracker modules to require login for submissions. The action was taken unilaterally, but I'm happy to entertain discussion after the fact -- it can be reverted if so desired. While I was at it, I enabled emailon status changes. IIRC, someone said there were some bugs involved -- maybe that the mailing list did not pass them on without approval? Has the bug been fixed? That change can be reverted too. Or we can set up an alias on a mailserver we control to forward the changes to the core group. -- Karl DeBisschop From sghosh at sghosh.org Wed Feb 19 21:00:07 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Wed Feb 19 21:00:07 2003 Subject: [Nagiosplug-devel] Changes to tracker status In-Reply-To: <1045716073.1111.14.camel@miles.debisschop.net> Message-ID: On 19 Feb 2003, Karl DeBisschop wrote: > In trying to close out tickets for this beta, I noticed I spent too much > time waiting on a peeople to comment on whether anonymous tickets had > been resolved. > > It's annoying. > > So I changed setting on all the tracker modules to require login for > submissions. The action was taken unilaterally, but I'm happy to > entertain discussion after the fact -- it can be reverted if so desired. I'm for login over anonymous submissions > > While I was at it, I enabled emailon status changes. IIRC, someone said > there were some bugs involved -- maybe that the mailing list did not > pass them on without approval? Has the bug been fixed? > > That change can be reverted too. Or we can set up an alias on a > mailserver we control to forward the changes to the core group. The bug is still there. mailadmins get a message for every submission :( Passing it through a mailserver that adds a valid To:/Cc: field would be useful. -- -sg From jeremy+nagios at UnderGrid.net Wed Feb 19 21:21:03 2003 From: jeremy+nagios at UnderGrid.net (Jeremy T. Bouse) Date: Wed Feb 19 21:21:03 2003 Subject: [Nagiosplug-devel] Changes to tracker status In-Reply-To: <1045716073.1111.14.camel@miles.debisschop.net> References: <1045716073.1111.14.camel@miles.debisschop.net> Message-ID: <20030220051907.GA30039@UnderGrid.net> You'll get no complaints on this one from me... I actually enabled this by default on my own project I've started on SF... As for the posts to the mailing lists it could be because the list is setup for submissions only from list members... It might allow spam to make it in but opening it up would allow the tracker emails to come through... I think you would have to do it through the Mailman interface itself rather than through the SF list admin pages... Jeremy On Wed, Feb 19, 2003 at 11:41:13PM -0500, Karl DeBisschop wrote: > In trying to close out tickets for this beta, I noticed I spent too much > time waiting on a peeople to comment on whether anonymous tickets had > been resolved. > > It's annoying. > > So I changed setting on all the tracker modules to require login for > submissions. The action was taken unilaterally, but I'm happy to > entertain discussion after the fact -- it can be reverted if so desired. > > While I was at it, I enabled emailon status changes. IIRC, someone said > there were some bugs involved -- maybe that the mailing list did not > pass them on without approval? Has the bug been fixed? > > That change can be reverted too. Or we can set up an alias on a > mailserver we control to forward the changes to the core group. > > -- > Karl DeBisschop > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From nagios at nagios.org Wed Feb 19 21:40:06 2003 From: nagios at nagios.org (Ethan Galstad) Date: Wed Feb 19 21:40:06 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: <1045643194.15269.195.camel@miles.debisschop.net> References: Message-ID: <3E541545.904.1E0F449@localhost> On 19 Feb 2003 at 3:26, Karl DeBisschop wrote: > On Tue, 2003-02-18 at 21:16, Richard Colley wrote: > > It would seem to me that relying on something like atomic write sizes is > > something of a hack. > > > > Practically speaking, the output has to be viewed on a web page. From > that point of view, 300 characters is pretty long anyway, unless you are > urlizing with a fairly long host name. > > So I'm willing to have the restriction imposed. However if we do not > plan to change the pipes, then I'd want to code for it. At least in > urlize where truncation can cause html syntax errors. > > > > > > Therein lies the rub. I don't think the plugin can code for it - it does > not know the length of the host/service name. So at best, that can only > be a guess. And if my quick scan of objects.h is correct, the > hostname/service can be arbitrarily long. > > On this basis, I'm a little concerned. It has not been a big problem so > far. And we can take more care to ensure that output length is less than > about 350 bytes when --verbose is not specified. > You must have missed the first few lines in objects.h :-) #define MAX_HOSTNAME_LENGTH 64 /* max. host name length */ #define MAX_SERVICEDESC_LENGTH 64 /* max. service description length */ #define MAX_PLUGINOUTPUT_LENGTH 352 /* max. length of plugin output */ > > > In the long run, I guess I don't like trusting to chance. Either > hostname/servicename should be limited in length so a dependable output > length calculation is possible, or we should implement something that is > more completely robust. > > I don't want this to be too complex. I'd be quite happy to limit > overhead from name lengths. The daemon enforces the max length of the plugin output it stores regardless of how long the plugin output length actually is, so as long as output is 351 chars or less things should be fine. It may increase in the future, but at least its a minimum value to work with. The host/service fields are trimmed to 64 chars each when results are getting sent back to the parent. Although I did notice that there are no errors/warnings being generated at startup if a host name or service description exceeds that length. I'll have to fix the bug. > > -- > Karl > > > Maybe it is time to wrap the named external command pipe with an API that > > serialises messages into the pipe. > > > > Also, a simpler way of fixing this issue for the internal non-named pipes > > from Nagios to children would be to have one pipe per child. Given the > > number of children that would normally be active simultaneously, this > > shouldn't be a major issue. > > > > Richard > > > > > > -----Original Message----- > > From: Ethan Galstad [mailto:nagios at nagios.org] > > Sent: Wednesday, 19 February 2003 12:45 PM > > To: nagiosPlug Devel > > Subject: Re: [Nagiosplug-devel] Perf Data > > > > > > On 18 Feb 2003 at 20:40, Subhendu Ghosh wrote: > > > > > On Tue, 18 Feb 2003, Ethan Galstad wrote: > > > > > > > > > > > There are two pipes of interest. One is the external command file, > > > > which is implemented as a FIFO and is restricted by the PIPE_BUF > > > > limit (512 bytes minimum for POSIX). Passive checks have to deal > > > > with this limit, but not active checks. > > > > > > > > The other pipe is used for IPC between the main (parent) Nagios > > > > process and the child processes. Each child writes the results of a > > > > plugin check (along with host/service name) to the pipe, at which > > > > point the parent reads it and process it. This pipe is also > > > > restricted by the PIPE_BUF limit. With host/service name overhead, > > > > you're left with about 350 bytes useable for plugin output+perfdata. > > > > It should be noted that *both* active and passive checks have results > > > > sent through this pipe. Passive checks enter through the FIFO and > > > > then get dumped into this pipe. > > > > > > > > If the size of the pipe becomes a real issue, we can probably break > > > > with POSIX compliance on most systems. The POSIX standard states a > > > > minimum of 512 bytes, but Linux has a 4K atomic write limit, while > > > > Solaris may have an 8K limit (I don't recall offhand). I guess I'll > > > > have to deal with it if and when it comes up. > > > > > > > > > > The second pipe - is that a single pipe per running install from the > > > temp_file var in the config file? > > > > > > > Its a single pipe, although its not implemented as a FIFO, so it > > doesn't exist anywhere in the filesystem - just in memory. You can > > think of it as a very limited type of socket that you would > > read/write from/to for network apps. It has one reader (the parent > > process) and multiple writers (the child processes). Its implemented > > with a call to pipe(2). > > > > > > > > Ethan Galstad, > > Nagios Developer > > --- > > Email: nagios at nagios.org > > Website: http://www.nagios.org > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > > The most comprehensive and flexible code editor you can use. > > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > > www.slickedit.com/sourceforge > > _______________________________________________ > > Nagiosplug-devel mailing list > > Nagiosplug-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > ::: Please include plugins version (-v) and OS when reporting any issue. > > ::: Messages without supporting info will risk being sent to /dev/null > > > > --- > > Incoming mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 > > > > > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > > The most comprehensive and flexible code editor you can use. > > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > > www.slickedit.com/sourceforge > > _______________________________________________ > > Nagiosplug-devel mailing list > > Nagiosplug-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > ::: Please include plugins version (-v) and OS when reporting any issue. > > ::: Messages without supporting info will risk being sent to /dev/null > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From nagios at nagios.org Wed Feb 19 21:50:07 2003 From: nagios at nagios.org (Ethan Galstad) Date: Wed Feb 19 21:50:07 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: Message-ID: <3E5417AC.29997.1EA5501@localhost> On 19 Feb 2003 at 13:16, Richard Colley wrote: > It would seem to me that relying on something like atomic write sizes is > something of a hack. Agreed, but its simple. :-) > > Maybe it is time to wrap the named external command pipe with an API that > serialises messages into the pipe. That could get pretty ugly and you would loose the benefit of a simple interface for external apps to use. A better solution would probably be to implement it as a unix domain socket instead of a FIFO. > > Also, a simpler way of fixing this issue for the internal non-named pipes > from Nagios to children would be to have one pipe per child. Given the > number of children that would normally be active simultaneously, this > shouldn't be a major issue. Yep, I'll take a look at implementing this in 2.0 > > Richard > > > -----Original Message----- > From: Ethan Galstad [mailto:nagios at nagios.org] > Sent: Wednesday, 19 February 2003 12:45 PM > To: nagiosPlug Devel > Subject: Re: [Nagiosplug-devel] Perf Data > > > On 18 Feb 2003 at 20:40, Subhendu Ghosh wrote: > > > On Tue, 18 Feb 2003, Ethan Galstad wrote: > > > > > > > > There are two pipes of interest. One is the external command file, > > > which is implemented as a FIFO and is restricted by the PIPE_BUF > > > limit (512 bytes minimum for POSIX). Passive checks have to deal > > > with this limit, but not active checks. > > > > > > The other pipe is used for IPC between the main (parent) Nagios > > > process and the child processes. Each child writes the results of a > > > plugin check (along with host/service name) to the pipe, at which > > > point the parent reads it and process it. This pipe is also > > > restricted by the PIPE_BUF limit. With host/service name overhead, > > > you're left with about 350 bytes useable for plugin output+perfdata. > > > It should be noted that *both* active and passive checks have results > > > sent through this pipe. Passive checks enter through the FIFO and > > > then get dumped into this pipe. > > > > > > If the size of the pipe becomes a real issue, we can probably break > > > with POSIX compliance on most systems. The POSIX standard states a > > > minimum of 512 bytes, but Linux has a 4K atomic write limit, while > > > Solaris may have an 8K limit (I don't recall offhand). I guess I'll > > > have to deal with it if and when it comes up. > > > > > > > The second pipe - is that a single pipe per running install from the > > temp_file var in the config file? > > > > Its a single pipe, although its not implemented as a FIFO, so it > doesn't exist anywhere in the filesystem - just in memory. You can > think of it as a very limited type of socket that you would > read/write from/to for network apps. It has one reader (the parent > process) and multiple writers (the child processes). Its implemented > with a call to pipe(2). > > > > Ethan Galstad, > Nagios Developer > --- > Email: nagios at nagios.org > Website: http://www.nagios.org > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003 > > Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From karl at debisschop.net Wed Feb 19 22:08:05 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Wed Feb 19 22:08:05 2003 Subject: [Nagiosplug-devel] Changes to tracker status In-Reply-To: <20030220051907.GA30039@UnderGrid.net> References: <1045716073.1111.14.camel@miles.debisschop.net> <20030220051907.GA30039@UnderGrid.net> Message-ID: <1045721103.11521.5.camel@miles.debisschop.net> On Thu, 2003-02-20 at 00:19, Jeremy T. Bouse wrote: > You'll get no complaints on this one from me... I actually > enabled this by default on my own project I've started on SF... As for > the posts to the mailing lists it could be because the list is setup for > submissions only from list members... It might allow spam to make it in > but opening it up would allow the tracker emails to come through... I > think you would have to do it through the Mailman interface itself > rather than through the SF list admin pages... If that's the case, maybe we could add the tracker originator as a member? > Jeremy > > On Wed, Feb 19, 2003 at 11:41:13PM -0500, Karl DeBisschop wrote: > > In trying to close out tickets for this beta, I noticed I spent too much > > time waiting on a peeople to comment on whether anonymous tickets had > > been resolved. > > > > It's annoying. > > > > So I changed setting on all the tracker modules to require login for > > submissions. The action was taken unilaterally, but I'm happy to > > entertain discussion after the fact -- it can be reverted if so desired. > > > > While I was at it, I enabled emailon status changes. IIRC, someone said > > there were some bugs involved -- maybe that the mailing list did not > > pass them on without approval? Has the bug been fixed? > > > > That change can be reverted too. Or we can set up an alias on a > > mailserver we control to forward the changes to the core group. > > > > -- > > Karl DeBisschop > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > > The most comprehensive and flexible code editor you can use. > > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > > www.slickedit.com/sourceforge > > _______________________________________________ > > Nagiosplug-devel mailing list > > Nagiosplug-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > > ::: Please include plugins version (-v) and OS when reporting any issue. > > ::: Messages without supporting info will risk being sent to /dev/null > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From karl at debisschop.net Wed Feb 19 22:16:03 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Wed Feb 19 22:16:03 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: <3E541545.904.1E0F449@localhost> References: <3E541545.904.1E0F449@localhost> Message-ID: <1045721636.11719.3.camel@miles.debisschop.net> On Thu, 2003-02-20 at 00:37, Ethan Galstad wrote: > You must have missed the first few lines in objects.h :-) > > > #define MAX_HOSTNAME_LENGTH 64 /* max. host name length */ > #define MAX_SERVICEDESC_LENGTH 64 /* max. service description length */ > #define MAX_PLUGINOUTPUT_LENGTH 352 /* max. length of plugin output */ I only did a grep of a few things. I didn't know the varable names, and I was more focused on getting the last plugin beta out. I'm glad to be proven wrong. Given those limits, it seems reasonable to just build the MAX_PLUGINOUTPUT_LENGTH constant into the plugins in the future. -- Karl From karl at debisschop.net Wed Feb 19 22:20:05 2003 From: karl at debisschop.net (Karl DeBisschop) Date: Wed Feb 19 22:20:05 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: <3E5417AC.29997.1EA5501@localhost> References: <3E5417AC.29997.1EA5501@localhost> Message-ID: <1045721888.11719.8.camel@miles.debisschop.net> On Thu, 2003-02-20 at 00:47, Ethan Galstad wrote: > On 19 Feb 2003 at 13:16, Richard Colley wrote: > > > It would seem to me that relying on something like atomic write sizes is > > something of a hack. > > Agreed, but its simple. :-) > > > > > Maybe it is time to wrap the named external command pipe with an API that > > serialises messages into the pipe. > > That could get pretty ugly and you would loose the benefit of a > simple interface for external apps to use. A better solution would > probably be to implement it as a unix domain socket instead of a > FIFO. > > > > > Also, a simpler way of fixing this issue for the internal non-named pipes > > from Nagios to children would be to have one pipe per child. Given the > > number of children that would normally be active simultaneously, this > > shouldn't be a major issue. > > Yep, I'll take a look at implementing this in 2.0 In a sense, this doesn't help though. Since the named pipe still has the limits, the plugins still need to check their length, right? I know nagios will truncate. but that is a problem if truncation leads to unbalance HTML, or to altered perf data. -- Karl From jeremy+nagios at UnderGrid.net Thu Feb 20 06:29:08 2003 From: jeremy+nagios at UnderGrid.net (Jeremy T. Bouse) Date: Thu Feb 20 06:29:08 2003 Subject: [Nagiosplug-devel] Changes to tracker status In-Reply-To: <1045721103.11521.5.camel@miles.debisschop.net> References: <1045716073.1111.14.camel@miles.debisschop.net> <20030220051907.GA30039@UnderGrid.net> <1045721103.11521.5.camel@miles.debisschop.net> Message-ID: <20030220142746.GA7280@UnderGrid.net> On Thu, Feb 20, 2003 at 01:05:43AM -0500, Karl DeBisschop wrote: > On Thu, 2003-02-20 at 00:19, Jeremy T. Bouse wrote: > > You'll get no complaints on this one from me... I actually > > enabled this by default on my own project I've started on SF... As for > > the posts to the mailing lists it could be because the list is setup for > > submissions only from list members... It might allow spam to make it in > > but opening it up would allow the tracker emails to come through... I > > think you would have to do it through the Mailman interface itself > > rather than through the SF list admin pages... > > If that's the case, maybe we could add the tracker originator as a > member? > Provided the tracker messages all originate from the same address that is a possible solution as well... I hadn't been paying close enough attention to see if they all came from the same address or not... Jeremy From kdebisschop at mail.debisschop.net Thu Feb 20 08:34:03 2003 From: kdebisschop at mail.debisschop.net (Karl DeBisschop) Date: Thu Feb 20 08:34:03 2003 Subject: [Nagiosplug-devel] Re: Changes to tracker status In-Reply-To: <20030220142746.GA7280@UnderGrid.net> References: <1045716073.1111.14.camel@miles.debisschop.net> <20030220051907.GA30039@UnderGrid.net> <1045721103.11521.5.camel@miles.debisschop.net> <20030220142746.GA7280@UnderGrid.net> Message-ID: Jeremy T. Bouse writes: > On Thu, Feb 20, 2003 at 01:05:43AM -0500, Karl DeBisschop wrote: >> On Thu, 2003-02-20 at 00:19, Jeremy T. Bouse wrote: >> > You'll get no complaints on this one from me... I actually >> > enabled this by default on my own project I've started on SF... As for >> > the posts to the mailing lists it could be because the list is setup for >> > submissions only from list members... It might allow spam to make it in >> > but opening it up would allow the tracker emails to come through... I >> > think you would have to do it through the Mailman interface itself >> > rather than through the SF list admin pages... >> >> If that's the case, maybe we could add the tracker originator as a >> member? >> > Provided the tracker messages all originate from the same > address that is a possible solution as well... I hadn't been paying > close enough attention to see if they all came from the same address or > not... It poses as noreply at sourceforge.net -- it looks like it's actually 'nobody' on the web server host. As far as I can tell so far, it's consistent. -- Karl From noreply at sourceforge.net Thu Feb 20 10:51:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 20 10:51:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-689679 ] New plugin: check_oracle_tbs Message-ID: Patches item #689679, was opened at 2003-02-19 18:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=689679&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Koyle (koiler) Assigned to: Nobody/Anonymous (nobody) Summary: New plugin: check_oracle_tbs Initial Comment: This is a simple plugin to connect to an oracle database and check for tablespaces that are nearly full. ---------------------------------------------------------------------- Comment By: John Marquart (vaix) Date: 2003-02-20 13:15 Message: Logged In: YES user_id=102671 John - I will check out your code - am quite excited about how you implemented it. Just a FYI - the latest CVS version of the check_oracle plugin (1.4) contains code to both check tablespace utilization as well as cache hit percentages (library and data buffers). -vaix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=689679&group_id=29880 From sghosh at sghosh.org Thu Feb 20 11:07:06 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Thu Feb 20 11:07:06 2003 Subject: [Nagiosplug-devel] Re: Changes to tracker status In-Reply-To: Message-ID: I added noreplyATsourceforge as an acceptable alias for nagiosplug-devel list. So we should start to see the tracker changes flowing directly to the list. Will let you know if this isn't so... -sg On Thu, 20 Feb 2003, Karl DeBisschop wrote: > Jeremy T. Bouse writes: > > > On Thu, Feb 20, 2003 at 01:05:43AM -0500, Karl DeBisschop wrote: > >> On Thu, 2003-02-20 at 00:19, Jeremy T. Bouse wrote: > >> > You'll get no complaints on this one from me... I actually > >> > enabled this by default on my own project I've started on SF... As for > >> > the posts to the mailing lists it could be because the list is setup for > >> > submissions only from list members... It might allow spam to make it in > >> > but opening it up would allow the tracker emails to come through... I > >> > think you would have to do it through the Mailman interface itself > >> > rather than through the SF list admin pages... > >> > >> If that's the case, maybe we could add the tracker originator as a > >> member? > >> > > Provided the tracker messages all originate from the same > > address that is a possible solution as well... I hadn't been paying > > close enough attention to see if they all came from the same address or > > not... > > It poses as noreply at sourceforge.net -- it looks like it's actually 'nobody' > on the web server host. > > As far as I can tell so far, it's consistent. > > -- > Karl > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > -- From sghosh at sghosh.org Thu Feb 20 16:32:14 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Thu Feb 20 16:32:14 2003 Subject: [Nagiosplug-devel] contrib plugins Message-ID: While beta3 is being tested, I am planning on adding all the contributed plugins to the contrib directory after any suitable massaging unless there are any objections. -- -sg From nagios at nagios.org Thu Feb 20 21:20:12 2003 From: nagios at nagios.org (Ethan Galstad) Date: Thu Feb 20 21:20:12 2003 Subject: [Nagiosplug-devel] Perf Data In-Reply-To: <1045721888.11719.8.camel@miles.debisschop.net> References: <3E5417AC.29997.1EA5501@localhost> Message-ID: <3E55624F.30382.15B1513@localhost> On 20 Feb 2003 at 1:18, Karl DeBisschop wrote: > On Thu, 2003-02-20 at 00:47, Ethan Galstad wrote: > > On 19 Feb 2003 at 13:16, Richard Colley wrote: > > > > > It would seem to me that relying on something like atomic write sizes is > > > something of a hack. > > > > Agreed, but its simple. :-) > > > > > > > > Maybe it is time to wrap the named external command pipe with an API that > > > serialises messages into the pipe. > > > > That could get pretty ugly and you would loose the benefit of a > > simple interface for external apps to use. A better solution would > > probably be to implement it as a unix domain socket instead of a > > FIFO. > > > > > > > > Also, a simpler way of fixing this issue for the internal non-named pipes > > > from Nagios to children would be to have one pipe per child. Given the > > > number of children that would normally be active simultaneously, this > > > shouldn't be a major issue. > > > > Yep, I'll take a look at implementing this in 2.0 > > In a sense, this doesn't help though. Since the named pipe still has the > limits, the plugins still need to check their length, right? > > I know nagios will truncate. but that is a problem if truncation leads > to unbalance HTML, or to altered perf data. > > -- > Karl > > If the external command file is implemented as a unix domain socket and the interal pipe is changed so that there is one pipe per child, there is no problem. The problem that exists now is due to the fact that there are multiple writers per pipe, so I need to worry about atomic write sizes. With one pipe per child for the internal stuff, there will be no theoretical limit as to how much data can be passed back to the daemon. The unix domain socket is essential the same as a network socket (each writer has its own connection), so there shouldn't be any limits there either. As far as developing for limits, I'd use the current ~350 char limit for plugin output+perf data. So much is changing internally right now that I can't guarantee I'll pull off the pipe/socket changes in 2.0. Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From a.weber at ico.de Fri Feb 21 06:27:05 2003 From: a.weber at ico.de (Alexander Weber) Date: Fri Feb 21 06:27:05 2003 Subject: [Nagiosplug-devel] plugin for Keyboard Simulator? Message-ID: Telejet GmbH - an affiliate - produces and sells a device called "Telejet Keyboard Simulator" (TKS). This is a small gadget that is plugged into the keyboard connector of a server. With a piece of software, the user can remote control or - to be a bit more specific - restart it by a clean shutdown without the risk of ruining file systems or databases. The software controlling the TKS is intended to be used interactively via a web interface. Information about the TKS can be found at http://www.webresetter.com Some time ago, a customer asked for a way to make it work with a watchdog software. As I do not have the time to maintain that software, I would like to know if there is someone out there who is willing and able to write and maintain a plug-in to Nagios. As far as I am concerned, I can and will provide any necessary information and chunks of perl code. The programming task should be easy, probably just a day's work. We do not plan to commercially exploit the software; it's license does not matter. Also, I do not demand from anyone to write this software if he doesn't want to use it. If you don't need such a plug-in (currently I am not aware about the number of TKS sold outside Germany) please ignore this message. -- Mit freundlichen Gr??en / best regards, Alexander P. Weber - ICO Innovative Computer GmbH Zuckmayerstra?e 15 - 65582 Diez Phone: +49 6432 9139350 - Mobile: +49 160 97210506 From marc.brun at maif.fr Fri Feb 21 06:35:06 2003 From: marc.brun at maif.fr (marc.brun (Marc BRUN)) Date: Fri Feb 21 06:35:06 2003 Subject: [Nagiosplug-devel] Error in check_ircd plugin Message-ID: <20030221_153413_C1_19d24895_C2_0000003e_Name_00433211539@maif.fr> plugin version : 1.0.3-beta3 I tried to use check_ircd, but got an error message at line 55 in the perl script : use lib "/usr/local/nagios/libexec" /libexec I advice to change it to : use lib "/usr/local/nagios/libexec"; /libexec shouldn't be there, and missing ";" Have fun Marc From sghosh at sghosh.org Fri Feb 21 10:38:05 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Fri Feb 21 10:38:05 2003 Subject: [Nagiosplug-devel] Error in check_ircd plugin In-Reply-To: <20030221_153413_C1_19d24895_C2_0000003e_Name_00433211539@maif.fr> Message-ID: On 21 Feb 2003, marc.brun wrote: > plugin version : 1.0.3-beta3 > > I tried to use check_ircd, but got an error message at line 55 in the perl script : > use lib "/usr/local/nagios/libexec" /libexec > I advice to change it to : > use lib "/usr/local/nagios/libexec"; > > /libexec shouldn't be there, and missing ";" > > Have fun > Marc > Is this from the tarball? What OS/awk version are you running? I can't reproduce it. -- -sg From noreply at sourceforge.net Fri Feb 21 11:30:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:30:08 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-689679 ] New plugin: check_oracle_tbs Message-ID: New Plugins item #689679, was opened at 2003-02-19 18:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=689679&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Koyle (koiler) Assigned to: Nobody/Anonymous (nobody) Summary: New plugin: check_oracle_tbs Initial Comment: This is a simple plugin to connect to an oracle database and check for tablespaces that are nearly full. ---------------------------------------------------------------------- Comment By: John Marquart (vaix) Date: 2003-02-20 13:15 Message: Logged In: YES user_id=102671 John - I will check out your code - am quite excited about how you implemented it. Just a FYI - the latest CVS version of the check_oracle plugin (1.4) contains code to both check tablespace utilization as well as cache hit percentages (library and data buffers). -vaix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=689679&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:30:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:30:17 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-656170 ] New check_cpu nagios plugin submission Message-ID: New Plugins item #656170, was opened at 2002-12-19 02:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=656170&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Dixon (fuzzyping) Assigned to: Nobody/Anonymous (nobody) Summary: New check_cpu nagios plugin submission Initial Comment: Here is a check_cpu (load averages) plugin that I wrote in perl. Feel free to use... or destroy. ;-) -J. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-01-30 11:48 Message: Logged In: YES user_id=664364 Thanks for the submission. New plugins are not a priority at the moment, but we are looking into it. Jason also says: These all use a standard pre-shared ssh key connection to connect and gather the relevant info. There will need to be a public ssh key for the local nagios user in the remote users' ~/.ssh/authorized_keys file, in addition to a copy of the public host key from the remote system in the local nagios user's ~/.ssh/known_hosts file. Very similar to check_by_ssh configuration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=656170&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:31:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:31:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-656169 ] New check_df nagios plugin submission Message-ID: New Plugins item #656169, was opened at 2002-12-19 02:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=656169&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Dixon (fuzzyping) Assigned to: Nobody/Anonymous (nobody) Summary: New check_df nagios plugin submission Initial Comment: Here is a check_df (diskfree) plugin that I wrote in perl. Feel free to use... or destroy. ;-) -J. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-01-30 11:43 Message: Logged In: YES user_id=664364 Thanks for the submission. New plugins are not a priority at the moment, but we are looking into it. Jason also says: These all use a standard pre-shared ssh key connection to connect and gather the relevant info. There will need to be a public ssh key for the local nagios user in the remote users' ~/.ssh/authorized_keys file, in addition to a copy of the public host key from the remote system in the local nagios user's ~/.ssh/known_hosts file. Very similar to check_by_ssh configuration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=656169&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:31:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:31:05 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-656173 ] New check_pfstate nagios plugin Message-ID: New Plugins item #656173, was opened at 2002-12-19 02:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=656173&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Dixon (fuzzyping) Assigned to: Nobody/Anonymous (nobody) Summary: New check_pfstate nagios plugin Initial Comment: Here is a check_pfstate plugin for nagios on *OPENBSD* that I wrote in perl. It gathers the number of current state entries (pfctl -s info). -J. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-01-30 11:48 Message: Logged In: YES user_id=664364 Thanks for the submission. New plugins are not a priority at the moment, but we are looking into it. Jason also says: These all use a standard pre-shared ssh key connection to connect and gather the relevant info. There will need to be a public ssh key for the local nagios user in the remote users' ~/.ssh/authorized_keys file, in addition to a copy of the public host key from the remote system in the local nagios user's ~/.ssh/known_hosts file. Very similar to check_by_ssh configuration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=656173&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:31:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:31:06 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-619255 ] New plugin: check_mysqlslave.pl Message-ID: New Plugins item #619255, was opened at 2002-10-06 10:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=619255&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mario Witte (chengfu) Assigned to: Nobody/Anonymous (nobody) Summary: New plugin: check_mysqlslave.pl Initial Comment: I'd like to contribute the attaches service check plugin. check_mysqlslave.pl checks if a MySQL-Replication is still running. The attached archive contains the skript itself, a patch to configure.in and a patch to plugin-scripts/Makefile.am. I tried to create the script as outlined in the developer guidelines, but if there are flaws or errors or whatever please contact me. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-01-30 12:05 Message: Logged In: YES user_id=664364 Thanks for the patch. New plugins are not a priority for 1.3, but will be considered for 1.4. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-01-02 10:59 Message: Logged In: NO I am just wandering what privileges must have the user to execute "show slave status" ( in order for plugin to work )? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=619255&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:31:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:31:11 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-680892 ] New plugin: check_cpu (by Dave Viner) Message-ID: New Plugins item #680892, was opened at 2003-02-05 08:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=680892&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 2 Submitted By: Ton Voon (tonvoon) >Assigned to: Nobody/Anonymous (nobody) Summary: New plugin: check_cpu (by Dave Viner) Initial Comment: This is a new plugin, written by Dave Winer, to check cpu usage on processes. Priority lowered as it is new functionality. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-02-05 12:24 Message: Logged In: YES user_id=664364 Apologies for my very poor fingers. Credit goes to Dave Viner. ---------------------------------------------------------------------- Comment By: Dave Viner (dviner) Date: 2003-02-05 12:16 Message: Logged In: YES user_id=90427 altho i am flattered that you might think i'm dave winer (the xmlrpc maven), i'm actally Dave Viner (lowly programmer). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=680892&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:33:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:33:05 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-619255 ] New plugin: check_mysqlslave.pl Message-ID: New Plugins item #619255, was opened at 2002-10-06 10:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=619255&group_id=29880 >Category: Application monitor Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mario Witte (chengfu) Assigned to: Nobody/Anonymous (nobody) Summary: New plugin: check_mysqlslave.pl Initial Comment: I'd like to contribute the attaches service check plugin. check_mysqlslave.pl checks if a MySQL-Replication is still running. The attached archive contains the skript itself, a patch to configure.in and a patch to plugin-scripts/Makefile.am. I tried to create the script as outlined in the developer guidelines, but if there are flaws or errors or whatever please contact me. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-01-30 12:05 Message: Logged In: YES user_id=664364 Thanks for the patch. New plugins are not a priority for 1.3, but will be considered for 1.4. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-01-02 10:59 Message: Logged In: NO I am just wandering what privileges must have the user to execute "show slave status" ( in order for plugin to work )? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=619255&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:33:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:33:07 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-689679 ] New plugin: check_oracle_tbs Message-ID: New Plugins item #689679, was opened at 2003-02-19 18:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=689679&group_id=29880 >Category: Application monitor Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Koyle (koiler) Assigned to: Nobody/Anonymous (nobody) Summary: New plugin: check_oracle_tbs Initial Comment: This is a simple plugin to connect to an oracle database and check for tablespaces that are nearly full. ---------------------------------------------------------------------- Comment By: John Marquart (vaix) Date: 2003-02-20 13:15 Message: Logged In: YES user_id=102671 John - I will check out your code - am quite excited about how you implemented it. Just a FYI - the latest CVS version of the check_oracle plugin (1.4) contains code to both check tablespace utilization as well as cache hit percentages (library and data buffers). -vaix ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=689679&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:33:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:33:12 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-656173 ] New check_pfstate nagios plugin Message-ID: New Plugins item #656173, was opened at 2002-12-19 02:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=656173&group_id=29880 >Category: System monitor Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Dixon (fuzzyping) Assigned to: Nobody/Anonymous (nobody) Summary: New check_pfstate nagios plugin Initial Comment: Here is a check_pfstate plugin for nagios on *OPENBSD* that I wrote in perl. It gathers the number of current state entries (pfctl -s info). -J. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-01-30 11:48 Message: Logged In: YES user_id=664364 Thanks for the submission. New plugins are not a priority at the moment, but we are looking into it. Jason also says: These all use a standard pre-shared ssh key connection to connect and gather the relevant info. There will need to be a public ssh key for the local nagios user in the remote users' ~/.ssh/authorized_keys file, in addition to a copy of the public host key from the remote system in the local nagios user's ~/.ssh/known_hosts file. Very similar to check_by_ssh configuration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=656173&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:33:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:33:13 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-656169 ] New check_df nagios plugin submission Message-ID: New Plugins item #656169, was opened at 2002-12-19 02:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=656169&group_id=29880 >Category: System monitor Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Dixon (fuzzyping) Assigned to: Nobody/Anonymous (nobody) Summary: New check_df nagios plugin submission Initial Comment: Here is a check_df (diskfree) plugin that I wrote in perl. Feel free to use... or destroy. ;-) -J. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-01-30 11:43 Message: Logged In: YES user_id=664364 Thanks for the submission. New plugins are not a priority at the moment, but we are looking into it. Jason also says: These all use a standard pre-shared ssh key connection to connect and gather the relevant info. There will need to be a public ssh key for the local nagios user in the remote users' ~/.ssh/authorized_keys file, in addition to a copy of the public host key from the remote system in the local nagios user's ~/.ssh/known_hosts file. Very similar to check_by_ssh configuration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=656169&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:33:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:33:14 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-656170 ] New check_cpu nagios plugin submission Message-ID: New Plugins item #656170, was opened at 2002-12-19 02:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=656170&group_id=29880 >Category: System monitor Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Dixon (fuzzyping) Assigned to: Nobody/Anonymous (nobody) Summary: New check_cpu nagios plugin submission Initial Comment: Here is a check_cpu (load averages) plugin that I wrote in perl. Feel free to use... or destroy. ;-) -J. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-01-30 11:48 Message: Logged In: YES user_id=664364 Thanks for the submission. New plugins are not a priority at the moment, but we are looking into it. Jason also says: These all use a standard pre-shared ssh key connection to connect and gather the relevant info. There will need to be a public ssh key for the local nagios user in the remote users' ~/.ssh/authorized_keys file, in addition to a copy of the public host key from the remote system in the local nagios user's ~/.ssh/known_hosts file. Very similar to check_by_ssh configuration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=656170&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:33:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:33:15 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-680892 ] New plugin: check_cpu (by Dave Viner) Message-ID: New Plugins item #680892, was opened at 2003-02-05 08:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=680892&group_id=29880 >Category: System monitor Group: None Status: Open Resolution: None Priority: 2 Submitted By: Ton Voon (tonvoon) Assigned to: Nobody/Anonymous (nobody) Summary: New plugin: check_cpu (by Dave Viner) Initial Comment: This is a new plugin, written by Dave Winer, to check cpu usage on processes. Priority lowered as it is new functionality. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-02-05 12:24 Message: Logged In: YES user_id=664364 Apologies for my very poor fingers. Credit goes to Dave Viner. ---------------------------------------------------------------------- Comment By: Dave Viner (dviner) Date: 2003-02-05 12:16 Message: Logged In: YES user_id=90427 altho i am flattered that you might think i'm dave winer (the xmlrpc maven), i'm actally Dave Viner (lowly programmer). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=680892&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:50:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:50:11 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-681623 ] check_disk patch to return performance data Message-ID: Patches item #681623, was opened at 2003-02-06 07:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=681623&group_id=29880 >Category: Perf data Group: None Status: Open Resolution: None Priority: 5 Submitted By: Edwin Eefting (drpsycho) Assigned to: Subhendu Ghosh (sghosh) Summary: check_disk patch to return performance data Initial Comment: Now returns performance data, following the official guidelines. (when checking mulitple disks it returns totals) ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-06 10:01 Message: Logged In: YES user_id=46572 Thanks - post 1.3 inclusion ---------------------------------------------------------------------- Comment By: Edwin Eefting (drpsycho) Date: 2003-02-06 07:34 Message: Logged In: YES user_id=400439 returns totals when checking mulitple disks. to be used with my performance data collector. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=681623&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:50:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:50:12 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-681625 ] check_load performance data Message-ID: Patches item #681625, was opened at 2003-02-06 07:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=681625&group_id=29880 >Category: Perf data Group: None Status: Open Resolution: None Priority: 5 Submitted By: Edwin Eefting (drpsycho) Assigned to: Subhendu Ghosh (sghosh) Summary: check_load performance data Initial Comment: now returns the official performance data format ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-06 10:00 Message: Logged In: YES user_id=46572 thanks - post 1.3 inclusion ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=681625&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:50:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:50:12 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-681627 ] check_ping performance data patch Message-ID: Patches item #681627, was opened at 2003-02-06 07:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=681627&group_id=29880 >Category: Perf data Group: None Status: Open Resolution: None Priority: 5 Submitted By: Edwin Eefting (drpsycho) Assigned to: Subhendu Ghosh (sghosh) Summary: check_ping performance data patch Initial Comment: returns official performance data ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-06 10:00 Message: Logged In: YES user_id=46572 Thanks - post 1.3 inclusion ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=681627&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:51:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:51:04 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-576371 ] Regular expression patch to check_procs Message-ID: Patches item #576371, was opened at 2002-07-02 09:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=576371&group_id=29880 >Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Bertelson (tbertels) Assigned to: Karl DeBisschop (kdebisschop) Summary: Regular expression patch to check_procs Initial Comment: This patch adds -r and -R flags to check_procs (similar to check_snmp). This makes comparisons with the -a and -C options match as regular expressions. Tested with Solaris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=576371&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:51:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:51:16 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-638898 ] check_ldap enhancement Message-ID: Patches item #638898, was opened at 2002-11-15 07:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=638898&group_id=29880 >Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gyula Szabo (gyufi) Assigned to: Nobody/Anonymous (nobody) Summary: check_ldap enhancement Initial Comment: This patch is provide some new argument to plugin. You could compare an LDAP attribute value with the set limits or an expected value. There is verbose mode, print all readable attribute from the DN. New arguments are: [-a ] [-e ] [-W ] [-C ] [-r] [-v] We use it to check the monitoring DN in iPlanet, for currentconnections, threads, replica status etc. ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-02-11 13:43 Message: Logged In: YES user_id=10485 As this adds new functionality it would be better to wait until 1.3 releases and work on 1.4 begins. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=638898&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:51:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:51:17 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-672841 ] utils.pm patch to read Nagios config file Message-ID: Patches item #672841, was opened at 2003-01-22 19:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=672841&group_id=29880 >Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Grimm (koreth) Assigned to: Subhendu Ghosh (sghosh) Summary: utils.pm patch to read Nagios config file Initial Comment: This patch adds a new externally accessible subroutine "config_value" to utils.pm, so scripts that want to read the Nagios config file (e.g. to find out the location of the command file) can do so without knowing the config file's location. Examples: @cfg_files = &utils::config_value('cfg_file'); $resource_file = &utils::config_value('resource_file'); ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-03 00:15 Message: Logged In: YES user_id=46572 Will hold off on this till 1.3 is released. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=672841&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:51:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:51:17 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-664615 ] new check_imap w/ ssl switch and check_jabber plugin Message-ID: New Plugins item #664615, was opened at 2003-01-08 15:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=664615&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: new check_imap w/ ssl switch and check_jabber plugin Initial Comment: Solaris [7-9] Attached is the gnu diff -ruN of the latest nagios-plugins source and my own edited version. The only difference between the two sources is I have created my own dir in the original nagios-plugins source called contrib-brylon and it contains my check_jabber and check_imap code, headers and Makefile. Both plugins have a cmd line switch to use SSL and whether or not you would like the server to have a valid certificate. Use as you seem fit. Thanks. Any feedback would be appreciated as well. Also I will include next just the contrib-brylon dir tarzipped if the above is of no use to you Thanks. Bryan Loniewski ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-01-30 12:02 Message: Logged In: YES user_id=664364 Just consolidating calls, by adding in the file in Bryan's other call #664621. The tarzip is the dir that contains the check_jabber and check_imap code, headers and Makefile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=664615&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:52:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:52:09 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-686476 ] pre compiler barfs on include path for system openssl Message-ID: Patches item #686476, was opened at 2003-02-14 05:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=686476&group_id=29880 >Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lutz Behnke (cypherfox) Assigned to: Nobody/Anonymous (nobody) Summary: pre compiler barfs on include path for system openssl Initial Comment: On Linux, the cpp prints a warning to stderr if a system include path is reset on the command line. The configure script takes this to mean that an error occored. The following patch checks if defining a new '-I' for the openssl include path is nessecary (it is not if openssl was installed as part of the system as for SuSE. mfg lutz --- nagios-plugins-1.3.0-beta2/configure.in 2002-11-22 03:46:49.000000000 +0100 +++ src/nagios-plugins-1.3.0-beta2/configure.in 2003-02-14 11:34:38.000000000 +0100 @@ -222,7 +222,10 @@ dnl Check for OpenSSL header files _SAVEDCPPFLAGS="$CPPFLAGS" FOUNDINCLUDE=yes -CPPFLAGS="-I$OPENSSL/include" +if test "$OPENSSL" != "/usr" ; then + CPPFLAGS="-I$OPENSSL/include" +fi + AC_CHECK_HEADERS(openssl/x509.h openssl/ssl.h openssl/rsa.h openssl/pem.h openssl/crypto.h openssl/err.h,SSLINCLUDE="-I$OPENSSL/include",FOUNDINCLUDE=no) if test "$FOUNDINCLUDE" = "no"; then FOUNDINCLUDE=yes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=686476&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:53:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:53:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-647959 ] check_dns fix Message-ID: Patches item #647959, was opened at 2002-12-03 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=647959&group_id=29880 >Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: check_dns fix Initial Comment: check_dns fix, uses a dns resolver directly, instead of the nslookup program. Gutted (changed) a decent amount of code, also NOTE the diff is run against nagiosplug-1.3-beta1 ---------------------------------------------------------------------- Comment By: Jeremy T. Bouse (undrgrid) Date: 2003-02-11 13:39 Message: Logged In: YES user_id=10485 I would recommend holding off to 1.4 as well since it's a major overhaul... Although the same idea may be applied at that time to others (ie- check_ping and check_dig) as well... ---------------------------------------------------------------------- Comment By: Karl DeBisschop (kdebisschop) Date: 2003-01-29 01:32 Message: Logged In: YES user_id=1671 I'm thinking this is a little to big a change for 1.3 -- If we do theis now, I''d suggest as a contrib until 1.4. Other thoughts? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=647959&group_id=29880 From noreply at sourceforge.net Fri Feb 21 11:54:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 11:54:09 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-635536 ] compilation problem solution for HP-UX! Message-ID: Patches item #635536, was opened at 2002-11-08 10:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=635536&group_id=29880 >Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandre ARMENGAUD (armengaud) Assigned to: Ton Voon (tonvoon) Summary: compilation problem solution for HP-UX! Initial Comment: Like many people here I had troubles compiling nagios plugins on HP-UX. I wanted to solve it cleanly, so I took the last CVS version and tried to debug it. I found several problems, that I could solve in the "configure.in" file. There was a problem in the snprintf.c : I guess it's a bug in the original file from SAMBA, but I didn't dare touching it (there is a test on if not defined HAVE_C99_SNPRINTF that isn't defined anywhere). I added a test in configure.in for HP-UX to define it, and the "#undef HAVE_C99_SNPRINTF" in the acconfig.h There was also problem in the order of test of functions that made them fail (probably because of snprintf). I solved that by changing test order. I changed also the configuration to make swap_format work, but it's a little dirty because I didn't want to touch the C source, so I made used a shell command to have the good swapinfo format. All seems ok now, and I tested the same configuration files on Linux, and it's working. I join the diff file for this new configuration (files configure.in and acconfig.h) ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-01-28 23:47 Message: Logged In: YES user_id=664364 Alexandre, Thanks for this patch. It looks very interesting, but I am having problems applying your fix to CVS. Can you send me a context or unified diff for the latest CVS version and I'll update it straight away for you to test. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=635536&group_id=29880 From noreply at sourceforge.net Fri Feb 21 13:28:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 13:28:14 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-689563 ] check_dns -a fails on FreeBSD Message-ID: Bugs item #689563, was opened at 2003-02-19 20:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=689563&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Simon L. Nielsen (nitro) >Assigned to: Ton Voon (tonvoon) Summary: check_dns -a fails on FreeBSD Initial Comment: When using the -a option to check_dns on FreeBSD it fails since nslookup on FreeBSD apparently prints the address with more whitespace than check_dns expects. Example : /tmp/nagios-plugins-1.3.0-beta2/plugins/check_dns -H www.nitro.dk -a 212.242.113.79 -s 192.168.3.2 DNS CRITICAL - expected 212.242.113.79 but got 212.242.113.79 The following fix (it should also be attached) strips spaces before the IP. http://simon.nitro.dk/patch/nagios/check_dns_freebsd.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=689563&group_id=29880 From noreply at sourceforge.net Fri Feb 21 13:58:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 13:58:26 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-689563 ] check_dns -a fails on FreeBSD Message-ID: Bugs item #689563, was opened at 2003-02-19 20:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=689563&group_id=29880 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Simon L. Nielsen (nitro) Assigned to: Ton Voon (tonvoon) Summary: check_dns -a fails on FreeBSD Initial Comment: When using the -a option to check_dns on FreeBSD it fails since nslookup on FreeBSD apparently prints the address with more whitespace than check_dns expects. Example : /tmp/nagios-plugins-1.3.0-beta2/plugins/check_dns -H www.nitro.dk -a 212.242.113.79 -s 192.168.3.2 DNS CRITICAL - expected 212.242.113.79 but got 212.242.113.79 The following fix (it should also be attached) strips spaces before the IP. http://simon.nitro.dk/patch/nagios/check_dns_freebsd.patch ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2003-02-21 22:06 Message: Logged In: YES user_id=664364 Simon, Thanks for the patch. Applied to check_dns.c v1.8. Closing this call. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=689563&group_id=29880 From noreply at sourceforge.net Fri Feb 21 14:03:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 14:03:08 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-652468 ] check_dns return code 139 out of bounds Message-ID: Bugs item #652468, was opened at 2002-12-12 03:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=652468&group_id=29880 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Ton Voon (tonvoon) Summary: check_dns return code 139 out of bounds Initial Comment: check_dns reports "(Return code of 139 is out of bounds)". /var/log/messages indicates check_dns exited on signal 11 (core dumped). ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2003-02-21 22:11 Message: Logged In: YES user_id=664364 Closing this call due to lack of updates. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-02-05 20:05 Message: Logged In: YES user_id=664364 Can you please try this with the latest version of check_dns. If this still fails, please can you provide information about your OS and an strace (or equivalent). We are trying to lower the number of outstanding problems and will close this call in a week's time if there have not been any updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=652468&group_id=29880 From noreply at sourceforge.net Fri Feb 21 14:05:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 14:05:06 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-654009 ] check_ftp seg fault Message-ID: Bugs item #654009, was opened at 2002-12-15 07:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=654009&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Ton Voon (tonvoon) Summary: check_ftp seg fault Initial Comment: using check_ftp gives me a seg fault (after appearing to work) However check_tcp seems to work fine. What gives? ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2003-02-21 22:12 Message: Logged In: YES user_id=664364 We are trying to lower the number of outstanding problems and will close this call in a week's time if there have not been any updates. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-02-14 17:59 Message: Logged In: YES user_id=664364 Ooops - that should be check_pop --version to get the version number.... ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-02-14 17:57 Message: Logged In: YES user_id=664364 Can you run check_pop -v to return the version number? check_tcp had a fix for seg faults in v1.8 and had a fix for the return of +OK for POP checks in v1.9. Can you please try the latest tarball for nagios plugins at http://www.debisschop.net/src/nagios/ (contains check_tcp at v1.12) to see if the problem is fixed. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-02-14 15:11 Message: Logged In: NO I have check_ftp, check_imap and check_pop (links to check_tcp) segfaulting under RH 7.3. > ./check_pop 10.10.10.250 -p 110 POP OK - 0.004 second response time on port 110|time= 0.004 Segmentation fault Plain check_tcp to port 110 of 10.10.10.250 does not segfault. This may be not very helpful. Ask more. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-02-10 14:54 Message: Logged In: YES user_id=664364 676524 was investigated by Karl and he had to close the call because of lack of information about the problem. Under what conditions does it fail? Which version of check_ftp is used? What OS? This is potentially a show stopper, so I don't really want to ignore it, but will have to close this call without further facts. Ton ---------------------------------------------------------------------- Comment By: Jan Ruzicka (ruza) Date: 2003-02-10 12:55 Message: Logged In: YES user_id=195140 this looks like duplicate of 676524. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-01-29 21:16 Message: Logged In: YES user_id=664364 Will need more information: OS? Plugin version? strace (or equivalent). We are trying to lower the number of outstanding problems and will close this call in a week's time if there have not been any updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=654009&group_id=29880 From noreply at sourceforge.net Fri Feb 21 14:06:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 21 14:06:19 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-656247 ] check_pop segfault Message-ID: Support Requests item #656247, was opened at 2002-12-19 11:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=656247&group_id=29880 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Ton Voon (tonvoon) Summary: check_pop segfault Initial Comment: On RH 7.3 and nagios-plugins-1.3.0-beta2 check_pop exits with segfault: POP OK - 0.132 second response time on port 110|time= 0.132 Segmentation fault ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2003-02-21 22:14 Message: Logged In: YES user_id=664364 Closing this call due to lack of updates. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2003-02-11 00:56 Message: Logged In: YES user_id=664364 Can you please retry with the latest tarballs at http://www.debisschop.net/src/nagios/ as there have been a few fixes around this area. We are trying to lower the number of outstanding problems and will close this call in a week's time if there have not been any updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=656247&group_id=29880 From simon at nitro.dk Sat Feb 22 06:54:04 2003 From: simon at nitro.dk (Simon L. Nielsen) Date: Sat Feb 22 06:54:04 2003 Subject: [Nagiosplug-devel] check_ntp problem with locan NTP server Message-ID: <20030222145324.GM371@nitro.dk> Hello I use check_ntp to monitor the NTP deamon running on the same server as Nagios to make sure the NTP daemon is alive. The problem is that since the NTP daemon is running on localhost the time is some times exactly the same and check_ntp thinks there is a problem and sets a critical error : [02-22-2003 14:09:47] SERVICE ALERT: trillian.nitro.dk;NTP;CRITICAL;SOFT;1;CRITICAL: server 192.168.1.6, stratum 2, offset -0.000000, delay 0.02573 I don't really know what the correct fix is since I suppose the check for offset = 0 is there for a reason. Do anybody have an idea for a proper way to handle this ? -- Simon L. Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From noreply at sourceforge.net Sat Feb 22 16:20:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 22 16:20:21 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-691412 ] check_ifstatus not displaying interface description Message-ID: Bugs item #691412, was opened at 2003-02-22 18:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691412&group_id=29880 Category: Interface (example) Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Mike McHenry (mmchenry) Assigned to: Nobody/Anonymous (nobody) Summary: check_ifstatus not displaying interface description Initial Comment: check_ifstatus no longer displays the interface descriptions. See attached patch for fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691412&group_id=29880 From noreply at sourceforge.net Sat Feb 22 16:21:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 22 16:21:08 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-691412 ] check_ifstatus not displaying interface description Message-ID: Bugs item #691412, was opened at 2003-02-22 18:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691412&group_id=29880 Category: Interface (example) >Group: v1.3.0 beta3 Status: Open Resolution: None Priority: 5 Submitted By: Mike McHenry (mmchenry) Assigned to: Nobody/Anonymous (nobody) Summary: check_ifstatus not displaying interface description Initial Comment: check_ifstatus no longer displays the interface descriptions. See attached patch for fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691412&group_id=29880 From noreply at sourceforge.net Sat Feb 22 16:22:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 22 16:22:08 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-691412 ] check_ifstatus not displaying interface description Message-ID: Bugs item #691412, was opened at 2003-02-22 18:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691412&group_id=29880 >Category: None Group: v1.3.0 beta3 Status: Open Resolution: None Priority: 5 Submitted By: Mike McHenry (mmchenry) Assigned to: Nobody/Anonymous (nobody) Summary: check_ifstatus not displaying interface description Initial Comment: check_ifstatus no longer displays the interface descriptions. See attached patch for fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691412&group_id=29880 From noreply at sourceforge.net Sat Feb 22 16:26:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 22 16:26:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-691412 ] check_ifstatus not displaying interface description Message-ID: Bugs item #691412, was opened at 2003-02-22 18:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691412&group_id=29880 Category: None Group: v1.3.0 beta3 Status: Open Resolution: None Priority: 5 Submitted By: Mike McHenry (mmchenry) Assigned to: Nobody/Anonymous (nobody) Summary: check_ifstatus not displaying interface description Initial Comment: check_ifstatus no longer displays the interface descriptions. See attached patch for fix. ---------------------------------------------------------------------- >Comment By: Mike McHenry (mmchenry) Date: 2003-02-22 18:33 Message: Logged In: YES user_id=718530 See updated patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691412&group_id=29880 From noreply at sourceforge.net Sat Feb 22 16:42:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 22 16:42:06 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-691417 ] check_bgpstatus.pl displays SNMP community string Message-ID: Bugs item #691417, was opened at 2003-02-22 18:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691417&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike McHenry (mmchenry) Assigned to: Nobody/Anonymous (nobody) Summary: check_bgpstatus.pl displays SNMP community string Initial Comment: check_bgpstate.pl in the contrib directory displays the SNMP community string which could be a security risk. Please see the attached file for a patch to disable this behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691417&group_id=29880 From noreply at sourceforge.net Sat Feb 22 16:43:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 22 16:43:01 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-691417 ] check_bgpstatus.pl displays SNMP community string Message-ID: Bugs item #691417, was opened at 2003-02-22 18:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691417&group_id=29880 Category: None >Group: v1.3.0 beta3 Status: Open Resolution: None Priority: 5 Submitted By: Mike McHenry (mmchenry) Assigned to: Nobody/Anonymous (nobody) Summary: check_bgpstatus.pl displays SNMP community string Initial Comment: check_bgpstate.pl in the contrib directory displays the SNMP community string which could be a security risk. Please see the attached file for a patch to disable this behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691417&group_id=29880 From sghosh at sghosh.org Sat Feb 22 17:49:01 2003 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Sat Feb 22 17:49:01 2003 Subject: [Nagiosplug-devel] check_ntp problem with locan NTP server In-Reply-To: <20030222145324.GM371@nitro.dk> Message-ID: On Sat, 22 Feb 2003, Simon L. Nielsen wrote: > > Hello > > I use check_ntp to monitor the NTP deamon running on the same server as > Nagios to make sure the NTP daemon is alive. The problem is that since > the NTP daemon is running on localhost the time is some times exactly > the same and check_ntp thinks there is a problem and sets a critical > error : > > [02-22-2003 14:09:47] SERVICE ALERT: trillian.nitro.dk;NTP;CRITICAL;SOFT;1;CRITICAL: server 192.168.1.6, stratum 2, offset -0.000000, delay 0.02573 > > I don't really know what the correct fix is since I suppose the check > for offset = 0 is there for a reason. Do anybody have an idea for a > proper way to handle this ? > > I don't think anybody had planned for check_ntp to be used on a localhost :) Since check_ntp actually does 2 different test - ntpdate and nptq, perhaps a switch could be added to turn one of them off. ntpdate could be used against remote NTP or SNTP hosts to check for relative synchronization. ntpq could be used to check that NTP was running and was synchronized to a stratum (not 16) peer. (no relative synchronization check) Since this would be an enhancement, it would be added afetr the 1.3 release. Intermediate step would be run check_proc to see if ntpd was running and possbily comment out the ntpdate section where offset==0 is checked -- -sg From noreply at sourceforge.net Sun Feb 23 05:55:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 23 05:55:12 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-691417 ] check_bgpstatus.pl displays SNMP community string Message-ID: Bugs item #691417, was opened at 2003-02-22 19:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691417&group_id=29880 Category: None Group: v1.3.0 beta3 Status: Open Resolution: None Priority: 5 Submitted By: Mike McHenry (mmchenry) Assigned to: Nobody/Anonymous (nobody) Summary: check_bgpstatus.pl displays SNMP community string Initial Comment: check_bgpstate.pl in the contrib directory displays the SNMP community string which could be a security risk. Please see the attached file for a patch to disable this behavior. ---------------------------------------------------------------------- >Comment By: Karl DeBisschop (kdebisschop) Date: 2003-02-23 09:03 Message: Logged In: YES user_id=1671 Hey Mike - where's the patch? Being a security item, I'd like to get this into the 1.3.0 RC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691417&group_id=29880 From noreply at sourceforge.net Sun Feb 23 09:27:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 23 09:27:07 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-691753 ] check_ifstatus enhancement, use snmpLocIfDescr or snmpIfDesc Message-ID: Patches item #691753, was opened at 2003-02-23 11:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=691753&group_id=29880 Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike McHenry (mmchenry) Assigned to: Nobody/Anonymous (nobody) Summary: check_ifstatus enhancement, use snmpLocIfDescr or snmpIfDesc Initial Comment: This patch enhances the default behavior of check_ifstatus as follows. Some devices do not support the snmpLocIfDescr OID while most Cisco devices do. snmpLocIfDescr contains the description of the interface on Cisco devices but will result in errors if run on some non-cisco devices. The attached patch checks for the presence of snmpLocIfDescr. If found it will use this variable giving more information about which port is down. If snmpLocIfDescr is not found on the device the script reverts back to snmpIfDescr. This patch also includes some cosmetic cleanup such as replacing the
breaks at the end of lines with commas. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=691753&group_id=29880 From noreply at sourceforge.net Sun Feb 23 09:28:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 23 09:28:18 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-691417 ] check_bgpstatus.pl displays SNMP community string Message-ID: Bugs item #691417, was opened at 2003-02-22 19:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691417&group_id=29880 Category: None Group: v1.3.0 beta3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Mike McHenry (mmchenry) >Assigned to: Subhendu Ghosh (sghosh) Summary: check_bgpstatus.pl displays SNMP community string Initial Comment: check_bgpstate.pl in the contrib directory displays the SNMP community string which could be a security risk. Please see the attached file for a patch to disable this behavior. ---------------------------------------------------------------------- >Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-23 12:36 Message: Logged In: YES user_id=46572 Fixed - thanks ---------------------------------------------------------------------- Comment By: Karl DeBisschop (kdebisschop) Date: 2003-02-23 09:03 Message: Logged In: YES user_id=1671 Hey Mike - where's the patch? Being a security item, I'd like to get this into the 1.3.0 RC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691417&group_id=29880 From noreply at sourceforge.net Sun Feb 23 09:37:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 23 09:37:05 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-691412 ] check_ifstatus not displaying interface description Message-ID: Bugs item #691412, was opened at 2003-02-22 19:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691412&group_id=29880 Category: None Group: v1.3.0 beta3 >Status: Pending >Resolution: Rejected Priority: 5 Submitted By: Mike McHenry (mmchenry) >Assigned to: Subhendu Ghosh (sghosh) Summary: check_ifstatus not displaying interface description Initial Comment: check_ifstatus no longer displays the interface descriptions. See attached patch for fix. ---------------------------------------------------------------------- >Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-23 12:44 Message: Logged In: YES user_id=46572 LocIfDescr is a cisco specific MIB. Without its use the plugin is more generally useful. ifName from ifXTable contains the same data as LocIfDescr if your IOS support rfc1573 (interfaces) try using the -I switch to enable ifMIB -sg ---------------------------------------------------------------------- Comment By: Mike McHenry (mmchenry) Date: 2003-02-22 19:33 Message: Logged In: YES user_id=718530 See updated patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691412&group_id=29880 From noreply at sourceforge.net Sun Feb 23 09:37:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 23 09:37:12 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-691417 ] check_bgpstatus.pl displays SNMP community string Message-ID: Bugs item #691417, was opened at 2003-02-22 19:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691417&group_id=29880 Category: None Group: v1.3.0 beta3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Mike McHenry (mmchenry) Assigned to: Subhendu Ghosh (sghosh) Summary: check_bgpstatus.pl displays SNMP community string Initial Comment: check_bgpstate.pl in the contrib directory displays the SNMP community string which could be a security risk. Please see the attached file for a patch to disable this behavior. ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-23 12:36 Message: Logged In: YES user_id=46572 Fixed - thanks ---------------------------------------------------------------------- Comment By: Karl DeBisschop (kdebisschop) Date: 2003-02-23 09:03 Message: Logged In: YES user_id=1671 Hey Mike - where's the patch? Being a security item, I'd like to get this into the 1.3.0 RC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=691417&group_id=29880 From noreply at sourceforge.net Sun Feb 23 09:40:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 23 09:40:22 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-691753 ] check_ifstatus enhancement, use snmpLocIfDescr or snmpIfDesc Message-ID: Patches item #691753, was opened at 2003-02-23 12:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=691753&group_id=29880 Category: Enhancement Group: None >Status: Pending >Resolution: Rejected Priority: 5 Submitted By: Mike McHenry (mmchenry) >Assigned to: Subhendu Ghosh (sghosh) Summary: check_ifstatus enhancement, use snmpLocIfDescr or snmpIfDesc Initial Comment: This patch enhances the default behavior of check_ifstatus as follows. Some devices do not support the snmpLocIfDescr OID while most Cisco devices do. snmpLocIfDescr contains the description of the interface on Cisco devices but will result in errors if run on some non-cisco devices. The attached patch checks for the presence of snmpLocIfDescr. If found it will use this variable giving more information about which port is down. If snmpLocIfDescr is not found on the device the script reverts back to snmpIfDescr. This patch also includes some cosmetic cleanup such as replacing the
breaks at the end of lines with commas. ---------------------------------------------------------------------- >Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-23 12:48 Message: Logged In: YES user_id=46572 see comments on Bug#691412 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=691753&group_id=29880 From noreply at sourceforge.net Mon Feb 24 04:31:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 24 04:31:14 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-692207 ] New plugin: check_hpres Message-ID: New Plugins item #692207, was opened at 2003-02-24 13:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=692207&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mikael Olofsson (oet) Assigned to: Nobody/Anonymous (nobody) Summary: New plugin: check_hpres Initial Comment: This plugin uses snmp to check resources on HP-printers (I have only tested with LaserJet 8100N). It check fuser, drum and transfer kits and also toner. example from our services.cfg define service { host_name teti service_description Toner black check_command check_hpjdres!1 use generic-service max_check_attempts 4 normal_check_interval 5 retry_check_interval 1 check_period workhours notification_interval 960 notification_period workhours notification_options c,r contact_groups printer-admins } Cheers Oet ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=692207&group_id=29880 From noreply at sourceforge.net Mon Feb 24 05:09:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 24 05:09:10 2003 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-692207 ] New plugin: check_hpres Message-ID: New Plugins item #692207, was opened at 2003-02-24 13:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=692207&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mikael Olofsson (oet) Assigned to: Nobody/Anonymous (nobody) Summary: New plugin: check_hpres Initial Comment: This plugin uses snmp to check resources on HP-printers (I have only tested with LaserJet 8100N). It check fuser, drum and transfer kits and also toner. example from our services.cfg define service { host_name teti service_description Toner black check_command check_hpjdres!1 use generic-service max_check_attempts 4 normal_check_interval 5 retry_check_interval 1 check_period workhours notification_interval 960 notification_period workhours notification_options c,r contact_groups printer-admins } Cheers Oet ---------------------------------------------------------------------- >Comment By: Mikael Olofsson (oet) Date: 2003-02-24 14:18 Message: Logged In: YES user_id=130720 The printer I tried this plugin on was an HP ColorJet 4550 /Oet ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=692207&group_id=29880 From noreply at sourceforge.net Wed Feb 26 10:31:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 26 10:31:09 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-693831 ] check_by_ssh -C "check_disk" does not work Message-ID: Bugs item #693831, was opened at 2003-02-26 19:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=693831&group_id=29880 Category: None Group: v1.3.0 beta3 Status: Open Resolution: None Priority: 5 Submitted By: Axel Staacke (sicksegv) Assigned to: Nobody/Anonymous (nobody) Summary: check_by_ssh -C "check_disk" does not work Initial Comment: check_by_ssh -l nagios -H remotehost -C "~/bin/nagiosplug/check_disk -w 10 -c 5" yields the following: DISK WARNING - [1587400 kB (84%) free on /dev/ida/c0d0p5] etc. The check_disk plugin, when called locally on the "remotehost", returns OK, however. check_by_ssh -C "check_ping" also works OK. It seems as though check_disk exits with status 1 whenever ssh is involved. According to the C sources this happens either because there is output in stderr or spclose returns an error code. How can I get it to work correctly? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=693831&group_id=29880 From noreply at sourceforge.net Thu Feb 27 01:42:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 27 01:42:01 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694259 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694259, was opened at 2003-02-27 09:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694259&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) Status: Open Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694259&group_id=29880 From noreply at sourceforge.net Thu Feb 27 01:42:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 27 01:42:17 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694260 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694260, was opened at 2003-02-27 09:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694260&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) Status: Open Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694260&group_id=29880 From noreply at sourceforge.net Thu Feb 27 01:43:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 27 01:43:09 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694262 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694262, was opened at 2003-02-27 09:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694262&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) Status: Open Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694262&group_id=29880 From noreply at sourceforge.net Thu Feb 27 01:43:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 27 01:43:16 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694261 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694261, was opened at 2003-02-27 09:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694261&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) Status: Open Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694261&group_id=29880 From noreply at sourceforge.net Thu Feb 27 01:44:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 27 01:44:07 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694264 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694264, was opened at 2003-02-27 09:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694264&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) Status: Open Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694264&group_id=29880 From noreply at sourceforge.net Thu Feb 27 08:09:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 27 08:09:14 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694264 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694264, was opened at 2003-02-27 04:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694264&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) >Status: Closed Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) >Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- >Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-27 11:17 Message: Logged In: YES user_id=46572 duplicate 694259 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694264&group_id=29880 From noreply at sourceforge.net Thu Feb 27 08:09:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 27 08:09:22 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694260 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694260, was opened at 2003-02-27 04:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694260&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) >Status: Closed Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) >Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694260&group_id=29880 From noreply at sourceforge.net Thu Feb 27 08:09:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 27 08:09:23 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694261 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694261, was opened at 2003-02-27 04:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694261&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) >Status: Closed Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) >Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694261&group_id=29880 From noreply at sourceforge.net Thu Feb 27 08:09:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 27 08:09:23 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694262 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694262, was opened at 2003-02-27 04:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694262&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) >Status: Closed Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) >Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694262&group_id=29880 From noreply at sourceforge.net Thu Feb 27 08:11:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 27 08:11:02 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694259 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694259, was opened at 2003-02-27 04:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694259&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) Status: Open Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) >Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- >Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-27 11:19 Message: Logged In: YES user_id=46572 where are you getting the error? on the windows machine or on the unix machine? What versions are you running? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694259&group_id=29880 From Jeremy.Bouse at UnderGrid.net Thu Feb 27 08:34:05 2003 From: Jeremy.Bouse at UnderGrid.net (Jeremy T. Bouse) Date: Thu Feb 27 08:34:05 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694259 ] Cannot map "tcp" to protocol number In-Reply-To: References: Message-ID: <20030227163151.GB26110@UnderGrid.net> I have actually seen this problem surface in other plugins and was one of the reasons while working on the AF-Independent patch I made I changed the protocol paramaters of functions to use the POSIX #defines of IPPROTO_TCP and IPPROTO_UDP which are passed as integers... Hopefully after 1.3 is released we can integrate this change as it will clean things up... Jeremy On Thu, Feb 27, 2003 at 08:19:38AM -0800, SourceForge.net wrote: > Support Requests item #694259, was opened at 2003-02-27 04:50 > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694259&group_id=29880 > > Category: Install Problem (example) > Group: v1.0 (example) > Status: Open > Priority: 5 > Submitted By: Alexander Wolters (diamondlink) > Assigned to: Nobody/Anonymous (nobody) > >Summary: Cannot map "tcp" to protocol number > > Initial Comment: > after installing the NSClient and configuring the > Service, I get that error message: "Cannot map "tcp" to > protocol number" > I'm using the default Port 1248. > Can anybody help me please?! > The documentation for the plugin sucks realy.... and I > can't find any other documentation or help on the web :-( > > Thanks in advanced > > ---------------------------------------------------------------------- > > >Comment By: Subhendu Ghosh (sghosh) > Date: 2003-02-27 11:19 > > Message: > Logged In: YES > user_id=46572 > > where are you getting the error? on the windows machine or > on the unix machine? > > What versions are you running? > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694259&group_id=29880 > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null From noreply at sourceforge.net Fri Feb 28 01:30:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 28 01:30:09 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694259 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694259, was opened at 2003-02-27 09:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694259&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) Status: Open Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) >Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- >Comment By: Alexander Wolters (diamondlink) Date: 2003-02-28 09:39 Message: Logged In: YES user_id=721439 I'm getting the error message @ the unix machine ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-27 16:19 Message: Logged In: YES user_id=46572 where are you getting the error? on the windows machine or on the unix machine? What versions are you running? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694259&group_id=29880 From noreply at sourceforge.net Fri Feb 28 01:54:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 28 01:54:07 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694259 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694259, was opened at 2003-02-27 09:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694259&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) Status: Open Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) >Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- >Comment By: Alexander Wolters (diamondlink) Date: 2003-02-28 10:02 Message: Logged In: YES user_id=721439 It's FreeBSD 5.0 ---------------------------------------------------------------------- Comment By: Alexander Wolters (diamondlink) Date: 2003-02-28 09:39 Message: Logged In: YES user_id=721439 I'm getting the error message @ the unix machine ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-27 16:19 Message: Logged In: YES user_id=46572 where are you getting the error? on the windows machine or on the unix machine? What versions are you running? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694259&group_id=29880 From noreply at sourceforge.net Fri Feb 28 02:08:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 28 02:08:07 2003 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-694259 ] Cannot map "tcp" to protocol number Message-ID: Support Requests item #694259, was opened at 2003-02-27 09:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694259&group_id=29880 Category: Install Problem (example) Group: v1.0 (example) Status: Open Priority: 5 Submitted By: Alexander Wolters (diamondlink) Assigned to: Nobody/Anonymous (nobody) >Summary: Cannot map "tcp" to protocol number Initial Comment: after installing the NSClient and configuring the Service, I get that error message: "Cannot map "tcp" to protocol number" I'm using the default Port 1248. Can anybody help me please?! The documentation for the plugin sucks realy.... and I can't find any other documentation or help on the web :-( Thanks in advanced ---------------------------------------------------------------------- >Comment By: Alexander Wolters (diamondlink) Date: 2003-02-28 10:17 Message: Logged In: YES user_id=721439 nagios-1.0 nagios-plugins-1.3.0.b2 ---------------------------------------------------------------------- Comment By: Alexander Wolters (diamondlink) Date: 2003-02-28 10:02 Message: Logged In: YES user_id=721439 It's FreeBSD 5.0 ---------------------------------------------------------------------- Comment By: Alexander Wolters (diamondlink) Date: 2003-02-28 09:39 Message: Logged In: YES user_id=721439 I'm getting the error message @ the unix machine ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2003-02-27 16:19 Message: Logged In: YES user_id=46572 where are you getting the error? on the windows machine or on the unix machine? What versions are you running? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=694259&group_id=29880