Beiträge von ksmx

Meine leise Hoffung ist auch, dass der ACME-Client aus LiveConfig es in Zukunft erlaubt die Preferred-Chain zu waehlen, so dass man LE-Zertfikate anfordern kann, welche "DST Root CA X3" nicht mehr enthalten. Vielleicht habe ich heute Nacht aber auch nur getraeumt, dass es diese Loesung gibt.

Es scheint mir als haette das LiveConfig-Backend ("SSL-Zertifikate") den abgelaufenen Teil der Kette zum Anlass genommen alle Letsencrypt-Zertifikate als "abgelaufen" zu markieren (Kalender-Icon neben dem Ablaufdatum). Zu Schaden hat dies bisher nicht gefuehrt. Ich konnte es aber auf mehreren Systemen mit unabhaengigen Alter verfolgen. Ist es richtig, dass LiveConfig seine eigene libssl mitbringt? Bedient sich LiveConfig aus dem allg. Truststore der Distribution? Gibt es einen Weg, wie ich das Flag wieder umwerfe oder LiveConfig zu einer erneuten Pruefung der Zertifikate auffordern kann? Wenn ich ein Zertifikat neu ausstellen lasse, dann verschwindet der Hinweis. Die Kette im Zertifikat sieht daraufhin aber unveraendert aus.

Der Alias (mailping: mailping) erfuellt seinen Zweck. Vielen Dank fuer den Support!

Danke fuer die Hinweise. Ich habe mich in der Tat nicht gut informiert. Wie erreiche ich, dass lokale Accounts wieder Mails erhalten koennen? Ein Eintrag in der /etc/aliases der Form "mailping: mailping" fuehlt sich falsch an.

Mit diesem Release ist eine Zeile in der /etc/postfix/main.cf hinzugekommen:

local_recipient_maps = $alias_maps

Sie sorgt leider dafuer, dass Mails an Linux-User / System-User (user@$myhostname) abgewiesen werden:

-> RCPT TO:<mailping@hostname.fqdn>
<** 550 5.1.1 <mailping@hostname.fqdn>: Recipient address rejected: User unknown

Ich habe den Ausfall zum Anlass genommen zur recherchieren und festgestellt, dass die Implementierung im Apache 2.4 mit Vorsicht zu genießen ist. Ich wuerde mich ueber einen Tipp freuen, ob man das Feature per custom.lua deaktivieren kann. Die temporaere Loesung war hier auch:

sed -i 's#SSLUseStapling off#SSLUseStapling on#g' /etc/apache2/sites-available/*.conf

Man sollte "sed" nicht auf "sites-enabled" los lassen, sonst werden aus dem Symlinks echte Dateien.

Auch eines unserer Systeme hat dieses Feature heute zum erliegen gebracht. Ein negatives/kein Feedback wird scheinbar nicht im Cache aufgenommen. Aus diesem Grund kosteter jeder Request min. 5 Sekunden, was leider dazu fuehrte, dass jegliche Requests in der Queue des Apaches versumpften.

Die Default-Settings sind leider sehr prominent in der 000-default.conf. Einen Hebel Stapling zu deaktivieren oder global an den Settings zu drehen habe ich leider nicht gefunden.

Seit Version 2.8 liefert die cron.php.sh immer einen Return-Code 1:

+ set -e
+ . /etc/liveconfig/sysconfig
+ LC_WEBROOT=/var/www
+ LC_CFGVERSION=45
+ EXPIRE=1440
+ id -u
+ USER_ID=0
+ pgrep -u 0 -f /bin/sh /usr/lib/liveconfig/cron.php.sh
+ which php
+ [ -d /var/www ]
+ php -r echo phpversion();
+ cut -d . -f 1
+ PHPVERSION=7
+ [ -d /var/www/html -a -d /var/www/html/tmp ]
+ continue
+ [ -d /var/www/index.html -a -d /var/www/index.html/tmp ]
+ continue
+ [ -d /var/www/web108 -a -d /var/www/web108/tmp ]
+ CHUSR=
+ [ 0 = 0 ]
+ id -u /var/www/web108
+ CHECK_USER=
1

"id -u" sollte mit dem Usernamen gefuettert werden und nicht mit dem Homeverzeichnis des Customers.

Okay, dann sehe ich noch den Weg, dass ich in Liveconfig einmalig manuell ein Zertifikat fuer die beiden Dienste einpflege und ich per certbot regelmäßig ein aktualisiertes Zertifikat in die Dateien

/etc/ssl/certs/postfix.crt
/etc/ssl/certs/dovecot.crt

schreibe. Per renewal-hook werden die Dienste dann neu gestartet.

Zitat von antondollmaier

Übergabe an LiveConfig - nicht.

Die neuen API-Methoden lassen sich dafür auch nicht nutzen?

Hallo,

mir ist nicht klar, ob es das Feature schon gibt oder es nu in der Planung war. Ich vermissen folgendes bzw. suche einen Weg es zu realisieren:

Dovecot und Postfix sollen *ein* Zertifikat erhalten, welches mehrere SANs enthaelt. Ich moechte die Kunden nicht zwingen die Einstellungen ihres eMail-Programms aendern zu muessen, deshalb soll das System mehrere valide Namen haben.

Kann ich über Liveconfig ein Letsencrypt-Zertifikat erstellen, welches mehrere SANs besitzt? Ich habe mich durch den LUA-Code gewuehlt in der Hoffnung mit Hilfe eines Hooks einem ausgewaehlten Zertifikat eine weitere SAN mitgeben zu koennen, leider ohne Erfolg. Ich finde keinerlei Letsencrypt-Logik.

Angenommen ich baue mir ein LE-Zertifikat per Certbot ganz an Liveconfig vorbei, dann wuerde ich es gerne trotzdem an Liveconfig uebergeben, so dass Liveconfig es an die Dienste (Postfix, Dovecot) verteilt. Ist dies der Weg den ich gehen sollte? Muss ich dafuer wirklich mit der API sprechen? Ich wuerde gerne allzu große Klimmzüge vermeiden.

Gruß ksmx

Hallo,

wir nutzen hin und wieder die Moeglichkeit eine von Liveconfig abweichende php.ini unter .php5 zu platzieren. Dieses Verzeichnis kommt auch auf Systemen zum Einsatz, wo ausschließlich PHP7 zur Verfügung steht. Die Suchreihenfolge der cron.php.sh sieht wie folgt aus:

if [ 'x$PHPVERSION' = 'x7' ] && [ -e '$cust/conf/php7/php.ini' ]; then
      cur=$(php -c "$cust/conf/php7/php.ini" -d "error_reporting='E_ALL & ~E_DEPRECATED'" -r 'print ini_get("session.gc_maxlifetime");')
    elif [ -e '$cust/.php5/php.ini' ]; then
      cur=$(php -c "$cust/.php5/php.ini" -d "error_reporting='E_ALL & ~E_DEPRECATED'" -r 'print ini_get("session.gc_maxlifetime");')
    elif [ -e '$cust/conf/php5/php.ini' ]; then
      cur=$(php -c "$cust/conf/php5/php.ini" -d "error_reporting='E_ALL & ~E_DEPRECATED'" -r 'print ini_get("session.gc_maxlifetime");')
    fi

Die conf/php7/php.ini wird deshalb der .php5/php.ini bevorzugt. Da Erstere nicht zum Einsatz kommt, greift das Skript zu einer falschen session.gc_maxlifetime. Meines Erachtens sollte der Override den anderen Konfiguration vorgezogen werden.

Gruß ksmx

Hi,

mit großer Freude habe ich gelesen, dass ab Version 1.9.1 individuelle DH-Parameter moeglich sind und dieser Debian-Security Backport unterstuetzt wird:

* Backport support for adding DH parameters to the SSLCertificateFile.

Trotzdem klagt ssllabs bei eine Pruefung. Daraufhin habe ich festgestellt, dass auf allen Systemen die Liveconfig-Default-DH-Parameter zum Einsatz kommen. Im Debian-Paket findet sich leider kein Indiz, wann die DH-Parameter neu generiert werden. Angeblich soll dies der Fall sein. Ich kann dies nicht bestaetigen. Dokumentation laesst sich leider auch keine finden.

Kann es sein, dass der entsprechende Cronjob vergessen wurde?

Gruß ksmx

Hallo zusammen,

hin und wieder lege ich eine .httpd.conf in einem Vertrag an oder nutze die Moeglichkeit eine individuelle php.ini in den Ordner .php5 zu legen. In diesen Faellen ist es notwendig eine beliebige Domain innerhalb dieses Vertrags erneut zu speichern, um eine Aktualisierung der Webserver-Konfiguration zu triggern, welche die neuen Konfigurationen findet und laed.

Gibt es einen API-Call, welchen ich feuern kann oder ein Kommandozeilentool, mit welchem ich das Update einer vHost-Konfiguration anstoßen kann. Die Anmeldung an der Weboberflaeche empfinde ich als ziemlich laestig.

Gruß ksmx

Ich bin kein Freund von Ausnahmen, ueber welche man im laufenden Betrieb stolpert. Aus diesem Grund bin ich fuer Variante (a).

Hallo zusammen,

ich habe OpenDKIM in Liveconfig (Lab-Preview) ausprobiert. Dabei wirft Postfix folgende Fehlermeldung:

May 29 08:02:02 services postfix/cleanup[32043]: warning: connect to Milter service unix:/var/run/opendkim/opendkim.sock: No such file or directory

Schaut man sich die /etc/postfix/master.cf an, dann sieht man, dass cleanup in einem chroot laeuft und das Pfad wohl anders heissen muesste bzw. OpenDKIM seinen Socket voranders platzieren sollte. Es handelt sich um Debian 7.

Gruß ksmx

Nachtrag: Ignoriert man den obigen Umstand und legt einen Reseller an, welcher ausschliesslich eMail-Management koennen soll, so scheitert das Anlegen eines Vertrags (im Reseller) mit dem Fehler: Ungültige Zeit für Log-Rotation

Das Tab "Log" steht jedoch garnicht zur Verfuegung.

Hallo zusammen,

ein Kunde wünschte sich seine eMail-Postfächer selbstständig managen zu können. Meine Wahl viel kurzerhand auf Liveconfig, mit dem Plan lediglich Postfix & Dovecot von Liveconfig verwalten zu lassen. Verfolgt man diesen Ansatz bei der Installation kommt man leider irgendwann zu dem Punkt, dass die "Webspace"-Rubrik logischerweise fehlt und Domains nicht für den Mailserver aktiviert werden.

Ich werde wohl nun zaehneknirschend den Webserver an Liveconfig uebergeben in der Hoffnung, dass die existenten vHosts unabhaengig von LiveConfig weiterlaufen koennen, um sie nicht ins LiveConfig-Schema und Benutzermanagement ueberfuehren zu muessen.

Mache ich etwas falsch oder ist mein Anwendungsfall einfach nicht vorgesehen?

Gruß ksmx

Ich war mutig und habe ein wenig experimentiert. Die Funktion "Vertrag verschieben" laesst sich nutzen, um Vertraege einem anderen Reseller-Vertrag zuzuordnen. Liegt der Vertrag erstmal im Reseller-Vertrag des neuen Resellers, kann von diesem erneut die Funktion "Neu zuordnen" genutzt werden, um den Vertrag wieder einem Kunden zuzuordnen. Der Kundendatensatz/Account muss dann zwar erneut (beim neuen Reseller) angelegt werden, jedoch konnte ich so mit etwas Handarbeit das gewuenschte Ziel erreichen.

Ich würde mich auch über dieses Feature freuen oder einen Tipp, welche Datensätze alles angefasst werden müssen, um einen Kunden umzuhängen.