[OPEN-ILS-DEV] Debugging OpenSRF installation

[Victoria Bush]

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

--
Victoria Bush
Opscan Evaluation Manager
Center for Teaching, Learning & Technology
vbush at ilstu.edu