Beiträge von TCRserver

    Wenn ich es noch richtig im Kopf habe, dann war es irgendwas im Zusammenspiel mit dem syslog^bzw. dem postrotate Befehl.
    Betroffen waren bei uns nur Systeme die ein Debian 9 auf 10 Upgrade bekommen haben.


    So aus dem Kopf raus:
    Edit: /etc/logrotate.d/rsyslog


    suche nach:

    Code
    postrotate
                    invoke-rc.d rsyslog rotate > /dev/null
            endscript


    und ersetze durch:

    Code
    postrotate
                    /usr/lib/rsyslog/rsyslog-rotate
            endscript


    Aber wirklich aus dem Kopf raus und ohne Gewähr!

    Verwendet von euch noch jemand sourceDESK?
    Wir nutzen es seit einem Jahr mit gemischten Gefühlen.


    Nur seit gut 3 Wochen hören wir nichts mehr von der Firma hinter sourceDESK.
    Tickets werden nicht bearbeitet, Zahlungen nicht verbucht und somit werden auch akute Probleme nicht mehr gelöst.


    Um da eigentlich Thema nochmal auf zu greifen:
    Hat jemand Erfahrungen mit HostBill?

    Ich zitiere mal aus einer Mail die wir von einem unserer Registrare bekommen haben:


    Zitat


    Bei allen Produkten, die über die Smart-NIC GmbH bzw. das Domain-Bestellsystem bezogen werden, handelt es sich unserer Auffassung nach um Dienstleistungen (insbesondere die Registrierung und Verwaltung von Internet Domains). Diese Dienstleistung ist unteilbar und wird üblicherweise im Sinne von § 13 UStG mit Registrierung bzw. Verlängerung der Domain erbracht. Die weitere Bereitstellung von Verwaltungsmöglichkeiten ist eine reine Nebenpflicht und wird darüber hinaus über die monatliche Grundgebühr für den jeweiligen Leistungszeitraum berechnet. Daraus abgeleitet werden wir die Umsatzsteuer auf unseren Rechnungen gemäß dem Zeitpunkt der Leistungserbringung ausweisen.


    Wir bitten zu beachten, dass dies keine (steuer-)rechtliche Beratung darstellt und ersuchen alle Kunden, die für ihren Geschäftsbetrieb geltenden steuerlichen Verpflichtungen eigenständig zu prüfen.


    Das deckt sich so ziemlich zu der Meinung von Herr Keppler bzgl. Domains.
    Aber (hoffentlich) ganz korrekt kann es nur der Steuerberater sagen ;)

    Vielen Dank für die Aufklärung!
    Ich zerbreche mir schon die ganze Zeit den Kopf darüber wie wir das am besten machen.
    Zumal unsere Software es vermutlich eher auch nicht kann und der Hersteller sich die gleichen Gedanken macht.


    Und an die schon bezahlten Laufzeiten habe ich dabei noch gar nicht gedacht!
    Oder umgekehrt, die Laufzeiten die in den 6 Monaten verlängert werden...

    Hallo Herr Keppler,


    bei unseren Debian Buster Servern erhalten wir von Dovecot folgende Fehlermeldung:


    Error: net_connect_unix(/var/run/dovecot/stats-writer) failed: Per))


    Beschrieben ist das verhalten auch im Dovecot Wiki als harmlose Fehlermeldung.
    https://wiki2.dovecot.org/Upgrading/2.3


    Vielleicht kann man den Parameter service_stats ja trotzdem in die Konfiguration mit aufnehmen. Sieht dann im Graylog etwas ordentlicher aus.

    Fast richtig. Man kann nur einen Benutzer auf dem Basic Server nutzen.
    Ich nutze die Basic Lizenzen sehr gerne für vServer, die nur ein Kunde nutzt.

    Guten Morgen,


    für dein Vorhaben reicht die Kombination von 1 x Business und 2 x Basic vollkommen aus.


    Solange du einen Server mit einer Business Lizenz hast und andere Server (mit einer Basic Lizenz ausgestattet) damit verknüpft sind, hast du auch bei den Basic Servern den vollen Funktionsumfang. Nur die Beschränkung bei der Kunden Anzahl bleibt erhalten.

    So habe ich das auch aus der Doku raus gelesen.
    Aber gegen welche IP Adresse validiert LC es, also welche http-Server Adresse?


    Mein Verdacht war hier eben, dass hier die private IP-Adresse angezogen wird.


    Oder wie ist die Fehlermeldung zu verstehen?
    DNS check failed: DNS error: unknown/invalid IP(s) found in DNS


    Für mich war das ein Hinweis auf ein Abgleich zwischen DNS und konfigurierter Apache-IP-Adresse.
    Und in der Serverkonfiguration bei IP-Adresse wurde ja auch die private IP-Adresse angezogen und nicht die öffentliche.


    Das der Resolver falsche Daten geliefert hat, ist auch nicht ganz ausgeschlossen. Kann ich aber auch nicht mehr nachvollziehen.


    Ich bin aber ziemlich warscheinlich sowas von auf dem Holzweg und interpretiere es völlig falsch.
    Da ich keinen passenden Server mehr habe, kann ich es auch leider auch nicht mehr nachvollziehen.

    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.4


    Der 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 gesetzt


    Nach 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.

    Code
    server 99.99.99.99 {
            keys { LC-xxxxxxxxxx.; };
    };
    


    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.

    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.

    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.