“* Upgrade your existing Ubuntu 14.04 Mail-in-a-Box to version v0.30 first. This is mandatory and relates to limitations in the PHP versions supported by ownCloud/Nextcloud database migrations.This step is no longer possible because PHP maintainers have discontinued support for PHP packages for Ubuntu 14.04. If you have not used any Nextcloud features — contacts, calendar, shared files, etc. — it is possible to skip this step. If you have used any Nextcloud features, you will not be able to smoothly upgrade using these instructions. Please open a new topic on this forum for help.”
I find myself in exactly this situation.
Where there is extensive use of all Nexcloud functions (cloud storage, Caldav, Carddav) with many domains …
Is there a way, even with manual steps, to go about solving PHP limitations?
If you did not regularly do upgrades, you will need to change the PPA’s to the archive PPA’s that Ubuntu manages. This MAY help…
From there you are going to have to install each old version which has a NC upgrade one at a time, after you move to Ubuntu 18. There is a thread on this buried somewhere. All in all this is going to take you SEVERAL hours to accomplish.
If you didn’t have NC data, this would be easy using an alternative method. NC is what is going to make this difficult.
Then you try to make sure you can install all those packages, from other repository, manually. After installation, maybe try manually removing those lines before running your set up again, so that it will skip the apt installs (if not your setup will probably halt since they cannot find the files in the distro)
I think that should work, but I don’t have an installation to try, so I can only point to you a direction and hopefully it works for you.
The gist of the matter is the installation of PHP version 7 in order to satisfy the requirements of the MIB 0.30. Now the “PHP limitations” mentioned in the update article are clearer.
Trying to run a test command something finds:
root @ box: / home / ubuntu # apt-cache search php7.0
php7.0-xsl - XSL module for PHP (dummy)
php7.0-fpm - server-side, HTML-embedded scripting language (FPM-CGI binary)
php7.0-xml - DOM, SimpleXML, WDDX, XML, and XSL module for PHP
php7.0-gd - GD module for PHP
php7.0-mcrypt - libmcrypt module for PHP
php-apcu - APC User Cache for PHP
php7.0-common - documentation, examples and common module for PHP
php-msgpack - PHP extension for interfacing with MessagePack
php-apcu-bc - APCu Backwards Compatibility Module
php7.0-intl - Internationalization module for PHP
php7.0-soap - SOAP module for PHP
php7.0-cli - command-line interpreter for the PHP scripting language
php7.0-zip - Zip module for PHP
php7.0-opcache - Zend OpCache module for PHP
php7.0-curl - CURL module for PHP
php7.0-readline - readline module for PHP
php7.0-json - JSON module for PHP
php7.0 - server-side, HTML-embedded scripting language (metapackage)
php7.0-pspell - pspell module for PHP
php7.0-imap - IMAP module for PHP
php7.0-dev - Files for PHP7.0 module development
php7.0-sqlite3 - SQLite3 module for PHP
php-memcached - memcached extension module for PHP, uses libmemcached
php-igbinary - igbinary PHP serializer
php7.0-mbstring - MBSTRING module for PHP
So you advise me:
Create a snaphot (before doing this I close the IMAP / POP / SMTP ports and the HTTP ports to public addresses, so that the data is not altered in the meantime).
What i’m saying is to create a snapshot of your server, then do whatever migration test you need on this cloned server, making sure all files are copied correctly etc, then you repeat the steps on your real server (with backups done as well) of course.
The suggestions above are not tested, and I have no where to test, which is the reason why I asked you to test with a clone first. Remember the steps, then take action on your real server if everything is working correctly.