Am 01.04.21 um 15:40 schrieb Thomas Lamprecht:
On 11.03.21 10:22, Fabian Ebner wrote:
on a given node (and storage).
Signed-off-by: Fabian Ebner <f.eb...@proxmox.com>
---
New in v3
PVE/API2/VZDump.pm | 89 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 89 insertions(+)
diff --git a/PVE/API2/VZDump.pm b/PVE/API2/VZDump.pm
index 44376106..109e178b 100644
--- a/PVE/API2/VZDump.pm
+++ b/PVE/API2/VZDump.pm
@@ -146,6 +146,95 @@ __PACKAGE__->register_method ({
return $rpcenv->fork_worker('vzdump', $taskid, $user, $worker);
}});
+__PACKAGE__->register_method ({
+ name => 'defaults',
+ path => 'defaults',
+ method => 'GET',
+ description => "Get the currently configured vzdump defaults.",
+ permissions => {
+ description => "The user needs 'Datastore.Audit' or " .
+ "'Datastore.AllocateSpace' permissions for the specified storage " .
+ "(or default storage if none specified). Some properties are only "
.
+ "returned when the user has 'Sys.Audit' permissions for the node.",
style nit: you can go up to 100 character columns here, also we
Ok
+ user => 'all',
+ },
+ proxyto => 'node',
+ parameters => {
+ additionalProperties => 0,
+ properties => {
+ node => get_standard_option('pve-node'),
+ storage => get_standard_option('pve-storage-id', { optional => 1 }),
+ },
+ },
+ returns => {
+ type => 'object',
+ additionalProperties => 0,
+ properties => PVE::VZDump::Common::json_config_properties(),
above may suggest that all those properties are returned, but we delete some
out flat, so even if one would access this as root@pam they won't get all of
those and may get confused due to API schema/return value mismatch.
Maybe we could derive a hash from above list at module scope, and delete those
keys that never will be returned. That list could also be reused below for
filtering out those unwanted keys too then.
The only key that is always dropped is the deprecated 'size' key. For
privileged users, all others are returned. And the schema says that all
properties are optional. We could create a new hash and drop the
'optional' for those with a default value that are never dropped, but
not sure if that's worth it...
+ },
+ code => sub {
+ my ($param) = @_;
+
+ my $node = extract_param($param, 'node');
+ my $storage = extract_param($param, 'storage');
+
+ my $rpcenv = PVE::RPCEnvironment::get();
+ my $authuser = $rpcenv->get_user();
+
+ my $res = PVE::VZDump::read_vzdump_defaults();
+
+ $res->{storage} = $storage if defined($storage);
+
+ if (!defined($res->{dumpdir}) && !defined($res->{storage})) {
+ $res->{storage} = 'local';
+ }
+
+ if (defined($res->{storage})) {
+ $rpcenv->check_any(
+ $authuser,
+ "/storage/$res->{storage}",
+ ['Datastore.Audit', 'Datastore.AllocateSpace'],
+ );
+
+ my $info = PVE::VZDump::storage_info($res->{storage});
+ foreach my $key (qw(dumpdir prune-backups)) {
style nit, for new code use `for`, `foreach` has no additional
value/functionality
over `for` since a long time (if ever, actually not too sure from top of my
head).
Will do, but might be worth updating the style guide:
"use either of foreach or for when looping over a list of elements."
https://pve.proxmox.com/wiki/Perl_Style_Guide#Perl_syntax_choices
+ $res->{$key} = $info->{$key} if defined($info->{$key});
+ }
+ }
+
+ if (defined($res->{'prune-backups'})) {
+ $res->{'prune-backups'} = PVE::JSONSchema::print_property_string(
+ $res->{'prune-backups'},
+ 'prune-backups',
+ );
+ }
+
+ $res->{mailto} = join(",", @{$res->{mailto}})
+ if defined($res->{mailto});
+
+ $res->{'exclude-path'} = join(",", @{$res->{'exclude-path'}})
+ if defined($res->{'exclude-path'});
+
+ # normal backup users don't need to know these
+ if (!$rpcenv->check($authuser, "/nodes/$node", ['Sys.Audit'], 1)) {
+ delete $res->{mailto};
+ delete $res->{tmpdir};
+ delete $res->{dumpdir};
+ delete $res->{script};
+ delete $res->{bwlimit};
The bwlimit could be exposed though, similarly to how we do already on backup
restore.
For not so privileged user we may want to do something like getting the
min($api_bwlimit, $storage_or_dc_options_bwlimit) to ensure an user cannot
weasel
themself out of admin imposed restrictions... Also, this does not needs to be in
that series, just a general idea...
Ok. From the top of my head, it should be enough to do a
get_bandwith_limit call for the storage together with the potential
override, i.e. res->{bwlimit}.
I mean the admin imposed restriction would still take place on the
vzdump call afterwards, but of course better if the value returned here
is actually what's to be expected afterwards.
+ delete $res->{ionice};
+ }
+
+ my $pool = $res->{pool};
+ if (defined($pool) &&
+ !$rpcenv->check($authuser, "/pool/$pool", ['Pool.Allocate'], 1)) {
+ delete $res->{pool};
+ }
+
+ delete $res->{size}; # deprecated, to be dropped with PVE 7.0
+
+ return $res;
+ }});
+
__PACKAGE__->register_method ({
name => 'extractconfig',
path => 'extractconfig',
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
