Logrotate liest keine symbolverknüpften Konfigurationsdateien mehr, da sie nicht im Besitz des Root-Verzeichnisses sind

3741
phantomwhale

Wir aktualisieren derzeit von Ubuntu 12.04 LTS auf 14.04 LTS auf unseren Ruby on Rail-Anwendungsservern und haben festgestellt, dass die Protokolldateien nicht mehr rotieren.

Auf beiden Maschinen haben wir eine Datei, /var/app-name/config/logrotatedie unserem Unix-Benutzer gehört deployerund eine gültige Logrotate-Datei wie folgt enthält:

/var/app-name/log/*.log { daily rotate 365 delaycompress compress dateext dateformat -%Y%m%d missingok copytruncate }

Dies wird dann als symbolisch in das /etc/logrotate.d/Verzeichnis verlinktapp-name

Auf unserem Ubuntu 12.04 Server haben wir die logrotate 3.7.8, die einwandfrei läuft. Es geht in das var/app-name/log/Verzeichnis und dreht alle Protokolldateien

Auf Ubuntu 14.04 Server haben wir jedoch logrotate 3.8.7, wodurch die Logfiles für unsere Anwendung nicht gedreht werden.

Beim Debuggen über sudo logrotate -d -f /etc/logrotate/.confbekomme ich folgende Ausgabe:

Ignoring /etc/logrotate.d/app-name because the file owner is wrong (should be root).

Bei der Verfolgung im Code scheint diese Änderung für den 3.8.x-Release-Stream hinzugefügt worden zu sein: https://github.com/demands/logrotate/commit/b8ce386a969c60e5c8ee78023c24a1ba0aab1526

Wenn ich den Besitzer der Datei, zu der ein Symlink erstellt wurde, /var/app-name/config/logrotatein rootdann ändere, funktioniert sie wieder. Da diese Datei jedoch Teil meiner Anwendung ist und mit dem Capistrano-Implementierungs-Framework erstellt wurde, das wir in diesem Zustand verwenden, muss ich die Besitzrechte nicht ändern, wenn sie einwandfrei funktionierte.

Werden Symlink-Konfigurationsdateien von logrotate empfohlen / unterstützt?

Und wenn ja, sollte es ablehnen, meine (im Besitz befindliche deployer) Datei, die in das /etc/logrotate.dVerzeichnis eingebunden ist, als Fehler zu verwenden?

Oder gibt es einen anderen empfohlenen Ansatz für die anwendungsspezifische Protokollrotation?

(auch unter Unix StackExchange gefragt )

14
Gute Frage! Wie ich sehe, gab es [etwas Diskussion] (https://fedorahosted.org/logrotate/ticket/36) später über das Überprüfen gegen den Benutzernamen "root" anstelle von uid == 0, aber auch das löste die Frage nicht aus warum Root-Besitz erforderlich ist. agtoever vor 10 Jahren 0

2 Antworten auf die Frage

5
pelle

Das Problem ist, dass eine logrotate-Konfigurationsdatei jeden Befehl als root ausführen kann (unter Verwendung von Zeilengruppen vorrotiert / postrotiert). Daher würden Sie Ihrem deployerBenutzer tatsächlich Root-Rechte gewähren, indem Sie ihm Schreibzugriff auf Dateien in gewähren /etc/logrotate.d/. Also nein, es ist kein Fehler.

Wenn Sie Ihrem Deployer-Benutzer vertrauen, könnten Sie das Problem möglicherweise lösen, indem Sie ihm Sudo-Rechte zum Kopieren von Dateien erteilen /etc/logrotate.d/. Vorausgesetzt natürlich, dass der Deployer-Benutzer nicht derselbe Benutzer ist, als den die Web-App ausgeführt wird.

Es war immer unser Ansatz, die Verknüpfung von Verzeichnissen außerhalb der Anwendung in Anwendungsdateien zu bevorzugen, sodass bei jeder Implementierung nicht nur die neue Anwendung ausgegeben wird, sondern auch Änderungen an der Konfigurationsdatei. Selbst wenn dem Implementierer die Rechte zum Bereitstellen von Code außerhalb des Anwendungsverzeichnisses eingeräumt werden, verstößt dies gegen diesen Ansatz. Aber auch die Tatsache, dass eine Anwendungsdatei als root-Besitz nach dem Deployment bezeichnet werden muss, wirkt sich wie eine schlechte Sache (TM) aus. Vielleicht kann der ursprüngliche Ansatz daher mit logrotate 3.8.0+ nicht mehr gut funktionieren phantomwhale vor 10 Jahren 0
@phantomwhale Ihr ursprünglicher Ansatz gewährte Ihrem Deployer-Benutzer implizit alle Root-Rechte. Das ist in logrotate 3.8 nicht neu. Wenn Sie die Rechte des Bereitstellers einschränken möchten, während Sie ihm dennoch erlauben, die Konfiguration zu aktualisieren, müssen Sie meiner Meinung nach etwas anderes als logrotate verwenden. pelle vor 10 Jahren 2
2
dayer4b

Mir ist klar, dass ich zu spät zur Party komme, aber ich hatte ein ähnliches Problem und dachte, ich würde meine Lösung teilen.

Meine Probleme begannen, als logrotateich die von mir geschriebene Konfiguration nicht lesen konnte. Ich wollte keine neuen Konfigurationen in einem Ordner von root bereitstellen, da der Bereitstellungsbenutzer keinen Root-Zugriff auf irgendetwas haben soll .

Zuerst habe ich versucht, logrotateals Implementierungsbenutzer auszuführen, aber er beschwerte sich über den Zugriff auf die Statusdatei unter /var/lib/logrotate/state. Dann habe ich die Manpage gelesen. Sie können die Statusdatei angeben, die logrotateverwendet wird! Es schien mir also eine bessere Lösung zu sein, einen täglichen Cron einzurichten, der logrotateals Deploy-Benutzer mit einer benutzerdefinierten Statusdatei ausgeführt werden sollte. Auf diese Weise ist kein Root-Zugriff für den Implementierungsbenutzer oder die Anwendung erforderlich.

So legen Sie die Statusdatei fest:

logrotate --state /path/to/status /path/to/custom_logrotate.conf

Jetzt können Sie logrotate als beliebiger Benutzer und Konfigurationseigner ausführen, den Sie mögen!

Verwandte Probleme