Add golint to the Dockerfile, and a `validate-lint` task to the
Makefile. Currently, the linter will process a harcoded list of packages
that will expand as we fix more warnings. Eventually, the linter should
process all subpackages of the repo (excluding vendored code).
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Upstream-commit: 6cce8d18384a5ae1212e7b0f7b7ac9662a89c8c1
Component: engine
The automatic installation of AppArmor policies prevents the
management of custom, site-specific apparmor policies for the
default container profile. Furthermore, this change will allow
a future policy for the engine itself to be written without demanding
the engine be able to arbitrarily create and manage AppArmor policies.
- Add deb package suggests for apparmor.
- Ubuntu postinst use aa-status & fix policy path
- Add the policies to the debian packages.
- Add apparmor tests for writing proc files
Additional restrictions against modifying files in proc
are enforced by AppArmor. Ensure that AppArmor is preventing
access to these files, not simply Docker's configuration of proc.
- Remove /proc/k?mem from AA policy
The path to mem and kmem are in /dev, not /proc
and cannot be restricted successfully through AppArmor.
The device cgroup will need to be sufficient here.
- Load contrib/apparmor during integration tests
Note that this is somewhat dirty because we
cannot restore the host to its original configuration.
However, it should be noted that prior to this patch
series, the Docker daemon itself was loading apparmor
policy from within the tests, so this is no dirtier or
uglier than the status-quo.
Signed-off-by: Eric Windisch <eric@windisch.us>
Upstream-commit: 80d99236c1ef9d389dbaca73c1a949da16b56b42
Component: engine
These will create the apt & yum repos for the deb/rpms generated by build-deb
and build-rpm.
Adds sign-repo script which signs the repo metadata with a gpg key.
Signed-off-by: Jessica Frazelle <princess@docker.com>
Upstream-commit: c850e97c84abffc71509692ab1accd38408fa51b
Component: engine
I ran a single integration test and got an error that the file
/sys/module/apparmor/parameters/enabled doesn't exist. I don't have
apparmor installed. So, just check the file first to avoid a confusing
error.
Signed-off-by: Christy Perez <christy@linux.vnet.ibm.com>
Upstream-commit: 691ed6ef995b8ee7cf9bdcea29ccf4b58a244234
Component: engine
This helps ensure that `github.com/docker/docker/pkg/...` is actually safe to use in isolation (ie, doesn't import anything from `github.com/docker/docker` except other things from `pkg` or vendored dependencies).
Adding `github.com/docker/docker/utils` to the imports of `pkg/version/version.go`:
```
---> Making bundle: validate-pkg (in bundles/1.7.0-dev/validate-pkg)
These files import internal code: (either directly or indirectly)
- pkg/version/version.go imports github.com/docker/docker/autogen/dockerversion
- pkg/version/version.go imports github.com/docker/docker/utils
```
And then removing it again:
```
---> Making bundle: validate-pkg (in bundles/1.7.0-dev/validate-pkg)
Congratulations! "./pkg/..." is safely isolated from internal code.
```
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
Upstream-commit: 9465272c281c602c758e51ed99f344c0686a899a
Component: engine
Adding in other areas per comments
Updating with comments; equalizing generating man page info
Updating with duglin's comments
Doug is right here again;fixing.
Signed-off-by: Mary Anthony <mary@docker.com>
Upstream-commit: eacae64bd89ccc95a6db7bda76d36014e71e70ac
Component: engine
no longer load hide critical code such as in .integration-daemon-{start,stop},
if this step failed, it will had logged the corresponding module before:
---> Making bundle: .integration-daemon-start (in bundles/1.7.0-dev/daemon-start)
which is nicer to debug.
This will make it also easier to execute a single tests in an interactive shell.
$ make shell
docker> . hack/make.sh binary .integration-daemon-start .integration-daemon-setup
docker> docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
docker> go test github.com/docker/docker/integration-cli
Signed-off-by: Jörg Thalheim <joerg@higgsboson.tk>
Upstream-commit: 2b4facdf2ed6b1074a2a8abc031bf0827b6d5f33
Component: engine
I added 301 redirects from dockerproject.com to dockerproject.org but may as
well make sure everything is updated anyways.
Signed-off-by: Jessica Frazelle <princess@docker.com>
Upstream-commit: 7943bce8942ee8c262180652951216d963fa6202
Component: engine
Using "DEST" for our build artifacts inside individual bundlescripts was already well-established convention, but this officializes it by having `make.sh` itself set the variable and create the directory, also handling CYGWIN oddities in a single central place (instead of letting them spread outward from `hack/make/binary` like was definitely on their roadmap, whether they knew it or not; sneaky oddities).
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
Upstream-commit: ac3388367b6493987cef8017774fa4cdb5d2098f
Component: engine
Ubuntu Precise has a number of warts that made it non-trivial to add initially, but I've managed to work through some of them and come up with a working build. Two important parts to note are that it has neither the `btrfs` nor the `devicemapper` graphdriver backends since `btrfs-tools` and `libdevmapper-dev` in the precise repositories are too ancient for them to even compile.
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
Upstream-commit: 98180b89543396c07c1f1ea420554fbcce31c513
Component: engine
This fixes the part of #12996 that I forgot. 👼
This also fixes a minor path issue (there's no `libexec` in Debian), and fixes a minor bug with the `debVersion` parsing.
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
Upstream-commit: 867eed8f3586c81b32dc9f85208692e9e1c9909a
Component: engine
This change adds a new docker-in-docker dynamic binary make target which
builds a centos container for creating the dynamically linked binary.
To use it, you first must create the static binary and then call the
dind-dynbinary target. You can call it like:
$ hack/make.sh binary dind-dynbinary rpm
This would then package the dynamic binary into the rpm after having
created it in the centos build container. Unfortunately with this approach
you can't create the rpms and the debs with the same command. They have to
be created separately otherwise the wrong version (static vs. dynamic) gets
packaged.
Various RPM fixes including:
- Adding missing RPM dependencies.
- Add sysconfig configuration files to the RPM.
- Add an epoch to silence the fpm warning.
- Remove unnecessary empty package.
Signed-off-by: Patrick Devine <patrick.devine@docker.com>
Signed-off-by: Chad Metcalf <chad@docker.com>
Upstream-commit: 878dcb89f38e8eb7bb07ccd4a4e5ce622252ff30
Component: engine
Add an convenient way to switch --userland-proxy on and off in
integration tests.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Upstream-commit: 44de5fecce9dd194fade1b696e9297ac5c985754
Component: engine
Turns out that `-f` on a file that's in `.dockerignore` actually does work. No idea why it wasn't when I was doing this before, but oh well! 🤘
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
Upstream-commit: 9f5730e131699caaf6f8f6f941d5942d68295055
Component: engine
From the Bash manual's `set -e` description:
(https://www.gnu.org/software/bash/manual/bashref.html#index-set)
> Exit immediately if a pipeline (see Pipelines), which may consist of a
> single simple command (see Simple Commands), a list (see Lists), or a
> compound command (see Compound Commands) returns a non-zero status.
> The shell does not exit if the command that fails is part of the
> command list immediately following a while or until keyword, part of
> the test in an if statement, part of any command executed in a && or
> || list except the command following the final && or ||, any command
> in a pipeline but the last, or if the command’s return status is being
> inverted with !. If a compound command other than a subshell returns a
> non-zero status because a command failed while -e was being ignored,
> the shell does not exit.
Additionally, further down:
> If a compound command or shell function executes in a context where -e
> is being ignored, none of the commands executed within the compound
> command or function body will be affected by the -e setting, even if
> -e is set and a command returns a failure status. If a compound
> command or shell function sets -e while executing in a context where
> -e is ignored, that setting will not have any effect until the
> compound command or the command containing the function call
> completes.
Thus, the only way to have our `.integration-daemon-stop` script
actually run appropriately to clean up our daemon on test/script failure
is to use `trap ... EXIT`, which we traditionally avoid because it does
not have any stacking capabilities, but in this case is a reasonable
compromise because it's going to be the only script using it (for now,
at least; we can evaluate more complex solutions in the future if they
actually become necessary).
The alternatives were much less reasonable. One is to have the entire
complex chains in any script wanting to use `.integration-daemon-start`
/ `.integration-daemon-stop` be chained together with `&&` in an `if`
block, which is untenable. The other I could think of was taking the
body of these scripts out into separate scripts, essentially meaning
we'd need two files for each of these, which further complicates the
maintenance.
Add to that the fact that our `trap ... EXIT` is scoped to the enclosing
subshell (`( ... )`) and we're in even more reasonable territory with
this pattern.
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
Upstream-commit: 929af4c38d8ca4754d2a3ccf087d359bb67c33f3
Component: engine
- every execution of dirname costs time
- less repeating
Signed-off-by: Jörg Thalheim <joerg@higgsboson.tk>
Upstream-commit: 6533cb973f6bab672018148fd6a67644580cc61f
Component: engine
better safe then sorry. especially for rm
Signed-off-by: Jörg Thalheim <joerg@higgsboson.tk>
Upstream-commit: ac20568b0a62c794c0f1190703f051bd1cfac341
Component: engine
