add the ability to build images using files local to the remote-client
but over a varlink interface to a "remote" server.
Signed-off-by: baude <bbaude@redhat.com>
in cases where a container is part of a network namespace, we should
show the network namespace's ports when dealing with ports. this
impacts ps, kube, and port.
fixes: #846
Signed-off-by: baude <bbaude@redhat.com>
When parsing a string name for repo and tag (for images output), we
should be using parsenormalizedname and reference.Canonical to
get the proper output.
Resolves: #2175
Signed-off-by: baude <bbaude@redhat.com>
enable podman-remote push so that users can push images from a
remote client.
change in push API to deal with the need to see output over the
varlink connection.
Signed-off-by: baude <bbaude@redhat.com>
When cleaning up containers, we presently remove the exit file
created by Conmon, to ensure that if we restart the container, we
won't have conflicts when Conmon tries writing a new exit file.
Unfortunately, we need to retain that exit file (at least until
we get a workable events system), so we can read it in cases
where the container has been removed before 'podman run' can read
its exit code.
So instead of removing it, rename it, so there's no conflict with
Conmon, and we can still read it later.
Fixes: #1640
Signed-off-by: Matthew Heon <mheon@redhat.com>
At present, when manually detaching from an attached container
(using the detach hotkeys, default C-p C-q), Podman will still
wait for the container to exit to obtain its exit code (so we can
set Podman's exit code to match). This is correct in the case
where attach finished because the container exited, but very
wrong for the manual detach case.
As a result of this, we can no longer guarantee that the cleanup
and --rm functions will fire at the end of 'podman run' - we may
be exiting before we get that far. Cleanup is easy enough - we
swap to unconditionally using the cleanup processes we've used
for detached and rootless containers all along. To duplicate --rm
we need to also teach 'podman cleanup' to optionally remove
containers instead of cleaning them up.
(There is an argument for just using 'podman rm' instead of
'podman cleanup --rm', but cleanup does have different semantics
given that we only ever expect it to run when the container has
just exited. I think it might be useful to keep the two separate
for things like 'podman events'...)
Signed-off-by: Matthew Heon <mheon@redhat.com>
Image more clearly describes what the type represents.
Also, only include the image name in the `ImageNotFound` error returned
by `GetImage()`, not the full error message.
Signed-off-by: Lars Karlitski <lars@karlitski.net>
This is more consistent and eaiser to parse than the format that
golang's time.String() returns.
Fixes#2260
Signed-off-by: Lars Karlitski <lars@karlitski.net>
when checking for a container's mountpoint, you must lock and sync
the container or the result may be "".
Fixes: #2304
Signed-off-by: baude <bbaude@redhat.com>
Currently we can get into a state where a container exists in
storage but does not exist in libpod. If the user forces a
removal of this container, then we should remove it from storage
even if the container is owned by another tool.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We intend to migrate to the cobra cli from urfave/cli because the
project is more well maintained. There are also some technical reasons
as well which extend into our remote client work.
Signed-off-by: baude <bbaude@redhat.com>
Instead of unconditionally resetting to ContainerStateConfigured
after a reboot, allow containers in the Exited state to remain
there, preserving their exit code in podman ps after a reboot.
This does not affect the ability to use and restart containers
after a reboot, as the Exited state can be used (mostly)
interchangeably with Configured for starting and managing
containers.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
We are missing the equivalence of the docker system commands
This patch set adds `podman system prune`
and `podman system info`
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
addition of import and export for the podman-remote client. This includes
the ability to send and receive files between the remote-client and the
"podman" host using an upgraded varlink connection.
Signed-off-by: baude <bbaude@redhat.com>
if some paths are overriden in the global configuration file, be sure
that rootless podman honors them.
Closes: https://github.com/containers/libpod/issues/2174
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
To get the more-robust handling from 0f6535cf (libpod/image: Use
ParseNormalizedNamed in RepoDigests, 2019-01-08, #2106) here too.
Signed-off-by: W. Trevor King <wking@tremily.us>
The toolbox project would benefit from a few changes to more closely
resembe the original atomic cli project. Changes made are:
* only pull image for container runlabel if the label exists in the image
* if a container image does not have the desired label, exit with non-zero
Signed-off-by: baude <bbaude@redhat.com>
we now, by default, only prune dangling images. if --all is passed, we
prune dangling images AND images that do not have an associated containers.
also went ahead and enabled the podman-remote image prune side of things.
Fixes: #2192
Signed-off-by: baude <bbaude@redhat.com>
initial enablement of podman-remote version. includes add a APIVersion const
that will allow us to check compatibility between host/client when connections
are made.
also added client related information to podman info.
Signed-off-by: baude <bbaude@redhat.com>
add support for ports redirection from the host.
It needs slirp4netns v0.3.0-alpha.1.
Closes: https://github.com/containers/libpod/issues/2081
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This will now verify labels passed in by the user.
Will also prevent users from accidently relabeling their homedir.
podman run -ti -v ~/home/user:Z fedora sh
Is not a good idea.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We try to keep c.config immutable, but Go doesn't really agree
with me that things other than strings and ints can be immutable,
so occasionally things like this slip through.
When unmarshalling the OCI spec from disk, do it into a separate
struct, to ensure we don't make lasting modifications to the
spec in the Container struct (which could affect container
restart).
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
When waiting for a container, there is a long interval between
status checks - plenty long enough for the container in question
to start, then subsequently be cleaned up and returned to Created
state to be restarted. As such, we can't wait on container state
to go to Stopped or Exited - anything that is not Running or
Paused indicates the container is dead.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
We clean up the code by eliminating stuttering references when we embed
the runtime struct into localRuntime. Makes for less change in the future
as well.
++ jhonce
Signed-off-by: baude <bbaude@redhat.com>
Add the ability to run the integration (ginkgo) suite using
the remote client.
Only the images_test.go file is run right now; all the rest are
isolated with a // +build !remotelinux. As more content is
developed for the remote client, we can unblock the files and
just block single tests as needed.
Signed-off-by: baude <bbaude@redhat.com>
we can define multiple OCI runtimes that can be chosen with
--runtime.
in libpod.conf is possible to specify them with:
[runtimes]
foo = [
"/usr/bin/foo",
"/usr/sbin/foo",
]
bar = [
"/usr/bin/foo",
"/usr/sbin/foo",
]
If the argument to --runtime is an absolute path then it is used
directly without any lookup in the configuration.
Closes: https://github.com/containers/libpod/issues/1750
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This deprecates the libpod.conf variable of `runtime_path=`, and now has
`runtimes=`, like a map for naming the runtime, preparing for a
`--runtime` flag to `podman run` (i.e. runc, kata, etc.)
Reference: https://github.com/containers/libpod/issues/1750
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Finally, these members no longer have any users.
Future users should usually call referenceWithRegistry / normalizedReference,
and work with the returned value, instead of reintroducing these variables.
Similarly, direct uses of unnormalizedRef should be rare (only for cases
where the registry and/or path truly does not matter).
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Image.MatchRepoTag and findImageInRepoTags do some kind of
heuristic search; the motivation and design of both, and how they
should deal with digests, is not obvious to me.
Instead of figuring that out now, just factor it out into a
scary-named method and leave the "tag" value (with its "latest"/"none"
value) alone.
Similarly, the .registry and .name fields should typically not be used;
users should use either hasRegistry or normalized reference types;
so, isolate the difficult-to-understand search code, and computation
of these values, into this new search-specific helper.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
imageruntime.getImage, through ParseStoreReference, already uses
reference.TagNameOnly on the input, so this extra lookup is completely
redundant to the lookup that has already happened.
Should not change behavior, apart from speeding up the code a bit.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Instead of returning a string, return a native value and convert it
into the string in the caller, to make it that small bit more
common to use reference types.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Again, rely on the official API, instead of the suprising "suspiciousTagValueForSearch"
value (set to :latest on untagged images, and :none on digested ones!)
CHANGES BEHAVIOR, but the previous output of normalization of digested values was
not even syntatically valid, so this can't really be worse.
Still, maybe we should refuse to tag with digested references in the first place.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This is another step to using reference values instead of strings here.
CHANGES BEHAVIOR: docker.io/busybox is now normalized to docker.io/library/busybox.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This will be used in normalizeTag to work with references instead of strings.
Not used anywhere yet, should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... instead of open-coding something similar. Eventually
we will use the reference type further in here.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This shortens the code a bit, but most importantly ensures that all pulls from
docker.Transport are processed exactly the same way, and there is only a single
store.ParseStoreReference in the pull code.
It's a bit wasteful to call decompose() in getPullRefPair just after
pullGoalFromPossiblyUnqualifiedName has qualified the name, but on balance
only having exactly one code path seems worth it. Alternatively we could
split getPullRefPairToQualifiedDestination from getPullRefPair.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
CHANGES BEHAVIOR.
This bypasses .assemble, and preserves the original
lack of tag / original digest instead of adding :latest/:none
(still subject to ParseStoreReference normalization).
Using the original digest seems clearly correct; dropping the :latest
suffix from .image strings, and adding /library to docker.io/shortname,
only affects user-visible input; later uses of the return value of
pullImageFrom... use ParseStoreReference, which calls reference.ParseNormalizedNamed
and reference.TagNameOnly, so the image name should be processed
the same way whether it contains a tag, or libray/, or not.
This also allows us to drop the problematic hasShaInInputName heuristic/condition/helper.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
CHANGES BEHAVIOR.
This bypasses .assemble, and preserves the original
lack of tag / original digest instead of adding :latest/:none
(still subject to ParseStoreReference normalization).
Using the original digest seems clearly correct; dropping the :latest
suffix from .image strings only affects user-visible input; later
uses of the return value of pullImageFrom... use ParseStoreReference,
which calls reference.TagNameOnly, so the image name should be processed
the same way whether it contains a tag or not.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This is the primary goal of decompose()+assemble(), to support
qualifying an image name.
Does not have any users yet, so does not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
CHANGES BEHAVIOR.
If the name is qualified, instead of decomposing it into components and
re-assembling, just use the input name unmodified:
- For name:tag values, .assemble() just recreates the input.
- For untagged values, .assemble() adds ":latest"; we keep
the input as is, but both docker.ParseReference and storage.Transport.ParseStoreReference
use reference.TagNameOnly() already.
- For digested references, .assemble() adds ":none", but
the code was already bypassing .assemble() on that path
already - for the source reference. For the destination,
this replaces a :none destination with a the @digest reference,
as expected.
Note that while decompose() has already parsed the input,
it (intentionally) bypassed the docker.io/library normalization;
therefore we parse the input again (via docker.ParseReference) to ensure
that the reference is normalized.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Both imageParts and this function implicitly assume docker.Transport
troughout, so instead of pretending to be flexible about DefaultTransport,
just hard-code docker.ParseReference directly.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It is only ever set to DefaulTransport, and all of the code
is docker/reference-specific anyway, so there's no point in
making this a variable.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
After inlining assembleWithTransport, we have two branches with
the same prepending of decomposedImage.transport; move that out of
the branches.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
imageParts.transport is a constant, and the design of imageParts
is not transport-independent in any sense; we will want to eliminate
the transport member entirely.
As a first step, drop assembleWithTransport and inline an exact
equivalent into all callers.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
We will eventually want to eliminate most members of imageParts
in favor of using the c/image/docker/reference API directly.
For now, just record the reference.Named value, and we will
replace uses of the other members before removing them.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Now that DecomposeString has no users, make the type private again.
Any new users of it should come with a rationale - and new users
of the "none"/"latest" handling of untagged/digested names that is
currently implemented should have an exceptionaly unusual rationale.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
- It is used to fill Repository(misnamed)/Tag members which have no users;
so it's completely unclear why this is useful.
- Given the mishandling of tags by imageParts.tag, at the very least
all new code should primarily use reference.Named (even if
after a decompose() to internally deal with unqualified names first),
introducing new uses of original decompose() just reintroduces known
trouble - so without any provided rationale, reverting seems
a reasonable default action.
- This drags in all of libpod/image into the "remote client" build,
which seems undesirable.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Read the $PODMAN_VARLINK_BRIDGE environment variable
(normally looks like: "ssh user@host varlink bridge")
Also respect $PODMAN_VARLINK_ADDRESS as an override,
if using a different podman socket than the default.
Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
The json-iterator package will panic on attempting to use
MarshalIndent with a non-space indentation. This is sort of silly
but swapping from tabs to spaces is not a big issue for us, so
let's work around the silly panic.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
The jsoniter library does not require code generation, which is a
massive advantage over easyjson (it's also about the same in
performance). Begin moving over to it by removing the existing
easyjson code.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
If we are not able to make arbitrary changes to the RLIMIT_NOFILE when
lacking CAP_SYS_RESOURCE, don't fail but bump the limit to the maximum
allowed. In this way the same code path works with rootless mode.
Closes: https://github.com/containers/libpod/issues/2123
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Avoid generating
quay.io/openshift-release-dev/ocp-release@sha256@sha256:239... and
similar when the image name is already digest-based [1]. It's not
clear exactly how we get into this state, but as shown by the unit
tests, the new code handles this case correctly (while the previous
code does not).
[1]: https://github.com/containers/libpod/issues/2086
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #2106
Approved by: rhatdan
Apply the default AppArmor profile at container initialization to cover
all possible code paths (i.e., podman-{start,run}) before executing the
runtime. This allows moving most of the logic into pkg/apparmor.
Also make the loading and application of the default AppArmor profile
versio-indepenent by checking for the `libpod-default-` prefix and
over-writing the profile in the run-time spec if needed.
The intitial run-time spec of the container differs a bit from the
applied one when having started the container, which results in
displaying a potentially outdated AppArmor profile when inspecting
a container. To fix that, load the container config from the file
system if present and use it to display the data.
Fixes: #2107
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
The initial implementation to request the same IP address for a
container during a restore was based on environment variables
influencing CNI.
With this commit the IP address selection switches to Podman's internal
static IP API.
This commit does a comment change in libpod/container_easyjson.go to
avoid unnecessary re-generation of libpod/container_easyjson.go during
build as this fails in CI. The reason for this is that make sees that
libpod/container_easyjson.go needs to be re-created. The commit,
however, only changes a part of libpod/container.go which is marked as
'ffjson: skip'.
Signed-off-by: Adrian Reber <areber@redhat.com>
There's been a lot of discussion over in [1] about how to support the
NVIDIA folks and others who want to be able to create devices
(possibly after having loaded kernel modules) and bind userspace
libraries into the container. Currently that's happening in the
middle of runc's create-time mount handling before the container
pivots to its new root directory with runc's incorrectly-timed
prestart hook trigger [2]. With this commit, we extend hooks with a
'precreate' stage to allow trusted parties to manipulate the config
JSON before calling the runtime's 'create'.
I'm recycling the existing Hook schema from pkg/hooks for this,
because we'll want Timeout for reliability and When to avoid the
expense of fork/exec when a given hook does not need to make config
changes [3].
[1]: https://github.com/opencontainers/runc/pull/1811
[2]: https://github.com/opencontainers/runc/issues/1710
[3]: https://github.com/containers/libpod/issues/1828#issuecomment-439888059
Signed-off-by: W. Trevor King <wking@tremily.us>
baude