[pve-devel] [PATCH container] restore: fix fw.conf restore for PBS

2020-12-07 Thread Fabian Grünbichler
the 'files' command returns a list of hashes, and the filename is
'fw.conf.blob' not 'fw.conf'.

Signed-off-by: Fabian Grünbichler 
---
Tested with container with and without firewall config.

 src/PVE/LXC/Create.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/PVE/LXC/Create.pm b/src/PVE/LXC/Create.pm
index 39902a2..5c64566 100644
--- a/src/PVE/LXC/Create.pm
+++ b/src/PVE/LXC/Create.pm
@@ -280,7 +280,7 @@ sub restore_configuration_from_proxmox_backup {
 my $cmd = "files";
 
 my $list = PVE::Storage::PBSPlugin::run_client_cmd($scfg, $storeid, 
"files", [$name]);
-my $has_fw_conf = grep { $_ eq 'fw.conf' } @$list;
+my $has_fw_conf = grep { $_->{filename} eq 'fw.conf.blob' } @$list;
 
 if ($has_fw_conf) {
my $pve_firewall_dir = '/etc/pve/firewall';
-- 
2.20.1



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


[pve-devel] applied: [PATCH container] restore: fix fw.conf restore for PBS

2020-12-07 Thread Thomas Lamprecht
On 07.12.20 09:18, Fabian Grünbichler wrote:
> the 'files' command returns a list of hashes, and the filename is
> 'fw.conf.blob' not 'fw.conf'.
> 
> Signed-off-by: Fabian Grünbichler 
> ---
> Tested with container with and without firewall config.
> 
>  src/PVE/LXC/Create.pm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
>

applied, thanks!



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


[pve-devel] applied-series: [PATCH manager 1/2] vzdump: warn when both storage and dumpdir are defined in vzdump.conf

2020-12-07 Thread Thomas Lamprecht
On 04.12.20 10:15, Fabian Ebner wrote:
> and prefer storage, because the storage configuration might contain more
> settings. Warning is preferable over dying, because all backups would be
> affected (even if they don't use the vzdump.conf parameters) and the settings
> could've been compatible (i.e. dumpdir being the storage's dump dir). 
> Previously
> one of the two options would randomly be chosen in the loop in new(), because 
> of
> perl hash iteration.
> 
> Reported here: 
> https://forum.proxmox.com/threads/vzdump-times-out-very-often-on-zfs-storage-pool.80035/post-354277
> 
> Signed-off-by: Fabian Ebner 
> ---
>  PVE/VZDump.pm | 5 +
>  1 file changed, 5 insertions(+)
> 
>

applied both patches, thanks!


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] [PATCH proxmox] correct email in changelog

2020-12-07 Thread Hannes Laimer
Signed-off-by: Hannes Laimer 
---
`E: librust-proxmox-dev: debian-changelog-file-contains-invalid-email-address 
root@elsa` prevented a proper install
 proxmox/debian/changelog | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proxmox/debian/changelog b/proxmox/debian/changelog
index 765e2f7..5e8c449 100644
--- a/proxmox/debian/changelog
+++ b/proxmox/debian/changelog
@@ -4,7 +4,7 @@ rust-proxmox (0.8.1-1) unstable; urgency=medium
 
   * fix example array in Cargo.toml
 
- -- root   Sun, 06 Dec 2020 09:07:45 +0100
+ -- Proxmox Support Team   Sun, 06 Dec 2020 09:07:45 +0100
 
 rust-proxmox (0.8.0-1) unstable; urgency=medium
 
-- 
2.20.1



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



Re: [pve-devel] [PATCH http-server v2 1/5] add debug print helper

2020-12-07 Thread Thomas Lamprecht
On 04.12.20 18:56, Stoiko Ivanov wrote:
> Suggested-by: Thomas Lamprecht 
> Signed-off-by: Stoiko Ivanov 
> ---
>  PVE/APIServer/AnyEvent.pm | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/PVE/APIServer/AnyEvent.pm b/PVE/APIServer/AnyEvent.pm
> index c55da7f..7916bdd 100644
> --- a/PVE/APIServer/AnyEvent.pm
> +++ b/PVE/APIServer/AnyEvent.pm
> @@ -66,6 +66,16 @@ my $split_abs_uri = sub {
>  return wantarray ? ($rel_uri, $format) : $rel_uri;
>  };
>  
> +sub dprint {
> +my ($self, $message) = @_;
> +
> +return if !$self->{debug};
> +
> +my ($pkg, $pkgfile, $line, $sub) = caller(1);
> +$sub =~ s/^.+::([^:]+)$/\1/;

Could be a bit simpler, avoiding capturing group and back reference:
$sub =~ s/^(?:.+::)+//;

(note did not actually test it)

> +print "worker[$$]: $pkg +$line: $sub: $message\n";
> +}
> +
>  sub log_request {
>  my ($self, $reqstate) = @_;
>  
> 

please merge 5/5 into this one, makes no sense to have that split and the
use part ordered last.



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



Re: [pve-devel] [PATCH http-server v2 2/5] accept-phase: fix conn_count "leak"

2020-12-07 Thread Thomas Lamprecht
On 04.12.20 18:56, Stoiko Ivanov wrote:
> When handling new connections in 'accept_connections' the number of
> active connections got increased before the AnyEvent::Handle
> registered the callback which would decrement it on error/eof.
> 
> Any error/die beforehand would skip the decrement, and leave the
> process in an endless loop upon exiting in wait_end_loop.
> 
> This can happen e.g. when the call to getpeername fails, or if the
> connection is denied by the ALLOW_FROM/DENY_FROM settings in
> '/etc/default/pveproxy' (which is also a simple reproducer for
> that).
> 
> Additionally it can cause a denial of service, by attempting to
> connect from a denied ip until the connection count exeeds the maximum
> connections of all child-processes.
> 
> Should the connection count become negative a warning is logged in both
> places where we decrement it, in case of a failed AnyEvent::Handle->new(),
> the count is not decremented if this would happen.
> 
> Reported via our community-forum:
> https://forum.proxmox.com/threads/pveproxy-eats-available-ram.79617/
> 
> Co-Authored-by: Dominik Csapak 
> Signed-off-by: Stoiko Ivanov 
> ---
>  PVE/APIServer/AnyEvent.pm | 22 +++---
>  1 file changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/PVE/APIServer/AnyEvent.pm b/PVE/APIServer/AnyEvent.pm
> index 7916bdd..af2fde8 100644
> --- a/PVE/APIServer/AnyEvent.pm
> +++ b/PVE/APIServer/AnyEvent.pm
> @@ -157,6 +157,11 @@ sub client_do_disconnect {
>  
>  &$shutdown_hdl($hdl);
>  
> +if ($self->{conn_count} <= 0) {
> + my $msg = "connection count <= 0!\n";
> + syslog('warn', $msg);
> + $self->dprint("warn: $msg");

see below, at the end, for a comment about doing both, debug print and syslog.

> +}
>  $self->{conn_count}--;
>  
>  print "$$: CLOSE FH" .  $hdl->{fh}->fileno() . " 
> CONN$self->{conn_count}\n" if $self->{debug};
> @@ -1489,8 +1494,6 @@ sub accept {
>  
>  fh_nonblocking $clientfh, 1;
>  
> -$self->{conn_count}++;
> -
>  return $clientfh;
>  }
>  
> @@ -1564,6 +1567,7 @@ sub check_host_access {
>  sub accept_connections {
>  my ($self) = @_;
>  
> +my $hdl_err;

can we please avoid adding to that mess of arbitrary shortened variable names, 
at
least for new ones?

Also, this suggest a bit like it would denote if there's an handle error, but 
what
it actually tells is, if handle creation point got reached - naming should not 
be bound
to much to one use case.

Maybe:
my $handle_creation = 0;

or rather, just reuse $early_err (which has similar naming issues, but is 
pre-existing),
the $self->push_request_header is doing everything in a eval + warn only scope 
anyway.

>  eval {
>  
>   while (my $clientfh = $self->accept()) {
> @@ -1571,7 +1575,7 @@ sub accept_connections {
>   my $reqstate = { keep_alive => $self->{keep_alive} };
>  
>   # stop keep-alive when there are many open connections
> - if ($self->{conn_count} >= $self->{max_conn_soft_limit}) {
> + if ($self->{conn_count} + 1 >= $self->{max_conn_soft_limit}) {
>   $reqstate->{keep_alive} = 0;
>   }
>  
> @@ -1587,6 +1591,8 @@ sub accept_connections {
>   next;
>   }
>  
> + $hdl_err = 1;
> + $self->{conn_count}++;

still no comment whatsoever, that is unacceptable to me for such subtle thing, 
especially
paired with the commit message, which still mentions that increasing the count 
before
registering the callback handle (which we still do, for good reasons), makes it
confusing.

Please note that we explicitly increment here, not after calling ->new, because 
creating the
handle below starts off reading from the fh immediately and can trigger at 
least an on_error
(and possible other) callback.

>   $reqstate->{hdl} = AnyEvent::Handle->new(
>   fh => $clientfh,
>   rbuf_max => 64*1024,
> @@ -1609,6 +1615,7 @@ sub accept_connections {
>   if (my $err = $@) { syslog('err', "$err"); }
>   },
>   ($self->{tls_ctx} ? (tls => "accept", tls_ctx => 
> $self->{tls_ctx}) : ()));
> + $hdl_err = 0;
>  
>   print "$$: ACCEPT FH" .  $clientfh->fileno() . " 
> CONN$self->{conn_count}\n" if $self->{debug};
>  
> @@ -1618,6 +1625,15 @@ sub accept_connections {
>  
>  if (my $err = $@) {
>   syslog('err', $err);
> + if ($hdl_err) {
> + if ($self->{conn_count} <= 0) {
> + my $msg = "connection count <= 0 not decrementing!\n";
> + syslog('warn', $msg);
> + $self->dprint("warn: $msg");

If we already log to syslog, isn't that enough to have it visible?

Or could a single `warn` call do the "correct thing", i.e., stderr so to
syslog if running as systemd service and to console if running in foreground?

Not too hard feelings here though.

> + } else {
> + $self->{conn_count}--;
> + }
> + }
>   $self->{end_loop} = 1;
>  }
>

Re: [pve-devel] [PATCH http-server v2 3/5] accept-phase: shutdown socket on early error

2020-12-07 Thread Thomas Lamprecht
On 04.12.20 18:56, Stoiko Ivanov wrote:
> if an error happens before AnyEvent::Handle registers the cleanup
> callback, we should shutdown the socket, when handling it.
> 
> Co-Authored-by: Dominik Csapak 
> Signed-off-by: Stoiko Ivanov 
> ---
>  PVE/APIServer/AnyEvent.pm | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/PVE/APIServer/AnyEvent.pm b/PVE/APIServer/AnyEvent.pm
> index af2fde8..a679006 100644
> --- a/PVE/APIServer/AnyEvent.pm
> +++ b/PVE/APIServer/AnyEvent.pm
> @@ -1535,6 +1535,11 @@ sub check_host_access {
>  
>  my $cip = Net::IP->new($clientip);
>  
> +if (!$cip) {
> + self->dprint("client IP not parsable: $@");
> + return 0;
> +}
> +
>  my $match_allow = 0;
>  my $match_deny = 0;
>  
> @@ -1567,10 +1572,13 @@ sub check_host_access {
>  sub accept_connections {
>  my ($self) = @_;
>  
> -my $hdl_err;
> +my ($clientfh, $early_err, $hdl_err);

ah OK, ignore my regards to "$early_err" in the previous comment, I thought it 
was pre-exsiting...

>  eval {
>  
> - while (my $clientfh = $self->accept()) {
> + while (1) {
> + $early_err = 1;
> + $clientfh = $self->accept();
> + last if !$clientfh;

what use has above change? Why not keeping it as is, you can still declare 
$clientfh
earlier to extend it's scope:

> + while ($clientfh = $self->accept()) {


>  
>   my $reqstate = { keep_alive => $self->{keep_alive} };
>  
> @@ -1582,14 +1590,19 @@ sub accept_connections {
>   if (my $sin = getpeername($clientfh)) {
>   my ($pfamily, $pport, $phost) = 
> PVE::Tools::unpack_sockaddr_in46($sin);
>   ($reqstate->{peer_port}, $reqstate->{peer_host}) = ($pport,  
> Socket::inet_ntop($pfamily, $phost));
> + } else {
> + shutdown($clientfh, 1);

Do we still plan to send anything? I.e., was `1` (SHUT_RD) used because of 
caution or
are there more explicit reasons for not using `2` (SHUT_RDWR)? Can be fine, but 
would
be good to know.

> + next;
>   }
>  
>   if (!$self->{trusted_env} && 
> !$self->check_host_access($reqstate->{peer_host})) {
>   print "$$: ABORT request from $reqstate->{peer_host} - access 
> denied\n" if $self->{debug};
>   $reqstate->{log}->{code} = 403;
>   $self->log_request($reqstate);
> + shutdown($clientfh, 1);

same as above

>   next;
>   }
> + $early_err = 0;
>  
>   $hdl_err = 1;
>   $self->{conn_count}++;
> @@ -1625,6 +1638,7 @@ sub accept_connections {
>  
>  if (my $err = $@) {
>   syslog('err', $err);
> + shutdown($clientfh, 1) if $early_err || $hdl_err;

same as above, and maybe we could do with just one such flag variables, 
reducing the combination
matrix a bit.

>   if ($hdl_err) {
>   if ($self->{conn_count} <= 0) {
>   my $msg = "connection count <= 0 not decrementing!\n";
> 




___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] applied: [PATCH proxmox] correct email in changelog

2020-12-07 Thread Thomas Lamprecht
On 07.12.20 10:58, Hannes Laimer wrote:
> Signed-off-by: Hannes Laimer 
> ---
> `E: librust-proxmox-dev: debian-changelog-file-contains-invalid-email-address 
> root@elsa` prevented a proper install
>  proxmox/debian/changelog | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
>

applied, thanks!


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



Re: [pve-devel] [PATCH http-server v2 4/5] add debug log for problems during accept

2020-12-07 Thread Thomas Lamprecht
On 04.12.20 18:56, Stoiko Ivanov wrote:
> Signed-off-by: Stoiko Ivanov 
> ---
>  PVE/APIServer/AnyEvent.pm | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/PVE/APIServer/AnyEvent.pm b/PVE/APIServer/AnyEvent.pm
> index a679006..0165264 100644
> --- a/PVE/APIServer/AnyEvent.pm
> +++ b/PVE/APIServer/AnyEvent.pm
> @@ -1547,6 +1547,7 @@ sub check_host_access {
>   foreach my $t (@{$self->{allow_from}}) {
>   if ($t->overlaps($cip)) {
>   $match_allow = 1;
> + $self->dprint("client IP allowed: ". $t->prefix());
>   last;
>   }
>   }
> @@ -1555,6 +1556,7 @@ sub check_host_access {
>  if ($self->{deny_from}) {
>   foreach my $t (@{$self->{deny_from}}) {
>   if ($t->overlaps($cip)) {
> + $self->dprint("client IP denied: ". $t->prefix());
>   $match_deny = 1;
>   last;
>   }
> @@ -1591,6 +1593,7 @@ sub accept_connections {
>   my ($pfamily, $pport, $phost) = 
> PVE::Tools::unpack_sockaddr_in46($sin);
>   ($reqstate->{peer_port}, $reqstate->{peer_host}) = ($pport,  
> Socket::inet_ntop($pfamily, $phost));
>   } else {
> + $self->dprint("getpeername failed: $!");
>   shutdown($clientfh, 1);
>   next;
>   }
> @@ -1638,6 +1641,7 @@ sub accept_connections {
>  
>  if (my $err = $@) {
>   syslog('err', $err);
> + self->dprint("connection accept error: $err");

this cannot work, missing the dollar signe: `self` vs. `$self`

>   shutdown($clientfh, 1) if $early_err || $hdl_err;
>   if ($hdl_err) {
>   if ($self->{conn_count} <= 0) {
> 



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] [PATCH qemu-server] clone_disk: fix offline clone of efidisk

2020-12-07 Thread Fabian Ebner
by partially reverting 4df98f2f14348d0ed57529c4c04a1b5ffb840055 and fixing the
line-length issue differently. The commit didn't update two later usages of
$size, breaking copying the efidisk. The other usage as a parameter to
qemu_img_convert() is luckily only cosmetic, for progress output.

Signed-off-by: Fabian Ebner 
---
 PVE/QemuServer.pm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 70c14ba..607f77b 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -6951,8 +6951,9 @@ sub clone_disk {
} else {
($size) = PVE::Storage::volume_size_info($storecfg, $drive->{file}, 
10);
}
-   $size /= 1024;
-   $newvolid = PVE::Storage::vdisk_alloc($storecfg, $storeid, $newvmid, 
$dst_format, $name, $size);
+   $newvolid = PVE::Storage::vdisk_alloc(
+   $storecfg, $storeid, $newvmid, $dst_format, $name, ($size/1024)
+   );
push @$newvollist, $newvolid;
 
PVE::Storage::activate_volumes($storecfg, [$newvolid]);
-- 
2.20.1



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



Re: [pve-devel] Compiling PBS on arm64

2020-12-07 Thread Kamil Trzciński
Thank you Fabian :)

I was looking for just that.

I was able to remove `.cargo/config` and use `crates.io` to compile
packages. I will post more results once it is done, but I got it rebuild at
least on amd64,
and waiting for arm64 to finish.

Kamil

On Mon, Dec 7, 2020 at 8:54 AM Fabian Grünbichler <
f.gruenbich...@proxmox.com> wrote:

> On December 6, 2020 8:41 pm, Kamil Trzciński wrote:
> > I'm slightly progressing, but I stumbled across some `debcargo` problem.
> It
> > appears that
> > Proxmox uses their own fork of `debcargo`, which is needed in order to
> > build crates
> > without the usage of crates.io. Is this patch published somewhere?
> >
> > rust-debcargo (2.4.2-pve1) proxmox-rust; urgency=medium
> >
> >   * allow overriding maintainer via debcargo.toml
> >   * implement local crate support.patch
> >
> >  -- Proxmox Support Team   Tue, 14 Jan 2020
> 16:13:48
> > +0100
>
>
> https://git.proxmox.com/?p=debcargo-conf.git;a=tree;f=src/debcargo/debian/patches;h=7345cadea4cbffc3174c04e34960e91767892100;hb=refs/heads/proxmox/buster
>
> all of the toolchain backports are published as well on
> git.proxmox.com.. if you want to re-compile all of our devel repo for
> arm64, I suggest familiarizing yourself with debcargo and the
> debcargo-conf repo (especially the upstream and Proxmox readmes) ;)
>
> > On Fri, Dec 4, 2020 at 4:21 PM Kamil Trzciński  wrote:
> >
> >> ARM64 is becoming increasingly popular, especially that PBS seems at
> least
> >> for my usage-pattern to be ideal to run on my arm64 NAS. In the end
> >> I want to try to be able to recompile everything for arm64 and see how
> >> nicely
> >> it works there.
> >>
> >> But first I decided to try to compile all packages for `amd64`. And I'm
> >> scratching my head
> >> to try to do that. This proves to be super hard due to multitude of
> >> dependencies that are backported,
> >> unordered, and require a very special set of commands to be executed
> >> depending on a git repo
> >> since PBS is rust-based.
> >>
> >> Do you maybe happen to have a comprehensive guide that allows you to
> >> compile everything
> >> from the scratch without the use of `/devel` repo, ideally with some
> kind
> >> of CI scripts that would do this heavy lifting?
> >>
> >> Kamil Trzciński
> >>
> >>
> >>
> > ___
> > pve-devel mailing list
> > pve-devel@lists.proxmox.com
> > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> >
>
>
> ___
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


Re: [pve-devel] [PATCH manager] api: metrics/server: test connection on add/update

2020-12-07 Thread Thomas Lamprecht
On 03.12.20 17:55, Thomas Lamprecht wrote:
> On 25.11.20 13:56, Dominik Csapak wrote:
>> just a basic check, but better than not checking at all
>>
> 
> so, just had an issue with the network (some test IPv6 LAN here) and had a 
> metric
> server configured on that net, thus pvestatd spammed the log with "network
> unreachable" messages, and all my resources got the good ol' question mark in 
> the
> gui, so far so good.
> But, I then tried to disable that ext. metrics entry, but we then *also* do a
> connection check which obv. fails ^^
> 

any news on above?


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



Re: [pve-devel] [PATCH manager] api: metrics/server: test connection on add/update

2020-12-07 Thread Dominik Csapak

On 12/7/20 3:30 PM, Thomas Lamprecht wrote:

On 03.12.20 17:55, Thomas Lamprecht wrote:

On 25.11.20 13:56, Dominik Csapak wrote:

just a basic check, but better than not checking at all



so, just had an issue with the network (some test IPv6 LAN here) and had a 
metric
server configured on that net, thus pvestatd spammed the log with "network
unreachable" messages, and all my resources got the good ol' question mark in 
the
gui, so far so good.
But, I then tried to disable that ext. metrics entry, but we then *also* do a
connection check which obv. fails ^^



any news on above?



oh sorry, i have a patch here, i thought i sent it already...
coming right up ..


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] [PATCH manager] status/plugin: do not test connection if disabled

2020-12-07 Thread Dominik Csapak
so that if one disables the plugin (e.g. because it is offline),
it will work even when the server is not reachable

Signed-off-by: Dominik Csapak 
---
if my other series is ok, i'll rebase either this, or my other
series, depending what gets applied first ;)

 PVE/Status/Plugin.pm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/PVE/Status/Plugin.pm b/PVE/Status/Plugin.pm
index c3e0bec1..040b4538 100644
--- a/PVE/Status/Plugin.pm
+++ b/PVE/Status/Plugin.pm
@@ -129,6 +129,9 @@ sub send {
 sub test_connection {
 my ($class, $cfg) = @_;
 
+# do not check connection for disabled plugins
+return if $cfg->{disable};
+
 my $conn = $class->_connect($cfg);
 $class->_disconnect($conn);
 }
-- 
2.20.1



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] applied: [PATCH storage 2/2] nfs and cifs: implement backup notes helper

2020-12-07 Thread Thomas Lamprecht
reuse the one from DirPlugin by directing the call to it, but with
the actual $class. This should stay stable, as we provide an ABI and
try to always use $class->helpers.

Signed-off-by: Thomas Lamprecht 
---
 PVE/Storage/CIFSPlugin.pm | 9 +
 PVE/Storage/NFSPlugin.pm  | 9 +
 2 files changed, 18 insertions(+)

diff --git a/PVE/Storage/CIFSPlugin.pm b/PVE/Storage/CIFSPlugin.pm
index 36339db..be06cc7 100644
--- a/PVE/Storage/CIFSPlugin.pm
+++ b/PVE/Storage/CIFSPlugin.pm
@@ -284,4 +284,13 @@ sub check_connection {
 return 1;
 }
 
+sub get_volume_notes {
+my $class = shift;
+PVE::Storage::DirPlugin::get_volume_notes($class, @_);
+}
+sub update_volume_notes {
+my $class = shift;
+PVE::Storage::DirPlugin::update_volume_notes($class, @_);
+}
+
 1;
diff --git a/PVE/Storage/NFSPlugin.pm b/PVE/Storage/NFSPlugin.pm
index f8d7e68..e8e27c0 100644
--- a/PVE/Storage/NFSPlugin.pm
+++ b/PVE/Storage/NFSPlugin.pm
@@ -171,4 +171,13 @@ sub check_connection {
 return 1;
 }
 
+sub get_volume_notes {
+my $class = shift;
+PVE::Storage::DirPlugin::get_volume_notes($class, @_);
+}
+sub update_volume_notes {
+my $class = shift;
+PVE::Storage::DirPlugin::update_volume_notes($class, @_);
+}
+
 1;
-- 
2.20.1



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] applied: [PATCH storage 1/2] api: content/backup: handle deletion of notes

2020-12-07 Thread Thomas Lamprecht
Previous to this we did not called the plugins update_volume_notes at
all in the case where a user delted the textarea, which results to
passing a falsy value ('').

Also adapt the currently sole implementation to delete the notes field
in the undef or '' value case. This can be done safely, as we default
to returning an empty string if no notes file exists.

Signed-off-by: Thomas Lamprecht 
---
 PVE/API2/Storage/Content.pm | 4 ++--
 PVE/Storage/DirPlugin.pm| 7 +--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/PVE/API2/Storage/Content.pm b/PVE/API2/Storage/Content.pm
index 349231d..c391b35 100644
--- a/PVE/API2/Storage/Content.pm
+++ b/PVE/API2/Storage/Content.pm
@@ -370,8 +370,8 @@ __PACKAGE__->register_method ({
 
PVE::Storage::check_volume_access($rpcenv, $authuser, $cfg, undef, 
$volid);
 
-   if (my $notes = $param->{notes}) {
-   PVE::Storage::update_volume_notes($cfg, $volid, $notes);
+   if (exists $param->{notes}) {
+   PVE::Storage::update_volume_notes($cfg, $volid, $param->{notes});
}
 
return undef;
diff --git a/PVE/Storage/DirPlugin.pm b/PVE/Storage/DirPlugin.pm
index 7bb85e8..2267f11 100644
--- a/PVE/Storage/DirPlugin.pm
+++ b/PVE/Storage/DirPlugin.pm
@@ -107,8 +107,11 @@ sub update_volume_notes {
 my $path = $class->filesystem_path($scfg, $volname);
 $path .= $class->SUPER::NOTES_EXT;
 
-PVE::Tools::file_set_contents($path, $notes);
-
+if (defined($notes) && $notes ne '') {
+   PVE::Tools::file_set_contents($path, $notes);
+} else {
+   unlink $path or die "could not delete notes - $!\n";
+}
 return;
 }
 
-- 
2.20.1



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] applied: [PATCH manager] status/plugin: do not test connection if disabled

2020-12-07 Thread Thomas Lamprecht
On 07.12.20 15:37, Dominik Csapak wrote:
> so that if one disables the plugin (e.g. because it is offline),
> it will work even when the server is not reachable
> 
> Signed-off-by: Dominik Csapak 
> ---
> if my other series is ok, i'll rebase either this, or my other
> series, depending what gets applied first ;)
> 
>  PVE/Status/Plugin.pm | 3 +++
>  1 file changed, 3 insertions(+)
> 
>

applied, thanks!


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel