On Fri, Apr 21, 2017 at 04:02:50PM +1000, William Brown wrote: > On Fri, 2017-04-21 at 07:55 +0200, Simon Pichugin wrote: > > On Fri, Apr 21, 2017 at 09:25:23AM +1000, William Brown wrote: > > Partly, yes. My question was about possible regression. > > > > We have a lot of tests for nsslapd-allowed-sasl-mechanisms in TET. > > It has raised two concerns I have now. > > > > First, if we are trying to set 'empty value' with a replace operation, it fails (and it is okay). > > > > But now with your new cn=config feature we have 'nsslapd-allowed-sasl-mechanisms' empty by default. > > It seems to be wrong as long as the servers forbids to set 'empty value' manually. > > Well, the bug there is we can't set an empty value. You should be able > to delete the attribute though, and that should reset it. > > Additionally, it may be worth checking that if the value is empty sasl > treats that as *all* mechs are allowed. This would be one of the few > config items where I think it should be a blacklist, rathar than > whitelist. > > So certainly, this could be a bug. > > > > > Second test that fails now asserts that we can't add more values to the > > single-value attribute (nsslapd-allowed-sasl-mechanisms is the one). > > The test excpects an error. But the server just replaces the value with > > a new one. No error happens. Is it by design or we should fix it? > > I did fix some code related to add/replace. I think that if you add > another value, and it replaces, that's a bug. It contradicts the ldap > standard I think. Hi William, after some investigation I've found out that my previous report was misleaded by TET. Though I've found some strange behaviour in the cn=config reset to defaults feature and the subject. On clean instance: 1. Check the supportedSASLMechanisms on a clean instance with a default nsslapd-allowed-sasl-mechanisms: [root@qeos-236 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "" -s base supportedSASLMechanisms dn: supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: GSS-SPNEGO supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: PLAIN supportedSASLMechanisms: ANONYMOUS 2. Set some particular SASL mechanism: [root@qeos-236 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 dn: cn=config changetype: modify replace: nsslapd-allowed-sasl-mechanisms nsslapd-allowed-sasl-mechanisms: DIGEST-MD5 modifying entry "cn=config" 3. Check the supportedSASLMechanisms: [root@qeos-236 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "" -s base supportedSASLMechanisms dn: supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: DIGEST-MD5 4. Reset to default by deleting the attribute: [root@qeos-236 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -w Secret123 dn: cn=config changetype: modify delete: nsslapd-allowed-sasl-mechanisms modifying entry "cn=config" 5. Check the supportedSASLMechanisms once againg: [root@qeos-236 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "" -s base supportedSASLMechanisms dn: supportedSASLMechanisms: EXTERNAL 6. Restart the instance: [root@qeos-236 dirsrv-tet-install]# restart-dirsrv Restarting instance "qeos-236" 7. Check the supportedSASLMechanisms: [root@qeos-236 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "" -s base supportedSASLMechanisms dn: supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: GSS-SPNEGO supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: PLAIN supportedSASLMechanisms: ANONYMOUS Results: So if we reset the attribute it will not be applied without a restart. Though if we set some SASL mechanism manually it will be applied instantly. Thanks, Simon > > -- > Sincerely, > > William Brown > Software Engineer > Red Hat, Australia/Brisbane >
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
