knarfs Weblog

Nachdem die Meldung verfrueht schon bei Heise und Golem zu lesen war, was zu diverser Kritik fuehrte, nun auch hier: Vor etwa 24 Stunden wurde FreeBSD 8.0-RELEASE offiziell veroeffentlicht.

Fuer die Ungeduldigen gibt es die Highlights, fuer die Interessierten mit etwas Zeit zum Lesen: Die kompletten Release Notes. Darin sind auch die Aenderungen gegenueber 7.1 und 7.2 zu finden.

FreeBSD 8.0 macht Spass. Ich habe die letzten Tage, seit dem 8.0-RELEASE im cvs tree getagt war, damit verbracht die Maschinen in meinem Umfeld auf 8.0-RELEASE zu bringen. Zuerst die, die zum Test in einer voellig unwichtigen VMWare irgendwo rumduempelten, teilweise mit einem ueppig installierten ports-tree, um auch das Verhalten von den anstehenden portupgrade -f Massenaufrufen beurteilen zu koennen. Aber da war nichts.

Der eben erst aufgesetzte Kundenserver mit 8.0-RC3 machte das Update erwartungsgemaess problemlos mit.

Fuer den speziellen Fall, dass jemand lagg(4) zusammen mit em(4) verwendet: Es funktioniert nicht. Ich musste die schoenen Intel-Karten echt gegen Realtek-Schrott austauschen und schon war wieder alles beim alten. Der FreeBSD-Intel-Treiber wird von Intel persoenlich entwickelt. So aendern sich die Zeiten. Dranbleiben. Das muss eigentlich sofort in die ERRATA.

Fuer AMD-Xen-User: Das noetige Tuneable fuer AMD-Xens heisst hw.clflush_disable=1.

Spannend finde ich die Tatsache, dass die Verteilung des Interesses von i386 (32bit) und amd64 (64bit) im FreeBSD Torrent Tracker gleich verteilt erscheint.

Die aelteren unter uns mag interessieren, dass COM1: jetzt /dev/cuau0 heisst. Die Zeiten von mgetty, uucico und pppd sind leider lange vorbei. Wir haben jetzt uart(4) statt sio(4). Ob man nun einen 16550 oder einen 16550A hat, interessiert lange keinen mehr. Ich verwende tatsaechlich noch den apcupsd ueber die Serielle.

FreeBSD 8.0 ist das erste FreeBSD in dem der ZFS-Support nicht mehr als experimental gekennzeichnet ist (quasi seit dem Import von zfsv13). Ich habe ZFS in v6 mit unterdimensionierter Hardware (i386, wenig RAM, bisschen Gefummel an den tuneables) getestet und habe nicht zuletzt durch nicht ganz gewolltes Fehlverhalten ein desastroeses Ergebnis produzieren koennen. Seit v13 habe ich zwei amd64-Maschinen mit ausreichend RAM (8 und 16 GByte) mit zfs im Einsatz und es macht seit Wochen im Produktivbetrieb keinerlei Aerger. Snapshots werden intensiv genutzt: zfs-snapshot-mgmt ist ein toller port, aber auch das gute alte freebsd-snapshot laesst sich problemlos parallel einsetzen. Ohne wenigstens eines der beiden moechte ich am liebsten kein Unix-System mehr betreuen, anstaendig konfigurierte Snapshots (mit mount via amd, ich sage nur cd /snap/home:daily.0) sind echt ein Segen.

Da ja nun fdisk und mbr bald (also in ein paar Jahren oder so) ausgedient haben werden, ist dies nun auch der richtige Zeitpunkt, um sich mit gpt auseinanderzusetzen. Vor dreieinhalb Jahren kam ich mit meinem 2.4TiB 3ware-RAID5 zum ersten mal in die Verlegenheit. Da hiess das FreeBSD-Kommando noch gpt(8). Nun ist es gpart(8). Es wird die Zeit kommen in der man regelmaessig Festplatten mit >2TiB in den Haenden hat.

Ganz aktuell gibt es eine schoene Anleitung um FreeBSD mit gpt, zfsroot und ganz ohne ufs-Partition zu installieren: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot

Die ganze Aktion ist gewiss nichts fuer Leute mit einer Kommandozeilenaversion. Es bleibt abzuwarten wie lange es benoetigt, bis der aufgezeigte Pfad seinen Weg in sysinstall findet. Ich habe die Schritte nachvollzogen und habe nun in einer weiteren VMWare-Instanz ein GPT-ZFS-only-FreeBSD-8.0-RELEASE. Diese Installationsmethode koennte ich problemlos auf einem Hetzner-Server mit Hilfe des FreeBSD-Rescue-Systems durchfuehren. Bei 1&1 bleibt immer noch nur die Holzhammermethode: VMWare-Minimal-Disk-Image via ssh | dd auf die Platte schreiben und hoffen, dass es von der hoffentlich korrekt konfigurierten Seriell-Console bootet. Das mbrlabel kann man unter FreeBSD problemlos mit fdisk(8) auf die tatsaechliche Groesse aendern. Dass das auch mit gpart(8) geht, ist anzunehmen, aber mir liegen hierzu keine Erfahrungen vor...

Seit etwa 15 Jahren signiere ich nahezu alle meine E-Mails. Damals noch mit PGP/MIME seit wenigen Jahren mit S/MIME. Die Resonanz war immer sehr gering. In der PGP-Zeit regten sich vor allem Outlook-Express-User darueber auf, dass meine E-Mail-Inhalte immer nur als TXT-Anhang dargestellt wurden. Schuld ist da natuerlich OE (bis heute), aber irgendwann wurde mir das zu dumm und ich besorgte mir ein Class2-Zertifikat von StartCom und verwendete fortan S/MIME.

Vor zwei Monaten hat es das Stammzertifikat von StartCom in den Microsoft-Container geschafft, es koennen nun also nicht mehr nur Thunderbird-User die Echtheit meiner E-Mails ueberpruefen, sondern auch Outlook-Express- und Outlook-User. So ganz ohne Konfiguration, es funktioniert einfach. Toll!

Aber jetzt kommt's: Ich bin Kunde bei der comdirect Bank. Die bisherige Kommunikation verlief reibungslos. Ich rief an, man sagte mir ich solle einen Brief schreiben, ich schrieb einen Brief, man rief mich wieder an und erklaerte mir, dass alles bald erledigt sei. Heute versuchte man mich wieder (ohne Rufnummernuebermittlung) anzurufen, leider vergeblich. Sie entschlossen sich also dazu, mir eine E-Mail zu schreiben in der man mich bat mein Anliegen des Briefes erneut per Post vorzubringen. Ich antwortete also per E-Mail, dass ich es fuer wenig sinnvoll erachte nochmal einen Brief zu schreiben, in dem ich das selbe schreiben wuerde wie im ersten Brief. Doch nun kommt's:

Date: Mon, 2 Nov 2009 17:28:30 +0100
Subject: RE: Geblockt: Re: Depotwerte / Auflösung des Depots

Sehr geehrte Damen und Herren,

vielen Dank für Ihre E-Mail.

Ihre an uns geschickte E-Mail war mit Anhängen versehen und wurde
daher aus Sicherheitsgründen nicht angenommen.

Wir bitten Sie, die E-Mail nur im Textformat nochmals an uns zu
senden und auf die Anlagen zu verzichten.

Sollten zur Klärung des Problems Screenshots oder Anlagen notwendig
sein, so senden Sie uns diese bitte per Fax an die Nummer
04106 - 708 1923 zu.


Mit freundlichen Grüßen                                                         

M. H. [Name auf ausdruecklichen Wunsch unkenntlich gemacht]
Technische Hotline
Tel.: 01803 - 33 64 40 
Fax : 01805 - 33 64 55 **
E-Mail: support@comdirect.de

 EUR 0,09/Min. aus dem Festnetz der Dt. Telekom / Mobilfunkpreise ggf. abweichend
** EUR 0,14/Min. aus dem Festnetz der Dt. Telekom / Mobilfunkpreise ggf. abweichend
[...]

Natuerlich liess ich mir nicht nehmen, der technischen Hotline zu erklaeren wie sinnfrei ich es finde, ordentlich signierte E-Mails aus Sicherheitsgruenden abzulehnen. Ich bekam rasch folgende Antwort (natuerlich ohne References: oder In-Reply-To: - aber was will man von "JavaMail" schon erwarten?).

Sehr geehter Herr Bartels,

vielen Dank für Ihre E-Mail. 

Eingehende Mails werden durch unsere Sicherheitssoftware
automatisiert geprüft. Jegliche Inhalte die nicht automatisiert
geöffnet und geprüft werden können und oder Inhalte die
Ausführbar sind werden abgelehnt. 

Da wir via E-Mail keine Aufträge entgegennehmen ist die
Notwendigkeit einer Signatur nicht gegeben. Wir bitten Sie
Ihre Anfrage erneut zu stellen. 


Mit freundlichen Grüßen

Christian Sperling
Technische Hotline
[...]

Tja, zwei Sturkoepfe treffen aufeinander und nichts geht vorwaerts. Zum Glueck ist es mir voellig egal ob sie meine E-Mail lesen, denn die Sinnhaftigkeit der Kommunikation war schon vor dem Kommunikationskanalwechsel auf E-Mail nicht mehr gegeben.

Update 05.11.2009: Heute schicken Sie mir doch tatsaechlich einen Brief mit der Bitte meinen Brief noch einmal zu schicken. Naja, nicht ganz, sie bitten mich ein Formular auszufuellen, ich soll den Inhalt meines ersten Briefes dort eintragen. Mache ich natuerlich nicht, wo kaemen wir da hin?

Update 06.11.2009: Heute kommt noch ein Brief in dem sie mir bestaetigen alles erledigt zu haben (und zwar ohne dass ich einen zweiten Brief schreiben musste). Und es steht sogar explizit dabei, dass ich mich melden solle, wenn mir etwas daran nicht gefaellt. Hurra! Manchmal hilft Geduld.