FS#69604 - [solr] unable to create core in 8.8.0-1
Attached to Project:
Community Packages
Opened by jazztickets (jazztickets) - Tuesday, 09 February 2021, 21:33 GMT
Last edited by David Runge (dvzrv) - Tuesday, 09 November 2021, 09:50 GMT
Opened by jazztickets (jazztickets) - Tuesday, 09 February 2021, 21:33 GMT
Last edited by David Runge (dvzrv) - Tuesday, 09 November 2021, 09:50 GMT
|
Details
Description:
There is no way to create a core due to hardcoded paths to readonly directories in the .service file. To reproduce: 1. Start the solr service 2. Open browser to something like "http://localhost:8983" 3. Click Core Admin, then Add Core 4. Displayed is an error: "Error CREATEing SolrCore 'new_core': Couldn't persist core properties to /usr/share/solr/server/solr/new_core/core.properties : /usr/share/solr/server/solr/new_core: Read-only file system" This isn't how you create a core however, it just illustrates that the solr.solr.home variable is misconfigured. In the .service file is the line: ExecStart=/usr/bin/solr start -f -d /usr/share/solr/server -s /usr/share/solr/server/solr -t /var/lib/solr From the command 'solr start -help': -s <dir> Sets the solr.solr.home system property; Solr will create core directories under this directory. It needs to create files under /var/lib/solr, not /usr/share... The problem with using these flags in the service file is that it overrides any variables in /etc/solr/solr.in.sh, rendering it useless. I think it should be changed to something like: ExecStart=/usr/bin/solr start -f -d /usr/share/solr/server But then you'd have to have the package automatically set SOLR_HOME inside /etc/solr/solr.in.sh to "/var/lib/solr", and also copy solr.xml to /var/lib/solr/. Another problem is with the command line tool. Running the command: sudo -u solr solr create -c new_core -d /usr/share/solr/server/solr/configsets/_default/ Results in: Error: Could not find or load main class org.apache.solr.util.SolrCLI Caused by: java.lang.ClassNotFoundException: org.apache.solr.util.SolrCLI Currently the only way to create a core file (after fixing the .service file) would be: sudo -u solr mkdir /var/lib/solr/new_core sudo -u solr cp -r /usr/share/solr/server/solr/configsets/_default/conf/ /var/lib/solr/new_core/ |
This task depends upon
Closed by David Runge (dvzrv)
Tuesday, 09 November 2021, 09:50 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed with 8.10.1-3
Tuesday, 09 November 2021, 09:50 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed with 8.10.1-3
The systemd service integration is done in this way to support one instance, not several.
To achieve what you want, you either have to adapt the service in an override (see systemctl edit [1]) or start solr outside of systemd. The integration is unfortunately not very intuitive.
Potentially one could also think about patching the default configuration file or similar.
At any rate, I am not very sure how to best achieve this for several instances, but potentially with a templated systemd service, that first copies the required files in place.
Suggestions are much welcome!
[1] https://man.archlinux.org/man/systemctl.1
https://solr.apache.org/guide/8_8/solr-cores-and-solr-xml.html
My suggestion is to just use the PKGBUILD on AUR as a starting point: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=solr6
It puts all mutable data in /opt and simply starts Solr with the command "/opt/solr/bin/solr start -f"
> I'm not exactly sure what you mean by "is done in this way to support one instance, not several." I'm talking about creating Solr cores, not running multiple Solr instances on different ports(?)
> https://solr.apache.org/guide/8_8/solr-cores-and-solr-xml.html
If I understand this correctly, we would need to install the entirety of what is currently in `/usr/share/solr/server/solr/*` to `/var/lib/solr/` instead (while retaining symlinks for the configurations) or copy these files as part of an ExecStartPre step in the service (the latter is not really feasible I believe as it would mean to overwrite existing data).
Do you know if this only requires `{solr,zoo}.xml` or also the `/usr/share/solr/server/solr/configsets` directory?
> My suggestion is to just use the PKGBUILD on AUR as a starting point: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=solr6
> It puts all mutable data in /opt and simply starts Solr with the command "/opt/solr/bin/solr start -f"
No, as that PKGBUILD puts *all package data* below `/opt/solr` and lets a system user have domain over those files (including the modification of its own executables and libraries). This is very dangerous and nothing that should go into a system package.
With regards to your other issue with creating a new core:
It appears that the script in `/usr/bin/solr` (which is the same as `/usr/share/solr/bin/solr`) has some broken assumptions about locations in regards to some commands, which is why calling it in the latter location works for the purpose of creating a core:
```
sudo -u solr bash /usr/share/solr/bin/solr create_core -c test -d /usr/share/solr/server/solr/configsets/_default
Created new core 'test'
```
```
76 │ SOLR_TIP=`dirname "$SOLR_SCRIPT"`/..
77 │ SOLR_TIP=`cd "$SOLR_TIP"; pwd`
```
Is there a way I can test your WIP PKGBUILD file?
Do you believe either of the two should be writable by the solr user (was that what you meant with "more so zoo.cfg")?
I can push a package to [community-testing] and you can try it from there! :)
Nope, I don't think it needs to be modifiable by the solr user.
I'll try it out once you get it pushed. Thanks!
The zoo.cfg is also owned by the solr user/group. If you think that's not needed, I can remove the user permission again.
Please let me know whether 8.10.1-2 in [community-testing] works for you!