PHP: Schwerwiegende Bugs innerhalb von Configs in speziellen Fällen

1)
Standardmäßig sieht LC für die PHP-Einstellung error_reporting den Datentyp String/ Zeichenkette vor. Tatsächlich ist eines Bitmaske die PHP intern als Integer verarbeitet. Wir brauchen in LC einen neuen Datentyp "Bitmaske" und/ oder -weniger fehleranfällig- eine Auswahlliste mit definierten Optionen. Dies muss dann dennoch als Bitmaske/ ohne Quotes in die php.ini-Dateien geschrieben werden. Eventuell lassen sich beide Ansätze sinnvoll mergen.

Gut möglich das die Einstellung error_reporting mit den aktuellen Quotes gar nicht von PHP beachtet wird.

http://php.net/manual/de/error…n.php#ini.error-reporting

Workaround: Einstellung via LC nicht setzen

Fixed: https://www.liveconfig.com/de/…=8883&viewfull=1#post8883

2)
Wenn eine PHP-Einstellung in LC gesetzt ist, aber keine druckbare Zeichen enthält (NULL) schreibt LC in die php.ini Konfiguration jeweils None, was m.E.n. kein funktionierender Ersatz für NULL ist.

Korrekt wäre etwas wie:

geoip.custom_directory =

statt

geoip.custom_directory = None

Habe ich das Verhalten von PHP richtig verstanden hat das auch für einige Crashes beim Starten von php-cgi durch Apache geführt.

Workaround: Einstellung via LC nicht setzen oder validen Wert zuweisen

3)
Auf der Seite Domains bei den Einstellungen einer Domain enthält das Attribut value des <option>-Knotens der Standard-PHP-Version keinen Wert:

<select name="phpversion">
  <option value="">Standard (5.5)</option>
  <option value="cBiy9BRyTGsa">5.3</option>
  <option value="cM5ura3E.fyW">5.4</option>
  <option value="cGf2YBaQMBtD">5.6</option>
</select>

Das führt dazu, dass in der apache.lua beim Schreiben des vhosts ein hartkodierter Pfad zu einem PHP Binary verwendet wird, der in meinem Fall nicht funktioniert und in der PHP-Versionsliste eigentlich ausgeblendet wurde.

-- use another PHP version?
      if php ~= 'php5' then
        fh:write("        FcgidWrapper ", opts.path, "/conf/", php, "/php-fcgi-starter .php\n")
        fh:write("        FcgidWrapper ", opts.path, "/conf/", php, "/php-fcgi-starter .php5\n")
      else
        fh:write("        FcgidWrapper ", opts.path, "/conf/php5/php-fcgi-starter .php\n")
        fh:write("        FcgidWrapper ", opts.path, "/conf/php5/php-fcgi-starter .php5\n")
      end

Wäre es möglich für diese drei Problemstellungen kurzfristig ein Bugfix-Release zu erhalten?

Workaround: Problem tritt nur mit meinem web.lua Patch auf. Ist dieser im Einsatz sollte beim Aufruf von addPHP() keine Prio angegeben werden, sodass dann die älteste PHP-Version Standard wird (Erste <option> im <select>).

Das ist mir erst beim stracen aufgefallen..

Kann das jemand verifizieren?

Zitat

LiveConfig setzt bewusst keine error_reporting-Einstellung, sondern kopiert standardmäßig nur die Werte aus der Standard-php.ini.

Gut, error_reporting zählt für mich (bzw. Kunden) zu einem der wichtigsten Einstellungen warum der Kunde/ Admin PHP-Einstellungen ändern können müsste.

Zu None:
Gut möglich das ich da was verwechselt habe, sorry. In der PHP-Doku wird die Wahrheit stehen. Werde ich noch einmal testen müssen.

Zu der HTML-Sache:
Nach einer Korrektur in meinem LUA-Patch sehe ich das LC nun folgenden Code generiert:

<select name="phpversion">
  <option value="" selected="selected">Standard (5.5)</option>
  <option value="cBiy9BRyTGsa">5.3</option>
  <option value="cM5ura3E.fyW">5.4</option>
  <option value="cGf2YBaQMBtD">5.6</option>
</select>

Zitat

Ist auch kein Fehler, sondern durchaus so beabsichtigt: damit "markiert" LC die Standard-PHP-Version.

Kann ich als Außenstehender nicht nachvollziehen. Ist dafür nicht das selected-Attribut zuständig?

Ich werde in den kommenden Tagen einige Hundert Domains in LiveConfig anlegen. Durch die Sache mit der Auswahlliste wird standardmäßig PHP 5.3 ausgewählt.

Foreman 1.8 mit der neuen Template-Engine werde ich ich vor den ersten Bugfix/ Maintenance Releases noch nicht ausrollen.

Ich schätze in 1.7 wird an der Auswahlliste nicht mehr gearbeitet?

Zitat von kk

An der 1.7 planen wir keine Änderungen mehr, die 1.8 befindet sich dafür in den letzten Zügen

Das ist schade. Die Releases der letzten Monate haben gezeigt das man den Minor-Releases vor der Verwendung ein wenig Zeit zur Reifung geben muss. Ich hoffe also das ich in den nächsten 4-8 Wochen nicht auf gravierende Sicherheitslücken o.ä. stoßen werde und muss wohl bis dahin auf Bugfixes verzichten können.

Zitat von kk

es wird eben die Version standardmäßig ausgewählt, die auf dem Server standarmäßig installiert ist.

Das ist aber nicht die Version die der Benutzer als zu verwendende Version ausgewählt hat! Was nutzt einem Benutzer der Dialog wenn er nicht funktioniert?

Ich kann mich entscheiden: Setze ich in der custom.lua eine Standardversion (prio=0) wird das zwar in der GUI korrekt dargestellt, jedoch wird dann wahlweise ein funktionierendes, defektes oder nicht vorhandenes PHP der Distri verwendet. Setze ich keine Standardversion (gemäß offizieller Doku) wird wegen alphanumerischer/ numerischer Sortierung die kleinste PHP-Version als erste <option> im <select>-Menü, also als Standard vorausgewählt.

Zitat

Ist auch kein Fehler, sondern durchaus so beabsichtigt: damit "markiert" LC die Standard-PHP-Version.

Nochmal: Wenn LC die Benutzerwahl anhand eines value-Attributs mit leerem Inhalt verifiziert dann wird HTML einfach falsch generiert und verarbeitet. Im HTML wird doch bereits das selected-Attribut eingefügt.

http://www.w3.org/TR/2012/WD-h…5/the-option-element.html

Nun kann man natürlich als Standard bzw. erste <option> etwas nehmen wie "Bitte wählen" und hoffen das der Benutzer eine Wahl trifft. Erstens ist das in Sachen Usability so richtig ungünstig und zweitens wird nicht jeder Benutzer wissen welche Version die geeignete ist. Ich als Admin möchte das die Benutzer die jüngste stabile PHP-Version verwenden, also möchte ich eine Version als Standard vorgegeben.

Um es auf den Punkt zu bringen:
Das Setzen einer Standardversion ist aktuell weder offiziell supportet noch technisch implementiert worden (siehe LUA-Patch). Möchte man aber dem Benutzer zusätzliche PHP-Versionen anbieten, jedoch nicht die distributionseigene weil diese bspw. gar nicht existiert (!), hat man ein dickes Problem.

Es würde mich freuen wenn LiveConfig den Standard <option>-Knoten auch mit gefülltem value-Attribut generiert damit _jede_ der auswählbaren PHP-Versionen benutzbar ist.

Schönen Abend.