Description of problem: An integration test in IdM sets a server as hidden which basically makes the server invisible to clients. In practice it removes a couple of attribute values and inserts a new one. The test has a broken assumption based on the current behavior of ldif2db which is restoring the deleted values. Version-Release number of selected component (if applicable): 389-ds-base-1.4.3.28-3.module+el8.6.0+13706+e2f14737.x86_64 How reproducible: Every time Steps to Reproduce: 1. Install an IPA server. I installed with DNS with: ipa-server-install -a password -p password -r EXAMPLE.TEST -U --setup-dns --allow-zone-overlap --no-forwarders -N --auto-reverse --hostname ipa.example.test --ip-address 10.0.136.14 2. Install another IPA server: I did a two-step: ipa-client-install followed by ipa-replica-install --setup-ca 3. Make the replica hidden: ipa server-state --state hidden `hostname` 4. Back up the replica server: ipa-backup 5. Uninstall the replica: ipa-server-install --uninstall -U 6. Reset the hostname: hostname replica.example.test 7. Restore from backup: ipa-restore /var/lib/ipa/backup/<backup-dir> Actual results: I picked one service that is marked as hidden. This affects more than just the KDC service. # kinit admin # ldapsearch -LLL -Y GSSAPI -b cn=KDC,cn=replica.example.test,cn=masters,cn=ipa,cn=etc,dc=example,dc=test dn: cn=KDC,cn=replica.example.test,cn=masters,cn=ipa,cn=etc,dc=example,dc=test cn: KDC ipaConfigString: startOrder 10 ipaConfigString: configuredService ipaConfigString: kdcProxyEnabled ipaConfigString: pkinitEnabled ipaConfigString: enabledService ipaConfigString: hiddenService objectClass: nsContainer objectClass: ipaConfigObject objectClass: top Expected results: Basically the same minus enabledService and configuredService Additional info: To see the ldif: cd /var/lib/ipa/backup/<backup-dir> tar xf ipa-full.tar view EXAMPLE-TEST-userRoot.ldif The values are: # entry-id: 511 dn: cn=KDC,cn=replica.example.test,cn=masters,cn=ipa,cn=etc,dc=example,dc=test modifyTimestamp;adcsn-61fc62f5000000030003;vucsn-61fc62f5000000030003: 2022020 3231917Z modifiersName;adcsn-61fc62f5000000030002;vucsn-61fc62f5000000030002: uid=admin ,cn=users,cn=accounts,dc=example,dc=test objectClass;vucsn-61fc615d000000030000: nsContainer objectClass;vucsn-61fc615d000000030000: ipaConfigObject objectClass;vucsn-61fc615d000000030000: top cn;vucsn-61fc615d000000030000;mdcsn-61fc615d000000030000: KDC ipaConfigString;vucsn-61fc615d000000030000: startOrder 10 ipaConfigString;vucsn-61fc6174000000030000: kdcProxyEnabled ipaConfigString;vucsn-61fc6265000000030000: pkinitEnabled ipaConfigString;vucsn-61fc62f5000000030001: hiddenService ipaConfigString;vucsn-61fc615d000000030000;vdcsn-61fc628e000000030000;deleted: configuredService ipaConfigString;vucsn-61fc628e000000030001;vdcsn-61fc62f5000000030000;deleted: enabledService creatorsName;vucsn-61fc615d000000030000: cn=Directory Manager createTimestamp;vucsn-61fc615d000000030000: 20220203231229Z nsUniqueId: bdca4f10-854611ec-a1818257-054c1e7a entryUUID: 784dacd4-13a4-40e3-b74b-8724bdc1b74f
FYI: I have done a test export an ldif with replication data then adding above entry (after changing its DN) in the ldif and reimporting the entry ldapsearch -Q -LLL -Y EXTERNAL -H ldapi://$S1 -b dc=example,dc=com "(cn=KDC)" dn: cn=KDC,dc=example,dc=com objectClass: nsContainer objectClass: ipaConfigObject objectClass: top cn: KDC ipaconfigstring: startOrder 10 ipaconfigstring: kdcProxyEnabled ipaconfigstring: pkinitEnabled ipaconfigstring: hiddenService entryuuid: 784dacd4-13a4-40e3-b74b-8724bdc1b74f So as expected the deleted values are not present. And as far as I know the "import" task cannot resurrect deleted value (It just restores the entry state information as is). So IMHO there is something behind the scene either in the way the import was done or because the replication reverted the change. I would suggest to: stop the other instances that could replicate towards the hidden one perform a dsconf instance backend import userRoot ldifPath and see what the ldapsearch returns restart the stopped instances wait a bit and see what the ldapsearch returns Another interresting data would be to run: ldapsearch -LLL -Y GSSAPI -b cn=KDC,cn=replica.example.test,cn=masters,cn=ipa,cn=etc,dc=example,dc=test ipaConfigString nscpEntryWSI to collect the current entry state
IPA backs up and restores things a bit differently, pre-dating by far dsconf. tar is used to backup most static files and directories. The database is backed up both using db2bak and db2ldif. The ldif version is restored after stripping out the RUV data, so replication shouldn't be an issue. Still, I shut down the other server. It shouldn't matter though as the delete and add of the ipaConfigString values should be, and are, consistent between the two prior to backup. I took the time to re-confirm. I'll also add this this is behaving differently in newer versions of 389-ds. The values are not restored. https://pagure.io/freeipa/issue/9095
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.