[OPEN-ILS-DEV] Apache conf improvements

Dan Scott denials at gmail.com
Wed Sep 2 21:29:54 EDT 2009


2009/9/2 Joe Atzberger <atz at esilibrary.com>:
> Dan Scott wrote:
>>
>> On 02/09/2009, Joe Atzberger <atz at esilibrary.com> wrote:
>>
>>>
>>> I'm not trying to make the decision whether SSL is required for
>>> Evergreen or not.  In fact, I explicitly added to the documentation:
>>>
>>>    a2enmod ssl        # enable mod_ssl
>>>
>>
>> If I recall correctly, that step is already in Makefile.install - and
>> to date, anything that can be automated easily goes into
>> Makefile.install and is not part of the distro-specific wiki
>> directions
>> (http://open-ils.org/dokuwiki/doku.php?id=server:1.4.0:install).
>>
>
> Yeah, and if I can get to it, I'll also be touching that to prevent that
> step from crashing on Debian etch, as it did during my initial attempts.

Hmm, strange that no one else has reported that problem. I suspect
most of us are working with Debian Lenny / Ubuntu Hardy these days. It
might be worthwhile discussing how much effort we want to put into the
support of Etch for Evergreen 1.6 / 2.0 given that Lenny has been out
since the spring.

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

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

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.

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

> In general, I think we need at least one end-to-end install document.  It
> doesn't matter for what platform.  Any distro-specific docs can replicate
> it, or be more of a "diff", saying effectively "Do steps 1-6 from the main
> doc.  For step 7, do xxxx."

Sure, that sounds reasonable. FWIW, there used to be separate Ubuntu
and Debian install pages, but the diffs were so small, and with the
annoyance of making the same changes to each page (or worse, making a
change to one but forgetting the other) I consolidated them back in
February.

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.

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

> We also need a chart of what OpenSRF versions
> are compatible with what versions of EG.

That makes a lot of sense.

> And the start/stop controls for router and others could be more
> bulletproofy.  I'll stop now....

Sounds good! Your fresh eyes are probably going to find all kinds of
rough areas that are invisible to many of us now, and that will
definitely help improve the project.

-- 
Dan Scott
Laurentian University


More information about the Open-ils-dev mailing list