Ändert man den Standard wie beschrieben z.B. von PHP 5.6 auf 7.3 wirkt sich dies
auf alle Domains (auch Bestand) auf, welche die Standard PHP-Version verwenden.
Man müsste vorher für diese Domains explizit die php56 Version setzen und
im Anschluss den Standard umstellen - Darum geht es hier im Thread und um
die dazu notwendigen manuellen Eingriffe in die LC-DB.
(bzw. es geht hier darum, die Funktion in LC zu integrieren)
arghs ja alles klar ..
(auch interessant dass das nur für die 7.2 benötigt wird, die anderen 7.x klappten auch so)
Hallo zusammen,
auf einem debian9 System soll solr für die PHP 7.2 7.3 7.4 Versionen bereitgestellt werden.
Folgende PHP LC Pakete sind installiert:
php-7.2-opt php-7.2-opt-apcu php-7.2-opt-dev
php-7.2-opt-igbinary php-7.2-opt-imagick php-7.2-opt-redis
php-7.3-opt php-7.3-opt-apcu php-7.3-opt-dev
php-7.3-opt-igbinary php-7.3-opt-imagick php-7.3-opt-redis
php-7.4-opt php-7.4-opt-apcu php-7.4-opt-dev
php-7.4-opt-igbinary php-7.4-opt-imagick php-7.4-opt-redis
Für 7.3 und 7.4 klappte es wie folgt ohne Probleme:
/opt/php-7.3/bin/pear channel-update pecl.php.net
/opt/php-7.3/bin/pear install pecl.php.net/solr
echo "extension=solr.so" > /opt/php-7.3/etc/conf.d/solr.ini
/opt/php-7.4/bin/pear channel-update pecl.php.net
/opt/php-7.4/bin/pear install pecl.php.net/solr
echo "extension=solr.so" > /opt/php-7.4/etc/conf.d/solr.ini
Nur für die 7.2 kommt es beim "/opt/php-7.2/bin/pear install pecl.php.net/solr"
beim make am Ende zu folgendem Fehler:
running: make
/bin/bash /tmp/pear/temp/pear-build-rooti41jWS/solr-2.5.0/libtool --mode=compile cc -I. -I/tmp/pear/temp/solr -DPHP_ATOM_INC -I/tmp/pear/temp/pear-build-rooti41jWS/solr-2.5.0/include -I/tmp/pear/temp/pear-build-rooti41jWS/solr-2.5.0/main -I/tmp/pear/temp/solr -I/opt/php-7.2/include/php -I/opt/php-7.2/include/php/main -I/opt/php-7.2/include/php/TSRM -I/opt/php-7.2/include/php/Zend -I/opt/php-7.2/include/php/ext -I/opt/php-7.2/include/php/ext/date/lib -I/usr/local/include -I/usr/include/libxml2 -I/opt/php-7.2/include/php -I/opt/php-7.2/include/php/main -I/opt/php-7.2/include/php/TSRM -I/opt/php-7.2/include/php/Zend -I/opt/php-7.2/include/php/ext -I/opt/php-7.2/include/php/ext/date/lib -I/usr/local/include -I/usr/include/libxml2 -DHAVE_CONFIG_H -g -O2 -c /tmp/pear/temp/solr/src/php7/php_solr.c -o src/php7/php_solr.lo
mkdir src/php7/.libs
cc -I. -I/tmp/pear/temp/solr -DPHP_ATOM_INC -I/tmp/pear/temp/pear-build-rooti41jWS/solr-2.5.0/include -I/tmp/pear/temp/pear-build-rooti41jWS/solr-2.5.0/main -I/tmp/pear/temp/solr -I/opt/php-7.2/include/php -I/opt/php-7.2/include/php/main -I/opt/php-7.2/include/php/TSRM -I/opt/php-7.2/include/php/Zend -I/opt/php-7.2/include/php/ext -I/opt/php-7.2/include/php/ext/date/lib -I/usr/local/include -I/usr/include/libxml2 -I/opt/php-7.2/include/php -I/opt/php-7.2/include/php/main -I/opt/php-7.2/include/php/TSRM -I/opt/php-7.2/include/php/Zend -I/opt/php-7.2/include/php/ext -I/opt/php-7.2/include/php/ext/date/lib -I/usr/local/include -I/usr/include/libxml2 -DHAVE_CONFIG_H -g -O2 -c /tmp/pear/temp/solr/src/php7/php_solr.c -fPIC -DPIC -o src/php7/.libs/php_solr.o
In file included from /tmp/pear/temp/solr/src/php7/php_solr.h:46:0,
from /tmp/pear/temp/solr/src/php7/php_solr.c:21:
/opt/php-7.2/include/php/ext/pcre/php_pcre.h:29:18: fatal error: pcre.h: No such file or directory
#include "pcre.h"
^
compilation terminated.
Makefile:194: recipe for target 'src/php7/php_solr.lo' failed
make: *** [src/php7/php_solr.lo] Error 1
ERROR: `make' failed
Fehlt mir eine Abhängigkeit?
Danke!
Gruß
Thomas
Beides (noch) debian9 Systeme, session-Modul ist aktiv bzw. wurde nicht deaktiviert
und die /opt/php-7.2/etc/conf.d/session.ini ist vorhanden (extension=session.so)
Aber danke für den Hinweis in diese Richtung .. igbinary wurde bereits via pecl
installiert und es gab eine zweite ini welche ebenfalls das igbinary Modul lud.
Ohne das doppelte Laden klappt es nun, Danke!
Hallo,
auf zwei Systemen haben wir die php-7.x-opt-igbinary Pakete für PHP 7.2 7.3 und 7.4 nachinstalliert
und erhalten auf beiden Systemen dabei einen Fehler - Beispiel über die Konsole:
# /opt/php-7.2/bin/php -i > /dev/null
PHP Warning: PHP Startup: Unable to load dynamic library 'igbinary.so' (tried: /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/igbinary.so (/opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/igbinary.so: undefined symbol: ps_globals), /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/igbinary.so.so (/opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/igbinary.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
# /opt/php-7.3/bin/php -i > /dev/null
PHP Warning: PHP Startup: Unable to load dynamic library 'igbinary.so' (tried: /opt/php-7.3/lib/extensions/no-debug-non-zts-20180731/igbinary.so (/opt/php-7.3/lib/extensions/no-debug-non-zts-20180731/igbinary.so: undefined symbol: ps_globals), /opt/php-7.3/lib/extensions/no-debug-non-zts-20180731/igbinary.so.so (/opt/php-7.3/lib/extensions/no-debug-non-zts-20180731/igbinary.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
# /opt/php-7.4/bin/php -i > /dev/null
< kein Fehler, hier passt es>
Fehlt uns hier noch eine Abhängigkeit?
Oder liegt das Problem doch an anderer Stelle?
( siehe Fehlermeldung mit doppelter Dateiendung -> igbinary.so.so: cannot open shared object file: No such file or directory )
Danke,
Gruß
Thomas
Danke für die Info / Rückmeldung dazu!
Hallo,
System ist ein aktuelles debian 10.2 mit lcclient 2.9.1
# dpkg -l | egrep -i "php|xml"
ii libexpat1:amd64 2.2.6-2+deb10u1 amd64
ii libtidy5deb1:amd64 2:5.6.0-10 amd64
ii libxml2:amd64 2.9.4+dfsg1-7+b3 amd64
ii libxmlrpc-epi0:amd64 0.54.2-1.2 amd64
ii php-7.2-opt 1:7.2.25-1+deb10u1 amd64
ii php-7.2-opt-apcu 5.1.18-1+buster1 amd64
ii php-7.2-opt-imagick 3.4.4-1+buster1 amd64
ii php-7.3-opt 1:7.3.12-1+deb10u1 amd64
ii php-7.3-opt-apcu 5.1.18-1+buster1 amd64
ii php-7.3-opt-imagick 3.4.4-1+buster1 amd64
ii php-7.4-opt 1:7.4.0-1+deb10u1 amd64
ii php-7.4-opt-apcu 1:5.1.18-1+deb10u1 amd64
ii php-7.4-opt-imagick 1:3.4.4-1+deb10u1 amd64
# /opt/php-7.4/bin/php -i | grep -i xml
/opt/php-7.4/etc/conf.d/simplexml.ini,
/opt/php-7.4/etc/conf.d/xmlreader.ini,
/opt/php-7.4/etc/conf.d/xmlwriter.ini,
xmlrpc_error_number => 0 => 0
xmlrpc_errors => Off => Off
DOM/XML => enabled
DOM/XML API Version => 20031129
libxml Version => 2.9.4
libxml
libXML support => active
libXML Compiled Version => 2.9.4
libXML Loaded Version => 20904
libXML streams => enabled
mbstring.http_output_conv_mimetypes => ^(text/|application/xhtml\+xml) => ^(text/|application/xhtml\+xml)
SimpleXML
SimpleXML support => enabled
xmlreader
XMLReader => enabled
xmlwriter
XMLWriter => enabled
libxslt compiled against libxml Version => 2.9.4
# /opt/php-7.3/bin/php -i | grep -i xml
/opt/php-7.3/etc/conf.d/simplexml.ini,
/opt/php-7.3/etc/conf.d/xmlreader.ini,
/opt/php-7.3/etc/conf.d/xmlrpc.ini,
/opt/php-7.3/etc/conf.d/xmlwriter.ini,
xmlrpc_error_number => 0 => 0
xmlrpc_errors => Off => Off
DOM/XML => enabled
DOM/XML API Version => 20031129
libxml Version => 2.9.4
libxml
libXML support => active
libXML Compiled Version => 2.9.4
libXML Loaded Version => 20904
libXML streams => enabled
mbstring.http_output_conv_mimetypes => ^(text/|application/xhtml\+xml) => ^(text/|application/xhtml\+xml)
SimpleXML
SimpleXML support => enabled
xml
XML Support => active
XML Namespace Support => active
libxml2 Version => 2.9.4
xmlreader
XMLReader => enabled
xmlrpc
core library version => xmlrpc-epi v. 0.54
homepage => http://xmlrpc-epi.sourceforge.net
xmlwriter
XMLWriter => enabled
libxslt compiled against libxml Version => 2.9.4
Diff PHP 7.3 <> 7.4 sind die Abschnitte:
xml
XML Support => active
XML Namespace Support => active
libxml2 Version => 2.9.4
xmlrpc
core library version => xmlrpc-epi v. 0.54
homepage => http://xmlrpc-epi.sourceforge.net
Gruß
Thomas
Steht das noch auf der Agenda für eine der 2.9.x Versionen?
Wir haben eine Domain (mit ~200 DNS-Records) die wir einem anderen Vertrag (unter der gleichen Kundennummer) zuordnen müssten ..
*push*
Wir nutzen https://www.ssllabs.com/ssltest/ zum Prüfen von Webseiten.
Mit SSL-Server-Chiffren = kompatibel (damit TLS 1.0 und 1.1 aktiv) erhält man
dort die Note A aber mit der Info, dass TLS 1.0 und 1.1 ab 01/2020 mit B bewertet wird.
Schaltet man die SSL-Server-Chiffren auf Strong um, passt die Meldung zur TLS Version
zwar allerdings fehlen dann scheinbar Ciphern (This server does not support Forward Secrecy with the reference browsers. Grade capped to B.)
Frage jedenfalls:
Kommt die Option zum TLS 1.0/1.1 via GUI abschalten noch zeitnah oder muss
man den "Kniff" über die extra httpd.conf gehen?
Danke für das apcu Paket - konnten wir zwischenzeitlich über das normale Repo installieren 
Mit PHP 7.4 haben wir bei Typo3 und Joomla noch festgestellt, dass beide die xml-Extension als fehlend bemängeln.
Stellen wir auf PHP 7.3 zurück, passt die xml-Extension.
Installierte Pakete:
für 7.3 : php-7.3-opt php-7.3-opt-apcu php-7.3-opt-imagick
für 7.4 : php-7.4-opt php-7.4-opt-apcu php-7.4-opt-imagick
phpinfo() für 7.3 zeigt neben xmlreader/xmlwriter/xmlrpc auch einen "reinen" xml und einen xmlrpc -Abschnitt.
In der 7.4 fehlen diese Abschnitt.
Fehlen uns Pakete? Oder fehlt ggf. etwas im php-7.4-opt Paket?
Hallo zusammen,
sofern das nicht nur für uns sinnvoll erscheint:
Praktisch wäre es, wenn man z.B. über die Serververwaltung einzelne
Server als "Voll" bzw. "Nicht verwenden" markieren könnte.
Dieser Server sollte beim Anlegen von Verträgen entsprechend nicht
mehr im Ressourcen-DropDown (Web- DB- Mail-) auftauchen.
Oder ist dies ggf. über die DB bereits machbar?
Gruß
Thomas
Danke für die Info aus der Mail.
Eventuell sollte man die Entscheidung selbst fällen können.
Immerhin gibt es doch schon das Dropdown-Feld, dort müsste nur der LE-Account
des Kunden mit rein und noch die Option geschaffen werden, den default-Wert zu wählen.
So hat man nun:
- LE-Certs für Domains vom Kunden im eigenen Hosting-Bereich sofern man die Domain hinzufügt
- LE-Certs für Domains vom Kunden im Kunden-Bereich sofern der Kunde (oder Admin als Kunde) das Cert aktiviert
- Kunden die dann nur einen Teil Ihrer Zertifikate sehen
- Kunden Zertifikate vermischt mit den eigenen Zertifikaten im eigenen Hosting-Bereich
Hallo zusammen,
ist folgendes Verhalten beim Hinzufügen einer Domain beabsichtigt?
Menü: Kunde -> Kunde wählen -> Domains -> neue Domain
SSL/TLS ist automatisch angewählt.
Aber leider nicht mit dem LE-Account des Kunden bzw. des Vertrags
sondern mit dem LE-Account aus dem Admin bzw. Hosting-Bereich.
Eigentlich wollen wir die Certs für die Kunden-Domains nicht mit unserem LE-Account verwalten.
Sofern der Kunde über einen eigenen LE-Account verfügt sollte dieser verwendet werden.
Ist kein LE-Account vorhanden, sollte ggf. einer erstellt werden?
Bei Kunden die über einen LE-Account verfügen wird dieser auch nicht im Dropdown angeboten.
Gruß
Thomas
*push*
( kk )
Kann eventuell jemand ( kk ?) die SQL Queries prüfen?
Vermutlich geht das ja auch einfacher bzw. in weniger Schritten ..
Wünschenswert wäre eine Lösung durch LiveConfig selbst (ein Script oder ähnliches?)
damit keine manuellen Änderungen in der DB notwendig sind ohne zu wissen
an welcher Stelle ggf. noch etwas geändert oder beachtet werden muss ..
1) Über den Hostname des Webservers die richtige Server-ID ermitteln
Query: SELECT SRV_ID FROM SERVERS WHERE SRV_HOSTID LIKE '%<Hostname/Teil vom Hostname>%';
Ergibt: SRV_ID = 14
2) Anhand der Server-ID die passende Webserver-ID ermitteln
Query: SELECT WS_ID FROM WEBSERVERS WHERE WS_SERVERID = '<ID aus der #1>';
Ergibt: WS_ID = 11
3) Anhand der Webserver-ID die PHP-Versionen und die "PHP-ID" ermitteln
Query: SELECT WR_ID, WR_CODE, WR_VERSION FROM WEBRUNTIMES WHERE WR_SERVERID = '<ID aus der #2>';
Ergibt:
"WR_ID" "WR_CODE" "WR_VERSION"
"23" "php5" "5.6.40"
"24" "php55" "5.5.38"
"25" "php70" "7.0.33"
"57" "php71" "7.1.28"
"97" "php72" "7.2.17"
"152" "php73" "7.3.4"
4) Prüfen was am Server default ist
root@<HOST>:~# lcclient --diag | grep DEFAULT
- PHP 5.6.40 [DEFAULT] (code='php5')
Entspricht der ID 23 aus der #3
5) Domains und PHP-ID ermitteln (IST-Stand)
Query: SELECT SD_HOST, SD_WEBDESTINATION, SD_PHPVERSIONID, SD_WEBSERVERID FROM SUBDOMAINS WHERE SD_WEBSERVERID = '<ID aus der #2>';
Ergibt: Auflistung mit Domain + NULLs in der PHP-ID-Spalte wenn default-PHP-Version gesetzt ist
6) Domains von NULL auf die passende PHP-ID updaten
=> Wurde von mir nicht getestet! Bitte nicht auf einem Produktivsystem testen!
Query: UPDATE SUBDOMAINS SET SD_PHPVERSIONID = <ID aus der #4> WHERE SD_PHPVERSIONID IS NULL AND SD_WEBSERVERID = <ID aus der #2>;
Ergibt: Die PHP-ID anstelle von NULL für die jeweiligen Domains des Servers
7) Den Server auf default v7.3 umstellen
/usr/lib/liveconfig/lua/custom.lua -> LC.web.PHPDEFAULT="php73"
Damit ist php73 Standard und die alten Webseiten laufen mit den jeweiligen PHP-Versionen weiter.
Mein Fehler, proxy_fcgi war nicht geladen, FPM steht nun auch zur Auswahl
Die Umstellung auf debian8 Basis sollte doch ähnlich einfach möglich sein - Oder?
Wird das php5-fpm noch zusätzlich zu php-7.2-opt bzw. php-7.3-opt benötigt?
Muss sonst noch etwas beachtet werden?
Im Vertrag des Kunden haben wir im PHP-Dropdown nur "FastCGI" oder "wählen ..." zur Auswahl.
Bei uns läuft das Zertifikat nun ebenfalls ab.
Die Schritte über CSR erstellen und Cert selbst unterschreiben funktionieren nicht.
Fehler im Log: Unknown CGI variable 'comment' -> always call initForm() before checkForm()!
