[Asterisk-Users] Extensions.conf sugestion?

[John Todd]

Mark says you can include other configuration files from within 
extensions.conf with #include.  Take a look at the bottom of this 
message for the forwarded note.  It does work; I currently use it. 
Note that the statement must look like this:

#include filename

There is no "=>" like with other entries in the config file.

Just a side note: this is an extremely powerful feature, and I think 
it's probably under-used by most administrators.  The ability to 
split the config file out into multiple sub-files makes for a much 
more sane method of managing larger installations, especially with 
automated configuration tools.

JT


>In automating things with *, I've hit this a few times myself.
>
>I typically solved it with headers like
>
>; ###START OF MY STUFF###
>stuff
>stuff
>stuff
>; ###END OF MY STUFF###
>
>Then I just throw away that chunk and regenerate from scratch (from my
>other data source, typically a custom configuration file from a custom
>script).
>
>One question, is there a way to include one file from another in our
>config files?  That would be really useful--especially for having a
>script generate certain settings.  There's nothing like just blowing
>away a completely generated file with a new completely generated file.
>Includes would allow that without touching the rest of the
>configuration.  Not to mention that extensions.conf can get really long
>and that would seriously help manage it.
>
>Right now, I use a number of python-based scripts to synchronize my naming
>conventions between voicemail.conf, extensions.conf, and zapata.conf
>(peoples names matching their extensions).  Includes would make them
>*MUCH* simpler.  Ironically, I actually keep a number of my * files in
>RCS because keeping track of the changes has been so painful.  Being
>able to separate things out into files would really help there.
>Otherwise, I think the configuration syntax will become a serious
>problem when we start getting to sizes that compete with the big boys
>(10,000 extensions over multiple servers).
>
>Jayson




>From: Mark Spencer <markster at digium.com>
>To: <asterisk-dev at lists.digium.com>
>Subject: Re: [Asterisk-Dev] Feature request: reading in parts of config files
>  via URI
>Reply-To: asterisk-dev at lists.digium.com
>Date: Tue, 15 Apr 2003 08:04:18 -0500 (CDT)
>
>I believe you can use "#include" statements in asteirsk config files.
>
>Mark
>
>On Mon, 14 Apr 2003, John Todd wrote:
>
>  >
>  >
>>  I was working with some global configurations today, and was
>>  wondering how difficult it would be to include the contents of files
>>  (or, heck, URLs) to set variables or extensions.  I am pretty sure
>>  that using the prefix of "local =>" is a bad idea, so I substituted
>>  "read =>" instead.  It might even be possible that extension logic
>>  could be read in via the same method, so perhaps using "include =>"
>>  is not so outrageous if this gets expanded in concept...
>>
>>  In other words, something like these two examples:
>>
>>
>>  [global]
>>  read => file:/etc/asterisk/sitespecific/stuff
>>  .
>>  .
>>  .
>>
>>  [default]
>>  read => http://www.mybigfatserver/companystuff.txt
>>  .
>>  .
>>  .
>>
>>
>>  where /etc/asterisk/sitespecific/stuff looks like this:
>>
>>  PHONE1=SIP/9393
>>  PHONE2=SIP/3111
>>  OUTSIDELINE1=Zap/1
>>  OUTSIDELINE2=Zap/2
>>  ANALOG911=Zap/1
>>
>>
>>
>>  and where  http://www.mybigfatserver/companystuff.txt looks like this:
>>
>>
>>  1234 => _1.,1,Dial(Zap/1,${EXTEN})
>>  1234 => _1.,2,Hangup
>>
>>
>>  In the first example, we're simply reading in global variable names
>>  which might be site specific.  This would help a lot for
>>  configuration files that are the same between individual offices as
>>  far as their logic goes, but there might be different settings for
>>  each specific site as far as variables go.
>>
>>  The second example includes a small snippet of actual dial plan
>>  pulled in from the URL (or file, or whatever) specified.  This would
>>  allow some central admin to change and keep dial plans between
>>  multiple offices in one repository.  Even using IAX, you still need
>  > to go twiddle each server remotely.  Perhaps this is just a more
>>  centralized way of administering Asterisk servers, but I'm already
>>  running into the "ten million ssh sessions" clutter when doing three
>>  or four way configuration changes.
>>
>>
>>  PS: A side note on this would be an application that could be called
>>  to reload Asterisk's dial plan.  In that way, a central administrator
>>  could cause reloads simply by dialing a number. This is potentially a
>>  very dangerous tool, but probably pretty useful.
>>
>  > JT
>>