Beiträge von kk

    Die Unterstützung von Wildcard-Zertifikaten ist geplant, allerdings muss hierfür die betroffene Domain durch LiveConfig im DNS verwaltet werden, oder man muss manuell einen (von LC bereitgestellten) TXT-Record in seiner Zone anlegen. In letzterem Fall (externe DNS, manueller TXT-Record) Verlängerungen problemlos klappen ist noch nicht klar.


    Zitat

    Der manuelle Aufwand bei 40 Subdomains ist enorm!


    Warum nicht gleich für jede Subdomain ein "eigenes" SSL-Zertifikat verwenden? Ist im zweifelsfall ohnehin sicherer. Ob man das selbe Wildcard-Zertifikat für jede Domain auswählt oder gleich ein eigenes Zertifikat anlegt macht ja keinen Unterschied im Aufwand.

    Pl*k benötigt zwangsweise von jedem Benutzer/Kunden eine E-Mail-Adresse (u.a. um dann so beliebte Mails wie "We would like to hear your opinion about Pl*k" zu schicken).


    LiveConfig tut das eben nicht - in Bezug auf die DSGVO ist eine E-Mail-Adresse ein persönliches Datum, welches technisch nicht für die Erbringung der Dienstleistung (Webhosting) benötigt wird. Somit ist es prinzipiell schwer, eine Voreinstellung hierfür zu treffen.


    Wer seinen Endkunden die php.ini-Einstellung sendmail_from ermöglichen möchte, kann das mit zwei Mausklicks tun: in der php.ini-Verwaltung einen neuen Eintrag "sendmail_from" anlegen, Wert dabei leer lassen, und die Änderbarbeit auf "durch Kunden" einstellen. Dann kann jeder Kunde in seinen php.ini-Einstellungen hierfür einen Wert eintragen.

    Zitat

    Warum ist das hier so umständlich?


    Der große Unterschied zu Plesk ist, dass da der Webserver immer (ob man will oder nicht) durch das Control Panel mit verwaltet wird. Somit ist es auch keine Zauberei, die Autorisierung für das SSL-Zertifikat dort in die Apache/NGINX-Konfiguration zu bekommen.
    Die Architektur von LiveConfig ist da grundlegend anders. Wenn auf einem Server kein Webserver betrieben/verwaltet wird, dann kann dort keine SSL-Autorisierung durchgeführt werden.


    Ein Workaround ist ja bereits beschrieben (Reverse Proxy) - wir arbeiten aber an einer eleganteren Lösung.


    Zitat

    Nebenbei. Man darf von einem LC-Betreibr schon erwarten, das er ein echtes Zertifikat verwendet.


    Das ist Quatsch. SSL-Zertifikate von Let's Encrypt sind genauso "echte" Zertifikate, der Validierungsvorgang ist sogar transparenter als bei manchen kommerziellen CAs. ;)

    Schwierig... eine "falsche" Domain gibt es an sich ja nicht, da die Postfachnamen im Confixx gar keinen Domainnamen angefügt hatten.


    Nehmen wir an, in Confixx gab es die Domains "test1" und "test2", und das Postfach hieß "web1p1".
    Dann waren effektiv zwei Weiterleitungen angelegt (info@test1 -> web1p1 sowie info@test2 -> web1p1)


    Beim Import in LiveConfig wird mit dem Benutzernamen (web1p1) und der erstbesten Domain (z.B. test1) ein Postfach angelegt => web1p1@test1. Die beiden Weiterleitungen (info@test1 und info@test2) werden unverändert übernommen.


    Existiert für ein Postfach nur eine einzige Weiterleitung (z.B. im Confixx nur die info@test1 auf web1p1), dann optimiert der cfximport das so, dass auch nur ein Postfach ohne Weiterleitung angelegt wird: web1p1@test1, mit dem Alias "info".


    Es ist also nicht damit getan, die Postfächer einfach auf eine andere Domain umzustellen - in der Regel gibt es noch "kollidierende" Weiterleitungen, die erst gelöscht werden müssen.


    Es besteht grundsätzlich schon die Möglichkeit, über einen Eingriff in die Datenbank einige Mailkonfigurationen auf einen Schlag zu ändern (z.B. das Quota) - das klären wir am liebsten aber im Einzelfall per Mail an support@liveconfig.com (wir möchten vermeiden, dass sich jemand ins Knie schießt...)
    Ein Umbenennen mehrerer Postfächer könnte schwierig werden, wenn es kollidierende Weiterleitungen gibt. Ansonsten ist das evtl auch möglich, daher bitte kurze Mail an uns.


    Viele Grüße


    -Klaus Keppler

    Ich habe genau selbiges mit der aktuellen Version probiert, aber ich lande egal was ich mache nachher wieder beim Hostname.url:8443 mit dem selbst signiertem Zertifikat.


    Wann genau landen Sie auf der Seite mit dem selbstsignierten Zertifikat - direkt nach dem Aufruf der URL, oder erst nach dem Abschicken der LiveConfig-Anmeldedaten?


    Zitat

    Als Proxy Weiterleitung sind https://localhost:8443/* bei HTTP und HTTPS eingetragen


    Das macht nicht viel Sinn. Bei HTTP tragen Sie bitte eine Weiterleitung auf https://acp.meinedomain1.de/* ein, und nur bei HTTPS die o.g. Proxy-Weiterleitung.


    Ansonsten können Sie uns gerne mal den "echten" Domainnamen an support@liveconfig.com schicken, vielleicht fällt uns da was auf.


    Viele Grüße


    -Klaus Keppler

    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.