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)
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)
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>
With -CAcreateserial the serial file will be automatically created
and initialized if it is missing.
Signed-off-by: Lorenz Leutgeb <lorenz.leutgeb@gmail.com>
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>
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>
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>
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)
This makes it possible to make the Docker client "secure by default"
without wrapping the binary in a shell alias so that `--tlsverify` is
always passed.
Signed-off-by: Aanand Prasad <aanand.prasad@gmail.com>
Sven Dowideit