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


#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


#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.


#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!


#32

No, my MiaB handles all the DNS entries, I do not use any external DNS.


#33

Just wanted to thank the team for their hard work, the instructions for upgrading from 14.04 to 18.04 were great and our migration went flawless.

Thank you!!

Chris


#34

Another possibility is that you did your test before the new DKIM key propagated … is this still an issue now?


#35

Yes, it’s still an issue, but as I said only at http://dkimvalidator.com. I just tested at http://www.appmaildev.com/en/dkim and there is no such issue - result: DKIM passed.


#36

Upgraded from 14.04 to 18.04 on LeaseWeb.com. No problems. (so far :wink: )


#37

Hi there, all.

Just a quick question. I want to upgrade the proper way described here. However, my cloud provider does not have any more availability in the region I’m already in. That means I would not be able to transfer my current IP to a new dedicated server upon installation. It also means I’d experience more latency when connecting to my server. As such, I would rather just keep my current one running. Is a do-release-upgrade chain from 14.04-16.04-18.04 completely unsupported? I’d hate to lose my IP and the reputation that comes with it, but I really want to do this upgrade.


#38

Just curious, but it is not important - who is your VPS provider? @dkbrown12

I have a similar situation with one of my providers. My intention is to make new backups and store them off site along with the secret_key.txt file. I will then recreate my VPS, meaning that it will be started from scratch with Ubuntu 18.04. Then I will install MiaB and restore the backup.

The method that Josh presented is the best for a perfect world – if something goes tilt, you simply continue on by continuing to use the existing droplet. In your and my situation we will only be able to rely upon our backup and that everything will work out.

I STRONGLY advise against doing the do-release-upgrade chain. Absolutely do not go this way. It too often fails, or introduces funky issues.


#39

I’m using Online.net. They’re great and affordable, but I prefer the AMS1 region and they only have availability in France right now.

I’ve trusted do-release-upgrade on my personal laptops and desktops, I’ve never encountered issues there. This is the first I’ve considered running it on a server, though.


#40

You are certainly free to try it. There is absolutely NO guarantee that it will work. If it does NOT work there is absolutely NO guarantee that anyone here will be able to help you work out the issues … that said, of course, I am sure that those here will try but …

So perhaps your best solution is to just rebuild your VPS by reinstalling the OS.

But if you absolutely want to try do-release-upgrade, then by all means do - knowing that if you run into errors or issues that you likely will be on your own. If you try and run into issues please start a new topic and we will help you if possible.

But honestly my personal feeling is that it will fail. Not so much on the OS level, but the components of MiaB will not make the changes cleanly. You will be in for much less time and frustration spent reinstalling your OS within your providers control panel. It is your decision.


#41

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)