$30 off During Our Annual Pro Sale. View Details »

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

    View Slide

  2. Who’s responsible for configuration?

    View Slide

  3. Who’s responsible for configuration?

    View Slide

  4. Distributions

    Distributions are responsible for providing
    a good out of the box experience

    This includes distributing “sensible”

    New upstream developments often
    require new settings

    View Slide

  5. 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

    View Slide

  6. Problems

    Distribution config installed in

    User edits /etc/$foo.conf

    New $foo package wishes to change
    defaults/introduce new parameters


    View Slide

  7. View Slide

  8. 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”

    View Slide

  9. 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

    View Slide

  10. systemD

    Nice structured ‘Unit’ files

    Dedicated location for distro config
    – /usr/lib/systemd/system

    Dedicated location for user config
    – /etc/systemd/system

    View Slide

  11. 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

    View Slide

  12. libeconf

    Flexible & configurable C library for
    implementing systemd-like configuration

    Supports both “/usr vs /etc” configs and
    “/usr/*/$foo*.d/ vs /etc/*/$foo*.d/” drop-

    View Slide

  13. Current Limitations

    Not magic; software must add libeconf support

    Only suitable for “.ini style” config values with
    key/value/group structure

    View Slide

  14. 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

    View Slide

  15. API Call Examples

    econf_set{$FOO}Value – set Value of type
    {$FOO} in a Key

    econf_mergeFiles – merge contents of two

    econf_writeFile – write config file from
    key_file (not yet stable)

    View Slide

  16. 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

    These locations are configurable by
    bother distros and software developers

    View Slide

  17. Examples

    – Distro config in /usr/etc/pam.d
    – User config in /etc/pam.d
    – Both parsed with libeconf at runtime
    – /etc values always win

    View Slide

  18. Examples

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

    View Slide

  19. 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

    View Slide

  20. Examples

    – Distro config in /usr/etc/rebootmgr.conf
    – User config in /etc/rebootmgr.conf
    – Both merged libeconf at runtime, written to

    View Slide

  21. Plans

    – Highly reliable parser with support for more
    complex merging, diverse filetypes & layouts
    – Not Certain: Larger dependencies, more code

    – Generic ‘helper’ tool for understanding and
    editing layered configuration

    View Slide

  22. Other Ideas

    Different file parser

    Language Bindings
    – Python?
    – Go?
    – Rust?

    View Slide

  23. How to Contribute


    Contributions Welcome

    Changes Welcome

    New Features Welcome

    View Slide

  24. View Slide