Konfigurationsänderungen am OVH Enterprise SP-64

Dieser Abschnitt unseres Erfahrungsberichts zum OVH Enterprise SP-64 unter Debian GNU/Linux dokumentiert die vorgenommenen Konfigurationsänderungen am dedizierten Mietserver.

Nicht alle Standardeinstellungen gefallen uns bei dem OVH-Server; in vielen Bereichen kann, muss oder sollte noch manuell nachgebessert werden.

Authentifizierung

Zu einem der ersten Handgriffe auf einem neuen Server zählt es, die Authentifizierung über PAM abzuschalten; stattdessen generiert man einen Key mit ssh-keygen und passt /etc/ssh/sshd_config wie folgt an:

PermitRootLogin         no

PasswordAuthentication  no

UsePAM                  no

Brute-Force-Angriffe scheitern dann bereits, wenn kein Key übermittelt wird.

Alternativ - oder zusätzlich - kann man auch ein Tool wie Fail2ban einsetzen. Das generiert unter bestimmten Konditionen dynamische Firewall-Regeln und sperrt auffällige IP-Adressen mehr oder minder dauerhaft aus. Das sieht im Logfile dann folgendermaßen aus:

# tail -f /var/log/fail2ban.log

2014-03-19 20:30:48,223 fail2ban.actions: WARNING [ssh] Ban 60.173.26.16

2014-03-19 20:40:48,934 fail2ban.actions: WARNING [ssh] Unban 60.173.26.16

2014-03-20 00:22:37,943 fail2ban.actions: WARNING [ssh] Ban 177.99.212.186

2014-03-20 00:32:38,616 fail2ban.actions: WARNING [ssh] Unban 177.99.212.186

2014-03-20 00:49:57,764 fail2ban.actions: WARNING [ssh] Ban 177.99.212.186

2014-03-20 00:59:58,459 fail2ban.actions: WARNING [ssh] Unban 177.99.212.186

2014-03-20 01:22:24,949 fail2ban.actions: WARNING [ssh] Ban 177.99.212.186

2014-03-20 01:32:25,619 fail2ban.actions: WARNING [ssh] Unban 177.99.212.186

2014-03-20 11:14:41,326 fail2ban.actions: WARNING [ssh] Ban 221.179.89.90

2014-03-20 11:24:41,338 fail2ban.actions: WARNING [ssh] Unban 221.179.89.90

Fakeraid und Partitionierung

Ohne weitere Anpassungen richtet der OVH-Installer ein großes Array für / ohne weitere Partitionierung; auch /boot liegt im Array, was mit neueren Kerneln tatsächlich auch funktioniert.

# df -h

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf

rootfs          1,8T    748M  1,7T    1% /

/dev/root       1,8T    748M  1,7T    1% /

devtmpfs         32G       0   32G    0% /dev

tmpfs           6,3G    264K  6,3G    1% /run

tmpfs           5,0M       0  5,0M    0% /run/lock

tmpfs            25G       0   25G    0% /dev/shm

Das ist recht flexibel, aber sicherlich nicht optimal bei einer 2-TB-Platte; vermutlich sollte man so viel Plattenplatz auch noch im Jahr 2014 ein wenig partitionieren, wenn auch die Notwendigkeit im Vergleich zu früheren SCSI-Systemen zurückgegangen sein mag.

Aktuelle Best Practise-Empfehlungen zur Partitionierung von Linux-Servern sind mir hierzu nicht bekannt. Überlegung: Auf einem SCSI-System hatte man meist einen ganzen Zoo an vergleichsweise kleinen Laufwerken. Dabei war es beispielsweise sinnvoll, die Swap-Partition auf ein separates Laufwerk auszulagern und mit drei oder vier Platten ein Level-5-RAID einzurichten. Nichts davon ist bei zwei Riesenplatten möglich; die kann man nur spiegeln. Eine Partitionierung hätte also allenfalls Vorteile bei einem Festplattencheck -oder?

# cat /proc/mdstat

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]

md2 : active raid1 sdb2[1] sda2[0]

      1922790336 blocks [2/2] [UU]

     

unused devices: <none>

Das Array ist sauber, um die unsinnigen RAID4/5/6/10-Personalities kümmern wir uns vorerst nicht.

Paketquellen und Updates

OVH hat die Paketquellen für Debian drastisch abgespeckt und teilweise auf eigene Mirror umgebogen; je nach nach Verwendungsprofil kann es notwenig sein, zusätzliche Repositories wie "non-free" freizuschalten.

Bei der Installation unseres ersten Servers aus dem 2014er-Line-up war das OVH-Image aktuell; ein erstes aptitude update bei unveränderter sources.list ergab keine Updates.

Kernel

Als laufender Kernel meldet sich der 64-bittige IPv6-Kernel 3.10.23-xxxx-std-ipv6-64. Probleme beim Updaten dieses Kernels sind nicht zu erwarten.

Lokalisierung und Internationalisierung

Standardmäßig sind im OVH-Image fünf Spracheinstellungen installiert:

 # cat /etc/locale.gen

de_DE ISO-8859-1

 de_DE.UTF-8 UTF-8

 de_DE.UTF-8@euro UTF-8

 de_DE@euro ISO-8859-15

 en_US.UTF-8 UTF-8
.

Eigentlich sollte auch die Locale de_DE.UTF-8 UTF-8 ausreichen, die man mittels dpkg-reconfigure locales als Systemstandard setzen könnte. Beläßt man es bei den OVH-Einstellungen, ergibt sich:

 # set |grep LANG

LANG=de_DE.UTF-8

cat /etc/environment ergibt eine leere Ausgabe (warum?)

# locale

LANG=de_DE.UTF-8

LANGUAGE=

LC_CTYPE="de_DE.UTF-8"

LC_NUMERIC="de_DE.UTF-8"

LC_TIME="de_DE.UTF-8"

LC_COLLATE="de_DE.UTF-8"

LC_MONETARY="de_DE.UTF-8"

LC_MESSAGES="de_DE.UTF-8"

LC_PAPER="de_DE.UTF-8"

LC_NAME="de_DE.UTF-8"

LC_ADDRESS="de_DE.UTF-8"

LC_TELEPHONE="de_DE.UTF-8"

LC_MEASUREMENT="de_DE.UTF-8"

LC_IDENTIFICATION="de_DE.UTF-8"

LC_ALL=

Locales sind noch immer ein gruseliges Thema unter Debian und Derivaten. Hier scheint es ein grundsätzliches Problem zu geben, dem man bei Gelegenheit mal nachgehen sollte (vgl. auch http://ubuntuforums.org/showthread.php?t=319397).

Zeit

Der Zeit-Dienst ntp ist nicht eingerichtet:

 # cat /etc/ntp.conf

cat: /etc/ntp.conf: Datei oder Verzeichnis nicht gefunden

Einen Server im Internet ohne saubere Zeitsynchronisation berzeitzustellen ist sicherlich keine gut Idee. ntp sollte man also schleunigst nachinstallieren:

 # aptitude install ntp

Mit dpkg-reconfigure tzdata (ehemals tzconfig kann man die Zeitzone ändern; bei Strato war sie standardmäßig auf "Europe/Berlin" gesetzt, während die Server bei OVH nach französischer Zeit laufen:

 # cat /etc/timezone

Europe/Paris

Ob man da ein - für deutsche Server eher zutreffendes - "Europe/Berlin" einträgt, oder die OVH-Einstellung belässt, ist wohl ziemlich egal; der Versatz zu GMT/UTC bleibt ja gleich.

Dienste

Eine Reihe von Diensten müssen nachinstalliert werden; je nach Anwendung können das beispielsweise Apache2, MySQL oder auch Postfix sein. Mehr dazu im Abschnitt Installation zusätzlicher Anwendungen auf dem OVH Enterprise SP-64.

Monitoring

OVH verbaut mittlerweile Western-Digital- bzw. HGST-Platten; die werden nicht so heiß wie die Produkte von Seagate, trotzdem sollte man ihre Temperatur überwachen. Dazu dient hddtemp. Rekonfiguration:

# dpkg-reconfigure hddtemp

Der nun folgende Dialog fragt folgende Werte ab (Standardwert in [eckigen Klammern]):

  • Soll hddtemp mit root-Rechten arbeiten?: [Nein] → Nein
  • Zeitraum zwischen den Überprüfungen der Festplattentemperatur: [0] → 600
  • Den Hddtemp-Dienst beim Hochfahren des Systems starten: [Nein] → Ja
  • Schnittstelle, an der auf Anfragen gewartet wird: [127.0.0.1] → 127.0.0.1
  • Port, an dem auf Anfragen gewartet wird: [7634] → 7634

Die Konfigurationsdaten finden sich in /etc/default/hddtemp.

HGST HUS724020ALA640 ist die Modellbezeichnung für die Festplatte HGST Ultrastar 7K4000, die als "Enterprise Hard Drive" deklariert wird. Aus der Spezifikation:

Performance:
  • Data Buffer (MB) 64
  • Rotational Speed (RPM) 7200
  • Interface transfer rate (MB/sec, max) 600
  • Sustained transfer rate (MB/sec, typ.) 181 (512e), 172 (512n)
  • Seek Time (read, ms, typical) 8.0
Reliability
  • Error Rate (non-recoverable, bits read) 1 in 10^15
  • MTBF (M hours) 2.0 (= 2,0 Millionen Stunden MTBF)
  • Load/Unload Cycles 600,000
  • Availability (hrs/day x days/wk) 24x7

hddtemp meldet nun: Starting disk temperature monitoring daemon: hddtemp: /dev/sda /dev/sdb. Im Syslog finden sich passende Einträge:

Mar 19 15:26:47 {host} hddtemp[27792]: /dev/sda: HGST HUS724020ALA640: 34 C

Mar 19 15:26:47 {host} hddtemp[27792]: /dev/sdb: HGST HUS724020ALA640: 35 C

Ja, etwas warm für idle, aber noch im grünen Bereich - und ein ein paar Grad kühler als die Platten aus früheren OVH-Servern. Vergleichswerte:

…von einem OVH-Server aus dem Jahr 2011 (Seagate-Platten):

# cat /var/log/syslog | grep hddtemp

Mar 19 12:13:17 ns225163 hddtemp[3218]: /dev/sda: ST32000641AS: 41 C

Mar 19 12:13:17 ns225163 hddtemp[3218]: /dev/sdb: ST32000641AS: 42 C

…von meinem lokalen Desktop-Rechner (Samsung-Platten)

Jul  5 14:51:24 localdesktop hddtemp[19762]: /dev/sda: SAMSUNG HD502HI: 32 C

Jul  5 14:51:24 localdesktop hddtemp[19762]: /dev/sdg: SAMSUNG HD502HI: 30 C

Jul  5 14:51:24 localdesktop hddtemp[19762]: /dev/sdh: SAMSUNG HD502HI: 31 C

Die smartmontools werden in /etc/default/smartmontools konfiguriert. Damit der Monitoring-Daemon smartd aktiv wird, muss in der Konfigurationsdatei start_smartd=yes gesetzt werden.

smartd wird in /etc/smartd.conf konfiguriert. Standardeinstellung ist hier:

DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

Mit dem Lm sensors-Paket lassen sich zusätzlich Temperaturen, die Lüfterdrehzahlen, Spannungen und einige weitere Informationen des Mainboards auslesen.

Beispielausgabe:

$ sensors

it8720-isa-0290

Adapter: ISA adapter

in0:         +0.85 V  (min =  +0.00 V, max =  +4.08 V)  

in1:         +1.58 V  (min =  +0.00 V, max =  +4.08 V)  

in2:         +3.34 V  (min =  +0.00 V, max =  +4.08 V)  

+5V:         +3.04 V  (min =  +0.00 V, max =  +4.08 V)  

in4:         +0.40 V  (min =  +0.00 V, max =  +4.08 V)  

in5:         +3.14 V  (min =  +0.00 V, max =  +4.08 V)  

in6:         +0.08 V  (min =  +0.00 V, max =  +4.08 V)  

5VSB:        +3.07 V  (min =  +0.00 V, max =  +4.08 V)  

Vbat:        +3.26 V

fan1:       1558 RPM  (min =   10 RPM)

fan2:          0 RPM  (min =    0 RPM)

fan3:          0 RPM  (min =    0 RPM)

fan4:       1573 RPM  (min =   10 RPM)

temp1:       +42.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor

temp2:       +25.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor

temp3:       +35.0°C  (low  = +127.0°C, high = +90.0°C)  sensor = thermistor

Wir installieren lm-sensors auf dem OVH-Server nicht - wir haben ja Server Hosting und kein Server Housing gebucht und überlassen daher die Überwachung dieser Komponenten vertrauensvell den Kollegen im OVH-Rechenzentrum.

Netmarks