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.