Coverity 66480 - Potential array index out of bounds, since result was not verified to be positive prior to using as an index for state[]. Simply reording the if statement should resolve the issue. - SR
Coverity 66514 - Possible leakage and overflow with addr in redirect functionality. Not confirmed as null terminated, and externally gathered. Restrict string comparisons and duplications by size. - SR
Coverity 66524 - req.data is not neccessarily null terminated but still feed to printf statements. This both does that, and verifies the struct more so than before. - SR
Recv into buffer is not properly null terminated prior to strstr and possible other string functions expecting a null termination. Simply take bytes received and use as an index to append \0 after. We are creating buffer[] with size of MAX_INPUT_BUFFER and recv with MAX_INPUT_BUFFER-1 so this should never overflow.
Coverity 66531 - ereg.buffer can be printed without being initialized if do_include and do_exclude are null and critical is an invalid regex. While minor this may leak memory and cause undefined behavior.
when returning syscontact. So make them optional since we want to test
check_snmp and not the snmpd.
Signed-off-by: Sven Nierlein <Sven.Nierlein@consol.de>
The SNMPv3 noAuthNoPriv security level, somewhat unintuitively, requires
a security name to be passed along together with the request. Check_snmp
previously did not do this, causing snmpget to throw an error:
"External command error: No log handling enabled - turning on stderr
logging
snmpget: No securityName specified"
This patch fixes the issue by always providing the security name when
noAuthNoPriv is specified.
See also:
https:://bugs.op5.com/view.php?id=8385.
Signed-off-by: Anton Lofgren <alofgren@op5.com>
thats because check_procs verifys there is a user for a
given uid filter. So even we use sample data for this
test, we still need a real user.
Signed-off-by: Sven Nierlein <Sven.Nierlein@consol.de>
check_snmp becomes capable of evaluating negative values properly,
but it might be returning CRITICALs where it used to return OK and was ignored,
if a negative value turns out to actually be a valid value.
If negative values are valid, this can be worked around,
by adding "~:" to the warning/critical threshold : 100 -> ~:100
When a timeout value is specified with the -t option, dig will sometimes
timeout before the timer is actually reached.
The problem occurs because the check_dig plugin does not pass the specified
timeout value to dig, leaving dig to timeout with it's default value which
seems to be around 10-15seconds.
To reproduce:
time ./check_dig -H 127.0.0.2 -l www.google.com -t 30
It will not run for 30secs, which is the expected behaviour.
The following will work, because the timeout is less than the default dig
timeout, so the plugin cancels the dig command:
time ./check_dig -H 127.0.0.2 -l www.google.com -t 2
This fix passes the timeout value to dig, and sets the number of retries which tends to vary from system to system by default.
Closes#1168
Check_swap used to allow no swap when thresholds were only specified in
percent. This is no longer the case and the state now must be specified
explicitly. The default is to always return CRITICAL when the swap is
absent regardless of thresholds.
