0

I'm running snmptt as a SNMP trap handler for snmptrapd, with the aim being to write to a trap file that can be read and processed by Zabbix.

I have set up snmptt to run as the zabbix user by changing the init script.

# grep daemon /etc/init.d/snmptt
# description: SNMP Trap Translator daemon
# Short-Description: SNMP Trap Translator daemon
OPTIONS="--daemon"
        daemon --user=zabbix /usr/sbin/snmptt $OPTIONS

snmpttt is running as expected as the zabbix user, the same user which is running the Zabbix server.

# ps -ef | grep snmp
root      3796     1  0 Jun19 ?        00:13:04 /usr/sbin/snmpd -LS0-6d -Lf /dev/null -p /var/run/snmpd.pid
zabbix    4444     1  0 15:00 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon
zabbix    4445  4444  0 15:00 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon
root      9300 29899  0 15:25 pts/2    00:00:00 grep snmp
zabbix   16576 16511  0 Aug16 ?        00:00:11 /path/to/sbin/zabbix_server: snmp trapper [processed data in 0.000007 sec, idle 1 sec]
root     16600     1  0 Aug16 ?        00:00:07 /usr/sbin/snmptrapd -A -Lf /var/log/snmptrapd.log -D -p /var/run/snmptrapd.pid

The log file to send traps caught is /var/tmp/zabbixtest/zabbix_traps.tmp

# egrep "^(log_file|pid)" /etc/snmp/snmptt.ini
pid_file = /var/run/snmptt/snmptt.pid
log_file=/var/tmp/zabbixtest/zabbix_traps.tmp

However, the trap log file is being written to, and owned by the root user, not as the zabbix user as expected. Moreover, the permissions on the file are 0640, meaning that the zabbix user running the server is not able to read the file.

# service snmptt stop
Stopping snmptt:                                           [  OK  ]
# rm /var/tmp/zabbixtest/zabbix_traps.tmp
rm: remove regular file `/var/tmp/zabbixtest/zabbix_traps.tmp'? y
# ls -lia /var/tmp/zabbixtest/zabbix_traps.tmp
ls: cannot access /var/tmp/zabbixtest/zabbix_traps.tmp: No such file or directory
# ls -lia /var/tmp/zabbixtest/
total 24
263224 drwxrwxr-x 2 root zabbix 4096 Aug 17 15:32 .
262145 drwxrwxrwt 7 root root   4096 Aug 17 14:53 ..
# service snmptt start
Starting snmptt: PID file: /var/run/snmptt/snmptt.pid
                                                           [  OK  ]
# ps -ef | grep snmptt
zabbix    9944     1  0 15:32 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon
zabbix    9945  9944  0 15:32 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon
root      9981 29899  0 15:32 pts/2    00:00:00 grep snmptt
# ps -ef | grep snmp
root      3796     1  0 Jun19 ?        00:13:04 /usr/sbin/snmpd -LS0-6d -Lf /dev/null -p /var/run/snmpd.pid
zabbix    9944     1  0 15:32 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon
zabbix    9945  9944  0 15:32 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon
root      9986 29899  0 15:32 pts/2    00:00:00 grep snmp
zabbix   16576 16511  0 Aug16 ?        00:00:11 /path/to/sbin/zabbix_server: snmp trapper [processed data in 0.000079 sec, idle 1 sec]
root     16600     1  0 Aug16 ?        00:00:07 /usr/sbin/snmptrapd -A -Lf /var/log/snmptrapd.log -D -p /var/run/snmptrapd.pid
# ls -lia /var/tmp/zabbixtest/zabbix_traps.tmp
262265 -rw-r----- 1 root root 122 Aug 17 15:32 /var/tmp/zabbixtest/zabbix_traps.tmp

Note the file permissions and ownership of /var/tmp/zabbixtest/zabbix_traps.tmp.

Accordingly, the zabbix user is unable to read the file and is hence unable to process it.

I can fix by manually modifying the mode of the trap file /var/tmp/zabbixtest/zabbix_traps.tmp to 0644, for example, but I am hoping there is a better way, e.g. via a configuration file, since the file location will most likely change. (There are some blog sites recommending to change the mode to 0777, obviously that is not the correct solution).

I guess it is due to the snmptrapd configuration, running as root, but not sure the best way to fix this.

My questions:

Why is the trap log file being written to as the root user with 0640 permissions, instead of as zabbix user running snmptt?

How can/should I configure snmptt and/or snmptrapd to have the trap file be owned and readable by the zabbix user instead of root user.

Other relevant info:

snmptrapd config file:

# grep -v '^#' /etc/snmp/snmptrapd.conf
disableAuthorization yes

traphandle default /usr/sbin/snmptthandler

Running RHEL 6.6

  • Cannot spot anything obvious - are you sure the file has not been created earlier while running snmptt in standalone mode? – Richlv Aug 17 '17 at 11:13
0

Found a solution at least after Richlv's comment about the file being created in standalone mode.

I made a few changes and got a working solution at least.

I think I had not restarted snmptrapd after changing snmptrapd.conf to read traphandle default /usr/sbin/snmptthandler instead of traphandle default /usr/sbin/snmptt.

Why written as root

A new instance of snmptt was being called by snmptrapd, which was running as root and must be to bind to snmp port 162. Therefore the files written by snmptt were owned by root also.

The permissions however, remains a mystery to me. I cannot tell where the 0640 permissions are coming from.

Main changes believed to have fixed the issue

  1. Restart snmptrapd (service snmptrapd restart), which caused re-read of snmptrapd.conf, to ensure that snmptthandler is used for processing traps instead of snmptt , which had previously been written in the config file.

This does not fix entire issue, however, since now snmptthandler writes traps to the spool directory /var/spool/snmptt, which is subsequently read by snmptt daemon process:

# grep spool_directory /etc/snmp/snmptt.ini
spool_directory = /var/spool/snmptt/

# grep -A5 SPOOL /usr/sbin/snmptthandler
...
while (defined(my $line = <>))
{
        print SPOOL $line;

        if ($DEBUGGING >= 1)
        {
                # Print out item passed from snmptrapd
                print $line."\n";
        }

The spooled files will be owned by root, with the same permissions 0640 as was issue with log file from snmptt in standalone mode. That means the snmptt daemon process will still not be able to read and process them after snmptthandler is finished. (In the log file /var/log/snmptt/snmptt.debug, there will be a permissions denied error when trying to read the spool file.)

So, the next step:

Set ownership of the spool directory to be the snmptt daemon user, and use the set-gid on the spool directory, causing the new files written to be owned by, and readable by, the user running snmptt.

chown zabbix:zabbix /var/spool/smptt
chmod g+s /var/spool/smptt
#ls -lia /var/spool/snmptt/
total 8
209 drwxrwsr-x  2 zabbix zabbix 4096 Aug 18 11:40 .
#ps -ef | grep snmptt
zabbix    8787     1  0 12:44 ?        00:00:00 /usr/bin/perl /usr/sbin/snmptt --daemon

Following that, the snmptt daemon can read the spooled files, and will write the files into the expected log directory /var/tmp/zabbixtest/zabbix_traps.tmp as the zabbix user, not as root.

### After a trap is received 
# ls -lia /var/tmp/zabbixtest/snmptt.log
524605 -rw-rw-r--  1 zabbix zabbix   646 Aug 18 13:16 snmptt.log

The umask for the log file is from the snmptt script:

$ grep -i umask /usr/sbin/snmptt
#umask 0;
umask 002;
  #umask 0;
  umask 002;

Other changes, good practice but not believe to have directly impacted the result

  1. Changed snmptt.ini to read mode=daemon instead of mode=standalone. (Not clear what effect this had, if any)
  2. Change /etc/snmp/snmptt.ini to read daemon_uid= (blank) instead of daemon_uid=zabbix (this is recommended in snmp docs, and prevents the double snmptt processes by the same user.

So, there is a way to fix it. Not sure if it is the best way. Best way might include changing snmptthandler to use the user/umask defined in configuration file.

This doesn't answer full question (0640 permissions still not clear) Comments or assistance welcome for that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.