Errata

LDAP System Administration

Errata for LDAP System Administration

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.

Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted by Date submitted
PDF Page 6
First Footnote

The listed URL for "Understanding X.500 -- The Directory" by David W. Chadwick is no longer valid. The following URL can be used instead: http://sec.cs.kent.ac.uk/x500book/

 octoquad  Dec 12, 2011 
Printed Page 14
Figure 2-2's figure title

I think the figure title for figure 2-2 shouldn't describe the RDNs
pictured as multivalued. The description that precedes the figure
suggests that this is a restructuring of the DIT to avoid multivalued
RDNs.

 Anonymous   
PDF Page 23
Scheme References - First Reference

Since the book was released in 2003, most of the RFC's the author mentions are now obsolete and have been replaced by newer RFC's. For instance on this page RFC3377 has been replaced with RFC4510. RFC4510 also replaces the following RFC's: RFC2251, RFC2252, RFC2253, RFC2254, RFC2255, RFC2256, RFC2829, RFC2830, RFC3377, RFC3771 and should be updated in the book to reflect these changes and avoid confusion for the reader.

 octoquad  Dec 13, 2011 
PDF Page 23
Schema References - Last Reference

Since the merger of Sun and Oracle and major restructuring of their site, the documentation for SunOne Directory Server has moved to http://docs.oracle.com/cd/E19199-01/816-6696-10/contents.html

octoquad  Dec 13, 2011 
Printed Page 41
2nd full para; 3rd line

...bit flags that can be logically ORed together.
should probably be:
...bit flags that can be logically read together.

(Maybe "read" isn't the proper word, but "ORed" definitely isn't.)

 Anonymous   
Printed Page 48
3rd paragraph

The example "security update_sasl=128,update_tls=128" is incorrect.
It should read "security update_sasl=128 update_tls=128" (blank instead of comma).

cf slapd.conf man page :
"require <conditions>
Specify a set of conditions (separated by white space) to require (default
none).(...)"

 Anonymous   
Printed Page 54
1st code example

The comment in the code snippet states "## Maintain presence and equality searches on
the cn and uid attributes." yet the following line of code only only refers to cn and
not uid.

 Anonymous   
Printed Page 55
code example

The comment preceeding the 'rootdn' entry states "This is the Base64-encoded MD5 hash
of "secret"; this comment does not pertain to 'rootdn', it might pertain to the
following 'rootpw' entry.

 Anonymous   
Printed Page 57,121
first line and examples (57) vs. first ex. (121)

attrs vs. attr

page 57, use of attrs in ACL
page 121, use of attr in ACL

man and doc talk about "attrs"
but i tested with "attr" and it works (OpenLDAP 2.1.22)...

 Anonymous   
Printed Page 67-68
Last entry on page, top of next page

On RH 9, using openldap 2.1.22, creating the root directory exactly as instructed by
the book would produce the error: "slapadd: could not parse entry", for the OU
specification. When I removed the people ou, and just had the organisation in the
file, it accepted. I then started the database anew, save this time instead of making
the *company* an ou, as the book (and example files online) strangely tell you to do,
I made the company an o, and the division an ou. They were both thus accepted without
problems:

dn: dc=epixmed,dc=com
objectClass: dcObject
objectClass: organization
dc: epixmed
o: Epix Medical
description: Epix Medical

## Discovery Dept.
dn: ou=Discovery,dc=epixmed,dc=com
ou: Discovery
objectClass: organizationalUnit

|ldap:/usr/local/var/openldap/raw-db-data| root# slapadd -v -l epix-root.ldif
added: "dc=epixmed,dc=com" (00000001)
added: "ou=Discovery,dc=epixmed,dc=com" (00000002)

 Anonymous   
Printed Page 70
"list of attributes to return" paragraph

"To limit the result to a few specific attributes, list the attributes you want on
the command line, separated by commas."

should read:

"To limit the result to a few specific attributes, list the attributes you want on
the command line, separated by blanks."

 Anonymous   
Printed Page 90
$ldapadd...

>ou:people must be >ou:hosts

 Anonymous   
Printed Page 92
about -C option

The option -C is not seen in the example, not in manpage either...

 Anonymous   
Printed Page 92
Second ldapsearch example

The prose before the second example details the use of the -C (chase referrals) parameter but the command in the second `ldapsearch` example doesn't actually include the -C option. However, the output does appear to be correct as if the -C was used.

Fix: add the "-C" to the 2nd example invocation of ldapsearch

 Tim Chase  Feb 29, 2024 
Printed Page 94
$ldapsearch ...

> -w n0pass must be > -w secret

 Anonymous   
Printed Page 98
$ldapmodify ...

> -f testuser.ldif must be > -f /tmp/test.ldif (cf. pg 97)

 Anonymous   
Printed Page 105
fig. 6-3

Optional are not correct

From nis.schema (OpenLDAP 2.1.22)
must: cn,uid,uidNumber,gidNumber,homedirectory
may: userPassword,loginShell,gecos,description

 Anonymous   
Printed Page 143
below 1st paragraph, 2nd directory entry block

I feel, the second directory entry has a mistake on the page 143.
(the section on sendmail aliases integration with LDAP)

the second directory entry look like this:

dn: sendmailMTAKey=postmaster,ou=aliases,ou=sendmail,
ou=services,dc=plainjoe,dc=org
objectClass: sendmailMTAAliasObject
sendmailMTAAliasValue: /dev/null
sendmailMTAKey: nobody

I feel it should be like this:

dn: sendmailMTAKey=nobody,ou=aliases,ou=sendmail,
ou=services,dc=plainjoe,dc=org
objectClass: sendmailMTAAliasObject
sendmailMTAAliasValue: /dev/null
sendmailMTAKey: nobody

difference is nobody will replace postmaster on the first line of the entry.

 Anonymous   
Printed Page 144
1st example in section "Mail routing using LDAP"

"The following virtual user table entry would route messages that are addressed to
joe@foo.com to the host somehost.foo.com:

joe@foo.com somehost.foo.com"

The above is incorrect. Without LDAP, Sendmail (v8.13.1) cannot achieve the above.
The default "virtualuser table" cannot forward an address to another host without re-
writing the address, e.g:

joe@foo.com joe@somehost.foo.com

 Anonymous   
Printed Page 147
3rd paragraph example code

The example code
$ /usr/sbin/sendmail -bt > /parse kcarter@plainjoe.org
should be
$ echo '/parse kcarter@plainjoe.org' | /usr/sbin/sendmail -bt

 Anonymous   
Printed Page 167
2nd paragraph

ldap filter = "(&(uid=%U)(objectclass=sambaAccont))"

quite simply doesn't work. It's noted that it is the default, but you never get any
entries returned by that command, as its sent as (uid=)(objectclass=sambaAccont),
which doesn't return anything. If it is not included in the configuration file, the
_Real_ default is used, which works.

 Anonymous   
Printed Page 196
3rd paragraph (just below figurer 9-1)

The text refers to selecting "Properties" on the "Users" icon in paragraph 2.
Paragraph 3 then begins a process of selecting a "Security Tab". However, there is no
such tab for the "Users" folder in Active Directory under Windows 2003 (the version
that I have). Windows 2000 is out of date and no errata/corrections/updates are found
on this web site as to how to proceed with interoperability using Active Directory
under Windows 2003.

 Anonymous