Skip to content

Latest commit

 

History

History
265 lines (204 loc) · 12 KB

2017-03-18_lcdproc.md

File metadata and controls

265 lines (204 loc) · 12 KB
Raw

Elektrify LCDproc

  • guid: d52657b5-60da-4a21-9679-f8aacf6d6b72
  • author: Markus Raab
  • pubDate: Sat, 18 Mar 2017 20:43:03 +0100
  • shortDesc: Elektrify LCDproc

LCDproc is a piece of open source software that displays real-time system information from your Linux/*BSD box on a LCD.

LCDproc's website is a bit outdated but LCDproc itself is now well-maintained on GitHub and had a release recently.

Like in many projects, it invented its own configuration access and INI parser which did not evolve with the needs of the project. As a consequence inconsistencies and code duplication spread over the source. For example, the LCDproc configuration access does not support values that represent display's size (such as 20x4). Thus every LCDproc's module has its own parsing code for such values.

Some days ago (16.03.2017), we met with Harald Geyer and discussed the current situation. We decided that we will elektrify LCDproc and remove all the configuration access and parsing code within LCDproc. To elektrify an application means to change the application so that it uses LibElektra afterwards.

Goals

We formulated three goals:

  1. We (Elektra Initiative, mainly Thomas Waser) remove as much code as possible from LCDproc's code base.
  2. Users of LCDproc should be able to use LCDd.conf as they use it now.
  3. We avoid the current duplications of configuration specifications. (Currently in LCDd.conf, the docbook, in code checking the limits, and the default parameter in the code.)

Nice-to-have is:

  • Safe updates: make install should not break the current LCDd.conf. (As it is already done in Debian.)
  • The robustness of LCDproc on misconfiguration should be improved (Thomas Waser writes the specification).
  • Automatic reloading of the daemon when using Elektra to update configuration. (Manual SIGHUP-signals will work in any case.)
  • Have physical units with metric prefix like 500ms for 0.5s (seconds).

Possible limitations are:

  • We break support for systems that only have very old compilers.
  • The -c option to specify a different configuration file is against the abstraction Elektra should deliver. We might create a wrapper script that emulates -c via mountpoints.
  • LCDproc will depend on the yet-to-be-released 0.8.20. We will delay the 0.8.20 release until all parts for LCDproc are tested and ready.

In any case, the advertised benefits of Elektra will automatically apply (incomplete list):

  • Global key database: you can connect other configuration files with the LCDproc's configuration and validation.
  • Allows users to easily modify the specifications, for example to have different command-line options, or support for environment variables.
  • Profile support: Having multiple complete configuration settings you can easily choose from. (thanks to Thomas Waser)
  • Introspectibility: you can check with kdb-tool which configuration settings LCDproc will receive.
  • Other configuration file formats can be used instead, e.g. JSON or XML. (Only if wanted as personal preference, by default INI will be used to remain compatibility with LCDd.conf.)
  • Easy migration paths to use other configuration file formats such as YAML as default in future. (thanks to René Schwaiger)
  • Elektra's tool can be used to configure LCDconf, including:
    • kdb set to modify individual settings within scripts and validation.
    • kdb editor, which spawns your favourite editor but validates the configuration file before writing it out.
    • kdb qt-gui, the Qt GUI (thanks to Raffael Pancheri).
    • The web UI of Elektra (thanks to Daniel Bugl).
  • Elektra's website can be used to share LCDproc's configuration files, and you can use the curlget plugin to mount files from the website. (thanks to Marvin Mall)
  • You can use Shell, Python, or Lua to write small scripts that are executed on configuration access.
  • Elektra allows you to directly read and write from git using the git plugin. (Even if LCDd.conf is not checked out, thanks to Thomas Waser)
  • We extensively test Elektra with modern techniques such as fuzzing.

Validation

Instead of ifs within the code, we will use SpecElektra for validation. SpecElektra is a configuration specification language that allows us to describe which configuration is valid.

This specification will be installed as part of LCDproc to /usr/share/elektra/specifications. It uses the metadata as defined by the plugins to validate configuration changed via Elektra.

For broken installations or when executing LCDproc from the source repository, there is also a built-in specification. The specification will only be used if the installed one cannot be found.

Thus the configuration validation specification is a normal configuration file also integrated in Elektra, also the specification can be introspected: useful for system administrators who want to know about valid entries, but also for tools like our newly developed web-UI by Daniel Bugl.

The web-UI automatically restricts the interface so that only valid entries can be entered. For example, if you should enter a boolean, only a check box is presented to you.

  • For more information about validation, see the tutorial

Code Generation

We (mainly Dominik Hofer) are currently developing a high-level API, whose first user will be LCDproc. In this API, we will make sure during compilation, that configuration access is done correctly.

This is especially useful when configuration settings get renamed. Then all places where out-dated configuration settings are used will fail to compile.

In particular using code generation developers do not need to use strings to refer to configuration settings and they get easy-to-use enums consistent with the configuration specification.

Furthermore, code generation will make sure that a specification (and default configuration settings) will be found even if no /etc or no /usr is found.

We also found that we cannot use code generation everywhere. In generic access code, code generation obviously is limited.

  • For more information about code generation, see the tutorial

Risks

Understandably, users might be concerned that such a change will not work or create problems in the future. Here we will discuss some of the concerns.

Elektra might be discontinued.

From history perspective, Elektra received steady development since 2004. Elektra is a FLOSS project and welcomes everyone to join. In the last years several people did, with an increasing number per year. Currently following people are working on substantial new features in Elektra (sorted by first name):

  • Armin Wurzinger: Quality Improvements
  • Bernhard Denner: Puppet Module
  • Daniel Bugl: WebUI
  • Dominik Hofer: the high-level API
  • Kurt Micheli: Order Preserving Minimal Hash Map
  • Markus Raab: Maintainer
  • Michael Zehender: Quality Improvements
  • Mihael Pranjić: mmap plugin
  • Peter Nirschl: crypto plugin
  • René Schwaiger: YAML plugin
  • Sebastian Bachmann: Shell Completion
  • Thomas Waht: Notification
  • Thomas Waser: Validation and Transformations of Configuration
  • Vanessa Kos: Misconfiguration Bug Database

Obviously, there are many more casual contributors.

Elektra has a large set of automated tests and only a small amount of technical dept. Elektra has no required external dependencies except libc. So without internal changes, only minimal maintenance cost is required.

Elektra is unfinished.

Technically this is true: we did not reach 1.0. We are, however, on track to reach this goal within this summer. Now is the best time to join because we can provide more support and are more flexible for changes and wishes.

Some time ago we asked in a survey in which direction Elektra should develop. Most open issues are (in)direct responses from this wanted direction.

Some plugins are experimental or proof-of-concept, but they are clearly marked as such.

It seems a bit to me like xkcd: Standards.

Elektra does not invent a new configuration file format nor new standards where to store configuration files but abstracts over these issues.

Elektra not being available in my distribution.

For the following Linux Distributions Elektra 0.8 packages are available:

See INSTALL for the complete and up-to-date list.

If Elektra does not take off and achieve world dominance, will we be worse off than before?

Making sure that projects will not be worse off is what we did the last years: Not only offer an API and wait for world dominance but to offer an implementation that can compete with any configuration library out there. We are not completely there yet (there are some details where specific other libraries are better than Elektra in specific points) but these are not points that the current configuration system of LCDproc supports (not even close). And the libraries that can compete with Elektra have a completely different level on which dependencies they have: Elektra is the only one only requiring libc.

Do we retain the old way of configuring things, i.e. manually editing an ini file in /etc?

Absolutely, you can think of libelektra as a small library in C that reads a configuration file and returns a data structure if you do not use any of its advanced features.

Do we retain the old way reloading/restarting the system service?

Elektra does not interfere with restarting. It is a passive library. It provides some techniques for reloading but they are optional (but we recommend that you keep the in-memory and persistent configuration in sync via notification).

For more information, see the FAQ.

Win-Win

We can both profit from it:

  1. For LCDproc it will be a simplification of code while getting many more tools.
  2. For Elektra it will improve its adoption and packaging.

For oyranos it already worked well on both sides, see our discussions in the issue tracker, for example #1134.

If you also maintain an free or open source (FLOSS) project with an out-dated configuration system, please contact us.

Obviously, we cannot fully port every FLOSS project ourselves, instead we will handle requests on a first come, first serve basis. Earlier projects will also have an higher impact on the feature set of Elektra, thus you will less likely need to implement your own plugin.

See Also

  • Progress can be viewed here
  • We discussed about alternatives to Elektra here.

Best regards, Markus