Beiträge von kk

  • LE Zertifikat für LiveConfig SSL verwenden

    Zitat von suppenuser

    Zum Einen: Wenn ich mir anschaue, wie oft hier eine Verlängerung eines LC-Zertifikats nicht klappt und nachgearbeitet werden muss, dann setze ich ehr auf stabiles, bewährtes und gebe ein paar Cent dafür aus.


    Als wenn es da keine Probleme gäbe... ;) (Verlängerung schlichtweg vergessen weil manuell notwendig, CA inzwischen als "unsicher" gebrandmarkt, usw...)


    Zitat

    wenn ich in meiner eigenen -relevanten- Umgebung noch nicht einmal 10 Euro (brutto) für ein Zertifikat ausgeben will.


    Die Tatsache, dass man für ein SSL-Zertifikat Geld bezahlt, macht dieses per se doch nicht "besser".
    Let's Encrypt bedeutet, dass der Prozess für eine Basisverschlüsselung *voll automatisiert* ist. Das wäre mir persönlich wichtiger als ein Zertifkat, bei dem ich jährlich an die Verlängerung denken muss oder von der ausstellenden CA diesbezüglich zugespammt werde.


    Und wie unser gemeinsamer Freund eines (sehr empfehlenswerten) SSL-Anbieters sagt: "secure is not safe". Eine anständige Validierung (OV/EV) kostet natürlich Geld, aber vollautomatisierte DV-Zertifikate sind doch nur noch eine Gelddruckmaschine, die langsam zusammenbricht.

  • Let's Encrypt Wildcard-Zertifikate

    Die werden auch vereinfacht, aber nicht über Wildcard-Zertifikate (das wäre der falsche Ansatz).
    Demnächst wird man beim Anlegen von (Sub-)Domains direkt SSL aktivieren können - also in einem einzigen Workflow.

  • Let's Encrypt Wildcard-Zertifikate

    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.

  • Sendmail-Path PHP Mail und /etc/aliases

    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.

  • LE Zertifikat für LiveConfig SSL verwenden

    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. ;)

  • Mehrere Postfächer auf einmal ändern

    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

  • LE Zertifikat für LiveConfig SSL verwenden

    Zitat von nightshift

    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

  • LiveConfig v2.6.0

    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... :)

  • Weg von postfix.NOUPDATE = true

    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...

  • ACME - Zerfifikate >> Domainauswahl

    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.

  • End Of Life (EOL): Debian 7 ("Wheezy")

    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

  • LiveConfig v2.6.3

    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

  • Berechtigungen von /priv /tmp und /conf durch Kunden änderbar

    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.

  • Berechtigungen von /priv /tmp und /conf durch Kunden änderbar

    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

  • Postfix & DSN

    Zitat von kroerig

    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'] = ""
}