Beiträge von kk

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Version 7.1.24 bzw. 7.2.12 aktualisiert.

Viele Grüße

-Klaus Keppler

Zitat von mhagge

Ich glaube das geht um das Default Server-Zertifikat für SSL für den Webserver - steht in der Liste der SSL-Zertifikate mit der Bemerkung "Default SSL-zertifikat für SNI"

Dieses Zertifikat sollte im Normalfall ohnehin niemand zu Gesicht bekommen (wird ja nur dann ausgeliefert, wenn man per HTTPS auf eine Domain zugreifen will, die zwar in LiveConfig angelegt ist, für die aber kein eigenes Zertifikat existiert). Also über "opportunistisches HTTPS", oder falsche Verlinkung.

Wie auch immer - der Austausch ist sogar noch wesentlich einfacher.

1. im LiveConfig auf den Punkt "SSL-Zertifikate" gehen und dieses Zertifikat zum Bearbeiten anklicken.
2. Bei "Zertifikat-Anforderung (CSR)" auf den Button "erzeugen" klicken, ggf. die Felder ausfüllen. Bei "Common Name" (CN) am besten so was wie "localhost" oder "Default SSL Certificate" eintragen.
3. anschließend im Abschnitt "SSL-Zertifikat (CRT)" auf den Button "selbst unterzeichnen" klicken und den Anweisungen folgen.
4. zum Schluß ganz unten auf den Button "speichern" klicken, um das neue Zertifikat zu übernehmen.

Welches Zertifikat genau? Das von der LiveConfig-Weboberfläche?
Dieses SSL-Zertifikat ist unter /etc/liveconfig/sslcert.pem gespeichert.

Wenn Sie kein "offizielles" SSL-Zertifikat nutzen sondern ein neues selbst-signiertes Zertifikat anlegen möchten, verwenden Sie folgende Befehle:

openssl genrsa 4096 >sslcert.pem
openssl req -x509 -key sslcert.pem -days 730 >>sslcert.pem

Anschließend LiveConfig neu starten.

Zitat von meladelio

Eine Domain xyz.com kann nur einem Webspace (server 1) zugeordnet werden, somit kann mail.xyz.com (Mailserver auf server 2) nicht mehr unter selber domain verwaltet werden.

Da gibt es eine einfache Lösung.
Wird DNS für diese Domain auch durch LiveConfig verwaltet?
Wenn ja:
im LiveConfig den Vertrag öffnen, in dem die Domain (xyz.com) bislang liegt. Eine neue Subdomain "mail" (.xyz.com) anlegen. In den Subdomain-Einstellungen Webspace und E-Mail deaktivieren, und nur einen manuellen DNS-Eintrag (A-Record) mit der IP-Adresse des Mailservers anlegen.

Wenn nein: (externer DNS-Server)
einfach beim DNS-Anbieter eine Subdomain "mail" (.xyz.com) anlegen, dort die IP-Adresse des Mailserver hinterlegen.

Wenn Sie diese neue Subdomain (mail.xyz.com) nun in irgendeinem anderen Vertrag nutzen sollen, fügen Sie die einfach wie eine normale Domain hinzu - als DNS-Server wählen Sie aber dann "externer DNS".

Verstehe ich das also richtig, dass unter mail.xyz.com sowohl E-Mail (Postfix/Dovecot) als auch Webmail laufen soll?

Die einfachste Lösung wäre, Webmail einfach auf einer separaten Subdomain laufen zu lassen ("webmail.xyz.com")...
Ansonsten bliebe nur die Möglichkeit, auf dem Mailserver einen Apache/NGINX aufzusetzen, damit dort ein Webmail gehostet werden kann (wenn man aber einen dedizierten Mailserver betreibt, will man da meistens keinen Webserver mit aufsetzen).

Zitat von Febas

UPDATE:

Anscheinend werden die Rechte auf diesem System falsch gesetzt (Der Ordner wurde automatisch angelegt)

Danke für die Info. Offenbar haben Sie eine recht restriktive umask für Init-Scripte (077 statt 022). Wir prüfen das mal, ggf. werden die Init-Scripte (für non-systemd) noch mal entsprechend angepasst.

Viele Grüße

-Klaus Keppler

Zur Info: die Init-Scripte unserer PHP-Pakete wurden eben aktualisiert.

Hallo,

die PHP-Pakete für Debian/Ubuntu (5.6/7.0/7.1/7.2/7.3) wurden eben aktualisiert - die Init-Scripte unterstützen nun auch den Start von PHP-FPM wenn auf dem jeweiligen System kein systemd installiert ist.
Es wurden also lediglich die Dateien /etc/init.d/php##-fpm modifiziert - mehr ändert sich mit dem Update nicht.

Viele Grüße

-Klaus Keppler

Sehr gute Frage... ich habe auf Anhieb keinerlei Dokumentation dazu finden können.
Rein intuitiv würde ich sagen, dass dieses Limit nur pro Vertrag (= pro opcache.file_cache) Sinn macht - allerdings ist PHP einfach alles zuzutrauen...

Läuft lcsam überhaupt? (ps aux | grep lcsam)
Der lcsam protokolliert seine Meldungen üblicherweise mit in /var/log/mail.log
Falls der nicht mehr läuft kann es sein, dass er z.B. vom OOM-Killer des Kernels abgeschossen wurde. Ich weiß das gerade nicht auswendig, aber so etwas sollte ebenfalls im mail.log bzw. im syslog protokolliert sein.

Zitat von Febas

Der Ordner /var/run/php7.0-fpm/ existiert nicht.

Ich vermute, dass es sich um ein Debian/Ubuntu-System ohne systemd handelt?
Dann erstellen Sie bitte einfach das o.g. Verzeichnis und führen anschließend "/etc/init.d/php70-fpm start" aus - dann sollte es klappen.
Wir aktualisieren in diesen Minuten die PHP-Pakete in unseren Repositories, die genau diesen Fehler beheben (betrifft nur Server ohne systemd).

Diese andere Meldung (mit dem "Error 500") taucht nicht mehr auf?
Ich habe in unseren Testumgebungen keinerlei Probleme mit Opcache.

Erstellen Sie ggf. mal eine phpinfo()-Datei und schicken uns deren komplette Ausgabe (oder einen Link darauf) an support@liveconfig.com, dann vergleichen wir das mal mit unserer Ausgabe.

Keine Fehlermeldung - keine Hilfe möglich...

Hallo,

ab sofort steht LiveConfig v2.7.0 zum Download bereit.

Die wichtigsten Neuheiten sind:

• Web-basierte Inbetriebnahme ("onboarding") zur Konfiguration der Lizenz, Zugangsdaten und Kontaktdaten bei Neuinstallationen
• AutoDeploy für eine vereinfachte automatisierte Installation von LiveConfig
• Unterstützung von PHP-FPM (FastCGI Process Manager)
• Unterstützung von TLS 1.3 in der LiveConfig-Oberfläche (OpenSSL 1.1.1)

Zudem gab es viele kleinere Verbesserungen und Fehlerbehebungen - die vollständige Liste steht wie immer im Changelog.

Aktuell werden unsere PHP-Pakete für Debian/Ubuntu noch mal neu compiliert, da auf Systemen ohne systemd der FPM-Prozess sonst nicht startet (deren Update steht ab morgen Vormittag im Repository).

Das LiveConfig-Update lässt sich wie immer problemlos über die regulären Paket-Updates einspielen (APT/yum/zypper).
Debian 7 ("Wheezy") wird nicht mehr unterstützt.

Viele Grüße

-Klaus Keppler

Zitat von kroerig

ii libpcre3:amd64 2:8.41-1.2+ubuntu16.04.1+deb.sury.org+1

Da haben wir die Ursache schon... Sie haben offenbar die bei Ubuntu mitgelieferte libpcre durch die Version von deb.sury.org ersetzt. Offenbar ist diese aber inkompatibel zur 8.38, daher kracht's bei PHP.
Einzige Frage wäre daher: wenn Sie ohnehin schon PCRE von deb.sury.org verwenden, warum dann nicht auch gleich die PHP-Pakete von dort?

Hmm, auf unserer Ubuntu-16-Testmaschine läuft alles problemlos, auch mit Opcache.
Da die Fehlermeldung auf ein Problem mit PCRE hindeutet, was liefern die folgenden Befehle?

ldd /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so
ldd /opt/php-7.2/bin/php | grep pcre
dpkg -l | grep pcre

Kurze Info: PHP 7.3.0 wurde auf RC4 aktualisiert.

Und: was genau liefert der Befehl "/opt/php-7.2/bin/php -v" ?

Zitat von kroerig

PHP Warning: Failed loading Zend extension 'opcache.so' (tried: /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so (/opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so: undefined symbol: pcre_free), [...]

Das hilft schon mal weiter - das Problem liegt offenbar darin, dass die opcache-Erweiterung nicht geladen werden kann.
Welche Distribution genau nutzen Sie?
Sie könnten testweise mal die Datei /opt/php-7.2/etc/conf.d/opcache.ini bearbeiten und dort die zend_extension-Anweisung auskommentieren, dann sollte es vorerst wieder laufen.

Zitat von RB-Media-Group

wurde bei den ShortTags was verändert, bei einem Kunden funktionieren diese seit dem Update auch nicht mehr, im LiveConfig sind Sie aber aktiviert.

Was genau meinen Sie mit "funktionieren nicht mehr"?
Welche PHP-Version genau?
Welche Linux-Distribution?
Was für ein Update? LiveConfig oder PHP?

Seitens LiveConfig wurde bzgl. short_open_tag nichts verändert.