Beiträge von kk

    Die Preview wurde eben auf v1.8.3-r3577 aktualisiert; diese Version wird dann im Laufe des Tages als Produktivversion freigegeben.


    Es gab keine nennenswerten Änderungen mehr, lediglich kleinere "Schönheitskorrekturen" und Detailverbesserungen.


    Alles Weitere dann in Kürze in einem separaten Posting zum v1.8.3-Release.


    Viele Grüße


    -Klaus Keppler

    deb http://ftp.debian.org/debian squeeze main contrib non-free
    deb http://security.debian.org squeeze/updates main contrib non-free


    Ja, dann haben Sie einfach ein hoffnungslos veraltetes Debian 6 am Laufen.
    Wenn Sie Debian 6 LTS nutzen möchten, müssen Sie das zusätzlich mit aufnehmen:

    Code
    deb http://ftp.debian.org/debian [U][B]squeeze-lts[/B][/U] main contrib non-free


    Es nutzt nichts, wenn die ClamAV-Virendefinitionen durch Freshclam aktualisiert werden, der ClamAV selbst aber alt bleibt.

    Für Postfächer muss in LiveConfig immer ein Quota angegeben werden (die Gesamtgröße aller Postfächer kann in einem Vertrag zwar unbegrenzt sein, ein Postfach braucht aber immer ein Limit).


    Eine pauschale Antwort, was in diesem Fall zu machen ist, kann man nur schwer geben - das kommt zu sehr auf den Einzelfall an. Die einfachste Lösung könnte sein, in der Confixx-Datenbank für die Postfächer einen Quota-Wert festzulegen (kann ja auch ein großer Wert sein, z.B. 10 GB).

    Die Preview wurde nun zum voraussichtlich letztem Mal aktualisiert (v1.8.3-r3569). Damit werden nun u.a. für DKIM die notwendigen Resource-Records automatisch im DNS angelegt (wenn die Domain auf "eigenen" Nameservern verwaltet wird).


    Letzte Baustelle sind noch die OpenDKIM-Init-Scripte für CentOS - dann sollte dem Release nichts mehr im Wege stehen.


    Viele Grüße


    -Klaus Keppler

    Kurzer Hinweis: das lcdbdump-Utility (siehe KB#15) wurde überarbeitet - der erzeugte SQL-Dump lässt sich nun ca. 46x schneller in MySQL importieren. :)
    Die Download-Links sind die selben geblieben; ob man die "neue" Version hat sieht man durch Aufruf des Programms ohne Parameter - in der neuen Version wird dann das Release-Datum angezeigt.


    Viele Grüße


    -Klaus Keppler


    Hallo,


    wenn möglich führen Sie den SELECT-Befehl aus dem Slow-Query-Log mal mit dem Befehl "EXPLAIN " (als Präfix) aus. Das Ergebnis schicken Sie uns am besten per Mail (support@liveconfig.com).
    Ich tippe darauf, dass es eni großes "Ungleichgewicht" in der Schlüsselverteilung gibt, was zu der langen Ausführungszeit führt.
    Unabhängig davon sollten aber auf einer SSD Abfragen mit 10 Mio durchsuchten Records trotzdem keine 22 Sekunden dauern...


    Viele Grüße


    -Klaus Keppler

    Ja, der Flaschenhals dürfte bei SQLite liegen. Genaue "Grenzwerte" bis wann SQLite ausreicht gibt es nicht, da es zu sehr auf die jeweilige Maschine ankommt (I/O-Leistung, tatsächliche Auslastung, etc.). Wichtiger als die Zahl der Domains ist eher die Zahl der Verträge und Postfächer - für diese werden regelmäßig Statistikdaten eingesammelt (insbes. Quota), was die Datenbank ziemlich beschäftigt.


    Eine Umstellung von SQLite auf MySQL ist aber problemlos möglich, siehe http://www.liveconfig.com/de/kb/15
    Auf die SQLite-Datenbank können Sie mit dem Tool "sqlite3" zugreifen (ist in jeder Distribution über den Paketmanager installierbar).


    Viele Grüße


    -Klaus Keppler

    Aha. Der Ursprung würde mich ja mal interessieren. :)
    Fakt ist, dass zumindest ich keinen "Showstopper" kenne, warum LiveConfig nicht mit Debian Jessie zurecht kommen würde. Die Versionen der zu verwaltenden Software sind unspektakulär, und da Jessie auch mit systemd noch "klassische" Init-Scripte unterstützt klappt soweit alles.
    Unsere automatisierten Tests laufen inzwischen auch unter Debian Jessie, dort waren keinerlei Anpassungen notwendig. Einen Demoserver haben wir vorgestern von Debian 7 auf 8 aktualisiert, lief einwandfrei durch.


    Lediglich das Paket "liveconfig-meta" ließ sich in v0.3.4 nicht unter Jessie installieren, da dieses noch eine Abhängigkeit zu suPHP hatte. Mit Version 0.4.0 (inzwischen im Test-Repository sowie im Source unter https://github.com/liveconfig/meta) klappt das dann aber auch reibungslos.


    Viele Grüße


    -Klaus Keppler

    CentOS 7 wird bereits seit einiger Zeit von LC unterstützt. CentOS 7.0 hatte allerdings noch einige Kinderkrankheiten (konkret hatten wir in unserer Xen-Testumgebung einen reproduzierbaren Crash von ProFTPd aufgrund eines längst in RedHat gepatchten Kernel-Bugs; mit CentOS 7.1 sollte das aber behoben sein. Bei Interesse kann ich die Fehlernummer mal heraussuchen)


    Zitat

    CentOS mit seinen 10 Jahren Laufzeit ist da sehr interessant.


    Hmm, unsere Begeisterung zur Unterstützung von CentOS 5 bis 01.04.2017 hält sich in Grenzen. ;)
    Manchmal ist es schon eine echte Herausforderung, uralte Softwarepakete halbwegs brauchbar zu konfigurieren.

    Preview wurde eben von r3555 auf 1.8.3-r3560 aktualisiert - darin wurde der Fehler mit dem ungültigen DKIM-Key behoben. Außerdem werden DKIM-Daten nun auch automatisch im DNS eingetragen/aktualisiert.
    Nun werden noch die Übersetzungen aktualisiert und ein paar weitere Änderungen/Features gemerged, morgen wir dann der "release candidate" freigegeben.


    Viele Grüße


    -Klaus Keppler

    ich dachte dieses Problem wäre schon beseitigt ?

    Code
    liveconfig (1.8.3-r3555) wird eingerichtet ...
     * Starting LiveConfig Server liveconfig
     - /usr/sbin/liveconfig: Can't listen to socket at address (null), port 8443: Address already in use
     - /usr/sbin/liveconfig: Can't open any socket for address (null), port 8443
                                                                                                                                      [fail]


    Sollte es auch...
    Die Frage ist:
    - von welcher LC-Version wurde aktualisiert?
    - was steht um den Neustart-Zeitraum herum in /var/log/liveconfig/liveconfig.log? (ggf. großzügigen Ausschnitt aus dem Log an support@liveconfig.com schicken)


    Viele Grüße


    -Klaus Keppler

    Ich persönlich halte absolut gar nichts davon, Besucher auf Basis des Quell-Landes auszuschließen (das bringt uns dann nämlich auf die selbe Ebene wie China, Saudi-Arabien, Nordkorea etc...). Wenn es konkrete Angriffe gibt empfehle ich eine individuelle IP-Filterung (z.B. fail2ban auf eine zentrale Log-Datei einrichten). Spätestens mit IPv6 ist GeoIP derzeit ohnehin nur sehr begrenzt brauchbar. Und bei dem zunehmenden IPv4-Handel und -Partitionierung ist auch da die Gefahr von "false positives" steigend.


    Unabhängig davon kenne ich die CSF-Firewall nicht im Detail und kann daher auch nichts dazu sagen.
    Individuelle Änderungen an der Apache-Konfiguration können sonst direkt in apache.lua vorgenommen werden (wird aber bei jedem Update überschrieben), oder man biegt die betroffene Funktion per custom.lua auf eine eigene Funktion um.


    Viele Grüße


    -Klaus Keppler

    Einen Fehler habe ich eben gefunden: im angezeigten DNS-Schnipsel steht "k=rsa", der OpenDKIM selbst wird aber mit "rsa-sha256" konfiguriert. Richtig wäre im DNS also "k=rsa-sha256".
    Am Nachmittag kommen die "großen" Tests (bislang prüfen wir nur ob die Dateien alle richtig erzeugt wurden und eine DKIM-Signatur vorhanden ist), da wissen wir dann sicher mehr.


    Viele Grüße


    -Klaus Keppler

    Lass ich von Liveconfig ein Schlüsselpaar erzeugen ist der Public Key immer ungültig.


    Wie äußert sich das, dass der Public Key ungültig ist?


    Zitat

    Habe ich ein Denkfehler? Müssten die Public Keys nicht identisch sein?


    Nicht unbedingt - das was da angezeigt wird ist nur die Base64-codierte Darstellung des RSA-Public-Keys. Dessen Codierung (ich glaube TASN.1) ist nicht eindeutig (soll heißen, es gibt verschiedene Codierungsmöglichkeiten für die selben Ausgangsdaten). Da macht es schon einen Unterschied ob man mit OpenSSL 0.9.8 oder 1.0.0 arbeitet.


    Bei unseren Tests gab es bislang noch keine Auffälligkeiten, wir haben aber noch nicht für alle Fälle die Tests fertig programmiert. Ich prüfe den oben beschriebenen Fall in Kürze mal manuell durch.


    Viele Grüße


    -Klaus Keppler

    Die Preview wurde eben aktualisiert (v1.8.3-r3555).
    Neben ein paar kleineren Features (Anzeige des Plattenplatzes, HTTP-Traffic-Graph für Endkunden, etc.) wurde insbesondere die DKIM-Unterstützung verbessert. Wir schließen derzeit nur noch die DNS-Integration von DKIM ab, dann erfolgt die Freigabe. Ein weiteres Preview-Update ist für nächste Woche geplant.


    Viele Grüße


    -Klaus Keppler

    Der "Bad Gateway"-Fehler tritt auf, wenn (vereinfacht gesagt) alle PHP-Instanzen voll beschäftigt sind auch auch deren Warteschlangen (Backlog) voll sind. In diesem Fall lehnen die weitere Verbindungen von NGINX ab, was dann zum "Bad Gateway" führt.
    Die Lösung ist prinzipiell recht einfach: Anzahl der PHP-Instanzen erhöhen. Das Problem ist nur, dass sich diese Option derzeit noch nicht über LiveConfig steuern lässt (ich denke wir werden das kurzfristig als weiteren Konfigurationsparameter mit aufnehmen).


    Um das vorerst mal manuell zu lösen, bearbeiten Sie die Datei /etc/nginx/sites-available/web10.conf. Am Ende der Datei steht folgende Zeile:

    Code
    # NGINX_FCGI_CHILDREN=5


    Ändern Sie die "5" in z.B. "50" und führen danach "/etc/init.d/nginx-php-fcgi restart" aus - damit sollte dieser User bis zu 50 PHP-Instanzen erhalten.


    Aber Vorsicht - dieser Wert wird wieder auf "5" zurückgesetzt, sobald was im LiveConfig im Vertrag "web10" neu gespeichert wird. Ggf setzen Sie das "+i"-Attribut (chattr +i web10.conf), damit die Datei nicht versehentlich überschrieben werden kann.

    Ab sofort stehen die aktualisierten PHP-Pakete in den Versionen 5.4.40, 5.5.24 und 5.6.8 für Debian 6 (Squeeze) und Debian 7 (Wheezy) bereit (siehe KB#22).


    Ab sofort sind auch die Module "intl" und "shmop" enthalten (Letzteres ist standardmäßig aber deaktiviert - ggf. muss man also die Datei /opt/php-5.x/conf.d/shmop.ini.disabled entsprechend umbenennen und anpassen)


    Wir planen auch für das in Kürze erscheinende Debian 8 ("Jessie") entsprechende PHP-Pakete bereitzustellen.


    Viele Grüße


    -Klaus Keppler