Fedora directory users - Mar 2007 - nisDomain/Solaris schema not loading???

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).

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

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.

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 :(

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 ) )

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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Richard,

Progress....

Richard Megginson wrote:
> 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 wasn''t sure but that is good to know.  I hope I will never crowd the 
remaining space between 64 and 98, though :)
>> 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
Well, I wandered off for a while and came back and there they were -- 
nis* objects/attributes.    So I moved the schema back to 63*, 
restarted, went to lunch and they are still there.  Does restart order 
matter for that (schema adds)?  I didn''t think so.  I am not sure what 
It did. 

So I was able to add the nisDomainObject objectcalss and nisDomain 
attribute for my domain object. (I will say that the much lengthier 
document referenced in the How To was very helpful in helping me confirm 
what to do there.)

So no, the iPlanet client service on the EMC is able to find its profile 
and such.  Still doesn''t work, but progress.  I will now return to that
thread.

Thanks!

Jim
>
>>
>> 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@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   

-- 
/***************************************************************/
 Jim Hogan                   jimh@u.washington.edu

 Director, Computing Support
 Department of Environmental and Occupational Health Sciences
 4225 Roosevelt Way NE, Room 301F
 Box 354695
 206-616-7836
/***************************************************************/