Net::IP->overlaps returns more than just true or false, as
it tests both directions, we need IP_B_IN_A_OVERLAP in our
test.
Removed return on mask eq '0.0.0.0' as this doesn't exist in
the $ipv4_mask_hash_localnet.
---
src/PVE/Firewall.pm | 16 +++-
1 file changed, 11 insertions(+), 5
inet_ntop only takes an addres, not a CIDR notation. Since
the normalized address should just be a compressed
lower-case address, Net::IP::ip_compress_address should be
sufficient.
inet_ntop didn't succeed before, the result of which was
that ipsets weren't generated at all for ipv6 address ranges
> Now that we have qemu 2.4,
> I think we can apply this patch ?
The patch does not apply:
error: patch failed: PVE/QemuServer.pm:2607
error: PVE/QemuServer.pm: patch does not apply
Patch failed at 0001 add memory_unplug support
?
___
pve-devel mailin
On Tue, Jul 28, 2015 at 07:27:00AM +0200, Alexandre DERUMIER wrote:
> The main problem is ip change on bridge directly, because we can't shutdown
> it if vms tap are plugged on it.
> So we need to do it online.
There's no need to shut it down.
On Tue, Jul 28, 2015 at 06:12:09AM +0200, Martin Wa
---
www/manager/storage/ZFSPoolEdit.js | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/www/manager/storage/ZFSPoolEdit.js
b/www/manager/storage/ZFSPoolEdit.js
index dfefa0b..9ad1284 100644
--- a/www/manager/storage/ZFSPoolEdit.js
+++ b/www/manager/storage/ZFSPoolEdit.
Now that we have qemu 2.4,
I think we can apply this patch ?
- Mail original -
De: "aderumier"
À: "pve-devel"
Cc: "aderumier"
Envoyé: Mercredi 1 Juillet 2015 17:37:23
Objet: [PATCH] add memory_unplug support
qemu 2.4 feature
Signed-off-by: Alexandre Derumier
---
PVE/QemuServer.pm
we have done it for lxc container.
https://git.proxmox.com/?p=pve-container.git;a=blob_plain;f=src/PVE/LXC.pm;hb=HEAD
sub update_ipconfig {}
What I would like to do, is when in gui we have done the new config in
/etc/network/interfaces.new,
then apply it online.
So manage dependencies betwe
> When can we expect a fix in pvetest repositories?
its already there (pvetest and pve-no-subscription) - please test.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> Am 27.07.2015 um 20:27 schrieb Michael Rasmussen :
>
> On Mon, 27 Jul 2015 20:08:24 +0200 (CEST)
> Alexandre DERUMIER wrote:
>
eval {
ovs-vsctl add-port $bridge vlan$port tag=$port -- set interface
vlan$port type=internal
};
>>
>> internal interface can have a random name.
When can we expect a fix in pvetest repositories?
--
Fügen Sie uns in die Liste "vertrauenswürdiger Absender" hinzu.
If you have any further questions, please let us know.
Mit freundlichen Grüßen / With best regards
myVirtualserver.de | Development Team
Henry Spanka
I think the best option is to run every KVM as another user and chown
the /var/lib/vz/images/VMID/ directory to that user.
There will be vulnerabilities at any time and the best option is to
just use other users to prevent execution of code on the host or
modify other vms(read data).
Best r
> > A document is already describing something similar.
> > http://docs.ganeti.org/ganeti/2.13/html/design-kvmd.html
>
> I always tried to avoid that.
We can still use a shutdown "script", but it needs to be something
that can be compiled in order to get the necessary capabilities.
Hmm, what's a
> A monitoring process which does not rely on events could potentially be
> a resource hawk.
Well I wasn't suggesting a busy-waiting daemon. More like listening with
inotify on the qemu cgroup directory, since we use systemd-run to run VMs
in a scope now, this would allow an event-based implementa
> A document is already describing something similar.
> http://docs.ganeti.org/ganeti/2.13/html/design-kvmd.html
I always tried to avoid that.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
On Mon, 27 Jul 2015 20:11:54 +0200 (CEST)
Wolfgang Bumiller wrote:
>
> This is better. Even better would be a monitoring process that doesn't need to
> be signaled.
> (Coincidentally, this would also add the possibility of adding reliably-fired
> exit-time hooks.)
>
A monitoring process which d
On Mon, 27 Jul 2015 20:08:24 +0200 (CEST)
Alexandre DERUMIER wrote:
> >>eval {
> >>ovs-vsctl add-port $bridge vlan$port tag=$port -- set interface
> >>vlan$port type=internal
> >>};
>
> internal interface can have a random name.
>
I know, but to keep it simple and IMHO more intuitive use a d
> Exit scripts could be suid if needed.
Scripts cannot be suid, because the executable is their interpreter, iow
/bin/sh, which
in turn is not setuid-root.
> The exit scripts could simply notify some other privlidged process
> that they are shutting down.
This is better. Even better would be
>>eval {
>>ovs-vsctl add-port $bridge vlan$port tag=$port -- set interface
>>vlan$port type=internal
>>};
internal interface can have a random name.
also, we need to manage update. (ip modification for example).
we could do down, up . But it's not optimal.
- Mail original -
De: "da
On Wed, 22 Jul 2015 01:25:14 +0200
Michael Rasmussen wrote:
> Hi all,
>
> I have installed a proxmox 4.0 to test openvswitch and IMHO the current
> network GUI config is not suited for the task since every time you need
> to create or delete an OVSint Port a reboot of the node is required. I
> w
> I guess it would also help if we add a reasonable apparmor profile?
>
apparmor profiles would be greatly appreciated
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> > AFAIK this is already possible with latest version from git.
> >
> Yes;-) When will the patch hit pvetest?
I will try to upload this week.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-deve
On Mon, 27 Jul 2015 18:29:32 +0200 (CEST)
Dietmar Maurer wrote:
>
> AFAIK this is already possible with latest version from git.
>
Yes;-) When will the patch hit pvetest?
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG keys:
michael rasmussen cc
http://pgp.mit.edu:11371/pks/lookup?
I guess it would also help if we add a reasonable apparmor profile?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> Why is it not possible to add a nic to a lxc CT using DHCP?
>
> The reason I ask is because every time a lxc CT is restarted the
> interfaces file is reset provided it is configured to use DHCP.
AFAIK this is already possible with latest version from git.
https://git.proxmox.com/?p=pve-contain
Hi all,
Why is it not possible to add a nic to a lxc CT using DHCP?
The reason I ask is because every time a lxc CT is restarted the
interfaces file is reset provided it is configured to use DHCP.
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG keys:
michael rasmussen cc
http://pgp.m
Le 27/07/2015 15:29, Eric Blevins a écrit :
> I have no idea if CVE-2015-5154 that Stephan inquired about affests Proxmox.
>
> But when I see exploits like that the first thought in my mind is how
> easy it would be for such an exploit to get root on the Proxmox host.
>
> I've done some experimen
we could create the tap interface,
tunctl -t tap0 -u myuser
then pass it to qemu without script
-netdev tap,ifname=tap0,id=mynet0,script=no
(and the bridge create, tap plug, could be also done manually in qemuserver
vmstart)
- Mail original -
De: "aderumier"
À: "Eric Blevins"
Cc:
Can qemu create the tap interface without root privilege ?
- Mail original -
De: "Eric Blevins"
Cc: "pve-devel"
Envoyé: Lundi 27 Juillet 2015 16:33:49
Objet: Re: [pve-devel] Running KVM as root is a security issue
Having only PCI passthrough VMs running as root would be a huge improvem
>>to answer myself. PVE is affected. Every VM with a CDROM can get root.
yes, indeed :(
https://access.redhat.com/security/cve/CVE-2015-5154
- Mail original -
De: "Stefan Priebe"
À: "pve-devel"
Envoyé: Lundi 27 Juillet 2015 15:39:54
Objet: Re: [pve-devel] CVE-2015-5154
to answer myse
Apparently hit y and enter without looking.
This should be ignored, sorry about that, my bad.
On 07/27/2015 03:33 PM, Thomas Lamprecht wrote:
Updated debian package control files and Makefile
to build GFS2-3.1.8 for Proxmox VE 4.
We use the following sources to build GFS2:
https://git.fedorahos
Having only PCI passthrough VMs running as root would be a huge improvement.
Maybe cgroups could be used to reduce the risk.
Exit scripts could be suid if needed.
An exploted VM could potentially use the suid pve-bridgedown script to
destroy bridges of other VMs.
Long term I think a better idea i
These patches update GFS2 to the actual stable version 3.1.8
and also update the debian package control files.
GFS2 sources used:
https://git.fedorahosted.org/cgit/gfs2-utils.git/snapshot/gfs2-utils-3.1.8.tar.gz
Thomas Lamprecht (2):
gfs2-utils: Fixed patches for updated GFS2
gfs2-utils: updat
Removed old, for the actual gfs2 version (3.1.8), unnecessary patch.
Made patch for gfs2 lockcapture, so that it uses corosync tools directly.
We do not throw an error when no GFS2 entry is in /etc/fstab, because
there cannot possible be an entry after the first installation and it's
very confusing
Updated debian package control files and Makefile to build GFS2-3.1.8
for Proxmox VE 4.
We use the following gfs2-utils sources for this build:
gfs2-utils.git: 3.1.8 tag
Signed-off-by: Thomas Lamprecht
---
Makefile | 6 +++---
debian/changelog | 4 ++--
debian/control | 2 +-
debian/co
On Mon, Jul 27, 2015 at 04:07:10PM +0200, Alexandre DERUMIER wrote:
> >>Yes, that much I've tested, too. I'm worried about the shutdown scripts
> >>though (bridgedown). They might lack permissions if qemu doesn't keep a
> >>privileged parent process around for those.
>
> I think that pci passthrou
does somebody have tested my vlan bridges patches ? (note that that need
iproute2 from debian sid, for vlan ranges)
It's working really fine here, I'm looking to add a patch for Q-in-Q bridge
too. (I think Stefan Priebe use them)
- Mail original -
De: "aderumier"
À: "Wolfgang Bumi
>>Yes, that much I've tested, too. I'm worried about the shutdown scripts
>>though (bridgedown). They might lack permissions if qemu doesn't keep a
>>privileged parent process around for those.
I think that pci passthrough need root access too. (maybe not with vfio).
Not sure about disks with /de
Closes #303
---
www/manager/Utils.js | 2 +-
www/manager5/Utils.js | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/www/manager/Utils.js b/www/manager/Utils.js
index 351f157..0e2e8a2 100644
--- a/www/manager/Utils.js
+++ b/www/manager/Utils.js
@@ -166,7 +166,7 @@ Ext.define(
> A patch exists to prevent a crash when a socket cannot be opened.
> https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00577.html
Included in the current 2.4 devel build.
> I've done some experimenting. If I take the KVM command as generated
> by Proxmox and simply add "-runas nobody" the
to answer myself. PVE is affected. Every VM with a CDROM can get root.
Stefan
Am 27.07.2015 um 14:36 schrieb Stefan Priebe - Profihost AG:
> Hi,
>
> does this affect proxmox? I don't understand why xen is explicit content
> of the advisory.
> http://seclists.org/oss-sec/2015/q3/212
>
> --
> Ste
Updated debian package control files and Makefile
to build GFS2-3.1.8 for Proxmox VE 4.
We use the following sources to build GFS2:
https://git.fedorahosted.org/cgit/gfs2-utils.git/snapshot/gfs2-utils-3.1.8.tar.gz
Signed-off-by: Thomas Lamprecht
---
Makefile | 6 +++---
debian/changelog
I have no idea if CVE-2015-5154 that Stephan inquired about affests Proxmox.
But when I see exploits like that the first thought in my mind is how
easy it would be for such an exploit to get root on the Proxmox host.
I've done some experimenting. If I take the KVM command as generated
by Proxmox
>>Yes I think you can match almost everything in pretty much every table.
>>Provided they have implemented it ;-) so we'll have to wait for ct to
>>land in bridge tables before considering switching to nft.
Yes, we should wait.
Currently I'm just testing it, time to time, to see how it's evolvin
On Mon, Jul 27, 2015 at 03:01:30PM +0200, Alexandre DERUMIER wrote:
> Oh, I speak too fast,
> seem that for tcp traffic in bridge chain, I can see PROTO and port.
>
> forward: IN=tap150i0 OUT=fwln150i0
> MAC=00:08:7c:bd:ae:40:76:ef:e9:ed:9d:41:08:00 SRC=10.3.95.240
> DST=192.168.100.76 LEN=108 T
Oh, I speak too fast,
seem that for tcp traffic in bridge chain, I can see PROTO and port.
forward: IN=tap150i0 OUT=fwln150i0
MAC=00:08:7c:bd:ae:40:76:ef:e9:ed:9d:41:08:00 SRC=10.3.95.240
DST=192.168.100.76 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=42868 DF PROTO=TCP
SPT=22 DPT=49876 WINDOW=291 RES=
Hi,
does this affect proxmox? I don't understand why xen is explicit content
of the advisory.
http://seclists.org/oss-sec/2015/q3/212
--
Stefan
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-deve
>>you
>>have a single tool managing tables containing the chains. Iow. bridge
>>stuff still goes into the bridge tables, ip stuff into the ip tables,
>>arp stuff into the arp tables.
bridge log: (get forward working).
: IN=fwln150i0 OUT=tap150i0 ARP HTYPE=1 PTYPE=0x0800 OPCODE=1
MACSRC=5a:1
On Mon, Jul 27, 2015 at 01:41:56PM +0200, Alexandre DERUMIER wrote:
> Also , it seem that connection tracking is not implemented in bridge table
>
> http://wiki.nftables.org/wiki-nftables/index.php/Bridge_filtering
:-(
___
pve-devel mailing list
pve-de
> oh ok, didn't known that. (still a bit confuse between bridge vs ip/inet
> tables)
I'm new to nft, too, but as far as I understand it's not actually much
different from iptables (from the outside anyway).
It's just that rather than having several tools managing chains, you
have a single tool ma
Also , it seem that connection tracking is not implemented in bridge table
http://wiki.nftables.org/wiki-nftables/index.php/Bridge_filtering
- Mail original -
De: "aderumier"
À: "Wolfgang Bumiller"
Cc: "pve-devel"
Envoyé: Lundi 27 Juillet 2015 13:33:59
Objet: Re: [pve-devel] nftables 0
>>I think Xbriport only ever works on bridge filters, (on current kernels,
>>too). Is there any reason to put it in the ip tables? You can still
>>match on `ip saddr`, `ip6 saddr`, `ip6 nexthdr` etc. in bridge filters.
I don't known why, but I don't see any traffic in forward from bridge table.
Instead of a lot of hardcoded if's use JSONSchema::parse_config to
parse and validate vzdump.conf. To do that $confdesc was extended
to match a valid schema.
Signed-off-by: Thomas Lamprecht
---
Changes since v2:
* use given PVE::Tools method to get file content
* relocate confdesc to top, no need
On Mon, Jul 27, 2015 at 12:07:41PM +0200, Michael Rasmussen wrote:
> On Mon, 27 Jul 2015 11:42:57 +0200
> Wolfgang Bumiller wrote:
>
> >
> > The `= undef;` part shouldn't be necessary as that's implicit. We seem
> > to mostly leave it out in our code as far as I can tell.
> >
> This is a legacy
I think Xbriport only ever works on bridge filters, (on current kernels,
too). Is there any reason to put it in the ip tables? You can still
match on `ip saddr`, `ip6 saddr`, `ip6 nexthdr` etc. in bridge filters.
Btw. I find the table syntax much more readable than command lists.
table bridge filt
Hi,
I have done a small test with nftables 0.4 (from debian sid) + kernel 3.19,
modprobe nf_tables
modprobe nf_tables_ipv4
modprobe nft_meta_bridge
nft list ruleset
nft flush table inet filter
nft add table inet filter
nft add chain inet filter forward { type filter hook forward priority 0 \; }
On Mon, 27 Jul 2015 11:42:57 +0200
Wolfgang Bumiller wrote:
>
> The `= undef;` part shouldn't be necessary as that's implicit. We seem
> to mostly leave it out in our code as far as I can tell.
>
This is a legacy for all old Perl coders back from the days where
variables where declared in globa
> -my $res = {
> +my $defaults = {
(...)
> +foreach my $key (keys %$defaults) {
> + $res->{$key} = $defaults->{$key} if !$res->{$key};
> +}
I wonder if this is actually even necessary as parse_config should
simply override old keys.
> + local $/ = undef;
The `= undef;` pa
Instead of a lot of hardcoded if's use JSONSchema::parse_config to
parse and validate vzdump.conf. To do that $confdesc was extended
to match a valid schema.
Signed-off-by: Thomas Lamprecht
---
PVE/VZDump.pm | 58 +-
1 file changed, 17 inse
applied.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
applied, thanks.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
---
...reboot-flag-and-delete-old-veth-on-reboot.patch | 34 --
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git
a/debian/patches/0001-pass-on-reboot-flag-and-delete-old-veth-on-reboot.patch
b/debian/patches/0001-pass-on-reboot-flag-and-delete-old-veth-on-reboot.
61 matches
Mail list logo
