Beiträge von kk

    Suchen Sie bitte mal im /var/log/mail.log, was da so zum lcsam-Prozess drin steht (am besten per grep). Wenn lcsam nicht mehr läuft, müsste es sich natürlich irgendwann beendet haben. Vielleicht gibt das Log mehr Auskünfte dazu.


    Ich gehe davon aus, dass Sie die aktuelle LC-Version einsetzen? (v1.7.5-r3127)

    Ja, DNSSEC wird unterstützt, offiziell aber noch als "Beta".
    Soweit wir das bislang getestet haben funktioniert alles (auch dynamische Zonen-Updates werden korrekt signiert), das mit dem Key-Rollover müssen wir aber noch ausführlicher prüfen.

    Hallo,


    weil sich bei uns die Anfragen zur v1.8 nun häufen, möchte ich an dieser Stelle mal eine kurze Info zum Zwischenstand geben.


    v1.8 hat ja zwei Schwerpunkte: die Unterstützung eigener CSS-Templates sowie der Ausbau der DNS-Verwaltung (frei konfigurierbare A/MX/CNAME/etc. Records).


    Zum CSS: die Arbeiten hieran waren etwas umfangreicher als ursprünglich angenommen. Wir haben die Gelegenheit genutzt, die komplette HTML-Erzeugung zu optimieren. Das heißt: über 80 Eingabemasken wurden komplett überarbeitet, außerdem wurden die meisten unserer eigenen JavaScript-Funktionen in Form von jQuery-Plugins umgeschrieben. Diese Arbeiten sind nun zum größten Teil erledigt und werden diese Woche abgeschlossen.
    Erwähnen möchte ich noch, dass neben den geänderten Eingabemasken parallel auch alle Tests überarbeitet werden mussten, da sich die XPath-Ausdrücke im HTML natürlich auch geändert haben. Da dauert leider alles etwas.


    Zum DNS: die "komplizierten" Sachen sind auch erledigt (insbes. Sicherstellung der dynamischen Zonen-Updates, Vermeidung von Fehlkonfigurationen). Hier werden aktuell "nur" noch die Eingabemasken angepasst, was ebenfalls in den nächsten Tagen abgeschlossen ist.


    Nicht zuletzt wurde natürlich auch an einigen anderen Stellen Verbesserungen durchgeführt. Die Postfix-Verwaltung (postfix.lua) wurde komplett überarbeitet und stark vereinfacht; wer eigene Einstellungen an der main.cf vornehmen möchte, kann das nun mit einer ganz einfachen "Overlay"-Tabelle machen. Beispielcode ist dann im nächsten Handbuch enthalten.


    Zudem wurde angeregt, die Lua-Scripte auf Github zu pflegen. Wir haben nach kurzer Besprechung beschlossen, das einfach mal auszuprobieren. Unsere eigene Versionsverwaltung wird unabhängig davon weiter gepflegt werden, der Stand dann aber regelmäßig mit Github abgeglichen. Aus Zeitgründen werden wir das aber erst nach der Freigabe von LiveConfig v1.8 angehen.


    Voraussichtlich am Mittwoch (19.11.) werden wir einen separaten Demo-Server mit der v1.8 bereit stellen, um sich schon mal einen ersten Eindruck vom neuen Look&Feel verschaffen zu können.


    Viele Grüße


    -Klaus Keppler

    Könnten Sie das "klappt nicht" bitte etwas konkretisieren?
    Bei all unseren Testsystemen klappt nämlich der Statistikzugriff absolut reibungslos auf der jeweils im LiveConfig eingestellten Subdomain - egal ob diese nun ein "www" davor hat oder nicht.


    Wenn Kunden .htaccess-Dateien mit Rewrite-Regeln anlegen, die dann eventuell die Erreichbarkeit der Statistik beeinträchtigen, dann ist das Sache der jeweiligen Kunden (LiveConfig kann hierauf ja keinen Einfluss nehmen).


    Viele Grüße


    -Klaus Keppler

    Noch mal als Hinweis: "example.org" ist kein Hostname.
    "www.example.org" ist auch kein Hostname.
    "www" ist ein Hostname. "example.org" ist ein Domainname. "www.example.org" ist ein FQDN (Fully Qualified Domain Name).


    Der Befehl "hostname" sollte "www" ausspucken. Der Befehl "hostname -f" sollte "www.example.org" ausgeben.


    Viele Grüße


    -Klaus Keppler

    Äh - die exakte Subdomain, unter der die Statistik erreichbar sein soll, lässt sich doch über LiveConfig einstellen...
    Hosting -> Webspace -> Web-Statistiken
    In dem Popup, in dem man auch Benutzername & Passwort einträgt, wählt man auch die gewünschte Subdomain aus. Wer seine Statistiken unter "www.example.org" abrufen will, wählt eben "www.example.org" aus, und nicht "example.org".

    Standardmäßig sieht LC für die PHP-Einstellung error_reporting den Datentyp String/ Zeichenkette vor.


    Ist schon länger bekannt - wird vermutlich auf spezielle Bitmasken hinauslaufen. Wer nämlich mod_php nutzt, muss beim php_admin_value die Zahlenwerte angeben - dort können die PHP-Konstanten (E_*) nicht geparsed werden.
    LiveConfig setzt bewusst keine error_reporting-Einstellung, sondern kopiert standardmäßig nur die Werte aus der Standard-php.ini.


    Zitat

    Wenn eine PHP-Einstellung in LC gesetzt ist, aber keine druckbare Zeichen enthält (NULL) schreibt LC in die php.ini Konfiguration jeweils None, was m.E.n. kein funktionierender Ersatz für NULL ist.


    Laut PHP-Doku ist aber genau "None" der zu setzende Wert für "nichts". Quasi das "NULL" für php.ini.


    Zitat
    Code
    geoip.custom_directory =


    statt


    Code
    geoip.custom_directory = None


    Haben Sie eine Quelle dafür?


    Zitat

    Habe ich das Verhalten von PHP richtig verstanden hat das auch für einige Crashes beim Starten von php-cgi durch Apache geführt.


    Lässt sich das reproduzieren?


    Zitat

    Auf der Seite Domains bei den Einstellungen einer Domain enthält das Attribut value des <option>-Knotens der Standard-PHP-Version keinen Wert:


    Ist auch kein Fehler, sondern durchaus so beabsichtigt: damit "markiert" LC die Standard-PHP-Version.


    Ich kann da bislang also keine "schwerwiegenden Bugs" erkennen.

    Mit folgendem Befehl finden Sie alle Dateien, die der Gruppe "web2" gehören:

    Code
    find / -group web2


    Vielleicht tauchen da ja die ganzen Dateien auf, die zu dem hohen Quota-Wert führen.


    Ansonsten: es muss heißen "repquota -ag", nicht "-a" (das "-g" ist wichtig für Group Quota). Ebenso bei quotacheck das "-g" verwenden.

    Die phpinfo() zeigt an, wo Ihr PHP nach der php.ini sucht. Vermutlich woanders als Sie möchten. ;)
    Schauen Sie sich mal die configure-Optionen "--with-config-file-path=" und "--with-config-file-scan-dir=" an.

    Das ist so beabsichtigt. Kaum ein E-Mail-Programm unterstützt IDNs. Würden hier die Domains nun in UTF8 angezeigt (statt Punycode), würden die Kunden naiv ihre "info@müller-möhren.de" einrichten und sich dann wundern warum keine E-Mails ankommen...


    Viele Grüße


    -Klaus Keppler

    Ist seit v1.7.5-r3135 in unserer Entwicklungsversion drin, also im kommenden Update enthalten.
    Die Preview (v1.8) wird freigegeben sobald der Umbau der HTML/CSS-Ausgabe fertig ist (bis dahin ist die GUI kaum nutzbar) - wir sind damit aber noch mindestens bis Ende dieser Woche beschäftigt.


    Viele Grüße


    -Klaus Keppler

    Zitat

    Zur Anmeldung an LiveConfig fügen Sie dann ab sofort den jeweils aktuellen Token an Ihr Passwort an. Wenn Ihr Passwort beispielsweise „PaSsWoRt“ lautet und Ihr Token-Generator die Zahl „123456“ anzeigt, dann geben Sie auf der LiveConfig-Anmeldeseite als Passwort „PaSsWoRt123456“ ein.


    Quelle: Handbuch.
    Und in dem Popup-Fenster während der OTP-Einrichtung wird auch darauf hingewiesen. ;)

    Ja, ganz einfach: in der php.ini-Verwaltung in LiveConfig (Hosting -> php.ini) die entsprechenden Variablen bearbeiten oder entfernen, und ganz am Ende dort auf den Button "Vorlage anwenden"*) klicken.


    *) "Vorlage anwenden" ist die Übersetzung von "Apply template", wird künftig aber "Änderungen übernehmen" heißen. Erst wenn Sie diesen Button anklicken, werden alle php.ini-Dateien aktualisiert.

    Um das kurz vorwegzunehmen: ist in der nächsten Version (v1.8) bereits komplett überarbeitet. :) Die erforderliche Passwort-Komplexität ist konfigurierbar. Während der Eingabe werden die tatsächliche und die erforderliche Komplexität angezeigt. Mit v1.8.1 gibt's zusätzlich noch eine konfigurierbare Passwort-Blacklist (quasi Dictionary).
    Die Änderungen sind in der Entwicklungsversion komplett abgeschlossen - da wir aber derzeit noch mit groben Umbauarbeiten bei der HTML-Ausgabe beschäftigt sind (HTML5 & eigene CSS-Templates) dauert's noch einige Tage bis zu Freigabe der nächsten Preview.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    ja, der Fehler ist bereits bekannt und hier in der Entwicklungsversion auch schon behoben. Das Default-Zertifikat kann/soll nicht für vHosts verwendet werden.
    Legen Sie bitte einfach ein neues, selbst-signiertes Zertifikat an und verwenden das dann.


    Viele Grüße


    -Klaus Keppler