<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"></head><body style="font-family:Arial;font-size:14px"><p>
        thanks to Peter for his clear recommendation :<br><br>
        my setup is now this (all servers are on Ubuntu 14.04 LTS 'trusty', running inside LXC containers, on a Ubuntu 14.04 LTS guest host) :<br>
        1) on the master TL server, I configured 2 known agent servers (will make that max 10 when all users are connecting)<br>
        2) I defined a new profile that runs the command "/opt/thinlinc/bin/tl-run-unixapp mate-session"<br>
        3) on the agent TL servers, I modified this (shell script) "/opt/thinlinc/bin/tl-run-unixapp" so that it does not use the fixed-coded list of UNIX application servers from "/opt/thinlinc/etc/conf.d/appservergroups.hconf", but instead applies my custom method to map a user-name with his 'private' agent-hostname :<br>
        instead of the line<br>
        X11SERVER=`echo ${X11SERVERS} | awk '{print $1}'`X11SERVER=`echo ${X11SERVERS} | awk '{print $1}'`<br>
        this will become<br>
        X11SERVER=`mymethodToMapUserVersusHostname $USER`<br><br>
        A side-note : because the "mate-session" is being launched on a server (the remote, per-user server) which does not run the X11-display server itself (it runs on the selected agent-server), I hit the long-time-discussed issue of 'dbus-launch' not terminating on the remote user-server because the X11-server process is not stopped yet.<br><br>
        Peter suggested correctly to replace the command in "tl-run-unixapp" script by the following :<br><br>
        echo "$@" | ${NOCTTY} ssh -Y -T ${USER}@${X11SERVER}<br>
        becomes<br>
        echo "$@ && pkill -u ${USER}" | ${NOCTTY} ssh -Y -T ${USER}@${X11SERVER}<br><br>
        so that all user processes (typically only "dbus" and "dbus-launch" are still there) are gracefully killed, releasing the SSH connection from the agent-server to the user-specific server, and thus releasing the session from the agent.<br><br>
        The elegant thing about this is : the per-user-specific LXC containers are very light-weight to start/stop, totally isolate each user's processes and home-dir from another, and can be created (takes 1min) during the new-user-registration process.<br><br><br>
        Quoting Rob De Langhe <<a href="mailto:rob.de.langhe@twistfare.be">rob.de.langhe@twistfare.be</a>>:</p>
<blockquote style="border-left:2px solid blue;margin-left:2px;padding-left:12px;" type="cite">
        <p>
                hy ThinLinc enthousiasts,<br><br>
                I am looking for a 'best practice' to box users in their individual virtual server.<br><br>
                At the highest level, I can choose to create individual terminal servers at the time where a new user gets defined in the system (that user list will probably be kept in LDAP). So this would become potentially many (10's, 100's or even 1000's) of terminal servers.<br>
                - disadvantages (if I understood well) : not sure (documentation?) how we can replace the load-balancing method of the VSM server by some mechanism to force the VSM server to startup a session on a specific terminal server for an authenticated user ; a bit of effort to develop the automated creation/drop of virtual servers when users are created/deleted<br>
                - advantages : user sessions are boxed ; virtual servers can be created and resources can be assigned/tuned dynamically<br><br>
                At a lower level, I can define 2 (or more?) terminal servers to startup all user sessions. Is there a way to replace the startup of a user session on the terminal server by a script which determines a virtual server to use for that user, starts that virtual server (1-2 seconds needed only) does a X11-forwarded SSH connection to that virtual server and starts there a GNOME2 (or whatever chosen) X11 session<br>
                - disadvantages : not sure (documentation?) how we can replace the session-startups on terminal servers by some new self-developed script (which will figure out the virtual server to use for this new session, startup that virtual server, SSH to it and starts session on it)<br>
                - advantages : any server and any UNIX flavor can act as guest host to run such virtual servers ; virtual servers are totally independent from ThinLinc ; more control over the actions performed by the script running on the ThinLinc terminal servers<br><br>
                Any comments, experiences, hints ?<br><br>
                best regards,<br>
                Rob</p>
</blockquote>
<br><br></body></html>