Mantis Bug Tracker - Forums

I see that the forums, bug tracker, etc., contain entries related to:

APPLICATION ERROR #2900

For security reasons MantisBT will not operate when $g_crypto_master_salt is not specified correctly in config_inc.php or is shorter than 16 characters long.
Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.

After reviewing various "fixes" or "corrections", etc., I find I cannot resolve this error on a new installation of mantisbt-2.18.0, and can reliably reproduce the problem.

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.6 (Maipo)

Apache version 2.4.6

$ mysql --version
mysql Ver 15.1 Distrib 5.5.60-MariaDB, for Linux (x86_64) using readline 5.1

$ php --version
PHP 5.6.38 (cli) (built: Sep 13 2018 16:53:51)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
$ for ext in curl gd fileinfo my mbstring; do php -m | grep -i "${ext}"; done
curl
gd
fileinfo
mysql
mysqli
mysqlnd
pdo_mysql
mbstring

First the tarball was expanded in the web space.
Permissions are essentially user.apache such that all expanded files are readable by apache.
Next, write permissions for apache are added to the config folder.

I want to set the database user to something other than root and to use a more meaningful database name than bugtracker since I'm evaluating a number of bug trackers. I've tried to do this a number of ways:

1) I supplied both the database user/password to create and the admin user/password.

This spectacularly fails long before installation completes.

2) In addition to 1) above, the user and password were created ahead of time.

This spectacularly fails long before installation completes.

3) Then a a procedure that works for other similar applications:

CREATE USER 'mbtuser'@'localhost' IDENTIFIED BY 'password';
CREATE DATABASE mantisbt DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_bin;
GRANT ALL ON mantisbt.* TO mbtuser@localhost;

All results on Check and Install Database report GOOD.

The APPLICATION ERROR #2900 appears.

$ grep g_crypto_master_salt mantisbt/config/config_inc.php | awk -v FS="'" '{ print $1; print length($2); }' -
$g_crypto_master_salt =
44

It is clear the value is set, and to a sufficiently long value...

4) I gave up trying to set a custom user, so supplied only root/password for the first user/password set, and left the database name as the default value.

This naturally gives warnings on the second screen due to the optional "admin" password, and all other results are "GOOD".

The result is also that APPLICATION ERROR #2900 appears... though this time instead of

5) I supplied root/password for both user/passwords and left all other settings default.

Same results, though this time all GOOD.

Some helps online have bizarre "fixes" that do not appear to work:

1) chmod -R 777 the whole web space... WHAT! ... there are secrets in there! Nevertheless, I tried it to no avail.
2) Copy mantisbt/config_defaults_inc.php into config and back, though the exact process for doing this is not clearly identified. I've tried it by running phases of the install between file moves.

I have PHP's error_log set, but no error log is dropped by PHP.

/var/log/mysql logs are empty.

Surely this is a ridiculous error message to throw when the problem is clearly not that $g_crypto_master_salt is incorrect.

In any event, how to fix/troubleshoot this. I hate to cross mantisdb off the list just because it won't install successfully.

Yes, I've RTM: https://mantisbt.org/docs/master/en-US/ ... in.install.

Somehow for all that detail, omitted was the MantisBT version: 2.18.0.

Copious notes were taken throughout the troubleshoot endeavor. Between attempts, careful reset of the environment occurred... deleting any database user/database if one was one I created... removed the config/config_inc.php file between attempts, etc. At various points, the MantisBT files were completely removed from the web space and replaced with a fresh copy from the tarball. A password database was used to avoid password gaffs. The extent to which care was taken to perform steps was great. Where possible, mysql command history was used to assure consistent results.

So it is with great annoyance that upon trying one more time... after posting this thread... got APPLICATION ERROR #2900 again... used the back button... let the browser resubmit to reload the prior screen... reviewed all the green GOODs and absence of any warning, error etc... clicked the link at the bottom of the page, as done countless times before, and the login screen came up pretty as you please.

The error can no longer be reproduced... even by completely obliterating the install and carefully following the instructions written from the times that failed. No server reboot... no software installed...

Having taken great pains to make sure my install steps were not rushed and full of mistakes, other than if somehow the browser was caching something from initial failures, at this point there is no clear clue to what was wrong. In any event, it is working, and while glad of that, am also terribly annoyed at losing a day to the madness.

I assume the problem was caused by a PHP caching issue and that http://php.net/manual/en/book.opcache.php (or another opcache) is enabled on your installation.
If so, there are various settings that influcence if / when changed PHP code is executed.
Especially the following one could have caused your issue
http://php.net/manual/en/opcache.config ... idate-freq

hello,
have the same problem, while using sql server as database.

tried to read through various posts and tried to get some clues but nothing worked by now.

seems that the config_inc doesnt accept the salt-value i set, but i tried with another ones, and got the same error.

please help !