A Sane Way to Manage Asterisk Configuration Files
How do you manage your Asterisk configuration files? There are so many of them with so many parameters, sections, and such. All too easy to fall into configuration management spaghetti hell. How do you differentiate default v. custom/override? How do you deactivate part of a configuration? This is really driving me insane in the membrane.Some Asterisk distributions came up with an alternate option using an include file in the form of sip_custom.conf or even sip_general_custom.conf for specific section override which is fine for solving part of the problem but far from ideal.
During this Christmas holidays, I’ve been working on implementing a Chef cookbook for Asterisk (which should be the subject of another post). At some point, my main problem was related to properly and cleanly manage configuration files. The basic idea involves a few configuration tricks offered within Asterisk configuration mechanism, namely, #include, #exec, and (+).
Partly inspired by Apache 2 configuration structure from Debian and friendly a2ensite/a2dissite scripts, I came up with the following /etc/asterisk directory structure:
The basic idea is to move all default configuration files into a available directory then enable specific ones on a case by case basis, linking the actual config within the enabled directory.
Yes. Yes. But how are the configurations loaded into asterisk now that the initial ones have been moved somewhere else. Once again, on a case by case basis, inclusion configuration files are created with a simple #exec instruction which provides dynamic #include statement. For instance, the following would be the content for sip.conf.
#exec /usr/bin/asterisk-load sip
where the actual configuration loader is
This script would simply look for enabled/sip.conf and enabled/sip/**/*.conf files to be dynamically loaded if present. Now, to deactivate a specific configuration, associated link within enabled directory should simply be moved to the disabled one.
In order to fulfill all promises, configuration override needs to be taken into account. While any configuration files can be enabled/disabled, some configuration key/value within a specific category/section may re-defined some from other configuration files, the idea is to rely on another configuration technique, namely, (+) attributions. For instance, given the following enabled/manager.conf file:
[general] enabled = no port = 5038 bindaddr = 0.0.0.0
we could be interested in activating the manager and define the following enabled/manager/activation.conf
[general](+) enabled = yes
which overrides the key/value has defined in the first configuration file. Sweet.
Now to wrap this rather long post, it would be nice to have a script to manage all this wizardry instead of doing manual typing which can get confusing. The following rake file provides a few tasks to handle enablement/disablement.
RAKEFILE=https://raw.github.com/gist/1542978/fc3f37e4a6417ef130a1cdaa587901c3f9bf005f/Rakefile curl $RAKEFILE > Rakefile; rake install rake enable[manager] rake enable[manager/activation] rake disable[manager/activation]