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 |
| Printed |
Page 106
First line |
The author puts most of the shared data somewhere into the /usr directory. According
to the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/) it should be
possible to mount this directory read-only. If there is another edition of the book
it might be therefore worth considering putting the data somewhere else, for example
into the /srv or /var directory.
(This is not just an issue of the specified page, the errata form won't let me submit
a whole-book issue.)
AUTHOR'S COMMENT:
This is a valid point; however, the text isn't actually wrong, and the examples
do work; it's just that they won't work *IF* the user has mounted /usr
read-only. As these are just examples, they're MEANT to be modified for
user-specific conditions. The FHS is a useful document, but not everybody (or
all distributions) adhere to it 100% faithfully. Placing writable data
in /usr won't break the system. Thus, it's not really an erratum (something
that's flat-out wrong with the book); it's more something that can (and
should) be changed for a second edition (not a second printing of this
edition). At least, IMHO.
|
Anonymous |
|
| Printed |
Page 124
First paragraph |
The author suggests that the user moves the freshly compiled library into /lib.
According to Filesystem Hierarchy Standard (and common sense, too) much better
location would be /usr/local/lib/.
(Follow this link to the relevant section of the Filesystem Hierarchy Standard:)
http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBESSENTIALSHAREDLIBRARIESANDKERN
AUTHOR'S COMMENT:
(Same as for [106])
|
Anonymous |
|
| Printed |
Page 130
First paragraph under the Using the cifs driver headline |
"As a practical matter, the main reason to use the cifs driver is if you want to
close off port 139 on the server (say, for security reasons)."
I fail to see the point here, what good is closing one port for, when I
simultaneously open another well-known port 445? Maybe there could be some
clarification.
AUTHOR'S COMMENT:
Admittedly, I was reaching; at the time I wrote the book, the CIFS driver was
buggier and therefore less practical than the SMBFS driver. Because of its
bugs, the only practical reason I could think of to use it was if you wanted
to close off the SMBFS port. It's CONCEIVABLE that some cracker script would
search on port 139 but not port 445, but I don't know that any such script
actually exists.
The CIFS driver has improved a lot since I wrote the book, so I'd write this
differently today.
Again, this is the sort of thing that's not really an errata (the text isn't
wrong, at least not in the context of when it was written), but it is a
legitimate issue to be addressed in a future edition, in this case simply
because the software has advanced since then.
|
Anonymous |
|