.
ctys-common-addresssyntax - Definition of the Generic Address Superset
This document describes the common generic address syntax for 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".
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 following namebinding founds the superset of addressing attributes, which supports explicit addressing of targets as well as generic addressing of 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 not to be order dependent, the keywords are case-insensitive.
The contained paranthesis, angle, and square brackets are just syntactic helpers. When they are part of the syntax, they will be quoted with single quotation marks.
The top-level addressed 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 port.
<target-application-entity>:=<tae>
<tae>:=[<access-point>]<application>
<access-point>:={
<physical-access-point>
|<virtual-access-point>
|<physical-access-point>[<virtual-access-point>]
|<group-access-points>
}
<physical-access-point>:=<pm>
<pm>:=<machine-address>[:<access-port>]
<virtual-access-point>:='['<vm>']'
<vm>:=<machine-address>[:<access-port>]
<group-access-points>:=<group>[:<access-port>]
<application>:=<host-execution-frame><application-entity>
<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>][,]
<group-address>:= (
[ <machine-addresses>['(' <machine-options> ')']{0,n}]
[ <group-address>['(' <group-options> ')']{0,n}]
)['('<group-options>')']
The <DISPLAYext> addresses a network display, where the full bath includes the <target-application-entity>, thus providing for various addressing schemas including application gateways.
<DISPLAYext>:=<target-display-entity>
<target-display-entity>:=<tde>
<tde>:=<tae>:<local-display-entity>
<local-display-entity>:=<lde>
<lde>:=(<display>|<label>)[.<screen>]
The given general syntaxes lead to the following applied syntaxes with the slightly variation of assigned keywords.
<target-application-entity>:=<tae>
<tae>:=[<access-point>]<application>
<access-point>:=<physical-access-point>[<virtual-access-point>]
<physical-access-point>:=<pm>
<pm>:=<machine-address>[:<access-port>]
<virtual-access-point>:='['<vm>']'
<vm>:=<machine-address>[:<access-port>]
<application>:=<host-execution-frame><application-entity>
The above minor variations take into account some common implementation aspects.
TDE - Target Display Entity address =================================== <DISPLAYext>:=<target-display-entity> <target-display-entity>:=<tde> <tde>:=<tae>:<lde>
<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 for daily business. The following section depicts a formal meta-syntax as a preview of the final ASN.1 based definition. A stack address has the sytax as depicted in Figure Stack-Address.
<stack-address>:=<access-point-list>
<access-point-list>:=[
<physical-access-point>
|<virtual-access-point-list>
]
<virtual-access-point-list>:=
'['<virtual-access-point>']'['('<context-opts>')']
[<virtual-access-point-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:
Groups are valid replacements of any addressed object, such as a HOST. 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
In addition to simple names a relative pathname for a group file could be used. 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 of 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.
The usage of stacked addresses is supported by the GROUPS objects for any entry, where an address is required, except for cases only applicable to PMs, e.g. WoL. The usage of stacked addresses within groups is supported too.
Therefore the behaviour for global remote options on ctys-CLI is to
chain the option with any entity within the group, such as for the
single PM case in
Figure Group Stack Addresses.
ctys -a <action> -- '(<glob-opts>)' <group>'('<group-opts>')'
=> group expansion results to:
...
<group-member0>'(<glob-opts>)'('<group-opts>')'
<group-member1>'(<glob-opts>)'('<group-opts>')'
...
=> host expansion result to:
...
<group-member0>'(<glob-opts> <group-opts>')'
<group-member1>'(<glob-opts> <group-opts>')'
...
This behaviour of "chaining options" results due it's intended mapping to the internal canonical form before expanding it's options, to the permutation of the <group-options> to each member of the group. The same is true for the special group VMSTACK
that the global and context options are in case of groups just set for the last - topmost - stack element Figure Groups member option expansion.
<group-member0>'(<glob-opts>)(<group-opts>)'
=> group expansion results to:
'[<vm0>][vm1][vm2](<glob-opts>)(<group-opts>)'
=> host + stack expansion result to:
level-0: <vm0>
level-1: <vm0>'['<vm1>']'
level-2: <vm0>'['<vm1>']''['vm2']''('<glob-opts>)'('<group-opts>')'
When entries within the stack require specific context-options, these has to be set explicitly within the group definition, or the stack has to be operated step-by-step. This behaviour is planned to be expanded within one of the next versions.
Written and maintained by Arno-Can Uestuensoez:
| Maintenance: | <<acue_sf1 (a) sourceforge net>> |
| Homepage: | <https://arnocan.wordpress.com> |
| Sourceforge.net: | <http://sourceforge.net/projects/ctys> |
| Project moved from Berlios.de to OSDN.net: | <https://osdn.net/projects/ctys> |
| Commercial: | <https://arnocan.wordpress.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.