planetknauer.net

Na ja, vielleicht auch mehr als nur eines

Mit Kernel 2.6.26 ist der usbserial Patch nicht mehr nötig, da ist der usbserial-Bug endlich behoben. Damit funktioniert UMTS nun out-of-the-Box. Zu 2.6.25 kann ich keine Angaben machen, den habe ich Aufgrund von Ferien und Zwangsferien übersprungen.

Des weiteren hatte ich nun keine Geduld mehr, auf Kabel zu warten und hab mir ADSL legen lassen. Wenigstens übernimmt mein Provider die Swisscom-Zwangsabgabe. Blöd nur, dass die mir kein Modem geschickt haben. Mein Dialog mit der Hotline:
H: "Da giits ja nööööd! Wir haben Ihnen tatsächlich kein Modem zugeschickt. Haben Sie nicht zufällig ein anderes Modem rumliegen? Es kann bis 10 Tage dauern, bis Sie Ihr Modem haben."
Ich: "Ja, ich hab eins, so ein Zyxel 630."
H: "Oh je... na gut, ich werd das nun mit Ihnen zusammen einrichten."
Ich: "OK, aber Sie werden wohl grad noch mehr stöhnen, wenn ich Ihnen nun sage, dass ich nur Linux benutze."
H: "Ah, das ist super, ich benutz auch nur Linux. Aber ich glaube, für das Modem gibt's keinen Treiber..."
Ich: *frickel* *frickel*

Nach drei Stunden lief es unter Ubuntu, nach weiteren drei Stunden auch unter Gentoo. Faszinierend daran finde ich, dass es unter Ubuntu nur in einer PPP-over-ATM Konfiguration und Einwahl direkt durch pppd läuft, während es unter Gentoo nur mit PPPoE und rp-pppoe funktioniert, trotz ansonsten identischer Einstellungen.

Eher eine kleine Notiz an mich, aber vielleicht hilft's ja auch sonstwem.

Wenn das GUI von VMWare nicht startet sondern nur die Konsole mit Fehlermeldungen der Art

/usr/local/lib/vmware/bin/vmware: /usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc
_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2)

vollrotzt, hilft es, die libgcc_s.so.1 von VMWare mit der von Ubuntu zu überschreiben. Ich installiere VMWare stets nach /usr/local, d.h. ich muss folgendes ausführen:
cp -f /lib/libgcc_s.so.1 /usr/local/lib/vmware/lib/libgcc_s.so.1/

Jaja, das hat man jetzt davon, dass man Debian nutzt. Ist ja an sich eine tolle Distro, aber wenn sich die Maintainer für ach-wie-tolle-Hechte halten und Sicherheitslöcher der Kategorie "Microsoft" anfangen reinzubasteln, wird's mehr als nur nervig.

Wie auch immer, SSH-Keys sind alle ersetzt. Weitere SSL-Keys werden je nach Wichtigkeit bei Gelegenheit ausgetauscht. Das Planetknauer-HTTPS-Zertfikat ist jedenfalls vorsorglich schon wieder auf sicherem Stand.

Wenn man zwei Server mit Samba betreibt, welche beide in zwei Netzen gleichzeitig sind (eth0: Hauptnetz, öffentliche IPs; eth1: Wartungsnetz, private IPs), so führt das gerne zu massig Einträgen im Syslog, wo "martian source" Pakete angeprangert werden:

Apr 24 05:26:32 xyz kernel: martian source xxx.xxx.xxx.255 from 10.0.0.xxx, on dev eth0

Ein tcpdump -i eth0 host 10.0.0.xxx hat mir gezeigt, dass der Auslöser netbios-Anfragen, also Namensauflösungen von Samba, waren. Vermutlich bekommt er da etwas Verwirrung, wenn ein Name auf zwei unterschiedliche IPs aufgelöst werden kann.

Meine Lösung: Da Samba bei uns im Wartungsnetz nicht gebraucht wird (dort läuft alles über NFS), hab ich halt Samba bei beiden Rechnern von eth1 gelöst. Seitdem tritt das Problem nun nicht mehr auf. Vielleicht würde sich das aber auch über eine fixe WINS-Konfiguration der Server lösen lassen.

Neulich hab ich ein Email eines Bloglesers erhalten, dass der von mir hier beschriebene Patch mit dem neuen Kernel 2.6.24 nicht mehr funktionieren würde. Jedoch hatte ich bislang noch keines meiner Systeme, welches das UMTS-Modem nutzt schon so weit aktualisiert, was ich nun an meinem Gentoo-Server nachgeholt habe.
Tatsächlich haben sich ein paar Änderungen am Kernelmodul ergeben, wie mit ein kurzes diff zwischen der usb-serial.c von 2.6.23 und 2.6.24 gezeigt hat. Jedoch sollten diese nicht gravierend sein. Nichtsdestotrotz hab ich den Patch mal genauer angeschaut. In der Folge habe ich ein paar Schönheitskorrekturen vorgenommen. Der Patch liess sich nun einwandfrei anwenden und funktioniert problemlos.

Der Leser bemerkte auch noch, dass der Patch nicht in den Kernel eingeflossen sei. Nun, dazu schrieb ich schon vor Urzeiten dem Autor des Patches. Seine Antwort war, dass der Patch zwar auf der LKML eingereicht wurde, aber nicht akzeptiert wurde, da es sich nur um einen schnellen Hack handeln würde und die Kernel-Entwickler das Problem lieber sauber lösen würden. Tja, das ist nun schon einige Kernel-Releases her, aber getan hat sich diesbezüglich leider noch überhaupt nichts. Es ist zwar schön, dass gemäss Kernel-Guru Greg Kroah-Hartman unterdessen extrem viele Geräte unterstützt werden. Aber auch schlampige Unterstützung ist Unterstützung. Nur ist der User deswegen aber noch nicht zufrieden.

Zur Vervollständigung hier noch zwei Files von mir:

• USB-Serial Patch für Kernel 2.6.24


• udev-Regeln (Gentoo /etc/udev/rules.d/)

Nach einem Update von SysCP hat Apache folgende Meldung ausgespuckt:

(98)Address already in use: make_sock: could not bind to address xxx.xxx.xxx.xxx:80
no listening sockets available, shutting down
Unable to open logs
failed!

Meine Interpretation davon:
- Da horcht schon was auf xxx.xxx.xxx.xxx:80
- Apache kann seine Logfiles nicht vollmüllen.

Natürlich war nichts auf Port 80 und die Logfiles hat er trotzdem vollgemüllt.

Denn was Apache eigentlich sagen wollte:
- Mach keine redundanten Listen-Direktiven.
- Wenn du vhost-Container erstellst, schau gefälligst, dass auch alle zu nutzenden IP-Adressen im System verfügbar sind.

Grad ersteres dürfte dem einen oder anderen Updater von SysCP 1 auf SysCP 1.2 Probleme bereiten. Drum an dieser Stelle die Lösung: Einfach bei Debian Etch den Inhalt der Datei /etc/apache2/ports.conf auskommentieren. Sowas gehört eigentlich in die Update-Doku.

OK, kann natürlich sein, dass da schon eine Apache-Instanz auf 0.0.0.0:80 gestartet wurde, so dass dann der vhost xxx.xxx.xxx.xxx:80 nicht erstellt werden konnte. Natürlich wird ein netstat keine Belegung von Port 80 ausgeben, da ja die verschuldende Apache-Instanz nach Auftreten des Fehlers auch beendet wird. Von dem her ist die erste Fehlermeldung vielleicht nicht ganz falsch. Aber das mit den Logs werd ich wohl nie verstehen...

Um eine laute Festplatte zu eliminieren, habe ich mal den Versuch gewagt, Linux auf einem USB-Stick zu installieren. An sich erwies sich das als einfacher als befürchtet.

Die Hardware ist mein uralter VIA-C3 1Ghz mit 512MB RAM (abzüglich 16MB für die Grafikkarte), IDE-CD-Brenner und Laptop-Netzteil. Ehemals war da eine superlaute 60GB Platte drin, die vorherige Installation belegte etwas über 2GB also habe ich einen 4GB Stick gekauft. Dabei habe ich auf Performance geachtet, der Stick schafft gemäss Verpackung 25MB/s lesend und 18MB/s schreibend und ist Enhanced-Ready-Boost zertifiziert. Letzteres weist darauf hin, dass er zumindest minimale Performance-Anforderungen erfüllt.

Als Distribution habe ich Xubuntu gewählt, aus zwei Gründen: Erstens braucht es wenig Ressourcen, zweitens ist es blitzschnell installiert. Für eine blanke Xubuntu-Installation ohne weitere Extras würde auch ein 2GB-Stick reichen.

Das Vorgehen war recht einfach: Xubuntu starten, Stick partitionieren (wurde als /dev/sda erkannt und konnte wie eine SATA-Platte genutzt werden) und mit ext3 formatieren (der Installer bietet leider noch keine spezielle USB-Stick-Dateiformate), installieren, gut ist. Nicht vergessen, den Bootloader Grub in den Master-Boot-Record des Sticks zu schreiben
Na ja, nicht ganz. Beim Booten wird sich Grub vermutlich mit "Error 18" verabschieden. Dieser Fehler bedeutet, dass das Kernel-Image auf einem Plattenbereich liegt, der vom BIOS nicht angesprochen werden kann. Also habe ich die Installation nochmals durchgeführt und dabei zum ersten Mal bei einer Linux-Installation eine eigene Partition für /boot von 64MB Grösse eingerichtet. Und siehe, damit bootet der Rechner tatsächlich.

Da Sticks nur eine begrenzte Lebensdauer haben, da sie nur eine begrenzte Anzahl Schreibzyklen unterstützen, sollten Schreibzugriffe möglichst reduziert werden. Als erste Massnahme sollte deshalb bei der Installation auf eine Swap-Partition verzichtet werden. Der Ubuntu-Installer wird zwar meckern, aber ich weiss ja, was ich da tue. Als nächstes sollte /tmp und /var/run in eine RAMDisk gelegt werden. Dazu muss die /etc/fstab um zwei Zeilen erweitert werden:

none /tmp tmpfs auto,mode=1777 0 0
none /var/run tmpfs auto,mode=0755 0 0

Update: Ganz vergessen zu erwähnen habe ich noch eine wichtige Einstellung! Die restlichen Partitionen sollten alle mit der Option "noatime" gemountet werden. Dies verhindert, dass bei jedem Lesezugriff der Lesezeitstempel der Dateien aktualisiert und auf den Stick geschrieben wird. (Ende vom Update)

Das wär's dann schon. Jetzt muss man nur hoffen, dass der Stick bei jedem Einschalten erkannt wird (kommt sporadisch vor, dass es nicht klappt).

Die Performance ist hingegen zweischneidig: Wenn das System erstmals gebootet hat, dann rennt es ganz ordentlich (zumindest soweit es bei dieser lahmen CPU geht). Allerdings bis Grub und das Kernel-Image geladen sind, kann es sehr lange dauern. Vermutlich wird der Stick da über irgend ein langsames Low-Level-Protokoll angesprochen.

Tja, was soll man machen? Man ist Informatiker, sitzt 5-6 Tage pro Woche den ganzen Tag an der Uni, braucht also daheim selten Internet, aber brauchen kann man es eben trotzdem.
Kabelinternet wär zwar günstig. Geht aber nicht, weil die Bude bzw deren TV-Kabelinstallation zu alt ist.
DSL will ich nicht, da mir die Angebote nicht passen. CHF 25.25 für eine Telefonleitung, die ich eh nicht brauche bezahl ich schlicht nicht. Und das Angebot von Monopoly-Spieler Bluwin mit erlassender Grundgebühr ist ein schlechter Witz, wenn ich dafür erstens mein Handy-Abo upgraden und ich mich zweitens noch länger als nötig an die Swisscom binden muss (ich freu mich ja schon auf den Tag, an dem mein Abo ausläuft).
Analogmodem kommt aus Prinzip (Performance) nicht in Frage und braucht auch wieder einen Telefonanschluss.

Lösung? Söönreis (wie's eine BWL-Professorin xmal pro Vorlesung ausgesprochen hat) Mobildatenabo mit UMTS. Klappt auch prima unter Pinguin-OS.

Allerdings bringt die Leitung nach Einstöpseln und konfigurieren des Modems nur mit ca 500kbps, auch wenn eigentlich viel mehr drinliegen müsste. Ein Bisschen suchen im Internet hat mich dann zu dieser Anleitung zum Patchen des usbserial-Moduls geführt. Allerdings ist nur eine Anleitung für Kernel 2.4 dabei, das ist bei aktuellen Distributionen nicht mehr so ganz passend. Deshalb gibt's hier eine kleine Anleitung für Ubuntu 7.10 (durch anpassen der Kernel-Source-Version eigentlich auf jede Distro adaptierbar):

Erst die Kernel-Source installieren:
# aptitude install linux-source ncurses-dev && cd /usr/src && tar -jxf linux-source-2.6.22.tar.bz2 && cp /boot/config-$(uname -r) /usr/src/linux-source-2.6.22/.config && make menuconfig
Nun die Konfiguration wieder beenden (Pfeiltaste nach rechts und Enter). Jetzt geht's ans Eingemachte, den auf der soeben verlinkten Seite erhältlichen Patch einspielen. Der Patch kann z.B. als /root/usbserial.c.patch abgespeichert werden:
# cd /usr/src/linux-source-2.6.22/ && patch -Np0 -i /root/usbserial.c.patch
Nun muss das usbserial-Modul neu kompiliert werden. In der ursprünglichen Anleitung ist ein Bandwurm von gcc-Befehl drin, das klappt bei mir aber nicht. Nun, der Einfachheit halber hab ich einfach alle Module neu übersetzt. Das dauert zwar, ist aber ein zuverlässiger Weg:
# make modules
Als nächstes muss das neue Modul installiert werden (vorher besser das Original noch sichern -> Murphy ist überall):
# mv /lib/modules/$(uname -r)/kernel/drivers/usb/serial/usbserial.ko /root/usbserial.ko.old && cp drivers/usb/serial/usbserial.ko /lib/modules/$(uname -r)/kernel/drivers/usb/serial/ && update-modules
Der Befehl
# modinfo usbserial
sollte nun den neuen Parameter maxSize anzeigen.

Für mein Novatel MC950D muss der Treiber nun wie folgt geladen werden (erst muss das Pseude-CD-Laufwerk mit dem Treiber ausgehängt werden):
# eject /dev/scd1; sleep 3; modprobe usbserial vendor=0x1410 product=0x4400 maxSize=2048

Das Resultat ist beachtlich. Statt mit 500kbps bin ich jetzt mit 2.7mbps unterwegs. Also locker 5x schneller. Einzig an der Latenz hab ich noch was auszusetzen. Ping über 100ms zu den schnellsten Servern ist nicht sooo toll. Insbesondere dass kein DNS-Server in weniger als 300ms zu erreichen ist, verzögert natürlich jeden Verbindungsaufbau. Ich brauch wohl einen lokalen DNS-Cache.

Eine meiner virtuellen Maschinen "tickt" anscheinend nicht ganz richtig. Resultat davon ist eine etwas gar hohe Uptime:

# uptime
01:09:25 up 18538 days, 21:34, 4 users, load average: 0.16, 0.07, 0.50

Also rund 50 Jahre.

Infos zum System:

# date
Fri Jan 4 01:09:53 CET 2008

# uname -a
Linux gentoovm 2.6.23-gentoo-r3 #1 SMP Wed Jan 2 14:36:11 CET 2008 i686 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz GenuineIntel GNU/Linux

Die virtuelle Maschine war ein paar Tage lang "suspendiert", drum das Datum vom 4. Januar. Der Kernel wurde am 2. Januar übersetzt. Interessant, dass da über 18'000 Tage dazwischen liegen sollen.

Nachdem ich ja schon über Ubuntu 7.04 geschrieben habe, sollte ich die 7.10 nicht vernachlässigen. Nun ja, Gutsy Gibbon ist soweit ganz OK. Während ich anderweitig beschäftig war, liess ich mal den update-manager (mit Parameter -c) seine Arbeit tun und das Ding aktualisieren. Verlief soweit auch ganz gut, dauerte etwas länger als von 6.10 auf 7.04, aber das spielt nun echt keine Rolle. Nervig waren einzig die häufigen Nachfragen nach dem Vorgehen bei manuell editierten Konfigurationsdateien. Nach dem ersten Start war auch alles noch genau so wie zuvor, abgesehen davon, dass ich vom Schnellstart-Icon im Gnome-Panel das Icon für Thunderbird (den Email-Clienten habe ich unterdessen von 1337 auf Mainstream gewechselt) neu setzen musste und gkrellm für den Localhost neu verlinkt werden wollte.
OK, gmpc hat eine neue Oberfläche bekommen, die derart viel Platz braucht, dass ich grad so gut auf Listen oder AmaroK (KDE-basierende Distro vorausgesetzt... kommt wohl mit KDE 4 ) umsteigen kann. Aber sonst gibt es sich nichts. Peripheriegeräte habe ich noch nicht gross ausprobiert (kommt noch... mitsamt Begründung für den bislang ausgefallenen Test). Xinerama funktioniert weiterhin wie zuvor. Nur Pidgin macht mal wieder Probleme. Ich bin ja schon vor längerer Zeit auf einen handkompilierten Pidgin statt Gaim umgestiegen, auch mit OTR-Unterstützung. Aber unter Gutsy will das einfach nicht. Ohne OTR kein Problem, mit OTR zeigt Pidgin einfach keinen Inhalt sondern nur leere Fenster an (was heissen soll: leere Kontaktliste, beim Hinzufügen neuer Accounts eine leere Liste unterstützer Protokolle und beim Auswählen von Plugins alles grau unterlegt abgesehen von OTR). Na gut, mal ein paar Updates abwarten, ansonsten gibt's halt Pidgin für ein halbes Jahr ohne Privatsphäre.

Als nächstes kommt das Update auf meinem Bürorechner. Und als gaaaanz langfristiges Ziel ist die Migration aller Mitarbeiter auf irgendwas ABM (Anything But Microsoft) weiterhin gesetzt, wobei Ubuntu, manchmal zurecht auch Klickibuntu genannt) ganz gute Dienste leisten könnte. Und Freunde und (Sauf-)Kollegen die Migriert werden wollen habe ich auch noch genug. Schon openSuSE oder OSX wär mir ja recht... Ihr müsst nicht mal ins kalte Wasser springen. Von flüssigem Helium (-273°C -> Windows) zu gefrorenem Kohlendioxid (-56°C -> OSX) wär mir ja schon recht. Kaltes Wasser geht nach meiner Definition übrigens unter 25°C los (in den See spring ich schon ab 20°C...). Also los. Linux-Distributionen haben etwa 26°C erreicht

Es geht nichts über gute Dozenten, die logische, gut strukturierte, vollständige und korrekte Unterlagen anbieten. Ich repetiere grad die Materialen einer Vorlesung über Unix. Selten so viel Blödsinn auf einem Haufen gesehen:

Zitat:

Der Pfadname ist eine Zeichenkette, die zur Lokalisierung einer gegebenen Datei
innerhalb des Dateisystems dient. Der Pfadname kann entweder relativ oder absolut sein:

• Absoluter Pfadname beginnt mit einem Schrägstrich (/). Ein einfacher
  Schrägstrich wird zur Bezeichnung des Wurzelverzeichnisses verwendet.


• Relative Pfadnamen beziehen sich immer auf das sogenannte laufende

Verzeichnis. Laufendes Verzeichnis ist dasjenige auf das der betreffende Benutzer
gegenwärtig Bezug nimmt.

• Hauptverzeichnis (Home-Verzeichnis, Login-Verzeichnis). Beim Anmelden erhält
  der Benutzer automatisch dieses Verzeichnis als das laufende Verzeichnis.

/etc/mount /dev/dsk1 /lib

OK... Aber wieso kommt nun mitten im Abschnitt über das Mounten von Dateisystemen plötzlich ein Satz über das Login-Verzeichnis? Natürlich kann man login und mount über pam_mount kombinieren und dynamisch das Homeverzeichnis beim Login mounten. Aber pam_mount ist definitiv nicht Teil von Unix-Grundlagen, pam wird glaub überhaupt nicht angegschaut...
Wieso /etc/mount? In /etc liegen Konfigurationsdateien, keine Programme, lieber Dozent. Und eine Erklärung, was diese Zeile bedeuten soll, wär auch nicht all zu übel.

Jeder Benutzer enthält eine Benutzeridentifikation (uid), die den Zugriff auf Dateien
festlegen. Es gibt zwei Benutzeridentifikatoren, den effektiven uid und den realen uid.

Mööööööööp! Jeder Prozess erhält eine reale und eine effektive UID. Dateien erhalten genau eine UID. Ausser man verwendet ACL, aber das ist wieder ausserhalb des Rahmens der Vorlesung.

Der Superuser (Root) zeichnet sich dadurch aus, dass für ihn die normalen
Schutzmechanismen nicht gelten. Er ist in der Lage, alle Dateien und Kataloge zu lesen,
zu modifizieren, zu löschen und deren Attribute zu ändern.

Schön und gut, aber jetzt wär's noch gut, wenn auch erklärt würde, was ein Katalog ist, statt nur mit neuen Begriffen wild um sich zu werfen.

Diese Stilblüten sind auf grad mal zwei Seiten von etwa zweihundert noch durchzuarbeitenden. Weg mit dem Grüntee, her mit dem Whisky...

Wie versprochen hier mein nächster Microsoft-Hass-Beitrag. Die Firma kotzt mich echt nur noch an.

Problem Nummer eins ist bzw war technischer, womöglich aber auch politischer Natur. Vor einiger Zeit ist im Büro plötzlich der Druckserver vermeintlich ausgestiegen. Als Druckserver agiert ein Debian-Server mit CUPS und Samba, als Clients etwa 35 Rechner mit Windows XP SP2, ein paar Macs und meine Linux-Workstation. Nun funktionierte das Drucken mit OSX und Linux weiterhin, nur mit Windows gabs ein kleines Problem: Nach absenden des Druckauftrags hing erstmal das Programm, woraus gedruckt werden sollte. Ansonsten passierte nichts weiter So nach 30 Minuten bis 2 Stunden wurde dann der Auftrag gedruckt und das Programm reagierte wieder. Inzwischen geschah gar nichts, keine Netzwerkaktivität, keine Prozessbewegungen, einfach nichts. Weder auf Client noch auf Server. Nun, wir haben als Notlösung eine Windows-Workstation als Printserver eingerichtet, was abgesehen von der beschränkten Anzahl Verbindungen funktionierte. Dann hab ich mich wieder Samba gewidmet und bis zur Verblödung dran rumgebastelt, ein neues Samba aufgesetzt... Resultat: Nix. Zwei Stunden warten bis es druckt. Ich war schon kurz davor, Microsofts Lügen über die TCO von Linux und Windows zu glauben. Doch mit einem frisch installierten XP SP2 ohne weitere Updates klappte Drucken perfekt. Also musste sich der Fehler irgendwann über ein Windows-Update eingeschlichen haben. Danke, Microsoft.
In der Microsoft-Knowledge-Base (das ist diese unübersichtliche Wissenssammlung mit den maschinell "übersetzten" Texten) fand ich dann das: http://support.microsoft.com/?scid=kb%3Ben-us%3B909987&x=18&y=11. Aha, schön. Das Problem ist bekannt. Ein Hotfix existiert. Aber der Hotfix ist nicht öffentlich erhältlich sondern nur gegen Bares. Wenigstens hat die Uni einen Supportvertrag, so dass ich den Fix darüber anfordern konnte. Eingespielt, den erforderlichen Reboot (ha ha ha) gemacht und siehe da, jetzt druckt es wieder.

Meine Einschätzung: DAS ist Absicht. So lässt man durch bewusst eingebaute Fehler in den Client-Systemen die eigenen Server in besserem Licht dastehen als die Konkurrenzprodukte. Aber da der Fehler bei Microsoft liegt und er nur kostenpflichtig behebbar ist, müsste die TCO-Berechnung wohl nochmals neu durchgeführt werden. Ja, ich denke, dass ich jetzt all meinen Mitarbeitern Linux oder OSX aufzwingen werde. Deren Wirtschaftlichkeit überzeugt einfach mehr.


Problem Nummer zwei ist wiederum rein politisch und wird erst in Zukunft technisch. Ohne es gross ausbreiten, aber was Microsoft da bei den Standardisierungsgremien abzieht, passt ja wohl auf keine Kuhhaut. Da gibt's nur eins: Boykott!
So zwängt man nämlich sogenannte "Standards" mit finanzieller Macht durch:
WOZ: Kuscht die Schweiz vor Microsoft?
Computerwoche: Microsoft manipuliert weltweit Office-Standard


Alles in allem gibt's sowieso nur eine Lösung für Rechner mit installiertem Windows:

Teeren, Federn, Aufhängen. Wenn Microsoft Wildwest-Methoden mag, nun, nur zu. Ich kenne die auch.

So, das wars. Meine Familie ist ab sofort befreit von den Fessen von Microsoft. Mein Vater hat heute Morgen sein neues MacBook entgegennehmen dürfen, womit die "Sklaverei" zu Ende ist. Abgesehen von dieser OSX-Maschine läuft alles andere mit Linux.

Oh ja, Windows ist so toll. Ich habe als letzte Tätigkeit als Familien-Windows-Administrator die Daten per USB-Stick rüberkopieren wollen. Schön: Windows musste ab meinem 2GB grossen USB-Stick fast 10 Minuten rattern und die Festplatte strapazieren, bis der Stick endlich als neues Laufwerk erkannt wurde. Zwischenzeitlich wurde das CD-Laufwerk noch neu erkannt und ein inexistentes USB-HID-Device eingerichtet. Und ausserdem wurde zweimal nach dem Admin-Passwort gefragt. Das ist sehr performant, effizient und anwenderfreundlich.

So, und bevor wieder jemand versucht aufgrund veralteter Mythen zu lästern: Nein, Microsoft hält keine Aktien von Apple mehr. Die 1997 gekauften Anteile für 150 Mio USD wurden bereits vor Jahren (mit Gewinn) wieder verkauft.

Die LUGS (Linux User Group Switzerland) hat diesen Sommer die Patenschaft für einen Königspinguin übernommen. Logisch, schliesslich ist der Pinguin ja auch das Wappentier von Linux. Und als Mitglied der LUGS bin ich somit indirekt Pate von einem dieser Schwimmvögel. Neulich hab ich's endlich mal geschafft in den Zürcher Zoo zu gehen, da war der Besuch im Pinguinhaus natürlich obligatorisch. Ich hab zwar nun keine Ahnung, welcher von den putzigen Kleinen denn nun zu mir gehört, aber witzig sind die Viecher allemal.

Heute bin ich nun endlich zum Upgrade meines Hauptrechners gekommen.

Da mir der Platz auf der / Partition ausgegangen ist, habe ich bei diesem Rechner eine Neuinstallation von Ubuntu 7.04 Feisty Fawn gemacht und dabei die alte, seit Monaten nie wieder gebootete Gentoo-Installation zur Platzbeschaffung geopfert.

Der erste Eindruck: Begriffsstutzig. Man muss ihm alles zweimal sagen, damit es klappt.
Der zweite Eindruck: Schnell. Extrem schnell.
Der dritte Eindruck: Ein paar Dinge nerven schon jetzt

Aber kurz der Reihe nach. Direkt nach Erscheinen der Final-Version habe ich per Bittorrent die Live- und die Alternate-CD per Bittorrent (huuu, ganz schön kriminell, diese Linuxer. Nicht?) heruntergeladen (beide x86).
Heute Mittag habe ich dann mit der Installation angefangen, d.h. zuerst mal die / Partition in ein tar-Archiv gesichert und dann mal von der Alternate-CD gebootet. Die Partitionen umgestellt, neues Software-RAID gebastelt, installiert. Soweit alles sehr einfach, unkompliziert. Reboot, Spannung. Doch soweit mal ein Fehlschlag: Grub meldet Fehler 22. Aha gut. Danke. Also mit der Live-CD gebootet. Doch siehe da, beim Start der grafischen Oberfläche gibt's kein Bild. Der per VGA angeschlossene TFT meldete "out of Range" und der per DVI angeschlossene brachte nur ein verzerrtes Bild. Reset gedrückt und nochmals probiert. X startet einwandfrei. Komisch, aber mir soll's recht sein. Also die Sache mit dem Bootloader mal inspiziert. Letztendlich habe ich ein chroot mit der Installation auf der Platte gemacht und von dort aus den Grub manuell in die MBRs beider Platten installiert. Reboot und läuft perfekt ab Festplatte. Aber alles in allem tönt das nach Bug...
Nun angefangen einzurichten. Kein Netzwerk. Hmmm OK, /etc/network/interfaces auf statisch umgestellt, eth0 mehrfach von Hand versucht zu konfigurieren... eth0 war zwar da, liess sich aber keine IP geben. ifconfig eth0 192.168.0.8 gab jeweils ein OK zurück, machte aber doch nix. Letztendlich das Forcedeth-Modul entladen und neu geladen. Siehe da, jetzt klappt's auch mit dem Netzwerk.
Nun das TwinView wiederhergestellt. Wenn man zwei Monitore hat, sollen die auch richtig genutzt werden. Also erstmals das proprietäre nvidia-Modul installiert, xorg.conf angepasst, X gestartet. Fehlermeldung: Kann das nvidia-Modul nicht finden. Aha. Installation überprüft. Wieso auch immer, aber das nvidia-glx-Paket war nicht installiert (aber mit pi gekennzeichnet, was auch immer das heissen mag). Nun, ein zweites aptitude install nvidia-glx hat das Paket dann endgültig raufgehauen und X liess sich einwandfrei starten.
Als nächstes X beendet, die /etc/fstab angepasst, so dass ich mein altes /home zurückbekomme, die NFS-Shares vom Server eingerichtet und zum Testen neu gestartet. Klappt perfekt.
Nun noch eine Tonne Programme nachinstalliert, schon läuft's.

Zeitaufwand: etwa 2 Stunden. Etwas länger als fürs Upgrade meines Büro-PCs (1h15 oder so, aber der hat auch eine direkte 100MBit Anbindung an den Switch-Mirror ), aber durchaus vertretbar

Nun kurz zu den Macken:
Mein Scanner ist Opfer des USB-Suspend geworden und funktioniert nicht mehr.
Sylpheed motzt, dass das IMAP-SSL-Zertifikat nicht verfiziert werden könne, da Handsigniert. Mehr Sicherheit ist ja schön, aber dann wäre eine Möglichkeit, das Zertifikat direkt zu importieren nicht übel.
GAIM hat gelegentlich Stockungen. Nun ja, hoffentlich unterstützt Gajim bald OTR, dann fliegt GAIM eh raus