Our original server is an openSUSE 12.3 machine running Pydio 6.0.8 ZIP archive install with PHP5; the data directory is in another location out of the web path. I dumped the axjp database to a file, performed a Pydio 6.0.8 ZIP install on a new server running openSUSE Leap 15 (which only has PHP7 available), imported the database into it and was unable to get the site to work because mcrypt isn’t available in PHP7.
I then created an interim server running openSUSE Leap 42.3 with PHP5. I installed Pydio 6.0.8 on it, imported the database from the original server and successfully upgraded it to Pydio 8.2.1.
Now I’m stuck: the in-app upgrade to Pydio 8.2.2 fails on the interim 42.3/PHP5 server. If I dump the database and import it to the Leap 15/PHP7 server with a fresh install of Pydio 8.2.1, the users and workspaces look to be there, but all the shares appear to be gone.
I’ve made some progress with this by copying some of the data/plugins folders from the original server over to both the interim Leap 42.3/PHP5 server and the new Leap 15/PHP7 server. I think one of the main kickers was the metastore.serial folder.
Now the workspace shares appear, but if I log in as one of the users who had access to a workspace share on the original 12.3/PHP5 server, and try to access the workplace share, I get a “Missing user in node URL” error and I don’t really have access.
If I remove the share, and create a new share with that same user, that user can then access the workspace.
Anybody have any thoughts on this?
More progress! I’ve apparently solved the “Missing user in node URL” issue. The old original openSUSE 42.3/PHP5 server started out at AjaXplorer 5.x and has slowly been upgraded over the years. The original data path for AJXP_DATA_PATH was “/srv/ajaxplorer/data.” When I built the new interim openSUSE 42.3/PHP5 and openSUSE Leap 15/PHP7 servers, I used different folder paths for the data folder and inserted those different locations in the definition lines for AJXP_DATA_PATH in the bootstrap_context.php files.
Well, evidently, somewhere in the database and/or PHP information that “/srv/ajaxplorer/data” path still exists and my new AJXP_DATA_PATH isn’t reflected. Changing the data folder path names on the servers to “/srv/ajaxplorer/data” via symbolic links or simply renaming the folders solves the public links shares and worksplace shares issues.
So, I have running Pydio 8.2.1 on both the newer servers. However, when I try to upgrade from 8.2.1 to 8.2.2 on the openSUSE 42.3/PHP5 server it says the update was successful but I get a warning to check my server logs. The apache2 log error says this:
[Fri Nov 02 09:41:03.745867 2018] [php5:error] [pid 3786] [client 10.x.x.x:34412] PHP Parse error: syntax error, unexpected ‘function’ (T_FUNCTION), expecting identifier (T_STRING) or \\ (T_NS_SEPARATOR) in /srv/www/htdocs/pydio/core/vendor/zendframework/zend-diactoros/src/functions/marshal_headers_from_sapi.php on line 10, referer: http://myserver.mydomain.com/pydio/index.php/settings/admin/action.updater
When I exit the website and try to log in again I get a blank window in the browser.
Any ideas … anyone?
I’ve been successful with my upgrade!
I saw a note that PHP 5.6 was the minimum required for Pydio 8 Enterprise, and apparently the last version available on openSUSE 42.3 was 5.5.14. I uninstalled the PHP 5 modules and installed the following PHP 7.0.7 modules:
php7-sqlite (this may not be needed if using Mysql)
I did get a server error after the upgrade, but I researched this forum and discovered when using PHP 7.0.7, in the …/data/plugins/boot.conf/bootstrap.json file, right after the “mysql_username”:"" line, I needed to add the line: “mysql_use_mysqli”:“true”. Restarting the web server after that edit resulted in a running Pydio 8.2.2 server.
With PHP 7.2.5 on openSUSE Leap 15 it appears that the mysqli line in the bootstrap.json file has already been included, so I simply made sure the PHP 7 modules, above, were installed. The Pydio 8.2.1 -> 8.2.2 update then went off with a hitch so it appears I now have my Pydio 8 server fully operational.
Looks like this thread can be marked “Solved.”