Due to Ceph dropping privileges when running the 'ceph-crash' daemon
[0], it is necessary to allow the daemon to authenticate with its
cluster in a safe manner.
In order to avoid exposing sensitive keyrings or somehow escalating
its privileges again, 'ceph-crash' is therefore provided with its own
keyring in the '/etc/pve/ceph' directory. This directory, due to being
on 'pmxcfs', may be read by members of the 'www-data' group, which
'ceph-crash' is made part of [1].
Expected Configuration
----------------------
1. A keyring file named '/etc/pve/ceph/ceph.client.crash.keyring'
exists
2. A section named 'client.crash' exists in '/etc/pve/ceph.conf'
3. The 'client.crash' section has a key named 'keyring' which
references the keyring file as '/etc/pve/ceph/$cluster.$name.keyring'
4. The 'client.crash' section has *no* key named 'key'
New Clusters
------------
The keyring file is created and the conf file is updated after the first
monitor has been created (when calling `pveceph mon create`).
Existing Clusters
-----------------
A new helper script creates and configures the 'client.crash' keyring in
`postinst`, if:
* Ceph is installed
* Ceph is initialized ('/etc/pve/ceph.conf' and '/etc/pve/ceph' exist)
* Connection to RADOS is successful
If the above conditions are met, the helper script ensures that the
existing configuration matches the expected configuration mentioned
above.
The configuration is not changed if it is already as expected.
The helper script may be called again manually if the `postinst` hook
fails. It is installed to '/usr/share/pve-manager/helpers/pve-init-ceph-crash'.
Existing `client.crash` Key
---------------------------
If a key named 'client.crash' already exists within the cluster, it is
reused and not regenerated.
[0]: https://github.com/ceph/ceph/pull/48713
[1]: https://git.proxmox.com/?p=ceph.git;a=commitdiff;h=f72c698a55905d93e9a0b7b95674616547deba8a
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
This commit adds the '/etc/pve/ceph' directory to our overall expected
Ceph configuration.
This directory is meant to store cluster-wide, non-private
configuration files used by Ceph applications and services that are
executed with lower privileges, such as 'ceph-crash.service'.
The existence of the directory is now also checked for when checking
whether Ceph is configured correctly. This makes it easier for our
other tooling to rely on the directory's existence, reducing the
number of otherwise needless frequent checking.
* For new clusters: `pveceph init` now creates '/etc/pve/ceph' when
called.
* For existing clusters: The 'postinst' hook this commit adds ensures
that '/etc/pve/ceph' is created when updating.
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
Allows to configure a custom broadcast address to use when sending a
wake on lan packet to wake a remote node.
Default behaviour remains to fallback to 255.255.255.255.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Allows to optionally configure a local interface name to which to
bind to when sending a wake on lan packet to wake a remote node.
Default behaviour remains to send the packet via the interface for
the default gateway.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Moves the wakeonlan property to be a property string, with current mac
address as default key. This allows to later add further optional
properties such as bind-interface and broadcast-address.
Adds the `get_wakeonlan_config` helper function to parse the string
when read from the node config.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
[ TL: also improve if-expression wrapping ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The Ceph monitor removal assertion contains a condition that checks
whether the given mon ID actually exists and thus may be removed.
The first part of the condition checks whether the hash returned by
`get_services_info` [0] contains the key "mon.$monid". However, the
hash's keys are never prefixed with "mon.", which makes this check
incorrect.
This is fixed by just using "$monid" directly.
The second part checks whether the mon hashes returned by
Ceph contain the "name" key before comparing the key with the given
mon ID. This key existence check is also incorrect; in particular:
* If the lookup `$_->{name}` evaluates to e.g. "foo", the check
passes, because "foo" is truthy. [1]
* If the lookup `$_->{name}` evaluates to "0", the check fails,
because "0" is falsy (due to it being equivalent to the number 0,
according to Perl [1]).
This is solved by using the inbuilt `defined()` instead of relying on
Perl's definition of truthiness.
[0]: https://git.proxmox.com/?p=pve-manager.git;a=blob;f=PVE/Ceph/Services.pm;h=e0f31e8eb6bc9b3777b3d0d548497276efaa5c41;hb=HEAD#l112
[1]: https://perldoc.perl.org/perldata#Scalar-values
Fixes: https://bugzilla.proxmox.com/show_bug.cgi?id=5198
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
This was restricted to Sys.Modify + Sys.Audit on the whole cluster to
ensure that only trusted users get access to a method that can scan
the (local) network from the POV of the Proxmox VE node, even if only
through HTTP HEAD requests.
Nowadays there's enough user interest [0] to warrant a separate access
privilege to cover such an use case, and while most of the requests
are for the download-url storage API endpoint, this method here is not
only a bit less powerful than the storage one, it's rather tied to the
latter anyway (e.g. for querying the metadata of a URL in the web UI
for name and size before downloading it to a storage).
For backwards compatibility keep the old check and add the new
privilege as alternative to fulfill the permission requirements of
that API endpoint.
[0]: https://bugzilla.proxmox.com/show_bug.cgi?id=5254
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
I recently added the same info to PMG and added them to the return
schema, so copying them over here comes for free, and while far from
complete but better than nothing.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Previously, the /cluster/replication API handler would fail completely
with a HTTP 403 if a user does have VM.Audit permissions for
a single VM/CT. That was due to the 'noerr' parameter not set for
$rpcenv->check()
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
it's not that expensive but we call the endpoint that returns the boot
mode info very frequently, and EFI vars are provided by the firmware,
and there are lots of known cases where firmware was just a plain
mess.
So, don't risk that overly frequent reads will cause some weird side
effect and rather just cache the whole info, it cannot change without
a reboot anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
report if the node is booted in EFI or Legacy BIOS mode, for the
former also pass along the secure boot state.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This new endpoint allows to get the values of config keys that are
either set in the config db or the ceph.conf file.
Values that are set in the ceph.conf file have priority over values set
in the conifg db via 'ceph config set'.
Expects the --config-keys parameter as a semicolon separated list of
"<section>:<config key>" where the section is a section in the ceph.conf
or config db. For example: global:osd_pool_default_size
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Tested-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
since poolid can now contain `/`, it's not possible to use it (properly) as
path parameter anymore.
accordingly:
- merge `read_pool` (`GET /pools/{poolid}`) into 'index' (`GET
/pools/?poolid={poolid}`) (requires clients to extract the only member of the returned array if they want to query an individual pool)
- move `update_pool` to `/pools`, deprecating the old variant with path parameter
- move `delete_pool` to `/pools`, deprecating the old variant with path parameter
- deprecate `read_pool` API endpoint
pool creation is blocked for nested pools where the parent does not already
exist. similarly, the checks for deletion are extended to block deletion if
sub-pools still exist.
the old API endpoints continue to work for non-nested pools. `pvesh ls /pools`
is semi-broken for nested pools, listing the entries, but no methods on them,
since they reference the old API. fixing this would require extending the REST
handling to support a new type of child reference.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@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>
To ease the migration from old-style mailto/mailnotification paramters
for backup jobs, the code will add a ephemeral sendmail endpoint and
a matcher.
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
Ceph does a quick benchmark when creating a new OSD and stores the
osd_mclock_max_capacity_iops_{ssd,hdd} settings in the config DB.
When destroying the OSD, Ceph does not automatically remove these
settings. Keeping them can be problematic if a new OSD with potentially
more performance is added and ends up getting the same OSD ID.
Therefore, we remove these settings ourselves when destroying an OSD.
Removing both variants, hdd and ssd should be fine, as the MON does not
complain if the setting does not exist.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Tested-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
support for it got added to Proxmox repositories, so there is no need to use
custom logic and manual fetching for this anymore.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
caaIdentities was mistakenly labled as a string in a previous patch
and not as an array of strings, as it is defined in the rfc [0].
[0] https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.1
Signed-off-by: Folke Gleumes <f.gleumes@proxmox.com>
That way it shows up in the task-log that something was requested that
cannot work currently.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As even though restricted to some specific endpoints and formats, one
can still scan HTTP, potentially also on the LAN.
We can do this here as the API call is new and was never packaged
since introduced, so this isn't a breaking change.
The TOS one will be removed with the next major release, so not a
problem anymore from then one.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The ToS endpoint ignored data that is needed to detect if EAB needs to
be used. Instead of adding a new endpoint that does the same request,
the tos endpoint is deprecated and replaced by the meta endpoint,
that returns all information returned by the directory.
Signed-off-by: Folke Gleumes <f.gleumes@proxmox.com>
Reviewed-by: Fabian.Grünbichler <f.gruenbichler@proxmox.com>
Tested-by: Fabian.Grünbichler <f.gruenbichler@proxmox.com>
This setting was removed in [1] as part of the v13.0.2 tag. Running
ceph config set global osd_pg_bits 42
results in
Error EINVAL: unrecognized config option 'osd_pg_bits'
So we mark this api as deprecated and make it a no-op operation.
[1] e6acf2d1d5
Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
Allows to automatically create multiple OSDs per physical device. The
main use case are fast NVME drives that would be bottlenecked by a
single OSD service.
By using the 'ceph-volume lvm batch' command instead of the 'ceph-volume
lvm create' for multiple OSDs / device, we don't have to deal with the
split of the drive ourselves.
But this means that the parameters to specify a DB or WAL device won't
work as the 'batch' command doesn't use them. Dedicated DB and WAL
devices don't make much sense anyway if we place the OSDs on fast NVME
drives.
Some other changes to how the command is built were needed as well, as
the 'batch' command needs the path to the disk as a positional argument,
not as '--data /dev/sdX'.
We drop the '--cluster-fsid' parameter because the 'batch' command
doesn't accept it. The 'create' will fall back to reading it from the
ceph.conf file.
Removal of OSDs works as expected without any code changes. As long as
there are other OSDs on a disk, the VG & PV won't be removed, even if
'cleanup' is enabled.
The '--no-auto' parameter is used to avoid the following deprecation
warning:
```
--> DEPRECATION NOTICE
--> You are using the legacy automatic disk sorting behavior
--> The Pacific release will change the default to --no-auto
--> passed data devices: 1 physical, 0 LVM
--> relative data size: 0.3333333333333333
```
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
and not just upgrade.
note that the only other non-login command (ceph_install) is restricted to
root@pam in the web UI anyway, and that the termproxy endpoint is lacking this
check and thus always falls back to a login prompt for non-login commands
requested by non-root users.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
We already trim correctly in the API endpoint's code, but that happens
after the parameter verification from the REST server, and as
patterns are anchored between ^$pattern$ there by default, it fails if
someone sends some whitespace before/after the actual key.
Simply allow arbitrary whitespace, but only at the API endpoint
itself, do not adapt the subscription pattern to avoid that an actual
whitespace sneaks in and let some lower level code throw up on it.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
A simple string regex match on data that the API returns anyway can be
the job of a frontend/client..
Safe to do as we never released this API change in a bumped manager
version and switched the UI to extract this info client-side.
This reverts commit d61728e289.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
actually drop the deprecated ones from the API routes index and
ensure the replacement /pool is returned (/cfg already was)
Signed-off-by: Thomas Lamprecht <t.lamprecht@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 is weird and buggy and breaches the unpriv./priv. separation of
our api daemons, so root-only for now and possibly removal soon.
note that this had several limitations already anyway, like running
in sync context and thus failing after 30s.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Rather than failing with an error claiming that the job doesn't exist.
The disabled status will be visible in the result of the call.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
nested conditionals stretching over multiple lines are always a bit hard to
untangle, so let's make it explicit:
1. is the interface a bridge
2. if it is, are we looking for one?
3. is it something else that we are looking for?
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Like it did here before 9f65a584 ("api: backup: update: check
permissions of delete params too") and like it does in the create
case.
This should not have a practical effect, it's mostly for consistency
and to avoid anybody reading anything into the different orders of
checks between update and create.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
In particular this ensures that the user is allowed to remove data on
the storage, because configuring low retention results in removed
older backups. Of course setting the storage itself also needs to
require the same privilege then.
This is a breaking API change, but it seems sensible to require
permissions on the affected storage too.
Jobs with a dumpdir setting can be configured by root only.
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
