X2go: Unterschied zwischen den Versionen
Boenki (Diskussion | Beiträge) K typo |
Dirk (Diskussion | Beiträge) K es gibt kein ISDN mehr |
||
(14 dazwischenliegende Versionen von 8 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
{{SEITENTITEL:x2go}} | |||
x2go erlaubt die Nutzung des eigenen Desktops von anderen Rechnern aus - sowohl im LAN als auch über das Internet. Dabei läuft die Übertragung über eine ssh-Verbindung, ist also verschlüsselt. Weiterhin wird durch die Verwendung der freien nx Bibliotheken (nomachine) eine sehr akzeptable Geschwindigkeit und Reaktionsverhalten des Desktops erzielt. | [[Bild:x2go-1.png|thumb|400px|x2go in Aktion]] | ||
x2go erlaubt die Nutzung des eigenen Desktops von anderen Rechnern aus - sowohl im LAN als auch über das Internet. Dabei läuft die Übertragung über eine ssh-Verbindung, ist also verschlüsselt. Weiterhin wird durch die Verwendung der freien nx Bibliotheken (nomachine) eine sehr akzeptable Geschwindigkeit und Reaktionsverhalten des Desktops erzielt. | |||
So kann z.B. unterwegs vom Laptop aus der heimische Desktop genutzt werden, inkl. der Umgebung, Anwendungen und der Geschwindigkeit des entfernten Arbeitsplatzes. Auch ist mit x2go problemlos der Zugriff von einer Vielzahl von Clients auf einen Rechner möglich (Terminal-Server, Thin-Client). | So kann z.B. unterwegs vom Laptop aus der heimische Desktop genutzt werden, inkl. der Umgebung, Anwendungen und der Geschwindigkeit des entfernten Arbeitsplatzes. Auch ist mit x2go problemlos der Zugriff von einer Vielzahl von Clients auf einen Rechner möglich (Terminal-Server, Thin-Client). | ||
Zeile 16: | Zeile 13: | ||
=== Installation und Konfiguration === | === Installation und Konfiguration === | ||
An Paketen wird aus dem AUR gebraucht: x2goserver und x2goclient. Und die jeweiligen abhängigen Pakete. Die Abhängigkeiten (nxcomp*, nxproxy) sind jeweils zuerst zu kompilieren. | An Paketen wird aus dem [[AUR]] gebraucht: x2goserver und x2goclient. Und die jeweiligen abhängigen Pakete. Die Abhängigkeiten (nxcomp*, nxproxy) sind jeweils zuerst zu kompilieren. | ||
* Hinweis zum Paket nxcomp: Aufgrund eines Fehlers im AUR kann dieses PKGBUILD nicht über den normalen Weg bezogen werden. Das notwendige PKGBUILD ist aber als Kommentar im Paket nxcompext vorhanden. | * Hinweis zum Paket nxcomp: Aufgrund eines Fehlers im AUR kann dieses PKGBUILD nicht über den normalen Weg bezogen werden. Das notwendige PKGBUILD ist aber als Kommentar im Paket nxcompext vorhanden. | ||
* Hinweis zum Paket x2goagent: Dieses Paket baut die Quellen eines kompletten xorg Quellpaketes, braucht aber nur Teile daraus. Der Kompiliervorgang ist trotz allem etwas umfangreicher! | * Hinweis zum Paket x2goagent: Dieses Paket baut die Quellen eines kompletten xorg Quellpaketes, braucht aber nur Teile daraus. Der Kompiliervorgang ist trotz allem etwas umfangreicher! | ||
* Weiterhin ist bei x2goagent zu beachten: Beim Kompilieren muss dieses Paket Zugriff auf die Source(scr)-Verzeichnisse der abhängigen Pakete nxcomp, nxcompext und nxcompshad haben. Diese sind ja als Abhängigkeit schon gebaut, man darf aber nicht durch makepkg den src-Tree darin entfernen lassen. In x2goagent werden SymLinks zu diesen Paketen hergestellt. Dafür müssen eben genannte Pakete im übergeordneten | * Weiterhin ist bei x2goagent zu beachten: Beim Kompilieren muss dieses Paket Zugriff auf die Source(scr)-Verzeichnisse der abhängigen Pakete nxcomp, nxcompext und nxcompshad haben. Diese sind ja als Abhängigkeit schon gebaut, man darf aber nicht durch makepkg den src-Tree darin entfernen lassen. In x2goagent werden SymLinks zu diesen Paketen hergestellt. Dafür müssen eben genannte Pakete im übergeordneten Verzeichnis vorhanden sein, also eine Struktur wie: | ||
./nxcomp/src | ./nxcomp/src | ||
./nxcompext/src | ./nxcompext/src | ||
./nxcompshad/src | ./nxcompshad/src | ||
'''./x2goagent''' (was man gerade am Bauen ist) | '''./x2goagent''' (was man gerade am Bauen ist) | ||
Nachdem nun alle Pakete gebaut sind installiert man: | Nachdem nun alle Pakete gebaut sind installiert man: | ||
'''Auf dem Server(z.B. Arbeitsplatz zuhause):''' | |||
'''Auf dem Server(z.B. Arbeitsplatz zuhause):''' | |||
x2goserver (plus Abhängigkeiten) | x2goserver (plus Abhängigkeiten) | ||
'''Auf dem Client(z.B. Laptop):''' | '''Auf dem Client(z.B. Laptop):''' | ||
x2goclient (plus Abhängigkeiten) | x2goclient (plus Abhängigkeiten) | ||
'''Konfiguration Server''' | '''Konfiguration Server''' | ||
Ein lokal funktionierenden Xserver plus Desktop(z.B. KDE) wird vorausgesetzt. Nutzbar ist vom Client aus aber auch jeder andere Windowmanager. | Ein lokal funktionierenden Xserver plus Desktop(z.B. KDE) wird vorausgesetzt. Nutzbar ist vom Client aus aber auch jeder andere Windowmanager. | ||
a) Installiere den sshd-Daemon mit: | a) Installiere den sshd-Daemon mit: | ||
pacman - | pacman -S openssh | ||
systemctl start sshd | |||
Damit der sshd beim Neustart mitgestartet wird, per systemctl einschalten | |||
systemctl enable sshd | |||
b) Das fuse Modul laden, damit vom Client aus eine | b) Das fuse Modul laden, damit vom Client aus eine Verzeichnisfreigabe(Datenaustausch) mit dem Desktop des Servers möglich ist: | ||
modprobe fuse | modprobe fuse | ||
Damit das Modul bei jedem Start geladen wird dieses bei MODULES in die /etc/rc.conf eintragen. | Damit das Modul bei jedem Start geladen wird dieses bei MODULES in die /etc/rc.conf eintragen. | ||
c) Benutzern bzw. einer Gruppe erlauben ein Programm mit Root-Rechten auszuführen: | c) Benutzern bzw. einer Gruppe erlauben ein Programm mit Root-Rechten auszuführen: | ||
pacman - | pacman -S sudo | ||
visudo | visudo | ||
Dort eintragen (als Beispiel für alle Mitglieder der Gruppe users): | Dort eintragen (als Beispiel für alle Mitglieder der Gruppe users, wenn man Postgres als Datenbank nutzt): | ||
%users ALL=(ALL) NOPASSWD: /usr/bin/x2gopgwrapper | %users ALL=(ALL) NOPASSWD: /usr/bin/x2gopgwrapper | ||
bzw. falls man SQLite nutzt: | |||
%users ALL=(ALL) NOPASSWD: /usr/bin/x2gosqlitewrapper | |||
d) Die | d) Die SQL-Datenbank initialisieren und den SQL-Server starten: | ||
Wenn man Postgres als Datenbank nutzt, muss der Daemon gestartet werden: | |||
/etc/rc.d/postgresql start | /etc/rc.d/postgresql start | ||
Nutzt man SQLite, gibt es natürlich keinen Daemon, der gestartet werden muss. | |||
Nun werden initial die x2go Datenbank und Tabellenstruktur angelegt: | |||
x2godbadmin --create | |||
Nutzt man Postgres, den Dankbankserver neustarten: | |||
/etc/rc.d/postgresql restart | /etc/rc.d/postgresql restart | ||
Und zuletzt x2goserver neu starten: | |||
/etc/rc.d/x2goserver start | /etc/rc.d/x2goserver start | ||
Damit beide Dienste beim Neustart automatisch gestartet werden, diese wieder als Daemons ein die /etc/rc.conf eintragen: | Damit beide Dienste beim Neustart automatisch gestartet werden, diese wieder als Daemons ein die /etc/rc.conf eintragen: | ||
DAEMONS=(... network ... sshd ... '''postgresql''' ... '''x2goserver''') | DAEMONS=(... network ... sshd ... '''postgresql''' ... '''x2goserver''') | ||
'''Konfiguration Client''' | '''Konfiguration Client''' | ||
Du solltest sicherstellen, dass vom Client aus eine ssh-Sitzung zum Rechner mit dem x2goserver aufgebaut werden kann: | Du solltest sicherstellen, dass vom Client aus eine ssh-Sitzung zum Rechner mit dem x2goserver aufgebaut werden kann: | ||
ssh deinusername_amServer@dein_hostname_oder_ip | ssh deinusername_amServer@dein_hostname_oder_ip | ||
Zeile 80: | Zeile 84: | ||
=== Datenaustausch vom Client zum Desktop auf dem x2go-Server === | === Datenaustausch vom Client zum Desktop auf dem x2go-Server === | ||
Im x2goclient wird lokal (Laptop z.B.) ein Ordner mit Daten "freigegeben". Dieser steht per fuse und sshfs dann am x2goserver zur Verfügung und wird dort im $Home- | Im x2goclient wird lokal (Laptop z.B.) ein Ordner mit Daten "freigegeben". Dieser steht per fuse und [[sshfs]] dann am x2goserver zur Verfügung und wird dort im $Home-Verzeichnis eingemountet, und zwar im Verzeichnis media. So können mehrere Verzeichnisse genutzt werden, z.B. um Arbeitsdaten vom Laptop am heimischen Arbeitsplatz zur Verfügung zu haben. Diese können auch "fest" eingestellt werden, so dass diese bei jeder Verbindung zum Server gemountet werden. | ||
=== Sitzung vorübergehend verlassen === | === Sitzung vorübergehend verlassen === | ||
Zeile 93: | Zeile 97: | ||
Bei Nachfragen und Problemen beim Bauen bitte im Forum fragen oder mich direkt (GerBra). | Bei Nachfragen und Problemen beim Bauen bitte im Forum fragen oder mich direkt (GerBra). | ||
== | == Weblinks == | ||
[http://x2go.berlios.de Projektseite] | [http://x2go.berlios.de Projektseite] | ||
[[Kategorie:Konfiguration]] | [[Kategorie:Konfiguration]] | ||
[[Kategorie:X11]] | |||
[[Kategorie:Netzwerk]] | |||
[[en:X2Go]] |
Aktuelle Version vom 5. Januar 2022, 14:47 Uhr
x2go erlaubt die Nutzung des eigenen Desktops von anderen Rechnern aus - sowohl im LAN als auch über das Internet. Dabei läuft die Übertragung über eine ssh-Verbindung, ist also verschlüsselt. Weiterhin wird durch die Verwendung der freien nx Bibliotheken (nomachine) eine sehr akzeptable Geschwindigkeit und Reaktionsverhalten des Desktops erzielt.
So kann z.B. unterwegs vom Laptop aus der heimische Desktop genutzt werden, inkl. der Umgebung, Anwendungen und der Geschwindigkeit des entfernten Arbeitsplatzes. Auch ist mit x2go problemlos der Zugriff von einer Vielzahl von Clients auf einen Rechner möglich (Terminal-Server, Thin-Client).
Das Paket besteht aus einem Server (x2goserver in Verbindung mit x2goagent) und der Client-Software. Auf dem Server muss der postgresql SQl-Server laufen. Clients gibt es für Linux (momentan einen QT4-basierenden Client, GTK kommt noch) und auch für Windows (Download über die x2go Homepage). Weiterhin muss der Server einen sshd zur Verfügung stellen.
x2go und Archlinux
Die notwendigen Pakete gibt es im AUR. Aktuell sind die notwendigen Bibliotheken, der Server/Agent und der qt basierende Client vorhanden. Noch nicht (aber in Arbeit) ist die LDAP-basierende Verwaltung von Benutzer, Sitzungen und Zugängen.
Auch fehlen noch ein paar Tool, die x2go interessant für Schulen bzw. ThinClient-Umgebungen machen. Aber ich arbeite daran ;-)
Installation und Konfiguration
An Paketen wird aus dem AUR gebraucht: x2goserver und x2goclient. Und die jeweiligen abhängigen Pakete. Die Abhängigkeiten (nxcomp*, nxproxy) sind jeweils zuerst zu kompilieren.
- Hinweis zum Paket nxcomp: Aufgrund eines Fehlers im AUR kann dieses PKGBUILD nicht über den normalen Weg bezogen werden. Das notwendige PKGBUILD ist aber als Kommentar im Paket nxcompext vorhanden.
- Hinweis zum Paket x2goagent: Dieses Paket baut die Quellen eines kompletten xorg Quellpaketes, braucht aber nur Teile daraus. Der Kompiliervorgang ist trotz allem etwas umfangreicher!
- Weiterhin ist bei x2goagent zu beachten: Beim Kompilieren muss dieses Paket Zugriff auf die Source(scr)-Verzeichnisse der abhängigen Pakete nxcomp, nxcompext und nxcompshad haben. Diese sind ja als Abhängigkeit schon gebaut, man darf aber nicht durch makepkg den src-Tree darin entfernen lassen. In x2goagent werden SymLinks zu diesen Paketen hergestellt. Dafür müssen eben genannte Pakete im übergeordneten Verzeichnis vorhanden sein, also eine Struktur wie:
./nxcomp/src ./nxcompext/src ./nxcompshad/src ./x2goagent (was man gerade am Bauen ist)
Nachdem nun alle Pakete gebaut sind installiert man:
Auf dem Server(z.B. Arbeitsplatz zuhause):
x2goserver (plus Abhängigkeiten)
Auf dem Client(z.B. Laptop):
x2goclient (plus Abhängigkeiten)
Konfiguration Server
Ein lokal funktionierenden Xserver plus Desktop(z.B. KDE) wird vorausgesetzt. Nutzbar ist vom Client aus aber auch jeder andere Windowmanager.
a) Installiere den sshd-Daemon mit:
pacman -S openssh systemctl start sshd
Damit der sshd beim Neustart mitgestartet wird, per systemctl einschalten
systemctl enable sshd
b) Das fuse Modul laden, damit vom Client aus eine Verzeichnisfreigabe(Datenaustausch) mit dem Desktop des Servers möglich ist:
modprobe fuse
Damit das Modul bei jedem Start geladen wird dieses bei MODULES in die /etc/rc.conf eintragen.
c) Benutzern bzw. einer Gruppe erlauben ein Programm mit Root-Rechten auszuführen:
pacman -S sudo visudo
Dort eintragen (als Beispiel für alle Mitglieder der Gruppe users, wenn man Postgres als Datenbank nutzt):
%users ALL=(ALL) NOPASSWD: /usr/bin/x2gopgwrapper
bzw. falls man SQLite nutzt:
%users ALL=(ALL) NOPASSWD: /usr/bin/x2gosqlitewrapper
d) Die SQL-Datenbank initialisieren und den SQL-Server starten: Wenn man Postgres als Datenbank nutzt, muss der Daemon gestartet werden:
/etc/rc.d/postgresql start
Nutzt man SQLite, gibt es natürlich keinen Daemon, der gestartet werden muss. Nun werden initial die x2go Datenbank und Tabellenstruktur angelegt:
x2godbadmin --create
Nutzt man Postgres, den Dankbankserver neustarten:
/etc/rc.d/postgresql restart
Und zuletzt x2goserver neu starten:
/etc/rc.d/x2goserver start
Damit beide Dienste beim Neustart automatisch gestartet werden, diese wieder als Daemons ein die /etc/rc.conf eintragen:
DAEMONS=(... network ... sshd ... postgresql ... x2goserver)
Konfiguration Client
Du solltest sicherstellen, dass vom Client aus eine ssh-Sitzung zum Rechner mit dem x2goserver aufgebaut werden kann:
ssh deinusername_amServer@dein_hostname_oder_ip
Im lokalen Netzwerk sollte das kein Problem sein. Wie du von außerhalb z.B. über das Internet eine Verbindung zum "heimischen" Rechner aufbaust ist eine Frage deines Netzwerkaufbaus. Und es würde den Rahmen des Artikels sprengen. Deshalb nur ein paar Stichworte:
- am Router/Gateway muss ein Port geöffnet werden, welcher Anfragen an diesen Port z.B. zum Arbeitsplatz und dort an den sshd-Port (i.d.R. Port 22) weiterleitet (PortForwarding). Um einen großen Teil der Portscan-Attacken auszuschließen bietet sich als öffentlicher Port statt 22 z.B. die 222 an.
- Damit man die eigene öffentliche IP-Adresse nicht im Kopf haben muss (die ja meist auch dynamisch wechselt), bietet sich ein sog. dynamischer DNS-Dienst an (DynDNS, DynIP). Meist sind die Router schon zur Aktualisierung dieses Dienstes vorbereitet, so dass der eigene Rechner zuhause immer per Namen erreichbar ist.
Jetzt aber zum x2goclient:
x2goclient
Das öffnet die Client-Anwendung. Hier können nun mehrere Sitzungen erstellt werden, auf die dann per Klick rechts zugegriffen werden kann. Jeder Eintrag besteht aus dem Anmeldenamen auf dem Server, dem Hostnamen/IP und dem Port für den ssh-Zugang. Weiterhin sind mehrere Geschwindigkeitsprofile einstellbar (von Modem bis zu LAN), ebenso welche Desktop-Umgebung auf dem entfernten Rechner gestartet werden soll.
Fallstrick: Bei KDE und Gnome nicht einfach die beiden Voreinstellungen wählen sondern "Eigene"; dort dann eintragen (für KDE): /usr/bin/startkde. Genauso kann aber auch z.B. openbox oder ein anderer Windowmanager/Desktop gestartet werden.
Nach Abfrage des Passwortes (für den Userzugang am Server) sollte nach kurzer Zeit das x2go-Logo gezeigt werden und dann der Desktop - voila!
Datenaustausch vom Client zum Desktop auf dem x2go-Server
Im x2goclient wird lokal (Laptop z.B.) ein Ordner mit Daten "freigegeben". Dieser steht per fuse und sshfs dann am x2goserver zur Verfügung und wird dort im $Home-Verzeichnis eingemountet, und zwar im Verzeichnis media. So können mehrere Verzeichnisse genutzt werden, z.B. um Arbeitsdaten vom Laptop am heimischen Arbeitsplatz zur Verfügung zu haben. Diese können auch "fest" eingestellt werden, so dass diese bei jeder Verbindung zum Server gemountet werden.
Sitzung vorübergehend verlassen
Eine weitere Besonderheit von x2go ist es, da. eine Sitzung auf dem Server quasi "suspended" werden kann. So kann eine laufende Sitzung geparkt werden und später - auch von einem anderen x2go-Client - wieder aufgenommen werden. Dabei ist es egal, woher der Client die Verbindung aufgebaut hat. So kann problemlos eine Sitzung im LAN begonnen werden und später die Verbindung z.B. vom Laptop aus einem Internet-Cafe wieder aufgenommen werden. Die Sitzungsinformationen werden dazu auf dem Server in der postgesql-Datenbank gespeichert und verwaltet. Der Prozess x2gocleansessions überwacht dabei den Status der Sitzungen.
Ausblick
Momentan besteht das Paket in Arch hauptsächlich aus dem x2goserver und dem x2goclient. In der nächsten Zeit sollen noch hinzukommen:
- Die LDAP-Anbindung. Damit können dann User, Sitzungen und Anmeldungen per LDAP verwaltet werden (z.B. für Firmen oder Schulen interessant). Dafür gibt es Control-Programme, die sich in das KDE-Systemeinstellungen integrieren.
- Der GTK-x2goclient und der Client für die Kommandozeile. Weiterhin die Option den x2goclient als Anmeldebildschirm z.B, für Thin-Clients zu nutzen.
- Die Möglichkeit lokale Geräte (CD, Floppy, USB-Stick) transparent im entfernten Desktop benutzen zu können.
Bei Nachfragen und Problemen beim Bauen bitte im Forum fragen oder mich direkt (GerBra).