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 <[email protected]> 6/19/2009 6:55 AM >>> 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
