More edits. Hackety Hack.

(This used to be commit 6829762e3d71bd934b834dc2f09cc136758d04e0)

1 files changed, 91 insertions, 10 deletions

diff --git a/docs/docbook/projdoc/StandAloneServer.xml b/docs/docbook/projdoc/StandAloneServer.xml
index c5b5c67250..1246ff0f3a 100644
--- a/docs/docbook/projdoc/StandAloneServer.xml
+++ b/docs/docbook/projdoc/StandAloneServer.xml
@@ -4,8 +4,42 @@
 </chapterinfo>
 <title>Stand-Alone Servers</title>
 
+<para>
+Stand-Alone servers are independant of an Domain Controllers on the network.
+They are NOT domain members and function more like workgroup servers. In many
+cases a stand-alone server is configured with a minimum of security control
+with the intent that all data served will be readilly accessible to all users.
+</para>
+
+<sect1>
+<title>Features and Benefits</title>
+
+<para>
+Stand-Alone servers can be as secure or as insecure as needs dictate. They can
+have simple or complex configurations. Above all, despite the hoopla about
+Domain security they remain a very common installation.
+</para>
+
+<para>
+If all that is needed is a server for read-only files, or for
+printers alone, it may not make sense to affect a complex installation.
+For example: A drafting office needs to store old drawings and reference
+standards. No-one can write files to the server as it is legislatively
+important that all documents remain unaltered. A share mode read-only stand-alone
+server is an ideal solution.
+</para>
+
+<para>
+Another situation that warrants simplicity is an office that has many printers
+that are queued off a single central server. Everyone needs to be able to print
+to the printers, there is no need to affect any access controls and no files will
+be served from the print server. Again a share mode stand-alone server makes
+a great solution.
+</para>
+</sect1>
+
 <sect1>
-<title>Stand Alone Server</title>
+<title>Background</title>
 
 <para>
 The term <emphasis>stand alone server</emphasis> means that the server
@@ -13,21 +47,22 @@ will provide local authentication and access control for all resources
 that are available from it. In general this means that there will be a
 local user database. In more technical terms, it means that resources
 on the machine will either be made available in either SHARE mode or in
-USER mode. SHARE mode and USER mode security are documented under
-discussions regarding "security mode". The smb.conf configuration parameters
-that control security mode are: "security = user" and "security = share".
+USER mode.
 </para>
 
 <para>
 No special action is needed other than to create user accounts. Stand-alone
-servers do NOT provide network logon services, meaning that machines that
-use this server do NOT perform a domain logon but instead make use only of
-the MS Windows logon which is local to the MS Windows workstation/server.
+servers do NOT provide network logon services. This means that machines that
+use this server do NOT perform a domain log onto it. Whatever logon facility
+the workstations are subject to is independant of this machine. It is however
+necessary to accomodate any network user so that the logon name they use will
+be translated (mapped) locally on the stand-alone server to a locally known
+user name. There are several ways this cane be done.
 </para>
 
 <para>
 Samba tends to blur the distinction a little in respect of what is
-a stand alone server. This is because the authentication database may be
+a stand-alone server. This is because the authentication database may be
 local or on a remote server, even if from the samba protocol perspective
 the samba server is NOT a member of a domain security context.
 </para>
@@ -38,10 +73,56 @@ Through the use of PAM (Pluggable Authentication Modules) and nsswitch
 another server. We would be inclined to call this the authentication server.
 This means that the samba server may use the local Unix/Linux system
 password database (/etc/passwd or /etc/shadow), may use a local smbpasswd
-file (/etc/samba/smbpasswd or /usr/local/samba/lib/private/smbpasswd), or
-may use an LDAP back end, or even via PAM and Winbind another CIFS/SMB
+file, or may use an LDAP back end, or even via PAM and Winbind another CIFS/SMB
 server for authentication.
 </para>
 
 </sect1>
+
+<sect1>
+<title>Example Configuration</title>
+
+<para>
+The following examples are designed to inspire simplicity. It is too easy to
+attempt a high level of creativity and to introduce too much complexity in
+server and network design.
+</para>
+
+<sect2>
+<title>Reference Documentation Server</title>
+
+<para>
+Put one here!
+</para>
+
+</sect2>
+
+<sect2>
+<title>Central Print Serving</title>
+
+<para>
+Put one here!
+</para>
+
+</sect2>
+
+<sect2>
+<title>Legal Office Daily Work Server</title>
+
+<para>
+Put one here!
+</para>
+
+</sect2>
+
+</sect1>
+
+<sect1>
+<title>Common Errors</title>
+
+<para>
+Put stuff here.
+</para>
+
+</sect1>
 </chapter>