Docker DA - Automating the encryption of dfc.globalregistry.password
I'm using the Documentum Administrator (DA) image with Docker Compose and am following the setup instructions. It states that the dfc.properties details should be passed in as an environment variable within the YML file. This includes the dfc.globalregistry.password (which is unencrypted).
However the password needs to be encrypted for it to work. The only way I can achieve this is by manually encrypting the password using the DFC.jar and then copying the password into the dfc.properties.
Isn't there a way for the image to run this encryption upon build and then set the password in the dfc.properties accordingly?
This is frustrating if you're trying to create an automated docker-compose script for a Documentum system.
Best Answers
-
I've said this many times: Documentum cloud engineers can't tell a container from a VM (and therefore, they don't know what they are doing), and then these things happen. As you said, you can't do this without modifying the image by OT. In this case, your best approach is to build your own da image ( ) and adding there your dfc.properties with all the information.
If you want to have a properly running image, you'll need to add as well your dfc.keystore and the app.xml file with your custom dmc_wdk_preferences_owner/dmc_wdk_presets_owner encrypted passwords, something that OT forgot when creating the image.
1 -
In the stateless_compose.yml, you have a DFC_PROPERTIES environment variable where you can set all required values, e.g.
- DFC_PROPERTIES=dfc.data.dir=<DFC_DATA_DIRECTORY>::dfc.tokenstorage.dir=<DFC_TOKENSTORAGE_DIRECTORY>::dfc.tokenstorage.enable=false::dfc.docbroker.host[0]=<DFC_DOCBROKER_HOST>::dfc.docbroker.port[0]=<DFC_DOCBROKER_PORT>::dfc.globalregistry.repository=<DFC_GLOBALREGISTRY_REPOSITORY>::dfc.globalregistry.username=<DFC_GLOBALREGISTRY_USERNAME>::dfc.globalregistry.password=<DFC_GLOBALREGISTRY_PASSWORD>::dfc.session.allow_trusted_login=false::dfc.security.ssl.use_anonymous_cipher=true
About the password, it doesn't have to be encrypted in order to work (even though it is obviously recommended). I have a dev environment where I keep it in clear text and it works fine. You can encrypt it as documented if you want and paste the encrypted password in the YAML file.
About Docker Compose in general, I'm not sure how long OpenText will provide support for it (not that OT support provided any useful help on that subject for me). The future is clearly Kubernetes and Helm.
1
Answers
-
I've said this many times: Documentum cloud engineers can't tell a container from a VM (and therefore, they don't know what they are doing), and then these things happen. As you said, you can't do this without modifying the image by OT. In this case, your best approach is to build your own da image ( ) and adding there your dfc.properties with all the information.
If you want to have a properly running image, you'll need to add as well your dfc.keystore and the app.xml file with your custom dmc_wdk_preferences_owner/dmc_wdk_presets_owner encrypted passwords, something that OT forgot when creating the image.
1 -
Alvaro,
Thanks a lot for getting back, and for your continued work in your blog (I've consulted it many times :) ).
Yes, I was trying to achieve this without creating my own image, but as you say, it's not really doable. They don't need to include the dfc.properties within WEB-INF/classes at all. It could be placed solely within the external config volume, given that the user will always need to add their own configuration to it. Maybe in the future!
0 -
In the stateless_compose.yml, you have a DFC_PROPERTIES environment variable where you can set all required values, e.g.
- DFC_PROPERTIES=dfc.data.dir=<DFC_DATA_DIRECTORY>::dfc.tokenstorage.dir=<DFC_TOKENSTORAGE_DIRECTORY>::dfc.tokenstorage.enable=false::dfc.docbroker.host[0]=<DFC_DOCBROKER_HOST>::dfc.docbroker.port[0]=<DFC_DOCBROKER_PORT>::dfc.globalregistry.repository=<DFC_GLOBALREGISTRY_REPOSITORY>::dfc.globalregistry.username=<DFC_GLOBALREGISTRY_USERNAME>::dfc.globalregistry.password=<DFC_GLOBALREGISTRY_PASSWORD>::dfc.session.allow_trusted_login=false::dfc.security.ssl.use_anonymous_cipher=true
About the password, it doesn't have to be encrypted in order to work (even though it is obviously recommended). I have a dev environment where I keep it in clear text and it works fine. You can encrypt it as documented if you want and paste the encrypted password in the YAML file.
About Docker Compose in general, I'm not sure how long OpenText will provide support for it (not that OT support provided any useful help on that subject for me). The future is clearly Kubernetes and Helm.
1 -
No I haven't had that problem. Did you check the docker compose logs?
0
Categories
- All Categories
- 123 Developer Announcements
- 54 Articles
- 150 General Questions
- 148 Thrust Services
- 57 OpenText Hackathon
- 37 Developer Tools
- 20.6K Analytics
- 4.2K AppWorks
- 9K Extended ECM
- 918 Core Messaging
- 84 Digital Asset Management
- 9.4K Documentum
- 32 eDOCS
- 186 Exstream
- 39.8K TeamSite
- 1.7K Web Experience Management
- 8 XM Fax
- Follow Categories