Colon was bold, but regular at other occurences.
Blame cf27b310c4fc8d2c13ba181398a628d03e1e3c58
Signed-off-by: Lorenz Leutgeb <lorenz.leutgeb@gmail.com>
Upstream-commit: a51554988e615b317e95125f5612a28c3bff8e8a
Component: engine
* Adjust header to match _page_title
* Add instructions on deletion of CSRs and setting permissions
* Simplify some path expressions and commands
* Consqeuently use ~ instead of ${HOME}
* Precise formulation ('key' vs. 'public key')
* Fix wrong indentation of output of `openssl req`
* Use dash ('--') instead of minus ('-')
Remark on permissions:
It's not a problem to `chmod 0400` the private keys, because the
Docker daemon runs as root (can read the file anyway) and the Docker
client runs as user.
Signed-off-by: Lorenz Leutgeb <lorenz.leutgeb@gmail.com>
Upstream-commit: 02a793c6a133f46129d0fc83ce218d3a92f1e644
Component: engine
This fixes the container start issue for containers which were started
on a daemon prior to the resolv.conf updater PR. The update code will
now safely ignore these containers (given they don't have a sha256 hash
to compare against) and will not attempt to update the resolv.conf
through their lifetime.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 30eff2720a110f3ece0e429ef1897a254f0d9e71
Component: engine
Only modifies non-running containers resolv.conf bind mount, and only if
the container has an unmodified resolv.conf compared to its contents at
container start time (so we don't overwrite manual/automated changes
within the container runtime). For containers which are running when
the host resolv.conf changes, the update will only be applied to the
container version of resolv.conf when the container is "bounced" down
and back up (e.g. stop/start or restart)
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 63a7ccdd2372d87f56f7a86da07c72ea51332c2a
Component: engine
since we can control it with --mac-address.
Signed-off-by: Tangi COLIN <tangicolin@gmail.com>
Upstream-commit: d9ec04e18d5e1fede1afcec27a0d2c69d514a123
Component: engine
Using --insecure is (you guessed it) *insecure* as the server side
certificate is not being validated. To offer the same degree of
security as invocations of the docker client in "Secure by default"
with cURL, the trusted CA certificate must be supplied.
Signed-off-by: Lorenz Leutgeb <lorenz.leutgeb@gmail.com>
Upstream-commit: 26187bd851141236a909c0bada5a2743fc237e0e
Component: engine
With -CAcreateserial the serial file will be automatically created
and initialized if it is missing.
Signed-off-by: Lorenz Leutgeb <lorenz.leutgeb@gmail.com>
Upstream-commit: 131c62d7661ace86453de540cb1a58956b59e347
Component: engine
Do not encrypt private keys in the first place, if the encryption
is stripped anyway.
Signed-off-by: Lorenz Leutgeb <lorenz.leutgeb@gmail.com>
Upstream-commit: f957f258d722fa563ead0a14978acca7c6745d3f
Component: engine
Moves some information around, expanding information on
user namespaces, pull/load security, cap add/drop.
Also includes various grammar improvements and edits.
Signed-off-by: Eric Windisch <eric@windisch.us>
Upstream-commit: e704dd31e79114a2156c4fdda3247a181ad6435d
Component: engine
Copying the entire docker service file isn't necessary to add an
environment variable, instead use a drop-in configuration file. The nice
side-effect is that the user gets any vendor updates to the
docker.service file.
Signed-off-by: Brandon Philips <brandon.philips@coreos.com>
Upstream-commit: 2d51d71561565987fc6a600234f2e2d15e0ecf31
Component: engine
Minor but important typo in the new systemd guide introduced in #9347.
Signed-off-by: Brandon Philips <brandon.philips@coreos.com>
Upstream-commit: 1ae7be716eadf6efdc7ee033c83127e975222a76
Component: engine
Update for changes in docker 1.2. Running the docker daemon with "-r=false" has been deprecated in favor of per-container restart policies.
Signed-off-by: wilsaj <wilson.andrew.j+github@gmail.com>
Upstream-commit: 9542ea72188614d5b14f9e7fc31c80e6425738c4
Component: engine
PR 6720 introduce that use `--dns-search=.` will not set `search` in `/etc/resolv.conf`.
Signed-off-by: Huayi Zhang <irachex@gmail.com>
Upstream-commit: 36ffbd7acf60d15942c0591bb4fec498f021331e
Component: engine
The CLI commands had long dashes that won't work on most terminals when copy pasting.
Signed-off-by: wilsaj <wilson.andrew.j+github@gmail.com>
Upstream-commit: 36dae27fa26fe58efaf68296169cd2c6ba6dfcfe
Component: engine
We do this to prevent leakage of information, we don't want people
to be able to probe for existing content.
According to RFC 2616, "This status code (404) is commonly used when the server does not
wish to reveal exactly why the request has been refused, or when no other response i
is applicable."
https://www.ietf.org/rfc/rfc2616.txt
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity. If the server does not wish to
make this information available to the client, the status code 404
(Not Found) can be used instead.
10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or
permanent. The 410 (Gone) status code SHOULD be used if the server
knows, through some internally configurable mechanism, that an old
resource is permanently unavailable and has no forwarding address.
This status code is commonly used when the server does not wish to
reveal exactly why the request has been refused, or when no other
response is applicable.
When docker is running through its certificates, it should continue
trying with a new certificate even if it gets back a 404 error code.
Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
Upstream-commit: 69fe3e1a3493e53acb2da7220764bd3807415ea2
Component: engine
