HowTo: multiple Apache2 vhosts mit unterschiedlichen SSL-Zertifikaten

Die Aufgabe: in Apache bei verschiedenen vhosts verschiedene SSL-Zertifikate fuer die Verschluesselung definieren.
Das Problem: mit mod_ssl laesst sich das ganze nicht so einfach realisieren.
Die Ursache: vhosts basieren auf Basis von HTTP-Headers, SSL liegt ein Layer darunter. Die Verbindung wird gesichert bevor HTTP gesprochen wird. Der Server kann bei Verbindungsaufbau nicht wissen welchen vhost er danach bedienen soll, deswegen kann er das richtiger Zertifikat nicht auswaehlen.
Die Loesung: mod_gnutls
HowTo: das ganze unter Debian Lenny

Ich gehe an dieser Stelle davon aus, dass man bereits SSL-Zertifikate generiert hat (blubs).

Als naechstes ist es nun wichtig das Modul zu installieren, anzupassen und zu aktivieren:

aptitude install libapache2-mod-gnutls

Danach die /etc/apache2/mods-available/gnutls.conf anpassen:

<IfModule mod_gnutls.c>
  GnuTLSCache dbm /var/cache/apache2/gnutls_cache
 
  AddType application/x-x509-ca-cert .crt
  AddType application/x-pkcs7-crl    .crl
 
  GnuTLSCacheTimeout 300
  NameVirtualHost *:443
</IfModule>

und das Modul aktivieren:

a2enmod gnutls

Nun noch die Zeile:

Listen 443

zu der /etc/apache2/ports.conf hinzufuegen und dabei darauf achten, dass die Zeile vor der „Listen 80“ steht, da es sonst in der /var/log/apache2/error.log zu den folgenden Zeilen kommen kann:

[Sun Dec 05 14:37:06 2010] [error] [client ::1] GnuTLS: Handshake Failed (-8) 'A record packet with illegal version was received.'

Nun koennen die vhosts entsprechend eingerichtet werden. Hier ein generisches Beispiel fuer einen vhost:

<VirtualHost *:443>
    ServerAdmin webmaster@example.net
    ServerName www.example.net
    ServerAlias example.net
    DocumentRoot /var/www/example.net/
 
    <Directory /var/www/example.net/>
        Options +Indexes
    </Directory>
 
    GnuTLSEnable on
    GnuTLSCertificateFile /etc/ssl/myCA/private/www.example.net-key-cert.pem
    GnuTLSKeyFile /etc/ssl/myCA/private/www.example.net-key-cert.pem
    GnuTLSPriorities SECURE:!MD5
 
    CustomLog /var/log/apache2/example.net-access.log combined
</VirtualHost>

Nach einem Neustart von Apache2 kann nun per https auf den gewuenschten vhost zugegriffen werden, viel Spass beim Einrichten des zweiten und freien wenns klappt!

bash [if -e *.TIF -> [: too many arguments

Wenn man in bash in einer if [ -e Schleife nach einem Wildcardeintrag sucht, bekommt man immer die Fehlermeldung [: too many arguments. Hintergrund ist, dass -e immer nur ein Argument verarbeiten kann und nicht mit Wildcards umgehen kann. Der Workaround dafuer ist:

files=$(ls *.TIF 2> /dev/null | wc -l)
if [ "$files" != "0" ] ; then
  for i in *.TIF; do
    mv $i ${i/\.tif/\.TIF};
  done
fi

Gefunden habe ich die Loesung bei MDLog:/sysadmin

Howto: Der eigene Weave Minimal Server / Firefox Sync

Vor 1 1/2 Jahren habe ich den Artikel „Firefox Lesezeichen ueberall – Selfmade!“ geschrieben, wo ich beschrieben habe, wie man mit dem Firefoxplugin Foxmarks bzw. spaeter Xmarks und einem Apache Webserver mit mod_dav enabled seine Lesezeichen auf den eigenen Server synct und so die Kontrolle ueber die Daten behaelt.

Mozilla hat vor einiger Zeit das Weave Projekt gegruendet, dass es spaeter in Sync umbenannt hat. Fuer Firefox 3.5 aufwaerts gibts ein Firefoxplugin, ab der Version 4.0 wird die Funktionalitaet direkt in Firefox enthalten sein. Das Plugin kann Lesezeichen, Passwoerter, Einstellungen, Chronik und offene Tabs an einen Server syncen und so an verschiedenen Standorten verfuegbar machen. Grund genug sich das anzugucken und grund  fuer mich, mich von Xmarks zu verabschieden.

Voraussetzung fuer eine Installation ist, dass man einen eigenen Apacheserver irgendwo laufen hat. Wenn ich das richtig ueberblicke benoetigt man die Module

aptitude install libapache2-mod-php5 php5-sqlite

Anschliessend das weave_minimal.tgz aus diesem Blogeintrag vorletzter Absatz (Mirror) herunterladen und in ein Verzeichnis im DocumentRoot entpacken. Ich persoenlich habe mir eine eigene Subdomain gemacht und in Apache einfach fix einen neuen vhost eingerichtet. Wichtig ist nur, dass man anschliessend in der Apacheconfig einen Alias setzt:

Alias /weave /PATH/TO/DOCUMENTROOT//weave/index.php

Wobei der Pfad entsprechend der lokalen gegebenheiten anzupassen ist. Nun einmal den Apache neustarten damit die Aenderungen uebernommen werden. Als naechstes geht man mit seinem Webbrowser auf die URL: http://MYDOMAIN.TLD/weave/1.0/MYUSERNAME/info/collection wobei MYDOMAIN.TLD natuerlich mit dem eigenen Domainnamen und MYUSERNAME ein Benutzername ist. Bei der Aufforderung sich einzuloggen gibt man einfach eirgendwas ein. Die Authentifizierung schlaegt fehl aber die Datenbank wird erzeugt. Danach geht man auf den Server in das Verzeichnis in dem der entpackte Tarball liegt und legt einen Benutzer an mit dem Befehl:

php5 create_user MYUSERNAME

wobei MYUSERNAME wieder durch den gewuenschten Benutzernamen zu ersetzen ist. Weiter waehlt man sein Passwort und bestaetigt dieses. Nun ist man schon fast am Ziel. Falls noch nicht geschehen das Firefox Sync Plugin installieren und den Browser neustarten.

Wenn man nun Firefox Sync ueber den Assistenten einrichtet waehlt man als erstes aus „I Have a Firefox-Sync Account“. In dem zweiten Fenster sagt man „Eigenen Server verwenden“ und gibt die Server URL mit dem anschliessenden /weave/ ein, z.B. http://MYDOMAIN.TLD/weave/ . Der Benutzername und das Passwort sind die, die man bei dem create_user angelegt hat. Nachdem man diesen Punkt mit „Weiter“ bestaetigt hat, wird man aufgefordert seinen Sync Key einzugeben. Zuerst war ich etwas irritiert, aber es ist _nicht_ das Passwort sondern eine random Zeichenkette die die eigenen Daten auf dem Server dann verschluesselt. Ich habe hier einfach ein alternatives Passwort genommen. Mit „Weiter“ und „Fertigstellen“ Bestaetigen und voila…

KVM, interne Maschine, RDP Zugriff von extern

Wenn man mit KVM eine Maschine virtualisiert hat, und diese dann in ein eigenes internes Netz haengt, z.B. 192.168.X.X, dann ist es zwar normalerweise moeglich via NAT ins Internet zu gehen, aber wie komme ich von extern auf diese Maschine. Konkrete Fragestellung bei mir war: Wie komme ich von extern per Remotedesktop auf die Maschine?

  • per SSH mit X-Forwarding auf der physikalischen einloggen und dann mit rdesktop, Beispiel:
 rdesktop -k de -u MYUSERNAME -g 1280x1024 192.168.2.2
  • mit netten iptables Regeln

Als erstes generell erlauben, dass Traffic auch an die internen Maschinen weitergeleitet werden darf:

iptables -I FORWARD -d 192.168.2.0/24 -j ACCEPT

Danach den entsprechenden Dienst einrichten, in diesem Fall RDP:

iptables -t nat -A PREROUTING -p tcp -d 1.2.3.4 --dport 3389 -j DNAT --to-destination 192.168.2.2:3389

Die iptables Regeln habe ich bereits vor einiger Zeit von meinen Cousin Emil Wagner per Mail bekommen. Danke dafuer!