Upgrading a Virtual Installation and Keeping My Data

Thanks again for providing the update to 1.72.

I am having trouble figuring out how to get the data that I have in my 1.71 install to the updated 1.72 virtual machine. I am running VMware Server 2.0.

I did find on the Tracks site the following documentation about upgrading:
http://bsag.github.com/tracks/upgrading.html

But, I think this applies to native installations, rather than virtual-ized installs. Is there documentation anywhere that would tell a novice admin, like myself, step-by-step how to move my data?

Hi,

It seems that is only necessary to import the data. You can create a mysqldump from the previous installation and then export the data in the new database:

$ mysqldump -u root -p bitnami_tracks > tracks_backup.sql

Then copy the “tracks_backup.sql” file to the new virtual appliance in the and run the following command:

$ mysql -u root -p bitnami_tracks < tracks_backup.sql

Usually it is necessary to run a migrate script but following the Tracks notes it seems that it is not necessary for upgrades from 1.71 to 1.72. I hope it helps.

Forgive my ignorance… I am having trouble copying the file over.

My 1.71 Tracks Bitnami VMware server is at: 192.168.0.252. My 1.72 Tracks Bitnami VMware server is at 192.168.0.247. I was able to create the tracks_backup.sql flie. From the VMware console on .252, I entered the following command:

scp tracks_backup.sql bitnami@192.168.0.247:tracks_backup.sql

Response:

ssh: connect to host 192.168.0.247 port 22: Connection refused
lost connection

Do I need to include the login info somewhere for the .247 server?

Hi,

SSH is not enabled by default in the Virtual Appliances for security reasons. You can enable it using the following notes http://bitnami.com/faq/virtual_machines

You can also copy it wihtout enabling it. You can use another machine which has the SSH enabled. For example:

From old machine:

scp tracks_backup.sql your_user@your_machine:

From new machine:

scp your_user@your_machine:tracks_backup.sql .

Another solution is copy the sql file to the Apache folder “/op/bitnami/apache2/htdocs” and you can download it “http://machine_ip/tracks_backup.sql” from any machine.

Hey,

Thanks again for your guidance. I made progress, but I am still not quite there. I was able to turn on SSH and transfer the file. I confirmed that tracks_backup.sql was on the new 1.72 virtual server (.247, in my case).

I ran the command you gave:
mysql -u root -p bitnami_tracks < tracks_backup.sql

I was prompted again for a password. I correctly guessed that I should enter: bitnami

After doing this, I get the command line back, with no message. Next, I tried to login to my 1.72 Tracks server and it would no longer accept the default user, or the user ID that I created on my 1.71 server. For sanity sake, I went back to my 1.71 server and was able to login with both the default and a user id that I created, on that 1.71 server.

Any ideas why I can’t use those same credentials to log in to the 1.72 server?

Hi,

Did you restart the server? Try to restart them:

$ cd /opt/bitnami
$ sudo ./ctlscript.sh restart

Hi,

I did try restarting my upgraded server through the VMware console but not with a command line instruction, like you posted above.

I ran the command line restart (as per above) and the server shut down and restarted. When I tried to authenticate my login attempts were again unsuccessful. I tried both the default login (u: user, p: bitnami) and a login that I had created for myself in 1.71 server.

Any other ideas?

Hi,

Not sure but it is possible that you have to run the migrate script:

$ cd /opt/bitnami/apps/tracks
$ rake db:migrate RAILS_ENV=production

I hope it helps

There is a small typo in the first command of your last post (just in case anyone else is reading this thread). The “7” should be a “/”. No big deal.

I ran the commands. I tried them on both my Ubuntu and Suse Tracks 1.72 virtual machines and got an error message back from both machines. I kind of expected this, since a 1.71 to 1.72 update does not have a database structure change. I am still unable to login to either 1.72 Tracks instance (SUSE or Ubuntu).

Because I am fairly non-technical, I really like running virtual servers: there is very little opportunity for me to make mistakes. Even if I manage to do something wrong, or there is a problem – either at time of an application upgrade or even days/weeks after the upgrade, I can revert back to my previous install, by turning on the old VM image… assuming, of course, that I can access my data and that my data is compatible with both versions, which might not happen all the time. Also, with this set up, I would also be able to back up my VM application install separately from my data, which is a good thing too, as the VM image should only change when there is a new version/bug fix.

I will post in the Tracks forum and ask if any of the developers have considered introducing a feature in the Tracks Admin interface, whereby an admin could specify a complete path (including a different server/IP, and the ability to provide credentials for that different server/IP) for the data.

Beltran, thanks for your help so far. Let me know if you have anything else you’d like me to try.

Thanks, I fixed the typo. Not sure what could be the problem, maybe Tracks developers points to the solution.

I am seeing the same problem. I have done lots of backup and transfers of the database form 1.7.1 to 1.71 systems, both physical and virtual, but I believe there is something different on the way that the data is stored in the database between 1.7.1 and 1.7.2

Since I need to have 1.7.2 up and running, I continue to work on this problem

OK I found the solution. The Salt variable needs to be changed in the file apps/config/site.yml. Look at the first line that has the Variable salt: “……….”

It looks like in the 1.7.1 version the bitnami version did nothing but left it to the default version of “change-me” and the 1.7.2 version it truly is a random number. A quick and dirty solution is to downgrade the salt to “change-me” and it worked perfectly

It would be nice to find a way to re-salt the database.

I used the following documentation to get to this solution:

http://bitnami.com/forums/forums/tracks/topics/…

OK, I got it up and running. The problem is that in the 1.72 version the salt variable is a random value, and in the 1.7.1 it was the default “change-me”

You just need to go to the file apps/tracks/config/site.yml in the new version. If you have changed the salt in your 1.7.1 then it needs to be the same as that value.

I used the following document for the solution:

https://github.com/bsag/tracks_manual/blob/8cb3…

I’m glad to hear you were able to fix it.

Thanks for posting the solution. This will help other bitnami users.