Blog

In the age of Infrastructure as a Service (IaaS) most cloud platforms have APIs to update and read the current configurations. Linux in comparison, tends to have an array of text files. While there are tools such as Ansible, Chef, Puppet etc to automate configuration of config files, they often don’t really understand the text files. Instead, they apply mechanical text transformations with complex expressions to match lines or words or make substitutions. We’d argue there’s a number of drawbacks of having lots of text files for config:

A separate format for every program which results in:

1. Each program maintaining its own parser. This isn’t ideal for security, plus other associated tooling needs to be maintained and developed, e.g. means of generating corresponding documentation.
2. Users having to learn multiple syntaxes.
3. Little reuse of external configuration tools, e.g. Ansible has separate modules to handle configuration of each program.
4. No accessible parser for external tools to manipulate the config files – instead tools have to build their own parsers or some hideously complicated regular expression to ‘find and replace’ that hopefully doesn’t have unintended consequences.
5. 'Blunt' version control. At best, version control considers the contents of the text file. There’s no ‘smartness’ that determines what the change actually means – has a setting been updated, or is it just an updated comment?
6. Permissions granularity – permissions are only enforced by the file system on whole text file level

As computer scientists we look for patterns and opportunities where we can reuse code. But many programs are maintaining their own parsers and mechanisms for generating documentation. Users also have multiple syntaxes to contend with; ‘what is the separator for this file, commas, tabs, colons or equal sign?’, ‘What about comments, are they # , or ;, and are they restricted to being the first character of a line’?

When text files are compared without parsing them, it's difficult to know the meaning of what has changed. Consider when Linux packages are upgraded, the current mechanism is to use diff to compare text files and look for the lines that aren’t identical. Diff can’t determine between a harmless comment added to a line or a breaking change. If instead, a standard structure were to be adopted, there could be a standard tool to determine exactly which nodes had changed, and further logic could be built to determine if this resulted in conflicting settings, or if not, merge them.

With text file configurations, there’s no fine grained security. It’s not possible to restrict access to a single configuration setting, all that can be done is limiting read and/or write permissions of the entire file.

In our next post we suggest where we think development is needed to bring configuration files up-to-date.