The log lines you list do not indicate that the command was denied so I', not sure I understand the problem you are having.

If you are running sudo via a web server, there will be no tty present, so "TTY=unknown" in the log is correct and not an error.

(In reply to comment #1)
> The log lines you list do not indicate that the command was denied so
> I', not sure I understand the problem you are having.
> 
> If you are running sudo via a web server, there will be no tty present,
> so "TTY=unknown" in the log is correct and not an error.

hm, ok, thanks for the info, let me explain what's going on

check_raidstat.pl executes following commands and processes the output:
/opt/MegaRAID/MegaCli/MegaCli -adpCount
/opt/MegaRAID/MegaCli/MegaCli -LdGetNum -a0
/opt/MegaRAID/MegaCli/MegaCli -LdInfo -L0 -a0
/opt/MegaRAID/MegaCli/MegaCli -LdInfo -L1 -a0
/opt/MegaRAID/MegaCli/MegaCli -PdList -a0

- the same plugin in the same version works well on CentOS 5 boxes with sudo 1.7.x (requiretty line commented out); megacli version is corresponding as well (2.00.15)

- on 32 Bit boxes with CentOS 4 and sudo 1.6.x I get a bit different output regarding the tty assignment inside log file compared to centos 5 running sudo 1.7.x;

working one (centos 5 & sudo 1.7.x):
sudo:     root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/opt/MegaRAID/MegaCli/MegaCli -adpCount
sudo:     root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/opt/MegaRAID/MegaCli/MegaCli -LdGetNum -a0
sudo:     root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/opt/MegaRAID/MegaCli/MegaCli -LdInfo -L0 -a0
sudo:     root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/opt/MegaRAID/MegaCli/MegaCli -LdInfo -L1 -a0
sudo:     root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/opt/MegaRAID/MegaCli/MegaCli -PdList -a0

buggy / missconfigured one (centos 4 running sudo 1.6.x):
sudo:   nagios : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/opt/MegaRAID/MegaCli/MegaCli -adpCount

- shouldn't be there a pseudo terminal available instead of 'unknown' like shows the logs from centos 5 server(s) ?

- there is no webserver installed on this servers, this is handled by nrpe which works fine for all other installed plugins:
tcp        0      0 0.0.0.0:5666                0.0.0.0:*                   LISTEN      22605/nrpe  

- nrpe reloaded in debug mode, which shows:
xinetd[14442]: START: nrpe pid=16979 from=xxxxxxxx
nrpe[16979]: Added command[check_disk]=/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$ 
nrpe[16979]: Added command[check_raidstat]=/usr/lib/nagios/plugins/check_raidstat.pl 
 nrpe[16979]: INFO: SSL/TLS initialized. All network traffic will be encrypted.
nrpe[16979]: Handling the connection...
nrpe[16979]: Host is asking for command 'check_raidstat' to be run...
nrpe[16979]: Running command: /usr/lib/nagios/plugins/check_raidstat.pl
sudo:   nagios : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/opt/MegaRAID/MegaCli/MegaCli -adpCount
nrpe[16979]: Command completed with return code 0 and output: OK: Drives:0  
nrpe[16979]: Return Code: 0, Output: OK: Drives:0 
sshd[17021]: Connection closed by xxxxx

- there was only the first megacli command executed, log shows this ended with retval 0 and output was: OK: Drives:0

- executing check_raidstat.pl as root and as user nagios shows the same output (even if I su as nagios and execute raidstat plugin using sudo), which does not correspondent to debug messages from nrpe:
OK: 0:0:RAID-1:2 drives:931GB:Optimal 0:1:RAID-5:4 drives:2793GB:Optimal Drives:6

- nrpe debug log on a server running cOS 5 & sudo 1.7.x shows all 5 MegaCli commands were executed, the output fit's the the output from shell execution

It seems I'm going round in circles, for now it looks for me like that the plugin execution is not possible due to unknown tty, servers with newer sudo version deliver at least a pty which seems to be enough :)

If you could point me to the right direction that would be great, I've considered and checked against settings, logfiles etc in last few days and I don't see anything else which could case this state (nagios showing "CHECK_NRPE: Error receiving data from daemon." on the nagios monitoring screen - but this seems have nothing to do with the nrpe itself).

Thank you,

Adrian

The main difference in tty checking between sudo 1.6 and sudo 1.7 is that sudo 1.7 also checks to see if the stdandard error points to a tty whereas sudo 1.6 only checks the standard input and standard output.

That said, I would not expect a daemon run via xinetd to have access to a tty at all.  Typically a tty is only available during a login session.  You might check your CentOS 5 nagios setup to see if nrpe is running under xinetd or standalone on the CentOS 5 machines and, if xinetd, compare the xinetd.d files between the two systems.  If nrpe is running standalone on CentOS 5 and it doesn't redirect stdin, stdout, and stderr to /dev/null or elsewhere (as it really ought to) that might explain why a tty is available.

This doesn't seem like a sudo problem to me but you can try updating your sudo package on CentOS 4 to version 1.7.6p2 and see if that makes any difference.  You can find the official sudo RPM for CentOS 4 i386 at http://www.sudo.ws/sudo/dist/packages/Centos/4/sudo-1.7.6-3.el4.i386.rpm

If that doesn't solve your problem then at least you know it is not a sudo issue.

Sudo 1.6.x is no longer supported.