It's not enough to check whether $! is set. From "perldoc perlvar":
> Many system or library calls set "errno" if they fail, to
> indicate the cause of failure. They usually do not set "errno"
> to zero if they succeed and may set "errno" to a non-zero value
> on success. This means "errno", hence $!, is meaningful only
> *immediately* after a failure:
To protect against potential issues, check the return value of unlink
and only check $! if it failed.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
we cannot import the state of the efivars (e.g. boot order)
so add a warning for that
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: add new warning to return schema ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
does not really make sense, and if the plugin wants that, it can still
be done, like we do here for the ESXiPlugin
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This allows the frontends to translate them and avoids somewhat
duplicated info by having some warnings explicitly (ignored-volumes)
while others are in the warnings array.
By passing along the key and the value the frontend can also show the
warnings in-line, e.g. by marking a disk-entry in a grid as having
potential problems.
Ideally we'd have a central list of known types used for the API
return schema enum and to check when calling the $warn closure, but as
we only got three warnings keep this as is and only add a comment.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This will be used for returning the base meta information of a
external VM that is about to be imported into Proxmox VE.
A front-end can use this endpoint to show the proposed configs with
potential override switches to the user, so that they can adapt the
most important options to ensure that import can work.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
[ TL: add more commit message with some background ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The download-url API endpoint has some implications that admins are
unaware of, namely that it basically allow to scan the whole network
via HTTP URLs, and potentially even download some image that the user
should not have access to and adding to a VM that the user controls.
That's why in addition to the Datastore.AllocateTemplate privilege on
the storage, the Sys.Modify on the whole Cluster was required to use
the API call. That design was chosen as we were not fully sure if a
separate privilege is warranted, but user feedback has shown that the
(not so big) cost of adding such a new privilege is justified.
Change the permission check to allow the combination of
Datastore.AllocateTemplate on the storage and either 'Sys.Modify' on
/, for backwards compatibility, or the newer 'Sys.AccessNetwork' on
the node that handles the download.
Using a node-specific ACL path allows admins to e.g. prepare one
specific node's firewall so that pveproxy can access only a safe set
of hosts via outgoing HTTP (not stemming from valid connection
tracking to the PVE API), and thus even further limit the privileges
of users or tools that are trusted to download images to a storage.
Buglink: 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>
It is possible to run multiple OSD daemons on one disk. The new
'osdid-list' parameter returns an array of all OSD IDs found on the
disk.
The old 'osdid' parameter is kept for compatibility. We might want to
deprecate / remove it in the future.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
adds information for how to decompress isos.
generates the compressor regex from a list of comression formats (to
avoid redundancy)
extends the download_url wtih the functionality to handley compression
for images
Signed-off-by: Philipp Hufnagl <p.hufnagl@proxmox.com>
removed Data::Dumper and a newline
Signed-off-by: Philipp Hufnagl <p.hufnagl@proxmox.com>
re-added the newline, but fixed up the indentation at that line..
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
The Proxmox VE storage systems doesn't cares at all if the
Datastore.Allocate privilege is present if no Proxmox VE storage will
be allocated.
Note, if we want to restrict this further as Sys.Modify on /, which
is already quite a powerful permission, we should probably add a new
one under the Sys. space, e.g., Sys.Disk.Use or the like.
This is a step in splitting the disk manage code out of the
pve-storage package, and maybe even repository
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Local disk and storage creation and listing is something rather
different than the Proxmox VE storage client ABI that provides an
abstract access to a variety of storage types, specifically targeted
to virtual guests images, templates and backups.
The Datastore.* privilege group is specifically made for auditing the
abstract configuration, here the name must be interpreted in context
and not just assumed that due to "datastore" sounding like it could
have to do something with disks or creation of local storage it just
must be a good fit.
Luckily, Sys.Audit was already used too, which is the correct one
here, this is for node specific (HW) details, not some config for
accessing datastore in a restricted way.
This is a step in splitting the disk manage code out of the
pve-storage package, and maybe even repository.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Move the warning over to creating and updating storage configs, which
is much less noisy as the constantly called activate storage (e.g.,
pvestatd).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This avoids confusing errors about other properties when the storage
type doesn't match. By highlighting that the type doesn't match, users
should know right away what the issue is.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
