--- Begin Message ---
Hello,
This is my first time writing to this mailing list. I have never
contributed to proxmox but I would like to try and write a feature that
allows native container support (not inside an LXC or VM).
My goal would be that you could manage those containers much like
LXC
A bug in proxmox-ve-config caused the key to be defaulted to on, if it
didn't exist in the configuration. Add this scenario to the
integration tests, so we can potentially catch problems with the
missing firewall key via the integration tests.
Signed-off-by: Stefan Hanreich
---
proxmox-firewall/
v2 with slightly updated patch from upstream master:
https://lore.proxmox.com/pve-devel/20250313113214.23456-1-f.gruenbich...@proxmox.com/T/#u
On March 11, 2025 9:44 am, Fabian Grünbichler wrote:
> this broke with 2.2.7, and can potentially cause data loss or
> inconsistency. the patch basically
a comment and small nit inline, other than that LGMT!
Consider this and the following three patches:
Tested-by: Hannes Laimer
Reviewed-by: Hannes Laimer
On 13.03.25 14:22, Stefan Hanreich wrote:
When the firewall key wasn't present in the network device
configuration of a guest, the firewall
applied and s/nt_/nf_/ (except where referencing existing commit, to not
mess up copy&paste sesarches)
On Wed, Mar 12, 2025 at 02:20:24PM +0100, Hannes Laimer wrote:
> ... on the guest table. There is no reason to not repect that option
> on those two chains. These two were missed in the reference
Thanks for contributing to Proxmox VE! Have you already signed a CLA [1]
with us? Otherwise we cannot accept your contribution
Gave this patch a quick spin on my shiny new dual-stack Simple Zone with
DHCP enabled. Could reproduce the issue and the patch fixed it, so
consider this:
Tested-by: Stef
On 13.03.2025 16:16, Thomas Lamprecht wrote:
On 13/03/2025 13:49, Gabriel Goller wrote:
Resolve conflict between F_ISIS_UNIT_TEST and ISIS_OPT_DUMMY_AS_LOOPBACK
which were both using the same bit value (0x01). This collision caused
unit test mode to be unintentionally enabled when DUMMY_AS_LOOPB
Tested these changes, I could reproduce the described problem, and
after applying the patches the macros only matches the correct ICMP
packets, not all.
so consider this:
Tested-by: Hannes Laimer
On 04.02.25 10:57, Stefan Hanreich wrote:
Rules using the Ping macro were wrongly generated due to
Previously, notification templates could be modified by the user, but
these were overwritten again with installing newer package versions of
pve-manager and proxmox-backup.
Now override templates can be created cluster-wide in the path
“/etc/{pve,proxmox-backup}/notification-templates/{namespace}”
On 13/03/2025 13:49, Gabriel Goller wrote:
> Resolve conflict between F_ISIS_UNIT_TEST and ISIS_OPT_DUMMY_AS_LOOPBACK
> which were both using the same bit value (0x01). This collision caused
> unit test mode to be unintentionally enabled when DUMMY_AS_LOOPBACK was set.
>
This is also wrong at ups
ipfilter ipsets and rules were still generated, even if the firewall
was disabled for the network device.
Signed-off-by: Stefan Hanreich
---
proxmox-firewall/src/firewall.rs | 4
1 file changed, 4 insertions(+)
diff --git a/proxmox-firewall/src/firewall.rs b/proxmox-firewall/src/firewall.r
The firewall generated mac filters for outgoing packets even if the
firewall was disabled for a specific interface. This was applicable to
ARP packets as well.
Signed-off-by: Stefan Hanreich
---
proxmox-firewall/src/firewall.rs | 1 +
1 file changed, 1 insertion(+)
diff --git a/proxmox-firewall
gave this a test on my machine:
* tested outgoing/incoming connectivity for guests
* tested DHCP in a simple zone
* checked generated firewall rulesets with setting on/off
small nit: settings is called nf_conntrack_allow_invalid, not
nt_conntrack_allow_invalid - maybe we could change that on commi
https://lore.proxmox.com/pve-devel/20250313132231.166477-1-s.hanre...@proxmox.com/T/
On 2/19/25 11:09, Stefan Hanreich wrote:
> When the firewall key wasn't present in the network device
> configuration of a guest, the firewall defaulted to on instead of off.
> Since the UI omitted the firewall se
When the firewall key wasn't present in the network device
configuration of a guest, the firewall defaulted to on instead of off.
Since the UI omitted the firewall setting in the API calls when it is
unchecked, there was no way for the firewall to be turned off for a
specific network device of a gu
The network device configuration doesn't return a reference anymore,
so we do not need to dereference here anymore.
Signed-off-by: Stefan Hanreich
---
Notes:
This and the subsequent tests patch require a bump of proxmox-ve-config to
work
proxmox-firewall/src/firewall.rs | 4 ++--
1 file c
applied - but also generally updated d/control to fit the current
dependencies
On Thu, Mar 13, 2025 at 01:46:08PM +0100, Stefan Hanreich wrote:
> Signed-off-by: Stefan Hanreich
> ---
>
> Notes:
> Changes from v1:
> * split from
> https://lore.proxmox.com/pve-devel/20250123101300.72647-1
applied series, thanks
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
split into two series and rebased on top of master:
https://lore.proxmox.com/pve-devel/20250313124608.136789-1-s.hanre...@proxmox.com/T/#u
https://lore.proxmox.com/pve-devel/20250313124920.138960-1-s.hanre...@proxmox.com/T/#u
On 1/23/25 11:12, Stefan Hanreich wrote:
> Signed-off-by: Stefan Hanre
Security groups can be bound to a specific interface. The notion of
this breaks down when considering the forward direction, since there
are two interfaces involved: incoming and outgoing, which can be
different depending on the kind of traffic.
With the current implementation, the firewall refuse
Resolve conflict between F_ISIS_UNIT_TEST and ISIS_OPT_DUMMY_AS_LOOPBACK
which were both using the same bit value (0x01). This collision caused
unit test mode to be unintentionally enabled when DUMMY_AS_LOOPBACK was set.
Signed-off-by: Gabriel Goller
---
* I'm not sure about the debian version n
There was a bug where rulesets with security groups bound to a
specific interface would cause the firewall to fail to create a new
ruleset. Catch this by adding a security group bound to an interface
to the ruleset.
Signed-off-by: Stefan Hanreich
---
proxmox-firewall/tests/input/cluster.fw
Signed-off-by: Stefan Hanreich
---
Notes:
Changes from v1:
* split from
https://lore.proxmox.com/pve-devel/20250123101300.72647-1-s.hanre...@proxmox.com/
* update d/control
Cargo.toml | 2 +-
debian/control | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/
most of the building blocks are already there:
* we can have qcow2 files in an import storage
* we can import qcow2 files via the api from such a storage
this series fills in the missing bits & pieces:
* allow uploading qcow2 files into an import storage via the webgui
* adding the possibility to
this broke with 2.2.7, and can potentially cause data loss or
inconsistency. the patch basically reverts to pre-2.2.7 behaviour,
verified via a fio benchmark.
reported on our forum: https://forum.proxmox.com/threads/163066
cherry-picked from upstream master
Signed-off-by: Fabian Grünbichler
Tes
this sometimes comes in handy when we only want to show specific files.
Signed-off-by: Dominik Csapak
---
www/manager6/form/FileSelector.js | 10 ++
1 file changed, 10 insertions(+)
diff --git a/www/manager6/form/FileSelector.js
b/www/manager6/form/FileSelector.js
index ef2bedf9..9db20
partially fixes #2424
Signed-off-by: Dominik Csapak
---
www/manager6/window/UploadToStorage.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/www/manager6/window/UploadToStorage.js
b/www/manager6/window/UploadToStorage.js
index cdf548a8..3ce2d1f5 100644
--- a/www/manager6/w
adds a checkbox 'import image' above the storage selector which:
* hides the original storage selector
* shows a 'source storage' selector
* shows a 'import file' selector
* shows a 'target storage' selector
Since the wizard and the hd edit share this panel, this also works in
the wizard.
Signed-
so users can upload qcow2 files directly in the ui
Signed-off-by: Dominik Csapak
---
src/PVE/API2/Storage/Status.pm | 17 -
src/PVE/Storage.pm | 2 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/PVE/API2/Storage/Status.pm b/src/PVE/API2/Storag
applied, thanks
On Thu, Mar 13, 2025 at 09:30:26AM +0100, Dominik Csapak wrote:
> we cleaned up extracted images, but logged it even for non extracted
> ones. Only log this when we actually cleaned anything up.
>
> Signed-off-by: Dominik Csapak
> ---
> PVE/API2/Qemu.pm | 6 --
> 1 file chan
Hi, thanks for the patch! I can't comment on the change itself, but have
some remarks on the commit message:
On 11/03/2025 12:52, Alexander Abraham wrote:
> A user reported a bug where they were attempting to login into our
> app for PVE and they used a password with two spaces at the end.
> The l
we cleaned up extracted images, but logged it even for non extracted
ones. Only log this when we actually cleaned anything up.
Signed-off-by: Dominik Csapak
---
PVE/API2/Qemu.pm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index dc
I can confirm that logging in with passwords containing leading or
trailing whitespaces did not work previously, and your patch fixes the
issue.
However, please note that pve_flutter_frontend is the wrong repository,
as this patch is meant to be applied on the proxmox_login_manager
repository
33 matches
Mail list logo
