1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
<chapter id="StandAloneServer">
<chapterinfo>
&author.jht;
</chapterinfo>
<title>Stand-Alone Servers</title>
<para>
Stand-Alone servers are independent of 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 readily 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>Background</title>
<para>
The term <emphasis>stand-alone server</emphasis> means that the server
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 be made available in either SHARE mode or in
USER mode.
</para>
<para>
No special action is needed other than to create user accounts. Stand-alone
servers do NOT provide network logon services. This means that machines that
use this server do NOT perform a domain logon to it. Whatever logon facility
the workstations are subject to is independent of this machine. It is however
necessary to accommodate 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 can 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
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>
<para>
Through the use of PAM (Pluggable Authentication Modules) and nsswitch
(the name service switcher) the source of authentication may reside on
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
(<filename>/etc/passwd</filename> or <filename>/etc/shadow</filename>), may use a
local smbpasswd 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>
Configuration of a read-only data server that EVERYONE can access is very simple.
Here is the smb.conf file that will do this. Assume that all the reference documents
are stored in the directory /export, that the documents are owned by a user other than
nobody. No home directories are shared, that are no users in the <filename>/etc/passwd</filename>
Unix system database. This is a very simple system to administer.
</para>
<programlisting>
# Global parameters
[global]
workgroup = MYGROUP
netbios name = REFDOCS
security = SHARE
passdb backend = guest
wins server = 192.168.1.1
[data]
comment = Data
path = /export
guest only = Yes
</programlisting>
<para>
In the above example the machine name is set to REFDOCS, the workgroup is set to the name
of the local workgroup so that the machine will appear in with systems users are familiar
with. The only password backend required is the "guest" backend so as to allow default
unprivileged account names to be used. Given that there is a WINS server on this network
we do use it.
</para>
</sect2>
<sect2>
<title>Central Print Serving</title>
<para>
Configuration of a simple print server is very simple if you have all the right tools
on your system.
</para>
<orderedlist>
<title> Assumptions:</title>
<listitem><para>
The print server must require no administration
</para></listitem>
<listitem><para>
The print spooling and processing system on our print server will be CUPS.
(Please refer to the <link linkend="CUPS-printing">CUPS Printing</link> chapter for more information).
</para></listitem>
<listitem><para>
All printers that the print server will service will be network
printers. They will be correctly configured, by the administrator,
in the CUPS environment.
</para></listitem>
<listitem><para>
All workstations will be installed using postscript drivers. The printer
of choice is the Apple Color LaserWriter.
</para></listitem>
</orderedlist>
<para>
In this example our print server will spool all incoming print jobs to
<filename>/var/spool/samba</filename> until the job is ready to be submitted by
Samba to the CUPS print processor. Since all incoming connections will be as
the anonymous (guest) user, two things will be required:
</para>
<itemizedlist>
<title>Enabling Anonymous Printing</title>
<listitem><para>
The Unix/Linux system must have a <command>guest</command> account.
The default for this is usually the account <command>nobody</command>.
To find the correct name to use for your version of Samba do the
following:
<screen>
<prompt>$ </prompt><userinput>testparm -s -v | grep "guest account"</userinput>
</screen>
Then make sure that this account exists in your system password
database (<filename>/etc/passwd</filename>).
</para></listitem>
<listitem><para>
The directory into which Samba will spool the file must have write
access for the guest account. The following commands will ensure that
this directory is available for use:
<screen>
&rootprompt;<userinput>mkdir /var/spool/samba</userinput>
&rootprompt;<userinput>chown nobody.nobody /var/spool/samba</userinput>
&rootprompt;<userinput>chmod a+rwt /var/spool/samba</userinput>
</screen>
</para></listitem>
</itemizedlist>
<para>
<programlisting>
# Global parameters
[global]
workgroup = MYGROUP
netbios name = PTRSVR1
security = SHARE
passdb backend = guest
wins server = 192.168.1.1
[printers]
comment = All Printers
path = /var/spool/samba
printer admin = root
guest ok = Yes
printable = Yes
printing = cups
use client driver = Yes
browseable = No
</programlisting>
</para>
</sect2>
</sect1>
<sect1>
<title>Common Errors</title>
<para>
The greatest mistake so often made is to make a network configuration too complex.
It pays to use the simplest solution that will meet the needs of the moment.
</para>
</sect1>
</chapter>
|
