Configuring the Connector for File Systems (Deprecated)

Google Search Appliance software versions 7.0 and later
Connector Manager version 3.0.4 and later



The Google Search Appliance Connector for File Systems enables the Google Search Appliance to index and search content and related metadata stored in file systems.

The Connector for File Systems is preinstalled on the Google Search Appliance with search appliance software version 7.0 and higher and is also available to install on a separate host.

This document is for File Systems administrators and administrators who install and configure the Google Search Appliance. If you are not familiar with the system that the connector will traverse and index, work closely with your system administrators to determine the correct values for installing and configuring the connector.


New Features

The Google Search Appliance (GSA) Connector for File Systems release 3 is a major re-engineering of the File System Connector implementation. The connector is no longer using the Diffing Connector model. It is now using the to a Lister/Retriever model. In the past, the connector compared what had changed between crawls to gather new information for indexing. Now, the connector sends links (lists) to the GSA, which the GSA then can crawl using standard HTTP. The most significant improvements are:

  • Faster feed and indexing performance.
  • Support for ACL inheritance and ACL deny access for SMB file systems (with GSA 7.0 and higher).
  • Coordination with the Traversal Schedule.
  • Support for HTTPS requests from the Google Search Appliance
  • Support for policy ACLs.

Upgrading From Previous Versions

Before applying an update you should have the following available to you:

  • Administrative access to the GSA that the Connector is feeding.
  • Access to the computer running the Connector and its Tomcat application server. You will need sufficient access rights to start and stop Tomcat and modify files in its deployment directory.
  • A binary distribution of the Connector Manager version 3 release, available on the Connector Manager Downloads page.
  • A binary distribution of the File System Connector version 3 release, available on the File System Connector Downloads page.
  • Familiarity with the command line environment of the deployment computer (cmd.exe on Windows or a shell environment on Unix/Linux).
  • Knowledge of the appropriate rules for using late binding, if you wish to use late binding. The new file system connector doesn't use googleconnector:// URLs. This means that it isn't matched in the default Connector Flexible Authorization rule.

For detailed instructions, please see Instructions for manually upgrading to File System Connector version 3 in Release Notes.


Getting Started

The connector feeds all documents that can be accessed using the credentials you provide at configuration time and that match the include and exclude patterns.


Supported File System Protocols

The Google Search Appliance (GSA) Connector for File Systems is supported in this release with the following file system protocols:

  • SMB 1.0 for Windows
  • CIFS, which is a variety of SMB, on Windows
  • Windows file shares with offboard servers
  • DFS with stand-alone root and domain root
  • Windows Clusters on Microsoft Cluster Service using the Shared Nothing model. The File Connector is not supported with the Shared Disk and Mirrored Disk models.
  • Samba on UNIX and Linux

Features

These features are supported:

  • Files and folders
  • General properties
  • Document-level ALLOW ACLs
  • Document-level DENY ACLs (only with GSA 7.0 and higher)
  • User name and password credentials
  • NTLM
  • Directory level ACLs
  • Policy ACLs
    Note: If you are updating Policy ACLs, you will need to change the Policy ACL patterns for version 3.0 of the connector.
  • NFS v2 and v3, but the support does not include ACLs.
  • Support for ACL inheritance and deny for SMB file systems (only with GSA 7.0 and higher)

Limitations

The File System Connector does not support the following:

  • SMB 2.0, 2.2, or 3.0
  • NFS 4
  • Custom properties (extended attributes)
  • Windows Workgroups
  • Kerberos or X.509 certificates
Note: Kerberos/X.509 authentication is not supported for the traversal user id (which is used to traverse the repository and crawl the documents.) However if you use other forms of authorization at serve time, it is supported.

Setting the Port

For the on-board connector, ensure that the GSA can connect to the file share using the following ports. In case of off-board connector, ensure that the host of the Connector Manager can connect via these ports to your fileshare. These settings apply for Windows File Shares.

  • tcp 445
  • tcp 139

Validating Connector Host Privileges

To run the connector installer, you must have the following user privileges on the connector host:

  • On Windows, you must be an administrator.
  • On Linux, you must have sufficient rights to execute the installer file. You can be a root or nonroot user.

On the File Share Server, if you are the user whose credentials are entered on the Google Search Appliance for performing the crawl, you must also be a member of one of the following groups on the file share server. Otherwise, the search appliance cannot extract ACLs from the documents:

  • Administrator
  • Power User
  • Print Operator
  • Server Operator
Note: It is not sufficient to be a member of one of the groups at the Domain level. For more information, read the following Microsoft document: http://msdn.microsoft.com/en-us/library/bb525388(VS.85).aspx
Important: In addition, the crawl user needs to have at least Read permission for both the files and folders the connector will traverse.

Validating Directory Access

Before you use the File System connector, ensure that all directories the search appliance will traverse are accessible:

  • Windows file shares must be accessible directly using the CIFS protocol.
  • Linux file shares must be accessible using the SMB protocol using Samba or other daemons.

Determining what to Index

The file connector indexes documents that match the included directory and file patterns that you enter on the Admin Console on the connector configuration form. Before you configure the file connector, determine which directories and files you want indexed and which you want excluded using the connector’s settings for “Include Patterns” and “Exclude Patterns”. Editing these settings is explained in Getting Started. This section contains tips about what to include or exclude. Configuring these settings wisely will cause the connector to index only those files that matter to searchers, enhancing performance, improving result relevance, and reducing troubleshooting efforts.

If you know you only desire to index a few document types (for example, MS Office docs or PDFs), using Include Patterns will be the easiest way to configure these settings and it is relatively simple. However, “Exclude Patterns” tends to be simpler to express, as shown in the example.

File system connector exclude patterns

Here are explanations for the less-obvious choices in the screenshot above:

  • "contains:/." will exclude files or directories whose first character is "." - hidden files in Unix parlance.
  • "~$" would exclude files that end in the "~" character because these are backup files created by certain text editors.

But more important than deciding which file types to include or exclude is deciding which directories to include or exclude. At times, customers see log files full of warnings about traversing inappropriate content - either the traversal user does not have permission to access large bodies of content, or there are obvious directories that should not be included. For example:

  • (\Windows\System32,
  • \Windows\Program Files
  • database storage directories
  • .Trash
  • /tmp

Careful thought when choosing appropriate included and excluded directories can save the connector a great deal of time by avoiding directories with irrelevant content.


Configuring a Connector on the Admin Console

Use the Add Connector page in the Google Search Appliance Admin Console to create and configure a file connector instance. The Add Connector page prompts you to enter values for all required configuration parameters.

To add a file connector:

  1. On the Google Search Appliance Admin Console, click Connector Administration > Connectors.

    Admin Console Connector Admin menu

    The list of existing connectors is displayed.

  2. Click Add New Connector.

    Additional fields are displayed.

    Admin Console Add Connector file system example

    In the Connector Name field, type the name of the connector instance. Each connector instance added to a particular connector manager or Google Search Appliance must have a unique name.

    The connector name must be:

    • all lower case.
    • a maximum of 64 alphanumeric characters

    The connector name:

    • can include underscores (_) and hyphens (-).
    • cannot begin with a number or a hyphen.
  3. On the Type drop-down list, select File Connector Type.
  4. Click Get Configuration Form.

    The connector manager name, connector name, and connector type are displayed. These fields cannot be edited.

    File system connector configuration start paths

  5. In the Start paths field, type the root directories from which you want traversal to start. You must specify the hostname as a Fully qualified host name (FQDN). For example: smb://fileserver.domain.com/docs/
  6. To add more rows, click Add another row.
  7. In the Include patterns field, type any file patterns you want included in the traversal. For example, entering the pattern regexp:.* instructs the connector to traverse all documents under the Start path. Please see Determining what to Index for guidelines and tips.
  8. To add more rows, click Add another row.
  9. In the optional Exclude patterns field, type any file patterns you want excluded from traversal. For example, entering the pattern regexpIgnoreCase:\\.ppt$ instructs the connector to ignore all PowerPoint presentation documents.
  10. To add more rows, click Add another row.
  11. In the optional Domain field, type in the domain to be traversed.

    File system connector configuration fields

  12. In the Username field, type the user name of a user who has access to the file system.
  13. In the Password field, type the password for the file system user.
  14. In Full Traversal interval (days) enter the number of days appropriate for the amount and file types of the content. Refer to Full and Incremental Traversals for details.
  15. In the Advanced properties selection, choose Show to fine tune security and related settings.

    File system configuratino advanced properties

    To learn about these parameters, see Configuring ACE Formats using the Advanced Configuration properties.

  16. Enter values for Global and Local Namespace.

    File system configuration namespace

    File system configuration traversal settings

  17. In the Traversal Rate section, type the number of documents per minute that you want traversed.
  18. In the Retry Delay section, specify the number of minutes to wait between the time when a traversal is completed and the time when the next traversal starts.
  19. To disable traversal, check Disable traversal.
  20. In the Connector Schedule section, indicate the hours between which you want the repository traversed.

    Note that a connector scheduled to run from 12 a.m. to 12 a.m. always runs. Any other schedule with the same beginning and ending time never runs, either for a connector or for the Google Search Appliance’s standard crawl function.

  21. Click Add Line to Schedule for each additional traversal period you want to schedule.
  22. Click Save Configuration.

    Clicking Save Configuration runs a connectivity test. If there are any errors, you will see them displayed on the Admin Console. Correct the errors and click Save Configuration again. If the connector is configured correctly, the new connector name will appear on the Connectors list.


Security Concepts, Tips, and Settings

This section describes advanced configuration relating to security settings.

ACL Namespaces, ACL Inheritance, and Deny ACLs

Access Control Lists (ACLs) may be inherited from a parent folder or file share. This reduces the number of files/directories that must be re-indexed as a result of an ACL change to a folder far up the directory hierarchy.

The Connector for File Systems also supports Deny ACLs - ACLs which deny access to specific individuals or groups, local and global namespaces for ACL users and groups.

Note: Note GSA version 7.0 or newer is required to support ACL namespaces, inheritance, and Deny ACLs. The file system connector only supports ACLs for SMB file systems at this time.

Default User and Group ACL Formats Have Changed

The default ACL format changed between file system connector version 2.x and version 3.0. The new default user ACL format is domain\user. The new default group ACL format is domain\group. These new defaults will be the most appropriate formats to use with GSA version 7.0 and later. The previous ACL formats, user and group (without the domain), are unlikely to work with GSA version 7.0. If the Authentication mechanism for this connector returns a domain element, then the user and group ACLs must also include the domain.

If you have previously explicitly configured the user and group ACL formats in the Advanced Configuration, that explicit configuration will still be honored (although you may wish to change it if you are upgrading the GSA as well as the connector.)

If you have not explicitly configured the user and group ACL formats, the new default format will be used. If, when using file system connector version 3.0, you wish to use the unadorned “user” and “group” formats, you must explicitly enable those formats in the Advanced Configuration.

Configuring ACE Formats using the Advanced Configuration properties

To configure the way in which Access Control Entries (ACEs) are fed to the GSA, select Show to see and edit the Advanced properties.

ACE advanced properties

This will configure the connectorInstance.xml file. These are the values available.

  1. Locate the aceSecurityLevel parameter that you want to change.
  2. Uncomment the parameter if it is commented out.
  3. Change the value of the parameters as desired.
 
Property Name Possible Values Default Value Comments
aceSecurityLevel FILEANDSHARE
SHARE
FILE
FILEORSHARE
FILREORSHARE

This is the most restrictive value, so it is the default.

Security level to be considered for fetching ACL for a file

The four possible values listed are in the order of stronger to weaker security levels.

Note: For GSA 7.0 and above, this configuration is ignored and FILEANDSHARE is always used, unless inherited ACLs are disabled in the Connector Manager advanced configuration.

markDocumentPublicFlag true
false
false Flag to mark all crawled documents as 'public'.
lastAccessResetFlagForSmbl true
false
false Flag to reset the last access time of a SMB file after crawling.
markDocumentPublicFlag true
false
false Flag to mark all crawled documents as 'public'.
lastAccessResetFlagForLocalWindows true
false
false Flag to reset the last access time of a local windows file after crawling. Use this when the start path of the url is a windows style file path. E.g. "c://share/data"
pushAclFlag true
false
true Flag to determine whether or not to include ACLs in the feed.
groupAclFormat domain\group
group@domain
group
domain\group Represents the format in which ACE entries should be fed to GSA for groups

Specifying group indicates only the group name without domain information.

Note: For GSA 7.0 and above, omitting the domain name is rarely the correct choice. Use it only if your authentication mechanism does not supply a domain.

userAclFormat domain\user
user@domain
user
domain\user Represents the format in which ACE entries should be fed to GSA for groups

Specifying user indicates only the group name without domain information.

Note: For GSA 7.0 and above, omitting the domain name is rarely the correct choice. Use it only if your authentication mechanism does not supply a domain.

ifModifiedSinceCushionMinutes   60 Cushion for inaccurate timestamps in if-modified-since comparisons, usually due to unsynchronized clocks.

The cushion value is the number of minutes before the if-modified-since check time in which a file may still be considered modified.

For instance, if the cushion is 60 minutes, and we are looking for files modified since time X, a file modified at X - 30 minutes would still qualify.

threadPoolSize   10 Number of threads in the traversal thread pool. Each start point is traversed in its own thread, so this value affects how many start points may be traversed concurrently.

Using Late Binding

The Connector for File Systems does not support HEADREQUEST authorizations.

To use late binding, configure a flexible authorization rule for the connector's URLs and route to it using Connector Authorization. If you have multiple File System connectors, you must add multiple flex authorization rules with a specific URL pattern.

To use Late Binding, you need a separate rule for each File System connector you want to use with late binding. Create a Connector Flexible Authorization rule with the URL Pattern something like:

^http://localhost:7886/connector-manager/getDocumentContent\?ConnectorName=myconnector

(where 'my connector' is the name of the connector) and the appropriate Connector Name, and where “host” and “port” are those of the machine running the connector, not the file share.

Please see the Google Search Appliance Connector documentation page for updated details.


Operating System Limitations on ACL/ACE sizes

As the Microsoft knowledge base explains, the size of an Access Control List (ACL) depends on the number and size of its Access Control Entries (ACEs. The maximum size of an ACL is 64K, which is about 1,820 ACEs. If this limitation is approached, the File System Connector will report failure to traverse warning messages, and will not be able to feed to the GSA.

This limitation applies to the following operating systems:

  • Microsoft Windows Server 2003
  • Microsoft Windows XP
  • Microsoft Windows 2000
  • Microsoft Windows NT

Traversal

The following sections describe traversal for the Google Search Appliance Connector for File Systems, including new features for 3.0, setting up schedules, tuning, and monitoring.


Traversal Schedule Awareness

The Google Search Appliance Connector for File System 3.0 is aware of the Traversal Schedule, including scheduled traversal intervals, Retry Delay, and run-once traversals (Retry Delay of -1). The Retry Delay governs the delay between traversals of the repository.

Deprecated Settings

Previous versions of this connector ignored the Traversal Schedule, replicating certain functionality with advanced configuration options. Since the connector is now aware of the Traversal Schedule, the following advanced configurations have been deprecated and will be ignored if set:

  • "delayBetweenTwoScansInMillis"
  • "introduceDelayAfterEveryScan"
Full and Incremental Traversals

Here are some important tips and concepts about full and incremental traversals. The Full Traversal Interval governs the interval between full, rather than incremental, traversals of the repository. Most traversals are incremental traversals and look only for items that have changed since the last traversal, based upon the file's last-modified timestamp.

  • Some traversals are full traversals, which feed all appropriate contents of the repository to the Search Appliance.
  • You may wish to configure the forced Full Traversal Interval for the needs of your organization. File and directory adds and copies and changes to file contents are detected during the connector's incremental traversals. However, moved or renamed files and changes to ACLs and other metadata may only be detected during full traversals.
  • Frequent full traversals may overwhelm the Search Appliance, bogging down its feed processing. Long full traversal intervals increase the time it takes for the Search Appliance to notice certain types of changes.
  • A full traversal may also be triggered manually at any time by resetting the connector in the Search Appliance Admin Console.
  • A full traversal is automatically triggered if you change the connector's configuration or schedule, or restart the Tomcat web application server.
  • If you have a large number of files in your repository (more than 1 million), the default Retry Delay and Full Traversal Interval values are likely too small. Consider Retry Delay values of hours (4 hours = 240 minutes).
  • Consider a Full Traversal Interval that is at least 2 days for each million documents fed.
  • At this time, the connector ignores the Traversal Rate configuration.

Details about these concepts and tips are in the following sections.

Considering Multiple Connectors

Typically, each instance of the Connector for File Systems can traverse hundreds of thousands of documents per day. However, if you have a large number of PowerPoint documents, the traversal rate is much lower. Google recommends that you set up multiple File System connector instances to ensure a high traversal speed during the discovery phase of the traversal. This is easier to configure if your content repository can be subdivided so that there are multiple start paths.


Creating and Tuning Connector Schedules

When you schedule connector instances, the performance of the repository is a significant consideration. Depending on the number of traversals and the size of the documents retrieved for indexing, the use of connectors may degrade repository performance. Monitoring and performance-tuning the repository server is especially important when you deploy a new connector or document repository.

Note that a connector scheduled to run from 12 a.m. to 12 a.m. never stops. Any other schedule with the same beginning and ending time never runs, either for a connector or for the Google Search Appliance’s standard crawl function.

When you determine the connector schedule, consider:

  • When to run the traversal process

    For example, add a connector instance to run in off-peak hours to spread out the initial index creation during times of low demand on the repository.

  • How long to run the traversal process

    For example, set a very brief schedule to perform predeployment testing, and to experiment with the effects of lengthening the schedule.

A connector instance cannot self-modify its traversal schedule. Therefore, you must monitor the performance of both the Google Search Appliance and the content management system regularly, and make manual adjustments to the traversal schedules of connectors to optimize performance. You can tune scheduling for optimal performance in these ways:

  • Create a schedule that minimizes the number of concurrent traversal processes that are running.
  • Restrict the times at which those processes run. For example, if the content management system is executing a resource-intensive job, the connector might run slowly. Schedule the connector to run at times when demand on the content management system is light.
Traversal Time Limit

The connector manager will interrupt a connector that takes too long to process a batch of documents. The default duration after which the connector manager interrupts the connector is 1800 seconds, or 30 minutes. The duration is set by the value of the traversal.time.limit property in the applicationContext.properties file. If you want a shorter duration, you can change the value of traversal.time.limit.

To change the default value of the traversal.time.limit property:

  1. Stop Apache Tomcat.
  2. Open the applicationContext.properties file in a text editor. The top of the file contains comments with explanatory text. Do not uncomment any of the explanatory text, including the example for traversal.time.limit.
  3. Examine the file to see whether there is a traversal.time.limit entry.
    • If there is an entry, modify the duration.
    • If there is no entry, add one to the end of the file:

      traversal.time.limit=duration_in_seconds

  4. Save the file.
  5. Restart Tomcat.
Changing the Connector Retry Delay and Schedule

The search appliance Admin Console enables you to modify the connector retry delay, which is the time period that elapses between when one traversal is completed and the next starts. For example, you might want the connector to traverse the repository every hour between 8 a.m. and 8 p.m. or every two hours from midnight to 9 a.m.

The default retry delay is 5 minutes.

To change the traversal schedule, set the start and end times for traversal on the Connector Schedule drop down menus.

Resetting the Traversal

When you reset the traversal, the content is traversed in full from the beginning point and the index is recreated.

In search appliance software version 7.0 and later, use Reset link for the connector instance on the Admin Console > Connectors page.

The Retry Delay determines how long the connector waits after completing a traversal before starting a new traversal. The Full Traversal interval (a separate configuration) determines whether the next traversal will be a Full Traversal or an Incremental traversal.

When to Restart the Connector Service

Restarting the connector service means restarting Apache Tomcat. Restart the connector service only under the following circumstances:

  • When you manually edit the connector’s properties file or one of the configuration files (applicationContext.xml, applicationContext.properties, logging.properties, or connectorInstance.xml). Alternatively, for edits to the connectorInstance.xml file only, you can apply the changes on the Admin Console, without restarting the connector service. Click the Edit link for the connector instance, then click Save Configuration.
  • When you install a connector or connector manager JAR file.

Understanding Serving

Using the Google Search Appliance and Google Search Appliance Connector for File Systems to search a file share is similar to using Google.com to search the web.

To locate particular information or documents in the repository, a user opens a browser window and navigates to a search page. The search page can be the default search page available on the Google Search Appliance or it can be a customized search page. The user types a search term in the search box and clicks Search.

The Google Search Appliance searches its index for documents and metadata containing the user’s search term.

When the Google Search Appliance finds all the documents that match the search request, it presents the user with a pop-up window and asks for the user’s user name and password. The connector manager passes the search results and the user credentials to the repository server. The repository server authenticates the user, evaluates the permissions for each document returned by the user’s search, determines which documents the user is authorized to view, and returns that information to the connector manager.

The Google Search Appliance displays a results page listing the documents the user is authorized to view. When the user clicks a link on the results page, a web client window opens in which the user can view the document or its metadata, depending on how the connector is configured. If the user does not have an open session to the repository, the web client asks for the user’s login credentials before displaying the document.


Understanding the Lister/Retriever Model

The Google Search Appliance (GSA) Connector for File System 3.0 uses a Lister/Retriever model to feed documents to the GSA. Rather than pushing a Content feed to the GSA, the Lister pushes a Metadata-and-URL feed, where the URL (referred to as the Content URL) points back to the connector's document content Retriever.

The document content is then fetched by the GSA using the Content URL.

  • Since the document content is no longer contained within the feed itself, the feeds are much smaller.
  • The responsibility for document change detection moves from the connector to the search appliance, which uses HTTP “If-Modified-Since” request header to conditionally retrieve changed content. This change simplifies the connector implementation considerably, removing its dependence on the “Diffing Connector” infrastructure.
Note: As a result of the move away from the Diffing Connector infrastructure, the "queueSize" Advanced Configuration option has been deprecated, and will be ignored if set.

Troubleshooting the Google Search Appliance Connector for File Systems

If you have a problem that requires you to file a ticket with Google Cloud Support, please be prepared to provide Support with the following information:

  • Verbose connector logs. See Logging for information on changing the default logging level. If you are reporting a problem to Support, it is ideal if you can reproduce the problem with the logging level set to ALL. However, log files with entries made when the problem occurred are also helpful.
  • Connector configuration files.
  • Feed record and metadata log file. See Logging Feed Record and Metadata Information to a Text File for information on generating this log file.

Logging

Logging is a useful technique for recording information about how your installation is operating. You can use the information logged for troubleshooting the operations of the connector, the Google Search

When using Connector Manager 3.0, the logging level can be adjusted via the Admin Console. Use the Connector Log Level settings. However this change affects only the currently running process and will be reverted back to default upon restarting the connector manager.

The output from the FileHandler appears in the connectors_root_dir/connector_name/Tomcat/logs directory. The output appears in the google-connectors.sequence.log file, where sequence is a series of numbers starting with 0 and incremented by 1 on each occurrence (0, 1, 2, 3...n). The first three log file names would be google-connectors.0.log, google-connectors.1.log, and google-connectors.2.log.


Error Messages

This section describes some commonly encountered error messages and potential solutions.

Search Appliance Unable to Connect to the Connector Manager

If the Apache Tomcat instance where the Connector Manager is installed is not started or if the location you type in is incorrect or invalid, a message is displayed on the Connector Manager Administration page of the Admin Console saying “The appliance could not connect to the connector manager as specified in the location. Make sure that the URL is correct, or try again later.”

HTTP 404 Error When Registering a Connector Manager

When you are registering a new connector manager, you might see the following error message:

The HTTP response failed with the following code: 404. No external connector managers registered.

This means that the CATALINA_HOME environment variable is not set correctly on the Tomcat host. Examine the Tomcat startup script or .bashrc and ensure that CATALINA_HOME points to the correct Tomcat installation.

Error Message When Trying to Add a Connector to an Unavailable Connector Manager

When a connector manager is unavailable, the Admin Console displays a circular red indicator next to the connector manager name. If you try to add a connector to an unavailable connector manager, you see the following error message:

The appliance encountered an error while trying to make the following servlet call: getConnectorList

The connector manager might be unavailable for one of the following reasons:

  • Tomcat is not running on the registered host and port.
  • The connector manager host is unreachable.
  • The Tomcat Remote Address Filter is rejecting access.

Check each condition and correct any problems.


Uninstalling Connectors and Connector Managers


Deleting a Connector Instance from the Admin Console

You delete a connector instance only on the Admin Console of the Google Search Appliance. When you delete the instance, you delete the configuration information for the instance. The connector manager no longer creates and runs the instance.

Each connector instance is listed on the Admin Console in the Connector Administration > Connectors section. The indicator light is either green or red. Green indicates the existence of the connector instance.

To delete a connector instance:

  1. Log in to the Admin Console as an administrator.
  2. Click Connector Administration > Connectors.
  3. Click the Edit link for the correct connector.
  4. Click the Delete link on the line for the correct connector instance.
  5. Click OK.

Deleting a Connector Manager

To delete a connector manager, you must first unregister the connector manager from the Admin Console, then uninstall the connector manager on the Tomcat host.

Before you unregister a connector manager, you must delete all connector instances associate with that connector manager. If you have a large number of connector instances, you can first stop the Tomcat instance where the connector manager is running, then unregister the connector manager.

It is also possible to uninstall the connector manager on the Tomcat host, then unregister the connector manager on the Admin Console.

Unregistering a Connector Manager from the Admin Console

To unregister a connector manager from the Admin Console:

  1. Log in to the Admin Console as an administrator.
  2. Click Connector Administration > Connector Managers.
  3. Locate the connector manager you want to delete.
  4. Click the Unregister link on the line for the correct connector manager.
  5. Click OK.
Uninstalling a Connector Manager

To uninstall a connector manager from the Tomcat host, do one of the following:

  • On Windows, click Start > All Programs > Google Search Appliance Connector version_number > Uninstall.
  • On Linux, click the appropriate shortcut.

To manually delete a connector manager on the Apache Tomcat host:

  1. Log in to the Apache Tomcat host as the installation owner (the user who installed Tomcat).
  2. Shut down Tomcat.
  3. Navigate to the $CATALINA_HOME/webapps directory.
  4. Delete the connector-manager.war file.
  5. Delete the $CATALINA_HOME/webapps/connector-manager directory.
  6. Restart Tomcat.
Was this helpful?
How can we improve it?