Nachdem der Sysadminday letztes Jahr nicht ganz so stolperfrei verlief, scheint es heute ein ruhiger Feiertag der Systemadministratoren zu werden *klopfaufholz*.

Also an alle Systemverwalter da draußen: Happy Sysadminday!

Ich war selbst überrascht, als ich das vor ein paar Tagen bemerkt habe: Mittlerweile fülle ich dieses Blog seit genau drei Jahren mit allem, was mich Linux-technisch oder sonst wie besonders interessiert oder bemerkenswert erscheint.

Bemerkenswert viele Leser interessieren sich anscheinend für Xen-Server – ich werde hier wohl einmal eine eigene Kategorie anlegen und mich dem Thema vermehrt widmen.

Ich hoffe, meine Beiträge sind auch sonst interessant zu lesen, ansonsten gehe ich natürlich auch gerne auf Wünsche oder Anmerkungen ein.

Na dann stoße ich heute abend mit mir mal mit einem Gläschen Sekt auf das Jubiläum an.

Prost

Ich weiß nicht, ob ich’s hier schon einmal angemerkt habe:

Ich hasse DFS!

Vom Konzept her ist das Distributed Filesystem ja schon interessant, bietet es doch einen einheitlichen Namespace auf CIFS-Freigaben, die verteilt auf irgendwelchen Servern liegen dürfen. Auch die Replikation ist eine feine Sache.

Aber der Dienst ist sowas von störrisch. Ich kann garnicht mitzählen, wie oft wir schon Theater damit hatten.

Bei der Migration von Windows 2000 nach Windows 2008 ließ sich der Namespace auf dem neuen DC zwar anlegen, die zuvor exportieren Links ließen sich dort jedoch nicht importieren.

Entweder es hieß, der Stamm sei nicht vorhanden – dann ließ er sich aber auch über dfsutil nicht anlegen, oder es hieß, der Stamm sei zwar vorhanden, der Import-Vorgang könne jedoch nicht durchgeführt werden. Im zweiten Fall war das Löschen des Stammes über dfsutil dann wieder nicht möglich. Die Fehlermeldung, man ahnt es schon: “Der DFS-Stamm ist nicht vorhanden.”

Nach stundenlanger Recherche dann die Lösung: Der Namespace musste einmal über die AD-Domänendienste in den erweiterten Features unter “System/Dfs-Configuration” manuell gelöscht werden.

Ganz empfindlich reagiert DFS auf nicht konsistente Uhrzeiten zwischen den DCs. Auf einmal ist einfach kein Zugriff mehr auf die DFS-Freigaben möglich. Auch die Replikation versagt in diesem Fall ihren Dienst.

Ebenso bei einer vermeintlich falschen DNS-Konfiguration.

Heute das nächste Ärgernis: Ich wollte den Namespace aufräumen und verwaiste und nicht mehr benötigte Links aus dem Baum schmeissen.

Ein

dfsutil link remove \\domain\namespace\link

wird aber schlicht mit:

Der Befehl konnte nicht erfolgreich ausgeführt werden.
SYSTEMFEHLER – Die Funktion kann nicht abgeschlossen werden.

quittiert.

Eintrag in der “Ereignisanzeige”: Fehlanzeige.

Naja, dann werde ich erst einmal alle Ordnerziele manuell deaktivieren und die Freigaben zunächst umbenennen. Vielleicht findet sich ja mal eine Lösung.

Achso: Für Tipps bin ich natürlich dankbar

Interessante “Leseempfehlung“, die Udo Vetter da in seinem Blog-Beitrag “So kann’s gehen” gibt.

Sollte so einige Leute wachrütteln, die sich zu grundlegenden politischen Entscheidungen uninteressiert geben oder diesen gar – nicht hinterfragt – zustimmend gegenüberstehen.

Interessant auch die Kommentare einiger Leser zu Udos Artikel, deren geistige Begrenzung wohl noch vor den Brillengläsern anfängt.

Auf diesen Artikel aufmerksam geworden durch: Veni, Vidi, VISA

Voller Enthusiasmus nach der Migration unserer Xen-Server-Umgebung auf Version 5.5, habe ich gestern angefangen, unsere virtualisierten Maschinen zu sichern.

Das Script, das ich dazu erstellt hatte, arbeitet auch fehlerfrei.

Bis ich auf einmal auf folgenden Fehler lief:

Error code: SR_BACKEND_FAILURE_44
Error parameters: , There is insufficient space,

Eigentlich unerklärlich, eigentlich nutzen die virtuellen Kisten gerade einmal ca. 360GB der verfügbaren 500GB, es sollte also auch für größere Installationen genug Backup-Reserve auf dem Storage vorhanden sein.

Ein Blick auf die Storage-Info im Xen-Center wies dann aber aus:

499,2 GB used of 500 GB total (362,6 GB allocated)

Nicht gelöschte Snapshots konnten es nicht sein, “xe vdi-list is-a-snapshot=true” lieferte kein Ergebnis.

Eine komplette VDI-Liste brachte dann aber zum Vorschein: Jedes Backup hinterlässt zwei neue Disk-Images, auch wenn die gesicherte Instanz schon gelöscht ist. Eine enthält als Beschreibung “Base Copy” und ist Read-Only, die zweite enthält weder ein Label noch eine Beschreibung und ist ebenso Read-Only. Beide Images sind genauso groß wie das Original.

Eine Internet-Recherche ergab: Das Problem ist das “alte” Raw-Format der Platten der VMs, die vor der Migration auf den aktuellen Xen-Server angelegt wurden.

In der von Carl Fischer geposteten Erklärung unter http://bugtracker.vmd.citrix.com/browse/XSB-57 heißt es:

When you create a snapshot the original VDI (”A”) is marked as read-only, a new VDI (”B”) is created to contain the copy-on-write blocks, and third VDI (”C”) is created for the snapshot.

In the non-upgrade case the volume associated with VDI A is then resized down to its actual size on disk, ie if VDI A was 40GB but only contained 20GB of data it’s volume would be resized to 20GB. XS 5.5 does not support thin provisioning on LVM-based SRs so the volume for VDI B will be 40GB even though it only contains the writes that have occurred since the snapshot. VDI C is also a 40GB volume, but it is automatically resized down to it’s actual size on disk (8MB) since snapshots are generally read-only.

In your case because the VDI being snapshotted was upgraded from 5.0 there is an additional implication on the amount of space required in the SR. The parent VDI (A), because it was upgraded, remains of type ‘RAW’ and RAW volumes do not provide a method to determine if a block is actual data or empty. Therefore VDI A’s volume is not resized down to its actual disk space usage when the snapshot occurs.

So in the upgrade case the amount of disk space required in the SR to take a snapshot is the original VDI size x 2. A bit of additional space is required in VDI B for the VHD journaling as well so it’s actually x 2 + ~100MB for a 40GB VDI.

In the non-upgrade case a snapshot requires the size of the original VDI (for VDI B) + the journaling overhead + the amount of data actually present in the VDI prior to the snapshot (for VDI A).

[...] this is specific to upgraded VDIs in LVM SRs. VDIs created after upgrading to 5.5 will be different as described above. NFS SRs, which use file-based VHDs, will not have the provisioning constraints described above that are specific to volume-based VHDs.

D.h., ich brauche in jedem Fall ein Vielfaches der Plattenkapazitäten der virtuellen Maschinen, wenn ich meine Disk-Images noch nicht im VHD-Format habe.

Eine Möglichkeit, die vorhandenen Maschinen von RAW nach VHD zu konvertieren gibt es noch nicht, aber:

We are working on documenting a procedure to ‘convert’ volumes from RAW to VHD but do not have anything available yet.

Super. Also abwarten und Tee trinken…

Letzte Woche haben wir unsere Xen-Server-Farm auf die aktuelle Version 5.5 hochgezogen. Herausragendste Merkmale des aktuellen Virtualisierers sind imho v.a. das Workload-Loadbalancing, die “native” Unterstützung unseres SAN sowie die Möglichkeit, Snapshots von laufenden virtuellen Maschinen anzulegen.

So ist es endlich möglich, automatisiert Backups der Server anzulegen. Ich habe für unsere Umgebung ein kleines Sicherungsscript erstellt, das für einen Server einen Snapshot anlegt, aus diesem eine virtuelle Maschine generiert, und diese in einen NFS-Share wegsichert:

#!/bin/bash

### Backup einer virtuellen Maschine in NFS-Share
# $1 – Name der zu sichernden Maschine
#
# (w) 07/2009 Stefan Peters
#

PATH=/opt/xensource/bin:/sbin:/bin:/usr/bin:$PATH

# Variablen definieren
BACKUP_SHARE=server:/var/nfsshare
BACKUP_DIR=/media/backup

DATUM=$(date +%F)

logger -s “Backup VM ${1} – Backup gestartet”

# Existiert das Zielverzeichnis für den NFS-Mountpoint?
if [ ! -d ${BACKUP_DIR} ]; then
mkdir -p ${BACKUP_DIR}
fi

# pruefen, ob die NFS-Freigabe fuer die Backups gemountet ist und ggf. einhaengen
mount |grep ${BACKUP_DIR} >/dev/null
if [ "$?" -ne "0" ]; then
mount.nfs $BACKUP_SHARE $BACKUP_DIR 2>/dev/null
if [ "$?" -gt "0" ]; then
logger -s “Backup VM ${1} – Backup-Share konnte nicht gemounted werden”
exit 1
fi
fi

# pruefen, ob die zu sichernde VM existiert
xe vm-list |egrep “RW\): ${1}$” >/dev/null
if [ "$?" -ne "0" ]; then
logger -s “Backup VM ${1} – VM existiert nicht”
exit 1
fi

# Snapshot erstellen
strSnapshot=$(xe vm-snapshot vm=${1} new-name-label=${DATUM}_${1})

# Snapshot zu VM wandeln
xe template-param-set is-a-template=false uuid=${strSnapshot}

# Snapshot sichern
BACKUP_VM=${BACKUP_DIR}/${1}.xva
BACKUP_VM_OLD=${BACKUP_VM}_TMP

if [ -f "${BACKUP_VM}" ]; then
mv “${BACKUP_VM}” “${BACKUP_VM_OLD}”
fi

xe vm-export vm=${strSnapshot} filename=”${BACKUP_VM}”
if [ "$?" -ne "0" ]; then
logger -s “Backup VM ${1} – Backup fehlgeschlagen”
else
rm “${BACKUP_VM_OLD}”
logger -s “Backup VM ${1} – Backup erfolgreich abgeschlossen”
fi

# Snapshot loeschen
xe vm-uninstall uuid=${strSnapshot} force=true

exit 0

Dem Script wird als Parameter der Name der zu sichernden Maschine mitgegeben.

Wenn bereits eine Sicherung der betreffenden Maschine existiert, so wird diese zunächst umbenannt und erst nach dem erfolgreichem Abschluss der Serversicherung gelöscht.

Letzte Woche wurde ich auf Ubitquiti aufmerksam. Die Firefox-Erweiterung ergänzt den Browser um eine Art Kommandozeile, über die man auf bequeme Art eine Mail verschicken, das Wetter für einen beliebigen Ort ermitteln, Wikipedia- oder andere Online-Lexika befragen kann, u.v.m. und bildet vom Konzept her so eine Art “Online-Gnome-Do”.

Das wollte ich als sehr tastaturlastiger User natürlich gerne ausprobieren.

Als Voraussetzung für Ubiquiti 0.5 galt jedoch der aktuelle Firefox in der Version 3.5, der in Jaunty jedoch nicht enthalten ist.

Deswegen in aller Kürze der Weg, um den aktuellen Mozilla-Browser in Ubuntu zu integrieren:

Zunächst die Launchpad-Paketquellen, die bei mir als /etc/apt/sources.list.d/firefox35.list abgespeichert wurden:
deb http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main

Nachdem man diese mit:
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 247510BE
$ sudo aptitude update
in sein Paketmanagement aufgenommen hat, reicht ein simples:
$ sudo aptitude install firefox-3.5
und der Browser wird neben dem bestehenden Firefox 3.0 installiert.

Ein:
$ sudo ln -sf /usr/lib/firefox-3.5.1pre/firefox-3.5 /usr/bin/firefox
macht die aktuelle Version zum “Standard”.

Die 3.5er werkelt wirklich gut, in einigen Belangen scheint sie spürbar schneller zu arbeiten, als die Vorgängerversionen.

Einziger Wehrmutstropfen bisher:
Die Erweiterungen “Tab buttons”, “Quickproxy” und die “Ubuntu Firefox Modifications” sind nicht zum neuen Webbrowser kompatibel.

Für die “Tab buttons” gibt’s mittlerweile allerdings eine in den Mozilla-Browser integrierte Funktion “Undo Close Tab” und Quickproxy habe ich durch “FoxyProxy” ersetzt.

Und Ubiquity? Mhh – da muss ich mich wohl erst noch dran gewöhnen. Ich werde hier auf jeden Fall noch darüber berichten, ob ich das Addon bei mir produktivitätssteigernd einsetzen kann.

Von aptgetupdate.de und apfelnase.de initiiert, startet die Aktion Blogfield 2009.

Der interessierte Blogger ist aufgerufen, sich einen Avatar zu erstellen (beispielsweise aus der Simpsons- oder der Southpark-Welt) und diesen für ein “Gruppenfoto” an aptgetupdate.de zu senden.

Alles zu den “Teilnahmebedingungen”: hier

Also, mein Avatar ist schon unterwegs

Mir passiert es immer mal wieder, dass ich auf meinen Systemen als nicht privilegierter User mit dem vi Dateien zum Bearbeiten aufrufe, für die ich keine Schreibrechte besitze.

Das hieß bislang: geänderte Datei unter einem anderen Namen speichern und dann wieder mit root-Rechten an die richtige Stelle kopieren.

Das hat aber dank Christian nun ein Ende. Sein vim-Plugin sudoedit.vim erweitert den Editor um den Befehl “:SudoWrite”. Und nach Eingabe des root-Passwortes wird die Datei dann erfolgreich an ihren eigentlichen Heimatort zurückgeschrieben.

Das Plugin gibt es: hier zum Download.

Bei manchen Sachen weiß man erst, dass man sie braucht, wenn man sie dann hat…

Schick, schick, was Julius Eckert da mit Keyboardr.com erstellt hat.

Das Suchmaschinen-Interface basiert auf Ajax-Techniken und stellt schon beim Tippen des Suchstrings eine Ergebnisliste aus verschiedenen Internetdiensten zusammen. Dazu gehören neben einigen Google-Diensten (Google-Web, Google-Blog oder Google-Images) auch andere Dienste, wie die Wikipedia und Youtube.

Das Suchergebnis wird ansprechend, übersichtlich und vor allem auch richtig flott dargestellt. Genial ist die Möglichkeit, zwischen den Suchergebnissen einfach mit den Pfeiltasten zu wählen – ein Druck auf die Enter-Taste ruft den ausgewählten Sucheintrag dann auf.

Kurzes Fazit: Schick, komfortabel und schnell – so wie man sich eine Suchmaschine wünscht.