
 2. Desktop Sessions - Secure User Interfaces
 ============================================

   The basic idea behind ctys is to support a common access framework
   for a combined environment 

     - intermixed with multiple OS(Unix, Windows)
     - running on distributed and intermixed 
     - physical and virtual platforms. 

   Therefore some common software plugins like VNC, X11, XEN, SSH,
   Kerberos, LDAP and automount are combined together by usage of ctys
   in order to supply simplified creation and transparent access to
   sessions.

   The implementation of ctys as a "bash" based shell script provides
   flexibility when using it within login-profiles, for batch files,
   and ineractivly from the desktop.

   The management of the sessions client windows on X11 based destops
   is supported broadly, as probably one of the most important task
   for distributed environments. Therefore the X11-geometry option is
   extended based on the standard configuration file "xorg.conf". Any
   position related section, including multiple "LayoutSections" could
   be addressed symbolical or numerical. Particularly in Xinerama mode
   the required offsets for windows positions are calculated as
   required, also when symbolic Screen-Names are used for
   extendedGeometry. The resolutions of servers and clients could be
   set seperately within one call, when supported by the sessions base
   application like VNC. In addition the addressing means of "wmctrl"
   for multiple desktops are supported when the tool is detected.

   The titles of the windows, which are visible on the desktop and
   as labels within the taskbar, could be used in a syntactically
   unified manner for addressing any ctys managed session. 

   The resulting calls could be particularly for pre-set default
   values quite simple:


     ctys -a CREATE=label:CONSOLE,REUSE host01


   This line first checks on the host01 whether a VNC session with
   label "CONSOLE" is already running. If so, a server-local vncviewer
   is started and connected to that server-process. The whole
   connection, including the display forwarding is established through
   an SSH tunnel.  When no session with given label exists, a new one
   is started and connected to a vncviewer.

   Next example starts a VMware-Workstation/Server/Player with native
   gui on the host "host01".


     ctys -t vmw  -a CREATE=fname:'vmware/openbsd-001.vmx',REUSE host01


   or


     ctys -t vmw  -a CREATE=id:'vmware/openbsd-001.vmx',REUSE host01


   or


     ctys -t vmw  -a CREATE=label:OpenBSD-001,REUSE  host01


   Last three examples are executed with the identical vmx-file, if
   "label:OpenBSD-001" matches "displayName" within
   "fname:vmware/openbsd-001.vmx", which will be searched by "find"
   command.


   The VM is immediately opened and executed due to default
   call options "-x -q -l". The GUI is closed when VM is shutdown.
   The vmx-file is located relative to caller's remote HOME. The
   default mode is "-L DisplayForwarding", which starts a coallocated
   client on the same machine as the server component is executed.


   One of the basic advantage is the comprehensive unification of
   addresses for sessions with the introduction of a common addressing
   layer. This assures a common means of direct or indirect user
   defined LABELS as an alias for usage as sessions identifier. The
   mapping will be done completely dynamic, so no persistent extra
   database is required.  Mapping for VMs is based on their various
   "name-entries", e.g. the Domain-Name or the Display-Name.

   The LABEL is forced to be visible on several places, so it is used
   as call option, windows title, or if no otherwise possible as a
   masked comment on CLI, still visible with ps-command. Due to usage
   as window title it is visible in the taskbars of most destop
   managers.

   These LABELs will be used for the "ssh-tunnel" call too, so a simple
   ps will show which "tunnel" is related to which session, displaying
   it's ports and various sessions parameters for 
   "-L ConnectionForwarding".

   Be aware, that security could be seen as almost perfect for network
   packages, but lower, once local access is provided. Same as for
   Kerberos e.g.

   In addition some handy extensions are available, like using UUIDs,
   MAC-addresses, TCP/IP-addresses for addressing of VMs. This could
   be used by defining path prefixes for "find and scan" options,
   which even allows the move of VMs without change of addressing.


   2.1 Security and authorization assumptions
   ==========================================

    Ctys itself utilizes SSH with port forwarding, though utilizes the
    security mechanisms of SSH and additionyl components. If any kind
    of pre-configured direct or indirect network login is supported
    such as SSO by the underlying systems, no additional user
    interaction is required for authorization.
 
    If you have not set up such a network login, you have to type your
    password by means of SSH each time you access a remote account,
    which could be somewhat threatening, when you use a bulk feature
    for tests or automatically open several remote sessions during
    execution of your login scripts. 
 
    Thus, most benefit is given when any kind of an SSO is provided,
    particularly with kerberos and SSH, probably in combination with
    LDAP and an LDAP based automount.
 
    Another point to underline here is the "-b" option, which
    internally leads to a call of ssh with it's "-f" option. The "-f"
    option of ssh handles forking of processes to background operation
    after required authorisation dialog, such as password entry when no
    SSO is provided.  So, the "-b" option forces the ssh-client into
    background operation for immediate release of the current console.
 
    Do not use "&" instead.
 
    For some display functions such as ENUMERATION or LIST synchronous
    operations is default and might be preferred.

  

   2.2 Reference X11-ServerLayouts
   ===============================

    The most of the following examples are based on the monitor array
    described here. Each screen is configured as 1280x1024, with the
    following ServerLayout. The Identifier="Layout[all]" is as default
    of Gnome/Xorg, but any number of specified ServerLayouts as
    supported by X11 is applicable and could be addressed of
    course. Any number of Screens in any combination and mapping, as
    well as related indexing is supported.
 

    REMARK:

     1.There is some minor limitation within this version. This is due
       to the calculations of screen positions for logical addressing
       screens by their numbers or labels - see "-g" option of ctys. 

       The keywords for configuration of X11 - such as "leftof" - are
       not supported within the so called "geometryEx" internal
       position calculations for logical screen addressing. 

       Therefore the absolute screen positions as numerical values
       have to be used within xorg.conf. This is e.g. the default for
       CentOS based distributions and current versions of NVidia
       utilities.

     2.The usage of "-" as minus for screen positions of geometry
       is not supported in this version.

       This seems not to be a real thread, because the supported
       platforms have positive absolute positions only. 

       Relative addressing from a viewpoint other than the standard
       (0,0) is not supported.

 
    Following is an overview of the reference ServerLayout.
 
 
    2.2.1 Physical Layout-1
     ----------------------
 
     This example is a physical layout with several low-cost dual-port
     graphic cards, all screens are attached to the same computer. The
     X11 operations mode is Xinerama.
 

                                                   +---+
     +---------+---------+---------+---------+    /   /|
     |0,0      |1280.0   |2560,0   |3840,0   |   +---+ |
     |Screen3  |Screen4  |Screen5  |Screen6  |---|   | |
     |3        |4        |5        |6        | . | W | |
     +---------++-+------+---+-+---+---------+ . | S | |
     |0,1024    | |1280,1024 | |2560,1024    | . |   | + 
     |Screen1   | |Screen0   | |Screen2      |---|   |/ 
     |1         | |0         | |2            |   +-+-+     
     +----------+ +----------+ +-------------+     |
                                                   |
                   +--------+  +-+                 |
                   |keyboard|--|m|-----------------+
                   +--------+  +-+                 
                       O                           
                     --+-- 
                       |        
                      / \       
 

    2.2.1.1. Logical Layout-1a - standard X11-mapping
     ------------------------------------------------
 
     The logical representation of the previous physical layout within
     "/etc/X11/xorg.conf" is as follows. The X11 operations mode is
     Xinerama.

 
 
     +---------+---------+---------+---------+
     |0,0      |1280.0   |2560,0   |3840,0   |
     |Screen3  |Screen4  |Screen5  |Screen6  |
     |3        |4        |5        |6        |
     +---------+---------+---------+---------+
     |0,1024   |1280.1024|2560,1024|          
     |Screen1  |Screen0  |Screen2  |
     |1        |0        |2        |         
     +---------+---------+---------+ 


     The Screen numbering here was the original positioning on the
     first motherboard on the used workstation with 1xAGP and multiple
     PCI graphichs cards. Each of which had 2 Ports and GPUs, some
     were actually connected to one monitor only. 

     Based on this the cabling was designed and numbered, and of
     course installed in the "cable-tree". These more or less fixes
     the connectors in the "bulk" of the cabling bundle.

                           
    2.2.1.2. Logical Layout-1b - X11-re-mapping - Labels
     ---------------------------------------------------
 
     The logical representation of the previous physical layout within
     "/etc/X11/xorg.conf" changed as follows after required changing
     of the motherboard. This is due to the fact, that the new
     motherboard has 2 PCIe and 4 PCI slots, whereas the old had 1 AGP
     and 5 PCI slots. The slots are intermixed by their positions due
     to the assumption of the manufacturer for utilization some SLI
     cards with oversized thickness. Anyhow, due to less importance of
     graphics processing itself only fanless and low-power standard
     GPUs with standard sizes are used.

     The numbering order of the busses changed due to the different
     interconnection of chipset and it's busses and the physical
     positions of it's slots, though the plugin positions. Thus the
     physical positions of the logical X11 screen names changed too. 


     +---------+---------+---------+---------+
     |0,0      |1280.0   |2560,0   |3840,0   |
     |Screen1* |Screen4  |Screen3* |Screen6  |
     |1*       |4        |3*       |6        |
     +---------+---------+---------+---------+
     |0,1024   |1280.1024|2560,1024|          
     |Screen5* |Screen0  |Screen2  |
     |5*       |0        |2        |         
     +---------+---------+---------+ 


     So due to logical remapping of the screen positions it was not
     neccessary to reposition the cables, but just to redefine some
     labels.

     By manual configuration of names within "/etc/X11/xorg.conf" the
     above array could be prepared for logical addressing.

     One possible naming could be an 2-dimensional array simulating
     Index-Style.

     +---------+---------+---------+---------+
     |0,0      |1280.0   |2560,0   |3840,0   |
     |A00      |A10      |A20      |A30      |
     |1*       |4        |3*       |6        |
     +---------+---------+---------+---------+
     |0,1024   |1280.1024|2560,1024|          
     |A01      |A11      |A21      |
     |5*       |0        |2        |         
     +---------+---------+---------+ 


     Now the physical "Screen3", which became the logical "Screen1*",
     could be addressed as "A00", the "Screen5*" as "A01".


        label    | physical  | #logical
       ----------+-----------+----------
        A00      | Screen3   | 1*
        A10      | Screen4   | 4
        A20      | Screen5   | 3*
        A30      | Screen6   | 6
        A01      | Screen1   | 5*
        A11      | Screen0   | 0
        A21      | Screen2   | 2


     These symbolic names could be literally used within ctys the "-g"
     options and it's value <geometryExt>.
 
    2.2.1.3. Logical Layout-1c - Gnome + vmctrl
     ------------------------------------------
 
     In addition to addressing physical screens and positions, the
     full scope of GNOME desktops is supported. 

     The workspace feature is utilized by usage of the tool
     "wmctrl". Thus a fully qualified addressing is provided by
     encapsulating the whole set of tools within a seamless view.
 
     The following functionality is only available when "wmctrl" is
     installed appropriately, else the optional path element of
     workspace is just ignored and the current visible workspace is
     used.



 
     Workspace-1 ->  +---------+---------+---------+---------+
                     |0,0      |1280,0   |2560,0   |3840,0   |
     Workspace-0 ->+---------+---------+---------+---------+ |
                   |0,0      |1280,0   |2560,0   |3840,0   | |
                   |Screen3  |Screen4  |Screen5  |Screen6  |-+
                   |3        |4        |5        |6        |
                   +---------+---------+---------+---------+
                   |0,1024   |1280.1024|2560,1024| |         
                   |Screen1  |Screen0  |Screen2  |-+
                   |1        |0        |2        |
                   +---------+---------+---------+ 
 


    Desktops/Workspaces could be selected by their numerical
    index or literally by the user configured string-representation.

    Within the user supported labels of Desktops/Workspaces SPACES are
    not supported, and the usage of SPECIAL CHARACTERS should be
    avoided, else the numerical ID could be used only.


    2.2.2. Physical Layout-2
     -----------------------
 
     This example is a physical layout with several low-cost dual-port
     graphic cards, which are attached to multiple computers. In
     addition two touch screens are attached to the first machine.
     The touch screens are supporting complex context specific User
     Interfaces for quick decisions of applications operators.  The
     size of the monitor only screens are given as 1280x1024, whereas
     the sizes of the touch screen is Screen8(1048x768). The Number of
     the screens is yust limited by processing capacitiy.
 


 
                                                             -----
                                                            /     \ 
                                                      +----<  LAN  >-----+
                                                    +-+-+   \     /    +-+-+
      +---------+---------+---------+---------+    /   /|    -----    /   /|
      |0,0      |1280.0   |2560,0   |3840,0   |   +---+ |            +---+ |
      |Screen3  |Screen4  |Screen5  |Screen6  |---|   | |            |   | |
      |3        |4        |5        |6        | . | W | | +--------+ | W | |
      +---------++-+------+---+-+---+---------+ . | S | | |3840,0  | | S | |
      |0,1024    | |1280.1024 | |2560,1024    | . | 1 | + |Screen7 +-+ 2 | +  
      |Screen1   | |Screen0   | |Screen2      |---|   |/  |7       | |   |/
      |1         | |0         | |2            |   +-+-+   +--------+ +---+    
      +----------+ +----------+ +-------------+     |                  
                                                    |                  
                    +--------+  +-+                 |                  
                    |keyboard|--|m|-----------------+                  
                    +--------+  +-+                 |                  
                        O                           |                  
                      --+--        +---------+      |                  
                        |          |4884,0   |      |                  
                       / \         |Screen8  +------+                  
                                   |8        |      
                                   +---------+      
                      
  



     This configuration is in current version supported by means of
     the package Xdmx, which has to be preconfigured. Based on this
     configuration the virtual screen - e.g. in Xinerama-Mode - will
     be managed by ctys.


   2.3. Handling of Client-Session-Windows
   =======================================
 
     This section handles primarily the functionality related to
     visual layout on the desktop. Even though the type of session
     involves in cases of a virtual machine the startup and/or
     connection to that, this will be focused in the next chapter, the
     visual aspects are reviewed here.
 
     So the following basic configuration is the standard case to be
     handled. It represents a close peer-to-peer relation of a client
     initiating the session and a server which hosts the applications
     a.k.a. XClients. In this case the Client only serves as a thin
     client which just executes the vncviewer. Two standard cases are
     supported. First, the Xserver and Xclients for the application
     are all together located on the server. Second, the Xserver
     located on the server, whereas the Xclients is started on the
     client. In both cases the communications is performed
     port-forwarding feature of ssh.


 
 
         +----------+       +--------+
        /          /|      /        /|
       +----------+ |     +--------+ |
       |          | |     |+-+     | |
       |        +>+------>+| |     | |
       |        | | |     |+-+     +------+
       | Server | | |     | Client | +    |
       |        +-+<------+<---+   |/     |
       +----------+/      +----+---+      |
                          +--------+  +-+ |                  
                          |keyboard|--|m|-+                  
                          +--------+  +-+ 
                              O  
                            --+--
                              | 
                             / \
 


 
 
     Setting up a layout based on xorg.conf-entries will be done for
     example by the following call:

 
     "ctys -t vmw -a CREATE='f:vmware/openbsd-001.vmx' \
        -g "600x400+2660+100" host01"

 
     This Starts a VMware-Workstation/Server session on a Xinerama
     group with offsets and size given by "-g" parameter.
 
     The given values yield to a GUI-Window on "Screen5" with Index=5
     which is in the offset range of +2600+100. The upper left corner
     has the coordinates (2560,0), thus window is positioned with an
     relative offset of (100,100)=+100+100.
 
     Starts a VMware-Server session on a Xinerama group with offsets
     and size given by "-g" parameter. The given values yield to a
     GUI-Window on "Screen5" with Index=5. The upper left corner has
     the coordinates (2560,0), thus window is positioned with an
     relative offset of (100,100)=+100+100.

 
     Same could be now given in one of the following ways:

 
     ->FullyQualified Screen-Addressing by labels from xorg.conf.

 
       ctys -t vmw -a CREATE='f:vmware/openbsd-001.vmx' \
          -b on -g "600x400+100+100:Screen5:ServerLayout" host01

 
 
     ->Qualified Screen-Addressing by labels from xorg.conf, using
       the default for missing ServerLayout, which is defined as
       "take the first section".
 

       ctys -t vmw -a CREATE='f:vmware/openbsd-001.vmx' \
          -b on -g "600x400+100+100:Screen5"  host01
 
 
     ->Same as before, but using the numerical index of the screen 
       instead of it's label.

   
       ctys -t vmw -a CREATE='f:vmware/openbsd-001.vmx' \
          -b on -g "600x400+100+100:5" host01
 
 
     Things become even easier when using default sizes, which is the
     full-screen. The following opens a VNC session, which is the 
     default for the "-t"- sessionType-option.
 

       ctys -b on -a cREaTe='l:CONSOLE'  -g ":5" root@host01

 
     or

   
       ctys -b on -a CrReAtE='l:CONSOLE' -g ":Screen5" root@host01
 

     or

 
       ctys -b on -a CrReAtE='l:CONSOLE' -g ":Screen5" -l root host01
 
 
        Remark: Keywords are case-insensitive and handled internally 
                with uppercase for keywords only.

 
     The previous examples open a session window of a vncviewer for a
     VNC session and set the title to "CONSOLE". The login is performed
     as the user "root@host01" of course.
 
 
     Another build-in feature of VNC-sessions is the stateless
     operation, and the automatic session-takeover by another login.
     Thus the shift of a Client-Window to another position on screen or
     to another machine is performed on-the-fly when the new one is
     opened. No additional user interaction for tykeover is required.
 
     Following opens the same window on "Screen3" and closes old one on
     "Screen5" with new sizes.
 

       ctys -b on -a create=connect,id:1 -g "300x300+500+600:3" \
           root@host01
 
 
 
     Conditional connect or - if not present - creation is supported
     too by the "REUSE" flag of the CREATE-mode.
 
     Following creates a new window on "Screen4"(assuming this is a new
     session).
 

       ctys -b on -a create=l:TST1,REUSE -g "300x300+500+600:4" host01

 
     Following opens the same sesion in another window on "Screen5" and
     closes old one on "Screen4" with new sizes.

 
       ctys -b on -a create=l:TST1,REUSE -g "300x300+500+600:5" host01

 
     That's it related to desktop layout.
 
 
   2.4. Bulk access 
   ================

    2.4.1. Multiple targets and desktops
     -----------------------------------
 
     This features enable the access of multiple targets with one call.
     The buld features are particularly helpful for installation or
     update of this tool, start standard sessions - e.g. CONSOLE - on
     multiple hosts for the current(which is DEFAULT) or a given user.
     When "-t" option is not supplied th default "VNC" is used.
 

       ctys -b on -a create=l:CONSOLE -l user01 host01 host02 host03

     
     Another approach is to start a defined number of sessions on each 
     machine:
 
 
     REMARK: The number is currently limited to maximum=20.  
             Yes, ... this piece of software is buggy - as any other.  
 
             So, an erroneous count - e.g. of 1000 - could have
             effects on the target host which you might not agree,
             particularly when using it on a critical system. Be aware
             of this when changing the limit.
 
             I accidentally started some hundreds during tests, which
             unfortunately happens so fast that nothing else than a
             "hard-reboot" had aggreed to be performed within this
             century...


 
       ctys -b on -a create=10,l:CONSOLE -L ServerOnly \
          host01 host02 host03

 

     Which makes 30 sessions for current user, but due to "-L" option
     no clients are started. Just the VNCserver is executed. The label
     will be indexed in this case by an incremental postfix unique
     within current session.
 

       ctys -b on -a create=connect,id:1,id:2,l:CONSOLE,id:9 \
           host01 host02

  
     This connects to the sessions on each of given host.
 
 
     Each host could be set individually with any option available,
     particularly individual "geometry" parameters are supported.
  

     For any VM based sesion several addressing schemas are supported,
     so e.g. the following call searches a given base directory for
     vmx-file for the given UUID and when matching it the VM will be
     started:


        ctys -t vmw \
             -a create="uuid:01123...123",base:vmware/dir2,RECONNECT \
             -D admin \
             -g 800x500+100+400:5 \
             -L ConnectionForwarding \
             -W \
             host01


     That's what happens behind the scenes:

       - Due to RECONNECT any locally running client will be terminated,
         on the server(host01) and on the callers machine.

       - On the caller machine, due to the "-L" option caussing the client
         to be excuted on the local machine and "digging an encrypted
         tunnel" to the server.

         REMARK: Currently requires VMware-Server locally and remote,
                 will be checked during init, and rejected if not.

       - The window of the client will be started on the desktop named
         by the user as "admin" due to "-D" option. Alternatively the
         numerical ID could be used.

       - The size and position of the window will be set by "-g"
         option as defined by geometryExtended, which is X11 geometry
         semantics(for now only '+' are allowed). In addition the
         screen number of "/etc/X11/xorg.conf" will be used for the
         offset.

         Following an display of the clients window with size
         "800x500" on screen 5 with the offset of "+100+400".

         The server resolution is set by default to the viewer size.

         REMARK: Requires the deactivation of Edit->Preferences
                 AutofitWindow and AutofitGuest, otherwise the
                 position is only set.


     Almost any supported option could be set for specific hosts only,
     superposing the current state:


        ctys -t vmw \
             -a create="uuid:01123...123",base:vmware/dir2,RECONNECT \
             -D admin \
             -g 800x500+100+400:5 \
             -L ConnectionForwarding \
             -W \
             -- \
             host01 \
             host02'(-t vnc -a create=connect,i:2 -g :4)' \
             host03'(-t vnc -a create=connect,l:CONSOLE \
                     -g :3 -r 1600x1280)' \
             host04'(-t vnc -a create=l:TST,REUSE -L DF)'\
             host05'(-t vnc -a create=l:TST -L SO -r 1280x1024 -D 1)'


     Yes, it (hopefully still) works:

     - host01
       Created as before.

     - host02
       Connects a local vncviewer to VNC session with ":2", and opens
       a window on desktop "admin" screen #4. 

     - host03
       Connects to VNC server with LABEL="CONSOLE" and opens on screen
       #3. The server resolution is set to "1600x1280", whereas the
       viewer size remains as "800x500", thus scrollbars appear.

     - host04
       Creates if not present, a 3 new sessions, naming them "TST001,
       TST002, TST003" and running the vncviewer with
       "DF=DisplayForwarding". If e.g. the session ":2" is already
       present it will be reused, else created.

       The server resolution is for newly created sessions still set
       to "1600x1280", whereas the viewer size remains as "800x500",
       thus scrollbars appear. This is due to chained superposing
       without reset.

     - host05
       Similiar to host04, but now no client is started
       (SO=ServerOnly) and already present servers lead to an abrupt
       cancel of execution. The already created sessions still
       continue to be executed, no automatic cancel for partial jobs
       is applied.

       The window will be displayed on desktop "#1", which might be
       different or not from the desktop as labeled "admin" by the
       user.


     For additional examples refer to the chapter "EXAMPLES-BASE" or
     use the online help for displaying the EXAMPLES only:


      "ctys -H "EXAMPLES"


     For additional description refer to the options itself. 


    2.4.2. Group Concept
     -------------------

     Additional to supplying multiple targets just enumerated one by
     one, where each is a single host, ctys supports the concept of
     groups. Therefore an ordinary file has to be created within a
     standards configuration directory and filled with an arbitrary
     number of host names or nested include assignments.

     The literal name of the groupfile could be used as a fully
     functional replacement of any target. Multiple groupnames are
     supported as well as intermixed groupnames with hostnames.

     E.g. the following construct could be used for a group:


      ...myGroup1'(:A20)' myHost1'(-d 99)' myGroup'(-W -g :A10)'...


     The groupfile contains any comma seperated number of hostnames
     each line. Single host per lines is applicable too.

     Any level of nested includes is supported, therefore the include
     statement has to be at the beginning of the line:

       "#include <groupname>

     Circular inclusion will be detected at an default level of 20 and
     terminated than.

     Comment lines begin with a "#", empty lines are ignored.

     Due to integrated caching of expanded groups within the common
     nameservice, the "ctys-vhost" utility supports the visualization
     of configured groups in a strutured manners, tree-view is planned
     to follow.


     REMARK: The order of listed targets cannot be relied on, it is
             slightly varied, due to implementation eas by
             includes-first evaluation.


     One example of groups expansion is given as follows:

       "ctys -a list MYGROUP01'(-d 99)' hostX MYGROUP02'(-d 3)'"

         -> group:MYGROUP01

                "#include MYINCLUDE"
                "host01,host02"
                "host03"

         -> group:MYGROUP02

                "hostZ"

         -> group:MYINCLUDE

            contents of MYINCLUDE:

                "hostA"
                "hostB"

         resulting call is - with MODIFIED ORDER:

         "ctys -a list                                        \
              hostA'(-d 99)' hostB'(-d 99)'                   \
              hostZ'(-d 99)'                                  \
              hostX'(-d 99)'                                  \
              host01'(-d 99)' host02'(-d 99)'host03'(-d 99)'  \
              "

     Any host entry within a group-file could be supported with
     specific context options. Thus the group feature implements an
     almost full scale MACRO feature for on-call access. 

     This could be helpful e.g. as predefined shutdown and suspend,
     and start-up groups. E.g. it is now an easy task to gracefully
     handle all PMs with all the currently executed VM stacks, which
     are connected to one UPS, which signaly an alarm. Predefined
     escalation-shutdown groups, in order to expand the remaining
     backup-time for higher-priority tasks could be setup and
     preconfigured easily.

     Generally coul be said, nesting of braces is NOT supported, but
     chaining of brase IS. Permutation is performed for now only for
     the first level of group resolution, which might change, when
     implementing a some more sophisticated scanner/parser.

     One specific point to be aware of is, that due to the following

     1. re-ordering of entries
     2. the "from-set-on" for all relevant, but not resetted values
        of the overwritten context options

     it has to be underlined, that when using context options within a
     group file, all items has to be set explicitly, or none at
     all. Other wise a number of side effects might occur due to
     unexpected mixture and interference of options from various
     contexts.

     This results technically from the decision to eas of design and
     implementation caused by support of limited namespace
     capabilities and the absence of "structered data assemblies" and
     associative arrays within the bash.

     The tool "ctys-vhost" supports an interface with the option "-C"
     and "-S" for basic management of user defined groups and their
     pre-resolved caching due to performance enhancements.
 

   2.5. SSH encryption and tunneling - Basics
   ==================================================
 
     Due to the the "forest" of interconnection types of several tools
     and their requirements, the decision for this tool was made to
     support encryption by OpenSSH only. The commercial version might
     work appropriately too, even tough it is not tested until this
     version.
 

     REMARK:

       First of all, this tool is intended for handling user interfaces
       and some automated sessions with less or no priorioty on the
       ability of handling bulk data. The focus is more on the handling
       of display data, which is partly optimized for line bandwidth
       not required to speak about nowadays. The connection
       establishment, as long as it offers an adequate responsetime for
       a user interface, is not that critical too. Even the bulk
       configuration of sessions with huge numbers of logins requiring
       a recognisable time, may seem to a user as performance boost, who
       is accustomed to do that manually.
 
       So, the usage of OpenSSH sessions with dynamic allocation would
       be for the target use-cases perfectly allright.

 
     The first pro-argument was the broad support of platforms and
     tool-complements for OpenSSH, particularly the easy utilization
     and seamless intergration into KerberosV. It works perfectly with
     combinations of MIT-Kerberos and Heimdal implementation. 
     Additionally the seamless integration and interworking with GSSAPI
     based OpenLDAP access and the LDAP based automount for SSO
     completed the decision.
 
     The integration with the X11-based user interfaces supported by
     the embedded port forwarding feature of OpenSSH was the second
     main argument to use it.
 
     The next decision made was not to support SSH specific parameters
     of some tools too. This decision is again made in order of
     extracting a reliable common standard interface and might be
     extended in future releases, when appropriate.
 
     Thus currently the following two constellations of enrcypted
     communication channels with the related port-forwarding are
     supported.
 

     2.5.1. DisplayForwarding
     ========================
 
                     |                      |        
                     |                      |         +----+
                     |    +-------+         |        /    /|
                     |    |       |         |       +----+ |
                     |    |       |         |       |    | |
                     |    |       |         |       |    | |
                     |    +-------+         |       |    | +
       Physical      |   /         \        |       |    |/
       Location      |  +-----------+       |       +----+
      ---------------+----------------------+-------------------------
       Logical       |                      |
       Location      |                      |
       SW-Config     |                      |
                     |                      |                  +----+
                     |                      |                 /    /|
       1.)Display    |   +-------+     encrypted             +----+ |
          Forwarding |   |  +-+  |     port-forw.   +-+      |    | |
                     |   |  | +--+<----O=======O--->| |<---->|    | |
                     |   |  +-+  | X11-     |       +-+  raw |    | +
                     |   +-------+ DISPLAY  |      /   \     |    |/
                     |  /         \         |     +-----+    +----+
                     | +-----------+        |      client     server
                     |                      |      ======     ======
                     |                      |     a.k.a.:        a.k.a.:
                     |                      |     -XServer    -XClient
                     |                      |     -vncviewer  -vncserver
                     |                      |     -vmware     -vmware-vmx
                     |                      |     -...        -...
          Raw-Calls: |>ssh -X -f user@host \|
                     |   vncserver          |
                     |>ssh -X -f user@host \|
                     |   vncviewer :#X      |
                     |                      |     





      1.)Display Forwarding
         The whole set of applications processes including the virtual
         peer-Xserver of the application will be performed (virtually)
         on the server, whereas the client is in this case conceptually
         a ThinClient.
 
         Concerning the application of SSH, the connection will be
         established as a channel of an active user session and will be
         closed when the user closes his session.
 
         No additional precautions for the termination of the
         ssh-tunnel is required. 


     2.5.2. ConnectionForwarding
     ===========================
 
                     |                      |        
                     |                      |         +----+
                     |    +-------+         |        /    /|
                     |    |       |         |       +----+ |
                     |    |       |         |       |    | |
                     |    |       |         |       |    | |
                     |    +-------+         |       |    | +
       Physical      |   /         \        |       |    |/
       Location      |  +-----------+       |       +----+
      ---------------+----------------------+-------------------------
       Logical       |                      |
       Location      |                      |
       SW-Config     |                      |
                     |                      |               +----+
                     |                      |              /    /|
       2.)Connection |   +---------+    encrypted         +----+ |
          Forwarding |   |   +-+   |    port-forw.        |    | |
                     |   |   | +---+<---O=======O-------->|    | +
                     |   |   +-+   | raw    |      raw    |    |/
                     |   |  /   \  |        |             +----+
                     |   | +-----+ |        |
                     |   +---------+        |
                     |  /           \       |
                     | +-------------+      |  
                     |      client          |         server   
                     |      ======          |         ======
                     |      a.k.a.:         |         a.k.a:
                     |      -XServer        |         -XClient
                     |      -vncviewer      |         -vncserver
                     |      -vmware         |         -vmware-vmx
                     |       -...           |         -...
                     |                      | 
          Raw-Calls: |>ssh -X -f user@host \|
                     |   vncserver          |
                     |>getRport             |     
                     |>calcLport            |     
                     |>ssh -f -N            |     
                     |   -L $Lport:localhost|     
                     |      :$Rport         |     
                     |   user@host          |     
                     |>getPidOfSSH          |     
                     |>vncviewer            |     
                     |   $((lport-5900));\  |     
                     |   kill PIDofSSH      |     
                     |                      |     


 
      2.)ConnectionForwarding
         The advantage - if required so - is in this case, that the
         client process is executed on the client machine and the
         communications by the applications protocol only will be
         forwarded to the server-process/machine. In case of efficient
         protocols this is clearly an advantage for
         restricted-bandwidth communications channels. 
 

         Remark: Why do I call it Connection Forwarding instead of the
                 common term Port Forwarding?
 
                 Yes, this is just an abstract, not related to whether
                 a Forwarding("-L ConnectionForwarding"),
                 "Backwarding"("-L DisplayFrowarding"), a dynamic
                 or static approach is used, it just means:
 
                  1. The applications executes a client locally.
                  2. This client establishes a connection based on 
                     applications protocol to it's remote server 
                     process.
                  3. The connection utilizes an ssh-tunnel.
 

         Mainly two drawbacks result of this:
 
         A. The usage of Connection Forwarding requires the
            establishment of an ssh-channel explicitly. This results in
            some port calculations in a multi-client-to-multi-server
            environment. The requirement is caused by the local-only
            uniqueness of the port assignments on the involved nodes
            for the majority (if not all) of involved
            applications/tools.
 
            For example VNC enumerates it's DISPLAY-Numbers for each
            node incremental beginning with one. This numbers are used
            for the servers listenning communications ports as an offset
            e.g. to 5900. 
 
            This port and/or DISPLAY number could be set by the user
            more or less arbitrarily too, but as mentioned, this
            requires the management of numbers. In a multi-user and
            multi-node environment the assignment of unambiguous
            numbers gets quickly cumbersome.
 
            So, for this tool a combined approach is choosed. The remote
            numbes will be managed by the hosting nodes locally, the
            local port/display numbers for the client will be
            calculated as unique peer-access-points.
 
         B. The second drawback is the required explicit cancellation
            of the port-forwarding tunnel. This could again be defined
            in several ways. For now and this tool a complete dynamic
            allocation of session-attached allocation of ssh-tunnels is
            defined. Thus these will be terminated with the session
            consequently. 
 
            The choosed solution gets clearer when examining a
            non-shared VNC session, which is handed-over by openning a
            session to an existing one from another node. In this case,
            which is perfectly all right and for a roaming user not
            unusual, the trigger for cancellation of the ssh-channel
            has to be given by the hand-over of the vncviewer. This is
            coupled with the release of the port/display number, which
            now might be re-used on the remote node for another session,
            which could be owned by another user from another node. So,
            the local channel might not be reuseable at all.
 
            So, the cancellation of the channel with the related
            session allows last but not least for an easier algorithm
            of local port/display assignment too.
 
 
     2.6. SUMMARY
     ============

     The following options are related to control of clients execution,
     execution-location, and interconnection.
      
 
     -L "ConnectionForwarding"
      This case is the Connection Forwarding. Executing a local client
      and forwarding its port from local access to the remote by
      SSH(ssh -f -L).
 
     -L "DisplayForwarding"
      This case is the Display Forwarding. Executing client and server
      on remote machine and just forwarding the display to local
      XServer by SSH(ssh -f -X). 
 
     -L "DisplayRedirection"
      This case is similar to Display Forwarding, but redirects the
      display to another XServer running locally. Remote redirections
      are withdrawn.

      The primary intention is to concentrate consoles of multiple
      sessions started independently within the same PM on specified
      virtual desktops like VNC.

      REMARK: This feature is currently under developement and might
              not yet be available.

 
     -L "ServerOnly"
      Starts the server only, no client is started. A client could be
      attached later by '-a connect=...' option.
 
      This could be performed either by Display Forwarding or by
      Connection Forwarding.
 
     -L "LocalOnly"
      Starts the server and the client on local callers machine. So no
      remote connections and thus no SSH is applied.
 


