[OPEN-ILS-DEV] Debugging OpenSRF installation

[Dan Wells]

Just to clarify my earlier statement, I was merely saying that few people (if anyone?) currently run OpenSRF alone for any length of time before installing Evergreen, so the window of opportunity for finding this bug was quite small.  I certainly didn't test public.localhost on my previous install before charging ahead :)

DW

>>> Dan Scott <denials at gmail.com> 6/19/2009 6:55 AM >>>
2009/6/18 Dan Wells <dbw2 at calvin.edu>:
> Hello Victoria,
>
> The default Evergreen install has many services running on the public interface, so I think you will be fine.  In fact, that is almost certainly the reason nobody else ran into this bug before.

Well... The sample srfsh.xml.example in OpenSRF source and displayed
in the install instructions uses private.localhost, which avoids that
particular bug because it allows access to all applications. Victoria
used the sample with that default value, had a successful request to
opensrf.math, and then chose to try using public.localhost.

I would suggest that the reason nobody else has run into this bug is
that most people strictly follow the install instructions making the
fewest possible changes to default configuration files, they
successfully test OpenSRF using private.localhost in .srfsh.xml, and
then go on to a successful Evergreen install. The point of breaking
the install process up into two sets of instructions is to ensure
OpenSRF is up and running first before adding the more complicated
Evergreen configuration and applications.

Straying from the instructions and default configs is great for
finding bugs, though, and that's very good for the project. It's not
so good if all that you're trying to do is get a running Evergreen
server going.

-- 
Dan Scott
Laurentian University