#48362 With exhausted range, part of DNA shared configuration is deleted after server restart
Closed: wontfix None Opened 8 years ago by tbordaz.

When a DNA config entry is created with exhausted range (e.g. MaxValue < NextValue), some attributes set in the shared config entry of the host (e.g dnaHostname=<host_fqdn>+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX) are lost after a DS server restart.

This ticket is a corner case of https://fedorahosted.org/389/ticket/47779.

Having initial exhausted range is used when creating an IPA replica, so that it requests a new range to the master. This way all servers use the initially defined range by default.

The problem can be reproduced systematically with the attached test case


If the DNA config entry contains an exhausted range, the remaining allowed values is set to 0.

The consequence is that the host shared config entry will be created with dnaRemainingValues=0 (dna_update_shared_config).

Then this host shared config entry will be added to an internal servers list (at startup or change of DNA config entry) (dna_get_shared_servers). But having a null remaining values, this server entry is seen as invalid and not added to the list.

The host shared config entry (e.g. (e.g dnaHostname=<host_fqdn>+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX)) can be updated with some additional attributes, but the host remains not listed in the server list.

At startup, the host shared config entry is deleted (dna_update_config_event) and recreated based on the server list. As it is not present in the servers list, the host shared config entry is recreated with the minimum attributes.

Workaround:

A workaround is to create the DNA config entry with valid range.
An other workaround is to trigger the range request (add a user on the host), so that the host shared entry is seen as a valid host.

There are actually two lists:
* A list of config entries (i.e. cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX). This list is 'dna_global_config'. Based on defined ranges/values, this in memory list contains the remaining values granted by the entry. The remaining values is used (in that list) to determine if a new range is required or can be granted.

  • A list of servers, that is based one-level shared entries (e.g dnaHostname=<host_fqdn>+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX)). The servers in that list are built from values taken in the previous list (including remaining values). This list is used
  • to recreate the entries (dnaHostname=<host_fqdn>+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX) at startup (or shared config post-op). Only servers with ''remaining'' > 0 are in that list.
  • to find the server with the largest remaining values (the list is sorted)

I think this is acceptable to have null remaining values server in that list. They will be the last one in the list (that seems ok). It will create shared config ldap entries even for null remaining entries. That also seems ok

Thanks Mark for the review

'''master'''

Counting objects: 18, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 4.26 KiB, done.
Total 10 (delta 7), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
c4233ec..30aa91c master -> master

commit 30aa91c
Author: Thierry Bordaz tbordaz@redhat.com
Date: Mon Nov 30 16:47:12 2015 +0100

'''389-ds-base-1.3.4'''

Counting objects: 18, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 4.26 KiB, done.
Total 10 (delta 7), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
8cd610a..ee060e8 389-ds-base-1.3.4 -> 389-ds-base-1.3.4

commit ee060e8
Author: Thierry Bordaz tbordaz@redhat.com
Date: Mon Nov 30 16:47:12 2015 +0100

Metadata Update from @tbordaz:
- Issue assigned to tbordaz
- Issue set to the milestone: 1.3.4 backlog

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1693

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata