Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SOLR-16980 Connect to SOLR standalone with basic authentication #1957

Merged
merged 10 commits into from
Sep 26, 2023

Conversation

stillalex
Copy link
Member

https://issues.apache.org/jira/browse/SOLR-16980

Description

Adding support for passing basic auth details to cli command

Solution

Please provide a short description of the approach taken to implement your solution.

Tests

Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.

Checklist

Please review the following and check all that apply:

  • I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
  • I have created a Jira issue and added the issue ID to my pull request title.
  • I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
  • I have developed this patch against the main branch.
  • I have run ./gradlew check.
  • I have added tests for my changes.
  • I have added documentation for the Reference Guide

@epugh
Copy link
Contributor

epugh commented Sep 25, 2023

Awesome work @stillalex .... Have you looked at #1954 (SOLR-14496) where I took a stab at adding credentials to the SolrCLI? It would be great if we used the same patterns in both there AND here... For example, I went with -u eric:password instead of seperate username and password params, mostly because curl does it that way!

Sigh, in looking, looks like we use net.sourceforge.argparse4j instead of commons-cli... Wish we picked one CLI arg parser for them all!

Lastly, are there any improvements here that could be reused in better handling of the CLI stuff? Would that change any of this code?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this class? Probably, but I wonder if it actually is required with all the other builders we have for Solr Clients? Seems a shame to have "YASCB". yet another solr client builder..... ;-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it wires the existing builders with params passed via cli, it didn't fee like a big problem to me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I just wished we could use one of the other factory/builders we have.. You are right that this probably isn't a big deal ;-)...

@@ -96,6 +96,20 @@ public class SolrExporter {
+ ARG_NUM_THREADS_DEFAULT
+ ".";

private static final String[] ARG_USER_FLAGS = {"-u", "--user"};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

at least we have --user instead of -user, over on SolrCLI, we want to get to the -- pattern!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved it all to 'credentials' similar to the example PR.

@@ -242,6 +256,22 @@ public static void main(String[] args) {
.setDefault(ARG_CLUSTER_ID_DEFAULT)
.help(ARG_CLUSTER_ID_HELP);

parser
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious if we love this parser or not for CLI args??? THoughts on this versus the commons-cli ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used what was there already :( I can take a stab at rewriting this cli code on top of commons-cli

if (!res.getString(ARG_USER_DEST).isEmpty() && !res.getString(ARG_PASSWORD_DEST).isEmpty()) {
String user = res.getString(ARG_USER_DEST);
String password = res.getString(ARG_PASSWORD_DEST);
scrapeConfiguration.withBasicAuthCredentials(user, password);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i ended up littering the #1954 code iwth lots of things that look like this too ;-).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have you seen the new "sane defaults" security.json? It declares four roles, index, search, admin, and superadmin. I wonder if it would make sense to add a "monitor" role to that as part of this? So you do:

bin/solr auth...

and now you are ready for Prometheus?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similar to the kubernetes setup (I think)? sounds like a good idea

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the "default" security.json that we now have! https://github.com/apache/solr/blob/main/solr/core/src/resources/security.json

Copy link
Member Author

@stillalex stillalex Sep 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see a metrics-read permission here. is this what you were hinting to? like maybe add a role to include this one

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, a "metrics" role or a "monitor" role that has what you would need, that way you don't have to figure that stuff out just to use Prometheus... (assuming there are some logical permissions you need)

public static void setupSolrHome() throws Exception {
Path solrHome = LuceneTestCase.createTempDir();
Files.copy(
SolrTestCaseJ4.TEST_PATH().resolve("security.json"), solrHome.resolve("security.json"));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a thought... that if security.json isn't special for your test, just use the one that now ships with Solr?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it only has a user+pass. if one already exists and is available to this module I can try to use it, sure

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

trying to find an example for this. would you happen to have one that I could use as a reference?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thin the trouble is prometheus module does not depend on core (not even for testing)? bringing that in just for access to the security file might be overkill.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah.. yeah.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

found a cleaner way. removed the file and I am recreating it as needed.

25, new SolrNamedThreadFactory("solr-cloud-scraper-tests"));
solrScraper = new SolrStandaloneScraper(solrClient, executor, "test");

Helpers.indexAllDocs(solrClient);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't love this class name? Helpers feels very generic... Also, we don't have the equivaletn of indexAllDocs somewhere already?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah. class name is the existing test class name plus BasicAuth :) I can change if you think there is a better name

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, the class name I didn't love was Helpers... ;-) I feel like that method indexAllDocs must exist already!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah right. this was already there. I picked up the SolrStandaloneScraperTest test (cleaned it up a bit) and added basic auth to it. indexAllDocs will actually index a local copy of the solr examples files. I'm pretty sure this was not strictly needed for this, but yeah I didn't add any of it.

Files.copy(top.resolve("managed-schema.xml"), subHome.resolve("schema.xml"));
Files.copy(top.resolve("solrconfig.xml"), subHome.resolve("solrconfig.xml"));

Files.copy(top.resolve("stopwords.txt"), subHome.resolve("stopwords.txt"));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wish we had a different more minimal config that dind't drag along stopwords and synnymos....

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

trouble with using the minimal config is that the data indexed here uses multi value strings heavily which is not allowed in the existing min config. it will fail indexing, so this is the best I could come up with

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense. Maybe someday we figure out how many tests actually want stopwords, or which ones want stopwords, and only have those tests depend on it!

@@ -127,7 +136,7 @@ public void metricsForHost() throws Exception {
assertEquals(1, metricsByHost.size());

List<Collector.MetricFamilySamples> replicaSamples =
metricsByHost.get(restTestHarness.getAdminURL()).asList();
metricsByHost.get(solrRule.getBaseUrl()).asList();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool!

@stillalex
Copy link
Member Author

thank you for the review @epugh!

Awesome work @stillalex .... Have you looked at #1954 (SOLR-14496) where I took a stab at adding credentials to the SolrCLI? It would be great if we used the same patterns in both there AND here... For example, I went with -u eric:password instead of seperate username and password params, mostly because curl does it that way!

I have not, no. will take a look and try to make it consistent with #1954. -u style works too I don't have a strong preference here.

Sigh, in looking, looks like we use net.sourceforge.argparse4j instead of commons-cli... Wish we picked one CLI arg parser for them all!

strange. did not even notice this until you said it. will try to see how complicated the refactor to commons-cli would be

@epugh
Copy link
Contributor

epugh commented Sep 25, 2023

thank you for the review @epugh!

Awesome work @stillalex .... Have you looked at #1954 (SOLR-14496) where I took a stab at adding credentials to the SolrCLI? It would be great if we used the same patterns in both there AND here... For example, I went with -u eric:password instead of seperate username and password params, mostly because curl does it that way!

I have not, no. will take a look and try to make it consistent with #1954. -u style works too I don't have a strong preference here.

Sigh, in looking, looks like we use net.sourceforge.argparse4j instead of commons-cli... Wish we picked one CLI arg parser for them all!

strange. did not even notice this until you said it. will try to see how complicated the refactor to commons-cli would be

Also, not wedded to commons-cli... I think if the community likes argparse4j, then happy to go that way as well ;-)

@@ -96,6 +96,13 @@ public class SolrExporter {
+ ARG_NUM_THREADS_DEFAULT
+ ".";

private static final String[] ARG_CREDENTIALS_FLAGS = {"-u", "--credentials"};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Loving it!

@stillalex
Copy link
Member Author

@epugh re. commons-cli vs argparse4j I want to take a stab at rewriting, but I would like to do it as a part of a different PR as an improvement. for this PR i am focusing on resolving a regression: not being able to use prometheus with basic auth. if that works for you I will create another Jira to track it so it doesn't get lost.

@epugh
Copy link
Contributor

epugh commented Sep 25, 2023

@epugh re. commons-cli vs argparse4j I want to take a stab at rewriting, but I would like to do it as a part of a different PR as an improvement. for this PR i am focusing on resolving a regression: not being able to use prometheus with basic auth. if that works for you I will create another Jira to track it so it doesn't get lost.

Awesome! Totally agree! You could link it to https://issues.apache.org/jira/browse/SOLR-16757 which is what I'm using to guide me in trying to get our varous CLI's to a better place.

@stillalex
Copy link
Member Author

sure, created SOLR-16996 and linked to umbrella ticket.

@stillalex stillalex merged commit 61d41e5 into apache:main Sep 26, 2023
2 checks passed
@stillalex stillalex deleted the SOLR-16980-prometheus-basicauth branch September 26, 2023 13:14
stillalex added a commit that referenced this pull request Sep 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants