Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#69604 - [solr] unable to create core in 8.8.0-1

Attached to Project: Community Packages
Opened by Alan (jazztickets) - Tuesday, 09 February 2021, 21:33 GMT
Last edited by David Runge (dvzrv) - Tuesday, 09 November 2021, 09:50 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To David Runge (dvzrv)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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
Comment by David Runge (dvzrv) - Saturday, 06 November 2021, 17:39 GMT
@jazztickets: Thanks for the ticket and sorry for the long response delay.

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
Comment by Alan (jazztickets) - Monday, 08 November 2021, 15:13 GMT
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

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"
Comment by David Runge (dvzrv) - Monday, 08 November 2021, 16:17 GMT
Thanks for getting back!

> 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.
Comment by David Runge (dvzrv) - Monday, 08 November 2021, 17:35 GMT
I just tested this with `{solr,zoo}.xml` being symlinked into `/var/lib/solr/` instead and it works. I will change this in an upcoming pkgrel bump.

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'
```
Comment by David Runge (dvzrv) - Monday, 08 November 2021, 18:05 GMT
I guess this would explain why (`/usr/bin/solr`):

```
76 │ SOLR_TIP=`dirname "$SOLR_SCRIPT"`/..
77 │ SOLR_TIP=`cd "$SOLR_TIP"; pwd`
```
Comment by Alan (jazztickets) - Monday, 08 November 2021, 18:21 GMT
I believe you would want to copy solr.xml and zoo.cfg into /var/lib/solr since those should be configurable (more so zoo.cfg, since solr.xml can pull values from JVM system properties). I think leaving configsets in /usr/share.. is fine since the user can always read from a custom configset path when creating a core.

Is there a way I can test your WIP PKGBUILD file?
Comment by David Runge (dvzrv) - Monday, 08 November 2021, 19:43 GMT
Both files are now symlinked to /var/lib/solr/ (the actual files remain in /etc/solr due to FHS and being backed up by pacman).
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! :)
Comment by Alan (jazztickets) - Monday, 08 November 2021, 21:09 GMT
Ah right, symlinked from /etc. I was thinking it was still coming from /usr/share.

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!
Comment by David Runge (dvzrv) - Monday, 08 November 2021, 21:51 GMT
I have set them to be readable by the solr group at least.
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!
Comment by Alan (jazztickets) - Monday, 08 November 2021, 22:06 GMT
I think just solr group owned is fine on those, although I haven't actually used ZooKeeper before. If anything that'll be another report for another day. Otherwise, the changes are working well!
Comment by David Runge (dvzrv) - Tuesday, 09 November 2021, 09:49 GMT
Thanks for testing! I have changed the user ownership for /etc/solr/zoo.cfg back to root in 8.10.1-3, which is now in [community].

Loading...