How to Create an On-Premise Test Environment in Linux

This guide is meant to help an on-premise system administrator through the process of setting up a test server. Each on-premise license includes a complimentary test license that renews annually. Contact your Account Manager to request your test license or email sales@netx.net. If you are a SaaS customer and would like to request a permanent test site, please contact your Account Manager.

Prerequisites

• New, separate VM/server with identical OS and specifications to run the test version of NetX
• New, separate location of appFiles and Repository
• New, separate database instance/server for test purposes.
• Must be running version 7.3 or later (some paths have changed from older versions)

Prepare and clone data

1. For best results, shut down the production NetX instance during this process. This will ensure that the database is in sync with the repository. If that is not possible, refrain from major import processes or system modifications during this time.
2. Create a new repository location for the test instance. For example, if your production repository is a network share on \\Server1\share\repository, you could create a new location in \\Server2\share\repository.
3. Copy the repository data from the production repository to the test repository. The repository path can be found in the database's location table where name is Internal repository, as well as the system property sys.repository_directory.
   
   

   Note: Some users with very large datasets may omit this step, or may decide to only copy a subset of the repository. If the application sees a database record for an asset, but cannot locate the physical asset that matches the path listed in the database, users will still see the asset record and metadata but will not be able to download, repurpose, or perform certain actions on the asset.

4. Create a new appFiles directory for the test server. For example, if your production appFiles directory is on a network share \\Server1\share\appFiles, you could create a new location in \\Server2\share\appFiles.
5. Copy the appFiles data to the new location (thumbnails, zooms, pdf page views, constituents, versions). The appFiles path can be determined by the system property storage.appFiles.directory.  This can also be determined by the legacy property image.fileDirectory which was superseded by storage.appFiles.directory.
6. Take a full backup of the database from the production database server. For example, in mysql, you can use mysqldump to create a backup file.
7. Create a new database for the test environment. Load the production data into the new test database instance.

8. Run a query on the new test database to update the paths in the location table to match the location of the repository on the test environment.

   Example: If the production server is on \\Server1\share\repository and the test data is on \\Server2\share\repository:

   SQL Server MySQL

   USE netx_test
   UPDATE location SET base_path = REPLACE(base_path,'\\Server1\share\repository','\\Server2\share\repository') WHERE base_path LIKE '%\\Server1\share\repository%'

   For NetX versions prior to 11, also update the path in the image table.

   UPDATE image SET path = REPLACE(path,'\\Server1\share\repository','\\Server2\share\repository') WHERE path LIKE '%\\Server1\share\repository%'

   mysql use netx_test;
   mysql UPDATE location SET base_path = replace(base_path, '\\\\Server1\\share\\repository', '\\\\Server2\\share\\repository');

   For NetX versions prior to 11, also update the path in the image table.

   mysql UPDATE image SET path = replace(path, '\\\\Server1\\share\\repository', '\\\\Server2\\share\\repository');

Install and configure NetX on a test server

1. 1. Make sure the prerequisite JDK version, and any external engines are installed on the test server to match what is already on the production server.
   2. Run through the NetX Installation Guide for Linux on the test server up until step 2: "Verify that you can access http://localhost ....". Do not run the NetX Configurator.
   3. Shut down the NetX service on the test server. 
   4. Copy the appropriate JDBC jar file from your production instance into .../webapps/ROOT/WEB-INF/lib inside the NetX directory on the test server. See Supported JDBC Drivers for more information.
   5. Create a tar archive of the netx directory inside the NetX directory on production and copy this to the same directory on the test server.
   6. Untar the archive created above in the same location on the test server. Overwrite any files if prompted.
   7. Copy your test license into .../netx/license inside the NetX directory on the test server. If you need a test license, please contact your Account Manager or email sales@netx.net.
   8. Navigate to netx/config inside the NetX directory. Edit exogen-config.xml (additionally, update any files with the name exogen-config*.xml) update the following properties to reflect the new test environment (see Configuring Properties):
      • sys.site_domain - this should match the new DNS hostname or IP address of the test server
      • sys.docroot_url - this should match the full http URL of the new test server
      • sys.tomcatManagerUrl - this should match "http://[ip-address of test server]/manager/"
      • image.fileDirectory - this should match the path of appFiles folder that was created for test. Example: \\Server2\share\appFiles
      • sys.repository_directory - this should match the path of the repository that was created for test. Example: \\Server2\share\repository
      • database.url - this should match the JDCB URL of the new test database.
      • database.user - this should match an account with full access to the new test database.
      • database.password - the password that corresponds to the above account
      • Additionally, search the config files for any other references to the production URL. Make sure there are no additional path references that would apply only to production.
      • Disable any 3rd-party integrations to not interfere with what is running in production. Examples include Amazon S3 or Glacier integrations, etc. If you have any questions about this, please contact NetX support.
   9. Copy the .../bin/setenv.sh shell script from the NetX directory on your production server to the test server to preserve JVM heap size. See Java Memory Heap for more details.
   10. Start the NetX service.
   11. Go to http://localhost/ from the test server to verify that the application is loading. Assets may take some time to show up. See System > Jobs to determine if the Solr Index job is still running.
   12. Once Solr on test has finished its indexing jobs, the application should be ready to use. Do one final verification of thumbnails loading, ability to download, and ability to import new files.