Version 60 for Ubuntu 22.04 is released

[johnfl68]

I also had this same issue.

Thank you for posting the steps to correct!

[st0rm]

Looks like Exchange/Activesync support is broken in V60

[tiagoespinha]

Thanks @Mandrake this was really helpful! One thing I noticed is that MIAB will restore the local.conf to the original every night when it does maintenance.

So my extension to this suggestion, that I’m contemplating submitting as a PR, is to change the base templates that the maintenance scripts use to create the local.conf, such that when maintenance regenerates local.conf, it does so with the required changes.

I changed:

• ~/mailinabox/conf/nginx-top.conf - here add the php7.4-fpm upstream as suggested by Mandrake.

• ~/mailinabox/conf/nginx-alldomains.conf - here change the /Microsoft-Server-ActiveSync location and the autodiscover.xml location to use the php7.4-fpm.

And that’s it then next time maintenance runs, it uses these files and everyone’s happy.

This has been working well for me so far. I guess the one thing to watch out for is that when I take a new version of Mailinabox, all my changes are probably going to get overwritten…

[Infidelus]

Tried to upgrade last week but ran into a number of issues and ran out of time to troubleshoot. Tried again today after finding a few fixes.

60.1 is now up and running on Ubuntu 22.04, but I did see a couple of minor errors at the end when reconfiguring MIAB:

doveconf: Warning: NOTE: You can get a new clean config file with: doveconf -Pn > dovecot-new.conf
doveconf: Warning: Obsolete setting in /etc/dovecot/conf.d/10-ssl.conf:91: ssl_dh_parameters_length is no longer needed

I’m not sure if there’s anything I actually need to do on these.

More or an irritation is, and as someone else has mentioned above, neither my contacts nor calendar are populated with any entries. There’s mention of using the occ command, but I can’t seem to find the right syntax to try and disable/re-enable both apps to see if that fixes the issue.

[Edit]Found the relevant commands:

sudo -u www-data php /usr/local/lib/owncloud/occ app:disable calendar

Sadly though, running disable and enable haven’t fixed the issue and I still don’t have my calendar or contacts list back.

[bdmacl]

I’m having “Temporary failure in name resolution” issues. As a result, trying to resolve and restore my backups is failing. I’ve started from bare metal on my Virtual instance, installed Ubuntu 22.04 LTS X64, followed the normal MIAB installation process, and get those name resolution failures. I destroyed the server and tried again via the built in console with my service provider, thinking maybe there is an issue with my SSH connection and my firewall, but I end up with the same issue. I went ahead and tried the migration/restore effort, and any secondary domain and DNS info is not restored. I then reverted back to my “snapshot” instance and ran “mailinabox” on the old instance to see if I would get the same name resolution issues, and I do not.

The first error happens at the Roundcube installation, twice when installing Nextcloud, then again after Nextcloud states it is already at the latest version, and finally at the Munin installation.

Suggestions?

[andrew]

I saw something similar, and got around it by editing /etc/resolv.conf so it pointed to a good (local) name server, then rerunning sudo mailinabox. (resolv.conf might be left pointing to 127.0.0.1, but if your box doesn’t have a functioning name server at that point, things are going to go pear-shaped!)

A symptom for me was that many unrelated commands that produced error/log messages got very slow (I guess they were waiting for a timeout) and I’d get a “cannot resolve” for my local box.

[bdmacl]

I thought that, but when I restore to my previous system image, /etc/resolve.conf also only has 127.0.0.1, and no other IP. And if I run “sudo mailinabox” it successfully runs through the process without errors or those nameserver issues.

[andrew]

For a completed MIAB install, /etc/resolv.conf does have only 127.0.0.1, because it’s using a local instance of named as the name server.

I have seen my box with that named service not working, then you can’t resolve names, and so the install etc can’t run. If your install process breaks and you get an error doing something like nslookup www.google.com, then editing resolve.conf might help. But if nslookup is working fine, you have some other problem.

It’s not clear to me, from your description, exactly what the problem is. Does the install run completely? Was MIAB working, at least partly, after the install? It’s not clear what you mean by “those name resolution failures”.

[bdmacl]

MIAB install completes. It then gives me errors when trying to go to the web console, but if I refresh a couple of times, I’ll get in. However, MIAB isn’t truly functional, in that it won’t restore completely. I reverted back to a snapshot, and I’ll do a fresh backup, and try again next week. I’ll capture screenshots along the way too.

[ice2k2]

Besides the normal ones above - one thing that i found missing was a local postgrey file - not sure it’s in the scope tho - but just if anyone notice that postgray was enabled after migrating.

/etc/postgrey/whitelist_clients.local was not grabbed - naturally just manually recreated it, so local files with custom changes might not be grabbed.

[tdahbura]

I opened an issue in GitHub for this (just tested again with 60.1) and it is still present.

[jjj]

Thanks for this! It worked great for me, too!

[michaelscott]

Very excited about this release. I have installed Ubuntu Server 22.04. However, every time I try to install Mail-in-a-Box by following the instructions I get to the point where it asks for the hostname, I provide it and then after a couple of minutes the installation fails. The error says:

FAILED: add-apt-repository -y ppa:duplicity-team/duplicity-release-git, followed by a lot of references to recent calls made in the code.

So–in an effort to avoid being lazy I added this to the repository myself, did an apt update and an apt upgrade. Then I did an apt install duplicity and installed it manually.

Still–even after all this the installation fails at the same location every time with the same message.

Any ideas on what else I could try? Is there an installation log file somewhere I could peruse or upload?

Looking forward to the new version. I’m currently on Ubuntu 18.04 and MIAB v55.

Mike

[michaelscott]

Just to be thorough I blitzed everything and did a fresh install of Ubuntu Server 22.04.

On a clean install I am having the same exact error as I was before I re-installed.

Just updating the issue. No idea where to go from here. I admit–I don’t know where/if there is an installation log file that might give me the answer I need to resolve…

[digititus]

Monitoring. Have the same issue

[shuttermonster]

Recommended change to the upgrade instructions: add a final step saying “grab and store securely your NEW backups-key as this will be different from your old server.” I almost missed that step but, thankfully, it occurred to me to confirm that the key was the same and, of course, it wasn’t.

[hughsw]

Hi All,
I am getting ready to do this upgrade, having carefully (I hope) read and digested the travails reported here.

My /home directory is on a separate data volume, so I can attach it to any server in the data center. My question is what do the experts say regarding just attaching and mounting the volume on the new Ubuntu 22.04 server, after doing the MIAB install on the new server (instead of doing the duplicity restore step)? My proposal is to:

• set up the new Ubuntu server and install MIAB (this step is already done)
• on the old server, do all the backup, cleaning of ssl directory, etc prep work that precedes the duplicity restore step as documented in Moving to a New Box / Testing Backups
• shut down the old server and attach the volume to the new server
• edit /etc/fstab to mount the volume on /home
• reboot
• rerun sudo mailinabox as per instructions

Does anyone have any suggestions, gotchas, insights with this plan? I think my question boils down to whether there are things that get put on the new server in /home/user-data that need to stay there for the new MIAB to work? Or will the sudo mailinabox put them there if they are missing?

[hughsw]

For the record, I had a trouble-free upgrade, with some different steps from the “official” guide:

I have migrated my MIAB from v57a to v60.1 without any difficulties. I followed a plan derived from the above outline, but more closely mimicing the duplicity restore, and with a couple of additional steps.

Dual boot server

In order to preserve my IP address I configured the server to be dual boot Ubuntu – either 18.04 with my existing v57a MIAB, or 22.04 with the fresh v60.1 MIAB install with exactly the same configuration (/etc/mailinabox.conf) and the initial admin email account, but otherwise no users or data.

There were (brief) downtimes for the 18.04/v57a email server any time I was booted into the 22.04/v60.1 distro. While doing such work I disabled all ports in the firewall except 22, 80, and 443 in order to prevent any bogus rejections of email to the primary domain. I ran /usr/local/bin/mailinabox a couple of times, and logged into the admin page to sanity check that MIAB plumbing was working, albeit hobbled.

Verifications

The existing 18.04/v57a server had the disk for the 22.04/v60.1 server mounted at /mnt/new so I could perform the following steps while the existing MIAB was operational.

I verified that the UID and GID for the www-data user and group were the same in /etc/passwd and /mnt/new/etc/passwd. I similarly verfied the user-data user and group. This seems like an important check. In an earlier upgrade attempt my 22.04 Ubuntu distro included an ubuntu user which caused the user-data user and group to have a different IDs from those in my existing 18.04/v57a MIAB (which has no ubuntu user).

Instead of populating /mnt/new/home/user-data from my backups (11GB, rsynced to a remote host) I copied /home/user-data onto the fresh /mnt/new/home/user-data, using rsync.

Before doing so I ran some diffs in order to see the set of files in the 22.04/v60.1 installation that would not be overwritten by 18.04/v57a files. In addition to the timestamped files in the ssl directory that are implicitly implicated as troublesome in Moving to a New Box / Testing Backups, I found keyfiles in dns/dnssec that looked like they could be similarly confusing to runtime components. I decided to remove them too.

Changes and copying files

rm -r /new/home/user-data/ssl/*
rm -r /new/home/user-data/dns/dnssec/*
# Copy credentials used for rsync backup
cp /root/.ssh/id_rsa_miab /root/.ssh/id_rsa_miab.pub  /mnt/new/root/.ssh/

# Initial copy of user-data on live user-data tree -- took several mintues
rsync -av /home/user-data/ /mnt/new/home/user-data/ > ./migrate-prep-$(date '+%Y-%m-%d-%H%M-%S').log1

Any inconsistencies from running that initial rsync on a live system are corrected in the subsequent rsync below.

I then ran the following script on the old MIAB system:

#!/bin/bash

set -eu

ufw --force reset
# Just in case anything fails
ufw allow 22
ufw --force enable

(cd /root/mailinabox ; management/backup.py)

service postfix stop
service dovecot stop
service php7.2-fpm stop

service spampd stop
service postgrey stop
service mailinabox stop

# this time it's fast
rsync -av  /home/user-data/ /mnt/new/home/user-data/ > ./migrate-prep-$(date '+%Y-%m-%d-%H%M-%S').log2

shutdown -h now

Updated server

I then rebooted the server to 22.04/v60.1, logged in, ran mailinabox, and then checked up on status and used my email client. Everything looked good. In my email, a few recent emails were marked as unread even though I had read them shortly before the final backup, rsync, and shutdown. Otherwise, nothing untoward in the past 36 hours, and “everything seems to work” from a couple of power users.

[hughsw]

On an earlier attempt to upgrade, I had a similar failure, and I confirmed that the duplicity-team repository was down. It came back up much later in the day…