Beiträge von kk

Die Preview für LiveConfig 2.5.0 wurde eben aktualisiert (r4728).

Neue Features & Verbesserungen:

• Unterstützung von Single Sign-On an phpMyAdmin
• Unterstützung von PHP7 als Apache-Modul (mod_php7)
• Performance des Logsplit-Programms (lclogsplit) verbessert (50x weniger I/O)
• Autoresponder sendet keine Antwort, wenn die Nachricht als SPAM markiert wurde (betrifft nur neue und aktualisierte Postfächer)
• Zeitzonen-Datenbank auf Version 2017b aktualisiert

Bugfixes:

• Let's Encrypt-Zertifikate konnten nicht mit Subdomains bestellt werden, die als Reverse Proxy konfiguriert waren (Apache)
• Doppelte Einträge aus /etc/apache2/accesslog.map entfernt
• über Port 465 (SMTPS) eingereichte E-Mails wurden von lclogparse nicht gezählt
• Postfach-Statistiken (maildirsize) mit Postfächern >2GB funktionierten nicht auf 32-Bit-Sytemen

Viele Grüße

-Klaus Keppler

Zitat von TCRserver

Ein weiteres Problem scheinen bei mir die CAA Records zu verursachen.
Nach dem ausfüllen und speichern des Formulars wird die GUI leer wieder angezeigt.

Merkwürdig, hier klappt alles einwandfrei. Welche Distribution und welches Datenbank-Backend (SQLite/MySQL) nutzen Sie?

Am einfachsten ist es wirklich für HSTS den gewünschten Header per .htaccess senden zu lassen.
Besteht denn Bedarf, das auch über GUI einzurichten?

Das Problem ist: wenn jemand HSTS irrtümlicherweise aktiviert (oder zu "Testzwecken"), dabei aber eine lange Gültigkeit eingestellt hat (empfohlen wird ja ~1 Jahr), ist die Domain anschließend möglicherweise "unbrauchbar" falls HTTPS doch nicht klappt. Mit anderen Worten: man sollte wissen, was man tut, wenn man HSTS aktiviert. Und wer das weiß, der ist i.d.R. auch in der Lage, eine .htaccess-Datei zu erstellen.

HPKP ist vermutlich eh tot - spannender ist da DANE/TLSA (zusammen mit DNSSEC). Hier ist ein Hauptproblem aber der Roll-Over, wenn sich mal der Schlüssel des Zertifikats ändert. Auch da gilt: wer weiß was er tut, kann das per "eigene DNS-Einträge" schon heute im LiveConfig anlegen (die Hashes dazu berechnet unser SSL-Check).

Ja, die kommt noch dieses Jahr (der technische Teil ist schon fertig, nur GUI muss noch angepasst werden).

Ja, immer noch offen.
Wenn wir das SAN-Feld parsen und dort den erstbesten Domainnamen daraus verwenden, wird es GARANTIERT die nächsten Beschwerden geben, warum denn nicht der zweite Name / ein wählbarer Name / alle Namen / ein frei einstellbarer Name / oder was-auch-immer angezeigt wird.

Man kann inzwischen in der SSL-Verwaltung zu jedem Zertifikat einen Kommentar hinterlegen, der bei einer eindeutigen Zuordnung hilft.
Wir lassen den Feature Request mal offen, bislang ist mir aber kein zweiter Kunde bekannt, der damit ein Problem hat.

[EDIT] zumal Multi-Domain-Zertifikate in Zeiten von Let's Encrypt ohnehin an Bedeutung verlieren dürften - da holt man sich im Zweifelsfall separate Zertifikate...

Zitat von kroerig

Wieso? Bei den "großen" ist das normal. Pro Vertrag gibt es ein kostenloses SSL-Zert. Egal wieviel Domains der Kunde darin hat.

In dem Fall von Symantec.

Kennen Sie die Konditionen von Symantec für deren kostenlose Zertifikate?
(die Konditionen erklären nämlich, warum die Anbieter das limitieren "müssen")

Wenn Sie das limitieren möchten, dann müssten Sie das so handhaben dass Ihre Kunden nur eine begrenzte Anzahl kostenloser Zertifikate über Ihren Support "bestellen" können - und Sie legen diese dann eben im LiveConfig als "admin" an.
Da SSL (HTTPS) aber gerade auf dem Weg zum De-Facto-Standard ist, dürfte es nur eine Frage der Zeit sein bis man sich durch so eine Limitierung gegenüber seinen Wettbewerbern selbst benachteiligt.

Zitat von kroerig

wie kann ich meinen Kunden ermöglichen LE Zertifikate zu verwenden, ohne ihnen direkt die ganz Zertifikatsverwaltung freigeben zu müssen?

Das ist nicht möglich - irgendwo muss der Vorgang der Zertifikatsbestellung ja verwaltet werden.
Alternativ können Sie höchstens als "admin" Let's-Encrypt-Zertifikate anlegen und die (automatisch) dem jeweiligen Kunden zuordnen - dann kann der Kunde die verwenden, hat aber keinen Zugriff auf die Zertifikate selbst.

Anfang kommenden Jahres gibt es ein neues Protokoll für die automatisierte Zertifikatsverwaltung (ACME v2), womit Let's Encrypt dann u.a. auch Wildcard-Zertifikate ermöglicht. Wir planen in diesem Zuge auch die SSL-Verwaltung deutlich einfacher zu gestalten, so dass ein Kunde dann letztendlich nur noch die Verschlüsselung per Checkbox aktivieren/deaktivieren braucht - um den Rest kümmert sich LiveConfig völlig transparent.

Zitat

Und ich würde auch gerne die Anzahl der Zertifikate, die ein Kunde nutzen darf einstellen können.

So etwas ist bislang nicht vorgesehen und wohl auch eher "exotisch".

Ändern Sie die Pfade erst in /usr/lib/liveconfig/lua/custom.lua ab und starten LiveConfig anschließend neu.
Danach bearbeiten Sie eine beliebige php.ini-Einstellung (Hosting -> PHP-Einstellungen) - z.B. setzen Sie "expose_php" auf "Ja" und dann wieder auf "nein" und speichern das ab.
Klicken Sie dann ganz unten auf den Button "Änderungen anwenden...". Damit werden alle PHP-Einstellungen (php.ini, FastCGI-Starter usw.) neu geschrieben und somit auch die neuen Pfade verwendet.

posix, sysvmsg, sysvsem, sysvshm
"Normale" Webanwendungen sollten solche Funktionen nicht brauchen, beim Shared Hosting kann man den Host dadurch kinderleicht in die Knie zwingen (lokaler DoS).

Zitat von Ringelnatz

Vielleicht lässt sich das ja irgendwie reproduzieren, ansonsten gebe ich gerne weitere Infos. Eingesetzt wird die aktuelle LiveConfig-Version auf Debian Stretch.

Ich kann das leider nicht reproduzieren (Debian 9).
Es gibt aber einen aktuellen Bugfix (ist in der Preview bereits berücksichtigt), da Passwörter in bestimmten Fällen falsch entschlüsselt wurden (da wurde dann ein "x" angefügt). Verwenden Sie testweise mal ein Passwort das ein Zeichen kürzer ist (z.B. also 39 statt 40 Zeichen).

Zitat von kroerig

und ich muss nur die Erweiterungen installieren, die auch benötigt werden.

In der o.g. Liste sehe ich übrigens mindestens vier Module, die in Shared-Hosting-Umgebungen definitiv nichts verloren haben.

Zitat von HBO

Naja, das selbst zu bauen ist ja nun nicht wirklich schwer

Ob das "schwer" ist oder nicht, darüber kann man sich bestimmt streiten. Ich würde mal sagen, dass es nicht unmöglich ist - aber wie man z.B. ein PHP 5.4 unter Debian 9 erstellt ist nicht gaaaanz so trivial.
(Beispiel: cURL benötigt OpenSSL 1.1.x, PHP 5.4 unterstützt aber nur PHP 1.0.x ...)

Zitat von kroerig

Mir scheint, da ist alles in ein Binary gepackt worden, phpinfo() klappt erst, wenn man das Paket installiert hat.

Meinen Sie mit "Binary" ein .deb-Paket oder das PHP-Binary selbst?

Zitat

Da wäre eine Auflistung welche Erweiterungen eingebunden wurden, nur logisch. Zumal mir Shared Objects lieber sind. Dann ist das bin-File nämlich kleiner und ich muss nur die Erweiterungen installieren, die auch benötigt werden.

Fast alle PHP-Module/Extensions sind in unseren Paketen als Shared Objects compiliert, die Sie über /opt/php-###/etc/conf.d/ einzeln abschalten können.

Die Paketierung von PHP unter Debian/Ubuntu ist leider alles andere als trivial, wir nehmen aber gerne in die Wunschliste auf, die Erweiterungen einzeln installierbar zu machen.

Viele Grüße

-Klaus Keppler

Das ist sogar schon vorbereitet (sieht man nach einem Session-Timeout, da wird man mit einem URL-Parameter "&from=/liveconfig/..." auf die Anmeldeseite geleitet. Aus irgendeinem Grund wird dieser Parameter nach dem Login aber derzeit nicht ausgewertet - wir prüfen das noch mal.
(ich glaube mich ganz dunkel daran zu erinnern, dass es da um potenzielle XSS-Probleme ging...)

Zitat von Sven_67

3 Jahre später....

Noch immer wird lcsam nach einem reboot nicht gestartet.
Noch immer muss man lcsam manuell starten = -1

Meine LC Version: 2.2.3 (r4343) ( Diese deshalb immer noch, weil ich einfach mal abwarten möchte, was noch so alles nicht funktioniert. )
Mein Server läuft mit: Debian GNU/Linux 8.7 (jessie) in der aktuellen Version

Ich komme da auch nicht so ganz mit...
Debian Jessie hat derzeit Version 8.9 (nicht 8.7), und LiveConfig 2.2.3 ist fast genau ein Jahr alt. Wie sollen sich eventuelle Fehler ohne das Einspielen von Updates beheben?
Eine Liste aller Änderungen, neuen Features und Bugfixes finden Sie mit jedem Release unter https://www.liveconfig.com/de/changelog.

Viele Grüße

-Klaus Keppler

Zitat von aziegler

heißt für alle mit vielen Servern wieder selbst in der sqlite rumbasteln um das überall zu aktivieren?
Manchmal hab ich echt das Gefühl LC wird primär/nur für Gelegenheits-Admins mit 5-10 Servern ausgelegt...

LiveConfig ändert bei bestehenden Installationen im Rahmen eines Upgrades grundsätzlich nichts an der Konfiguration. Wenn der Admin ein neues Feature nutzen will, dann muss er das also ausdrücklich aktivieren - ich denke das ist auch in Ihrem Sinn.

Wenn es darum geht, neue Features automatisiert auszurollen, dann ist das eine andere Sache über die wir gerne diskutieren können.

Viele Grüße

-Klaus Keppler

Zitat von TCRserver

Laut der (an dieser Stelle etwas verwirrenden) NGINX Doku müssen aber die IPv6 Adressen geklammert werden:

Danke für den Hinweis, wurde inzwischen korrigiert (r4695).

Hello,

the PHP packages for Debian/Ubuntu have been updated to version 7.0.24 and 7.1.10.

Best regards

-Klaus keppler

Hallo,

die PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.0.24 und 7.1.10 aktualisiert.

Viele Grüße

-Klaus Keppler

Die Preview wurde eben auf Version v2.5.0-r4692 aktualisiert. Damit wird die NGINX-Konfiguration verbessert:

• falls NGINX durch LiveConfig verwaltet wird, dann wird während des Upgrades eine Datei namens /etc/nginx/conf.d/resolver.conf angelegt. Diese enthält die DNS-Resolver (aus /etc/resolv.conf).
  NGINX löst ansonsten alle Hostnamen (z.B. für Reverse-Proxy URLs) nur einmalig (beim Start/Reload) auf - auf den System-Resolver kann NGINX aus Architekturgründen nicht zurückgreifen...
• die Konfiguration von Reverse-Proxy vHosts wurde verbessert (da gab es unter Umständen Probleme)

Viele Grüße

-Klaus Keppler