Immerhin wäre es doch schön wenn LC für Duplikatanfrage warnt.
Gerne, wird mit aufgenommen.
Immerhin wäre es doch schön wenn LC für Duplikatanfrage warnt.
Gerne, wird mit aufgenommen.
Kommt darauf an welche SSL-Liste genau Sie meinen.
Unter "Hosting" -> "SSL-Zertifikate" können beliebig viele Zertifikate für die selbe Domain verwaltet werden. Um diese ggf. auseinander zu halten, kann man beim Bearbeiten eines Zertifikats einen Kommentar angeben. Dieser wird dann auch bei der Auswahl eines SSL-Zertifikats unter "Hosting" -> "Domains" -> (Subdomain bearbeiten) angezeigt.
In diesem Fall würde ich einfach das abgelaufene Zertifikat löschen und anschließend unter "Hosting" -> "Domains" bei der betroffenen Domain das LE-SSL-Zertifikat auswählen und damit speichern.
Geht doch viel einfacher: den FastCGI-Workaround in die /etc/nginx/fastcgi_params mit aufnehmen. ![]()
Für uns wäre interessant ob noch jemand die Erfahrung gemacht hat, dass die PATH_INFO falsch/unbrauchbar ist. Bevor wir das "global" ändern müsste halt sichergestellt sein, dass damit keine anderen Probleme entstehen.
Ist für die Domains Webspace oder zumindest eine Weiterleitung aktiviert?
Sie können die Domain dann zwar löschen, nach Ablauf der Authorisierungs-Gültigkeit wird das Zertifikat dann aber nicht automatisch verlängert werden können.
In diesem Fall wird LiveConfig Sie dann per E-Mail informieren - dann müssen Sie die Domain erneut anlegen und quasi von vorne beginnen.
Für Sachen wie "mail.###" ist vermutlich eine permanente Weiterleitung auf die eigene Website am elegantesten.
Das ist kein Fehler, sondern die Domain ist schlicht nicht im LiveConfig angelegt. ![]()
Also: Domain (bzw. Subdomain) anlegen und HTTP dafür aktivieren (entweder mit Webspace oder als Weiterleitung) - sonst klappt die Domainprüfung nicht.
Viele Grüße
-Klaus Keppler
php5-suhosin gibt's unter Debian Wheezy (7) nicht. Daher ist das im Meta-Paket ja nur "Recommended", nicht aber "Dependend".
Eine normale Installation per "aptitude install liveconfig-meta" sollte aber anstandslos funktionieren. Wie genau versuchen Sie, das Paket zu installieren?
Nein, bislang geht das noch nicht. Diese Funktion wird noch kommen, aber bewusst etwas beschränkt werden (z.B. Revoke nur durch Admin möglich).
Ein Revoke sollte nur stattfinden, wenn der private Schlüssel kompromittiert wurde. Wenn man das Zertifikat einfach nur nicht mehr benötigt, kann man getrost den Schlüssel löschen und das Zertifikat ablaufen (expire) lassen. Das ist LE sogar lieber als ein Revoke (der belastet nämlich die OCSP-Infrastruktur). Auf das Ausstellungs-Limit (Zertifikate pro Zeitraum) hat ein Revoke auch keinen Einfluß.
Nein, Zertifikate sind dort nicht zu sehen, sondern die Authorisierungen für Zertifikatsanforderungen. Die laufen automatisch ab (das Datum ist jeweils angegeben). Wenn mal erneut ein Zertifikat für eine Domain beantragt wird und noch eine gültige Authorisierung vorliegt, dann geht die Beantragung schneller.
Selbst wenn man die Authorisierungen vorzeitig aus LiveConfig löschen würde, diese bleiben dennoch bei Let's Encrypt bestehen und mit dem Account verknüpft (bis zum Ablaufdatum eben).
Danke für die ausführliche Beschreibung. Der Fehler konnte reproduziert und anschließend gleich behoben werden (hing mit einer neuen Prüfung der Eingaben zusammen, damit keine Sonderzeichen mehr in Benutzernamen erlaubt sind). Beim admin-Account kam es da zu einem Fehler. ![]()
Ist also mit dem nächsten Update erledigt.
ich wollte gerne den admin Benutzer umbennenen
allerdings scheint die Änderung nicht übernommen zu werden.
Könnten Sie das etwas genauer beschreiben? Wieso scheint die Änderung nicht übernommen zu werden? Der admin-Account kann seit v1.8.3-r3493 umbenannt werden.
Auch wenn die offizielle Mitteilung auf php.net noch aussteht: PHP 7.0 ist da! Weitere Infos (auch zu den Geschwindigkeitsvorteilen) gibt's im Heise Newsticker.
Wir haben die PHP-Pakete für Debian (Squeeze/Wheezy/Jessie) eben aktualisiert - ab sofort steht also PHP 7.0.0 (release) für den Einsatz bereit (siehe Wiki).
Wichtig: die Sicherheitserweiterung "Suhosin" unterstützt derzeit noch kein PHP 7 (siehe #81)! Wir verfolgen das und werden Suhosin so schnell wie möglich aufnehmen, sobald das verfügbar ist. Auf Shared Hosting System bedeutet das, dass sich u.a. das Memory Limit mit ini_set() ändern lässt oder auch Datei-Uploads nicht automatisch auf Malware geprüft werden können (wenn maldet/ClamAV installiert sind).
Update ist gemacht aber leider säuft mir immer noch der RAM ab.
Wo säuft da RAM ab? Der reale Verbrauch pendelt sich da offenbar gerade ein (zum Vergleich: in einem "warmgelaufenen" System belegt LiveConfig je nach genutzten Funktionen zwischen 8 und 21 MB RAM).
ZitatGenau 0.00 Uhr hatte ich plötzlich einen Load von über 11 und diese Ausgabe
Kurz vor 0.00 Uhr war der Load noch unter 1.
Das ging also schlagartig hoch.
Und was soll das mit LiveConfig zu tun haben? Die gezeigte ps-Ausgabe zeigt nur völlig unauffällige Prozesse (0% CPU, 0% RAM, 0:00-0:12 CPU-Minuten seit Prozessstart).
Welche Version genau läuft denn bei Ihnen? ("liveconfig -v")
Wenn LiveConfig frisch gestartet ist (was Ihrem Log nach um 17:56 war) dann wächst der Speicherverbrauch selbstverständlich erst noch etwas an (Caching von MySQL-Statements, von Objekten usw...). Schauen Sie sich den Verbrauch noch mal nach 15-20 Minuten an, dann sollte sich das eingependelt haben.
fcgiwrap wird absolut nicht benötigt, und erst recht nicht für Let's Encrypt.
Die Unterstützung von ACME-Authorisierungen (für Let's Encrypt) mit NGINX kam erst ein Update später (mit LiveConfig 2.0.1-r3973 - siehe Änderungsverlauf).
Die Verwaltung eigener DNS-Einträge ist seit Version 1.8.0 (Dezember 2014) möglich.
Voraussetzungen:
- mindestens der Primary DNS einer Domain muss von LiveConfig verwaltet werden
- im Hostingvertrag (oder -Angebot) muss die Option "eigene DNS-Einträge" erlaubt sein (steht unterhalb von "Subdomains"
Viele Grüße
-Klaus Keppler
Kommt drauf an was Sie mit "gelöscht werden" meinen. Es wird die Whitelist gelöscht (da diese ja dann nicht mehr benötigt wird). Alle bislang ausgestellten Zertifikate bleiben selbstverständlich gültig.
Woran genau scheitert es denn?
Mit v2.0.1-r3878 steht ab sofort ein Update bereit, welches das Leak behebt.
[Hintergrund für Interessierte: das eigentliche Memory-Leak (eine fehlende Freigabe von JSON-Objekten) wurde mit r3973 beseitigt. Wir hatten das erfolgreich mit Valgrind getestet - der komplette Speicher war nach dem Ende eines LiveConfig-Prozesses wieder ordentlich freigegeben. Allerdings prüft der ACME-Client minütlich ob es Arbeit für ihn gibt - das passiert in einem separaten Thread (wegen den asynchronen HTTP-Anfragen zum ACME-Server), und eben diese Threads wurden am Ende ihrer Tätigkeit nicht vollständig beendet. Allerdings wurden diese Threads mit dem Ende von LiveConfig automatisch aufgeräumt, wodurch das im Memory-Profiler nicht aufgefallen ist.]