Extending Collection Virtual Host Configurations

1. Introduction

Globus Connect Server utilizes Apache HTTP virtual host configurations to provide the HTTPS interface for collections. While GCS manages the default behavior of these interfaces, administrators may need to tailor the configuration to meet specific site requirements, such as adjusting security headers, upload limits, or concurrency settings. This document describes how to extend and override these configurations at various levels of the GCS hierarchy.

Important
Care must be taken to ensure that custom configurations do not negatively impact existing collection HTTP operations. Malformed configurations can prevent the Apache service from starting or disrupt data access for users. Always validate syntax before applying changes in a production environment.

2. Supported Apache Configuration Directives

Collection HTTP virtual host configurations are name-based virtual hosts, so when extending configurations, only use directives suitable for that context.

3. Configuration File Locations and Targets

Admins may place Apache HTTP configuration fragments in the following locations to target specific GCS collections. All directives found in these files will be injected into the context of the target collection’s VirtualHost configuration.

Node-wide Targets

A file at /etc/globus/httpd/gcs.conf or any files located at /etc/globus/httpd/gcs/*.conf will override the behavior of all collections on the node.

Storage Gateway Targets

A file at /etc/globus/httpd/<storage_gateway_id>.conf or any files located at /etc/globus/httpd/<storage_gateway_id>/*.conf will override the behavior of all collections associated with that specific storage gateway.

Collection Targets

A file at /etc/globus/httpd/<collection_id>.conf or any files located at /etc/globus/httpd/<collection_id>/*.conf will override the behavior of that specific collection. If the target is a mapped collection, all guest collections parented by that mapped collection will inherit these modifications as well.

Note
To apply these configurations, you must identify the unique identifiers (UUIDs) for your targets. You can find the Storage Gateway ID, Mapped Collection ID, or Guest Collection ID by using the globus-connect-server collection show <collection_id> command and identifying the necessary ID field in the output.

Admins do not need to create all directories or files listed above; only create the paths necessary to achieve the desired configuration for your target(s).

Note
It is the administrator’s responsibility to place these vhost configurations on all nodes in the endpoint. GCS does not manage, synchronize, or replicate these manual configuration files between nodes in a multi-node deployment.

4. Precedence and Merging Logic

If multiple configuration files pertain to the same collection, they are processed in a specific order. Directives in later configuration files override the same directives in earlier files. The order of precedence is as follows:

  1. /etc/globus/httpd/gcs.conf

  2. /etc/globus/httpd/gcs/*.conf (loaded alphabetically)

  3. /etc/globus/httpd/<storage_gateway_id>.conf

  4. /etc/globus/httpd/<storage_gateway_id>/*.conf (loaded alphabetically)

  5. If a guest collection: /etc/globus/httpd/<mapped_collection_id>.conf

  6. If a guest collection: /etc/globus/httpd/<mapped_collection_id>/*.conf (loaded alphabetically)

  7. /etc/globus/httpd/<collection_id>.conf

  8. /etc/globus/httpd/<collection_id>/*.conf (loaded alphabetically)

5. Restart Apache HTTP Service for Changes to Take Effect

After placing or modifying any of the configuration files, you must restart the Apache HTTP service for the changes to take effect. This ensures that the new configurations are loaded and applied to the relevant collection virtual hosts.

Ubuntu, Debian, SUSE
$ sudo systemctl restart apache2.service
Fedora, CentOS, RedHat
$ sudo systemctl restart httpd.service

6. Verifying Configuration Changes

After applying changes to the Apache HTTP configuration, it is important to verify that the changes have been applied correctly and are functioning as intended. This can be done through a combination of checking the Apache configuration syntax, reviewing Apache logs for any errors, and performing test operations against the affected collections. The validation steps listed here are to verify that impacted GCS collection virtual hosts are correctly providing their intended functionality.

Using the Globus Webapp, perform the following operations against the collection(s) impacted by the configuration changes:

  1. Perform a directory listing of the collection and verify that it completes successfully and returns the expected results.

  2. Use the Webapp’s "Upload" feature to upload a file to the collection and verify that it completes successfully.

  3. Use the Webapp’s "Download" feature to download a file from the collection and verify that it completes successfully.