Diese Anfragen häufen sich - einige Kunden finden es nicht selbsterklärend.
Das Problem tritt IMHO nur im Zusammenhang mit eigenen DNS-Einträgen auf: bisher wird dort nur "Zone" und nicht "Subdomain" als Konstrukt erkannt.
Grundsätzlich finde ich die Fortführung der Logik konsequent.
ZitatWas haltet ihr von einer Zeile oder einem Symbol "neue Subdomain" unterhalb jeder Domain
Zumindest bei den "eigenen DNS-Einträgen" würde das helfen.
Neue Subdomain: "_25._tcp.mail", dann dort Webspace deaktivieren und den TLSA-Record erstellen.
wer von euch lässt LiveConfig automatisch updaten? Kann mir jemanden sagen, wie man das am besten bewerkstelligt?
Konfigurationsmanagement (Puppet/Ansible/Salt) kann Pakete auf die gewünschten Versionen heben.
Alternativ Cronjobs oder UnattendedUpgrades.
Wir fahren ein wöchentliches Wartungsfenster, in dem dann auch LiveConfig aktualisiert wird.
Ja, am besten machst Du Dir einen Grep auf die /etc/postfix/virtual_alias (erste Spalte) in eine Datei
awk '{print $1}' /etc/postfix/virtual_alias | while read i; do /usr/lib/liveconfig/lcpolicyd set ${i} 10 30; doneZitatZu den falsch konfigurierten Zwischenzertifikaten: wir erweitern LiveConfig aktuell, dass es beim Start alle SSL-Intermediates prüft und auf abgelaufene Zwischenzertifikate oder fälschlicherweise konfigurierte Root-CA-Zertifikate hinweist.
yeah!
ZitatUrsprünglich wollten wir diese auch automatisch löschen, das ist aber nicht ganz trivial, da eventuelle Ketten damit ungewollt unterbrochen werden könnten. Wir lassen uns da aber auch etwas einfallen.
Eventuell als Idee:
https://github.com/zakjan/cert-chain-resolver
Nimmt das Zertifikat und sucht die CA-Chain selbst raus.
Nicht als Reseller den Endkunden-Vertrag editieren, sondern als Admin den Reseller-Vertrag bearbeiten.
Dort gibt es dann unterhalb des "eigene DNS-Einträge erlaubt/verboten"-Dropdown auch die Auswahl der DNS-Vorlage (in Version 2.9 gerade verifiziert).
ich habe hier eine Multiserver Umgebung mit eigenen NS. Wenn der Admin Domains für sich oder für Kunden anlegt, werden die internen NS zur Auswahl angeboten, wenn dies ein Reseller tut, gibt es nur die Option externe NS.
Ja:
Reseller-Vertrag bearbeiten, Tab Domains. Dort dann die DNS-Vorlage, die der Reseller nutzen darf, auswählen.
Funktioniert hier alles problemlos.
Die SOAP-API kenne ich noch nicht, gibts da irgendwo eine Dokumentation dazu?
(Sorry, wenn ich jetzt die Abkürzung nehme - ich gebe zu, noch nicht danach gesucht zu haben)
im Handbuch, ja:
https://www.liveconfig.com/de/handbuch/api.soap.xhtml
ZitatAllerdings halte ich das für nicht ganz ungefährlich, Programmierfehler hätten da möglicherweise ziemlich schräge Folgen.
Deshalb testet man solche krassen Eingriffe normal auch erst in der Dev-Umgebung mit einigen wenigen Accounts 
Aber ja, das ist eher ein Workaround und keine echte Lösung.
Ich möchte/muss (DSGVO) jetzt die Mails und Accounts vom Server löschen, da sie ja hier nicht mehr gebraucht werden.
Ergänzende Anmerkung: das Vorgehen ist auch nötig, damit der Web/Mailserver selbst den externen MX verwendet und somit auch andere Domains auf dem selben Mailserver die nun externe Domain erreichen können.
Mit der SOAP-API könnte das mit Code umgesetzt werden. Alternativ könnte die Domain auch komplett aus dem Vertrag gelöscht werden - allerdings entfernt das dann auch alle Web-Konfigurationen.
Was spricht dagegen, MariaDB zu benutzen statt MySQL?
Shopware6 und Akeneo PIM empfehlen beide den Einsatz von MySQL, da MariaDB bei einigen Abfragen (JSON) fehlerhafte Antworten gibt.
Hi,
ich hatte die virtual_alias und virtual_domains Textvariante nicht mitkopiert, in dem Gedanken dass Liveconfig die eh neu schreibt, aber es wird nur bei Änderungen nur genau die Änderung geschrieben.
Dass hier eine Kopie angelegt wird, war aus dem Beitrag allerdings nicht ersichtlich.
Zitat:thumpup für eine Option in liveconfig alle Konfigdateien neu zu genieren.
Das ist - beispielsweise bei den Postfächern in Dovecot - nicht möglich, da LiveConfig die Passwörter nicht selbst speichert, sondern diese nur in der passwd von Dovecot abgelegt werden.
LiveConfig schreibt in die virtual_alias bzw virtual_domains nur bei Änderungen. Ansonsten werden die Konfigurations-Dateien nicht angefasst.
Die virtual_*-Dateien werden auch beim Reload bzw "Konfiguration neu schreiben" nicht mehr neu erzeugt.
Ich benötige die Deaktivierung nur für einen Vertrag, nicht für die komplette IP-Gruppe.
Nur auf IP-Ebene möglich, es sei denn:
Not possible.
This is caused by permission issues for resellers and is affecting not just php settings.
Die Validierung für solche Zertifikate müsste via DNS erfolgen, und das ist leider recht anfällig für Probleme (hauptsächlich das Caching).
Reicht es nicht, vor dem Anstoßen der Validierung durch LE sicherzustellen, dass alle aktiven Nameserver tatsächlich mit dem korrekten Record antworten - ohne einen Resolver zu bemühen?
ZitatEs gibt zudem kaum ernste Anwendungsfälle für Wildcard-Zertifikate - in der Regel tun's ja auch "normale" Zertifikate.
Jain:
- Große Anzahl an Subdomains
- Domains, die auf interne IP-Adressen zeigen (HTTP-Validierung nicht möglich, DNS aber schon)
Sind beides, auch im Kontext mit LiveConfig, IMHO valide Gründe.
Die Pakete php und php-fpm sind allerdings installiert
php-cgi fehlt dann.
Versuche ich nun ein apt-get install liveconfig, wird eine Neuinstallation initiiert, statt ein Upgrade durchzuführen.
Blöder Vorschlag:
- Daten sichern (betrifft ja nur die liveconfig.db bzw. mySQL-Datenbank)
- Paket neu installieren
- Dienst stoppen
- Backup zurückfahren
- Dienst wieder starten
- sicherstellen, dass die Daten tatsächlich da sind
Ggf. nochmals die Neu-Erstellung der Konfigurationsdateien/Services anstoßen, damit auch wirklich das Upgrade durch läuft.
Das sollte stressfreier gehen als jetzt manuell in der dpkg-Datenbank rumzufriemeln.
Also würde das ganze so aussehen?
Möglich - funktioniert der Code nicht?
Der Override funktioniert hier doch wie bei allen anderen LUA-Funktionen auch:
dovecot.USERDB_SIEVE = "userdb_sieve=/var/mail/%C/%I/default.sieve"
function dovecot.addMailbox(cfg, opts, data)
endauf einem Debian Jessie System
Debian Jessie ist End of Life seit 2018, die LTS wird ihr EoL auch in 3 Monaten erreichen.
Wäre ein Upgrade nicht sinnvoll?
