trac on apache2 with mod_fcgid: can’t apply process slot
Recently had some serious trouble running Trac on Apache2 with mod_fcgid. An included Doxygen-page spent hours loading and the Apache error log contained lines like this:
[Sat Apr 21 21:38:26 2012] [warn] [client 88.65.186.160] mod_fcgid: can't apply process slot for /home/webX/trac/htdocs/favicon.ico [Sat Apr 21 21:42:01 2012] [warn] [client 66.249.66.247] mod_fcgid: read data timeout in 40 seconds [Sat Apr 21 21:42:01 2012] [error] [client 66.249.66.247] Premature end of script headers: trac.fcgi
The cause I finally discovered was that I had mixed up several ways of running Trac (mod_python, mod_fastcgi, mod_fcgid) while testing performance, so the lines in my Trac vhost looked like this (including the disabled lines):
<VirtualHost x.y.z.w:80> ServerName domain.org ServerAlias www.domain.org DocumentRoot /home/webX/trac/htdocs Alias /chrom/common /usr/share/pyshared/trac/htdocs Alias /chrome/site /home/webX/trac/htdocs Alias /favicon.ico /home/webX/trac/htdocs/favicon.ico <Directory "/usr/share/pyshared/trac/htdocs"> Order allow,deny Allow from all </Directory> <Directory /home/webX/trac/htdocs> Order allow,deny Allow from all </Directory> ScriptAlias / /home/webX/trac/fcgi/trac.fcgi/ # <Location /> # SetHandler fcgid-script # Options ExecCGI # Allow from all # </Location> <Location "/login"> AuthType Basic AuthName "Trac" AuthUserFile "/home/webX/trac/passwd.htaccess" Require valid-user </Location> CustomLog /var/log/apache2/domain.org.access.log combined ErrorLog /var/log/apache2/domain.org.error.log </VirtualHost>
Removed the superfluous <Location /> - Block and trouble was gone 
Confixx Setup nachbessern
An einem frisch per Virtualisierungs-Container installierten Confixx schraubt man üblicherweise an ein paar Stellen herum, um das Panel abzusichern. Bei einem kürzlich von mir durchgeführten Server-(Provider-)Wechsel war diesmal jedoch so viel Handarbeit nötig, dass ich diese hier mal kurz festhalten möchte.
Ohne manche der mit [Fix] markierten Schritte hätten einige Dienste übrigens garnicht oder mit unschönen Nebeneffekten funktioniert, weshalb ich vom Installations-Image meines Providers auch ziemlich enttäuscht war - da hätte ich es besser selbst aufgesetzt Als Distribution kam bei mir Debian 6.0.4 Squeeze zum Einsatz.
Hinweis: Irren ist menschlich, alle hier vorgestellten Schritte erfolgen auf eigene Gefahr! Backups sind Gold wert!
Upgrade
Bei mir war ein Upgrade auf die aktuelle Version 3.3.9 erforderlich, wer einen Guide sucht kann hier fündig werden.
[Security] MySQL-Accounts ändern
Das Wichtigste zuerst: unbedingt alle mit Confixx in Verbindung stehenden Passwörter überprüfen. Bei meinem Setup war doch tatsächlich als Passwort für den MySQL-root 'T' (ja, der Buchstabe 'T') gesetzt! Und das bei einem standardmäßig über PHPMyAdmin von außen erreichbaren Dienst!
Ich habe einen separaten MySQL-Benutzer für Confixx erstellt und ihm entsprechende Rechte gegeben. Anzufassen sind folgende Configs:
<confixx-install-dir>/confixx_main.conf: ab Zeile 547/var/www/confixx/settings.inc.php: Werte aus der confixx_main.conf übertragen/etc/spamassassin/local.cf(wird aber sowieso neu generiert)
[Fix] Mail-Aliase behalten
Diverse Pakete legen eigene Benutzer an und tragen diese in die /etc/aliases ein, z.B. logcheck. Dumm nur, dass Confixx die /etc/aliases periodisch (bzw. bei jeder Änderung an Postfächern) neu schreibt, und zwar "dumm" nach einem eigenen Template, was die neuen Benutzer nicht reflektiert.
Hier ist also dauerhaft Handarbeit angesagt: neue System-Aliase oder eigens angelegte müssen in die <confixx-install-dir>/safe/aliases_header aufgenommen werden, um nicht verloren zu gehen.
[Fix] Spamassassin
Ohne Nachbessern war bei mir Spamassassin nicht funktionstüchtig. Ich habe einen separaten Benutzer für den spamd angelegt:
$ groupadd -g 5001 spamd $ useradd -u 5001 -g spamd -s /usr/sbin/nologin -d /var/lib/spamassassin spamd $ mkdir /var/lib/spamassassin $ chown spamd:spamd /var/lib/spamassassin
Dann die Startoptionen für den Daemon korrigieren:
# /etc/default/spamassassin (...) OPTIONS="--create-prefs --nouser-config --max-children 5 -H /var/lib/spamassassin -u spamd -q" (...)
[Fix] AWStats
AWStats muss scheinbar das 10-Minuten-Update als root durchführen, daher unter /etc/cron.d/awstats beim oberen Eintrag den Benutzer auf root ändern. Das habe ich allerdings nicht näher untersucht, also besser selbst nochmal checken.
[Fix] Apache "other vhosts" log
Da Confixx für jeden Vhost nur ein Custom-Log über eine Pipe setzt (/etc/apache2/confixx_vhost.conf), bewirkt die Direktive in /etc/apache2/conf.d/other-vhosts-access-log, dass jeder (!!) Zugriff auf irgendeinen Vhost unter /var/log/apache2/other_vhosts_access.log vermerkt wird. Das lässt das File je nach Auslastung des Servers extrem schnell wachsen, man sollte die Option also der Performance und des Plattenplatzes zuliebe besser auskommentieren.
[Fix] Postfix SASL authentication
Abgesehen von einer komplett überarbeiteten main.cf musste ich für Postfix noch die SASL-Authentifizierung fixen, was praktischerweise in der /etc/default/saslauthd schon vorgesehen ist:
# Example for postfix users: "-c -m /var/spool/postfix/var/run/saslauthd"Details siehe /usr/share/doc/sasl2-bin/README.Debian.gz.
Das wars erstmal mit den wichtigsten Nachbesserungen. Confixx in eine eigene Subdomain zu sperren und das Vhost-Schema dauerhaft zu ändern war nochmal eine ganz eigene Angelegenheit - vielleicht dazu demnächst ein HowTo.
365 Tage Uptime
Happy Birthday, vServer: heute vor einem Jahr wurdest Du erstellt und gebootet.
[alex@vserver ~]$ uptime 23:07:56 up 365 days, 1:26, 1 user, load average: 0.00, 0.00, 0.00
Seit damals war - auch für sämtliche Konfigurationsorgien - kein einziger Reboot notwändig. Auch wenn das bei einer XEN-VM wie Dir recht schwer zu messen ist, zeigt mein Tracking der Pakete auf den Netzwerkschnittstellen keine Sprünge oder Unstimmigkeiten.
Auf das nächste Jahr ohne Reboot! 
RFC-ignorant
RFC2142 beschreibt u.A. die reservierte Adresse postmaster@ für jede Domain mit smtp-Server. Bisher habe ich mein Setup so konform wie möglich gehalten, um nicht auf einer Blacklist von rfc-ignorant.org zu landen.
Blöderweise sind 100% der ~7 SPAM-Mails, die ich täglich noch bekomme durch eben diese Ausnahmeregelung (kein Filtering) für die reservierten Adressen, insb. postmaster@, verschuldet.
Da simple Regex-Regeln mittlerweile nicht mehr darauf matchen, und ich absolut keine Lust habe, mit SpamAssassin & Co. anzufangen (ich teile diesbezüglich die Ansicht des Autors von Das Postfix-Buch, Peer Heinlein), schließe ich nun also die Lücke und pfeife auf RFC2142.
Mal schauen, wie schnell man gelistet wird
Automatische Vhosts mit Lighttpd
Mein bereits erwähntes lighttpd-vhost-script hat ein Update erfahren und unterstützt jetzt Subdomains und Vhost- sowie Subdomain-spezifische configs:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | #!/bin/bash VHOST_ROOT="/var/www" VHOST_DEF="default" VHOST_CONF="vhost.conf" SBD_ROOT="subdomains" DOC_ROOT="htdocs" for VHOST in $(find $VHOST_ROOT -mindepth 1 -maxdepth 1 -type d -exec basename {} \;); do # skip default vhost if [ "$VHOST_DEF" == "$VHOST" ]; then continue fi echo "\$HTTP[\"host\"] =~ \"^(www\.|)$VHOST\" {" echo " server.document-root = \"$VHOST_ROOT/$VHOST/$DOC_ROOT\"" echo " accesslog.filename = \"/var/log/lighttpd/$VHOST.access.log\"" if [ -e "$VHOST_ROOT/$VHOST/$VHOST_CONF" ]; then # include vhost config cat "$VHOST_ROOT/$VHOST/$VHOST_CONF" fi echo "}" echo "" # subdomains if [ -d "$VHOST_ROOT/$VHOST/$SBD_ROOT" ]; then for SBD in $(find $VHOST_ROOT/$VHOST/$SBD_ROOT -mindepth 1 -maxdepth 1 -type d -exec basename {} \;); do echo "\$HTTP[\"host\"] =~ \"^$SBD.$VHOST\" {" echo " server.document-root = \"$VHOST_ROOT/$VHOST/$SBD_ROOT/$SBD/$DOC_ROOT\"" echo " accesslog.filename = \"/var/log/lighttpd/$VHOST.access.log\"" if [ -e "$VHOST_ROOT/$VHOST/$SBD_ROOT/$SBD/$VHOST_CONF" ]; then # include subdomain's custom config cat "$VHOST_ROOT/$VHOST/$SBD_ROOT/$SBD/$VHOST_CONF" fi echo "}" done echo "" fi done |
Server setup – Teil 3: Mailserver
Jeder, der einfach nur einen kleinen Mailserver mit Greylisting und IMAP-Daemon aufsetzen will, und sich damit an Exim4/Courier wagt, wird verstehen, warum man zum Thema Mailserver so gut wie kein aktuelles Material im Netz findet: hat man die configs endlich so, wie man sie haben will, will man um Gottes Willen nicht nochmal damit in Kontakt kommen
Als endgültige MTA/MDA Lösung bin ich nun bei Postfix/Dovecot geblieben (danke nochmal für den Tipp, Mario ). Warum? Weil es so verdammt viel einfacher zu konfigurieren ist, und meine vergleichsweise primitiven Anforderungen an einen MTA trotzdem voll erfüllt. Will man einen skalierbaren Mailserver mit Loadbalancing und diversen Features für größere Setups, ist man sicher mit Exim4 besser beraten.
Da das Setup stark von der Umgebung abhängt, möchte ich hier einfach auf die beiden Quellen verweisen, die ich besonders hilfreich fand:
- Postfix, policyd-weight & dovecot imapd/pop3d Howto für Debian lenny 5.0
- Postfix & Dovecot Mailserver unter Debian GNU/Linux 5.0 "Lenny" Howto
Interessant fand ich auch den Hinweis, auf den ich bei meiner Recherche zur Exim4-Einrichtung gestoßen bin, betreffend SPOP3 und SIMAP, die SSL-Varianten der beiden Dienste: gemäß RFC 2595 soll die Verwendung separater Ports für die SSL-gesicherten Varianten von POP3 und IMAP nur eine Übergangslösung gewesen sein, weil damals das Kommando STARTTLS noch von kaum einem Client unterstützt wurde. Leider hatte ich noch keine Zeit, das Dokument zu lesen.
Server Setup – Teil 1
Mehr oder weniger als Nachtrag hier ein paar Worte zum Setup des bereits angekündigten, neuen Servers: cron, logrotate und iptables.
Die Kiste (Debian 5.0 Lenny, minimal install) hatte standardmäßig anacron installiert, aufgrund der erweiterten Features wie load-condition und nice-values bin ich da gleich auf fcron umgestiegen.
Unter Lenny ist kein init-script mehr für iptables vorhanden, es ist wohl vorgesehen, einen Hook in den up- und down-scripts für die entsprechenden Interfaces zu verwenden. Da man auf einem Server ja eine eher statische Umgebung hat, genügte mir hier ein auf meinem iptables-setup-script basierendes init-script.
Zum logrotate-setup bleibt noch zu sagen, dass der Parameter dateext sich als sehr hilfreich erwiesen hat.
Veränderungen
In den kommenden Tagen wird es wahrscheinlich einige Downtimes der Seite geben, ich ziehe auf einen neuen Server um und wechsle gleich mal sämtliche Dienste
Apache -> lighttpd, qmail --> exim4, proftpd --> vsftpd, um nur die größten zu nennen. Lots of fun, immerhin mache ich das freiwillig