Mal wieder ein Problem mit logrotate und AWStats

Haben Sie einen Bug entdeckt? Teilen Sie es uns mit.
Post Reply
tab-kh
Posts: 450
Joined: Thu 22. Apr 2021, 23:06

Mal wieder ein Problem mit logrotate und AWStats

Post by tab-kh »

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
(Probleme ohne KeyHelp-Bezug gehören ins Offtopic-Forum)

Server-Betriebssystem + Version
(z.B. Ubuntu 20.04)
Debian 11.6 (64-bit)

Eingesetzte Server-Virtualisierung-Technologie
(z.B. keine, OpenVZ, KVM, XEN, etc.)
KVM

KeyHelp-Version + Build-Nummer
(z.B. 22.0 - Build 2366)
22.2 (Build 2838)

Problembeschreibung / Fehlermeldungen
Fehlermeldung im Syslog bei logrotate/AWStats

Erwartetes Ergebnis
Keine Fehlermeldungen

Tatsächliches Ergebnis

Code: Select all

Dec 28 00:00:01 sunny logrotate[630658]: Error while processing /etc/awstats/awstats.tabwp.conf
Dec 28 00:00:01 sunny logrotate[630666]: Create/Update database for config "/etc/awstats/awstats.tabwp.conf" by AWStats version 7.8 (build 20200416)
Dec 28 00:00:01 sunny logrotate[630666]: From data in log file "/home/users/tabwp/logs/access.log"...
Dec 28 00:00:01 sunny logrotate[630666]: Phase 1 : First bypass old records, searching new record...
Dec 28 00:00:01 sunny logrotate[630666]: Direct access after last parsed record (after line 543)
Dec 28 00:00:01 sunny logrotate[630666]: Error: Couldn't open file "/home/keyhelp/www/kh.webstats/tabwp/awstats122022.tabwp.tmp.630664" for write: Permission denied
Dec 28 00:00:01 sunny logrotate[630666]: Setup ('/etc/awstats/awstats.tabwp.conf' file, web server or permissions) may be wrong.
Dec 28 00:00:01 sunny logrotate[630666]: Check config file, permissions and AWStats documentation (in 'docs' directory).
Dec 28 00:00:01 sunny logrotate[630658]: Error while processing /etc/awstats/awstats.tbantel.conf
Dec 28 00:00:01 sunny logrotate[630670]: Create/Update database for config "/etc/awstats/awstats.tbantel.conf" by AWStats version 7.8 (build 20200416)
Dec 28 00:00:01 sunny logrotate[630670]: From data in log file "/home/users/tbantel/logs/access.log"...
Dec 28 00:00:01 sunny logrotate[630670]: Phase 1 : First bypass old records, searching new record...
Dec 28 00:00:01 sunny logrotate[630670]: Direct access after last parsed record (after line 8812)
Dec 28 00:00:01 sunny logrotate[630670]: Error: Couldn't open file "/home/keyhelp/www/kh.webstats/tbantel/awstats122022.tbantel.tmp.630667" for write: Permission denied
Dec 28 00:00:01 sunny logrotate[630670]: Setup ('/etc/awstats/awstats.tbantel.conf' file, web server or permissions) may be wrong.
Dec 28 00:00:01 sunny logrotate[630670]: Check config file, permissions and AWStats documentation (in 'docs' directory).

Schritte zur Reproduktion
??? s.u.

Zusätzliche Informationen
(z.B. kürzlich durchgeführte Änderungen am Server, Auszüge aus Protokolldateien (/var/log/*, /var/log/keyhelp/php-error.log, etc.))
Probleme mit logrotate/readonly/AWStats gab es ja schon mal. Deswegen hier gleich mal die Datei /lib/systemd/system/logrotate.service ...

Code: Select all

[Unit]
Description=Rotate log files
Documentation=man:logrotate(8) man:logrotate.conf(5)
RequiresMountsFor=/var/log
ConditionACPower=true

[Service]
Type=oneshot
ExecStart=/usr/sbin/logrotate /etc/logrotate.conf

# performance options
Nice=19
IOSchedulingClass=best-effort
IOSchedulingPriority=7

# hardening options
#  details: https://www.freedesktop.org/software/systemd/man/systemd.exec.html
#  no ProtectHome for userdir logs
#  no PrivateNetwork for mail deliviery
#  no NoNewPrivileges for third party rotate scripts
#  no RestrictSUIDSGID for creating setgid directories
LockPersonality=true
MemoryDenyWriteExecute=true
PrivateDevices=true
PrivateTmp=true
ProtectClock=true
ProtectControlGroups=true
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectSystem=full
RestrictNamespaces=true
RestrictRealtime=true
Ich habe jetzt unten wieder die fehlende Zeile eingefügt

Code: Select all

# Exception so that AWStats works without complaints
ReadWritePaths=/etc/awstats
und

Code: Select all

systemctl reload-daemon
ausgeführt. Da die Fehlermeldungen aber anders sind als beim letzten Problemfall, bei dem auch JIT mit von der Partie war
viewtopic.php?p=37962
bin ich mir nicht sicher, ob das reichen wird oder ob da mehr zu tun ist, um das Problem zu fixen. Insbesondere sind da ja einige Hardening-Options mehr aktiviert als bei der originalen mit Keyhelp installierten Datei, die hier wohl bei einem Update im Laufe des Augusts diesen Jahres überschrieben wurde. Bei einem relativ neuen Server vom 30.08.22 ist noch die Originaldatei aus der Keyhelp-Installation drin, also muss die Datei vor diesem Termin überschrieben worden sein. Bei allen älteren Servern (alle gleiche OS und Keyhelp Version wie oben) sah sie so aus wie oben.

Da es aber wieder um logrotate und AWStats geht und um Dateien, die nicht geschrieben werden können, gehe ich schon davon aus, dass die Ursache ähnlich oder identisch ist.

Da das Problem sowieso schon längere Zeit besteht ohne aufgefallen zu sein, kann ich auch gerne bis zum nächsten Auftreten auf einem der betroffenen Server warten, um zu sehen, ob es geholfen hat. Oder sollte ich besser vorsorglich komplett die mit Keyhelp installierte Version der Datei wieder herstellen?
tab-kh
Posts: 450
Joined: Thu 22. Apr 2021, 23:06

Re: Mal wieder ein Problem mit logrotate und AWStats

Post by tab-kh »

Da der Fehler heute nach Mitternacht wieder aufgetreten ist, habe ich jetzt die /lib/systemd/system/logrotate.service komplett durch die "Originalversion" von Keyhelp ersetzt, also

Code: Select all

[Unit]
Description=Rotate log files
Documentation=man:logrotate(8) man:logrotate.conf(5)
ConditionACPower=true

[Service]
Type=oneshot
ExecStart=/usr/sbin/logrotate /etc/logrotate.conf

# performance options
Nice=19
IOSchedulingClass=best-effort
IOSchedulingPriority=7

# hardening options
#  details: https://www.freedesktop.org/software/systemd/man/systemd.exec.html
#  no ProtectHome for userdir logs
#  no PrivateNetwork for mail deliviery
#  no ProtectKernelTunables for working SELinux with systemd older than 235
#  no MemoryDenyWriteExecute for gzip on i686
PrivateDevices=true
PrivateTmp=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectSystem=full
RestrictRealtime=true

# Exception so that AWStats works without complaints
ReadWritePaths=/etc/awstats
Gefolgt von

Code: Select all

systemctl daemon-reload
Dann warte ich mal bis zur nächsten Ausführung von logrotate.
tab-kh
Posts: 450
Joined: Thu 22. Apr 2021, 23:06

Re: Mal wieder ein Problem mit logrotate und AWStats

Post by tab-kh »

Der Fehler ist immer noch da. Auf den zwei neueren meiner vier Keyhelp-Server, beide in diesem Jahr installiert (Edit: Installation Keyhelp direkt auf Debian 11 minimal), tritt er auf. Bei den beiden älteren nicht (Edit: Installation Keyhelp auf Debian 10 minimal, später dann per Upgrade-Skript auf Debian 11 gebracht). Ich komme da im Moment nicht weiter. Vielleicht nächstes Jahr.
User avatar
Alexander
Keyweb AG
Posts: 3811
Joined: Wed 20. Jan 2016, 02:23

Re: Mal wieder ein Problem mit logrotate und AWStats

Post by Alexander »

Ich hatte gehofft, man könnte die Konfigurationsdatei außerhalb von /etc/ ablegen um somit sich den Workaround für Logrotate komplett zu sparen. Rein logisch würd ich es gern unter /home/keyhelp/www/kh.webstats/<USERNAME>/<DOMAIN>/ ablegen.

Leider lässt das Awstats aus welchem Grund auch immer nicht zu. Die Datei befindet sich an der angegebenen Stelle, an der Awstats vorgibt zu suchen. Aber finden will er sie trotzdem nicht... :x

Code: Select all

root@dev01:/# awstats -config='/tmp/alex.conf' -update
Error: Couldn't open config file "awstats./tmp/alex.conf.conf", nor "awstats.conf", nor "/tmp/alex.conf" after searching in path "/usr/bin, /etc/awstats, /usr/local/etc/awstats, /etc/opt/awstats, /tmp/alex.conf": No such file or directory

Code: Select all

root@dev01:/# ls -la /tmp/
total 92
drwxrwxrwt 18 root    root    4096 Jan  3 13:00 .
drwxr-xr-x 21 root    root    4096 Nov 22 11:41 ..
-rwxrwxrwx  1 root    root     843 Jan  3 13:00 alex.conf
EDIT: Laut Awstats code wurde das Feature wohl aus Sicherheitsgründen deaktiviert, aber die Fehlermeldung haben sie nicht angepasst...
Mit freundlichen Grüßen / Best regards
Alexander Mahr

**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
tab-kh
Posts: 450
Joined: Thu 22. Apr 2021, 23:06

Re: Mal wieder ein Problem mit logrotate und AWStats

Post by tab-kh »

Alexander wrote: Tue 3. Jan 2023, 13:04

Code: Select all

root@dev01:/# awstats -config='/tmp/alex.conf' -update
Error: Couldn't open config file "awstats./tmp/alex.conf.conf", nor "awstats.conf", nor "/tmp/alex.conf" after searching in path "/usr/bin, /etc/awstats, /usr/local/etc/awstats, /etc/opt/awstats, /tmp/alex.conf": No such file or directory
Ist das jetzt eine verwirrende Meldung von awstats oder steht da tatsächlich "/tmp/alex.conf" im Pfad? Dann könnte er die Datei wohl tatsächlich nicht finden. Das logrotate der access.log(s) selbst scheint aber zu funktionieren, das ist mir momentan das Wichtigste dabei, auch wenn sicher im nächsten Jahr bei meinen Servern nicht zu befürchten ist, dass das Dateisystem überläuft :). Ob awstats jetzt immer alle Zugriffe auswertet ist mir persönlich nicht so wichtig. Allgemein gesehen wäre es freilich trotzdem schön, wenn auch awstats fehlerfrei laufen und alles auswerten würde.

Was mir freilich Sorgen und Hoffnung gleichzeitig macht ist, dass es auf zwei Servern zu funktionieren scheint. Obwohl, ich muss mir das auch nochmal im Detail anschauen, ob ich da auch wirklich einen Tag angeschaut habe, wo logrotate auch tatsächlich was gemacht hat an den access.logs auf diesen Servern.
User avatar
Alexander
Keyweb AG
Posts: 3811
Joined: Wed 20. Jan 2016, 02:23

Re: Mal wieder ein Problem mit logrotate und AWStats

Post by Alexander »

Normalerweise nimmt awstats das, was man unter dem Parameter "-config=<WERT>" angibt und baut daraus "/etc/awstats/awstats.<WERT>.conf".
Man soll laut Dokumentation aber auch einen vollen Pfad angeben können.

Hab mitlerweile im Code von Awstats geschaut. Da wurde das Feature wohl aus Sicherheitsgründen deaktiviert/auskommentiert, aber die Fehlermeldung haben sie nicht angepasst, weswegen der Pfad in der Meldung noch aufgeführt wird.
Mit freundlichen Grüßen / Best regards
Alexander Mahr

**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
User avatar
Alexander
Keyweb AG
Posts: 3811
Joined: Wed 20. Jan 2016, 02:23

Re: Mal wieder ein Problem mit logrotate und AWStats

Post by Alexander »

Ich habe einmal auf diversen Servern geschaut, ob die ls -la /lib/systemd/system/logrotate.service in der letzten Zeit geändert wurde.

Bei Ubuntu Systemen:
- Änderungsstand der vom 14. Dezember 2021
- das deckt sich mit dem Fix, der mit KeyHelp 21.3 am 14. Dezember 2021 kam. Fix ist in der Datei enthalten.

Bei Debian Systemen:
- häufig Änderungsstand 21. August 2020
- Datei wurde mit alter Version überschrieben, kein Fix mehr vorhanden.


Hmm, könnte nun hingehen und bei Debian Systemen alle paar Tage die Datei überschreiben, gefällt mir nicht unbedingt, und führt ja wie bei dir auch nicht unbedingt zum Erfolgt.
Mit freundlichen Grüßen / Best regards
Alexander Mahr

**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
tab-kh
Posts: 450
Joined: Thu 22. Apr 2021, 23:06

Re: Mal wieder ein Problem mit logrotate und AWStats

Post by tab-kh »

Zu der Datei logrotate.service gab es ja schon diverse Threads. Ich habe die ja auch schon in drei verschiedenenVersionen benutzt. Zum einen so, wie sie laut einem der Threads mit Keyhelp ausgeliefert wurde, unten mit einer Ausnahme für awstats. Dann die Datei, wie ich sie in einem der betroffenen Server vorgefunden hatte. Also mit mehr Hardening-Einträgen und ohne die Ausnahme für awstats. Zuguterletzt auch noch die neue Version, mit der von mir eingefügten Ausnahme für awstats. Geholfen hat letztlich nichts.

Im Moment habe ich jetzt überall die "Originalversion" von Keyhelp am Laufen. Auch hiermit besteht das Problem auf (mindestens) zwei der vier Server. Ich schaue heute Abend mal genauer rein bei den scheinbar nicht betroffenen Server, um festzustellen, wann logrotate zuletzt die Access-Logs rotiert hat und ob an diesem Tag nicht vielleicht doch der Fehler geworfen wurde.

Edit: Eben mal reingeschaut, die syslog und syslog.1 auf dem einen nicht betroffenen Server decken den Zeitraum ab 25.12.22 ab und enthalten den Fehler nicht. Hier beginnt die aktuelle /home/users/userxxx/logs/access.log am 01.01.23 00:00:43 (erster Eintrag), die alte access.log.1 endet am 01.01.23 00:00:14 (letzter Eintrag). Es hat also vom 31.12.22 auf den 01.01.23 ein logrotate der access.log stattgefunden.

Zwischen

Code: Select all

Jan  1 00:00:00 bunny systemd[1]: Starting Rotate log files...
am Ende der /var/log/syslog.1 und

Code: Select all

Jan  1 00:00:21 bunny systemd[1]: logrotate.service: Succeeded.
Jan  1 00:00:21 bunny systemd[1]: Finished Rotate log files.
der aktuellen /var/log/syslog steht zwar jede Menge anderes Zeug, inklusive dem ersten Teil eines Laufs von freshclam, aber der Fehler mit awstats ist da definitiv nicht drin. Also lief das logrotate hier wohl ohne den Fehler mit awstats ab.
Post Reply