we use Mendix for some of our custom-apps; we are getting ready to migrate from m2ee-tools to docker deplyments of on-premise systems. This is because Mendix drops support for m2ee-tools beginning with Centos/RHEL 8, and the latest supported Centos/RHEL 7 end of life is in about 2 years (June 2024).
We got stuck on one key point in our proof-of-concept scenario and need help:
How to enable/disable debugger in a Mendix app that is running in a docker container?
What we have already found:
We are aware of triggering the debugger at container’s startup by providing them with a variable DEBUGGER_PASSWORD="stringData", but then the debugger is enabled throughout the lifetime of this instance of container which is undesired.
From some in-depth analysys we have also found that the debugger is normally enabled on a running Mendix application by a POST request to a running app. However, we are currently unaware of what the message body is.
We have identified the answer. Since finding the answer was not trivial, the original question has been unanswered for 3 weeks, and has received an upvote, therefore I will add the answer to this thread so it is usefull in case other Mendix developers search for "docker" + "debugger".
A container parametrized and started using the following command:
docker run -it -p 8088:8080 \
-e ADMIN_PASSWORD='ApplicationAdminPassword1' \
-e DATABASE_ENDPOINT='postgres://pgPassword:pgUser@192.168.0.1:5432/pgDbName' \
-e M2EE_PASSWORD='PasswordForAdministrativeTasks1' \
mendix/mendix-buildpack:v1.2
can have the debugger enabled like this:
curl -X POST -u 'MxAdmin:PasswordForAdministrativeTasks1' \
-H "Content-Type: application/json" \
-H "X-M2EE-Authentication: `echo -n 'PasswordForAdministrativeTasks1' | base64`" \
-H "Connection: close" \
-d '{"action": "enable_debugger", "params": {"password": "aRandomPassForDebugger1"}}' \
localhost:8088/_mxadmin/; echo
and the debugger is available as normal, via the address http://applicationHostIP:8088/debugger/ using the pasword you have declared "aRandomPassForDebugger1". M2ee-tools seem to be using alphanumeric characters only (perhaps in order to avoid troubles with special caracters in certain contexts or situations) - in this case the password strength has to be obtained by lengthening it. M2ee-tools use more than 20 characters.
The second action can in fact be performed using a variety of tools, not ecesairly with curl.
Two manuals were helpful, but required some effort to "comsume" and be turned into a method for enabling the debugger. The manuals can be found at docs.mendix.com and at github.com/mendix.
As you can see, in order to communicate with the runtime, you need to send a POST message with simple auth and the additional headers. Mendix team has decided to migrate from an admin-port used by m2ee-tools to a service available in the docker container at "_mxadmin" directory of the application-provisioning web-end.
Pay attention to this part:
-H "X-M2EE-Authentication: `echo -n 'PasswordForAdministrativeTasks1' | base64`"
It is a header with base64-encoded password (yes, the same password provided again in the same POST message, just provided in a different form). You can substitute the inline (that calculates base64) with the off-line-made string, which in this example is UGFzc3dvcmRGb3JBZG1pbmlzdHJhdGl2ZVRhc2tzMQ== .
Note that the message's paylod is a json data structure. Many payload-actions require only the "action" clause, but some other additionaly require parameters (like enable_debugger).
'{"action": "enable_debugger", "params": {"password": "aStrongPass"}}''{"action": "get_debugger_status"}''{"action": "disable_debugger"}''{"action": "get_admin_action_info"}'The last listed action (get_admin_action_info) has a potential to be particularily useful for figuring out many other actions for communicating with the runtime-messaging (it returns a list of available actions), so try it out yourself.