I discovered the source of all my problems and woes with being unable to
login after the upgrade: the cookie_path setting. I carried over all of my
previous site's old settings from the universe_wsgi.ini file and they
included the settings recommended on this page (
http://wiki.g2.bx.psu.edu/Admin/Config/Apache%20Proxy) which say:

"[filter:proxy-prefix]

use = egg:PasteDeploy#prefix
prefix = /galaxy

[app:main]
filter-with = proxy-prefix
cookie_path = /galaxy

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 <jniel...@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
>
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Reply via email to