EEE-PC 1002HA mit Debian und KDE

Diesen Beitrag schreibe ich gerade auf meinem alten Asus EEE-PC 1002HA unter Debian Linux und KDE. Angeregt durch den Podcast von Dirk und Roman habe ich mal den  alten Rechner aus dem Regal geholt und neu installiert. Ich erzähle mal, was ich gemacht habe und wie ich bis jetzt zufrieden bin.

Technische Daten

Der 1002HA hat einen Intel Atom 270 Prozessor, 1GB Hauptspeicher und eine 160GB Festplatte. Der Prozessor ist mit 1,6GHz getaktet. Alles in allem nicht viel Leistung für KDE, das nicht für seine Ressourcenfreundlichkeit bekannt ist.

Grundinstallation

Ich habe also ein Debian Stable (Squeeze) installiert. Bei der Installation habe ich nur die Grundinstallation und die Basissystemwerkzeuge ausgewählt, um danach eine schlanke KDE-Installation durchzuführen.

Nach der Grundinstallation habe ich die /etc/apt/sources.list angepasst, um auf die Backports von Testing zurückgreifen zu können. Folgende Zeilen sind in der Datei dazugekommen:

# backports
deb http://backports.debian.org/debian-backports squeeze-backports main contrib nonfree
# iceweasel
deb http://mozilla.debian.net/ squeeze-backports iceweasel-release

Danach habe ich eine Datei /etc/apt/preferences mit folgendem Inhalt angelegt:

Package: *
Pin: release a=squeeze-backports
Pin-Priority: 200

Danach erfolgt die Installation des Xorg-Servers:

aptitude install xserver-xorg-video-all

und danach die KDE-Minimalinstallation

aptitude install kdebase-workspace kde-plasma-workspace kde-l10n-de

Nach einem Neustart des Systems startet nun bereits KDE mit einer minimalen Sofwareauswahl und ohne 3D-Effekt-Schnick-Schnack. So weit, so gut.

Jetzt kommt als Grundausstattung noch ein Browser (Firefox aka Iceweasel), der Networkmanager und ein Mixer für den guten Ton drauf:

aptitude install kmix iceweasel iceweasel-l10n-de network-manager-kde

Kosmetik

KDE ist mit der Version 4.4.5 nicht das frischste und der Aero-Stil kam mit der Grafikkarte  noch nicht so klar, es sah teilweise hässlich aus. Also habe ich noch den Stil "Oxywin" heruntergeladen und als Icon Set "KFaenza", damiit sieht der Desktop schon ganz ordentlich aus und  läuft auch recht flott. Soweit bin ich erstmal zufrieden, die Bootzeit liegt bei 1 Minute und 20 Sekunden inklusive Anmeldung und Start von KDE. Ich werde  jetzt mal weiter damit arbeiten und noch weitere Software installieren und hier darüber berichten.

Ach ja, hier sind noch ein paar Screenshots des Desktops (anklicken für die große Ansicht):





Fehlersuche im VPN

Gestern Abend saß ich mit einem befreundeten Admin zusammen. Er hatte ein Problem mit einem VPN-Gateway eines Kunden und wir wollten uns zusammen auf Fehlersuche machen. Der Server ist ein IPSEC-Gateway auf Linuxbasis und sollte neben einigen reinen IPSEC-Clients noch ein iPhone mittels L2TP anbinden.

Die Einwahl mit dem iPhone funktionierte auch schon, allerdings waren danach die Server im internen Netz des Kunden nicht erreichbar. Die Konstellation bei dieser Konfiguration ist also wie folgt:

iPhone --> Internet --> IPSEC --> L2TP --> PPP Verbindung --> internes Netz

Also jede Menge potenzielle Fehlerquellen. Da die Verbindung an sich aber zu Stande kam, nahmen wir uns die erste Verdächtige vor.

1. Firewall

Nach eingehender Untersuchung konnten wir hier keinen Fehler feststellen. Eine Blick in die Log-Dateien offenbarte auch keine blockierten Pakete. Also weiter.

2. Konfigurationsdateien

In der Konfiguration mit Openswan als IPSEC-Dienst, xl2tpd als L2TP-Dämon und PPP für die Point-to-Point Verbindung gibt es einige Konfigurationsdateien, die es zu testen galt. Wir prüften die Dateien auf Fehler in den Netzwerkkonfigurationen, das sollte sich später noch als nicht ausreichend erweisen. Die Konfiguration der Netzwerkelemente war in Ordnung, die PPP-Verbindung kam mit den richtigen IP-Adressen zu Stande. Der PPP-Dämon baut eine virtuelle Verbindung zwischen zwei IP-Adressen aus dem internen Netz auf und leitet den Verkehr dann an das physische Netzwerkdevice des VPN-Routers weiter. Dadurch ist kein Routing notwendig, um die virtuelle Adresse des iPhones zu erreichen. Das wird später noch wichtig werden.

3. Netzwerkdevices

Eine kurze Untersuchung der Netwerkdevices der virtuellen PPP-Verbindung mit ifconfig ergab, dass das Device zwar Pakete raus schickte, aber keine zurück kamen. Doch die Firewall? Also noch mal zurück zu 1., dann

4. Ratlosigkeit

Es war schon etwas später, wir wollten schon den Einsatz beenden. Dann wollten wir doch noch einen letzten Versuch machen, den Fehler zu finden.

5. Netzpakete untersuchen

Also noch tcpdump angeworfen, um die Pakete zu untersuchen, die beim Aufbau einer Verbindung zum Exchange-Server so übers Netz gehen. Gesagt, getan, das SYN-Paket geht raus, aber keine Antwort des Exchange. Ah, Moment, da ist noch eine ARP-Anfrage, der Exchange möchte wissen, unter welcher MAC-Adresse er die virtuelle IP des iPhones erreichen kann (es ist ja eine interne Adresse). Offensichtlich bekommt er keine Antwort. Ich ahne etwas. In der Options-Datei der PPP-Verbindung für L2TP gibt es den Parameter "proxyarp", der dafür zuständig ist, dass der PPP-Dämon ARP-Anfrage nach der virtuellen IP mit der MAC-Adresse der Netzwerkkarte des Servers beantwortet. Ein Blick in die Konfigurationsdatei zeigt, das der Parameter schlicht fehlt. Bingo. Parameter eingefügt, Verbindung neu gestartet, alles läuft.

Das ganze hat knapp 3 Stunden gedauert und hätte auch etwas schneller gehen können, wenn wir unter 2. bereits die Parameter in der Options-Datei geprüft hätten, und uns nicht nur auf die Netzwerkparameter konzentriert hätten. Das war zwar ärgerlich, aber wir haben für das nächste Mal auch etwas gelernt, ist auch wichtig.


SSH Autorisierung automatisieren

Es kommt öfter vor, dass ich mich auf verschiedenen Linux-Rechnern via SSH anmelden muss. Aus Sicherheitsgründen nutze ich die Autorisierung mittels Keys, gerade, wenn die Anmeldung über das Internet erfolgt.

Bash

Da der private Schlüssel mit einem Passwort gesichert ist, muss man dieses bei jeder Anmeldung eingeben, es sei denn, man automatisiert diesen Vorgang. Die Arbeit übernimmt das Tool ssh-agent.

Der Agent wird zunächst gestartet:

ssh-agent

Unter dem von mir genutzten Kubuntu ist übrigens ein ssh-agent standardmäßig bereits gestartet. Danach fügt man den privaten Schlüssel des aktuellen Benutzers mit

ssh-add

hinzu, sofern dieser unter dem Standartpfaden (~/.ssh/identity, ~/.ssh/id_dsa, ~/.ssh/id_rsa) abgelegt ist. Dabei wird einmalig das Passwort des privaten Schlüssels abgefragt. Danach wir bei jeder SSH-Anmeldung automatisch mit diesem Key autorisiert. Das funktioniert so lange, bis der Agent beendet wird. Die Autorisierung funktioniert auch bei anderen SSH-Tools, wie z.B. beim Dateien kopieren mit scp.