Indexing and Search Service Command-Line Utilities

Skip to end of metadata
Go to start of metadata

Indexing and Search Service Command-line Utilities

Topics:

List of Indexing and Search Service Utilities

The following table contains information about the command-line utilities that can be used to administer ISS.

Message Store Command-line Utilities

Utility Description
checkIndex.sh Checks individual index directories for consistency, and corrects some errors (Lucene tool for debugging).
checkIss Checks the status of ISS to verify that the ISS services are running and that the log files have been written to recently.
checkStack Checks the ISS installation by bootstrapping a user then performing a search through the RESTful interface.
csearchmgr.sh Adds and removes Cluster Search Services for one or many indexing nodes.
factorymgr.sh Views and manages JNDI lookup objects.
issadmin.sh Prints information about the ISS store instance and provides options to administer the ISS store.
isshttpdmgr Starts and stops the isshttpd service, and configures Directory Server entries for the lookup table.
issrehostuser.sh Automates the movement of accounts from one ISS instance to another.
issversion Reports the version of ISS.
mergeIndex.sh Merges multiple index files.
search_query_number.sh Reports the number of search queries that have been run since the last time that the searchSvc service was restarted.
searchRun.sh Searches the index interactively, from the command line. Prompts for input and displays the results of the query to standard output.
svc_control.sh Starts and stops ISS services.
watchermgr.sh Enables or disables the watcher service outside of the standard ISS setup script.

Other Tools

Indexing and Search Service provides other tools based on Lucene for manipulating index directories within the store instance. For more information, see Other ISS Tools.

Deprecated Commands

indexSvcBootstrap.sh

Beginning with Indexing and Search Service 1 Update 2, the indexSvcBootstrap.sh command is deprecated. Use issadmin.sh --bootstrap instead.

The indexSvcBootstrap.sh utility is used to create the initial index for an account, known as bootstrapping the account. For accounts which exist on the content server (Messaging Server) prior to installation of the Indexing and Search Services, the data in each account must be initially indexed before the search can be used. This command is used to extract data from the content server (by using the standard IMAP interface) and create the index for each account. (Depending on how many accounts and how much data (email) each has, this can take considerable time. This command is multithreaded to speed up this process; however, it also might produce significant load on the Messaging Server IMAP service, because it must access every email in each account.)

Requirements: Must be root or the ISS user. The content server must be configured to enable access to each account by using the IMAP interface. An account may or may not exist in the index when you use this command. If the account already exists, then it must not be already in the Active state. The index must not contain any records for any folders to be bootstrapped by this command, or duplicate index records may be created.

Location: iss-base/indexapi/scripts/indexSvcBootstrap.sh

Indexing and Search Service 1 Update 1: Also in iss-base/bin/indexSvcBootstrap.sh

Syntax

indexSvcBootstrap.sh --host <HOST> --user USER [--datapath PATHNAME]
 [--folder FOLDER] [--group GROUPNUM]
 [--loglevel ALL|CONFIG|FINE|FINER|FINEST|INFO|SEVERE|WARNING] [--password]
 [--passwordfile FILE] [--port PORT] [--protocol ssl|tls]
 [--runoptimizer true|false] [--singleton] [--skipfolder SKIPFOLDER]
 [--storepath PATHNAME]

Options

These are the options for this command:

Option Description
--host HOST Required. Specifies the host or domain of the account to be indexed.
--user USER Required. Specifies the user name of the account to be indexed.
--datapath PATHNAME Optional. Specifies the path of an alternative ISS data (that is, attachment) store to use. The default data store (from the configuration parameter iss.data.dir) is used unless this option is specified. The path specified includes the final directory, in the same fashion as is specified in the iss.data.dir parameter. See also --storepath option. Be careful when specifying --datapath because you might also need to use --storepath to obtain the results you want.
--folder FOLDER Optional. Specifies to index only this one folder of the account. This includes any nested folders.
--group GROUPNUM Optional. Specifies the integer group number into which the account index will be placed. If not specified, the default allocation policy will select a group into which to place the account. See ISS Store Instance Overview and Concepts for more information on default allocation policy.
--loglevel ALL|CONFIG|FINE|FINER|FINEST|INFO|SEVERE|WARNING Optional. Specifies the level of logging information to be generated by the bootstrapping process.
--password Optional. For development only. It is not meant for production use because it puts the password in the command-line arguments, which is not secure.
--passwordfile FILE Plaintext. If --password option is provided, you are prompted for the password.
--port PORT Optional. Used to specify the port for the IMAP connection to the content server (Messaging Server). Default is 143.
--protocol sls|tls Optional. Used to specify the security protocol used by the IMAP connection to the content server (Messaging Server). By default, no security protocol is assumed to be needed.
--runoptimizer true|false Optional. Used to indicate whether the index being created should be optimized at the conclusion of the bootstrapping. Optimization will make the process take a little longer, but the additional time is usually not significant relative to that of the rest of the processing. However, search performance of an optimized index may be significantly better than the unoptimized index.
--singleton Optional. Specifies that the target group of the indexing must contain only the one account being bootstrapped.
--skipfolder SKIPFOLDER Optional. Specifies that the folder named SKIPFOLDER in the account is not to be indexed during this bootstrap process. This is sometimes useful if there is some problem with a certain folder or if it contains a huge number of emails such that processing it would take an inordinate amount of time.
--storepath PATHNAME Optional. Specifies the path of an alternative ISS store to use. The default store (from the configuration parameter iss.store.dir) is used unless this option is specified. The path specified does not include the final "/store", just the full path name up to it (such as /var/iss/index). See also --datapath option. Be careful when specifying --storepath because you might also need to use --datapath to obtain the results you want.

Arguments can appear in any order.

Example

# cd /opt/sun/comms/jiss/indexapi/scripts
# ./indexSvcBootstrap.sh --user user1 --host mailhost.example.com --runoptimizer true

indexSvcFork.pl

In Indexing and Search Service 1 Update 1, this command is replaced by indexSvcFork.sh.

The indexSvcFork.pl utility provides a means to bootstrap a list of users in parallel.

Requirements: Must be run as root or the ISS user.

Location: iss-base/indexapi/scripts/indexSvcFork.pl

Syntax

indexSvcFork.pl [ -f filename ] [ -m mailhost ] [ -n max number of spawns ]
   [ -p polling interval(seconds) ] [ -t timeout(seconds) ]

Options

These are the options for this command:

Option Description
-f filename Required. File name containing list of users to index, single user name per line.
-m mailhost Optional. Mail host of the users to be indexed. Defaults to mail.server in the jiss.conf file.
-n max number of spawns Optional. Number of indexSvcBootstrap.sh calls to create at one time. Defaults to 5.
-p seconds Optional. How often processes should be polled for completion (seconds). Defaults to 1 second.
-t seconds Optional. How long an indexSvcBootstrap.sh should run before timing out(seconds). Defaults to 3600 seconds.

Example

# cd /opt/sun/comms/jiss/indexapi/scripts
# ./indexSvcFork.pl -f users.conf -m mailhost.example.com -n 10

indexSvcFork.sh

  • Beginning with Indexing and Search Service 1 Update 2, the indexSvcFork.sh command is deprecated. Use issadmin.sh --bootstrap with the -accountlist option instead.
  • This command was introduced with Indexing and Search Service 1 Update 1.

The indexSvcFork.sh utility provides a means to bootstrap a list of users in parallel.

Requirements: Must be run as root or the ISS user.

Location: iss-base/indexapi/scripts/indexSvcFork.sh (or iss-base/bin/indexSvcFork.sh)

Syntax

indexSvcFork.sh  --file FILE  [ --host hostname ] [ --threads num_threads ]
                    [ --runoptimizer true|false ] [ --timeout num_seconds ]
                    [ --port PORT ] [ --protocol ssl|tls ]

Options

These are the options for this command:

Option Description
--file filename Required. File name containing list of users to index; file format is the same as for the --accountlist option of the issadmin.sh utility.
--host mailhost Optional. Mail host of the users to be indexed, if not specified in the file.
--threads num_threads Optional. Number of bootstraps to run in parallel. Defaults to 8.
--runoptimizer true|false Optional. Whether or not to optimize the account. Defaults to false.
--timeout num_seconds Optional. How long in seconds a bootstrap should run before timing out. Defaults to 50000 seconds.
--port PORT Optional. What port the imap server is running run, default is mail.imap.port in jiss.conf.
--protocol ssl/tls Optional. Use specified type of encryption for imap instead of default in jiss.conf.

Example

# cd /opt/sun/comms/jiss/indexapi/scripts
# ./indexSvcFork.sh --file /tmp/users.conf --host mailhost.example.com --threads 10
Labels:
indexsearchservice indexsearchservice Delete
reference reference Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.