Wir setzen aktuell Debian 12 ein. Nach meinem Wissen ist PHP 7.x nicht mehr mit Debian 11 bzw. 12 kompatibel. Wir haben dafür bereits einen Legacy-Server mit Debian 10 im Einsatz und wollten diesen eigentlich auf Debian 11 aktualisieren – allerdings lief dort PHP 7.x nicht mehr.
Falls es doch eine Möglichkeit geben sollte, wäre für uns die Kombination aus LC3 und der Option „darf veraltete PHP-Versionen nutzen“ die ideale Lösung.
Hallo zusammen,
wir überlegen, wie wir den Umgang mit alten PHP-Versionen am besten lösen können. Idee:
Auf dem Hauptserver laufen nur aktuelle PHP-Versionen.
Für Kunden, die ihre Website nicht anpassen können oder wollen, soll es einen separaten „Legacy-PHP-Server“ geben, auf dem ältere Versionen (z. B. PHP 7.x) laufen.
Frage:
Lässt sich in LiveConfig die PHP-Ausführung so auslagern, dass ein VHost seine PHP-Anfragen an einen externen PHP-Server weiterleitet?
Und wäre es möglich, im Kunden-Interface nur die jeweils freigeschalteten Versionen anzuzeigen (z. B. aktuelle Versionen standardmäßig, Legacy-Versionen nur bei gebuchtem Zusatzservice)?
Wichtig: Für uns ist es keine Option, einen zweiten Webserver aufzusetzen und die Legacy-Kunden komplett dorthin umzuziehen. Das haben wir aktuell so im Einsatz und es bedeutet: Dateien und Datenbanken müssen verschoben werden, Kunden brauchen neue Zugangsdaten usw. – viel zu aufwändig.
Ein ausgelagerter PHP-Server, an den der Hauptserver nur die PHP-Ausführung delegiert, wäre aus unserer Sicht die deutlich smartere Lösung.
Hat jemand so ein Setup schon umgesetzt oder weiß, ob LiveConfig das unterstützt?
Gibt es auch eine Lösung für 2.x, da wir noch nicht so schnell wechseln wollen. Wir warten mit dem Wechsel noch bis die Kinderkrankheiten beseitigt sind 
Wir haben unser LiveConfig-Backend vor einiger Zeit auf Let’s Encrypt umgestellt. Gestern traten Probleme auf: das Zertifikat war abgelaufen und ein Login ins LC-Backend war nicht mehr möglich.
Nach Recherche haben wir festgestellt, dass das Zertifikat für Port 8443 über die Datei /etc/liveconfig/liveconfig.conf gesteuert wird (http_ssl_certificate = /etc/liveconfig/sslcert.pem). Dieses Zertifikat hängt offenbar nicht mit den Zertifikaten zusammen, die im LiveConfig-Backend für die Domains eingerichtet sind.
In den VirtualHosts wird das Zertifikat genutzt, das im Backend für die jeweilige Domain konfiguriert ist – das gilt aber nur für Port 443, nicht für 8443.
Wir haben das Zertifikat in liveconfig.conf jetzt manuell mit Certbot erneuert. Meine Vermutung ist aber, dass dieses Zertifikat nicht automatisch von LC verlängert wird, anders als die Zertifikate der Kundendomains.
Frage:
Ist es möglich, dass LiveConfig auch für Port 8443 das Zertifikat aus dem Backend automatisch erneuert?
Falls ja: Gibt es eine Anleitung oder empfohlene Vorgehensweise, um das einzurichten?
Kurzfassung:
Ziel ist es, dass für kunden.domain.tld:8443 die Zertifikatsverwaltung von LC genutzt wird, sodass auch dieses Zertifikat automatisch verlängert wird.
Perfekt. Danke das wars
Seit ein paar Monaten wird mein LiveConfig Backend nicht mehr aktualisiert. ist das so gewollt? installierte Version: 2.16.6 (release); Verfügbare Version: 2.17.0-release
in der liveconfig.list habe ich nur das stehen:
deb [signed-by=/usr/share/keyrings/liveconfig-keyring.gpg] http://repo.liveconfig.com/debian/ bookworm php
Früher hat ein apt upgrade und apt upgrade genügt.
Die Änderung von Vertrag zu Benutzer hat das Problem gelöst. Mich wundert das nur, dass das nicht LiveConfig Standard sein soll, da hier von unserer Seite nie was geändert wurde. Und erst durch die Änderung das Schraubenschlüsselsymbol erschien. Siehe Bild:
Das Problem ist aber trotzdem gelöst. Vielen Dank für die Hilfe.
Ja es wird ein include_path eingetragen
php_admin_value[include_path] = ".:/usr/local/lib/php"So ist es auch in den PHP-Einstellungen in LiveConfig eingetragen (Standardeinstellung).
Wenn ich auf FastCGI zurückstelle, funktioniert Roundcube wieder.
In dem Vertrag kommen PHP 8.3.21 und Roundcube 1.6.7 zum Einsatz
ich kämpfe aktuell mit einem sehr hartnäckigen Problem. Roundcube läuft nicht und bringt die Meldung "Fatal error: ini_set/set_include_path does not work." nach der Umstellung von FastCGI zu FPM.
Zur Umgebung:
/var/www/MEIN_HOSTING/apps/roundcube/var/www/MEIN_HOSTING/htdocs/Was ich schon probiert habe:
Meine aktuelle Vermutung:
PHP blockiert ini_set/set_include_path grundsätzlich, wenn open_basedir aktiv ist – selbst wenn die Pfade korrekt sind und auch bei None ändert sich das Verhalten nicht. Offenbar gibt es aber keinen aktiven ini_set-Aufruf im Code mehr (auch nicht in Libraries oder Plugins)
Hat jemand schon mal erlebt, dass Roundcube ohne ini_set-Aufruf trotzdem diesen Fehler bringt? Gibt es noch Tricks, wie ich die Quelle des Fehlers genauer identifizieren kann? Könnte ein PHP-Setting, das ich übersehen habe, das Verhalten noch beeinflussen?
Für jeden Hinweis oder Erfahrungswert bin ich dankbar!
ich habe es nun gelöst, indem ich den Datensatz in Account gelöscht habe und danach den Datensatz in HOSTINGCONTRACTS. Das hat funktioniert.
Es ist keine Datenbank vorhanden und unter /var/lib/mysql/ ist auch kein Verzeichnis vorhanden. es gibt keine Domain, Postfächer, Datenbanken mehr. Alles weg. Und der Kunde lässt sich leider nicht löschen.
in der DBS Tabelle ist der Kunde auch nicht mehr. Einträge zum Kunden sind in folgenden Tabellen vorhanden:
ACCOUNTS
HOSTINGCONTRACTS
LOG
USERS
Anscheinend hab ich einen ganz speziellen fall 
Ich habe beim Kunden alle Verträge, Datenbanken, Postfächer etc. gelöscht. Wenn ich den Kunden löschen möchte kommt folgende Meldung "Um diesen Kunden zu löschen müssen Sie erst alle ihm zugeordneten Verträge löschen." ich habe dann probiert den Datenbankeintrag zu ändern mit:
UPDATE HOSTINGCONTRACTS SET HC_DELETED=0 WHERE HC_DELETED=1;dadurch ist der Vertrag wieder erschienen. Wenn ich den Vertrag nun in LC löschen möchte, wird er nicht gelöscht, sondern HC_DELETED auf 1 gesetzt und der Kunde kann noch immer nicht gelöscht werden.
Eine Reparatur der Datenbank war nicht nötig. Ich habe die Schritte hier befolgt. und beim vierten Punkt ok bekommen. also dachte ich mir, härtere Maßnahmen müssen her. über phpmyadmin wollte ich den Datensatz manuell löschen. Allerdings bekomme ich die Meldung: "#1451 - Kann Eltern-Zeile nicht löschen oder aktualisieren: eine Fremdschlüsselbedingung schlägt fehl (`LIVECONFIG`.`ACCOUNTS`, CONSTRAINT `ACCOUNTS_ibfk_2` FOREIGN KEY (`AC_CONTRACTID`) REFERENCES `HOSTINGCONTRACTS` (`HC_ID`))". Den Datensatz in der Tabelle Account wollte ich nicht einfach löschen, da ich nicht weiß wie sich das auf LiveConfig auswirkt. Wie soll ich weiter vorgehen um den Kunden löschen zu können (und den Vertrag)?
Aktuell gibt es im LC nur den Anbieter Let's Encrypt als Auswahl. Da ja bald die Zertifikatslebensdauer zukünftig verkürzt werden (200 Tage, 100 Tage, 47 Tage) wird es später eine extreme Herausforderung alle Zertifikate aller Kunden jeden Monat manuell zu aktualisieren. Wird es zukünftig hier weitere Schnittstellen geben? bzw. die Möglichkeit eigene hinzuzufügen? Wir beziehen unser Zertifikate von PSW-Group.
FTP (Systembenutzer) = SSH.
Das habe ich probiert. ich bekomme sowohl bei sftp als auch bei ssh "access denied". muss ich in der /etc/ssh/sshd_config noch bestimmte einstellungen vornehmen?
Am Donnerstag haben wir Serverwartung, da kann ich es testen.
EDIT:
Nach Neustart ist das Problem behoben.
Hallo, ich habe leider den Fehler, dass ich keine Änderungen mehr bei unserem eigenen Vertag speichern kann. Sobald ich auf Speichern klicke bekomme ich die Meldung: Ungültige Einstellung für PHP.
PHP kann ich leider nicht einstellen, da ich dort nur "wählen..." zur Auswahl habe. (Siehe Bild)
Wie kann ich das Problem beheben?
