YaST2: The System Configuration Repository (SCR)

Agents

The SCR creates a consistent view onto the system hardware and configuration files. For each piece of interest there exists a corresponding YCP data structure representing it. The SCR has a bunch of helper programs, which do the actual work. Such a helper is called agent. An SCR agent maps a YCP data structure onto a particular piece of hardware or a configuration file and vice versa.

An example agent could be one the reads and writes the hostname of the computer. The YCP representation of the hostname is a data structure consisting of a single string. When writing, the agent changes the variable HOSTNAME in the file /etc/rc.config and calls the program hostname to set the hostname in the kernel. When reading, the agent calls the program hostname to read the actual hostname and creates a YCP string from it.

Documentation about the agents can be found below the /usr/share/doc/packages/yast2/ag_* directories.

Tree

As a computer's hardware and software configuration is quite complex, the SCR organizes all data in a tree. It is much like a filesystem. The SCR tree consists of three different kinds of nodes:

data nodes A data note represents one piece of data, for example the hostname or the mountpoint of one of the filesystems in /etc/fstab. It is a leaf in the tree.
map nodes A map node is an inner node. It has none, one or more subtrees and assigns a name to each subtree. It is used to structure data. The root node of the SCR tree is a map node. One of its subtrees is called config, another hardware. The name map node resembles the YCP data type map.
list nodes A list node is much like a map node, but its subtrees are not named but numbered. List nodes represent data that is countable, such as the /etc/fstab.

Paths

A path is a description were to find a node in the tree. It is a list of path components. Each path component may be either a string or an integer. The empty list specifies the root node. If the path p specifies a map node and the map node has a subtree called n, then add(p, n) specifies the root node of the subtree. If the path p specifies a list node and the list node and i is an integer, then add(p, i) specifies the i'th subtree of the list node.

Consider this tree:

The green nodes are list nodes, the blue nodes are map nodes, the smaller grey nodes are data nodes. The right green node represents the filesystem table (/etc/fstab).

The path to the fstab list node is ["config", "fstab"]. The path to the second entry in the filesystem table is ["config", "fstab", 1]. The YCP parser allows you to write paths with a dot-notation. In dot-notation the path would be written .config.fstab.1. The path to the mount point of the first entry of the filesystem table would be .config.fstab.0.mountpoint.

Access

The task of the SCR is to provide the modules with information about the hardware and the software configuration and write back changed configuration without the modules having to know anything about the details of the data representation.

For this the SCR provides an API, i.e. a defined set of YCP functions it understands. You can call these functions from YCP scripts running in the Workflowmanager with the call SCR(...). We use path as a shortcut for list(string|integer). These are the commands:

FunctionWhat it does
Read(path p) -> any Reads the data represented by the node at path p.
Write(path p, any v) -> boolean Writes the value v to the node at path p. The boolean return value is true on success. On error a log entry is made. Reasons for errors can be a mistyped value v or some problem with the periphery.
Dir(path p) -> list(path) Returns a list of all subtrees of the node p. p must point to map node. For each subtree the list contains a string. In the example if you call Dir(.config), the answer would be ["net", "fstab"]

Agents and Implementation

How is the SCR implemented? Each agent handles one subtree. In our example one agent handles the filesystem table. It is mounted to the path .config.fstab. If the SCR gets a request for this path, it delegates it to the agent, stripping the .config.fstab away before this. Thus if you send Read(.config.fstab) to the SCR, the fstab agent will have to answer Read(.). The agent has to handle all calls for one of its nodes.

The fstab agent does not only have to be able to read the complete fstab in answer to Read(.), it also has to implement reading of one entry, e.g. Read(.3). It has to implement every SCR function for every node. To make life easier, there is a library that supports writing agents, which is called libscr.

The easiest way to implement an agent is one, that only implement Read() and Write() for the root path (.). The libscr can deduce the implementation of the other paths from that, even if it is less performant than a native implementation could be.

Remote SCR

There is no special networking support within the SCR, since this is not neccessary: Any two YaST2 components can communicate over a network connection choosing out of a variety of protocols like telnet, rsh, getty or a serial line. When you mount an agent into the scr tree, you specify a server component name. This name can denote a remote component as well as a local one.