thinkretro.de

Atyfb auf dem Dell Latitude CPx H500GT

Seit geraumer Zeit besitze ich einen schon in etwas die Jahre gekommenen (manch einer würde sagen antiken) Dell Latitude CPx H500GT. Ein 14-Zoll Notebook mit einer 500MHz Pentium-III CPU und 256 MB Ram aus dem Jahr 2000. Zwar ist das nichts mit dem man heute noch irgendwen beeindrucken kann, aber das Ding ist in tadelosem Zustand und auf der Tastatur tippen sich die Blogposts wie in Butter ☺. Installiert ist ein aktuelles Debian "Stretch", ohne X - und was soll ich sagen, alles läuft so wie es soll. Zumindest mittlerweile. Ich hatte nämlich bis dato ziemliche Probleme das richtige Kernelmodul für die verbaute ATI Mach64 Grafikkarte zu laden. Nach langem hin-und-her, habe ich jetzt endlich zumindest einen Workaround gefunden mit dem das atyfb-Kernelmodul geladen werden kann.

Einen ersten Schritt in die richtige Richtung brachte das Einfügen der Zeile GRUB_TERMINAL=console in der Datei /etc/default/grub. Gesagt getan und siehe da man kann nun mit sudo modprobe atyfb das richtige Kernelmodul laden.

Das Ganze zu automatisieren war wiederum eine andere Geschichte. Für das Laden spezifischer Kernelmodule zum Bootzeitpunkt ist der SystemD-Dienst systemd-modules-load.d.service zuständig, der zunächst im Ordner /etc/modules-load.d nach *.conf Dateien Ausschau hält und dann die darin genannten Kernelmodule lädt. So weit zur Theorie. Legt man in diesem Verzeichnis eine Datei atyfb.conf und schreibt in diese den gleichnamigen Modulnamen atyfb so sollte dieses beim Systemstart geladen werden. Eigentlich. Nach langem hin und her und nach einem aufmerksamen durchlesen der Ausgabe von journalctl -xe | less fand ich den Hinweis, dass das Kernelmodul nicht geladen werden konnte, weil es auf einer blacklist stand. Das Ganze brachte mich dann wiederum zu der Frage ob so eine Blacklist noch an anderer Stelle als unter /etc/modprobe.d geführt wird und siehe da mit der Brachialmethode grep -r atyfb / 2>/dev/null erschien die verräterische Zeile /lib/modprobe.d/blacklist-fbdev: blacklist atyfb, die ich nur noch auskommentieren musste.

Jedenfalls klappt es nun und das richtige Kernelmodul wird beim Systemstart geladen. So richtig smooth ist diese Methode allerdings noch nicht. Warum auch immer werden Einstellungen, die ich in der Datei /etc/default/console-setup vorgenommen habe nicht beim Start geladen. Hier hilft immer nur ein manuelles systemctl restart console-setup.service. Man kann halt nicht alles haben und vermutlich ist das der Preis, wenn man auf 17 Jahre alter Hardware unterwegs ist ☺.

Alles neu

Der ein oder andere (wieviele lesen hier eigentlich mit?) wird es vermutlich bemerkt haben, hier hat sich einiges verändert. Nachdem ich es Anfang Februar versäumt hatte rechtzeitig ein Sicherheitsupdate für Wordpress einzuspielen wunderte ich mich nicht schlecht, dass mich am morgen eine kurdische Flagge und der Slogan 'long live the Peshmerga' auf meiner Website stand. Jedenfalls war das der Auslöser hier mal ein paar Dinge umzustellen. Schon seit längerer Zeit habe ich mit dem Gedanken gespielt von einer Wordpressumgebung auf eine statisch vorgenerierte Website umzustellen.

Im Wesentlichen war ich ganz zufrieden mit Wordpress, ich hatte nur den Eindruck für das was es hier zu sehen gibt ist ein ganzes Content-Management-System eine Spur zu überdimensioniert - wer braucht schon ne ganze Datenbank für ein bißchen Text und ein paar Bilder? Von den Anforderungen an ein Backup ganz zu schweigen.

Long story short...ich habe das Ganze jetzt mal ein wenig verschlankt. Ich schreibe immer noch meine Blogartikel in markdown mit vim und benutze jetzt Pelican um daraus mein Blog zu bauen. Die fertigen html-Dateien lade ich dann via rsync auf meinen vServer hoch. Fertig :-). Als Theme verwende ich das Theme Blue Penguin, das ich ein wenig an meine Bedürfnisse angepasst habe.

Das ganze funktioniert ausgesprochen gut, aber wehe du willst etwas an dem Theme ändern und hast eigentlich keine Ahnung von CSS. Dann geht das Theater los. Irgendwie ist Webentwicklung eklig und so richtig Spaß kommt da nicht auf. Aber so ganz ohne Theme ist's auch ein bißchen fade. Naja zum Glück gibts übrigens den Entwicklermodus (einfach mal Strg+Shift+i drücken) im Chromium, da lässt sich ziemlich charmant live am css herumfummeln und man sieht sofort die Auswirkungen.

Der große Vorteil ist allerdings, dass die Generierung dieser Website keine nennenswerten Hardwareressourcen verbraucht. Damit sind jetzt auch wieder Blogposts auf fast zwanzig Jahre alter Hardware möglich ☺

Join the Shell Users' Revolutionary Front Rage Against the Web

Das schöne an Linux ist ja, dass es immer wieder etwas Neues zu entdecken gibt. Oft stellt man dabei auch noch fest, dass es für eine bestimmte Aufgabe - wie etwa die Suche im Web - noch einen kürzeren, eleganteren und vor allem schnelleren Weg gibt. So z.B. mit Surfraw (Shell Users Front Rage Against the Web), das über die Shell aufgerufen, die query-url für eine ganze Reihe an Webseiten und Suchmaschinen zusammenbaut und das ganze dann im Browser aufruft. Klingt erst einmal wenig spektakulär, aber genau darin liegt die Magie :-) Da ich eh immer ein Terminalfenster offen habe, ist das wesentlich schneller als erst zum Browser zu wechseln, dort die Website einzugeben und dann die Suchfunktion zu bemühen.

Eine einfache Suche über surfraw bei duckduckgo sieht bspw. so aus:

$: sr duckduckgo Battle of Hoth

Surfraw bringt von Haus aus eine ganze Reihe an unterstützten Webseiten (elvis) genannt mit. Eine einfache Liste dieser Elvis kann man über

$: sr -elvi

aufrufen oder einfach im Verzeichnis /usr/lib/surfraw nachsehen. Ich benutze z.B. folgende Elvis ziemlich regelmäßig:

• debpkghome -- Website der Originalsoftware in einem Debianpaket
• archwiki -- Archlinux Wiki
• duckduckgo -- nette Suchmaschine
• youtube -- videos direkt suchen
• google -- gute Ergebnisse, aber evil :-)
• wayback -- internet archive wayback machine
• wikipedia -- enzyklopädie
• leodict -- Dictionary

Jedes Elvi bietet zudem noch einige Optionen, mit der man die Suche entweder präzisieren kann oder aber das Verhalten der aufgerufenen Website zu steuern. Dabei listet

$: sr elvi -local-help

die für das elvi verfügbaren Optionen auf. Im Falle von duckduckgo wäre das bspw.:

$: sr duckduckgo -local-help

    Usage: duckduckgo [options] [search words]...
    Description:
    Surfraw search the web using DuckDuckGo (www.duckduckgo.com)
    Local options:
            -d,-ducky,-l,-lucky         use in case of overwhelming feeling of duckiness
            -j,-javascript              use javascript
            -safe                       enable safe search
            -r,-redirect                use redirection
            -s,-insecure                disable SSL search

eigene Bookmarks, eigene elvis

Neben den bereits vorhandenen elvis bietet surfraw zudem die Möglichkeit bookmarks zu setzen. Will man bspw. die Pronom-Datenbank der National Archives nach einer bestimmten PUID (= Pronom unique identifier) suchen, kann man das bequem über ein Bookmark machen. Dazu erstellt man die Datei ~/.config/surfraw/bookmarks und trägt dort Folgendes ein:

puid http://www.nationalarchives.gov.uk/PRONOM/%s

Nun kann man über

$: sr puid fmt/44

oder

$: sr puid x-fmt/20

direkt den jeweiligen Eintrag in der Pronomdatenbank aufrufen. Alternativ kann man übrigens auch den entsprechenden Bang von duckduckgo nutzen (think of the possibilities :-) ):

$: sr duckduckgo \!puid fmt/44

Wichtig ist hierbei das Ausrufezeichen zu escapen, damit es nicht von der Shell interpretiert wird.

Alternativ kann man auch direkt loslegen und ein eigenes elvi erstellen. Wie das geht, ist im offiziellen Surfraw Hacking Guide beschrieben. Die einfachste Methode ist sich ein existierendes elvi, das am besten zu der gewünschten Website passt, zu nehmen und und es einfach entsprechend anzupassen.

Wordpress mit Lighttpd, MariaDB und PHP

Lighttpd

Nachdem ich meinen neuen vServer abgesichert habe, geht es nun ans Eingemachte: die Übertragung meines Weblogs von meinem alten Webspace an seine neue Heimat. Dazu braucht man lediglich einen Webserver, eine Datenbank (in der Regel MySQL) und PHP. Wenn es darum geht, einen Webserver unter Linux zu betreiben, dann stößt man im Internet fast überall auf den Apache Webserver oder nginx. Daneben gibt es aber noch eine Reihe anderer, z.T. weniger bekannte Alternativen, die vor allem in Sachen Ressourcensparsamkeit besonders punkten können. Ein solcher Kandidat ist Lighttpd oder kurz: lighty Ich setze lighty schon seit geraumer Zeit auf meinem BananaPi ein um dort Dienste wie etwa owncloud oder tiny tiny rss nutzen zu können. Gerade in einer Umgebung mit eingeschränkten Ressourcen bei nicht allzu hohen Anforderungen (etwa viele gleichzeitige Anfragen an den Webserver) hat lighty bisher eine exellente Figur gemacht. Klar, dass er deshalb auch prädestiniert für mein vServer-Projekt ist :-)

Konfiguration

Das schöne an lighty ist die recht simple Konfiguration. Zentraler Anlaufpunkt für die Konfiguration ist die Datei /etc/lighttpd/lighttpd.conf. Für meine Konfiguration nutze ich folgende Module:

• mod_access
• mod_compress
• mod_rewrite
• mod_fastcgi
• mod_accesslog

Die eigentliche Konfiguration für meine Domain packe ich in den folgenden Abschnitt. Darin definiere ich zunächst das Rootverzeichnis wo die eigentliche Wordpressinstallation liegt und die Speicherorte für das access.log und das error.log; zudem schalte ich das 'directory listing' aus. Da Lighttpd keine Unterstützung für eine .htaccess Datei bietet muss der Zugriffsschutz auf bestimmte Dateien auf anderem Wege eingerichtet werden. Mittels url.access-deny kann man den Zugriff auf diese Dateien verbieten. Zum Schluss noch eine rewrite-Regel, die ich hier gefunden habe, damit die Wordpress Permalinks sauber aufrufbar sind. Der letzte Abschnitt verhindert, dass mein Weblog über die IP-Adresse aufgerufen werden kann.

$HTTP["host"] =~ "(www.)?thinkretro.de" {
  server.document-root = "/var/www/thinkretro.de"
  accesslog.filename = "/var/log/lighttpd/thinkretro.de/access.log"
  server.errorlog = "/var/log/lighttpd/thinkretro.de/error.log"
  dir-listing.activate = "disable"
  url.access-deny = ("wp-config.php", "wp-cron.php", "wp-login.php", "wp-trackback.php", "xmlrpc.php")
  url.rewrite = (
        "^/(.*)\.(.+)$" => "$0",
        "^/(.+)/?$" => "/index.php/$1"
    )
}
$HTTP["host"] =~ "138.201.159.234" {
  url.access-deny = ( "" )
}

Damit die neue Konfiguration geladen wird muss der Webserver neu gestartet werden:

#: systemctl restart lighttpd

Wenn auf dem System noch eine Firewall läuft, sollte man zudem den Port 80 freigeben. Sonst sollte man sich nicht wundern, warum man einfach keine Verbindung zum Webserver von außen herstellen kann. ;-)

Installation von MariaDB und Import des SQL-Dumps

Statt MySQL nutze ich die völlig freie und zu MySQL kompatible Datenbank MariaDB. Die Installation ist auch schnell erledigt:

#: sudo apt-get install mariadb-server mariadb-client
#: sudo mysql_secure_installation

Standardmäßig wird bei der Installation u. a. eine Testdatenbank und ein Benutzeraccount "anonymous" angelegt, der jedem den Login ohne Passwort erlaubt, daher empfiehlt es sich für eine Produktivumgebung erst einmal aufzuräumen. Der letzte Befehl sorgt u. a. dafür, dass diese Testdatenbank entfernt wird und sich nur autorisierte Benutzer anmelden dürfen.

Neuen Benutzer anlegen und leere Datenbank erstellen:

Nun gilt es eine neue Datenbank und einen neuen Benutzer zu erstellen. Anmelden an der Datenbank als root:

$: mysql -u root -p
MariaDB [(none)]> create database if not exists wordpress_db;
MariaDB [(none)]> create user 'wordpress'@'localhost' identified by 'password';
MariaDB [(none)]> grant all on wordpress_db.* to 'wordpress';
MariaDB [(none)]> flush privileges;
MariaDB [(none)]> exit;

Als erstes wird eine leere Datenbank 'wordpress_db' erstellt. Danach ein neuer Benutzer 'wordpress' mit dem Passwort 'password'. Als nächstes werden diesem Benutzer alle Rechte an der Datenbank 'wordpress_db' zugeteilt und zum Schluss die Privilegien aktualisiert und die Datenbank verlassen. Nun kann man den SQL-Dump in die neue Datenbank importieren:

$: mysql -u wordpress -p wordpress_db < sql_dump.sql

PHP

Die Installation von PHP gestaltet sich hier wesentlich simpler und einfacher. Installation der benötigten Pakete:

sudo apt-get install php5-cgi php5 php5-mysql

Wenn man nicht den Apache als Webserver einsetzen will, muss man hier auf die richtige Installationsreihenfolge der Pakete achten. Damit der Fast-CGI Prozess vom Webserver gestartet werden kann, muss noch die entsprechende Konfigurationsdatei /etc/lighttpd/lighttpd.conf angepasst werden. Dort fügt man ein:

#PHP-fcgi:
fastcgi.server = ( ".php" => ((
"bin-path" => "/usr/bin/php5-cgi",
"socket" => "/tmp/php.socket"
)))

Darüber hinaus muss in der Datei /etc/php5/cgi/php.ini der Kommentar in der Zeile cgi.fix_pathinfo = 1 entfernt werden.

Was noch fehlt

Wie man sieht, ist die Konfiguration wahrlich kein Hexenwerk und - wenn man sich mal etwas eingelesen hat - auch recht schnell erledigt. Was jetzt noch fehlt ist die Umstellung des kompletten Datenverkehrs auf Https.

Erste Schritte mit dem neuen vServer

Seit geraumer Zeit schlage ich mich mit dem Gedanken herum, meine Webseite auf einen eigenen Rootserver umzuziehen. Hauptgrund ist dabei die Möglichkeit den gesamten Verkehr über https laufen zu lassen (Let's Encrypt lässt grüßen :-) ) und darüber hinaus auch automatisiert regelmäßige Backups anlegen zu können. Ersteres lässt sich mein momentaner Webspaceanbieter nämlich fürstlich bezahlen, Letzteres war bisher von mir nur sporadisch gepflegt worden da man Backups nur manuell in der Administrationsoberfläche anstoßen konnte.

Das Mehr an Flexibilität (den Spaß nicht zu vergessen :-) ) geht jedoch einher mit einem gestiegenen Wartungsaufwand sowie einem hohen Maß an Verantwortung; schließlich ist man auch direkt verantwortlich, wenn der Server gekapert wird, weil man ihn nicht richtig abgesichert hat und nun Amok läuft. Entscheiden musste ich mich letztendlich nur noch, ob ich mir einen eigenen kleinen Server zu Hause hinstelle oder ob ich etwas Passendes miete. Nach einigem hin und her habe ich mich dann für die Mietoption entschieden, jedoch statt eines echten physischen Servers "nur" einen virtualisierten gemietet. Zum einen war mir ein ausgewachsener Rootserver mit 8-Kern-CPU und Gigabytes voll RAM dann doch 'ne Nummer zu oversized für meine Bedürfnisse, zum anderen zahlt man für solche Rechenknechte auch ein hübsches Sümmchen monatlich. Da bieten gerade die kleineren vServer eine gute Mischung aus Preis und verfügbarer Leistung und sollten für kleinere Projekte vollkommen ausreichen. Gesagt getan, der Server war bestellt und schon nach 5 (!) Minuten bekam ich die Mail mit den Zugangsdaten. Und das am Freitag Abend nach 19 Uhr; Respekt :-)

Erste Schritte

Mit den Zugangsdaten kann man sich nun via SSH auf dem Server als root einloggen. Das erste, was man auf jeden Fall tun sollte ist das Passwort zu ändern:

#: passwd

da der Server bei Auslieferung noch auf Englisch gestellt war, habe ich ihn kurzerhand auf Deutsch umgestellt:

#: dpkg-reconfigure locales

dort die entsprechenden locales auswählen und dann mittels

#: locale-gen

generieren. Da ich nicht gerne ständig im root-Kontext arbeite erstelle ich mir gleich einen eigenen Benutzer

#: adduser vserver-user

SSH-Dienst absichern

Neben einer Firewall wohl der wichtigste Punkt. Momentan kann man sich via SSH mittels Passwort anmelden und auch root kann sich dort anmelden. Um auch hier ein gesteigertes Maß an Sicherheit zu bekommen, sollte man auf jeden Fall den SSH-Login auf Publickey Authentication umstellen und die Anmeldung via Passwort unterbinden; darüber hinaus sollte es dem root user nicht erlaubt sein, sich überhaupt per SSH einzuloggen. Die einzelnen Punkte habe ich hier schonmal beschrieben.

Firewall einrichten

Der nächste Punkt auf der Liste ist die Einrichtung einer Firewall, wenn man nicht will, das die Serverdienste munter und unkontrolliert mit der Außenwelt kommunizieren können. Ich setze dabei auf die 'uncomplicated firewall' bzw. 'ufw', die ein leicht zu bedienendes Frontend für iptables bietet. Als erstes erstellen wir eine Standardregel und verbieten grundsätzlich alles, danach erlauben wir speziell den ssh-Dienst und dann schalten wir noch das logging ein:

#: ufw default deny
#: ufw allow ssh
#: ufw logging on

fail2ban

Ich hatte den Server keine halbe Stunde und schon klopften die ersten Idioten an die Tür, wie mir ein Blick in die Datei

/var/log/auth.log

verrät. Standardmäßig haben sie beliebig viele Versuche um reinzukommen. Um das einzuschränken, bietet sich fail2ban an. Dieses nützliche, in Python geschriebene Programm, scant periodisch verschiedene Logdateien nach verdächtigen Inhalten (z.B. mehrfach gescheiterte Login-Versuche pro IP) und sperrt bspw. eine IP-Adresse nach zuvielen gescheiterten Loginversuchen. Den Status eines 'jails' kann man jederzeit via

#: fail2ban-client status ssh

abrufen.

Fazit

Ich denke, wenn man diese Punkte erst einmal abgearbeitet hat, hat man seinen Server schon ein bedeutendes Maß sicherer gemacht und kann nachts etwas ruhiger schlafen. Absolute Sicherheit gibt es leider nicht, daher sollte man seinen Server regelmäßig kritisch beobachten und vor allem regelmäßg Sicherheitsaktualisierungen einspielen.

Grub-Bootloader in einer chroot-Umgebung wiederherstellen

Es passiert irgendwie immer wieder. Ich habe jüngst auf einer Partition Windows 7 installiert und irgendwie wurde (mal wieder) der GRUB Bootloader überschrieben.

Um das Ganze wieder zu reparieren besorgt man sich  zunächst das entsprechende archlinux-iso und schreibt dieses auf einen USB Stick und bootet dan von diesem USB Stick. Das Archlinux-Image nehme ich deshalb, da es praktischerweise sowohl für x86_32 als auch für x86_64 Systeme passt, man kann nämlich nicht mit einem 32-bit Linux in eine 64-bit Chroot-Umgebung wechseln. Welche Laufwerke und Partitionen vorhanden sind erhält man mittels:

$: lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 111,8G  0 disk 
├─sda1   8:1    0  72,7G  0 part 
└─sda4   8:4    0  39,1G  0 part 
sdb      8:16   0 232,9G  0 disk 
├─sdb1   8:17   0   100M  0 part 
└─sdb2   8:18   0 232,8G  0 part 
sdc      8:32   0 596,2G  0 disk 
├─sdc1   8:33   0  14,9G  0 part 
├─sdc2   8:34   0 156,3G  0 part 
└─sdc3   8:35   0   425G  0 part 
sdd      8:48   1  1007M  0 disk 
└─sdd1   8:49   1  1005M  0 part 
sr0     11:0    1  1024M  0 rom

In meinem Fall ist /dev/sda4 meine Linux-Partition. Nun kann man die chroot-Umgebung vorbereiten:

#: mkdir mnt
#: mount /dev/sda4 mnt/
#: mount -t proc proc mnt/proc
#: mount -t sysfs sys mnt/sys
#: mount -o bind /dev mnt/dev

Als nächstes kann die Chroot-Umgebung betreten werden und grub auf /dev/sda installiert werden:

#: chroot mnt/ /bin/bash
#: pacman -S grub
#: grub-install /dev/sda
#: grub-mkconfig -o /boot/grub/grub.cfg

Danach die Chroot Umgebung verlassen und die mounts wieder auflösen:

#: exit
#: umount mnt/dev
#: umount mnt/sys
#: umount mnt/proc
#: umount mnt/
#: reboot

Das war's. Wie man sieht eine Sache von ein paar Minuten :-)

Statusbericht 2016

Es ist schon wieder einige Zeit her, genauer gesagt schon mehr als ein halbes Jahr ?, und das Jahr 2016 hat auch schon begonnen. Da ist ein kurzes Lebenszeichen von mir wohl mehr als fällig. Kurz gesagt, ja ich lebe noch. Auch habe ich die Lust an meinem Hobby und an alter Hardware nicht verloren. Ich habe mich in der letzten Zeit intensiver mit der Linux Kommandozeile auseinander gesetzt und bin dabei auch ein wenig in die Shell-Programmierung mit der Bash eingestiegen. Kurzfristig hat das dazu geführt, dass es hier ein wenig ruhiger geworden ist, allerdings erhoffe ich mir langfristig ein grundlegenderes Verständnis von Linux und der Kommandozeile, die ich dann hier in ausgewählte Artikel einfließen lassen kann. Tatsächlich hatte ich insbesondere beim näheren Betrachten der Shell schon einige AHA-Erlebnisse, die einen eigenen Artikel wert sind. Aber nun zunächst die Nachrichten aus Hard- und Software :-)

Hardware

So langsam spricht es sich in meinem Bekanntenkreis herum, was für ein obskures Hobby ich so pflege :-) Netter Nebeneffekt ist, dass mir die Leute nun ihre ausgediente Hardware vermachen, statt sie einfach zu entsorgen. Das hat dazu geführt, dass ich nun über eine hübsche Sammlung an alten Notebooks verfüge. Welche ich davon letztendlich behalten werde, weiß ich jedoch noch nicht. Dabei hat sich vor allem das T43 als mein rundum-sorglos-Laptop etabliert und einen festen Platz auf meinem Schreibtisch bekommen. Aber auch die anderen Rechner gibt es natürlich noch und funktionieren tadellos.

Des Weiteren habe ich meine Synology-NAS dieses Jahr durch ein selbst zusammengestelltes System getauscht. Momentan läuft darauf openmediavault und ich bin bisher sehr zufrieden.

Als kleiner, stomsparender Server läuft bei mir nach wie vor der BananaPi. Seitdem ich dort jedoch mit Syncthing allerhand Daten synchronisiere, geht dem Kleinen etwas die Puste aus. Wie gut, dass vor kurzem der Oodroid-C2 von Hardkernel angkündigt wurde.

Software

Neben der Bash habe ich mich in letzter Zeit intensiver mit dem VIM beschäftigt. Ich würde mich allerdings immer noch eher als fortgeschrittenen Anfänger bezeichnen. Aber es ist schon erstaunlich, was man alles mit diesem Editor machen kann; man muss sich nur die Mühe machen, sich mit dem Vim intensiv zu beschäftigen. Ansonsten ist softwaretechnisch alles beim alten geblieben. Ich versuche derzeit lediglich zu den meisten Gui-Programmen ein Pendant für die Konsole zu finden um noch etwas flexibler zu werden.

An Betriebssystemen dominieren derzeit bei mir vor allem Debian und Archlinux. Als Desktopumgebung setze ich gerade Cinnamon ein, mit der ich recht zufrieden bin, wenngleich sie auch nichts für schwache Rechner ist. Spielt Ressourcenverbrauch eine Rolle, so ist nach wie vor openbox meine erste Wahl. So setze ich auf dem T43 gerade Debian mit LXDE ein, das auf dem mittlerweile 10 Jahre alten Thinkpad eine recht gute Figur macht.

Ausblick für 2016

Konkrete Pläne für 2016 habe ich zwar nicht, ich möchte mich aber auf jeden Fall noch mehr mit den Grundlagen von Linuxsystemen beschäftigen. Aber natürlich möchte ich auch wieder mehr schreiben, schließlich ist das hier ein Blog :-)

Bonjour Thinkpad T43

Seit kurzem gibt es einen Neuzugang in meiner stetig größer werdenden Sammlung von ~~Computerschrott~~ historischen Notebooks. Und wie es der Zufall so will, ist es mal wieder ein Thinkpad geworden :-) Genauer ein Thinkpad T43 aus dem Jahre 2005. Erworben habe ich es von einem guten Freund samt passender Dockingstation für umgerechnet etwa ein bis zwei Kästen Bier, ein unschlagbarer Wechselkurs also :-) Es ist optisch wie technisch in einem hervorragenden Zustand und wurde offensichtlich gut gepflegt.

Ausstattung

Von der Ausstattung her kann man ganz und gar nicht meckern; hier die wesentlichen Leistungsdaten:

• Intel Pentium-M (Centrino) @ 1.73 GHz
• 2048 MB DDR2 Ram
• Ati Radeon Mobility x300
• 64 GB Transcend IDE SSD
• 14 Zoll XGA Display
• Intel PRO/Wireless 2200BG
• Gigabit-Ethernet
• Intel Audio

Wennauch der Pentium-M nicht mehr so ganz taufrisch ist, so reicht er dennoch für sämtliche alltäglichen Aufgaben auch heute noch vollkommen aus. Lediglich bei der Wiedergabe von Full-HD-Videomaterial geht ihm - mangels Hardwarebeschleunigung - ein wenig die Puste aus; aber wer schaut sich auch Full-HD-Filme bei XGA-Auflösung an :-)

OS

Wie praktisch, dass jüngst Debian 8 alias Jessie erschienen ist :-). Da konnte ich der Versuchung einfach nicht wiederstehen und musste das gleich mal auf dem Thinkpad T43 ausprobieren. Insbesondere wollte ich mal sehen, was sich seit dem Umstieg auf SystemD so getan hat. Als Fenstermanager kommt hier wieder Openbox zum Einsatz, der mir auch schon auf anderen Systemen gute Dienste geleistet hat. Die Installation verlief - ohne dass ich an irgendeiner Stelle eingreifen musste - völlig problemfrei durch, nicht einmal am Sound- oder Grafiktreiber musste ich in irgend einer Weise Hand anlegen.

Was mir sofort auffiel war, dass offensichtlich der Webbrowser Midori aus den Debian-Repositories geflogen ist. Nun bin ich auf der Suche nach einer guten Alternative; der Firefox (bzw. Iceweasel wie er unter Debian heisst) ist mir - trotz SSD - leider ein wenig zu träge. Auch cmus - mein beliebter Musikplayer für die Konsole - zickt ein wenig rum; aber hier gibt es ja noch den MOC :-)

Fazit

Ich bin ausserordentlich zufrieden mit dem Thinkpad T43, alles funktioniert so wie es soll. Ich hoffe, dass ich an diesem guten Stück noch lange Freude haben werde und mir noch den ein oder anderen interessanten Blogpost beschert :-). Einziger Schimmer am sonst ungetrübten Abendhimmel ist das Flexing-Problem der T4x-Reihe (und anderer Notebooks der Centrino-Generation). Da das T43 aber sowieso eher auf meinem Schreibtisch steht und wenig herumgetragen wird, sollte es eigentlich keine Probleme geben...

Eigene SSH-Konfiguration verwenden

Es gibt so manche Dinge im Leben bei denen man sich fragt - wenn man sie denn einmal herausgefunden hat - warum nicht gleich so? Eines dieser Dinge ist bspw. eine eigene Konfigurationsdatei für ssh-Verbindungen. Normalerweise sieht ein Login auf einem meiner Server nämlich so aus:

$ ssh -p 12345 -i ~/.ssh/server_key user@domain

Das ist vor allem immer eine elende Tipperei. Dabei geht es auch einfacher, indem man das Ganze einfach in eine config-Datei schreibt und in seinem Homeverzeichnis unter ~/.ssh/config ablegt:

Host Servername
    HostName server.domain.de 
    Port 12345 
    User username 
    IdentityFile ~/.ssh/server_key

Danach kann man ganz einfach mit

$ ssh Servername

sich zu seinem ssh-Server verbinden. Gerade wenn man mehrere ssh-Verbindungen managen will (mit unterschiedlichen RSA-Keys) lohnt es sich eine eigene Konfigurationsdatei anzulegen.

Richtig cool ist allerdings, dass man über ssh bestimmte Ports auf dem Zielserver auf einen (nicht-privilegierten) Port auf dem lokalen Rechner mappen kann. Ich kann also bspw. meinen internen Webserver der daheim auf dem BananaPi zu administrativen Zwecken läuft auf einen beliebigen Port meines Laptops mappen und so von außerhalb bequem darauf zugreifen. Dazu muss man seine ~/.ssh/config nur wie folgt erweitern:

Host tunnel_zum_webserver 
    HostName server.domain.de 
    Port 12345 
    User username 
    IdentityFile ~/.ssh/server_key 
    LocalForward 4000 127.0.0.1:8080

Jetzt kann man mit

$ ssh -f -N tunnel_zum_webserver

eine einfache Verbindung zu seinem Webserver aufbauen und der ganze Verkehr wird über ssh getunnelt :-)

Das ganze funktioniert nicht nur mit einem Webserver, sondern auch mit allen anderen Diensten, die über das Netzwerk erreichbar sind, wie etwa Samba-Freigaben oder ein MySQL-Server... :-)

Slitaz-base auf dem Thinkpad 600E

Was gibt es schöneres an einem sonnigen Tag als auf einem etwas betagten Laptop Linux zu installieren? Obwohl das Thinkpad 600E mit seinem Pentium II Prozessor und 192 MB Ram durchaus genug Power besitzt um eine grafische Oberfläche zu zeichnen, habe ich mich diesmal für eine Konsole-only Variante entschieden. Als Basis hierfür habe ich diesmal Slitaz genommen, dass in dem Ruf steht auch auf einem 486er mit nur 16 MB Ram noch lauffähig zu sein (ein Test steht da noch aus :-) )

Iso-Image besorgen und davon booten

Zunächst habe ich mir auf der Slitaz-Homepage ein aktuelles Iso-Image der Stable-Version heruntergeladen. Dabei kann man zwischen verschiedenen Versionen (‘Flavors’) wählen. Hier gibts eine direkte Übersicht. Ich habe mich für die ‘base’ Variante entschieden, mit lediglich 8 MB. Für die Installation habe ich mich an die unter folgendem Link einsehbaren Anleitung gehalten.

Partitionen erstellen

Als erstes muss die Festplatte partitioniert werden. Im Prinzip reichen mir zwei Partitionen aus; eine ‘Root-Partition’ und eine ‘Swap-Partition’. Natürlich kann man das aber machen wie man will. Gerade wenn man noch andere Betriebssysteme auf dem Rechner installiert, lohnt es sich vielleicht noch über eine separate ‘Home-Partition’ nachzudenken. Nach dem Partitionieren müssen noch die erstellten Partitionen mit dem gewünschten Dateisystem formatiert werden:

~# mkswap /dev/hda2 && swapon /dev/hda2

~# mkfs.ext4 /dev/hda1

Danach sollte ~# blkid etwa folgendes ausgeben:

/dev/hda1: UUID="42ea812e-58c6-437f-a624-05e162ae116b" TYPE="ext4"
/dev/hda2: UUID="8962e5a4-1630-44e6-85fe-71b3254c9ac3" TYPE="swap"

Partition einbinden

Als nächstes muss die Root-Partition in das Dateisystem eingebunden werden:

~# mkdir /mnt/slitaz && mount /dev/hda1 /mnt/slitaz

Da bei mir das Einbinden der base-CDRom aus einem mir unerfindlichen Grund nicht klappen wollte, habe ich mir das Iso-Image manuell heruntergeladen und als loop-device eingebunden:

~# wget http://mirror.switch.ch/ftp/mirror/slitaz/iso/stable/flavors/slitaz-4.0-base.iso

~# mount -o loop slitaz-4.0-base.iso /media/cdrom

Bootkernel kopieren und Root-Dateisystem extrahieren

Boot-Verzeichnis erstellen:

~# mkdir /mnt/slitaz/boot

~# cp -a /media/cdrom/vmlinuz-* /mnt/slitaz/boot

~# cp /media/cdrom/rootfs.gz /mnt/slitaz

~# cd /mnt/slitaz

~# lzma d rootfs.gz -so | cpio -id

~# rm rootfs.gz init

~# grub-install --root-directory=/mnt/slitaz /dev/hda

title  slitaz
       root(hd0,0)
       kernel /boot/vmlinuz-2.6.37-slitaz root=/dev/hda1 vga=791

Die Option vga=791 aktiviert beim Thinkpad 600E praktischerweise den Framebuffer und stellt die Auflösung auf 1024x768x16.
Nach einem Reboot hat man (hoffentlich :-) ) ein schlankes, frisches Slitaz auf der Festplatte. Was jetzt noch fehlt ist nur noch die Audio Unterstützung.

Audio

Die Treiber für die im Thinkpad verbaute Cirrus Logic CS 4610/11 Soundkarte befinden sich im Paket hardware-thinkpad-600e-1.0, welches mittels folgendem Kommando installiert werden kann:

~# tazpkg get-install hardware-thinkpad-600e-1.0

~# tazpkg get-install alsa-lib alsa-utils

~# soundconf