KeyHelp Community

Nach meinem Verständnis wäre es für Keyhelp idealerweise um 0 Uhr. So ist es auch bisher bei all meinen Servern gewesen. Aber nicht bei dem neuen von Strato. Da lief logrotate um 6:24:50. An sich sollte es ja egal sein, aber eventuell stört es bei den Web-Statistiken (awstats)? Hatte da beim logrotate auch wieder die altbekannten Fehlermeldungen wie auf einigen anderen Servern, die ich im letzten Jahr mal versucht habe loszuwerden - bisher ohne Erfolg.

Jedenfalls wird logrotate ab heute um Mitternacht gstartet. Nachdem ich mich bei der Ursachensuche durch die Einträge in cron.daily und lib/systemd/system/logrotate.service und .../timer durchgeämpft habe, wobei das Letztere wieder mal Neuland für mich war, fand ich dann in logrotate.timer die von den anderen Servern abweichenden Einträge und habe sie dann angepasst. Jetzt werde ich das mal beobachten müssen. Die Datei logrotate.service wurde ja seitens Keyhelp geändert wegen Ausnahmen für awstats, wird bei der Gelegenheit nicht auch gleich die logrotate.timer angepasst? Da stand jetzt auf dem Strato-Server bei "OnCalendar=" die abweichende, oben genannte tägliche Ausführungszeit drin, während bei den anderen "daily" drinstand. So habe ich das jetzt auch geändert und auch AccuracySec von 12h auf 1h an die anderen Server angeglichen, wonach es jetzt so aussieht:

Code: Select all

root@fanny:~# systemctl list-timers
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Sat 2023-08-19 18:09:00 CEST 25min left    Sat 2023-08-19 17:39:01 CEST 4min 35s ago phpsessionclean.timer        phpsessionclean.service
Sun 2023-08-20 00:00:00 CEST 6h left       Sat 2023-08-19 06:24:55 CEST 11h ago      logrotate.timer              logrotate.service
Sun 2023-08-20 00:00:00 CEST 6h left       Sat 2023-08-19 00:00:01 CEST 17h ago      man-db.timer                 man-db.service
Sun 2023-08-20 03:10:38 CEST 9h left       Sun 2023-08-13 03:11:01 CEST 6 days ago   e2scrub_all.timer            e2scrub_all.service
Sun 2023-08-20 04:11:29 CEST 10h left      Sat 2023-08-19 14:52:08 CEST 2h 51min ago apt-daily.timer              apt-daily.service
Sun 2023-08-20 06:20:09 CEST 12h left      Sat 2023-08-19 06:47:01 CEST 10h ago      apt-daily-upgrade.timer      apt-daily-upgrade.service
Sun 2023-08-20 15:45:08 CEST 22h left      Sat 2023-08-19 15:45:08 CEST 1h 58min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2023-08-21 01:16:58 CEST 1 day 7h left Mon 2023-08-14 00:12:09 CEST 5 days ago   fstrim.timer                 fstrim.service

8 timers listed.
Pass --all to see loaded but inactive timers, too.

Interessant...Ich hab jetzt mal auf einigen meiner Systeme geschaut. Bei allen Systemen sieht meine logrotate.timer so aus:

Code: Select all

[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)

[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

Bei einem System allerdings so:

Code: Select all

[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)

[Timer]
OnCalendar=*-*-* 06:24:50
AccuracySec=12h
Persistent=true

[Install]
WantedBy=timers.target

Also der selbe Effekt wie bei dir.
Ist aber keine Strato Kiste

Ehrlich gesagt, ist mir das bisher nicht aufgefallen...vielleicht auch, weil ich auf dem System, wo eine Startzeit eingetragen ist, kein Awstats nutze...

Edit:

Ich hab mal nach möglichen Unterschieden bzw. Gemeinsamkeiten geschaut.
Alle Systeme bis auf den Abweichler sind vServer, die auf Hosts mit Intel CPU und KVM laufen, der Abweichler auf AMD mit XEN.
Die Files logrotate.service und logrotate.timer haben auf allen Systemen Timestamps, die seit der Installation unverändert sind, beim Abweichler ist der Timestamp vom 03. Juni 10:20 Uhr.

Bisher erschließt sich mir die Ursache noch nicht wirklich. Ich setze heute abend mal ein paar Test-VMs auf und stöbere weiter.

Sehe ich das richtig, dass logrotate normalerweise erst vom Keyhelp-Installationsskript installiert wird? Habe hier gerade mal meinen Miniserver angeworfen, den ich als Munin-Server verwenden will. Da ist jedenfalls bei dem Debian 12 Image von Strato kein logrotate installiert und auch kein Timer dafür. Da ist allerdings noch nicht mal cron vorhanden

.

Davor hatte ich zwei Wochen klaglos Debian 11 mit Keyhelp darauf laufen, hatte mich einfach mal interessiert ob die Ressourcen für eine Keyhelp-Installation reichen. Tun sie tatsächlich, das Panel konnte problemlos benutzt werden und hat brav die paar Dutzend von fail2ban gebannten Chinesen angezeigt. Hatte mir sogar kurz überlegt, ob ich Keyhelp da drauf lasse. Aber macht ja nicht wirklich Sinn, jetzt wird er ohne Keyhelp seinem eigentlichen Zweck zugeführt.

tab-kh wrote: ↑Sat 19. Aug 2023, 20:50 Sehe ich das richtig, dass logrotate normalerweise erst vom Keyhelp-Installationsskript installiert wird?

Ich habs jetzt mal schnell in einer Virtualbox VM getestet. Debian 11 minimal installiert (bei der Installation nur SSH und Standard Systemwerkzeuge ausgewählt), logrotate ist schon dabei und wird auch mit:

Code: Select all

[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true

korrekt eingerichtet.

Könntest du mal die Ausgabe von

Code: Select all

lscpu

von der betreffenden Kiste posten?

Jolinar wrote: ↑Sat 19. Aug 2023, 18:27 Interessant...Ich hab jetzt mal auf einigen meiner Systeme geschaut. Bei allen Systemen sieht meine logrotate.timer so aus:
[...]
Ehrlich gesagt, ist mir das bisher nicht aufgefallen...vielleicht auch, weil ich auf dem System, wo eine Startzeit eingetragen ist, kein Awstats nutze...

Ich nutze Awstats bisher auf keinem meiner Keyhelp-Server. Es macht sich nur auf den meisten Servern unangenehm bemerkbar, weil logrotate die Syslog mit Fehlermeldungen für jede einzelne eingerichtete Domain/Subdomain vollmüllt. Das ist selbst zwischen netcup-Servern unterschiedlich ob es auftritt oder nicht. Bei Strato-Servern passiert es jedenfalls bis jetzt immer. Das Thema hatte ich ja mal als Problem gemeldet und andere schon vor mir. Die genaue Ursache scheint aber noch nicht gefunden zu sein. Ich selbst habe auch keine gefunden und die auf einigen Servern auftretenden Fehlermeldungen notgedrungen akzeptiert. Unterschiede konnte ich jedenfalls damals keine feststellen und so wichtig, dass ich da mit meinen limiterten Kenntnissen Wochen investiere, ist mir das nicht. Natürlich muss es aber einen Grund geben.

Jolinar wrote: ↑Sat 19. Aug 2023, 18:27 Edit:

Ich hab mal nach möglichen Unterschieden bzw. Gemeinsamkeiten geschaut.
Alle Systeme bis auf den Abweichler sind vServer, die auf Hosts mit Intel CPU und KVM laufen, der Abweichler auf AMD mit XEN.
Die Files logrotate.service und logrotate.timer haben auf allen Systemen Timestamps, die seit der Installation unverändert sind, beim Abweichler ist der Timestamp vom 03. Juni 10:20 Uhr.

Bisher erschließt sich mir die Ursache noch nicht wirklich. Ich setze heute abend mal ein paar Test-VMs auf und stöbere weiter.

Ich habe das mit dem Zeitpunkt des logrotate-Laufs eigentlich nur aufgebracht, weil ich das als Ursache für ein anderes Problem im Verdacht hatte. Das ist mittlerweile widerlegt. Das Problem ist nach dem logrotate Lauf um Mitternacht wieder aufgetreten. Es betrifft clamav/freshclam bzw dessen Logs. Dazu mache ich gleich einen eigenen Thread auf, einen offiziellen Problem/Bug-Thread in Keyhelp möchte ich aber erst einmal nicht aufmachen, da ich mir absolut nicht sicher bin, dass das Problem überhaupt von Keyhelp verursacht und nicht eher allgemeinerer Natur ist. Sollte sich im weiteren Verlauf jedoch ein konkreter Verdacht in Richtung Keyhelp ergeben, werde ich das gern tun.

tab-kh wrote: ↑Sun 20. Aug 2023, 12:33 Ich habe das mit dem Zeitpunkt des logrotate-Laufs eigentlich nur aufgebracht, weil ich das als Ursache für ein anderes Problem im Verdacht hatte.

Dei bei dir und bei mir identische Ausführungszeit halte ich aber für mehr als nur einen Zufall...

Jolinar wrote: ↑Sun 20. Aug 2023, 11:29
tab-kh wrote: ↑Sat 19. Aug 2023, 20:50 Sehe ich das richtig, dass logrotate normalerweise erst vom Keyhelp-Installationsskript installiert wird?
Ich habs jetzt mal schnell in einer Virtualbox VM getestet. Debian 11 minimal installiert (bei der Installation nur SSH und Standard Systemwerkzeuge ausgewählt), logrotate ist schon dabei und wird auch mit:
Code: Select all
[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true
korrekt eingerichtet.

Könntest du mal die Ausgabe von
Code: Select all
lscpu
von der betreffenden Kiste posten?

Gut, dann scheint minimal halt nicht für jeden Serveranbieter das selbe zu bedeuten. Ebenso wie KVM. Strato schreibt ja explizit "KVM Plattform". Und in der detaillierten Liste nochmal "Virtualisierung KVM". Was das in dem Fall konkret bedeutet weiss ich nicht. Die Kisten laufen ja offenbar nicht auf einem Linux-Host. Zugute halten muss ich denen, dass die Kiste im allgemeinen recht performant ist und dass sie ihre angebotenen Images auch nicht als "Minimal" bezeichnen.

Ausgabe von lscpu:

Code: Select all

root@mail:~# lscpu
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Byte Order:                         Little Endian
Address sizes:                      40 bits physical, 48 bits virtual
CPU(s):                             4
On-line CPU(s) list:                0-3
Thread(s) per core:                 2
Core(s) per socket:                 1
Socket(s):                          2
NUMA node(s):                       1
Vendor ID:                          AuthenticAMD
CPU family:                         25
Model:                              1
Model name:                         AMD EPYC-Milan Processor
Stepping:                           1
CPU MHz:                            2000.000
BogoMIPS:                           4000.00
Virtualization:                     AMD-V
Hypervisor vendor:                  Microsoft
Virtualization type:                full
L1d cache:                          64 KiB
L1i cache:                          64 KiB
L2 cache:                           1 MiB
L3 cache:                           64 MiB
NUMA node0 CPU(s):                  0-3
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Not affected
Vulnerability Spec rstack overflow: Mitigation; safe RET, no microcode
Vulnerability Spec store bypass:    Mitigation; Speculative Store Bypass disable
                                    d via prctl and seccomp
Vulnerability Spectre v1:           Mitigation; usercopy/swapgs barriers and __u
                                    ser pointer sanitization
Vulnerability Spectre v2:           Mitigation; Retpolines, IBPB conditional, IB
                                    RS_FW, STIBP conditional, RSB filling, PBRSB
                                    -eIBRS Not affected
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep
                                    mtrr pge mca cmov pat pse36 clflush mmx fxsr
                                     sse sse2 ht syscall nx mmxext fxsr_opt pdpe
                                    1gb rdtscp lm rep_good nopl cpuid extd_apici
                                    d tsc_known_freq pni pclmulqdq ssse3 fma cx1
                                    6 pcid sse4_1 sse4_2 x2apic movbe popcnt aes
                                     xsave avx f16c rdrand hypervisor lahf_lm cm
                                    p_legacy svm cr8_legacy abm sse4a misalignss
                                    e 3dnowprefetch osvw topoext perfctr_core in
                                    vpcid_single ssbd ibrs ibpb stibp vmmcall fs
                                    gsbase bmi1 avx2 smep bmi2 invpcid rdseed ad
                                    x smap clflushopt clwb sha_ni xsaveopt xsave
                                    c xgetbv1 xsaves clzero xsaveerptr wbnoinvd
                                    arat npt nrip_save umip pku ospke rdpid
root@mail:~#

Jolinar wrote: ↑Sun 20. Aug 2023, 12:43
tab-kh wrote: ↑Sun 20. Aug 2023, 12:33 Ich habe das mit dem Zeitpunkt des logrotate-Laufs eigentlich nur aufgebracht, weil ich das als Ursache für ein anderes Problem im Verdacht hatte.
Dei bei dir und bei mir identische Ausführungszeit halte ich aber für mehr als nur einen Zufall...

Zufall sicher nicht. Aber wohl nicht die Ursache für das andere Problem.

tab-kh wrote: ↑Sun 20. Aug 2023, 12:50 Die Kisten laufen ja offenbar nicht auf einem Linux-Host.

Nach der Ausgabe von lscpu scheint der Host ein Windows Serversystem zu sein. Seit WS 2016 ist ja KVM Virtualisierung ins OS integriert...Allerdings bin ich an diesem Punkt dann auch außen vor, ich hab noch nie mit Win Serversystemen gearbeitet (und werde das auch zukünftig nicht anfassen^^).

Jolinar wrote: ↑Sun 20. Aug 2023, 13:00
tab-kh wrote: ↑Sun 20. Aug 2023, 12:50 Die Kisten laufen ja offenbar nicht auf einem Linux-Host.
Nach der Ausgabe von lscpu scheint der Host ein Windows Serversystem zu sein. Seit WS 2016 ist ja KVM Virtualisierung ins OS integriert...Allerdings bin ich an diesem Punkt dann auch außen vor, ich hab noch nie mit Win Serversystemen gearbeitet (und werde das auch zukünftig nicht anfassen^^).

Ich bin da weniger konsequent. Wenn es eine vollständige Virtualisierung und performant ist, dann ist mir der Host und der Hypervisor relativ egal, die muss ich ja (hoffentlich) nicht betreuen. Keyhelp kommt damit eigentlich gut zurecht, schreibt im Dashboard halt brav "Virtualisierung MICROSOFT" und läuft wie eine Eins. Zumindest das "Problem" der anderen Zeit für den logrotate Aufruf scheint ja auch bei anderen Virtualisierungen/Images aufzutauchen. Und sogar meine netcup-Server verhalten sich zumindest in Bezug auf die logrotate/awstats-Fehlermeldungen unterschiedlich.

Jolinar wrote: ↑Sun 20. Aug 2023, 13:00 Die Kisten laufen ja offenbar nicht auf einem Linux-Host.

Wenn es sonst keine Erklärung dafür gibt, dann ist vermutlich dieses OnCalendar einfach nur ein Feature

Bei Microsoft Produkten kann ich nur dringend von abraten, nach dem Exchange und Azure Gau haben die noch mehr in Petto, sieht für mich aus als wäre der komplette Laden derweil durch und durch kompromittiert:
https://www.heise.de/hintergrund/Gestoh ... 34601.html

Ich habe nach 12 Jahren kurz mal eine V-Box Installation gewagt wg. Garmin Updates ... am Ende hat mich mein Übermut ganze 2 Tage gekostet und nix kam dabei rum außer Frust. Aber davon ab, die Anwendungen bzw. deren Paket Quellen wären für mich kaum noch vertrauenswürdig und von der Stabilität ist es auch keine gute Wahl darauf eine Virtualisierung für Linux Systeme aufzubauen.

Ralph wrote: ↑Sun 20. Aug 2023, 15:34 Bei Microsoft Produkten kann ich nur dringend von abraten

Wobei man hier aber ehrlicherweise sagen muß, daß der Normaluser, der sich bei einem Hoster irgendeinen Server mietet, in der Regel eher nicht vorher recherchiert, welches OS die Hostsysteme verwenden.

Die logrotate.timer Datei mit "06:24:50" kommt von KeyHelp und wird bei der Installation bzw. beim Dist-Upgrade installiert.
Wenn die Angabe mittlerweile nicht mehr drin steht, muss sie also von anderen Diensten (oder im Zuge von 'apt upgrade' etc.) überschrieben worden sein.

06:24:50 war früher mal Standard, damals war der logrotate über einen eigenen Cronjob des Logrotate Dienstes geregelt.
(Ubuntu 18.04 war das letzte System, was es noch nach diesem alten Schema machte).

Mit "Einführung" der Timer-Dateien in den neueren Betriebssystem-Versionen fiel dann auch der Cronjob weg, aber der Logrotate um 0:00 Uhr verursachte an anderer Stelle Probleme (welche das waren weiß ich adhoc auch nicht mehr genau, hatte was mit dem Statistiklauf zu tun), ergo hab ich die Durchführzeit durch die Timer-Datei wieder auf den ursprünglichen Wert 06:24:50 gesetzt.

Alexander wrote: ↑Mon 21. Aug 2023, 09:57 ergo hab ich die Durchführzeit durch die Timer-Datei wieder auf den ursprünglichen Wert 06:24:50 gesetzt.

Und wieder ein Mysterium aufgeklärt.

Hmm, ca um die selbe Zeit läuft aber bei mir logwatch per /etc/cron.daily, deswegen wollte ich von der Zeit wieder weg und bei meinen alten Servern lief logrotate halt um ca 0:00. Deswegen habe ich das auf dem neuen Server den selben Wert gesetzt wie eben dort auch. Wenn das also Probleme macht, dann haben diese Probleme prinzipiell derzeit alle meine Server. Ist es denn zwingend erforderlich, das so knapp vor 6:25 laufen zu lassen oder kann ich das auch auf 6:00 stellen oder 6:20, so dass etwas Zeit dazwischen ist und logrotate mit Sicherheit abgeschlossen ist bevor logwatch losläuft?

KeyHelp Community

Wann sollte logrotate laufen?

Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?

Re: Wann sollte logrotate laufen?