Quelltext der Seite Archiv:2011/IT/Dokumentation/OVH-Grundinstallation

= Grundinstallation =

== OVH-spezifische Vorbereitungen ==

Zuerst muss der Server über das OVH-Webinterface in den Rescue-Modus gesetzt werden. Dazu meldet man sich beim OVH-Manager an, wählt oben in der Leiste den Server aus, klickt links im Menü auf "Dienstleistungen", und im Hauptteil auf "Netboot". Im folgenden Konfigurationsmenü wählt man den Netboot "rescue-pro", gibt seine E-Mail-Adresse an, unter der man die Zugangsdaten für den Rescue-Modus erhalten will und bestätigt. Anschließend klickt man im Menü links wieder auf "Dienstleistungen" und dann auf "Reboot". Als Grund gibt man "Serverneuinstallation" ein und bestätigt. Sobald der server im Rescue-Modus ist, schickt er an die angegebene E-Mail-Adresse die Zugangsdaten. Das kann bis zu 10 Minuten dauern.

== Partitionierung der Platten ==

Jetzt können wir die Festplatten "ganz normal" partitionieren: Zuerst löschen wir den Anfang der Festplatten, schreiben dann neue Master Boot Records und lesen die Partitionstabelle neu ein. Das ist leider oft genug mit einem Reboot verbunden.

 rescue:~# dd if=/dev/zero of=/dev/sda count=512 bs=1M
 rescue:~# dd if=/dev/zero of=/dev/sdb count=512 bs=1M
 rescue:~# sfdisk --force /dev/sda <<EOF
 # partition table of /dev/sda
 unit: sectors
 
 /dev/sda1 : start=       63, size=   514017, Id=fd, bootable
 /dev/sda2 : start=   514080, size=1464629985, Id=fd
 /dev/sda3 : start=        0, size=        0, Id= 0
 /dev/sda4 : start=        0, size=        0, Id= 0
 EOF
 rescue:~# sfdisk --force /dev/sdb <<EOF
 # partition table of /dev/sdb
 unit: sectors
 
 /dev/sdb1 : start=       63, size=   514017, Id=fd, bootable
 /dev/sdb2 : start=   514080, size=1464629985, Id=fd
 /dev/sdb3 : start=        0, size=        0, Id= 0
 /dev/sdb4 : start=        0, size=        0, Id= 0
 EOF

Hier wird aller Wahrscheinlichkeit nach ein Reboot fällig:

 rescue:~# reboot

Dann kurz warten, und wir haben wieder Post vom Server: Neues root-Passwort.

Nun erstellen wir das Software-Raid, die LVM-Partitionen und die Dateisysteme. Auf dem Raid für <code>/boot</code> muss wegen <code>grub</code> die Metadata-Version 0.90 sein, sonst kann der nicht auf <code>/boot</code> installiert werden.

 rescue:~# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
 rescue:~# mdadm --create /dev/md1 --metadata=1.2 --bitmap=internal --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2

Dannach initialisieren wir die Partition für LVM, indem wir ein LVM-Physical-Volume erstellen, dannach eine Volume-Group (raid) und die ersten Logical Volumes und erstellen die Dateisysteme.

 rescue:~# pvcreate /dev/md1
 rescue:~# vgcreate raid /dev/md1
 rescue:~# lvcreate --size 2G --name blackpearl_root raid
 rescue:~# lvcreate --size 1G --name blackpearl_swap raid
 rescue:~# mke2fs -j -L blackpearl_root /dev/raid/blackpearl_root
 rescue:~# mke2fs -j -L blackpearl_boot /dev/md0
 rescue:~# mkswap -L blackpearl_swap /dev/raid/blackpearl_swap

== Eigenes <code>debootstrap</code> notwendig? ==

Früher mussten Anpassungen speziell für das OVH-Rescue-System gemacht werden. Da OVH ein Sarge-Rescue-System verwendete, enthielt das natürlich keinen Lenny-fähigen <code>debootstrap</code> und wir mussten einen neuen herunterladen und installieren. Dummerweise ist das root-Filesystem ein read-only NFS-Share und wir mussten das Paket per Hand nach <code>/tmp</code> installieren, patchen und in den Pfad bringen:

 rescue:~# cd /tmp
 rescue:/tmp# wget -q http://ftp.fr.debian.org/debian/pool/main/d/debootstrap/debootstrap_1.0.20_all.deb
 rescue:/tmp# ar -x debootstrap_1.0.20_all.deb
 rescue:/tmp# tar xzf data.tar.gz
 rescue:/tmp# sed -i -e 's#DIR=/usr#DIR=/tmp/usr#' usr/sbin/debootstrap
 rescue:/tmp# export PATH=/tmp/usr/sbin:$PATH

== Installieren des Zielsystems ==

Wir hängen nun die vorbereiteten Partitionen in <code>/mnt</code> ein und starten das gepatchte <code>debootstrap</code>:

 rescue:~# mount /dev/raid/blackpearl_root /mnt/
 rescue:~# mkdir /mnt/boot
 rescue:~# mount /dev/md0 /mnt/boot/
 rescue:~# debootstrap --arch=amd64 lenny /mnt/ http://ftp.fr.debian.org/debian

Anschliessend hängen wir noch die Dateisysteme <code>/proc</code> und <code>/dev</code> um, damit wir innerhalb des Zielsystems auch auf Geräte und Prozesse zugreifen können. Anschliessend gehen wir in das Zielsystem:

 rescue:~# mount -t proc proc /mnt/proc/
 rescue:~# mount -o bind /dev/ /mnt/dev/
 rescue:~# chroot /mnt/ /bin/bash

== Konfiguration des Zielsystems ==

Ab jetzt sind wir im Zielsystem. Wir werden nun diverse Teile des Systems konfigurieren. Fangen wir mit der Zeitzone an, diese wurde bereits via debootstrap gesetzt, also müssen wir sie umsetzen und das System sich neu konfigurieren lassen:

 rescue:/# echo "Europe/Berlin" > /etc/timezone
 rescue:/# dpkg-reconfigure -f noninteractive tzdata

Setzen wir gleich auch ein Passwort für <code>root</code>

 rescue:/# passwd

Wir müssen auch noch die Partitionen eintragen. Dafür editieren wir die <code>/etc/fstab</code>:

 rescue:/# cat > /etc/fstab <<EOF
 proc /proc proc defaults 0 0
 /dev/raid/blackpearl_root / ext3 errors=remount-ro 0 1
 /dev/raid/blackpearl_swap none swap sw 0 0
 /dev/md0 /boot ext3 defaults 0 2
 EOF

Dann kümmern wir uns um das Datennetz. Wir setzen den Hostnamen und erstellen eine <code>/etc/hosts</code> und <code>/etc/network/interfaces</code>. Hier bitte auf die IP-Adressen, Gateways, Hostnamen etc aufpassen und die eigenen wählen!

 rescue:/# echo blackpearl > /etc/hostname
 rescue:/# cat > /etc/hosts <<EOF
 127.0.0.1       localhost
 94.23.220.83    blackpearl.piratenpartei.de   blackpearl
 
 # The following lines are desirable for IPv6 capable hosts
 ::1     localhost ip6-localhost ip6-loopback
 fe00::0 ip6-localnet
 ff00::0 ip6-mcastprefix
 ff02::1 ip6-allnodes
 ff02::2 ip6-allrouters
 ff02::3 ip6-allhosts
 EOF
 rescue:/# cat >> /etc/network/interfaces <<EOF
 
 # The loopback network interface
 auto lo
 iface lo inet loopback
 
 # The primary network interface
 allow-hotplug eth0
 iface eth0 inet static
         address 94.23.220.83
         netmask 255.255.255.0
         network 94.23.220.0
         broadcast 94.23.220.255
         gateway 94.23.220.254
         # dns-* options are implemented by the resolvconf package, if installed
         dns-nameservers 213.186.33.99
         dns-search piratenpartei.de
 EOF

Anschließend konfigurieren wir apt. Da die OVH-Kisten in Frankreich stehen, ziehen sie vom französischen Debian-Mirror:

 rescue:/# cat > /etc/apt/sources.list <<EOF
 deb http://ftp.fr.debian.org/debian lenny main contrib non-free
 deb http://security.debian.org lenny/updates main contrib non-free
 EOF

== Installation von System-Paketen ==

Als erstes müssen wir <code>aptitude</code> die Paketlisten updaten lassen, anschließend upgraden wir die benötigten Pakete:

 rescue:/# aptitude update
 rescue:/# aptitude safe-upgrade

Die <code>locales</code> sind noch nicht installiert, und um uns lästige Fragen zu ersparen, legen wir die Konfigurationsdateien bereits im Vorfeld an und installieren dannach:

 rescue:/# cat > /etc/locale.gen <<EOF
 en_US.UTF-8 UTF-8
 de_DE.UTF-8 UTF-8
 en_GB.UTF-8 UTF-8
 ja_JP.UTF-8 UTF-8
 ru_RU.UTF-8 UTF-8
 EOF
 rescue:/# cat > /etc/default/locale <<EOF
 LANG=de_DE.UTF-8
 LC_MESSAGES=en_US.UTF-8
 EOF
 rescue:/# aptitude install locales

Wir müssen noch die LVM-Tools installieren, dass das System nach dem Neustart auf die LVM-Partition zugreifen kann:

 rescue:/# aptitude install -y lvm2

Ausserdem muss noch <code>mdadm</code> installiert werden, um auf die Raid-Partitionen zugreifen zu können. Dummerweise will der einen Mailer installieren, und zwar <code>exim</code>. Das ist uns aber zu viel, wir bevorzugen den kleinen <code>nullmailer</code>:

 rescue:/# echo blackpearl.piratenpartei.de > /etc/mailname
 rescue:/# debconf-set-selections <<EOF
 nullmailer      shared/mailname         string  blackpearl.piratenpartei.de
 nullmailer      nullmailer/relayhost    string  mail.piratenpartei.de
 nullmailer      nullmailer/adminaddr    string
 EOF
 rescue:/# aptitude install nullmailer
 rescue:/# aptitude install mdadm

Weiter gehts mit dem Boot-Loader, ich bin ein <code>grub</code>-Fan, darum kommt der drauf:

 rescue:/# aptitude install -y grub

Achtung! Wenn <code>/dev/md0</code> nicht komplett ist, scheitert folgender Befehl:

 rescue:/# grub-install /dev/md0
 rescue:/# grub <<EOF
 root (hd0,0)
 setup (hd0)
 setup (hd1)
 quit
 EOF

Dann installierten wir den Kernel, davor konfigurieren wir aber noch die Kernel-Image-Erstellung:

 rescue:/# cat > /etc/kernel-img.conf <<EOF
 # Kernel image management overrides
 # See kernel-img.conf(5) for details
 do_symlinks = yes
 relative_links = yes
 do_bootloader = no
 do_bootfloppy = no
 do_initrd = yes
 link_in_boot = no
 postinst_hook = update-grub
 postrm_hook   = update-grub
 EOF
 rescue:/# aptitude install -y linux-image-2.6-amd64

== Installation der Administrations-Pakete ==

So, jetzt haben wir das neue System bootfertig, aber kommen noch nicht drauf. Dafür brauchen wir noch <code>openssh-server</code>, den wir anschliessend absichern:

 rescue:/# aptitude -y install openssh-server
 rescue:/# sed -i -e 's/^PermitRootLogin yes$/#&\nPermitRootLogin no/' -e 's/^UsePAM yes$/#&\nUsePAM no/' -e 's/^#PasswordAuthentication yes$/&\nPasswordAuthentication no/' /etc/ssh/sshd_config

Damit die Rechte für den Root-Account sauber getrennt werden, verwenden wir <code>sudo</code>, das wir auch gleich konfigurieren:

 rescue:/# aptitude install sudo
 rescue:/# sed -i -e 's/^root\tALL=(ALL) ALL$/&\ndyfa\tALL=(ALL) ALL\nsebi\tALL=(ALL) ALL\nchrit\tALL=(ALL) ALL\nunger\tALL=(ALL) ALL\njamasi\tALL=(ALL) ALL\nnhornung\tALL=(ALL) ALL/' /etc/sudoers

Um die Festplatten überwachen zu können, installieren wir noch <code>smartmontools</code>, die wir auch noch aktivieren müssen:

 rescue:/# aptitude install -y smartmontools
 rescue:/# sed -i -e 's/^#\(start_smartd=yes\)$/\1/' /etc/default/smartmontools

Damit die Uhrzeit auf dem Server synchron zut Atomzeit läuft, installieren wir noch einen NTP-Dämon. Aus Sicherheitsaspekten und benötigten Features benutzen wir <code>openntpd</code>:

 rescue:/# aptitude install openntpd

Es gibt noch einige kleine, aber sehr hilfreiche Tools, die wir ebenfalls noch installieren:

* <code>file</code> zeigt den Dateityp an
* <code>htop</code> ist ein komfortableres <code>top</code>
* <code>iftop</code> zeigt die momentane Auslastung der Netzwerk-Schnittstellen an
* <code>less</code> ist ein komfortablerer pager als <code>more</code>
* <code>locate</code> dient zum schnellen Auffinden von Dateinamen
* <code>lshw</code> dient zur Anzeige der installierten Hardware
* <code>lsof</code> zeigt offene Dateien an
* <code>mc</code> ist ein Norton-Commander-Klon, ein Dateimanager
* <code>netcat-openbsd</code> ist mächtiger als <code>netcat-traditional</code>, welches wir gleich deinstallieren
* <code>screen</code> benutzt man, um Sitzungen oder Befehle auszuführen, die auch weiterlaufen, wenn man die Verbindung schließt; man kann sie später wieder aufnehmen
* <code>strace</code> ist ein Tool, das die ausgeführten Systemcalls eines Programms anzeigt
* <code>sysstat</code> dient zur Anzeige von IO-Statistiken
* <code>tcpdump</code> benutzt man, um Netzwerkverkehr anzeigen zu können

 rescue:/# aptitude install -y file htop iftop less locate lshw lsof mc netcat-openbsd netcat-traditional- screen strace sysstat tcpdump

== Anlegen der User-Accounts ==

Nun müssen wir auch User-Accounts anlegen, sonst können wir uns nicht mehr einloggen, hier mal für 2 von der Leitung (auch gut für neuinstallationen):

<pre>
rescue:/# useradd -c "Sebastian Mohr" -m -s /bin/bash sebi
rescue:/# passwd sebi
rescue:/# su - sebi
sebi@rescue:~$ mkdir .ssh
sebi@rescue:~$ cat > .ssh/authorized_keys <<EOF
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAjtzKxPXNIlHzao8WeojHHCFvixMhDEFgt/4HlC+5DO+Vzned23Ymg6vKLKot+VtCR5qbshHbmvfiqFkj6qahPtZdzsMg7Git2lMd88MgvzDI8ao9f4o6NrPrP7nOTR/mk8zKzRPF79O/u2Pz2bRLiuaIn8fOCi3mqsnmUqA3zene9Hn/stURTHin+elcewQt2Q66YmhersY2nulXL6PVQsW1MhstVy02lMvbbaxdHmeG0FJY/e+ibZt1CR2l5OOZ6ZmbpfN/14Do5ebqB0lOoOSwvnSgnB78pg6cFDa/k8ugUnCMndbprBgxvGDHSBQf7dmCm4Pi2XnH6dltBnZwraewG3RsxmndqA2dGtSG7mLn9TjxjJ9W4LMOndtts9HzMFDXT1CY/Izv4PsaC8s3rAsvR6bT8lSyRDVdYkwmD/YmoX8dnpiNphmdJVO/4WiHWkL0j+BYVxGrd3dZ7yNhUSgftdvuVF99zWWoO1atZlN7xMMP2sI4Dz5NJvVLCy4nmKSYoDiKZ0s06fKzFMAoAePaBNawSNSei5I2eih/VyLq+qUvEbYrAtPcvApPaOT22MjP24LNf1+WWhlB8Zii+8cWNsW+58Ze2+Ku9/RqlmGltC9a7n2zVevkmCV4JJ8TBBW66IKuInixW6qs9sFYXiBWGi3Edwc1SYpz56Rc6U9h0pZiQJze7H4RH/PqowNifjPMEhO8Ci7xB59zzx1jQECo6UHs+2PDnPWnP+V8oiusrr9wu+ONcy6aStD sebi@sinkpad
EOF
sebi@rescue:~$ exit

rescue:/# useradd -c "Jan Simons" -m -s /bin/bash jamasi
rescue:/# passwd jamasi
rescue:/# su - jamasi
jamasi@rescue:~$ mkdir .ssh
jamasi@rescue:~$ cat > .ssh/authorized_keys <<EOF
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAx2olFDwlPhh1plmUn24IZBj86gq2SxiqKgkmHEFy3qLKr5ZxiwqbZgDXba7ThGmcTmTEPGg/MhHl2pbbKaQrPGCrKDbtdJA2+8A/l4MDWln92KANqedR9n2L1ubEzFf4LUxBRIYMcu9L8PgqtJKIXq8bVD/i99tyJlE9Tz1y6LU= jan@blood
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuQQc/FK9lI1ZGecCkvf8PPl4Y/N+NW2GB/N8XSSf+1FQmNqqbGN5XhBOmzBWnTmEIjIOQVVsz6NH/ItT90Xxa0Tgu5BbLUc8WKqxIp5VjQI4/WYhJ3t+xopMDIdGqH5mMWUQpcGmUU/8/wgemMILahbQJXIeE9dP+BLFxTZ0UCFYNiuTDWLQxYeg46Kyg6AxVdNyOo6xIZG75vFuAVwoZRw3Z1UFEfWb+i2vwels2/CWAhGSJ8iWASCjlJTJCN4rPJUPDuHUC9s8w27064xyD/IeHtRlPRh3NzDcAhlACRd6HTjyy75iqXLEeRf5CFBiGSmqXQke6RdWnRoyfZHDPw== jan@subito
EOF
jamasi@rescue:~$ exit
</pre>

== Aufräumen ==

Am Schluss räumen wir noch alles auf:

 rescue:/# exit
 rescue:~# killall ntpd
 rescue:~# killall nullmailer-send
 rescue:~# killall mdadm
 rescue:~# umount /mnt/boot/
 rescue:~# umount /mnt/dev/
 rescue:~# umount /mnt/proc/
 rescue:~# umount /mnt/

Und schalten im OVH-Manager wieder auf Festplatten-Boot, dannach das letzte Kommando:

 rescue:~# reboot

Und dann kommt die neue Kiste hoffentlich bald wieder hoch ;-)

= Installation der Dual-Server-Lösung =

Für einen professionellen Betrieb wollen wir mehrere Netze einrichten:

* Externes Netz
** Öffentliche IP-Adressen, Dienste für Benutzer
* Internes Netz
** Interner Datenaustausch, z.B. für DB-Abfragen, Mail zwischen den Kisten, usw.
** Aus Performanzgründen sollte geroutet und nicht gebriged werden
* Storage-Netz
** Schaufelt die benötigten Daten zu den Kisten; hier kümmert es sich um die Synchronisation der VM-Platten zwischen den Kisten mit DRBD.
** Hier sollte jeder DRBD-Link einzeln verschlüsselt sein.
* Admin-Netz
** Administration und Installation der Rechner. Hier müssen DHCP-Anfragen verschickt werden und die VMs sollen unabhängig von dem eingesetzten Netz direkt erreichbar sein können.
** Hier muss ein gebridgdes Netz vorliegen.

Weiterhin haben wir uns für die Virtualisierungslösung KVM entschieden. Im Test von 3 verschiedenen Versionen hat sich kvm-72 bewährt.

Die Performanztests sind hier zu finden: [[IT/Dokumentation/OVH-Grundinstallation/Performanztests]]

== <code>bridge-utils</code> oder Verbindungen zwischen den VMs ==

Damit unsere virtuellen Maschinen sinnvoll miteinander reden können, benötigen wir eine Bridge für das Admin-Netz, auf der sich dann die entsprechenden tap-Devices der Netzwerkkarten der KVM-Instanzen tummeln. Dadurch können sie bereits DHCP-Anfragen beantworten, was für den Installations-Server wichtig wird.

Wir installieren dafür <code>bridge-utils</code> und tragen dannach in der <code>/etc/network/interfaces</code> zwei zusätzliche Bridges ein und aktivieren sie. Wichtig dabei ist, das forward delay herabzusetzen, sonst können die KVM-Maschinen nicht übers Netz booten:

 sebi@blackpearl:~$ sudo aptitude install bridge-utils
 sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat >> /etc/network/interfaces'
 
 # The administration network
 auto bradmin
 iface bradmin inet manual
         bridge_ports none
         bridge_fd 0
         bridge_maxwait 0
         bridge_stp on
 
 # The internal data network
 auto brdata
 iface brdata inet manual
         bridge_ports none
         bridge_fd 0
         bridge_maxwait 0
         bridge_stp on
 EOF
 sebi@blackpearl:~$ sudo ifup bradmin
 sebi@blackpearl:~$ sudo ifup brdata

Nun sollten wir noch netfilter (Kernel-Firewall) aus Sicherheits- und Effizienzgründen auf den Bridges abschalten und die Änderungen aktivieren:

 sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat > /etc/sysctl.d/bridge-netfilter-off.conf'
 net.bridge.bridge-nf-call-ip6tables = 0
 net.bridge.bridge-nf-call-iptables = 0
 net.bridge.bridge-nf-call-arptables = 0
 EOF
 sebi@blackpearl:~$ sudo /etc/init.d/procps restart

== <code>openvpn</code> oder Verbindungen zwischen den Servern ==

Damit sie auch mit den Maschinen auf dem anderen Host im selben Subnetz sind und nach einer Migration immer noch unter der selben IP-Adresse zu erreichen sind, müssen wir diese Brücken miteinander verbinden. Dazu benutzen wir OpenVPN im p2p-Modus (da nur zwei Maschinen), um eine sichere Verbindung zum anderen Server aufbauen zu können.

Also installieren wir erstmal openvpn:

 sebi@blackpearl:~$ sudo aptitude -y install openvpn

Dannach erstellen wir ein kleines Hilfs-Script zum Hinzufügen der Interfaces zu den jeweiligen Brücken, die Konfigurationsdateien und die gemeinsamen Schlüssel:

 sebi@blackpearl:~$ cat <<'EOF' | sudo sh -c 'cat >> /etc/openvpn/brctl-wrapper.sh'
 #!/bin/sh
 # $1: "addif", "delif"
 # $2: bridge-name
 # $3: interface-name
 brctl $1 $2 $3
 ip link set up $3
 EOF
 sebi@blackpearl:~$ sudo chmod 755 /etc/openvpn/brctl-wrapper.sh
 sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat >> /etc/openvpn/bounty-blackpearl-admin.conf'
 local 94.23.220.83
 remote 94.23.198.106
 port 14139
 dev tap
 persist-tun
 persist-key
 up '/etc/openvpn/brctl-wrapper.sh addif bradmin '
 script-security 2
 user nobody
 group nogroup
 comp-lzo
 secret bounty-blackpearl-admin_static.key
 EOF
 sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat >> /etc/openvpn/bounty-blackpearl-data.conf'
 local 94.23.220.83
 remote 94.23.198.106
 port 41201
 dev tap
 persist-tun
 persist-key
 up '/etc/openvpn/brctl-wrapper.sh addif brdata '
 script-security 2
 user nobody
 group nogroup
 comp-lzo
 secret bounty-blackpearl-data_static.key
 EOF
 sebi@blackpearl:~$ sudo openvpn --genkey --secret /etc/openvpn/bounty-blackpearl-admin_static.key
 sebi@blackpearl:~$ sudo openvpn --genkey --secret /etc/openvpn/bounty-blackpearl-data_static.key

Die <code>.key</code>-Dateien müssen nun verschlüsselt auf den 2. Host übertragen werden. Für die Konfigurationsdateien auf dem 2. Host müssen nur die Parameter von "local" und "remote" vertauscht werden.

== <code>drbd-modules</code> oder Daten-Speicher-Syncronisation ==

Als erstes einmal installieren wir die DRBD-Module und die DRBD-Utilities

 sebi@blackpearl:~$ sudo aptitude -y install drbd8-modules-2.6-amd64 drbd8-utils

Dann schreiben wir noch den gemeinsam genutzten Teil der Konfigurationsdatei für DRBD.

 sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat > /etc/drbd.conf'
 global {
   usage-count no;
 }
 common {
   syncer { rate 80M; }
   startup {
     wfc-timeout 120;
     degr-wfc-timeout 60;
   }
 }
 EOF

Zum Schluss starten wir noch DRBD über die init-Scripte, damit die Module geladen werden können.

 sebi@blackpearl:~$ sudo /etc/init.d/drbd start

Beim nächsten Systemstart werden die automatisch ausgeführt.

== <code>kvm</code> oder Virtuelle Maschinen ==

Wir installieren kvm und libvirt ohne recommends, das spart uns einige Pakete, die das System sehr aufblähen würden:

 sebi@blackpearl:~$ sudo aptitude -y --without-recommends install kvm libvirt-bin

Anschließend fügen wir die Nutzer der libvirt-Gruppe hinzu, so dass sie mit dem <code>virt-manager</code> arbeiten können.

 sebi@blackpearl:~$ sudo usermod -G libvirt dyfa
 sebi@blackpearl:~$ sudo usermod -G libvirt sebi
 sebi@blackpearl:~$ sudo usermod -G libvirt chrit
 sebi@blackpearl:~$ sudo usermod -G libvirt unger
 sebi@blackpearl:~$ sudo usermod -G libvirt jamasi
 sebi@blackpearl:~$ sudo usermod -G libvirt nhornung

Wir erweitern KVM um die Möglichkeit des PXE-Netz-Boots, einmal per Boot-ROM, einmal per Boot-CD.

 sebi@blackpearl:~$ sudo wget http://rom-o-matic.net/gpxe/gpxe-0.9.9/contrib/rom-o-matic/build.php --post-data 'version=0.9.9&ofmt=ROM+binary+%28flashable%29+image+%28.rom%29&nic=virtio-net&pci_vendor_code=1af4&pci_device_code=1000&A=Get+Image' -O /usr/share/kvm/pxe-virtio.bin
 sebi@blackpearl:~$ sudo wget http://rom-o-matic.net/gpxe/gpxe-0.9.9/contrib/rom-o-matic/build.php --post-data 'version=0.9.9&ofmt=ISO+bootable+image+%28.iso%29&nic=virtio-net&pci_vendor_code=1af4&pci_device_code=1000&A=Get+Image' -O /root/gpxe-0.9.9-virtio-net.iso

=== KVM-Standard-Host mit Anmerkungen===
XML Aufspannen.

 <domain type='kvm'>

Domain benennen.

   <name>changeme</name>

Wird generiert.

   <uuid></uuid>

Benutzter Speicher; Ballooning (ändern von <code>currentMemory</code>) führte zu Abstürzen.

   <memory>524288</memory>
   <currentMemory>524288</currentMemory>

Anzahl der CPUs

   <vcpu>1</vcpu>

Wir fahren den Gast mit 64-Bit (<code>x86_64</code>) / 32-Bit (<code>i686</code>) und booten von Platte (<code>hd</code>) / CD-ROM (<code>cdrom</code>) / PXE aus dem Netzwerk (<code>network</code>).

   <os>
     <type arch='x86_64' machine='pc'>hvm</type>
     <boot dev='hd'/>
   </os>

Wir können ACPI und APIC und werden das auch benutzen!

   <features>
     <acpi/>
     <apic/>
   </features>

Unser Betriebssystem kann mit mehreren Zeitzonen gut umgehen.

   <clock offset='utc'/>

Verhalten nach Beendigung des KVM-Prozesses

   <on_poweroff>destroy</on_poweroff>
   <on_reboot>restart</on_reboot>
   <on_crash>destroy</on_crash>

Wir verwenden <code>/usr/bin/kvm</code> fürs virtualisieren.

   <devices>
     <emulator>/usr/bin/kvm</emulator>

Ein CD-Laufwerk am IDE-Bus. Können wir nach funktionierendem Netzboot weglassen.

     <disk type='file' device='cdrom'>
       <source file='/path/to/image.iso'/>
       <target dev='hda' bus='ide'/>
       <readonly/>
     </disk>

Zwei Platten, am flotten virtio-Bus. <code>changeme_disk</code> ist die System-Platte, <code>changeme_srv</code> ist das Dateisystem mit den Daten, welches unter <code>/srv</code> im Zielsystem gemountet wird. Siehe auch [[IT/Dokumentation/Namenskonventionen]]

     <disk type='block' device='disk'>
       <source dev='/dev/raid/changeme_disk'/>
       <target dev='vda' bus='virtio'/>
     </disk>
     <disk type='block' device='disk'>
       <source dev='/dev/raid/changeme_srv'/>
       <target dev='vdb' bus='virtio'/>
     </disk>

Die Netzwerk-Interfaces, wieder virtio. Netzwerk-Boot ist nur von der ersten definierten Karte möglich. Boot-ROM unter rom-o-matic.net besorgen, PCI-ID: 1af4:1000. 'bridge'-Interfaces werden gleich auf eine Brücke gelegt, 'ethernet'-Interfaces bleiben im Host sichtbar und können direkt geroutet werden. Maximale Länge des device-Namens beachten!

     <interface type='bridge'>
       <source bridge='bradmin'/>
       <target dev='changeme_adm'/>
       <model type='virtio'/>
     </interface>
     <interface type='bridge'>
       <source bridge='brdata'/>
       <target dev='changeme_int'/>
       <model type='virtio'/>
     </interface>
     <interface type='ethernet'>
       <script path='no'/>
       <target dev='changeme_ext'/>
       <model type='virtio'/>
     </interface>

Grafische Ein- und Ausgabe. <code>type='tablet'</code> nimmt er nicht an. Nur Konsole (<code><console/></code>) nimmt er auch nicht an.

     <input type='mouse' bus='ps2'/>
     <graphics type='vnc' autoport='yes' keymap='de'/>
   </devices>
 </domain>

Bitte [[IT/Dokumentation/OVH-Grundinstallation/KVM-Erstellung]] beachten!

[[Kategorie:IT-Infrastruktur]]
[[Kategorie:Dokumentation]]