Beiträge von kk

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.

Zitat von DasBill

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

Zitat von dicker

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

Zitat

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

Zitat von Stricted

das "ssl_prefer_server_ciphers on;" steht schon in der nginx.conf

Das ist ab Debian 8 standardmäßig da drin (bei Upgrades von Deb 7 nicht).
Ab LiveConfig 2.0.1-r3978 wird das nun auskommentiert wenn man NGINX durch LiveConfig verwaltet.

Zitat von m_k

Ist hier die Möglichkeit vorhanden, bestimmte Postfächer davon auszunehmen, bzw. dort andere Werte einzutragen?

Ja, selbstverständlich.

Für eine reibungslose Einführung planen wir alle bestehenden Postfächer standardmäßig von diesem Limit auszunehmen und es nur bei neuen Postfächern zu setzen.
Gleichzeitig soll es eine Möglichkeit geben, das Limit auch auf alle bestehenden Postfächer anzuwenden. Ein weiterer Bericht soll zeigen, welche Accounts in den letzten X Tagen das Versandlimit überschritten haben (oder hätten) - dann kann man das "tunen".

Zitat von leepfrog

Es wäre schön wenn Unterstützung in der GUI für die Konfiguration des PHP Parameters "mail.log" vorhanden wäre um die per PHP verschickten Mails zu loggen.

Hosting -> PHP-Einstellungen. Dort können Sie ja diese Einstellung mit aufnehmen - als Wert wäre dann wohl so etwas wie "%HOME%/logs/priv/php_mail.log" ganz sinnvoll.
Da das Log mit den Rechten des jeweiligen Webspace-Users erzeugt wird, muss zwangsläufig eine separate Datei pro Webspace verwendet werden (sonst hätten ja alle Zugriff auf diese Datei).

Tipp: https://www.debian-administrat…aking_/tmp_non-executable
(dort der letzte Abschnitt - /etc/apt/apt.conf)

Haben Sie /tmp/ zufällig mit "noexec" gemounted?

Ok, aber dieser Thread ist eigentlich nur für die E-Mail-Limits gedacht (eine allgemeine Wunschliste würde hier den Rahmen sprengen - bitte ins Forum "Feedback und Vorschläge").

Hallo,

mit dem kommenden Update (v2.0.2) wird LiveConfig ein- und ausgehende E-Mails limitieren können. Folgende Mechanismen haben wir bereits umgesetzt:

• Vertrag gesperrt:
  eingehende E-Mails werden mit der neutralen Fehlermeldung "Mailbox unavailable" (5xx) abgewiesen, ausgehende E-Mails werden mit "Account disabled - please contact your administrator" (evtl auch lokalisiert in die Sprache des jeweiligen Accounts) abgelehnt.
  Der Abruf von E-Mails (POP3/IMAP) bleibt auch bei gesperrten Verträgen vorerst möglich (wenn man das auch sperrt bewegt man sich im Rahmen des TKG auf ziemlich dünnem Eis - außerdem kann nur so der Kunde ja auch per E-Mail wirksam über die Sperrung informiert werden)
• Rate-Limit:
  Anzahl ausgehender E-Mails pro Stunde pro Account.
  Das Rate-Limit wird mit jedem Update der Mail-I/O-Statistiken geprüft (also ca. alle 10 Minuten) - bei eventuellem Spam-Ausbruch dauer es also nicht 60 Minuten sondern (je nach Anzahl der Mails) nur wenige Minuten bis das Postfach gesperrt wird.
  In diesem Fall werden - aus Compliance-Gründen - drei E-Mails versendet: einmal an den Postfachinhaber selbst, einmal an den Admin-C des Vertrags und einmal an den Admin/Reseller.
  Eine Freischaltung muss manuell im Postfach-Dialog erfolgen (und passiert auch automatisch wenn das Mailpasswort geändert wird). Eventuell wird's auch eine automatische Freischaltung nach einem bestimmten Intervall geben (wäre bei Spam aber kontraproduktiv, weil's dann ja wieder weiter geht - bis zur nächsten Sperrung...)

Wenn es noch weitere Anregungen gibt, bitte her damit. Die erste Preview auf 2.0.2 ist für Ende dieser Woche geplant.

Viele Grüße

-Klaus Keppler