Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introducing libeconf - Bringing systemd-like configuration layering to everything else

Introducing libeconf - Bringing systemd-like configuration layering to everything else

systemD has a very distribution-friendly way of providing it's configuration, with distributions providing defaults in /usr and users being able to override things either selectively or entirely with their own files in /etc. This is especially nice for distributions wishing to be in some way stateless, support a read-only root filesystem, or provide some kind of factory-reset. libeconf is a newly written C library to ease the adoption of similar configuration layering in other programs across the Linux ecosystem.

This talk will give a brief introduction to libeconf, how to use it in your existing programs and demonstrate some examples that have already adopted libeconf (eg. PAM, util-linux, rebootmgr, etc).

The session will also share some future plans and welcome suggestions for future contributions, especially for additional features, language bindings, etc.

The target audience is primarily developers of 'low level' distribution plumbing (eg. core daemons & services, package managers, etc) that are most likely to benefit from libeconf, but might be of interest to anyone developing any service for linux distributions.

Richard Brown

February 02, 2020

More Decks by Richard Brown

Other Decks in Programming


  1. Introduction to libeconf Bringing Peace to the Configuration War Linux

    Distribution Engineer Richard Brown [email protected] sysrich on Freenode.net @sysrich
  2. Distributions • Distributions are responsible for providing a good out

    of the box experience • This includes distributing “sensible” defaults • New upstream developments often require new settings
  3. Users • Users need to be able to configure their

    system as they see fit • This may include “unsensible” choices • They might not know of new features/changes needing new settings
  4. Problems • Distribution config installed in /etc/$foo.conf • User edits

    /etc/$foo.conf • New $foo package wishes to change defaults/introduce new parameters • …….
  5. Imperfect Solutions • Package PostScripts editing existing /etc config –

    Users: “The Distro broke my config!” • Backing up user config and installing new in /etc (eg .rpmsave) – Users: “The Distro broke my config!” • Avoiding user config in /etc and storing new alongside (eg .rpmnew) – Distros/Upstreams: “Sorry your setup is not supported”
  6. Atomic Distros (eg. openSUSE MicroOS) • Growing availability of Atomic/Transactional

    Distributions • Many allow users changing /etc for runtime configuration changes • Need some way of atomically delivering new configuration with their atomically installed packages
  7. systemD • Nice structured ‘Unit’ files • Dedicated location for

    distro config – /usr/lib/systemd/system • Dedicated location for user config – /etc/systemd/system
  8. systemD drop-ins • Selected parameters can be overridden by ‘drop-in’

    files – /usr/lib/systemd/system/$foo.service.d – /etc/systemd/system/$foo.service.d • Perfect for distros with multiple ‘consumers’ of a service & and for users wanting to make minimal changes
  9. libeconf • Flexible & configurable C library for implementing systemd-like

    configuration layering • Supports both “/usr vs /etc” configs and “/usr/*/$foo*.d/ vs /etc/*/$foo*.d/” drop- ins
  10. Current Limitations • Not magic; software must add libeconf support

    • Only suitable for “.ini style” config values with key/value/group structure [Group] Key=Value Key2=Value2
  11. API Call Examples • econf_readFile – read config file and

    stores it’s contents into a key_file • econf_readDirs – read config files in directory • econf_getGroups – get [Groups] from key_file • econf_getKeys – get Keys from Group • econf_get{$FOO}Value – get Value (of type {$FOO}) from Key
  12. API Call Examples • econf_set{$FOO}Value – set Value of type

    {$FOO} in a Key • econf_mergeFiles – merge contents of two key_file • econf_writeFile – write config file from key_file (not yet stable)
  13. libeconf & openSUSE - /usr/etc • /etc is considered ‘user

    data’ and treated with the same reverence & avoidance as /home, /srv and similar. • libeconf managed config files moving to /usr/etc • These locations are configurable by bother distros and software developers
  14. Examples • pam – Distro config in /usr/etc/pam.d – User

    config in /etc/pam.d – Both parsed with libeconf at runtime – /etc values always win
  15. Examples • shadow – Distro config in /usr/etc/pam.d & /usr/login.defs

    – User config in /etc/pam.d & /etc/login.defs – Both parsed with libeconf at runtime – /etc values always win
  16. Examples • util-linux (su, login, remote, runuser) – Distro config

    in /usr/etc/pam.d – User config in /etc/pam.d – Both parsed with libeconf at runtime – /etc values always win
  17. Examples • Rebootmgr – Distro config in /usr/etc/rebootmgr.conf – User

    config in /etc/rebootmgr.conf – Both merged libeconf at runtime, written to /etc/rebootmgr.conf
  18. Plans • Augeas – Highly reliable parser with support for

    more complex merging, diverse filetypes & layouts – Not Certain: Larger dependencies, more code complexity • econftool – Generic ‘helper’ tool for understanding and editing layered configuration