[Freeipa] [Bug 2040359] Re: Merge bind9 from Debian unstable for noble
rds with a TTL value larger than 86400 seconds when dnssec-policy is set to insecure. + Fix the ability to read HMAC-MD5 key files (LP: #2015176). + Fix stability issues with the catalog zone implementation. - See https://bind9.readthedocs.io/en/v9.18.18/notes.html for additional information. -- Lena Voytek Tue, 05 Sep 2023 13:20:06 -0700 bind9 (1:9.18.16-1ubuntu4) mantic; urgency=medium * d/t/dyndb-ldap: allow writing to the dns tree (LP: #2034250) -- Andreas Hasenack Tue, 05 Sep 2023 10:20:27 -0300 bind9 (1:9.18.16-1ubuntu3) mantic; urgency=medium * d/t/control: exclude the i386 architecture for the dyndb-ldap test, since bind9-dyndb-ldap is not available there on Ubuntu * d/t/dyndb-ldap: fix for the ldap bind9 dn entry -- Andreas Hasenack Wed, 30 Aug 2023 10:14:04 -0300 bind9 (1:9.18.16-1ubuntu2) mantic; urgency=medium * d/t/control, d/t/dyndb-ldap: add DEP8 test (LP: #2032650) -- Andreas Hasenack Tue, 22 Aug 2023 09:24:02 -0300 bind9 (1:9.18.16-1ubuntu1) mantic; urgency=medium * Merge with Debian unstable (LP: #2018050). Remaining changes: - Don't build dnstap as it depends on universe packages: + d/control: drop build-depends on libfstrm-dev, libprotobuf-c-dev and protobuf-c-compiler (universe packages) + d/dnsutils.install: don't install dnstap + d/rules: don't build dnstap nor install dnstap.proto - Add back apport: + d/bind9.apport: add back old bind9 apport hook, but without calling attach_conffiles() since that is already done by apport itself, with confirmation from the user. + d/control, d/rules: build-depends on dh-apport and use it - d/control: remove optional libjemalloc-dev Build-Depends as it is not in main. - d/NEWS: mention relevant packaging changes - Improve dep-8 test suite (LP #2003584): + d/t/zonetest: Add dep8 test for checking the domain zone creation process + d/t/control: Add new test outline * Added Changes: - d/po/de.po: Fix German UTF-8 encoding - d/copyright: Fix lintian warnings + Remove the entry for lib/isc/hp.c lib/isc/include/isc/hp.h as they were deleted in 9.18.2 + Remove the entry for lib/isc/include/pkcs11/pkcs11.h as it is no longer bundled as of 9.17.19 + Update the location of random_test.c and add info about its public domain section + Add wildcards to folders as needed + Note that m4/ uses the FSFAP license - d/control: Remove lsb-base dependency as it is no longer needed + See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019851 -- Lena Voytek Mon, 26 Jun 2023 14:25:50 -0700 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2040359/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1978849] Re: bind9-dyndb-ldap has unmet dependencies
This was fix released for lunar on https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.10-4ubuntu0.1 ** Changed in: bind-dyndb-ldap (Ubuntu Lunar) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/1978849 Title: bind9-dyndb-ldap has unmet dependencies Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Invalid Status in bind-dyndb-ldap source package in Focal: Won't Fix Status in bind-dyndb-ldap source package in Jammy: Fix Released Status in bind-dyndb-ldap source package in Lunar: Fix Released Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Invalid Bug description: [ Impact ] There is a tight coupling between src:bind-dyndb-ldap and src:bind9, such that everytime bind9 is updated, even if it's a simple no-change rebuild, src:bind-dyndb-ldap has to be rebuilt too. This is often forgotten, leading to multiple repeated bugs against src:bind-dyndb-ldap. The fix for now is to rebuild src:bind-dyndb-ldap, and to avoid it from happening again, add a DEP8 test to it so that a src:bind9 update won't be released without this rebuild. Ideally this coupling shouldn't be that tight, and some ideas are floating around (see [1], [2], and [3]). But for now, I think this is the quickest way to avoid hitting this problem again in the near future. 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 2. https://pagure.io/bind-dyndb-ldap/issue/225 3. https://salsa.debian.org/dns-team/bind9/-/merge_requests/21 [ Test Plan ] The fix is to rebuild the src:bind-dyndb-ldap package with the current src:bind9 in the archive for the affected ubuntu release. With the build succeeding, and the dyndb-ldap DEP8 test also passing, the verification can be considered successfull. [ Where problems could occur ] With this new DEP8 change, a bind9 update can be blocked by a bind- dyndb-ldap failure to build or run with it. While this is exactly the intent (not leave a broken bind-dyndb-ldap package in the release), there is a history indicating that bind- dyndb-ldap can be late in catching up to bind9 changes. We may reach a situation where an important bind9 security update, for example, will be blocked by a failing dyndb-ldap test, and it may be difficult to fix bind-dyndb-ldap in time, specially if the security update is under embargo and the bind-dyndb-ldap developers do not yet have details of the changes. [ Other Info ] See also bug https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2032650 which adds the same test to the src:bind9 package. [Original Description] bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap: ~# apt install bind9 bind9-dyndb-ldap Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed E: Unable to correct problems, you have held broken packages. ~# apt-cache policy bind9 bind9: Installed: (none) Candidate: 1:9.18.1-1ubuntu1.1 Version table: 1:9.18.1-1ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 1:9.18.1-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages ~# apt-cache policy bind9-dyndb-ldap bind9-dyndb-ldap: Installed: (none) Candidate: 11.9-5build2 Version table: 11.9-5build2 500 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/1978849/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 2032650] Re: Add DEP8 tests for bind-dyndb-ldap integration
This was fix released for lunar on https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.10-4ubuntu0.1 ** Changed in: bind-dyndb-ldap (Ubuntu Lunar) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/2032650 Title: Add DEP8 tests for bind-dyndb-ldap integration Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Fix Released Status in bind-dyndb-ldap source package in Jammy: Fix Released Status in bind9 source package in Jammy: Fix Released Status in bind-dyndb-ldap source package in Lunar: Fix Released Status in bind9 source package in Lunar: Fix Released Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Fix Released Bug description: [ Impact ] bind-dyndb-ldap breaks very frequently with bind9 updates. Both must have DEP8 tests so these breakages can be caught before a release. [ Test Plan ] For both packages, the test plan consists in having the new dyndb-ldap DEP8 test run and succeed. [ Where problems could occur ] With this new DEP8 change, a bind9 update can be blocked by a bind-dyndb-ldap failure to build or run with it. While this is exactly the intent (not leave a broken bind-dyndb-ldap package in the release), there is a history indicating that bind- dyndb-ldap can be late in catching up to bind9 changes. We may reach a situation where an important bind9 security update, for example, will be blocked by a failing dyndb-ldap test, and it may be difficult to fix bind-dyndb-ldap in time, specially if the security update is under embargo and the bind-dyndb-ldap developers do not yet have details of the changes. [ Other Info ] The same test is to be applied to the bind9 package, and is already in mantic. But SRUs for DEP8 changes only are frowned upon, so the plan is to upload it to proposed and block it there, but AFTER bind-dyndb-ldap has been released. The tight coupling between bind9 and bind-dyndb-ldap is problematic (see [1], [2] and [3]). The moment a new bind9 hits proposed with this test, it fill fail until a new bind-dyndb-ldap is rebuilt with that proposed version. One option would perhaps to accept a one-time DEP8-only change for bind9, so that we can upload both packages together, instead of leaving this in proposed with a blocking tag, to be picked up by the next bind9 "real" update? 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 2. https://pagure.io/bind-dyndb-ldap/issue/225 3. https://salsa.debian.org/dns-team/bind9/-/merge_requests/21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2032650/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1987276] Re: certmonger - libcrypto issues with openssl3
This bug is awaiting verification for a long time now, could someone affected please perform the verification from the test plan? -- You received this bug notification because you are a member of FreeIPA, which is subscribed to certmonger in Ubuntu. https://bugs.launchpad.net/bugs/1987276 Title: certmonger - libcrypto issues with openssl3 Status in certmonger package in Ubuntu: Fix Released Status in certmonger source package in Jammy: Fix Committed Bug description: [Impact] Requesting SCEP certificates crashes certmonger when it's built with OpenSSL 3, and it needs a patch backported to fix this. [Test case] Check that the SCEP requests succeed without the daemon crashing. [Where things could go wrong] This patch has been upstream for several months now, and this part of certmonger hasn't seen any additional commits since, so it's safe to say that adding this shouldn't regress things. -- I just want to let you know that this bug is still present from 22.04 onwards (anything that uses libssl3 as default) - bug is being tracked in https://pagure.io/certmonger/issue/244 - I already tested the patch provided and it works, but I would love to see an updated package on the official repository. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/certmonger/+bug/1987276/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 2028413] Re: MRE updates of bind9 for focal, jammy and lunar
** Description changed: This bug tracks an update for the bind9 package, moving to versions: * lunar (23.04): bind9 9.18.18 * jammy (22.04): bind9 9.18.18 * focal (20.04): bind9 9.16.43 These updates include bug fixes following the SRU policy exception defined at https://wiki.ubuntu.com/Bind9Updates. [Upstream changes] 9.18.13-9.18.18 for lunar and jammy: Updates: Mark a primary server as temporarily unreachable when a TCP connection response to an SOA query times out, matching behavior of a refused TCP connection. Mark dialup and heartbeat-interval options as deprecated. Retry DNS queries without an EDNS COOKIE when the first response is FORMERR with the EDNS COOKIE that was sent originally. Use NS records for the relaxed QNAME minimization mode to reduce the number of queries from named. Mark TKEY mode 2 as deprecated. Mark delegation-only and root-delegation-only as deprecated. Run RPZ and catalog zone updates on specialized offload threads to reduce blocked query processing time. Bug Fixes: Fix assertion failure from processing already-queued queries while server is being reconfigured or cache is being flushed. Fix failure to load zones containing resource records with a TTL value larger than 86400 seconds when dnssec-policy is set to insecure. Fix the ability to read HMAC-MD5 key files (LP: #2015176). Fix stability issues with the catalog zone implementation. Fix bind9 getting stuck when listen-on statement for HTTP is removed from configuration. Do not return delegation from cache after stale-answer-client-timeout. Fix failure to auto-tune clients-per-query limit in some situations. Fix proper timeouts when using max-transfer-time-in and max-transfer-idle-in statements. Bring rndc read timeout back to 60 seconds from 30. Treat libuv returning ISC_R_INVALIDPROTO as a network error. Clean up empty-non-terminal NSEC3 records. Fix log file rotation cleanup for absolute file path destinations. Fix various catalog zone processing crashes. Fix transfer hang when downloading large zones over TLS. Fix named crash when adding a new zone into the configuration file for a name which was already configured as a member zone for a catalog zone. Delay DNSSEC key queries until all zones have finished loading. CVE Fixes - already available as patches: CVE-2023-2828 CVE-2023-2911 For full release notes, see: https://bind9.readthedocs.io/en/v9.18.18/notes.html#notes-for- bind-9-18-18 While there are behavioral changes in this release, I was unable to find any backwards-incompatible changes. Some features were marked as deprecated, but are still usable as they were before. Other changes are related to performance and timeout management, neither of which should change how bind9 works, but are worth keeping an eye on in case any regressions arise. [Test Plan] DEP-8 test results: simpletest PASS validation FLAKY non-zero exit status 1 zonetest PASS dyndb-ldap PASS validation is known to be broken in its current state, both due to a need for internet access and incorrect output checking, so the failure is expected. + [Other Information] + + Note to SRU team: this update must happen together with src:bind-dyndb-ldap, and in a particular order: + - first src:bind9 must be accepted + - once src:bind9 is fully built in all architectures, *then* src:bind-dyndb-ldap can be accepted. In other words, src:bind-dyndb-ldap must build with the new src:bind9 version. + - it is expected that until both packages are in proposed, DEP8 tests will fail. That's our safeguard against mistakenly releasing them out of sync + [Regression Potential] Upstream has an extensive build and integration test suite. So regressions would likely arise from a change in interaction with Ubuntu- specific integrations. ** Description changed: This bug tracks an update for the bind9 package, moving to versions: * lunar (23.04): bind9 9.18.18 * jammy (22.04): bind9 9.18.18 * focal (20.04): bind9 9.16.43 These updates include bug fixes following the SRU policy exception defined at https://wiki.ubuntu.com/Bind9Updates. [Upstream changes] 9.18.13-9.18.18 for lunar and jammy: Updates: Mark a primary server as temporarily unreachable when a TCP connection response to an SOA query times out, matching behavior of a refused TCP connection. Mark dialup and heartbeat-interval options as deprecated. Retry DNS queries without an EDNS COOKIE when the first response is FORMERR with the EDNS COOKIE that was sent originally. Use NS records for the relaxed QNAME minimization mode to reduce the number of queries from named. Mark TKEY mode 2 as deprecated. Mark delegation-only and root-delegation-only as deprecated. Run RPZ and catalog zone updates on specialized offload threads to reduce blocked query processing time. Bug Fixes:
[Freeipa] [Bug 2032650] Re: Add DEP8 tests for bind-dyndb-ldap integration
The dep8 tests are green. Jammy: https://ubuntu-archive-team.ubuntu.com/proposed- migration/jammy/update_excuses.html#bind-dyndb-ldap Lunar: https://ubuntu-archive-team.ubuntu.com/proposed- migration/lunar/update_excuses.html#bind-dyndb-ldap The security team just released USN-6390-1, which is about bind9, so bind-dyndb-ldap will need another rebuild. They agreed to grab this package from proposed and rebuild it in the security pocket, and if all goes well, they will push to the security pocket tomorrow. ** Tags removed: verification-needed-jammy verification-needed-lunar ** Tags added: verification-done-lunar verification-needed-done -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/2032650 Title: Add DEP8 tests for bind-dyndb-ldap integration Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Fix Released Status in bind-dyndb-ldap source package in Jammy: Fix Committed Status in bind9 source package in Jammy: New Status in bind-dyndb-ldap source package in Lunar: Fix Committed Status in bind9 source package in Lunar: New Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Fix Released Bug description: [ Impact ] bind-dyndb-ldap breaks very frequently with bind9 updates. Both must have DEP8 tests so these breakages can be caught before a release. [ Test Plan ] For both packages, the test plan consists in having the new dyndb-ldap DEP8 test run and succeed. [ Where problems could occur ] With this new DEP8 change, a bind9 update can be blocked by a bind-dyndb-ldap failure to build or run with it. While this is exactly the intent (not leave a broken bind-dyndb-ldap package in the release), there is a history indicating that bind- dyndb-ldap can be late in catching up to bind9 changes. We may reach a situation where an important bind9 security update, for example, will be blocked by a failing dyndb-ldap test, and it may be difficult to fix bind-dyndb-ldap in time, specially if the security update is under embargo and the bind-dyndb-ldap developers do not yet have details of the changes. [ Other Info ] The same test is to be applied to the bind9 package, and is already in mantic. But SRUs for DEP8 changes only are frowned upon, so the plan is to upload it to proposed and block it there, but AFTER bind-dyndb-ldap has been released. The tight coupling between bind9 and bind-dyndb-ldap is problematic (see [1], [2] and [3]). The moment a new bind9 hits proposed with this test, it fill fail until a new bind-dyndb-ldap is rebuilt with that proposed version. One option would perhaps to accept a one-time DEP8-only change for bind9, so that we can upload both packages together, instead of leaving this in proposed with a blocking tag, to be picked up by the next bind9 "real" update? 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 2. https://pagure.io/bind-dyndb-ldap/issue/225 3. https://salsa.debian.org/dns-team/bind9/-/merge_requests/21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2032650/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1978849] Re: bind9-dyndb-ldap has unmet dependencies
For the jammy verification: DEP8 tests are green: https://ubuntu-archive-team.ubuntu.com/proposed-migration/jammy/update_excuses.html#bind-dyndb-ldap Package built correctly in all arches: https://launchpad.net/ubuntu/+source/bind-dyndb- ldap/11.9-5ubuntu0.22.04.2 And was test-installed in comment #18 Jammy verification succeeded. -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/1978849 Title: bind9-dyndb-ldap has unmet dependencies Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Invalid Status in bind-dyndb-ldap source package in Focal: Won't Fix Status in bind-dyndb-ldap source package in Jammy: Fix Committed Status in bind-dyndb-ldap source package in Lunar: Fix Committed Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Invalid Bug description: [ Impact ] There is a tight coupling between src:bind-dyndb-ldap and src:bind9, such that everytime bind9 is updated, even if it's a simple no-change rebuild, src:bind-dyndb-ldap has to be rebuilt too. This is often forgotten, leading to multiple repeated bugs against src:bind-dyndb-ldap. The fix for now is to rebuild src:bind-dyndb-ldap, and to avoid it from happening again, add a DEP8 test to it so that a src:bind9 update won't be released without this rebuild. Ideally this coupling shouldn't be that tight, and some ideas are floating around (see [1], [2], and [3]). But for now, I think this is the quickest way to avoid hitting this problem again in the near future. 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 2. https://pagure.io/bind-dyndb-ldap/issue/225 3. https://salsa.debian.org/dns-team/bind9/-/merge_requests/21 [ Test Plan ] The fix is to rebuild the src:bind-dyndb-ldap package with the current src:bind9 in the archive for the affected ubuntu release. With the build succeeding, and the dyndb-ldap DEP8 test also passing, the verification can be considered successfull. [ Where problems could occur ] With this new DEP8 change, a bind9 update can be blocked by a bind- dyndb-ldap failure to build or run with it. While this is exactly the intent (not leave a broken bind-dyndb-ldap package in the release), there is a history indicating that bind- dyndb-ldap can be late in catching up to bind9 changes. We may reach a situation where an important bind9 security update, for example, will be blocked by a failing dyndb-ldap test, and it may be difficult to fix bind-dyndb-ldap in time, specially if the security update is under embargo and the bind-dyndb-ldap developers do not yet have details of the changes. [ Other Info ] See also bug https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2032650 which adds the same test to the src:bind9 package. [Original Description] bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap: ~# apt install bind9 bind9-dyndb-ldap Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed E: Unable to correct problems, you have held broken packages. ~# apt-cache policy bind9 bind9: Installed: (none) Candidate: 1:9.18.1-1ubuntu1.1 Version table: 1:9.18.1-1ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 1:9.18.1-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages ~# apt-cache policy bind9-dyndb-ldap bind9-dyndb-ldap: Installed: (none) Candidate: 11.9-5build2 Version table: 11.9-5build2 500 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/1978849/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1978849] Re: bind9-dyndb-ldap has unmet dependencies
Lunar verification DEP8 results are green: https://ubuntu-archive-team.ubuntu.com/proposed- migration/lunar/update_excuses.html#bind-dyndb-ldap Build OK in all arches: https://launchpad.net/ubuntu/+source/bind-dyndb- ldap/11.10-4ubuntu0.1 Also did a quick manual install of the proposed package: $ sudo apt install bind9-dyndb-ldap -t lunar-proposed -y Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: bind9 bind9-utils dns-root-data Suggested packages: bind-doc The following NEW packages will be installed: bind9 bind9-dyndb-ldap bind9-utils dns-root-data (...) $ apt-cache policy bind9-dyndb-ldap bind9-dyndb-ldap: Installed: 11.10-4ubuntu0.1 Candidate: 11.10-4ubuntu0.1 Version table: *** 11.10-4ubuntu0.1 500 500 http://br.archive.ubuntu.com/ubuntu lunar-proposed/universe amd64 Packages 100 /var/lib/dpkg/status 11.10-4 500 500 http://br.archive.ubuntu.com/ubuntu lunar/universe amd64 Packages No installation errors: $ dpkg -l bind9-dyndb-ldap Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++----= ii bind9-dyndb-ldap 11.10-4ubuntu0.1 amd64LDAP back-end plug-in for BIND lunar verification succeeded ** Tags removed: verification-needed-lunar ** Tags added: verification-done-lunar -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/1978849 Title: bind9-dyndb-ldap has unmet dependencies Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Invalid Status in bind-dyndb-ldap source package in Focal: Won't Fix Status in bind-dyndb-ldap source package in Jammy: Fix Committed Status in bind-dyndb-ldap source package in Lunar: Fix Committed Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Invalid Bug description: [ Impact ] There is a tight coupling between src:bind-dyndb-ldap and src:bind9, such that everytime bind9 is updated, even if it's a simple no-change rebuild, src:bind-dyndb-ldap has to be rebuilt too. This is often forgotten, leading to multiple repeated bugs against src:bind-dyndb-ldap. The fix for now is to rebuild src:bind-dyndb-ldap, and to avoid it from happening again, add a DEP8 test to it so that a src:bind9 update won't be released without this rebuild. Ideally this coupling shouldn't be that tight, and some ideas are floating around (see [1], [2], and [3]). But for now, I think this is the quickest way to avoid hitting this problem again in the near future. 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 2. https://pagure.io/bind-dyndb-ldap/issue/225 3. https://salsa.debian.org/dns-team/bind9/-/merge_requests/21 [ Test Plan ] The fix is to rebuild the src:bind-dyndb-ldap package with the current src:bind9 in the archive for the affected ubuntu release. With the build succeeding, and the dyndb-ldap DEP8 test also passing, the verification can be considered successfull. [ Where problems could occur ] With this new DEP8 change, a bind9 update can be blocked by a bind- dyndb-ldap failure to build or run with it. While this is exactly the intent (not leave a broken bind-dyndb-ldap package in the release), there is a history indicating that bind- dyndb-ldap can be late in catching up to bind9 changes. We may reach a situation where an important bind9 security update, for example, will be blocked by a failing dyndb-ldap test, and it may be difficult to fix bind-dyndb-ldap in time, specially if the security update is under embargo and the bind-dyndb-ldap developers do not yet have details of the changes. [ Other Info ] See also bug https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2032650 which adds the same test to the src:bind9 package. [Original Description] bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap: ~# apt install bind9 bind9-dyndb-ldap Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: bind9-dyndb-ldap : Depends:
[Freeipa] [Bug 1978849] Re: bind9-dyndb-ldap has unmet dependencies
** Description changed: + [ Impact ] + + * An explanation of the effects of the bug on users and + + * justification for backporting the fix to the stable release. + + * In addition, it is helpful, but not required, to include an +explanation of how the upload fixes this bug. + + [ Test Plan ] + + * detailed instructions how to reproduce the bug + + * these should allow someone who is not familiar with the affected +package to reproduce the bug and verify that the updated package fixes +the problem. + + * if other testing is appropriate to perform before landing this update, +this should also be described here. + + [ Where problems could occur ] + + * Think about what the upload changes in the software. Imagine the change is +wrong or breaks something else: how would this show up? + + * It is assumed that any SRU candidate patch is well-tested before +upload and has a low overall risk of regression, but it's important +to make the effort to think about what ''could'' happen in the +event of a regression. + + * This must '''never''' be "None" or "Low", or entirely an argument as to why +your upload is low risk. + + * This both shows the SRU team that the risks have been considered, +and provides guidance to testers in regression-testing the SRU. + + [ Other Info ] + + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance + + + [Original Description] + bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap: - ~# apt install bind9 bind9-dyndb-ldap - Reading package lists... Done - Building dependency tree... Done - Reading state information... Done - Some packages could not be installed. This may mean that you have - requested an impossible situation or if you are using the unstable - distribution that some required packages have not yet been created - or been moved out of Incoming. - The following information may help to resolve the situation: + ~# apt install bind9 bind9-dyndb-ldap + Reading package lists... Done + Building dependency tree... Done + Reading state information... Done + Some packages could not be installed. This may mean that you have + requested an impossible situation or if you are using the unstable + distribution that some required packages have not yet been created + or been moved out of Incoming. + The following information may help to resolve the situation: - The following packages have unmet dependencies: - bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed - E: Unable to correct problems, you have held broken packages. + The following packages have unmet dependencies: + bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed + E: Unable to correct problems, you have held broken packages. - ~# apt-cache policy bind9 - bind9: - Installed: (none) - Candidate: 1:9.18.1-1ubuntu1.1 - Version table: - 1:9.18.1-1ubuntu1.1 500 - 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages - 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages - 1:9.18.1-1ubuntu1 500 - 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages + ~# apt-cache policy bind9 + bind9: + Installed: (none) + Candidate: 1:9.18.1-1ubuntu1.1 + Version table: + 1:9.18.1-1ubuntu1.1 500 + 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages + 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages + 1:9.18.1-1ubuntu1 500 + 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages - ~# apt-cache policy bind9-dyndb-ldap - bind9-dyndb-ldap: - Installed: (none) - Candidate: 11.9-5build2 - Version table: - 11.9-5build2 500 - 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages + ~# apt-cache policy bind9-dyndb-ldap + bind9-dyndb-ldap: + Installed: (none) + Candidate: 11.9-5build2 + Version table: + 11.9-5build2 500 + 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages ** Description changed: [ Impact ] - * An explanation of the effects of the bug on users and + There is a tight coupling between src:bind-dyndb-ldap and src:bind9, + such that everytime bind9 is updated, even if it's a simple no-change + rebuild, src:bind-dyndb-ldap has to be rebuilt too. - * justification for backporting the fix to the stable release. + This is often forgotten, leading to multiple repeated bugs against +
[Freeipa] [Bug 2032650] Re: Add DEP8 tests for bind-dyndb-ldap integration
** Description changed: + [ Impact ] + bind-dyndb-ldap breaks very frequently with bind9 updates. Both must have DEP8 tests so these breakages can be caught before a release. + + [ Test Plan ] + + For both packages, the test plan consists in having the new dyndb-ldap + DEP8 test run and succeed. + + [ Where problems could occur ] + With this new DEP8 change, a bind9 update can be blocked by a bind-dyndb-ldap failure to build or run with it. + + While this is exactly the intent (not leave a broken bind-dyndb-ldap + package in the release), there is a history indicating that bind-dyndb- + ldap can be late in catching up to bind9 changes. We may reach a + situation where an important bind9 security update, for example, will be + blocked by a failing dyndb-ldap test, and it may be difficult to fix + bind-dyndb-ldap in time, specially if the security update is under + embargo and the bind-dyndb-ldap developers do not yet have details of + the changes. + + + [ Other Info ] + + The same test is to be applied to the bind9 package, and is already in mantic. But SRUs for DEP8 changes only are frowned upon, so the plan is to upload it to proposed and block it there, but AFTER bind-dyndb-ldap has been released. + + The tight coupling between bind9 and bind-dyndb-ldap is problematic (see + [1], [2] and [3]). The moment a new bind9 hits proposed with this test, + it fill fail until a new bind-dyndb-ldap is rebuilt with that proposed + version. + + One option would perhaps to accept a one-time DEP8-only change for + bind9, so that we can upload both packages together, instead of leaving + this in proposed with a blocking tag, to be picked up by the next bind9 + "real" update? + + + 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 + 2. https://pagure.io/bind-dyndb-ldap/issue/225 + 3. https://salsa.debian.org/dns-team/bind9/-/merge_requests/21 -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/2032650 Title: Add DEP8 tests for bind-dyndb-ldap integration Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Fix Released Status in bind-dyndb-ldap source package in Jammy: In Progress Status in bind9 source package in Jammy: New Status in bind-dyndb-ldap source package in Lunar: In Progress Status in bind9 source package in Lunar: New Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Fix Released Bug description: [ Impact ] bind-dyndb-ldap breaks very frequently with bind9 updates. Both must have DEP8 tests so these breakages can be caught before a release. [ Test Plan ] For both packages, the test plan consists in having the new dyndb-ldap DEP8 test run and succeed. [ Where problems could occur ] With this new DEP8 change, a bind9 update can be blocked by a bind-dyndb-ldap failure to build or run with it. While this is exactly the intent (not leave a broken bind-dyndb-ldap package in the release), there is a history indicating that bind- dyndb-ldap can be late in catching up to bind9 changes. We may reach a situation where an important bind9 security update, for example, will be blocked by a failing dyndb-ldap test, and it may be difficult to fix bind-dyndb-ldap in time, specially if the security update is under embargo and the bind-dyndb-ldap developers do not yet have details of the changes. [ Other Info ] The same test is to be applied to the bind9 package, and is already in mantic. But SRUs for DEP8 changes only are frowned upon, so the plan is to upload it to proposed and block it there, but AFTER bind-dyndb-ldap has been released. The tight coupling between bind9 and bind-dyndb-ldap is problematic (see [1], [2] and [3]). The moment a new bind9 hits proposed with this test, it fill fail until a new bind-dyndb-ldap is rebuilt with that proposed version. One option would perhaps to accept a one-time DEP8-only change for bind9, so that we can upload both packages together, instead of leaving this in proposed with a blocking tag, to be picked up by the next bind9 "real" update? 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 2. https://pagure.io/bind-dyndb-ldap/issue/225 3. https://salsa.debian.org/dns-team/bind9/-/merge_requests/21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2032650/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 2034251] Re: Incorrect rdn in the bind9 dn entry in the DEP8 test
Oops, this was fixed in bind9 already.
** No longer affects: bind9 (Ubuntu)
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to bind-dyndb-ldap in Ubuntu.
https://bugs.launchpad.net/bugs/2034251
Title:
Incorrect rdn in the bind9 dn entry in the DEP8 test
Status in bind-dyndb-ldap package in Ubuntu:
In Progress
Bug description:
There is a small mistake in the bind9 DN entry, it should have an
attribute matching the dn, but instead it mentions a "replicator"
entity that doesn't exist.
It doesn't fail the test, but it's an incorrect LDAP entry and should
be fixed:
diff --git a/debian/tests/dyndb-ldap b/debian/tests/dyndb-ldap
index 5482bc0..019bf24 100644
--- a/debian/tests/dyndb-ldap
+++ b/debian/tests/dyndb-ldap
@@ -8,6 +8,7 @@ myhostname="dep8"
ldap_admin_dn="cn=admin,${ldap_suffix}"
ldap_admin_pw="secret"
ldap_bind9_dn="uid=bind9,${ldap_suffix}"
+ldap_bind9_rdn="uid: bind9" # match ldap_bind9_dn
ldap_bind9_pw="secretagain"
cleanup() {
@@ -122,7 +123,7 @@ EOF
create_bind9_uid() {
ldapadd -x -D "${ldap_admin_dn}" -w "${ldap_admin_pw}"
[Freeipa] [Bug 2034251] [NEW] Incorrect rdn in the bind9 dn entry in the DEP8 test
Public bug reported:
There is a small mistake in the bind9 DN entry, it should have an
attribute matching the dn, but instead it mentions a "replicator"
entity that doesn't exist.
It doesn't fail the test, but it's an incorrect LDAP entry and should be
fixed:
diff --git a/debian/tests/dyndb-ldap b/debian/tests/dyndb-ldap
index 5482bc0..019bf24 100644
--- a/debian/tests/dyndb-ldap
+++ b/debian/tests/dyndb-ldap
@@ -8,6 +8,7 @@ myhostname="dep8"
ldap_admin_dn="cn=admin,${ldap_suffix}"
ldap_admin_pw="secret"
ldap_bind9_dn="uid=bind9,${ldap_suffix}"
+ldap_bind9_rdn="uid: bind9" # match ldap_bind9_dn
ldap_bind9_pw="secretagain"
cleanup() {
@@ -122,7 +123,7 @@ EOF
create_bind9_uid() {
ldapadd -x -D "${ldap_admin_dn}" -w "${ldap_admin_pw}" <https://salsa.debian.org/freeipa-
team/bind-dyndb-ldap/-/commit/6b5096776ee0502d9cac3966b6aa5f4da4cef664
** Affects: bind-dyndb-ldap (Ubuntu)
Importance: Low
Assignee: Andreas Hasenack (ahasenack)
Status: In Progress
** Affects: bind9 (Ubuntu)
Importance: Low
Assignee: Andreas Hasenack (ahasenack)
Status: In Progress
** Also affects: bind-dyndb-ldap (Ubuntu)
Importance: Undecided
Status: New
** Changed in: bind-dyndb-ldap (Ubuntu)
Status: New => In Progress
** Changed in: bind-dyndb-ldap (Ubuntu)
Importance: Undecided => Low
** Changed in: bind-dyndb-ldap (Ubuntu)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
** Summary changed:
- Incorrect rdn in the bind9 dn entry
+ Incorrect rdn in the bind9 dn entry in the DEP8 test
** Description changed:
There is a small mistake in the bind9 DN entry, it should have an
attribute matching the dn, but instead it mentions a "replicator"
entity that doesn't exist.
- It doesn't fail the test, but it's an incorrect LDAP entry:
+ It doesn't fail the test, but it's an incorrect LDAP entry and should be
+ fixed:
+
diff --git a/debian/tests/dyndb-ldap b/debian/tests/dyndb-ldap
index 5482bc0..019bf24 100644
--- a/debian/tests/dyndb-ldap
+++ b/debian/tests/dyndb-ldap
@@ -8,6 +8,7 @@ myhostname="dep8"
- ldap_admin_dn="cn=admin,${ldap_suffix}"
- ldap_admin_pw="secret"
- ldap_bind9_dn="uid=bind9,${ldap_suffix}"
+ ldap_admin_dn="cn=admin,${ldap_suffix}"
+ ldap_admin_pw="secret"
+ ldap_bind9_dn="uid=bind9,${ldap_suffix}"
+ldap_bind9_rdn="uid: bind9" # match ldap_bind9_dn
- ldap_bind9_pw="secretagain"
-
- cleanup() {
+ ldap_bind9_pw="secretagain"
+
+ cleanup() {
@@ -122,7 +123,7 @@ EOF
- create_bind9_uid() {
- ldapadd -x -D "${ldap_admin_dn}" -w "${ldap_admin_pw}" <https://salsa.debian.org/freeipa-team/bind-dyndb-ldap/-/commit/6b5096776ee0502d9cac3966b6aa5f4da4cef664
+ This was fixed in debian already via https://salsa.debian.org/freeipa-
+ team/bind-dyndb-ldap/-/commit/6b5096776ee0502d9cac3966b6aa5f4da4cef664
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to bind-dyndb-ldap in Ubuntu.
https://bugs.launchpad.net/bugs/2034251
Title:
Incorrect rdn in the bind9 dn entry in the DEP8 test
Status in bind-dyndb-ldap package in Ubuntu:
In Progress
Status in bind9 package in Ubuntu:
In Progress
Bug description:
There is a small mistake in the bind9 DN entry, it should have an
attribute matching the dn, but instead it mentions a "replicator"
entity that doesn't exist.
It doesn't fail the test, but it's an incorrect LDAP entry and should
be fixed:
diff --git a/debian/tests/dyndb-ldap b/debian/tests/dyndb-ldap
index 5482bc0..019bf24 100644
--- a/debian/tests/dyndb-ldap
+++ b/debian/tests/dyndb-ldap
@@ -8,6 +8,7 @@ myhostname="dep8"
ldap_admin_dn="cn=admin,${ldap_suffix}"
ldap_admin_pw="secret"
ldap_bind9_dn="uid=bind9,${ldap_suffix}"
+ldap_bind9_rdn="uid: bind9" # match ldap_bind9_dn
ldap_bind9_pw="secretagain"
cleanup() {
@@ -122,7 +123,7 @@ EOF
create_bind9_uid() {
ldapadd -x -D "${ldap_admin_dn}" -w "${ldap_admin_pw}" <https://salsa.debian.org/freeipa-
team/bind-dyndb-ldap/-/commit/6b5096776ee0502d9cac3966b6aa5f4da4cef664
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2034251/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 2034250] [NEW] Insufficient access in dyndb DEP8 test
Public bug reported:
Caught this in a run of the dyndb-ldap DEP8 test:
280s 2023-09-05T00:59:05.435102+00:00 autopkgtest slapd[1491]: conn=1010 op=1
MOD dn="idnsName=example.internal,ou=dns,dc=example,dc=internal"
280s 2023-09-05T00:59:05.435953+00:00 autopkgtest slapd[1491]: conn=1010 op=1
MOD attr=idnsSOAserial
280s 2023-09-05T00:59:05.436043+00:00 autopkgtest slapd[1491]: conn=1010 op=1
RESULT tag=103 err=50 qtime=0.09 etime=0.001324 text=
280s 2023-09-05T00:59:05.436068+00:00 autopkgtest named[1519]: LDAP error:
Insufficient access: while modifying(replace) entry
'idnsName=example.internal,ou=dns,dc=example,dc=internal'
Looks like sometimes the dyndb-ldap plugin wants to write to the tree,
and not just read from it. Looking at the code, that can happen for some
SOA attributes, and perhaps other cases too. The documentation isn't
immediately clear.
A re-run of this test cleared the error, but we all dislike flaky tests,
so it's probably best to adjust the ACL and allow the bind9 user to
write to the DNS tree. Production deployments will definitely want to
fine tune this ACL and list explicit attribites and entry types that can
be modified, but for a DEP8 test, this is enough.
```diff
--- a/debian/tests/dyndb-ldap
+++ b/debian/tests/dyndb-ldap
@@ -135,7 +135,7 @@ EOF
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
-olcAccess: {1}to dn.subtree="ou=dns,${ldap_suffix}" by
dn.exact="${ldap_bind9_dn}" read by * none
+olcAccess: {1}to dn.subtree="ou=dns,${ldap_suffix}" by
dn.exact="${ldap_bind9_dn}" write by * none
EOF
}
```
** Affects: bind-dyndb-ldap (Ubuntu)
Importance: Undecided
Assignee: Andreas Hasenack (ahasenack)
Status: In Progress
** Affects: bind9 (Ubuntu)
Importance: Undecided
Assignee: Andreas Hasenack (ahasenack)
Status: In Progress
** Also affects: bind9 (Ubuntu)
Importance: Undecided
Status: New
** Changed in: bind9 (Ubuntu)
Status: New => In Progress
** Changed in: bind9 (Ubuntu)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to bind-dyndb-ldap in Ubuntu.
https://bugs.launchpad.net/bugs/2034250
Title:
Insufficient access in dyndb DEP8 test
Status in bind-dyndb-ldap package in Ubuntu:
In Progress
Status in bind9 package in Ubuntu:
In Progress
Bug description:
Caught this in a run of the dyndb-ldap DEP8 test:
280s 2023-09-05T00:59:05.435102+00:00 autopkgtest slapd[1491]: conn=1010 op=1
MOD dn="idnsName=example.internal,ou=dns,dc=example,dc=internal"
280s 2023-09-05T00:59:05.435953+00:00 autopkgtest slapd[1491]: conn=1010 op=1
MOD attr=idnsSOAserial
280s 2023-09-05T00:59:05.436043+00:00 autopkgtest slapd[1491]: conn=1010 op=1
RESULT tag=103 err=50 qtime=0.09 etime=0.001324 text=
280s 2023-09-05T00:59:05.436068+00:00 autopkgtest named[1519]: LDAP error:
Insufficient access: while modifying(replace) entry
'idnsName=example.internal,ou=dns,dc=example,dc=internal'
Looks like sometimes the dyndb-ldap plugin wants to write to the tree,
and not just read from it. Looking at the code, that can happen for
some SOA attributes, and perhaps other cases too. The documentation
isn't immediately clear.
A re-run of this test cleared the error, but we all dislike flaky
tests, so it's probably best to adjust the ACL and allow the bind9
user to write to the DNS tree. Production deployments will definitely
want to fine tune this ACL and list explicit attribites and entry
types that can be modified, but for a DEP8 test, this is enough.
```diff
--- a/debian/tests/dyndb-ldap
+++ b/debian/tests/dyndb-ldap
@@ -135,7 +135,7 @@ EOF
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
-olcAccess: {1}to dn.subtree="ou=dns,${ldap_suffix}" by
dn.exact="${ldap_bind9_dn}" read by * none
+olcAccess: {1}to dn.subtree="ou=dns,${ldap_suffix}" by
dn.exact="${ldap_bind9_dn}" write by * none
EOF
}
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2034250/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 2032650] Re: Add DEP8 tests for bind-dyndb-ldap integration
** Tags added: block-proposed-jammy block-proposed-lunar -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/2032650 Title: Add DEP8 tests for bind-dyndb-ldap integration Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Fix Released Status in bind-dyndb-ldap source package in Jammy: In Progress Status in bind9 source package in Jammy: New Status in bind-dyndb-ldap source package in Lunar: In Progress Status in bind9 source package in Lunar: New Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Fix Released Bug description: bind-dyndb-ldap breaks very frequently with bind9 updates. Both must have DEP8 tests so these breakages can be caught before a release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2032650/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1978849] Re: bind9-dyndb-ldap has unmet dependencies
The focal situation explained in the last comments above is still more complicated than originally thought. Looks like bind-dyndb-ldap never really worked in focal. Some options: a) fire up gdb, and see where exactly it's failing. It could be a symbol clash, an incorrect library being linked in, just incompatible code, or something else; b) backport a new bind-dyndb-ldap version what works with bind9 9.16.x as shipped in focal. The problem is that src:bind9 in focal does not provide a dev package, so where are no header files nor development libraries to link with. A new binary package built from src:bind9 in focal would have to be created, like bin:bind9-dev that exists in jammy and later. Given the above, and the fact that there is another LTS where bind- dyndb-ldap works (after this update here in the bug), we think it's not worth it to attempt to fix bind-dyndb-ldap for focal. If the situation changes (perhaps a patch becomes available, or another solution different from (a) and (b) above, or there is a strong demand to have this fixed in focal), then this can be re-evaluated. ** Changed in: bind-dyndb-ldap (Ubuntu Focal) Status: New => Won't Fix -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/1978849 Title: bind9-dyndb-ldap has unmet dependencies Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Invalid Status in bind-dyndb-ldap source package in Focal: Won't Fix Status in bind-dyndb-ldap source package in Jammy: In Progress Status in bind-dyndb-ldap source package in Lunar: In Progress Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Invalid Bug description: bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap: ~# apt install bind9 bind9-dyndb-ldap Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed E: Unable to correct problems, you have held broken packages. ~# apt-cache policy bind9 bind9: Installed: (none) Candidate: 1:9.18.1-1ubuntu1.1 Version table: 1:9.18.1-1ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 1:9.18.1-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages ~# apt-cache policy bind9-dyndb-ldap bind9-dyndb-ldap: Installed: (none) Candidate: 11.9-5build2 Version table: 11.9-5build2 500 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/1978849/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1978849] Re: bind9-dyndb-ldap has unmet dependencies
So in focal we get this missing symbol: 04-Sep-2023 14:33:22.532 failed to dynamically load instance 'ldap_zone' driver '/usr/lib/bind/ldap.so': /usr/lib/bind/ldap.so: undefined symbol: cfg_parse_buffer2 (failure) That comes from the libisccfg library. If I link with it, however, we get: 04-Sep-2023 14:34:10.260 loading DynDB instance 'ldap_zone' driver '/usr/lib/bind/ldap.so' 04-Sep-2023 14:34:10.269 registering library from dynamic ldap driver, 0x7f88631220d0 != 0x7f884600b010. 04-Sep-2023 14:34:10.269 registering dynamic ldap driver for ldap_zone. 04-Sep-2023 14:34:10.264 mem.c:731: fatal error: 04-Sep-2023 14:34:10.264 malloc failed: Cannot allocate memory 04-Sep-2023 14:34:10.264 exiting (due to fatal error in library) -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/1978849 Title: bind9-dyndb-ldap has unmet dependencies Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Invalid Status in bind-dyndb-ldap source package in Focal: New Status in bind-dyndb-ldap source package in Jammy: In Progress Status in bind-dyndb-ldap source package in Lunar: In Progress Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Invalid Bug description: bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap: ~# apt install bind9 bind9-dyndb-ldap Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed E: Unable to correct problems, you have held broken packages. ~# apt-cache policy bind9 bind9: Installed: (none) Candidate: 1:9.18.1-1ubuntu1.1 Version table: 1:9.18.1-1ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 1:9.18.1-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages ~# apt-cache policy bind9-dyndb-ldap bind9-dyndb-ldap: Installed: (none) Candidate: 11.9-5build2 Version table: 11.9-5build2 500 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/1978849/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1978849] Re: bind9-dyndb-ldap has unmet dependencies
** Changed in: bind-dyndb-ldap (Ubuntu Lunar) Status: New => In Progress ** Changed in: bind-dyndb-ldap (Ubuntu Jammy) Status: New => In Progress ** Changed in: bind-dyndb-ldap (Ubuntu Lunar) Importance: Undecided => High ** Changed in: bind-dyndb-ldap (Ubuntu Jammy) Importance: Undecided => High -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/1978849 Title: bind9-dyndb-ldap has unmet dependencies Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Invalid Status in bind-dyndb-ldap source package in Focal: New Status in bind-dyndb-ldap source package in Jammy: In Progress Status in bind-dyndb-ldap source package in Lunar: In Progress Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Invalid Bug description: bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap: ~# apt install bind9 bind9-dyndb-ldap Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed E: Unable to correct problems, you have held broken packages. ~# apt-cache policy bind9 bind9: Installed: (none) Candidate: 1:9.18.1-1ubuntu1.1 Version table: 1:9.18.1-1ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 1:9.18.1-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages ~# apt-cache policy bind9-dyndb-ldap bind9-dyndb-ldap: Installed: (none) Candidate: 11.9-5build2 Version table: 11.9-5build2 500 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/1978849/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1978849] Re: bind9-dyndb-ldap has unmet dependencies
Fixed in mantic with the rebuild in https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.10-6build1 ** Changed in: bind-dyndb-ldap (Ubuntu Mantic) Status: In Progress => Fix Released ** Also affects: bind9 (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: bind-dyndb-ldap (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: bind9 (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: bind-dyndb-ldap (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: bind9 (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: bind-dyndb-ldap (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: bind-dyndb-ldap (Ubuntu Focal) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** Changed in: bind-dyndb-ldap (Ubuntu Jammy) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** Changed in: bind-dyndb-ldap (Ubuntu Lunar) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** No longer affects: bind9 (Ubuntu Lunar) ** No longer affects: bind9 (Ubuntu Focal) ** No longer affects: bind9 (Ubuntu Jammy) -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/1978849 Title: bind9-dyndb-ldap has unmet dependencies Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Invalid Status in bind-dyndb-ldap source package in Focal: New Status in bind-dyndb-ldap source package in Jammy: New Status in bind-dyndb-ldap source package in Lunar: New Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Invalid Bug description: bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap: ~# apt install bind9 bind9-dyndb-ldap Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed E: Unable to correct problems, you have held broken packages. ~# apt-cache policy bind9 bind9: Installed: (none) Candidate: 1:9.18.1-1ubuntu1.1 Version table: 1:9.18.1-1ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 1:9.18.1-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages ~# apt-cache policy bind9-dyndb-ldap bind9-dyndb-ldap: Installed: (none) Candidate: 11.9-5build2 Version table: 11.9-5build2 500 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/1978849/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1978849] Re: bind9-dyndb-ldap has unmet dependencies
Given that the soname in bind9-libs is an exact copy of the package version, including the ubuntu suffix, it will change with even a no- change rebuild: $ objdump -x usr/lib/x86_64-linux-gnu/libbind9-9.18.12-0ubuntu0.22.04.3~local1-Ubuntu.so | grep SONAME SONAME libbind9-9.18.12-0ubuntu0.22.04.3~local1-Ubuntu.so Note the "~local1" I added for a local rebuild. That means that even if I force an install of bind9-dyndb-ldap to ignore the Depends line, as if I had relaxed the Depends version, it will still search for the exact bind9 soname it was built with and fail: $ ldd /usr/lib/bind/ldap.so|grep "not found" libdns-9.18.12-0ubuntu0.22.04.1-Ubuntu.so => not found libisc-9.18.12-0ubuntu0.22.04.1-Ubuntu.so => not found Therefore, the "fix" for this bug for now is to rebuild bind-dyndb-ldap everytime bind9 is updated :/ The added DEP8 test will block migration until that is done. There were some discussions in debian, where this situation is also happening, in bug https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=1014503 and others. One option was to move[2] src:bind-dyndb-ldap into src:bind9 itself, so they get built together, but there are licenses incompatibilities. Timo asked[1] src:bind-dyndb- ldap upstream if they could change the license. 1. https://pagure.io/bind-dyndb-ldap/issue/225 2. https://salsa.debian.org/dns-team/bind9/-/merge_requests/21#note_389188 ** Bug watch added: Debian Bug tracker #1014503 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/1978849 Title: bind9-dyndb-ldap has unmet dependencies Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Invalid Status in bind-dyndb-ldap source package in Focal: New Status in bind-dyndb-ldap source package in Jammy: New Status in bind-dyndb-ldap source package in Lunar: New Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Invalid Bug description: bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap: ~# apt install bind9 bind9-dyndb-ldap Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed E: Unable to correct problems, you have held broken packages. ~# apt-cache policy bind9 bind9: Installed: (none) Candidate: 1:9.18.1-1ubuntu1.1 Version table: 1:9.18.1-1ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 1:9.18.1-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages ~# apt-cache policy bind9-dyndb-ldap bind9-dyndb-ldap: Installed: (none) Candidate: 11.9-5build2 Version table: 11.9-5build2 500 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/1978849/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1978849] Re: bind9-dyndb-ldap has unmet dependencies
There is nothing to do in the bind9 package, so marking that task as invalid. The DEP8 test was added to bind in a separate bug (#2032650). ** Changed in: bind9 (Ubuntu Mantic) Status: In Progress => Invalid -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/1978849 Title: bind9-dyndb-ldap has unmet dependencies Status in bind-dyndb-ldap package in Ubuntu: In Progress Status in bind9 package in Ubuntu: Invalid Status in bind-dyndb-ldap source package in Mantic: In Progress Status in bind9 source package in Mantic: Invalid Bug description: bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap: ~# apt install bind9 bind9-dyndb-ldap Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed E: Unable to correct problems, you have held broken packages. ~# apt-cache policy bind9 bind9: Installed: (none) Candidate: 1:9.18.1-1ubuntu1.1 Version table: 1:9.18.1-1ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 1:9.18.1-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages ~# apt-cache policy bind9-dyndb-ldap bind9-dyndb-ldap: Installed: (none) Candidate: 11.9-5build2 Version table: 11.9-5build2 500 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/1978849/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1978849] Re: bind9-dyndb-ldap has unmet dependencies
Summary: # focal focal's src:bind-dyndb-ldap situation is more complicated, a simple rebuild won't fix it. In focal we have two bind9 sources: src:bind9-libs, and src:bind9, at very different versions. Focal's bind- dyndb-ldap does not work with the version of src:bind9 shipped there, hence src:bind9-libs being available at a lower version. This allows src:bind-dyndb-ldap to build, but it doesn't load correctly into bind9's server at runtime. I don't even know if it can be made to work. TBD # jammy and later A simple rebuild fixes it. I checked if we can relax the bind9-libs dependency, but even if we could, it won't help: src:bind9 in jammy and later produces very specific libraries, with the full ubuntu version in their soname: $ objdump -x /lib/x86_64-linux-gnu/libisc-9.18.12-0ubuntu0.22.04.2-Ubuntu.so | grep SONAME SONAME libisc-9.18.12-0ubuntu0.22.04.2-Ubuntu.so So even a simple no-change rebuild of src:bind9 in these releases will change the soname, and will require a src:bind-dyndb-ldap rebuild to link with the new one. The plan for jammy and later, therefore, is to add a dep8 test to these packages (src:bind-dyndb-ldap and src:bind9) which will load the ldap.so module into bind. This will block a src:bind9 update without an accompaining src:bind-dyndb-ldap update, because the test will fail without a rebuild. This is a bit awkward: a package in universe can now block the release of a critical package like bind9 (if the test fails). If we ever get into a situation where a bind9-dyndb-ldap bug (where just a rebuild is not enough to get the test to pass) blocks a critical bind9 update, we will have to override the test. -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/1978849 Title: bind9-dyndb-ldap has unmet dependencies Status in bind-dyndb-ldap package in Ubuntu: In Progress Status in bind9 package in Ubuntu: In Progress Status in bind-dyndb-ldap source package in Mantic: In Progress Status in bind9 source package in Mantic: In Progress Bug description: bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap: ~# apt install bind9 bind9-dyndb-ldap Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed E: Unable to correct problems, you have held broken packages. ~# apt-cache policy bind9 bind9: Installed: (none) Candidate: 1:9.18.1-1ubuntu1.1 Version table: 1:9.18.1-1ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 1:9.18.1-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages ~# apt-cache policy bind9-dyndb-ldap bind9-dyndb-ldap: Installed: (none) Candidate: 11.9-5build2 Version table: 11.9-5build2 500 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/1978849/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 2032650] Re: Add DEP8 tests for bind-dyndb-ldap integration
** Also affects: bind9 (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: bind-dyndb-ldap (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: bind9 (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: bind-dyndb-ldap (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: bind-dyndb-ldap (Ubuntu Lunar) Status: New => In Progress ** Changed in: bind-dyndb-ldap (Ubuntu Jammy) Status: New => In Progress ** Changed in: bind-dyndb-ldap (Ubuntu Jammy) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** Changed in: bind-dyndb-ldap (Ubuntu Lunar) Assignee: (unassigned) => Andreas Hasenack (ahasenack) -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/2032650 Title: Add DEP8 tests for bind-dyndb-ldap integration Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Fix Released Status in bind-dyndb-ldap source package in Jammy: In Progress Status in bind9 source package in Jammy: New Status in bind-dyndb-ldap source package in Lunar: In Progress Status in bind9 source package in Lunar: New Status in bind-dyndb-ldap source package in Mantic: Fix Released Status in bind9 source package in Mantic: Fix Released Bug description: bind-dyndb-ldap breaks very frequently with bind9 updates. Both must have DEP8 tests so these breakages can be caught before a release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2032650/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 2003586] Re: MRE Updates 9.18.12 / 9.16.39
I verified the test results for bind-dyndb-ldap and am satisfied that they show the executed planned test case, and that the results are correct. I noticed that this upload happens to (very probably) also fix bug #1978849, which was missed in the changelog/changes file. I added a comment to the bug asking for verification from the reporters. The package built correctly in all architectures and Ubuntu releases it was meant for. This package does not have DEP8 tests (yet: they are coming!) There is no SRU freeze ongoing at the moment. There is no halted phasing on the previous update. -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/2003586 Title: MRE Updates 9.18.12 / 9.16.39 Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Fix Released Status in bind9 source package in Focal: In Progress Status in bind-dyndb-ldap source package in Jammy: Fix Released Status in bind9 source package in Jammy: Fix Released Status in bind-dyndb-ldap source package in Kinetic: Fix Released Status in bind9 source package in Kinetic: Fix Released Bug description: This bug tracks an update for the bind9 package, moving to versions: * Kinetic (22.10): bind9 9.18.12 * Jammy (22.04): bind9 9.18.12 * Focal (20.04): bind9 9.16.39 These updates include bug fixes following the SRU policy exception defined at https://wiki.ubuntu.com/Bind9Updates. [Upstream changes] For bind9 9.18.2-9.18.12, major changes include: CVE fixes (These already existed as patches but are now included as part of upstream): CVE-2022-1183 CVE-2022-2795 CVE-2022-2881 CVE-2022-2906 CVE-2022-3080 CVE-2022-38178 CVE-2022-3094 CVE-2022-3736 CVE-2022-3924 Features: update-quota option named -V shows supported cryptographic algorithms Additional info given for recursion not available and query (cache) '...' denied outputs Jammy only (Kinetic already has these): Catalog Zones schema version 2 support in named DNS error support Stale Answer and Stale NXDOMAIN Answer remote TLS certificate verification support reusereport option Bug Fixes: https://gitlab.isc.org/isc-projects/bind9/-/issues/3178 https://gitlab.isc.org/isc-projects/bind9/-/issues/3636 https://gitlab.isc.org/isc-projects/bind9/-/issues/3772 https://gitlab.isc.org/isc-projects/bind9/-/issues/3752 https://gitlab.isc.org/isc-projects/bind9/-/issues/3678 https://gitlab.isc.org/isc-projects/bind9/-/issues/3637 https://gitlab.isc.org/isc-projects/bind9/-/issues/3739 https://gitlab.isc.org/isc-projects/bind9/-/issues/3743 https://gitlab.isc.org/isc-projects/bind9/-/issues/3725 https://gitlab.isc.org/isc-projects/bind9/-/issues/3693 https://gitlab.isc.org/isc-projects/bind9/-/issues/3683 https://gitlab.isc.org/isc-projects/bind9/-/issues/3727 https://gitlab.isc.org/isc-projects/bind9/-/issues/3638 https://gitlab.isc.org/isc-projects/bind9/-/issues/3183 https://gitlab.isc.org/isc-projects/bind9/-/issues/3721 https://gitlab.isc.org/isc-projects/bind9/-/issues/3707 https://gitlab.isc.org/isc-projects/bind9/-/issues/3591 https://gitlab.isc.org/isc-projects/bind9/-/issues/3598 https://gitlab.isc.org/isc-projects/bind9/-/issues/3247 https://gitlab.isc.org/isc-projects/bind9/-/issues/2895 https://gitlab.isc.org/isc-projects/bind9/-/issues/3584 https://gitlab.isc.org/isc-projects/bind9/-/issues/3627 https://gitlab.isc.org/isc-projects/bind9/-/issues/3563 https://gitlab.isc.org/isc-projects/bind9/-/issues/3603 https://gitlab.isc.org/isc-projects/bind9/-/issues/3542 https://gitlab.isc.org/isc-projects/bind9/-/issues/3557 https://gitlab.isc.org/isc-projects/bind9/-/issues/2982 https://gitlab.isc.org/isc-projects/bind9/-/issues/3439 https://gitlab.isc.org/isc-projects/bind9/-/issues/3438 https://gitlab.isc.org/isc-projects/bind9/-/issues/2918 https://gitlab.isc.org/isc-projects/bind9/-/issues/3462 https://gitlab.isc.org/isc-projects/bind9/-/issues/3400 https://gitlab.isc.org/isc-projects/bind9/-/issues/3402 https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 https://gitlab.isc.org/isc-projects/bind9/-/issues/3415 https://gitlab.isc.org/isc-projects/bind9/-/issues/2506 Jammy only: https://gitlab.isc.org/isc-projects/bind9/-/issues/3327 https://gitlab.isc.org/isc-projects/bind9/-/issues/3380 https://gitlab.isc.org/isc-projects/bind9/-/issues/3302 https://gitlab.isc.org/isc-projects/bind9/-/issues/2931 https://gitlab.isc.org/isc-projects/bind9/-/issues/3242 https://gitlab.isc.org/isc-projects/bind9/-/issues/3020 https://gitlab.isc.org/isc-projects/bind9/-/issues/3128 https://gitlab.isc.org/isc-projects/bind9/-/issues/3145 https://gitlab.isc.org/isc-projects/bind9/-/issues/3184 https://gitlab.isc.org/isc-projects/bind9/-/issues/3205 https://gitlab.isc.org/isc-projects/bind9/-/issues/3244
[Freeipa] [Bug 1978849] Re: bind9-dyndb-ldap has unmet dependencies
This is being fixed in bug #2003586, and the package is already in proposed: https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.9-5ubuntu0.22.04.1 https://launchpad.net/ubuntu/+source/bind-dyndb-ldap/11.10-1ubuntu0.22.10.1 Unfortunately the changes file doesn't list this bug, so it won't be auto-closed once it hits updates (which I'm working on right now). Please, if you can test the package when it's in updates (or proposed right now), add a comment here. -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/1978849 Title: bind9-dyndb-ldap has unmet dependencies Status in bind-dyndb-ldap package in Ubuntu: Confirmed Bug description: bind9-dyndb-ldap cannot be installed on Ubuntu 22.04. It appears the bind0 package has been updated, but not bind9-dyndb-ldap: ~# apt install bind9 bind9-dyndb-ldap Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: bind9-dyndb-ldap : Depends: bind9-libs (= 1:9.18.1-1ubuntu1) but 1:9.18.1-1ubuntu1.1 is to be installed E: Unable to correct problems, you have held broken packages. ~# apt-cache policy bind9 bind9: Installed: (none) Candidate: 1:9.18.1-1ubuntu1.1 Version table: 1:9.18.1-1ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages 1:9.18.1-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages ~# apt-cache policy bind9-dyndb-ldap bind9-dyndb-ldap: Installed: (none) Candidate: 11.9-5build2 Version table: 11.9-5build2 500 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/1978849/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 2003586] Re: MRE Updates 9.18.12 / 9.16.39
I flipped the tags back to verification-needed, but this applies to bind-dyndb-ldap, not bind (which was already released for jammy and kinetic even). ** Tags removed: verification-done-jammy verification-done-kinetic ** Tags added: verification-needed-jammy verification-needed-kinetic -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/2003586 Title: MRE Updates 9.18.12 / 9.16.39 Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Fix Released Status in bind9 source package in Focal: In Progress Status in bind-dyndb-ldap source package in Jammy: Fix Committed Status in bind9 source package in Jammy: Fix Released Status in bind-dyndb-ldap source package in Kinetic: Fix Committed Status in bind9 source package in Kinetic: Fix Released Bug description: This bug tracks an update for the bind9 package, moving to versions: * Kinetic (22.10): bind9 9.18.12 * Jammy (22.04): bind9 9.18.12 * Focal (20.04): bind9 9.16.39 These updates include bug fixes following the SRU policy exception defined at https://wiki.ubuntu.com/Bind9Updates. [Upstream changes] For bind9 9.18.2-9.18.12, major changes include: CVE fixes (These already existed as patches but are now included as part of upstream): CVE-2022-1183 CVE-2022-2795 CVE-2022-2881 CVE-2022-2906 CVE-2022-3080 CVE-2022-38178 CVE-2022-3094 CVE-2022-3736 CVE-2022-3924 Features: update-quota option named -V shows supported cryptographic algorithms Additional info given for recursion not available and query (cache) '...' denied outputs Jammy only (Kinetic already has these): Catalog Zones schema version 2 support in named DNS error support Stale Answer and Stale NXDOMAIN Answer remote TLS certificate verification support reusereport option Bug Fixes: https://gitlab.isc.org/isc-projects/bind9/-/issues/3178 https://gitlab.isc.org/isc-projects/bind9/-/issues/3636 https://gitlab.isc.org/isc-projects/bind9/-/issues/3772 https://gitlab.isc.org/isc-projects/bind9/-/issues/3752 https://gitlab.isc.org/isc-projects/bind9/-/issues/3678 https://gitlab.isc.org/isc-projects/bind9/-/issues/3637 https://gitlab.isc.org/isc-projects/bind9/-/issues/3739 https://gitlab.isc.org/isc-projects/bind9/-/issues/3743 https://gitlab.isc.org/isc-projects/bind9/-/issues/3725 https://gitlab.isc.org/isc-projects/bind9/-/issues/3693 https://gitlab.isc.org/isc-projects/bind9/-/issues/3683 https://gitlab.isc.org/isc-projects/bind9/-/issues/3727 https://gitlab.isc.org/isc-projects/bind9/-/issues/3638 https://gitlab.isc.org/isc-projects/bind9/-/issues/3183 https://gitlab.isc.org/isc-projects/bind9/-/issues/3721 https://gitlab.isc.org/isc-projects/bind9/-/issues/3707 https://gitlab.isc.org/isc-projects/bind9/-/issues/3591 https://gitlab.isc.org/isc-projects/bind9/-/issues/3598 https://gitlab.isc.org/isc-projects/bind9/-/issues/3247 https://gitlab.isc.org/isc-projects/bind9/-/issues/2895 https://gitlab.isc.org/isc-projects/bind9/-/issues/3584 https://gitlab.isc.org/isc-projects/bind9/-/issues/3627 https://gitlab.isc.org/isc-projects/bind9/-/issues/3563 https://gitlab.isc.org/isc-projects/bind9/-/issues/3603 https://gitlab.isc.org/isc-projects/bind9/-/issues/3542 https://gitlab.isc.org/isc-projects/bind9/-/issues/3557 https://gitlab.isc.org/isc-projects/bind9/-/issues/2982 https://gitlab.isc.org/isc-projects/bind9/-/issues/3439 https://gitlab.isc.org/isc-projects/bind9/-/issues/3438 https://gitlab.isc.org/isc-projects/bind9/-/issues/2918 https://gitlab.isc.org/isc-projects/bind9/-/issues/3462 https://gitlab.isc.org/isc-projects/bind9/-/issues/3400 https://gitlab.isc.org/isc-projects/bind9/-/issues/3402 https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 https://gitlab.isc.org/isc-projects/bind9/-/issues/3415 https://gitlab.isc.org/isc-projects/bind9/-/issues/2506 Jammy only: https://gitlab.isc.org/isc-projects/bind9/-/issues/3327 https://gitlab.isc.org/isc-projects/bind9/-/issues/3380 https://gitlab.isc.org/isc-projects/bind9/-/issues/3302 https://gitlab.isc.org/isc-projects/bind9/-/issues/2931 https://gitlab.isc.org/isc-projects/bind9/-/issues/3242 https://gitlab.isc.org/isc-projects/bind9/-/issues/3020 https://gitlab.isc.org/isc-projects/bind9/-/issues/3128 https://gitlab.isc.org/isc-projects/bind9/-/issues/3145 https://gitlab.isc.org/isc-projects/bind9/-/issues/3184 https://gitlab.isc.org/isc-projects/bind9/-/issues/3205 https://gitlab.isc.org/isc-projects/bind9/-/issues/3244 https://gitlab.isc.org/isc-projects/bind9/-/issues/3248 https://gitlab.isc.org/isc-projects/bind9/-/issues/3142 https://gitlab.isc.org/isc-projects/bind9/-/issues/3200 This will also fix bugs LP: #1258003, LP: #1970252, and LP: #2006972 Full release notes for versions 9.18.2-9.18.12:
[Freeipa] [Bug 2003586] Re: MRE Updates 9.18.12 / 9.16.39
Hi all, what's the test plan for bind-dyndb-ldap? It's not in the bug description. From a few comments, I see that it was just an install test? That's a bit superficial, specially given the amount of patches that it got. There are also no DEP8 tests, nor build-time tests. I think we need a test run to show that bind can actually start with this plugin loaded. Not just a simple installation test, which is just about dependencies. Just installing the bind9-dyndb-ldap package doesn't cause bind9 to load the module. There could be unresolved symbols or even crashes at load time which we wouldn't know about if we just install the package. I suggest to follow this guide: https://wiki.debian.org/LDAP/OpenLDAPSetup#DNS.2FBind9 It relies on the schema and example ldif files shipped with the package, which, incidentally, don't work out of the box with openldap. This being a Redhat project, these files are customized for their LDAP server (389, purchased years ago from Netscape). That debian wiki has some "sed"s to adjust the config for openldap. It still needs some tiny changes for ubuntu, though: - admin dn is cn=admin,dc=example,dc=com (and not uid=admin,...) - the named apparmor profile needs to allow connecting to the ldapi:/// (or just switch to ldap://) - I'd suggest to use example.fake instead of example.com, because there is a real example.com, but that's minor This can even become a DEP8 test (hint!) -- You received this bug notification because you are a member of FreeIPA, which is subscribed to bind-dyndb-ldap in Ubuntu. https://bugs.launchpad.net/bugs/2003586 Title: MRE Updates 9.18.12 / 9.16.39 Status in bind-dyndb-ldap package in Ubuntu: Fix Released Status in bind9 package in Ubuntu: Fix Released Status in bind9 source package in Focal: In Progress Status in bind-dyndb-ldap source package in Jammy: Fix Committed Status in bind9 source package in Jammy: Fix Released Status in bind-dyndb-ldap source package in Kinetic: Fix Committed Status in bind9 source package in Kinetic: Fix Released Bug description: This bug tracks an update for the bind9 package, moving to versions: * Kinetic (22.10): bind9 9.18.12 * Jammy (22.04): bind9 9.18.12 * Focal (20.04): bind9 9.16.39 These updates include bug fixes following the SRU policy exception defined at https://wiki.ubuntu.com/Bind9Updates. [Upstream changes] For bind9 9.18.2-9.18.12, major changes include: CVE fixes (These already existed as patches but are now included as part of upstream): CVE-2022-1183 CVE-2022-2795 CVE-2022-2881 CVE-2022-2906 CVE-2022-3080 CVE-2022-38178 CVE-2022-3094 CVE-2022-3736 CVE-2022-3924 Features: update-quota option named -V shows supported cryptographic algorithms Additional info given for recursion not available and query (cache) '...' denied outputs Jammy only (Kinetic already has these): Catalog Zones schema version 2 support in named DNS error support Stale Answer and Stale NXDOMAIN Answer remote TLS certificate verification support reusereport option Bug Fixes: https://gitlab.isc.org/isc-projects/bind9/-/issues/3178 https://gitlab.isc.org/isc-projects/bind9/-/issues/3636 https://gitlab.isc.org/isc-projects/bind9/-/issues/3772 https://gitlab.isc.org/isc-projects/bind9/-/issues/3752 https://gitlab.isc.org/isc-projects/bind9/-/issues/3678 https://gitlab.isc.org/isc-projects/bind9/-/issues/3637 https://gitlab.isc.org/isc-projects/bind9/-/issues/3739 https://gitlab.isc.org/isc-projects/bind9/-/issues/3743 https://gitlab.isc.org/isc-projects/bind9/-/issues/3725 https://gitlab.isc.org/isc-projects/bind9/-/issues/3693 https://gitlab.isc.org/isc-projects/bind9/-/issues/3683 https://gitlab.isc.org/isc-projects/bind9/-/issues/3727 https://gitlab.isc.org/isc-projects/bind9/-/issues/3638 https://gitlab.isc.org/isc-projects/bind9/-/issues/3183 https://gitlab.isc.org/isc-projects/bind9/-/issues/3721 https://gitlab.isc.org/isc-projects/bind9/-/issues/3707 https://gitlab.isc.org/isc-projects/bind9/-/issues/3591 https://gitlab.isc.org/isc-projects/bind9/-/issues/3598 https://gitlab.isc.org/isc-projects/bind9/-/issues/3247 https://gitlab.isc.org/isc-projects/bind9/-/issues/2895 https://gitlab.isc.org/isc-projects/bind9/-/issues/3584 https://gitlab.isc.org/isc-projects/bind9/-/issues/3627 https://gitlab.isc.org/isc-projects/bind9/-/issues/3563 https://gitlab.isc.org/isc-projects/bind9/-/issues/3603 https://gitlab.isc.org/isc-projects/bind9/-/issues/3542 https://gitlab.isc.org/isc-projects/bind9/-/issues/3557 https://gitlab.isc.org/isc-projects/bind9/-/issues/2982 https://gitlab.isc.org/isc-projects/bind9/-/issues/3439 https://gitlab.isc.org/isc-projects/bind9/-/issues/3438 https://gitlab.isc.org/isc-projects/bind9/-/issues/2918 https://gitlab.isc.org/isc-projects/bind9/-/issues/3462 https://gitlab.isc.org/isc-projects/bind9/-/issues/3400
[Freeipa] [Bug 1733571] Re: unable to access kerberized nfs4 shares with keyring ccache
Confirmed in bionic. This seems to be a known issue and needs further
investigation to see if it was fixed upstream of if there is a
workaround available. maybe via gss-proxy? Have to check.
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1733571
Title:
unable to access kerberized nfs4 shares with keyring ccache
Status in freeipa package in Ubuntu:
Confirmed
Status in nfs-utils package in Ubuntu:
Confirmed
Bug description:
# Problem
With default `ipa-client-install` method, users authenticated to
kerberos cannot access kerberized nfs shares from other ipa joined
ubuntu hosts, even though permissions are correct.
# Steps to reproduce
1. Set up FreeIPA server on CentOS 7 per default docs
2. Set up two Ubuntu 16.04 hosts, one `server.domain.tld` one
`client.domain.tld`, join both to FreeIPA
3. Create principals `nfs/server.domain.tld` and `nfs/client.domain.tld`
4. Create user in FreeIPA `testuser`
5. Install `nfs-kernel-server` on `server.domain.tld` and share `/srv/nfs4`:
`/srv/nfs4 *(sec=krb5i,rw,fsid=root,crossmnt,no_subtree_check,root_squash)`,
run `exportfs -rav`
6. Create some files and directories in `/srv/nfs4` owned by
`testuser:testuser`
7. Install `nfs-common` on `client.domain.tld` and mount: `mount -t nfs4
server.domain.tld:/ /srv/nfs4`
8. Log in as `testuser` and `kinit testuser` if necessary
9. `cd /srv/nfs4; ls /srv/nfs4; touch /srv/nfs4/some_file`
# Expected result
Changing of working directory to `/srv/nfs4`, listing directory
contents and creating new file
# Actual result
`Permission denied`
# Reason
After quite some time debugging I found that `gssd` in Ubuntu 16.04
cannot read kernel persistent keyrings for kerberos' ccache. Removing
the line `default_ccache_name = KEYRING:persistent:%{uid}` from
`/etc/krb5.conf` solved the issue.
This config file is created by `ipa-client-install` in
`configure_krb5_conf()` after `#configure KEYRING CCACHE if
supported`.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: freeipa-client 4.3.1-0ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-101.124-generic 4.4.95
Uname: Linux 4.4.0-101-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.12
Architecture: amd64
Date: Tue Nov 21 12:41:59 2017
JournalErrors:
Error: command ['journalctl', '-b', '--priority=warning', '--lines=1000']
failed with exit code 1: Hint: You are currently not seeing messages from other
users and the system.
Users in the 'systemd-journal' group can see all messages. Pass -q to
turn off this notice.
No journal files were opened due to insufficient permissions.
SourcePackage: freeipa
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/1733571/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1769440] Re: freeipa server install fails - named-pkcs11 fails to run
Uploaded to bionic unapproved, waiting for SRU team's approval.
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1769440
Title:
freeipa server install fails - named-pkcs11 fails to run
Status in bind9 package in Ubuntu:
Fix Released
Status in freeipa package in Ubuntu:
Invalid
Status in bind9 source package in Bionic:
In Progress
Bug description:
[Impact]
Using RTLD_DEEPBIND in bind9 causes the FreeIPA serve install to fail.
This patch, also applied in fedora and debian, disables use of RTLD_DEEPBIND.
https://src.fedoraproject.org/rpms/bind/c/3d5ea105bd877f0069452e450320f8877b01cb52?branch=master
https://salsa.debian.org/dns-team/bind9/commit/afc6b5fe2e359e4e7eadc256cd94481965418b4b
[Test Case]
# uvt-kvm create --memory 2048 cosmic-freeipa release=cosmic label=daily
# uvt-kvm wait cosmic-freeipa
# uvt-kvm ssh cosmic-freeipa
Inside vm:
# sudo su
# apt purge -y cloud-init
# echo "cosmic-freeipa.example.com" >/etc/hostname
# sed -i 's/127.0.1.1.*cosmic.*//g' /etc/hosts
# echo "$(ip addr | grep 'state UP' -A2 | tail -n1 | awk '{print $2}' | cut
-f1 -d'/') cosmic-freeipa.example.com" >>/etc/hosts
# apt update
# apt dist-upgrade -y
# reboot
# apt install -y freeipa-server
* Default Kerberos realm: EXAMPLE.COM
* Kerberos servers: cosmic-freeipa.example.com
* Administrative server: cosmic-freeipa.example.com
Get machine's ip address. You'll be using the x.x.x.1 address for the DNS
forwarder
# ip addr
# ipa-server-install --allow-zone-overlap
* Do you want to configure integrated DNS (BIND): YES
* Server host name: cosmic-freeipa.example.com
* Please confirm the domain name: example.com
* Please provide a realm name: EXAMPLE.COM
* Directory Manager password: (anything)
* IPA admin password: (anything)
* Do you want to configure DNS forwarders: yes
* Do you want to configure these servers as DNS forwarders?: no
* Enter an IP address for a DNS forwarder, or press Enter to skip: (x.x.x.1
address from before)
* Do you want to search for missing reverse zones?: yes
Installation should fail.
[Regression Potential]
In theory, if another library with the exact same symbol is loaded,
bind9 may end up calling the wrong function. This is, however, a
potential problem with any program that loads shared libraries.
[Original Description]
Setting up FreeIPA server fails at "Configuring the web interface",
step 12/21
It's in a cleanly started LXC Ubuntu Bionic container. The
ppa:freeipa/ppa is also used to get tomcat 8.5.30-1ubuntu1.2
Configuring the web interface (httpd)
[1/21]: stopping httpd
[2/21]: backing up ssl.conf
[3/21]: disabling nss.conf
[4/21]: configuring mod_ssl certificate paths
[5/21]: setting mod_ssl protocol list to TLSv1.0 - TLSv1.2
[6/21]: configuring mod_ssl log directory
[7/21]: disabling mod_ssl OCSP
[8/21]: adding URL rewriting rules
[9/21]: configuring httpd
[10/21]: setting up httpd keytab
[11/21]: configuring Gssproxy
[12/21]: setting up ssl
[error] RuntimeError: Certificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORCertificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORThe ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
and in the log there is
2018-05-05T20:37:29Z DEBUG stderr=
2018-05-05T20:37:29Z DEBUG step duration: httpd configure_gssproxy 1.09 sec
2018-05-05T20:37:29Z DEBUG [12/21]: setting up ssl
2018-05-05T20:37:33Z DEBUG certmonger request is in state
dbus.String(u'GENERATING_KEY_PAIR', variant_level=1)
2018-05-05T20:37:38Z DEBUG certmonger request is in state
dbus.String(u'CA_REJECTED', variant_level=1)
2018-05-05T20:37:42Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
555, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
541, in run_step
method()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/httpinstance.py",
line 376, in __setup_ssl
passwd_fname=key_passwd_file
File "/usr/lib/python2.7/dist-packages/ipalib/install/certmonger.py", line
320, in request_and_wait_for_cert
raise RuntimeError("Certificate issuance failed ({})".format(state))
RuntimeError: Certificate issuance failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG [error] RuntimeError: Certificate issuance
failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG File
"/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 174, in exec
ute
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1769440/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
[Freeipa] [Bug 1769440] Re: freeipa server install fails - named-pkcs11 fails to run
I'll take care of this for bionic.
** Changed in: bind9 (Ubuntu Bionic)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
** Changed in: bind9 (Ubuntu Bionic)
Importance: Undecided => High
** Changed in: bind9 (Ubuntu Bionic)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1769440
Title:
freeipa server install fails - named-pkcs11 fails to run
Status in bind9 package in Ubuntu:
Fix Released
Status in freeipa package in Ubuntu:
Invalid
Status in bind9 source package in Bionic:
In Progress
Bug description:
[Impact]
Using RTLD_DEEPBIND in bind9 causes the FreeIPA serve install to fail.
This patch, also applied in fedora and debian, disables use of RTLD_DEEPBIND.
https://src.fedoraproject.org/rpms/bind/c/3d5ea105bd877f0069452e450320f8877b01cb52?branch=master
https://salsa.debian.org/dns-team/bind9/commit/afc6b5fe2e359e4e7eadc256cd94481965418b4b
[Test Case]
# uvt-kvm create --memory 2048 cosmic-freeipa release=cosmic label=daily
# uvt-kvm wait cosmic-freeipa
# uvt-kvm ssh cosmic-freeipa
Inside vm:
# sudo su
# apt purge -y cloud-init
# echo "cosmic-freeipa.example.com" >/etc/hostname
# sed -i 's/127.0.1.1.*cosmic.*//g' /etc/hosts
# echo "$(ip addr | grep 'state UP' -A2 | tail -n1 | awk '{print $2}' | cut
-f1 -d'/') cosmic-freeipa.example.com" >>/etc/hosts
# apt update
# apt dist-upgrade -y
# reboot
# apt install -y freeipa-server
* Default Kerberos realm: EXAMPLE.COM
* Kerberos servers: cosmic-freeipa.example.com
* Administrative server: cosmic-freeipa.example.com
Get machine's ip address. You'll be using the x.x.x.1 address for the DNS
forwarder
# ip addr
# ipa-server-install --allow-zone-overlap
* Do you want to configure integrated DNS (BIND): YES
* Server host name: cosmic-freeipa.example.com
* Please confirm the domain name: example.com
* Please provide a realm name: EXAMPLE.COM
* Directory Manager password: (anything)
* IPA admin password: (anything)
* Do you want to configure DNS forwarders: yes
* Do you want to configure these servers as DNS forwarders?: no
* Enter an IP address for a DNS forwarder, or press Enter to skip: (x.x.x.1
address from before)
* Do you want to search for missing reverse zones?: yes
Installation should fail.
[Regression Potential]
In theory, if another library with the exact same symbol is loaded,
bind9 may end up calling the wrong function. This is, however, a
potential problem with any program that loads shared libraries.
[Original Description]
Setting up FreeIPA server fails at "Configuring the web interface",
step 12/21
It's in a cleanly started LXC Ubuntu Bionic container. The
ppa:freeipa/ppa is also used to get tomcat 8.5.30-1ubuntu1.2
Configuring the web interface (httpd)
[1/21]: stopping httpd
[2/21]: backing up ssl.conf
[3/21]: disabling nss.conf
[4/21]: configuring mod_ssl certificate paths
[5/21]: setting mod_ssl protocol list to TLSv1.0 - TLSv1.2
[6/21]: configuring mod_ssl log directory
[7/21]: disabling mod_ssl OCSP
[8/21]: adding URL rewriting rules
[9/21]: configuring httpd
[10/21]: setting up httpd keytab
[11/21]: configuring Gssproxy
[12/21]: setting up ssl
[error] RuntimeError: Certificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORCertificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORThe ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
and in the log there is
2018-05-05T20:37:29Z DEBUG stderr=
2018-05-05T20:37:29Z DEBUG step duration: httpd configure_gssproxy 1.09 sec
2018-05-05T20:37:29Z DEBUG [12/21]: setting up ssl
2018-05-05T20:37:33Z DEBUG certmonger request is in state
dbus.String(u'GENERATING_KEY_PAIR', variant_level=1)
2018-05-05T20:37:38Z DEBUG certmonger request is in state
dbus.String(u'CA_REJECTED', variant_level=1)
2018-05-05T20:37:42Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
555, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
541, in run_step
method()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/httpinstance.py",
line 376, in __setup_ssl
passwd_fname=key_passwd_file
File "/usr/lib/python2.7/dist-packages/ipalib/install/certmonger.py", line
320, in request_and_wait_for_cert
raise RuntimeError("Certificate issuance failed ({})".format(state))
RuntimeError: Certificate issuance failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG [error] RuntimeError: Certificate issuance
failed (CA_REJECTED)
2018-05-05T20:37:42
[Freeipa] [Bug 1769440] Re: freeipa server install fails - named-pkcs11 fails to run
I don't think there is anything to do here for freeipa itself, just
bind9. Marking the freeipa task as invalid.
** Changed in: freeipa (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1769440
Title:
freeipa server install fails - named-pkcs11 fails to run
Status in bind9 package in Ubuntu:
Confirmed
Status in freeipa package in Ubuntu:
Invalid
Bug description:
Setting up FreeIPA server fails at "Configuring the web interface",
step 12/21
It's in a cleanly started LXC Ubuntu Bionic container. The
ppa:freeipa/ppa is also used to get tomcat 8.5.30-1ubuntu1.2
Configuring the web interface (httpd)
[1/21]: stopping httpd
[2/21]: backing up ssl.conf
[3/21]: disabling nss.conf
[4/21]: configuring mod_ssl certificate paths
[5/21]: setting mod_ssl protocol list to TLSv1.0 - TLSv1.2
[6/21]: configuring mod_ssl log directory
[7/21]: disabling mod_ssl OCSP
[8/21]: adding URL rewriting rules
[9/21]: configuring httpd
[10/21]: setting up httpd keytab
[11/21]: configuring Gssproxy
[12/21]: setting up ssl
[error] RuntimeError: Certificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORCertificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORThe ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
and in the log there is
2018-05-05T20:37:29Z DEBUG stderr=
2018-05-05T20:37:29Z DEBUG step duration: httpd configure_gssproxy 1.09 sec
2018-05-05T20:37:29Z DEBUG [12/21]: setting up ssl
2018-05-05T20:37:33Z DEBUG certmonger request is in state
dbus.String(u'GENERATING_KEY_PAIR', variant_level=1)
2018-05-05T20:37:38Z DEBUG certmonger request is in state
dbus.String(u'CA_REJECTED', variant_level=1)
2018-05-05T20:37:42Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
555, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
541, in run_step
method()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/httpinstance.py",
line 376, in __setup_ssl
passwd_fname=key_passwd_file
File "/usr/lib/python2.7/dist-packages/ipalib/install/certmonger.py", line
320, in request_and_wait_for_cert
raise RuntimeError("Certificate issuance failed ({})".format(state))
RuntimeError: Certificate issuance failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG [error] RuntimeError: Certificate issuance
failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG File
"/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 174, in exec
ute
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1769440/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1769440] Re: freeipa server install fails - named-pkcs11 fails to run
Timo, where is the patch in debian git? I'm looking at
g...@salsa.debian.org:dns-team/bind9.git (https://salsa.debian.org/dns-
team/bind9) but can't find it. It's currently at debian/1%9.11.4+dfsg-4
which is what was released last.
I also checked https://salsa.debian.org/dns-team/bind
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1769440
Title:
freeipa server install fails - named-pkcs11 fails to run
Status in bind9 package in Ubuntu:
Confirmed
Status in freeipa package in Ubuntu:
Confirmed
Bug description:
Setting up FreeIPA server fails at "Configuring the web interface",
step 12/21
It's in a cleanly started LXC Ubuntu Bionic container. The
ppa:freeipa/ppa is also used to get tomcat 8.5.30-1ubuntu1.2
Configuring the web interface (httpd)
[1/21]: stopping httpd
[2/21]: backing up ssl.conf
[3/21]: disabling nss.conf
[4/21]: configuring mod_ssl certificate paths
[5/21]: setting mod_ssl protocol list to TLSv1.0 - TLSv1.2
[6/21]: configuring mod_ssl log directory
[7/21]: disabling mod_ssl OCSP
[8/21]: adding URL rewriting rules
[9/21]: configuring httpd
[10/21]: setting up httpd keytab
[11/21]: configuring Gssproxy
[12/21]: setting up ssl
[error] RuntimeError: Certificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORCertificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORThe ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
and in the log there is
2018-05-05T20:37:29Z DEBUG stderr=
2018-05-05T20:37:29Z DEBUG step duration: httpd configure_gssproxy 1.09 sec
2018-05-05T20:37:29Z DEBUG [12/21]: setting up ssl
2018-05-05T20:37:33Z DEBUG certmonger request is in state
dbus.String(u'GENERATING_KEY_PAIR', variant_level=1)
2018-05-05T20:37:38Z DEBUG certmonger request is in state
dbus.String(u'CA_REJECTED', variant_level=1)
2018-05-05T20:37:42Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
555, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
541, in run_step
method()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/httpinstance.py",
line 376, in __setup_ssl
passwd_fname=key_passwd_file
File "/usr/lib/python2.7/dist-packages/ipalib/install/certmonger.py", line
320, in request_and_wait_for_cert
raise RuntimeError("Certificate issuance failed ({})".format(state))
RuntimeError: Certificate issuance failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG [error] RuntimeError: Certificate issuance
failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG File
"/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 174, in exec
ute
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1769440/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1769440] Re: freeipa server install fails - named-pkcs11 fails to run
I wonder if this patch shouldn't be applied only when doing the -pkcs11
rebuild
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1769440
Title:
freeipa server install fails - named-pkcs11 fails to run
Status in bind9 package in Ubuntu:
Confirmed
Status in freeipa package in Ubuntu:
Confirmed
Bug description:
Setting up FreeIPA server fails at "Configuring the web interface",
step 12/21
It's in a cleanly started LXC Ubuntu Bionic container. The
ppa:freeipa/ppa is also used to get tomcat 8.5.30-1ubuntu1.2
Configuring the web interface (httpd)
[1/21]: stopping httpd
[2/21]: backing up ssl.conf
[3/21]: disabling nss.conf
[4/21]: configuring mod_ssl certificate paths
[5/21]: setting mod_ssl protocol list to TLSv1.0 - TLSv1.2
[6/21]: configuring mod_ssl log directory
[7/21]: disabling mod_ssl OCSP
[8/21]: adding URL rewriting rules
[9/21]: configuring httpd
[10/21]: setting up httpd keytab
[11/21]: configuring Gssproxy
[12/21]: setting up ssl
[error] RuntimeError: Certificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORCertificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORThe ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
and in the log there is
2018-05-05T20:37:29Z DEBUG stderr=
2018-05-05T20:37:29Z DEBUG step duration: httpd configure_gssproxy 1.09 sec
2018-05-05T20:37:29Z DEBUG [12/21]: setting up ssl
2018-05-05T20:37:33Z DEBUG certmonger request is in state
dbus.String(u'GENERATING_KEY_PAIR', variant_level=1)
2018-05-05T20:37:38Z DEBUG certmonger request is in state
dbus.String(u'CA_REJECTED', variant_level=1)
2018-05-05T20:37:42Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
555, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
541, in run_step
method()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/httpinstance.py",
line 376, in __setup_ssl
passwd_fname=key_passwd_file
File "/usr/lib/python2.7/dist-packages/ipalib/install/certmonger.py", line
320, in request_and_wait_for_cert
raise RuntimeError("Certificate issuance failed ({})".format(state))
RuntimeError: Certificate issuance failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG [error] RuntimeError: Certificate issuance
failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG File
"/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 174, in exec
ute
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1769440/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1788497] Re: DEP8 tests currently giving a false green status
** Changed in: freeipa (Ubuntu)
Status: New => Triaged
** Changed in: freeipa (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1788497
Title:
DEP8 tests currently giving a false green status
Status in freeipa package in Ubuntu:
Triaged
Bug description:
The freeipa DEP8 test in cosmic are currently giving a false pass
result. See
http://autopkgtest.ubuntu.com/packages/freeipa/cosmic/amd64
Here is an example:
(...)
self.start_creation(runtime=runtime)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
555, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
541, in run_step
method()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/cainstance.py",
line 832, in __export_ca_chain
chain = self.__get_ca_chain()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/cainstance.py",
line 825, in __get_ca_chain
raise RuntimeError("Unable to retrieve CA chain: %s" % str(e))
2018-08-22T04:21:20Z DEBUG The ipa-server-install command failed, exception:
RuntimeError: Unable to retrieve CA chain: [Errno 111] Connection refused
2018-08-22T04:21:20Z ERROR Unable to retrieve CA chain: [Errno 111]
Connection refused
2018-08-22T04:21:20Z ERROR The ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
autopkgtest [04:21:23]: test server-install: ---]
autopkgtest [04:21:24]: test server-install: - - - - - - - - - - results - -
- - - - - - - -
server-install PASS
autopkgtest [04:21:24]: summary
server-install PASS
Exit request sent.
Creating nova instance adt-cosmic-amd64-freeipa-20180822-040426 from image
adt/ubuntu-cosmic-amd64-server-20180817.img (UUID
d738a39f-ea40-4b0e-8726-3e3be911a4cf)...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/1788497/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1788497] [NEW] DEP8 tests currently giving a false green status
Public bug reported:
The freeipa DEP8 test in cosmic are currently giving a false pass
result. See http://autopkgtest.ubuntu.com/packages/freeipa/cosmic/amd64
Here is an example:
(...)
self.start_creation(runtime=runtime)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
555, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
541, in run_step
method()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/cainstance.py", line
832, in __export_ca_chain
chain = self.__get_ca_chain()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/cainstance.py", line
825, in __get_ca_chain
raise RuntimeError("Unable to retrieve CA chain: %s" % str(e))
2018-08-22T04:21:20Z DEBUG The ipa-server-install command failed, exception:
RuntimeError: Unable to retrieve CA chain: [Errno 111] Connection refused
2018-08-22T04:21:20Z ERROR Unable to retrieve CA chain: [Errno 111] Connection
refused
2018-08-22T04:21:20Z ERROR The ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
autopkgtest [04:21:23]: test server-install: ---]
autopkgtest [04:21:24]: test server-install: - - - - - - - - - - results - - -
- - - - - - -
server-install PASS
autopkgtest [04:21:24]: summary
server-install PASS
Exit request sent.
Creating nova instance adt-cosmic-amd64-freeipa-20180822-040426 from image
adt/ubuntu-cosmic-amd64-server-20180817.img (UUID
d738a39f-ea40-4b0e-8726-3e3be911a4cf)...
** Affects: freeipa (Ubuntu)
Importance: Medium
Status: Triaged
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1788497
Title:
DEP8 tests currently giving a false green status
Status in freeipa package in Ubuntu:
Triaged
Bug description:
The freeipa DEP8 test in cosmic are currently giving a false pass
result. See
http://autopkgtest.ubuntu.com/packages/freeipa/cosmic/amd64
Here is an example:
(...)
self.start_creation(runtime=runtime)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
555, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
541, in run_step
method()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/cainstance.py",
line 832, in __export_ca_chain
chain = self.__get_ca_chain()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/cainstance.py",
line 825, in __get_ca_chain
raise RuntimeError("Unable to retrieve CA chain: %s" % str(e))
2018-08-22T04:21:20Z DEBUG The ipa-server-install command failed, exception:
RuntimeError: Unable to retrieve CA chain: [Errno 111] Connection refused
2018-08-22T04:21:20Z ERROR Unable to retrieve CA chain: [Errno 111]
Connection refused
2018-08-22T04:21:20Z ERROR The ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
autopkgtest [04:21:23]: test server-install: ---]
autopkgtest [04:21:24]: test server-install: - - - - - - - - - - results - -
- - - - - - - -
server-install PASS
autopkgtest [04:21:24]: summary
server-install PASS
Exit request sent.
Creating nova instance adt-cosmic-amd64-freeipa-20180822-040426 from image
adt/ubuntu-cosmic-amd64-server-20180817.img (UUID
d738a39f-ea40-4b0e-8726-3e3be911a4cf)...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/1788497/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1769440] Re: freeipa server install fails - named-pkcs11 fails to run
We can take on this.
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1769440
Title:
freeipa server install fails - named-pkcs11 fails to run
Status in bind9 package in Ubuntu:
Confirmed
Status in freeipa package in Ubuntu:
Confirmed
Bug description:
Setting up FreeIPA server fails at "Configuring the web interface",
step 12/21
It's in a cleanly started LXC Ubuntu Bionic container. The
ppa:freeipa/ppa is also used to get tomcat 8.5.30-1ubuntu1.2
Configuring the web interface (httpd)
[1/21]: stopping httpd
[2/21]: backing up ssl.conf
[3/21]: disabling nss.conf
[4/21]: configuring mod_ssl certificate paths
[5/21]: setting mod_ssl protocol list to TLSv1.0 - TLSv1.2
[6/21]: configuring mod_ssl log directory
[7/21]: disabling mod_ssl OCSP
[8/21]: adding URL rewriting rules
[9/21]: configuring httpd
[10/21]: setting up httpd keytab
[11/21]: configuring Gssproxy
[12/21]: setting up ssl
[error] RuntimeError: Certificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORCertificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORThe ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
and in the log there is
2018-05-05T20:37:29Z DEBUG stderr=
2018-05-05T20:37:29Z DEBUG step duration: httpd configure_gssproxy 1.09 sec
2018-05-05T20:37:29Z DEBUG [12/21]: setting up ssl
2018-05-05T20:37:33Z DEBUG certmonger request is in state
dbus.String(u'GENERATING_KEY_PAIR', variant_level=1)
2018-05-05T20:37:38Z DEBUG certmonger request is in state
dbus.String(u'CA_REJECTED', variant_level=1)
2018-05-05T20:37:42Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
555, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
541, in run_step
method()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/httpinstance.py",
line 376, in __setup_ssl
passwd_fname=key_passwd_file
File "/usr/lib/python2.7/dist-packages/ipalib/install/certmonger.py", line
320, in request_and_wait_for_cert
raise RuntimeError("Certificate issuance failed ({})".format(state))
RuntimeError: Certificate issuance failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG [error] RuntimeError: Certificate issuance
failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG File
"/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 174, in exec
ute
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1769440/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1769440] Re: freeipa server install fails - named-pkcs11 fails to run
Has anybody reproduced this on debian? I confirm it happening then
deploying freeipa, but I'm also looking at a simpler test case now.
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1769440
Title:
freeipa server install fails - named-pkcs11 fails to run
Status in bind9 package in Ubuntu:
Triaged
Status in freeipa package in Ubuntu:
Confirmed
Bug description:
Setting up FreeIPA server fails at "Configuring the web interface",
step 12/21
It's in a cleanly started LXC Ubuntu Bionic container. The
ppa:freeipa/ppa is also used to get tomcat 8.5.30-1ubuntu1.2
Configuring the web interface (httpd)
[1/21]: stopping httpd
[2/21]: backing up ssl.conf
[3/21]: disabling nss.conf
[4/21]: configuring mod_ssl certificate paths
[5/21]: setting mod_ssl protocol list to TLSv1.0 - TLSv1.2
[6/21]: configuring mod_ssl log directory
[7/21]: disabling mod_ssl OCSP
[8/21]: adding URL rewriting rules
[9/21]: configuring httpd
[10/21]: setting up httpd keytab
[11/21]: configuring Gssproxy
[12/21]: setting up ssl
[error] RuntimeError: Certificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORCertificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORThe ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
and in the log there is
2018-05-05T20:37:29Z DEBUG stderr=
2018-05-05T20:37:29Z DEBUG step duration: httpd configure_gssproxy 1.09 sec
2018-05-05T20:37:29Z DEBUG [12/21]: setting up ssl
2018-05-05T20:37:33Z DEBUG certmonger request is in state
dbus.String(u'GENERATING_KEY_PAIR', variant_level=1)
2018-05-05T20:37:38Z DEBUG certmonger request is in state
dbus.String(u'CA_REJECTED', variant_level=1)
2018-05-05T20:37:42Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
555, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
541, in run_step
method()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/httpinstance.py",
line 376, in __setup_ssl
passwd_fname=key_passwd_file
File "/usr/lib/python2.7/dist-packages/ipalib/install/certmonger.py", line
320, in request_and_wait_for_cert
raise RuntimeError("Certificate issuance failed ({})".format(state))
RuntimeError: Certificate issuance failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG [error] RuntimeError: Certificate issuance
failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG File
"/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 174, in exec
ute
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1769440/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1769440] Re: freeipa server install fails - named-pkcs11 fails to run
Thanks, he definitely knows more about bind than I do :)
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1769440
Title:
freeipa server install fails - named-pkcs11 fails to run
Status in bind9 package in Ubuntu:
Triaged
Status in freeipa package in Ubuntu:
Confirmed
Bug description:
Setting up FreeIPA server fails at "Configuring the web interface",
step 12/21
It's in a cleanly started LXC Ubuntu Bionic container. The
ppa:freeipa/ppa is also used to get tomcat 8.5.30-1ubuntu1.2
Configuring the web interface (httpd)
[1/21]: stopping httpd
[2/21]: backing up ssl.conf
[3/21]: disabling nss.conf
[4/21]: configuring mod_ssl certificate paths
[5/21]: setting mod_ssl protocol list to TLSv1.0 - TLSv1.2
[6/21]: configuring mod_ssl log directory
[7/21]: disabling mod_ssl OCSP
[8/21]: adding URL rewriting rules
[9/21]: configuring httpd
[10/21]: setting up httpd keytab
[11/21]: configuring Gssproxy
[12/21]: setting up ssl
[error] RuntimeError: Certificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORCertificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORThe ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
and in the log there is
2018-05-05T20:37:29Z DEBUG stderr=
2018-05-05T20:37:29Z DEBUG step duration: httpd configure_gssproxy 1.09 sec
2018-05-05T20:37:29Z DEBUG [12/21]: setting up ssl
2018-05-05T20:37:33Z DEBUG certmonger request is in state
dbus.String(u'GENERATING_KEY_PAIR', variant_level=1)
2018-05-05T20:37:38Z DEBUG certmonger request is in state
dbus.String(u'CA_REJECTED', variant_level=1)
2018-05-05T20:37:42Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
555, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
541, in run_step
method()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/httpinstance.py",
line 376, in __setup_ssl
passwd_fname=key_passwd_file
File "/usr/lib/python2.7/dist-packages/ipalib/install/certmonger.py", line
320, in request_and_wait_for_cert
raise RuntimeError("Certificate issuance failed ({})".format(state))
RuntimeError: Certificate issuance failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG [error] RuntimeError: Certificate issuance
failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG File
"/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 174, in exec
ute
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1769440/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1769440] Re: freeipa server install fails - named-pkcs11 fails to run
I'll take a look
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1769440
Title:
freeipa server install fails - named-pkcs11 fails to run
Status in bind9 package in Ubuntu:
Triaged
Status in freeipa package in Ubuntu:
Confirmed
Bug description:
Setting up FreeIPA server fails at "Configuring the web interface",
step 12/21
It's in a cleanly started LXC Ubuntu Bionic container. The
ppa:freeipa/ppa is also used to get tomcat 8.5.30-1ubuntu1.2
Configuring the web interface (httpd)
[1/21]: stopping httpd
[2/21]: backing up ssl.conf
[3/21]: disabling nss.conf
[4/21]: configuring mod_ssl certificate paths
[5/21]: setting mod_ssl protocol list to TLSv1.0 - TLSv1.2
[6/21]: configuring mod_ssl log directory
[7/21]: disabling mod_ssl OCSP
[8/21]: adding URL rewriting rules
[9/21]: configuring httpd
[10/21]: setting up httpd keytab
[11/21]: configuring Gssproxy
[12/21]: setting up ssl
[error] RuntimeError: Certificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORCertificate issuance failed (CA_REJECTED)
ipapython.admintool: ERRORThe ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
and in the log there is
2018-05-05T20:37:29Z DEBUG stderr=
2018-05-05T20:37:29Z DEBUG step duration: httpd configure_gssproxy 1.09 sec
2018-05-05T20:37:29Z DEBUG [12/21]: setting up ssl
2018-05-05T20:37:33Z DEBUG certmonger request is in state
dbus.String(u'GENERATING_KEY_PAIR', variant_level=1)
2018-05-05T20:37:38Z DEBUG certmonger request is in state
dbus.String(u'CA_REJECTED', variant_level=1)
2018-05-05T20:37:42Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
555, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/dist-packages/ipaserver/install/service.py", line
541, in run_step
method()
File "/usr/lib/python2.7/dist-packages/ipaserver/install/httpinstance.py",
line 376, in __setup_ssl
passwd_fname=key_passwd_file
File "/usr/lib/python2.7/dist-packages/ipalib/install/certmonger.py", line
320, in request_and_wait_for_cert
raise RuntimeError("Certificate issuance failed ({})".format(state))
RuntimeError: Certificate issuance failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG [error] RuntimeError: Certificate issuance
failed (CA_REJECTED)
2018-05-05T20:37:42Z DEBUG File
"/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 174, in exec
ute
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1769440/+subscriptions
___
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
[Freeipa] [Bug 1747411] Re: Change of default database file format to SQL
** Tags added: server-next -- You received this bug notification because you are a member of FreeIPA, which is subscribed to dogtag-pki in Ubuntu. https://bugs.launchpad.net/bugs/1747411 Title: Change of default database file format to SQL Status in certmonger package in Ubuntu: Fix Released Status in corosync package in Ubuntu: New Status in dogtag-pki package in Ubuntu: Fix Released Status in freeipa package in Ubuntu: Fix Released Status in libapache2-mod-nss package in Ubuntu: Won't Fix Status in nss package in Ubuntu: New Bug description: nss in version 3.35 in upstream changed [2] the default file format [1] (if no explicit one is specified). For now we reverted that change in bug 1746947 until all packages depending on it are ready to work with that correctly. This bug here is about to track when the revert can be dropped. Therefore we list all known-to-be-affected packages and once all are resolved this can be dropped. [1]: https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql [2]: https://github.com/nss-dev/nss/commit/33b114e38278c4ffbb6b244a0ebc9910e5245cd3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/certmonger/+bug/1747411/+subscriptions ___ Mailing list: https://launchpad.net/~freeipa Post to : freeipa@lists.launchpad.net Unsubscribe : https://launchpad.net/~freeipa More help : https://help.launchpad.net/ListHelp
