[asterisk-dev] minimal default configuration

Sun Nov 25 00:13:52 CST 2007

On Sun, Nov 25, 2007 at 01:43:30AM +0100, Michiel van Baak wrote:
> On 20:29, Sat 24 Nov 07, Tzafrir Cohen wrote:
> > The subdirectory configs/ of asterisk contains well-annotated and
> > detailed configuration files. Those files are installed as 'sample'
> > configuration files (the separate installation target 'make samples').
> > Thus they serve both the purpose of reference and example.
> > 
> > There's an annoying behaviour I occasionally run into with respect to
> > the Asterisk configuration files in Debian packages. But please bear
> > with me, as I'll explain later why I think it indicates a more generic
> > problem.
> > 
> > With Debian packaging there's special handling of configuration files
> > (basically: files under /etc ). Those files are generally not to be
> > automatically updated if the user has edited them. If the user has, dpkg
> > will ask the user what to do (get the new version? keep the modified
> > one? fix things manually?)
> > 
> > The asterisk package (actually a separate sub-package, asterisk-config,
> > but this is for unrelated technical reasons) thus has some 67 files
> > under /etc/asterisk/ . If a user just installs asterisk and doesn't
> > need to change any of those: no problem - an upgrade will go smoothly.
> > But if the user has actually changed anything, then on an upgrade he has
> > extra work.
> > 
> > So an upgrade of the asterisk-config (even if this is due to a small
> > change that has not really changed the behaviour  of the relevant
> > module) becomes a pain. 
> > 
> > And then again: some users want to just start from scratch, without the
> > many samples. And thus they have to actively delete our files.
> > 
> > 
> > So what happens for those users who don't like debs? 
> > With a typical installation you'd just run 'make samples' once at
> > initial install and hope to have a sane defaults. 
> > 
> > And then what happens if you upgrade Asterisk and the file in configs/
> > changes? The file under /etc/asterisk would still be the old, unfixed,
> > copy. 
> > 
> > 
> > And then the files themselves are quite detailed. They also set quite a
> > few values, and thus make then a sort of "de-facto defaults". And by
> > that they are confusing as reference. Two examples for that:
> > 
> > asterisk.conf is sets all the values under [directories] even though
> > there's no need to set them. That file is generated to reflect the
> > default build settings. Thus there is no need to set any value in
> > the [directoies] section to get the required result.
> > 
> > So the file asterisk.conf installed by default will confuse me if I want
> > to write one from scratch.
> > 
> > (BTW: the other sectoins in asterisk.conf are indeed well-written. At
> > least the version in trunk)
> > 
> > Do you think that indeed default values should generally not be enabled
> > in the sample configuration files? 
> > 
> > 
> > 
> > The [modules] section in modules.conf includes "autoload=yes". I ofen
> > wonder why this is not the default: if you don't want to load modules
> > automatically, you'll need to take the time to handcraft the list of
> > modules in modules.conf anyway. Adding "autoload=no" there is no
> > problem.
> > 
> > Such a case (sample value differs from the default) is a source for
> > support issues: what exactly is the "default"? If someone wrote that
> > file from scratch, did he forget that?
> > 
> > Changing the default to a value is naturally not something to be taken
> > lightly. I wonder what other configuration values in Asterisk have
> > incorrect defaults.
> > 
> > 
> > And then there are some cases where too many things are installed. Why
> > do we need both extensions.conf and extensions.ael installed? Assuming
> > that both pbx_config.so and pbx_ael.so are installed (which is the
> > default) both will be installed and the result is a confusing dialplan.
> > 
> > 
> > So I'd like to get to a situation where Asterisk is as functional as
> > possible with the minimal ammount of configuration files, rather than
> > rely on the sample config files.
> > 
> 
> All them configuration files will only be installed if you
> manually run 'make samples'
> I think you should do the same with the debian package. Make
> it optional. Dont let asterisk or asterisk-addons or
> whatever package depend on it.

But then I install asterisk and it will not work.

This is because some modules fail to load. Or because chan_alsa /
chan_oss (who ever got there first) hogs on my sound card and won't
release it. Or whatever.

> 
> Yes, I'm a big OpenBSD fan, I know, but hear me out.
> For this same reason OpenBSD upgrades dont install the
> etc<version>.tgz
> the etc<version>.tgz tarball has the default configs for
> that version, and during an upgrade you cannot select the
> etc tarball to be installed. They do notify you to compare
> the stuff by hand and they also give a list of files you
> probably can copy verbatim and a list of files you most
> probably edited to reflect your install.

As I mentioned before, that strategy will lead you to have an obsolete
sample files under /etc/asterisk/ . That policy is practically the same
except you thift the whole burder to the user. The problem remains the
same.

> 
> I think this is the way to go for packages.
> The asterisk source install is very nice as it requires an
> extra step before you overwrite your configs.

But again, this eventually leaves you with obsolete configs under
/etc/asterisk . Because noone should run 'make samples' on a system that
has already been configured.

Again, you're ignoring the problem.

> Specially because every howto/source/install refers to
> UPGRADE.txt so you can look there what you need to change.
> (yes, this is even doable for 1.0->1.4 upgrades, I just did
> that last friday on a couple of production boxen)

I also refer to updates between versions in the stable branch.

-- 
               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