One of the most painful legacies of UNIX’s long gestation is the mess of scripts, configuration files, and databases we affectionately call “/etc”. Binaries go in “/bin”, libraries belong in “/lib”, user directories expand out under “/home”, and if something doesn’t fit? Where does it go? “/etc”.
Of course, “/etc” isn’t really the overflow directory that its name would imply. “/config” would be a far better choice, more accurately reflecting the nature of its contents, but like so much of the data contained within it, its name suggests a lack of organization rather a coherent collection of configuration settings. While the rest of the filesystem has moved on to SQL, the user account database is still stored in colon-separated fields. Cisco routers can snapshot a running network configuration to be restored on reboot, but the best we can do is fiddle the interfaces file, then reboot to take the changes live. Or adjust the interface settings by hand and wait for the next reboot to see if the network comes up right. Our name service is configured in /etc/hosts, or /etc/resolv.conf, or /etc/network, or /etc/dnsmasq.d, or /etc/systemd, or wherever the next package maintainer decides to put it. Nor can you simply save a system’s configuration by making a copy of /etc, because there’s plenty of non-configuration information there, mostly system scripts.
What a mess.
The networking community has been experimenting for years with standardized data models for device configuration, initially SNMP MIBs, and more recently YANG. While SNMP was widely adopted for monitoring operational statistics, it was never really accepted for device configuration. YANG may change that. At the very least, Cisco seems to be moving decisively towards adopting YANG
for configuration tasks, with both NETCONF and RESTCONF supported as configuration protocols. It is yet to be seen if these network programmability tools will supplant command-line configuration to any meaningful degree.
Part of Cisco’s network programmability strategy involved their 2014 acquisition of the Swedish company Tail-f, a leader in YANG development. I recently spent a few hours experimenting with the free version of their confd product, and while it isn’t free software, it certainly left me thinking that we need something like it, and soon.
confd‘s basic design is that a single configuration daemon (confd) manages all system-wide configuration tasks. confd provides a command-line interface for interactive configuration, speaks NETCONF and RESTCONF to management software, saves and restores running configurations, and maintains a history of configuration changes to facilitate rollback. Other specialized daemons interact only with confd, via an API that lets them retrieve their configuration information and receive notifications of changes.
Consider, for example, dhcpd, and allow me to discard Tail-f’s currentl implementation of confd and speculate on how a free software confd might operate. dhcpd‘s distribution would include a file or files containing a YANG data model that specifies all of dhcpd‘s configuration state, plus operational data such as a list of current DHCP leases. dhcpd, when it starts, would connect to confd over D-Bus, using a standard API that allows any YANG-capable client to announce a YANG model to confd, obtain its current configuration, and subscribe to future changes. Administrator configuration of dhcpd will occur by connecting to confd‘s CLI and altering the data model there. The dhcpd model would be one part of a comprehensive data model that would represent the configuration of the entire system, and could be saved and restored in any format (config file, XML, JSON) understood by confd. confd, on its part, would need no DHCP-specific component, as it could parse YANG and interact with any client exporting a YANG data model.
The ultimate goal would be replacing most of /etc with a single configuration store that captures the entire configuration of the system. The running and startup configuration would both be stored in the same format, allowing administrators to adjust the running configuration, then save it with the confidence that it will be correctly restored after the next reboot.
The biggest challenge would be to convince the developer community to embrace such a standard. With so much momentum behind the current hodge podge structure of /etc, it seems like a tough sell. The easiest thing to do is to keep doing what we’ve always done. Got a new daemon? Whip up a config file in whatever format you please and stick it somewhere in /etc. Which, of course, add more momentum to a poor design.
A first step in this direction would be a free software version of confd that can parse YANG, presents a D-Bus API, has a configuration mode, and speaks NETCONF and/or RESTCONF. Then we can start modifying existing daemons to use the new standard. Some kind of backward compatibility to parse and write existing conf files would probably be mandatory, though the whole point of the design is to move away from that.
Whatever you do… Please Stop Enabling!