[asterisk-dev] handling system commands in AMI

[Nánássy Dániel]

2009/6/5 Philipp Kempgen <philipp.kempgen at amooma.de>

> Tzafrir Cohen schrieb:
> > On Fri, Jun 05, 2009 at 06:50:05PM +0200, Philipp Kempgen wrote:
> >> Tzafrir Cohen schrieb:
> >
> >> > Specifically: '!' or '!command' in 'asterisk -r' shell runs a local
> >> > shell rather than a shell on the remote Asterisk process. It's not
> >> > something that should even go over the wire.
> >>
> >> > So you can just as well implement this on the remote side without
> >> > touching Asterisk's code :-)
> >>
> >> In what scenario would I want to use "!" then?
> >
> > If you're in a asteriskr shell and have no other terminal to run a
> > command in.
>
> I see. That makes sense.
>
>
>    Philipp Kempgen
>
 Thank you for the answers but unfortunately not everything is clear.
The originate issues the same with id -a:

[wait]
exten => _X.,1, Answer()
exten => _X.,n, Wait(${exten})

Action: Originate\r\n
Channel: Local/100 at wait\r\n
Application: system\r\n
Data: id -a > /tmp/originate.txt\r\n\r\n

originate.txt:
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

Let me tell what was the purpose writing this patch.
The business requirement is to encode the recorded files in vorbis and then
report the encoded file sizes.
Everything is controlled on the remote side which is a Windows service. I
use the originate AMI command (Action: originate\r\nChannel:
Local/100 at wait\r\nApplication: system\r\nData: <my script> <params>\r\n\r\n)
and the script stores the file sizes in astdb which is accessible and
removable on the remote side.
This method is a bit complicated. It would be easier to do it in one commad:

Action: Command\r\nCommand:!<my script> <params>\r\n\r\n
Response: Follows\r\n<output of the exectued command>--END COMMAND--\r\n\r\n

So I do not understand the security concerns, but there is a problem with
this approach: it blocks the manager during the scripts executes.
Could it make sense if the answer would be asyncronous (or maybe the
origniting is the best solution and amending this patch further is waste of
time)?

An other thing to this. I do not trust in astdb too much. I sometimes read
strange entries from the db at heavy load. These entries are fractions of
other db entries.
Did anyone experinece the same?

Thanks,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20090609/738bde75/attachment.htm