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>
When downloading an ISO, VZ template, or OVA file via the web UI, the
web UI uses the query-url-metadata endpoint to query file size, file
name and MIME type via an HTTP HEAD request. In a setup where this
request has to go over a proxy (configured via the http_proxy
datacenter option), querying the metadata only works for http:// URLs,
not https:// URLs. The reason is that the query-url-metadata handler
uses LWP and does not register the proxy for the https scheme.
Fix this by registering the proxy also for the https scheme.
This will break setups that rely on http_proxy not being respected for
https:// URLs. For example, setups that have a proxy for external
connections, but download e.g. ISO files (only) via https from an
internal repository that the proxy doesn't serve.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Reviewed-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Tested-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Link: https://lore.kernel.org/r/20250326105108.34911-3-f.weber@proxmox.com
The new PVE::Notify::common_template_data helper gives us a hash of
properties which should be available in all notifications (hostname,
fqdn, cluster-name at this moment). This commit makes sure that
replication notifications have these available.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Clean up the notification templates to prepare for user-customizable
templates
- Change some of the template variable names to improve clarity
- Generate the table for available updates in the template itself,
not via the 'table' helper. This makes it possible for users
to change the style/structure of the table.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Disallow colons, slashes and whitespace in pool and filesystem names,
creating such pools/filesystems either fails or results in unusable
pools.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
this now takes into account the 'not_allowed_nodes' hash we get from the
api call. With that, we can now limit the 'local_resources' check for
online vms only, as for offline guests, the 'unavailable-resources' hash
already includes mapped devices that don't exist on the target node.
This now also includes unavailable storages on target nodes.
Signed-off-by: Dominik Csapak <d.csapak@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>
it's not all fields, but many useful ones
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Most options come from the api call parameter list
(`json_config_properties`). The description and types for the remaining
ons are either taken from the manpages, source code or similar
documentation where available.
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>
The API itself allows several list separators. The network configuration
for bridge_vids expects a space separated list. We therefore convert it
initially to a space separated list.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
we already have the information parsed, so it's cheap, and we already
have a mechanism in place that adds 'ha-<hastate>' as a css class, so
let's reuse that.
I chose a blue wrench, as wrenches are associated with 'maintenance',
and because the state is different than 'online' and 'offline', but
don't make it yellow since it's not really a 'failure' state.
Users mentioned in the forum that this would be nice:
https://forum.proxmox.com/threads/125768/
Signed-off-by: Dominik Csapak <d.csapak@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>
Stick to the pattern
single: "(for type 'foo')"
multiple: "(for types 'foo', 'bar'(...) and 'last-type')"
Also adapt line-wrapping accordingly (for a 100 column limit) and fix
some minor typos (and one phrasing) while at it.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The endpoint name is mostly used for calling the API methods as first
class perl method through autoloader, but manager is a leaf node
w.r.t. dependencies and there is no existing call for either of the
two.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Currently, when we have a PCI resource mapping, we manually check only
the available models for the first PCI entry. This often works, but not
always, since one could have completely different devices in one
mapping, or with the new NVIDIA sysfs api we don't get the generally
available models.
To improve this, extend the parameter for the PCI ID to accept both,
PCI IDs or named mappings, and for the latter mappings, iterate over
all local PCI devices in it and extract the mdev types.
Rename also the parameter to better reflect what it accepts. While the
this is changing a API parameter, it's not a breaking change in this
specific case because the parameter is derived from the URL path, and
any attempt to include the parameter with a name manually is not
possible and will result in an error:
duplicate parameter (already defined in URI) with conflicting values!
Since we cannot reach the API handler without giving the parameter
already via the URL, there is no way to give it via name.
Accepting named mappings directly in this API endpoint also vastly
simplifies the UI code, since we now only have to give the mapping to
the selector instead of an (arbitrarily selected) PCI id from that
mapping.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: also split pciid into pci-id for readability and reword message
slightly ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
used the same description as for the guests.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: avoid having netin twice, change to netout once ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This was missing, but it mostly well defined since we're using the rust
bindings here. I copied most descriptions over from the PBS api, except
the ones only existing here (like sockets and level)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
both the task and system log API endpoints support downloading the log data.
annotate the API method schema accordingly to allow passing the newly
introduced checks in the API handler that limit download functionality to
annotated endpoints.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
jobs converted from vzdump.cron have an ID of the format
$digest:$counter
where $digest is the hash of the vzdump.cron file, and $counter is the
position of the job within the crontab.
while the section config schema pretends jobs.cfg's section IDs are
of type pve-configid, that is not enforced anywhere, and the API
endpoints managing such jobs allowed arbitrary strings in the past.
the ':' character is not allowed by `pve-configid`, but it is by the
section config parsers and the Job API.
convert the API schema to use the unification of previous definition
used by the job API, and what the section config parser accepts.
Fixes: f5a97f1f5 (api: jobs: vzdump: pass job 'job-id' parameter)
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
and put it into PVE::VZDump because there is a cycle between
PVE::Jobs::VZDump, PVE::API2::VZDump and PVE::API2::Backups
that prevents any of those containing it for now.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@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>
This allows us to access the backup job id in the send_notification
function, where we can set it as metadata for the notification.
The 'job-id' parameter can only be used by 'root@pam' to prevent
abuse. This has the side effect that manually triggered backup jobs
cannot have the 'job-id' parameter at the moment. To mitigate that,
manually triggered backup jobs could be changed so that they
are not performed by a direct API call by the UI, but by requesting
pvescheduler to execute the job in the near future (similar to how
manually triggered replication jobs work).
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
[ TL: fleece in d/control bump for guest-common now that the version
is known ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Ceph MDS IDs cannot start with a number [0].
[0] https://docs.ceph.com/en/latest/man/8/ceph-mds/
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Tested-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Christoph Heiss <c.heiss@proxmox.com>
The field contains the hostname of the host (without any domain part)
which sends the notification. This field can be used in match-field
match rules.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
- The man page warns about the usage of `hostname -f`, since a host
may have multiple domains (or none at all)
- The fallback PVE::INotify::nodename() already only returned the
hostname without the domain part
- Fencing notifications didn't include the domain part anyway
This may result in soft-breakage for any users who have already relied
on the domain being present. If there is need for it, it could include
a fqdn metadata field.
The hostname property used for rendering the notification template
is unaffected for now.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
This allows users to create notification match rules for specific
replication jobs, if they so desire.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
This commit adapts notification sending for
- package update
- replication
- backups
to use named templates (installed in /usr/share/pve-manager/templates)
instead of passing template strings defined in code to the
notification stack.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Tested-by: Max Carrara <m.carrara@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
Similar to how Datastore.AllocateSpace is required for the backup
storage, it should also be required for the fleecing storage.
Removing a fleecing storage from a job does not require more
permissions than for modifying the job.
Suggested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
