Fileserver Teil 8 - neues Ram neues Glück

So das neue RAM ist da, Micron/Crutial 16GB reg. ECC Riegel (MTA36ASF2G72PZ-2G1A2). Die finden sich auch auf der HCL von Supermicro. Ich bin zuversichtlich. Diesmal konnte ich auch große Dateien kopieren und derzeit läuft einen Memtest.

Der Server steht gerade unter meinem Schreibtisch und ist schon sehr leise. Das lauteste sind die Seagate Platten.

...ein paar Stunden später...

Memtest lief auch durch ohne Probleme, diesmal ohne Failsafe-Mode.
Habe auch gerade Geekbench4 laufen lassen, hier das Ergebnis:
https://browser.geekbench.com/v4/cpu/4022145

Etwas langsamer als der Spielerechner mit i7-7700K aber schneller als der Mac Pro mit Xeon x5670. Demnächst werde ich auch mal den alten Server benchmarken.

ICjkzdC

»

Warum Ubuntu immer schlechter wird

Ich habe hier IPv6 auf Vodafone zum laufen gebracht und wollte mal schnell was in einer Lubuntu 16.04.3 VM testen (noch nicht auf dem neuen Server, da fehlt immernoch das RAM). Dabei fiel mir auf, dass folgendes Kommando funktioniert:

dig -6 heise.de a @2a02:810c:c83f:d6f0:20d:b9ff:fe45:ce7a

aber dieses nicht:

dig -6 heise.de a

Das war sehr verwunderlich, da "2a02:810c:c83f:d6f0:20d:b9ff:fe45:ce7a" mein lokaler Nameserver ist und dieser Ubuntu auch bekannt ist.

Das Kommando versucht den A Record für heise.de zu resolven. "-6" gibt an, dass es dazu nur IPv6 benutzen soll. "@IP" gibt an, dass eben dieser Nameserver gefragt werden soll.

Dass der Nameserver dem System wirklich bekannt ist, weiß ich durch folgendes Kommando:

nmcli -t device show enp0s3 | grep IP6.DNS

Die Ausgabe davon ist:

IP6.DNS[1]:2a02:810c:c83f:d6f0:20d:b9ff:fe45:ce7a

Das passt also.

Warum funktioniert es dann nicht?

Ganz einfach, die Spezialexperten von Ubuntu konnten natürlich nicht einfach die ermittelten Nameserver nach /etc/resolv.conf schreiben, sondern mussten das abstrahieren. In /etc/resolv.conf steht jetzt nur noch "nameserver 127.0.1.1" was eine Localhost Addresse ist. Und auf Localhost lauscht dieser Prozess hier:

cbubel@lubuntu-vm:~$ sudo netstat -tulpn | grep 53
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      919/dnsmasq     
udp        0      0 127.0.1.1:53            0.0.0.0:*                           919/dnsmasq

Und damit hätten wir auch schon das Problem gefunden.

Natürlich kann dig nicht IPv6 benutzen, wenn der verdammte dnsmasq nur auf dem IPv4 Localhost lauscht. Damit das funktioniert müsste noch ein ::1/128 in die resolv.conf und dnsmasq müsste natürlich auch darauf hören. Einfach mal ne Config ändern reicht hier nicht, da muss man erstmal die Config anlegen, da das alles hard gecoded ist. Wers nicht glaubt, möge mal die Stelle suchen, an der dnsmasq gesagt wird, dass er auf localhost hören soll.

Ob das Problem auch in 17.04 besteht, weiß ich nicht. Aber schlimm genug, dass es keinem im LTS aufgefallen ist.

Update: Ja auch 17.04 ist kaputt, etwas anders zwar, aber kaputt. Dnsmasq scheint durch systemd ersetzt worden zu sein, aber da bin ich mir nicht absolut sicher.

»

Fileserver Teil 7 - Instabil

Habe nun einige VMs installiert und angefangen alles ausgiebiger zu testen. Als ich größere Files vom alten Fileserver in die neue FreeNAS VM kopiert habe blieb das ganze System nach ein paar GB stehen. Auch beim Import einer großen VM ist mir der Server abgesürzt. Zum Ram hatte ich zwar vertrauen, da der Memtest diesmal tatsächlich lief, aber das könnte immernoch die Ursache der Probleme sein.

Ich muss mal schauen, ob ich anderes RAM zum testen besorgen kann, am besten welches, das auch in der Kompatibilitätsliste von Supermicro auftaucht.

»

vim.fault.filenotfound

Falls ihr mal eine VM, die ihr aus einem anderen ESXi exportiert habt, importieren wollt, könnte euch die Fehlermeldung aus dem Titel begegnen.

Das Problem hierbei ist meistens ein der VM zugeordnetes ISO File, das nicht mit exportiert wird. Wenn man ein OVF File hat, kann man einfach die Sektion mit dem CD-Rom Laufwerk entfernen und der Import wird funktionieren.

Bei einem OVA File wird das etwas komplizierter. Und zwar muss man dieses File erstmal entpacken. 7-Zip ist da hilfreich. Danach sollte man ein OVF und ein VMDK File erhalten. Das OVF kann nun wie zuvor beschrieben editiert werden.

»

Neuer Fileserver Teil 6 - pulsierende Lüfter

Das neue Mainboard ist da und läuft deutlich stabiler. ESXi ist installiert und ich fange an die virtuellen Maschinen einzurichten. Den SAS Controller an FreeNAS durchzureichen war kein Problem. Das neue Webinterface ist an manchen Stellen etwas merkwürdig, aber ich will mich nicht beschweren.

Etwas genervt haben die Lüfter, die laufen nur mit 300rpm und das Mainboard dachte die seien wohl kaputt und hat dann immer wieder auf 1500rpm hochgeregelt. Das lag daran, dass der minimal Wert im IPMI per Default zu niedrig gesetzt ist. Im Webinterface kann man die Werte nicht setzen, aber dafür gibt es ipmiutil, das auch in Homebrew unter MacOS oder jeder guten Linux Distribution enthalten ist. Alternativ kann man auch ipmitool nehmen.

So liest man die Lüfter aus:

ipmiutil sensor -N 192.168.0.159 -U ADMIN -P ADMIN -c -g fan
ipmiutil ver 2.95
isensor: version 2.95
Connecting to node 192.168.0.159 192.168.0.159
-- BMC version 3.50, IPMI version 2.0
 ID  | SDRType | Type            |SNum| Name             |Status| Reading
03f1 | Full    | Fan             | 41 | FAN1             | OK   | 300.00 RPM
0434 | Full    | Fan             | 42 | FAN2             | Absent | 0.00 na
0477 | Full    | Fan             | 43 | FAN3             | OK   | 300.00 RPM
04ba | Full    | Fan             | 44 | FAN4             | OK   | 300.00 RPM
04fd | Full    | Fan             | 45 | FAN5             | OK   | 300.00 RPM
0540 | Full    | Fan             | 47 | FANA             | Absent | 0.00 na
ipmiutil sensor, completed successfully

Und so setzt man die neuen Werte:

ipmiutil sensor -N 192.168.0.159 -U ADMIN -P ADMIN -n 47 -u 250:250:250:25400:25400:25500

Die 47 ist die SNum des Lüfters. Das macht man für alle und dann ist Ruhe. Evtl. muss man noch einmal den IPMI Controller resetten.

»