Fedora Info

[Test-Announce] 2026-06-08 @ 15:00 UTC - Fedora Quality Meeting

2026-06-07T08:41:51.561-07:00

# Fedora Quality Assurance Meeting # Date: 2026-06-08 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+quality+meeting&iso=20260525T15&p1=1440&ah=1 If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 45 status 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net -- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Test-Announce] Fedora 45 Rawhide 20260606.n.2 nightly compose nominated for testing

2026-06-06T13:09:11.203-07:00

Announcing the creation of a new nightly release validation test event for Fedora 45 Rawhide 20260606.n.2. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20260603.n.0: anaconda-45.6-1.fc45.src, 20260606.n.2: anaconda-45.6-2.fc45.src kiwi - 20260603.n.0: kiwi-10.3.0-1.fc45.src, 20260606.n.2: kiwi-10.3.0-2.fc45.src lorax - 20260603.n.0: lorax-45.2-1.fc45.src, 20260606.n.2: lorax-45.2-2.fc45.src pungi - 20260603.n.0: pungi-4.13.0-1.fc45.src, 20260606.n.2: pungi-4.13.0-2.fc45.src python-blivet - 20260603.n.0: python-blivet-3.13.2-2.fc45.src, 20260606.n.2: python-blivet-3.13.2-3.fc45.src pyparted - 20260603.n.0: pyparted-3.13.0-14.fc44.src, 20260606.n.2: pyparted-3.13.0-15.fc45.src pykickstart - 20260603.n.0: pykickstart-3.73-1.fc45.src, 20260606.n.2: pykickstart-3.73-2.fc45.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/45 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Base https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Server https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260606.n.2_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://forge.fedoraproject.org/quality/relvalconsumer -- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: replica RUV communicanting by 389 port

2026-06-03T00:51:33.618-07:00

Please excuse the mistake in my previous message; the communication on port 389 is actually from the supplier nodes to the consumer nodes, not the other way around. What could be triggering traffic on port 389 if the replication agreements are strictly configured on port 636? Note that we are running an old version of 389-ds: 389-ds-base-1.3.10.2-10. Thank you in advance for your help. Best regards -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Test-Announce] Fedora 45 Rawhide 20260603.n.0 nightly compose nominated for testing

2026-06-02T23:42:22.735-07:00

Announcing the creation of a new nightly release validation test event for Fedora 45 Rawhide 20260603.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20260527.n.1: anaconda-45.5-1.fc45.src, 20260603.n.0: anaconda-45.6-1.fc45.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/45 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://forge.fedoraproject.org/quality/relvalconsumer -- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: Fwd: retrieving 75K objects each with 77 attributes vs. all attributes

2026-06-01T01:37:37.363-07:00

On 5/29/26 4:45 PM, Bob Green via 389-users wrote: > On Fri, May 29, 2026 at 6:46 AM Pierre Rogier <progier@redhat.com> wrote: >> Hi Bob, >> >> The difference between using allids and providing a list of 77 attributes is indeed when determining the list of attributes to send. >> i.e calling send_all_attrs instead of send_specific_attrs >> >> in the first case it walks the attribute list of the given entry >> while in the second case for the 77 attributes it iterates on all the attributes to find the searched attribute (i.e performing strcasecmp on the attribute type) >> >> In you case the 77 lookups spend 25 seconds more while sending less data over the network (because some attributes values are not sent) >> >> 75682 objects with 870191 attributes means around 12 attributes per entries >> ==> most of searched attributes are not in the entry meaning that it loops on all attributes to find them. >> so in average something around 75682 * [ 65 * 12 + 12 * 6 ] i.e: 64 M >> strcasecmp are performed on 25 seconds >> Or 2.5 M strcasecmp per seconds >> IMHO that seems a bit low so there is maybe something else than pure CPU bottleneck >> paging maybe, or other processes spending the bandwidth ? > Thank you for your analysis. I went back to take a closer look at > these ~76K objects and indeed there are approximately 77 attributes > being retrieved for each object, which makes the total attributes > retrieved when specifying all 77 explicitly a bit over 5.8 million. > When requesting all attributes the total per object is closer to 87 > attributes each. The 870191 number of total attributes I shared > initially is clearly wrong, I must have come up with this number by > parsing the output through sort | uniq which was incorrect. I'm > guessing now that I've clarified the actual number of attributes > returned from a query your strcasecmp analysis would indicate a CPU > bottleneck. Also note that the server returns values not only attributes. So if some attributes have a large set of values or large values (like jpeg, certs..) then the networks can be a bottleneck. You may redirect your search into a file to compute the amount of transfer data. > > Thank you for sharing these details. > Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: Fwd: retrieving 75K objects each with 77 attributes vs. all attributes

2026-05-29T07:45:49.377-07:00

On Fri, May 29, 2026 at 6:46 AM Pierre Rogier <progier@redhat.com> wrote: > > Hi Bob, > > The difference between using allids and providing a list of 77 attributes is indeed when determining the list of attributes to send. > i.e calling send_all_attrs instead of send_specific_attrs > > in the first case it walks the attribute list of the given entry > while in the second case for the 77 attributes it iterates on all the attributes to find the searched attribute (i.e performing strcasecmp on the attribute type) > > In you case the 77 lookups spend 25 seconds more while sending less data over the network (because some attributes values are not sent) > > 75682 objects with 870191 attributes means around 12 attributes per entries > ==> most of searched attributes are not in the entry meaning that it loops on all attributes to find them. > so in average something around 75682 * [ 65 * 12 + 12 * 6 ] i.e: 64 M > strcasecmp are performed on 25 seconds > Or 2.5 M strcasecmp per seconds > IMHO that seems a bit low so there is maybe something else than pure CPU bottleneck > paging maybe, or other processes spending the bandwidth ? Thank you for your analysis. I went back to take a closer look at these ~76K objects and indeed there are approximately 77 attributes being retrieved for each object, which makes the total attributes retrieved when specifying all 77 explicitly a bit over 5.8 million. When requesting all attributes the total per object is closer to 87 attributes each. The 870191 number of total attributes I shared initially is clearly wrong, I must have come up with this number by parsing the output through sort | uniq which was incorrect. I'm guessing now that I've clarified the actual number of attributes returned from a query your strcasecmp analysis would indicate a CPU bottleneck. Thank you for sharing these details. Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: retrieving 75K objects each with 77 attributes vs. all attributes

2026-05-29T07:06:35.383-07:00

On Thu, May 28, 2026 at 3:48 PM Bob Green <wood.green.robert@gmail.com> wrote: > > On Thu, May 28, 2026 at 1:16 PM Mark Reynolds <mareynol@redhat.com> wrote: > > > > Otherwise, in this case the only other option is to make sure your entry > > cache is large enough to hold all the entries. Note - running > > concurrent searches like this is not going to be performant because it > > has to process so many results. So I am not surprised the more > > concurrent searches you run the slower they all get. > > Am I correct that nsslapd-cachesize: -1 under dn: cn=userroot,cn=ldbm > database,cn=plugins,cn=config will "automatically size" the entry > cache? I ask because dsconf INSTANCE backend monitor --suffix > dc=example,dc=com reports: > > currententrycachesize: 2818570021 > maxentrycachesize: 2818572288 > > which is just about at the maximum, though perhaps this will grow in > size as needed? Or should I replace -1 with a larger value? To answer my question, if you want to manually set your nsslapd-cachememsize attribute you must make the following ldapmodify changes: dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cache-autosize nsslapd-cache-autosize: 0 dn: cn=userroot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: <new_value> Thanks again, and I apologize for my previous email which was forwarded rather than replied, due to me not noticing I had only replied to Mark and not the list previously. Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: Fwd: retrieving 75K objects each with 77 attributes vs. all attributes

2026-05-29T06:46:28.477-07:00

Hi Bob,

The difference between using allids and providing a list of 77 attributes is indeed when determining the list of attributes to send.
i.e calling send_all_attrs instead of send_specific_attrs

in the first case it walks the attribute list of the given entry
while in the second case for the 77 attributes it iterates on all the attributes to find the searched attribute (i.e performing strcasecmp on the attribute type)

In you case the 77 lookups spend 25 seconds more while sending less data over the network (because some attributes values are not sent)

75682 objects with 870191 attributes means around 12 attributes per entries
==> most of searched attributes are not in the entry meaning that it loops on all attributes to find them.
so in average something around 75682 * [ 65 * 12 + 12 * 6 ] i.e: 64 M
strcasecmp are performed on 25 seconds
Or 2.5 M strcasecmp per seconds
IMHO that seems a bit low so there is maybe something else than pure CPU bottleneck
paging maybe, or other processes spending the bandwidth ?

Regards
Pierre

On Fri, May 29, 2026 at 12:49 AM Bob Green via 389-users <389-users@lists.fedoraproject.org> wrote:

On Thu, May 28, 2026 at 1:16 PM Mark Reynolds <mareynol@redhat.com> wrote:
>
> Hi Bob,
>
> What is in the access log for these searches? I suspect you're doing an
> unindexed search (check access log for notes=A or notes=U).

There are no notes=A or notes=U access events, just notes=P (paged
search) and a smattering of notes=N.

> This is not really an ideal way to test the server's performance. One
> thing to help with this type of search is to adjust the idscanlimit to
> at least 100000 (it might already be set really high)
>
> # dsconf slapd-YOUR_INSTANCE backend config get | grep
> nsslapd-idlistscanlimit
>
> If it's 4000 (or less than 100k) you can bump it up:
>
> # dsconf slapd-YOUR_INSTANCE backend config set
> --idlistscanlimit=100000 (this does not require a server restart to
> take effect)

nsslapd-idlistscanlimit is 2147483646.

> Otherwise, in this case the only other option is to make sure your entry
> cache is large enough to hold all the entries. Note - running
> concurrent searches like this is not going to be performant because it
> has to process so many results. So I am not surprised the more
> concurrent searches you run the slower they all get.

Am I correct that nsslapd-cachesize: -1 under dn: cn=userroot,cn=ldbm
database,cn=plugins,cn=config will "automatically size" the entry
cache? I ask because dsconf INSTANCE backend monitor --suffix
dc=example,dc=com reports:

currententrycachesize: 2818570021
maxentrycachesize: 2818572288

which is just about at the maximum, though perhaps this will grow in
size as needed? Or should I replace -1 with a larger value?

I also increased nsslapd-ndn-cache-max-size, dcsonf INSTANCE config
replace nsslapd-ndn-cache-max-size after seeing this with dsconf
INSTANCE monitor backend:

currentnormalizeddncachesize: 20971440
maxnormalizeddncachesize: 20971440

Thank you for the suggestions.
Bob
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

--

389 Directory Server Development Team

-- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

Reminder about the sunset of pagure.io

2026-05-29T03:45:50.618-07:00

Hello everyone, we aim to decommision our old forge pagure.io around the Flock conference. We encourage you to migrate all your repositories from Pagure to our new forge[1] or to any other Git hosting service. If you have any questions, you can contact us on Matrix[2] or open a ticket with the Forge team [3]. Discussion and feedback can be held in the Discourse topic[4]. New organisation requests can be filed on the Forge ticket tracker[3] On behalf of the Fedora Infrastructure Team Smolík Vít [1] https://forge.fedoraproject.org [2] https://matrix.to/#/#fedora-forgejo:fedoraproject.org [3] https://forge.fedoraproject.org/forge/forge [4] https://discussion.fedoraproject.org/t/decommissioning-of-pagure-io-anticipated-by-flock-2026/181997 -- _______________________________________________ announce mailing list -- announce@lists.fedoraproject.org To unsubscribe send an email to announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] replica RUV communicanting by 389 port

2026-05-29T03:02:07.638-07:00

Hello team, I have my replication agreements working on port 636 via LDAPS with SSL/TLS encryption, but I can still see port 389 traffic between consumer and supplier nodes. I suspect that this might be due to RUV traffic between them, as I can see port 389 referenced in my supplier configuration. ObjectClass nsDS5ReplicationAgreement (structural) ObjectClass top (abstract) cn supplier1 cn=consumer1,cn=replica,cn=c\3Des,cn=mapping tree,cn=config nsds50ruv {replica 31 ldap://supplier1.domain.net:389} 588cd5a80000001f0000 69ec217b0359001f0000 nsruvReplicaLastModified {replica 31 ldap://supplier1.domain.net:389} 00000000 Is it possible that RUV communication is going over port 389? If so, is there any way to change this configuration so that RUV traffic uses the secure 636 port instead? Thank you very much in advance for your appreciated help. -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: parentid index mismatch after replica initialization causes one-level search to return no entries

2026-05-28T16:13:37.290-07:00

Hi,

In our case, both RHEL8 and RHEL9 replica targets were freshly provisioned systems.

They were not upgraded replicas.

We installed the IPA packages on clean systems and then performed the initial replica configuration from source server.

The nsMatchingRule: integerOrderingMatch appeared on the replica during that replica setup flow.

So the part we are trying to understand is:

why does a freshly provisioned replica end up with a parentid index definition using integerOrderingMatch,

while the actual on-disk parentid index still uses lexicographic ordering after initial replication/total init?

We understand that removing nsMatchingRule and reindexing may be a workaround,

but we would like to understand why this mismatch is created on a fresh replica in the first place.

Thanks,

Seongho Park

보낸 사람: Thierry Bordaz via 389-users <389-users@lists.fedoraproject.org>
보낸 날짜: 2026년 5월 28일 목요일 오후 5:16
받는 사람: 389-users@lists.fedoraproject.org <389-users@lists.fedoraproject.org>
참조: Thierry Bordaz <tbordaz@redhat.com>
제목: [389-users] Re: parentid index mismatch after replica initialization causes one-level search to return no entries

389-users@lists.fedoraproject.org에게서 전자 메일을 받지 못하는 경우가 많습니다. 이 문제가 중요한 이유

On 5/28/26 1:54 AM, 박성호 via 389-users wrote:

Hello 389-ds users,

We are investigating a reproducible issue during FreeIPA/IdM replica installation.

After initial replication completes, the replica target contains the expected LDAP entries, but one-level searches under cn=masters return no entries. Subtree searches under the same base return the expected entries.

On the replica target:

ldapsearch -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" -s one dn

=> returns no entries

ldapsearch -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" -s sub dn

=> returns the expected master and service entries

At the same time, 389-ds logs the following error:

Backend 'userRoot': MISMATCH - parentid index has integerOrderingMatch configured, but on-disk data uses lexicographic ordering. This will cause searches to return incorrect or incomplete results. Please reindex the parentid attribute: dsconf <instance> backend index reindex --attr parentid userRoot

The issue was reproduced in both cases:

1. Source 389-ds-base 1.4.3.39-23 -> Replica 389-ds-base 1.4.3.39-23

2. Replica 389-ds-base 1.4.3.39-23 -> Replica 389-ds-base 2.8.0-6

The index configuration differs between the original source and the replicas.

Source server:

parentid index has no nsMatchingRule.

Replica servers:

parentid index has:

nsMatchingRule: integerOrderingMatch

The error message comes this mismatch between the configure MR and the effective order in parentid index db.
Did you upgraded the replica, so the nsMatchingRule is a leftover from previous install ?

I suggest to remove this matching rule and reindex with the command that is in the error log.

regards

Running a userRoot parentid reindex on the replica target restores the one-level search immediately. However, in the FreeIPA installer flow, this happens after ipa-replica-install has already failed.

Question:

Why does the replica target build or retain parentid on-disk index data using lexicographic ordering when the configured parentid index expects integerOrderingMatch? Is this expected after a total initialization from an older index definition, or should the replica initialization rebuild parentid using the target-side matching rule?

Is there a supported way to force or validate parentid index consistency immediately after total initialization and before upper-layer applications rely on one-level searches?

Please refer to the final inquiry sent to the FreeIPA users mailing list for additional technical details and follow-up discussion.

Thanks,

Seongho Park

보낸 사람: Rob Crittenden <rcritten@redhat.com>
보낸 날짜: 2026년 5월 28일 목요일 오전 3:55
받는 사람: FreeIPA users list <freeipa-users@lists.fedorahosted.org>; Florence Blanc-Renaud <flo@redhat.com>
참조: 이철구 <cgulee@lgcns.com>; 박성호 <seongho.park@lgcns.com>
제목: Re: [Freeipa-users] Re: FreeIPA replica install fails after initial replication: one-level search under cn=masters returns 0 until userRoot reindex

[rcritten@redhat.com 전자 메일을 받지 않는 경우가 많습니다. https://aka.ms/LearnAboutSenderIdentification ]에서 중요한 이유 알아보기

박성호 via FreeIPA-users wrote:
> Hello FreeIPA users,
>
> Is there anyone who can help with the following?
> The same error log was confirmed in both of the below cases.
>
> *Error Logs From (/var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors)*
> /var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors:[27/May/2026:11:10:31.315009288
> +0000] - ERR - ldbm_instance_check_index_config - Backend 'userRoot':
> MISMATCH - parentid index has integerOrderingMatch configured, but
> on-disk data uses lexicographic ordering. This will cause searches to
> return incorrect or incomplete results. Please reindex the parentid
> attribute: dsconf <instance> backend index reindex --attr parentid userRoot
>
>   *
>     Source server #1 (389-ds-base-1.4.3.39-23) => Replica server #1
>     (389-ds-base-1.4.3.39-23)
>   *
>     Replica server #1 (389-ds-base-1.4.3.39-23) => Replica server #2
>     (389-ds-base-2.8.0-6)
>
>
> *Our source server information*
> [root@xxxx ~]# dsconf "$INST" backend index get userRoot --attr parentid
> dn: cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: parentid
> nsIndexType: eq
> nsSystemIndex: true
> objectClass: top
> objectClass: nsIndex
>
> *Our replica server #1 information*
> [root@xxxx ~]# dsconf "$INST" backend index get userRoot --attr parentid
> dn: cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: parentid
> nsIndexType: eq
> nsMatchingRule: integerOrderingMatch
> nsSystemIndex: true
> objectClass: top
> objectClass: nsIndex
>
> *Our replica server #2 information*
> [root@xxxx ~]# dsconf "$INST" backend index get userRoot --attr parentid
> dn: cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: parentid
> nsIndexType: eq
> nsMatchingRule: integerOrderingMatch
> nsSystemIndex: true
> objectClass: top
> objectClass: nsIndex
>
> We found a workaround, but we are curious about the underlying reason
> why we need to perform a reindex.
>
> Thanks,
> Seongho Park
>
> ------------------------------------------------------------------------
> *보낸 사람:* 박성호 <seongho.park@lgcns.com>
> *보낸 날짜:* 2026년 5월 26일 화요일 오후 11:33
> *받는 사람:* Florence Blanc-Renaud <flo@redhat.com>; FreeIPA users list
> <freeipa-users@lists.fedorahosted.org>
> *참조:* 이철구 <cgulee@lgcns.com>
> *제목:* Re: [Freeipa-users] FreeIPA replica install fails after initial
> replication: one-level search under cn=masters returns 0 until userRoot
> reindex
>
> Hello Flo!
> Thank you for checking this quickly.
>
> Are you saying that I need to upgrade the source server's 389-ds version?
> I'm not entirely sure yet, but it looks higher than the version you
> mentioned.
>
>     - on 8.10: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A3126&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373262857%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2F6pMM8M8Cgi246yf3tPmbrJ%2FsMBCAndhwnj81wTJo6w%3D&reserved=0 with
>     389-ds-base-1.4.3.39-22.module+el8.10.0+24000+b6bfdf3f
>
> Currently, there are restrictions on checking the contents of
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F7135993&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373293970%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w0HudefEfnMp0tIIGwPiiUgxVRVUBBSuGypCvc%2FW7xk%3D&reserved=0,
> so additional verification will be available tomorrow. Below are the
> details of the version currently in use.
> *
> *
> *Our source server information*
>
>   *
>     Rocky Linux 8.8 (Green Obsidian)
>   *
>     ipa-server-4.9.13-21.module+el8.10.0+40089+03bf3c1f.x86_64
>   *
>     ipa-client-4.9.13-21.module+el8.10.0+40089+03bf3c1f.x86_64
>   *
>     ipa-server-dns-4.9.13-21.module+el8.10.0+40089+03bf3c1f.noarch
>   *
>     ipa-server-trust-ad-4.9.13-21.module+el8.10.0+40089+03bf3c1f.x86_64
>   *
>     389-ds-base-1.4.3.39-23.module+el8.10.0+40135+69dd2a79.x86_64
>   *
>     389-ds-base-libs-1.4.3.39-23.module+el8.10.0+40135+69dd2a79.x86_64
>
>
> *Our replica server #1 information*
>
>   *
>     Red Hat Enterprise Linux 8.10 (Ootpa)
>   *
>     ipa-server-4.9.13-21.module+el8.10.0+23944+84561300.x86_64
>   *
>     ipa-client-4.9.13-21.module+el8.10.0+23944+84561300.x86_64
>   *
>     ipa-server-dns-4.9.13-21.module+el8.10.0+23944+84561300.noarch
>   *
>     ipa-server-trust-ad-4.9.13-21.module+el8.10.0+23944+84561300.x86_64
>   *
>     389-ds-base-1.4.3.39-23.module+el8.10.0+24085+b368a310.x86_64
>   *
>     389-ds-base-libs-1.4.3.39-23.module+el8.10.0+24085+b368a310.x86_64
>
>
> *Our replica server #2 information*
>
>   *
>     Red Hat Enterprise Linux 9.8 (Plow)
>   *
>     ipa-server-4.13.1-3.el9_8.2.x86_64
>   *
>     ipa-client-4.13.1-3.el9_8.2.x86_64
>   *
>     ipa-server-dns-4.13.1-3.el9_8.2.noarch
>   *
>     package ipa-server-trust-ad is not installed
>   *
>     389-ds-base-2.8.0-6.el9_8.x86_64
>   *
>     389-ds-base-libs-2.8.0-6.el9_8.x86_64

This is really more a question for the 389-ds team. They sometimes pop
in here so someone might answer, but you may want to cross-post this to
the 389-users list to be sure they see it.

The parentid index is created by 389-ds directly and not by IPA.

rob

> ------------------------------------------------------------------------
> *보낸 사람:* Florence Blanc-Renaud <flo@redhat.com>
> *보낸 날짜:* 2026년 5월 26일 화요일 오후 10:04
> *받는 사람:* FreeIPA users list <freeipa-users@lists.fedorahosted.org>
> *참조:* 이철구 <cgulee@lgcns.com>; 박성호 <seongho.park@lgcns.com>
> *제목:* Re: [Freeipa-users] FreeIPA replica install fails after initial
> replication: one-level search under cn=masters returns 0 until userRoot
> reindex
>
>
> flo@redhat.com에게서 전자 메일을 받지 못하는 경우가 많습니다. 이 문제가
> 중요한 이유 <https://aka.ms/LearnAboutSenderIdentification>
>
>
> Hi,
>
> This is a known issue with 389-ds, you can get more information at
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F7135993&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373318052%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rkFIhgxu1FGGyFoL75V5PgEmg54yIJzZ7LJJJAcS9lM%3D&reserved=0
>
> The fixes are available:
> - on 8.10:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A3126&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373340316%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zTDmpz8H3uR%2BsSDGe5J7Qx937bLg2gNwIKysbgRpKTQ%3D&reserved=0 with 389-ds-base-1.4.3.39-22.module+el8.10.0+24000+b6bfdf3f
> - on 9.7: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHSA-2026%3A3189&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373359894%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qJbhA4z4%2BC2pt4U1H8CMs2wfMRt2hLq5jMlRs8Y%2BYlI%3D&reserved=0 with
> 389-ds-base-2.7.0-10.el9_7
> - on 9.8: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A18956&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373379524%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v94KwvhN7yrwy9a3148ZxseUfsE65j8a8V1jZRk%2Fnng%3D&reserved=0 with
> 389-ds-base-2.8.0-6.el9_8
> - on 10.1:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHSA-2026%3A3208&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373401060%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JQYIzOSDrJYf%2Bd2ivTMQPJVmqRGKMqY6M61eY7KciUE%3D&reserved=0 with 389-ds-base-3.1.3-7.el10_1.
> - on 10.2: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A18575&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373422008%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UrqWJfvLu%2Bi0EFhRrfL5%2BBOppnmfVkPhe5BV%2FsL%2BFys%3D&reserved=0 with
> 389-ds-base-3.2.0-6.el10_2
>
> HTH,
> flo
>
> On Tue, May 26, 2026 at 12:11 PM 박성호 via FreeIPA-users
> <freeipa-users@lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>
>     Hi FreeIPA users,
>
>     I am investigating a reproducible FreeIPA/IdM replica installation
>     failure.
>
>     Summary:
>     After initial replication succeeds during ipa-replica-install, local
>     LDAP subtree searches under cn=masters work, but one-level searches
>     under the same DN return zero entries. This causes ipa server-find
>     --servrole="IPA master", ipa server-role-find --include-master, and
>     dns_update_system_records during replica installation to fail with:
>
>       no matching entry found
>
>     A full userRoot reindex immediately fixes the issue.
>
>     Environment:
>     - Existing master: RHEL 8.10, FreeIPA 4.9.x
>     - New replica test 1: RHEL 8.10, FreeIPA 4.9.x
>     - New replica test 2: RHEL 9.x, FreeIPA 4.13.x
>     - Domain: idm.example.com <https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fidm.example.com%2F&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373444724%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=I3h0eyB161Eg8gWjpzjJ2QzilKOZeXha3Q6fCgsXUUU%3D&reserved=0>
>     - Realm: IDM.EXAMPLE.COM <https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fidm.example.com%2F&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373464870%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UI2%2F643yBENt%2F7nfdBi1l3320g9raftRHNZH%2FO%2ByEg0%3D&reserved=0>
>
>     The same behavior is reproduced on both RHEL8 and RHEL9 replicas.
>
>     Failure path from ipareplica-install.log:
>
>       ipa-replica-install
>         -> dns_update_system_records()
>         -> server_find(servrole='IPA master')
>         -> server_role_find(role_servrole='IPA master',
>     status='enabled', include_master=True)
>         -> servroles._fill_in_absent_masters()
>         -> ldap2.get_entries()
>         -> EmptyResult: no matching entry found
>
>     Before reindex, on the new replica:
>
>       ldapsearch -H ldapi://%2Frun%2Fslapd-IDM-EXAMPLE-COM.socket -Y
>     GSSAPI -LLL \
>         -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" \
>         -s one "(objectClass=*)" dn cn objectClass
>
>     returns no entries.
>
>     But subtree search works:
>
>       ldapsearch -H ldapi://%2Frun%2Fslapd-IDM-EXAMPLE-COM.socket -Y
>     GSSAPI -LLL \
>         -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" \
>         -s sub "(objectClass=ipaConfigObject)" dn cn objectClass
>
>     returns the expected master and service entries.
>
>     After running:
>
>       dsconf IDM-EXAMPLE-COM backend index reindex --wait userRoot
>
>     the one-level search works, and ipa server-find / ipa
>     dns-update-system-records work.
>
>     Things already checked:
>     - This does not appear to be specific to a RHEL8 or RHEL9 replica
>     target.
>     - The replicated data appears to exist locally; the issue seems
>     specific to one-level search/index behavior under cn=masters.
>     - A full userRoot reindex immediately makes the same one-level
>     search and FreeIPA commands work.
>
>     Question:
>     Is this a known 389-ds / FreeIPA replica initialization issue where
>     the local parent/one-level search index is incomplete immediately
>     after total init? Is there a supported way to force or verify index
>     consistency before ipa-replica-install reaches
>     dns_update_system_records?
>
>     Please let me know if this should be reported to 389-ds instead of
>     FreeIPA.
>
>     Thanks.
>
>
>     고객의소리열기
>     <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcppm.singlex.com%2Fpublic%2FpainpointDirects%2FC998%3FmediaSource%3DEMAIL&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373484115%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hsjsphHj1VXKWBu3wOYlm3ASQ2A9E%2FlonfpQ7tYIX%2Bs%3D&reserved=0>
>
>     ------------------------------------------------------------------------
>     상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지
>     정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수
>     로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주
>     시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다.
>     상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는
>     것은 금지되어 있습니다.(주)LG CNS.
>     This message and its attachments may contain confidential
>     information, and they are intended to be viewed or used by only the
>     individuals specified in the message. If you have received this
>     message in an error from the sender, please contact the sender
>     immediately to notify the error and delete all of the message and
>     its copies. It is prohibited to view, use, make public and/or
>     distribute part or whole of this message without written permission.
>     --
>     _______________________________________________
>     FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>     <mailto:freeipa-users@lists.fedorahosted.org>
>     To unsubscribe send an email to
>     freeipa-users-leave@lists.fedorahosted.org
>     <mailto:freeipa-users-leave@lists.fedorahosted.org>
>     Fedora Code of Conduct:
>     https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373504038%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IOJUFt4zqwKuTlpE8LbiX%2BkdB67CYaL2fRUhDxDay4U%3D&reserved=0
>     List Guidelines: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373523224%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w%2FD4THwBp4NTfmF%2BMfEiKdmfu7lcCE4%2BQkGLW1MMTtI%3D&reserved=0
>     List Archives:
>     https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.org&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373541933%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hAa3x6%2F4K0DboQQjEOQlMztE%2Bc4NWC8dla9p4bO6bDo%3D&reserved=0
>     Do not reply to spam, report it:
>     https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforge.fedoraproject.org%2Finfra%2Ftickets%2Fissues%2Fnew&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373564065%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FhzXocFM4KEG4Fp1GzDMBIZVBbyffN6Vt999UiFY2ns%3D&reserved=0
>
>
>
> 고객의소리열기
> <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcppm.singlex.com%2Fpublic%2FpainpointDirects%2FC998%3FmediaSource%3DEMAIL&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373582605%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vLy6f9yqW7yXvSO0IlzDQHvgf%2BOqfzBE4p0w81oB3K4%3D&reserved=0>
>
> ------------------------------------------------------------------------
> 상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된
> 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여
> 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시
> 지와 모든 사본을 폐기해 주시기 바랍니다.
> 상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은
> 금지되어 있습니다.(주)LG CNS.
> This message and its attachments may contain confidential information,
> and they are intended to be viewed or used by only the individuals
> specified in the message. If you have received this message in an error
> from the sender, please contact the sender immediately to notify the
> error and delete all of the message and its copies. It is prohibited to
> view, use, make public and/or distribute part or whole of this message
> without written permission.
>

상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다.
상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은 금지되어 있습니다.(주)LG CNS.
This message and its attachments may contain confidential information, and they are intended to be viewed or used by only the individuals specified in the message. If you have received this message in an error from the sender, please contact the sender immediately to notify the error and delete all of the message and its copies. It is prohibited to view, use, make public and/or distribute part or whole of this message without written permission.

상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다.
상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은 금지되어 있습니다.(주)LG CNS.
This message and its attachments may contain confidential information, and they are intended to be viewed or used by only the individuals specified in the message. If you have received this message in an error from the sender, please contact the sender immediately to notify the error and delete all of the message and its copies. It is prohibited to view, use, make public and/or distribute part or whole of this message without written permission.

[389-users] Fwd: retrieving 75K objects each with 77 attributes vs. all attributes

2026-05-28T15:49:05.200-07:00

On Thu, May 28, 2026 at 1:16 PM Mark Reynolds <mareynol@redhat.com> wrote: > > Hi Bob, > > What is in the access log for these searches? I suspect you're doing an > unindexed search (check access log for notes=A or notes=U). There are no notes=A or notes=U access events, just notes=P (paged search) and a smattering of notes=N. > This is not really an ideal way to test the server's performance. One > thing to help with this type of search is to adjust the idscanlimit to > at least 100000 (it might already be set really high) > > # dsconf slapd-YOUR_INSTANCE backend config get | grep > nsslapd-idlistscanlimit > > If it's 4000 (or less than 100k) you can bump it up: > > # dsconf slapd-YOUR_INSTANCE backend config set > --idlistscanlimit=100000 (this does not require a server restart to > take effect) nsslapd-idlistscanlimit is 2147483646. > Otherwise, in this case the only other option is to make sure your entry > cache is large enough to hold all the entries. Note - running > concurrent searches like this is not going to be performant because it > has to process so many results. So I am not surprised the more > concurrent searches you run the slower they all get. Am I correct that nsslapd-cachesize: -1 under dn: cn=userroot,cn=ldbm database,cn=plugins,cn=config will "automatically size" the entry cache? I ask because dsconf INSTANCE backend monitor --suffix dc=example,dc=com reports: currententrycachesize: 2818570021 maxentrycachesize: 2818572288 which is just about at the maximum, though perhaps this will grow in size as needed? Or should I replace -1 with a larger value? I also increased nsslapd-ndn-cache-max-size, dcsonf INSTANCE config replace nsslapd-ndn-cache-max-size after seeing this with dsconf INSTANCE monitor backend: currentnormalizeddncachesize: 20971440 maxnormalizeddncachesize: 20971440 Thank you for the suggestions. Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

Fedora 42 Has Reached END OF LIFE

2026-05-28T15:20:13.337-07:00

Hello all,

Fedora 42 has reached end of life for updates today, 2026-05-28. It was originally supposed to happen yesterday but there was a slight delay. Apologies.

No more updates of any kind, including security updates or security announcements, will be available for Fedora 42 after this date. No pending updates will be pushed to stable.

Fedora 43 will continue to receive updates until approximately one month after the release of Fedora 45. The maintenance schedule of Fedora releases is documented here [1]. The documentation also contains instructions [2] on how to upgrade from a previous release to a version receiving updates.

Best regards,

Patrik Polakovic

Fedora Release Engineering

[1] https://docs.fedoraproject.org/en-US/releases/lifecycle/#_maintenance_schedule
[2] https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/

-- _______________________________________________ announce mailing list -- announce@lists.fedoraproject.org To unsubscribe send an email to announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Test-Announce] Fedora 42 Has Reached END OF LIFE

2026-05-28T14:58:58.049-07:00

Hello all,

Fedora 42 has reached end of life for updates today, 2026-05-28. It was originally supposed to happen yesterday but there was a slight delay. Apologies.

No more updates of any kind, including security updates or security announcements, will be available for Fedora 42 after this date. No pending updates will be pushed to stable.

Best regards,

Patrik Polakovic

Fedora Release Engineering

[1] https://docs.fedoraproject.org/en-US/releases/lifecycle/#_maintenance_schedule
[2] https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/

-- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: retrieving 75K objects each with 77 attributes vs. all attributes

2026-05-28T13:16:53.243-07:00

Hi Bob, What is in the access log for these searches? I suspect you're doing an unindexed search (check access log for notes=A or notes=U). This is not really an ideal way to test the server's performance. One thing to help with this type of search is to adjust the idscanlimit to at least 100000 (it might already be set really high) # dsconf slapd-YOUR_INSTANCE backend config get | grep nsslapd-idlistscanlimit If it's 4000 (or less than 100k) you can bump it up: # dsconf slapd-YOUR_INSTANCE backend config set --idlistscanlimit=100000 (this does not require a server restart to take effect) Otherwise, in this case the only other option is to make sure your entry cache is large enough to hold all the entries. Note - running concurrent searches like this is not going to be performant because it has to process so many results. So I am not surprised the more concurrent searches you run the slower they all get. And yes, requesting specific attrs adds some overhead to the search. Anyway check the access log and your idscanlimit first. Regards, Mark On 5/28/26 4:02 PM, Bob Green via 389-users wrote: > I've been fiddling with various 389ds tuning parameters to see if I > can improve performance running > 389-ds-2.7.0~git144.f597a91d8-150700.3.13.1.x86_64 on SLES15sp7 on a > modestly specced KVM guest with 16GB of RAM and 2 "Intel Core > Processor (Haswell, no TSX)". I believe performance is bottlenecked > by my CPUs. I'm wondering if someone can confirm that an ldapsearch > filter (objectclass=computer) that retrieves 75682 objects with 870191 > attributes counting dn: in just under a minute is considered > reasonable? If instead I request the 77 attributes I want to retrieve > for each object, rather than "attrs=ALL", the same query filter will > take ~85 seconds. I'm guessing the increased time is due to the > overhead incurred by 389ds to selectively pick out those attributes, > and that this is expected? > > I was wondering if there exists any computer sizing recommendations > that might help me determine what hardware I should install 389ds on? > > As mentioned, I believe my 389ds instance is CPU bound, when I run the > same query above in parallel, every additional query seems to add > roughly 30 seconds to the amount of time the queries will take to > finish. e.g. single query finishes in 60 seconds, 2 in parallel 90 > seconds, 4 in parallel ~150 seconds, 10 concurrent queries will take > ~330 seconds for all to complete. sar/mpstat on the 389ds instance > shows that as I increase the number of concurrent queries cpu %usr > utilization on the 389ds increases while %sys drops. expected I'm > guessing... > > I'm trying to rule out whether I have inadequate indexing or whether > some other tunable might improve concurrent queries of what is an > admittedly large query, and hoping the community might be able to > validate that yes, your query is large, if you insist on running this > on 389ds you should plan on having 389ds run on significant hardware > resources. > > Thank you for your time, > Bob -- Identity Management Development Team -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] retrieving 75K objects each with 77 attributes vs. all attributes

2026-05-28T13:02:25.397-07:00

I've been fiddling with various 389ds tuning parameters to see if I can improve performance running 389-ds-2.7.0~git144.f597a91d8-150700.3.13.1.x86_64 on SLES15sp7 on a modestly specced KVM guest with 16GB of RAM and 2 "Intel Core Processor (Haswell, no TSX)". I believe performance is bottlenecked by my CPUs. I'm wondering if someone can confirm that an ldapsearch filter (objectclass=computer) that retrieves 75682 objects with 870191 attributes counting dn: in just under a minute is considered reasonable? If instead I request the 77 attributes I want to retrieve for each object, rather than "attrs=ALL", the same query filter will take ~85 seconds. I'm guessing the increased time is due to the overhead incurred by 389ds to selectively pick out those attributes, and that this is expected? I was wondering if there exists any computer sizing recommendations that might help me determine what hardware I should install 389ds on? As mentioned, I believe my 389ds instance is CPU bound, when I run the same query above in parallel, every additional query seems to add roughly 30 seconds to the amount of time the queries will take to finish. e.g. single query finishes in 60 seconds, 2 in parallel 90 seconds, 4 in parallel ~150 seconds, 10 concurrent queries will take ~330 seconds for all to complete. sar/mpstat on the 389ds instance shows that as I increase the number of concurrent queries cpu %usr utilization on the 389ds increases while %sys drops. expected I'm guessing... I'm trying to rule out whether I have inadequate indexing or whether some other tunable might improve concurrent queries of what is an admittedly large query, and hoping the community might be able to validate that yes, your query is large, if you insist on running this on 389ds you should plan on having 389ds run on significant hardware resources. Thank you for your time, Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Re: parentid index mismatch after replica initialization causes one-level search to return no entries

2026-05-28T01:16:19.370-07:00

On 5/28/26 1:54 AM, 박성호 via 389-users wrote:

Hello 389-ds users,

We are investigating a reproducible issue during FreeIPA/IdM replica installation.

After initial replication completes, the replica target contains the expected LDAP entries, but one-level searches under cn=masters return no entries. Subtree searches under the same base return the expected entries.

On the replica target:

ldapsearch -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" -s one dn

=> returns no entries

ldapsearch -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" -s sub dn

=> returns the expected master and service entries

At the same time, 389-ds logs the following error:

Backend 'userRoot': MISMATCH - parentid index has integerOrderingMatch configured, but on-disk data uses lexicographic ordering. This will cause searches to return incorrect or incomplete results. Please reindex the parentid attribute: dsconf <instance> backend index reindex --attr parentid userRoot

The issue was reproduced in both cases:

1. Source 389-ds-base 1.4.3.39-23 -> Replica 389-ds-base 1.4.3.39-23

2. Replica 389-ds-base 1.4.3.39-23 -> Replica 389-ds-base 2.8.0-6

The index configuration differs between the original source and the replicas.

Source server:

parentid index has no nsMatchingRule.

Replica servers:

parentid index has:

nsMatchingRule: integerOrderingMatch

The error message comes this mismatch between the configure MR and the effective order in parentid index db.
Did you upgraded the replica, so the nsMatchingRule is a leftover from previous install ?

I suggest to remove this matching rule and reindex with the command that is in the error log.

regards

Running a userRoot parentid reindex on the replica target restores the one-level search immediately. However, in the FreeIPA installer flow, this happens after ipa-replica-install has already failed.

Question:

Why does the replica target build or retain parentid on-disk index data using lexicographic ordering when the configured parentid index expects integerOrderingMatch? Is this expected after a total initialization from an older index definition, or should the replica initialization rebuild parentid using the target-side matching rule?

Is there a supported way to force or validate parentid index consistency immediately after total initialization and before upper-layer applications rely on one-level searches?

Please refer to the final inquiry sent to the FreeIPA users mailing list for additional technical details and follow-up discussion.

Thanks,

Seongho Park

보낸 사람: Rob Crittenden <rcritten@redhat.com>
보낸 날짜: 2026년 5월 28일 목요일 오전 3:55
받는 사람: FreeIPA users list <freeipa-users@lists.fedorahosted.org>; Florence Blanc-Renaud <flo@redhat.com>
참조: 이철구 <cgulee@lgcns.com>; 박성호 <seongho.park@lgcns.com>
제목: Re: [Freeipa-users] Re: FreeIPA replica install fails after initial replication: one-level search under cn=masters returns 0 until userRoot reindex

[rcritten@redhat.com 전자 메일을 받지 않는 경우가 많습니다. https://aka.ms/LearnAboutSenderIdentification ]에서 중요한 이유 알아보기

박성호 via FreeIPA-users wrote:
> Hello FreeIPA users,
>
> Is there anyone who can help with the following?
> The same error log was confirmed in both of the below cases.
>
> *Error Logs From (/var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors)*
> /var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors:[27/May/2026:11:10:31.315009288
> +0000] - ERR - ldbm_instance_check_index_config - Backend 'userRoot':
> MISMATCH - parentid index has integerOrderingMatch configured, but
> on-disk data uses lexicographic ordering. This will cause searches to
> return incorrect or incomplete results. Please reindex the parentid
> attribute: dsconf <instance> backend index reindex --attr parentid userRoot
>
>   *
>     Source server #1 (389-ds-base-1.4.3.39-23) => Replica server #1
>     (389-ds-base-1.4.3.39-23)
>   *
>     Replica server #1 (389-ds-base-1.4.3.39-23) => Replica server #2
>     (389-ds-base-2.8.0-6)
>
>
> *Our source server information*
> [root@xxxx ~]# dsconf "$INST" backend index get userRoot --attr parentid
> dn: cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: parentid
> nsIndexType: eq
> nsSystemIndex: true
> objectClass: top
> objectClass: nsIndex
>
> *Our replica server #1 information*
> [root@xxxx ~]# dsconf "$INST" backend index get userRoot --attr parentid
> dn: cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: parentid
> nsIndexType: eq
> nsMatchingRule: integerOrderingMatch
> nsSystemIndex: true
> objectClass: top
> objectClass: nsIndex
>
> *Our replica server #2 information*
> [root@xxxx ~]# dsconf "$INST" backend index get userRoot --attr parentid
> dn: cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: parentid
> nsIndexType: eq
> nsMatchingRule: integerOrderingMatch
> nsSystemIndex: true
> objectClass: top
> objectClass: nsIndex
>
> We found a workaround, but we are curious about the underlying reason
> why we need to perform a reindex.
>
> Thanks,
> Seongho Park
>
> ------------------------------------------------------------------------
> *보낸 사람:* 박성호 <seongho.park@lgcns.com>
> *보낸 날짜:* 2026년 5월 26일 화요일 오후 11:33
> *받는 사람:* Florence Blanc-Renaud <flo@redhat.com>; FreeIPA users list
> <freeipa-users@lists.fedorahosted.org>
> *참조:* 이철구 <cgulee@lgcns.com>
> *제목:* Re: [Freeipa-users] FreeIPA replica install fails after initial
> replication: one-level search under cn=masters returns 0 until userRoot
> reindex
>
> Hello Flo!
> Thank you for checking this quickly.
>
> Are you saying that I need to upgrade the source server's 389-ds version?
> I'm not entirely sure yet, but it looks higher than the version you
> mentioned.
>
>     - on 8.10: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A3126&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373262857%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2F6pMM8M8Cgi246yf3tPmbrJ%2FsMBCAndhwnj81wTJo6w%3D&reserved=0 with
>     389-ds-base-1.4.3.39-22.module+el8.10.0+24000+b6bfdf3f
>
> Currently, there are restrictions on checking the contents of
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F7135993&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373293970%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w0HudefEfnMp0tIIGwPiiUgxVRVUBBSuGypCvc%2FW7xk%3D&reserved=0,
> so additional verification will be available tomorrow. Below are the
> details of the version currently in use.
> *
> *
> *Our source server information*
>
>   *
>     Rocky Linux 8.8 (Green Obsidian)
>   *
>     ipa-server-4.9.13-21.module+el8.10.0+40089+03bf3c1f.x86_64
>   *
>     ipa-client-4.9.13-21.module+el8.10.0+40089+03bf3c1f.x86_64
>   *
>     ipa-server-dns-4.9.13-21.module+el8.10.0+40089+03bf3c1f.noarch
>   *
>     ipa-server-trust-ad-4.9.13-21.module+el8.10.0+40089+03bf3c1f.x86_64
>   *
>     389-ds-base-1.4.3.39-23.module+el8.10.0+40135+69dd2a79.x86_64
>   *
>     389-ds-base-libs-1.4.3.39-23.module+el8.10.0+40135+69dd2a79.x86_64
>
>
> *Our replica server #1 information*
>
>   *
>     Red Hat Enterprise Linux 8.10 (Ootpa)
>   *
>     ipa-server-4.9.13-21.module+el8.10.0+23944+84561300.x86_64
>   *
>     ipa-client-4.9.13-21.module+el8.10.0+23944+84561300.x86_64
>   *
>     ipa-server-dns-4.9.13-21.module+el8.10.0+23944+84561300.noarch
>   *
>     ipa-server-trust-ad-4.9.13-21.module+el8.10.0+23944+84561300.x86_64
>   *
>     389-ds-base-1.4.3.39-23.module+el8.10.0+24085+b368a310.x86_64
>   *
>     389-ds-base-libs-1.4.3.39-23.module+el8.10.0+24085+b368a310.x86_64
>
>
> *Our replica server #2 information*
>
>   *
>     Red Hat Enterprise Linux 9.8 (Plow)
>   *
>     ipa-server-4.13.1-3.el9_8.2.x86_64
>   *
>     ipa-client-4.13.1-3.el9_8.2.x86_64
>   *
>     ipa-server-dns-4.13.1-3.el9_8.2.noarch
>   *
>     package ipa-server-trust-ad is not installed
>   *
>     389-ds-base-2.8.0-6.el9_8.x86_64
>   *
>     389-ds-base-libs-2.8.0-6.el9_8.x86_64

This is really more a question for the 389-ds team. They sometimes pop
in here so someone might answer, but you may want to cross-post this to
the 389-users list to be sure they see it.

The parentid index is created by 389-ds directly and not by IPA.

rob

> ------------------------------------------------------------------------
> *보낸 사람:* Florence Blanc-Renaud <flo@redhat.com>
> *보낸 날짜:* 2026년 5월 26일 화요일 오후 10:04
> *받는 사람:* FreeIPA users list <freeipa-users@lists.fedorahosted.org>
> *참조:* 이철구 <cgulee@lgcns.com>; 박성호 <seongho.park@lgcns.com>
> *제목:* Re: [Freeipa-users] FreeIPA replica install fails after initial
> replication: one-level search under cn=masters returns 0 until userRoot
> reindex
>
>
> flo@redhat.com에게서 전자 메일을 받지 못하는 경우가 많습니다. 이 문제가
> 중요한 이유 <https://aka.ms/LearnAboutSenderIdentification>
>
>
> Hi,
>
> This is a known issue with 389-ds, you can get more information at
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F7135993&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373318052%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rkFIhgxu1FGGyFoL75V5PgEmg54yIJzZ7LJJJAcS9lM%3D&reserved=0
>
> The fixes are available:
> - on 8.10:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A3126&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373340316%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zTDmpz8H3uR%2BsSDGe5J7Qx937bLg2gNwIKysbgRpKTQ%3D&reserved=0 with 389-ds-base-1.4.3.39-22.module+el8.10.0+24000+b6bfdf3f
> - on 9.7: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHSA-2026%3A3189&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373359894%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qJbhA4z4%2BC2pt4U1H8CMs2wfMRt2hLq5jMlRs8Y%2BYlI%3D&reserved=0 with
> 389-ds-base-2.7.0-10.el9_7
> - on 9.8: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A18956&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373379524%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v94KwvhN7yrwy9a3148ZxseUfsE65j8a8V1jZRk%2Fnng%3D&reserved=0 with
> 389-ds-base-2.8.0-6.el9_8
> - on 10.1:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHSA-2026%3A3208&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373401060%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JQYIzOSDrJYf%2Bd2ivTMQPJVmqRGKMqY6M61eY7KciUE%3D&reserved=0 with 389-ds-base-3.1.3-7.el10_1.
> - on 10.2: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A18575&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373422008%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UrqWJfvLu%2Bi0EFhRrfL5%2BBOppnmfVkPhe5BV%2FsL%2BFys%3D&reserved=0 with
> 389-ds-base-3.2.0-6.el10_2
>
> HTH,
> flo
>
> On Tue, May 26, 2026 at 12:11 PM 박성호 via FreeIPA-users
> <freeipa-users@lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>
>     Hi FreeIPA users,
>
>     I am investigating a reproducible FreeIPA/IdM replica installation
>     failure.
>
>     Summary:
>     After initial replication succeeds during ipa-replica-install, local
>     LDAP subtree searches under cn=masters work, but one-level searches
>     under the same DN return zero entries. This causes ipa server-find
>     --servrole="IPA master", ipa server-role-find --include-master, and
>     dns_update_system_records during replica installation to fail with:
>
>       no matching entry found
>
>     A full userRoot reindex immediately fixes the issue.
>
>     Environment:
>     - Existing master: RHEL 8.10, FreeIPA 4.9.x
>     - New replica test 1: RHEL 8.10, FreeIPA 4.9.x
>     - New replica test 2: RHEL 9.x, FreeIPA 4.13.x
>     - Domain: idm.example.com <https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fidm.example.com%2F&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373444724%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=I3h0eyB161Eg8gWjpzjJ2QzilKOZeXha3Q6fCgsXUUU%3D&reserved=0>
>     - Realm: IDM.EXAMPLE.COM <https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fidm.example.com%2F&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373464870%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UI2%2F643yBENt%2F7nfdBi1l3320g9raftRHNZH%2FO%2ByEg0%3D&reserved=0>
>
>     The same behavior is reproduced on both RHEL8 and RHEL9 replicas.
>
>     Failure path from ipareplica-install.log:
>
>       ipa-replica-install
>         -> dns_update_system_records()
>         -> server_find(servrole='IPA master')
>         -> server_role_find(role_servrole='IPA master',
>     status='enabled', include_master=True)
>         -> servroles._fill_in_absent_masters()
>         -> ldap2.get_entries()
>         -> EmptyResult: no matching entry found
>
>     Before reindex, on the new replica:
>
>       ldapsearch -H ldapi://%2Frun%2Fslapd-IDM-EXAMPLE-COM.socket -Y
>     GSSAPI -LLL \
>         -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" \
>         -s one "(objectClass=*)" dn cn objectClass
>
>     returns no entries.
>
>     But subtree search works:
>
>       ldapsearch -H ldapi://%2Frun%2Fslapd-IDM-EXAMPLE-COM.socket -Y
>     GSSAPI -LLL \
>         -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" \
>         -s sub "(objectClass=ipaConfigObject)" dn cn objectClass
>
>     returns the expected master and service entries.
>
>     After running:
>
>       dsconf IDM-EXAMPLE-COM backend index reindex --wait userRoot
>
>     the one-level search works, and ipa server-find / ipa
>     dns-update-system-records work.
>
>     Things already checked:
>     - This does not appear to be specific to a RHEL8 or RHEL9 replica
>     target.
>     - The replicated data appears to exist locally; the issue seems
>     specific to one-level search/index behavior under cn=masters.
>     - A full userRoot reindex immediately makes the same one-level
>     search and FreeIPA commands work.
>
>     Question:
>     Is this a known 389-ds / FreeIPA replica initialization issue where
>     the local parent/one-level search index is incomplete immediately
>     after total init? Is there a supported way to force or verify index
>     consistency before ipa-replica-install reaches
>     dns_update_system_records?
>
>     Please let me know if this should be reported to 389-ds instead of
>     FreeIPA.
>
>     Thanks.
>
>
>     고객의소리열기
>     <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcppm.singlex.com%2Fpublic%2FpainpointDirects%2FC998%3FmediaSource%3DEMAIL&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373484115%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hsjsphHj1VXKWBu3wOYlm3ASQ2A9E%2FlonfpQ7tYIX%2Bs%3D&reserved=0>
>
>     ------------------------------------------------------------------------
>     상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지
>     정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수
>     로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주
>     시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다.
>     상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는
>     것은 금지되어 있습니다.(주)LG CNS.
>     This message and its attachments may contain confidential
>     information, and they are intended to be viewed or used by only the
>     individuals specified in the message. If you have received this
>     message in an error from the sender, please contact the sender
>     immediately to notify the error and delete all of the message and
>     its copies. It is prohibited to view, use, make public and/or
>     distribute part or whole of this message without written permission.
>     --
>     _______________________________________________
>     FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>     <mailto:freeipa-users@lists.fedorahosted.org>
>     To unsubscribe send an email to
>     freeipa-users-leave@lists.fedorahosted.org
>     <mailto:freeipa-users-leave@lists.fedorahosted.org>
>     Fedora Code of Conduct:
>     https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373504038%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IOJUFt4zqwKuTlpE8LbiX%2BkdB67CYaL2fRUhDxDay4U%3D&reserved=0
>     List Guidelines: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373523224%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w%2FD4THwBp4NTfmF%2BMfEiKdmfu7lcCE4%2BQkGLW1MMTtI%3D&reserved=0
>     List Archives:
>     https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.org&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373541933%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hAa3x6%2F4K0DboQQjEOQlMztE%2Bc4NWC8dla9p4bO6bDo%3D&reserved=0
>     Do not reply to spam, report it:
>     https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforge.fedoraproject.org%2Finfra%2Ftickets%2Fissues%2Fnew&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373564065%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FhzXocFM4KEG4Fp1GzDMBIZVBbyffN6Vt999UiFY2ns%3D&reserved=0
>
>
>
> 고객의소리열기
> <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcppm.singlex.com%2Fpublic%2FpainpointDirects%2FC998%3FmediaSource%3DEMAIL&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373582605%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vLy6f9yqW7yXvSO0IlzDQHvgf%2BOqfzBE4p0w81oB3K4%3D&reserved=0>
>
> ------------------------------------------------------------------------
> 상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된
> 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여
> 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시
> 지와 모든 사본을 폐기해 주시기 바랍니다.
> 상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은
> 금지되어 있습니다.(주)LG CNS.
> This message and its attachments may contain confidential information,
> and they are intended to be viewed or used by only the individuals
> specified in the message. If you have received this message in an error
> from the sender, please contact the sender immediately to notify the
> error and delete all of the message and its copies. It is prohibited to
> view, use, make public and/or distribute part or whole of this message
> without written permission.
>

상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다.
상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은 금지되어 있습니다.(주)LG CNS.
This message and its attachments may contain confidential information, and they are intended to be viewed or used by only the individuals specified in the message. If you have received this message in an error from the sender, please contact the sender immediately to notify the error and delete all of the message and its copies. It is prohibited to view, use, make public and/or distribute part or whole of this message without written permission.

[389-users] parentid index mismatch after replica initialization causes one-level search to return no entries

2026-05-27T16:55:07.128-07:00

Hello 389-ds users,

We are investigating a reproducible issue during FreeIPA/IdM replica installation.

After initial replication completes, the replica target contains the expected LDAP entries, but one-level searches under cn=masters return no entries. Subtree searches under the same base return the expected entries.

On the replica target:

ldapsearch -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" -s one dn

=> returns no entries

ldapsearch -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" -s sub dn

=> returns the expected master and service entries

At the same time, 389-ds logs the following error:

Backend 'userRoot': MISMATCH - parentid index has integerOrderingMatch configured, but on-disk data uses lexicographic ordering. This will cause searches to return incorrect or incomplete results. Please reindex the parentid attribute: dsconf <instance> backend index reindex --attr parentid userRoot

The issue was reproduced in both cases:

1. Source 389-ds-base 1.4.3.39-23 -> Replica 389-ds-base 1.4.3.39-23

2. Replica 389-ds-base 1.4.3.39-23 -> Replica 389-ds-base 2.8.0-6

The index configuration differs between the original source and the replicas.

Source server:

parentid index has no nsMatchingRule.

Replica servers:

parentid index has:

nsMatchingRule: integerOrderingMatch

Running a userRoot parentid reindex on the replica target restores the one-level search immediately. However, in the FreeIPA installer flow, this happens after ipa-replica-install has already failed.

Question:

Why does the replica target build or retain parentid on-disk index data using lexicographic ordering when the configured parentid index expects integerOrderingMatch? Is this expected after a total initialization from an older index definition, or should the replica initialization rebuild parentid using the target-side matching rule?

Is there a supported way to force or validate parentid index consistency immediately after total initialization and before upper-layer applications rely on one-level searches?

Please refer to the final inquiry sent to the FreeIPA users mailing list for additional technical details and follow-up discussion.

Thanks,

Seongho Park

보낸 사람: Rob Crittenden <rcritten@redhat.com>
보낸 날짜: 2026년 5월 28일 목요일 오전 3:55
받는 사람: FreeIPA users list <freeipa-users@lists.fedorahosted.org>; Florence Blanc-Renaud <flo@redhat.com>
참조: 이철구 <cgulee@lgcns.com>; 박성호 <seongho.park@lgcns.com>
제목: Re: [Freeipa-users] Re: FreeIPA replica install fails after initial replication: one-level search under cn=masters returns 0 until userRoot reindex

[rcritten@redhat.com 전자 메일을 받지 않는 경우가 많습니다. https://aka.ms/LearnAboutSenderIdentification ]에서 중요한 이유 알아보기

박성호 via FreeIPA-users wrote:
> Hello FreeIPA users,
>
> Is there anyone who can help with the following?
> The same error log was confirmed in both of the below cases.
>
> *Error Logs From (/var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors)*
> /var/log/dirsrv/slapd-IDM-EXAMPLE-COM/errors:[27/May/2026:11:10:31.315009288
> +0000] - ERR - ldbm_instance_check_index_config - Backend 'userRoot':
> MISMATCH - parentid index has integerOrderingMatch configured, but
> on-disk data uses lexicographic ordering. This will cause searches to
> return incorrect or incomplete results. Please reindex the parentid
> attribute: dsconf <instance> backend index reindex --attr parentid userRoot
>
>   *
>     Source server #1 (389-ds-base-1.4.3.39-23) => Replica server #1
>     (389-ds-base-1.4.3.39-23)
>   *
>     Replica server #1 (389-ds-base-1.4.3.39-23) => Replica server #2
>     (389-ds-base-2.8.0-6)
>
>
> *Our source server information*
> [root@xxxx ~]# dsconf "$INST" backend index get userRoot --attr parentid
> dn: cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: parentid
> nsIndexType: eq
> nsSystemIndex: true
> objectClass: top
> objectClass: nsIndex
>
> *Our replica server #1 information*
> [root@xxxx ~]# dsconf "$INST" backend index get userRoot --attr parentid
> dn: cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: parentid
> nsIndexType: eq
> nsMatchingRule: integerOrderingMatch
> nsSystemIndex: true
> objectClass: top
> objectClass: nsIndex
>
> *Our replica server #2 information*
> [root@xxxx ~]# dsconf "$INST" backend index get userRoot --attr parentid
> dn: cn=parentid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> cn: parentid
> nsIndexType: eq
> nsMatchingRule: integerOrderingMatch
> nsSystemIndex: true
> objectClass: top
> objectClass: nsIndex
>
> We found a workaround, but we are curious about the underlying reason
> why we need to perform a reindex.
>
> Thanks,
> Seongho Park
>
> ------------------------------------------------------------------------
> *보낸 사람:* 박성호 <seongho.park@lgcns.com>
> *보낸 날짜:* 2026년 5월 26일 화요일 오후 11:33
> *받는 사람:* Florence Blanc-Renaud <flo@redhat.com>; FreeIPA users list
> <freeipa-users@lists.fedorahosted.org>
> *참조:* 이철구 <cgulee@lgcns.com>
> *제목:* Re: [Freeipa-users] FreeIPA replica install fails after initial
> replication: one-level search under cn=masters returns 0 until userRoot
> reindex
>
> Hello Flo!
> Thank you for checking this quickly.
>
> Are you saying that I need to upgrade the source server's 389-ds version?
> I'm not entirely sure yet, but it looks higher than the version you
> mentioned.
>
>     - on 8.10: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A3126&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373262857%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2F6pMM8M8Cgi246yf3tPmbrJ%2FsMBCAndhwnj81wTJo6w%3D&reserved=0 with
>     389-ds-base-1.4.3.39-22.module+el8.10.0+24000+b6bfdf3f
>
> Currently, there are restrictions on checking the contents of
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F7135993&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373293970%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w0HudefEfnMp0tIIGwPiiUgxVRVUBBSuGypCvc%2FW7xk%3D&reserved=0,
> so additional verification will be available tomorrow. Below are the
> details of the version currently in use.
> *
> *
> *Our source server information*
>
>   *
>     Rocky Linux 8.8 (Green Obsidian)
>   *
>     ipa-server-4.9.13-21.module+el8.10.0+40089+03bf3c1f.x86_64
>   *
>     ipa-client-4.9.13-21.module+el8.10.0+40089+03bf3c1f.x86_64
>   *
>     ipa-server-dns-4.9.13-21.module+el8.10.0+40089+03bf3c1f.noarch
>   *
>     ipa-server-trust-ad-4.9.13-21.module+el8.10.0+40089+03bf3c1f.x86_64
>   *
>     389-ds-base-1.4.3.39-23.module+el8.10.0+40135+69dd2a79.x86_64
>   *
>     389-ds-base-libs-1.4.3.39-23.module+el8.10.0+40135+69dd2a79.x86_64
>
>
> *Our replica server #1 information*
>
>   *
>     Red Hat Enterprise Linux 8.10 (Ootpa)
>   *
>     ipa-server-4.9.13-21.module+el8.10.0+23944+84561300.x86_64
>   *
>     ipa-client-4.9.13-21.module+el8.10.0+23944+84561300.x86_64
>   *
>     ipa-server-dns-4.9.13-21.module+el8.10.0+23944+84561300.noarch
>   *
>     ipa-server-trust-ad-4.9.13-21.module+el8.10.0+23944+84561300.x86_64
>   *
>     389-ds-base-1.4.3.39-23.module+el8.10.0+24085+b368a310.x86_64
>   *
>     389-ds-base-libs-1.4.3.39-23.module+el8.10.0+24085+b368a310.x86_64
>
>
> *Our replica server #2 information*
>
>   *
>     Red Hat Enterprise Linux 9.8 (Plow)
>   *
>     ipa-server-4.13.1-3.el9_8.2.x86_64
>   *
>     ipa-client-4.13.1-3.el9_8.2.x86_64
>   *
>     ipa-server-dns-4.13.1-3.el9_8.2.noarch
>   *
>     package ipa-server-trust-ad is not installed
>   *
>     389-ds-base-2.8.0-6.el9_8.x86_64
>   *
>     389-ds-base-libs-2.8.0-6.el9_8.x86_64

This is really more a question for the 389-ds team. They sometimes pop
in here so someone might answer, but you may want to cross-post this to
the 389-users list to be sure they see it.

The parentid index is created by 389-ds directly and not by IPA.

rob

> ------------------------------------------------------------------------
> *보낸 사람:* Florence Blanc-Renaud <flo@redhat.com>
> *보낸 날짜:* 2026년 5월 26일 화요일 오후 10:04
> *받는 사람:* FreeIPA users list <freeipa-users@lists.fedorahosted.org>
> *참조:* 이철구 <cgulee@lgcns.com>; 박성호 <seongho.park@lgcns.com>
> *제목:* Re: [Freeipa-users] FreeIPA replica install fails after initial
> replication: one-level search under cn=masters returns 0 until userRoot
> reindex
>
>
> flo@redhat.com에게서 전자 메일을 받지 못하는 경우가 많습니다. 이 문제가
> 중요한 이유 <https://aka.ms/LearnAboutSenderIdentification>
>
>
> Hi,
>
> This is a known issue with 389-ds, you can get more information at
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F7135993&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373318052%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rkFIhgxu1FGGyFoL75V5PgEmg54yIJzZ7LJJJAcS9lM%3D&reserved=0
>
> The fixes are available:
> - on 8.10:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A3126&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373340316%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zTDmpz8H3uR%2BsSDGe5J7Qx937bLg2gNwIKysbgRpKTQ%3D&reserved=0 with 389-ds-base-1.4.3.39-22.module+el8.10.0+24000+b6bfdf3f
> - on 9.7: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHSA-2026%3A3189&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373359894%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qJbhA4z4%2BC2pt4U1H8CMs2wfMRt2hLq5jMlRs8Y%2BYlI%3D&reserved=0 with
> 389-ds-base-2.7.0-10.el9_7
> - on 9.8: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A18956&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373379524%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v94KwvhN7yrwy9a3148ZxseUfsE65j8a8V1jZRk%2Fnng%3D&reserved=0 with
> 389-ds-base-2.8.0-6.el9_8
> - on 10.1:
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHSA-2026%3A3208&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373401060%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JQYIzOSDrJYf%2Bd2ivTMQPJVmqRGKMqY6M61eY7KciUE%3D&reserved=0 with 389-ds-base-3.1.3-7.el10_1.
> - on 10.2: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Ferrata%2FRHBA-2026%3A18575&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373422008%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UrqWJfvLu%2Bi0EFhRrfL5%2BBOppnmfVkPhe5BV%2FsL%2BFys%3D&reserved=0 with
> 389-ds-base-3.2.0-6.el10_2
>
> HTH,
> flo
>
> On Tue, May 26, 2026 at 12:11 PM 박성호 via FreeIPA-users
> <freeipa-users@lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>
>     Hi FreeIPA users,
>
>     I am investigating a reproducible FreeIPA/IdM replica installation
>     failure.
>
>     Summary:
>     After initial replication succeeds during ipa-replica-install, local
>     LDAP subtree searches under cn=masters work, but one-level searches
>     under the same DN return zero entries. This causes ipa server-find
>     --servrole="IPA master", ipa server-role-find --include-master, and
>     dns_update_system_records during replica installation to fail with:
>
>       no matching entry found
>
>     A full userRoot reindex immediately fixes the issue.
>
>     Environment:
>     - Existing master: RHEL 8.10, FreeIPA 4.9.x
>     - New replica test 1: RHEL 8.10, FreeIPA 4.9.x
>     - New replica test 2: RHEL 9.x, FreeIPA 4.13.x
>     - Domain: idm.example.com <https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fidm.example.com%2F&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373444724%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=I3h0eyB161Eg8gWjpzjJ2QzilKOZeXha3Q6fCgsXUUU%3D&reserved=0>
>     - Realm: IDM.EXAMPLE.COM <https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fidm.example.com%2F&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373464870%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UI2%2F643yBENt%2F7nfdBi1l3320g9raftRHNZH%2FO%2ByEg0%3D&reserved=0>
>
>     The same behavior is reproduced on both RHEL8 and RHEL9 replicas.
>
>     Failure path from ipareplica-install.log:
>
>       ipa-replica-install
>         -> dns_update_system_records()
>         -> server_find(servrole='IPA master')
>         -> server_role_find(role_servrole='IPA master',
>     status='enabled', include_master=True)
>         -> servroles._fill_in_absent_masters()
>         -> ldap2.get_entries()
>         -> EmptyResult: no matching entry found
>
>     Before reindex, on the new replica:
>
>       ldapsearch -H ldapi://%2Frun%2Fslapd-IDM-EXAMPLE-COM.socket -Y
>     GSSAPI -LLL \
>         -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" \
>         -s one "(objectClass=*)" dn cn objectClass
>
>     returns no entries.
>
>     But subtree search works:
>
>       ldapsearch -H ldapi://%2Frun%2Fslapd-IDM-EXAMPLE-COM.socket -Y
>     GSSAPI -LLL \
>         -b "cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=com" \
>         -s sub "(objectClass=ipaConfigObject)" dn cn objectClass
>
>     returns the expected master and service entries.
>
>     After running:
>
>       dsconf IDM-EXAMPLE-COM backend index reindex --wait userRoot
>
>     the one-level search works, and ipa server-find / ipa
>     dns-update-system-records work.
>
>     Things already checked:
>     - This does not appear to be specific to a RHEL8 or RHEL9 replica
>     target.
>     - The replicated data appears to exist locally; the issue seems
>     specific to one-level search/index behavior under cn=masters.
>     - A full userRoot reindex immediately makes the same one-level
>     search and FreeIPA commands work.
>
>     Question:
>     Is this a known 389-ds / FreeIPA replica initialization issue where
>     the local parent/one-level search index is incomplete immediately
>     after total init? Is there a supported way to force or verify index
>     consistency before ipa-replica-install reaches
>     dns_update_system_records?
>
>     Please let me know if this should be reported to 389-ds instead of
>     FreeIPA.
>
>     Thanks.
>
>
>     고객의소리열기
>     <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcppm.singlex.com%2Fpublic%2FpainpointDirects%2FC998%3FmediaSource%3DEMAIL&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373484115%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hsjsphHj1VXKWBu3wOYlm3ASQ2A9E%2FlonfpQ7tYIX%2Bs%3D&reserved=0>
>
>     ------------------------------------------------------------------------
>     상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지
>     정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수
>     로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주
>     시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다.
>     상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는
>     것은 금지되어 있습니다.(주)LG CNS.
>     This message and its attachments may contain confidential
>     information, and they are intended to be viewed or used by only the
>     individuals specified in the message. If you have received this
>     message in an error from the sender, please contact the sender
>     immediately to notify the error and delete all of the message and
>     its copies. It is prohibited to view, use, make public and/or
>     distribute part or whole of this message without written permission.
>     --
>     _______________________________________________
>     FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>     <mailto:freeipa-users@lists.fedorahosted.org>
>     To unsubscribe send an email to
>     freeipa-users-leave@lists.fedorahosted.org
>     <mailto:freeipa-users-leave@lists.fedorahosted.org>
>     Fedora Code of Conduct:
>     https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373504038%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IOJUFt4zqwKuTlpE8LbiX%2BkdB67CYaL2fRUhDxDay4U%3D&reserved=0
>     List Guidelines: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373523224%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w%2FD4THwBp4NTfmF%2BMfEiKdmfu7lcCE4%2BQkGLW1MMTtI%3D&reserved=0
>     List Archives:
>     https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Ffreeipa-users%40lists.fedorahosted.org&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373541933%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hAa3x6%2F4K0DboQQjEOQlMztE%2Bc4NWC8dla9p4bO6bDo%3D&reserved=0
>     Do not reply to spam, report it:
>     https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforge.fedoraproject.org%2Finfra%2Ftickets%2Fissues%2Fnew&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373564065%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FhzXocFM4KEG4Fp1GzDMBIZVBbyffN6Vt999UiFY2ns%3D&reserved=0
>
>
>
> 고객의소리열기
> <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcppm.singlex.com%2Fpublic%2FpainpointDirects%2FC998%3FmediaSource%3DEMAIL&data=05%7C02%7Cseongho.park%40lgcns.com%7C145d613c83534753f32608debc218765%7Cfab2d60fe6144f9db2ad9fb1397f2efe%7C0%7C0%7C639155049373582605%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vLy6f9yqW7yXvSO0IlzDQHvgf%2BOqfzBE4p0w81oB3K4%3D&reserved=0>
>
> ------------------------------------------------------------------------
> 상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된
> 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여
> 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시
> 지와 모든 사본을 폐기해 주시기 바랍니다.
> 상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은
> 금지되어 있습니다.(주)LG CNS.
> This message and its attachments may contain confidential information,
> and they are intended to be viewed or used by only the individuals
> specified in the message. If you have received this message in an error
> from the sender, please contact the sender immediately to notify the
> error and delete all of the message and its copies. It is prohibited to
> view, use, make public and/or distribute part or whole of this message
> without written permission.
>

[Test-Announce] Fedora 45 Rawhide 20260527.n.1 nightly compose nominated for testing

2026-05-27T14:01:20.345-07:00

Announcing the creation of a new nightly release validation test event for Fedora 45 Rawhide 20260527.n.1. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20260523.n.0: anaconda-45.4-1.fc45.src, 20260527.n.1: anaconda-45.5-1.fc45.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/45 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260527.n.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260527.n.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260527.n.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260527.n.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260527.n.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260527.n.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260527.n.1_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://forge.fedoraproject.org/quality/relvalconsumer -- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Test-Announce] 2026-05-25 @ 15:00 UTC - Fedora Quality Meeting

2026-05-24T09:35:09.421-07:00

# Fedora Quality Assurance Meeting # Date: 2026-05-25 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Greetings testers! It's meeting time again. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+quality+meeting&iso=20260525T15&p1=1440&ah=1 If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 45 status 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net -- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Test-Announce] Fedora 45 Rawhide 20260523.n.0 nightly compose nominated for testing

2026-05-22T23:40:12.148-07:00

Announcing the creation of a new nightly release validation test event for Fedora 45 Rawhide 20260523.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pykickstart - 20260520.n.0: pykickstart-3.72-1.fc45.src, 20260523.n.0: pykickstart-3.73-1.fc45.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/45 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260523.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260523.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260523.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260523.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260523.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260523.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260523.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://forge.fedoraproject.org/quality/relvalconsumer -- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

Re: Invitation to participate in our academic survey on "Perception of providing security contact information for domains"

2026-05-21T18:32:19.923-07:00

On Thu, May 21, 2026 at 10:46:49AM -0400, Paul Wouters wrote: > Without commenting on the usefulness of security.txt, I just wanted to > point out fedoraproject seems to publish one not on the main domain but on > the admin subdomain: > > https://admin.fedoraproject.org/.well-known/security.txt Yes, we do. > RFC9116 seems to believe it should be available per service name and that > one on the main domain (or on on www.) would not cover anything else (eg > sub domains). > > I don't think this is only available on admin.fedoraproject.org by design, > but I could be wrong. The situation does however match my personal (not > endorsed by Fedora) feelings about security.txt in general :) Yeah. I don't know that we want to produce a security.txt for every subdomain we have, especially when they would likely be all the same contents. > Note when you google for "fedora security" you do get to > https://fedoraproject.org/security/ that also has contact information at > the bottom. > > Paul, not speaking for the Fedora Project here kevin, speaking for fedora infrastructure, but agreeing with Paul. ;) kevin -- > > > > > > > > On Wed, May 20, 2026 at 7:32 PM AIFB-security-txt-study < > security-txt-study@aifb.kit.edu> wrote: > > > Greetings, > > > > we are researchers from the university in Karlsruhe, Germany, the > > Karlsruhe Institute of Technology (KIT). We are contacting you today, > > because by analyzing the most visited domains [1] we found that your domain > > fedoraproject.org is seemingly not providing contact information for a > > security contact via a security.txt [2]. > > > > As part of our research project on vulnerability notifications [3] we are > > investigating why domain owners do not provide a security.txt. We aim to > > identify reasons for non-adoption, as well as reasons that hinder or delay > > adoption. In case you already provide security contact information in other > > forms, we also highly appreciate your response. > > > > Your perspective is very valuable to us, as it helps us pinpoint specific > > issues that we need to take into account when developing recommendations > > and awareness materials. > > > > To allow you to respond anonymously, we have created an online survey. The > > survey will take about 5 minutes to complete. The survey can be accessed > > via the following link: https://soscisurvey.scc.kit.edu/securitytxt > > > > Alternatively, we also appreciate your feedback as response to our email. > > Please find the questions below. > > > > Thank you very much for your time and support! > > > > Best regards, > > Anne Hennig > > > > [1] https://tranco-list.eu/ > > [2] https://securitytxt.org > > [3] https://s.kit.edu/vulnerability-notifications > > > > > > QUESTIONS > > 1. Have you ever heard about security.txt before? [Yes / No] > > 1.1 If yes: On what occasion did you hear about security.txt? > > 2. Have you already implemented or are you planning to implement > > security.txt for your domain? [Yes / No / Already implemented / I provide > > contact information in other forms (please specify)] > > 2.1 If in planning: What is your timeline for the implementation? Why > > did you decide to implement a security.txt? What are your greatest > > concerns? What benefits do you expect? > > 2.2 If no implementation planned: Why did you decide not to implement > > a security.txt? What are your greatest concerns? What would motivate you to > > implement a security.txt? Can you think of potential benefits when > > implementing a security.txt? > > 2.3 If already implemented: Why did you decide to implement a > > security.txt? What were your greatest concerns before implementation? What > > benefits did you expect? What are your current experiences? > > 3. Demographic information: > > 3.1 In which country is your organization mainly located? > > 3.2 What is your role with regard to the domain we contacted? > > 3.3 What sector does your organization of business belong to? > > 3.4 How many employees does your organization or business have? [1-9, > > 10-49, 50-249, 250-499, 500-999, 1000-4.999, 5.000 or more] > > > > ----------- > > > > Legal Disclaimer: > > The legal basis for the processing of your personal data is Article > > 6(1)(e) in conjunction with Article 6(3) of the General Data Protection > > Regulation (GDPR) and Section 13(1) of the Baden-Württemberg State Data > > Protection Act. > > > > In accordance with Articles 13 and 14 of the GDPR, we hereby inform you > > that we have processed your contact information for scientific research > > purposes without having obtained your prior consent. The processing is > > carried out exclusively for the purpose of inviting you to participate in > > the aforementioned study. You have the right at any time to have your > > contact information deleted and to object to further contact. > > > > We will not contact you again for the purpose of this study. Your name and > > email address, will be stored separately from your responses. It is not > > possible to identify you personally from this data. We will delete your > > contact information at the end of the project. > > > > ----------- > > > > Karlsruhe Institute of Technology (KIT) > > Institute of Applied Informatics and Formal Description Methods (AIFB) > > Research Group Security • Usability • Society (SECUSO) > > > > Anne Hennig, M.A. > > Research Associate > > > > E-Mail: anne.hennig@kit.edu > > > > Registered Office > > Kaiserstraße 12, 76131 Karlsruhe > > > > KIT – The University in the Helmholtz-Association > > -- _______________________________________________ websites mailing list -- websites@lists.fedoraproject.org To unsubscribe send an email to websites-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/websites@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Test-Announce] Fedora 45 Rawhide 20260520.n.0 nightly compose nominated for testing

2026-05-19T23:40:46.430-07:00

Announcing the creation of a new nightly release validation test event for Fedora 45 Rawhide 20260520.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20260511.n.0: anaconda-45.2-1.fc45.src, 20260520.n.0: anaconda-45.4-1.fc45.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/45 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260520.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260520.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260520.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260520.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260520.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260520.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260520.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://forge.fedoraproject.org/quality/relvalconsumer -- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[389-users] Docker, dscontainer, and production version(s)

2026-05-18T09:04:28.108-07:00

Hello, I could use a little advice before I go down too many more rabbit holes: We are looking to run 389 in Docker and we prefer a stable version that will be supported for a while. We have a large user base and and value stability over new features. Is there a maintained docker image for, ideally, 389 versions 2.6 or 2.7? I'm open to 2.8 or 3.0 but worry they are a bit too bleeding edge for use in a large-ish environment. 2.4 worked well for us when we last tested but looks to now but deprecated. I'm happy to diy but from my testing and reading 2.6 and 2.7 dscontainer, at least in Alma Linux 9 as the base Docker image, seem to be buggy: the config directory is not correctly populated in the data directory. I am game for diy'ing a 2.8 or 3.0 Docker image if the consensus is that they are production ready but does dscontainer work in them and do you have a suggestion for what Docker operating system base image to use? I see 3.0, and maybe 2.8, can be enabled through copr in Alma 9 but don't want to get *too* exotic for production use. thank you! -morgan -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Test-Announce] Heroes of Fedora Quality for Fedora 44

2026-05-18T06:42:46.361-07:00

Hello, we'd like to highlight the top Fedora Quality contributors who helped us release Fedora 44. Please see the article here:

https://kparal.wordpress.com/2026/05/15/heroes-of-fedora-quality-for-fedora-44/

Our sincere thanks to everyone involved!

Kamil Paral (he/him/his)

Fedora QA