Re: [asterisk-dev] Fwd: Code Review request of func_redis module
The part of the internal API that I used haven't changed from 11 to 13 so it should work without any problem. But I haven't tested the module intensively and I'm not sure if it is thread safe, so I don't recommend use it in production servers right now. Today I'm gonna install the module in an asterisk 11 active-passive cluster of preproduction to test it better, after that I will expose my conclusions here, if some one that have more experience developing in asterisk can look at the code and confirm that it is thread safe i will be very grateful. 2015-05-11 21:22 GMT+01:00 Ludovic Gasc gml...@gmail.com: Hi, Your library is very interesting, because we already use Redis as a cache for some stuffs. For now, I've made a FastAGI server to serve Redis data, but it should be faster to read Redis data directly. Do you think I could test your module on an Asterisk 13, or the Asterisk internal API is too different to be used with another version than 11 ? Regards. Ludovic Gasc (GMLudo) http://www.gmludo.eu/ On 11 May 2015 09:14, GESTION DE TELEFONIA IP gest...@ull.edu.es wrote: Hi all, I have developed an asterisk module to interact with redis from the dialplan, the project is motivated by the need to share information between different asterisk in both active-active and active-passive scheme, in an easy way like AstDB. You can use an agi script or a system call to a script to use redis from the dialplan but the performance is low compared to a asterisk module and the integration is worst. I think that maybe this module can be interesting to the community, It's the first time that I develop a asterisk module so If some one can make a code review to the module to see if there are use of insecure functions or something that can crash asterisk, I will be very grateful, the module is under GPLv2 License in this repo https://github.com/tic-ull/func_redis. At the moment the module is shipped outside the asterisk project, as a Cmake project. You can see the instructions to install and to use it in the README.md of the repo. The english isn't my native language so sorry if there ara some writing mistakes. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
On Tue, May 12, 2015 at 10:39:04AM -0600, George Joseph wrote: On Tue, May 12, 2015 at 10:08 AM, Jeffrey Ollie j...@ocjtech.us wrote: On Tue, May 12, 2015 at 9:47 AM, George Joseph george.jos...@fairview5.com wrote: On Tue, May 12, 2015 at 5:41 AM, Tzafrir Cohen tzafrir.co...@xorcom.com wrote: On Mon, May 11, 2015 at 01:29:04PM -0600, George Joseph wrote: As for the other issues, why not just have asterisk fork itself on startup and reloads just to send the stats. No separate executables, no AMI, no cron, and you get the process separation so a segv or orthe rerror doesn't kill the main process. KISS! This makes it part of the asterisk service, as far as systemd is concerned. Is that a bad thing? Did I miss something in the email chain? I wouldn't call it a bad thing, it's just an implementation choice that has its pluses and minuses. If the main Asterisk process forks a copy of itself systemd will track the subprocess and kill it off when shutting down the main service. However, you then need to add to Asterisk code to keep track of the subprocess, reap the process if the subprocess dies and restart the subprocess. You'd still need some sort of remote API for the subprocess to gather the statistics from the main process, but it wouldn't have to be stable, even between minor releases, because each side would always be running the same code.. Personally, I'd go with an external process that's a separate binary (or could even be written in a scripting language) that talks to an API presented by Asterisk. The stats API would need to be a little more stable, but that wouldn't be a bad thing either. Hmmm. It just seems to me we're way over thinking this. Separate executables and a public APIs seems overkill for something that on;y needs to run for a few seconds on startup and reload. Why does it only need to run on startup and reload? Shouldn't it send stats periodically? -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
On Tue, May 12, 2015 at 11:39 AM, George Joseph george.jos...@fairview5.com wrote: Hmmm. It just seems to me we're way over thinking this. Separate executables and a public APIs seems overkill for something that on;y needs to run for a few seconds on startup and reload. Hmm, yes, I guess that I had read into some of the other messages a need/want for ongoing runtime statistics. -- Jeff Ollie -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
On Tue, May 12, 2015 at 11:15:40AM -0600, George Joseph wrote: The only volatile stats to be reported were active/total calls and I'd be willing to give that up to keep the process simple. Even if we did keep the calls, and it reported a few times a day I still don't see the need for the complexity. I don't want to have to set up cron jobs and worry about extra services or have to go through exposing new APIs. In the time we've been discussing this, a basic module that does what we needed could have been written. The API: asterisk stats dump [noreset] By default the stats will be collected (unless disabled at build time) - the overhead for collecting them seems small enough (right?). However as long as they are not dumped, nothing is reported to the Big Brother. Dumps current stats (to standard output) and resets counters. Setting up a cron job is simple. And this removes complexity from the Asterisk process. It also removes unnecessary network connectivity from the Asterisk process, and simplifies settings of whatever network settings. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
On Tue, May 12, 2015 at 10:08 AM, Jeffrey Ollie j...@ocjtech.us wrote: On Tue, May 12, 2015 at 9:47 AM, George Joseph george.jos...@fairview5.com wrote: On Tue, May 12, 2015 at 5:41 AM, Tzafrir Cohen tzafrir.co...@xorcom.com wrote: On Mon, May 11, 2015 at 01:29:04PM -0600, George Joseph wrote: As for the other issues, why not just have asterisk fork itself on startup and reloads just to send the stats. No separate executables, no AMI, no cron, and you get the process separation so a segv or orthe rerror doesn't kill the main process. KISS! This makes it part of the asterisk service, as far as systemd is concerned. Is that a bad thing? Did I miss something in the email chain? I wouldn't call it a bad thing, it's just an implementation choice that has its pluses and minuses. If the main Asterisk process forks a copy of itself systemd will track the subprocess and kill it off when shutting down the main service. However, you then need to add to Asterisk code to keep track of the subprocess, reap the process if the subprocess dies and restart the subprocess. You'd still need some sort of remote API for the subprocess to gather the statistics from the main process, but it wouldn't have to be stable, even between minor releases, because each side would always be running the same code.. Personally, I'd go with an external process that's a separate binary (or could even be written in a scripting language) that talks to an API presented by Asterisk. The stats API would need to be a little more stable, but that wouldn't be a bad thing either. Hmmm. It just seems to me we're way over thinking this. Separate executables and a public APIs seems overkill for something that on;y needs to run for a few seconds on startup and reload. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
On Tue, May 12, 2015 at 10:59 AM, Tzafrir Cohen tzafrir.co...@xorcom.com wrote: On Tue, May 12, 2015 at 10:39:04AM -0600, George Joseph wrote: On Tue, May 12, 2015 at 10:08 AM, Jeffrey Ollie j...@ocjtech.us wrote: On Tue, May 12, 2015 at 9:47 AM, George Joseph george.jos...@fairview5.com wrote: On Tue, May 12, 2015 at 5:41 AM, Tzafrir Cohen tzafrir.co...@xorcom.com wrote: On Mon, May 11, 2015 at 01:29:04PM -0600, George Joseph wrote: As for the other issues, why not just have asterisk fork itself on startup and reloads just to send the stats. No separate executables, no AMI, no cron, and you get the process separation so a segv or orthe rerror doesn't kill the main process. KISS! This makes it part of the asterisk service, as far as systemd is concerned. Is that a bad thing? Did I miss something in the email chain? I wouldn't call it a bad thing, it's just an implementation choice that has its pluses and minuses. If the main Asterisk process forks a copy of itself systemd will track the subprocess and kill it off when shutting down the main service. However, you then need to add to Asterisk code to keep track of the subprocess, reap the process if the subprocess dies and restart the subprocess. You'd still need some sort of remote API for the subprocess to gather the statistics from the main process, but it wouldn't have to be stable, even between minor releases, because each side would always be running the same code.. Personally, I'd go with an external process that's a separate binary (or could even be written in a scripting language) that talks to an API presented by Asterisk. The stats API would need to be a little more stable, but that wouldn't be a bad thing either. Hmmm. It just seems to me we're way over thinking this. Separate executables and a public APIs seems overkill for something that on;y needs to run for a few seconds on startup and reload. Why does it only need to run on startup and reload? Shouldn't it send stats periodically? The only volatile stats to be reported were active/total calls and I'd be willing to give that up to keep the process simple. Even if we did keep the calls, and it reported a few times a day I still don't see the need for the complexity. I don't want to have to set up cron jobs and worry about extra services or have to go through exposing new APIs. In the time we've been discussing this, a basic module that does what we needed could have been written. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
On Tue, May 12, 2015 at 9:47 AM, George Joseph george.jos...@fairview5.com wrote: On Tue, May 12, 2015 at 5:41 AM, Tzafrir Cohen tzafrir.co...@xorcom.com wrote: On Mon, May 11, 2015 at 01:29:04PM -0600, George Joseph wrote: As for the other issues, why not just have asterisk fork itself on startup and reloads just to send the stats. No separate executables, no AMI, no cron, and you get the process separation so a segv or orthe rerror doesn't kill the main process. KISS! This makes it part of the asterisk service, as far as systemd is concerned. Is that a bad thing? Did I miss something in the email chain? I wouldn't call it a bad thing, it's just an implementation choice that has its pluses and minuses. If the main Asterisk process forks a copy of itself systemd will track the subprocess and kill it off when shutting down the main service. However, you then need to add to Asterisk code to keep track of the subprocess, reap the process if the subprocess dies and restart the subprocess. You'd still need some sort of remote API for the subprocess to gather the statistics from the main process, but it wouldn't have to be stable, even between minor releases, because each side would always be running the same code.. Personally, I'd go with an external process that's a separate binary (or could even be written in a scripting language) that talks to an API presented by Asterisk. The stats API would need to be a little more stable, but that wouldn't be a bad thing either. -- Jeff Ollie -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
Correction: as one will end up getting a new ID (the second one to reuse the same token). On Tue, May 12, 2015 at 1:24 PM, Scott Griepentrog sgriepent...@digium.com wrote: So as opposed to spoofing, there is also the case that someone having a copy of Asteirsk in a virtual machine clones it, and ends up with two instances reporting the same random ID. With the spoofing detection mechanism (using tokens to get an ID from the server), the effect of this case is minimized as each one will end up getting a new ID after token timeout. On Tue, May 12, 2015 at 12:59 PM, Tzafrir Cohen tzafrir.co...@xorcom.com wrote: Quoting the spec: | Spoofing | | In order to limit spoofing, the server will return a token for all | accepted requests to a server. Any subsequent requests to that resource | must present the token in the request. If a subsequent request fails to | provide the token, the request is rejected. Tokens expire after 48 | hours, at which point, a request does not have to provide a token. If a | request does provide a token that is expired - and no token is required | at that point - the request should be accepted and a new token granted. | Once a request is made without a token (and no token is expected), a new | token is issued for subsequent requests. | | So long as Asterisk's transmission of data occurs faster than once every | 48 hours, a malicious entity will not be able to spoof a resource. If a | system is down then a remote system can 'take over' a system, and the | legitimate system's attempts will be rejected. If that occurs... oh | well. It is anonymous data. I'm not sure I understand the need for the token. The Debian popularity-contest (popcon, [1]) only identifies systems by a single random token (MY_HOSTID in /etc/popularity-contest.conf). It supports sending information by mail as well (thus: completely non-interactively). I don't see what the extra temporary token buys here. Just send a report that includes the (random) server ID. Nobody should be able to copy those (as they are only sent encrypted over the internet). And in any event, why would anybody want to spoof that (as opposed to merely add records to skew the stats, which is possible either way just as easily). What am I missing here? [1] https://packages.debian.org/sid/popularity-contest -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- [image: Digium logo] Scott Griepentrog Digium, Inc · Software Developer 445 Jan Davis Drive NW · Huntsville, AL 35806 · US direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090 Check us out at: http://digium.com · http://asterisk.org -- [image: Digium logo] Scott Griepentrog Digium, Inc · Software Developer 445 Jan Davis Drive NW · Huntsville, AL 35806 · US direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090 Check us out at: http://digium.com · http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Fwd: Code Review request of func_redis module
Don't worry, I understand it isn't production ready, I'll test that only on a dev instance. I don't know yet if I'll have skills to help you with pull requests, but at least, with tests and eventual bug reports. For now, it isn't really critical, because I've a daemon that plays as a Redis proxy for Asterisk, but I vote always for simplifications, if only I don't have efficiency impacts. -- Ludovic Gasc (GMLudo) http://www.gmludo.eu/ 2015-05-12 9:04 GMT+02:00 Sergio Medina Toledo gest...@ull.edu.es: The part of the internal API that I used haven't changed from 11 to 13 so it should work without any problem. But I haven't tested the module intensively and I'm not sure if it is thread safe, so I don't recommend use it in production servers right now. Today I'm gonna install the module in an asterisk 11 active-passive cluster of preproduction to test it better, after that I will expose my conclusions here, if some one that have more experience developing in asterisk can look at the code and confirm that it is thread safe i will be very grateful. 2015-05-11 21:22 GMT+01:00 Ludovic Gasc gml...@gmail.com: Hi, Your library is very interesting, because we already use Redis as a cache for some stuffs. For now, I've made a FastAGI server to serve Redis data, but it should be faster to read Redis data directly. Do you think I could test your module on an Asterisk 13, or the Asterisk internal API is too different to be used with another version than 11 ? Regards. Ludovic Gasc (GMLudo) http://www.gmludo.eu/ On 11 May 2015 09:14, GESTION DE TELEFONIA IP gest...@ull.edu.es wrote: Hi all, I have developed an asterisk module to interact with redis from the dialplan, the project is motivated by the need to share information between different asterisk in both active-active and active-passive scheme, in an easy way like AstDB. You can use an agi script or a system call to a script to use redis from the dialplan but the performance is low compared to a asterisk module and the integration is worst. I think that maybe this module can be interesting to the community, It's the first time that I develop a asterisk module so If some one can make a code review to the module to see if there are use of insecure functions or something that can crash asterisk, I will be very grateful, the module is under GPLv2 License in this repo https://github.com/tic-ull/func_redis. At the moment the module is shipped outside the asterisk project, as a Cmake project. You can see the instructions to install and to use it in the README.md of the repo. The english isn't my native language so sorry if there ara some writing mistakes. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
So as opposed to spoofing, there is also the case that someone having a copy of Asteirsk in a virtual machine clones it, and ends up with two instances reporting the same random ID. With the spoofing detection mechanism (using tokens to get an ID from the server), the effect of this case is minimized as each one will end up getting a new ID after token timeout. On Tue, May 12, 2015 at 12:59 PM, Tzafrir Cohen tzafrir.co...@xorcom.com wrote: Quoting the spec: | Spoofing | | In order to limit spoofing, the server will return a token for all | accepted requests to a server. Any subsequent requests to that resource | must present the token in the request. If a subsequent request fails to | provide the token, the request is rejected. Tokens expire after 48 | hours, at which point, a request does not have to provide a token. If a | request does provide a token that is expired - and no token is required | at that point - the request should be accepted and a new token granted. | Once a request is made without a token (and no token is expected), a new | token is issued for subsequent requests. | | So long as Asterisk's transmission of data occurs faster than once every | 48 hours, a malicious entity will not be able to spoof a resource. If a | system is down then a remote system can 'take over' a system, and the | legitimate system's attempts will be rejected. If that occurs... oh | well. It is anonymous data. I'm not sure I understand the need for the token. The Debian popularity-contest (popcon, [1]) only identifies systems by a single random token (MY_HOSTID in /etc/popularity-contest.conf). It supports sending information by mail as well (thus: completely non-interactively). I don't see what the extra temporary token buys here. Just send a report that includes the (random) server ID. Nobody should be able to copy those (as they are only sent encrypted over the internet). And in any event, why would anybody want to spoof that (as opposed to merely add records to skew the stats, which is possible either way just as easily). What am I missing here? [1] https://packages.debian.org/sid/popularity-contest -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- [image: Digium logo] Scott Griepentrog Digium, Inc · Software Developer 445 Jan Davis Drive NW · Huntsville, AL 35806 · US direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090 Check us out at: http://digium.com · http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Journald support for Asterisk
I've two remarks about that: 1. Even if a journald support is one day included in Asterisk, it will be for Asterisk 14 or 15 at least. The time you have that as stable version, it will be 2016 or 2017. Even if we already have some few CentOS on production because it's mandatory for some products, we stopped to install new CentOS 6 a long time ago. At least for us, when we want to have a new version of Asterisk, we install first a new VM with the latest stable version, in this case, CentOS 7, because it's very easier to setup a new VM, migrate data, and finally switch DNS records, instead of to cut the service. 2. Moreover, the support of journald doesn't mean you must drop syslog logging: I don't know how the standard logging mechanism works in C, but in Python: a. You log has usual your message with logging.info(), and you add a parameter extra with the metadata/dict of the log. b. You have a list of handlers already included in Python to log in syslog, console, file...: https://docs.python.org/3.4/library/logging.handlers.html#module-logging.handlers Most handlers don't support extra parameter, its drop extra data. For handlers that support that like journald, it's included. Ludovic Gasc (GMLudo) http://www.gmludo.eu/ On 12 May 2015 07:25, Corey Farrell g...@cfware.com wrote: CentOS/RHEL 6 are under production support until Nov 2020 [1] and journald is not available. Even if journald could improve Asterisk logging, that's not an acceptable reason to force Asterisk users to upgrade from a supported OS. If there was a module that allowed Asterisk logging to talk to journald I wouldn't care, but it should not replace the logging system or be required to run Asterisk. [1] http://wiki.centos.org/FAQ/General#head-fe8a0be91ee3e7dea812e8694491e1dde5b75e6d On Sun, May 10, 2015 at 5:22 PM, Ludovic Gasc gml...@gmail.com wrote: 2015-05-10 20:46 GMT+02:00 Bruce Ferrell bferr...@baywinds.org: On 05/09/2015 01:53 PM, Ludovic Gasc wrote: 2015-05-09 16:15 GMT+02:00 Bruce Ferrell bferr...@baywinds.org mailto:bferr...@baywinds.org: On 05/09/2015 01:17 AM, Ludovic Gasc wrote: Hi, Systemd and Journald is now by default on Debian Jessie and Ubuntu 15.04, as on RHEL/CentOS. Journald supports syslog format, nevertheless, at least for us, the structured log system provided with journald helps us to debug the production. The idea behind that is to attach metadata with a log line to facilitate the search with journalctl, you can write queries to find the errors. For example, with Apache: http://httpd.apache.org/docs/trunk/mod/mod_journald.html For our Python daemons, for each log line, we store account_id, request_id, endpoint and method used to be easy to retrieve quickly interesting logs. Moreover, not yet used for us, but you can generate statistics about your source code real usage based on: http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#CODE_FILE= For Asterisk, for example with dialplan logging, you should attach the context, the extension and the channel. You can simulate this journald feature with a specific format message for your logs, nevertheless, journalctl is more user-friendly to retrieve pertinent logs compare to the classical grep usage. ave no idea if i I'm permitted to raise the question about an eventual journald support in Asterisk because I don't find anything about that in issues tracker nor mailing list. Moreover, I understand that even if you add the journald support, it's certainly necessary to change logging everywhere in Asterisk, however, I should help to do that. Regards -- Ludovic Gasc (GMLudo) http://www.gmludo.eu/ systemd and journald SUCK to high heaven. I've no problems to believe you, nevertheless, could you be more precise ? What are the facts that you arrive to this conclusion ? I have no idea if the issues I've had with them (OpenSUSE) are distro related or inherent. It's issues on your production with several servers ? Or on your laptop ? Could give us links with unresolved bugs you have ? For now, to my experience, with 6 VMs on Debian Jessie on production with small clients and Asterisk 13, I've no issues with systemd nor journald. I have seen that the implementation of apache with a static systemd/journald module will no longer correctly serve content. Could you give me a link about that ? I would suggest you try it for yourself. Procedure to reproduce: Perform fresh install of OpenSUSE 13.2 assure apache/php/MySQL support are installed install wordpress from wordpress.org Observe CSS is NOT correctly served. I did this several times to assure my findings. I rebuilt the opensuse rpms from the source rpms to omit systemd/journald from
Re: [asterisk-dev] Journald support for Asterisk
2015-05-12 13:48 GMT+02:00 Tzafrir Cohen tzafrir.co...@xorcom.com:
On Mon, May 11, 2015 at 11:26:31PM +0200, Ludovic Gasc wrote:
The idea behind structured log is to retrieve easily a context with a log
to reduce the effort of categorization after, because you don't need to
parse and recognize patterns in log message.
Technically, instead of to have a String, you have a Dict of Strings.
That's nice in theory. Could you please give an example of the required
output? An example of how it would help?
For now, this is the situation to log for most applications:
1. In your source code, where you want to log, you aggregate data from
several variables to generate a log message. Example:
logger.info('This is a call from %s with the uniqueid %s and
callerid %s to call %s extension in %s context', endpoint, uniqueid,
callerid, extension, context)
2. This message is stored in the text format in /var/log/asterisk/debug.log
3. For example, to retrieve all logs about a specific extension, the
sysadmin needs to use: grep -i \%s\
extension /var/log/asterisk/debug.log or write regex for a log analysis
tool, with a risk of false positive or miss something.
At the beginning, in your source code, you have structured data, you encode
as string for log.
After, to get metadata in logs, you need to decode your logs with regex to
retrieve structured data to query inside.
The final situation should be:
logger.info('This is a call from %(endpoint)s with the uniqueid
%(uniqueid)s and callerid %(callerid)s to call %(extension)s
extension in %(context)s context', {'endpoint': endpoint, 'uniqueid':
uniqueid, 'callerid': callerid, 'extension': extension, 'context': context})
And after, depends on the handler:
a. For syslog, you use the dict only to replace values in string
b. For journald, you push also the dict with the log message. With
that, you don't need to encode/decode, you retrieve directly structured
data included in message log.
And yes, ideally, it should be useful if we can generate log messages with
the structured data directly in the dialplan.
BTW, you just give me an interesting idea to have this feature easily: I
can make a FastAGI daemon that generate my journald message, based on data
pushed as parameter with a JSON dict structure.
Not really funny to write the dialplan source code, however, it will work.
If it isn't enough concrete for you, I can give you a concrete example with
a click2call HTTP endpoint, where the order starts from WebBrowser, to
finish in asterisk.
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.co...@xorcom.com
+972-50-7952406 mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
Quoting the spec: | Spoofing | | In order to limit spoofing, the server will return a token for all | accepted requests to a server. Any subsequent requests to that resource | must present the token in the request. If a subsequent request fails to | provide the token, the request is rejected. Tokens expire after 48 | hours, at which point, a request does not have to provide a token. If a | request does provide a token that is expired - and no token is required | at that point - the request should be accepted and a new token granted. | Once a request is made without a token (and no token is expected), a new | token is issued for subsequent requests. | | So long as Asterisk's transmission of data occurs faster than once every | 48 hours, a malicious entity will not be able to spoof a resource. If a | system is down then a remote system can 'take over' a system, and the | legitimate system's attempts will be rejected. If that occurs... oh | well. It is anonymous data. I'm not sure I understand the need for the token. The Debian popularity-contest (popcon, [1]) only identifies systems by a single random token (MY_HOSTID in /etc/popularity-contest.conf). It supports sending information by mail as well (thus: completely non-interactively). I don't see what the extra temporary token buys here. Just send a report that includes the (random) server ID. Nobody should be able to copy those (as they are only sent encrypted over the internet). And in any event, why would anybody want to spoof that (as opposed to merely add records to skew the stats, which is possible either way just as easily). What am I missing here? [1] https://packages.debian.org/sid/popularity-contest -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] systemd sd_notify() [was: Re: Journald support for Asterisk]
On Sun, May 10, 2015 at 3:03 AM, Tzafrir Cohen tzafrir.co...@xorcom.com wrote: On Sat, May 09, 2015 at 10:17:24AM +0200, Ludovic Gasc wrote: Hi, Systemd and Journald is now by default on Debian Jessie and Ubuntu 15.04, as on RHEL/CentOS. Journald supports syslog format, nevertheless, at least for us, the structured log system provided with journald helps us to debug the production. Slightly off-topic: if anybody wants to implement support for sd_notify(3)[1] in Asterisk, it would be nice. Suppose there would be a function called ast_daemon_changed_state()[2] to notify journald on end of start, start/end of reload and start of end. Is this information useful to anything else besides notifying systemd via sd_notify()? [1] http://www.freedesktop.org/software/systemd/man/sd_notify.html [2] Bad name, I know. I'm not sure I'd create a new C API for this. Asterisk already uses Stasis to convey a lot of this information, although today, it is only consumed by AMI. The right way to do this would be to pull the messages out of the manager topic and make them a bit more publicly consumable. If that is done, you could then have a completely independent external module that interfaces with systemd. Since there isn't a reload start/stop, there'd have to be at least one new message added as well. The messages to look at are: The publishing of Reload in loader.c::publish_reload_message The publishing of FullyBooted in asterisk.c::publish_fully_booted The publishing of Shutdown in asterisk.c::really_quit -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] (unreported) uninitialized: struct ast_sockaddr
On Mon, May 11, 2015 at 9:16 AM, Alexander Traud pabstr...@compuserve.com wrote: B) Change my patch not to use a char* but char[128]. Your easiest option with less chance of regression elsewhere would be this. Yes. Anyway: Is the Asterisk team interested in a patch at least for the 5 affected files? These are 54 changes. I am not sure if the path via an issue (Jira) and a commit (Gerrit) is welcome for something like this. Furthermore, again there are several options: I) in those 5 files, report only those 54 changes which I need; or II) in those 5 files, correct *all* struct inits The latter is interesting, because there are memsets(.) which get unnecessary then. This created an additional option/question: III) shall I remove all - then duplicate - struct inits as well? Or shall I stop wasting anyone's time and go for option B, a char[128]? I wouldn't say you're wasting anyone's time. It's a good question. What you're proposing is a change to the semantics of ast_sockaddr in order to accommodate a change in a patch you're making. A few things to keep in mind: 1) Your module/patch, as well as the rest of the Asterisk modules, may not be the only consumers of ast_sockaddr. It is a fundamental data structure in Asterisk; other third party modules may use it. Since your change modifies the semantics of the struct, you will also break them. 2) If the rest of your patch is never pushed back up to the main project, then the change you've made has little positive affect, while breaking most other external modules that use it. That's not good for the project. On the other hand, if you propose your feature for inclusion as well, there's more of a benefit to the change. That aside, if you can make a change with a little bit more work that maintains the existing usage semantics, you get the best of both worlds: your new feature gets what it needs, and the mainline Asterisk project - as well as other third party modules - aren't broken. So yes, I'd just use a char array with a fixed length. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
On Mon, May 11, 2015 at 01:29:04PM -0600, George Joseph wrote: As for the other issues, why not just have asterisk fork itself on startup and reloads just to send the stats. No separate executables, no AMI, no cron, and you get the process separation so a segv or orthe rerror doesn't kill the main process. KISS! This makes it part of the asterisk service, as far as systemd is concerned. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Journald support for Asterisk
On Mon, May 11, 2015 at 11:26:31PM +0200, Ludovic Gasc wrote: The idea behind structured log is to retrieve easily a context with a log to reduce the effort of categorization after, because you don't need to parse and recognize patterns in log message. Technically, instead of to have a String, you have a Dict of Strings. That's nice in theory. Could you please give an example of the required output? An example of how it would help? -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Journald support for Asterisk
On Sat, May 9, 2015 at 9:15 AM, Bruce Ferrell bferr...@baywinds.org wrote: systemd and journald SUCK to high heaven. I have no idea if the issues I've had with them (OpenSUSE) are distro related or inherent. You're welcome to your opinion, but I find systemd/journald very nice. I'd welcome having Asterisk log directly to journald as an option. I wouldn't support dropping other logging methods because there are systems that don't have journald, or their admins would prefer some other logging method. I have seen that the implementation of apache with a static systemd/journald module will no longer correctly serve content. The Apache httpd mod_journald is very new so it's not surprising that there are bugs. It also breaks fail2ban site security. As a point of fact, journald support was added to fail2ban over a year ago, and works quite well. -- Jeff Ollie -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
On Tue, May 12, 2015 at 5:41 AM, Tzafrir Cohen tzafrir.co...@xorcom.com wrote: On Mon, May 11, 2015 at 01:29:04PM -0600, George Joseph wrote: As for the other issues, why not just have asterisk fork itself on startup and reloads just to send the stats. No separate executables, no AMI, no cron, and you get the process separation so a segv or orthe rerror doesn't kill the main process. KISS! This makes it part of the asterisk service, as far as systemd is concerned. Is that a bad thing? Did I miss something in the email chain? -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
