Introduce `ex livefs`
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639
Closes: #652
Approved by: jlebon
2017-03-01 01:16:48 +03:00
#!/bin/bash
#
# Copyright (C) 2017 Red Hat Inc.
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this library; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
2017-10-01 16:34:23 +03:00
set -euo pipefail
Introduce `ex livefs`
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639
Closes: #652
Approved by: jlebon
2017-03-01 01:16:48 +03:00
. ${ commondir } /libtest.sh
. ${ commondir } /libvm.sh
set -x
2018-06-27 15:23:05 +03:00
# We do various assertions on deployment length, need a reliably
# clean slate.
vm_rpmostree cleanup -pr
Introduce `ex livefs`
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639
Closes: #652
Approved by: jlebon
2017-03-01 01:16:48 +03:00
vm_assert_layered_pkg foo absent
2020-11-17 04:53:06 +03:00
vm_cmd rpm -qa | sort > original-rpmdb.txt
2017-06-29 17:11:25 +03:00
vm_build_rpm foo
2020-10-24 20:31:39 +03:00
vm_build_rpm bar
2018-09-06 23:09:04 +03:00
vm_rpmostree install /var/tmp/vmcheck/yumrepo/packages/x86_64/foo-1.0-1.x86_64.rpm
Introduce `ex livefs`
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639
Closes: #652
Approved by: jlebon
2017-03-01 01:16:48 +03:00
vm_assert_status_jq '.deployments|length == 2'
echo "ok install foo locally"
if vm_cmd rpm -q foo; then
assert_not_reached "have foo?"
fi
2020-11-17 04:53:06 +03:00
vm_rpmostree status > status.txt
assert_not_file_has_content_literal status.txt 'LiveDiff'
2018-07-13 18:52:27 +03:00
vm_assert_status_jq '.deployments|length == 2' \
'.deployments[0]["live-replaced"]|not' \
Introduce `ex livefs`
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639
Closes: #652
Approved by: jlebon
2017-03-01 01:16:48 +03:00
'.deployments[1]["live-replaced"]|not'
2020-10-24 20:31:39 +03:00
vm_rpmostree ex livefs
Introduce `ex livefs`
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639
Closes: #652
Approved by: jlebon
2017-03-01 01:16:48 +03:00
vm_cmd rpm -q foo > rpmq.txt
assert_file_has_content rpmq.txt foo-1.0-1
2020-10-24 20:31:39 +03:00
vm_cmd ls -al /usr/bin/foo
vm_assert_status_jq '.deployments|length == 2' '.deployments[0]["live-replaced"]|not' \
'.deployments[1]["live-replaced"]'
if vm_cmd test -w /usr; then
fatal "Found writable /usr"
fi
2020-11-17 04:53:06 +03:00
vm_rpmostree status > status.txt
assert_file_has_content_literal status.txt 'LiveDiff: 1 added'
vm_rpmostree status -v > status.txt
assert_file_has_content_literal status.txt 'LiveAdded:'
2020-10-24 20:31:39 +03:00
echo "ok livefs basic"
vm_rpmostree cleanup -p
vm_rpmostree install bar
vm_assert_status_jq '.deployments|length == 2' \
'.deployments[0]["live-replaced"]|not' \
Introduce `ex livefs`
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639
Closes: #652
Approved by: jlebon
2017-03-01 01:16:48 +03:00
'.deployments[1]["live-replaced"]'
2020-10-24 20:31:39 +03:00
vm_rpmostree ex livefs
vm_cmd rpm -qa > rpmq.txt
assert_file_has_content rpmq.txt bar-1.0-1
assert_not_file_has_content rpmq.txt foo-1.0-1
vm_cmd ls -al /usr/bin/bar
if vm_cmd test -f /usr/bin/foo; then
fatal "Still have /usr/bin/foo"
fi
2020-11-17 04:53:06 +03:00
vm_rpmostree status > status.txt
assert_file_has_content_literal status.txt 'LiveDiff: 1 added'
Introduce `ex livefs`
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639
Closes: #652
Approved by: jlebon
2017-03-01 01:16:48 +03:00
2020-10-24 20:31:39 +03:00
echo "ok livefs again"
Introduce `ex livefs`
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639
Closes: #652
Approved by: jlebon
2017-03-01 01:16:48 +03:00
2017-06-29 17:11:25 +03:00
vm_build_rpm test-livefs-with-etc \
build 'echo "A config file for %{name}" > %{name}.conf' \
2017-07-11 08:12:47 +03:00
install ' mkdir -p %{ buildroot} /etc
install %{ name} .conf %{ buildroot} /etc
2017-06-29 17:11:25 +03:00
mkdir -p %{ buildroot} /etc/%{ name} /
echo subconfig-one > %{ buildroot} /etc/%{ name} /subconfig-one.conf
echo subconfig-two > %{ buildroot} /etc/%{ name} /subconfig-two.conf
mkdir -p %{ buildroot} /etc/%{ name} /subdir
echo subconfig-three > %{ buildroot} /etc/%{ name} /subdir/subconfig-three.conf
mkdir -p %{ buildroot} /etc/opt
echo file-in-opt-subdir > %{ buildroot} /etc/opt/%{ name} -opt.conf' \
files " /etc/%{name}.conf
/etc/%{ name} /*
/etc/opt/%{ name} *"
2017-09-15 19:53:30 +03:00
# Simulate a service that adds a user and has data in tmpfiles.d
vm_build_rpm test-livefs-service \
build "echo test-livefs-service > test-livefs-service.txt" \
install " mkdir -p %{buildroot}/{usr/share,var/lib/%{name}}
install test-livefs-service.txt %{ buildroot} /usr/share" \
pre " groupadd -r livefs-group
useradd -r livefs-user -g livefs-group -s /sbin/nologin" \
files " /usr/share/%{name}.txt
/var/lib/%{ name} "
2017-07-04 20:06:53 +03:00
# make sure there are no config files already present
vm_cmd rm -rf /etc/test-livefs-with-etc \
/etc/test-livefs-with-etc.conf \
/etc/opt/test-livefs-with-etc-opt.conf
2018-09-06 23:09:04 +03:00
vm_rpmostree install /var/tmp/vmcheck/yumrepo/packages/x86_64/test-livefs-{ with-etc,service} -1.0-1.x86_64.rpm
2020-10-24 20:31:39 +03:00
vm_rpmostree ex livefs
vm_cmd rpm -q bar test-livefs-{ with-etc,service} > rpmq.txt
assert_file_has_content rpmq.txt bar-1.0-1 test-livefs-{ with-etc,service} -1.0-1
Introduce `ex livefs`
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639
Closes: #652
Approved by: jlebon
2017-03-01 01:16:48 +03:00
vm_cmd cat /etc/test-livefs-with-etc.conf > test-livefs-with-etc.conf
assert_file_has_content test-livefs-with-etc.conf "A config file for test-livefs-with-etc"
2017-05-23 18:26:40 +03:00
for v in subconfig-one subconfig-two subdir/subconfig-three; do
vm_cmd cat /etc/test-livefs-with-etc/${ v } .conf > test-livefs-with-etc.conf
assert_file_has_content_literal test-livefs-with-etc.conf $( basename $v )
done
vm_cmd cat /etc/opt/test-livefs-with-etc-opt.conf > test-livefs-with-etc.conf
assert_file_has_content test-livefs-with-etc.conf "file-in-opt-subdir"
2017-09-15 19:53:30 +03:00
# Test /usr/lib/{passwd,group} bits
vm_cmd getent passwd livefs-user > test-livefs-user.txt
assert_file_has_content test-livefs-user.txt livefs-user
vm_cmd getent group livefs-group > test-livefs-group.txt
assert_file_has_content test-livefs-group.txt livefs-group
# Test systemd-tmpfiles
vm_cmd test -d /var/lib/test-livefs-service
Introduce `ex livefs`
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639
Closes: #652
Approved by: jlebon
2017-03-01 01:16:48 +03:00
2020-11-17 04:53:06 +03:00
vm_rpmostree status > status.txt
assert_file_has_content_literal status.txt 'LiveDiff: 3 added'
Introduce `ex livefs`
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639
Closes: #652
Approved by: jlebon
2017-03-01 01:16:48 +03:00
echo "ok livefs stage2"
2020-11-17 04:53:06 +03:00
# Now undo it all
2020-12-12 21:52:23 +03:00
vm_rpmostree ex apply-live --reset
2020-11-17 04:53:06 +03:00
vm_cmd rpm -qa | sort > current-rpmdb.txt
diff -u original-rpmdb.txt current-rpmdb.txt
if vm_cmd test -f /usr/bin/bar; then
fatal "Still have /usr/bin/bar"
fi
vm_rpmostree status > status.txt
assert_not_file_has_content_literal status.txt 'LiveDiff:'
echo "ok livefs reset"