[pve-devel] Error when build i18n file

2021-08-25 Thread Claudio Ferreira
Hi

I did a lot of translations and I want to try it in my env. I followed this
instructions[1] and returned this error:
$ ./po2js.pl -t pve pt_BR.po > pve-lang-pt_BR.js
Use of uninitialized value in concatenation (.) or string at ./po2js.pl
line 91.

Unfortunately, google can't help me.
Some tip?

Regards,
Claudio Ferreira

[1]https://pve.proxmox.com/wiki/Translations
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



Re: [pve-devel] debian11 ifslave bonding bug (with ifupdown1)

2021-08-25 Thread Thomas Lamprecht
Hi,

On 25/08/2021 07:55, alexandre derumier wrote:
> multiple users have reported problems if ifenslave (ifupdown1),
> (maintly upgrade from proxmox6 without switch to ifupdown2)

FWIW, I thought about adding a note to the pve6to7 upgrade checker script
to recommend switching to ifupdown2, IMO most probably would fare better with
that, more features (e.g., live reload) and more and more of our setups run it
too, so it gets good testing too.
 
> 
> when physical interfaces have "auto .."
> 
> auto eth0
> iface eth0
>  ...
> auto eth1
> iface eth1 
>   
> 
> auto bond0
>   iface bond0
>   bond-slaves eth0 eth1
> 
> 
> it seem to come from a bug in ifenslave pre-up script
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968368
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990428
> 
> patch here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=968368;filename=ifenslave-args.diff;msg=5
> 

did you by chance verify that patch already?

> Maybe it could be great to add a note in the upgrade procedure about
> this until it's fixed. (or maybe provide a fixed proxmox ifenslave
> package)

IMO it's always better to ship a fixed package if possible, upgrade notes tend
to get missed by a not negligible percentage of users.

cheers,
Thomas


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


Re: [pve-devel] [RFC firewall] implement fail2ban in firewall

2021-08-25 Thread Oguz Bektas
hi,

thank you for the review :)

On Tue, Aug 24, 2021 at 08:58:10PM +0200, Thomas Lamprecht wrote:
> On 23/08/2021 16:07, Oguz Bektas wrote:
> > only as POC/RFC
> > 
> 
> some thoughts/discussions about the methods/decisions you made would get here.
> 
> E.g., did you think about checking the log just directly here, after all we 
> run
> every 10s anyway, so one could just directly parse the daemon log and add the
> rules directly here, no extra daemon and external instance, which adapts 
> filter
> rules, required (the latter is racy anyway). Not necessarily a must, but the
> simple regex on a single file would be easy, hardest thing would be to handle
> rotations and make reading not completely inefficient; but neither to 
> complicated
> either.

in the v2 it works better after implementing your suggestions (i'll send
it today), now we check if the jail file has changed and only write it then.

> 
> any how, does fail2ban always flushes all their rules, as else our rewrite of
> the filter and raw tables on each update would make it somewhat moot?

i'm not exactly sure, but in my tests the banned IP addresses stayed
even after changing configuration and reloading the services. you can
check with `fail2ban-client banned`.

> 
> Still a few comments for review of that approach, which does not means that
> it is the right approach (see above), but nonetheless, check them out.
> 
> > Signed-off-by: Oguz Bektas 
> > ---
> > 
> > known issues:
> > - see FIXME in generate_fail2ban_config. when update/compile is called
> >   the fail2ban service will be restarted, that leads to reload every 10s
> >   (also the jail conf file is re-written, which i'd like to avoid)
> > - no API integration yet. add to host.fw:
> > 
> > ==
> > [FAIL2BAN]
> > maxretry: N
> > bantime: N # minutes
> 
> your parser would not support above line with the comment though, as
> /^(bantime):\s+(\d+)\S*$/

fixed in v2 along with the other suggestions

> 
> would not allow any whitespace (but arbitrary non-whitespace???) characters
> after the integer..
> 
> > ==
> > 
> > 
> >  debian/control  |  1 +
> >  src/PVE/Firewall.pm | 81 -
> >  2 files changed, 81 insertions(+), 1 deletion(-)
> > 
> > diff --git a/debian/control b/debian/control
> > index 4684c5b..377c9ae 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -17,6 +17,7 @@ Package: pve-firewall
> >  Architecture: any
> >  Conflicts: ulogd,
> >  Depends: ebtables,
> > + fail2ban,
> 
> meh, would prefer to avoid a hard dependency on that package, rather use 
> "Suggests" and
> catch + error out if it isn't available.


ah well, i've enabled it for default, that's why i added it as a hard
dependency.

> 
> >   ipset,
> >   iptables,
> >   libpve-access-control,
> > diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm
> > index edc5336..73ae396 100644
> > --- a/src/PVE/Firewall.pm
> > +++ b/src/PVE/Firewall.pm
> > @@ -1347,6 +1347,26 @@ our $host_option_properties = {
> >  },
> >  };
> >  
> > +our $fail2ban_option_properties = {
> > +   enable => {
> > +   description => "Enable or disable fail2ban on a node.",
> > +   type => 'boolean',
> > +   default => 1,
> > +   },
> > +   maxretry => {
> > +   description => "Amount of failed tries to ban after.",
> > +   type => 'integer',
> > +   minimum => 1,
> > +   default => 3,
> > +   },
> > +   bantime => {
> > +   description => "Minutes to ban suspicious IPs.",
> > +   type => 'integer',
> > +   minimum => 1,
> > +   default => 5,
> > +   },
> > +};
> > +
> >  our $vm_option_properties = {
> >  enable => {
> > description => "Enable/disable firewall rules.",
> > @@ -2407,6 +2427,30 @@ sub ruleset_generate_vm_rules {
> >  }
> >  }
> >  
> > +sub generate_fail2ban_config {
> > +my ($maxretry, $bantime) = @_;
> > +
> > +my $fail2ban_filter = "
> > +[Definition]
> > +failregex = pvedaemon\\[.*authentication failure; rhost= user=.* 
> > msg=.*
> > +ignoreregex =\n";
> > +my $filter_path = '/etc/fail2ban/filter.d/proxmox.conf';
> 
> unnecessary intermediate variable that is only used once locally, just use 
> the path
> directly..
> 
> > +PVE::Tools::file_set_contents($filter_path, $fail2ban_filter);
> > +
> > +my $fail2ban_config = "
> > +[proxmox]
> > +enabled = true
> > +port = https,http,8006
> > +filter = proxmox
> > +logpath = /var/log/daemon.log
> > +maxretry = $maxretry
> > +bantime = $bantime\n";
> 
> we normally use heredoc strings for such multiline stuff
> 
> > +
> > +my $jail_path = '/etc/fail2ban/jail.d/proxmox.conf';
> > +PVE::Tools::file_set_contents($jail_path, $fail2ban_config);
> > +#run_command([qw(systemctl try-reload-or-restart fail2ban.service)]); 
> > # FIXME: excessive... gets called by update/compile every 10 seconds so 
> > disable for now
> 
> you can simply check if the existing configuration, if any, and the 

[pve-devel] [PATCH firewall] implement fail2ban backend

2021-08-25 Thread Oguz Bektas
adds a section "[FAIL2BAN]" in the hostfw configuration, which allows
the properties 'maxretry' and 'bantime' (in minutes) for the GUI ports.

Signed-off-by: Oguz Bektas 
---
RFC->PATCH:

* better parser regex to allow comments in hostfw
* use heredoc for multiline file contents
* check if filter file exists, and if the jail configuration has changed
before writing it out
* removed the unrelated empty lines that i forgot, and the debug print :D
* error out if we can't parse an option


 debian/control  |  1 +
 src/PVE/Firewall.pm | 79 -
 2 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 4684c5b..377c9ae 100644
--- a/debian/control
+++ b/debian/control
@@ -17,6 +17,7 @@ Package: pve-firewall
 Architecture: any
 Conflicts: ulogd,
 Depends: ebtables,
+ fail2ban,
  ipset,
  iptables,
  libpve-access-control,
diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm
index edc5336..ed13ca5 100644
--- a/src/PVE/Firewall.pm
+++ b/src/PVE/Firewall.pm
@@ -1347,6 +1347,26 @@ our $host_option_properties = {
 },
 };
 
+our $fail2ban_option_properties = {
+   enable => {
+   description => "Enable or disable fail2ban on a node.",
+   type => 'boolean',
+   default => 1,
+   },
+   maxretry => {
+   description => "Amount of failed tries to ban after.",
+   type => 'integer',
+   minimum => 1,
+   default => 3,
+   },
+   bantime => {
+   description => "Minutes to ban suspicious IPs.",
+   type => 'integer',
+   minimum => 1,
+   default => 5,
+   },
+};
+
 our $vm_option_properties = {
 enable => {
description => "Enable/disable firewall rules.",
@@ -2407,6 +2427,39 @@ sub ruleset_generate_vm_rules {
 }
 }
 
+sub generate_fail2ban_config {
+my ($maxretry, $bantime) = @_;
+
+my $bantime_seconds = $bantime * 60;
+
+my $fail2ban_filter = < user=.* msg=.*
+ignoreregex =
+CONFIG
+my $filter_path = '/etc/fail2ban/filter.d/proxmox.conf';
+PVE::Tools::file_set_contents($filter_path, $fail2ban_filter) unless -f 
$filter_path;
+
+
+my $fail2ban_jail = <{$1}->{default});
+} else {
+   die "error parsing fail2ban options: $line";
+}
+}
+
 sub generic_fw_config_parser {
 my ($filename, $cluster_conf, $empty_conf, $rule_env) = @_;
 
@@ -2965,6 +3028,11 @@ sub generic_fw_config_parser {
 
my $prefix = "$filename (line $linenr)";
 
+   if ($empty_conf->{fail2ban} && ($line =~ m/^\[fail2ban\]$/i)) {
+   $section = 'fail2ban';
+   next;
+   }
+
if ($empty_conf->{options} && ($line =~ m/^\[options\]$/i)) {
$section = 'options';
next;
@@ -3046,6 +3114,13 @@ sub generic_fw_config_parser {
$res->{aliases}->{lc($data->{name})} = $data;
};
warn "$prefix: $@" if $@;
+   } elsif ($section eq 'fail2ban') {
+   my ($opt, $value) = eval { parse_fail2ban_option($line) };
+   if (my $err = $@) {
+   warn "fail2ban parsing error: $err";
+   next;
+   }
+   $res->{fail2ban}->{$opt} = $value;
} elsif ($section eq 'rules') {
my $rule;
eval { $rule = parse_fw_rule($prefix, $line, $cluster_conf, $res, 
$rule_env); };
@@ -3620,7 +3695,7 @@ sub load_hostfw_conf {
 
 $filename = $hostfw_conf_filename if !defined($filename);
 
-my $empty_conf = { rules => [], options => {}};
+my $empty_conf = { rules => [], options => {}, fail2ban => {}};
 return generic_fw_config_parser($filename, $cluster_conf, $empty_conf, 
'host');
 }
 
@@ -4590,6 +4665,8 @@ sub update {
}
 
my $hostfw_conf = load_hostfw_conf($cluster_conf);
+   my $fail2ban_opts = $hostfw_conf->{fail2ban};
+   generate_fail2ban_config($fail2ban_opts->{maxretry}, 
$fail2ban_opts->{bantime});
 
my ($ruleset, $ipset_ruleset, $rulesetv6, $ebtables_ruleset) = 
compile($cluster_conf, $hostfw_conf);
 
-- 
2.30.2



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



Re: [pve-devel] [RFC firewall] implement fail2ban in firewall

2021-08-25 Thread Thomas Lamprecht
On 25/08/2021 11:34, Oguz Bektas wrote:
> On Tue, Aug 24, 2021 at 08:58:10PM +0200, Thomas Lamprecht wrote:
>> E.g., did you think about checking the log just directly here, after all we 
>> run
>> every 10s anyway, so one could just directly parse the daemon log and add the
>> rules directly here, no extra daemon and external instance, which adapts 
>> filter
>> rules, required (the latter is racy anyway). Not necessarily a must, but the
>> simple regex on a single file would be easy, hardest thing would be to handle
>> rotations and make reading not completely inefficient; but neither to 
>> complicated
>> either.
> 
> in the v2 it works better after implementing your suggestions (i'll send
> it today), now we check if the jail file has changed and only write it then.
> 

that has zero to do with thinking and evaluating about just doing it ourself 
here
though? As there's still an additional dependency with an extra daemon running 
that
may not even interact correctly with how we operate the iptables...

>>
>> any how, does fail2ban always flushes all their rules, as else our rewrite of
>> the filter and raw tables on each update would make it somewhat moot?
> 
> i'm not exactly sure, but in my tests the banned IP addresses stayed
> even after changing configuration and reloading the services. you can
> check with `fail2ban-client banned`.

I did not asked about the banned IP address view from the fail2ban daemon but
rather if the actual *iptables* rules persist, would be good to get sure about
such stuff if wanting to integrate such a feature..


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



[pve-devel] [PATCH pve-docs] fix #844: document first VM/CT start-up delay

2021-08-25 Thread Dylan Whyte
adds paragraphs in the respective qm/pct boot order sections, mentioning
the initial VM/CT startup delay feature.

Signed-off-by: Dylan Whyte 
---
 pct.adoc | 10 ++
 qm.adoc  |  8 
 2 files changed, 18 insertions(+)

diff --git a/pct.adoc b/pct.adoc
index b88569f..deb57ef 100644
--- a/pct.adoc
+++ b/pct.adoc
@@ -433,6 +433,16 @@ always start after those where the parameter is set, and 
this parameter only
 makes sense between the machines running locally on a host, and not
 cluster-wide.
 
+In case your containers rely on slow-to-start resources, for example an 
external
+NFS server, you can also set a per-node delay between the time {pve} boots and
+the time the first container boots. This can be achieved by setting the
+following:
+
+ pvenode config set --startall-onboot-delay 10
+
+where `10` represents the delay in seconds.
+
+
 Hookscripts
 ~~~
 
diff --git a/qm.adoc b/qm.adoc
index c291cb0..7f23ede 100644
--- a/qm.adoc
+++ b/qm.adoc
@@ -923,6 +923,14 @@ start after those where the parameter is set. Further, 
this parameter can only
 be enforced between virtual machines running on the same host, not
 cluster-wide.
 
+In case your VMs rely on slow-to-start resources, for example an external NFS
+server, you can also set a per-node delay between the time {pve} boots and the
+time the first VM boots. This can be achieved by setting the following:
+
+ pvenode config set --startall-onboot-delay 10
+
+where `10` represents the delay in seconds.
+
 
 [[qm_qemu_agent]]
 Qemu Guest Agent
-- 
2.30.2



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



Re: [pve-devel] [PATCH firewall] implement fail2ban backend

2021-08-25 Thread Thomas Lamprecht
Again, I'm not convinced that the approach may be the best we can do, but
as I already looked at it I'll quick review that one nonetheless.

missing "partially fix #1065" prefix.

On 25/08/2021 11:47, Oguz Bektas wrote:
> adds a section "[FAIL2BAN]" in the hostfw configuration, which allows
> the properties 'maxretry' and 'bantime' (in minutes) for the GUI ports.
> 

misses at least some description about what is done with it, as currently it
is "magic" that does the actually banning. Also a link to the wiki this was
derived from, i.e., https://pve.proxmox.com/wiki/Fail2ban would be good.


> Signed-off-by: Oguz Bektas 
> ---
> RFC->PATCH:
> 
> * better parser regex to allow comments in hostfw
> * use heredoc for multiline file contents
> * check if filter file exists, and if the jail configuration has changed
> before writing it out
> * removed the unrelated empty lines that i forgot, and the debug print :D
> * error out if we can't parse an option
> 
> 
>  debian/control  |  1 +
>  src/PVE/Firewall.pm | 79 -
>  2 files changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/debian/control b/debian/control
> index 4684c5b..377c9ae 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -17,6 +17,7 @@ Package: pve-firewall
>  Architecture: any
>  Conflicts: ulogd,
>  Depends: ebtables,
> + fail2ban,
>   ipset,
>   iptables,
>   libpve-access-control,
> diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm
> index edc5336..ed13ca5 100644
> --- a/src/PVE/Firewall.pm
> +++ b/src/PVE/Firewall.pm
> @@ -1347,6 +1347,26 @@ our $host_option_properties = {
>  },
>  };
>  
> +our $fail2ban_option_properties = {
> + enable => {
> + description => "Enable or disable fail2ban on a node.",
> + type => 'boolean',
> + default => 1,

no, please do not enable that by default, follow the common defaults of the
firewall and disable it at start.

Also, FWICT this setting is useless, as it is nowhere checked for??

> + },
> + maxretry => {
> + description => "Amount of failed tries to ban after.",
> + type => 'integer',
> + minimum => 1,
> + default => 3,
> + },
> + bantime => {
> + description => "Minutes to ban suspicious IPs.",
> + type => 'integer',
> + minimum => 1,
> + default => 5,
> + },
> +};
> +
>  our $vm_option_properties = {
>  enable => {
>   description => "Enable/disable firewall rules.",
> @@ -2407,6 +2427,39 @@ sub ruleset_generate_vm_rules {
>  }
>  }
>  
> +sub generate_fail2ban_config {
> +my ($maxretry, $bantime) = @_;
> +
> +my $bantime_seconds = $bantime * 60;
> +
> +my $fail2ban_filter = < +[Definition]
> +failregex = pvedaemon\\[.*authentication failure; rhost= user=.* msg=.*
> +ignoreregex =
> +CONFIG
> +my $filter_path = '/etc/fail2ban/filter.d/proxmox.conf';
> +PVE::Tools::file_set_contents($filter_path, $fail2ban_filter) unless -f 
> $filter_path;

we do not use `unless` see our style guide[0]

[0]: https://pve.proxmox.com/wiki/Perl_Style_Guide#Perl_syntax_choices

> +
> +
> +my $fail2ban_jail = < +[proxmox]
> +enabled = true

always enabled and we nowhere check for the "enable" property to either set this
false or delete the config if it is false, meh...

> +port = https,http,8006
> +filter = proxmox
> +logpath = /var/log/daemon.log
> +maxretry = $maxretry
> +bantime = $bantime_seconds
> +CONFIG
> +
> +my $jail_path = "/etc/fail2ban/jail.d/proxmox.conf";
> +my $current_fail2ban_jail = PVE::Tools::file_get_contents($jail_path);
> +
> +if ($current_fail2ban_jail ne $fail2ban_jail) {
> + PVE::Tools::file_set_contents($jail_path, $fail2ban_jail);
> + run_command([qw(systemctl try-reload-or-restart fail2ban.service)]);
> +}
> +}
> +
>  sub generate_nfqueue {
>  my ($options) = @_;
>  
> @@ -2937,6 +2990,16 @@ sub parse_alias {
>  return undef;
>  }
>  
> +sub parse_fail2ban_option {
> +my ($line) = @_;
> +
> +if ($line =~ m/^(maxretry|bantime):\s+(\d+)\s*(?:#\s*(.*?)\s*)?$/) {

Note that I just mentioned the weird regex and that your example config wouldn't
get parsed by it, not that it has to accept comments.

So, do other FW config properties actually allow comments too? As else it would 
be
really weird if just those two accept them but others don't..

> + return ($1, $2 // $fail2ban_option_properties->{$1}->{default});
> +} else {
> + die "error parsing fail2ban options: $line";
> +}
> +}
> +
>  sub generic_fw_config_parser {
>  my ($filename, $cluster_conf, $empty_conf, $rule_env) = @_;
>  
> @@ -2965,6 +3028,11 @@ sub generic_fw_config_parser {
>  
>   my $prefix = "$filename (line $linenr)";
>  
> + if ($empty_conf->{fail2ban} && ($line =~ m/^\[fail2ban\]$/i)) {
> + $section = 'fail2ban';
> + next;
> + }
> +
>   if ($empty_conf->{options} && ($line =~ m/^\[options\]$/i)) 

Re: [pve-devel] [PATCH pve-docs] fix #844: document first VM/CT start-up delay

2021-08-25 Thread Thomas Lamprecht
On 25/08/2021 15:15, Dylan Whyte wrote:
> adds paragraphs in the respective qm/pct boot order sections, mentioning
> the initial VM/CT startup delay feature.
> 

looks OK content wise but what spoke against placing this in a sub-paragraph to
the "Proxmox Node Management" section:
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_proxmox_node_management
and then link to it from qm/pct? Would avoid some repetition.

semi-related, that section could expand a bit with mentioning the start/stop-all
commands and maybe the task related ones. And while looking at the `pvenode`
command list output I noticed that we could add a `pvenode task stop `
subcommand there too, but really unrelated now, just mentioning to avoid
forgetting it and maybe you want to do that in a separate patch ;-)

> Signed-off-by: Dylan Whyte 
> ---
>  pct.adoc | 10 ++
>  qm.adoc  |  8 
>  2 files changed, 18 insertions(+)
> 
> diff --git a/pct.adoc b/pct.adoc
> index b88569f..deb57ef 100644
> --- a/pct.adoc
> +++ b/pct.adoc
> @@ -433,6 +433,16 @@ always start after those where the parameter is set, and 
> this parameter only
>  makes sense between the machines running locally on a host, and not
>  cluster-wide.
>  
> +In case your containers rely on slow-to-start resources, for example an 
> external
> +NFS server, you can also set a per-node delay between the time {pve} boots 
> and
> +the time the first container boots. This can be achieved by setting the
> +following:
> +
> + pvenode config set --startall-onboot-delay 10
> +
> +where `10` represents the delay in seconds.
> +
> +
>  Hookscripts
>  ~~~
>  
> diff --git a/qm.adoc b/qm.adoc
> index c291cb0..7f23ede 100644
> --- a/qm.adoc
> +++ b/qm.adoc
> @@ -923,6 +923,14 @@ start after those where the parameter is set. Further, 
> this parameter can only
>  be enforced between virtual machines running on the same host, not
>  cluster-wide.
>  
> +In case your VMs rely on slow-to-start resources, for example an external NFS
> +server, you can also set a per-node delay between the time {pve} boots and 
> the
> +time the first VM boots. This can be achieved by setting the following:
> +
> + pvenode config set --startall-onboot-delay 10
> +
> +where `10` represents the delay in seconds.
> +
>  
>  [[qm_qemu_agent]]
>  Qemu Guest Agent
> 



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



Re: [pve-devel] Error when build i18n file

2021-08-25 Thread Thomas Lamprecht
Hi,

On 25/08/2021 03:00, Claudio Ferreira wrote:
> $ ./po2js.pl -t pve pt_BR.po > pve-lang-pt_BR.js
> Use of uninitialized value in concatenation (.) or string at ./po2js.pl
> line 91.
> 
> Unfortunately, google can't help me.
> Some tip?

That's just a warning due to a missing version which we nowadays add to the
beginning of the file to improve marking the cached file stale for a browser.

Nonetheless I pushed out a fallback to "dev-build " to avoid that warning
in the git repo, so either pull or pass a `-v foo` option to "fix" this.

The file should have still been generated though.

cheers,
Thomas



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



[pve-devel] applied: Re: [PATCH v2 container] centos: set /etc/locale.conf to avoid systemd-firstboot hanging

2021-08-25 Thread Thomas Lamprecht
On 24/08/2021 13:35, Oguz Bektas wrote:
> we can set the locale to a sane default to avoid the issue described in
> forum post [0]
> 
> [0]: 
> https://forum.proxmox.com/threads/centos-lxc-containers-require-a-reboot.94972/
> 
> Signed-off-by: Oguz Bektas 
> ---
> v1->v2:
> * only write if file doesn't exist
> 
>  src/PVE/LXC/Setup/CentOS.pm | 5 +
>  1 file changed, 5 insertions(+)
> 
>

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 firewall] implement fail2ban backend

2021-08-25 Thread Mark Schouten

Hi,


Few comments:
* I'd say you would enable this on a cluster-level, for all nodes
* Please allow a whitelist to be added
* Feature request: When fail2ban on a node bans an IP, also add it to a 
blocklist used by VM's with a Proxmox firewall enabled.


-- 
Mark Schouten 
CTO, Tuxis B.V. | https://www.tuxis.nl/ 
 | +31 318 200208



 From:   Oguz Bektas  
 To:
 Sent:   2021-08-25 11:47 
 Subject:   [pve-devel] [PATCH firewall] implement fail2ban backend 

adds a section "[FAIL2BAN]" in the hostfw configuration, which allows 
the properties 'maxretry' and 'bantime' (in minutes) for the GUI ports. 
 
Signed-off-by: Oguz Bektas  
--- 
RFC->PATCH: 
 
* better parser regex to allow comments in hostfw 
* use heredoc for multiline file contents 
* check if filter file exists, and if the jail configuration has changed 
before writing it out 
* removed the unrelated empty lines that i forgot, and the debug print :D 
* error out if we can't parse an option 
 
 
 debian/control      |  1 + 
 src/PVE/Firewall.pm | 79 - 
 2 files changed, 79 insertions(+), 1 deletion(-) 
 
diff --git a/debian/control b/debian/control 
index 4684c5b..377c9ae 100644 
--- a/debian/control 
+++ b/debian/control 
@@ -17,6 +17,7 @@ Package: pve-firewall 
 Architecture: any 
 Conflicts: ulogd, 
 Depends: ebtables, 
+         fail2ban, 
          ipset, 
          iptables, 
          libpve-access-control, 
diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm 
index edc5336..ed13ca5 100644 
--- a/src/PVE/Firewall.pm 
+++ b/src/PVE/Firewall.pm 
@@ -1347,6 +1347,26 @@ our $host_option_properties = { 
     }, 
 }; 
  
+our $fail2ban_option_properties = { 
+     enable => { 
+         description => "Enable or disable fail2ban on a node.", 
+         type => 'boolean', 
+         default => 1, 
+     }, 
+     maxretry => { 
+         description => "Amount of failed tries to ban after.", 
+         type => 'integer', 
+         minimum => 1, 
+         default => 3, 
+     }, 
+     bantime => { 
+         description => "Minutes to ban suspicious IPs.", 
+         type => 'integer', 
+         minimum => 1, 
+         default => 5, 
+     }, 
+}; 
+ 
 our $vm_option_properties = { 
     enable => { 
      description => "Enable/disable firewall rules.", 
@@ -2407,6 +2427,39 @@ sub ruleset_generate_vm_rules { 
     } 
 } 
  
+sub generate_fail2ban_config { 
+    my ($maxretry, $bantime) = @_; 
+ 
+    my $bantime_seconds = $bantime * 60; 
+ 
+    my $fail2ban_filter = < user=.* msg=.* 
+ignoreregex = 
+CONFIG 
+    my $filter_path = '/etc/fail2ban/filter.d/proxmox.conf'; 
+    PVE::Tools::file_set_contents($filter_path, $fail2ban_filter) unless -f 
$filter_path; 
+ 
+ 
+    my $fail2ban_jail = <{$1}->{default}); 
+    } else { 
+     die "error parsing fail2ban options: $line"; 
+    } 
+} 
+ 
 sub generic_fw_config_parser { 
     my ($filename, $cluster_conf, $empty_conf, $rule_env) = @_; 
  
@@ -2965,6 +3028,11 @@ sub generic_fw_config_parser { 
  
      my $prefix = "$filename (line $linenr)"; 
  
+     if ($empty_conf->{fail2ban} && ($line =~ m/^\[fail2ban\]$/i)) { 
+         $section = 'fail2ban'; 
+         next; 
+     } 
+ 
      if ($empty_conf->{options} && ($line =~ m/^\[options\]$/i)) { 
          $section = 'options'; 
          next; 
@@ -3046,6 +3114,13 @@ sub generic_fw_config_parser { 
           $res->{aliases}->{lc($data->{name})} = $data; 
          }; 
          warn "$prefix: $@" if $@; 
+     } elsif ($section eq 'fail2ban') { 
+         my ($opt, $value) = eval { parse_fail2ban_option($line) }; 
+         if (my $err = $@) { 
+          warn "fail2ban parsing error: $err"; 
+          next; 
+         } 
+         $res->{fail2ban}->{$opt} = $value; 
      } elsif ($section eq 'rules') { 
          my $rule; 
          eval { $rule = parse_fw_rule($prefix, $line, $cluster_conf, $res, 
$rule_env); }; 
@@ -3620,7 +3695,7 @@ sub load_hostfw_conf { 
  
     $filename = $hostfw_conf_filename if !defined($filename); 
  
-    my $empty_conf = { rules => [], options => {}}; 
+    my $empty_conf = { rules => [], options => {}, fail2ban => {}}; 
     return generic_fw_config_parser($filename, $cluster_conf, $empty_conf, 
'host'); 
 } 
  
@@ -4590,6 +4665,8 @@ sub update { 
      } 
  
      my $hostfw_conf = load_hostfw_conf($cluster_conf); 
+     my $fail2ban_opts = $hostfw_conf->{fail2ban}; 
+     generate_fail2ban_config($fail2ban_opts->{maxretry}, 
$fail2ban_opts->{bantime}); 
  
      my ($ruleset, $ipset_ruleset, $rulesetv6, $ebtables_ruleset) = 
compile($cluster_conf, $hostfw_conf); 
  
--  
2.30.2 
 
 
 
___ 
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] applied: Re: [PATCH docs] storage: add minimal zfs over iscsi doc

2021-08-25 Thread Thomas Lamprecht
On 06/07/2021 18:45, Stoiko Ivanov wrote:
> mostly copied from the wiki-page[0], and adapted to include LIO as
> target provider.
> 
> Additionally I added a note to explain that the plugin needs ZFS on
> the target side (and does not make your SAN speak ZFS)
> 
> Tested during the PVE 7.0 tests for the plugin I did.
> 
> [0] https://pve.proxmox.com/wiki/Storage:_ZFS_over_iSCSI
> 
> Signed-off-by: Stoiko Ivanov 
> ---
> I plan on adding this about once per Debian release (while testing and
> wondering why we don't have that in our reference docs) - but the plan
> usually gets replaced by something more urgent (and fun).
> 
>  pve-storage-zfs.adoc | 139 +++
>  pvesm.adoc   |   2 +
>  2 files changed, 141 insertions(+)
>  create mode 100644 pve-storage-zfs.adoc
> 
>

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 access-control] fix #3513: pass configured proxy to OpenID

2021-08-25 Thread Thomas Lamprecht
On 13/07/2021 10:09, Fabian Grünbichler wrote:
> Signed-off-by: Fabian Grünbichler 
> ---
> seemed like the easiest way to fix this - but we could also change the
> proxmox-openid-rs API to take the proxy as parameter..
> 

seems OK in general, but do we only want to set it in case it actually has
a value? Not sure if non-existing and existing but empty makes any difference
here - e.g., a behavior that one could possibly imagine is that it would 
override
another source/default for a proxy to force no-proxy...

Mostly just asking if you thought about that, it's probably just a very vague 
and
theoretical issue..

>  src/PVE/API2/OpenId.pm | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/src/PVE/API2/OpenId.pm b/src/PVE/API2/OpenId.pm
> index 22423ba..9080865 100644
> --- a/src/PVE/API2/OpenId.pm
> +++ b/src/PVE/API2/OpenId.pm
> @@ -97,6 +97,9 @@ __PACKAGE__->register_method ({
>  code => sub {
>   my ($param) = @_;
>  
> + my $dcconf = PVE::Cluster::cfs_read_file('datacenter.cfg');
> + local $ENV{all_proxy} = $dcconf->{http_proxy};
> +
>   my $realm = extract_param($param, 'realm');
>   my $redirect_url = extract_param($param, 'redirect-url');
>  
> @@ -149,6 +152,9 @@ __PACKAGE__->register_method ({
>  
>   my $res;
>   eval {
> + my $dcconf = PVE::Cluster::cfs_read_file('datacenter.cfg');
> + local $ENV{all_proxy} = $dcconf->{http_proxy};
> +
>   my ($realm, $private_auth_state) = 
> PVE::RS::OpenId::verify_public_auth_state(
>   $openid_state_path, $param->{'state'});
>  
> 



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


[pve-devel] applied: Re: [PATCH docs] installation: add missing 'you'

2021-08-25 Thread Thomas Lamprecht
On 13/07/2021 12:59, Stoiko Ivanov wrote:
> small glitch I noticed while reading through the pmg-docs
> 
> Signed-off-by: Stoiko Ivanov 
> ---
> With reformat to 80 characters/line this looks far larger (it only adds a you
> in the first part of the sentence)
> 
>  pve-installation.adoc | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
>

applied, thanks!


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



[pve-devel] applied: Re: [PATCH docs v2] pveceph: update pgcalc url

2021-08-25 Thread Thomas Lamprecht
On 14/07/2021 14:51, Dominik Csapak wrote:
> currently the pgcalc tool is only available via waybackmachine of archive.org
> 
> Signed-off-by: Dominik Csapak 
> ---
> changes from v1:
> * link changed from old.ceph.com to archive.org since old.ceph.com is
>   not there anymore...
> 
>  pveceph.adoc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
>

Original URL still does not work, so: 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 v2 1/3] ship proper nodejs module 'pve-eslint'

2021-08-25 Thread Thomas Lamprecht
On 19/07/2021 12:31, Dominik Csapak wrote:
> instead of concatenating the eslint module into our app.js, ship
> a 'pve-eslint' module that exports the built eslint module
> 
> to do this, we have to leave the module type on 'umd' instead of
> changing to 'var' so that nodejs can properly import it.
> 
> Signed-off-by: Dominik Csapak 
> ---
>  Makefile|  2 +-

Does not applies here, did not really investigated yet though:

Applying: ship proper nodejs module 'pve-eslint'
Using index info to reconstruct a base tree...   
error: removal patch leaves file contents
error: src/Makefile: patch does not apply


>  debian/control  |  7 +--
>  debian/dirs |  1 +
>  debian/links|  1 +
>  debian/rules|  5 -
>  patches/0001-adapt-webpack-config.patch | 19 +--
>  src/Makefile| 15 ---
>  src/{ => bin}/app.js|  5 -
>  src/index.js|  3 +++
>  src/package.json|  9 +
>  10 files changed, 33 insertions(+), 34 deletions(-)
>  create mode 100644 debian/dirs
>  create mode 100644 debian/links
>  delete mode 100644 src/Makefile
>  rename src/{ => bin}/app.js (99%)
>  create mode 100644 src/index.js
>  create mode 100644 src/package.json
> 
> diff --git a/Makefile b/Makefile
> index 9dbe3d0..2ac 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -49,7 +49,7 @@ download:
>  # NOTE: needs npm installed, downloads packages from npm
>  .PHONY: buildupstream
>  buildupstream: ${BUILDSRC}
> - cp ${BUILDSRC}/build/eslint.js ${SRCDIR}/eslint.js
> + cp ${BUILDSRC}/build/eslint.js ${SRCDIR}/lib/eslint.js
>  
>  ${BUILDSRC}: ${UPSTREAM} patches
>   rm -rf $@
> diff --git a/debian/control b/debian/control
> index 3f9b014..7ea3664 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -2,13 +2,16 @@ Source: pve-eslint
>  Section: devel
>  Priority: optional
>  Maintainer: Proxmox Support Team 
> -Build-Depends: debhelper (>= 12~)
> +Build-Depends: debhelper (>= 12~),
> +   nodejs,
> +   pkg-js-tools (>= 0.8.11)
>  Standards-Version: 4.3.0
>  Homepage: http://www.proxmox.com
>  
>  Package: pve-eslint
>  Architecture: all
> -Depends: node-commander, node-colors, nodejs, ${misc:Depends},
> +Depends: node-commander, node-colors, nodejs (>= ${nodejs:Version}), 
> ${misc:Depends},
> +Provides: ${nodejs:Provides}
>  Description: ESLint for Proxmox Virtual Environment development
>   This package contains a version of eslint used to develop the
>   Proxmox Virtual Environment, and other Proxmox projects, web GUI.
> diff --git a/debian/dirs b/debian/dirs
> new file mode 100644
> index 000..e772481
> --- /dev/null
> +++ b/debian/dirs
> @@ -0,0 +1 @@
> +usr/bin
> diff --git a/debian/links b/debian/links
> new file mode 100644
> index 000..99342ed
> --- /dev/null
> +++ b/debian/links
> @@ -0,0 +1 @@
> +usr/share/nodejs/pve-eslint/bin/app.js usr/bin/eslint
> diff --git a/debian/rules b/debian/rules
> index 2d33f6a..b4c4090 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -1,4 +1,7 @@
>  #!/usr/bin/make -f
>  
>  %:
> - dh $@
> + dh $@ --with nodejs
> +
> +execute_after_dh_fixperms:
> + chmod --recursive a+x -- debian/*/usr/share/nodejs/pve-eslint/bin/*
> diff --git a/patches/0001-adapt-webpack-config.patch 
> b/patches/0001-adapt-webpack-config.patch
> index 4698e74..b0201e1 100644
> --- a/patches/0001-adapt-webpack-config.patch
> +++ b/patches/0001-adapt-webpack-config.patch
> @@ -3,21 +3,20 @@ From: Dominik Csapak 
>  Date: Thu, 2 Apr 2020 07:10:18 +
>  Subject: [PATCH] adapt webpack config
>  
> -changes to 'var' from 'umd' since we want to use it in the same file
>  adds 'cli-engine' to build (we use it in our wrapper)
>  and target 'node' since we will use it on the cli
>  
>  Signed-off-by: Dominik Csapak 
>  ---
> - webpack.config.js | 6 +++---
> - 1 file changed, 3 insertions(+), 3 deletions(-)
> + webpack.config.js | 3 ++-
> + 1 file changed, 2 insertions(+), 1 deletion(-)
>  
>  diff --git a/webpack.config.js b/webpack.config.js
> -index 29d60cb4..95027075 100644
> +index a22c99b..9209159 100644
>  --- a/webpack.config.js
>  +++ b/webpack.config.js
> -@@ -2,14 +2,14 @@
> - 
> +@@ -4,8 +4,9 @@ const NodePolyfillPlugin = 
> require("node-polyfill-webpack-plugin");
> + /** @type {import("webpack").Configuration} */
>   module.exports = {
>   mode: "none",
>  +target: "node",
> @@ -27,13 +26,5 @@ index 29d60cb4..95027075 100644
>   },
>   output: {
>   filename: "[name].js",
> - library: "[name]",
> --libraryTarget: "umd",
> --globalObject: "this"
> -+libraryTarget: "var"
> - },
> - module: {
> - rules: [
>  -- 
>  2.20.1
> -
> diff --git a/src/Makefile b/src/Makefile
> deleted file mode 100644
> index bef1c57..000