The release of Ubuntu 18.04 LTS is coming closer and closer now.
April 26th 2018 is the release date.
I wonder if there are already plans for the Mailinabox migration from 14.04 LTS to 18.04 LTS.
As the end of 14.04 LTS is approaching fast now.
As posted over here
@jirislav runs a working, modified copy of Mailinabox on 16.04 LTS.
Perhaps he can contribute one way or the other?
Yeah, I won't hesitate to contribute ;) Btw, I know we could start migrating to 18.04 right away, but there still may be a lot to change until official release, so when do you guys think it would be the best time to do this?
I think also @zazaian could help (based on what he wrote into this issue: https://github.com/mail-in-a-box/mailinabox/issues/1225)
According to the ReleaseSchedule, there will be FeatureFreeze & Debian Import Freeze at March 1st, so that could be our day to start the migration.
Hey @xetorixik and @jirislav - I'd definitely be willing to help with this. I got the whole mailinabox backend working on 16.04 but gave up when I hit issues with the python service daemon. I'll peek at @jirislav's fork to compare. My fork is zazaian/mailinabox. You'll see my 16.04 commits on top of the base system. I'm not an experienced pythonista but I think we should also prioritize improving the implementation of the python layer, including adding a test suite so this process isn't as painful in the future. I'm mobile right now so I just wanted to chime in, but I'll provide further thoughts when I get to my laptop later.
_Sent from my Motorola XT1254 using FastHub_
Good to see that there is so much enthusiasm.
@jirislav next Thursday is indeed the feature freeze.
Not much will change, a few days before feature freeze, apart from bug fixing and polishing.
Ideal to setup now and start the transition in a couple of days.
As we get closer and closer to 14.04's EOL, switching to 18.04 becomes more and more urgent.
As written by Mail in a Box founder @JoshData:
"My hope is that we switch to 18.04, giving us about a year before 14.04's end."
Given the fact that you have to give end-users time to switch quietly.
Based on a stable MIB 18.04 system that is not yet available.
It is now time for action. In short, my topic is a wake-up call.
@jirislav
As you want to start right away
and 18.04 feature freeze is around the courner.
Maybe you could arrange something with @JoshData.
To start with @zazaian
@jirislav As it is March 1st today.
Ubuntu 18.04 LTS is feature frozen.
According to the ReleaseSchedule, there will be FeatureFreeze & Debian Import Freeze at March 1st, so that could be our day to start the migration.
Okay, so I'm trying the migration from my working fork with MIAB on Ubuntu 16.04 to upgrade to 18.04.
As I can't know if that will work & yet I'm using that MIAB as the one and only production server, I have snapshotted the MIAB first, so that I can easily revert this operation to the working 16.04, if anything goes wrong.
After the snapshot is done, I got into the interactive root session so that I don't have to type sudo before every command:
# Be careful
sudo -i
Next, I've issued these commands to upgrade to bionic:
# update current packages to the latest
apt update && apt upgrade -y
# get current ubuntu codename (lsb_release -c | awk '{print $2}') and replace it with bionic in /etc/apt/sources.list
sed -i "s,`lsb_release -c | awk '{print $2}'`,bionic,g" /etc/apt/sources.list
# perform the upgrade
apt update && apt dist-upgrade -y
Now that takes a little bit long, but after a while, I'm prompted for decision about changing several configuration files. I decided about everyone of them to be kept at their current installed version.
In my case the config collision was with those services:
include /etc/nginx/modules-enabled/*.conf; (absence of modules could cause some issues)grub due to the default way digitalocean sets up the droplet - I always choose to keep the old versionUserID opendkim to increase the security of the system - we should consider adding it from within the setup/start.sh - let me file a new issue after I finish this migrationThen the apt dist-upgrade -y got frozen at 92% for a while, when there was suddenly a message saying that opendkim.service systemd unit got probably broken somehow, thus returning an error from dkpg: opendkim --configure saying that installed opendkim package post-installation script subprocess returned error exit status 1 - let's hope it's not a big deal.
Next it continued showing another conflicts (still leaving old configurations everywhere):
opendkim, so this should also be fixedAfter the dist-upgrade finished, I've got into investigating the problems with opendkim & opendmarc. It have showed up that there was problem creating PID file, so I've issued the following remedies:
sed -i 's,/var/run/opendmarc.pid,/var/run/opendmarc/opendmarc.pid,g' /etc/opendmarc.conf
echo 'UserID opendkim' >> /etc/opendkim.conf
echo 'PidFile /var/run/opendkim/opendkim.pid' >> /etc/opendkim.conf
After fixing those configurations, it was sufficient to run:
apt install -f
And now, it seems like I've got working MIAB at the Ubuntu 18.04 Bionic Beaver! :)
Use at your own risk (snapshot or another backup process is strongly recommended):
rm -rf $HOME/mailinabox
# Clone this fork
git clone https://github.com/jirislav/mailinabox.git $HOME/mailinabox
cd $HOME/mailinabox
git checkout v0.26c-ubuntu16
# Run installation
setup/start.sh
# Get interactive sudo shell
sudo -i
# Prepare for bionic
sed -i 's,/var/run/opendmarc.pid,/var/run/opendmarc/opendmarc.pid,g' /etc/opendmarc.conf
echo 'UserID opendkim' >> /etc/opendkim.conf
echo 'PidFile /var/run/opendkim/opendkim.pid' >> /etc/opendkim.conf
# Upgrade to bionic
sed -i "s,`lsb_release -c | awk '{print $2}'`,bionic,g" /etc/apt/sources.list
apt update && apt dist-upgrade -y
# Finally, reboot
reboot
After then, I see all services up & running without any exception :)
Note that after greater version than v0.26c is released, the recommended way to upgrade to Bionic Beaver will change by omitting the # Prepare for bionic section. I'll try not to forget to update this comment.
I'll have to incorporate those configuration fixes to the setup/start.sh, so I've created an issue on my fork for that.
Expect this to be done along with next MIAB release merge.
Oh, now I've encountered a problem with Nextcloud & Munin not running at all. Gonna look into this.
But all other services look okay according to the admin panel.
Looks like a problem with nginx. Got to have more time for this ..
Also running setup/start.sh ends with more problems:
Primary Hostname: ####
Public IP Address: ####
Public IPv6 Address: ####
Mail-in-a-Box Version: v0.26c-47-gee06587
Updating system packages...
Installing system packages...
Initializing system random number generator...
WARN: Duplicate profile 'Dovecot IMAP', using last found
WARN: Duplicate profile 'Dovecot Secure IMAP', using last found
WARN: Duplicate profile 'Dovecot POP3', using last found
WARN: Duplicate profile 'Dovecot Secure POP3', using last found
WARN: Duplicate profile 'Dovecot IMAP', using last found
WARN: Duplicate profile 'Dovecot Secure IMAP', using last found
WARN: Duplicate profile 'Dovecot POP3', using last found
WARN: Duplicate profile 'Dovecot Secure POP3', using last found
Firewall is active and enabled on system startup
Installing nsd (DNS server)...
WARN: Duplicate profile 'Dovecot IMAP', using last found
WARN: Duplicate profile 'Dovecot Secure IMAP', using last found
WARN: Duplicate profile 'Dovecot POP3', using last found
WARN: Duplicate profile 'Dovecot Secure POP3', using last found
Installing Postfix (SMTP server)...
WARN: Duplicate profile 'Dovecot IMAP', using last found
WARN: Duplicate profile 'Dovecot Secure IMAP', using last found
WARN: Duplicate profile 'Dovecot POP3', using last found
WARN: Duplicate profile 'Dovecot Secure POP3', using last found
WARN: Duplicate profile 'Dovecot IMAP', using last found
WARN: Duplicate profile 'Dovecot Secure IMAP', using last found
WARN: Duplicate profile 'Dovecot POP3', using last found
WARN: Duplicate profile 'Dovecot Secure POP3', using last found
Installing Dovecot (IMAP server)...
FAILED: apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confnew install dovecot-core dovecot-imapd dovecot-pop3d dovecot-lmtpd dovecot-sqlite sqlite3 dovecot-sieve dovecot-managesieved dovecot-lucene
-----------------------------------------
Reading package lists...
Building dependency tree...
Reading state information...
Package dovecot-lucene is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
dovecot-core
E: Package 'dovecot-lucene' has no installation candidate
thus I don't recommend upgrading to bionic yet. Going to revert the upgrade.
What you did is a big improvement. Thanks & Congrats! ... Just wondering if could be easy or not for you to make 'Munin' and 'Nextcloud' optional at installation step... To have the option to exclude one or both or 'none' to be installed, would be awesome, too.
@jirislav Hugh first step! Great. Thanks.
What I notice:
The modified Postgrey is compiled against the current Ubuntu 14.04.
It seems to me that this should be compiled against version 18.04.
When available as a final version in April later this year.
Dovecot_lucene is phased out since Ubuntu 16.04. Therefore this error?
Ubuntu advises Solr as a replacement.
@jirislav Does Solr work according to your wishes?
As written here to your fork.
Free_tls_certificates
How long can it last?
As the current slution is to pin Free_tls_certificates's acme to v0.20, which is the last version compatible with free_tls.
Your fork is different with upstream at first sight.
The following is different.
Nextcloud Spreed and Nextant
Chat, Video & audio calls for Nextcloud and Full text search.
It seems to me that this is optional?
Hey guys, I'm going to have quite busy time in the next few weeks so I'm not going to be able to obtain enough time and take a deeper look into this. I hope that I'll be finished with the apartment reconstruction before the end of March.
@xetorixik Solr didn't fulfill my expectations mainly because of it's huge RAM requirements, polluting the swap, thus increasing the latency of the server. Also, it's really complicated to maintain working Solr updates using just Bash & python, we would need more advanced tool, e.g. Salt Stack, but that's a long story. Bottom line I'd like to evade Solr as possible until we have good tools to maintain it.
My fork is different, yes. For now, I've dropped the Solr & Nextant installation, so the only thing that differs from upstream is Spreed. But it's installation is not optional. It gets installed by default and you would have to change the source code to change that.
Debian still has the dovecot_lucene-package, is it possible at all to make Mail-in-a-Box run on a Debian machine?
If somebody already tried this than I would like to know about possible caveats. Otherwise I might look into this myself, I would like to contribute
@dexbleeker the upstream Debian dovecot_lucene package is indeed still available and is also actively maintained.
Mail in a box on Ubuntu 14 uses its own dovecot_lucene fork.
It seems to me that a fork is an option for Mail in a box on Ubuntu 18.
But that is of course to be decided by @JoshData
It is waiting for his reaction, since he has not been seen here for a while.
@JoshData Any official date for an upgraded release to Ubuntu 18 ?
Sorry for a non very helpful contribution, in my case my mail server is based on a Debian 7, which has only about two month of LTS remaining, so the ability to switch to a fresh Ubuntu LTS with MailInABox would be awesome.
Unfortunately I still haven't had time yet to start working on this, and I don't know when I'll be able to. Probably not until May.
Alright, thank you, can we expect something stable to released for the end of summer 2018 ?
No, I really mean it when I say I don't know when I'll have time to start working on it. :|
I think in the past we semi-decided that at a minimum we should wait until the first point release so that other project handle the initial teething problems anyway. Historically the first post LTS Ubuntu point release contains the biggest delta of urgent fixes.
@JoshData personal I would love to help with the development - did you created a meta issue or a project that contains all, to you known, parts that needs modifications or need to be watched for?
Not that now 10 people just basically do the same and get lost somewhere, where everybody could have made just a little bunch of work to make it happen. This is just my personal idea to get this beauty up an running.
I'm interested in helping out with this as well. I started by looking at the dovecot_lucene business. The dovecot documentation makes it look pretty straightforward to compile dovecot with the plugin, but I wasn't able to find any documentation (could be missing something obvious) if there were any other special compilation instructions given before compiling again 18.04. Also, for any of us that might be wanting to take a bit of a load off of @JoshData by tinkering at this, maybe having a different repo than the project one to toss stuff into to test?
Also, for any of us that might be wanting to take a bit of a load off of @JoshData by tinkering at this, maybe having a different repo than the project one to toss stuff into to test?
I don't think that is necessary. That's what repository branches are for.
@justinmayer I'll bare my throat here to you. I'm quite comfortable with Linux, but quite a novice at any sort of development. I'd like to contribute to this project and help with its development towards the future, but I'm going to have to learn what repo branches are and how I can use them to do so. If you've got a rabbit trail that you'd recommend I go down, I'll follow it.
Make a fork. No need for Josh to give someone permissions, especially early on into the "contribution process".
Hi all. I'm getting closer to having time to work on this.
I've started by working on a certbot branch that replaces my free_tls_certificates package with EFF's certbot tool so that we have less to maintain going forward, in light of current breakages and a long history of keeping this working.
I'm not sure what the deal is with dovecot-lucene. It wasn't available in Ubuntu 14.04 either (we use a PPA I made that builds it), so I'm not sure how it became even less available. :( I'm pretty sure we'll just end up dropping support for server-side full text search because I can't spend time trying to build a new .deb again.
Similarly, I'd like to drop my PPA's postgrey package too and use something like the suggestion in #765 instead so we can stick to Ubuntu-maintained packages as much as possible. That'll also let us drop my PPA entirely, which would be a good thing.
Some ways to be helpful include working on automated tests like in #777 so that we have a way to check that a Ubuntu 18.04 version is actually working, and then finding the minimum changes we must make to our scripts to get it to run correctly in the new Ubuntu release. Thanks all.
Hello, I'd like to make a suggestion. As by now some work have to be done, maybe it's time to move to SOGo Groupware, like it was asked in #920?
I mean it would save the not really needed things like nextcloud and (on iOS only?) the not working z-Push. Instead you would have all the contacts, calendars, mail and well working Exchange support built in. Please think about it.
That's not really related to moving to Ubuntu 18.04, and assuming Nextcloud's installation doesn't have to change for 18.04, then I definitely don't have the time to switch out a major component of Mail-in-a-Box, which includes providing a data-preserving upgrade path for existing users.
@JoshData I just see this comment now:
drop support for server-side full text search because I can't spend time trying to build a new .deb again.
This after I finally fixed my lack of server side seaching. lol #1385
Anyway, hope this feature stays because it's awesome and a deal breaking for me switching some family members.
Awesome
Is mailinabox dead? Can't find much info anywhere on 18.04 :(
Please read the thread before sending out a notification to everyone.
The plan as far as we know is to have it ready a month or two before trusty is EOL.
@dexbleeker Yes, it possible to run it on Debian Stretch with some changes. If you or anyone else is interested I can put up my fork.
Hey guys - sorry I've tapped out of this conversation to this point. I'm under the gun on the release of a major project that's launching soon and subsequently sapping all of my time. When I get some breathing room I'd be happy to review the work @xetorixik, @jirislav, @jdriordan and others have made.
One of the issues I had with the initial release while porting to (originally) 16.04, was with some of the Python business logic for the UI front-end. Something that may be nice to provide in our 18.04 release would be either a modernized structure for the Python interface (maybe with Django? Though my personally expertise are in the Ruby/Rails and Elixir/Phoenix stacks), or at least just adding some unit tests to the existing Python logic to make it more easily portable moving forward.
Any thoughts on this?
Adding tests is always a good thing. See #777. But it's not something that we need to do before upgrading to 18.04. (Using Django would take a lot of work and probably be overkill.)
@JoshData maybe it's just my naivit茅 in Python, but I was trucking along with my 16.04 upgrade until I hit the Python section and flamed out. My 16.04 branch should be near-productional with the exception of some bugs in the front-end. My point is that without tests it was very difficult for me to troubleshoot deep-stack bugs.
I understand what you're saying. I'm not disagreeing. I'm just saying it's a logically separate issue from the topic of this issue.
Please read the thread before sending out a notification to everyone.
The plan as far as we know is to have it ready a month or two before trusty is EOL.
@damongant - there had been no talk for a month, and @jirislav's fork was retired, so I was wondering if there was still conversation going on. Maybe I could have done it in a better way but there sure has been a lot of discussion since I commented...
Any news, guys?
I just wanted to sidenote that I was able to get mailinabox to work on 16.04. Just make sure you keep your configurations, or at least inspect the differences when apt asks you whether you want to keep your configs or inspect the differences or use the package maintainer's version. You do not want to use the package maintainer's version without at least inspecting what gets changed.
I imagine the process will be the same for 18.04 but I haven't had the opportunity to dig further and confirm that things work nicely when upgrading.
The main showstopper for me is that mailinabox's launchpad.net repo doesn't have binaries for xenial and most likely won't have any for bionic beaver:
So if we want the upgrades to go off smoothly, we'll at the very minimum need these packages to be resolved:
Err http://ppa.launchpad.net xenial/main amd64 Packages
404 Not Found
Err http://ppa.launchpad.net xenial/main i386 Packages
404 Not Found
Ign http://ppa.launchpad.net xenial/main Translation-en_US
Ign http://ppa.launchpad.net xenial/main Translation-en
Fetched 6,385 kB in 6s (936 kB/s)
W: Failed to fetch http://ppa.launchpad.net/mail-in-a-box/ppa/ubuntu/dists/xenial/main/binary-amd64/Packages 404 Not Found
W: Failed to fetch http://ppa.launchpad.net/mail-in-a-box/ppa/ubuntu/dists/xenial/main/binary-i386/Packages 404 Not Found
@JoshData Please please please do NOT drop full text search in the 18.04 version!
@tramtrist And what will you be doing to help that effort?
@JoshData Yeah, if FTS ins't working on release I'll be pulling the aforementioned Debian dovecot-lucene package and at least taking a stab at porting it. I'd rather work on that then have to keep using another service. Mailinabox just works and works really well.
It has to be easier than it was getting solr working with mailcow which I eventually got working and which takes waaaay too many resources and crashes about once a week due to memory issues.
If you can figure out how to make it work, that'd be great!
Thanks to @deflume1 and #1398, work has begun on the branch https://github.com/mail-in-a-box/mailinabox/tree/ubuntu_bionic.
Thank you @JoshData! How is it working? I am thinking about spinning up an 18.04 to start planning the move. Or is there discussion somewhere directly related to that branch so I could ask more appropriate questions??
@derekslenk Perhaps not final yet but pay a look to https://github.com/mail-in-a-box/mailinabox/pull/1398#issuecomment-417878402 . Hope this helps!
I notice that the dovecot guys have a build of dovecot-lucene for 16.04 here: https://repo.dovecot.org/
Has anybody tried using that? Or getting in touch to see what it would take for them to provide an 18.04 build?
Fyi, according to cmouse in #dovecot they are working on having 18.04 packages in that repo by the end of this year.
Okay, one more update for today. I have now installed the 16.04 packages from https://repo.dovecot.org/ on a miab system running 18.04, including dovecot-lucene.
I had a problem with dovecot-antispam, which is included in the standard Ubuntu repos but in an old version. I tried rebuilding the package, but it turned out that the old version didn't support dovecot 2.3. So I used the latest source version of dovecot-antispam, built it and install with checkinstall (I don't really know my way around package maintenance very well, so I didn't know what the professional way is of doing this). I was then able to install that plugin correctly.
I modified dovecot config files along the lines of the 14.04 setup, including the fts and fts_lucene plugins. As a result, I now have a working 18.04 miab system that uses fts with lucene - I tried with some indexes that I had previously created on 14.04 and I indexed a new folder - no problems.
There are a few warnings on startup of dovecot, due to outdated config file syntax. Otherwise I don't see any problems with this setup.
cmouse on #dovecot said it's possible that the 16.04 packages are not perfectly adjusted for 18.04, so that's something I'll keep in mind. But before long there should be 18.04 packages from that repo, so it's not a long-term issue.
I'm considering working on a PR to integrate the dovecot related work I did in the 18.04 branch. @JoshData would you consider going the way I described? If that's not an approach you'd be willing to take, I don't need to do that work.
I think it'd be best to hold off on more work until they have 18.04 packages. It'll just be a lot simpler then. Less work for everyone. :)
Well, other than adding their repo and using it over the standard Ubuntu one, the only issue is that of building a compatible version of dovecot-antispam. And that's still going to be a problem when there are 18.04 packages in that repo.
We can figure that out later. Removing dovecot-antispam is an option --- and perhaps preferable to losing fts-lucene.
I don't mind maintaining a launchpad ppa for a dovecot-antispam build on the basis of the dovecot repo packages - 16.04 or 18.04 or both.
I just found that dovecot-antispam is deprecated according to the dovecot wiki, they suggest replacing it with IMAPSieve. I'll look into this in more detail.
Hi all. I'm now running the ubuntu_bionic branch on my personal Mail-in-a-Box, so things are looking good. (Note that I upgraded my existing box to the latest MiaB release and _then_ did a backup/restore to a new clean Ubuntu 18.04 box and installed MiaB using the ubuntu_bionic branch there. That's the only supported upgrade path.)
Josh- That's great news. Will there be a posting with the supported upgrade path on the Mail-in-a-Box homepage? Sounds like it went like this:
(On Ubuntu 14)
-upgrade mail-in-a-box to the latest release (v0.28) branch.
-backup mail-in-a-box (stash the backup files somewhere)
-Provision a Ubuntu 18.04 (LTS) box on your favorite hosting providor
-Install the ubuntu_bionic branch by:
$ git clone https://github.com/mail-in-a-box/mailinabox
$ cd mailinabox
$ git checkout ubuntu_bionic
$ sudo setup/start.sh
and then let things proceed as usual.
Is that about right?
That's right. I also ensured postfix remained off after the last backup was made to ensure I didn't receive any email that wouldn't be copied over by the backup, and in general probably nginx should be turned off as well so that users aren't using contacts/calendar/webmail.
I'm going to do one more final release of the Ubuntu 14.04 Mail-in-a-Box --- in fact, the current release is not the right version to be using before going to Ubuntu 18, I think it has to be the unreleased version because of Nextcloud. After that release we'll prepare Ubuntu 18 upgrade instructions, and then make an Ubuntu 18 release.
If you are planning a new release @joshdata would you mind if I create a PR to upgrade Nextcloud? The current version throws a security warning on iOS and has several usability issues.
After that I鈥檒l upgrade my dev box and if that works my main.
There's already a commit to get it to Nextcloud 13. If there's a newer 13.x, yes please. I think we can wait to go to 14 until later tho.
I missed that! I鈥檒l have a look. 14 can wait until later.
To support scaleway during the beta is it possible to merge this: https://github.com/mail-in-a-box/mailinabox/pull/1438
Oh yes, thanks, will do.
Josh- That's great news. Will there be a posting with the supported upgrade path on the Mail-in-a-Box homepage? Sounds like it went like this:
(On Ubuntu 14)
-upgrade mail-in-a-box to the latest release (v0.28) branch.
-backup mail-in-a-box (stash the backup files somewhere)-Provision a Ubuntu 18.04 (LTS) box on your favorite hosting providor
-Install the ubuntu_bionic branch by:
$ git clone https://github.com/mail-in-a-box/mailinabox
$ cd mailinabox
$ git checkout ubuntu_bionic
$ sudo setup/start.sh
and then let things proceed as usual.
- bring backup files over to new machine and restore using this process: (https://mailinabox.email/maintenance.html#moving-boxes)
Is that about right?
Hello.
I am getting an error
~
line 95: DEFAULT_PUBLIC_IP: unbound variable
~
Please help me to get rid of the same. I am using AWS.
Currently the command to clone the right GIT ubuntu_bionic branch (over 18.04 server only) is:
git clone -b ubuntu_bionic https://github.com/mail-in-a-box/mailinabox.git
Hope this helps.
Currently the command to clone the right GIT ubuntu_bionic branch (over 18.04 server only) is:
git clone -b ubuntu_bionic https://github.com/mail-in-a-box/mailinabox.git
Hope this helps.
Hello,
Still facing the same issue.
~
setup/questions.sh: line 95: DEFAULT_PUBLIC_IP: unbound variable
~
Please help.
@bhaskarb79, those problems should be fixed by #1482
@bhaskarb79, those problems should be fixed by #1482
Getting another line of error even after all modifications
~
RTNETLINK answers: Network is unreachable
~
That error is from here:https://github.com/mail-in-a-box/mailinabox/blob/0d4565e71db5ecbf1af444d433ba03321c7ce666/setup/functions.sh#L130
Error handling with this function might need some adjustments.
tldr; if you don't have ipv6 on your box, the error above shouldn't affect you
I migrated this week without any issues :+1:
Thanks for reporting your success!
I plan to make an official release of the ubuntu_bionic branch this weekend!
I'm running the bionic branch on my prod box. I had some issues with upgrading to v0.30, the dns update couldn't reach the management deamon. I couldn't reproduce this, it was fixed by rebooting. I'm blaming solar flares for now.
Thanks @JoshData for the huge amount of free time and work you put in the migration to bionic! I appreciate it very much 馃憤
Released! Details: https://discourse.mailinabox.email/t/mail-in-a-box-version-v0-40-and-moving-to-ubuntu-18-04/4289
Please open new issues if you see any new problems. Thanks everyone for all your help!!
Most helpful comment
That's not really related to moving to Ubuntu 18.04, and assuming Nextcloud's installation doesn't have to change for 18.04, then I definitely don't have the time to switch out a major component of Mail-in-a-Box, which includes providing a data-preserving upgrade path for existing users.