 Yeah, and welcome to the last day of DebConf and we will start with a talk by Mike Gabriel about X2Go, terminal server, architecture, and yeah, enjoy. Yeah, welcome. My name is Mike Gabriel. I am a member of Upstream X2Go and also a Devin developer, which has been quite recent actually. In March. So what I would like to, thanks a lot, so what I would like to talk about is a an approach for a remote desktop solution that is not yet available in Debian and also has some difficulties to enter Debian at all because there's one component that is not, well, it's a component that's hard to chew on in the security team. So what I do first, it's actually, it's has been announced as a talk, but I would like to have it more as a both. So maybe people want to come a bit further so we can discuss about things. I have a lot of questions for the people in the room. So, yeah, it's it's rather both actually. So I'll have some notes on the gobby and here it is. So if you want to share notes on Debcon 13, boff and then X2Go. So how many of you use some sort of remote desktop solution like VNC like one, two, three, four, five, six, seven, eight, nine, ten. Okay. How many would need a better or, well, a remote desktop solution at all or a better one? Okay, right, right, right. So quite a few, actually. So may I ask what you use, actually? How many use VNC? One, two, three. Okay. How many use SSH minus capital X? One, two, three, four, five. Works well on the one connections, doesn't it? Pretty well. Okay. Well, not so well, actually. How many of you use XPRA? Yay. Okay. Okay. It works a bit better if you have a weak connection or if you have high latency on the network that we're working on, doesn't it? Okay. So it doesn't really matter, actually. Okay, right. We need a microphone for that guy. Thank you. You get a microphone. Isn't it? Well, I'm not upstream XPRA, so I don't know. I have tried it a couple of times because we are seeking for alternatives for our core functionality, but well, I wasn't so convinced about XPRA. It works fine for the seamless desktop integration of Windows, but it's for full desktop solutions and full screen, it's not designed for it. It breaks sometimes. So who uses free RDP as a server on Linux machines? So providing Linux desktops via free RDP, free RDP server. No one. Who has to access Windows desktops using RDP? Quite a few. Okay, right. Yeah. So that gives us quite an overview, actually. And how many of you are content with the solution you have? Okay, Keith. Right. Good. Ah, cool. Okay. So, yeah. So what is X2Go? X2Go is actually a bundle of packages. We call it X2Go components. Well, three of them are client-side, but they are exchangeable. So it's X2Go client and two tools that I've written. They're called Pyhoka. Py, because they have been written in Python. And Fokker, because the seal is the logo of the mascot of X2Go. And Fokker in Latin is the seal. So that's Pyhoka, and there's a GUI one, which is what looks like the network manager applet, actually. You have in GNOME or KDE or so. So you have a tiny icon on the right top of your screen or the bottom, wherever you have that, the system tray area or the indicator applet area. And from there you can control multisessions to multiservice. The native X2Go client application you have seen while I was logging in. It has originally been designed as a thin client logon manager, but you can also use it as a normal client application. The disadvantage of the current X2Go client is that you only can launch one session to one server per X2Go client instances. So if you have to hop on from one server to the other, or you have several servers and you want to open them at once, you need loads of X2Go client applications started and each of them can connect to one server, but it's a bit awkward. So that's why I designed the Pyhoka GUI application, actually. So the advantages of X2Go compared to other solutions are, or it is actually, it really scales quite well over one connections. My primary use case was system administration. So yes, SSH works for everyone, but we serve schools. I'm part of the Debian Editor team as well. So we support schools and we have content filtering on the firewalls and loads of requests are, well, I can't open this on that page. Can you check? And then I need a browser inside that school to check how the browser behaves within that infrastructure. So I need some graphical thing. Most schools are behind the DSL uplink and that was till last summer we had only 2048 kilobit per second uplink downstream. Upstream was even much slower. With X2Go, you can administrate those schools, those places graphically. So the features, the built-in features of X2Go are also client-side printing support. So I can print something in the terminal server session and it comes out of my printer at my desk. We have the possibility of sharing client-side folders or devices. So in thin client mode you can plug in a USB stick, USB flash drive and it appears as a desktop icon in your session. Depending on the desktop you use, sometimes it's not an icon, but anyway. Then there is a possibility with the native X2Go client to have GNU PG smart card authentication, which is you have your SSH key on the smart card, you have to unlock it by a GNU PG key and then this SSH key on the smart card is used for authentication. So you can have a set up where people have a card and shove it into a device and the session is on screen. Then quite recently we published a broker. So that is an HTTP server somewhere on the network and this serves the X2Go client with configuration setups depending on the user who is sitting in front of the screen. So session brokerage is quite an issue in Microsoft terminal server-based networks and that can be sort of imitated in X2Go as well. Load balancing, having multi-server sites, stuff like that. So then as some of you, those who have come early might have seen, I booted my very old EPC over the network. So I'm working inside of an X2Go session. So as you can see, I can scroll here. I could even open Mozilla Firefox and the flash video inside it like a YouTube video, it would stutter a little bit, but not too much actually. I can do that later maybe. So we have this thin client environment that needs some more fixes and then actually I plan to bring that to Debian as well. So the client side is pretty fine concerning Debian and Debian policy. And what we also have is we have bindings for several desktops. Bindings means like you mount a folder into the session and then there appears a desktop icon. Or binding means in this case if I go to a system in the Matty desktop and then I can suspend my X2Go session, which I will actually do now. Boom, gone. So, well now I'm in some sort of a company and I change my offers to go to meeting room or wherever. There's a terminal and I have the same setup there. I click and I can resume my earlier session. Okay, we have pulse audio support in it. So I can play sound on the thin client, just like normal thin client you would expect from it. So I get the sound from, that's the server over the network, pulse audio directly onto my machine. Everything in X2Go is designed to work over one SSH connection. So how many of you know free NX, NX server, no machine? Right, okay. So how many of you have found the public key there? Okay, the NX client ships a public key that works with every NX server. So the handshake in the session in NX, in free NX server is do one authentication as user NX with a pre-shared public key and then do the rest of the handshake, of the session handshake as the user ID that actually wants to connect. Next to go, we got rid of that completely. So what happens is that you do a normal SSH login and then some port forwarding and reverse port forwarding tunnels gets set up and through those tunnels SSHFS goes through for the fire system, for the printing support, pulls audio streams and the graphical stream goes through that. How that works I'll explain a little bit later actually. So what use cases can we have? Well one use case probably is you have a home box, you have IPv6 at home or a dynamic DNS, something like that. And you can access and then you forward the SSH port to one machine on your local network and you can work on your home box. So you can work on your, with the environment you have at home you can work on the data you have at home. So that's quite handy for many people actually. Then I have a customer in Denmark called Flatenet and they serve, they are canonical partners and they serve several schools and municipalities with remote desktops, YRX to go and they use Unity in 12.04. One of the limitations is that 12.04 was the last Unity version that can be used with X2Go, yes. One more question, what is it about using different resolutions in the screen you have at home and your laptop and so on, is it automatically scaled or what is used to use different resolutions? Resolutions, the resolution is, you mean like pixels on screen? Yes, correct. The resolution is always the one you select. So you can use a full screen mode like I have now here. You can use a desktop session locked into a window. You can have seamless applications. Seamless application would be, for example, with the Pahokar application, with the GUI application, you get a start menu, an application menu like you use from your local desktop but with the applications on the remote server and even with the icons those applications have on the remote server. So what you're probably asking is, how is the compression adapted to the connection I have? No, I mean at home I have 16,000 to 1,200 resolution. On my laptop I have 1,024 and I have to, it has to be managed to get rid of these differences because of window manager and so on. And some windows manager has to restart and so on. Okay, so how X2Go works, I come to that a little bit later. But basically you don't access the session you see on the monitor at home. So you don't, it's a possibility you can do that. It's an option or a feature. But normally you would just start your computer, don't log in, go to work and then start a remote session on your computer with the resolution your laptop provides. Yeah, okay. And when you change from one laptop to the next laptop on the next laptop is an EPC or a tiny network PC and the other one was just like 1,600 times 900 pixels. Then the sessions, most of the sessions supports rescaling. So it was on the large screen before it will be on the EPC and it will fit. Yeah, okay. So then there's a nice project with the same customer. It's called the Samsung project. And so what people tend to ask is, well, why do I have to use remote desktop solutions in Linux? I can use like live systems. I can use this workstations on a network. They scale much better in multimedia. But one use case is that's really nice in the Samsung project because they provide servers for students in Norway, for schools in Norway. And when these students go home or go to bed, then in Myanmar the servers are used. So they provide and the provision of the servers in Norway are free for the people in Myanmar. So it's a project for supporting that country actually. We also use it as a drop-in replacement for LTSP and Debian Edo deployments. LTSP is the Linux terminal server project, which works well but only on the local network. And I also know from a customer who uses, they have a huge core center, loads of core center agents like several hundreds. And they use a cluster, an extra go cluster for provisioning of the desktops that those people work at. And I have a customer in the Netherlands as well who uses it as a software as a service. So he just projects one application that is hosted on Linux servers on the Windows desktops with that approach. So yeah, so that was X2Go upstream. And now it's going to be about X2Go and Debian. So X2Go is partially in Debian already. That is only the client side. We have the X2Go client is in Weezy already and the Python clients are in Unstable and have also already entered Ubuntu. And I plan to bring the Thin Client environment into Debian as well. But that's all client-side. The issue about the server-side components I will come to in a very second and maybe some here in the room know actually what they are about. I see that someone is editing in Gobi. Could you do me a favor and look up the bug number for NXlips, the one with a long thread. Thank you. So basically what you have to do to get an insight into X2Go before it enters Debian is you have to add our archive, our packaging archive and so the URL is here on the screen. And on the server you need to install two packages. I recommend those two. Yeah, I don't know if I can that. Preferences, is it there? Okay, thanks. Oh yeah, here. Okay, right, I see. The down, left, oh yeah. Yeah, thank you. Okay, cool, okay, thank you. Good point. So on the server you just install X2Go Server X Session and X2Go Server Printing and then most of the X2Go Server works actually. That's another one that's quite nice because it does some general XDG desktop binding so that's this one. I know it jumps but let's do this one. Okay, here we go. On the client you either need X2Go Client or the Pahoka Client. And then once you've done that and if you have a user that can access the X2Go Server by your SSH then he can access it via X2Go and then you can get a graphical desktop. But we have challenges and that's actually the reason why I'm here. So the one challenge is basically the challenge is that the technology for getting the image onto the clients is old and works with desktop shells and applications that use the old fashioned X11 protocol. So whenever it comes to that the applications use a new widget library and a lot of rendering is already happening in the application itself. Then loads of bitmaps fly over the wire and these bitmaps this is not the dozen scale as well as it would be just the X rendering commands so that the rendering happens on the client side machine actually. But that's feasible. It still scales well actually. But the real issue we have is that the NX backend we use so we use stuff from no machine that is free that is GPL2 but that's like years ago, like years old and it is not so well maintained by no machine to fill that gap. We decided we as another DD actually is Raina Tatla, sorry, Tatla. So what we did is we did a redistribution of NX Lips and this NX Lips redistributed is already upstream or it's becoming upstream for Fedora at the moment and they have been communicating with Canonica and they are interested in having that in Ubuntu as well. So what we do there is we have a very complex giddy, kilt-based workflow that allows you to see what no machine originally did to the sources and when they upgrade some of the taboos, one of the components, we can merge that in and still have our patches separate from what no machine does and then we run loads of patches over it. Some of them are bug fixes, build fixes, feature add-on, stuff like that. But it's still very old code. Very old, I mean it's xoxx.9 with many, many security issues, patches missing. So what I am actually currently looking for is an alternative to that. And this is the part where I need your help, where I need your ideas. So one idea is there is a free RDP backend for Wayland, for Western. So that would serve the purpose of having a full desktop as a remote session. In Western you can have a complete desktop but you cannot have seamless applications as far as I know, not yet at the moment. Then there also is the idea of getting SFHario using SFHario so that at least on local networks the setup works. You won't be able to work over one connection but the idea is to find a way to get the X2Go server components into Debian and avoiding working around the NX code. So who have you have tried, how many of you have tried X2Go actually already? I saw Thomas, yeah, okay. So how many of you have sort of played with the thought of well what terminal server solutions, what remote desktop solutions can there be? Yes, okay. So what were your conclusions, Gerhard? I was in doubt to raise my hand from who is playing with remote desktop solutions. I'm from the age of Telnet as a sage, a colleague of mine 20, 25 years younger as me he has installed XRDP on his server that is in the cloud and for web browsers things he has a much better performance than when I go with SSH with X forwarding to the same machine. That is what I have been playing with desktops and I think I found a new candidate called X2Go. I suspend the session for now while we talk and launch a local desktop on my computer and then I show you the other client that we have. So we continue the discussion and while that my system here will reboot. Yeah, actually I have played with many of those and at the end if I have a well a non GNOME 3 based desktop let's say that as long as I have that it works quite well but the future of well GNOME is really out of choice GNOME 3 at the moment because it does not work and it won't work with 3.8 because they as far as I know they removed the 4-back session stuff in GNOME 3 for 3.8 but Keith might know better. You don't know. Oh, you have been at the conference so I thought you might know. I was at aquatic last week and I know that the while they are trying to remove the fallback session stuff they are providing a more classic desktop still using GNOME shell. And I suspect the rendering performance of that is going to be similar unfortunately to the other GNOME shell stuff. Fortunately there are a lot of other desktop choices like GNOME and in fact GNOME at this point is the minority desktop in the Debian environment. XFCE is definitely a more popular desktop environment. So what I have also started working on is the Marty desktop, the packaging team. And that is the one you saw actually on the screen it wasn't GNOME 2 it was Marty and that one works really well next to go as well. So yeah, the GTK 2 based desktops work really fine like LXDE, like XFCE, Marty, probably Ice we have stuff like that as well. KDE still works until it's still while it's still on Qt 4. I think in Qt 5 they will remove the native session support. Exactly yes. So the other screencasting technology that we are looking at in other environments is to move away from a remote graphics, rendering protocol and moving to remote video transmission. Using something like MPEG 4 or H.264 to transmit the contents of the screen which provides a scalable bandwidth option so that when things change quickly you get blur, you get a lot of artifacts on the screen and then when you have more time you can catch up and fill in at a lower resolution. I don't know how viable that is but it certainly provides a solution for 3D, 2D, modern desktops and all that kind of stuff. One of the advantages there is we can take advantage of the server compression hardware to do the video compression in the server. Yeah, so we have quite some plans around that actually. I have looked at the X624 encoding thing in XPRA and it works well if the latency on the network is fine but if that goes down then it's like watching an AVI over a stream. You have these clusters in the image that take some time to re-build and stuff like that. In terms of usability, in X2Go the mouse always moves even if the network goes down because the mouse pointer is local. In a streamed environment you are watching a movie so the mouse is in the movie. If the network is a hiccup or something then the mouse stops stuff like that. The usability is less. That's what I'm saying for the video transmission but adding to that the ability to do local mouse echoing definitely improves that. The question is whether we can take advantage of any local rendering at all given what modern desktops are going to. Certainly doing H.264, some other video encoding over the wire would make sure you could capture any desktop environment and then adding to that things like the local mouse echoing and all of the other services would provide a similar environment. I don't know what the bandwidth requirements would be. The nice thing about going to either something like X2Go or video encoding is that it's fairly latency insensitive and our network bandwidths are improving much faster than our latency is improving. In fact latency is getting worse in most environments. The question is whether a video environment would be adequate over a high bandwidth network. I did a bunch of research in a wrap in the early 2000s about network effects on the X window system and we built a synthetic network that would allow us to adjust the latency in bandwidth independently in the lab and that way you could actually see how the remote X session in this case worked over a higher latency or a lower bandwidth network and adjust those parameters independently in the lab so you wouldn't have to go around the world looking for specific network characteristics. In X2Go latency is a greater issue than bandwidth. Bandwidth can be really, really small. If the latency is like over 100 milliseconds then it becomes sluggy. There's another idea but it's just a question of manpower or financial power actually is that someone well we have one developer on the team who could do that that is Rebase. He changes that NoMachine did in XOR 6.1 and Rebase that against the latest XORC but that would need big cooperation between the XORC team on Freedest.org and the X2Go team actually because that should then really, really go upstream and at one point then even be maintained there with our support of course but changes in the XORC. What's the licensing on that code? There is the compression libraries in an XRGPL GPL2 without the plus. That's fine. There was a license change in XORC as well that actually should now make it possible to use the compression libraries with XORC but that has to be investigated again more thoroughly where someone really knows about licensing. My question is what's the license to the X server integrated changes not the external components? It's also GPL2 I think. The problem with that is that I can't maintain GPL2 patches inside the X server code without changing the license of the X server. That's always been the problem and while I would love to change the X server GPL2 it is MIT licensed at this point. Yes. Rebasing would become a rewrite then. You're welcome to rebase because you can ship an X server that's GPL2 with the NX patches. It won't be XORC then. I can't maintain those upstream. I can't ship that as the core X server. That's what happened five years ago, six years ago. That would be nice for now but then in terms of sustainability it won't work at all because we have that situation now. We have a fork that is so old and so insecure without anyone noticing actually but it would reproduce the problem in five years. The realistic solution there if you want to maintain patches in the X server tree is to construct something which is MIT licensed either as interface changes into an external library so that you could move the existing NX code into an external library and maintain that separately or as rewriting appropriate sections that are necessary inside the X server. Yeah. But still it's nothing one can do at the weekends. Probably not. I've never looked at the NX patches. I don't know how extensive they are. Any other comments so far? Questions? No, okay. So what I want to show you now is the other client. The X2Go client just looks like the login screen on... Oh, it's so dark. Yeah. So I'm on awesome so I don't have window decorations. So that's the X2Go client. You have a session cards here. You can click on one of those and then you can log on to one server. And I much prefer this one if I have a multiple server setup. So I can group my sessions, my preconfigured sessions and I can configure those with a right click button on this. Let's see, I take my notebook here for example and then I have loads of parameters that I can configure. I can, for example, if I'm in a window desktop mode I can configure the session title. So different windows, they can bear the name of the session I'm currently in. So that helps quite a bit actually, especially if they all look like a Debian Etude desktop and it's really getting confusing. You have several session types that you can connect to. So we tested Trinity actually as well. There is an RDP proxy via X2Go. So it means you have a gateway that runs an X2Go server and you have RDP servers behind that gateway and you use the NX compression, access this gateway and have a local RDP connection on the internet of a remote site. Then you can launch single applications and you can also do something like Citrix does. It's called publish applications. I can show that in a minute actually. Then you can play with the connection. You have SSH agent forwarding support. Oh, it's German actually, I just realized. So what you can do is you do SSH minus add, log on to one session and you can reuse your local key in that session to hop onto other servers on that remote network site. You can use an SSH proxy on the way. So, keep. It's a fun look in your face while doing this here. So that means if you have some site and you have a gateway on that site and you have X2Go servers behind that gateway, not RDP now, then you can jump to this gateway via SSH, set up a tunnel that goes through the gateway to the target server and then start remote session there. And there is actually in the native X2Go client, the blue one, there is a patch in it that does that via HTTP. It hasn't been tested because that well because the lib SSH patch that is required for that is not yet stable, but it's coming. So what else do we have? Then you can play with the connection speed and latency you have. You can do something with the compression, but the default is just fine. And then you can, well, the application, do you want a full screen? Do I want to maximize window with a desktop session inside? Or do you want to have a custom window, custom size? The native X2Go client already has Xenorama support. So you can have like three screens and either let the sessions pop on one specific screen or have used all of these three screens for one session. And then inside the session, the windows know where the one monitor ends so that's quite nice. Then you can have auto configuration of the server side keyboard. So the client side keyboard gets recognized on the client or is configured on the client pretty well and that one appears preconfigured in the session. So you can be sure that your local keyboard mostly works unless you have a Mac then it doesn't work. So we have pulled out your support. We used to have art support when that was still alive and you can optionally switch to ESD support but I don't ever do that because ESD is normally emulated why it puts audio, so why? And then you can connect client side folders and that can be configured like do connect them when the session starts but I can also connect folders whenever I need them on demand. So I go back to the goby. Yay. Are there any more questions at the moment? Okay. Criticisms. Is there anything that's in your mind that's sort of, well, this old code or whatever? One discussion we had in the ITP we will look it up in a minute when has somebody entered it into the goby text? Yes, I see that, okay, right. So I resumed the session that I had earlier. So in terms of getting X2Go more known which will be then maybe a means to get the manpower issue fixed or get it improved. Well, we have that in Debbie and Edward where that manpower is always an issue but in X2Go especially it is that it is mostly known in Germany sometimes in some countries in Europe and there are quite a few people who are mailing this from the US, from Russia. But it's, in Germany it is an issue. So we have the Linux magazine and there are articles in that one but what is needed more is that it gets more known internationally so that we get more input from other people actually. So and then this would be, this is one reason why I really would like to see that in Debbie. But for that we have this NX issue. Okay, there's the bug number. So if you have some time this afternoon try to go through it. It takes an hour or so to read it and it actually also contains a history of why NX is a fork. What happened like when the Italian company No Machine started working on NX, what happened then? It also contains all the criticisms in terms of security, why NX cannot be in Debian while we have to ship those packages via an external archive. So but I think if more people start using it and if more people start contributing we are NX upstream for, we can be NX upstream for Debian because we redistribute. So there can be an effort to get things patched more well while we also have the idea of rebasing code but not actually outside upstream XORG. That wouldn't make sense to me. I think in order to get this integrated into XORG ideally what would happen, one of the resistances that X had historically was against GPLv2 modules even in upstream. We don't have that problem anymore. We have some GPLv2 code in external drivers and as long as those external drivers aren't required to run X then that's just fine. So if there's an NX2 video driver and NX2 input driver and those are GPLv2 that would be fine. Hang on for a second. Actually the NX agent which is the application that is used is a hardware thing. So you have this HW and then loads of different hardware drivers and it's a virtual hardware driver actually. So I think it might be actually plugable. Yeah exactly. Well in fact if there's a hardware driver that's GPLv2 we can have that in the X server source code that would be just fine. The key is any changes that need to be made into the core server to support that hardware we need to make sure those are MIT licensed. We are not the copyright holders only. So you need to rewrite. So if there are patches into the X server or core code base to support that. Yes there are actually. Then we'd have to rewrite those and re-license those under MIT. The reason why this scales so well over the network is over a slow network connection is that the no machine people got rid of the round trips in X. So the redrawing of the screen with every action you take. Well just like RDP or VNC. Yeah but RDP and VNC are both capturing methods. So it's like you put a camera for that acceleration for simple rendering operations and VNC does not but like the Citrix ICA protocol is very similar to what NX did in terms of capturing the rendering commands draw line draw characters and forwarding those and then with a backup of a general screen capture technique and I never looked at NX but I assume it's basically the same as ICA except without the horrible serial protocol. Okay we're just right before the end is there anything that you want to ask? Okay if you want to get more demonstration effects to go I'll be here till tomorrow morning. So just come by meet me in the bar and I show you more stuff like the broker or something that we have. Okay thanks a lot then.