Da hatte ich mich vermutlich unklar ausgedrückt. Ich meinte damit die Fehler, die dieses Update betrafen. Von Ihrer Liste müssten aber auch einige Punkte erledigt sein.
Zumindest laut bisherigem Changelog nicht, aber muss man dann wohl im Release durchprüfen, ob vielleicht nur der Changelog nicht vollständig ist.
Die gemeldeten Fehler wurden tatsächlich alle beseitigt
Kommt dann wohl auf die Definition von Fehler/Bug an?
Selbst bei engerer Definition, als ich sie setzen würde, fallen mir da 3-4 ein die vermutlich weiter nicht behoben sein werden... Die Liste liegt ihnen ja vor und das meiste wurde auch hier im Forum diskutiert.
Danke für die Info!
Gerade das Feature der kostenlosen Multidomain-Zertifikate (die es ja gibt, sofern ich das richtig verstanden habe) könnten wir für ein gemeinnütziges Projekt gerade gut gebrauchen 
Als Alternative bleibt dann vorerst wohl doch nur eine Domain mit Startssl und "virtuelle" Unterordner für die einzelnen Dienste, bei denen nginx die Umleitung/Weiterleitung intern erledigt...
im Preview-Changelog scheinen ja Sachen zu fehlen, wenn selbst Design&ACME nicht erwähnt werden 
wie es ja eigentlich auch gedacht ist
So schön die Unterstützung von letsencrypt auch ist, mal wieder ein Marketing-taugliches Feature-Release nach langem Warten statt zeitnahe Releases mit Detailverbesserungen, die an so vielen Stellen nötig wären
Wir haben das auch seit längerem auf der Wunschliste, die Herr Keppler von uns hat
und ich gewinne jeden Tag zwei Mal im Lotto und erhalte alle zwei Stunden eine Rechnung mit ner EXE im Anhang - Danke dafür!
direkt am Live-System lernen wollen ist eben so eine Krankheit... naja, deutsche Servermieter kann man im Zweifel wenigstens noch in die Haftung nehmen "am Ende"
Vielleicht sollte man auch dazusagen, das es "paar" kritische Bugs seit dem EOL von 5.3 bzw. 5.2 gegeben hat. Diese sollten (müssten) bei einer Nutzung mit reingepatched werden und dass ist sicher einiges an Arbeit ;).
ganz ehrlich: da ist der Kunde, der das unbedingt haben will, dann selbst Schuld, wenn er die alte Version trotz Abratens nutzt.
Bisher ist mir auch noch kein Hack untergekommen, der auf die PHP-Version zurückzuführen war.
z.B. für lcdbdump und andere Tools wird die Domain download.liveconfig.com verwendet.
Leider aber Links ohne HTTPS, der Abruf mit klappt zwar, jedoch passt das Zertifikat nicht zur Domain.
Schön wäre es also, wenn man ein Zertifikat mit passendem CN oder subjectaltname hinterlegt und dann sogar eine Weiterleitung von http auf https einrichtet.
EDIT:
das Forum würde HTTPs auch mal vertragen
stimmt, da hat der Kollege doch ein paar Patches, damit das geht.
Gibt's auf Anfrage per PN bei mir aber gerne!
das Forum hat keine Attachment-Funktion hier und einen Download-Server auf dem die Datei ewig liegen bleibt (damit der Link hier gültig bleibt) kenne ich nicht.
WebOscar
Wir haben auch genug Kunden die noch 5.3 oder gar 5.2 brauchen, daher können wir aus eigener Erfahrung sagen:
Ein 5.3 Build (oder gar 5.2) für Jessie ist keine Hexerei.
Domains, die HTTPS aktiviert haben, werden mit einem Schloss-Symbol von LiveConfig in der Liste markiert.
Aber das täuscht fälschlich Sicherheit vor, wenn die Domain immer noch per HTTP unverschlüsselt aufrufbar ist, statt bei HTTP einen 301 Forward auf HTTPS zu haben.
Dies sollte schon in der Domainliste erkennbar sein, um auf das Sicherheitsproblem aufmerksam zu werden.
nicht über das Liveconfig-PHP-Repository.
Mein Fehler... haben unsere eigenen Builds
Hier würde es nützen, wenn LC beim Start die Domains auf fehlerhafte / fehlende FastCGI-Konfiguration prüft und das im Fehlerfall loggt ("Domain example.com is using PHP 5.6, which is not present ATM") sowie die Domain dann auf den Default zurücksetzt.
Gebe zu, nicht perfekt: bei "temporär nicht vorhandener PHP-Version" wären dann alle (Kunden-)Einstellungen dazu weg. Sowas darf aber eigentlich auch nicht auftreten.
irgendwas wäre da nett, ja..... haben nun aber schon fast alle Liveconfig-Nodes auf Jessie.
Das Upgrade war bei unseren (deutlich mehr) Servern kein größeres Problem.
Von Squeeze auf Wheezy ist der Dovecot etwas zu beachten, das wurde an anderer stelle im Forum aber ja schon beschrieben.
Zu den PHP-Versionen:
1) Natürlich gibt es 5.3 noch unter Jessie.
2) Wenn ein Benutzer vor dem Upgrade auf Wheezy PHP 5.5 oder PHP 5.6 eingestellt hatte, bleibt das erhalten. Bei 5.4 kann es sein, dass du manuell eingreifen muss über die LC-Oberfläche.
Das gleiche gilt für das Upgrade auf Jessie, wenn 5.3 oder 5.5 eingestellt ist (unter Wheezy), bleibt das erhalten, alles was auf Standard steht (5.4) ist danach der neue Standard 5.6 und was explizit vorher schon auf 5.6 war muss nach dem Upgrade auf Jessie meist manuell auf Standard umgestellt werden.
Etwas ärgerlich, ich überlege daher schon, nur noch selbst kompilierte Versionen zu nutzen, um bei Upgrades dieses Problem zu umschiffen.
Danke, funktioniert!
Hallo,
leider schon wieder ein Bug...
System:
Debian 8.2, Postfix 2.11.3-1, LiveConfig 1.9.1-r3747
Wenn man in der Serververwaltung von LiveConfig im Abschnitt für Postfix die Verwendung der Blacklists deaktiviert kommt nach dem Abspeichern folgende Fehlermeldung:
/usr/lib/liveconfig/lua/postfix.lua:828: bad argument #1 to 'ipairs' (table expected, got nil) stack traceback: [C]: in function 'ipairs' /usr/lib/liveconfig/lua/postfix.lua:828: in function 'configure' /usr/lib/liveconfig/lua/smtp.lua:213: in functionIm liveconfig.log steht dazu folgendes:
[2015/09/11 19:05:26.048497] [15867|15868] [LUA] LC.mutex: forcing unlock of mutex 'smtp.configure'
[2015/09/11 19:05:26.048525] [15867|15868] LC.smtp.configure() failed: /usr/lib/liveconfig/lua/postfix.lua:828: bad argument #1 to 'ipairs' (table expected, got nil)
stack traceback:
[C]: in function 'ipairs'
/usr/lib/liveconfig/lua/postfix.lua:828: in function 'configure'
/usr/lib/liveconfig/lua/smtp.lua:213: in function </usr/lib/liveconfig/lua/smtp.lua:184>Bitte beheben 
Wenn man nach der Installation einer Anwendung der Domain so umstellt, dass von HTTP auf HTTPs umgeleitet wird, verschwindet die Domain aus der Detailansicht der Anwendung im Bereich der Liste der Anwendungen
Es wird dort nur noch ein "-" angezeigt statt der http oder https URL.
Update: Bei Verträgen wird das wohl schon geprüft mittlerweile, bei Angeboten noch immer nicht.
Klär mal bitte auf - den Fehler muß ja kein anderer nochmal machen
manche Fehler möchte man garnicht genauer ausführen, wenn man mal wieder Tomaten auf den Augen hatte
