Mantis Restore/Migrate fails // sql-user mantis wrong password

/usr/lib/inithooks/firstboot.d/20regen-mantis-secrets

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...

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.

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. 

APPLICATION ERROR #401
Database query failed. Error received from database was #1054: Unknown column 'p.inherit_global' in 'field list' for the query: SELECT DISTINCT p.id, ph.parent_id, p.name, p.inherit_global, ph.inherit_parent
FROM mantis_project_table p
LEFT JOIN mantis_project_hierarchy_table ph
ON ph.child_id = p.id
WHERE p.enabled = ?
ORDER BY p.name.

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.

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? 

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 the nslookup command can be useful (may require install on Mac & Linux; should be ready to go in Windows).

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

/var/www/webroot/NEW

Changed the user rights

chown -R www-data:www-data /var/www/webroot/NEW

ran 

http://host.ip/NEW/admin/install.php

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

mysqldump --opt -p -u root mantis > /media/nfs/db_mantis.sql

and applied it to a newly installed TKL14 Mantis installation

 mysql -u root -p mantis < /media/nfs/db_mantis.sql 

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. 

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.