[389-users] Re: 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