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) > > * * * _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users