Archive for the ‘Computers’ Category

Getting Exim4 running on a new server

Friday, July 6th, 2018

We’ve always kept our virtual domains in /etc/mail/virtuals and I was under the impression it was the default location. It isn’t.

I don’t remember adding this code when I set up Exim4 on my Linode server, but it is missing on my Digital Ocean server. I needed to add the folowing lines to exim4.conf.template, just above the line system_aliases: in the router section.


virtual_domains:
  driver = redirect
  domains = dsearch;/etc/mail/virtuals
  data = ${lookup{$local_part}wildlsearch{/etc/mail/virtuals/$domain}}
  allow_fail
  allow_defer
  file_transport = address_file

I also missed the step of creating the self-signed key and cert, so make sure you do that as well.

The documents have lots of special cases for handling email that I never used, but one could come in handy. An attempt to deliver to a particular local part can be deferred or forced to fail by aliasing the local part to
:defer:
or
:fail:

So you could do something like this, since spammers use this address all the time.
support: :fail:

One thing we never did in the virtuals file is to send a comment for addresses that bounce, but it could come in handy. e.g

X.Employee: :fail: Gone away, no forwarding address
support: :fail: Please use the contact form on our website if you have support questions.

Getting Dovecot running on a new server.

Sunday, June 24th, 2018

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.

Monday, June 18th, 2018

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.

Monday, May 21st, 2018

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

Monday, May 21st, 2018

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.

Privacy Preference Center

Necessary

Advertising

Analytics

Other

Well Golly


Atheism Plus

Buy from Amazon