summaryrefslogtreecommitdiff
path: root/docs/docbook/projdoc
diff options
context:
space:
mode:
Diffstat (limited to 'docs/docbook/projdoc')
-rw-r--r--docs/docbook/projdoc/Samba-PDC-HOWTO.xml264
-rw-r--r--docs/docbook/projdoc/ServerType.xml258
-rw-r--r--docs/docbook/projdoc/UNIX_INSTALL.xml7
3 files changed, 316 insertions, 213 deletions
diff --git a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml
index 7952f7c75f..171300091d 100644
--- a/docs/docbook/projdoc/Samba-PDC-HOWTO.xml
+++ b/docs/docbook/projdoc/Samba-PDC-HOWTO.xml
@@ -20,14 +20,13 @@
<para>
There are many who approach MS Windows networking with incredible misconceptions.
That's OK, because it give the rest of us plenty of opportunity to help someone.
-Those who really want help would be well advised to not make too big a fool
-of themselves by not being informed when are where the information needed is in
-fact available.
+Those who really want help would be well advised to be informed of information that
+is in fact already available.
</para>
</formalpara>
<para>
-The reader is well advised NOT to tackle this section until having first understood
+The reader is well advised NOT to tackle this section without having first understood
and mastered some basics. MS Windows networking is not particularly forgiving of
misconfiguration. Users of MS Windows networking are likely to complain bitterly
of persistent niggles that may be caused by broken network or system configuration.
@@ -53,7 +52,7 @@ networking problems:
</itemizedlist>
<para>
-Now, do not be put off too much, on the surface of it MS Windows networking seems so simple
+Do not be put off too much, on the surface of it MS Windows networking seems so simple
that any fool can do it. In fact, only a fool would set up an MS Windows network with
inadequate training and preparation. So let's get our first indelible principle out of the
way: <emphasis>It is perfectly OK to make mistakes!</emphasis> In the right place and at
@@ -63,16 +62,105 @@ burden on an organisation.
</para>
<para>
-So where is the right place to make mistakes? Only out of harms' way! If you are going to
+Where is the right place to make mistakes? Only out of harms' way! If you are going to
make mistakes, then please do this on a test network, away from users and in such a way as
to not inflict pain on others. Do your learning on a test network.
</para>
<sect1>
-<title>Background</title>
+<title><Features and Benefits</title
-<sect2>
-<title>Domain Controller</title>
+<para>
+The following functionalities are new to the Samba-3 release:
+</para>
+
+<itemizedlist>
+ <listitem><para>
+ Windows NT4 domain trusts
+ </para></listitem>
+
+ <listitem><para>
+ Adding users via the User Manager for Domains
+ </para></listitem>
+</itemizedlist>
+
+<para>
+The following functionalities are NOT provided by Samba 3.0:
+</para>
+
+<itemizedlist>
+ <listitem><para>
+ SAM replication with Windows NT4 Domain Controllers
+ (i.e. a Samba PDC and a Windows NT BDC or vice versa)
+ </para></listitem>
+
+ <listitem><para>
+ Acting as a Windows 2000 Domain Controller (i.e. Kerberos and
+ Active Directory)
+ </para></listitem>
+</itemizedlist>
+
+<para>
+Please note that Windows 9x / Me / XP Home clients are not true members of a domain
+for reasons outlined in this article. Therefore the protocol for
+support of Windows 9x-style domain logons is completely different
+from NT4 / Win2k type domain logons and has been officially supported for some
+time.
+</para>
+
+<para><emphasis>
+MS Windows XP Home edition is NOT able to join a domain and does not permit
+the use of domain logons.</emphasis>
+</para>
+
+<para>
+Samba-3 offers a complete implementation of group mapping between Windows NT groups
+and Unix groups (this is really quite complicated to explain in a short space).
+</para>
+
+<para>
+A Samba-3 PDC also has to store machine trust account information
+in a suitable backend data store. With Samba-3 there can be multiple back-ends
+for this including:
+</para>
+
+<itemizedlist>
+ <listitem><para>
+ <emphasis>smbpasswd</emphasis> - the plain ascii file stored used by
+ earlier versions of Samba. This file configuration option requires
+ a Unix/Linux system account for EVERY entry (ie: both for user and for
+ machine accounts). This file will be located in the <emphasis>private</emphasis>
+ directory (default is /usr/local/samba/lib/private or on linux /etc/samba).
+ </para></listitem>
+
+ <listitem><para>
+ <emphasis>tdbsam</emphasis> - a binary database backend that will be
+ stored in the <emphasis>private</emphasis> directory in a file called
+ <emphasis>passwd.tdb</emphasis>. The key benefit of this binary format
+ file is that it can store binary objects that can not be accomodated
+ in the traditional plain text smbpasswd file.
+ </para></listitem>
+
+ <listitem><para>
+ <emphasis>ldapsam</emphasis> - An LDAP based back-end. Permits the
+ LDAP server to be specified. eg: ldap://localhost or ldap://frodo.murphy.com
+ </para></listitem>
+</itemizedlist>
+
+<para>Read the chapter about the <link linkend="passdb">User Database</link>
+for details.</para>
+
+<note><para>
+The new tdbsam and ldapsam account backends store vastly more information than
+smbpasswd is capable of. The new backend database includes capacity to specify
+per user settings for many parameters, over-riding global settings given in the
+<filename>smb.conf</filename> file. eg: logon drive, logon home, logon path, etc.
+</para></note>
+
+</sect1>
+
+<sect1>
+<title>Basics of Domain Control</title>
<para>
Over the years public perceptions of what Domain Control really is has taken on an
@@ -80,7 +168,7 @@ almost mystical nature. Before we branch into a brief overview of Domain Control
there are three basic types of domain controllers:
</para>
-<sect3>
+<sect2>
<title>Domain Controller Types</title>
<itemizedlist>
@@ -92,7 +180,11 @@ there are three basic types of domain controllers:
<para>
The <emphasis>Primary Domain Controller</emphasis> or PDC plays an important role in the MS
Windows NT4 and Windows 200x Domain Control architecture, but not in the manner that so many
-expect.
+expect. There is a form of folk lore that dictates that because of it's role in the MS Windows
+network that the PDC should be the most powerful and most capable machine in the network.
+As corny as it may seem to say this here, where good over all network performance is desired
+the entire infrastructure needs to be balanced. It may be more advisable to invest more in
+the Backup Domain Controllers and Stand-Alone (or Domain Member) servers than in the PDC.
</para>
<para>
@@ -103,22 +195,21 @@ database with Backup Domain Controllers.
</para>
<para>
-New to Samba-3 is the ability to use a back-end file that holds the same type of data as
+New to Samba-3 is the ability to use a back-end database that holds the same type of data as
the NT4 style SAM (Security Account Manager) database (one of the registry files).
-The samba-3 SAM can be specified via the smb.conf file parameter "passwd backend" and
-valid options include <emphasis> smbpasswd tdbsam ldapsam nisplussam plugin unixsam</emphasis>.
-The smbpasswd, tdbsam and ldapsam options can have a "_nua" suffix to indicate that No Unix
-Accounts need to be created. In other words, the Samba SAM will be independant of Unix/Linux
-system accounts, provided a uid range is defined from which SAM accounts can be created.
+The samba-3 SAM can be specified via the smb.conf file parameter
+<emphasis>passwd backend</emphasis> and valid options include
+<emphasis>smbpasswd, tdbsam, ldapsam, nisplussam, xmlsam, mysqlsam, plugin, guest</emphasis>.
</para>
<para>
The <emphasis>Backup Domain Controller</emphasis> or BDC plays a key role in servicing network
-authentication requests. The BDC is biased to answer logon requests so that on a network segment
-that has a BDC and a PDC the BDC will be most likely to service network logon requests. The PDC will
-answer network logon requests when the BDC is too busy (high load). A BDC can be promoted to
-a PDC. If the PDC is on line at the time that the BDC is promoted to PDC the previous PDC is
-automatically demoted to a BDC.
+authentication requests. The BDC is biased to answer logon requests in preference to the PDC.
+On a network segment that has a BDC and a PDC the BDC will be most likely to service network
+logon requests. The PDC will answer network logon requests when the BDC is too busy (high load).
+A BDC can be promoted to a PDC. If the PDC is on line at the time that the BDC is promoted to
+PDC the previous PDC is automatically demoted to a BDC. With Samba-3 this is NOT an automatic
+operation, the PDB and BDC must be manually configured and changes need to be made likewise.
</para>
<para>
@@ -141,16 +232,25 @@ Active Directory domain.
</para>
<para>
+New to Samba-3 is the ability to function fully as an MS Windows NT4 style Domain Controller,
+excluding the SAM replication components. However, please be aware that Samba-3 support the
+MS Windows 200x domain control protcols also.
+</para>
+
+<para>
At this time Samba-3 is capable of acting as an <emphasis>ADS Domain Controller</emphasis> but
in only a limited and experimental manner. This functionality should not be depended upon
until the samba-team offers formal support for it. At such a time, the documentation will
be revised to duely reflect all configuration and management requirements.
</para>
-</sect3>
+
</sect2>
+<sect2>
+<title>Preparing for Domain Control<title>
+
<para>
-This article outlines the steps necessary for configuring Samba-3 as an MS Windows NT4 style PDC.
+The following outlines the steps necessary for configuring Samba-3 as an MS Windows NT4 style PDC.
It is necessary to have a working Samba server prior to implementing the PDC functionality.
</para>
@@ -185,61 +285,21 @@ that are covered separately in this document.
</note>
<para>
-The following functionalities are new to the Samba-3 release:
-</para>
-
-<itemizedlist>
- <listitem><para>
- Windows NT4 domain trusts
- </para></listitem>
-
- <listitem><para>
- Adding users via the User Manager for Domains
- </para></listitem>
-</itemizedlist>
-
-<para>
-The following functionalities are NOT provided by Samba 3.0:
+Implementing a Samba PDC can basically be divided into 4 broad
+steps.
</para>
-<itemizedlist>
- <listitem><para>
- SAM replication with Windows NT4 Domain Controllers
- (i.e. a Samba PDC and a Windows NT BDC or vice versa)
- </para></listitem>
-
+<orderedlist numeration="arabic">
<listitem><para>
- Acting as a Windows 2000 Domain Controller (i.e. Kerberos and
- Active Directory)
+ Configuration of basic MS Windows Networking
</para></listitem>
-</itemizedlist>
-
-<para>
-Please note that Windows 9x / Me / XP Home clients are not true members of a domain
-for reasons outlined in this article. Therefore the protocol for
-support of Windows 9x-style domain logons is completely different
-from NT4 / Win2k type domain logons and has been officially supported for some
-time.
-</para>
-
-<para><emphasis>
-MS Windows XP Home edition is NOT able to join a domain and does not permit
-the use of domain logons.</emphasis>
-</para>
-
-
-<para>
-Implementing a Samba PDC can basically be divided into 3 broad
-steps.
-</para>
-<orderedlist numeration="arabic">
<listitem><para>
Configuring the Samba PDC
</para></listitem>
<listitem><para>
- Creating machine trust accounts and joining clients to the domain
+ Creating machine trust accounts and joining machines to the domain
</para></listitem>
<listitem><para>
@@ -248,15 +308,16 @@ steps.
</orderedlist>
<para>
-There are other minor details such as user profiles, system policies, etc...
+There are other details such as user profiles, system policies, etc.
However, these are not necessarily specific to a Samba PDC as much as they are
related to Windows NT networking concepts.
</para>
+</sect2>
</sect1>
<sect1>
-<title>Configuring Samba NT4 Style Domain Control</title>
+<title>Domain Control - Example Configuration</title>
<para>
The first step in creating a working Samba PDC is to understand the parameters necessary
@@ -355,20 +416,13 @@ There are a couple of points to emphasize in the above configuration.
</para></listitem>
</itemizedlist>
-<para>
-Samba 3.0 offers a complete implementation of group mapping
-between Windows NT groups and Unix groups (this is really quite
-complicated to explain in a short space).
-</para>
-
<sect2>
-<title>Creating Machine Trust Accounts and Joining Clients to the Domain</title>
+<title>Machine Trust Accounts and Domain Membership</title>
<para>
-A machine trust account is a Samba account that is used to
-authenticate a client machine (rather than a user) to the Samba
-server. In Windows terminology, this is known as a "Computer
-Account."</para>
+A machine trust account is an account that is used to authenticate a client machine
+(rather than a user) to the Domain Controller server. In Windows terminology,
+this is known as a "Computer Account."</para>
<para>
The password of a machine trust account acts as the shared secret for
@@ -388,45 +442,6 @@ the new repository for machine trust accounts.
</para>
<para>
-A Samba-3 PDC also has to store machine trust account information
-in a suitable backend data store. With Samba-3 there can be multiple back-ends
-for this including:
-</para>
-
-<itemizedlist>
- <listitem><para>
- <emphasis>smbpasswd</emphasis> - the plain ascii file stored used by
- earlier versions of Samba. This file configuration option requires
- a Unix/Linux system account for EVERY entry (ie: both for user and for
- machine accounts). This file will be located in the <emphasis>private</emphasis>
- directory (default is /usr/local/samba/lib/private or on linux /etc/samba).
- </para></listitem>
-
- <listitem><para>
- <emphasis>tdbsam</emphasis> - a binary database backend that will be
- stored in the <emphasis>private</emphasis> directory in a file called
- <emphasis>passwd.tdb</emphasis>. The key benefit of this binary format
- file is that it can store binary objects that can not be accomodated
- in the traditional plain text smbpasswd file.
- </para></listitem>
-
- <listitem><para>
- <emphasis>ldapsam</emphasis> - An LDAP based back-end. Permits the
- LDAP server to be specified. eg: ldap://localhost or ldap://frodo.murphy.com
- </para></listitem>
-</itemizedlist>
-
-<para>Read the chapter about the <link linkend="passdb">User Database</link>
-for details.</para>
-
-<note><para>
-The new tdbsam and ldapsam account backends store vastly more information than
-smbpasswd is capable of. The new backend database includes capacity to specify
-per user settings for many parameters, over-riding global settings given in the
-<filename>smb.conf</filename> file. eg: logon drive, logon home, logon path, etc.
-</para></note>
-
-<para>
A Samba PDC, however, stores each machine trust account in two parts,
as follows:
@@ -504,7 +519,6 @@ appended to the NetBIOS name of the client or Samba will not recognize
this as a machine trust account.
</para>
-
<para>
Now that the corresponding Unix account has been created, the next step is to create
the Samba account for the client containing the well-known initial
@@ -558,7 +572,8 @@ be created manually.
</para>
-<para>Below is an example for a RedHat 6.2 Linux system.
+<para>
+Below is an example for a RedHat Linux system.
</para>
<para><programlisting>
@@ -573,8 +588,7 @@ be created manually.
<sect3><title>Joining the Client to the Domain</title>
<para>
-The procedure for joining a client to the domain varies with the
-version of Windows.
+The procedure for joining a client to the domain varies with the version of Windows.
</para>
<itemizedlist>
diff --git a/docs/docbook/projdoc/ServerType.xml b/docs/docbook/projdoc/ServerType.xml
index ce2af3887b..2e6ee5712c 100644
--- a/docs/docbook/projdoc/ServerType.xml
+++ b/docs/docbook/projdoc/ServerType.xml
@@ -11,14 +11,81 @@
This chapter provides information regarding the types of server that Samba may be
configured to be. A Microsoft network administrator who wishes to migrate to or to
use Samba will want to know what within a Samba context, terms familiar to MS Windows
-adminstrator mean.
+adminstrator mean. This means that it is essential also to define how critical security
+contexts function BEFORE we get into the details of how to configure the server itself.
</para>
<para>
-The chapter also provides an overview of the security modes of which Samba is capable
+The chapter provides an overview of the security modes of which Samba is capable
and how these relate to MS Windows servers and clients.
</para>
+<para>
+Firstly we should recognise the question so often asked, "Why would I want to use Samba?"
+So, in those chapters where the answer may be important you will see a section that highlights
+features and benefits. These may be for or against Samba.
+</para>
+
+<sect1>
+<title>Samba Features and Benefits</title>
+
+<para>
+Two men were walking down a dusty road, when one suddenly kicked up a small red stone. It
+hurt his toe and lodged in his sandle. He took the stone out and cursed it with a passion
+and fury fitting his anguish. The other looked at the stone and said, that is a garnet - I
+can turn that into a precious gem and some day it will make a princess very happy!
+</para>
+
+<para>
+The moral of this tale: Two men, two very different perspectives regarding the same stone.
+Like it or not, Samba is like that stone. Treated the right way and it can bring great
+pleasure, but if you are forced upon it and have no time for it's secrets then it can be
+a source of discomfort.
+</para>
+
+<para>
+Samba started out as a project that sought to provide interoperability for MS Windows 3.x
+clients with a Unix server. It has grown up a lot since it's humble beginnings and now provides
+features and functionality fit for large scale deployment. It also has some warts. In sections
+like this one we will tell of both.
+</para>
+
+<para>
+So now, what features are covered in this chapter?
+</para>
+
+<itemizedlist>
+ <listitem><para>
+ X
+ </para></listitem>
+
+ <listitem><para>
+ X
+ </para></listitem>
+
+ <listitem><para>
+ X
+ </para></listitem>
+
+ <listitem><para>
+ X
+ </para></listitem>
+
+ <listitem><para>
+ X
+ </para></listitem>
+
+ <listitem><para>
+ X
+ </para></listitem>
+
+ <listitem><para>
+ X
+ </para></listitem>
+</itemizedlist>
+
+</sect1>
+
<sect1>
<title>Server Types</title>
@@ -174,92 +241,6 @@ with share mode security servers. You are strongly discouraged from use of this
</sect2>
<sect2>
-<title>Server Level Security</title>
-
-<para>
-Now to review <emphasis>server level</emphasis> security. In server level security the samba
-server reports to the client that it is in user level security. The client then does a
-<emphasis>session setup</emphasis> as described earlier. The samba server takes the
-username/password that the client sends and attempts to login to the
-<emphasis>password server</emphasis> by sending exactly the same username/password that
-it got from the client. If that server is in user level security and accepts the password
-then samba accepts the clients connection. This allows the samba server to use another SMB
-server as the <emphasis>password server</emphasis>.
-</para>
-
-<para>
-You should also note that at the very start of all this, where the server tells the client
-what security level it is in, it also tells the client if it supports encryption. If it
-does then it supplies the client with a random cryptkey. The client will then send all
-passwords in encrypted form. Samba supports this type of encryption by default.
-</para>
-
-<para>
-The parameter <emphasis>security = server</emphasis> means that Samba reports to clients that
-it is running in <emphasis>user mode</emphasis> but actually passes off all authentication
-requests to another <emphasis>user mode</emphasis> server. This requires an additional
-parameter <emphasis>password server</emphasis> that points to the real authentication server.
-That real authentication server can be another Samba server or can be a Windows NT server,
-the later natively capable of encrypted password support.
-</para>
-
-<note><para>
-When Samba is running in <emphasis>server level</emphasis> security it is essential that
-the parameter <emphasis>password server</emphasis> is set to the precise netbios machine
-name of the target authentication server. Samba can NOT determine this from NetBIOS name
-lookups because the choice of the target authentication server arbitrary and can not
-be determined from a domain name. In essence a samba server that is in
-<emphasis>server level</emphasis> security is operating in what used to be known as
-workgroup mode.
-</para></note>
-
-<note><para>
-<emphasis>Server level</emphasis> security is incompatible with what is known as
-<emphasis>schannel</emphasis> or <emphasis>sign and seal</emphasis> protocols. This means that
-if you want to use <emphasis>server</emphasis> level security you must disable the use of
-<emphasis>sign and seal</emphasis> on all machines on your network.
-</para></note>
-
-<sect3>
-<title>Example Configuration</title>
-<para><emphasis>
-Using MS Windows NT as an authentication server
-</emphasis></para>
-
-<para>
-This method involves the additions of the following parameters in the &smb.conf; file:
-</para>
-
-<para><programlisting>
- encrypt passwords = Yes
- security = server
- password server = "NetBIOS_name_of_a_DC"
-</programlisting></para>
-
-
-<para>
-There are two ways of identifying whether or not a username and password pair was valid
-or not. One uses the reply information provided as part of the authentication messaging
-process, the other uses just an error code.
-</para>
-
-<para>
-The down-side of this mode of configuration is the fact that for security reasons Samba
-will send the password server a bogus username and a bogus password and if the remote
-server fails to reject the username and password pair then an alternative mode of
-identification of validation is used. Where a site uses password lock out after a
-certain number of failed authentication attempts this will result in user lockouts.
-</para>
-
-<para>
-Use of this mode of authentication does require there to be a standard Unix account
-for the user, this account can be blocked to prevent logons by other than MS Windows clients.
-</para>
-
-</sect3>
-</sect2>
-
-<sect2>
<title>Domain Level Security</title>
<para>
@@ -367,6 +348,107 @@ regarding this configuration option.
</sect3>
</sect2>
+
+<sect2>
+<title>Server Level Security</title>
+
+<para>
+Server level security is a left over from the time when Samba was not capable of acting
+as a domain member server. It is highly recommended NOT to use this feature. Server level
+security has many draw backs. The draw backs include:
+</para>
+
+<itemizedlist>
+ <listitem><para>Potential Account Lockout on MS Windows NT4/200x password servers</para></listitem>
+ <listitem><para>Lack of assurance that the password server is the one specified</para></listitem>
+ <listitem><para>Does not work with Winbind, particularly needed when storing profiles remotely</para></listitem>
+ <listitem><para>This mode may open connections to the password server, and keep them open for extended periods.</para></listitem>
+ <listitem><para>Security on the samba server breaks badly when the remote password server suddenly shuts down</para></listitem>
+ <listitem><para>With this mode there is NO security account in the domain that the password server belongs to for the samba server.</para></listitem>
+</itemizedlist>
+
+<para>
+In server level security the samba server reports to the client that it is in user level
+security. The client then does a <emphasis>session setup</emphasis> as described earlier.
+The samba server takes the username/password that the client sends and attempts to login to the
+<emphasis>password server</emphasis> by sending exactly the same username/password that
+it got from the client. If that server is in user level security and accepts the password
+then samba accepts the clients connection. This allows the samba server to use another SMB
+server as the <emphasis>password server</emphasis>.
+</para>
+
+<para>
+You should also note that at the very start of all this, where the server tells the client
+what security level it is in, it also tells the client if it supports encryption. If it
+does then it supplies the client with a random cryptkey. The client will then send all
+passwords in encrypted form. Samba supports this type of encryption by default.
+</para>
+
+<para>
+The parameter <emphasis>security = server</emphasis> means that Samba reports to clients that
+it is running in <emphasis>user mode</emphasis> but actually passes off all authentication
+requests to another <emphasis>user mode</emphasis> server. This requires an additional
+parameter <emphasis>password server</emphasis> that points to the real authentication server.
+That real authentication server can be another Samba server or can be a Windows NT server,
+the later natively capable of encrypted password support.
+</para>
+
+<note><para>
+When Samba is running in <emphasis>server level</emphasis> security it is essential that
+the parameter <emphasis>password server</emphasis> is set to the precise netbios machine
+name of the target authentication server. Samba can NOT determine this from NetBIOS name
+lookups because the choice of the target authentication server arbitrary and can not
+be determined from a domain name. In essence a samba server that is in
+<emphasis>server level</emphasis> security is operating in what used to be known as
+workgroup mode.
+</para></note>
+
+<note><para>
+<emphasis>Server level</emphasis> security is incompatible with what is known as
+<emphasis>schannel</emphasis> or <emphasis>sign and seal</emphasis> protocols. This means that
+if you want to use <emphasis>server</emphasis> level security you must disable the use of
+<emphasis>sign and seal</emphasis> on all machines on your network.
+</para></note>
+
+<sect3>
+<title>Example Configuration</title>
+<para><emphasis>
+Using MS Windows NT as an authentication server
+</emphasis></para>
+
+<para>
+This method involves the additions of the following parameters in the &smb.conf; file:
+</para>
+
+<para><programlisting>
+ encrypt passwords = Yes
+ security = server
+ password server = "NetBIOS_name_of_a_DC"
+</programlisting></para>
+
+
+<para>
+There are two ways of identifying whether or not a username and password pair was valid
+or not. One uses the reply information provided as part of the authentication messaging
+process, the other uses just an error code.
+</para>
+
+<para>
+The down-side of this mode of configuration is the fact that for security reasons Samba
+will send the password server a bogus username and a bogus password and if the remote
+server fails to reject the username and password pair then an alternative mode of
+identification of validation is used. Where a site uses password lock out after a
+certain number of failed authentication attempts this will result in user lockouts.
+</para>
+
+<para>
+Use of this mode of authentication does require there to be a standard Unix account
+for the user, this account can be blocked to prevent logons by other than MS Windows clients.
+</para>
+
+</sect3>
+</sect2>
+
</sect1>
<sect1>
diff --git a/docs/docbook/projdoc/UNIX_INSTALL.xml b/docs/docbook/projdoc/UNIX_INSTALL.xml
index 3ad83c1f9d..39fac749b9 100644
--- a/docs/docbook/projdoc/UNIX_INSTALL.xml
+++ b/docs/docbook/projdoc/UNIX_INSTALL.xml
@@ -2,6 +2,7 @@
<chapterinfo>
&author.tridge;
&author.jelmer;
+ &author.jht;
<author><firstname>Karl</firstname><surname>Auer</surname></author>
<!-- Isn't some of this written by others as well? -->
@@ -19,6 +20,12 @@
<para>If you need to compile samba from source, check the
<link linkend="compiling">appropriate appendix chapter</link>.</para>
+
+ <para>If you have already installed samba, or if your operating system
+ was pre-installed with samba, then you may not need to bother with this
+ chapter. On the other hand, you may want to read this chapter anyhow
+ for information about updating samba.</para>
+
</sect1>
<sect1>