[Fedora-directory-users] nisDomain/Solaris schema not loading???

Wed Mar 21 18:05:20 UTC 2007

Jim Hogan wrote:
> I am running FDS 1.02 in master/client setup on Centos 4.4.  With 
> respect to an earlier query about an EMC NAS and Solaris client 
> config, I am running into a more basic problem with one of the two 
> schema from the Solaris How-To 
> (http://directory.fedora.redhat.com/wiki/Howto:SolarisClient), (I 
> named these 62DUAConfigProfile.ldif and 63nisDomain.ldif because I 
> already had a Samba schema on 61).
You can use the same number as long as the schema in one file does not 
refer to the schema in the other file with the same number.  I don't 
think the nisDomain schema refers to the samba schema, or vice versa.
> I was easily able to load the provided 62DUAConfigProfile schema file 
> (and I created a profile object for the EMC client that relied on 
> attributes in that schema).  I can see those new DUA attributes like 
> profileTTL.
>
> However, When I attempted to add the 63nisDomain.ldif schema, I can 
> restart the FDS slapd without error, but the nis* attributes do not 
> then show up in the FDS directory schema no matter how I look (try to 
> add attribute in phpLDAPadmin, or via FDS console under 
> config-->schema or elsewhere).  I have a 2 server master/client setup 
> and have added the schema files on both and restarted slapd on both 
> several times
For the authoritative view of the schema, use ldapsearch:
ldapsearch -x -s base -b "cn=schema" | grep nis
>
> There are a few other nis* attributes visible (nismap, nisnetgroup, 
> nisobject) but none of these seem to duplicate what are provided by 
> 63nisDomain.ldif.
>
> This config file appeared elsewhere on line and I tried it from 2 
> sources but it looked to be identical.  I was able to make the slapd 
> fail on restart by adding an unwanted space/CR to the file, so it 
> seems like slapd is definitely trying to read it.  I have verified 
> that the LDIF on both FDS servers is identical.  I turned logging up 
> to 64 on slapd to get config processing errors, but it didn't yield much:
>
> config - Unknown attribute mod will be ignored
> [21/Mar/2007:10:21:28 -0700] - Fedora-Directory/1.0.2 B2006.060.1928 
> starting up
> [21/Mar/2007:10:21:28 -0700] - Unknown config attribute readonly
> [21/Mar/2007:10:21:28 -0700] - DNS ldap.example.com -> DN 
> dc=ldap,dc=example,dc=com
> [21/Mar/2007:10:21:28 -0700] - slapd started.  Listening on All 
> Interfaces port 389 for LDAP requests
> [21/Mar/2007:10:21:29 -0700] - Listening on All Interfaces port 636 
> for LDAPS requests
>
> Not sure what those unknowns are, but I removed the nisDomain.ldif 
> from config/schema and restarted; the error log output was unchanged.
That's odd.  Try start-slapd -d 1 - this will spew out a large amount of 
text, but should reveal any config file parsing problems.
>
> In case there was some unknown precedence issue, I changed the order 
> of the 2 new LDIF to make nisDomain first, 62.  I then moved it ahead 
> of Samba schema to "59".  No change.
>
> The LDIF I am using now is pasted below -- a one-attribute-per-line 
> format.
>
> I am at a bit of a stand on this.  I am *really* not understanding why 
> I can't find any of these attributes.  But, it feels like one of those 
> times (they come about 10 times a year) where somebody may hit Jim 
> with a very large clue stick -- like I am really missing something :(
I don't see anything obvious.
>
> Any insight appreciated.
>
> Jim
>
> Current 63NisDomain.ldif:
>
> dn: cn=schema
> attributeTypes: ( 1.3.6.1.1.1.1.28 NAME 'nisPublickey' DESC 
> 'nisPublickey' EQUALITY caseIgnoreIA5Match SYNTAX 
> 1.3.6.1.4.1.1466.115.121.1.26 )
> attributeTypes: ( 1.3.6.1.1.1.1.29 NAME 'nisSecretkey' DESC 
> 'nisSecretkey' EQUALITY caseIgnoreIA5Match SYNTAX 
> 1.3.6.1.4.1.1466.115.121.1.26 )
> attributeTypes: ( 1.3.6.1.4.1.1.1.1.12 SUP name NAME 'nisDomain' DESC 
> 'NIS domain' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
> attributeTypes: ( 2.16.840.1.113730.3.1.30 NAME 'mgrpRFC822MailMember' 
> DESC 'mgrpRFC822MailMember' EQUALITY caseIgnoreIA5Match SYNTAX 
> 1.3.6.1.4.1.1466.115.121.1.26 )
> attributeTypes: ( 1.3.6.1.4.1.42.2.27.1.1.12 NAME 'nisNetIdUser' DESC 
> 'nisNetIdUser' EQUALITY caseExactIA5Match SYNTAX 
> 1.3.6.1.4.1.1466.115.121.1.26 )
> attributeTypes: ( 1.3.6.1.4.1.42.2.27.1.1.13 NAME 'nisNetIdGroup' DESC 
> 'nisNetIdGroup' EQUALITY caseExactIA5Match SYNTAX 
> 1.3.6.1.4.1.1466.115.121.1.26 )
> attributeTypes: ( 1.3.6.1.4.1.42.2.27.1.1.14 NAME 'nisNetIdHost' DESC 
> 'nisNetIdHost' EQUALITY caseExactIA5Match SYNTAX 
> 1.3.6.1.4.1.1466.115.121.1.26 )
> objectClasses: ( 1.3.6.1.1.1.2.14 NAME 'NisKeyObject' DESC 
> 'NisKeyObject' SUP top MUST ( cn $ nisPublickey $ nisSecretkey ) MAY ( 
> uidNumber $ description ) )
> objectClasses: ( 1.3.1.6.1.1.1.2.15 NAME 'nisDomainObject' DESC 
> 'nisDomainObject' SUP top AUXILIARY MUST ( nisDomain ) )
> objectClasses: ( 2.16.840.1.113730.3.2.4 NAME 'mailGroup' DESC 
> 'mailGroup' SUP top MUST ( mail ) MAY ( cn $ mgrpRFC822MailMember ) )
> objectClasses: ( 1.3.6.1.4.1.42.2.27.1.2.6 NAME 'nisNetId' DESC 
> 'nisNetId' SUP top MUST ( cn ) MAY ( nisNetIdUser $ nisNetIdGroup $ 
> nisNetIdHost ) )
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20070321/539573e8/attachment.bin>