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.

Transcript

1. Introduction to libeconf Bringing Peace to the Configuration War Linux Distribution Engineer Richard Brown rbrown@opensuse.org sysrich on Freenode.net @sysrich
2. Who’s responsible for configuration?
3. Who’s responsible for configuration?
4. 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
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
6. Problems • Distribution config installed in /etc/$foo.conf • User edits /etc/$foo.conf • New $foo package wishes to change defaults/introduce new parameters • …….
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”
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
10. systemD • Nice structured ‘Unit’ files • Dedicated location for distro config – /usr/lib/systemd/system • Dedicated location for user config – /etc/systemd/system
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
12. 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
13. 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
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
15. 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)
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 /usr/etc • These locations are configurable by bother distros and software developers
17. 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
18. 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
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
20. 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
21. 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
22. Other Ideas • Different file parser • Language Bindings – Python? – Go? – Rust?
23. How to Contribute • https://github.com/openSUSE/libeconf • Contributions Welcome • Changes Welcome • New Features Welcome