[asterisk-users] Which installation policy is behind Asterisk doc delivered with source code ?

[Tzafrir Cohen]

On Tue, Dec 02, 2008 at 11:17:11AM +0100, Olivier wrote:
> 2008/12/2 Tzafrir Cohen <tzafrir.cohen at xorcom.com>
> 
> > On Tue, Dec 02, 2008 at 08:30:34AM +0100, Olivier wrote:
> > > Hi,
> > >
> > > Testing latest 1.6.1, it occurred to me I had to add a couple of noload
> > > statements in /etc/asterisk/modules.conf to remove ERROR messages, when
> > > starting Asterisk.
> > > (I don't imply those ERROR messages were fatal to Asterisk but as a
> > general
> > > rule, I tried to start Asterisk without any of those).
> >
> > Could you be specific? I think that some messages may be
> > wrongly-labeled.
> 
> 
> >From memory, I had  for instance "Failed to open /dev/dahdi/transcode: No
> such file or directory" on pure-IP platform in which I installed
> asterisk-libpri-dahdi trilogy.

/dev/dahdi/transcode should only be required for codec_dahdi.so . Most
people don't need it and would be annoyed by the warning[0]

> 
> Maybe, it's me while following README instructions, maybe README
> instructions could be improved or maybe it's wrongly labeled messages ?
> That's why I told myself : I'm waiting too much from doc ? is a pure-IP
> platform too specific ? what is the official policy ?
> 
> README starts with "check hardware compliance".
> So maybe, the policy is to have a "somehow functional system with any of
> mentioned compliant hardware, with all enhancements such as running as
> non-root, set apart".

> 
> 
> 
> >
> > >
> > > As I'm not very familiar with module concepts at the moment, I told myself
> > > it would be helpful, if strictly following instructions included in README
> > > files, I did get a system that starts without any ERROR message of any kind
> > > and still could provide some basic telephony services.
> > >
> > > So my question is :
> > > - is there a policy fixing the target of README files ?

Yes, please submit fixes.

> > > - for example, if someone installs Asterisk (according README files) on a
> > > platform equipped with a Digium analog board, should this board be
> > > automatically discovered, configured and ready to run ?
> >
> > Not yet:
> >
> > # which modules to load: a temporary workaround
> 
> 
> That's the point : if optimizing modules load could be postponed to a later
> stage, that would be better, IMHO, as installing from source is already a
> long process.

"modules" here referes to DAHDI (kernel) modules rather than Asterisk
ones. It refers to an inherent limitation of Zaptel/DAHDI - the order of
hardware discovery sets the order of channels. However fixing this is
not trivial to say the least. So let's leave it aside for now. It's not
really something you care about if you just have a single card, anyway
:-)

> 
> >
> > # dahdi_modules is a simple two-liner scrippt that is currently not
> > # installed by default. I figure I should get that functionality added
> > # to dahdi_genconf
> > dahdi_modules >/etc/dahdi/modules
> > /etc/init.d/dahdi start
> > # generate /etc/dahdi/system.conf and /etc/asterisk/dahdi-channels.conf
> > dahdi_genconf
> > dahdi_cfg
> >
> > # edit chan_dahdi.conf accordingly. e.g.:
> > echo '#include dahdi-channels.conf' >>/etc/asterisk/chan_dahdi.conf
> >
> > # apply changes: start/restart asterisk, or:
> > asterisk -rx 'dahdi restart'
> 
> 
> IMHO, setting a policy would help to guide efforts of many people involved.
> That done, maybe we would conclude an interactive script would be the
> missing piece to incorporate user choices that are hard to default to.

The above procedure is not a policy. 

The fact that a configuration can be generaed automatically without
manual fine tuning indicates to me that it should be. Currently I'm
looking into ways of doing so (and still allowing simple manual
overrides). I hope that generally running dahdi_cfg on each span
separately on each span at post-registration would do the trick, but
this still takes exposing information through sysfs or whatever.

As a side note, I would rather avoid interactive setup scripts as they 
tend to be complicated to automate and force you to keep feeding the 
same selections again and again. Sangoma's setup script is, IMHO, an 
example of an interactive script that requires an expert, and takes a 
heaps of screen space. Not to mention changes a half the system to fit 
its grand plan.

[0] Either actively annoyed by it, or learn to ignore it, and hence
later on ignore a warning / error you should have read.

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