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