Verschiedene PHP-Versionen und deren Module

  • Hallo,


    ich möchte gerne verschiedene PHP-Versionen anbieten und dazu die passenden Module. Das einrichten und das switchen funktioniert durch die Anleitung https://www.liveconfig.com/wiki/de/multiphp einwandfrei. Allerdings verstehe ich nicht ganz, wo ich den Ordner der PHP-Module angeben kann?


    Bei mir wäre das:
    /usr/local/php/5.6/usr/lib64/php/modules/
    /usr/local/php/7.0/usr/lib64/php/modules/
    /usr/local/php/7.1/usr/lib64/php/modules/


    Soweit ich weiß muss auch noch unter Admin > Hosting > PHP-Einstellungen die Extension angelegt werden, dennoch spuckt mir "liveconfig --diag" immer folgendes aus:



    Deshalb vermute ich, das man irgendwo den Module Ordner für die verschiedenen Versionen definieren muss .. ;)


    Ein Eintragen des richtigen Pfads in der Modul ini (z.B. /usr/local/php/7.0/etc/php.d/phar.ini) hat da leider nicht geholfen :(

  • Genau. Das verstehe ich ja noch, nur leider bekomme ich weiterhin die obrigen Fehlermeldungen, wenn ich den "liveconfig --diag" Befehl ausführe ...


    Muss vllt. in der "/usr/lib/liveconfig/lua/custom.lua" noch irgendwie der Modulepfad zu den passenden PHP-Versionen eingetragen werden? Denn so wie das ausschaut, guckt dieser immer in "/usr/lib64/php/modules/" nach, was ja falsch wäre da die hier:


    /usr/local/php/7.0/usr/lib64/php/modules/
    /usr/local/php/7.1/usr/lib64/php/modules/


    die richtigen wären .. :S

  • die custom.lua hat damit nichts zu tun.
    Ich würde die Pfadangaben in den jeweiligen ini-dateien angeben


    zb. so
    ein beispiel für die zend.ini in /opt/php5.*/etc/conf.d

    Zitat

    zend_extension=/usr/local/Zend/ZendGuardLoader.so


    oder aber du kompilierst deine php-Versionen mit den gewünschten Pfaden.


    LG


    Thomas

  • Achso
    Das habe ich auch schon probiert, das wird ignoriert :S


    In der php.ini von einem Testweb zeigt auch weiterhin alles auf /etc/php.d, obwohl die Pfade (z.b. für gd > /usr/local/php/7.0/etc/php.d/gd.ini) angepasst worden sind.


    Code
    PHP Version 7.0.17
    System 	Linux liveconfigtest 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 UTC 2017 x86_64
    Build Date 	Mar 19 2017 14:34:35
    Server API 	CGI/FastCGI
    Virtual Directory Support 	disabled
    Configuration File (php.ini) Path 	/etc
    Loaded Configuration File 	/var/www/web110/conf/php70/php.ini
    Scan this dir for additional .ini files 	/etc/php.d
    Additional .ini files parsed 	/etc/php.d/curl.ini, /etc/php.d/dom.ini, /etc/php.d/fileinfo.ini, /etc/php.d/gd.ini, /etc/php.d/json.ini, /etc/php.d/mysql.ini, /etc/php.d/mysqli.ini, /etc/php.d/pdo.ini, /etc/php.d/pdo_mysql.ini, /etc/php.d/pdo_sqlite.ini, /etc/php.d/phar.ini, /etc/php.d/posix.ini, /etc/php.d/soap.ini, /etc/php.d/sqlite3.ini, /etc/php.d/sysvmsg.ini, /etc/php.d/sysvsem.ini, /etc/php.d/sysvshm.ini, /etc/php.d/wddx.ini, /etc/php.d/xmlreader.ini, /etc/php.d/xmlrpc.ini, /etc/php.d/xmlwriter.ini, /etc/php.d/xsl.ini, /etc/php.d/zip.ini


    Komischerweise steht in der php.ini, die sich im conf Ordner unter der passenden PHP-Version berfindet, die Extension drin (habe es mal mit gd und phar probiert)


    gd = /usr/local/php/7.0/usr/lib64/php/modules/gd.so
    phar = /usr/local/php/7.0/usr/lib64/php/modules/phar.so

  • Ne, ich habe nur die RPM's entpackt .. Aber das sollte ja auch funktionieren ;D


    Nö, sollte es nicht.
    Die PHP-Versionen wurden offenbar so compiliert, dass sie in /etc/php.d noch nach zusätzlichen ini-Dateien suchen.


    Also diesen Ordner aufräumen und alle Extensions (warum man das auch immer will) direkt in LiveConfig verwalten, wodurch die Anweisungen mit in die Kunden-php.ini aufgenommen werden.

  • Nö, sollte es nicht.
    Die PHP-Versionen wurden offenbar so compiliert, dass sie in /etc/php.d noch nach zusätzlichen ini-Dateien suchen.


    Also diesen Ordner aufräumen und alle Extensions (warum man das auch immer will) direkt in LiveConfig verwalten, wodurch die Anweisungen mit in die Kunden-php.ini aufgenommen werden.


    ich habe allerdings meine Zweifel, ob da auch alle php-binarys da liegen,wo sie sollen, und nicht die zuletzt installierte die anderen überschrieben hat.


    LG


    Thomas

  • Nö, sollte es nicht.
    Die PHP-Versionen wurden offenbar so compiliert, dass sie in /etc/php.d noch nach zusätzlichen ini-Dateien suchen.


    Also diesen Ordner aufräumen und alle Extensions (warum man das auch immer will) direkt in LiveConfig verwalten, wodurch die Anweisungen mit in die Kunden-php.ini aufgenommen werden.


    Hm könnte sein. Warum? Weil nicht alle Module die sich jetzt in /etc/php.d befinden (PHP5) mit PHP7 und 7.1 funktionieren, da vermutich andere Version der Module ..


    ich habe allerdings meine Zweifel, ob da auch alle php-binarys da liegen,wo sie sollen, und nicht die zuletzt installierte die anderen überschrieben hat.


    Ne die wurden ja getrennt runtergeladen!


    --


    Habe mal Testweise auf einem Testsystem die "/usr/lib/liveconfig/lua/apache.lua" angepasst, so das in der php-fcgi-starter oben "export PHP_INI_SCAN_DIR=/usr/local/php/7.0/etc/php.d/" drin steht. Nun zeigt die PHP-Info alles passend an ..



    Vielleicht habe ich da auch einfach nur ein Verständnisproblem.


    Wie macht ihr das denn mit den Modulen? Ihr habt doch sicherlich nicht nur ein Ordner für die Module, für alle PHP-Versionen oder?

  • Selbst kompelieren, die default php.ini so klein wie möglich halten. Alle Module laden wir per Liveconfig, ob diese nun zum aktivieren/deaktivieren für Kunden freigegeben sind ist wurscht. So lade ich nur noch die Sourcen für die aktuellsten Versionen runter, hau nen configure/make drüber und verteil den Spaß auf alle Systeme. Wozu irgendwelche vorgefertigten Sachen bei denen man 0 Flexibilität hat?


    Wenn ich RPMs lese schätze ich es ist ein CentOS, viel Spaß mit den RPMs. Das wird so nicht klappen da diese viele Verzeichnisse vorgeben und es nicht nur nen schlichtes Entpacken ist.

  • Wie macht ihr das denn mit den Modulen? Ihr habt doch sicherlich nicht nur ein Ordner für die Module, für alle PHP-Versionen oder?


    Jede PHP-Version hat ein eigenes Scan-Dir und somit eigene Module etc, alles getrennt.


    Welche RPM hast du denn da genau runtergeladen? Das sieht nämlich nicht danach aus, dass du die Daten so verwendest, wie das vom RPM vorgesehen ist/war.

  • Wie schon von HBO vermutet ist es ein CentOS. Die RPMs habe ich via --downloadonly aus dem Repository geladen, PHP passend entpackt und da dachte ich, das würde dann funktionieren.


    Nachdem ich aber nun PHP kompiliert und das passende Verzeichnis angegeben habe, funktioniert es!


    Ok das Fazit ist also: PHP kompilieren und alles ist gut! ;) Vielen Dank für die Hilfe/Infos!

Jetzt mitmachen!

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