Poor Man's Tech

PBX in a Flash vs. trixbox

2008-03-04T12:46:00.003-04:00

As promised, I have spent some time comparing the various benefits of PBX-in-a-Flash over trixbox. In a nutshell, my conclusion is relatively straightforward.

It's worth switching.

Why, you may ask? Well, the reasons are many and varied, but here are the high points:

1) Upgrades. If you've spent any time poring over the various email lists for trixbox, you will quickly come to realize that the general consensus with respect to upgrading trixbox is as follows: if it ain't broke, don't fix it. Upgrading trixbox can be a nightmare (something I've personally experienced), and the simplest solution is to either (a) live with an older version; or (b) do a clean install. Upgrading PBIAF, though, is really, really simple, and it actually works. Everything is web-based, wizard driven, and painless. In fact, the default installation regularly checks for both core and module upgrades, and offers to do it for you.

2) Extending functionality. PBIAF has a rapidly growing set of modules that are simple to install, and add nice functionality to the base system. Wait, you say -- so does trixbox! Well, yes, it does, but when it comes to installing and upgrading these modules, PBIAF is the hands down winner.

For these two reasons alone, it's worth the upgrade.

Highly recommended.

PBX in a Flash

2008-02-21T16:12:00.001-04:00

Last week I downloaded and installed the new PBX in a Flash alternative to Trixbox. I have had excellent luck with Trixbox, and no real complaints, but I like to keep abreast of things, had some time on my hand, and thought I'd give it a whirl.

I am impressed.

Installation was simple, and it has all the functionality of Trixbox, and then some. Like Trixbox, it uses FreePBX for the actual management of the PBX, but unlike Trixbox, it runs on CentOS 5, and lacks the annoying "feature" of having all Zap functionality die if you happen to be running on a non-multicore CPU.

There are a host of modules already available, including some nifty text-to speech features, but I haven't had an opportunity to test those as of yet. I plan on doing so next week, just to see how things work.

One added bonus -- for some reason, PBX-in-a-Flash actually fixed one annoying problem I had with Trixbox: on my outbound trunk using Vonage, I often had problems with IVRs (when I was dialing the phone company to complain about another billing error, for example). The whole "press one for sales, two for tech support" etc. didn't work a lot of the time. Now it does.

That alone was worth making the switch.

Browse securely with OpenVPN

2007-12-18T10:30:00.002-04:00

Sometimes you find yourself in a situation where you are forced to connect to the outside world through a decidedly insecure connection. Perhaps you are in an airport, using free Wifi, or a hotel room. Or, maybe you happen to be on the Rogers network, and you've read about the tendency of that ISP to watch what you are doing on line. Whatever the case may be, you are in a situation where security is somewhat less than ideal. If you have access to a machine on a secure connection somewhere else in the world, and that machine has either a static IP address or is configured through a free service such as dyndns.org, you can set things up so that all your Internet traffic is encrypted, and passes through the known, secure machine before coming to your local machine.

This is not difficult to set up.

First, you have to have OpenVPN server set up on the remote machine. We have covered this before, so if you don't have it in place, then go install and configure it. The instructions here are virtually identical to those we set up before, with one important difference -- we are going to tell OpenVPN to redirect all traffic through itself, so nothing going to your local machine (which I'll call a laptop) or leaving it will pass unencrypted. You are browsing so that all traffic is SSL encrypted.

You will recall that OpenVPN server is conrtolled using a file in /usr/local/etc/openvpn (at least on FreeBSD). Copy that file to one called "openvpnredir.conf" and edit it. We are going to change two things: the port that OpenVPN listens to, and we are going to add a directive that tells OpenVPN to redirect all traffic through its secure connection. Here is the file, with the changes higlighted in red.

# Specify device
dev tun

port 1195

# Server and client IP and Pool
server 10.9.0.0 255.255.255.0
ifconfig-pool-persist ipp2.txt

# Certificates for VPN Authentication
ca /usr/local/etc/openvpn/ca.crt
cert /usr/local/etc/openvpn/server.crt
key /usr/local/etc/openvpn/server.key
dh /usr/local/etc/openvpn/dh1024.pem

# Routes to push to the client
# in the next line 192.168.xxx.0 should be the ip range of your internal network
push "route 192.168.xxx.0 255.255.255.0 default"

# route all traffic through vpn
push "redirect-gateway def1"

# Use compression on the VPN link
comp-lzo

# change the ip address in the next line to whatever dns you want to use
push "dhcp-option DNS 192.168.0.100"

# Make the link more resistant to connection
failures keepalive 10 60
ping-timer-rem
persist-tun
persist-key

# Run OpenVPN as a daemon and drop privileges to user/group nobody user nobody
group nobody
daemon

As you can see, the changes are minimal. Now, on the client side, find the configuration file you use to set up a VPN connection. On Macs, it's in ~/Library/openvpn. On Windows, it's usually in C:/Program Files/OpenVPN/config.

Duplicate that file, and change the name to something meaningful (i.e. Redir OpenVPN, or whatever), and then change the line that reads "port 1194" to "port 1195".

Now, you should have a new vpn connection available to you, and all traffic will go through the VPN server.

Trixbox phones home?

2007-12-17T09:46:00.000-04:00

Nerdvittles has an interesting post today -- apparently, trixbox phones home at 3:41 AM each day and gets a list of shell commands to run:

You may have read that a user discovered last week that current trixbox systems as recently as today include a remotely-configurable BOT, a software program that can execute certain commands locally once it receives its instructions. Reportedly, trixbox’s registry.pl “phones home” to Fonality via the Internet at 3:41 a.m. each morning to get a list of Linux commands to run. It then executes those Linux commands on your server while you’re sleeping. If the assertions of trixbox end users are true and we have no reason to believe otherwise, the existence of this remotely-configurable BOT had never been disclosed to unsuspecting users whether they were individuals or corporations. In fact, it doesn’t appear that even trixbox resellers were aware of the existence of the remotely-configurable BOT.

This is interesting, and disturbing. To be fair, the folks at Nerdvittles suggest that they "don’t for a minute believe that Chris Lyman and other senior management of Fonality knew about this in advance", but they certainly know about it now!

This is cause for concern. Since the ability to remotely execute shell commands exists, it's only a matter of time before someone else figures out how to exploit it.

Maybe it's time to accelerate my testing of pbx-in-a-flash....

Use the Linksys SPA922 as a Remote Extension

2007-11-12T09:03:00.000-04:00

Last time I mentioned that I had used the Linksys SPA922 IP Phone as the "handset of choice" for phones. I also indicated that I wanted to have one as a remote extension -- i.e., it has a standard extension number, is part of the PBX system, can make and receive calls, etc., but is physically outside of the network.

This turned out to be relatively easy, once I figured out the firewall settings.

Setting up a remote extension using Asterisk/Trixbox is not that difficult, and consists of three basic steps:

1) Create the extension in Trixbox

2) Make some firewall modifications on the trixbox end

3) Plug in and configure the remote extension itself (i.e. the physical phone)

These steps are explained in more detail below:

Create the Extension in Trixbox

First we need to have an extension to play with, so we'll log onto our Trixbox installation using our favourite web browser, and choose "FreePBX" from the "Asterisk" menu. This pops up a new browser window (or tab) and allows us to create a new extension, among other things. Choose "Setup" from the top menu, then "Extensions" from the menu on the left, and create a new SIP extension. Fill in values similar to the ones below, substituting where appropriate for your information. For example, a "secret" of "verysecret" is probably not a good idea.

Make certain that you have "nat" set to "yes".

The only other thing we need to take care of within Trixbox is a tiny modification to the sip_nat.conf file. Again, we can do this using our web browser. Close the browser window with FreePBX running, and you should be back in the Trixbox admin window. Choose "Config Edit" from the "Asterisk" menu, and then scroll down until you find "sip_nat.conf". In a default installation, it is empty. Put in values like the following:

extern_ip=xxx.xxx.xxx.xxx
localnet=192.168.0.0/255.255.255.0

The first line, extern_ip, is the external (public facing) ip address of your Trixbox. Note that you probably don't have one, so instead put the public IP of whatever router, gateway, etc. you use to get access to the outside world.

The second line, localnet, describes the subnet that your Trixbox installation lives on.

Now, reload your configurations in Trixbox, and we are ready to configure our firewall.

Firewall Modifications

We need to make some modifications on the Trixbox end of the network (i.e. not at home, if that's where your remote extension is, but on the the end of the connection where your Trixbox PBX lives). Specific modifications will vary depending on what you are using for a router/gateway, but in general there are only a few things to change. I am using a Linksys machine as the external gateway, so I made changes as follows:

In essence, forward the following to your Trixbox machine:

5004-5082 udp
16384-16482 udp
10001 - 20001 udp
4569 udp (optional, and only for IAX2 units; ignore if you are just using sip)

Make these changes, and we are ready to set up the phone itself.

Configure the SPA922 IP Phone

As before, I simply unpacked the phone, found a place for it on my desk at home, and plugged it in. After a few seconds, it found itself an IP address and did its best to find dial tone. Naturally, it failed, but I did appreciate the effort.

All configuration on the SPA922 can be done with a web browser... but you need to know what IP address to connect to. After it has powered up, click on the "menu" button on the handset. It looks like a dog-eared piece of paper, just below the voice mail button. Now use the navigation button (big circle with four arrows) to scroll down to Network, and click the select soft button (leftmost, just below the LCD. Its label is part of the LCD). You'll see your phone's IP address displayed on the LCD. Mine was set to 192.168.2.149.

So, fire up your web browser, and go to http://192.168.2.149, or whatever IP address your phone has. You'll see the Linksys screen. Click on "Admin Login" in the upper right hand corner, then "Advanced." Note that by default the phone ships with no password for the admin tool; please remember to change that at some point (like right now).

Click on the Ext1 tab, and scroll down to NAT Settings. Set NAT Mapping Enable and NAT Keepalive Enable to "YES". Scroll down to SIP Settings. Set SIP Port and Ext SIP port both to 5062.

Next scroll down to the "Proxy and Registration" section. Set "Proxy" and "Outbound Proxy" to the external IP address used by your Trixbox machine. Set "Use Outbound Proxy" and "Use OB in Dialog" to "Yes".

Scroll down to Subscriber information, and set User ID to the extension number for your phone, and password to whatever "secret" you set up in Trixbox for this extension.

Now scroll down to Audio Configuration. Set DTMF Tx Method to "Inband+INFO". (Note: I had to do this to get most IVRs to work, i.e. when I call someone and have to press 1 for this, 2 for that, and so forth. YMMV).

Click on "Submit all Changes."

Now, go to the SIP tab. Scroll down to RTP Parameters. Set RTP port min to 16384. Set RTP port max to 16482. Now, scroll down to NAT Support Parameters. Set Handle VIA received, Insert VIA received, Substitute VIA address, Handle VIA rport, and Insert VIA rport all to "Yes."

Save your changes, and in a few moments, you should be able to make calls!

Alternative to Trixbox coming soon

2007-10-21T12:09:00.000-03:00

The folks over at nerdvittles.com have an interesting project in the works -- PBX in a Flash. Apparently they (and others) are getting a bit fed up with the direction that Trixbox is taking; on the nerdvittles site, the authors put it this way: "suffice it to say that it’s just gotten a little too proprietary, too closed, and too commercial for our open source, puritanical tastes."

So they decided to take matters into their own hands, and are working on something called "PBX in a Flash". From the site:

Our up front promise is to keep the project open, participatory, reliable, and fun. After all, that’s what the Asterisk revolution was and is all about. The plan is to provide a free ISO-based offering for home or office use that will run on a dedicated Linux machine. There also will be a VMware image that will run on a Windows desktop. And, for the Mac desktop, we’ll provide both a VMware and a Parallels image.

I'll be interested to see where this goes, and intend to give it a try.

Trixbox and the Linksys SPA922

2007-10-21T11:43:00.000-03:00

I got tired of trying to figure out how to wire my office such that we could continue to use the analog phones we have with the Trixbox setup I recently installed. Accordingly, I bit the bullet and ordered some Linksys SPA922 phones as a trial run. These are true IP phones, meaning that all they need hooked up to them is an ethernet cable (and a power adapter, if you are too cheap to purchase the Power over Ethernet adapter).

These are wonderful phones.

Setting it up on the internal network was absolutely trivial. Unpack it, hook up the handset, run an ethernet cable to it, and tell it what extension id and password you want, and you are finished. In fact, it's so easy to set up that I really can't see the point of posting the details here.... the quick start guide that comes with the phone is self explanatory, and so simple my 10 year old daughter could probably figure it out.

As a bonus, the various "star key" combinations are pre-configured to work with Asterisk, so I didn't even have to set those up. Right off the bat the call forward, do-not-disturb, and voice mail keys worked.

Great phone.

Next, I'm going to try to hook one of these up as a remote extension, and have an office phone at home as well. My understanding is that this would be easier with an IAX2 phone, but I don't have one of those, so I'll figure out how to do this with what I have at my disposal.

Using the Vonage SoftPhone with Asterisk

2007-10-18T19:14:00.000-03:00

As promised, here are some more details about setting up an Asterisk system for a small office/home office. Last time we got a single hard line up and running, and this time we are going to add true VOIP functionality to our system.

You may have been reading about Vonage in the news a bit lately. Yes, they are under some serious attacks by the established telcos, but they offer a wonderful service -- easily the best quality VOIP I have tried. More to the point for this exercise, Vonage offers a service that interfaces nicely with Aterisk -- the softphone.

Vonage offers a softphone option for existing customers -- in Canada, at least, it's an add on to an existing service, and costs around $15.00/month. I understand it is less expensive elsewhere, but even at $15.00, it's fairly cheap.

I wanted to have my outgoing calls on the office network not be limited to the number of hard lines from our local telco; voip is, of course, a wonderful alternative to this, and (at least around here) Vonage's offering is every bit as good as a telco. At least none of my customer's have noticed the difference...

Here's how to set up the Vonage softpone as a trunk (inbound and outbound) on Asterisk (specifically on Trixbox).

1) Add a trunk. In FreePBX, choose Setup -> Trunks -> Add Trunk. Name the trunk whatever your softphone number is, i.e. 19995551212.

2) Outbound caller id - this appears to no have effect, but I set mine up anyway, i.e. "Caller id Inc" <19995551212>
3) For "Peer Details" I used this:

allow=all
auth=md5
canreinvite=yes
defaultexpirey=120
dtmfmode=rfc2833
fromdomain=sphone.vopr.vonage.net
fromuser=[vonage phone number]
host=sphone.vopr.vonage.net
insecure=very
nat=yes
port=5061
secret=[secretgiventomebyvonage]
type=friend
username=[vonage phone number]

Note that "secret" and "username" must be changed to whatever you got from Vonage. Also, the "square brackets" are not part of the peer details.

4) Under User Context, I entered this:

auth=md5
canreinvite=no
context=from-pstn
dtmfmode=inband
fromdomain=sphone.vopr.vonage.net
fromuser=[vonage phone number]
host=sphone.vopr.vonage.net
insecure=very
nat=yes
port=5061
secret=[vonage password]
type=friend
username=[vonage phone number]

5) For register string, I used this:

[phone]:[secret]@sphone.vopr.vonage.net:5061

For example, if your phone number is 1-999-555-1212 and your secret is abcd1234, you would enter:

19995551212:abcd1234@sphone.vopr.vonage.net:5061

Save, and your trunk is now active. Next, we need to add outbound routes.

Last time around, we added a context for dialing out by pressing 9. We are going to modify that so that by default, all outbound calls first go out through vonage, and if that fails or is too busy, then use the hard line. This is trival.

Modify your outbound route "0 9_Outside". Scroll down to Trunk Sequence, and use the drop down menus to select the first as being vonage, and the second as your hard line. Save, and you are done.

That was easy.

Asterisk, Trixbox, and the Linksys SPA 3102

2007-10-16T14:14:00.000-03:00

I have finally completed my Asterisk installation, and have it working. Surprisingly, it was fairly painless. As I had indicated in an earlier post, I intended to get it working using a single incoming analog line, a Linksys Sipura 3000, and a fairly elderly PC. Much to my surprise, I was able to procure a 1.8 GHz Pentium IV machine for less than $200.00, and it works very, very well.

The Linksys Sipura 3000 had been replaced by the SPA 3102 by the time I got around to ordering one, so I bought one from http://www.voipdepot.ca (cheaper shipping, and overnight at that!) It arrived, and here's what I did:

Install Trixbox
This is trival. I downloaded the version 2.2.4 ISO from http://www.trixbox.org, burned a CD and inserted it into the drive on the PC I am using as a PBX. I rebooted, answered a few (obvious) questions, and let it do its thing. Two additional automatic reboots later, Trixbox was installed.
By default, the Trixbox install uses DHCP to get an IP address, and that's no good, so I logged in as root and set the IP address to a static one, so I'd know how to get there. Do this by typing "netconfig" at the prompt, as root, and give it an IP address. Now, reboot one final time.

Configure Trixbox
All configuration is done from a web browser. Assuming you chose 192.168.0.76 as the IP address for your Trixbox machine in the previous step, just fire up your favourite web browser and go there (http://192.168.0.76). We need to get to admin mode, so click on the "[ switch ]" link in the upper right hand corner. You will be prompted for a password. The default username/password combination is "maint/password". We'll change that later.

Now, Choose "FreePBX" from the "Asterisk" menu, and we are ready to start. A new browser window (or tab, depending on your browser) will open. Click on "Tools" in the top menu, and then "Modules" from the menu on the left. Click on "Check for updates online." Click on "Download all". Install all modules.

Now, we need to set up some trunks. In my situation, I have one hard line coming in (a physical telco line) and I'm using Vonage's softphone for an addtional, pure VOIP line. We'll do the hard line first. It's connected using the SPA 3102.

SPA 3102
This is fairly easy to set up. Plug it in, and connect to it using a crossover cable and a PC/Mac/whatever. Go to its built in web browser, and give it a static IP address. I chose 192.168.0.234. The web based admin is typical Linksys -- easy to use. Assuming the IP address you chose is the same as mine, go here: http://192.168.0.234/admin/

Note that there are no passwords set on the SPA 3102 by default. You'll probably want to change that.

I made the following changes to the SPA 3102's default configuration:

1) Remove all "Vertical Service Activation Codes" under Voice/Regional. They conflict with the codes we will use in Asterisk.
2) Under Line 1, Proxy/Registration, I set the Proxy to 192.168.0.76 (the IP of the trixbox machine)
3) On the same screen, I set DTMF Tx Method to Inband+Info
4) On the same screen, I set up the info for the extension we're going to set up in Asterisk shortly -- Display Name = your name, password to whatever you want for a password, User ID = the extension number you are going to assign to the phone hooked up to the SPA 3102.

All done.

Setting up Trunks
Now, let's set up a trunk for this in Asterisk. Back on the FreePBX window in your browser, click on "Setup" on the top menu, then "Trunks" on the left menu. There is a ZAP trunk there, but we'll ignore it. Add a SIP trunk.

Fill in the values as follows, modifying for your particular information as required:

Outbound caller id: "19995551212"
This is your caller id information.

Maximum channels: 1
Trunk Name: SPA3102
Peer Details:

allow=ulaw
canreinvite=no
context=from-pstn
disallow=all
host=192.168.0.234
insecure=very
nat=yes
port=5060
qualify=yes
type=peer

User Context: SPA3102_In

allow=ulaw
canreinvite=no
context=from-pstn
disallow=all
host=192.168.0.76
insecure=very
nat=yes
port=5060
type=user

Now save the info. Okay, we have a trunk. Let's add a method of dialing out to the outside world.

Adding Outbound Routes
Click on "Setup" in the top menu, then Outbound Routes in the left. You probably have a route called "9_Outside", so let's use that. If not, add one and name it 9_Outside.

All we have to do here is specify a dial patter. I want to use "dial 9 for an outside line", so I have this in the dial pattern box:

9|.

That was easy. Now pick SIP/SPA3102 as your trunk, and save your changes.

Next, we need to have a method of receiving calls, so let's add an extension.

Adding an Extension
This is trivial. Click "Setup" in the top menu, then "Extensions" in the left menu. Add an extension. Add a SIP extension. All you really need is the extension number, but voice mail is nice, so scroll down and add that info. Be sure to specify a password for voice mail, and for the extension! If you added extension info to the SPA3102 when you set that up, you might as well enter the same information here....

Save, and you are good do go. Now let's add an inbound route, so we can receive calls.

Adding Inbound Routes
This is fairly easy as well. Just click on "Setup" in the top menu, then "Inbound Routes" in the left menu. Add a route. We are just going to have one for now, and it will handle all calls. Just add a route with the DID info (and everything else) set to defaults (empty) and then under "Set Destination" (at the bottom of the screen) choose "Core" and select the extension you set up a few moments ago.

Change the Passwords!
You really should change the passwords for Trixbox. You will notice a couple of rather profound warnings in the web based admin tool, with links to how to go about changing them. I strongly recommend you do so.

Next time, I'll give details on how to hook Vonage's softphone up , as well as the Linksys SPA922 IP Phone. We'll configure it for use within the network, as well as an external (remote) extension.

Excellent IPTables firewall script

2007-09-19T13:14:00.000-03:00

Last time I talked a bit about using pf as a firewall, on the various BSDs. Naturally, there are far more installations of Linux out there than there are of FreeBSD, OpenBSD, etc. The current firewall of choice on the linux platform is iptables. One of the best open source firewall configurations I've found using iptables is Arno's IPtables Firewall Script.

There are a few things that you want to keep in mind when you pick a firewall technology:

1) The firewall should be stateful - e.g. the firewall is programmed to distinguish legitimate packets for different types of connections. Only packets matching a known connection state will be allowed by the firewall; others will be rejected.
2) The firewall should be easy to configure
3) The firewall should allow you to easily determine what's going on when you look at the log files.

Arno's script does all of these things, and more. Give it a look.

Using pf as a Firewall

2007-09-14T09:36:00.001-03:00

I've long been a fan of FreeBSD (although I also use a Mac, Linux, and Windows machine -- right tool for the job, and all that), and one of the things I like best about the various BSDs is the ease with which you can set up a stateful packet-filtering firewall. To put it simply, pf rocks.

Setting it up for the first time, though, can be a bit of a chore. If you are interested in giving pf a look, here's how you do it on FreeBSD.

Recompile your kernel
For the sake of argument, let's assume that we are going to be setting up a machine called "zeus" as a gateway server with a few simple services running on it. We first need to compile the pf stuff into the kernel, and then install our new kernel. First, get to the right directory:

[tcs@zeus] ~> su -
Password:
1:28PM up 60 days, 3:54, 1 user, load averages: 0.03, 0.01, 0.00
[root@zeus] ~# cd /usr/src/sys/i386/conf/

Now, copy the file GENERIC to some new file (I'm calling my zeus):

[root@zeus] ~# cp GENERIC ZEUS

Edit the file ZEUS and add the following lines just below "options ADAPTIVE_GIANT":

#PF Support
device pf #PF OpenBSD packet-filter firewall
device pflog #logging support interface for PF
device pfsync #synchronization interface for PF

#ALTQ Support
options ALTQ
options ALTQ_CBQ # Class Bases Queueing
options ALTQ_RED # Random Early Drop
options ALTQ_RIO # RED In/Out
options ALTQ_HFSC # Hierarchical Packet Scheduler
options ALTQ_CDNR # Traffic conditioner
options ALTQ_PRIQ # Priority Queueing

Now, we need to compile and install the kernel. Go to the /usr/src directory and execute this command:

make buildkernel KERNCONF=ZEUS

Wait (quite a while). When it's done, type this:

make installkernel KERNCONF=ZEUS

Wait a bit longer. Reboot. If it comes up, congrats -- you have a new kernel.

Enable PF in rc.conf
We need to tell the OS that we want to use pf. Enter the following in /etc/rc.conf

pf_enable="YES"
pf_rules="/etc/pf.conf" # rules definition file for pf
pf_flags="" # additional flags for pfctl startup
pflog_enable="YES" # start pflogd(8)
pflog_logfile="/var/log/pflog" # where pflogd should store the logfile
pflog_flags="" # additional flags for pflogd startup

Set up the firewall: pf.conf
The default rules for pf.conf are very, very detailed. We are going to ignore them, and make our own. First, back up the /etc/pf.conf file that is (probably) there by default:

cd /etc
mv pf.conf pf.conf.dist

Now, edit a new file called pf.conf and enter the file below (each service is mentioned in the comments preceding it):

# define our interfaces. Find yours by typing ifconfig as root
lo="lo0"
ext_if="fxp1" #your external nic
ext_gw="19x.xx.xx.254" #change this to the ip of your gateway router
int_if="fxp0" #your internal nic
oip1="19x.xxx.xxx.222" #change this to your external ip address

#clean everything up (reset to defaults)
scrub in

# nat for internal clients
nat on $int_if from 192.168.0.0/24 to any -> ($int_if)

# Pass/block rules

block in

pass quick on { $lo $int_if } all

# we shouldn't have to do this, but seem to have to on freebsd
pass out on $lo all

# allow ssh to local machine
pass in on $ext_if proto tcp to ($ext_if) port ssh keep state

Save, and you are ready to give things a try!

Helpful hints:

To enable the firewall rules:

pfctl -f /etc/pf.conf

To enable pf:

pfctl -e

To disable pf:

pfctl -d

Secure your ssh with PKI

2007-09-07T13:59:00.000-03:00

It shocks me how many otherwise intelligent people leave port 22 wide open on their machines. In case you didn't know, this is the default port for ssh -- an widely used method of making connections to a machine from remote locations.

ssh is a wonderful system. The default install on virtually every unix like system out there (including Linux, the various BSDs, and Mac OS X) is inherently insecure, and subject to brute force attacks. We see these on our servers virtually every day. A brute force attack is shockingly simple to implement -- the attacker simply runs a script that tries many, many username/password combinations until they get in. Once they have an account, it's only a hop, skip and jump to root access.

Then bad things happen.

There are a number of ways to make it tougher for attackers, of course. First, configure your firewall to only allow incoming ssh requests from known, safe IP addresses. Additionally, you should implement PKI security on your ssh system. This is, fortunately, very simple to do.

The process is simple:

Generate your public/private key pair
Install the keys on the machines you are going to use to access the server
Modify your ssh server's config file to require known keys
Restart your server

We are going to generate RSA keys for our client. The public key will live on the remote server, and both keys will live on the client machine. For simplicity, we will generate our keys on the server, and then transfer them to our client machine. Log onto the server as the account you want to generate keys for, and then execute these commands:

server$ cd ~

server$ mkdir .ssh

server$ chmod 700 .ssh

server$ ssh-keygen -q -f ~/.ssh/id_rsa -t rsa

Enter passphrase (empty for no passphrase):

Enter same passphrpase again:

Entering a passphrase is optional.... but do it anyway.

Now lock down the file permissions...

chmod go-w ~/.ssh

Now copy the contents of .ssh directory to your client machine. Use a USB key or some other secure method, just to be safe.

Now we need to modify the /etc/ssh/sshd_config file for our ssh server. Mine looks like this:

Protocol 2
ListenAddress 192.168.5.100
HostKey /etc/ssh/ssh_host_rsa_key
SyslogFacility AUTHPRIV
AuthorizedKeysFile .ssh/id_rsa.pub
HostbasedAuthentication no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
Subsystem sftp /usr/libexec/openssh/sftp-server
AllowUsers tcs

This is a bare minimum. Note the items in red:

your public key must exist in /home/yourhomedirectory/.ssh/id_rsa.pub
ChallengeResponseAuthentication disables simple username/passwords to log on
AllowUsers is another safety check -- only users who exist here will be able to log in regardless as to what keys they have.

Now, restart your sshd server, and give it a try.

Anti-spam for qmail: spamdyke

2007-09-05T10:18:00.000-03:00

I have long been a fan of qmail. Yes, I know that it is long in the tooth, and there are a great number of fans of postfix and so forth out there, but say what you will about qmail -- it's solid as a rock, and incredibly fast. I am a big fan of it.

A few years ago I became a fan of the "cookbook" found on www.qmailrocks.org, but it is, sadly, a bit out of date. Nevertheless, careful perusal of various mailing lists and so forth has allowed me to keep up to date with my qmail installs and things are running along smoothly.

Recently, I found another weapon to use in the ongoing battle with spam: spamdyke (http://www.spamdyke.org). This is a great tool for a number of reasons:

it works
it does not require patching qmail
it's free
it brings a lot of functionality to the table that is just not in the standard qmail install (patched, qmailrocks version, etc.)

From the site:

spamdyke is a filter for monitoring and intercepting SMTP connections between a remote host and a qmail server. When a connection is established from a spam source (as determined by the active filters), spamdyke will reject the email -- qmail never sees it.
Beyond filtering, spamdyke offers a number of other features:
spamdyke supports SMTP AUTH and will even provide SMTP AUTH to an unpatched qmail server.
spamdyke supports TLS and will even provide TLS to an unpatched qmail server.
spamdyke provides much better, much more complete logging than qmail, using syslogd.
spamdyke can log all SMTP traffic to aid troubleshooting.
Best of all, using spamdyke does not require patching or recompiling qmail!

Installation is trivial, and it works out of the box, as it were.

Some other qmail related links that might be of help to you if you are looking for a solid, easy to maintain system:

FreeBSD Rocks! (http://www.freebsdrocks.net) - a step by step to installing qmail on FreeBSD. This is an excellent successor to qmailrocks.
Setting up mailhubs (http://qmail.jms1.net/mailhub.shtml) - how to set up multiple incoming servers all delivering mail to a centralized mailbox machine. Excellent way to share the load on busy sites.

There are many other resources out there, and most of them are linked on the main qmail site (http://www.qmail.org).

Another alternative to Parallels: Q

2007-09-04T10:06:00.000-03:00

A few days ago I was extolling the virtues of VirtualBox, an alternative virtualization package for Mac OS X that allows me to run FreeBSD, Windows, Linux & so forth on my Mac, without the need to reboot. Well, I just stumbled across another one with the rather memorable name of "Q". You can find it here: http://www.kju-app.org/kju/

I have not tried this package yet, but it looks promising. From their website:

Run Windows, Linux and a lot more Systems on your Mac. Q is a feature packed cocoa port of QEMU: Switch fast between guest PCs. Save and restart guest PCs at any stage. Easily exchange Files between Host and Guest. Q makes use of OS X most advanced technologies like openGL, quartz and coreaudio to accelerate your experience with your guest PC. Please remember: At the present state, QEMU is still considered ALPHA software.

Note the reference to the package being alpha software. I'm not quite ready to install it on the machine that I make my living with, but I'll keep an eye on it.

Use your Blackberry as a bluetooth modem on your Mac

2007-09-04T09:30:00.000-03:00

As I mentioned a few days ago, I recently purchased a MacBook. I have been extremely happy with this machine in most respects. The only thing I miss is the ability to use it my Blackberry as a Bluetooth modem. Since I live in Canada, where the data charges are absolutely unreasonable (can you say $10.00/meg after the first meg of traffic??) this has not been a huge problem, but there is a certain sense of security knowing that if I absolutely have to, I can connect to the Internet and get to my servers wherever there happens to be cellular coverage.

Fortunately, I have successfully figured out how to do this. I found my information here and here, although neither post was 100% accurate for my setup. Thus, I decided to share my findings here.

My setup:

MacBook (2GHz Core 2 Duo)
Mac OS X 10.4.10
BlackBerry Pearl (8100)
Rogers cellular network

The first step is to download the Blackberry 8100 modem script. Save this to your desktop. If your Mac helpfully appends a .txt extension to the file, rename it so the .txt is missing. Move this file to your Library/Modem Scripts folder. Next, pair the Blackberry with your Mac. This is fairly simple.

First, make sure your Mac is "Discoverable" in the Bluetooth system preferences panel. Then, open the "Options" feature on your Blackberry (in the default interface, it looks like a wrench). Scroll down to Bluetooth, and click on it. Click the menu button (to the left of the scroll ball) and click "Add Device." Your Mac will show up. Choose it. In a few seconds, your Mac will generate a passkey and put it on your screen. Enter that into your Blackberry. The next screen on your Mac will give you two choices -- "Use with Address Book" and "Access the Internet with your phone's data connection". Make sure both are checked, and that you choose "Use a direct, higher speed connection..."

Next, your Mac will ask you for details about your setup. You'll get this screen:

Your Username is "wapuser1", your password is "wap" and your GPRS CID String is "internet.com" (no quotes on anything). Note that these settings are for Rogers Canada. Your mileage may vary.

Make sure you leave "Show modem status in menu bar" checked. Click continue, and you're done.

To connect to the Internet, just click on the phone icon in your menu bar and choose "Connect." To disconnect, go to the same menu and click disconnect.

NOTE: data charges in Canada are very, very high. Make sure you don't overdo it and get a massive phone bill at the end of the month.

DIY Network Attached Storage

2007-09-01T11:01:00.000-03:00

After a (rather busy) summer, I have finally elected to return to my "do it yourself network attached storage" project. I've done some reasearch, and picked my operating system -- FreeNAS (http://www.freenas.org). Their site describes it thusly: "FreeNAS is a free NAS (Network-Attached Storage) server, supporting: CIFS (samba), FTP, NFS, AFP, RSYNC, iSCSI protocols, S.M.A.R.T., local user authentication, Software RAID (0,1,5) with a Full WEB configuration interface."

There are a number of things I really like about this implementation. First, it's tiny -- and I mean really, really small. A full implementation takes about 30 megs for the operating system, leaving the rest of your disk space available for storage. Secondly, it's based on FreeBSD, so you know it's going to be rock solid, and require very little maintenance. Finally, in a heterogeneous network, this is ideal -- it talks to everybody. We have Macs, linux work stations, and windows all trying to play nicely together. This solution is perfect for our needs.

Give it a look. It's stable as a rock, and works like a charm.

Windows on a Mac - Alternatives to Parallels

2007-08-28T14:41:00.000-03:00

I recently purchased a MacBook (Core 2 Duo) and bumped the RAM up to 4 gigs (yes, you can do that if you elect to purchase your memory from somewhere other than the Apple store). With all this extra memory and a number of unused licenses for Windows XP, I thought I'd download a trial copy of Parallels and give it a go. Parallels has this nifty little feature called the "transporter" that claims to be able to migrate an entire Windows install from some other machine on your local network and automagically install it on your Mac.

Sounds good, I think. I'll give it a shot.

So, I download and install the software, and run the installer. First, the transporter simply failed, several times over, so I gave up on that, and decided to do a simple clean install. This worked better, for awhile, but hung at "33 minutes left to install" and stayed there. Overnight.

Now, I'm sure this is an odd case, as lots and lots of people are successfully using the software, but I have a fairly low tolerance for software that does not work as advertised the first time (or the third -- I gave it three tries). So, I started looking to see what else was available.

The first thing that came up, of course, was Apple's Bootcamp. It looked promising, and I gave it a try. It works exceptionally well. The disadvantage, of course, is that it's a dual boot solution. You are either on Windows, or on the Mac, and never the twain shall meet. Not exactly what I was looking for. I'll give it this, though; it's fast. Since Bootcamp gives all the hardware directly to Windows, this isn't surprising, but it's arguably the best experience I've ever had with Windows on a laptop. Plus, Apple thoughtfully gives you a driver disk that enables things like the iSight video, the Bluetooth tools, the Airport wireless, and so on. Extremely well done. I just don't want to boot into Windows to do whatever trivial task I have to do that requires it. I want to have Windows run at the same time as Mac OSX.

Then I stumbled across VirtualBox. The site describes it thusly: " innotek VirtualBox is a family of powerful x86 virtualization products for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers, it is also the only professional solution that is freely available as Open Source Software under the terms of the GNU General Public License (GPL). See "About VirtualBox" for an introduction; see "innotek" for more about our company."

It's open source, it's free, and it exists for Mac OSX. This is exactly what I was looking for. I'm surprised I had not heard of this product before, as it exists for a lot of different platforms. I downloaded it, installed Windows, and was off to the races.

There are some differences between Parallels and VirtualBox. First, the desktop integration with Parallels is much smoother -- Windows does not live in its own window, as it were. At least that's what it says on their website; I never actually got that far. In VirtualBox, the entire Windows desktop exists by itself. I can copy and paste between Mac and Windows apps, though, so that's not such a big deal. The other thing to note is that it does not support the various resolutions of my monitor (neither the LCD panel that's part of the MacBook, nor the external Compaq 19" widescreen I have hooked up). I get 800x600, or 1024x768, and that's it.

Other than that, it works great. I highly recommend it.

Photos of Wifi Antenna

2007-08-05T07:01:00.000-03:00

Someone was asking for photos of the Wifi antenna I built late last year. Apparently the instructions on how the "tupperware" part was used were a bit unclear. I hope a photograph is more helpful.

Build your own NAS device

2007-06-02T15:11:00.000-03:00

I believe it is a universal truth that data will always expand to fill all available media -- even if you do nothing with that data. At least, that always seems the case with us.

We have been considering picking up a few Network Attached Storage (NAS) devices for awhile now, so as to increase storage capacity without adding significantly to the space and power consumption in our server facility.

Naturally, this seems to me to be an excellent opportunity to repurpose some old hardware and build my own NAS device.

Before you go too far down this road, though, consider the fact that there are quite a few not-too-expensive NAS devices out there that will work quite well for small office/home office environments. A quick visit to tigerdirect.ca, for instance, shows that you can find a decent sized NAS for well under $500.00 without too much effort. However, serious NAS devices with RAID configurations, redundancy, and 1 TB+ disk space are still very pricey -- so much so that it is probably cheaper to build your own.

I'm going to start the research now, and keep you posted. Here are my goals:

1) Must support Windows/Mac clients
2) Must be fault tolerant (i.e. RAID)
3) Small form factor
4) 1TB+ storage capacity
5) minimum power consumption/heat generation

I'll keep you posted.

Update: This looks like a nice case for the price....

Installing Mono on CentOS 5

2007-05-28T11:59:00.000-03:00

There are a variety of ways to install Mono. I elected to use CentOS version 5 as the base operating system, and since this is basically RedHat Enterprise Server with some simple re-branding, it seemed that the best way to do this was via the Yum package manager. Well, this sounds great in theory, but it broke. It turns out that binaries created for CentOS 4 are not exactly compatible with CentOS 5.

Who knew?

So, it's back to an installation from source. Fortunately, this is not terribly difficult. Here is the basic system/software I was installing on:

CentOS 5
Dual Core Pentium IV processor (3 GHz)
Apache 2.0.59
Mono 1.2.4

Apache is installed from source -- I can't help it. I like to know exactly what's installed, and how it's configured; I still don't trust RPMs.

I elected to install Mono in /opt. The directory didn't exist, so I first created it. I logged in, su-d to root, and created the directory:

[root@luther]# cd /
[root@luther]# mkdir opt

Then I changed to the newly created directory, and downloaded the necessary files. In order to serve .aspx files, we need the mono base, the XSP server, and mod_mono. I got all those files using the trust wget application:

[root@luther]# cd opt
[root@luther]# wget http://go-mono.com/sources/mono/mono-1.2.4.tar.bz2
[root@luther]# wget http://go-mono.com/sources/xsp/xsp-1.2.4.tar.bz2
[root@luther]# wget http://go-mono.com/sources/mod_mono/mod_mono-1.2.4.tar.bz2

Now, upack everything:

[root@luther]# tar jxvmfp *.bz2

Change to the newly created mono-1.2.4 directory, and configure mono. Notice the parameter I passed the configure program; it tells it to install mono in /opt/mono. I then make, and make install the application.

[root@luther]# cd mono-1.2.4
[root@luther]# ./configure --prefix=/opt/mono
[root@luther]# make ; make install

Wait a bit, and voila -- you have the mono base installed. Now let's do the same thing for Xsp. Xsp is the web server for mono -- it handles the compilation and delivery of .aspx files. This is pretty simple as well:

[root@luther]# cd ../xsp-1.2.4
[root@luther]# ./configure --prefix=/opt/mono
[root@luther]# make ; make install

If "configure" or "make" complains about not finding something, try executing this:

[root@luther]# export PATH=/opt/mono/bin:$PATH

Then run the above commands again.

Now, on to mod_mono:

[root@luther]# cd ../mod_mono-1.2.4
[root@luther]# ./configure --prefix=/opt/mono \
--with-mono-prefix=/opt/mono \
--with-apr-config=/usr/local/apache2/bin/apr-config
[root@luther]# make ; make install

When this is done, if you go to /usr/local/apache2/modules (or wherever you told it apache lives) and look at the files there, you should see these: mod_mono.so (a symlink) and mod_mono.so.0.0.0. These are the modules (well, there's only really one -- mod_mono.so is a pointer to mod_mono.so.0.0.0) that apache needs to invoke xsp and deliver .aspx files.

Now we need to configure apache.

Open the apache configuration file with your fvourite editor (we'll use vi):

[root@luther]# vi /usr/local/apache2/conf/httpd.conf

Go to the bottom of that file, and append this text:

<IfModule !mod_mono.c>
LoadModule mono_module /usr/local/apache2/modules/mod_mono.so
AddType application/x-asp-net .aspx
AddType application/x-asp-net .asmx
AddType application/x-asp-net .ashx
AddType application/x-asp-net .asax
AddType application/x-asp-net .ascx
AddType application/x-asp-net .soap
AddType application/x-asp-net .rem
AddType application/x-asp-net .axd
AddType application/x-asp-net .cs
AddType application/x-asp-net .config
AddType application/x-asp-net .Config
AddType application/x-asp-net .dll
AddType application/x-asp-net .asp
DirectoryIndex index.aspx
DirectoryIndex Default.aspx
DirectoryIndex default.aspx
</IfModule>

Now, we'll configure a virtual host to serve up the test suite that ships with mono. In the virtual host section of your file, put in something like this:

<VirtualHost 198.xxx.xxx.xxx:80>
DocumentRoot /home/httpd/aspx/html
ServerName aspx.yoursite.com
Alias /demo /opt/mono/lib/xsp/test
MonoApplications "/demo:/opt/mono/lib/xsp/test"
MonoServerPath /opt/mono/lib/mono/1.0/mod-mono-server.exe
<Directory /opt/mono/lib/xps/test>
SetHandler mono
</Directory>
</VirtualHost>

Note that you should specify your actual DocumentRoot and IP address to whatever you are using. This tells Apache that everything served under http://aspx.yoursite.com/demo is actually found in /opt/mono/lib/xsp/test, and handled by mono.

Restart apache, and go to http://aspx.yoursite.com/demo/index.aspx

You should see the full mono test suite.

Cool, eh?

Note that with this configuration, I can also put aspx files right in the document root for my virtual host, and they will be handled by mono as well. For example, I put this in the root level of the web server and called it test.aspx:

<html>
<body>
<% Response.Write("Hello World!"); %>
</body>
</html>

And it compiled and worked just fine.

Support .NET on your server without Windows

2007-05-07T09:33:00.000-03:00

I've been watching the Mono project for quite some time. My company hosts most of the web applications we build for our clients, and although we don't do a lot of work in .NET (or the classic .asp version), we routinely come across someone who wants to host his or her site with us, but has everything built in ASP or ASP.NET pages.

What a pain.

We actually ran a few Windows based servers for awhile, but spent so much time patching and maintaining them that it turned out to be somewhat less than cost effective. Please note that I am not slamming Microsoft -- this is purely a matter of playing to our strengths, and we really, really like Linux, FreeBSD, and their various variants.

Along comes the Mono Project. This open source system promises a lot:

Mono provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix. Sponsored by Novell (http://www.novell.com), the Mono open source project has an active and enthusiastic contributing community and is positioned to become the leading choice for development of Linux applications.

Well, that looks most encouraging. I am spending a few nights in the server room this week as we upgrade our fibre connection and add some additional redundancy, so think I'll take one of the servers we are replacing and "repurpose" it to try out this software.

I'll keep you posted.

Open Source Routers - XORP

2007-03-10T06:47:00.000-04:00

Last time I did some research into various open source routers. I've explored three in some detail, but should probably preface my remarks by stating that I am not a network engineer. Like the guy who figures that, given enough time and adequate tools, he can probably do the maintenance on his car himself, I know enough to get by, provided there is adequate documentation available (and by adequate documentation, I include Google, of course).

Nevertheless, I figure there's no harm in trying this stuff out on elderly hardware, and seeing how things turn out.

The three I looked at in detail were XORP, Vyatta, and Freesco. Today I want to look at XORP.

XORP
Of the three products I looked at in some detail, XORP (the eXtensible Opensource Router Project) looks and feels the most like a traditional FOSS product. It also has a great license -- the BSD style, which is extremely flexible. At the time of this writing, it's up to version 1.4 RC (that's release candidate for you non-techie types out there). The first page of the site says that...

Initial funding to develop XORP is provided by Intel and the National Science Foundation. Further funding has been provided by Microsoft Corporation and Vyatta. We are extremely grateful for their support.

Well, isn't that civic minded of the folks at Vyatta? This led me to suspect that there is probably significant crossover in some of the code between Vyatta and Xorp. I have not verified this.

The folks at XORP conveniently offer a LiveCD download, so I was able to get this thing up and running in no time.

Functionality
The functionality currently in place with XORP is listed (in great detail) on their website, here. There is also an extremely helpful (and well written) user manual available. As you can see if you go through the list, it offers a reasonably rich feature set. Unlike some of its commercial cousins, though, don't expect a slick gui or web based interface -- this is about as minimalist as you can get. Be certain to download and print the (160+) page manual. You're going to need it.

Overall, though, this is an extremely powerful and well developed product. I was in particular impressed with the LiveCD product -- you could use this to set up a CDROM based firewall, an emergency router, etc. with minimal effort. And the LiveCD takes great pains to try to figure out how and where it can load/save configuration files (it seems devoted to floppy discs, though; it would be nice if it tried looking for memory sticks first).

This is a great product. I'm almost certainly going to configure some failover hardware using the LiveCD version of XORP.

Evaluating Open Source Routers

2007-02-17T15:14:00.000-04:00

Recently a friend of mine realized that his entire internal network depended on an ancient Cisco 2500 series router (a 2511, I believe). This particular router is older than all of my children -- and I have four!

He is currently evaluating a number of alternative Cisco products, any one of which would do the trick for him. He needs to manage a full class C subnet, and a few additional static IPs. I think he is looking at the 1800 series from Cisco right now, and I'm sure they will be more than fine.

Of course, the cheapest one being offered to him by his ISP is more than $2,400 CDN, and that strikes me as outrageous.

Accordingly, I began looking around to see what alternatives to Cisco their might be in the FOSS world, and I have found a few. I've yet to investigate any of these thoroughly, so if someone has had some experience in this area and would like to share their wisdom, please feel free to comment.

Here's what I've found so far:

I'm sure there are many others, and I will continue to look around for these. I'll keep you posted.

Making Samba your Primary Domain Controller - Part Quarto

2007-02-08T23:15:00.000-04:00

Last time we went over installing Samba on both Linux and FreeBSD. It was pretty simple. Configuring Samba, though, can be a bit tougher. I ran into a number of difficulties, all to do with the (rather cryptic) smb.conf configuration.

Samba is controlled by a single file -- smb.conf. Depending on which operating system you favour, you'll find it in either /etc/smb.conf (most Linux distros), /etc/samba/smb.conf, or /usr/local/etc/smb.conf (FreeBSD).

Configuring smb.conf
Remember that our goal is to use Samba as a primary domain controller. Below is a minimalist smb.conf configuration that will achieve this goal (at least in theory). We have a machine named Aragorn, in a Windows domain named middleearth. We are telling Samba to set up profiles for NT/2000/XP users, and specifying who is a domain admin. We're also telling Samba how to add users to the system. Note that in smb.conf, a comment is either a '#', or a semi-colon (';'). Anything preceded by either of those symbols is ignored. I strongly encourage you to put lots and lots of comments in. It will make life much easier if you have to go in and make a change.

[global]
; name our machine and workgroup
netbios name = aragorn
workgroup = middleearth
encrypt passwords = yes

; tell samba we are a PDC
domain master = yes
local master = yes
preferred master = yes
os level = 65

; we'll probably come back to these settings,
; but they'll do for now
security = user
domain logons = yes

; logon path tells Samba where to put Windows NT/2000/XP
; roaming profiles
logon path = \\%L\profiles\%u\%m
logon script = logon.bat

logon drive = O:
; logon home is used to specify home directory and
; Windows 95/98/Me roaming profile location
;logon home = \\%L\%u\.win_profile\%m

time server = yes

; Use the names of all users in the Windows NT/2000/XP
; Administrators group who log on to the domain
domain admin group = root tcs susand

; this works on Centos Linux -- YMMV
add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u

; share a directory for everyone
[public]
 path = /samba/shares/public
 public = yes
 only guest = yes
 writable = yes
 printable = no

; make one private to tcs
[tcs]
 comment = tcs's stuff
 path = /samba/shares/private/tcs
 valid users = tcs
 public = no
 writable = yes
 printable = no
 create mask = 0765

This might seem a bit cryptic, but it actually makes sense. There are some oddities specific to this file, though, so let's go through this section a bit. First, note that we begin with a [global] tag. As you might expect, this simply states that everything that comes after this tag prior to the next one is "global" in nature. We begin in this section by setting the NetBIOS name of the Samba server. The NetBIOS name is used in UNCs that appear later in smb.conf. The next two lines are a bit odd. We appear to be naming a workgroup -- but although it reads "workgroup", we are actually setting the name of our domain. For a workgroup, using encrypted passwords is optional; when using a domain, they are required, so we'll encrypt our passwords.

The next four lines set up our Samba machine to handle browsing services. This line:

domain master = yes

looks like it is telling Samba to act as a PDC. After all, it has the word "master" and the word "primary" -- sounds important. In fact, all this line does is tell Samba to act as a domain "master browser," which handles browsing services for the domain across multiple subnets (in conjunction with the built in WINS service, which we'll get to in awhile), if necessary. These lines,

local master = yes
preferred master = yes
os level = 65

simply tell Samba to participate in browser elections and allow itself to win. To be safe, the "preferred master" and "os level" lines are there so as to ensure that Samba wins the elections.

This section,

security = user
domain logons = yes

tells Samba to handle the actual domain logons. We set security to "user" so that Samba will require a username and password (always a good thing). This is actually the default setting for Samba, and the only reason we're including it explicitly is to avoid confusion.

"domain logons" is what tells Samba we want this server to handle domain logons (finally!). To support roaming profiles inWindows NT/2000/XP clients, we have to supply Samba with a "logon path":

logon path = \\%L\profiles\%u\%m
logon script = logon.bat

The value following "logon path" refers to a share held on the Samba server where the profiles are kept. The variables %L and %u are replaced with the name of the server and the username of the logged on user, respectively (this is done automatically, by Samba, while it runs. Don't try to manually edit the file to put in your own values -- just use %L and %u).

If you put those entries into your smb.conf (and make the changes appropriate for our system, of course), you will have a functional, if bare bones, PDC running. Next time I'll go through fine tuning this and adding some additional bells and whistles.

Making Samba your Primary Domain Controller - Part Trois

2007-02-03T18:22:00.000-04:00

Last time around we went over the basic choices for hardware/operating system for a Samba installation. In case you're curious, here is the hardware I'm using. Yes, it's elderly, but remember this is a test, and if this particular system ever sees use, it'll be on a home network. For a production environment, I'll use something newer, faster, and with a warranty.

Compaq Proliant 800 (tower)
Dual PIII 800Mhz processors
1 gig RAM
120 gigs storage (SCSI drives, hardware RAID)
additional 300 gigs storage (IDE drive)
FreeBSD 6.2
Samba 3.0.24d

Although hardly cutting edge in terms of hardware, this is more than adequate for a small network with few users. Naturally, if this ever went into production, it would require a failover machine of some sort. There are many solutions, and I'll eventually get around to writing about that particular topic as well.

Installation of Samba on FreeBSD
This is trivial. First, update "ports". To do this, as root, change to the ports directory:
cd /usr/ports
Assuming you have your ports configuration file in your home directory, and it's named "ports-supfile", execute this command:

cvsup -g -L 2 ~/ports-supfile

Wait a bit. If it's been quite some time since you last updated ports, what a while. When it's done, execute these commands:

cd net/samba3
make
make install clean

I strongly encourage you to get a cup of coffee at this point. Or possibly take a nice, long nap. My installation took several hours. This is because it had to download the necessary components (including the ldap client) and compile everything. Of course, I was also rebuilding world at the same time (BSD aficionados will understand that reference) so I suppose it was my own fault.

Installation on Linux
For my CentOS installation of Samba, things were equally uncomplicated. CentOS, like many distros, uses the yum package manager. As root, I simply executed a search for the appropriate packages:

yum search samba

and got this result:

samba.i386 3.0.10-1.4E.9 base
Matched from:
samba
The Samba SMB server.
Samba is the protocol by which a lot of PC...

Yep, that's the one I'm looking for. Like ports, yum takes care of all the dependencies and so forth, so a simple...

yum install samba

...takes care of everything. Samba is now installed.

Purists will insist that Samba should be installed from source, and I suspect they are right. In fact, with very few exceptions, I usually install everything from source so I can fine tune it for my own needs. If you feel that this is the route for you with respect to Samba, then details for the various configurations options for doing so are available at http://www.samba.org.

Next time I'll get to the specifics of configuring smb.conf and adding users.

Making Samba your Primary Domain Controller - Part Deux

2007-02-01T21:03:00.000-04:00

As promised, here is the continuation of my post on making Samba your Primary Domain Controller. Before you actually begin the installation, it's a good idea to try and work out some of the gritty details. How many users will there be? What operating system should you use? For example, if you have several hundred potential users, putting everything on that dusty old Pentium II with a single 10BaseT card in it is probably not such a great idea -- particularly if it's your phone that rings when network problems crop up.

Hardware Recommendations
Hardware requirements, as always, depend on the load to be handled. Since this is our single point of entry into network services, if the PDC goes down, then users can't access the network. This is bad. However, if you are going to have a relatively small number of users, re-purposing older gear might be a viable option for you. If this is the case for you, then you might want to keep a few rules of thumb in mind:

Processor: A pair of Celerons or Durons will hold up better under load than a single Pentium class processor. If you have an old 2 way (or 4 way, or whatever) machine kicking around, give it a hard look. It might be a viable candidate for this.
Memory: Processor speed is only one factor to bear in mind; memory is equally important. Max out your RAM.
Disk: The disk subsystem also plays a major role. Samba acts as a file server. File servers read from and write to the disk, and they do it a lot. Get the fastest drive you can afford. You won't regret it.
Network interface card: do you have an old 10 Base T card in there? Get rid of it, and spend a few bucks on at least a 100BaseT card. You won't regret it at all.

Operating System requirements
Samba runs on just about anything, including your toaster. It's supported on Linux, Unix, BSD, Mac OSX, Netware, AmigaDOS... well, you get the idea. This is largely a matter of taste. I've always been a fan of BSDs, so I chose FreeBSD. For fun, I did a simultaneous installation on CentOS as well.

Installation
First check to see if you have it installed already. Note these innocuous words of wisdom directly from the Samba site (emphasis added):

As always with Linux, there are two ways to install an application: RPM, or compile from source. (OK, there are three: Debian's apt-get. As I don't speak Debian, I'll leave that to the Debian Linux gurus.) RPM is easier, compile from source gives more control. Whichever method you choose, be sure to remove any existing Samba installations first.

Please, make certain you do not have Samba installed. If you do, remove it. If you happen to be running some version of Linux (an RPM based distro such as RedHat, CentOS, etc.) you can check by executing this command as root:

rpm -qa | grep amba

Yes, I left the "S" off, and no, that's not a typo. Sometimes it's installed as Samba-XX.rpm, and sometimes as samba-xx.rpm.

Which Version?
Samba 3.0 adds native connectivity with Microsoft's Active Directory, support for Microsoft's version of Kerberos, SAM (Security Accounts Manager) replication, and lots of other nifty features. It's the way to go. Older versions also support PDC functionality, but hey, that's yesterday's news. The latest version is faster, more stable, and more functional. It's a no brainer.

Next time, I'll take you through the actual installation and smb.conf configuration.

Making Samba your Primary Domain Controller - Part One

2007-01-28T07:35:00.000-04:00

My Samba installation went so well that I've decided to improve our network at the office a bit. We are a small company, but there are enough of us to make a primary domain controller a good idea. I did a bit of browsing around the 'net to see how this is done in Samba, only to discover that all of the necessary instructions seem to be for Samba 2; I'm using Samba 3. "Oh well," I say to myself, "how much different can it be?"

Before we get into the ugly details, a bit of background is in order. First, what is a Primary Domain Controller (PDC)?

Domain Controller
A PDC is actually a pretty good idea. The goal is to store a user's log on information in one place, and allow them to access different services in the domain without needing multiple authentications. Samba makes an excellent PDC. It supports roaming profiles, domain logon from all Windows clients, Windows system policies, name services, master browser, and user-level security for Windows 9x/ME clients (assuming you actually have any of those; do you? Shame on you).

What does this mean? Well, if a Windows user logs on from any machine on your network, their profile goes with them, and they'll have access to only those things that they ought to have access to, and their desktop will look just like they expect it to. This is generally a good thing, and saves lots of pointless calls for help to the sysadmin.

This is of less value to a Mac, BSD, or Linux user, but let's face it -- Windows dominates in the business world, and will for some time to come. If this is the case on your network, then Samba as a PDC might serve very well for you.

A word of caution: just as was the case with Connor McLeod, "in the end, there can only be one." Don't try this if you have a PDC on your network already. Bad things will happen. Your network might blow up. Ethernet cables will melt. Your hair will fall out. Avoid the heartache, and instead try this on a test network, get it working fine, and then use your shiny new Samba PDC as a drop in replacement for whatever you're using now.

So how do you do this? From what I can find on the 'net it looks fairly painless. The steps are as follows:

1) Install Samba.
2) Edit smb.conf, the Samba configuration file.
3) Add machines and users.

I did see some references to Windows XP being a pain, and the Professional edition requiring a registry patch to work with Samba, but those were email messages made some time ago. From the silence on the topic for the past couple of years, I can only conclude one of two things: either Samba is not being used as a PDC by anyone now, or it works fine. I'm hoping for the latter.

I should also note that you can use your Samba PDC in a variety of other ways, although I have not personally tried some of these. For example, I found reference to using Samba as a member of an Active Directory domain (update: this is natively supported in Samba 3.0x), and there are a number of other suggestions in this article. A lot of information is dated, and needs to be tested, but I plan on trying a few different things.

In part II, I'll cover the installation and configuration.

Alternatives to Nagios

2007-01-20T08:25:00.000-04:00

I've never been a fan of putting all my eggs in one basket. Although, by all accounts, Nagios looks like it will be an adequate solution to network monitoring, there are alternatives. Here are the ones I've come across for my "just in case this doesn't work" list:

OpenNMS
One that I've seen quite a few times in my research is called OpenNMS. The website states that

OpenNMS is the world's first enterprise grade network management platform developed under the open source model. It consists of a community supported open-source project as well as a commercial services, training and support organization.

World's first, eh? And what's your criteria for establishing whether something "enterprise grade" or not? Ah, well. Cynicism is unbecoming, and the product looks decent enough, whether or not it's the "world's first."

I do have a few concerns about this product, though, that encouraged me to move it to the "just in case" list. I came across this on a mailing list:

The big thing that makes OpenNMS a non-starter for me was the inability to create dependencies between services. It's a pain to do in Nagios but it's there and that is a critical tool for enterprise level operations.

Yeah, that would be a bit of a show stopper, unless you're doing nothing more sophisticated than running a plain vanilla server install with a few simple services -- and who does that anymore?

Zenoss
This one seems relatively new, but has been getting a fair bit of buzz. Zenoss, according to the website, is as follows:

Zenoss Core is an enterprise-grade network and systems monitoring product that delivers the functionality IT operations teams need to effectively manage the health and performance of their entire infrastructure through a single, integrated package... Zenoss has changed the game by offering a complete, easy-to-use solution as a free..., downloadable, open source software product.

Okay, so far, so good. I perused the website fairly extensively, and have to admit that it looks like a very slick package -- arguably more feature complete and functional than Nagios. There is a fully functional demo available, so I can check things out without having to do a local install, and see if it's more hype than reality... and this appears not to be the case. This is encouraging. Plus, the app appears to be written in Python, so it'll be portable and easy to modify and extend, should the need arise.

I may in fact do a double install -- both Nagios and Zenoss, just to see which one is more appropriate for my needs.

Zenoss seems very impressive.

Server Monitoring: Nagios

2007-01-19T13:09:00.000-04:00

As I mentioned last time, I am looking for an easy, free, stable, and highly functional network monitoring system. Nagios is my first venture into this investigation. Nagios has been around for awhile, and I believe that I evaluated it a few years ago before throwing my hands up in frustration and doing a quick and dirty solution myself. In all fairness, I was incredibly busy at the time, and probably didn't give it a fair shake.

According to the website, it will do exactly what I want:

Nagios is a host and service monitor designed to inform you of network problems before your clients, end-users or managers do. It has been designed to run under the Linux operating system, but works fine under most *NIX variants as well. The monitoring daemon runs intermittent checks on hosts and services you specify using external "plugins" which return status information to Nagios. When problems are encountered, the daemon can send notifications out to administrative contacts in a variety of different ways (email, instant message, SMS, etc.). Current status information, historical logs, and reports can all be accessed via a web browser.

Well, I've never been much of one for believing in the whole truth in advertising thing, so I decided to give it a go on my own, and see how it works.

The network I decided to test it on consists of six machines. In addition, I have two development servers in an external data center that were doing nothing but humming, so I elected to include them in the tests. The machines are a mixture of FreeBSD and a couple of different Linux distros (CentOS and Debian).

Prior to actually installing this package, I did a bit of reading on their website. They have a number of helpful screenshots; here are a few that were of interest to me.

This is the status detail screen (and it would appear that someone is having a bad day with this particular network!). It looks quite helpful, and provides a good "dashboard" view of the various processes on a given machine.

Now this is interesting -- a status map of a network segment. I'm not sure how you define the map (but suspect it is painful), but it is an interesting method of graphically representing the layout of various workstations and servers. Nice touch.

This gives the bird's eye view of all monitored services. Simple, and effective. It seems that you can group services together, which would be very helpful.

After I finished amusing myself with screenshots and the propoganda on their site, I went over to the Wikipedia entry to see what it had to say. It's a short article, and simply lists the services it monitors, has pointers to helpful install guides, and mentions that it came out in 2002, when it used to be called NetSaint. The talk page had this obscure comment:

I would say this is a very handy application when argumented with Cacti. I just set up one and its really cool to see it in action.

I presume "argumented" was supposed to be "augmented", but there you go. But was is this "Cacti"? I'll have to find out.

I'm going to try a test install of this on the weekend. I'll keep you posted.

Automated Server Monitoring

2007-01-14T15:19:00.000-04:00

I have been looking for a decent, non resource intensive server monitoring program. There are a number of them out there (many written in Perl, and getting a bit long in the tooth) but it has been some time since I explored this in any detail. Actually, I think it's been several years since I did this. I'm getting old.

Last time around, I wound up trying and abandoning a number of solutions, and writing a simple Java process that polled a list of servers & ports, and sent an SMS, email, and page when it was unable to connect to something on its watch list.

Talk about rudimentary.

As I recall, there were a few packages that did what I wanted, but they ate CPU cycles like they were going out of style, which was unacceptable. I hope things have improved over time.

Ideally, the monitoring software will track cpu usage, system temperature, disk space, maintain a list of processes to watch and keep up, memory usage, track logins, and so forth. It should also support a "dashboard" of services, statistics, and allow for historical reporting.

I've compiled a short list (which will no doubt grow as I get into the research) of projects to try out, and I'm going to start with Nagios.

I'll keep you posted.

Trixbox 2.0

2007-01-09T22:11:00.000-04:00

While browsing around today I noticed a post on distrowatch.org, indicating that Trixbox 2.0 was released a few days ago. The press release is available here. According to the press release, Trixbox is a CentOS based distribution that includes a completely functional, ready to customize install of Asterisk. It can be installed in less than 15 minutes, supports multiple languages and provides increased reliability and stability, flexible user customization, and support for a wide-range of hardware vendors.

Given that I am planning to do an @home install of Asterisk, this seems like a logical approach. I am still waiting to order the necessary hardware to complete my installation of Asterisk at home, but could use one of the many "softphones" to play with this.

I have managed to cobble together some hardware from spare parts, and will attempt an install of this over the next few days. It is entirely possible that my wife may throw me out for cutting of her phone for hours at a time... but hey, she has a cell phone ;)

Exchange Server Alternatives - Scalix

2007-01-08T13:06:00.001-04:00

I've made some additional progress in the ongoing saga to find an alternative to Microsoft Exchange. As promised, I've done some research into (and actually played with) Scalix. I came at this one with some skepticism, largely because of the great deal of online attention focussed on its competitors, most notably Open-Xchange. I was pleasantly surprised -- this is a very good alternative to OX.

Like most of the packages I've explored so far, Scalix comes in both "free" and "commercial" flavours. Unlike its competitors, it's not as feature-crippled in the for-free version. Of the most interest to me at this point is the fact that it offers complete Outlook connectivity without a fee. Admittedly, the free version only offers this for a limited number of users, but you can upgrade to the commercial version at any time without a complete reinstall required. This is quite attractive.

It took me some time to figure out what all of the various offerings on their web site were -- and to distinguish between the various versions. Things get much simpler if you simply go to the download page and give it a read -- I recommend skipping much of the marketing hype and going directly there.

I have found Outlook support on everything I've looked at so far to be... well... okay. Not great, but acceptable. So when I saw this on the Scalix site:

Scalix offers the Linux industry’s most transparent Outlook support because it is a mature native MAPI implementation. Scalix’s Outlook support has been enhanced further with Scalix 11, with indexed search and improved mobile performance.

I was skeptical, to say the least. I am pleased to report that there is sometimes truth in marketing. Support for Outlook (a client which I personally do not like or use, I might add, but many people I work with require it) is exceptionally good in this package. In addition, the package offers support for Google Desktop and MSN Search, McAfee VirusScan, Symantec Norton Utilities and Captaris RightFax Outlook Extension. Well done.

I plan on doing some extensive testing on this in the coming days, but right now this package wins, hands down.

Exchange Server Alternatives: Results So Far Part Deux

2006-12-30T09:35:00.000-04:00

Yesterday I finished looking at the features of Open-Xchange, and today I have been looking at Zimbra's functionality. Zimbra helpfully gives us a chart comparing the various features of its five different edition. So as to compare apples to apples as far as possible, I am looking at the "Open Source Edition", i.e. the one that has no dollar signs attached to it.

Zimbra seems to spend a great deal of time boasting about it's Ajaxified (yes, I know it's not a word, but it's getting a lot of usage) email & calendar features. Ajax, or Asynchronous Javascript and XML, is an old technology that became incredibly trendy (and very useful) in late 2005 and 2006. It permits a web page to send a request to and receive a response from a remote server without reloading the entire page. This makes a web application appear to function much faster, as less data has to move around the Internet, and you only have to load the part of the page that has changed rather than all the HTML and images for the entire page. It's quite a useful technology, and we implement it on the vast majority of the web applications we build.

The feature set of the free edition of Zimbra is rather more limited than that of Open-Xchange. First, there is no Outlook connectivity; you have to spend money for that. Second, there is no inline display of HTML attachments for email. Third, there is no easy online backup/restore (which just seems insane to me, but there you go). In fact, in order to connect with Outlook and MAPI clients, you need to purchase the full "Network Professional Edition" -- presumably the most expensive, with an annual licensing fee, or a monthly subscription fee. How much does it cost? Well, that's a bit difficult to figure out without talking to a sales rep -- always a bad sign --but you do get a bit of information on the site:

Licenses are sold in blocks of 25 and priced on a sliding scale based on the size of your installation and business segment. For example, 75 Professional Edition mailboxes for a business are priced at $28/user/year; a non-profit for the same will be discounted 50%.

There is a bit more info on the site regarding pricing for the various editions. For example: for the Network Professional Edition for a business, the first 25 pack is set at $35/user/year. Assuming that you have a minimum of 25 users, then the annual cost is $875.00. This is all well and good, but 10 minutes on Froogle shows that I can get Exchange itself with an equivalent number of client access licenses for the same money or less -- and it's not an annual subscription.

So what's the point?

Next, I'm going to give Scalix a look.

Exchange Server Alternative: Results so far

2006-12-29T11:12:00.000-04:00

So I've been working away, trying to identify the best alternative to Microsoft Exchange Server for my organization. I had initially narrowed the field down to two: Zimbra, and Open-Xchange. I've spent a few hours today going through the latter, and a fairly thorough review of the Open-Xchange site suggests that it supports the following:

Messaging (email)
Shared Calendars
Shared Tasks
Shared Contacts
Document sharing
Project portals (not entirely certain what this is, but if it is what I think it is, it looks promising)
User forums, bulliten boards
Knowledge base (sort of like a faq on steroids)
Bookmark repository (our own private del.icio.us?)
Support for Outlook (through a nifty api called the oxtender)
Support for Palm
Support for Samba
Support for SyncML
Advanced user management
Advanced messaging archival/reporting/retrieval

Wow. That exceeds my initial requirements list, and then some. There are, to be fair, a few missing elements -- spam & virus prevention are must haves, and network faxing would be nice. If my cursory read of the architecture is accurate, then I suspect none of these are going to be problematic (in fact, I might be able to stick my my existing smtp transport layer, and have to do nothing in this regard). This is an extremely well thought out package. I plan on reviewing Zimbra's featureset next, and then doing a test install of each package.

Exchange Server Alternative: Requirements

2006-12-28T14:05:00.000-04:00

Quite often when dealing with a client -- particularly a new one -- I spend a great deal of time simply educating them on the need for sufficient planning prior to actually beginning a project. Like most IT firms, we call this the requirements phase, and out of it comes (naturally enough) the requirements document. Smaller clients often put up some resistance to this, and, much like an eager new developer, just want to jump right in and begin work. There are a number of rather serious problems with this approach. I find analogy usually helps in cases like this.

"Would you build a house without a blueprint?"
"Well... No..."

Well, they say that confession is good for the soul, and it is time to come clean. Perhaps it is the unusual feeling of relaxation that comes during the holiday season, or perhaps it is simple laziness, but whatever the case, I have not put sufficient planning into my "let's find a free, or at any rate reasonably inexpensive alternative to Microsoft Exchange Server" project.

I haven't even clearly articulated my objectives to myself, let alone in this particular forum.

Accordingly, I am making an early resolution this year: find out exactly what Exchange does, which of those features are going to be a requirement for my project, and enumerate other features that would be nice to have, but don't exist yet. Once an appropriate platform is chosen and installed, perhaps we can even complete add ons for whichever platform we choose, and release those for the benefit of others.

A quick read through the product features list on Microsoft's site lists these as must haves:

shared calendars
shared address books
easy integration with Microsoft Outlook
anti-spam
anti-virus
messaging records management
webmail access
pop3, pop3s, imap, imaps protocol support
smtp and smtps protocol support
flexible and sophisticated calendaring functionality
integration with popular PDAs for to-dos, calendars, etc.

Yes, those are what a child of the eighties would call "no brainers", but there you go. If you don't write it down, it didn't happen.

As I work through my research, I'll construct a "nice-to-have" list as well.

Exchange Server Alternatives: Update

2006-12-27T09:21:00.001-04:00

I have been conducting some research into which platform will be the most appropriate to put in a system that will provide much the same functionality as Microsoft Exchange, without the cost and security vulnerabilities (which may or not be mythical; there is no question as to the cost - it's very real). This is the first of my DIY projects that I approach with some reluctance, as I personally do not use or like Outlook. However, many of my clients, contractors, etc. do, and I can understand their desire to have this functionality in place. So far, it looks like there are two viable alternatives that will do what I want, without serious limitations: Zimbra, and Open-Xchange. Both work within a browser, and permit use from other applications (most notably Microsoft Outlook).

I have a lot more work to do before I make my final determination, including setting up a test environment, some additional research, and serious testing, but I believe I have narrowed it down to these two.

Exchange Server Alternatives

2006-12-24T08:27:00.000-04:00

We have been under some pressure from both clients and selected staff (curse them) who really, really want to have an Exchange server installed for our office. Although I have resisted for quite awhile, and continue to use a rock sold qmail installation for our email services, there are, I admit, some benefits to having Microsoft Exchange installed -- shared calendars, shared address books, and so forth. However, Microsoft Exchange is a pricey little thing, and I have heard countless horror stories about security.

Naturally, I am looking for a free, stable, secure alternative right now.

So far, I have come up with this list of possible alternatives:

eGroupware - a PHP based groupware solution, intended to be used with a web browser. Not a true replacement for exchange server. http://www.egroupware.org
Group-Office - like eGroupware, this is a PHP based groupware solution, intended to be used with a web browser. Not a true replacement for exchange server. http://www.group-office.com
Open-Xchange - Hmmm... now this is more like it. Integrated SMTP & messaging server, integration with Samba, and "OXTenders", for connections with various non-browser applications. This sounds more like what I am looking for. http://www.open-xchange.com/EN/developer/
Kolab - From their site: "Kolab is a Groupware Solution for Emails, Appointments, Contacts and more. It supports mixed client environments (Outlook/KDE) because of an open storage format. Any email client speaking standard protocols can be served. For the full Kolab experience you need a Kolab Server and Kolab Clients. " A quick overview of the required software suggests that although this will connect with Exchange, it requires a "proprietary, [connector] with gratis 30 day evaluation", called "Toltec connector 2". Hey, I don't want to spend any money if I don't have to... http://www.kolab.com
OGo - OpenGroupware http://www.opengroupware.org
Zimbra http://www.zimbra.com
Open Source Outlook MAPI Connector http://www.openconnector.org

Update: A visitor suggests Scalix (www.scalix.com), which looks very promising. It comes in two flavours - commercial, and "community edition." The latter is free, but limited to 25 users. I will include it in my research, though.

I have not done a great deal of research into any of these, but plan to do so over the holidays. I'll keep you posted.

Asterisk via Live CD

2006-12-23T23:17:00.000-04:00

While waiting for my various components to arrive for the Asterisk install, I decided to see if I could simply play around with soft phone technology, experiment, and so forth. I didn't actually accomplish anything so far, but I did stumble across this Live CD Asterisk product. In case you are unfamiliar with the concept, a Live CD is a rather nifty little thing -- it's a complete, task specific operating system on some bootable media (typically a CD ROM or DVD ROM, but you can use it on a compact flash card, USB key, etc. -- anything that has sufficient storage space and can boot your PC). This is a complete, fully functional Asterisk install on a CD ROM. I actually downloaded it, burned it, and used it to boot my PC. It worked -- at least I think it did. Once again, I'm waiting for some gear to arrive to be able to complete the install and see how it works.

Asterisk Update

2006-12-09T10:34:00.000-04:00

It's been awhile since I have been able to post here -- November and December are typically very busy for me, and I have little time for extracurricular activities. However, I have managed to do some work on the Asterisk install. I've installed the base code on my backup server, which is now running the latest build of CentOS. It went smoothly, largely because I am unable to test anything as of yet -- I have not picked up the hardware necessary to complete the installation. I've decided to go with the Linksys Sipura SPA 3000 for my hardware requirements, for a couple of reasons. First, the box running Asterisk is a bit elderly, and having the FXO/FXS in a stand alone box will reduce the processor requirements; and second, the price is much better this way. I can pick the box up for as little as $115.00 CDN.

I hope to order one this month, and begin testing the application.

A bit off topic

2006-11-28T07:42:00.000-04:00

This really isn't about saving money or cheap technology... but it's such a good effort by someone in Japan that I couldn't resist. This gentleman guts his Mac Cube and gives it a new enclosure, echoing a miniature version of the Aluminum Grilled Power Mac G5 in Cube Form.

I wonder if I could get him to cut the holes for my cheese grater antenna...

Internet Cafe Security

2006-11-25T18:22:00.000-04:00

This PDF discusses a simple (and free) way to foil keyloggers on public terminals such as those found in Internet Cafes. It's common for thieves to install malicious software such as keyloggers in an effort to steal personal information, passwords and so forth from those who use the systems.

Since I hate reading PDFs in web browsers, I copy the relevant bits here:

Rather than hide the password our approach is to embed it in a sequence of random characters. So we seek a way of entering random keys so that they will be seen by the keylogger, but will not affect normal login. The trick lies in the fact that keyloggers employ very low level OS calls. The keylogger sees everything, but it doesn’t understand what it sees. The browser also sees everything, but it doesn’t use everything that it sees: it does not know what to do with keys that are typed anywhere other than the text entry fields, and lets them fall on the floor. The keylogger has no easy way to determine which keys are used by the browser and which fall on the floor. It is very easy to record all of the keys or mouse events (this is true both for Windows and Linux based systems). It is also very easy to determine which application had focus at the time of the event (e.g. this key went to the browser). But it is very hard to determine what the application did with those events. Between successive keys of the password we will enter random keys. In the spirit of chaffing and winnowing, the string that the keylogger receives will contain the password, but embedded in so much random junk that discovering it is infeasible. Observe that we are not exploiting a particular feature of any particular browser: this trick works with all versions of Internet Explorer, Netscape Navigator and Mozilla Firefox. We are exploiting the difficulty from the OS layer of determining how the GUI of an an application handles events. It involves typing random characters between successive characters of the password, and changing focus to and from the password field using the mouse. Instead of the password snoopy2 the keylogger now gets:
hotmail.comspqmlainsdgsosdgfsodgfdpuouuyhdg2
Here a total of 26 random characters have been inserted among the 7 characters of the actual password. In general a total of n extra characters in a length k password will yield so many possible passwords that attack is infeasible (recall the password that can only be tested by attempting login). There are various attacks on this method as we explain below. However, none of the keyloggers reviewed ... appear to have to functionality to defeat this simple trick.

Simple, neat trick.

Computer Part Wreath

2006-11-25T18:14:00.000-04:00

This is too funny -- this site shows a Christmas wreath made from left over/spare/elderly computer parts, wired to a frame. There are no details of construction -- just the picture. But seriously, how hard could it be? And who among us does not have a few dozen spare printed circuit boards laying around?

I think I'll give this a try and impress my wife. She laments the fact that I see Christmas decorations as both pointless and wasteful.

DIY Home Theatre PC - Update

2006-11-24T22:56:00.000-04:00

I've done some looking around, and found that there are quite a few varying opinions on building a Digital Home Theatre System.

On a side note, I should probably come up with something simpler to call it. "Digital Home Theatre System" is too cumbersome, and DHTS sounds wrong somehow. Well, it's a PC, and it's a home theatre... how about Home Theatre PC, or HTPC for short?

This article over at PCStats.com outlines their approach to building a system (which, I might add, they call their HTPC. I confess; I stole the acronym). It's quite good, right up until the point where they elect to install Windows as their operating system. There's nothing wrong with Windox XP (even the media center edition is fine for most people). I just don't want to (a) pay for it; (b) steal it; or (c) keep it patched and up to date. This is a TV system I'm building. I don't particularly want to have to reboot my television.

The information provided, though, is quite helpful.

I'll keep researching.

Replace your phone service with Skype

2006-11-24T09:39:00.000-04:00

The folks over at Linuxjournal.com have a nifty how-to guide for replacing your PSTN phone service (that's Public Switched Telephone Network, for people like me, who are still new to this whole VOIP thing) with a Skype based solution.

This is rather slick...

The author claims that his "solution was to build a Skype server that provides 24/7 phone service with the minimum of hassle and fuss. By dumping your regular phone company and taking back control of your home phone wiring using a Skype server, you will have not only a phone system with nearly the same capabilities as before-indeed, in some ways better-you will also save a bundle of money! In my case, I save a little less than $700 US each year (this year, next year, and the year after that, and so on), or about 82% off of my old phone bill."

Hmmm... 82% is a lot of dough.

Update:
Darn. The SkypeIn service (details on the Skype website) is not yet available in Canada. Well, it is, but my next door neighbours would have to call a number in some other country to get me... and that's not going to happen.

Oh well.

Freevo - the MythTV Alternative?

2006-11-23T13:02:00.000-04:00

So I've been doing some more reading into my Digital home theatre project (it seems I've been doing a lot of reading lately). I came across an alternative to MythTV: Freevo. As the name suggests, this is intended to be a free (as in you put hours of work into something and place no actual monetary value on your time) alternative to TiVo.

It looks interesting. I'm not sure if there is any general consensus as to which is better, but it is probably worth some additional investigation.

I did find a bunch of comments on someone's digg post that argue both sides of the fence, which wasn't very helpful. I wanted to post a screenshot, but the ones on Freevo's site don't seem to work (which isn't very encouraging).

Why MythTV?

2006-11-22T13:40:00.000-04:00

I've been doing some more reading, and it seems that MythTV is a logical choice for the Home Theatre PC I want to put together. Here are some of the features offered by MythTV:

Basic 'live-tv' functionality. Pause/Fast Forward/Rewind "live" TV.
Support for multiple tuner cards and multiple simultaneous recordings.
Distributed architecture allowing multiple recording machines and multiple playback machines on the same network, completely transparent to the user.
Compresses video in software using rtjpeg (from Nuppelvideo) or mpeg4 (from libavcodec). Full support for Hardware MPEG-2 encoder cards (Hauppauge PVR-250 / PVR-350). Preliminary support for DVB cards and the new pcHDTV tuner card.
Support for the (very nice looking) hardware MPEG-2 decoder and TV out present on the Hauppauge PVR-350.
Completely automatic commercial detection/skipping
Grabs program information using xmltv.
A fully themeable menu to tie it all together.

Here's what it looks like (the above info and the below screenshot are taken from the MythTV website):

All in all, this looks like a pretty good system. Of course, my wife will insist that it's aesthetically pleasing as well, and that could be more of a challenge...

DIY Home Theater

2006-11-22T07:53:00.000-04:00

Last night I realized that I am using a VCR that is older than my oldest child, and she hits the double digits next year.

I'm getting old.

Rather than wallow in self pity, though, I decided to focus my energy into something productive. It's time to do away with the elderly analog VCR and try building a Home Theater PC. I've been thinking about this for quite some time, and believe it's time to give it a go.

Although I don't have the specifics worked out, I am certain that MythTV will be a component of the final mix. This is a free, Tivo-like package that does not require a subscription.

Besides, I think that getting my Asterisk system working is going to take awhile. I need to have a success of some sort in the meantime.

Interesting Add On for Asterisk

2006-11-21T14:33:00.000-04:00

While planning for my Asterisk install, it occurred to me that someone has almost certainly already built and released an open source project for web based administration of the server. While I have by no means completed my research into this topic, I did stumble across a very nice package called VoiceOne. This seems to be almost exactly what I will need.

Here is a sample screenshot of the application. It looks very promising.

Asterisk update

2006-11-21T07:54:00.000-04:00

I've been doing some more reading about the hardware requirements and options for setting up an Asterisk PBX, and came across this information:

"If you build an Asterisk system without the need for PCI cards, you have a much greater set of choices for what kind of computer to run Asterisk on. If things are configured correctly, the ATAs are handling all of the load for coding/decoding digitized streams of voice to/from analog. You have a better chance of being able to successfully share a computer for asterisk and some other tasks. There are some great choices in small form factor computers. It's even possible to run Asterisk on a Linksys WRT54GS, but that box is a bit too underpowered for a full featured Asterisk configuration. Linksys also sells ATAs with firmware from Sipura. Now it's been announced that Linksys is buying Sipura. I haven't seen any reports on hacking the version of the WRT54G with the embedded ATA yet, but I'm hoping we might see some pretty cool things soon."

Please note that I fixed some spelling errors in this prior to putting it here. I can't help it; the English prof in me takes precedence over the nerd from time to time. Anyway, it sounds a lot like the external box (i.e. the Linksys - Sipura SPA-3000) might be a better solution given that I'm using older hardware for my home installation of Asterisk. After a bit of browsing, I found an excellent price on one here, in Canada. I'm tempted to try this using my Linksys WRT54GS router, but since that's currently connecting my antenna to the Internet, I might be asking it to do more than it can.

Automatic Backups with rdiff-backup

2006-11-20T15:17:00.000-04:00

I finally got around to finishing my backup scripts. My goal was to have off site backup of machines on my internal network to a remote location, through a secure tunnel established with OpenVPN. I elected to go with rdiff-backup, as it permits nifty features like point-in-time recovery (i.e. restore this file/directory/whatever as it was on a certain date at a certain time). I set up a machine in the same physical location as the servers I wanted to back up as a primary backup server (so as to permit speedy recovery without having to go through the tunnel), and then backed up once a day off site to the remote machine.

It turned out to be pretty easy.

The first step was to allow automatic backups without human intervention. The way that rdiff-backup works is actually pretty cool. You establish a connection to the remote server using some login facility such as telnet, rlogin, or ssh (I went with ssh for obvious reasons -- it's the most secure), and then execute the rdiff-backup program on the remote machine, telling it to send the files across the network to wherever you want them backed up. This means that rdiff-backup has to be installed on both the "server" and the "clients". Installation is a snap.

The next step is to create a "backupuser" account on all machines, and use Public Key Infrastructure (PKI) to permit secure unattended logins.

This is relatively simple. First, create the account on all machines (i.e. adduser command). Next, generate a public/private keypair for the account as follows:

trolius> ssh-keygen2
Generating 2048-bit dsa key pair
1 oOo.oOo.o
Key generated.
2048-bit dsa, user@Local, Wed Mar 22 2002 00:13:43 +0200
Passphrase :
Again :
Private key saved to /home/backupuser/.ssh/id_dsa_2048_a
Public key saved to /home/backupuser/.ssh/id_dsa_2048_a.pub

Note that you might get slightly different feedback depending on your version of OpenSSH. Next, rename the generate private and public keys to whatever your OpenSSH requires them to be (hint: read /etc/ssh/sshd_config for a clue). Copy the keys to the remote machines, and log into each once so that you can say "yes" when prompted as to whether or not you want to accept the keys.

Finally, back everything up! These commands will do it for you:

/usr/local/bin/rdiff-backup \
 backupuser@192.168.0.16::/home/httpd \
 /backup/luther/httpd

Note that the slashes (\) are there to keep the command from going out of the text area on the blog; you can use them or not, as you wish, when you type the actual commands. This command backs up /home/httpd on "luther" to /backup/luther/httpd on the machine which originated the command (i.e. the one that is receiving the backup).

rdiff-backup -r 3D /backup/luther/httpd/somedir/ \
/home/backupuser/tmp/

This will restore the entire "somedir" directory to the local directory /home/backupuser/tmp/ as it was three days ago. The "r" stands for "restore as of". You can use a variety of formats to specify date, time, etc. Other acceptable time strings include 5m4s (5 minutes and 4 seconds) and 2002-03-05 (March 5th, 2002).

I ran the backups once, to ensure that everything is backed up, and then added each command as a crontab in /etc/crontab to run it hourly on the "primary" backup server. I then added similar entries on the crontab of the remote backup server, to run once a day at 4:00 AM.

Couldn't be simpler, and I can sleep better at night knowing my data is stored redundantly.

Planning the Asterisk Install

2006-11-20T13:38:00.000-04:00

After reviewing the basic instructions found here, it would appear that I need to purchase PCI cards with Foreign eXchange Station (FXS) ports, and with Foreign Exchange Office ports. Telephones are connected to the FXS ports, and phone lines are connected to the FXO ports.

Apparently bad things happen if you get this wrong. FXS ports provide power and generate ring signals, while FXO ports receive power and ring signals. I'll have to be careful with that.

I'm also going to need an Analog Telephone Adaptor, or ATA, that acts as a gateway between my digital network (the Asterisk box) and plain old analog phones and phone lines. Fortunately, the most common ATAs offer FXS ports, so there is less hardware to buy (and money to spend).

Apparently there has been considerable success using the TDM400P with a couple of daughter cards for a self contained PC to handle everything. Or, we could go with the Sipura 3000 (a stand alone box that you connect your Asterisk machine to via ethernet). I guess it all comes down to price.

Pricing out the first option, the Digium TDM400P, doesn't look too bad. I found a decent price here, at voipdepot.ca.

My, what a wonderful new crop of acronyms to learn. I connect from the CO to my FXO, then go through my ATA to FXS to connect to a phone and get dial tone. What fun.

Why install Asterisk at home?

2006-11-19T08:43:00.000-04:00

I've had a number of people ask me why I would be interested in installing Asterisk PBX at home. Well, there are a number of reasons. First, I pay for voice mail and a few other features on my home phones, and it costs me a bit of cash every month. The PBX will pay for itself inside of a year. The main reason, though, is functionality. Here are some of the features that are of interest to me:

Sophisticated Voice Mail system - This can provide a mail box per person, that can be deliver notification by e-mail. Web based access to your voice mail is also available.
Interactive Voice Response IVR system - You can present callers with a menu, which can be particularly useful if you have more people in the house than you have incoming phone lines. "Press 1 for Him, Press 2 for Her, Press 3 for Kid No. 1, Press 4 for Kid No. 2"...
Control over which phones ring, and at what times.
Functions as an Intercom - Place in house calls.
Call routing - Route incoming calls by Caller ID.
Multi-line functionality - if you need more than 2 incoming lines, you will quickly discover that phones that handle more than two lines are much more expensive than 1 or 2 line phones, and there isn't very much selection available.
Call Detail Reports - for attempting to gain some control over costs, and/or teenagers, etc.
Check your voice mail over the web.
Email notification of voice mail.

There are many more features, but even this brief overview shows the kind of control you can have.

Plus, it's cool. And although I do hate to admit it, there is a fairly wide "geek" streak in me. It rears its ugly head sometimes.

Progress with Asterisk

2006-11-18T07:44:00.000-04:00

I've made some progress with my Asterisk PBX planning. As I indicated earlier, I had to do a re-install of the operating system on my backup server (From FreeBSD to CentOS) first, and I've managed to get that out of the way. I've also developed a strong appreciation and respect for the "yum" package manager. It's very good, and as easy to use as ports on FreeBSD.

Anyway, I've begun the work necessary to build a simple PBX system at home, using Asterisk. I figure I'll practice at home, and if it works well, eventually migrate my business onto the same system. At this point, it's largely reading and research, as I have to (gasp) actually purchase some hardware in order to make this work.

Apparently, I'm going to need a PSTN interface card.

For those not in the know (like me, up until recently), PSTN stands for Public Switched Telephone Network. Also, POTS is Plain Old Telephone Service. And in case you were wondering, PBX stands for Private Branch eXchange. Wikipedia has some great info on the history of the PBX.

I'm sorry for the digression.

A PSTN interface card is the basic device that permits you to connect analog or digital phone lines (the ones that you use at work or at home to connect regular phones to) to your PBX. Once you've done that you have access to all the nifty features that Asterisk offers, such as call parking, voice mail, and so forth.

There is a helpful site found here that details all of the various cards known to work well with Asterisk. I'm going to have to do some serious price comparison for awhile, and find one known to work well with my system.

This is going to take awhile.

No go on the cheese grater

2006-11-16T20:38:00.000-04:00

After some careful consideration, I've decided to give the slotted wave guide antenna a miss. I only have 10 fingers, and I'm particularly attached to them. I spoke with a friend who does metal work, and asked him if he thought I could do it... and I think he's still laughing.

Oh well...

Asterisk - VOIP for the handyman

2006-11-16T17:50:00.000-04:00

While configuring my backup server, it occurred to me that this would be an ideal time to try working with Asterisk, the free VOIP solution available for Linux. Naturally, this entails re-doing much of what I have already done with Samba, as I chose FreeBSD as my operating system. I'll have to strip it and go with CentOS instead. Sigh.

The Asterisk site claims that Asterisk is a complete PBX in software. It runs on Linux, BSD and MacOSX and provides all of the features you would expect from a PBX and more. Asterisk does voice over IP in many protocols, and can interoperate with almost all standards-based telephony equipment using relatively inexpensive hardware. However, my research has indicated that it runs best on Linux, so Linux it is.

I'll keep you posted. And this time I'll take notes.

Slotted Waveguide Antenna for 802.11x

2006-11-12T18:02:00.000-04:00

This looks interesting... This is a slotted waveguide antenna, which is an alternative to the double-biquad on a satellite dish I put together last month. According to Trevor Marshall's site, this is a rather good design for Wifi network reception. I wonder how hard it would be to make one of these...

Making your own portable internet

2006-11-12T15:20:00.002-04:00

As promised, here are the details for making your own, I'll-only-pay-for-this-once "portable Internet." The goal here is simple: we are going to take a standard wireless router and use the "antennna-side" to connect to an existing wireless network as a client, and then use the "wired ports-side" on that hub to connect our machine(s) to the Internet.

This is really a trivial exercise. There are only two things you'll need:

1) A wireless base station that supports dd-wrt;
2) A copy of dd-wrt.

The first is strictly a matter of preference and budget. I went with the readily available Linksys WRT54G model. You can find them all over the place, but whatever you do, make certain that you look at the serial number prior to buying it. The newest releases are not able to run any version of dd-wrt, as Linksys (in their infinite wisdom) has somewhat crippled them by reducing the amount of flash memory they have. Ensure that you have nothing later than version 7.0 by comparing the serial number on the outside of the box against this chart on Wikipedia.

If you want to spend a bit more, but get a machine with some additional horsepower, then the kind folks at dd-wrt recommend the Buffalo Airstation WHR-HP-G54. It costs a few dollars more, but it's worth it. Not only is it more aesthetically pleasing, but it also has loads of memory, and (so I am told) a better range than the Linksys models. I didn't do this. I wish I had.

Once you have your wireless router, simply download the appropriate version of dd-wrt by going here. Installation is trivial; just follow the instructions here.

Once you have that done, this is a trivial exercise.

1) Run an ethernet cable from one of the router ports on the back of your wireless hub to the ethernet port of your pc/mac/laptop/whatever.

2) Start up a web browser on your computer.

3) Access the following URL http://192.168.1.1

4) Click on the "Status" tab. When prompted, type in the username/password to get into the admin tool (by default, these are set to root/admin. Please change them). Then click on the "Wireless" subtab.

5) Scroll down till you see "Wireless Nodes". Click on "Site Survey".

7) A window opens showing all available networks. Pick one that you can legally connect to, and click "Join". When a button allowing you to continue shows up, click it.

8) Next you are bounced to the "Basic Settings" for wireless config page. Ensure that "Client" is chosen in the drop down menu, and click "Save Settings".

You are done. Wasn't that easy? For future connects, you simply have to repeat steps 3 through 8 to pick the network you want to connect to. It only takes a few seconds. Personally, I find performing a 10 second routine is preferable to giving someone $50/month.... but that's just my opinion.

Rogers Portable Internet

2006-11-11T09:09:00.000-04:00

I live in a fairly rural part of Canada, and this means that we sometimes lag behind other parts of the world for the latest technical advances to become available. We were late getting digital cell phone coverage, Vonage service, Cable modems (although we did have DSL coverage long before the rest of the country for some strange reason).

However, this should not not be any kind of barrier to the truly dedicated. After all, my goal is to get much of this kind of functionality for free, or at least as close to free as I can get. Besides, you will often see larger corporations doing little more than charging you a monthly fee for something you could get for free yourself.

~~Take Rogers in Canada, for instance. They now offer the "Portable Internet". This is a Wifi adaptor that connects to your computer, and then searches for and connects to available Wifi networks~~. As some readers have helpfully pointed out, Rogers portable internet is not a Wifi service at all. Mea culpa, and my apologies to Rogers. However, you can still use this post and its followup to connect to free Wifi networks if you happen to have any nearby. This is a great idea, and Rogers helpfully supplies you with coverage maps showing where the "hot spots" are throughout the country. What they neglect to tell you is that in a lot of cases the "coverage area" is not supplied by Rogers at all. In fact, all they are really doing is renting you a piece of hardware for what seems to me to be a very high price (at the time of this writing, you pay approximately $100 for the "modem" and $50/month for the service). Given the fact that all they really need to do is ship you the "modem", and someone else is providing the actual connectivity, this is a bit outrageous.

In fact, you can give yourself ~~exactly the same service as Rogers~~ excellent access to available free Wifi Networks in your area for a one time fee of about $50.00. It involves purchasing the appropriate wireless router and installing dd-wrt on it.

I'm going to post detailed instructions for doing so here. ~~I like Rogers' network, and in fact subscribe to a number of their services... but this $50/month for the right to use someone else's network strikes me as usurious.~~

Stay tuned...

Antenna Update

2006-11-09T10:27:00.000-04:00

My double biquad antenna got a real test last night. We had seriously heavy rainfall, and I am told that water absorbs radio frequency in the 2.4 GHz range (the range used by WiFi). I am pleased to report that it worked flawlessly throughout the entire storm.

Yes, it was the caffeine

2006-11-08T13:20:00.000-04:00

It turns out that caffeine deprivation is not a good thing. Following copious quantities of Jamaican Blue Mountain bean, I successfully mounted Trolius (my new Samba server) on the network as a master browser. It worked, and I have no idea what I did differently. This is why I usually write things down as I do them.

The next step is to relocate this machine to a remove location, connect to the network at the office using OpenVPN, and start experimenting with rdiff-backup. Hopefully I'll have some time to do that over the weekend.

It's good to be back to coffee. I don't think I'll try giving it up again...

Irritations with Samba

2006-11-07T15:53:00.000-04:00

I've been drinking less coffee lately, and that might go a long way towards explaining why I had such trouble trying to configure Samba last night. This should have been a trivial exercise, but my forehead is sore from banging it against the wall so much.

As a side note, I need to get softer walls.

The installation of Samba on FreeBSD is trivial. Just type:

cd /usr/ports/net/samba
make install clean

Wait a bit, and suddenly you have samba installed. The startup scripts are, as usual, in:

/usr/local/etc/rc.d

and the configuration files are in:

/usr/local/etc/samba.

Nothing unusual there.

The next step is to modify the sample configuration file (smb.conf). I copied it (to save the original) and opened it up. Wow. There are a lot of options in there. I decided to try something simple at first, just to get it working. I had formatted the filesystem to leave a large (750 gig) partition mounted as /archive. That was where I planned to have rdiff-backup store everything. Why not make that mount as a Windows fileserver? That should be easy.

Using the existing smb.conf file as a starting point, I examined some of the sample entries. Here's the one I went with:

;[public]
; path = /usr/somewhere/else/public
; public = yes
; only guest = yes
; writable = yes
; printable = no

This seemed simple enough, so I changed it to this (removing the semicolons, which are comment markers):

[Archive]
path = /archive
public = yes
writable = yes

That looked easy enough. I made the change, entered some simple stuff at the top (server name, etc.) and started the process. Typing ps ax | grep smb showed that the process was running, so I fired up a Windows laptop, typed this in the address bar of a window:

\\trolius.local\Archive

(trolius.local being the name of the box I am working on, obviously). Lo and behold, the server mounted! Great. Well, that was easy. Just to be sure that things were working as expected, I opened the "My Network Places" icon on my desktop, and browsed the local network.

No server.

And it's still not there. And I can't figure out why. I think I'll purchase some coffee and try again. Caffeine solves so many problems...

Step one complete...

2006-11-06T15:45:00.000-04:00

I took the time necessary to do a clean install of FreeBSD 6.1 on my dual processor Compaq last evening. It was, as is usually the case with FreeBSD, a very painless process.

The only thing that was a bit annoying was setting up the SMP part of the kernel. By default, FreeBSD does not use a kernel that supports multiple processors. Fortunately, this is a simple thing to do (although it did take quite a while to compile).

Tonight I hope to start experimenting with Samba, and see how much it's changed since I last gave it any consideration. I'll also install rdiff-backup, as (if things go well) I'll need it fairly soon anyway.

"The rumours of my death...."

2006-11-04T09:40:00.000-04:00

In my previous post I had suggested that Tiny Sofa linux was in hibernation. Apparently this is not true, as anyone with enough initiative to visit their website can see. It was updated to tinysofa classic server 2.0 Update 6 (Ceara) just last month. To be fair, I was talking about the Enterprise version of this distro, which hasn't seen a significant update since February, 2005.

Mea culpa.

Picking an Operating System

2006-11-04T09:03:00.000-04:00

Step one in getting my "this isn't going to cost me anything 'cause we'll just use open source and exising hardware" file server up and running is, of course, picking an appropriate operating system. I've always been somewhat agnostic in this area; I run a number of FreeBSD boxen, a couple of Macs, several Linux machines, and so forth. In the BSD world, I do have a decided preference for FreeBSD As for Linux, I used to use a distro called Tiny Sofa, but it appears to have gone into hibernation. Currently, I've been using CentOS, a repackaged version of Red Hat Enterprise Linux 4, without the subscription fee. (I did visit distrowatch.com to see what was "cool" these days, but decided that it's turned into little more than a popularity contest).

The hardware I want to work with is an elderly Compaq, with dual Pentium III processors, tons of disk space and a gig of RAM. While this might seem museum-quality gear to to uninitiated, please bear in mind that we'll be running this without the Redmond tax, and without the (massive) overhead required by Windows. In fact, we won't run any windowing system at all; everything will be set up via the command line. If we want a GUI of some sort for administration, we'll find an open source web service that fits the bill, and run it from there.

Anyway, back to the process of choosing an operating system. A primary consideration, of course, is maintenance. I don't want to even think about this machine once it is up and running. Thus, updates should be painless. Well, CentOS has a pretty simple to use update manager (typing "yum update" and hitting the "y" a couple of times is pretty easy). But it's very hard to beat the ports system in FreeBSD.

After a bit of research into hardware compatibility, reliability, etc., I could not come up with a compelling reason to go with one operating system over the other. What it finally came down to was this: I found the FreeBSD install CD before I located my CentoOS disks.

FreeBSD it is!

Replacing a Windows Fileserver

2006-11-03T15:16:00.000-04:00

We have been using an elderly Pentium II with an ancient install of Windows NT Server as our primary backup and file server for quite some time now. I was considering simply retiring the box, and replacing it with a newer machine with Windows Server 2003 (some variation thereof), when it occurred to me that reading about the open source alternative, Samba, has been on my to do list for quite some time.

Why make Microsoft any richer, when there is a free alternative out there?

This would also give me a chance to try out rdiff-backup, a rather nifty open source back up solution with point-in-time recovery (i.e. restore this file/directory/whatever to the condition it was last Tuesday at 11:23 AM). That would be very, very helpful in my line of work.

The Goal: use existing hardware and free software to create a fully functional Windows compatible file server and turf the elderly NT server solution. At the same time, design and implement a set-and-forget, point-in-time recovery capable backup strategy that will regularly poll live servers and our internal network and back everything up.

I'm going to start reading now. I'll keep you posted.

Success!

2006-10-23T14:26:00.000-03:00

This past weekend I finally found the time to assemble everything and give the dish/double biquad antenna a try, and it worked surprisingly well.

Here's how it went: first, I downloaded a copy of dd-wrt from http://www.dd-wrt.com, and used it to replace the built in OS on my Linksys WRT54G wireless router. It turned out to be a simple enough process, and took less than 30 minutes. By the way, it's amazing the additional functionality this replacement router OS offers -- even if you are not interested in building your own antenna, you should give this a look. It's a serious improvement.

Next, I removed one of the antennas from the router, and connected the router directly to the double biquad using a pigtail cable. I was preparing to hook the double biquad to a dish when I noticed that the router was already reporting more than a dozen available access points -- even without the dish!

This was phenomenal.

I browsed through the available access points to discover that the free wireless network I wanted to connect to was already showing up as available -- and this from inside my house, at my kitchen table. I Clicked on "Join" from within the dd-wrt admin tool, and lo and behold, I was suddenly connected to the internet. Admittedly, this was only a 1 meg connection, but I figured that would improve when I mounted the antenna to the dish, and put the dish on the roof. I made a note of the MAC address of the machine I had connected to so I could figure out just how far away the access point was.

Next, I mounted the double biquad onto the satellite dish. I decided to try the StarChoice dish first, as it was the largest, and I figured it would collect the strongest signal. Mounting was simple enough. I simply tore apart the LNB and then used a power drill and a wood screw to mount it to the plastic housing. That was simple. After I finished, it occurred to me that I should probably have taken into account the fact that I live in Canada, and we don't have the mildest of winters. So, it was off to the dollar store to see if I could find a microwave safe, watertight plastic container to cover the antenna. This turned out to be simple as well. Armed with a Xacto knife and a tube of silicone sealant, I proceeded to mount the assembly a second time, this time in a waterproof container.

An hour later I was up on the roof, and trying to point the dish where I knew there to be an access point or two.

It took some experimentation, but I managed to get a stable, relatively fast 4 meg connection to the wireless network in town.

Ah, the sweet smell of success.... and money saved.

Making the double biquad

2006-10-04T14:05:00.000-03:00

I had some time last night, so I decided to make the actual double biquad part of the antenna. As I said in a recent posting, I used the ground wire from standard household electrical wiring. I used a permanent marker (the kind used to write on recordable cds) to mark out the location of the various bends. According the what I found online, each side of the "diamonds" should be as close to 30.5mm as possible.

At first, I tried using two pairs of pliers to make the bends as sharp as possible, but that didn't work very well. I then switched to using a vise:

That worked much better. After a bit, I had something like this:

It took some effort, but I had it completed in about a half an hour. Now, I needed something to attach it to. I took the bit of 3/4" copper piping I got for free from a local hardware store and soldered it to my copper reflector plate. I also used a dremel tool to remove a few millimetres from one edge, so that the antenna would not touch it when it came up from the pipe. The result looked like this. Note the excess solder. I don't do this sort of thing often enough.

I then soldered a center post to the n-connector (which protruded through the center of the pipe), and tried to solder it to the finished double biquad. What a serious pain that turned out to be. After some thought, it occurred to me that I probably should have made the center post of the biquad part of the double biquad itself -- i.e., why snip it off when I could have simply bent it 90 degrees straight down. Also, I snipped the two ends that should have been soldered to the pipe a bit short, and soldering them to the copper piping turned out to be rather problematic.

I plan on trying this again. This time, I'll make the center post and the double biquad out of a single piece of copper, and leave the two "tails" that have to be connected to the pipe a bit longer than they need to be. I'll use the dremel to create two small grooves in the top of the pipe, lay the two tail ends in those grooves, and put a drop of solder on each. That should make things simpler.

Biquad Wifi - making progress

2006-10-01T12:51:00.000-03:00

I've come much closer to getting the antenna ready for trial. First, I've acquired a dish. This set me back the staggering sum of $10.00 + shipping from eBay. Just to be safe, I picked up one for nothing from a yard sale, just moments before it closed, as well. The first (pictured below) is a Dish Network model; the second is an elliptical model. I'll try both, and go with the one that has the stronger signal.

Next, I picked up some 15mm tall 3/4" copper piping from a local hardware store. They actually didn't even charge me for these, which I thought was very kind of them.

I picked up a few feet of standard household wiring out of the mess in my "don't throw this stuff away 'cause you might need it someday" box in my basement. Used my trusty pocket knife to open this up and extract the ground wire. That way, I don't have to strip the insulation off of the wire.

Easy Certs

2006-09-29T14:53:00.000-03:00

FYI, I stumbled on a nifty (and free) utility to generate the certificates you need to use with OpenVPN.

You can find it here:

http://openvpn.se/mycert/

OpenVPN client configuration

2006-09-29T14:42:00.000-03:00

Configuring OpenVPN for client use turned out to be rather simple. We installed the OpenVPN GUI found at http://openvpn.se, and then went to the configuration files stored in this location:

c:\program files\openvpn\config

First, we copied the files we generated on the server to this folder. Since I was installing on a laptop, I named my key files "laptop.key" and "laptop.crt". I placed copies of those files in this folder. I also need the "ca.crt" file from the server stored in this location. All three files were copied over using a USB thumb drive, so there is no risk of them getting into the wrong hands.

My configuration file looked like this:

client
remote 205.174.168.29 1194

dev tun
# proto udp
comp-lzo
ca ca.crt
cert laptop.crt
key laptop.key

verb 3

I then double clicked on the OpenVPN icon in the system tray, and lo and behold, I was connected to the local network at work!

After a bit though, it started randomly dropping the connection and then reconnecting. This was annoying, so I did a bit more digging.

By adding these lines to the config, the connection became much more stable:

persist-key
persist-tun

OpenVPN Server configuration

2006-09-28T19:25:00.000-03:00

As promised, here are some more details about how I configured my OpenVPN server. The machine in question is running a recent build of FreeBSD, with ports installed. If you haven't used FreeBSD, you might want to consider it. It's a very easy to use, stable system (although if you've ever tried to run a serious Java application on it, you'll quickly become frustrated. FreeBSD + threads = headache, IMHO).

Installing OpenVPN on FreeBSD is as simple as this:

admin@max>cd /usr/ports/security/openvpn
admin@max>make install clean

And that's it. After a few minutes, I had a nice, clean installation of OpenVPN. Now to configure it.

In the FreeBSD world, configuration files are stored in /usr/local/etc/openvpn. So, I went there, and followed the instructions found here: http://openvpn.net/howto.html#config (Please note that the docs indicate helpful scripts for setting up keys etc. are in /usr/share/doc/openvpn, but in the BSD world they seem to be in /usr/local/share/doc/openvpn).

The only hiccup I ran into was that the docs give examples using the bash shell, and I tend to stick to tcsh. Not a big deal. I just ran these commands:

admin@max>pkg_add -r bash
admin@max>rehash
admin@max>exec bash

and I was in bash, where things all worked the docs indicated. Simple enough.

Once I had all my certs set up, my final openvpn.conf file looked something like this:

[tcs@max] /usr/local/etc/openvpn> cat openvpn.conf
# Specify device
dev tun
proto udp

# Server and client IP and Pool
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

# Certificates for VPN Authentication
ca /usr/local/etc/openvpn/ca.crt
cert /usr/local/etc/openvpn/server.crt
key /usr/local/etc/openvpn/server.key
dh /usr/local/etc/openvpn/dh1024.pem

# Routes to push to the client
push "route 10.10.132.0 255.255.255.0"

# route all traffic through vpn
push "redirect-gateway def1"

# Use compression on the VPN link
comp-lzo

push "dhcp-option DNS 10.10.132.123"

# Make the link more resistent to connection failures
keepalive 10 60
ping-timer-rem
persist-tun
persist-key

# Run OpenVPN as a daemon and drop privileges to user/group nobody user nobody
group nobody
daemon

Finally, since I wanted to use my server as a gateway to my internal LAN, I had to change my pf.conf file (the firewall configuration). The relevant line looks like this:

# nat for vpn
nat on $int_if from $vpn_net to any -> ($int_if)

where $inf_if is the interface device connected to the internal network, and $vpn_net is the subnet I've assigned to the VPN (10.8.0.0/24).

More on this, and on client configuration, when I have a bit more time.

Update: Part three is here.

The Adventure Begins

2006-09-28T14:33:00.000-03:00

So I've started getting together the things I'll need to build my biquad wifi antenna. After some scrounging and a few trips to the web, I have acquired the first two bits of equipment I need to start: copper, and an n-connector. They're not much to look at yet, but here they are:

The copper was free -- scrap donated from a local sheet metal shop, and bent into shape very carefully using a couple of bits of lumber. It was fairly trivial.

The n-connector set me back slightly under six dollars. Next, I'll see if I can scrounge some copper wiring somewhere, and bend it into the appropriate shape.

Free Wifi Internet for around $20

2006-09-25T07:17:00.000-03:00

The city I live near has free WiFi Internet, with very good coverage inside the city limits. Unfortunately, I'm some 15 miles outside those limits, and thus forced to pay for either DSL or cablemodem service. This just doesn't seem right to me. Free Wifi access a scant 15 miles away? There has to be some way to connect.

So, it's off to Google, and lo and behold, I discover this: How to build a biquad wifi antenna, over at Engadget. Given some copper, about $20 worth of gear, and a used satellite dish, you can vastly extend the range of a wifi network.

A bit more reading over here, at Martybugs, suggests that the actual antenna portion can get a higher gain with a few modifications to the design given at Engadget. Checking out Martybugs' sources leads me here, to Trevor Marshall's information. This gives even more detailed information. Hey -- I have a soldering iron and a highly developed sense of adventure, so why not?

I think I'll give it a go. I'll keep you posted.

Virtual Private Networking for Everyone - OpenVPN

2006-09-24T16:51:00.000-03:00

I own a small tech firm on the East coast, and have long wanted a safe, secure method of connecting from my residence (about 15 miles outside of the city) to the LAN at the office. My network at the office is mixed, consisting of Windows XP machines, various Macs, and both Linux and FreeBSD servers. At home we have a single XP machine, and several Mac notebooks (iBooks and Intel-based MacBooks).

Naturally, the best solution for connecting between the two locations would be a Virtual Private Network of some sort. Given the fact that I am notoriously cheap, I decided to search around and see if I could come up with some sort of open source solution... and it took me all of fifteen minutes with my favourite search engine to come up with a viable alternative: OpenVPN. It took me a bit longer to get everything working as well as I wanted to, but not all that long. Read on if you'd like to see how I did it.

Why use a VPN?
There are any number of reasons why you might want to have a VPN in place. For example, with a properly set up VPN, you can access resources at one location from the other. So if I want to print something at the office from home, I can do that. Similarly, if I need to recover a file from offsite back up (read: the backup server I keep in my basement) I can do that without having to drive all the way home.

Of course, there are the more obvious things a VPN will give you. If you use a wireless home router that's more than a year or two old, chances are it uses one of the more archaic forms of encryption, like WEP. The problem with these encryption methods is that they don't actually protect your data; anyone with the inclination could park outside your house, apartment building, whatever, and "sniff" your network traffic. Encrypting all traffic between your web browser and some secure gateway will take the wind out of some potential hacker's sails. Remember, just because you're paranoid doesn't mean they're not out to get you....

Or, if you're so paranoid you don't even trust your ISP, you can use a VPN between your home computer and a secure gateway you control somewhere else (like your office) and encrypt allthe traffic that exists on your ISP's network. It won't get decrypted until it hits your gateway machine. Of course, assuming you are a relatively law abiding citizen, this might be going a bit far (unless you are partial to tinfoil hats, that is).

Why OpenVPN?
OpenVPN is free, cross platform, and relatively easy to install and maintain. It also uses a very secure ecryption algorithm -- 128 bit Secure Sockets Layer (SSL) or the same level of encryption you probably use when you access your banking information online. I figure if it's good enough for the major North American financial institutions, it's probably sufficient for my purposes.

Installing OpenVPN
We decided to install OpenVPN on a FreeBSD box, using ports. It was trivial. We'll post a detailed howto here in a week or so. But if you have access to a FreeBSD box, ports is the way to go. Trust me.

Installing OpenVPN clients
Reading the documentatation found on OpenVPN's web site suggests that this is a daunting task. It probably is, if you elect to go their route. We decided to stand on the shoulders of those who have gone before, and use some simple solutions where the heavy lifting is done for us.

For the Windows clients, we went with OpenVPN GUI (http://openvpn.se). Installing it took about 30 seconds, and configuring it took a bit longer (but not much).

For the Macintosh clients, we went with Tunnelblick (http://www.tunnelblick.net). Granted, it has a rather silly name, but it works very, very well, and didn't give us any problems on either the G4 based Macs, or the Intel based machines.

Stay tuned for the technical details of how we made this all work...

Update: Part two is here.