Gargleblaster.org

Mailman on freeBSD with Postfix

One of my co-workers asked me if I could help him with sending emails to over 100 people.
On certain planets this would be considered as spamming, but all the addresses are prospects or exisiting customers. Until now, he was used to send the mails one by one. But the address list grew larger and larger.

So time for me to enter the next step in mailserver-administration: Setting up a mailinglist.
In the early days of the net, I have been a co-adminstrator of a majordomo-list. But nowadays every list on the internet seems to be managed by Mailman. And since I don’t really dig perl, Mailman seemed an obvious choice.

Using ports, Mailman was very quickly installed. Some fiddling with apache-conf later and it seemed up and running.
However, making it run along side with the several virtual domains (in fact, even masquarading the FQDN of the mailserver to the mailing-domain) took some extra care.

But overriding these values in Mailman/mm_cfg.py seemed to work:

MTA = 'Postfix'
DEFAULT_EMAIL_HOST = 'domain.ex'
DEFAULT_URL_HOST = 'host.subnet.domain.ex'
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
DEFAULT_URL_PATTERN = 'http://%s/mailman/'
PUBLIC_ARCHIVE_URL = 'http://%(hostname)s/pipermail/%(listname)s'
POSTFIX_STYLE_VIRTUAL_DOMAINS = ['domain1.ex', 'domain2.ex']

And in /etc/postfix/main.cf:

owner_request_special = no
recipient_delimiter = +

# for making virtual domains work
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf, hash:/usr/local/mailman/data/virtual-mailman

#for making the obvious Mailman aliases work
alias_maps = mysql:/etc/postfix/mysql-aliases.cf, hash:/usr/local/mailman/data/aliases

After this ( and a good deal of coffee later) all seemed to work. Creating the lists, add some co-workers as testing guinee-pigs, everything seemed fine.

Created the list for external use, loaded 50+ emailaddresses and wrote up the announcement email.
clikckerdeclickerdie
“send”

not.
The maillog was flooded with “554 relaying not allowed” messages.
Lesson learned: configure and test your Mailman configuration with addresses outside your own domain.
Solution was to fiddle around with postfix relay options.

I changed it in /etc/postfix/main.cf to:

smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination

Make sure 127.0.0.1/8 belongs to mynetworks.

and tadaaa! A working mailinglist :)

Finally… sasl with virtual accounts in mysql working!

*sigh*
This bothered me from the moment I got my new postfix mailserver.
Everything worked…tls/amavisd-new/courier/plain-sasl/postfix all with mysql. But somehow I didn’t get sasl working with the virtual user accounts in mysql. I tried almost everything and nothing worked.
Once in a while I tried to get it working again, but every time it ended in a dissapointment.
Until today! Jippie!

The missing link turned out to be using the “-r ” option in saslauthd.sh.
From the saslauthd man pages:

     -r      Combine the realm with the login (with an '@' sign in between).
             e.g.  login: "foo" realm: "bar" will get passed as login:
             "foo@bar".  Note that the realm will still be passed, which may
             lead to unexpected behavior.

On freeBSD, add this to rc.conf:

saslauthd_flags="-r -a getpwent"

And in /usr/local/lib/sasl2/smtpd.conf:

sasl_pwcheck_method: auxprop
sasl_auxprop_plugin: sql
sql_engine: mysql
mech_list: login plain crammd6 digestmd5
sql_user: sql-user
sql_passwd: sql-pass
sql_database: postfix
sql_select: SELECT clear FROM postfix_users WHERE email = '%u@%r'
sql_verbose: yes

And don’t forget to restart the saslauthd after editing this file.

# saslauthd -v
saslauthd 2.1.21
authentication mechanisms: sasldb getpwent kerberos5 pam rimap

Entering the world of version control

Doing PHP development for several years now, I never really understood version control and how to integrate it with my web-application development. For “traditional” programming, it is clear. You create a repository, all the developers keep in sync and commit their updates. But being the whole development team yourself and have code that for 100% depends on the database stopped me from even try to set up a version control system.
Until last week. I just finished a project and was starting a new one, when I decided that this was the ideal moment for fiddling around with version control. I happened to have a golden oldie compaq proliant 1850R with RAID 5 disks AND a fresh install of freeBSD 5.4. Ideal for the task of becoming a CVS server….eh… cvs? subversion?

Being a total version control newbie, I did my googling and reading.
In one sentence: CVS is old and insecure, Subversion is hot and the talk of the town. CVS compares to Subversion as telnet to ssh.
And the fun thing? installing and setting up took me 1,5 hour. Using ports
there are basically two ports to install: Apache2 and Subversion.
Below are links to the pages I used for setting up my subversion server, but here are some hints/notes: (not a howto or tutorial! read the pages!)

Create a svn user and group, and adjust the umask of that user. I used: umask 002.

Build apache2 with WITH_BERKELEYDB=db42.
I have changed httpd.conf to have apache2 runs as svn user and group, this spares you from read/write issues when using Subversion with webdav.

Build Subversion with -DWITH_SVNSERVE_WRAPPER -DWITH_MOD_DAV_SVN.

Su -l to the SVN user, create the repository and import your initial project layout, confiure apache to serve the repository with webDAV and…you’re free to go!

It kicks ass!
I do my webdevelopment on my mac offcourse and I found svnX to be a fantastic client wrapper. 2, 3 hours after installing and setting up my first version control, I found myself wondering how I ever lived (eh..ok developed) without it.

The links I used:
onlamp - Setting up a Secure Subversion Server
the SVN book (free!)

macdev center- making the jump to subversion
onLamp - top ten tips for Subversion users
OS X Subversion client package (you need this for being able to use a gui front-end as svnX.
svnX
Versions Systems link collection

And because I always forget the exact procedure:
Apache+SSL on freeBSD

Recent addition is this article from RedHat, a introduction suited for both CVS users and those new to version control.

CVS is out, Subversion is in found with digg.com

Upgrading freeBSD

Keeping mission critical machines up2date is always a burden for a sysadmin.
Esp. if you are an allround sysadmin, responsible for all kind of servers.
On freeBSD, this has become quite easy.
There has is a new tool in town: portsnap.

Setup is easy. See this article on TaoSecurity.
After installing it boils down to this:

cd /usr/ports
portsnap fetch
portsnap update
make fetchindex
portsdb -u
portversion -v -l “<”
Check /usr/ports/UPDATING for information relating to my applications
portupgrade -varR

Total control :)