we only handled the special rootfs mount so creating a template
from a container with additional mountpoint did not work correctly.
Use foreach_mountpoint to create a base vdisk for all mount points
after checking if the storage supports it
otherwise the size information gets lost when detaching and reattaching
a mountpoint volume, which is less than ideal since mountpoints without
size information require manual information when restoring.
This finishes the work started with 07084526aa4a ("create:
open templates as real root"), which opened templates as
real root, but passed it to tar via /proc/*/fd, which does
not actually bypass the check. (Curiously tar did manage to
figure out the file extension from it).
In order to actually extract templates the unprivileged user
cannot access by themselves, we need to pass it to tar via
stdin, however, this means tar cannot auto-detect the
compression (or more accurately, it can and does, but tells
you which option to pass it rather than just extracting
it...)
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
systemd-networkd keeps trying to use keyctl() and if it
refuses to work it is apparently a fatal error, so let's
make it think keyctl() support doesn't actually exist by
letting it always fail with ENOSYS.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Alwin Antreich [Wed, 14 Mar 2018 12:51:55 +0000 (13:51 +0100)]
Fix pct skiplock
The method vm_start sets an environment variable that is not picked up
anymore by systemd. This patch removes the environment variable and
introduces a skiplock file that is picked up by the
lxc-pve-prestart-hook.
Alwin Antreich [Fri, 9 Mar 2018 15:14:59 +0000 (16:14 +0100)]
Fix #1547: on migration abort, the CT starts again
When a migration fails, the final_cleanup phase now starts the container
on the source node again, if it was a migration in restart_mode and the
CT was running.
Thomas Lamprecht [Fri, 16 Feb 2018 07:40:48 +0000 (08:40 +0100)]
close #1668: add Devuan support
Add separate Plugin as the Debian Plugin will get more systemd
specific stuff in the future, while this here is as anti-systemd as
it gets, so make the split from the start.
But only overwrite the plugin constructor for now, the rest is still
backward compatible.
Short nack history:
In PVE 4 Beta we introduced LXC as our new container technology.
Initially we did not used the our section config format for its
configuration file in /etc/pve . It was then decided to reuse our
config format (section config), so that we do not need to maintain a
separate parser, and that VM and CT config where not completely
different, which could confuse users.
This script was added to allow an easy transition from the old LXC
config format to the new Proxmox SectionConfig one.
All new installations since, and including, PVE 4.0 never needed this.
And all beta users must go through PVE 4.4 if they want to
dist-upgrade to PVE 5.0, so just remove it - it's forever tracked in
git anyway
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Thu, 16 Nov 2017 14:07:40 +0000 (15:07 +0100)]
create: refactor arch detection to run_fork_with_timeout
Swap out our own fork/waitpid code with run_fork_with_timeout, which
not only allows to return arbitrary results from the called method
but also has a timeout configured, which prevents that a creation
hangs forever (= next reboot).
As we can now return more than with an exit code number we do not
return the ELF class but the detected architecture directly and pull
the fallback code into this method.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Since we use a post-stop hook to unmount all file systems at
container shutdown rather than a stop hook (because at this
point there are still multiple mount namespaces around), we
need to wait for the lxc-start/monitor process to exit to be
sure all the unmounting has succeeded, because it will put
the container into a STOPPED state before executing the
post-stop hook, making lxc-wait and lxc-stop signal success
too early when waiting for the container to stop.
Introduce a vm_stop() helper which calls lxc-stop and then
waits for the command socket to close. Note that lxc-stop
already has the "hard-stop-after-timeout" mechanic built in,
so the 'forceStop' code path of the vm_stop api call removed
here was not actually necessary.
Technically we could pass --nokill for the behavior assumed
there, but for now this patch should not be causing any
actual behavior changes.
We changed this to read values from the container's inner
cgroup, but didn't take into account that unprivileged
containers don't have one.
Add a parameter to specify whether it is an unprivileged
container.
Fixes: 41ef9833bf00 ("include ns/ dir in read_cgroup_value") Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
we want our unit to only start when manually invoked (by our code), and
stop on shutdown via pve-guests or pve-ha-lrm. lxc@ units are stopped by
systemd on shutdown, because of transitive dependencies.
since all instances of template service units are by default assigned to
a new slice with DefaultDependencies=yes, we also need to introduce our
own custom slice with DefaultDependencies=no.
With 2.1 a bunch of keys were renamed for consistency, and
network interface configuration is now done with explicit
indices.
Since we allow various custom "lxc.*" keys in our container
configuration we need to deal with this change and we now
inform the user about this with a warning.
API/clone: do not overwrite global signal handlers
perls 'local' must be either used in front of each $SIG{...}
assignments or they must be put in a list, else it affects only the
first variable and the rest are *not* in local context.
This may cause weird behaviour where daemons seemingly do not get
terminating signals delivered correctly and thus may not shutdown
gracefully anymore.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Philip Abernethy [Wed, 23 Aug 2017 15:04:37 +0000 (17:04 +0200)]
close #1478: add check for unsupported config
Adds a check if an unprivileged container is configured to use
quota on any of its mountpoints. If so an understandable error
message is given. Ideally I'd like to catch those
configurations on the GUI, too, to avoid users just running
into it.
SLES 12 shares its base with opensuse leap, so we shouldn't get into
much trouble here.
I copied the os-release file from a SLES installation.
I didn't found official SLES CT/rootfs images, people with access to
the repos should be able to create them.
Fixes: #1464 Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
setup/suse: check early if setting up the ct getty service is needed
Explixitly set if we need to call setup_container_getty_service(), as
its more expressive, especially with suse version jumping in mind.
Also next patches will add support for other opensuse based releases
(tumbleweed, sles).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
setup/suse: use new os_release_var to simplify version detection
Not only simplify but also correct version detection.
Until now we checked the files 'SuSE-release' and 'SuSE-brand' for
version parsing. 'SuSE-release' is marked as obsolete and replaced by
the newer standarised 'os-release', and the fallback is plain wrong
and not guaranteed to exist or match the actual version.
'SuSE-brand' does not get supplied by the 'openSUSE-release' package
but by another package, i.e. 'branding-openSUSE' this isn't
guaranteed to be installed, at least on CT creation, and may have
another version as the actual template provides. E.g. on tumbleweed I
get version 13.3 there, while the release package tells me "20170729".
As "os-release" is available at least sine openSUSE 12.2, and we
support 13.X and newer currently, just use it instead.
Adapt the regex as the non-rolling releases have always a X.Y format.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This should exist everywhere, its content look like shell
assignments but are limited enough to not require a shell to
parse (see os-release(5) or its parts pasted as a comment to
the parse function).
Further motivation for this is the fact that in suse the
/etc/SuSE-release file is declared deprecated in favor of
/etc/os-release.
Note that we have to read the file in a protected_call to
avoid symlink issues.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
projects / pve-container.git / log