[OPEN-ILS-DEV] nginx + Evergreen (was: Fixing the mixed-content warnings in My Account)

[Dan Scott]

2009/6/2 Mike Rylander <mrylander at gmail.com>:
> On Tue, Jun 2, 2009 at 6:39 AM, Dan Scott <denials at gmail.com> wrote:
>> 2009/5/29 Mike Rylander <mrylander at gmail.com>:
>>> On Fri, May 29, 2009 at 12:38 AM, Dan Scott <denials at gmail.com> 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