Beiträge von kk

Welche Linux-Distribution setzen Sie denn ein?

Nur auf dem Server mit der Business-Lizenz läuft letztendlich eine Weboberfläche (LiveConfig-GUI). Dort haben Sie unter "Serververwaltung" die Möglichkeit, weitere Server aufzunehmen (da legen Sie u.a. für jeden Client eine eigene ID fest, die Sie dem Client auch mitgeben müssen).

Wenn die beiden zusätzlichen Server mit in der Serververwaltung auftauchen, dann aktivieren Sie dort die Verwaltung der gewünschten Dienste (z.B. auf dem einen Server nur für Postfix/Dovecot, auf dem anderen nur für MySQL).

Beim Anlegen eines Hostingvertrags wählen Sie dann aus, auf welchem Server die jeweiligen Dienste deployed werden sollen (Web/Mail/Datenbank).

Ich hoffe, dass das schon mal weiter hilft.

Viele Grüße

-Klaus Keppler

Ja, reicht aus. Im nächsten Update wird LiveConfig auch Port 443 mit ACME unterstützen.

Mit geringfügigen Änderungen haben wir das in v2.0.1-r3985 aufgenommen. Der Abschnitt sieht dann so aus:

# PHP is enabled
        index index.php index.html index.htm;
        location ~ \.php(/|$) {
                try_files $fastcgi_script_name =404;
                fastcgi_split_path_info ^(.+\.php)(/.*)$;
                include /etc/nginx/fastcgi_params;
                set $path_info $fastcgi_path_info;
                fastcgi_param PATH_INFO $path_info;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_index index.php;
                fastcgi_pass unix:/var/www/web1/conf/sockets/nginx-php-fcgi.sock;
        }

Zitat von ñull

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.

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