Verschiedene PHP Installationen und Configs - Fehlende PHP Extensions

[phill54]

Hi,

ich versuch ja grundsätzlich die Übersicht zu behalten.
Ich habe auf meiner DS215j sowohl php56 als auch php70 installiert. Dann habe ich herausgefunden, dass man diverse php-extensions und configs nur über die Installation von "Web Station" auswählen kann - auch wenn man "Web-Station" gar nicht verwenden wollte (...). Dort habe ich in der Oberfläche diverse extensions für php56 angeklickt, die ich teilweise unmittelbar, teilweise nur vielleicht benötige. Dann wollte ich das gleiche für php70 tun und stelle fest, dass dort meine auswahl von php56 übernommen wurde.

Mittlerweile bin ich soweit, dass ich folgendes verstanden habe:
1. Ich habe 3 verschiedene php binaries auf meinem synology

myuser@synology:~$ which php
/bin/php
myuser@synology:~$ which php56
/usr/local/bin/php56
myuser@synology:~$ which php70
/usr/local/bin/php70

2. Meine 3 php installationen verwenden 3 unterschiedliche configs

myuser@synology:~$ php --ini
Configuration File (php.ini) Path: /etc/php
Loaded Configuration File:         /etc/php/php.ini
Scan for additional .ini files in: (none)
Additional .ini files parsed:      (none)

myuser@synology:~$ php56 --ini
Configuration File (php.ini) Path: /usr/local/etc/php56
Loaded Configuration File:         /usr/local/etc/php56/php.ini
Scan for additional .ini files in: /usr/local/etc/php56/conf.d
Additional .ini files parsed:      /usr/local/etc/php56/conf.d/apcu.ini,
/usr/local/etc/php56/conf.d/extensions.ini,
/usr/local/etc/php56/conf.d/opcache.ini

myuser@synology:~$ php70 --ini
Configuration File (php.ini) Path: /usr/local/etc/php70
Loaded Configuration File:         /usr/local/etc/php70/php.ini
Scan for additional .ini files in: /usr/local/etc/php70/conf.d
Additional .ini files parsed:      (none)

Ich hab jetzt noch nicht überprüft ob und welche Änderungen aus der GUI sich auf welche und wieviele Configs auswirken, aber ich habe das Gefühl, da läuft was schief.

Ich wollte also mal wissen wo überhaupt die extensions für php abgelegt sind:

myuser@synology:~$ php -i | grep "modules"
extension_dir => /usr/lib/php/modules => /usr/lib/php/modules

myuser@synology:~$ php56 -i | grep "modules"
extension_dir => /usr/local/lib/php56/modules => /usr/local/lib/php56/modules

myuser@synology:~$ php70 -i | grep "modules"
extension_dir => /usr/local/lib/php70/modules => /usr/local/lib/php70/modules

Und dann hab ich den Inhalt der Ordner überprüft:

myuser@synology:~$ ls -alh /usr/lib/php/modules
total 896K
drwxr-xr-x 2 root root 4.0K Feb  3 04:53 .
drwxr-xr-x 5 root root 4.0K Feb  3 04:53 ..
-rwxr-xr-x 1 root root  25K Jan 26 01:15 bcmath.so
-rwxr-xr-x 1 root root  17K Jan 26 01:15 bz2.so
-rwxr-xr-x 1 root root  73K Jan 26 01:15 curl.so
-rwxr-xr-x 1 root root  33K Jan 26 01:15 iconv.so
-rwxr-xr-x 1 root root  49K Jan 26 01:15 ldap.so
-rwxr-xr-x 1 root root  38K Jan 26 01:15 mcrypt.so
-rwxr-xr-x 1 root root 117K Jan 26 01:15 openssl.so
-rwxr-xr-x 1 root root  20K Jan 26 01:15 pdo_sqlite.so
-rwxr-xr-x 1 root root 236K Jan 26 01:15 phar.so
-rwxr-xr-x 1 root root  21K Jan 26 01:15 posix.so
-rwxr-xr-x 1 root root 8.3K Jan 26 01:15 shmop.so
-rwxr-xr-x 1 root root  70K Jan 26 01:15 sockets.so
-rwxr-xr-x 1 root root  37K Jan 26 01:15 sqlite3.so
-rwxr-xr-x 1 root root  14K Jan 26 01:16 syno_compiler.so
-rwxr-xr-x 1 root root  95K Jan 26 01:15 zip.so

myuser@synology:~$ ls -alh /usr/local/lib/php56/modules/
total 8.0K
drwxr-xr-x 2 root root 4.0K Mar 23  2017 .
drwxr-xr-x 3 root root 4.0K Mar 23  2017 ..

myuser@synology:~$ ls -alh /usr/local/lib/php70/modules/
total 8.0K
drwxr-xr-x 2 root root 4.0K Jan 17 13:33 .
drwxr-xr-x 3 root root 4.0K Jan 17 13:33 ..

Jetzt ist mir klar, warum in meiner php56 Installation nix läuft wie erwartet.
Ich stelle mir jetzt nur die Frage wie ich das Problem lösen kann? Eine De- und Neuinstallation von php56/php70 über die DSM (6.1) Oberfläche belässt alles unverändert. Sind die php-extensions aus /usr/lib/php/modules kompatibel mit php56 und/order php70 ? kann ich die einfach rüberkopieren? Überschreibt mir eine Änderung in der DSM Oberfläche meine angepassten php56 ini-config?

Hintergrund warum ich mich damit beschäftige: ich habe eine composer.phar geladen und wollte von einem Laravel-Projekt die Dependencies updaten.

Die php56 && php70 binaries funktionieren nicht mit meiner composer.phar mangels phar-extension/module

myuser@synology:~/code/laravelproject$ php56 composer.phar update
PHP Fatal error:  Class 'Phar' not found in /volume2/homes/myuser/code/laravelproject/composer.phar on line 23

Fatal error: Class 'Phar' not found in /volume2/homes/myuser/code/laravelproject/composer.phar on line 23
myuser@synology:~/code/laravelproject$ php70 composer.phar update
PHP Fatal error:  Uncaught Error: Class 'Phar' not found in /volume2/homes/myuser/code/laravelproject/composer.phar:23
Stack trace:
#0 {main}
  thrown in /volume2/homes/myuser/code/laravelproject/composer.phar on line 23

Fatal error: Uncaught Error: Class 'Phar' not found in /volume2/homes/myuser/code/laravelproject/composer.phar:23
Stack trace:
#0 {main}
  thrown in /volume2/homes/myuser/code/laravelproject/composer.phar on line 23

Und die php-binary failed am ende mit folgendem Fehler:

myuser@synology:~/code/laravelproject$ php composer.phar update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
[...]
    - psy/psysh v0.8.17 requires nikic/php-parser ~1.3|~2.0|~3.0 -> satisfiable by nikic/php-parser[v1.3.0, v1.4.0, v1.4.1, v2.0.0, v2.0.1, v2.1.0, v2.1.1, v3.0.0, v3.0.1, v3.0.2, v3.0.3, v3.0.4, v3.0.5, v3.0.6, v3.1.0, v3.1.1, v3.1.2, v3.1.3, v3.1.4].
    - psy/psysh v0.8.2 requires nikic/php-parser ~1.3|~2.0|~3.0 -> satisfiabl
    - psy/psysh v0.7.2 requires nikic/php-parser ^1.2.1|~2.0 -> satisfiable by nikic/php-parser[v1.2.1, v1.2.2, v1.3.0, v1.4.0, v1.4.1, v2.0.0, v2.0.1, v2.1.0, v2.1.1].
    - nikic/php-parser v3.1.4 requires ext-tokenizer * -> the requested PHP extension tokenizer is missing from your system.
[...]
    - nikic/php-parser v1.2.1 requires ext-tokenizer * -> the requested PHP extension tokenizer is missing from your system.
    - Installation request for laravel/tinker ~1.0 -> satisfiable by laravel/tinker[v1.0.0, v1.0.1, v1.0.2, v1.0.3].

  To enable extensions, verify that they are enabled in your .ini files:
    - /etc/php/php.ini
  You can also run `php --ini` inside terminal to see which files are used by PHP in CLI mode.

Allerdings ist der Tokenizer default-mässig seit php 4.3 inkludiert (http://php.net/manual/de/tokenizer.installation.php). Demnach wurde er für die php-binary auf synology beim compilieren explizit weggelassen.... hmpf.

Also ich würde mich freuen, wenn jemand einen hilfreichen Tipp hätte

 

[Arni]

Mal ein Schuß ins Blaue: Hast du in der Webstation für die jeweilige PHP Version auch die Module aktiviert?

 

[phill54]

Ja, sorry, ich dachte das ginge aus meinem Text hervor.




Sonderbarerweise wurden die gleichen Erweiterungen, die ich für php56 ausgewählt hatte auch ohne mein zutun automatisch für php70 ausgewählt.

 

[phill54]

Also Zwischenstand: ich hab jetzt den extension_dir pfad von php56/php.ini auf den von php/php.ini umgelegt und aktiv die phar.so eingetragen. jetzt geht zumindest mein "php56 composer.phar update"-command. Schmutzig finde ich das allerdings schon. Hat da sonst jemand Erfahrung? Mit php70 hab ichs nicht probiert, ich gehe aber auch davon aus, dass die binary für php56 nicht mit php70 kompatibel ist...

 

[Frogman]

Für diejenigen, die hier auch mal in der beschriebenen Situation sind - mir sind gerade, nachdem ich vom bewährten DSM5.2 auf die 6.1 hochgezogen bin, die gleichen Probleme begegnet (insbesondere zur Aktivierung des Redis-Moduls).
Es hilft, für die jeweiligen PHP-Installationen eine Datei /usr/local/etc/php56/conf.d/user-settings.ini bzw. /usr/local/etc/php70/conf.d/user-settings.ini anzulegen und dort die relevanten Module bzw. auch spezifische open_basedir hineinzuschreiben:

PHP56

open_basedir = Null

extension = apcu.so
extension = bcmath.so
extension = bz2.so
extension = calendar.so
extension = curl.so
extension = dba.so
extension = exif.so
extension = ftp.so
extension = gd.so
extension = gettext.so
extension = gmp.so
extension = iconv.so
extension = imap.so
extension = intl.so
extension = ldap.so
extension = mcrypt.so
extension = mssql.so
extension = mysql.so
extension = mysqli.so
extension = openssl.so
extension = pdo_dblib.so
extension = pdo_mysql.so
extension = pdo_pgsql.so
extension = pdo_sqlite.so
extension = pgsql.so
extension = phar.so
extension = posix.so
extension = redis.so
extension = shmop.so
extension = soap.so
extension = sockets.so
extension = sqlite3.so
extension = sysvmsg.so
extension = sysvsem.so
extension = sysvshm.so
extension = wddx.so
extension = xmlrpc.so
extension = xsl.so
extension = zip.so

PHP70

open_basedir = Null

zend_extension = opcache.so
zend_extension = xdebug.so

extension = apcu.so
extension = bcmath.so
extension = bz2.so
extension = calendar.so
extension = curl.so
extension = dba.so
extension = exif.so
extension = ftp.so
extension = gd.so
extension = gettext.so
extension = gmp.so
extension = iconv.so
extension = imap.so
extension = intl.so
extension = ldap.so
extension = mailparse.so
extension = mcrypt.so
extension = memcached.so
extension = mysqli.so
extension = openssl.so
extension = pdo_dblib.so
extension = pdo_mysql.so
extension = pdo_pgsql.so
extension = pdo_sqlite.so
extension = pgsql.so
extension = phar.so
extension = posix.so
extension = redis.so
extension = shmop.so
extension = soap.so
extension = sockets.so
extension = sqlite3.so
extension = ssh2.so
extension = sysvmsg.so
extension = sysvsem.so
extension = sysvshm.so
extension = wddx.so
extension = xmlrpc.so
extension = xsl.so
extension = zip.so

 

[sector]

Hi,

ich habe das Problem mit den Libraries mcrypt.so & mysql.so. Die Libraries benötige ich für Nextcloud

Geht dieses Vorhaben immernoch? Habe aktuell installiert: DSM 6.2.3-25426 Update 2

 

[Fusion]

Was für ein Problem hast du denn?
Bekommst die Module im PHP Profil nicht aktiviert?

 

[sector]

Je nachdem, in der DSM oberfläche, tauchen die Module gar nicht auf.

Ich möchte bei #Nextcloud ne app installieren über php72 occ dann kommt der Fehler:

But now, even if in the /etc/php/php.ini file 512MB is configured, I recieve the following error:
php72 occ help
PHP Warning: PHP Startup: Unable to load dynamic library 'mcrypt.so' (tried: /usr/local/lib/php72/modules/mcrypt.so (/usr/local/lib/php72/modules/mcrypt.so: cannot open shared object file: No such file or directory), /usr/local/lib/php72/modules/mcrypt.so.so (/usr/local/lib/php72/modules/mcrypt.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'mysql.so' (tried: /usr/local/lib/php72/modules/mysql.so (/usr/local/lib/php72/modules/mysql.so: cannot open shared object file: No such file or directory), /usr/local/lib/php72/modules/mysql.so.so (/usr/local/lib/php72/modules/mysql.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0

 

[Fusion]

Php72?
Welche App? Ist diese nicht über die nextcloud Gui verfügbar?
Wie/wo und welche Version von nextcloud?
Wie lauten die kompletten Befehle die du absetzt?
Empfiehlt sich teils absolute php Pfade und die passenden ini/confs mit in die Befehle zu packen damit der Kontext stimmt.
MySQL ist normal pdo_mysql und verfügbar.
Mcrypt ist in der normalen Auswahl nicht vorhanden. Müsste ich aber selbst erst schauen, in welcher Version es vielleicht wenigstens noch per config aktivierbar ist

 

[Waldschrat]

Hallo Fusion. Ich habe sie selben Probleme.
wenn ich php74 -i|grep memory absetze bekomme ich:

PHP Warning: PHP Startup: mcrypt: Unable to initialize module Module compiled with module API=20131226 PHP compiled with module API=20190902 These options need to match in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library 'mysql.so' (tried: /usr/local/lib/php74/modules/mysql.so (/usr/local/lib/php74/modules/mysql.so: cannot open shared object file: No such file or directory), /usr/local/lib/php74/modules/mysql.so.so (/usr/local/lib/php74/modules/mysql.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0 memory_limit => 1024M => 1024M Collecting memory statistics => No

Ich komme hier nicht weiter. In Nexcloud ist die Updatefunktion ausser BEtrieb und ich vermute, dass es am fehlenden mcrypt.so liegt.
Eine Suche danach ergibt folgendes Ergebnis:

/usr/local/lib/php74/modules/mcrypt.so /volume1/@appstore/PHP7.4/usr/local/lib/php74/modules/mcrypt.so

Die /usr/local/etc/php74/conf.d/user-settings.ini enthält:

open_basedir = /volume1/@appstore/PHP7.4/usr/local/lib/php74/modules zend_extension = opcache.so zend_extension = xdebug.so extension = apcu.so extension = bcmath.so extension = bz2.so extension = calendar.so extension = curl.so extension = dba.so extension = exif.so extension = ftp.so extension = gd.so extension = gettext.so extension = gmp.so extension = iconv.so extension = imap.so extension = intl.so extension = ldap.so extension = mailparse.so extension = mcrypt.so extension = memcached.so extension = mysqli.so extension = openssl.so extension = pdo_dblib.so extension = pdo_mysql.so extension = pdo_pgsql.so extension = pdo_sqlite.so extension = pgsql.so extension = phar.so extension = posix.so extension = redis.so extension = shmop.so extension = soap.so extension = sockets.so extension = sqlite3.so extension = ssh2.so

 

[Fusion]

Ich habe jedem vHost ein PHP-Profil zugeordnet.
Für Nextcloud habe ich kein mcrypt bzw. auch sonst nirgends mehr drin.
/var/packages/WebStation/etc/php_profile/<string>/conf.d/user_settings.ini

 

[Ulfhednir]

@Waldschrat Im anderen Thread wurde ja bereits mitgeteilt, dass mcrypt seit PHP > 7.1 deprecated ist und anstelle dessen auf OpenSSL gesetzt werden sollte. Wenn du also eine Komponente verwendest, welche auf mcrypt setzt, dürfte diese in Sachen Sicherheit und Wartung nicht mehr state of the art sein. Ein Einsatz halte ich persönlich für bedenklich und für vergebene Liebesmüh.

 

[Waldschrat]

@Fusion: Da steht bei mir auch kein "mcrypt.so" mehr drin. Umso mehr frage ich mich woher mein php74 meint sich ein mcrypt.so laden zu müssen.
@Ulfhednir: Danke für den Hinweis. Gibt es irgenwo eine Anleitung wie ich OpenSSL für mein php74 konfigurieren kann?

 

[Fusion]

Woher stammt die letzte Liste? Extension = mcrypt.so?

Wird schon irgendeine Änderung an Configs gewesen sein wo das jetzt drin steht, aber nicht mehr vorhanden ist / geladen werden kann.
Weißt du hoffentlich am besten wo du überall Hand angelegt hast.
Ansonsten vielleicht mal php74 neu installieren und Profile neu erstellen.

Openssl ist meines Erachtens auch nur ein Module. Was benutzt wird hängt am Ende vom php Profil und vorrangig von der Web Anwendung (Bsp nextcloud) ab.

 

[Ulfhednir]

@Ulfhednir: Danke für den Hinweis. Gibt es irgenwo eine Anleitung wie ich OpenSSL für mein php74 konfigurieren kann?

OpenSSL kannst du als Modul im PHP-Profil aktivieren. Hier muss aber die Software gleichziehen und auf die spezifischen PHP-Funktionen setzen.
Sonst hast du damit auch nichts gekonnt.

 

[Waldschrat]

@Fusion: Die Liste ist aus /usr/local/etc/php74/conf.d/user-settings.ini. Wenn ich "mcrypt.so" angebe bekomme ich die Meldung über unterschiedliche "mcrypt.so"-Versionen auch wenn ich die Zeile mit "extension = mcrypt.so" lösche.
Eine Neuinstallation von php74 habe ich bereits durchgeführt.

@Ulfhednir: openssl ist tatsächlich im PHP-Profil aktiviert und lt. "php74 -i" auch aktiv.

Jetzt suche ich mir nur noch einen Wolf wo noch ".ini"-Dateien liegen könnten die auf "mcrypt.so" verweisen. Das selbe Problem gibt´s auch mit "mysql.so". In meinen ".ini" Dateien habe ich nur "mysqli.so" und das funktioniert auch gut.

user@DiskStation:~$ php74 --ini
PHP Warning:  PHP Startup: mcrypt: Unable to initialize module
Module compiled with module API=20131226
PHP    compiled with module API=20190902
These options need to match
 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 'mysql.so' (tried: /usr/local/lib/php74/modules/mysql.so (/usr/local/lib/php74/modules/mysql.so: cannot open shared object file: No such file or directory), /usr/local/lib/php74/modules/mysql.so.so (/usr/local/lib/php74/modules/mysql.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Configuration File (php.ini) Path: /usr/local/etc/php74/cli
Loaded Configuration File:         /usr/local/etc/php74/cli/php.ini
Scan for additional .ini files in: /usr/local/etc/php74/cli/conf.d
Additional .ini files parsed:      /usr/local/etc/php74/cli/conf.d/extension.ini,
/usr/local/etc/php74/cli/conf.d/phpMyAdmin.ini,
/usr/local/etc/php74/cli/conf.d/timezone.ini

EDIT:
Problem gelöst. Die fehlerhaften Aufrufe standen in /usr/local/etc/php74/cli/conf.d/phpMyAdmin.ini. Nachdem ich dort sowohl "mcrypt.so" als auch "mysql.so" gelöscht hatte gibt es beim Aufruf von "php74" keine Warnings mehr. "phpMyAdmin" läuft trotzdem fehlerfrei.
Danke für die Unterstützung!

 

[Ulfhednir]

Ich kann die Bemühungen nicht wirklich nachvollziehen. mcrypt wird von PHP nicht mehr unterstützt. Was du dort zu finden magst, dürften Artefakte von Synology sein. Die Komponenten wurden scheinbar nicht vom Source entfernt - das reine Vorhandensein dürfte keine Garantie darstellen, dass das überhaupt noch funktioniert.

Unabhängig davon: Schau doch einfach auf den Timestamp. Du versuchst hier 9 Jahre alten, verwaisten Source zu verwursten, welcher als Abandonware markiert ist. Was Abandonware ist, sagt dir Wikipedia: "Als Abandonware bezeichnet man Software, die ein Hersteller nicht mehr vertreibt und für die er keine technische Unterstützung mehr anbietet."

Unter Anbetracht der Erfahrungen mit log4j und Co. muss man hier auch sagen, dass die Verwendung grob fahrlässig ist.

 

[Fusion]

Er will doch gerade mcrypt loswerden und nicht weiter verwenden.... Oder nicht?

Hattest du phpmyadmin noch installiert?
Das erst mal deinstallieren bevor man einzelne Module von Hand irgendwo löscht?
Falls nicht mehr, ist natürlich ätzend und irgendwie immer unsicher, ob man hinter Synology gut genug hergekehrt hat.

 

[Ulfhednir]

Das klang hier etwas anders. Leider hat sich Waldschrat auch nicht wirklich dazu geäußert, warum und weshalb er sich überhaupt mit mycrypt auseinandersetzen muss. Aufgrund #9 hatte ich jedenfalls die Annahme, dass er ein Plugin o.ä. für NextCloud verwenden möchte, welches auf mycrpt-Funktionen zurückgreift.

 

[Fusion]

Hatte ich auch gelesen und von der zeitlichen Abfolge auf ein Wandel in der Einstellung geschlossen... Ich sollte nicht so viel spekulieren.
Abwarten, Tee trinken.