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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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 2bde88fb3f6ed61ddb67c01190cbffdbfc210ea9 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 c91649753 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>
we will use components from proxmox-widget-toolkit rather than
directly from pve-manager
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
with the use of systemd the /etc/init.d/pveproxy restart call got
intercepted and redirected to systemd, which did an restart.
But, that is a behvaior change to the intention of the init.d script,
which would not restart but reload the service.
Thus change this to systemds equivalent:
systemctl try-reload-or-restart pveproxy.service
Which tries to reload, if the unit supports it, and only if that does
not worked it restarts.
Same for spiceproxy.
Reported-by: Stefan Priebe <s.priebe@profihost.ag>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Instead of fixing up permissions manually as the make
install target is actually responsible for this (and already
doing it).
Signed-off-by: Wolfgang Bumiller <w.bumiller@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>
