Allgemeine Infos zu IPv6, die grundsätzliche Konfiguration unter Linux und die Einrichtung eines SixXS-Tunnels werden bereits ausgezeichnet im IPv6-Wiki von Ralf Krüdewagen beschrieben, daher werde ich hier nicht nochmals darauf eingehen.

Stattdessen erzähle ich über ein paar Dinge zu DHCP und DNS, die mir erst heute klar geworden sind und zeige, wie die technische Umsetzung funktioniert. Mag sein, dass ich mich hier und da nicht ganz korrekt ausdrücke… Feedback ist willkommen. :-)

Zusammengefasst sind Stand heute folgende Funktionen möglich:

• IPv6-Tunnelnutzung mit SixXS
• Router Advertisement mit radvd
• DHCP-Server für IPv4 / IPv6
• DNS-Server für IPv4 / IPv6
• dynamische DNS-Updates (DDNS) für IPv4 / IPv6

Im Doppelpack

Ich bin bisher davon ausgegangen, dass man entweder “radvd” oder einen IPv6-fähigen DHCP-Server für die dynamische Zuweisung von IP’s verwendet. Richtig ist aber, dass beide Dienste als Team arbeiten. radvd verkündet im Netz lediglich das IPv6-Prefix, also das zu verwendende Subnetz und Angaben zum Router. Clients weisen sich anhand dieser Informationen selbst eine IP-Adresse zu. Wird nur radvd eingesetzt, spricht man von Stateless Address Autoconfiguration. In diesem Szenario können sich Clients bereits im Netz bewegen und mit anderen IP-Adressen/Hosts kommunizieren.

In einem typischen (Heim-)Netzwerk reicht das jedoch nur sehr selten. Das wohl wichtigste Feature ist das Zuweisen eines DNS-Servers. Hinzu kommen Optionen wie z.B. Domain-Name, Such-Suffixe, PXE oder WPAD-Angaben. Genau hier setzt der DHCP-Server auf, der den radvd sinnvoll ergänzt.

Kurz: IP-Adressen kommen vom radvd, Zusatz-Optionen vom DHCP-Server. Man spricht hier von “Stateful Address Configuration”. (siehe auch IPv6-Autokonfiguration bei Wikipedia).

Die technische Umsetzung:

Die radvd-Konfiguration wird auf ein Minimum reduziert. Wichtig ist die Option “AdvManagedFlag on”. Die Angabe eines prefix-Bereichs entfällt.

“/etc/radvd.conf”:

interface eth0
{
        AdvSendAdvert on;
        AdvManagedFlag on;
        MinRtrAdvInterval 5;
        MaxRtrAdvInterval 10;
}

Ich nutze unter openSUSE 11.4 den ISC DHCP Server (RPM-Paket “dhcp-server”), derzeit in der Version 4.2.1. Dieser Dienst besteht aus zwei Komponenten, “dhcpd” für IPv4 und “dhcpd6″ für IPv6. Ich beschäftige mich in diesem Artikel ausschließlich mit Letzterem. Die DHCP-Konfiguration wird in zwei Dateien vorgenommen:

“/etc/sysconfig/dhcpd” (Auszug):

DHCPD6_INTERFACE="eth0"

“/etc/dhcpd6.conf” (<- auf die “6″ achten!):

authoritative;
ddns-update-style interim;
ddns-updates off;

default-lease-time 2592000;
preferred-lifetime 604800;
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
option dhcp6.info-refresh-time 21600;

allow leasequery;

log-facility local7;

subnet6 2001:xxxx:yyyy::/64 {

        range6 2001:xxxx:yyyy:: /64;

        option dhcp6.name-servers 2001:xxxx:yyyy::1;
        option dhcp6.domain-search "ipv6.site site";
}

(IP-Adressen wurden anonymisiert)

Wenn nun beide Dienste gestartet wurden und keine Firewall im Weg ist, sollten Clients bereits in der Lage sein, eine IPv6-Adresse inkl. Router- und DNS-Server-Adresse zu beziehen. In Kürze werde ich außerdem beschreiben, wie dynamische DNS-Updates mit IPv6 funktionieren.

Anwenden kann man diese Konfiguration z.B. bei Shared-Webhosting, wo unabhängige User ihren eigenen Webspace verwalten. Anstelle des unsicheren FTP kann hier dann eine sichere SFTP-Kommunikation stattfinden. Auch CVS-Repositories können auf diese Weise abgesichert werden.

Ich gebe in diesem Artikel nachfolgend eine Kurzanleitung, die die grundsätzliche chroot-Konfiguration beschreibt. Ich verwende derzeit openSUSE 11.3, grundsätzlich ist die Distribution aber natürlich nicht entscheidend.

Als Beispiel-Basisordner für die chroot-Umgebung verwenden wir “/srv/sftp“. Jeder User soll darin seinen eigenen Unterordner erhalten.

1. Erstellen einer neuen Benutzergruppe “sftponly”:

   groupadd sftponly

    

2. Erstellen zweier Benutzerkonten “user1″ und “user2″:

   useradd -s /bin/false user1
   useradd -s /bin/false user2

    

3. Setzen der Passwörter für die neuen User:

   passwd user1
   passwd user2

    

4. Hinzufügen der User zur neuen Gruppe:

   usermod user1 -A sftponly
   usermod user2 -A sftponly

    

5. Erstellen des Ordners “/srv/sftp” und der exemplarischen Unterordner “/srv/sftp/user1″ und “/srv/sftp/user2″:

   mkdir /srv/sftp
   chown root:sftponly/srv/sftp
   chmod 750 /srv/sftp
   
   mkdir /srv/sftp/user1
   chown user1: /srv/sftp/user1
   chmod 700 /srv/sftp/user1
   
   mkdir /srv/sftp/user2
   chown user2: /srv/sftp/user2
   chmod 700 /srv/sftp/user2

    

6. Anpassen der Datei “/etc/ssh/sshd_config”:

   #Subsystem      sftp    /usr/lib64/ssh/sftp-server
   Subsystem       sftp    internal-sftp
   
   Match Group sftponly
       ForceCommand internal-sftp
       ChrootDirectory /srv/sftp
       X11Forwarding no
       AllowTcpForwarding no

    

7. Neustart des SSH-Servers:

   /etc/init.d/ssh restart

    

Verbinden sich die eingerichteten User nun via SFTP (z.B. “sftp”-Kommando bei Linux oder WinSCP bei Windows) mit dem Server, sollten sie automatisch im Ordner “/srv/sftp” landen. Im eigenen Unterordner des User ist dann die Schreibberechtigung für abzulegende Inhalte vorhanden.

Wichtig ist bei dieser Einrichtung vor allem die korrekte Vergabe der Verzeichnis-Berechtigungen:

• Der Eigentümer des chroot-Ordners MUSS “root” (UID 0) sein.
• Die Gruppe des chroot-Ordners MUSS die in der “sshd_config” angegebene Gruppe (hier “sftponly”) sein.
• Die Berechtigung des chroot-Ordners MUSS 750 (User: Vollzugriff, Gruppe, lesen+ausführen, Andere: kein Zugriff) sein.

Wird eine dieser Bedingungen nicht erfüllt, verweigert der SSH-Server den Zugriff mit einer entsprechenden Fehlermeldung im Syslog:

Feb 11 11:33:02 server sshd[10053]: fatal: bad ownership or
modes for chroot directory "/srv/sftp"

Requested file to big, increase BLKSIZE

Grundsätzlich ist es so, dass das TFTP-Protokoll bei einer Standardgröße von 512 Byts pro Datenpaket nur Dateien mit einer Maximalgröße von 32 Megabytes übertragen kann. Dies liegt am 16-Bit Paketzähler (512 * 65536).

Will man nun größere Dateien übertragen, muss man die Anzahl der Bytes pro Datenpaket erhöhen. Gemeint ist hiermit der “blocksize”-Wert.

BlockSize = „zu übertragende Image-Größe in Bytes“ / 65536

Am Einfachsten ist es, das Ergebnis etwas nach oben aufzurunden. Die maximal verwendbare BlockSize ist “65504″:

65504 = 65536 - IP-Header(20) - UDP-Header(8) - TFTP-Header(4)

Die Blockgröße muss vom Client aus angegeben werden, d.h. der Client muss sie anfordern können. Gängige TFTP-Client, wie “atftp”, kennen diese Option. Die LAN-Boot-Funktion im BIOS der meisten Motherboards bietet diese Möglichkeit leider nicht.

1. Ich gehe von einer bereits erfolgten Drupal-Standard-Installation aus (siehe z.B. Quick install for beginners). Die Standard-Website ist demnach unter “http://example.com” erreichbar. Ziel dieser Anleitung ist es, eine weitere Site über die Adresse “http://www.beispiel.de” bereit zu stellen.
2. Im Drupal-Installationverzeichnis existiert ein Ordner namens “sites“. Darin wird für jede zusätzliche Site ein neuer Unterordner erstellt. Wir erstellen also den Ordner “sites/www.beispiel.de“.
3. Im Ordner “sites” existiert u.a. bereits der Ordner “default“. Aus diesem Ordner kopieren wir die Datei “settings.php” in den soeben neu erstellten Ordner “www.beispiel.de“.
4. Nun muss die Datei “settings.php” angepasst werden. Wir verwenden der Einfachheit halber die Datenbank der Drupal-Hauptinstanz mit und müssen daher nur ein separates Tabellen-Prefix eintragen, damit Drupal nicht durcheinander gerät: Im Array “$databases” (ca. Zeile 181) tragen wir ein Prefix ein, z.B.

   $databases = array (
     'default' =>
     array (
       'default' =>
       array (
         'database' => 'drupal',
         'username' => 'drupal',
         'password' => 'secret',
         'host' => 'localhost',
         'port' => '',
         'driver' => 'mysql',
         'prefix' => 'site1_',
       ),
     ),
   );

    

5. Anschließend sorgen wir noch mittels “chmod” und/oder “chown” dafür, dass der Webserver-User im Ordner “sites/www.beispiel.de” schreiben darf.
6. Die Anpassung der Drupal-Dateien ist nun fast abgeschlossen. Nun muss (falls noch nicht geschehen) dafür gesorgt werden, dass der DNS-Name “www.beispiel.de” auf den Webserver zeigt und dass der Webserver über diesen Namen auf die Drupal-Installation zeigt. Diese Basics sind nicht Teil dieser Anleitung. :-)
7. Sind diese Vorbereitungen getroffen, kann man mit einem Webbrowser “http://www.beispiel.de/install.php” aufrufen. Es erscheint dann wie bereits in der Installationanleitung (siehe 1.) gezeigt, der Einrichtungsdialog für die neue Site.
8. Nach der Durchführung ist die neue Site dann über “http://www.beispiel.de” verfügbar.

In Drupal 7 hat man außerdem die Möglichkeit, dieser zusätzlichen Site weitere Aliase zu geben. Verweist man beispielsweise mit den ServerAlias “beispiel.de” (also ohne “www“) ebenfalls auf die Drupal-Installation, kann man dafür sorgen, dass man – statt auf die default-Site – direkt bei der neuen Site (“www.beispiel.de“) landet.

Dazu kopiert man im Ordner “sites” die Datei “example.sites.php” zu “sites.php“, ebenfalls im Ordner “sites“. Für jeden zusätzlich gewünschten Alias fügt man der Datei eine neue Zeile hinzu:

$sites['beispiel.de'] = 'www.beispiel.de';
$sites['test.ganzanderedomain.de'] = 'www.beispiel.de';

Drupal findet diese Datei automatisch, wenn sie existiert und setzt die Konfiguration entsprechend um. Neben diesen explizit gesetzten Einstellungen, versucht Drupal auch automatisch, eine passende Site zur aufgerufenen URL zu finden. Dies ist ein Auszug aus der Datei “sites/example.sites.php“:

For example, for a fictitious site installed at
http://www.drupal.org/mysite/test/, the 'settings.php'
is searched in the following directories:

1. sites/www.drupal.org.mysite.test
2. sites/drupal.org.mysite.test
3. sites/org.mysite.test

4. sites/www.drupal.org.mysite
5. sites/drupal.org.mysite
6. sites/org.mysite

7. sites/www.drupal.org
8. sites/drupal.org
9. sites/org

10. sites/default

Weiterführend gibt’s hier eine Anleitung zum Updaten einer Drupal-MultiSite-Umgebung.

Zunächst ist es hierzu erforderlich, die VMDK-Dateien mit dem beim VMware-Server beigelegten Tool “vmware-vdiskmanager” zu konvertieren. Ich hatte die Software allerdings nicht mehr installiert, wollte aber auf das Tool nicht verzichten. Da ich noch das RPM-Paket “VMware-server-2.0.2-203138.x86_64.rpm” vorliegen hatte, habe ich einfach Folgendes gemacht:

1. Anlegen eines neuen Ordners (“/tmp/vmware”)
2. Öffnen des RPM-Pakets im Midnight Commander (“mc”)
3. Öffnen der enthaltenen Datei “CONTENTS.cpio”
4. Kopieren der folgenden darin enthaltenen Dateien nach “/tmp/vmware”:
   usr/bin/vmware-vdiskmanager
   usr/lib/vmware/lib/libcrypto.so.0.9.8/libcrypto.so.0.9.8
   usr/lib/vmware/lib/libssl.so.0.9.8/libssl.so.0.9.8

Danach kann man “/tmp/vmware/vmware-vdiskmanager” nutzen, als wäre der komplette Server installiert.

• Kernel 2.6.32
• Unterstützung für KMS (Kernel-based Mode-Einstellungen)
• Xen 4.0
• Unterstützung von KVM und Hyper-V
• Verbesserungen bei Audio- und Bluetooth-Unterstützung
• und einiges mehr