lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Confusing error when creating a new core with TLS, service enabled
Date Wed, 11 Apr 2018 14:29:29 GMT

On 4/10/18 10:16 AM, Shawn Heisey wrote:
> On 4/10/2018 7:32 AM, Christopher Schultz wrote:
>>> What happened is that the new core directory was created as root,
>>> owned by root.
>> Was it? If my server is running as solr, how can it create directories
>> as root?
> Unless you run Solr in cloud mode (which means using zookeeper), the
> server cannot create the core directories itself. When running in
> standalone mode, the core directory is created by the bin/solr program
> doing the "create" -- which was running as root.

That is ... surprising.[1]

> I know that because
> you needed the "-force" option.  So the core directory and its "conf"
> subdirectory (with the config) are created by the script, then Solr is
> asked (using the CoreAdmin API via http) to add that core.  It can't,
> because the new directory was created by root, and Solr can't write the
> file that defines the core for Solr.

Okay, then that makes sense. I'll try running bin/solr as "solr" via
sudo instead of merely as root. I was under the mistaken impression that
the server kept its own files in order.

It also means that one cannot remote-admin a Solr server. :(

> When running Solr in cloud mode, the configs are in zookeeper, so the
> create command on the script doesn't have to make the core directory in
> order for Solr to find the configuration.  It can simply upload the
> config to zookeeper and then tell Solr to create the collection, and
> Solr will do so, locating the configuration in ZooKeeper.

Good to know, though I'm not at the stage where I'm using ZK.

> You might be wondering why Solr can't create the core directories itself
> using the CoreAdmin API except in cloud mode.  This is because the
> CoreAdmin API is *OLD* and its functionality has not really changed
> since it was created.  Historically, it was only designed to add a core
> that had already been created.

*snapping sounds from inside brain*

> We probably need to "fix" this ... but
> it has never been a priority.  There are bigger problems and features to
> work on.  Cloud mode is much newer, and although the Collections API
> does utilize the CoreAdmin API behind the scenes, the user typically
> doesn't use CoreAdmin directly in cloud mode.
>> The client may be running as root, but the server is running as 'solr'.
>> And the error occurs on the server, not the client. So, what's really
>> going on, here?
> I hope I've explained that clearly above.

You have. Running bin/solr as user 'solr' was able to create the core.

The way the installer and server work together is very unfortunate.
bin/solr knows the euid of the server and, if running under root/sudo
could easily mkdir/chown without crapping itself. Having installed a
"service" using the Solr installer practically requires you to run
bin/solr using sudo, and then it doesn't work. Is there a JIRA ticket
already in existence where I can leave a comment?



View raw message