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>
To ensure manifest integrity when pulling by digest, this changeset ensures
that not only the remote digest provided by the registry is verified but also
that the digest provided on the command line is checked, as well. If this check
fails, the pull is cancelled as with an error. Inspection also should that
while layers were being verified against their digests, the error was being
treated as tech preview image signing verification error. This, in fact, is not
a tech preview and opens up the docker daemon to man in the middle attacks that
can be avoided with the v2 registry protocol.
As a matter of cleanliness, the digest package from the distribution project
has been updated to latest version. There were some recent improvements in the
digest package.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
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>
The DOCKER_EXPERIMENTAL environment variable drives the activation of
the 'experimental' build tag.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
If a container was started with a non-root user the container
may not be able to resolve DNS names because of too restrictive
permission in the /etc/resolv.conf container file. This problem
is in how this file gets created in libnetwork and ths PR
attempts to fix the issue by vendoring in the libnetwork code
with the fix.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Previously, we've taken advantage of the fact that libcontainer's `update-vendor.sh` is the same syntax as Docker's `vendor.sh` with some shell magic. This changes that to copy libcontainer's dependencies into this file explicitly so that we can scale to more projects with varying methods of vendoring (assuming they don't use import re-writing, which screws up everyone).
We'll need to stay diligent in making sure this list matches what's in libcontainer's `update-vendor.sh` (minus the not-required codegangsta/cli dep), but that's a fair trade-off for being able to scale our dependency model better (and track new discrete dependencies more directly).
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
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>
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>
To help avoid version mismatches between libcontainer and Docker, this updates libcontainer to be the source of truth for which version of logrus the project is using. This should help avoid potential incompatibilities in the future, too. 👍
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
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>
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>
https://www.kali.org/ is a Debian derivative. This script completes
succesfully using the Debian install path
Signed-off-by: Andrew Martin <sublimino@gmail.com>
libdm started offering deferred remove functionality from version
1.02.89. As docker still builds against older libdm, define a tag
libdm_no_deferred_remove to determine whether we are compiling
against new libdm or older one and enable/disable deferred remove
functionality accordingly.
Signed-off-by: Vincent Batts <vbatts@redhat.com>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
This is a symlink to the latest "bundle" that was assembled. For example, if `VERSION` is currently `1.5.0-dev`, then `bundles/latest` will be a symlink to `bundles/1.5.0-dev` after an attempted build.
One interesting property of this is that after a successful `binary` build, we can `./bundles/latest/binary/docker -v` and get back something like `Docker version 1.5.0-dev, build 3ff6723-dirty`.
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
This will assure that the install script will not
begin executing until after it has been downloaded should
it be utilized in a 'curl | bash' workflow.
Signed-off-by: Eric Windisch <eric@windisch.us>
Docker does not know about our named cpuacct,cpu,cpuset cgroup
hierarchy with multiple subsystems in it. So to use them with docker
in integration-cli test TestRunWithCpuset inside docker container
we need to add symlinks to them in hack/dind script.
Example:
old version of parser will do:
cat /proc/1/cgroup
11:cpu,cpuacct,name=my_cpu_cpuacct:/
...
and create and mount this hierarchy to directory
/cgroup/cpu,cpuacct,name=my_cpu_cpuacct/
so docker cannot find it because it has strange name
in new parser directory will be same as on host
/cgroup/my_cpu_cpuacct
and have symlinks for docker to find it
/cgroup/cpu -> /cgroup/my_cpu_cpuacct
/cgroup/cpuacct -> /cgroup/my_cpu_cpuacct
in other case if where is no name
cat /proc/1/cgroup
11:cpu,cpuacct:/
...
mount will be same for both parsers
/cgroup/cpu,cpuacct
and new one will also create symlinks
/cgroup/cpu -> /cgroup/cpu,cpuacct
/cgroup/cpuacct -> /cgroup/cpu,cpuacct
Signed-off-by: Pavel Tikhomirov <ptikhomirov@parallels.com>
Phil Estes
Arnaud Porterie
David Calavera
Alexey Guskov
Jessie Frazelle
Aidan Hobson Sayers
Tianon Gravi
Stephen J Day
Alexander Morozov
Jessica Frazelle
Jana Radhakrishnan
boucher
Sebastiaan van Stijn
Madhu Venugopal
John Howard
Qiang Huang
Michael Crosby
Tibor Vass
Alexander Morozov
Jörg Thalheim
Vincent Batts
Patrick Devine
unclejack
moxiegirl
Antonio Murdaca
Doug Davis
Andrew Martin
Vivek Goyal
Yahya
Tatsushi Inagaki
Michael Crosby
Jessica Frazelle
bobby abbott
Evan Hazlett
Eric Windisch
Johan Euphrosine
Aaron Welch
Derek McGowan
Pavel Tikhomirov