Tags:
create new tag
view all tags

Notes on the LCFG XML Profile structure

It is not really possible to write a proper schema to describe the LCFG XML profile structure. The aim of this document is to specify what can be relied upon and explain how the structure works in practice based on a few simple examples.

There is a top-level node named profile which contains a single element node named lcfg, this always contains the following singleton element nodes:

published_by
The host name of the LCFG server which published this profile (e.g. vermeer.inf.ed.ac.uk)
published_at
The timestamp at which this profile was published (e.g. 07/10/13 11:48:31)
server_version
The version of the LCFG server software (e.g. 3.1.0)
components
The set of information for the LCFG components for this LCFG client. See below for more details.
packages
The list of packages for this LCFG client. See below for more details.
last_modified
The timestamp at which this profile was last modified (e.g. 07/10/13 11:45:10). This is the most recent timestamp of all the source files which were used to form this profile.
last_modified_file
The name of the source file with the most recent timestamp (e.g. /var/lcfg/conf/server/releases/develop/core/packages/dice/dice_sl6_env.rpms). This is the absolute path to where the file is found on the LCFG server.

The profile node also contains the following xml namespace declarations:

  • xmlns = "http://www.lcfg.org/namespace/profile-1.1"
  • xmlns:cfg = "http://www.lcfg.org/namespace/cfg-1.0"

Components

Under the components node there are one or more component element nodes, the name of each node is the name of the component (e.g. alias, client, updaterpms). Each component node has one or more resource nodes, each resource node is named after the resource (e.g. aliases, components, rpmpath).

At the most simple a resource just has a single value, for example:

  <updaterpms>
    <flags cfg:derivation="/var/lcfg/conf/server/releases/develop/core/include/lcfg/defaults/updaterpms.h:48,66">-h -a x86_64</flags>

In this case the updaterpms.flags resource has the value -h -a x86_64 A node for a simple single-valued resource just contains a text value (or is empty) and does not contain any element sub-nodes.

Note that there may be more than one resource element node for any LCFG resource, each one will have a different LCFG context specification, for example:

   <client>
    <ack cfg:derivation="/var/lcfg/conf/server/defaults/client-3.def:47" cfg:type="boolean">true</ack>
    <ack cfg:derivation="/var/lcfg/conf/server/defaults/client-3.def:68" cfg:context="net=none" cfg:type="boolean">false</ack>

Here, the standard value of the client.ack resource is true but when the net=none context evaluates to true the value becomes false.

Alongside single-valued resources LCFG has the concept of tag-lists. If a resource has a cfg:template attribute then it is a tag-list resource and it will have one or more element sub-nodes. Those sub-nodes can be in either of two forms.

In the first form there is precisely one resource element node associated with each tag, for example:

   <om_methods cfg:derivation="/var/lcfg/conf/server/defaults/om-1.def:15" cfg:template="om_acl_$">
     <om_acl cfg:name="configure" cfg:derivation="/var/lcfg/conf/server/defaults/om-1.def:17">om/all</om_acl>
     <om_acl cfg:name="start" cfg:derivation="/var/lcfg/conf/server/defaults/om-1.def:17">om/all</om_acl>
     <om_acl cfg:name="stop" cfg:derivation="/var/lcfg/conf/server/defaults/om-1.def:17">om/all</om_acl>

The tag name is stored in the cfg:name attribute for each node. After parsing, the tag names are joined together, with a single-space separator, to create the value for the tag-list resource itself. The template (specified in the cfg:template attribute) is used to build the names of the resources by replacing the placeholder $ characters with the tags. This example would yield the following four resources:

om_methods=configure start stop
om_acl_configure=om/all
om_acl_start=om/all
om_acl_stop=om/all

For the second form of tag-lists there are either zero or more than one resources associated with each separate tag, the standard terminology for these is records. For each tag there is a record node which contains a set of resource nodes. Any resource node may itself be a tag list (without any limits on depth) so this is best handled as a tree.

Here is an example from the auth component:

    <extragroup cfg:derivation="/var/lcfg/conf/server/releases/develop/core/include/lcfg/defaults/auth.h:41"
         cfg:template="grpent_$ gr_name_$ gr_passwd_$ gr_gid_$ gr_mem_$">

     <extragroup_RECORD cfg:name="lcfg">
      <gr_gid cfg:derivation="/var/lcfg/conf/server/defaults/auth-2.def:63" cfg:type="string(group entry gid)"></gr_gid>
      <gr_mem cfg:derivation="/var/lcfg/conf/server/defaults/auth-2.def:64"></gr_mem>
      <gr_name cfg:derivation="/var/lcfg/conf/server/defaults/auth-2.def:60"></gr_name>
      <gr_passwd cfg:derivation="/var/lcfg/conf/server/defaults/auth-2.def:61">x</gr_passwd>
      <grpent cfg:derivation="/var/lcfg/conf/server/releases/develop/core/include/lcfg/defaults/auth.h:42">lcfg:x:980:</grpent>
     </extragroup_RECORD>
     <extragroup_RECORD cfg:name="quagga">
      <gr_gid cfg:derivation="/var/lcfg/conf/server/defaults/auth-2.def:63" cfg:type="string(group entry gid)"></gr_gid>
      <gr_mem cfg:derivation="/var/lcfg/conf/server/defaults/auth-2.def:64"></gr_mem>
      <gr_name cfg:derivation="/var/lcfg/conf/server/defaults/auth-2.def:60"></gr_name>
      <gr_passwd cfg:derivation="/var/lcfg/conf/server/defaults/auth-2.def:61">x</gr_passwd>
      <grpent cfg:derivation="/var/lcfg/conf/server/releases/develop/core/include/dice/options/routing.h:52">quagga:x:990:</grpent>
     </extragroup_RECORD>

Here the tag-list has five resources associated with each tag. Note that the RECORD entries have an invented node name, the name does not matter here, anything would do. It must be assumed that all element nodes which are immediate children of a multi-resource tag list are records. The same rules apply as with the single-resource tag lists when it comes to building the resource names from the tags and the templates. The first record of the example above gives:

gr_gid_lcfg=
gr_mem_lcfg=
gr_name_lcfg=
gr_passwd_lcfg=
gr_grpent_lcfg=lcfg:x:980:

The value of the extragroup resource when these two records are the complete list is lcfg quagga.

If there are zero resources for the tag-list there will be an empty template and a set of records, this just generates a single resource which is a space-separated list of tags. For example:

<client>
  <components cfg:derivation="..." cfg:template="">
     <component_RECORD cfg:name="sysinfo">
     </component_RECORD>
     <component_RECORD cfg:name="client">
     </component_RECORD>
     <component_RECORD cfg:name="auth">
     </component_RECORD>
     <component_RECORD cfg:name="file">
     </component_RECORD>
     <component_RECORD cfg:name="authorize">
     </component_RECORD>
     <component_RECORD cfg:name="boot">
     </component_RECORD>
     <component_RECORD cfg:name="cron">
     </component_RECORD>

This would make the client.components value to be the string sysinfo client auth file authorize boot cron, this is a slight peculiarity and not something that happens much but must still be handled properly.

The following attributes are always supported:

cfg:derivation
A space-separated list of locations (file names and line numbers) in the source files where this resource has been specified, (e.g. /var/lcfg/conf/server/defaults/client-3.def:47).
cfg:context
An LCFG context specification which must evaluate to true for this resource value to apply, (e.g. net=none).
cfg:type
An LCFG type which applies to this resource (typically one of boolean, integer, string or list)

Packages

Under the packages node there are one or more package element nodes. For example:


<package cfg:derivation="/var/lcfg/conf/server/releases/develop/core/packages/lcfg/lcfg_sl6_lcfg.rpms:13">
    <name>lcfg-client</name>
    <v>2.3.1</v>
    <r>1/noarch</r>
</package>
<package cfg:context="install!=true" cfg:derivation="/var/lcfg/conf/server/releases/develop/core/include/ed/options/kernel-sl6.h:55">
    <name>kernel-devel</name>
    <v>2.6.32</v>
    <r>358.14.1.el6/x86_64</r>
    <options>b</options>
</package>

Each package node always contains the following singleton element nodes:

name
The name of the package (e.g. lcfg-client)
v
The version string of the package (e.g. 2.3.1)
r
The release string of the package (e.g. 1/noarch)

It may also contain the following singleton element nodes:

options
Options which should be passed to the package management tool (e.g. updaterpms). For example, this might be b for "boot-time only" or r for "request reboot".

The following attributes are also supported:

cfg:derivation
A space-separated list of locations (file names and line numbers) in the source files where this package has been specified, (e.g. /var/lcfg/conf/server/releases/develop/core/packages/lcfg/lcfg_sl6_lcfg.rpms:13).
cfg:context
An LCFG context specification which must evaluate to true for this package to be installed, (e.g. install!=true).

-- Main.squinney - 2013-12-05

Topic revision: r2 - 2013-12-05 - squinney
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback