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:[EMAIL PROTECTED] +972-50-7952406 mailto:[EMAIL PROTECTED] http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
