Auf einem oVirt 3.2.1 Setup hatte ich ein seltsames Problem: Es konnte keine VM mehr von CD-ROM (ISO Image) booten. Im oVirt Admin Portal wurde nur eine nichtssagende Fehlermeldung angezeigt. Also habe ich auf dem oVirt Engine Server einen Blick in das engine.log geworfen und bekam eine bessere Meldung zu sehen:
2013-04-29 16:38:33,744 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-9) Received a cdrom Device without an address when processing VM 658ca53d-12cf-4b03-973d-a0d2cdf5315f devices, skipping device: [...]
OK, also irgendetwas gefällt oVirt scheinbar an der CD-ROM Konfiguration nicht. Im Admin Portal ist nichts Auffälliges zu finden… Also auf dem oVirt Node Server mit virsh -r (Kommandos list + dumpxml) noch einen Blick in die VM Konfiguration werfen:
<disk type=’file’ device=’cdrom’>
<driver name=’qemu’ type=’raw’/>
<source startupPolicy=’optional’/>
<target dev=’hdc’ bus=’ide’/>
<readonly/>
<serial></serial>
<boot order=’1′/>
<alias name=’ide0-1-0′/>
<address type=’drive’ controller=’0′ bus=’1′ target=’0′ unit=’0′/>
</disk>
Und tatsächlich: oVirt hat definitiv kein ISO Image eingebunden. Also kein Wunder, dass die VM nicht von CD-ROM booten kann. Auf der oVirt Mailingliste wusste leider auch niemand Rat. Also habe ich die betroffene oVirt Node kurzerhand in den Maintenance Mode gesetzt und – einige Minuten später – wieder aktiviert. Und siehe da: Plötzlich kann wieder problemlos jedes ISO Image eingebunden und davon gebootet werden. Die Ursache für diesen Fehler ist zwar weiterhin unklar, aber immerhin ist die Funktionalität vorerst wiederhergestellt.
Um Informationen aus einem bereits vorhandenen Certificate Request (CSR) auszulesen, genügt folgendes OpenSSL Kommando:
openssl req -noout -text -in test.csr
Die Ausgabe enthält dann neben dem Public Key auch die bei der Erstellung eingegebenen Daten:
Data:
Version: 0 (0×0)
Subject: C=DE, ST=Bavaria, L=Munich, O=Example Inc., OU=IT, CN=test.example.com/emailAddress=testuser@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
…
Unter oVirt kann es vorkommen, dass eine VM nicht eingeschaltet werden kann. Im oVirt Frontend erscheint dann folgende Meldung:
Cannot run VM. Host swap percentage is above the defined threshold. – Check your configuration parameters for Host Swap Percentage.
Offensichtlich benutzt unsere oVirt Node, auf der die VM gestartet werden soll, bereits zu viel Swap. Mit top sieht man dann wahrscheinlich, dass nur wenig Swap verwendet wird und die RAM-Auslastung gar nicht so hoch ist. Also warum dann diese Meldung? Wir schauen uns auf dem oVirt Engine Server einmal die Einstellung für dieses Limit an:
# engine-config -g BlockMigrationOnSwapUsagePercentage
BlockMigrationOnSwapUsagePercentage: 0 version: general
In der Standardeinstellung darf bei oVirt gar kein Swap in Benutzung sein, damit das Starten einer VM möglich ist. Also kein Wunder, dass früher oder später wohl jeder diese Meldung erhält, denn auch auf großzügig dimensionierten Systemen wird irgendwann mal ein wenig Swap verwendet. Diese Einstellung ist geradezu extrem konservativ - und für meinen Geschmack um Größenordnungen zu niedrig eingestellt. Deshalb ändern wir sie auch gleich:
# engine-config -s BlockMigrationOnSwapUsagePercentage=90 –cver=general
# service ovirt-engine restart
Wichtig: Nach dem ändern der Einstellung muss der oVirt Engine Dienst neugestartet werden (wie im obigen Beispiel). Ab sofort wird erst bei 90% belegtem Swap-Speicher der Start weiterer VMs verhindert. Eine Übersicht der Konfigurationsoptionen findet sich übrigens in der offiziellen Dokumentation zu RHEV 3.1.
203f
Mit folgenden Schritten kann ein LVM2 Volume online vergrößert werden. Wobei “online” hier etwas irreführend sein könnte, denn in den meisten Fällen muss der zusätzliche Speicherplatz zuvor in Form einer weiteren Partition hinzugefügt werden – und das erfordert voraussichtlich einen Reboot. Das Dateisystem selbst wird dann im Betrieb – also “online” – vergrößert.
Diese Anleitung wurde unter CentOS 6 erstellt, sollte jedoch auf den meisten Linux-Distributionen nahezu identisch durchführbar sein.
Warnung: Bei derartigen Vorgängen besteht die Gefahr eines Datenverlusts! Sie sollten vorher unbedingt eine Datensicherung durchführen!
Hinweis: Einige Werte sind farblich gekennzeichnet und müssen den aktuellen Gegebenheiten angepasst werden.
- neue Partition anlegen
- fdisk /dev/sda
- mit fdisk eine neue primäre Partition im freien Speicherplatz anlegen (und den Namen merken, z.B. sda3)
- den Partitionstyp auf “Linux LVM” ändern
- wahrscheinlich ist danach ein Reboot des Servers nötig
- LVM Physical Volume hinzufügen
- pvcreate /dev/sda3
- mit pvcreate die neue Partition als Physical Volume zu LVM hinzufügen
- danach mit pvdisplay überprüfen
- LVM Volume Group vergrößern
- mit vgdisplay die aktuelle Volume Group anzeigen (und den Namen merken, z.B. VolGroup)
- vgextend VolGroup /dev/sda3
- die Volume Group mit vgextend vergrößern
- mit vgdisplay überprüfen, ob die korrekte Größe angezeigt wird
- LVM Logical Volume vergrößern
- mit lvdisplay die Logical Volumes anzeigen (und den Namen merken, z.B. lv_home)
- lvresize -L +60G /dev/VolGroup/lv_home
- mit lvresize das Logical Volume auf die gewünschte Größe erweitern
- mit lvdisplay überprüfen, ob beim Logical Volume die korrekte Größe angezeigt wird
- Dateisystem vergrößern
- mit df -h die aktuelle Dateisystembelegung anzeigen lassen
- resize2fs /dev/mapper/VolGroup-lv_home
- mit resize2fs das EXT4 Dateisystem online vergrößern (es wird automatisch auf die maximale Größe erweitert)
- mit df -h überprüfen, ob das Dateisystem die korrekte Größe anzeigt
Natürlich gibt es auch an anderen Stellen im Netz gute Anleitungen zu diesem Thema.
Nach der Migration eines alten Webservers von PHP 5.2 auf PHP 5.3 funktionierte eine uralte PHP-Anwendung nicht mehr. Sie verweigerte den Dienst mit folgender Meldung:
mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication. Please use an administration tool to reset your password with the command SET PASSWORD = PASSWORD(‘your_existing_password’). This will store a new, and more secure, hash value in mysql.user. If this user is used in other scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag from your my.cnf
Das ist natürlich ein alter Hut. Wir einnern uns: Mit MySQL 4.1 wurde ein neues sichereres Passwortformat eingeführt. Das war lange Zeit kein Problem, denn auf einem neuen MySQL Server konnte seither mit der Option old-passwords die Unterstützung für das alte Format beibehalten werden.
Und mit PHP 5.3 endete die Unterstützung für das vorherige unsichere Passwortformat. Offenbar endgültig, denn der Zugriff funktioniert weder mit mysql noch mit mysqli (obwohl dies von manchen als Lösung angegeben wird).
Also muss jeder in den sauren Apfel beißen und das fragliche Passwort neu setzen, genauso wie es die PHP-Fehlermeldung bereits vorgeschlagen hatte:
SELECT user, Length(Password) FROM mysql.user WHERE user=’username’;
UPDATE mysql.user SET Password=PASSWORD(‘altesPasswort’) WHERE user=’username’;
SELECT user, Length(Password) FROM mysql.user WHERE user=’username’;
FLUSH PRIVILEGES;
Der Zugriff mit PHP 5.3+ sollte ab sofort möglich sein.
262c
Irgendwann kommt der Tag, an dem die RRDs (von Cacti, Munin, MRTG, Nagios, usw.) auf einen neuen Server übertragen werden müssen. Wenn sich dabei noch die Architektur von 32-Bit auf 64-Bit ändert, kommt auf dem neuen Server beim Zugriff auf die RRDs eine Fehlermeldung:
ERROR: Cannot tune logfile: This RRD was created on another architecture
Was nun? Da hilft nur der klassische Dump & Restore. Also zuerst von jeder RRD auf dem alten Server einen Dump erstellen:
rrdtool dump filename.rrd >filename.xml
Die Dumps dann auf den neuen Server kopieren und dort in eine neue RRD einspielen:
rrdtool restore filename.xml filename.rrd
Fertig. 
Ich habe dieses Problem bereits selbst unter FreeBSD 8.3 beobachtet: Während der Erstellung eines Dateisystemsnapshots, zum Beispiel bei der Verwendung von dump, kommt es zum totalen Stillstand. Das System läuft zwar noch, aber die Festplattenaktivität kommt vollständig zum erliegen. Nichts hilft, bis auf einen Reset der Maschine.
Das Beste was ich dazu finden konnte, war dieser Thread auf der freebsd-current Mailingliste von Anfang 2012. Leider führte diese Diskussion nicht zu einem Bugfix und es betraf FreeBSD 9 im Kontext des neuen SU-J Features.
Kürzlich berichtete jemand auf der freebsd-stable Mailingliste von einem ähnlichen Problem unter FreeBSD 8-STABLE. Diesmal wurden verantwortliche Committer darauf aufmerksam und es gab einen Bugfix im FreeBSD Repository. Aktuell gibt es also noch keinen offiziellen RELEASE, bei dem dieser Bugfix bereits enthalten wäre. Mit etwas Glück, wird es einen Backport dieser Lösung für FreeBSD 8-STABLE oder 9-STABLE geben. In kritischen Situationen könnte man den Patch natürlich selbst für den gewünschten FreeBSD-Release anpassen.
Unter Windows 7 gibt es mehrere Probleme, die dazu führen, dass Windows Update nicht mehr funktioniert. Deshalb gibt es inzwischen von Microsoft schon länger das Fixit Tool, um die üblichen Reparaturen automatisiert durchzufühen.
Bei einem Acer Notebook hatte ich jetzt ein Windows Update Problem, bei dem alle üblichen Reparaturversuche erfolglos waren. Zur Situation: In dem Notebook wurde die 500 GB Festplatte durch ein 750 GB Modell ersetzt. Zu diesem Zweck wurden die Daten mittels CloneZilla auf das neue Gerät gespiegelt. Das funktionierte vollkommen problemlos.
Danach war Windows Update allerdings kaputt, obwohl sonst alle installierten Programme fehlerfrei arbeiteten. Da Windows Update ohne aussagekräftige Fehlermeldung den Dienst verweigerte und auch in der Ereignisanzeige nichts Brauchbares zu finden war, folgte eine längere Google-Session. Aber die üblichen Lösungsansätze halfen hier nicht weiter.
Dann bin ich zufällig über dieses Post in einem Forum gestolpert. Darin behauptet ein Nutzer namens humprey, dass ein veralteter Intel Rapid Storage Technology Treiber die Ursache für das Problem ist. Eine einfache Aktualisierung dieses Treibers soll das Problem sofort beheben. Das fand ich ein wenig absurd: Was soll der Treiber des SATA-Controllers mit dem Windows Update Dienst zu tun haben?
Doch ziemlich viele User bestätigten, dass ein Update bei Ihnen geholfen hat. Noch dazu wird in dem Post auf einen Supportartikel von HP verwiesen, der genau dieses Problem mit größeren Festplatten beschreibt. HP bietet auch gleich einen neuen Treiber in Version 9.5 zum Download an, in dem es das Problem nicht mehr geben soll. Da ich keine halben Sachen machen wollte, habe ich gleich die neueste Version 11.7 von Intel heruntergeladen und installiert. Das Ergebnis: Unglaublich – Windows Update lief sofort wieder völlig problemlos.
Und was lernen wir daraus? Toyota hatte damals eben doch Recht – “Nichts ist unmöglich!”.
32bd
Sometimes you cannot simply delete a file or a directory. It fails with an error indicating that this operation is not permitted. In my example I tried to cleanup an old tinderbox build:
# rm -rf tinderbox/7.3_freebsd_i386/
rm: tinderbox/7.3_freebsd_i386/bin/rcp: Operation not permitted
rm: tinderbox/7.3_freebsd_i386/bin: Directory not empty
rm: tinderbox/7.3_freebsd_i386: Directory not empty
It is obvious that tinderbox uses special file flags to protect the build. Since I want to delete it anyway, I don’t need to find out which flag is set und must be unset. So I just unset all flags:
# chflags -R 0 tinderbox/7.3_freebsd_i386/
Finally the old build directory can be deleted.
In einem Shell-Script war diese Funktion von `date` gerade sehr nützlich: Mittels einer Option kann man ausgehend vom aktuellen Datum beliebig weit zurück in die Vergangenheit gehen.
# heutiges Datum (nett formatiert)
> date +”%Y-%m-%d”
2011-12-06
# 1 Tag zurück
> date -v-1d +”%Y-%m-%d”
2011-12-05
# 1 Jahr und 3 Monate zurück
date -v-1y -v-3m +”%Y-%m-%d”
2010-09-06