: The scripts as they are written now only acts on a local Solr server.  Some
: of the
: scripts are more than just a wrapper to curl to post XML to a Solr server.
: For example,
: a couple of the scripts also backup the index directory.  If we want the


I know ... but even if the script must be run localy on the server, people
may want to configure their server with host based rules, or access
controls by path -- they should be able to set ENV variables (or command
line args) to override the entire URL.




: > On Mar 23, 2006, at 4:32 PM, Chris Hostetter wrote:
: > > regardless of the seperate thread about support for multiple
: > > indexes and
: > > how thta might change the URL, we should probably make the URLs
: > > used by
: > > all of hte scripts completely configurable (not just the port, but
: > > everything up to the webapp context) ...
: > >
: > >  1) people might want to change the webapp name (ie: rename the war)
: >
: > In fact if you build Solr from source, you end up with solr-1.0.war,
: > and it must be renamed to match the examples anyway to solr.war when
: > deployed.  Unless I'm missing something.
: >
: > >  2) for scripts like optimize/commit people might want to run them
: > > from
: > >     remote hosts (so hardcoding "localhost" would be bad).
: > >  3) even for scripts that only make sense when run on localhost (ie:
: > >     making backups) people may configure their appserver to block
: > > reuqests
: > >     that don't use a specific hostname, or have certain authentication
: > >     information -- ie: only allow/commits updates if the
: > >     update-solr.internal.domain hostname is used, or only allow
: > > updates to
: > >     a particular user/password pair (i *think* curl supports
: > >     http://user:[EMAIL PROTECTED]/path urls ... right?)
: >
: > I'm in the midst of learning Solr and prototyping with it to replace
: > my much less feature rich custom XML-RPC search server.  When I get
: > to the point of leveraging the command-line scripts, I'll likely
: > write my own Ruby versions of them and would be happy to contribute
: > those if they come to life.  I'd make all the pieces parameterizable,
: > and agree that should be the case for the shell scripts as well.
: >
: >         Erik
: >
: >
:



-Hoss

Reply via email to