NGINX-Dienstrotation verwendet keine neuen Protokolldateien

NGINX-Dienstrotation verwendet keine neuen Protokolldateien

Ich habe Probleme mit allen Befehlen, die nginx anweisen, neue Protokolldateien zu verwenden. Ich verwende Ubuntu 18.04, nginx/1.14.0, logrotate 3.11.0

Wenn ich neue access.logoder error.logDateien in /var/log/nginx erstelle, entweder manuell oder über logrotate, werden sie nicht verwendet und stattdessen nutzt der Dienst die alten Protokolldateien (die ich access.log.1für diesen Test umbenannt habe, um zu simulieren, was logrotate macht).

Ich habe die folgenden Befehle (getrennt) ausprobiert. Keiner von ihnen erzeugt eine Fehlermeldung, sie erzeugen alle die erwartete Ausgabe. Aber nginx weigert sich, die Verwendung der alten Protokolle einzustellen.

service nginx rotate

invoke-rc.d nginx rotate

kill -USR1 `cat /var/run/nginx.pid`

Ich habe auch überprüft, ob sich die obige .pidDatei am richtigen Ort befindet.

Die einzige Möglichkeit, wie ich die Protokollrotation zum Laufen bringen konnte, ist über einen service nginx reload, der die Aufgabe erledigt, aber auch Konfigurationsdateien neu lädt. Ich weiß, dass es bei einem Neuladen keine Ausfallzeiten gibt, aber ich würde es trotzdem vorziehen, so wenig wie möglich neu zu laden, weshalb ich es zum service nginx rotateLaufen bringen möchte.

Ich bin fast sicher, dass es an Berechtigungsproblemen in liegt /var/log. Vor Kurzem haben wir einen Cronjob eingerichtet, um sicherzustellen, dass die Protokolldateien sichere Berechtigungen haben. Dies war für ein Audit, da das Pentest-Unternehmen verschiedene Sicherheitsmaßnahmen in Bezug auf die Protokollierung vorgeschlagen hatte. Der von uns eingerichtete Cronjob wird beim Booten ausgeführt:

#!/bin/bash
  
setfacl -Rm u::rwx,g::r--,o::--- /var/log
find /var/log -type f -exec chmod g-wx,o-rwx "{}" + -o -type d -exec chmod g-w,o-rwx "{}" +
chmod g+wx /var/log

chown -R www-data:adm /var/log/nginx

Hier sind die Berechtigungen der relevanten Verzeichnisse und Dateien nach dem Ausführen des Cronjobs:

Das Verzeichnis /var/log selbst:

drwxrwx--- 14 root syslog  4096 Aug 27 10:01 log

Das Verzeichnis /var/log/nginx selbst:

drwxr-----  2 www-data  adm               4096 Aug 24 02:25  nginx

Und der Inhalt von /var/log/nginx (wir verwenden benutzerdefinierte benannte Protokolle in unserer Nginx-Konfiguration):

-rwxr----- 1 www-data adm     0 Aug 24 02:24 access.log
-rwxr----- 1 www-data adm   108 Aug 24 02:24 error.log
-rwxr----- 1 www-data adm 49317 Aug 27 10:11 x3nr0s.access.log
-rwxr----- 1 www-data adm   798 Aug 27 10:02 x3nr0s.error.log

Wenn wir logrotate --force /etc/logrotate.d/nginx -v(ausführlich) oder sogar manuell touchneue Dateien erstellen, werden diese mit 640 Berechtigungen erstellt (gemäß der Konfigurationsdatei von logrotate). Soweit ich gelesen habe, reichen 640:

-rwxr----- 1 www-data adm     0 Aug 24 02:24 access.log
-rw-r----- 1 www-data adm     0 Aug 27 10:13 error.log
-rwxr----- 1 www-data adm  1972 Aug 27 10:13 error.log.1
-rw-r----- 1 www-data adm     0 Aug 27 10:13 x3nr0s.access.log
-rwxr----- 1 www-data adm 51521 Aug 27 10:13 x3nr0s.access.log.1
-rw-r----- 1 www-data adm     0 Aug 27 10:13 x3nr0s.error.log
-rwxr----- 1 www-data adm   798 Aug 27 10:02 x3nr0s.error.log.1

Wie Sie sehen, bleiben die neuen Dateien leer und die Protokollierung wird in der alten Datei fortgesetzt. Ich habe auch die ausführliche Logrotate-Ausgabe überprüft und im Hinblick auf den Postrotate-Abschnitt scheint alles in Ordnung zu sein. (Der ausgeführt wird invoke-rc.d nginx rotate. Wie ich bereits erwähnt habe, scheint dieser Befehl nichts zu rotieren...)

Als letzten Test habe ich versucht, dem Benutzer Ausführungsberechtigungen für die neuen Dateien zu erteilen, und habe einen ausgeführt service nginx rotate. Nginx verwendet immer noch die alten Dateien. In einigen anderen Antworten wird erwähnt, dass geprüft werden soll, ob der Speicherplatz voll ist. Dies ist nicht der Fall.

Würde mich über Hilfe freuen! Danke.

Weitere Informationen

Hier ist meine /etc/logrotate.d/nginx-Konfiguration:

/var/log/nginx/*.log {
        daily
        missingok
        rotate 14
        compress
        delaycompress
        notifempty
        create 0640 www-data adm
        sharedscripts
        prerotate
                if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
                        run-parts /etc/logrotate.d/httpd-prerotate; \
                fi \
        endscript
        postrotate
                invoke-rc.d nginx rotate >/dev/null 2>&1
        endscript
}

Wie oben erwähnt, kann ich logrotate und nginx nur dazu bringen, mit den neuen Protokolldateien ordnungsgemäß zu funktionieren, indem ich den postrotateAbschnitt durch ersetze service nginx reload.

Hier ist die Ausgabe von ps -ef | grep nginx:

root      1367     1  0 10:45 ?        00:00:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data  1368  1367  0 10:45 ?        00:00:00 nginx: worker process
www-data  1369  1367  0 10:45 ?        00:00:00 nginx: worker process
www-data  1370  1367  0 10:45 ?        00:00:00 nginx: worker process
www-data  1371  1367  0 10:45 ?        00:00:00 nginx: worker process
root     15247 14835  0 11:19 pts/0    00:00:00 grep --color=auto nginx

Hier ist das getfaclin /var/log:

# file: var/log
# owner: root
# group: syslog
user::rwx
group::rwx
other::---

Und hier ist das getfaclzu /var/log/nginx:

# file: var/log/nginx
# owner: www-data
# group: adm
user::rwx
group::r--
other::---

Antwort1

Dies /etc/logrotate.d/nginxist die Standardeinstellung und sollte funktionieren.

Ändern Sie jedoch den postrotate.dBefehl, um nginx zu zwingen, seine Konfiguration neu zu laden (und die neue Protokolldatei zu verwenden).

  service nginx reload >/dev/null 2>&1

könnte eine schnelle Lösung sein.

Wenn ein normalerweise funktionierender Dienst eine Datei nicht erstellen/öffnen/umbenennen/ändern kann, sind häufig Zugriffsrechte betroffen.

Hier wurden die Zugriffe (aus Sicherheitsgründen) geändert, aber die Standard-ACL sollte auch funktionieren/sicher sein, ohne dass sie einbezogen wird, setfaclwas zwar leistungsstark ist, aber bei Verwendung der Standardoptionen nicht sofort angezeigt wird ls.

Die Standard-ACL ist für/var/log

drwxrwxr-x 18 root syslog 4096 Aug 27 07:25 /var/log/

und der Standard-nginx ist (eigentlich)

drwxr-x--- 2 www-data adm 4096 Aug 27 07:25 /var/log/nginx/

nginxist ok, /var/logkönnte etwas enger sein

drwxrwx--x 18 root syslog 4096 Aug 27 07:25 /var/log/

die othersden Zugriff auf das Verzeichnis (und darunter) ermöglichen, aber die Auflistung des Inhalts verhindern.

Was die facl betrifft, getfacllistet der Befehl die tatsächlich hinzugefügten ACLs für /var/logund /var/log/nginxauf /var/log/nginx/*, was auf ein Problem hinweisen könnte.

Machen Sie übrigens auch eine

dpkg-statoverride --list

um zu prüfen, welche ACLs das Installationsprogramm nach einem Update oder einer Installation setzt, und ggf. eine Zeile zu ändern oder hinzuzufügen (man dpkg-statoverride)

verwandte Informationen