Category: software

How I upgrade Asterisk 1.8

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

Note: This article was originally posted in August, 2011 and is very out-of-date.

This is just one of those things that I figured it might not hurt to put into a blog post so I can find it later if I ever need to.  This is the procedure I use to upgrade Asterisk 1.8 when a new release appears that has a fix that I feel I need, or that closes a security hole.  PBX in a Flash users should NOT do this, and FreePBX Distro users probably shouldn’t do this either, as you have your own respective upgrade mechanisms.  This is for folks who have either built a system from scratch, or who (like me) started out with a distro but the decided to go your own way as far as upgrades are concerned.  Note that I am only saying that this is how I do it.  I am NOT telling you to do it this way, and if you do so you do it at your own risk.

There are the steps from the CentOS Linux command prompt.  Some of them need further explanation and those have a footnote number next to them.  Do NOT enter the footnote number from the command prompt! Also, in these examples I’m using Asterisk 1.8.5.0 (the current release version as I write this) as the version I’m installing, but you should go to http://downloads.asterisk.org/pub/telephony/asterisk/releases/ and find the current version and use that instead.  If the lines overflow the width of the column, you should probably copy and paste the entire block into a text editor so that you can see the complete lines and know where the line breaks are supposed to be.

cd /usr/src
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.8.5.0.tar.gz ¹
tar xvfz asterisk-1.8.5.0.tar.gz ¹
cd /usr/src/asterisk-1.8.5.0 ¹
make clean
contrib/scripts/get_mp3_source.sh
./configure
make menuselect ²
/root/stopnoise ³
make
make install

After doing this I find it’s easiest to just reboot the system to nip any “weirdness” in the bud. Some Linux purists will hate that idea (it seems to be a badge of pride among some of them to see how many days they can run a system without rebooting), and if you don’t want to reboot, feel free not to — it’s your system. Many people will stop Asterisk before starting the upgrade procedure by doing amportal stop at the beginning, and amportal start at the end, but since I usually reboot anyway I’ve never found the need to do that (the upgrade seems to go just fine even if Asterisk is running at the time, so I’m not sure why so many people think they have to stop Asterisk first — probably a case of one person did it, so everyone else follows like lemmings to the sea). However, if you don’t plan on rebooting, then you must stop and restart Asterisk to get it to use the upgraded version.  If I want to only restart Asterisk for some reason, I usually go into the Asterisk CLI and do “core restart when convenient” so that the system will restart as soon as there are no calls in progress.

I do NOT use the flite synthesized voices (I can’t stand them; they are far too mechanical for my taste) so you won’t find any instructions here pertaining to those.

Now the footnotes:

¹ Use the correct version number for the version of Asterisk you are installing in place of 1.8.5.0

² When you run “make menuselect” it will bring up a menu that lets you select various options. You will want to pay attention to what is selected and what is not. Typically I need to make these changes:

Under Add-ons, I select everything EXCEPT chan_ooh323 — most of the others are required for FreePBX to function properly. Under Applications, I use the defaults. Under Bridging Modules through PBX Modules, everything that is not X’ed out is selected. Under Resource Modules everything that is not X’ed out is selected except res_pktccops (NOTE: If res_srtp has XXX next to it and you would like to enable SRTP support, stop here and read the note at the bottom of this article). Under Test Modules NOTHING is selected. Under Compiler Flags, LOADABLE_MODULES is selected by default and in addition I select G711_NEW_ALGORITHM and G711_REDUCED_BRANCHING. Under Voicemail Build Options through Module Embedding I just accept the defaults. Under Core Sound Packages through Extras Sound Packages I accept the defaults and also add the sounds corresponding to the language and codecs I use on my system (in my case the *-EN-WAV and *-EN-ULAW packages, and if I had any wideband endpoints I’d also use the *-EN-G722 packages). So, the only screens on which I make changes (in other words, I don’t just accept the defaults) are the Add-ons, Compiler Flags, and the three sound-related screens. Note that the Compiler Flags are just a personal preference (I just think the new algorithm may make G.711 calls a bit clearer) and the sounds MAY not need to be reloaded on every upgrade, but I’d rather be safe and include them, just in case some of the sound files have been updated.

³ This is a bash script I have in my /root directory that contained the following three lines prior to Asterisk 1.8.12.0:

#!/bin/bash
sed -i 's/ast_verb(4, "ast_get_srv: SRV lookup for/ast_verb(11, "ast_get_srv: SRV lookup for/' main/srv.c
sed -i 's/ast_verb(4, "doing dnsmgr_lookup for/ast_verb(11, "doing dnsmgr_lookup for/' main/dnsmgr.c

Starting with Asterisk 1.8.12.0 it appears they changed the default value in the last line, so now I use this:

#!/bin/bash
sed -i 's/ast_verb(4, "ast_get_srv: SRV lookup for/ast_verb(11, "ast_get_srv: SRV lookup for/' main/srv.c
sed -i 's/ast_verb(6, "doing dnsmgr_lookup for/ast_verb(11, "doing dnsmgr_lookup for/' main/dnsmgr.c

If either or both of the phrases “doing dnsmgr_lookup for …” and/or “ast_get_srv: SRV lookup for …” are familiar (and annoying) to you, then you may want to use this script. Otherwise, you can just skip this instruction. For more information, see this thread in the PBX in a Flash forum.

NOTE REGARDING MISSING SRTP SUPPORT: It is possible to add this by following this procedure:

In your browser go to ftp://ftp.owlriver.com/pub/local/ORC/srtp/ (your browser must support the ftp protocol – try Firefox if yours doesn’t). You should see a file named srtp-1.4.4-1orc.src.rpm or perhaps a newer version. Download it and then move it to a directory (such as /tmp or /root) on your Asterisk server. Then do this, changing the version number if you got a different one:

cd (whatever directory you put the file into)
rpm -ivh srtp-1.44-1orc.src.rpm
cd /usr/src/redhat/SOURCES/srtp

(If the srtp directory does not exist then cd /usr/src/redhat/SOURCES/ and tar xvf srtp-1.4.4.tgz)
./configure
make
make install

Then go back and restart the upgrade procedure, starting at the second cd … command and make clean. When you get to make menuselect, res_srtp should now be enabled. Note that this is not the only thing you need to do to make SRTP functional; at a bare minimum you would beed to add the line encryption=yes to the extension’s configuration, and even that would not be sufficient for some devices due to a so far unpatched bug in Asterisk. But, that is beyond the scope of this article.

How to keep one group of extensions from being able to call another group of extensions in FreePBX

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

FreePBX is NOT designed for multi-tenant use. Yet a lot of people will still try to, for example, run two small companies off the same FreePBX server. The question then invariably arises “How do I keep one company’s users from calling the other company’s extensions?”

Just yesterday in the FreePBX forum, someone asked:

Imagine I have extensions 100-110 and I name those CustomContext “GroupA” and I name 200-210 as “GroupB”. Can anyone tell me how I’d eliminate GroupA and GroupB from dialing each other?

And I replied as follows:

Create two new contexts in /etc/asterisk/extensions_custom.conf (just add these to the bottom of the file):

[from-group-a] exten => _2XX,1,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

[from-group-b] exten => _1XX,1,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

After you do that:

Go to the extension configuration page for each extension in Group A and change the context from from-internal to from-group-a.

Go to the extension configuration page for each extension in Group B and change the context from from-internal to from-group-b.

The way this works is if someone in Group A attempts to call an extension in the 200-299 range, OR if someone in Group B attempts to call an extension in the 100-199 range, the call is diverted to “congestion” (a fast busy signal). Otherwise, the call goes to the from-internal context and is processed in the normal way.

No nice way to do this from a GUI page, unfortunately. But, this is pretty simple, I think.

EDIT: There may be a slightly more elegant way to do this, that only involves adding ONE additional context to /etc/asterisk/extensions_custom.conf:

[from-restricted-exts] exten => _2XX/_1XX,1,Goto(app-blackhole,congestion,1)
exten => _1XX/_2XX,1,Goto(app-blackhole,congestion,1)
exten => _[*0-9]!,1,Goto(from-internal,${EXTEN},1)
exten => h,1,Hangup()

Then you would change the context for all “restricted” extensions from from-internal to from-restricted-exts — this should have the exact same effect as the above contexts (if you don’t understand why, see Asterisk hiding a useful feature in plain sight by giving it a “cute” name).

What I did not really go into in that reply is that this does NOT provide 100% separation.  Although it prevents a user in one group from calling a user on the other directly, it does not address a host of other issues that could arise.  Just as one example, there is nothing that would stop a user in “Group A” from transferring a call to a user in “Group B”.  Did I mention that FreePBX is NOT designed to be a multi-tenant system?

Probably the best solution for multi-tenant use is to run separate installations of Asterisk and FreePBX for each tenant.  You can run them on separate servers, or on separate Virtual Machines on the same server, but be careful if you do the latter, because some VM’s work better than others for the purpose.  The PBX in a Flash folks would tell you, for example, that they’ve never had a problem running PBX in a Flash under Proxmox, but always seem to have issues if trying to run it under VMware.  But others will say that with the right tweaks (and by installing VMware Tools) they’ve made it work under VMware.  But I think that if you only have one server available, running two installs of Asterisk and FreePBX in Virtual Machines is better than trying to make FreePBX (and perhaps Asterisk itself) do something it is clearly not designed to do.

Asterisk hiding a useful feature in plain sight by giving it a "cute" name

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
easter eggs in the stage of painting
Easter Eggs (Image via Wikipedia)

Somewhere in FreePBX 2.7 or thereabouts, it became know that there was a feature of FreePBX Outbound Route dial patterns, were you could use a /CallerID extension. This (among other things) basically lets you limit the use of an Outbound Route to a particular extension or group of extensions.  It’s a very useful feature, but wasn’t widely announced or promoted at the time.  I finally figured out why.

Thing is, it’s NOT a FreePBX feature, it’s a feature of Asterisk.  Anywhere in an Asterisk dial plan where you have a line that starts with

exten => _somepattern,…

you can use the Caller ID modifier, like this:

exten => _somepattern/callerid,…

In which case the pattern won’t be matched unless the current Caller ID number (which on an internal call is the number of the calling extension) matches whatever you’ve replaced callerid with.  Callerid can itself be a number or a pattern.

The real kick in the head is that it appears this feature has been around for a LONG time.  It was definitely in Asterisk 1.4.  Yet virtually none of the documentation you see on Asterisk even mentions this feature.  It might as well have been an “Easter Egg” hidden in the software, for all anyone knew of it.  Well, I finally figured out why — the Asterisk folks hung a “cute” name on it, and it stuck.

They called it ex-girlfriend logic.  The idea is that you can use it to stop an ex-girlfriend from bothering a particular user on your system (at least in raw Asterisk, though I don’t think that’s directly supported in FreePBX).  Besides being a bit sexist, it’s also about the last terminology anyone would think to Google on if they were trying to find out about this feature.  So while people were writing third-party modules like Custom Contexts and Outbound Route Permissions in FreePBX, it now turns out that essentially the same basic functionality was there all along, but hardly anyone (at least in the FreePBX world) knew about it until around about the time of FreePBX 2.7 or so.  If you can find anything at all about this feature in “official” Asterisk documentation (that doesn’t include third-party sites!), you’re a better searcher than I.

Makes you wonder if there are any OTHER cool features in Asterisk that are hidden in plain sight, under unfortunate descriptive names that no one would ever think to use when searching for such a feature!

 

Problems you may encounter when attempting to install phpMyAdmin on your Centos server, and how to solve them

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This article was originally published in August, 2011 and may contain outdated information.

phpMyAdmin logo
Image via Wikipedia

I just spent an interesting couple of hours trying to install phpMyAdmin on an Asterisk server running CentOS 5.5. As I encountered each problem and solved it, I had to wade through a lot of pages that weren’t applicable to my installation, etc. Since many readers of this blog run similar configurations I thought I’d just list the hiccups I encountered, and what I had to do to solve them. Note that some distributions come with phpMyAdmin already installed, so make sure you don’t already have it before you try to install it!

NOTE: Think carefully about whether you really want to follow the instructions below, particularly if it requires adding a repository. If you do that, make sure you only install the software you actually need from that repository, then disable it (set enabled=0). If you don’t do that, you could easily get into a situation where some of your curent software (such as PHP) simply will not upgrade no matter what you do. And if you are running a PBX “install and go” distribution, they may specifically warn you not to add repositories, or it will break your installation, so don’t do it!

If you do anything suggested below, you do it at your own risk!

• yum install phpmyadmin doesn’t work — try using the dag repository — there are several pages on the Web that tell how to do this. Use Google to search for “how to enable the dag repository” (without the quotes) if you need help. The basic idea is you need to create a file called /etc/yum.repos.d/dag.repo (with the proper permissions, ownership, etc.) and put something like this inside:

[dag] name=Dag RPM Repository for Red Hat Enterprise Linux
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
gpgcheck=1
enabled=1

BUT you also need to install a GPG key, and getting THAT can be a bit of a problem. Some instructions will tell you to do this:

rpm –import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

That link no longer works, and you have to do this instead:

rpm –import http://apt.sw.be/RPM-GPG-KEY.dag.txt

But for some people even THAT doesn’t work, in which case it’s suggested you use wget to obtain the file, then import it:

wget http://apt.sw.be/RPM-GPG-KEY.dag.txt
rpm –import RPM-GPG-KEY.dag.txt

I’m being a bit non-specific because the instructions could change, and I’d prefer you find a current reference on how to enable this repository. Also, some may prefer to install RPMforge, which is a collaboration of Dag and other packagers. Regardless of the effort involved, I do suggest you install phpMyAdmin using yum, because it will install everything in the correct locations for CentOS, and you don’t have to compile it or anything like that.

Note that when you do install phpMyAdmin using yum, it may also install required dependencies such as libmcrypt and php-mcrypt (another advantage to using yum).

• You don’t have permission to access /phpmyadmin/ on this server.

Go to /etc/httpd/conf.d/phpmyadmin.conf
Under the line:
Allow from 127.0.0.1
You could add a line to allow access from your local network, for example:
Allow from 192.168.0.0/255.255.255.0
(But use values appropriate to your network).

If you are accessing the box remotely, then add a line allowing access from your IP address. Be VERY careful, because you don’t want to let the entire world into your databases!

• Existing configuration file (./config.inc.php) is not readable.

If you’re doing this on a system running FreePBX, scroll down to where I discuss changing the ownership of all phpMyAdmin-related files and directories to be the same as the MySQL user. Otherwise, the easiest solution (though not necessarily the most secure) is to change the permissions of the file /usr/share/phpmyadmin/config.inc.php from the default of 640 to 644 (add user read permission). If no one can get to your system from outside your local network, this probably isn’t an issue, but if anyone has a better idea on this, feel free to leave a comment.

• “Error
The configuration file now needs a secret passphrase (blowfish_secret).”

Open /usr/share/phpmyadmin/config.inc.php and find this section:

* This is needed for cookie based authentication to encrypt password in
* cookie
*/
$cfg[‘blowfish_secret’] = ‘oh my this is such a wonderful passphrase‘; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */

Insert any phrase you like (within reason) between the second pair of single quotes in the last line shown above (but don’t use ‘oh my this is such a wonderful passphrase‘, I just inserted that as an example.  Be creative!).  Don’t worry, this isn’t something you’ll actually have to type in every time you want to use phpMyAdmin.

– Access denied for user ‘root’@’localhost’ (using password: YES)

You don’t login as root, you use your MySQL username and password. In FreePBX-based systems these can be found in /etc/amportal.conf, in the AMPDBUSER and AMPDBPASS settings. BUT… if you enter a wrong user name before logging in correctly, it may have already set a cookie with that username and password and then you won’t be able to get in even if you DO use the correct username and password. The solution is to clear all browser cookies for the address of your server, then try again — and make sure you get it right this time! 😉

I will note here that you can avoid some of these cookie-related issues, probably including those mentioned above, by going into /usr/share/phpmyadmin/config.inc.php and finding this section:

/* Authentication type */
$cfg[‘Servers’][$i][‘auth_type’] = ‘cookie’;

If your system is behind a hardware firewall or is otherwise VERY secure, you could change the auth_type from ‘cookie’ to something else, such as ‘http’. This will save you a lot of frustration during the login process, but at the possible expense of making your database less secure.  For those concerned about security, a document on the phpMyAdmin wiki advises you to “See the page on Security or the multi–user sub–section of the FAQ for additional information, especially FAQ 4.4.”  I personally found their security documentation rather useless, because they make a lot of suggestions but provide no specific examples of how to implement those suggestions.  Anyway, I personally feel that as long as a system is behind a good firewall that doesn’t permit anyone on the “outside” to access phpMyAdmin, ‘http’ is a good compromise between a security model that might drive you crazy (‘cookie’) and one of the other models that’s fairly insecure, such as ‘config’ (which some consider insecure because it stores your server username and password in plain text).  However, if your system is otherwise VERY secure and you just don’t want to have to enter a password to use phpMyAdmin, then it is possible to change the ‘auth_type’ to ‘config’ and (in the same config file), look for these lines:

/*
 * End of servers configuration
 */

And just above those lines, insert these lines:

$cfg[‘Servers’][$i][‘user’] = ‘mysqluser’;
$cfg[‘Servers’][$i][‘password’] = ‘mysqlpassword’;

Change mysqluser and mysqlpassword to the correct vales for your system (on a FreePBX-based system, these are the values in /etc/amportal.conf mentioned above).  I do not recommend using ‘config’ because it is less secure (be sure to read the page on Security mentioned above), but it’s up to you to decide how secure you want your system to be.

(I’m fully aware that any objections to storing the user and password values in plain text in the phpMyAdmin config.inc.php fall a bit flat when you realize the same values are stored in plain text in amportal.conf, but I also feel as though the fewer places those values are exposed, the better.  Why give potential attackers one more place to find this information?)

• phpMyAdmin – Error
Cannot start session without errors, please check errors given in your PHP and/or webserver log file and configure your PHP installation properly.

Check your /var/log/httpd/error_log – in my case, the first error message of each set contained a phrase like “open(/var/lib/php/session/sess_somerandomstring, O_RDWR) failed: Permission denied (13)” and I figured that the problem was another permissions issue.

On some sites I have found a suggestion that you change the ownership of all phpMyAdmin-related files and directories to be the same as the MySQL user (in the case of an Asterisk/FreePBX system, that would be asterisk:asterisk). On a FreePBX-based system, you could try this (check to make sure these are the correct paths before doing this):

chown asterisk:asterisk /usr/share/phpmyadmin -R
chown asterisk:asterisk /var/lib/php/session -R

If that doesn’t resolve the issue (or you’re doing this on a system that’s not running FreePBX), perhaps the easiest solution (though not necessarily the most secure) is to change the permissions of the offending file. If you have the same issue I had, try changing the permissions of the directory /var/lib/php/session from the default of 770 to 777 (add full user permissions).

Strangely, this one didn’t show up until after I’d successfully run phpMyAdmin a few times. Go figure. Also, after fixing this, I had to delete cookies again (as mentioned in the previous item) before I could log in, but that was when I still had the ‘auth_type’ set to ‘cookie’ (another reason I decided to change that to ‘http’).

Found and solved any other “gotchas” while installing phpMyAdmin under CentOS? Think I could have solved a problem in a better way? Feel free to share your solutions in the comments.

EDIT: There is one other thing that can happen after you install or update PHP on your system (as might happen if you let a FreePBX-based distribution do an upgrade).  You may start seeing PHP warning messages such as:

PHP Warning:  PHP Startup: mcrypt: Unable to initialize module
Module compiled with module API=20050922, debug=0, thread-safety=0
PHP    compiled with module API=20060613, debug=0, thread-safety=0
These options need to match
 in Unknown on line 0

If that happens try updating the dependencies that came with phpMyAdmin, for example:

yum update libmcrypt
yum update php-mcrypt

It was the second of those two that vanquished the PHP warning messages for me.

And why did I NEED to install phpMyAdmin, you ask?  Well, because someone (ahem) made a slight configuration error and caused an endless loop, that within the space of about ten seconds or so, generated over a THOUSAND bogus records in the ‘asteriskcdr’ (Call Detail) database.  The only easy way to I knew of at the time to clean them out was phpMyAdmin (since I don’t “speak” MySQL), but I don’t recommend you attempt something like that unless you know what you’re doing, because one wrong move and you could delete your entire FreePBX database (trust me, that would be a VERY bad thing!). In retrospect I probably could have used Webmin, since it also has the ability to access the MySQL database, but I didn’t think of that at the time.

Link: FreePBX security advisory – SIP extension types

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
We can set defaults for all these, so why not extension type?
We can set defaults for all these, so why not extension type?

The SysAdminMan blog has posted a new article related to FreePBX security, that I strongly urge you to read if you are running FreePBX or any FreePBX-based distribution:

FreePBX security advisory – SIP extension types

The basic issue is that by default, FreePBX sets extensions to type=friend rather than the more secure type=peer.  The article says it’s for historical reasons but I suspect there have been other reasons at play here (pure stubbornness, perhaps?).  But with the growing body of evidence that type=friend is bad, and because FreePBX now has an Advanced Settings module that allows you to to change certain defaults (though not yet this one), I have put in a Feature Request asking that system administrators be allowed to select a default type for extensions.  We’ll see if it goes anywhere (and it might help if anyone who supports this idea would add a comment to that ticket), but given that in the past they’ve been reluctant to even entertain the idea of changing the default, I fear that they may once again refuse to even consider it.  And for those of us who want to keep our systems as secure as reasonably possible, that would be a real shame.

Do you use Webmin to configure iptables and also run fail2ban? Don’t forget to do this!

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

For many Linux users this will be a “Thank you, Captain Obvious” type of post, but it’s one of those things that some Webmin users might not realize.  If you use Webmin’s “Linux Firewall” configuration page to configure the iptables firewall in Linux, and you click “Apply Configuration”, it will remove fail2ban‘s rules from your active iptables configuration.  So, you must go to a Linux command prompt and enter service fail2ban restart — UNLESS you make a small change in the Webmin “Linux Firewall” configuration.

From the Webmin “Linux Firewall” main page, click Module Config, then on the configuration page, in the “Configurable options” section, look for the line “Command to run after applying configuration.” Click the button next to the text box on that line, and in the text box enter service fail2ban restart and then click the Save button at the bottom of the page. That’s all you need — now every time you make a firewall change and click “Apply Configuration”, it will automatically restart fail2ban for you.

Fixing Midnight Commander’s unreadable dropdown menus

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

If you’ve installed Midnight Commander and haven’t changed the default colors, when you try to access a dropdown menu you may see this:

Midnight Commander — Original Colors

REALLY hard to read that menu, isn’t it? Wouldn’t you rather see this?

Midnight Commander — Changed Colors

To fix the unreadable menus, just make sure Midnight Commander is not open, then use any text editor (such as nano) to open ~/.mc/ini:

nano ~/.mc/ini

Assuming that there is no existing [Colors] section in the file, just add this at the bottom of the file (if the second line exceeds the blog column width, just use copy and paste to get it all):

[Colors] base_color=default,default:menu=black,cyan:menuhot=brightmagenta,cyan:menusel=white,blue:menuhotsel=brightmagenta,blue

If there is an existing [Colors] section, you can try tweaking it using the parameters shown above. If you have a very recent version of Midnight Commander (which you probably will have if you are running Ubuntu), then instead of menu= you’ll need to use menunormal=, as shown here:

[Colors] base_color=default,default:menunormal=black,cyan:menuhot=brightmagenta,cyan:menusel=white,blue:menuhotsel=brightmagenta,blue

Note that for some reason the base_color parameter must appear, or the other items are ignored. Save the change, exit the editor, and open Midnight Commander. If you then close Midnight Commander, you may find that the position of the [Colors] section has moved within the ini file — apparently Midnight Commander rewrites the file when you close it — but if you don’t like the changes you can remove the [Colors] section to reverse the change.

I figured out how to do this after reading this blog post:
Ajnasz Blog – Midnight Commander colors and themes
Another source of information is:
Zagura’s blog – Midnight Commander Color Themes

A Perl script to send Caller ID popups from Asterisk to computers running Notify OSD (such as Ubuntu Linux) or any command-line invoked notification system

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This is basically an update to my article, A Perl script to send Caller ID popups from Asterisk to computers running Growl under OS X on a Mac or Growl for Windows, and you should still use that article if you are sending notifications to a computer on your local network that runs Growl or Growl for Windows as the notification system.

I wanted to find a way to send Caller ID popups to a Ubuntu Linux box, and in the process I discovered a different method of sending such notifications.  There are pros and cons to using the new method, so let me explain those first:

Pros:

  • Can send notifications to any computer that supports command line generated notifications (so it could also be used with Growl, if you can use growlnotify from a command prompt to generate a notification).
  • Can send notifications to any computer that you can SSH into, provided you have it set up to use public/private key authentication rather than password authentication.

Cons:

  • Notifications typically display a couple of seconds later than under the previous method.  I suspect this is due to the SSH authentication taking a second or two.
  • It’s a little bit more complicated to set this up, though not horribly so.
  • Because this uses SSH and requires that Asterisk be granted permission to establish an SSH connection as the super user (by using sudo), there may be unforeseen security risks.

Read that last point again, and please understand that as with all projects on this site, I offer this for experimental purposes only.  I explicitly do not warrant this method as being 100% secure, nor will I tell you that it could not be exploited to do bad things on your system.  I don’t think it can (and feel free to leave a comment if you think I’m wrong), but I just don’t know that for sure.  So, if you decide to use anything in this article, you agree to assume all risks. If you’re the type that likes to sue other people when something goes wrong, then you do not have permission to use this code.  We’re all experimenters here, so no guarantees!

As with the previous method, you must have the Perl language installed on your Asterisk server, and you must have the Asterisk::AGI module installed (I’m going to assume you know how to install a Perl module from the CPAN repository – if you have Webmin installed, it can be done from within Webmin). Chances are you already have Asterisk::AGI installed, unless you built your Asterisk server “from scratch” and never installed it.

There’s one additional thing you must do on the Asterisk server before this will run, and that’s allow Asterisk to run the ssh command as root. So, add this to your /etc/sudoers file (probably at the very end, but in any case it should be obvious where to add this because it will be in a section where Asterisk is granted similar privileges with regard to other programs):

asterisk ALL = NOPASSWD: /usr/bin/ssh

Next you want to copy and paste the following Perl script to the filename /var/lib/asterisk/agi-bin/notifysend.agi on your Asterisk server (to create a non-existent file, you can use the touch command, and after that you can edit it in Midnight Commander or by using the text editor of your choice). If this code looks somewhat familiar, it’s because it’s adapted from some code that originally appeared in a FreePBX How-To, which I have modified.

#!/usr/bin/perl
use strict;
use warnings;
use Asterisk::AGI;
my $agi = new Asterisk::AGI;
my %input = $agi->ReadParse();

# Next two lines fork the process so Asterisk can get on with handling the call
open STDOUT, '>/dev/null';
fork and exit;

my $num = $input{'callerid'};
my $name = $input{'calleridname'};
my $ext = $input{'extension'};
my $user = $ARGV[0];
my $ip = $ARGV[1];

if ( $ip =~ /^([0-9a-f]{2}(:|$)){6}$/i ) {
    $ip = $agi->database_get('growlsend',uc($ip));
}

# OMIT this section if you don't want IP address
# checking (e.g. you want to use foo.bar.com)
unless ( $ip =~ /^(d+).(d+).(d+).(d+)$/ ) {
    exit;
}

if ( $ARGV[2] ne "" ) {
 $ext = $ARGV[2];
}

my @months = (
    "January", "February", "March", "April", "May", "June",
    "July", "August", "September", "October", "November", "December"
);
my @weekdays = (
    "Sunday", "Monday", "Tuesday", "Wednesday",
    "Thursday", "Friday", "Saturday"
);
my (
    $sec,  $min,  $hour, $mday, $mon,
    $year, $wday, $yday, $isdst
) = localtime(time);
my $ampm = "AM";
if ( $hour > 12 ) {
    $ampm = "PM";
    $hour = ( $hour - 12 );
}
elsif ( $hour eq 12 ) { $ampm = "PM"; }
elsif ( $hour eq 0 )  { $hour = "12"; }
if ( $min < 10 ) { $min = "0" . $min; }
$year += 1900;
my $fulldate =
"$hour:$min $ampm on $weekdays[$wday], $months[$mon] $mday, $year";

# Next two lines normalize NANP numbers, probably not wanted outside of U.S.A./Canada/other NANP places
$num =~ s/^([2-9])(d{2})([2-9])(d{2})(d{4})$/$1$2-$3$4-$5/;
$num =~ s/^(1)([2-9])(d{2})([2-9])(d{2})(d{4})$/$1-$2$3-$4$5-$6/;

my $cmd = qq(./remotenotify.sh "$name" "$num calling $ext at $fulldate");
$cmd = "sudo ssh $user@$ip '$cmd'";
exec "$cmd";

Also, if you want to be able to specify computers that you wish to send notifications to using MAC addresses rather than IP addresses (in case computers on your network get their addresses via DHCP, and therefore the IP address of the target computer can change from time to time), then you must in addition install the following Perl script (if you have not already done so when using the previous method). Note that if you have a mix of computers on your network and you are using both the new and old methods, you only need to do this once — it works with both methods (hence the reference to “growlsend” in the database and “gshelper” as the name of this script). Call it /var/lib/asterisk/agi-bin/gshelper.agi and note that there is a line within it that you may need to change to reflect the scope of your local network:

#!/usr/bin/perl
use strict;
use warnings;
my ($prev, @mac, @ip);
# Change the 192.168.0.0/24 in the following line to reflect the scope of your local network, if necessary
my @nmap = `nmap -sP 192.168.0.0/24|grep -B 1 MAC`;
foreach (@nmap) {
    if (index($_, "MAC Address:") >= 0) {
        @mac = split(" ");
        @ip = split(" ",$prev);
        `/usr/sbin/asterisk -rx "database put growlsend $mac[2] $ip[1]"`;
    }
    $prev=$_;
}

Make sure to modify the permissions on both scripts to make them the same as other scripts in that directory (owner and group should be asterisk, and the file should be executable), and if you use the gshelper script, make sure to set up a cron job to run it every so often (I would suggest once per hour, but it’s up to you).

Now go to this page and search for the paragraph starting with, “After you have created that file, check the ownership and permissions” (it’s right under a code block, just a bit more than halfway down the page) and if you are using FreePBX follow the instructions from there on out (if you are not using FreePBX then just read that section of the page so you understand how this works, and in any case ignore the top half of the page, it’s talking about a different notification system entirely). However, note that the syntax used in extensions_custom.conf differs from what is shown there, depending on whether you are specifying an IP address or a MAC address to identify the target computer.

First, if you are specifying the IP address of the target computer, then instead of using this syntax:

exten => ****525,1,AGI(growlsend.agi,192.168.0.123,GrowlPassWord,525)

You will need to use this:

exten => ****525,1,AGI(notifysend.agi,username,192.168.0.123,525)

Note that username is the account name you use when doing an ssh login into the destination system, and it should also be the desktop user on the system (not root!). Let’s say that the system is currently at IP address 192.168.0.123. In order for this to work, you need to be able to ssh into your Ubuntu box from your Asterisk server, using the following command from the Asterisk server’s command line:

ssh username@192.168.0.123

If it asks for a password, then you need to follow the instructions at Stop entering passwords: How to set up ssh public/private key authentication for connections to a remote server, and get it set up so that it will not ask for a password (if you don’t like my article, maybe this one will make it clearer).

It’s probably easiest to configure each computer that is to receive notifications to use a static IP address. But note that if you use the above code and have the gshelper.agi program running as a cron job, then after the first time it has run while the computer to receive the notifications is online you should be able to use a computer’s MAC address instead of the IP address. This only works if you’ve used the modified script on this page, not the one shown in the FreePBX How-To. As an example, instead of

exten => ****525,1,AGI(growlsend.agi,192.168.0.123,GrowlPassWord,525)

as shown in the example there, you could use

exten => ****525,1,AGI(notifysend.agi,username,01:23:45:AB:CD:EF,525)

(the above is all one line) where 01:23:45:AB:CD:EF is the MAC address of the computer you want to send the notification to. Once again, just in case you missed it the first time I said it, this won’t work until the gshelper.agi script has been run at least once while the computer to receive the notifications was online. If for some reason it still doesn’t appear to work, run the nmap command (from gshelper.agi) including everything between the two backticks (`) directly from a Linux command prompt and see if it’s finding the computer (depending on the size of your network, it might be several seconds before you see any output, which is why I don’t try to run this in real time while a call is coming in).

If you are NOT running FreePBX, but instead writing your Asterisk dial plans by hand, then you will have to insert a line similar to one of the above examples into your dial plan, except that you don’t need the four asterisks (****) in front of the extension number, and if it’s not the first line in the context, you’ll probably want to use n rather than 1 for the line designator (and, you won’t be putting the line into extensions_custom.conf because you probably don’t have such a file; instead you’ll just put it right in the appropriate section of your dial plan). In other words, something like this (using extension 525 as an example):

exten => 525,n,AGI(notifysend.agi,username,192.168.0.123,525)

This line should go before the line that actually connects the call through to extension 525. I do not write Asterisk dial plans by hand, so that’s about all the help I can give you. And if you don’t write your dial plans by hand, but you aren’t using FreePBX, then I’m afraid you’ll have to ask for help in whatever forum you use for advice on the particular software that you do use to generate dial plans, because I can’t tell you how to insert the above line (or something like it) into your dial plan.

Now is where it gets just a bit more complicated than in the original method. If you have followed the above instructions, you’ll be able to send the notifications to the remote system using SSH, but there will be nothing there to receive them. So we have to create a small script on the receiving system to do something with the received notifications. That script will vary depending on the receiving system, but it must be named remotenotify.sh and it must be placed in the destination user’s home directory, and don’t forget to make it executable! Here’s one that will work in most Ubuntu installations that have Notify OSD installed:

export DISPLAY=:0
notify-send --urgency="critical" --icon="phone" "$1" "$2"

Those two lines are all you need. On a different type of system (or if you have multiple displays) you may need to or wish to do something different. For example, as I mentioned above, if the destination system is running Growl then your remotenotify.sh script will need to call growlnotify, but beyond that I wouldn’t know what to use there (EDIT: But if the target system is a Mac that is running OS X, a pretty good guess would probably be that you’d only need one line, something like this:

growlnotify -s -p 1 -a Telephone -m "$2" $1

In this case it should make the notification sticky until dismissed by the user, give it a priority of 1 — the default is 0 — and use the application icon from the “Telephone” application if you have it installed. Instead of -a to specify an application’s icon you could use -I followed by a path to an .icns file that contains an icon you want to use.  Type growlnotify –help to see all the growlnotify options.  Oh, and before you can make an SSH connection to a Mac you have to go into System Preferences | Sharing and turn on Remote Login).

The beauty of this approach is that you can make the remotenotify.sh script as simple or as complicated as you need — you could even make it forward a notification to other devices if you wish, but figuring out how to do that is up to you (if you come up with something good, please leave a comment and tell us about it!).

If you’re running Ubuntu on the target system, here’s a few articles you may wish to use to help you get your notifications to look the way you want them to appear:

Tweak The NotifyOSD Notifications In Ubuntu 10.10 Maverick Meerkat [Patched NotifyOSD PPA Updated]
Get Notifications With A Close Button In Ubuntu
Configurable NotifyOSD Bubbles For Ubuntu 11.04: Move, Close On Click, Change Colors And More

If you want to be able to review missed notifications, you may be able to use this (as a side note, why don’t they have something like this for Growl?):

Never Miss A NotifyOSD Notification With “Recent Notifications” GNOME Applet

The idea behind the shell script that runs on the target system was found in a comment on the following article, which may be of special interest to MythTV users:

Send OSD notification messages to all systems on a network

There are links to other original sources throughout the article, so feel free to follow those if you want more in-depth commentary.

How to export Outbound Route Dial Patterns and Trunk Dialed Number Manipulation Rules to a CSV file in FreePBX

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

If you use a recent version of FreePBX, you are familiar with the new and tedious method of entering Outbound Route Dial Patterns and Trunk Dialed Number Manipulation Rules.  Fortunately, version 2.9 and above offer a way to import a list of patterns from a CSV file (there’s a way to patch FreePBX 2.8 to get this functionality as well — see Ticket #4691).

What they don’t give you is a way to export a list of patterns once you have them installed.  So if you want to clone a route and you’ve lost your original CSV file (or never had one to begin with because FreePBX converted your existing routes and trunks when you upgraded from version 2.7), what do you do?  Fear not, because it actually is possible, if not exactly the most straightforward process.

EDIT: Now there is an easy way around all this — see this thread on the FreePBX Swiss Army Knife Module.  If you use that module, you don’t need to read the rest of this article (although, you might be interested in the part about editing CSV files). Unfortunately, it is reported that the module does not work with FreePBX 2.10 or above, and the author has said he will not fix it to work with newer versions. It is possible that the ability to export outbound route and trunk data to a CSV file may be present in the newest version(s) of FreePBX.

EDIT: Steps 1 and 2 involve using a Database editor module to export the data to a CSV file.  Unfortunately, one commenter says that this module no longer works with FreePBX 2.9.  There are other ways to accomplish the same thing — see the edit at the end of this article to use Webmin or phpMyAdmin instead of the Database editor module.  If you export the data using one of those other programs, then skip to step 3 below.

Step 1: Go to the FreePBX bug tracker and look for Ticket #4793 — Database editor module (like phpMyAdmin for FreePBX).  On that page you’ll find a download link for dbeditor-1.0.tgz which (at the time of this writing) is the only version of this software available. Download and install it as you would any third-party module (download it to your computer, then in FreePBX’s GUI navigate to Module Admin and then click the “Upload Module” link, then upload the module and follow the directions to complete the install).

Step 2: Once you have the Database Editor installed, it will appear under the FreePBX “Tools” tab, in the “System Administration” section. Click on the “Database Editor” link, and you should see a list of database tables used by FreePBX. The two you are interested in are called outbound_route_patterns and trunk_dialpatterns. Near each pattern name you will see two links for “Export” and “Drop” — do not click either of those (especially be careful not to click drop!), because the “Export” here will export the table in MySQL format, which is not what you want. Instead, click on the name of the table (that is, click on either outbound_route_patterns or trunk_dialpatterns) and a new page will open. Near the top of the page you will see a place where it says, “Export to CSV: pipe – tab – comma – semicolon” — click on comma and it should bring up a file save dialog that will let you save the file to your system.

Step 3. Load the downloaded file into any text editor that can deal with Linux/Unix-style line endings and not change them (so, don’t use Notepad!), or better yet, use a CSV editor if you have one (an excellent free one is CSVed, which runs under Windows but will also install and run under CodeWeavers’ CrossOver on a Mac, which tends to make me think it would probably also run under WINE on a Linux or Mac OS X computer). I do NOT recommend opening the file in a spreadsheet application such as Excel, because if you have any patterns that start with one or more leading zeroes, those might be removed, and it’s also possible that any non-numeric characters may be misinterpreted or removed.

The first number in each line is associated with a particular outbound route or trunk, so, you want to cut out the lines not applicable to the route or trunk you want to keep. Don’t erase the top (header) line. If you have many routes or trunks, it may be a bit tricky to figure out which is which, since the numbers don’t tell you the name of the route or trunk they are associated with.

Deleting columns using CSVed

After you do that, you also have to get rid if the first column in each line. So let’s say you are using route 3, and each line starts with 3,. What you want to do is a search and replace on <newline>3, (or expressed as a regular expression: n3,) and replace it with a newline only (n as a regular expression). In a CSV editor you may be able to just delete the first column. For a trunk, the principle is the same except that you will need to remove the first AND last columns, leaving only the middle three.

While you’re at it, it’s also possible to use search and replace in other ways. For example, if you are duplicating list of outbound route patterns but need to change the extension field pattern in all lines, you could do that using search and replace, if you understand what you’re doing.

Step 4. Once you have edited out all the lines except the ones pertaining to the route or trunk you want, you need to change the header line at the top. It’s important to get this right. For an outbound route you want to change it from this:

route_id,match_pattern_prefix,match_pattern_pass,match_cid,prepend_digits

(Note that the route_id may be missing after the previous edit) to this:

prefix,match pattern,callerid,prepend

Visually inspect the lines following the header to make sure you have four fields separated by exactly three commas.

For a trunk, you will need to change the first header line from this:

trunkid,match_pattern_prefix,match_pattern_pass,prepend_digits,seq

(Note that the trunkid and seq may be missing after the previous edit) to this:

prefix,match pattern,prepend

Visually inspect the lines following the header to make sure you have three fields separated by exactly two commas. Also, and this applies to trunks only, if it is important that trunk dial patterns be in a particular order then you will want to check to make sure they are in the correct order in the CSV file, since the “seq” column is not preserved. In many situations this is not an issue but in certain special cases the order of trunk dial patterns can make a difference in how they are processed.

Step 5: Save the modified file to a file with the .csv extension (if using a CSV editor make sure you are saving in comma-delimited format). Again, try to make sure your editor doesn’t change the line endings – I don’t know for certain that it would make a difference, but it might.

Step 6: Now you can create a new route or trunk, and in the “Dial patterns wizards” or “Dial Rules Wizards” dropdown select “Upload from CSV” and select your file to upload. Note that if you are using a beta version of FreePBX 2.9, it may complain if you try to submit an outbound route with no patterns, even if you are uploading a CSV file. In that case, just put a single “X” in the “match pattern” field. After you submit changes, be sure to scroll through the patterns to make sure they appear to be correct. In particular, make sure that all values are in the correct fields.

There are probably other ways to accomplish this, and maybe eventually the FreePBX developers will add an export function on the route and trunk pages (obviously, it would probably not be a good idea for me to request it, and besides, it appears that someone already has).

EDIT:  Here is a way to export the data using Webmin or phpMyAdmin (replacing steps 1 and 2 above).  Use Webmin if you have it, because it produces cleaner output:

If using Webmin, from the main Webmin page, go to “Servers”, then “MySQL Database Server.”  Under “MySQL Databases”, click on “asterisk”, and it should take you to the “Edit Database” page (be very careful from here on out because if you do the wrong thing you could really mess up your system).  In the “Edit table” dropdown, select either outbound_route_patterns or trunk_dialpatterns, depending on which you want to work with.  That should take you to an “Edit table” page, but at the bottom of that page you should see a button labeled “Export as CSV.” Click on that button, and it will take you to a “CSV export options” page.  You want to select the following:

  • CSV with quotes
  • Yes to “Include column names in CSV?”
  • For export destination, use whichever is more convenient for you (note that if you “Save to file” it will be placed in a directory on your server, so you might find it easier to display it in a browser window and then save it from there).
  • Export all rows
  • Leave all columns selected in “Columns to include in CSV” (you’ll discard the first column in step 3, but you’ll still need it to allow you to determine which rows to keep for each route or trunk)

Then click the “Export Now” button.  If you exported to a browser window, use Ctrl-A to select all the lines, and Ctrl-C to copy them (⌘A and ⌘C on a Mac), then proceed with Step 3 above (except use Ctrl-V or ⌘V to paste the lines into the text editor). Or, if you prefer to use a CSV editor, then in your browser simply go to File | Save Page As… and save the entire page as a plain text file with a .csv extension to your local machine, and then proceed with Step 3 above.

If using phpMyAdmin, from the main page select “asterisk” in the left-hand column, then (still in the left-hand column) either outbound_route_patterns or trunk_dialpatterns, depending on which you want to work with. Then click the “Export” tab in the main window, and then under “View dump (schema) of table”, in the “Export” section select CSV.  The view should change to show an “Options” section, and there you want to change “Fields terminated by:” from a semicolon to a comma, and then check the “Put fields names in the first row” checkbox.   Then click the “Go” button and it should display the data in a format that can be copied and pasted into a text editor. Sorry, that’s the best I can advise you with regard to phpMyAdmin, since I seldom use that program (and I may have an older version, so things might have changed slightly).

Link: Monit: Disk space monitoring

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This article was originally posted in February, 2011 and may be out of date. You may also wish to read Link: How to Install and Setup Monit (Linux Process and Services Monitoring) Program.

A hard disk drive with the platters and motor ...
Image via Wikipedia

Here’s an article that will be helpful to may of you who are running PBX servers under CentOS, especially (but not limited to) those running on virtual machines with low disk storage space.  Note that if you installed from an “all-in-one” distribution ISO, this possibly might already be installed, but may still need to be configured.

One thing you definitely don’t want to happen to your server is for it to run out of disk space, especially the root partition.

There are lots of pieces of open source monitoring software, a popular one being monit.

Below is a quick guide to installing monit and generating alert e-mails for disk space and cpu/memory usage. The installation was done on a SysAdminMan VPS running CentOS 5.5

Full article here (SysAdminMan)

The instructions should work for any system running CentOS 5.5.  You might be tempted to take a shortcut and just do “yum install monit” but please be aware that (at least as of the day I’m writing this) it will get you a much older version of the software, so I suggest you stick with the instructions in the article.  I have just now installed this on one system and have not fully tested it, but it did send an e-mail confirming that it had started.

This is just another tool you can use to make your life a little easier and help you avoid a problem before it becomes a major headache!

Recent Posts

Recent Comments

Archives

Categories

Meta

GiottoPress by Enrique Chavez