Beiträge von kk

Das ist sogar schon vorbereitet (sieht man nach einem Session-Timeout, da wird man mit einem URL-Parameter "&from=/liveconfig/..." auf die Anmeldeseite geleitet. Aus irgendeinem Grund wird dieser Parameter nach dem Login aber derzeit nicht ausgewertet - wir prüfen das noch mal.
(ich glaube mich ganz dunkel daran zu erinnern, dass es da um potenzielle XSS-Probleme ging...)

Zitat von Sven_67

3 Jahre später....

Noch immer wird lcsam nach einem reboot nicht gestartet.
Noch immer muss man lcsam manuell starten = -1

Meine LC Version: 2.2.3 (r4343) ( Diese deshalb immer noch, weil ich einfach mal abwarten möchte, was noch so alles nicht funktioniert. )
Mein Server läuft mit: Debian GNU/Linux 8.7 (jessie) in der aktuellen Version

Ich komme da auch nicht so ganz mit...
Debian Jessie hat derzeit Version 8.9 (nicht 8.7), und LiveConfig 2.2.3 ist fast genau ein Jahr alt. Wie sollen sich eventuelle Fehler ohne das Einspielen von Updates beheben?
Eine Liste aller Änderungen, neuen Features und Bugfixes finden Sie mit jedem Release unter https://www.liveconfig.com/de/changelog.

Viele Grüße

-Klaus Keppler

Zitat von aziegler

heißt für alle mit vielen Servern wieder selbst in der sqlite rumbasteln um das überall zu aktivieren?
Manchmal hab ich echt das Gefühl LC wird primär/nur für Gelegenheits-Admins mit 5-10 Servern ausgelegt...

LiveConfig ändert bei bestehenden Installationen im Rahmen eines Upgrades grundsätzlich nichts an der Konfiguration. Wenn der Admin ein neues Feature nutzen will, dann muss er das also ausdrücklich aktivieren - ich denke das ist auch in Ihrem Sinn.

Wenn es darum geht, neue Features automatisiert auszurollen, dann ist das eine andere Sache über die wir gerne diskutieren können.

Viele Grüße

-Klaus Keppler

Zitat von TCRserver

Laut der (an dieser Stelle etwas verwirrenden) NGINX Doku müssen aber die IPv6 Adressen geklammert werden:

Danke für den Hinweis, wurde inzwischen korrigiert (r4695).

Hello,

the PHP packages for Debian/Ubuntu have been updated to version 7.0.24 and 7.1.10.

Best regards

-Klaus keppler

Hallo,

die PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.0.24 und 7.1.10 aktualisiert.

Viele Grüße

-Klaus Keppler

Die Preview wurde eben auf Version v2.5.0-r4692 aktualisiert. Damit wird die NGINX-Konfiguration verbessert:

• falls NGINX durch LiveConfig verwaltet wird, dann wird während des Upgrades eine Datei namens /etc/nginx/conf.d/resolver.conf angelegt. Diese enthält die DNS-Resolver (aus /etc/resolv.conf).
  NGINX löst ansonsten alle Hostnamen (z.B. für Reverse-Proxy URLs) nur einmalig (beim Start/Reload) auf - auf den System-Resolver kann NGINX aus Architekturgründen nicht zurückgreifen...
• die Konfiguration von Reverse-Proxy vHosts wurde verbessert (da gab es unter Umständen Probleme)

Viele Grüße

-Klaus Keppler

Zitat von rob

Wird dann der fix zum entfernen der Dupletten aus der "accesslog.map"-Datei doch nicht in der 2.5.0 erscheinen? Wann ist es geplant?

Dieser Bugfix ist noch einer der Showstopper für v2.5.0, kommt also auf jeden Fall noch in dieses Release.

Das ist insbesondere für Multi-Server-Setups konzipiert (Single-Server ist dann nur eine "Vereinfachung" davon)

Wir sind bereits mitten in der Umsetzung. Backups können künftig wahlweise auf dem Server verbleiben (mit Begrenzung der Anzahl der Backups) oder heruntergeladen werden.
Wir geben die Funktion schrittweise nach Fertigstellung frei (zuerst Webspace, dann Datenbanken, zuletzt E-Mails).

Die Preview wurde eben auf v2.5.0-r4690 aktualisiert.
Darin sind die mit der letzten Preview gemeldeten Fehler behoben, sowie folgende neue Funktionen dazu gekommen:

• Unterstützung von HTTP/2 mit Apache 2.4.17+ und NGINX 1.9.5+
  (kann also ab Debian 9 und Ubuntu 16 genutzt werden)
• verbesserte OCSP-Konfiguration mit Apache 2.3.3+
  (die bisherige Konfiguration war in vielen Fällen wirkungslos, außer man hatte ein Default-SSL-Zertifikat mit gültiger OCSP-URL eingerichtet)

Die Korrektur an den OCSP-Einstellungen wird während des Upgrades automatisch an /etc/apache2/sites-available/000-default.conf vorgenommen.

Um HTTP/2 verwenden zu können muss bei Apache erst das Modul "mod_http2" aktiviert werden (Befehl: "a2enmod http2"). Das aktualisierte LiveConfig-Meta-Paket macht das künftig bei Neuinstallationen automatisch. Wenn mod_http2 zwar vorhanden, aber nicht installiert ist, wird das in der Liste der Apache-Module (Serververwaltung -> Web) entsprechend angezeigt.
HTTP/2 muss zudem separat für die gewünschten IP-Gruppen aktiviert werden (also einfach IP-Gruppe bearbeiten und Checkbox anhaken). SSL und HTTP/2 sind künftig für neue IP-Gruppen standardmäßig aktiviert.
Mit dem Speichern der IP-Gruppen werden alle betroffenen Apache vHosts automatisch aktualisiert - nach spätestens 60 Sekunden kann man das also testen, z.B. unter https://tools.keycdn.com/http2-test

Viele Grüße

-Klaus Keppler

Welches Repository genau haben Sie konfiguriert? (/etc/apt/sources.list.d/liveconfig.list), und welche Distribution verwenden Sie (Xenial oder Jessie)? Das geht aus dem Posting leider beides nicht hervor.

Im Test-Repo (debian-test) gab es mit PHP 7.0 ein Problem, das inzwischen aber behoben sein sollte.

Wir haben nun auch PHP 7.0 für Stretch und Wheezy aktualisiert. Falls es noch irgendwo hakt, bitte kurz melden.

Ok, so wie es aussieht war im Test-Repo zwischenzeitlich das PHP-7.0-Paket für Stretch in das Jessie-Verzeichnis gerutscht. APT aktualisiert die Abhängigkeiten aber nicht so lange sich die Versionsnummer nicht ändert.
Damit das Test-Repo wieder korrekt funktioniert, haben wir das PHP-Paket für Jessie "aktualisiert" (auf 7.0.23-2+jessie1). Es hat sich aber effektiv nur die Versionsnummer geändert, sonst nichts.

Zitat von TCRserver

Bei unserem Test System (Debian Jessie) will er PHP7.0-OPT deinstallieren weil eine Abhängigkeit zu libicu55 und libjpeg8 nicht erfüllt ist.

Das klingt eher so, als wäre für PHP das Stretch-Repository ausgewählt.
Was genau steht bei Ihnen in /etc/apt/sources.list.d/liveconfig.list ?

Hallo,

ab sofort steht eine erste Preview-Version von LiveConfig v2.5.0 bereit.

Eine leider recht zeitraubende Änderung hat komplett "unter der Haube" stattgefunden: die verwendete OpenSSL-Bibliothek wurde von v1.0.2 auf v1.1.0 aktualisiert. Auch wenn das nicht nach viel Arbeit klingt, durch viele inkomplatible und häufig undokumentierte API-Änderungen benötigte das viel Zeit.

Aber nun zu den neuen Features:

• für SSL-Zertifikate wird neben RSA nun auch ECDSA unterstützt (natürlich auch mit Let's Encrypt). Wir haben lange überlegt, ob eine Dual-Konfiguration sinnvoll und notwendig ist, und uns am Ende aufgrund der ziemlich komplexen Konfiguration und noch schwierigeren Fehlersuche im Problemfall dagegen entschieden. Moderne Browser kommen mit ECDSA bestens zurecht (Cloudflare verwendet inzwischen fast ausschließlich ECDSA).
• in der Schnellsuche (Eingabefeld ganz oben rechts) kann nun in der Ergebnisliste über ein per "hover"-Effekt sichtbares Icon direkt eine Session in den entsprechenden Kundenvertrag gestartet werden (spart mind. zwei Mausklicks)
• bei eigenen DNS-Einträgen können nun auch die zunehmend an Bedeutung gewinnenden CAA-Records angelegt werden. Das klappt auch mit "alten" BIND-Servern (ist abwärtskompatibel). Allerdings macht LiveConfig derzeit noch keine Syntaxprüfung für diesen Record, bis zum Release von v2.5.0 kommt das noch.
• wenn eine LiveConfig-Installation aktualisiert wird, dann wird gleichzeitig der neue GPG-Schlüssel für das LiveConfig-Repository installiert (der aktuelle GPG-Schlüssel läuft zum 05.11.2017 ab, wir planen ab dem 01.11. die Repositories und alle Pakete mit dem neuen Schlüssel zu signieren und bereiten deshalb mit diesem Update den Key-Rollover vor)
• Single Sign-On für phpMyAdmin
  Unter https://github.com/LiveConfig/pma-sso stellen wir ein Script bereit, das in eine phpMyAdmin-Installation kopiert werden kann und damit ab LiveConfig v2.5.0 ein Single Sign-On aus LiveConfig heraus erlaubt.
  Im Prinzip ist auf der GitHub-Seite alles im Detail dokumentiert. Wichtig ist, dass in diesem Fall die MySQL-Passwörter dauerhaft in LiveConfig gespeichert bleiben müssen (natürlich verschlüsselt), und dass die Passwörter nicht über den Browser an phpMyAdmin übermitelt werden (das macht unser "Plug-In").

Weitere Features befinden sich gerade noch im Test, Updates folgen also noch.

Viele Grüße

-Klaus Keppler

Zitat von taenzerme

Wie bringe ich LiveConfig denn PHP-FPM bei, u.a. in Verbindung mit nginx?

Das ist derzeit noch nicht möglich (zumindest nicht ohne massiv die Lua-Funktionen umzubiegen).
Was Apache betrifft bietet FPM keinen nennenswerten Vorteil gegenüber FastCGI (eher im Gegenteil).
Für NGINX macht FPM Sinn, da NGINX keine dynamischen Worker-Pools realisieren kann. Hier fehlt seitens LiveConfig aber noch die entsprechende Konfigurationsmöglichkeit.
Das Thema steht auf der ToDo-Liste, einen Termin kann ich aber noch nicht nennen.

Zitat

P.S: Tut sich bei LiveConfig grundsätzlich noch etwas? Das letzte Update ist auch bereits etwas her und ich warte immer noch auf die individuellen SpamAssassin-Einstellungen, die mit 2.4.2 Preview angekündigt wurden - das war am 17. Juli :-/

v2.4.2 wird quasi übersprungen, das nächste Release trägt die Nummer v2.5.0.
Und es hat sich eine ganze Menge getan - alle Details finden sich dann im Changelog.

Serververwaltung -> Web -> IP-Adressen -> (IP-Gruppe bearbeiten). Dort in der DropDown-Box die SSL-Server-Chiffren auf "kompatibel" setzen.

/usr/lib/liveconfig/lua/cron.lua - in Zeile 48 müsste dann so etwas rein wie

fh:write("SHELL=/usr/local/bin/jailshell.sh\n")

Wir werden dafür einfach eine Variable definieren, die man dann optional per custom.lua setzen kann.

Das hat weniger mit LiveConfig zu tun, sondern ist vielmehr allgemein ein Problem mit Jail-Umgebungen.
Auch wenn man das mit Cronjobs in den Griff bekommt, die nächste Lücke wartet bestimmt. Etwa ein Bug in PHP, der open_basedir (mal wieder) umgehen lässt. Oder ein lokaler Kernel-Exploit, der einen Ausbruch aus der chroot-Umgebung erlaubt.
Grundsätzlich sollten Dateien in /etc/ (und nicht nur dort) so abgesichert sein, dass nur authorisierte Benutzer diese lesen dürfen. LiveConfig erzeugt (fast?) alle Konfigurationsdateien bewusst nicht "world-readable". Ich möchte sogar behaupten, dass es keine von LiveConfig erzeugte Datei in /etc/ gibt, die "sensible" Informationen enthält und die irgendein Web-User lesen darf (einzige Ausnahme: /etc/passwd).
SELinux wäre ein prima Ansatz, nur ist das leider so scharf dass ein "normales" Shared Hosting damit praktisch nicht möglich ist.
Eine andere Idee (quasi Weiterentwicklung von SSH-Jails) wäre das CageFS von CloudLinux (mehr dazu demnächst).

Zum aktuellen Cron-Thema: man kann in Crontabs über die Umgebungsvariable PATH= einstellen, mit welcher Shell die Prozesse ausgeführt werden. Eine erste Idee (ungetestet!) wäre, hier ein Wrapperscript festzulegen, welches die eigentliche Shell dann in der Jail des jeweiligen Kunden startet.
(sollte ja genügen, die Shell aus /etc/passwd auszulesen... warum macht Cron das eigentlich nicht selbst?)
Falls das hilft, wäre es für uns keine große Sache, die Erstellung der crontab-Datei entsprechend zu "patchen", damit LiveConfig die PATH=...-Angabe fest in jede Crontab einbaut.

Viele Grüße

-Klaus Keppler