Beiträge von kk

zur Info: Bindestrich ist ab v1.7.0-r2535 erlaubt (https://www.liveconfig.com/dev/issues/104)

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

Apple Mail unterstützt kein autoconfig/autodiscover.

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:

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

Zur Information für andere Kunden - hier sind die "offiziellen" Hilfeseiten von web.de:
http://postmaster.web.de/de/faq-administrator/
http://postmaster.web.de/de/best-practice/

Wenn Quota nicht auf dem Server aktiviert wäre, dann könnte LiveConfig auch nicht anzeigen wie viel Speicherplatz bereits belegt ist.
Wenn bei Ihnen der Befehl "repquota -ag" eine Liste zurückgibt, dann ist Quota aktiviert.

Das tmp-Verzeichnis wird beim Quota jedenfalls mit berücksichtigt (deshalb hat jeder User sein "eigenes" tmp-Verzeichnis, das sich üblicherweise auch auf der selben Partition befindet wie dessen restlichen Verzeichnisse). Und wenn das Quota keinen Platz mehr erlaubt, können auch Session-Files nicht mehr erzeugt werden.

Sie können das Passwort aus dem Private Key ganz einfach entfernen:

openssl rsa -in keyfile.pem -out keyfile-raw.out

Den unverschlüsselten RSA-Key können Sie dann im LiveConfig eingeben.

LiveConfig entfernt eine eventuelle Verschlüsselung ohnehin beim Import, damit Apache/NGINX/Postfix/usw. ohne Passworteingabe starten können.

Rein interessenhalber: wie genau haben Sie den Key erzeugt?

Wie stellen Sie sich denn eine Hilfe vor? Glaskugel?

Alle zu prüfenden Dinge wurden genannt - eine Antwort hierauf haben Sie aber noch nicht gegeben (HELO-Meldung?).

Senden Sie einfach mal eine Testmail an support@liveconfig.com, dann sehen wir mal in unseren Mailserver wie sich Ihr Mailserver meldet.
(Hinweis: diese Leistung geht rein auf Kulanz, das hat absolut nichts mit LiveConfig zu tun...)

Zitat von proplay.de

Mein Vorschlag: SPF einrichten. hotmail / outlook erwarten ein SPF.

Wir raten von SPF ab (macht nur Ärger, insbesondere bei Weiterleitungen). Unabhängig davon "erwartet" Hotmail sicher kein SPF, sondern berücksichtigt das bestenfalls positiv (wir betreiben einige große Mailserver ohne SPF und haben keinerleit Probleme mit Hotmail & Co.).

Zitat

Könnte bei web.de / gmx.de auch so sein.

Von web.de wissen wir, dass die sehr viel Wert auf eine korrekte Einlieferung legen. Die wichtigsten Punkte sind inbesondere:
- korrekter Reverse-DNS (falls IPv6 vorhanden ist, auch dessen RDNS prüfen!)
- korrekter HELO-Wert (/etc/mailname sowie der Hostname müssen korrekt sein)

Viele Grüße

-Klaus Keppler

Wir überarbeiten derzeit den Shop und den Lizenzserver entsprechend; wenn alles klappt soll es die Kaufversion auch mit v1.7 geben (es sind dazu eben auch einige kleinere Änderungen an LiveConfig selbst nötig).
Zum Preis: kalkuliert ist dieser etwa mit der "Monatsmiete" x 36 (also der Mietpreis für drei Jahre), das entspricht der üblichen Abschreibungsdauer von Software. Updates und Support sind für 1 Jahr enthalten, Verlängerung ist jährlich möglich. Die Kaufversion hat dann natürlich ein zeitlich unbegrenztes Nutzungsrecht.

Außerdem wird es im Shop auch die Möglichkeit geben, die Mietversion mit längeren Abrechnungszeiträumen zu erwerben (z.B. Abrechnung alle 3, 6 oder 12 Monate), sowie die Zahlung per PayPal ohne Kreditkarte (geht nur mit mind. 3monatiger Laufzeit).

Viele Grüße

-Klaus Keppler

Zitat von Seppelchen

suPHP_AddHandler application/x-httpd-suphp53
AddType application/x-httpd-suphp53 .php .php5
In die Datei /etc/suphp/suphp.conf im Abschnitt "Handlers" folgende Zeile hinzufügen:

Code:
application/x-httpd-suphp54="php:/usr/local/php53/bin/php-cgi"

Bitte achten Sie genau darauf, dass Sie die Konfiguration konsistent erstellen. Es funktioniert natürlich nichts, wenn Sie einmal einen Handler für "x-httpd-suphp53" anlegen und einmal mit "x-httpd-suphp54" arbeiten.

Zitat

P.s. Wenn man FASTCGI nimmt Problem, wie kann man dieses noch füllen:
> Scan this dir for additional .ini files
> Additional .ini files parsed

[/quote]

Dieser Pfad ist hardcodiert und kann nur bei der Compilierung von PHP verändert werden.

Mit LiveConfig hat das jeweils nichts zu tun.

Warum das Compilieren fehlschlägt lässt sich mit den o.g. Infos beim besten Willen nicht sagen, vermutlich fehlt irgendeine Bibliothek (Tipp: die vollständige Fehlermeldung lesen)
Entpacken: wenn in dem Archiv (ich tippe mal auf .tar.gz?) die Dateien mit einer User-ID eingepackt wurden die dem web2 entspricht, dann werden die auch so wieder entpackt. Der "tar"-Befehl hat viele Optionen - eine davon dient dazu, Dateien beim entpacken einem anderen Benutzer zuzuordnen oder die User-ID einfach zu ignorieren.

Viele Grüße

-Klaus Keppler

Das liegt daran, dass es diese Funktion derzeit noch nicht gibt.

Mail-Templates sind für eines der kommenden Updates (ab v1.7.1) eingeplant.

Viele Grüße

-Klaus Keppler

Zitat von janwego

Also ich hab r2509 und jetzt steht es wieder da... der Punkt Arbeitsspeicher war vorher nicht zu sehen ... komisch

Ich schaue mal ob wir das vielleicht noch als Anmerkung irgendwo ins Handbuch aufnehmen können: die Speichernutzung wird in einer RRD-Tabelle verwaltet (damit man den Speicherverlauf theoretisch auch mal über die Zeit hinweg betrachten kann). Die Anzeige erfolgt (aktuell) erst dann, wenn mindestens ein RRD-Satz geschrieben wurde, also nach 5 oder 15 Minuten (ich weiß das gerade nicht auswendig welches Intervall wo gilt).
Daher also das o.g. Verhalten - es hat einfach ein wenig gebraucht, bis LC soweit war.

Seppelchen: das erklärt aber nicht, warum bei Ihnen noch immer keine Daten angezeigt werden. Das kann eigentlich nur dann der Fall sein, wenn der LiveConfig-Client-Prozess gar keine Daten an den Serverprozess liefert - sprich: sich aufgehängt hat.
Werden denn aktuelle Trafficdaten oder CPU-Daten angezeigt? Läuft die aktuellste LiveConfig-Version? (v1.6.4-r2509)

Viele Grüße

-Klaus Keppler

Hallo,

bitte fügen Sie in /usr/lib/liveconfig/lua/postfix.lua in Zeile 487 noch die Zeichen "> 0" ein und starten Sie LiveConfig anschließend neu:

if LC.bits.band(opts.sslmode, 4) [U][B]> 0[/B][/U] then

Lua wertet auch ein numerisches "0" in diesem Fall als "wahres" (true) Ergebnis.
Fehler ist in der nächsten Version beseitigt.

Viele Grüße

-Klaus Keppler