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.
Slate has reprinted the piece that Ron Rosenbaum wrote for Esquire in 1971, explaining to the world that there was an underground movement of people hacking the phone system. (Rosenbaum is now a columnist for Slate.) According to the article’s new introduction and followup piece by Rosenbaum reflecting on its impact — and to the New York Times obituary for Steve Jobs — this article inspired Jobs and Wozniak to start building blue boxes themselves, an effort that made them several thousand dollars.
It has been reported (though I can’t recall the source at the moment) that this is the article that caused AT&T to turn its employees into common thieves. The idea that people might have access to this information frightened them so much that they literally sent their people out to steal the copies of this issue of Esquire from every public library in the country (of course they missed a few). Although this was long before the days of the Internet and the “Streisand effect“, it did have the result that those who had access to the article had a tendency to photocopy it and pass it around, so AT&T’s ham-fisted attempt at censorship probably gave the article far more exposure than it ever would have had in the first place.
I would daresay that one article probably had a significant effect on our modern way of life. For one thing, it taught us that “security through obscurity” doesn’t work, and for another it forced AT&T and other phone companies to modernize their phone networks (probably much earlier than they would have otherwise intended) to prevent the type of “toll fraud” made possible by the blue box, and that made it much easier for alternative long distance carriers to offer their services.
Although I never had the technical skills to build a blue box, I definitely wanted to know how they worked. The copy of Esquire at my local library had already gone missing but I discovered they still had a copy at the Grand Rapids public library. Apparently the librarians there had apparently been tipped off about AT&T’s attempts to make that issue disappear, so they were keeping it behind the desk and you had to request it from a librarian. Which I did, and then promptly asked where the photocopy machine was. The librarian looked me over and said, “You’re not going to copy that article, are you?” and I said, “Oh, yes I am!” She clearly disapproved, but still pointed me in the direction of the copier (the alternative would have been to attempt to forcibly pry the magazine back out of my hands!). That copy of the article went back home with me and got shared with a few interested friends, and at least two of them later got jobs in the telecommunications field.
Of course, nowadays it would be a simple task for any modern computer to generate the same multifrequency tomes that blue boxes generated, but the last telephone company in the country to actually use that signaling method dropped it on June 15, 2006. And now we have computers and the Internet and VoIP, but I have a feeling that much of that might still not be in existence had it not been for that one article, which literally gave birth to an entire community of hackers, many of whom later went on to do great things and to build the networks we have today. It’s funny how one thing that seems so small at the time — in this case, one magazine article — can create such ripples throughout society.
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 run Asterisk you may have encountered this issue: Your Internet connection goes down, and so does your ability to call from extension to extension, even between extensions on your local network. This is a long-standing bug in Asterisk (exactly the sort of bug that drives people to try alternatives such as FreeSWITCH) but let’s say that for whatever reason you need to stick with Asterisk, so you’d like to find a way to make that bug go away. Without going into all the technical details, the reason that calls fail is that Asterisk can’t access a DNS server. I’ve read several reports that say the easiest solution is to install the BIND DNS server on the same machine as your Asterisk server. If you are also running Webmin on the server, installing and configuring BIND is a relative piece of cake. So here’s how it’s done. Please note that most of the images below can be enlarged by clicking on them, and that I have installed the StressFree theme in Webmin, so if it looks a little different from what you’re used to seeing, that’s probably why.
To start with, log into Webmin, click on “Servers”, then click on “BIND DNS Server” (if you don’t find it there, try looking in “Un-used Modules”):
Webmin Servers page — click on "BIND DNS Server"
Assuming you have not previously installed BIND, you’ll get a screen like this. Just click where it says “Click here”:
Webmin BIND DNS Server error page — click where it says "Click here"
You will then see this screen come up as BIND is installed. Just let it run to completion and (assuming it installs successfully) click on “Return to BIND DNS Server” at the bottom of the page:
Webmin "Install Package" page — click on "Return to BIND DNS Server"
Next, because you don’t yet have an /etc/named.conf file, you’ll see this page. Click the button for “Setup nameserver for internal non-internet use only” (don’t worry, we’ll fix it in the next steps), then click the bar that says “Create Primary Configuration File and Start Nameserver”:
Webmin — click "Setup nameserver for internal non-internet use only"
At this point BIND is installed and running, but it probably isn’t doing what you want it to, and your system isn’t using it. So the first thing we need to do is tell it where to go when it needs to do a DNS lookup. You should be seeing a page that looks like this — click on “Forwarding and Transfers”:
Webmin BIND DNS Server page — click on "Forwarding and Transfers"
When you get to the following screen, check “Yes” next to “Lookup directly if forwarders cannot?” You also need to enter one or more addresses of DNS servers that BIND can access when it needs to pull a DNS record. You might want to give some thought to which DNS servers you want to use, and in what order, before you start entering them. You can enter up to three IP addresses of DNS servers, and then click “Save”. This will throw you out to the previous screen, and if by some chance you want to enter even more DNS servers, you can click on “Forwarding and Transfers” again to come back and enter up to three more servers, until you are finished. In this example, I have already entered the IP addresses of my router’s DNS Server as the top priority pick, followed by two Google DNS Server addresses.
Webmin — BIND DNS Server — Forwarding and Transfers page
Once you have done this, you are through configuring BIND directly, but there are two more things we need to do. The first is to make sure that the BIND server starts each time we restart the machine. To do that, go to Webmin’s “System” page and then click on “Bootup and Shutdown”:
Webmin System page — click on "Bootup and Shutdown"
This is a long page so I’m not showing all of it — what you have to do is find the entry for named and check the box next to it:
Webmin Bootup and Shutdown page — check the box next to "named"
Then go to the bottom of the page and click “Start on Boot”:
Bottom of Webmin Bootup and Shutdown page — click "Start on Boot"
At this point BIND is running, and should be using the correct DNS servers, and is set to start at bootup, but your server still isn’t using it for its DNS queries. To get it to do that, go to Webmin’s “Networking” page and click on “Network Configuration”:
Webmin Networking page — click on "Network Configuration"
Once on the Network Configuration page, click on “Hostname and DNS Client”:
Webmin Network Configuration page — click on "Hostname and DNS Client"
Once on the Hostname and DNS Client page, what you need to do is make the first entry in the DNS Servers list 127.0.0.1. If you trust BIND to always be operating, that’s the only entry you need. I didn’t quite trust BIND that much (actually, what I didn’t trust was my ability to set this up correctly) so I set the DNS server in the router as the secondary DNS address. You could use any DNS server as the secondary, or you could choose to just enter the 127.0.0.1 address to use BIND and let it go at that. Personally, I feel a lot more comfortable having a “fallback” DNS. Don’t forget to click “Save” when you are finished making changes here:
Webmin Hostname and DNS Client page - 127.0.0.1 must be first DNS server
That’s all there is to it, as far as I know (if you think I’ve missed anything or done something wrong, the comment section is open!). If you’re like me, the next question you will have is, “How do I know it’s working?” And the easiest way to do that is to go to a Linux command prompt and “dig” some site you have not been to recently twice in a row. Here’s an example, using cnn.com — the part we are interested in is in red:
;; ANSWER SECTION: cnn.com. 287 IN A 157.166.224.25 cnn.com. 287 IN A 157.166.224.26 cnn.com. 287 IN A 157.166.226.25 cnn.com. 287 IN A 157.166.226.26 cnn.com. 287 IN A 157.166.255.18 cnn.com. 287 IN A 157.166.255.19
;; AUTHORITY SECTION: . 76691 IN NS i.root-servers.net. . 76691 IN NS j.root-servers.net. . 76691 IN NS k.root-servers.net. . 76691 IN NS l.root-servers.net. . 76691 IN NS m.root-servers.net. . 76691 IN NS a.root-servers.net. . 76691 IN NS b.root-servers.net. . 76691 IN NS c.root-servers.net. . 76691 IN NS d.root-servers.net. . 76691 IN NS e.root-servers.net. . 76691 IN NS f.root-servers.net. . 76691 IN NS g.root-servers.net. . 76691 IN NS h.root-servers.net.
;; ADDITIONAL SECTION: b.root-servers.net. 386178 IN A 192.228.79.201 d.root-servers.net. 402826 IN A 128.8.10.90 d.root-servers.net. 230000 IN AAAA 2001:500:2d::d f.root-servers.net. 370827 IN A 192.5.5.241 g.root-servers.net. 463754 IN A 192.112.36.4 h.root-servers.net. 374116 IN A 128.63.2.53 h.root-servers.net. 517382 IN AAAA 2001:500:1::803f:235 j.root-servers.net. 185528 IN A 192.58.128.30 j.root-servers.net. 578747 IN AAAA 2001:503:c27::2:30
;; ANSWER SECTION: cnn.com. 223 IN A 157.166.255.19 cnn.com. 223 IN A 157.166.224.25 cnn.com. 223 IN A 157.166.224.26 cnn.com. 223 IN A 157.166.226.25 cnn.com. 223 IN A 157.166.226.26 cnn.com. 223 IN A 157.166.255.18
;; AUTHORITY SECTION: . 76627 IN NS c.root-servers.net. . 76627 IN NS d.root-servers.net. . 76627 IN NS e.root-servers.net. . 76627 IN NS f.root-servers.net. . 76627 IN NS g.root-servers.net. . 76627 IN NS h.root-servers.net. . 76627 IN NS i.root-servers.net. . 76627 IN NS j.root-servers.net. . 76627 IN NS k.root-servers.net. . 76627 IN NS l.root-servers.net. . 76627 IN NS m.root-servers.net. . 76627 IN NS a.root-servers.net. . 76627 IN NS b.root-servers.net.
;; ADDITIONAL SECTION: b.root-servers.net. 386114 IN A 192.228.79.201 d.root-servers.net. 402762 IN A 128.8.10.90 d.root-servers.net. 229936 IN AAAA 2001:500:2d::d f.root-servers.net. 370763 IN A 192.5.5.241 g.root-servers.net. 463690 IN A 192.112.36.4 h.root-servers.net. 374052 IN A 128.63.2.53 h.root-servers.net. 517318 IN AAAA 2001:500:1::803f:235 j.root-servers.net. 185464 IN A 192.58.128.30 j.root-servers.net. 578683 IN AAAA 2001:503:c27::2:30
Notice how on the first run, it takes 26 msec to do the lookup, because BIND doesn’t have that address cached yet, whereas on the second run it only takes 1 msec to do the lookup! Could that perhaps improve system performance? I’ll bet it could! And the SERVER line tells us that it is indeed using our BIND server (127.0.0.1) – if it were using, say, our router’s DNS server then that line would show this:
;; SERVER: 192.168.0.1#53(192.168.0.1)
The idea here is that when your Internet connection takes a dive, Asterisk will still be finding a working DNS server and therefore won’t tank. That, at least, is the theory I’ve seen on several web sites. The ONLY thing I am showing here is how to set up BIND using Webmin, and I won’t even guarantee that I’m doing that 100% correctly. I definitely do not guarantee that it will actually work as intended — you’ll have to test that yourself. Doing a real test would mean disconnecting your cable or DSL modem, etc. from your router for several hours or days to see if the phones continue to work, and in most households or businesses that idea will go over like a lead balloon. However, feel free to give it a good test if you like and report the results in the comments.
You may wonder why I selected “Setup nameserver for internal non-internet use only” in the fourth screenshot. Obviously, that description is not entirely accurate. The real difference is that if you select that instead of the default “Setup as an internet name server, and download root server information”, it won’t create a “root” DNS zone, which you simply don’t need for this application. You can use the other option if you want to, but it will download additional information and increase the complexity of your setup. Either way, you should be able to access the Internet, because we set up DNS forwarding. If by some chance this BIND server is going to act as a nameserver for your entire network, and you don’t mind the additional traffic and complexity (and it’s the additional traffic that scares me the most, since I have no idea what it’s actually downloading nor how often it’s doing it), then by all means feel free to use the second option. All I will say is that I used the first. and it works fine, and I’ve seen at least one instance where this same thing is set up using a method other than Webmin, and except for the order of statements it uses an /etc/named.conf file that is identical to what Webmin produces when configured as I have shown here (in other words, no “zones” at all). I’m just waiting for some Linux purist to say this isn’t the “right” way to do this but keep the goal in mind here — all we are trying to do is work around a bug in Asterisk that should have been fixed years ago, not set up a DNS server to feed an entire subnet. But again, you can feel free to use whichever of the options you like — it should work either way.
(By the way, if after reading the above you have “setup remorse” — you know, that feeling you get after you’ve installed something that you should have picked a different option — you can get a “do-over” by simply deleting or moving/renaming /etc/named.conf. If you then exit Webmin’s BIND module and come back in, it should see that named.conf doesn’t exist and start you over at the fourth screen shown above. Of course, you will lose anything you have already configured from within that module. If you originally selected the option to download the root server information, I think that’s at least partly stored in the file /etc/db.cache, so you could move or remove that file to make sure it’s not used, however I’m not sure if any other files are or were also downloaded. That particular file is very small so I’m not worried about that one per se, it’s just that the way things are worded on a couple of pages I read, I don’t know if that’s all it downloads, or if at some point in the middle of the night it rises up and tried to cache all the DNS information for the Internet, or just exactly what it does. Sometimes I wish people would just give a sentence or two of additional information, so you have a better idea of what’s the right thing to do when you’re setting up something like this.)
Now, if you are a True Linux Geek who somehow stumbled across this article, and are disappointed that it isn’t much more complicated, I’ll refer you to this page. If you can figure all THAT out, you should be getting paid the big bucks as the networking expert that you are! 🙂
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.
Image via Wikipedia
Here’s a program that may be useful for those of you who, like me, sometimes find ourselves at a Linux command prompt trying to recall the syntax of a command we use frequently (because, you know, it would never have occurred to the designers of Linux to actually implement commands with names that have a clear meaning in plain English):
Alias are a great tool to help increment your productivity on the terminal with bash (or any shell program you’re using), but usually we are too lazy to think at what are the most common, or long commands that we use frequently and prepare an alias for them.
And so someone has done a small piece of software to do this job: aliaser
Aliaser helps you identify frequently typed commands and creates bash aliases for them. Aliaser analyses your bash history and helps you identify commands that you use frequently.
One thing they forgot to mention is that once you’ve added an alias, it won’t actually be available for use until you log out and then log back in. Also, you can delete the aliaser file and temporary directory from your /tmp directory once installation is complete. If you ever want to uninstall aliaser, just remove the three lines added to your .bashrc file, remove the ~/.aliaser directory, and remove the /usr/bin/aliaser file.
One way I find this useful is to make commands I can’t remember into ones that that I can remember. For example, I did this:
aliaser add processes “ps awx”
The Linux purists are probably rushing to comment that I just turned a six character command into a nine character one. Yes, BUT, I can actually remember the word “processes”, whereas I cannot remember the options I need to use after “ps” to get the output I want. The designers of Linux seem to not realize that some of us users have really bad memories. Another use for this is turning arcane Linux commands into the equivalent Windows commands that you’re familiar with. You could do this:
aliaser add dir “ls -al”
So that when you type “dir”, you get a directory listing similar to what you are used to.
If you can’t even remember the aliases you’ve created (yeah, my memory really is that bad some days), just use aliaser show to see all the aliases you’ve added.
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.
Dial Patterns section of new FreePBX Outbound Route
IMPORTANT: When implementing any sort of restrictions on extensions, using the method described here or any other method, please be absolutely certain that you do not inadvertently restrict access to emergency services numbers (such as 911 in the U.S./Canada)!
There is a recurring question that comes up every so often, regarding how to give one particular extension (or a group of extensions) access to a different trunk for specific outgoing calls, or perhaps to restrict access to a particular trunk. Usually this involves an extension that is accessible to people that might want to make calls that cost money, and you don’t want them to do that. But there are many other reasons to route calls differently for different extensions, while still keeping all extensions on the same system so they can call each other.
Usually when someone asks about this, a common suggestion is to use the unsupported third-party Custom Contexts module. While this module is very versatile and lets you have a high degree of control over what each extension may access, there are at least two downsides. One is that it’s not part of the official distribution and therefore, a future upgrade of FreePBX might “break” it.
(This is probably less likely now, because it appears some of the FreePBX developers have taken an interest in maintaining it, but it’s still not beyond the realm of possibility.)
The other issue is that you have to go through and check (and maybe change) all the priority dropdowns if you add, remove, or move a route, and that can get to be a pain in the butt very quickly if you are in the habit modifying your routes with any frequency.
The problem with this page is that although it discusses several alternatives to using Custom Contexts (and you may wish to read it just to learn about those other possibilities), it is getting rather dated and therefore does not mention the use of the fourth field in Outbound Routes, a.k.a the “CallerID” field, which is by far the easiest way to implement this.
Let’s say you have an existing outbound route, over which your outbound calls normally travel, and it has a particular selection of trunks. But you also have an extension, let’s say it’s extension 234, and you want it to use a different trunk or group of trunks. In FreePBX 2.9 or later, all you have to do is this:
Go to the settings page for the Outbound Route that is currently used for outgoing calls.
At the bottom of the page, next to the “Submit Changes” button, there is a new “Duplicate Route” button. Click on “Duplicate Route”.
Move the duplicated route to be higher in priority than the original route (it should appear just above the original route in the right-hand column).
Optionally rename the duplicated route to something more to your liking.
In the duplicated route, under “Dial Patterns that will use this Route“, add the extension number (or pattern matching a group of extensions) to the fourth (CallerID) field of EVERY dial pattern on the list. Or, if using the Swiss Army Knife Module and you have checked the “Turn On Old (Pre 2.8) Dial Plan Textbox” checkbox (EDIT: or if you have FreePBX 12 or later, and under Settings | Advanced Settings, in the “GUI Behavior” section you have set Enable The Old Style FreePBX Dial Patterns Textarea to True), then add the extension number or pattern to the end of every existing pattern, separated by a forward slash. As an example, an existing pattern of 1+NXXNXXXXXX would become 1+NXXNXXXXXX/234. Again, you must do this to every pattern in the pattern list.
And finally, in the duplicated route, change the the “Trunk Sequence for Matched Routes” to include only those trunks that you want that extension or group of extensions to use.
If there are additional Outbound Routes for which you want to change the trunk selection for the same extension, repeat the above, starting with the other outbound route(s). If you have additional extensions and you want one or more of them to have different trunk usage, repeat the above, using the different extension number(s) in the CallerID field and the different trunk selections.
If you want to block an extension’s ability to make toll calls, use the same procedure but only give them access to an ENUM trunk. ENUM is pretty broken then days, it it would be rare for a call to actually complete, but if it does it’s not going to cost you anything. This particular usage is discussed in more detail in “How to block a single extension’s ability to make outgoing toll calls in FreePBX“. (EDIT: In the most recent versions of FreePBX you can simply not select any trunks at all in the “Trunk Sequence for Matched Routes” section of the Outbound Route, and then optionally select a failure announcement or whatever treatment you want to give the call in the “Optional Destination on Congestion” section.)
And again, please note that you can use a single extension number OR a pattern in the CallerID field. For example, if you had a pattern like 1NXXNXXXXXX, you could do something like:
1NXXNXXXXXX/100 – match on the pattern only if the call is from extension 100
1NXXNXXXXXX/2[45]X – match on the pattern only if the call is from an extension in the range 240-259
1NXXNXXXXXX/3XX – match on the pattern only if the call is from an extension in the range 300-399
And if you wanted to allow the call only if it came from extension 100, 240-259, or an extension in the 300’s then you could use all three of the above rules in the same outbound route.
I will offer my opinion that using the Swiss Army Knife Module and checking “Turn On Old (Pre 2.8) Dial Plan Textbox” is the only way to go if you happen to have several hundred dial patterns! Well, maybe not the only way (you could export a .CSV file, edit it, and import it back in), but definitely the easiest, because you can simply cut all the patterns from the textbox and paste them into a text editor, then use search-and-replace to add the extension numbers, then copy the changed patterns from the text editor and paste them back into the textbox in the Outbound Route. If the search-and-replace function supports regex matching then it’s easy – set the find string to n and set the replace string to /234n (assuming 234 is the extension number you want to add), and replace all occurrences (be sure to check the first and last lines to make sure they look as they should, in case there was a missing or extra newline character somewhere).
EDIT: We have been informed that the old-style textboxes are once again available in FreePBX 12 and later. You have to click on the Settings tab, then Advanced Settings, then find the “GUI Behavior” section and change the Enable The Old Style FreePBX Dial Patterns Textarea setting to True.
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 are a Mac user, you’ve probably heard of Little Snitch. It’s a commercial (as in, not free) program that lets you allow or deny connections to the Internet from individual applications. One reason for using such a program is to detect software that should have no reason to connect to the Internet nevertheless attempting to do so. For example, you download a free screensaver (dumb move to start with) and it sends all the personal information it can find on you to some group of hackers on the other side of the world. A program like Little Snitch would let you know that the screensaver is trying to connect to the Internet, and allow you to deny that connection. In the Windows world, I believe that ZoneAlarm has a similar capability, and it’s also a commercial (as in, not free) program.
Leopard Flower personal firewall for Linux OS screenshot
It appears that these is a similar program for Linux users, and it IS free! It’s called Leopard Flower and it’s described as a “Personal firewall for Linux OS (based on libnetfilter_queue) which allows to allow or deny Internet access on a per-application basis rather than on a port/protocol basis.”
Looking at the screenshot it appears to have very much the same per-application blocking functionality you’d get in one of those other programs. I have not personally tried it yet, but I wanted to create a post about it so if someday in the future I am trying to remember the name of this program, I’ll know where to find it (yes, this blog does sort of serve as my long-term memory!). 🙂
Douane personal firewall for GNU/Linux screenshotDuane configurator screenshot
The only downside to this one is that as of this writing the only available package is for Arch Linux but if you want to try to build it for a Ubuntu or Debian system, they provide a page showing the needed dependencies.
There is an older similar program called TuxGuardian but apparently is hasn’t been updated since 2006, so I have no idea if it will even work with current versions of Linux. And as for you Android users, try the NoRoot Firewall app.
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.
Image via CrunchBase
I’ve seen this happen several times now on Ubuntu-Linux based systems that have NVIDIA graphics. What happens is that “Update Manager” pops up and tell you there are updates for your software, and you accept them. It then tells you that your system has to be rebooted. And when you do that, you get no video, or text only. What probably happened was that the updates you installed included an update to the Linux kernel, and the NVIDIA graphics driver currently installed on the system was compiled against the OLD kernel.
Note that this generally can only happen if you manually updated the NVIDIA graphics driver at some point. If you always installed it from the standard repositories for your distribution, you’ll probably never see this issue. So a word to the wise — when you finally get around to doing an upgrade of your Linux distribution, try to avoid manually installing the NVIDIA graphics driver. Instead, let the distribution pull it from its repository. After that, you should not have this issue in the future. By the way, if you currently are running Ubuntu, we recommend upgrading to Linux Mint rather than a newer version of Ubuntu. Linux Mint is very similar to Ubuntu, but leaves out some of the things that users seem to hate about newer releases of Ubuntu. More to the point, they are not currently talking about switching their base graphics system from the X window server system to a new display manager, which I have a feeling might cause problems for some NVIDIA graphics users.
But if you’re not yet ready to do a full reinstall of Linux, the fix for this problem is easy IF you had the foresight to set up SSH access to your Linux system BEFORE the trouble started. If you didn’t, and you’re not a true Linux geek, you may be kind of screwed. So if you’re reading this and your system is working fine, and you haven’t yet set up SSH access, you may want to do that. There are several sites that tell you how to do that; here are two that I found using Google:
If you didn’t do this beforehand, you may still be able to do it if you can get to a command prompt.
Anyway, the actual fix is to (re-)install the latest NVIDIA driver for your system. They will be compiled against the new Linux kernel and then everything should work fine. To find the correct NVIDIA driver, go to the NVIDIA Driver Downloads page, and use the dropdowns to select the correct driver for your system. Download it to your local system, then upload it to your Linux PC (if you have SSH access working then you can use an SFTP client, such as WinSCP or Transmit, to upload your driver file). Once you have it on your PC, from a command prompt navigate to the directory where you put the driver and then change the permissions to make it executable:
sudo chmod +x driver_upgrade_script_filename
Now try running the script (it should have a .run extension):
sudo ./driver_upgrade_script_filename
It should not complain that the Gnome Display Manager or KDE Display Manager is running (if it were, you wouldn’t be in a state of near-panic right now), but if you were just doing a regular update you’d have to do this when the GDM/KDM is stopped. For a guide that covers that scenario, see How To Install Official Nvidia Drivers in Linux, or just know that to stop the display manager,
sudo /etc/init.d/gdm stop
should stop the Gnome Display Manager, or if you’re using KDE then the command would be
sudo /etc/init.d/kdm stop
Most sources I’ve seen suggest that you answer yes to any questions the installer may ask. The only one I’d be cautious about is letting it create a new xorg.conf if you are using a customized one (which you may well be if you’ve used any of my previous HTPC-related articles). If you have edited xorg.conf, then I’d make sure you at least have a backup before letting the installer create a new one, so you can revert back to your custom one (or compare the two and insert your customizations into the new one) if necessary.
Under Ubuntu, you may get a message similar to “Provided install script failed”. That will happen every time you update the NVIDIA driver this way and it is normal. Just ignore it and continue the installation. If you get “Error locating kernel source”, run sudo apt-get install kernel-source from the command prompt, then run the driver upgrade script again.
When the installer has successfully finished, reboot the system and when it comes back up, hopefully you should be happy again!
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.
Someone in the PBX in a Flash forum wanted to know if there was some technique that could be used to get an e-mail alert if a user on the system dialed 911. There are probably many ways this could be done, but here was the way I thought would work. This has not been tested in a working installation so please note the disclaimer at the end of the article. I DO NOT guarantee that this will work on your FreePBX installation!
EDIT (November 24, 2012): Another approach to doing this would be to add some custom dialplan to the [macro-dialout-trunk-predial-hook] context in extensions_custom.conf. See How to use the FreePBX [macro-dialout-trunk-predial-hook] macro and regular expressions to blacklist or whitelist outgoing calls on all trunks for more information on this technique, which would allow you to easily detect outgoing calls to a particular number on just about any trunk with only a few lines of code, eliminating the need to create a CUSTOM trunk as shown below. Either method will work, so do whichever you’re more comfortable with.
1. First, add a small additional context to /etc/asterisk/extensions_custom.conf (note that you will probably need to copy and paste this into a text editor to get the first line of the context complete and without line breaks where they shouldn’t be):
[custom-notify-email]
exten => _X!,1,TrySystem(echo "This is to notify you that ${CALLERID(name)} at ${CALLERID(num)} has called 911" | mail -s "911 call notification" you@youraddress.com)
exten => _X!,n,Goto(from-internal,0000${EXTEN},1)
exten => h,1,Macro(hangupcall,)
Note that the first line of the context (not counting the context label line) contains the actual email to be sent. Replace the various elements of the e-mail (body, subject, destination address) with appropriate elements for your situation. In the second line of the context, note that I’m prepending a four-digit code of “0000” to the number dialed before sending it back into the dial plan. This code can be anything you want and any number of digits you want, but it should start with something that a user would never dial when making a regular call. Therefore, things like “0000”, “111111”, or even “*****” could be good choices, while “9876” would be a poor choice because a user might actually attempt to call a number such as “987-6911”. One PBX in a Flash forum user reported that “0000” conflicted with Astridex in some way, so that’s why I’m taking pains to explain this. Since the user isn’t expected to dial these digits, you could even use something like “010100001111”, just as long as it’s a code used uniquely for this purpose.
2. Create a CUSTOM trunk. Make the trunk name whatever you like, but for the Custom Dial String use:
Local/$OUTNUM$@custom-notify-email
When you set it up it should look like this:
CUSTOM trunk (here named Send-email-notification) sends calls to custom-notify-email context
3. Assuming you’re using this to monitor 911 calls, create a NEW emergency 911 Outbound Route that duplicates your existing 911 route (In FreePBX 2.9 or later you can click on the “Duplicate Route” button). In the duplicate (which should be right underneath the original in priority) change the dial pattern from 911 to 0000|911 (but if you used something other than 0000 in step 1, use the same thing here). What this does is strip off the digits that were prepended to the number by the custom-notify-email context — this is done so you don’t create an endless loop. Note the pattern I have shown assumes you are using FreePBX 2.7 or earlier OR are using the Swiss Army Knife module to restore the pre-2.8 dial pattern text box in your Outbound Routes — if you haven’t done that then be sure you get each component of the dial pattern in the correct little box.
DUPLICATE of original 911 emergency route that strips prepend in dial pattern (route has been renamed to 911-strip-prepend). Note how Swiss Army Knife module restores textbox entry for dial patterns!
4. In your ORIGINAL emergency 911 Outbound Route, change the trunk selection to use only the CUSTOM trunk you created in step 2.
ORIGINAL 911 emergency route, with trunk selection changed to use CUSTOM trunk
That’s it. The call flow is as follows:
Someone dials 911, it goes to the original 911 outbound route, then to the custom trunk and from there to your custom context which sends the email, prepends 0000 (or the digits you have used instead) onto the number (for example, making it 0000911 internally), and sends it back to the from-internal dial plan. It hits the duplicate 911 outbound route which strips the prepended digits and sends the call to your original trunk selection for 911 calls.
I would STRONGLY urge you to make a test call and see if it all works as you expect, if your local 911 service allows you to do that (call them on the non-emergency number first to make sure it’s okay). See the disclaimer below!!
You could use this same technique for non-emergency calls, but you’d have to have an Outbound Route dedicated to just those calls (in other words, it should only contain dial patterns for the calls you are trying to monitor, and it needs to be higher in priority than any other Outbound Route that might ordinarily handle such calls. Once you have that working you can apply the above technique, which among other things means you’ll be making a duplicate of that Outbound Route, and making adjustments to the original and the copy as described above.
Disclaimer: The above is just a suggestion of what SHOULD work, and should be considered UNTESTED. Do NOT rely on it until you have tested it yourself to make sure it works as you expect. I don’t guarantee it will do anything except take up more space on your hard drive, so it is solely up to YOU to make sure it works as you want.
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:
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.
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.
This question comes up a lot and rather than having to re-type the answer each time I see it posted in some forum, I decided to put it here, where I can just link to it. If you want to know why this works, read my previous article, Asterisk hiding a useful feature in plain sight by giving it a “cute” name.
Many organizations have a single extension that is a “house phone” for visitors, and they don’t want anyone to be able to use that phone to make “off-site” calls. The thing you must decide is, do you want your users to only be able to make in-house calls, or do you want to in addition allow calls to local and toll-free numbers? It makes a bit of difference in how you do this. And remember, in most places, by law you MUST allow calls to 911 or whatever your local emergency number might be — if you block emergency calls and someone tries to use that phone to summon an ambulance or get other necessary emergency help and is unsuccessful in doing so, then prepare to have your butt sued off (and possibly even serve some time in prison), and I don’t have a bit of sympathy for you. I don’t care what reasons you may think you have for wanting to block emergency calls, just DON’T DO IT.
Anyway, here’s the basic technique:
1. Create a Trunk: (EDIT: This step is unnecessary in the most recent versions of FreePBX). If you want to allow “free” off-premises calls, then the easiest thing to do is create an ENUM trunk, if you haven’t done so already. If you DON’T want to allow free calls, then create a “dummy” trunk for the purpose. Create a CUSTOM trunk (not SIP or IAX2, etc.), name it Blocked, and make the Custom Dial String Local/congestion@app-blackhole — that’s all you have to do. For extra safety, you can also check the “Disable Trunk” checkbox (this should play a recording saying that all circuits are busy, or something to that effect, whereas leaving the trunk enabled would play “fast busy” tones). Then submit the changes.
2. Create an Outbound Route: Give the Outbound Route any name you like. In the “Dial Patterns that will use this Route” section, enter the patterns you do NOT want the extension to be able to dial (in the third field of a pattern if using FreePBX 2.8 or higher) followed by the extension number that you want to restrict (in the fourth field in FreePBX 2.8 or higher, or after a forward slash character if using a lower version). I’m going to show the following examples in the syntax used in FreePBX 2.7 (EDIT: you would also use this syntax in FreePBX 12 or later, if under Settings | Advanced Settings, in the “GUI Behavior” section you have set Enable The Old Style FreePBX Dial Patterns Textarea to True). Let’s say you want to block calls from extension 234:
To block all calls of 11 digits or more (in case you have “local” 10 digit dialing): XXXXXXXXXXX!/234
To block all calls of 8 digits or more (allowing 7 digit local calls): XXXXXXXX!/234
To block all calls of 4 digits or more (in case you have three-digit extensions and want to allow in-house and 911 calls only): XXXX!/234
In the Outbound Route trunk selection, (EDIT: if you have a recent version of FreePBX, simply do not select any trunks at all in the “Trunk Sequence for Matched Routes” section of the Outbound Route, and then optionally select a failure announcement or whatever treatment you want to give the call in the “Optional Destination on Congestion” section. Otherwise, if you are still running an older version of FreePBX) select whichever trunk you created in Step 1 (ENUM or Blocked). Select only that one trunk. Note that if you “disabled” the Blocked trunk it may be grayed out, but you still should be able to select it as a trunk choice, and that should be sufficient to keep FreePBX from complaining that you haven’t made a trunk selection.
Priority is important! Make sure this Outbound Route appears in your list of Outbound Routes BELOW any routes that handle calls you want to allow (your emergency route(s) for sure, and possibly routes that handle Toll-Free calls if you want to allow those), but ABOVE any routes that would normally be used for the type of calls you want to restrict. Remember that this route will only restrict calls that match the patterns, so if you only restrict calls that are 8 digits or more and you have a lower-priority route that handles 7-digit local calls, those calls should still go out.
Just a note about use of an ENUM trunk (EDIT: Optional and not necessary in newer versions of FreePBX). If someone calls a number that is registered as an ENUM number, it will go out as a direct SIP call, bypassing your normal SIP or IAX providers, so it won’t cost you a dime. The vast majority of numbers are NOT reachable via ENUM so if you use an ENUM trunk as your “blocker” trunk, it will be a very rare thing if a call actually connects that way, but if it does you won’t be paying for it. Sometimes U.S. or Canada Toll-Free numbers are reachable via ENUM and sometimes they are not — it’s actually pretty much a crap shoot whether it will even work at all. So if you want to specifically allow toll-free calls, don’t count on ENUM to handle them, but be aware that in some cases they might go through via ENUM, at no cost to you (other than whatever you may pay for your Internet connection, of course).
Be sure to make some test calls from the extension to make sure everything works as you expect. And double-check to make sure you have not blocked emergency (911, or whatever your local number is) calls!
If you need to do blocking for more than one extension, you can either use patterns (rather than single extension numbers) after the forward slash, or simply add new blocking rules. For example, you could do this:
Block all calls of 4 digits or more from extension 234 or 235: XXXX!/23[45]
Block all calls of 4 digits or more from extension 230 through 239: XXXX!/23X
Block all calls of 4 digits or more from extension 234, and block all calls to 1-900 numbers from extension 288: XXXX!/234 1900XXXXXXX/288 900XXXXXXX/288
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?”
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):
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:
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.
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy
Recent Comments