Example solrctl Usage

This topic includes some examples of:

  • Configuration changes that may be required for solrctl to function as desired.
  • Common tasks completed with solrctl.

Continue reading:

Using solrctl with an HTTP proxy

Using solrctl to manage a deployment in an environment that uses an HTTP proxy fails because solrctl uses curl, which attempts to use the proxy. You can disable the proxy so solrctl succeeds:

  • Modify the settings for the current shell by exporting the NO_PROXY environment variable. For example: 
    export NO_PROXY='*'
  • Modify the settings for single commands by prefacing solrctl with NO_PROXY='*'. For example: 
    NO_PROXY='*' solrctl collection --create collectionName -s 3

Creating Replicas of Existing Shards

You can create additional replicas of existing shards using a command of the following form:

solrctl core --create <newCore> -p collection=<name> \
-p shard=<shard_to_replicate>

For example to create a new replica of collection named collection1 that is comprised of shard1, use the following command:

solrctl core --create collection1_shard1_replica2 \
-p collection=collection1 -p shard=shard1

Converting Instance Directories to Configs

Cloudera Search supports converting existing deployments that use instance directories to use configs:

  1. Create a temporary config based on the existing instance directory. For example, if the instance directory name is weblogs_config: 
    solrctl config --create weblogs_config_temp weblogs_config \
-p immutable=false
  2. Delete the existing instance directory. For example: 
    solrctl instancedir --delete weblogs_config
  3. Create a config using the same name as the instance directory you just deleted, based on the temporary config you created earlier. 
    solrctl config --create weblogs_config weblogs_config_temp \
-p immutable=false
  4. Delete the temporary config: 
    solrctl config --delete weblogs_config_temp
  5. Reload the affected collection (weblogs in this example): 
    solrctl collection --reload weblogs

Configuring Sentry for a Collection

If you have enabled Apache Sentry for authorization, you must have UPDATE permission for the admin=collections object as well as the collection you are creating (test_collection in this example). You can also use the wildcard (*) to grant permissions to create any collection.

For more information on configuring Sentry and granting permissions, see Configuring Sentry Authorization for Cloudera Search.

To grant your user account (jdoe in this example) the necessary permissions:

  1. Switch to the Sentry admin user (solr in this example) using kinit: 
    kinit solr@EXAMPLE.COM
  2. Create a Sentry role for your user account: 
    solrctl sentry --create-role test_role
  3. Map a group to this role. In this example, user jdoe is a member of the eng group: 
    solrctl sentry --add-role-group test_role eng
  4. Grant UPDATE privileges to the test_role role for the admin=collections object and test_collection collection: 
    solrctl sentry --grant-privilege test_role 'admin=collections->action=UPDATE'
solrctl sentry --grant-privilege test_role 'collection=test_collection->action=UPDATE'
    For more information on the Sentry privilege model for Cloudera Search, see Authorization Privilege Model for Cloudera Search.