While one can re-add a user quite easily, the ACLs and the old
password may still be lost, so not really just like a simple "undo".
That's why it should show the warning triangle and have no selected
as default.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
now that we no longer ship our own LVM packages, set the relevant
filtering options here if they are missing.
for an upgrade from PVE 6.x, the following two scenarios are likely:
A: user edited config provided by our old lvm2 package. it likely
contains our (or a modified) global_filter, but the old scan_lvs
default. in this case we ignore global_filter as long as it contains our
'don't scan zvols' entry, and set scan_lvs to false.
B: config provided by our old lvm2 package was taken over by default
config from stock lvm2 package. scan_lvs defaults to false already, but
global_filter is unset (scan everything), so we need to set our own
global_filter excluding zvols.
other combinations should be handled fine as well.
for new installs (installer, install on top of Debian Bullseye) we are
always in scenario B.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
we have lots of information already parsed and cached, use that and
give the frontend more to work with/display.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
any system upgrading to 7.x was either installed with >= 6.4 in the
first place, or upgraded to >= 6.4 and thus fixed those issues already.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
We could also just check the mtime of the machine-id as heuristic,
but extracting the machine-ids from our ISO archive was pretty
straight forward and avoids special handling for from Debian
installed systems, so use that.
The full map:
pve 4.0-62414ad6-11 -> "2ec24eda629a4c8d8c1f8dac50a9ee5f"
pve 4.1-a64d2990-21 -> "bd94244c0da6419a82a383e62dc03b51"
pve 4.2-95d93422-28 -> "45d4e7046c3d4c26af8acd589f358ac6"
pve 4.3-29d03d47-2 -> "8c445f96b3064ff79f825ea78a3eefde"
pve 4.4-f4006904-1 -> "6f9fae0f0a794fd4b89b3abecfd7f182"
pve 4.4-f4006904-2 -> "6f9fae0f0a794fd4b89b3abecfd7f182"
pve 5.0-786da0da-1 -> "285de85759894b3f9ad9844a89045af6"
pve 5.0-786da0da-2 -> "89971dede7b04c98b2b0bc8845f53320"
pve 5.0-20170505-test -> "4e3b6e9550f24d638bc26211a7b37df5"
pve 5.0-ad98a36-5 -> "bc2f684e31ee4daf95e45c62410a95b1"
pve 5.0-d136f4ad-3 -> "8cc7bc883fd048b78a4af7433c48e341"
pve 5.0-9795f744-4 -> "9b46d99712854566bb02a656a3ff9191"
pve 5.0-22d7548f-1 -> "e7fc055af47048ee884dcb88a7474336"
pve 5.0-273a9671-1 -> "13d879f75e6447a69ed85179bd93759a"
pve 5.1-2 -> "5b59e448c3e74029af2ac91f572d68a7"
pve 5.1-3 -> "5a2bd0d11a6c41f9a33fd527751224ea"
pve 5.1-cfaf62cd-1 -> "516afc72013c4b9da85b309aad987df2"
pve 5.1-test-20171019-1 -> "b0ce8d24684845e8ac337c588a7715cb"
pve 5.1-test-20171218 -> "e0af064c16e9463e9fa980eac66427c1"
pve 5.2-1 -> "6e925d11b497446e8e7f2ff38e7cf891"
pve 5.3-1 -> "eec280213051474d8bfe7e089a86744a"
pve 5.3-2 -> "708ded6ee82a46c08b77fecda2284c6c"
pve 5.3-preview-20181123-1 -> "615cb2b78b2240289fef74da610c146f"
pve 5.4-1 -> "b965b329a7e246d5be66a8d367f5760d"
pve 6.0-1 -> "5472a49c6436426fbebd7881f7b7f13b"
The 6.0 one should never trigger as there we had the fix already out,
but it may be that some internal installation missed that and it
doesn't hurt to check, so include it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
'for...in array' returns the id in the array but not the value,
'for...of array' returns the values.
Another issue that I ran into was if the property did not exist.
Checking if the property evaluates to false will catch situations where
the property does not exist or is null. All other situations where there
is a value for the name, id or type, should evaluate to true if present
as they are strings or the VMID.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
migration and (container) startup will no longer work when the storage's content
type is not correct, and unreferenced volumes on such storages will not be
scanned for anymore.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
the backend will have actual explicit length limits on the
description properties (was limited indirectly through PUT/POST
request size limit of 64 KiB), so convey that limit also in the GUI.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
a common function to download arbitrary files from urls has been
defined as PVE::Tools::download_file_from_url and is now used.
Signed-off-by: Lorenz Stechauner <l.stechauner@proxmox.com>
while the command itself is 'suspend', the task description
is 'qmpause', so simply add a parameter and overwrite it for the pause
menu item
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we should not warn for ceph's built-in default value for min_size as
having the min_size half of the size (rounded up) is ok and even the
default for ceph
Since there seems to be no 'quorum based' pg inconsistency recovery[0],
only a copy from the authoritative osd, there is nothing wrong
with setting that.
0: https://docs.ceph.com/en/latest/rados/operations/pg-repair/
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Multiple public networks can be defined in the ceph.conf. The networks need to
be routed to each other.
Support handling multiple IPs for a single monitor. By default, one address from
each public network is selected for monitor creation, but, as before, it can be
overwritten with the mon-address parameter, now taking a list of addresses.
On removal, make sure the all addresses are removed from the mon_host entry in
the ceph configuration.
Originally-by: Alwin Antreich <a.antreich@proxmox.com>
[handling of multiple addresses]
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
by also comparing the canonical form to decide when to remove an address. When
getting the IP from the rados information, also drop eventual brackets, so our
existing function can handle it. Add the brackets back within the
remove_addr_from_mon_host function.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Partially based on pve-storage's CephConfig.pm get_monaddr_list, but the
interface is not the best for the use case here.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
in preparation for supporting multiple addresses. The config section does not
allow more than one public_addr.
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
mostly relevant to prepare support for IPv4/IPv6 dual stack mode as a special
case of the planned support for mutliple public networks.
As before, only set the false value when we are dealing with the first address,
but also be explicit about the IPv4 case as the defaults might change in the
future.
Then, when an address of a different type comes along later, set the relevant
bind option to true.
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
fixes 'infinite' height of the guest notes, by setting the height on the
container a level up
the notes view itself is already scrollable, so if it is too large,
there'll be a scrollbar
this does not change anything for templates, as there we show nothing
under the notes and thus there the infinite height is ok
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
