Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-8440

Script support for enabling basic auth

    Details

      Description

      Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin (SOLR-8429), it would be sweet to provide a super simple way to "Password protect Solr"™ right from the command line:

      bin/solr basicAuth -adduser -user solr -pass SolrRocks
      

      It would take the mystery out of enabling one single password across the board. The command would do something like this

      1. Check if HTTPS is enabled, and if not, print a friendly warning
      2. Check if /security.json already exists
        1. NO => create one with only plugin class defined
        2. YES => Abort if exists but plugin is not BasicAuthPlugin
      3. Using security REST API, add the new user
      1. SOLR-8440.patch
        18 kB
        Ishan Chattopadhyaya
      2. SOLR-8440.patch
        18 kB
        Ishan Chattopadhyaya
      3. SOLR-8440.patch
        12 kB
        Ishan Chattopadhyaya
      4. SOLR-8440.patch
        14 kB
        Ishan Chattopadhyaya
      5. SOLR-8440.patch
        13 kB
        Ishan Chattopadhyaya
      6. SOLR-8440.patch
        13 kB
        Ishan Chattopadhyaya
      7. SOLR-8440.patch
        9 kB
        Ishan Chattopadhyaya
      8. SOLR-8440.patch
        6 kB
        Ishan Chattopadhyaya
      9. SOLR-8440-follow-up.patch
        31 kB
        Ishan Chattopadhyaya
      10. SOLR-8440-follow-up.patch
        19 kB
        Ishan Chattopadhyaya
      11. SOLR-8840_opt_parsing.patch
        28 kB
        Jan Høydahl

        Issue Links

          Activity

          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          I'm planning to work on this soon.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - I'm planning to work on this soon.
          Hide
          noble.paul Noble Paul added a comment -

          I guess we must enable RulebasedAuthorization as well. ensure that collection-admin-edit, core-admin-edit,security-edit are protected

          Show
          noble.paul Noble Paul added a comment - I guess we must enable RulebasedAuthorization as well. ensure that collection-admin-edit , core-admin-edit , security-edit are protected
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Agreed.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Agreed.
          Hide
          janhoy Jan Høydahl added a comment -

          For this feature I simply intended to add ONE user which can do everything (blockUnknown=true), and if you don't authenticate you cannot do anything. That's the first, simplest, most logical and most useful step for a random user. We should probably have a usage like this for completeness and future proof:

          bin/solr auth -type basic <adduser|deluser|setprop|delprop> [-user <user>] [-pass <pass>] [-prop <key>[=value]]
          

          Let's create another JIRAs for enabling Authorization, defining groups, adding users to groups etc...

          Show
          janhoy Jan Høydahl added a comment - For this feature I simply intended to add ONE user which can do everything (blockUnknown=true), and if you don't authenticate you cannot do anything. That's the first, simplest, most logical and most useful step for a random user. We should probably have a usage like this for completeness and future proof: bin/solr auth -type basic <adduser|deluser|setprop|delprop> [-user <user>] [-pass <pass>] [-prop <key>[=value]] Let's create another JIRAs for enabling Authorization, defining groups, adding users to groups etc...
          Hide
          janhoy Jan Høydahl added a comment -

          Or perhaps multiple sub commands for the various steps

          bin/solr auth enable [-f] -type <basic|kerberos|hadoop>   # -f Force to change from existing?
          # This sets an empty {{authentication}} object with class only in security.json, now you can start using the REST API if you wish
          bin/solr auth [--user=solr:SolrRocks] setuser <user=pass>
          bin/solr auth property [-d] <key=prop>
          
          Show
          janhoy Jan Høydahl added a comment - Or perhaps multiple sub commands for the various steps bin/solr auth enable [-f] -type <basic|kerberos|hadoop> # -f Force to change from existing? # This sets an empty {{authentication}} object with class only in security.json, now you can start using the REST API if you wish bin/solr auth [--user=solr:SolrRocks] setuser <user=pass> bin/solr auth property [-d] <key=prop>
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited

          WIP patch.

          1. Introduces the "auth" command, e.g. bin/solr auth -enable -type basic -adminuser solr -adminpassword SolrRocks
          2. Support for optional blocksUnknown (false by default)
          3. TODO: Put the hash of the password. Currently hardcoded to hash of "SolrRocks"
          4. TODO: Introduce a separate file and put the admin username/password there for use by the script. If user wants, the bin/solr.in.sh can be used to override this user/pw. Added auth.overlay.sh file, which is applied after solr.in.sh has been applied. This file is created during -enable, and deleted during -disable.
          5. TODO: Do pre-checks before enabling; don't do anything if already enabled.
          6. Uploads the following security.json by default (apart from the user/password hash variant.
          7. TODO: Windows script (bin/solr.cmd)
          {
            "authentication":{
             "blockUnknown": $blockUnknown
             "class":"solr.BasicAuthPlugin",
             "credentials":{$user:$saltedhash_of_password}
            },
            "authorization":{
             "class":"solr.RuleBasedAuthorizationPlugin",
             "permissions":[
          	{"name":"security-edit", "role":"admin"},
          	{"name":"collection-admin-edit", "role":"admin"},
          	{"name":"core-admin-edit", "role":"admin"}
             ],
             "user-role":{"$user":"admin"}
            }
          }
          

          With just this in place (after fixing TODOs and nocommits), one can enable basicauth with typical authz configuration. After this, the user can use the REST API for authc/authz, or we can build further support for adding users, roles etc. to the script.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited WIP patch. Introduces the "auth" command, e.g. bin/solr auth -enable -type basic -adminuser solr -adminpassword SolrRocks Support for optional blocksUnknown (false by default) TODO: Put the hash of the password. Currently hardcoded to hash of "SolrRocks" TODO: Introduce a separate file and put the admin username/password there for use by the script. If user wants, the bin/solr.in.sh can be used to override this user/pw. Added auth.overlay.sh file, which is applied after solr.in.sh has been applied. This file is created during -enable, and deleted during -disable. TODO: Do pre-checks before enabling; don't do anything if already enabled. Uploads the following security.json by default (apart from the user/password hash variant. TODO: Windows script (bin/solr.cmd) { "authentication" :{ "blockUnknown" : $blockUnknown "class" : "solr.BasicAuthPlugin" , "credentials" :{$user:$saltedhash_of_password} }, "authorization" :{ "class" : "solr.RuleBasedAuthorizationPlugin" , "permissions" :[ { "name" : "security-edit" , "role" : "admin" }, { "name" : "collection-admin-edit" , "role" : "admin" }, { "name" : "core-admin-edit" , "role" : "admin" } ], "user-role" :{ "$user" : "admin" } } } With just this in place (after fixing TODOs and nocommits), one can enable basicauth with typical authz configuration. After this, the user can use the REST API for authc/authz, or we can build further support for adding users, roles etc. to the script.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Another WIP patch. This is functionally complete: -enable and -disable both work. Updating the TODO items in the previous comment.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Another WIP patch. This is functionally complete: -enable and -disable both work. Updating the TODO items in the previous comment.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Updating the patch. Fixes the TODOs and nocommits.
          This seems ready now. Would appreciate if someone can please review.

          Note: This issue is for "enabling basicAuth", and the attached patch does only that. However, for a full set of capabilities, like adding users, roles, one should be using the HTTP API right now. In a subsequent issue, such support can be baked into the script itself.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Updating the patch. Fixes the TODOs and nocommits. This seems ready now. Would appreciate if someone can please review. Note: This issue is for "enabling basicAuth", and the attached patch does only that. However, for a full set of capabilities, like adding users, roles, one should be using the HTTP API right now. In a subsequent issue, such support can be baked into the script itself.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Updating the patch, minor cleanup.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Updating the patch, minor cleanup.
          Hide
          janhoy Jan Høydahl added a comment -

          This patch assumes that Auth can only be enabled with SolrCloud. However, we now also support security.json in $SOLR_HOME for standalone.
          Propose to try to replace explicit zkClient logic with using SecurityConfHandler, (SecurityConfHandlerLocal/SecurityConfHandlerZk somehow. They have a nice SecurityConfig abstraction as well as persistConf(SecurityConfig securityConfig) methods. May need to refactor some of these into static methods or something to access from SolrCLI though.

          Show
          janhoy Jan Høydahl added a comment - This patch assumes that Auth can only be enabled with SolrCloud. However, we now also support security.json in $SOLR_HOME for standalone. Propose to try to replace explicit zkClient logic with using SecurityConfHandler , ( SecurityConfHandlerLocal/SecurityConfHandlerZk somehow. They have a nice SecurityConfig abstraction as well as persistConf(SecurityConfig securityConfig) methods. May need to refactor some of these into static methods or something to access from SolrCLI though.
          Hide
          noble.paul Noble Paul added a comment -

          there is no concept of an admin role in Solr. So it makes no sense to have an argument such as adminuser and adminpassword . Can we have another choice?

          Show
          noble.paul Noble Paul added a comment - there is no concept of an admin role in Solr. So it makes no sense to have an argument such as adminuser and adminpassword . Can we have another choice?
          Hide
          janhoy Jan Høydahl added a comment -

          I'm not super keen on the new auth.overlay.sh/cmd files. We're trying to get away from platform specific files, such as in SOLR-7871 and moving more stuff to Java space. Can we instead simply print

          Solr is now password protected. For continued use of bin/solr, please set these environment variables in your shell or in solr.in.sh/cmd:
          SOLR_AUTH_TYPE = "basic"
          SOLR_AUTHENTICATION_OPTS = "-Dbasicauth=user:pass"
          

          Alternatively, support an option to update solr.in.sh/cmd in-place (not rocket science with SolrCLI.java)

          bin/solr auth -enable [...] -persist
          

          Another comment to the patch is that if $SOLR_INCLUDE is used when calling bin/solr, e.g. to run multiple instances from same install dir, your patch will fail to select a folder in which to place auth.overlay.sh, since $include will be empty.

          Show
          janhoy Jan Høydahl added a comment - I'm not super keen on the new auth.overlay.sh/cmd files. We're trying to get away from platform specific files, such as in SOLR-7871 and moving more stuff to Java space. Can we instead simply print Solr is now password protected. For continued use of bin/solr, please set these environment variables in your shell or in solr.in.sh/cmd: SOLR_AUTH_TYPE = "basic" SOLR_AUTHENTICATION_OPTS = "-Dbasicauth=user:pass" Alternatively, support an option to update solr.in.sh/cmd in-place (not rocket science with SolrCLI.java) bin/solr auth -enable [...] -persist Another comment to the patch is that if $SOLR_INCLUDE is used when calling bin/solr , e.g. to run multiple instances from same install dir, your patch will fail to select a folder in which to place auth.overlay.sh , since $include will be empty.
          Hide
          noble.paul Noble Paul added a comment -

          Ishan Chattopadhyaya I would agree with Jan Høydahl let's close this issue by printing a message to add a couple of lines to solr.in.sh one extra file to manage is a PITA

          Show
          noble.paul Noble Paul added a comment - Ishan Chattopadhyaya I would agree with Jan Høydahl let's close this issue by printing a message to add a couple of lines to solr.in.sh one extra file to manage is a PITA
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Thanks Jan, Noble. I'll modify the patch to print the message.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Thanks Jan, Noble. I'll modify the patch to print the message.
          Hide
          hgadre Hrishikesh Gadre added a comment -

          In general its not a good idea to print the password on command-line or in log files. Can we avoid printing the password? May be replace actual password string with something like "xxx" and add a comment to replace "xxx" with actual password. What do you think?

          Show
          hgadre Hrishikesh Gadre added a comment - In general its not a good idea to print the password on command-line or in log files. Can we avoid printing the password? May be replace actual password string with something like "xxx" and add a comment to replace "xxx" with actual password. What do you think?
          Hide
          janhoy Jan Høydahl added a comment -

          As long as the user types bin/solr auth ... -adminpassword SolrRocks on the cmdline anyway, does it give any added security in not printing that same password out in the response? It's easier for user to copy/paste for sure

          Of course we could wish for some more secure way of sending the password into the script. Guess that letting the OS read the pwd interactively from terminal is more secure, but awkward to script.

          Show
          janhoy Jan Høydahl added a comment - As long as the user types bin/solr auth ... -adminpassword SolrRocks on the cmdline anyway, does it give any added security in not printing that same password out in the response? It's easier for user to copy/paste for sure Of course we could wish for some more secure way of sending the password into the script. Guess that letting the OS read the pwd interactively from terminal is more secure, but awkward to script.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Hrishikesh, given that the credentials are specified by the user in clear text anyway, printing it out doesn't seem any worse.

          However, if we want the user to put in the credentials himself/herself in solr.in.sh (not very user friendly), we can do the following:

          1. The script/SolrCLI prompts the user for the credentials.
          2. Prints out a message to put the password into the solr.in.sh with redacted credentials.

          Please note that the credentials are to be present in solr.in.sh file in clear text anyway.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Hrishikesh, given that the credentials are specified by the user in clear text anyway, printing it out doesn't seem any worse. However, if we want the user to put in the credentials himself/herself in solr.in.sh (not very user friendly), we can do the following: The script/SolrCLI prompts the user for the credentials. Prints out a message to put the password into the solr.in.sh with redacted credentials. Please note that the credentials are to be present in solr.in.sh file in clear text anyway.
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya Jan Høydahl Thanks for the comments. I haven't reviewed this patch in detail, but the basic auth mechanism supports specifying a configuration file (which would contain the password). User can set permissions for this config file such that only solr admin can read/modify/delete the file.

          https://github.com/apache/lucene-solr/blob/07cc043664c4b82c208237b111f698ab2ae0ae07/solr/solrj/src/java/org/apache/solr/client/solrj/impl/PreemptiveBasicAuthClientBuilderFactory.java#L51

          Does this address your concerns? If yes, then it may be a good idea to expose this mechanism via the solr shell command instead of exposing passwords on command-line.

          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya Jan Høydahl Thanks for the comments. I haven't reviewed this patch in detail, but the basic auth mechanism supports specifying a configuration file (which would contain the password). User can set permissions for this config file such that only solr admin can read/modify/delete the file. https://github.com/apache/lucene-solr/blob/07cc043664c4b82c208237b111f698ab2ae0ae07/solr/solrj/src/java/org/apache/solr/client/solrj/impl/PreemptiveBasicAuthClientBuilderFactory.java#L51 Does this address your concerns? If yes, then it may be a good idea to expose this mechanism via the solr shell command instead of exposing passwords on command-line.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          The steps required by the user to use the basicAuth sysprop (which supplies the credentials) or using the solr.httpclient.config sysprop (which supplies a file which contains the credentials) would be the same (i.e. manually follow printed instructions). In both options, the actual credentials will stay in clear text (either in solr.in.sh or a separate file). I don't see how this improves either security or ease of use.

          Due to the awkwardness of the scripting, I think we should avoid the prompt and make it easy to setup (by providing simple copy-paste lines). It will also help ignorant users, who might inadvertently copy the redacted line to the solr.in.sh and nothing will work for him.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - The steps required by the user to use the basicAuth sysprop (which supplies the credentials) or using the solr.httpclient.config sysprop (which supplies a file which contains the credentials) would be the same (i.e. manually follow printed instructions). In both options, the actual credentials will stay in clear text (either in solr.in.sh or a separate file). I don't see how this improves either security or ease of use. Due to the awkwardness of the scripting, I think we should avoid the prompt and make it easy to setup (by providing simple copy-paste lines). It will also help ignorant users, who might inadvertently copy the redacted line to the solr.in.sh and nothing will work for him.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Updated patch.

          1. Renamed -adminusername and -adminpassword to -credentials.
          2. -enable and -disable will print out instructions on editing solr.in.sh (in case of -enable, the exact line that needs to be added).
          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Updated patch. Renamed -adminusername and -adminpassword to -credentials. -enable and -disable will print out instructions on editing solr.in.sh (in case of -enable, the exact line that needs to be added).
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya

          In both options, the actual credentials will stay in clear text (either in solr.in.sh or a separate file). I don't see how this improves either security or ease of use.

          The main difference is that the second option allows admins to customize the file permissions upfront such that the config file will be readable only to a set of trusted users on the system. Specifying password on the command-line has number of security related issues

          BTW what are the default file-permissions for the solr.in.sh ? Is it world readable?

          It will also help ignorant users, who might inadvertently copy the redacted line to the solr.in.sh and nothing will work for him.

          The second option also helps in this case. Since it just provides a file-system path, it is quite safe to be printed on the command-line. If a malicious user attempt to read this configuration file, he would get file permissions error from the operating system (assuming permissions are setup appropriately).

          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya In both options, the actual credentials will stay in clear text (either in solr.in.sh or a separate file). I don't see how this improves either security or ease of use. The main difference is that the second option allows admins to customize the file permissions upfront such that the config file will be readable only to a set of trusted users on the system. Specifying password on the command-line has number of security related issues BTW what are the default file-permissions for the solr.in.sh ? Is it world readable? It will also help ignorant users, who might inadvertently copy the redacted line to the solr.in.sh and nothing will work for him. The second option also helps in this case. Since it just provides a file-system path, it is quite safe to be printed on the command-line. If a malicious user attempt to read this configuration file, he would get file permissions error from the operating system (assuming permissions are setup appropriately).
          Hide
          janhoy Jan Høydahl added a comment -

          I also vote for keeping it user friendly first and foremost.

          However, one advantage of solr.httpclient.config is that the plaintext password will not be available as a system property. If it is passed in to Solr as system property it will be visible both in Admin UI and in ps -efwww. So if bin/solr auth.... is able to create the password file inside $SOLR_VAR_DIR for the instance, i.e. next to solr.in.sh and update solr.in.sh accordingly.

          Show
          janhoy Jan Høydahl added a comment - I also vote for keeping it user friendly first and foremost. However, one advantage of solr.httpclient.config is that the plaintext password will not be available as a system property. If it is passed in to Solr as system property it will be visible both in Admin UI and in ps -efwww . So if bin/solr auth.... is able to create the password file inside $SOLR_VAR_DIR for the instance, i.e. next to solr.in.sh and update solr.in.sh accordingly.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          To be clear, Jan, do you suggest (a) just printing out a message instructing the user to add something to solr.in.sh himself, or (b) updating solr.in.sh through the SolrCLI? In the interest of ease of use, I prefer (b), but I got the impression from comments above (except your last one) that Noble and you prefer (a).

          Hrishikesh, I'll add support for both a prompt and ability to pass credentials to the script. We can document both options.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - To be clear, Jan, do you suggest (a) just printing out a message instructing the user to add something to solr.in.sh himself, or (b) updating solr.in.sh through the SolrCLI? In the interest of ease of use, I prefer (b), but I got the impression from comments above (except your last one) that Noble and you prefer (a). Hrishikesh, I'll add support for both a prompt and ability to pass credentials to the script. We can document both options.
          Hide
          janhoy Jan Høydahl added a comment -

          I'm just pointing out that whatever we add to solr.in.sh will in some way end up as Java Properties on the command line when Solr is started, and the "superuser" password may therefore leak out to users logged in with a read-only password, say, for search only.

          Strictly speaking, is there any reason why the bin/solr start command should need to pass SOLR_AUTHENTICATION_OPTS on the command line? Solr will start without a password, it is only the other CLI commands that need authentication. So if we instead remove these from the start command, there should be no problem having plain-text password in solr.in.sh. Of course, an attacker with access to the server could run ps and reveal the password if there is a long-running bin/solr command being run just then.

          BTW what are the default file-permissions for the solr.in.sh ? Is it world readable?

          I checked a Solr installed using install_solr_service.sh and found this to be world readable:

          -rw-r--r-- 1 root root 5968 Feb 15 14:55 /etc/default/solr.in.sh
          

          For better security, I guess this should rather have been

          -rw-r----- 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh
          

          or perhaps rw for 'solr' user, if the start script needs to modify it.

          Show
          janhoy Jan Høydahl added a comment - I'm just pointing out that whatever we add to solr.in.sh will in some way end up as Java Properties on the command line when Solr is started, and the "superuser" password may therefore leak out to users logged in with a read-only password, say, for search only. Strictly speaking, is there any reason why the bin/solr start command should need to pass SOLR_AUTHENTICATION_OPTS on the command line? Solr will start without a password, it is only the other CLI commands that need authentication. So if we instead remove these from the start command, there should be no problem having plain-text password in solr.in.sh. Of course, an attacker with access to the server could run ps and reveal the password if there is a long-running bin/solr command being run just then. BTW what are the default file-permissions for the solr.in.sh ? Is it world readable? I checked a Solr installed using install_solr_service.sh and found this to be world readable: -rw-r--r-- 1 root root 5968 Feb 15 14:55 /etc/default/solr.in.sh For better security, I guess this should rather have been -rw-r----- 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh or perhaps rw for 'solr' user, if the start script needs to modify it.
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya and Jan Høydahl

          Hrishikesh, I'll add support for both a prompt and ability to pass credentials to the script. We can document both options.

          For better security, I guess this should rather have been

          -rw-r----- 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh
          

          +1 to both the suggestions. Let's not sacrifice security for the sake of usability. Let users decide what works for them depending on their security requirements.

          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya and Jan Høydahl Hrishikesh, I'll add support for both a prompt and ability to pass credentials to the script. We can document both options. For better security, I guess this should rather have been -rw-r----- 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh +1 to both the suggestions. Let's not sacrifice security for the sake of usability. Let users decide what works for them depending on their security requirements.
          Hide
          janhoy Jan Høydahl added a comment -

          Ishan Chattopadhyaya, have you tested the patch with -blockUnknown true?
          If I'm not mistaken, it will cause Solr to be locked down and not even the admin user will be able to /query or /update
          Is there any way, using same security.json, to just flip blockUnknown and allow the admin user to do everything once authenticated?

          Or perhaps we should add support for an optional "normal" user right away. We could have three different hardcoded security.json files for these three cases:
          A: Auth always required, but only one user who has all power (implicit blockUnknown and an "all" permission for the "user" role):

          bin/solr auth -enable -type basic -user solr -password normalUser
          

          B: Normal query / update activity not protected, but security-edit, collection edit requires admin user (as current patch)

          bin/solr auth -enable -type basic -adminuser solr -adminpassword SolrRocks
          

          C: Auth always required, the admin user is required for security, collection etc, while an ordinary user can do all the rest (implicit blockUnknown=true):

          bin/solr auth -enable -type basic -adminuser solr -adminpassword SolrRocks -user solr -password normalUser
          

          I think the current assumption that most novice users would be happy with B is not realistic. I don't even know if it makes sense to try to model the full power of the Authorization REST API on the command line - if you need complex stuff you'd probably use REST APIs, but perhaps these three use cases can cover 80% of typical user needs?

          Show
          janhoy Jan Høydahl added a comment - Ishan Chattopadhyaya , have you tested the patch with -blockUnknown true ? If I'm not mistaken, it will cause Solr to be locked down and not even the admin user will be able to /query or /update Is there any way, using same security.json, to just flip blockUnknown and allow the admin user to do everything once authenticated? Or perhaps we should add support for an optional "normal" user right away. We could have three different hardcoded security.json files for these three cases: A: Auth always required, but only one user who has all power (implicit blockUnknown and an "all" permission for the "user" role): bin/solr auth -enable -type basic -user solr -password normalUser B: Normal query / update activity not protected, but security-edit, collection edit requires admin user (as current patch) bin/solr auth -enable -type basic -adminuser solr -adminpassword SolrRocks C: Auth always required, the admin user is required for security, collection etc, while an ordinary user can do all the rest (implicit blockUnknown=true): bin/solr auth -enable -type basic -adminuser solr -adminpassword SolrRocks -user solr -password normalUser I think the current assumption that most novice users would be happy with B is not realistic. I don't even know if it makes sense to try to model the full power of the Authorization REST API on the command line - if you need complex stuff you'd probably use REST APIs, but perhaps these three use cases can cover 80% of typical user needs?
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Updated patch.

          1. -enable now accepts -credentials solr:SolrRocks or -prompt
          2. Updating the solr.in.sh/solr.in.cmd in-place to comment out existing variables and to append necessary variables.
          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Updated patch. -enable now accepts -credentials solr:SolrRocks or -prompt Updating the solr.in.sh/solr.in.cmd in-place to comment out existing variables and to append necessary variables.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited

          Ishan Chattopadhyaya, have you tested the patch with -blockUnknown true? If I'm not mistaken, it will cause Solr to be locked down and not even the admin user will be able to /query or /update

          I have tested the blockUnknown functionality here. When used, this locks down Solr to everyone, except the initial user (that was added to the admin role using the -enable). More users can be added using REST API by using that user's credentials.

          Is there any way, using same security.json, to just flip blockUnknown and allow the admin user to do everything once authenticated?

          blockUnknown is meant to block out access for those users that are not known to the system. The user that was already added (and given admin role) will continue to have access to do whatever he wants.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited Ishan Chattopadhyaya, have you tested the patch with -blockUnknown true? If I'm not mistaken, it will cause Solr to be locked down and not even the admin user will be able to /query or /update I have tested the blockUnknown functionality here. When used, this locks down Solr to everyone, except the initial user (that was added to the admin role using the -enable). More users can be added using REST API by using that user's credentials. Is there any way, using same security.json, to just flip blockUnknown and allow the admin user to do everything once authenticated? blockUnknown is meant to block out access for those users that are not known to the system. The user that was already added (and given admin role) will continue to have access to do whatever he wants.
          Hide
          noble.paul Noble Paul added a comment -

          adminpassword is still there

          Show
          noble.paul Noble Paul added a comment - adminpassword is still there
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          adminpassword is still there

          Remnants of the previous patch. Updated to remove it. This is ready, planning to commit shortly.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - adminpassword is still there Remnants of the previous patch. Updated to remove it. This is ready, planning to commit shortly.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          not even the admin user will be able to /query or /update

          I tested that the initial user (with admin role) is able to issue /query and /select, as well as collection-edit operations. All other users are blocked out.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - not even the admin user will be able to /query or /update I tested that the initial user (with admin role) is able to issue /query and /select, as well as collection-edit operations. All other users are blocked out.
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          It'd probably be safer to read password from the command line using Console.readPassword. See http://docs.oracle.com/javase/7/docs/api/java/io/Console.html#readPassword%28%29

          Show
          shalinmangar Shalin Shekhar Mangar added a comment - It'd probably be safer to read password from the command line using Console.readPassword. See http://docs.oracle.com/javase/7/docs/api/java/io/Console.html#readPassword%28%29
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          It'd probably be safer to read password from the command line using Console.readPassword. See http://docs.oracle.com/javase/7/docs/api/java/io/Console.html#readPassword%28%29

          Indeed, done exactly that in the patch. This is available for use if -prompt is specified. For users who insist on passing in credentials through command line, -credentials solr:SolrRocks is available.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - It'd probably be safer to read password from the command line using Console.readPassword. See http://docs.oracle.com/javase/7/docs/api/java/io/Console.html#readPassword%28%29 Indeed, done exactly that in the patch. This is available for use if -prompt is specified. For users who insist on passing in credentials through command line, -credentials solr:SolrRocks is available.
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          Ah sorry I didn't notice. Sorry for the noise.

          Show
          shalinmangar Shalin Shekhar Mangar added a comment - Ah sorry I didn't notice. Sorry for the noise.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit c9541c216d57ff816d64beef566990d8754008db in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c9541c2 ]

          SOLR-8440: Support for enabling basic authentication using bin/solr|bin/solr.cmd

          Usage:
          bin/solr auth -enable -prompt
          bin/solr auth -enable -credentials solr:SolrRocks
          bin/solr auth -disable

          Show
          jira-bot ASF subversion and git services added a comment - Commit c9541c216d57ff816d64beef566990d8754008db in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c9541c2 ] SOLR-8440 : Support for enabling basic authentication using bin/solr|bin/solr.cmd Usage: bin/solr auth -enable -prompt bin/solr auth -enable -credentials solr:SolrRocks bin/solr auth -disable
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 4dbc3fcb9ed783f8ae3ded22faebde4bcac53745 in lucene-solr's branch refs/heads/branch_6x from Ishan Chattopadhyaya
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4dbc3fc ]

          SOLR-8440: Support for enabling basic authentication using bin/solr|bin/solr.cmd

          Usage:
          bin/solr auth -enable -prompt
          bin/solr auth -enable -credentials solr:SolrRocks
          bin/solr auth -disable

          Show
          jira-bot ASF subversion and git services added a comment - Commit 4dbc3fcb9ed783f8ae3ded22faebde4bcac53745 in lucene-solr's branch refs/heads/branch_6x from Ishan Chattopadhyaya [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4dbc3fc ] SOLR-8440 : Support for enabling basic authentication using bin/solr|bin/solr.cmd Usage: bin/solr auth -enable -prompt bin/solr auth -enable -credentials solr:SolrRocks bin/solr auth -disable
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Thanks everyone for valuable inputs!

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Thanks everyone for valuable inputs!
          Hide
          janhoy Jan Høydahl added a comment -

          I tested that the initial user (with admin role) is able to issue /query and /select, as well as collection-edit operations. All other users are blocked out.

          Ah, thanks for testing, that is just perfect I think you found a good balance between usability and security in this issue, thanks Ishan!

          Show
          janhoy Jan Høydahl added a comment - I tested that the initial user (with admin role) is able to issue /query and /select, as well as collection-edit operations. All other users are blocked out. Ah, thanks for testing, that is just perfect I think you found a good balance between usability and security in this issue, thanks Ishan!
          Hide
          janhoy Jan Høydahl added a comment - - edited

          A comment on the choice of location for basicAuth.conf. It will be placed next to SOLR_INCLUDE_FILE. Three problems with that:

          • install_solr_service.sh defaults to /etc/default as location for solr.in.sh, and that folder is only writable by root, and creation of the new file will fail
          • When installing multiple instances of Solr on same node, the second instance will use e.g. /etc/default/solr2.in.sh, but you're only using a static file name basicAuth.conf which will then overwrite the password for the previous instance already running.
          • The generic name basicAuth.conf is bad if the file will reside in a non-solr-specific path such as /etc/default/

          Due to these three issues, should we change the default location of basicAuth.conf to SOLR_VAR_DIR instead, since this folder is guaranteed unique per Solr instance /var/solr, /var/solr2 etc, and the solr user already have write access to it, and it's where we already put PID file.

          I think that change can be done by re-opening this issue and doing another commit.

          In addition, we should spin off new JIRAs:

          Show
          janhoy Jan Høydahl added a comment - - edited A comment on the choice of location for basicAuth.conf . It will be placed next to SOLR_INCLUDE_FILE. Three problems with that: install_solr_service.sh defaults to /etc/default as location for solr.in.sh, and that folder is only writable by root, and creation of the new file will fail When installing multiple instances of Solr on same node, the second instance will use e.g. /etc/default/solr2.in.sh , but you're only using a static file name basicAuth.conf which will then overwrite the password for the previous instance already running. The generic name basicAuth.conf is bad if the file will reside in a non-solr-specific path such as /etc/default/ Due to these three issues, should we change the default location of basicAuth.conf to SOLR_VAR_DIR instead, since this folder is guaranteed unique per Solr instance /var/solr , /var/solr2 etc, and the solr user already have write access to it, and it's where we already put PID file. I think that change can be done by re-opening this issue and doing another commit. In addition, we should spin off new JIRAs: To change default permission of solr.in.sh to writable by Solr user, as discussed above SOLR-10644 To make solr auth command work in non-cloud mode, as commented a few days ago SOLR-10645 To modify bin/solr to NOT pass authentication options on cmdline for solr start as also discussed above SOLR-10646
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          The bin/solr script has no notion of SOLR_VAR_DIR. I'm not familiar with the bin/install_solr_service.sh, which has the SOLR_VAR_DIR. Can you please advice how to proceed, or cook up a patch for this? Also, I can look at it myself, but I might miss the 6.6 release branch cutoff. But, maybe, this is fine to fix even after release branch is cut.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - The bin/solr script has no notion of SOLR_VAR_DIR. I'm not familiar with the bin/install_solr_service.sh, which has the SOLR_VAR_DIR. Can you please advice how to proceed, or cook up a patch for this? Also, I can look at it myself, but I might miss the 6.6 release branch cutoff. But, maybe, this is fine to fix even after release branch is cut.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          install_solr_service.sh defaults to /etc/default as location for solr.in.sh, and that folder is only writable by root, and creation of the new file will fail

          In the event that a file is not writeable, I have just printed out the lines which need to be copy-pasted.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - install_solr_service.sh defaults to /etc/default as location for solr.in.sh, and that folder is only writable by root, and creation of the new file will fail In the event that a file is not writeable, I have just printed out the lines which need to be copy-pasted.
          Hide
          janhoy Jan Høydahl added a comment -

          The bin/solr script has no notion of SOLR_VAR_DIR

          I know. The script only knows about SOLR_TIP, SOLR_HOME, SOLR_PID_DIR etc.

          SOLR_PID_DIR will default to $SOLR_TIP/bin, but if custom SOLR_HOME is set, then SOLR_PID_DIR will be equal to SOLR_HOME, unless SOLR_PID_DIR is set explicitly, as it is by the installer...

          If we chose SOLR_PID_DIR as location for basicAuth.conf then

          • In a default unzipp'ed install, it will end up in bin/ next to start script
          • In the default linux installer setup it will end up in /var/solr/
          • In a custom install it will end up next to PID file which is probably in SOLR_HOME.

          So perhaps simply SOLR_HOME is as good location as anything, where also solr.xml, zoo.cfg, and security.json for non-cloud already are? You decide...

          Show
          janhoy Jan Høydahl added a comment - The bin/solr script has no notion of SOLR_VAR_DIR I know. The script only knows about SOLR_TIP, SOLR_HOME, SOLR_PID_DIR etc. SOLR_PID_DIR will default to $SOLR_TIP/bin , but if custom SOLR_HOME is set, then SOLR_PID_DIR will be equal to SOLR_HOME, unless SOLR_PID_DIR is set explicitly, as it is by the installer... If we chose SOLR_PID_DIR as location for basicAuth.conf then In a default unzipp'ed install, it will end up in bin/ next to start script In the default linux installer setup it will end up in /var/solr/ In a custom install it will end up next to PID file which is probably in SOLR_HOME. So perhaps simply SOLR_HOME is as good location as anything, where also solr.xml , zoo.cfg , and security.json for non-cloud already are? You decide...
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          SOLR_HOME sounds good. I'll post a patch shortly.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - SOLR_HOME sounds good. I'll post a patch shortly.
          Hide
          janhoy Jan Høydahl added a comment -

          The new sub command auth is not advertised in help

          Usage: solr COMMAND OPTIONS
                 where COMMAND is one of: start, stop, restart, status, healthcheck, create, create_core, create_collection, delete, version, zk
          
          Show
          janhoy Jan Høydahl added a comment - The new sub command auth  is not advertised in help Usage: solr COMMAND OPTIONS where COMMAND is one of: start, stop, restart, status, healthcheck, create, create_core, create_collection, delete, version, zk
          Hide
          janhoy Jan Høydahl added a comment - - edited

          Running solr auth -enable without starting Solr throws a stack trace instead of printing usage. Do we need to hit localhost HTTP before validating program args?

          Exception in thread "main" org.apache.http.conn.HttpHostConnectException: Connect to localhost:80 [localhost/127.0.0.1] failed: Connection refused (Connection refused)
          	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:151)
          

          If you move the getZkHost(cli) check to after the credentials check, then it's a bit better.

          Also, can we add an option zkHost to the auth options, so that it is possible to specify -zkHost localhost:2181 and enable auth without a running Solr? This is nice for scripting installers.

          Show
          janhoy Jan Høydahl added a comment - - edited Running solr auth -enable without starting Solr throws a stack trace instead of printing usage. Do we need to hit localhost HTTP before validating program args? Exception in thread "main" org.apache.http.conn.HttpHostConnectException: Connect to localhost:80 [localhost/127.0.0.1] failed: Connection refused (Connection refused) at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:151) If you move the getZkHost(cli) check to after the credentials check, then it's a bit better. Also, can we add an option zkHost to the auth options, so that it is possible to specify -zkHost localhost:2181 and enable auth without a running Solr ? This is nice for scripting installers.
          Hide
          janhoy Jan Høydahl added a comment -

          Ishan Chattopadhyaya did you actually test your patch, copying the two lines into solr.in.sh?
          Cause when I try it here, I get nullpointer exception in PreemptiveBasicAuthClientBuilderFactory:

          solr@osboxes:/opt/solr$ bin/solr status
          
          Found 1 Solr nodes: 
          
          Solr process 6555 running on port 8983
          Exception in thread "main" java.lang.ExceptionInInitializerError
          	at org.apache.solr.util.SolrCLI.getHttpClient(SolrCLI.java:567)
          	at org.apache.solr.util.SolrCLI$StatusTool.getStatus(SolrCLI.java:891)
          	at org.apache.solr.util.SolrCLI$StatusTool.runImpl(SolrCLI.java:849)
          	at org.apache.solr.util.SolrCLI$ToolBase.runTool(SolrCLI.java:160)
          	at org.apache.solr.util.SolrCLI.main(SolrCLI.java:258)
          Caused by: java.lang.NullPointerException
          	at org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory.initHttpClientBuilder(PreemptiveBasicAuthClientBuilderFactory.java:114)
          	at org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory.getHttpClientBuilder(PreemptiveBasicAuthClientBuilderFactory.java:109)
          	at org.apache.solr.client.solrj.impl.HttpClientUtil.<clinit>(HttpClientUtil.java:142)
          	... 5 more
          

          Turns out you have a typo in the instructions, see SolrCLI.java#L3711, it should be -Dbasicauth= without uppercase "A".

          Other nitpick:

          • Method updateIncludeFileEnableAuth takes username, password as args but they are never used
          • Wrong code indent in SolrCLI#3629-3671
          Show
          janhoy Jan Høydahl added a comment - Ishan Chattopadhyaya did you actually test your patch, copying the two lines into solr.in.sh ? Cause when I try it here, I get nullpointer exception in PreemptiveBasicAuthClientBuilderFactory: solr@osboxes:/opt/solr$ bin/solr status Found 1 Solr nodes: Solr process 6555 running on port 8983 Exception in thread "main" java.lang.ExceptionInInitializerError at org.apache.solr.util.SolrCLI.getHttpClient(SolrCLI.java:567) at org.apache.solr.util.SolrCLI$StatusTool.getStatus(SolrCLI.java:891) at org.apache.solr.util.SolrCLI$StatusTool.runImpl(SolrCLI.java:849) at org.apache.solr.util.SolrCLI$ToolBase.runTool(SolrCLI.java:160) at org.apache.solr.util.SolrCLI.main(SolrCLI.java:258) Caused by: java.lang.NullPointerException at org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory.initHttpClientBuilder(PreemptiveBasicAuthClientBuilderFactory.java:114) at org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory.getHttpClientBuilder(PreemptiveBasicAuthClientBuilderFactory.java:109) at org.apache.solr.client.solrj.impl.HttpClientUtil.<clinit>(HttpClientUtil.java:142) ... 5 more Turns out you have a typo in the instructions, see SolrCLI.java#L3711 , it should be -Dbasicauth= without uppercase "A". Other nitpick: Method updateIncludeFileEnableAuth takes username, password as args but they are never used Wrong code indent in SolrCLI#3629-3671
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Thanks Jan, I'll fix shortly!

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Thanks Jan, I'll fix shortly!
          Hide
          janhoy Jan Høydahl added a comment -

          The 6.6 release branch is cut in a few hours. Are you confident that this feature will have good enough quality to go in 6.6? The patch does not contain a single unit test. I would expect it to be possible to cover most of the SolrCLI functionality in with unit tests. bin/solr is harder or course. Is it well tested on Windows?

          Show
          janhoy Jan Høydahl added a comment - The 6.6 release branch is cut in a few hours. Are you confident that this feature will have good enough quality to go in 6.6? The patch does not contain a single unit test. I would expect it to be possible to cover most of the SolrCLI functionality in with unit tests. bin/solr is harder or course. Is it well tested on Windows?
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          So perhaps simply SOLR_HOME is as good location as anything, where also solr.xml, zoo.cfg, and security.json for non-cloud already are

          It seems that SOLR_HOME is only applicable in the context of a start command, where the home directory is specifically provided by the user. However, for a running Solr instance, it should be possible to query it to know which home directory it started with. But, I'm not sure how to get at the home directory (or what a home directory even means) for a not-yet-started Solr instance (assuming that your motivation behind suggesting a -zkUrl was that a not-yet-started instance could also leverage -enable). Any ideas, Jan Høydahl?

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - So perhaps simply SOLR_HOME is as good location as anything, where also solr.xml, zoo.cfg, and security.json for non-cloud already are It seems that SOLR_HOME is only applicable in the context of a start command, where the home directory is specifically provided by the user. However, for a running Solr instance, it should be possible to query it to know which home directory it started with. But, I'm not sure how to get at the home directory (or what a home directory even means) for a not-yet-started Solr instance (assuming that your motivation behind suggesting a -zkUrl was that a not-yet-started instance could also leverage -enable). Any ideas, Jan Høydahl ?
          Hide
          janhoy Jan Høydahl added a comment -

          But, I'm not sure how to get at the home directory

          The bin/solr script already resolves the SOLR_HOME variable but as you say, only for "start" command. Guess we have to move the SOLR_HOME resolution lines higher up in the script

          if [ -z "$SOLR_HOME" ]; then
            SOLR_HOME="$SOLR_SERVER_DIR/solr"
          else
            if [[ $SOLR_HOME != /* ]] && [[ -d "$SOLR_SERVER_DIR/$SOLR_HOME" ]]; then
              SOLR_HOME="$SOLR_SERVER_DIR/$SOLR_HOME"
              SOLR_PID_DIR="$SOLR_HOME"
            elif [[ $SOLR_HOME != /* ]] && [[ -d "`pwd`/$SOLR_HOME" ]]; then
              SOLR_HOME="$(pwd)/$SOLR_HOME"
            fi
          fi
          

          It should then work for both cold and running Solr. If SOLR_HOME is given in ENV or solr.in.sh it will be used, else it will be resolved to server/solr. No need to ask the running Solr where its home dir is, the bin/solr script already knows (unless an instance was started one-off with -s <dir> on the command line. However, let's assume in the first version that SOLR_HOME is either the default or is specified in env or solr.in.sh. So to configure auth for another instance, it could look like

          bin/solr auth -enable .... -s /path/to/solrhome -zkHost localhost:2181  # Explicitly point out both home and zk
          SOLR_INCLUDE=/path/to/our/instance/solr.in.sh && bin/solr auth -enable ...  # Pull both SOLR_HOME and ZK_HOST from solr.in
          

          In a later version we could of course also support

          bin/solr auth -enable .... -p 8984  # Lookup what home and zk the running solr is using
          bin/solr auth -enable .... -i /path/to/solr.in.sh  # Explicitly point to solr.in.sh instead of setting SOLR_INCLUDE
          

          Another benefit of always knowing where SOLR_HOME is, is that SOLR-10645 will know where to put security.json too

          Show
          janhoy Jan Høydahl added a comment - But, I'm not sure how to get at the home directory The bin/solr script already resolves the SOLR_HOME variable but as you say, only for "start" command. Guess we have to move the SOLR_HOME resolution lines higher up in the script if [ -z "$SOLR_HOME" ]; then SOLR_HOME= "$SOLR_SERVER_DIR/solr" else if [[ $SOLR_HOME != /* ]] && [[ -d "$SOLR_SERVER_DIR/$SOLR_HOME" ]]; then SOLR_HOME= "$SOLR_SERVER_DIR/$SOLR_HOME" SOLR_PID_DIR= "$SOLR_HOME" elif [[ $SOLR_HOME != /* ]] && [[ -d "`pwd`/$SOLR_HOME" ]]; then SOLR_HOME= "$(pwd)/$SOLR_HOME" fi fi It should then work for both cold and running Solr. If SOLR_HOME is given in ENV or solr.in.sh it will be used, else it will be resolved to server/solr. No need to ask the running Solr where its home dir is, the bin/solr script already knows (unless an instance was started one-off with -s <dir> on the command line. However, let's assume in the first version that SOLR_HOME is either the default or is specified in env or solr.in.sh. So to configure auth for another instance, it could look like bin/solr auth -enable .... -s /path/to/solrhome -zkHost localhost:2181 # Explicitly point out both home and zk SOLR_INCLUDE=/path/to/our/instance/solr.in.sh && bin/solr auth -enable ... # Pull both SOLR_HOME and ZK_HOST from solr.in In a later version we could of course also support bin/solr auth -enable .... -p 8984 # Lookup what home and zk the running solr is using bin/solr auth -enable .... -i /path/to/solr.in.sh # Explicitly point to solr.in.sh instead of setting SOLR_INCLUDE Another benefit of always knowing where SOLR_HOME is, is that SOLR-10645 will know where to put security.json too
          Hide
          hossman Hoss Man added a comment -

          NOTE: i posted a longish comment in SOLR-10644 against that change...

          FWIW: I'm -0 on the installer making solr.in.sh writable by any user other then the user running the installer (ie: "root"). ...

          Since that jira seems to have been motivated entirely by this feature, It seems important for me to cross post here a -0 towards the current solution of how the changes script should be able to modify solr.in.sh ... if people feel this goal is important then as i mentioned in SOLR-10644 ...

          ... the solution to that objective should be error checking and help messages instructing the user that those specific commands need to be run as root via {{sudo bin/solr ... }}

          Show
          hossman Hoss Man added a comment - NOTE: i posted a longish comment in SOLR-10644 against that change... FWIW: I'm -0 on the installer making solr.in.sh writable by any user other then the user running the installer (ie: "root"). ... Since that jira seems to have been motivated entirely by this feature, It seems important for me to cross post here a -0 towards the current solution of how the changes script should be able to modify solr.in.sh ... if people feel this goal is important then as i mentioned in SOLR-10644 ... ... the solution to that objective should be error checking and help messages instructing the user that those specific commands need to be run as root via {{sudo bin/solr ... }}
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          if people feel this goal is important then as i mentioned in SOLR-10644 ...

          In my opinion, it is not necessary. The changes supposed to be made to solr.in.sh in this issue are printed out for the user to put in himself/herself, in case the file is not writeable.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - if people feel this goal is important then as i mentioned in SOLR-10644 ... In my opinion, it is not necessary. The changes supposed to be made to solr.in.sh in this issue are printed out for the user to put in himself/herself, in case the file is not writeable.
          Hide
          janhoy Jan Høydahl added a comment -

          Hi, sorry for the quick commit on SOLR-10644. I'm willing to revert that any time.

          So if I'm reading you correctly Hoss Man, a safer way for this is to let solr.in.sh still be owned by root, and print the manual instructions as today if we cannot write, but if solr auth... is run by root/sudo, then the solr.in.sh edit will succeed. Alternatively, we could always require root for all auth commands? Whatever we decide should be documentedt in the refGuide and usage.

          Show
          janhoy Jan Høydahl added a comment - Hi, sorry for the quick commit on SOLR-10644 . I'm willing to revert that any time. So if I'm reading you correctly Hoss Man , a safer way for this is to let solr.in.sh still be owned by root, and print the manual instructions as today if we cannot write, but if solr auth... is run by root/sudo, then the solr.in.sh edit will succeed. Alternatively, we could always require root for all auth commands? Whatever we decide should be documentedt in the refGuide and usage.
          Hide
          hossman Hoss Man added a comment -

          ... Alternatively, ...

          I think fundementally there are 3 distinct points here...

          1. any bin/solr subcommand that wants to write to a file should always give a clear error message if the current effective UID doesn't have the neccessary permissions
          2. bin/solr should never assume any particular file ownership/permissions just based on the convention/defaults of the installer – users might change them later, so the checks/warnings/msgs produced by #1 should always account for that possibility.
          3. it may make sense for any auth related subcommands to require that the user running the command be root – that might be a good check to have independent of whether the current effective UID already has write permissions to whatever files it wants to modify.
          Show
          hossman Hoss Man added a comment - ... Alternatively, ... I think fundementally there are 3 distinct points here... any bin/solr subcommand that wants to write to a file should always give a clear error message if the current effective UID doesn't have the neccessary permissions bin/solr should never assume any particular file ownership/permissions just based on the convention/defaults of the installer – users might change them later, so the checks/warnings/msgs produced by #1 should always account for that possibility. it may make sense for any auth related subcommands to require that the user running the command be root – that might be a good check to have independent of whether the current effective UID already has write permissions to whatever files it wants to modify.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Updated patch.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Updated patch.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited

          The new sub command auth is not advertised in help

          Fixed

          Running solr auth -enable without starting Solr throws a stack trace instead of printing usage.

          Done, printed a message to the effect that Solr should've been started in cloud mode or zkHost should've been provided.

          If you move the getZkHost(cli) check to after the credentials check, then it's a bit better.

          Done

          it should be -Dbasicauth= without uppercase "A".

          Fixed

          Method updateIncludeFileEnableAuth takes username, password as args but they are never used

          Fixed.

          Wrong code indent in SolrCLI#3629-3671

          Fixed.

          Guess we have to move the SOLR_HOME resolution lines higher up in the script

          I found that using $SOLR_PID_DIR was much simpler than the $SOLR_HOME (which more or less point to the same location). On Windows, used $SOLR_TIP/bin.

          Are you confident that this feature will have good enough quality to go in 6.6?

          This is a new feature. So long as it doesn't trip up any existing parts of Solr, and it works for the cases we've tested manually, I am confident to have it in 6.6. Any bugs, if they escape attention, can be fixed later. Not putting it in 6x would delay the actual adoption by users, who are more likely, in the short term, to upgrade to 6.6 than 7.0.

          I would expect it to be possible to cover most of the SolrCLI functionality in with unit tests.

          Actually, I found it quite difficult to test the changes I've introduced to SolrCLI without writing some fundamental support to test external systems here. For example, I would've liked to test if the correct security.json is being uploaded to ZK or not. But without significant effort in building such scaffolding in our test framework, I couldn't see a way to test for that. Did I miss something obvious? Can you point me to any existing tests which I can derive any clues from? I didn't find the tests for the Examples very useful.

          For this patch, I have tested manually on Linux, and still testing on Windows.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited The new sub command auth is not advertised in help Fixed Running solr auth -enable without starting Solr throws a stack trace instead of printing usage. Done, printed a message to the effect that Solr should've been started in cloud mode or zkHost should've been provided. If you move the getZkHost(cli) check to after the credentials check, then it's a bit better. Done it should be -Dbasicauth= without uppercase "A". Fixed Method updateIncludeFileEnableAuth takes username, password as args but they are never used Fixed. Wrong code indent in SolrCLI#3629-3671 Fixed. Guess we have to move the SOLR_HOME resolution lines higher up in the script I found that using $SOLR_PID_DIR was much simpler than the $SOLR_HOME (which more or less point to the same location). On Windows, used $SOLR_TIP/bin. Are you confident that this feature will have good enough quality to go in 6.6? This is a new feature. So long as it doesn't trip up any existing parts of Solr, and it works for the cases we've tested manually, I am confident to have it in 6.6. Any bugs, if they escape attention, can be fixed later. Not putting it in 6x would delay the actual adoption by users, who are more likely, in the short term, to upgrade to 6.6 than 7.0. I would expect it to be possible to cover most of the SolrCLI functionality in with unit tests. Actually, I found it quite difficult to test the changes I've introduced to SolrCLI without writing some fundamental support to test external systems here. For example, I would've liked to test if the correct security.json is being uploaded to ZK or not. But without significant effort in building such scaffolding in our test framework, I couldn't see a way to test for that. Did I miss something obvious? Can you point me to any existing tests which I can derive any clues from? I didn't find the tests for the Examples very useful. For this patch, I have tested manually on Linux, and still testing on Windows.
          Hide
          janhoy Jan Høydahl added a comment -

          Great progress!

          I found that using $SOLR_PID_DIR was much simpler than the $SOLR_HOME (which more or less point to the same location). On Windows, used $SOLR_TIP/bin.

          Problem with SOLR_PID_DIR and SOLR_TIP/bin is that it does not support an install with multiple instances run from same binaries. Once you set password for the second instance, it will overwrite the $SOLR_TIP/bin/basicAuth.conf which was placed there by any prior auth settings for other instances. $SOLR_PID_DIR works for PID files, since they are unique, containing port name in filename.

          So I would still prefer using $SOLR_HOME for the basicAuth.conf. Alternatively name it basicAuth_$PORT.conf and use that name in the SOLR_AUTHENTICATION_OPTS var; then it could go in SOLR_PID DIR without problems.

          Show
          janhoy Jan Høydahl added a comment - Great progress! I found that using $SOLR_PID_DIR was much simpler than the $SOLR_HOME (which more or less point to the same location). On Windows, used $SOLR_TIP/bin. Problem with SOLR_PID_DIR and SOLR_TIP/bin is that it does not support an install with multiple instances run from same binaries. Once you set password for the second instance, it will overwrite the $SOLR_TIP/bin/basicAuth.conf which was placed there by any prior auth settings for other instances. $SOLR_PID_DIR works for PID files, since they are unique, containing port name in filename. So I would still prefer using $SOLR_HOME for the basicAuth.conf. Alternatively name it basicAuth_$PORT.conf and use that name in the SOLR_AUTHENTICATION_OPTS var; then it could go in SOLR_PID DIR without problems.
          Hide
          janhoy Jan Høydahl added a comment -

          Actually, I found it quite difficult to test the changes I've introduced to SolrCLI

          Guess I was thinking more along the lines of simple unit tests that tests updateIncludeFileEnableAuth(), updateIncludeFileDisableAuth() and perhaps factor out more code in testable methods.

          Haven't checked very hard, but it should be possible to add another tests to BasicAuthIntegrationTest that instead of explicitly uploading the hardcoded security.json, programatically instantiates AuthTool and calls enable, then later in the test verify that you need to authenticate. You could then test disable and -blockUnknown afterwards in the same test, and we'd exercise much of the new functionality?

          Show
          janhoy Jan Høydahl added a comment - Actually, I found it quite difficult to test the changes I've introduced to SolrCLI Guess I was thinking more along the lines of simple unit tests that tests updateIncludeFileEnableAuth() , updateIncludeFileDisableAuth() and perhaps factor out more code in testable methods. Haven't checked very hard, but it should be possible to add another tests to BasicAuthIntegrationTest that instead of explicitly uploading the hardcoded security.json, programatically instantiates AuthTool and calls enable, then later in the test verify that you need to authenticate. You could then test disable and -blockUnknown afterwards in the same test, and we'd exercise much of the new functionality?
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Problem with SOLR_PID_DIR and SOLR_TIP/bin is that it does not support an install with multiple instances run from same binaries.

          Isn't it the case that all of those instances will be part of the same SolrCloud cluster, and hence they should have the same basicAuth.conf? However, when this feature is extended to cover standalone mode, then we could suffix the file with a port (or somehow figure out how to use a SOLR_HOME).

          Guess we have to move the SOLR_HOME resolution lines higher up in the script

          Trying to use SOLR_HOME by "moving" the logic up the logic would break the resolution of the SOLR_HOME in the case of a "start" command. I am trying to do it both higher up as well as where it is currently done, but that also is breaking the "start" command. Also, the whole $SOLR_SERVER_DIR block also needs to be copied/moved higher up, since $SOLR_HOME depends on that. Here's that block:

                      if [[ "$2" == "." || "$2" == "./" || "$2" == ".." || "$2" == "../" ]]; then
                        SOLR_SERVER_DIR="$(pwd)/$2"
                      else
                        # see if the arg value is relative to the tip vs full path
                        if [[ "$2" != /* ]] && [[ -d "$SOLR_TIP/$2" ]]; then
                          SOLR_SERVER_DIR="$SOLR_TIP/$2"
                        else
                          SOLR_SERVER_DIR="$2"
                        fi
                      fi
          

          Needless to say, trying to use SOLR_HOME is proving quite tricky. I am still trying, though..

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Problem with SOLR_PID_DIR and SOLR_TIP/bin is that it does not support an install with multiple instances run from same binaries. Isn't it the case that all of those instances will be part of the same SolrCloud cluster, and hence they should have the same basicAuth.conf? However, when this feature is extended to cover standalone mode, then we could suffix the file with a port (or somehow figure out how to use a SOLR_HOME). Guess we have to move the SOLR_HOME resolution lines higher up in the script Trying to use SOLR_HOME by "moving" the logic up the logic would break the resolution of the SOLR_HOME in the case of a "start" command. I am trying to do it both higher up as well as where it is currently done, but that also is breaking the "start" command. Also, the whole $SOLR_SERVER_DIR block also needs to be copied/moved higher up, since $SOLR_HOME depends on that. Here's that block: if [[ "$2" == "." || "$2" == "./" || "$2" == ".." || "$2" == "../" ]]; then SOLR_SERVER_DIR= "$(pwd)/$2" else # see if the arg value is relative to the tip vs full path if [[ "$2" != /* ]] && [[ -d "$SOLR_TIP/$2" ]]; then SOLR_SERVER_DIR= "$SOLR_TIP/$2" else SOLR_SERVER_DIR= "$2" fi fi Needless to say, trying to use SOLR_HOME is proving quite tricky. I am still trying, though..
          Hide
          janhoy Jan Høydahl added a comment -

          Isn't it the case that all of those instances will be part of the same SolrCloud cluster, and hence they should have the same basicAuth.conf?

          Normally, yes, not as you say it won't necessarily be true for standalone.
          Question is, how many times should a cloud user need to run solr auth -enable...? Say there are three servers, each with two Solr nodes, totally six nodes in the cluster. To be able to run bin/solr commands from any of the nodes without typing the password every time, the user would need to add the basicAuth.conf file to all three servers, and to point SOLR_AUTHENTICATION_OPTS to that file in each of the six solr.in.sh files. He could do that manually or by running solr auth -enable six times, once for each node... How do you plan to document this in refGuide? And each command would re-upload the json to ZK

          And what if the user changes his "admin" password through REST APIs, he should also find some documentation on how to update all the basicAuth.conf files on all nodes, either manually or through solr auth -changepass or something?

          Perhaps it would be wiser to split the commands up in an -enable (server-side) command and a -remember (client-side) command?

          bin/solr auth -enable -credentials solr:SolrRocks  # takes care of security.json
          SOLR_INCLUDE=/etc/defaults/solr.in.sh ; bin/solr auth -remember -credentials solr:SolrRocks
          SOLR_INCLUDE=/etc/defaults/solr2.in.sh ; bin/solr auth -remember -credentials solr:SolrRocks
          SOLR_INCLUDE=/etc/defaults/solr3.in.sh ; bin/solr auth -remember -credentials solr:SolrRocks
          

          Another general comment
          The bin/solr sub tools, like bin/solr zk do not prefix the commands with a -. I.e. you have bin/solr zk mkdir foo. Could we follow that style here as well, i.e.

          Usage: solr auth enable [-type basicAuth] -credentials user:pass [-blockUnknown]
                 solr auth disable
          
          Show
          janhoy Jan Høydahl added a comment - Isn't it the case that all of those instances will be part of the same SolrCloud cluster, and hence they should have the same basicAuth.conf ? Normally, yes, not as you say it won't necessarily be true for standalone. Question is, how many times should a cloud user need to run solr auth -enable... ? Say there are three servers, each with two Solr nodes, totally six nodes in the cluster. To be able to run bin/solr commands from any of the nodes without typing the password every time, the user would need to add the basicAuth.conf file to all three servers, and to point SOLR_AUTHENTICATION_OPTS to that file in each of the six solr.in.sh files. He could do that manually or by running solr auth -enable six times, once for each node... How do you plan to document this in refGuide? And each command would re-upload the json to ZK And what if the user changes his "admin" password through REST APIs, he should also find some documentation on how to update all the basicAuth.conf files on all nodes, either manually or through solr auth -changepass  or something? Perhaps it would be wiser to split the commands up in an -enable (server-side) command and a -remember (client-side) command? bin/solr auth -enable -credentials solr:SolrRocks # takes care of security.json SOLR_INCLUDE=/etc/defaults/solr.in.sh ; bin/solr auth -remember -credentials solr:SolrRocks SOLR_INCLUDE=/etc/defaults/solr2.in.sh ; bin/solr auth -remember -credentials solr:SolrRocks SOLR_INCLUDE=/etc/defaults/solr3.in.sh ; bin/solr auth -remember -credentials solr:SolrRocks Another general comment The bin/solr sub tools, like bin/solr zk do not prefix the commands with a - . I.e. you have bin/solr zk mkdir foo . Could we follow that style here as well, i.e. Usage: solr auth enable [-type basicAuth] -credentials user:pass [-blockUnknown] solr auth disable
          Hide
          janhoy Jan Høydahl added a comment - - edited

          The bin/solr usage part does not mention -z option, while the bin/solr.cmd version does.

          Attaching a new patch SOLR-8840_opt_parsing.patch which fixes usage print, and improves opt parsing for bin/solr and modifies SolrCLI to accept enable/disable as arguments instead of options. This should work both for linux and windows but not tested on windows.

          Show
          janhoy Jan Høydahl added a comment - - edited The bin/solr  usage part does not mention -z option, while the bin/solr.cmd version does. Attaching a new patch SOLR-8840 _opt_parsing.patch which fixes usage print, and improves opt parsing for bin/solr and modifies SolrCLI to accept enable/disable as arguments instead of options. This should work both for linux and windows but not tested on windows.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Perhaps it would be wiser to split the commands up in an -enable (server-side) command and a -remember (client-side) command?

          I like this approach. Alternatively, we could have an option in enable to do this, e.g. bin/solr auth enable --update-include-file-only -credentials solr:abc and bin/solr auth disable --update-include-file-only. This would make it clear that this is still a step needed for enabling authentication, but just that it updates the include file to use the provided credentials, instead of changing the security.json. What do you think?

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Perhaps it would be wiser to split the commands up in an -enable (server-side) command and a -remember (client-side) command? I like this approach. Alternatively, we could have an option in enable to do this, e.g. bin/solr auth enable --update-include-file-only -credentials solr:abc and bin/solr auth disable --update-include-file-only . This would make it clear that this is still a step needed for enabling authentication, but just that it updates the include file to use the provided credentials, instead of changing the security.json. What do you think?
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          And what if the user changes his "admin" password through REST APIs, he should also find some documentation on how to update all the basicAuth.conf files on all nodes, either manually or through solr auth -changepass or something?

          I think we should include support for changing the default credentials, though I think that it can be done in a separate issue and not strictly necessary for 6.6.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - And what if the user changes his "admin" password through REST APIs, he should also find some documentation on how to update all the basicAuth.conf files on all nodes, either manually or through solr auth -changepass or something? I think we should include support for changing the default credentials, though I think that it can be done in a separate issue and not strictly necessary for 6.6.
          Hide
          janhoy Jan Høydahl added a comment -

          I think we should include support for changing the default credentials, though I think that it can be done in a separate issue and not strictly necessary for 6.6.

          Absolutely, Currently, disable + enable works well...

          My main point was however that you won't be able to push the basicAuth.conf to all nodes with the -enable command anyway**, so you'd in any case need to run the -enable (or -remember) command locally on each node. Thus, you could just as well de-couple the two and have a unique file per instance, not per node?

          ** Well, you could of course put the PW file in ZK but that makes no sense as long as ZK is not TLS and ACL protected

          Show
          janhoy Jan Høydahl added a comment - I think we should include support for changing the default credentials, though I think that it can be done in a separate issue and not strictly necessary for 6.6. Absolutely, Currently, disable + enable works well... My main point was however that you won't be able to push the basicAuth.conf to all nodes with the -enable command anyway**, so you'd in any case need to run the -enable (or -remember ) command locally on each node. Thus, you could just as well de-couple the two and have a unique file per instance, not per node? ** Well, you could of course put the PW file in ZK but that makes no sense as long as ZK is not TLS and ACL protected
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Here's what I'm working on at the moment:

          1. ./solr auth to accept -d and -s (server dir and home dir), consistent with the start options. They are optional, and influence the effective $SOLR_HOME where the basicAuth.conf file will be kept. (Done with this on bash already, but proving nightmarish on Windows)
          2. To "remember", adding --update-include-file-only (as per this comment https://issues.apache.org/jira/browse/SOLR-8440?focusedCommentId=16009765&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16009765)

          Sounds good, Jan Høydahl?

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Here's what I'm working on at the moment: ./solr auth to accept -d and -s (server dir and home dir), consistent with the start options. They are optional, and influence the effective $SOLR_HOME where the basicAuth.conf file will be kept. (Done with this on bash already, but proving nightmarish on Windows) To "remember", adding --update-include-file-only (as per this comment https://issues.apache.org/jira/browse/SOLR-8440?focusedCommentId=16009765&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16009765 ) Sounds good, Jan Høydahl ?
          Hide
          janhoy Jan Høydahl added a comment -

          +1 for me. I sympathize with you having to fight with the totally broken CMD script language PS: Should we throw away solr.cmd and replace it with solr.ps1 ?

          Show
          janhoy Jan Høydahl added a comment - +1 for me. I sympathize with you having to fight with the totally broken CMD script language PS: Should we throw away solr.cmd and replace it with solr.ps1 ?
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          PS: Should we throw away solr.cmd and replace it with solr.ps1 ?

          No idea about powershell either.

          If we make --blockUnknown to be -blockUnknown true and, similarly, -prompt to be -prompt true, then I have a very neat way of parsing arguments in windows. Just the sight of how "solr.cmd zk" has done the options parsing and the comment "REM Clumsy to do the state machine thing for -d and -n, but that's required for back-compat" is making me nervous in going down that path. WDYT, sounds reasonable for now, as a stopgap?

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - PS: Should we throw away solr.cmd and replace it with solr.ps1 ? No idea about powershell either. If we make --blockUnknown to be -blockUnknown true and, similarly, -prompt to be -prompt true , then I have a very neat way of parsing arguments in windows. Just the sight of how "solr.cmd zk" has done the options parsing and the comment "REM Clumsy to do the state machine thing for -d and -n, but that's required for back-compat" is making me nervous in going down that path. WDYT, sounds reasonable for now, as a stopgap?
          Hide
          janhoy Jan Høydahl added a comment -

          I might even be inclined to release the feature with limited solr.cmd support for now and open a followup jira for it.

          Show
          janhoy Jan Høydahl added a comment - I might even be inclined to release the feature with limited solr.cmd support for now and open a followup jira for it.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Updated the patch:

          1. Changed -blockUnknown and -prompt to have a true|false argument.
          2. Accepts -s and -d (home and server directory), where basicAuth.conf is kept.
          3. Updated the Windows script to parse the parameters.
          4. Introduced -updateIncludeFileOnly true|false parameter, which avoids updating security.json and only updates the solr.in.sh / solr.in.cmd.

          Tested manually on GNU/Linux and Windows. Jan Høydahl, please review. I'll test a bit more before committing.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Updated the patch: Changed -blockUnknown and -prompt to have a true|false argument. Accepts -s and -d (home and server directory), where basicAuth.conf is kept. Updated the Windows script to parse the parameters. Introduced -updateIncludeFileOnly true|false parameter, which avoids updating security.json and only updates the solr.in.sh / solr.in.cmd. Tested manually on GNU/Linux and Windows. Jan Høydahl , please review. I'll test a bit more before committing.
          Hide
          janhoy Jan Høydahl added a comment -

          Did a quick visual read-through of the new patch (did not apply and test), and did not spot any red flags...

          Show
          janhoy Jan Høydahl added a comment - Did a quick visual read-through of the new patch (did not apply and test), and did not spot any red flags...
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 9be68cc3079a320d323e46c570de3e9e883052ed in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9be68cc ]

          SOLR-8440: Support for enabling basic authentication using bin/solr|bin/solr.cmd

          Show
          jira-bot ASF subversion and git services added a comment - Commit 9be68cc3079a320d323e46c570de3e9e883052ed in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9be68cc ] SOLR-8440 : Support for enabling basic authentication using bin/solr|bin/solr.cmd
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 89dc9c5e748fdebfed51ca33c3207233c9983836 in lucene-solr's branch refs/heads/branch_6x from Ishan Chattopadhyaya
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=89dc9c5 ]

          SOLR-8440: Support for enabling basic authentication using bin/solr|bin/solr.cmd

          Show
          jira-bot ASF subversion and git services added a comment - Commit 89dc9c5e748fdebfed51ca33c3207233c9983836 in lucene-solr's branch refs/heads/branch_6x from Ishan Chattopadhyaya [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=89dc9c5 ] SOLR-8440 : Support for enabling basic authentication using bin/solr|bin/solr.cmd
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit b30a042bcfbc24db8eac31d65997098ac7c8c2d9 in lucene-solr's branch refs/heads/branch_6_6 from Ishan Chattopadhyaya
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b30a042 ]

          SOLR-8440: Support for enabling basic authentication using bin/solr|bin/solr.cmd

          Show
          jira-bot ASF subversion and git services added a comment - Commit b30a042bcfbc24db8eac31d65997098ac7c8c2d9 in lucene-solr's branch refs/heads/branch_6_6 from Ishan Chattopadhyaya [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b30a042 ] SOLR-8440 : Support for enabling basic authentication using bin/solr|bin/solr.cmd
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 606b3bfc62b5b47903d21dac7e0609b6f0aeb6f1 in lucene-solr's branch refs/heads/master from Cassandra Targett
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=606b3bf ]

          Ref Guide: add auth section for SOLR-8440

          Show
          jira-bot ASF subversion and git services added a comment - Commit 606b3bfc62b5b47903d21dac7e0609b6f0aeb6f1 in lucene-solr's branch refs/heads/master from Cassandra Targett [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=606b3bf ] Ref Guide: add auth section for SOLR-8440
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 2d6edc69b365b8bcc0450b647b2facfac6e777c7 in lucene-solr's branch refs/heads/master from Cassandra Targett
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2d6edc6 ]

          Ref Guide: finish bin/solr auth docs for SOLR-8440

          Show
          jira-bot ASF subversion and git services added a comment - Commit 2d6edc69b365b8bcc0450b647b2facfac6e777c7 in lucene-solr's branch refs/heads/master from Cassandra Targett [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2d6edc6 ] Ref Guide: finish bin/solr auth docs for SOLR-8440
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 5e8eac780275e030b04f1d158ae54a58fa103dd3 in lucene-solr's branch refs/heads/branch_6x from Cassandra Targett
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5e8eac7 ]

          Ref Guide: backport all bin/solr auth doc changes relating to SOLR-8440

          Show
          jira-bot ASF subversion and git services added a comment - Commit 5e8eac780275e030b04f1d158ae54a58fa103dd3 in lucene-solr's branch refs/heads/branch_6x from Cassandra Targett [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5e8eac7 ] Ref Guide: backport all bin/solr auth doc changes relating to SOLR-8440
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 9ea8cafc4679739e2c8f6c87cde00e99de227145 in lucene-solr's branch refs/heads/branch_6_6 from Cassandra Targett
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9ea8caf ]

          Ref Guide: backport all bin/solr auth doc changes relating to SOLR-8440

          Show
          jira-bot ASF subversion and git services added a comment - Commit 9ea8cafc4679739e2c8f6c87cde00e99de227145 in lucene-solr's branch refs/heads/branch_6_6 from Cassandra Targett [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9ea8caf ] Ref Guide: backport all bin/solr auth doc changes relating to SOLR-8440

            People

            • Assignee:
              ichattopadhyaya Ishan Chattopadhyaya
              Reporter:
              janhoy Jan Høydahl
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development