vncserver (tigervnc) unter Fedora 18 mit systemd einrichten

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (1 Stimmen, Durchschnitt: 5,00 von 5)
Loading...

Seit Fedora mit systemd ausgeliefert wird (ab Fedora 16) ist die Einrichtung des vncservers etwas anders anzugehen. Dieses HowTo soll euch die Einrichtung erleichtern. Vermutlich dürfte das auch für alle anderen Linux Distributionen gelten, welche systemd einsetzen.

Zuerst müssen wir das Paket installieren:

yum install tigervnc-server

Anschließend muss eine Datei kopiert werden, um einen passenden Start für den VNCServer zu konfigurieren:

cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:1.service

Möchte man mehrere Sitzungen starten, dann einfach weitere Kopien anlegen und die Zahl nach dem @: erhöhen.

Die nun kopierte Datei öffnen wir und editieren dann folgende Zeilen. Dort muss USER durch den Usernamen ersetzt werden, mit welchem die VNC Sitzung gestartet werden soll.

vi /etc/systemd/system/vncserver@:1.service
ExecStart=/sbin/runuser -l “USER” -c “/user/bin/vncserver %i”
ExecStop=/sbin/runuser -l “USER” -c “/user/bin/vncserver -kill %i”

Nun sollten wir den systemctl Dienst neuladen lassen, alternativ müsste man neustarten:

systemctl daemon-reload

Jetzt müssen wir das Passwort für den User vergeben, unter dem die Sitzung läuft. Folgendes Beispiel würde bedeuten, dass wir einen VNC Screen unter dem User Root oder dem User testuser laufen lassen wollen:

vncpasswd /root/.vnc/passwd
vncpasswd /home/testuser/.vnc/passwd

Das wars auch schon, jetzt können wir den Dienst starten:

systemctl enable vncserver@:1.service
systemctl start vncserver@:1.service

Aktuell gibt es unter Fedora 18 noch einen Bug, der das starten des vncservers via systemd verhindert. Den Link zum Bug finden sie hier.

UPDATE 09.02.2013:

Ohne systemd lässt sich der vncserver problemlos starten. Führen Sie dazu folgenden Befehl mit dem User, unter dem die VNC Sitzung gestartet werden soll, von der Konsole aus:

/usr/bin/vncserver :1 -geometry 1600x950

Beenden können Sie die Sitzung wie folgt:

/usr/bin/vncserver -kill :1

Nach Fedora 18 Update via yum startet gnome nicht mehr

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (Keine Bewertung vorhanden)
Loading...

Heute stand ein weiteres System auf der Tagesordnung zum Update, diesmal ein Desktop Client. Hier läuft als X-Umgebung gnome. Diese Umgebung lässt sich seit dem Update leider nicht mehr starten. Auch das Update auf den neusten Kernel brachte keine Besserung.

Aktuell habe das Gerät in den Runlevel 3 starten lassen, damit wenigstens etwas getestet werden kann. Wie das genau geht, entnehmen Sie bitte dem separaten Beitrag von uns.

Folgende Fehler tauchen im messages Log auf, das Xorg.0.log zeigt keine Auffälligkeiten:

kernel: [87.120128] gnome-session-c[1114]: segfault at c ip b739dbe4 sp bf84813c error 4 in libxcb-glx.so.0.0.0[b7394000+17000]
gnome-session[1084]: Gdk-WARNING: gnome-session: Fatal IO error 11 (Die Ressource ist zur Zeit nicht verfügbar) on X server :0.

Sobald wir dafür eine Lösung haben, werden wir das entsprechend hier veröffentlichen.

UPDATE:

Die Ursache lag wohl ein einer falschen /etc/X11/xorg.conf Datei. Nach dem ich diese entfernt habe, ließ sich einwandfrei gnome starten. VNC startet jedoch nach wie vor keine gnome Session. Hier forschen wir weiter.

UPDATE2:

Herausgefunden habe ich nun, dass der vncserver (tigervnc) nicht startet und folgende Meldung wirft:

gnome-session[1506]: WARNING: App 'gnome-shell.desktop' respawning too quickly

Der lokale X-Server startet aber sauber & problemlos, nachdem die xorg.conf entfernt wurde. Also kann es eigentlich nicht mehr viel sein. Jetzt kommt das Interessante. Startet man den VNCServer manuell, also nicht via systemd, sondern so:

/usr/bin/vncserver :1 -geometry 1600x950

Startet der VNCServer problemlos. Beenden kann man Ihn dann wieder via:

/usr/bin/vncserver -kill :1

Jetzt ist die große Frage, warum funktioniert das nicht via systemd. Ich suche weiter 🙂

UPDATE3:

So, hier haben wir nun auch den passenden Bug bei Redhat im Bugzilla gefunden. Dann ist das eigentlich nur noch eine Frage der Zeit, bis das gefixt ist. Im Archlinux Forum ist ebenfalls das Thema aufgetaucht, auch dort kann man bestätigen, dass es wohl einen Zusammenhang zu systemd gibt.

Ändern des Default-Runlevel mit systemd

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (Keine Bewertung vorhanden)
Loading...

In den älteren Linux-Distributionen, in denen noch kein systemd eingesetzt wurde, konnte man über /etc/inittab den Default-Runlevel sehr einfach ändern. Ab z.B. Fedora 15 wird systemd eingesetzt, da ist dieser Wert in der inittab überflüssig.

So wechseln Sie in Runlevel 5:

systemctl enable graphical.target

So wechseln Sie in Runlevel 3:

systemctl enable multi-user.target

rpmfusion & Fedora 18 Upgrade via yum

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (Keine Bewertung vorhanden)
Loading...

Nach dem heute das 2. System ans Update gehen sollte, scheiterten wir mit der bereits beschriebenen Methode. Grund dafür ist, dass dort die rpmfusion Repositories eingebunden sind. Wir haben folgenden Fehler erhalten:

 Could not open/read file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-18-i386

Daher sollten folgende beiden Befehle vor dem distro-sync ausgeführt werden:

yum remove rpmfusion-free-release rpmfusion-nonfree-release
yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-17.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-17.noarch.rpm

Anschließend das Update erneut starten. Nun sollte das Upgrade auch hier durchlaufen.