[Asterisk-Users] Administrative suggestions

[info-lists at robertc.de]

Philipp,
Good document, my comments are inline with the parts to which they apply.
(and yes, this was a top post, otherwise it wouldn't make sense.)

Robert


> Hi there,
>
> mostly based upon list postings I compiled a couple of administrative
> suggestions on the Wiki page below. I'd be glad to have this reviewed and
> commented:
>
> http://www.voip-info.org/tiki-index.php?page=Asterisk+administration
>
> Cheers, Philipp
>
>
> Adminstrative suggestions
>
> Use a GUI client that's based upon the manger API (like gastman or astman
> etc) to obtain an overview of what is currently going on in your PBX. Of
> course you should also regularly check the log files in /var/log/asterisk
> and watch their size.
>
**
** Might be good to give some idea of what to look for in the logs and
** why to watch the file sizes.
**
> Separate your PC network from your VoIP network (see also Quality-of-
> Service (QoS) issues)
>
> Remove all uneeded modules from your Asterisk server. For example if you
> are only doing ZAP and SIP then specify noload= for MGCP, Skinny in
> modules.conf. That reduces risks of potential exploits sleeping in those
> modules
>
> Disallow users to work on your Asterisk server. The recently published
> serious kernel exploits all required local user access to start with.
>
> Consider to not use mpg123 for music-on-hold (MOH), or take provisions to
> kill hung mpg123 threads whenever applicable. mpg123 has the habit to not
> terminate after stopping Asterisk.
>
**
** Might want to list the alternatives.  Its not a good idea to say don't
** use something without giving an alternative.  Personally I don't remember
** seeing that mpg123 shouldn't be considered for MOH.  The problem with
** not stopping the threads after Asterisk is terminated might be right but
** doesn't seem to justify a reccomendation not to use mpg123.
**
**
> Look into your startup script and take provisions to detect and restart
> and hung asterisk. Check out daemontools for this purpose. You could also
> regularly telnet into Asterisk (manager.conf) to at least make sure it
> hasn't completely crashed.
>
**
**  "restart and hung asterisk.".  Did you mean "restart a hung asterisk
process"?
**

> Find out if you can run Asterisk with a user other than "root". The
> documentation states that in principle that should be possible, however
> there seem to be no/few users who have ever attempted this.
>
> Think about creating your extensions.conf, sip.conf and voicemail.conf
> based upon a database that can be shared like mySQL (or whatever else you
> are used to). The recently added ODBC support in Asterisk opens up a lot
> of possibilites. Next to that the #include syntax that permits to include
> other files into any of the .conf files can be of help.
>
> An unthoughtful change to extension.conf can have a disastrous effect on
> your entire PBX. Establish a procedure for those changes to be not
> suddenly left without e.g. emergency services (911 or 999 or 112) without
> you noticing. Always check the log file after having applied a change to
> extensions.conf in a production system.
>
> Think about putting a quota on voicemailboxes, or schedule a script that
> deletes all voicemail older than x days. One way to enable quotas is to
> trigger an AGI script just before a user is directed to voicemail and
> then decide if a message can be recorded or of the user has run out of
> space.
>
> Use Ethereal (with the IAX plugin) to analyse your network traffic.
>
> Set an AbsoluteTimeout value for all cost-producing calls to prevent sky-
> high bills in case something should ever go wrong with either Asterisk or
> one of your phones. Take especially the SIP protocol and its limitations
> to detect a disconnected client into account.
>
**
** Do you really want to do this and then have people complain because
** a call to an important customer was disconnected?  Some conference calls
** can go on for hours, particularly between Germany and the USA due to
** reductions in travel authorizations.
**
> Regularly restart (better: stop and start) your PBX during off-hours. A
> repetitive reload will not be sufficient, and can actually cause more
> harm than it does good.
>
**
** Might want to explain why a repetitive reload can "cause more harm than
it does good."
**

> Spend some thought on redundance, load balancing and maybe even
> clustering. So far there is not perfect solution worked out for Asterisk,
> however that should not prevent you from thinking about this issue (a
> search on the mailing list asterisk-users will reveal a lot of competent
> postings)
>
> * * *