IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
check if a unit is masked before starting/restarting/reloading it,
as else we get pretty ugly error messages during upgrade.
as "deb-systemd-helper --quiet was-enabled" differs from the
"systemctl is-enabled" behaviour, the former returns true for masked
units while the latter does not, we have to manually call systemctl,
circumventing the deb helper.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Acked-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
we don't use anything bash specific in our postinst, and this way linitian
should warn us about any bashisms we introduce.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
with an added "reload-or" for pvedaemon/pveproxy/spiceproxy, which
dh_start unfortunately does not yet support
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
reduce code duplication, and reload-or-restart timers just like service
units instead of just starting them.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
We have the pvebanner.service in places which ensures this gets
called on boot before the getty target.
Thus this only had an effect if we changed the nodename to IP mapping
_and_ upgraded/reinstalled pve-manager, then switching to another TTY
would show the updated IP. But as this a) is for sure not a common
triggered path and b) a IP change suggest a reboot either way, and if
the user can handle it on their own without a reboot, they should be
able to also handle an outdated /etc/issue until the next reboot.
Also for PVE ontop of plain Debian a reboot is needed, so that the
PVE kernel gets booted, so this shouldn't be an issue ther neither.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
In commit 8b89f7533e2df983e0285e2f170971a3637d7349 we needed to
change the ceph.service install target to multi-user.target, as
ceph.target could hang indefinitely if ceph-common gets upgraded.
This change is included in pve-manager 4.4-13 and newer, as users
wanting to upgrade to 5.0 must upgrade to latest 4.4 to be able to do
so (without headache) this can be removed.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The first case won't happen anymore on a recent PVE.
The 'version is empty or <unknown>' check may drop the '<unknown>'
part, it gets handled by the 'dpkg --compare-versions' bits just
fine, if it happens at all for the 'configure' case
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
"Note that not all init systems print messages to the system console,
so that the logfile may remain empty; this is the case with systemd
(the default init system). Try "journalctl -b" instead."
-- https://packages.debian.org/stretch/bootlogd
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This was added by 82f9a5d7c on 2012-02-21 11:42:32, as we had 2 major
upgrades since them every system either was update or new installed,
so just remove this.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the name 'pve-manager' collides with our pve-manager package name,
which - from the user point of view - provides mainly the API and
WebUI.
An user could thus think that restarting 'pve-manager' would restart
the WebUIs server, which is relatable.
But, the pve-manager.service does not controls the WebUI or its
server but is responsible for starting all guest with 'onboot=1' in
their config on system boot and to stop all remaining running guests
on system shutdown.
Thus rename it to pve-guests and adapt its description. This may not
seem as ideal name at first glance, but its better than the current
option. Further it leads to log messages like:
> Starting PVE guests (Service providing start-on-boot and stop-all-on-shutdown)
> [...]
> Started PVE guests (Service providing start-on-boot and stop-all-on-shutdown)
> [...]
> Stopping PVE guests (Service providing start-on-boot and stop-all-on-shutdown)
which makes it clearer what happens, or what this service is for.
Alias the new service to the old pve-manager.service for legacy
reasons. While our services do not depend on it an user could have
made an own service which used pve-manager.service as synchronisation
point.
Linitian then complains about init.d/pve-manager not having a related
systemd service file. Instead of renmaning it just drop it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This reverts commit 7637ce6464bc28c3651b5884c3fbf2fac6ed5b66.
Revert "add missing file"
This reverts commit 7599e35af893ad9d8b544a05d5289da4093749e4.
We've switched to Let's Encrypt.
postinst configure: run update-ca-certificates if the
previous version is <= 5.0-23.
having our ceph.service pulled in by ceph.target does not
work anymore, because "systemctl start ceph.target" hangs
forever on ceph-common upgrades. multi-user.target seems to
work as well, and we are ordered after pve-cluster anyway.
only replace the old ceph.service if it is an exact match.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
