Beiträge von weltmeister

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!

Danke! D.h. die "Mailflut" hat dann ein Ende und es muss nichts weiter getan werden?

Folgende Meldung trifft für alle Server ein:

Zitat

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.liveconfig.com/debian main InRelease: Die folgenden Signaturen waren ungültig: EXPKEYSIG E73A23BF3A2B2840 LiveConfig Package Signer <pkgadmin@liveconfig.com>
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.liveconfig.com/debian stretch InRelease: Die folgenden Signaturen waren ungültig: EXPKEYSIG E73A23BF3A2B2840 LiveConfig Package Signer <pkgadmin@liveconfig.com>
W: Fehlschlag beim Holen von http://repo.liveconfig.com/debian/dists/main/InRelease Die folgenden Signaturen waren ungültig: EXPKEYSIG E73A23BF3A2B2840 LiveConfig Package Signer <pkgadmin@liveconfig.com>
W: Fehlschlag beim Holen von http://repo.liveconfig.com/debian/dists/stretch/InRelease Die folgenden Signaturen waren ungültig: EXPKEYSIG E73A23BF3A2B2840 LiveConfig Package Signer <pkgadmin@liveconfig.com>
W: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.

Der Schlüssel wurde bereits aktualisiert (wget -O - https://www.liveconfig.com/liveconfig.key | apt-key add -) - wo ist der Fehler versteckt? Muss die Datei unter /etc/liveconfig ersetzt werden?

Nun nach dem Update wurden alle Server umgestellt. Das Problem mit den Fehlermeldungen ist größtenteils behoben. Nur einige wenige Kunden beklagen sich noch über Störungen auf deren Seiten. In den Logs findet man dazu:

Zitat

[Thu Sep 17 10:53:23.198601 2020] [proxy_fcgi:error] [pid 24268:tid 140071785109248] [client 80.136.182.94:58768] AH01067: Failed to read FastCGI header, referer: https://www.xxxx.de/
[Thu Sep 17 10:53:23.198618 2020] [proxy_fcgi:error] [pid 24268:tid 140071785109248] (104)Connection reset by peer: [client xxx.xxx.xxx.xxx:58768] AH01075: Error dispatching request to : , referer: https://www.xxx.de/

Komischerweise wieder nur unter PHP 7.4.

Hier ist sicher noch ein Feinschliff an einer gewissen Stelle erforderlich? Gern schicke ich die Logs oder weitere Einzelheiten zu, falls benötigt.

Jetzt kommen auch noch diese Meldungen von allen Servern per Mail rein:

Zitat

E: The repository 'http://repo.liveconfig.com/debian main Release' does no longer have a Release file.
E: The repository 'http://repo.liveconfig.com/debian stretch Release' does no longer have a Release file.

Muss noch etwas getan / angepasst werden?

Vielen Dank!

Es läuft Debian 9

Ausgabe:

-rw-rw-rw- 1 root root 13432 Sep 17 01:50 /etc/logrotate.d/liveconfig-vhosts

Seite dem gestrigen Update gab es heute eine Mail (von jedem Server):

Zitat

Betreff: Cron <root@xxx.de> test -x /usr/sbin/anacron ( cd / && run-parts --report /etc/cron.daily )
/etc/cron.daily/logrotate:
error: Ignoring liveconfig-vhosts because of bad file mode - must be 0644 or 0444.

Was ist hier konkret noch zu tun und welche Logs sind gemeint?

Ich schließe mich an, der Hinweis auf "EOL" bei alten Versionen kann nicht schaden.

Danke für das schnelle Update. Die ersten 3 Server wurden "umgestellt" und der Cache wieder aktiviert: bisher ohne Probleme, alle Seiten, Unterseiten... sind erreichbar.

Zitat von kk

Und ich schätze mal, dass wenn jemand merkt dass unter PHP 7.4 ein Fehler auftaucht, er einfach wieder auf 7.3 zurückstellt und das nicht weiter hinterfragt.

Ganz im Gegenteil: jede 2. Mail lautete "Ihr Server ist Down / Abgstürzt / nicht erreichbar". D.h. die Kunden haben auf PHP 7.4 umgestellt, vermuten dort aber den Fehler nicht. (An dieser Stelle hätte nie jemand nach der Ursache gesucht - das waren immer die gleichen Aussagen). Niemand hat zurückgestellt. Alle Kunden glaubten bisher, der Server wäre "abgestürzt" oder hätte ein Problem. (Dabei war dieser selbst weiterhin erreichbar, nur die entsprechende Kundenseite hat den Fehler ausgegeben.) D.h. die Ursache wurde in 99% aller Support-Anfragen bei uns, also beim Provider gesucht.

"Der Server ist Down!"
"Dringend!"
"Was haben Sie gemacht?"
"Haben Sie an den Seiten manipuliert?"
"Warum ist Ihr Server nicht errichbar?"
"Ich verzichte diesesmal darauf, Sie für die Nicht-Erreichbarkeit in Regress zu nehmen."
" Meine Seite ist schon den halben Tag nicht erreichbar, es kommen keine Bestellungen rein!"
"Sofortige Kündigung!"
"Bei anderen Providern gibt es auch PHP 7.4, dort läuft komischerweise alles!"
"Sie machen sich Schadensersatzpflichtig!"
"Ich verlange die sofortige herausgabe meiner Auth-Codes!"

Das sind nur einige Textauszüge aus den vielen Mails der letzten Tage. Das hat Nerven gekostet...

Über 9000 Webseiten, verteilt auf 54 Server, allerdings "nur" ca. 3500 Kunden. Bei uns läuft das Hosting als Vollzeiterwerb seit 2007 und wir leben ausschließlich allein davon, d.h. auf funktionierende Systeme sind wir angewiesen.

Seit dem der Cache gestern abgestellt worden ist, kam keine einzige Anfrage mehr rein. Mal nebenbei bemerkt, das Problem hat uns bisher leider 2 langjährige (zum Glück nur kleinere) Kunden und einen enormen Support-Aufwand gekostet.

Wir haben nun, um das enorme Support-Aufkommen zu stoppen, überall opcache.enable=0 hinterlegt. Das sollte aber hoffentlich nur eine kurzzeitige Lösung sein, bis es ein Update gibt.

Es sind jeweils versch. PHP-Versionen der einzelnen Kundenprojekte aktiv, z.B. 7.3 oder auch 7.4.

Über eine baldige Lösung würden wir uns freuen.

Was wir nach einigen Tagen festegestellt haben: der Befehl

rm -rf /var/www/<Vertrag>/tmp/*

schafft offensichtlich nur kurzzeitg abhilfe. Die Fehler sind wieder da, selbst wenn man die PHP-Version nicht umstellt. Die Kundenanfragen reißen nicht mehr ab, jetzt sind es fast 200 Anfragen.

Aktueller Fall aus der Praxis: Kunde hat auf PHP 7.4 umgestellt, die Seite war anschließend nicht erreichbar. Erst durch das löschen des alten Cache war alles wieder funktionstüchtig. D.h. wenn LiveConfig diesen Cache automatisch bei einer PHP-Versionsumstellung löschen könnte, wäre alles gut.

Wir hoffen auf ein zeitnahes Update.