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 email@example.com. If your site is hosted by NetX and you would like to request a *permanent* test site, please contact your Account Manager.
The instructions below are intended as a general guide and reflect the practices we use here at NetX. Your environment may vary, so some of the steps outlined below may need to be adjusted according to your needs and the technologies you are employing to host NetX. We strongly recommend that test site deployment be performed by experienced system administrators, DBAs, etc. Test sites are not covered under our Support Policy, so customers will need to engage our professional services team if further assistance is required.
- 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
- 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.
Copy the repository data from the storage location on production (this can be found in System > Storage ). Double click on the default location to see its path. The full paths to asset files and proxies are stored in the database. Because of this, if the storage is on a network share, you will want to use identical mount points on the production and test servers so that the paths referenced in the cloned database still work.
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.
- Copy the "appFiles" data to the new location (thumbnails, zooms, pdf page views, constituents, versions). Again, if these are located on a network share, you will want to ensure that the files are mounted at the same location on the production and test server. This location is determined by the system property image.fileDirectory which can be found in System > Properties.
Take a full backup of the database from the production database server. For example, for mysql, one would use something like mysqldump to create a backup file.
Create a new database for the test environment. Load the dumped data into the new test database instance.
Install and configure NetX on a test server
- 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.
- 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.
- Shut down the NetX service on the test server.
- Copy the appropriate JDBC jar file into '.../webapps/ROOT/WEB-INF/lib' inside the NetX directory on test server. This file should be available to copy from on the production instance. See Supported JDBC Drivers for more information.
- 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.
- Untar the archive created above in the same location on the test server. Overwrite any files if prompted.
- Copy your test license into '.../netx/license' inside the NetX directory on test server. If you need a test license, please contact your Account Manager or email firstname.lastname@example.org.
- 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.
- If there are any 3rd-party integrations, they should most likely be turned off as to not interfere with what is running in production. Examples include Amazon S3 or Glacier integrations, etc. If there is a question about this, please contact NetX support.
- 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.
- Start the NetX service.
- Go to http://localhost/ from the test 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.
- 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.