Hi,
in den Systeminformationen werden mir 3GB Swap aufgefuehrt. Frage ich jedoch "free -m", so werden mir die korrekten 10GB reportet. Aufgefallen ist es mir in LiveConfig 1.6.0-r1957 auf einem Debian Squeeze (6.0.6) Server.
Gruss ksmx
Hi,
in den Systeminformationen werden mir 3GB Swap aufgefuehrt. Frage ich jedoch "free -m", so werden mir die korrekten 10GB reportet. Aufgefallen ist es mir in LiveConfig 1.6.0-r1957 auf einem Debian Squeeze (6.0.6) Server.
Gruss ksmx
Hi,
mir sind heute folgende Eintrag im Logfile von LiveConfig aufgefallen:
[2012/10/24 11:58:42.174018] [19788|20018] Connecting to update.liveconfig.com ([62.146.188.96]:443)...
[2012/10/24 11:58:42.980239] [19788|19788] SSL read error (OS): Connection reset by peer
[2012/10/24 11:58:43.100980] [19788|19788] SSL read error (OS): Connection reset by peer
[2012/10/24 11:58:43.103494] [19788|19788] SSL read error (OS): Connection reset by peer
Ein "wget https://62.146.188.96/" funktioniert hingegen tadellos - und wenn wir schon dabei sind: Was bedeutet die Zeile:
Gruss ksmx
Hi,
ich würde mich freuen, wenn dieses Thema geschlossen wird, sobald LiveConfig diese Funktion besitzt. Meine Kunden waeren auch stark an ihrem error.log interessiert.
Gruss ksmx
Die Ursache meines Problems scheint einen anderen Ursprung zu haben. Ob LiveConfig eine Rolle spielt, konnte ich noch nicht ausschließen. Waere der "graceful restart" von LiveConfig der Ausloeser, dann wuerde mein Logauszug die Zeile
enthalten. Dies ist aber nicht der Fall. Ich werde mir mod_fcgid einmal im Detail ansehen muessen, um die Ursache fuer obige Warnung zu finden. In meinem Fall füllt sich der Arbeitsspeicher des Servers mit leblosen PHP-Instanzen. Irgendwann schlägt des obere Limit von mod_fcgid zu (FcgidMaxProcessesPerClass) und legt den entsprechenden User lahm. Führt man ein Restart des Apaches aus und räumt die PHP-Instanzen per Hand weg, so herrscht im Anschluss nur noch durchschnittliche Last mit Luft nach oben.
Gruss ksmx
Hi,
ich bin über das Problem gestolpert, dass bei Apache 2.2.16 (Debian Squeeze) in Zusammenspiel mit fcgi 2.3.6 der "graceful restart" problematisch sein kann. In der error.log des Apaches lassen sich alle paar Stunden folgende Eintraege finden:
[Sun Oct 14 21:23:49 2012] [warn] mod_fcgid: process 32174 graceful kill fail, sending SIGKILL
[Sun Oct 14 21:23:53 2012] [warn] mod_fcgid: process 32166 graceful kill fail, sending SIGKILL
[Sun Oct 14 21:23:57 2012] [warn] mod_fcgid: process 15967 graceful kill fail, sending SIGKILL
[Sun Oct 14 21:26:04 2012] [warn] mod_fcgid: process 489 graceful kill fail, sending SIGKILL
[Sun Oct 14 21:35:58 2012] [warn] mod_fcgid: process 28348 graceful kill fail, sending SIGKILL
[Sun Oct 14 21:46:42 2012] [warn] mod_fcgid: process 22746 graceful kill fail, sending SIGKILL
Stoppt man LiveConfig, so findet man diese Fehlermeldungen einiges seltener. Für mich stellt sich an dieser Stelle die Frage, wann genau LiveConfig einen "graceful restart" durchfuehrt. Finden diese auch statt, wenn sich niemand ins Backend eingeloggt und Veraenderungen vorgenommen hat? Gibt es weitere Komponenten, welche Restarts durchfuehren?
Gruss ksmx
Oh, ich Blindfisch!
Hi,
ich meine das Thema schonmal in der Roadmap gesehen zu haben, jedoch kann ich es weder dort, noch im Forum wieder finden. In der Roadmap findet man jedoch "DNS-Konfiguration / Zonen-Verwaltung". Ist eine Maske zu Registrierung und automatischen Einbindung von neuen Domains ebenfalls Bestandteil der Entwicklung oder ist abschätzbar, ab wann es diese Funktion geben wird?
Ich wuerde gerne meinen Kunden die Moeglichkeit geben neue Domains registrieren zu koennen. Aus Confixx heraus war / ist dies moeglich. Die Daten werden dort in Form einer Mail herausgereicht, wenn ich mich recht entsinne. Eine API oder ein RPC-Call waere natuerlich auch nett.
Gruss ksmx
Bei mir zeigte sich heute Nacht nach einem Update auf die Lab-Version selbige Fehlermeldung.
Die AuthOrder auf "mod_auth_file.c" beschraenken war keine gute Idee. Der FTP-Zugang eines Webspace wird ueber die /etc/passwd aufgeloest und Kunden sind äußerst verwundert, wenn manchen FTP-Zugaenge funktionieren und andere nicht.
Hallo,
aus der Rubrik "Angebote" weiss ich, dass sich SSH-Zugriff für bestimmte Angebotstypen aktivieren lässt. An meinem Benutzer Admin hängen zwei Verträge, die beide als "- individuell -" gekennzeichnet sind. Bearbeite ich diesen individuellen Vertrag, so besitze ich keine Möglich SSH zu aktivieren. Was mache ich falsch?
Gruss ksmx
PS. Was ich eigentlich ausprobieren wollte: Wie realisiert LiveConfig den SSH-Zugriff? Wird der Benutzer in ein Jail gesteckt (vermutlich nicht) oder darf er sich freizuegig bewegen?
Hi,
ich habe mich gefragt, wie haeufig LiveConfig die User-Logs rotiert (monatlich). Dabei ist mir aufgefallen, dass die Datei veraltete Eintraege besitzt von Kunden, die es garnicht mehr gibt.
Gruss ksmx
Hi,
bei jedem FTP-Login eines (virtuellen LiveConfig) FTP-Users sehe ich folgende zwei Zeilen im auth.log:
Aug 24 15:27:19 hostname proftpd: pam_unix(proftpd:auth): check pass; user unknown
Aug 24 15:27:19 hostname proftpd: pam_unix(proftpd:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/ftpd29118 ruser=virtuser rhost=
Scheinbar wird erst PAM gefragt, ob der Benutzer existiert und danach das eingesetzt mod_auth_file. Die Ergänzung des Eintrags "AuthOrder mod_auth_file.c" loest fuer mich das Problem. Jedoch koennen sich ab nun keine Unix-Benutzerkonten mehr an den FTP-Server anmelden, was ich nicht weiter schlimm finde. Der Eintrag "AuthOrder mod_auth_file.c mod_auth_pam.c" loest das Problem seltsamerweise nicht.
Gruss ksmx
Hi,
einerseits ist es schick und geschickt, wie die einzelnen Subdomains in der Apache-Konfiguration ausgesteuert werden. Andererseits ist die Organisation im Ordner "htdocs" nicht so schön. Angenommen der Kunde leitet seine Domain direkt nach htdocs und kommt spaeter auf die Idee Subdomains anzulegen, so sind die Zielordner der Subdomain auch ueber die Hauptdomain erreichbar. Das Problem kennt man moeglicherweise von Confixx.
An dieser Stelle wollte ich schlau sein und habe eine weitere Schicht eingefuehrt, so dass die Struktur nun wie folgt aussieht:
/var/www/web1/htdocs/www.example.com
/var/www/web1/htdocs/sub.example.com
(Der Umstand, dass unkonfigurierte Domains weiterhin nach /var/www/web1/htdocs/ laufen besteht leider weiterhin)
Nun hat man bei der Bedienung von LiveConfig jedoch ein Problem. In der Ansicht "Domains -> Auswahl -> Subdomain bearbeiten -> Webspace, Server-Verzeichnis" besteht keine Moeglichkeit ein Verzeichnis anzulegen.
An dieser Stelle waere ich gerne flexibeler.
Gruss ksmx
Sollte man glauben, ja. Aber leider hat GnuTLS ein Problem mit Intermediate certificate chain files, was zu so manchem Kopfzerbrechen fuehren kann. Hier ein Beispiel:
$ gnutls-cli -p 443 gitserver
Processed 152 CA certificate(s).
Resolving 'gitserver'...
Connecting to '...:443'...
|<1>| Note that the security level of the Diffie-Hellman key exchange has been lowered to 512 bits and this may allow decryption of the session data
- Peer's certificate is trusted
- The hostname in the certificate matches 'gitserver'.
- Session ID: F6:B5:98:55:44:62:75:63:35:8A:68:0D:78:25:A5:C3:FB:ED:8F:43:71:12:20:F1:A8:59:D1:09:00:05:F3:97
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
...
$ grep -A2 BEGIN /etc/ssl/certs/9a152b29e9b1e6f6-ca.crt
-----BEGIN CERTIFICATE-----
MIIEjzCCA3egAwIBAgIQdhASihe2grs6H50amjXAkjANBgkqhkiG9w0BAQUFADCB
qTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYGA1UECxMf
--
-----BEGIN CERTIFICATE-----
MIIERTCCA66gAwIBAgIQM2VQCHmtc+IwueAdDX+skTANBgkqhkiG9w0BAQUFADCB
zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Alles anzeigen
funktioniert also. Dann einmal drehen:
$ grep -A2 BEGIN 9a152b29e9b1e6f6-ca.crt
-----BEGIN CERTIFICATE-----
MIIERTCCA66gAwIBAgIQM2VQCHmtc+IwueAdDX+skTANBgkqhk
iG9w0BAQUFADCBzjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
--
-----BEGIN CERTIFICATE-----
MIIEjzCCA3egAwIBAgIQdhASihe2grs6H50amjXAkjANBgkqhk
iG9w0BAQUFADCBqTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRo
$
$ gnutls-cli -p 443 gitserver
Processed 152 CA certificate(s).
Resolving 'gitserver'...
Connecting to '...:443'...
|<1>| Note that the security level of the Diffie-Hellman key exchange has been lowered to 512 bits and this may allow decryption of the session data
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- The hostname in the certificate matches 'gitserver'.
*** Verifying server certificate failed...
*** Fatal error: Error in the certificate.
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
...
Alles anzeigen
Git verweigert an diese Stelle seinen Dienst. Der GnuTLS-Client beendet an dieser Stelle auch die Verbindung. Anfangs hatte ich Angst, dass LiveConfig automatisch die Zertifikate sortiert - dies ist gluecklicherweise nicht der Fall.
Gruss ksmx
Hi,
aktuell laeuft Liveconfig in Version 1.5.1-r1754. Ich wuerde gerne ein Certificate Chain aktualisieren. Die Aenderung wird angenommen und ist daraufhin auch per "CA anzeigen" sichtbar, jedoch schlaegt sich die Aktualisierung nicht im Dateisystem nieder. Beobachte ich /etc/ssl/certs/*-ca.crt, so erfahren die Dateien keine Aenderung.
In aller "Verzweifelung" habe ich schonmal einen Thawte Chain gegen den von Geotrust getauscht. Mein eigentliches Ziel ist die Reihenfolge von den zwei Zertifikaten im Thawte Chain zu drehen, um Anwendungen zufrieden zu stellen, die gegen eine TLS-Implementierung gebaut wurden und nicht auf OpenSSL setzen.
off-topic: Dieses Problem wird damit geloest.
Wie der nattch-Wert zu diesem Zeitpunkt war, kann ich leider nicht mehr beschwoeren. Hier ein Logauszug:
[2012/08/20 22:48:10.130620] [24693|24693] Received SIGTERM, immediately terminating child processes
[2012/08/20 22:48:10.130859] [24694|24694] Server child terminating... (shutdown=0, exitcode=0)
[2012/08/20 22:48:10.130919] [24694|24694] LiveConfig terminated.
[2012/08/20 22:48:13.380229] [24694|24694] Closing log file
[2012/08/20 22:48:13.383627] [24693|24693] Server child process 24694 terminated; return code: 0
[2012/08/20 22:48:13.383657] [24693|24693] Resource usage statistics:
[2012/08/20 22:48:13.383669] [24693|24693] Uptime: 292720 sec.
[2012/08/20 22:48:13.383680] [24693|24693] User time: 11.0176
[2012/08/20 22:48:13.383691] [24693|24693] System time: 13.0672
[2012/08/20 22:48:54.535837] [12277|12277] LiveConfig 1.5.1-1754 starting...
[2012/08/20 22:48:54.535931] [12277|12277] Database driver loaded: SQLite (3.7.13)
[2012/08/20 22:48:54.539510] [12277|12277] Upgrading database schema (r1695 -> r1705)
[2012/08/20 22:48:54.568774] [12277|12277] Upgrading database schema (r1705 -> r1715)
[2012/08/20 22:48:54.572326] [12277|12277] Upgrading database schema (r1715 -> r1719)
[2012/08/20 22:48:54.575570] [12277|12277] Upgrading database schema (r1719 -> r1731)
[2012/08/20 22:48:54.577202] [12277|12277] Upgrading database schema (r1731 -> r1737)
[2012/08/20 22:48:54.584460] [12277|12277] License is valid.
[2012/08/20 22:48:54.585558] [12277|12277] Server already running? Can't create shared memory segment: File exists
[2012/08/20 22:48:54.585605] [12277|12277] Closing log file
[2012/08/20 22:49:04.827643] [12467|12467] LiveConfig 1.5.1-1754 starting...
[2012/08/20 22:49:04.827822] [12467|12467] Database driver loaded: SQLite (3.7.13)
[2012/08/20 22:49:04.835669] [12467|12467] License is valid.
[2012/08/20 22:49:04.836333] [12467|12467] Server already running? Can't create shared memory segment: File exists
Alles anzeigen
Mir ist noch etwas eingefallen/aufgefallen: Nachdem der Update-Prozess die neue Liveconfig-Instanz nicht ordentlich starten konnte habe ich mir die Prozessliste angesehen und den Prozess 24696 gefunden (scheinbar auch ein weiterer Thread). Diesen habe ich per kill terminiert. Vielleicht ist es ein Indiz dafuer, dass liveconfig nicht unter jedem Umstand sauber/komplett beendet.
Gruss ksmx
Hi,
langsam wird es gruselig. Eben ist mir eine Lab-Version bei einem Update auf den Server gerutscht und prompt fangen leider die Probleme an. Das Update beendet mit einem "LiveConfig failed". Der Grund ist eine etwas wenig aussagekraeftige Fehlermeldung:
Im Handbuch habe ich dann den entscheidenen Hinweis gefunden. Das shmem-Segment soll man angeblich per
loeschen koennen. Den Parameter -s gibt es zwar... fuehrt aber in meinem Fall (Debian Squeeze) nicht zum Ziel. Vielmehr ist
der korrekte Parameter. Ein anschließender Start erfolgte glückerweise reibungslos.
Gruss ksmx
Hi,
es ist zwar sehr kleinlich aber ich konnte keine Erklaerung zum "priv"-Verzeichnis in der Dokumentation finden. Ich gehe davon aus, dass der User dort persoenliche Daten ablegen darf, welche nicht fuer den Webserver zugaenglich sein sollen.
Gruss ksmx
Soviel ich weiss kann man ganze Listen an Sieve-Files nutzen. Ich denke es ist auch interessant, sobald SPAM-Filter Loesungen integriert wurden, um Junk zu sortieren: http://wiki.dovecot.org/LDA/Si…vis_tagged_mail_filtering
Hi,
inspiziert man die Liste der konfigurierten Mailadressen (/etc/dovecot/passwd), so stellt man fest, dass pro Adresse eine userdb_sieve gesetzt ist und das System grundsaetzlich Sieve unterstuetzt. Spricht etwas dagegen von Haus aus managesieve zu laden und anzubieten oder ist bereits ein Weg vorgesehen Regeln in das System zu geben und ich bin lediglich noch nicht drueber gestolpert?
Gruss ksmx