You are here
Max Fischer - Tue, 2016/01/19 - 00:39
Hi (again),
since you've been so helpful with the last report, I figured you could maybe help me with this one as well.
I have an old Mantis Turnkey Installation (TK12.0, Mantis 1.1.8), which I want to upgrade and also move from the local network to the cloud.
When opening the URL of the new instance (TK14.0, Mantis 1.2.19), I get the following error after the backup/migrate/restore process with tklbam.
APPLICATION ERROR #400 Database connection failed. Error received from database was #1045: Access denied for user 'mantis'@'localhost' (using password: YES). 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. Previous non-fatal errors occurred. Page contents follow. SYSTEM WARNING: 'mysqli_real_connect(): (28000/1045): Access denied for user 'mantis'@'localhost' (using password: YES)' in '/var/www/mantis/library/adodb/drivers/adodb-mysqli.inc.php' line 110
I guess it really is a no-brainer, but I have no idea where in the system (besides in the mysql db) I have to alter the password.
Can you give me a hint or probably point me to a solution?
Thanks in advance!
edit: typo
Forum:
As the error notes there is an issue with Mantis DB user creds
However there could actually be deeper issues... IIRC Mantis was previously installed from the Debian repos; but it was removed in Debian Jessie (what v14.0 is based on) so we installed it direct from upstream. This means that there is a possibility that some of the files are actually in the wrong place, although I'm not sure on that...
Bottom line is that the mantis config file is providing the correct DB user account (mantis) but the wrong password. Once you work out where this file is then you can adjust it to use the correct password. As I say though, there may still be further issues...
Actually now I think about it, I suspect that the old Mantis conf is in /etc (probably something like /etc/mantis.conf or /etc/mantis/mantis.conf) but the new one is within the Mantis webroot (/var/www/mantis). I suspect that it is using the credentials from the new (i.e. v14.0) mantis config file to access your old (restored) mantis DB. So depending on what files come across in the backup we mat need to exclude some files from your backup (and manually move some) to make it all work how it should...
I suggest that you do this work on a local VM for now so you don't have any cost pressures (of a running cloud server). Once you have it all sorted out; then you can do a TKLBAM backup of your fixed (v14.0) VM and it should all just work (v14.0 -> v14.0 should be really straight forward).
Regardless, let us know how you go...
Error #401 instead of #400
Hi Jeremy,
many thanks for your reply.
The script indeed worked! I ran it and a second later I could reach the frontpage of the mantis installation on tkl14.
But you where right with the suspected deeper issues. Now I'm getting this.
My experience in juggling SQL databases is zero, so I'm a bit lost.
My only idea would be to take the old tkl12 installation, put mantis 1.2.x on it and do the upgrade manually following this guide. Later, if successful, do a 'tklbam-backup' and see where this brings me in a tkl14 instance.
What do you think, could that work?
Apologies on slow response
Anyway I think that you should be able to do the upgrade on TKL v14.0 after restoring your backup. FWIW the v14.0 appliance includes Mantis v1.2.19.
So long as you do all your work in a VM; then even if you completely wreck things, worst case scenario reinstall the VM and restore the original TKLBAM backup again. Better still do a snapshot of the VM just after the TKLBAM restore (and perhaps as you go too) and return to a previous snapshot if/when you trash it.
As someone wise once said: "If you haven't broken it, you're not trying hard enough"! :)
Let me know how you go and I'll try to help as much as I can.
(nearly) SOLVED
so, where to begin ...
Me not really knowing TurnKey Linux started with the mistake of using a new TKL14 instance to restore my TKL12 backup to, with the intention to do the upgrade on the new vm. But of course the 1.2.19 install.php script is not able to proceed because the >Table 'mantis_plugin_table' already exists<, which is correct, because some *hooks of TKL here and there already tried the upgrade of my db scheme when applying the backup to TKL14.
So I kept on breaking it as hard as I could, and ended up with the following veeery simple steps.
Downloaded Mantis-1.2.19 and extracted it into
Changed the user rights
ran
followed the guide by entering my user credentials of the database and change the name of intended database from 'bugtracker' to 'mantis'.
After clicking 'Install/Upgrade' in my test phase I had to copy my older version of config_inc.php manually to NEW/ and add the part the guide was telling me to add. But in my final conversion the script was able to do by itself.
Now porting this upgraded database with tklbam-backup I ran into this issue which could be solved by following the instructions in the comments. Still the backup first failed with some errors (duplicity.Error: non-zero exitcode (30) [...]), but later proceeded succesfully. But ultimately the finally restored migrated version still had troubles (don't really remeber which ones), so I decided to do the most simplest thing of
creating a dump on the now upgraded TKL12 instance
and applied it to a newly installed TKL14 Mantis installation
and that's it. (using an existing NFS share on my network)
So really simple in the end: Download the new version, run the upgrade, create the dump, apply the dump.
All working fine now, except for the *.tklapp.com resolution. Don't know why.
Awesome!
As for tklapp.com resolution. In my experience many DNS providers cache DNS for way too long and sometimes updated DNS can take hours to propagate. I found that using Google Public DNS on the PCs where I access *.tklapp.com meant that the DNS updated within 5-10 mins.
As a first step I suggest that you run
hubdns-update
to see if there are any other issues. If that reports success then you can double check by using a third party DNS lookup tool. Many of the Whois providers also provide a DNS lookup service within the web browser. If you want to see what your computer is doing then thenslookup
command can be useful (may require install on Mac & Linux; should be ready to go in Windows).all working
Yes, I expected that, but I was irritated by the fact that nslookup already pointed to the correct IP. Anyway, now it's working, so I'll close this chapter for the moment.
Thanks for the help.
Add new comment