Remote desktop naar een linux machine

[dikkehein]

Hallo!

Sinds kort ben ik bezig met het experimenteren met VM’s op mijn Unraid server. Ik heb een pc staan thuis met daarop windows. Die gebruik ik voornamelijk voor gamen etc. Nu wil ik af en toe ook wel eens programmeren en dat doe ik liever op linux dan een incapabel OS. Dus ik dacht, ik ga een VM draaien op mijn nas waar ik naar remote desktop om zo te kunnen werken. Ik heb 3 beeldschermen op mijn eigen pc en die zou ik graag ook alle 3, indien mogelijk, willen benutten.

Nou heb ik echter wat problemen en vroeg mij af wat de ervaringen zijn met Linux em remote desktopping.

Ik heb Ubuntu 18.04.3 geïnstalleerd met een isotje. Via de web VNC client werkt t prima, laggy maar voor de basic setup prima. Nou wil ik graag gaan RDP’en. Hiervoor heb ik XRDP geïnstalleerd. Dit werkt echter niet voor mij. Via Mac (heb ook een macbook staan) krijg ik alleen een zwart scherm en via Windows krijg ik foutmeldingen dat de login faalt (user/pass zijn correct, kan inloggen via de web VNC client). Er blijkt een bug te zitten in XRdP maar die zou ook weer opgelost moeten zijn? Ondertussen zo veel tutorials en blogposts gevolg, ik heb geen idee meer welke wat doet/zegt.
Ik heb ook VNC geprobeerd maar geen enkele client bood mij daar de mogelijkheid om meerdere schermen te gebruiken. (Tevens zou het minder veilig zijn?).

Nou goed. Al met al. Mijn vraag: wat is jullie ervaring met remote desktopping op Linux (niet per se ubuntu)? Heeft iemand temote desktops aan de praat gekregen met meerdere schermen? En/of weet er iemand nog een goeie linux distro om zoiets mee uit te voeren? Ik heb geen idee waar ik t nou moet zoeken. (Ben bekend met Linux en als het super enge Arch een uitkomst is, ben ik bereid de uitdaging aan te gaan).

Alvast bedankt!

[DataGhost]

Waarom wil je precies RDP gaan gebruiken ipv VNC? Ah, multi-monitor. Anyway, ik heb dat zelf nooit gebruikt met Linux als server, maar ik kan me niet voorstellen dat het enorm veel beter gaat zijn.

Ik zou persoonlijk eens kijken naar Xpra, dat gebruik ik zelf en werkt behoorlijk fijn vind ik. Je hebt dan niet zoals met RDP/VNC een hele desktop die een heel scherm inneemt, maar je hebt gewoon de losse vensters, dus je kan je Linux-programma's gebruiken alsof ze native in Windows draaien en je kan ze over verschillende schermen verspreiden tussen je Windows-vensters bijvoorbeeld.

Wat betreft veiligheid kan je zowel VNC als Xpra-verbindingen encrypten of zelfs tunnelen via SSH of een VPN.

[ Voor 11% gewijzigd door DataGhost op 20-01-2020 23:47 ]

[jbhc]

Dat wordt een uitdaging.

xrdp met Mint krijg ik zo goed als niet voor elkaar en Mint is op Ubuntu gebaseerd.
De enige manier waarop mij dat soort van lukt is xrdp installeren en vervolgens tigervnc-server installeren.
Je kunt dan een VNC sessie starten, althans op Mint.

Er schijnt iets te zijn met de xrdp en/of VNC inplementatie onder gnome voor zover ik op de diverse websites heb kunnen vinden.

Als Mint fan heeft de "lalalalala, vingers in mijn oren, teamviewer en nomachine werken prima" mentaliteit mij in ieder geval weggejaagd.

Ik ben met mijn systemen aan het overstappen naar Debian daar werkt het bijna prima met als enige minpunt dat je op de host niet fysiek op de desktop ingelogd mag zijn.

Bij mij is het positieve wat ik hier aan heb ondervonden dat ik mij nu afvraag waarom ik eigenlijk een Debian fork gebruikte. Debian is eigenlijk net zo makkelijk als Ubuntu / Mint

[ Voor 14% gewijzigd door jbhc op 21-01-2020 00:32 ]

[Room42]

Ik heb nooit een RDP-server gedraaid op Linux maar ik weet dat de Raspberry Pi's dit nog wel eens willen, dus je zou daar eens kunnen spieken wat zij gebruiken.

Wat ik zou proberen is Teamviewer of AnyDesk. Vooral die laatste werkte bij mij wel goed om mijn vader remote te ondersteunen.

Verder doe ik altijd alles via SSH, sorry.

[jbhc]

@Room42 Teamviewer om een pc op je LAN te benaderen, echt ? Niet dat het niet werkt hoor maar bij mij voelt het gewoon zo verschrikkelijk fout....

[Wim-Bart]

jbhc schreef op dinsdag 21 januari 2020 @ 01:00:
@Room42 Teamviewer om een pc op je LAN te benaderen, echt ? Niet dat het niet werkt hoor maar bij mij voelt het gewoon zo verschrikkelijk fout....

Tja, mensen snappen niet dat Linux wat meer nodig heeft om deze grafisch te benaderen. En oplossingen zoals vnc en xrdp zijn echt draken.

De enige oplossing is een X-server op een Windows of Mac te installeren die gebruik kan maken van de X-Cliënt op de Linux host. Maar dan gaan mensen weer zeggen, hey de Linux doos is toch de server, grinnik, noobs.

Persoonlijk werk ik met Putty of variant, gewoon lekker met SSH.

[Room42]

@Wim-Bart nou nou...

@jbhc ik heb er overheen gelezen dat het om LAN ging.

[ Voor 58% gewijzigd door Room42 op 21-01-2020 01:18 ]

[Verwijderd]

Wim-Bart schreef op dinsdag 21 januari 2020 @ 01:04:
[...]

Tja, mensen snappen niet dat Linux wat meer nodig heeft om deze grafisch te benaderen. En oplossingen zoals vnc en xrdp zijn echt draken.

De enige oplossing is een X-server op een Windows of Mac te installeren die gebruik kan maken van de X-Cliënt op de Linux host. Maar dan gaan mensen weer zeggen, hey de Linux doos is toch de server, grinnik, noobs.

Persoonlijk werk ik met Putty of variant, gewoon lekker met SSH.

Idd, putty FTW. Ik ben al blij als iemand de moeite heeft genomen om een .bashrc te maken zodat ik kleurtjes heb. Grafisch een desktop overnemen eigenlijk nog nooit gedaan, maar kan handig zijn. Volgens mij zijn servers vaak echter niet uitgerust met een grafische omgeving waarmee je hulp-utils kunt gebruiken om bepaalde dingen te configureren, toch? Dan is het een beetje nutteloos om te gaan teamviewen om vervolgens een terminal te openen.

[Wim-Bart]

Verwijderd schreef op dinsdag 21 januari 2020 @ 01:25:
[...]

Idd, putty FTW. Ik ben al blij als iemand de moeite heeft genomen om een .bashrc te maken zodat ik kleurtjes heb. Grafisch een desktop overnemen eigenlijk nog nooit gedaan, maar kan handig zijn. Volgens mij zijn servers vaak echter niet uitgerust met een grafische omgeving waarmee je hulp-utils kunt gebruiken om bepaalde dingen te configureren, toch? Dan is het een beetje nutteloos om te gaan teamviewen om vervolgens een terminal te openen.

Een complete grafische installatie is niet nodig op Linux, wat van belang is, maar is dat X-Client en de benodigde tools, zoals xterm, xcalc, en dergelijke zijn geïnstalleerd. Op je werkplek heb je X-Servrr software nodig.

https://sourceforge.net/projects/vcxsrv/

Een leuke tutorial
http://christopher5106.gi...indows-10-for-ubuntu.html

[Verwijderd]

Wim-Bart schreef op dinsdag 21 januari 2020 @ 01:35:
[...]


Een complete grafische installatie is niet nodig op Linux, wat van belang is, maar is dat X-Client en de benodigde tools, zoals xterm, xcalc, en dergelijke zijn geïnstalleerd. Op je werkplek heb je X-Servrr software nodig.

https://sourceforge.net/projects/vcxsrv/

Een leuke tutorial
http://christopher5106.gi...indows-10-for-ubuntu.html

Dat begrijp ik, op de werkplek is het wenselijk. Remotely? Ik denk dat menigeen uit de voeten kan met een terminal via SSH, niet? (ik vaak ook niet, daar niet van)

Vroeger wel vaak VNC gebruikt. Misschien is het handig om TS te vragen waar hij de remote desktop omgeving voor wil gebruiken? Kennelijk werkt VNC web client wel, het feit dat dit een web client is kan de lag veroorzaken als de client PC niet de vlotste is, of misschien loopt de web VNC via een proxy? Wellicht heeft het nut om eens te proberen de "echte" VNC client te gebruiken.

[clogie886]

Misschien is Anydesk een oplossing voor je, https://anydesk.com/en maar nooit geprobeerd met meerdere schermen.

[jbhc]

clogie886 schreef op dinsdag 21 januari 2020 @ 04:03:
Misschien is Anydesk een oplossing voor je, https://anydesk.com/en maar nooit geprobeerd met meerdere schermen.

Dit is toch dezelfde oplossing als nomachine en teamviewer?

[oohh]

Installeer een vnc client naar keuze op je Ubuntu VM en open op je Mac Screen Sharing. Gewoon het IP-adres + juiste poort invullen en het moet werken

[clogie886]

jbhc schreef op dinsdag 21 januari 2020 @ 08:08:
[...]


Dit is toch dezelfde oplossing als nomachine en teamviewer?

Klopt, zie nu pas dat Anydesk al als oplossing gepost was maar nomachine kon ik nog niet, bedankt!

[dikkehein]

Hmm blijkbaar niet duidelijk genoeg geweest.

Ik wil graag vanaf mijn windows machine een linux machine kunnen benaderen. Zodat ik op die linux machine kan programmeren. En dan heb ik t over een Linux desktop omgeving, geen server. Want ik zou graag gewoon een IDE kunnen draaien (Ja ja, lekker VIMmen op de command line kan ook he? I know, maar ik prefereer toch nog wel een IDE). En ik wil ook graag een webbroswer kunnen openen (want web apps). Ik heb dus meer nodig dan een simpele ssh connectie. Teamviewer ben ik niet heel erg fan van en zoals iemand al noemde voelt t erg fout. Dus vandaar dat ik eerder zocht naar andere oplossingen. Maar goed, de opties blijven daar wel voornamelijk bij hangen. NoMachine, Anydesk en Teamviewer. Dan zal ik daar toch maar eens naar moeten kijken.

Verwijderd schreef op dinsdag 21 januari 2020 @ 01:45:
[...]

Dat begrijp ik, op de werkplek is het wenselijk. Remotely? Ik denk dat menigeen uit de voeten kan met een terminal via SSH, niet? (ik vaak ook niet, daar niet van)

Vroeger wel vaak VNC gebruikt. Misschien is het handig om TS te vragen waar hij de remote desktop omgeving voor wil gebruiken? Kennelijk werkt VNC web client wel, het feit dat dit een web client is kan de lag veroorzaken als de client PC niet de vlotste is, of misschien loopt de web VNC via een proxy? Wellicht heeft het nut om eens te proberen de "echte" VNC client te gebruiken.

Eigen PC is krachtig genoeg. 'T is de webVNC client die gewoon laggy werkt en traag reageert etc want t moet gewoon een hele desktop omgeving weergeven. De server waarop de VM draait is gewoon te bereiken via LAN. Dus de VM ook (gebridged naar mijn LAN netwerk en een IPtje van de DHCP server gekregen). Wat bedoel je met een echte VNC client?


Bedankt voor de tips allen!

---

Wim-Bart schreef op dinsdag 21 januari 2020 @ 01:04:
[...]

Tja, mensen snappen niet dat Linux wat meer nodig heeft om deze grafisch te benaderen. En oplossingen zoals vnc en xrdp zijn echt draken.

De enige oplossing is een X-server op een Windows of Mac te installeren die gebruik kan maken van de X-Cliënt op de Linux host. Maar dan gaan mensen weer zeggen, hey de Linux doos is toch de server, grinnik, noobs.

Persoonlijk werk ik met Putty of variant, gewoon lekker met SSH.

*knip*
Misschien niet geheel duidelijk geweest dat ik een desktop versie heb geinstalleerd. *knip*

[ Voor 5% gewijzigd door Cyphax op 21-01-2020 22:09 . Reden: laten we het wel gezellig houden naar elkaar ]

[ActaNonVerba]

Misschien niet wat je precies zoekt, maar het is het proberen waard: https://code.visualstudio.com/docs/remote/remote-overview

Aansluitend op dit kan je ook beginnen met Docker! Het is dan mogelijk om in een linux omgeving jouw code te realiseren op een Windows machine. Succes!

[jbhc]

Je zou RealVNC kunnen proberen.

code:

 sudo apt install realvnc

Zou moeten kunnen werken.

Wat ik heb begrepen is dat gnome iets met vino heeft uitgespookt waardoor het niet goed meer werkt.


Ik ben er heel wat uurtjes zoet mee geweest maar heb onder mint (en neem dus aan ook Ubuntu) geen fatsoenlijke oplossing kunnen vinden.

[ Voor 57% gewijzigd door jbhc op 21-01-2020 11:36 ]

[Blokker_1999]

Maar waarom wil je net op die Linux VM je ontwikkeling doen? Je IDE kan toch perfect lokaal draaien terwijl deze de bestanden van je webapp remote benaderd tijdens de ontwikkeling? En voor de browser maakt het normaal ook niet uit of deze nu http://localhost danwel http://remotehost moet doen. De rendering engine blijft hetzelfde dus de pagina gaat er hetzelfde uitzien ongeacht het OS waarop de browser draait.

En ondank je reactie naar @Wim-Bart toe, moet ik zeggen dat hij wel gelijk heeft. Met een beetje configuratiewerk kan je de applicaties die je op de Linux machine wenst te draaien, draaien op je Windows of Mac omgeving. Zowel X11 als Wayland maken gebruik van een client/server model waardoor de applicatie kan renderen op de ene machine (je Linux systeem) en weergegeven worden op een andere machine (je Windows of Mac machine) en dat kan dan weer netjes over je SSH sessie die je kunt opzetten. In plaats van zijn post weg te lachen zou je die al bijna als beste antwoord kunnen markeren want dat is net de manier waarop de Linux grafische rendering net ontworpen is en net met de reden die jij wil: remote werken met grafische apps. Bijkomend voordeel: je apps zijn vensters die netjes integreren in je lokale desktop.

Nog een alternatief: je VM draaien in bijvoorbeeld Virtualbox op je game machine ipv je NAS. Die machine is veel sneller dan je NAS, gaat je veel betere performantie geven, de virtuele harde schijf kan alsnog op je NAS staan. Je hebt dan zonder problemen ook voldoende hardwareversnelling op zowel CPU als GPU (indien gewenst) en multi monitor support is ook geen enkel probleem.

[dikkehein]

Blokker_1999 schreef op dinsdag 21 januari 2020 @ 13:23:
Maar waarom wil je net op die Linux VM je ontwikkeling doen? Je IDE kan toch perfect lokaal draaien terwijl deze de bestanden van je webapp remote benaderd tijdens de ontwikkeling? En voor de browser maakt het normaal ook niet uit of deze nu http://localhost danwel http://remotehost moet doen. De rendering engine blijft hetzelfde dus de pagina gaat er hetzelfde uitzien ongeacht het OS waarop de browser draait.

En ondank je reactie naar @Wim-Bart toe, moet ik zeggen dat hij wel gelijk heeft. Met een beetje configuratiewerk kan je de applicaties die je op de Linux machine wenst te draaien, draaien op je Windows of Mac omgeving. Zowel X11 als Wayland maken gebruik van een client/server model waardoor de applicatie kan renderen op de ene machine (je Linux systeem) en weergegeven worden op een andere machine (je Windows of Mac machine) en dat kan dan weer netjes over je SSH sessie die je kunt opzetten. In plaats van zijn post weg te lachen zou je die al bijna als beste antwoord kunnen markeren want dat is net de manier waarop de Linux grafische rendering net ontworpen is en net met de reden die jij wil: remote werken met grafische apps. Bijkomend voordeel: je apps zijn vensters die netjes integreren in je lokale desktop.

Nog een alternatief: je VM draaien in bijvoorbeeld Virtualbox op je game machine ipv je NAS. Die machine is veel sneller dan je NAS, gaat je veel betere performantie geven, de virtuele harde schijf kan alsnog op je NAS staan. Je hebt dan zonder problemen ook voldoende hardwareversnelling op zowel CPU als GPU (indien gewenst) en multi monitor support is ook geen enkel probleem.

Als ie t net zo goed en netjes had uitgelegd als jij, dan wel . Kom op zeg, mag toch wel een beetje met respect met elkaar om gaan? Tevens totaal geen onderbouwing voor het onderuit halen van mijn zoekrichting.

Goed. Toegegeven, nuttige tips waar ik me zeker in kan verdiepen. Ik wist inderdaad niet dat Linux grafische rendering zo ontworpen is, en zit ik blijkbaar in de verkeerde richting te kijken.
Ik programmeer liever op een linux omgeving dan windows, voornamelijk vanwege de mogelijkheden die gewoon vele malen makkelijker zijn (voor mij) op een linux bak dan op een windows machine. Denk aan bijvoorbeeld command line tools. Ik heb gewoon altijd gezeur gehad met windows terwijl linux vaak het best ondersteund wordt door de programmeer wereld.
Wat ik ook probeer te bereiken met deze scheiding is dat ik mijn eigen PC vrij houdt van dit soort dingen. (Programmas, projecten etc). Alhoewel een Virtualbox dat inderdaad zo veel mogelijk beperkt.

[jbhc]

Lokaal een remote applicatie draaien is ook niet zaligmakend.
- Kwa snelheid is dat echt niet veel beter dan een rdp verbinding.
- kwa gebruiksgemak is het ook behoorlijk bagger.

We hebben toch geen fullhd of 4k schermen om vervolgens allerlei basisdingen in een cli te gaan doen?

[Rukapul]

jbhc schreef op dinsdag 21 januari 2020 @ 13:57:
Lokaal een remote applicatie draaien is ook niet zaligmakend.
- Kwa snelheid is dat echt niet veel beter dan een rdp verbinding.
- kwa gebruiksgemak is het ook behoorlijk bagger.

We hebben toch geen fullhd of 4k schermen om vervolgens allerlei basisdingen in een cli te gaan doen?

Op je Windows machine VcXsvr installeren en vervolgens met Putty of andere SSH client (Linux subsystem for Windows bv) X-forwarding selecteren bij het verbinden naar de Linux machine is toch niet zo'n gedoe? Moet je alleen de IDE etc. nog even opstarten. Het is ongeveer de meest cleane manier van werken.

[Verwijderd]

Ik had een soortgelijk vraagstuk. Voor mij was dual boot de beste oplossing. Wellicht is dat nog een idee voor je?

[jbhc]

@Rukapul

Persoonlijk heb ik gewoon graag een desktop voor me en ik denk dat ik niet de enige ben, anders zouden we allemaal gewoon nog gebruik maken van een commandline en niet van een gui

[gwystyl]

Waarom geen linux VM op je windows desktop? Lijkt me makkelijker dan een remote systeem op je desktop toveren.

[Wim-Bart]

dikkehein schreef op dinsdag 21 januari 2020 @ 11:14:
Hmm blijkbaar niet duidelijk genoeg geweest.

Ik wil graag vanaf mijn windows machine een linux machine kunnen benaderen. Zodat ik op die linux machine kan programmeren. En dan heb ik t over een Linux desktop omgeving, geen server. Want ik zou graag gewoon een IDE kunnen draaien (Ja ja, lekker VIMmen op de command line kan ook he? I know, maar ik prefereer toch nog wel een IDE). En ik wil ook graag een webbroswer kunnen openen (want web apps). Ik heb dus meer nodig dan een simpele ssh connectie. Teamviewer ben ik niet heel erg fan van en zoals iemand al noemde voelt t erg fout. Dus vandaar dat ik eerder zocht naar andere oplossingen. Maar goed, de opties blijven daar wel voornamelijk bij hangen. NoMachine, Anydesk en Teamviewer. Dan zal ik daar toch maar eens naar moeten kijken.


[...]


Eigen PC is krachtig genoeg. 'T is de webVNC client die gewoon laggy werkt en traag reageert etc want t moet gewoon een hele desktop omgeving weergeven. De server waarop de VM draait is gewoon te bereiken via LAN. Dus de VM ook (gebridged naar mijn LAN netwerk en een IPtje van de DHCP server gekregen). Wat bedoel je met een echte VNC client?


Bedankt voor de tips allen!

---


[...]


Sorry meneer, wist niet dat ik hier te maken had met De Linux Professional!
Misschien niet geheel duidelijk geweest dat ik een desktop versie heb geinstalleerd. Goed, bedankt voor de solide onderbouwing van je argumenten, erg behulpzaam. Duik jij maar weer "gewoon lekker" in je SSH tunnel.

Volgens mij heb je in een tweede posting een oplossing gegeven welke jouw use case perfect kan oplossen. Je werkt dan op je Linux machine hebt de kracht van je eigen PC voor het grafische werk.

Je bent dus volledig op je Linux machine bezig met alle toolling die je daar installeer, maar toch voelt het aan alsof je lokaal werkt.

http://christopher5106.gi...indows-10-for-ubuntu.html

Lees het eens goed door, en trek dan je conclusie.

[boyette]

test eens even of je met ubuntu wel kunt inloggen op die xdrp met remmina bijv.

dat is normaliter gewoon de beste methode

[dikkehein]

Wim-Bart schreef op dinsdag 21 januari 2020 @ 18:03:
[...]

Volgens mij heb je in een tweede posting een oplossing gegeven welke jouw use case perfect kan oplossen. Je werkt dan op je Linux machine hebt de kracht van je eigen PC voor het grafische werk.

Je bent dus volledig op je Linux machine bezig met alle toolling die je daar installeer, maar toch voelt het aan alsof je lokaal werkt.

http://christopher5106.gi...indows-10-for-ubuntu.html

Lees het eens goed door, en trek dan je conclusie.

Fair enough, je voorstel ga ik zeker nader onderzoeken. Ik wist niet van dat soort mogelijkheden af. Ik ga kijken of dit voor mij de oplossing biedt waar ik naar zoek. Dus bij deze alsnog bedankt voor de info.

gwystyl schreef op dinsdag 21 januari 2020 @ 15:07:
Waarom geen linux VM op je windows desktop? Lijkt me makkelijker dan een remote systeem op je desktop toveren.

Ja ik wou eigenlijk uiteindelijk misschien ook kijken naar het benaderen van de VM op een andere pc, Zodat ik altijd door kan met waar ik gebleven was. Maar goed, dat had ik er niet bij gezegt dus dit is nogsteeds een valide suggestie .

jbhc schreef op dinsdag 21 januari 2020 @ 14:50:
@Rukapul

Persoonlijk heb ik gewoon graag een desktop voor me en ik denk dat ik niet de enige ben, anders zouden we allemaal gewoon nog gebruik maken van een commandline en niet van een gui

Dat heb ik dus ook een beetje. Ik zou graag gewoon een algehele Linux desktop voor me zien.

Goed, dank voor alle input. Ik ga hier van t weekend maar weer mee aan de slag.

[DataGhost]

dikkehein schreef op dinsdag 21 januari 2020 @ 19:10:
[...]


Ja ik wou eigenlijk uiteindelijk misschien ook kijken naar het benaderen van de VM op een andere pc, Zodat ik altijd door kan met waar ik gebleven was. Maar goed, dat had ik er niet bij gezegt dus dit is nogsteeds een valide suggestie .

Daar gebruik ik dus Xpra voor, op m'n laptop heb ik een VM draaien waarin ik dev, dan kan ik gewoon lokaal verbinden als ik onderweg ben maar als ik thuis ben verbind ik vanaf m'n desktop en heb ik alles nog precies zo staan als ik het achtergelaten heb. Maar Xpra is volgens mij behoorlijk onbekend hier dus iedereen gaat er een beetje aan voorbij zonder er naar te kijken.
Anyway, dat ziet er dan zo uit:

[Lethalis]

Ik gebruik op mijn Windows 10 PC's Hyper V met Linux VM die automatisch meedraait.

Als het puur voor development is, kun je ook WSL gebruiken. IDE op Windows draaien, CLI tools in WSL. Je kunt via /mnt/c gewoon bij de bestanden van Windows

Zo kun je dus eenvoudig Linux tools met een Windows IDE / editor (zoals VS Code) combineren.

PS
Remote Desktop naar Linux heb ik de afgelopen jaren vaak geprobeerd, maar uiteindelijk opgegeven. Sorry Het werkte namelijk nooit echt lekker en bij lange na niet zo snel als een Windows Remote Desktop sessie. Ik heb diverse VNC servers getest en NoMachine. Die laatste leek vroeger prima te werken, geen idee waarom het anno nu ook traag is.

[ Voor 50% gewijzigd door Lethalis op 21-01-2020 23:56 ]

[Hero of Time]

Rukapul schreef op dinsdag 21 januari 2020 @ 14:10:
[...]

Op je Windows machine VcXsvr installeren en vervolgens met Putty of andere SSH client (Linux subsystem for Windows bv) X-forwarding selecteren bij het verbinden naar de Linux machine is toch niet zo'n gedoe? Moet je alleen de IDE etc. nog even opstarten. Het is ongeveer de meest cleane manier van werken.

Dat kan makkelijker door gewoon MobaXterm te gebruiken. Die heeft een X-server ingebakken zitten.


Wil je een wat meer graifsche omgeving, kijk dan eens naar een launcher panel*. Die start je dan op vanuit je ssh sessie en de rest doe je dankzij X11 forwarding lekker grafisch.

*Eerste die in mij op komt, is xfce4-panel. Menuknopje erop of alleen een paar launchers en task switcher en klaar.

[jbhc]

Even vanuit mijn eigen situatie gesproken;

Ik heb meerdere losse systemen in huis en vind het gewoon prettig om die over te kunnen nemen ongeacht welk systeem ik gebruik.

Ik persoonlijk vind het dan gewoon prettig om dmv een remote desktop het complete systeem over te kunnen nemen.

Ja, er zijn andere manieren van werken maar ieder zijn eigen ding en tot Ubuntu 17.x / Mint 18.3 werkte dit dus gewoon prima.

Dat dat voor die distro's nu opeens niet meer kan vind ik bijzonder onhandig.

[ddkiller0900]

Ik werk dagelijks remote op een Linux VM met Red Hat en benaderde VM via xrdp. Op zich valt er niet veel in te stellen en de performance is gewoon prima. Ik gebruik de omgeving voornamelijk voor development. Mocht je meer willen weten ontvang ik graag een DM.

[Room42]

ddkiller0900 schreef op woensdag 22 januari 2020 @ 21:21:
Ik werk dagelijks remote op een Linux VM met Red Hat en benaderde VM via xrdp. Op zich valt er niet veel in te stellen en de performance is gewoon prima. Ik gebruik de omgeving voornamelijk voor development. Mocht je meer willen weten ontvang ik graag een DM.

Zou je het hier willen delen? Ik vind dat op zich wel interessant.

[dikkehein]

ddkiller0900 schreef op woensdag 22 januari 2020 @ 21:21:
Ik werk dagelijks remote op een Linux VM met Red Hat en benaderde VM via xrdp. Op zich valt er niet veel in te stellen en de performance is gewoon prima. Ik gebruik de omgeving voornamelijk voor development. Mocht je meer willen weten ontvang ik graag een DM.

Room42 schreef op woensdag 22 januari 2020 @ 21:48:
[...]

Zou je het hier willen delen? Ik vind dat op zich wel interessant.

Mee eens! Ik hoor het ook graag!

[ddkiller0900]

Room42 schreef op woensdag 22 januari 2020 @ 21:48:
[...]

Zou je het hier willen delen? Ik vind dat op zich wel interessant.

Eerst en vooral even de context aangeven van hoe wij op kantoor werken. We maken namelijk gebruik van een stepping stone (Windows server) om toegang te krijgen tot onze beheeromgeving door middel van Citrix.

In deze omgeving is alles best wel afgeschermd, zelfs voor een beheerder. Dit houdt in dat bv. een applicatie remote uitvoeren met X11 over SSH niet mogelijk is. Dit genoot mijn voorkeur aangezien ik dan eenvoudig een specifieke applicatie kan starten in plaats van een hele desktop en er geen GUI nodig is op de server. Doordat dit niet mogelijk is maak ik nu via remote desktop een verbinding naar deze server.

Wat in eerste instantie een VM moest worden om een testomgeving in te draaien, is inmiddels mijn eigen development omgeving geworden. Ik werk met Red Hat 7.x (weet even niet precies welke versie) server en heb daar Gnome 3 op geïnstalleerd. Verder zorgt xrdp ervoor dat ik remote kan inloggen. De instellingen heb ik vrij standaard gehouden. Eén van de voordelen van xrdp is dat je je sessie kunt hervatten. Al moet ik zeggen dat dit soms niet mogelijk is. Na wat uitzoekwerk kwam ik erachter dat dit te maken heeft met hoe xrdp zich gedraagt binnen Red Hat. Om eerlijk te zijn heb ik het nog niet getest met een ander besturingssysteem en heb ik het probleem niet verder onderzocht aangezien ik er niet vaak last van heb. Remote desktop vanuit de stepping stone omgeving werkt gewoon vloeiend en ik merk niet eens dat ik remote aan het werken ben.

Mocht iemand interesse hebben in de xrdp config let me know. Dan post ik deze morgen. Of als er nog andere vragen zijn hoor ik het graag.

[dikkehein]

ddkiller0900 schreef op donderdag 23 januari 2020 @ 00:01:
[...]


Eerst en vooral even de context aangeven van hoe wij op kantoor werken. We maken namelijk gebruik van een stepping stone (Windows server) om toegang te krijgen tot onze beheeromgeving door middel van Citrix.

In deze omgeving is alles best wel afgeschermd, zelfs voor een beheerder. Dit houdt in dat bv. een applicatie remote uitvoeren met X11 over SSH niet mogelijk is. Dit genoot mijn voorkeur aangezien ik dan eenvoudig een specifieke applicatie kan starten in plaats van een hele desktop en er geen GUI nodig is op de server. Doordat dit niet mogelijk is maak ik nu via remote desktop een verbinding naar deze server.

Wat in eerste instantie een VM moest worden om een testomgeving in te draaien, is inmiddels mijn eigen development omgeving geworden. Ik werk met Red Hat 7.x (weet even niet precies welke versie) server en heb daar Gnome 3 op geïnstalleerd. Verder zorgt xrdp ervoor dat ik remote kan inloggen. De instellingen heb ik vrij standaard gehouden. Eén van de voordelen van xrdp is dat je je sessie kunt hervatten. Al moet ik zeggen dat dit soms niet mogelijk is. Na wat uitzoekwerk kwam ik erachter dat dit te maken heeft met hoe xrdp zich gedraagt binnen Red Hat. Om eerlijk te zijn heb ik het nog niet getest met een ander besturingssysteem en heb ik het probleem niet verder onderzocht aangezien ik er niet vaak last van heb. Remote desktop vanuit de stepping stone omgeving werkt gewoon vloeiend en ik merk niet eens dat ik remote aan het werken ben.

Mocht iemand interesse hebben in de xrdp config let me know. Dan post ik deze morgen. Of als er nog andere vragen zijn hoor ik het graag.

Hmm ik ben dan wel benieuwd wat je hebt aangepast, of hoe jouw xrdp config er uit ziet. Ik heb zowel "standaard" als aangepaste instellingen geprobeerd. Beide werkten niet voor mij. Zou graag de config zien Dank!

[ddkiller0900]

dikkehein schreef op donderdag 23 januari 2020 @ 19:53:
[...]


Hmm ik ben dan wel benieuwd wat je hebt aangepast, of hoe jouw xrdp config er uit ziet. Ik heb zowel "standaard" als aangepaste instellingen geprobeerd. Beide werkten niet voor mij. Zou graag de config zien Dank!

/etc/xrdp/xrdp.ini

code:

[Globals]
; xrdp.ini file version number
ini_version=1

; fork a new process for each incoming connection
fork=true
; tcp port to listen
port=ask3389
; 'port' above should be connected to with vsock instead of tcp
use_vsock=false
; regulate if the listening socket use socket option tcp_nodelay
; no buffering will be performed in the TCP stack
tcp_nodelay=true
; regulate if the listening socket use socket option keepalive
; if the network connection disappear without close messages the connection will be closed
tcp_keepalive=true
#tcp_send_buffer_bytes=32768
#tcp_recv_buffer_bytes=32768

; security layer can be 'tls', 'rdp' or 'negotiate'
; for client compatible layer
security_layer=negotiate
; minimum security level allowed for client
; can be 'none', 'low', 'medium', 'high', 'fips'
crypt_level=high
; X.509 certificate and private key
; openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365
certificate=
key_file=
; set SSL protocols
; can be comma separated list of 'SSLv3', 'TLSv1', 'TLSv1.1', 'TLSv1.2', 'TLSv1.3'
ssl_protocols=TLSv1.2, TLSv1.3
; set TLS cipher suites
#tls_ciphers=HIGH

; Section name to use for automatic login if the client sends username
; and password. If empty, the domain name sent by the client is used.
; If empty and no domain name is given, the first suitable section in
; this file will be used.
autorun=

allow_channels=true
allow_multimon=true
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
#hidelogwindow=true
max_bpp=32
new_cursors=true
; fastpath - can be 'input', 'output', 'both', 'none'
use_fastpath=both
; when true, userid/password *must* be passed on cmd line
#require_credentials=true
; You can set the PAM error text in a gateway setup (MAX 256 chars)
#pamerrortxt=change your password according to policy at http://url

;
; colors used by windows in RGB format
;
blue=009cb5
grey=dedede
#black=000000
#dark_grey=808080
#blue=08246b
#dark_blue=08246b
#white=ffffff
#red=ff0000
#green=00ff00
#background=626c72

;
; configure login screen
;

; Login Screen Window Title
#ls_title=My Login Title

; top level window background color in RGB format
ls_top_window_bg_color=009cb5

; width and height of login screen
ls_width=350
ls_height=430

; login screen background color in RGB format
ls_bg_color=dedede

; optional background image filename (bmp format).
#ls_background_image=

; logo
; full path to bmp-file or file in shared folder
ls_logo_filename=
ls_logo_x_pos=55
ls_logo_y_pos=50

; for positioning labels such as username, password etc
ls_label_x_pos=30
ls_label_width=65

; for positioning text and combo boxes next to above labels
ls_input_x_pos=110
ls_input_width=210

; y pos for first label and combo box
ls_input_y_pos=220

; OK button
ls_btn_ok_x_pos=142
ls_btn_ok_y_pos=370
ls_btn_ok_width=85
ls_btn_ok_height=30

; Cancel button
ls_btn_cancel_x_pos=237
ls_btn_cancel_y_pos=370
ls_btn_cancel_width=85
ls_btn_cancel_height=30

[Logging]
LogFile=xrdp.log
LogLevel=DEBUG
EnableSyslog=true
SyslogLevel=DEBUG
; LogLevel and SysLogLevel could by any of: core, error, warning, info or debug

[Channels]
; Channel names not listed here will be blocked by XRDP.
; You can block any channel by setting its value to false.
; IMPORTANT! All channels are not supported in all use
; cases even if you set all values to true.
; You can override these settings on each session type
; These settings are only used if allow_channels=true
rdpdr=true
rdpsnd=true
drdynvc=true
cliprdr=true
rail=true
xrdpvr=true
tcutils=true

; for debugging xrdp, in section xrdp1, change port=-1 to this:
#port=/tmp/.xrdp/xrdp_display_10

; for debugging xrdp, add following line to section xrdp1
#chansrvport=/tmp/.xrdp/xrdp_chansrv_socket_7210


;
; Session types
;

; Some session types such as Xorg, X11rdp and Xvnc start a display server.
; Startup command-line parameters for the display server are configured
; in sesman.ini. See and configure also sesman.ini.
[Xvnc]
name=Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1
#xserverbpp=24
#delay_ms=2000

[Xorg]
name=Xorg
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
code=20

/etc/xrdp/sesman.ini

code:

;; See `man 5 sesman.ini` for details

[Globals]
ListenAddress=127.0.0.1
ListenPort=3350
EnableUserWindowManager=true
; Give in relative path to user's home directory
UserWindowManager=startwm.sh
; Give in full path or relative path to /etc/xrdp
DefaultWindowManager=startwm-bash.sh
; Give in full path or relative path to /etc/xrdp
ReconnectScript=reconnectwm.sh

[Security]
AllowRootLogin=true
MaxLoginRetry=4
TerminalServerUsers=tsusers
TerminalServerAdmins=tsadmins
; When AlwaysGroupCheck=false access will be permitted
; if the group TerminalServerUsers is not defined.
AlwaysGroupCheck=false
; When RestrictOutboundClipboard=true clipboard from the
; server is not pushed to the client.
RestrictOutboundClipboard=false

[Sessions]
;; X11DisplayOffset - x11 display number offset
; Type: integer
; Default: 10
X11DisplayOffset=10

;; MaxSessions - maximum number of connections to an xrdp server
; Type: integer
; Default: 0
MaxSessions=50

;; KillDisconnected - kill disconnected sessions
; Type: boolean
; Default: false
; if 1, true, or yes, kill session after 60 seconds
KillDisconnected=false

;; DisconnectedTimeLimit - when to kill idle sessions
; Type: integer
; Default: 0
; if not zero, the seconds before a disconnected session is killed
; min 60 seconds
DisconnectedTimeLimit=0

;; IdleTimeLimit (specify in second) - wait before disconnect idle sessions
; Type: integer
; Default: 0
; Set to 0 to disable idle disconnection.
IdleTimeLimit=0

;; Policy - session allocation policy
; Type: enum [ "Default" | "UBD" | "UBI" | "UBC" | "UBDI" | "UBDC" ]
; Default: Xrdp:<User,BitPerPixel> and Xvnc:<User,BitPerPixel,DisplaySize>
; "UBD" session per <User,BitPerPixel,DisplaySize>
; "UBI" session per <User,BitPerPixel,IPAddr>
; "UBC" session per <User,BitPerPixel,Connection>
; "UBDI" session per <User,BitPerPixel,DisplaySize,IPAddr>
; "UBDC" session per <User,BitPerPixel,DisplaySize,Connection>
Policy=Default

[Logging]
LogFile=xrdp-sesman.log
LogLevel=DEBUG
EnableSyslog=1
SyslogLevel=DEBUG

;
; Session definitions - startup command-line parameters for each session type
;

[Xorg]
; Specify the path of non-suid Xorg executable. It might differ depending
; on your distribution and version. The typical path is shown as follows:
;
; Fedora 26 or later    :  param=/usr/libexec/Xorg
; Debian 9 or later     :  param=/usr/lib/xorg/Xorg
; Ubuntu 16.04 or later :  param=/usr/lib/xorg/Xorg
; Arch Linux            :  param=/usr/lib/xorg-server/Xorg
; CentOS 7              :  param=/usr/bin/Xorg or param=Xorg
;
param=Xorg
; Leave the rest paramaters as-is unless you understand what will happen.
param=-config
param=xrdp/xorg.conf
param=-noreset
param=-nolisten
param=tcp
param=-logfile
param=.xorgxrdp.%s.log

[Xvnc]
param=Xvnc
param=-bs
param=-nolisten
param=tcp
param=-localhost
param=-dpi
param=96

[Chansrv]
; drive redirection, defaults to xrdp_client if not set
FuseMountName=thinclient_drives

[SessionVariables]
PULSE_SCRIPT=/etc/xrdp/pulse/default.pa