[pve-devel] [RFC PATCH v2] Fix #1446: allow pve-firewall package install twice in a row

On packages removal (!= purge) systemd units are masked. The postinst script has then to reenable this units at the beginning of the 'configure' step. Our other packages are doing this manually, or automatically when the dh_systemd_enable helpers generated a postinst, but this was missing here.

[pve-devel] [PATCH 2/3] buildsys: move to dpkg-buildpackage

Signed-off-by: Thomas Lamprecht --- Makefile | 15 +++ changelog.firmware => debian/changelog | 0 debian/compat | 1 + control.firmware => debian/control | 8 +--- debian/install

[pve-devel] [PATCH 1/3] buildsys: set SOURCE_DATE_EPOCH to allow reproducible build

Signed-off-by: Thomas Lamprecht --- allows to check changes (or better, the lack of them) from the upcomming "move to buildpackage" patch. Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index 32d98cd..645afd4 100644 --- a/Makefile

Re: [pve-devel] Corosync-qdevice

Hi Thomas... I get it... But i have one doubt: The corosync-qdevice-net-certutil procedure will no mess up a previously cluster?? I ask this because I already have my cluster here work normally... Thanks Obrigado Cordialmente Gilberto Ferreira Consultor TI Linux | IaaS Proxmox, CloudStack,

[pve-devel] applied: [RFC PATCH v2] Fix #1446: allow pve-firewall package install twice in a row

applied On Mon, Jul 17, 2017 at 02:50:26PM +0200, Emmanuel Kasper wrote: > On packages removal (!= purge) systemd units are masked. > The postinst script has then to reenable this units at the > beginning of the 'configure' step. > > Our other packages are doing this manually, or automatically >

Re: [pve-devel] Corosync-qdevice

Hi, On 07/17/2017 12:35 AM, Gilberto Nunes wrote: Hi folks Is Corosync-qdevice read for tests and production??? For testing for sure, production normally also, but as we haven't any documentation in the official PVE docs and some helpers I would like to integrate still miss, it's a

[pve-devel] applied: [PATCH qemu-server v2] use machine version in vga default type selection

applied to master On Wed, Jul 12, 2017 at 07:34:51AM +0200, Thomas Lamprecht wrote: > If we get an VM machine older than 2.9 we use the old selection > expression for the VGA type. This allows to live migrate VMs to PVE > 5.0 from beta 1 and PVE 4.4 again. > > Signed-off-by: Thomas Lamprecht

[pve-devel] applied: [PATCH cluster] pvecm: lock corosync config on addition and deletion

applied On Thu, Jul 13, 2017 at 03:01:02PM +0200, Thomas Lamprecht wrote: > This avoids potentiall races which would lead to an inconsistent > corosync config. > > Signed-off-by: Thomas Lamprecht > --- > > While this looks like a preety big change its mostly just

Re: [pve-devel] Corosync-qdevice

Sorry but, as far as I understanding, the qdevice still need a third part to work properly or I can use one of the nodes??? I don't understand and * start the services everywhere (corosync-qdevice on the PVE nodes and the corosync-qnetd... on the qdevice serving host) What qdevice serving

Re: [pve-devel] Corosync-qdevice

Hi, On 07/17/2017 08:08 PM, Gilberto Nunes wrote: Sorry but, as far as I understanding, the qdevice still need a third part to work properly or I can use one of the nodes??? Yes, three real votes are always needed in for an arbitrary quorum service to work [1][2] (Side note for other