skip to main content

LCFG Build Tools : Anatomy of a Component Package

Before building a package it is worth familiarising yourself with the files which are likely to be present for an LCFG component. A standard LCFG component which uses the "old" system will contain some or all of the following files:


A number of files will have the ".cin" suffix, this indicates that they should go through a translation stage before the final package is built. This replaces all autoconf-style macros (e.g. @FOO@) with the associated values. Note that the way in which this is done differs slightly between the old and new build tools. Previously a shell script using sed, named "" was generated which rewrote the files, only changing known variables. With the new system CMake is used and it will replace ALL variables, if a variable is unknown then it will be replaced with an empty string

Assuming a package version of 1.2.3 this typically gives an installed file tree like:


The Component

For an LCFG component named "foo" there is normally a Perl or bash shell script which will actually do the configuration work. This will be named "foo.cin". This will be installed into the LCFGCOMP directory.

The Schema

For an LCFG component named "foo" there is normally a schema file which specifies the resources used by the component, what values they can hold and their default values. This will be named "foo.def.cin". This will be installed into the LCFGCLIENTDEF and LCFGSERVERDEF directories.

Configuration Files

The only configuration file which might be considered a standard part of an LCFG component is the logrotate template. The ngeneric component generates logrotate configuration files for each component. If a component-specific template exists that will be used otherwise it uses a default. Most components just use the default so it is unusual to see this as part of a component package.


Many components have a file named "template" or "template.cin" in the top-level directory for the project. Many other projects use a "templates" sub-directory. The old build tools did not have any built-in support for managing templates but there are some accepted practices.

Nagios Modules

Some LCFG components have associated LCFG nagios Perl modules. These are stored in the "nagios" sub-directory and are named like "*.pm" or "*.pm.cin". Typically they use the Perl MakeMaker tool to handle installation.

Documentation Files

A number of files document the component source. These include README, README.BUILD, ChangeLog and the pod file (e.g. "foo.pod"). Of these the most important is the pod file, this will be installed into the LCFGPOD directory and will also be converted into a unix manual page and installed as "lcfg-foo" in section 8. It is not a requirement to have this documentation but it is considered good practice to document the resources and methods to which the component responds. The other important documentation file is the change log, normally named "ChangeLog", which notes all the component changes, bug fixes, etc. The location into which these are installed is typically dependent on which packaging system is being used (e.g. RPM)

Build Files

The old LCFG build tools relies on a file named "" to document various component metadata and a Makefile to drive the build process. The new build tools use a file named "lcfg.yml" to hold the component metadata and, optionally, a file named "CMakeLists.txt" to drive the build process. It is possible to convert the old config to the new with a tool named lcfg-cfg2meta. The other file which might exist is a specfile for building the component into an RPM.