staging.inyokaproject.org

Moin,

nur mal eben schnell aus der Mittagspause gemeldet:

Unter Windows ist diese Funktion als Remotedesktop...

? Bei mir ist unter der Windose der Remotedesktop das RDP-Protokoll welches einen Terminalserver auf der Gegenseite erwartet!

Ist das ein "Fehler" oder fasst man (meines semiprofessionellen Wissens nach NICHT) beides (VNC+RDP) unter RDP zusammen?

Max-Ulrich Farber schrieb:

und da es ja ein Wiki ist vor allem für Anfänger und nicht nur für Profis.

Wobei man "Anfänger" und "Profi" noch präzisieren müsste. Der größte Teil des Wiki richtet sich wohl an "Mittelklasse-Benutzer", die zwar keine Anfänger mehr sind, aber eben auch keine Profis.

Du meinst Semiprofessionelle wie mich, die keine 25 Befehle mehr brauchen; ich richte mein System mit nur einem Befehl hin 😀

Deshalb bin ich dafür, Wiki-Artikel – soweit möglich - nach einem 3-Stufen-Schema aufzubauen: Erst eine Einführung für Anfänger, worum es überhaupt geht, evtl. mit einem simplen "Howto". wie man das Ding schnell zum Laufen bringt. Dann der "Hauptteil" für die Mittelklasse mit verständlichen Erklärungen und nötigenfalls auch Belehrungen, und schließlich noch, möglichst weit am Schluss, weitere Hinweise für Profis. Ein solcher Aufbau geht natürlich nicht immer, er soll deshalb auch nicht zum starren Schema werden.

• Lösung

• Erklärung

• Vertiefung

Ich kopiere erst stumpf die Befehle ab bis das "Problem" gelöst ist, danach in aller Ruhe schauen "was macht welcher Befehl warum".... und danach fange ich an zu spielen um es zu lernen/zu begreifen ☺

sollte am Anfang dieses Artikels vielleicht eine Übersicht stehen?!

+1, ist ganz in diesem Sinne.

..dann mache ich mal weiter mit Vino am Wochenende ☺

* Lösung

* Erklärung

* Vertiefung

So kann man es ausdrücken. Was noch dazu kommt, ist die schrittweise Veränderung der Zielgruppe: Die "Lösung" soll wirklich für Anfänger verständlich sein, die "Erklärung" kann so formuliert sein, dass das "Mittelfeld" sie versteht, und in der "Vertiefung" ist die Verwendung einer gewissen Fachsprache nicht mehr vermeidbar.

Gruß und schönes Wochenende – Max-Ulrich

Max-Ulrich Farber schrieb:

Mit dem Auslaufen von Ubuntu 10.04 kann dann auch der Abnschnitt "Drag&Drop funktioniert nicht (10.04)" entfernt werden. In 12.04 ist auch dieser Bug gefixt.

Erledigt.

Aktuell steht da Falls der Host hinter einer Firewall (z.B. einem Hardware-Router) steht, muss der entsprechende TCP-Port (also z.B. 5900) weitergeleitet werden.. Ich kann mit dieser Formulierung aber Nachts nicht schlafen, am 30c3 gab es ja so ein schönes Video mit den ganzen öffentlich erreichbaren VNC Diensten. Da sollten wir unsere Anwender nicht auf blöde Ideen bringen, können wir das mit dem Portforwarding vielleicht einfach unterschlagen?

mfg Stefan Betz

Hallo,

unterschlagen = den Satz / Abschnitt ersatzlos streichen? Oder wie ist die bessere / sichere Alternative?

Gruß, noisefloor

Die ggf. gewünschte Erreichbarkeit habe ich zwischenzeitlich als Anlaß für eine Portweiterleitung mit aufgenommen.

noisefloor schrieb:

Oder wie ist die bessere / sichere Alternative?

SSH oder OpenVPN.

mfg Stefan Betz

Moin! Im Abschnitt VNC (Abschnitt „Reverse-VNC-Verbindung-ueber-SSH-Verbindung“) steht, die Verbinung könne mit

1
2

ssh -f -L 5500:localhost:5500 hilflos@IP-ADRESSE-HELFER sleep 10
x11vnc -connect_or_exit localhost:5500 

aufgebaut werden. Erst dachte ich es funktioniert einfach nicht und habe reichlich viel Zeit mit der Recherche in anderen Foren/Anleitungen und lesen der Manpages verbracht (die einen anderen Ansatz verfolgen nämlich:

1

ssh -t -L 5900:localhost:5900 far-host 'x11vnc -localhost -display :0' 

, welcher leider ebenfalls nicht funktionierte. Letzlich hab ich mich den Befehlen hier aus dem Wiki immer weiter angenähert, bis es die selben waren, welche lediglich durch ein && verbunden wurden. Anscheinend war einfach die Zeit zu kurz gewählt. Gerade, wenn eine Person noch nicht viel Erfahrung im Umgang mit der Konsole hat.

Da mich und der Person (Linux-Neuling) der ich helfen wollte dieser kleine aber feine Unterschied eine frustrierende Stunde am Telefon gekostet hat, bevor wir aufgegeben haben und ich es mit meinen zwei Computern daheim gelöst hab, werd ich das jetzt einfach mal im Wiki anpassen. Ich denk das kann nur in aller Interesse sein ☺

Lange Rede kurzer Sinn..

Grüße, Thomas

Vor sleep fehlte die Befehlsverkettung '&&' im Beispiel. Ich habe es im Wiki korrigiert.

Nein, hat nicht gefehlt. Es handelt sich ja um eine SSH-Verbindung, die im Hintergrund läuft und deshalb direkt einen Befehl erwartet. In diesem Fall einfach nur, dass sie warten soll und nicht gleich zusammenbricht bzw sich wieder abbaut, weil ungenutzt. So wie es jetzt im Wiki steht funktioniert es auch nicht. Mit dem etwas komplexeren Befehl die VNC-Verbindung aufzubauen klappt das so aber nicht. Der muss verkettet sein. Die Alternative den Befehl für die VNC-Verbindung direkt dahinter in Hochkommas zu stellen, wie es in der Manpage steht, hat bei mir nicht funktioniert. Deshalb muss es sein, wie es vorher war.

Grüße, Thomas

Die übliche SSH-Verbindung wird vom Klienten initiiert. Dabei wird die dem Hostnamen folgende Angabe als Befehl interpretiert. Üblicherweises also als Befehl an den Host.

Hier liegt ein (Reverse-)Aufruf vom Host an den Klienten vor. An welchen Rechner richtet sich der Befehl sleep?

Die SSH-Verbindung wird hier auch vom Clienten initiiert. Aber im Hintergrundmodus, da sie ausschließlich dazu genutzt wird die VNC-Verbindung zu tunneln. Die VNC-Verbindung hingegen wird rückwärts -nämlich vom Server- aufgebaut.

Übrigens stand der Befehl vorher auch so im Wiki, wie du an meinem vorletzten Beitrag sehen kannst. Das hatte auch so funktioniert, aber die Zeit war mit 10 sec recht kurz gewählt. So wie ich es dann geändert hab, hat es auch den Vorteil, das es in einem Rutsch kopiert werden kann.

Fakt ist auch ganz einfach, dass es ohne die ersten && funktioniert und mit nicht. Dann kommt nämlich folgende Fehlermeldung:

user@pc:~$ ssh -f -L 5500:localhost:5500 tom@192.168.0.27
Cannot fork into background without a command to execute.
user@pc:~$ ssh -f -L 5500:localhost:5500 tom@192.168.0.27 && sleep 10 && ...
Cannot fork into background without a command to execute.

wie ich schon sagt, ssh im Hintergrundmodus erwartet einen Befehl

Gruß, Thomas

Bei SSH der Schalter -N könnte dir dabei helfen 😉

mfg Stefan Betz

Klingt zwar vielversprechent,

ssh -N -L 5500:localhost:5500 tom@192.168.0.27 && x11vnc -connect_or_exit localhost:5500
ssh -N -L 5500:localhost:5500 tom@192.168.0.27 'x11vnc -connect_or_exit localhost:5500'
ssh -N -L 5500:localhost:5500 tom@192.168.0.27 x11vnc -connect_or_exit localhost:5500

funktioniert aber alles leider nicht. Hängt sich auf oder wartet darauf, das was passiert. Also entweder bitte präziser schreiben wie es gemeint ist, oder wir lassen es bei dieser funktionierenden Variante:

ssh -f -L 5500:localhost:5500 user@IP-des-Helfers sleep 10 && x11vnc -connect_or_exit localhost:5500

Wie gesagt, so war es vorher ja quasi auch, nur nicht verkettet. Und es hatte ja funktioniert, nur hatte mensch wenig Zeit die nächste Zeile zu kopieren und einzufügen. Insbesodere also Linux- / Konsolenneuling war es zu wenig. Bei dieser Variante ist der einzige Unterschied, dass es hier auf einmal eingefügt werden kann und somit sleep vermutlich auch auf 1 sec gesetzt werden könnte.

Ich hab gard auch anderes am PC zu tun. Und ich finds grad ganz schön müßig.. alles wegen einer kleinen Änderung.. 😕 Irgendwie geht diese Diskussion auch etwas am Thema vorbei find ich

Korrekt ist -NfL bei SSH, und dann halt die Portforwarding Parameter. Denn mit -f schickst du SSH in den Hintergrund, mit -N ist keine Shell erforderlich und -L macht halt das Portforwarding.

mfg Stefan Betz