Karmic Koala auf der Seashell

Hier war es eine weile sehr ruhig, dass hatte zwei Gründe. Erstens hatte ich Urlaub (die letzte Woche) zum anderen hat sich gezeigt, dass beim Netbook-Remix von Jaunty (9.04) auf Karmic (9.10) sehr viel passieren würde. Es hätte wenig Sinn gemacht, den Jaunty auf der Seashell bis zum Brechen zu optimieren, um ihn anschließend durch den Karmic zu ersetzten.

Darum dreht sich die Frage ja im Grunde. Lohnt es sich, eine funktionierende  Jaunty-Netbook-Installation durch eine Karmic zu ersetzten. Kurz und knapp: Ja. Sämtliche Funktionen der Seashell funktionieren Out-of-the-Box. Hier nochmal die Auflistung:

  • WLAN und LAN: Beide Interfaces werden erkannt und können sofort genutzt werden.
  • HotKeys/LEDS: Fast alle wichtigen HotKeys (WLAN ausschalten, usw) funktionieren tadelos. Ausnahmen Touchpad-deaktiviern
  • Suspend to Disk/Ram: laufen jetzt besser/robuster.

Diese Verbesserungen sind zu großen Teilen auf den neuen Kernel (2.6.31) zurückzuführen. Hier war der Jaunty einfach „benachteiligt“. Beim damaligen Release hat sich in zu vielen Treiberteilen, die die Netbooks betreffen, zu viel getan. Besonders hart hat es den Treiber der Intel-Grafikkarten getroffen. Dieser war im alten Kernel einfach „gebrochen“. Die Performance ist zwar immer noch hinter den Windows-Treibern aber schon erheblich besser als unter Jaunty.

Das Design und die Bedienung wurden im Detail verbessert. Es wirkt alles aufgeräumter und dezenter.

3Ware installation

Das erste was nach der Installation der Hardware auffällt ist, dass der Boot-Vorgang extrem viel länger dauert. Beim ersten Start hat es locker 30 Sek gebraucht, bis das BIOS des RAID-Controllers durch war und mein Server endlich ins Linux gebootet hat. In den folgenden Boots wird das nicht viel besser.

Die Installation des 9650 ist unter Ubuntu 9.04 denkbar einfach. Auch alle anderen Distributionen werden (wenn auch nicht offiziell) ohne Probleme unterstützt. Einzig die Kernelversion 2.6.14  oder die entsprechenden Treibermodule werden vorausgesetzt. 3Ware bietet drei Möglichkeiten den RAID-Controller zu administrieren. BIOS, CLI und die 3DM -genannte webbasierte RemoteManagement – Konsole. Die Installation erfolgt problemlos, einzig eine „echte“ JavaRuntime und das Programm „bc“ werden benötigt. Beide sind aber im offiziellen Repository enthalten und man gefährdet seinen Server nicht mit Fremdquellen. Ein „kleines“ „aptitude install“ vorneweg und die Installation kann beginnen.

Hat man eine grafische Oberfläche kann man das Setup einfach so starten, steht einem nur ein Kommandozeilen-Terminal zur Verfügung muss man noch den Parameter „-console“ anhängen. Anschließend führt ein Assistent durch die Installation und nach „wenigen“ Minuten steht einem der RAID-Controller in vollen Funktionsumfang zur Verfügung.

sudo aptitute install bc
tar xfvz 3DM2_CLI-Linux-x86_64-9.5.2.tgz
sudo ./setupLinux_x64.bin -consol

Jetzt wird man durch den Assistenten geführt. Das dauert wie gesagt ein paar Minuten. Anschließend ist alles nach Wunsch installiert und konfiguriert. Will man nachträglich etwas ändern so findet man das Config-File unter /etc/3dm2/

Man muss nur noch dafür sorgen, dass die Remote – Konsole auch automatisch gestartet wird. Leider ist der mitgelieferte Startscript, der auch brav unter /etc/init.d abgelegt wird, nicht ganz Standardkonform. Es fehlen die Angaben zu Required-Start und Required-Stop. Ergo schnell die Datei mit einem Editor der Wahl geöffnet und den Header angepasst.

#!/bin/sh
#
# 3dm2:         Starts the 3ware daemon
#
# Author:       Michael Benz

#
# Default-Start: 3 4 5
# Default-Stop: S 0 1 6
# Required-Start:  $network $remote_fs $syslog
# Required-Stop:   $network $remote_fs $syslog
# Provides: tdm2
# Short-Description: 3ware Daemon
# Description: Start the 3dm2 application which logs the current state
#              of the 3ware DiskSwitch controller card, and then polls
#              for state changes.
#
# config: /etc/3dm2/3dm2.conf

Zeile 9 und 10 sind von mir eingefügt. Anschließend folgenden Befehl ausführen.

sudo update-rc.d tdm2 defaults

Nun startet die Remote-Konsole automatisch beim Systemstart mit.
Für den ersten Test startet man entweder neu oder ruft den Script manuell auf.

/etc/init.d/tdm2 start

Wenn man die Konsole aufrufen will muss man beachten, dass nur HTTPS anfragen beantwortet werden. Nach dem Login (Standartpassword: 3ware) sollte man sofort die Passwörter ändern und ein BIOS-Update einspielen. letzteres bedarf leider eines Neustarts.

Anschließend kann man seine RAID-Arrays konfigurieren.

Seashell RFKillswitch unter Ubuntu

Damit man auf Knopfdruck das WLan abschalten kann muss man das modul rfkill-input laden lassen. In der Datei „/etc/modules“ das modul angeben.

Man kann auch mit dem folgendem Befehl, das modul temporär laden und testen.

sudo modprobe rfkill-input

will man etwas mehr komfort braucht man eines der „vielen“ EeePC-Applets. Ein gutes wird über das statux.org-Repository. Danach kann man sich das EeePC-Tray installieren. Danach bekommt man eine Visualisierung ob der Tastendruck „gezogen“ hat, da der WPA-Supplicant ein wenig verzögert reagiert.

Ein Rückblick: eine Woche Ubuntu-Netbook-Remix

Ich hab jetzt seit einer Woche ein Netbook im Einsatz. Es ist also Zeit für einen kleinen Rückblick. Erstes Fazit: arbeiten auf der Seashell macht Spaß. Besonders da es momentan noch wirklich Arbeit ist. Es braucht eine weile bis man sich Ubuntu so angepasst hat, das es so läuft wie man es wirklich will. Besonders die Optimierung auf „Sparsamkeit“ ist noch (Konsolen) Arbeit. Daneben lassen sich hervorragend Texte schreiben, Mails lesen und im Internet surfen.

Neben der Tastatur und dem Display überzeugt vor allem der Netbook-Remix selber. Diesen muss man in zwei Bereiche teilen: Kernel/Unterbau und GUI.
Der Kernel im Netbook-Remix samt die ihm umgebene Konfiguration aus Daemons ist nicht „optimal“. Was aber nicht weiter verwundert, es zwar ein optimierter aber immer noch „allgemeingültigen“ Kernel eingesetzt. Auch der Xserver läd noch alle Module/Treiber um eine Nvidia, ATI oder sonst irgendeine Karte zu befeuern. Dies ist dem Umstand geschuldet, das es sich beim Netbook Remix um eine „große“ Distribution handelt, keine optimierte Spartenvariante. Das ließ sich aber schnell ändern. Mit „wenigen“ Handgriffen war der „allgemeine“ Kernel gegen einen EeePC-Kernel ausgetauscht, der ist nicht nur kleiner sondern spart auch Strom. Auch sonst ließ sich der Unterbau mittels aptitude und Config-Scriptes sehr komfortabel an die Bedürfnisse anpassen. Momentan hab ich das Gefühl eine Betriebssystem zu haben, was sich „fast“ perfekt an die vorhanden Hardware angepasst hat. Noch ein zwei Ecken weg schleifen (Softkey zum laufen bringen) und ich bin wunschlos glücklich.

Bei der Oberfläche überlebte ich einige Überraschungen. Ich war mit der Einstellung „ran gegangen“ Ubuntu zu installieren (da es noch kein Xubuntu Netbook-Remix gibt) und das enthaltene Gnome schnellstmögliche runter zuschmeißen und gegen Xfce zu tauschen. Da dies ja ressourcensparender ist und mehr „KDE-like“. „Gnome ist halt hässlich“. Naja es kam alles ein wenig anders. Beim Zwangsboot von Windows merkte ich das erste mal, dass eine Standard Desktopoberfläche auf einen 10“-Display alles andere als optimal ist. Die Fensterleiste zu breit, dass „Windowing“ zu platz verschwendend. Von 600 Pixeln (vertikal) gehen alleine schon knapp 100 Pixel für „Startleiste“ und „Fensterrahmen“ drauf. Nach der Installation von Ubuntu war ich erstmal schockiert von der Farbgebung. Ich mochte dieses grau in braun noch nie… Durch das Fehlen der Netzwerkfunktionalität war ich gezwungen erstmal mit dieser Oberfläche zu arbeiten, wenn auch nur in der Konsole. Nach den ersten Stunden (2-3) hatte ich Netzwerk und machte meine Drohung war. Einmal den Befehl ausgeführt, der mir GNOME runter schmeißt und XFCE draufhaut. Ohne Seil und doppelten Boden. Weg mit dem braunen Brei, her mit der … Desktopoberfläche… Nachdem ich die erste Stunde mit XFCE gearbeitet hatte (Einrichten, gestalten und auf Energiesparen trimmen) stellte ich fest, dass sich mein erster Eindruck bestätigte. Irgendwie fühlte sich das alles unrund an. Das ständige überlagern von Fenstern, das schieben und anordnen war ein Krampf. Ich verwarf das alles und installierte Ubuntu nochmal neu. Nachdem ich mich mit den Braun angefreundet hatte (mittlerweile empfinde ich es sogar als angenehm) stellten sich die Vorteile des Oberflächendesign noch stärker heraus. Bis auf ein paar nicht angepasste Dialoge (oder die Möglichkeit zu große Dialoge zu scrollen) wirkt alles aus einem Guss und aufeinander angepasst. Sogar mein Lieblingsbrowser lässt sich mit Skin wunderbar in die Oberfläche integrieren. Als Zentrale Anlaufstelle habe ich den Gnome-Netbook-Launcher wirklich ins Herz geschlossen. Anfangs wirkte das Ding überflüssig wie ein Kropf, mittlerweile findee ich das „OnScreen“Menüunervig.. Bei der kleinen Auflösung hat man oft Überblendungen oder „aufploppen“ an stellen wo man das Menü nicht erwartet. Wenn ich raus gefunden hab wie ich den Launcher auf Tastendruck einblende verschwindet das Menü endgültig…

Seashell – Kernel optimieren und LAN

Adam McDaniel bietet einen speziell an den EeePC (oder andere Netbooks) angepassten Kernel für Ubuntu an. Der ist zwar aktuell hinter dem Ubuntu-Kernel hinterher (2.6.28-13 gegen 2.6.28-12) dafür ist er aber um einiges schlanker und „schneller“. Wobei der Leistungszuwachs unter den „alten“ EeePC wohl größer ist. Ich betreibe meine SeaShell dennoch mit dem neuen Kernel, da der Kernel ungefähr 0.5 bis 1 Watt weniger Strom verbraucht (laut Powertop) und damit gut 30 min längere Akkulaufzeit bietet.

Um den Kernel zu installieren muss man erstmal die neuen quellen über die /etc/apt/source.list einbinden.

deb http://www.array.org/ubuntu jaunty main
deb-src http://www.array.org/ubuntu jaunty main

Anschließend den zugeörigen PublicKey herunterladen und ein Quellenupdate durchführen.

wget http://www.array.org/ubuntu/array-apt-key.asc
sudo apt-key add array-apt-key.asc
sudo apt-get update

Ist das erledigt, installiert man sich den optimierten Kernel

sudo apt-get install linux-netbook-eeepc
sudo apt-get install linux-backports-modules-jaunty-netbook-eeepc
sudo apt-get install linux-headers-2.6.28-12-netbook-eeepc

Die letzte Zeile kann man sich sparen, wenn man „nur“ den gleichen zustand herstellen will wie bei der „normalen“ Ubuntu installation. WIll man hingegen noch den LAN Treiber installieren braucht man die Header Files.

Den Treiber für die Gigabit-Ethernet-Karte gibt es bei Atheros oder direkt bei mir. Einmal entpackt beginnt der berühmte aber leicht abgewandelte Linux-Dreisatzt.

make
sudo make install
sudo insmod atl1e.ko

Danach funktionierts auch mit der Lan-Karte.

1008HA – Sound zu leise

Nach der Standartinstallation des NetBook-Remix auf der SeaShell wird man schnell feststellen, dass der Sound extrem leise daher kommt, obwohl unter windows der „Sound“ während der Einrichtung nerfig laut war, das muss man leider über sich ergehen lassen.

Leider lässt sich dem problem mit GUI-Boardmitteln nicht wirklich bei kommen. Da man aber die Console bei der Seashell durchaus gewöhnt ist/sein muss reicht ein aufruf des Alsamixers in der Console…

alsamixer

dort den zweiten Kanal hochdrehen (Anschlag) und anschließend die Einstellungen speichern

sudo alsactl store

und schon klappt es mit dem Sound 🙂

WLAN unter Ubuntu NetBook Remix auf der SeaShell zum laufen bringen

Unter der aktuellen Version des NetBook-Remixes ist die Seashell nicht sinnvol zum Einsatzt zu bringen, weder LAN noch WLan sind nutzbar. Um diesen Umstand zu lösen bedarf es eines Updates. Die kann man über folgenden Befehl bewerkstelligen.

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install linux-backports-modules-jaunty

wohl dem der eine externe USB LAN/WLAN-Karte hat, wie zb bei „where’s the [any] key“.

Leider dürften die meisten käufer wie ich erstmal etwas verduzt drein schauen. Das die WLAN Karte nicht nutzbar war, damit rechnet man, das eine einfache LAN-Karte nicht nutzbar ist, das hat man unter Linux schon lange nicht mehr erlebt.

Nach einer kleinen Suche im Debian-Handbuch war die Lösung aber „schnell“ parat. Zu finden hier: Debian Handbuch

Hier der Ablauf:

Als erstes ein Medium der Wahl, am besten USB-Stick oder SD-Karte, formatieren und mit der folgenden Ordnerstruktur vorbereiten (ich hab das Medium dabei unter /media/Disk eingebunden):

/media/Disk/
  archives/
     partial/
  lists/
     partial/

danach inter /media/Disk/ eine Datei mit dem namen apt.conf anlegen (kann auch anders heißen) und mit folgendem inhalt füllen:

APT
      {
        Architecture "i386";
        Get::Download-Only "true";
      };

      Dir
      {
        State "/media/Disk/";
        State::status "status";
        Cache::archives "/media/Disk/archives/";
        Etc "/media/Disk/";
      };

Nun (auf dem EeePC) das medium mounten (wenn nicht schon geschehen) und die Datei /var/lib/dpkg/status kopieren

cp /var/lib/dpkg/status /media/Disk/

Nun das Medium auf den Rechner mit Internet Mounten und die /etc/apt/sources.list kopieren.

cp /etc/apt/sources.list /media/Disk/

nun „apt“ temporär „umbiegen“ und „updaten“:

#auf dem "download"-Rechner braucht es keine root rechte
export APT_CONFIG="/media/Disk/apt.conf"
apt-get update
apt-get dist-upgrade
apt-get install linux-backports-modules-jaunty

Nun warten bis die dateien auf das Trägermedium geschrieben wurden, dann am EeePC wieder mounten und dort updaten.

#kurzeitig eine root umgebung besorgen, erleichtert das ganze...
sudo -s
export APT_CONFIG="/media/Disk/apt.conf"
apt-get check
apt-get --no-d -o dir::etc::status=/var/lib/dpkg/status dist-upgrade
apt-get --no-d -o dir::etc::status=/var/lib/dpkg/status install linux-backports-modules-jaunty

anschließend neu starten und das WLan in Betrieb nehmen.

Seashell und Ubuntu NetBook Remix

ASUS hat mit dem ersten EeePC für Furore gesorgt weil dieser ohne ein Windows daher kam. Ja man konnte nicht mal eins installieren. Dieser neue EeePC ist „voll“ Windows-tauglich, so heißt es zu mindestens. Ausgeliefert wird er mit einer in vier Partitionen geteilten Platte samt vorinstallierten Windows XP.

WARNUNG: Die Linuxer unter euch, die sofort alles löschen und daraus ein oder mehrere EXT/Reiser Partitionen machen wollen, sollten hier innehalten. ASUS liefert BIOS Updates aus (die wichtig sind), welche nur von Windows aus zu installieren sind. Ihr braucht also eine Wartungspartition. Ich für meinen Teil hab eine 10GB XP partition und 150 GB EXT3.

Zudem läuft OOTB weder LAN noch WLAN mit Ubuntu. Damit fällt der Netzboott/NetInstall (PXE) ins Wasser. Zwar kann das BIOS via PXE booten, das aktuelle Jaunty Image kann jedoch die LAN-Karte nicht ermitteln und bricht ab. Einer Installation über USB Stick/SD-Karte steht aber nix im weg (NetbookRemix). Es Bedarf aber in jedem Fall einen zweiten Rechner mit funktionierendem Internetzugang und am besten apt-get. Denn man muss das erste Update ohne Internet fahren und erst danach bekommt man die WLan Karte (Artheros) ans laufen.

Hier die Zusammenfassung:

[OOTB funktional Ubuntu 9.04 Jaunty (NetbookRemix)]

Suspend to RAM
Suspend to Disk
Bluetooth
Sound
WebCam
Hintergrundbeleuchtung (Regelung)
Tastatur/Maus

[OOTB nicht funktional Ubuntu 9.04 Jaunty (NetbookRemix)]

LAN
WLAN
Alle Softkey haben keine Funktion (auch die um die WLan/BT verindung abzuschalten)
Sound zu leise (was sich aber ohne weiteres beheben lässt)

Die Akkulaufzeit beträgt rund 4 Stunden, wenn man es mittels powertop und ein paar Skriptes optimiert schafft man ohne Probleme die 6 Stunden.

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