As we link statically with liblxc, we don't need to
link with liblxc_ext_sources, as all the symbols will come
from liblxc.a itself.
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Our main branch is "main" for some time, but
in github scripts we still use "master" which is incorrect
and prevent some stuff from working.
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Put a bunch of functions under #if IN_LIBLXC to compile-out
them when network.c is linked with tools/tests code.
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
This helper is used in the lxc/tools and it's
fully independent of storage_utils code, let's move it
to utils.c
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Move some idmaps-related functions from lxc/conf.c
to a new idmap_utils.c file.
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Let's unhide lxc_config_define_add, lxc_config_define_load and
lxc_config_define_free helpers. These functions are safe enough
to be used by external tools. Semantic is also clear.
Reason is that we have lxc-start/lxc-execute tools which
use these symbols. Right now it works, because we just
link a whole liblxc statically to each lxc-* tool...
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
The purpose of it is to tell us if we are compiling
liblxc or lxc test/tool/command.
This thing is needed to exclude unnecessary functions
from being compiled-in in the resulting executables
like lxc-start, lxc-attach, etc.
The problem is that lxc tools (lxc-start, lxc-stop, etc)
depend not only on the liblxc as a shared library, but also
require some non-exported symbols or helpers from liblxc
internals. So, we have to link these executables with some liblxc
object files directly which results in the dependency hell,
because linking one .c file from liblxc may end up having to
link with another one (what contains some dependency) and so on.
By using IN_LIBLXC in the liblxc internals we can selectively
omit some functions from being compiled in such cases.
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
lxc_fill_elevated_privileges() is used only in lxc-attach tool,
let's move this function in there.
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
We have removed the same piece of code in
ec85e5ca49 ("lxc-test-usernic: drop cgroup handling")
let's do the same for two other tests.
This fixes autopkgtests.
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
lxc-copy can start container as lxc-start does in some cases,
so we need to have the same profile for it.
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
This commit addresses an issue in the OCI template where lxc-create
fails if OCI-cache directory for blob caching is not on the same mount
as the destination OCI directory. lxc-create bails when skopeo tries to
create a hard-link across the two and fails.
For example, if /var/lib/lxc is a bind mountpoint of a random directory
and skopeo fails to hard-link across /var/cache/lxc and /var/lib/lxc
This commit introduces a check where if both directories are on not the
same mount points, it disables blob caching in skopeo and continues.
Signed-off-by: Tanmay Naik <tnaik96@gmail.com>
This stuff is not needed in a modern systemd based system, and in fact
breaks. It would probably be better to detect such a system so that a
non-systemd box can still run this test. But I'm not sure what would be
reliable.
Signed-off-by: Serge Hallyn <serge@hallyn.com>
ifconfig is not available on many modern systems. Use ip instead.
Maybe it would be better to detect what's available, but that
could become brittle.
Signed-off-by: Serge Hallyn <serge@hallyn.com>
Update tar invocation to preserve all xattrs when unpacking the rootfs,
notably retaining security.capability xattrs (e.g. for ping, newuidmap)
Note: bsdtar already preserves xattrs with -p
Signed-off-by: Jacob McNamee <jacob@jacobmcnamee.com>
In our current codebase we have a logical pattern:
list_empty(&handler->conf->id_map)
*IF AND ONLY IF*
container does NOT use user namespace
Which is perfectly correct nowadays, but once we (hopefully)
get an "isolated user namespaces" stuff ready it won't be the case.
It will be perfectly fine to have a user namespace with empty
/proc/*/{u,g}id_map files. Nowadays it's also possible,
but this kind of a configuration close to useless and nobody
actually uses it.
No functional changes intended.
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
No functional changes.
Will be useful in future support for an isolated
user namespaces [1]. I have already played with
that locally and found that in the LXC codebase
we have a bunch of different ways to ensure if
a container uses user namespaces or not.
This commit contains a trivial conversion from
an open-coded version of the container_uses_namespace()
helper to an actual use of the helper.
[1] https://lpc.events/event/17/contributions/1569/
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
