Quite a few translations produce a longer label here, so account for
that, the window is still very small.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Doing a simple numericity check and warn in the console so developers
can notice if there is something off.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
An empty string is passed by the backup job window when using
selection mode 'all', would be converted to [""] and wrongly add an
entry with VMID 0 because the item "" could not be found in the store.
Reported in the community forum:
https://forum.proxmox.com/threads/130164/
Fixes: 7a5ca76a ("fix #4239: ui: show selected but non-existing vmids in backup edit")
Suggested-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
For Fedora 38 the systemd shared object files used to check the systemd
version are located at /usr/lib64/systemd or /usr/lib/systemd.
Therefore, include /usr/lib64/systemd in the list of directories to
check.
Further, Fedora 38 adds a fc38 postfix to the filename, so expand the
regex to cover that as well.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
A simple string regex match on data that the API returns anyway can be
the job of a frontend/client..
Safe to do as we never released this API change in a bumped manager
version and switched the UI to extract this info client-side.
This reverts commit d61728e289.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Currently it was only used once and it had not really any benefit, as
the one thing it did is defining a list of compressors – the
KVComboBox is made such, so that this can be done on definition
directly, no need for inheritance.
Also, if one would think about adopting this more for other similar
selectors: While we have some uses of compressors all over the place,
and most of them are not really coupled to each other, so having a
single widget for them does not make sense.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The compression algorithm will be automatically detected when querying the
download URL. It can be overriden by the user using the "compression algorithm"
drop down under advanced.
Signed-off-by: Philipp Hufnagl <p.hufnagl@proxmox.com>
Reworded title and message, updated d/control for libpve-storage-perl version
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
extend the query_url_metadata endpoint with the option to detect and return
used compression algorithms, if supported by PVE. this will be used to support
decompression as part of the download flow for certain file types (ISO files
for now).
Signed-off-by: Philipp Hufnagl <p.hufnagl@proxmox.com>
Slightly reworded commit title/message
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
While not a must, it helps to ensure we got the newly documented
pbs-entries-max feature actually available and avoids all to freaky
set ups.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
configuring pbs-entries-max can avoid failing backups due to a high
amount of files in folders where a folder exclusion is not possible
Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
The 'allow' wording makes it clearer that we just not block something,
but do not really do anything else. And we use the 'move' wording also
for when moving volumes between guests, which is in the same spirit as
this here (remove something from a entity and add it to another).
While this was already bumped, we did not move it outside of pvetest,
so I do not see practical concerns with API breakage.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
It's not really providing good UX, as user needs to extra tick this
but cannot be sure what transfer means in this case.
Just replace this with a simple, more telling hint that will inform
users about what happens.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As suggested in [1], it is recommended to use `_` in all cases when
dealing with config files. Note that this is for creation only, and we
enforce that there cannot be an existing MDS with the same ID, so we
do not have to bother how ceph would handle the case where both exist.
[1] https://docs.ceph.com/en/reef/rados/configuration/ceph-conf/#option-names
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Fix file extension for SPICE config download on
AppleWebKit browsers to ensure proper application
association on MacOS.
Signed-off-by: Markus Frank <m.frank@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The backend has supported the 'mode' parameter for quite a while,
however it has not yet been exposed in the GUI, contrary to PMG
and PBS.
The benefit of 'mode' is that it supports LDAP, LDAPS and LDAP via
STARTTLS, compared to just LDAP/LDAPS for the 'secure' parameter.
The modified AuthEdit{LDAP,AD} panel will now automatically migrate
to the new paramter by hooking into onGetValues/onSetValues.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
still default to Ceph 17.2 Quincy for now, at least if there isn't a
Ceph Reef set-up in the cluster already.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Do not crowd the higher level API endpoint handler code directly with
some rather low level procfs parsing code, rather factor that out in a
helper. Make said helper private for now so that anybody wanting to
use cannot do so, and thus increase the chance that said dev will
actually think about if this makes sense as is as a general interface.
Avoid fatal die's for the odd case that the smaps_rollup file cannot
be opened, or the even less likely case where PSS stats cannot be
found in the content.
The former could happen due to the general TOCTOU race here, i.e., the
PID we get from systemctl service status parsing isn't guaranteed to
exist anymore when we read from procfs, and if, it's actually not
guaranteed to still be the OSD - but we cannot easily use pidfd's
here and OSD stops are not something that happens frequently, but in
anyway avoid that such a thing fails the whole API call only because a
single metric is affected.
In the long rung it might be better to add a "errors" array to the
response, so that the user can be informed about such an (odd) thing
happening.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
$raw isn't used anywhere here and probably just a left over from copy
pasting, and the "int cast ternary" can be avoided by just directly
casting to int when assigning the variable in the first place.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Currently we are using the MemoryCurrent property of the OSD service
to determine the used memory of a Ceph OSD. This includes, among other
things, the memory used by buffers [1]. Since BlueFS uses buffered
I/O, this can lead to extremely high values shown in the UI.
Instead we are now reading the PSS value from the proc filesystem,
which should more accurately reflect the amount of memory currently
used by the Ceph OSD.
Aaron and I decided on PSS over RSS, since this should give a better
idea of used memory - particularly when using a large amount of OSDs
on one host, since the OSDs share some of the pages.
[1] https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Aaron Lauterer <a.lauterer@proxmox.com>
The new helper is available since proxmox-widget-toolkit version 3.6.1
which we can be sure to be available since a while in praxis, but
definitively by d/control constraints, since 51f54177 ("bump
proxmox-widget-toolkit dependency to 4.0.7")
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
[TL: add context since when this function is available ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
In some situations, such as backing up VMs with 2 or more disks to
PBS, we get passed the backup archive size as a string instead of
as an integer. This led to errors rendering the notification template
down the line.
This commit explicitly casts the data from the task table to an int.
It would be a good idea to actually hunt down the places that produced
the string instead of an integer, but as a quick fix and as a
safeguard against similar lurking errors this approach is fine, IMO.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
During the redesign of www.proxmox.com the menu structure and therefore
some url changed. Update the external link in order to avoid an
unneccessary redirect
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
While it makes sense to reload the Web UI after ordering a certificate
for the same node, it is unnecessary to reload the Web UI when ordering
a certificate for a different node.
Signed-off-by: Filip Schauer <f.schauer@proxmox.com>
PVE::Notify::send_notification is now private (the mocking was for the
old api)
'cfs_read_file' gets exported into PVE::Notify before it gets mocked,
so it needs to be mocked inside PVE::Notify, not PVE::Cluster.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Virtual (or anonymous) endpoints/groups are used for sending
one-off notifications to a target that does not exist in the
config.
VZDump uses this to send out notification mails to those addresses
configured by the `mailto` parameter.
Suggested-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Since the target does not require Mapping.Use, it should also be
visible and testable by all users.
Short explanation why the 'mail-to-root' is exempt from priv checks:
To ensure backwards compatibility, the 'mail-to-root' target does not
require the `Mapping.Use` privs. This is needed due to the fact that
this target is used as a fallback in case no other target is
configured for an event. For instance, the /node/<name>/apt/update API
call only requires Sys.Modify for the node, but it can also send a
notification. If we were to require Mapping.Use, we could break the
apt/update API compat in the case that a notification shall be sent,
but without any configured notification target (which will then
default to 'mail-to-root').
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
