[asterisk-dev] Asterisk Beacon Module Proposal

[Matthew Jordan]

<snip>

Thanks everyone for the suggestions and ideas. I'm sorry I haven't had
a chance to reply back to them all until now, but I've had a lot of
trips and other things pop up, and didn't have a chance to fully
digest the suggestions and reply back until now.

I've grouped the various suggestions that I had not yet previously
replied to below.

Suggestion 1: Make the module opt in instead of opt out.

In most cases, I would normally agree with this proposal, as I
personally prefer an opt in model instead of an opt out model.
Unfortunately, I'm not sure I can think of a way where this suggestion
would work with Asterisk - where work implies that a meaningful number
of people are presented with the option to opt in in a consistent
fashion. Unlike a number of other projects, Asterisk does not have:
* A consistent way in which it is downloaded or deployed. Asterisk is
built from source; obtained from upstream distro packages; from the
project packages; from ISO distributions; and more. All of these can
determine what is presented during the process, and the Asterisk
project itself has little control over those mechanisms.
* A UI that can present a user with a single, one-time only option to
'opt in'. This is in contrast to say Operating Systems or anything
running with any kind of installation UI.

Personally, I'd like some way to present any user of Asterisk with a
one-time only, non-annoying "please help the project and opt in"
question, and then move on forever. Unfortunately, I don't have a good
idea on making this suggestion work. If the only way to opt in is to
provide a .conf file and set "enable = true", then I can't see
anywhere near sufficient numbers of people being aware of the
configuration choice, much less making the choice to enable it, to
justify the creation of the module itself.

If someone has a good proposal on making the suggestion work, then I'd
love to entertain it further.

Suggestion 2: Have Asterisk fork itself on startup

While this seems like a good idea, there are some nasty things that
can occur when you fork the Asterisk process. Asterisk throws a lot of
caution to the wind by mixing itself as a forking process and
multi-threaded process (for a good explanation of why you should never
do this, read http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them).
I've personally spent over a month trying to debug the last time we
held a mutex right when we forked the process, and it was not a fun
experience.

If we fork the process when we go to do a report, any mutex held by a
thread will still be held in the forked process. This includes, for
example, the module list lock that needs to be grabbed when we iterate
over the list of loaded modules. If the report sends that information
and the list is locked at that point (because someone ran the CLI
command "module show..." at the same time), that forked process will
deadlock, leaving an orphaned process sitting out there. Yikes.

I'd rather not mix multi-processing into the design of the module.
Given that this is a very simple set of information that we are
looking to send - and we are going to (a) write a TON of tests for
this, and (b) everything will go through our usual strenuous code
review, I think we can mitigate any risk substantially. I certainly
would invite everyone on the list to help review the code and tests to
make sure we don't miss anything.

Suggestion 3: Use a separate cron job to trigger the sending

I think this is a great idea, although I would modify it just
slightly. How about modifying the interval setting such that if it is
set to 0 in the conf file, Asterisk will *not* schedule sending
(effectively soft disabling transmission), and then adding the
aforementioned CLI command (and probably an AMI variant as well)? That
gives the best of both worlds: external control can completely take
over the transmission of the report, while still not requiring any
additional setup.

Suggestion 4: Questions about the need of a token

The token usage was I think a bit misunderstood. To quote Tzafrir:

{quote}
So let's assume I have to cloned servers, A and B. Both have the same
ID, but each gets a different (temporary) token.

I assume tokens don't live very long. So now you need to corelate a
number of temporary tokens with A and others with B. If they do live
long enough, they might get cloned. The corelation of temporary IDs to
different servers does not seem reliable enough for me.
{quote}

So that is actually incorrect. Say you had two servers who happened to
get the same Server ID, because you cloned the AstDB. Whoops. Both do
*not* get a temporary token when they report. The reporting server
should prevent collisions in that case, and only hands a token to the
first Asterisk server that presents a Server ID and the current valid
token. Token expiration on the server is supposed to be quite long.
Each Asterisk with a Server ID gets a unique temporary token, and if
an Asterisk with the same Server ID asks for a token but does not
present the current token when it does so, it will be rejected. The
module should then request a new Server ID.

At any point in time, there is only one token associated with one
Server ID, not multiples.

Really, if this needs substantially more explanation on the wiki page,
that's fine, but this is really a mechanism to try and reasonably
prevent collisions. It is not meant to be a security mechanism (other
than it may frustrate someone who really is bored and tries to spoof
random UUIDs). The usage of reporting server assigned UUIDs is
probably going to account for 99% of our cases.


Hopefully this answers some of the concerns and suggestions.

Thanks!

Matt

-- 
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