mailinabox
mailinabox copied to clipboard
mail-in-a-box
Support Ubuntu 22.04 Jammy Jellyfish
This is a draft PR combining #1752, #2008, and some additional changes to prepare for switching our support to Ubuntu 22.04, which is the next long-term support release coming in April.
Go for it. :)
Right now, Nextcloud doesn't appear to be installing correctly and it seems the PHP apcu apt package is built incorrectly. It has the module for PHP 8.1 instead of 8.0. I'm not sure if these are related, but probably. (https://bugs.launchpad.net/ubuntu/+source/php-apcu/+bug/1957261)
I haven't tried installing yet, but I did discover php-apcu-bc APCu Backwards Compatibility Module. Can that work?
That is indeed different. apc is an older extension that was replaced by apcu, however, not all apc functions are supported in apcu, and the apcu-bc extension adds the missing pieces. This is only really relevant for legacy apps running on newer PHP versions, as apcu has been around for a long time now, and some of what the old extension did provide is now handled by zend opcache, which is newer/better.
I wonder if they will fix this. After all, the bug is so far only affecting two people...
What about installing from pecl/pear (I never know the difference) until it's fixed?
How should we post issues or questions on this release? For example, I just ran apt upgrade and am greeted with a dialog box I don't recall seeing before:
┌─────────────────────────────┤ Configuring opendmarc ├──────────────────────────────┐
│ │
│ The opendmarc package must have a database installed and configured before it can │
│ be used. This can be optionally handled with dbconfig-common. │
│ │
│ If you are an advanced database administrator and know that you want to perform │
│ this configuration manually, or if your database has already been installed and │
│ configured, you should refuse this option. Details on what needs to be done │
│ should most likely be provided in /usr/share/doc/opendmarc. │
│ │
│ Otherwise, you should probably choose this option. │
│ │
│ Configure database for opendmarc with dbconfig-common? │
│ │
│ <Yes> <No> │
│ │
└────────────────────────────────────────────────────────────────────────────────────┘
This is after a fresh install, no edits, yet, and not a restore.
Maybe we should have a v60 milestone?
Yes, please post issues with this PR here.
I have no idea what that opendmarc configuration dialog is about, so I don't have any response to that now, but we'll have to figure it out eventually. Installing apuc from pecl/pear is a good idea and a fine workaround so we can keep developing this PR, but with luck Ubuntu will fix that before April.
Good evening, is the quota in mailinbox will be integrate for ubuntu 22.04 version?
Best,
FWIW
Everyone has probably realized by now that jammy will ship with PHP 8.1, not 8.0 so the apcu issue should go away. However Nextcloud does not currently support 8.1:
https://github.com/nextcloud/server/issues/29287
Roundcube also appears to lack support for 8.1 because the test matrix for the 1.5 branch only includes php up to version 8.0, but master includes 8.1. No specific bug or issue that I could find, though. I did not check the Roundcube plugins.
For Roundcube it looks like in the 1.6-beta milestone the PHP 8.1 tasks are complete with one still open in 1.6-rc milestones.
A quick skimming of the plugins and I didn't see any open issues or PRs mentioning 8.1.
Has anyone seen this before in Ubuntu? This is after running apt-get -qqy upgrade:
Package configuration
┌────┤ Daemons using outdated libraries ├─────┐
│ │
│ │
│ Which services should be restarted? │
│ │
│ [ ] dbus.service │
│ [*] dovecot.service │
│ [*] multipathd.service │
│ [*] named.service │
│ [ ] networkd-dispatcher.service │
│ [*] nginx.service │
│ [*] nsd.service │
│ [*] ntp.service │
│ [*] opendkim.service │
│ [*] packagekit.service │
│ [*] php8.0-fpm.service │
│ [*] polkit.service │
│ [*] [email protected] │
│ [*] rsyslog.service │
│ [*] ssh.service │
│ [ ] systemd-logind.service │
│ [*] udisks2.service │
│ [ ] unattended-upgrades.service │
│ [*] upower.service │
│ [ ] [email protected] │
│ │
│ │
│ <Ok> <Cancel> │
│ │
└─────────────────────────────────────────────┘
Maybe need to document something for new users.
Everyone has probably realized by now that jammy will ship with PHP 8.1, not 8.0 so the apcu issue should go away. However Nextcloud does not currently support 8.1:
Uh oh. It's actually much worse for us than that. Since Nextcloud only (officially) supports upgrades from consecutive versions, we need there to be two consecutive versions that support PHP 7.2 (which we have on Ubuntu 18.04 now) and PHP 8.1. Nextcloud 20 is the last version to support 7.2. (We have that version on Mail-in-a-Box now.) So unless Nextcloud backports PHP 8.1 support to Nextcloud 21 (unlikely, since they're up to 23) or backports PHP 7.2 support to any of the newer versions (even less likely), we can't perform the upgrade. So this is very bad.
I'll wait a bit to see if Ubuntu changes course and goes back to PHP 8.0, but if they proceed with 8.1 what we'll have to do is release a new version for Ubuntu 18.04 that adds a PHP PPA and install 7.3, 7.4 or 8.0. (Even 7.3 would be enough to move to the current latest version of Nextcloud and presumably would be lower risk than installing 8.0, so it would probably be 7.3.)
Sury several years back Sury started making all of the packages so that even the main repo won't interfere with each other (e.g., php7.2-fpm.sock, php7.3-fpm.sock, etc.) If php is invoked from command line, that has to be configured using update-alternatives --set php /usr/bin/phpx.x.
IMHO, it seems unlikely php 8.0 would be included with jammy because it would leave just 6 or 7 months of active php support assuming an April release.
https://www.php.net/supported-versions.php
It might be worth removing haveged in this PR.
Doing some research on it's relevance today it seems like the consensus even from the developer is newer kernels don't need it: https://github.com/jirka-h/haveged/issues/57
Given 22.04 will ship with kernel 5.15, I think this dependency can be removed and streamline things ever so slightly.
It might be worth removing haveged in this PR.
Nice catch. I'd happily accept a PR to this branch removing it. (If no one does it, I will.)
FWIW, I ran php static analyzers phan and phpcompatibility against the three roundcube plugins (html_notifier, rcmcarddav, and persistent_login). Phan only does backward compatibility checks, so not that useful and unfortunately phpcompatibility does not yet support php 8.1. Anyway, no compatibility issues were found at least up to php 8.0 for those plugins.
I don't see any compatibility checks for php 8.1, or at least it's not listed in the rulesets section of exakat doctor:
exakat :
executable : /usr/src/exakat/exakat-2.3.0.phar
version : 2.3.0
build : 1265
exakat.ini : ./config/exakat.ini,
test/config.ini
graphdb : gsneo4j
reports :
rulesets : CompatibilityPHP53,
CompatibilityPHP54,
CompatibilityPHP55,
CompatibilityPHP56,
CompatibilityPHP70,
CompatibilityPHP71,
CompatibilityPHP72,
CompatibilityPHP73,
CompatibilityPHP74,
CompatibilityPHP80,
Analyze,
Preferences,
Appinfo,
Appcontent,
Dead code,
ClassReview,
Performances,
Security,
Custom,
Inventory,
Stats,
php-cs-fixable,
Rector
extra rulesets :
ignored rules :
tokenslimit : 100 000 000
stubs :
PHP :
binary : 7.4.11
memory_limit : -1
short_open_tags : Off
ext/curl : Yes
ext/hash : Yes
ext/phar : Yes
ext/sqlite3 : Yes
ext/tokenizer : Yes
ext/mbstring : Yes
ext/json : Yes
ext/xmlwriter : Yes
pcre.jit : On (Must be off on PHP 7.3 and OSX)
java :
installed : Yes
type : OpenJDK Runtime Environment (build 11.0.8+10-post-Debian-1deb10u1)
version : openjdk
$JAVA_HOME : <none>
$JAVA_OPTIONS :
tinkergraph :
configured : No tinkergraph configured in config/exakat.ini.
tinkergraphv3 :
configured : No tinkergraph configured in config/exakat.ini.
gsneo4j :
installed : Yes (folder : /usr/src/exakat/tinkergraph)
host : 127.0.0.1
port : 8182
gremlin version : 3.4.8
neo4j version : 3.2.3
gsneo4jv3 :
configured : No gsneo4jv3_folder configured in config/exakat.ini.
nogremlin :
installed : Always
project :
name : html5_notifier
url : projects/html5_notifier
phpversion : 7.4
reports : ""
rulesets : CompatibilityPHP53, CompatibilityPHP54, CompatibilityPHP55, CompatibilityPHP56, CompatibilityPHP70, CompatibilityPHP71, CompatibilityPHP72, CompatibilityPHP73, CompatibilityPHP74, CompatibilityPHP80, Analyze, Preferences, Appinfo, Appcontent, Dead code, ClassReview, Performances, Security, Custom, Inventory, Stats, php-cs-fixable, Rector
included dirs :
ignored dirs : /assets, /cache, /css, /data, /doc, /docker, /docs, /example, /examples, /images, /js, /lang, /spec, /sql, /test, /tests, /tmp, /version, /var, /vendor, /vendor, /vendor
ignored rules :
file extensions : php, php3, inc, tpl, phtml, tmpl, phps, ctp, module
folders :
projects folder : Yes
php74 :
configured : Yes (/usr/local/bin/php)
actual version : 7.4.11
auditing : with this version
That's odd, as it definitely exists! Docs for it start here: https://exakat.readthedocs.io/en/latest/Reference/Rulesets.html#ruleset-compatibilityphp81
I note that the output you posted is from an old version 2.3.0; it's currently at 2.3.6.
Further complication - Roundcube 1.6 will no longer support PHP 7.2.
See:
https://github.com/roundcube/roundcubemail/issues/7976 https://github.com/roundcube/roundcubemail/blob/master/CHANGELOG.md
Go for it. :)
Right now, Nextcloud doesn't appear to be installing correctly and it seems the PHP apcu apt package is built incorrectly. It has the module for PHP 8.1 instead of 8.0. I'm not sure if these are related, but probably. (https://bugs.launchpad.net/ubuntu/+source/php-apcu/+bug/1957261)
I did report the apcu bug. They fixed it kinda with a php8.1 package so we're screwed. Also, an apt-get dist-upgrade will upgrade php to 8.1 even if you installed php8.0 and some 8.0 packaged are phased out (php8.0-fpm in particular) so I installed ondrej PPA and changed the source file to impish (no jammy Release file so...) and it did the trick. I'll probably revert to Ubuntu repos once I have a php8.1 compatible Nextcloud release.
Have we checked whether Z-Push plays nicely with PHP 8.1 yet? Looks like globally their last commit was ~8 months ago (https://stash.kopano.io/projects/ZHUB/repos/z-push/commits), and their last "official" release was a year ago (https://z-push.org/z-push-2-6-2-final-released/)
FWIW, here is a script that will upgrade Nextcloud using docker that does not require installing parallel versions of php or using update-alternatives.
It seems to work well with two downsides. 1. it requires about 1.5GB of free hard drive space, and 2. the local Nextcloud will no longer work since it no longer supports php 7.2.
For 2, if the script is run after a jammy system upgrade (probably multiple times to upgrade to a version of Nextcloud that jammy supports), then it's no longer a problem.
One upside is that the upgrade could be performed on a different computer from the one mailinabox is installed on - you'd just have to grab copies of /usr/local/lib/owncloud and /home/user-data/owncloud, then run the script, then copy the /home/user-data/owncloud files back.
Just another possibility for getting Nextcloud upgraded.
DOCKER-NEXTCLOUD-UPGRADE.sh
#!/bin/bash
#
# upgrade Nextcloud to version 21 using Docker on a Ubuntu 18 computer
# that has php 7.2
#
# Background: Nextcloud 21 requires php 7.4 or 8.0 and Ubuntu 18
# (bionic) system's only have php 7.2. This script uses docker and the
# official Nextcloud images on docker hub to upgrade the config, files
# and database and does not require installing parallel php versions
# or using update-alternatives.
#
# the script is hard coded for Nextcloud 21, but it could easily
# upgrade any version of Nextcloud
#
# after the upgrade is complete, your local Nextcloud will no longer
# work because the Nextcloud database and config have been upgrade to
# Nextcloud 21, but the local Nextcloud web files are still Nextcloud
# 20
#
# after upgrading, you can restore the database and config using the
# "restore" argument
#
# IMPORTANT: this script is still a work-in-progress and is not
# intended to be run on production systems
#
# Run it from the root of your mailinabox installation.
#
source /etc/mailinabox.conf
source setup/functions.sh
if [ "${1:-}" = "restore" ]; then
BACKUP_DIRECTORY=$STORAGE_ROOT/owncloud-backup/$(ls $STORAGE_ROOT/owncloud-backup | tail -1)
cp $BACKUP_DIRECTORY/config.php $STORAGE_ROOT/owncloud/config.php
cp $BACKUP_DIRECTORY/owncloud.db $STORAGE_ROOT/owncloud/owncloud.db
sudo -u www-data php /usr/local/lib/owncloud/occ maintenance:mode --off
systemctl start cron
exit 0
elif [ "${1:-}" = "destroy" ]; then
CONTAINER_ID=$(docker ps --last 1 -q)
if [ ! -z "$CONTAINER_ID" ]; then
set -e
echo "Destroy container $CONTAINER_ID"
docker stop $CONTAINER_ID
docker rm $CONTAINER_ID
fi
exit 0
fi
if [ ! -x /usr/bin/docker ]; then
apt install -y docker.io
fi
docker pull nextcloud:21
# prevent the local nextcloud cron job from running and put the local
# server in maintenance mode
echo "Stop host's cron service to prevent the Nextcloud cron job"
systemctl stop cron
echo "Turn on host's Nextcloud maintenance mode"
sudo -u www-data php /usr/local/lib/owncloud/occ maintenance:mode --on
# make a backup of config.php and owncloud.db
echo "Backup host's config.php and owncloud.db"
BACKUP_DIRECTORY=$STORAGE_ROOT/owncloud-backup/$(date +"%Y-%m-%d-%T")
mkdir -p "$BACKUP_DIRECTORY"
cp $STORAGE_ROOT/owncloud/owncloud.db $BACKUP_DIRECTORY
cp $STORAGE_ROOT/owncloud/config.php $BACKUP_DIRECTORY
# create a docker container running Nextcloud 21
echo "Creating docker container"
docker run -d --network=none -p 127.0.0.1:8080:80 -v $STORAGE_ROOT/owncloud:$STORAGE_ROOT/owncloud nextcloud:21
CONTAINER_ID=$(docker ps --last 1 -q)
echo "CONTAINER_ID=$CONTAINER_ID"
# install our config.php
sleep 5
echo "Install config.php"
docker exec $CONTAINER_ID /bin/ln -sf $STORAGE_ROOT/owncloud/config.php /var/www/html/config/config.php
# copy our apps
echo "Copy calendar app"
docker cp /usr/local/lib/owncloud/apps/calendar $CONTAINER_ID:/var/www/html/apps/
echo "Copy contacts app"
docker cp /usr/local/lib/owncloud/apps/contacts $CONTAINER_ID:/var/www/html/apps/
# user_external >=2.1.0 is required for Nextcloud 21
echo "Install user_external app"
version_user_external=2.1.0
hash_user_external=6e5afe7f36f398f864bfdce9cad72200e70322aa
wget_verify https://github.com/nextcloud/user_external/releases/download/v$version_user_external/user_external-$version_user_external.tar.gz $hash_user_external /tmp/user_external.tgz
docker cp /tmp/user_external.tgz $CONTAINER_ID:/var/www/html/apps/
docker exec --user www-data --workdir /var/www/html/apps $CONTAINER_ID tar xf user_external.tgz
docker exec $CONTAINER_ID rm /var/www/html/apps/user_external.tgz
# perform the upgrade
echo "Perform Nextcloud upgrade"
docker exec --user www-data $CONTAINER_ID php occ upgrade
# remove this unwanted config setting made by the upgrade
echo "Clean up config.php"
docker exec --user www-data $CONTAINER_ID php occ config:system:delete apps_paths
# destroy the container and remove the image
echo "Destroy container $CONTAINER_ID"
docker stop $CONTAINER_ID
docker rm $CONTAINER_ID
echo "Remove image"
docker image rm nextcloud:21
What about working with the Nextcloud's All In One official docker image here. I know its still beta but I think it would work and keep things seperate.
https://github.com/nextcloud/all-in-one
I opened up a feature request for a mail server. I think it would be a great merge and docker keeps things separate and clean
https://github.com/nextcloud/all-in-one/issues/68
