Mail-in-a-Box version v0.40 and moving to Ubuntu 18.04

Announcements
11

Thank you so much, Josh and all contributors. My stuff is working. The upgrade to 18.04 and v0.40 was very smooth. I am so happy with it!

Something I just thought of concerning a final step for the migration – the secret_key.txt file changes as part of the reinstallation under 18.04 and v0.40, and I think a reminder to store the new post-upgrade secret_key.txt safely would not go amiss.

1 Like
12

Thanks Josh and team!!

Followed the instructions above and it was perfectly smooth sailing: did final backup to S3, rebuilt machine (Linode) to 18.04 so IP address etc stays the same, installed miab, pulled backup down from S3…PERFECT! Everything was there as if I’d never changed a thing.

Possible Gotcha Some people may overlook that even though their config is restored, it is not truly restored in it’s entirety i.e. the backup configs (from /home/user-data/backup) are not restored since they are not part of the backup in the first place. Thus you need to manually reconfigure backups via the admin control panel.

Thanks again!

Brett

1 Like
13

Perhaps it goes without saying, but a new machine (even if you use Digital Ocean’s rebuild option instead provisioning a new VPS) means a new ssh host key on the MiaB, and if you’re fetching local backups from the MiaB instance to somewhere else, you gotta update the known_hosts file, too, else your offsite backup scripts will get the man-in-the-middle warning.

So ALL aspects of the backup routine (local and remote) need to be checked and updated.

14

Hi,
thank you very much for the hard work!

Just want to add that since a year I use a separate disk mounted on /home/user-data , it is a nice approach as running out of space won’t harm your system root partition and makes backups with snapshot easier.

Now I can just create a new instance with Ubuntu 18.04 and attach the same disk to the new machine without having to restore or copy (a process that can be slow), making total downtime just a minute longer than the setup script

Maybe a good thing to do since a lot of users will switch
Cheers!

1 Like
15

I’m trying to setup MIAB on a fresh server, but stuck like this. Tried 2 times same result.

Waiting for the Mail-in-a-Box management daemon to start…

16

Looks like you are at UpCloud, too … Try this: Ubuntu 18 install issue and confirm if solved.

1 Like
17

Hey @JoshData - you may want to recommend WinSCP to users instead of FileZilla. Earlier this year the dev for FileZilla started shipping releases with “bundled offers,” i.e. adware. Some of the bundled stuff led to more bundled stuff that was straight-up malware.
Link:

18

That’s correct. And Thank you so much. The above solution worked me. MIAB is running perfectly fine. :sunglasses:

1 Like
19

Just wanted to say hi and a big thank you!

I have just upgraded and moved to ubuntu 18.04 without experiencing any issues.:+1:

20

Another option for Linode users is to go to “Remote Access” in the Linode Manager and select IP Swap.

21

I had problems when running the restore. I had to delete the following links manually in order to restore properly:

rm -rf mail/sieve/jcoplastic.es/administracion.sieve
rm -rf mail/sieve/jcoplastic.es/calidad.sieve
rm -rf mail/sieve/jcoplastic.es/comercial.sieve
rm -rf mail/sieve/jcoplastic.es/compras.sieve
rm -rf mail/sieve/jcoplastic.es/contabilidad.sieve
rm -rf mail/sieve/jcoplastic.es/copiacomercial.sieve
rm -rf mail/sieve/jcoplastic.es/direccion.sieve
rm -rf mail/sieve/jcoplastic.es/jefeturno.sieve
rm -rf mail/sieve/jcoplastic.es/jefeturnoinyeccion.sieve
rm -rf mail/sieve/jcoplastic.es/logistica.sieve
rm -rf mail/sieve/jcoplastic.es/mantenimiento.sieve
rm -rf mail/sieve/jcoplastic.es/marketing.sieve
rm -rf mail/sieve/jcoplastic.es/nopen.sieve
rm -rf mail/sieve/jcoplastic.es/pedidos.sieve
rm -rf mail/sieve/jcoplastic.es/procesos.sieve
rm -rf mail/sieve/jcoplastic.es/produccion.sieve
rm -rf mail/sieve/jcoplastic.es/subdireccion.sieve
rm -rf mail/sieve/jcoplastic.es/ventas.sieve
rm -rf mail/sieve/jcoplastic.es/ventas2.sieve
rm -rf owncloud-backup/2017-06-08-19:08:49/owncloud-install/config/config.php
rm -rf owncloud-backup/2017-12-07-08:53:16/owncloud-install/config/config.php
rm -rf owncloud-backup/2018-03-04-16:28:49/owncloud-install/config/config.php
rm -rf owncloud-backup/2018-11-08-18:40:06/owncloud-install/config/config.php
rm -rf ssl/ssl_certificate.pem

Hope this helps someone

Btw, great work to all the people putting their effort in MiAB

1 Like
22

Hi! Thank you for the great work on this release! :clap: I followed your instructions and I was able to go through the upgrade, and now I have a 18.04 droplet humming like a bird.

Some experience notes:

  • When I chose to destroy and rebuild the droplet as 18.04 I discovered that it did not include my ssh key. So, then I created a new separate 18.04 droplet with my ssh key included from which I then took a snapshot backup.
  • When I then selected to destroy and rebuild the droplet I was not able to select the newly created snapshot. It turned out that I had to resize my old 10$ droplet to the new 10$ 50GB droplet type. I was then able to select the new snapshot and rebuild from that.
  • When I tried to ssh into the newly rebuilt droplet I had to give a root password, which had been sent to me on my Digital Ocean mail which was hosted on my mailserver. So, I had to restore my 14.04 DO snapshot, have it running, before I could change my DO account email to an email not hosted by MIAB while I was upgrading the droplet.
  • After changing the DO account email I was then able to rebuild and log into the 18.04 droplet. I then installed MIAB and uploaded my local backups and did a restore which worked well.

Now I have a well working 18.04 installation. :blush: :tada:

23

My migration to Ubuntu 18.04 went flawlessly minus one issue. PHP files are not being processed in my www/default directory. I have a one line file that just echo’s a string. In Chrome I get a 200 HTTP response but an empty page. No errors in access or error nginx log files. Anyone have this similar issue? Any help appreciated.

SOLUTION:

I found the issue with my setup. I had to add:

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

To my nginx conf in /home/user-data/www directory.

24

My suggestion for everyone would be to make sure to copy the latest secret key somewhere safe. Test it and make sure it will actually decrypt the backup files.

Unfortunately, it seems the old secret key I had stored from when I first setup up MIAB is bad and will not decrypt any duplicity backups. I should have tested my backups before doing this process. I’m now stuck with useless backups and will have to start over from scratch. Live and learn, I guess.

26

I had one small problem.

Deployed an Ubuntu 18.04 VM, installed MIAB using the script, copied my user-data from the 14.04 VM to the 18.04 VM. Rebooted the server. A bunch of DNS errors in the admin interface status page. Waited for some hours and nothing changed.

Made a change to one of my domains (deleted a forwarding domain then re-added it) and got a general error in the admin interface (something like ‘Error Adding Domain’) - but then all the DNS errors went away, and mail started pouring in.

27

I succeeded in upgrading without too much trouble. A couple of things I could have done with - the restore from backup command says you need to use the path to the backup, however, what it actually wants is the path to the encrypted folder inside the backups folder, that is (by default) /home/user-data/backups/encrypted. One thing worth knowing is that it can take a long time to copy a backup to a new server, so I recommend using rsync rather than filezilla or scp - a first sync of backups might take an hour, but after a repeat backup, a second rsync only takes a few seconds, meaning you can have less downtime for your users. In case you’re wondering, an appropriate rsync command would be:

rsync -avP --delete /home/user-data/backups/ root@new-server.example.com:/path/to/mailserverbackup/

The --delete option is there to ensure you don’t get any obsolete files in your destination folder after a repeat sync (e.g. files that were obsoleted by a repeat backup).

The other small change I made was to preinstall the ppa:ondrej/nginx-mainline PPA. This resulted in it installing nginx 1.15.8 and openssl 1.1.1, meaning I could get latest TLSv1.3 support, and that all worked fine for admin and webmail. I also tightened up the default sshd_config settings to remove some old cruft, insecure MACs, ciphers etc - I could turn that into a PR if anyone’s interested.

1 Like
28

That would be great! I installed the PPA and it works fine post-install too. :smiley:

29

Thanks for your great work, @JoshData! The upgrade succeeded without any problems!

I just have one questions as there is something weird with testing out my DKIM signature. As suggested I used http://dkimvalidator.com but it’s shown that it’s not valid:

0.1 DKIM_INVALID DKIM or DK signature exists, but is not valid

When I send an Email to myself and check all the parameter within roundcube there are no such issues and my DKIM signature is shown as valid. Does anybody has an idea of what is going wrong?

30

Are you by any chance using external DNS?

If so, you need to change the DKIM key in your DNS settings. Also compare the External DNS page in the admin area to see if there are any other changes.

31

This is not supported by Mail-in-a-Box!