YaST2: The System Configuration Repository (SCR)
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.
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:
|
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 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:
|
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.
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.