Signed-off-by: Markus Frank <m.frank@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Laurențiu Leahu-Vlăducu <l.leahu-vladucu@proxmox.com
Reviewed-by: Daniel Kral <d.kral@proxmox.com>
Tested-by: Laurențiu Leahu-Vlăducu <l.leahu-vladucu@proxmox.com>
Tested-by: Daniel Kral <d.kral@proxmox.com>
Tested-by: Lukas Wagner <l.wagner@proxmox.com>
Link: https://lore.proxmox.com/20250407134950.265270-7-m.frank@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by also providing the global config in assert_valid, and by also
adding the mdev config in the 'toCheck' object in the gui
For the gui, we extract the mdev property from the global entry, and add
it to the individual mapping entries, that way we can reuse the checking
logic of the other properties.
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This fixes the error:
unknown permission test at /usr/share/perl5/PVE/RPCEnvironment.pm line 536. (500)
which occurred when trying to create or update a notification target.
The cause was a permission 'check' parameter for the API handlers
which was nested one level too deep by accident.
This regression was introduced in a previous commit which raised the
needed permissions for notification target management. It likely went
unnoticed because the permission check is skipped for root@pam, so the
error occurs only if using another user.
Reported in the community forum:
https://forum.proxmox.com/threads/158101
Fixes: a3fe9c54 ("api: notifications: require powerful privileges for target management")
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
[ TL: minor commit message touch ups ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
These allow one to indirectly access resources from the POV of the
Proxmox VE cluster nodes. While gotify is relatively harmless, smtp
could already cause more problems to admins that are not aware of the
implications of allowing users to add targets while having some open
smtp relay that is only accessible from networks the PVE nodes can
access but not the user that can talk with PVE's API. The webhook one
is then pretty much free-form and might cause some adverse effects in
environments that are only loosely guarded, and while that might point
at general security problems, it's likely that admins will still place
the blame at our projects.
So while the former should not be problematic, the new not yet fully
released webhooks could have some impact. That said, it currently
requires Mapping.Modify, which is a intermediate powerful level priv,
so it's not like any user could use this. Still, hedging for the
safer side here seems the better choice for now, we still can open
this up if there's user feedback and we deem it safe enough doing so.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
These just call the API implementation via the perl-rs bindings.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-By: Stefan Hanreich <s.hanreich@proxmox.com>
The get_targets API endpoint is now implemented in Rust.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-By: Stefan Hanreich <s.hanreich@proxmox.com>
This new endpoint returns node, storage and guest metrics in JSON
format. The endpoint supports history/max-age parameters, allowing
the caller to query the recent metric history as recorded by the
PVE::PullMetric module.
The returned data format is quite simple, being an array of
metric records, including a value, a metric name, an id to identify
the object (e.g. qemu/100, node/foo), a timestamp and a type
('gauge', 'derive', ...). The latter property makes the format
self-describing and aids the metric collector in choosing a
representation for storing the metric data.
[
...
{
"metric": "cpu_avg1",
"value": 0.12,
"timestamp": 170053205,
"id": "node/foo",
"type": "gauge"
},
...
]
Some experiments were made in regards to making the format
more 'efficient', e.g. by grouping based on timestamps/ids, resulting
in a much more nested/complicated data format. While that
certainly reduces the size of the raw JSON response by quite a bit,
after GZIP compression the differences are negligible (the
simple, flat data format as described above compresses by a factor
of 25 for large clusters!). Also, the slightly increased CPU load
of compressing the larger amount of data when e.g. polling once a
minute is so small that it's indistinguishable from noise in relation
to a usual hypervisor workload. Thus the simpler, format was
chosen. One benefit of this format is that it is more or less already
the exact same format as the one Prometheus uses, but in JSON format -
so adding a Prometheus metric scraping endpoint should not be much
work at all.
The API endpoint collects metrics for the whole cluster by calling
the same endpoint for all cluster nodes. To avoid endless request
recursion, the 'local-only' request parameter is provided. If this
parameter is set, the endpoint implementation will only return metrics
for the local node, avoiding a loop.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
[WB: remove unused $start_time leftover from benchmarks]
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This new API route returns known notification metadata fields and
a list of known possible values. This will be used by the UI to
provide suggestions when adding/modifying match rules.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
'disable' can be set to disable a matcher/target.
'origin' signals whether the configuration entry
was created by the user or whether it was built-in/
built-in-and-modified.
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 privileges 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>
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>
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>
i have added it to the pci api call, but forgot to add it for usb
otherwise adding a mapped usb device only works on the node where the
gui is connected to
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this adds the typical section config crud API calls for
USB and PCI resource mapping to /cluster/mapping/{TYPE}
the only special thing that this series does is the list call
for both has a special 'check-node' parameter that uses the
'proxyto_callback' to reroute the api call to the given node
so that it can check the validity of the mapping for that node
in the future when we e.g. broadcast the lspci output via pmxcfs
we drop the proxyto_callback and directly use the info from
pmxcfs (or we drop the parameter and always check all nodes)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This API endpoint returns a big nested schema. This patch adds a mostly
complete description.
For the actual service instance return schema, we include commonly used
and important properties. It will usually return more. What exactly
depends on the Ceph service type.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
to include a more complete description of the returned data.
Sort properties in alphabetical order if the list is longer.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
When a schedule only has a limited amount of runs it can happen
(e.g. 2022-10-01 8:00/30), $next will be undef after the last run.
Exit early in that case.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
not only the given parameters, e.g. at the moment, the gui will
never send a 'verify-certificate' parameter, even if set in the config
by using the complete resulting config, we test the actual settings.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
a simple api call to simulate calendar event triggers
takes a schedule, an optional number (default 10), an optional starttime
(default 'now') and returns a list with unix timestamps, as well as
humanly readable utc timestamps.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
in addition to listing the vzdump.cron jobs, also list from the
jobs.cfg file.
updates/creations go into the new jobs.cfg only now
and on update, starttime+dow get converted to a schedule
this transformation is straight forward, since 'dow'
is already in a compatible format (e.g. 'mon,tue') and we simply
append the starttime (if any)
id on creation is optional for now (for api compat), but will
be autogenerated (uuid). on update, we simply take the id from before
(the ids of the other entries in vzdump.cron will change but they would
anyway)
as long as we have the vzdump.cron file, we must lock both
vzdump.cron and jobs.cfg, since we often update both
we also change the backupinfo api call to read the jobs.cfg too
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Since commit: 8a3a300b ("ceph services: drop broadcasting legacy
version pmxcfs KV")
The 'ceph-version' kv is not broadcasted anymore, so we should not
query it, instead use get_ceph_versions
Also drop the other legacy keys for the versions
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
like we do in it for the storage section configs
we will need this to store the token for influxdbs http api
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
