Relocating CodeStation

You can move the CodeStation artifacts to a different location on the server.

About this task

By default, the server's log files and CodeStation artifacts are stored in the application data directory. You specified this directory when you installed the server. In the case of high-availability clusters, this directory is in a shared location where each server in the cluster can access it.

Ideally, this data is stored on robust network storage that is regularly synchronized with an off-site disaster recovery facility. In addition, the HCL DevOps Deploy (Deploy) server requires a fast network connection to this storage.

Tip: The following formula shows a good rule-of-thumb for determining CodeStation storage requirements: average artifact size * number of versions that are imported per day * average number of days before cleanup

Procedure

Follow these steps to move the location of the CodeStation artifacts:

Stop the server.
See Starting and stopping the server.
Move the CodeStation data to a new location.
Which folders you move depend on whether the server uses an application data folder or not:
- Check the installed.properties file on the server. If the server.appdata.dir property in this file has a value of two periods, (..) the server does not use an application data folder. If the property has a value other than two periods, the server uses an application data folder.
When you know whether the server has an application data folder or not, you can move the correct files to a new location.
- If the server uses an application data folder, complete these steps:
  1. Move the application data folder to a new location. The default application data folder is /opt/devops-deploy/server/appdata on Linux™ and C:\Program Files\devops-deploy\server\appdata on Windows™.
  2. On the server, open the devops-deploy/conf/server/installed.properties file and update the following properties to reflect the new location of the application data (appdata) folder:
    - server.appdata.dir — The path to the appdata folder.
    - encryption.keystore — The path to the encryption keystore file.
    - server.keystore — The path to the server keystore file.
    - derby.system.home (only if you use the Derby database) — The path to the Derby database home.
    For example, specify the properties as follows:
```
server.appdata.dir=../appdata
encryption.keystore=../appdata/conf/encryption.keystore
server.keystore=../appdata/conf/server.keystore
derby.system.home=../appdata/var/db
```
    Note:
    - By default, the installed.properties file uses relative paths (for example, ../appdata). If you relocate the application data folder to a non-standard location such as a network-attached storage (NAS) mount, use absolute paths instead of relative paths to ensure that the Deploy server can reliably resolve the file locations.
    - The operating system user account that runs the Deploy server process must have full read and write access to the new appdata directory and all of its contents, including the conf and var subdirectories. On Linux, you can verify permissions by running: ls -la /data/devops-deploy/appdata. You must ensure that the ownership and permissions match the user that runs the Deploy server service.
  If the new application data folder is on a remote system, you might have to set the server.appdata.dir property to a remotely mounted folder or other network storage.
- If the server does not use an application data folder, complete these steps:
  1. Move the following individual folders to new locations:
    - install_folder/var/plugins
    - install_folder/var/repository
    - install_folder/var/sa
    - install_folder/logs
    - install_folder/conf/server/notification-templates
    - install_folder/conf/encryption.keystore
    - install_folder/conf/server.keystore
    - install_folder/conf/collectors
    - install_folder/patches
    - install_folder/conf/server/log4j.properties
  2. Create links from the previous folder locations to the new folder locations so that the server can continue to access the folders. For example, on Linux™ systems, you can use symbolic links, also known as symlinks.
Start the server.