Je nach Patch-Stand in PHP lässt sich das sogar noch einfacher umgehen:
ini_set('open_basedir', '..');
chdir('..');chdir('..');chdir('..');chdir('..');chdir('..');chdir('..');
ini_set('open_basedir', '/');Ganz unnützig ist open_basedir aber auch wieder nicht, weil es einen anderen (kritischen) Angriffsvektor gibt, der nach meinem Kenntnisstand nur damit umgangen werden kann.
Kleine Preview: so wird beispielsweise ein Backup-Ziel mit Borg konfiguriert:
Und so sehen Zeitpläne aus:
Und wie das aus Benutzersicht aussieht (Verwaltung der Backups, Restore-Jobs etc.) gibt's auch bald zu sehen...
Ich habe eine Hand voll vorheriger Beiträge eben weg-moderiert, da die mit dem Thema überhaupt nichts zu tun hatten.
Bitte immer schön sachlich bleiben. Stichwort "Netiquette" und so.
Zum Backup: das in LiveConfig 2.x enthaltene Backup-System ist eine Beta-Funktion. Diese wird auch nicht weiter unterstützt, sondern durch ein komplett anderes Backupsystem in LiveConfig 3.x ersetzt. Bei einer Multi-Server-Datensicherung gibt es eine ganze Menge Herausforderungen, die nicht ganz trivial sind - u.a.:
Das Alles war mit dem "alten" Backup-System nicht so realisierbar wie wir es ursprünglich geplant hatten. Das neue System macht das.
Zudem greifen wir beim neuen Backup auf vorhandene Tools wie Borg und Restic zurück und machen keine "dummen" FTP-Backups. (wer das zwingend braucht, kann aber auch das haben).
Sehr viele Dinge, die wir mit v3 auflösen, lassen sich in LiveConfig 2.x leider nicht einfach nachrüsten - sonst wäre das selbstverständlich der entspannteste Weg. Wir sind bei vielen Funktionen auf eine grundlegend andere Architektur angewiesen - diese ist wesentlich mächtiger und zukunftsfähiger, aber eben leider Gottes komplett neu.
Wir nähern uns immer mehr der Fertigstellung, aber auf neue (naturgemäß nicht belastbare) Terminankündigungen verzichte ich besser.
Derzeit arbeiten wir an der letzten großen Kernkomponente (der eigentlichen (Sub)Domain-Konfiguration mitsamt automatischem TLS. Ich weiß gar nicht was dabei komplexer ist: das Frontend (in dem wir versuchen, alle überflüssigen Optionen wegzulassen und möglichst viel "automatisch" zu erledigen), oder das Backend (in dem alle noch so undenkbaren Angriffs- und Fehlerfälle abgefangen werden müssen).
Also. Es geht voran. Und jetzt bitte beim Thema bleiben.
Hallo,
es handelt sich da um ein immerhin sehr seltenes Problem (nur bei Migrationen sehr "alter" MySQL-Datenbanken).
Mit der kommenden Version (2.16.1) aktualisieren wir nun das Datenbankformat so, dass die Meldung "Row size too large" da nicht mehr auftreten sollte.
Das Vorgehen wäre wie folgt:1.) folgenden SQL ausführen:
UPDATE LIVECONFIG SET LC_VALUE='0216004' WHERE LC_KEY='dbschema' AND LC_VALUE < '0216004'(ausschließlich in diesem speziellen Einzelfall, weil die o.g. Schemaänderungen ja offenbar bereits durchgeführt wurden)
2.) aktuelle LiveConfig-Preview installieren:
cd /tmp
wget https://repo.liveconfig.com/debian-test/pool/main/l/liveconfig/liveconfig_2.16.1-dev20230711.1_amd64.deb
dpkg -i liveconfig_2.16.1-dev20230711.1_amd64.debDanach sollte LiveConfig die restlichen Schemaänderungen ausführen können und normal starten.
Ggf. hab ich aber PHP auch aus dem PHP Repository von ondrej installiert.
Vorab: Ondrej macht eine tolle Arbeit - insbesondere im Backporting der Patches neuerer Versionen!
Allerdings sind die mitgelieferten systemd-Unit-Files unserer Ansicht nach nicht für Shared Hosting ausgelegt/optimiert, sondern eher für den Fall, dass alles unter "www-data" läuft.
Um die Pakete von deb.sury.org nutzen zu können, muss man die gewünschten PHP-Binaries im LiveConfig registrieren - siehe Anleitung.
Der Codename "php8" ist in dem Fall in Ordnung - das heißt intern so viel wie "die 8er Standardversion von PHP".
Ich verstehe die Fragestellung noch nicht ganz. Geht es um ein Upgrade oder um eine Migration/Umzug?
Es ist immer wesentlich einfacher, einen Server zu aktualisieren, als alles manuell Dienst für Dienst neu aufzusetzen und die Inhalte umzuziehen.
Ubuntu 18 ist auch nicht sooo als dass man sich schämen müsste (bekommt ja auch noch LTS-Support). Ein Upgrade von 18.04 auf 20.04 und anschließend von 20.04 auf 22.04 sollte ziemlich reibungslos ablaufen.
Viele Grüße
-Klaus Keppler
Ja, der Fehler ist bekannt und bereits behoben, die Preview-Version wird heute mit einem entsprechenden Bugfix aktualisiert, in v2.17 ist das dann auch behoben.
Der Fehler tritt nur dann auf, wenn noch eine domain-spezifische manuelle Konfigurationsdatei (~/conf/<domain>.httpd.conf) existiert.
Da das bei Weiterleitungen i.d.R. keinen Sinn macht, dürfte der einfachste Workaround darin bestehen, diese .conf-Datei zu löschen.
Damit in diesem Thread nicht der Eindruck entsteht, dass wir uns in den letzten Wochen nur die Sonne auf den Pelz haben scheinen lassen und Däumchen drehen: dem ist nicht so. 😎
Es gibt täglich Commits im LiveConfig3, aber da diese Version ja noch nicht veröffentlicht ist, macht es auch keinen Sinn einen öffentlichen Changelog zu pflegen. Die REST-API-Doku spiegelt (wie schon mehrfach erklärt) den Stand der fertigen Funktionen wider, und erlaubt somit einen Rückschluss auf den Fortschritt. Aktuell arbeiten wir an der letzten großen Baustelle (Domainkonfiguration - von DNS und DNSSEC über Webspace bis TLS). Da das aber alles "work-in-progress" ist, ist die API dieser Funktionen derzeit noch häufig Änderungen unterworfen.
Würden wir nun z.B. die API-Doku für die Bearbeitung von Domains veröffentlichen und da alle paar Tage Änderungen vornehmen, würden uns die Entwickler an den Hals springen, die auf der Basis schon eigenen API-Code schreiben wollen.
Was genau für eine Kommunikation würden Sie denn erwarten - haben Sie konkrete Beispiele/Wünsche?
Sollen wir mal eine Woche lang protokollieren, was täglich entwickelt/geändert wurde?
Es freut mich sehr dass die neue Version sehnsüchtig erwartet wird - und ich garantiere, dass wir selber diese auch am liebsten schon gestern fertig hätten.
Ab sofort stellen wir ein neues Paket namens liveconfig-keyring bereit, welches die Installation des LiveConfig-Repositories komplett übernimmt.
Der aktuelle Key läuft am 23.03.2024 ab. Für einen reibungslosen Übergang haben wir einen neuen Key vorbereitet, der in diesem Paket bereits enthalten ist.
Alle weiteren Details haben wir auf folgender Seite zusammengefasst:
Wir haben das eben mal durchgetestet und können keine Probleme feststellen.
(Vertrag unter Debian 12 sowohl per Hand als auch per SOAP-API angelegt, Domain hinzugefügt die auf Unterverzeichnis verweist, dort eine index.html abgelegt -> klappt auf Anhieb wie erwartet).
Wenn Sie möchten, schicken Sie eine kurze Mail an support@liveconfig.com, dann kann ich Ihnen unser Testscript zusenden.
Ansonsten wäre interessant, was in /var/log/apache2/error.log protokolliert wird, wenn dieser "Forbidden"-Fehler ausgegeben wird.
Hallo,
unsere PHP-Pakete für Debian/Ubuntu wurden eben in den Versionen 5.6/7.0/7.1/7.2/7.3/7.4 aktualisiert.
Es handelt sich dabei um zurückportierte Bugfixes von Remi Collet.
Soll heißen: diese PHP-Versionen gelten zwar weiterhin als (teil völlig) veraltet und potenziell unsicher, aber manchmal geht's nunmal nicht anders...
Viele Grüße
-Klaus Keppler
PS: wir weisen ja nicht auf jedes einzelne PHP-Update hin, das wir bereitstellen. Aber um das mal in Zahlen zu fassen: für dieses Update wurden 6 PHP-Versionen auf 7 verschiedenen Distributionen und zwei Architekturen compiliert. Es wurden insgesamt 308 .deb-Packages aktualisiert, unser Build-Server war fast einen ganzen Tag lang durchgehend damit beschäftigt. Und da waren PHP 8.0/8.1/8.2 ja noch gar nicht mit dabei.
Die mangelnde Abwärtskompatibilität von PHP ist ein Riesenproblem, und ich weiß nicht wohin der Weg noch führt - werden wir in 10 Jahren dann alle vier Wochen zwanzig PHP-Versionen aktualisieren...?
By the way (especially referring to the well-known XKCD strip): the next major release (v3) will actually make use of diceware-like passwords.
(we even try to support local language dictionaries).
Was für ein Browser ist das denn?
Sind eventuell Adblocker aktiv? Wenn ja, welche?
Ok - Ursache gefunden: unter Debian 12 gibt's keine Log-Datei /var/log/mail.log mehr - daher kann der bisherige lclogsplit dort nichts mehr machen.
Wir arbeiten an einer Lösung. 
lclogparse wird nur dann aktiviert, wenn Postfix durch LiveConfig verwaltet wird. Ist das bei Ihnen der Fall?
Ja, über "Passwort vergessen" wird das derzeit deaktiviert.
Im LC3 wird 2FA dort aus Sicherheitsgründen aber beibehalten - dafür kann dort dann der Admin/Reseller die 2FA über das Bearbeiten des Kunden deaktivieren.
Es gibt ganz unten auf der Seite mit den PHP-Einstellungen noch einen Button "Änderungen übernehmen". Möglicherweise müssen Sie diesen noch anklicken.
Wir wollen damit vermeiden, dass bei jeder einzelnen Änderung _alle_ php.ini-Dateien aller Accounts neu geschrieben werden (das können tausende sein), sondern erst wenn man mit den Änderungen fertig ist.
Aber ich nehme das als Anregung, dass wir das in der nächsten Version besser visualisieren.
System ist ein Ubuntu 20.04LTS mit Liveconfig 2.15.1, [...]
Aktuell ist LiveConfig 2.16.0 
Ich habe das bestimmt schon oft geschrieben, aber gerne nochmal... 
chroot für SSH-User nutzt schon dann nichts mehr, wenn der User eine PHP-Shell ausführt. Hierfür müsste dessen PHP-Instanz nämlich selber wiederum in einer chroot-Umgebung ausgeführt werden. Und das würde bedeuten, dass man nicht nur pro Vertrag mindestens einen FPM-Pool laufen lässt, sondern auch noch eine komplette PHP-Installation pflegt (in welcher Form auch immer: Symlinks, bind-mount, copy, ...).
Und das Ausbrechen aus einer chroot-Umgebung ist zwar nicht trivial, aber auch nicht unmöglich.
Viel wichtiger ist es daher, den Server insgesamt so sauber zu konfigurieren, dass ein User dort keine Informationen findet, mit denen er irgendwas anfangen kann.
LiveConfig konkret kümmert sich darum:
Nach unserem Verständnis kann ein User maximal anhand der /etc/passwd herausfinden, welche Account-Namen auf dem Server vorhanden sind. Sofern die angemessen anonym sind ("web1", "web2", ...) ist das also auch wertlos.
Mit cgroups und bind-mounts gibt es interessantere/mächtigere Werkzeuge als chroot, um Informationen zusätzlich zu filtern. Sobald LiveConfig 3.0 fertig ist, werden wir in dem Bereich verstärkt etwas entwickeln.
Viele Grüße
-Klaus Keppler
Die Liste mit den neuen Beiträgen sollte bis morgen wieder funktionieren. Auch die eine oder andere Style-Kleinigkeit wird derzeit noch korrigiert.
