> However, is there any support for groups in OpenID Connect, or a similar
> concept?
In OpenID, it is possible to request "scopes" from the server, which can then
send additional data (claims).
But I am unsure if and how people use those system to manage groups. So what
kind of OpenID server
ZFS 2.1.2 handles this internally
(commit 16da688f2518526389e6bff8370684a1a2a1469c)
Signed-off-by: Stoiko Ivanov
---
...onfig-disable-module-BTF-debug-info.patch} | 0
...ove-the-ERESTARTSYS-handling-in-blkd.patch | 40 ---
2 files changed, 40 deletions(-)
rename patches/kernel
From: Aron Xu
(cherry picked from debian upstream [0]
commit 5ae98b5499022c2c127d546a7b5aeb906f6f2a6b)
[0] https://salsa.debian.org/zfsonlinux-team/zfs
Signed-off-by: Stoiko Ivanov
---
debian/rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
This patchset updates ZFS to 2.1.2 and adapt the buildsystem to it.
The cherry-picked patch from debian-upstream - of ignoring failed abigail
runs is due to ZFS switching over to libabigail 2.0.0 (which is not
available in bullseye) - one alternative could be to completely drop the
ABI checking in
else it is not easily applied with git am (as used by
debian/scripts/import-patchqueue)
Signed-off-by: Stoiko Ivanov
---
...Config-disable-module-BTF-debug-info.patch | 23 +++
patches/kernel/0009-disable-split-btf.patch | 13 ---
2 files changed, 23 insertions(+), 13 d
Signed-off-by: Stoiko Ivanov
---
debian/patches/0005-Enable-zed-emails.patch | 2 +-
debian/patches/0007-Use-installed-python3.patch | 6 +++---
upstream| 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/debian/patches/0005-Enable-ze
some feedback/known issues/.. from Dominik's testing:
- there is some mishandling with the export/import (hash keys with '-'
vs '_') that breaks rename and qcow2 support (already fixed locally)
- we could probably drop the targetnode parameter and replace it with
localhost, if we punt the nod
Since most zfs operations can take a while (under certain conditions),
increase the minimum timeout for zfs_request in workers to 5 minutes.
We cannot increase the timeouts in synchronous api calls, since they are
hard limited to 30 seconds, but in worker we do not have such limits.
The existing
