1 NISLDAPMAPPING(4) File Formats and Configurations NISLDAPMAPPING(4)
2
3
4
5 NAME
6 NISLDAPmapping - mapping file used by the NIS server components
7
8 SYNOPSIS
9 /var/yp/NISLDAPmapping
10
11
12 DESCRIPTION
13 The NISLDAPmapping file specifies the mapping between NIS map entries
14 and equivalent Directory Information Tree (DIT) entries.
15
16
17 The presence of /var/yp/NISLDAPmapping on a NIS master server causes
18 that server to obtain NIS data from LDAP. See ypserv(4). If
19 /var/yp/NISLDAPmapping is present but the connection configuration file
20 that is defined in /etc/default/ypserv cannot be found, a warning is
21 logged. See ypserv(1M).
22
23
24 NIS slave servers always obtain their data from a NIS master server,
25 whether or not that server is getting data from LDAP, and ignore the
26 /var/yp/NISLDAPmapping file.
27
28
29 A simple NISLDAPmapping file is created using inityp2l(1M). You can
30 customize your NISLDAPmapping file as you require.
31
32
33 Each attribute defined below can be specified
34 in/var/yp/NISLDAPmappingLDAP or as an LDAP attribute. If both are
35 specified, then the attribute in /var/yp/NISLDAPmapping (including
36 empty values) takes precedence.
37
38
39 A continuation is indicated by a '\' (backslash) in the last position,
40 immediately before the newline of a line. Characters are escaped, that
41 is, exempted from special interpretation, when preceded by a backslash
42 character.
43
44
45 The '#' (hash) character starts a comment. White space is either ASCII
46 space or a horizontal tab. In general, lines consist of optional white
47 space, an attribute name, at least one white space character, and an
48 attribute value.
49
50 EXTENDED DESCRIPTION
51 File Syntax
52 Repeated fields, with separator characters, are described by the
53 following syntax:
54
55 One or more entries
56 entry:entry:entry
57
58 entry[":"...]
59
60
61
62 Zero or more entries
63
64 [entry":"...]
65
66
67
68 Attributes
69 Attributes generally apply to one more more NIS maps. Map names can be
70 specified either on their own,that is in passwd.byname, in which case
71 they apply to all domains, or for individual NIS domains, for example,
72 in passwd.byname,example.sun.uk. Where a map is mentioned in more than
73 one attribute, both versions are applied. If any parts of the
74 attributes are in conflict, the domain specific version takes
75 precedence over the non-domain specific version.
76
77
78 Each domain specific attributes must appear in NISLDAPmapping before
79 any related non-domain specific attribute. If non-domain specific
80 attributes appear first, behavior may be unpredictable. Errors are
81 logged when non-domain specific attributes are found first.
82
83
84 You can associate a group of map names with a databaseId. In effect, a
85 macro is expanded to the group of names. Use this mechanism where the
86 same group of names is used in many attributes or where domain specific
87 map names are used. Then, you can make any changes to the domain name
88 in one place.
89
90
91 Unless otherwise noted, all elements of the syntaxes below may be
92 surrounded by white space. Separator characters and white space must be
93 escaped if they are part of syntactic elements.
94
95
96 The following attributes are recognized.
97
98 nisLDAPdomainContext
99
100 The context to use for a NIS domain.
101
102 The syntax for nisLDAPdomainContext is:
103
104 NISDomainName ":" context
105
106 The following is an example of the nisLDAPdomainContext attribute:
107
108 domain.one : dc=site, dc=company, dc=com
109
110 The mapping file should define the context for each domain before
111 any other attribute makes use of the NISDomainName specified for
112 that domain.
113
114
115 nisLDAPyppasswddDomains
116
117 Lists the domains for which password changes should be made. NIS
118 password change requests do not specify the domains in which any
119 given password should be changed. In traditional NIS this
120 information is effectively hard coded in the NIS makefile.
121
122 The syntax for the nisLDAPyppasswddDomains attribute is:
123
124 domainname
125
126 If there are multiple domains, use multiple nisLDAPyppasswddDomain
127 entries with one domainname per entry.
128
129
130 nisLDAPdatabaseIdMapping
131
132 Sets up an alias for a group of NIS map names. There is no default
133 value.
134
135 The syntax for the nisLDAPdatabaseIdMapping attribute is:
136
137 databaseId ":" ["["indexlist"]"] mapname[" "...]
138
139 where
140
141 databaseId = Label identifying a (subset of a) NIS
142 object for mapping purposes.
143 indexlist = fieldspec[","...]
144 fieldspec = fieldname "=" fieldvalue
145 fieldname = The name of a entry field as defined in
146 nisLDAPnameFields.
147 fieldvalue = fieldvaluestring | \" fieldvaluestring \"
148
149 indexlist is used for those cases where it is necessary to select a
150 subset of entries from a NIS map. The subset are those NIS entries
151 that match the indexlist. If there are multiple specifications
152 indexed for a particular NIS map, they are tried in the order
153 retrieved until one matches. Note that retrieval order usually is
154 unspecified for multi-valued LDAP attributes. Hence, if using
155 indexed specifications when nisLDAPdatabaseIdMapping is retrieved
156 from LDAP, make sure that the subset match is unambiguous.
157
158 If the fieldvaluestring contains white space or commas, it must
159 either be surrounded by double quotes, or the special characters
160 must be escaped. Wildcards are allowed in the fieldvaluestring.
161 See Wildcards
162
163 To associate the passwd.byname and passwd.byuid maps with the
164 passwd databaseId:
165
166 passwd:passwd.byname passwd.byuid
167
168 The passwd and passwd.adjunct databaseIds receive special handling.
169 In addition to its normal usage, passwd defines which maps
170 yppasswdd is to update when a passwd is changed. In addition to its
171 normal usage passwd.adjunct defines which maps yppasswdd is to
172 update when an adjunct passwd is changed.
173
174 You may not alias a single map name to a different name, as the
175 results are unpredictable.
176
177
178 nisLDAPentryTtl
179
180 Establish TTLs for NIS entries derived from LDAP.
181
182 The syntax for the nisLDAPentryTtl attribute is:
183
184 mapName[" "...]":"
185 initialTTLlo ":" initialTTLhi ":" runningTTL
186
187 where
188
189 initialTTLlo
190 The lower limit for the initial TTL (in seconds)
191 for data read from LDAP when the ypserv starts. If
192 the initialTTLhi also is specified, the actual
193 initialTTL will be randomly selected from the
194 interval initialTTLlo to initialTTLhi , inclusive.
195 Leaving the field empty yields the default value of
196 1800 seconds.
197
198
199 initialTTLhi
200 The upper limit for the initial TTL. If left empty,
201 defaults to 5400.
202
203
204 runningTTL
205 The TTL (in seconds) for data retrieved from LDAP
206 while the ypserv is running. Leave the field empty
207 to obtain the default value of 3600 seconds.
208
209 If there is no specification of TTLs for a particular map, the
210 default values are used.
211
212 If the initialTTLlo and initialTTLhi have the same value, the
213 effect will be that all data known to the ypserv at startup times
214 out at the same time. Depending on NIS data lookup patterns, this
215 could cause spikes in ypserv-to-LDAP traffic. In order to avoid
216 that, you can specify different initialTTLlo and initialTTLhi
217 values, and obtain a spread in initial TTLs.
218
219 The following is an example of the nisLDAPentryTtl attribute used
220 to specify that entries in the NIS host maps read from LDAP should
221 be valid for four hours. When ypserv restarts, the disk database
222 entries are valid for between two and three hours.
223
224 hosts.byname hosts.byaddr:7200:10800:14400
225
226
227
228 nisLDAPobjectDN
229
230 Specifies the connection between a group of NIS maps and the LDAP
231 directory. This attribute also defines the 'order' of the NIS
232 maps. When NIS maps are bulk copied to or from the DIT, they are
233 processed in the same order as related nisLDAPobjectDN attributes
234 appear in /var/yp/NISLDAPmapping.
235
236 The syntax for the nisLDAPobjectDN attribute is:
237
238 mapName[" "...] ":" objectDN *( ";" objectDN )
239
240 where
241
242 objectDN = readObjectSpec [":"[writeObjectSpec]]
243 readObjectSpec = [baseAndScope [filterAttrValList]]
244 writeObjectSpec = [baseAndScope [attrValList]]
245 baseAndScope = [baseDN] ["?" [scope]]
246 filterAttrValList = ["?" [filter | attrValList]]]
247 scope = "base" | "one" | "sub"
248 attrValList = attribute "=" value
249 *("," attribute "=" value)
250
251 The baseDN defaults to the value of the nisLDAPdomainContext
252 attribute for the accessed domain. If the baseDN ends in a comma,
253 the nisLDAPdomainContext value is appended.
254
255 scope defaults to one. scope has no meaning and is ignored in a
256 writeObjectSpec.
257
258 The filter is an LDAP search filter and has no default value.
259
260 The attrValList is a list of attribute and value pairs. There is no
261 default value.
262
263 As a convenience, if an attrValList is specified in a
264 readObjectSpec, it is converted to a search filter by ANDing
265 together the attributes and the values. For example, the attribute
266 and value list:
267
268 objectClass=posixAccount,objectClass=shadowAccount
269
270 is converted to the filter:
271
272 (&(objectClass=posixAccount)\
273 (objectClass=shadowAccount))
274
275 Map entries are mapped by means of the relevant mapping rules in
276 the nisLDAPnameFields and nisLDAPattributeFromField .
277
278 If a writeObjectSpec is omitted, the effect is one of the
279 following:
280
281 o If there is no trailing colon after the readObjectSpec,
282 then there is no write at all.
283
284 o If there is a colon after the readObjectSpec, then
285 writeObjectSpec equals readObjectSpec.
286 The following is an example of a nisLDAPobjectDN attribute
287 declaration that gets the hosts.byaddr map entries from the
288 ou=Hosts container under the default search base and writes to the
289 same place.
290
291 hosts.byaddr:ou=Hosts,?one?objectClass=ipHost:
292
293 The following is an example of a nisLDAPobjectDN attribute
294 declaration that obtains passwd map entries from the ou=People
295 containers under the default search base, and also from
296 dc=another,dc=domain.
297
298 passwd:ou=People,?one?\
299 objectClass=shadowAccount,\
300 objectClass=posixAccount:;\
301 ou=People,dc=another,dc=domain,?one?\
302 objectClass=shadowAccount,\
303 objectClass=posixAccount
304
305
306
307 nisLDAPnameFields
308
309 Specifies the content of entries in a NIS map and how they should
310 be broken into named fields. nisLDAPnameFields is required because
311 NIS maps do not store information in named fields.
312
313 The syntax for the nisLDAPnameFields attribute is as follows:
314
315 "nisLDAPnameFields" mapName ":" "(" matchspec "," fieldNames ")"
316 fieldName = nameOrArrayName[","...]
317 nameOrArrayName = Name of field or 'array' of repeated fields.
318 matchspec = \" formatString \"
319
320 formatString may contains a list of %s and %a elements each of
321 which represents a single named field or a list of repeated fields.
322 A %a field is interpreted as an IPv4 address or an IPv6 address in
323 preferred format. If an IPv6 address in non preferred format is
324 found, then it is converted and a warning is logged.
325
326 Where there are a list of repeated fields, the entire list is
327 stored as one entry. The fields are broken up into individual
328 entries, based on the internal separator, at a latter stage. Other
329 characters represent separators which must be present. Any
330 separator, including whitespace, specified by the formatString, may
331 be surrounded by a number of whitespace and tab characters. The
332 whitespace and tab characters are ignored.
333
334 Regardless of the content of this entry some fieldNames are
335 reserved:
336
337 rf_key
338 The DBM key value
339
340
341 rf_ipkey
342 The DBM key value handled as an IP address. See
343 the discussion of %a fields.
344
345
346 rf_comment
347 Everything following the first occurrence of a
348 symbol. rf_comment is defined by
349 nisLDAPcommentChar.
350
351
352 rf_domain
353 The name of the domain in which the current NIS
354 operation is being carried out.
355
356
357 rf_searchipkey
358 The rf_searchkey value handled as an IP address.
359 See the discussion of %a fields above.
360
361
362 rf_searchkey
363 See the description under
364 nisLDAPattributeFromField below.
365
366 For example, the rpc.bynumber map has the format:
367
368 name number alias[" "...]
369
370 The NIS to LDAP system is instructed to break it into a name, a
371 number, and an array of alias field by the following entry in the
372 mapping file:
373
374 nisLDAPnameFields rpc.bynumber : \
375 "%s %s %s", name,number,aliases)
376
377
378
379 nisLDAPsplitFields
380
381 Defines how a field, or list of fields, named by nisLDAPnameFields
382 is split into subfields. The original field is compared with each
383 line of this attribute until one matches. When a match is found
384 named subfields are generated. In latter operations subfield names
385 can be used in the same way as other field names.
386
387 The syntax for the nisLDAPsplitFields attribute is as follows:
388
389 "nisLDAPsplitFields" fieldName ":" splitSpec[","...]
390 splitSpec = "(" matchspec "," subFieldNames ")"
391 fieldName = Name of a field from nisLDAPnameFields
392 subFieldNames = subFieldname[","...]
393 matchspec = \" formatString \"
394
395 The netgroup memberTriples can have format (host, user, domain) or
396 groupname. The format is specified by the attribute:
397
398 nisLDAPsplitField memberTriple: \
399 ("(%s,%s,%s)", host, user, domain) , \
400 ("%s", group)
401
402 Later operations can then use field names host, user, domain, group
403 or memberTriple. Because lines are processed in order, if host,
404 user and domain are found, group will not be generated.
405
406 Several maps and databaseIds may contain fields that are to be
407 split in the same way. As a consequence, the names of fields to be
408 split must be unique across all maps and databaseIds.
409
410 Only one level of splitting is supported. That is, a subfield
411 cannot be split into further subfields.
412
413
414 nisLDAPrepeatedFieldSeparators
415
416 Where there is a list of repeated, splittable fields,
417 nisLDAPrepeatedFieldSeparators specifies which characters separate
418 instances of the splittable field.
419
420 The syntax for the nisLDAPrepeatedFieldSeparators attribute is as
421 follows:
422
423 "nisLDAPrepeatedFieldSeparators" fieldName \"sepChar[...]\"
424 sepChar = A separator character.
425
426 The default value is space or tab. If repeated splittable fields
427 are adjacent, that is, there is no separating character, then the
428 following should be specified:
429
430 nisLDAPrepeatedFieldSeparators netIdEntry: ""
431
432
433
434 nisLDAPcommentChar
435
436 Specifies which character represents the start of the special
437 comment field in a given NIS map. If this attribute is not present
438 then the default comment character # is used.
439
440 To specify that a map uses a asterix to mark the start of comments.
441
442 nisLDAPcommentChar mapname : '*'
443
444 If a map cannot contain comments, then the following attribute
445 should be specified.
446
447 nisLDAPcommentChar mapname : ''
448
449
450
451 nisLDAPmapFlags
452
453 Indicates if YP_INTERDOMAIN or YP_SECURE entries should be created
454 in a map. Using nisLDAPmapFlags is equivalent to running
455 makedbm(1M) with the -b or the -s option. When a map is created
456 from the contents of the DIT, the mapping file attribute is the
457 only source for the YP_INTERDOMAIN or YP_SECURE entries.
458
459 The syntax for the nisLDAPmapFlags attribute is as follows:
460
461 "nisLDAPmapFlags" mapname ":" ["b"]["s"]
462
463 By default neither entry is created.
464
465
466 nisLDAPfieldFromAttribute
467
468 Specifies how a NIS entries field values are derived from LDAP
469 attribute values.
470
471 The syntax for the nisLDAPfieldFromAttribute attribute is as
472 follows:
473
474 mapName ":" fieldattrspec *("," fieldattrspec)
475
476 The format of fieldattrspec is shown below at Field and Attribute
477 Conversion Syntax.
478
479 To map by direct copy and assignment the value of the ipHostNumber
480 attribute to the addr named field, for example:
481
482 addr=ipHostNumber
483
484 Formats for the named field and attribute conversion syntax are
485 discussed below, including examples of complex attribute to field
486 conversions.
487
488
489 nisLDAPattributeFromField
490
491 Specifies how an LDAP attribute value is derived from a NIS entriy
492 field value.
493
494 The syntax for the nisLDAPattributeFromField attribute is as
495 follows:
496
497 mapName ":" fieldattrspec *("," fieldattrspec )
498
499 The format of fieldattrspec is shown below at Field and Attribute
500 Conversion Syntax.
501
502 As a special case, if the dn attribute value derived from a
503 fieldattrspec ends in a comma (","), the domains context from
504 nisLDAPdomainContext is appended.
505
506 Use the following example to map the value of the addr field to the
507 ipHostNumber attribute by direct copy and assignment:
508
509 ipHostNumber=addr
510
511 All relevant attributes, including the dn, must be specified.
512
513 For every map it must be possible to rapidly find a DIT entry based
514 on its key. There are some maps for which a NIS to LDAP mapping
515 for the key is not desirable, so a key mapping cannot be specified.
516 In these cases a mapping that uses the reserved rf_searchkey must
517 be specified. Mappings that use this field name are ignored when
518 information is mapped into the DIT.
519
520
521 Field and Attribute Conversion Syntax
522 The general format of a fieldattrspec is:
523
524 fieldattrspec = lhs "=" rhs
525 lhs = lval | namespeclist
526 rhs = rval | [namespec]
527 namespeclist = namespec | "(" namespec *("," namespec) ")"
528
529
530
531 The lval and rval syntax are defined below at Values. The format of a
532 namespec is:
533
534 namespec
535
536 ["ldap:"] attrspec [searchTriple] | ["yp:"] fieldname
537 [mapspec]
538
539
540
541 fieldname
542
543 field | "(" field ")"
544
545
546
547 attrspec
548
549 attribute | "(" attribute ")"
550
551
552
553 searchTriple
554
555 ":" [baseDN] ["?" [scope] ["?" [filter]]]
556
557
558
559 baseDN
560 Base DN for search
561
562
563 filter
564 LDAP search filter
565
566
567 mapspec
568 Map name
569
570
571
572 The repository specification in a namespec defaults is as follows:
573
574 o For assignments to a field:
575
576
577 on the LHS
578 yp
579
580
581 on the RHS
582 ldap
583
584
585 NIS field values on the RHS are those that exist before the NIS
586 entry is modified.
587
588 o For assignments to an attribute:
589
590
591 on the LHS
592 ldap
593
594
595 on the RHS
596 yp
597
598
599 Attribute values on the RHS are those that exist before the LDAP
600 entry is modified.
601
602
603 When the field or attribute name is enclosed in parenthesis, it denotes
604 a list of field or attribute values. For attributes, the meaning is the
605 list of all attributes of that name, and the interpretation depends on
606 the context. See the discussion at Values. The list specification is
607 ignored when a searchTriple or mapspec is supplied.
608
609
610 For fields, the fieldname syntax is used to map multiple attribute
611 instances to multiple NIS entries.
612
613
614 The searchTriple can be used to specify an attribute from a location
615 other than the read or write target. The defaultvalues are as follows:
616
617 baseDN
618 If baseDN is omitted, the default is the current objectDN. If
619 the baseDN ends in a comma, the context of the domain is
620 appended from nisLDAPdomainContext .
621
622
623 scope
624 one
625
626
627 filter
628 Empty
629
630
631
632 Similarly, the mapspec can be used to specify a field value from a NIS
633 map other than the one implicitly indicated by the mapName. If
634 searchTriple or mapspec is explicitly specified in a namespec, the
635 retrieval or assignment, whether from or to LDAP or NIS, is performed
636 without checking if read and write are enabled for the LDAP container
637 or NIS map.
638
639
640 The omission of the namespec in an rhs is only allowed if the lhs is
641 one or more attributes. The effect is to delete the specified
642 attribute(s). In all other situations, an omitted namespec means that
643 the rule is ignored.
644
645
646 The filter can be a value. See Values. For example, to find the
647 ipHostNumberthat uses the cn, you specify the following in the filter
648 field:
649
650 ldap:ipHostNumber:?one?("cn=%s", (cname, "%s.*"))
651
652
653
654 In order to remove ambiguity, the unmodified value of a single field or
655 attribute must be specified as the following when used in the filter
656 field.
657
658 ("%s", namespec)
659
660
661
662 If the filter is not specified, the scope will be base, and the baseDN
663 is assumed to be the DN of the entry that contains the attribute to be
664 retrieved or modified. To use previously existing field or attribute
665 values in the mapping rules requires a lookup to find those values.
666 Obviously, this adds to the time required to perform the modification.
667 Also, there is a window between the time when a value is retrieved and
668 then slightly later stored back. If the values have changed in the mean
669 time, the change may be overwritten.
670
671
672 When fieldattrspecs are grouped into rule sets, in the value of a
673 nisLDAPfieldFromAttribute or nisLDAPattributeFromField attribute, the
674 evaluation of the fieldattrspecs proceed in the listed order. However,
675 evaluation may be done in parallel for multiple fieldattrspecs. If
676 there is an error when evaluating a certain fieldattrspec, including
677 retrieval or assignment of entry or field values, the extent to which
678 the other fieldattrspec rules are evaluated is unspecified.
679
680 Wildcards
681 Where wildcard support is available, it is of the following limited
682 form:
683
684 *
685 Matches any number of characters
686
687
688 [x]
689 Matches the character x
690
691
692 [x-y]
693 Matches any character in the range x to y, inclusive
694
695
696
697 Combinations such as [a-cA-C0123] are also allowed, which would match
698 any one of a, b, c, A, B, C, 0, 1, 2, or 3.
699
700 Substring Extraction
701 substringextract = "(" namespec "," matchspec ")"
702 name = field or attribute name
703 matchspec =
704
705
706
707 The matchspec is a string like the sscanf(3C) format string, except
708 that there may be at most one format specifier, a single %s. The output
709 value of the substringextract is the substring that matches the
710 location of the %s.
711
712
713 If there is no %s in the formatstring, it must instead be a single
714 character, which is assumed to be a field separator for the namespec.
715 The output values are the field values. Wild cards are supported. If
716 there is no match, the output value is the empty string, " ".
717
718
719 For example, if the fieldcname has the value user.some.domain.name.,
720 the value of the expression:
721
722 (cname, "%s.*")
723
724
725
726 is user, which can be used to extract the user name from a NIS
727 principal name.
728
729
730 Similarly, use this expression to extract the third of the colon-
731 separated fields of the shadow field:
732
733 (shadow, "*:*:%s:*")
734
735
736
737 This form can be used to extract all of the shadow fields. However, a
738 simpler way to specify that special case is:
739
740 (shadow, ":")
741
742
743 Values
744 lval = "(" formatspec "," namespec *("," namespec) ")"
745 rval = "(" formatspec ["," namelist ["," elide] ] ")"
746
747 namelist = name_or_sse *( "," name_or_sse)
748 name_or_sse = namespec | removespec | substringextract
749 removespec = list_or_name "-" namespec
750 list_or_name = "(" namespec ")" | namespec
751 formatspec =
752 formatstring = A string combining text and % field specifications
753 elide =
754 singlechar = Any character
755
756
757
758 The syntax above is used to produce rval values that incorporate field
759 or attribute values, in a manner like sprintf(3C), or to perform
760 assignments to lval like sscanf(3C). One important restriction is that
761 the format specifications,% plus a single character, use the
762 designations from ber_printf(3LDAP). Thus, while %s is used to extract
763 a string value, %i causes BER conversion from an integer. Formats other
764 than %s, for instance, %i, are only meaningfully defined in simple
765 format strings without any other text.
766
767
768 The following ber_printf() format characters are recognized:
769
770 b i n o s
771
772
773
774 If there are too few format specifiers, the format string may be
775 repeated as needed.
776
777
778 When used as an lval, there is a combination of pattern matching and
779 assignment, possibly to multiple fields or attributes.
780
781
782 In an assignment to an attribute, if the value of the addr field is
783 1.2.3.4, the rval:
784
785 ("ipNetworkNumber=%s,", addr)
786
787
788
789 produces the value ipNetworkNumber=1.2.3.4,, while:
790
791 ("(%s,%s,%s)", host, user, domain)
792
793
794
795 results in:
796
797 (assuming host="xyzzy", user="-", domain="x.y.z")
798 "(xyzzy,-,x.y.z)"
799
800
801
802 The elide character feature is used with attribute lists. So:
803
804 ("%s,", (mgrprfc822mailmember), ",")
805
806
807
808 concatenates all mgrprfc822mailmember values into one comma-separated
809 string, and then elides the final trailing comma. Thus, for
810
811 mgrprfc822mailmember=usera
812 mgrprfc822mailmember=userb
813 mgrprfc822mailmember=userc
814
815
816
817 the value would be:
818
819 usera,userb,userc
820
821
822
823 As a special case, to combine an LHS extraction with an RHS implicit
824 list creates multiple entries and values. So
825
826 ("(%s,%s,%s)", host, user, domain)=(nisNetgroupTriple)
827
828
829
830 creates one NIS entry for each nisNetgroupTriple value.
831
832
833 The 'removespec' form is used to exclude previously assigned fields
834 values from a list. So, if an LDAP entry contains:
835
836 name: foo
837 cn: foo
838 cn: foo1
839 cn: foo2
840
841
842
843 and the mapping file specifies :
844
845 myName = name, \
846 myAliases = ("%s ", (cn) - yp:myName, " ")
847
848
849
850 then the following assignments are carried out:
851
852 1. Assign value foo to myName
853
854 2. Assign value foo foo1 foo2 to myAliases
855
856 3. Remove value of myName from value myAliases
857
858
859 This results in the field values myName is set to foo, and myAliases is
860 set to foo1 foo2.
861
862 Assignments
863 The assignment syntax, also found at Field and Attribute Conversion
864 Syntax, is as follows:
865
866 fieldattrspec = lhs "=" rhs
867 lhs = lval | namespeclist
868 rhs = rval | namespec
869 namespeclist = namespec | "(" namespec *("," namespec) ")"
870
871
872
873 The general form of a simple assignment, which is a one-to-one mapping
874 of field to attribute, is:
875
876 ("%s", fieldname)=("%s", attrname)
877
878
879
880 As a convenient shorthand, this can also be written as:
881
882 fieldname=attrname
883
884
885
886 A list specification, which is a name enclosed in parenthesis, can be
887 used to make many-to-many assignments. The expression:
888
889 (fieldname)=(attrname)
890
891
892
893 where there are multiple instances of attrname, creates one NIS entry
894 for each such instance, differentiated by their fieldname values. The
895 following combinations of lists are allowed, but they are not
896 particularly useful:
897
898 (attrname)=(fieldname)
899 Equivalent to attrname=fieldname
900
901
902 attrname=(fieldname)
903 Equivalent to attrname=fieldname
904
905
906 (fieldname)=attrname
907 Equivalent to fieldname=attrname
908
909
910 fieldname=(attrname)
911 Equivalent to fieldname=attrname
912
913
914
915 If a multi-valued RHS is assigned to a single-valued LHS, the LHS value
916 will be the first of the RHS values. If the RHS is an attribute list,
917 the first attribute is the first one returned by the LDAP server when
918 queried. Otherwise, the definition of "first"is implementation
919 dependent.
920
921
922 Finally, the LHS can be an explicit list of fields or attributes, such
923 as:
924
925 (name1,name2,name3)
926
927
928
929 If the RHS is single-valued, this assigns the RHS value to all entities
930 in the list. If the RHS is multi-valued, the first value is assigned to
931 the first entity of the list, the second value to the second entity,
932 and so on. Excess values or entities are silently ignored.
933
934 EXAMPLES
935 Example 1 Assigning an Attribute Value to a Field
936
937
938 The following example illustrates how to assign the value of the
939 ipHostNumber attribute to the addr field
940
941
942 addr=ipHostNumber
943
944
945 Example 2 Creating Multiple NIS Entries from Multi-Valued LDAP
946 Attributes
947
948
949 An LDAP entry with:
950
951
952 cn=name1
953 cn=name2
954 cn=name3
955
956
957
958 and the following assignments:
959
960
961 cname=cn
962 (name)=(cn)
963
964
965
966 creates three NIS entries. Other attributes and fields are omitted for
967 clarity.
968
969
970 cname=name1, name=name1
971 cname=name1, name=name2
972 cname=name1, name=name3
973
974
975 Example 3 Assigning String Constants
976
977
978 The following expression sets the passwd field to x:
979
980
981 passwd=("x")
982
983
984 Example 4 Splitting Field Values to Multi-Valued Attributes
985
986
987 The expansion field contains a comma-separated list of alias member
988 names. In the following example, the expression assigns each member
989 name to an instance of mgrprfc822mailmember:
990
991
992 (mgrprfc822mailmember)=(expansion, ",")
993
994
995 FILES
996 /var/yp/NISLDAPmapping
997 Mapping file used by the NIS server
998 components
999
1000
1001 ATTRIBUTES
1002 See attributes(5) for descriptions of the following attributes:
1003
1004
1005
1006
1007 +---------------------+-----------------+
1008 | ATTRIBUTE TYPE | ATTRIBUTE VALUE |
1009 +---------------------+-----------------+
1010 |Interface Stability | Obsolete |
1011 +---------------------+-----------------+
1012
1013 SEE ALSO
1014 inityp2l(1M), makedbm(1M), ypserv(1M), ber_printf(3LDAP), sprintf(3C),
1015 sscanf(3C), ypserv(4), attributes(5)
1016
1017
1018 System Administration Guide: Naming and Directory Services (DNS, NIS,
1019 and LDAP)
1020
1021
1022
1023 February 25, 2017 NISLDAPMAPPING(4)