lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Demian Katz <demian.k...@villanova.edu>
Subject RE: Installing Solr with Ivy
Date Wed, 03 Aug 2016 13:30:34 GMT
Dan,

In case you, or anyone else, is interested, let me share my current solution-in-progress:

https://github.com/vufind-org/vufind/pull/769

I've written a Phing task for my project (Phing is the PHP equivalent of Ant) which takes
some loose inspiration from your Ant download task. The task uses a local directory to cache
Solr distributions and only hits Apache servers if the cache lacks the requested version.
This cache can be retained on my continuous integration and development servers, so I think
this should get me the effect I desire without putting an unreasonable amount of load on the
archive servers. I'd still love in theory to find a solution that's a little more future-proof
than "build a URL and download from it," but for now, I think this will get me through.

Thanks again!

- Demian

-----Original Message-----
From: Davis, Daniel (NIH/NLM) [C] [mailto:daniel.davis@nih.gov] 
Sent: Tuesday, August 02, 2016 11:33 AM
To: solr-user@lucene.apache.org
Subject: RE: Installing Solr with Ivy

Demian,

I've long meant to upload my own "automated installation" - it is ant without ivy, but with
checksums.   I suppose gpg signatures could also be worked in.
It is only semi-automated, because our DevOps group does not have root, but here is a clean
version - https://github.com/danizen/solr-ant-install

System administrators prepare the environment:
- creating a directory for solr (/opt/solr) and logs (/var/logs/solr), maybe a different volume
for solr data.
- create an administrative user with a shell (owns the code)
- create an operational user who runs solr (no shell, cannot modify the code)
- install the initscripts
- setup sudoers rules

The installation this supports is very, very small, and I do not intend to support the cleaned
version of this going forward.   I will update the README.md to make that clear.

I agree with your summary of the difference.   One more aspect of maturity/fullness of solution
- MySQL/PostgreSQL etc. support multiple projects on the same server, at least administratively.
  Solr is getting there, but until role-based access control (RBAC) is strong enough out-of-the-box,
it is hard to setup a *shared* Solr server.    Yet it is very common to do that with database
servers, and in fact doing this is a common way to avoid siloed applications.    Unfortunately,
HTTP auth is not quite good enough for me; but it is only my own fault I haven't contributed
something more.

Dan Davis, Systems/Applications Architect (Contractor), Office of Computer and Communications
Systems, National Library of Medicine, NIH







-----Original Message-----
From: Demian Katz [mailto:demian.katz@villanova.edu]
Sent: Tuesday, August 02, 2016 8:37 AM
To: solr-user@lucene.apache.org
Subject: RE: Installing Solr with Ivy

Thanks, Shawn, for confirming my suspicions.

Regarding your question about how Solr differs from a database server, I agree with you in
theory, but the problem is in the practice: there are very easy, familiar, well-established
techniques for installing and maintaining database platforms, and these platforms are mature
enough that they evolve slowly and most versions are closely functionally equivalent to one
another. Solr is comparatively young (not immature, but young).

Solr still (as far as I can tell) lacks standard package support in the default repos of the
major Linux distros, and frequently breaks backward compatibility between versions in large
and small ways (particularly in the internal API, but sometimes also in the configuration
files). Those are not intended as criticisms of Solr -- they're to a large extent positive
signs of activity and growth -- but they are, as far as I can tell, the current realities
of working with the software.

For a developer with the right experience and knowledge, it's no big deal to navigate these
challenges. However, my package is designed to be friendly to a less experienced, more generalized
non-technical audience, and bundling Solr in the package instead of trying to guide the user
through a potentially confusing manual installation process greatly simplifies the task of
getting things up and running, saving me from having to field support emails from people who
can't figure out how to install Solr on their platform, or those who end up with a version
that's incompatible with my project's configurations and custom handlers.

At this point, my main goal is to revise the bundling process so that instead of storing Solr
in Git, I can install it on-demand with a simple automated process during continuous integration
builds and packaging for release. In the longer term, if the environmental factors change,
I'd certainly prefer to stop bundling it entirely... but I don't think that is practical for
my audience at this stage.

In any case, sorry for the long-winded reply, but hopefully that helps clarify my situation.

- Demian

-----Original Message-----

[...snip...]

In a theoretical situation where your program talked an SQL database, would you include a
database server in your project?  How much time would you invest in automating the download
and install of MySQL, Postgres, or some other database?  I think what you would do in that
situation is include client code to talk to the database and expect the user to provide the
server and prepare it for your program.  In this respect, how is a Solr server any different
than a database server?

Thanks,
Shawn

Mime
View raw message