Alte PHP Configs löschen

  • Hallo!


    Nach ein paar Updates sammeln sich jetzt die PHP-Configs in den Kundenaccounts. Wie werde ich die wieder los?


    Code
    dr-xr-xr-x 2 web0     web0 4096 Jan 20 02:33 php5
    dr-xr-xr-x 2 web0     web0 4096 Jan 20 02:33 php55
    dr-xr-xr-x 2 web0     web0 4096 Jan 29 00:42 php56
    dr-xr-xr-x 2 web0     web0 4096 Jan 29 00:42 php7
    dr-xr-xr-x 2 web0     web0 4096 Jan 29 00:42 php70


    Aktiv sind nur noch 5.6, 7.(1) und 7.0.


    Klaus Rörig

  • 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.

    # Das Gras wächst nicht schneller wenn man daran zieht # Bitte keine inflationären Vollzitate #

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


    Code
    root@liveconfig01 /var/www/web0/conf # rm -rf php5
    rm: cannot remove 'php5/php.ini': Operation not permitted
    rm: cannot remove 'php5/php-fcgi-starter': Operation not permitted


    Warum? Darum:

    Code
    root@liveconfig01 /var/www/web0/conf # lsattr php5
    ----i--------e-- php5/php.ini
    ----i--------e-- php5/php-fcgi-starter
  • 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:

    Code
    cd /var/www
    chattr -i */conf/php5/php*
    rm -rf */conf/php5
  • Womit wir bei der Frage wären: Was passiert eigentlich, wenn ich eine PHP-Version aus der Konfiguration entferne, Kunden sie also nicht mehr auswählen können?


    Ich kann Kunden ja leider (noch nicht?) verbieten die PHP-Version zu ändern.

  • 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.

  • 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.


    Wenn ich die Version auch vom Server entferne, sonst würde die technich wohl weiterlaufen.


    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.


    Mir würde es ja schon reichen, wenn ich die Kunden auf eine PHP-Version "festnageln" könnte.

  • 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!

  • 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.


    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

    Für Entwickler und Interessierte stellen wir hier die jeweils aktuelle Entwicklungsversion von LiveConfig zum Download bereit. Diese enthält häufig noch nicht fertig gestellte Funktionen oder sonstige Einschränkungen. Für einen produktiven Einsatz ist diese nicht geeignet!


    https://www.liveconfig.com/de/lab


    Da steht es schwarz auf weiß.


    RCs hätte ich keine Bauchschmerzen mit. Hier sind die Funktionen fertig und es geht rein darum im Feldtest die letzten Macken zu finden und auszubüglen, denn der Entwickler rechnet mit allen, nur nicht mit dem Erfindungsreichtum des Endanwenders.


    Aber die Beschreibung oben sagt eindeutig: BETA.


    Das sollten wir aber in ein eigenes Thema auslagern. Hier ging es ursprünglich um PHP Versionen.


  • Das Löschen ist denkbar einfach:

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


    Reicht nicht.


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


    führte zum Ziel.

    # Das Gras wächst nicht schneller wenn man daran zieht # Bitte keine inflationären Vollzitate #

  • 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.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!