Mit einem Hetzner Cloud-Server haben wir das eben getestet und auch kein Problem feststellen können (wir hatten aber das normale CentOS7-Image verwendet, da wird das Netzwerkinterface noch als "eth0" konfiguriert).
Was liefert denn der Befehl "ifconfig -a"? (gerne auch per E-Mail an support@liveconfig.com, dann müssen Sie das nicht anonymisieren)
Viele Grüße
-Klaus Keppler
Wird nur LiveConfig neu gestartet oder der ganze Server?
Auf welcher Virtualisierungsplattform (oder falls das unbekannt ist: bei welchem Anbieter) läuft der Server?
Vielen Dank für die schnelle Antwort. Es gab wirklich einen Eintrag. Habe diesen gelöscht und jetzt scheint alles wieder soweit zu klappen.
Wo kam denn dieser Eintrag her? Durch LiveConfig selbst, oder durch Software von Ihnen?
ZitatSeit ein paar Tagen habe ich das Problem, dass sehr viele DNSSEC abgelaufen sind.
Warning : The following zones have expired DNSSEC signatures
Wo genau wird das gemeldet?
Die DNSSEC-Signaturen werden vom Primary DNS automatisch aktualisiert (BIND macht das). Wenn diese Meldungen auf einem Secondary auftauchen, dann klappt vielleicht die DNS-Kommunikation nicht zwischen diesen beiden Servern.
ZitatGibt eine Möglichkeit alle DNS-Einträge von LC erneut schreiben zu lassen ??
Das nutzt nichts ohne zu wissen, warum die DNSSEC-Signaturen nicht erneuert werden.
Sehr merkwürdig. Dem Stack Trace nach zu urteilen liegt das Problem darin, dass eine Subdomain mit SD_HOST=NULL existiert (beim Start von LiveConfig werden ausstehende DNS-Updates verarbeitet). Das dürfte eigentlich gar nicht passieren.
Wenn möglich, öffnen Sie mal die LiveConfig-Datenbank und prüfen mit "SELECT SD_ID FROM SUBDOMAINS WHERE SD_HOST IS NULL", ob tatsächlich eine solche Subdomain existiert.
(bzw. mit "SELECT D_NAME FROM SUBDOMAINS, DOMAINS WHERE SD_DOMAINID=D_ID AND SD_HOST IS NULL" erhalten Sie Namen der Domains mit ungültigen Hostnamen)
Sie könnten den Eintrag dann ändern ("UPDATE SUBDOMAINS SET SD_HOST='' WHERE SD_HOST IS NULL") um den Programmabbruch an dieser Stelle zu vermeiden.
Bei weiteren Fragen wenden Sie sich bitte am besten direkt an support@liveconfig.com.
Viele Grüße
-Klaus Keppler
Thank you for your hint regarding the manual - we've updated this for the next release, the instructions at GitHub are actually the most recent ones.
ZitatIn both cases I get: The request to verify the token failed. Please try again!
Does your LiveConfig run with a self-signed certificate? If yes, is "PMA_DISABLE_SSL_PEER_VALIDATION" set to "FALSE"? (lc-sso.php)
If using an official certificate: is it possible to run eg. "curl https://url-to-your-liveconfig:8443/" without any certificate warnings? (some older distributions may not have current CA certificates)
I've updated the lc-sso.php script at GitHub for better error handling, maybe try this new version.
Best regards
-Klaus
Meinen Sie damit, dass die Webalizer-Statistiken also nur per HTTP und nicht per HTTPS erreichbar sind?
Müssten wir mal prüfen, das ließe sich natürlich ändern...
Nein, an Debian liegt das nicht.
Zuerst müssen Sie die Verwaltung der einzelnen Dienste aktivieren (Serververwaltung -> Web/Mail/Datenbanken/...). Siehe Handbuch.
Anschließend können Sie im einfachsten Fall unter "Mein Hosting" einen Hostingvertrag anlegen. Dem können Sie dann Domains hinzufügen, und somit danach auch E-Mail-Adressen, Datenbanken etc. anlegen.
Ja, aktuell führt LiveConfig die Paketerkennung nur beim Start aus.
DNS-Validierung kann die Bereitstellung beschleunigen
Nicht wirklich. Auf die Geschwindigkeit der Zonen-Updates (vom Master zu den Secondaries) hat man nur begrenzt Einfluss - das kann u.U. länger dauern als ein Webserver-Reload.
Zitatdie Reloads der Webserver reduzieren
Das möchten wir mittelfristig ohnehin anders lösen (komplett ohne Webserver-Reload).
Zitatund auch Zertifikate bereitstellen, wenn http://example.com deaktiviert ist und nur https aktiv ist.
Da ist ein Argument für DNS-Validierung, nicht aber für Wildcard-Zertifikate. 
Hallo,
die PHP-Pakete für Debian/Ubuntu wurden auf die Versionen 5.6.35, 7.0.29, 7.1.16 und 7.2.4 aktualisiert.
Diese Pakete installieren erstmals in /etc/liveconfig/lua.d/php##.lua Scripte zur automatischen Registrierung - diese werden ab LiveConfig v2.6 berücksichtigt. Details dazu sowie zur Kompatibilität mit bestehenden Anweisungen in custom.lua folgen in einem separaten Beitrag.
Künftig muss man "zusätzliche" PHP-Versionen aus dem LiveConfig-Repository also nicht mehr manuell in einer custom.lua registrieren - das geschieht dann automatisch bereits während der Installation.
Viele Grüße
-Klaus Keppler
Wildcard-Zertifikate sind aktuell mit LiveConfig nicht möglich.
Hierfür muss die Domainvalidierung per DNS erfolgen (d.h. die betroffene Domain muss durch LiveConfig im DNS verwaltet werden). Aktuell unterstützt LiveConfig noch keine DNS-Validierung für Let's Encrypt (ist aber geplant, zusammen mit einer offeneren SSL-Schnittstelle - mehr dazu wenn das soweit fertig ist).
Uns ist bislang auch kaum ein sinnvoller Anwendungsfall für Wildcard-Zertifikate bekannt. Aus Serversicht es es völlig egal, ob für jede gewünschte Subdomain ein einzelnes Zertifikat angelegt wird, oder ob ein Wildcard-Zertifikat für mehrere Subdomains genutzt wird.
Viele Grüße
-Klaus Keppler
So ungern ich Ausnahmen pflegen und dadurch die Großen bevorzugen möchte (die definieren ja auch keine Ausnahmen für uns!) - auf das wird's rauslaufen müssen.
Ich stelle dann mal ganz kätzerisch die Frage, ob diese Blacklists jeweils so geeignet sind. Eigentlich sollte dann z.B. Spamcop mal eine Ausnahme für T-Online definieren.
Am schrecklichsten finde ich persönlich derzeit die IronPort-Sache von Cisco (https://www.talosintelligence.com/). Damit haben wir derzeit die größten Probleme - am einen Ende sitzen (oft kommunale :p) Kunden, die sich so ne IronPort zur Spam-Abwehr anschaffen aber die dann quasi unkonfiguriert mit "FooBar"-Standard-Zertifikaten betreiben, am anderen Ende fühlt sich niemand Verantwortlich für's Blacklisting oder De-Listing (es gibt da schlicht keine Ansprechpartner, keine Dokumentation und keine Verantwortung... ein Blacklisting erfolgt scheinbar willkürlich...).
So, das musste mal raus... :mad:
Aktuell sehen die smtpd_client_restrictions ja etwa so aus:
smtpd_client_restrictions =
permit_mynetworks,
check_sasl_access hash:/etc/postfix/sasl_access,
permit_sasl_authenticated,
reject_invalid_hostname,
reject_unknown_reverse_client_hostname,
reject_rbl_client ix.dnsbl.manitu.netIch schlage vor, dass wir nach "permit_sasl_authenticated" noch eine (manuell pflegbare) Liste für's Server-Whitelisting aufnehmen:
smtpd_client_restrictions =
permit_mynetworks,
check_sasl_access hash:/etc/postfix/sasl_access,
permit_sasl_authenticated,
[COLOR=#ff0000][B]check_client_access hash:/etc/postfix/client_exceptions,[/B][/COLOR]
reject_invalid_hostname,
reject_unknown_reverse_client_hostname,
reject_rbl_client ix.dnsbl.manitu.netDiese Liste enthält dann die IP-Adressen oder Hostnamen von Servern, die man immer durchlassen möchte, z.B.:
mailout01.t-online.de OK
mailout02.t-online.de OK
...wobei statt "OK" evtl. ein "DUNNO" angebracht wäre, das müssten wir noch testen. Schließlich sollen die restlichen Prüfungen (insbes. Antivirus) ja weiterhin ausgeführt werden.
Dann macht es aber vermutlich mehr Sinn, eine separate Liste mit "Blacklisting-Ausnahmen" zu pflegen, statt die DNS-Whitelist dafür zu verwenden.
DNS-Whitelists sind i.d.R. weniger dynamisch als Blacklists, daher macht es IMHO schon Sinn, akute Spam-Fluten weiterhin über Blacklists abzuhalten.
Wir schauen uns die Postfix-Konfiguration mal an, mir schwebt da so was wie "/etc/postfix/blacklist-exceptions.db" vor, in die man dann (manuell) die auszunehmenden Mailserver eintragen kann.
Die Idee hinter der aktuellen Konfiguration ist wie folgt:
Aus diesem Grund kann man die DNS-Whitelist im LiveConfig auch nur dann pflegen, wenn Greylisting aktiviert ist.
Kurz aber knapp: geht nicht, weil MySQL nur /8, /16 und /24 unterstützt.
(daher auch die Einschränkung in der GUI, statt einem freien Textfeld)
Diese Meldungen können Sie ignorieren (ich glaube sogar dass diese in v2.6 entfernt wurden/werden). LiveConfig führt vorsorglich "chcon" aus (falls vorhanden), um die Attribute für SELinux zu setzen.
Ist eigentlich keine große Sache, können wir gerne mit einschieben.
Ich hatte kurzfristig überlegt, direkt /etc/skel als Vorlage zu verwenden - denke aber es ist sinnvoller, ein separates Skeleton hierfür zu nutzen.
Gab es dann aber nicht das Problem das die Sachen überschrieben wurden wenn jemand die Urlaubsfunktion von LC genutzt hat?
Das wird weiterhin bestehen (LiveConfig überschreibt für den Autoresponder die Sieve-Datei).
Aber:
Aktuell (v2.5.3) gibt es übrigens noch das Problem, dass beim Aktualisieren von Postfacheinstellungen durch LiveConfig eventuelle ManageSieve-Scripte in manchen Fällen deaktiviert werden, das ist in v2.6.0 behoben (das tritt dann auf, wenn ManageSieve einen Symlink auf's Sieve-Script erstellt - LC prüfte wiederum nur, ob das eine "echte" Datei ist).
