Another copy edit update.

(This used to be commit 7d998a020d8de890bdefc6b9312d26001f3ab7eb)

1 files changed, 152 insertions, 148 deletions

diff --git a/docs/Samba-Guide/SBE-UpgradingSamba.xml b/docs/Samba-Guide/SBE-UpgradingSamba.xml
index 6ce1df51b7..04a6d3bc9b 100644
--- a/docs/Samba-Guide/SBE-UpgradingSamba.xml
+++ b/docs/Samba-Guide/SBE-UpgradingSamba.xml
@@ -37,8 +37,8 @@ context in either book, I could not find it.
 <para>
 <indexterm><primary>contributions</primary></indexterm>
 So in response to the significant request for these situations to be better 
-documented this chapter has now been added. User contributions and documentation
-of real-world experiences will be a most welcome addition to this chapter.
+documented, this chapter has now been added. User contributions and documentation
+of real-world experiences are a most welcome addition to this chapter.
 </para>
 
 <sect1>
@@ -49,20 +49,20 @@ of real-world experiences will be a most welcome addition to this chapter.
 <indexterm><primary>upgrade</primary></indexterm>
 <indexterm><primary>frustration</primary></indexterm>
 A Windows network administrator explained in an email what changes he was
-planning to make and and followed with the question: <quote>Anyone done this before?</quote>.
-Many of us have upgraded and updated Samba without incident. Others have
-experienced much pain and user frustration. So it is to be hoped that the
-notes in this chapter will make a positive difference by assuring that
-someone will be saved a lot of discomfort.
+planning to make and followed with the question: <quote>Anyone done this
+before?</quote> Many of us have upgraded and updated Samba without incident.
+Others have experienced much pain and user frustration. So it is to be hoped
+that the notes in this chapter will make a positive difference by assuring
+that someone will be saved a lot of discomfort.
 </para>
 
 <para>
-Before anyone commences an upgrade or an update of Samba the one cardinal
+Before anyone commences an upgrade or an update of Samba, the one cardinal
 rule that must be observed is: Backup all Samba configuration files in
 case it is necessary to revert to the old version. Even if you do not like
 this precautionary step, users will punish an administrator who
 fails to take adequate steps to avoid situations that may inflict lost
-productivity on a user.
+productivity on them.
 </para>
 
 <warning><para>
@@ -81,8 +81,8 @@ in the rare event that this may be necessary.
 It is prudent also to backup all data files on the server before attempting
 to perform a major upgrade. Many administrators have experienced the consequences
 of failure to take adequate precautions. So what is adequate? That is simple!
-If data is lost during an upgrade or and update and it can not be restored
-the precautions take were inadequate. If a backup was not needed, but was available,
+If data is lost during an upgrade or update and it can not be restored,
+the precautions taken were inadequate. If a backup was not needed, but was available,
 precaution was on the side of the victor.
 </para>
 
@@ -99,16 +99,16 @@ precaution was on the side of the victor.
 	<indexterm><primary>upgrade</primary></indexterm>
 	<indexterm><primary>generation</primary></indexterm>
 	This is as good a time as any to define the terms <constant>upgrade</constant> and
-	<constant>update</constant>. The term <constant>upgrade</constant> is used to refer to
+	<constant>update</constant>. The term <constant>upgrade</constant> refers to
 	the installation of a version of Samba that is a whole generation or more ahead of
 	that which is installed. Generations are indicated by the first digit of the version
-	number. So far Samba has been released in generations 1.x, 2.x, 3.x and currently 4.0
+	number. So far Samba has been released in generations 1.x, 2.x, 3.x, and currently 4.0
 	is in development.
 	</para>
 
 	<para>
 	<indexterm><primary>generation</primary></indexterm>
-	The term <constant>update</constant> is used to refer to a minor version number installation
+	The term <constant>update</constant> refers to a minor version number installation
 	in place of one of the same generation. For example, updating from Samba 3.0.10 to 3.0.14
 	is an update. The move from Samba 2.0.7 to 3.0.14 is an upgrade.
 	</para>
@@ -118,15 +118,15 @@ precaution was on the side of the victor.
 	While the use of these terms is an exercise in semantics, what needs to be realized
 	is that there are major functional differences between a Samba 2.x release and a Samba
 	3.0.x release. Such differences may require a significantly different approach to
-	solving the same networking challenge and generally requires careful review of the
+	solving the same networking challenge and generally require careful review of the
 	latest documentation to identify precisely how the new installation may need to be
 	modified to preserve prior functionality.
 	</para>
 
 	<para>
-	There is an old axiom that says, <quote>The greater the volume of the documentation
-	the greater the risk that no-one will read it, but where there is no documentation
-	no-one can read it!</quote>. While true, some documentation is an evil necessity.
+	There is an old axiom that says, <quote>The greater the volume of the documentation,
+	the greater the risk that noone will read it, but where there is no documentation,
+	noone can read it!</quote> While true, some documentation is an evil necessity.
 	It is to be hoped that this update to the documentation will avoid both extremes.
 	</para>
 
@@ -140,7 +140,7 @@ precaution was on the side of the victor.
 	<indexterm><primary>SID</primary></indexterm>
 	<indexterm><primary>networking</primary><secondary>client</secondary></indexterm>
 	<indexterm><primary>security</primary><secondary>identifier</secondary></indexterm>
-	Before the days of Windows NT and OS/2 every Windows and DOS networking client
+	Before the days of Windows NT and OS/2, every Windows and DOS networking client
 	that used the SMB protocols was an entirely autonomous entity. There was no concept
 	of a security identifier for a machine or a user outside of the username, the
 	machine name, and the workgroup name. In actual fact, these were not security identifiers
@@ -155,7 +155,7 @@ precaution was on the side of the victor.
 	<indexterm><primary>SID</primary></indexterm>
 	<indexterm><primary>username</primary></indexterm>
 	<indexterm><primary>Windows</primary><secondary>client</secondary></indexterm>
-	Versions of Samba prior to 1.9 did not make use of a SID, instead they make exclusive use
+	Versions of Samba prior to 1.9 did not make use of a SID. Instead they make exclusive use
 	of the username that is embedded in the SessionSetUpAndX component of the connection
 	setup process between a Windows client and an SMB/CIFS server. 
 	</para>
@@ -165,7 +165,7 @@ precaution was on the side of the victor.
 	<indexterm><primary>rpc</primary></indexterm>
 	<indexterm><primary>security</primary></indexterm>
 	Around November 1997 support was added to Samba-1.9 to handle the Windows security
-	rpc based protocols that implemented support for Samba to store a machine SID. This
+	RPC-based protocols that implemented support for Samba to store a machine SID. This
 	information was stored in a file called <filename>MACHINE.SID.</filename>
 	</para>
 
@@ -173,9 +173,9 @@ precaution was on the side of the victor.
 	<indexterm><primary>machine</primary></indexterm>
 	<indexterm><primary>SID</primary></indexterm>
 	<indexterm><primary>secrets.tdb</primary></indexterm>
-	Within the life time of the early Samba 2.x series the machine SID information was
-	relocated into a tdb file called <filename>secrets.tdb</filename>, which is where is
-	is still located in Samba 3.0.x along with other information that pertains to the
+	Within the lifetime of the early Samba 2.x series, the machine SID information was
+	relocated into a tdb file called <filename>secrets.tdb</filename>, which is where
+	it is still located in Samba 3.0.x along with other information that pertains to the
 	local machine and its role within a domain security context.
 	</para>
 
@@ -186,7 +186,7 @@ precaution was on the side of the victor.
 	<indexterm><primary>SAS</primary></indexterm>
 	There are two types of SID, those pertaining to the machine itself and the domain to
 	which it may belong, and those pertaining to users and groups within the security
-	context of the local machine (in the case of stand-alone servers (SAS) and domain member
+	context of the local machine, in the case of standalone servers (SAS) and domain member
 	servers (DMS).
 	</para>
 
@@ -198,24 +198,24 @@ precaution was on the side of the victor.
 	<indexterm><primary>SID</primary></indexterm>
 	<indexterm><primary>secrets.tdb</primary></indexterm>
 	When the Samba <command>smbd</command> daemon is first started, if the <filename>secrets.tdb</filename>
-	file does not exist it is created at the first client connection attempt. If this file does
-	exist, <command>smbd</command> checks that there is a machine SID (if it is a domain controller
+	file does not exist, it is created at the first client connection attempt. If this file does
+	exist, <command>smbd</command> checks that there is a machine SID (if it is a domain controller,
 	it searches for the domain SID). If <command>smbd</command> does not find one for the current
-	name of the machine or for the current name of the workgroup a new SID will be generated and
-	then written to the <filename>secrets.tdb</filename> file. The SID is generated in a non-determinative
+	name of the machine or for the current name of the workgroup, a new SID will be generated and
+	then written to the <filename>secrets.tdb</filename> file. The SID is generated in a nondeterminative
 	manner. This means that each time it is generated for a particular combination of machine name
-	(hostname) and domain name (workgroup) it will be different.
+	(hostname) and domain name (workgroup), it will be different.
 	</para>
 
 	<para>
 	<indexterm><primary>ACL</primary></indexterm>
 	The SID is the key used by MS Windows networking for all networking operations. This means
-	that when the machine or domain SID changes all security encoded objects such as profiles
+	that when the machine or domain SID changes, all security-encoded objects such as profiles
 	and ACLs may become unusable.
 	</para>
 
 	<note><para>
-	It is of paramount importance that the machine and domain SID must be backed up so that in
+	It is of paramount importance that the machine and domain SID be backed up so that in
 	the event of a change of hostname (machine name) or domain name (workgroup) the SID can
 	be restored to its previous value.
 	</para></note>
@@ -232,8 +232,8 @@ precaution was on the side of the victor.
 	<indexterm><primary>SAS</primary></indexterm>
 	<indexterm><primary>SID</primary></indexterm>
 	In Samba-3 on a domain controller (PDC or BDC), the domain name controls the domain
-	SID. On all prior versions the hostname (computer name, or netbios name) controlled
-	the SID. On a stand-alone server (SAS) the hostname still controls the SID.
+	SID. On all prior versions the hostname (computer name, or NetBIOS name) controlled
+	the SID. On a standalone server the hostname still controls the SID.
 	</para>
 
 	<para>
@@ -255,13 +255,13 @@ SID for domain FRODO is: S-1-5-21-726309263-4128913605-1168186429
 
 	<para>
 	Samba 1.9.x stored the machine SID in the the file <filename>/etc/MACHINE.SID</filename>
-	from which it can be recovered and stored into the <filename>secrets.tdb</filename> file
+	from which it could be recovered and stored into the <filename>secrets.tdb</filename> file
 	using the procedure shown above.
 	</para>
 
 	<para>
 	Where the <filename>secrets.tdb</filename> file exists and a version of Samba 2.x or later
-	has been used there is no specific need to go through this update process. Samba-3 has the
+	has been used, there is no specific need to go through this update process. Samba-3 has the
 	ability to read the older tdb file and to perform an in-situ update to the latest tdb format.
 	This is not a reversible process &smbmdash; it is a one-way upgrade.
 	</para>
@@ -280,7 +280,7 @@ SID for domain FRODO is: S-1-5-21-726309263-4128913605-1168186429
 <screen>
 &rootprompt; smbpasswd -S PDC -Uadministrator%password
 </screen>
-	From which the SID could be copied to a file and then it could be written to the Samba 2.2.x
+	from which the SID could be copied to a file and then written to the Samba-2.2.x
 	<filename>secrets.tdb</filename> file by executing:
 <screen>
 &rootprompt; smbpasswd -W S-1-5-21-726309263-4128913605-1168186429
@@ -290,7 +290,7 @@ SID for domain FRODO is: S-1-5-21-726309263-4128913605-1168186429
 	<para>
 	<indexterm><primary>rpcclient</primary></indexterm>
 	<indexterm><primary>net</primary><secondary>rpc</secondary><tertiary>info</tertiary></indexterm>
-	Domain security information, that includes the domain SID, can be obtained from Samba-2.2.x
+	Domain security information, which includes the domain SID, can be obtained from Samba-2.2.x
 	systems by executing:
 <screen>
 &rootprompt; rpcclient lsaquery -Uroot%password
@@ -315,9 +315,9 @@ Num local groups: 0
 	<indexterm><primary>SID</primary></indexterm>
 	Take note that the domain SID is used extensively in Samba. Where LDAP is used for the
 	<parameter>passdb backend</parameter>, all user, group, and trust accounts are encoded
-	with the domain SID. This means that if the domain SID changes for any reason the entire
-	Samba environment can become broken thus requiring extensive corrective action is the 
-	original SID can not be restored. Fortunately, it can be recovered from a dump of the
+	with the domain SID. This means that if the domain SID changes for any reason, the entire
+	Samba environment can become broken and require extensive corrective action if the 
+	original SID cannot be restored. Fortunately, it can be recovered from a dump of the
 	LDAP database. A dump of the LDAP directory database can be obtained by executing:
 <screen>
 &rootprompt; slapcat -v -l filename.ldif
@@ -328,14 +328,14 @@ Num local groups: 0
 	<indexterm><primary>SID</primary></indexterm>
 	<indexterm><primary>profiles</primary></indexterm>
 	<indexterm><primary>RPM</primary></indexterm>
-	When the domain SID has changed roaming profiles will cease to be functional. The recovery
-	of roaming profiles will necessitate resetting of the domain portion of the user SID
+	When the domain SID has changed, roaming profiles cease to be functional. The recovery
+	of roaming profiles necessitates resetting of the domain portion of the user SID
 	that owns the profile. This is encoded in the <filename>NTUser.DAT</filename> and can be
 	updated using the Samba <command>profiles</command> utility. Please be aware that not all
-	Linux distributions of the Samba RPMs do include this essential utility. Please do not
-	complain to the Samba Team if this utility is missing, that is an issue that must be
+	Linux distributions of the Samba RPMs include this essential utility. Please do not
+	complain to the Samba Team if this utility is missing; that issue that must be
 	addressed to the creator of the RPM package. The Samba Team do their best to make
-	available all the tools needed to manage a Samba based Windows networking environment.
+	available all the tools needed to manage a Samba-based Windows networking environment.
 	</para>
 
 	</sect3>
@@ -346,40 +346,40 @@ Num local groups: 0
 	<para>
 	<indexterm><primary>netbios</primary><secondary>machine  name</secondary></indexterm>
 	<indexterm><primary>netbios name</primary></indexterm>
-	Samba uses two (2) methods by which the primary NetBIOS machine name (also known as a computer
-	name or the hostname) may be determined: If the &smb.conf; file contains an entry
-	<parameter>netbios name</parameter> entry its value will be used directly. In the absence
-	of such and entry the UNIX system hostname will be used.
+	Samba uses two methods by which the primary NetBIOS machine name (also known as a computer
+	name or the hostname) may be determined: If the &smb.conf; file contains a
+	<parameter>netbios name</parameter> entry, its value will be used directly. In the absence
+	of such an entry, the UNIX system hostname will be used.
 	</para>
 
 	<para>
 	Many sites have become victims of lost Samba functionality because the UNIX system
 	hostname was changed for one reason or another. Such a change will cause a new machine
-	SID to be generated. If this happens on a domain controller it will also change the
-	domain SID. These SIDs can be updated (restored) using the procedure outlined above.
+	SID to be generated. If this happens on a domain controller, it will also change the
+	domain SID. These SIDs can be updated (restored) using the procedure outlined previously.
 	</para>
 
 	<note><para>
 	Do NOT change the hostname or the <parameter>netbios name</parameter>. If this
-	is changed be sure to reset the machine SID to the original setting, otherwise
+	is changed, be sure to reset the machine SID to the original setting. Otherwise
 	there may be serious interoperability and/or operational problems.
 	</para></note>
 
 	</sect3>
 
 	<sect3>
-	<title>Change of workgroup (domain) name</title>
+	<title>Change of Workgroup (Domain) Name</title>
 
 	<para>
 	<indexterm><primary>workgroup</primary></indexterm>
-	The domain name of a Samba server is identical with the workgroup name and is
+	The domain name of a Samba server is identical to the workgroup name and is
 	set in the &smb.conf; file using the <parameter>workgroup</parameter> parameter.
 	This has been consistent throughout the history of Samba and across all versions.
 	</para>
 
 	<para>
 	<indexterm><primary>SID</primary></indexterm>
-	Be aware that when the workgroup name is changed a new SID will be generated.
+	Be aware that when the workgroup name is changed, a new SID will be generated.
 	The old domain SID can be reset using the procedure outlined earlier in this chapter.
 	</para>
 
@@ -402,7 +402,7 @@ Num local groups: 0
 	</para>
 
 	<para>
-	During the life of the Samba 2.x release the &smb.conf; file was relocated
+	During the life of the Samba 2.x release, the &smb.conf; file was relocated
 	on Linux systems to the <filename>/etc/samba</filename> directory where it
 	remains located also for Samba 3.0.x installations.
 	</para>
@@ -411,14 +411,14 @@ Num local groups: 0
 	<indexterm><primary>secrets.tdb</primary></indexterm>
 	Samba 2.x introduced the <filename>secrets.tdb</filename> file that is also stored in the
 	<filename>/etc/samba</filename> directory, or in the <filename>/usr/local/samba/lib</filename>
-	directory sub-system.
+	directory subsystem.
 	</para>
 
 	<para>
 	<indexterm><primary>smbd</primary></indexterm>
 	The location at which <command>smbd</command> expects to find all configuration and control
 	files is determined at the time of compilation of Samba. For versions of Samba prior to
-	3.0 one way to find the expected location of these files is to execute:
+	3.0, one way to find the expected location of these files is to execute:
 <screen>
 &rootprompt; strings /usr/sbin/smbd | grep conf
 &rootprompt; strings /usr/sbin/smbd | grep secret
@@ -463,10 +463,11 @@ Paths:
 
 	<para>
 	<indexterm><primary></primary></indexterm>
-	It is important that both the &smb.conf; file and the <filename>secrets.tdb</filename> should
-	be backed up before attempting any upgrade. The <filename>secrets.tdb</filename> file is version
-	encoded and therefore a newer version may not work with an older version of Samba. A backup
-	means that it is always possible to revert a failed or problematic upgrade.
+	It is important that both the &smb.conf; file and the <filename>secrets.tdb</filename>
+	be backed up before attempting any upgrade. The <filename>secrets.tdb</filename> file
+	is version-encoded, and therefore a newer version may not work with an older version
+	of Samba. A backup means that it is always possible to revert a failed or problematic
+	upgrade.
 	</para>
 
 	</sect3>
@@ -479,7 +480,7 @@ Paths:
 	<indexterm><primary>character set</primary></indexterm>
 	<indexterm><primary>codepage</primary></indexterm>
 	<indexterm><primary>internationalization</primary></indexterm>
-	Samba-2.x had not support for Unicode, instead all national language character set support in file names
+	Samba-2.x had no support for Unicode; instead, all national language character-set support in file names
 	was done using particular locale codepage mapping techniques. Samba-3 supports Unicode in file names, thus
 	providing true internationalization support.
 	</para>
@@ -495,7 +496,7 @@ Paths:
 	<para>
 	<indexterm><primary>UTF-8</primary></indexterm>
 	Files that are created with Samba-3 will use UTF-8 encoding. Should the file system ever end up with a
-	mix of codepage (unix charset) encoded file names and UTF-8 encoded file names, the mess will take some
+	mix of codepage (unix charset)-encoded file names and UTF-8-encoded file names, the mess will take some
 	effort to set straight.
 	</para>
 
@@ -503,7 +504,7 @@ Paths:
 	<indexterm><primary>convmv</primary></indexterm>
 	A very helpful tool is available from Bjorn Jacke's <ulink url="http://j3e.de/linux/convmv/">convmv</ulink>
 	work. Convmv is a tool that can be used to convert file and directory names from one encoding method to
-	another. The most common use for this tool is to convert locale encoded files to UTF-8 Unicode encoding.
+	another. The most common use for this tool is to convert locale-encoded files to UTF-8 Unicode encoding.
 	</para>
 
 	</sect3>
@@ -519,7 +520,7 @@ Paths:
 Sites that are being upgraded from Samba-2 (or earlier versions) to Samba-3
 may experience little difficulty or may require a lot of effort, depending
 on the complexity of the configuration. Samba-1.9.x upgrades to Samba-3 will
-generally be simple and straight forward, although no upgrade should be
+generally be simple and straightforward, although no upgrade should be
 attempted without proper planning and preparation.
 </para>
 
@@ -533,7 +534,7 @@ Samba-2.x could be compiled with LDAP support.
 	<title>Samba 1.9.x and 2.x Versions Without LDAP</title>
 
 	<para>
-	Where it is necessary to upgrade an old Samba installation to Samba-3
+	Where it is necessary to upgrade an old Samba installation to Samba-3,
 	the following procedure can be followed:
 	</para>
 
@@ -546,22 +547,22 @@ Samba-2.x could be compiled with LDAP support.
 		<indexterm><primary>nmbd</primary></indexterm>
 		Stop Samba. This can be done using the appropriate system tool
 		that is particular for each operating system or by executing the
-		<command>kill</command> command on <command>smbd, nmbd</command>
-		and on <command>winbindd</command>.
+		<command>kill</command> command on <command>smbd</command>,
+		<command>nmbd</command>, and <command>winbindd</command>.
 		</para></step>
 
 		<step><para>
-		Find the location of the Samba &smb.conf; file - back it up to a
+		Find the location of the Samba &smb.conf; file and back it up to a
 		safe location.
 		</para></step>
 
 		<step><para>
-		Find the location of the <filename>smbpasswd</filename> file -
+		Find the location of the <filename>smbpasswd</filename> file and
 		back it up to a safe location.
 		</para></step>
 
 		<step><para>
-		Find the location of the <filename>secrets.tdb</filename> file -
+		Find the location of the <filename>secrets.tdb</filename> file and
 		back it up to a safe location.
 		</para></step>
 
@@ -575,7 +576,7 @@ Samba-2.x could be compiled with LDAP support.
 		location used by the Samba Team is in
 		<filename>/usr/local/samba/var/locks</filename> directory,
 		but on Linux systems the old location was under the
-		<filename>/var/cache/samba</filename> directory, however the
+		<filename>/var/cache/samba</filename> directory. However, the
 		Linux Standards Base specified location is now under the
 		<filename>/var/lib/samba</filename> directory. Copy all the
 		tdb files to a safe location.
@@ -590,13 +591,13 @@ Samba-2.x could be compiled with LDAP support.
 
 		<para>
 		On systems that do not support a reliable package management system
-		it is advisable either to delete the Samba old installation , or to
+		it is advisable either to delete the Samba old installation or to
 		move it out of the way by renaming the directories that contain the
 		Samba binary files.
 		</para></step>
 
 		<step><para>
-		When the Samba upgrade has been installed the first step that should
+		When the Samba upgrade has been installed, the first step that should
 		be completed is to identify the new target locations for the control
 		files. Follow the steps shown in <link linkend="sbeug1"/> to locate
 		the correct directories to which each control file must be moved.
@@ -627,15 +628,15 @@ Samba-2.x could be compiled with LDAP support.
 </screen>
 	<indexterm><primary>stripped</primary></indexterm>
 		The resulting &smb.conf; file will be stripped of all comments
-		and will be stripped of all non-conforming configuration settings.
+		and of all nonconforming configuration settings.
 		</para></step>
 
 		<step><para>
 		<indexterm><primary>winbindd</primary></indexterm>
 		It is now safe to start Samba using the appropriate system tool.
-		Alternately, it is possible to just execute <command>nmbd, smbd</command>
-		and <command>winbindd</command> for the command line while logged in
-		as the 'root' user.
+		Alternately, it is possible to just execute <command>nmbd</command>,
+		<command>smbd</command>, and <command>winbindd</command> for the command
+		line while logged in as the root user.
 		</para></step>
 
 	</procedure>
@@ -643,7 +644,7 @@ Samba-2.x could be compiled with LDAP support.
 	</sect2>
 
 	<sect2>
-	<title>Applicable to all Samba 2.x to Samba-3 Upgrades</title>
+	<title>Applicable to All Samba 2.x to Samba-3 Upgrades</title>
 
 	<para>
 	<indexterm><primary>PDC</primary></indexterm>
@@ -651,15 +652,15 @@ Samba-2.x could be compiled with LDAP support.
 	<indexterm><primary>inter-domain</primary></indexterm>
 	Samba 2.x servers that were running as a domain controller (PDC)
 	require changes to the configuration of the scripting interface
-	tools that Samba uses to perform operating system updates for
-	users, groups and trust accounts (machines and inter-domain).
+	tools that Samba uses to perform OS updates for
+	users, groups, and trust accounts (machines and interdomain).
 	</para>
 
 	<para>
 	<indexterm><primary>parameters</primary></indexterm>
-	The following parameters are new to Samba-3 and should be correctly
-	configured. Please refer to Chapters 3-6 in this book for examples
-	of use of the new parameters shown here:
+	The following parameters are new to Samba-3 and should be correctly configured.
+	Please refer to <link linkend="secure"/> through <link linkend="2000users"/>
+	in this book for examples of use of the new parameters shown here:
 	<indexterm><primary>add group script</primary></indexterm>
 	<indexterm><primary>add machine script</primary></indexterm>
 	<indexterm><primary>add user to group script</primary></indexterm>
@@ -700,31 +701,32 @@ Samba-2.x could be compiled with LDAP support.
 	<indexterm><primary>groupmod</primary></indexterm>
 	<indexterm><primary>groupdel</primary></indexterm>
 	Where the <parameter>passdb backend</parameter> used is either <constant>smbpasswd</constant>
-	(the default), or the new <constant>tdbsam</constant>, the system interface scripts
-	are typically used. These involve use of operating system tools such as
-	<command>useradd, usermod, userdel, groupadd, groupmod, groupdel</command>, etc.
+	(the default) or the new <constant>tdbsam</constant>, the system interface scripts
+	are typically used. These involve use of OS tools such as <command>useradd</command>,
+	<command>usermod</command>, <command>userdel</command>, <command>groupadd</command>,
+	<command>groupmod</command>, <command>groupdel</command>, and so on.
 	</para>
 
 	<para>
 	<indexterm><primary>passdb backend</primary></indexterm>
 	<indexterm><primary>LDAP</primary></indexterm>
 	<indexterm><primary>Idealx</primary></indexterm>
-	Where the <parameter>passdb backend</parameter> makes use of an LDAP directory
-	it will be necessary either to use the <constant>smbldap-tools</constant> provided
-	by Idealx, or else to use an alternate tool-set either provided by another third
-	party, or else home crafted tools to manage the LDAP directory accounts.
+	Where the <parameter>passdb backend</parameter> makes use of an LDAP directory,
+	it is necessary either to use the <constant>smbldap-tools</constant> provided
+	by Idealx or to use an alternate toolset provided by a third
+	party or else home-crafted to manage the LDAP directory accounts.
 	</para>
 
 	</sect2>
 
 	<sect2>
-	<title>Samba-2.x with LDAP support</title>
+	<title>Samba-2.x with LDAP Support</title>
 
 	<para>
-	Samba version 2.x could be compiled for use either with, or without, LDAP.
+	Samba version 2.x could be compiled for use either with or without LDAP.
 	The LDAP control settings in the &smb.conf; file in this old version are
 	completely different (and less complete) than they are with Samba-3. This
-	means that after migrating the control files it will be necessary to reconfigure
+	means that after migrating the control files, it is necessary to reconfigure
 	the LDAP settings entirely.
 	</para>
 
@@ -737,7 +739,7 @@ Samba-2.x could be compiled with LDAP support.
 	<indexterm><primary>schema</primary></indexterm>
 	<indexterm><primary>WHATSNEW.txt</primary></indexterm>
 	The Samba SAM schema required for Samba-3 is significantly different from that
-	used with Samba 2.x. This means that the LDAP directory will need to be updated
+	used with Samba 2.x. This means that the LDAP directory must be updated
 	using the procedure outlined in the Samba WHATSNEW.txt file that accompanies
 	all releases of Samba-3. This information is repeated here directly from this
 	file:
@@ -901,7 +903,7 @@ the DN's with quotation marks.
 
 <para>
 The key concern in this section is to deal with the changes that have been
-affected in Samba-3 between the samba-3.0.0 release and the current update.
+affected in Samba-3 between the Samba-3.0.0 release and the current update.
 Network administrators have expressed concerns over the steps that should be
 taken to update Samba-3 versions.
 </para>
@@ -911,19 +913,19 @@ taken to update Samba-3 versions.
 The information in <link linkend="sbeug1"/> would not be necessary if every
 person who has ever produced Samba executable (binary) files could agree on
 the preferred location of the &smb.conf; file and other Samba control files.
-Clearly, such agreement is further away than a pipe-dream.
+Clearly, such agreement is further away than a pipedream.
 </para>
 
 <para>
 <indexterm><primary>vendors</primary></indexterm>
-Vendors and packagers who produce Samba binary install-able packages do not,
+Vendors and packagers who produce Samba binary installable packages do not,
 as a rule, use the default paths used by the Samba-Team for the location of
 the binary files, the &smb.conf; file, and the Samba control files (tdb's
-as well as files such as <filename>secrets.tdb</filename>. This means that
+as well as files such as <filename>secrets.tdb</filename>). This means that
 the network or UNIX administrator who sets out to build the Samba executable
 files from the Samba tarball must take particular care. Failure to take care
-will result in both the original vendors' version of Samba remaining installed
-as well as the new version that will be installed in the default location used
+will result in both the original vendor's version of Samba remaining installed
+and the new version being installed in the default location used
 by the Samba-Team. This can lead to confusion and to much lost time as the
 uninformed administrator deals with apparent failure of the update to take
 effect.
@@ -934,21 +936,21 @@ effect.
 The best advice for those lacking in code compilation experience is to use
 only vendor (or Samba-Team) provided binary packages. The Samba packages
 that are provided by the Samba-Team are generally built to use file paths
-that are compatible with the original operating system vendors' practices.
+that are compatible with the original OS vendor's practices.
 </para>
 
 <para>
 <indexterm><primary>binary package</primary></indexterm>
 <indexterm><primary>binary files</primary></indexterm>
-If you are not sure whether or a binary package complies with the operating
-system vendors' practices it is better to ask the package maintainer via
-email to be certain than to waste much time dealing with the nuances.
+If you are not sure whether or a binary package complies with the OS
+vendor's practices, it is better to ask the package maintainer via
+email than to waste much time dealing with the nuances.
 Alternately, just diagnose the paths specified by the binary files following
 the procedure outlined above.
 </para>
 
 	<sect2>
-	<title>Samba-3 to Samba-3 updates on the Same Server</title>
+	<title>Samba-3 to Samba-3 Updates on the Same Server</title>
 
 	<para>
 	The guidance in this section deals with updates to an existing
@@ -975,7 +977,7 @@ the procedure outlined above.
 	<para>
 	<indexterm><primary>schema</primary></indexterm>
 	<indexterm><primary>LDAP</primary><secondary>schema</secondary></indexterm>
-	When updating versions of Samba-3 prior to 3.0.6 to 3.0.6-3.0.10
+	When updating versions of Samba-3 prior to 3.0.6 to 3.0.6 through 3.0.10,
 	it is necessary only to update the LDAP schema (where LDAP is used).
 	Always use the LDAP schema file that is shipped with the latest Samba-3
 	update.
@@ -985,7 +987,7 @@ the procedure outlined above.
 	<indexterm><primary>ldapsam</primary></indexterm>
 	<indexterm><primary>tdbsam</primary></indexterm>
 	<indexterm><primary>passdb backend</primary></indexterm>
-	Samba-3.0.6 introduced the ability to remember the last 'n' number
+	Samba-3.0.6 introduced the ability to remember the last <emphasis>n</emphasis> number
 	of passwords a user has used. This information will work only with
 	the <constant>tdbsam</constant> and <constant>ldapsam</constant>
 	<parameter>passdb backend</parameter> facilities.
@@ -1018,9 +1020,10 @@ the procedure outlined above.
 	</para>
 
 	<para>
-	In Samba-3.0.11 there were some functional changes to the <parameter>ldap user suffix</parameter>
-	and to the <parameter>ldap machine suffix</parameter> behaviors. The following
-	information has been extracted from the WHATSNEW.txt file from this release:
+	In Samba-3.0.11 there were some functional changes to the <parameter>ldap user
+	suffix</parameter> and to the <parameter>ldap machine suffix</parameter> behaviors.
+	The following information has been extracted from the WHATSNEW.txt file from this
+	release:
 <screen>
 ============
 LDAP Changes
@@ -1051,15 +1054,15 @@ back to searching the 'ldap suffix' in some cases.
 
 	<para>
 	<indexterm><primary>DMS</primary></indexterm>
-	Replacement of a domain member server (DMS) should be done
+	Replacement of a domain member server should be done
 	using the same procedure as outlined in <link linkend="unixclients"/>.
 	</para>
 
 	<para>
 	Usually the new server will be introduced with a temporary name. After
-	the old server data has been migrated to the new server it is customary
-	that the new server will be renamed to that of the old server. This will
-	change its SID and will necessitate re-joining to the domain.
+	the old server data has been migrated to the new server, it is customary
+	that the new server be renamed to that of the old server. This will
+	change its SID and will necessitate rejoining to the domain.
 	</para>
 
 	<para>
@@ -1069,14 +1072,14 @@ back to searching the 'ldap suffix' in some cases.
 	<indexterm><primary>wins.dat</primary></indexterm>
 	<indexterm><primary>browse.dat</primary></indexterm>
 	<indexterm><primary>resolution</primary></indexterm>
-	Following a change of hostname (netbios name) it is a good idea on all servers to
-	shutdown the Samba <command>smbd, nmbd</command> and <command>winbindd</command>
-	services, delete the <filename>wins.dat</filename> and <filename>browse.dat</filename>
-	files, then restart Samba. This will ensure that the old name and IP address
-	information is no longer able to interfere with name to IP address resolution.
-	If this is not done, there can be temporary name resolution problems. These
-	problems usually clear within 45 minutes of a name change, but can persist for
-	a longer period of time.
+	Following a change of hostname (NetBIOS name) it is a good idea on all servers
+	to shut down the Samba <command>smbd</command>, <command>nmbd</command>, and
+	<command>winbindd</command> services, delete the <filename>wins.dat</filename>
+	and <filename>browse.dat</filename> files, then restart Samba. This will ensure
+	that the old name and IP address information is no longer able to interfere with
+	name to IP address resolution.  If this is not done, there can be temporary name
+	resolution problems. These problems usually clear within 45 minutes of a name
+	change, but can persist for a longer period of time.
 	</para>
 
 	<para>
@@ -1084,12 +1087,13 @@ back to searching the 'ldap suffix' in some cases.
 	<indexterm><primary>/etc/passwd</primary></indexterm>
 	<indexterm><primary>/etc/shadow</primary></indexterm>
 	<indexterm><primary>/etc/group</primary></indexterm>
-	If the old DMS had local accounts, it is necessary to create on the new DMS
-	the same accounts with the same UID and GID for each account. Where the
-	<parameter>passdb backend</parameter> database is stored in the <constant>smbpasswd</constant>
-	or in the <constant>tdbsam</constant> format the user and group account
-	information for UNIX accounts, that match the Samba accounts, will reside in
-	the system <filename>/etc/passwd, /etc/shadow</filename> and
+	If the old domain member server had local accounts, it is necessary to create
+	on the new domain member server the same accounts with the same UID and GID
+	for each account. Where the <parameter>passdb backend</parameter> database
+	is stored in the <constant>smbpasswd</constant> or in the
+	<constant>tdbsam</constant> format, the user and group account information
+	for UNIX accounts that match the Samba accounts will reside in the system
+	<filename>/etc/passwd, /etc/shadow</filename>, and
 	<filename>/etc/group</filename> files. In this case be sure to copy these
 	account entries to the new target server.
 	</para>
@@ -1098,7 +1102,7 @@ back to searching the 'ldap suffix' in some cases.
 	<indexterm><primary>nss_ldap</primary></indexterm>
 	Where the user accounts for both UNIX and Samba are stored in LDAP, the new
 	target server must be configured to use the <command>nss_ldap</command> tool set.
-	This will then automatically ensure that the appropriate user entities are
+	This will automatically ensure that the appropriate user entities are
 	available on the new server.
 	</para>
 
@@ -1109,8 +1113,8 @@ back to searching the 'ldap suffix' in some cases.
 
 	<para>
 	<indexterm><primary>domain</primary><secondary>controller</secondary></indexterm>
-	In the past, people who replaced a Windows NT4 domain controller would typically
-	install a new server, create printers and file shares on it, then migrate across
+	In the past, people who replaced a Windows NT4 domain controller typically
+	installed a new server, created printers and file shares on it, then migrate across
 	all data that was destined to reside on it. The same can of course be done with
 	Samba.
 	</para>
@@ -1119,22 +1123,22 @@ back to searching the 'ldap suffix' in some cases.
 	From recent mailing list postings it would seem that some administrators
 	have the intent to just replace the old Samba server with a new one with
 	the same name as the old one. In this case, simply follow the same process
-	as upgrading a Samba 2.x system in respect of the following:
+	as for upgrading a Samba 2.x system and do the following:
 	</para>
 
 	<itemizedlist>
 		<listitem><para>
 		Where UNIX (POSIX) user and group accounts are stored in the system
-		<filename>/etc/passwd, /etc/shadow</filename> and 
-		<filename>/etc/group</filename> files be sure to add the same accounts
+		<filename>/etc/passwd, /etc/shadow</filename>, and 
+		<filename>/etc/group</filename> files, be sure to add the same accounts
 		with identical UID and GID values for each user.
 		</para>
 
 		<para>
-		Where LDAP is used, if the new system is intended to be the LDAP server
+		Where LDAP is used, if the new system is intended to be the LDAP server,
 		migrate it across by configuring the LDAP server 
-		(<filename>/etc/openldap/slapd.conf</filename>). The directory can either
-		be populated initially by setting this LDAP server up as a slave, or else
+		(<filename>/etc/openldap/slapd.conf</filename>). The directory can
+		be populated either initially by setting this LDAP server up as a slave or
 		by dumping the data from the old LDAP server using the <command>slapcat</command>
 		command and then reloading the same data into the new LDAP server using the
 		<command>slapadd</command> command. Do not forget to install and configure
@@ -1156,7 +1160,7 @@ back to searching the 'ldap suffix' in some cases.
 
 		<listitem><para>
 		Before starting the Samba daemons, verify that the hostname of the new server
-		is identical with that of the old one. Note: The IP address can be different
+		is identical to that of the old one. Note: The IP address can be different
 		from that of the old server.
 		</para></listitem>
 
@@ -1175,11 +1179,11 @@ back to searching the 'ldap suffix' in some cases.
 	</para>
 
 	<para>
-	All Samba servers, other than one that uses LDAP, depend on the tdb files, and in
-	particular the <filename>secrets.tdb</filename> file. So long as the tdb files are
+	All Samba servers, other than one that uses LDAP, depend on the tdb files, and
+	particularly on the <filename>secrets.tdb</filename> file. So long as the tdb files are
 	all in place, the &smb.conf; file is preserved, and either the hostname is identical
 	or the <parameter>netbios name</parameter> is set to the original server name, Samba
-	should correctly pick up the original SID, and preserve all other settings. It is
+	should correctly pick up the original SID and preserve all other settings. It is
 	sound advice to validate this before turning the system over to users.
 	</para>
 
@@ -1208,7 +1212,7 @@ back to searching the 'ldap suffix' in some cases.
 
 		<step><para>
 		In the Advanced/DNS section of the TCP/IP settings on your Windows 
-		workstations, make sure <parameter>DNS suffix for this 
+		workstations, make sure the <parameter>DNS suffix for this 
 		connection</parameter> field is blank. 
 		</para></step>
 
@@ -1234,7 +1238,7 @@ back to searching the 'ldap suffix' in some cases.
 		and satisfy all errors before committing the migration. Note that the 
 		test will always fail, because the machine will not have been actually 
 		migrated. You'll need to interpret the errors to know whether the 
-		failure was due to a problem, or simply due to the fact that it was just 
+		failure was due to a problem or simply to the fact that it was just 
 		a test.
 		</para></step>
 
@@ -1249,7 +1253,7 @@ back to searching the 'ldap suffix' in some cases.
 
 	<itemizedlist>
 		<listitem><para>
-		You can also migrate workstations remotely. You can specify that SIDs 
+		You can migrate workstations remotely. You can specify that SIDs 
 		be simply added instead of replaced, giving you the option of joining a 
 		workstation back to the old domain if something goes awry. The 
 		workstations will be joined to the new domain.
@@ -1271,7 +1275,7 @@ back to searching the 'ldap suffix' in some cases.
 		The ADMT lets you test all operations before actually performing the 
 		migration. Accounts and workstations can be migrated individually or in 
 		batches. User accounts can be safely migrated all at once (since no 
-		changes are made on the original domain); It is recommended to migrate only one 
+		changes are made on the original domain). It is recommended to migrate only one 
 		or two workstations as a test before committing them all.
 		</para></listitem>