Beiträge von ksmx

    Hi,


    mir sind heute folgende Eintrag im Logfile von LiveConfig aufgefallen:


    Code
    [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:


    Code
    Can't get system informations: (null)


    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


    Code
    [Mon Oct 15 10:36:12 2012] [notice] SIGUSR1 received.  Doing graceful restart


    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:


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

    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

    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,


    bei jedem FTP-Login eines (virtuellen LiveConfig) FTP-Users sehe ich folgende zwei Zeilen im auth.log:


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



    funktioniert also. Dann einmal drehen:



    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.


    Code
    git clone https://gitserver/git/test.git
    Cloning into 'test'...
    error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://gitserver/git/test.git/info/refs
    fatal: HTTP request failed

    Wie der nattch-Wert zu diesem Zeitpunkt war, kann ich leider nicht mehr beschwoeren. Hier ein Logauszug:



    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:


    Code
    Server already running? Can't create shared memory segment: File exists


    Im Handbuch habe ich dann den entscheidenen Hinweis gefunden. Das shmem-Segment soll man angeblich per


    Code
    ipcrm -s <shmid>


    loeschen koennen. Den Parameter -s gibt es zwar... fuehrt aber in meinem Fall (Debian Squeeze) nicht zum Ziel. Vielmehr ist


    Code
    ipcrm -m <shmid>


    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

    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