I've created a repository with Courier RPM packages built for CentOS 7 x86_64. The packages are compiled and signed automatically in a toolchain I have automated - but no particular reseach, tweaks or testing has been done to ensure that the packages are suitable for deployment. The packages were created because I want to work on Ajenti-V's Mail plugin and support my platform of choice for servers (CentOS) which doesn't currently have Courier packages available through repos (at least none of any repute).
For a couple of years since I started self-hosting my own email I've wanted to find a way to help other people do the same. After you put in a lot of work to understand the absolute ghetto that is the email-server enironment, it's not that hard and it gives you a lot of peace of mind. I've been looking at how I can start to clean up the ghetto and I even started writing my own mail server aimed at being as simple to configure and run as possible. That's a lot of work, especially with the lofty design goals I have, so I didn't get very far though I won't say I've quit just yet. For the moment I've decided that existing mail server software can be easily used and will siffice if work is put into creating documentation, identifying sane defaults and creating tools to guide administration in a self-hosting environment.
I found Ajenti and I think it's a promising framework for creating self-hosting solutions due to being designed for easy deployment and plugin development. Ajenti-V also already includes the ability to easily bring up a mail server with TLS, DKIM and SPF using Exim and Courier. Although I generally absolutely abhor control panels on servers I think that Ajenti isn't so bad as it doesn't meddle with configuration too much and it generally acts as a helper for configuration files, exposing the files in a text-editor most of the time, rather than munger for configuration files. People can see what is going on which is nice. Also, it isn't written in PHP.
It's early days and I don't want to fill up this post with too much irrelevant information but what I've done already is created an Ansible playbook to deploy Ajenti to CentOS and I hope to include some custom bits and pieces to give a fully functional, secure and spam-resistent setup with the least amount of effort. I also hope to push the majority of my changes upstream into Ajenti-V but I don't believe pushing everything upstream will be appropriate or even be accepted. Soon I hope to actually allow Ajenti to use Cyrus IMAPd rather than just Courier which will result in CalDAV and CardDAV capability and also JMAP in the future.
Courier isn't available from a CentOS repository so I created a signed package repository because the status-quo of running rpmbuild -ta courier-*.tar.bz2 is not good enough. It's great that Courier project has made building RPMs so easy but at the end of the day people shouldn't be compiling packages on theirservers.
To use the repository create the following file:
[DDEVnet] name = The DDEVnet repo baseurl = https://ddevnet.net/repo/centos/7/x86_64/RPMS/ gpgcheck = 1 # Optional below [DDEVnet-Source] name = The DDEVnet repo - source packages baseurl = https://ddevnet.net/repo/centos/7/SRPMS/ gpgcheck = 1 enabled = 0
Then import the public key used to sign the packges:
$ rpm --import https://ddevnet.net/repo/RPM-GPG-KEY-ddevnet # Key fingerprint = 8B0E E7E3 AB9A 4366 AED3 AC6A 0921 9327 6191 76A5)
Now you can install the folling courier packages:
courier courier-authlib courier-authlib-debuginfo courier-authlib-devel courier-authlib-ldap courier-authlib-mysql courier-authlib-pgsql courier-authlib-pipe courier-authlib-sqlite courier-authlib-userdb courier-debuginfo courier-fax courier-imapd courier-ldap courier-maildrop courier-maildrop-wrapper courier-mlm courier-mlm-web courier-mysql courier-pgsql courier-pop3d courier-unicode courier-unicode-debuginfo courier-unicode-devel courier-webadmin courier-webmail
If you have any problems with the packages or they need updating don't hesitate to let me know by email devine@[thisdomain].
Update: I have just found that Courier uses non-semantic versioning and inconsistent naming for their various components.
The components currently present in the repository are versioned correctly - sort of. Most Courier projects can have TWO different versions and also slightly different package names depending on whether the component was sourced from the all-in-one tarball or the standalone tarball. Yes - that makes no sense. The result is that packages which list Courier components as dependencies have two different (and conflicting) version numbers and package names. For example, there is the Courier IMAP server comes in two different packages one named courier-imapd of version 0.75 and another named courier-imap versioned 4.16.2.
To continue development of my project in the short-term I may just have the two different packages and versions in my repository at the same time, but I hope to be able to find the time soon to find out how to unify the packages and get this solution pushed upstream. A Google search has shown that the Ubuntu (though the solution may have been purloined from the Debian) seems to have sorted this problem out and perhaps I can copy this solution but in the RPM format (if appropriate).
Update 2: Fixing the non-semantic versioning problem might take a while... See this short mailing list thread for the reason why.Comments powered by Disqus