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 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 8b89f7533e 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>
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>
This reverts commit 7637ce6464.
Revert "add missing file"
This reverts commit 7599e35af8.
We've switched to Let's Encrypt.
postinst configure: run update-ca-certificates if the
previous version is <= 5.0-23.
instead of having font-awesome copied into the repository,
depend on the debian package 'fonts-font-awesome', which provides all we
need
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
for better building pve-manager
this moves the copyright file to debian/
the debian/changelog.Debian to debian/changelog
we do not need the debian/conffiles anymore (gets autogenerated from
files in ./etc/)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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>
The actual 4.3-12 release is done in a separate
branch "hotfix-4.3-12", because we cannot release
commit 58b12d605 now (requires updated pve-cluster
package).
Instead we will the use the CA certificate provided by the
ca-certificates packages, which is now a mandatory depency of
pve-manager since 8204daafaf and
pve-manager 4.2-17. This change allows us in the future to
use different CA for our https repositories.
This changed has been tested OK with the following combination:
* https repository using a StartCom certificate: works
* https repository using a Let's encrypt certificate: works
User visible changes:
* none : the new configuration file 75pveconf silently
overwrites the olderone, except if local changes were made
in which case you're presented with the traditional debian menu
(keep local/ use packager version/ diff / open a shell)
ca-certificates provides the necessary root ca certificates
to connect to the PVE enterprise repositories
The package was always installed since pve-manager 3.1-13 as an indirect
'Depends:' via liblwp-protocol-https, but could have been missing in previous
versions of pve.
Adding this dependency directly makes it sures that it's available
in each PVE installs no matter what Debian packagers do.
With this package installed we no longer need to ship
our own server CA cert.
in my commit 2e1eb55afc
i introduced a bug with that an item gets selected
in the tree when you right click on it
also fix the function parameters
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>