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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
otherwise it is missing when building in a clean chroot via a generated
source packages.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
to ensure we have the /etc/hosts inotify read/write, needed for it's
gui part, methods available
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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 actually want to keep this for now as else we get the
autogenerated systemd helper code here which stops all services from
this package before upgrading, which we really really do not want
(kills API connections, among other things)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
With #DEBHELPER# the manual maintained code will be autogenerated, no
need to manually track which services and timers this packages has.
Signed-off-by: Thomas Lamprecht <t.lamprecht@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>
