Beiträge von kk

Ich denke das sollte machbar sein, dass man eine bestimmte PHP-Version als Standard für neue Domains auswählt.
Wir müssen uns aber dann noch etwas einfallen lassen, wie man solche festgelegten PHP-Versionen später "upgradet".
Beispiel: eine neue Domain wird heute angelegt, als PHP-Version wird (automatisch) 7.2 festgelegt.
Nun kommt einige Monate später PHP 7.3 raus...
Aus unserer Sicht ist es ein Unterschied, ob eine Domain die "Standard-PHP-Version" hat, oder eine bestimmte Version festgelegt hat (z.B. weil die Software das so erfordert).
Vermutlich wird das auf ein neues Flag in der Datenbank hinauslaufen, mit dem gespeichert wird, ob die eingestellte Version explizit oder als Standardeinstellung gewählt wurde.
Theoretisch wäre es dann auch möglich, eine Einstellung wie "immer die neueste PHP-Version" umzusetzen.

Die automatische Registrierung läuft so ab, dass das Paket künftig eine Datei namens /etc/liveconfig/lua.d/php##.lua erzeugt. LiveConfig liest diese dann beim Start automatisch ein.

Somit ist es rein technisch kein Problem, diese Pakete auch auf "Nicht-LiveConfig-Servern" zu installieren, und das belassen wir auch so.

Hello,

the PHP packages for Debian/Ubuntu have been updated to version 5.6.34, 7.0.28, 7.1.15 and 7.2.3.
Additionally, the APCu and ImageMagick extensions are now also available for PHP 7.2 as well as for all Ubuntu PHP packages (7.0/7.1/7.2).

In presumably 3-4 weeks we'll update these packages once again to support automatic registration with LiveConfig (will be supported with LC 2.6).

Best regards

-Klaus Keppler

Hallo,

die PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 5.6.34, 7.0.28, 7.1.15 und 7.2.3 aktualisiert.
Außerdem stehen nun die APCu- und ImageMagick-Erweiterungen auch für PHP 7.2 sowie für alle Ubuntu-PHP-Pakete (7.0/7.1/7.2) bereit.

In voraussichtlich 3-4 Wochen werden wir diese Pakete noch mal aktualisieren, damit diese sich dann automatisch bei LiveConfig registrieren können (wird dann ab LC 2.6 unterstützt).

Viele Grüße

-Klaus Keppler

Existiert die /etc/apache2/conf-available/liveconfig.conf?
Wenn ja, dann den Befehl "a2enconf liveconfig" ausführen - das sollte den Symlink erzeugen.
Entweder ist beim Upgrade was schief gegangen, oder Apache wurde zwischenzeitlich gelöscht und neu installiert...

Naja, die erste Frage wäre dann natürlich, ob denn Statistikdateien existieren (/var/www/<Vertrag>/logs/access.log)

Wenn nicht: existiert die Datei /etc/apache2/conf-enabled/liveconfig.conf? (Symlink auf /etc/apache2/conf-available/liveconfig.conf)

- entfernen Sie am besten das Paket "libapache2-mod-php7.0" wieder
- installieren Sie das Paket "php7.0-cgi"
- starten Sie LiveConfig neu (damit die geänderte PHP-Installation erkannt wird)
- wenn Sie Hosting-Angebote angelegt haben, bearbeiten Sie diese und stellen dort PHP auf "FastCGI" um
- angelegte Verträge müssen ggf. auch bearbeitet und dort PHP auf FastCGI umgestellt werden.

Sie machen nichts falsch.
In dem Screenshot wird gezeigt, welche Apache-Module aktiviert sind. In dem Fall ist eben kein mod_php aktiviert (was soweit auch gut und richtig ist).

Mit der nächsten LiveConfig-Version (v2.6) wurde diese Anzeige etwas umgestaltet, um Verwirrung zu vermeiden.

Zitat von bfal

denn im Grunde sind alle veraltet.

WordPress, Joomla und RoundCube sind alle auf dem aktuellen Stand (das betrifft also >90% aller Installationen). Für Drupal gibt's voraussichtlich heute ein Update (da gibt es erst seit einigen Tagen eine neue Version).
Für die ganze "neue Generation" vieler Apps wird oftmals PHP7 benötigt, was auf Distributionen wie Debian 7/8, Ubuntu 14 und CentOS nicht zur Verfügung steht. Wir ändern in dem Zusammenhang derzeit die Verwaltung von PHP-Interpretern, so dass der AppInstaller "weiß" welche zusätzlichen PHP-Versionen bereitstehen und entsprechend inkompatible Anwendungen dann ausblenden kann.

"Service unavailable" bedeutet in dem Zusammenhang meistens, dass der Prozess "clamd" (bzw. "clamav-daemon") nicht läuft.
Warum der nicht mehr läuft (bzw. seinen Dienst eingestellt hat) lässt sich eventuell über die einschlägigen Log-Dateien herausfinden.

Kürzlich gab es einen kritischen Bug im ClamAV-Daemon, über den man mit einer einzigen (präparierten) E-Mail den ClamAV abstürzen lassen konnte. Inzwischen stehen aktualisierte Debian-/Ubuntu-Pakete dafür bereit, die aber i.d.R. nur über das "updates"-Repository installiert werden (nicht über "security").

Viele Grüße

-Klaus Keppler

Zitat von kroerig

wie weit ist LC auf die neue DSVGO vorbereitet?

Bis auf das Löschen von unbenutzten Handles (aktuell in Arbeit) sehen wir derzeit keine Konformitätsprobleme seitens der Software. Wir werden in den nächsten zwei Monaten aber noch eine Herstellererklärung vorbereiten, die genau darlegt, welche Daten wo gespeichert und welche Daten an uns übermittelt werden.
(vorab schonmal: da LiveConfig absolut keine Daten außer der Lizenznummer an uns sendet, ist das äußerst unproblematisch. Bei anderen Panels ist die Situation nicht ganz so einfach ;-))

Zitat

Was mir da so spontan einfällt, wären die Loggingeinstellungen der einzelnen über LC konfigurierten Dienste (Webserver, Mailserver).

Die Konfigurationsmöglichkeiten werden wir im Handbuch ggf. näher beschreiben.

Zitat

Wie kann ich z.B. in LC einstellen dass Postfix, Dovecot und Apache keine vollständigen IP-Adressen/ E-Mail-Adressen mehr loggen? Und das (auch) benutzerbezogen?

Was Apache betrifft, können Sie das aktuell schon pro Angebot oder Vertrag einstellen (Tab "Log-Dateien", Einstellung "Log-Anonymisierung"). NGINX-Logs werden ab v2.6 auch durch LiveConfig geschrieben (und ggf. mit Apache-Logs zusammengeführt), da gilt dann das selbe.
Postfix/Dovecot protokolliert ja nur Aktionen "eigener" Kunden, eine Anonymisierung ist da wenig zielführend und widerspricht dann z.T. anderen gesetzlichen Anforderungen (TKG, TKÜV).

Die größte Herausforderung bei der Umsetzung der DSGVO sind eher die Prozesse im Unternehmen. Viele Fachzeitschriften bringen da aktuell Schwerpunktthemen, welche einen guten Überblick verschaffen.
Ansonsten empfehlen wir, sich gezielt beraten zu lassen (z.B. bei PSW und/oder einem entsprechenden Fachanwalt).

Viele Grüße

-Klaus Keppler

Erzeugen Sie einfach einen neuen 1024-Bit DKIM-Schlüssel - der vorherige 2048-Bit-Schlüssel wird automatisch ersetzt.

In der Tat beschreibt das auch ganz gut die Feature-Wünsche, die bei uns am häufigsten nachgefragt werden.
Die meisten der o.g. Punkte sind im nächsten Update (v2.6) bereits enthalten, etwa zum CloudFest herum wird diese zumindest als Preview freigegeben.
(die Begrenzung ausgehender Mails fehlte in der Liste noch - die wird in 2.6 auch in die GUI integriert sein)

Zitat von aziegler

Wird das dokumentiert, sodass man das auch in eigenen PHP-Builds so machen kann?

Ja, natürlich.
Voraussichtlich muss nur eine einzelne Datei zusätzlich ins Paket aufgenommen werden (etwa in der Form "/etc/liveconfig/lua.d/php-x.y.lua").

Schicken Sie uns bitte eine kurze Mail an support@liveconfig.com - wir würden Ihnen dann morgen eine Debug-Version schicken, welche den SSL-Handshake detaillierter protokolliert.

Zitat von Ultrashadow

Auch das ist getestet und hier sind die Ergebnisse

Code

[user@host ~]# sudo su -s /bin/bash liveconfig
bash-4.2$ pwd
/var/lib/liveconfig
bash-4.2$ openssl s_client -connect acme-v01.api.letsencrypt.org:443
Verify return code: 0 (ok)

Bei dem o.g. SSL-Befehl muss es erheblich mehr Output geben als nur "Verify return code: 0". Bitte schicken Sie uns mal die gesamte Ausgabe dazu, dazu noch die Ausgabe von "openssl version".

Zitat

Tatsächlich hat LiveConfig in einigen Ordnern keine Execution-Rechte, im Home unter /var/lib/liveconfig sowie unter /srv/www/liveconfig aber schon. Für mich lässt sich hieraus kein Problem erschließen.

Was meinen Sie mit "in einigen Ordnern"? Haben Sie einige Berechtigungen eingeschränkt?
Es kann z.B. durchaus ein Problem sein, wenn LiveConfig keinen Zugriff auf die CA-Zertifikate des Systems hat.

Zitat

Könnte das Problem etwas mit PHP zutun haben? Neben Updates gab es unter anderem ein Versionsprung von 5.4 auf 7.1 (5.4 komplett entfernt)

Was für ein Update war das denn? CentOS 7 bringt nur PHP 5.4 mit.
LiveConfig (und insbes. der integrierte ACME-Client) laufen unabhängig von PHP.

Wir haben hier auf CentOS7 (und auch auf allen anderen Distributionen) nicht das geringste Problem mit Let's Encrypt.
Die Meldung "SSL Handshake Failed" deutet darauf hin, dass zwar die TCP-Verbindung selbst zum Let's-Encrypt-Server aufgebaut werden kann, danach aber ein Fehler beim SSL-Handshake auftritt.

Führen Sie den o.g. "openssl"-Befehl bitte noch mal als Benutzer "liveconfig" aus (also erst mit "su -s /bin/bash liveconfig" den Benutzer wechseln).

Wie wäre es, wenn LiveConfig ein Umschalten der CLI-PHP-Version per GUI ermöglicht?
Dazu würden wir dann /usr/bin/php durch ein (äußerst schlankes) Wrapper-Programm ersetzen, welches dann an den für den jeweiligen Vertrag/Benutzer ausgewählten Interpreter übergibt.

Eine andere (sauberere) Lösung sehe ich gerade nicht.

Zitat von Ultrashadow

CentOS Linux release 7.4.1708

Ist zufällig SELinux aktiviert? (was liefert der Befehl "getenforce"?)
Wenn ja, dann könnte hier das Problem liegen (es gibt Regeln, welche Prozessen ausgehende TCP-Verbindungen verbieten...)

Ja, das ist recht einfach.
Legen Sie eine Datei namens /var/www/<Vertrag>/conf/nginx.conf an und tragen Sie da die gewünschten NGINX-Anweisungen ein.
Anschließend speichern Sie im LiveConfig irgendeine Vertrags- oder Domaineinstellung neu ab (dadurch schreibt LiveConfig die /etc/nginx/sites-enabled/<Vertrag>.conf-Datei neu und holt per include die o.g. nginx.conf mit hinein).

Viele Grüße

-Klaus Keppler