[pve-devel] Regression in ifupdown2 with templates ?
Hi there.
I'm running a 5 nodes PVE6 cluster, and I'm using ifupdown2 templating features
to create vxlan overlays between my nodes (setup this before the SDN feature
went live). Here's a snippet of my /etc/network/interfaces :
%for i in range(1, 6):
%for v in range(0, 21):
auto vxlan${i*100+v}
iface vxlan${i*100+v}
vxlan-id ${i*100+v}
vxlan-mcastgrp 225.20.118.1
vxlan-physdev enp132s0f0.2018
bridge-access ${i*100+v}
%endfor
%endfor
auto vmbr0
iface vmbr0 inet manual
%for i in range(1, 6):
bridge-ports glob vxlan${i*100}-${i*100+20}
%endfor
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
Everything is working fine with ifupdown2-2.0.1-1+pve10 but if I update
ifupdown to v 3.0.0-1+pve2, my vxlan aren't created anymore. An ifreload -a
outputs these errors :
root@pve4:~# ifreload -a
warning: unable to set template lookup path /etc/network/ifupdown2/templates
('NoneType' object is not callable): are you sure 'python-mako'is installed?
warning: /etc/network/interfaces: line33: vxlan${i*100+v}: unexpected
characters in interface name
error: /etc/network/interfaces: line37: iface vxlan${i*100+v}: invalid syntax
'%endfor'
error: /etc/network/interfaces: line38: iface vxlan${i*100+v}: invalid syntax
'%endfor'
error: /etc/network/interfaces: line44: iface vmbr0: invalid syntax '%endfor'
warning: vmbr0: error parsing glob expression 'vxlan${i*100}-${i*100+20}'
(supported glob syntax: swp1-10.300 or swp[1-10].300 or swp[1-10]sub[0-4].300
warning: vmbr0: error parsing glob expression 'vxlan${i*100}-${i*100+20}'
(supported glob syntax: swp1-10.300 or swp[1-10].300 or swp[1-10]sub[0-4].300
error: vxlan${i*100+v}: invalid vxlan-id '${i*100+v}'
warning: vxlan${i*100+v}: invalid use of bridge attribute (bridge-access) on
non-bridge stanza
error: netlink: vxlan${i*100}-${i*100+20}: cannot enslave link
vxlan${i*100}-${i*100+20} to vmbr0: interface name exceeds max length of 15
warning: vmbr0: error parsing glob expression 'vxlan${i*100}-${i*100+20}'
(supported glob syntax: swp1-10.300 or swp[1-10].300 or swp[1-10]sub[0-4].300
error: vmbr0: bridge port vxlan${i*100}-${i*100+20} does not exist
(yes, python-mako is installed)
I had to downgrade ifupdown2 on all my nodes to get my network stack back
online.
Is there a regression with templating support in ifupdown2 v3 or has something
changed and must be adapted ?
Cheers,
Daniel
--
[ https://www.firewall-services.com/ ]
Daniel Berteaud
FIREWALL-SERVICES SAS, La sécurité des réseaux
Société de Services en Logiciels Libres
Tél : +33.5 56 64 15 32
Matrix: @dani:fws.fr
[ https://www.firewall-services.com/ | https://www.firewall-services.com ]
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Regression in ifupdown2 with templates ?
- Le 16 Juil 20, à 9:29, Alexandre DERUMIER aderum...@odiso.com a écrit : > Hi, > > ifupdown3 have migrated to python3, > > maybe try to install python3-mako package ? Didn't know it was switching to py3 :-) Indeed, installing python3-mako makes the previous error message go away. But the result is even worst now, as ifupdown2 completly fails and don't even configure interfaces which are not using templates in /etc/network/interfaces root@pve5:~# ifreload -a -v info: requesting link dump info: requesting address dump info: requesting netconf dump info: loading builtin modules from ['/usr/share/ifupdown2/addons'] info: module ppp not loaded (module init failed: no /usr/bin/pon found) info: module batman_adv not loaded (module init failed: no /usr/sbin/batctl found) info: executing /sbin/sysctl net.bridge.bridge-allow-multiple-vlans info: module mstpctl not loaded (module init failed: no /sbin/mstpctl found) info: executing /bin/ip rule show info: executing /bin/ip -6 rule show info: address: using default mtu 1500 info: address: max_mtu undefined info: executing /usr/sbin/ip vrf id info: mgmt vrf_context = False info: dhclient: dhclient_retry_on_failure set to 0 info: executing /bin/ip addr help info: address metric support: OK info: module ppp not loaded (module init failed: no /usr/bin/pon found) info: module mstpctl not loaded (module init failed: no /sbin/mstpctl found) info: module batman_adv not loaded (module init failed: no /usr/sbin/batctl found) info: looking for user scripts under /etc/network info: loading scripts under /etc/network/if-pre-up.d ... info: loading scripts under /etc/network/if-up.d ... info: loading scripts under /etc/network/if-post-up.d ... info: loading scripts under /etc/network/if-pre-down.d ... info: loading scripts under /etc/network/if-down.d ... info: loading scripts under /etc/network/if-post-down.d ... info: 'link_master_slave' is set. slave admin state changes will be delayed till the masters admin state change. info: using mgmt iface default prefix eth info: processing interfaces file /etc/network/interfaces info: template processing on interfaces file ... error: main exception: a bytes-like object is required, not 'str' info: exit status 1 root@pve5:~# So it looks like ifupdown2 v3 is not fully compatible with config working in v2. Haven't digged yet into it (those are prod servers, so not easy to play with their network stack) Cheers, Daniel -- [ https://www.firewall-services.com/ ] Daniel Berteaud FIREWALL-SERVICES SAS, La sécurité des réseaux Société de Services en Logiciels Libres Tél : +33.5 56 64 15 32 Matrix: @dani:fws.fr [ https://www.firewall-services.com/ | https://www.firewall-services.com ] ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Regression in ifupdown2 with templates ?
- Le 16 Juil 20, à 10:38, Alexandre DERUMIER aderum...@odiso.com a écrit : >>>error: main exception: a bytes-like object is required, not 'str' > > seem to be a bug here, maybe in template parsing. > > Maybe this commit is fixing it: > > https://github.com/CumulusNetworks/ifupdown2/commit/c44a7a363579d78c42b0cf17ff1b726dcde9296c That's it ! Installing python3-mako and applying this patch made everything working again. I guess it'll picked up on the next ifupdown2 release (or should this be backported in pve package ?) Anyway, many thanks Alexandre ! Regards, Daniel -- [ https://www.firewall-services.com/ ] Daniel Berteaud FIREWALL-SERVICES SAS, La sécurité des réseaux Société de Services en Logiciels Libres Tél : +33.5 56 64 15 32 Matrix: @dani:fws.fr [ https://www.firewall-services.com/ | https://www.firewall-services.com ] ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH proxmox-acme 0/1] Close the acme standalone connection after sending a response
Close connection of the standalone ACME listener after sending a response so next requests can be handled Fixes #3048 Daniel Berteaud (1): Close the acme standalone connection after sending a response src/PVE/ACME/StandAlone.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.26.2 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH proxmox-acme 1/1] Close the acme standalone connection after sending a response
Without this, the first req get a response, but not the next ones as the
listeners stays busy
Fixes #3048
Signed-off-by: Daniel Berteaud
---
src/PVE/ACME/StandAlone.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/PVE/ACME/StandAlone.pm b/src/PVE/ACME/StandAlone.pm
index 0e2ece6..552c35c 100644
--- a/src/PVE/ACME/StandAlone.pm
+++ b/src/PVE/ACME/StandAlone.pm
@@ -55,8 +55,8 @@ sub setup {
} else {
$c->send_error(404, 'Not found.')
}
+ $c->close();
}
- $c->close();
$c = undef;
}
}
--
2.26.2
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH proxmox-acme 1/1] Close the acme standalone connection after sending a response
- Le 1 Oct 20, à 11:15, Fabian Grünbichler f.gruenbich...@proxmox.com a
écrit :
> On September 30, 2020 4:09 pm, Daniel Berteaud wrote:
>> Without this, the first req get a response, but not the next ones as the
>> listeners stays busy
>> Fixes #3048
>>
>> Signed-off-by: Daniel Berteaud
>> ---
>> src/PVE/ACME/StandAlone.pm | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/PVE/ACME/StandAlone.pm b/src/PVE/ACME/StandAlone.pm
>> index 0e2ece6..552c35c 100644
>> --- a/src/PVE/ACME/StandAlone.pm
>> +++ b/src/PVE/ACME/StandAlone.pm
>> @@ -55,8 +55,8 @@ sub setup {
>> } else {
>> $c->send_error(404, 'Not found.')
>> }
>> +$c->close();
>
> I think this is not right - we only end up looping/blocking on
> get_request if the client requested keep alive, in which case the server
> should obviously not close the connection..
>
> I guess we have to fork (up to some limit) on accept()? it's obviously
> not ideal that anybody can race with the LE validation attempts and
> block the single request handler ;)
Indeed, having a few more handlers could limit the risk of this happening.
>
> maybe you can change something in your apache config to close the
> connection (or rather, to propagate the connection closing from the
> actual client)? it looks like this can only affect you if
> - your apache proxy keeps the connection open
> - your apache proxy does not re-use the open connection
You're right, the issue was on my rev proxy, which didn't re-used keep-alived
connexions as it should (it was an old httpd 2.2.3 on a CentOS 5 box, on which
I had no control).
Switching my setup so it now runs behind a nginx proxypass works normaly
without any modification
Sorry for not having looked at this more closely before posting ;-)
Cheers,
Daniel
--
[ https://www.firewall-services.com/ ]
Daniel Berteaud
FIREWALL-SERVICES SAS, La sécurité des réseaux
Société de Services en Logiciels Libres
Tél : +33.5 56 64 15 32
Matrix: @dani:fws.fr
[ https://www.firewall-services.com/ | https://www.firewall-services.com ]
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage] ZFSPlugin: untaint lun number
- Le 9 Oct 20, à 17:13, Stoiko Ivanov s.iva...@proxmox.com a écrit :
> ZFS over iSCSI fetches information about the disk-images via ssh, thus
> the obtainted data is tainted (perlsec (1)).
>
> Since pvedaemon runs with '-T' enabled trying to start a VM via GUI/API
> failed,
> while it still worked via `qm` or `pvesh`.
>
> The issue surfaced after commit cb9db10c1a9855cf40ff13e81f9dd97d6a9b2698 in
> pve-common ('run_command: improve performance for logging and long lines'),
> and results from concatenating the original (tainted) buffer to a variable,
> instead of a captured subgroup.
>
> Untainting the value in ZFSPlugin should not cause any regressiosn, since the
> other 3 target providers already have a match on '\d+' for retrieving the
> lun number.
>
> reported via pve-user [0].
>
> reproduced and tested by setting up a LIO-target (on top of a virtual PVE),
> adding it as storage and trying to start a guest (with a disk on the
> ZFS over iSCSI storage) with `perl -T /usr/sbin/qm start $vmid`
>
> [0] https://lists.proxmox.com/pipermail/pve-user/2020-October/172055.html
>
> Signed-off-by: Stoiko Ivanov
> ---
> PVE/Storage/ZFSPlugin.pm | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/PVE/Storage/ZFSPlugin.pm b/PVE/Storage/ZFSPlugin.pm
> index 383f0a0..63b9551 100644
> --- a/PVE/Storage/ZFSPlugin.pm
> +++ b/PVE/Storage/ZFSPlugin.pm
> @@ -159,7 +159,11 @@ sub zfs_get_lun_number {
>
> die "could not find lun_number for guid $guid" if !$guid;
>
> -return $class->zfs_request($scfg, undef, 'list_view', $guid);
> +if ($class->zfs_request($scfg, undef, 'list_view', $guid) =~ /^(\d+)$/) {
> + return $1;
> +}
> +
> +die "lun_number for guid $guid is not a number";
> }
Will give this a try ASAP !
Thanks
--
[ https://www.firewall-services.com/ ]
Daniel Berteaud
FIREWALL-SERVICES SAS, La sécurité des réseaux
Société de Services en Logiciels Libres
Tél : +33.5 56 64 15 32
Matrix: @dani:fws.fr
[ https://www.firewall-services.com/ | https://www.firewall-services.com ]
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage] ZFSPlugin: untaint lun number
- Le 9 Oct 20, à 17:26, Daniel Berteaud dan...@firewall-services.com a
écrit :
> - Le 9 Oct 20, à 17:13, Stoiko Ivanov s.iva...@proxmox.com a écrit :
>
>> ZFS over iSCSI fetches information about the disk-images via ssh, thus
>> the obtainted data is tainted (perlsec (1)).
>>
>> Since pvedaemon runs with '-T' enabled trying to start a VM via GUI/API
>> failed,
>> while it still worked via `qm` or `pvesh`.
>>
>> The issue surfaced after commit cb9db10c1a9855cf40ff13e81f9dd97d6a9b2698 in
>> pve-common ('run_command: improve performance for logging and long lines'),
>> and results from concatenating the original (tainted) buffer to a variable,
>> instead of a captured subgroup.
>>
>> Untainting the value in ZFSPlugin should not cause any regressiosn, since the
>> other 3 target providers already have a match on '\d+' for retrieving the
>> lun number.
>>
>> reported via pve-user [0].
>>
>> reproduced and tested by setting up a LIO-target (on top of a virtual PVE),
>> adding it as storage and trying to start a guest (with a disk on the
>> ZFS over iSCSI storage) with `perl -T /usr/sbin/qm start $vmid`
>>
>> [0] https://lists.proxmox.com/pipermail/pve-user/2020-October/172055.html
>>
>> Signed-off-by: Stoiko Ivanov
>> ---
>> PVE/Storage/ZFSPlugin.pm | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/PVE/Storage/ZFSPlugin.pm b/PVE/Storage/ZFSPlugin.pm
>> index 383f0a0..63b9551 100644
>> --- a/PVE/Storage/ZFSPlugin.pm
>> +++ b/PVE/Storage/ZFSPlugin.pm
>> @@ -159,7 +159,11 @@ sub zfs_get_lun_number {
>>
>> die "could not find lun_number for guid $guid" if !$guid;
>>
>> -return $class->zfs_request($scfg, undef, 'list_view', $guid);
>> +if ($class->zfs_request($scfg, undef, 'list_view', $guid) =~ /^(\d+)$/)
>> {
>> +return $1;
>> +}
>> +
>> +die "lun_number for guid $guid is not a number";
>> }
>
I can confirm this is fixing the issue of the VM not starting from the web
interface. There's still a (probably) related issue : ZFS over iSCSI disks
can't be removed (eg, at the end of a live disk move) :
Use of uninitialized value in die at /usr/share/perl5/PVE/Storage/LunCmd/LIO.pm
line 337.
error during cfs-locked 'storage-iscsi-zfs-zol1-prd' operation: command
'/usr/bin/ssh -o 'BatchMode=yes' -i /etc/pve/priv/zfs/10.29.255.252_id_rsa
root@10.29.255.252 -- /usr/bin/targetcli
/iscsi/iqn.2019-10.fr.fws.pve:prod/tpg1/luns/ delete lun1' failed: Insecure
dependency in exec while running with -T switch at
/usr/share/perl/5.28/IPC/Open3.pm line 178.
...propagated at /usr/share/perl5/PVE/Storage/LunCmd/LIO.pm line 337.
It might be only affecting the LIO backend though
Cheers,
Daniel
--
[ https://www.firewall-services.com/ ]
Daniel Berteaud
FIREWALL-SERVICES SAS, La sécurité des réseaux
Société de Services en Logiciels Libres
Tél : +33.5 56 64 15 32
Matrix: @dani:fws.fr
[ https://www.firewall-services.com/ | https://www.firewall-services.com ]
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage 0/2] LIO: fix tainted config and minor cleanup
- Le 12 Oct 20, à 17:34, Stoiko Ivanov s.iva...@proxmox.com a écrit : > This patchset follows the fix in 609f117ff24d2cff6b155e1d4b1175ceebe5bd7b. > Since several operations rely on values read from the remote target's > LIO config (which is tainted), this patchset untaints the settings, which are > actually needed (and stores only those), while reading the config. > > The second patch removes two small left-over statements, which confused me > while debugging. > > Tested very roughly (adding disks, create/rollback snapshot, remove disk) on > a VM backed by a LIO-iSCSI target. > Just tested it on my install, and everything seems to be working again (tested disk creation, removal, resize, move, snapshot, rollback, delete snapshot) Thanks ! -- [ https://www.firewall-services.com/ ] Daniel Berteaud FIREWALL-SERVICES SAS, La sécurité des réseaux Société de Services en Logiciels Libres Tél : +33.5 56 64 15 32 Matrix: @dani:fws.fr [ https://www.firewall-services.com/ | https://www.firewall-services.com ] ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Proposal: support for atomic snapshot of all VM disks at once
--- Begin Message --- - Le 4 Oct 24, à 17:13, Dietmar Maurer diet...@proxmox.com a écrit : > We already make sure that shaphots of a group of volumes are atomic at qemu > level (VM is halted while snapshots are created), so I wonder > if there is any real advantage here? I think there could be one advantage : reduce the freez time during snapshot. I take regular snapshots of my VM, and it causes timeshifts of a few seconds (which chronyd inside the guest takes a bit a time to correct). It's just a 1-4 sec, but it can cause issues. One example is minio, when used with an OIDC login (as minio doesn't support any clock skew, login can fail if minio lags just a few seconds behind the IDP) ++ -- Daniel Berteaud --- End Message --- ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
