Beiträge von kk

    Ein LiveConfig-Neustart ist vorerst weiterhin notwendig, da LC die Paketerkennung nur beim Start ausführt.
    Wir sind derzeit dabei, den Build der PHP-Pakete komplett auf Debian-Bordmittel umzustellen (dpkg-buildpackage). Mit Debian 7.2 sind wir fertig, 7.1 läuft in diesen Minuten, dann kommen noch die restlichen (7.0, 5.6, evtl ältere). Wenn alles erledigt ist, wird die o.g. Wiki-Seite komplett neu erstellt (wenn alles gut geht etwa Mitte nächster Wocher).


    Hintergrund: die "neuen" Pakete erledigen nicht nur die Lua-Registrierung, sondern bringen auch alles mit was LiveConfig braucht, um PHP via FPM laufen zu lassen (z.B. entsprechende systemd-Unit-Files).
    Weitere Details dann hoffentlich in Kürze... :)

    Schicken Sie uns einfach eine kurze Mail an support@liveconfig.com mit der Info um welche Distribution es sich bei Ihrem Server handelt, dann schicken wir Ihnen die Ausgabe von "postconf" sowie die main.cf/master.cf eines Testsystems einfach zu.
    Letztendlich hängt es aber immer davon ab, welche Einstellungen Sie im LiveConfig aktivieren...

    Auswahllisten machen dann keinen Sinn mehr, wenn man mehr als 20 Domains auf dem Server angelegt hat. ;)


    Ich würde diesen Punkt gerne zurückstellen, der ganze Workflow der SSL-Bestellung (für DV-Zertifikate) wird derzeit überarbeitet und stark vereinfacht. Bitte aber noch ein klein wenig Geduld.

    Die LTS-Unterstützung von Debian 7 (Wheezy) ist zum 31.05.2018 ausgelaufen.


    Die nächste LiveConfig-Version (v2.7) wird Debian 7 nicht mehr unterstützen.
    Auch die zusätzlichen PHP-Pakete für Debian 7 werden wir nicht mehr weiter aktualisieren.


    Hinweise zum Upgrade von Debian haben wir im Wiki zusammengestellt - das Upgrade von Debian 7 auf 8 läuft unserer Erfahrung nach recht problemlos. Wer sich bislang noch nicht mit systemd beschäftigt hat, wird daran aber nun nicht mehr vorbei kommen.


    Im übrigen ist es wesentlich einfacher, ein System von Debian 7 auf 8 zu aktualisieren, als einen Serverumzug durchzuführen.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    ab sofort steht LiveConfig v2.6.3 (r5013) zum Download bereit.


    Es handelt sich hierbei hauptsächlich um Bugfixes. Unter anderem gab es ein Problem, wenn /var/run (oder /run) auf einem "tmpfs" (RAM-Disk) liegt - dann existiert nach einem Reboot das Verzeichnis /var/run/liveconfig/ nicht mehr, weshalb lclogsplit dann nicht starten kann.
    Mit dem Update werden auch alle vHosts neu konfiguriert, um die Option "nocreate" in die Logrotate-Konfiguration (/etc/logrotate.d/liveconfig-vhosts) aufzunehmen. Bei Systemen mit einer sehr restriktiven "umask" (z.B. 037) macht Logrotate die access.log-Dateien sonst unlesbar.


    Viele Grüße


    -Klaus Keppler

    Ah, verstehe. Wir werden die unter conf/ untergeordneten Verzeichnisse kurzfristig mit dem Immutable-Flag versehen. Preview-Update kommt in ca. einer Stunde, Release dann voraussichtlich morgen Vormittag. Während des Upgrades werden bestehende Verzeichnisse automatisch mit +i versehen.


    php.ini-Dateien kann der Kunde übrigens dennoch nicht bearbeiten (durch +i geschützt), auch wenn er die Schreibrechte für die php*-Verzeichnisse erweitert hat.

    Nein, der Benutzer hat ja keine Schreibberechtigungen in /conf und dessen untergeordneten Verzeichnissen.


    Code
    $ ls -al conf/
    total 20
    drwxr-x--- 5 www-data web11 4096 Jun 21 13:56 .
    drwxr-xr-x 8 root     root  4096 Jun 21 13:56 ..
    dr-xr-xr-x 2 web11    web11 4096 Jun 21 13:57 php5
    dr-xr-xr-x 2 web11    web11 4096 Jun 21 13:57 php56
    dr-xr-xr-x 2 web11    web11 4096 Jun 21 13:57 php70

    Welchen Sinn macht es DSN komplett zu unterdrücken?


    DSNs können unerwünscht weitere Informationen zur internen Serverstruktur ausplaudern (z.B. Namen des nächsten Hops). Es gehört eigentlich zu den "Best Practices", positive DSNs nicht zu erlauben.
    Wenn Sie das aber nutzen möchten, brauchen Sie nicht die ganze Postfix-Konfiguration sperren. Es genügt folgender Eintrag in die custom.lua:

    Code
    postfix.LOCALCONFIG = {
      ['smtpd_discard_ehlo_keywords'] = ""
    }

    Auf CentOS 7 sehen die Verzeichnisrechte so aus:


    Unter Debian 9:

    Code
    # ls -al /var/www/web1
    total 32
    drwxr-xr-x 8 root     root     4096 Jun 21 11:01 .
    drwxr-xr-x 9 root     root     4096 Jun 21 11:01 ..
    drwxr-x--- 5 www-data web1     4096 Jun 21 11:01 conf
    drwxr-x--- 3 web1     www-data 4096 Jun 21 11:01 htdocs
    drwxr-x--- 3 www-data web1     4096 Jun 21 11:01 logs
    drwxr-x--- 2 web1     web1     4096 Jun 21 11:01 priv
    drwxr-x--- 2 www-data web1     4096 Jun 21 11:01 stats
    drwxrwx--- 2 web1     www-data 4096 Jun 21 11:01 tmp

    Was jedoch unschöner ist, dass der Kunde bei LiveConfig Webhostings ebenso die Berechtigungen für /priv /tmp und /conf ändern kann. Gerade im /conf Ordner meinte dann mancher Kunde schon, herumfrickeln zu müssen..


    Uh-oh, dann ist da was anderes schief gelaufen. Das Homeverzeichnis des Kunden (/var/www/<Vertrag>) muss root:root gehören (mode 0755). Im conf-Verzeichnis darf er generell gar keine Schreibrechte haben, die PHP-FastCGI-Starter sind mittels Immutable-Flags geschützt.


    Bitte legen Sie testweise mal einen neuen Vertrag an und prüfen die Rechte der erstellten Verzeichnisse.


    [2018/06/20 13:49:40.209923] [18007|18007] Server child process 18009 terminated; uncaught signal: 11 (Segmentation fault)
    ..... + viele Zeilen mit Verweis auf Files....


    Könnten Sie uns bitte genau diese "vielen Zeilen" (den Stacktrace) an support@liveconfig.com schicken? Das könnte Hinweise darauf geben, wo genau das Problem liegt.


    Viele Grüße


    -Klaus Keppler

    Vielleicht liefert der "dmesg"-Befehl hilfreiche Hinweise?
    Ansonsten können wir Ihnen da leider auch nicht weiterhelfen - das muss sich ein Admin direkt auf dem Server anschauen.
    Der Log-Meldung nach wurde LiveConfig jedenfalls regulär beendet und ist nicht abgestürzt o.ä. - zusammen mit dem Hinweis auf ein langsames System deutet das auf den OOM-Killer hin.

    Ich habe jetzt das in der liveconfig Log gefunden.


    Das ist eine völlig normale Meldung, wenn LiveConfig beendet wird.
    Stellt sich also die Frage, warum LiveConfig beendet wird (bzw. wer das beendet).
    Ein Blick in /var/log/messages bzw. /var/log/syslog gegen 06:02:58 könnte da weiterhelfen.


    Eine Möglichkeit: ein Backup-Prozess der um diese Zeit läuft, zu viele Ressourcen benötigt und über den OOM-Killer LiveConfig abschießt...

    LiveConfig arbeitet überhaupt nicht mit den User-IDs, sondern nur mit den Benutzernamen.
    Daher dürfte es auch künftig keine Probleme seitens LiveConfig geben. :)

    Muss man mehr machen, als die User ID im[INDENT]/etc/passwd
    [/INDENT]
    ändern


    Soweit nicht, da LiveConfig keine User-IDs speichert sonder nur mit den Usernamen arbeitet.


    und dann alle Files im Filesystem mittels[INDENT]chown -R 20000:20000 /var/www/web1
    [/INDENT]
    [INDENT]chown -R 20000:20000 /var/mail/[/INDENT]


    NEIN - bloß nicht!
    Die Rechte in /var/mail/ müssen gar nicht geändert werden, da die Mails dem Systemuser "mail" gehören.
    Bei den Webspaces ist das deutlich differenzierter - einige Verzeichnisse gehören <Vertrag>:www-data, andere <Vertrag>:<Vertrag>, usw.
    Der Benutzer darf KEINE Schreibrechte in seinem Homeverzeichnis haben, das muss weiterhin root:root gehören!


    Führen Sie einfach das Script "/usr/lib/liveconfig/lcservice.sh fix-permissions [Vertrag]" aus (optional mit einem Vertragsnamen, oder ohne Parameter um alle Webspace-Verzeichnisse durchzugehen).
    (am besten im ersten Durchgang mal nur mit einem einzelnen Webspace testen, also z.B. "/usr/lib/liveconfig/lcservice.sh fix-permissions web1")