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. 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. 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. 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. 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. 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) * * *
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) > > * * *
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) > > * * *
Hi,> -----Original Message----- > 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+administrationCheerio, good work. Some comments (also added in the wiki): * 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. ''Running Asterisk can also be done from /etc/inittab, resulting in an automatic restart after a stop. Do make sure your machine at least starts properly, or it will reload at maximum speed. To monitor the livelyness of Asterisk, some tools are available which assist with integration in monitoring systems such as mon, big brother and netsaint.'' * __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. ''If you run Asterisk provisioned for automatic reloading this could be as simple as placing a cronjob to execut easterisk -rx 'stop gracefully'.'' Added issue: * __Ensure a stable Asterisk code base__ by using some form of staging environment. Latest stable release (tar.gz file) is often not the best choice, but bleeding edge CVS isn't either. Your own preferred patches might also not be in CVS yet. I tried doing this with my own CVS tree, but keeping it maintained proved a pain in the *ss. Who has good suggestions about this ? :-)) Florian