Getting Dovecot running on a new server.

I followed these Dovecot installation instructions and everything appeared to work, but I couldn’t get mail. I went into my mail client and retyped the password. I got an error message when it tried to verify the server saying that I had an invalid certificate.

I tried getting a standalone certificate using certbot, but my attempt failed. It turns out that you need to stop apache before running certbot with the standalone command. Then run:


sudo certbot certonly --standalone --preferred-challenges http -d mail.mymaildomain.com <code>

This puts a new certificate just for mail in the /etc/letsencrypt/live/mail.mymaildomain.com directory. You need to tell Dovecot where to find the certificate by editing the SSL file.

Look for these lines near the top of the file.


#ssl_cert = </etc/dovecot/dovecot.pem
#ssl_key = </etc/dovecot/private/dovecot.pem

Configure Dovecot

Dovecot’s SSL configuration is done in an auxiliary file located at /etc/dovecot/conf.d/10-ssl.conf. In here you’ll find two parameters that need to be changed: ssl_cert and ssl_key. Like postfix, dovecot will need the full certificate chain to present to clients for validation.

Edit the configuration file to point to the new certificates. Be sure to include the leading < before the file path, this is what tells dovecot to read from a file rather than use the value literally.


ssl_cert = </etc/letsencrypt/live/mail.example.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.example.com/privkey.pem

The only other issue I had was with the mail_location. I must have picked mbox format when the messages are in Maildir format. I changed this line in 10-mail.conf.


mail_location = maildir:~/Maildir

Notes on testing domains while migrating to a new server.

When moving sites to a new server, you can test each one by replacing the DocumentRoot in the 000-default.conf file with the directory containing each site. You might want to do some site tweaking and changing the location for each site can get tedious after a while. The solution is to set up Apache to test virtual servers without domain names. The first step is to edit the /etc/hosts file on the computer that you will be using to visit the sites. Add the sites you wish to test and the IP address at the end of the file.


142.255.228.33 firstsitetotest.com
142.255.228.33 secondsitetotest.com
...
142.255.228.33 lastsitetotest.com

You don’t need to reboot your computer or reload the file to get it to work.

Next, edit the 000-default.conf file in /etc/apache2/sites-available/
I keep my site files in the /www directory.


 <VirtualHost firstsitetotest.com:80>
    ServerName www. firstsitetotest.com
    DocumentRoot /www/firstsitetotest

 </VirtualHost>

<VirtualHost secondsitetotest.com:80>
    ServerName www.secondsitetotest.com
    DocumentRoot /www/secondsitetotest

 </VirtualHost>
...
 <VirtualHost lastsitetotest.com:80>
    ServerName www. lastsitetotest.com
    DocumentRoot /www/lastsitetotest

 </VirtualHost>

Reload Apache with sudo systemctl reload apache2 and test your config with sudo systemctl status apache2

If the sites currently exist, you should make a small change in the main file to make sure you are being redirected to the new site.

Notes on setting up a cloud server.

I’m moving a server that is on very old hardware to a Linode instance with Ubuntu Linux 18.04, Apache, MariaDB, and PHP 7. I know that I am going to have some migration issues since the current server is running Ubuntu 10.04.4 LTS.

Setting up Apache and PHP were straightforward, but I ran into problems with MariaDB. I turns out that even if you harden the installation and set a new password for root, you can’t log in with the new password. It uses the password for the root login on the machine. Once I figured that out, I created a user for myself and then installed phpMyAdmin.

Two problems occurred with that installation. First, apparently PHP7 does not include mcrypt, but the newest version of phpMyAdmin does not require it.

Second problem is that the conf file was not installed. I made a symlink to its location and restarted Apache. Then let Apache know that the conf file was available by running:


sudo a2enconf phpmyadmin


username: /etc/apache2/conf-available $ sudo ln -s /etc/phpmyadmin/apache.conf phpmyadmin.conf
sudo systemctl restart apache2

Notes on migrating user accounts to a new server

I found this link that was useful in moving my users to a new machine.


export UGIDLIMIT=1000
awk -v LIMIT=$UGIDLIMIT -F: '($3>LIMIT) && ($3!=65534)' /etc/passwd > /root/migrate/passwd.mig

awk -v LIMIT=$UGIDLIMIT -F: '($3>LIMIT) && ($3!=65534)' /etc/group > /root/migrate/group.mig

awk -v LIMIT=$UGIDLIMIT -F: '($3>LIMIT) && ($3!=65534) {print $1}' /etc/passwd | tee - |egrep -f - /etc/shadow > /root/migrate/shadow.mig

tar -zcvpf /root/migrate/home.tar.gz /home
tar -zcvpf /root/migrate/mail.tar.gz /var/spool/mail

cd /
tar -zxvf /path/to/location/home.tar.gz

cd /
# tar -zxvf /path/to/location/mail.tar.gz

There is one manual step that I needed to do. The procedures above create new groups but do not update the users in existing groups. To find out the current groups for the users run this command:


groups (admin_name)

I only need to do this for the handful of admin users on the system, so I didn’t bother to automate it.

Reboot to see your changes.

Notes on creating a droplet

I created a new Digital Ocean droplet and mostly followed the tutorials to get things up and running. A couple of things that I need to do to get the environment the way it is on other machines.

I had a bit of trouble with using Public Key Authorization. I think that I was selecting the key by triple clicking until everything was highlighted and then copying. I believe that I got a line feed a the end of the key that was messing up my login attempts. Carefully highlighting just the key seems to have done the trick.

I also was stymied for a while when my site didn’t display. First, since I turned on the firewall I needed to add either www (sudo ufw allow www) or Apache (sudo ufw allow Apache) to the rules. And then verify with sudo ufw status.

When I created the droplet, I destroyed the previous one so I needed to find the DNS records and change the IP address. Unlike other services, DO puts that in Networking.

I need to copy my .bash_profile file over to my home directory and add the line
. ~/.bash_profile to my .profile file.

Reload the profile with source ~/.profile

I also want all of the files in the www directory to be created with the admin group. That way, no matter who created them, I’ll be able to edit them.

You can change the default group for all files created in a particular directory by setting the setgid flag on the directory (chmod g+s _dir_). New files in the directory will then be created with the group of the directory (set using chgrp <group> <dir>). This applies to any program that creates files in the directory. mark4o

The default location for web files is /var/www, which is different than the setup on my older machines. (probably because the default location varies across distributions and over time). I put a symlink to it in the root. sudo ln -s /var/www/ www

I don’t want people to be able to view the directories, especially the images directory, so I disabled that ability by removing the word Indexes from the option line.


<Directory /var/www/>
  Options Indexes FollowSymLinks
  AllowOverride None
  Require all granted
</Directory>

I covered this in earlier posts, but it doesn’t hurt to repeat it. I make a few modifications to the apache config file to keep people from seeing things on the server. I added these lines after the section on .htaccess.


# We don't want people to see .inc files
<Files  ~ "\.inc$">
  Order allow,deny
  Deny from all
</Files>

# Do not allow .git version control files to be viewed
<Directorymatch "^/.*/\.git+/">
  Order deny,allow
  Deny from all
</Directorymatch>

# We don't want people to see .svn files, mainly in Wordpress installs
<Directorymatch "^/.*/\.svn+/">
  Order deny,allow
  Deny from all
</Directorymatch>

On my older servers I have lots of sites and their names end in .com, .net, etc. but on this version of Apache, the a2ensite requires files to end in .conf.

I also had some trouble with the https code that was added to the site by certbot. I took them out after reviewing the output of sudo journalctl -xe.

To install the certbot certificate I went to the page for my setup and followed the directions. I have a .com and .org version of this site and allow access using www and without so I need the certificate to work for all four of these. Rather than getting four certificates, I got one for the name I will use most, the .org, and then added the ones for www and .com.

Unfortunately, at the moment there is a security vulnerability so the normal method does not work.

Instead I had to stop Apache and run


sudo certbot --authenticator webroot --webroot-path /var/www/ACOV/ --installer apache2 -d example.org

sudo certbot certonly --cert-name example.org -d example.com,www.example.org,www.example.com

service apache2 restart

I had some problems at first because I had not set up the DNS records at Digital Ocean correctly. I typed the whole domain into the add a record field, when I should have just typed www. It added www.example.com.examp instead of www.example.org. After I fixed that it created the certificates and I checked them.

Unfortunately, something else is not right because Apache is not serving up the SSL connection. I’ll update the post when I figure it out.