[ 
https://issues.apache.org/jira/browse/SOLR-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14646314#comment-14646314
 ] 

Timothy Potter commented on SOLR-7850:
--------------------------------------

Would appreciate a good review of that service installer / init.d stuff 
[~elyograg] ... 

In the meantime, yes, the installer does setup {{/var/solr/solr.in.sh}} which 
takes precedence over {{/opt/solr/bin/solr.in.sh}} (the one in the distro).

As for upgrading, the approach I documented was to lay down a new Solr 
installation but keep your existing {{/var/solr}} directory as-is, including 
{{/var/solr/solr.in.sh}}. However, we should add mention about doing a diff 
with the new {{bin/solr.in.sh}} to see if any new goodies have been introduced 
to that file that you may need to include / override with your customized 
{{/var/solr/solr.in.sh}} when doing the upgrade.


> 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]

Reply via email to