From william at leibzon.org Tue Jul 2 00:13:49 2013 From: william at leibzon.org (William Leibzon) Date: Mon, 1 Jul 2013 15:13:49 -0700 Subject: [Nagiosplug-devel] New Threshold Syntax In-Reply-To: <51D0662B.8070909@LINworks.de> References: <51CEDDA3.6020406@quantentunnel.de> <51CF3F38.2050100@quantentunnel.de> <51D0662B.8070909@LINworks.de> Message-ID: Hi, I appreciate the comments, my replies to them are further below. And seeing as there is some interest in this and it should be better documented, I've decided to extend existing doc and put into wiki which is open to pubic editing. The wiki is on my github copy of nagios-plugins main repository: https://github.com/willixix/nagios-plugins/wiki/New-Threshold-Syntax Please check it out and tell me what you think. Above in addition to extensions I mentioned in my first email (using ':' in addition to '=', adding 'perf' and 'absent' keywords), I also added several additional keywords: name:{name} - this is used to specify threshold that would apply to specific named attribute, this could be specific process name in case of check_procs or it could be specific partition for check_disk, etc. Note - I should extend set of symbols allowed there, somebody please comment what it should be. label:{label} - this is used to re-label named attribute for purpose of displaying it in status line or in perf awarn:{range], acrit:{range} - these add capability to specify that multiple warn (or critial) threshold levels must all match i.e. its logical AND rather than logical OR which is default if multiple warn and crit appear. I need this for combining multiple types of checks on same metric. This spec is what I intend to implement in my perl library (and most of this functionality is already there now) and what will eventually be used by majority of my plugins. And hopefully other plugin library writers who were willing to implement proposed format would follow with these extensions as well - overall it is still same as original proposal. And I'd be willing to create ABNF and more formal spec doc (similar to RFC, and I have participated in IETF and written drafts) if people want to go that way. On Sun, Jun 30, 2013 at 10:08 AM, Jochen Bern wrote: >>> Why not use the "mathematical syntax"? For this we need [] instead of () () and [] are in fact correct mathematical notation for open an close interval which also allows for mix of those brackets >>> Examples: >>> [1..5] means 1 ? x ? 5 >>> [1..5[ means 1 ? x < 5 >>> ]1..5] means 1 < x ? 5 >>> ]1..5[ means 1 < x < 5 I agree that you can do things by redefining ] bracket at start to mean (. But to me this looks less natural, perhaps because I have a graduate math degree :) Anyway I don't see strong reasons to not use both types of brackets and its easier for the parsers too. > Folks, you're spending a lot of mental effort over something that won't > get you noticeable appreciation. The thing that will win users and other > plugin authors over to a new syntax is not that it looks nicer or more > similar to existing notation conventions in whatever field, it's that it > allows them to do the things they need to do now and in the upcoming > years and that they had to *hack* with the former standard. In other > words, *functionality* (that the syntax is bound to have to adapt to to > a certain degree, anyway). I agree. My starting premise to work on this was to develop better format to express complex thresholds that I could not do with existing including being able to specify complex consisting of multiple types of checks on same metric in the future and more. I came up on my own (and without knowing about new threshold syntax) with something that is very much like it. The main difference is that I never bothered to re-define range so my current library parses threshold line kind-of like new format but with range specified using old style nagios way plus also my own ">num", " I the wrote the comment under > http://nagiosplugins.org/rfc/new_threshold_syntax > , and I'm *STILL* waiting for a check_disk (to reuse the example) that I > can tell to consider the minfree part of the available diskspace for > /var/log, but not /tmp, This will be possible to do using "name" keyword. I brought it over from my own specification (although in my own it also meant label which is confusing and I separated it). William From noreply at sourceforge.net Sun Jul 7 18:53:47 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 07 Jul 2013 09:53:47 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-3442015 ] check_http: Fix for checking http on different virtual port Message-ID: Patches item #3442015, was opened at 2011-11-25 03:28 Message generated for change (Settings changed) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3442015&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: release-1.4.15 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christopher Odenbach (odenbach) >Assigned to: Holger Weiss (hweiss) Summary: check_http: Fix for checking http on different virtual port Initial Comment: Patch against Plugin Version (-V output): 1.4.15 Plugin Name: check_http Example Plugin Commandline: with patch: check_http -H www.uni-paderborn.de:80 -p 5033 -I siva1 -v | head -4 GET / HTTP/1.1 User-Agent: check_http/v1.4.15 (nagios-plugins 1.4.15) Connection: close Host: www.uni-paderborn.de without patch: check_http -H www.uni-paderborn.de:80 -p 5033 -I siva1 -v | head -4 GET / HTTP/1.1 User-Agent: check_http/v1.4.15 (nagios-plugins 1.4.15) Connection: close Host: www.uni-paderborn.de:80:5033 Tested on operating system: Debian Linux, Squeeze Tested on architecture: amd64 Tested with compiler: x86_64-linux-gnu-gcc Explanation: We use a loadbalancer to balance http requests to our two webservers. On the loadbalancer we have defined several IP addresses for different web sites. On the webservers however we use different ports for the different sites. So www.uni-paderborn.de:80 is balanced to siva1.uni-paderborn.de:5033 and siva2.uni-paderborn.de:5033. Now we want to check both web servers individually to tell if a single host has failed (if one host fails the site is still available over the other one so users do not recognize the error). In the current version check_http does understand the concept of virtual hosts (using -H and -I), but it does not understand the concept of virtual ports. Let me make this clearer: If I leave out the virtual port like this: check_http -H www.uni-paderborn.de -p 5033 -I siva1 -v | head -4 GET / HTTP/1.1 User-Agent: check_http/v1.4.15 (nagios-plugins 1.4.15) Connection: close Host: www.uni-paderborn.de:5033 The request then contains the physical port which is wrong. If I add the virtual port to the hostname after the -H switch, I get the muddled up result from above. The patch corrects this behaviour while leaving everything else as it was before. If only one port is given (either in -H or with -p), that one is taken as physical and virtual port. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=3442015&group_id=29880 From noreply at sourceforge.net Tue Jul 9 13:28:32 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 09 Jul 2013 04:28:32 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1090549 ] check_dhcp ignores DHCP replies Message-ID: Bugs item #1090549, was opened at 2004-12-23 12:21 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1090549&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: CVS >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Laurentiu C. Badea (L.C.) (wotevah) >Assigned to: Holger Weiss (hweiss) Summary: check_dhcp ignores DHCP replies Initial Comment: check_dhcp ignores the DHCP replies apparently because they are broadcast to 255.255.255.255. .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from , length: 548, flags: [Broadcast] .bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 420, flags: [Broadcast] (0x8000) I believe the problem may be that recvfrom is not expecting a possible broadcast packet in response, so it ignores it. Relevant part from strace below: sendto(3, , 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1103833074]) = 1103833074 time([1103833074]) = 1103833074 select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 999000}) recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) recvfrom(3, 0xfef67370, 548, 0, 0xfef67280, 0xfef67274) = -1 EINVAL (Invalid argument) Client is Fedora Core 2 with nagios-plugins-1.3.1-10.1.fc2.dag. Server is Red Hat 9 with dhcp-3.0pl1-23. ---------------------------------------------------------------------- >Comment By: Holger Weiss (hweiss) Date: 2013-07-09 04:28 Message: Closing this issue, as there's nothing we can do about it (short of writing a separate OMAPI plugin). ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-07-22 06:59 Message: Logged In: YES user_id=759506 Originator: NO And sorry for overlooking your comment (it wasn't there yet as I wrote mine and then I got distracted before I submitted it) ;-) ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2008-07-22 06:48 Message: Logged In: YES user_id=46572 Originator: NO sorry about the repost - browser reload issue ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2008-07-22 06:46 Message: Logged In: YES user_id=46572 Originator: NO The current code base using the DHCP protocol cannot monitor a server on the same host as the plugin. One alternative, at least for the ISC DHCP server, would be write a new plugin using dhctl/omapi to query the server directly. side benefit would be ability to probe for the dhcp failover state ---------------------------------------------------------------------- Comment By: Holger Weiss (hweiss) Date: 2008-07-22 06:33 Message: Logged In: YES user_id=759506 Originator: NO Checking a DHCP server which runs on the *local* host currently is not possible with check_dhcp (though it might work if the DHCP server was compiled to use normal sockets, as opposed to the LPF/BPF/whatever interfaces it usually uses). Making this possible requires some non-trivial code changes to check_dhcp, so we cannot make any promises as to when this will be done. As a workaround, check_dhcp can be executed on a remote host via NRPE or NSCA (IMO, checking DHCP remotely makes sense anyway). ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2008-07-22 06:19 Message: Logged In: YES user_id=46572 Originator: NO The current code base using the DHCP protocol cannot monitor a server on the same host as the plugin. One alternative, at least for the ISC DHCP server, would be write a new plugin using dhctl/omapi to query the server directly. side benefit would be ability to probe for the dhcp failover state ---------------------------------------------------------------------- Comment By: tigalch (tigalch) Date: 2008-06-05 04:34 Message: Logged In: YES user_id=2108467 Originator: NO Hello, I would like to know if a solution to this problem is allready available or will be available soon? With the most recent plugins (1.4.12)the problem still remains. thanks and regards ---------------------------------------------------------------------- Comment By: liosme (lisme) Date: 2007-07-26 13:49 Message: Logged In: YES user_id=1854343 Originator: NO hello, i want to know if you resolv the problem with check_dhcp. I have tha same problem it is: ============================================ [root at desarrollo libexec]# ./check_dhcp -v DHCP socket: 3 Hardware address: 00e07dd6dd58 DHCPDISCOVER to 255.255.255.255 port 68 DHCPDISCOVER XID: 116527212 (0x6F2106C) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 CRITICAL: No DHCPOFFERs were received. ========================================= i use fedora 4 nagios 3.0a4 and plugin 1.4.7 if you resolv this problem with check_dhcp, woud you tell me how you resolv this. or explained more please. ---------------------------------------------------------------------- Comment By: Loic Dachary (loic) Date: 2007-05-20 14:53 Message: Logged In: YES user_id=1537 Originator: NO I experienced the problem today. On debian etch. I'm running check_dhcp and the dhcp server on the same interface. The dhcp server otherwise runs fine. strace /usr/lib/nagios/plugins/check_dhcp -s dhcp.dmz.tld -i eth2 ... read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\26"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=78500, ...}) = 0 mmap2(NULL, 81456, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7c17000 mmap2(0xb7c2a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xb7c2a000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c16000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7c15000 mprotect(0xb7d57000, 20480, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7c156c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xb7f04000, 8510) = 0 brk(0) = 0x804f000 brk(0x8070000) = 0x8070000 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE, "eth2\0\0\0\0\0\0\0\0\0\0\0\0\17\0\0\0\4\0\0\0\5\0\0\0$"..., 32) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(68), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 ioctl(3, SIOCGIFHWADDR, {ifr_name="eth2", ifr_hwaddr=00:13:72:40:39:0a}) = 0 time(NULL) = 1179697853 sendto(3, "\1\1\6\0b\\:\347\377\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1179697853]) = 1179697853 time([1179697853]) = 1179697853 select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout) time([1179697855]) = 1179697855 close(3) = 0 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 11), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f06000 write(1, "CRITICAL: No DHCPOFFERs were rec"..., 39CRITICAL: No DHCPOFFERs were received. ) = 39 munmap(0xb7f06000, 4096) = 0 exit_group(2) = ? Process 15586 detached ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-20 07:35 Message: Logged In: YES user_id=1694341 Originator: NO Hi all, I'm setting this one back to Resolution: None, because reuben's problem is reproducable using the cvs version for me. First i didn't get dhcpd to send a reply at all. That was caused by incorrect udp checksums which dhcpd didn't like. So I switched off checksum offloading in the network driver and finally came into reuben's situation. So I did some investigations and have following notes now: - problem encounters if check_dhcp is run from the same system serving dhcp - the select times out according to strace - offers are sent according to tcpdump/ethereal - dhcpcd-test works flawlessly - check_dhcp works on remote system The fact that select times out makes me think that no data actually arrives at the socket. If two servers are online, i get only the response from the remote server. One more thing I noticed is that dhcpcd-test sends discovers with source ip 0.0.0.0 but the offers are sent to the offered destination ip. A dest-ip the client doesn't even know - and cannot bind a socket on. I can't imagine how this works at all. Any hints? Matthias ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2007-05-19 06:42 Message: Logged In: YES user_id=26209 Originator: NO Yes seems that the issue still persists: tornado libexec # ./check_dhcp -v -i vlan10 -s 192.168.10.12 Requested server address: 192.168.10.12 DHCP socket: 3 Hardware address: 001676ce4a2c DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 348330319 (0x14C3194F) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 CRITICAL: No DHCPOFFERs were received. tornado libexec # Meanwhile, the server logged: May 19 23:34:51 tornado dhcpd: DHCPDISCOVER from 00:16:76:ce:4a:2c via vlan10 May 19 23:34:51 tornado dhcpd: DHCPOFFER on 192.168.10.24 to 00:16:76:ce:4a:2c via vlan10 Running just: ./check_dhcp results in a "CRITICAL: No DHCPOFFERs were received" message. I'm now running Gentoo not Fedora, but I gather that's probably not that critical anyway. I have a second, FC6 system which I manage which exhibits the same problem with this plugin (it doesn't use a vlan interface either, it has only a single eth0 e100 NIC in it). reuben ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2007-05-18 04:14 Message: Logged In: YES user_id=1694341 Originator: NO sent an email to reuben, to ask if the problem still persists ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2006-05-28 06:29 Message: Logged In: YES user_id=26209 In my case the problem seems to be caused by the plugin being run on the *same system* as the DHCP server. I did raise this earlier but I don't think it was investigated and obviously not fixed. Regardless, that is still the case and seems to be the cause of the problem for me. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2006-05-25 21:32 Message: Logged In: YES user_id=26209 Nope, still broken for me with current CVS. The DHCP server offers the lease but it is not responded to..and the check_dhcp test fails. I'll do some more looking into this this weekend. ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 11:11 Message: Logged In: YES user_id=2225 Based on previous comments, it looks like this was already fixed in CVS a while ago... ---------------------------------------------------------------------- Comment By: Ethan Galstad (egalstad) Date: 2006-05-25 10:57 Message: Logged In: YES user_id=2225 Can the folks who were experiencing this problem please check out the latest CVS version of check_dhcp? If I don't hear any problem reports in the next few weeks, I'll be closing this item. Thanks! ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-08 00:33 Message: Logged In: YES user_id=724669 Right. I *should have* tried the CVS. I compiled it on my dev box (FC3), copied it to my FC2 machine and it worked fine there. So I suppose the bug isn't all that, now. But that made me curious. I went and got each previous revision of check_dhcp.c, recompiled and they all worked. So I suspected a problem in Dag's rpm package. I copied the "bad" binary to another FC2 machine and there it works. The only difference is an SMP kernel where it failed, and the UP kernel (same version) on the other. But that's just useless trivia now I suppose since the version compiled by hand works either way. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-02-07 15:17 Message: Logged In: YES user_id=395628 Dear Laurentiu, I think you are correct there are _two_ problems. I think that one has been dealt with (ie packet filtering and or alias interface misbehaviour). I agree with your analysis - why should recv() fail when select says the read handle is ready for reading. Are you familair with gdb ? A gdb session with check_dhcp is the way to deal with this. recvfrom(3, 0xfef67370, 548, 2, 0xfef67280, 0xfef67274) socket, pointer to buffer, buffer len, flags, pointer to from and pointer to from len. I guess that 2 is MSG_PEEK (from the notes in the text). Is 2 the value of MSG_PEEK on your system. Hey ! The plugin is 1.3. You must try the CVS. Yours sincerely. ---------------------------------------------------------------------- Comment By: Laurentiu C. Badea (L.C.) (wotevah) Date: 2005-02-07 10:45 Message: Logged In: YES user_id=724669 I have to apologize, I haven't been monitoring this report (I was kind of hoping SF would send notification emails on activity, but it didn't). Anyway, I noticed a difference between my strace and the others, that may be significant. Specifically, the select() call returns with data on the socket in my version (but the recvfrom still fails!), while it times out in the others. So we may be dealing with two different problems here. Yes, exactly what you wanted to hear, isn't it... I'll try the CVS version later on tonight and let you know. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 02:48 Message: Logged In: YES user_id=26209 Ok it's a flat topology: * Single switch * Single router, with 192.168.0.1 internally, 60.234.x.x address externally doing NAT * Single Linux server, 2.6.11-rc1-mm2 (at the moment), with eth0 (192.168.0.3) eth0:0 (192.168.0.4) gre0 (172 address) and a loopback. The machine has only one NIC. Clients are also on the 192.168.0.0/24 network. Simple home network ;-) dhcpd is not bound to any particular interface, but when I shut down gre0 and eth0:0 and then restarted dhcpd to avoid binding problems, same result when running check_dhcp :( Jan 24 23:08:03 tornado dhcpd: Internet Systems Consortium DHCP Server V3.0.2rc3 Jan 24 23:08:03 tornado dhcpd: Copyright 2004 Internet Systems Consortium. Jan 24 23:08:03 tornado dhcpd: All rights reserved. Jan 24 23:08:03 tornado dhcpd: For info, please visit http://www.isc.org/sw/dhcp/ Jan 24 23:08:03 tornado dhcpd: Internet Systems Consortium DHCP Server V3.0.2rc3 Jan 24 23:08:03 tornado dhcpd: Copyright 2004 Internet Systems Consortium. Jan 24 23:08:03 tornado dhcpd: All rights reserved. Jan 24 23:08:03 tornado dhcpd: For info, please visit http://www.isc.org/sw/dhcp/ Jan 24 23:08:03 tornado dhcpd: Wrote 0 deleted host decls to leases file. Jan 24 23:08:03 tornado dhcpd: Wrote 0 new dynamic host decls to leases file. Jan 24 23:08:03 tornado dhcpd: Wrote 4 leases to leases file. Jan 24 23:08:03 tornado dhcpd: Listening on LPF/eth0/00:0d:61:5e:8b:b3/192.168.0.0/24 Jan 24 23:08:03 tornado dhcpd: Sending on LPF/eth0/00:0d:61:5e:8b:b3/192.168.0.0/24 Jan 24 23:08:03 tornado dhcpd: Sending on Socket/fallback/fallback-net Jan 24 23:13:03 tornado dhcpd: DHCPDISCOVER from 00:0d:61:5e:8b:b3 via eth0 Jan 24 23:13:04 tornado dhcpd: DHCPOFFER on 192.168.0.11 to 00:0d:61:5e:8b:b3 via eth0 ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-24 02:31 Message: Logged In: YES user_id=395628 Thanks very much for your comment Reuben. Please would you consider letting me know 1 whether eth0:0 is a 'virtual' interface ? Does the host running check dhcp have two (2) NICs ? 2 try and sketch the topology for me Is it | |--------- check_dhcp/dhcpd --------| | etho eth1 | | some other /x |------------ router 192.168.0.0/24 ? Which interface is dhcpd bound to ? You are welcome to write me direct (SHopcroft at IPAustralia.Gov.AU) if that's more convenient. Thank you. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 02:09 Message: Logged In: YES user_id=26209 I've just down'ed eth0:0 and restarted dhcpd, still same result....... :( Router is connected to 192.168.0.0/24 and external (routable) IP address only. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-24 02:04 Message: Logged In: YES user_id=395628 Firstly, a very heart felt thank you to zytak and reuben for their willingness to test, listen to my silly remarks and retest. This release owes a lot to both gentlemen. (your initiative also saved you hearing more silly remarks such as did you regen configure ? ...) All ones (ie 255.255.255.255) broadcasts has some 'minor gotchas' that appear to be evident here. (See Unix Network Programming vol 1 p 471-2) I think what is happening is that 1 check_dhcp broadcasts are only being sent from the primary (eth0) interface and are being transformed from 'all-ones' to 'subnet-directed' broadcast (the broadcast ip address of eth0). 2 your dhcp server is replying with a broadcast on _that_ prefix network which your secondary interface - check_dhcp - is not connected to. Presumably, your router is connected to both LANs and will reply on _all_ interfaces - since some OS's replicate broadcasts on _all_ their interfaces. Thanks very much for your comments. Will update the usage information ... ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 01:12 Message: Logged In: YES user_id=26209 Ok, some progress. If I serve up DHCP from my cisco router with dhcpd off on my server, check_dhcp works just fine: [root at tornado ~]# /usr/lib/nagios/plugins/check_dhcp DHCP ok: Received 1 DHCPOFFER(s), max lease time = 86400 sec. If I then turn dhcp off on the router and re-enable dhcpd on my server, it fails again. So it appears that running check_dhcp from the same host as the dhcp server is a no-go, at least in my case......... ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 01:02 Message: Logged In: YES user_id=26209 I still experience the problem even with my iptables rules off: [root at tornado nagiosplug]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at tornado nagiosplug]# iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT tcp -- network.reub.net/16 !network.reub.net/16 tcp dpt:http to:192.168.0.3:3128 Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at tornado nagiosplug]# Other possible ideas: * I have two IP addresses, a main and a secondary IP address on eth0(:0) * My server which does the monitoring also does DHCP If I can come up with anything I'll post here. ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-24 00:59 Message: Logged In: YES user_id=26209 Firstly, can I confirm that sourceforge CVS has the most current version? Latest CVS has: $Id: check_dhcp.c,v 1.6 2004/12/30 00:41:39 opensides Exp $ I don't think your latest changes have made it into the publically visible repo :( Here's an strace: [root at tornado nagiosplug]# strace /usr/lib/nagios/plugins/check_dhcp execve("/usr/lib/nagios/plugins/check_dhcp", ["/usr/lib/nagios/plugins/check_dhcp"], [/* 22 vars */]) = 0 uname({sys="Linux", node="tornado", ...}) = 0 brk(0) = 0x804e000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=39607, ...}) = 0 old_mmap(NULL, 39607, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ff6000 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\320D\7"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=97608, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ff5000 old_mmap(0x4b071000, 88064, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4b071000 old_mmap(0x4b083000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0x4b083000 old_mmap(0x4b085000, 6144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4b085000 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\360\343"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=81252, ...}) = 0 old_mmap(0x4b02c000, 75944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4b02c000 old_mmap(0x4b03b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x4b03b000 old_mmap(0x4b03d000, 6312, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4b03d000 close(3) = 0 open("/lib/tls/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 \277\353"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1521596, ...}) = 0 old_mmap(0x4aea7000, 1215644, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4aea7000 old_mmap(0x4afca000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x123000) = 0x4afca000 old_mmap(0x4afce000, 7324, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4afce000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ff4000 mprotect(0x4afca000, 8192, PROT_READ) = 0 mprotect(0x4b03b000, 4096, PROT_READ) = 0 mprotect(0x4b083000, 4096, PROT_READ) = 0 mprotect(0x4aea3000, 4096, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ff46c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xb7ff6000, 39607) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=39591472, ...}) = 0 mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7df4000 mmap2(NULL, 204800, PROT_READ, MAP_PRIVATE, 3, 0x1029) = 0xb7dc2000 brk(0) = 0x804e000 brk(0x806f000) = 0x806f000 mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x1072) = 0xb7dc1000 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE, "eth0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\264\356\377\277\370"..., 32) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(68), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 ioctl(3, SIOCGIFHWADDR, 0xbfffedd0) = 0 time(NULL) = 1106556165 sendto(3, "\1\1\6\0\34|\211\212\377\0\200\0\0\0\0\0\0\0\0\0\0\0\0"..., 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1106556165]) = 1106556165 time([1106556165]) = 1106556165 select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout) time([1106556167]) = 1106556167 close(3) = 0 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dc0000 open("/usr/share/locale/locale.alias", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2528, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7da0000 read(3, "# Locale name alias data base.\n#"..., 131072) = 2528 read(3, "", 131072) = 0 close(3) = 0 munmap(0xb7da0000, 131072) = 0 open("/usr/share/nagios/locale/en_US/LC_MESSAGES/nagios-plugins.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/nagios/locale/en/LC_MESSAGES/nagios-plugins.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(1, "DHCP problem: No DHCPOFFERs were"..., 43DHCP problem: No DHCPOFFERs were received. ) = 43 munmap(0xb7dc0000, 4096) = 0 exit_group(2) = ? [root at tornado nagiosplug]# Also: [root at tornado nagiosplug]# /usr/lib/nagios/plugins/check_dhcp -v DHCP socket: 3 Hardware address: 000d615e8bb3 DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 842612958 (0x323940DE) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 DHCP problem: No DHCPOFFERs were received. [root at tornado nagiosplug]# ---------------------------------------------------------------------- Comment By: zyta2k (zyta2k) Date: 2005-01-24 00:48 Message: Logged In: YES user_id=544197 Wooooops :/ Shame on me =) flushed all iptables rules and now it works... The "strange thing" is: dhcp is fully functional if I use the same rulebase !! Here are the rules ---- schnippi ---- Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp any ACCEPT ipv6-crypt-- anywhere anywhere ACCEPT ipv6-auth-- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:5353 ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ftp ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh REJECT all -- anywhere anywhere reject-with icmp-host-prohibited ---- schnappi ---- ?m... no idea which rule stops the check_dhcp plug... :/ ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-23 18:57 Message: Logged In: YES user_id=395628 Dear Folks, I am perplexed about this problem. 1 the open socket won't ignore a broadcast reply with the dhcp client port unless the reply is filtered by some kernel packet filter (iptable on Linux ?), or there is a firewall or router between the client and server. Given the PRs this doesn't seem likely. 2 the failure is however consistent with L.C's (Laurentiu C. Badea) PR showing EINVAL from the recvfrom call. Please would either L.C., Rueben Farrelly or zyta2k do an strace or equivalent (truss/ktrace ?) to show if recvfrom is still returning -1/EINVAL from a CVS copy (not many changes from L.C's report of the prob with the 1.3 plugins but its nice to be sure) EINVAL seems to suggest an argument problem but I can't imagine what this may be - the parms seem fine. Thank you. ---------------------------------------------------------------------- Comment By: Stanley Hopcroft (stanleyhopcroft) Date: 2005-01-21 01:35 Message: Logged In: YES user_id=395628 Thank you for a superb PR. Unfortunately, this is unlikely to help you much but would you please try the latest CVS (not tar ball) and post your command invocation (changes have been made to get it to build properly on Linux and FreeBSD - you seem to have done this yourself). On FreeBSD 4.10 and ISC dhcpd (V3.0.1rc14), it works Ok. The reply to the discover should be a broadcast (methinks) since the client has no ip. Thanks for your help. ---------------------------------------------------------------------- Comment By: zyta2k (zyta2k) Date: 2005-01-04 02:41 Message: Logged In: YES user_id=544197 I can confirm the problem... === Verbose Output From Plugin === DHCP socket: 3 Hardware address: 00110a32c75e DHCPDISCOVER to 255.255.255.255 port 67 DHCPDISCOVER XID: 1269450911 (0x4BAA489F) DHCDISCOVER ciaddr: 0.0.0.0 DHCDISCOVER yiaddr: 0.0.0.0 DHCDISCOVER siaddr: 0.0.0.0 DHCDISCOVER giaddr: 0.0.0.0 send_dhcp_packet result: 548 No (more) data received Result=ERROR Total responses seen on the wire: 0 Valid responses for this machine: 0 DHCP problem: No DHCPOFFERs were received. ============= TCPDUMP ============ # tcpdump -vv dst port 68 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:25:54.418410 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto 17, length: 341) dhcp01.foobar.com > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000) Your IP: 10.29.20.121 Server IP: dhcp01.foobar.com Gateway IP: 10.29.20.2 Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp] 11:25:54.418675 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto 17, length: 341) dhcp01.foobar.com.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000) Your IP: 10.29.20.121 Server IP: dhcp01.foobar.com Gateway IP: 10.29.20.3 Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp] 11:25:54.418975 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto 17, length: 341) dhcp02.foobar.com.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000) Your IP: 10.29.20.143 Server IP: dhcp02.foobar.com Gateway IP: 10.29.20.2 Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp] 11:25:54.421156 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto 17, length: 341) dhcp02.foobar.com.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 313, xid:0x4baa489f, secs:65280, flags: [Broadcast] (0x8000) Your IP: 10.29.20.143 Server IP: dhcp02.foobar.com Gateway IP: 10.29.20.3 Client Ethernet Address: 00:11:0a:32:c7:5e [|bootp] 4 packets captured 4 packets received by filter 0 packets dropped by kernel ========== MY SYSTEM ============= Distribution: Fedora Core 3 Kernel: 2.6.9 Glibc: 2.3.4 Plugin Version: CVS v 1.6 2004/12/30 00:41:39 hth zyta2k ---------------------------------------------------------------------- Comment By: Reuben Farrelly (reuben) Date: 2005-01-02 12:48 Message: Logged In: YES user_id=26209 Still no go here either using bleeding edge CVS (on FC3): sendto(3, "\1\1\6\0\6\372\275\241\377\0\200\0\0\0\0\0\0\0\0\0\0\0"..., 548, 0, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("255.255.255.255")}, 16) = 548 time([1104698558]) = 1104698558 time([1104698558]) = 1104698558 select(4, [3], NULL, NULL, {2, 0}) = 0 (Timeout) time([1104698560]) = 1104698560 close(3) = 0 Returns with "DHCP problem: No DHCPOFFERs were received." Meanwhile the DHCP server has seen the DHCPDISCOVER come in and DHCPOFFER'ed an address to 255.255.255.255.bootpc ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-02 10:42 Message: Logged In: YES user_id=388184 Hi, could you test with the lastest cvs, and report your findings Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1090549&group_id=29880 From noreply at sourceforge.net Thu Jul 11 14:54:13 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Jul 2013 05:54:13 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2555775 ] nagios check_smtp expects integer instead of double Message-ID: Bugs item #2555775, was opened at 2009-02-01 08:36 Message generated for change (Comment added) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2555775&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: nagios check_smtp expects integer instead of double Initial Comment: The following Bugreport we got against the ubuntu package: Command execution returns error with double value: # /usr/lib/nagios/plugins/check_smtp -H localhost -w 0.2 check_smtp: Warning time must be a positive integer Usage:check_smtp -H host [-p port] [-e expect] [-C command] [-f from addr][-A authtype -U authuser -P authpass] [-w warn] [-c crit] [-t timeout] [-S] [-D days] [-n] [-v] [-4|-6] But docu ( /usr/lib/nagios/plugins/check_smtp -h) says: -w, --warning=DOUBLE Response time to result in warning status (seconds) -c, --critical=DOUBLE Response time to result in critical status (seconds) I think, that the integer check is done on error, since all other commands with -w / -c option take double arguments and sub second response time checks are really useful. ----------------------------------------- Current package: Status: install ok installed Priority: extra Section: net Installed-Size: 1252 Maintainer: Ubuntu Core Developers Architecture: i386 Source: nagios-plugins Version: 1.4.11-1ubuntu5 ---------------------------------------- Patch vs nagios-plugins-1.4.12 source (untested): --- check_smtp.orig 2009-01-19 10:57:05.000000000 +0100 +++ check_smtp.c 2009-01-19 11:34:04.000000000 +0100 @@ -103,9 +103,9 @@ char *authtype = NULL; char *authuser = NULL; char *authpass = NULL; -int warning_time = 0; +double warning_time = 0; int check_warning_time = FALSE; -int critical_time = 0; +double critical_time = 0; int check_critical_time = FALSE; int verbose = 0; int use_ssl = FALSE; @@ -432,9 +432,9 @@ elapsed_time = (double)microsec / 1.0e6; if (result == STATE_OK) { - if (check_critical_time && elapsed_time > (double) critical_time) + if (check_critical_time && elapsed_time > critical_time) result = STATE_CRITICAL; - else if (check_warning_time && elapsed_time > (double) warning_time) + else if (check_warning_time && elapsed_time > warning_time) result = STATE_WARNING; } @@ -565,21 +565,19 @@ nresponses++; break; case 'c': /* critical time threshold */ - if (is_intnonneg (optarg)) { - critical_time = atoi (optarg); - check_critical_time = TRUE; - } + if (!is_nonnegative (optarg)) + usage4 (_("Critical time must be a positive")); else { - usage4 (_("Critical time must be a positive integer")); + critical_time = strtod (optarg, NULL); + check_critical_time = TRUE; } break; case 'w': /* warning time threshold */ - if (is_intnonneg (optarg)) { - warning_time = atoi (optarg); - check_warning_time = TRUE; - } + if (!is_nonnegative (optarg)) + usage4 (_("Warning time must be a positive")); else { - usage4 (_("Warning time must be a positive integer")); + warning_time = strtod (optarg, NULL); + check_warning_time = TRUE; } break; case 'v': /* verbose */ Cross comparison with other files (e.g. check_http.c) showed that there might be more of these issues, e.g. wrong message outputs/conversions case 'w': /* warning time threshold */ if (!is_nonnegative (optarg)) usage2 (_("Warning threshold must be integer"), optarg); else { warning_time = strtod (optarg, NULL); check_warning_time = TRUE; } break; You can track the whole bugreport at https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/318703 Thank, Jan. ---------------------------------------------------------------------- >Comment By: Jan Wagner (cyco_dd) Date: 2013-07-11 05:54 Message: pull request pending: https://github.com/nagios-plugins/nagios-plugins/pull/58 ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-02-04 20:37 Message: Thanks for your report. The proper fix would rather be using the nagios thresholds functions. OTOH it's more likely that we put time toward implementing the new thresholds format than fixing plugins that were never converted to the old one. Feel free to attach a working patch if you wish - we'll consider it anyway. Otherwise a quick fix would rather be fixing the documentation. ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2009-02-01 08:51 Message: File Added: patch-nagios-plugins-1.4.12 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2555775&group_id=29880 From noreply at sourceforge.net Thu Jul 11 18:01:50 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Jul 2013 09:01:50 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614674 ] [Mayhem] Crashes while passing garbage as argument Message-ID: Bugs item #3614674, was opened at 2013-07-11 09:01 Message generated for change (Tracker Item Submitted) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614674&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: [Mayhem] Crashes while passing garbage as argument Initial Comment: The Mayhem[1] project tested all Debian binary packages if they can be crashed by passing garbage arguments. For nagios-plugins there was found a couple of bugs: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=nagios-plugins;dist=unstable;submitter=alexandre%40cmu.edu Whould be nice to have those fixed, even if they are minor issues. Many thanks, Jan. [1] http://lists.debian.org/debian-devel/2013/06/msg00720.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614674&group_id=29880 From noreply at sourceforge.net Thu Jul 11 18:09:54 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 11 Jul 2013 09:09:54 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2555775 ] nagios check_smtp expects integer instead of double Message-ID: Bugs item #2555775, was opened at 2009-02-01 08:36 Message generated for change (Settings changed) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2555775&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) >Assigned to: Holger Weiss (hweiss) Summary: nagios check_smtp expects integer instead of double Initial Comment: The following Bugreport we got against the ubuntu package: Command execution returns error with double value: # /usr/lib/nagios/plugins/check_smtp -H localhost -w 0.2 check_smtp: Warning time must be a positive integer Usage:check_smtp -H host [-p port] [-e expect] [-C command] [-f from addr][-A authtype -U authuser -P authpass] [-w warn] [-c crit] [-t timeout] [-S] [-D days] [-n] [-v] [-4|-6] But docu ( /usr/lib/nagios/plugins/check_smtp -h) says: -w, --warning=DOUBLE Response time to result in warning status (seconds) -c, --critical=DOUBLE Response time to result in critical status (seconds) I think, that the integer check is done on error, since all other commands with -w / -c option take double arguments and sub second response time checks are really useful. ----------------------------------------- Current package: Status: install ok installed Priority: extra Section: net Installed-Size: 1252 Maintainer: Ubuntu Core Developers Architecture: i386 Source: nagios-plugins Version: 1.4.11-1ubuntu5 ---------------------------------------- Patch vs nagios-plugins-1.4.12 source (untested): --- check_smtp.orig 2009-01-19 10:57:05.000000000 +0100 +++ check_smtp.c 2009-01-19 11:34:04.000000000 +0100 @@ -103,9 +103,9 @@ char *authtype = NULL; char *authuser = NULL; char *authpass = NULL; -int warning_time = 0; +double warning_time = 0; int check_warning_time = FALSE; -int critical_time = 0; +double critical_time = 0; int check_critical_time = FALSE; int verbose = 0; int use_ssl = FALSE; @@ -432,9 +432,9 @@ elapsed_time = (double)microsec / 1.0e6; if (result == STATE_OK) { - if (check_critical_time && elapsed_time > (double) critical_time) + if (check_critical_time && elapsed_time > critical_time) result = STATE_CRITICAL; - else if (check_warning_time && elapsed_time > (double) warning_time) + else if (check_warning_time && elapsed_time > warning_time) result = STATE_WARNING; } @@ -565,21 +565,19 @@ nresponses++; break; case 'c': /* critical time threshold */ - if (is_intnonneg (optarg)) { - critical_time = atoi (optarg); - check_critical_time = TRUE; - } + if (!is_nonnegative (optarg)) + usage4 (_("Critical time must be a positive")); else { - usage4 (_("Critical time must be a positive integer")); + critical_time = strtod (optarg, NULL); + check_critical_time = TRUE; } break; case 'w': /* warning time threshold */ - if (is_intnonneg (optarg)) { - warning_time = atoi (optarg); - check_warning_time = TRUE; - } + if (!is_nonnegative (optarg)) + usage4 (_("Warning time must be a positive")); else { - usage4 (_("Warning time must be a positive integer")); + warning_time = strtod (optarg, NULL); + check_warning_time = TRUE; } break; case 'v': /* verbose */ Cross comparison with other files (e.g. check_http.c) showed that there might be more of these issues, e.g. wrong message outputs/conversions case 'w': /* warning time threshold */ if (!is_nonnegative (optarg)) usage2 (_("Warning threshold must be integer"), optarg); else { warning_time = strtod (optarg, NULL); check_warning_time = TRUE; } break; You can track the whole bugreport at https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/318703 Thank, Jan. ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2013-07-11 05:54 Message: pull request pending: https://github.com/nagios-plugins/nagios-plugins/pull/58 ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-02-04 20:37 Message: Thanks for your report. The proper fix would rather be using the nagios thresholds functions. OTOH it's more likely that we put time toward implementing the new thresholds format than fixing plugins that were never converted to the old one. Feel free to attach a working patch if you wish - we'll consider it anyway. Otherwise a quick fix would rather be fixing the documentation. ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2009-02-01 08:51 Message: File Added: patch-nagios-plugins-1.4.12 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2555775&group_id=29880 From donkishoot at neuf.fr Fri Jul 12 11:18:03 2013 From: donkishoot at neuf.fr (DonKiShoot) Date: Fri, 12 Jul 2013 11:18:03 +0200 Subject: [Nagiosplug-devel] check_snmp bug on some strings Message-ID: <51DFC9CB.7090204@neuf.fr> Hi list, I found my problem and will reply to myself and maybe to other users with the same problem. If you received hexadecimal values in reply, you probably need to add parameter '-m' and specify the mib file for the OID you check. Sorry to have disturbing. Regards, ----------------------------------------------------------------------------------------------------- Hi list, check_snmp bug on some strings while snmpget has no problem Client version : net-snmp-5.3.2.2-20.el5 Server version : net-snmp-5.3.2.2-20.el5 To describe a minimum, i'm trying to retreive two oids. The first oid correspond to a number who represent the exit code from a command. The second oid correspond to the result string of the same command. For more information see 'extend' parameter from snmpd.conf Now the bug ... Example OK : /usr/lib64/nagios/plugins/check_snmp -H 192.168.1.1 -P 2c -C public -o .1.3.6.1.4.1.8072.1.3.2.3.1.4.10.84.97.98.108.101.83.112.97.99.101,.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.84.97.98.108.101.83.112.97.99.101.1 -w 1 -c 2 SNMP CRITICAL - *3* "Usage: check_oracle --tns check_oracle --db check_oracle --login check_oracle --cache check_oracle --tablespace check_oracle --oranames check_oracle --help check_oracle --version" | iso.3.6.1.4.1.8072.1.3.2.3.1.4.10.84.97.98.108.101.83.112.97.99.101=3 Example KO : /usr/lib64/nagios/plugins/check_snmp -H 192.168.1.1 -P 2c -C public -o .1.3.6.1.4.1.8072.1.3.2.3.1.4.10.84.97.98.108.101.83.112.97.99.101,.1.3.6.1.4.1.8072.1.3.2.4.1.2.10.84.97.98.108.101.83.112.97.99.101.1 -w 1 -c 2 SNMP WARNING - *2* 43 52 49 54 49 43 41 4C 20 2D 20 4F 52 41 2D 31| iso.3.6.1.4.1.8072.1.3.2.3.1.4.10.84.97.98.108.101.83.112.97.99.101=2 iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.84.97.98.108.101.83.112.97.99.101.1=43 check_snmp return hexa characters "43 52 49 54 49 43 41 4C 20 2D 20 4F 52 41 2D 31 ..." instead of a string like on the first check With snmpget the string is ok : snmpget -v2c -c altaread 10.2.50.111 iso.3.6.1.4.1.8072.1.3.2.4.1.2.10.84.97.98.108.101.83.112.97.99.101.1 NET-SNMP-EXTEND-MIB::nsExtendOutLine."TableSpace".1 = STRING: CRITICAL - ORA-12154: TNS : l'identificateur de connexion indiqu? n'a pas pu ?tre r?solu What can i do to receive the string instead of Hexa characters ??? PS: Sorry for my poor english Regards, From palli at ok.is Mon Jul 15 22:57:46 2013 From: palli at ok.is (=?utf-8?Q?P=C3=A1ll_Gu=C3=B0j=C3=B3n_Sigur=C3=B0sson?=) Date: Mon, 15 Jul 2013 20:57:46 -0000 (GMT) Subject: [Nagiosplug-devel] New Threshold Syntax In-Reply-To: Message-ID: Hey William, Cool project you have going on! My humble two cents to follow. We implemented same RFC in pynag (python modules for nagios related stuff). We also hit some walls and wanted to make modifications. Unfortunately, it's been a long time since it was written and author of the proposal is not answering my emails on the topic. I am not sure if there is a lot of motivation among the nagios-plugins folks to implement this RFC, so i wonder if third party libraries like you and should coordinate on it anyway ? On the topic of multiple thresholds with different suffix (i.e. adding -rate to a threshold) i say, the RFC should NOT cover that situation and its up to the plugin developer to create multiple differently named metrics for this (my two cents) Mathematical syntax is already an established standard, but i agree that easy shell expansion is more important. Cheers, Palli ----- Original Message ----- From: "William Leibzon" To: "Nagios Plugin Development Mailing List" Sent: Monday, July 1, 2013 10:13:49 PM Subject: Re: [Nagiosplug-devel] New Threshold Syntax Hi, I appreciate the comments, my replies to them are further below. And seeing as there is some interest in this and it should be better documented, I've decided to extend existing doc and put into wiki which is open to pubic editing. The wiki is on my github copy of nagios-plugins main repository: https://github.com/willixix/nagios-plugins/wiki/New-Threshold-Syntax Please check it out and tell me what you think. Above in addition to extensions I mentioned in my first email (using ':' in addition to '=', adding 'perf' and 'absent' keywords), I also added several additional keywords: name:{name} - this is used to specify threshold that would apply to specific named attribute, this could be specific process name in case of check_procs or it could be specific partition for check_disk, etc. Note - I should extend set of symbols allowed there, somebody please comment what it should be. label:{label} - this is used to re-label named attribute for purpose of displaying it in status line or in perf awarn:{range], acrit:{range} - these add capability to specify that multiple warn (or critial) threshold levels must all match i.e. its logical AND rather than logical OR which is default if multiple warn and crit appear. I need this for combining multiple types of checks on same metric. This spec is what I intend to implement in my perl library (and most of this functionality is already there now) and what will eventually be used by majority of my plugins. And hopefully other plugin library writers who were willing to implement proposed format would follow with these extensions as well - overall it is still same as original proposal. And I'd be willing to create ABNF and more formal spec doc (similar to RFC, and I have participated in IETF and written drafts) if people want to go that way. On Sun, Jun 30, 2013 at 10:08 AM, Jochen Bern wrote: >>> Why not use the "mathematical syntax"? For this we need [] instead of () () and [] are in fact correct mathematical notation for open an close interval which also allows for mix of those brackets >>> Examples: >>> [1..5] means 1 ? x ? 5 >>> [1..5[ means 1 ? x < 5 >>> ]1..5] means 1 < x ? 5 >>> ]1..5[ means 1 < x < 5 I agree that you can do things by redefining ] bracket at start to mean (. But to me this looks less natural, perhaps because I have a graduate math degree :) Anyway I don't see strong reasons to not use both types of brackets and its easier for the parsers too. > Folks, you're spending a lot of mental effort over something that won't > get you noticeable appreciation. The thing that will win users and other > plugin authors over to a new syntax is not that it looks nicer or more > similar to existing notation conventions in whatever field, it's that it > allows them to do the things they need to do now and in the upcoming > years and that they had to *hack* with the former standard. In other > words, *functionality* (that the syntax is bound to have to adapt to to > a certain degree, anyway). I agree. My starting premise to work on this was to develop better format to express complex thresholds that I could not do with existing including being able to specify complex consisting of multiple types of checks on same metric in the future and more. I came up on my own (and without knowing about new threshold syntax) with something that is very much like it. The main difference is that I never bothered to re-define range so my current library parses threshold line kind-of like new format but with range specified using old style nagios way plus also my own ">num", " I the wrote the comment under > http://nagiosplugins.org/rfc/new_threshold_syntax > , and I'm *STILL* waiting for a check_disk (to reuse the example) that I > can tell to consider the minfree part of the available diskspace for > /var/log, but not /tmp, This will be possible to do using "name" keyword. I brought it over from my own specification (although in my own it also meant label which is confusing and I separated it). William ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________________ Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net Unsubscribe at 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 Jul 16 16:17:06 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Jul 2013 07:17:06 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614716 ] np_net_ssl_read fails to take SSL_WANT_READ into account Message-ID: Bugs item #3614716, was opened at 2013-07-16 07:17 Message generated for change (Tracker Item Submitted) made by pepijn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pepijn Schmitz (pepijn) Assigned to: Nobody/Anonymous (nobody) Summary: np_net_ssl_read fails to take SSL_WANT_READ into account Initial Comment: The np_net_ssl_read function in sslutils.c fails to take the SSL_ERROR_WANT_READ return code into account. This is not an error but indicates that the read should be retried. It can occur for instance when an SSL/TLS renegotiation occurs. This is causing the following check_http command to fail with a "HTTP CRITICAL - Error on receive" message, causing a false negative (the site in question works fine): check_http -I www.essentialmall.com -S The fix is to replace the np_net_ssl_read() function with this: int np_net_ssl_read(void *buf, int num) { int rc; do { rc = SSL_read(s, buf, num); } while ((rc < 0) && (SSL_get_error(s, rc) == SSL_ERROR_WANT_READ)); return rc; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 From noreply at sourceforge.net Tue Jul 16 16:19:08 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Jul 2013 07:19:08 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614716 ] np_net_ssl_read fails to take SSL_WANT_READ into account Message-ID: Bugs item #3614716, was opened at 2013-07-16 07:17 Message generated for change (Comment added) made by pepijn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pepijn Schmitz (pepijn) Assigned to: Nobody/Anonymous (nobody) Summary: np_net_ssl_read fails to take SSL_WANT_READ into account Initial Comment: The np_net_ssl_read function in sslutils.c fails to take the SSL_ERROR_WANT_READ return code into account. This is not an error but indicates that the read should be retried. It can occur for instance when an SSL/TLS renegotiation occurs. This is causing the following check_http command to fail with a "HTTP CRITICAL - Error on receive" message, causing a false negative (the site in question works fine): check_http -I www.essentialmall.com -S The fix is to replace the np_net_ssl_read() function with this: int np_net_ssl_read(void *buf, int num) { int rc; do { rc = SSL_read(s, buf, num); } while ((rc < 0) && (SSL_get_error(s, rc) == SSL_ERROR_WANT_READ)); return rc; } ---------------------------------------------------------------------- Comment By: Pepijn Schmitz (pepijn) Date: 2013-07-16 07:19 Message: This is in release 1.4.16. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 From noreply at sourceforge.net Tue Jul 16 18:40:12 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Jul 2013 09:40:12 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614716 ] np_net_ssl_read fails to take SSL_WANT_READ into account Message-ID: Bugs item #3614716, was opened at 2013-07-16 07:17 Message generated for change (Comment added) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pepijn Schmitz (pepijn) Assigned to: Nobody/Anonymous (nobody) Summary: np_net_ssl_read fails to take SSL_WANT_READ into account Initial Comment: The np_net_ssl_read function in sslutils.c fails to take the SSL_ERROR_WANT_READ return code into account. This is not an error but indicates that the read should be retried. It can occur for instance when an SSL/TLS renegotiation occurs. This is causing the following check_http command to fail with a "HTTP CRITICAL - Error on receive" message, causing a false negative (the site in question works fine): check_http -I www.essentialmall.com -S The fix is to replace the np_net_ssl_read() function with this: int np_net_ssl_read(void *buf, int num) { int rc; do { rc = SSL_read(s, buf, num); } while ((rc < 0) && (SSL_get_error(s, rc) == SSL_ERROR_WANT_READ)); return rc; } ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2013-07-16 09:40 Message: easiest way to get patches integrated is to send push requests to https://github.com/nagios-plugins/nagios-plugins ---------------------------------------------------------------------- Comment By: Pepijn Schmitz (pepijn) Date: 2013-07-16 07:19 Message: This is in release 1.4.16. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 From noreply at sourceforge.net Tue Jul 16 22:24:37 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Jul 2013 13:24:37 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614716 ] np_net_ssl_read fails to take SSL_WANT_READ into account Message-ID: Bugs item #3614716, was opened at 2013-07-16 07:17 Message generated for change (Settings changed) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pepijn Schmitz (pepijn) >Assigned to: Holger Weiss (hweiss) Summary: np_net_ssl_read fails to take SSL_WANT_READ into account Initial Comment: The np_net_ssl_read function in sslutils.c fails to take the SSL_ERROR_WANT_READ return code into account. This is not an error but indicates that the read should be retried. It can occur for instance when an SSL/TLS renegotiation occurs. This is causing the following check_http command to fail with a "HTTP CRITICAL - Error on receive" message, causing a false negative (the site in question works fine): check_http -I www.essentialmall.com -S The fix is to replace the np_net_ssl_read() function with this: int np_net_ssl_read(void *buf, int num) { int rc; do { rc = SSL_read(s, buf, num); } while ((rc < 0) && (SSL_get_error(s, rc) == SSL_ERROR_WANT_READ)); return rc; } ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2013-07-16 09:40 Message: easiest way to get patches integrated is to send push requests to https://github.com/nagios-plugins/nagios-plugins ---------------------------------------------------------------------- Comment By: Pepijn Schmitz (pepijn) Date: 2013-07-16 07:19 Message: This is in release 1.4.16. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 From william at leibzon.org Tue Jul 16 23:16:30 2013 From: william at leibzon.org (William Leibzon) Date: Tue, 16 Jul 2013 14:16:30 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614716 ] np_net_ssl_read fails to take SSL_WANT_READ into account In-Reply-To: References: Message-ID: Well, you can't just continue to retry forever. There is of course general plugin timeout, but here it should have a limit on a number of retries too. > int np_net_ssl_read(void *buf, int num) { > int rc; > do { > rc = SSL_read(s, buf, num); > } while ((rc < 0) && (SSL_get_error(s, rc) == SSL_ERROR_WANT_READ)); > return rc; > } > > ---------------------------------------------------------------------- > > Comment By: Pepijn Schmitz (pepijn) > Date: 2013-07-16 07:19 > > Message: > This is in release 1.4.16. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at 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 william at leibzon.org Tue Jul 16 23:28:01 2013 From: william at leibzon.org (William Leibzon) Date: Tue, 16 Jul 2013 14:28:01 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614716 ] np_net_ssl_read fails to take SSL_WANT_READ into account In-Reply-To: References: Message-ID: Holger, I'll take this and send you a github pull request. Personally I think if it gives an error once, its not a big deal because nagios should send notifications after two or more consecutive errors. But I agree that this is valid point and SSL_WANT_READ needs to be handled. For my fix I'll add short delay between retries and max # of retries. On Tue, Jul 16, 2013 at 1:24 PM, SourceForge.net wrote: > Bugs item #3614716, was opened at 2013-07-16 07:17 > Message generated for change (Settings changed) made by hweiss > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: General plugin execution > Group: Release (specify) > Status: Open > Resolution: None > Priority: 5 > Private: No > Submitted By: Pepijn Schmitz (pepijn) >>Assigned to: Holger Weiss (hweiss) > Summary: np_net_ssl_read fails to take SSL_WANT_READ into account > > Initial Comment: > The np_net_ssl_read function in sslutils.c fails to take the SSL_ERROR_WANT_READ return code into account. This is not an error but indicates that the read should be retried. It can occur for instance when an SSL/TLS renegotiation occurs. This is causing the following check_http command to fail with a "HTTP CRITICAL - Error on receive" message, causing a false negative (the site in question works fine): > > check_http -I www.essentialmall.com -S > > The fix is to replace the np_net_ssl_read() function with this: > > int np_net_ssl_read(void *buf, int num) { > int rc; > do { > rc = SSL_read(s, buf, num); > } while ((rc < 0) && (SSL_get_error(s, rc) == SSL_ERROR_WANT_READ)); > return rc; > } > > ---------------------------------------------------------------------- > > Comment By: Jan Wagner (cyco_dd) > Date: 2013-07-16 09:40 > > Message: > easiest way to get patches integrated is to send push requests to > https://github.com/nagios-plugins/nagios-plugins > > ---------------------------------------------------------------------- > > Comment By: Pepijn Schmitz (pepijn) > Date: 2013-07-16 07:19 > > Message: > This is in release 1.4.16. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at 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 holger at cis.fu-berlin.de Wed Jul 17 00:31:44 2013 From: holger at cis.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Wed, 17 Jul 2013 00:31:44 +0200 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614716 ] np_net_ssl_read fails to take SSL_WANT_READ into account In-Reply-To: References: Message-ID: <20130716223144.GB18712@zedat.fu-berlin.de> * William Leibzon [2013-07-16 14:28]: > But I agree that this is valid point Yes. > and SSL_WANT_READ needs to be handled. I was going to check whether setting SSL_MODE_AUTO_RETRY? would be a better choice. When using blocking I/O, I don't see the point in having OpenSSL's I/O functions return SSL_WANT_READ. I just wanted to make sure this won't break GnuTLS (or older OpenSSL versions, but I think they introduced SSL_MODE_AUTO_RETRY ages ago). If GnuTLS supports SSL_MODE_AUTO_RETRY, I'd happily pull a commit that sets this mode (maybe wrapped in an "#ifdef SSL_MODE_AUTO_RETRY" if it's only supported by newer GnuTLS versions). Holger ? https://www.openssl.org/docs/ssl/SSL_CTX_set_mode.html From noreply at sourceforge.net Wed Jul 17 00:55:18 2013 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 16 Jul 2013 15:55:18 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614716 ] np_net_ssl_read fails to take SSL_WANT_READ into account Message-ID: Bugs item #3614716, was opened at 2013-07-16 07:17 Message generated for change (Comment added) made by pepijn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pepijn Schmitz (pepijn) Assigned to: Holger Weiss (hweiss) Summary: np_net_ssl_read fails to take SSL_WANT_READ into account Initial Comment: The np_net_ssl_read function in sslutils.c fails to take the SSL_ERROR_WANT_READ return code into account. This is not an error but indicates that the read should be retried. It can occur for instance when an SSL/TLS renegotiation occurs. This is causing the following check_http command to fail with a "HTTP CRITICAL - Error on receive" message, causing a false negative (the site in question works fine): check_http -I www.essentialmall.com -S The fix is to replace the np_net_ssl_read() function with this: int np_net_ssl_read(void *buf, int num) { int rc; do { rc = SSL_read(s, buf, num); } while ((rc < 0) && (SSL_get_error(s, rc) == SSL_ERROR_WANT_READ)); return rc; } ---------------------------------------------------------------------- Comment By: Pepijn Schmitz (pepijn) Date: 2013-07-16 15:55 Message: I guess the write function should be similarly adapted (for SSL_ERROR_WANT_WRITE), but I have not seen that cause a problem yet. ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2013-07-16 09:40 Message: easiest way to get patches integrated is to send push requests to https://github.com/nagios-plugins/nagios-plugins ---------------------------------------------------------------------- Comment By: Pepijn Schmitz (pepijn) Date: 2013-07-16 07:19 Message: This is in release 1.4.16. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3614716&group_id=29880 From william at leibzon.org Wed Jul 17 00:57:40 2013 From: william at leibzon.org (William Leibzon) Date: Tue, 16 Jul 2013 15:57:40 -0700 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-3614716 ] np_net_ssl_read fails to take SSL_WANT_READ into account In-Reply-To: <20130716223144.GB18712@zedat.fu-berlin.de> References: <20130716223144.GB18712@zedat.fu-berlin.de> Message-ID: On Tue, Jul 16, 2013 at 3:31 PM, Holger Wei? wrote: > * William Leibzon [2013-07-16 14:28]: >> But I agree that this is valid point > > Yes. > >> and SSL_WANT_READ needs to be handled. > > I was going to check whether setting SSL_MODE_AUTO_RETRY? would be a > better choice. When using blocking I/O, I don't see the point in having > OpenSSL's I/O functions return SSL_WANT_READ. I just wanted to make > sure this won't break GnuTLS (or older OpenSSL versions, but I think > they introduced SSL_MODE_AUTO_RETRY ages ago). If GnuTLS supports > SSL_MODE_AUTO_RETRY, I'd happily pull a commit that sets this mode > (maybe wrapped in an "#ifdef SSL_MODE_AUTO_RETRY" if it's only supported > by newer GnuTLS versions). Yeah, that's even better. It was added in 0.9.6 which is 2004. William From feytol972 at gmail.com Fri Jul 19 17:04:19 2013 From: feytol972 at gmail.com (=?ISO-8859-1?Q?OUISLY_C=E9dric?=) Date: Fri, 19 Jul 2013 17:04:19 +0200 Subject: [Nagiosplug-devel] Bug -> nagios-plugins Message-ID: Hi there, I am on debian 7 I have set up nagios without issue Trying to set up the nagios-plugins-1.4.16.tar.gz Following the procedure, everything's come well but when i do "make install", i get this : Appending installation info to /usr/local/nagios/perl/lib/i486-linux-gnu-thread-multi-64int/perllocal.pod make[3]: quittant le r?pertoire ? /usr/local/src/nagios-plugins-1.4.16/perlmods/Test-Simple-0.70 ? make[3]: entrant dans le r?pertoire ? /usr/local/src/nagios-plugins-1.4.16/perlmods/Params-Validate-0.88 ? cc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -DVERSION=\"0.88\" -DXS_VERSION=\"0.88\" -fPIC "-I/usr/lib/perl/5.14/CORE" Validate.c Validate.xs: In function ?get_type?: Validate.xs:208:5: error: duplicate case value Validate.xs:205:5: error: previously used here make[3]: *** [Validate.o] Erreur 1 make[3]: quittant le r?pertoire ? /usr/local/src/nagios-plugins-1.4.16/perlmods/Params-Validate-0.88 ? Can't run make install at ../tools/build_perl_modules line 85. make[2]: *** [install-exec-local] Erreur 2 make[2]: quittant le r?pertoire ? /usr/local/src/nagios-plugins-1.4.16/perlmods ? make[1]: *** [install-am] Erreur 2 make[1]: quittant le r?pertoire ? /usr/local/src/nagios-plugins-1.4.16/perlmods ? make: *** [install-recursive] Erreur 1 Could you tell me what's happening ? Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From waja at cyconet.org Fri Jul 26 17:08:51 2013 From: waja at cyconet.org (Jan Wagner) Date: Fri, 26 Jul 2013 17:08:51 +0200 Subject: [Nagiosplug-devel] Bug -> nagios-plugins In-Reply-To: References: Message-ID: <51F29103.6010106@cyconet.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 19.07.2013 17:04, schrieb OUISLY C?dric: > I am on debian 7 I have set up nagios without issue Trying to set > up the nagios-plugins-1.4.16.tar.gz just a short uqestion, why don't you install the nagios-plguins package provided by Debian. This is also a 1.4.16, but mit some additional bugfixes. Cheers, Jan. - -- Never write mail to , you have been warned! - -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++ - ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFR8pEC9u6Dud+QFyQRAjfHAKDnuy3ystjfyFl5LrztEJwAVr+VWQCfbx1z fdm2e7pe673eEhWBzcjc87A= =X71Z -----END PGP SIGNATURE----- From feytol972 at gmail.com Fri Jul 26 18:57:11 2013 From: feytol972 at gmail.com (=?ISO-8859-1?Q?OUISLY_C=E9dric?=) Date: Fri, 26 Jul 2013 18:57:11 +0200 Subject: [Nagiosplug-devel] Bug -> nagios-plugins In-Reply-To: <51F29103.6010106@cyconet.org> References: <51F29103.6010106@cyconet.org> Message-ID: In fact, I don't if in doing this, i am able to configure options like " --enable-perl-modules" or for nagios"--enable-event-broker --enable-nanosleep\ --enable-embedded-perl --with-perlcache" 2013/7/26 Jan Wagner > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Am 19.07.2013 17:04, schrieb OUISLY C?dric: > > I am on debian 7 I have set up nagios without issue Trying to set > > up the nagios-plugins-1.4.16.tar.gz > > just a short uqestion, why don't you install the nagios-plguins > package provided by Debian. This is also a 1.4.16, but mit some > additional bugfixes. > > Cheers, Jan. > - -- > Never write mail to , you have been warned! > - -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- > PS PE Y++ > PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++ > - ------END GEEK CODE BLOCK------ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iD8DBQFR8pEC9u6Dud+QFyQRAjfHAKDnuy3ystjfyFl5LrztEJwAVr+VWQCfbx1z > fdm2e7pe673eEhWBzcjc87A= > =X71Z > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 87.varun at gmail.com Mon Jul 29 06:32:58 2013 From: 87.varun at gmail.com (Varun Munjal) Date: Mon, 29 Jul 2013 10:02:58 +0530 Subject: [Nagiosplug-devel] Notifications options switch. Message-ID: Hi There, Could you please help me with issues on using ?s? switch in notifications options in nagiosQL. Its suppose to throw an email alert when a host enters downtime and when it exit from downtime however when I enable it for any host, it send the same email alert 2-3 times a day about downtime start. I am using version Nagios? Core? 3.2.3. Thanks, ------------------------------ *Varun Munjal | System Administrator | * *Phone : +91 120 4016300 | Mobile +91 9910333281| Email: varun.munjal at exponential.com* * * -------------- next part -------------- An HTML attachment was scrubbed... URL: