[Freeipa] [Bug 2028413] Update Released

2023-10-26 Thread Robie Basak 
The verification of the Stable Release Update for bind9 has completed
successfully and the package is now being released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
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/2028413

Title:
  MRE updates of bind9 for focal, jammy and lunar

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 Focal:
  Triaged
Status in bind9 source package in Focal:
  Triaged
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

Bug description:
  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 and built in the 
correct order, 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

[Freeipa] [Bug 2032650] Update Released

2023-10-26 Thread Robie Basak 
The verification of the Stable Release Update for bind9 has completed
successfully and the package is now being released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
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 Committed
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 1778911] Re: freeipa-client hard depends on chrony

2019-05-14 Thread Robie Basak 
Looks like this was fixed in 4.7.1-1 in Debian, so this is fixed >=
Cosmic in Ubuntu.

If you need a fix for an existing stable release, please comment with a
justification against https://wiki.ubuntu.com/StableReleaseUpdates#When
and complete steps 1 through 4 in
https://wiki.ubuntu.com/StableReleaseUpdates#Procedure - and go ahead
with all the steps if you can. Note that that SRU team would need to
make a final decision.

** Bug watch added: Debian Bug tracker #909803
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909803

** Also affects: freeipa (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909803
   Importance: Unknown
   Status: Unknown

** Changed in: freeipa (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of FreeIPA,
which is subscribed to freeipa in Ubuntu.
https://bugs.launchpad.net/bugs/1778911

Title:
  freeipa-client hard depends on chrony

Status in ceph package in Ubuntu:
  Invalid
Status in chrony package in Ubuntu:
  Invalid
Status in freeipa package in Ubuntu:
  Fix Released
Status in maas package in Ubuntu:
  Invalid
Status in freeipa package in Debian:
  Unknown

Bug description:
  That freeipa-client needs accurate time to work is obvious. But there are 
various ways to go about this:
  1) install a  timeserver like chrony or ntp
  2) Not at all, because the system is an lxc client and thus the time is 
synced externally.

  Currently chrony is installed, and another package requires ntp.
  Furthermore puppet is running on the host and installs chrony on one
  run and in the next run ntp etc etc. And that on a host which requires
  neither.

  There are many ways to solve this problem with various levels of being
  accurate. Please think the problem through in such a way that all
  possible scenarios are covered.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: chrony 3.2-4ubuntu4.1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Wed Jun 27 14:40:03 2018
  SourcePackage: chrony
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1778911/+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

2018-08-13 Thread Robie Basak 
@Gabriel thanks, I follow now.

@Timo do you have plans on getting this landed please? Or do you want
the server team to do it?

** Tags added: server-next

-- 
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

2018-08-02 Thread Robie Basak 
> Looks like bind9 is fixed! Install completes with no issues and named-
pks11 runs without crashing.

Great! Thank you for the report.

I'm not sure this bug was ever clear on exactly what the problem was
with bind9, in terms of bind9. And if it is now fixed, I don't know when
it was fixed. So I'll mark the bind9 task Incomplete for now. If someone
wants to describe the bind9 bug in terms of bind9 itself, and/or
describe when it was fixed, we can update the status appropriately.

** Changed in: bind9 (Ubuntu)
   Status: Triaged => Incomplete

-- 
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:
  Incomplete
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