This is still applicable to the latest master for the referenced
repositories. Any movement?
On Fri, Aug 30, 2024, 5:34 PM Thomas Skinner wrote:
> In the OpenID Connect documentation (
> https://openid.net/specs/openid-connect-core-1_0.html), the
> protocol abstract defined in 1.3 states in step
This is still applicable to the latest master for the referenced
repositories. Any movement?
On Sun, Sep 1, 2024, 11:55 AM Thomas Skinner wrote:
> This patch series adds support for groups for OpenID logins.
>
> The following options are implemented:
> - Configurable claim for retrieving a lis
Fixes rare read corruption issues using the in kernel ceph client.
On incomplete read requests, the clean tail flag should make sure to
zero fill the remaining bytes for the subrequest.
If the iov iterator is not at the correct position, this can however
zero fill downloaded data, corrupting the r
a new v5 has been sent
https://lore.proxmox.com/pve-devel/20241002131157.227292-1-a.laute...@proxmox.com/T/#t
On 2024-07-29 13:55, Aaron Lauterer wrote:
since I only incorporated smaller suggested changes, I left the r-b and
t-b in place.
this version reworks a few parts since
v3: incorporat
The API itself allows several list separators. The network configuration
for bridge_vids expects a space separated list. We therefore convert it
initially to a space separated list.
Signed-off-by: Aaron Lauterer
---
I opted for a comment before the step where we split and reassemble the
list with
In some situations we don't want a total empty list. I opted for a
dedicated function instead of integrating it as error in the
`split_list` function. It is used in many places and the potential
fallout from unintended behavior changes is too big.
Signed-off-by: Aaron Lauterer
---
changes since:
This is one step to make it possible to define the VLAN IDs and ranges
for bridges.
It is expected to be used in combination with the `-list` magic
property. Therefore it defines and checks the validity of a single list
item that could just be a single VLAN tag ID or a range.
Signed-off-by: Aaron
The new optional bridge_vids field allows to set that property via the
GUI. Since the backend needs to support it, the field needs to be
explicitly enabled.
For now, Proxmox VE (PVE) is the use case.
Signed-off-by: Aaron Lauterer
Tested-By: Stefan Hanreich
Reviewed-by: Shannon Sterz
---
change
Since this version reworks a few things, especially in the logic, I
dropped the r-b and t-b tags in some patches.
The following patch has been dropped as this is handled in the API call
itself now.
[PATCH common v4 3/7] inotify: interfaces: make sure bridge_vids use space as
separator
There is n
Signed-off-by: Aaron Lauterer
Tested-By: Stefan Hanreich
Reviewed-by: Shannon Sterz
---
changes since
v4: none
v3: none
v2: none
www/manager6/node/Config.js | 1 +
1 file changed, 1 insertion(+)
diff --git a/www/manager6/node/Config.js b/www/manager6/node/Config.js
index d27592ce..7bdfb6d9 10
The old check for defined would also be true if it contained an empty
string. By checking its truthyness, an empty string will be falsy and
therefore the default value will be used.
Signed-off-by: Aaron Lauterer
---
changes since:
v4: newly added
src/PVE/INotify.pm | 2 +-
1 file changed, 1 ins
Make clear that it affects only out-/inbound traffic and can be used if
the underlying physical NICs support only a limited number of VLANs when
offloading is possible.
Signed-off-by: Aaron Lauterer
Reviewed-by: Shannon Sterz
---
changes since
v4: none
v3-follow-up:
* reordered inside the patch
v2 posted:
https://lore.proxmox.com/pve-devel/20241002122933.628461-1-c.he...@proxmox.com/
On Tue, May 28, 2024 at 10:13:41AM GMT, Christoph Heiss wrote:
> This uses the regex for elements as defined in
> the HTML spec to validate emails in the installer. That regex should be
> a lot more robust
That regex should be a lot more accurate in what it allows - if it's
good enough for the HTML spec, it should be for us too.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* move `EMAIL_DEFAULT_PLACEHOLDER` constant to
proxmox-installer-common/lib.rs
proxmox-installer-common/Cargo.t
This uses the regex for elements as defined in
the HTML spec to validate emails in the installer. That regex should be
a lot more robust than our current on and cover basically all cases of
email addresses that might be encountered in the while.
Also, patch #6 adds validation for the auto-install
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* no changes
Cargo.toml| 2 ++
proxmox-auto-install-assistant/Cargo.toml | 2 +-
proxmox-auto-installer/Cargo.toml | 2 +-
proxmox-chroot/Cargo.toml | 2 +-
proxmox-fetch-answer/Cargo.t
That regex should be a lot more accurate in what it allows - if it's
good enough for the HTML spec, it should be for us too.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* no changes
Proxmox/Makefile | 1 +
Proxmox/Sys.pm | 9 +
proxinstall | 3 ++-
3 files changed, 12
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* instead of re-using/-naming the `verify_locale_settings()` for the
email validation, combine it the with root password validation
proxmox-auto-installer/src/utils.rs | 12
1 file changed, 8 insertions(+), 4 deletions(-)
d
Otherwise, context info is simply lost -- which might contain valuable
information for the user.
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* no changes
proxmox-auto-installer/src/bin/proxmox-auto-installer.rs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/proxm
Signed-off-by: Christoph Heiss
---
Changes v1 -> v2:
* no changes
proxmox-auto-installer/src/utils.rs | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/proxmox-auto-installer/src/utils.rs
b/proxmox-auto-installer/src/utils.rs
index 45ad222..cc483c9 100644
--- a/proxm
On Sun Sep 29, 2024 at 10:52 AM CEST, =?utf-8?B?SmFtZXMgQnJvd24=?= wrote:
> https://github.com/proxmox/pve-common/pull/11
Hi,
thanks for your contribution! Please note that the GitHub repositories
are read-only and we do not accept pull requests there. Would you mind
re-submitting the patches in
note that the gui's default is a bit "fake". it pre-sets the field to
`x86-64-v2-AES`, but if you click the little "x" next to it, the field
will be cleared and if you submit the form like that the default ends up
being `kvm64` again. this happens because the final config file does not
specify a cp
22 matches
Mail list logo
