[asterisk-dev] action: getconfig, what about zaptel.conf?

[Tzafrir Cohen]

On Fri, Jun 15, 2007 at 12:04:55AM -0500, Brandon Kruse wrote:
> Hey devlist,
> 
> I have a question, of course, or else I would not be annoying you with this :/
> 
> So....action: getconfig will return me all the contents of a config file in /etc/asterisk/
> for me to parse in javascript, and update, delete, etc etc.
> 
> What about if I want to add/delete/and update entries from zaptel.conf?

When would you need to do that? Why would you need to do that from
Asterisk?

One concert here:

Let's assume that Asterisk does not run from root. ztcfg if often
normally run by the asterisk init.d script. Should it trust files
generated by the user asterisk?

> 
> I did a quick ln -sf /etc/zaptel.conf /etc/asterisk/zaptel.conf.
> 
> The problem is, since its not an "asterisk" config file, it does not have contexts
> that can be easily parsed and sent through manager. I end up getting a "file does not
> exist". I do not want to edit asterisk yet, because then we will have yet another revision
> of asterisk, that makes all previous versions not work with that feature of the GUI.
> ( We have enough of this as it is. )
> 
> If I add [default] at the top, or [contextwhatever], it works fine, and I can see
> all the options, and maybe even update and edit them for digital card support in the GUI.
> 
> Then of course, ztcfg, gets mad at the brackets ([]s) 

Why is it the job of Asterisk to parse those files?

Comments in ztcfg begin with '#'. So consider the following ztcfg:

# However another case to think of i what happen if we ever get to 
# include /etc/fstab

Not to mention #exec .

The two files have separate formats. Asterisk's code should not be
bloated with that.

You should also consider the possibility that this zaptel.conf
does not properly represent the system's hardware, and hence ztcfg would
fail.

> 
> I am kind of at a dead point, and I am open to suggestions, 2 cents, and whatever else you feel is relevant. 

Zaptel's code already has a bunch of perl classes to detect zaptel
hardware and loaded modules, under xpp/utils/zconf and a few sample
scripts under xpp/utils/

Take a look at zaptel_hardware and genconf from there. Theoretically
genconf is supposed to do everything genzaptelconf does only cleaner and
faster.

It is written in perl, but uses no external modules (right, except
strict and Getopts::Long) and hence will run fine with miniperl /
microperl which is common in embedded systems.

> 
> 
> The goal is to be able to edit zaptel.conf. Then people will be able 
> to configure all your zaptel.conf stuff from the GUI. 

We already know basically what each span is. Detecting analog spans is
quite easy, except the fact that Digium cards and others don't provide
enough information. My suggested workarounds:

 http://bugs.digium.com/view.php?id=7613 

   autocatically configure analog spans. Has the same hueristics as
   zapscan that is run automatically on zaptel startup, but does not
   require touching zaptel.conf . 
   Unlike zapscan, it can be overriden by editing zaptel.conf .

   It puts logic in kernelspace, but I fail to see a reason why that is
   not a sane default. Noone has yey commented on that.


 http://bugs.digium.com/view.php?id=9496

   Actually provide the little missing information (FXS or FXO?) for
   each channel in the procfs file.


The proper fix would probably be with sysfs.

So let's go look at the rest of the oarameters of the span line:

With digital spans we know the span number and the number of channels.
So we know if it is T1 or E1 (or BRI). 

All the BRIs I ran into so far had framing/coding ccs,ami . But maybe 
this is european.

E1s and T1s seem to be slightly more direrve but from my (*very
limited*) experince genzaptelconf had quite a good chances ate guessing
them.

LBO: anybody actually gets to change it?




For instance: we can know if a span is E1, T1 or BRI by counting the
number of channels (hmmm... this is what Asterisk does today,
basically). 

Channel numbers are better be handled as automatically as possible, as
those give the users a big rope to hang themselves with.



> Also do cool stuff like monitor alarms on spans, and remote setup, etc etc. ( not that you
> could not do this with other tools before, but still, throw me a bone. )

Asterisk already knows about spans.

On a similar note, please see
http://bugs.digium.com/view.php?id=9503
because some people will eventually want to edit zapata.conf. And the
one you currently have will require too many hacs from the user
interdface (genzaptelconf adds a "reset" for any value it sets due to
this awkwards semantics).

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