Beiträge von kk

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.23 und 7.3.10 aktualisiert.

Viele Grüße

-Klaus Keppler

Danke auch für die Rückmeldung!

In v2.8.4-r5651 (aktuelle Preview) ist's nun auch korrigiert.

Aaargh... Stop. Nachtrag.
Ich habe den betroffenen Code eben analysiert - im lcsam steckte da tatsächlich ein Fehler bei der Umwandlung von IPv6-Adressen.
Ich habe das eben aktualisiert - ein aktualisiertes LiveConfig-Paket werden wir dann gleich bereitstellen.

Welche Distribution und welche Postfix-Version nutzen Sie denn?

lcsam wird von Postfix aus über die Milter-API angesprochen. Die Funktion lcsam_connect() erhält dabei (zumindest laut API-Spezifikation) die IP-Adresse der SMTP-Gegenseite.

Wenn da nun was anderes (unbrauchbares) drin steht, kann kann das bedeuten, dass eine der beteiligten Komponenten (vermutlich Postfix oder dessen libmilter) kein IPv6 beherrschen.

Um das zu testen, müssten wir aber die genaue Distribution kennen.

Viele Grüße

-Klaus Keppler

Welche Version von SpamAssassin genau kommt zum Einsatz? (SA <3.4 kann IPv6 nur eingeschränkt).

Please edit the reseller subscription (as admin). Click the tab "Domains & Mail". Below the "subdomains" property, you can select the DNS template which may be used by that reseller.

The reseller can then use your own DNS server (using the allowed DNS template).

Nein - ist alles online. Ggf. "apt update" noch mal ausführen?

Hallo,

ab sofort steht LiveConfig v2.8.3 zum Download bereit.
Dieses Update enthält hauptsächlich Detailverbesserungen und Bugfixes - die vollständige Liste aller Änderungen befindet sich wie immer im Changelog.

Viele Grüße

-Klaus Keppler

Zitat von Feuernatter

Ich verwende LiveComnfig noch nicht so lange, daher nun meine Frage:
Wo finde ich diese Tabelle IPS?

In der LiveConfig-Datenbank. Standardmäßig läuft diese mit "SQLite", liegt dann unter /var/lib/liveconfig/liveconfig.db (zum Bearbeiten das Paket "sqlite3" installieren - aber IMMER vorher ein Backup machen!)

[quote[Wenn ich das richtig verstanden habe, müssen die öffentlichen IPs nach einer Eintragung in dieser Tabelle nicht mehr direkt am Interface konfiguriert werden. Ist das so richtig?[/QUOTE]

Exakt.

Da es diese Rückfragen (aufgrund NAT) inzwischen häufiger bei uns gab, werden wir das mit einem der kommenden Updates direkt in die Oberfläche integrieren.

Das Tool ist bereits fertig und wird sogar schon mit installiert, in der LiveConfig-GUI gibt es aber noch keine Konfigurationsmöglichkeit (weil LiveConfig derzeit noch keinen Scan auf verfügbare CLI-Versionen durchführt).

Das Programm nennt sich "lcphp", in der zugehörigen man-Page ist eigentlich alles beschrieben (insbes. Aktivierung unter Debian/Ubuntu). Um für einen Kunden dann den PHP-Interpreter umzuschalten muss der gewünschte PHP-Interpreter als Symlink unter ~/conf/php hinterlegt werden.

GUI-Integration steht schon im Arbeitsplan, kommt mit einem der nächsten Updates.

Viele Grüße

-Klaus Keppler

Zitat von WuChEn

Habe es installiert und liveconfig der Gruppe root hinzugefügt.
Läuft so wie ich das sehe

Aaaargh! Bitte nicht! Der Benutzer "liveconfig" darf unter keinen Umständen in der Gruppe "root" sein!

Das Cron-Script zum Aufräumen der PHP-Session-Files wird ohnehin als Benutzer "root" ausgeführt. sudo wird verwendet, damit das Script PHP jeweils als "Endkunde" ausführen kann, um die Session-Expire-Dauer sicher auszulesen.
Dass sudo häufig nicht installiert ist, hatten wir nicht bedacht - wir werden am Montag eine Lösung erarbeiten (eventuell wird das auf ein eigenes kleines Programm hinauslaufen, so dass wir weder sudo noch su benötigen).

Viele Grüße

-Klaus Keppler

Hallo,

an sofort steht LiveConfig v2.8.2 zum Download bereit.

Die wichtigsten Änderungen sind:

• die Schnellsuche umfasst nun auch exakte Domainnamen und Benutzernamen unterhalb von Wiederverkäufern (keine Suche nach Teilbegriffen möglich - aus Datenschutz- und Performancegründen; man kann also nach "kundendomain.de" suchen, nicht aber nach "kundendomain")
• viele Verbesserungen bei der neuen Let's-Encrypt-Integration (automatische Wiederholung nach 24 Stunden wenn Bestellung mit 404 fehlgeschlagen ist; Fehler im Zusammenhang mit MySQL als Backend behoben; ...)
• Probleme beim Start von LiveConfig via systemd behoben (keine doppelten Log-Meldungen mehr, bessere Entkopplung der Prozesse - führte vorher dazu, dass lange Upgrade-Vorgänge durch systemd abgebrochen wurden, u.v.m.)

Die vollständige Liste aller Änderungen finden Sie wie immer im Änderungsverlauf.

Viele Grüße

-Klaus Keppler

Zitat von RB-Media-Group

[...]
[2019/09/12 10:37:07.854337] [20672|20679] ACME2: triggering http validation for 'domain.de'... (AU_ID=3668)
[...]
[2019/09/12 10:37:08.412097] [20672|20679] ACME2: triggering http validation for 'www.domain.de'... (AU_ID=3669)
[...]

Das bedeutet, dass LiveConfig den Auftrag zu Let's Encrypt abgeschickt hat - nun wartet LiveConfig quasi auf die Rückmeldung, ob die Domainvalidierung erfolgreich war.
Im liveconfig.log sollten eigentlich weitere Meldungen dazu auftauchen - suchen Sie bitte mal mit "grep" nach dem Domainnamen:

grep <domainname> /var/log/liveconfig/liveconfig.log | grep ACME2

Viele Grüße

-Klaus Keppler

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.1.32, 7.2.22 und 7.3.9 aktualisiert.
Zudem gibt es folgende Änderungen:

• für PHP 7.3 steht nun auch die "xmlrpc"-Extension zur Verfügung
• die Redis-Extension (php-7.x-opt-redis) für PHP 7.2/7.3 wurde auf 5.0.2 aktualisiert
• PHP 7.4.0 steht nun als "Release Candidate 1" zur Verfügung
  Für den RC2 planen wir, auch all die Extensions mit bereitzustellen, die wir auch schon für PHP 7.3 anbieten (u.a. igbinary, redis, ImageMagick, ...)
• unsere PHP-Pakete 7.2/7.3 unterstützen den "Argon2"-Algorithmus (wird derzeit häufig von Typo3-Anwendern nachgefragt)

Viele Grüße

-Klaus Keppler

Was exakt steht in /etc/liveconfig/lclogparse.conf und in /var/lib/liveconfig/lclogparse.status ?

Führen Sie bitte diesen Schritt (noch mal) aus:

Zitat

Machen Sie zudem eine Kopie von /var/lib/liveconfig/smtp.stats und prüfen ebenfalls nach ca. 15 Minuten mal per "diff", ob sich in der Datei etwas geändert hat.

Was genau steht dann im diff?

Welche Version lief vor dem Update?
PHP-Auswahl ist nicht möglich bei Verträgen, die auf mod_php konfiguriert sind.

Zitat von pkambach

Eine .htaccess sieht z.B. so aus:

Ich habe es mit exakt dieser .htaccess getestet, und der Zugriff auf /.well-known/ wird korrekt auf die Validierungsdatei geroutet...

Prüfen Sie bitte mal die vHost-Konfiguration (/etc/httpd/vhosts.d/<Vertrag>.conf), ob dort folgender Abschnitt drin steht:

<IfModule mod_rewrite.c>
        RewriteEngine On


        RewriteMap  "lc" "int:tolower"
        RewriteCond %{REQUEST_URI} ^/\.well-known/(.*/)?([^/]*)$
        RewriteCond /var/www/web1/htdocs/.well-known/%1%2 !-f
        RewriteCond /var/www/.well-known/htdocs/%1${lc:%{HTTP_HOST}}.%2 -f
        RewriteRule / /var/www/.well-known/htdocs/%1${lc:%{HTTP_HOST}}.%2 [T=text/plain,L]
    </IfModule>

Der sorgt dafür, dass Zugriffe auf http://<domain>/.well-known/<datei> umgeleitet werden auf /var/www/.well-known/htdocs/<domain>.<datei>

Testweise können Sie einfach mal eine Datei mit dem Namen /var/www/.well-known/htdocs/acme-challenge/<domain>.test.txt anlegen - die müsste dann unter http://<domain>/.well-known/acme-challenge/test.txt abrufbar sein.

Zudem müsste in /etc/httpd/vhosts.d/00_default_vhost.conf auch folgendes zu finden sein:

[...]
<Directory /var/www/.well-known/htdocs/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>
[...]


<VirtualHost <IP>:80>


    Servername default
    DocumentRoot "/usr/share/liveconfig/html/"


    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteMap  "lc" "int:tolower"
        RewriteCond %{REQUEST_URI} ^/\.well-known/(.*/)?([^/]*)$
        RewriteCond /usr/share/liveconfig/html/.well-known/%1%2 !-f
        RewriteCond /var/www/.well-known/htdocs/%1${lc:%{HTTP_HOST}}.%2 -f
        RewriteRule / /var/www/\.well-known/htdocs/%1${lc:%{HTTP_HOST}}.%2 [T=text/plain,L]
    </IfModule>


</VirtualHost>

Damit routet LiveConfig die Zugriffe auf .well-known für Domains, die deaktiviert oder noch nicht vollständig konfiguriert sind.

Hmm, interessant - sollte eigentlich nicht möglich sein.
Könnten Sie uns mal schicken was genau in den RewriteRules der .htaccess drin steht? Dann testen wir das mal durch.
Ziel seitens LiveConfig ist es immer, den Kunden "vor sich selbst" zu schützen.

Zitat von aziegler

aber der Betreiber und das OS hat dann weniger Kontrolle über die DNS-Tätigkeiten die vom System ausgehen

Ja, es hat eben alles Vor- und Nachteile. Wenn direkte DNS-Zugriffe möglich sind, dann nutzt LiveConfig diese um den TTL von DNS-Daten ignorieren zu können - wird ein externer Resolver verwendet, dann erhält LiveConfig ggf. Antworten aus dessen Cache (was im Normalbetrieb ja erwünscht ist, für Diagnosezwecke aber ungünstig ist).

Bei Multi-Server-Setups genügt es, wenn der LiveConfig-Hauptserver DNS-Zugriff hat (die LiveConfig-Clients lösen keine DNS-Anfragen aus). Und wenn die DNS-Zugriffe lokal (iptables) gefiltert werden, kann man mittels "owner"-Modul einzelne Benutzer freischalten - wie z.B. den Benutzer "liveconfig".