Category: software

Setting up an OpenVPN tunnel using a CentOS-based system as the server and a router flashed with Tomato firmware as the client – Part 2

 

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.
Continued from Part 1

EDIT (Jaunary 2011): Since I originally wrote this article in 2009, a new project has appeared called Easy OpenVPN, which is described as “a collection of bash scripts which will install and configure the Open VPN software on your PBXIAF server. Also includes scripts for creating client certificate files.”  The project’s page further notes that these scripts are compatible with the security models used in, and have been tested with PBX In A Flash and Elastix, and that they may be compatible with other PBX distributions, but have not been formally tested.  It also notes that the scripts do not interact directly with Asterisk or FreePBX.  I have NOT tested these scripts, but it sounds as if it they might work on just about any CentOS-based OS.  Certainly, if you are using one of those distributions, it’s worth looking into — it might be a faster and easier way to set up OpenVPN on your server than the procedure I outline here.  Some instructions can be found in this thread.  Even if you go that route, you might still want to read the rest of this series, since it gives some explanations and usage tips that may come in handy if the scripts don’t configure OpenVPN the way you’d like. FURTHER EDIT: If you want a dedicated OpenVPN server, check this out: Create a VPN with the Raspberry Pi (from Linux User & Developer).

Before you can begin to set up the OpenVPN server, there is some preparation work that needs to be done. But first, let’s talk about the prerequisites and assumptions we are making here. In the case of the tunnel I was helping to set up, the OpenVPN server was located on a box that runs the Elastix PBX distribution, which includes the CentOS operating system, plus FreePBX and Asterisk and a few other things. It doesn’t really matter whether the box has other servers on it (of course, if it’s a really old/slow box there may be performance issues), but for the purposes of our instructions here, the most important thing is that you have Webmin installed.  Let me repeat that loud and clear:

You MUST have Webmin installed to use these instructions!

You don’t have Webmin installed and you don’t want to install it? Fine, shoo, away with you then. There are hundreds of other installation guides on the Internet, go find one you like.  You have to keep in mind that with me, whenever there’s a choice between using the Linux command line or manually editing a configuration file, and using a nice GUI, I’ll pick the GUI every time.  Some people (usually long time Linux users) seem to have some philosophical objection to using Webmin – if that’s you then you’re obviously much too smart to need these instructions, so what are you doing here?

I’m going to assume you already have Webmin installed, but if you don’t, try doing yum install webmin — it might already be in a CentOS repository.  If that doesn’t work, you should be able to do this:

wget download.webmin.com/devel/rpm/webmin-current.rpm
rpm -ivh webmin-current.rpm

Once you get Webmin installed (or if you are using a Debian-based distribution such as Ubuntu) go to The ‘Point and Click’ Home VPN HowTo Guide — we’re going to refer to that document several times, so you may want to keep it open in another browser tab. But for now, just follow the instructions related to installing Webmin, starting (for CentOS users) with the subheading “Access Webmin”.  For now, just follow the instructions in the two paragraphs in that section.  On a Debian-based system, I’d try following the entire document, but I can tell you there are parts missing for a CentOS-based system, so stick with us for a bit.

Another assumption we are making is that your primary network (the one the server in on) has addresses in the 192.168.0.1 through 192.168.0.255 range.  It’s okay if the “0” in the third octet is some other number (hopefully it’s not 5, because that what we used at the client end) but the main point is that we’re assuming it’s a small network.  If you’re using more than 255 addresses on the primary network it’s not an insurmountable problem, as long as the client end has its own unique address space.

Open the file /etc/hosts.allow at the server – you should see something like this:

ALL : 192.168.0.0/255.255.255.0

If you do, you could change it to the following two lines (note the change in the netmask in the first line):

ALL : 192.168.0.0/255.255.0.0
ALL : 10.8.0.0/255.255.255.0

However,  if there are any addresses in the range 192.168.0.0 through 192.168.255.255 that are normally reachable but not in your LAN — a primary example is a cable modem status page on 192.168.100.1 — you may not want to extend the scope of your local network quite that much. You could use a more restrictive netmask — for example, you could use these two lines, which is what I’d recommend for this project:

ALL : 192.168.0.0/255.255.240.0
ALL : 10.8.0.0/255.255.255.0

That would specify that anything in the range 192.168.0.0 through 192.168.15.255 is on your local network (including subnets on the other side of your tunnel).  Alternately, if you wish to be a bit more precise and/or secure, you could specify the network(s) at the distant ends of the tunnel individually (using a more restrictive netmask), e.g.:

ALL : 192.168.0.0/255.255.255.0
ALL : 192.168.5.0/255.255.255.0
ALL : 10.8.0.0/255.255.255.0

(If you do the latter, you may also want to add a line for the network on the WAN side of the client router, e.g. ALL : 192.168.1.0/255.255.255.0 to be able to reach devices in that subnet from the server side of the tunnel — assuming that won’t conflict with any addresses on your own local network).

You also need to go into your router (the one between the OpenVPN server and the Internet, that controls the LAN at the server end – not the client router running the Tomato firmware) and expand the scope of your local network.  I can’t give you specific instructions for your router, but generally the principle is the same as in the hosts.allow file – in most cases you need to expand the scope of the local netmask to 255.255.something.0, where something is less restrictive than 255 and includes all local nets on both sides of the tunnel, but not your cable or DSL modem’s status page (don’t worry about the 10.8.0.x addresses, your router won’t see those).  I suggest using 255.255.240.0 and then making sure that your local networks on both ends of the tunnel fall within the range 192.168.0.x through 192.168.15.x. The reason you need to change the netmask is so that when something on your primary LAN tries to connect to an address in the 192.168.5.x range (on the other side of the tunnel), your router will send out an ARP probe to find out which device on the network has that address (getting the OpenVPN server to respond is another issue that we’ll cover later). But if you are trying to get to something on the backside of your router (the modem status page being the prime example), you don’t want your router thinking it’s on your LAN – hence the need for care when changing the netmask.

If for some reason you can’t follow my suggestions about local network range, you’ll still need to figure out an appropriate netmask, both for the etc/hosts.allow file and your server-side router configuration.  Fortunately, there are many pages on the Web that will help you – Google the phrase “netmask calculator” (include the quotes) and you’ll find several sites that will help you calculate an appropriate netmask.  Of course, there are limits on this – you’re going to have a much harder time making this all work if all the local networks on both sides of the tunnel aren’t in the 192.168.x.x range (or, more specifically, don’t have at least the first two octets of the LAN IP address in common).

While you are in the router on the server side of your connection, you need to open UDP port 1194 for incoming traffic and point it at your OpenVPN server – otherwise outside connection attempts will never be received by the server. Don’t open the corresponding TCP port – it’s really not a good idea to use TCP for OpenVPN unless you are forced to do so (by an overly restrictive ISP, for example).

You also need to open up the file /etc/sysctl.conf and make sure that the following line is NOT commented out (add it if it doesn’t already exist):

net.ipv4.ip_forward=1

Also, at a terminal prompt, execute the following:

echo 1 > /proc/sys/net/ipv4/ip_forward

While in the terminal, you SHOULD upgrade OpenVPN to the most current version (or install it if it’s not already installed).  Older versions of OpenVPN will not work with these instructions.  Just type openvpn from a command prompt and at the top of the resulting output it should show you what version you have, if it is installed.  It will look something like this:

OpenVPN 2.2.0 i686-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Jun  6 2011

2.2.0 is the version in this example.  But on a recent CentOS install, just doing yum install openvpn only offered to install version 2.0.9, which is too old to work with these instructions!  Here is how I installed a newer version (edited July 27, 2011 to reflect a better way):

Add the dag repository if you haven’t done so already.  In the /etc/yum.repos.d directory, create a new file called dag.repo:

touch /etc/yum.repos.d/dag.repo

Edit the file using any text editor (for example, nano /etc/yum.repos.d/dag.repo) and add the following lines exactly as shown:

[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

Save the edited file and then from a command prompt import the repository’s key:

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

Now if you do

yum install openvpn

You should get the latest version plus any dependencies (it should offer to upgrade your current version if it is older).  Note that you must use compatible versions of OpenVPN at both the client and server ends, so once you have an OpenVPN tunnel working, it might not be a good idea to just go upgrading the software at one end or the other unless you know the newer version is still compatible with what you’re using on the other end (minor version upgrades are probably okay, but I am not guaranteeing that!).

Now return to The ‘Point and Click’ Home VPN HowTo Guide — you want to find the section headed “Setting Firewall rule(s) to allow VPN web traffic to redirect out eth0” — now I will just say that you need to follow those instructions, but when setting up the actual rules, I found that only two were really important.  So if I were rewriting their instructions, here is how I’d say it:

First we’ll assume that the firewall is not set up yet so click Reset Firewall. Now we need to add some rules. From the Showing IPTable: dropdown select Packet filtering  (filter) where we’ll create the following rule:

Forwarded Packets (FORWARD)

Accept If input interface is tun0
Incoming interface Equals tun0

Then, from the Showing IPTable: dropdown select Network address translation (nat) where we’ll create the following rule — this is the rule that goes along with the VPN “push redirect-gateway”. This allows the VPN web traffic to be routed out through your connection:

Packets after routing (POSTROUTING)

Masquerade If source is 10.8.0.0/24 and output interface is eth0
Source address or network Equals 10.8.0.0/24
Outgoing interface Equals eth0

Why not add the rest of the rules? Well, if you Reset Firewall as instructed, you don’t need them, because they are specifying default conditions. But if you didn’t want to reset the firewall because you already have some preexisting rules, or if you ever actually decide to go in and configure some more restrictive firewall rules, then you may need some of the other rules listed. There’s certainly no harm in adding the other rules, but I’d rather emphasize the two that are absolutely necessary to get this working, assuming you started with a clean slate.

When you are finished, the two rules pages should look like this:

Firewall rule: Accept If input interface is tun0
Firewall rule: Accept If input interface is tun0
Firewall rule: Masquerade If source is 10.8.0.0/24 and output interface is eth0
Firewall rule: Masquerade If source is 10.8.0.0/24 and output interface is eth0

(I know that at this point, some Elastix and FreePBX users may be wondering if the above would interfere with the operation of fail2ban, in the event they have installed it. As far as I can tell, the answer is no… fail2ban communicates with the firewall in a different way, and unless you add rules that explicitly contradict what fail2ban does, I don’t think there will be any issues. However, I do recommend that you temporarily disable fail2ban, possibly from Webmin’s System | Bootup and Shutdown page, prior to connecting a new VoIP adapter or similar device on the client end of a tunnel for the first time. The reason is that if the device fails to register for any reason, such as a mis-typed password, fail2ban might refuse connections even after you fix the issue, and it might even clamp down on other connections from the client end of your tunnel. So get your devices registered and working, then restart fail2ban. Alternately, if turning off fail2ban makes you nervous, you could open /etc/fail2ban/jail.conf in a text editor, then edit the ignoreip option under the [DEFAULT] section to include the IP addresses or network on the client side of your tunnel — for example, you could add 10.8.0.0/24 and 192.168.5.0/24 as address ranges you don’t ever want to ban.)

Once again, return to The ‘Point and Click’ Home VPN HowTo Guide — now you want to start at the section, “Install OpenVPN-admin module” and continue through to the part entitled “Testing the VPN Server using the OpenVPN client GUI from Windows.” If their suggested download method doesn’t work, use the download link on this page to download it to your local machine, then in Webmin install the module “From uploaded file” rather than “From ftp or http URL” as the article suggests. What I suggest you do here is setup TWO clients, one for a soft client you can use for testing purposes, and one that you will use with the OpenVPN client in the Tomato firmware. While you might be able to get a Windows-based client to work using the instructions shown, I can assure you that the Tomato client isn’t going to work until you add a few additional tweaks, which we’ll cover in Part 3. But you can certainly set up and test the Windows-based client if you like, just to assure yourself that the server is actually working.

Just so you don’t spend a couple hours beating yourself up wondering why the server won’t start, I will point out that there’s a glitch in the Webmin OpenVPN module. When you click on the VPN server list and then click on Start to start a server, the server name is supposed to turn from red to black, and the word Start is supposed to turn to Stop. For whatever reason, that doesn’t happen on our server… you can click Start until the cows come home and it still won’t turn black. It probably has something to do with the module configuration itself – for example there’s a setting for PID file path of running OpenVPN processes (*) which by default is set to /var/run, which may not be correct — however, when I changed it to /var/run/openvpn, which does seem to be correct, it made no difference. I just start and stop the server using the buttons at the bottom of the main “OpenVPN Administration” page, which seem to work fine.  EDIT:  See Leon Baker’s comment in the comments section below for a fix for this problem.  Thanks, Leon!

Next up, in Part 3: Configuring the OpenVPN server using Webmin (or more specifically, the changes and additions you need to make to actually get it working as expected). More screenshots!!!

Setting up an OpenVPN tunnel using a CentOS-based system as the server and a router flashed with Tomato firmware as the client – Part 1

 

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. The link to Amazon.com in this article is an affiliate link, and if you make a purchase through that link I will receive a small commission on the sale.

Some readers of this blog may recall that several months ago I had wished for a Simple VPN device – back then I had written:

There is another type of software that ought to be moved into its own box, and that is Virtual Private Network (VPN) client and server software. Yes, I’m aware of OpenVPN, and I tried to find setup instructions that someone like me could understand, but to no avail – it looks like you need a degree in computer networking to understand how to set up this type of software. And yet, built into hardware devices, it could be immensely useful in certain circumstances. Let’s consider the following diagram:

Diagram showing position of "client side" and "server side" VPN devices

In this particular case we have a SIP-based VoIP adapter at a remote location. Anyone who has worked with Asterisk behind the wrong kind of firewall knows the issues involved with using SIP and not having things set up just so (one-way audio, anyone)? But also, we may for whatever reason want that “remote” VoiP adapter to appear as if it were on the local network (maybe we have an ISP playing games with SIP packets?). So we plug the VoIP adapter into our “VPN Client-Side Device” and on the other end, we have a companion “VPN Server-Side Device” which in this case makes two connections to the router – one to receive the “tunneled” data and the second to send the unencrypted data back onto the local network. The green arrows represent the “tunnel”, the orange arrows show where the data from the VoIP adapter enters and exits the tunnel. Please note this is entirely a wired connection, we aren’t using wireless anywhere here. Also note that as far as the VoIP adapter is concerned, the only network it can “see” is the one at the other end of the tunnel – under no circumstances can it access the Internet other than by going through the tunnel.

I show this using a VoIP adapter, but I’m sure that people could think of a lot of other ways this could be used, and a lot of other devices that could be connected to the client end.

Now some will probably argue that it is inefficient to have a device that does nothing but provide the tunnel. But that’s the point – almost anyone could set this up. If you send the client-side device to your grandmother, she can set it up (well, maybe that’s pushing it a bit, but you get my point). People who would never touch a Linux box or a server could use this.

I want to tell you, when I wrote that I had no idea just how difficult it would be to actually get VPN tunneling working using OpenVPN.  The problem isn’t that it doesn’t work — actually, it works quite well — the problem is that it’s a real bear to set up, unless you have someone who knows what they are doing walk you through it.  Unfortunately, you may not haves someone who knows what they are doing to help you, so you’re stuck with me (unless you can find a better page on the subject – if such exists, please let us know in a comment).

The real issue is that you have to learn so many new things at once to make this work.  So, my attempt here is going to be to try and give you a “cookbook”, with plenty of screenshots so you can see how things actually look when everything is configured.  I’m actually also going to approach this in a slightly backward manner, showing you how to configure the client first, then the server.  My theory is that you will think that configuring the client is so simple that configuring the server can’t be much harder, and you’ll get sucked into the project before you realize what you’ve gotten yourself into! 🙂

By the way, what we are doing here doesn’t look exactly like the diagram above – instead it looks more like this (note that the “Primary Router” on the client side can be omitted if you don’t need any UN-tunneled connections, or if the DSL or Cable modem has a built-in router):

Diagram showing position of OpenVPN client and OpenVPN server in data flow
Diagram showing position of OpenVPN client and OpenVPN server in data flow

For our client, we need something that you can plug your desired device into. You may have a laptop, and you want to communicate securely with a home office. You may have a VoIP adapter, and you want to make secure calls to a remote Asterisk server.  While you can run a software client on the Laptop, when you have a hardware device like a VoIP adapter your choices become more limited.  The solution is to purchase a router that is capable of being re-flashed with custom firmware.  In this case we are going to use the Tomato firmware, and in particular, a version of the firmware designed to support OpenVPN as either a client or a server. Here we’re going to use it as a client. The idea will be that ANY device plugged into the router will automatically use the VPN tunnel, and if for some reason the tunnel isn’t available then the connected device will not be able to communicate, therefore there’s little chance that an insecure communication can take place.

Some readers will already have a router capable of running Tomato firmware, and some will not.  The main Tomato Firmware page shows which routers are supported.  If you do not already have one of these and plan to buy one, I recommend that you consider the Asus WL-520GU. I know that the main Tomato firmware page says there’s no USB support for that model, but that’s not necessary for what we’re going to do, and it’s not even true if you use the recommended firmware build. The reason I suggest using the WL-520GU is because I’m told that although it’s not totally impossible to “brick” the router by doing a bad flash, if you do make a mistake, your chances of being able to recover (so that the router isn’t consigned to being an expensive paperweight) are far better than with some other models.

I should mention here that I inherited this project from someone else who couldn’t get it to work.  I had made the mistake of casually suggesting they get the Asus router if they wanted to attempt this, only to find them on my doorstep with router in hand.  So again, I’m not saying this will be easy, and the one thing I will not tell you how to do is how to get the Tomato firmware onto your router.  The reason is that if I give you instructions and leave out a step and you brick your router, you will be mad at me.  Better you find someone else’s instructions, and if they’ve left out a step, you can be mad at them. I will mention that, at least in the case of the Asus router I had here, it was a two-step process – I used the Asus Firmware Restoration Utility to first install DD-WRT (using these instructions) and then used DD-WRT’s web interface (Administration -> Firmware Upgrade) to install Tomato (I’m skipping a whole tale of woe and grief that transpired between those two events). Basically I followed the instructions at An Easy Guide to Installing Tomato on the Asus 520gu, but I’m not telling you to do that — it’s up to you which instructions you wish to follow.

Why Tomato instead of DD-WRT?  Because Tomato works, that’s why. But if you want to try getting it working on DD-WRT, go ahead, knock yourself silly (only one tip for you, from a tweet by @pista01 on Twitter —  if you keep getting TLS errors, make sure your NTP client is set up). If you succeed, great for you. If you don’t, you’re welcome to come back here and continue on.

But don’t just grab the first build of the Tomato firmware that you see. You need one that includes VPN support.  There are two versions I would highly recommend — if you have taken my advice and acquired an Asus WL-520GU (or similar model with built-in USB port), then I recommend teddy bear’s build because it enables the “missing” USB support, and also includes the VPN support from SgtPepperKSU’s build — which is the one you should get if you DON’T have the Asus WL-520GU, but instead have some other compatible router (EDIT: Advanced users may also wish to check out thor2002ro’s build, which offers both the VPN and USB support from the aforementioned builds, plus support for SDHC, SNMP, and perhaps other additional features.  I haven’t tested that one at all, and note that recent versions probably won’t work with many router models due to memory requirements, so unless you really need one of the features in that version and know that your router supports it, I’d stick with one of the other versions). Make sure you read up on the chosen build and be sure you get the correct firmware version.  For the Asus I used the binary from inside the tomato-1.25-ND-USB-8632-vpn3.3.rar archive, but since then a newer version has been released (tomato-1.25-ND-USB-8634-vpn3.4.rar was released in August, 2009), or you may prefer a different version.

tomatoIn this series you will see several screenshots.  I’m using the custom “Tomato USB” theme, so the colors and “look” may be a bit different than what you see, but other than that everything’s in the same place as with the default theme. Later (after taking the screenshots) I replaced the tomato.png file from the theme with the one you see at the right, which I happen to like a little bit better.

Two other caveats: Although this router has wireless capability, for this application we aren’t going to use it — it’s going to be used on a wired network only.  That said, once you get it set up and working, feel free to experiment with the wireless capabilities if you like — just be aware that if something on the wireless side of things doesn’t work, I really can’t assist you. And also, we’re assuming that everything plugged into this router will be using the VPN tunnel full time, which implies that this router might (perhaps in a majority of cases) be plugged into another router, so that some other devices can access the local Internet connection, while the devices plugged into this router are limited to going through the tunnel. Note that if this router is plugged into another router, it would be preferable (but not absolutely essential) if it were in that router’s DMZ, so that you don’t have double NAT (Network Address Translation) taking place.

And now, a word about OpenVPN.  OpenVPN supports two different modes of operation — TAP and TUN.  In this case, we are using TUN.  We MIGHT explore TAP at a later time, but TUN is easier to set up, and ANYTHING that can be done to simplify this process is worthwhile.  The main difference, from the users point of view, is that using TUN the two ends of the tunnel occupy two different portions of the local address range.  In this case, on our “home” LAN, the addresses are in the 192.168.0.x range and are assigned by the main router.  At the client end of the tunnel, the router running the Tomato firmware will hand out addresses in the 192.168.5.x range.  Neither router steps on the other’s toes, so to speak, when handing out addresses.  And there is one other difference — although shared directories can be accessed across the network, Windows/Samba shares cannot be “seen” on opposite ends of the tunnel. If you know they are there and know the IP address and share name of the hosting device, you can still access them, but the mechanism that advertises shares doesn’t cross the tunnel.

With TAP, on the other hand, the router at the primary location hands out IP addresses in the same local address range to devices on both sides of the tunnel, and also (in theory, anyway) shares will be “advertised” across the tunnel.  Sound like what you’d want, right?  Except that when we tried to set it up on the server side, somehow we managed to bring down the entire network – it basically acted like a denial-of-service attack on the entire LAN, and the problem stopped the moment we went back to using TUN. After you’ve messed with this stuff long enough, something like that can leave a rather bitter taste in your mouth, so we decided to stick with what worked.  In our particular application, seeing shares across the LAN would not be essential. Even if you eventually want to try using TAP, I suggest setting it up using TUN first, then when you have achieved that you can cross your fingers and try switching the mode to TUN at both ends.  I doubt it will work easily for you, but experimentation is certainly welcome.

If you want to know more about TUN/TAP and other OpenVPN options, you might want to get the book Beginning OpenVPN 2.0.9 (Amazon affiliate link) by Markus Feilner and Norbert Graf — see my recent mini-review of this book (links edited February, 2010 to reflect updated and expanded edition of the book).

So with the preliminaries out of the way, let’s get to the client screenshots…

Tomato Firmware - Basic | Network page
Tomato Firmware – Basic | Network page

This first shot shows the header, sidebar, and Save/Cancel buttons. Since the settings are probably a bit hard to read, we’ll zoom in on the pertinent part:

Settings portion of Basic | Network page
Settings portion of Basic | Network page

The main thing to keep in mind here is that the subnet you select must not conflict with address assignments on the primary network at the server. Next, on the Router Identification page, enter a Hostname to identify the router:

Basic | Identification page
Basic | Identification page

One thing I have read in several places is that it’s important for the time to be set accurately at the client.  For your choice of time servers there are several presets, but if you use Custom you can specify one or more of your own as the first choice(s), if you have a machine on your network that acts as an NTP server:

Basic | Time page
Basic | Time page

At this point you should probably go to the Administration | Admin Access page and set things up there to your liking. Remember that anything you make accessible on the router’s local LAN will also be accessible on the other side of your tunnel using the same security methods, so be careful.

Now to what we came for… setting up the VPN client. Click on VPN Tunneling and then on Client. I’ll say that one more time – you MUST click on Client. It’s far too easy to skip that step and accidentally be trying to configure a server! Then you should be at the Client 1, Basic tab:

VPN | Client page, Basic tab
VPN | Client page, Basic tab

Of course, the button at the bottom of the page will sat “Start Now” instead of “Stop Now” – I took these screenshots through the tunnel, so I couldn’t very well stop it to get that little detail right! After setting that up you want to click on the Advanced tab:

VPN | Client page, Advanced tab
VPN | Client page, Advanced tab

Note that the connection retry value is -1 (which means infinite retries) and there are two added lines in the custom configuration section:

keepalive 10 120
float

In case the connection to the server or the Internet goes down for a time, those settings should cause the client to keep attempting to re-establish the connection to the server. The float command is useful if your client is at a location where the ISP might change the IP address without advance notice — it is supposed to allow the VPN connection to survive an IP address change. You can omit float if your client is at a fixed IP address that is not subject to change.

And then the Keys tab – just take a look now, when we move on to the server I’ll explain how these are filled in:

VPN | Client page, Keys tab
VPN | Client page, Keys tab

There is one more thing that needs to be done (besides adding the keys) for our tunnel on the client side. Go to Administration | Scripts and click on the WAN Up tab. Enter the following two lines into the text box:

route del -net 0.0.0.0
route add -host `nvram get vpn_client1_addr` gw `nvram get wan_gateway`

The second line may wrap on your display due to length. You may want to copy and paste those lines so you get them right, but if you must type them, note that the ` characters are actually backticks – the small apostrophe-like character on the key to the left of the “1” key (the number 1) near the top left corner of most keyboards (well, in my part of the world, anyway). Then click on the Save button way down at the bottom of the page. If you fail to do this and your tunnel ever goes down (server dies or is inaccessible, etc.) there is a possibility that traffic that should go through the tunnel will use the local Internet connection instead.  These two lines will keep that from happening. When you are done it should look like this:

Administration | Scripts page | WAN Up tab
Administration | Scripts page | WAN Up tab

Just a note for future reference: You can optionally add an additional line here to allow you to get to something “upstream” of the network on the WAN side of the router. For example, let’s say you have configured the server to allow you to connect to devices on both the LAN subnet (192.168.5.x in our example here) and also devices connected to the primary router, in other words, on the WAN side of the router running the Tomato firmware (which were in the 192.168.1.x range on our example setup). But let’s suppose that upstream of that, you have a cable modem at 192.168.100.1 at the client location that you’d also like to be able to access. As long as you don’t have a conflicting address elsewhere in your network, you could add a line such as this in your WAN Up script:

route add -net 192.168.100.0 netmask 255.255.255.0 gw `nvram get wan_gateway`

… which would allow access to anything in the range of 192.168.100.0 through 192.168.100.255. If you want to be more specific, you can narrow it down to an exact address:

route add -host 192.168.100.1 gw `nvram get wan_gateway`

We’ll cover what else has to be done to enable this type of additional routing at the server end in the upcoming installments, but the above is what has to be done at the client-side router that is running the Tomato firmware. Note that you do not normally have to a a line such as this to get to devices on the same subnets as the LAN or WAN ports of the router, but just for anything upstream of the network that the WAN port of the router is connected to. If you don’t understand why you might want to add this type of additional routing now, just ignore this information for the time being, but make sure you do add the first two lines I mentioned above.

Once your tunnel is operational, you should go to the Advanced | Routing page and look at the Current Routing Table. Your addresses will differ (this was a test setup; you probably will see a wider range of addresses) but the main thing you want to make sure is that there is never an entry of default (or 0.0.0.0) in the destination column that goes to any interface other than a tunnel (tun11 in this illustration) — you should never see that whether the tunnel is enabled or disabled. If you do, then something’s likely wrong with the two lines you entered above (under the WAN Up tab):

Advanced | Routing page
Advanced | Routing page

So, that’s the basic client setup. Wasn’t too difficult, right? Ah, but just wait until we get going on the server — hopefully I can make it easy enough that you won’t have about three weeks worth of sleepless nights, when you occasionally mutter under your breath things like “Why? Why?? Why??? WHY won’t this damn thing work!”, and other things I’d rather not put on the Internet! But before I can write the next part, I REALLY need to catch some ZZZ’s, so the server will have to wait for part 2.

Review of OpenVPN: Building and Integrating Virtual Private Networks by Markus Feilner (Packt Publishing)

 

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. In order to comply with Federal Trade Commission regulations, I am disclosing that he received a free product sample of the item under review prior to writing the review, and that any links to Amazon.com in this article are affiliate links, and if you make a purchase through one of those links I will receive a small commission on the sale.
Cover of OpenVPN: Building and Integrating Virtual Private Networks
Cover of OpenVPN: Building and Integrating Virtual Private Networks

Before I start, let me give you a brief description of what’s in each chapter (this is taken directly from the Packt Publishing web site):

  • Chapter 1 looks at what VPNs are, how they evolved during the last decade, why it is necessary to modern enterprises, how typical VPNs work. The chapter also covers some essential networking concepts.
  • Chapter 2 explains VPN security issues, including symmetric and asymmetric encryption, the SSL/TLS library, and SSL certificates.
  • Chapter 3 introduces OpenVPN. In this chapter, we learn about the history of OpenVPN, how OpenVPN works, and how OpenVPN compares to IPSec VPN applications.
  • Chapter 4 covers installing OpenVPN on both Windows, the Mac, Linux, and FreeBSD. It covers the installation on Linux from the source code and RPM packages. Installation on Suse and Debian is covered in detail.
  • In Chapter 5, an encryption key for OpenVPN is created and it is then used to setup up our first OpenVPN Tunnel between two windows systems in the same network. The key is then copied on a Linux system and this system is connected through a tunnel to the first windows machine.
  • Chapter 6 shows how to create x509 server and client certificates for use with OpenVPN. easy-rsa which comes with OpenVPN and is available for both Windows and Linux is used.
  • Chapter 7 reviews the syntax of the command line tool openvpn, which enables building tunnels quickly. The configuration options of openvpn are covered in detail with examples.
  • Chapter 8 shows how to make the example tunnels created earlier safer and persistent by choosing a reliable combination of configuration file parameters. It then covers how to configure firewalls on Linux and Windows to work with OpenVPN.
  • Chapter 9 focuses on using xca, the advanced Windows tool with which x509 certificates can be easily managed. Its Linux equivalent, Tinyca2, which can even manage multiple certificate authorities, is also covered.
  • Chapter 10 covers advanced OpenVPN configurations, including Tunneling through a proxy server, pushing routing commands to clients, pushing and setting the default route through a tunnel, Distributed compilation through VPN tunnels with distcc, and OpenVPN scripting.
  • Chapter 11 shows how to debug and monitor VPN tunnels. It covers standard networking tools that can be used for scanning and testing the connectivity of a VPN server.

Although this may seem like a strange subject for this blog, I have recently become interested in the concept of Virtual Private Networks (VPN) because of the increasing number of attacks on Asterisk-based system based on spoof SIP credentials. SIP, the most popular protocol for VoIP, is an inherently insecure protocol – it relies on password protection only, and on most Asterisk boxes and in many VoIP devices and software products, the password is stored in plain text. On many systems, the user name is the same as the extension number, so all a potential intruder has to do is start a brute-force attack guessing passwords. The use of strong passwords along with the use of software like Fail2Ban (with iptables) can help minimize the exposure, but in the end it’s still only password protection.

Therefore, my feeling is that it would be much better to restrict extensions to access from within the local network (wherever possible), using the permit/deny fields in FreePBX or some similar mechanism, and then “tunnel” remote extensions through a secure VPN, so they appear to be on the local network.  The VPN could do the heavy lifting for security (even making the actual calls secure, although that wasn’t a priority in my situation).  My problem was that I knew next to nothing about VPN’s, and most of the pages on the Web seemed to assume at least some prior knowledge.  I needed something that would take me from zero knowledge to VPN guru.  Unfortunately, at my age it’s a case of “the spirit is willing but the brain is a bit weak”, so I realized that the “guru” part might not come very quickly (just as a comparison, I’ve been playing with FreePBX since back in the Asterisk@Home days, and there’s still a lot I don’t understand, but for the first year or so I felt totally lost).

Since the folks at Packt Publishing were willing to send me a review copy of OpenVPN: Building and Integrating Virtual Private Networks, I decided to see if I could actually learn anything from the book.  The first thing you need to know is that there are many types of VPN’s out there, and each will only communicate with its own kind, as it were.  The problem with most other tunnels is that they are either not all that secure, or contain proprietary code, or are incredibly complicated to set up and use (or some combination of the above).  OpenVPN has several advantages, perhaps the biggest being that it’s open source (so you can, if you are so inclined, examine the code and make sure there are no “backdoors” built in), that it can be as secure as you want it to be (and it’s not that difficult to make it very secure), and that it doesn’t rely on a third-party service over which you have no control (like one VPN application that touts itself as “zero-configuration”). So of all the VPN methods out there, OpenVPN seemed like a logical choice.

Now, having said that, the book covers its subject in a very logical manner.  Advanced readers (those already familiar with the principles behind VPNs) might find the introductory material in the first chapters a bit tedious, but believe me, it was just what I needed to help me get a grasp on the subject. As you go further through the book, there are many actual examples, first showing how to set up a working VPN tunnel, then how to add additional security, and finally how to troubleshoot connections.  If you are brand new at this, like me, you will probably find that you learn a great deal from the first chapters but find the latter chapters (especially Chapter 10) a bit beyond your comprehension at first.  However, the person who has some networking or VPN experience under their belt may think the first chapters a bit elementary, but will find the real meat they are looking for in the latter parts of the book. Either way, I guarantee you will come away with a greater comprehension of the subject.

The book shows how to install OpenVPN on several platforms (Windows, Mac OS X using Tunnelblick, FreeBSD, and SuSE, Debian, and Redhat/Fedora based versions of Linux), but it seems like some platforms are better covered than others.  A disproportionate number of examples and screenshots seem to be based on a Windows installation, whereas the Mac gets very little coverage. Because there are so many variations of Linux, the coverage there is mixed, although it seems like SuSE and Debian are better covered than Fedora-based versions, which was just a little bit disappointing because most Asterisk and FreePBX systems are based on CentOS, which is a Fedora-based OS. But most of the information in this book is not OS specific, so I didn’t have any real problem following along.

The biggest disappointment for me was in Chapter 8, where the book covers the use of Webmin, but primarily as an aid to administration of the Shorewall firewall.  Many Asterisk/FreePBX systems don’t use Shorewall, but instead use iptables (if they have a firewall on the Asterisk server at all).  But what was really disappointing was that there was no mention of, nor instructions for the use of the OpenVPN + CA module for Webmin (page is in Italian, but here is a description in English). I can only guess that because the book was first released in May,  2006 and version 1.0 of the Webmin module had only just been released in January of that same year, the author perhaps hadn’t had an opportunity to work with the module before the final draft of the book was submitted to the publisher. I hope that if this book is ever updated and republished, there will be consideration given to adding a chapter on the use of the Webmin module to set up and administer OpenVPN. In the meantime, you can find instructions for using the OpenVPN + CA module in The ‘Point and Click’ Home VPN HowTo Guide.

That said, I felt I learned a great deal from this book.  I was able to set up an OpenVPN server (using the Webmin module, but the book definitely helped me understand the purpose of the various options, and when I checked the configuration file that the module generated I was able to spot a couple of things that weren’t the way they should be for my setup and was able to change them) and the Windows client.  It all worked beautifully.

My project now, when I have absolutely nothing else to do, is trying to get the OpenVPN client running on an Asus WL-520gu router that has the DD-WRT firmware installed (I inherited this project from someone else who couldn’t do it).  So far this has proven to be a tough nut to crack – although it should be easy because (if you get the right version of DD-WRT) there is a built-in OpenVPN client with a handy configuration page, it just doesn’t seem to work “out of the box” – and from what I’m reading on the ‘net, for every one person who says they’ve got it working, there are about twenty others who have become incredibly frustrated by the process (example here – note that the original poster says he got it working, but that’s followed by about 16 pages of comments, mostly by people who just can’t seem to get it to go).  It’s a bit strange because the Windows client will work perfectly (indicating it’s not an issue with the server) but the firmware client in DD-WRT just doesn’t seem to work.  If I ever get it figured out, I’ll try to post what I did in this blog, but so far I’ve had no luck.  That, however, is not the fault of the book – in my opinion it’s the fault of the writers of the DD-WRT firmware, who apparently included a half-baked OpenVPN client interface in the firmware (I know, it’s free software so I can’t really complain, but one does wish that they’d taken a bit more care to make sure it worked).

After having read the book, I do feel fairly confident that if I should throw in the towel and decide to dump DD-WRT and install a different firmware on the router (I’m thinking about trying the Tomato firmware with USB support) I would be able to install an OpenVPN client from scratch and make it work.  Probably the main reason I haven’t wanted to do that is because I very much prefer using a GUI to do things, and would like to try to make the OpenVPN GUI in DD-WRT work (even if it requires a little help), but so far that doesn’t seem to be panning out.

But I digress a bit – anyway, if you are wanting to learn about OpenVPN, whether or not you are a rank beginner you will benefit from this book. The numerous examples and screenshots make it almost impossible to fail to get an OpenVPN tunnel up and running (providing you’re not using a questionable firmware client). And, as I said above, the book is laid out in a very logical progression, so I really didn’t feel totally lost at any point (as so often happens when I try to read technical books). Especially in the case where your boss suddenly decides he needs VPN tunneling capability, and wants you to have one up and running in a very short timeframe, this would be the book to get!

OpenVPN: Building and Integrating Virtual Private Networks by Markus Feilner (Amazon affiliate link)

EDIT: This book has been updated and expanded under a new title — see Mini-review of Beginning OpenVPN 2.0.9 by Markus Feilner and Norbert Graf (Packt Publishing)

Improve the Mac’s ability to display colors

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which in turn was reposted with the permission of the original author from a now-defunct Macintosh-oriented blog. It is reposted with his permission.

This article was originally posted in January, 2009.

One issue that some Mac “switchers” have encountered is that the colors on the Mac display look just a bit washed out compared to those on a PC. It’s generally not enough of a difference that anyone would complain; in fact, many new Mac users would think it was their imagination, or would attribute the difference to hardware variations (different display or graphics card).

In reality, however, there is a difference, and it is due to a configuration choice made by Apple. There is a page that describes the issue in some depth:

A solution to Mac “Save For Web” colour discrepancies

The gist of the problem is that Apple has chosen to, by default, go with a gamma setting of 1.8, whereas other systems use 2.2 as the default. On the above-mentioned page, it gives this bit of wisdom: “Unless you have a color management expert instructing you otherwise, select a 2.2 gamma and a D65 white point.” However, the white point is not as important as the gamma, and you may wish to use the default white point that has been determined to be right for your display. It’s most important to change the gamma setting, and calibrate the display in the process. How do you do this? By setting up a new color profile. This is fairly easy to do.

First of all, if you are using the “Shades” program (or any other program that gives you software control over display brightness or any other display parameter), go into the program or preference panel and turn it off before you begin this process, otherwise it may fight you at every step of the calibration process, turning an easy task into a really difficult one with less than satisfactory results.

Go to System Preferences, click on Displays, then go to the “Color” tab, then click on “Calibrate”:

System Preferences-Display-Color Tab
System Preferences-Display-Color Tab

Then follow the instructions. BUT, before you change the setting of your display’s contrast (using the control on the display itself), make a note of the current setting. You will be changing it as part of the calibration process but once you are all finished, you may decide that you want to go back to that setting, or something reasonably close.

During the calibration, when you are asked to adjust the monitor’s brightness, it will say to set it to where you can “just see” the oval:

Display Adjustment screen
Display Adjustment screen

The only problem is, Apple’s idea of “just seeing it” and yours might be a bit different. We wound up using a setting that was a bit more than where the oval was just barely perceptible, but still a bit less than where the two halves of the surrounding rectangle started to appear as different, and that seemed to work best. Originally we tried setting it where the oval was just barely perceptible, but then after the adjustments were completed we couldn’t get a monitor setting that we liked (everything was too dark for our liking, particularly on some of the wallpaper).

When you get to this screen:

Target Gamma Selection
Target Gamma Selection

You want to select the “2.2 Television Gamma” because that is the setting used on most non-Apple computers, and therefore that is the setting that most graphics (including those on the Web) are adjusted for. This is the setting that Apple probably should have used in the first place – at least they give you the option to use it, but we think it should have been the default. On the next screen you’ll be asked to select a target white point:

Target white point selection
Target white point selection

We suspect that “D65″ and “Native” are very close on modern displays (perhaps even identical). You can try both and see which works best, or you can just go with the recommendation from the above-mentioned article to use D65.

EDIT: The second time I attempted to do this, the display calibrator crashed before I could save the settings.  If it happens to you, try this: In Finder navigate to Macintosh HD/System/Library/ColorSync/Calibrators/Display Calibrator.app and right-click on the application, then click on “Get Info”, and when the information panel is displayed, you should see a checkbox for “Open Using Rosetta.”  Check that box, and the problem goes away (at least it did for me, and for the people who posted replies in this thread).

When you are all through, you are likely to see color in places that only looked grey or washed out before. That is because Apple’s default color profile and gamma setting tends to wash out certain colors. But, unless you have just acquired your Mac, it will look strange to you, because it’s not what you’ve become used to. You may have to try adjusting the monitor’s brightness and contrast to get something you like. The interesting thing is that whites may seem “whiter” than before and that may throw you a bit, but it will also show how screwed up Apple’s default color profile is. Try it for at least a day or two before you decide you don’t like it. We found that by setting the monitor’s contrast back to the original setting (the one we told you to note in the previous paragraph) and then using the brightness to adjust the monitor for best picture yielded the best results, but your results may be different.

If you decide you really hate the calibrated profile, you can always go back to the default Mac color profile for your monitor, but then you can expect displays on other computers to look strange. Keep in mind that if you’ve gotten used to looking at washed out colors, it may take some time to adjust!

Stop entering passwords: How to set up ssh public/private key authentication for connections to a remote server

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which in turn was reposted with the permission of the original author from a now-defunct Macintosh-oriented blog. It is reposted with his permission. Comments dated before the year 2013 were originally posted to The Michigan Telephone Blog.

This article assumes that you are already able to ssh into a remote server using a password (that is, that your account has been created on the remote system and you are able to access it). Here’s how to set up ssh public/private key authentication so you don’t have to use the password on future logins, or so you can use Public Key authentication with MacFusion.

First, open a terminal or iTerm window as we will be using it for most of the following operations. First, navigate to your home directory, and see if there is a folder called .ssh. Note that Finder will NOT show you this directory unless you have it set to show all file extensions, so since we are at a command line prompt anyway, it’s easiest to just type “cd ~” (without the quotes) to go to your home directory in Terminal or iTerm and type “ls -a” (again without the quotes – always omit the quotes when we quote a command) to see if the .ssh directory exists. If it does, go into the directory (”cd .ssh”) and see if there are two files called id_rsa and id_rsa.pub (use “ls -a” again). If either the directory or the files do not exist, you will need to create them.

ssh-keygen -t rsa -f ~/.ssh/id_rsa -C "your@emailaddress.com"

Replace your@emailaddress.com with your email address – this is just to make sure the keys are unique, because by default it will use your_user_name@your_machine_name.local, which might come up with something too generic, like john@Mac.local. It’s unlikely that anyone else is using your e-mail address in a key.  If this process fails with a “Permission denied” error, it might be because SELinux is enabled.  To check that theory, see How to Disable SELinux, which will show you how to disable it temporarily (for testing) or permanently.

Now, from your terminal window on your local system, execute this command:

ssh-copy-id username@remote

You can run ssh-copy-id -h or man ssh-copy-id to see the available options, but normally you don’t need any. In the event your system does not have ssh-copy-id installed, you can instead run the following three commands from a terminal or iTerm window on your local system. Whichever method you use, replace username with your login name and remote with the address of the remote system. Note that you should NOT be logged into the remote system when you execute these – these are run from a command prompt on your local system, and you probably will be prompted to enter your password (for the remote system):

ssh username@remote ‘mkdir ~/.ssh;chmod 700 ~/.ssh’

The above creates the .ssh directory on the remote system and gives it the correct permissions. If the command fails (for example, I’ve had it complain that mkdir isn’t a valid command, even though it is on just about every Unix/Linux system), then either you have copied and pasted the above line and WordPress changed the single quotes to the “prettified” versions (so change them back) or you may have to actually log into the remote system (using a password) and enter the two commands individually (mkdir ~/.ssh followed by chmod 700 ~/.ssh). Then, if you don’t already have an authorized_keys file on the remote system, go back to your local terminal or iTerm window for this:

scp ~/.ssh/id_rsa.pub username@remote:~/.ssh/authorized_keys

The above creates a new list of authorized keys on the remote system (overwriting any existing file with that name) and copies your public key to it.  If you already have such a file and don’t want it overwritten, then you’ll have to manually add the contents of your local ~/.ssh/id_rsa.pub file to the end of the ~/.ssh/authorized_keys file on the remote system.

ssh username@remote ‘chmod 600 ~/.ssh/authorized_keys’

This fixes the permissions on the authorized_keys file on the remote system. Once again, there may be the odd situation where you can only run the command within the single quotes from the remote system.

And, that’s basically all there is to it. If you are the system administrator of the remote system, but you don’t ever plan to login from a remote location as root, then for extra security edit the file /etc/ssh/sshd_config on the remote system (you’ll probably have to be root, or use sudo to do this task). Just use your favorite text editor on the remote system to open the file, and look for a line that says:

PermitRootLogin yes

And change the “yes” to “no”.

If you are still asked for a password after you are finished making the above changes, look for a line in /etc/ssh/sshd_config that says:

StrictModes yes

And change the “yes” to “no”. You’ll need to reboot or restart the ssh server for this to take effect. An alternate, and probably more secure fix is to check the permissions on your home directory – if it is not writable by anyone but the owner, then it should not be necessary to change the StrictModes parameter. For more troubleshooting hints see Debugging SSH public key authentication problems.

The above are very basic instructions for setting up ssh public/private key authentication. There are other ways to do this (including some that are arguably a bit more secure) but we wanted to keep it simple. Hopefully this will help someone who is using ssh, MacFusion, etc. and wants something a bit more secure and less bothersome than password access.

One other note:  If you find the connection drops within a minute or so, particularly after you’ve just purchased a new router, then on the client machine running Mac OS X edit the file /private/etc/ssh_config (under Linux it’s /etc/ssh/sshd_config and I don’t know what it would be called under Windows, or if they even have such a file) and add this line:

ClientAliveInterval 60

If it still stops working lower the timeout to 30. See How to fix ssh timeout problems for more information.

If you find my instructions confusing, try SSH Passwordless Login Using SSH Keygen in 5 Easy Steps.

And, for hints on making ssh more secure (particularly if you permit access from the Internet in general and not just your local network), see this article on Securing OpenSSH (via the CentOS wiki).

How to install Midnight Commander under Mac OS X (the easy way, using Rudix)

 

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.
Mc-screenshot
Image via Wikipedia

EDIT: New article for Midnight Commander users: Fixing Midnight Commander’s unreadable dropdown menus.

EDIT: This article has been revised to show the latest information as of 2012. Note that these instructions probably will not work unless you are running a relatively recent version of OS X. Also, you really should read How to install Midnight Commander under Mac OS X (the easiest way?) before using the procedure shown here!

I have to admit, I am one of those people who dislikes Linux for one major reason: Whenever you ask for help in any online forum, the knowledgeable people all seem to be command-line devotees, and they invariably give you instructions that involve typing long, arcane commands into the command line. I hate using the command line – if I had wanted to use a command line, I’d never have moved away from MS-DOS, and i cannot understand why Linux geeks insist on using it, and on trying to get others to use it.  Even users of Linux distributions such as Ubuntu have found that when they go online asking how to do some function that could easily be accomplished using one of the GUI tools, often some obnoxious twit helpful person will reply by giving a bunch of stuff (that makes no sense at all to the uninitiated) to type in at the command line. One of the things I like most about Mac OS X is that you almost never have to do anything from a terminal prompt if you don’t want to, and Mac users seem to have a healthy disdain for using a computer as if it were still the 1970’s.

Long ago, when I was using MS-DOS, there was one tool that I had to have on any system I was using: Norton Commander.  The original, dual-pane file manager that made it oh-so-easy to do typical file manipulations like copying and moving files, viewing and editing text files, launching executables, etc.  without typing in DOS commands.  Norton Commander was such a great program that it inspired similar programs on other platforms, such as Total Commander under Windows, and the cross-platform muCommander that runs on just about anything (if it has Java installed).  In the Linux world, KDE users have Krusader, and Gnome users have Gnome Commander.

Mac OS X users have a number of choices, including the aforementioned muCommander and Xfolders, both of which are free.  Possibly the best alternative today is XtraFinder, which is excellent and free — it add tabs and other features to the OS X Finder, and can display dual panes in either a horizontal or vertical alignment.

However, despite your best intentions, there may come a time when you find yourself working at a shell prompt.  Maybe you are working with a Linux server, or on a Mac, maybe you can’t get OS X to come up but you are able to get to a terminal prompt (in my early days of using a Mac, this happened to me twice after OS X upgrades). More commonly, you are getting a permissions error on some file and can’t understand why – that’s very rare on the Mac, but it happens, and now you find yourself in the terminal trying to remember how to change permissions or ownership on a file (by the way, in most cases you should be doing this by right-clicking on the file in Finder,  then clicking on “Get Info” in the context menu, and then using the Sharing & Permissions section at the bottom of the information panel. But there are occasions when nothing else seems to work, and you want to go a bit deeper into the guts of the system). It is at those times when Midnight Commander may be the tool you want.

However, up until now there has not been a really easy way to install Midnight Commander on a Mac running OS X (at least not that I’ve seen).  But now, there is a package by Rudá Moura called Rudix, which is described this way:

Rudix features a world class collection of pre-compiled and ready to use Unix compatible software which are not available from a fresh installation of Mac OS X but are popular among other Unix environments. Here you can find utilities, programming languages, libraries and tools delivered as standard Mac OS X packages.

Now, I hear some of you “cut-my-teeth-on-Unix” types screaming, “What about MacPorts? What about the Fink project?”  Those are all well and good if that’s your cup of tea, but they require a much higher lever of Unix “geekiness” to install, and they add a lot of code that the typical user doesn’t need.  Rudix will let you add a whole bunch of Unix utilities if you really want to do that, but if you only want a few needed utilities then the “Custom Install” button in the Rudix installation lets you select exactly what you want, and no more.

So here is how you would install Midnight Commander in Mac OS X, using Rudix:

Go to the Rudix mc: Midnight Commander page. Select the correct package for your version of OS (filename ends in .pkg) and click on the package filename. On the next page, click the package filename again to download it to your computer. When it has downloaded, double click on it to run it. You should see a screen like this:

Rudix - Midnight Commander installer
Rudix – Midnight Commander installer

Click “Continue” and continue to do so until it has been installed. That’s all there is to it!

I should point out that this used to be a much more convoluted process, and there was a much longer set of instructions here explaining it, but all those old instructions are superfluous now.

Once you have installed Midnight Commander, you will realize that you can easily install many other utilities commonly found on Unix/Linux systems, if they are available in the Rudix package list. Personally, I would not go hog wild on this – I’d only install the utilities you actually need, as you need them. One package I typically install is wget, because so many scripts (such as those written in Perl) expect it to be present.

Edit March 28, 2008: I made an interesting discovery tonight.  Normally I use iTerm as my terminal program, and Midnight Commander runs fine in that. What it does not seem to run so well under is the Terminal.app program that comes with OS X. What specifically does not work in Terminal.app, at least on my system, is the mouse.  Under iTerm, mouse clicks get passed to Midnight Commander in the normal manner, but under Terminal.app that doesn’t seem to be the case. Another thing that you can do in iTerm (but not Terminal) is hold down the ⌘ (Command) key and right click on a file to select it. So, for the “best user experience”, so to speak, I’d suggest downloading and installing iTerm, which has a lot of other nice features you’ll probably appreciate (and did I mention it’s free?).

Edit April 1, 2008: If, for some reason, you want to modify the color theme of Midnight Commander, here are a couple of blog posts that show how to do that:

And, the Midnight Commander manual is another good source of information on this subject.

Command line haters of the world, untype!

Regular Expression Laboratory

 

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.

If you are like me and haven’t had to do much with regular expressions, but every so often encounter them (or worse yet, want to create one), you may find this free software useful. It’s called Regular Expression Laboratory and this is the description:

Regular Expression Laboratory is an assistant simple to use tool to help you learn and prepare regular expressions.

If you are a developer or just concerned with text processing tasks, the Regular Expression Laboratory is a tool that you need. In fact, you felt that you need a program like this but could not formalize your needs. We have done this job for you. Now you can construct your regular expressions with much ease and test them by applying to an arbitrary text.

Regular Expression Laboratory support the incredible size of a stored regular expression: 2MB!

This could be a useful piece of software for those that have pulled their hair out trying to construct, or to interpret someone else’s regular expressions.

Featured Article:

Recent Posts

Recent Comments

Archives

Categories

Meta

GiottoPress by Enrique Chavez

%d bloggers like this: