solr docker image

[Bjørn Kristian Larsen]

Hi, I need to move an existing solr instance to kubernetes.

I am trying to write a Dockerfile to
1. create a core
2. load data
3. run solr

I am able to create a core from my existing config and run it with
"docker run -v myconf:/myservice solr:6.6 -c myservice -d /myservice"

But i want to avoid saving that container to a new image and then reuse
that image in kubernetes.

I would guess this is a common usecase but I can not find anything about it
here https://github.com/docker-solr/docker-solr

Any help would be appreciated!

Bjørn Larsen

Re: solr docker image

[Timo Grün]

Hi Bjørn, 

First the Dockerfile is simply a blue-print to create an image. 
So you wouldn’t run the Solr directly from the Dockerfile. 

1. Instead you would create your custom image with the following content:

FROM solr:6.6
ADD  

2. To build the image you can use the following command:

docker create —tag my-solr:1.0.0 .

3. To run your preconfigured solr, simply use:

docker run my-solr:1.0.0


If would like to completely get rid of the Dockerfile, you can use Helm instead 
to add the data to the pod while creating.

Hope this helps, 

Best,
Timo Grün



> On 6. May 2021, at 13:23, Bjørn Kristian Larsen  wrote:
> 
> Hi, I need to move an existing solr instance to kubernetes.
> 
> I am trying to write a Dockerfile to
> 1. create a core
> 2. load data
> 3. run solr
> 
> I am able to create a core from my existing config and run it with
> "docker run -v myconf:/myservice solr:6.6 -c myservice -d /myservice"
> 
> But i want to avoid saving that container to a new image and then reuse
> that image in kubernetes.
> 
> I would guess this is a common usecase but I can not find anything about it
> here https://github.com/docker-solr/docker-solr
> 
> Any help would be appreciated!
> 
> Bjørn Larsen

Re: solr docker image

[Jan Høydahl]

So do you want to pacakge a pre-built index into a docker image and distribute 
that image to k8s? Or do you also need to index data to Solr live in k8s?

For the first case, where you periodically re-build an index and includes it in 
the image, Timo's Dockerfile inheritance could work well. Benefit is that you 
can use k8s ASG to add replicas easily.

If you instead want a fully operational Solr cluster in k8s in which you can 
create collections, scale out, index content to live etc, then have a look at 
Solr Operator instead - https://solr.apache.org/operator/. It is more 
heavy-weight for sure, but it will spin up a Zookeeper cluster along with a 
SolrCloud cluster, and then you can point your application to that cluster 
through an ingress for index/query.

Jan

> 6. mai 2021 kl. 13:23 skrev Bjørn Kristian Larsen :
> 
> Hi, I need to move an existing solr instance to kubernetes.
> 
> I am trying to write a Dockerfile to
> 1. create a core
> 2. load data
> 3. run solr
> 
> I am able to create a core from my existing config and run it with
> "docker run -v myconf:/myservice solr:6.6 -c myservice -d /myservice"
> 
> But i want to avoid saving that container to a new image and then reuse
> that image in kubernetes.
> 
> I would guess this is a common usecase but I can not find anything about it
> here https://github.com/docker-solr/docker-solr
> 
> Any help would be appreciated!
> 
> Bjørn Larsen

Re: Solr 8.8.2 childFilter multiple conditions

[David Smiley]

Hi,

It appears this was broken in 8.0 by
https://issues.apache.org/jira/browse/SOLR-12768
And then fixed in 9.0 (not released) by SOLR-15156

I didn't back-port the fix because I thought users might be relying on the
escaping behavior.  I didn't realize such escaping didn't exist before
SOLR-12768.  In light of this, the change would make an appropriate
addition to 8.9 but not a bug-fix version.

A work-around is to express your query without colons, since the internal
logic is gated on that.  So something like:
   childFilter='+{!field f=docType v=child_doc_type} +{!field f=color
v=Red}'etc.   Disclaimer: I didn't test that; it *may* be necessary
to move out some of this into other parameters based on parsing
rules/restrictions e.g. childFilter=$theChildFilter  and then add a
top-level param.  But I think it's not needed.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Tue, May 4, 2021 at 6:30 PM Jonathan Bridges 
wrote:

> Hello,
>
> With Solr 8.8.2 I am unable to provide more than one filter in the fl
> "childFilter" param.
>
> For example,
>
> fq={!parent which='docType:parent_doc_type'} docType: child_doc_type AND
> color: Red AND size: Large
>
> This fq will filter all parent documents which have child documents that
> are 'Red' and 'Large'.
>
> Now I want to show the parents with the children in the result, but only
> the children which are 'Red' and 'Large'. In the past (Solr v6) I would
> accomplish this with:
>
> fl=*, [child childFilter='docType:child_doc_type AND color: Red AND size:
> Large']
> However, with Solr 8.8.2 I get no children in the results and no errors.
>
> If I remove the extra AND conditions:
>
> fl=*, [child childFilter='docType:child_doc_type']
> I then get all child documents, even ones which are Blue and Small.
>
> How can I include only child documents which match the fq? Is there some
> way to specify multiple conditions now that I just can't find in the docs?
>
> Thanks for any help.
>

[Operator] [ANNOUNCE] Apache Solr Operator v0.3.0 released

[Houston Putman]

The Solr PMC is pleased to announce the release of the Apache Solr Operator
v0.3.0.

The Apache Solr Operator is a safe and easy way of managing a Solr
ecosystem in Kubernetes.

This release contains numerous bug fixes, optimizations, and improvements,
some of which are highlighted below. The release is available for immediate
download at:

  


### Solr Operator v0.3.0 Release Highlights:

* The Solr Operator is now an Apache project managed by the Apache Solr PMC.
* The CRDs are now under the solr.apache.org group instead of
solr.bloomberg.com.
* The Solr Operator now fully supports running Solr in a secure and locked
down way:
  * Basic Auth support is now built in when requested in the SolrCloud CRD
  * Solr can be run with TLS (optional mTLS, if provided to the operator)
* More helm chart options are provided to customize running the Solr
Operator
* The Zookeeper Operator is now up-to-date with the most recent release,
v0.2.9.
  * It can now be installed as a helm-chart dependency with the Solr
Operator.
* Users can now provide custom Solr log4j.xml and Prometheus Exporter
config xml configMaps
* Fixed a bug in custom probes for Solr pods
* Solr pod shutdown is more graceful, has better coordination between
Kubernetes and Solr.
* SolrCloud can now be used with the Kubernetes HPA to autoscale Solr Cloud
pods.

A summary of important changes is published in the documentation at:

  

For the most exhaustive list, see the full release notes in the Github
Releases or by viewing the git history in the solr-operator repo.

  


Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases. It is possible that the mirror you are using may not
have
replicated the release yet. If that is the case, please try another mirror.
This also applies to Maven access.

-Ddisable.configEdit=true does not work

[Bogdan Korchevskiy]

I need to disable Config API on my SOLR, where the system is already installed 
and running.
As its mentioned over web, I need to add the string:
SOLR_OPTS="$SOLR_OPTS -Ddisable.configEdit=true"
to the solr.in.sh file. However, I dont have the solr.in.sh file.

I also found that another way is to set system properties in the Solr startup 
file, there is usually a parameter named SOLR_OPTS, where I can add 
-Ddisable.configEdit=true
So, according to that, I added string:
-Ddisable.configEdit=true
to the SolrCloud.exe>JAVA>Java options.
and restarted the SOLR services.
When I log in to the SOLR UI Admin>Java Properties 
(http://localhost:portNumber/solr/~java-properties)
I can see in the left column: disable.​configEdit
and in the right columns: true
So it looks like I disabled configEdit.

However, when I run curl command in order to verify it - the curl command runs 
with no error:
curl http://localhost:portNumber/solr/core_name/config -H "Accept: 
application/json" -H "Content-type:application/json" -d "{'set-user-property' : 
{'variable_name':'some_value'}}"

What am I doing wrong?  

-Ddisable.configEdit=true does not work

[Bogdan Korchevskiy]

-Ddisable.configEdit=true does not work

text_en_splitting with quotes not matching when there are 2 adjacent stopwords

[Drini Cami]

Hello! I have a question about the text_en_splitting fieldType (solr 8.8.2,
very vanilla schema). I noticed that it was failing for queries like:
`title:"The
Mark of the Crown"`, but succeeding for queries like `title:The Mark of the
Crown`. Using the solr analysis tool, I noticed that the index analyzer
converts "The Mark of the Crown" to `[_, mark, _, crown]`, but the query
analyzer converts it to `[_, mark, _, _, crown]`. I then noticed the index
analyzer has as a final filter FlattenGraphFilterFactory, which seems to
combine adjacent `_`. I tried also adding FlattenGraphFilterFactory to the
query analyzer and that fixed the issue. Is this a reasonable solution? If
so, should that be the default? Or am I using the wrong fieldType
altogether?

Thank you,

Drini

Re: Solr 8.8.2 childFilter multiple conditions

[Jonathan Bridges]

Thanks David for confirming this and the work around, really appreciate it.

I also found a subquery could give correct results, though haven't tested
performance comparison with childFilter. I had never used subquery before
so it hadn't occurred to me. Will try them both out.

fq={!parent which='docType:factory'} docType:widget AND color:Red AND
size:Large
fl=*, widgets:[subquery]
widgets.q=docType: child_doc_type AND color: Red AND size: Large
widgets.fq={!terms f=_nest_parent_ v=$row.id}

Thanks again,
Jon Bridges


On Thu, May 6, 2021 at 9:38 AM David Smiley  wrote:

> Hi,
>
> It appears this was broken in 8.0 by
> https://issues.apache.org/jira/browse/SOLR-12768
> And then fixed in 9.0 (not released) by SOLR-15156
>
> I didn't back-port the fix because I thought users might be relying on the
> escaping behavior.  I didn't realize such escaping didn't exist before
> SOLR-12768.  In light of this, the change would make an appropriate
> addition to 8.9 but not a bug-fix version.
>
> A work-around is to express your query without colons, since the internal
> logic is gated on that.  So something like:
>childFilter='+{!field f=docType v=child_doc_type} +{!field f=color
> v=Red}'etc.   Disclaimer: I didn't test that; it *may* be necessary
> to move out some of this into other parameters based on parsing
> rules/restrictions e.g. childFilter=$theChildFilter  and then add a
> top-level param.  But I think it's not needed.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, May 4, 2021 at 6:30 PM Jonathan Bridges 
> wrote:
>
> > Hello,
> >
> > With Solr 8.8.2 I am unable to provide more than one filter in the fl
> > "childFilter" param.
> >
> > For example,
> >
> > fq={!parent which='docType:parent_doc_type'} docType: child_doc_type AND
> > color: Red AND size: Large
> >
> > This fq will filter all parent documents which have child documents that
> > are 'Red' and 'Large'.
> >
> > Now I want to show the parents with the children in the result, but only
> > the children which are 'Red' and 'Large'. In the past (Solr v6) I would
> > accomplish this with:
> >
> > fl=*, [child childFilter='docType:child_doc_type AND color: Red AND size:
> > Large']
> > However, with Solr 8.8.2 I get no children in the results and no errors.
> >
> > If I remove the extra AND conditions:
> >
> > fl=*, [child childFilter='docType:child_doc_type']
> > I then get all child documents, even ones which are Blue and Small.
> >
> > How can I include only child documents which match the fq? Is there some
> > way to specify multiple conditions now that I just can't find in the
> docs?
> >
> > Thanks for any help.
> >
>

Security: Better secure defaults?

[David Smiley]

I'm reaching out to our user community to get opinions on what Solr should
do to be more secure-by-default.

TL;DR: Solr 9 has better secure-by-defaults, but maybe we should do more
like have Solr pick some of it's default settings dependent on a new
env=dev|prod.

I was shown a glimpse of a massive list of Solr servers exposed on the
public internet by a security researcher.  I'm kinda blown away that so
many people would be so careless.  I think Solr could and should run with
better "secure-by-default" settings.

The situation will be much better in Solr 9 -- and I'll give a shout-out of
thanks to Rob Muir for helping make this so.  Here's a couple prominent
ones:
* Solr's Jetty now binds to localhost by default, configurable via
SOLR_JETTY_HOST.  Before 9, you can configure a similar thing in the Jetty
config files.  SOLR-13985
* Java's SecurityManager sandbox is enabled by default. -- SOLR-13984.
This option also exists in Solr since 8.5, toggle-able
via SOLR_SECURITY_MANAGER_ENABLED.  Mostly this prevents the worst of
security bugs -- RCE.

I wonder if users will promptly set SOLR_JETTY_HOST=0.0.0.0 to get anything
done?  I think so... but it's something, protecting some users.

Perhaps Solr ought to default to requiring a username/password?  I've heard
this suggestion and it's an obvious one even if some of us (me included)
worry that it would make it too annoying to play with Solr when getting
started.  I think the concerns could be mitigated based on the approach.
If Solr had an opt-in env=dev setting, for example, then Solr could not
insist on authentication, whereas a default env=prod would insist.  Of
course the authentication or lack thereof could be explicitly configured or
disabled at the user's prerogative.  What I like about an "env" setting is
that many other settings could be gated on this as well.

I particularly like the idea of an env=dev|prod setting because a variety
of settings in Solr could have a default that is dependent on this value.
In particular I argue that a env=prod should result in Solr's config APIs
being disabled -- equivalent to -Ddisable.configEdit=true.  I believe a
minority of Solr users actually use these APIs, yet they are frequently a
step in exploiting weaknesses in Solr.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley

Re: Security: Better secure defaults?

[matthew sporleder]

On Thu, May 6, 2021 at 5:25 PM David Smiley  wrote:
>
> I'm reaching out to our user community to get opinions on what Solr should
> do to be more secure-by-default.
>
> TL;DR: Solr 9 has better secure-by-defaults, but maybe we should do more
> like have Solr pick some of it's default settings dependent on a new
> env=dev|prod.
>
> I was shown a glimpse of a massive list of Solr servers exposed on the
> public internet by a security researcher.  I'm kinda blown away that so
> many people would be so careless.  I think Solr could and should run with
> better "secure-by-default" settings.
>
> The situation will be much better in Solr 9 -- and I'll give a shout-out of
> thanks to Rob Muir for helping make this so.  Here's a couple prominent
> ones:
> * Solr's Jetty now binds to localhost by default, configurable via
> SOLR_JETTY_HOST.  Before 9, you can configure a similar thing in the Jetty
> config files.  SOLR-13985
> * Java's SecurityManager sandbox is enabled by default. -- SOLR-13984.
> This option also exists in Solr since 8.5, toggle-able
> via SOLR_SECURITY_MANAGER_ENABLED.  Mostly this prevents the worst of
> security bugs -- RCE.
>
> I wonder if users will promptly set SOLR_JETTY_HOST=0.0.0.0 to get anything
> done?  I think so... but it's something, protecting some users.
>
> Perhaps Solr ought to default to requiring a username/password?  I've heard
> this suggestion and it's an obvious one even if some of us (me included)
> worry that it would make it too annoying to play with Solr when getting
> started.  I think the concerns could be mitigated based on the approach.
> If Solr had an opt-in env=dev setting, for example, then Solr could not
> insist on authentication, whereas a default env=prod would insist.  Of
> course the authentication or lack thereof could be explicitly configured or
> disabled at the user's prerogative.  What I like about an "env" setting is
> that many other settings could be gated on this as well.
>
> I particularly like the idea of an env=dev|prod setting because a variety
> of settings in Solr could have a default that is dependent on this value.
> In particular I argue that a env=prod should result in Solr's config APIs
> being disabled -- equivalent to -Ddisable.configEdit=true.  I believe a
> minority of Solr users actually use these APIs, yet they are frequently a
> step in exploiting weaknesses in Solr.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley

I have also found open solr servers and normally send an email like
"shall I delete your data or wait for you to do it?"

As solr is primarily an index of other data the primary issue is data
disclosure.  Config editing, inserting data, etc are all pretty
secondary.
HTTP Basic Auth with a first-boot-random password is a massively
simple thing built into jetty that will solve 99% of exposed solr
servers.

secure-by-default will decrease adoption without major east-to-follow
warning messages so tread lightly.

Solr and Security; what is CVE worthy?

[David Smiley]

Hello Solr user community,

**What sort of security problems warrant publishing a CVE?**

The Solr PMC grapples with this internally as we have access to messages
sent to secur...@solr.apache.org which report possible vulnerabilities /
security weaknesses in Solr.  Some reporters pressure us to issue a CVE,
which I assume is because it's tied to their livelihood / career in some
way.  In my day job, I also see how my employer takes CVEs quite seriously
as my colleagues and I scramble to do something about them, even when a
vulnerability is quite moot / irrelevant based on how we use / configure
the affected software.  So, CVEs are a big deal and they shouldn't be
issued over minor matters.

I don't think CVEs should be issued for scenarios where there is a clear
failing of a user to secure Solr adequately.  We publish advice on this in
the ref guide, and Solr even complains about Authentication / Authorization
not being configured on startup.  I suspect few users use those plugins but
there are many ways to secure Solr, and users needn't use all means
available.  I confess there is a gray area on what assumptions we have and
on what measures are adequate.

My approach to considering CVE-worthiness is strongly influenced by the
RBAC (Role Based Access Control) permission [4] for the endpoint.  If it's
a "read" based permission, I lean towards a CVE, otherwise, I lean against
it on the grounds that the user probably isn't restricting access to Solr
adequately.  Of course there is no formula to this but I want to share
that.  Also, problems with the access controls themselves are generally CVE
worthy, IMO.

I assert that all Solr components (plugins of all kinds) can be assumed to
be configurable only by trusted users.  Consequently, such components don't
have CVE worthy vulnerabilities *relating to their configuration* if they
can be configured by an attacker to cause harm.  I assert that it's up to
Solr security controls and you, our users, to use them and other controls
to stop an attacker from configuring whatever they please.  For example
someone is likely to report an issue soon relating to the
PingRequestHandler that requires that the attacker can configure it.  Does
this approach sound reasonable?

References:
* [1] Solr's security home page containing a list of CVEs:
https://solr.apache.org/security.html
* [2] Solr Reference Guide -- Securing Solr:
https://solr.apache.org/guide/8_8/securing-solr.html
* [3] Config API -- https://solr.apache.org/guide/8_8/config-api.html at
"/config"
* [4] Authentication / Authorization plugins --
https://solr.apache.org/guide/8_8/authentication-and-authorization-plugins.html
(RBAC -- Role Based Access Control).  The ref guide actually uses the
achronym RBAP.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley

Re: Security: Better secure defaults?

[Eric Pugh]

I think that part of the challenge goes to the deeper issue that configuring 
Solr isn’t easy. We don’t really have the concept of a environment specific 
settings file. I’d love to see a -env=production.yml or -env=development.yml 
type file that was the single place for all settings, and had sane defaults for 
each environment.   Something that worked across Docker, classic installed 
service, or just via a bin/solr start command line ;-).

I am constantly finding new command line config options that I didn’t know 
about ;-)


> On May 6, 2021, at 5:58 PM, matthew sporleder  wrote:
> 
> On Thu, May 6, 2021 at 5:25 PM David Smiley  wrote:
>> 
>> I'm reaching out to our user community to get opinions on what Solr should
>> do to be more secure-by-default.
>> 
>> TL;DR: Solr 9 has better secure-by-defaults, but maybe we should do more
>> like have Solr pick some of it's default settings dependent on a new
>> env=dev|prod.
>> 
>> I was shown a glimpse of a massive list of Solr servers exposed on the
>> public internet by a security researcher.  I'm kinda blown away that so
>> many people would be so careless.  I think Solr could and should run with
>> better "secure-by-default" settings.
>> 
>> The situation will be much better in Solr 9 -- and I'll give a shout-out of
>> thanks to Rob Muir for helping make this so.  Here's a couple prominent
>> ones:
>> * Solr's Jetty now binds to localhost by default, configurable via
>> SOLR_JETTY_HOST.  Before 9, you can configure a similar thing in the Jetty
>> config files.  SOLR-13985
>> * Java's SecurityManager sandbox is enabled by default. -- SOLR-13984.
>> This option also exists in Solr since 8.5, toggle-able
>> via SOLR_SECURITY_MANAGER_ENABLED.  Mostly this prevents the worst of
>> security bugs -- RCE.
>> 
>> I wonder if users will promptly set SOLR_JETTY_HOST=0.0.0.0 to get anything
>> done?  I think so... but it's something, protecting some users.
>> 
>> Perhaps Solr ought to default to requiring a username/password?  I've heard
>> this suggestion and it's an obvious one even if some of us (me included)
>> worry that it would make it too annoying to play with Solr when getting
>> started.  I think the concerns could be mitigated based on the approach.
>> If Solr had an opt-in env=dev setting, for example, then Solr could not
>> insist on authentication, whereas a default env=prod would insist.  Of
>> course the authentication or lack thereof could be explicitly configured or
>> disabled at the user's prerogative.  What I like about an "env" setting is
>> that many other settings could be gated on this as well.
>> 
>> I particularly like the idea of an env=dev|prod setting because a variety
>> of settings in Solr could have a default that is dependent on this value.
>> In particular I argue that a env=prod should result in Solr's config APIs
>> being disabled -- equivalent to -Ddisable.configEdit=true.  I believe a
>> minority of Solr users actually use these APIs, yet they are frequently a
>> step in exploiting weaknesses in Solr.
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
> 
> I have also found open solr servers and normally send an email like
> "shall I delete your data or wait for you to do it?"
> 
> As solr is primarily an index of other data the primary issue is data
> disclosure.  Config editing, inserting data, etc are all pretty
> secondary.
> HTTP Basic Auth with a first-boot-random password is a massively
> simple thing built into jetty that will solve 99% of exposed solr
> servers.
> 
> secure-by-default will decrease adoption without major east-to-follow
> warning messages so tread lightly.

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Re: Security: Better secure defaults?

[matthew sporleder]

One problem I have seen in the past is cultural.  Back when solr was mostly a 
.war file it was very easy to say "secure your own tomcat" but in the era of 
"solr is a database not a web app" it needs to embrace the entirety of that 
distinction.

You can't have it both ways and I am not sure the culture shift was fully 
embraced. 

Another point of feedback is that we have built apps with both solr "clients" 
and a lot of diy with curl so any security settings need to be sane. 

Listen on 0.0.0.0 but only accept traffic from private addresses?  Respect 
x-forwarded-for (and its aliases) in that case.





> On May 6, 2021, at 7:02 PM, Eric Pugh  wrote:
> 
> I think that part of the challenge goes to the deeper issue that configuring 
> Solr isn’t easy. We don’t really have the concept of a environment specific 
> settings file. I’d love to see a -env=production.yml or -env=development.yml 
> type file that was the single place for all settings, and had sane defaults 
> for each environment.   Something that worked across Docker, classic 
> installed service, or just via a bin/solr start command line ;-).
> 
> I am constantly finding new command line config options that I didn’t know 
> about ;-)
> 
> 
>> On May 6, 2021, at 5:58 PM, matthew sporleder  wrote:
>> 
>>> On Thu, May 6, 2021 at 5:25 PM David Smiley  wrote:
>>> 
>>> I'm reaching out to our user community to get opinions on what Solr should
>>> do to be more secure-by-default.
>>> 
>>> TL;DR: Solr 9 has better secure-by-defaults, but maybe we should do more
>>> like have Solr pick some of it's default settings dependent on a new
>>> env=dev|prod.
>>> 
>>> I was shown a glimpse of a massive list of Solr servers exposed on the
>>> public internet by a security researcher.  I'm kinda blown away that so
>>> many people would be so careless.  I think Solr could and should run with
>>> better "secure-by-default" settings.
>>> 
>>> The situation will be much better in Solr 9 -- and I'll give a shout-out of
>>> thanks to Rob Muir for helping make this so.  Here's a couple prominent
>>> ones:
>>> * Solr's Jetty now binds to localhost by default, configurable via
>>> SOLR_JETTY_HOST.  Before 9, you can configure a similar thing in the Jetty
>>> config files.  SOLR-13985
>>> * Java's SecurityManager sandbox is enabled by default. -- SOLR-13984.
>>> This option also exists in Solr since 8.5, toggle-able
>>> via SOLR_SECURITY_MANAGER_ENABLED.  Mostly this prevents the worst of
>>> security bugs -- RCE.
>>> 
>>> I wonder if users will promptly set SOLR_JETTY_HOST=0.0.0.0 to get anything
>>> done?  I think so... but it's something, protecting some users.
>>> 
>>> Perhaps Solr ought to default to requiring a username/password?  I've heard
>>> this suggestion and it's an obvious one even if some of us (me included)
>>> worry that it would make it too annoying to play with Solr when getting
>>> started.  I think the concerns could be mitigated based on the approach.
>>> If Solr had an opt-in env=dev setting, for example, then Solr could not
>>> insist on authentication, whereas a default env=prod would insist.  Of
>>> course the authentication or lack thereof could be explicitly configured or
>>> disabled at the user's prerogative.  What I like about an "env" setting is
>>> that many other settings could be gated on this as well.
>>> 
>>> I particularly like the idea of an env=dev|prod setting because a variety
>>> of settings in Solr could have a default that is dependent on this value.
>>> In particular I argue that a env=prod should result in Solr's config APIs
>>> being disabled -- equivalent to -Ddisable.configEdit=true.  I believe a
>>> minority of Solr users actually use these APIs, yet they are frequently a
>>> step in exploiting weaknesses in Solr.
>>> 
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>> 
>> I have also found open solr servers and normally send an email like
>> "shall I delete your data or wait for you to do it?"
>> 
>> As solr is primarily an index of other data the primary issue is data
>> disclosure.  Config editing, inserting data, etc are all pretty
>> secondary.
>> HTTP Basic Auth with a first-boot-random password is a massively
>> simple thing built into jetty that will solve 99% of exposed solr
>> servers.
>> 
>> secure-by-default will decrease adoption without major east-to-follow
>> warning messages so tread lightly.
> 
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com  
> | My Free/Busy   
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
> 
> 
> This e-mail and all contents, including attachments, is considered to be 
> Company Confidential unless explicitly stated otherwise, regardless of