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.

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

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

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.

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.

Während meines Studiums komme ich nicht umhin auch mal ein wenig an Software herumzufrickeln – eine davon ist ein KSWS (komplexes SoftWare-System). Zu viert versuchen wir einen Petrinetz-Analyse-Tool aufzubohren, damit es netzwerkfähig wird. Durch den enormen Arbeitsspeicher verbrauch kommt es bei großen Netzen zu Engpässen. Dies versuchen wir dadurch zu umgehen, dass wir die einzelnen Zustände/Schaltvorgänge in einem Cluster zu verteilen, wozu OpenMPI zum Einsatz kommen sollte. Von einem Betreuer erfuhren wir dann, dass sein Nightly-Build-Script auf einem Solaris läuft. Dies stellte ihn vor das Problem, dass er nun versuchen müsste ein OpenMPI auf Solaris zur Verfügung zu stellen, was sich jedoch als schwieriger herausstellte als ihm lieb war.

pkgsrc auf Solaris

Ich habe nun schon die eine oder andere Sache mit pkgsrc zu tun gehabt – ein Paketmanagement, dass ursprünglich aus der NetBSD-Ecke kommt. Durch die enorme Portabilität läuft es auf vielen Betriebssystemen wie z.B. Windows – oder eben auch Solaris. Via CVS war pkgsrc schnell ausgecheckt (wie das geht, siehe pkgsrc-Handbuch) und dann ging das Suchen los: pkgsrc auf Solaris, ohne root-Zugriff in irgendeinen Ordner. Das pkgsrc-Handbuch half mir leider nicht viel weiter, also habe ich joerg@netbsd.org mal ein wenig dazu befragt. Er gab mir den Hinweis, dass ich nur ein –prefix beim bootstraping brauche. Der erste Versuch damit gab mir dann die Meldung, dass ich root-Zugriff brauche um durchzulaufen ODER ein –unprivileged benutze. Hier nun mal meine Konfiguration:

• pkgsrc-Tree liegt ausgepackt unter: /users/wwwstud/ug003/pkgsrc/cvs
• pkgsrc-Installation wird unter: /users/wwwstud/ug003/pkgsrc/pkgsrc liegen

Um nun pkgsrc zu installieren, wechselt man nach /users/wwwstud/ug003/pkgsrc/cvs/bootstrap und führt ein:

./bootstrap \

--prefix=/users/wwwstud/ug003/pkgsrc/pkgsrc \

--unprivileged

aus, was zumindest auf SunOS ekas 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Fire-V440 problemlos durchlief. Danach hat man eigentlich alles zur Hand, was man braucht. Was man natürlich noch beachten muss ist das, was einem pkgsrc zum Schluss des bootstraps noch als Hinweis gibt:

Please remember to add /users/wwwstud/ug003/pkgsrc/pkgsrc/bin to your PATH environment variable and /users/wwwstud/ug003/pkgsrc/pkgsrc/man to your MANPATH environment variable, if necessary.

An example mk.conf file with the settings you provided to “bootstrap” has been created for you. It can be found in:

/users/wwwstud/ug003/pkgsrc/pkgsrc/etc/mk.conf

You can find extensive documentation of the NetBSD Packages Collection in /users/wwwstud/ug003/pkgsrc/cvs/doc/pkgsrc.txt.

Hopefully everything is now complete.
Thank you

Das hoffe ich dann natürlich auch, zumal mein eigentliches Problem mit OpenMPI damit noch nicht gelöst ist, denn dies gibts nur im WiP (Work-In-Progress)-Tree von pkgsrc.

pkgsrc WiP-Tree

Den WiP-Tree erhält man ebenfalls über CVS. Die Anleitung dazu gibt es auf den sourceforge-Seiten des pkgsrc-wip projects. Danach ist der WiP-Tree bei mir dann z.B. unter /users/wwwstud/ug003/pkgsrc/cvs/wip zu finden und man kann im Ordner openmpi ein bmake install clean durchführen. Am Ende hat man dann ein laufendes OpenMPI, dass ohne root-Zugriff auskommt – hoffte ich.


==> Your Makefile has been rebuilt. <==
==> Please rerun the make command. <==
false
*** Error code 1

Stop in /usr/ports/lang/perl5.8/work/perl-5.8.9/ext/DynaLoader.
make config failed, continuing anyway...
Makefile out-of-date with respect to Makefile.PL
Cleaning current config before rebuilding Makefile...
make -f Makefile.old clean > /dev/null 2>&1
../../miniperl "-I../../lib" "-I../../lib" Makefile.PL "INSTALLDIRS=perl" "INSTALLMAN3DIR=none" "PERL_CORE=1" "LIBPERL_A=libperl.so"
Writing Makefile for DynaLoader
==> Your Makefile has been rebuilt. <==
==> Please rerun the make command. <==
false
*** Error code 1

Stop in /usr/ports/lang/perl5.8/work/perl-5.8.9/ext/DynaLoader.
*** Error code 1

Stop in /usr/ports/lang/perl5.8/work/perl-5.8.9.
*** Error code 1

Stop in /usr/ports/lang/perl5.8.
*** Error code 1

Stop in /usr/ports/lang/perl5.8.


Das fand ich dann ein wenig bedenklich. Also fing ich an zu gruebeln, was das sein koennte. Der Versuch ein frisches FreeBSD-Grundsystem zu installieren, scheiterte daran, dass irgendwelche Dateien nicht kopiert werden konnten, weil sie angeblich nicht existierten. Warum aber lief dann bitte das buildworld durch? Neuinstallieren und nochmal probiert. Aenderte nichts, das Perl brach beim selben Fehler wieder ab. Ich weiss nicht mehr genau bei welchem Befehl es war, aber irgendwann gab mir ein Kommando mal zurueck, dass das Systemdatum nicht stimmte. Bah! Widerliches Zeug, also Systemdatum korrigiert und auf ein neues Perl kompiliert – siehe da: geht doch!

Achja, fast haette ich es vergessen, zwischenzeitlich versuchte ich dann auf dem mit dem falschen Systemdatum nochmal ein aelteres Perl (5.6 oder so). Das hatte einen anderen lustigen Effekt: es hing in irgendeine Endlosschleife und erzeugte immer neue Shell/make-Prozesse.

Was es nicht alles gibt und was ein falsches Systemdatum nicht alles anrichten kann. Genug davon für heute, ich geh schlafen.