Managing Cloudera Search Configuration

You can manage configuration objects directly using the solrctl config command, which is a wrapper script for the ConfigSets API.

Configs are named configuration sets that you can reference when creating collections. The solrctl config command syntax is as follows:

solrctl config [--create <name> <baseConfig> [-p <name>=<value>]...]
               [--delete <name>]

• --create <name> <baseConfig>: 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.
  • -p <name>=<value>: Overrides 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.
• --delete <name>: Deletes the specified config. You cannot delete an immutable config without accessing ZooKeeper directly as the solr super user.

If you are using Apache Sentry, you must have permissions for the specific config you are creating or deleting, as well as the admin=collections privilege object.

An instance directory is a named set of configuration files. You can generate an instance directory template locally, edit the configuration, and then upload the directory to ZooKeeper as a named configuration set. You can then reference this named configuration set when creating a collection.

Creating configuration sets using instance directories cannot be restricted using Sentry. If you want to control access to configuration sets, you must enable ZooKeeper ACLs and use configs instead.

The solrctl instancedir command syntax is as follows:

solrctl instancedir [--generate <path> [-schemaless]]
                    [--create <name> <path>]
                    [--update <name> <path>]
                    [--get <name> <path>]
                    [--delete <name>]
                    [--list]

• --generate <path>: Generates an instance directory template on the local filesystem at <path>. The configuration files are located in the conf subdirectory under <path>.
  • -schemaless: Generates a schemaless instance directory template. For more information on schemaless support, see Schemaless Mode Overview and Best Practices.
• --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.
• --delete <name>: Deletes the specified instance directory from ZooKeeper.
• --list: Lists existing instance directories as well as configs created by the solrctl config command.

You can restrict access to configuration sets by setting ZooKeeper ACLs on all znodes under and including /solr and using Sentry to control access to the ConfigSets API. Sentry requires Kerberos authentication.

The solrctl instancedir command interacts directly with ZooKeeper, and therefore cannot be protected by Sentry. Because the solrctl config command is a wrapper script for the ConfigSets API, it can be protected by Sentry.

To force users to use the ConfigSets API, you must set all ZooKeeper znodes under and including /solr to read-only (except the solr user):

1. Create a jaas.conf file containing the following:

   Client {
     com.sun.security.auth.module.Krb5LoginModule required
     useKeyTab=false
     useTicketCache=true
     principal="solr@EXAMPLE.COM";
   };
   

   Replace EXAMPLE.COM with your Kerberos realm name.

2. Set the LOG4J_PROPS environment variable to a log4j.properties file:

   export LOG4J_PROPS=/etc/zookeeper/conf/log4j.properties

3. Set the ZKCLI_JVM_FLAGS environment variable:

   export ZKCLI_JVM_FLAGS="-Djava.security.auth.login.config=/path/to/jaas.conf \
   -DzkACLProvider=org.apache.solr.common.cloud.SaslZkACLProvider \
   -Droot.logger=INFO,console"

4. Authenticate as the solr user:

   kinit solr@EXAMPLE.COM

   Replace EXAMPLE.COM with your Kerberos realm name.

5. Run the zkcli.sh script as follows:
   • Cloudera Manager Deployment:

     /opt/cloudera/parcels/CDH/lib/solr/bin/zkcli.sh -zkhost zk01.example.com:2181 -cmd updateacls /solr

   • Unmanaged Deployment:

     /usr/lib/solr/bin/zkcli.sh -zkhost zk01.example.com:2181 -cmd updateacls /solr

   Replace zk01.example.com with the hostname of a ZooKeeper server.

After completing these steps, you cannot run commands such as solrctl instancedir --create or solrctl instancedir --delete without first authenticating as the solr@EXAMPLE.COM super user principal. Unauthenticated users can still run solrctl instancedir --list and solrctl instancedir --get, because those commands only perform read operations against ZooKeeper.

After setting ZooKeeper ACLs, you must configure Sentry to allow users to create and delete configs. For instructions on configuring Sentry for configs, see Configuring Sentry Authorization for Cloudera Search.