Admin bloggt

Aktuell haben wir einige Xen-Installationen umzuziehen. Daher hier mal eine kurze Anleitung, wie man es durchführen kann.
In unserem Fall wurde die Dom0 jeweils komplett neu installiert (vorher Debian etch, Neuinstallation mit Debian lenny). Die DomU liegt im LVM.

1. Herunterfahren der DomU:
   
   # xm shutdown hostname
   
2. Kopieren der DomU auf die neue Dom0:
   
   # dd if=/dev/vg0/hostname_domu-disk | ssh -c blowfish hostname_neue_dom0 “dd of=/dev/vg0/hostname_domu-disk”
   
3. Mounten und neue Kernel-Module hineinkopieren
   
   # mount /dev/vg0/hostname_domu-disk /mnt
   # cp -a /lib/modules/`uname -r` /mnt/lib/modules/
   # umount /mnt
4. Kopieren der DomU-Konfiguration auf die neue Dom0
5. Editieren und folgende Zeile hinzufügen:
   
   extra = ‘xencons=tty clocksource=jiffies’
   
6. Außerdem die IP-Adresse änden und den neuen Kernel eintragen:
   
   kernel  = ‘/boot/vmlinuz-2.6.26-2-xen-amd64′
   ramdisk = ‘/boot/initrd.img-2.6.26-2-xen-amd64′
   
7. DomU wieder hochfahren:
   
   # xm create /etc/xen/hostname_domu.cfg
   
8. Die /etc/networking/interfaces öffnen und neue IP-Adresse konfigurieren.
9. /etc/resolv.conf öffnen und neue Nameserver hinterlegen

Hier hat das so prima geklappt.

Wer in der DomU mehrere IP-Adressen auf dem eth0-Interface nutzen möchte (also eth0, eth0:0, etc.), der muss auch die zusätzlichen IP-Adressen in die Konfiguration der DomU aufnehmen.

Bei einer IP-Adresse sieht der Eintrag in der Regel so aus:

vif  = [ 'ip=192.168.1.1']

Bei 2 IP-Adressen dann:

vif  = [ 'ip=192.168.1.1 192.168.1.2']

Die IP-Adressen müssen also mit Leerzeichen ausgelistet werden. Ich musste ganz schön lange suchen, bis ich die richtige Syntax rausgefunden habe.

Ich hatte hier einen USB-UMTS-Stick, der beim Verbindungsaufbau unter Windows XP immer bei der “Authentifizierung” stehen geblieben ist. Manuelles Öffnen der DFÜ-Verbindung gab immer einen Fehlercode 720 zurück. Das scheint ein häufiges Problem zu sein. Es war jedoch schwer eine Lösung zu finden. Nach langer Recherche bin ich jedoch auf einen Hinweis gestoßen: das RAS-Subsystem neu installieren. Das geht am einfachsten mit dem kleinen Tool RArepair. Vielleicht hilft es auch bei ähnlichen Problemen und Fehlermeldungen mit UMTS-Sticks.

Jeder Admin kennt dies:

• Man hat ein Problem mit einem PC und möchte erstmal sicher gehen, dass man die aktuellen Treiber verwendet.
• Man installiert einen PC und hat im Geräte-Manager eine unbekannte Hardware und man weiß wirklich nicht, welcher Treiber nun benötigt wird.

Für beide Probleme gibt es eine kostenlose Lösung: Driver Easy

Die Software durchsucht alle Treiber und die Hardware im System nach möglichen Updates und stellt diese direkt zum Download und zur Installation zur Verfügung. Außerdem ist es in der kostenpflichtigen Version möglich alle aktuell installierten Treiber zu sichern.

(via)

swaks ist ein Kommandozeilenwerkzeug zum Testen von SMTP. Möchte man z.B. prüfen, ob TLS ordnungsgemäß funktioniert, hilft einem dieses einfach zu bedienende Tool. Es ist auch für viele weitere Anwendungszwecke geeignet.

Unter Debian kann man swaks auch als Paket einfach installieren (apt-get install swaks). Danach ruft man das Tool einfach über die Kommandozeile auf. Wenn man nur den lokalen SMTP-Server testen möchte, braucht man keinerlei Parameter angeben. Ansonsten bietet der Parameter –help ausführliche Beschreibungen zu den Möglichkeiten.

Möchte man z.B. den lokalen Mailserver darauf prüfen, ob TLS korrekt funktioniert, ruft man swaks mit dem Parameter -tls auf:

# swaks -tls

Die Hilfe sagt zu diesem Parameter:

Require connection to use STARTTLS.  Exit if TLS not available for any reason (not advertised, negotiations failed, etc).

Wenn man ein Update des Citrix Provisioning Server vornimmt (z.B. von 5.1 SP1 auf 5.1 SP2), dann sollte man auch auf dem Target Device das Update durchführen.
Eine Möglichkeit hierfür ist die vdisk lokal auf einen HyperV Server zu kopieren und dort eine neue VM mit dieser vorhandenen vdisk anzulegen. Hierbei kommt es jedoch manchmal zu dem Problem, dass das Target Device nach dem Deinstallieren der alten Version und dem darauf folgenden Neustart immer einen Bluescreen mit einem 7B Stopcode hat.

Abhilfe schafft folgendes vorgehen:

• Neue VM in HyperV booten
• CPS deinstallieren – NICHT neustarten
• HyperV Intergrationsdienste drüber installieren/reparieren
• Neustarten
• CPS installieren
• herunterfahren, fertig

Wiedermal einige kurze Link-Tips:

• Windows 7 Tastaturkürzel: Es ist das ein oder andere interessante Kürzel dabei, dass man sich merken sollte.
• RZ Icon Set: Für die Visualisierung von Rechenzentren gibt es hier ein schönes freies Icon Set. (via)
• Web 2.o Icons: Eine kleine Auflistung von Links für die Suche nach Web 2.o Icons.
• Atto Bench32 und HDD Speed Test Tool: 2 Tools um die Geschwindigkeit von Festplatten (lokal und im Netzwerk) zu testen. (via)
• vManage: VMware Management über das iPhone (via)
• Speccy: Von den Machern des CCleaners nun eine Software, die dir Infos zu deiner Hardware ausliest. Auch als portable Version verfügbar. (via)
• Nagios Benachrichtigungen per Push aufs iPhone: sicherlich für den ein oder anderen eine Alternative zur SMS.

Nur ganz kurz: Um das Mozilla Firefox Profil zu optimieren gibt es SpeedyFox, um das Mozilla Thunderbird Profil zu optimieren gibt es ThunderFix.

Wer die Igel Universal Management Suite für die Verwaltung seiner Igel-Thin-Client-Infrastruktur verwendet, sollte natürlich auch ein regelmäßiges Backup der integrierten Datenbank durchführen. Leider habe ich keinerlei Dokumentation zu entsprechenden Kommandozeilen-Tools gefunden, die man in Backupscripts einbauen könnte, daher hier ein Hinweis zu der vorhandenen embackup.exe:

C:\Programme\IGEL\RemoteManager\rmadmin\embackup.exe -b C:\Datensicherung\backup.embak

Wer unter Windows 2008 nur den Systemstate sichern möchte, der scheint an diesem Problem zu verzweifeln. Wenn man das Kommandozeilen-Tool wbadmin verwendet, dann funktioniert es allerdings ganz gut (auch wenn das Backup nachher doch ziemlich groß ist):

C:\>WBADMIN START SYSTEMSTATEBACKUP -backuptarget:C: -quiet

Bringt erstmal eine Fehlermeldung:

Fehler – der Speicherort für die Sicherung ist ein kritischer Volume.

Toll! Wenn man nun aber nur die eine Partition hat, macht es eventuell Sinn den Systemstate doch auf C: zu sichern und dann über einen Backupserver abzuholen. In dem Fall hilft ein Regkey-Eintrag:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\

Dort den folgenden Wert anlegen:

Name: AllowSSBToAnyVolume
Datentyp: DWORD
Wertdaten: 1