NGINX configuration for Galaxy production
Colleagues, I encountered a curious problem while configuring nginx as a proxy for Galaxy. I posed the question through Enis who forwarded it to one of the lists. I just want to share a solution to the issue, which could perhaps be documented in a small change to the http://bitbucket.org/galaxy/galaxy-central/wiki/Config/nginxProxydocumentati... page. The observed problem was that Galaxy proxied through NGINX would only display properly in Microsoft IE but not in Firefox or Opera. One of my colleagues noticed that a Firefox error console reported that the various cascading style sheets were observed as having MIME type "text/plain" not "text/css" hence, where not loaded by Firefox. Presumably IE assumed CSS file type by the context of retrieval but the other browsers were more strict. Anyhow, this suggested that although NGINX has a configuration file of MIME types associated with file extensions, the content-type wasn't being properly set. I don't know if this represents a bug in NGINX operations, but after perusing the NGINX wiki docs, I came across a directive that appeared to solve the problem: default_type. The "default_type" covers any files in a specified context (http, server, location) which don't otherwise have their MIME type recognized (for whatever reason) and is itself originally set "by default" to "text/plain", which may explain the observed error in content type sent back. What I therefore did is reset the default type, in the style sheet nginx "location" directive context, to "text/css". This appeared to work. In the nginxProxy wiki documentation page on BitBucket, somebody with editorial privileges to this page may wish to document this throughout the page where the style directives are documented , i.e. location /static/style { alias /home/nate/galaxy_dist/static/june_2007_style/blue; default_type text/css; # other directives... } Cheers, Richard Bruskiewich, PhD Senior Scientist, Computational and Systems Biology Applications Team for Computational Genomics T.T. Chang Genetic Resources Center International Rice Research Institute
Sorry... premature to announce this solution. It only partially fixes the Galaxy page display through the proxy NGINX server. If anyone has some specific insights on how to get this NGINX configuration correct, please kindly advise. Richard On Thu, Dec 2, 2010 at 10:01 AM, Richard Bruskiewich <r.bruskiewich@irri.org
wrote:
Colleagues,
I encountered a curious problem while configuring nginx as a proxy for Galaxy. I posed the question through Enis who forwarded it to one of the lists. I just want to share a solution to the issue, which could perhaps be documented in a small change to the http://bitbucket.org/galaxy/galaxy-central/wiki/Config/nginxProxydocumentati... page.
The observed problem was that Galaxy proxied through NGINX would only display properly in Microsoft IE but not in Firefox or Opera. One of my colleagues noticed that a Firefox error console reported that the various cascading style sheets were observed as having MIME type "text/plain" not "text/css" hence, where not loaded by Firefox. Presumably IE assumed CSS file type by the context of retrieval but the other browsers were more strict.
Anyhow, this suggested that although NGINX has a configuration file of MIME types associated with file extensions, the content-type wasn't being properly set. I don't know if this represents a bug in NGINX operations, but after perusing the NGINX wiki docs, I came across a directive that appeared to solve the problem: default_type.
The "default_type" covers any files in a specified context (http, server, location) which don't otherwise have their MIME type recognized (for whatever reason) and is itself originally set "by default" to "text/plain", which may explain the observed error in content type sent back.
What I therefore did is reset the default type, in the style sheet nginx "location" directive context, to "text/css". This appeared to work.
In the nginxProxy wiki documentation page on BitBucket, somebody with editorial privileges to this page may wish to document this throughout the page where the style directives are documented , i.e.
location /static/style { alias /home/nate/galaxy_dist/static/june_2007_style/blue;
default_type text/css; # other directives... }
Cheers,
Richard Bruskiewich, PhD Senior Scientist, Computational and Systems Biology Applications Team for Computational Genomics T.T. Chang Genetic Resources Center International Rice Research Institute
-- *Richard Bruskiewich, PhD* Senior Scientist, Computational and Systems Biology Applications Team for Computational Genomics T.T. Chang Genetic Resources Center International Rice Research Institute
Richard Bruskiewich wrote:
Sorry... premature to announce this solution. It only partially fixes the Galaxy page display through the proxy NGINX server.
If anyone has some specific insights on how to get this NGINX configuration correct, please kindly advise.
Hi Richard, Can you expand on what the remaining issue is? Thanks, --nate
Richard
On Thu, Dec 2, 2010 at 10:01 AM, Richard Bruskiewich <r.bruskiewich@irri.org
wrote:
Colleagues,
I encountered a curious problem while configuring nginx as a proxy for Galaxy. I posed the question through Enis who forwarded it to one of the lists. I just want to share a solution to the issue, which could perhaps be documented in a small change to the http://bitbucket.org/galaxy/galaxy-central/wiki/Config/nginxProxydocumentati... page.
The observed problem was that Galaxy proxied through NGINX would only display properly in Microsoft IE but not in Firefox or Opera. One of my colleagues noticed that a Firefox error console reported that the various cascading style sheets were observed as having MIME type "text/plain" not "text/css" hence, where not loaded by Firefox. Presumably IE assumed CSS file type by the context of retrieval but the other browsers were more strict.
Anyhow, this suggested that although NGINX has a configuration file of MIME types associated with file extensions, the content-type wasn't being properly set. I don't know if this represents a bug in NGINX operations, but after perusing the NGINX wiki docs, I came across a directive that appeared to solve the problem: default_type.
The "default_type" covers any files in a specified context (http, server, location) which don't otherwise have their MIME type recognized (for whatever reason) and is itself originally set "by default" to "text/plain", which may explain the observed error in content type sent back.
What I therefore did is reset the default type, in the style sheet nginx "location" directive context, to "text/css". This appeared to work.
In the nginxProxy wiki documentation page on BitBucket, somebody with editorial privileges to this page may wish to document this throughout the page where the style directives are documented , i.e.
location /static/style { alias /home/nate/galaxy_dist/static/june_2007_style/blue;
default_type text/css; # other directives... }
Cheers,
Richard Bruskiewich, PhD Senior Scientist, Computational and Systems Biology Applications Team for Computational Genomics T.T. Chang Genetic Resources Center International Rice Research Institute
-- *Richard Bruskiewich, PhD* Senior Scientist, Computational and Systems Biology Applications Team for Computational Genomics T.T. Chang Genetic Resources Center International Rice Research Institute
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Dear Nate and Galaxy community, Funny thing... I left the issue aside for a great many days, and turned back to other work on my desk. Finally, today, I rebooted my (shut-down) EC2 instance with the partial configuration I had set up, then started both NGINX and Galaxy up in the standard way, without modifying my "best" parameters... and pointed my Firefox web browser to the server (with its new ec2 host name, assigned by Amazon). Surprise! the interface now appears (on first glance) to work fine. All of the CSS files are processed and no incorrect MIME content type is reported. Thus, something appears to be fixed. I still suspect that the specific modification I made to the NGINX file may have helped and been useful, but that some kind of strange web / internet caching (perhaps against the old EC2 host name) may have interfered with full expression of the solution. Once again, the extra configuration I added to the NGINX configuration file, under the "server { ...}" block, was the following: location ~* /galaxy/static/style/(.*\.css.*)$ { alias /home/galaxy/galaxy-dist/static/june_2007_style/blue/$1; default_type text/css; expires 24h; } I'm using a subdomain directory "galaxy" but the paths may be adjusted by others to suit. Anyhow, at this point, I've heard a week or so ago that a fresh Galaxy EC2 cloud AMI may soon be released and (hopefully) cloned to AP-Southeast (for access by we poor Asian-hosted folks...). In which case, I probably can now focus on more data-centric configuration issues. Thanks again, Galaxy team, for a great platform! Cheers Richard On Wed, Dec 8, 2010 at 11:31 PM, Nate Coraor <nate@bx.psu.edu> wrote:
Richard Bruskiewich wrote:
Sorry... premature to announce this solution. It only partially fixes the Galaxy page display through the proxy NGINX server.
If anyone has some specific insights on how to get this NGINX configuration correct, please kindly advise.
Hi Richard,
Can you expand on what the remaining issue is?
Thanks, --nate
Richard
On Thu, Dec 2, 2010 at 10:01 AM, Richard Bruskiewich <
wrote:
Colleagues,
I encountered a curious problem while configuring nginx as a proxy for Galaxy. I posed the question through Enis who forwarded it to one of
lists. I just want to share a solution to the issue, which could
documented in a small change to the
http://bitbucket.org/galaxy/galaxy-central/wiki/Config/nginxProxydocumentati....
The observed problem was that Galaxy proxied through NGINX would only display properly in Microsoft IE but not in Firefox or Opera. One of my colleagues noticed that a Firefox error console reported that the
various
cascading style sheets were observed as having MIME type "text/plain" not "text/css" hence, where not loaded by Firefox. Presumably IE assumed CSS file type by the context of retrieval but the other browsers were more strict.
Anyhow, this suggested that although NGINX has a configuration file of MIME types associated with file extensions, the content-type wasn't being properly set. I don't know if this represents a bug in NGINX operations, but after perusing the NGINX wiki docs, I came across a directive that appeared to solve the problem: default_type.
The "default_type" covers any files in a specified context (http, server, location) which don't otherwise have their MIME type recognized (for whatever reason) and is itself originally set "by default" to "text/plain", which may explain the observed error in content type sent back.
What I therefore did is reset the default type, in the style sheet nginx "location" directive context, to "text/css". This appeared to work.
In the nginxProxy wiki documentation page on BitBucket, somebody with editorial privileges to this page may wish to document this throughout
r.bruskiewich@irri.org the perhaps be the
page where the style directives are documented , i.e.
location /static/style { alias /home/nate/galaxy_dist/static/june_2007_style/blue;
default_type text/css; # other directives... }
Cheers,
Richard Bruskiewich, PhD Senior Scientist, Computational and Systems Biology Applications Team for Computational Genomics T.T. Chang Genetic Resources Center International Rice Research Institute
-- *Richard Bruskiewich, PhD* Senior Scientist, Computational and Systems Biology Applications Team for Computational Genomics T.T. Chang Genetic Resources Center International Rice Research Institute
_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
-- *Richard Bruskiewich, PhD* Senior Scientist, Computational and Systems Biology Applications Team for Computational Genomics T.T. Chang Genetic Resources Center International Rice Research Institute
participants (2)
-
Nate Coraor -
Richard Bruskiewich