pve-manager/debian/postinst

203 lines
7.0 KiB
Plaintext
Raw Normal View History

#!/bin/sh
2011-08-23 07:40:22 +02:00
# Abort if any command returns an error value
set -e
# This script is called as the last step of the installation of the
# package. All the package's files are in place, dpkg has already
# done its automatic conffile handling, and all the packages we depend
# of are already fully installed and configured.
set_lvm_conf() {
LVM_CONF_MARKER="# added by pve-manager to avoid scanning"
# only do these changes once
# keep user changes afterwards provided marker is still there..
if ! grep -qLF "$LVM_CONF_MARKER" /etc/lvm/lvm.conf; then
OLD_VALUE="$(lvmconfig --typeconfig full devices/global_filter)"
NEW_VALUE='global_filter=["r|/dev/zd.*|"]'
export LVM_SUPPRESS_FD_WARNINGS=1
# check global_filter
# keep previous setting from our custom packaging if it is still there
if echo "$OLD_VALUE" | grep -qvF 'r|/dev/zd.*|'; then
SET_FILTER=1
BACKUP=1
fi
# should be the default since bullseye
if lvmconfig --typeconfig full devices/scan_lvs | grep -qv 'scan_lvs=0'; then
SET_SCAN_LVS=1
BACKUP=1
fi
if test -n "$BACKUP"; then
echo "Backing up lvm.conf before setting pve-manager specific settings.."
cp -vb /etc/lvm/lvm.conf /etc/lvm/lvm.conf.bak
fi
if test -n "$SET_FILTER"; then
echo "Setting 'global_filter' in /etc/lvm/lvm.conf to prevent zvols from being scanned:"
echo "$OLD_VALUE => $NEW_VALUE"
# comment out existing setting
sed -i -e 's/^\([[:space:]]*global_filter[[:space:]]*=\)/#\1/' /etc/lvm/lvm.conf
# add new section with our setting
cat >> /etc/lvm/lvm.conf <<EOF
devices {
$LVM_CONF_MARKER ZFS zvols
$NEW_VALUE
}
EOF
fi
if test -n "$SET_SCAN_LVS"; then
echo "Adding scan_lvs=0 setting to /etc/lvm/lvm.conf to prevent LVs from being scanned."
# comment out existing setting
sed -i -e 's/^\([[:space:]]*scan_lvs[[:space:]]*=\)/#\1/' /etc/lvm/lvm.conf
# add new section with our setting
cat >> /etc/lvm/lvm.conf <<EOF
devices {
$LVM_CONF_MARKER LVM volumes
scan_lvs=0
}
EOF
fi
fi
}
2011-08-23 07:40:22 +02:00
case "$1" in
triggered)
# We don't print a status message here, as dpkg already said
# "Processing triggers for ...".
# test if /etc/pve is mounted; else simple exit to avoid
# error during updates
test -f /etc/pve/local/pve-ssl.pem || exit 0;
2015-02-28 12:42:20 +01:00
test -e /proxmox_install_mode && exit 0;
# the ExecStartPre doesn't triggers on service reload, so just in case
pvecm updatecerts --silent || true
deb-systemd-invoke reload-or-try-restart pvedaemon.service
deb-systemd-invoke reload-or-try-restart pvestatd.service
deb-systemd-invoke reload-or-try-restart pveproxy.service
deb-systemd-invoke reload-or-try-restart spiceproxy.service
replace systemd timer with pvescheduler daemon The whole thing is already prepared for this, the systemd timer was just a fixed periodic timer with a frequency of one minute. And we just introduced it as the assumption was made that less memory usage would be generated with this approach, AFAIK. But logging 4+ lines just about that the timer was started, even if it does nothing, and that 24/7 is not to cheap and a bit annoying. So in a first step add a simple daemon, which forks of a child for running jobs once a minute. This could be made still a bit more intelligent, i.e., look if we have jobs tor run before forking - as forking is not the cheapest syscall. Further, we could adapt the sleep interval to the next time we actually need to run a job (and sending a SIGUSR to the daemon if a job interval changes such, that this interval got narrower) We try to sync running on minute-change boundaries at start, this emulates systemd.timer behaviour, we had until now. Also user can configure jobs on minute precision, so they probably expect that those also start really close to a minute change event. Could be adapted to resync during running, to factor in time drift. But, as long as enough cpu cycles are available we run in correct monotonic intervalls, so this isn't a must, IMO. Another improvement could be locking a bit more fine grained, i.e. not on a per-all-local-job-runs basis, but per-job (per-guest?) basis, which would improve temporary starvement of small high-periodic jobs through big, less peridoci jobs. We argued that it's the user fault if such situations arise, but they can evolve over time without noticing, especially in compolexer setups. Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
2021-11-08 14:07:53 +01:00
deb-systemd-invoke reload-or-try-restart pvescheduler.service
2011-08-23 07:40:22 +02:00
exit 0;;
configure)
# Configure this package. If the package must prompt the user for
# information, do it here.
mkdir /etc/pve 2>/dev/null || true
2012-02-21 12:15:10 +01:00
if test ! -e /var/lib/pve-manager/apl-info/download.proxmox.com; then
mkdir -p /var/lib/pve-manager/apl-info
cp /usr/share/doc/pve-manager/aplinfo.dat /var/lib/pve-manager/apl-info/download.proxmox.com
pveam update || true
fi
if ! test -f /root/.forward || ! grep -q '|/usr/bin/pvemailforward' /root/.forward; then
echo '|/usr/bin/pvemailforward' >>/root/.forward
fi
2015-02-28 12:42:20 +01:00
systemctl --system daemon-reload >/dev/null || true
# same as dh_systemd_enable (code copied)
replace systemd timer with pvescheduler daemon The whole thing is already prepared for this, the systemd timer was just a fixed periodic timer with a frequency of one minute. And we just introduced it as the assumption was made that less memory usage would be generated with this approach, AFAIK. But logging 4+ lines just about that the timer was started, even if it does nothing, and that 24/7 is not to cheap and a bit annoying. So in a first step add a simple daemon, which forks of a child for running jobs once a minute. This could be made still a bit more intelligent, i.e., look if we have jobs tor run before forking - as forking is not the cheapest syscall. Further, we could adapt the sleep interval to the next time we actually need to run a job (and sending a SIGUSR to the daemon if a job interval changes such, that this interval got narrower) We try to sync running on minute-change boundaries at start, this emulates systemd.timer behaviour, we had until now. Also user can configure jobs on minute precision, so they probably expect that those also start really close to a minute change event. Could be adapted to resync during running, to factor in time drift. But, as long as enough cpu cycles are available we run in correct monotonic intervalls, so this isn't a must, IMO. Another improvement could be locking a bit more fine grained, i.e. not on a per-all-local-job-runs basis, but per-job (per-guest?) basis, which would improve temporary starvement of small high-periodic jobs through big, less peridoci jobs. We argued that it's the user fault if such situations arise, but they can evolve over time without noticing, especially in compolexer setups. Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
2021-11-08 14:07:53 +01:00
UNITS="pvedaemon.service pveproxy.service spiceproxy.service pvestatd.service pvebanner.service pvescheduler.service pve-daily-update.timer"
NO_RESTART_UNITS="pvenetcommit.service pve-guests.service"
for unit in ${UNITS} ${NO_RESTART_UNITS}; do
deb-systemd-helper unmask "$unit" >/dev/null || true
2015-02-28 12:42:20 +01:00
# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled "$unit"; then
2015-02-28 12:42:20 +01:00
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable "$unit" >/dev/null || true
2015-02-28 12:42:20 +01:00
else
# Update the statefile to add new symlinks (if any), which need to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state "$unit" >/dev/null || true
2015-02-28 12:42:20 +01:00
fi
done
# FIXME: remove after beta is over and add hunk to actively remove the repo
BETA_SOURCES="/etc/apt/sources.list.d/pvetest-for-beta.list"
if test -f "$BETA_SOURCES" && dpkg --compare-versions "$2" 'lt' '7.0-9~' && dpkg --compare-versions "$2" 'gt' '7.0~'; then
echo "Removing the during beta added pvetest repository file again"
rm -v "$BETA_SOURCES" || true
fi
# FIXME: remove in PVE 8.0
if test ! -e /proxmox_install_mode && test -n "$2" && dpkg --compare-versions "$2" 'lt' '7.0-6~'; then
d/postinst: handle static machine-id from 4.0 <= x <= 5.4 We could also just check the mtime of the machine-id as heuristic, but extracting the machine-ids from our ISO archive was pretty straight forward and avoids special handling for from Debian installed systems, so use that. The full map: pve 4.0-62414ad6-11 -> "2ec24eda629a4c8d8c1f8dac50a9ee5f" pve 4.1-a64d2990-21 -> "bd94244c0da6419a82a383e62dc03b51" pve 4.2-95d93422-28 -> "45d4e7046c3d4c26af8acd589f358ac6" pve 4.3-29d03d47-2 -> "8c445f96b3064ff79f825ea78a3eefde" pve 4.4-f4006904-1 -> "6f9fae0f0a794fd4b89b3abecfd7f182" pve 4.4-f4006904-2 -> "6f9fae0f0a794fd4b89b3abecfd7f182" pve 5.0-786da0da-1 -> "285de85759894b3f9ad9844a89045af6" pve 5.0-786da0da-2 -> "89971dede7b04c98b2b0bc8845f53320" pve 5.0-20170505-test -> "4e3b6e9550f24d638bc26211a7b37df5" pve 5.0-ad98a36-5 -> "bc2f684e31ee4daf95e45c62410a95b1" pve 5.0-d136f4ad-3 -> "8cc7bc883fd048b78a4af7433c48e341" pve 5.0-9795f744-4 -> "9b46d99712854566bb02a656a3ff9191" pve 5.0-22d7548f-1 -> "e7fc055af47048ee884dcb88a7474336" pve 5.0-273a9671-1 -> "13d879f75e6447a69ed85179bd93759a" pve 5.1-2 -> "5b59e448c3e74029af2ac91f572d68a7" pve 5.1-3 -> "5a2bd0d11a6c41f9a33fd527751224ea" pve 5.1-cfaf62cd-1 -> "516afc72013c4b9da85b309aad987df2" pve 5.1-test-20171019-1 -> "b0ce8d24684845e8ac337c588a7715cb" pve 5.1-test-20171218 -> "e0af064c16e9463e9fa980eac66427c1" pve 5.2-1 -> "6e925d11b497446e8e7f2ff38e7cf891" pve 5.3-1 -> "eec280213051474d8bfe7e089a86744a" pve 5.3-2 -> "708ded6ee82a46c08b77fecda2284c6c" pve 5.3-preview-20181123-1 -> "615cb2b78b2240289fef74da610c146f" pve 5.4-1 -> "b965b329a7e246d5be66a8d367f5760d" pve 6.0-1 -> "5472a49c6436426fbebd7881f7b7f13b" The 6.0 one should never trigger as there we had the fix already out, but it may be that some internal installation missed that and it doesn't hurt to check, so include it. Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
2021-06-22 12:14:53 +02:00
# PVE 4.0 beta to 5.4 ISO had a bug and did not generated a unique machine-id. below is a
# very relaxed machine-id list from all ISOs (released, tests & internal) possibly affected
if grep -q \
-e a0ee88c29b764c46a579dd89c86c2d84 \
-e ecbf104295bd4f8b90bb82dc2fa5e9e5 \
-e c8fa51cd0c254ea08b0e37c1e37afbb9 \
d/postinst: handle static machine-id from 4.0 <= x <= 5.4 We could also just check the mtime of the machine-id as heuristic, but extracting the machine-ids from our ISO archive was pretty straight forward and avoids special handling for from Debian installed systems, so use that. The full map: pve 4.0-62414ad6-11 -> "2ec24eda629a4c8d8c1f8dac50a9ee5f" pve 4.1-a64d2990-21 -> "bd94244c0da6419a82a383e62dc03b51" pve 4.2-95d93422-28 -> "45d4e7046c3d4c26af8acd589f358ac6" pve 4.3-29d03d47-2 -> "8c445f96b3064ff79f825ea78a3eefde" pve 4.4-f4006904-1 -> "6f9fae0f0a794fd4b89b3abecfd7f182" pve 4.4-f4006904-2 -> "6f9fae0f0a794fd4b89b3abecfd7f182" pve 5.0-786da0da-1 -> "285de85759894b3f9ad9844a89045af6" pve 5.0-786da0da-2 -> "89971dede7b04c98b2b0bc8845f53320" pve 5.0-20170505-test -> "4e3b6e9550f24d638bc26211a7b37df5" pve 5.0-ad98a36-5 -> "bc2f684e31ee4daf95e45c62410a95b1" pve 5.0-d136f4ad-3 -> "8cc7bc883fd048b78a4af7433c48e341" pve 5.0-9795f744-4 -> "9b46d99712854566bb02a656a3ff9191" pve 5.0-22d7548f-1 -> "e7fc055af47048ee884dcb88a7474336" pve 5.0-273a9671-1 -> "13d879f75e6447a69ed85179bd93759a" pve 5.1-2 -> "5b59e448c3e74029af2ac91f572d68a7" pve 5.1-3 -> "5a2bd0d11a6c41f9a33fd527751224ea" pve 5.1-cfaf62cd-1 -> "516afc72013c4b9da85b309aad987df2" pve 5.1-test-20171019-1 -> "b0ce8d24684845e8ac337c588a7715cb" pve 5.1-test-20171218 -> "e0af064c16e9463e9fa980eac66427c1" pve 5.2-1 -> "6e925d11b497446e8e7f2ff38e7cf891" pve 5.3-1 -> "eec280213051474d8bfe7e089a86744a" pve 5.3-2 -> "708ded6ee82a46c08b77fecda2284c6c" pve 5.3-preview-20181123-1 -> "615cb2b78b2240289fef74da610c146f" pve 5.4-1 -> "b965b329a7e246d5be66a8d367f5760d" pve 6.0-1 -> "5472a49c6436426fbebd7881f7b7f13b" The 6.0 one should never trigger as there we had the fix already out, but it may be that some internal installation missed that and it doesn't hurt to check, so include it. Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
2021-06-22 12:14:53 +02:00
-e 2ec24eda629a4c8d8c1f8dac50a9ee5f \
-e ef8db290720047159b426bd322839d70 \
d/postinst: handle static machine-id from 4.0 <= x <= 5.4 We could also just check the mtime of the machine-id as heuristic, but extracting the machine-ids from our ISO archive was pretty straight forward and avoids special handling for from Debian installed systems, so use that. The full map: pve 4.0-62414ad6-11 -> "2ec24eda629a4c8d8c1f8dac50a9ee5f" pve 4.1-a64d2990-21 -> "bd94244c0da6419a82a383e62dc03b51" pve 4.2-95d93422-28 -> "45d4e7046c3d4c26af8acd589f358ac6" pve 4.3-29d03d47-2 -> "8c445f96b3064ff79f825ea78a3eefde" pve 4.4-f4006904-1 -> "6f9fae0f0a794fd4b89b3abecfd7f182" pve 4.4-f4006904-2 -> "6f9fae0f0a794fd4b89b3abecfd7f182" pve 5.0-786da0da-1 -> "285de85759894b3f9ad9844a89045af6" pve 5.0-786da0da-2 -> "89971dede7b04c98b2b0bc8845f53320" pve 5.0-20170505-test -> "4e3b6e9550f24d638bc26211a7b37df5" pve 5.0-ad98a36-5 -> "bc2f684e31ee4daf95e45c62410a95b1" pve 5.0-d136f4ad-3 -> "8cc7bc883fd048b78a4af7433c48e341" pve 5.0-9795f744-4 -> "9b46d99712854566bb02a656a3ff9191" pve 5.0-22d7548f-1 -> "e7fc055af47048ee884dcb88a7474336" pve 5.0-273a9671-1 -> "13d879f75e6447a69ed85179bd93759a" pve 5.1-2 -> "5b59e448c3e74029af2ac91f572d68a7" pve 5.1-3 -> "5a2bd0d11a6c41f9a33fd527751224ea" pve 5.1-cfaf62cd-1 -> "516afc72013c4b9da85b309aad987df2" pve 5.1-test-20171019-1 -> "b0ce8d24684845e8ac337c588a7715cb" pve 5.1-test-20171218 -> "e0af064c16e9463e9fa980eac66427c1" pve 5.2-1 -> "6e925d11b497446e8e7f2ff38e7cf891" pve 5.3-1 -> "eec280213051474d8bfe7e089a86744a" pve 5.3-2 -> "708ded6ee82a46c08b77fecda2284c6c" pve 5.3-preview-20181123-1 -> "615cb2b78b2240289fef74da610c146f" pve 5.4-1 -> "b965b329a7e246d5be66a8d367f5760d" pve 6.0-1 -> "5472a49c6436426fbebd7881f7b7f13b" The 6.0 one should never trigger as there we had the fix already out, but it may be that some internal installation missed that and it doesn't hurt to check, so include it. Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
2021-06-22 12:14:53 +02:00
-e bd94244c0da6419a82a383e62dc03b51 \
-e 45d4e7046c3d4c26af8acd589f358ac6 \
-e 8c445f96b3064ff79f825ea78a3eefde \
-e 6f9fae0f0a794fd4b89b3abecfd7f182 \
-e 6f9fae0f0a794fd4b89b3abecfd7f182 \
-e 285de85759894b3f9ad9844a89045af6 \
-e 89971dede7b04c98b2b0bc8845f53320 \
-e 4e3b6e9550f24d638bc26211a7b37df5 \
-e bc2f684e31ee4daf95e45c62410a95b1 \
-e 8cc7bc883fd048b78a4af7433c48e341 \
-e 9b46d99712854566bb02a656a3ff9191 \
-e e7fc055af47048ee884dcb88a7474336 \
-e 13d879f75e6447a69ed85179bd93759a \
-e 5b59e448c3e74029af2ac91f572d68a7 \
-e 5a2bd0d11a6c41f9a33fd527751224ea \
-e 516afc72013c4b9da85b309aad987df2 \
-e b0ce8d24684845e8ac337c588a7715cb \
-e e0af064c16e9463e9fa980eac66427c1 \
-e 6e925d11b497446e8e7f2ff38e7cf891 \
-e eec280213051474d8bfe7e089a86744a \
-e 708ded6ee82a46c08b77fecda2284c6c \
-e 615cb2b78b2240289fef74da610c146f \
-e b965b329a7e246d5be66a8d367f5760d \
-e 5472a49c6436426fbebd7881f7b7f13b \
/etc/machine-id
then
echo "found static machine-id bug from Proxmox VE ISO installer <= 5.4, regenerating machine-id"
systemd-id128 new | tee /etc/machine-id.new /var/lib/dbus/machine-id.new
# atomically replace
mv /etc/machine-id.new /etc/machine-id
mv /var/lib/dbus/machine-id.new /var/lib/dbus/machine-id
echo "new machine-id generated, a reboot is recommended"
else
echo "machine-id check OK"
fi
fi
set_lvm_conf
2015-02-28 12:42:20 +01:00
if test ! -e /proxmox_install_mode; then
# modeled after code generated by dh_start
for unit in ${UNITS}; do
if test -n "$2"; then
dh_action="reload-or-restart";
else
dh_action="start"
fi
if systemctl -q is-enabled "$unit"; then
deb-systemd-invoke $dh_action "$unit"
fi
2015-02-28 12:42:20 +01:00
done
fi
;;
2011-08-23 07:40:22 +02:00
abort-upgrade|abort-remove|abort-deconfigure)
2011-08-23 07:40:22 +02:00
;;
*) echo "$0: didn't understand being called with \`$1'" 1>&2
exit 0;;
esac
exit 0