Re:Dockersh – a shell that puts users into individual docker...
by scintill76 on Wednesday August 27, 2014 @12:51AM
(#8230896)
> This allows you to have a single ssh process on the normal ssh port which places user sessions into their own individual docker containers in a secure and locked down manor.
Funniest instance of this misused homonym I've seen.
Re:Dockersh – a shell that puts users into individual docker...
by scintill76 on Wednesday August 27, 2014 @10:55PM
(#8235723)
Ah, I've been out-pedanted. Yeah, I realized a while after posting. Looking at Wikipedia and some dictionaries, it looks like homonym doesn't always imply same spelling. Homophone would be more correct though.
Re:Dockersh – a shell that puts users into individual docker...
by donw on Wednesday August 27, 2014 @04:54AM
(#8231307)
I'm not sure if this is related -- because it doesn't require Docker or Linux -- but I've got a small shell tool for transparent development on remote machines. Gives you the ability to do something similiar (`ws shell`), and drop directly into the remote environment you're working in.
I use it to work on my Mac, but develop on a Linux box:
Re:Dockersh – a shell that puts users into individual docker...
by heavenlyhash on Wednesday August 27, 2014 @10:24AM
(#8232241)
To shamelessly plug a much more minimalist solution, https://github.com/polydawn/siphon-cli can also give you new shells shells inside existing containers (or whatever; it's more like screen than anything tightly bound to docker).
Siphon does nothing but create and forward psuedoterminals, so it has a lot less features to directly interact with docker than dockersh appears to have, but it's also able to do its job without root or any priviledged syscalls, and doesn't rely on any knowledge of kernel namespaces at all. Which is more useful may depend on your perspective and usecases.
Re:Dockersh – a shell that puts users into individual docker...
by thu on Wednesday August 27, 2014 @04:25AM
(#8231248)
The point is not containerization with Docker (vs. something else), but showing a project that can be used as a login shell. I.e. I think a good chunk of the challenge was gluing everything from sshd to the running individual containers.
Even if you were saying that such a login shell already exists with another containerization scheme, the fact it uses Docker is relevant to those who are investing in Docker. For instance Dockersh can be configured to run the shell in a specific Docker image; that is you can re-use your existing knowlegde and tooling.
Re:Dockersh – a shell that puts users into individual docker...
by jacques_chester on Wednesday August 27, 2014 @07:31AM
(#8231619)
Sometimes, during development or when fixing a deployed app, you want to get inside the container environment to poke around. Just to work out why the hell something did or didn't happen.
Right now it is difficult. Docker doesn't support it directly. There is a lot of demand for it:
Re:Dockersh – a shell that puts users into individual docker...
by thu on Wednesday August 27, 2014 @07:39AM
(#8231640)
Are you sure it is related to entering an existing container (and running a new process) ?
From reading the README file, it seemed to me it was only spawning a login shell process in a new container (not an existing one), and possibly resuming an existing container.
Re:Dockersh – a shell that puts users into individual docker...
by taylorbuley on Wednesday August 27, 2014 @10:09AM
(#8232150)
I feel this docker pain. But isn't an isolated process the point? I thought I read an article here recently that said, basically, if you're running an ssh server in your proc then you're doing it wrong.
Re:Dockersh – a shell that puts users into individual docker...
by antocv on Wednesday August 27, 2014 @07:33AM
(#8231623)
> This allows you to have a single ssh process on the normal ssh port which places user sessions into their own individual docker containers in a secure and locked down manner.
No! Warning!
Docker is not secure and locked down. Do not use this for "security".
Funniest instance of this misused homonym I've seen.
I use it to work on my Mac, but develop on a Linux box:
https://github.com/matadon/workspace
Siphon does nothing but create and forward psuedoterminals, so it has a lot less features to directly interact with docker than dockersh appears to have, but it's also able to do its job without root or any priviledged syscalls, and doesn't rely on any knowledge of kernel namespaces at all. Which is more useful may depend on your perspective and usecases.
https://gist.github.com/TeMPOraL/3d134ce0d4a2b2f4232b
Basically, it starts a screen instance with a shell and your script running side by side, so when you Docker-attach to it, you can C-a " to shell.
run.sh would be the script you want to be run in container - the one that starts your webserver, database, whatever.
I adapted a screen solution from some random StackOverflow comment.
http://sandbox.libvirt.org/quickstart/
Libvirt sandbox can also put processes, jobs, users etc into real VMs as well as chroots ^W containers.
Or how we ISPs gave dialup modem users their own login shells in mid 1990's:
http://www.freebsd.org/cgi/man.cgi?query=jail
I can't find docs for the chroot shell we used back then, but what we did was along the same lines as this:
http://www.aarongifford.com/computers/chrsh.html
Even if you were saying that such a login shell already exists with another containerization scheme, the fact it uses Docker is relevant to those who are investing in Docker. For instance Dockersh can be configured to run the shell in a specific Docker image; that is you can re-use your existing knowlegde and tooling.
This is a fun alternative to proper jails but unfortunately, security wise this would not last very long on in a real world application.
Not going to lie, would be pretty cool to set something like this up and auto provision upon payment.
Yes, design is outdated. This was great at the time; people were still using tables for layouts.
http://l3net.wordpress.com/2014/04/16/how-to-restrict-a-logi...
Right now it is difficult. Docker doesn't support it directly. There is a lot of demand for it:
https://github.com/docker/docker/issues/1228
You have to use nsenter, which is OK, but requires additional installation:
https://github.com/jpetazzo/nsenter
It looks as though an-almost-but-not-quite-the-same thing will land in Docker at some point:
https://github.com/docker/docker/pull/7409
And this shell is another attempt to make a very useful feature available.
From reading the README file, it seemed to me it was only spawning a login shell process in a new container (not an existing one), and possibly resuming an existing container.
I know the phusion/baseimage argues against excessive isolation:
https://github.com/phusion/baseimage-docker#docker_single_pr...
No! Warning!
Docker is not secure and locked down. Do not use this for "security".