Instead of marking all pve-kernel-.* packages as NeverAutoRemove we compile
a list of specific versions to keep.
This functionality is added in the proxmox-ve package (along with the config
for booting kernels with systemd-boot).
this is a short running script, so the version list can be re-used,
the chance that there where updates in between are slim and racy
anyway. IF getting the versions did not succeeded, we still retry on
every call though, simpler and ensures a warning is printed in the
caller check vicinity.
Makes script noticeable faster.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
only as a warning, since this will also trigger a Ceph health warning
and is easily recoverable.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Adds the same check we run in pve-cluster before joining a node to make
sure the hostname resolves to a configured IP.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
this warns the user that he cannot live migrate VMs with svm/vmx to PVE6 when
the nested parameter of the kvm module is on
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
While we nowadays can work much better with package upgrades relating
the cluster stack it still happens that a pve-cluster upgrade can
produce a false-positive 401 (auth failure) code for a currently
valid ticket, e.g., because a pmxcfs lock was requested but the
pmxcfs was currently not mounted due an upgrade triggered restart.
A frequent case for a few false positive 401 is also a cluster
creation, especially if not done over the web GUI.
Thus add a counter, which gets set to 0 on each successful login or
ticket renewal and gets increased on each 401 error. Only show the
logged out window if we get five or more 401 responses. While 5 may
sound a bit much one needs to remember that we always have quite a
few API call in flight (resource update store, stores from current
panel ...) and thus, if one got really auth denied it will still show
quite fast (1 to 5 seconds, depending on which panel is currently
opened). Further, the backend naturally does not allows to do
anything during this time, this has no security implications
whatsoever.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
a 'mon remove' does this already for us, so do not stop it
this lead to a race where we could stop the next to the last monitor
before it was removed from the cluster, leading to a state
where two monitor were needed for quorum, but only one did exist
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we need to remove an ip, ip:port or a ipvector from monhost
so use multiple regex search and replaces for this
this looks not really nice, but due to the strange format
of the line (e.g. ',' is a seperator inside and outside of a vector,
also ipv6 adresses may be surrounded with [] but so are vectors),
i found no better way
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
otherwise it is possible that multiple users create monitors at the same
time, resulting in a wrong ceph.conf and probably worse
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
in nautilus, the default msgr protocol is v2, but it has to be
explicitely given to monmaptool, also we don't want to use the
monitor sections anymore so only update mon_host
ceph can cope with mixed mon_host and monitor sections, so this is
not a problem
also the ceph-create-keys part is not necessary anymore since
this is done by the monitor itself now
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
by using our new 'get_services_info'
this already checks for nautilus+ style 'mon_host' key in the ceph.conf
for the ip address
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Make clear thet the 5.x is also supported and reword a bit as
"5.X/4.X/3.X/2.6" is a bit hard to read, so use "5.X - 2.6"
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
normally this gets created on package installation, but could be
deleted, e.g., by a debug purge. As it costs nothing to create just
do a mkdir on it, which does not fails if it already exists..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
it makes no sense to have the mon key inside the client.admin.keyring
also the order and operations did not make much sense
also create the client admin keyring when creating the config
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
if we already have a monitor, we can try to get the public_network via
the ceph configuration database
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
