· Oct 3, 2019

Remote terminal to IRIS container

When deploying IRIS in a container, what are recommendations for permitting users terminal access? There is docker exec -it, but that does not work from a user's workstation where - in the old deployment model - they would connect to the server over ssh using Putty and open a terminal session from there.

Discussion (9)2
Log in or sign up to continue

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.


Hi Brendan,

So you must have a CHUI based app or part of it, still on chui/ssh. On one hand I'd like to suggest it's time to move on to something more modern as containers are in general seen as backend services (UDP, TCP, http, etc.) on the other I do understand that it's difficult to evolve quickly.

A few years ago I used to use Tutum containers based on Ubuntu and CentOS that had sshd in it. Docker bought them and their containers disappeared. You can probably still find them in the Docker Hub but they'd be old and stagnating.

Since then you've probably seen this link on the Docker doc. One issue is about users's mapping though, as mentioned. The WebTerminal or managing your sshd are the two most realistic options right now.

Apparently InterSystems is working on something that maybe useful to you but their lips are tight :)

Hi Evgeny,

We need to allow users to log in using their UNIX credentials (via LDAP) and run terminal sessions as their OS user. Because web-terminal works over the SuperServer port, even if we used LDAP auth at that level, their processes would run as the user associated with the SuperServer service, so it does not fit our security model. We will look at it, because it may have some limited usefulness in some contexts, but probably not in production.

Thanks for sharing the dockerfile.