On 11/27/20 12:12 PM, Alexander Bokovoy via FreeIPA-devel wrote:
>On ke, 18 marras 2020, Alexander Bokovoy via FreeIPA-devel wrote:
>>On ma, 16 marras 2020, Alexander Bokovoy via FreeIPA-devel wrote:
>>>On pe, 13 marras 2020, Alexander Bokovoy via FreeIPA-devel wrote:
>>>>On ke, 11 marras 2020, Stanislav Levin via FreeIPA-devel wrote:
>>>>>
>>>>>
>>>>>11.11.2020 14:11, Alexander Bokovoy via FreeIPA-devel пишет:
>>>>>>On ke, 11 marras 2020, Stanislav Levin wrote:
>>>>>>>>
>>>>>>>>On top of that we have a worrying behavior of the
>>>>>>>>Azure CI with regards
>>>>>>>>to DNSSEC that waits for investigation.
>>>>>>>please, where to see the failure?
>>>>>>
>>>>>>You can look, for example, at
>>>>>>https://github.com/freeipa/freeipa/pull/5248
>>>>>It is like
https://pagure.io/freeipa/issue/8538
>>>>>
>>>>>At least, 389-ds logging may be raised to 8192 from the
>>>>>current one (0)
>>>>>for debugging.
>>>>>
>>>>We already have debugging enabled in Azure CI builds. I
>>>>uploaded logs to
>>>>the issue 8538.
>>>>
>>>>To me this looks like 389-ds issue 4363 is not really fixed yet.
>>>
>>>I ran few experiments with Rawhide and git master over weekend. Here is
>>>my status before 4.9.0-rc1 release preparation:
>>>
>>>- Master branch seems to be no worse than 4.8.0 in terms of running on
>>> Fedora 32 in Azure Pipelines CI and PR CI.
>>>
>>>- Rawhide has fixes for certmonger and 389-ds-base but I was unable to
>>> get them fully tested due to upgrade of glibc that made impossible to
>>> use Azure Pipelines with Rawhide anymore on kernels less than v5.8.
>>>
>>>glibc changed implementation of faccessat() to use faccessat2() if this
>>>syscall is available at the compile time -- requires kernel v5.8 or
>>>later. As a result, systemd cannot start anymore in unprivileged
>>>container on Azure Pipelines CI even with host Ubuntu 20.04 which uses
>>>v5.4. The exact solution is unclear yet because it is a general issue
>>>with libseccomp not knowing about newer syscalls and not being able to
>>>filter out unknown syscalls in a way that would trigger a fallback to
>>>faccessat() in glibc.
>>>
>>>This is a generic issue -- other projects saw a similar fallout when
>>>coreutils and other projects started to use statx() syscall. For
>>>example,
https://bugzilla.redhat.com/show_bug.cgi?id=1784228 outlines
>>>this for libuv which is used by Node.js.
>>>
>>>libseccomp only added support for faccessat2() in version 2.5:
>>>https://github.com/seccomp/libseccomp/commit/5696c896409c1feb37eb502df33cf36efb2e8e01,
>>>
>>>this version is available in Debian Sid already, so one option would be
>>>to try to update the host image at runtime to use newer libseccomp2
>>>package from Sid (it is easily installable on top of Focal repositories,
>>>I checked), then restart docker and reuse our unprivileged containers.
>>
>>An update to the FreeIPA 4.9.0 release candidate releases.
>>
>>We merged most of fixes regarding Rawhide runs to git master and I
>>branched ipa-4-9 for a new release.
>>
>>FreeIPA 4.9.0 release candidate 1 is out now and is built in Rawhide.
>>There is a bug in client-only build which should now be addressed with
>>PR:
https://github.com/freeipa/freeipa/pull/5276
>>
>>Armando did set up PR CI to track ipa-4-9 branch. I did the same for
>>Azure Pipelines. There is also a label 'ipa-4-9' for proposing pull
>>requests for the backports.
>
>Another update.
>
>I am planning for FreeIPA 4.9.0 release candidate 2 for December 1st.
>
>Rawhide state:
>
> - bind-dyndb-ldap 11.6-1.fc34 should be in a working state against BIND
> 9.11 now. Installing IPA master with integrated DNS works just fine.
>
> - python3-dns 2.1.0-0.1.rc1.fc34 is broken and does not allow to
> install IPA replica. This should be fixed with python3-dns
> 2.1.0-0.2.rc1.fc34:
>https://bodhi.fedoraproject.org/updates/FEDORA-2020-622a2dccdc
> With this fix installing IPA replica works fine.
>
> - Spec file for FreeIPA needs updates based on our recent discussions
> with Thomas for RHEL 8.4 packaging. I'll handle this in
>
https://github.com/freeipa/freeipa/pull/5279
>
>Pull requests I expect to land before 4.9.0rc2 release:
> 5294 Allow Apache to answer to ipa-ca requests without
>ipa-4-9
https://github.com/freeipa/freeipa/pull/5294
>{'failure': 1, 'success': 1, 'pending': 28}
> 5292 Always define the path DNSSEC_OPENSSL_CONF ipa-4-9
>https://github.com/freeipa/freeipa/pull/5292 {'success': 1,
>'pending': 3}
5292 has been merged in master and backported to ipa-4-9.
> 5290 Improve PKI subsystem detection ipa-4-6 ipa-4-8 ipa-4-9
>https://github.com/freeipa/freeipa/pull/5290 {'success': 1,
>'failure': 1, 'pending': 24}
5290 needs discussions with pki team, we can skip this fix for the next rc.
> 5279 freeipa.spec.in: unify spec files across upstream WIP
>ipa-4-9
https://github.com/freeipa/freeipa/pull/5279
>{'success': 1, 'pending': 24}
> 5199 Change KRA profiles in certmonger tracking so they
>ipa-4-6 ipa-4-8 ipa-4-9
>https://github.com/freeipa/freeipa/pull/5199 {'success': 1,
>'pending': 27, 'failure': 1, 'error': 1}
5199 has been merged on the master branch and a backport to ipa-4-9 is
in progress.
Thanks, Flo. So I need to complete 5279 to proceed with RC2.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland