* Detection via /etc/SuSE-brand
* Currently only supporting version 13.1 (This apparently
ships no systemd-networkd and has no wicked yet.)
* Introduced ct_modify_file_head_portion: Both Redhat and
SuSE have separate route files for network interfaces, but
with a different formats. For consistency the SuSE code also
only changes routes between the BEGIN/END PVE comment lines.
This version also fixes a bug where the route file got
deleted instead of left untouched when no changes were made
(now caught by a testcase).
create: don't skip arch detection on unpack errors
The -ignore-unpack-errors option needs to be taken into
account in restore_archive instead of restore_and_configure
as restore_archive is also responsible for arch detection.
For now only Fedora 22 is tested. The setup routines from
the Redhat base can be kept, so the only difference for now
is the version scheme and 'ostype'.
Otherwise this runs through the code causing all kinds of
different errors like use of uninitialized values in
peculiar places or format errors trying to validate empty
string or 'missing property' errors trying to parse empty
property strings...
When using the 'storage:size' notation to allocate a disk we
only modify the volume id, so it makes sense to just update
this along with the size rather than creating a new hash
which would drop extra parameters such as 'backup=yes'.
vzdump: exclude lost+found with unprivilged containers
The lost+found directory is created by mkfs and fsck with
the absolute numeric owner of 0:0 which causes tar on an
unprivileged container to error when trying to read it, so
it needs to be excluded un-anchored.
This doesn't need to be done for rsync as rsync runs as
privileged root.
rsync treats --exclude as anchored when they start with
a slash which they do, and which is our desired behavior,
so we should also include --anchored for our tar command.
honor backup=yes/no for bind and device mountpoints
Initially we skipped bind and device mountpoints because we
didn't start out with a backup property. Now that it is
available it is more appropriate to give control back to the
user. The default is 'off' anyway.
To avoid having to use the ^/ and ^/dev/ regexes which are
easy to forget about there's now a 'type' property on
mountpoints which classify them via names, for now including
"volume", "bind" and "device".
The NETWORKING and NETWORKING_IPV6 variables are now setup
in setup_network instead of set_hostname, which now only
sets the hostname.
This changes the variable order so the testcase had to be
adapted.
Note that the HOSTNAME update s// now uses \h instead of \s
for horizontal spaces so it doesn't eat up newlines at the
end of file (caught by the testcase).
In some cases the user may genuinly want to ignore unpacking
errors. (Like permission denied errors on mknod commands in
some templates where the user might choose to work around
the problem manually in the running container.)
This was added before we had bind mounts, instead we now
change ownership when creating disks by passing the
`root_owner` option to mkfs or activating+chown()ing the
paths for subvolumes.
The rationale here is simply that if the host can see all
the mounts, then any program on the host entering a new
mount namespace can keep the mountpoints active.
This can potentially lead to hard-to-track problems with
multiple mount protection or NFS storages not syncing to the
end when stop-migrating a container to another node.
This flag (like lxc.id_map entries) should only be set at
create-time in order to make sure the container's filesystem
has the correct ownerships and permissions.
For this reason modification is not allowed via the API.
An unprivileged containers defines lxc.id_map properties,
and includes $ostype.userns.conf in addition to
$ostype.common.conf in its lxc config.
when an id_map is configured for the container or the
unprivileged flag set (which implies the default userid
map), the file access wrappers (LXC::Setup::Plugin::ct_*
functions) will use the id_map to fixup ownership of created
files.
POSIX capabilities are stored as security.capability xattr.
The --xattrs option alone won't store anything outside the
usernamespace, so we have to specifically ask for this
capability to be included when calling tar.
Note that we deliberately don't store the entire security
namespace as labeling by xattr is common with some security
modules and possibly a planned apparmor feature, too, so
this way we avoid restoring arbitrary lables from dumps and
templates we might not want.
Since these flags are used in two separate files I moved
them to @$PVE::LXC::COMMON_TAR_FLAGS;
The --acls flag for tar (and -A flag for rsync) have also
been added.
Run df on /proc/$pid/root instead of attaching to the
container and running its contained 'df' binary, as this
could create freezed processes of the container is frozen.
Also, since the container PIDs are now used in both loops
they're precached beforehand.
Move ip_is_in_cidr checks on $d->{gw} into the
defined($d->{gw}) guarded if block to avoid warnings and
useless route files being created when using dhcp.
restore: delete config from container after restore
We don't need to leave /etc/vzdump/pct.conf or vps.conf in
the container's directory structure after using it, it only
causes the next backup to have the file twice in the
archive.
restore: make sure only the first pct.conf is extracted
When making a stop/snapshot mode backup of a container that
was already restored from a backup, its /etc/vzdump/pct.conf
file was replacing our newly created one in the archive. We
need to prevent the duplicate file from overwriting our new
one.
redhat: don't use aliases for dual stack networking
A static IPv6 as alias interface for ipv4 doesn't work (RH
has "secondaries" for that), DHCP on aliases doesn't work
either.
The only drawback of putting both in the same file is that
static addresses take longer to be configured if the DHCP
server is slow.
projects / pve-container.git / log