LinCS
(Linux Configuration System) is a configuration tool aiming to offer a uniform way for applications,
the OS itself and machine clusters to store/retrieve their configuration information. Thus, it will
completely replace the standard configuration files, such as the ones stored in /etc. It follows on the
road opened by other configuration tools such as gconf but it is novel in that
it addresses the area of system configuration. Another novelty is that it offers
a transparent way for "older" applications that use configuration
files to live on a LinCS-configured OS. Its design is modular and
extensible.

A separate component is the text-based UI editor
tiger
(Text Interface Generic EditoR), allowing users to manage their
configuration values and admins to configure the machine(s).

LinCS is written in C, while tiger in written in C++, as it uses third-party
libraries for the UI - currently tvision.

Currently only Linux is used as a development platform but if it succeeds in
being adopted by enough users, one might expect it to be ported to other
platforms. Internationalization is an issue that will be targeted later, while
security and robustness are of every moment concerns.

Quick Overview

The LinCS system is one unique tool aiming to allow to configure and
administer networks, machines and applications in an uniform way and to offer
additional functionalities, such as notifications when configuration changes,
and rollbacks.
LinCS is made mainly of the following components:

A client library, of which applications willing to benefits from
the new features have to make use.

A library to intercept calls from applications not using directly
the LinCS system, as to allow them live on a LinCS-configured machine
without having to re-write and re-compile them. The library makes
use of various expert modules to re-create the configuration
files from the values stored by LinCS.

A daemon serving requests from clients. Currently there is a daemon per
machine but there might be also a daemon per user in the future.

Various modules named backends, that manipulate configuration
information or offer special functionalities. This modular
approach gives the system the flexibility needed to add
functionality in a transparent way.

Various admin tools.

The client library normally talks directly to the daemon to fulfill requests but
if the daemon is not up (for instance, at boot time) the library will talk
directly to the backends.

The configuration information consists of entities, each one having a list of
attributes, each attribute having a name (call it att-name) and a value
(att-value). For instance we can have a config entity to store the IP address
of the first network card: an entity with an attribute with
att-name='name' having the associate att-value='/network/ip/eth0' and with an
att-name='value' having the associate att-value='192.168.60.3'. There is no
restriction concerning the attribute list but some att-names have special
meanings.

The space of configuration entities is thus structured logically by the
att-name called 'name'. It is planned to have entities also groupped into
layers, a layer taking precedence over another based on a policy decided
by the administrator.