GS DATADIR Migration

[tdipisa]

In order to allow the client to update all the GeoServer configurations connected to last developments about MS locales (see #89), we need to update the data directory in test environment by aligning it to the one in production: the data directory of the production GeoServer need to be copied from PROD to TEST (geoserver02). The client will provide all needed configuration in GeoServer TEST and finally the production environment will be updated with the new data directory of TEST.

The only blocker to this activity is that all coverages are located in the PROD data directory, therefore they should be moved outside in a different location (the preferred one is a new storage that can be mounted on both machines, PROD and TEST). The client will take care of:

• Providing a new disk and mount it PROD and TEST machines
• Copy all relevant data files (like coverages) there, initially this new data location will be used only for the new configuration in TEST and the data dir in PROD is untouched.

At the end of the update process in TEST:

• New data added in the meantime only in PROD will be added in TEST too and the new data storage updated accordingly if needed
• The data directory in PROD will be initially moved in a different location of the file system to be restored if need
• The new data directory in TEST copied in PROD and prod restarted.

Once TEST is updated with the PROD data directory the activities to do are:

• Reconfigure all the needed Stores to point to the new data storage location
• Update all SLD styles by following the GeoSolutions guidelines, that means replicate what has been provided for the layer Ambiente:Quartieri:
  • Update of the main SLD style to use the ENV variable
  • Removal of the other SLD styles no longer needed (_it, _de)
  • Configuration of the ENV parameter filter for all available tile layers
  • Configuration of all existing MS maps to use the ENV locale for GetMap requests (catalog + layer settings)

After this work the following actions in production are suggested (the client will take care of this):

• Regular backup of the new data storage
• Regular backup of the GeoServer data directory

[randomorder]

A few remarks to allow flawless datadir migration between environments:

• if the client is using different DBMS / DBs between DEV and PROD we may have to externalize the stores configurations
• if the proxy base URL is set in the datadir we'll have to externalize it using env vars
• if the auditing configuration differs between environments then it must be externalized / configured using environment variables

Are they using the LDAP integration? we may haev to do something as well for that IF the configuration is different between the two environments

[tdipisa]

Below is a more detailed description of needd actions to perform by the Comune di Bolzano team after the GS data dir update in test environment.

Once TEST is updated with the PROD data directory the activities to do are:

• Reconfigure all the needed Data Stores (both raster and vector) in GeoServer to point to the new data storage location (/opt/coverages, the same is used also for vectorial files)

• Update all SLD styles of vector layers by following the GeoSolutions guidelines, that means replicate what has been provided for the layer Ambiente:Quartieri:

1. Update of the main SLD style to use the ENV variable with reference on the quartieri SLD the relevant parts to take into account are the following.

The Title tag used in legends

<sld:Title>
     <Localized lang="de">Zentrum-Bozner Boden-Rentsch</Localized>
     <Localized lang="it">CENTRO-PIANI-RENCIO</Localized>
</sld:Title>

The Label tag of text symbolizers used for labels in tiles (the Recode function is used to get the language code from the ENV variable present in getMaps requests)

<ogc:Function name="Recode">
    <ogc:Function name="env">
          <!-- This is the default value -->
      <ogc:Literal>mapstore_language</ogc:Literal>
      <ogc:Literal>it</ogc:Literal>
    </ogc:Function>
    <ogc:Literal>it</ogc:Literal>
    <ogc:PropertyName>DESCRIZ</ogc:PropertyName>
    <ogc:Literal>de</ogc:Literal>
    <ogc:PropertyName>DESCR_TD</ogc:PropertyName>
</ogc:Function>

2. Removal of the other SLD styles no longer needed (_it, _de) with reference on the quartieri SLD, the styles to remove are quartiery_it and quartieri_de

3. Configuration of the ENV parameter filter for all available tile layers (this is needed to generate cached tiles in GWC according to the language specified in the new query parameter for GetMap requests _ENV=mapstorelanguage:it/de).

For each Tile Layer the parameter filter must be properly set, below is the example of the Ambiente:quartieri layer in test environment (Tile Caching section):

4. Configuration of all existing MS maps to use the ENV locale for GetMap requests (catalog + layer settings). Existing maps in MapStore must be configured to use the new locale query parameter for layers already present in the map itself or new layers added from the catalog tool.

As soon as the Abilita stili di livello localizzati property is checked inside the Catalog source advanced settings, the locale query parameter will be automatically used for all layers added from that source

For existing layers already published in the map, it is possible to enable the use the locale query parameter by opening the layer settings

[randomorder]

I updated the Test geoserver datadir aligning it with the one from PROD with a few adjustments. I documented the procedure in the GDoc for geoserv02