Beiträge von kk

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

Hello,

the PHP packages for Debian were updated to version 7.0.23 and 7.1.9.

Additionally, we now have a PHP 7.1.9 package for Ubuntu 16.04 LTS. More PHP versions and PHP extensions for Ubuntu 16 will follow within the next days.

We do NOT plan to build PHP packages for Ubuntu 17.x, we focus only on the LTS versions.

Best regards

-Klaus Keppler

Hallo,

die PHP-Pakete für Debian wurden eben auf die Versionen 7.0.23 und 7.1.9 aktualisiert.

Außerdem steht ab sofort PHP 7.1.9 auch für Ubuntu 16.04 LTS zum Download bereit. Weitere PHP-Versionen und -Erweiterungen für Ubuntu 16 folgen in den nächsten Tagen.

PHP-Pakete für Ubuntu 17.x sind derzeit NICHT geplant, wir fokussieren uns auf die LTS-Versionen.

Viele Grüße

-Klaus Keppler

Das erste PHP-Paket für Ubuntu 16.04 steht ab sofort bereit (PHP 7.1.9), weitere Versionen und PHP-Module folgen in in den nächsten Tagen.

Viele Grüße

-Klaus Keppler

Zitat von kroerig

Was muss ich ändern, damit Dovecot die Aliases finden und auflösen kann.

Das ist praktisch nicht möglich. Dovecot weiß von den Aliasen nichts, weil diese als Mail-Weiterleitungen in Postfix konfiguriert sind (/etc/postfix/virtual_alias).

Viele Grüße

-Klaus Keppler

Zitat von aziegler

Wir machen das übrigens über DigitalOcean Droplets. Mittels API laufen die dann jeweils unter einer Stunde, macht nur ein paar Kröten pro Monat.

Ja, so etwas ist durchaus attraktiv.
Bei uns löst jeder Commit einen Testbuild auf allen unterstützten Distributionen in allen unterstützten Versionen aus - je nach Aktivität ist das durchaus mehrmals pro Stunde. Für die Entwicklung gibt es zudem nochmal separate vServer mit allen Distri-/Versions-Kombinationen (ich habe inzwischen aufgehört mit zu zählen), die in einem separaten VLAN hängen. Da ist eine "on premise"-Lösung etwas einfacher.

Wir haben letzte Woche einen weiteren Server in Betrieb genommen, auf dem dann auch PHP für Ubuntu gebaut wird. Das dauert aber ein wenig - da steckt noch ziemlich viel Arbeit drin.

Zitat von kroerig

Gleiches dürfte dann auch für die FTP-User gelten, oder?

Bei den Präfixen für FTP-User ist "%c" auch jetzt schon außerhalb des Anfangs erlaubt.

Zitat

Wann soll den dann die Final Version erscheinen?

Wenn sie fertig ist.
Es gab massive Änderungen am "Kernel" (u.a. Umstellung auf OpenSSL 1.1). Inzwischen laufen alle Tests stabil, das Stable-Release wird aber noch ein paar Wochen dauern (ein paar Features sind noch in Arbeit).
Ganz unverbindlich sage ich mal Anfang/Mitte September. Preview voraussichtlich ab nächster Woche.

Ab der nächsten Version (voraussichtlich 2.5.0) muss bei Datenbank-Präfixen das "%c" nun nicht mehr zwangsweise am Anfang stehen. Damit sind dann auch Präfixe wie "usr_%c_" möglich.
Die erste Preview planen wir kommende Woche bereitzustellen.

Viele Grüße

-Klaus Keppler

Zitat von Aybee

Ich wäre ja schon froh wenn Herr KK mal endlich auf Support Anfrage per Mail Antwortet.

Heute zum 3 mal nun eine Anfrage per E-Mail geschickt.

Das sind keine Support-Anfragen, sondern Feature Requests. Diese werden natürlich auch beantwortet - das dauert i.d.R. aber etwas länger.

Zitat von Mogwais

wo finde ich nun ein Anleitung dafür? Ich könnte das wirklich gebrauchen. Ob das nun per Webinterface, DB Eintrag oder CLI passieren muss ist mir dabei egal.

man lcpolicyd

Es kann sooo einfach sein

Um also für den Absender "info@example.org" maximal 5 Mails pro 10 Minuten zu erlauben:

lcpolicyd set info@example.org 10 5

Mit "lcpolicyd dump" kann man die Werte beobachten.

Viele Grüße

-Klaus Keppler

Hello,

the PHP packages for Debian have been updated to version 7.0.22 and 7.1.8.

Best regards

-Klaus Keppler

Hallo,

die PHP-Pakete für Debian wurden eben auf die Version 7.0.22 und 7.1.8 aktualisiert.

Viele Grüße

-Klaus Keppler

Zitat von a-s

Also der Fehler ist folgender in cURL - (60) SSL certificate problem: unable to get local issuer certificate.

Ich habe jetzt die neuste cacert.pem heruntergeladen und nach /etc/ssl/certs/ca-certificates.crt verschoben.

Welche cacert.pem? (also von welcher Quelle?)

Zitat

Die php.ini in der ich gerne den Pfad (curl.cainfo = "/etc/ssl/certs/ca-certificates.crt") zu cURL anpassen würde, lässt sich über die Konsole nicht bearbeiten bzw. ist schreibgeschützt, da diese von LiveConfig verwaltet wird. Ich könnte dies auch über das LC-Admin machen, was ich da allerdings eingeben muss, damit das funktioniert, weiß ich leider nicht.

Es gibt zwei Möglichkeiten:
- in /etc/php5/conf.d/ eine Datei namens z.B. "curl.ini" anlegen und dort die gewünschte Anweisung eintragen, oder
- im LiveConfig in der php.ini-Verwaltung einen neuen Schlüssel namens "curl.cainfo" anlegen, Typ=Text, Wert="/etc/ssl/certs/ca-certificates.crt").
Macht aber beides vermutlich keinen Sinn, weil dann alle anderen CA-Zertifikate nicht mehr anerkannt werden.

Zitat

Meine Frage war: Wie behebe ich das Problem und kann ich dies beheben indem ich das Default-SSL-Zertifikat durch ein echtes SSL-Zertifikat ersetze? Oder bin ich da auf dem völlig falschen Weg und es hat damit überhaupt nichts zu tun?

Ich weiß noch immer nicht welches SSL-Zertifikat Sie meinen und was das mit cURL zu tun hat.
Möchten Sie lokal auf dem Server via cURL auf LiveConfig zugreifen? Welches SSL-Zertifikat (für welchen Dienst) meinen Sie? ...
Unter Debian gibt es einen eigenen Weg, um "eigene" CA-Zertifikate zu installieren (/usr/local/share/ca-certificates/, siehe man-Page zu "update-ca-certificates").

Zitat von a-s

Wie kann ich das Problem mit cURL und den SSL-Zertifikat-Problem beheben.

Welches Problem?