Well, I took the following text from the installation instructions:

Copy /openils/conf/srfsh.xml.example to .srfsh.xml in the home directory of each user you want to use to run the srfsh command line client for testing OpenSRF, and edit .srfsh.xml as follows:

* domain is the router hostname (following our domain examples, private.localhost will give your srfsh access to all OpenSRF services, while public.localhost will only give you access to those OpenSRF services that are publicly exposed)

to mean that I needed to test both interfaces to verify they worked. You only showed private, but my assumption was that public also needed to be tested. If I wasn't supposed to test the public interface, it shouldn't have been mentioned. You did say to edit the file. :D

-Vicki (who can be rather pendantic, unfortunately)


On Jun 19, 2009, at 5:55 AM, Dan Scott wrote:

2009/6/18 Dan Wells <[email protected]>:
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

--
Victoria Bush
Opscan Evaluation Manager
Center for Teaching, Learning & Technology
[email protected]



Reply via email to