Daniel-Constantin Mierla wrote: Do you mean just editing the text of the config? Or do you mean editing the config in some high-level way? You probably mean the former, but if by chance you mean the latter, I personally would recommend staying away from this. It seems like it would be an unmanageable mess. The problem is that Kamailio is far too polymorphic and extensible, and there are as many ways to write a configuration as there are to skin a cat. Everyone's configuration file is going to have different attributes, except in the respects in which they all must be common of course. But the applications vary immensely; the config route script is part of what makes the system such a powerful building block of SIP telephony applications and platforms. This means you have to build and maintain another another parser and lexer or hijack the existing one. Either way it would have to be outboard and feed data into the PHP application as Bison/flex/friends don't output PHP parsers. Then, you are still left with the challenge of interpreting the many thousands of permutations of configuration that come out of the parser in various data structures, although you are assisted here by the relative rigidity of the route script syntax in contrast to, say, Perl. The other alternative would be to take the approach of many web front-ends to complicated things; have SIREMIS generate the configuration out of a template, and produce a result that is rich with meta-data. This means it is not especially feasible to edit it manually afterward; you must use SIREMIS for all aspects of configuration, else you break the meta-data and SIREMIS won't understand the configuration anymore. That in turn means you are now limited in capabilities to merely the set of common things SIREMIS supports. That is clearly a bad idea that is anathema to the very essence of the purpose of the route script. -- Alex -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775

On Friday 13 February 2009, Daniel-Constantin Mierla wrote: Hi Daniel, seconding Alex reply, this is also something i'd not recommend. I don't think that allowing the webserver account to access my logfiles is a good idea. If i choose to also write accounting logs, it could even read them. This is sensitive data, where a security breach would be not nice. And also i don't think that forcing the user to install a webserver with PHP on their production system is a good move. There are also existing system management packages that have this functionality, one well known is webmin, which provides a module for this: http://doxfer.com/Webmin/SystemLogs Cheers, Henning

On Fri, February 13, 2009 10:21 pm, Daniel-Constantin Mierla wrote: PHP >> on their production system is a good move. Hi Daniel, i belong probably not really in the target user group of this application, please bear with me.. ;-) I thought a bit longer about this, given the fact that this interface already communicate with some FIFO commands with the kamailio system, the additional security risk is probably not that a big problem. And if its configurable i've no issue with it. One thing that would certainly make sense would be to highlight certain log file content, filter or count certain errors classes. Like this: -> server foo has 123 logs with status ERROR or higher in the last hour -> click here to see all that are labeled CRITICAL.. -> server bar has 53 log entries, click here for a module summary.. (would display a list with errors belonging to the core and modules) As our log format at least in this areas is stable, this would be work ok. Trying to match individual log statements would be probably not really work, as this changes more often over time, and we also don't really have clear defined rules for log statements. Cheers, Henning