Zum Inhalt springen

Archiv

Kategorie: Linux

Ich nutze den SuSE Linux Enterprise Server 11 (SLES11) als Dom0 mit Xen 4. Aus mir bisher unbekannten Gründen (ich vermute, das Kernel-Update auf 2.6.32.13-0.4.1 ist schuld) hatte ich immer wieder Probleme beim Starten von DomU-Instanzen, vor allem dann, wenn sie per “vm-install” erzeugt wurden.

Die genaue Fehlermeldung war “Error: Device 0 (vif) could not be connected. Hotplug scripts not working.“. In der Datei “/var/log/xen/xen-hotplug.log” war außerdem zu lesen: “/etc/xen/scripts/xen-hotplug-cleanup: line 24: [: !=: unary operator expected".

Anscheinend ist an der entsprechenden Stelle im genannten Skript nun eine Variable leer, die eigentlich gefüllt sein sollte. Das Ergebnis ist nun jedoch ungültig, woraufhin das Skript auf die Nase fällt. Bis Novell ein Update zur Verfügung stellt, um den Fehler zu beheben (ich hoffe, dass Novell die Lösung beisteuert) kann man sich mit einem Workaround helfen, der darin besteht, die Zeilen 24 und 25 im Skript "/etc/xen/scripts/xen-hotplug-cleanup" anzupassen:

aus:

if [ $(xenstore-read "$vm_dev" 2>/dev/null) != "" ] \
&& [ "${path_array[1]}” = “vbd” ]; then

wird:

if [ x$(xenstore-read "$vm_dev" 2>/dev/null) != "x" ] \
&& [ x"${path_array[1]}" = "xvbd" ]; then

Damit sollte das Problem umgangen werden können. Bisher funktioniert's bei mir ohne Probleme.

 

UPDATE (20.07.2010):

Meine Xen-Umgebung lief in den letzten Tagen ziemlich wackelig. Das Starten von domU's war möglich, wenn ich allerdings eine der Instanzen stoppen oder neu starten musste, befand sie sich für ca. eine Minute im "paused"-Zustand und brach dann ab. Die Meldung war (wie gehabt) "Error: Device 0 (vif) could not be connected. Hotplug scripts not working.".

Ich habe Foren durchsucht, Manuals gelesen und diverse Mailinglisten umgegraben, doch zunächst schien nichts zu helfen, was auch immer ich versuchte.

Nun habe ich endlich das Problem für mich isoliert und "vorerst" behoben. SLES11SP1 nutzt in der Standardauslieferung für Xen das Kernelpaket "kernel-xen-2.6.32.12-0.7.1". Damit lief alles reibungslos. Dann kam vor einigen Tagen ein Kernel-Patch heraus, Version "kernel-xen-2.6.32.13-0.4.1". Und hiermit fing - wie anfangs bereits vermutet - der ganze Ärger an. Ich habe mittlerweile die Version wieder auf den Originalzustand zurück gedreht und schon funktioniert alles wieder reibungslos. Ich hatte war vor ein paar Tagen schon probiert, den Kernel zurück zu drehen, doch ich hatte auf meinem Server noch ein weiteres Problem, dass mit dem Booten von Software-RAID-Partitionen zusammen hing. Das konnte ich beheben, indem ich "mkinitrd-2.5.10-4.6.1" installierte. Ich glaube aber nicht, dass es sich hierbei um ein grundsätzliches Problem handelt... aber wer weiß. :-)

Ich habe vor Kurzem einen Linux-Server von VMware-Server auf Xen 4.0 umgestellt, inkl. Neuinstallation des Hosts. Im Nachhinein wollte ich nun einige VMware-Guests konvertieren, um diese mit Xen verwenden zu können.

Zunächst ist es hierzu erforderlich, die VMDK-Dateien mit dem beim VMware-Server beigelegten Tool “vmware-vdiskmanager” zu konvertieren. Ich hatte die Software allerdings nicht mehr installiert, wollte aber auf das Tool nicht verzichten. Da ich noch das RPM-Paket “VMware-server-2.0.2-203138.x86_64.rpm” vorliegen hatte, habe ich einfach Folgendes gemacht:

  1. Anlegen eines neuen Ordners (“/tmp/vmware”)
  2. Öffnen des RPM-Pakets im Midnight Commander (“mc”)
  3. Öffnen der enthaltenen Datei “CONTENTS.cpio”
  4. Kopieren der folgenden darin enthaltenen Dateien nach “/tmp/vmware”:
    usr/bin/vmware-vdiskmanager
    usr/lib/vmware/lib/libcrypto.so.0.9.8/libcrypto.so.0.9.8
    usr/lib/vmware/lib/libssl.so.0.9.8/libssl.so.0.9.8

Danach kann man “/tmp/vmware/vmware-vdiskmanager” nutzen, als wäre der komplette Server installiert.

Ab sofort steht das Service Pack 1 des SuSE Linux Enterprise Servers bei Novell zum Download bereit.

  • Kernel 2.6.32
  • Unterstützung für KMS (Kernel-based Mode-Einstellungen)
  • Xen 4.0
  • Unterstützung von KVM und Hyper-V
  • Verbesserungen bei Audio- und Bluetooth-Unterstützung
  • und einiges mehr

David Wong, ein Hacker aus Kanada, hat es geschafft, Linux und das Google-Betriebssystem für mobile Geräte (“Android”) auf einem Apple iPhone ans Laufen zu bringen. In einem Youtube-Video zeigt David Wong, wie ein funktionsfähiges iPhone über den Bootloader openiboot schließlich Android bootet. Es läuft fast Bug-frei, es sind jedoch Einschränkungen vorhanden, da das iPhone zu wenige Tasten besitzt. Android-Handys haben ein paar Tasten mehr, daher müssen hier Workarounds geschaffen werden.

Die Details sind in diesem Blog-Eintrag von D. Wong nachzulesen: http://linuxoniphone.blogspot.com/. Dort findet man außerdem alle zum Nachbauen wichtigen Ressourcen, wie Tools und Anleitungen. Viel Erfolg!

Nehmen wir mal an, man möchte mit seinem Linux-PC eine Dummy-Webcam, also eine virtuelle statt echte Kamera betreiben, um z.B. bei Skype Video-Clips einspielen zu können oder bei Chatroulette.com sein Unwesen zu treiben. Für solche Fälle habe ich einen Gerätetreiber gefunden und ein wenig damit herum gespielt. Das Projekt nennt sich AVLD (Another Video Loopback Device) und bietet ein Kernel-Modul, das man einbinden und für diverse Zwecke verwenden kann. Neben dem einfachen “Vorgaukeln” einer Webcam für verschiedenste Programme kann man sogar Videos auf diesem Device ausgeben. Es erscheint dem Betrachter dann wie gerade live aufgenommen.

Die Vorgehensweise:

1. Installation

Ich nutze derzeit openSUSE 11.2 (i586). Leider existiert derzeit noch kein offizielles RPM für AVLD, daher muss es von Hand kompiliert werden. Zur Vorbereitung wurden die RPMs “gcc”, “make”, “patch” und “kernel-source” installiert. Außerdem wurde natürlich die aktuellste Version von AVLD (momentan 0.1.4) heruntergeladen und entpackt.

weiter lesen…

Seit einiger Zeit hatte ich Probleme, die Webschnittstelle meines VMware-Servers (2.0.2) mit dem Mozilla Firefox zu verwenden. Gelegentlich wurde nur der Hintergrund angezeigt und das Anmeldefenster fehlte. Manchmal war die Anmeldung auch möglich, aber die Inhalte der Admin-Oberfläche wurden nicht korrekt angezeigt. Bei einem Reload bzw. Neuladen der Seite wurde häufig nur die Meldung “Fehler: Verbindung unterbrochen – Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde” angezeigt. In der Datei /var/log/vmware/hostd.log war häufig zu lesen: “SSL Handshake on client connection failed: SSL Exception: error:140D9115:SSL routines:SSL_GET_PREV_SESSION:session id context uninitialized“. Komischerweise trat der Fehler beim Konqueror nicht auf.

Nun bin ich endlich auf die Lösung gestoßen. Beim Mozilla Firefox ist es erforderlich, die Konfigurationseinstellung “security.enable_ssl2” zu aktivieren. Dazu gibt ruft man im Browser die Adresse “about:config” auf und gibt im Filter “security.enable_ssl2″ ein. In der rechten Spalte der entsprechenden Zeile steht der aktuelle Wert der Option (“false”). Durch einen Doppelklick auf die Zeile oder durch Auswählen der Aktion “Umschalten” im Kontextmenü der Maus wird die Option aktiviert (“true“).

Nach einem Neustart des Browsers sollte die Verbindung mit dem VMware-Webinterface wieder möglich sein. Die gelegentlich auftretenden Anzeige-Probleme bleiben zwar bestehen, aber die lästigen Verbindungsabbrüche scheinen damit beseitigt zu sein. Für die Rest kann ich empfehlen, im Fehlerfall den Cache des Browsers zu löschen.

Hier ein Tipp, mit dem man veraltete “mysql-bin.0000xy”-Dateien aus seiner MySQL-Installation entfernen kann. Ich habe meinen Server heute ein paar Stunden mit Anfragen beschossen. Heraus gekommen sind mehrere dieser Logdateien, einige größer als 1 GB. Und so wird man sie wieder los: weiter lesen…

Seit der Version 2.0.2 des VMWare-Servers hatte ich eine zeitlang arge Probleme, mich an meinem Windows XP Gastsystem anzumelden. Grund hierfür war, dass zunächst die Tastenkombination Strg+Alt+Entf, bzw. Strg+Alt+Einfg gedrückt werden muss, um zum eigentlichen Login zu gelangen. Merkwürdigerweise funktioniert dies bei mir unter openSUSE 11.2 und der besagten VMware-Version nicht mehr, wenn ich die Remote Console verwende.

Die Lösung: Die zu verwendende Tastenkombination ist “Strg+Alt+Druck“. Nun klappt’s wieder einfandfrei.

Es ist ein merkwürdiges Phänomen: Wenn ich mich von meinem Linux-Client (openSUSE 11.2) mit dem NX-Client von NoMachine (Version 3.4.0-5) zum FreeNX-Server (openSUSE 11.2, FreeNX 0.7.2) verbinde, fehlen mir bestimmte Key-Mappings. Bild-auf-/Bild-ab-Taste, Pfeiltasten und Tasten wie “Entf”, “Pos1″ usw. zeigen entweder keine Reaktion oder schlicht etwas völlig falsches.

Ausschlaggebend für das Problem scheint wohl das verwendete Client-Betriebssystem, denn baue ich die Verbindung über ein System mit openSUSE 11.1 auf, funtioniert alles wie erwartet. Die Behebung des beschriebenen Problems ist durch den Aufruf dieses Befehls innerhalb der NX-Sitzung möglich:

setxkbmap -model evdev -layout $LANGUAGE

also in meinem Fall

setxkbmap -model evdev -layout de

Wird dieser Befehl in die Datei “.bashrc” im Home-Verzeichnis des Users auf dem NX-Server eingetragen, wird er direkt beim Anmelden ausgeführt. Allerdings verursacht dies bei mir wieder Probleme, wenn ich mich nicht mit dem openSUSE 11.2 Client  zum Server verbinde. :-(

Es sind nur noch wenige Tage bis zur Veröffentlichung von openSUSE 11.2. Beim Testen des RC2 stellte sich nun heraus, dass der SSH daemon standardmäßig deaktiviert sein soll. Grund hierfür ist scheinbar die dadurch erreichte höhere Sicherheit. Allerdings war geplant, den Dienst bei Remote-Installationen automatisch zu aktivieren, um den direkten Zugriff auf das installierte System nicht zu verlieren. Dies scheint aber nicht umgesetzt worden zu sein. Daher wurde nun ein kritischer Bug eingestellt, der dieses Problem in letzter Minute beseitigen soll.


UPDATE:

Wie sich herausstellte, funktioniert die Technik nun doch problemlos. Bei Remote-Installationen über SSH wird der Daemon automatisch aktiviert und in der Firewall freigeschaltet. Bei lokalen Installationen wird SSH dagegen nun standardmäßig deaktiviert. Dies lässt sich während der Installation bequem ändern, indem die entsprechende Schaltfläche (s. Screenshot) verwendet wird.

opensuse-11-2-ssh-firewall

Ich würde trotzdem gerne wissen, wie viele User sich nach der Installation irritiert fragen werden, wieso der SSH-Aufruf lediglich mit “connection refused” endet… :-)


UPDATE 2:

Wenn nun das Kind bereits in den Brunnen gefallen ist, helfen die zwei folgenden Kommandos, um den SSH-Server inkl. Autostart wieder zu aktivieren:

/sbin/chkconfig -a sshd
/usr/sbin/rcsshd start

Außerdem muss SSH noch in der Firewall (falls genutzt) freigeschaltet werden. Das geht bequem über YaST oder über die Datei /etc/sysconfig/SuSEfirewall2:

FW_CONFIGURATIONS_EXT="sshd"