Introduction

Samba is a tool most known for it’s ability to provide windows file sharing cababilities to linux/unix platforms. With very little effort you can set up a Samba file server which will cost you very little. If you had to go out and buy one of the Windows server editions you’d be up for at least a couple of thousand dollars in windows licenses.

In addition to basic file server, Samba actually join your Windows Domain, which allows it to authenticate users against your Window security infrastructure. There’s no need to synchronise user databased between systems, because Samba reads all this information directly from your domain controller(s). So restricting access to Samba shares to particular Windows users or groups is simply a matter of a little configuration.

This also opens the door for other applications running in your unix environment to authenticate against a Windows Domain. For example, authenticating users when accessing the internet through a Squid web proxy (but I’ll leave the configuration of that for another day…).

Installation

I’m not going to go into too much detail here, because installation is usually handled pretty well by most linux distributions. We user Debian Linux which automates most of the installation process. If you want to roll it your self grab it from the Samba download page and follow the very good documentation. If like us you use Debian just run:

# apt-get install samba winbind

Winbind is the part of samba that is responsible for for integrating windows authentication and the user database into unix.

NOTE: I’m assuming you’re using Samba 3.0.x, which has been out since Sept 2003, so there’s no good reason not to be running it. I’m using 3.0.7 because it provides the latest and greatest functionality to authenticate to a Windows domain… and fixes a couple of issues.

Configuration

Open up the Samba config file smb.conf, which on Debian is located /etc/samba.

First set the workgroup setting to the name of your windows domain, e.g.

workgroup = MYDOMAIN

To instruct Samba to use the domain for it’s user/group database you need to set the security settting as follows:

security = DOMAIN

To allow winbind to map windows users and groups into the unix world you need to instruct winbind which uid and gid ranges to use. Make sure these don’t overlap with entries in your /etc/passwd and /etc/group files. Add entries like the following:

idmap uid = 10000-20000
idmap gid = 10000-20000

And by setting the following you won’t have to prefix your usernames with the domain (i.e. MYDOMAINuser) from within unix, because the default domain will be assumed by default.

winbind use default domain = Yes

Then save your changes to smb.conf.

Joining the Domain

Before you restart your Samba daemons for the changes to take effect, you need to do the following to join your Samba machine to the windows domain. You’ll probably need to be running as root. The username/password you specify here is a Admin user on your windows domains that has permission to add machines to the domain.

# net rpc join -UAdministrator%'password'
Joined domain MYDOMAIN.

Now you can (re)start your sambe service (smbd, nmbd, winbind). On Debian do:

# /etc/init.d/samba restart
Stopping Samba daemons: nmdb smbd.
Starting Samba daemons: nmdb smbd.
# /etc/init.d/winbind restart
Restarting the Winbind daemon: winbindd.

Now you have to tell your system to use winbind in addition to the standard files (/etc/passwd and /etc/group) as a user/group database. To do this edit /etc/nsswitch.conf as follows:

passwd: files winbind
group:  files winbind
hosts:  files dns winbind

And then we need to tell winbind what user to use when initiating sessions to your domain controller. To do this (using an admin user on your domain):

# wbinfo --set-auth-user=Administrator%password

Testing it all

And finally we should be able to test that all the above works ….

# wbinfo -u
MYDOMAINAdministrator
MYDOMAINGuest
MYDOMAINmatt
... remainder of domain users ...

If you got a list of users from your domain then we’re cooking with gas! wbinfo -g will give you a list of all your domain groups.

To check that winbind is doing it’s job you should be able to query the unix user database and find users from your windows domain, like below:

# getent passwd Administrator
Administrator:x:10000:10000::/home/MYDOMAIN/Administrator:/bin/false

Woohoo … it’s working. Winbind is authenticating to the windows domain. More later on useful ways on how to make use of this.

I spent quite a bit of time over the weekend configuring the new Papercut mail server. We’re running Debian Linux on our servers. It’s a great distribution that makes it damn easy to get almost any linux application working…

apt-get install app-name

… wait a few seconds while apt-get downloads the package and any of it’s dependencies and installs and you’re done.

Choice of mailbox format

The key decision you need to make before choosing the IMAP server is the mail folder format. Each IMAP server has a preferred mail box format, so choosing the right format first time, could save you a lot of time down the track. You have the choice of:

• mbox — the traditional UNIX format. One file contains all mail in the folder
• mbx — an updated version of mbox that make some common operations faster
• maildir — each message is stored in a separate file within a directory

To me the idea of storing all mail in a single text file sounds a horrible. When you delete a single message from a huge mail folder, the whole file could have to be rewritten. Care must also be taken so that 2 processes don’t try to update the mail folder at once, otherwise corruption could occur. The mbox/mbx vs. maildir issue seems to be fairly contentious, but to me maildir seemed the more natural way to go. It also allows us to write simple scripts to move mail between folder (… something we do when setting up the spam filtering below).

Choice of IMAP server

Now that we’ve chosen maildir as the mail box format, we need to choose an IMAP server. The main choices are:

• Courier — very popular but complex
• Dovecot — simple and uses indexing to make folder and message access fast

Simple and fast sounded good to me … so Dovecot got the nod.

The MTA — Exim4

The server started it’s life as a Debian 3 “Woody” which used Exim3 as its MTA. Exim3 was doing a fine job, but given that Exim 4 is the default for the upcoming Debian release and Exim3 was no longer developed I chose to upgrade.

apt-get install exim4

… answer a couple of questions … and it’s working perfectly! Lovely.

The only thing we need to do to tell Exim to deliver to a maildir instead of the mbox default. In Debian it’s just a matter of setting the LOCAL_DELIVERY=maildir_home in the exim config file. The result of this is that an exim router for local mail is configured to deliver mail to the following transport:

maildir_home:
debug_print = "T: maildir_home for $local_part@$domain"
driver = appendfile
directory = $home/Maildir
delivery_date_add
envelope_to_add
return_path_add
maildir_format
mode = 0600
mode_fail_narrower = false

Make sure you restart exim …

~$ /etc/init.d/exim4 restart
Restarting MTA: exim4.

To test that things are working correctly try something like this:

~$ sendmail localuser
hello
.

If all went well, a maildir should be created for the user you sent the mail to in . The new/ subdirectory should contain a file containing the message you just sent.

If that didn’t work, you might have to look through some logs to see what went wrong. On Debian, look for:

/var/log/mail.info
/var/log/mail.err
/var/log/exim4/exim4.log

OK, now for the IMAP setup…

Installing Dovecot IMAP

Some more Debian magic …

apt-get install dovecot

… connect to the server with Mozilla Thunderbird using IMAP. Hey, presto … it works!! I can see the test email in the inbox.

OK, so local mail delivery is now working. But that’s not very exciting. All our mail gets delivered to POP accounts on the hosting service. To deliver the mail locally I use fetchmail which periodically polls one or more POP inboxes and delivers the mail to local users via the local MTA. (I actually have more than one POP account … but fetchmail can handle that with ease.

Setting up fetchmail

Once fetchmail is installed it’s a simple of matter of telling it where to fetch the mail from. Create a file in your home directory called .fetchmailrc, and for each POP account you want to collect mail from add a line:

poll mail.myisp.com protocol pop3 user "username" pass "password"
is "localuser" here keep

The keep option tells fetchmail to keep the mails on the POP server. This is recommended until you’re sure it’s all working. Otherwise an incorrect mail server setup my cause you to lose mail.

To test that it’s working ok type:

~$ fetchmail
fetchmail: No mail for username at mail.myisp.com

It will output details of the connection to your mail server(s) and whether it retrieved any mail. It’s probably a good idea to send some test mail to your account and then re-run fetchmail. If all goes well the mail will end up in the ~/Maildir/new directory. (NOTE: Try to send mail from a different account … because if something goes wrong you won’t be able to easily see the delivery failure message.)

If you call fetchmail with the -F option it will delete any messages that it’s already downloaded. So I’ve set up a crontab to call fetchmail every 5 mins and leave the mail on the server. Then once a day I call fetchmail -F to clear mails from the POP account. This way if something goes wrong with the mail server, then the mail will be stored safely on the POP server for 24 hours. So nothing will get lost.

The blog’s been up for a couple of days and I’ve got my first comment … how exciting! Thanks Gunther Dippe.

Since the last blog I’ve spent quite a lot of time researching tools to use for our knowledge base, FAQs, etc. I’ve looked at about 5 different CMS systems (Drupal, Mambo, Plone, etc). But they’re all a bit over the top for our needs. So I started looking more into wikis.

We need something that is:

• simple to customise the look and feel
• supports security (so no just anyone can update pages)
• make editing pages and articles easy
• allows our resellers to translate the pages
• needs to be hostable by our provider without a DB

That cuts down the field considerably.

I downloaded and installed about 6-7 different wikis, that were mostly powered by PHP (which we can run on our web servers). I ruled out most due to their dependence on a database, and others because they were hard to customise the look. I also really hate the look of wikis WhenAllTheLinksOnTheirPagesLookLikeThis. In the end I decided that a simple wiki called pmWiki was the way to go. It’s simple, configurable and it works!

Within about 20 minutes I had it up and running and looking just like the main Papercut site. It needs a little bit of tweaking, but not much.

It’s going to make creating great documentation easy, which leads to higher quality docs and satisfied customers. (Hopefully!)

After examining a few different options for blogging software, I’ve decided to choose Wordpress as Papercut Software’s standard blogging tool.

It’s really feature packed and is easy to set up. The only downside at the moment is that you need a separate installation for each blog. That means that when I customise the style to match the website, I have to make those changes in all blogs. Hopefully true multi-blog support will be added eventually so I can avoid this duplication of effort.

The Worpress wiki explains how to setup multiple blogs to use the same MySQL database, so that’s what I’ve done.

We’re also in the process of evaluating products to enhance web site for PaperCut customers. We’re currently looking into a:

1. Forums - to build a community of Papercut users, where questions can be asked and answer by both us and other users
2. Knowledge Base - a searchable list of article, how to guides, FAQs, etc. We might use a wiki as a way to maintain the pages (and possibly even let users help out!)

The current contender for the forum is phpBB2. For the knowledgebase/wiki I’m look at MediaWiki (which is the tool that drives the fantastic wikipedia). It’s is really polished, but given that it’s focus is on building an encyclopedia, it might not meet our needs (i.e. user security, etc).

Maybe we’ll need a proper Content Management System instead? But maybe that’s overkill …