On Sun, 2017-04-23 at 22:28 +0200, Simon Pichugin wrote: > 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. > Ahhh, so the issue is in how we reset this value to a default. Okay, that is a bug. Do you mind opening an issue an assigning it to me? Should be relatively easy to resolve. Do you have a lib389 testcase? Or is this tet? -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
