Beiträge von weltmeister

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.

Wir hatten gestern auch ca. 40 Mails nur wegen diesem Problem.... und die Lösung ist so einfach!

Ein Test auf 5 weiteren Servern war erfolgreich. Jeweils war dieser Befehl die Lösung und alles ist wieder erreichbar.

kk hat zu 99% die Lösung gefunden: erst der Befehl

Zitat

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

schafft Abhilfe nach einer beliebigen PHP-Umstellung. D.h. der Cache muss gelöscht werden, damit es zu keinen Fehlermeldungen kommt.

Ich habe dies so jetzt auf mehreren Servern getestet und betrachte dies als Lösung des Problems.

@rex: kannst du dies auch probieren und bestätigen?

Wir haben aktuell 52 Server, (verschienene Hardware, teilweise Debian 9, teilweise Debian 10) wo dieses Problem auftritt, allerdings ausschließlich unter PHP 7.4

Kann es evtl. auch den Einstellung in der Datei /etc/apache2/mods-available/fcgid.conf liegen? Wie sind da die empfohlenen Einstellungen für einen fehlerfreien Betrieb, zwecks abgleich?
Ich weiß ansonsten leider nicht mehr, wo man noch suchen sollte. Ein erfahrener externer Admin ist leider auch gescheitert an dieser Sache.

Hier wäre die Plugin-Liste einer betroffenen Installation:

wp-youtube-lyte
wp-vgwort
wp-optimize
wp-gdpr-compliance
wp-external-links
wordpress-seo
webp-converter-for-media
updraftplus
table-of-contents-plus
statify
shortcodes-ultimate
search-meter
post-snippets
plugin-report
header-footer-code-manager
gp-premium
enable-jquery-migrate-helper
cookie-bar
block-options
autoptimize
aawp

Theme: generatepress

Es ist jeweils noch IonCube aktiv (apt install php-7.4-opt-ioncube), weil einige Kunden diese Erweiterung leider benötigen.

Auch auf komplett neu aufgesetzten Servern besteht das Problem leider. (Wurde auf 2 neuen Servern getestet) Ich denke mal, das diese Fehler mit dem Bug zusammenhängen müssen.

Ansonsten laden Sie in die WP-Installation mal ein paar Themes oder Plugins, der Fehler muss dann jedenfalls auftreten.