Bug 2050439

Summary: ldif2db restores deleted values
Product: Red Hat Enterprise Linux 8 Reporter: Rob Crittenden <rcritten>
Component: 389-ds-baseAssignee: LDAP Maintainers <idm-ds-dev-bugs>
Status: CLOSED WONTFIX QA Contact: LDAP QA Team <idm-ds-qe-bugs>
Severity: medium Docs Contact:
Priority: high    
Version: 8.6CC: idm-ds-dev-bugs, mreynolds, progier, tbordaz
Target Milestone: rcKeywords: Triaged
Target Release: 8.9   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: sync-to-jira
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-08-03 07:28:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Rob Crittenden 2022-02-03 23:43:20 UTC
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

Comment 1 Pierre Rogier 2022-02-04 12:53:55 UTC
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

Comment 3 Rob Crittenden 2022-02-04 15:03:31 UTC
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

Comment 9 RHEL Program Management 2023-08-03 07:28:35 UTC
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.