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 at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users > ------------------------------------------------------------------------ > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -- /***************************************************************/ Jim Hogan jimh at u.washington.edu Director, Computing Support Department of Environmental and Occupational Health Sciences 4225 Roosevelt Way NE, Room 301F Box 354695 206-616-7836 /***************************************************************/
