Fedora directory users - Feb 2006 - dumping the data base

Hello, 

  I am attempting to pull the schema of my FDS, I am use to using a command such
as ''ldapsearch -x -s base -b "" subschemasubentry''
or ''ldapsearch -b
"cn=subschema" attributetypes''

 Can anyone shine any light on how my syntax is wrong with these commands.  I am
trying to pull the subschema to show the various attribute definitions.

  I am sure I have just missed how to do it in the docs.

Thanks in advance

Scott Boggs wrote:
>Hello, 
>
>  I am attempting to pull the schema of my FDS, I am use to using a command
such
>as ''ldapsearch -x -s base -b ""
subschemasubentry'' or ''ldapsearch -b
>"cn=subschema" attributetypes''
>  
>
You first have to find out what the subschemasubentry suffix is:
ldapsearch -x -s base -b "" subschemasubentry
dn:
subschemasubentry: cn=schema

Then, you can query cn=schema:
ldapsearch -x -s base -b "" attributeTypes objectClasses
> Can anyone shine any light on how my syntax is wrong with these commands. 
I am
>trying to pull the subschema to show the various attribute definitions.
>
>  I am sure I have just missed how to do it in the docs.
>
>Thanks in advance
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  
>

Scott Boggs wrote:
>Hello, 
>
>  I am attempting to pull the schema of my FDS, I am use to using a command
such
>as ''ldapsearch -x -s base -b ""
subschemasubentry'' or ''ldapsearch -b
>"cn=subschema" attributetypes''
>  
>
You first have to find out what the subschemasubentry suffix is:
ldapsearch -x -s base -b "" subschemasubentry
dn:
subschemasubentry: cn=schema

Then, you can query cn=schema:
ldapsearch -x -s base -b "cn=schema" attributeTypes objectClasses
> Can anyone shine any light on how my syntax is wrong with these commands. 
I am
>trying to pull the subschema to show the various attribute definitions.
>
>  I am sure I have just missed how to do it in the docs.
>
>Thanks in advance
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  
>

Richard Megginson <rmeggins <at> redhat.com> writes:
>
> >  
> >
> You first have to find out what the subschemasubentry suffix is:
> ldapsearch -x -s base -b "" subschemasubentry
> dn:
> subschemasubentry: cn=schema
> 
> Then, you can query cn=schema:
> ldapsearch -x -s base -b "cn=schema" attributeTypes objectClasses
> 

I must really be screwing something up, when I type:
"ldapsearch -x -s base -b "" subschemasubentry" I get the
following error:

ldap search: Bad search filter

When I perform the following search, I get the same error:

"ldapsearch -x -s base -b "cn=schema" attributeTypes
objectClasses

ldap search: Bad search filter

This FDS is pretty much a basic build, so I have not really changed anything.  

I am runnning the ldapsearch command from within the /opt/fedora-ds/shared/bin
directory, if that makes any difference.  

thanks much for your advice, I am just trying to pull the definitions for the
attributes, I believe this would be the correct method..

--- Scott Boggs <sboggs@trustedcs.com> wrote:
> Richard Megginson <rmeggins <at> redhat.com> writes:
> 
> >
> > >  
> > >
> > You first have to find out what the subschemasubentry suffix is:
> > ldapsearch -x -s base -b "" subschemasubentry
> > dn:
> > subschemasubentry: cn=schema
> > 
> > Then, you can query cn=schema:
> > ldapsearch -x -s base -b "cn=schema" attributeTypes
objectClasses
> > 
> 
> 
> I must really be screwing something up, when I type:
> "ldapsearch -x -s base -b "" subschemasubentry" I get
the following error:
there are two ldapsearch''es, you know.

There''s also one in /usr/bin/ldapsearch, comes with openldap-clients
package.

Running /usr/bin/ldapsearch -x -b "dc=foo,dc=com" should return your
tree, at least.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Susan <logastellus <at> yahoo.com> writes:
> 
> there are two ldapsearch''es, you know.
> 
> There''s also one in /usr/bin/ldapsearch, comes with
openldap-clients package.
> 
> Running /usr/bin/ldapsearch -x -b "dc=foo,dc=com" should return
your tree, at
least.
>
Thanks

Richard Megginson <rmeggins <at> redhat.com> writes:
> 
> Scott Boggs wrote:
> 

I have been looking at the 00core.ldif to see if there is a method of editing
attributed definition, but I only see definitions for objectclasses.  Where does
FDS store the individual attribute definitions?

Scott Boggs wrote:
>Richard Megginson <rmeggins <at> redhat.com> writes:
>
>  
>
>>Scott Boggs wrote:
>>
>>    
>>
>
>
>I have been looking at the 00core.ldif to see if there is a method of
editing
>attributed definition, but I only see definitions for objectclasses.  Where
does
>FDS store the individual attribute definitions? 
>
>  
>
In the attributetypes attribute (as objectclasses are stored in the 
objectclasses attribute).  There are most definitely attributes defined 
in 00core.ldif since attributes have to be defined before you define 
objectclasses that rely on them.

-- 
Pete

Pete Rowley <prowley <at> redhat.com> writes:
> In the attributetypes attribute (as objectclasses are stored in the 
> objectclasses attribute).  There are most definitely attributes defined 
> in 00core.ldif since attributes have to be defined before you define 
> objectclasses that rely on them.
> 
So if I wanted to change the actual attributetype definition, I
could''nt? I know
it would violate the RFC, but I thought still had access to the core definition
like with the core.ldif of openldap.

Scott Boggs wrote:
>Richard Megginson <rmeggins <at> redhat.com> writes:
>
>  
>
>>> 
>>>
>>>      
>>>
>>You first have to find out what the subschemasubentry suffix is:
>>ldapsearch -x -s base -b "" subschemasubentry
>>dn:
>>subschemasubentry: cn=schema
>>
>>Then, you can query cn=schema:
>>ldapsearch -x -s base -b "cn=schema" attributeTypes
objectClasses
>>
>>    
>>
>
>
>I must really be screwing something up, when I type:
>"ldapsearch -x -s base -b "" subschemasubentry" I get
the following error:
>
>ldap search: Bad search filter
>
>When I perform the following search, I get the same error:
>
>"ldapsearch -x -s base -b "cn=schema" attributeTypes
objectClasses
>
>ldap search: Bad search filter
>
>This FDS is pretty much a basic build, so I have not really changed
anything.
>  
>
Oh, sorry.  From your previous email, it looked like you had set up some 
sort of default search filter.  You need to use "objectclass=*" for
your
search filter.
>I am runnning the ldapsearch command from within the
/opt/fedora-ds/shared/bin
>directory, if that makes any difference.  
>
>thanks much for your advice, I am just trying to pull the definitions for
the
>attributes, I believe this would be the correct method..
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  
>

Scott Boggs wrote:
>Pete Rowley <prowley <at> redhat.com> writes:
>
>  
>
>>In the attributetypes attribute (as objectclasses are stored in the 
>>objectclasses attribute).  There are most definitely attributes defined 
>>in 00core.ldif since attributes have to be defined before you define 
>>objectclasses that rely on them.
>>
>>    
>>
>
>So if I wanted to change the actual attributetype definition, I
could''nt? I know
>it would violate the RFC, but I thought still had access to the core
definition
>like with the core.ldif of openldap.  
>
>  
>
Yes you can.  I think perhaps your confusion comes from the fact the 
"objectclass" type is the first attribute type defined in the file:

attributeTypes: ( 2.5.4.0 NAME ''objectClass'' DESC
''Standard LDAP
attribute type'' EQUALITY objectIdentifierMatch SYNTAX 
1.3.6.1.4.1.1466.115.121.1.38 X-ORIGIN ''RFC 2256'' )

Note "attributeTypes:" at the beginning - you are quite free to change
whatever you wish, noting the dire warnings given previously :)

-- 
Pete

Pete Rowley <prowley <at> redhat.com> writes:
> 
> Note "attributeTypes:" at the beginning - you are quite free to
change
> whatever you wish, noting the dire warnings given previously :)
> 

Great I see it.   Thanks you really helped me understand..