Я пробовал немного погуглить по этому поводу, но ничего не нашел, поэтому решил, что спрошу здесь. Вот моя текущая проблема:
Я использую сервер Ubuntu 18.04 в значительной степени. Цель сервера - запустить приложение Vision. Проблема, с которой я сталкиваюсь, заключается в том, что когда я проверяю journalctl для службы приложения Vision, PAM (Pluggable Authentication Module) и некоторые другие службы, связанные с операционной системой, чрезмерно регистрируются в приложении Vision, чего я бы предпочел не делать. Вот пример:
journalctl -u visionapp.service | less
вывод:
(some stuff omitted)
Jan 08 10:43:12 visionapp sudo[2483]: root : TTY=unknown ; PWD=/opt ; USER=root ; COMMAND=/sbin/iptables -F
Jan 08 10:43:12 visionapp sudo[2483]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 08 10:43:12 visionapp sudo[2483]: pam_unix(sudo:session): session closed for user root
Jan 08 10:43:12 visionapp sudo[2490]: root : TTY=unknown ; PWD=/opt ; USER=root ; COMMAND=/sbin/sysctl net.ipv4.conf.xxx999.forwarding=1
Jan 08 10:43:12 visionapp sudo[2490]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 08 10:43:12 visionapp VisionApp[2471]: net.ipv4.conf.xxx999.forwarding = 1
Jan 08 10:43:12 visionapp sudo[2490]: pam_unix(sudo:session): session closed for user root
Jan 08 10:43:12 visionapp sudo[2493]: root : TTY=unknown ; PWD=/opt ; USER=root ; COMMAND=/sbin/sysctl net.ipv4.conf.yyy888.forwarding=1
Jan 08 10:43:12 visionapp sudo[2493]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 08 10:43:13 visionapp VisionApp[2471]: net.ipv4.conf.yyy888.forwarding = 1
Jan 08 10:43:13 visionapp sudo[2493]: pam_unix(sudo:session): session closed for user root
Jan 08 10:43:13 visionapp VisionApp[2471]: route: sudo iptables -t nat -A PREROUTING -p tcp -d 88.88.88.63 --dport 77777 -j DNAT --to-destination 99.99.99.35:77777
Jan 08 10:43:13 visionapp sudo[2496]: root : TTY=unknown ; PWD=/opt ; USER=root ; COMMAND=/sbin/iptables -t nat -A PREROUTING -p tcp -d 88.88.88.63 --dport 77777 -j DNAT --to-destination 99.99.99.35:77777
Jan 08 10:43:13 visionapp sudo[2496]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 08 10:43:13 visionapp sudo[2496]: pam_unix(sudo:session): session closed for user root
Jan 08 10:43:13 visionapp VisionApp[2471]: route: sudo iptables -t nat -A PREROUTING -p tcp -d 88.88.88.63 --dport 5555 -j DNAT --to-destination 99.99.99.11:80
Jan 08 10:43:13 visionapp sudo[2499]: root : TTY=unknown ; PWD=/opt ; USER=root ; COMMAND=/sbin/iptables -t nat -A PREROUTING -p tcp -d 88.88.88.63 --dport 5555 -j DNAT --to-destination 99.99.99.11:80
Jan 08 10:43:13 visionapp sudo[2499]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 08 10:43:13 visionapp sudo[2499]: pam_unix(sudo:session): session closed for user root
Jan 08 10:43:13 visionapp VisionApp[2471]: route: sudo iptables -t nat -A PREROUTING -p tcp -d 88.88.88.63 --dport 6666 -j DNAT --to-destination 99.99.99.30:80
Jan 08 10:43:13 visionapp sudo[2502]: root : TTY=unknown ; PWD=/opt ; USER=root ; COMMAND=/sbin/iptables -t nat -A PREROUTING -p tcp -d 88.88.88.63 --dport 6666 -j DNAT --to-destination 99.99.99.30:80
Jan 08 10:43:13 visionapp sudo[2502]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 08 10:43:13 visionapp sudo[2502]: pam_unix(sudo:session): session closed for user root
Jan 08 10:43:13 visionapp VisionApp[2471]: route: sudo iptables -t nat -A PREROUTING -p udp -d 88.88.88.63 --dport 23456 -j DNAT --to-destination 99.99.99.30:23456
Jan 08 10:43:13 visionapp sudo[2505]: root : TTY=unknown ; PWD=/opt ; USER=root ; COMMAND=/sbin/iptables -t nat -A PREROUTING -p udp -d 88.88.88.63 --dport 23456 -j DNAT --to-destination 99.99.99.30:23456
Jan 08 10:43:13 visionapp sudo[2505]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 08 10:43:13 visionapp sudo[2505]: pam_unix(sudo:session): session closed for user root
Jan 08 10:43:13 visionapp VisionApp[2471]: route: sudo iptables -t nat -A PREROUTING -p tcp -d 88.88.88.63 --dport 28208 -j DNAT --to-destination 99.99.99.30:28208
Jan 08 10:43:13 visionapp sudo[2508]: root : TTY=unknown ; PWD=/opt ; USER=root ; COMMAND=/sbin/iptables -t nat -A PREROUTING -p tcp -d 88.88.88.63 --dport 28208 -j DNAT --to-destination 99.99.99.30:28208
Jan 08 10:43:13 visionapp sudo[2508]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 08 10:43:13 visionapp sudo[2508]: pam_unix(sudo:session): session closed for user root
Jan 08 10:43:13 visionapp VisionApp[2471]: route: sudo iptables -t nat -A PREROUTING -p tcp -d 88.88.88.63 --dport 2112 -j DNAT --to-destination 99.99.99.36:2112
Jan 08 10:43:13 visionapp sudo[2511]: root : TTY=unknown ; PWD=/opt ; USER=root ; COMMAND=/sbin/iptables -t nat -A PREROUTING -p tcp -d 88.88.88.63 --dport 2112 -j DNAT --to-destination 99.99.99.36:2112
Jan 08 10:43:13 visionapp sudo[2511]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 08 10:43:13 visionapp sudo[2511]: pam_unix(sudo:session): session closed for user root
Jan 08 10:43:13 visionapp VisionApp[2471]: Make Routable: sudo iptables -t nat -A POSTROUTING -j MASQUERADE
Jan 08 10:43:13 visionapp sudo[2514]: root : TTY=unknown ; PWD=/opt ; USER=root ; COMMAND=/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE
Jan 08 10:43:13 visionapp sudo[2514]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 08 10:43:13 visionapp sudo[2514]: pam_unix(sudo:session): session closed for user root
(some stuff omitted)
Я изменил некоторые имена и номера, чтобы защитить анонимность компании, но в остальном это реальный результат. Я бы предпочел иметь возможность каким-то образом это подавить.
После консультации с этим сообщением https://unix.stackexchange.com/questions/327301/how-to-stop-sudo-pam-messages-in-auth-log-for-a-specific-user-on-ubuntu-16-04 Я бы предпочел держаться подальше от файлов конфигурации PAM по трем причинам:
1) Я попробовал то, что предлагалось в публикации, но это не сработало, и приложение Vision вылетело.
2) Ошибка при редактировании журналов PAM может привести к блокировке корневого доступа.
3) Некоторые из вышеперечисленных сообщений не генерируются PAM.
Последний ответ в приведенном выше сообщении упоминает фильтрацию на уровне системного журнала. Я пытался прочитать об этом, но пока не смог добиться многого. Я, по крайней мере, смог определить, что критические файлы кажутся /etc/rsyslog.conf и файлы в /etc/rsyslog.d/.
вот мой /etc/rsyslog.conf/:
$ cat /etc/rsyslog.conf
# /etc/rsyslog.conf Configuration file for rsyslog.
#
# For more information see
# /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html
#
# Default logging rules can be found in /etc/rsyslog.d/50-default.conf
#################
#### MODULES ####
#################
module(load="imuxsock") # provides support for local system logging
#module(load="immark") # provides --MARK-- message capability
# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")
# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")
# provides kernel logging support and enable non-kernel klog messages
module(load="imklog" permitnonkernelfacility="on")
###########################
#### GLOBAL DIRECTIVES ####
###########################
#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
# Filter duplicated messages
$RepeatedMsgReduction on
#
# Set the default permissions for all log files.
#
$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$PrivDropToUser syslog
$PrivDropToGroup syslog
#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog
#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf
Есть 3 файла в rsyslog.d:
$ cd /etc/rsyslog.d
$ ls -l
-rw-r--r-- 1 root root 314 Aug 15 2017 20-ufw.conf
-rw-r--r-- 1 root root 255 Apr 27 2018 21-cloudinit.conf
-rw-r--r-- 1 root root 1124 Jan 30 2018 50-default.conf
У меня такое впечатление что 20-ufw.conf и 21-cloudinit.conf предназначены для некоторых других конкретных целей. Вот это 50-default.conf:
$ cat 50-default.conf
# Default rules for rsyslog.
#
# For more information see rsyslog.conf(5) and /etc/rsyslog.conf
#
# First some standard log files. Log by facility.
#
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
#daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
#lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
#user.* -/var/log/user.log
#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
#mail.info -/var/log/mail.info
#mail.warn -/var/log/mail.warn
mail.err /var/log/mail.err
#
# Some "catch-all" log files.
#
#*.=debug;\
# auth,authpriv.none;\
# news.none;mail.none -/var/log/debug
#*.=info;*.=notice;*.=warn;\
# auth,authpriv.none;\
# cron,daemon.none;\
# mail,news.none -/var/log/messages
#
# Emergencies are sent to everybody logged in.
#
*.emerg :omusrmsg:*
#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
#daemon,mail.*;\
# news.=crit;news.=err;news.=notice;\
# *.=debug;*.=info;\
# *.=notice;*.=warn /dev/tty8
Насколько мне известно, эти файлы предназначены для установки сервера Ubuntu 18.04.
Итак, вот мои вопросы на данный момент:
1) Должен ли я редактировать один из вышеуказанных файлов или создавать другой файл в /etc/rsyslog.d, пр. 20-visionapp.conf или похожие?
2) Есть ли способ изменить указанные выше файлы, чтобы условно не включать сообщения журнала для visionapp.service? т.е. если строка журнала содержит pam_unix(sudo:session) или root : TTY=unknown не включать его? Если кто-то может предложить такую линию, пожалуйста, поясните, будет ли она применима ко всем systemd услуги или только visionapp.service в частности, а также применимо ли это ко всем пользователям или к конкретному пользователю? Если бы были доступны варианты, из которых можно было бы выбрать оба, это было бы еще лучше.
-- Обновить --
После большего количества поисков в Google я сделал следующее:
cd /etc/rsyslog.d
sudo nano 20-visionapp.conf
в nano Я вошел:
:msg,contains,"pam_unix" /var/log/PAM.log
& stop
затем из командной строки снова я сделал:
service rsyslog restart
Затем запустил и снова остановил приложение Vision. Я надеялся, что любое сообщение, содержащее pam_unix теперь перейду к файлу /var/log/PAM.log, но когда я побежал journalctl -u visionapp.service | less в pam_unix сообщения все еще были там.
Я думаю, что я здесь, по крайней мере, близко. Что я делаю не так? Какие-либо предложения?
- Обновление2 -
На основе этой документации https://www.rsyslog.com/discarding-unwanted-messages/ для /etc/rsyslog.d/20-visionapp.conf, Я также пробовал:
:msg,contains,"pam_unix" ~
и
:msg, contains, "pam_unix" ~
Ни одна из этих работ не работает, т.е. journalctl -u visionapp.service | less все еще показывает pam_unix Сообщения.
Я также должен упомянуть, что этот пост https://unix.stackexchange.com/questions/133898/why-does-rsyslogd-not-honor-the-following-lines-in-rsyslog-d описывает очень похожую проблему и пока не имеет принятого ответа.
- Обновление3 -
Если я сделаю это:
sudo nano /etc/rsyslog.d/19-visionapp.conf
затем введите:
:msg, contains, "pam_unix" /var/log/visionapp-other.log
& stop
Тогда все сообщения с pam_unix войти в оба /var/log/visionapp-other.log и чтобы journalctl -u visionapp.service | less. Кажется из этого поста https://unix.stackexchange.com/questions/8737/rsyslog-is-not-discarding-message-as-it-should это была известная ошибка в прошлом. Есть ли у кого-нибудь обходной путь или дополнительная информация по этому поводу?
- Обновление4 -
После дополнительных поисков в Google я убедился, что шаги, которые я упомянул в предыдущем обновлении, верны и есть ли ошибка в rsyslog или интеграция rsyslog на сервер Ubuntu 18.04. На данный момент я выбрал обходной путь - создать сценарий в домашнем каталоге, содержащий:
journalctl -u visionapp.service | grep -v "pam_unix" | grep -v "TTY=unknown" | less
Это экранирует сообщения с pam_unix и TTY=unknown что я бы предпочел не видеть. Это явно не лучшее решение, и я разочарован в rsyslog и Ubuntu за то, что они не предоставляют лучшего способа изменить вывод журнала systemd.