Hi,
it seems that meeting at FOSDEM brought lot of ideas around.
Stefan already had a good suggestion - integration of SIREMIS with SEMS giving the possibility to monitor SEMS servers in the same nice manner from a web page.
I would like to collect suggestions about what would be good to have in SIREMIS, what should be improved.
My goal up to Kamailio 1.5 release is to add support for carrierroute, a cdr rating engine and cleanup the source tree in order to upload the sourceforge svn - this would make easier for others to contribute. However, if it is something we find very useful then I will prioritize. There is time to add new features after the release, as well.
Please shoot here any crazy idea you have for a web management interface of Kamailio and later SIP Router.
Regards, Ramona
Hello,
although we have discussed internally at asipto, I want to see opinions from others related to ability of displaying (eventually editing) config file in siremis.
Would this be a security risk (e.g., contains database credentials)? it could be pretty useful to check config content without doing ssh.
This brings another idea, displaying parts of different files that are listed in configuration file of siremis. For example a tail over syslog file. The drawback for these extensions is the limitation of having siremis installed on same server or another communication way which means providing login access ...
Cheers, Daniel
On 02/12/2009 11:15 PM, Elena-Ramona Modroiu wrote:
Hi,
it seems that meeting at FOSDEM brought lot of ideas around.
Stefan already had a good suggestion - integration of SIREMIS with SEMS giving the possibility to monitor SEMS servers in the same nice manner from a web page.
I would like to collect suggestions about what would be good to have in SIREMIS, what should be improved.
My goal up to Kamailio 1.5 release is to add support for carrierroute, a cdr rating engine and cleanup the source tree in order to upload the sourceforge svn - this would make easier for others to contribute. However, if it is something we find very useful then I will prioritize. There is time to add new features after the release, as well.
Please shoot here any crazy idea you have for a web management interface of Kamailio and later SIP Router.
Regards, Ramona
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Daniel-Constantin Mierla wrote:
although we have discussed internally at asipto, I want to see opinions from others related to ability of displaying (eventually editing) config file in siremis.
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
On 02/13/2009 07:59 PM, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
although we have discussed internally at asipto, I want to see opinions from others related to ability of displaying (eventually editing) config file in siremis.
Do you mean just editing the text of the config? Or do you mean editing the config in some high-level way?
simply editing, like we all usually do with vi/vim.
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.
I do mean former and I really would stay away from the second. It is just about simple text presentation of the config, eventually editing it as text instead of ssh+vim.
Cheers, Daniel
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
On Friday 13 February 2009, Daniel-Constantin Mierla wrote:
This brings another idea, displaying parts of different files that are listed in configuration file of siremis. For example a tail over syslog file. The drawback for these extensions is the limitation of having siremis installed on same server or another communication way which means providing login access ...
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
Hello Henning,
On 02/13/2009 08:14 PM, Henning Westerholt wrote:
On Friday 13 February 2009, Daniel-Constantin Mierla wrote:
This brings another idea, displaying parts of different files that are listed in configuration file of siremis. For example a tail over syslog file. The drawback for these extensions is the limitation of having siremis installed on same server or another communication way which means providing login access ...
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.
it would be a matter of configuration. It is about deciding if someone finds it useful.
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.
Again, it is not a forcing. It can be turned on/off.
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
Right, I was thinking to something simpler...
Cheers, Daniel
On Fri, February 13, 2009 10:21 pm, Daniel-Constantin Mierla wrote:
This brings another idea, displaying parts of different files that are listed in configuration file of siremis. For example a tail over syslog file. The drawback for these extensions is the limitation of having siremis installed on same server or another communication way which means providing login access ...
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.
it would be a matter of configuration. It is about deciding if someone finds it useful.
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.
Again, it is not a forcing. It can be turned on/off.
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
Hello Henning,
On 02/14/2009 04:41 PM, Henning Westerholt wrote:
On Fri, February 13, 2009 10:21 pm, Daniel-Constantin Mierla wrote:
This brings another idea, displaying parts of different files that are listed in configuration file of siremis. For example a tail over syslog file. The drawback for these extensions is the limitation of having siremis installed on same server or another communication way which means providing login access ...
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.
it would be a matter of configuration. It is about deciding if someone finds it useful.
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.
Again, it is not a forcing. It can be turned on/off.
Hi Daniel,
i belong probably not really in the target user group of this application, please bear with me.. ;-)
don't worry, proper discussions bring the right solutions...
I thought a bit longer about this, given the fact that this interface already communicate with some FIFO
It uses UDP for two reasons: - to be able to communicate with sip server hosted on a different machine - xmlrpc c library gives kicks quite often
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.
siremis is admin management interface, it should be all the time accessed over HTTPS/TLS, and preferably via a private network.
One thing that would certainly make sense would be to highlight certain log file content, filter or count certain errors classes.
Good idea -- a filtering on a given regexp would be nice as well.
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.
Anyhow, looks like a bit of work, so probably will be after the kamailio 1.5.0 release...
Thanks for input, Daniel
-
Alex Balashov -
Daniel-Constantin Mierla -
Elena-Ramona Modroiu -
Henning Westerholt