we create and execute our deployer projects automatically (using “projectautomator.bat” and “Deploy.bat”).
The project automator can use password handles instead of passwords.
But we can’t find out how to use password handles in Deploy.bat (this would be the password the program uses to establish the connection to the deploy server).
Our goal is to avoid using the passwords (encrypted or clear text); we’d like to specify only handles.
Is it possible to use Deploy.bat with password handle? I couldn’t find an appropriate Option in webMethods Deployer User’s Guide.
I know that it’s possible in the project automator. But in the deployer, I think, it’s not possible. It’s weird that two such closely related programs use different ways to specify the password.
I agree with you, that its very weird of not having the support of pwd handles in Deployer.bat.
Coming to your question -
ProjectAutomator will encrypt the password which is there in the pwd tag (for the first time). Copy this encrypted password
You create a configuration file under /packages/WmDeployer/bin/config.cnf
Sample config file (D:\SoftwareAG\IntegrationServer\instances\WM_IS_Dev\packages\WmDeployer\bin\config.cnf) - host=enterpriseESB.com
port=5555
user=Deployer
pwd={AES}345zUapDRbe5L8GqZtVQfA== (This password is the one which you copied in above step)
sample target from Build.xml for deploying the project (which uses the above config file) -
the password is encrypted, yes, but it can be easily decrypted. Our goal is to not have a password in any easily accessible file, neither encrypted nor in clear text.
Store your passwords in a password store that you trust
In your automated script, retrieve the password from the store immediately before calling deploy.bat
Do one of these two things:
(a) Create the deployer config file dynamically using the password you retrieved from the store
(b) Pass the password directly to deploy.bat via the -pwd argument
If you choose 3a above, be sure to delete the temporary config file after you call deploy.bat. If you choose 3b, make sure the deploy.bat command (and the arguments) are not being redirected to standard output or to any log file.
The password store could be the IS outbound store or really any other trustworthy store of your choosing.
Store your passwords in a password store that you trust
In your automated script, retrieve the password from the store immediately before calling deploy.bat
Do one of these two things:
(a) Create the deployer config file dynamically using the password you retrieved from the store
(b) Pass the password directly to deploy.bat via the -pwd argument
If you choose 3a above, be sure to delete the temporary config file after you call deploy.bat. If you choose 3b, make sure the deploy.bat command (and the arguments) are not being redirected to standard output or to any log file.
The password store could be the IS outbound store or really any other trustworthy store of your choosing.
thank you for your ideas! We’ve eventually implemented something very similar to 3.b. We use the password store of the deployer IS. It works well for us.
The problem with “make sure the deploy.bat command (and the arguments) are not being redirected to standard output or to any log file” is that you can never know for sure who and how calls the script and how debugging and log redirection is configured.
But IMO we have now the best the product allows for.