[asterisk-users] RFC: multiple packages editing asterisk config files

[Tzafrir Cohen]

Hi

I'm lately bothered with the need to provide a set of Asterisk
configuration files in a package that will be good for a wide range of 
Asterisk users.

Asterisk configuration files support #include and a number of other
interesting tricks, as mentioned in
http://svn.digium.com/svn/asterisk/branches/1.4/doc/configuration.txt [0].


Let's start with manager.conf . 

Let's start with the simplest possible variant:

;;;;;;;;;;;;;;;;;;;;;;; manager.conf
[general]
enabled = yes
bindaddr = 127.0.0.1

; here come also a number of other remmed-out values for a human admin
; to edit
;webanbled = yes
;port = 5038 ; The default

#include manager.d/*.conf

; Here the human admin can add complete sections:
;[admin]
;secret = xxxxxx
;read = all
;write = all
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


Some Asterisk configuration interface (let's call our fictional one
astcfg) can then create:

/etc/asterisk/manager.d/astcfg.conf (which can also be a symlink to a
directory where astcfg can actually write[1])

;;;;;;;;;;;;;;;;;;;;;;;; /etc/asterisk/manager.d/astcfg.conf 
[general](+)
; Those settings don't necessarily make sense. They are here to
; demonstrate how configuration parsing works
bindaddr = 0.0.0.0
port = 3030

[astcfg]
secret = 209348
read =  all
write = all
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


Now for a more complicated example. sip.conf . sip.conf gives us a
little extra pain that most users have a matching 'register =>' entry.
But we already learned how to do that: an extra [general](+) section[2]. 

As we can clearly see, it is very simple to automatically add extra
sections and to add extra directives to sections. It is impossible to
cancel sections and to cancel directiver (or "reset to default" e.g: 
reset the "port" setting so that the port in "bindaddr" would take 
effect, or vice versa) directives. I wonder if this is an actual 
limitation, and if so: if there is a simple way to overcome it.


Problems:
1. voicemail.conf . It is accessed directly from oh so many places.
Teaching all of them to respect the cool asterisk configuration files
tricks (for rewriting!) is a futile attempt. Workarounds: update
password with an external script, and only use the existing Asterisk
interfaces to check for ovicemail authentication. Practical?


What other problems would such a method have?


[0] Note that this is a link to the file from 1.4. In 1.6 the file is in
    TeX format that is slightly less readable. Any simple way to
    reference directly to the relevant chapter from the generated Asterisk 
    Book?

[1] Preventing astcfg from write access to the Asterisk config files is
    not a real protection, because:
    1. If the use of '#exec' is enabled, the astcfg can force Asterisk
       to run some script of its choosing e.g. to edit other
       configuration files.
    2. If astcfg is allowed to manipulate the dialplan in any way (e.g.:
       originate calls, it still has complete control).

    This may, however, save the need to run apache as asterisk. 

[2] If there are too many of those, we should ask ourselves how to fit 
    those register lines into the peer entries in order to simplify the
    configuration parsing.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir