Salient Soft

Update 18/10/2019 – file permission issue after unzip of new version

I upgraded to 2.22.1.  When the install zip was unzipped on the server, all the files and directories had group write access. This was not the case for previous installs/upgrades, and I was not clear on the cause.
This causes the upgrade script to fail, as the version of PHP in use disallowed the scripts from running with this permission present.

To remedy this I tried changing the permissions a directory at a time in the CPanel file manager but this was very time consuming.

I then tried to connect via SSH to the CPanel hosting, but this failed and timed out. It should be possible to enable it in Cpanel as per here but the Zen CPanel does not have this and does not seem to allow it.
The Zen support boards did not have anything on this either.

In the end I found that FileZilla can do it as per this post here.
It can recurse subdirectories, and also crucially all the check boxes are tri-state so they can either be “force on“, “force off“, or “leave as was“, so I could use the same recurse to fix both directories and all files to remove group write but leave everything else alone, given that other directory permissions are different to those of files and I didn’t want to mess with them.

This worked fine, and allowed the Mantis install script (which also does upgrades) to run.

When upgrading, the script helpfully does a precheck of requirements for the upgrqade. It said that a db type in the config script of ‘mysql’ was legacy and not supported in the zen configuration, so it said to change this to ‘mysqli’ in the config_inc.php file.
This then passed all the prechecks and the upgrade ran quickly and cleanly.

Original Version

This is fairly straight forward (apart from the database permissions issue below) and is documented here.

For additional information about initial installation of MantisBT see here.

The steps I performed were as follows:-

1. Backup the site including the MySQL databases
2. Rename the existing Mantis installation on the site to another folder for easy backout.
3. Upload the installation zip to the site, and unzip.
4. Rename the unzipped directory to the desired target name (in my case, mantis)
5. Copied the config_inc.php from the old installation to the new one. Note that in my case the config had been moved in the new version to a config subfolder under the installation directory.
6. Compared the copied config_inc.php with the sample one in config_inc.php.sample, to reconcile any config changes in the new version. In my case, going from version 1.2.4 to version 2.1.0, I had to add an entry for $g_crypto_master_salt which was not present in the old version. To create the salt I used the WordPress salt creation site here as Mantis did not have a convenient one, and it was not straightforward to create a random salt under windows.
7. Run the database upgrade script (see note below about permission issues).
8. I also used the Directory Privacy option under cPanel to force a username and password to allow access to Mantis (in addition to the login that Mantis provides). Note that when renaming the existing Mantis installation in step 2/ the existing directory privacy settings moved with the renamed directory.

Database fails to upgrade database due to permission errors

This was found when upgrading from 1.2.4 to the latest version at the time, 2.1.0.Running the upgrade database script gave errors on alter table commands, even though the user for that particular hosted database had full permissions. The solution was to use the overall master account for database access, which allowed the script to run. This is described in more detail here.

No Comments »

cPanel MySQL access is provided by the phpMyAdmin application.

When creating MySQL databases for different applications, each get their own database schema and user, but their is also a master user which has the same username and password as the cPanel hosting (in my case, swoodley/…..).

This is relevant as I have found during upgrading some hosted software where a database upgrade script needs to be run, sometimes the script fails when run under the username for the specific schema with permission errors e.g. on alter table, even though the user has full permissions. This occurred in particular when upgrading Mantis BT. This appears to be because the script in question contains specific database schema references when referring to tables, of the form mydb.tablename. This kind of reference fails when run using the login account for the particular database schema.

Logging in using the master user solved the problem. It may be that modifying the script to take out specific schema references may then allow it to work with the schema/database account rather than the master one. However, this was not necessary in my case.

No Comments »