Allows redirects to be authorized if authorization is provided
for the redirected to host. The authorization will always go
to the redirect and never to the referrer.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Currently, the cri-integration tests do not work on Windows due to various reasons.
One of the reasons is because all the tests are using Linux-specific images.
Previous commits refactored the image pulling / usage in the cri-integration tests,
making it easier to update, and easier to configure a custom registry to pull images
with Windows support.
For Windows runs, custom registries can be created, which will also contain Windows
images, and the cri-integration tests can be configured to use those registries by
specifying the "--repo-list" argument, a YAML file which will contain an alternative
mapping of the default registries. This is similar to how E2E tests are handled for
Windows runs in Kubernetes.
Some of the tests are Skipped, as they do not pass yet on Windows.
Windows does not collect inodes used stats, thus, the tests that were expecting non-zero
inodes stats were failing.
Signed-off-by: Claudiu Belu <cbelu@cloudbasesolutions.com>
Packaging systems often want to override the install(1) command via INSTALL
environment variable, in order to do distro specific fixups (eg. splitting
out debug symbols from binaries to separate files).
Also use it for creating install target directories.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Let install-man depend on man, so manpages are really built before
trying to install them.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Note that this is the code in containerd that uses runc (as almost
a library). Please see the other commit for the update to runc binary
itself.
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
This forces vendoring to only take dependencies of this repository to
be taken into account, effectively cutting the circular dependency (for
the vendored code), and to prevent depending on transitive dependencies
coming from older versions of containerd.
go mod does not allow using the main module as a local "replace" rule using
a path; see golang/go#45492 and golang/go#34417, so instead, an empty module
is used.
One change observed is that older versions containerd depended on an older
version of imgcrypt that had an "indirect" dependency on more current versions
of gopkg.in/yaml.v2 and prometheus/procfs.
For those, a temporary "indirect" dependency was added, until prometheus/client_golang
and kubernetes are updated.
from go mod graph (before):
github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba gopkg.in/yaml.v2@v2.4.0
github.com/containerd/imgcrypt@v1.0.4-0.20210301171431-0ae5c75f59ba github.com/prometheus/procfs@v0.6.0
For some reason, some older versions of containerd are still taken into account,
causing satori/go.uuid to be added as "indirect" dependency, likely because some
modules have this dependency in their go.sum. This should likely disappear once
those plugins are updated to contain a current version of containerd.
git grep 'github.com/satori/go.uuid'
vendor/github.com/Microsoft/hcsshim/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
vendor/github.com/containerd/aufs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
vendor/github.com/containerd/imgcrypt/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
vendor/github.com/containerd/nri/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
vendor/github.com/containerd/zfs/go.sum:github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit e26fc84729)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
I noticed AdaptInfo missing test cases. I think this
func a bit important to test since we use this func
in other packages like content, store (walking), etc.
Signed-off-by: Furkan Turkal <furkan.turkal@trendyol.com>
Signed-off-by: Furkan <furkan.turkal@trendyol.com>
This change splits the definition of pkg/cri/os.ResolveSymbolicLink by
platform (windows/!windows), and switches to an alternate implementation
for Windows. This aims to fix the issue described in containerd/containerd#5405.
The previous implementation which just called filepath.EvalSymlinks has
historically had issues on Windows. One of these issues we were able to
fix in Go, but EvalSymlinks's behavior is not well specified on
Windows, and there could easily be more issues in the future, so it
seems prudent to move to a separate implementation for Windows.
The new implementation uses the Windows GetFinalPathNameByHandle API,
which takes a handle to an open file or directory and some flags, and
returns the "real" name for the object. See comments in the code for
details on the implementation.
I have tested this change with a variety of mounts and everything seems
to work as expected. Functions that make incorrect assumptions on what a
Windows path can look like may have some trouble with the \\?\ path
syntax. For instance EvalSymlinks fails when given a \\?\UNC\ path. For
this reason, the resolvePath implementation modifies the returned path
to translate to the more common form (\\?\UNC\server\share ->
\\server\share).
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
(cherry picked from commit b0d3b35b28)
Signed-off-by: Phil Estes <estesp@gmail.com>
