Start Deploy
This topic provides instructions for starting the Deploy server.
To start the Deploy server, open a command prompt or terminal, go to the XL_DEPLOY_SERVER_HOME/bin directory, and execute the appropriate command:
| Operating system | Command |
|---|---|
| Microsoft Windows | run.cmd |
| Unix-based systems | run.sh |
Start Deploy in the background
To run the Deploy server as a background process:
- On Unix, use
nohup bin/run.sh &or run Deploy as a service - On Windows, run Deploy as a service
If you have installed Deploy as a service, you must ensure that the Deploy server is configured so that it can start without user interaction. For example, the server should not require a password for the encryption key that protects passwords in the repository. Alternatively, you can store the password in the XL_DEPLOY_SERVER_HOME/conf/deployit.conf file as follows: repository.keystore.password=MY_PASSWORD
Deploy will encrypt the password when you start the server.
Server options
Start the server with the -help flag to see the options it supports. They are:
| Option | Description |
|---|---|
-force-upgrades | Forces the execution of upgrades at Deploy startup. |
-recovery | Attempts to recover a corrupted repository. |
-repository-keystore-password VAL | Specifies the password that Deploy should use to access the repository keystore. Alternatively, you can specify the password in the deployit.conf file with the repository.keystore.password key. If you do not specify the password and the keystore requires one, Deploy will prompt you for it. |
-reinitialize | Reinitialize the repository. This option is only available for use with the -setup option, and it is only supported when Deploy is using a filesystem repository. It cannot be used when you have configured Deploy to run against a database. |
-setup | Runs the Deploy setup wizard. |
-setup-defaults VAL | Specifies a file that contains default values for configuration properties in the setup wizard. |
-release-db-locks | During upgrade, the Deploy database schema may undergo changes. Additionally, if Deploy is abruptly stopped, it may result in a database lock and this lock can prevent Deploy from starting again. You can use the -release-db-locks option to remove the lock and attempt to apply pending changes. Using this option will not corrupt or harm the database in any way. This option should only be used if you see the liquibase.exception.LockException: Could not acquire change log lock error while starting Deploy. Note: Before using this option, ensure that no other Deploy instance in the cluster is being upgraded at the same time. |
Any options you want to give the Deploy server when it starts can be specified in the XL_DEPLOY_SERVER_OPTS environment variable.
For information about the -setup-defaults option, refer to Install Deploy.
SecurityManager configuration
The Deployfile functionality allows users to execute scripts on the Deploy server. The execution environment for these scripts is sandboxed by the SecurityManager of the JVM. This is configured in the wrapper configuration file with these lines:
wrapper.java.additional.4=-Djava.security.manager=java.lang.SecurityManager
wrapper.java.additional.5=-Djava.security.policy=conf/xl-deploy.policy
When these lines are removed or commented, the XLD server will start faster, but the sandbox will not be secured and will allow commands such as the one below to execute through the CLI:
user > repository.applyDeployfile("println(new File('/etc/passwd').text)")
This command would print the content of the /etc/passwd file on the console in the Deploy server.
With the sandbox properly configured, executing this command would result in an exception:
com.xebialabs.deployit.deployfile.execute.DeployfileExecutionException: Error while executing script on line 1.
...
Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/etc/passwd" "read")
It is strongly recommended to have the SecurityManager configuration enabled on any installation that is accessible by multiple users. Only for demonstration or temporary purposes should it be considered to comment/disable it in favor of faster startup times.
AspectJWeaver for JMX monitoring
When the JMX monitoring is switched on (xl.jmx.enabled = true), parts of the task engine can be instrumented to provide more detailed information. To enable this, the following setting must be added/uncommented in the wrapper configuration file:
wrapper.java.additional.6=-javaagent:lib/aspectjweaver-1.8.10.jar
This will slow down the startup of the Deploy server considerably. If do not add this line, the following warning will show up in the log:
ERROR kamon.ModuleLoaderExtension -
___ _ ___ _ _ ___ ___ _ _
/ _ \ | | |_ | | | | | | \/ |(_) (_)
/ /_\ \ ___ _ __ ___ ___ | |_ | | | | | | ___ __ _ __ __ ___ _ __ | . . | _ ___ ___ _ _ __ __ _
| _ |/ __|| '_ \ / _ \ / __|| __| | | | |/\| | / _ \ / _` |\ \ / // _ \| '__| | |\/| || |/ __|/ __|| || '_ \ / _` |
| | | |\__ \| |_) || __/| (__ | |_ /\__/ / \ /\ /| __/| (_| | \ V /| __/| | | | | || |\__ \\__ \| || | | || (_| |
\_| |_/|___/| .__/ \___| \___| \__|\____/ \/ \/ \___| \__,_| \_/ \___||_| \_| |_/|_||___/|___/|_||_| |_| \__, |
| | __/ |
|_| |___/
It seems like your application was not started with the -javaagent:/path-to-aspectj-weaver.jar option but Kamon detected
the following modules which require AspectJ to work properly:
kamon-akka, kamon-scala
If you need help on setting up the aspectj weaver go to http://kamon.io/introduction/get-started/ for more info. On the
other hand, if you are sure that you do not need or do not want to use the weaver then you can disable this error message
by changing the kamon.show-aspectj-missing-warning setting in your configuration file.
The task engine metrics will not be available, but other metrics will be accessible through JMX.