Versions Compared

Old Version 28

changes.mady.by.user Michael Fleuchaus

Saved on

compared with

New Version Current

changes.mady.by.user Serviva Service Desk

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

For deployment of new empty DMS or restoring from backup, check here.

For importing an existing document store into a new empty DMS, check here.

Note: Following the setup of the DMS using the Auto-deploy method, to finish the email setup, you should modify the environment specific settings in the settings.xml file in the nuxeo repository. Please check here for further information.

The following describes the overall functionality/use.

...

i)      Deploy script: This contains the script logic.

httpshttp://stash172.20.practiceinsight.io/stash32.20:7990/projects/DMSCLIENT/repos/deploy_script/browse

ii)     Default template: This contains a template for the client-specific configuration repository.

httpshttp://stash172.20.practiceinsight.io/stash32.20:7990/projects/DMSCLIENT/repos/default_config/browse

iii)    Client repository: This will contain the client specific repo.

httpshttp://stash172.20.practiceinsight32.io20:7990/stash/projects/DMSCLIENT/repos/<clientname>/browse

Script updates

If you downloaded the base OVA after 2017-06-01, you can run a scripted update command on all three scripts by issuing "./update_scripts.sh" from the home directory of the root user. If you downloaded your base OVA before that, your scripts need to be updated manually by cd'ing into their respective directory and running the "git pull" command.

Basic method of use:

  1. Fork PI forks Default template to client specific repository with <clientname> upon request;
  2. Edit configuration files in client specific git repository as required for specific client’s DMS environment. Most of the times, only changes to containers.conf, dms.conf, and, if applicable, postfix-config.sh will need to be made (see below for some guidance on the DMS heap configuration in dms.conf). Edits to the remaining files (e.g. commands.conf) will be rare and only required in special situations, such as, for example, if proxy setups need to be catered for. They should only be made if you are sure you understand what you are doing. Make sure changes are pushed back to repository;
    Please make sure to change the standard NUXEO_PASSWORD in the dms.conf.
  3. Copy any fonts you intend using to /storage/nuxeo/fonts/ (unless you are using a different storage location; if so, adapt accordingly);
  4. Create folder ~/deploy/config/ to store configuration files and clone client specific repository into this folder;
  5. Create folder ~/deploy/deploy_script/ to store deploy script logic files and clone client specific repository into this folder;
  6. Create an empty nuxeo repository, restore from a previous DMS version (using the restore scripts - check here for details);

  7. Copy any fonts you intend using to the storage location (default is /storage/nuxeo/fonts/);

  8. cd into  ~/deploy/deploy_script/ folder and run "./deploy.sh" with necessary options.

...

  1. cd into ~/deploy/config/ and edit configuration file containers.conf to define the version that should be deployed. Make sure changes are pushed back to repository;
  2. cd into  ~~/deploy/deploy_script/ folder and run "./deploy.sh" with necessary options.

...

  • Restarting of elastic or postgres containers without restaring nuxeo container will break DMS functionality until nuxeo container restart.
  • The deploy.sh script will check if modifications have been made to the files in ~/deploy/config/ that have not been committed/pushed to the client specific git repository (ie. if there is discrepancy between the origin of the client specific git repository and the local configuration files). If such is the case, deploy.sh will not execute but output a corresponding warning and quit. It is important to commit local changes to the repository. After that, run "./deploy.sh" again.
  • For correction function of the DMS, you must set the LANGUAGE and COUNTRY variables in the dms.conf before deploying the DMS (or redeploy after setting it) to the correct values matching your location. Please check: http://www.oracle.com/technetwork/java/javase/java8locales-2095355.html and use the LANGUAGE (ISO 639) tag for the language and the COUNTRY (ISO 3166) tag for the country. 

   Example: LANGUAGE="en", COUNTRY="GB"

DMS heap settings based on installation environment:

The following heap settings to be set in dms.conf present some guidance based on user count. Note that other parameters such as status of the project (eg. document background analysis phase or only production phase), etc. play into these values which may thus be subject to change.
It's usually recommended to set the same value to the XMS and XMX part, especially for elasticsearch, as the heap extension is a costly operation. Unequal values can lead to experiences of short freezes. The XMS value will be ignored in newer DMS versions.

0-5 users

5-20 users

20-40 users

40-80 users

NX_XMS="1024M"

NX_XMS="4096M"

NX_XMS="8192M"

NX_XMS="12288M"

NX_XMX="8192M"

NX_XMX="16384M"

NX_XMX="32768M"

NX_XMX="40960M"

CB_XMS="512M"

CB_XMS="512M"

CB_XMS="1024M"

CB_XMS="4096M"

CB_XMX="1024M"

CB_XMX=“2048M”

CB_XMX=“4096M”

CB_XMX="10240M"

ES_XMS=“256M"

ES_XMS=“256M"

ES_XMS=“512M"

ES_XMS="512M"

ES_XMX=“512M"

ES_XMX=“1024M"

ES_XMX=“2048M"

ES_XMX=“4096M"

Deploying the DMS using https security

Starting version 1.9.8.2.4-2, your DMS can be deployed to make use of https security in all client/server communication. This requires a certain level of experience with basic system administration to obtain certificates and deploy them in your DMS VM. A step-by-step description of how to activate https security in your DMS environment is outlined here: Deploying the DMS in https mode