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>
This commit adds a new view that allows configuring notification
targets for all existing notification events (replication, updates,
fencing).
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
This commit adds a possibility to choose between different options
for notifications for backup jobs:
- Notify via email, in the same manner as before
- Notify via an endpoint/group
If 'notify via mail' is selected, a text field where an email address
can be entered is displayed:
Notify: | Always notify v |
Notify via: | E-Mail v |
Send Mail to: | foo@example.com |
Compression: | ..... v |
If the other option is selected selected, a combo picker for selecting
a channel is displayed:
Notify: | Always notify v |
Notify via: | Endpoint/Group v |
Target: | endpoint-foo v |
Compression: | ..... v |
The code has also been adapted to use the newly introduced
'notification-policy' parameter, which replaces the 'mailnotification'
paramter for backup jobs. Some logic which automatically migrates from
'mailnotification' has been added.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Check notification targets configured in datacenter.cfg and jobs.cfg,
failing if the group/endpoint to be removed is still in use there.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
The API call returns all entities that can be used as notification
targets (endpoints, groups). Only targets for which the user has
appropriate permissions are returned.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
The Perl part of the API methods primarily defines the API schema,
checks for any needed priviledges and then calls the actual Rust
implementation exposed via perlmod. Any errors returned by the Rust
code are translated into PVE::Exception, so that the API call fails
with the correct HTTP error code.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
The Perl part of the API methods primarily defines the API schema,
checks for any needed priviledges and then calls the actual Rust
implementation exposed via perlmod. Any errors returned by the Rust
code are translated into PVE::Exception, so that the API call fails
with the correct HTTP error code.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
The Perl part of the API methods primarily defines the API schema,
checks for any needed priviledges and then calls the actual Rust
implementation exposed via perlmod. Any errors returned by the Rust
code are translated into PVE::Exception, so that the API call fails
with the correct HTTP error code.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
The Perl part of the API methods primarily defines the API schema,
checks for any needed priviledges and then calls the actual Rust
implementation exposed via perlmod. Any errors returned by the Rust
code are translated into PVE::Exception, so that the API call fails
with the correct HTTP error code.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
