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>
This commit adds a new Perl module, PVE::API2::Cluster::Notification.
The module will contain all API handlers for the new notification
subsystem.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
If the new 'target-replication' option in datacenter.cfg is set to a
notification target, we send notifications that way. If it is not set,
we continue send a notification to the default target (mail to
root@pam).
There is also a new 'replication' option. It controls whether to send
a notification at all.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
... instead of using sendmail directly
If the new 'target-package-updates' is set, we send a notification to
this target. If not, we continue to send a mail to root@pam (if the
mail address is configured)
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
... instead of using sendmail directly.
If the new 'notification-target' parameter is set,
we send the notification to this endpoint or group.
If 'mailto' is set, we add a temporary endpoint and a
temporary group containg both targets.
This commit also refactors the old 'sendmail' sub heavily:
- Use template-based notification text instead of endless
string concatenations
- Removing the old plaintext/HTML table rendering in favor of
the new template/property-based approach offered by the
`proxmox-notify` crate.
- Rename `sendmail` sub to `send_notification`
- Breaking out some of the code into helper subs, hopefully
reducing the spaghetti factor a bit
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
A user can no see all vms/containers, even the ones that are already a
member of a pool. They can be transfered now after checking the newly
introduced "allow transfer" checkbox.
Signed-off-by: Philipp Hufnagl <p.hufnagl@proxmox.com>
When the newly introduced optional parameter "transfer" is set, the user
add a vm/container to a pool even if it is already in one. If so it will
be removed from the old pool
Signed-off-by: Philipp Hufnagl <p.hufnagl@proxmox.com>
This is required for the new check-connection parameter for ldap
realms added in the next commit.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Before, there was zero space between the the grid border line and the
button, making it look a bit odd.
The ListField form component is currently used in the
'User Tag Access' and 'Registered Tags' dialog windows in datacenter
option view.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Alter style to make the parameter check more concise
Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
The case-sensitive option is not really something that should be CLI
only and is quite common for Microsoft AD setups, so add it to the UI
too as requested in the Forum [0], improving discoverability.
[0]: https://forum.proxmox.com/threads/74547/#post-575854
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
They need to have the same name as the target.
Took the opportunity to move the .PHONY right next to the target recipe,
so that mistakes like these are hopefully easier caught.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
move ipam selector to main items as it's non optional, and it's breaking
display if present in advanced.
move common id,mtu,nodes fields from modules to base
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Commit 114e5f2c ("pve7to8: sync over from stable-7 branch")
accidentally got rid of the correct value 0 here and also the new TODO
message to improve the situation. But the TODO is actually easy,
because there already is the $upgraded variable. Just rely on that
instead of hard-coding and forgetting about it again.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
