I bought a new server last Friday, spent part of the weekend installing it and migrating all of my email/websites to it. Everything went pretty smoothly, but I did have one hiccup with my Postfix/Dovecot LDA setup. When trying to deliver a message, I would get this sequence in my maillogs:

Jun  9 12:39:10 www2 postfix/pipe[24300]: fatal: user= command-line attribute specifies mail system maildrop group id 126
Jun  9 12:39:11 www2 postfix/qmgr[24159]: warning: private/dovecot socket: malformed response
Jun  9 12:39:11 www2 postfix/qmgr[24159]: warning: transport dovecot failure -- see a previous warning/fatal/panic logfile record for the problem description
Jun  9 12:39:11 www2 postfix/master[13698]: warning: process /usr/local/libexec/postfix/pipe pid 24301 exit status 1
Jun  9 12:39:11 www2 postfix/master[13698]: warning: /usr/local/libexec/postfix/pipe: bad command startup -- throttling

At some point, postfix must have stopped allowing stuff to be sent through the 'pipe' command running as whatever you have in setgid_group. My dovecot line in master.cf previously looked like

dovecot   unix  -       n       n       -       -       pipe
  flags=DRhu user=dovecot:maildrop argv=/usr/local/libexec/dovecot/deliver -d ${recipient}

I fixed this by dropping the group:

dovecot   unix  -       n       n       -       -       pipe
  flags=DRhu user=dovecot argv=/usr/local/libexec/dovecot/deliver -d ${recipient}

Works fine.

In short, don't bother. Get something else.

Last weekend, we brought home a new puppy. I decided that it would be fun to connect a webcam to my laptop to keep an eye on him while I'm at work. I haven't used a webcam in years, and I have no idea what kinds of linux drivers exist. Some googling brought me to the gspca/spca5xx driver, which supports a ton of cameras. I compared items on this list to those available at CompUSA, and eventually decided to try the Microsoft LifeCam VX-3000. I felt strange buying a Microsoft product for a linux PC, but I figured all of these cameras are made by the same Taiwanese company and re-badged with a ton of different logos.

I got it home installed the gscpa drivers (available as an official debian package):

# apt-get install gspca-source
# module-assistant a-i -i -f gspca
# modprobe gspca

So far, so good. I checked dmesg and the device did show up. I started up canorama, a generic gui webcam app, only to find an ugly, garbled image:

Googling led me to some other users who had the same problem, but no solution. I tried viewing at the maximum resolution of 640x480. The image looked different, but still completely off:

I ended up returning it, and I bought a Logitech QuickCam Chat instead. The quality is pretty bad, possibly due to poor lighting, but at least now I can tell what I'm looking at.

Eventually, my plan is to stream the video over a web server. I'll probably post another article once I figure out how to do it!

Last night, after upgrading many of the packages on my mail server using FreeBSD's portupgrade tool, I found that I was no longer able to log in via IMAP. I noticed that the courier-authdaemon config files were all new, and that my old configs had been overwritten. After grabbing the old configs from backup and restarting courier-authdaemon, I was back in. That's good and everything, but I've been meaning to move away from courier, and this seemed like as good a time as any.

Recently, I've been using dovecot on new mail server installs, and I've been impressed so far. One feature I've found to be particularly useful is its local delivery agent, deliver. The LDA allows us to use quotas, mailbox indexing, and sieve plugin used for mail filtering and forwarding. I have several IMAP folders in my mailboxes, and I like to keep incoming mail sorted, so sieve will be very nice for this.

This article deals with migrating from courier to dovecot, but may also be useful for fresh installs.

Installation

First thing I did was installed dovecot from ports:

# cd /usr/ports/mail/dovecot
# make install

Since my postfix setup is using virtual users stored in MySQL, I need to check the MySQL support option when installing the Dovecot port. Just as the package message told me, I have to add a line to /etc/rc.conf to get it to start on boot:

# echo dovecot_enable="YES" >> /etc/rc.conf

Before I do anything else, I'm going to install the sieve plugin, which is also in ports:

# cd /usr/ports/mail/dovecot-sieve
# make install

Dovecot Configuration

Dovecot installed its sample configs to /usr/local/etc. I didn't have to make too many changes to the defaults, but here's :

ssl_cert_file = /etc/ssl/certs/mail.mydomain.com.crt
ssl_key_file = /etc/ssl/private/mail.mydomain.com.key

Here, I simply specified the path to my SSL certificate and private key. I already had one in place for webmail, so I just used those. If you don't have an SSL cert, be sure to set ssl_disable = no.

mail_location = maildir:/var/virtual/%u:INDEX=/var/virtual/%u/indexes

Here, I specify where my maildirs are. My users' maildir paths look like /var/virtual/user@domain.com/. The %u part is specified in the dovecot-sql.conf, which we will look at later.

first_valid_uid = 125

This needs to be set to the postfix user's uid, which can be found in /etc/passwd:

postfix:*:125:125:Postfix Mail System:/var/spool/postfix:/usr/sbin/nologin

protocol lda {
  debug = yes
  postmaster_address = postmaster@mydomain.com
  mail_plugins = cmusieve
  sendmail_path = /usr/sbin/sendmail
  auth_socket_path = /var/run/dovecot/auth-master
  log_path = /var/log/dovecot-deliver.log
  info_log_path = /var/log/dovecot-deliver.log
}

During the initial setup, debug = yes was useful for...well, debugging. postmaster_address is self-explanatory. mail_plugins = cmusieve loads the sieve plugin. Here, you can load other plugins, separted by spaces. So, if you wanted to load sieve and quota, set this to:

mail_plugins = cmusieve quota

I also added the log_path and info_log_path options, so deliveries wouldn't clutter my maillog.

Now, we need to set up a password database:

auth default {
  passdb sql {
        args = /usr/local/etc/dovecot-sql.conf
        master = yes
        pass = yes
  }
  userdb sql {
    args = /usr/local/etc/dovecot-sql.conf
  }
  socket listen {
    master {  
      path = /var/run/dovecot/auth-master
      mode = 0666
      user = postfix
      group = maildrop
    }
  }
}

The first two sections simply tell us that our users are stored in SQL, and that we have a separate config file that includes the necessary queries. If you don't have a sample config already, create the dovecot-sql.conf as stated above. Here's what mine looks like:

driver = mysql
connect = host=localhost dbname=postfix user=postfixuser password=p4ssw0rd
default_pass_scheme = CRYPT
user_query = SELECT CONCAT('/var/virtual/',maildir) as home, 125 AS uid,
 126 AS gid FROM mailbox WHERE username = '%u'
password_query = SELECT password FROM mailbox WHERE username = '%u' 
 AND active = '1'

The first two lines tells us that we're using mysql, and gives dovecot your database login information. The default_pass_scheme specifies the format in which your passwords are stored in the database. CRYPT works for most virtual mail setups I've worked with. The last two lines are the queries used to select the username, home directory, and password. My database doesn't contain a field with the full path to the user's maildir, only the directory name. I added the CONCAT('/var/virtual/',maildir) part to add the return the full path instead. You may need to add more to these queries if you are using quotas, or if your have a different table layout. Note that my queries above spill over to a second line on this page - they should not do this in the actual config file. The user_query and password_query should each be on their own line.

You can now start dovecot with:

# /usr/local/etc/rc.d/dovecot start

Since I already had courier running on port 143, I started dovecot on port 10143 for testing. I did this by setting:

   protocol imap {
     listen = *:10143
   }

in dovecot.conf. This way, I can test IMAP without things up for other users. LDA won't be working yet, since we still have to set that up in Postfix. We'll look at that next.

Postfix Setup

We now need to tell postfix to use dovecot to deliver messages. To do this, we need to add this to master.cf:

dovecot   unix  -       n       n       -       -       pipe
  flags=DRhu user=dovecot:maildrop argv=/usr/local/libexec/dovecot/deliver -d ${recipient}

To activate this, I changed the virtual_transport in main.cf:

#virtual_transport = virtual
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1

After restarting postfix with

# postfix reload

we should have dovecot handling message delivery. If your setup is anything like mine, it won't work perfectly right away. When sending a test message, I found this in /var/log/dovecot-deliver.log:

Fatal: setuid(125) failed: Operation not permitted

It seems that postfix cannot execute deliver as root. To fix this, I went into /usr/local/libexec/dovecot, and did:

# chmod 4755 deliver

to setuid root. You can confirm this with an ls -l:

-rwsr-xr-x  1 root  wheel  478260 Jun 27 11:11 deliver

After restarting postfix, all of my messages in queue were delivered. Once I confirmed that everything was working, I stopped courier and removed the package, and restarted dovecot to listen on port 143.

That should be it, there may be other issues I ran into that I forgot about - feel free to leave a comment if I missed anything.

For awhile now, I've been running an old Netscreen 10 appliance as a firewall and VPN gateway for my home network. It's not a bad device - it has 3 interfaces, supports site-to-site VPN tunnels, and "dial-up" VPN connections from a client. Unfortunately, I've ran into a few issues that have started to get more and more annoying - specifically, larger HTTP and FTP downloads from my linux PCs seem to time out after awhile. This has made updating my debian systems a lot more difficult than they need to be, so I started looking into some alternatives. Before I had the Netscreen in place, I was using a FreeBSD server running pf as my home network gateway. I never had any problems with this, so I figured I would go that route and use FreeBSD's IPSec implementation to set up my VPN to the office.

Kernel Compilation

IPSec is not supported in FreeBSD's default "GENERIC" kernel, so you'll have to compile a new one. This is pretty simple. First, make sure you have kernel sources installed and updated. If do not, you can do this with cvsup:

# cvsup /usr/share/examples/cvsup/stable-supfile

You may see the following error:

Unknown host "CHANGE_THIS.FreeBSD.org"

If so, open up stable-supfile in a text editor, and change the default host setting to something valid. cvsup.freebsd.org should work.

Once you have kernel sources, you can begin compiling a new one.

# cd /usr/src/sys/i386/conf

In a text editor, create a file for your new kernel config. Mine is simply called IPSEC:

include GENERIC
ident           IPSEC
options         IPSEC
options         IPSEC_ESP

This will take the entire GENERIC kernel config, and add the options IPSEC and IPSEC_ESP. The ident line will give your new kernel a name. Save it, and you can begin compiling:

# config MYKERNELNAME
# cd ../compile/IPSEC
# make cleandepend; make depend; make; make install
# reboot

After rebooting, you should be up and running in your IPSec kernel.

Racoon Setup

Racoon is the IKE daemon used to key your VPN connections. Install it from ports:

# cd /usr/ports/security/ipsec-tools
# make install clean

A sample config file will be installed to /usr/local/etc/racoon/. Here's the config I used, to connect from home to the office netscreen. The padding, listen and timer settings will be mostly unchanged from the sample config supplied by ports. The remote section refers to your phase 1 negotiations, which correspond to the VPNs -> Autokey Advanced -> Gateway settings on the Netscreen. The sainfo section refers to your phase 2 (VPNs -> Autokey IKE).

path pre_shared_key "/usr/local/etc/racoon/psk.txt";
log debug;
padding
{
        maximum_length 20;      # maximum padding length.
        randomize off;          # enable randomize length.
        strict_check off;       # enable strict check.
        exclusive_tail off;     # extract last one octet.
}
listen
{
        #isakmp ::1 [7000];
        #isakmp 202.249.11.124 [500];
        #admin [7002];          # administrative port for racoonctl.
        #strict_address;        # requires that all addresses must be bound.
}
timer
{
        # These value can be changed per remote node.
        counter 5;              # maximum trying count to send.
        interval 20 sec;        # maximum interval to resend.
        persend 1;              # the number of packets per send.
        # maximum time to wait for completing each phase.
        phase1 30 sec;
        phase2 30 sec;
}
remote OFFICE_NETSCREEN_PUBLIC_IP
{
        exchange_mode main;
        situation identity_only;
        my_identifier address;
        lifetime time 28800 seconds;
        nonce_size 16;
        initial_contact on;
        proposal_check obey;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
}
sainfo anonymous 
{
        lifetime time 3600 seconds;          
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate ;
}

The first line indicates that the preshared key is in /usr/local/etc/racoon/psk.txt. This file will contain one line, with the IP address of the remote gateway followed by the preshared key:

X.X.X.X abcd1234

This file must have read & write permissions only too root, or else racoon will refuse to read it:

# chmod 600 /usr/local/etc/racoon/psk.txt

You probably won't need to change anything in the remote section. The exchange_mode setting can be set to agressive, if you chose that in your Netscreen config. The proposal subsection needs to match the Netscreen's phase 1 proposal. Recall that on the Netscreen, I had chosen pre-g2-3des-sha. These correspond to the racoon settings as follows:

pre : authentication_method pre_shared_key;
g2 : dh_group 2;
3des : encryption_algorithm 3des;
sha : hash_algorithm sha1;


As you can see, this is pretty self-explanatory. The racoon.conf man page goes in to greater detail on the available options.

The sainfo section describes the phase 2 proposal. I chose nopfs-esp-3des-sha on the Netscreen, which translate to racoon as follows:

nopfs : (not needed for nopfs)
esp : (not needed in racoon.conf, will be set in ipsec.conf instead)
3des : encryption_algorithm 3des;
sha : authentication_algorithm hmac_sha1;

Note that if you chose g2 instead of nopfs here on the netscreen, you can set pfs_group 2; here in racoon.conf.

Once this is set, you will need to add racoon to /etc/rc.conf to make it start on boot up:

racoon_enable="YES"

and then start it up for the first time:

 
# /usr/local/etc/rc.d/racoon start

If there are any problems, racoon logs to /var/log/security by default, and you can usually see any problems there.

VPN Policy

We're almost done. Once racoon is up and running, we need to create a policy to specify which networks should be talking to each other. Open a new file /etc/ipsec.conf. Here's what mine looks like:

flush;
spdflush;
spdadd HOME_LAN_SUBNET OFFICE_LAN_SUBNET any -P out ipsec
 esp/tunnel/HOME_PUBLIC_IP-OFFICE_PUBLIC_IP/require;
spdadd OFFICE_LAN_SUBNET HOME_LAN_SUBNET any -P in ipsec
 esp/tunnel/OFFICE_PUBLIC_IP-HOME_PUBLIC_IP/require;

The HOME_LAN_SUBNET and OFFICE_LAN_SUBNET be in CIDR format ("slash" notation). For example, if my home network was 192.168.23.x, I would use 192.168.23.0/24. The HOME_PUBLIC_IP and OFFICE_PUBLIC_IP are the public IPs of your FreeBSD server and the office Netscreen.

To run this for the first time, do:

setkey -f /etc/ipsec.conf

You can enable this on startup by adding these lines to rc.conf:

ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"

Create gif Interface

Finally, you will need to create a virtual network interface for your VPN tunnel. There is a way to set your ipsec.conf in such a way that this step isn't required, but I found that the Netscreen always gave policy mismatch errors without it. To create the interface:

# ifconfig gif0 create
# ifconfig gif0 tunnel HOME_PUBLIC_IP OFFICE_PUBLIC_IP
# ifconfig gif0 inet HOME_PRIVATE_IP OFFICE_PRIVATE_IP netmask 0xffffffff

where HOME_PUBLIC_IP is your public IP, OFFICE_PUBLIC_IP is the Netscreen's public IP, HOME_PRIVATE_IP the inside IP of the server you are setting up, and OFFICE_PRIVATE_IP is the inside IP of the Netscreen. At this point, you should be able to ping the Netscreen's private IP. To reach the rest of the remote network, you will need to add a static route:

route add -net OFFICE_LAN_SUBNET OFFICE_PRIVATE_IP

Where OFFICE_LAN_SUBNET is your office network in CIDR format.
These steps can be added to rc.conf to be added on boot as well:

gif_interfaces="gif0"
gifconfig_gif0="HOME_PUBLIC_IP OFFICE_PUBLIC_IP"
ifconfig_gif0="inet HOME_PRIVATE_IP OFFICE_PRIVATE_IP netmask 0xffffffff"
static_routes="vpn"
route_vpn="OFFICE_LAN_SUBNET OFFICE_PRIVATE_IP netmask 0xffffff00"

That's it! Depending on your setup, you may need to add firewall rules to allow traffic from the remote network in. You will also need to make sure that UDP port 500 (isakmp) and protocol 50 (esp) are open to the remote gateway IP.