You are here

Apache

Slashdot'ted

Ich hatte ja dieser Tage berichtet, daß wir den m68k Port von Debian wieder so halbwegs in die Spur gebracht haben, weil die ersten Autobuilder wieder laufen. Der Post, weil er Debian betraf und englischsprachig war, erschien natürlich auch auf Planet Debian, wo er ein paar hundert Leser generierte. Aber irgendwie fand die Nachricht dann auch zu Slashdot. Und so wurde ich dann zum ersten Mal slashdotted:

Ich hatte das gar nicht so recht mitbekommen, wunderte mich nur, warum das Log des Webservers, das ich für solche außergewöhnlichen Zwecke immer mitlaufen lasse, plötzlich so permanent durchscrollte und der Rechner so langsam wurde. Eigentlich war ich nämlich dabei, einen kleinen Fehler im update-buildd.net Script zu beheben und wunderte mich, daß der Connect zum Webserver so langsam war bzw. nicht zustandekam.

Insgesamt kamen innerhalb von wenigen Stunden ca. 15x mehr Seitenaufrufe zustande als üblich. Ich hab das dann dadurch gelöst, daß ich den Webserver kurz heruntergefahren habe, um der virtuellen Maschine mehr RAM und mehr CPU zu geben. Außerdem hab ich dann noch die Anzahl der Apache Prozesse erhöht. Aber auch das Herunterfahren hat aufgrund der Last einige Zeit in Anspruch genommen.

Naja, heute hat sich der Traffic wieder normalisiert, nachdem die Meldung nicht mehr auf der ersten Seite von Slashdot vorhanden ist.

Kategorie: 
 

Apache and SNI - problems with some clients

Never change a running system. Old but true saying, but sometimes there's no other chance. Until a few days ago I was happy with SSL vhosts running with a single SSL certificate. Then I needed to add another SSL certificate for another site with several subdomains like svn.site-A.de, trac.site-A.de and www.site-A.de. With Apache2 running on Squeeze it's possible to make use of Server Name Indication (SNI) mechanism in order to be able to use multiple SSL certs on a single IP based vhost setup.

Well, it works for some client software, but apparently it does not work well with korganizer or Firefox Sync plugin nor with Cyberduck on OS X. Here's an example config: 

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile  /etc/apache2/ssl/site-A-cert.pem
SSLCertificateKeyFile  /etc/apache2/ssl/site-A-key.pem
SSLOptions StrictRequire
SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM
SSLVerifyClient none
SSLProxyEngine off

This is identical to all SSL vhosts on my system. The funny thing is now that it works for two sites (site A and site B) while it doesn't work for site C. In Firefox Sync plugin I get an error that the connection couldn't be established while on Cyberduck (a webdav client for OS X) I get a requester stating that I get cert for site A on site C. Pointing the browse to the appropriate URL I get the correct cert for site C on site C.

Is there anything I miss with SNI setup in Apache?

Kategorie: 
 

Apache Makros

Man lernt immer wieder etwas Neues hinzu. Heute: Makros beim Webserver Apache! Das zugrundeliegende Problem war, daß ich verschiedene virtuelle Hosts konfiguriert hatte, die ich sowohl über HTTP als auch HTTPS verfügbar haben wollte. Bisher habe ich dann immer die <VirtualHost> Direktive kopiert und um die notwendigen Zeilen für SSL erweitert.

Mal davon abgesehen, daß man dann immer zwei VHosts konfigurieren und pflegen muss, trägt das natürlich auch nicht zur Übersichtlichkeit bei, ist aber umso anfälliger für Konfigurationsfehler. Abhilfe schafft hier nun die Installation libapache2-mod-macro. Damit kann man Macros in den Konfigurationsdateien definieren und sich so viel Arbeit ersparen. Für HTTP und HTTPS VHosts sind zum Beispiel die meisten Zeilen in der Config gleich, etwa ServerName, DocumentRoot, LogFile, etc. Somit ergibt sich dann folgende Möglichkeit: 

<Macro beispielconfig>
  ServerName foobar.de
  ServerAlias barbaz.de
  DocumentRoot /path/to/www
</Macro>

<VirtualHost 1.2.3.4:80>
  Use beispielconfig
</VirtualHost>

<VirtualHost 1.2.3.4:443>
  SSLEngine On
  SSL....
  Use beispielconfig
</VirtualHost>

Mit Hilfe von libapach2-mod-macro kann man auch noch mehr Sachen machen, wie auf perl.apache.org beschrieben, indem man mit Variablen arbeitet.

Ich glaube, das Modul wird nun zu einem meiner Lieblingsmodule bei Apache werden. Schade nur, daß ich erst heute entdeckt habe. :)

Kategorie: 
 

Upgrading to Squeeze - and suddenly CGI doesn't work anymore

Before I upgraded from Lenny to Squeeze, all my CGI scripts were working properly. The CGI scripts has been executed by Apache and resulted in rendered webpage. After the upgrade to Squeeze all those CGI scripts stopped been executed but instead started to get displayed as a plain text.

Common to all those CGI scripts is that they have .phtml as suffix, but the bang path/shebang consists of "#!/usr/bin/python". As an example you can have a look at Buildd.Net and its scripts like this one. The section in Apaches config looks like this: 

        <Directory /home/builddnet/unstable/WWW/cgi/>
                Options -Indexes +ExecCGI +FollowSymLinks
                AddHandler cgi-script .cgi .sh .pl .py .phtml
                Order allow,deny
                Allow from all
        </Directory>

So, I would expect that the CGI script handler will get executed when loading a *.phtml file and that the shebang would be honoured. Funny enough: when I rename that script to *.cgi it works.

I haven't figured out yet, what causes this beahviour or what have changed during the upgrade - and how to revert to the old behaviour. So, dear lazyweb, can you give me some hints and pointers?

 

Kategorie: 
 

Gesucht: URL-Rewrite für Drupal

Vor kurzem bin ich ja von Serendipity auf Drupal umgestiegen. Dadurch haben sich natürlich auch meine RSS-Feeds geändert. Durch die Ankündigung im Blog hatte ich zwar gehofft, daß die meisten Subscriber von sich aus auf die neuen Feeds umsteigen, aber so wie es ausschaut, gibt es immer noch einige, die den alten Feed suscribed haben. Also muss ich mir nun etwas mit mod_rewrite basteln. Der alte Feed hatte die folgende URL: 

http://bluespice.dyndns.org/index.php?/feeds/index.rss2

Die neue Feed-URL ist hingegen: 

http://blog.windfluechter.net/blog/feed

bzw.

http://blog.windfluechter.net/index.php?q=/blog/feed

Drupal benutzt also bereits selber Rewrites, um von der langen URL in die kurze Form (ohne "index.php?q=") zu kommen. Ich habe es dann mal mit folgender Konfiguration im Apache versucht: 

RewriteEngine on
RewriteCond %{QUERY_STRING} &?/feeds/index\.rss2
RewriteRule ^index\.php\?/feeds/index\.rss2$ http://blog.windfluechter.net/blog/feed [L,PT,R=301]

Das funktioniert nur leider nicht. Laut Apache Doku muss die RewriteCond auf den Query String sein. Anstatt aber den Query-String umzuschreiben, will ich ja nur auf eine andere URL weiterleiten.

Hat jemand einen Tipp für ein Rewrite, das auch noch funktioniert?

UPDATE 23.10.2010:
Eigentlich war es nun doch ganz einfach. Folgende Zeilen scheinen nun wohl zu funktionieren: 

RewriteCond %{QUERY_STRING} /feeds/index\.rss2
RewriteRule ^/ /blog/feed? [R]
 

Kategorie: 
 

Pages

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer