Configuration of Personal CloudComputing-Workspaces
August, 2010



The UnifiedSessionsManager is currently first of all a command line application, but designed for the application of complex multi-vendor and multi-screen environments of physical and virtual facilities. Thus it is a sessions management utility of modern workspaces, thus basically a graphics-control application.

The lifecycle of the UnifiedSessionsManager is going to evolve to the migration towards the extension for a graphical user interface in current versions. The first step for providing an additional graphical interface is the integration of the generated cache database into the Gnome based starter application. The first application here is a simple list based starter application for intermixed hypervisors, physical machines, and additionally the combination with the functionality for native logins into OSs by provided HOSTs plugins.

Initially two basic interfaces are provided from now own. The CREATE list element for the start of virtual machines, and physical machines either by Wake-On-LAN or (next) by IPMI. Second the LOGIN list element for native logins - either into Host-OSs running on the physical machines, or GuestOSs running within virtual machines.

Both applications are implemented quite simple in order to demostrate

The following steps show the blueprint for the realworld application - these are actually almost the complete resulting application steps. These are described within the following chapters with additional application examples.

The following menu is provided as a basic menu and starting point as customisation pattern for automated installation by a script.

Gnome menu template

The next figure depicts the display of the database entries by the list 'ctys-CREATE-ALL', which contains all the complete unfiltered set of database record. The entry number '477' is selected for start, the resulting execution call is offered by the dialog box 'ctys-Selection' either for modification, or for execution by confirmation.

Gnome starter - CREATE

The internal data of the operational data storage, is integrated here by just a few lines of scripting with zenity into the Gnome based desktop, providing a graphical starter application. The scope of managed entities within the displayed list comprises here all supported VMs and PMs, including native logins by CLI, X11-Terminals, VNC, and RDP. Due to stored defaults, in addition to hypervisor consoles also the preconfigured native login applications could be started automatically.

This demonstrates the combination and setup of ctys-vdbgen(1) for automatic creation of the cacheDB and the gnome-starter(1) application for graphical presentation of the data within some minutes. The presented test environment on a medium-range machine for example contains about 350VMs used by NFS on several machines resulting in about 1400entries for VMs and PMs by multipath-access. The whole automated initial creation of the cacheDB takes some Minutes for scanning filesystems and presents than the shown graphical interface with a startup in the range of seconds for each selected VM.

Database creation and application

The database contains the hypervisors KVM, QEMU, VBOX, VMW, and XEN, additionally PMs. For each entry also default login desktops or commandline applications are stored for automation of console interconnection as well as native logins - based on CLI, X11, VNC, and RDP. Additionally a first minor version of customisable menus for Gnome based desktops is integrated. These offer either for private menus, or shared common menus with a pattern for simple customisation.

The next important aspect when working with huge amounts of machines and consoles - either physical, or virtual, or just ordinary remote desktops - is the usability of the workspace on the desktop. This frequently requires the application of multiple displays.

Gnome Xinerama

The Xinerama mode is provided by a specific extension for logical addressing of the standard X11 functionality.

The previous examples are just performed by a mouse-click - within seconds - no longer by painful manual execution or enduring custom-scripts development.


This part and related specific utilities are temporary pre-releases for demonstration of first draft graphical integration due to requests. Thus these are in alpha-state, and are planned to be replaced by a graphical application in future versions.

The current version supports the manual integration of ctys into menu entries of any X11 based desktop. This document describes the manual setup of ctys based menu entries for Gnome desktops.

The additional standard Gnome utility required for GUI based start of VMs is zenity, which offers an easy-to-use minimalistic graphical interface particularly for list-elements. This simply could be called from a shell script and returns the selected data. Another zenity widget e.g. provides a text-box for modification and confirmation of the current call.

Gnome - Automated menu Creation with Templates

The following menu is provided as a pattern to be installed either as a private, or as a shared menu. The configuration files and install scripts are installed within the directory $HOME/.ctys/xdg.d.

Gnome menu template

The private installation is performed by ctys-xdg --menu-create , whereas the shared installation is performed by the script ctys-xdg --menu-create --menu-shared The shared installation is stored within the common system directories and therefore requires root permissions. For the private installation the user permissions are sufficient.

The private base directories used are the standard directories as defined by the Desktop Menu Specification-1.0 from freedesktop.org. These are $HOME/.config, $HOME/.icons, $HOME/.local/share/applications, and $HOME/.local/share/desktop-directories.

The following description offers a simple and fast setup of the predefined menus by just one script-call. But the whole process could be performed manually by the property menus too as described within the specific chapters.

Gnome - Private and Shared menus

Gnome offers facilities for the creation of custom menus, which could be either setup individually within a private environment, or as a shared menus for all users on a specific machine. The resulting functional possibilities are basically similiar, thus the intention of usage and flexibility is the major aspect for the design choice.

Whereas the resulting functionality is quite similiar, the physical storage of the configuration infomation is obviously different. The common shared menu entries for the machine are stored within the system directories, with write operations requiering root permissions. The private environments are stored commonly within individual subdirectories of the specific user, thus frequently are visible just for the owner.

The configuration decision here is to use the custom files for static setups as defined by Gnome, even though some configuration with toolsets for runtime dynamic configuration might be applicable. Nevertheless, due to the contibous automatic synchronisation of the Gnome desktop with it's configuration files, some - almost unlimited - runtime dynamic is available inherently by default.

The applied directory structures are designed and named in order to minimize the deviation between the shared and private variant.

Private menus

Customization-Hook - gnome-applications.menu

The menu structure of Gnome is defined by a basically tree based data structure, which is defined by XML syntax within a nested file structure. The configuration syntax is a powerful set of language elements particularly offering for file and directory based inclusion configuration data extension. This is extended by means of decisive syntax elements for suppression, additional, exclusive, and non-exclusive extension of present menu configuration data.

The UnifiedSessionsManager menus are hooked-in into the configuration file:


This is done by the entry


The entry is located within the file for example as depicted in the following figure, where the file itself is contained within a subdirectoy 'applications-merged' and addressed by a relative path:

  <!DOCTYPE Menu
    PUBLIC '-//freedesktop//DTD Menu 1.0//EN'
    <MergeFile type="parent">/etc/xdg/menus/gnome-applications.menu</MergeFile>
  <!-- *** HOOK-START *** -->
  <!-- *** HOOK-END *** -->

The file is actually located within the pathname:


The menu definition is hereby assembled by the following file types in accordance to the standard Gnome and Common Desktop definitions:

Custom menu - ctys-UnifiedSessionsManager.menu

The hooked-in file contains the current version the whole structure definition of the ctys-menu-hierarchy as single standalone structure-definition file. The menu UnifiedSessionsManager is here included as a sub-menu of the Applications menu.

  <!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
  <!-- Do not edit manually - generated and managed by xdg-desktop-menu -->
        <Merge type="all"/>
        <Merge type="menus"/>
        <Merge type="files"/>


Custom desktop-directories

The following entry depicts as an example representation the data for the entry node of the configuration submenu for the UnifiedSessionsManager itself.

  [Desktop Entry]
  Name=ctys configuration
  Name[de]=ctys Konfiguration
  Name[en_GB]=ctys configuration
  Comment=Configuration Files
  Comment[de_DE]=Konfigurations Dateien
  Comment[en_GB]=Configuration Files

Custom applications

The following entry depicts as an example representation the data for the entry node of the configuration for the gnome-starter(1) with CREATE. submenu for the UnifiedSessionsManager itself.

  [Desktop Entry]
  Name=ctys Create Console
  Comment=ctys Create Console
  Name[en_CA]=ctys Create Console
  Name[en_GB]=ctys Create Console
  Name[de_DE]=ctys Start-Konsole
  Comment[de]=ctys Start-Konsole
  #Possible absolute PATH:
  #  Exec=/homen/acue/utils/gnome-starter CREATE CONSOLE ALL
  Exec=gnome-starter CREATE CONSOLE ALL
  #Possible absolute PATH:
  #  Icon=/opt/i4p/patches/icons/misc-collection/ctys-exe.svg
  #Possible absolute PATH:
  #  ~/.icons

Custom pixmaps

The pixmaps could be stored within several directories in multiple formats and resolution. The current choice for the UnifiedSessionsManager is svg and stored in a pixmaps directory coallocated with the directories applications and desktop-directories in accordance to the standard sub-structure of /usr/shared directory tree. This simplifies the common installation procedure for private and shared installs.

Shared menus

The share instalation is basically the same, the deviation is basically just within the root nodes for installation. The applications, desktop-directories, and pixmaps directories are allocated within the /usr/shared directory tree.

The applications-merged files are just copied into the /etc/xdg/menus/applications-merged subdirectory. Due to present inclusion of all files within this directory no file-patch is required in this case.

Gnome - Basic Manual menu Creation

The first step is to open the dialog box for the menu entries by mouse context menu by right-mouse-click.

Manual Gnome menu creation - Open context

The dialogue box enables the creation and setting of submenus and entries.

Manual Gnome menu creation - Dialogue

Entries for Scripts

A script is a shell executable, which could contain ctys calls intermixed with native shell calls. Thus this is particularly suitable for desktops containing various local applications. The setup of a script is quite easy due to simple syntax as well as by tool support with configurable standard editors. The following example shows the 'manuals01.sh' entry for the creation of the complete desktop for editing the manuals of ctys.

Script Entries

The setup is given as:


Where the content is:

  #Prepare environment
   . $(dirname ${0})/common.sh
  #Start environment
  if [ "$1" != "SETENV" ];then
      gnome-terminal --geometry=$(getGeometry  -g  180x20+0+0:A10) \
          --working-directory="$DOC_BLD_ROOT" \
          --title="DOC_BLD_ROOT" -x $0 SETENV&
      gnome-terminal --geometry=$(getGeometry  -g  180x10+0+350:A10) \
          --working-directory="$DOC_BLD_ROOT" \
          --title="DOC_BLD-01" -x $0 SETENV&
      gnome-terminal --geometry=$(getGeometry  -g  180x10+0+550:A10) \
          --working-directory="$DOC_BLD_ROOT" \
          --title="DOC_BLD-02" -x $0 SETENV&
      gnome-terminal --geometry=$(getGeometry  -g  180x10+0+750:A10) \
          --working-directory="$DOC_BLD_ROOT" \
          --title="DOC_BLD-03" -x $0 SETENV&
      nautilus --geometry=$(getGeometry  -g  1280x700+0+0:A20) $DOC_ALL&
      konq\u\eror --geometry=$(getGeometry  -g  1280x1048+0+0:A31) \
         $DOC_ALL_EN $DOC_ALL_DE&
      konq\u\eror --geometry=$(getGeometry  -g  1280x1048+0+0:A30) \
      konq\u\eror --geometry=$(getGeometry  -g  1280x1048+0+0:A00) \
      cd $BLD_ROOT && ctys desktops/dev/ctys/manuals01
      #Set environment
      if [ -z "$CTYS_ENVSET" ];then
          export CTYS_ENVSET=1
  	exec bash -i
  exit 0

The result is depicted in the following figure.

Script Entries - Resulting Desktop

Entries for GROUPs

GROUPS are sets of hosts and virtual machines for ctys only. This are particularly suitable for desktops build up by remote applications only, including remote desktops and consoles. The setup of groups allows for various specific parameters for each connection and executed desktop. In addition an overall task control is setup for a GROUP, which also could be setup by reusable modular includes for various purposes. The setup of a GROUP called by 'ctys' could be created in the same manner as script entries. The following example shows the 'ctys admin/admin0' group entry for the creation of the complete desktop for administration of some servers.

GROUP Entries - menu Entries

The menu entry could be setup as following, in this example:

  /homen/acue/bin/ctys admin/admin0

With the content of the GROUP:

  #  -*- mode: conf; -*-
  #This groups contains all machines in the management group of the
  #server group.
  #fileserver - CentOS-5.4 - VMware-Server
  root@delphi'( -t vnc -a create=l:DELPHI,reuse -g 1268x994:A00:ALL  -b 1,2)'
  #backup-server - CentOS-5.4
  root@olymp'(  -t vnc -a create=reuse,l:OLYMP  -g 1268x964:A10:ALL  -b 1,2)'
  #database-server - CentOS-5.4 - KVM
  root@app1'(   -t vnc -a create=reuse,l:APP1   -g 1268x994:A01:ALL  -b 1,2)'
  #CUDA-server - CentOS-5.4 - KVM
  root@app2'(   -t vnc -a create=reuse,l:APP2   -g 1268x994:A21:ALL  -b 1,2)'

GROUP Entries

The result is depicted in the following figure.

Script Entries - Resulting Desktop


The online help menu could be basically created with any tool from the package. The usage is:

  ctys -H html=base


  ctys -H html=doc

This opens a browser with the provided help file 'doc.html'. The preconfigured browser is konqueror by default for now, when not available firefox is used. Any browser could be customized by the user.

The script could be integrated into Gnome by just configuring a menu item and using the call for openning a (now still) draft online help by html and pdf files. Additionally the commandline interface man pages are available.

ctys-help-on - Online Help


The GROUPS objects are represented by files containing multiple host entries. These could be edited by a preconfigured editor with the following call, which could be used within menu entries.

  ctys-groups -e

The started editor or filebrowser opens by default all configured directories within the CTYS_GROUPS_PATH. The preconfigured default is the Emacs editor, if not present vi, vim, konqueror, or nautilus are called. The user can customize any browser or filemanager as required.

GROUPs - Emacs editor

This could be varied call-by-call e.g. by

  CTYS_GROUPSEDIT=konqueror ctys-groups -e

GROUPs - konqueror browser with tabs


The MACROS are represented by files containing the set of definitions to be applied. These could be edited by a preconfigured editor with the following call, which could be used within menu entries.

  ctys-macros -e

The started editor or filebrowser opens by default all configured directories within the CTYS_MACROS_PATH. The preconfigured default is the Emacs editor, if not present vi, vim, konqueror, or nautilus are called. The user can customize any browser or filemanager as required.

MACROS - Emacs editor


The SCRIPTS are contained in within the defined search path CTYS_SCRIPTS_PATH similar to the systems PATH variable. These could be edited by a preconfigured editor with the following call, which could be used within menu entries.

  ctys-scripts -e

The started editor or filebrowser opens by default all configured directories within the CTYS_SCRIPTS_PATH. The preconfigured default is the Emacs editor, if not present vi, vim, konqueror, or nautilus are called. The user can customize any browser or filemanager as required.

SCRIPTS - Emacs editor

This could be varied call-by-call e.g. by

  CTYS_SCRIPTEDIT=konqueror ctys-scripts -e

SCRIPTS - konqueror browser with tabs


The configuration files could be browsed by konqueror with the following call:

  ctys-config -e

The started editor or filebrowser opens by default all configured directories within the standard paths. The preconfigured default is the Emacs editor, if not present vi, vim, konqueror, or nautilus are called. The user can customize any browser or filemanager as required.

CONFIGURATION - konqueror browser

Graphical VM and PM Starter

The following example shows the configuration of a graphical starter based on zenity.

This is based on some pre-requirements in order to work. The main requirement is the presence of a cacheDB, which could be generated by the utility ctys-vdbgen(1) , for further information refer to the man pages of the tool. The second requirement is the static definition of the call parameters of the start call, which relies on the defaults of each plugin. These could be modified by the related configuration files, but may suffice the basic initial creation and reconnection(by REUSE) for each VM.

This works for all supported hypervisors due to the unique interface for all - providing basic features for each. Additional parameters such as the screen position and windows size are not provided for current version.

It is recomended to set the type of the menu entry to 'Start application in terminal' because some user interaction may be required. For example in case of SSH first time connection the new key has to be confirmed.


The temporary utility gnome-starter accepts the parameters PM, VM, and LIST. The parameter PM sets the start of a PM login by usage of VNC, this also restricts the displayed choice-list to PMs only and additionally assures that the displayed records are unique each. The parameter VM works similiar for VMs, where only VMs, but of all supported types are displayed. Due to the generic standard-interface and apropriate defaults delivered, each could be started in the same manner.

The standard call syntax fo selection of subsets from the database is

  gnome-starter <ACTION> <TARGET-TYPE> <SCOPE>


The current version does support for native access UNIX systems only. Thus even though guest systems could contain any OS supported by the hypervisor are successfully collected into the database, the selection in the starter for LOGIN actions may fail for non-supported systems. Specific parameters e.g. for individual screen positions are not provided by this version.

CREATE - PM and VM Starter

The PM starter could be configured in the same manner as any menu item. The required call is

  gnome-starter CREATE CONSOLE PM

The generated standard call is:

  ctys -t <type> \
       -a create=dbrec:<database-index>,reuse,CONSOLE:<current-default> \
       -Y  -c local <username>@<hostname>

This opens now 2 windows, the zenity list window and in addition a terminal window.

ATTENTION: The terminal window is required in cases, where user interaction is requiered. In some cases the system may even hang in an non-reachable console dialog, when a terminal is missing.

Gnome starter menu

Gnome starter

After a specific entry is selected a second window is opened for call confirmation. This text-box allows for modification of the generated call if required. The confirmation of this second window starts the entry.

Call confirmation

The requested user interaction is here to confirm new host entry for OpenSSH.

Gnome starter - SSH-Confirmation

The result is depicted in the following figure.

Gnome starter - Resulting Desktop

The VM starter could be configured in the same manner as any menu item. The required call is

  gnome-starter CREATE CONSOLE VM

LOGIN - HOSTs Starter

The starter for LOGIN is similar but slightly different. This is due to required additional information related to the guest OS, such as the ip address of the contained guest system. Also the preconfigured default HOSTs CONSOLE is displayed and used instead of the CONSOLE to be attached to the hypervisor. In addition some helpful information related to the contained guest OS distribution are presented.

Gnome starter - LOGIN list

The resulting call is a complete call due to the much simpler structure for a simple login, than in case of CREATE, where additional data may be fetched form the database.

Gnome starter - Gnome starter - LOGIN confirmation


In case of difficulties call the interface manually from the command line. The main prerequirement is an existing cacheDB (refer to ctys-vdbgen(1) ), which may not contain redundant entries. This could be verified by ctys-vhost(1) with the -M option.

When a call does not start from the menu entry the required PATH may not be complete. Thus one solution is to enter absolute pathnames for the executable, for example:

  /home/yourHome/bin/ctys ...

Multiple Monitors - Xinerama Setup

The most important practical usability aspect when working with huge amounts of machines and consoles - either physical, or virtual, or just ordinary remote desktops - is the usability of the workspace on the desktop. The key for the usability is here the application of multiple display environments, where these could be either combined locally, or virtually from local and remote sites.

Gnome Xinerama

These local and remote pyhsical screens could be combined to a virtual screen by e.g. Xinerama (or distributed e.g. by Xrdb) what is supported by the UnifiedSessionsManager particularly through the extension of the geometry option of X11. This extension provided - beneath others - for an overlay of a virtual grid of screens on top of the combined displays, thus the physical screens could be addressed by user-defined labels, the required pixel-calculations are encapsulated by the mapping-functions of the UnifiedSessionsManager.

The following screenshot represents the logical view of the combined displays.

Gnome Xinerama

Another benefit from handling of logical addresses only is the independent addressing from physical changes, which occurs frequently when the hardware is exchanged. This is due to the automatic enumeration of components by the system, which varies widely by seemingly minor changes.

The mapping and address calculations are described in depth within the User-Manual of the DOC-Package(Remember the CCL-3.0 Licensing).

Physical and Logical Screens - A Sumup

Physical screens are by default supported for the X11 based desktops as independent terminal sessions. This particularly excludes the mouse movement between the screens by default.

One appropriate facility for the combination of pyhsical screens into on superpositined-screen as a combination is the so called Xinerama mode. This simply adds the pixel-arrays together and produces a resulting array of size by the overall sum of pixels. Therefore the new address range changes to the new screen size. In practical cases the order of the screens - meaning the actual physical position of a specific pixel-area - may change e.g. due to initialization or hardware-exchange. Particularly the hardware exchange, even the exchange of the slot position of a specific graphics card, may change the whole setup dramitically. Therefore the persistent storage of desktop scripts with geometry-positions should address logically without physical dependency.

Logical Display Addressing by the UnifiedSessionsManager

The applied scheme for logical addressing is - as the main philosophy - kept as simple as possible, therefore just relies on the standard means of the X11 configuration files. The specific approach is to utilize the X11 feature of user specific section/screen address labels for multiple display. These could be simply registered by editing the file


The custom labels are from then on valid screen aliasses for the specific array of pixels of the defined screen. Particularly in case of hardware changes the only thing to change is the label within the xorg.conf file, the bunch of user specific desktop configurations could remain unchanged.

An extract from an example file is given in the following figure. The Section ServerLayout is the logical overall screen, whereas the Screen sub-sections represent specific pixel-arrays mapped to a physical position. Thus by exchange of physical pixel arrays a re-positioning of physical devices could be adapated to previous definitions, and the legacy desktop configurations could be kept unchanged. In this particular case the screen names are defined in accordance to the 2-dimension array-like matrice-layout of the virtual screen. This eases the sddressing e.g. by '100x100+766+531:A21', which meand the positions are relative to the screen A21. instead of calculating '100x100+2146+1811', which may change completely for HW changes, without physical changes of the screen-position. This result from a logically double-level-remapping of pixels. For further details refer to the User-Manual(Remember the CCL-3.0 License with the full scope of commercial restrictions).

  # nvidia-xconfig: 
  #    X configuration file generated by nvidia-xconfig
  # nvidia-xconfig:  
  #    version 1.0  (buildmeister@builder58)  Tue Oct 20 21:25:04 PDT 2009
  Section "ServerLayout"
      Identifier     "ALL"
      Screen      0  "A11" 1280 1024
      Screen      1  "A21" 2560 1024
      Screen      2  "A30" 3840 0
      Screen      3  "A01" 0 1024
      Screen      4  "A00" 0 0
      Screen      5  "A31" 3840 1024
      Screen      6  "A10" 1280 0
      Screen      7  "A20" 2560 0
      InputDevice    "Keyboard0" "CoreKeyboard"
      InputDevice    "Mouse0" "CorePointer"
      Option         "Xinerama" "1"
  Section "Files"
      FontPath        "unix/:7100"
  Section "Module"
      Load           "dbe"
      Load           "extmod"
      Load           "type1"
      Load           "freetype"
      Load           "glx"
  Section "ServerFlags"
  # Removed Option "Xinerama" "1"
  # Removed Option "Xinerama" "0"
      Option         "Xinerama" "1"
  Section "InputDevice"
      # generated from default

The following (independent) example depicts the resulting mapping required for actually unchanged virtual display positions in case of pyhsical re-ordering of pixels.

Physical Xinerama-Mapping


The following examples show some additional examplary cases of convenience integration into gnome by simple menus.


The following desktop demonstrates the automated setup of a complex runtime environment. There are just some positioning restrictions due to limits of some propriatery client applications.

The required menu entry for starting is:

  /home/userName/bin/ctys demo/vm-desktop-01

Gnome starter - Demo Desktop

The following extract from the GROUPs file shows the configuration parts for XEN and VBOX.

Gnome starter - Extract from GROUP

The ctys-groups(1) command could be used to resolv the entries within the GROUP for cut-and-paste operations.

Gnome starter - Display of resolved GROUP

Single Machine Entry

This example shows an entry for a single VM. The actual menu entry is written within one line:

      -t vmw 
      -a create=reuse,l:office001,b:/mntn/vmpool/vmpool03/vmw/office,user:acue 
      -g 1268x994:A11:ALL 
      -b 1 
      -c local

Gnome starter single entry - Menu

This menu entry starts a VM for example here on a VMware Server-2(TM). It has to be recognised that the whole command line is visible in clear text by 'ps' command on the local machine, and at least partially on the target machine. The intermediate connection is encrypted by OpenSSH. Additonally menu entries are stored within files, which must not contain any serious passwords at all. Thus for security reasons in this case the username is provided only, the password is entered interactively.

Gnome starter - Gnome starter LOGIN - VMWRC Login

The started Windows2000(TM) desktop in this case could be seen as 'second level menu entry' for virtual applications.

Gnome starter LOGIN - Started W2K desktop

PABX with VLAN-Gateway

This example shows an entry for a the maintenance of two PABXs, where one is an Asterisk PABX on a distinct VoIP VLAN.

Gnome starter PABX - Interconnection Structure

The interconnection is setup by an intermediate gateway, which is passed by the utility 'ctys-beamer'.

  ctys-beamer -Y --x11 -R root@tserv00 -b async --beam-this \
    ctys -Y -a create=l:PABX2,reuse root@

The resulting starter script is

Gnome starter PABX - Script

The actual menu entry is:


which could be started as:

Gnome starter PABX - menu

This opens the two views, on the left the VM containing the legacy configuration and monitoring utily from the '90s' running on the local segment interconnected by an RS232 on one gateway. The right view shows the Asterisk master PABX which is running on the VoIP gateway within another VLAN, thus has to be interconnected by a TCP/IP gateway.

Gnome starter PABX - Script

REMARK: Due to some limits by OpenSSH for handling of specific interfaces on the targeted TCP/IP gateway, evantually some static routing for specific hosts on different VLANs is required.


ctys(1) , ctys-config(1) , ctys-groups(1) , ctys-macros(1) , ctys-scripts(1) , gnome-starter(1) , ctys-xdg(1) , ctys-vdbgen(1) , ctys-vhost(1) , zenity(1)

For standards:
Freedesktop: <http://www.freedesktop.org>
Xorg: <http://www.x.org>

For implementations:
FVWM: <http://www.fvwm.org>
Gnome: <http://www.gnome.org>
KDE: <http://www.kde.org>
XFCE: <http://www.xfce.org>


Written and maintained by Arno-Can Uestuensoez:

Maintenance: <<acue_sf1 (a) sourceforge net>>
Homepage: <http://www.UnifiedSessionsManager.org>
Sourceforge.net: <http://sourceforge.net/projects/ctys>
Berlios.de: <http://ctys.berlios.de>
Commercial: <http://www.i4p.com>


Copyright (C) 2008, 2009, 2010 Ingenieurbuero Arno-Can Uestuensoez

For BASE package following licenses apply,

This document is part of the DOC package,

For additional information refer to enclosed Releasenotes and License files.