Version 60 for Ubuntu 22.04 is released

Announcements
#82

Like a few others I performed an in-place upgrade of Ubuntu from 18.04 to 20.04 and then 22.04, and then ran the mailinabox installer to get version 60. I know this isn’t supported, but It works, and I’m able to send and receive emails just as I could before.

I’m guessing the reason this method isn’t recommended is the warnings you get in /var/log/mail.log after doing this. Both postfix and dovecot retained the old configuration files, which causes warnings about settings no longer being required in dovecot and backwards compatibility mode in postfix.

I’m pretty sure these are going to cause an issue in the future, so I’ve fixed them myself by performing a clean install on a new instance and then copying /etc/postfix/main.cf, /etc/postfix/master.cf, and /etc/dovecot/conf.d/10-ssl.conf back (this seems to have covered all warnings so far)

Other than that I haven’t had any issues

2 Likes
#83

Sure, done! Here and here.

1 Like
#84

I had tried the in-place way as well, but eventually, I had issues with python / pip venv variables, that I could not wrap my head around. So I went with a fresh install which was less painful than I anticipated it to be. Well, apart from the ssl issue. :slightly_smiling_face:

1 Like
#85

Thanks for posting the procedure. It seems to have worked fine for me.

#86

Hi @cinergi just want to call out that this summary was super helpful for me and immediately fixed Z-Push on my end. Thank you!

#87

I’m glad it helped! However, please also see my post here. After using it for a while, I found that it’s unstable. I’ve since stopped using it and am using regular IMAP instead. Z-Push does not officially support PHP 8.0; if it were a simple matter of changing a few lines of code as I optimistically did, the maintainers of the Z-Push project would surely have done it already… I think we’ll have to wait for official PHP 8.0 support from upstream.

1 Like
#88

I also had this same issue.

Thank you for posting the steps to correct!

#89

Looks like Exchange/Activesync support is broken in V60 :frowning:

#90

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 :smile: 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…

#91

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.

#92

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?

#93

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.

#94

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.

#95

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

#96

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.

#97

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.

#98

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

#99

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

#100

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

Ran the setup script - temporary failure resolving
#101

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…