Re: [pve-devel] [PATCH manager] ui: mark strings translatable

2023-11-28 Thread Thomas Lamprecht
Am 28/11/2023 um 16:29 schrieb Dietmar Maurer:
>> I'm taking on a lot of contributions to translations and the common complaint
>> I hear is that not all can be translated correctly due to such tricks (or 
>> just
>> missing gettext), most translators care much more about a correct translation
>> than some over-optimized ones than then break depending on context or target
>> language.
>>
>> Also, changing this now results in only a few new strings to be translated 
>> for
>> those languages we get common contributions for, so not really much effort to
>> catch up again.
>>
>>> So what languages are the problem exactly? Please can you
>>> give me an example?
>>
>> Any right-to-left languages could be broken.
> 
> If its only right-to-left languages, we could just add another helper
> to assemble lists in the correct order?

Those I'm rather sure of, but I'd not bet anything that they are the
only ones..

But as said, IMO such special helpers and optimizations are not really
worth the hassle, as most translators do not care and are happier if they
have more context and that the end result is OK, not that they have a
dozen strings, or so, less to translate..

I think the 

Ext.String.format(gettext('Default ({0})'), gettext('Free')) 

is really the biggest reuse one would get, and it needs no special new
helpers and  we have that pattern quite a few time, so IMO worth it.

btw. @Maximiliano: "Free" is rather a bad original text for the
component in question anyway, should be probably rather "Unrestricted".



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



Re: [pve-devel] [PATCH manager] ui: mark strings translatable

2023-11-28 Thread Dietmar Maurer
> I'm taking on a lot of contributions to translations and the common complaint
> I hear is that not all can be translated correctly due to such tricks (or just
> missing gettext), most translators care much more about a correct translation
> than some over-optimized ones than then break depending on context or target
> language.
> 
> Also, changing this now results in only a few new strings to be translated for
> those languages we get common contributions for, so not really much effort to
> catch up again.
> 
> > So what languages are the problem exactly? Please can you
> > give me an example?
> 
> Any right-to-left languages could be broken.

If its only right-to-left languages, we could just add another helper
to assemble lists in the correct order?


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] applied: [PATCH docs 1/2] secure boot: fix typos, add inline code formatting

2023-11-28 Thread Thomas Lamprecht
Am 28/11/2023 um 14:56 schrieb Alexander Zeidler:
> Signed-off-by: Alexander Zeidler 
> ---
>  system-booting.adoc | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
>

applied series, thanks!


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



Re: [pve-devel] [PATCH manager] ui: mark strings translatable

2023-11-28 Thread Thomas Lamprecht
Am 28/11/2023 um 15:39 schrieb Dietmar Maurer:
> Well, this also duplicates the number of things to translate!

I'm taking on a lot of contributions to translations and the common complaint
I hear is that not all can be translated correctly due to such tricks (or just
missing gettext), most translators care much more about a correct translation
than some over-optimized ones than then break depending on context or target
language.

Also, changing this now results in only a few new strings to be translated for
those languages we get common contributions for, so not really much effort to
catch up again.

> So what languages are the problem exactly? Please can you
> give me an example?

Any right-to-left languages could be broken.

Am 28/11/2023 um 15:46 schrieb Dietmar Maurer:
> To be more clear, I would use:
> 
> proxmox.Utils.defaultText + ' (' + gettext('Free') + ')'


If, we would need to use

Ext.String.format(gettext('Default ({0})'), gettext('Free'))

But FWIW, that also drops a bit of context information (Free might be
translated different in the context of a default-value then some button
that free's something.


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] [PATCH] update kernel to 6.5.11 and ZFS to 2.2.1, refresh patches

2023-11-28 Thread Stoiko Ivanov
* for the kernel-patch this includes a rename from 0003+0004 to
  0001+0002
* for ZFS there was a change in upstream's autotools-setup - I
  referenced the commit in the actual patch-file

minimally tested with a VM with a zfs-pool and an ext4 disk
* restore of a directory on ext4 containing 160MB of debian packages
  as tar.zstd
* restore of a small folder (/root in a debian container) on zfs
both worked

restoring files from a Windows guest - worked, however there is an
independent issue with tpmstate not being found:
`given image 'drive-tpmstate0-backup.img.fidx' not found (400)`

directories with 10 million files also still cause the restore-shim to
run into OOM (but this is independent of the restore-image)

Signed-off-by: Stoiko Ivanov 
---
 ...ch => 0001-vsock-reduce-packet-size.patch} |  9 +++--
 ...estore-halt-machine-on-kernel-panic.patch} |  9 +++--
 .../0001-remove-reference-to-libudev.patch| 19 +--
 src/submodules/ubuntu-kernel  |  2 +-
 src/submodules/zfsonlinux |  2 +-
 5 files changed, 17 insertions(+), 24 deletions(-)
 rename src/patches/kernel/{0003-vsock-reduce-packet-size.patch => 
0001-vsock-reduce-packet-size.patch} (86%)
 rename src/patches/kernel/{0004-PBS-restore-halt-machine-on-kernel-panic.patch 
=> 0002-PBS-restore-halt-machine-on-kernel-panic.patch} (83%)

diff --git a/src/patches/kernel/0003-vsock-reduce-packet-size.patch 
b/src/patches/kernel/0001-vsock-reduce-packet-size.patch
similarity index 86%
rename from src/patches/kernel/0003-vsock-reduce-packet-size.patch
rename to src/patches/kernel/0001-vsock-reduce-packet-size.patch
index 378da53..75b0e92 100644
--- a/src/patches/kernel/0003-vsock-reduce-packet-size.patch
+++ b/src/patches/kernel/0001-vsock-reduce-packet-size.patch
@@ -1,4 +1,4 @@
-From a437d428733881f408b5d42eb75812600083cb75 Mon Sep 17 00:00:00 2001
+From  Mon Sep 17 00:00:00 2001
 From: Stefan Reiter 
 Date: Mon, 26 Apr 2021 14:08:36 +0200
 Subject: [PATCH] vsock: reduce packet size
@@ -19,10 +19,10 @@ Signed-off-by: Stefan Reiter 
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
-index dc636b727179..18c09ff72929 100644
+index c58453699ee9..62a609444e12 100644
 --- a/include/linux/virtio_vsock.h
 +++ b/include/linux/virtio_vsock.h
-@@ -9,7 +9,7 @@
+@@ -112,7 +112,7 @@ static inline size_t virtio_vsock_skb_len(struct sk_buff 
*skb)
  
  #define VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE  (1024 * 4)
  #define VIRTIO_VSOCK_MAX_BUF_SIZE 0xUL
@@ -31,6 +31,3 @@ index dc636b727179..18c09ff72929 100644
  
  enum {
VSOCK_VQ_RX = 0, /* for host to guest data */
--- 
-2.20.1
-
diff --git 
a/src/patches/kernel/0004-PBS-restore-halt-machine-on-kernel-panic.patch 
b/src/patches/kernel/0002-PBS-restore-halt-machine-on-kernel-panic.patch
similarity index 83%
rename from 
src/patches/kernel/0004-PBS-restore-halt-machine-on-kernel-panic.patch
rename to src/patches/kernel/0002-PBS-restore-halt-machine-on-kernel-panic.patch
index d79833f..8c2cabd 100644
--- a/src/patches/kernel/0004-PBS-restore-halt-machine-on-kernel-panic.patch
+++ b/src/patches/kernel/0002-PBS-restore-halt-machine-on-kernel-panic.patch
@@ -1,4 +1,4 @@
-From 7222e7424aab957f63b98853ea9fb30eec83666e Mon Sep 17 00:00:00 2001
+From  Mon Sep 17 00:00:00 2001
 From: Stefan Reiter 
 Date: Mon, 3 May 2021 11:13:10 +0200
 Subject: [PATCH] PBS-restore: halt machine on kernel panic
@@ -14,10 +14,10 @@ Signed-off-by: Stefan Reiter 
  1 file changed, 3 insertions(+)
 
 diff --git a/kernel/panic.c b/kernel/panic.c
-index 332736a72a58..56339ae5165c 100644
+index ea1c5fcb2d19..c317ca992a26 100644
 --- a/kernel/panic.c
 +++ b/kernel/panic.c
-@@ -325,6 +325,9 @@ void panic(const char *fmt, ...)
+@@ -417,6 +417,9 @@ void panic(const char *fmt, ...)
}
}
if (panic_timeout != 0) {
@@ -27,6 +27,3 @@ index 332736a72a58..56339ae5165c 100644
/*
 * This will not be a clean reboot, with everything
 * shutting down.  But if there is a chance of
--- 
-2.20.1
-
diff --git a/src/patches/zfs/0001-remove-reference-to-libudev.patch 
b/src/patches/zfs/0001-remove-reference-to-libudev.patch
index 467d9b5..8fe9b31 100644
--- a/src/patches/zfs/0001-remove-reference-to-libudev.patch
+++ b/src/patches/zfs/0001-remove-reference-to-libudev.patch
@@ -6,6 +6,8 @@ Subject: [PATCH] remove reference to libudev
 since there's no command line flag I can see...
 
 Signed-off-by: Stefan Reiter 
+[ SI adapt to aebd94cc8541e0ec3b1de57edbd57c4280213089 ]
+Signed-off-by: Stoiko Ivanov 
 ---
  config/user-libudev.m4 | 17 -
  config/user.m4 |  1 -
@@ -36,17 +38,14 @@ index 8c3c1d7e0..0
 -  ])
 -])
 diff --git a/config/user.m4 b/config/user.m4
-index c22067551..1b6d3a24e 100644
+index 6ec27a5b2..46244f19b 100644
 

Re: [pve-devel] [PATCH manager] ui: mark strings translatable

2023-11-28 Thread Dietmar Maurer
To be more clear, I would use:

proxmox.Utils.defaultText + ' (' + gettext('Free') + ')'


> On 28.11.2023 15:39 CET Dietmar Maurer  wrote:
> 
>  
> > The string `proxmox.Utils.defaultText + ' (free)'` was inlined as
> > `Default (Free)` cutting translatable strings makes them harder or even
> > impossible to translate in certain languages.
> 
> Well, this also duplicates the number of things to translate!
> 
> So what languages are the problem exactly? Please can you
> give me an example?
> 
> 
> ___
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



Re: [pve-devel] [PATCH manager] ui: mark strings translatable

2023-11-28 Thread Dietmar Maurer
> The string `proxmox.Utils.defaultText + ' (free)'` was inlined as
> `Default (Free)` cutting translatable strings makes them harder or even
> impossible to translate in certain languages.

Well, this also duplicates the number of things to translate!

So what languages are the problem exactly? Please can you
give me an example?


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] [PATCH docs 1/2] secure boot: fix typos, add inline code formatting

2023-11-28 Thread Alexander Zeidler
Signed-off-by: Alexander Zeidler 
---
 system-booting.adoc | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/system-booting.adoc b/system-booting.adoc
index c8761a4..af56225 100644
--- a/system-booting.adoc
+++ b/system-booting.adoc
@@ -380,10 +380,11 @@ and integration in `proxmox-boot-tool`.
 
 The following packages need to be installed for Secure Boot to be enabled:
 
-- shim-signed (shim bootloader signed by Microsoft)
-- shim-helpers-amd64-signed (fallback bootloader and MOKManager, signed by 
Proxmox)
-- grub-efi-amd64-signed (Grub EFI bootloader, signed by Proxmox)
-- proxmox-kernel-6.X.Y-Z-pve-signed (Kernel image, signed by Proxmox)
+- `shim-signed` (shim bootloader signed by Microsoft)
+- `shim-helpers-amd64-signed` (fallback bootloader and MOKManager, signed by
+  Proxmox)
+- `grub-efi-amd64-signed` (Grub EFI bootloader, signed by Proxmox)
+- `proxmox-kernel-6.X.Y-Z-pve-signed` (Kernel image, signed by Proxmox)
 
 Only Grub as bootloader is supported out of the box, since there are no other
 pre-signed bootloader packages available. Any new installation of {pve} will
@@ -419,7 +420,7 @@ To check the latter, run:
 # findmnt /
 
 
-If the host is indeed running using ZFS as root filesystem, the `FSTYPE` column
+If the host is indeed using ZFS as root filesystem, the `FSTYPE` column
 should contain `zfs`:
 
 TARGET SOURCE   FSTYPE OPTIONS
@@ -485,8 +486,8 @@ can try adding it manually (if supported by the firmware), 
by adding the file
 
 NOTE: Some UEFI firmwares are known to drop the `proxmox` boot option on 
reboot.
 This can happen if the `proxmox` boot entry is pointing to a Grub installation
-on a disk, where the disk itself not a boot option. If possible, try adding the
-disk as a boot option in the UEFI firmware setup utility and run
+on a disk, where the disk itself is not a boot option. If possible, try adding
+the disk as a boot option in the UEFI firmware setup utility and run
 `proxmox-boot-tool` again.
 
 TIP: To enroll custom keys, see the accompanying
-- 
2.39.2



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] [PATCH docs 2/2] installation: be more specific about current secure boot state

2023-11-28 Thread Alexander Zeidler
Signed-off-by: Alexander Zeidler 
---
 pve-installation.adoc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/pve-installation.adoc b/pve-installation.adoc
index 44b59c0..1e909e2 100644
--- a/pve-installation.adoc
+++ b/pve-installation.adoc
@@ -60,7 +60,8 @@ Please insert the xref:installation_prepare_media[prepared 
installation media]
 (for example, USB flash drive or CD-ROM) and boot from it.
 
 TIP: Make sure that booting from the installation medium (for example, USB) is
-enabled in your servers firmware settings and secure boot is disabled.
+enabled in your server's firmware settings. Secure boot needs to be disabled
+when booting an installer prior to {pve} version 8.1.
 
 [thumbnail="screenshot/pve-grub-menu.png"]
 
-- 
2.39.2



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



Re: [pve-devel] [PATCH pve-network] validation: add support for arrays to change tracking

2023-11-28 Thread Hannes Dürr

Tested-by: Hannes Duerr 

On 11/22/23 13:28, Stefan Hanreich wrote:

This is needed so dhcp-ranges are properly displayed as changed in the
web UI.

Also took the chance to properly indent the encode_value function with
our indentation scheme.

Signed-off-by: Stefan Hanreich 
---
  src/PVE/Network/SDN.pm | 14 --
  1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/src/PVE/Network/SDN.pm b/src/PVE/Network/SDN.pm
index c306527..3af09b5 100644
--- a/src/PVE/Network/SDN.pm
+++ b/src/PVE/Network/SDN.pm
@@ -241,12 +241,14 @@ sub generate_dhcp_config {
  sub encode_value {
  my ($type, $key, $value) = @_;
  
-if ($key eq 'nodes' || $key eq 'exitnodes') {

-if(ref($value) eq 'HASH') {
-return join(',', sort keys(%$value));
-} else {
-return $value;
-}
+if ($key eq 'nodes' || $key eq 'exitnodes' || $key eq 'dhcp-range') {
+   if (ref($value) eq 'HASH') {
+   return join(',', sort keys(%$value));
+   } elsif (ref($value) eq 'ARRAY') {
+   return join(',', sort @$value);
+   } else {
+   return $value;
+   }
  }
  
  return $value;



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



Re: [pve-devel] [PATCH manager] ui: mark strings translatable

2023-11-28 Thread Maximiliano Sandoval


Maximiliano Sandoval  writes:

> + { flag: 'ssbd', desc: gettext('Protection for "Speculative Store 
> Bypass" for Intel models') },
> + { flag: 'ibpb', desc: gettext('Allows improved Spectre mitigation 
> with AMD CPUs') },
> + { flag: 'virt-ssbd', desc: gettext('Basis for "Speculative Store 
> Bypass" protection for AMD models') },
> + { flag: 'amd-ssbd', desc: gettext('Improves Spectre mitigation 
> performance with AMD CPUs, best used with "virt-ssbd"') },
> + { flag: 'amd-no-ssb', desc: gettext('Notifies guest OS that host is 
> not vulnerable for Spectre on AMD CPUs') },

Welp, indentation is broken here.


--
Maximiliano


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] [PATCH manager] ui: mark strings translatable

2023-11-28 Thread Maximiliano Sandoval
The string `proxmox.Utils.defaultText + ' (free)'` was inlined as
`Default (Free)` cutting translatable strings makes them harder or even
impossible to translate in certain languages.

Signed-off-by: Maximiliano Sandoval 
---
 www/manager6/dc/UserTagAccessEdit.js   | 10 +-
 www/manager6/form/VMCPUFlagSelector.js | 24 
 www/manager6/lxc/CreateWizard.js   |  4 ++--
 www/manager6/qemu/CreateWizard.js  |  4 ++--
 www/manager6/qemu/HDEdit.js|  2 +-
 www/manager6/window/Settings.js| 12 ++--
 6 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/www/manager6/dc/UserTagAccessEdit.js 
b/www/manager6/dc/UserTagAccessEdit.js
index 61c38c07..3e9a2d8e 100644
--- a/www/manager6/dc/UserTagAccessEdit.js
+++ b/www/manager6/dc/UserTagAccessEdit.js
@@ -54,11 +54,11 @@ Ext.define('PVE.dc.UserTagAccessEdit', {
deleteEmpty: false,
value: '__default__',
comboItems: [
-   ['__default__', Proxmox.Utils.defaultText + ' (free)'],
-   ['free', 'free'],
-   ['existing', 'existing'],
-   ['list', 'list'],
-   ['none', 'none'],
+   ['__default__', gettext('Default (Free)')],
+   ['free', gettext('Free')],
+   ['existing', gettext('Existing')],
+   ['list', gettext('List')],
+   ['none', gettext('None')],
],
defaultValue: '__default__',
},
diff --git a/www/manager6/form/VMCPUFlagSelector.js 
b/www/manager6/form/VMCPUFlagSelector.js
index ace3c531..e855b253 100644
--- a/www/manager6/form/VMCPUFlagSelector.js
+++ b/www/manager6/form/VMCPUFlagSelector.js
@@ -21,18 +21,18 @@ Ext.define('PVE.form.VMCPUFlagSelector', {
fields: ['flag', { name: 'state', defaultValue: '=' }, 'desc'],
data: [
// FIXME: let qemu-server host this and autogenerate or get from 
API call??
-   { flag: 'md-clear', desc: 'Required to let the guest OS know if MDS 
is mitigated correctly' },
-   { flag: 'pcid', desc: 'Meltdown fix cost reduction on Westmere, 
Sandy-, and IvyBridge Intel CPUs' },
-   { flag: 'spec-ctrl', desc: 'Allows improved Spectre mitigation with 
Intel CPUs' },
-   { flag: 'ssbd', desc: 'Protection for "Speculative Store Bypass" 
for Intel models' },
-   { flag: 'ibpb', desc: 'Allows improved Spectre mitigation with AMD 
CPUs' },
-   { flag: 'virt-ssbd', desc: 'Basis for "Speculative Store Bypass" 
protection for AMD models' },
-   { flag: 'amd-ssbd', desc: 'Improves Spectre mitigation performance 
with AMD CPUs, best used with "virt-ssbd"' },
-   { flag: 'amd-no-ssb', desc: 'Notifies guest OS that host is not 
vulnerable for Spectre on AMD CPUs' },
-   { flag: 'pdpe1gb', desc: 'Allow guest OS to use 1GB size pages, if 
host HW supports it' },
-   { flag: 'hv-tlbflush', desc: 'Improve performance in overcommitted 
Windows guests. May lead to guest bluescreens on old CPUs.' },
-   { flag: 'hv-evmcs', desc: 'Improve performance for nested 
virtualization. Only supported on Intel CPUs.' },
-   { flag: 'aes', desc: 'Activate AES instruction set for HW 
acceleration.' },
+   { flag: 'md-clear', desc: gettext('Required to let the guest OS 
know if MDS is mitigated correctly') },
+   { flag: 'pcid', desc: gettext('Meltdown fix cost reduction on 
Westmere, Sandy-, and IvyBridge Intel CPUs') },
+   { flag: 'spec-ctrl', desc: gettext('Allows improved Spectre 
mitigation with Intel CPUs') },
+   { flag: 'ssbd', desc: gettext('Protection for "Speculative Store 
Bypass" for Intel models') },
+   { flag: 'ibpb', desc: gettext('Allows improved Spectre mitigation 
with AMD CPUs') },
+   { flag: 'virt-ssbd', desc: gettext('Basis for "Speculative Store 
Bypass" protection for AMD models') },
+   { flag: 'amd-ssbd', desc: gettext('Improves Spectre mitigation 
performance with AMD CPUs, best used with "virt-ssbd"') },
+   { flag: 'amd-no-ssb', desc: gettext('Notifies guest OS that host is 
not vulnerable for Spectre on AMD CPUs') },
+   { flag: 'pdpe1gb', desc: gettext('Allow guest OS to use 1GB size 
pages, if host HW supports it') },
+   { flag: 'hv-tlbflush', desc: gettext('Improve performance in 
overcommitted Windows guests. May lead to guest bluescreens on old CPUs.') },
+   { flag: 'hv-evmcs', desc: gettext('Improve performance for nested 
virtualization. Only supported on Intel CPUs.') },
+   { flag: 'aes', desc: gettext('Activate AES instruction set for HW 
acceleration.') },
],
listeners: {
update: function() {
diff --git a/www/manager6/lxc/CreateWizard.js b/www/manager6/lxc/CreateWizard.js
index b57b3050..149acd07 100644
--- 

[pve-devel] applied: [PATCH manager] node: add guard for missing secure-boot efi var

2023-11-28 Thread Thomas Lamprecht
Am 28/11/2023 um 07:58 schrieb Fabian Grünbichler:
> some (old) systems might have efivars, but don't have the SecureBoot one.
> 
> Signed-off-by: Fabian Grünbichler 
> ---
> 
> Notes:
> reported on the forum for a Dell server from 2009(!):
> 
> https://forum.proxmox.com/threads/error-failed-to-read-secure-boot-state-from-pveproxy-since-updating-to-6-5-11-4-pve-8-1-3.137225/
> 
>  PVE/API2/Nodes.pm | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
>

applied, thanks!


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


Re: [pve-devel] [PVE-User] Proxmox VE 8.1 released!

2023-11-28 Thread Jan Vlach via pve-devel
--- Begin Message ---
https://www.reddit.com/r/zfs/comments/1826lgs/psa_its_not_block_cloning_its_a_data_corruption/
 


found this one in meantime, no idea what's the current state of affairs in 
proxmox ...

JV

> On 23. 11. 2023, at 23:35, Jan Vlach  wrote:
> 
> Hello Martin,
> 
> I'm sorry for stupid question, but I don't quite follow what the OpenZFS  
> 2.2.0 with "the most important bugfixes from 2.2.1" means.
> 
> there is issue 15526 (https://github.com/openzfs/zfs/issues/15526 
> ) in openzfs that enables block 
> cloning feature by default and that on linux "eats" data.
> 
> OpenZFS 2.2.1 specifically switches the block cloning on by default to off by 
> default and nothing else. ( 
> https://github.com/openzfs/zfs/commit/479dca51c66a731e637bd2d4f9bba01a05f9ac9f
>  
> 
>   )
> 
> So is the code at 2.2.0 (toxic) eating data by default or at 2.2.1 where 
> block cloning is disabled by default and therefore safe?
> 
> Thank you for clarification,
> JV
> 
>> On 23. 11. 2023, at 15:27, Martin Maurer > > wrote:
>> 
>> We're very excited to announce the release 8.1 of Proxmox Virtual 
>> Environment! It's based on Debian 12.2 "Bookworm" but uses a newer Linux 
>> kernel 6.5, QEMU 8.1.2, and OpenZFS 2.2.0 ((with stable fixes backported)
>> 
>> Here is a selection of the highlights of Proxmox VE 8.1
>> 
>> - Debian 12.2 (“Bookworm”), but uses a newer Linux kernel 6.5 as stable 
>> default
>> - latest versions of QEMU 8.1.2 and ZFS 2.2.0 including the most important 
>> bugfixes from 2.2.1 already
>> - Software-defined Networking (SDN)
>> - Secure Boot
>> - New flexible notification system with matcher-based approach
>> - Ceph Server: Ceph Reef 18.2.0 is default, and Ceph Quincy 17.2.7 comes 
>> with continued support.
>> -Countless GUI and API improvements.
>> 
>> As always, we have included countless bugfixes and improvements on many 
>> places; see the release notes for all details.
>> 
>> Release notes
>> https://pve.proxmox.com/wiki/Roadmap 
>> 
>> Press release
>> https://www.proxmox.com/en/news/press-releases/
>> 
>> Video tutorial
>> https://www.proxmox.com/en/training/video-tutorials/item/what-s-new-in-proxmox-ve-8-1
>> 
>> Download
>> https://www.proxmox.com/en/downloads
>> Alternate ISO download:
>> https://enterprise.proxmox.com/iso
>> 
>> Documentation
>> https://pve.proxmox.com/pve-docs
>> 
>> Community Forum
>> https://forum.proxmox.com
>> 
>> Bugtracker
>> https://bugzilla.proxmox.com
>> 
>> Source code
>> https://git.proxmox.com
>> 
>> There has been a lot of feedback from our community members and customers, 
>> and many of you reported bugs, submitted patches and were involved in 
>> testing - THANK YOU for your support!
>> 
>> FAQ
>> 
>> Q: Can I upgrade latest Proxmox VE 7 to 8 with apt?
>> A: Yes, please follow the upgrade instructions on 
>> https://pve.proxmox.com/wiki/Upgrade_from_7_to_8
>> 
>> Q: Can I upgrade an 8.0 installation to the stable 8.1 via apt?
>> A: Yes, upgrading from is possible via apt and GUI.
>> 
>> Q: Can I install Proxmox VE 8.1 on top of Debian 12 "Bookworm"?
>> A: Yes, see 
>> https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_12_Bookworm
>> 
>> Q: Can I upgrade my Proxmox VE 7.4 cluster with Ceph Pacific to Proxmox VE 
>> 8.1 and to Ceph Reef?
>> A: This is a three-step process. First, you have to upgrade Ceph from 
>> Pacific to Quincy, and afterwards you can then upgrade Proxmox VE from 7.4 
>> to 8.1. As soon as you run Proxmox VE 8.1, you can upgrade Ceph to Reef. 
>> There are a lot of improvements and changes, so please follow exactly the 
>> upgrade documentation:
>> https://pve.proxmox.com/wiki/Ceph_Pacific_to_Quincy
>> https://pve.proxmox.com/wiki/Upgrade_from_7_to_8
>> https://pve.proxmox.com/wiki/Ceph_Quincy_to_Reef
>> 
>> Q: Where can I get more information about feature updates?
>> A: Check the roadmap, forum, the mailing list, and/or subscribe to our 
>> newsletter.
>> 
>> -- 
>> Best Regards,
>> 
>> Martin Maurer
>> Proxmox VE project leader
>> 
>> 
>> ___
>> pve-user mailing list
>> pve-u...@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-user
> 

--- End Message ---
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


Re: [pve-devel] [PVE-User] Proxmox VE 8.1 released!

2023-11-28 Thread Jan Vlach via pve-devel
--- Begin Message ---
Hello Martin,

I'm sorry for stupid question, but I don't quite follow what the OpenZFS  2.2.0 
with "the most important bugfixes from 2.2.1" means.

there is issue 15526 (https://github.com/openzfs/zfs/issues/15526 
) in openzfs that enables block 
cloning feature by default and that on linux "eats" data.

OpenZFS 2.2.1 specifically switches the block cloning on by default to off by 
default and nothing else. ( 
https://github.com/openzfs/zfs/commit/479dca51c66a731e637bd2d4f9bba01a05f9ac9f 

  )

So is the code at 2.2.0 (toxic) eating data by default or at 2.2.1 where block 
cloning is disabled by default and therefore safe?

Thank you for clarification,
JV

> On 23. 11. 2023, at 15:27, Martin Maurer  wrote:
> 
> We're very excited to announce the release 8.1 of Proxmox Virtual 
> Environment! It's based on Debian 12.2 "Bookworm" but uses a newer Linux 
> kernel 6.5, QEMU 8.1.2, and OpenZFS 2.2.0 ((with stable fixes backported)
> 
> Here is a selection of the highlights of Proxmox VE 8.1
> 
> - Debian 12.2 (“Bookworm”), but uses a newer Linux kernel 6.5 as stable 
> default
> - latest versions of QEMU 8.1.2 and ZFS 2.2.0 including the most important 
> bugfixes from 2.2.1 already
> - Software-defined Networking (SDN)
> - Secure Boot
> - New flexible notification system with matcher-based approach
> - Ceph Server: Ceph Reef 18.2.0 is default, and Ceph Quincy 17.2.7 comes with 
> continued support.
> -Countless GUI and API improvements.
> 
> As always, we have included countless bugfixes and improvements on many 
> places; see the release notes for all details.
> 
> Release notes
> https://pve.proxmox.com/wiki/Roadmap
> 
> Press release
> https://www.proxmox.com/en/news/press-releases/
> 
> Video tutorial
> https://www.proxmox.com/en/training/video-tutorials/item/what-s-new-in-proxmox-ve-8-1
> 
> Download
> https://www.proxmox.com/en/downloads
> Alternate ISO download:
> https://enterprise.proxmox.com/iso
> 
> Documentation
> https://pve.proxmox.com/pve-docs
> 
> Community Forum
> https://forum.proxmox.com
> 
> Bugtracker
> https://bugzilla.proxmox.com
> 
> Source code
> https://git.proxmox.com
> 
> There has been a lot of feedback from our community members and customers, 
> and many of you reported bugs, submitted patches and were involved in testing 
> - THANK YOU for your support!
> 
> FAQ
> 
> Q: Can I upgrade latest Proxmox VE 7 to 8 with apt?
> A: Yes, please follow the upgrade instructions on 
> https://pve.proxmox.com/wiki/Upgrade_from_7_to_8
> 
> Q: Can I upgrade an 8.0 installation to the stable 8.1 via apt?
> A: Yes, upgrading from is possible via apt and GUI.
> 
> Q: Can I install Proxmox VE 8.1 on top of Debian 12 "Bookworm"?
> A: Yes, see 
> https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_12_Bookworm
> 
> Q: Can I upgrade my Proxmox VE 7.4 cluster with Ceph Pacific to Proxmox VE 
> 8.1 and to Ceph Reef?
> A: This is a three-step process. First, you have to upgrade Ceph from Pacific 
> to Quincy, and afterwards you can then upgrade Proxmox VE from 7.4 to 8.1. As 
> soon as you run Proxmox VE 8.1, you can upgrade Ceph to Reef. There are a lot 
> of improvements and changes, so please follow exactly the upgrade 
> documentation:
> https://pve.proxmox.com/wiki/Ceph_Pacific_to_Quincy
> https://pve.proxmox.com/wiki/Upgrade_from_7_to_8
> https://pve.proxmox.com/wiki/Ceph_Quincy_to_Reef
> 
> Q: Where can I get more information about feature updates?
> A: Check the roadmap, forum, the mailing list, and/or subscribe to our 
> newsletter.
> 
> -- 
> Best Regards,
> 
> Martin Maurer
> Proxmox VE project leader
> 
> 
> ___
> pve-user mailing list
> pve-u...@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-user

--- End Message ---
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


Re: [pve-devel] [PATCH pve-manager] sdn: ipam: fix ipam grouping identical subnets in different vnets

2023-11-28 Thread Hannes Dürr

Tested-by: Hannes Duerr 

On 11/28/23 09:58, Stefan Hanreich wrote:

When SDN is configured with the same subnet in two different VNets the
IPAM tree would render them wrongly.

Reported-By: Hannes Duerr 
Signed-off-by: Stefan Hanreich 
---
  www/manager6/tree/DhcpTree.js | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/www/manager6/tree/DhcpTree.js b/www/manager6/tree/DhcpTree.js
index d0b80803d..60029d3f4 100644
--- a/www/manager6/tree/DhcpTree.js
+++ b/www/manager6/tree/DhcpTree.js
@@ -60,7 +60,11 @@ Ext.define('PVE.sdn.DhcpTree', {
zones[element.zone].children.push(vnet);
}
  
-			if (!(element.subnet in subnets)) {

+   if (!(element.vnet in subnets)) {
+   subnets[element.vnet] = {};
+   }
+
+   if (!(element.subnet in subnets[element.vnet])) {
let subnet = {
name: element.subnet,
zone: element.zone,
@@ -71,13 +75,13 @@ Ext.define('PVE.sdn.DhcpTree', {
children: [],
};
  
-			subnets[element.subnet] = subnet;

+   subnets[element.vnet][element.subnet] = subnet;
vnets[element.vnet].children.push(subnet);
}
  
  			element.type = 'mapping';

element.iconCls = 'x-tree-icon-none';
-   subnets[element.subnet].children.push(element);
+   
subnets[element.vnet][element.subnet].children.push(element);
});
  
  		me.getView().setRootNode(root);



___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] [PATCH pve-network] dhcp: dnsmasq: Use dir_glob_foreach for deleting configuration files

2023-11-28 Thread Stefan Hanreich
The current invocation is quite unsafe and triggers the taint mode of
Perl. Replacing it with dir_glob_foreach solves those issues.

Reported-By: Friedrich Weber 
Signed-off-by: Stefan Hanreich 
---
I wasn't sure whether directly unlinking the files in the callback
would influence the iteration, hence why I store them in an
intermediate array. Also, unlinking them all at once probably is
better than unlinking them one-by-one (although it shouldn't matter
with the low amount of files here..)

 src/PVE/Network/SDN/Dhcp/Dnsmasq.pm | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/PVE/Network/SDN/Dhcp/Dnsmasq.pm 
b/src/PVE/Network/SDN/Dhcp/Dnsmasq.pm
index e65e973..2844943 100644
--- a/src/PVE/Network/SDN/Dhcp/Dnsmasq.pm
+++ b/src/PVE/Network/SDN/Dhcp/Dnsmasq.pm
@@ -234,7 +234,13 @@ CFG
$default_dnsmasq_config
 );
 
-unlink glob "$config_directory/10-*.conf";
+my @config_files = ();
+PVE::Tools::dir_glob_foreach($config_directory, '10-.*\.conf', sub {
+   my ($file) = @_;
+   push @config_files, "$config_directory/$file";
+});
+
+unlink @config_files;
 }
 
 sub after_configure {
-- 
2.39.2


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel



[pve-devel] [PATCH pve-manager] sdn: ipam: fix ipam grouping identical subnets in different vnets

2023-11-28 Thread Stefan Hanreich
When SDN is configured with the same subnet in two different VNets the
IPAM tree would render them wrongly.

Reported-By: Hannes Duerr 
Signed-off-by: Stefan Hanreich 
---
 www/manager6/tree/DhcpTree.js | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/www/manager6/tree/DhcpTree.js b/www/manager6/tree/DhcpTree.js
index d0b80803d..60029d3f4 100644
--- a/www/manager6/tree/DhcpTree.js
+++ b/www/manager6/tree/DhcpTree.js
@@ -60,7 +60,11 @@ Ext.define('PVE.sdn.DhcpTree', {
zones[element.zone].children.push(vnet);
}
 
-   if (!(element.subnet in subnets)) {
+   if (!(element.vnet in subnets)) {
+   subnets[element.vnet] = {};
+   }
+
+   if (!(element.subnet in subnets[element.vnet])) {
let subnet = {
name: element.subnet,
zone: element.zone,
@@ -71,13 +75,13 @@ Ext.define('PVE.sdn.DhcpTree', {
children: [],
};
 
-   subnets[element.subnet] = subnet;
+   subnets[element.vnet][element.subnet] = subnet;
vnets[element.vnet].children.push(subnet);
}
 
element.type = 'mapping';
element.iconCls = 'x-tree-icon-none';
-   subnets[element.subnet].children.push(element);
+   
subnets[element.vnet][element.subnet].children.push(element);
});
 
me.getView().setRootNode(root);
-- 
2.39.2


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel