Beiträge von kk

    Innerhalb einer LiveConfig-Umgebung macht das wenig Sinn. Als DNS-Server für die Sub-Zone wären ja die selben wie für die Zone selbst eingetragen.


    Es dürfte einfacher sein, die gewünschte Subdomain bei der Hauptzone direkt anzulegen (also nur den A-Record). Beim anderen Vertrag, wo diese verwendet werden soll, wird die dann über "Domain hinzufügen" angelegt, dort aber "externe Nameserver" ausgewählt.

    Ich wüsste nicht was gegen Unbegrenzt spricht?


    Code
    while(true) do; dd if=/dev/urandom bs=10M | mail opfer@example.org; done


    Ohne Postfach-Quota (egal wie groß) ist mindestens der Mailservice, wahrscheinlicher aber der ganze Server so binnen kürzester Zeit tot.
    Nicht zuletzt "freut" sich auch der Kunde dann darüber, wenn er "unbegrenzt" viel Müll aus seinem Postfach entfernen darf. ;)

    Ich habe eine Subdomain (blabla.example.com) unter "Mein Hosting" als eigene Domain angelegt und einen DNSSEC Key für diese Domain erstellt.


    Ah ja. Es geht also um eine eigene Unter-Zone.
    Voraussetzung ist, dass die übergeordnete Domain (example.org) DNSSEC-signiert ist.


    In diesem Fall muss der DS-Record in der übergeordneten Zone hinterlegt werden.
    In "example.org" stehen ja für "blabla.example.org" bereits mindestens zwei NS-Records. Da muss der DS-Record dazu. Den Hash und die Parameter für den DS-Records kann man sich im LiveConfig anzeigen lassen (bei der Anzeige der DNSSEC-Schlüssel im Tab "DS-RR").

    Wie schon geschrieben gibt es technisch betrachtet kein "unbegrenzt".


    Ich empfehle ohnehin dringend, immer irgendein Quota zu setzen, da sonst ein DoS-Angriff möglich wäre (vereinfacht gesagt: so viele Mails an ein Postfach senden bis der Server voll läuft).


    Zum Thema "Fortschritt": Confixx hatte die Mailquotas per Filesystem-Quota realisiert, ein IMAP-Client hatte somit keine Ahnung wie voll ein Postfach ist. LiveConfig macht das im Dovecot ganz ordentlich über "Maildirsize" und IMAP-Quota, jeder moderne IMAP-Client kann das Quota also anzeigen.


    Viele Grüße


    -Klaus Keppler

    Ich verstehe die Frage nicht wirklich.


    Eine Subdomain ist technisch betrachtet nur ein "Resource Record" innerhalb einer Domain (=Zone).
    Wenn ich für "blabla.example.org" also eine DNSSEC-Signatur haben möchte, dann muss in der dazugehörigen Zone (example.org) ein entsprechender Key hinterlegt sein.


    LiveConfig (bzw. BIND) signiert selbstverständlich auch alle Subdomains etc. innerhalb einer mit DNSSEC signierten Zone.


    Viele Grüße


    -Klaus Keppler

    So wie es aussieht kann LiveConfig die Liste der Module gar nicht auslesen, vermutlich weil die Konfiguration (derzeit) "kaputt" ist.
    Führen Sie bitte die o.g. Befehle aus (a2dissite/rm) und prüfen dann nochmal, was "liveconfig --diag" bei den Apache-Modulen ausgibt.

    Ich kann das leider nicht reproduzieren. Beim Löschen eines Vertrages unter Debian 8 sollte das liveconfig.log etwa so aussehen:


    Gehen Sie bitte im LiveConfig mal auf "Serververwaltung" -> "Web". Taucht der Apache httpd dort auf?
    Auf den ersten Blick sieht das so aus, als ob LiveConfig zum Zeitpunkt des Löschens keinen (korrekt installierten) Apache vorgefunden hatte.


    Zitat

    wie kann ich die Apache-Configs nun aktualisieren?


    Starten Sie den LiveConfig-Prozess mal neu und prüfen, ob Apache gefunden wird (Serververwaltung -> Web). Die noch vorliegende "web28"-Konfiguration können Sie mit den Befehlen

    Code
    a2dissite web28.conf
    rm /etc/apache2/sites-available/web28.conf
    service apache2 reload


    entfernen.

    Danke für die Rückmeldung.


    1. PHP 7.1 meldet nach der Installation das die "libltdl.so.7" nicht gefunden werden kann.


    Interessant... die libltdl wird eigentlich sehr häufig benötigt, daher wundert es mich etwas dass diese nicht durch irgendeine andere Abhängigkeit installiert wurde.
    Wir haben nun eine Abhängigkeit auf libltdl7 in alle PHP-Pakete mit aufgenommen.


    2. PHP 5.5 meldet das Modul pdo_mysql.so ein "undifined symbol....".


    Danke, die mysqlnd.ini wurde versehentlich vergessen. Update folgt in Kürze.

    Die PHP-Pakete für Debian 9 wurden eben nochmal aktualisiert, was zwei Fehler behebt:

    1. der "sendmail_path" war falsch gesetzt (der Versand von Mails via sendmail führte daher zu einem Fehler wenn "sendmail_path" nicht explizit via .ini-Datei gesetzt wurde)
    2. das in PHP 5.6 enthaltene OpenSSL hatte die CA-Zertifikate an einer falschen Stelle gesucht (/usr/local/lib/openssl-1.0.2/certs statt /usr/lib/ssl/certs) - das führte zu Fehlern sofern man nicht mit "verify_peer=false" arbeitet.


    Wir testen diese beiden Fälle künftig automatisiert durch.


    Viele Grüße


    -Klaus Keppler

    Das Update (v2.4.0-r4607) steht nun bereit - damit werden die o.g. Dateien auch bei Neuinstallationen angelegt.
    Der Fehler war, dass wir diese Dateien auf unseren Testservern nicht automatisch gelöscht hatten, somit fiel uns das leider nicht auf.