Linuxconf framework

Modules may interact in various ways with Linuxconf framework. As such they can provide more functionalities than independant admin tools.

Menu registration A module may map in various place in linuxconf menu
Command line options Module may define their own command line
Virtual registry Map configuration into the virtual registry
Resources Adapt to different Linux distribution/version
Inter-module messaging Reacts to various broadcast sent by other linuxconf areas
Inter-module APIs Export various functions usable by other modules
Probing Participate in the activation control
Privileges Fine grain privileges to allow operation by non root users
Co-managers Several module may participate in a single dialog
Gurus Visual step by step configurations
System profile versioning Archive configuration files in various profiles
Standalone mode Perform task for end users
Programming language Modules may be written in C++, Python, Perl and Bash

Menu registration

A module may provide functionalities in various sub-menu of the framework.

Modules using this feature

Command line options

A module has generally a good understanding of the various configuration file it is handling. As such, it is a good candidate to perform various automated operations on those files.

Modules may define their own set of command line option. Often a module main menu is reachable directly from the command line. The general syntax is:

	linuxconf --modulemain module-name [ options ... ]
	linuxconf --modulemain module-name --help

Note also that "linuxconf --help" presents the command line of all enabled module.

Modules using this feature

Several module provides command line options: apache , dhcpd , dialout , dnsconf , gurus , inittab , kernelconf , mailconf , managerpm , netadm , postfixconf , shellmod , syslogconf , usermenu , vregistry , wuftpd , xterminals

Virtual registry

The virtual registry is a uniform interface to manipulate settings in the various configuration file found in Linux. A module has the ability to parse and write back various configuration file. It then exports "variables" to the virtual registry so other modules may peek and poke into those configuration files without any knowledge of their format.

The module vregistry make the virtual registry available from the command line. It becomes very easy to manipulate configurations from shell scripts. Here is an example:

	/sbin/vregistry --set samba.workgroup mygroup

It also make it easy for one module to interact with another module. Here is a C++ example:

	master_registry.start_session();
	master_registry.set ("samba.workgroup","mygroup");
	master_registry.end_session();

The virtual registry is an abstraction. There is no intermediate file or hidden database.

Run "/sbin/vregistry --list" to learn which variables are available.

Modules using this feature

More and more modules exports variables this way. Here are some dhcpd , dialout , kernelconf , mailconf , nisconf , samba , usersbygroup

Some useful links

virtual registry C++ documentation

Resources

Modules using this feature

Inter-module messaging

Modules using this feature

nisconf , samba

Inter-module APIs

Modules using this feature

conectiva , dialout , dhcpd , dnsconf , fetchmailconf , firewall , gurus , inetdconf , inittab , kbdconf , managerpm , modemconf , nisconf , pppdialin , redhat , redhatppp , samba , status , syslogconf , Xkbdconf , xterminals

Probing

Modules using this feature

Privileges

A module may define various privileges. Those privileges may be granted to normal users. A module may define a fixed number of privileges, or potentially a variable number based on the current configuration. For example the printer module defines one privilege per printer queue.

Modules using this feature

dialout , fetchmailconf , mailconf , printer , usersbygroup , usermenu

Co-managers

It is sometime useful to coordinate the edition of independant configurations using a single dialog. This make life much easier for the administrator. A good example of this is the user account dialog. There are several settings related to user accounts and those settings are related to different packages (potentially not installed).

Having to visit many dialogs everytime you add, delete or modify a user account is cumbersome and error prone.

Several modules may participate to a single dialog, adding fields and notebook tabs as needed. They participate to the layout and validation. They are informed when the dialog changed are accepted or canceled. They are also informed if the record (the user account) is deleted, so they can do some cleanup. For example, if you delete a user account, the mailconf module deletes the corresponding user from all aliases list.

Modules using this feature

mailconf , status , treemenu

Some useful links

USERACCT_COMNG: Co-manager API

Gurus

Modules using this feature

gurus , xterminals

System profile versioning

All configuration files manipulated by a module are associated to one or more sub-system definition. Linuxconf may enumerate every configuration files managed by its various module. It also knows to which sub-system they belong.

Supports is also provided for module managing a variable number of configuration file. For example the dnsconf module manage an arbitrary large number of zone files defined in /etc/named.conf. Using the CONFIG_FILE_LISTER object, Linuxconf can request the module to enumerate those extra configuration files.

From there, Linuxconf can perform various operations on configuration files:

A profile associated the various sub-systems to different archives. Two profile may select the same archive for all sub-system except one. When switching between those 2 profiles, only one sub-system is exchanged. This allow one to tell what is common and what differs between to profile.

You will find more information about system profiles and how they may be used here

Modules using this feature

All

Standalone mode

A module may be executed by linuxconf or linuxconf-wrapper. The later is executing the module without any privileges. The module received a flag "standalone". It tells the module it is not doing system administration, but serving a end user. A module may be used this way to configure system files and let a user override some settings in his private configuration files (in his HOME).

Some module such as wineconf may use this way to double as a system tool and an end user tool.

linuxconf-wrapper may be use to run linuxconf modules on operating system where linuxconf has not been fully tested. A module may be used independantly.

Modules using this feature

wineconf

Programming language

Linuxconf is written in C++, but other languages may be used to write modules. Not all language bindings are equal (so far at least). Bindings are provided by modules written in C++, themselve managing their own modules.

At this point, the pythonmod provides access to most of the services outlined in this document while the shellmod module provide access to the user interface and the co-manager facility. Shellmod may be used to write module in bash or perl. Especially useful for on-site enhancements.

Modules using this feature

pythonmod , shellmod