Beiträge von ksmx

    Hi,


    ich lege fuer gewoehnlich einen Redirect von example.com auf http://www.example.com an. Leider kommt es immer wieder zu der Situation, dass es Deep-Links auftauchen, welchen das "www" fehlt und ein direkter Wurf auf die Hauptseite ist nicht erwuenscht.


    Ich wuerde gerne vermeiden dieses Verhalten ueber eine .htaccess im entsprechenden Docroot auszusteuern. Vielmehr waere mir ein grosszuegiger Redirect lieb:


    Apache Configuration
    RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
    RewriteRule ^/.*         http://www.example.com [R=301,L]


    Spricht etwas dagegen eine Regel vom Stil


    Apache Configuration
    RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
    RewriteRule ^/(.*)$         http://www.example.com/$1 [R=301,L]


    einzusetzen? Alternativ waere mir ein Ratschlag lieb, ob ich Zeile 1486 des aktuellen apache.lua's entsprechend modifizieren darf, ohne dass mir alles um die Ohren fliegt. :)


    Gruss ksmx

    Hi,


    Postfix nimmt unter Debian Squeeze (mit der LiveConfig-Default Konfiguration ohne Postgrey & Virenscanner) jegliche Mails an und macht sich anschließend die Muehe einen Bounce zu schicken. Frueher hat man von diesem Verhalten abgesehen und moeglichst frueh Mails zurueckgewiesen. Ist dieses Verhalten gewuenscht?


    Hier ein Log-Schnippsel:


    Code
    Nov 16 11:38:08 tonno postfix/qmgr[13320]: 7A3DF8568FE: from=<a@b>, size=188, nrcpt=1 (queue active)
    Nov 16 11:38:08 tonno postfix/pipe[13329]: 7A3DF8568FE: to=<c@d>, relay=dovecot, delay=9.1, delays=9/0.01/0/0.02, dsn=5.1.1, status=bounced (user unknown)
    Nov 16 11:38:08 tonno postfix/cleanup[13328]: 736EC856900: message-id=<20121116103808.736EC856900@e>
    Nov 16 11:38:08 tonno postfix/bounce[13331]: 7A3DF8568FE: sender non-delivery notification: 736EC856900
    Nov 16 11:38:08 tonno postfix/qmgr[13320]: 736EC856900: from=<>, size=1986, nrcpt=1 (queue active)
    Nov 16 11:38:08 tonno postfix/qmgr[13320]: 7A3DF8568FE: removed
    Nov 16 11:38:08 tonno postfix/smtp[13332]: 736EC856900: to=<a@b>, relay=b:25, delay=0.17, delays=0/0.02/0.05/0.09, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as D279B6A1EA)
    Nov 16 11:38:08 tonno postfix/smtp[13332]: warning: network_biopair_interop: error reading 5 bytes from the network: Connection reset by peer
    Nov 16 11:38:08 tonno postfix/qmgr[13320]: 736EC856900: removed


    Die main.cf



    Danke schonmal fuer die Aufklaerung. :)


    Gruss ksmx


    PS. Ueber die TLS-Warnung grummel ich auch gerade. Dieses Problem scheint in letzter Zeit haeufig aufzutreten, wenn ein Squeeze-Postfix mit einem Lenny-Postfix spricht.

    Aktuell existiert dieses Feature noch nicht. Ich bin mir aktuell ueber die Best Practice in der Verarbeitung von System-Mails in Zusamemnspiel mit LiveConfig unschluessig. Der Hintergrund:


    LiveConfig setzt in der main.cf als mydestination ausschliesslich den localhost. Der Mailname meines Systems findet an dieser Stelle keine Beachtung. Aliases (/etc/aliases) werden somit ignoriert. Eigentlich bin ich nicht bereit den Mailname auch in LiveConfig anzulegen und die System-Aliase (postmaster, clamav, logcheck, etc.) dort zu pflegen.


    Bisher habe ich den Mailname manuell in den mydestinations eintragen und war regelmaessig ueberrascht, wenn er wieder verschwunden war. :(


    Gruss ksmx

    Hi,


    ich habe soeben eine weitere IP fuer SSL in Betrieb nehmen wollen. Das Vorgehen war wie immer (Serververwaltung, IP-Gruppe, Haekchen - die IP, SSL, exklusiv - Kunde ausgewaehlt, Vertrag geoeffnet, Domain editiert, SSL aktiviert, Zertifikat ausgewaehlt und gespeichert). Kurze Zeit spaeter musste ich feststellen, dass sich die Seite per SSL nicht oeffnen liess. Erst habe ich ein Problem mit dem Zertifikat vermutet (es ist ein Wildcard-Zert). Ich habe es naemlich bisher nur auf dem LiveConfig-Server in Betrieb gehabt und war nun positiv ueberrascht, dass auf den LC-Client uebertragen wird, sobald es fuer den Betrieb dort ebenfalls notwendig ist. Kurzum: /etc/ssl/{certs,keys} waren nicht das Problem.


    Danach habe ich die Apache-Konfiguration inspiziert und musste feststellen, dass der Listen-Eintrag in der "default" fehlt. Ein erneutes oeffnen des Kundens und das editieren der entsprechenden Domain hat Abhilfe geschaffen. Ich kann ausschliessen, dass ich "zu schnell war". Zwischen dem initialen Anlegen von IP-Gruppe/Domain-SSL und der Pruefung auf Funktion lagen mindestens 5 Minuten.


    Gruss ksmx

    Es handelt sich um ein Debian Squeeze. Initial habe ich LiveConfig installiert und dann zu lcclient migriert. Das dpkg.log erzaehlt folgendes:


    Code
    $ cat dpkg.log.1 dpkg.log | egrep -i "livec|lcc" | grep "status install"
    2012-10-23 18:02:26 status installed liveconfig 1.6.0-r1957
    2012-10-24 16:14:39 status installed liveconfig 1.6.0-r1957
    2012-10-24 16:15:33 status installed lcclient 1.6.0-r1976
    2012-10-25 18:54:04 status installed lcclient 1.6.0-r1979
    2012-10-28 10:52:48 status installed lcclient 1.6.0-r1980
    2012-11-01 18:19:28 status installed lcclient 1.6.0-r1987
    2012-11-04 09:39:36 status installed lcclient 1.6.0-r2002


    Im lcclient.log befinden sich keine Informationen ueber das initiale Verteilen der Konfiugration(en). Ein liveconfig.log gibt es leider nicht (mehr).

    Ich habe auf einem System lcclient laufen und war auch gerade ueberrascht, dass kein lclogsplit-Prozess laeuft. Es hat sich herausgestellt, dass die Datei /etc/apache2/conf.d/liveconfig in meinem Fall nicht existierte.

    Waere es nicht moeglich in diesen Faellen ein wenig zu Tricksen? Zum Beispiel in diese Richtung:


    Code
    ORDER BY CAST(SUBSTRING_INDEX(RTRIM(field), liveconfigWebspacePrefix, -1) AS SIGNED INTEGER)


    Ich empfinde diese falsche Sortierung auch als extrem störend und kenne nur eine Software, die es genauso schlecht macht: Lexware.

    Ich stelle gerade fest, dass ich mich selbst ueberlistet habe und ueberhaupt kein Fehler vorliegt. Ich hatte temporaer auf dem neuen Server "liveconfig" installiert und fuer Tests einen Benutzer angelegt ("web1"). Nach der Entscheidung zur Business-Lizenz habe ich dieses Verzeichnis gesichert (verschoben) und LiveConfig deinstalliert. Deshalb hatte ich den Ordner /var/www leer geglaubt.


    Die Wirklichkeit war nun jedoch anders:


    Code
    $ cat /var/log/dpkg.log.0 | grep liveconfig
    2012-10-24 16:14:39 status installed liveconfig 1.6.0-r1957
    2012-10-24 16:14:39 remove liveconfig 1.6.0-r1957 1.6.0-r1957
    
    
    $ ls -l /var/www | grep web1
    drwxr-xr-x 3 root root 4096 24. Okt 15:56 web1


    Vergleicht man die Zeiten, dann steht fest, dass LiveConfig noch fix vor der Deinstallation ein paar neue Verzeichnisse angelegt hat. :) Ich hoffe meine Unachtsamkeit ist zu entschuldigen!


    Gruss ksmx

    So ist es. Auf dem neuen Server ist der komplette Verzeichnisbaum fuer den Webspace "web1" vorhanden, obwohl er nur auf den alten Server gehoert. Besitzer dieser Dateien und Verzeichnisse ist jedoch web4. Es gibt keinen Eintrag in der /etc/passwd.

    Hi,


    ich habe vor ein paar Stunden auf die letzte Preview aktualisiert. Gerade eben musste ich feststellen, dass der "liveconfig"-Prozess Amok laeuft.


    Code
    Tasks: 197 total,   2 running, 195 sleeping,   0 stopped,   0 zombie
    Cpu(s): 13.2%us,  0.4%sy,  0.0%ni, 86.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.1%st
    Mem:  27254620k total, 23360592k used,  3894028k free,   229020k buffers
    Swap: 33554424k total,   458656k used, 33095768k free,  9196236k cached
    
    
      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                
    12502 liveconf  20   0  161m  19m 2492 R   99  0.1 111:54.78 liveconfig                                                                                                             
    [...]


    Der Restart wurde mit einem "failed" quittiert. Der Inhalt des Logs sieht aktuell so aus:


    Code
    [2012/10/25 22:02:33.007736] [12501|12501] Received SIGTERM, immediately terminating child processes
    [2012/10/25 22:03:03.061580] [29564|29564] LiveConfig 1.6.0-1979 starting...
    [2012/10/25 22:03:03.061673] [29564|29564] Database driver loaded: SQLite (3.7.13)
    [2012/10/25 22:03:03.101702] [29564|29564] License is valid.
    [2012/10/25 22:03:03.102000] [29564|29564] Can't open any socket for address (null), port 8443
    [2012/10/25 22:03:03.102046] [29564|29564] Closing log file


    Scheinbar lauscht dort noch etwas gestorbenes am Port 8443.


    Code
    $ netstat -putln | grep 8443
    tcp        0      0 0.0.0.0:8443            0.0.0.0:*               LISTEN      12502/liveconfig


    Per SIGTERM laesst sich der Prozess nicht verjagen - 100% CPU konsumiert er weiterhin. Ich habe den Prozess per SIGKILL beendet. Das uebrig bleibende SHM-Segment sieht so aus:



    Hui, nach einem Neustart standen aussagekraeftige Zeilen im Log:


    Hi,


    seit gestern betreibe ich eine LiveConfig Business-Instanz mit einem LiveConfig Standard-Client. Neue Vertraege werden (wenn gewuenscht) ordnungsgemaess auf dem neuen Server (LC-Client) abgebildet. Auf dem anderen Server existierten schon Vertraege, welche laut "Vertraege -> Statistik" auf die bisherige Host-ID (localhost) zeigen.


    Nun wurde in einem dieser alten Vertraege eine Aenderung gemacht (fastcgi aktiviert). Dies schlaegt sich seltsamerweise auch auf dem lcclient in folgender Weise nieder:



    Schau ich mir den Inhalt des php-fcgi-starter an, so zeigt die PHPRC auf web1. Von den Rechten her gehoeren die Dateien aber web4 (dem einzigen, neuen und rechtmaessigen Vertrag auf dem Client).


    Gruss ksmx


    PS. Auf beiden Servern wird die Version 1.6.0-r1976 eingesetzt.

    Zwei LC-Restarts spaeter hatte sich das Problem schon verfluechtigt. Nun ist aus LiveConfig der LCclient geworden und die Werte sehen weiterhin normal aus.