Meine Vermutung war, dass der LC DNS-Resolver bei Servern mit NAT gegen die interne IP-Adresse geprüft hat und nicht gegen die öffentliche Adresse.
Ich habe es aber nicht weiter verfolgt, da wir eh umstellen wollten.
Beiträge von TCRserver
-
-
kk Sry für den Schock am Morgen
Aber:
https://www.liveconfig.com/de/…7736&viewfull=1#post17736Bei uns kam bei allen NAT Servern, permanent ein "DNS check failed: DNS error: unknown/invalid IP(s) found in DNS".
-
Mir ist nicht bekannt, dass LiveConfig + let's Encrypt + NAT (+ konfigurierter IPS.IP_NAT) im Moment funktioniert!
Bei unserem letzten vServer mit NAT konnte bis zum letzten 2.8.4 Release kein Zertifikat mehr erstellt werden. Und laut Changelog wurde auch nichts mit NAT + Let's Encrypt geändert.Wir haben mit dem aufkommen des Problems unsere betroffenen Server mit NAT alle auf eine Instanz ohne NAT umgezogen. Was eh schon längst überfällig war.
-
Hier eine kleine Anleitung zum umziehen eines LiveConfig Nameserver (Primary + Secondary) auf einen neuen Server bzw. neue IP-Adressen.
Motivation für den Umzug bei uns war die Abkündigung der Hetzner vServer Serie und dem damit verbunden Umzug auf eine Cloud Instanz.Danke an das Team von Hr. Keppler beim verstehen und lösen der Fallstricke!
Wer Anmerkungen, Verbesserungen oder eigene Erfahrungen hat ist eingeladen sein Wissen zu teilen und den Post zu verbessern.
OS: Debian 9
LiveConfig: 2.8.4Der eigentlich Umzug ist relativ einfach und wird am besten via Rsync im Hetzner Rescue vollzogen.
Kompliziert wird es erst durch das verändern der IP Adressen.Vorraussetzungen damit der Bind9 generell funktioniert sind:
Glue-Records auf die neuen IPs gesetzt
DNS Namesauflösung funktioniert korrekt auf die neuen IP Adressen (wichtig!)
Evtl. /etc/hosts angepasst
Evtl. /etc/network/interfaces angepasst
PTR Records der neuen IP-Adressen gesetztNach dem Transfer des Servers und dem starten ins Betriebssystem, muss im LiveConfig, in der Serververwaltung, der Bind neu konfiguriert werden. Dadurch werden die neuen IP-Adressen in der named.conf.options geändert.
Vor den Änderungen an den Konfigurations Dateien empfiehlt es sich die Zonen Updates via "rndc freeze" anzuhalten und die Zonenfiles runter zu schreiben.
Und am Ende aller arbeiten mit "rndc thaw"neu zu laden.Auf einem Master-Server muss zusätzlich noch die Datei /etc/bind/keys.liveconfig überprüft werden, ob die neuen IP-Adressen der Slave-Server übernommen wurden.
Auf dem Slave-Server(n) müssen in der Datei /etc/bind/keys.liveconfig die IPv4/IPv6 Adresse des Master-Servers ausgetauscht werden.
Zudem muss noch in der Datei /etc/bind/zones.liveconfig zu jeder eingetragenen Zone ebenfalls die IP-Adresse des Master Servers ausgetauscht werden.
Code… zone "example.com" { type slave; file "example.com.db"; masters { 99.99.99.99; 1234::1; }; }; …
Dieser Schritt kann auch via LiveConfig erfolgen indem die Domain einmal zwischen internerm, externem und wieder internem Nameserver umgeschaltet wird.Den Bind Server neu starten und ggf. Zonen Updates via "rndc thaw" wieder erlauben.
Damit sollten die Nameserver auf die neuen IP-Adressen umgestellt sein und wieder funktionieren.
-
Hallo KK,
ich habe einen Hetzner vServer wegen Abkündigung der Produktreihe auf eine Cloud Instanz umgezogen.
Beim Umzug von vServer nach Cloud werden neue IP-Adressen vergeben (logisch).
Dabei entfällt zum Glück auch das "nervige" NAT Feature der vServer.Beim neu schreiben der Konfigurations Dateien über die Serververwaltung, wird beim ProFTP die masquerade.conf Datei nicht neu geschrieben bzw. gelöscht. Somit werden die passiven Ports mit der falschen IP Adresse maskiert und es kann kein FTP genutzt werden.
OS: Debian 9
LC: 2.8.4-r5653 -
Wir haben uns im letzten Jahr sehr intensiv damit auseinander gesetzt.
Das einzig halbwegs sinnvolle Modul (welches wir getestet haben) war von plambee (https://www.plambee.de/whmcs-m…whmcs-liveconfig-hosting/).
Es funktioniert, aber wirklich der Knaller war es nicht. Der Support nur mittelmäßig und im Einstieg zusammen mit WHMCS sorgt es für mehr Frust als Lust!WHMCS ist meiner Meinung nach, eh nicht wirklich gut nutzbar für den deutschen Markt. Es geht, aber es benötigt sehr viel an Anpassungen.
Wenn man sich noch nicht für WHMCS entschieden hat, oder daran gebunden ist, dann würde ich noch einen Blick in Richtung sourceDESK empfehlen.
Auch hier ist bei weitem vieles noch nicht perfekt, aber preislich ist es deutlich eine Alternative zu WHMCS. Zumal hier auch extrem viele Module (u.a. LiveConfig) enthalten sind. -
Ja klar, sonst würden die Server ja nicht korrekt funktionieren.
Die Server sind schon seit eingen Jahren im Einsatz (seit es das LC NAT Feature gibt). -
Ich habe leider auch noch ein Problem mit den LE Zertifikaten.
Alle Domains die auf Server mit NAT IP-Adresse sind, zeigen folgende Fehlermeldung:
[01.10.2019 21:24:20] ACME2: http://www.example.de: DNS check failed: DNS error: unknown/invalid IP(s) found in DNS: xxx.xxx.xxx.xxxUnd somit werden die Zertifikate nicht verlängert.
-
Ich verstehe den Wunsch von euch ganze Zonen zu blockieren um den lästigen SPAM in den Griff zu bekommen. Aber wirklich begeistert bin ich von so einer Funktion nicht. Wenn Möglich, dann bitte Konfigurierbar machen, damit man die Funktion ggf. auch deaktivieren kann.
-
Das grenzt dann aber schon an Zensur, wenn man eine ganze Zone pauschal blockiert...
-
Ein Neustart von LC während Pakete installert wurden kann ich nicht ganz ausschließen.
Gestern Abend habe ich den Dovecot Patch und LC 2.8.1 in einem Rutsch installiert.Teilweise wurde die Konfiguration von Dovecot erst einige Minuten nach dem Restart wieder angezeigt.
Inzwischen habe ich alle Clients nochmals neu gestartet und die Konfiguration wird bei allen Servern korrekt angezeigt. Ich kann es aktuell auch nicht mehr reproduzieren.
-
Hallo Klaus,
bei mir wird mit der 2.8.1 in der Server Verwaltung der Dovecot Server nicht mehr angezeigt.
Ein "lcclient --diag" findet den Dovecot aber zuverlässig. Daher tippe ich jetzt einfach mal auf ein Problem mit der anzeige.Zitat
Checking for POP/IMAP server software:
- Found 'dovecot' POP/IMAP server
Version: '2.2.27'
Package version: '1:2.2.27-3+deb9u5'Bei mir ist es auf vielen Servern reproduzierbar.
Ein Neustart des Clients bringt nicht immer eine Lösung.Getestete OS: Debian 9.9 und 10
-
Was sagen die Logfiles liveconfig.log, lcclient.log und access.log? Ist dort irgendwas relevantes hinterlegt?
-
Ist das Template korrekt angelegt bzw. wurde was am Template geändert?
Bei uns ist es am Anfang immer mal wieder zu Problemen gekommen, wenn wir mit den Templates und der Konfiguration "gespielt" haben. Dann wurden Domains nicht richtig aktualisiert.
Also Lösung haben wir 2 NS aufgesetzt, die zwar existieren, die aber nur als Dummy-Nameserver dienen und nach außen via Fiewall geblockt sind.
Wenn es zu Problemen kommt, transferieren wir die Zone auf dieses Dummy-Nameserver Set und danach wieder zurück auf die Produktiven. -
Steht die Verbindung zwischen dem LiveConfig Server und dem Client?
Erkennbar im LiveConfig im Menüpunkt Serververwaltung. -
Nee, aber wir fummeln gerne mal in der DB rum und schwitzen dann... :cool:
-
Zitat
aber wir möchten den nunmal auch nicht im Regen stehen lassen
Sehr gut! Vielen Dank dafür!
So habe ich kk und sein Team bei X Besuchen auf dem WHD/Cloudfest kennen gelernt und so gehört es sich auch. Kunden helfen, aus Fehlern lernen und dabei noch das Produkt verbessern.
Auch wenn es einen Release Termin verschiebt.Und nein, wir sind es ausnahmsweise mal nicht den es getroffen hat.
-
Ich zitiere mal die Ankündigung zur Preview 2.8
Zitatder neue Backup-Service (lcbackup) ist noch nicht in die GUI integriert
Also nix mit totschweigen sondern daran wird gearbeitet.
Auch wenn es sehr lange gedauert hat.Und als kleiner Tipp: Eine eigene Lösung via rsync, duplicity oder einem der vielen anderen Tools ist schnell umgesetzt, wenn man sich damit beschäftigt.
Und ein nicht voll automatischer Restore kann ja auch zusätzliche Umsätze generieren :cool: -
Also bei uns läuft SA unter Debian 9 ebenfalls relativ Problemlos.
Nur die Qualität der SPAM Erkennung ist öfters mal nicht ganz so prickelnd.Das einzigste was wir kennen ist das Berechtigungs Thema:
https://www.liveconfig.com/de/…1839&viewfull=1#post11839Ansonsten wären wirklich einmal die Logfiles ganz gut.
-
Welches OS und welche Version verwendet ihr?