Hey... wäre langsam mal toll wenn man das Server Zertifikat auch automatisch erneuern könnte damit...
LiveConfig normal auf :8443 laufen lassen, zusätzlich aber eine Domain (z.B. config.example.com) im Webspace via LiveConfig erstellen. Weiterleitungs-Typ Proxy, Ziel: "https://localhost:8443".
Für "config.example.com" bekommt man ganz normal Zertifikate.
Die wichtigsten Änderungen sind:
- Verträgen aus beliebiger Tiefe können nun einem Administrator oder Reseller neu zugeordnet werden
- Status-Anzeige auf Kunden-Detail-Seite wenn Kunde gesperrt/deaktiviert ist
- Passwort von zusätzlichen (virtuellen) FTP-Accounts wurde zurückgesetzt wenn nur das Startverzeichnis geändert wurde
- Lua: Fehler in LC.timeout()-Funktion behoben, wodurch z.B. Dienste manchmal zu früh aktualisiert (reloaded) wurden
- SOAP API: Berechtigungen wurden nicht aktualisiert wenn das Angebot eines Vertrags via HostingSubscriptionEdit() geändert wurde
wuhu! Danke! 
Nun zur Frage:
Gibt es eine Möglichkeit die mkdir und chown Befehle beim Erstellen des Vertrags zu automatisieren
Die von Herrn Keppler erstellte Funktion kann auch genutzt werden, um direkt in LUA neue Verzeichnisse etc zu erzeugen:
Ist jetzt nur ne Vermutung aber vielleicht meint er das die jeweils Aktuellste Version installiert werden sollte und nicht das eine schon installierte geupdatet wird.
Das war auch meine Vermutung. Ändert aber nichts an meinem skizziertem Kunden-Fehlverhalten.
Wenn Kunden ihre CMS nicht erneuern, bringt ein Installer mit der neuesten Version nur wenig Vorteile.
In der heutigen Zeit muss/sollte Software Top-Aktuell gehalten werden.
Was hat diese Aussage mit dem Installer zu tun?
Konkret:
- Kunde installiert heute das jetzt aktuelle Wordpress 4.6.
- nächste Woche kommt Wordpress 4.6.1 raus. Die Wordpress-Installation ist also nicht mehr aktuell.
- das LC-Repository bleibt auf 4.6. Der Kunde installiert ein zweites Wordpress, immer noch 4.6. 4.6.1 wäre aktuell.
Wo ist bei diesem Szenario nun konkret ein Problem des Installers?
Wenn der Kunde das CMS anschließend nicht selbst aktuell hält, bringt der neueste Installer auch nichts.
Dass "halbwegs aktuell" durchaus zu empfehlen wäre, gerade bei Sicherheits-kritischen Lücken, erklärt sich von selbst. 1-2 Versionen hinten dran stellt aber jetzt kein Problem dar, IMHO.
Da ärgern mich komplett fehlende Webanwendungen mehr. Shopware ist da ganz vorne 
- Aufruf der Inhalte eines Webspace, direkt per Einzel-IP, z.B. http://198.33.22.43 (war mit Confixx möglich)
Das wurde jetzt erst gesperrt:
Zitat von ChangelogIP-Adressen können nun nicht mehr als "externe Domains" hinzugefügt werden
(Halte ich auch für den richtigen Weg. Es gibt Subdomains - und mit IPv6 sollte ja eh keine IP mehr direkt angesprochen werden...)
Let's Encrypt verschickt meines Wissens aktuell keine E-Mails mehr (zumindest nicht wenn das betroffene Zertifikat inzwischen verlängert wurde).
Korrekt. Wir hatten letztens den Fall, dass bei einem CN die Validierung abgelaufen ist und LC das Zertifikat nicht erneuert hat. Dann kam von Let's Encrypt eine Hinweis-Mail.
Beim erfolgreichen Renew meldet sich Let's Encrypt aber nicht - LiveConfig auch nicht.
Finde die Erinnerung SEHR wichtig. Danke!
(nichts desto trotz sind da noch einige Bugs offen ... )
Langsam bereue ich den Wechsel zu LC wirklich.
Über Confixx konnten Domains über die GUI auch nicht verschoben werden.
Spätestens bei den Postfächern im Dateisystem wäre auch die manuelle Datenbank-Änderung am Ende. Das müsste nämlich auch noch manuell gemacht werden.
Ist aktuell weder in Basic noch sonstwo möglich. "Verschieben" gibt es leider noch nicht.
Das ist nur ein Make-UP Problem, viel schlimmer ist es das der Wiederverkäufer einstellen kann was er will (zumindest bei uns).
Kann ich bestätigen. Ticket(s) sind auch schon offen.
- Wiederverkäufer-Account wird z.B. mit 5GB Mail-Quota erstellt
- der Kunde/Wiederverkäufer kann nun einen Endkunden-Account mit 10GB Quota (oder auch unlimitiert!) erstellen
- und der Endkunde kann sich problemlos ein Postfach mit mehr als 5GB Quota anlegen.
Entweder bin ich da zu doof, den Reseller-Account richtig zu konfigurieren, oder da besteht ein massives Problem.
Dass man anfangs beim Anlegen eines Endkunden immer die Auswahl zwischen mod_php, suPHP und FastCGI hat, obwohl der Server nur FastCGI unterstützt, kann ich gerade noch verschmerzen.
Hier noch die ganz blöde Frage: wo legt man dieses Zertifikat konkret an?
Ganz regulär als SSL-Zertifikat, wie ein regulär gekauftes halt auch - nur kümmert sich ACME um den Renew.
Danach bei der Serververwaltung auswählen.
LE-Zertifikate und "reguläre" manuelle Zertifikate unterscheiden sich nur dadurch, dass sich LiveConfig um den Renew kümmert.
Auch bisher musste die Server-Konfiguration manuell erneuert werden, wenn das Zertifikat getauscht wurde.
Vielen Dank für den Tipp, der austausch des Zertifikates hat schon abhilfe geschaffen.
ZitatDa fällt mir doch gleich folgende Frage an den Chef ein: wie sieht es aus mit der Verwaltung der Serverzertifikate, erstellt und verlängert durch Let's Encrypt?
öhm:
Zitat von http://www.liveconfig.com/de/changelogÄnderungen in Version 2.2.0-r4254 (14.07.2016):
(...)
- SSL-Zertifikate für SMTP, POP3/IMAP und FTP werden aktualisiert wenn ein SSL-Zertifikat bearbeitet/verlängert wurde (z.B. Let's Encrypt)
Da ist vermutlich bloß die CA-Chain kaputt bzw. vertraut Filezilla dieser nicht. Was sagt der SSL-Check?
https://www.liveconfig.com/de/sslcheck
(im Übrigen wäre eine Diagnose ohne das aus-xxx-en der Daten deutlich leichter)
Kunden sollten natürlich im SSH keine Daten von anderen Kunden zugänglich sein, nicht mal die Auflistung
chmod 0751 /var/www
(verhindert natürlich nicht, auf anderen Wegen, wie "top" oder "ps", an die Listen zu kommen)
Nicht so schön wenn einige Kunden davon abhängig sind.
Vorab auf FastCGI umstellen.
mod_php ist - auch bei Single-Hosting-Systemen - IMHO nicht mehr relevant. Oder welche Gründe gibt es für mod_php und gegen FastCGI?
Aber bins gewohnt von Nginx, Apache das Key und Zertifikat getrennt sind
Apache kann auch alles aus einer Datei lesen, HAProxy bevorzugt auch eine Datei.
Sorry, aber da gibt es schlimmere Baustellen.
Falls jemand noch dasselbe Problem hat und wegen der Suche hier landet -> ersteres in der ssl.load einkommentieren und letzteres reinschreiben.
oder beim Upgrade die Rückfrage, ob die ssl.conf überschrieben werden soll, bestätigen. Da sollte jetzt eine ssl.conf.dpkg-dist daneben liegen.
was steht denn in Zeile 12?
Syntax error on line 12 of /etc/apache2/mods-enabled/ssl.loadDie Fehlermeldung sieht danach aus, als ob dieses Modul nicht mit Apache 2.4 kompatibel wäre.
In Jessie gibt es das genannte Modul auch gar nicht: