
   12.6. Micellaneous
   ==================


    12.6.1. Basic EXEC principle
    ============================

     The basic execution principle of ctys is first to analyse the
     given options and build up an call array. Therefore several
     distinctions have to be made as resulting from permutation and
     superposing of the expanded CLI arguments. These array is finally
     executed in sets dependent from multiple criteria. Some examples
     are:

      - Grouping of common sessions for each desktop, due to
        reliability and addressing gaps when shifting windows between
        desktops.

      - Grouping of sessions for each remote server, but only if not
        ConnectionForward is choosen, because the current OpenSSH
        release does not support MuxDemux of multiple XSessions with
        different Displays.

      - Splitting of Remote Server and Local Client execution of ctys,
        for VMs even though the VM-configuration is available on the
        server site only, which requires a remote component of ctys to
        be executed.

      - ...and so on.


     The implementation of ctys is pure bash with usage of the common
     shell components such as awk and sed. The whole design is based
     on unique set of sources which will be executed as the local
     initial call and client starter part as well as the remote server
     execution script. In case of DisplayForwarding the local
     component just initiates the remote co-allocated execution of
     Client and Server component. For the case of LocalOnly both will
     be locally executed, thus the ctys acts locally as initial
     caller, server starter and client starter script.

     To assure consistancy and compatibility the remote and local
     versions will be checked and the execution is proceeded only in
     case of an match of both versions.


    12.6.2. PATH
    ============

     First of all: 
        This is normally just required when handling different
        versions during development.
 
     Due to the several execution parts locally and remotely located,
     some extension of PATH is frequently required.

     This is particularly true, when during development a version is
     executed which is not contained within the standard PATH. This is
     particularly to be recognized, when executing the remote
     component which relies on the PATH mechanism too.

     Due to compatibility issues diverging versions will be rejected,
     which could be controlled by "-F" option but should be avoided.

     Therefore the two environment variables are defined:

       R_PATH:  Replaces path for remote execution.
       L_PATH:  Replaces path for local execution.

     The local component L_PATH is required for local execution too,
     because the following subcalls of ctys will be executed based on
     PATH mechanism, which is most often different to initial
     path-prefixed test-call.
  
     For example this is for calling a test version for starting a
     local client and remote server from a test path without changing
     PATH:
  
       V=01_01_007a01;\
       export R_PATH=/mntn/rd/p-int/tools/ctys/src/ctys.$V/bin:\$PATH;\
       export L_PATH=$R_PATH;\
       ctys.$V/bin/ctys -t vmw \
         -a create=b:$HOME/vmware/dir2%$HOME/vmware/dir3,\
            l:"GRP01-openbsd-4.0-001",REUSE
         -g 800x400+100+300:3 \
         -L CF \
         -- '(-d 99)' app2
  
     The same for common user with standard install will be:
  
       ctys -t vmw \
         -a create=\
              base:$HOME/vmware/dir2%$HOME/vmware/dir3\
              ,label:"GRP01-openbsd-4.0-001"\
              ,REUSE
         -g 800x400+100+300:3 \
         -L CF \
         app2
  
  
    12.6.3. Configuration files
    ===========================

     The configurration of ctys is performed in 4 steps, first has
     highest priority.
  
        1. Environment Variable If an environment variable is set, it
           dominates other settings and it's value is kept.
  
        2. $HOME/.ctys/ctys.conf Config-File sourced:
           $HOME/.ctys/ctys.conf
  
        3. <install dir>/conf/ctys.conf Config-File sourced: 
           <install dir>/conf/ctys.conf
  
        4. Embeded defaults in ctys.
  
  
    12.6.3. Media Access Control(MAC) Addresses - VM-NICs
    =====================================================

     This is just an short extract of repetition for understanding WHY
     a VMs MAC-address should begin with either '2', or '6', or 'A',
     or 'E' - shortly [26AE].
  
     The knowledge of this is an mandatory and essential building
     block, when assigning addresses to NICs - a.k.a. VNICs - of VMs
     for participation of the VM on LAN communications. So will be
     given thoroughly here.
  
     First of all - this item is described excellently in the
     following book at pg. 42:
  
       Ethernet - The Definitve Guide; Charles E. Spurgeon; O'Reilly;
       ISBN: 1-56592-660-9
  
     Application hints with general visual VM-Networking explanation
     and a short sum-up for application of MAC-Addresses on VMs are
     available at:
  
       http://wiki.xensource.com/xenwiki/XenNetworking
  
     The standards are available at ieee.org.
  
  
     Now the details. The basis for this numbering are the so called
     DIX and IEEE 802.3 standards. The following items give the
     explanation, even though anyone should draw a blueprint of
     byte-bit-construction once by himself:
  
      - Multicast-bit -  by DIX and IEEE 802.3
        The Ethernet frames use the first bit of destination address
        for distinction between:  
  
          - an explicitly addressed single target - a.k.a. physical 
            or unicast address.
          - a group of recipients with an logical address -
            a.k.a. multicast address
  
        The syntax is given by most significant bit in Network 
        Order:
  
           0: unicast
           1: multicast
  
        Which is 'X' for frames bit-stream:
  
           Xnnn mmmm rrrr ssss ....
  
  
      - Locally and Globally Administered Addresses - IEEE 802.3
        This is defined for IEEE 802.3 only. This bit defines the
        namespace of (to be cared of!) unambiguity for the given
        address due to it's adminitrators area of responsibility.
  
           - globally administered addresses
             To be used by public - so globally coordinated - 
             access, which has to prevent anyone from buying two 
             NICs with the same MAC-Address.
     
           - locally administered addresses
             Could be used according to policies of locally
             responsible administrators. 
  
             This is particularly required for management of VMs, 
             when these should be used in bridged mode, which is a
             transparently complete host network access as for any
             physical host.
  
        The syntax is given by second significant bit in Network 
        Order:
  
           0: globally administered
           1: locally administered
  
        Which is 'Y' for frames bit-stream:
  
           nYnn mmmm rrrr ssss ....
  
  
  
      - Distinction of Network-Order and Representation-Order 
        So far so good, but when trying to define the concrete
        addresses now, some little details has to be recognized 
        first.
  
        The given control bits from the network standards are 
        related to networking - of course - thus address positions 
        in network streams as bit-representation.
  
        But the MAC-Address - 48bit - are written as 6 Octets of
        hexadecimal nibbles seperated by colons - for human
        readability.
  
        The difference of both for the actual "bit-order" arises 
        from the "different logical handling units" for the actual 
        set of bits.
  
        Whereas the Network-Order assumes a bit as unit, the
        Representation Order assumes nibbles grouped to octets 
        as handling units.
  
        So the definition of both units are:
  
          - Network-Order:
            bit as unit, and a constant bit-stream indexed
            incrementally beginning with the first bit
  
          - Representation-Order:
            nibble as unit, grouped to octets as least-significant
            nibble - containing the least significant bits of a 
            bit stream - first
  
        Thus the resulting mapping is given by:
  
          - Network-Order:
  
              nnnn mmmm rrrr ssss ....
              N    M    R    S   ....
  
          - Representation-Order, where additionally the 
            bit-order within the nibble is swapped by definition:
  
              MN:SR:...
  
            with N from n0-n1-n2-n3 to N3-N2-N1-N0.
  
              - Network:         0001 = 0x1
              - Representation:  1000 = 0xF
  
  
        Assuming that for a VM only addresses of following types
        should be used or to say 'are valid':
  
        unicast + locally administered
  
        OK, now after all this results to :
  
              01nn mmmm rrrr ssss ...
  
        ...which is represented as:
  
              M{nn10}:SR:...
  
        ...so has even values only beginning with 2 -  N=2+n*4:   
  
              {nn10}={2,6,10,14}={0x2,0x6,0xA,0xE}=[26AE]
  
        ...finally referring to the guide on "XenNetworking-Wiki":
  
          "aA:..." is a valid address, whereas "aB:...." is not.
  
        Mentioning this for completeness - any value of a 
        MAC-Address, where the second nibble of the leftmost octet 
        has one of the values [26AE], is valid.
  
        So, ...yes, no rule without exception. 
  
        When dealing with commercial products, free or not, any
        addressing-pattern could be predefined for manual and 
        generic MAC-Address assignment within a valid "private"
        range of the products supplier. This is the case when the 
        first 3 octets of the MAC-Address are defined to be fixed 
        - which is e.g. the suppliers globally assigned prefix - 
        whereas any numbering range could be defined within the 
        following 3 octets.
  
        The given convention should be recognized, because it might 
        be
        checked by any undisclosed hardcoded piece of code.
  
        For details refer to the specific manuals when required.
  
  
        "ctys" supports the display of MAC-Addresses as it does 
        UUIDs by action ENUMERATE. This could be used to check 
        uniqueness and might be supported as a ready-to-use MACRO.
