[OPEN-ILS-DEV] Apache conf improvements

[Dan Scott]

2009/9/3 Joe Atzberger <atz at esilibrary.com>:

>>> Also need to add "a2enmod xmlent", but at a later point after that
>>> EG-specific piece is compiled and available, before the apache restart.
>>>
>>
>> Hmm. I don't think anyone else has mentioned this as a requirement
>> before; is that new with trunk?
>>
>
> The code is invoking it in eg_vhost.conf is years old, according to git
> blame:
>
> 65769e21 (erickson 2007-02-21 20:35:41 +0000  65)     # - configure
> mod_xmlent
> 65769e21 (erickson 2007-02-21 20:35:41 +0000  66)     XMLEntStripPI "yes"
> 65769e21 (erickson 2007-02-21 20:35:41 +0000  67)     XMLEntEscapeScript
> "no"
> 65769e21 (erickson 2007-02-21 20:35:41 +0000  68)     XMLEntStripComments
> "yes"
> 65769e21 (erickson 2007-02-21 20:35:41 +0000  69)     XMLEntContentType
> "text/html; charset=utf-8"
> 65769e21 (erickson 2007-02-21 20:35:41 +0000  70)     # forces quirks mode
> which we want for now
> 65769e21 (erickson 2007-02-21 20:35:41 +0000  71)     XMLEntStripDoctype
> "yes"
>
> It appears that several others have had the same problems, somewhat
> commonly:
>
>   *
> http://osdir.com/ml/education.libraries.open-ils.devel/2008-07/msg00067.html
>   *
> http://www.open-ils.org/irc_logs/openils-evergreen/2009-01/%23openils-evergreen.28-Wed-2009.log
>   *
> http://osdir.com/ml/education.libraries.open-ils.devel/2008-09/msg00052.html
>   * http://markmail.org/message/uxrbalbu4phawhic

Interesting. When mod_xmlent is installed, one of the installation
steps (I think it's apxs2, actually) adds the following to
/etc/apache2/httpd.conf:

httpd.conf:LoadModule xmlent_module      /usr/lib/apache2/modules/mod_xmlent.so

... which avoids the need for "a2enmod xmlent". Sounds like that isn't
working on etch; maybe due to the apache2.conf vs. httpd.conf schism
(Lenny has "Include /etc/apache2/httpd.conf" as part of apache2.conf
to avoid that set of problems).

>> Ironically, now that the 'change Apache user to "opensrf"' section was
>> struck out and an editorial comment was added that it shouldn't be
>> necessary, etc, we no longer have an end-to-end install document for
>> Evergreen 1.4. As distasteful as the 'change Apache user to "opensrf"'
>> approach may be, it does work.
>>
>
> That was me.  I have to pass the buck on that because I don't actually know
> why that was once required or still considered required.  I guess I would
> characterize my sense on that as "open disbelief".  (I'm running my dev
> install without it, but of course I haven't tried every possible function.)
>
>> To enable new users to continue to complete installs with the stable
>> version successfully until a different Apache / opensrf approach is
>> agreed on, a different way of resolving the problem would be to bring
>> forward discomfort with that approach forward to the list, find out
>> why that's the approach currently, and based on that understanding
>> offer suggestions for how to avoid having to make that change (whether
>> it be fine-grained sets of permissions that need to be changed under
>> the /openils/var subdirectories or whatever).
>>
>
> Consider this my statement of discomfort.  What feature requires changing
> the base apache user?

Cool. Here's one problem - from apache's error.log when I make the
Apache user run as www-data instead of opensrf:

"""
Connection to Settings Failed  Cannot sysopen
/openils/var/log/osrfsys.log: Permission denied at
/usr/local/share/perl/5.10.0/OpenSRF/Utils/Logger.pm line 261.
 : Cannot sysopen /openils/var/log/osrfsys.log: Permission denied at
/usr/local/share/perl/5.10.0/OpenSRF/Utils/Logger.pm line 261.
"""

... because, of course, "chown -R opensrf:opensrf /openils" is one of
the  final installation steps.

That might be all there is to it (resolvable by adding www-data to the
opensrf group?), or there might be more beyond that. Once you peel
back that layer, though, especially on a machine with multiple
applications and multiple users, one might get a little concerned
(either way we approach it) by Apache having read access to all
Evergreen files.

For example, /openils/conf/live-db-setup.pl and
/openils/conf/opensrf_core.xml and /openils/conf/opensrf.xml all have
lots of nifty passwords; if a vulnerable application can be coaxed
into displaying their contents, hilarity / misery can quickly ensue.

-- 
Dan Scott
Laurentian University