Signed-off-by: Alexandre Derumier aderum...@odiso.com
---
data/PVE/Network.pm |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/data/PVE/Network.pm b/data/PVE/Network.pm
index ff4aa73..b30ec54 100644
--- a/data/PVE/Network.pm
+++ b/data/PVE/Network.pm
@@ -77,7 +77,8
I would like to known if we want to support firewall for random openvz veth
name ?
not really (no).
(by the way, why do we allow to setup random name ?)
because it is possible
Currently, my openvz patchs hang on tap_plug (cleanup_firewall_bridge)/unplug
(create_firewall_bridge_linux),
I thought you do not want random names?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
I thought you do not want random names?
Sorry - simply ignore me (I just read the patch more carefully).
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Ok, I applied a slightly different patch - hop that work for you?
diff --git a/data/PVE/Network.pm b/data/PVE/Network.pm
index ff4aa73..b141d09 100644
--- a/data/PVE/Network.pm
+++ b/data/PVE/Network.pm
@@ -66,7 +66,7 @@ my $read_bridge_mtu = sub {
};
my $parse_tap_devive_name = sub {
-my
Works perfectly. Thanks !
(tested with my openvz patches)
- Mail original -
De: Dietmar Maurer diet...@proxmox.com
À: Alexandre Derumier aderum...@odiso.com, pve-devel@pve.proxmox.com
Envoyé: Vendredi 16 Mai 2014 11:19:44
Objet: RE: [pve-devel] [PATCH] allow random openvz interface
(tested with my openvz patches)
I will try to include them next week (on Monday).
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
We currently use the following format for rules:
#TYPE ACTION IFACE SOURCE DEST PROTO D-PORT S-PORT
IN ACCEPT(MACRO) net0 192.168.2.0 1.2.3.4 tcp 80 20
This hard to write/read because you need to remember the correct order.
So I thought about using something like:
in ACCEPT(MACRO) -i net0
#TYPE ACTION IFACE SOURCE DEST PROTO D-PORT S-PORT
IN ACCEPT(MACRO) net0 192.168.2.0 1.2.3.4 tcp 80 20
This hard to write/read because you need to remember the correct order.
So I thought about using something like:
in ACCEPT(MACRO) -i net0 -source 192.168.2.0 -dest 1.2.3.4 -p tcp -dport 80
On Fri, 16 May 2014 15:44:52 +
Dietmar Maurer diet...@proxmox.com wrote:
We currently use the following format for rules:
#TYPE ACTION IFACE SOURCE DEST PROTO D-PORT S-PORT
IN ACCEPT(MACRO) net0 192.168.2.0 1.2.3.4 tcp 80 20
This hard to write/read because you need to remember the
Why not stick to the iptables format?
in ACCEPT(MACRO) -i net0 -s 192.168.2.0 -d 1.2.3.4 -p tcp -dport 80 -sport 20
beaucse we cannot provide full iptables functionality, and iptables format
is really clumsy (for example multiport maches, ipsets, ...).
But above syntax is basically iptables
Why not stick to the iptables format?
in ACCEPT(MACRO) -i net0 -s 192.168.2.0 -d 1.2.3.4 -p tcp -dport 80
-sport 20
beaucse we cannot provide full iptables functionality, and iptables format is
really clumsy (for example multiport maches, ipsets, ...).
For example, we want to write:
-
-Original Message-
From: pve-devel [mailto:pve-devel-boun...@pve.proxmox.com] On Behalf Of
Dietmar Maurer
Sent: Freitag, 16. Mai 2014 19:20
To: Michael Rasmussen; pve-devel@pve.proxmox.com
Subject: Re: [pve-devel] firewall rules format
Why not stick to the iptables format?
Or
On Fri, 16 May 2014 17:01:19 +
Dietmar Maurer diet...@proxmox.com wrote:
beaucse we cannot provide full iptables functionality, and iptables format
is really clumsy (for example multiport maches, ipsets, ...).
True.
But above syntax is basically iptables format, with some
But above syntax is basically iptables format, with some
simplifications ;-) Or what would you change exactly?
-source - -s
-dest - -d
The getopt-long parser usually accept several option format, like:
--source
-source
-s
As long as it is unique. But for now I want to keep things
On Fri, 16 May 2014 17:50:22 +
Dietmar Maurer diet...@proxmox.com wrote:
The getopt-long parser usually accept several option format, like:
--source
-source
-s
As long as it is unique. But for now I want to keep things simple. We just
need to
decide if we move from position based
Hi Dietmar,
Have you had the time to review my patch to QemuServer.pm?
Subject for patch: [PATCH 1/1] add initiator-name to iscsi drives if
configured
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG keys:
michael at rasmussen dot cc
On Mon, 12 May 2014 01:09:38 +0200
Michael Rasmussen m...@datanom.net wrote:
commit b3a716fa613391dc54244f7a894088de36b6a303: snapshot recent-both
I have tested this patch and have discovered a bug. If the user makes a
rollback which trigger the patch's test to not allow to make a rollback
On Fri, 16 May 2014 20:25:41 +0200
Michael Rasmussen m...@datanom.net wrote:
On Mon, 12 May 2014 01:09:38 +0200
Michael Rasmussen m...@datanom.net wrote:
commit b3a716fa613391dc54244f7a894088de36b6a303: snapshot recent-both
I have tested this patch and have discovered a bug. If the
As long as it is unique. But for now I want to keep things simple. We just
need to
decide if we move from position based arguments to named arguments.
Yes, keep it simple
in ACCEPT(MACRO) -i net0 -source 192.168.2.0 -dest 1.2.3.4 -p tcp -dport 80
-sport 20
seem to be enough
- Mail
20 matches
Mail list logo
