Mein Zweithirn

Wenn man wichtige Systemdienste updaten will, sollte man ein schnell einspielbares Backup der alten Software besitzen. Denn wenn die neue Version wider erwarten nicht das tut, was sie soll, versucht man auf die alte Version zurückzuspringen. Ein emerge package dauert aber seine Zeit, die Konfiguration muss danach auch wieder angepasst werden. Abhilfe schafft quickpkg auf dem portage-Paket. Es erstellt Binärpakete, ähnlich wie emerge --buildpkg package, aber nicht durch Compilen aus frischem Sourcecode, sondern durch packen der bereits compilten und installierten Dateien. Funktioniert logischerweise nur mit auf dem System installierten Paketen. Sehr hilfreich dabei ist auch die Kommandozeilenoption --include-config=y, welche auch die Konfiguration mit packt. Darin sind nur Dateien eingeschlossen, die bei einem unmerge (emerge -C package) verschwinden würden. Beim Ausspielen auf anderen Systemen ist zu beachten ist, das hier die möglicherweise gegenüber den Defaults geänderten Configdateien genommen werden. Die erzeugten Pakete landen in /usr/portage/packages. Auf den meisten Systemen muss das Verzeichnis noch erstellt werden. Zum schnellen Wiedereinspielen reicht ein emerge packages.tbz2.

Subversion mit WebDAV einzurichten und zu nutzen, ist total einfach. Zumal meist auf den Servern schon ein Apache läuft, der dann nur noch ein Zusatzmodul benötigt. WebDAV sollte man wegen Klartextpasswörtern nur in Verbindung mit SSL betreiben. Nun bin ich auf ein misteröses Problem gestoßen: Wenn man versucht mit svn move datei1 datei2 eine Datei umzubennen bzw. zu verschieben (oder per svn copy zu kopieren), meckert Subversion spätestens beim Einchecken mit

svn: Übertragen fehlgeschlagen (Details folgen): svn: COPY of datei2: 502 Bad Gateway (https://svn.domain.de)

Danach hab ich auch eine Weile gegooglet, aber nach einer erfolglosen Weile aufgegeben. Schließlich konnte ich mir immer mit einem

mv datei1 datei2 svn revert datei1 svn delete datei1 svn add datei2

aushelfen. Aber schön ist das, gerade bei vielen Dateien, sicherlich nicht. Die Ursache dieses Problem liegt am Apache im Zusammenspiel mit Vhosts und SSL. SVN über WebDAV nutzt HTTP als Transportprotokoll. In unserem Fall mit HTTPS geschützt. Ein Request zum Kopieren sieht ungefähr so aus:

COPY /svn/repos/datei1 HTTP/1.1 Host: svn.example.org Destination: https://svn.example.org/svn/repos/datei2

Die Tücke liegt im Detail. Theoretisch sollte der Aufruf in etwa folgendes bedeuten:

COPY https://svn.example.org/svn/repos/datei1 https://svn.example.org/svn/repos/datei2

Einfach auf dem selben Server, im selben Verzeichnis eine Datei kopieren. Dies missinterpretiert der Apache jedoch und macht daraus:

COPY http://svn.example.org/svn/repos/datei1 https://svn.example.org/svn/repos/datei2

Der Apache bemerkt, dass er nicht zwischen 2 verschiedenen Hosts kopieren kann und beendet die Anfrage mit 502 Bad Gateway. Das liegt an einer fehlerhaften Vhostkonfiguration. So fehlt dem Vhost svn.example.org in seiner Definition die Direktive SSLEngine On, die dem Apache vermittelt, es mit einem mit SSL-Verbindung geschütztem Vhost zu tun zu haben. Fehlt diese, wird aus svn.example.org halt http://svn.example.org Wie man die SSLEngine-Direktive aktiviert bekommt, beschreibe ich in einem anderen Artikel. Quellen: http://www.science.uva.nl/research/air/wiki/Subversion502BadGateway

Laut Dokumentation unterstützt Apache mit SSL keine Vhosts, da Vhosting auf Grundlage des HTTP-Headers funktioniert und SSL ein Layer drunter liegt und die Verbindung bereits sichert, bevor nur ein Byte HTTP-Protokoll gesprochen ist. Man kann es trotzdem nutzen, muss dafür aber ein paar Dinge tun. Pro IP brauch man 1 SSL-Zertifikat, in dem alle Hostnamen, die auf die IP zeigen, angegeben sein müssen. Für Subdomains braucht man entweder ein Wildcardzertifikat oder man muss alle existierenden Hostnamen eintragen. Solche Zertifikate gibt es z.B. bei CaCert. Dazu muss man sich einen CSR erzeugen und auf der Webseite hochladen. Um Zertifikate mit mehreren Hostnamen zu erstellen, muss man das Attribut subjectAltName benutzen. Zum Erstellen mit OpenSSL brauch man eine openssl.cf. Die wichtigsten Einträge dafür:

[ req ] distinguished_name = req_distinguished_name req_extensions = v3_req [ req_distinguished_name ] commonName = Common Name (eg YOUR name) commonName_default = domain.de [ v3_req ] subjectAltName = DNS:*.domain.de

Erstellt wird der CSR mit dem Aufruf:

openssl req -new -key domain.de.key -days 730 -nodes -out domain.de.csr -config openssl.cf

Das erzeugt einen Request für ein Wildcardzertifikat für domain.de. Mit der Option -x509 kann man sich das Zertifikat gleich selbst signieren, wenn man keinen Acocunt bei CaCert oder einer anderen CA hat. [Update: Damit die Extension mit dem subjectAltName auch im selbstsignierten Zertifikat erscheint, muss man statt

req_extensions = v3_req

x509_extensions = v3_req

angeben, da hier ja kein CSR erstellt wird.] Weitere Infos zum Erzeugen solcher CSRs findet man in der CaCert-Wiki bzw. in den Manpages zu req und config aus dem OpenSSL-Paket. Das unterschriebene Zertifikat legt man dann z.B. in /etc/apache2/ssl/domain.de.crt ab. Entscheidend ist dann die Kofiguration des Default-Host. Weit verbreitet sind folgende Einstellungen:

Listen *:443 NameVirtualHost *:443 <VirtualHost *:443>    ServerName www.domain.de    SSLEngine on    SSLCertificateFile /etc/apache2/ssl/domain.de.crt    SSLCertificateKeyFile /etc/apache2/ssl/domain.de.key </VirtualHost> <VirtualHost *:443>    ServerName subdomain.domain.de </VirtualHost>

Da mod_ssl nichts mit Vhosts anfangen kann, benutzt es die SSL-Einstellungen des ersten Vhost mit der IP-Port-Kombination auch für alle weiteren entsprechenden Vhosts. Dem obigen Beispiel folgend, würde auch die Verbidung zu subdomain.domain.de verschlüsselt. Dies ist für fast alle Anwendungen ausreichend. Mit einem Wildcardzertifikat sind dann auch die meisten Browser schweigsam, was die Zertifikatsprüfung angeht. Auf Serverseite kann dies aber zu Problemen führen. Denn, bis auf den Defaultvhost, fehlt allen anderen mit passenden IP-Port-Tupeln die SSLEngine-Direktive, was den Apache glauben lässt, sie nutzten nur unverschlüsselte Verbindungen. Ohne sie kann man jedoch z.B. in PHP nicht mehr feststellen, ob die SSL-Verschlüsselung aktiviert ist. Richtig nervig wird es dann mit WebDAV für z.B. SVN, was ich in einem anderen Eintrag beschrieben habe. Versucht man die Direktive für alle weiteren Vhosts zu setzen, verweigert der Apache komplett seinen Dienst. Es gibt aber Abhilfe. Namenlos beschreibt in einem älteren Artikel einen Workaround für Vhosting mit SSL. Dabei wird die Zertifikat- und Schlüsselangabe außerhalb der Vhost-Kofiguration gemacht:

Listen *:443 NameVirtualHost *:443 SSLCertificateFile /etc/apache2/ssl/domain.de.crt SSLCertificateKeyFile /etc/apache2/ssl/domain.de.key <VirtualHost *:443>    ServerName www.domain.de    SSLEngine on </VirtualHost> <VirtualHost *:443>    ServerName subdomain.domain.de    SSLEngine on </VirtualHost>

Erstaunlicherweise ist es dann möglich in mehreren Vhosts die SSLEngine-Direktive zu nutzen. Das funktioniert so aber nur mit einem Zertifikat. Wichtig ist noch: Das mod_ssl findet nun für eine IP-Port-Kombination 2 Hostnamen und meckert im Logfile, dass man Vhosting nicht unterstütze:

[warn] Init: SSL server IP/port conflict: domain.de:443 (/etc/apache2/sites-enabled/00default:45) vs. subdomain.domain.de:443 (/etc/apache2/sites-enabled/01domain.de:13) [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!

Leider erkennt es nicht, dass das hier zweimalig verwendete Zertifikat beide Hostnamen abdeckt. Aber ich denke, damit kann man leben, so lange es trotzdem funktioniert. Zeigen nun 2 oder mehr IPs und dazugehörige Domains auf den Server, muss man einen Schritt weiter gehen. Für jede IP sollte man ein extra Zertifikat haben, damit man nicht in Schwierigkeiten gerät, wenn man eine IP abgibt bzw. hinzufügt. Mit Probieren bin ich auf folgende für mich funktionierende Konstruktion gekommen:

Listen *:443 NameVirtualHost *:443 SSLCertificateFile /etc/apache2/ssl/domain.de.crt SSLCertificateKeyFile /etc/apache2/ssl/domain.de.key <VirtualHost 10.10.10.1:443>    ServerName domain1.de    SSLEngine on    SSLCertificateFile /etc/apache2/ssl/domain1.de.crt    SSLCertificateKeyFile /etc/apache2/ssl/domain1.de.key </VirtualHost> <VirtualHost 10.10.10.1:443>    ServerName subdomain.domain1.de    SSLEngine on </VirtualHost> <VirtualHost 10.10.10.2:443>    ServerName domain2.de    SSLEngine on    SSLCertificateFile /etc/apache2/ssl/domain2.de.crt    SSLCertificateKeyFile /etc/apache2/ssl/domain2.de.key </VirtualHost> <VirtualHost 10.10.10.2:443>    ServerName subdomain.domain2.de    SSLEngine on </VirtualHost>

Tatsächlich lässt sich im Defaultvhost für jede IP der Pfad zu Zertifikat und Schlüssel überschreiben. In diesem Fall kann das oben eingestellte Zertifikat-Schlüssel-Paar sogar ein Dummy sein, da es für jede IP neu gesetzt wird. In den ungeordneten Vhosts reicht dann das schon genannte SSLEngine On. Damit ist es möglich, auf einem Server mit mehreren IPs und seperaten Vielhost- oder Wildcardzertifikaten Vhosting zu betreiben. ...wenn man über die paar Zeilen Fehlermeldung beim Serverstart hinweg sehen kann. PS: Für diesen Artikel kamen Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 mod_ssl/2.2.3 OpenSSL/0.9.8c configured zum Einsatz.

mod_security ist eine Modul für den Apachewebserver, welches als Application-Layer-Filter arbeitet. Es kann also nicht nur nach Quell- und IP gefilter werden, sondern auch nach HTTP-Headern, POST-Eingaben, PHP-Variablen in der URL und in Cookies usw. Damit kann man sich mit geeigneten Regeln gegen eine Menge Angriffe auf Webseiten wehren, wie SQL oder Remotefile-Injections, XSS und auch automatisierten Anfragen durch z.B. Malware, Crawler oder Trojaner. Der Standardregelsatz bietet einen Grundschutz, muss aber ggf. auf die eigenen Ansprüche angepasst werden. Mit dem Update von mod_security von 1.9.x auf 2.x hat sich das Konfigurationsformat etwas geändert. Wichtigste Neuerung: Die Direktive SecFilter heißt nun SecRule. Weitergehende Infos zum Upgrade findet man unter [1]. Wenn man nun Subversion über WebDAV nutzen möchte, muss man den Standardregelsatz anpassen. Im Internet [2] fand ich folgende Zeilen für eine 99_custom_rules.conf:

SecRule REQUEST_METHOD "^(PROPFIND|PROPPATCH)$" allow SecRule REQUEST_METHOD "^(REPORT|OPTIONS)$" allow SecRule REQUEST_METHOD "^(MKACTIVITY|CHECKOUT)$" allow SecRule REQUEST_METHOD "^(PUT|DELETE|MERGE)$" allow SecRule REQUEST_METHOD "^(MKCOL)$" allow

Leider gelang der Zugriff auf das SVN danach immer noch nicht. Woran das liegt, müsste man sich nochmal genau ansehen. Wahrscheinlich greift eine Regel früher, die das Ausführen weiterer Regeln verhindert. Da man mod_security Vhost-weise konfigurieren kann, reichte uns als Workaround, das Modul für den Vhost zu deaktivieren. Das sollte sicherheitstechnisch kein Problem sein, wenn das nur der WebDAV-Vhost ist. Quellen: [1] http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf [2] http://www.moltar.ca/how-to-configure-modsecurity-to-play-nice-with-subversion-22/

Seit Kernel 2.6.19 gibt es für SATA und PATA-Geräte mit libata dieselbe Treiberbasis. Die neuen Treiber sollen die alten IDE-Treiber später ablösen. Es lohnt sich auf jeden Fall diese Treiber auch für PATA-Devices zu probieren, wenn mit den alten Treibern die Performance zu wünschen übrig lässt. Um libata zu verwenden, muss man die Kerneloption Serial ATA (prod) and Parallel ATA (experimental) drivers im Zweig Device Drivers aktivieren. In diesem Zweig sollte man dann einem zum Chipsatz passenden Treiber auswählen. Generic ATA Support sollte auch nicht fehlen, sonst findet der Kernel unter Umständen gar keine Platte. Wichtig ist, dass man zusätzlich im Zweig SCSI Device Support mindestens die Optionen SCSI Disc Support und SCSI generic Support aktiviert, denn ohne diese funktioniert der Treiber nicht. Ja, auch wenn man nur PATA-Festplatten installiert hat. Den alten Treiber (ATA/ATAPI/MFM/RLL Support) kann dann aus dem Kernel entfernt werden. Schließlich muss man die Bootloaderkonfiguration und die fstab anpassen, denn mit dem neuen Treiber heißen alle Devices unabhängig vom Anschluss /dev/sdX.

Wenn man mal in der Situation ist, einen Truecryptcontainer mounten zu müssen, der ein NTFS-Dateisystem beinhaltet und der Kernel keine NTFS-Unterstützung enthält, dann brauch man folgende Zeile:

truecrypt --filesystem ntfs-3g -u /dev/sda3 /mnt/verschlüsselt/

Vorausgesetzt man hat NTFS-3G installiert. Wenn nicht, sollte man diese Implementierung der im Kernel vorziehen.

Mit der Version 2.2.6 des Apache Webservers hat sich unter Gentoo die Konfiguration etwas geändert. Dabei verschieben sich Teile der Standardvhosts. Wenn man HTTPS benutzt, sollte man drauf achten, dass nach dem mergen der Dateien noch ein Listen 443 auskommentiert ist, sonst wird's nix mit SSL-Verbindungen.

Was es nicht alles gibt. Es gibt für den Apache Webserver ein Modul namens mod_macro. Damit kann man sich häufig wiederholende Passagen in den Apache-Configfiles in Macros packen. Grade für viele Vhosts ist das ideal. Ein Beispiel:

<Macro VHostCGI $customer $domain>   <VirtualHost $domain:80>     ServerName $domain     ServerAlias www.$domain     DocumentRoot /vaw/www/$customer/docroot/$domain/     ScriptAlias /cgi-bin/ /var/www/$customer/cgi-bin/     ErrorLog /var/log/apache/$customer/logs/$domain-error.log     CustomLog /var/log/apache/$customer/logs/$domain-access.log combined     <Directory /var/www/$customer/cgi-bin/>      Options ExecCGI     </Directory>   </VirtualHost> </Macro> Use VHostCGI customer1 example.com Use VHostCGI customer15 sample.net Use VHostCGI customer122 iamanexampletoo.org

Ich glaube, ich habe am Wochenende was zu tun Quellen: http://www.coelho.net/mod_macro/ http://www.gentoo.org/news/en/gwn/20071015-newsletter.xml

Wieso die Mozillabrowser unter Linux nicht auf die im System eingestellten Standardbrowser zurückgreifen, ist mir schleierhaft. Jedenfalls passiert ohne Anpassung bei dem Klick auf einen Link gar nichts. Ich nutze Opera unter Linux, mittlerweile die 9.5 Beta. Damit Thunderbird den Browser für Links nutzt, muss man in die user_pref.js etwas hinzufügen. Seit Version 2.0 kann man diese Datei direkt im Programm bearbeiten. Dazu geht man auf Einstellungen - Erweitert - erweiterte Konfiguration. Dort muss der Parameter network.protocol-handler.app.http gesetzt werden, im einfachsten Fall auf den Pfad zum Browser, z.B. /usr/bin/opera. Das funktioniert für den Anfang schon ganz gut, jedoch öffnet der Opera jedesmal ein neues Fenster, keinen neuen Tab. Theoretisch könnte man nun durch anhängen von -newpage Opera dazu bewegen, neue Tabs zu nutzen. Nur der Mozilla ignoriert zusätzliche Parameter einfach. Abhilfe schafft ein kleines Skript als Wrapper um den Opera.

#!/bin/bash /usr/bin/opera -newpage $1

Ich habe es opera-newpage genannt und nach /usr/local/bin verfrachtet. Mit einem

chmod a+x /usr/local/bin/opera-newpage

wird es für alle Nutzer des Systems nutzbar. Zuletzt setzt man das neue Skript im Thunderbird als Protokoll-Handler für http und https. Fertig.

File System In Userspace, kurz FUSE, ist ja eine sehr nützliche Sache. Ohne weitere Kernelmodule laden zu müssen, kann man verschiedene Medien ins Dateisystem einhängen. Verbreitet sind z.B. das NTFS-3G-Modul für den performanten Zugriff auf NT File Systeme, EncFS für verschlüsselte Partionen, GMailFS zum nutzbarmachen des eigenen Gmail-Kontos als Datenhalde, u.v.m. Ich nutze auf einigen Kisten SSHFS zum Mounten entfernter Verzeichnisse über eine SSH-Verbindung. In Verbindung mit dem Automounter aus dem Kernel, kann man damit sehr einfache Backupscripte schreiben, da mit Autofs die Verbindung nur dann aufgebaut wird, wenn sie gebraucht wird. Zum Konfigurieren von Autofs muss man die autofs.master Datei bearbeiten, die meist in /etc/autofs liegt:

/path/to/mount/point /etc/autofs/auto.sshfs --ghost

--ghost sorgt dafür, dass alle Mountpointverzeichnisse schon angelegt werden, auch wenn dort noch nichts gemountet wurde. Jetzt kann man die Einstellungen für die einzelnen Verzeichnisse anlegen:

autobackup -fstype=fuse,uid=1001,gid=1005,rw,allow_other,nodev,nonempty,noatime,port=124,BatchMode=yes,IdentityFile=/home/testuser/.ssh/id_rsa sshfs#testuser@server.test.de:/home/testuser/backupdir

autobackup ist ein selbstgewählter Mountpointname. BatchMode=yes verhindert die Passwortabfrage, die der Automounter nicht alleine beantworten kann, so dass stattdessen der Publickey genutzt wird, dessen zugehöriger Privatekey mit IdentifyFile angegeben wird. Falls SSH nicht auf einem Standardport liegt, hilft der Parameter port. Für viel Kopfzerbrechen sorgt oft das Mounten im Userspace, wo auch Nichtsuperuser zugreifen dürfen. Denn es reicht nicht die UID und GID zu setzen, sondern man muss noch ein allow_other in die Optionen schreiben.

You need allow_other if you want users other than the owner to access a mounted fuse.