Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Apropos / Subsearch:
optional field

NISLDAPmapping(4)                File Formats                NISLDAPmapping(4)

       NISLDAPmapping - mapping file used by the NIS server components


       The  NISLDAPmapping  file specifies the mapping between NIS map entries
       and equivalent Directory Information Tree (DIT) entries. The syntax  of
       this  file  is  based  on  the  equivalent  NIS+  to LDAP mapping file,

       The presence of /var/yp/NISLDAPmapping on a NIS  master  server  causes
       that  server  to  obtain  NIS  data  from  LDAP.   See  ypserv(4).   If
       /var/yp/NISLDAPmapping is present but the connection configuration file
       that  is  defined  in /etc/default/ypserv cannot be found, a warning is
       logged. See ypserv(1M).

       NIS slave servers always obtain their data from a  NIS  master  server,
       whether  or  not  that server is getting data from LDAP, and ignore the
       /var/yp/NISLDAPmapping file.

       A simple NISLDAPmapping file is created using  inityp2l(1M).   You  can
       customize your NISLDAPmapping file as you require.

       Each  attribute  defined  below  can be specified in/var/yp/NISLDAPmap-
       pingLDAP or as an LDAP attribute.  If  both  are  specified,  then  the
       attribute  in  /var/yp/NISLDAPmapping  (including  empty  values) takes

       A continuation is indicated by a '\' (backslash) in the last  position,
       immediately  before the newline of a line. Characters are escaped, that
       is, exempted from special interpretation, when preceeded  by   a  back-
       slash character.

       The  '#' (hash) character starts a comment. White space is either ASCII
       space or a horizontal tab. In general, lines consist of optional  white
       space,  an  attribute name, at least one white space character,  and an
       attribute value.

   File Syntax
       Repeated fields, with separator characters, are described by  the  fol-
       lowing syntax:

       One or more entries



       Zero or more entries


       Attributes  generally apply to one more more NIS maps. Map names can be
       specified either on their own,that is in passwd.byname, in  which  case
       they  apply to all domains, or for individual NIS domains, for example,
       in passwd.byname,example.sun.uk. Where a map is mentioned in more  than
       one  attribute,  both  versions  are  applied.  If  any  parts  of  the
       attributes are in conflict, the domain specific  version  takes  prece-
       dence over the non-domain specific version.

       Each  domain  specific  attributes must appear in NISLDAPmapping before
       any related  non-domain  specific  attribute.  If  non-domain  specific
       attributes  appear  first,  behavior  may  be unpredictable. Errors are
       logged when non-domain specific attributes are found first.

       You can associate a group of map names with a databaseId. In effect,  a
       macro  is  expanded to the group of names. Use this mechanism where the
       same group of names is used in many attributes or where domain specific
       map  names  are used. Then, you can make any changes to the domain name
       in one place.

       Unless otherwise noted, all elements of the syntaxes below may be  sur-
       rounded  by  white  space. Separator characters and white space must be
       escaped if they are part of syntactic elements.

       The following attributes are recognized.


           The context to use for a NIS domain.

           The syntax for nisLDAPdomainContext is:

           NISDomainName ":" context

           The following is an example of the nisLDAPdomainContext attribute:

           domain.one : dc=site, dc=company, dc=com

           The mapping file should define the context for each  domain  before
           any  other  attribute  makes use of the NISDomainName specified for
           that domain.


           Lists the domains for which password changes should be  made.   NIS
           password  change  requests  do not specify the domains in which any
           given password should be changed. In traditional NIS this  informa-
           tion is effectively hard coded in the NIS makefile.

           The syntax for the nisLDAPyppasswddDomains attribute is:

           domainname[" "...]


           Sets  up an alias for a group of NIS map names. There is no default

           The syntax for the nisLDAPdatabaseIdMapping attribute is:

           databaseId ":" ["["indexlist"]"] mapname[" "...]


           databaseId      = Label identifying a (subset of a) NIS
                             object for mapping purposes.
           indexlist       = fieldspec[","...]
           fieldspec       = fieldname "=" fieldvalue
           fieldname       = The name of a entry field as defined in
           fieldvalue      = fieldvaluestring | \" fieldvaluestring \"

           indexlist is used for those cases where it is necessary to select a
           subset  of entries from a NIS map. The subset are those NIS entries
           that match the indexlist.  If  there  are  multiple  specifications
           indexed  for  a  particular  NIS  map,  they are tried in the order
           retrieved until one matches. Note that retrieval order  usually  is
           unspecified  for  multi-valued  LDAP  attributes.  Hence,  if using
           indexed specifications when nisLDAPdatabaseIdMapping  is  retrieved
           from LDAP, make sure that the subset match is unambiguous.

           If  the  fieldvaluestring  contains  white space or commas, it must
           either be surrounded by double quotes, or  the  special  characters
           must be escaped. Wildcards are allowed in the fieldvaluestring. See

           To associate the  passwd.byname  and  passwd.byuid  maps  with  the
           passwd databaseId:

           passwd:passwd.byname passwd.byuid

           The passwd and passwd.adjunct databaseIds receive special handling.
           In addition to its normal usage, passwd defines which maps  yppass-
           wdd  is to update when a passwd is changed. In addition to its nor-
           mal usage passwd.adjunct defines which maps yppasswdd is to  update
           when an adjunct passwd is changed.

           You  may  not  alias  a single map name to a different name, as the
           results are unpredictable.


           Establish TTLs for NIS entries derived from LDAP.

           The syntax for the nisLDAPentryTtl attribute is:

           mapName[" "...]":"
                   initialTTLlo ":" initialTTLhi ":" runningTTL


           initialTTLlo            The lower limit for  the  initial  TTL  (in
                                   seconds)  for  data read from LDAP when the
                                   ypserv starts. If the initialTTLhi also  is
                                   specified,  the  actual  initialTTL will be
                                   randomly selected from  the  interval  ini-
                                   tialTTLlo   to  initialTTLhi  ,  inclusive.
                                   Leaving the field empty yields the  default
                                   value of 1800 seconds.

           initialTTLhi            The  upper  limit  for  the initial TTL. If
                                   left empty, defaults to 5400.

           runningTTL              The TTL (in  seconds)  for  data  retrieved
                                   from  LDAP  while  the  ypserv  is running.
                                   Leave the field empty to obtain the default
                                   value of 3600 seconds.

           If  there  is  no  specification  of TTLs for a particular map, the
           default values are used.

           If the initialTTLlo and  initialTTLhi  have  the  same  value,  the
           effect  will  be that all data known to the ypserv at startup times
           out at the same time. Depending on NIS data lookup  patterns,  this
           could  cause  spikes  in ypserv-to-LDAP traffic.  In order to avoid
           that, you can specify different initialTTLlo and initialTTLhi  val-
           ues, and obtain a spread in initial TTLs.

           The  following  is an example of the nisLDAPentryTtl attribute used
           to specify that entries in the NIS host maps read from LDAP  should
           be  valid  for  four hours. When ypserv restarts, the disk database
           entries are valid for between two and three  hours.

           hosts.byname hosts.byaddr:7200:10800:14400


           Specifies the connection between a group of NIS maps and  the  LDAP
           directory. This attribute also defines the 'order' of the NIS maps.
           When NIS maps are bulk copied to or from the DIT,  they  are   pro-
           cessed  in  the  same  order  as related nisLDAPobjectDN attributes
           appear in /var/yp/NISLDAPmapping.

           The syntax for the nisLDAPobjectDN attribute is:

           mapName[" "...] ":" objectDN *( ";" objectDN )


           objectDN            = readObjectSpec [":"[writeObjectSpec]]
           readObjectSpec      = [baseAndScope [filterAttrValList]]
           writeObjectSpec     = [baseAndScope [attrValList]]
           baseAndScope        = [baseDN] ["?" [scope]]
           filterAttrValList   = ["?" [filter | attrValList]]]
           scope               = "base" | "one" | "sub"
           attrValList         = attribute "=" value
                                       *("," attribute "=" value)

           The baseDN  defaults  to  the  value  of  the  nisLDAPdomainContext
           attribute  for the accessed domain. If the baseDN ends in a  comma,
           the nisLDAPdomainContext value is appended.

           scope defaults to one. scope has no meaning and  is  ignored  in  a

           The filter is an LDAP search filter and has no default value.

           The attrValList is a list of attribute and value pairs. There is no
           default value.

           As a convenience, if an attrValList is specified in  a  readObject-
           Spec,  it  is  converted  to a search filter by ANDing together the
           attributes and the values. For example,  the  attribute  and  value


           is converted to the filter:


           Map  entries  are  mapped by means of the relevant mapping rules in
           the nisLDAPnameFields and nisLDAPattributeFromField .

           If a writeObjectSpec is omitted, the effect is one of  the  follow-

             o  If  there  is no trailing colon after the readObjectSpec, then
                there is no write at all.

             o  If there is a colon after the  readObjectSpec,  then  writeOb-
                jectSpec equals readObjectSpec.

           The following is an example of a nisLDAPobjectDN attribute declara-
           tion that gets the hosts.byaddr map entries from the ou=Hosts  con-
           tainer under the default search base and writes to the same place.


           The following is an example of a nisLDAPobjectDN attribute declara-
           tion that obtains passwd map entries from the ou=People  containers
           under the default search base, and also from dc=another,dc=domain.



           Specifies  the content of entries in a NIS map and how they  should
           be broken into named fields. nisLDAPnameFields is required  because
           unlike  NIS+, NIS maps do not store information in named fields.

           The syntax for the nisLDAPnameFields attribute is as follows:

           "nisLDAPnameFields" mapName ":" "(" matchspec "," fieldNames ")"
           fieldName       = nameOrArrayName[","...]
           nameOrArrayName = Name of field or 'array' of repeated fields.
           matchspec       = \" formatString \"

           formatString  may  contains  a  list  of %s and %a elements each of
           which represents a single named field or a list of repeated fields.
           A  %a field is interpreted as an IPv4 address or an IPv6 address in
           preferred format. If an IPv6 address in  non  preferred  format  is
           found, then it is converted and a warning  is logged.

           Where  there  are  a  list  of repeated fields, the  entire list is
           stored as one entry. The  fields  are  broken  up  into  individual
           entries,  based on the internal separator, at a latter stage. Other
           characters represent separators which must be present. Any  separa-
           tor,  including  whitespace,  specified by the formatString, may be
           surrounded by a number  of  whitespace  and   tab  characters.  The
           whitespace and tab characters are ignored.

           Regardless  of  the  content  of  this  entry  some  fieldNames are

           rf_key                  The DBM key value

           rf_ipkey                The DBM key value handled as an IP address.
                                   See the discussion of %a fields.

           rf_comment              Everything following the first occurance of
                                   a symbol. rf_comment is defined by nisLDAP-

           rf_domain               The name of the domain in which the current
                                   NIS operation is being carried out.

           rf_searchipkey          The rf_searchkey value  handled  as  an  IP
                                   address.  See  the  discussion of %a fields

           rf_searchkey            See the description under nisLDAPattribute-
                                   FromField below.

           For example, the rpc.bynumber map has the format:

           name number alias[" "...]

           The  NIS  to  LDAP system is instructed to break it into  a name, a
           number, and an array of alias field by the following entry  in  the
           mapping file:

           nisLDAPnameFields rpc.bynumber : \
                   "%s %s %s", name,number,aliases)


           Defines how a field, or list of fields, named by  nisLDAPnameFields
           is split into subfields. The original field is compared  with  each
           line  of  this  attribute  until one matches. When a match is found
           named subfields are generated. In latter operations subfield  names
           can be used in the same way as other field names.

           The syntax for the nisLDAPsplitFields attribute is as follows:

           "nisLDAPsplitFields" fieldName ":" splitSpec[","...]
           splitSpec      = "(" matchspec "," subFieldNames ")"
           fieldName      = Name of a field from nisLDAPnameFields
           subFieldNames  = subFieldname[","...]
           matchspec = \" formatString \"

           The  netgroup memberTriples can have format (host, user, domain) or
           groupname. The format is specified by the attribute:

           nisLDAPsplitField memberTriple: \
                 ("(%s,%s,%s)", host, user, domain) , \
                 ("%s", group)

           Later operations can then use field names host, user, domain, group
           or  memberTriple.  Because  lines  are processed in order, if host,
           user and domain are found, group will not be generated.

           Several maps and databaseIds may contain  fields  that  are  to  be
           split  in the same way. As a consequence, the names of fields to be
           split must be unique across all maps and databaseIds.

           Only one level of spliting is supported.That is, a subfield  cannot
           be split into further subfields.


           Where there is a list of repeated, splitable fields, nisLDAPrepeat-
           edFieldSeparators specifies which characters separate instances  of
           the splitable field.

           The  syntax  for the nisLDAPrepeatedFieldSeparators attribute is as

           "nisLDAPrepeatedFieldSeparators" fieldName \"sepChar[...]\"
           sepChar = A separator character.

           The default value is space or tab. If repeated splitable fields are
           adjacent,  that is, there is no separating character, then the fol-
           lowing should be specified:

           nisLDAPrepeatedFieldSeparators netIdEntry: ""


           Specifies which character represents the start of the special  com-
           ment  field  in  a  given NIS map. If this attribute is not present
           then the default comment character # is used.

           To specify that a map uses a asterix to mark  the  start   of  com-

           nisLDAPcommentChar mapname : '*'

           If  a  map  cannot  contain  comments, then the following attribute
           should be specified.

           nisLDAPcommentChar mapname : ''


            Indicates if YP_INTERDOMAIN or YP_SECURE entries should be created
           in   a   map.   Using  nisLDAPmapFlags  is  equivalent  to  running
           makedbm(1M) with the -b or the -s option. When  a  map  is  created
           from  the  contents  of  the DIT, the mapping file attribute is the
           only source for the YP_INTERDOMAIN or YP_SECURE entries.

           The syntax for the nisLDAPmapFlags attribute is as follows:

           "nisLDAPmapFlags" mapname ":" ["b"]["s"]

           By default neither entry is created.


           Specifies how a NIS entries field  values  are  derived  from  LDAP
           attribute values.

           The  syntax  for the nisLDAPfieldFromAttribute attribute is as fol-

           mapName ":" fieldattrspec *("," fieldattrspec)

           The format of fieldattrspec is shown below at Field  and  Attribute
           Conversion Syntax.

           To  map by direct copy and assignment the value of the ipHostNumber
           attribute to the addr named field, for example:


           Formats for the named field and  attribute  conversion  syntax  are
           discussed  below,  including examples of complex attribute to field


            Specifies how an LDAP attribute value is derived from a NIS entriy
           field value.

           The  syntax  for the nisLDAPattributeFromField attribute is as fol-

           mapName ":" fieldattrspec *("," fieldattrspec )

           The format of fieldattrspec is shown below at Field  and  Attribute
           Conversion Syntax.

           As  a special case, if the dn attribute value derived from a field-
           attrspec ends in a comma (","), the domains context from nisLDAPdo-
           mainContext is appended.

           Use the following example to map the value of the addr field to the
           ipHostNumber attribute by direct copy and assignment:


           All relevant attributes, including the dn, must  be specified.

           For every map it must be possible  to  rapidly  find  a  DIT  entry
           based  on its key. There are some maps for which a NIS to LDAP map-
           ping for the key is not desirable, so a key mapping cannot be spec-
           ified. In these cases a mapping that uses the reserved rf_searchkey
           must be specified.  Mappings that use this field name  are  ignored
           when information is mapped into the DIT.

   Field and Attribute Conversion Syntax
       The general format of a fieldattrspec is:

       fieldattrspec     = lhs "=" rhs
       lhs               = lval | namespeclist
       rhs               = rval | [namespec]
       namespeclist      = namespec | "(" namespec *("," namespec) ")"

       The lval and rval syntax are defined below at  Values.  The format of a
       namespec is:

                       ["ldap:"] attrspec [searchTriple] | ["yp:"] fieldname

                       field | "(" field ")"

                       attribute | "(" attribute ")"

                       ":" [baseDN] ["?" [scope] ["?" [filter]]]

       baseDN          Base DN for search

       filter          LDAP search filter

       mapspec         Map name

       The repository specification in a namespec defaults is as  follows:

         o  For assignments to a field:

            on the LHS      yp

            on the RHS      ldap

            NIS field values on the RHS are those that  exist before  the  NIS
            entry is modified.

         o  For assignments to an attribute:

            on the LHS      ldap

            on the RHS      yp

            Attribute  values  on the RHS are those that exist before the LDAP
            entry is modified.

       When the field or attribute name is enclosed in parenthesis, it denotes
       a list of field or attribute values. For attributes, the meaning is the
       list of all attributes of  that name, and the interpretation depends on
       the  context. See the discussion at Values.  The list specification  is
       ignored when a searchTriple or mapspec is supplied.

       For fields, the fieldname syntax is  used  to  map  multiple  attribute
       instances to multiple NIS entries.

       The  searchTriple  can  be used to specify an attribute from a location
       other than the read or write target. The defaultvalues are as follows:

       baseDN          If baseDN  is  omitted,  the  default  is  the  current
                       objectDN. If the baseDN ends in a comma, the context of
                       the domain is appended from nisLDAPdomainContext .

       scope           one

       filter          Empty

       Similarly, the mapspec can be used to specify a field value from a  NIS
       map  other  than  the  one  implicitly  indicated  by  the  mapName. If
       searchTriple or  mapspec is explicitly specified  in  a  namespec,  the
       retrieval  or assignment, whether from or to LDAP or NIS, is  performed
       without checking if read and write are enabled for the  LDAP  container
       or NIS map.

       The  ommision  of  the namespec in an rhs is only allowed if the lhs is
       one  or  more  attributes.  The  effect  is  to  delete  the  specified
       attribute(s).  In  all other situations, an omitted namespec means that
       the rule is ignored.

       The filter can be a value. See Values. For example, to find the ipHost-
       Numberthat uses the cn, you specify the following in the filter field:

       ldap:ipHostNumber:?one?("cn=%s", (cname, "%s.*"))

       In order to remove ambiguity, the unmodified value of a single field or
       attribute must be specified as the following when used in  the   filter

       ("%s", namespec)

       If  the filter is not specified, the scope will be base, and the baseDN
       is  assumed to be the DN of the entry that contains the attribute to be
       retrieved  or  modified.  To use previously existing field or attribute
       values in the mapping rules requires a lookup  to  find  those  values.
       Obviously,  this adds to the time required to perform the modification.
       Also, there is a window between the time when a value is retrieved  and
       then slightly later stored back. If the values have changed in the mean
       time, the change  may be overwritten.

       When fieldattrspecs are grouped into rule  sets,  in  the  value  of  a
       nisLDAPfieldFromAttribute  or  nisLDAPattributeFromField attribute, the
       evaluation of the fieldattrspecs proceed in the listed order.  However,
       evaluation  may  be  done  in  parallel for multiple fieldattrspecs. If
       there is an error when evaluating a  certain  fieldattrspec,  including
       retrieval  or  assignment of entry or field values, the extent to which
       the other fieldattrspec rules are evaluated is unspecified.

       Where wildcard support is available, it is  of  the  following  limited

       *        Matches any number of characters

       [x]      Matches the character x

       [x-y]    Matches any character in the range x to y, inclusive

       Combinations  such  as [a-cA-C0123] are also allowed, which would match
       any one of a, b, c, A, B, C, 0, 1, 2, or 3.

   Substring Extraction
       substringextract = "(" namespec "," matchspec ")"
       name             = field or attribute name
       matchspec        =

       The matchspec is a string like the  sscanf(3C)  format  string,  except
       that there may be at most one format specifier, a single %s. The output
       value of the substringextract  is  the substring that matches the loca-
       tion of the %s.

       If  there  is  no  %s in the formatstring, it must instead be  a single
       character, which is assumed to be a field separator for  the  namespec.
       The  output  values  are the field values. Wild cards are supported. If
       there is no match, the output value is the empty string, "".

       For example, if the fieldcname has  the  value  user.some.domain.name.,
       the value of the expression:

       (cname, "%s.*")

       is  user, which can be used to extract the user name  from  a NIS prin-
       cipal name.

       Similarly, use this expression to extract the third  of  the colon-sep-
       arated fields of the shadow field:

       (shadow, "*:*:%s:*")

       This  form  can be used to extract all of the shadow fields. However, a
       simpler way to specify that special case is:

       (shadow, ":")

       lval            = "(" formatspec "," namespec *("," namespec) ")"
       rval            = "(" formatspec ["," namelist ["," elide] ] ")"

       namelist        = name_or_sse *( "," name_or_sse)
       name_or_sse     = namespec | removespec | substringextract
       removespec      = list_or_name "-" namespec
       list_or_name    = "(" namespec ")" | namespec
       formatspec      =
       formatstring    = A string combining text and % field specifications
       elide           =
       singlechar      = Any character

       The syntax above is used to produce rval values that incorporate  field
       or  attribute  values,  in  a  manner  like  sprintf(3C), or to perform
       assignments to lval like sscanf(3C). One important restriction is  that
       the  format  specifications,% plus a single character, use the designa-
       tions from ber_printf(3LDAP). Thus, while  %s  is  used  to  extract  a
       string  value, %i causes BER conversion from  an integer. Formats other
       than %s, for instance, %i, are only meaningfully defined in simple for-
       mat strings without any other text.

       The following ber_printf() format characters are recognized:

       b  i  n  o  s

       If  there  are  too  few  format  specifiers,  the format string may be
       repeated as needed.

       When used as an lval, there is a combination of  pattern  matching  and
       assignment, possibly to multiple fields or attributes.

       In  an  assignment  to an attribute, if the  value of the addr field is, the rval:

       ("ipNetworkNumber=%s,", addr)

       produces the value ipNetworkNumber=,, while:

       ("(%s,%s,%s)", host, user, domain)

       results in:

       (assuming host="xyzzy", user="-", domain="x.y.z")

       The elide character feature is used with attribute lists. So:

       ("%s,", (mgrprfc822mailmember), ",")

       concatenates all mgrprfc822mailmember values into  one  comma-separated
       string, and then elides the final trailing comma. Thus, for


       the value would be:


       As  a  special case, to combine an LHS extraction with an  RHS implicit
       list creates multiple entries and values. So

       ("(%s,%s,%s)", host, user, domain)=(nisNetgroupTriple)

       creates one NIS entry for each nisNetgroupTriple value.

       The 'removespec' form is used to  exclude  previously  assigned  fields
       values from a list. So, if an LDAP entry contains:

       name: foo
       cn: foo
       cn: foo1
       cn: foo2

       and the mapping file specifies :

       myName = name, \
       myAliases = ("%s ", (cn) - yp:myName, " ")

       then the following assignments are carried out:

       1.  Assign value foo to myName

       2.  Assign value foo foo1 foo2 to myAliases

       3.  Remove value of myName from value myAliases

       This  results  in the field values myName is set to foo,  and myAliases
       is set to foo1 foo2.

       The assignment syntax, also found at  Field  and  Attribute  Conversion
       Syntax, is as follows:

       fieldattrspec    = lhs "=" rhs
       lhs              = lval | namespeclist
       rhs              = rval | namespec
       namespeclist     = namespec | "(" namespec *("," namespec) ")"

       The  general form of a simple assignment, which is a one-to-one mapping
       of field to attribute, is:

       ("%s", fieldname)=("%s", attrname)

       As a convenient shorthand, this can also be written as:


       A list specification, which is a name enclosed in parenthesis,  can  be
       used to make many-to-many assignments. The expression:


       where  there  are multiple instances of attrname, creates one NIS entry
       for each such instance, differentiated by their fieldname  values.  The
       following  combinations of lists are allowed, but they are not particu-
       larly useful:

       (attrname)=(fieldname)          Equivalent to attrname=fieldname

       attrname=(fieldname)            Equivalent to attrname=fieldname

       (fieldname)=attrname            Equivalent to fieldname=attrname

       fieldname=(attrname)            Equivalent to fieldname=attrname

       If a multi-valued RHS is assigned to a single-valued LHS, the LHS value
       will  be  the first of the RHS values. If the RHS is an attribute list,
       the first attribute is the first one returned by the LDAP  server  when
       queried.  Otherwise, the definition of "first" is implementation depen-

       Finally, the LHS can be an explicit list of fields or attributes,  such


       If the RHS is single-valued, this assigns the RHS value to all entities
       in the list. If the RHS is multi-valued, the first value is assigned to
       the  first  entity  of the list, the second value to the second entity,
       and so on. Excess values or entities are silently ignored.

       Example 1: Assigning an Attribute Value to a Field

       The following example illustrates  how  to  assign  the  value  of  the
       ipHostNumber attribute to the addr field


       Example  2:  Creating  Multiple  NIS  Entries  from  Multi-Valued  LDAP

       An LDAP entry with:


       and the following assignments:


       creates three NIS entries. Other attributes and fields are omitted  for

       cname=name1, name=name1
       cname=name1, name=name2
       cname=name1, name=name3

       Example 3: Assigning String Constants

       The following expression sets the passwd field to x:


       Example 4: Splitting Field Values to Multi-Valued Attributes

       The  expansion  field  contains  a comma-separated list of alias member
       names. In the following example, the  expression  assigns  each  member
       name to an instance of mgrprfc822mailmember:

       (mgrprfc822mailmember)=(expansion, ",")

       /var/yp/NISLDAPmapping          Mapping  file  used  by  the NIS server

       See attributes(5)  for descriptions of the following attributes:

       tab()    allbox;    cw(2.750000i)|     cw(2.750000i)     lw(2.750000i)|
       lw(2.750000i).    ATTRIBUTE   TYPEATTRIBUTE  VALUE  AvailabilitySUNWypu
       Interface Stability Obsolete

       inityp2l(1M), makedbm(1M), ypserv(1M), ber_printf(3LDAP),  sprintf(3C),
       sscanf(3C), NIS+LDAPmapping(4), ypserv(4), attributes(5)

       System  Administration  Guide: Naming and Directory Services (DNS, NIS,
       and LDAP)

SunOS 5.10                        21 Apr 2003                NISLDAPmapping(4)