[OPEN-ILS-DEV] Apache conf improvements

[Joe Atzberger]

>>  Among other things, we apparently need to force install of Yaz, at least
>> until indexdata fixes or forgoes a dependence on their remote test server
>> (and your open firewall allowing access to it).
>>     
>
> Argh, not that problem again! I had hoped they would have learned from
> the last time.
>   

Yeah, we had to deal with month after month of the same questions on the 
Koha lists also.  : (

>> More notably, the package
>> libuuid-perl isn't available in etch (or in my backports apt source).  I had
>> to cpan B/BR/BRAAM/UUID-0.02.tar.gz explicitly.  Lacking that also crashed
>> apache, due to the startup script.
>>     
>
> Hmm, this explains something... you're trying to complete an
> end-to-end install of a development release using an install document
> for the stable version of Evergreen.
>   
Yeah, I also tried it following a separate"server install" document, 
which compensated for some differences (i.e. invoking autogen 
manually).  Of course, the existence of a libuuid-perl package for etch 
is not affected by whether you're installing from SVN or tarball.

> That said, I think that the contributor community is starting to grow
> at the rate that keeping a separate set of install documentation up to
> date with trunk would be a good way of avoiding needless
> re-discovering of the same new / revised requirements and steps.
>   
I'm for that.

>> 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

> 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?

--joe