Turned out that auth.log was giving information:

Feb 14 08:35:06 zaphod afpd[9740]: twist Erlkoenig.gargleblaster.org to /bin/echo "You are not welcome to use afpd from Erlkoenig.gargleblaster.org."


Aha! this ringed a bell! I recently installed denyhosts, which uses hosts.allow.

A quick look in hosts.allow gave :


# The rest of the daemons are protected.
ALL : ALL \
: severity auth.info \
: twist /bin/echo "You are not welcome to use %d from %h."


So adding:

#netatalk
afpd: ALL: allow

Did the trick… netatalk is working as expected again.

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 :)

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

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

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 :)