[PR] POC: Test picocli [solr]
janhoy opened a new pull request, #3247: URL: https://github.com/apache/solr/pull/3247 This is not intended for merge, more to spark a discussion about replacing commons-cli with [picocli](https://picocli.info) in bin/solr. This PR does the following * Parses `bin/solr` with picocli by default but also retain commons-cli for comparison. Switch using `SOLR_PICOCLI=false` * Implements `VersionTool`, `HealthcheckTool` and `StatusTool` as sub commands * New `ZkTool` sub command, which in turn has `ZkLsTool` as a sub command * Demonstrate use of custom `defaultValueProvider` to let `--zk-host` option look for a value in environment Implementing this took 2-3 hours. The annotation approach removes the need to lots of boilerplate, and the framework is fairly flexible. It should be doable to cover the rest of the tools within a few days. Following this approach we can validate old vs new output in the same codebase, and then remove commons-cli once everything is up to date. Remaining research to do option inheritance in a proper way, tailor the output formatting as we wish, implementing option groups for mutual exclusive and opts etc, and extend `defaultValueProvider` to handle default values for more options. Sample output for `bin/solr -h`: ``` Usage: solr [-hv] [COMMAND] Global options: -h, --help Display this help message -v, --version Print version information and exit Commands: status Get the status of a Solr server. healthcheck Check the health of a SolrCloud collection. version Prints the Solr version. zk Sub commands for working with ZooKeeper. SolrCloud example (embedded Zookeeper): ./solr start -c For more help on how to use Solr, head to https://solr.apache.org/ ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16305) MODIFYCOLLECTION with 'property.*' changes can't change values used in config file variables (even though they can be set during collection CREATE)
[
https://issues.apache.org/jira/browse/SOLR-16305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933574#comment-17933574
]
Chris M. Hostetter commented on SOLR-16305:
---
{quote}The table above might've had a column to represent core.properties
persistence, but I omitted that as it seems like an implementation detail that
users are unlikely to care about. Am I missing something there?
{quote}
I would generally agree with you that {{core.properties}} persistence _should_
be an implementation detail – but at the moment our ref-guide makes many
references to that file, and describes the entire concept/functionality of
"substitutable properties in config files" around the existence & contents of
this file – so whatever approach is taken to rectify/unify the various types of
"property apis" needs to ensure that the ref-guide is updated to either remove
all references to {{core.properties}} (or mention it only in the context of
being an implementation detail) and explain the _concepts_ in a way that
doesn't say "adds to this file"
—
{quote}Quick summary of the current state-of-play:
{quote}
I would argue that one thing that isn't in your table but deserves equal
consideration is {{ADDREPLICAPROP}} – if we're going to go to the trouble to
cleanup & unify the way collection level props are tracked & stored & usable in
config file variable substitutions, we should ideally also think about
how/where replica level props are tracked & stored & ensure that they can also
be used in config file variable substitutions (such that replica props should
override collection props which should override system props)
> MODIFYCOLLECTION with 'property.*' changes can't change values used in config
> file variables (even though they can be set during collection CREATE)
> ---
>
> Key: SOLR-16305
> URL: https://issues.apache.org/jira/browse/SOLR-16305
> Project: Solr
> Issue Type: Bug
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-16305_test.patch
>
>
> Consider a configset with a {{solrconfig.xml}} that includes a snippet like
> this...
> {code:java}
> ${custom.prop:customDefVal}
> {code}
> ...this {{custom.prop}} can be set when doing a {{CREATE}} command for a
> collection that uses this configset, using the {{property.*}} prefix as noted
> in the reg-guide...
> {quote}{{property.{_}name{_}={_}value{_}}}
> |Optional|Default: none|
> Set core property _name_ to {_}value{_}. See the section [Core
> Discovery|https://solr.apache.org/guide/solr/latest/configuration-guide/core-discovery.html]
> for details on supported properties and values.
> {quote}
> ...BUT
> These values can *not* be changed by using the {{MODIFYCOLLECTION}} command,
> in spite of the ref-guide indicating that it can be used to modify custom
> {{property.*}} attributes...
> {quote}The attributes that can be modified are:
> * {{replicationFactor}}
> * {{collection.configName}}
> * {{readOnly}}
> * other custom properties that use a {{property.}} prefix
> See the [CREATE
> action|https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create]
> section above for details on these attributes.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17656) Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING
[
https://issues.apache.org/jira/browse/SOLR-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933573#comment-17933573
]
Chris M. Hostetter commented on SOLR-17656:
---
[~houston] - i appreciate your help w/the test – but after reading your change
a couple of times now, and looking at the old version vs the new version, and
re-running w/your exact seed (and confirming that
{{testSkipLeaderRecoveryProperty}} ran before {{testRealTimeGet}}) I still
can't for the life of me understand when/why that failures would have happened
(in a way that your commit would now reliably prevent it from happening)
If the issue is that one of the jetties never restarted (or restarted too
slowly), then...
* I'd expect {{testSkipLeaderRecoveryProperty}} should have failed as well? ..
and if it didn't we shoudl also harden it's assertions
** but even then, i'd expect {{testRealTimeGet}} to timeout or fail when
creating it's collection -- not when adding a doc to that collection
* But also: {{testSkipLeaderRecoveryProperty}} isn't the first test in this
class to stop/restart jetty instances -- so if that's the problem it seems like
it could happen in other test methods as well, and the better fix would be to
put your "wait for live nodes" logic in a before/after method
...can you help walk me through what exactly the problem was and how your patch
fixed it?
> Add expert level option to allowe PULL replicas to go ACTIVE w/o RECOVERING
> ---
>
> Key: SOLR-17656
> URL: https://issues.apache.org/jira/browse/SOLR-17656
> Project: Solr
> Issue Type: New Feature
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Fix For: main (10.0), 9.9
>
> Attachments: SOLR-17656-1.patch, SOLR-17656.patch
>
>
> In situations where a Solr cluster undergoes a rolling restart (or some other
> "catastrophic" failure situations requiring/causing solr node restarts) there
> can be a snowball effect of poor performance (or even solr node crashing) due
> to fewer then normal replicas serving query requests while replicas on
> restarting nodes are DOWN or RECOVERING – especially if shard leaders are
> also affected, and (restarting) replicas first must wait for a leader
> election before they can recover (or wait to finish recovery from an
> over-worked leader).
> For NRT type usecases, RECOVERING is really a necessary evil to ensure every
> replicas is up to date before handling NRT requests – but in the case of PULL
> replicas, which are expected to routinely "lag" behind their leader, I've
> talked to a lot of Solr users w/usecases where they would be happy to have
> PULL replicas back online serving "stale" data ASAP, and let normal
> IndexFetching "catchup" with the leader later.
> I propose we support a new "advanced" replica property that can be set on
> PULL replicas by expert level users, to indicate: on (re)init, these replicas
> may skip RECOVERING and go directly to ACTIVE.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17607) HTTP ClusterStateProvider should defer talking to Solr until first use
[ https://issues.apache.org/jira/browse/SOLR-17607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley reassigned SOLR-17607: --- Assignee: David Smiley > HTTP ClusterStateProvider should defer talking to Solr until first use > -- > > Key: SOLR-17607 > URL: https://issues.apache.org/jira/browse/SOLR-17607 > Project: Solr > Issue Type: Improvement > Components: SolrCloud, SolrJ >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > > When using CloudSolrClient with HTTP URLs to get the ClusterState (HTTP > ClusterStateProvider), it will talk to Solr when the client is created to > fetch the live nodes. But maybe Solr isn't available at this time; it's > annoying to require that Solr is available at the time that the > CloudSolrClient is constructed. The ZK one is deferred till first use; I > propose the same behavior for HTTP. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17607) HTTP ClusterStateProvider should defer talking to Solr until first use
[ https://issues.apache.org/jira/browse/SOLR-17607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17607: -- Labels: pull-request-available (was: ) > HTTP ClusterStateProvider should defer talking to Solr until first use > -- > > Key: SOLR-17607 > URL: https://issues.apache.org/jira/browse/SOLR-17607 > Project: Solr > Issue Type: Improvement > Components: SolrCloud, SolrJ >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > When using CloudSolrClient with HTTP URLs to get the ClusterState (HTTP > ClusterStateProvider), it will talk to Solr when the client is created to > fetch the live nodes. But maybe Solr isn't available at this time; it's > annoying to require that Solr is available at the time that the > CloudSolrClient is constructed. The ZK one is deferred till first use; I > propose the same behavior for HTTP. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17607: Http ClusterStateProvider, lazy connect [solr]
dsmiley commented on PR #3249: URL: https://github.com/apache/solr/pull/3249#issuecomment-2708689884 CC @mlbiscoc -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[PR] SOLR-17607: Http ClusterStateProvider, lazy connect [solr]
dsmiley opened a new pull request, #3249: URL: https://github.com/apache/solr/pull/3249 i.e. stop eagerly connecting when CloudSolrClient is created. https://issues.apache.org/jira/browse/SOLR-17607 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17695) Don't warn user about solr url context having /solr when not passed in by user
Eric Pugh created SOLR-17695: Summary: Don't warn user about solr url context having /solr when not passed in by user Key: SOLR-17695 URL: https://issues.apache.org/jira/browse/SOLR-17695 Project: Solr Issue Type: Improvement Components: cli Affects Versions: 9.8 Reporter: Eric Pugh Assignee: Eric Pugh We look up the solr host from Solr, and the "baseUrl" has a trailing /solr, and then in the CLI we flag that you aren't supposed to do this, but since the user isn't submitting this value, it's missleading! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17695) Misleading warning in bin/solr start -e examples about solr url format
[ https://issues.apache.org/jira/browse/SOLR-17695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-17695: - Summary: Misleading warning in bin/solr start -e examples about solr url format (was: Don't warn user about solr url context having /solr when not passed in by user) > Misleading warning in bin/solr start -e examples about solr url format > -- > > Key: SOLR-17695 > URL: https://issues.apache.org/jira/browse/SOLR-17695 > Project: Solr > Issue Type: Improvement > Components: cli >Affects Versions: 9.8 >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > > We look up the solr host from Solr, and the "baseUrl" has a trailing /solr, > and then in the CLI we flag that you aren't supposed to do this, but since > the user isn't submitting this value, it's missleading! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17695) Misleading warning in bin/solr start -e examples about solr url format
[ https://issues.apache.org/jira/browse/SOLR-17695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-17695: - Description: We look up the solr host from Solr, and the "baseUrl" has a trailing /solr, and then in the CLI we flag that you aren't supposed to do this, but since the user isn't submitting this value, it's missleading! This cleans up what we output to the console. was:We look up the solr host from Solr, and the "baseUrl" has a trailing /solr, and then in the CLI we flag that you aren't supposed to do this, but since the user isn't submitting this value, it's missleading! > Misleading warning in bin/solr start -e examples about solr url format > -- > > Key: SOLR-17695 > URL: https://issues.apache.org/jira/browse/SOLR-17695 > Project: Solr > Issue Type: Improvement > Components: cli >Affects Versions: 9.8 >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > > We look up the solr host from Solr, and the "baseUrl" has a trailing /solr, > and then in the CLI we flag that you aren't supposed to do this, but since > the user isn't submitting this value, it's missleading! > > This cleans up what we output to the console. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17638 Some CLI errors not logged when starting prometheus exporter [solr]
epugh commented on PR #3236: URL: https://github.com/apache/solr/pull/3236#issuecomment-2708306236 @stillalex your plan makes sense to me! It LGTM. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17695) Misleading warning in bin/solr start -e examples about solr url format
[ https://issues.apache.org/jira/browse/SOLR-17695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-17695: -- Labels: pull-request-available (was: ) > Misleading warning in bin/solr start -e examples about solr url format > -- > > Key: SOLR-17695 > URL: https://issues.apache.org/jira/browse/SOLR-17695 > Project: Solr > Issue Type: Improvement > Components: cli >Affects Versions: 9.8 >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We look up the solr host from Solr, and the "baseUrl" has a trailing /solr, > and then in the CLI we flag that you aren't supposed to do this, but since > the user isn't submitting this value, it's missleading! > > This cleans up what we output to the console. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17309) Enhance Cert Authentication plugin with flexible cert principal resolution
[
https://issues.apache.org/jira/browse/SOLR-17309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933527#comment-17933527
]
ASF subversion and git services commented on SOLR-17309:
Commit a7fdb21cb851a1db7a713f0cad31ff2cf7425476 in solr's branch
refs/heads/branch_9x from Lamine
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=a7fdb21cb85 ]
SOLR-17309: Enhance certificate based authentication plugin with flexible cert
principal resolution (#3029)
-
Co-authored-by: Lamine Idjeraoui
Co-authored-by: Eric Pugh
(cherry picked from commit 9d2118bafb885f983d033c85c8a3accac11c0faa)
> Enhance Cert Authentication plugin with flexible cert principal resolution
> --
>
> Key: SOLR-17309
> URL: https://issues.apache.org/jira/browse/SOLR-17309
> Project: Solr
> Issue Type: Improvement
>Reporter: Lamine
>Priority: Minor
> Labels: pull-request-available
> Fix For: 9.9
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> TL;DR
> This the first part of a broader contribution to enhance CertAuthPlugin to
> support _Principal_ resolution, identity resolution and validation.
> This part deals with _Principal_ resolution.
> —
> Solr supports certificate-based authentication (mTLS) via the CertAuthPlugin.
> However, the feature offers limited flexibility. In fact, the class contains
> minimal code, primarily deferring certificate validation to Jetty and
> extracting the _Principal_ from the subject's Distinguish Name (DN). The
> Authorization plugin then maps the extracted _Principal_ to a role.
> I've identified a couple of issues with this approach, as well as potential
> areas for enhancement:
> *1- Issues with Using DN*
> - {*}Length and precision{*}: The DN is lengthy and requires an exact match
> for roles mapping. Even a minor discrepancy, like an extra space, or order of
> attributes (RDN), can break the mapping.
> - {*}One DN per certificate{*}: If different certificates are used for
> different hosts in a cluster, each DN has to be mapped separately to a
> particular role, complicating role mapping and increasing risks of errors.
> - {*}Not customizable{*}: The current implementation doesn't allow operators
> to adapt the Principal extracting to their specific needs.
> - {*}Bad user experience{*}: When logged into Solr Admin UI using
> CertAuthPlugin the whole DN is displayed on the left menu as the 'username'.
> _*Proposed Solution for DN Issues:*_
> - Extraction flexibility: Grant operators the ability to specify the data
> they wish to extract for the {_}Principal{_}, based on a defined path (for
> example: _SUBJECT.DN_ (default), {_}SAN.URI{_}, {_}SAN.email{_}, etc.).
> - Use of delimiters: Introduce optional delimiters (start and end) or
> prefix/suffix to extract only the necessary data from a field, for example a
> group ID.
> **
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17692) DELETEREPLICA should preempt full-recovery instead of waiting for completion
[ https://issues.apache.org/jira/browse/SOLR-17692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933035#comment-17933035 ] Jason Gerlowski commented on SOLR-17692: Solr makes a pretty good attempt to handle this case, but either it never targeted full-recovery, or something broke since the code was added. [CoreContainer.unload|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/core/CoreContainer.java#L2191-L2198], which does most of the processing for a DELETEREPLICA, makes two method calls in an attempt to preempt: * [core.getSolrCoreState().cancelRecovery()|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L383-L391] - aims to cover recovery "proper", and is most relevant to the case in the issue description above. * [zkSys.getZkController().stopReplicationFromLeader(...)|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L1503-L15] - preempts the periodically-triggered "background" replication done by PULL and TLOG replicas in the course of normal operation [DefaultSolrCoreState.cancelRecovery|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L383-L391] calls RecoveryStrategy.close(), which sets a boolean flag that the RecoveryStrategy checks at various points and can be used to early-exit. This all works great so far as it goes. The problem though is that the bulk of the logic for a full-recovery, including the loop to iterate over and fetch index files from the leader, lives elsewhere (particularly [ReplicationHandler.doFetch|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java#L452] and [IndexFetcher.fetchLatestIndex|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/IndexFetcher.java#L405]) and doesn't have access to RecoveryStrategy and its early-exit flag. So in practice once a full-recovery starts fetching files from the leader, it won't check RecoveryStrategy's early-exit flag again until it's finished. Interestingly, IndexFetcher has [its own early-exit flag|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/IndexFetcher.java#L1569-L1571] that can be set by a call to IndexFetcher.destroy(), and it is already used for preemption in the PULL/TLOG replica "background replication" scenario. This flag [_does_ get checked|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/IndexFetcher.java#L1747-L1751] in the "iterate and fetch each leader index file" loop, so it seems like a really great option for our case, if we can find a way to set it from [DefaultSolrCoreState.cancelRecovery|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java#L383-L391]. > DELETEREPLICA should preempt full-recovery instead of waiting for completion > > > Key: SOLR-17692 > URL: https://issues.apache.org/jira/browse/SOLR-17692 > Project: Solr > Issue Type: Bug > Components: replication (java), SolrCloud >Reporter: Jason Gerlowski >Priority: Major > > I recently deleted a NRT replica that was in the middle of a full-recovery > and was a bit surprised to see that the "delete" blocked waiting for the > recovery to finish. This is a minor pain when the index is small, but > becomes a huge waste of administrator time (and network bandwidth!) as index > sizes grow. > There's some plumbing in Solr that attempts to preempt recovery during a > DELETE, but it appears that it seems that it mostly comes into play during > peer-sync and "background replication" scenarios (i.e. PULL and TLOG replicas > that do full-recovery during normal operation). Preemption doesn't seem to > work once a recovering core is in the midst of a "full recovery". We should > modify this code that it stops full-recovery as well, unless there's some > compelling reason this was avoided in the initial implementation? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17638 Some CLI errors not logged when starting prometheus exporter [solr]
stillalex commented on PR #3236: URL: https://github.com/apache/solr/pull/3236#issuecomment-2708301043 @epugh could you take one final look? and I think I will wait for https://github.com/apache/solr/pull/3240 to merge and will aim at going in after it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17309) Enhance Cert Authentication plugin with flexible cert principal resolution
[
https://issues.apache.org/jira/browse/SOLR-17309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933526#comment-17933526
]
ASF subversion and git services commented on SOLR-17309:
Commit 9d2118bafb885f983d033c85c8a3accac11c0faa in solr's branch
refs/heads/main from Lamine
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=9d2118bafb8 ]
SOLR-17309: Enhance certificate based authentication plugin with flexible cert
principal resolution (#3029)
-
Co-authored-by: Lamine Idjeraoui
Co-authored-by: Eric Pugh
> Enhance Cert Authentication plugin with flexible cert principal resolution
> --
>
> Key: SOLR-17309
> URL: https://issues.apache.org/jira/browse/SOLR-17309
> Project: Solr
> Issue Type: Improvement
>Reporter: Lamine
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> TL;DR
> This the first part of a broader contribution to enhance CertAuthPlugin to
> support _Principal_ resolution, identity resolution and validation.
> This part deals with _Principal_ resolution.
> —
> Solr supports certificate-based authentication (mTLS) via the CertAuthPlugin.
> However, the feature offers limited flexibility. In fact, the class contains
> minimal code, primarily deferring certificate validation to Jetty and
> extracting the _Principal_ from the subject's Distinguish Name (DN). The
> Authorization plugin then maps the extracted _Principal_ to a role.
> I've identified a couple of issues with this approach, as well as potential
> areas for enhancement:
> *1- Issues with Using DN*
> - {*}Length and precision{*}: The DN is lengthy and requires an exact match
> for roles mapping. Even a minor discrepancy, like an extra space, or order of
> attributes (RDN), can break the mapping.
> - {*}One DN per certificate{*}: If different certificates are used for
> different hosts in a cluster, each DN has to be mapped separately to a
> particular role, complicating role mapping and increasing risks of errors.
> - {*}Not customizable{*}: The current implementation doesn't allow operators
> to adapt the Principal extracting to their specific needs.
> - {*}Bad user experience{*}: When logged into Solr Admin UI using
> CertAuthPlugin the whole DN is displayed on the left menu as the 'username'.
> _*Proposed Solution for DN Issues:*_
> - Extraction flexibility: Grant operators the ability to specify the data
> they wish to extract for the {_}Principal{_}, based on a defined path (for
> example: _SUBJECT.DN_ (default), {_}SAN.URI{_}, {_}SAN.email{_}, etc.).
> - Use of delimiters: Introduce optional delimiters (start and end) or
> prefix/suffix to extract only the necessary data from a field, for example a
> group ID.
> **
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17309) Enhance Cert Authentication plugin with flexible cert principal resolution
[
https://issues.apache.org/jira/browse/SOLR-17309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-17309.
--
Fix Version/s: 9.9
Resolution: Fixed
> Enhance Cert Authentication plugin with flexible cert principal resolution
> --
>
> Key: SOLR-17309
> URL: https://issues.apache.org/jira/browse/SOLR-17309
> Project: Solr
> Issue Type: Improvement
>Reporter: Lamine
>Priority: Minor
> Labels: pull-request-available
> Fix For: 9.9
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> TL;DR
> This the first part of a broader contribution to enhance CertAuthPlugin to
> support _Principal_ resolution, identity resolution and validation.
> This part deals with _Principal_ resolution.
> —
> Solr supports certificate-based authentication (mTLS) via the CertAuthPlugin.
> However, the feature offers limited flexibility. In fact, the class contains
> minimal code, primarily deferring certificate validation to Jetty and
> extracting the _Principal_ from the subject's Distinguish Name (DN). The
> Authorization plugin then maps the extracted _Principal_ to a role.
> I've identified a couple of issues with this approach, as well as potential
> areas for enhancement:
> *1- Issues with Using DN*
> - {*}Length and precision{*}: The DN is lengthy and requires an exact match
> for roles mapping. Even a minor discrepancy, like an extra space, or order of
> attributes (RDN), can break the mapping.
> - {*}One DN per certificate{*}: If different certificates are used for
> different hosts in a cluster, each DN has to be mapped separately to a
> particular role, complicating role mapping and increasing risks of errors.
> - {*}Not customizable{*}: The current implementation doesn't allow operators
> to adapt the Principal extracting to their specific needs.
> - {*}Bad user experience{*}: When logged into Solr Admin UI using
> CertAuthPlugin the whole DN is displayed on the left menu as the 'username'.
> _*Proposed Solution for DN Issues:*_
> - Extraction flexibility: Grant operators the ability to specify the data
> they wish to extract for the {_}Principal{_}, based on a defined path (for
> example: _SUBJECT.DN_ (default), {_}SAN.URI{_}, {_}SAN.email{_}, etc.).
> - Use of delimiters: Introduce optional delimiters (start and end) or
> prefix/suffix to extract only the necessary data from a field, for example a
> group ID.
> **
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17309: Enhance certificate based authentication plugin with flexible cert principal resolution [solr]
epugh merged PR #3029: URL: https://github.com/apache/solr/pull/3029 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17695: Don't warn user about solrUrl format when they do not supply it [solr]
epugh commented on PR #3246: URL: https://github.com/apache/solr/pull/3246#issuecomment-2708341416 This is small enough, not putting it in CHANGES.txt -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
