On Fri, 2010-04-02 at 19:23 +0200, Paul van der Vlis wrote:
brian mullan schreef:
Paul van der Vlis <paul@...> writes:
Cyril Vergne schreef: But there is a big problem about x2go on Ubuntu : No administration console. I am not sure what you exactly need. I don't use the administration module. You can live without it
Paul I think what the person was referring to was what I encountered lately.
If I download the x2go-server (full server) and follow the debian instructions for installing the "full server" on ubuntu (there was no example to do the same for ubuntu just debian)
http://www.x2go.org/uploads/tx_skpdfviewer/ installation_x2go_debian_en_01.pdf
The build/install fails because of dependency's on the kcontrol module which doesn't exist any longer in the ubuntu repositories. So I've yet to be able to try the full-version of the x2go solution.
I am a Gnome user so I don't want kcontrol-modules.
I have never tried them and never missed them. I think you can manage users with them in LDAP, but there are more ways to manage users in LDAP...
I don't know if that is a kde change that has occurred or what but for me I couldn't get that installation to succeed.
So I was left with x2go-home which does work well but its not meant to be scalable.
I use small installations, but I think you don't need this packages to be scalable. You need Postgres and LDAP. But maybe I am wrong. <snip> We are a KDE site. I have not used the tools for primarily two reasons:
- ignorance - we hope to look at them at some point
- Platform - we use CentOS Directory Server and not OpenLDAP. We will need to digest the schema and see how we port it before we can use it.
Regarding scalability, we are building an environment to accommodate thousands of X2Go desktops (hopefully - business plans are one thing - reality can be another). We also run one X2Go desktop per virtual machine using VServer in a fairly secure environment.
The scalability and platform issues are where we have made some changes. We use a central PostgreSQL server. We altered the X2Go database scripts to not use the PostgreSQL super user and to use one schema per desktop so no one can see another user's session information. We created a separate sessions table owned by the super user and updated from the desktop tables via a trigger. This gives us a central view of all sessions with restricted access.
We do not use x2gocleansessions on each desktop lest we have thousands of processes all hitting against the database every five seconds and each consuming CPU cycles on the desktop. It also requires more privileges in the virtual machine than we are willing to give based upon our security model. Instead, we disabled the x2goserver init script and moved the session cleaning to the VServer host which pulls upon the central session table.
We then centralized the printing on a single CUPS server and altered cups-x2go so that it can support multiple X2Go Servers. We pull the server information from the central session table (I believe - I haven't looked at that in a while).
So one can build a highly scalable environment. That doesn't mean the tools are not important. I suspect storing information in LDAP will be essential when the broker product becomes available. I suppose it is valuable now if one wants to eliminate manual configuration of the client. In our case, access is across the Internet for all users and the LDAP server is not publicly exposed. We've thus handled it another way. Hope this helps - John