Make sure that the host on which you are running the solrctl utility has either a Gateway or Solr Serverrole assigned.

In general, if an operation succeeds, solrctl exits silently with a success exit code. If an error occurs, solrctl prints a
diagnostics message combined with a failure exit code. solrctl supports specifying a log4j.properties file by setting the LOG4J_PROPS environment variable. By default, the LOG4J_PROPS setting specifies the log4j.properties in the Solr
configuration directory (for example, /etc/solr/conf/log4j.properties). Many solrctl commands redirect stderr to /dev/null, so Cloudera recommends that your log4j properties file specify a location other than stderr for log output.

You can run solrctl on any host that is configured as part of the SolrCloud deployment (the Solr service in Cloudera
Manager environments) . To run any solrctl command on a host outside of SolrCloud deployment, ensure that SolrCloud hosts are reachable and provide --zk and --solr command line options.

If you are using solrctl to manage your deployment in an environment that requires Kerberos authentication, you must have a valid Kerberos ticket, which
you can get using kinit.

Syntax

Each element and its possible values are described in the following sections.

Options

If used, the following options must precede commands:

--solr <solr_uri>: Directs solrctl to a
SolrCloud web API available at the specified URI. This option is required for hosts running outside of SolrCloud. A sample URI might be: http://search01.example.com:8983/solr.

--zk <zk_ensemble>: Directs solrctl to a
particular ZooKeeper quorum. This option is required for hosts running outside of SolrCloud. For example: zk01.example.com:2181,zk02.example.com:2181,zk03.example.com:2181/solr. Output from solrctl commands that use the --zk
option is sent to /dev/null, so no results are displayed.

--jaas /path/to/jaas.conf: Used to identify a JAAS configuration that specifies the principal with permissions to
modify Solr metadata. The principal is typically solr@EXAMPLE.COM. In Kerberos-enabled environments where ZooKeeper ACLs protect Solr metadata, you must use this
parameter when modifying metadata.

--help: Prints help.

--quiet: Suppresses most solrctl messages.

--debug: Prints errors to stdout.

--trace: Prints the executed commands to stdout.

Commands

The solrctl commands init, instancedir, config, collection, cluster, and sentry affect the entire SolrCloud deployment and only need to be run once per required
operation.

The solrctl core command affects a single SolrCloud host.

init [--force]: The init command, which initializes the overall state of the SolrCloud
deployment, must be run before starting solr-server daemons for the first time. Use this command cautiously because it erases all SolrCloud deployment state information from ZooKeeper, including all
configuration files. It does not delete collections. After successful initialization, you cannot recover any previous state.

--create <name><path>: Uploads a copy
of the instance directory from <path> on the local filesystem to ZooKeeper. If an instance directory with the specified <name> already exists, this command fails. Use --update to modify existing instance directories.

--update <name><path>: Overwrites an
existing instance directory in ZooKeeper using the specified files on the local filesystem. This command is analogous to first running --delete <name> followed by --create <name><path>.

--get <name><path>: Downloads the
specified instance directory from ZooKeeper to the specified path on the local filesystem. You can then edit the configuration and then re-upload it using --update.

--create name <baseConfig> [-p <name>=<value>: Creates a new config based on an existing config. The config is created with the specified <name>, using
<baseConfig> as the template. For more information about config templates, see Config
Templates. The -p name=value option verrides a <baseConfig> setting. The only config property that you can override is
immutable, so the possible options are -p immutable=true and -p immutable=false. If you are copying an
immutable config, such as a template, use -p immutable=false to make sure that you can edit the new config.

The collection uses the specified <configName> for its configuration set, and the specified <replicationFactor> controls the number of replicas for the collection. Keep in mind that this replication factor is on top of the HDFS
replication factor.

The maximum shards per host is determined by <maxShardsPerHost>, and you can specify specific hosts for the
collection in the <hostList>.

The only required parameters are <name> and -s <numShards>. If -c <configName> is not provided, it is assumed to be the same as the name
of the collection.

[--set-property <name><value>]: Sets property names and values.
Typically used in a deployment that is not managed by Cloudera Manager. For example, to configure a cluster to use TLS/SSL:

solrctl cluster --set-property urlScheme https

[--remove-property <name>]: Removes the specified property.

[--get-clusterstate <file>]: Downloads the clusterstate.json file from ZooKeeper
to the local system.
Note: In CDH 6, the clusterstate.json file is split per collection, and cluster state information is stored in
separate, collection-specific files under /collections/collectionname/state.json. The solrctl command still has the get-clusterstate command, but the clusterstate.json file that it downloads is empty.

There are three ways to access a collection’s state.json file in CDH 6.

Using the Solr Administration User Interface:

Open the Solr Administration User Interface.

Click Cloud > Tree, and expand /collections.

Open the collection of your choice.

Select the state.json file. The contents of the file are displayed on the right.

Note: The use of the curl command depends on whether Kerberos and SSL are enabled or not. If Kerberos is enabled, it
needs kinit. If SSL is enabled, the http port changes to https and the port default value changes from 8983 to 8985. For more information, see Using Kerberos with curl.

[--revoke-privilege <role><privilege>]: Revokes the specified
privilege from the specified role.

[--list-privileges <role>]: Lists all privileges granted to the specified role.

[--convert-policy-file <file> [-dry-run]]: Converts the specified policy file
to permissions in the Sentry service. This command adds roles, assigns roles to group, and grants permissions. For CDH versions 5.12 and higher, the Solr Gateway
role includes HDFS configuration files to facilitate Sentry integration. Because of this, the <file> path must be specified as
file:///path/to/file, or else the solrctl sentry command attempts to locate the file in HDFS.

The file-based model allows case-sensitive role names. During conversion, all roles and groups are converted to lower case.

If a policy-file conversion will change the case of roles or groups, a warning is presented. Policy conversion can proceed, but if you have enabled document-level security and use role
names as your tokens, you must re-index using the new lower case role names after conversion is complete.

If a policy-file conversion will change the case of roles or groups, creating a name collision, an error occurs and conversion cannot occur. In such a case, you must eliminate the
collisions before proceeding. For example, you could rename or delete the roles or groups that cause a collision.

The -dry-run option runs the process of converting the policy file, but sends the results to stdout without applying the changes. This can be used for
quick turnaround when debugging failures.

If this documentation includes code, including but not limited to, code examples, Cloudera makes this available to you under the terms of the Apache License, Version 2.0, including any required
notices. A copy of the Apache License Version 2.0 can be found here.