DOCEKR_TLS_VERIFY was being ignored because we were just checking if the
`-tlsverify` flag was set, not the actual value, which is defaulted to
the value of `os.Getenv("DOCKER_TLS_VERIFY") != ""`
The problem that this specifically fixes is where the client has set the
`DOCKER_TLS_VERIFY` env var but is connecting to a daemon that is not
verifed.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 5a6a33f7acccc7394a5ac418e777d5a6e1d1b7ed
Component: engine
This sets up the umask so that it's the same on all systems.
Signed-off-by: Cristian Staretu <cristian.staretu@gmail.com>
Upstream-commit: 6578ad90c307c5500a7998819743be88f63ef2b3
Component: engine
This patch creates a new `tlsconfig` package to handle creation of
secure-enough TLS configurations for clients and servers.
The package was created by refactoring TLS code in the client and the
daemon. After this patch, it is expected that all code creating TLS
configurations use this `tlsconfig` package for greater security,
consistency and readability.
On the server side, this fixes a bug where --tlsverify was not taken
into account. Now, if specified, it will require the client to
authenticate.
Signed-off-by: Tibor Vass <tibor@docker.com>
Upstream-commit: bfed4b7cc3820ee3a74580aca55d5918bf05eef5
Component: engine
The DOCKER_EXPERIMENTAL environment variable drives the activation of
the 'experimental' build tag.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Upstream-commit: ca6722f1c5e4e2017a71e33579d91ac0d9ea2a25
Component: engine
Due to popular demand :-)
See #11965
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: a85ca8b7c40f05f2b6471cc30fb8d5271605c1d1
Component: engine
Before this PR the list of commands that were printed for the help
text was statically put into the flags.Usage() function via main.init(). This
made it impossible to modify later on when we add new commands
via plugins.
This PR moves the list of commands (name & description) into a structure
that is sorted and printed dynamically by the Usage func. This will allow
the code to add to the list of commands after the init() func is done
but before the help text is printed for the user.
This just moves code around - it should have no UX impact at all.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 4f00b1020e8bf28d5d3dfb88730894888666fd9a
Component: engine
* daemon creation wasn't parallel to request buffering
* it was possible that empty volume will be created in
/var/run/docker.sock by some container
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: 08230703fdd0f7bcd9a87a0d61d88fdf2b901e66
Component: engine
Added daemon field to it, will use it later for acces to daemon from
handlers
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: d9ed3165228b60cb89c31d0d66b99e01ab83eb3e
Component: engine
It is simplifies code and lead to next refactoring step, where daemon
will be incorporated to some structure which represents API.
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: 181fea24aac7499a3d6dc0c8c9de67e6c0036140
Component: engine
This makes `registry.Service` a first class type and does not use jobs
to interact with this type.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 03d3d79b2b3f8b720fff2d649aff0ef791cff417
Component: engine
Currently the daemon will not stop on error because the serve API job is
blocking the channel wait for daemon init. A better way is to run the
blocking serve API job as a goroutine and make sure that error
notification gets back to the main daemon thread (using the already
existing channel) so that clean shutdown can occur on error.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 459e58ffc9bff8206a860fb63f973e4f07129756
Component: engine
It is implemented by intercepting and interpreting the output
escape sequence by calling win32 console apis.
In addition the input from win32 console is translated to linux keycodes
Signed-off-by: Sachin Joshi <sachin_jayant_joshi@hotmail.com>
Upstream-commit: d8c3090dd9abe3f0d95f99c9d8c7660922e9a719
Component: engine
Previously on error either from the daemon or from the api it is just
exiting with exit status 1 but not performing a shutdown.
This can produce insconsistent state depending on where the error came
from.
This makes sure that before we exit on error that the engine gets fully
shutdown.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 0e3f2f2ac07c69922bd837f864219a088d243248
Component: engine
