2009/6/2 Mike Rylander <[email protected]>: > On Tue, Jun 2, 2009 at 6:39 AM, Dan Scott <[email protected]> wrote: >> 2009/5/29 Mike Rylander <[email protected]>: >>> On Fri, May 29, 2009 at 12:38 AM, Dan Scott <[email protected]> wrote: >>>> If I understand correctly, some browsers (hello IE!) throw up warnings >>>> when patrons enter "My Account" in the OPAC because there are some >>>> hard-coded HTTP requests mixed in with the HTTPS session. When patrons >>>> opt to not allow the browser to load mixed content, hilarity (or some >>>> miserable facsimile thereof) ensues. This is bad. Apaprently things >>>> are even worse in IE8. >>>> >>>> It looks like the mixed content is due to >>>> Open-ILS/var/web/opac/skin/default/xml/setenv.xml: >>>> >>>> setenv.xml:<!--#set var="OILS_BASE" >>>> value="http://${SERVER_NAME}/${OILS_OPAC_BASE}"--> >>>> setenv.xml: <!--#set var="OILS_OPAC_JS_HOST" >>>> value="http://${OILS_OPAC_JS_HOST}"--> >>>> setenv.xml: <!--#set var="OILS_OPAC_CSS_HOST" >>>> value="http://${OILS_OPAC_CSS_HOST}"--> >>>> >>>> Setting these to the following alleviates the problem: >>>> >>>> setenv.xml:<!--#set var="OILS_BASE" value="${OILS_OPAC_BASE}"--> >>>> setenv.xml: <!--#set var="OILS_OPAC_JS_HOST" value=""--> >>>> setenv.xml: <!--#set var="OILS_OPAC_CSS_HOST" value=""--> >>>> >>>> The win from having a non-scary default configuration seems to, in my >>>> mind, outweigh the possible balancing of JS and CSS across different >>>> hosts. Would there be any objection to my merging a commit that resets >>>> each offending var to a non-scary default value, along with a comment >>>> that explains what in the wide world of sports is going on? >>> >>> How about we do that /AND/ supply https: versions of those three, >>> having the code that deals with (and makes up) the My OPAC stuff use >>> those. Perhaps even make that explicit in the name by putting MYOPAC >>> in there: >>> >>> setenv.xml:<!--#set var="OILS_MYOPAC_BASE" >>> value="https://${SERVER_NAME}/${OILS_OPAC_BASE}"--> >>> setenv.xml:<!--#set var="OILS_MYOPAC_JS_HOST" >>> value="https://${OILS_OPAC_JS_HOST}"--> >>> setenv.xml:<!--#set var="OILS_MYOPAC_CSS_HOST" >>> value="https://${OILS_OPAC_CSS_HOST}"--> >>> >>> Then My OPAC is happy in tin-foil browsers, and those sites that need >>> a separate content server (at least the 2 largest production sites, >>> that I recall OTTOMH) don't have to jump through any more hoops than >>> anyone else at upgrade time -- it stays as config settings. Do you >>> see any issues with that modification to your plan? >> >> Other than being more work and perhaps more susceptible to slipping in >> an error somewhere for the simple case, no, I think it will maintain >> the current approach for serving up static content in more complex >> configurations. For now, we have adopted the simplistic "serve >> everything up from a single host" approach (recognizing that that's >> eating up our Apache backends like crazy, but hey, it's summer and >> slow time for the academics). >> >> Rather than trying to solve the problem in the Evergreen application >> code, another approach would be to use something like nginx as a proxy >> to serve up all known static types (*.js, *.png, *.gif, and the like) >> / locations and to hand off the dynamic requests to Apache. nginx is >> apparently able to serve up static content at higher concurrency and >> using far less CPU & RAM than Apache requires. This would add one more >> moving part to a production configuration, but it would have the >> advantage of simplifying the application code (one less set of SSI to >> deal with). Each server in a load-balanced cluster could be >> responsible for serving up its own static content; or all static >> content could be served up from a designated host; or in a simple >> non-nginx environment, Apache could still serve up all static + >> dynamic content. >> >> There's a good intro to nginx at >> http://www.linuxjournal.com/article/10108 for those interested in >> pursuing this direction. >> > > That /is/ interesting, and definitely worth looking into (setting > aside my reactionary fear of proxies with EG) for large installations, > but I think it's more deserving of a "here's how to /really/ trick out > your EG install" article.
Made some headway on this tonight, documented at http://evergreen-ils.org/dokuwiki/doku.php?id=server_installation:nginx_proxy - there's probably much more that can be done, but it's a start. > Maybe that goes into main-line once we see it in production at Conifer > and all fears are put to rest? After some more testing on the virtual machine(s), I think we'll be putting this into production. I definitely want to slow down the recycling rate of our Apache processes. We'll let you know how that works out. -- Dan Scott Laurentian University
