Dynamic user support.

[whitingjr]

Currently the Indy docker file uses a user named "Indy" with id 1001.
When the same image is run in Openshift a dynamic user id is created. It means tools like whoami are broken.

sh-4.2$ whoami
whoami: cannot find name for user ID 1013040000
sh-4.2$

The image can be adapted to work elegantly with Openshift by adding dynamic user configuration. Documented here in Support Arbitrary User IDs.

[whitingjr]

For example when starting Indy this appears in the log file

/usr/bin/id: cannot find name for user ID 1060920000
/usr/bin/id: cannot find name for user ID 1060920000
/usr/bin/id: cannot find name for user ID 1060920000
/usr/bin/id: cannot find name for user ID 1060920000

[whitingjr]

PR #22 has been created to solve this issue.

[whitingjr]

I have reopend this issue because the issue still exists. But the PR #22 did not correctly solve the problem or implement correctly.

[whitingjr]

Not only does the running user not get recognized but this impacts the JVM process and the integration with JVM tooling. (jps, jcmd)
The JVM performance metrics subsystem relies on writing to a directory. Using this form.
/tmp/hsperfdata_<user>

Openshift then allocates a dynamic user id. In this case 1013040000.
That breaks the mechanism of recognizing the active user in the running container image. The JVM has no user information to work with. Causing the failure to write this expected directory
/tmp/hsperfdata_indy

When a operations user subsequently uses a JVM tool jps to list the running processes in the container that fails. The tool fails to communicate with the active running Indy JVM.

By correctly integrating the nss_wrapper library the current user can be correctly recognized when the Indy JVM starts up. Writing the expected directory /tmp/hsperfdata_indy and the expected process id file in the directory.

[whitingjr]

Investigation into how the Indy JVM is started reveals how shells are used.

At the Entrypoint the dumb init command is started with a login-less shell.
dumb-init is configured to start login Bourne shell, this process calls the start-indy.sh
start-indy.sh discovers configuration options and then uses the Python library to call the next script.
The python library uses another shell process to call indy.sh

The current container image which starts Indy JVM shows these log messages.

Command parts: ['/bin/bash', '-l', '/opt/indy/bin/indy.sh']
/usr/bin/id: cannot find name for user ID 1013040000
/usr/bin/id: cannot find name for user ID 1013040000
/usr/bin/id: cannot find name for user ID 1013040000
/usr/bin/id: cannot find name for user ID 1013040000
Loading logging config from .......

these messages are logged when shell process start-indy.sh script is discovering the user, then when the shell script is running the /etc/profile to set-up the environment.
A working solution needs to be found so that either shell can correctly initialize the environment.

[whitingjr]

Bash login shells requires configuring with nss_wrapper. But with no modification to /etc/passwd. Which is were the initial implementation failed in PR #22 .

The solution is:
re-configure dumb-init to call the setup-user.sh before starting start-indy.sh, thus ensuring the start-indy.sh script has a correctly configured shell environment

This correctly integrates the workaround for Openshift dynamic inventory user id. This article explains the integration with nss_wrapper in more detail. The article covers the security concerns and solution that Openshift uses to limit the exposure.