Donnerstag, 8. Oktober 2015

Auf einem entfernten Rechner das X11 DISPLAY von root auf einen normalen User umleiten (eigentlich andersherum ...)

Ich habe ab und zu das Problem, dass mich Nutzer bitten mal auf ihrem Linux-Rechner nachzusehen, warum dies oder jenes X11-Programm nicht läuft. Solange sich alles auf der Konsole abspielt, ist es easy, sobald aber grafische Tools hinzukommen, wird es schon schwieriger.

Ich habe für mich die Lösung gefunden, auf dem entfernen Rechner einen VNC-Server zu starten, der mir dann beim Start einen Xfce-Desktop bereitstellt. Die Anleitung geht hier davon aus, dass openssh, vncserver und xfce schon installiert sind.

In meinem Szenario greife ich von einem Mac OS X auf ein openSUSE Linux zu. Dies geht aber auch von jedem anderen Betriebssystem aus. In meiner Beschreibung steht 'L' für den Linuxrechner (also da wo ich hin will) und 'M' für den Mac (da wo ich herkomme). Anbei die Kurzform:

M: ssh root@L

L: vi /root/.vnc/xstartup
   
     #!/bin/sh
     dbus-launch /usr/bin/startxfce4

    :wq!

L: vncserver -geometry 1280x1024 -depth 16

M:
 

L: xhost + (als root im Terminal auf dem Xfce-Desktop)

L: su - USER

L: export DISPLAY=:1.0

L: X11-Anwendung starten


Nach dem Test:

L: exit

L: xhost -

L: vncserver -kill :1

L: exit

Dienstag, 29. Juli 2014

Skype startet ohne Sound nach Umstieg auf openSUSE 13.1

Nach einem Umstieg auf openSUSE 13.1 kann es bei manchen Nutzerprofilen passieren, dass Skype keinen Ton mehr von sich gibt. Dies lässt sich hiermit lösen:

PULSE_LATENCY_MSEC=60 skype

Einfach Skype mit diesem Kommando starten oder diese Zeile in ein Skript schreiben.

Donnerstag, 22. Mai 2014

Defekten Grub eines Software-Raids händisch reparieren

Bei einem CentOS 6.5 hatte sich durch ein Kernel-Update der Grub verabschiedet. Dies passiert immer mal wieder, wenn BIOS und Kernel eine unterschiedliche Platte an erster Stelle sehen. HD0 ist dann nicht immer gleich /dev/sda. Dann schlägt in der Regel auch ein grub-install fehl.

Per Hand klappt es so:

- Rescue-System von der ersten CD (z. B. minimal) booten
- CentOS erkennt das installierte System und bindet es als /mnt/sysimage ein
- start shell
- chroot /mnt/sysimage
- grub
- im grub: find /boot/grub/stage1
- die gefunden Platten (in der grub-Eingabe) verwenden (hier HD1,0 und HD2,0)
- root (hd1,0)
- setup (hd1)
- root (hd2,0)
- setup (hd2)
- quit
- jetzt rebooten und es sollte wieder funktionieren

Dienstag, 1. April 2014

SSH-Nagios-Zugriffsprobleme lösen

Falls Nagios-Plugins die per SSH-Verbindung auf einzelne Server zugreifen ihren Dienst verweigern, auch nachdem die SSH-Keys kopiert wurden, liegt dies meist an einem fehlenden Eintrag in der /etc/sudoers Datei.

Soll z. B. der Status des Software-Raids per SSH über den User nagios abgefragt werden, sind 2 Einträge entscheidend (mit dem Kommando visudo):

- aus Defaults: requiretty wird Defaults: nagios !requiretty
- hinzu kommt z. B.: nagios ALL=NOPASSWD:/usr/lib64/nagios/plugins/check_md_raid


Die Plugins selbst werden dann mit einem zusätzlichen sudo ausgeführt.

Mittwoch, 11. Dezember 2013

Per Shell-Script überprüfen ob ein Dienst läuft und diesen ggf. neu starten

Mit diesem kleinen Shell-Script könnt ihr ermitteln, ob ein Dienst noch läuft und falls nicht, diesen dann neu starten. Verpackt in ein Cronjob wird die Sache dann automatisiert. Getestet auf Scientific Linux 6.4.

#!/bin/sh
SERVICE='Dienst'

if ps ax | grep -v grep | grep $SERVICE > /dev/null
then
echo "$SERVICE service running, everything is fine"
else
echo "$SERVICE is not running"
/etc/init.d/$SERVICE restart
fi

Mittwoch, 20. November 2013

Einzelne Software-Raid-Platte per USB mounten

Neulich hatte ich es mit einem defekten Software-Raid zu tun und wollte die Daten retten, indem ich eine der Raid-Platten per USB mounte und dann abziehe.

Soweit so gut, allerdings ergab sich das Problem, dass sich das Linuxsystem der Platte automatisch annahm (hier: /dev/md127) und das Hinzufügen der Partition zu einem Software-Raid mir einem schnöden "is busy" quittiert wurde.

Anbei die Liste der Kommandos um die LVM-Partition (hier: /dev/sdf1) der Platte in ein eigenes Software-Raid (hier /dev/md0) einzubinden, um letztendlich ein Volume (hier: /dev/appliance/rootfs) innerhalb des LVM zu mounten. openSUSE 12.3 war hier das System der Wahl.

- cat /proc/mdstat (Anzeige der verfügbaren Software-Raids)
- mdadm --manage --stop /dev/md127 (Raid /dev/md127 stoppen)
- mdadm --assemble --run /dev/md0 /dev/sdf1 (LVM zu /dev/md0 hinzufügen)
- lvscan (LVM-Volumes sind noch inaktiv)
- vgchange -ay (LVM-Volumes aktivieren)
- lvscan (LVM-Volumes sind jetzt aktiv)
- mount /dev/appliance/rootfs /mountpoint (LVM-Volume mounten)

Mittwoch, 16. Oktober 2013

Clonezilla zerstört GRUB

Das Klonen mit Clonezilla ist eine feine Sache, allerdings sind dort manche Schalter standardmäßig nicht ganz glücklich gesetzt.

Fährt man z. B. ein Restore eines Linux-Images, kann es passieren, dass auf dem geklonten System beim Start nur noch die Grub-Eingabeauforderung erscheint.

Die Ursache hierfür ist ein Schalter in Clonezilla der den Grub im MBR neu installiert. Dieser zerschießt dann den bestehenden Grub und die Konfiguration wird nicht mehr gefunden.

Um dies zu vermeiden, muss bei der Wiederherstellung im Expert-Mode der Schalter "Reinstall grub in client disk MBR ..." abgewählt werden.

In meinem Fall handelte es sich um einen GRUB 2 und openSUSE 12.3 .