Roo's View – Page 19 – A clever tagline should go here

Moving things along

I’m a terrible digital hoarder. I have email archives that reach back years. I have multiple copies of my digital photos. I even have at least partial copies of old machine installs going back years. Heck, it’s just bits and storage is cheap.

This translates a little bit into the physical world, but at least for this post I’ll focus on cool technology that I’ve bought and just can’t let go.

First up is the SLIM Devices Squeezebox. At the time this was a ~$400 device, and while I’d already digitized a lot of our music from CD to MP3 this opened up a novel way to explore our music collection.

The remote was useful, but where things really got neat was the web browser interface to the music server where you could queue up songs as you ‘discovered’ them. This was a neat audiophile device supporting digital out so you could connect this into your HiFi gear. There was even FLAC support if you wanted to go that path.

Sadly, two things made this device fail.

The company was acquired by Logitech and there were multiple reshuffles of the software / ecosystem. Newer devices came out, and the legacy stuff was left in the dust.
Streaming services became the new way to listen to music. The apps got really good and the friction between you and the music you wanted to hear was removed. Owning your music became less important to consuming music.

I can imagine a few futures where a device like this would survive if it had something like Plex supporting it. Today I still have my digital music collection, but it’s served up by Plex and we use the various Plex apps and supported devices to listen to it – including an Ikea Sonos speaker.

The second device is the Acer AspireOne. This was also around ~$400 when it came out, which was a ground breaking price point for a laptop. Sure this was a tiny 8.9″ screen, but it had everything we’ve come to assume a Chromebook can do. It was branded a Netbook, a category that died when Chromebooks came out.

For a while, this was used as Jenn’s primary device. It had access to email, could surf the web and even had a webcam and mic for recording video. (this was before we had ubiquitous video meeting software). It even supported local document editing via early versions of what we know as LibreOffice now.

It was replaced with a mac mini ages ago, which in turn was replaced.. I kept this little laptop around. The original software was a special Linux build that was really pretty horrible, but as this was just a standard intel based machine it would accept a lot of the usual Linux distros.

At one point I even managed to squeeze neverware onto this to make it into a very low end Chromebook. It worked, but was barely capable of doing some of the heavier web workloads that are pervasive on the modern web.

My primary use for this was a hackable Linux laptop that would let me do stuff like reconfigure routers. It’s built in ethernet jack was great for this and meant that I didn’t have to crawl behind my desktop machine to mess with the network. Sadly the battery on this gave up and it needs to be wall powered, limiting it’s usefulness in terms of portability.

I’ll miss having it, but I’ve since gotten my hands on a 14″ HP Chromebook that I unlocked and installed Linux on, specifically GalluimOS. This has become my go-to portable Linux hack machine. The battery on this isn’t great, but it’ll still run an hour or so. Plenty of time for my needs.

Well, farewell to these devices. I’m glad that they didn’t hit the landfill as I was able to sell them on Kijiji for a couple of bucks. The squeezebox went for $20, very quickly I’ll add. The netbook for $10, which for a working laptop is some unbelievable price apparently. While that is horrible depreciation, at least someone is going to use them for something which has value to me.

Managing docker containers with makefiles

Image by Jason Scott, licensed under CC-BY-2.0.

I’m very old school when it comes to managing my personal infrastructure. When I came across Jessie Frazelle‘s blog on her personal infrastructure I was inspired to adopt a makefile based approach. There are a couple of others who’ve written about similar approaches.

Here is a generic version of my makefile for containers which are built and hosted on one of the container repositories

#
# comment
# https://hub.docker.com/r/project/name
#
NAME = containername
REPO = project/name:latest
#
ROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))

# Create the container
build:
        docker create \
                --name=$(NAME) \
                -p 8000:3000 \
                -e VARIABLE=true \
                -v $(ROOT_DIR)/config/:/path/in/container/ \
                --restart=unless-stopped \
                $(REPO) 

# Start the container
start:
        docker start $(NAME)

# Update the container
update:
        docker pull $(REPO)
        - docker rm $(NAME)-old
        docker rename $(NAME) $(NAME)-old
        make build
        docker stop $(NAME)-old
        make start

# comment

# https://hub.docker.com/r/project/name

NAME = containername

REPO = project/name:latest

ROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))

# Create the container

build:

docker create \

--name=$(NAME) \

-p 8000:3000 \

-e VARIABLE=true \

-v $(ROOT_DIR)/config/:/path/in/container/ \

--restart=unless-stopped \

$(REPO)

# Start the container

start:

docker start $(NAME)

# Update the container

update:

docker pull $(REPO)

- docker rm $(NAME)-old

docker rename $(NAME) $(NAME)-old

make build

docker stop $(NAME)-old

make start

There are 3 targets: build, start, update. The update leaves the old container with a -old name. This is useful if you have to roll back to a previous version if for some reason the new container breaks. You could even create a rollback target that did this automatically.

Now, this is great if there is an existing container repository that has a container for you to pull, but things need to change if you are starting with a Dockerfile and building your own container.

#
# comment
# https://github.com/project/name
#
NAME = containername
#
ROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))

# Create the container
build:
        git pull
        docker build . --tag $(NAME)
        docker create \
                --name=$(NAME) \
                --restart=unless-stopped \
                $(NAME)

# Start the container
start:
        docker start $(NAME)

# Update the container
update:
        - docker rm $(NAME)-old
        docker rename $(NAME) $(NAME)-old
        make build
        docker stop $(NAME)-old
        make start

# comment

# https://github.com/project/name

NAME = containername

ROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))

# Create the container

build:

git pull

docker build . --tag $(NAME)

docker create \

--name=$(NAME) \

--restart=unless-stopped \

$(NAME)

# Start the container

start:

docker start $(NAME)

# Update the container

update:

- docker rm $(NAME)-old

docker rename $(NAME) $(NAME)-old

make build

docker stop $(NAME)-old

make start

Again, I’ve used the same build, start, update commands and have a built in assumption that the Makefile lives in the root of the git project. Instead of pulling from a container registry, we pull the latest from the git project and do a local build.

Having a very similar structure helps with consistency of managing my docker containers.

One day I would like to further enhance these makefiles to support checking for updates, be that a newer container build or git changes. Adding a post update check to ensure that the container has started would be very good too.

Installing docker-mailserver

Everyone should have their own domain name (or several). Having a website on your domain is easy and a sensible use of that domain name. Almost no one should run their own email server, it’s complicated and makes you responsible for all of the problems.

There are lots of providers out there that run email services and allow you to bring your own domain. ProtonMail would be a good choice, you can even bring your own custom domain and still use ProtonMail. Alternatives are offered by Google, and Microsoft if you want to go that route, both provide support for custom domains.

If you are still thinking of running your own mail server, then grab your tinfoil hat and let’s look at the best way to operate a mail server in the age of containers. I’ve run my own email for a long time, mostly following the Ubuntu setup. Using the docker-mailserver solves all of the email problems with a single container.

I will mention there are many alternatives: mailu, iredmail, etc. The docker-mailserver project stands out for me as they have avoided database based configuration and have stuck with ‘files on disk’ as the model.

This is a long overdue mail upgrade. I started doing this way back in 2017, but never really finished the work. The SSD rebuild disrupted how I was doing things, and changing email is a little scary. The hard drive that stores my email is very old. It is a Seagate Barracuda 40GB (ST340014A). The SMART information says that the Power Cycle Count is only 502, but the Power On Hours is an astounding 130442 (that is 14.89 years). Every stat is in pre-fail or old age, it is definitely time to move my email off that drive.

Before starting, take the time to read through the documentation. Once you think you’re ready to start installing thing the ReadMe is the right path to follow. I’m going a slightly different path than the recommended one which uses docker-compose, and will build out a basic docker deployment.

First I grabbed the following two files

wget https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/docker-compose.yml
wget https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/mailserver.env

1 2	wget https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/docker-compose.yml wget https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/mailserver.env

And the setup script for v10.0.0 as I intend to use the ‘stable’ version vs. ‘edge’. It is important to get the matching setup.sh script for the version you are deploying.

wget https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/v10.0.0/setup.sh
chmod a+x ./setup.sh

1 2	wget https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/v10.0.0/setup.sh chmod a+x ./setup.sh

I used the docker-compose.yml file to inform me how to configure my Makefile based docker approach. Most of the create options are a direct mimic of the compose file.

#
# email
# https://hub.docker.com/r/mailserver/docker-mailserver
#
NAME = mailserver
REPO = docker.io/mailserver/docker-mailserver:latest
#
ROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))

# Create the container
build:
        docker create \
                --name=$(NAME) \
                --hostname mail \
                --domainname lowtek.ca \
                -p 25:25 \
                -p 143:143 \
                -p 465:465 \
                -p 587:587 \
                -p 993:993 \
                -v /path/to/mail/maildata:/var/mail \
                -v /path/to/mail/mailstate:/var/mail-state \
                -v /path/to/mail/maillogs:/var/log/mail \
                -v /etc/localtime:/etc/localtime:ro \
                -v $(ROOT_DIR)/config/:/tmp/docker-mailserver/ \
                -v /path/to/etc/letsencrypt:/etc/letsencrypt \
                --env-file $(ROOT_DIR)/mailserver.env \
                --cap-add NET_ADMIN \
                --cap-add SYS_PTRACE \
                --restart=unless-stopped \
                $(REPO) 

# Start the container
start:
        docker start $(NAME)

# Update the container
update:
        docker pull $(REPO)
        - docker rm $(NAME)-old
        docker rename $(NAME) $(NAME)-old
        make build
        docker stop $(NAME)-old
        make start

# email

# https://hub.docker.com/r/mailserver/docker-mailserver

NAME = mailserver

REPO = docker.io/mailserver/docker-mailserver:latest

ROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))

# Create the container

build:

docker create \

--name=$(NAME) \

--hostname mail \

--domainname lowtek.ca \

-p 25:25 \

-p 143:143 \

-p 465:465 \

-p 587:587 \

-p 993:993 \

-v /path/to/mail/maildata:/var/mail \

-v /path/to/mail/mailstate:/var/mail-state \

-v /path/to/mail/maillogs:/var/log/mail \

-v /etc/localtime:/etc/localtime:ro \

-v $(ROOT_DIR)/config/:/tmp/docker-mailserver/ \

-v /path/to/etc/letsencrypt:/etc/letsencrypt \

--env-file $(ROOT_DIR)/mailserver.env \

--cap-add NET_ADMIN \

--cap-add SYS_PTRACE \

--restart=unless-stopped \

$(REPO)

# Start the container

start:

docker start $(NAME)

# Update the container

update:

docker pull $(REPO)

- docker rm $(NAME)-old

docker rename $(NAME) $(NAME)-old

make build

docker stop $(NAME)-old

make start

I walked through the mailserver.env file and made a few changes

ONE_DIR=1
I’m not totally sure about this, but the documentation reads: “consolidate all states into a single directory (/var/mail-state) to allow persistence using docker volumes.” which seems like a good idea.
ENABLE_CLAMAV=1
My existing email server uses ClamAV
ENABLE_FAIL2BAN=1
I’m a fan of fail2ban for protecting my server from abuse
ENABLE_SPAMASSASSIN=1
My existing email sever uses SpamAssassin

The volume pointing to letsencrypt is sort of a placeholder for now. Once we get things basically setup I will be changing the SSL_TYPE to enable encryption using my existing letsencrypt certificate that my webserver container has setup.

I later added the following additional configuration to enable logwatch.

LOGWATCH_INTERVAL=daily
Having an email centric logwatch email vs. combining it with my server logwatch, seemed like a good idea.
LOGWATCH_RECIPIENT=postmaster@lowtek.ca
Where to send the email.

With my Makefile based docker approach I have build, start and update targets. I can manually roll-back if needed as the previous container is has a -old name. The first step is to build the container.

make build

1	make build

At this point we are at the Get up and running section. We need to start the container and configure some email addresses.

make start

1	make start

Assuming all goes well, the mailserver container will be running. If we poke around the filesystem we’ll see a few files have been created

config/dovecot-quotas.cf
maillogs/clamav.log
maillogs/freshclam.log

We should be able to run the setup script and add a user, and configure some key aliases.

# Put a space in front of the command
# This will prevent the shell from logging your password
 ./setup.sh email add myemail@lowtek.ca SuperSecretPassword

./setup.sh alias add postmaster@lowtek.ca myemail@lowtek.ca

# Put a space in front of the command

# This will prevent the shell from logging your password

./setup.sh email add myemail@lowtek.ca SuperSecretPassword

./setup.sh alias add postmaster@lowtek.ca myemail@lowtek.ca

The creation of the account will cause some additional files to be created

config/postfix-accounts.cf
config/postfix-virtual.cf

At this point we have a running email server – but we need to start getting data to flow there. You may have to open ports in your firewall on the docker host to allow external traffic to connect to this new container.

This is very encouraging, but there is still a list of things I need to do

Create accounts and aliases
Configure smart host sending via AWS SES
Enable SSL_TYPE
Set up DKIM
Change the port forwarding to point to my container host
Migrate email using imapsync

The rest of this post is details on those steps

Continue reading “Installing docker-mailserver”