Upgrading / Replacing Nextcloud Jail to newer version using Script - Internal Server Error

[GJSchaller]

I'm currently running a Jail with Nextcloud and PHP 8.0, as set up by the excellent @Dan B about a year ago. So far, so good.

Over time, Nextcloud has updated itself to newer versions (currently on 26), but the base jail has remained the same, running PHP 8.0. I wanted to try to get the Jail up to a newer version of PHP, and figured the best way to do this was to delete the jail and reinstall it, using the current version of the script which would handle bug fixes and the newer version of PHP.

When I did this, the Nextcloud site gives an Internal Server error, instead of the site working. I have a backup copy of the original script, which I was able to use to re-create the jail running PHP 8.0, so the site is back online without issue.

Any guidance on why the new script wouldn't work with the existing Files / DB / Config? Are there steps I need to take to prepare those resources for the new Jail & software versions, maybe?

 

[Apollo]

I try not to delete existing jails unless I have been able to recreate the same setup in a different jail.
The important thing to remember is to make sure you have snapshots of the jails.
I have several Nextcloud instances running in several jails and I usually perform the update on the less critical one.
When I tried to upgrade php to 8.1 and installing the missing packages, it failed and rendered my jail useless.
I tried to perform a reinstall of the previous version of php and still no success. One of the openSSL module is no longer available as it has been integrated as part of PHP.
At that point, I stopped the jail and reverted the changes by rolling back from the most recent snapshot which was taken prior to me performing the update.
I restarted the jail and I was back in business.
I proceeded with another attempt at updating PHP to and this time it worked. I updated Nextcloud (using the manual update approach) and installed one of the missing php module.
For some reason I couldn't make it work with php8.2 so I left it to php8.1.
I did proceed in the same manner with the other jail instances of Nextcloud.

The key point to remember is to make sure snapshots exists for the iocage jails prior to making any modification to it, this way, if something goes terribly wrong, at least it is possible to perform a rollback.
I don't recall having experimented with jail replication, but that would normally be doable.

 

[GJSchaller]

I try not to delete existing jails unless I have been able to recreate the same setup in a different jail.

Dan's scripts make this moot (which is a good thing) - the data, config files, and DB are all stored outside of the Jail itself, so in theory you can delete the jail, run the script, and it'll create a new jail with all of the new packages / settings in the creation script. This works - it's how I was able to re-create my jail quickly using an older version of the script that still worked.

The challenge is, when running the new script, Nextcloud is giving an internal error rather than picking up all of the settings from the existing config, and I need to roll back to the older script.

 

[victort]

I have also run into this issue. Upon further investigation I have discovered this.

In the config file /mnt/mypool/nextcloud/config/config.php there is an option called 'dbhost'
This option is set to 'localhost:/tmp/mysql.sock' in one of my older installations.

In the newer installation it is set to 'localhost:/var/run/mysql/mysql.sock'

Can you try reinstalling and changing that value to see if it works for you?

I changed it and it worked.

In the script instructions, it sets itself to /tmp/mysql.sock when choosing postgresql and /var/run/mysql/mysql.sock when choosing mariadb.

I have always run it as mariadb, so I don't really know where the issue is happening in the script.

 

[victort]

I have also run into this issue. Upon further investigation I have discovered this.

In the config file /mnt/mypool/nextcloud/config there is an option called 'dbhost'
This option is set to 'localhost:/tmp/mysql.sock' in one of my older installations.

In the newer installation it is set to 'localhost:/var/run/mysql/mysql.sock'

Can you try reinstalling and changing that value to see if it works for you?
I changed it and got the same error.

I changed it back and it worked.

In the script instructions, it sets itself to /tmp/mysql.sock when choosing postgresql and /var/run/mysql/mysql.sock when choosing mariadb.

I have always run it as mariadb, so I don't really know where the issue is happening in the script.

I just discovered that in one of the recent mariadb updated, @danb35 now has the script set this option to /var/run/mysql/mysql.sock so I think if you would edit your config file to do the same, you should be good to go since a reinstall doesn't touch you config file.

EDIT: since the mariadb update on the script, it indeed looks like the value used to be set to /tmp/mysql.sock but the update will cause it to be set to /var/run/mysql/mysql.sock ONLY WHEN DOING A REINSTALL, so you will have to manually set it when reinstalling.

 

[victort]

On another note, you will have to do this next step in addition.

Up till now the script configured the .cnf file to be moved to /var/db/mysql/my.cnf

But the new install (because of MariaDB update) moves that same file to /usr/local/etc/mysql/conf.d/nextcloud.cnf (notice it also renames it)

So you will need to delete the file in /var/db/mysql/my.cnf BEFORE reinstalling or else the mysql-server won’t start during the install.

 

[GJSchaller]

That did it! Perfect, thank you so much!