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.

C4d991702dcb0afa2b2afd8464be7f66?s=128

Richard Brown

February 02, 2020
Tweet

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 • …….
  7. None
  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
  24. None