Hello everyone, thanks for looking at the problem, here's a mor complete copy of our NGINX config :
As you can see, there are two differences :
1) we don't use the AUTH PAM module, but our own (a lua script), this should not (at least in theory) make a difference, since both modules merely set a value to a variable that sets the value to the REMOTE_USER header.
2) The proxy_pass directive is done *after* calling the 4 calls to proxy_set_header,
Both configs set the headers :
proxy_set_header REMOTE_USER "$loginOnHost";
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-URL-SCHEME https;
We will setup a proxy instance that does not do authentication (always sets the variable to a hard coded REMOTE_USER), and see if the problem persists.
Meanwhile if you could confirm that you are using this mechanism :
http://pythonpaste.org/modules/auth.cookie.html
If yes, could the problem be that "REMOTE_SESSION" is being changed at everyt call ?
if yes, I would suspect that the code on paste and or galaxy that does the "create session if none already exists" is the culprit, in this case it would be useful to debug this code, and/or add logging and/or tracing. Any pointers as to what log level to add or where in the code the decision to "create a REMOTE_SESSION if none exists " would be appreciated..
Thanks !
This sounds familiar enough that it may have been a bug I fixed previously. What revision of Galaxy are you running?
I am running a June 2, 2014 Galaxy Distribution .
Although I intend to update my code, I presently cannot update the prod version.
I was just wondering if it would be an simple fix/config that I could apply to this version, while I prepare the upgrade.
Thanks
I can't find the actual changeset I'm thinking of, but this wasn't a simple configuration change unfortunately. I'd recommend performing a full update in the near future, considering the recent security release.
Hi Dannon,
Thank for looking into this for me.
I installed all security updates so far, including the latest Jan 13th 2015.
I am planning on an update, but since this Galaxy is already in prod I was trying to modify what is there.
I've tried to update from my version to the latest (in a VM) and too many things went wrong. So I will probably go for a fresh install.
Thank you very much
Got it, I'm glad you installed the security updates.
If you could detail what went wrong with your last distribution update, I'd really, really like to hear it. We're trying very hard to make these updates as smooth as possible.
HI Dannon,
Yesterday I posted an answer for you about the update but I can't see it. So here it goes again.
The Problem was not the update process itself but how we have everything set up here.
Here in Canada we have a project called GenAP which aims to host Genetics and Genomics tools. Galaxy is one of the (the most important one).
In GenAP a PI can request his private Galaxy as if he was in a cloud facility. But he is actually starting a chroot of our 'master' VM in another VM that is a submit node in our HPC.
Our Galaxies share a few directories, one of them being tool-data. So all .loc files and genomes are shared. This is what was causing problems during the update. The update process does not follow the symlinks and throws an error.
Yesterday after we exchange messages I tried to update one of my dev VMs, but before I rename the tool-data dir. After solving few conflicts the update worked :)
I will continue to test and I will have to learn some of the new config options but everything seems fine now.
Thank you very much for your help
Thanks for the update, I understand now; tat's an interesting setup!
Good to hear that everything went mostly smooth with the update. Don't hesitate to let us know if there's anything else we can help with.
Hi Dannon,
I upgraded a VM to the latest version and put it behind the proxy. Unfortunately this did solved the problem. I still get a new history each time I log in.
Any clue of what might be wrong?
Thank you very much
Well that's a bummer, I was really thinking this was a bug we'd fixed. So, can you elaborate on what headers validateGenapCookies.lua sets? Your configuration is somewhat different from the base setup here: https://wiki.galaxyproject.org/Admin/Config/nginxProxy
Hi Dannon,
My friend Maxime, who is responsible for the nginx configuration answered you below.
We also put Galaxy (new and old codes) behind a simplified version of the configuration and it still creates new histories.
One thing that we did not mention is that we are using https. Could that be the source of the problem?
One last question how can I get to decode the cookie? Maybe by looking at the cookie 'galaxysession' we can figure out what is not being passed to Galaxy.
Thanks a lot