this one would deserve much more, especially the newer backup job
detail and not-backed-up view should be split out and done in a
declarative way (view view-controller)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
My browser here is pretty fixated on the history, and due to some
unknown reason I got a history fragment string like:
`#v1:=0:=18:=4:::::::` so the "hashes" got into strings, and I was
not able to move them back.
Adding a match here to always try reverse-mapping the hash to the
original input helps to fix that here.
We'd only run into issues if we'd use a integer-string as id, but we
really don't (IIRC not even allowed in extjs) so this is safe to do.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
eslint complains about the window.confirm call, and neither I nor
some other colleagues here did see that dialogue ever in practice.
The confirm here does not adds any real value, as all other back
navigation are unprotected, but have similar potential in loosing
state.
One can always navigate forward via their user agent and for console
(noVNC, xterm.js) we have now a separate check.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
if passing the hook script command as string, it might get interpreted
as shell command with side-effects. this is pretty harmless, since only
root is allowed to set the script parameter anyway, but making it more
robust and future-proof does not hurt.
tested with a reproducer of "/bin/echo $(touch $(whoami))" as script
parameter, with a file with that name existing, being executable and
having the following contents:
----8<----
echo "hello from hook script"
---->8----
without this change, the hookscript itself is not executed, but
'/bin/sh -c "/bin/echo $(touch $(whoami)) job"' and similar calls are,
which cause the file 'root' to be touched in the current working
directory of the vzdump process (or task worker).
with this change, the file is executed as is without any side-effects of
shell commands in the file name, and the 'hello from hook script' lines
are printed whenever the hook script is called by vzdump.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Also rename disks to blockdevices, as especially with the iSCSI stuff
the listed devices do not necessarily need to be real disks.
Grouping current(ish) load info in it's own system-load section seems
to be a better fit in general too.
bios/pci stuff is all hardware, so group it there to avoid adding to
much sections.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Makes all report-def entries hashes which allows to drop some
handling for the ARRAY ref case.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
And move the helper methods up and scope them to module-local only
Uses the fact that perl methods return the last statement, so the
dir2text sub closures in the command list do not need to be changed
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
PSI can be queried in /proc/pressure/{cpu,io,memory} for the
corresponding resources. this helps us track down disruptions caused
by resource overcommitment.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
This patch fixes a regression for hosts disabling ipv6 via kernel
commandline ('ipv6.disable=1')introduced in commit
e224b7d2e6
(disabling IPv6 via sysctl did not exhibit these problems)
by hardcoding the address to '::', pveproxy and spiceproxy failed to
start with:
'unable to create socket - Address family not supported by protocol'
This patch depends on the commit in pve-common, which tries first
binding to '::' and then falling back to '0.0.0.0', and needs a
versioned dependency bump on libpve-common-perl.
With this patch the listening addresses are (`ss -tlnp |grep 8006` output)
* ipv6 disabled via kernel cmdline: '0.0.0.0:8006'
* sysctl net.ipv6.conf.all.disable_ipv6=1: '*:8006'
* sysctl net.ipv6.bindv6only=1: '[::]:8006'
* else: '*:8006'
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Pushed this one out by mistake when commit a fixup, so do revert now
as I did not fully reviewed it and saw some UI changes I'd like to
do.
This reverts commit cfc6d15ed0.
and also show the retention options that will be used for a given storage. A
user with Datastore.AllocateSpace and VM.Backup can already remove backups from
the GUI manually, so it shouldn't be a problem if they can set the remove flag
when starting a manual backup in the GUI.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Do not fill in the default for compression, because the initial default for the
backend is to not compress, while the current default for the UI is zstd, which
is preferable.
The 'defaults' API call expects the user to have permissions on the storage,
because retention options are storage-dependent. Use a flag initialDefaults to
make sure storage-independent properties are only set once, so they are not
reset when a user changes the storage after editing them.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
on a given node (and storage).
There is no datacenter/storage fallback for the bandwidth limit, so the default
can just be returned as is. While the bandwidth limit is a root-only option when
executing the backup, it still makes sense to return it for all users, so they
can see what's going to be used.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
To make them load the updated librados2, as else they may potentially
not be able to communicate with the potentially newer ceph monitors,
as Debian 10 ships Jewel (12.2) by default...
While we could do some more fancy signaling to the workers to reload
the lib, that is rather a PITA and complex solution for something
that happens once in a blue moon.
We may want to add a trigger in ceph for this on updates though, that
would effectively fix this too - but needs to be thought out better.
So for now lets go with the simplest solution.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
nautilus 14.2.20 and octopus 15.2.11 fixed a security issue with
reclaiming the global ID auth (CVE-2021-20288). As fixing this issue
means that older client won't be able to connect anymore, the fix was
done behind a switch, with a HEALTH warning if it was not active
(i.e., disallowed connection from older clients).
New installations have this switch also at the insecure level, for
compat reasons, so lets deactivate it ourself after monitor creation
to avoid the health warning and slightly insecure setup (in default
PVE ceph the whole issue was of rather low impact/risk). But, only do
so when creating the first monitor of a ceph cluster, to avoid
breaking existing setups by accident.
An admin can always switch it back again, e.g., if they're recovering
from some failure and need to setup fresh monitors but have still old
clients.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
