home :: admin

Setting up a new e-mail server with more disk space

(done on June 2nd 2024)

Our family's e-mail server on DigitalOcean was running out of disk space, so I created a new droplet with FreeBSD 14.0 on it, allocating more disk space (50GB) and a bit more RAM (2MB), and then proceeded to moving our environment onto it.

Here's what I've done:

1) booted up the new droplet and ensured it had the latest patches to FreeBSD (with freebsd-update) and its packages (with pkg upgrade).

2) Create my account and enable sudo

Create my user with adduser, ensuring the right UID and GID, make sure the account is part of the wheel group, and enable sudo for the wheel group in /usr/local/etc/sudoers

3) Copied over the /etc/hosts.allow file from the previous mail server

4) Installed the packages I like to have on the new server:

dovecot, emacs-nox, mutt, mini-httpd, opensmtpd, perl5, python39, rsync, sshguard, sudo, unbound, zip, py39-certbot

5) Fixed /etc/rc.conf

Notably the hostname and all of the deamon activations. Most are disabled for now until their configuration files are set up properly.

6) Copy over the rsyncd configuration

Copy over /usr/local/etc/rsyncd/... so that we can move some files from the old server to the new, preserving ownership, dates, etc.

7) Bring over key /root files

Set up the files I need in /root: my-backup.sh, my-backup.pw, and crontab.root. Then run the crontab command on the root account to activate the crontab.root file.

8) Copy over all accounts

Merge /etc/master.passwd, /etc/passwd and /etc/group into the files on the new server

9) Copy over users' files

Replicate /home/... and /var/mail/...

10) Copy over web environment

Copy over /usr/local/www/...

11) Copy and adjust configuration files for dovecot

Move the configuration files in /usr/local/etc/dovecot over and adjust for new server name.

12) Copy and adjust configuration files for letsencrypt

Move the configuration files in /usr/local/etc/letsencrypt over and adjust for new server name (renaming directory and fixing renewal config file)

13) Copy and adjust configuration files for OpenSMTPd

Move the configuration files in /usr/local/etc/mail over and adjust for new server name.

14) Configure sshguard on new server

Edit configuration files for sshguard in /usr/local/etc to reflect new configuration.

15) Configure unbound on the new server

Copy over the relevant files from /usr/local/etc/unbound and adjust them for the new server name as required.

16) Fix files in /etc

Notably files in /etc/mail (mailer.conf, aliases, rc.conf, ntp.conf)

17) Fix DNS entries on DigitalOcean so that our domain now points to the new server

Put in the new IP address.

18) Set up let's encrypt properly

Seems to work... perhaps need to add atlantic to the certificate names?

19) Ensure latest version of e-mail has been copied over

Shutdown the OpenSMTPd service on ocean.zap.qc.ca, sync the users' e-mail files in /var/mail, redirect the DNS to atlantic, and turn off ocean.

Note that any e-mail in transit on ocean will be lost (yeah, I could do this more cleanly).

Note that DMARC and SPF DNS entries need to be fixed, and the lets-encrypt key files too!!!

20) Redirect e-mail filtering on duocircle.com to the new server

Change the address in the DuoCircle configuration screen to point to the new server.

21) Finish up

with all of that, the new mail server should be active and working. Send a Discord message to all users to ask them to check that their e-mail configuration still works.

If something goes wrong, re-enable the old server.

If all goes well, mothball the old server's files and destroy the droplet on DigitalOcean.

That was quite a bit of work, glad it's done!

P.S. It all worked fine, but I realized months later that the rsyncd setup for my blog transfer didn't work anymore -- fixed that on December 27th

/admin | Posted at 06:17 | permanent link

Big changes

eBox e-mailed me tonight to let me know that my new vCable 400 Internet connection had been activated.

So after watching the hockey game on TV, I connected my new technicolor TC4400-AM modem onto the coax cable with my old Videotron modem used to me connected, and within a few minutes my new internet connection was indeed up and running.

So after checking that everything was up and running properly, I ran the olde Ookla speed test to see if the speed was as advertized.

Whoa! I now get 454 Mbps download and 56 Mbps upload. This is nice.

It's also almost 3x the speed I had before for 30% less money monthly (to be fair, I've also changed some services, but rather minimally).

This is a nice upgrade... only thing left to change is the outgoing SMTP server in my Thunderbird connection, and then I'll be done with the internet connection.

Later on tomorrow, I'll configure the eBox TV app on my Sony Bravia Android TV: apparently, I will no longer need a set top box and my TV will be able to manage the eBox TV connection directly. I can't wait to try this out and see, but now it's late so time to go to sleep.

Oh, and until I cancel my Videotron contract, my old TV service still works, so no huge rush to migrate (except for the fact that as of today, I'll be paying twice for the service).

Good night all!

PS. Ah ha. There was more to do: not only did I need to fix the /etc/hosts.allow files on my internet servers to allow access from home, but I also needed to fix the SPF records for both of my domains to authorize e-mail coming from eBox's SMTP servers. I've cleaned up the hosts.allow file pretty heavily, so I may need to go back and authorize my mobile phone and such... Sigh, there are always little things left and right.

/admin | Posted at 01:24 | permanent link

Big changes

So, this is the last day of 2020, and what a year it has been. The COVID-19 global pandemic has certainly been extremely disruptive to most people's daily lives. Many of us found ourselves having to set up semi-permanent home office spaces for teleworking, and the companies that didn't have proper remote work infrastructures found themselves facing significant difficulties.

And that's not even mentioning industries such as restaurants, travel, and hospitality where entire companies have found themselves in dire straights and people have lost their jobs in droves.

Through all of this, I found a new and fascinating job running the IT department at my alma mater, so overall 2020 has been a good and positive year.

From a technical point of view, we're just about to leave our current internet (and TV) provider to adopt ebox. We'll be moving up to a 400 Mbps connection, which is great. Hard to believe that our first permanent internet connection in 1995 was a 0.014 Mbps modem link (a 14.4 kbps modem connection) to Interlinx that connected our little Unix machine to the Internet for real for the first time.

EBox seems like a solid outfit. I'll let you know more in 2021 once I've completed the connection and activated the TV and Internet services.

Cheers to all of you, and here's hoping that 2021 is less quirky than 2020!

/admin | Posted at 16:33 | permanent link

I despise 'Automatic Private IP Addressing'

The number of times where a Mac, an iPad, or a Windows machine has caused me grief by chosing to self-assign an "Automatic Private IP Address" is becoming annoyingly large.

I would much rather have these machines inform me that there is a problem with the DHCP server on the local LAN and that I should fix it, rather than trying to self assign an IP address in the range of 169.254.x.y, which generally doesn't work and doesn't let the machine talk with any of the other devices on the network... and of course, because the machine that tried to helpfully self assign an address thusly will not notify me of this, meaning that it will take longer to find out what has gone wrong.

Sometimes, especially on Apple devices, it will also be annoyingly hard to make the device snap out of this mode and actually request a brand new IP address from the local DHCP server. Argh! In addition to that, it is usually distressingly hard to disable this behavior in devices, as they all try to be simple and auto-configurable. Argh again!

Another woe of DHCP address assignment are home routers that do not provide options to manage the list of assigned DHCP addresses or their corresponding leases, and which therefore run out of assignable addresses with leases running well into 2021 or something! Recently, my Livebox from Orange ran out of available DHCP addresses, and therefore stopped giving them out... which caused various networking equipment to fail in interesting ways.

So yes, I know: "use static IP addresses". I do that most of the time, but still have my various mobile devices configured for DHCP, simply because that's what ones does when travelling with ones' mobile devices.

Anyway, here's hoping for:

1. a simple way to disable 169.254 addresses in Windows, IOS, and Mac OS X
2. a simple way to edit the DHCP leases table on the old Sagem Livebox

So yeah, I'm not holding my breath :-)

/admin | Posted at 18:52 | permanent link