Skip to content

Latest commit

 

History

History
984 lines (756 loc) · 36.7 KB

Hyrax_OLFS_Configuration.adoc

File metadata and controls

984 lines (756 loc) · 36.7 KB
Raw

OLFS Configuration

The OLFS is the outward facing component of the Hyrax server. This section provides OLFS configuration instructions.

Note
 The OLFS web application relies on one or more instances of the BES to provide it with data access and basic catalog metadata.

The OLFS web application stores its configuration state in a number of files. You can change the server’s default configuration by modifying the content of one or more of these files and then restarting Tomcat or the web application. These configuration files include the following:

  • olfs.xml: Contains the primary OLFS configuration, such as BES associations, directory view instructions, gateway service location, and static THREDDS catalog behavior. Located at /etc/olfs/olfs.xml. For more information about olfs.xml, please see the olfs.xml configuration section.

  • catalog.xml: Master(top-level) THREDDS catalog content for static THREDDS catalogs. Located at /etc/olfs/catalog.xml.

  • viewers.xml: Contains the localized viewers configuration. Located at /etc/olfs/viewers.xml.

Generally, you can meet your configuration needs by making changes to olfs.xml and catalog.xml. For more information about where these files might be located, please see the following section, OLFS Configuration Files.

OLFS Configuration Files

If the default configuration of the OLFS works for your intended use, there is no need to create a persistent localized configuration; however, if you need to change the configuration, we strongly recommend that you enable a persistent local configuration. This way, updating the web application won’t override your custom configuration.

The OLFS locates its configuration file by looking at the value of the OLFS_CONFIG_DIR user environment variable:

  • If the variable is set and its value is the pathname of an existing directory that is both readable and writable by Tomcat, the OLFS will use it.

  • If the directory /etc/olfs exists and is readable and writable by Tomcat, the OLFS will use it.

  • If the directory /usr/share/olfs exists and is readable and writable by Tomcat, then the OLFS will use it. (This was added for Hyrax 1.14.1.)

If none of the above directories exist or the variable has not been set, the OLFS uses the default configuration bundled in the web application web archive file (opendap.war). In this way, the OLFS can start without a persistent local configuration.

Create a Persistent Local Configuration

You can easily enable a persistent local configuration for the OLFS by creating an empty directory and identifying it with the OLFS_CONFIG_DIR environment variable:

export OLFS_CONFIG_DIR="/home/tomcat/hyrax"

Alternately, you can create /etc/olfs or /usr/share/olfs.

Once you have created the directory (and, in the first case, set the environment variable), restart Tomcat. Restarting Tomcat prompts the OLFS move a copy of its default configuration into the empty directory and then use it. You can then edit the local copy.

Warning
 The directory that you create must be both readable and writable by the user who is running Tomcat.

olfs.xml Configuration File

The olfs.xml file contains the core configuration of the Hyrax front-end service. The following subsections detailed its contents.

At the document’s root is the <OLFSConfig> element. It contains several elements that supply the configuration for the OLFS. The following is an example OLFS Configuration file:

<BESManager> Element (required)

The BESManager information is used whenever the software needs to access the BES’s services. This configuration is key to the function of Hyrax, for in it is defined each BES instance that is connected to a given Hyrax installation. The following examples will show a single BES example. For more information on configuring Hyrax to use multiple BESs look here.

Each BES is identified using a seperate <BES> child element inside of the <BESManager> element:

<BESManager>
    <BES>
        <prefix>/</prefix>
        <host>localhost</host>
        <port>10022</port>
        <timeOut>300</timeOut>
        <maxResponseSize>0</maxResponseSize>
        <ClientPool maximum="10" maxCmds="2000" />
        <adminPort>11002</adminPort>
    </BES>
    <NodeCache maxEntries="20000" refreshInterval="600"/>
    <SiteMapCache cacheFile="/tmp/SiteMap.cache" refreshInterval="600" />
</BESManager>

<BES> Child Elements

The <BES> child elements provide the OLFS with connection and control information for a BES. There are three required child elements within a <BES> element and four optional child elements:

  • <prefix> element (required): This element contains the URL prefix that the OLFS will associate with this BES. It also maps this BES to the URI space that the OLFS services.

    The prefix is a token that is placed between the host:port/context/ part of the Hyrax URL and the catalog root. The catalog root is used to designate a particular BES instance in the event that multiple BESs are available to a single OLFS.

    If you have maintained the default configuration of a single BES, the tag must be designated by a forward slash: <prefix>/</prefix>.

    Important
    		 There must be at least one BES element in the BESManager handler configuration whose prefix has a value of /. There may be more than one <BES>, but only this one is required.

    When using multiple BESs, each BES must have an exposed mount point as a directory (aka collection) in the URI space where it is going to appear. It is important to note that the prefix string must always begin with the slash (/) character: <prefix>/data/nc</prefix>. For more information, see Configuring With Multiple BESs.

  • <host> element (required): Contains the host name or IP address of the BES, such as <host>test.opendap.org</host>.

  • <port> element (required): Contains port number on which the BES is listening, such as <port>10022</port>.

  • <timeOut> element (optional): Contains the timeout time, in seconds, for the OLFS to wait for this BES to respond, such as <timeOut>600</timeOut>. Its default value is 300.

  • <maxResponseSize> element (optional): Contains in bytes the maximum response size allowed for this BES. Requests that produce a larger response will receive an error. Its default value of zero indicates that there is no imposed limit: <maxResponseSize>0</maxResponseSize>.

  • <ClientPool> element (optional): Configures the behavior of the pool of client connections that the OLFS maintains with this particular BES. These connections are pooled for efficiency and speed: <ClientPool maximum="200" maxCmds="2000" />.

    Notice that this element has two attributes, maximum and maxCmds:

    • The maximum attribute specifies the maximum number of concurrent BES client connections that the OLFS can make. Its default value is 200.

    • The maxCmds attribute specifies the maximum number of commands that can be issued over a particular BESClient connection. The default is 2000.

    If the <ClientPool> element is missing, the pool (maximum) size defaults to 200 and maxCmds defaults to 2000.

  • <adminPort> element (optional): Contains the port on the BES system that can be used by the Hyrax Admin Interface to control the BES, such as <adminPort>11002</adminPort>. The BES must also be configured to open and use this admin port.

<NodeCache> Child Element (optional)

The NodeCache element controls the state of the in-memory LRU cache for BES catalog/node responses. It has two attributes, refreshInterval and maxEntries.

The refreshInterval attribute specifies the time (in seconds) that any particular item remains in the cache. If the underlying system has a lot of change (model result output etc) then making this number smaller will increase the rate at which the change becomes "available" through the Hyrax service, at the expense of more cache churn and slower responses. If the underlying system is fairly stable (undergoes little change) then refreshInterval can be larger which will mean less cache churn and faster responses.

The maxEntries attribute defines the maximum number of entries to allowed in the cache. If the serviced collection is large then making this larger will definitely improve response times for catalogs etc.

Example:

<NodeCache maxEntries="20000" refreshInterval="600"/>

<SiteMapCache> Child Element (optional)

The SiteMapCache element defines the location and life span of the SiteMap response cache. A cache for the BES SiteMap response can be time consuming to produce for larger systems (~4 minutes for a system with 110k directories and 560k files) This configuration element addresses this by providing a location and refresh interval for a SiteMap cache. SiteMapCache has two attributes, cacheFile and refreshInterval.

The optional cacheFile attribute may be used to identify a particular location for the SiteMap cache file, if not provided it will be placed by default into cache directory located in the active OLFS configuration directory.

The refreshInterval attribute expresses, in seconds, the time that a SiteMap is held in the cache before the system generates a new one.

Example:

<SiteMapCache cacheFile="/tmp/SiteMap.cache" refreshInterval="600" />

<ThreddsService> Element (optional)

This configuration parameter controls the following:

  • The location of the static THREDDS catalog root in the URI space serviced by Hyrax.

  • Whether the static THREDDS catalogs are held in memory or read from disk for each request.

  • If the server will broker remote THREDDS catalogs and their data by following thredds:catalogRef links that point to THREDDS catalogs on other systems.

The following is an example configuration for the <ThreddsService> element:

<ThreddsService  prefix="thredds" useMemoryCache="true" allowRemote="false" />

Notice that <ThreddsService> has several attributes:

  • prefix attribute (optional): Sets the name of the static THREDDS catalogs' root in Hyrax. For example, if the prefix is thredds, then http://localhost:8080/opendap/thredds/ will give you the top-level static catalog, which is typically the contents of the file /etc/olfs/opendap/catalog.xml. This attribute’s default value is thredds.

  • useMemoryCache attribute (optional): This is a boolean value with a default value of true.

    • If the value of this attribute is set to true, the servlet will ingest all of the static catalog files at startup and hold their contents in memory, which is faster but more memory intensive.

    • If set to false, each request for a static THREDDS catalog will cause the server to read and parse the catalog from disk, which is slower but uses less memory.

    See this page for more information about the memory caching operations.

  • allowRemote attribute (optional): If this attribute is present and its value is set to true, then the server will "broker" remote THREDDS catalogs and the data that they serve. This means that the server, not the client, will perform the following steps:

    1. Retrieve the remote catalogs.

    2. Render them for the requesting client.

    3. Provide an interface for retrieving the remote data.

    4. Allow Hyrax to perform any subsequent processing before returning the result to the requesting client.

    This attribute has a default value of false.

<GatewayService> (optional)

Directs requests to the Gateway Service:

<GatewayService  prefix="gateway" useMemoryCache="true" />

The following are the attributes of <GatewayService>:

  • prefix attribute (optional): Sets location of the gateway service in the URI space serviced by Hyrax. For example, if the prefix is gateway, then http://localhost:8080/opendap/gateway/ should give you the Gateway Service page. This attribute’s default value is gateway.

  • useMemoryCache attribute (optional): See the previous section for more information.

<UseDAP2ResourceUrlResponse /> element (DEPRECATED)

The UseDAP2ResourceUrlResponse key has been deprecated.

Use DatasetUrlResponse and DataRequestForm to determine what kind of response Hyrax will return for the dataset URL.

This element controls the type of response that Hyrax will provide to a client’s request for the data resource URL:

<UseDAP2ResourceUrlResponse />

When this element is present, the server will respond to requests for data resource URLs by returning the DAP2 response (either an error or the underlying data object). Commenting out or removing the <UseDAP2ResourceUrlResponse /> element will cause the server to return the DAP4 DSR response when a dataset resource URL is requested.

NOTE: DAP2 responses are not clearly defined by any specification, whereas DAP4 DSR responses are well-defined by a specification.

This element has no attributes or child elements and is enabled by default.

<DatasetUrlResponse type="download|requestForm|dsr"/>

The DatasetUrlResponse configuration element is used to configure the type of response that the server will generate when a client attempts to access the Dataset URL. The type of response is controlled by the value of the type attribute. There are three supported values are: dsr, download, and requestForm.

  • download - If the configuration parameter AllowDirectDataSourceAccess is set (present) then the source data file will be returned for the dataset URL. If the configuration parameter AllowDirectDataSourceAccess is not present then a 403 forbidden will be returned for the dataset URL. (This is basically a file retrieval service, any constraint expression submitted with the dataset URL will be ignored.)

  • requestForm - The Hyrax Data Request Form Page will be returned for the dataset URL.

  • dsr - The dap4 DSR response will be returned for the dataset URL.

The default value is download:

<DatasetUrlResponse type="download"/>

<DataRequestForm type="dap2|dap4"/>

The value of the DataRequestForm element defines these server behaviors:

  • The DAP centric view of the catalog pages. This value controls if the catalog pages are of the DAP2 or DAP4 form. The "blue-bar" catalog(catalog.html) pages (catalog.html) for the preferred DAP data model contain links specifically associated with that data model. This includes the link to the Data Request Form.

  • This element also determines the type of Data request form page returned when the DatasetUrlResponse type is set to requestForm and the request is for the Dataset URL the request will be redirected to the DAP2 or DAP4 Data Request form.

Supported type values are: dap2 and dap4

The default value is dap4:

<DataRequestForm type="dap4" />

<AllowDirectDataSourceAccess/> element (optional)

The <AllowDirectDataSourceAccess/> element controls the user’s ability to directly access data sources via the Hyrax web interface:

    <!-- AllowDirectDataSourceAccess / -->

If this element is present and not commented out, a client can retrieve an entire data source (such as an HDF file) by requesting it through the HTTP URL interface.

This element has no attributes or child elements and is disabled by default. We recommend that you leave it unchanged, unless you want users to be able to circumvent the OPeNDAP request interface and have direct access to the data products stored on your server.

<ForceDataRequestFormLinkToHttps/> element (optional)

'ForceDataRequestFormLinkToHttps' - The presence of this element will cause the Data Request Form interfaces to "force" the dataset URL to HTTPS. This is useful for situations where the sever is sitting behind a connection management tool (like CloudFront) whose outward facing connections are HTTPS but Hyrax is not using HTTPS. Thus the internal URLs being received by Hyrax are on HTTP. When these URLs are exposed via the Data Request Forms they can cause some clients issues with session dropping because the protocols are not consistent.

    <ForceDataRequestFormLinkToHttps />

<AddFileoutTypeSuffixToDownloadFilename /> element (optional)

This optional element controls how the server constructs the download file name that is transmitted in the HTTP Content-Disposition header:

    <AddFileoutTypeSuffixToDownloadFilename />

For example, suppose the <AddFileoutTypeSuffixToDownloadFilename /> element is either commented out or not present. When a user requests a data response from somedatafile.hdf in netCDF-3 format, the HTTP Content-Disposition header will be set like this:

Content-Disposition: attachment; filename="somedatafile.hdf"

However, if the <AddFileoutTypeSuffixToDownloadFilename /> is present, then the resulting response will have an HTTP Content-Disposition header:

Content-Disposition: attachment; filename="somedatafile.hdf.nc"

By default the server ships with this disabled.

<BotBlocker> (optional)

This optional element can be used to block access from specific IP addresses or a range of IP addresses using regular expressions:

<BotBlocker>
    <IpAddress>128.193.64.33</IpAddress>
    <IpMatch>65\.55\.[012]?\d?\d\.[012]?\d?\d</IpMatch>
</BotBlocker>

<BotBlocker> has the following child elements:

  • <IpAddress> element: The text value of this element should be the IP address of a system that you would like to block from accessing your service. For example, <IpAddress>128.193.64.33</IPAddress> Will block the system located at 128.193.64.33 from accessing your server.

    There can be zero or more <IpAddress> child elements in the <BotBlocker> element.

  • <IpMatch> element: The text value of this element should be the regular expression that will be used to match the IP addresses of clients attempting to access Hyrax. For example, <IpMatch>65\.55\.[012]?\d?\d\.[012]?\d?\d</IpMatch> matches all IP addresses beginning with 65.55, and thus blocks access for clients whose IP addresses lie in that range.

    There can be zero or more <IpMatch> child elements in <BotBlocker element.

Developer Options

These configuration options are intended to be used by developers that are engaged in code developement for components of Hyrax. They are not meant to be enabled in any kind of production environment. They are included here for transparency and to help potential contributors to the Hyrax project.

<Timer>

The <Timer> attribute enables or disables the generation of internal timing metrics for the OLFS:

 <Timer enabled="true"/>

Timer has a single attribute, enabled, which is a boolean value. Uncommenting this value and setting it to true will output timing metrics to the log.

Warning
 Enabling the Timer will impose significant performance overhead on the server’s operation and should ony be done in an effort to understand the relative times spent in different operations--not as a mechanism for measuring the server’s objective performance.

<ingestTransformFile> child element (developer)

This child element of the ThreddsService element is a special code development option that allows a developer to specify the fully qualified path to an XSLT file that will be used to preprocess each THREDDS catalog file read from disk:

Example:

<ingestTransformFile>/fully/qualified/path/to/transfrm.xsl</ingestTransformFile>

The default version of this file, found in $CATALINA_HOME/webapps/opendap/xsl/threddsCatalogIngest.xsl, processes the thredds:datasetScan elements in each THREDDS catalog so that they contain specific content for Hyrax.

Viewers Service (viewers.xml file)

The Viewers service provides, for each dataset, an HTML page that contains links to Java WebStart applications and to WebServices, such as WMS and WCS, that can be used in conjunction with the dataset. The Viewers service is configured via the contents of the viewers.xml file, typically located at the following location: /etc/olfs/viewers.xml.

viewers.xml Configuration File

The viewers.xml contains a list of two types of elements:

  • <JwsHandler> elements

  • <WebServiceHandler> elements

The details of these are discussed elsewhere in the documentation. The following is an example configuration:

<ViewersConfig>
 
    <JwsHandler className="opendap.webstart.IdvViewerRequestHandler">
        <JnlpFileName>idv.jnlp</JnlpFileName>
    </JwsHandler>
 
    <JwsHandler className="opendap.webstart.NetCdfToolsViewerRequestHandler">
        <JnlpFileName>idv.jnlp</JnlpFileName>
    </JwsHandler>
 
    <JwsHandler className="opendap.webstart.AutoplotRequestHandler" />
 
    <WebServiceHandler className="opendap.viewers.NcWmsService" serviceId="ncWms">
        <applicationName>Web Mapping Service</applicationName>
        <NcWmsService href="/ncWMS/wms" base="/ncWMS/wms" ncWmsDynamicServiceId="lds" />
    </WebServiceHandler>
 
    <WebServiceHandler className="opendap.viewers.GodivaWebService" serviceId="godiva">
        <applicationName>Godiva WMS GUI</applicationName>
        <NcWmsService href="http://localhost:8080/ncWMS/wms" base="/ncWMS/wms" ncWmsDynamicServiceId="lds"/>
        <Godiva href="/ncWMS/godiva2.html" base="/ncWMS/godiva2.html"/>
    </WebServiceHandler>
 
</ViewersConfig>

Logging

For information about logging, see the Hyrax Logging Configuration Documentation.

Authentication and Authorization

The following subsections detail authentication and authorization.

Apache Web Server (httpd)

If your organization desires secure access and authentication layers for Hyrax, the recommended method is to use Hyrax in conjunction the Apache Web Server (httpd).

Most organizations that use secure access and authentication for their web presence are already doing so via Apache Web Server, and Hyrax can be integrated nicely with this existing infrastructure.

More about integrating Hyrax with Apache Web Server can be found at these pages:

Tomcat

Hyrax may be used with the security features implemented by Tomcat for authentication and authorization services. We recommend that you read carefully and understand the Tomcat security documentation.

For Tomcat 7.x see:

For Tomcat 8.5.x see:

We also recommend that you read chapter 12 of the Java Servlet Specification 2.4 that decribes how to configure security constraints at the web-application-level.

Tomcat security requires fairly extensive additions to the web.xml file located here: ${CATALINA_HOME}/webapps/opendap/WEB-INF/web.xml

Warning
 Altering the <servlet> definitions may render your Hyrax server inoperable.

Examples of security content for the web.xml file can be found in the persistent content directory of the Hyrax server, which by default is located here $CATALINA_HOME/webapps/opendap/WEB-INF/conf/TomcatSecurityExample.xml

Limitations

Tomcat security officially supports context-level authentication. This means that you can restrict access to the collection of servlets running in a single web application (i.e. all of the stuff that is defined in a single web.xml file). You can call out different authentication rules for different `<url-pattern>`s within the web application, but only clients that do not cache ANY security information will be able to easily access the different areas.

For example, in your web.xml file you might have the following:

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>fnoc1</web-resource-name>
            <url-pattern>/hyrax/nc/fnoc1.txt</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>fn1</role-name>
        </auth-constraint>
    </security-constraint>
 
    <security-constraint>
        <web-resource-collection>
             <web-resource-name>fnoc2</web-resource-name>
             <url-pattern>/hyrax/nc/fnoc2.txt</url-pattern>
         </web-resource-collection>
         <auth-constraint>
             <role-name>fn2</role-name>
          </auth-constraint>
    </security-constraint>
 
    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>MyApplicationRealm</realm-name>
    </login-config>

Where the security roles fn1 and fn2 (defined in the tomcat-users.xml file) have no common members.

The complete URI’s would be…​

http://localhost:8080/mycontext/hyrax/nc/fnoc1.txt
http://localhost:8080/mycontext/hyrax/nc/fnoc2.txt

This works for clients that do not cache anything; however, if you access these URLs with a typical internet browser, authenticating one URI would lock you out of the other URI until you "reset" the browser by purging all caches. This happens, because, in the exchange between Tomcat and the client, Tomcat sends the header WWW-Authenticate: Basic realm="MyApplicationRealm", and the client authenticates.

When you access the second URI, Tomcat sends the same authentication challenge with the same WWW-Authenticate header. The client, having recently authenticated to this realm-name (defined in the <login-config> element in the web.xml file - see above), resends the authentication information, and, since it is not valid for that url pattern, the request is denied.

Persistence

Be sure to back up your modified web.xml file to a location outside of the $CATALINA_HOME/webapps/opendap directory, as newly-installed versions of Hyrax will overwrite it.

You could, for example, use an XML ENTITY and an entity reference in the web.xml. This will cause a local file containing the security configuration to be included in the web.xml. For example…​

  1. Add the ENTITY

    [<!ENTITY securityConfig SYSTEM "file:/fully/qualified/path/to/your/security/config.xml">]

    to the !DOCTYPE declaration at the top of the web.xml.

  2. Add an entity reference (securityConfig, as above) to the content of the web-app element. This would cause your externally held security configuration to be included in the web.xml file.

. The following is an example ENTITY configuration:

    <?xml version="1.0" encoding="ISO-8859-1"?>

    <!DOCTYPE web-app
        PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
        "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"
        [<!ENTITY securityConfig      SYSTEM "file:/fully/qualified/path/to/your/security/config.xml">]
    >
    <web-app>

        <!--
            Loads a persistent security configuration from the content directory.
            This configuration may be empty, in which case no security constraints will be
            applied by Tomcat.
        -->
        &securityConfig;

        .
        .
        .

    </web-app>

This will not prevent you from losing your web.xml file when a new version of Hyrax is installed, but adding the ENTITY to the new web.xml file is easier than remembering an extensive security configuration.

Compressed Responses and Tomcat

Many OPeNDAP clients accept compressed responses. This can greatly increase the efficiency of the client/server interaction by diminishing the number of bytes actually transmitted over "the wire." Tomcat provides native compression support for the GZIP compression mechanism; however, it is NOT turned on by default.

The following example is based on Tomcat 7.0.76. We recommend that you carefully read the Tomcat documentation related to this topic before proceeding:

Details

To enable compression, you will need to edit the $CATALINA_HOME/conf/server.xml file. Locate the <Connector> element associated with your server. It is typically the only <Connector> element whose port attribute is set equal to 8080. You will need to add or change several of its attributes to enable compression.

With our Tomcat 7.0.76 distribution, we found this default <Connector> element definition in our server.xml file:

    <Connector
        port="8080"
        protocol="HTTP/1.1"
        connectionTimeout="20000"
        redirectPort="8443"
    />

You will need to add four attributes:

compression="force"
compressionMinSize="2048"
compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/octet-stream,application/vnd.opendap.dap4.dataset-services+xml,application/vnd.opendap.dap4.dataset-metadata+xml,application/vnd.opendap.dap4.data,application/vnd.opendap.dap4.error+xml,application/json,application/prs.coverage+json,application/rdf+xml,application/x-netcdf;ver=4,application/x-netcdf,image/tiff;application=geotiff"

The list of compressible MIME types includes all known response types for Hyrax. The compression attribute may have the following values:

  • compression="no": Nothing is compressed (default if not provided).

  • compression="yes": Only the compressible MIME types are compressed.

  • compression="force": Everything gets compressed (assuming the client accepts gzip and the response is bigger than compressionMinSize).

    Note
    		 You must set compression="force" for compression to work with the OPeNDAP data transport.

When you are finished, your <Connector> element should look like the following:

    <Connector
        port="8080"
        protocol="HTTP/1.1"
        connectionTimeout="20000"
        redirectPort="8443"
        compression="force"
        compressionMinSize="2048"
        compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/octet-stream,application/vnd.opendap.dap4.dataset-services+xml,application/vnd.opendap.dap4.dataset-metadata+xml,application/vnd.opendap.dap4.data,application/vnd.opendap.dap4.error+xml,application/json,application/prs.coverage+json,application/rdf+xml,application/x-netcdf;ver=4,application/x-netcdf,image/tiff;application=geotiff"
     />

Restart Tomcat for these changes to take effect.

You can verify the change by using curl as follows:

curl -H "Accept-Encoding: gzip" -I http://localhost:8080/opendap/data/nc/fnoc1.nc.ascii
Note
 The above URL is for Hyrax running on your local system and accessing a dataset that ships with the server.

You’ll know that compression is enabled if the response to the curl command contains:

Content-Encoding: gzip
Note
 If you are using Tomcat in conjunction with the Apache Web Server (our friend httpd) via AJP, you will need to also configure Apache to deliver compressed responses Tomcat will not compress content sent over the AJP connection.

Pitfalls with CentOS-7.x and/or SELinux

SELinux (bundled by default with CentOS-7) will create some new challenges for those not familiar with the changes it brings to the system environment. For one, Tomcat runs as a confined user. Here we’ll examine how these changes affect the OLFS.

Localizing the OLFS Configuration under SELinux

When using a yum-installed Tomcat on CentOS-7.x (or any other Linux environment that is essentially an SELinux variant), neither the /etc/olfs or the /usr/share/olfs configuration locations will work without taking extra steps. You must alter the SELinux access policies to give the Tomcat user permission to read and write to one of these directories.

The following code block will configures the /usr/share/olfs directory for reading and writing by the Tomcat user:

#!/bin/sh
# You must be the super user to do this stuff...
sudo -s

# Create the location for the local configuration
mkdir -p /usr/share/olfs

# Change the group ownership to the tomcat group.
# (SELinux will not allow you make the owner tomcat.)
chgrp tomcat /usr/share/olfs

# Make it writable by the tomcat group
sudo chmod g+w /usr/share/olfs

# Use semanage to change the context of the target
# directory and any (future) child dirs
semanage fcontext -a -t tomcat_var_lib_t "/usr/share/olfs(/.*)?"

# Use restorecon to commit/do the labeling.
restorecon -rv /usr/share/olfs

For further reading about SELinux and its permissions issues, see the following:

Tomcat Logs

In SELinux the yum-installed Tomcat does not produce a catalina.out file; rather, the output is sent to the journal and can be viewed with the following command:

journalctl -u tomcat