Browse securely with OpenVPN

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?

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

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

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

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

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

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

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

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

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:

1. Generate your public/private key pair
   
2. Install the keys on the machines you are going to use to access the server
   
3. Modify your ssh server's config file to require known keys
   
4. 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

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

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

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

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

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

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

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

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

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

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

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:

• XORP
• FREESCO Project
• Vyatta OFR

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

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

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

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

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

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.