Re: anonymous queries on second suffix subtrees

[Mark Reynolds]

On 4/30/20 9:53 AM, Mc Laughlin David Bruce (ID BD) wrote:
>  Hi, Mark.
>
>
>  I did not expect a reply so soon!
>
>
>  When I query as "Directory Manager", I get the expected result.
>
>
>  I used the setup-ds.pl script to create the o=ethz,c=ch root suffx.
>  
You should be using dscreate to create your instance, not setup-ds.pl
>  I used "dsconf backend create" to add the second suffix (o=psi,c=ch).
>  
Did you add any entries to o=psi,c=ch ?

>  The subtrees are not properly connected to their respective root suffixes.
>
>  Could this problem be caused by missing entries in the two "root 
>  suffix" databases?
>
>
>  [root@el-dap ~]#
>  [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL -x 
>  -b 'o=psi,c=ch' '(ou=*)'
>  No such object (32) 
So you did not initialize this suffix.  It is empty.

When creating the backend you could have created the top database node 
entry by adding the "--create-suffix" option:

# dsconf slapd-YOUR_INSTANCE backend create --suffix o=psi,c=ch 
--create-suffix

Note - dscreate or dsconf do not add any aci's by default.  You have to 
add the aci's after initializing the database with some data.

>  [root@el-dap ~]#
>
>
>  Anonymous queries on the two subtrees (ou=staff & ou=student) on root 
>  suffix (o=ethz,c=ch)
>
>  return the expected result.
>  
So searches on "ou=staff,o=ethz,c=ch" work?  But just searching on 
"o=ethz,c=ch" does not?  I'm getting confused because you keep changing 
which suffixes work or don't work.  First it was subtree's under 
o=psi,c=ch that didn't return any results, now it's different subtrees 
under o=ethz,c=ch

So if you are having issues with anything under "o=ethz,c=ch" then can 
you please run this search, and also clarify which subtrees work and 
don't work for anonymous searches under this suffix "o=ethz,c=ch":


# ldapsearch -D "cn=directory manager" -W -b "o=ethz,c=ch" aci=* aci

Thanks,
Mark


>  However, anonymous queries on the o=ethz,c=ch root suffix also return 
>  no records.
>
>
>  with best regards,
>
>  David
>
>
>  e-mail: david.mclaughlin(a)id.ethz.ch <mailto:[e-mail]>
>
>
>  ------------------------------------------------------------------------
>  *From:* Mark Reynolds <mreynolds(a)redhat.com&gt;
>  *Sent:* 30 April 2020 3:10 PM
>  *To:* General discussion list for the 389 Directory server project.; 
>  Mc Laughlin David Bruce (ID BD)
>  *Subject:* Re: [389-users] anonymous queries on second suffix subtrees
>
>
>  On 4/30/20 7:14 AM, Mc Laughlin David Bruce (ID BD) wrote:
> > Hello, 389ers.
> >
> > I am migrating a whitepages server from OpenLDAP to 389-DS.
> >
> > My instance has a root suffix with two subtrees (for staff and students).
> > Anonymous queries of the two root suffix subtrees return the expected 
> > results.
> >
> > The instance also has a second suffix of "o=psi,c=ch" with three 
> > subtrees:
> >   ou=contacts,o=psi,c=ch
> >   ou=groups,o=psi,c=ch
> >   ou=users,o=psi,c=ch
> >
> > Anonymous queries of the three "o=psi,c=ch" subtrees return NO records.
> >
> > I have added ACIs for the three "o=psi,c=ch" subtrees and restarted 
> > the instance, but
> > anonymous queries of any of the three "o=psi,c=ch" subtrees STILL 
> > return no records.
> >
> > Does anyone know how to allow anonymous queries?
>
>  First you don't need to restart the server when you add or change 
>  ACI's.  If you run the search as "cn=directory manager" does it return 
>  the results you expect?
>
>  Can you share all the ACI's you added to o=psi,c=ch subtrees?  Maybe 
>  gather all of them by using this search:
>
>      # ldapsearch -D "cn=directory manager" -W -b "o=psi,c=ch" aci=*
> aci
>
>  Thanks,
>  Mark
>
>
> >
> > Thanks,
> >  David
> >
> > [root@el-dap ~]#
> > [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -D 
> > "cn=Directory Manager" -W -x -b "ou=users,o=psi,c=ch" -s sub 
> > '(aci=*)' aci
> > Enter LDAP Password:
> > # extended LDIF
> > #
> > # LDAPv3
> > # base <ou=users,o=psi,c=ch> with scope subtree
> > # filter: (aci=*)
> > # requesting: aci
> > #
> > # users, psi, ch
> > dn: ou=users,o=psi,c=ch
> > aci: (target = "ldap:///ou=users,o=psi,c=ch")(version 3.0; acl 
> > "Anonymous read
> >  , search for users";allow (read, search) userdn = "ldap:///anyone";)
> > # search result
> > search: 2
> > result: 0 Success
> > # numResponses: 2
> > # numEntries: 1
> > [root@el-dap ~]#
> >
> >
> > [root@el-dap ~]#
> > [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL 
> > -x -b 'ou=users,o=psi,c=ch' '(cn=*kohler*)'
> > [root@el-dap ~]#
> >
> >
> > [root@el-dap ~]#
> > [root@el-dap ~]# tail /var/log/dirsrv/slapd-el-dap/access
> > [30/Apr/2020:10:23:02.362530519 +0200] conn=5 fd=64 slot=64 
> > connection from 129.132.65.9 to 129.132.65.9
> > [30/Apr/2020:10:23:02.362748318 +0200] conn=5 op=0 BIND dn="" 
> > method=128 version=3
> > [30/Apr/2020:10:23:02.362795436 +0200] conn=5 op=0 RESULT err=0 
> > tag=97 nentries=0 etime=0.0000179605 dn=""
> > [30/Apr/2020:10:23:02.363025956 +0200] conn=5 op=1 SRCH 
> > base="ou=users,o=psi,c=ch" scope=2 filter="(cn=*kohler*)"
> attrs=ALL
> > [30/Apr/2020:10:23:02.363471926 +0200] conn=5 op=1 RESULT err=0 
> > tag=101 nentries=0 etime=0.0000606595
> > [30/Apr/2020:10:23:02.363649360 +0200] conn=5 op=2 UNBIND
> > [30/Apr/2020:10:23:02.363680129 +0200] conn=5 op=2 fd=64 closed - U1
> > [root@el-dap ~]#
> >
> > ___________________________________________________
> >
> > David McLaughlin
> >
> > ETH Zürich / Swiss Federal Institute of Technology
> >
> > Informatikdienste
> >
> > Basisdienste
> >
> > Mail, Archive & Directories group
> >
> > CH-8092 Zürich
> >
> > Tel.: [phone]
> >
> > e-mail: david.mclaughlin(a)id.ethz.ch <mailto:[e-mail]>
> >
> >
> > _______________________________________________
> > 389-users mailing list --389-users(a)lists.fedoraproject.org
> > To unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List
> Archives:https://lists.fedoraproject.org/archives/list/[e-mail]...
>  -- 
>
>  389 Directory Server Development Team 
-- 

389 Directory Server Development Team

anonymous queries on second suffix subtrees

[Mc Laughlin David Bruce (ID BD)]

Hi, Mark.


Your questions and comments have pointed me in the right direction and solved several

mysteries about missing db files, etc.


I will remove both root suffixes and their respective databases and then re-create them
using

dscreate to create the instance and using dsconf (with the "--create-suffix"
option) to add the

 second root suffix.


Even with the https://directory.fedoraproject.org/docs/389ds/documentation.html site and
the

https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ 
documentation,

the product is so big that it is difficult to get an overview.


I will not bother you again before the instance and its suffixes have been rebuilt.


Thanks for your help,

David

___________________________________________________
David McLaughlin
ETH Zürich / Swiss Federal Institute of Technology
Informatikdienste
Basisdienste
Mail, Archive & Directories group
CH-8092 Zürich

Tel.: [phone]
e-mail: [e-mail]<mailto:[e-mail]>


________________________________
From: Mark Reynolds <mreynolds(a)redhat.com&gt;
Sent: 30 April 2020 4:21 PM
To: Mc Laughlin David Bruce (ID BD); General discussion list for the 389 Directory server
project.
Subject: Re: [389-users] anonymous queries on second suffix subtrees



On 4/30/20 9:53 AM, Mc Laughlin David Bruce (ID BD) wrote:

Hi, Mark.


I did not expect a reply so soon!


When I query as "Directory Manager", I get the expected result.


I used the setup-ds.pl script to create the o=ethz,c=ch root suffx.

You should be using dscreate to create your instance, not setup-ds.pl

I used "dsconf backend create" to add the second suffix (o=psi,c=ch).

Did you add any entries to o=psi,c=ch ?


The subtrees are not properly connected to their respective root suffixes.

Could this problem be caused by missing entries in the two "root suffix"
databases?


[root@el-dap ~]#
[root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL -x -b
'o=psi,c=ch' '(ou=*)'
No such object (32)

So you did not initialize this suffix.  It is empty.

When creating the backend you could have created the top database node entry by adding the
"--create-suffix" option:

# dsconf slapd-YOUR_INSTANCE backend create --suffix o=psi,c=ch --create-suffix

Note - dscreate or dsconf do not add any aci's by default.  You have to add the
aci's after initializing the database with some data.

[root@el-dap ~]#



Anonymous queries  on the two subtrees (ou=staff & ou=student) on root suffix
(o=ethz,c=ch)

return the expected result.

So searches on "ou=staff,o=ethz,c=ch" work?  But just searching on
"o=ethz,c=ch" does not?  I'm getting confused because you keep changing
which suffixes work or don't work.  First it was subtree's under o=psi,c=ch that
didn't return any results, now it's different subtrees under o=ethz,c=ch

So if you are having issues with anything under "o=ethz,c=ch" then can you
please run this search, and also clarify which subtrees work and don't work for
anonymous searches under this suffix "o=ethz,c=ch":

# ldapsearch -D "cn=directory manager" -W -b "o=ethz,c=ch" aci=* aci

Thanks,
Mark



However, anonymous queries on the o=ethz,c=ch root suffix  also return no records.


with best regards,

David


e-mail: [e-mail]<mailto:[e-mail]>


________________________________
From: Mark Reynolds <[e-mail]><mailto:[e-mail]>
Sent: 30 April 2020 3:10 PM
To: General discussion list for the 389 Directory server project.; Mc Laughlin David Bruce
(ID BD)
Subject: Re: [389-users] anonymous queries on second suffix subtrees



On 4/30/20 7:14 AM, Mc Laughlin David Bruce (ID BD) wrote:
Hello, 389ers.

I am migrating a whitepages server from OpenLDAP to 389-DS.

My instance has a root suffix with two subtrees (for staff and students).
Anonymous queries of the two root suffix subtrees return the expected results.

The instance also has a second suffix of "o=psi,c=ch" with three subtrees:
  ou=contacts,o=psi,c=ch
  ou=groups,o=psi,c=ch
  ou=users,o=psi,c=ch

Anonymous queries of the three "o=psi,c=ch" subtrees return NO records.

I have added ACIs for the three "o=psi,c=ch" subtrees and restarted the
instance, but
anonymous queries of any of the three "o=psi,c=ch" subtrees STILL return no
records.

Does anyone know how to allow anonymous queries?

First you don't need to restart the server when you add or change ACI's.  If you
run the search as "cn=directory manager" does it return the results you expect?

Can you share all the ACI's you added to o=psi,c=ch subtrees?  Maybe gather all of
them by using this search:

    # ldapsearch -D "cn=directory manager" -W -b "o=psi,c=ch" aci=*
aci

Thanks,
Mark


Thanks,
 David

[root@el-dap ~]#
[root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -D "cn=Directory
Manager" -W -x -b "ou=users,o=psi,c=ch" -s sub '(aci=*)' aci
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=users,o=psi,c=ch> with scope subtree
# filter: (aci=*)
# requesting: aci
#
# users, psi, ch
dn: ou=users,o=psi,c=ch
aci: (target = "ldap:///ou=users,o=psi,c=ch")(version 3.0; acl "Anonymous
read
 , search for users";allow (read, search) userdn = "ldap:///anyone";)
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
[root@el-dap ~]#


[root@el-dap ~]#
[root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL -x -b
'ou=users,o=psi,c=ch' '(cn=*kohler*)'
[root@el-dap ~]#


[root@el-dap ~]#
[root@el-dap ~]# tail /var/log/dirsrv/slapd-el-dap/access
[30/Apr/2020:10:23:02.362530519 +0200] conn=5 fd=64 slot=64 connection from 129.132.65.9
to 129.132.65.9
[30/Apr/2020:10:23:02.362748318 +0200] conn=5 op=0 BIND dn="" method=128
version=3
[30/Apr/2020:10:23:02.362795436 +0200] conn=5 op=0 RESULT err=0 tag=97 nentries=0
etime=0.0000179605 dn=""
[30/Apr/2020:10:23:02.363025956 +0200] conn=5 op=1 SRCH
base="ou=users,o=psi,c=ch" scope=2 filter="(cn=*kohler*)" attrs=ALL
[30/Apr/2020:10:23:02.363471926 +0200] conn=5 op=1 RESULT err=0 tag=101 nentries=0
etime=0.0000606595
[30/Apr/2020:10:23:02.363649360 +0200] conn=5 op=2 UNBIND
[30/Apr/2020:10:23:02.363680129 +0200] conn=5 op=2 fd=64 closed - U1
[root@el-dap ~]#

___________________________________________________
David McLaughlin
ETH Zürich / Swiss Federal Institute of Technology
Informatikdienste
Basisdienste
Mail, Archive & Directories group
CH-8092 Zürich

Tel.: [phone]
e-mail: [e-mail]<mailto:[e-mail]>



_______________________________________________
389-users mailing list --
[e-mail]<mailto:[e-mail]>
To unsubscribe send an email to
[e-mail]<mailto:[e-mail]>
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...


--

389 Directory Server Development Team

--

389 Directory Server Development Team

anonymous queries on second suffix subtrees

[Mark Reynolds]

On 4/30/20 10:56 AM, Mc Laughlin David Bruce (ID BD) wrote:
>  Hi, Mark.
>
>
>  Your questions and comments have pointed me in the right direction and 
>  solved several
>
>  mysteries about missing db files, etc.
>
>
>  I will remove both root suffixes and their respective databases and 
>  then re-create them using
>
>  *dscreate* to create the instance and using *dsconf* (with the 
>  "--create-suffix" option) to add the
>
>   second root suffix.
>
>
>  Even with the 
>  https://directory.fedoraproject.org/docs/389ds/documentation.html site 
>  and the
>
>  https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ 
>  documentation,
>
>  the product is so big that it is difficult to get an overview.
>
>
>  I will not bother you again before the instance and its suffixes have 
>  been rebuilt.
>  
We're here to help, we understand those new to 389/LDAP will have a lot 
of questions.  So keep them coming...
>  Thanks for your help,
>
>  David
>
>
>  ___________________________________________________
>
>  David McLaughlin
>
>  ETH Zürich / Swiss Federal Institute of Technology
>
>  Informatikdienste
>
>  Basisdienste
>
>  Mail, Archive & Directories group
>
>  CH-8092 Zürich
>
>  Tel.: [phone]
>
>  e-mail: david.mclaughlin(a)id.ethz.ch <mailto:[e-mail]>
>
>
>
>  ------------------------------------------------------------------------
>  *From:* Mark Reynolds <mreynolds(a)redhat.com&gt;
>  *Sent:* 30 April 2020 4:21 PM
>  *To:* Mc Laughlin David Bruce (ID BD); General discussion list for the 
>  389 Directory server project.
>  *Subject:* Re: [389-users] anonymous queries on second suffix subtrees
>
>
>  On 4/30/20 9:53 AM, Mc Laughlin David Bruce (ID BD) wrote:
> >
> > Hi, Mark.
> >
> >
> > I did not expect a reply so soon!
> >
> >
> > When I query as "Directory Manager", I get the expected result.
> >
> >
> > I used the setup-ds.pl script to create the o=ethz,c=ch root suffx.
> >
>  You should be using dscreate to create your instance, not setup-ds.pl
> >
> > I used "dsconf backend create" to add the second suffix (o=psi,c=ch).
> >
>  Did you add any entries to o=psi,c=ch ?
>
> >
> > The subtrees are not properly connected to their respective root 
> > suffixes.
> >
> > Could this problem be caused by missing entries in the two "root 
> > suffix" databases?
> >
> >
> > [root@el-dap ~]#
> > [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL 
> > -x -b 'o=psi,c=ch' '(ou=*)'
> > No such object (32)
>
>  So you did not initialize this suffix.  It is empty.
>
>  When creating the backend you could have created the top database node 
>  entry by adding the "--create-suffix" option:
>
>  # dsconf slapd-YOUR_INSTANCE backend create --suffix o=psi,c=ch 
>  --create-suffix
>
>  Note - dscreate or dsconf do not add any aci's by default.  You have 
>  to add the aci's after initializing the database with some data.
>
> > [root@el-dap ~]#
> >
> >
> > Anonymous queries on the two subtrees (ou=staff & ou=student) on root 
> > suffix (o=ethz,c=ch)
> >
> > return the expected result.
> >
>  So searches on "ou=staff,o=ethz,c=ch" work?  But just searching on 
>  "o=ethz,c=ch" does not? I'm getting confused because you keep changing 
>  which suffixes work or don't work.  First it was subtree's under 
>  o=psi,c=ch that didn't return any results, now it's different subtrees 
>  under o=ethz,c=ch
>
>  So if you are having issues with anything under "o=ethz,c=ch" then can 
>  you please run this search, and also clarify which subtrees work and 
>  don't work for anonymous searches under this suffix "o=ethz,c=ch":
>
>
>  # ldapsearch -D "cn=directory manager" -W -b "o=ethz,c=ch" aci=* aci
>
>  Thanks,
>  Mark
>
>
> >
> > However, anonymous queries on the o=ethz,c=ch root suffix  also 
> > return no records.
> >
> >
> > with best regards,
> >
> > David
> >
> >
> > e-mail: david.mclaughlin(a)id.ethz.ch <mailto:[e-mail]>
> >
> >
> > ------------------------------------------------------------------------
> > *From:* Mark Reynolds <mreynolds(a)redhat.com&gt;
> > *Sent:* 30 April 2020 3:10 PM
> > *To:* General discussion list for the 389 Directory server project.; 
> > Mc Laughlin David Bruce (ID BD)
> > *Subject:* Re: [389-users] anonymous queries on second suffix subtrees
> >
> >
> > On 4/30/20 7:14 AM, Mc Laughlin David Bruce (ID BD) wrote:
> >> Hello, 389ers.
> >>
> >> I am migrating a whitepages server from OpenLDAP to 389-DS.
> >>
> >> My instance has a root suffix with two subtrees (for staff and 
> >> students).
> >> Anonymous queries of the two root suffix subtrees return the 
> >> expected results.
> >>
> >> The instance also has a second suffix of "o=psi,c=ch" with three 
> >> subtrees:
> >>   ou=contacts,o=psi,c=ch
> >>   ou=groups,o=psi,c=ch
> >>   ou=users,o=psi,c=ch
> >>
> >> Anonymous queries of the three "o=psi,c=ch" subtrees return NO
> records.
> >>
> >> I have added ACIs for the three "o=psi,c=ch" subtrees and restarted 
> >> the instance, but
> >> anonymous queries of any of the three "o=psi,c=ch" subtrees STILL 
> >> return no records.
> >>
> >> Does anyone know how to allow anonymous queries?
> >
> > First you don't need to restart the server when you add or change 
> > ACI's.  If you run the search as "cn=directory manager" does it 
> > return the results you expect?
> >
> > Can you share all the ACI's you added to o=psi,c=ch subtrees?  Maybe 
> > gather all of them by using this search:
> >
> >     # ldapsearch -D "cn=directory manager" -W -b "o=psi,c=ch"
> aci=* aci
> >
> > Thanks,
> > Mark
> >
> >
> >>
> >> Thanks,
> >>  David
> >>
> >> [root@el-dap ~]#
> >> [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -D 
> >> "cn=Directory Manager" -W -x -b "ou=users,o=psi,c=ch" -s sub
>
> >> '(aci=*)' aci
> >> Enter LDAP Password:
> >> # extended LDIF
> >> #
> >> # LDAPv3
> >> # base <ou=users,o=psi,c=ch> with scope subtree
> >> # filter: (aci=*)
> >> # requesting: aci
> >> #
> >> # users, psi, ch
> >> dn: ou=users,o=psi,c=ch
> >> aci: (target = "ldap:///ou=users,o=psi,c=ch")(version 3.0; acl 
> >> "Anonymous read
> >>  , search for users";allow (read, search) userdn =
> "ldap:///anyone";)
> >> # search result
> >> search: 2
> >> result: 0 Success
> >> # numResponses: 2
> >> # numEntries: 1
> >> [root@el-dap ~]#
> >>
> >>
> >> [root@el-dap ~]#
> >> [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL 
> >> -x -b 'ou=users,o=psi,c=ch' '(cn=*kohler*)'
> >> [root@el-dap ~]#
> >>
> >>
> >> [root@el-dap ~]#
> >> [root@el-dap ~]# tail /var/log/dirsrv/slapd-el-dap/access
> >> [30/Apr/2020:10:23:02.362530519 +0200] conn=5 fd=64 slot=64 
> >> connection from 129.132.65.9 to 129.132.65.9
> >> [30/Apr/2020:10:23:02.362748318 +0200] conn=5 op=0 BIND dn="" 
> >> method=128 version=3
> >> [30/Apr/2020:10:23:02.362795436 +0200] conn=5 op=0 RESULT err=0 
> >> tag=97 nentries=0 etime=0.0000179605 dn=""
> >> [30/Apr/2020:10:23:02.363025956 +0200] conn=5 op=1 SRCH 
> >> base="ou=users,o=psi,c=ch" scope=2 filter="(cn=*kohler*)"
> attrs=ALL
> >> [30/Apr/2020:10:23:02.363471926 +0200] conn=5 op=1 RESULT err=0 
> >> tag=101 nentries=0 etime=0.0000606595
> >> [30/Apr/2020:10:23:02.363649360 +0200] conn=5 op=2 UNBIND
> >> [30/Apr/2020:10:23:02.363680129 +0200] conn=5 op=2 fd=64 closed - U1
> >> [root@el-dap ~]#
> >>
> >> ___________________________________________________
> >>
> >> David McLaughlin
> >>
> >> ETH Zürich / Swiss Federal Institute of Technology
> >>
> >> Informatikdienste
> >>
> >> Basisdienste
> >>
> >> Mail, Archive & Directories group
> >>
> >> CH-8092 Zürich
> >>
> >> Tel.: [phone]
> >>
> >> e-mail: david.mclaughlin(a)id.ethz.ch <mailto:[e-mail]>
> >>
> >>
> >> _______________________________________________
> >> 389-users mailing list --389-users(a)lists.fedoraproject.org
> >> To unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org
> >> Fedora Code of
> Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List
> Archives:https://lists.fedoraproject.org/archives/list/[e-mail]...
> > -- 
> >
> > 389 Directory Server Development Team
>  -- 
>
>  389 Directory Server Development Team 
-- 

389 Directory Server Development Team

anonymous queries on second suffix subtrees

[William Brown]

>  On 1 May 2020, at 04:27, Mark Reynolds <mreynolds(a)redhat.com&gt;
> wrote:
>  
>  
>  On 4/30/20 10:56 AM, Mc Laughlin David Bruce (ID BD) wrote:
> > Hi, Mark.
> > 
> > Your questions and comments have pointed me in the right direction and solved
> several
> > mysteries about missing db files, etc.
> > 
> > I will remove both root suffixes and their respective databases and then re-create
> them using
> > dscreate to create the instance and using dsconf (with the
> "--create-suffix" option) to add the
> >  second root suffix.
> > 
> > Even with the https://directory.fedoraproject.org/docs/389ds/documentation.html site
> and the
> > https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ 
> documentation,
> > the product is so big that it is difficult to get an overview. 
I think most LDAP servers are this big, but we also have extremely thorough and complete
documentation that reveals that. Those docs help me as a developer all the time, so I
appreciate them!

> > 
> > I will not bother you again before the instance and its suffixes have been rebuilt.
>  We're here to help, we understand those new to 389/LDAP will have a lot of questions.
>  So keep them coming... 
Exactly, we are happy to help, and any question is a way for us to improve our software :)


> >>> 
> >>> I am migrating a whitepages server from OpenLDAP to 389-DS. 
I'm currently leading some efforts to improve openldap to 389ds conversion, tooling
and documentation, so any comments on the process so far and what you are trying to
achieve will help me to make the process better. 

So please stay in contact! Thanks! 


—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

anonymous queries on second suffix subtrees

[William Brown]

>  On 1 May 2020, at 00:56, Mc Laughlin David Bruce (ID BD)
> <david.mclaughlin(a)id.ethz.ch&gt; wrote:
>  
>  Hi, Mark.
>  
>  Your questions and comments have pointed me in the right direction and solved several
>  mysteries about missing db files, etc.
>  
>  I will remove both root suffixes and their respective databases and then re-create them
> using
>  dscreate to create the instance and using dsconf (with the "--create-suffix"
> option) to add the
>   second root suffix. 
Yep, that would work. You can also consider just using dsconf to remove any suffixes you
have currently and to just re-add them without needing to re-create the instance :) 

>  
>  Even with the https://directory.fedoraproject.org/docs/389ds/documentation.html site and
> the
>  https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ 
> documentation,
>  the product is so big that it is difficult to get an overview. 
Yep, but that documentation is very helpful too :) 

>  
>  I will not bother you again before the instance and its suffixes have been rebuilt.
Feel free to bother us anytime, we are here to help!

>  
>  Thanks for your help,
>  David
>  
>  ___________________________________________________
>  David McLaughlin
>  ETH Zürich / Swiss Federal Institute of Technology
>  Informatikdienste
>  Basisdienste
>  Mail, Archive & Directories group
>  CH-8092 Zürich
>   
>  Tel.: [phone]
>  e-mail: david.mclaughlin(a)id.ethz.ch
>  
>  
>  From: Mark Reynolds <mreynolds(a)redhat.com&gt;
>  Sent: 30 April 2020 4:21 PM
>  To: Mc Laughlin David Bruce (ID BD); General discussion list for the 389 Directory server
> project.
>  Subject: Re: [389-users] anonymous queries on second suffix subtrees
>   
>  
>  On 4/30/20 9:53 AM, Mc Laughlin David Bruce (ID BD) wrote:
> > Hi, Mark.
> > 
> > I did not expect a reply so soon!
> > 
> > When I query as "Directory Manager", I get the expected result.
> > 
> > I used the setup-ds.pl script to create the o=ethz,c=ch root suffx.
>  You should be using dscreate to create your instance, not setup-ds.pl
> > I used "dsconf backend create" to add the second suffix (o=psi,c=ch).
>  Did you add any entries to o=psi,c=ch ?
> > 
> > The subtrees are not properly connected to their respective root suffixes.
> > Could this problem be caused by missing entries in the two "root suffix"
> databases?
> > 
> > [root@el-dap ~]#
> > [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL -x -b
> 'o=psi,c=ch' '(ou=*)'
> > No such object (32)
>  So you did not initialize this suffix.  It is empty.  
>  When creating the backend you could have created the top database node entry by adding
> the "--create-suffix" option:
>  # dsconf slapd-YOUR_INSTANCE backend create --suffix o=psi,c=ch --create-suffix
>  Note - dscreate or dsconf do not add any aci's by default.  You have to add the
> aci's after initializing the database with some data.
> > [root@el-dap ~]#
> > 
> > 
> > Anonymous queries  on the two subtrees (ou=staff & ou=student) on root suffix
> (o=ethz,c=ch) 
> > return the expected result.
>  So searches on "ou=staff,o=ethz,c=ch" work?  But just searching on
> "o=ethz,c=ch" does not?  I'm getting confused because you keep changing
> which suffixes work or don't work.  First it was subtree's under o=psi,c=ch that
> didn't return any results, now it's different subtrees under o=ethz,c=ch
>  So if you are having issues with anything under "o=ethz,c=ch" then can you
> please run this search, and also clarify which subtrees work and don't work for
> anonymous searches under this suffix "o=ethz,c=ch":
>  
>  # ldapsearch -D "cn=directory manager" -W -b "o=ethz,c=ch" aci=* aci
>  Thanks,
>  Mark
>  
> > 
> > However, anonymous queries on the o=ethz,c=ch root suffix  also return no records.
> > 
> > with best regards,
> > David
> > 
> > e-mail: david.mclaughlin(a)id.ethz.ch
> > 
> > 
> > From: Mark Reynolds <mreynolds(a)redhat.com&gt;
> > Sent: 30 April 2020 3:10 PM
> > To: General discussion list for the 389 Directory server project.; Mc Laughlin David
> Bruce (ID BD)
> > Subject: Re: [389-users] anonymous queries on second suffix subtrees
> >  
> > 
> > On 4/30/20 7:14 AM, Mc Laughlin David Bruce (ID BD) wrote:
> >> Hello, 389ers.
> >> 
> >> I am migrating a whitepages server from OpenLDAP to 389-DS.
> >> 
> >> My instance has a root suffix with two subtrees (for staff and students).
> >> Anonymous queries of the two root suffix subtrees return the expected results.
> >> 
> >> The instance also has a second suffix of "o=psi,c=ch" with three
> subtrees:
> >>   ou=contacts,o=psi,c=ch
> >>   ou=groups,o=psi,c=ch
> >>   ou=users,o=psi,c=ch
> >> 
> >> Anonymous queries of the three "o=psi,c=ch" subtrees return NO
> records.
> >> 
> >> I have added ACIs for the three "o=psi,c=ch" subtrees and restarted the
> instance, but
> >> anonymous queries of any of the three "o=psi,c=ch" subtrees STILL
> return no records.
> >> 
> >> Does anyone know how to allow anonymous queries?
> > First you don't need to restart the server when you add or change ACI's.  If
> you run the search as "cn=directory manager" does it return the results you
> expect?
> > Can you share all the ACI's you added to o=psi,c=ch subtrees?  Maybe gather all
> of them by using this search:
> >     # ldapsearch -D "cn=directory manager" -W -b "o=psi,c=ch"
> aci=* aci
> > Thanks,
> > Mark
> > 
> >> 
> >> Thanks,
> >>  David
> >> 
> >> [root@el-dap ~]#
> >> [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -D
> "cn=Directory Manager" -W -x -b "ou=users,o=psi,c=ch" -s sub
> '(aci=*)' aci
> >> Enter LDAP Password:
> >> # extended LDIF
> >> #
> >> # LDAPv3
> >> # base <ou=users,o=psi,c=ch> with scope subtree
> >> # filter: (aci=*)
> >> # requesting: aci
> >> #
> >> # users, psi, ch
> >> dn: ou=users,o=psi,c=ch
> >> aci: (target = "ldap:///ou=users,o=psi,c=ch")(version 3.0; acl
> "Anonymous read
> >>  , search for users";allow (read, search) userdn =
> "ldap:///anyone";)
> >> # search result
> >> search: 2
> >> result: 0 Success
> >> # numResponses: 2
> >> # numEntries: 1
> >> [root@el-dap ~]#
> >> 
> >> 
> >> [root@el-dap ~]#
> >> [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL -x -b
> 'ou=users,o=psi,c=ch' '(cn=*kohler*)'
> >> [root@el-dap ~]#
> >> 
> >> 
> >> [root@el-dap ~]#
> >> [root@el-dap ~]# tail /var/log/dirsrv/slapd-el-dap/access
> >> [30/Apr/2020:10:23:02.362530519 +0200] conn=5 fd=64 slot=64 connection from
> 129.132.65.9 to 129.132.65.9
> >> [30/Apr/2020:10:23:02.362748318 +0200] conn=5 op=0 BIND dn=""
> method=128 version=3
> >> [30/Apr/2020:10:23:02.362795436 +0200] conn=5 op=0 RESULT err=0 tag=97 nentries=0
> etime=0.0000179605 dn=""
> >> [30/Apr/2020:10:23:02.363025956 +0200] conn=5 op=1 SRCH
> base="ou=users,o=psi,c=ch" scope=2 filter="(cn=*kohler*)" attrs=ALL
> >> [30/Apr/2020:10:23:02.363471926 +0200] conn=5 op=1 RESULT err=0 tag=101
> nentries=0 etime=0.0000606595
> >> [30/Apr/2020:10:23:02.363649360 +0200] conn=5 op=2 UNBIND
> >> [30/Apr/2020:10:23:02.363680129 +0200] conn=5 op=2 fd=64 closed - U1
> >> [root@el-dap ~]#
> >> 
> >> ___________________________________________________
> >> David McLaughlin
> >> ETH Zürich / Swiss Federal Institute of Technology
> >> Informatikdienste
> >> Basisdienste
> >> Mail, Archive & Directories group
> >> CH-8092 Zürich
> >>  
> >> Tel.: [phone]
> >> e-mail: david.mclaughlin(a)id.ethz.ch
> >> 
> >> 
> >> _______________________________________________
> >> 389-users mailing list -- 
> >> 389-users(a)lists.fedoraproject.org
> >> 
> >> To unsubscribe send an email to 
> >> 389-users-leave(a)lists.fedoraproject.org
> >> 
> >> Fedora Code of Conduct: 
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> 
> >> List Guidelines: 
> >> https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> 
> >> List Archives: 
> >> https://lists.fedoraproject.org/archives/list/[e-mail]...
> > -- 
> > 
> > 389 Directory Server Development Team
> > 
>  -- 
>  
>  389 Directory Server Development Team
>  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs