[X2go-dev] Ubuntu 9.10 and Kcontrol module

[John A. Sullivan III]

On Fri, 2010-04-02 at 19:23 +0200, Paul van der Vlis wrote:
> brian mullan schreef:
> > Paul van der Vlis <paul at ...> 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:
1) ignorance - we hope to look at them at some point
2) 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