Erste Schritte im neuen Ubuntu 14.04 Server

Seit dieser Woche laufen bei mir die Updates auf das neue Ubuntu 14.04. Den Anfang machte gestern mein Server (nach „langer“ Vorbereitung). Nach diversen Problemen bei den letzten Updates hatte ich diesmal alle Vorbereitungen getroffen um die Ausfallzeit so „unauffallig“ wie möglich zu gestellten.

  • Wichtige Dienste wie Kerberos, Radius usw sind mittlerweile auf eigene Maschinen ausgelagert worden.
  • Der Server läuft mittlerweile auf einer „echten“ Serverhardware, inklusive Remote-Shell um im Fehlerfall eine lokale Anmeldung durchführen zu können.

Das größte Problem stellt der DNS-Server (Bind9) dar, der leider nicht auf einen meiner EdgeMax-Router zum Laufen zu bekommen ist. Fällt er längere Zeit aus, geht in meinem Heimnetzwerk nicht mehr viel.

Die Installationsroutine ist mittlerweile geübt. Manuell den aktiven Root-Raid 1 aufbrechen (Festplatte im laufenden Betrieb ausbauen). Anschließend wird die Platte direkt an eine VM weiter gereicht und das neue OS installiert. Die Installation verlief Problemlos, danach traten jedoch die ersten fehler auf. Wenn GRUB von einem RAD-Device starten soll, wirft er einen Fehler, bootet dann jedoch anstandslos weiter. Nach dem (erfolgreichen) Booten wird jedes „sudo“ von einer „memory leak“-Meldung begleitet. Diese wird durch das lib-pam-smb Paket verursacht. Nach dessen Deinstallation lief alles ohne Probleme weiter.

Einzig die Vergabe der Netzwerk-Interface Namen führte noch etwas zu Verwirrung. P4P1 hab ich so noch nie als Namen gesehen. Dem kann man aber mit einer passenden UDEV-Rule beikommen.

Der Tausch der Platten (diesmal bei ausgeschalteten Server) und der folgende „First Boot“ brauchten keine 5 Minuten. Bind und MySQL verrichtete sofort wieder ihre Dienste. Das mounten der XFS Laufwerke ging hingegen sofort auf die Bretter. Ein Blick ins „dmesg“ verrät, dass die Parameter „sunit“ und „swidth“ jetzt nicht mehr stillschweigend ignoriert werden, sondern der mount einfach abgebrochen wird. 5 Minuten später war das Storage gemountet und NFS (inkl. Kerberos) verrichtete seinen Dienst. Ab hier merkten die Endanwender (Familie) von den Arbeiten nichts mehr. Mit zwei Ausnahmen (Logitech Media server/Samba) liefen alle externen Dienste nach ca. 20 Minuten wieder.

Mehr Aufwand machte nur der neue Apache. Konfigfiles müssen immer auf „.conf“ enden, sonst werden sie ignoriert. Blöd das man das nur indirekt mitgeteilt bekommt. Nach einer Stunde rummbasteln ging mir dann ein Licht auf. Eine weitere Stunde später liefen wieder alle internen Monitoring Sites.

Richtig übel hat mir jedoch der Logitech Media Server mitgespielt. Der war am Abend gar nicht mehr zur Zusammenarbeit zu bewegen. Alle Squeezeboxen mussten manuell auf den Server von Logitech umgestellt werden. Da das Logging des Logitech Media Servers nicht sehr ergibig ist, konnte ich erste nach ein bisschen rumm probieren raus finden, dass die aktuelle Version 7.7.3 einfach nicht auf Ubnntn 14.04 lauf kann (Perl Version). Erst das Installieren des Nightly-Builds brachte Besserung,

Samba verrichtete zwar tadellos seinen dienst, jedoch waren die angeschlossenen Windows-Instanzen nicht mehr dazu zu bewegen sich an der Domäne anzumelden. Genauer gesagt konnte keine „Vertrauensstellung hergestellt werden“. Ein „rummfrickeln“ in den Untiefen der WindowsEinstellungen (regedit und policykit) brachten keine Besserung. Da ein Anmelden (Aufnehmen) in die Domäne klappt und auch ein Zugriff von Windows auf Samba hab ich nach 2 Stunden rumprobieren meine arbeiten eingestellt.

Kurzfazit: Ich hatte mehr „Ärger“ als erwartet. Gefühlt hab ich von 10.04 auf 14.04 aktualisiert. Das lag aber weniger an Ubuntu, als an den verwendeten Software-Paketen, bzw. hat 12.04 damals schon veraltete Pakete verwendet und der Sprung war jetzt merklich. Jetzt muss sich das System im Langzeittest beweisen. Da hab ich nun weniger Bedenken. Mahl sehen ob ich eine Uptime > 6 Monate hinbekomme.

AES-XTS-PLAIN – Retest

Nach einer langen Zeit (über einem Jahr) war es mal wieder Zeit zu testen, wie es um die Performance meines NAS bzw dessen Verschlüsselung steht. Leider hat sich zu damals die Plattenconfiguration geändert, so dass man eigendlich die Performance nicht vergleichen kann. Jedoch war damals wie heute nicht der RAID-IO der limitierende Faktor sondern die Cipher-Performance. Wie damals kommt ein RAID5 als Storage-Basis zum Einsatzt. Diesmal nur 1GB statt 250GB Platten. Weiterhin werkelt ein 2.5GHz Intel Core2Duo samt 4GB Ram in dem Server.

Da auf dem Storage schon ein Haufen Daten liegen entfallen leider die Vergleichstest der anderen Cipher, da ein on-the-fly umschlüsseln nicht möglich ist und ich keine Lust hab 8 stunden zu warten um ein Full-Backup einzuspielen.

Nun zu den Testergebnissen von Bonnie++:

  • Write Char: 1,31 MB/s (aktuell) statt 65,85MB/s (alt)
  • Read Char: 2,46 MB/s (aktuell) statt 29,46MB/s (alt)
  • Write Block: 128,57 MB/s (aktuell) statt 133,81MB/s (alt)
  • Rewrite: 38,68 MB/s (aktuell) statt 33,14MB/s (alt)
  • Read Block: 72,18 MB/s (aktuell) statt 57,13 MB/s (alt)

Zusammenfassung: Wie gehabt können Daten scheinbar schnell entschlüsselt als verschlüsselt werden. Was auch auffällt, dass die ersten drei Testwerte sehr viel schlechter sind als beim ersten Test. Das schiebe ich mal auf das initialisierte XFS Filesystem. Das FileSystem ist zu 55% gefüllt. Daher kommt es beim Write zu einer Lückensuche, die damals bei einem frisch aufgesetzten Filesystem nicht nötig war. Bei BlockRead und Rewrite zeigt sich dann, dass es Verbesserung in der Performance der Algorithmen gab. Leider scheint die Parallelisierung des AES-Algoritmus noch nicht wirklich weit voran geschritten zu sein. Ein CPU-Kern langweilt sich immer noch vollständig…

Ubuntu Server und der PowerButton

Aus irgendeinem Grund haben sich die Jungs bei Canonical gedacht, es sei uncool einen Server per Powerbutton am Gehäuse runter zu fahren. Ich kann mir zwar kaum einen Grund vorstellen, wofür das nützlich sein kann. IT-Personal das stolpert und durch Zufall den Button drückt, hat auch meist Kaffee in der Hand … *G*

Um das Problem zu beheben einfach:

Ubuntu als Router

Handelsübliche „DSL-Router“, oder die sogenannten eierlegenden Wollmilch-Säue, nehmen einem im Alltag schon sehr viel Arbeit ab. Leider legen die Hersteller wenig Wert auf  Transparenz oder Wartbarkeit.  Spätestens wenn man etwas mehr Flexibilität will, darf man gleich richtig Tief in die Tasche greifen oder sich selber was basteln bzw eine WRT-Firmware einsetzten.

Linux-Distributionen kommen schon seit Jahren mit einer Grundkonfigurationen die sie mit wenigen Handgriffen in einen vollwertigen Router verwandelt.

Einen DSL-Modem kann man mittels pppoeconf ansprechen.

Der Installationsmechanismus ist ein wenig krüppelig aber anschließend hat man eine Verbindung ins Internet. Standardmäßig ist sie im „persistenten“ Modus, soll heißen, nach einem 24 Stunden disconnect verbindet sich das System automatisch neu. Zusätzlich wird noch die Möglichkeit geboten scriptes aufzurufen wenn die Verbindung auf oder abgebaut wurde. Das kann man dazu nutzen einen dyndns-Dienst
zu aktualisieren. Installiert man den ddclient, klinkt er sich dort eigenständig ein.

zusätzlich zu dieser Konfiguration bedarf es noch der Verschaltung der Netzwerke. Wenn man nicht gerade ein öffentliches Netz im betrieb hat wird man NAT nutzen müssen. Dazu muss man einfach mittels iptables folgende regeln konfigurieren. Am besten sollte man das gleich in /etc/rc.local ablegen, damit das setup bei jedem reboot gesetzt wird.

Nach diesem Setup hat man erst mal wieder Internet von allen Clients, wenn man den default-dns-server und standart-gateway korrekt eingestellt hat.

Wenn man über längere zeit „ernsthaft“ einen Rechner direkt am I-Net hängen lässt, sollte man sich jedoch über iptables genauer Informieren. Das genannte Setup ist nur ein Grundsetup und lässt den Router-Rechner ziemlich „exposed“ im Netz.

serverseitige Profile

Wer mehrere Rechner sein eigen nennt und dazu noch einen Server beseitzt wird über kurz oder lang auf die wahnsinnige Idee kommen, alle userbezogenen Daten auf dem Server abzulegen, um im Falle eines Crashes alles wieder bei sammen zu haben oder schlicht um an allen Rechnern auf die gleichen Daten zuzugreifen.

Dies kann man unter Linux sehr bequem mittels mounting sehr elegant lösen. Einfach den Pfad /home/$(USERNAME) mittels pam_mount auf ein externe Quelle/Server mounten.

Unter Windows geht das nur über eine Domäne, bei der (nach wunsch) das Userprofiel serverseitig gespeichert wird.

Fährt man den Server jedoch mal runter  (kann im wartungsfall passieren) oder nutzt man das Ganze an einem Laptop und ist nicht im privaten netzt wird man folgendes festellen:

  • Linux: die GUI (Gnome/KDE/whatever) fährt hoch, aber alles sieht aus wie beim ersten Start.
  • Windows: man wird darauf hingewiesen, dass die Domäne samt serverseitgen Profielen nicht verfügbar ist. Sonst merkt man nichts.

Dies liegt an dem Umstand das Windows die Profile nach dem Anmelden downloaded und beim Abmelden wieder zurück kopiert. Steht der Server einmal nicht zur Verfügung wird mit der Kopie weitergearbeitet.

Steht ein Server bei einem Linux-Mount mittels CIFS oder NFS  nicht zur verfügung, schlegt der Mount fehl (was einem aber nur im syslog vermerkt wird) und man arbeitet nur noch lokal. Solange der Server online ist, schreibt man aber alles „direkt“ auf dem Server. Ohne nutzbare lokale kopie.

Ideal wäre eine DFS -implemntierung die einen das alles transparent abnimmt. Diese eierlegende Wollmichsau habe ich leider nicht gefunden. Deswegen habe ich folgenden Lösungsansatzt benutzt.

Die Idee von Microsoft für unterschiedliche „Systeme“ unterschiedliche Profile anzulegen, fand ich ganz vernünftig. Es gibt also Profile für ein WinXP64, WinXP32 usw… Auf einem DoppelKern mit dicker Graka läuft was anderes als auf einem Atom-Laptop. Nachteilig ist, dass das auch die „Eigenen Dateien“ betrifft, welche eigendlich Systemunabhängig sein sollten, wenn sich mal alle Entwickler drann halten würden.

Unter Linux lässt sich diese Trennung wesentlich leichter durchziehen, dank der Disziplin. Auf dem Server werden zwei Verzeichnisse angelegt und verfügbar gemacht.

  • Home-Verzeichniss: hier kommt alles rein was auf allen Rechnern zur verfügung stehen soll.
  • Profiles\$(System): hier kommt alles rein, was ein bestimmtes system betrifft.

Am Client muss man diese beiden verzeichnisse nur noch mittels mount irgendwohin mounten. „/mnt/.serverprofile“ und „/mnt/homedir“ bieten sich an . Da man den String der das System identifieziert selber wählen kann, steht einem die aufteilung frei. Sinnvoll ist eine auftreilung nach KDE/Gnome/Xfce. Es sind aber auch andere Aufteilungen möglich.

jetzt braucht es zwei scripte die das kopieren übernehmen:

  • Server->Lokale Kopie:
  • Lokale Kopie->Server:

Das erste Bash-Listing dürfte nicht verwundern. Alle Dateien aus den serververzeinissen werden in das Uservervzeichniss kopiert. „rsync -a“ sorgt nur dafür das alle gesetzten Rechte erhalten bleiben (außer ACLs was mich aber nicht stört)

Beim zweite Listing könnte nur der Ausdruck „~/.[a-Z,0-9]*“ verwirren. Der sorgt dafür das nur Files kopiert werden die mit einem Punkt beginnen. (Korrekt: es werden nur Dateien/Ordner kopiert die mit Punkt beginnen gefolgt von einem Buchstaben oder Zahl. Bei Bedarf muss das angepasst werden)

Die scripte sind nicht sonderlich intelligent und werden von mir im laufe der  Zeit auf effizents getrimmt. Man gewinnt viel zeit wenn man nur änderungen übertragt. Ich werde mal schauen was mit tar so gemacht werden kann…

Jetzt müssen diese beiden Scriptes nur noch bei an/abmeldung ausgeführt werden. Jeh nachdem welchen Desktopmanager man benutzt, ändert sich das vorgehen.

  • KDE: Unter „Systemeinstellung“ -> „Erweiterte Benutzereinstellung“ -> „Autostart“ kann man die Scriptes verlinken. Das ist unschön, da man es für jeden benutzer einzeln machen muss, für eine größere Anzahl an Rechner ist das nicht zu administrieren. Unter /usr/shutdown kann man auch scriptes ablegen. Diese Scriptes ziehen aber nur bei „Shutdown“ nicht logoff. Hier bin ich noch auf der suche nach einem entsprechend besseren Lösung.
  • Gnome: Hier bietet der GDM entsprechende Einsprungpunkte. /etc/gdm/PostSession und /etc/gdm/PreSession
  • Xcfe: hab ich (noch) nicht einsatzt. Wird aber im Laufe der nächsten Wochen geändert.

Mit den gemachten einstellung hat man sein Profiel auch wenn der Server mal nicht verfügbar ist.

PS: unter KDE wird er Kopie-Script ausgeführt wenn die Oberfläche oben ist. Es empfiehlt sich also vor dem ersten start, in der Konsole alles zu kopieren. Sonst könnte der geneigte user beim ersten start ein Schock bekommen: „Whaaa alles weg“.

Server Suspend – a long tail

Einleitung

Was braucht man sinnigerweise für einen Server den man Schlafen legen will?

  1. Eine CPU/Board – Kombo die das unterstützt…
  2. Eine Netzwerkkarte die WakeUp-on-LAN unterstützt
  3. Alle Periferiere muss Suspend unterstützen (RAID Controler, etc…)

Primär spielt es keine Rolle welchen Suspend man anstrebt. Ob „Suspend to Ram“ (Suspend) oder „Suspend to Disk“(Hibernate) unterscheidet sich im Administrativen, wie man den Server dazu bekommt, nicht. Es muss einfach ein anderer Wert (Zahl) in /proc/acpi/sleep geschrieben werden…

In meinen Versuchen hat sich Suspend to RAM aber als sinnvoller erwiesen. Das Aufwachen nach einem Suspend ging (erwartungsgemäß) schneller. Aus einem Suspend kam der Server innerhalb von unter 2 Sek wieder zum laufen (laut Kernel – Syslog, zu messen war das kaum sinnvoll…) beim Hibernate benötigte es einen kompletten Boot… das dauerte bei mir ganze 5-7 Sekunden.

Die Einsparung an Energie gegenüber einem Suspend hielt sich in grenzen:

  • Server (Boot): 75 Watt
  • Server (Working): 20 Watt
  • Server (Idle): 15 Watt
  • Server (Suspend): 3 Watt
  • Server (Hibernate): <1 Watt

Der geringe „Gewinn“ war es mir nicht wert meine Sicherheit und die Response-Zeit zu opfern… Man sollte immer bedenken, dass der Memory auf die Festplatte geschrieben wird…. und selbst wenn man den verschlüsselt, ein Angreifer den Server bewegen kann (da er keinen Strom braucht) und in seiner umgebung booten kann… Hat man hingegen ein verschlüsselte Boot-Partition (TrueCrypt etc) nutzt einem der Hibernate nicht viel, da der Server nicht „unbeobachtet“ wieder hoch kommt…

Vorbereitungen

Als erstes muss man die Netzwerkkarte testen bzw fit für WakeUp on Lan (WOL) machen. Wie das geht wird sehr gut hier beschrieben. Zu den einzelnen WOL-Modi:

  • WOL-Packet: Das eigentlich aufwecken über ein WOL/Magic-Packet ist weniger Sinnvoll und erlaubt nur einen Betrieb eines File/Domain-Servers. Beim Booten müssen alle Clientes automatisiert das WOL-Packet lostrehten und der Server darf über die dauer der Session nicht runter Fahren.
  • u/m/b/a: Das Aufwachen des Servers bei Broad/Multi/Uni-Cast ist die (imho) interessanteste Variante. Der Server wird in jedem Fall geweckt wenn er gebraucht wird. Fast alle heute verwendeten Protokolle arbeiten über IP. Dabei impliziert ist das beziehen einer Adresse (DHCP) und das Auflösen einer Adresse (ARP). Beide Protokolle beginnen den initialen Request über Broadcast. So kann man fast alles betreiben: DHCP, DNS, Webserver. Warum im Standart nochmals ein WakeUp on ARP(a) ausgewiesen wird, erschließt sich mir nicht…
  • WakeUp on physikal activity: diesen Modus hab ich bei meinen getesteten Karten nicht zum laufen bekommen. Oder nicht so wie ich das wollte. Entweder wurde der Rechner sofort nach seinem suspend wieder geweckt oder er reagierte überhaupt nicht… wer denn Sinn dahinter versteht, möge es posten…

Shutdown

Ich habe lange gesucht (ok, nicht wirklich lange, aber schon länger… ;)) bis ich eine geeignete Methode gefunden hatte, bzw zu meiner ersten Idee zurück kam. Ich machs kurz: Sleepd und andere Methoden Interupts abzufragen (oder besser deren nichterscheinen) funktionierten nicht oder nur eingeschränkt… Die interessanten Interrupts ließen sich nicht abhören und so was wie Maus und Tastatur nutzt bei einem Server ohne selbige nichts.

Deswegen verwende ich einen Script der alle 5 Minuten via Cron ausgeführt wird. Dieser ist in seiner „Urform“ hier zu finden. Der Script als solches funktioniert prima, musste nur um zwei Funktionalitäten an meine Bedürfnisse angepasst werden.

  • Wenn man den Server als zentralen FileServer für die Home-Dirs nutzt, sollte dieser tunlichst nicht runterfahren, solange ein User angemeldet ist. Das CIFS/Samba Protokoll und deren Implementierungen können das zwar ab, die Programme (KDE, OpenOffice, …) jedoch nicht. Stalled Lockfiles und andere „interessante“ Probleme sind die Folge… Aus diesem Grund habe ich den Script um eine Überprüfung erweitert, ob SMB-User angemeldet sind. Dies erfolgt über „smbstatus“.
  • Des weiteren kam es immer wieder dazu, dass der Server nicht „richtig“ in den Suspend ging, oder nicht ordentlich aufwachte.Dies häufte sich besonders bei häufigen Suspends (ich hatte Testhalber die Überprüfung auf minütlich gesetzt). Nach einer weile /var/syslog-Studium fand ich den Übeltäter. Cron kann zuschlagen, während der Kernel noch am „aufwachen“ ist und im somit abermals einen Schlafbefehl verpassen. Das bringt den Kernel ein wenig aus dem Trab. Um das zu unterbinden hab ich zwei weitere Prüfungen eingebaut. Zum einen wird ein Lockfile angelegt, das erst nach dem beenden von des „echo“-Befehls gelöscht wird, eine Semaphore. Zum zweiten muss zwischen „Aufwachen“ und erneutem Suspend mindestens 30 Minuten liegen. Dies wird mit einem Datei geprüft die mittels „touch“ aktualisiert wird, bevor das Lockfile gelöscht wird. Danach einfach das Datediff abfragen…

Die von mir verwendete Version ist hier zu finden.

Fazit

Der Server steht mir nunmehr 24/7 zur Verfügung, spart sich jedoch Strom da nicht immer an… Zudem zühlt die Uptime auch hoch, obwohl der Server am „Schlafen“ ist, nennt man das cheaten? *G*

Einziges Manko: Aus Sicht der Festplatten handelt es sich um einen „Shutdown“. Zu mindestens wird der Motor komplett stromlos geschaltet. Das Wiederanfahren sowie justieren der Köpfe reduziert die Lebensdauer der Platten entsprechend. Bei guten (verlässlichen) RAIDs sollte das aber kein Problem darstellen.

Links