The keyserver infrastructure is unreliable, and just adds another point
of failure without adding any security. Instead, commit the key used at
build time for ZFS to the repo, and inline our signing key into the
install script rather than just its fingerprint.
fix#28510fix#13555
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Upstream-commit: 91b42cf8428ec20c3d6775019ed04d89330c1dcd
Component: engine
`plugins.GetAll()` was not locking the plugin map when checking if a
plugin exists, this can cause a race and potentially a panic if another
goroutine is trying to load a plugin into the map at the same time.
Also fixes a race during activation where a plugin inserts itself into
the plugin map but does not check if something else is already there.
This is already checked before trying to activate the plugin, however
the map lock is not held for this entire period, so other plugins may be
loaded during this time.
To fix, before inserting the plugin into the map, check if one with the
same name already exists and use that instead.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 21fcbb39b73310e69d6403a1cfa8b26799cc1355
Component: engine
This test checks for the substring "foo" in the "secret ls" output. This
is a valid base36 substring and can sometimes show up by chance:
docker_cli_secret_create_test.go:86:
c.Assert(out, checker.Not(checker.Contains), name)
... obtained string = "" +
... "ID NAME CREATED UPDATED\n" +
... "ob8y4t4feuz8pn5h6vla9oxoz stefoo7e268ozqfupi9s4se9q Less than a second ago Less than a second ago\n"
... substring string = "foo"
Change the secret name to test_secret, matching other tests. Underscores
can't appear in base36 so this name is safe to grep for.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 45833ce54d741b2378819e3ba5859533c317ae01
Component: engine
Vendor the latest official logrus release instead of a custom fork
(which now happens to be identical to the fork).
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 11df2db538fbc7a6181c591b6ec47db9f96a87e4
Component: engine
I often get complains that container removal failed and users got following
error message.
"Driver devicemapper failed to remove root filesystem 18a69ba82aaf7a039ce7d44156215012d703001643079775190ac7dd6c6acf56:Device is Busy"
This error message talks about container id but does not give any info
about which particular device id is busy. Most likely device is mounted
in some other mount namespace and if one knows the device id, they
can try to do some debugging figuring which process and which mount
namespace is keeping the device busy and how did we reach that stage.
Without that information, it becomes almost impossible to debug the
problem.
So to improve the debuggability, when device removal fails, also return
device id in error message. Now new message looks as follows.
"Driver devicemapper failed to remove root filesystem 18a69ba82aaf7a039ce7d44156215012d703001643079775190ac7dd6c6acf56: Failed to remove device dbc15bdf9994a17c613d8ef9e924f3cffbf67f91e4f709295c901ad628377991:Device is Busy"
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 39bdf601f6bea3c189d8e189e13c7e48b6f66b43
Component: engine
returned in "docker info". Currently info endpoint isnt using the
GetAllByCap, but relies on existing networks to get the plugin names.
This causes a basic issue when it comes to global network plugins which
swarm-mode relies on, wherein swarmkit will not be able to schedule the
network on the worker nodes due to the filtering logic.
In order to break this chicken & egg issue, we must start to use the
GetAllManagedPluginsByCap. We are unable to use GetAllByCap due to
various issues with Plugin-V1's lazy loading approach causing issues
especially during daemon restarts (which uses SystemInfo)
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: 6aaa85f0b0dd030f68512ca9004823926419f5fd
Component: engine
