Beiträge von kk

    also die FTP Passwörter werden generell nicht angelegt.


    Exakt. Da LiveConfig (noch) keine Mail mit z.B. FTP-Zugangsdaten verschickt, macht es auch keinen Sinn, ein für den Endkunden unbekanntes Passwort anzulegen. Die Idee ist, dass der Kunde sich mit seinen LiveConfig-Zugangsdaten am Panel anmeldet, und dort erst mal selbst ein Passwort für seine FTP-Accounts einrichtet. Da das aber offenbar vielen Anwendern zu kompliziert oder zu unlogisch ist, wird das ja auch bald geändert.


    Es besteht eben in LiveConfig ein grundsätzlicher Unterschied zwischen LiveConfig-Kunden, LiveConfig-Benutzer, Webspace-Verträgen und FTP-Accounts. In Confixx war das alles der selbe Benutzer mit dem selben Passwort. War zwar einfach, aber dafür auch entsprechend unflexibel. Weitere Infos zu den verschiedenen Accounts haben wir im Handbuch.


    Viele Grüße


    -Klaus Keppler

    gibt es eine Möglichkeit die Alias bzw. Catchall Funktion zu deaktivieren :confused:


    Nein, die Möglichkeit gibt es nicht.
    Ich wüsste derzeit auch nicht, warum man die Alias-Funktion deaktivieren können sollte.
    Über eine Deaktivierbarkeit der CatchAll-Funktion können wir uns aber gerne unterhalten - wobei auch das der Kunde durchaus selbst entscheiden können sollte, ob er CatchAll-Accounts wirklich nutzen will.


    Viele Grüße


    -Klaus Keppler

    Richten Sie die IP auf dem Server ein (so dass diese beim Aufruf von "ifconfig" auch angezeigt wird). Danach starten Sie LiveConfig einfach neu - dabei liest LiveConfig die aktualisierte IP-Liste ein und bietet die neue IP unter "Serververwaltung" -> "Web" auch zur Auswahl an.


    Viele Grüße


    -Klaus Keppler

    Das SMTPS-Thema ist erledigt (s.o.); das mit dem Aktualisieren von SSL-Zertifikaten steht bereits bei einem Kollegen in der ToDo-Liste, dürfte also mit dem nächsten Update auch erledigt sein.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    soeben wurde Version 1.6.4-r2534 freigegeben. Dieses Update bringt keine neuen Funktionen, behebt aber zwei Fehler:

    • unter bestimmten Umständen hat ein LiveConfig-Business-Server Netzwerksockets nicht freigegeben (#103)
    • ein Fehler in der Postfix-Konfiguration wurde beseitigt (siehe hier)


    Beide Punkte sind nicht kritisch, wir empfehlen dennoch ein Update durchzuführen wenn ein LiveConfig-Business-Server oder Postfix mit SSL genutzt werden.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    der Fehler wurde gefunden und beseitigt. Unter bestimmten Umständen wurden die Sockets von nicht erfolgreich aufgebauten LCCP-Verbindungen nicht mehr freigegeben.
    Ein Update (v1.6.4-r2534) läuft derzeit durch die Buildsysteme und wird in den nächsten Stunden in den Repositories bereitgestellt.


    Viele Grüße


    -Klaus Keppler

    Am Sichersten wäre es, wenn Sie erst Apache installieren, dann alle Webspaces/Domains auf Apache umkonfigurieren und zum Schluß NGINX entfernen (zumindest wenn es sich um eine überschaubare Zahl an konfigurierten (Sub)Domains handelt).
    Das Vorgehen wäre etwa wie folgt:

    1. installieren Sie das Apache-Paket (je nach Distribution z.B. mit "aptitude install apache2-mpm-prefork") und alle ggf benötigten Module (libapache2-mod-fcgid, apache2-suxes, libapache2-mod-suphp, ...)
    2. starten Sie LiveConfig neu (damit Apache erkannt wird)
    3. melden Sie sich als "admin" im LiveConfig an. Gehen Sie auf "Serververwaltung" -> "Web". Bearbeiten Sie die IPs für NGINX und entfernen Sie einfach alle Häkchen an den Checkboxen (so dass NGINX also ohne IP konfiguriert ist).
    4. entfernen Sie anschließend die IP-Gruppe "default"
    5. aktivieren Sie die Verwaltung für Apache, und aktivieren Sie die gewünschten IPs für Apache
    6. bearbeiten Sie nun der Reihe nach alle Domains Ihrer Verträge (Hosting -> Domains; Subdomain anklicken -> Popup öffnet sich) und klicken dort jeweils einfach nur auf "speichern" (damit dort jeweils eine gültige IP-Gruppe verwendet wird, die auch mit Apache verknüpft ist)
    7. wenn das alles erledigt ist, stoppen Sie NGINX und starten Apache
    8. zuletzt können Sie den von Ihnen genannten SQL-Befehl ausführen (... SET WS_MANAGED=0...) und optional NGINX danach deinstallieren

    Danke, das hilft schon etwas weiter.
    Die ~7000 Verbindungen sind offenbar Socket-Connections zum LiveConfig-Server-Prozess (im o.g. Beispiel mit PID 13740 - das ist der Prozess, der auch auf Port 788 horcht). Das erklärt dann auch die "Too many open files"-Fehlermeldung.


    Vermutlich läuft um 03:00 Uhr irgendetwas, das LiveConfig aus dem Tritt bringt - evtl. VMWare-Snapshots, Backups o.ä.? Bislang ist uns dieses Verhalten noch nirgendwo aufgefallen oder gemeldet worden.


    Könnten Sie uns bitte die letzten Log-Meldungen (/var/log/liveconfig/liveconfig.log) vor Auftreten des Problems schicken? (also alles zwischen "funktioniert noch" und dem ersten "Too many open files...").
    Am besten wäre es zudem, wenn Sie beim nächsten Auftreten des Problems einen Coredump erzeugen könnten - damit können wir dann genau lokalisieren, wo etwas nicht stimmt. Hierzu gehen Sie bitte wie folgt vor:

    • lokalisieren Sie die PID des LiveConfig-Client-Prozesses (z.B. mit "netstat -tlpn | grep ':788'").
    • wechseln Sie ins Verzeichnis /root: cd /root
    • Starten Sie den GNU-Debugger (gdb) und verbinden sich mit diesem Prozess - z.B. "gdb --pid=13740"
    • erzeugen Sie den Coredump: "gcore"
    • beenden Sie gdb wieder: "quit"
    • komprimieren Sie den Core-Dump: "gzip -9 core.13740"
    • senden Sie die Datei dann per Mail an support@liveconfig.com (falls >20 MB, senden Sie uns ggf einen Download-Link)


    Viele Grüße


    -Klaus Keppler

    Da die Meldung im Kontext von "Error while accepting connection" erscheint, tippe ich darauf, dass es (zu) viele TCP-Verbindungen gibt (wobei das auch komisch ist, da LC in so einem Fall ohnehin keine weiteren Verbindungen mehr annehmen dürfte).


    Wenn Sie diesen Zustand wieder erhalten, lassen Sie sich bitte mal die Liste der offenen Netzwerkverbindungen zu LiveConfig ("netstat -tpn | grep liveconfig") und die Liste der offenen Filehandles (lsof | grep liveconfig) ausgeben.


    Die MySQL-Connect-Meldung kann auftreten, wenn Sie einen MySQL-Server mit LiveConfig verwalten (Serververwaltung -> Datenbank) und die Verbindung fehlschlägt.


    Viele Grüße


    -Klaus Keppler

    Bei Postfix/Dovecot konfiguriert LiveConfig derzeit keine IPs - da muss man also auch nichts ändern.


    Ohne eine brauchbare Fehlermeldung (also etwas mehr als "ein Übermittlungsfehler") hilft nur eine Kristallkugel weiter.

    Die bisherige Fehlerbeschreibung hilft leider absolut nicht weiter, da keine relevanten Infos vorhanden sind.


    - aktivieren Sie bitte im LiveConfig im betroffenen Vertrag das Fehlerprotokoll (error.log)
    - melden Sie sich als "root" auf dem Server an und ändern Sie manuell den php.ini-Eintrag "log_errors" auf "on":
    (dazu erst "chattr -i ~webxyz/conf/php5/php.ini", dann log_errors auf "on" setzen).
    - führen Sie anschließend in Wordpress das Plugin-Upgrade durch. Wenn nun die "weiße Seite" erscheint (sprich: ein Fehler auftritt), sollte in ~/logs/priv/php_errors.log eine entsprechende Info zu finden sein.


    Ob Confixx oder LiveConfig ist dabei völlig egal, weil Wordpress nunmal auf PHP (bzw. via Apache) läuft. Es kann aber sein, dass die php.ini von LiveConfig etwas sicherer und somit restriktiver ist als auf Ihrem anderen Server. Ohne eine genaue Fehlermeldung (die man im PHP-Errorlog auch erhält), ist alles Andere reine Spekulation.

    Konfigurationsdateien werden normalerweise sofort in die jeweiligen Config-Dateien geschrieben. Der Restart/Reload der Dienste erfolgt dann nach frühestens 10 Sekunden, spätestens nach 60 Sekunden (also eigentlich nach 10 Sek., wenn bis dahin weitere Änderungen erfolgen dann wird der Timer immer wieder zurückgesetzt, aber nach max 60 Sekunden erfolgt in jedem Fall ein Reload).


    In diesem Fall werden die php.ini-Dateien also *sofort* aktualisiert (einfach mal Dateidatum angucken), und Apache nach einigen Sekunden neu gestartet.

    Hallo,


    ich habe testweise auch einen Private Key bei StartSSL mit 4096 bit & SHA2 erzeugt. Mit "openssl rsa -in test.key ..." kann ich diesen erfolgreich entschlüsseln.


    Bitte prüfen Sie, ob die "test.pem" bei Ihnen auch tatsächlich den privaten RSA-Schlüssel enthält. Die Datei sollte etwa so aussehen:

    Code
    -----BEGIN RSA PRIVATE KEY-----
    Proc-Type: 4,ENCRYPTED
    DEK-Info: AES-256-CBC,[...]
    
    
    [...]
    -----END RSA PRIVATE KEY-----


    Übrigens kann auch LiveConfig diesen Key direkt importieren.


    Ich tippe daher mal darauf, dass Sie nicht den Key, sondern irgend etwas anderes (z.B. das Zertifikat?) verwendet haben.


    Viele Grüße


    -Klaus Keppler