Vorbereitungen

• FreeBSD-Installation sollte man hinbekommen haben
• Linux Kompatiblitaetslayer installieren (Anleitung aus dem FreeBSD-Handbuch)

Installation

Statisches Binary

Nun, da das FreeBSD installiert ist, kann man das Linux-Binary des Decoders herunterladen. Den gibt es auf den Seiten des OTR im Linux-Bereich (Link zu den OTR-Downloadseiten). Dort gibt es diverse Linux-Versionen. Zunächst habe ich es mit der einfach statisch gelinkten Version ausprobiert. Das ging soweit auch, allerdings konnte er nie zum Server verbinden um die OTR-Datei zu dekodieren. Ich habe immer den selben Fehler erhalten, wie er auch im OTRForum zu finden war: ”No Connection to Server”. Kein warum oder wieso… es geht schlicht nicht.

Statisch gelinktes Binary funktioniert also gar nicht.

Dynamisch gelinktes Ubuntu-Binary

Nächster Versuch erschien mir eigentlich unnötig, aber weil das ausprobieren ja schnell gemacht ist, habe ich dann doch noch das Ubuntu-Binary geladen und ausprobiert. Damit lief das Dekodieren der OTR-Datei problemlos. Wirklich installieren muss man den Decoder auch nicht. Es reicht das tar.bz2 auszupacken und die Datei otrdecoder auszufuehren (natuerlch mit den entsprechenden Parametern).

Welche der dort angebotenen Versionen funktionieren denn schlussendlich? Probiert habe ich insgesamt drei Versionen:

1. Dekoder (Statisch gelinkt): funktioniert nicht
2. Dekoder (Dynamisch gelinkt (Ubuntu Gutsy)): funktioniert
3. EasyDecoder (Konsolenversion, 32bit – Ubuntu 8.04): funktioniert.

Die 64bit Varianten habe ich nicht weiter getestet, nachdem die 32bit Versionen liefen.

1. /dev/xvda1 - 512MB Partition fuer /boot, ext2 als Dateisystem
2. /dev/xvda2 – etwa 8.5GB grosse Partition fuer LVM (enthaelt root und swap)

Um das ganze nun umzubauen, damit /dev/xvda3 mehr als nur diese 8.5GB hat, sondern auch den restlichen freien Platz nutzt, sind folgende Schritte notwendig:

Notwendige Software

Auf einem debian brauche ich dazu: gpart (enthaelt sfdisk) und lvm2:

aptitude install gpart lvm2

Werte bestimmen

Bestimmen der Start- und Endwerte der zu aendernden Partition:

fdisk -u -l /dev/xvda

Das gibt folgende Ausgabe:

Disk /dev/xvda: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b41d0

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1   *        2048      999423      498688   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/xvda2          999424    23066623    11033600   8e  Linux LVM

Werte berechnen

Die Ausgabe von dem fdisk-Aufruf eben enthaelt alle notwendigen Angaben. Sowohl den Anfangs- als auch den Endwert. Der Anfangswert ist die 999424 (siehe auch das Device xvda2) und der Endwert ist die Sektor der Platte 41943040. Die Groesse der Partition muss berechnet werden: Sektorzahl der Platte minus Anfangswert – in meinem Bespiel also 41943040 – 999424 = 40943616

Partition vergroessern

Das eigentliche Vergroessern erfolgt mit sfdisk:

sfdisk --force -uS -N2 /dev/xvda

An der Kommandozeile von dem Programm dann erst den Startwert (999424) und die Groesse (40943616) angeben, mit Enter bestaetigen und dann noch die Aenderung mit y bestaetigen.

Die Partitionsgrenzen sind damit verschoben und um diese Aenderungen vollstaendig zu uebernehmen, muss die Maschine neugestartet werden.

PV und LV vergroessern

Die Partition ist jetzt auf volle Groesse gebracht, nun erfolgt das Vergroessern der ganzen LVM-Geschichten:

1. Physical Volume vergroessern:

   pvresize /dev/xvda2

   Mit pvdisplay kann man die Aenderung kontrollieren.

2. Die Volume Group sollte jetzt ebenfalls vergroessert sein. Kontrolle erfolgt ueber: vgdisplay. Hier kann man dann ebenfalls sehen, wieviel Speicherplatz jetzt auf dem Volume frei ist.
3. Logical Volume vergroessern:

   sudo lvextend -l +100%FREE data/root

Dateisystem vergroessern

Als letztes wird dann noch das Dateisystem angepasst und auf die maximale Groesse aufgeblasen. In meinem Beispiel ist es ein ext3. Das Vergroessern dauert… je nach Groesse eine ganze Weile:

resize2fs /dev/data/root

Fertig. Kontrolle erfolgt ueber df -h. Wenn hier jetzt die neue Festplattengroesse erscheint, ist alles glatt gelaufen. Am besten aber nochmal die Maschine neustarten, damit man sicher ist, dass nicht irgendwo ein kleiner Fehler ist. Gegebenenfalls ist sogar ein Filesystemcheck sinnvoll. Dieser sollte nicht auf einem gemounteten Dateisystem durchgefuehrt werden, sondern beim naechsten Neustart ablaufen. Dazu muss die Datei /forcefsck angelegt werden:

touch /forcefsck

Die Datei wp-contents/blogs.php ist als veraltet markiert und kann im Laufe des Updates geloescht werden. Danach funktionierten dann in meinem gesamten Blognetzwerk die eingebundenen Dateien nicht mehr. Eine Aenderung an der .htaccess hat geholfen: Hier wurde die Zeile:

RewriteRule ^(.*/)?files/(.*) wp-contents/blogs.php?file=$2 [L]

in folgendes geaendert:

RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L]

In Deutschland hat sich die Qualität der Pkw- und Lkw-Fahrer deutlich verschlechtert. Aus diesem Grund hat das Straßenverkehrsamt ein neues System eingeführt, um die schlechten Fahrer zu identifizieren.

Mit sofortiger Wirkung werden allen Fahrern, die sich im Straßenverkehr unangemessen verhalten – unter anderem durch plötzliches Anhalten, zu dichtes Auffahren, Überholen an gefährlichen Stellen, Abbiegen ohne zu blinken, Drehen auf Hauptstraßen und rechts überholen – Fahnen ausgehändigt. Sie sind rot, mit einem schwarzen Streifen oben und einem gelben Streifen unten. Dadurch sind sie für andere Verkehrsteilnehmer als unfähige Autofahrer zu identifizieren. Diese Fahnen werden an der Autotür befestigt und müssen für alle anderen Verkehrsteilnehmer gut sichtbar sein.

Die Fahrer, die eine besonders schwache Leistung gezeigt haben, müssen je eine Fahne auf beiden Seiten ihres Autos befestigen, um auf ihre fehlende Fahrkunst und ihren Mangel an Intelligenz aufmerksam zu machen.

Desweiteren prüft das BMVBS in einem Feldversuch auch die Ausgabe der gleichen Zeichen als Rückspiegelkappen.

Bitte an andere Verkehrsteilnehmer weiterleiten, so dass alle die Bedeutung dieser Fahnen verstehen.

Die Ausgabe beginnt mit sofortiger Wirkung.

Die Seite zu den StuRa-Wahlen der Uni Rostock findet ihr hier: http://wahlen.stura.uni-rostock.de

Download: unixeinfuehrung2010.zip

Gestern war wieder so ein Versuch ein NetBSD5 auf eine Kiste zu buegeln. Es war bei NetBSD mal so, dass es einen extra Installations-Kernel gab. Da brauchte man lediglich die pxeboot-Datei, die dem DHCP-Server hingeworfen wurde und eben diesen Installation-Kern. Mitlerweile hat sich aber eine Kleinigkeit geaendert, denn es wird nur noch der GENERIC-Kern und eine Ramdisk (miniroot.kmod) benoetigt um ins NetBSD-Setup zu gelangen. Um diese Veraenderung zu verstehen bzw. um herauszubekommen, wie es nun tatsaechlich geht, habe ich eine ganze Weile gebraucht. Das NetBSD-Handbuch schweigt sich darueber aus.

Schritt 1: TFTP-Server

Der Anfang dieser Installation ist wie gehabt. Man startet einen TFTP-Server, der die Dateien pxeboot_ia32.bin (fuer NetBSD5 zum Beispiel hier herunterladbar) und kern-GENERIC.tgz (Download hier) ausliefert. Darueber hinaus braucht man mitlerweile noch die entsprechende Ramdisk: miniroot.kmod (gibts hier zum herunterladen)
Unter FreeBSD wuerde das etwa so aussehen: Zunaechst werden die Dateien heruntergeladen und in /tftpboot abgelegt.

cd /tftpboot
fetch ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-5.0/i386/installation/misc/pxeboot_ia32.bin
fetch ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-5.0/i386/binary/sets/kern-GENERIC.tgz
fetch ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-5.0/i386/installation/miniroot/miniroot.kmod

Nun muss noch der TFTP-Server in /etc/inetd.conf aktiviert werden. Dazu wird das Kommentarzeichen vor der Zeile

#tftp    dgram   udp     wait    root    /usr/libexec/tftpd      tftpd -l -s /tftpboot

entfernt. Danach kann man dann entweder ein inetd_enable=”YES” in /etc/rc.conf unterbringen und mittels /etc/rc.d/inetd starten, oder aber man fuehrt einfach ein /etc/rc.d/inetd forcestart aus. Beides fuehrt auf jeden Fall dazu, dass der inetd gestartet wird.

Schritt 2: DHCP-Server

Einen laufenden DHCP-Server vorausgesetzt, sollte ein kleiner Eintrag reichen. Ich selber habe einen isc-dhcpd am laufen, den ich um folgende Zeile im Subnet-Bereich der dhcpd.conf ergaenzt habe:

filename "pxeboot_ia32.bin";

Danach noch den DHCP-Server neustarten (/usr/local/etc/rc.d/isc-dhcpd restart) und alles sollte soweit funktionieren.
Sicher koennte man auch der Einfachheit halber einen Eintrag fuer die entsprechende MAC-Adresse machen, aber ich hatte diese gerade nicht zur Hand, als ich den DHCP konfiguriert habe. Sie stand schlichtweg nicht auf dem Device drauf. Also habe ich einfach als globale Einstellung das pxeboot eingetragen. Da sollte man vielleicht noch dran denken das wieder zu deaktivieren. Ansonsten koennte es irgendwann mal komische Ueberraschungen geben, wenn ploetzlich einige Rechner versuchen ein NetBSD aus dem Netz zu booten.

Schritt 3: Rechner installieren

Nun fehlt eigentlich nur noch eine Sache, die da waere, den Zielrechner zu installieren. Dazu wird er ganz normal angeschlossen und gestartet. Sofern er pxeboot-faehig ist und dies auch aktiviert ist (das ist rechnerabhaengig), sollte der NetBSD-pxeboot kommen. Dort hat man 5 Sekunden lang Zeit die Leertaste zu druecken. Nachdem das erfolgt ist, braucht man eigentlich nur noch zwei Befehle:

load tftp:miniroot.kmod
boot tftp:kern-GENERIC.tgz

Falls man noch Einstellungen mittels userconf machen will, kann man hier noch ein -c anfuegen: boot tftp:kern-GENERIC.tgz -c.

Soweit so gut, sollte eigentlich funktionieren und den Rechner ins Setup booten lassen.

Zusammen mit Andreas habe ich die Ueberlegungen in Software umgesetzt. Normalerweise war der Einsatz von Drupal als Content-Management-System gedacht, was sich aber relatig schnell wieder erledigt hat. Die Zeit war einfach zu knapp, als das wir uns ausreichend mit der Drupal-API haetten beschaeftigen koennen. Entsprechend dessen wurde alles selber geschrieben, viele Inhalte mussten statisch eingepflegt werden. Aber fuer die kurze Zeit (etwa ein bis zwei Wochen), ist das ganze doch recht ansehnlich geworden. Zumindest die Administration der Parteien, Fragen und Antworten ist ueber ein Webinterface auch fuer andere Leute moeglich.

Insgesamt ist uns da eine recht gut aussehende Seite (Danke an dieser Stelle an Michael Schultz fuer das Layout) gelungen, die technische Umsetzung ging schnell und relativ schmerzlos. Wir waren sehr puenktlich fertig. Montag, 18.05.2009 15:30 wurde die Geschichte vorgestellt. 15:35 waren wir mit den letzten wirklich gravierenden Aenderungen fertig, die uns erst im laufenden Betrieb aufgefallen sind.

yum -y update yum
yum clean all
yum -y update glibc
yum -y update

Nun noch das Plesk-Update durchwuergen – das gabs dann gestern Nacht. Sonst hatte ich ja bei jedem groesseren Plesk-Update eher mit Problemen zu kaempfen. Aber diesmal hat auch das erfreulicher Weise funktioniert. Man sollte sich lediglich die Updateanweisung einmal genauer anschauen. Diese ist auf den Parallels-Seiten zu finden. Das Greylisting funktioniert wunderbar und spart auf meinem Server einiges an Ressourcen an. DNS-Blacklisting ist zwar gut und schoen, bringt aber nicht immer sonderlich viel. Ich denke, dass die Kombination aus DNSBL und Greylisting sehr lange und gut funktionieren wird.