On 5/28/26 1:54 AM, 박성호 via 389-users wrote:
The error message comes this mismatch between the configure MR and the effective order in parentid index db.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-232. 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
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 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
