[
https://issues.apache.org/jira/browse/SOLR-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095949#comment-15095949
]
Dominique Béjean commented on SOLR-7850:
----------------------------------------
Personally, my prefered solution is to customize the "solr.in.sh" script an put
it in "/etc/default" or "/var/solr"
The problem with this method is the location search order in "bin/solr" script.
Today, it is :
# ./
# $HOME/.solr.in.sh
# /usr/share/solr
# /usr/local/share/solr
# /var/solr/
# /opt/solr
In my opinion, "./" should be the last location
Imagine you put "solr.in.sh" in "/etc/default"
First issue : coherence
If you use the "init.d/solr" script, the "/etc/default/solr/solr.in.sh" is used
If you use the "bin/solr" script, the "bin/solr.in.sh" is used
Second issue : upgrade
In order to fix the first issue, "bin/solr.in.sh" have to be deleted
If you upgrade Solr, a new "bin/solr.in.sh" exists and it is necessary to not
forget to delete it !
I suggest to update the "for include in ..." loop in "bin/solr" script in order
to have
# $HOME/.solr.in.sh
# /usr/share/solr
# /usr/local/share/solr
# /var/solr/
# /opt/solr
# ./
as location search order.
Furthermore in "init.d/solr", the SOLR_ENV variable is not necessary anymore.
> Move user customization out of solr.in.* scripts
> ------------------------------------------------
>
> Key: SOLR-7850
> URL: https://issues.apache.org/jira/browse/SOLR-7850
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
> Affects Versions: 5.2.1
> Reporter: Shawn Heisey
> Priority: Minor
>
> I've seen a fair number of users customizing solr.in.* scripts to make
> changes to their Solr installs. I think the documentation suggests this,
> though I haven't confirmed.
> One possible problem with this is that we might make changes in those scripts
> which such a user would want in their setup, but if they replace the script
> with the one in the new version, they will lose their customizations.
> I propose instead that we have the startup script look for and utilize a user
> customization script, in a similar manner to linux init scripts that look for
> /etc/default/packagename, but are able to function without it. I'm not
> entirely sure where the script should live or what it should be called. One
> idea is server/etc/userconfig.\{sh,cmd\} ... but I haven't put a lot of
> thought into it yet.
> If the internal behavior of our scripts is largely replaced by a small java
> app as detailed in SOLR-7043, then the same thing should apply there -- have
> a config file for a user to specify settings, but work perfectly if that
> config file is absent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
