3 ms·

When I read the title, I expected that I'd finally be able to use Podman containers for my development environments & shells (i.e. inside my existing user accou

When I read the title, I expected that I'd finally be able to use Podman containers for my development environments & shells (i.e. inside my existing user account), for reproducibility purposes and to protect against the most trivial of supply chain attacks etc. Unfortunately, this is not entirely trivial (think IDE integration; also, one likely wants to use both personal shell commands and project-specific commands on the same command line). So I was hoping the Podman devs had found a good solution here. Not really sure what one would use a login shell for, though. I mean, if I, as the user, am merely logging into a containerized shell, why don't I execute the container locally? Why use SSH? Sure, the volumes mounted into the login shell container might contain data I need, but one could also simply mount them as network storage locally.

5e92cb50239222b 3y ago
Have you looked at toolbox? it might already be doing what you want — it's a thin wrapper around podman that integrates containers with the rest of the system — you don't really even feel that you're running a container. https://github.com/containers/toolbox https://github.com/containers/toolbox
maffydub 3y ago
Have you tried floki (https://github.com/Metaswitch/floki https://github.com/Metaswitch/floki) - this is what we use to solve this problem.
Chris660 3y ago
In addition to the other suggestions, you might want to check-out distrobox: https://github.com/89luca89/distrobox https://github.com/89luca89/distrobox It provides support for starting host commands within a container, and also exporting commands from containers to the host.
- yencabulator 3y ago
  Last I looked, distrobox made $HOME fully accessible to all its containers. That's the very opposite of parent comment's "protect against the most trivial of supply chain attacks".
salawat 3y ago
Thin client is one answer to your question. Running a shell to a server results in significantly longer endurance for a client on battery than otherwise. Not swamping your system's I/O bus is another. OS incompat. Regulatory shenanigans. Then there's also the training angle. I've found nothing quite as tangibly gets the visceral sense of computing across like walking a junior through a "where are your bits now?" now exercise with a handful of physical boxen.

5e92cb50239222b 3y ago

Have you looked at toolbox? it might already be doing what you want — it's a thin wrapper around podman that integrates containers with the rest of the system — you don't really even feel that you're running a container. https://github.com/containers/toolbox https://github.com/containers/toolbox

maffydub 3y ago

Have you tried floki (https://github.com/Metaswitch/floki https://github.com/Metaswitch/floki) - this is what we use to solve this problem.

Chris660 3y ago

In addition to the other suggestions, you might want to check-out distrobox: https://github.com/89luca89/distrobox https://github.com/89luca89/distrobox It provides support for starting host commands within a container, and also exporting commands from containers to the host.

yencabulator 3y ago
Last I looked, distrobox made $HOME fully accessible to all its containers. That's the very opposite of parent comment's "protect against the most trivial of supply chain attacks".

salawat 3y ago

Thin client is one answer to your question. Running a shell to a server results in significantly longer endurance for a client on battery than otherwise. Not swamping your system's I/O bus is another. OS incompat. Regulatory shenanigans. Then there's also the training angle. I've found nothing quite as tangibly gets the visceral sense of computing across like walking a junior through a "where are your bits now?" now exercise with a handful of physical boxen.