With 389-ds-base-1.3.2.16-1.fc20.x86_64 I see very limited root DSE:
389-ds-base-1.3.2.16-1.fc20.x86_64
dn: objectClass: top defaultnamingcontext: dc=mkosek-fedora20,dc=test dataversion: 020140331095915020140331095915020140331095915 netscapemdsuffix: cn=ldap://dc=ipa,dc=mkosek-fedora20,dc=test:389 lastusn: 716 changeLog: cn=changelog firstchangenumber: 1 lastchangenumber: 85
When I check 389-ds-base-1.3.1.22-1.fc19.x86_64, I see much richer Root DSE:
dn: objectClass: top namingContexts: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com defaultnamingcontext: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.8.10.3 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 2.16.840.1.113730.3.6.5 supportedExtension: 2.16.840.1.113730.3.6.6 supportedExtension: 2.16.840.1.113730.3.6.7 supportedExtension: 2.16.840.1.113730.3.6.8 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: GSS-SPNEGO supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: ANONYMOUS supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 dataversion: 020140331095748 netscapemdsuffix: cn=ldap://dc=vm-119,dc=example,dc=com:38 9 lastusn: 241
This is the effect of a recent fix: https://fedorahosted.org/389/ticket/47634
It treats attributes of the usage dSAoperation as operational attributes and so they have to be requested in the search
Ok. I wonder if this may break anything. I would assume this limited view may be confusing for developers or people reading RootDSE, checking what information is there for their or their application consumption.
It can affect clients which do not explicitely request the attributes like supportedControl,.....
The intention of the fix was tomake schema reading and writing consistent and this is a side effect, but I think it is in accordance with standards, I think openldap also does not return these attributs if not requested
I confirm that openldap-servers-2.4.39-2.fc20.x86_64 behaves in the same way. Attributes are not returned unless explicitly requested.
I'm working on the corresponding DS ticket
Adding to list of tickets required for 4.0 release.
The option is ready on the DS side, IPA should enable it, when possible.
The option in DS is not about just enabling the behaviour, but we rather need to list all the attributes that should be returned without request. Should we follow the least suprise principle here and make the behaviour identical to previous releases? Or do we want to compile a custom list of attributes we want to return by default?
I would go for the option to achieve the same behavior as in previous releases.
After some fruitless investigation, I discovered that the underlying issue in DS was not properly fixed. I reopened the ticket in the 389's Trac.
well, the feature is implemented in DS, but there seems to be an issue when upgrading existing instances
Given we want to wait for DS fix (and Tomas is away), I am moving the ticket to 4.0.1.
I haven't found a problem in DS, looks like Tomas tried to add the attrs to the wrong entry "cn=config" instead to the root entry itself "dn: ". But I couldn't confirm his steps (before he is back) - so moving to 4.0.1 is ok
FreeIPA 4.0.1 was released, moving to next bugfixing release milestone.
Starting review
This change does not work or make sense until DS 1.3.3 is really released (not yet) with support of the config attribute. Moving to later release, waiting for 1.3.3.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1138795
Given that 1.3.3 is also required by the 4.0.x branch, it makes sense to push the patch there.
master:
ipa-4-1:
ipa-4-0:
Metadata Update from @mkosek: - Issue assigned to tbabej - Issue set to the milestone: FreeIPA 4.0.4
Login to comment on this ticket.