Beiträge von weltmeister

Diese Einstellung habe ich auch schon vergeblich gesucht...

CloudLinux 7 ist aber schon veraltet - oder irre ich mich da?

Auch bei uns gibt es ständig die Nachfrage, warum für jede Subdomain umständlich und manuell ein Zertifikat angelegt werden muss und warum keine Wildcard-Zertifikate möglich sind. Daher würde ich dies als neue Funktion begrüßen.

Das Problem besteht leider noch immer und ich weiß schon gar nicht mehr, wo ich noch suchen soll. Die Logs sagen leider nicht viel aus, siehe Beitrag 1.

Hat noch jemand einen Tipp, an welcher Stelle nach der Ursache gesucht werden kann?

Man muss dem "Support" aber gehörig auf den Leim gehen, bis die IP wieder freigegeben wird.

Vielen Dank für die Erläuterungen! Hierzu weitere eingehende Fragen:

Was könnte der Grund dafür sein, dass der lclogsplit-Prozess nicht läuft?
Gibt es eine Möglichkeit, diesen manuell zu starten oder gar neu zu installieren /zu aktivieren?
Hat dieser Dienst Konfigurationsdateien, die man auf Richtigkeit / vorhandensein prüfen kann?

Das Problem tritt auf insgesamt 7 Servern auf, die kürzlich von Debian 9 auf 10 aktualisiert worden sind. Ich wäre sehr daran interessiert, diese aus der Welt zu schaffen.

Habe das Problem einmal einem erfahrenen Administrator weitergereicht, hier dessen Antwort:

Wenn ich mir die Fehlermeldung von lograte ansehe:

systemctl status logrotate
● logrotate.service - Rotate log files
  Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled)
  Active: failed (Result: exit-code) since Thu 2020-11-12 00:00:01 CET; 9h ago
    Docs: man:logrotate(8)
          man:logrotate.conf(5)
 Process: 25679 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=1/FAILURE)
Main PID: 25679 (code=exited, status=1/FAILURE)


Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web4/logs/*.log '
Nov 12 00:00:01 s26.server.de logrotate[25679]: lclogsplit: Kein Prozess gefunden
Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web5/logs/*.log '
Nov 12 00:00:01 s26.server.de logrotate[25679]: lclogsplit: Kein Prozess gefunden
Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web6/logs/*.log '
Nov 12 00:00:01 s26.server.de logrotate[25679]: lclogsplit: Kein Prozess gefunden
Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web3/logs/*.log '
Nov 12 00:00:01 s26.server.de systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Nov 12 00:00:01 s26.server.de systemd[1]: logrotate.service: Failed with result 'exit-code'.Nov 12 00:00:01 s26.server.de systemd[1]: Failed to start Rotate log files.

wird klar das es am postrotate Kommando "/usr/bin/killall -HUP lclogsplit" in der Datei: /etc/logrotate.d/liveconfig-vhosts liegt.
Dieses Kommando killt das Programm lclogsplit für jedes Dort angegebene Verzeichnis Abschnitt.
Da schon beim ersten Aufruf der lclogsplit Daemon nicht mehr läuft, werden alle Folgeaufrufe mit Error 1 an das posttrotate zurückgegeben, was dann zu dieser Meldung führt.

Hier müssten Sie einmal an den Anbieter von Liveconfig herantreten ob es diesbezüglich ein Update/Patch gibt. Da das logrotate file aus liveconfig generiert wird, bringt es leider nichts es dort selbst zu beheben, da es immer wieder überschrieben wird.

Hier die 3 Einträge von heute:

Nov 06 00:00:05 s20.de systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Nov 06 00:00:05 s20.de systemd[1]: logrotate.service: Failed with result 'exit-code'.
Nov 06 00:00:05 s20.de systemd[1]: Failed to start Rotate log files.

In den Logfiles steht das selbe. Aber klug werde ich daraus nicht.

Vielen Dank, den Eintrag

Zitat

postrotate
invoke-rc.d rsyslog rotate > /dev/null
endscript

gibt es so in der gen. Datei nicht. Da das Problem leider noch immer besteht: wo könnte man noch nach der Ursache suchen?

Vielen Dank, das hat funktioniert.

Zitat von antondollmaier

Logrotate manuell ausführen (logrotate -v -f /etc/logrotate.conf)

...ist perfekt duchgelaufen. Wie aber kann man das Problem lösen, das sich der Dienst von selbst beendet?

Und jetzt eine vielleicht "ganz dumme" Frage: wie wird der Upload-Scan deaktivert, so das Kunden unter PHP 5.6. wieder Daten hochladen können?

Täglich um 00:00 Uhr "verabschiedet" sich der Logrotate-Dienst auf einigen Servern unter Debian 10. Leider sind die Logeinträge nicht gerade besonders hilfreich:

Zitat

Nov 4 00:00:07 s5 rsyslogd: [origin software='rsyslogd' swVersion='8.1901.0' x-pid='560' x-info='https://www.rsyslog.com'] rsyslogd was HUPed
Nov 4 00:00:07 s5 systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Nov 4 00:00:07 s5 systemd[1]: logrotate.service: Failed with result 'exit-code'.
Nov 4 00:00:07 s5 systemd[1]: Failed to start Rotate log files.

Hat jemand einen Tipp, wo man zuerst mit der Fehlersuche beginnen könnte?

Ich schließe mich hier an. Auch wir haben noch einige wenige Kunden mit genau dem selben Problem. Debian 10, PHP 5.6, kein Upload möglich. Da wir die Kunden nicht zwingen können, eine andere Software zu nutzen, diese aber auch nur ungern verlieren wollen, wäre eine Lösung von Vorteil.

Dieser Hinweis bezieht sich auf die OpCache-Verzeichnisse, welche von LiveConfig durch den phpini-Eintrag "%HOME%/.cache/opcache.%PHP%" automatisch angelegt werden:

der normale Endkunde kann diese Verzeichnisse komplett löschen. Das Resultat ist, dass der Kunde nur eine Error500-Meldung sieht, da das Verzeichnis fehlt.

Abhilfe wäre ein entsprechender Schreibschutz, der durch LiveConfig den Verzeichnissen automatisch mit gegeben wird.

Die anderen Verzeichnisse, wie conf, priv, tmp... kann der normale Endkunde immerhin auch nicht löschen.

Hier muss man leider den Microsoft-Support kontaktieren und extrem hartnäckig bleiben.

Nach ein paar Tagen kommt eine Antwort, die sind im Service leider nicht gerade die schnellsten.

Microsoft versucht einen dann erfahrungsgemäß mit Textbaustein-Antworten wieder los zu werden. ("Bitte erfüllen Sie die Richtlinien, bla bla bla...")

Man muss immer und immer wieder antworten und um entsperrung bitten. Irgendwann nach ein paar Tagen und geschätzten 5 weiteren Mails geben die dann nach und die IP ist entsperrt.

Warum, wieso, weshalb man gesperrt worden ist, erfährt man leider nicht, selbst wenn man 10x nachfragt.

Mit gutem Service hat das nur wenig zu tun. Vergleich: schreibt man der Telekom, hat man innerhalb von ca. 15 Minuten eine Antwort und die IP wird idR. ohne zickereien entsperrt und es wird auch Begründet, warum es ein Blacklisting gab.

Hab die Lösung bereits, falls es jemanden interessiert. Beispiel:

Zitat

chattr -R -i /var/www/*/conf/php72

Nach einem Upgrade auf Debian 10 versuche ich, alte configs zu löschen:

Befehle wie

Zitat

chattr -iR */conf/php5/

oder

Zitat

chattr -i /var/www/*/conf/php5/*

usw. führen leider nicht zum Erfolg.

("Die Operation ist nicht erlaubt")

Gibt es noch etwas zu beachten oder eine andere Vorgehensweise?

Ansonsten wäre es doch das einfachste, wenn man eine alte PHP-Version deinstalliert, dass die Configs dazu automatisch mit gelöscht werden.

Besser wäre sogar die Möglichkeit, global die PHP-Version für alle Kunden umschalten zu können. Immer wieder bekommen wir Mails, weil die Kunden glauben, das wir als Provider automatisch umschalten. Die Funktion zum umstellen für den Kunden selbst ist leider sehr versteckt und wird in 75% aller Fälle nicht von dem Kunden gefunden. Nummer 1 Thema bei Support-Anfragen: "wo stelle ich die PHP-Version um oder müssen Sie das machen...?"

Zitat von aho546745

Was denn für ne Mailflut? Bei mir meldete nur Icinga:

APT WARNING: 0 packages available for upgrade (0 critical updates). warnings detected.

Siehe oben!