> -Original Message-
> From: Alexandre DERUMIER [mailto:aderum...@odiso.com]
> Sent: Mittwoch, 19. März 2014 06:33
> To: Dietmar Maurer
> Cc: pve-devel@pve.proxmox.com
> Subject: Re: [pve-devel] [PATCH] add ips feature v3
>
> I'll send a new patch today, I found some other missing accept
> Just curious - how long are the command lines this patch generates?
Well, it looks like that depends on a number of things. The entire
contents of %$scfg are added to the environment as PMXCFG_*, the full path
to the ssh key is added to the environment as PMXVAR_SSHKEY (and then added
again as
> Of course, it's entirely possible (and even likely) that command line lengths
> will never become an issue, so my concern may be unwarranted
Just curios - how long are the command lines this patch generates?
___
pve-devel mailing list
pve-devel@pve.p
> Now that 3.2 is out, did you find the time to finally review/merge this patch
> series
Sorry for the delay, I am still in bug fixing mode ;-)
Just applied your patches (+one fix for undefined var $ifcount).
Please can you test if that still works?
https://git.proxmox.com/?p=pve-common.git;a=s
> > > AFAIK ssh does not allow to pass environment variables to remote
hosts?
> > So I guess
> > > it is better to pass all arguments on the command line?
> > Yes and no. While ssh doesn't pass the local environment to the remote
> > system, you can include the env var assignments as part of the s
I'll send a new patch today, I found some other missing accept
- Mail original -
De: "Alexandre DERUMIER"
À: "Dietmar Maurer"
Cc: pve-devel@pve.proxmox.com
Envoyé: Mardi 18 Mars 2014 10:33:06
Objet: Re: [pve-devel] [PATCH] add ips feature v3
> I don't known, but if they are criti
> > AFAIK ssh does not allow to pass environment variables to remote hosts?
> So I guess
> > it is better to pass all arguments on the command line?
> Yes and no. While ssh doesn't pass the local environment to the remote
> system, you can include the env var assignments as part of the ssh command
> AFAIK ssh does not allow to pass environment variables to remote hosts?
So I guess
> it is better to pass all arguments on the command line?
Yes and no. While ssh doesn't pass the local environment to the remote
system, you can include the env var assignments as part of the ssh command
line, ju
> 1) As I have no access to some of the software/hardware required to tests all
> of the currently implemented iSCSI targets, I would need some colaboration
> from existing users willing to tests the new code. Volunters?
Maybe Michael (mir) can do that?
> 2) Where should I include such scripts? M
> > Are you monitoring this?
>
> Sure (I reported the issue). Expect a new kernel in a few day.
Also see: https://git.proxmox.com/?p=pve-kernel-2.6.32.git;a=summary
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/m
> Are you monitoring this?
Sure (I reported the issue). Expect a new kernel in a few day.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> The 'protocol' which proxmox uses to communicate with the helper is simply
> based on exposing a set of environment variables
AFAIK ssh does not allow to pass environment variables to remote hosts? So I
guess
it is better to pass all arguments on the command line?
_
Hi,
> Subject: [pve-devel] Fw: [Bug 2242] vzctl restore error on NFS
>
> Hi Dietmar,
>
> Are you monitoring this?
[Martin Maurer]
Yes, we already tested this patch today and so far it looks ok (already did
some migrations with success).
Martin
___
Hi Dietmar,
Are you monitoring this?
Begin forwarded message:
Date: Tue, 18 Mar 2014 11:17:28 +
From: bugzilla-dae...@bugzilla.openvz.org
To: m...@datanom.net
Subject: [Bug 2242] vzctl restore error on NFS
https://bugzilla.openvz.org/show_bug.cgi?id=2242
--- Comment #43 from Kinsbursky St
On Tue, 18 Mar 2014 10:00:48 -0700
Chris Allen wrote:
>
> Michael, I can't seem to recreate this. I converted a VM with the sparse
> option to a template and created a linked clone, and then backed up the
> linked clone and didn't get this error message. This is a log of my linked
> clone bac
> Your patch still needs to handle the case where a VM has been converted
> to a template since image handling after conversion complains of an
> unknown setting: sparse.
Michael, I can't seem to recreate this. I converted a VM with the sparse
option to a template and created a linked clone, and
Hello,
This is a followup at my privous attempt at providing generic support
of LUN management to ZFS Plugin by using an independent helper script/binary.
This patch series refactors current ZFS Plugin, removing support for perl-based
LunCmd drivers, and instead provides a generic-way of invokin
Signed-off-by: Pablo Ruiz García
---
PVE/Storage/LunCmd/Comstar.pm | 102 ---
PVE/Storage/LunCmd/Iet.pm | 478 -
PVE/Storage/LunCmd/Istgt.pm | 580 -
PVE/Storage/LunCmd/Makefile |5 -
PVE/Storage/Makefile
The 'protocol' which proxmox uses to communicate with the helper is simply
based on exposing a set of environment variables along with a few command
line arguments which are passed to helper script. This is based on the
same concept around CGI, AGI, and other similar decoupled invocation protocols.
Hi,
I am now working on this change, and regarding existing LUN drivers, I
would like to try to create some drivers from the existing perl code. My
idea would be creating an independent & standalone 'driver.pl' for each
existing driver, which can be placed somewhere on your proxmox (or zfs)
server
> I don't known, but if they are critical, maybe can we bypass the ips ?
>>I guess this is a question to for the IPS developers.
I see in default suricata/snort rules
alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP Fragment Reassembly
Time Exceeded"; icode:1; itype:11; classtype:misc
> Do you think the overhead is big ?
> I can work on an optimisation to only replace ACCEPT when ips is enabled
>
Ok, lets go the simple way. We can optimize later.
> >>Besides, I cannot see that this patch replaces all ACCEPT actions, for
> example:
> >>
> >>---
> >>sub ruleset_gene
>>You use this chain unconditionally, so we slow down things when the IPS is
>>not active.
>>(because of an additional jump to PVEFW-Accept).
Do you think the overhead is big ?
I can work on an optimisation to only replace ACCEPT when ips is enabled
>>Besides, I cannot see that this patch re
23 matches
Mail list logo
