Alte PHP Configs löschen

Das ist eine spannende Frage, solche Dinge sollte LiveConfig m.E. eigenständig aufräumen, wenn die entsprechende PHP-Version nicht (mehr) angeboten wird.

LC sollte auch das Mittagessen zubereiten.
Schön wäre es, aber die Dateien kann man nun wirklich selbst automatisiert löschen. Auch hier wäre ein Hinweis im Wiki gut.

Wieso wollt ihr die überhaupt los werden? Die paar KB stören doch wirklich nicht.
Und "kaputt machen" kann damit auch keiner was.

(ja, cleanup wäre schön. aber da gibt es dringlicheres)

Zitat von kroerig

a) Weil es sich so gehört und b) weil selbst root die Dateien nicht so einfach löschen kann.

LiveConfig kann leider nicht wissen, dass Sie eine bestimmte PHP-Version künftig nicht mehr anbieten möchten.

Das Löschen ist denkbar einfach:

cd /var/www
chattr -i */conf/php5/php*
rm -rf */conf/php5

Die entsprechende "php5-fcgi-starter"-Datei wird dann keine PHP-Instanz der gewünschten Version mehr starten können (da diese ja auf ein nicht mehr vorhandenes PHP-Binary zeigt). Ergo wird es einen "500 Internal Server Error" geben.

Es gibt die Möglichkeit, ein "Massen-Update" über die Datenbank durchzuführen (um z.B. alle Kunden von PHP 5.X auf 5.Y umzustellen). Das ist nicht ganz trivial und erfordert die Ausführung einiger SQL-Befehle - bei Bedarf bitte an support@liveconfig.com wenden. Wir planen das in Zukunft über ein Command-Line-Interface (CLI) von LiveConfig zu vereinfachen.

das wäre mittelfristig beides wichtig, ja - sowohl das "festnageln" als auch das setzen eines neuen defaults, sobald man eine PHP-Version entfernt.

aber erst einmal würde ich mich freuen, wenn überhaupt mal wieder ein Release kommt - und ich äußere erneut den frommen Wunsch, dass Bugfix-Releases deutlich schneller erscheinen mögen und features separat entwickelt werden......

Mein Reden. Ich bin sowas von genervt, dass hier immer mal wieder der Indianer aussteigt, nachdem ein Kunde ein LE-Zertifikat eingerichtet hat, was dann plötzlich aber doch nicht da ist, aber im VHOST des Kunden verwendet wird. Und das passiert meist dann, wenn man gerade im Auto sitzt, schläft oder das Handakku leer ist. Und das seit Monaten!

Zitat von WebService4U

Mein Reden. Ich bin sowas von genervt, dass hier immer mal wieder der Indianer aussteigt, nachdem ein Kunde ein LE-Zertifikat eingerichtet hat, was dann plötzlich aber doch nicht da ist, aber im VHOST des Kunden verwendet wird. Und das passiert meist dann, wenn man gerade im Auto sitzt, schläft oder das Handakku leer ist. Und das seit Monaten!

Dieser SSL-Fehler ist ja auch schon seit > 10 Wochen gefixt läuft bei uns auf allen Servern sauber). Das kann man so auch schon in Monaten rechnen

Das schöne an den Lab-Versionen ist, das man Fehler auch melden darf. Und wenn ich "... seit Monaten!" lese, dann frage ich mich natürlich reflexartig, wann denn der Fehler gemeldet wurde?
Eigenlob: Wir hier melden jeden Fehler direkt wenn wir ihn finden, denn nur so kannst Du aus einer Lab auch eine Release machen...

Gruß Ralf

Lab != Stable.
Liveconfig rät ja selber vom produktiven Einsatz einer Labversion ab....... Also vom Prinzip hat er schon recht.

Zitat von Nosxxx

Lab != Stable.
Liveconfig rät ja selber vom produktiven Einsatz einer Labversion ab....... Also vom Prinzip hat er schon recht.

Na, ja. Das ist eher ein Selbstschutz. Wenn in einer Lab irgendwas noch nicht 100% tut, dann ist das eben die Lab, da kann man dem lieben Benutzer dann gerne sagen, das er sich seine 8-Stunden-Frist zur ultimativen Nachbesserung verbunden mit den 10 Mio. Schadensersatz dorthin schieben kann, wo es ganzj.... <zensiert> ist.
Mehr ist es aber auch nicht. Lab heisst ja auch nicht, das das Ding ungetestet auf der Website rumschwimmt. Das ist nur nicht fertig ausgetestet.

Aus meiner Sicht spricht (und wir haben LC seit es LC gibt in der Lab-Version im Einsatz) wirklich nichts dagegen. Eher im Gegenteil. Die Fehler halten sich sehr eng in Grenzen, sind schnell gefixt und mit dem Einsatz sorgst Du auch damit auch noch dafür, das das Ding stabil wird. Du kannst die meisten Fehler eben nicht im Labor / in der Testumgebung abfangen und bist auf den Feldtest angewiesen.

Gruß Ralf

Ich hatte in einem anderen Post schon mal geschrieben, dass ich keine Lab-Versionen produktiv einsetzen würde. Dafür sind Lab-Versionen einfach nicht da, denn wenn das so wäre, dann wären sie stable und nicht lab. Ich finde schon, dass meine Kritik hier sehr berechtigt ist. Eine Softwareentwicklung sollte niemals Bugfixes und neue Features im selben Zweig behandeln. Das ist einer der guten alten Grundsätze in den Entwicklungsworkflows. Ich weiß da wirklich wovon ich rede, mache das selbst lange genug.

Zitat von kk

Das Löschen ist denkbar einfach:

Code

cd /var/www
chattr -i */conf/php5/php*
rm -rf */conf/php5

Reicht nicht.

cd /var/www
chattr -iR */conf/php5/
rm -rf */conf/php5

führte zum Ziel.

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.

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

Zitat

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