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>
the information comes only from the key value store in the pmxcfs, so
we do not actually require ceph to be installed.
So only check if ceph is locally initialized and create the rados
connection after the early return when only versions scope is set.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We actually wanted to use that scheme for more new API paths, lets
see if it is really fitting starting with this.
Use the new widget-toolkit submitUrl helper to add the ID on create.
And unify the edit/create window creation, which may fit better in a
separate commit, it's quite small and was to cumbersome to untangle,
so just go against my one rules here... :(
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Luminous, Nautilus and Octopus. In Octopus the mon_status was dropped.
Also the ceph status was cleaned up and doesn't provide the mgrmap and
monmap.
The rados queries used in the ceph status API endpoints (cluster / node)
were factored out and merged to one place.
Signed-off-by: Alwin Antreich <a.antreich@proxmox.com>
so that we can choose to only include the versions and not all metadata
this is done to avoid having a seperate 'versions' api call
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
It's a bit hard to figure out the exact constellation required for
this to happen, but we saw it in live systems when one node was dead
in a three node cluster.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
include the version as string and as parts, as we do the split
already. Also include the build commit, so if we re-release a ceph
version, we can differ here too.
Use node as key, to make the new entry a bit more general, could be
easily expanded with other infos, if required.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
use PUT for setting or unsetting, as POST/DELETE (like the old node
specific API used) makes no sense. One does not creates or deletes
the flag, they are always here. One just updates their value
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
