[
https://issues.apache.org/jira/browse/SOLR-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861657#comment-16861657
]
Noble Paul edited comment on SOLR-13534 at 6/12/19 1:36 AM:
------------------------------------------------------------
bq.Imagine multi tenancy.
I would strongly recommend against setting {{enable.runtume.lib=true}} in a
multi tenant setup. You wouldn't want to to be responsible for code written by
others.
However, it should be possible the multi tenant Solr provider should to load
their own jars like this. The solution is to always lock down your config APIs.
I would say hitting a random url from solr should be the least of our concern.
bq.I was also concerned about the HA aspect of this. What if the URL is
unavailable, could it affect the whole cluster, or is the jar fetched and
cached on each node?
The jar is fetched when the node is started. Unlike jars loaded from
{{.system}} collection, it is not loaded at first request.
bq.So having to pre-register the "code repository" host:port in, say, solr.xml
or zk, ...
This can be an additional security measure. The user could add a whitelist of
domains in ZK from where the jars could be loaded
was (Author: noble.paul):
bq.Imagine multi tenancy.
I would strongly recommend against setting {{enable.runtume.lib=true}} in a
multi tenant setup. You wouldn't want to to be responsible for code written by
others.
However, it should be possible the multi tenant Solr provider should to load
their own jars like this. The solution is to always lock down your config APIs.
I would say hitting a random url from solr should be the least of our concern.
bq.I was also concerned about the HA aspect of this. What if the URL is
unavailable, could it affect the whole cluster, or is the jar fetched and
cached on each node?
The jar is fetched when the node is started. Unlike jars loaded from
{{.system}} collection, it is not loaded at first request.
> Dynamic loading of jars from a url
> ----------------------------------
>
> Key: SOLR-13534
> URL: https://issues.apache.org/jira/browse/SOLR-13534
> Project: Solr
> Issue Type: Improvement
> Reporter: Noble Paul
> Assignee: Noble Paul
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Dynamic loading is possible from {{.system}} collection. It's much easier to
> host the jars on a remote service and load it from there. This way the user
> should have no problem in loading jars when the {{.system}} collection is not
> available for some reason.
> The steps should look as follows
> # get the hash of your jar file. {{openssl dgst -sha512 <jar>}}
> # upload it your hosting service . say the location is
> {{[http://host:port/my-jar/location|http://hostport/]}}
> # create a runtime lib entry for the collection as follows
> {code:java}
> curl http://localhost:8983/solr/techproducts/config -H
> 'Content-type:application/json' -d '{
> "add-runtimelib": { "name":"jarblobname",
> "sha512":"e94bb3990b39aacdabaa3eef7ca6102d96fa46766048da50269f25fd41164440a4e024d7a7fb0d5ec328cd8322bb65f5ba7886e076a8f224f78cb310fd45896d"
> , "url" : "http://host:port/my-jar/loaction"}
> }'
> {code}
> to update the jar, just repeat the steps and use the {{update-runtimelib}} to
> update the sha512 hash
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
