[OPEN-ILS-DEV] ***SPAM*** Re: Apache conf improvements

[Dan Scott]

2009/9/3 Joe Atzberger <atz at esilibrary.com>:
> Dan Scott wrote:
>>
>> 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
>
> Yeah, it looks like that is in my httpd.conf:
> #
> #LoadModule mod_placeholder /usr/lib/apache2/modules/mod_placeholder.so
> LoadModule osrf_json_gateway_module
> /usr/lib/apache2/modules/osrf_json_gateway.so
> LoadModule osrf_http_translator_module
> /usr/lib/apache2/modules/osrf_http_translator.so
> LoadModule xmlent_module      /usr/lib/apache2/modules/mod_xmlent.so
>
> And my apache2.conf does have "Include /etc/apache2/httpd.conf" too, so that
> would seem consistent.  I don't know if the step to append to those lines
> failed initially or not.  Or maybe there is a timing issue with the startup
> script?

I doubt it's a timing issue with the startup scripts. It might be
worthwhile trying to reproduce the conditions on a fresh install;
perhaps the step that appends those lines gets executed in the wrong
order, so that the first time it fails to append and simply creates
the httpd.conf file, and then the second time it can successfully
append the lines.

>> 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.
>
> Interesting.  That line would be:
>
>   sysopen( SINK, $file, O_NONBLOCK|O_WRONLY|O_APPEND|O_CREAT )
>       or die "Cannot sysopen $logfile: $!";
>
> There's an error there, inasumuch as $file != $logfile, so the error message
> could be misleading.  But in your case, they're identical, so this issue
> must be easy to reproduce:
>
>   perl -we 'use strict; use FileHandle;
>   my $file=q(foo.txt);
>   sysopen(SINK, $file, O_NONBLOCK|O_WRONLY|O_APPEND|O_CREAT) or die
>   qq(Cannot sysopen $file: $!);
>   print SINK scalar localtime, qq(\n);'
>
>
> With the right foo.txt (or directory) owner/permissions, that does it.  So
> solutions would include:
>
>  1. chmod g+x /openils/var/log && chgrp www-data /openils/var/log
> #short term
>  2. log to /var/log/apache/xxx instead # where the normal user:group
>     aren't a problem
>  3. use a log framework like Sys::Syslog or log4perl   # long term

Actually, #3 is already in place if, in opensrf_core.xml, you specify
<logfile>syslog</logfile> instead of a local file. So on the face of
it, switching to syslog by default in opensrf_core.xml would solve the
Apache user=opensrf problem. Except then we have a new problem:
configuring syslog/syslog-ng to usefully separate out the pertinent
Evergreen / OpenSRF-related log entries, so that we can help sort out
what problems people might be running into when installing Evergreen.
This is probably why we adopted the "set Apache user=opensrf" approach
for the install instructions - enabling the simplest possible "get
people up and running first, and then they can refine their
configuration" approach took priority, rather than documenting a
production-ready best-practices configuration out of the box (at the
cost of more complexity in the install and possibly more failed
install attempts).

If you can help us move towards a more production-ready configuration
while keeping the install as simple as possible, awesome!

> Or is there a more fundamental problem?  Are we actually trying to write to
> the same log file for actions initiated by the web (by "www-data") and also
> those initiated by other actions (via cronjob or command-line as another
> user)?  Unless the logs are passed through a daemon, there wouldn't be any
> real fix for that.

Yep, the OpenSRF services write to the same logfile.

>>
>> 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
>
> You're not suggesting that having apache run as the owner of those files
> somehow makes them more secure, though, right?

Heh, no, that would be the "(either way we approach it)" portion of my
message. Trust me, a few of my neurons do work :)

-- 
Dan Scott
Laurentian University