The process of completing the upgrade of the computer is mostly tedious. I’ll note here that I whiffed a little in my archiving the configuration from the old server. I should have just grabbed all of /var since that’s where the user crontab files are kept, among other useful things. That’s not a huge loss, but it fits in with the general theme of tedium.
In the process of setting up my mail server again, I ran into a peculiarity. I use ssl certificates via fetchmail to encrypt the connections to the various mail servers. So I installed the ca-certificates package and checked my .fetchmailrc file to see whether I had any unique certificates. Sure enough, I have one for a college account I still maintain.
Now, it’s possible to have the ca-certificates add custom certificates if the .pem file is saved into the proper directory and renamed to a .crt file. I couldn’t remember if it was in /usr/share/ca-certificates or in /usr/local/share/ca-certificates. I checked the latter first, just to see if it existed and sure enough, it did. So I added the certificate there and ran dpkg-reconfigure ca-certificates. But the certificate didn’t show up.
So then I copied the certificate into /usr/share/ca-certificates/local (I added the local sub-directory manually) and re-ran dpkg-reconfigure. There was the certificate file. So I added the certificate and tested fetchmail.
It wouldn’t connect to the server. The error was a ‘permission denied’ when trying to open the certificate file. I took this to be a good development since clearly the file was being found. I checked the permissions on the links and finally the cert file itself. Sure enough, the permissions were wrong. I set them to match the permissions of the other certificates (0644) and tried again.
Still got the same error.
It took me awhile until I finally tracked down the problem. For some reason, even though I had to place the cert file in /usr/share/ca-certificates to get it recognized by the system, the symbolic link in /etc/ssl/cert was pointing to the file in /usr/local/share/ca-certificates, which, sure enough, had the wrong permissions. I modified the permissions and finally had success.
So mail is up and running properly. Onward to Samba!