- Add a *version* file placeholder.
- Update autogen and builds to use it and an autogen build flag
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 8054a303870b81eebe05e38261c1b68197b68558
Component: engine
This reverts commit d5cd032a86617249eadd7142227c5355ba9164b4.
Commit caused issues on systems with case-insensitive filesystems.
Revert for now
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: b78ca243d9fc25d81c1b50008ee69f3e71e940f6
Component: engine
- Move autogen/dockerversion to version
- Update autogen and "builds" to use this package and a build flag
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: d5cd032a86617249eadd7142227c5355ba9164b4
Component: engine
All docker subcommands support `-h` as an alias for `--help`
unless they have `-h` aliased to something else like `docker run`,
which uses `-h` for `--hostname`.
`-h` is not included in the help messages of the commands, though.
It ist visible in
* reference: only in `docker daemon` reference,
see output of `grep -Rse --help=false docs`
* man pages: only in `docker` man page
see output of `grep -RF '**-h**' man`
For consistency reasons, this commit removes `-h` as an alias for
`--help` from the reference page, man page and the bash completion.
Signed-off-by: Harald Albers <github@albersweb.de>
Upstream-commit: ceb11d966034f4b4308abf4fc2826b4c840b6e99
Component: engine
This patch creates a new cli package that allows to combine both client
and daemon commands (there is only one daemon command: docker daemon).
The `-d` and `--daemon` top-level flags are deprecated and a special
message is added to prompt the user to use `docker daemon`.
Providing top-level daemon-specific flags for client commands result
in an error message prompting the user to use `docker daemon`.
This patch does not break any old but correct usages.
This also makes `-d` and `--daemon` flags, as well as the `daemon`
command illegal in client-only binaries.
Signed-off-by: Tibor Vass <tibor@docker.com>
Upstream-commit: 96ce3a194aab2807fdd638825b9ea7cb9ba55c36
Component: engine
Carry #11675
Aside from what #11675 says, to me a key usecase for this is to support
more than one Docker cli running at the same time but each may have its
own set of config files.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: daced1d30345aca06857f874dfb48b7e90cb409b
Component: engine
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 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
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
I also needed to add a mflag.IsSet() function that allows you to check
to see if a certain flag was actually specified on the cmd line.
Per #9221 - also tweaked the docs to fix a typo.
Closes#9221
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: ae9bd580af55992974fcb94f73f72cc3b2257fec
Component: engine
Next steps, in another PR, would be:
- make all logging go through the logrus stuff
- I'd like to see if we can remove the env var stuff (like DEBUG) but we'll see
Closes#5198
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 2facc0467336a80f48c765dbdbd803055a431aa9
Component: engine
This removes the key generation for trust from main while it is not
being consumed. The problem is that because this is being set in main
if a user runs as root initially the files will be owned by root. Later
if the user sets up the docker group they are unable to read the keys.
This is half a user error and documentation problem and the other half
is management.
We decided to remove this code for now while it is not being used and
will revisit it later when the consuming features are added. A few
options are to generate lazily and provide a clear error message on an
EPERM so that the user knows what is wrong and can correct the
permissions.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 712e8da885de00d1957a15c0c7f862fb3b2f6beb
Component: engine
