Much like being able to tell (but not necessarily care) when I’m boring someone with a particular conversation, I use website analytics to see where website visitors come from, what they look at, and how frequently they return. Yes, some people come back. In fact, most people do. And the most popular pages are actually the NSLU2 guides which describe how to configure a very small, low-power Linux server based on a Linksys NAS device.

I have no delusions about the overall importance of nikrivers.com; nobody knows about it, it doesn’t appear very high up in any Google results unless you search for my name, and even my mum keeps forgetting how to find it (though she also has to keep asking me how to find the Internet, because “it’s gone from my desktop”).

That said, 101 different people have visited my NSLU2 guides in the last 20 days alone, about a third of which are visitors who have never been to my website before. Even after Linksys has discontinued the NSLU2, it still remains popular as a web and mail server.

But after changing blog themes the other day, I realised the NSLU2 pages were actually quite dependent on the underlying CSS – and for some themes, this means that they looked rubbish.

So I went about reformatting the pages. There are only half a dozen of them, and only one or two are of any considerable size – but this was enough to find exactly how annoying the WordPress WYSIWYG editor can be. I ended up with inconsistent newlines (although the HTML was consistent), weird closing tags that didn’t match anything else in the document, and random behaviour whereby the editor would say something along the lines of “hey, I can’t figure out exactly what you’re trying to do, so why don’t I double-space half of this here single-spaced text, indent the whole document from this point onwards, and completely unformat all your headings?”

There’s a little feature on the WordPress.org website called Kvetch!, which allows users to anonymously vent their annoyance at WordPress’s quirks and bugs. I had seen that several people don’t like the built-in HTML editor that WordPress has, but I myself had only ever needed to write a few paragraphs and make a couple of words bold, nothing more – and for this it is fine adequate.

But for decent formatting capabilities, the built-in editor just doesn’t cut it. It is what I have decided to call a WYSINWYWBYWJHTGWI editor. Yes, a What-You-See-Is-Not-What-You-Want-But-You-Will-Just-Have-To-Go-With-It editor. I’m going to register that as a trademark so that the WordPress people can’t thieve it from me when they release their next iteration.

So, there was else nothing for it. I cracked open Microsoft Visual Studio 2005, and used that as my editor to reformat everything. I didn’t use the WYSIWYG designer, I just wanted something that would give me syntax colouring.

I was fully prepared to go so far as to use notepad – but I think that would have been a little too hardcore for my liking.

With this theme, my NSLU2 guides currently look like they were formatted by a 4-year-old, so I might get round to fixing them, eventually. They’re by far the most popular pages on this site!

Installing CUPS

First off, install CUPS and its documentation package. Strangely enough, the docs include a lot of the files required to run the CUPS web interface.

ipkg install cups
ipkg install cups-doc

First of all, edit the CUPS config file.

vi /opt/etc/cups/cupsd.conf

There are a few lines which restrict access to CUPS to only the 192.168.0.0/24 network. This is fine for a lot of people, but if your network doesn’t use that range of addresses, you need to edit them accordingly.

Now you need to make sure your printer is connected to the Slug. By default, CUPS has no permissions on the device that represents the printer (/dev/lp0). Fix that with:

chmod 777 /dev/lp0

Next you need to put the startup script in /opt/etc/init.d so that CUPS can start automatically. Most other packages do this as part of their installation/configuration process, but with CUPS this has to be done manually. Also, start CUPS.

cp /opt/doc/cups/S88cups /opt/etc/init.d
/opt/doc/cups/S88cups

Now you can use a web browser to browse to http://your-slug:631 (where your-slug is the host name or IP address of your Slug) and use the CUPS web interface to manage your printer. Under Manage Printers you’ll see there’s already an HP 990c installed. While the HP990c apparently works with the majority of printers, I prefer to use the right driver for my printer – so I deleted the HP 990c, then went through the ‘Adding a printer to CUPS’ process.

Adding a printer to CUPS

From the main page in the CUPS web interface, click Add Printer. You will probably be presented with the message 426 Upgrade Required. This means that CUPS requires that your browser switches from http to https, but can’t do it automatically – you need to click the link, and you’ll be asked to provide a valid username and password to continue. Using root here is fine.

On the page that follows, give your printer a name – bear in mind this name will be part of the printer’s URL, so it can’t contain spaces, hashes or slashes. Provide a description and the location if you want, too.

On the next page, choose your printer from the drop-down list. CUPS queries the printer for this information, so it’s pretty accurate. If your printer isn’t listed, you probably forgot to change the permissions on /dev/lp0 as described above.

CUPS will then display a list of drivers, and you’ll probably not see your printer there. So head over to http://www.linuxprinting.org/printer_list.cgi, search for your printer, and download the PPD file for it. Once that’s done, return to the CUPS page. Click Browse… and select the PPD you downloaded, then click Add Printer. You’re done.

All you need to do now is click the Printers tab at the top of the page, and start your printer if it isn’t already started.

Note that your printer needs foomatic-rip if your Printers page shows a message such as this:

Filter “foomatic-rip” for printer “HP-PhotoSmart-8150″ not available: No such file or directory

My testing showed that my printer worked fine without foomatic-rip, but the printer needed to be started manually every time CUPS (or the Slug) restarted. There is probably a setting in the configuration file to force a printer to attempt to start regardless of errors, but I found installing foomatic-rip to be a cleaner fix:

cd /opt/lib/cups/filter
wget http://www.linuxprinting.org/foomatic-rip
wget http://www.linuxprinting.org/foomatic-gswrapper
chmod 755 foomatic-rip foomatic-gswrapper
/opt/etc/init.d/S88cups restart

No more error message, and the printer starts automatically when CUPS starts.

It is also worth backing up the /opt/etc/cups/printers.conf file. CUPS has a tendency to overwrite it with a file of the wrong format when you click on certain options in the web interface, resulting in 403 Forbidden errors when you try to access the web interface.

cp /opt/etc/cups/printers.conf /opt/etc/cups/printers.conf.backup

Using a CUPS printer in Windows

In Windows Vista, installing the printer is simple. Open the Control Panel, go to Printers, and then Add Printer. Select Add a network, wireless or Blutooth printer, and click Stop on the next page of the wizard; it won’t detect the printer, but you can add it easily, so click The printer that I want isn’t listed.

In the Select a shared printer by name text field, enter http://your-slug:631/printers/printer-name. You need to replace your-slug with either the host name or IP address of your Slug, and printer-name with the printer name you chose. Click Next. You will then be presented with a list of printer drivers to choose from. The list contains all the drivers that shipped with your release of Windows Vista plus all those that you have installed. If you don’t see the right printer driver in the list, visit your printer manufacturer’s website to download the right driver, and install it.

In Windows XP, open the Control Panel, go to Printers and Faxes, and then Add a Printer. Select Connect to a printer on the Internet or on a home or office network, and in the URL field enter http://your-slug:631/printers/printer-name. You need to replace your-slug with either the host name or IP address of your Slug, and printer-name with the printer name you chose.

Windows XP doesn’t have as comprehensive a driver database as Windows Vista, so the likelihood is that your printer won’t be shown in the dialog you see next (unless you had already installed your printer drivers on that computer). Download the drivers from your manufacturer’s website (or use the printer’s driver disk), and select Have Disk. Locate the driver and click OK, then choose the exact printer from the list that follows.

Issues

On Windows XP, certain actions or operations will cause a crash in Word 2003 and Word 2007 if a CUPS printer is installed and set as the default printer, but the CUPS server is unavailable.

The action that triggers the crash does not obviously relate the problem to the printer’s availability, but removing the printer (or setting a different printer to default) will prevent the problem – as will ensuring CUPS is always online and available to Windows XP clients.

This doesn’t seem to happen on Windows Vista.

If this information was useful, please leave a comment to let me know!

When it comes out of the factory the Slug has an inherrent bug which causes the internal clock to lose time; apparently Linksys tried to fix this problem by adjusting the time regularly (using cron) but it seems the time is adjusted in the wrong direction – thus, the error is doubled. This problem is fixed in Unslung 2.6 and higher anyway (Unslung 2.10 is the latest release as at Jan 2009), so we can remove the relevant crontab entry.

Edit the crontab file:

vi /etc/crontab

Comment out the call to hwclock (the Linksys ‘fix’). The hash (#) symbol is used to denote a comment:

#1 * * * * root /usr/sbin/hwclock -s &>/dev/null

Now install ntpd, and edit the config file to contain time servers that are geographically close to you – you can find out what these are by visiting http://www.pool.ntp.org/. Editing the config file is quite self-explanatory.

install ntp
vi /opt/etc/ntp/ntp.conf

Now edit the ntp startup script; there are a few things we need to do to make sure the time is set and maintained correctly.

vi /opt/etc/init.d/S77ntp

Add the following lines just before the existing call to ntp:

/opt/bin/tickadj 10000 > /dev/null
/opt/bin/ntpd -q -c /opt/etc/ntp/ntp.conf > /dev/null

The first line corrects the Slug’s tick value, and the second line makes ntp quickly (-q) set the time using the specified time servers, and exits. It is important to note that when ntp is running, it does not just simply set the correct time regularly; it constantly checks the time against that of the time servers, and gradually brings the system time in line. The call we just added, with the -q flag, ensures that the Slug has pretty accurate time before ntp starts properly.

Speaking of which, you will need to make sure the Slug has accurate time now. This can be done using the web interface, for example. It only needs to be as accurate as you can get it, and ntp will take care of the rest.

Now simply restart ntp:

/opt/etc/init.d/S77ntp restart

It will take a while for ntp to synchronise with the time servers you specified in the config file, sometimes upwards of 15 minutes – so don’t be too concerned if nothing seems to be happening straight away. You can check what’s going on with the ntpq tool:

ntpq -p

The command will list information about the time servers. If ntp has decided on a server’s suitability for synchronisation, the time server’s name will be preceeded by * (the chosen server), + (server is suitable), or - (server is unsuitable).

Note: if you are running Dovecot on your Slug, and ntp adjusts the time backwards after you initially set the Slug’s time (using the web interface), Dovecot will complain about time going backwards, and die. You will need to restart Dovecot; but this only happens while you’re configuring ntp, and won’t happen during normal operation once ntp is running.

If this information was useful, please leave a comment to let me know!

ipkg install openssl

Without going too deeply into SSL or TLS discussion, there are a few things to know. TSL is the successor to SSL, but they’re both very similar, being protocols for secure communication. We’ll be using SSL for pop3 and TLS for smtp.

In addition to encryption, SSL and TLS offer the ability to ensure we are communicating with the server we think we are. This is achieved through trust; when we first enter communication with our server, it will send us its certificate. This certificate is signed by a Certification Authority (CA) attesting that the server is who it says it is. Of course, we have to trust the CA’s word on this, but usually the CA will be someone reputable like Comodo or VeriSign.

But we don’t need to convince the public we are who we say we are, we only need to make sure that we’re connecting to our own email server. So we’ll be acting as our own CA, and signing our own certificate. After all, if you can’t trust yourself, who can you trust?

Versions

This how-to guide was updated in May 2009 for compatibility with the following package versions:

• Postfix 2.3.6-3
• Dovecot v1.2.0.beta1-2

This how-to may also work with previous versions, but may require slight changes with respect to paths – for example, previous versions of Dovecot installed dovecot.conf to /opt/etc/dovecot.conf, but the latest version installs it to /opt/etc/dovecot/dovecot.conf.

Creating the CA key and certificate

First of all, let’s find somewhere to store all our SSL stuff. I chose /opt/etc/ssl. Make the directory if it’s not already there, and cd to it. We need to create a few directories and files that openssl expects.

mkdir certs crl csr newcerts private
touch index.txt
echo 01 > serial

The openssl distribution came with a default configuration file, and we’re going to edit some of the values, so be sure to back it up first:

cp /opt/share/openssl/openssl.cnf /opt/share/openssl/openssl.cnf.orig

Now edit the config file:

vi /opt/share/openssl/openssl.conf

And modify the contents as you see fit. Pay particular attention to the paths; there’s only a few things you need to change:

dir = /opt/etc/ssl
[ policy_match ]
countryName = match
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

Save the file, and you are ready to create your own CA private key and certificate with the following command:

openssl req -new -x509 -days 3650 -keyout private/cakey.pem -out cacert.pem

You’ll be prompted for a little bit of information; you can leave fields empty to accept the [default], or enter a period to leave the field blank. Note that I edited the default values in the config file.

Country Name (2 letter code) [UK]:
State or Province Name (full name) [England]:
Locality Name (eg, city) [London]:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:Nik Rivers CA
Email Address []:

The important field is Common Name (CN); it is the name of your CA. Once you have entered all the required data, openssl will generate a private key and a certificate. Note that you will be asked for a passphrase; your private key cannot be used by anyone who doesn’t know this passphrase. You can remove the passphrase if you like – I chose to do so because I couldn’t imagine anyone wanting to misuse it, let alone being able to find it in the first place.

mv private/cakey.pem private/cakey.pem.orig
openssl rsa -in private/cakey.pem.orig -out private/cakey.pem
rm private/cakey.pem.orig

Creating the mail server key and certificate

Now simply issue this command to create your mail server certificate signing request:

openssl req -newkey rsa:1024 -keyout private/mailserver.key -keyform PEM -out csr/mailserver.csr

You’ll be asked a few familiar questions; this time, answer the questions bearing in mind this is the certificate for your mail server. Of particular importance is the CN field, which should ideally be the fully-qualified hostname of your mail server, such as mail.yourdomain.com. The challenge password and optional company name can be left blank. Now we must remove the passphrase from the mail server key – since otherwise Dovecot requires the passphrase to be provided in the config file (in plain text) and Postfix just plain won’t work.

mv private/mailserver.key private/mailserver.key.orig
openssl rsa -in private/mailserver.key.orig -out private/mailserver.key
rm private/mailserver.key.orig

Finally, sign your request with:

openssl ca -in csr/mailserver.csr

You will be asked if you want to sign the certificate, and whether you want to commit. Double-check the data, answer yes to both questions, and openssl will dump a load of info in front of you. You can now view your mail server’s signed certificate with the command:

more newcerts/01.pem

You can copy and rename the 01.pem and cacert.pem files to something more meaningful if you like, and if you will be using Windows clients to access the email server I recommend changing the file extension from pem to crt, so that Windows understands the file format:

cp newcerts/01.pem certs/mailserver.pem
cp newcerts/01.pem certs/mailserver.crt
cp cacert.pem certs/
cp cacert.pem certs/ca.crt

I then removed the certificate signing request.

rm csr/mailserver.csr

Configuring Postfix

vi /opt/etc/postfix/main.cf

Add this at the bottom of the file:

# TLS
smtpd_tls_cert_file = /opt/etc/ssl/certs/mailserver.crt
smtpd_tls_key_file = /opt/etc/ssl/private/mailserver.key
smtpd_tls_security_level = may

Setting the smtpd_tls_security_level parameter to may allows clients to connect with or without TLS; we could set this to encrypt, which forces the use of TLS, but my testing shows that it prevents other MTAs from being able to relay mail to the Slug.

Restart Postfix:

/opt/etc/init.d/S69postfix restart

Configuring Dovecot

vi /opt/etc/dovecot/dovecot.conf

Change or add (as appropriate) the following:

protocols = pop3s
ssl_disable = no
ssl_cert_file = /opt/etc/ssl/certs/mailserver.crt
ssl_key_file = /opt/etc/ssl/private/mailserver.key

Restart Dovecot:

/opt/etc/init.d/S90dovecot restart

Done.

Using the certificates

You have a couple of options. Your email client will probably ask you if you should trust the server’s certificate now and always, and agreeing to this is good enough.

Or you could install your CA certificate on your computer, which would cause all certificates that you, as a CA, sign – including your mail server’s certificate.

In Windows Vista, this is simply a case of right-clicking on the cakey.crt file, and selecting Install Certificate. The Certificate Import Wizard then guides you through the process – but when it asks you which certificate store to use, select the Trusted Root Certification Authorities store. Now when you open your mailserver.crt file Windows will show the certificate as being trusted implicitly since it was issued by you.

Configuring your mail client

All you need to do is tell your mail client to use TLS when connecting to the smtp server, and to use SSL over port 995 (pop3s) when connecting to the pop3 server.

For example, in Office Outlook 2007, when editing your mail account, click More Settings… and go to the Advanced tab. Under Incoming server (POP3) tick This server requires an encrypted connection (SSL). This will automatically change the pop3 port to 995. Under Outgoing server (SMTP) change Use the following type of encrypted connection to TLS. The Auto setting will also work, but why make Outlook guess when you can tell it the answer?

If this information was useful, please leave a comment to let me know!

Many thanks go to Raymond Mentjens (www.mentjens.nl) for his help in fixing a few (actually, quite a few) errors, and for all his feedback while he followed this article.  He has also created his own guides in Dutch – so if you read Dutch better than English, you may want to take a look at his site.

Versions

This how-to guide was updated in May 2009 for compatibility with the following package versions:

• Postfix 2.3.6-3
• Dovecot v1.2.0.beta1-2

This how-to may also work with previous versions, but may require slight changes with respect to paths – for example, previous versions of Dovecot installed dovecot.conf to /opt/etc/dovecot.conf, but the latest version installs it to /opt/etc/dovecot/dovecot.conf.

Install Postfix

Issue the command:

ipkg install postfix

The Postfix installation automatically creates a new group called maildrop; check maildrop is created:

more /etc/group

If the group is not there, you will have to create it yourself. Also note that it might suddenly disappear, requiring you to add it manually. For both eventualities, see the notes below.

Now we’ll need to start editing the configuration files to customise Postfix to our needs.

vi /opt/etc/postfix/master.cf

Add -v to the end of the line that specifies the smtp daemon so it reads smtpd -v (the line you need to modify is the first in the table, just beneath several lines of comments). This enables verbose output to the log file, which you should monitor in a separate PuTTY window using the following command:

tail -f /var/log/messages

This will help give you an idea of when and why problems occur. Note that tail sometimes hangs, and if you don’t see log output when you think you should then it may be time to abort tail (with CTRL+C) and restart it.

Let’s edit the main Postfix configuration file:

vi /opt/etc/postfix/main.cf

And provide our own values for the following parameters:

myhostname = <your slug’s host name – eg. mail.yourdomain.com>
inet_interfaces = all
proxy_interfaces = <your external ip address>
mynetworks_style = subnet

Before Postfix can be started, it needs to know where to deliver mail that is addressed to users such as root, postmaster, and other pseudo-accounts. The file that contains this mapping is /opt/etc/postfix/aliases. Edit the file:

vi /opt/etc/postfix/aliases

Uncomment the root alias, and provide the address where mail to root should be delivered (using your own address is a wise choice):

# Person who should get root’s mail. Don’t receive mail as root!
root: <your email address>

Now the file should be copied to /opt/etc/aliases, and turned into a hash file that postfix can read, using the newaliases tool. The output file is /opt/etc/aliases.db:

cp /opt/etc/postfix/aliases /opt/etc/aliases
newaliases

Now start Postfix, keeping an eye on your second PuTTY window for any messages Postfix might emit.

/opt/etc/init.d/S69postfix

At various points you’ll need to change Postfix configuration, and Postfix will need to reload those changes. You can do this with:

/opt/etc/init.d/S69postfix restart

Or, if you don’t like to keep stopping and starting it, you can simply issue:

postfix reload

Testing Postfix

Use telnet to connect to your slug’s smtp port:

telnet <slug’s host name or IP address> smtp

Make sure you can send mail, by having the following conversation with Postfix:

220 mail.yourdomain.com ESMTP Postfix
mail from:some_user
250 2.1.0 Ok
rcpt to:<an external email address you can check>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
Subject:Test Mail 1
This is a test message.
.
250 2.0.0 Ok: queued as EF7E4208003

When you check the email address to which you sent your test mail, you’ll see it comes from some_user@mail.localdomain (or something similar, according to what you put in your postfix configuration file), and is generally badly formed. Don’t worry, a proper email client will provide the necessary data, whereas we only provided the bare minimum. Note that some mail servers may reject this test mail because the sender’s address is malformed (i.e. the domain doesn’t exist). In this case, you will need to use a valid-looking email address (such as some_user@test.com) or even your own address.

If you don’t receive the test email, you can check the postfix queue to see whether an error occured:

postqueue -p

And also delete any failed/stuck messages:

postsuper -d <queue_id>

On a side note, it’s a good demonstration of how easy it is to send untraceable spam. The IP address in the email header is the only indication of where the email originated; but this can be faked quite easily.

Finalise Postfix Configuration

There’s already a convenient user and group (both called mail) configured by the system which Postfix can use to manage the mail store, so all we need to do it find out the uid and gid.

grep mail /etc/passwd

The 3rd and 4th elements of the output are the uid and gid respectively. Write them down; we’ll need them in a minute.

We need a disk location for storing users’ mail; I chose /var/spool/vmail, which seems as good as any. The following script creates the initial directory structure, along with the additional directories for user@yourdomain.com mail storage. The /var/spool directory didn’t exists on my system, so rather than checking to see if there was a more logical/suitable storage location elsewhere, I simply created it with brute force.

mkdir /var/spool
cd /var/spool
mkdir vmail
cd vmail
mkdir yourdomain.com
cd yourdomain.com
mkdir user
cd user
mkdir new cur tmp

Now the new directories need the right owners and permissions: root owns /var/spool (and gives full permission to everyone), whereas the vmail directory (and everything within it) is owned by mail, and only mail (and members of the mail group) have permissions.

chmod ugo=rwx /var/spool
chown -R mail:mail /var/spool/vmail
chmod -R ug=rwx,o= /var/spool/vmail

You can double-check this afterwards:

ls -l -R /var/spool/vmail | more

In order to use Dovecot’s SMTP AUTH mechanism, Postfix needs to know where Dovecot’s daemon socket is located. Currently it isn’t located anywhere, so that needs to be fixed:

cp /opt/var/spool/postfix/private/anvil /opt/var/spool/postfix/private/auth
chmod go=rw /opt/var/spool/postfix/private/auth
chown mail:mail /opt/var/spool/postfix/private/auth

Time to edit the postfix config again.

vi /opt/etc/postfix/main.cf

The config file isn’t set up with default values for virtual hosts, so these need to be added. We also tell Postfix that we’re using Dovecot for SMTP AUTH, and point it to the socket location we just created (relative to the queue directory). Note that as soon as we tell Postfix about the socket, it will grumble and complain (and fail to run) because Dovecot hasn’t created the socket yet. We’ll do that shortly.

# LOCAL CONFIG
local_recipient_maps = $virtual_mailbox_maps
# SMTP AUTH
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
# VIRTUAL HOSTS
# Config for virtual domains that are hosted by this server.
virtual_mailbox_domains = /opt/etc/postfix/virtual-hosts
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_maps = hash:/opt/etc/postfix/virtual-maps
virtual_uid_maps = static:<mail uid>
virtual_gid_maps = static:<mail gid>
virtual_minimum_uid = <mail uid>

Replace <mail uid> and <mail gid> with the uid and gid you noted earlier on.

Now we are left with two files to create. The file /opt/etc/postfix/virtual-hosts should contain a list of all the domains you are hosting, one on each line. The file /opt/etc/postfix/virtual-maps defines the storage location for your mail users.

virtual-hosts:

yourdomain.com

virtual-maps:

you@yourdomain.com yourdomain.com/you/
me@yourdomain.com yourdomain.com/me/

The second column is the storage path, relative to $virtual_mailbox_base. So mail for you@yourdomain.com will be stored in /var/spool/vmail/yourdomain.com/you. The trailing slash in the file is important, and specifies that the Maildir format of mail storage is to be used, as opposed than mbox. Maildir stores each mail as a separate file, which makes more sense to me than mbox, which stores all mail in one file.

We now turn /opt/etc/postfix/virtual-maps into a hash file, and give Postfix read permission:

postmap /opt/etc/postfix/virtual-maps
chmod o+r /opt/etc/postfix/virtual-maps.db

You can now restart the server so your changes take effect, but bear in mind that the smptd process will crash if you try to connect to it – because the Dovecot socket doesn’t exist yet.

/opt/etc/init.d/S69postfix restart

Install Dovecot

ipkg install dovecot

First, a warning: Dovecot caused more trouble than anything I’ve done with the Slug so far. It’s easier to configure than Postfix, but easier to mess up, too!

For starters, you will definitely want to edit the Dovecot config to turn logging on:

vi /opt/etc/dovecot/dovecot.conf

At the start of the file insert the following parameters (we’ll be removing them again later):

log_path = /var/log/dovecot
info_log_path = /var/log/dovecot
auth_debug = yes
auth_verbose = yes

Let’s tell Dovecot where mail can be found. Edit the mail_location parameter as follows. This tells Dovecot that mail for you@yourdomain.com can be found at /var/spool/vmail/yourdomain.com/you. Note that in older versions of Dovecot this setting was default_mail_env.

mail_location = maildir:/var/spool/vmail/%d/%n

Now we want to tell Dovecot about the STMP AUTH socket it needs to create. Find the auth default configuration block (about 80% of the way through the file) and add/edit the following configuration block inside the auth default block.

socket listen {
client {
path = /opt/var/spool/postfix/private/auth
mode = 0660
user = mail
group = mail
}
}

This tells Dovecot what we’ve already told Postfix – now Dovecot knows to create the auth socket, and put it in the right location. We now need to tell Dovecot which users are allowed to use our SMTP server and where it can find their passwords. The relevant sections, passdb and userdb, already exist in the auth default block, and should be edited as follows.

passdb passwd-file {
args = /etc/passwd-mail
}

userdb static {
args = uid=<mail uid> gid=<mail gid>
}

The passdb section tells Dovecot to use a passwd-like file located at /etc/passwd-mail to check users’ passwords. The userdb section is usually used in a similar way to look up valid email users – but since we don’t need another look up, we can use the ‘static’ mechanism, in which case Dovecot will rely on the passdb section for both valid users AND passwords.

Don’t forget to replace <mail uid> and <mail gid> with the uid and gid of your mail user and group. If your uid is less than 500 (which, if you used the built-in mail account, it is) you will need to change the first_valid_uid value in the config file to something less than or equal to the uid you are using.

The last thing involving the configuration file is to tell Dovecot which protocol we want clients to be able to use. By default, Dovecot supports only IMAP – but I prefer POP3.

#protocols = imap imaps
protocols = pop3

IMAP has some significant advantages over POP3, providing an Exchange-like environment for email, but it also has its disadvantages. If you’re happy to store all your email locally, you’re only going to connect from a single client, and prefer ISP-like email, the more common POP3 should be just fine.

Now we need to create the passwd-like lookup file.

vi /etc/passwd-mail

It’s content will be of the format <username>:{encryption_scheme}password, for example:

you@yourdomain.com:{plain}yourpassword

The {plain} directive denotes that the password is in plain text; this overrides whatever encryption Dovecot might be expecting – DES in this case (the same as you’d find in /etc/passwd). If you DES-encrypt your password before putting it in /etc/passwd-mail you do not need an {encryption_scheme} directive.

By default, the dovecot-auth process runs as user admin, which is a member of the group administrators. You can change this by editing dovecot.conf, but it is not necessary. The admin user needs read privileges on the mail password file, so give this permission to the group to which user admin belongs:

chown root:administrators /etc/passwd-mail
chmod g=r /etc/passwd-mail

Now you’re ready to start Dovecot. You may like to open a separate session on your Slug and run tail -f /var/log/dovecot to monitor what’s going on:

/opt/etc/init.d/S90dovecot start

If this produces errors, double-check the edits you made to /opt/etc/dovecot/dovecot.conf – a common problem is the mismatching of curly braces { and }.

Testing Dovecot

Now use telnet to connect to Dovecot on your slug:

telnet <slug’s host name or IP address> pop3

You can have the following conversation with it:

+OK Dovecot ready.
user you@yourdomain.com
+OK
pass wrongpassword
-ERR Authentication failed.
user you@yourdomain.com
+OK
pass yourpassword
+OK Logged in.

Great. You now have a working email server which offers SMTP without being an open relay, and provides POP3 to the user(s) you specified.

If Dovecot crashes when you authenticate, and logs “Panic: POP3(you@yourdomain.com): Trying to allocate 0 bytes“, you have found a kown bug with the Dovecot 1.2 beta 1 release (the latest release that is available through ipkg). Although this doesn’t prevent you from using Dovecot, most email clients will complain that the connection to the POP3 server was prematurely terminated. A patch is available at http://hg.dovecot.org/dovecot-1.2/rev/22d70947597c, but I have not had a chance to try it.

Finally

Don’t forget to turn off verbose logging for Postfix and Dovecot. For Postfix, remove the ‘-v’ smtpd parameter from /opt/etc/postfix/master.cf, and for Dovecot remove the first four lines of /opt/etc/dovecot/dovecot.conf (log_path, info_path, auth_debug and auth_verbose).

Limitations

The one big limitation with this set up is that the administration of mail users involves a lot of work. Every time you add a user you must create the relevant entry in virtual-maps, create the user’s mail delivery directory structure, and set permissions. The mitigation against this drawback is that you (probably) won’t be using your Slug as a mail server for more than a handful of email addresses – any heavier use would probably require a more significant investment, and hence more powerful tools.

Notes

Group ‘maildrop’ disappears
It seems that, at some point, the maildrop group ‘disappears’ from /etc/group. It may be something to do with the fact that /etc/group is a symbolic link to /share/flash/conf/group, and thus may be more closely-managed by the Slug than it appears. Regardless, it causes SMTP clients to be unable to connect (because Postfix fails to start), and Postfix emits an appropriate message to /var/log/message.

This can be resolved by manually recreating the appropriate entry in /etc/group for maildrop:

maildrop:x:69:

Fortunately, it seems that this is only required once.

Using your ISP’s SMTP server
Some ISPs may require that any email you send is relayed through their SMTP server; in this case you will likely need to add the relayhost parameter to your main.cf as well (although this wasn’t necessary in my case). Documentation for this parameter can be found on the Postfix website at http://www.postfix.org/postconf.5.html#relayhost. Explicit authentication with your ISP’s SMTP server is usually not required as long as you are connected to the Internet via that ISP’s connection (either dial-up or always-on).

Encryption of stored passwords
When installing and configuring Dovecot, I store email users’ passwords in plain text. If you want to store passwords in an encrypted format, see http://wiki.dovecot.org/Authentication/PasswordSchemes for an explanation.

Next Steps

Firewall
If you have a firewall or NAT between your Slug and the outside world (which is highly recommended) and you want to access your email from anywhere, you will need to configure your firewall or NAT to forward ports 25 (smtp) and 110 (pop3) to your Slug.

Of course, if you open up your email server to the rest of the world, you may want to make sure it can’t be abused. Go to http://www.abuse.net/relay.html, provide your external IP address, and let it test your email server for being an open relay.

Date/Time
It’s a good idea to keep your Slug’s time accurate so that the mail server can timestamp email correctly. This can be done by running an NTP client, which will synchronise the Slug’s time with reliable time servers around the world, or by running an NTP server, which will synchronise the Slug’s time AND allow you to synchronise your network computers’ time with the Slug.

Due to a glitch in the Slug, this isn’t as straight-forward as it could be – but it’s not beyond anyone with enough patience to work with vi.

Detailed instructions are here.

SSL/TLS
These instructions give you a working email server, but all authentication is performed using plain text. That means that anyone using a network sniffer in the right place at the right time could steal your usernames and passwords as you transmit them to the server.

Rather than configure authentication mechanisms that prevent this (and which, to be honest, look difficult to configure), we can encrypt the whole of the communication between client and server using SSL and TLS.

Detailed instructions are here.

Useful Links

http://www.postfix.org/
http://www.dovecot.org/
http://www.nslu2-linux.org/
http://www.howtoforge.com/linux_postfix_virtual_hosting
http://www.howtoforge.com/linux_postfix_virtual_hosting_2

If this information was useful, please leave a comment to let me know!

Installation is very simple:

ipkg install openssh

This will also install and configure openssl, and generate the necessary key and certificate files to enable encrypted connections.

If you don’t already have an SSH client you can download PuTTY for free from http://www.chiark.greenend.org.uk/~sgtatham/putty/.

Once you have successfully connected using PuTTY and SSH, you can turn off Telnet access to your Slug.

If this information was useful, please leave a comment to let me know!

Linksys NSLU2

About the NSLU2

The Linksys NSLU2 is a lovely little NAS storage server with 2 USB ports and an Ethernet LAN port. You can attach two USB hard drives to it and connect it to your network, and use it as a file server.

Or you can download alternative firmware, run a customised version of Linux on it, and use it as a mail server, a torrent server, a print server, a web server, and more.

It supports NTFS, USB hubs, and flash drives. It’s silent, draws no more than 10W of power, runs at 266MHz, and is the size of two Weetabix.

And it’s known as a Slug.

Full details, including the data sheet, user guide and firmware, can be found over at the Linksys website, and some information is available at Wikipedia.

The NSLU2 is now discontinued, but don’t let that put you off – this will only really affect you if you need to return your Slug for replacement under warranty. Flashing your firmware voids the warranty (as does making hardware modifications, which a lot of users seem to do), so its discontinuation seems hardly relevant.

Opinion seems to be divided on this issue, with a few differing viewpoints given on Paul Hutchinson’s blog. Regardless, I predict the NSLU2 will maintain a cult following of users and developers for quite some time.

Where to buy

These things aren’t particularly easy to get hold of in the UK at a decent price, but LambdaTek has them available at around £70, although at dwindling stock levels.

Or, if you’re in the market for a second-hand Slug, I have a spare for which I cannot find a use; I’m more than happy to consider offers on it. It’s the 266MHz version (as opposed to the 133MHz version) and has a UK power supply. For use outside the UK, a travel adapter should be fine since the power supply is auto-switching, or a generic 5V-2A power supply would do the trick.

The Linksys NSLU2 is no longer available – it seems all retailers have run down their stocks.  You might be lucky on eBay, but if you don’t own one already I recommend you find an alternative.

Finding more help

The NSLU2 community is at www.nslu2-linux.org, where there’s a LOT of information. However, it’s a community built on voluntary user contribution, so the information is sometimes incomplete, outdated, or otherwise inaccurate. There’s also a lot of information about the available packages out there on the Internet, but it doesn’t necessarily relate to the NSLU2 and often assumes you will be using packages that simply aren’t available to you.

The Unslung firmware is the first custom firmware that most users try. The binary download, which also contains all the information you need to get started, can be found at www.slug-firmware.net.

Getting the Unslung firmware up and running on my Slug was relatively easy. However, finding the information I needed to configure certain software packages proved more difficult, even though the actual installation of each package was quite simple.

In order to document my Slug’s configuration and to provide a reference point to others, I have created step-by-step NSLU2 instructions for the following tasks:

• Enabling SSH access
• Setting up an email server using Postfix and Dovecot
• Setting up an NTP server using ntp
• Setting up a print server using CUPS
• Configuring SSL and TLS for Postfix and Dovecot