Re: How to find out whether overlay module is loaded to openldap

[sandeep <sandeep@netcontinuum.com>]

Thanks  for your  reply

My serch  gives the following :
[root@ncins1 www]# ldapsearch -x -H ldap://:6666 -b cn=Overlays,cn=Monitor
# extended LDIF
#
# LDAPv3
# base <cn=Overlays,cn=Monitor> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1
[root@ncins1 www]# ldapsearch -x -H ldap://:6666 -b 
cn=Databases,cn=Monitor '(monitorOverlay=ppolicy)' '*' '+'
# extended LDIF
#
# LDAPv3
# base <cn=Databases,cn=Monitor> with scope subtree
# filter: (monitorOverlay=ppolicy)
# requesting: * +
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

 So it clearly shows no  Overlay module is loaded into ldap.
 But I have the following entry in  slapd.conf.
 # slapo-ppolicy has extra schema requirements
  include /usr/local/etc/openldap/schema/ppolicy.schema
  overlay     ppolicy
  ppolicy_default "cn=Default Policy,ou=Policies,dc=mydoamain,dc=com"

  So what would be  the reason ?
  How I can troubleshoot?
 
I am happy to put the FAQ entries and  some testing you people require.

Thanks for your help.
-Sandeep



Pierangelo Masarati wrote:

> > Hi all
> > quick question:
> >
> > How to find out whether overlay module is loaded to  openldap?
> > I am running openldap-2-3-11 in Fedora Core 3
> >    
>
> Do you mean:
> 1) an overlay compiled as a run-time mudule is loaded into slapd, or
> 2) an instance of that overlay is configured within a database?
>
> in case (1), you should look at the overlay types listed as
> "monitoredInfo" in "cn=Overlays,cn=Monitor":
>
> masarati@mbdyn:~> ldapsearch -x -H ldap://:9011 -b cn=Overlays,cn=Monitor
> -s base monitoredInfo
> # extended LDIF
> #
> # LDAPv3
> # base <cn=Overlays,cn=Monitor> with scope baseObject
> # filter: (objectclass=*)
> # requesting: monitoredInfo
> #
>
> # Overlays, Monitor
> dn: cn=Overlays,cn=Monitor
> monitoredInfo: glue
> monitoredInfo: valsort
> monitoredInfo: unique
> monitoredInfo: translucent
> monitoredInfo: syncprov
> monitoredInfo: rwm
> monitoredInfo: retcode
> monitoredInfo: refint
> monitoredInfo: pcache
> monitoredInfo: ppolicy
> monitoredInfo: lastmod
> monitoredInfo: dynlist
> monitoredInfo: dyngroup
> monitoredInfo: denyop
> monitoredInfo: accesslog
> monitoredInfo: chain
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> in case (2), you should look at the overlay types listed as
> "monitorOverlay" with the overlay's type below "cn=Databases,cn=Monitor":
>
> masarati@mbdyn-pm:~> ldapsearch -x -H ldap://:9011 \
>        -b cn=Databases,cn=Monitor '(monitorOverlay=syncprov)' '*' '+'
> # extended LDIF
> #
> # LDAPv3
> # base <cn=Databases,cn=Monitor> with scope subtree
> # filter: (monitorOverlay=syncprov)
> # requesting: * +
> #
>
> # Database 1, Databases, Monitor
> dn: cn=Database 1,cn=Databases,cn=Monitor
> objectClass: monitoredObject
> structuralObjectClass: monitoredObject
> cn: Database 1
> monitoredInfo: bdb
> monitorIsShadow: FALSE
> creatorsName:
> modifiersName:
> createTimestamp: 20051124182143Z
> modifyTimestamp: 20051124182143Z
> namingContexts: dc=example,dc=com
> readOnly: FALSE
> monitorOverlay: syncprov
> seeAlso: cn=Overlay 4,cn=Overlays,cn=Monitor
> seeAlso: cn=Backend 2,cn=Backends,cn=Monitor
> labeledURI:
> file:///home/masarati/Lavoro/sysnet/Ldap/ldap-devel/tests/testrun/
> db.1.a/
> entryDN: cn=Database 1,cn=Databases,cn=Monitor
> subschemaSubentry: cn=Subschema
> hasSubordinates: TRUE
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> You need to have the "database monitor" configured and read-accessible. 
> You can also see similar info from the "cn=config" context, but then you
> need to bind as the rootdn of that database; note that "cn=Monitor" is for
> monitoring purposes, and as such it shouldbe accessible by all the
> identities thta are authorized to monitor the status of the system;
> "cn=config" is for configuration handling, and its access is hardcoded for
> the rootdn only.
>
> May I suggest you write a FAQ entry on this topic?
>
> p.
>
>