The NIS information imported into the LDAP directory is extracted from standard NIS files and from your custom-built files. Solaris Extensions for Netscape Directory Server 4.11 provides a mapping of standard NIS entries to LDAP attributes. The default nis.mapping file explicitly describes the information mapping for the following NIS files:
The mapping syntax for the aliases file is commented in detail in "aliases Mapping" . The description of all other maps is limited to the mapping of attributes. For full details on mapping syntax and semantics, refer to Appendix A, "Mapping Syntax and Semantics."
The nis.mapping file also contains a generic mapping definition for files that are not specifically defined. This includes any custom-built maps listed in your Makefile, and the following standard NIS files:
A mapping definition for each of these files and any custom-built files is added automatically in the nis.mapping file when you run dsypinstall. These mapping definitions are created from the generic mapping described in "Generic Mapping" and are identical for every map, except for the map name.
The nis.mapping file is used by the following components:
The mapping definitions in the nis.mapping file specify the following:
Generic Mapping
A generic mapping is applied to all files listed in the NIS Makefile that do not have a specific mapping definition in the nis.mapping file. This mapping extracts the NIS key and NIS value information from any file and creates an LDAP entry as follows:
aliases Mapping
An entry in the aliases file is usually of the form:
aliasname: mailaddress1, mailaddress2, mailaddress3...
The mapping of this line in the nis.mapping file is shown below:
Table: mail.aliases
...
Import:
Extract:
LINE =>$aliasNameT:$aliasListT
Condense:
rfc822mailMembersT=string2instances($aliasListT,",")
trimrfc822mailMembersT=trim($rfc822mailMembersT)
objectClassT=string2instances("top nisMailAlias", " ")
Build:
dn=cn=$aliasNameT,$BASE_DN
cn=$aliasNameT
rfc822mailMember=$trimrfc822mailMembersT
objectClass=$objectClassT
The object class and attributes necessary to create an entry are listed in the Import/Build section of the mapping definition. The values assigned to the LDAP attributes listed in the Build section are taken from the tokens specified in either:
Extract Section
In the Extract section, the keyword LINE shows the initial decomposition of a line in the aliases file. If,in your aliases file you use a punctuation mark other than a colon to separate the alias name from the alias list, you must change the LINE definition to match your file format.
Condense Section
In the Condense section, the token definition for rfc822mailMembersT provides a further decomposition of the alias list. If in your aliases file you use a punctuation mark other than a comma to separate the elements in the alias list, you must change the token definition to match your file format.
The token definition for trimrfc822mailMemberT removes any unnecessary white spaces from the result produced by the preceding string2instances operation on the alias list. The string2instances and trim functions are described in Appendix A, "Mapping Syntax and Semantics.".
The token definition for objectClassT shows the nisMailAlias object class, and the object classes it inherits from, that is the top object class.
Build Section
In the Build section, the DN of the entry is created by concatenating the cn attribute and attribute value with the BASE_DN token. The BASE_DN token identifies the subtree under which the entry is created.
The rfc822mailMember and objectClass attributes are multi-valued. There is one occurrence of these attributes for each value resulting from the string2instances operations.
Example
For example, the aliases file in the domain France.airius.com contains the following line:
dir-team: pdurand, jdupond, asantini, msmith, dphilippe, smartin
The directory entry created from this line in the aliases file is:
dn: cn=dir-team, ou=Aliases, ou=Services, dc=France, dc=airius, dc=com
cn: dir-team
rfc822mailMember: pdurand
rfc822mailMember: jdupond
rfc822mailMember: asantini
rfc822mailMember: msmith
rfc822mailMember: dphilippe
rfc822mailMember: smartin
objectclass: nisMailAlias
objectclass: top
bootparams Mapping
An entry in the bootparams file is usually of the form:
hostname parameter1 parameter2 parameter3...parameterx
For example, the bootparams file in the domain France.airius.com contains the following line:
camembert root=server1:/export/camembert/root \
swap=server1:/export/camembert/swap \
domain=France.airius.com
The directory entry created from this entry in the bootparams file is:
dn: cn=camembert, ou=Hosts, ou=Services, dc=France, dc=airius, dc=com
cn: camembert
bootParameter: root=server1:/export/camembert/root
bootParameter: swap=server1:/export/camembert/swap
bootParameter: domain=France.airius.com
objectClass: top
objectClass: device
objectClass: bootableDevice
The host camembert probably also has an entry in /etc/ethers and in /etc/hosts. However, in the LDAP directory, the host camembert has just one entry, with all the attributes derived from the ethers mapping and the hosts mapping. The LDAP entry created for camembert has several object classes:
Based on the examples given in "ethers Mapping" , and in "hosts Mapping" , the complete entry created in the LDAP directory for host camembert is:
dn: cn=camembert, ou=Hosts, ou=Services, dc=France, dc=airius, dc=com
cn: camembert
cn: bertie
bootParameter: root=server1:/export/camembert/root
bootParameter: swap=server1:/export/camembert/swap
bootParameter: domain=France.airius.com
macAddress: 0:1:23:aa:bb:cc
ipHostNumber: 123.456.789.1
description: SS5 Pierre's desktop
objectClass: top
objectClass: device
objectClass: bootableDevice
objectClass:ieee802Device
objectClass: ipHost
If the entry for camembert is deleted from the bootparams file, the directory entry for camembert is updated by removing the bootableDevice object class and the bootParameter attributes which are specific to that object class.
ethers Mapping
An entry in the ethers file is usually of the form:
ethernetaddress machinename
For example, the ethers file in the domain France.airius.com contains the following line:
0:1:23:aa:bb:cc camembert
The directory entry created from this line in the ethers file is:
dn: cn=camembert, ou=Hosts, ou=Services, dc=France, dc=airius, dc=com
cn: camembert
cn: bertie
macAddress: 0:1:23:aa:bb:cc
objectClass: top
objectClass: device
objectClass:ieee802Device
The host camembert may also have an entry in the etc/bootparams file and the /etc/hosts file. See the example given in "bootparams Mapping" for details of the complete LDAP directory entry created from these files.
group Mapping
An entry in the group file is usually of the form:
groupname:password:groupidnumber:listofmembers
For example, the group file in the domain France.airius.com contains the following line:
sysadmin:yai957KJwXrjc:10:pdurand, jdupond, asantini
The directory entry created from this line in the group file is:
dn: cn=sysadmin, ou=Group, ou=Services, dc=France, dc=airius, dc=com
cn: sysadmin
gidNumber: 10
memberUid: pdurand
memberUid: jdupond
memberUid: asantini
userPassword: {crypt}yai957KJwXrjc
hosts Mapping
An entry in the hosts file is usually of the form:
ipaddress hostname hostaliasnames #hostdescription
For example, the hosts file in the domain France.airius.com contains the following line:
123.456.789.1 camembert bertie # SS5 Pierre's Desktop
The directory entry created from this line in the hosts file is:
dn: cn=camembert, ou=Hosts, ou=Services, dc=France, dc=airius, dc=com
cn: camembert
cn: bertie
ipHostNumber: 123.456.789.1
description: SS5 Pierre's desktop
objectClass: top
objectClass: device
objectClass: ipHost
The host camembert may also have an entry in the /etc/bootparams file and the /etc/ethers file. See the example given in "bootparams Mapping" for details of the complete LDAP directory entry created from these files.
netgroup Mapping
An entry in the netgroup file is usually of the form:
netgroupname grouptriple grouptriple grouptriple grouptriple
where grouptriple is of the form (hostname, username, domainname).
For example, the netgroup file in the domain France.airius.com contains the following line:
printers\
(bordeaux,-,France.airius.com)\
(bourgogne,-,France.airius.com)\
(sauternes,-,France.airius.com)
The directory entry created from this entry in the netgroup file is:
dn: cn=printers, ou=netgroup, ou=Services, dc=France, dc=airius, dc=com
cn: printers
nisNetGroupTriple: bordeaux,-,France.airius.com
nisNetGroupTriple: bourgogne,-,France.airius.com
nisNetGroupTriple: sauternes,-,France.airius.com
networks Mapping
An entry in the networks file is usually of the form:
networkname networkaddress networkalias #description
For example, the networks file in the domain France.airius.com contains the following line:
airius-eng 123.456.789 eng #engineering subnetwork
The directory entry created from this line in the networks file is:
dn: cn=airius-eng, ou=networks, ou=Services, dc=France, dc=airius,
dc=com
cn: airius-eng
cn: eng
ipNetworkNumber: 123.456.789
description: engineering subnetwork
objectClass: top
objectClass: ipNetwork
passwd Mapping
An entry in the passwd file is usually of the form:
userid:userPasswd:uidnumber:gidnumber:gecos:homeDir:shell
When there is a shadow file associated with the passwd file, it is usually of the form:
userid:userPasswd:::::::
The user ID in the passwd file and in the shadow file are identical, but the user's password is actually stored in the shadow file and not in the passwd file.
For example, the passwd file in the domain France.airius.com contains the following line for Pierre Durand:
pdurand:x:12345:67:Pierre Durand-Project Manager:/home/pdurand:/bin/csh
The x instead of the user password indicates that the actual password is stored in the shadow file. The shadow file contains the following line for Pierre Durand:
pdurand:yai957KJwXrjc:::::::
The directory entry created from this line in the passwd file is:
dn: uid=pdurand, ou=People, dc=France, dc=airius, dc=com
cn: Pierre Durand
uid: pdurand
userPassword: {crypt}yai957KJwXrjc
uidNumber: 12345
gidNumber: 67
gecos: Pierre Durand-Project Manager
homeDirectory: /home/pdurand
loginShell: /bin/csh
objectClass: top
objectClass: account
objectClass: posixAccount
protocols Mapping
An entry in the protocols file is usually of the form:
protocolname protocolnumber protocolalias #description
For example, the protocols file in the domain France.airius.com contains the following line:
tcp 0 TCP_Protocol #Transmission Control Protocol
The directory entry created from this line in the protocols file is:
dn: cn=tcp, ou=protocols, ou=Services, dc=France, dc=airius, dc=com
cn: tcp
cn: tcP_Protocol
ipProtocolNumber: 0
description: Transmission Control Protocol
objectClass: top
objectClass: ipProtocol
rpc Mapping
An entry in the rpc file is usually of the form:
programname programnumber protocolalias #description
For example, the rpc file in the domain France.airius.com contains the following line:
yppasswdd 100123 yppasswd
The directory entry created from this line in the rpc file is:
dn: cn=yppasswdd, ou=rpc, ou=Services, dc=France, dc=airius, dc=com
cn: yppasswdd
cn: yppasswd
oncRpcNumber: 100123
objectClass: top
objectClass: oncRpc
ypservers Mapping
In the NIS environment, the ypservers file contains a list of the NIS servers in the domain.
For example, the ypservers file in the domain France.airius.com contains the following list:
brie
camembert
emmental
gorgonzola
roquefort
A directory entry is created for each server listed in the file. For example, the entry created for the server brie is:
dn: cn=brie, ou=ypservers, ou=Services, dc=France, dc=airius, dc=com
cn: brie
objectClass: top
objectClass: sunNisServer