4 thoughts on - how to add-edit-delete entery into asterisk conf files

  • Hi,

    I know that by using vi editor we can edit all the Linux files but I want to
    use Php. So that from web page anyone can make some account into asterisk
    server.

    But thanks for your reply. And i have completed that task yesterday after
    sending e-mail.

  • [lots of fputs]

    Have you actually tried reading from the socket to see what the results
    are for your commands (hint: turn off events)?

    This is what I get:
    Response: Success
    ActionID: 9873497149817

    Looking at
    http://www.voip-info.org/wiki/view/Asterisk+Manager+API+Action+UpdateConfig
    it is clear that adding values to a category works different than you
    expected.

    First you need to create the new category (your scripts does that
    already), then you need to append lines to is in the form of appends to
    the category like in the example on voip-info.org:

    action:updateconfig
    reload:yes
    srcfilename:manager.conf
    dstfilename:manager.conf
    Action-000000:append
    Cat-000000:newuser
    Var-000000:secret
    Value-000000:nottelling

  • You’re not really editing. You’re writing.

    Note the following:

    * It requires Asterisk to be running, and accessible through the manager
    interface.
    * asterisk.conf may be in a path that is not the configuration
    directory. I’m not sure if this special case is handled.
    * #include are basically handled, but mostly for reading. IIRC the write
    is back to a single file. No idea about #exec, which will probably
    have odd interactions with UpdateConfig. Configuration templates
    (‘[section](template)’) are also not handled gracefully.

    This is a report of the the thing that did not happen. Next time you ask
    a question, please report what actually does happen (“I got the following
    response: …”).

  • 1- Per my experience I’ve used DB with configuration files and I was amazed
    that Asterisk was taking a union of DB + conf file configurations and
    accepting both.So if you just make a simple script or DB function to do file
    operation on some event/cronjob you’ll be saved.

    Moreover, if that still may induce duplication into configurations then DB
    replication and redundancy is the best way to cater your failure case. There
    are hundreds of how-tos on DB redundancy and failure etc.

    2- If you’ve to move forward with this approach I’ll suggest you to read
    only part of configuration file corresponding to one user i.e [user-1-area]
    and over-write that part only. If a new user then just append. This way file
    data loss will be minimized(may even avoided totally).

    Those were all my suggestions, if anyone else can add valuable comments to
    this.


    sammy