Beiträge von kk

    Hallo,
    hat jemand eine Ahnung wie genau ich opcache für ein bestimmten Webkunden via LC deaktivieren kann? Global geht es ja via opcache.enable=0 aber wie bekomme ich es hin, nur einen bestimmten Kunden zu deaktivieren?


    Eigentlich ganz einfach:

    • als "admin" anmelden. Auf "Hosting" -> "PHP-Einstellungen" gehen. Neue Einstellung anlegen: Name="opcache.enable", Typ=Ja/Nein, Wert=Ja, Änderbar: pro Vertrag (oder: durch Kunden)
    • anschließend den Button "Änderungen anwenden..." klicken!
    • dann: Vertrag des betroffenen Kunden bearbeiten. Dort den Tab "PHP-Einstellungen" anklicken, "opcache.enable" auf "Nein" setzen.


    Sollte eigentlich reibungslos funktionieren. Ansonsten hilft nur ein Blick in eine phpinfo() (um zu sehen welche php.ini geladen wird).


    Viele Grüße


    -Klaus Keppler

    Ach ja: für FastCGI muss mod_fcgid und mod_suexec aktiviert sein. Prüfen Sie bitte beides (wird in Serververwaltung -> Web angezeigt). Wenn etwas davon fehlt, z.B. mit "a2enmod suexec" aktivieren und optional LiveConfig anschließend neu starten (damit es die Module neu einliest).

    Wenn die Seite einfach "weiß" bleibt deutet das meist auf einen Fehler bei der PHP-Ausführung hin.
    Die ersten Schritte wären:

    1. Apache-Errorlog aktivieren (Hosting -> Webspace -> Fehlerprotokoll aktivieren)
    2. PHP-Errorlog aktivieren (Hosting -> Webspace -> PHP - Einstellungen... => dort "log_errors" auf "an" stellen)


    Nach ca. 30 Sekunden die Website erneut aufrufen. Unter "Hosting" -> "Webspace" -> Fehlerprotokoll anzeigen sollte dann irgendwas auftauchen, was weiterhelfen könnte.

    ich habe in Spamassassins diverse Anpassungen am X-Spam-Status gemacht. Leider werden diese nicht übernommen. Liegt das am LCSAM ?


    Ja, der "X-Spam-Status:"-Header wird durch lcsam geschrieben und nicht von SpamAssassin, daher ist der nicht konfigurierbar.


    Zitat

    Leider sind bei mir die "tests" im Mailheader immer leer, obwohl Listen angeschlagen haben.


    X-Spam-Status: No score=1.9 tagged_above=3.0 required=5.0 tests=[]


    Das war ein Fehler, der mit Version 2.3.0-r4354 behoben wurde (siehe auch bei GitHub) - mit dem nächsten LC-Update ist das also behoben.

    Ich habe das irgendwo anders schon mal ausführlich beschrieben. Das ist kein Fehler im klassischen Sinn, sondern eine wohl "suboptimale" Darstellung.


    Wenn jemand eine Domain anlegt ("example.org") werden automatisch zwei Subdomains erzeugt: einmal die mit dem Hostnamen "www", und einmal die mit einem leeren Hostnamen ("").


    Löscht man nun http://www.example.org, bleibt logischerweise nur noch die Subdomain mit dem leeren Hostnamen (example.org) übrig.
    Löscht man auch diese Subdomain, wäre streng genommen nur eine "leere" Domain übrig. LiveConfig kann das derzeit noch nicht separat hervorheben - daher sieht die "leere Domain" genauso aus wie eine Subdomain mit leerem Hostnamen (alles klar soweit?)
    Legt man nun eine Subdomain "www" an, dann existiert nur http://www.example.org, nicht aber example.org.


    Ich hoffe, etwas Licht in die Sache gebracht zu haben. :)


    Viele Grüße


    -Klaus Keppler

    Kurz zur Info: bei einem Update der Zeitzonen-Datenbank sind offenbar einige Verknüpfungen kaputt gegangen :( Im kommenden LiveConfig-Update ist das korrigiert, künftige Zeitzonen-Updates werden wir "anders" machen.


    Viele Grüße


    -Klaus Keppler

    Es sollte eine Subdomain angelegt werden in diesem Fall nbv.mk-xxx.de


    Das Problem war, das keine DNS Einträge gemacht wurden somit die Domain keinen DNS Eintrag hat bzw keinen A Eintrag, weil LiveConfig eben eine Subzone angelegt hat anstatt eine Subdomain. Somit funktioniert die Subdomain nicht da kein A-Eintrag vorhanden war.


    Woran haben Sie ausgemacht, dass der A-Record nicht angelegt wurde?
    Das Bearbeiten von DNS-Einträgen läuft ausschließlich über dynamische DNS-Updates. In der Zonendatei (/var/lib/bind/<Zone>.db) ändert sich dabei in der Regel nichts. Es wird aber von BIND eine Journal-Datei (binär) erzeugt, welche alle Updates protokolliert.
    Mit anderen Worten: der Inhalt der Zonen-Datei alleine ist erstmal nicht aussagekräftig. Man kann die Zonendatei aber durch BIND neu schreiben lassen (z.B. mit "rndc freeze <zone>", "rndc thaw <zone>").


    LiveConfig schreibt selbst auch keine $ORIGIN-Abschnitte, das macht BIND selbst. Und das ist - wie gesagt - völlig ok und normal. Das geschieht manchmal etwa wenn nur einzelne DNS-Einträge eine abweichende TTL aufweisen. Ohne die vollständige Zonendatei kann ich an dieser Stelle auch nur herum raten...


    Die ausnahmslos einzige Möglichkeit um zu prüfen, ob ein gewünschter DNS-Eintrag angelegt wurde ist, diesen direkt beim Primary DNS per "dig" abzufragen:

    Code
    dig @[I]primary.dns.server[/I] [I]name.der.subdomain[/I] ANY


    Viele Grüße


    -Klaus Keppler


    Ich verstehe das Problem irgendwie noch nicht ganz, mit den Daten kann ich leider nichts anfangen.
    Was für eine Subzone nochmal? Wenn BIND eine Zonen-Datei aktualisiert, dann ist es völlig normal dass er identische Subzonen in eigene $ORIGIN-Abschnitte gruppiert.
    Bitte beschreiben Sie, was genau gemacht wurde, was genau passiert ist und was daran falsch war.

    Also der Syslog gibt folgende Information zurück:

    Code
    Nov  2 10:10:24 web1 named[14531]: dns_dnssec_findzonekeys2: error reading private key file meindomainname.xyz/NSEC3RSASHA1/59090: file not found


    Das sagt doch eigentlich schon alles...
    Prüfen Sie bitte mal, ob auf Ihrem Primary DNS die Dareien /etc/bind/keys/K<Domain>.+007+<Id>.(key|private) vorhanden sind.
    Falls diese nicht mehr existieren (auch nicht im Backup), dann müssen Sie einen neuen DNSSEC-Key für diese Domains anlegen und diesen auch beim Domainregistrar aktualisieren.


    Viele Grüße


    -Klaus Keppler

    Ich habe leider Gottes das gleiche Problem mit einer virtuellen Kiste unter Debian 8. Den Trick von HBO hab ich auch schon einmal ausprobiert, leider ohne Erfolg. Bei mir gibts nur solche Einträge, aber keine Socketfehler:


    Code
    [749|755] Error while updating NS records (host '', zone 'meindomainname.xyz'): DNS update failed


    Kann mir so darauf erstmal keinen Reim machen, warum es von hier auf da nicht mehr funktioniert. Das Problem ist mir nach dem Hinzufügen einer neuen Kundendomain aufgefallen. (welche aber problemlos angelegt wurde)


    Wird vielleicht ein Nameserver als NS-Record hinterlegt, der in der selben Zone wie die betroffene Domain liegt?
    Ansonsten sollte es bei fehlgeschlagenen DNS-Updates eigentlich eine Meldung in /var/log/messages bzw. /var/log/syslog geben, oder ggf. im systemd ("journalctl").

    Unter welchen Umständen können es unzählige Zeilen in die Logfiles fremder Speicherplätze schaffen?


    Kurz gesagt: gar nicht.
    Webalizer wird für jeden Webspace ausschließlich mit /var/log/<Vertrag>/logs/access.log ausgeführt - anders gesagt: es fließen keine Daten "fremder" Webspaces in Webalizer mit ein.
    Suchen Sie den betroffenen Begriff einfach mal in dieser Datei, da sollten die entsprechenden Zugriffe protokolliert sein.


    In der Datei /etc/apache2/accesslog.map sehen Sie wiederum, in welcher Logdatei jeweils die Zugriffe der einzelnen Domains landen (in der accesslog.map steht jeweils nur der Domainname, der in der vHost-Konfiguration bei "ServerName" angegeben ist, die "ServerAlias"-Domains tauchen darin nicht auf).

    Hallo,


    danke für den Hinweis! Es handelte sich hier um einen Fehler, Thai kann tatsächlich nur auf der Anmeldeseite korrekt ausgewählt werden. Der Fehler wurde mit v2.3.0-r4377 behoben, diese Version wird in Kürze als Preview bereitgestellt.


    Viele Grüße


    -Klaus Keppler

    Wie genau finden Sie heraus, dass der MX nicht hinzugefügt wurde?
    Der einzige zuverlässige Weg um das zu prüfen ist ein DNS-Lookup am Primary DNS der Domain:


    dig @name.server example.org MX


    Der Blick in die Zonen-Datei reicht nicht (die wird nur einmalig beim Anlegen der Domain erzeugt, alle Änderungen erfolgen über dynamische Updates). Ein "normaler" nslookup beim Standard-Resolver kann wiederum gecachte Negativ-Auskünfte zurückgeben.


    Im Zweifelsfall kann man auf dem Primary DNS den Befehl "rndc freeze example.org" und danach "rndc thaw example.org" ausführen, damit werden alle bis dato erfolgten dynamischen Änderungen in die Zonen-Datei geschrieben.


    Viele Grüße


    -Klaus Keppler

    Derzeit planen wir das Thema etwa Mitte November anzugehen. Wir streben dabei natürlich die "sauberste" Lösung an: eine Dual-Konfiguration mit RSA- und ECDSA-Schlüsseln. Das ist nicht ganz trivial (das Datenbankschema muss angepasst werden, der Bestellvorgang bei Let's Encrypt, u.v.m.). Ich bitte also um etwas Geduld - sobald es los geht, geben wir Bescheid.

    Das gab es bereits an anderer Stelle. Let's Encrypt ist ab der Standard-Version enthalten, genauso wie auch einige andere Funktionen (u.a. DNSSEC).


    Wasser ist auch kostenlos, trotzdem wird es weder aus der Leitung noch in Flaschen verschenkt.
    So ist es eben auch mit den SSL-Zertifikaten. Die Lizenzgebühren für LiveConfig decken unseren Entwicklungsaufwand - es ist uns dafür völlig egal ob oder wie viele Let's-Encrypt-Zertifikate (oder Kunden, Domains, ...) damit verwaltet werden. Mit 2,35 EUR netto pro Monat bei einer Basic-Lizenz haben wir eben weniger Ressourcen als mit z.B. 8,24 EUR. Der Unterschied von 5,89,- EUR netto pro Monat entspricht etwa zwei Bier, drei Kaffee-to-Go oder einer Schachtel Zigaretten pro Monat...