November 2020 - FreeIPA-devel - Fedora mailing-lists

[freeipa PR#4909][opened] Add unauthenticated nsupdate
by fcami 28 Jun '21

28 Jun '21

URL: https://github.com/freeipa/freeipa/pull/4909 Author: fcami Title: #4909: Add unauthenticated nsupdate Action: opened PR body: """ ipa-client-install: update sssd.conf if nsupdate requires -g If dynamic DNS updates are selected, sssd will use GSS-TSIG by default for nsupdate. When ipa-client-install notices that plain nsupdate is required, switch sssd to use no authentication for dynamic updates too. Fixes: https://pagure.io/freeipa/issue/8402 + ipa-client-install: invoke nsupdate twice (GSS-TSIG, plain) ipa-client-install invokes nsupdate with GSS-TSIG at client enrollment time. If that fails, no retry is done. Change that behavior to try again without GSS-TSIG. Fixes: https://pagure.io/freeipa/issue/8402 #### This is purely WIP: - it needs a proper test - there are more nsupdate calls that should be adapted. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/4909/head:pr4909 git checkout pr4909

2 1

[freeipa PR#5256][opened] Handle multiple AJP adapters during upgrade
by cipherboy 25 Mar '21

25 Mar '21

URL: https://github.com/freeipa/freeipa/pull/5256 Author: cipherboy Title: #5256: Handle multiple AJP adapters during upgrade Action: opened PR body: """ In this patch, we ensure we upgrade all AJP adapters with the same secret value if any are missing. This ensures that both IPv4 and IPv6 adapters have the same secret value, so whichever httpd connects to will be in sync. This is consistent with what Dogtag does when provisioning them. Notably missing from this patch is handling of multiple unrelated AJP adapters. In an IPA scenario (and default PKI scenario) this shouldn't be necessary. However, with external load balancing, this might happen. This patch benefits IPA in the scenario when: 1. `pkispawn` runs on an older PKI version (pre-AJP secret, so ~8.2?) 2. pki gets upgraded to 10.10.1 before IPA can provision a secret, resulting in split IPv4/IPv6 adapters -- this would only happen on a direct migration from 8.2 -> 8.4 3. ipa upgrade script then runs to provision an AJP secret value for use with both Dogtag and IPA. Without this patch, only the first (IPv4) adapter would have a secret value provisioned in the above scenario. `Signed-off-by: Alexander Scheel <ascheel(a)redhat.com>` --- Is this scenario likely? Or will IPA have provisioned a secret anyway on older PKI versions? I do not know. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/5256/head:pr5256 git checkout pr5256

2 1

[freeipa PR#4923][opened] Add support for app passwords
by RichardKalinec 07 Mar '21

07 Mar '21

URL: https://github.com/freeipa/freeipa/pull/4923 Author: RichardKalinec Title: #4923: Add support for app passwords Action: opened PR body: """ Users will be able to have additional passwords besides the primary one - app passwords. They will be usable for accessing all systems and services that his/her FreeIPA account is used for, but not to manage the account (including configuring the app passwords). Resolves: https://pagure.io/freeipa/issue/4510 Design page and its discussion: https://github.com/freeipa/freeipa/pull/4061 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/4923/head:pr4923 git checkout pr4923

2 1

[freeipa PR#4061][opened] doc/designs: Add a design page for application-specific passwords
by RichardKalinec 07 Mar '21

07 Mar '21

URL: https://github.com/freeipa/freeipa/pull/4061 Author: RichardKalinec Title: #4061: doc/designs: Add a design page for application-specific passwords Action: opened PR body: """ This design page describes a new enhancement: application-specific passwords and permissions management for them. Users will be able to have additional passwords besides the primary one, and set permissions for them specifying what systems and services will each application-specific password have access to. Application-specific passwords will also be usable with other authentication mechanisms incorporating passwords, namely otp, radius and hardened. They will also be supported by ipa-kdb for Kerberos authentication. https://pagure.io/freeipa/issue/4510 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/4061/head:pr4061 git checkout pr4061

2 1

[freeipa PR#5071][opened] 389-DS BDB: switch deadlock behavior to DB_LOCK_MINWRITE
by fcami 14 Feb '21

14 Feb '21

URL: https://github.com/freeipa/freeipa/pull/5071 Author: fcami Title: #5071: 389-DS BDB: switch deadlock behavior to DB_LOCK_MINWRITE Action: opened PR body: """ Some IPA updates are expensive in term of processing and #page hit. The likelihood to generate a DS Berkeley DB database deadlock can be high for some common operations. When a deadlock is detected one deadlocking thread needs to be rejected to let the other(s) complete. DB_LOCK_YOUNGEST (9) is the DS default: it means the most recent operation fails in favor to the oldest one. DB_LOCK_MINWRITE (6) means the reader(s) are rejected in favor of the writers even if the reader(s) are older. Switch the default for FreeIPA to DB_LOCK_MINWRITE for new installs and also existing installs at update time. This depends on the backend redesign (https://pagure.io/389-ds-base/issue/49476) and therefore is valid on 389-DS 1.4.2.3 and higher. Explanation provided by Thierry Bordaz. Fixes: https://pagure.io/freeipa/issue/8479 Signed-off-by: François Cami <fcami(a)redhat.com> """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/5071/head:pr5071 git checkout pr5071

2 1

[freeipa PR#5176][opened] freeipa.spec.in: depend on libsss_sudo
by fcami 04 Feb '21

04 Feb '21

URL: https://github.com/freeipa/freeipa/pull/5176 Author: fcami Title: #5176: freeipa.spec.in: depend on libsss_sudo Action: opened PR body: """ On 10.10+ releases od Dogtag, the PKI installer will not depend on sudo anymore. This opens the possibility of creating IPA servers without a properly configured sudo. Depend on libsss_sudo to make sure all IPA servers can have sudo. Fixes: https://pagure.io/freeipa/issue/8530 Signed-off-by: François Cami <fcami(a)redhat.com> """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/5176/head:pr5176 git checkout pr5176

2 1

[freeipa PR#5280][opened] [ipa-4-9] ipatests: Update PR-CI definitions for ipa-4-9
by netoarmando 19 Jan '21

19 Jan '21

URL: https://github.com/freeipa/freeipa/pull/5280 Author: netoarmando Title: #5280: [ipa-4-9] ipatests: Update PR-CI definitions for ipa-4-9 Action: opened PR body: """ Adding PR-CI definitions for gating and "latest" nightly runs. Not including a definition for previous release, this must be done when updating from 32 to 33. Signed-off-by: Armando Neto <abiagion(a)redhat.com> """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/5280/head:pr5280 git checkout pr5280

2 1

[freeipa PR#5264][opened] [ipatests] Raise log level of 389-ds replication
by stanislavlevin 19 Jan '21

19 Jan '21

URL: https://github.com/freeipa/freeipa/pull/5264 Author: stanislavlevin Title: #5264: [ipatests] Raise log level of 389-ds replication Action: opened PR body: """ - change log level for replication debugging According to the docs: ``` default level of logging(16384) used for critical errors and other messages that are always written to the error log. Messages at this level are always included in the error log, regardless of the log level setting. ``` - always flush the access logs to filesystem During the testing access logs may be written with a significant delay, this results in logs are not collected by this test node, but for example, the next one. - as of now, the changes on `cn=config` are made after the installation of a server or replica. If an error occurs during these stages, then the actual log level will be the default and not as expected. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/5264/head:pr5264 git checkout pr5264

2 1

[freeipa PR#5188][opened] [ipa-4-8] ipatests: update PR-CI templates to Fedora 33
by netoarmando 11 Jan '21

11 Jan '21

URL: https://github.com/freeipa/freeipa/pull/5188 Author: netoarmando Title: #5188: [ipa-4-8] ipatests: update PR-CI templates to Fedora 33 Action: opened PR body: """ "previous" updated to Fedora 32 "latest" updated to Fedora 33 Fedora 33 is not released yet, therefore templates were based on nightly composes. Signed-off-by: Armando Neto <abiagion(a)redhat.com> """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/5188/head:pr5188 git checkout pr5188

1 1

[freeipa PR#5187][opened] [master] ipatests: update PR-CI templates to Fedora 33
by netoarmando 11 Jan '21

11 Jan '21

URL: https://github.com/freeipa/freeipa/pull/5187 Author: netoarmando Title: #5187: [master] ipatests: update PR-CI templates to Fedora 33 Action: opened PR body: """ "previous" updated to Fedora 32 "latest" updated to Fedora 33 "rawhide" based on Fedora 34 389ds, testing and pki definitions updated to Fedora 33 Fedora 33 is not released yet, therefore templates were based on nightly composes. Signed-off-by: Armando Neto <abiagion(a)redhat.com> """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/5187/head:pr5187 git checkout pr5187

1 1

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-devel November 2020