Možnosti vzdálené správy/plochy (diskuse)

[Josef Kufner]

XDMCP není vůbec špatná věc... (a tuším že přes to chodí opengl akcelerovaně)...

Prostě to jen v [xkg]dm povolit a pak:

X :1 -query 192.168.1.20

[Josef Kufner]

Jo a mimochodem... už tu pár článků o tom bylo

[Nebezpecna_sit]

Pravda, na to jsem zapomněla :)

[Zdeněk Štěpánek]

XDMCP není vůbec špatná věc... (a tuším že přes to chodí opengl akcelerovaně)...

Hmm, to by me velice zajimalo jak, kdyz graficky vykon je zavisly na komunikaci CPU-GPU. Ne nadarmo ted vymejslej takovy veci jako PCIe x16. Dejte si misto PCIe 100Mbit (nebo i 1Gbit) ethernet s latencema oproti PCIe jako krava a dejte vedet jak na tom pobezi OpenGL.

Zdenek

[Grunt]

XDMCP není vůbec špatná věc...

Ze všech výše jmenovaných bych dokonce řekl, že i nejlepší(až na to že se okna přenášejí jako XPM a né jako JPEG) a u Linuxu téměř nejjednodušší . Jen je nepěkné, že se i WindowManager spouští vzdáleně. Osobně to dělám, tak že si jako WM spustím lokálně Beryl nebo Compiz(není nutné pořád táhat po síti pixmapy při každém zakrytí okna) a přepošlu si pouze do již používaného X-Serveru kicker nebo gnome-panel, který umístím nahoru nebo na bok.

a tuším že přes to chodí opengl akcelerovaně

Ano, to sice chodí, ale i u blbého glxgears se FastEthernetová síť docela zapotí a plynulost…

X :1 -query 192.168.1.20

Téže není nutné. [xkg]dm má na to tlačítko Vzdálené přihlášení přes XDMCP a ve Windows lze použít Xming.

[Michal Kubeček]

až na to že se okna přenášejí jako XPM a né jako JPEG

To je hodně nepřesné. XDMCP je jen protokol pro komunikaci mezi dvěma displaymanagery, který vám umožní vzdálené přihlášení. Vlastní komunikace aplikace s X serverem probíhá naprosto stejně, jako když ji spustíte normálně a nastavíte proměnnou DISPLAY na váš X server. Takže se přenášejí jednotlivá grafická primitiva. Mimochodem, pokud si zrovna neprohlížíte fotky, používat JPEG kompresi pro bitmapy oken by byl hodně nešťastný nápad.

Jen je nepěkné, že se i WindowManager spouští vzdáleně.

XDMCP existuje právě proto, abyste si celou session včetně windowmanageru spustil na vzdáleném počítači a u vás běžel jen X server a windowmanager. Odeberte tuto vlastnost a XDMCP vlastně vůbec nepotřebujete.

Vypadá to, že ohledně fungování X11 a XDMCP panují trochu zkreslené představy, proto doporučuji k přečtení příslušnou kapitolu v učebnici.

[Grunt]

To je hodně nepřesné. XDMCP je jen protokol pro komunikaci mezi dvěma displaymanagery, který vám umožní vzdálené přihlášení. Vlastní komunikace aplikace s X serverem probíhá naprosto stejně, jako když ji spustíte normálně a nastavíte proměnnou DISPLAY na váš X server. Takže se přenášejí jednotlivá grafická primitiva.

XDMCP existuje právě proto, abyste si celou session včetně windowmanageru spustil na vzdáleném počítači a u vás běžel jen X server a windowmanager. Odeberte tuto vlastnost a XDMCP vlastně vůbec nepotřebujete.

Vypadá to, že ohledně fungování X11 a XDMCP panují trochu zkreslené představy, proto doporučuji k přečtení příslušnou kapitolu v učebnici.

Jen nazývám věci nesprávnými jmény. Významy XDMCP a X Protocol k sobě patří stejně jako Lolek a Bolek, takže prosím omluvte mou sníženou rozlišovací schopnost.

Mimochodem, pokud si zrovna neprohlížíte fotky, používat JPEG kompresi pro bitmapy oken by byl hodně nešťastný nápad.

Ale přenášet pixmapy na pomalé lince také není zrovna to nejšťastnější řešení.

[CET]

Významy XDMCP a X Protocol k sobě patří stejně jako Lolek a Bolek

No, jak se to vezme. To je jako rict, ze UDP a TCP k sobe patri. Pritom ale UDP a TCP muzu provozovat uplne zvlast jeden bez druheho, stejne tak XDMCP (UDP) a X11proto (TCP) muzu provozovat nezavisle.

XDMCP slouzi pouze k nalezeni login manageru. DEtaily http://en.tldp.org/HOWTO/XDMCP-HOWTO/gdm.html a http://en.wikipedia.org/wiki/X_display_manager. Potom spusti na lokalnim X serveru pres X11proto prihlasovaci manazer. Cili, pokud se nechci prihlasovat managerem, muzu si spustit celou X session vcetne WindowManagera pres Xforward v SSH. Je to proste neco jineho.

[Michal Kubeček]

Významy XDMCP a X Protocol k sobě patří stejně jako Lolek a Bolek

To bych rozhodně netvrdil. Použití XDMCP k vytvoření vzdálené session bez následného použití X11 pro komunikaci vzdálených aplikací s lokálním X serverem si sice dokážu představit jen těžko, ale naopak X11 se dnes daleko častěji používá bez XDMCP než s ním (a to i když budu počítat jen případy, kdy X server a aplikace neběží na stejném stroji).

Ale přenášet pixmapy na pomalé lince také není zrovna to nejšťastnější řešení.

Jenže to X11 protokol nedělá. X11 protokol přenáší od aplikace k X serveru požadavky na jednotlivé primitivní operace - nakresli čáru, vyplň oblast, zkopíruj oblast jinam, napiš text atd. Pixmapy z toho dělá až X server a ten je na druhé straně. Teprve v okamžiku, kdy se aplikace rozhodne vykreslit nějakou pixmapu - třeba při tom prohlížení fotek - musí ji poslat X serveru (stejně jako když poběží lokálně). Ale i pak bych upřednostnil třeba kompresi, kterou disponuje ssh, pro obsah většiny oken je JPEG naprosto nevhodný (používání JPEGu pro screenshoty je sice poměrně časté, ale je to hrozný nešvar).

[puco]

Šifrování na nízké úrovni využívá klíč o 56 bitech (256 možných čísel). Pokud chcete vysoké zabezpečení, vězte, že SSH umí pracovat až s 1024 bitovým klíčem.

V tejto casti splietate 2 rozne veci: symetricke a asymetricke sifrovanie. Dlzka 56 bitov zodpoveda DESu, co jem uz naozaj malo. Takze sa pouziva napr. AES128 alebo AES256. Este som nepocul, ze by niekto pouzival blokovu sifrun s dlzkou kluca vacsou ako 256bitov. Aj ked sa mozrejme ze, taka sifra sa da navrhnut.

Na druhu stranu pri asymetrickom sifrovani 1024 je uz teraz v podstate dolna hranica. Asymetricke sifrovanie sa nepouziva na prenos vsetkych udajov, prenesie sa len session key, kt. sa potom pouziva v symetrickej sifre.

[freshmouse]

Jůů. Zrovna včera jsem poprvé použil SSH, abych se přihlásil na FEL (díky Pepčovi). Co vám mám povídat, byl to zážitek.

[manasekp]

ssh na felu funguje celkem dobre, nedavno sem z tama potrebovsl nejakou javovskou tridu na nacitani neceho a ssh fungovalo asi na treti pokus

[=^..^= AmigaPower®]

Dobré dávám do záložek, v krátké budoucnosti se mi hodí, díky.

[Nebezpecna_sit]

Jsem ráda, že aspoň někomu to pomůže :)

[tsLnox]

Mě taky :-P Díky

[spenat28]

takže jsem Ti nekecal a nemlel nesmysly! :o) Hurá a sláva, to mam radost :o)

[Nebezpecna_sit]

jj, seš geek :o) (pardon, nemohla jsem odolat :o)) )

[spenat28]

Že Tě kopnu?

[CET]

VNC pomale?? Na lokalni siti?? Jakou presne verzi jsi pouzila (RealVNC nebo TightVNC)? ja osobne pouzivam tightvnc, ma lepsi tight kompresi, umoznuje nadefinovat kvalitu obrazu u JPEG obrazu a taky kompresi, takze i na pomalych sitich to jelo rychle. Krome tunelovani SSHckem jde jeste tunelovat stunnelem (vyhoda, pokud to chces pro jiny lidi a nechces jim davat ssh pristup). Navic tightvncviewer umoznuje automaticky spoustet ssh pro tunelovani.

Jinak krome dvou klavesnic a mysi lze pouzit sdileni klavesnice a mysi pro dva ruzny compy se dvouma monitorama - vyhoda je, ze nemusis prehmatavat. Na to se da pouzit bud synergy (win i lin) nebo x2vnc+win2vnc.

Zajimalo by me, jakym zpusobem Ubuntu dela to sdileni vzdalene plochy pres VNC-dokazala bys to zjistit? Ubuntu nemam a System -> Volby -> Vzdalena pracovni plocha taky ne. Osobne na sdileni aktualni X session pouzivam bud synergy nebo x11vnc-pouziva to Ubuntu taky nebo neco jineho? Tohle x11vnc taky pouziva tighvnc, takze by to melo byt dostatecne rychly.

Jinak, jak jsem uz psal, tightvnc umoznuje taky kompresi (a kvalitu) a (jak jsem ted zjistil) taky ssh, takze ne jenom NX. Je skoda, ze jsi nesla do hloubky a nezjistila vsechny parametry a neudelala skutecne objektivni porovnani, ale jenom takovy lehky, co jsi kde nasla ke kliknuti. Ale co se da delat, je to jenom blog.

Osobne radsi pouzivam reseni zalozeny na ssh a VNC (ssh text, VNC vzdaleny) a nekdy jenom tunelovani X proto v ssh. TightVNC se mi zda takovy univerzalnejsi nez NX a jednodussi. Pro linux jsou to dva balicky (pripadne jeden) tightvnc, pro Windows dokonce staci jenom WinVNC.exe+2 DLL soubory (pro server) a vncviewer.exe jako prohlizec. Navic VNC obsahuje i vncviewer v jave, takze pres web browser s javou se nemusi ani nic instalovat. Takhle jednoduse je to sice bez sifrovani, ale na jednoduchy sdileni (pomoc nekomu) to staci.

Nasledujici odstavecky na me pusobi trosku zmatene. Nechapu, jestli maji na sebe logickou navaznost, nebo pises o dvou vecech nezavisle.

Pokud chcete spouštět grafické aplikace za pomocí X11 forwarding, použijte přepínač -X: ssh -X richmond@192.168.1.20

A pokud chcete spustit grafickou aplikaci, která by se objevila na vzdáleném stroji, použijte pro její spouštění DISPLAY=:0.0 (nebo DISPLAY=:0.1 apod. Záleží na nastavení) DISPLAY=:0.0 gedit

ssh -X vytvari samo promennou DISPLAY, obsahujici obvykle neco jako localhost:10 (nebo cislo vetsi). Nastaveni display offset se dela v sshd_configu (viz man) a sam ssh -X provede taky zapis tzv. cookies pro autentizaci na lokalnim X serveru. Povoleni X forwardingu je samozrejme nutny povolit v sshd_configu a pripadne se da nastavit pro vybrany host v ssh_config.

Pokud chces spustit aplikaci na vzdalenych serveru, aby se ti objevila na tvym lokalnim X serveru (X session), tak musis do DISPLAY nacpat celej nazev tvyho X serveru a za to teprve cislo displaye, tedy napr. pracuju na stanici mojews.doma, DISPLAY mam :0.0 a na serveru mujserver.doma chci pustit xterm, tak musis po nalogovani pres SSH bez -X nastavit DISPLAY="mujews.doma:0.0". Krome toho samozrejme firewall musi povolovat spojeni na port 6000, X server musi mit povolene prijimani TCP spojeni a navic musis bud (a) na vzdalenym serveru nastavit spravne cookies (na svym PC xauth list $DISPLAY a pak na serveru xauth mojews.doma:0.0 . COOKIE), a/nebo (ted si nejsem jistej) (b) povolit pristup ze serveru do tvyho X serveru pomoci xhost +mujserver.doma. Celkove je tahle varianta hodne slozite a jednodussi je tunelovat to SSHckem, to chodi vetsinou - akorat pozor, nezapomenout, ze na serveru, kam se pomoci ssh -X prihlasuju, musi byt nainstalovany xauth program (debian balicek xbase-clients), aby ulozit X cookies, jinak to fungovat nebude.

Jinak jen pro upresneni:

• :0.0 je prvni screen a prvni monitor
• :0.1 je prvni screen a druhy monitor
• :1.0 je druhy screen (druhej X server) a prvni monitor
• :1.1 je druhy screen (druhej X server) a druhej monitor

[tsLnox]

Děkuji i tobě

[atan]

Tightvnc (a uz ani realvnc v pripade x-server 1.4) se nedokaze pripojit k bezicimu sezeni. Podle me je u vnc nejlepsi klasicky x11vnc s libvncserver pro server, a jako klient klidne tight nebo real. Samozrejme jestli clovek nepotrebuje novy sezeni.

[CET]

Tightvnc (a uz ani realvnc v pripade x-server 1.4) se nedokaze pripojit k bezicimu sezeni.

Tohle trosku nechapu:

* bud mas na mysli bezici klasicky vncserver(Xvnc), v tom pripade se samozrejme tightvnc i realvnc dokaze pripojit, jinak by to ani nemelo smysl

* nebo mas na mysli pripojovani pres vnc k bezici X session (klasicky na lokalnim monitoru) a v tom pripade viz Osobne na sdileni aktualni X session pouzivam bud synergy nebo x11vnc Tady je to mozna trosku neprehledne. Zatimco synergy umoznuje pouze ovladat vzdalenou plochu pomoci stejny kbd+mys, ale clovek musi mit druhy monitor u druheho pocitace se zobrazenou plochou. Kdezto x11vnc aktualni X session zabali do VNC serveru-pak je mozne bud podobne jako synergy pomoci x2vnc nebo win2vnc "preject" kurzorem na druhy monitor a ovladat druhou plochu (samozrejme clovek musi mit druhy monitor a vyhled na ten monitor), nebo je mozne pouzit vncviewer a zobrazit si vzdalenou X session na svem pocitaci (tohle jde pouzit i pro PC, ktera jsou nekde daleko na internetu a neni vyhled na monitor, nebo dokonce ani monitor nemaji). Dobry je, ze se tim da taky delat "vzdalena pomoc", kdyz uzival v linuxu v Xkach neco nevi, tak se muze clovek pripojit na jeho Xka a pomoct mu.

[atan]

Ja vedel, ze to mam precist poradne. ;o)

[CET]

Tak abys nebyl na vine jenom ty, prece jenom to bylo o trosku delsi nez obvykle prizpevek do diskuze byva Tak jsem si zkusil porovnat velikosti textu s puvodnim blogem a ten puvodni clanek ma (bez obrazku) priblizne 2867 bytu (rika gvim) a muj prizpevek ma 3988 bytu. No, tak sorry