Hello:
I just installed a fresh install of the 389 DS from EPEL and I see no schema:
------------------------------------------------------------- # ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager # extended LDIF # # LDAPv3 # base <cn=schema> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# schema dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1 -------------------------------------------------------------
If I look at /etc/dirsrv/slapd-*/schema I see lots of files all with all sorts of contents. Is the schema unavailable by design? I also looked with 389-console and I see nothing in the schema.
Version information: # rpm -q 389-ds 389-ds-1.2.1-1.el5 # grep ^ /etc/*release* /etc/redhat-release:CentOS release 5.8 (Final)
On 07/13/2012 09:41 AM, Gary Algier wrote:
Hello:
I just installed a fresh install of the 389 DS from EPEL and I see no schema:
# ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager # extended LDIF # # LDAPv3 # base <cn=schema> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# schema dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema
# search result search: 2 result: 0 Success
# numResponses: 2
# numEntries: 1
If I look at /etc/dirsrv/slapd-*/schema I see lots of files all with all sorts of contents. Is the schema unavailable by design? I also looked with 389-console and I see nothing in the schema.
Version information: # rpm -q 389-ds 389-ds-1.2.1-1.el5
rpm -q 389-ds-base ?
Note that in later 389 releases, the schema was made LDAPv3 compliant. The schema attributes attributeTypes, objectClasses, matchingRules, etc. are defined by LDAPv3 to be operational attributes. This means they must be specified explicitly in the ldapsearch command line e.g.
ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager "objectclass-*" * attributeTypes objectClasses ....
# grep ^ /etc/*release* /etc/redhat-release:CentOS release 5.8 (Final)
On 07/13/12 11:42, Rich Megginson wrote:
On 07/13/2012 09:41 AM, Gary Algier wrote:
Hello:
I just installed a fresh install of the 389 DS from EPEL and I see no schema:
# ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager # extended LDIF # # LDAPv3 # base <cn=schema> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# schema dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema
# search result search: 2 result: 0 Success
# numResponses: 2
# numEntries: 1
If I look at /etc/dirsrv/slapd-*/schema I see lots of files all with all sorts of contents. Is the schema unavailable by design? I also looked with 389-console and I see nothing in the schema.
Version information: # rpm -q 389-ds 389-ds-1.2.1-1.el5
rpm -q 389-ds-base ?
Note that in later 389 releases, the schema was made LDAPv3 compliant. The schema attributes attributeTypes, objectClasses, matchingRules, etc. are defined by LDAPv3 to be operational attributes. This means they must be specified explicitly in the ldapsearch command line e.g.
ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager "objectclass-*" * attributeTypes objectClasses ....
# grep ^ /etc/*release* /etc/redhat-release:CentOS release 5.8 (Final)
All versions, just in case: # % rpm -qa | grep 389- 389-ds-1.2.1-1.el5 389-ds-base-libs-1.2.9.9-1.el5 389-ds-console-doc-1.2.6-1.el5 389-dsgw-1.1.9-1.el5 389-admin-console-1.1.8-1.el5 389-ds-base-1.2.9.9-1.el5 389-admin-console-doc-1.1.8-1.el5 389-console-1.1.7-3.el5 389-ds-console-1.2.6-1.el5 389-admin-1.1.29-1.el5 389-adminutil-1.1.15-1.el5
So I need to ask specifically for the attributes, but I should still see the dns, shouldn't I?
# ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager "objectclass=*" * attributetypes objectclasses | grep -i ^dn: dn: cn=schema
My goal here is to get a dump of the schema so I can compare it to my live DS5.2 server in preparation for migration. Are there any other tools for doing this kind of thing? I have seen discussion of migration but everything seems to assume that the schemata match.
On 07/16/2012 10:03 AM, Gary Algier wrote:
On 07/13/12 11:42, Rich Megginson wrote:
On 07/13/2012 09:41 AM, Gary Algier wrote:
Hello:
I just installed a fresh install of the 389 DS from EPEL and I see no schema:
# ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager # extended LDIF # # LDAPv3 # base <cn=schema> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# schema dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema
# search result search: 2 result: 0 Success
# numResponses: 2
# numEntries: 1
If I look at /etc/dirsrv/slapd-*/schema I see lots of files all with all sorts of contents. Is the schema unavailable by design? I also looked with 389-console and I see nothing in the schema.
Version information: # rpm -q 389-ds 389-ds-1.2.1-1.el5
rpm -q 389-ds-base ?
Note that in later 389 releases, the schema was made LDAPv3 compliant. The schema attributes attributeTypes, objectClasses, matchingRules, etc. are defined by LDAPv3 to be operational attributes. This means they must be specified explicitly in the ldapsearch command line e.g.
ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager "objectclass-*" * attributeTypes objectClasses ....
# grep ^ /etc/*release* /etc/redhat-release:CentOS release 5.8 (Final)
All versions, just in case: # % rpm -qa | grep 389- 389-ds-1.2.1-1.el5 389-ds-base-libs-1.2.9.9-1.el5 389-ds-console-doc-1.2.6-1.el5 389-dsgw-1.1.9-1.el5 389-admin-console-1.1.8-1.el5 389-ds-base-1.2.9.9-1.el5 389-admin-console-doc-1.1.8-1.el5 389-console-1.1.7-3.el5 389-ds-console-1.2.6-1.el5 389-admin-1.1.29-1.el5 389-adminutil-1.1.15-1.el5
So I need to ask specifically for the attributes, but I should still see the dns, shouldn't I?
What does "dns" mean? If you mean Distinguished Name (DN) then yes, the schema entry has the DN cn=schema, which is printed below.
# ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager "objectclass=*" * attributetypes objectclasses | grep -i ^dn: dn: cn=schema
My goal here is to get a dump of the schema so I can compare it to my live DS5.2 server in preparation for migration. Are there any other tools for doing this kind of thing?
python-ldap has a nice schema parser
Note that if you want to use shell tools for things like grep and sed you'll have to unwrap the ldif - see http://richmegginson.livejournal.com/18726.html
I have seen discussion of migration but everything seems to assume that the schemata match.
On 07/16/12 12:10, Rich Megginson wrote:
On 07/16/2012 10:03 AM, Gary Algier wrote:
On 07/13/12 11:42, Rich Megginson wrote:
On 07/13/2012 09:41 AM, Gary Algier wrote:
Hello:
I just installed a fresh install of the 389 DS from EPEL and I see no schema:
# ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager # extended LDIF # # LDAPv3 # base <cn=schema> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# schema dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema
# search result search: 2 result: 0 Success
# numResponses: 2
# numEntries: 1
If I look at /etc/dirsrv/slapd-*/schema I see lots of files all with all sorts of contents. Is the schema unavailable by design? I also looked with 389-console and I see nothing in the schema.
Version information: # rpm -q 389-ds 389-ds-1.2.1-1.el5
rpm -q 389-ds-base ?
Note that in later 389 releases, the schema was made LDAPv3 compliant. The schema attributes attributeTypes, objectClasses, matchingRules, etc. are defined by LDAPv3 to be operational attributes. This means they must be specified explicitly in the ldapsearch command line e.g.
ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager "objectclass-*" * attributeTypes objectClasses ....
# grep ^ /etc/*release* /etc/redhat-release:CentOS release 5.8 (Final)
All versions, just in case: # % rpm -qa | grep 389- 389-ds-1.2.1-1.el5 389-ds-base-libs-1.2.9.9-1.el5 389-ds-console-doc-1.2.6-1.el5 389-dsgw-1.1.9-1.el5 389-admin-console-1.1.8-1.el5 389-ds-base-1.2.9.9-1.el5 389-admin-console-doc-1.1.8-1.el5 389-console-1.1.7-3.el5 389-ds-console-1.2.6-1.el5 389-admin-1.1.29-1.el5 389-adminutil-1.1.15-1.el5
So I need to ask specifically for the attributes, but I should still see the dns, shouldn't I?
What does "dns" mean? If you mean Distinguished Name (DN) then yes, the schema entry has the DN cn=schema, which is printed below.
# ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager "objectclass=*" * attributetypes objectclasses | grep -i ^dn: dn: cn=schema
Oops. Stupid me. I forgot that all the schema is under one DN. I had some sort of expectation of multiple DNs to hold everything. Its been a while since I actually looked at an LDAP schema. When I initially saw nothing I jumped to conclusions. Sorry.
My goal here is to get a dump of the schema so I can compare it to my live DS5.2 server in preparation for migration. Are there any other tools for doing this kind of thing?
python-ldap has a nice schema parser
Note that if you want to use shell tools for things like grep and sed you'll have to unwrap the ldif - see http://richmegginson.livejournal.com/18726.html
I like the one-liner. Much shorter than the 15 line perl script I use.
Just do a backup. Or you can use the openldap dump tools. On Jul 16, 2012 12:02 PM, "Gary Algier" gaa@ulticom.com wrote:
On 07/13/12 11:42, Rich Megginson wrote:
On 07/13/2012 09:41 AM, Gary Algier wrote:
Hello:
I just installed a fresh install of the 389 DS from EPEL and I see no schema:
------------------------------**------------------------------**- # ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager # extended LDIF # # LDAPv3 # base <cn=schema> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# schema dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1 ------------------------------**------------------------------**-
If I look at /etc/dirsrv/slapd-*/schema I see lots of files all with all sorts of contents. Is the schema unavailable by design? I also looked with 389-console and I see nothing in the schema.
Version information: # rpm -q 389-ds 389-ds-1.2.1-1.el5
rpm -q 389-ds-base ?
Note that in later 389 releases, the schema was made LDAPv3 compliant. The schema attributes attributeTypes, objectClasses, matchingRules, etc. are defined by LDAPv3 to be operational attributes. This means they must be specified explicitly in the ldapsearch command line e.g.
ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager "objectclass-*" * attributeTypes objectClasses ....
# grep ^ /etc/*release* /etc/redhat-release:CentOS release 5.8 (Final)
All versions, just in case: # % rpm -qa | grep 389- 389-ds-1.2.1-1.el5 389-ds-base-libs-1.2.9.9-1.el5 389-ds-console-doc-1.2.6-1.el5 389-dsgw-1.1.9-1.el5 389-admin-console-1.1.8-1.el5 389-ds-base-1.2.9.9-1.el5 389-admin-console-doc-1.1.8-1.**el5 389-console-1.1.7-3.el5 389-ds-console-1.2.6-1.el5 389-admin-1.1.29-1.el5 389-adminutil-1.1.15-1.el5
So I need to ask specifically for the attributes, but I should still see the dns, shouldn't I?
# ldapsearch -x -h localhost -s sub -b cn=schema -wxxxxxxxx \ -Dcn=directory\ manager "objectclass=*" * attributetypes objectclasses | grep -i ^dn: dn: cn=schema
My goal here is to get a dump of the schema so I can compare it to my live DS5.2 server in preparation for migration. Are there any other tools for doing this kind of thing? I have seen discussion of migration but everything seems to assume that the schemata match.
-- Gary Algier, WB2FWZ gaa at ulticom.com +1 856 787 2758 Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033
Nielsen's First Law of Computer Manuals: People don't read documentation voluntarily.
-- 389 users mailing list 389-users@lists.fedoraproject.**org 389-users@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/389-usershttps://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org