It's the last week of exams for me at the Campus02 and to make learning for me even harder, snowfall started yesterday morning here in Graz. the district I'm living in, Andritz, seems to have got the most snow since it's north of down-town.
Here are some photographs I have taken out from the windows of my appartment.
[gallery link="file"]
Wie ich heute morgen erfahren habe, hat die Deutsche Bahn AG den Blog von Netzpolitik.org abgemahnt. Dort wurde ein internes Memo veröffentlicht, welches die Vorgehensweisen und den Umfang von internen Rasterfahndungen unter den Mitarbeiter zum Thema hat. Abgesehen davon, dass die DB AG wohl hin und wieder Triebfahrzeuge verliert ("Projekt Traviata"), Whistleblower verfolgt ("Projekt Uhu") und auch Ehepartner von hochrangigen Mitarbeitern bespitzelt ("Projekt Eichhörnchen"), wurden auch in vielen Fällen private Kontodaten (auch von Nicht-Mitarbeitern wie Ehe-Parntern usw.) und andere Informationen aus privater Korrespondenz ohne Anonymisierung der Fahndungsfirma Network Deutschland GmbH ausgehändigt.
Die DB AG musste nach der erfolgten Abmahnung nun wohl schmerzlich feststellen, dass der Streisand-Effekt schneller greift als es für möglich gehalten wird. Das interne Memo fand sich innerhalb weniger Stunden bereits auf Wikileaks wieder, die es nun sicher vor weiterer Verfolgung der Öffentlichkeit zugänglich halten. Eine kurze Recherche meinerseits in div. P2P-Netzen (z.B. Torrent oder eDonkey 1 oder 2) hat gezeigt, dass das Dokument auch dort bereits über den gesamten Globus gespiegelt wird. Genau dieses Verhalten, das sofortige Spiegeln der von einer Zensur bedrohten Information, hat sich unter dem Namen Streisand-Effekt etabliert.
Ich wünsche Markus Beckedahl, dem Blogger von Netzpolitik.org, viel Erfolg gegen die DB AG und werde im Falle eines Verfahrens auch meinen Beitrag in Form einer Geldspende leisten. Der DB AG rate ich, so schnell als möglich Gras über die Sache wachsen zu lassen, da jeder weitere Schritt von nun an mit Argusaugen beobachtet und kommentiert wird, was bei einer weiteren Verfolgung der derzeitigen Zensur-Linie nur zu weiterer negativer Publicity führen kann.
Due to recent additions in services provided by uni.fladi.at my current hardware faces its limits. Continuous high load and increasing demand in memory have slowed down the system for the last few month.
All this has led to one conclusion: Replace the old hardware the server is running on with a complete new and up to date system. The migration from old to new hardware will take place on Thursday 12th February. Starting on 09:00 UTC the server will be offline till 16:00 UTC. During this period all services on uni.fladi.at (SMTP, IMAP, WebDAV, SVN, HTTP and more) will be unavailable.
There will be an announcement once the migration is complete.
The new hardware is in place and everything seems to be running smooth.
I'll post some details on the new setup later. The most significant improvement is the switch to the amd64 architecture and the Courier IMAP daemon has been replaced by Dovecot.
Some pictures I took while searching for new routes on the mountains north of Kindberg.
[gallery link="file"]
The Wiki has been updated with the specs of the new system: http://wiki.fladi.at/bin/view/Main/UniFladiAT
Nothing fancy ... just for the purpose of documentation.
It just slowed down the whole page and provieded no relevant information for this page.
Yesterday a new version of the libldap-2.4-2 package was uploaded to Debian unstable and after applying it to my system it broke sudo-ldap. It was no longer able to talk to my LDAP server over TLS encrypted connection. Plain communication without TLS was still possible but I did not want to resign to unencrypted connections for such vital systems.
This is the error sudo-ldap threw:
sudo: ldap_start_tls_s(): Connect error
After a lot of investigation I found a useful option to enable in my /etc/ldap/ldap.conf file in a Bugreport from Roberto C. Sánchez:
sudoers_debug 2
This brought up a lot of configuration parameters when invoking sudo on the shell. One of this parameters was a litte suspicious to me:
sudo: ldap_set_option: tls_cert -> /etc/ssl/certs
It turned out that sudo-ldap honors the sslpath option in /etc/ldap/ldap.conf which is originally part of the Netscape SDK SSL and which was accidentially enabled by myself. After commenting out sslpath everything worked again with sudo-ldap.
The working version of my ldap.conf can be found in my SSO Subversion repository. It is also suitable for use with libpam-ldap, libnss-ldap and all of the ldap-utils.
Since two weeks, most of my sites are available through HTTPS and are properly using a certificate (only one!) corresponding to their hostnames.
Before I set this up for myself, I believed, that there was no way to run multiple vhosts with Apache on a single IP with SSL enabled. Recently Walter pointed me to a very interesting article on the Net which made me aware of a not so well known field inside x509 certificates: subjectAltName
With this field correctly used, it is possible to use a certificate for multiple virtual hosts inside Apache. The subjectAltName can contain some kind of alias for each hostname the certificate will be valid for. Thus it is possible to set the fields content to correspond to all the possible used hostnames for the IP Apache is running on. This leads to at least one drawback: The restriction that there is only one Certificate per IP is still in place.
Upon starting a SSL connection Apache will use the certificate and the browser will honor the subjectAltName in the same way as the CN field and thereby validate the hostname of the vhost.In my case I created a CSR for cacert.org which included all the hostnames of my vhosts with a little script that asks for all necessary values. After I got this signed, the certificate and the key were placed on the server and included in the config. A good location for certificates used by servers is /etc/ssl/private/ as it's protected from other users by default. I moved my cetificate to /etc/ssl/private/uni.fladi.at_cacert.crt and my key to /etc/ssl/private/uni.fladi.at_cacert.key and granted rights only to the group ssl-cert:
chown root:ssl-cert /etc/ssl/private/uni.fladi.at_cacert.* chmod 640 /etc/ssl/private/uni.fladi.at_cacert.*
For each vhost I created at least two files. One containing the custom configuration for this host and two vhosts,and one for HTTP and HTTPS, which includes the custom configuration file.
For mail.fladi.at this would be:
Custom configuration in /etc/apache2/includes/mail.fladi.at:
DocumentRoot /var/www/vhosts/mail.fladi.at ServerName mail.fladi.at CustomLog /var/log/apache2/access.mail.fladi.at.log combined ErrorLog /var/log/apache2/error.mail.fladi.at.log
Both vhosts in /etc/apache2/sites-available/mail.fladi.at:
<IfModule mod_ssl.c> <VirtualHost *:443> Include /etc/apache2/includes/mail.fladi.at Include /etc/apache2/includes/default-ssl </VirtualHost> </IfModule> <VirtualHost *:80> Include /etc/apache2/includes/mail.fladi.at </VirtualHost>
The file /etc/apache2/includes/default-ssl contains all the configuration needed to set up HTTPS for a vhost:
SSLEngine on SSLCertificateFile /etc/ssl/private/uni.fladi.at_cacert.crt SSLCertificateKeyFile /etc/ssl/private/uni.fladi.at_cacert.key BrowserMatch ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0
No normal user should have read-access to /etc/ssl/private/uni.fladi.at_cacert.crt and /etc/ssl/private/uni.fladi.at_cacert.key. I've ensured this by adding the user www-data to the group ssl-cert which grants read-access to the files in /etc/ssl/private/:
usermod -a -G ssl-cert www-data
This SSL configuration can now be used for any host included in the subjectAltName of the certificate /etc/ssl/private/uni.fladi.at_cacert.crt.
If you get a warning upon restarting Apache make sure that a NameVirtualHost is enabled for hosts on port 443. This should be done in /etc/apache2/ports.conf:
NameVirtualHost *:443
I could not wait any longer 
I pulled Gnome 2.24 from Debian experimental and so far, it works like a charm. No big changes are visible at first sight. The launcher icons in my panel now fade towrads me when I click them and every thing feels a bit faster, but that can be my own imagination.
Two things I noticed that are broken:
- My beloved sshmenu applet which is missing the symbol gtk_file_system_error_quark in /usr/lib/ruby/1.8/x86_64-linux/gtk2.so. DBTS mentions that there is a fix upstream and I hope a fixed package will soon be uploaded. Until then I switched to hotssh which does somewhat the same, but runs as a standalone application with SSH-sessions as tabs.
- gnome-keyring-daemon does start when called by libpam-gnome-keyring which leads to a lot of annoying password-prompts when doing SSH, GPG, WebDAV or CIFS through GVFS.
There are some warnings in /var/log/auth but I haven't found a fix for it yet:
gdm[3331]: gnome-keyring-daemon: couldn't lookup keyring component setting: Der Konfigurationsserver konnte nicht kontaktiert werden; mögliche Fehlerquellen sind, dass TCP/IP für ORBit nicht aktiviert ist oder auf Grund eines Systemabsturzes alte NFS-Sperren gesetzt sind. Unter http://www.gnome.org/projects/gconf/ erhalten Sie weitere Informationen (Details - 1: Verbindung zur Sitzung konnte nicht abgerufen werden: dbus-launch failed to autolaunch D-Bus session: No protocol specified gdm[3331]: Autolaunch error: X11 initialization failed.
It's on again: Gmail.com XMPP servers are dropping TLS enabled S2S connections again.
A strange feeling startet to cripple up my spine as I noticed that all of my Jabber contacts over at gmail.com are offline for the second day in a row. "Looks like an error with S2S" was the first thought that crossed my mind. So i waded through the logs of my ejabberd server and it came up with messages like this:
=INFO REPORT==== 2009-02-25 13:23:05 === I(<0.6971.0>:ejabberd_s2s_out:311) : Closing s2s connection: fladi.at -> gmail.com (close in wait_for_stream)
I turned off TLS in /etc/ejabberd/ejabberd.cfg and ... all gmail.com contacts back online.
{s2s_use_starttls, false}.
Turn TLS security back on ... gmail.com completely gone.
For heavens sake Google, fix your TLS implementation!
And by the way, TLS encrypted S2S does not prevent your XMPP provider from spying on your messages. It justs prevents this for all the ISP that XMPP data has to cross to get from one Jabber system to the other. So this is no show-stopper for happy data-mining Google!
Update: It seems that Google is experiencing problems with their accounts: http://googleblog.blogspot.com/2009/02/current-gmail-outage.html
Just some photos I took some time ago while playing with one of my Degus whos name is "Linus" by the way :-)[gallery link="file"]
Heute morgen habe ich etwas sehr seltsames erhalten: Der niederösterreichische LAbg. Karl Schwab von der FPÖ (eh schon wissen) bietet eine rhetorische Show der Superlative. Ich denke, Österreich hat seinen "Barak Obama" gefunden! Einfach mal reinhören.
Für die Ergreifung des integrierten Gronenhirsches (tot und lebendig!) wird eine Belohnung in Form einer Nullparzelle in "Meckenburg-Vorkommen" ausgelobt!