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.da...@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.k...@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
