[389-devel] Re: Config attribute - nsslapd-allowed-sasl-mechanisms - behaviour

2017-04-20 Thread William Brown 
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:
> > On Thu, 2017-04-20 at 22:54 +0200, Simon Pichugin wrote:
> > > Hello William,
> > > I think my question is for you in the first place.
> > > It regards the default attributes for cn=config feature.
> > > 
> > > Version tested: 389-ds-base-1.3.6.1-9.el7.x86_64
> > > 
> > > During TET troubleshooting I've faced two issues:
> > > 1. By default, we have:
> > > [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
> > > "cn=Directory manager"
> > > -w Secret123 -b "cn=config" "objectclass=*" | grep 
> > > nsslapd-allowed-sasl-mechanisms
> > > nsslapd-allowed-sasl-mechanisms:
> > > 
> > > Empty value.
> > > 
> > > We can modify it and set something. (I'll skip the output, it works as 
> > > expected.
> > > And after this, the server allows to do like this:
> > > [root@qeos-126 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"
> > > 
> > > [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
> > > "cn=Directory manager"
> > > -w Secret123 -b "cn=config" "objectclass=*" | grep 
> > > nsslapd-allowed-sasl-mechanisms
> > > nsslapd-allowed-sasl-mechanisms:
> > > 
> > 
> > > 
> > 
> > Pretty sure the SASL mechs can't be written to: they are returned from
> > https://pagure.io/389-ds-base/blob/master/f/ldap/servers/slapd/saslbind.c#_754
> >  
> > 
> > And that only allows setting from mechs discovered by cyrus-sasl, and
> > mechs that are from plugins that register to
> > slapi_register_supported_saslmechanism() . The allowed mechs parameter
> > is the list that is checked to see if we'll allow using it, and that's
> > called from ids_sasl_getopt. During the set in libglobs, it looks like
> > we check that the mech is a real name supported by SASL, so perhaps test
> > with values like PLAIN, GSSAPI instead? 
> > 
> > > 
> > > 2. Second one is a known issue, but still I'd like to clarify the 
> > > expected behaviour:
> > > [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
> > > "cn=Directory manager"
> > > -w Secret123 -b "cn=config" "objectclass=*" | grep 
> > > nsslapd-allowed-sasl-mechanisms
> > > nsslapd-allowed-sasl-mechanisms: A
> > > [root@qeos-126 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D 
> > > "cn=Directory manager" -w Secret123
> > > dn: cn=config
> > > changetype: modify
> > > add: nsslapd-allowed-sasl-mechanisms
> > > nsslapd-allowed-sasl-mechanisms: B
> > > [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
> > > "cn=Directory manager"
> > > -w Secret123 -b "cn=config" "objectclass=*" | grep 
> > > nsslapd-allowed-sasl-mechanisms
> > > nsslapd-allowed-sasl-mechanisms: B
> > > 
> > > So it wouldn't be a multivalued attribute? if we'll do the 'add' 
> > > operation, it would replace the existing value with a new.
> > > 
> > > Please, comment of a both cases. First looks more like a bug to me 
> > > though, and I will file it if you'll confirm it.
> > 
> > Anyway, it looks like in libglobs.c, that it expects a comma seperated
> > list, it's not multivalued. The reason is that this single attribute is
> > returned in  config_get_allowed_sasl_mechs(); during the ids_sasl_getopt
> > call, which SASL_CB_GETOPT expects a specific format.
> > 
> > I imagine this is because it's easier to store it as one line in the
> > config, and requires less parsing each SASL request to go from
> > multivalue to one line, so it's an efficiency thing. 
> > 
> > 
> > Does that help explain the answer to your problems? 
> 
> 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 va

[389-devel] Re: Config attribute - nsslapd-allowed-sasl-mechanisms - behaviour

2017-04-20 Thread Simon Pichugin 
On Fri, Apr 21, 2017 at 09:25:23AM +1000, William Brown wrote:
> On Thu, 2017-04-20 at 22:54 +0200, Simon Pichugin wrote:
> > Hello William,
> > I think my question is for you in the first place.
> > It regards the default attributes for cn=config feature.
> > 
> > Version tested: 389-ds-base-1.3.6.1-9.el7.x86_64
> > 
> > During TET troubleshooting I've faced two issues:
> > 1. By default, we have:
> > [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
> > "cn=Directory manager"
> > -w Secret123 -b "cn=config" "objectclass=*" | grep 
> > nsslapd-allowed-sasl-mechanisms
> > nsslapd-allowed-sasl-mechanisms:
> > 
> > Empty value.
> > 
> > We can modify it and set something. (I'll skip the output, it works as 
> > expected.
> > And after this, the server allows to do like this:
> > [root@qeos-126 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"
> > 
> > [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
> > "cn=Directory manager"
> > -w Secret123 -b "cn=config" "objectclass=*" | grep 
> > nsslapd-allowed-sasl-mechanisms
> > nsslapd-allowed-sasl-mechanisms:
> > 
> 
> > 
> 
> Pretty sure the SASL mechs can't be written to: they are returned from
> https://pagure.io/389-ds-base/blob/master/f/ldap/servers/slapd/saslbind.c#_754
>  
> 
> And that only allows setting from mechs discovered by cyrus-sasl, and
> mechs that are from plugins that register to
> slapi_register_supported_saslmechanism() . The allowed mechs parameter
> is the list that is checked to see if we'll allow using it, and that's
> called from ids_sasl_getopt. During the set in libglobs, it looks like
> we check that the mech is a real name supported by SASL, so perhaps test
> with values like PLAIN, GSSAPI instead? 
> 
> > 
> > 2. Second one is a known issue, but still I'd like to clarify the expected 
> > behaviour:
> > [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
> > "cn=Directory manager"
> > -w Secret123 -b "cn=config" "objectclass=*" | grep 
> > nsslapd-allowed-sasl-mechanisms
> > nsslapd-allowed-sasl-mechanisms: A
> > [root@qeos-126 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D 
> > "cn=Directory manager" -w Secret123
> > dn: cn=config
> > changetype: modify
> > add: nsslapd-allowed-sasl-mechanisms
> > nsslapd-allowed-sasl-mechanisms: B
> > [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
> > "cn=Directory manager"
> > -w Secret123 -b "cn=config" "objectclass=*" | grep 
> > nsslapd-allowed-sasl-mechanisms
> > nsslapd-allowed-sasl-mechanisms: B
> > 
> > So it wouldn't be a multivalued attribute? if we'll do the 'add' operation, 
> > it would replace the existing value with a new.
> > 
> > Please, comment of a both cases. First looks more like a bug to me though, 
> > and I will file it if you'll confirm it.
> 
> Anyway, it looks like in libglobs.c, that it expects a comma seperated
> list, it's not multivalued. The reason is that this single attribute is
> returned in  config_get_allowed_sasl_mechs(); during the ids_sasl_getopt
> call, which SASL_CB_GETOPT expects a specific format.
> 
> I imagine this is because it's easier to store it as one line in the
> config, and requires less parsing each SASL request to go from
> multivalue to one line, so it's an efficiency thing. 
> 
> 
> Does that help explain the answer to your problems? 

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.

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?

> 
> 
> -- 
> Sincerely,
> 
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane
> 




signature.asc
Description: PGP signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Please review: 49229 49228

2017-04-20 Thread William Brown 
https://pagure.io/389-ds-base/issue/49228

https://pagure.io/389-ds-base/issue/raw/files/eaba716a895b94acd5a3dbde186983d9b51a5ae164cdad21f1285e44b91c3c81-0001-Ticket-49228-Fix-SSE4.2-detection.patch

https://pagure.io/389-ds-base/issue/49229

https://pagure.io/389-ds-base/issue/raw/files/11631f959403a92ba617df8ca256a7bbee9cfc6b7ca2bb18986bdf634337a3fd-0001-Ticket-49229-Correct-issues-in-latest-commits.patch



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Build failed in Jenkins: 389-ds-base #1259

2017-04-20 Thread jenkins 
See 

Changes:

[William Brown] Ticket 49226 - Memory leak in ldap-agent-bin

--
Started by an SCM change
Building remotely on F25 (Fedora25 fedora Fedora fedora25) in workspace 

Wiping out workspace first.
Cloning the remote Git repository
Cloning repository http://pagure.io/389-ds-base.git
 > git init  # 
 > timeout=10
Fetching upstream changes from http://pagure.io/389-ds-base.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > http://pagure.io/389-ds-base.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url http://pagure.io/389-ds-base.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url http://pagure.io/389-ds-base.git # timeout=10
Fetching upstream changes from http://pagure.io/389-ds-base.git
 > git -c core.askpass=true fetch --tags --progress 
 > http://pagure.io/389-ds-base.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/master^{commit} # timeout=10
Checking out Revision 6ff44aec5d1652ca5c497c82e17ccda513107418 (origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 6ff44aec5d1652ca5c497c82e17ccda513107418
 > git rev-list f1e5692b270d39c63de79d47e41a59ac55fec170 # timeout=10
[389-ds-base] $ /bin/sh -e /tmp/hudson3732902689916108019.sh

Running configure...
CFLAGS= -Wall CXXFLAGS= -Wall ./configure --with-tmpfiles-d=/etc/tmpfiles.d 
--with-openldap --enable-autobind --enable-gcc-security --with-selinux 
--with-systemdsystemunitdir=/lib/systemd/system 
--with-systemdsystemconfdir=/etc/systemd/system --enable-debug
Build log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1259.txt
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:29: installing './compile'
configure.ac:25: installing './config.guess'
configure.ac:25: installing './config.sub'
configure.ac:14: installing './install-sh'
configure.ac:14: installing './missing'
Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
autoreconf: Leaving directory `.'

Running make...
Build log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1259.txt

Checking for warnings...
Build https://jenkins.fedorainfracloud.org/job/389-ds-base/1259/ failed
There are build warnings
Warning log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build-warns.1259.txt
Last 100 lines of warning log:

ldap/servers/slapd/pblock.c:2105:15: warning: unused variable ‘x’ 
[-Wunused-variable]
ldap/servers/slapd/pblock.c:3749:15: warning: unused variable ‘x’ 
[-Wunused-variable]
ldap/servers/slapd/task.c:1010:57: warning: passing argument 3 of 
‘slapi_pblock_set’ discards ‘const’ qualifier from pointer target type 
[-Wdiscarded-qualifiers]
ldap/servers/slapd/slapi-plugin.h:856:5: note: expected ‘void *’ but argument 
is of type ‘const char *’
ldap/servers/slapd/psearch.c:158:2: warning: ‘slapi_pblock_clone’ is deprecated 
[-Wdeprecated-declarations]
In file included from ldap/servers/slapd/psearch.c:24:0:
ldap/servers/slapd/slap.h:1756:16: note: declared here
ldap/servers/snmp/main.c:53:29: warning: implicit declaration of function 
‘isdigit’ [-Wimplicit-function-declaration]


Build step 'Execute shell' marked build as failure
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Please review: fixes for tickets that were commited

2017-04-20 Thread William Brown 
https://pagure.io/389-ds-base/issue/49229

https://pagure.io/389-ds-base/issue/raw/files/11631f959403a92ba617df8ca256a7bbee9cfc6b7ca2bb18986bdf634337a3fd-0001-Ticket-49229-Correct-issues-in-latest-commits.patch

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Build failed in Jenkins: 389-ds-base #1258

2017-04-20 Thread jenkins 
See 

Changes:

[William Brown] Ticket 49214 - Implement htree concept

--
Started by an SCM change
Building remotely on F25 (Fedora25 fedora Fedora fedora25) in workspace 

Wiping out workspace first.
Cloning the remote Git repository
Cloning repository http://pagure.io/389-ds-base.git
 > git init  # 
 > timeout=10
Fetching upstream changes from http://pagure.io/389-ds-base.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > http://pagure.io/389-ds-base.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url http://pagure.io/389-ds-base.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url http://pagure.io/389-ds-base.git # timeout=10
Fetching upstream changes from http://pagure.io/389-ds-base.git
 > git -c core.askpass=true fetch --tags --progress 
 > http://pagure.io/389-ds-base.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/master^{commit} # timeout=10
Checking out Revision f1e5692b270d39c63de79d47e41a59ac55fec170 (origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f1e5692b270d39c63de79d47e41a59ac55fec170
 > git rev-list 356c31562fcbf0bd52b0c8bacdb3bc664a8e0c39 # timeout=10
[389-ds-base] $ /bin/sh -e /tmp/hudson31173561958864.sh

Running configure...
CFLAGS= -Wall CXXFLAGS= -Wall ./configure --with-tmpfiles-d=/etc/tmpfiles.d 
--with-openldap --enable-autobind --enable-gcc-security --with-selinux 
--with-systemdsystemunitdir=/lib/systemd/system 
--with-systemdsystemconfdir=/etc/systemd/system --enable-debug
Build log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1258.txt
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:29: installing './compile'
configure.ac:25: installing './config.guess'
configure.ac:25: installing './config.sub'
configure.ac:14: installing './install-sh'
configure.ac:14: installing './missing'
Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
autoreconf: Leaving directory `.'

Running make...
Build log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1258.txt

Checking for warnings...
Build https://jenkins.fedorainfracloud.org/job/389-ds-base/1258/ failed
There are build warnings
Warning log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build-warns.1258.txt
Last 100 lines of warning log:

ldap/servers/slapd/pblock.c:2105:15: warning: unused variable ‘x’ 
[-Wunused-variable]
ldap/servers/slapd/pblock.c:3749:15: warning: unused variable ‘x’ 
[-Wunused-variable]
ldap/servers/slapd/task.c:1010:57: warning: passing argument 3 of 
‘slapi_pblock_set’ discards ‘const’ qualifier from pointer target type 
[-Wdiscarded-qualifiers]
ldap/servers/slapd/slapi-plugin.h:856:5: note: expected ‘void *’ but argument 
is of type ‘const char *’
ldap/servers/slapd/psearch.c:158:2: warning: ‘slapi_pblock_clone’ is deprecated 
[-Wdeprecated-declarations]
In file included from ldap/servers/slapd/psearch.c:24:0:
ldap/servers/slapd/slap.h:1756:16: note: declared here


Build step 'Execute shell' marked build as failure
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: Build failed in Jenkins: 389-ds-base #1257

2017-04-20 Thread William Brown 
On Thu, 2017-04-20 at 23:41 +, jenk...@fedoraproject.org wrote:
> See 
> 
> Changes:
> 
> [William Brown] Ticket 49119 - Cleanup configure.ac options and defines

> 
> ldap/servers/slapd/pblock.c:2105:15: warning: unused variable ‘x’ 
> [-Wunused-variable]
> ldap/servers/slapd/pblock.c:3749:15: warning: unused variable ‘x’ 
> [-Wunused-variable]
> ldap/servers/slapd/task.c:1010:57: warning: passing argument 3 of 
> ‘slapi_pblock_set’ discards ‘const’ qualifier from pointer target type 
> [-Wdiscarded-qualifiers]
> ldap/servers/slapd/slapi-plugin.h:856:5: note: expected ‘void *’ but argument 
> is of type ‘const char *’
> ldap/servers/slapd/psearch.c:158:2: warning: ‘slapi_pblock_clone’ is 
> deprecated [-Wdeprecated-declarations]
> In file included from ldap/servers/slapd/psearch.c:24:0:
> ldap/servers/slapd/slap.h:1756:16: note: declared here
> 
> 

I'm working on a patch to address these issues :) 


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Build failed in Jenkins: 389-ds-base #1257

2017-04-20 Thread jenkins 
See 

Changes:

[William Brown] Ticket 49119 - Cleanup configure.ac options and defines

--
Started by an SCM change
Building remotely on F25 (Fedora25 fedora Fedora fedora25) in workspace 

Wiping out workspace first.
Cloning the remote Git repository
Cloning repository http://pagure.io/389-ds-base.git
 > git init  # 
 > timeout=10
Fetching upstream changes from http://pagure.io/389-ds-base.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > http://pagure.io/389-ds-base.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url http://pagure.io/389-ds-base.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url http://pagure.io/389-ds-base.git # timeout=10
Fetching upstream changes from http://pagure.io/389-ds-base.git
 > git -c core.askpass=true fetch --tags --progress 
 > http://pagure.io/389-ds-base.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/master^{commit} # timeout=10
Checking out Revision 356c31562fcbf0bd52b0c8bacdb3bc664a8e0c39 (origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 356c31562fcbf0bd52b0c8bacdb3bc664a8e0c39
 > git rev-list eacb3c96ad2ae9e448ee547a796154d27e985b7f # timeout=10
[389-ds-base] $ /bin/sh -e /tmp/hudson5609565035716299692.sh

Running configure...
CFLAGS= -Wall CXXFLAGS= -Wall ./configure --with-tmpfiles-d=/etc/tmpfiles.d 
--with-openldap --enable-autobind --enable-gcc-security --with-selinux 
--with-systemdsystemunitdir=/lib/systemd/system 
--with-systemdsystemconfdir=/etc/systemd/system --enable-debug
Build log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1257.txt
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:29: installing './compile'
configure.ac:25: installing './config.guess'
configure.ac:25: installing './config.sub'
configure.ac:14: installing './install-sh'
configure.ac:14: installing './missing'
Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
autoreconf: Leaving directory `.'

Running make...
Build log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1257.txt

Checking for warnings...
Build https://jenkins.fedorainfracloud.org/job/389-ds-base/1257/ failed
There are build warnings
Warning log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build-warns.1257.txt
Last 100 lines of warning log:

ldap/servers/slapd/pblock.c:2105:15: warning: unused variable ‘x’ 
[-Wunused-variable]
ldap/servers/slapd/pblock.c:3749:15: warning: unused variable ‘x’ 
[-Wunused-variable]
ldap/servers/slapd/task.c:1010:57: warning: passing argument 3 of 
‘slapi_pblock_set’ discards ‘const’ qualifier from pointer target type 
[-Wdiscarded-qualifiers]
ldap/servers/slapd/slapi-plugin.h:856:5: note: expected ‘void *’ but argument 
is of type ‘const char *’
ldap/servers/slapd/psearch.c:158:2: warning: ‘slapi_pblock_clone’ is deprecated 
[-Wdeprecated-declarations]
In file included from ldap/servers/slapd/psearch.c:24:0:
ldap/servers/slapd/slap.h:1756:16: note: declared here


Build step 'Execute shell' marked build as failure
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: Config attribute - nsslapd-allowed-sasl-mechanisms - behaviour

2017-04-20 Thread William Brown 
On Thu, 2017-04-20 at 22:54 +0200, Simon Pichugin wrote:
> Hello William,
> I think my question is for you in the first place.
> It regards the default attributes for cn=config feature.
> 
> Version tested: 389-ds-base-1.3.6.1-9.el7.x86_64
> 
> During TET troubleshooting I've faced two issues:
> 1. By default, we have:
> [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
> "cn=Directory manager"
> -w Secret123 -b "cn=config" "objectclass=*" | grep 
> nsslapd-allowed-sasl-mechanisms
> nsslapd-allowed-sasl-mechanisms:
> 
> Empty value.
> 
> We can modify it and set something. (I'll skip the output, it works as 
> expected.
> And after this, the server allows to do like this:
> [root@qeos-126 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"
> 
> [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
> "cn=Directory manager"
> -w Secret123 -b "cn=config" "objectclass=*" | grep 
> nsslapd-allowed-sasl-mechanisms
> nsslapd-allowed-sasl-mechanisms:
> 

> 

Pretty sure the SASL mechs can't be written to: they are returned from
https://pagure.io/389-ds-base/blob/master/f/ldap/servers/slapd/saslbind.c#_754 

And that only allows setting from mechs discovered by cyrus-sasl, and
mechs that are from plugins that register to
slapi_register_supported_saslmechanism() . The allowed mechs parameter
is the list that is checked to see if we'll allow using it, and that's
called from ids_sasl_getopt. During the set in libglobs, it looks like
we check that the mech is a real name supported by SASL, so perhaps test
with values like PLAIN, GSSAPI instead? 

> 
> 2. Second one is a known issue, but still I'd like to clarify the expected 
> behaviour:
> [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
> "cn=Directory manager"
> -w Secret123 -b "cn=config" "objectclass=*" | grep 
> nsslapd-allowed-sasl-mechanisms
> nsslapd-allowed-sasl-mechanisms: A
> [root@qeos-126 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D 
> "cn=Directory manager" -w Secret123
> dn: cn=config
> changetype: modify
> add: nsslapd-allowed-sasl-mechanisms
> nsslapd-allowed-sasl-mechanisms: B
> [root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
> "cn=Directory manager"
> -w Secret123 -b "cn=config" "objectclass=*" | grep 
> nsslapd-allowed-sasl-mechanisms
> nsslapd-allowed-sasl-mechanisms: B
> 
> So it wouldn't be a multivalued attribute? if we'll do the 'add' operation, 
> it would replace the existing value with a new.
> 
> Please, comment of a both cases. First looks more like a bug to me though, 
> and I will file it if you'll confirm it.

Anyway, it looks like in libglobs.c, that it expects a comma seperated
list, it's not multivalued. The reason is that this single attribute is
returned in  config_get_allowed_sasl_mechs(); during the ids_sasl_getopt
call, which SASL_CB_GETOPT expects a specific format.

I imagine this is because it's easier to store it as one line in the
config, and requires less parsing each SASL request to go from
multivalue to one line, so it's an efficiency thing. 


Does that help explain the answer to your problems? 


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Build failed in Jenkins: 389-ds-base #1256

2017-04-20 Thread jenkins 
See 

Changes:

[William Brown] Ticket 49222 - Resolve various test issues on rawhide

[William Brown] Ticket 49097 - Pblock get/set cleanup

[William Brown] Ticket 49097 - whitespace fixes for pblock change

--
Started by an SCM change
Building remotely on F25 (Fedora25 fedora Fedora fedora25) in workspace 

Wiping out workspace first.
Cloning the remote Git repository
Cloning repository http://pagure.io/389-ds-base.git
 > git init  # 
 > timeout=10
Fetching upstream changes from http://pagure.io/389-ds-base.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > http://pagure.io/389-ds-base.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url http://pagure.io/389-ds-base.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url http://pagure.io/389-ds-base.git # timeout=10
Fetching upstream changes from http://pagure.io/389-ds-base.git
 > git -c core.askpass=true fetch --tags --progress 
 > http://pagure.io/389-ds-base.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/master^{commit} # timeout=10
Checking out Revision eacb3c96ad2ae9e448ee547a796154d27e985b7f (origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f eacb3c96ad2ae9e448ee547a796154d27e985b7f
 > git rev-list fbf320f316c2742f4c60cdc9f3e27a38944468e2 # timeout=10
[389-ds-base] $ /bin/sh -e /tmp/hudson7947125270748506663.sh

Running configure...
CFLAGS= -Wall CXXFLAGS= -Wall ./configure --with-tmpfiles-d=/etc/tmpfiles.d 
--with-openldap --enable-autobind --enable-gcc-security --with-selinux 
--with-systemdsystemunitdir=/lib/systemd/system 
--with-systemdsystemconfdir=/etc/systemd/system --enable-debug
Build log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1256.txt
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:29: installing './compile'
configure.ac:25: installing './config.guess'
configure.ac:25: installing './config.sub'
configure.ac:14: installing './install-sh'
configure.ac:14: installing './missing'
Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
autoreconf: Leaving directory `.'

Running make...
Build log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build.1256.txt

Checking for warnings...
Build https://jenkins.fedorainfracloud.org/job/389-ds-base/1256/ failed
There are build warnings
Warning log is 
https://jenkins.fedorainfracloud.org/job/389-ds-base/ws/build-warns.1256.txt
Last 100 lines of warning log:

ldap/servers/slapd/pblock.c:2105:15: warning: unused variable ‘x’ 
[-Wunused-variable]
ldap/servers/slapd/pblock.c:3749:15: warning: unused variable ‘x’ 
[-Wunused-variable]
ldap/servers/slapd/task.c:1010:57: warning: passing argument 3 of 
‘slapi_pblock_set’ discards ‘const’ qualifier from pointer target type 
[-Wdiscarded-qualifiers]
ldap/servers/slapd/slapi-plugin.h:856:5: note: expected ‘void *’ but argument 
is of type ‘const char *’
ldap/servers/slapd/psearch.c:158:2: warning: ‘slapi_pblock_clone’ is deprecated 
[-Wdeprecated-declarations]
In file included from ldap/servers/slapd/psearch.c:24:0:
ldap/servers/slapd/slap.h:1756:16: note: declared here


Build step 'Execute shell' marked build as failure
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: Is it branch time

2017-04-20 Thread William Brown 
On Thu, 2017-04-20 at 08:11 -0400, Mark Reynolds wrote:
> 
> On 04/19/2017 12:18 AM, William Brown wrote:
> > Hi Mark,
> >
> > We have a few larger tickets coming in (mainly my fault), and things are
> > settling down on the 1.3.6 side. Is this time to branch so we can get
> > these merged and start on some of the clean-ups we want to do for 1.4.x?
> Once we get 1.3.6(RHEL 7.4) finalized we'll do a new branch.  Soon
> William, soon :)

No probs: With some of these larger patches I have sitting on my laptop,
do you want me to hold off merging them? Or go ahead? I think at this
point it won't disrupt 1.3.6 backports "too much", but we never know
what could pop out from QE. 


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Config attribute - nsslapd-allowed-sasl-mechanisms - behaviour

2017-04-20 Thread Simon Pichugin 
Hello William,
I think my question is for you in the first place.
It regards the default attributes for cn=config feature.

Version tested: 389-ds-base-1.3.6.1-9.el7.x86_64

During TET troubleshooting I've faced two issues:
1. By default, we have:
[root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
"cn=Directory manager"
-w Secret123 -b "cn=config" "objectclass=*" | grep 
nsslapd-allowed-sasl-mechanisms
nsslapd-allowed-sasl-mechanisms:

Empty value.

We can modify it and set something. (I'll skip the output, it works as expected.
And after this, the server allows to do like this:
[root@qeos-126 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"

[root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
"cn=Directory manager"
-w Secret123 -b "cn=config" "objectclass=*" | grep 
nsslapd-allowed-sasl-mechanisms
nsslapd-allowed-sasl-mechanisms:

Empty once again.
In the ldap/servers/slapd/libglobs.c:8185, we have the info that:
/*
 * Check the SASL mechanism values
 *
 * As per RFC 4422:
 * SASL mechanisms are named by character strings, from 1 to 20
 * characters in length, consisting of ASCII [ASCII] uppercase letters,
 * digits, hyphens, and/or underscores.
 */

And:
8204 if(strlen(str) < 1){
8205 /* ignore empty values */
8206 return 0;
8207 }


2. Second one is a known issue, but still I'd like to clarify the expected 
behaviour:
[root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
"cn=Directory manager"
-w Secret123 -b "cn=config" "objectclass=*" | grep 
nsslapd-allowed-sasl-mechanisms
nsslapd-allowed-sasl-mechanisms: A
[root@qeos-126 dirsrv-tet-install]# ldapmodify -h localhost -p 389 -D 
"cn=Directory manager" -w Secret123
dn: cn=config
changetype: modify
add: nsslapd-allowed-sasl-mechanisms
nsslapd-allowed-sasl-mechanisms: B
[root@qeos-126 dirsrv-tet-install]# ldapsearch -h localhost -p 389 -D 
"cn=Directory manager"
-w Secret123 -b "cn=config" "objectclass=*" | grep 
nsslapd-allowed-sasl-mechanisms
nsslapd-allowed-sasl-mechanisms: B

So it wouldn't be a multivalued attribute? if we'll do the 'add' operation, it 
would replace the existing value with a new.

Please, comment of a both cases. First looks more like a bug to me though, and 
I will file it if you'll confirm it.

Thanks,
Simon


signature.asc
Description: PGP signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] please review: Issue 48978 - Fix the emergency logging to reflect the proper severity level and remove duplicate messages

2017-04-20 Thread Mark Reynolds 
https://pagure.io/389-ds-base/issue/48978

https://pagure.io/389-ds-base/issue/raw/files/f822c1f0c1dd97a402c7462c3f8a59573b1c1463d646d3d81b175d8a340abb48-0001-Issue-48978-Fix-the-emergency-logging-functions-seve.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] please review: Issue 49227 - ldapsearch for nsslapd-errorlog-level returns incorrect values

2017-04-20 Thread Mark Reynolds 
https://pagure.io/389-ds-base/issue/49227

https://pagure.io/389-ds-base/issue/raw/files/639ec52e6459fc691b75dd120bfbdb65945fae03e5625679499107d5d487c1b0-0001-Issue-49227-ldapsearch-for-nsslapd-errorlog-level-re.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: Is it branch time

2017-04-20 Thread Mark Reynolds 


On 04/19/2017 12:18 AM, William Brown wrote:
> Hi Mark,
>
> We have a few larger tickets coming in (mainly my fault), and things are
> settling down on the 1.3.6 side. Is this time to branch so we can get
> these merged and start on some of the clean-ups we want to do for 1.4.x?
Once we get 1.3.6(RHEL 7.4) finalized we'll do a new branch.  Soon
William, soon :)
>
>
>
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org