lando.cc

Wenn man ein Ubuntu als vollvirtualiserte Maschine hat (z.B. wenn man eine physikalische Maschine virtualisiert hat), dann kann man es nachträglich recht einfach in eine paravirtualisierte VM umbauen. Dazu muss der Kernel passen und die Konsoleneinstellungen müssen in der VM angepasst werden. Danach werden ein paar HVM-Einstellungen geleert und der PV-Bootloader festgelegt.

1. Ubuntu Gast-Einstellungen:
1. # apt-get update && apt-get install linux-image-generic-pae
   (oder  entsprechenden amd64-Kernel)
2. # cp /etc/init/tty1.conf /etc/init/hvc0.conf
   Mit beliebigem Editor /etc/init/hvc0.conf editieren und alle vorkommenden tty1 durch hvc0 ersetzen und die Datei speichern.
3. # shutdown -P now
   Die VM herunterfahren.
2. XenServer-Einstellungen
   Auf der Konsole des XenServers müssen einige Einstellungen der VM angepasst werden
1. # xe vm-list power-state=halted
   Zeigt alle abgeschalteten VMs an. Hier die gewünschte VM heraussuchen und die UUID notieren
2. # xe vm-param-set uuid=UUID HVM-boot-policy=
   UUID durch die vorher ermittelte ersetzen. HVM-boot-policy wird ein leerer Wert zugewiesen
3. # xe vm-param-set uuid=UUID PV-bootloader=pygrub
   Der Bootloader für die VM wird auf pygrub geändert.
4. # xe vm-disk-list uuid=UUID
   Zeigt alle der Festplatte zugeordneten Festplatten an. Hier wird die UUID der VBD mit der ID 0 gesucht.
5. # xe vbd-param-set uuid=VBD_UUID bootable=true
   Diese VBD wird als bootfähig markiert
6. # xe vm-start uuid=UUID
   VM starten
3. Gasterweiterungen in der VM installieren
1. xs-tools.iso bei der VM einlegen
2. # mount /dev/xvdd /mnt
   In der VM die CD mounten (ggf. die Device- und Ordnernamen anpassen)
3. # cd /mnt/Linux; ./install.sh
   Gasterweiterungen installieren
   # dpkg -i /mnt/Linux/xe-guest-utils*i386.deb
   (oder statt i386.deb amd64.deb fuer 64bit-Systeme)
4. # sudo reboot
   VM neustarten

Nach dem Starten der VM muss man meist das XenCenter neustarten, da er sonst keine Eingabe in der Konsole der VM erlaubt.

Diese Prozedur funktioniert sowohl bei Ubuntu 10.04 als auch bei 8.04 und 8.10. Die Namen der Kernel-Images unterscheiden sich zwar hier und da, der grobe Ablauf ist aber der selbe.

Es gibt mehrere Möglichkeiten um VMs zu beenden. Der einfachste: im XenCenter ein Shut Down auslösen. Das hilft aber nicht immer, dann funktioniert meist ein Force Shut Down.

Heute hatte ich es, dass alle vollvirtualisierte VM keine Konsole mehr angezeigt hat – keinerlei Bild kam, noch nichteinmal irgendwas schwarzes. Auch auf der Konsole haben sich die VMs nicht beenden lassen. Ich bekam lediglich die Meldung, dass noch eine Operation ausgeführt wird. Auch ein xe task-list und xe task-cancel haben das nicht behoben.

Hier hat dann folgender Thread geholfen: http://forums.citrix.com/thread.jspa?threadID=274697&start=15&tstart=0. Der Thread ist zwar fuer XenServer 5.6, es trifft aber auch auf XenServer 6.0.0 zu.

Um es hier nochmal kurz zusammenzufassen:

1. VM-UUID herausfinden:
   # xe vm-list name-label=XYZ_VM params=uuid
   uuid ( RO)    : ddf7adee-13ff-85d8-d631-8287359f84dc
2. Domain-ID mittels der UUID der VM herausfinden:
   #  list_domains |grep ddf7adee-13ff-85d8-d631-8287359f84dc
   44 | ddf7adee-13ff-85d8-d631-8287359f84dc |    B H
3. Die ID 44 dann zum zerstören der Domain verwenden:
   # /opt/xensource/debug/destroy_domain -domid 8
4. Nun die VM neustarten:
   # xe vm-reboot uuid=ddf7adee-13ff-85d8-d631-8287359f84dc force=true

Wer einen Account bei OnlineTVRecorder.com hat, wird feststellen, dass der Decoder bei weitem nicht fuer alle Betriebssysteme verfuegbar ist. Eine Datei herunterladen und direkt auf dem Server dekodieren ist also nicht ganz so einfach, wenn man ein FreeBSD hat. Wie unschoen das zunaechst auch erscheint, es gibt eine Moeglichkeit den Decoder trotzdem zu nutzen: den Linux-Kompatibilitaets-Layer.

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.

Heute stand ich mal wieder vor einem interessanten Problem. Ich habe in einer virtuellen Umgebung (in diesem Falle XenServer) ein Template, dass nach dem Ausrollen in eine VM, eine 10GB Platte hat. Ich kann diese dann einfach im XenCenter vergroessern, was allerdings nur dazu fuehrt, dass das Betriebssystem in der VM, eine groessere Festplatte anzeigt. Eingebunden wird von diesem zusaetzlichen Speicherplatz nichts. Dazu bedarf es ein bisschen Abhilfe. Meine Festplatte ist im folgenden /dev/xvda, diese hat 2 Partitionen:

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

Vor ein paar Tagen habe ich das Update von WordPress-mu 2.9.2 auf WordPress 3 gemacht. Es hat erstaunlich einfach funktioniert. Eine einzige Kleinigkeit war zu beachten: Aktualisierung der .htaccess musste ich haendisch durchfuehren.

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]

Normalerweise verbreite ich ja keinerlei Rund/Kettenmails, aber – der folgende Text ist mir gestern zu Ohren und heute per Mail zugekommen. Sowas schoenes kann ich natuerlich niemandem vorenthalten:

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.

Wenn ihr hier gelandet seid, weil ihr www.deineuni-deinestimme.de aufgerufen habt, dann habt ihr euch nicht etwa vertippt – ihr seid hier goldrichtig. Dass hier nicht die Seite zu den StuRa-Wahlen erscheint, liegt an einer technischen Umstellung. Sobald der DNS-Eintrag geaendert wurde, wird unter der angegebenen Adresse auch wieder die gewuenschte Seite erscheinen. Nur mal zu statistischen Zwecken wuerde der AStA-Techniker sich freuen, wenn ihr eine kurze Mail an technik.asta@uni-rostock.de schickt, wenn euch das ganze etwas spanisch vorkommt.

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

Dieses Jahr wurde von der Fachschaft Informatik mal wieder eine Unixeinfuehrung in die Projektwoche aufgenommen, die ich letzten Freitag gehalten habe. Die Vortragsfolien finden sich im Anhang zum Download. Viel Spass damit.

Download: unixeinfuehrung2010.zip

So ab und an kommt es doch mal vor, dass ich mich von FreeBSD zu Open- oder NetBSD verirre. Dann stehe ich jedes mal vor der Frage: Verbrenne ich einen Rohling fuer die Installation oder installiere ich den Kram via Netzwerk? Meist entscheide ich mich dann fuer letzteres. Die Infrastruktur (TFTP- und DHCP-Server) ist sowieso vorhanden.

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.

Auch bei diesem Release gibt es die finalen Fedora-Images mal wieder ein kleines Stückchen früher als gewöhnlich zum downloaden: ftp://public.lando.cc/pub/linux/fedora11/.