Создание псевдонима для команды find в Linux

Решение найдено по крайней мере после комментария Richlv о том, что файл создается в автономном режиме.

Я внес несколько изменений и, по крайней мере, получил работающее решение.

Думаю, я не перезапустил snmptrapdпосле изменения snmptrapd.confна traphandle default /usr/sbin/snmptthandlerвместо traphandle default /usr/sbin/snmptt.

Почему написано как корень

Новый экземпляр snmpttвызывался snmptrapd, который работал от имени пользователя root и должен быть привязан к порту 162 snmp. Следовательно, файлы, написанные snmptt, также принадлежали пользователю root.

Однако разрешения остаются для меня загадкой. Я не могу сказать, откуда берутся разрешения 0640.

Основные изменения, которые, как считается, решили проблему

1. Перезапустите snmptrapd(service snmptrapd restart), что вызвало повторное -чтение snmptrapd.conf, чтобы убедиться, что snmptthandlerиспользуется для обработки прерываний вместо snmptt, который ранее был записан в файле конфигурации.

Однако это не устраняет проблему полностью, поскольку теперь snmptthandlerловушки записываются в каталог буфера /var/spool/snmptt, который затем считывается snmpttпроцессом демона:

# 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";
        }

Буферные файлы будут принадлежать rootс теми же разрешениями 0640, что и проблема с файлом журнала от snmpttв автономном режиме.Это означает, что процесс демона snmpttпо-прежнему не сможет читать и обрабатывать их после завершения snmptthandler. (В файле журнала /var/log/snmptt/snmptt.debugбудет ошибка permissions deniedпри попытке прочитать файл спула.)

Итак, следующий шаг:

Назначьте владельцем каталога спулинга пользователя демона snmpttи используйте set -gid для каталога спула, в результате чего новые файлы, записываемые и доступные для чтения,, пользователь, работающий 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

После этого демон snmpttможет читать буферные файлы и записывать файлы в ожидаемый каталог журнала /var/tmp/zabbixtest/zabbix_traps.tmpкак пользователь zabbix, а не как 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

Маска umask для файла журнала взята из сценария snmptt:

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

Прочие изменения, рекомендуемая практика, но не повлиявшие напрямую на результат

1. Изменено snmptt.iniна mode=daemonвместо mode=standalone. (Неясно, какой эффект это оказало, если таковой был)
2. Измените /etc/snmp/snmptt.iniна чтениеdaemon_uid=(пустым )вместо daemon_uid=zabbix(. Это рекомендуется в snmp docs и предотвращает двойные процессы snmpttодним и тем же пользователем.

Итак, есть способ это исправить. Не уверен, что это лучший способ. Лучший способ может включать изменение snmptthandlerдля использования пользователя/маски, определенных в файле конфигурации.

Это не дает полного ответа на вопрос. (0640 разрешения еще не ясны )Приветствуются комментарии или помощь.