Back in 2004, I started experimenting with FreeBSD jails and CFEngine. I wrote this guide while I was setting up a machine- mail server, DNS, that sort of thing. Most of the complexity was around using OpenLDAP and Kerberos for authentication, and also configuration via CFEngine (a precursor to Chef or Puppet). This was all way overkill for a machine that had maybe 8 active users.

Even at the time I don't think this was the state of the art, and it's fallen way further behind. I really like the techniques of setting machines up via programming, though, and there are now more modern tools.

I've some housekeeping here, primarily updating the fomatting, and I've updated the links to http://archive.org where needed. I suspect the links will keep rotting. It's roughly in the same shape as it was when I stoped working on it around August 13, 2004.

If you follow this, hopefully you'll end up with a circa-2003 FreeBSD machine fully set up. Seems like you'll have a pretty complicated LDAP system, maybe a mail server (with webmail!). Very usable! Don't put it on the internet, I'm sure there are vulnerabilities that've been fixed in the years since then.

Introduction

The start of my FreeBSD project computer; documented here so you won't have to live through the pain that I did.

The docs were produced using TeX; my first time using that, too^[1]. So bear with the awful formatting, and feel free to email me with comments.

FreeBSD actually has a pretty great docs itself; the http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html in particular was invaluable to me.

Installation

The FreeBSD handbook has much more information on this. Boot off of a CD (at least, this is what I do).

I use the Standard installation type; it's fairly fast.

When asked how to partition, just use 'a' if this is a dedicated hard drive. This lets FreeBSD use a single large actual partition, which it will carve up into smaller chunks later on. Later, you'll be prompted to create slices within those partitions; this is where FreeBSD does what under most other OSs would be partitions (/, /usr, /var, etc).

Install the base, crypto, man, src (and then all of the sub-packages of src), ports, and perl distributions. This gives you a good base to create a server from.

Post-Installation

Upgrading from CVS

First, the cvsup system needs to be setup.

There are advantages and disadvantages to having this setup; but it's probably best to just do it at this point.

We'll build the old versions, for the sake of simplicity. Remember to set the FTP_PASSIVE_MODE environment variable.

uip# setenv FTP_PASSIVE_MODE 1
uip# cd /usr/ports/net/cvsup-without-gui/
uip# make install clean

Next, make some supfiles. You'll need 2; one for src, and one for ports (they need different tags).

For ports, I use /usr/local/etc/cvsup/supfile.src:

*default tag=RELENG_5_2
*default host=cvsup4.us.FreeBSD.org
*default prefix=/usr
*default base=/usr/local/etc/cvsup
*default release=cvs delete use-rel-suffix compress

src-all

And for ports (/usr/local/etc/cvsup/supfile.ports):

*default tag=.
*default host=cvsup4.us.FreeBSD.org
*default prefix=/usr
*default base=/usr/local/etc/cvsup
*default release=cvs delete use-rel-suffix compress

ports-all

And a refuse file, so you don't accidentally pull a bunch of crap (/usr/local/etc/cvsup/sup/refuse):

ports/astro
ports/audio
ports/benckmarks
ports/biology
ports/cad
ports/finance
ports/graphics
ports/java
ports/math
ports/mbone
ports/multimedia
ports/palm
ports/picobsd
ports/print
ports/science
ports/x11*

ports/arabic
ports/chinese
ports/french
ports/german
ports/hebrew
ports/hungarian
ports/japanese
ports/korean
ports/polish
ports/portuguese
ports/russian
ports/ukrainian
ports/vietnamese
doc/da_*
doc/de_*
doc/el_*
doc/es_*
doc/fr_*
doc/it_*
doc/ja_*
doc/nl_*
doc/no_*
doc/pl_*
doc/pt_*
doc/ru_*
doc/sr_*
doc/zh_*

Then, do the cvsup:

uip# cvsup /usr/local/etc/cvsup/supfile.ports && \
cvsup /usr/local/etc/cvsup/supfile.src

Updating Everything

Odds are, your system is vulnerable to a few things -- with a vanilla 5.2.1 install, there're several holes^[2]. Fastest (at least, maybe easiest) is to update everything.

Add your information to /etc/make.conf. Here's what I set up. I used to include NO_SENDMAIL=true, but I found that you'll want sendmail at least in a sending-only capacity on most systems, even though I don't recommend using it as a mail server (for that, I'd use Postfix).

# -- use.perl generated deltas -- #
# Created: Sat Aug 14 02:46:22 2004
# Setting to use base perl from ports:
PERL_VER=5.6.1
PERL_VERSION=5.6.1
PERL_ARCH=mach
NOPERL=yo
NO_PERL=yo
NO_PERL_WRAPPER=yo

# small generated
CPUTYPE?=i686

# control what to build
NO_FORTRAN=true
NO_I4B=true
NO_X=true
NO_PROFILE=true

Create a new kernel configuration, if needed. If not, just go with the default. For more information, see my version here: kernel-config-small. Note that the final copy has to exist (either as a file or a symlink) in /usr/src/sys/i386/conf. I recommend creating the file in root's home directory (for ease of backup), then creating the symlink in /usr/src/sys/i386/conf.

Run mergemaster, to update any configuration files required by the makeworld (from /usr/src):

uip# mergemaster -p

And build the system, and install the kernel. Doing this in single-user mode may speed up your compiles, but at the price of doing nothing else while you're compiling. See below for more info on single-user mode.

# cd /usr/src
# make -j4 buildworld
# make buildkernel KERNCONF=CUSTOM
# make installkernel KERNCONF=CUSTOM
# reboot

Next, install the newly compiled system. This should also be done in single-user mode (to enter single-user mode, run shutdown now). touch: not found errors may be related to the system clock being off; to correct them, reset the system clock to the correct time and start the build process over.

# cd /usr/src
# make installworld
# mergemaster

Installing Ports

Pretty simple, FreeBSD's docs are much better than mine will be on this. Here's how to install CFEngine, a configuration management system which we'll use to simplify the management of all the different jails.

# cd /usr/ports/sysutils/cfengine2
# make install

This will automatically grab all the dependencies, as well.

Sometimes, you may have an out of date package that you need to install anyways (for instance, if the patch hasn't been released yet, but it's a dependency for something else). You can avoid vulnerability fatal errors by setting the environment variable DISABLE_VULNERABILITIES to yes.

Upgrading Ports

Install the portsupgrade package. To really use it, you'll need an empty refuse file (so you get all the files).

After a cvsup with ports (see above), run portsdb -Uu to update the portsupgrade database. To upgrade all out-of-date packages, use portupgrade -aRr to upgrade all packages (all, recurse both upwards and downwards).

If prompted, you may need to run pkgdb -F to refresh the package databaes. It will prompt you for packages, along with best guesses as to which packages fulfill the dependencies.

Jails

Jails allow a single physical machine to be separated into multiple virtual machines; similar in theory to how a mainframe can have multiple virtual hosts running at any given time. Unlike the mainframes, all the FreeBSD jails will be running under the same FreeBSD kernel.

Note that these steps depend somewhat on stages above; you'll need to install ports, and you must have world already built.

Installing Jails

Basically, from the jail(8) man page, with some small modifications to avoid building world again (since we've just done it above):

host# D=/here/is/the/jail
host# cd /usr/src
host# mkdir -p $D
host# make installworld DESTDIR=$D
host# cd etc
host# make distribution DESTDIR=$D
host# mount_devfs devfs $D/dev
host# cd $D
host# ln -sf dev/null kernel

To install ports inside of a jail, the fastest way is to mount the /usr/ports directory from the host system over a null mount, and then compile and install from there. This will keep the systems entirely separate.

host# mount_nullfs /usr/ports /path/to/jail/usr/ports

Then, from within the jail:

jail# cd /usr/ports/sysutils/cfengine2
jail# make install

If nothing happens, you may need to do a make clean before the install will work.

Setting up syslogd for Jails

There are two different strategies for dealing with system logs from inside of the jailed environment. The first is to use the host system's syslogd to listen in on /usr/jails/*/dev/log, using one syslogd process to listen in on all hosts. The second is to run a single syslogd process in each host, and have them log to a single loghost.

I've chosen the second, as the separation seems to be more in the spirit of jails.

To do this, each jail must have its own syslogd running (as it is by default), and the syslog.conf must point the logs at the remote loghost. For example, see this syslog.conf:

*.*                                             @loghost

This syslog.conf can be distributed as-is to all the concerned hosts, except for the loghost. The loghost should have something closer to this:

*.err;kern.debug;auth.notice;mail.crit          /dev/console
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err   /var/log/messages
security.*                                      /var/log/security
auth.info;authpriv.info                         /var/log/auth.log
mail.info                                       /var/log/maillog
lpr.info                                        /var/log/lpd-errs
ftp.info                                        /var/log/xferlog
cron.*                                          /var/log/cron
*.=debug                                        /var/log/debug.log
*.emerg                                         *

Upgrading Jails

I got information on this procedure from this page: http://memberwebs.com/nielsen/freebsd/jails/docs/jail_upgrade.html.

In a nutshell, though:

host# JAIL=/jails/thejail.com
host# cd /usr/src && \
make installworld DESTDIR=$JAIL &&
mergemaster -i -C -D $JAIL

Starting Jails

Very simple; see the man page for more information. To do it manually, just start the rc process from the host:

host$ jail JAILNAME

And there's an rc.conf script that'll let you start the jails more easily (and on boot). Add lines like these to rc.conf (these are to configure jails named elsie, nice, and loche):

ifconfig_dc0_alias0="inet 10.0.1.1/32"
ifconfig_dc0_alias1="inet 10.0.1.2/32"
ifconfig_dc0_alias2="inet 10.0.1.3/32"

jail_enable="YES"
jail_set_hostname_allow="NO"
jail_list="elsie nice loche"

jail_elsie_hostname="elsie.uip.swapspace.net" 
jail_elsie_ip="10.0.1.1"
jail_elsie_rootdir="/usr/jails/elsie"
jail_elsie_devfs_enable="YES"
jail_elsie_procfs_enable="YES"
jail_elsie_exec="/bin/sh /etc/rc"

jail_nice_hostname="nice.uip.swapspace.net"
jail_nice_ip="10.0.1.2"
jail_nice_rootdir="/usr/jails/nice"
jail_nice_devfs_enable="YES"
jail_nice_procfs_enable="YES"
jail_nice_exec="/bin/sh /etc/rc"

jail_loche_hostname="loche.uip.swapspace.net"
jail_loche_ip="10.0.1.3"
jail_loche_rootdir="/usr/jails/loche"
jail_loche_devfs_enable="YES"
jail_loche_procfs_enable="YES"
jail_loche_exec="/bin/sh /etc/rc"

LDAP

Using LDAP for authentication will (hopefully) make the several systems you're building here easier to administrate^[3], while at the same time padding your resume with some useless information. This is basically totally overkill for a jailed system like this, maybe if you had some workstations it would make a bit more sense.

Much of these instructions are taken from: http://www.cultdeadsheep.org/FreeBSD/docs/Quick_and_dirty_FreeBSD_5_x_and_nss_ldap_mini-HOWTO.html We'll build beyond that, ensuring that all communications are properly secured.

LDAP Server Setup

This shold prepare you for actually performing authentication against OpenLDAP. I got a lot of this information from various sources:

• http://www.openldap.org/lists/openldap-software/200010/msg00097.html
• http://www.faqs.org/rfcs/rfc2253.html (RFC 2253)

For reference, a brief list of the LDAP abbreviations, used extensively in these configuration steps:

Server Compilation

Note that since we want the server to also function as a client, we install both the server and the client NSS and PAM modules.

ldap_server# cd /usr/ports/net/openldap22-sasl-server
ldap_server# make install clean
ldap_client# cd /usr/ports/net/nss_ldap
ldap_client# make install clean
ldap_client# cd /usr/ports/security/pam_ldap
ldap_client# make install clean

slapd Configuration

The OpenLDAP daemon, slapd, needs to have its configuration setup before you can proceed. This will specify the root user, information on permissions (eventually), etc. The version below is very basic, and contains no ACL information or anything else, but it should be enough to begin adding user information. The file, by default on FreeBSD, lives in /usr/local/etc/openldap/slapd.conf.

Use slappasswd(8c) to generate the rootpw entry.

include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema
include         /usr/local/etc/openldap/schema/nis.schema

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

database        bdb
suffix          "dc=splendous,dc=net"
rootdn          "cn=Manager,dc=splendous,dc=net"
rootpw          {SSHA}...
directory       /var/db/openldap-data

# Indices to maintain
index   objectClass     eq
index   uid             pres,eq,sub

OU information

The LDAP database needs to be initialized with some OU information; this gives you "directories" to store your users and groups in. You can think of the people OU (the second paragraph below) as the /etc/passwd file, and the paragraph after that (the group OU) as the /etc/group file.

dn: dc=splendous, dc=net
objectClass: top
objectClass: dcObject
objectClass: organization
dc: splendous
o: splendous.net
description: splendous.net

dn: ou=people, dc=splendous, dc=net
objectClass: top
objectClass: organizationalUnit
ou: people
description: splendous.net people

dn: ou=group, dc=splendous, dc=net
objectClass: top
objectClass: organizationalUnit
ou: group
description: splendous.net groups

Put that information in a text file (init.ldif is what I used), and execute a command like this to read it into your LDAP database:

ldap_server# /usr/local/bin/ldapadd -f init.ldif -D "cn=Manager, dc=splendous, dc=net" -w manpass

Adding Users

Again, make an LDIF file with the user information (as in this example):

dn: cn=Your User,ou=people,dc=splendous,dc=net
uid: yuser
cn: Your User
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {SSHA}C5mXR4Y341F2RkQ74F5HrnvDJnHJv82s
shadowLastChange: 11226
shadowMax: 99999
shadowWarning: 7
shadowFlag: 134538484
loginShell: /bin/tcsh
uidNumber: 10000
gidNumber: 100
homeDirectory: /home/yuser
gecos: Your User

Adding Groups

More LDIF files:

dn: cn=users, ou=group, dc=splendous, dc=net
objectclass: top
objectclass: posixGroup
cn: users
gidnumber: 100

To add more users to the users group created above, add (for example) memberuid: yuser elements to the LDIF file. More likely, you'll be adding elements later, and then you use ldapmodify as follows:

TODO

Changing Passwords

Use slappasswd to generate a new password hash:

> slappasswd -h '{SSHA}'
New password: 
Re-enter new password: 
{SSHA}X

And create a temporary LDIF file with this information, like this (I named this file mypasswd.ldif, but it just has to match the next step):

dn: cn=Your User,ou=people,dc=splendous,dc=net
userPassword: {SSHA}X

Last, import this LDIF into the LDAP database. This can be done as the user, using the user's password (no Manager credentials are needed).

> ldapmodify -W -D "cn=Your User,ou=people,dc=splendous,dc=net" -H ldap://ldap.uip.splendous.net -f mypasswd.ldif -x
Enter LDAP Password: 
modifying entry "cn=Your User,ou=people,dc=splendous,dc=net"

LDAP Client Setup

Client Compilation

Install the port, pretty basic.

ldap_client# cd /usr/ports/net/openldap22-sasl-client
ldap_client# make install clean
ldap_client# cd /usr/ports/net/nss_ldap
ldap_client# make install clean
ldap_client# cd /usr/ports/security/pam_ldap
ldap_client# make install clean

Client Configuration

You'll need to configure a few files. The first ones, ldap.conf and ldap.secret, are only interim versions. We'll address more secure versions further down, as part of securing the LDAP installation. Mostly, we're binding (for all features) as the Manager, with root permissions; this couldn't be a worse idea.

This file, ldap.conf, configures the main interface from LDAP client libraries (such as PAM) into the LDAP database:

uri ldap://elsie.uip.swapspace.net
base dc=splendous,dc=net
ldap_version 3
rootbinddn cn=Manager,dc=splendous,dc=net
nss_base_passwd         ou=people,dc=splendous,dc=net?one
nss_base_shadow         ou=people,dc=splendous,dc=net?one
nss_base_group          ou=group,dc=splendous,dc=net?one

ldap.secret contains the password, corresponding with the rootbinddn parameter in the ldap.conf (above); just one line, only the password. Make sure this file has 0600 permissions; you don't want everyone running off with this password, no matter which account it goes to.

manpass

We'll also need links to these files for the NSS interface to work properly. The NSS LDAP interface expects the same files, with an 'nss_' prefix, as so:

> ls -al nss*
lrwxr-xr-x  1 root  wheel     9 Aug  9 20:26 nss_ldap.conf -> ./ldap.conf
lrwxr-xr-x  1 root  wheel    13 Aug 13 00:15 nss_ldap.secret -> ./ldap.secret

NSS Configuration

For NSS^[4] to work, the /etc/nsswitch.conf file must be configured. This is a recent addition to FreeBSD (within the 5.x development series; 5.2.1 stable may also contain it). Support is still limited, without the full range of functionality of other operating systems.

passwd: files ldap
shadow: files ldap
group: files ldap

PAM Configuration

PAM authentication will usually bubble down into NSS. However, the SSH PAM file does need to be changed. The changes from the default are minor; pretty much adding a pair of LDAP authentication lines. Here's my version of /etc/pam.d/sshd:

#
# $FreeBSD: src/etc/pam.d/sshd,v 1.15 2003/04/30 21:57:54 markm Exp $
#
# PAM configuration for the "sshd" service
#

# auth
auth            required        pam_nologin.so          no_warn
auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
auth            sufficient      pam_ldap.so             no_warn try_first_pass
auth            required        pam_unix.so             no_warn try_first_pass

# account
account         sufficient      pam_ldap.so
account         required        pam_login_access.so
account         required        pam_unix.so

# session
session         required        pam_permit.so

# password
password        required        pam_unix.so             no_warn try_first_pass

For sudo(1), an /etc/pam.d/sudo file like this will allow access while requiring a password:

passwd(1) compatibility

Unfortunately, FreeBSD's passwd(1) program doesn't actually use PAM to change passwords (despite the presence of an /etc/pam.d/passwd file). See http://www.freebsd.org/cgi/query-pr.cgi?pr=59638 for more information^[5].

To work around this,... TODO

su(1) Compatibility - sudo(1)

The su(1) program also doesn't seem to work with LDAP; at least, I couldn't make it work. So, use the (better) alternative, sudo. Install the port via the normal process, from above.

Make sure the port install has PAM compiled in, and create an /etc/pam.d/sudo file:

#
# PAM configuration for the "sudo" service
#

# auth
auth            required        pam_ldap.so             debug

Create a special group (similar to FreeBSD's wheel; I called mine lwheel) to place privileged users in. Then, you can create a /usr/local/etc/sudoers file similar to this one; this will allow only users in the lwheel group to execute with heightened privs.

# User privilege specification
root    ALL=(ALL) ALL

# Uncomment to allow people in group lwheel to run all commands
%lwheel         ALL=(ALL)       ALL

General OpenLDAP use

You can dump your LDAP database to stdout (in LDIF format) using slapcat(8c):

ldap_server# slapcat
...

LDAP Security

Storing all authentication in LDAP raises security just as it questions it.

SASL2

Doing any strong encryption through OpenLDAP depends on having the SASL library installed and configured. This lets you plug other security mechanisms (including GSSAPI) into OpenLDAP.

Installing SASL

At least for FreeBSD, the installation is relatively straight-forward. Just install the openldap-sasl-{server,client} instead of the regular versions.

saslpasswd2 -u splendous.net -c admin

TLS

CA Generation

Odds are, you'll be generating your own certificates, and signing them as well^[6]. You'll need OpenSSL for this (fortunately, most distributions come with that built in).

Turning Off Local Accounts

The last big step to this is turning off all the local accounts on all the jails. You should only have a few; your user account (you have been using one, right?) and root.

BIND

Setting up BIND is straight-forward, and is very comparable to the same process in different OSs. I use BIND v9, so these steps cover that.

Basically, install the port (within a jail, if you're doing that), configure it (see the docs from ISC or included with the port), and you're done. The rc.conf configuration (the only tricky bit for me) goes like this:

named_program="/usr/local/sbin/named"
named_enable="YES"
named_flags="-c /var/named/named.conf"

Mail

Mail, as we'll be using it, depends on a successful installation of LDAP. This will let us put a mail server in a jailed system with no local user accounts; the mail server will authenticate entirely over LDAP.

Postfix Compilation

Enter the postfix port (/usr/ports/mail/postfix), and make install. This will prompt you for the options to compile with; pick OpenLDAP, SSL and TLS, and SASL2.

Postfix Configuration

Replace Sendmail

The Postfix post-installation walks you through this, but here's a shortened version that may help.

Configure your /etc/mail/mailer.conf to look like this; this file tells FreeBSD what to use for its actual mail binaries:

#
# Execute the Postfix sendmail program, named /usr/local/sbin/sendmail
#
sendmail        /usr/local/sbin/sendmail
send-mail       /usr/local/sbin/sendmail
mailq           /usr/local/sbin/sendmail
newaliases      /usr/local/sbin/sendmail

And enter these lines to /etc/rc.conf, which will use the mailer.conf configuration to actually start Postfix:

# with the /etc/mailer.conf changes, this'll actually start postfix
sendmail_enable="YES"
sendmail_flags="-bd"
sendmail_pidfile="/var/spool/postfix/pid/master.pid"
sendmail_outbound_enable="NO"
sendmail_submit_enable="NO"
sendmail_msp_queue_enable="NO"

Lastly, we can turn off some periodic jobs that Sendmail requires, but Postfix does automatically. Adding the following lines to /etc/periodic.conf will take care of it (create the file if it doesn't exist).

daily_clean_hoststat_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_include_submit_mailq="NO"
daily_submit_queuerun="NO"

LDAP User Lookups

To enable LDAP user lookups in Postfix, enter (in your main.cf):

local_recipient_maps = ldap:/usr/local/etc/postfix/ldap-local.cf

And create a file /usr/local/etc/postfix/ldap-local.cf:

server_host = ldap.uip.splendous.net
search_base = ou=people, dc=splendous, dc=net
query_filter = (uid=%u)
result_attribute = uid

bind = no
version = 3

You can also use LDAP to create user aliases; since I won't be having too many of those, at least not yet, I haven't done so. The documentation from Postfix is focused on this, so that should get you started.

Courier-IMAP

Compilation

Simple; just compile the port, but use the WITH_LDAP=yes flag to the make install process.

Configuration

The DEBUG_LOGIN parameter was extremely useful for getting these initially working.

I was able to use the defaults for the /usr/local/etc/courier-imap/imapd-ssl file; this file defines the standard configuration.

The essential part is the authentication procuderes; you'll need to create a /usr/local/etc/courier-imap/authdaemonrc and /usr/local/etc/courier-imap/authldaprc files; the first defines the order of the authentication methods (in our case, we only want to allow authentication through LDAP). To define this, we change this single line in the file (leaving the rest alone):

authmodulelist="authldap"

The second file, /usr/local/etc/courier-imap/authldaprc, actually defines the LDAP authentication. My configuration follows (comment lines and blanks omitted for brevity, but you should maintain the overall state of the file, as Courier seems to use some comment sections internally). The LDAP_AUTHBIND parameter turned out to be essential for my success, but your situation may seem different.

LDAP_SERVER             ldap.uip.splendous.net
LDAP_PORT               389
LDAP_PROTOCOL_VERSION   3
LDAP_BASEDN             ou=people,dc=splendous,dc=net
LDAP_TIMEOUT            5
LDAP_AUTHBIND           1
LDAP_MAIL               uid
LDAP_HOMEDIR            homeDirectory
LDAP_FULLNAME           cn
LDAP_CRYPTPW            userPassword
LDAP_UID                uidNumber
LDAP_GID                gidNumber
LDAP_DEREF              never
LDAP_TLS                0

Startup

The Courier IMAP port currently doesn't come with standard rc.d scripts; instead, it uses the old style scripts. To enable their use, create symlinks of the form *.sh to /usr/local/libexec/courier-imap/imapd-ssl.rc or /usr/local/libexec/courier-imap/imapd.rc (or both), and define a line like the following in your /etc/rc.conf:

local_startup="/usr/local/etc/rc.d"

This line tells the system to execute all files matching the above pattern from /usr/local/etc/rc.d with a single start argument.

Squirrelmail

Compilation

Note that to enable TLS support, you need PHP to have OpenSSL enabled. The FreeBSD PHP port doesn't have this by default; adding lines like these to your /usr/ports/lang/php4/Makefile will allow you to use make install WITH_SSL=yes to enable OpenSSL support:

.if defined(WITH_SSL)
CONFIGURE_ARGS+=--with-openssl
.endif

This requirement will vanish with PHP 5, where the OpenSSL module can be compiled dynamically into place.

Configuration

The one file to put in an automated config system is config/config.php; it contains all the configuration put into place.

You can use sasldb2 for authentication, to add users use:

        saslpasswd2 -c username

If you want to enable SMTP AUTH with the system Sendmail, read
Sendmail.README

NOTE: This port has been compiled with a default pwcheck_method of
      auxprop.  If you want to authenticate your user by /etc/passwd,
      PAM or LDAP, install ports/security/cyrus-sasl2-saslauthd and
      set sasl_pwcheck_method to saslauthd after installing the
      Cyrus-IMAPd 2.X port.  You should also check the
      /usr/local/lib/sasl2/*.conf files for the correct
      pwcheck_method.
      
      
daily_clean_hoststat_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_include_submit_mailq="NO"
daily_submit_queuerun="NO"


If you are using SASL, you need to make sure that postfix has access to read
the sasldb file.  This is accomplished by adding postfix to group mail and
making the /usr/local/etc/sasldb* file(s) readable by group mail (this should
be the default for new installs).

Upkeep

User Creation

With all that's been said about creating the user through LDAP, there are a few more things to consider.

On the mail server, you must create the user's home directory (if this isn't done automatically), or Postfix will be unable to deliver their mail to them.

And That Was It

It trails off. But if you've done all this, your terribly out of date machine is ready to go.

If you've actually done this, I think Kerberos for SSO would be cool.