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

[Chris Cormack]

2009/10/4 Dan Scott <dan at coffeecode.net>:
> 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.
>
For my day job I work on a large media site, which uses a mix of
apache2, nginx and memcached to serve a large amount of dynamic pages
with an even larger amount of static files.

I'm willing to have a chat with anyone who is interested about how we
do it, there might be some nice tips for Evegreen.

(We shifted 1.2 terrabyte today .. some of that traffic was 5.2
million requests for 2 rss files .. nginx handles this kinda load
without even blinking)

Chris