Hi Maik,

changePassword.sh is still in the container, but its location has moved.  It is in the PATH for your container, so if you delete the absolute-path portion and use "changePassword.sh /durable/password_copied.txt" you should be up and running.

changePasswordHash.sh is an internal tool and we don't recommend customers use it.

Hope this helps.

This is a security feature.  The environment for things like LD_LIBRARY_PATH is strictly controlled to minimize the risk of unauthorized input.

There's an iris.cpf setting that will help you: https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=RACS_LibPath
 

Two Dockerfiles that would work:

FROM ${IMAGE}

ENV MYDIR /usr/mydir

    # Add MYDIR to the LD_LIBRARY_PATH of IRIS subprocesses
RUN sed /usr/irissys/iris.cpf -e "s%^LibPath=%LibPath=$MYDIR%" > /tmp/iris.cpf \
    # sed -i alters ownership, this approach preserves it
 && cat /tmp/iris.cpf > /usr/irissys/iris.cpf
FROM ${IMAGE}

ENV MYDIR /usr/mydir

USER root
    # Add MYDIR to the LD_LIBRARY_PATH of IRIS subprocesses
RUN sed -i $ISC_PACKAGE_INSTALLDIR/iris.cpf -e "s%^LibPath=%LibPath=$MYDIR%" \
    # sed -i alters ownership, let's reset it
 && chown $ISC_PACKAGE_MGRUSER:$ISC_PACKAGE_IRISGROUP $ISC_PACKAGE_INSTALLDIR/iris.cpf


USER $ISC_PACKAGE_MGRUSER

Hi Brendan,

For write-style operations, my recommendation is: Do not allow this in production.  Part of the gain from containerization is that you make production as automation-friendly as possible, and that it's manipulated by humans in potentially-unpredictable ways as rarely as possible.

For read-style operations - i.e., logging in and running "do ^GetReports" - I don't expect this to be a common use case. Containers usually operate on service models that involve a minimum of command-line interactivity, and as few ways as possible to access the application running inside.  Most of those methods are usually network-based rather than terminal-based.  You're absolutely correct that giving folks membership in the "docker" group on a host is equivalent to giving them host-root, which means it may be unsuitable for your use case here.

Installing sshd inside the image is an option, but will come with some complexity.  You'll need to start sshd in your iris-main --before, and preferably also stop it gracefully on the other side. You'll also have to clear the hurdle where the /etc/passwd and /etc/group entries inside the container are relatively unrelated to the entries outside of it, though if you have the container connect to the same NIS server as the host does, that problem should become fairly moot.

Side note on users/groups in the container vs. on host: Integer UIDs and GIDs are the same, which can be important when writing files to your Durable %SYS area or other host bind mounts, but the number->name mappings are totally independent; they're essentially two different interpretations of the same "primary key".  This can be a plus, and can allow you to have a custom approach to users/groups inside a container; when combined with named Docker volumes (instead of bind mounts), you can create a whole distinct user/group ecosystem, if you like.

I don't have a lot of experience with Web Terminal, but it would be my go-to option for letting users log in remotely via their IRIS credentials while bypassing the need for any management of Linux credentials inside the container.

If I'm wrong and this turns out to be a commonly-desired use case, we can look into other solutions or new features here.

Cheers,
Conor