.
ctys-common-addresssyntax - Definition of the Generic Address Superset
This document describes the common generic address syntax for the command line interface. Additional data interfaces e.g. for LDAP and SNMP exist and may support additional features.
This specification describes the common generic address syntax for the management of
single machines and groups of entities.
This suffices all supported systems and may for some plugins applicable as a subset only.
The current version provides almost only the
<machine-address>
and the
GROUPS
objects, thus the remaining definitions were
required for the design of an extendable overal concept.
The addressing facility including the namebinding is splitted into a logical description as a general view and it's conrete adaptions which could be implemented by multiple presentations. The foreseen and implemented syntax scanners are designed to allow implementation in a straight-forward manner allowing an simple implementation of hierarchical structured syntax definitions by nested loops.
The following characters are reservered syntax elements, the full set and description is given in the chapter "Options Scanners - Reserved Characters".
ctys -a create=CONNECT ... myAccount@myHost
ctys -t QEMU -a cancel=REBOOT,FORCE ... myAccount@myHost
ctys -a create=LABEL:UserString ... myAccount@myHost
ctys -t VMW \
-a create=LABEL:MyMachine,USER:myAccountA%mySecretPasswd \
myAccountB@myTargetHost
ctys myHostAccount@myTargetHost'( \
-t VMW \
-a create=LABEL:MyMachine,USER:myVmAccount%mySecretPasswd\
)'
This particularly enables the superposition of specific attributes for each of multiple targets:
ctys -t VMW \
myAccount@myTargetHost00'( \
-a create=LABEL:MyMachine,USER:myAccount00%mySecretPasswd00 \
)' \
myAccount@myTargetHost01'( \
-a create=LABEL:MyMachine,USER:myAccount01%mySecretPasswd01 \
)'
The following arguments handle in general groups of syntax elements defining a set of elements as a group. This comprises the definition of a set of elements on the same level - as siblings, and the definition of a vertical structure of a path - parent-child relations. The contained elements could be targeted instances as well as sets of attributes for a specific instance or a group of instances.
ctys -t create=LABEL:myTest host00,host01,host02Due to supported common legacy syntax of host addressing the previous example could also be written as
ctys -t create=LABEL:myTest host00 host01 host02
ctys -t create=LABEL:myTest myAccount@host00'(-z)'.vm01'(-t VMW -a create=LABEL:...)'
ctys '{macro:tst-subgroups-01}(-d 99999)'
Where the macro is defined as:
tst-subgroups-01 = -a list {host1 host2}
The final expanded syntax is:
ctys -a list host1'(-d 99999)' host2'(-d 99999)'
myGroup00:={
myTargetHost00'(-t VMW -a create=LABEL:MyMachine00a,USER:myAccount00%mySecretPasswd00)', \
myTargetHost00'(-t VMW -a create=LABEL:MyMachine00b,USER:myAccount00%mySecretPasswd00)', \
myTargetHost01'(-t QEMU -a create=LABEL:MyMachine01a)'
}
The new group instance could be applied as:
ctys myGroup00
The destination address of each target could be named by any element of it's <machine-address> as described in the following chapter. In some cases a single attribute may be ambiguous within a distributed multi-user environment. This could for example be true for the hostname of a single virtual machine. Thus multiple attributes may be be required for a unique address.
ctys [ LABEL:myMultiHost,BASEPATH:/mntn/myTestPool01/myHost007 ]
ctys -a show [ LABEL:myMultiHost,BASEPATH:/mntn/myTestPool01/myHost007 ]
ctys -a info [ LABEL:myMultiHost,BASEPATH:/mntn/myTestPool01/myHost007 ]
ctys-host [ LABEL:myMultiHost,BASEPATH:/mntn/myTestPool01/myHost007 ]The brackets pre-resolv the attribute set to an appropriate target address.
The current syntax description may not yet formally be
absolutely correct nor complete, but may cover the intended grade
of open description and required understanding for it's application.
Some modifications are still under development.
The previous elements provide for flexible and simplified addressing of hosts and contained applications. This could be as simple as
ctys-host -a create=LABEL:myDesktop
which starts a VNC desktop on '${USER}@localhost' and assigns the symbolic name 'myDesktop' to it. Same for a remote host '${USER}@myHost'
ctys-host -a create=LABEL:myDesktop myHost
which starts a VNC desktop(the configured default) on the host 'myHost' and assigns the symbolic name 'myDesktop' to it. The so called label 'myDesktop' could be used as a full scale address id for all further calls.
When required also a some more sophisticated call of a VM stack could be performed too:
ctys \
[ UUID:3f95fea7-ee51-445b-95ee-4e432e6e4187 ]\
.{ \
[ LABEL:myMultiHost,BASEPATH:/mntn/myTestPool01/myHost007 ]'( \
-t VMW -a create=LABEL:MyMachine00a,USER:myAccount00%myPasswd00\
)'\
,\
myTargetHost00'( \
-t VMW -a create=LABEL:MyMachine00b,USER:myAccount00%myPasswd00\
)', \
}'(-d 99999)' \
,\
myTargetHost01'( \
-t QEMU -a create=LABEL:MyMachine01a\
)'
The following namebinding defines the superset of addressing attributes, which supports explicit addressing of targets as well as generic addressing of single and multiple targets by using search paths and content attributes in analogy to wildcards, a.k.a. keywords or attribute value assertions. The given sub-options are defined by default not to be order dependent, but some may influence the remaining. The keywords are case-insensitive.
The contained parenthesis, angle, and square brackets in the following figures are syntactic helpers. When they are part of the syntax, they will be quoted with single quotation marks.
The addressed top-level entity is the APPLICATION, thus here the <target-application-entity>. This contains in analogy to the OSI model the machine as well as the access point.
<target-application-entity>:=<tae>
<tae>:=[<access-point>]<application>
<access-point>:={
<physical-access-point>
| <virtual-access-point>
| <dialogue-access-point>
}
<application>:=<host-execution-frame><application-entity>
<physical-access-point>:=<machine-address>[:<PM-access-port>]
<virtual-access-point>:=<machine-address>[:<VM-access-port>]
<dialogue-access-point>:=<machine-address>[:<HOST-access-port>]
<machine-address>:={
(
[(ID|I|PATHNAME|PNAME|P):<mconf-filename-path>][,]
|
[(ID|I):<id>][,]
)
[(BASEPATH|BASE|B):<base-path>[%<basepath>]{0,n}
[(LABEL|L):<label>][,]
[(FILENAME|FNAME|F):<mconf-filename>][,]
[(UUID|U):<uuid>][,]
[(MAC|M):<MAC-address>][,]
[(TCP|T):<TCP/IP-address>][,]
}
The type of access varies for the different <access-point>. Therefore the <access-port> has to be provided in several variants which are specific for the various products. The following figure depicts the major items, additional may be required, which are described within the specific subsystem.
<PM-access-port> := (CLIcon|RDPcon|VNCcon|X11con)
<VMaccess> := (QEMUcon|VBOXcon|VMWcon|XENcon)
<HOSTaccess> := (CLIcon|RDPcon|VNCcon|X11con)
These items represent the various plugins, particularly the HOSTs plugin as a set of major desktop and console plugins commonly used for dialogue and batch access to the VMs and PMs.
Each of the listed access types provides several additional options related to the protocol access point and additional feature parameters. These paramteres are described within the specific plugins documents.
CLIcon := (SHELL)
QEMUcon := (QEMU-SDL|CLI|VNC|X11)
RDPcon := (RDESKTOP)
VBOXcon := (VirtualBox|VBoxSDL|RDP)
VMWcon := (VMware|vmware-rc|firefox|VNC)
VNCcon := (VNCVIEWER)
X11con := (XTERM|GTERM|EMACS|EMACSM|EMACSA|EMACSAM)
XENcon := (CLI|VNC|X11)
<label>={[a-zA-Z-_0-9]{1,n} (n<30, if possible)}
User defined alias, which should be unique. Could be used for
any addressing means.
MAC|M.
The stack address is a logical collection of VMs, including an eventually basic founding PM, which are in a vertical dependency. The dependency results from the inherent nested physical execution dependency of each upper-peer from it's close underlying peer. Therefore the stack addresses are syntactically close to GROUPS with additional specific constraints, controlling execution dependency and locality. Particularly the addressing of a VM within an upper layer of a stack could be smartly described by several means of existing path addresses schemas. Within the UnifiedSessionsManager a canonical form is defined for internal processing( StacksAsVerticalSubgroups ), which is available at the user interface too. Additional specific syntactical views are implemented in order to ease an intuitive usage. The following section depicts a formal meta-syntax as a preview of the final ASN.1 based definition. A stack address has the syntax as depicted in Figure Stack-Address.
<stack-address>:=<access-point-list>
<access-point-list>:={
<physical-access-point>
|<virtual-access-point-path-list>
}
<virtual-access-point-path-list>:={
| <empty>
| <virtual-access-point>
['.'<virtual-access-point-path-list>]
| [[',']<virtual-access-point-path-list>]
}
A stack can basically contain wildcards and simple regexpr for the various levels, groups of entities within one level could be provided basically to. And of course any MACRO based string-replacement is applicable. But for the following reasons the following features are shifted to a later version:
<group-address>:= (
[ <machine-addresses>['(' <machine-options> ')'[',']]{0,n}]
[ <group-address>['(' <group-options> ')'[',']]{0,n}]
)['('<group-options>')']
Groups are valid replacements of any addressed object, such as a HOSTs. Groups can contain in addition to a simple set of hostnames a list of entities with context specific parameters and include other groups in a nested manner. Each set of superposed options is permutated with the new included set.
The resolution of group names is processed by a search path algorithm based on the variable CTYS_GROUPS_PATH ,which has the same syntax as the PATH variable. The search algorithm is a first-wins filename match of a preconfigured set. Nested includes are resolved with a first-win algorithm beginning at the current position.
In addition to simple names an absolute or relative pathname for a group file could be used. For common addressing as the path-seperator a '.' could be used. In case of a '.' the user has to be aware of possible ambiguity, when file extensions are used. The address resolution works on first-match-wins base.
This allows for example the definition of arbitrary categories, such as server, client, desktop, db, and scan. Here are some examples for free definitions of categories based on simple subdirectories to search paths. The level of structuring into subdirectories is not limited.
REMARK: The group feature requires a configured SSO, either by SSH-Keys or Kerberos when the parallel or async mode is choosen, which is the default mode. This is required due to the parallel-intermixed password request, which fails frequently.
For additional information on groups refer to GroupTargets and ctys-groups .
The GROUPS objects are a concatination of <machine-addresses> and nested GROUPS including specific context options.
The end of the command with it's specific option should be marked by the common standard with a
double column '--'.
ctys -a <action> -- '(<glob-opts>)' <group>'('<group-opts>')'
=> The expansion of contained hosts results to:
...
<host0>'(<host-opts> <glob-opts> <group-opts>')'
<host1>'(<host-opts> <glob-opts> <group-opts>')'
...
=> The expansion of contained nested groups results to:
...
<group-member0>'(<glob-opts>)'('<group-opts>')'
<group-member1>'(<glob-opts>)'('<group-opts>')'
...
The context options are applied succesively, thus are 'no-real-context' options, much more a successive superposition. More worst, the GROUP is a set, thus the members of a group are reordered for display and execution purposes frequently. So the context options are - in most practical cases - a required minimum for the attached entity.
| Arno-Can Uestuensoez | <https://arnocan.wordpress.com/> |
| <https://unifiedsessionsmanager.sourceforge.io/> | |
| <https://github.com/unifiedsessionsmanager> | |
|
Copyright (C) 2008, 2009, 2010, 2011, 2020 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.