Bug 212578

Summary: [PATCH] textproc/apache-solr5: new port where jdk7 is sufficient
Product: Ports & Packages Reporter: ari
Component: Individual Port(s)Assignee: Tobias Kortkamp <tobik>
Status: Closed Overcome By Events    
Severity: Affects Many People CC: mfechner, pi, w.schwarzenfeld
Priority: --- Keywords: patch
Version: LatestFlags: mfechner: maintainer-feedback+
Hardware: Any   
OS: Any   
Attachments:
Description Flags
new solr portfiles
none
new user/group
none
new solr5 port
none
new solr 5 port
none
new solr 5 port none

Description ari 2016-09-11 05:14:45 UTC
Created attachment 174640 [details]
new solr portfiles

I started work to get Solr to start up with a much more flexible startup rc.d script, but this work grew to the point where I rebuilt the entire port. The existing port has multiple problems including just not running since it points to the wrong executable.

Notable features:

1. Runs as solr user/group for better security
2. Uses superior Solr startup script which comes as part of the upstream package
3. Doesn't install the running core application in examples folder
4. Separate examples and docs as port options


Portlint passes.

# portlint
looks fine.

Poudriere builds, tested with both the options checked and with them unchecked.

pkg installed into my production server and runs. Haven't yet put it under load, but I'm doing that this week.
Comment 1 ari 2016-09-11 05:17:00 UTC
Created attachment 174641 [details]
new user/group

I'm also adding a new user/group in order to run Solr at a lower privilege than root.
Comment 2 Kurt Jaeger freebsd_committer freebsd_triage 2016-09-12 03:31:03 UTC
This overlapped with https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201455.

So is this PR still necessary ?
Comment 3 ari 2016-09-12 05:02:19 UTC
Well, yes there is overlap. However there are problems with the other port:

1. The other port has faulty CONFLICTS_INSTALL since it mentioned solr5, but fails to keep solr5 in a separate port. Some users may not want to upgrade solr major releases.

2. I prefer my COPYTREE_SHARE implementation that doesn't litter license files in the install folder.

3. I added options to avoid installed masses of files which 99% of users will not want.

4. I added a solr user to avoid running Solr as root

5. The alternative port /etc/solr.in.sh-dist is interesting, but ultimately sidesteps the usual FreeBSD approach of putting config knobs into rc.conf. I'm not really sure which is better.

6. The other port runs the application from the examples folder. That's not right.


Would you consider committing my port as the solr5 implementation and then we can work on merging the implementation to get the best of both?
Comment 4 ari 2016-09-12 05:04:32 UTC
Oh, and I'm not yet ready to upgrade to Java 8, so I need to stay on Java7 just now. Which rules out Solr6 for me just yet.
Comment 5 Kurt Jaeger freebsd_committer freebsd_triage 2016-09-12 05:33:09 UTC
Yes, adding it as solr5 is a good idea. Can you change the submission so that it can be added as solr5 ?
Comment 6 Kurt Jaeger freebsd_committer freebsd_triage 2016-09-12 05:33:31 UTC
Oh, and please use the solr UID/GID that is in the tree now. Thanks!
Comment 7 ari 2016-09-12 06:37:50 UTC
Created attachment 174672 [details]
new solr5 port

I moved this to Solr5. I've never made a new port from scratch, but I think I got it right.
Comment 8 ari 2016-09-12 06:39:26 UTC
Created attachment 174673 [details]
new solr 5 port

making the previous files obsolete
Comment 9 ari 2016-09-12 07:07:25 UTC
Created attachment 174674 [details]
new solr 5 port

Sorry, now I uploaded the wrong tar. This is correct now.
Comment 10 Matthias Fechner freebsd_committer freebsd_triage 2016-09-12 07:44:23 UTC
Thanks a lot for your work!
Please continue so we have the old solr5 in ports to not enforce users to upgrade to version 6.
Comment 11 Kurt Jaeger freebsd_committer freebsd_triage 2016-09-12 19:25:48 UTC
testbuilds@work
Comment 12 ari 2017-03-06 03:04:39 UTC
If no one is interested in taking my ports work into the FreeBSD tree, just close this ticket.
Comment 13 Walter Schwarzenfeld 2018-02-10 06:13:24 UTC
Any advance here?
Comment 14 Tobias Kortkamp freebsd_committer freebsd_triage 2019-01-25 21:34:32 UTC
Given that it has been over 2 years since anything happened here, I'm closing
this per comment #12.