Hacker News Reader

Comment by rvz | Hacker News Reader

Hardly a cross-platform solution like what the current Docker app does, with tons of moving parts which you are 1 upgrade away to breaking everything with that installation and its back to re-installing it again or wasting time digging down and trying to fix what went wrong for just one distro in the worst case.

> You may not be able to run this default image under MacOSX, although dock scripts themselves are fully compatible.

Probably developers using Windows are also unable to run this script as well. So I guess they are no better off with a 1 click install with Docker Desktop.

It seems the video I saw had more than 2 steps. If it is really a 2 steps installation then it is 50 steps back when it all breaks.

View on HN

Author here: it actually doesn't break. Been running it for 1,5 years. It's bash, there isn't much that can break. And it uses Docker cli with no hackery or experimental options.

The only thing I am working on right now: a way to avoid building special images for MacBooks or ARMs, but rather have a patch-tool (a bash script, essentially), which would pull any image you want from Docker Hub and then run patches on it (patches are also simple, readable Bash scripts which would work kind of like migrations for DBs), so that you will quickly have a Dock-compatible image and if you wanted a Python or a Ruby env you'd use an extra set of included patches or write your own.

It sounds more complex than it would actually work, honestly.

Under Windows, WSL/WSL2 is new (5 years old) big thing which is integrated with Docker Desktop as well.

I've tried to run `dock` under WSL2 and install works fine, container creation works fine, but connecting through SSH fails - due the fact that Docker is really running in different VM and is not directly accessible (ssh just times out). Looks like, adding some small modifications of way of exposing ssh/connecting there should allow it as well.

On side note - bash scripting is very nicely done! But running through `shellcheck` gives some hints on safer handling, i.e.

  echo "StrictHostKeyChecking no"                 >> ~/.ssh/dock_config_$ssh_suffix
                                                                        ^---------^ SC2086: Double quote to prevent globbing and word splitting.

I wasn't paying much attention to all sorts of safety issues, like potential RCEs, because this was initially intended for local development, not production use. But do let me know if you see how someone would be able to exploit those scripts without `dock` user knowing about it.

Also, thank you for trying it out and reporting it works even on Windows, pleasantly surprised.

I did some monkey patching for exposing ports and it works even further - okay, it automagically logins via ssh now as expected. I can probably send it as is to Github/Gitlab so you have an idea.

Disclaimer: was not considering any edge cases with my changes.

Could you please email me the git patch? Or put it on Github/Gitlab yourself and send me the link.

(I think I do make it a bit complex for people to contribute, but I don't have a lot of time to spare).

Pushed to Github, please take a look - https://github.com/CoolCold/dock/commit/101950b2275b3e920c55...

P.S. Email sounds like it's 1997 and lynx/elinks are still actual ;)

Yeah, ok. I'll be setting up a Github repo soon. I guess that's how we roll these days. Github will be learning more about how to program Bash then.

> But do let me know if you see how someone would be able to exploit those scripts

My (and my teams) rule of thumb is simple here - if shellcheck complains, that better be reviewed, usually it complains for a reason and makes code better/safer.

Reply on news.ycombinator.com