cookie_prefix should be set to prevent Galaxy's session cookies from clobbering each other if running more than one instance of Galaxy in different subdirectories on the same hostname."

Now, in my previous install I obviously didn't pay attention close enough to what setting cookie_path (as opposed to leaving it commented out) did, because I _do not_ have multiple galaxy sites running behind my proxy, just one, although I am using Apache as the local "proxy" with XSendFile and all that other configuration.

The funny thing is, setting "cookie_path = /galaxy" did nothing to harm my old install although I technically did not have multiple sites. However as soon as I migrated those settings over to the newest release of galaxy having that cookie_path setting enabled caused an odd behavior of _authenticating a user successfully_ but not actually letting them log in (thus no history, datasets, etc.). I still have the first three 'use', 'prefix', and 'filter-with' settings set exactly as shown above, but I had to comment out cookie_path to get my login functionality back.

What exactly is the root issue behind that which causes that behavior?

On Mon, May 7, 2012 at 10:59 AM, Josh Nielsen <jnielsen@hudsonalpha.com> wrote:

Hello all,

I recently tried moving from a tarball install of Galaxy to a Mercurial managed one, and in the process something went wrong with the database upgrade. I had intended to install the Mercurial-based Galaxy separately (though on the same machine) and then move it to production once it was working but it installed in-place over the current database while it was still completely active/up and running. That broke my existing Galaxy install and I had to move to the new install immediately. I recall having to run the Mercurial install's run.sh script multiple times though because the upgrade sequence (looked like 87->88, 88->89, etc. as it progressed) did not complete all the way the first time. I also ran it as root when I probably should have done it as our galaxy user. Long story short now I cannot log in to Galaxy even though Galaxy recognizes correct credentials from the database. My debugging so far has not yielded any results.

At this point after a week of unsuccessful attempts to repair the existing install I just want to create a fresh database and migrate over our users' history and dataset (and possibly login credentials) information stored in the database to the new one, if at all possible. Could someone give me any guidance as to how to do that, and which table files (MYI, MYD, etc.) that I should copy over into the new mysql database to make that happen?

P.S. I do have to thank Dannon Baker for helping me so far through private email correspondence to try to figure out what went wrong with the current install. However I'm not having any breakthroughs and our local Galaxy mirror has been down for over a week now and I just want to start fresh and migrate over critical data if possible.

Thanks for your help,
Josh Nielsen