~zulcss/samba/server-dailies-3.4

« back to all changes in this revision

Viewing changes to docs/htmldocs/Samba3-ByExample/upgrades.html

  • Committer: Chuck Short
  • Date: 2010-09-28 20:38:39 UTC
  • Revision ID: zulcss@ubuntu.com-20100928203839-pgjulytsi9ue63x1
Initial version

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter�8.�Updating Samba-3</title><link rel="stylesheet" href="../samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"><link rel="home" href="index.html" title="Samba-3 by Example"><link rel="up" href="DMSMig.html" title="Part�II.�Domain Members, Updating Samba and Migration"><link rel="prev" href="unixclients.html" title="Chapter�7.�Adding Domain Member Servers and Clients"><link rel="next" href="ntmigration.html" title="Chapter�9.�Migrating NT4 Domain to Samba-3"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter�8.�Updating Samba-3</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="unixclients.html">Prev</a>�</td><th width="60%" align="center">Part�II.�Domain Members, Updating Samba and Migration</th><td width="20%" align="right">�<a accesskey="n" href="ntmigration.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="upgrades"></a>Chapter�8.�Updating Samba-3</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="upgrades.html#id2598100">Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="upgrades.html#id2598196">Cautions and Notes</a></span></dt></dl></dd><dt><span class="sect1"><a href="upgrades.html#id2599525">Upgrading from Samba 1.x and 2.x to Samba-3</a></span></dt><dd><dl><dt><span class="sect2"><a href="upgrades.html#sbeug2">Samba 1.9.x and 2.x Versions Without LDAP</a></span></dt><dt><span class="sect2"><a href="upgrades.html#id2599894">Applicable to All Samba 2.x to Samba-3 Upgrades</a></span></dt><dt><span class="sect2"><a href="upgrades.html#id2600227">Samba-2.x with LDAP Support</a></span></dt></dl></dd><dt><span class="sect1"><a href="upgrades.html#id2600409">Updating a Samba-3 Installation</a></span></dt><dd><dl><dt><span class="sect2"><a href="upgrades.html#id2600519">Samba-3 to Samba-3 Updates on the Same Server</a></span></dt><dt><span class="sect2"><a href="upgrades.html#id2600723">Migrating Samba-3 to a New Server</a></span></dt><dt><span class="sect2"><a href="upgrades.html#id2601137">Migration of Samba Accounts to Active Directory</a></span></dt></dl></dd></dl></div><p>
 
2
<a class="indexterm" name="id2598015"></a>
 
3
<a class="indexterm" name="id2598022"></a>
 
4
It was a little difficult to select an appropriate title for this chapter.
 
5
From email messages on the Samba mailing lists it is clear that many people
 
6
consider the updating and upgrading of Samba to be a migration matter. Others
 
7
talk about migrating Samba servers when in fact the issue at hand is one of
 
8
installing a new Samba server to replace an older existing Samba server.
 
9
</p><p>
 
10
<a class="indexterm" name="id2598039"></a>
 
11
<a class="indexterm" name="id2598045"></a>
 
12
There has also been much talk about migration of Samba-3 from an smbpasswd
 
13
passdb backend to the use of the tdbsam or ldapsam facilities that are new
 
14
to Samba-3.
 
15
</p><p>
 
16
Clearly, there is not a great deal of clarity in the terminology that various
 
17
people apply to these modes by which Samba servers are updated. This is further 
 
18
highlighted by an email posting that included the following neat remark:
 
19
</p><div class="blockquote"><blockquote class="blockquote"><p>
 
20
<a class="indexterm" name="id2598067"></a>
 
21
I like the &#8220;<span class="quote">net rpc vampire</span>&#8221; on NT4, but that to my surprise does
 
22
not seem to work against a Samba PDC and, if addressed in the Samba to Samba
 
23
context in either book, I could not find it.
 
24
</p></blockquote></div><p>
 
25
<a class="indexterm" name="id2598088"></a>
 
26
So in response to the significant request for these situations to be better 
 
27
documented, this chapter has now been added. User contributions and documentation
 
28
of real-world experiences are a most welcome addition to this chapter.
 
29
</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2598100"></a>Introduction</h2></div></div></div><p>
 
30
<a class="indexterm" name="id2598108"></a>
 
31
<a class="indexterm" name="id2598114"></a>
 
32
<a class="indexterm" name="id2598121"></a>
 
33
A Windows network administrator explained in an email what changes he was
 
34
planning to make and followed with the question: &#8220;<span class="quote">Anyone done this
 
35
before?</span>&#8221; Many of us have upgraded and updated Samba without incident.
 
36
Others have experienced much pain and user frustration. So it is to be hoped
 
37
that the notes in this chapter will make a positive difference by assuring
 
38
that someone will be saved a lot of discomfort.
 
39
</p><p>
 
40
Before anyone commences an upgrade or an update of Samba, the one cardinal
 
41
rule that must be observed is: Backup all Samba configuration files in
 
42
case it is necessary to revert to the old version. Even if you do not like
 
43
this precautionary step, users will punish an administrator who
 
44
fails to take adequate steps to avoid situations that may inflict lost
 
45
productivity on them.
 
46
</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>
 
47
<a class="indexterm" name="id2598152"></a>
 
48
<a class="indexterm" name="id2598159"></a>
 
49
Samba makes it possible to upgrade and update configuration files, but it
 
50
is not possible to downgrade the configuration files. Please ensure that
 
51
all configuration and control files are backed up to permit a down-grade
 
52
in the rare event that this may be necessary.
 
53
</p></div><p>
 
54
<a class="indexterm" name="id2598174"></a>
 
55
<a class="indexterm" name="id2598181"></a>
 
56
It is prudent also to backup all data files on the server before attempting
 
57
to perform a major upgrade. Many administrators have experienced the consequences
 
58
of failure to take adequate precautions. So what is adequate? That is simple!
 
59
If data is lost during an upgrade or update and it can not be restored,
 
60
the precautions taken were inadequate. If a backup was not needed, but was available,
 
61
caution was on the side of the victor.
 
62
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2598196"></a>Cautions and Notes</h3></div></div></div><p>
 
63
        Someone once said, &#8220;<span class="quote">It is good to be sorry, but better never to need to be!</span>&#8221;
 
64
        These are wise words of advice to those contemplating a Samba upgrade or update.
 
65
        </p><p>
 
66
        <a class="indexterm" name="id2598214"></a>
 
67
        <a class="indexterm" name="id2598220"></a>
 
68
        <a class="indexterm" name="id2598227"></a>
 
69
        This is as good a time as any to define the terms <code class="constant">upgrade</code> and
 
70
        <code class="constant">update</code>. The term <code class="constant">upgrade</code> refers to
 
71
        the installation of a version of Samba that is a whole generation or more ahead of
 
72
        that which is installed. Generations are indicated by the first digit of the version
 
73
        number. So far Samba has been released in generations 1.x, 2.x, 3.x, and currently 4.0
 
74
        is in development.
 
75
        </p><p>
 
76
        <a class="indexterm" name="id2598254"></a>
 
77
        The term <code class="constant">update</code> refers to a minor version number installation
 
78
        in place of one of the same generation. For example, updating from Samba 3.0.10 to 3.0.14
 
79
        is an update. The move from Samba 2.0.7 to 3.0.14 is an upgrade.
 
80
        </p><p>
 
81
        <a class="indexterm" name="id2598271"></a>
 
82
        While the use of these terms is an exercise in semantics, what needs to be realized
 
83
        is that there are major functional differences between a Samba 2.x release and a Samba
 
84
        3.0.x release. Such differences may require a significantly different approach to
 
85
        solving the same networking challenge and generally require careful review of the
 
86
        latest documentation to identify precisely how the new installation may need to be
 
87
        modified to preserve prior functionality.
 
88
        </p><p>
 
89
        There is an old axiom that says, &#8220;<span class="quote">The greater the volume of the documentation,
 
90
        the greater the risk that noone will read it, but where there is no documentation,
 
91
        noone can read it!</span>&#8221; While true, some documentation is an evil necessity.
 
92
        It is hoped that this update to the documentation will avoid both extremes.
 
93
        </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2598300"></a>Security Identifiers (SIDs)</h4></div></div></div><p>
 
94
        <a class="indexterm" name="id2598308"></a>
 
95
        <a class="indexterm" name="id2598317"></a>
 
96
        <a class="indexterm" name="id2598324"></a>
 
97
        <a class="indexterm" name="id2598331"></a>
 
98
        <a class="indexterm" name="id2598337"></a>
 
99
        <a class="indexterm" name="id2598346"></a>
 
100
        Before the days of Windows NT and OS/2, every Windows and DOS networking client
 
101
        that used the SMB protocols was an entirely autonomous entity. There was no concept
 
102
        of a security identifier for a machine or a user outside of the username, the
 
103
        machine name, and the workgroup name. In actual fact, these were not security identifiers
 
104
        in the same context as the way that the SID is used since the development of
 
105
        Windows NT 3.10.
 
106
        </p><p>
 
107
        <a class="indexterm" name="id2598366"></a>
 
108
        <a class="indexterm" name="id2598373"></a>
 
109
        <a class="indexterm" name="id2598380"></a>
 
110
        <a class="indexterm" name="id2598387"></a>
 
111
        <a class="indexterm" name="id2598393"></a>
 
112
        <a class="indexterm" name="id2598400"></a>
 
113
        Versions of Samba prior to 1.9 did not make use of a SID. Instead they make exclusive use
 
114
        of the username that is embedded in the SessionSetUpAndX component of the connection
 
115
        setup process between a Windows client and an SMB/CIFS server. 
 
116
        </p><p>
 
117
        <a class="indexterm" name="id2598417"></a>
 
118
        <a class="indexterm" name="id2598424"></a>
 
119
        <a class="indexterm" name="id2598430"></a>
 
120
        Around November 1997 support was added to Samba-1.9 to handle the Windows security
 
121
        RPC-based protocols that implemented support for Samba to store a machine SID. This
 
122
        information was stored in a file called <code class="filename">MACHINE.SID.</code>
 
123
        </p><p>
 
124
        <a class="indexterm" name="id2598450"></a>
 
125
        <a class="indexterm" name="id2598456"></a>
 
126
        <a class="indexterm" name="id2598463"></a>
 
127
        Within the lifetime of the early Samba 2.x series, the machine SID information was
 
128
        relocated into a tdb file called <code class="filename">secrets.tdb</code>, which is where
 
129
        it is still located in Samba 3.0.x along with other information that pertains to the
 
130
        local machine and its role within a domain security context.
 
131
        </p><p>
 
132
        <a class="indexterm" name="id2598484"></a>
 
133
        <a class="indexterm" name="id2598493"></a>
 
134
        <a class="indexterm" name="id2598502"></a>
 
135
        <a class="indexterm" name="id2598509"></a>
 
136
        There are two types of SID, those pertaining to the machine itself and the domain to
 
137
        which it may belong, and those pertaining to users and groups within the security
 
138
        context of the local machine, in the case of standalone servers (SAS) and domain member
 
139
        servers (DMS).
 
140
        </p><p>
 
141
        <a class="indexterm" name="id2598523"></a>
 
142
        <a class="indexterm" name="id2598530"></a>
 
143
        <a class="indexterm" name="id2598537"></a>
 
144
        <a class="indexterm" name="id2598544"></a>
 
145
        <a class="indexterm" name="id2598551"></a>
 
146
        <a class="indexterm" name="id2598557"></a>
 
147
        When the Samba <code class="literal">smbd</code> daemon is first started, if the <code class="filename">secrets.tdb</code>
 
148
        file does not exist, it is created at the first client connection attempt. If this file does
 
149
        exist, <code class="literal">smbd</code> checks that there is a machine SID (if it is a domain controller,
 
150
        it searches for the domain SID). If <code class="literal">smbd</code> does not find one for the current
 
151
        name of the machine or for the current name of the workgroup, a new SID will be generated and
 
152
        then written to the <code class="filename">secrets.tdb</code> file. The SID is generated in a nondeterminative
 
153
        manner. This means that each time it is generated for a particular combination of machine name
 
154
        (hostname) and domain name (workgroup), it will be different.
 
155
        </p><p>
 
156
        <a class="indexterm" name="id2598607"></a>
 
157
        The SID is the key used by MS Windows networking for all networking operations. This means
 
158
        that when the machine or domain SID changes, all security-encoded objects such as profiles
 
159
        and ACLs may become unusable.
 
160
        </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
 
161
        It is of paramount importance that the machine and domain SID be backed up so that in
 
162
        the event of a change of hostname (machine name) or domain name (workgroup) the SID can
 
163
        be restored to its previous value.
 
164
        </p></div><p>
 
165
        <a class="indexterm" name="id2598628"></a>
 
166
        <a class="indexterm" name="id2598635"></a>
 
167
        <a class="indexterm" name="id2598642"></a>
 
168
        <a class="indexterm" name="id2598648"></a>
 
169
        <a class="indexterm" name="id2598655"></a>
 
170
        <a class="indexterm" name="id2598662"></a>
 
171
        <a class="indexterm" name="id2598669"></a>
 
172
        <a class="indexterm" name="id2598676"></a>
 
173
        <a class="indexterm" name="id2598683"></a>
 
174
        <a class="indexterm" name="id2598689"></a>
 
175
        In Samba-3 on a domain controller (PDC or BDC), the domain name controls the domain
 
176
        SID. On all prior versions the hostname (computer name, or NetBIOS name) controlled
 
177
        the SID. On a standalone server the hostname still controls the SID.
 
178
        </p><p>
 
179
        <a class="indexterm" name="id2598703"></a>
 
180
        <a class="indexterm" name="id2598712"></a>
 
181
        The local machine SID can be backed up using this procedure (Samba-3):
 
182
</p><pre class="screen">
 
183
<code class="prompt">root# </code> net getlocalsid &gt; /etc/samba/my-local-SID
 
184
</pre><p>
 
185
        The contents of the file <code class="filename">/etc/samba/my-local-SID</code> will be:
 
186
</p><pre class="screen">
 
187
SID for domain FRODO is: S-1-5-21-726309263-4128913605-1168186429
 
188
</pre><p>
 
189
        This SID can be restored by executing:
 
190
</p><pre class="screen">
 
191
<code class="prompt">root# </code> net setlocalsid S-1-5-21-726309263-4128913605-1168186429
 
192
</pre><p>
 
193
        </p><p>
 
194
        Samba 1.9.x stored the machine SID in the the file <code class="filename">/etc/MACHINE.SID</code>
 
195
        from which it could be recovered and stored into the <code class="filename">secrets.tdb</code> file
 
196
        using the procedure shown above.
 
197
        </p><p>
 
198
        Where the <code class="filename">secrets.tdb</code> file exists and a version of Samba 2.x or later
 
199
        has been used, there is no specific need to go through this update process. Samba-3 has the
 
200
        ability to read the older tdb file and to perform an in-situ update to the latest tdb format.
 
201
        This is not a reversible process  it is a one-way upgrade.
 
202
        </p><p>
 
203
        <a class="indexterm" name="id2598801"></a>
 
204
        In the course of the Samba 2.0.x series the <code class="literal">smbpasswd</code> was modified to
 
205
        permit the domain SID to be captured to the <code class="filename">secrets.tdb</code> file by executing:
 
206
</p><pre class="screen">
 
207
<code class="prompt">root# </code> smbpasswd -S PDC -Uadministrator%password
 
208
</pre><p>
 
209
        </p><p>
 
210
        The release of the Samba 2.2.x series permitted the SID to be obtained by executing:
 
211
</p><pre class="screen">
 
212
<code class="prompt">root# </code> smbpasswd -S PDC -Uadministrator%password
 
213
</pre><p>
 
214
        from which the SID could be copied to a file and then written to the Samba-2.2.x
 
215
        <code class="filename">secrets.tdb</code> file by executing:
 
216
</p><pre class="screen">
 
217
<code class="prompt">root# </code> smbpasswd -W S-1-5-21-726309263-4128913605-1168186429
 
218
</pre><p>
 
219
        </p><p>
 
220
        <a class="indexterm" name="id2598874"></a>
 
221
        <a class="indexterm" name="id2598881"></a>
 
222
        Domain security information, which includes the domain SID, can be obtained from Samba-2.2.x
 
223
        systems by executing:
 
224
</p><pre class="screen">
 
225
<code class="prompt">root# </code> rpcclient hostname lsaquery -Uroot%password
 
226
</pre><p>
 
227
        This can also be done with Samba-3 by executing:
 
228
</p><pre class="screen">
 
229
<code class="prompt">root# </code> net rpc info -Uroot%password
 
230
Domain Name: MIDEARTH
 
231
Domain SID: S-1-5-21-726309263-4128913605-1168186429
 
232
Sequence number: 1113415916
 
233
Num users: 4237
 
234
Num domain groups: 86
 
235
Num local groups: 0
 
236
</pre><p>
 
237
        It is a very good practice to store this SID information in a safely kept file, just in
 
238
        case it is ever needed at a later date.
 
239
        </p><p>
 
240
        <a class="indexterm" name="id2598928"></a>
 
241
        <a class="indexterm" name="id2598935"></a>
 
242
        <a class="indexterm" name="id2598941"></a>
 
243
        Take note that the domain SID is used extensively in Samba. Where LDAP is used for the
 
244
        <em class="parameter"><code>passdb backend</code></em>, all user, group, and trust accounts are encoded
 
245
        with the domain SID. This means that if the domain SID changes for any reason, the entire
 
246
        Samba environment can become broken and require extensive corrective action if the 
 
247
        original SID cannot be restored. Fortunately, it can be recovered from a dump of the
 
248
        LDAP database. A dump of the LDAP directory database can be obtained by executing:
 
249
</p><pre class="screen">
 
250
<code class="prompt">root# </code> slapcat -v -l filename.ldif
 
251
</pre><p>
 
252
        </p><p>
 
253
        <a class="indexterm" name="id2598977"></a>
 
254
        <a class="indexterm" name="id2598984"></a>
 
255
        <a class="indexterm" name="id2598991"></a>
 
256
        When the domain SID has changed, roaming profiles cease to be functional. The recovery
 
257
        of roaming profiles necessitates resetting of the domain portion of the user SID
 
258
        that owns the profile. This is encoded in the <code class="filename">NTUser.DAT</code> and can be
 
259
        updated using the Samba <code class="literal">profiles</code> utility. Please be aware that not all
 
260
        Linux distributions of the Samba RPMs include this essential utility. Please do not
 
261
        complain to the Samba Team if this utility is missing; that issue that must be
 
262
        addressed to the creator of the RPM package. The Samba Team do their best to make
 
263
        available all the tools needed to manage a Samba-based Windows networking environment.
 
264
        </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2599028"></a>Change of hostname</h4></div></div></div><p>
 
265
        <a class="indexterm" name="id2599036"></a>
 
266
        <a class="indexterm" name="id2599045"></a>
 
267
        Samba uses two methods by which the primary NetBIOS machine name (also known as a computer
 
268
        name or the hostname) may be determined: If the <code class="filename">smb.conf</code> file contains a
 
269
        <em class="parameter"><code>netbios name</code></em> entry, its value will be used directly. In the absence
 
270
        of such an entry, the UNIX system hostname will be used.
 
271
        </p><p>
 
272
        Many sites have become victims of lost Samba functionality because the UNIX system
 
273
        hostname was changed for one reason or another. Such a change will cause a new machine
 
274
        SID to be generated. If this happens on a domain controller, it will also change the
 
275
        domain SID. These SIDs can be updated (restored) using the procedure outlined previously.
 
276
        </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
 
277
        Do NOT change the hostname or the <em class="parameter"><code>netbios name</code></em>. If this
 
278
        is changed, be sure to reset the machine SID to the original setting. Otherwise
 
279
        there may be serious interoperability and/or operational problems.
 
280
        </p></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2599094"></a>Change of Workgroup (Domain) Name</h4></div></div></div><p>
 
281
        <a class="indexterm" name="id2599102"></a>
 
282
        The domain name of a Samba server is identical to the workgroup name and is
 
283
        set in the <code class="filename">smb.conf</code> file using the <em class="parameter"><code>workgroup</code></em> parameter.
 
284
        This has been consistent throughout the history of Samba and across all versions.
 
285
        </p><p>
 
286
        <a class="indexterm" name="id2599127"></a>
 
287
        Be aware that when the workgroup name is changed, a new SID will be generated.
 
288
        The old domain SID can be reset using the procedure outlined earlier in this chapter.
 
289
        </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="sbeug1"></a>Location of config files</h4></div></div></div><p>
 
290
        The Samba-Team has maintained a constant default location for all Samba control files
 
291
        throughout the life of the project. People who have produced binary packages of Samba
 
292
        have varied the location of the Samba control files. This has led to some confusion
 
293
        for network administrators.
 
294
        </p><p>
 
295
        <a class="indexterm" name="id2599158"></a>
 
296
        The Samba 1.9.x <code class="filename">smb.conf</code> file may be found either in the <code class="filename">/etc</code>
 
297
        directory or in <code class="filename">/usr/local/samba/lib</code>.
 
298
        </p><p>
 
299
        During the life of the Samba 2.x release, the <code class="filename">smb.conf</code> file was relocated
 
300
        on Linux systems to the <code class="filename">/etc/samba</code> directory where it
 
301
        remains located also for Samba 3.0.x installations.
 
302
        </p><p>
 
303
        <a class="indexterm" name="id2599205"></a>
 
304
        Samba 2.x introduced the <code class="filename">secrets.tdb</code> file that is also stored in the
 
305
        <code class="filename">/etc/samba</code> directory, or in the <code class="filename">/usr/local/samba/lib</code>
 
306
        directory subsystem.
 
307
        </p><p>
 
308
        <a class="indexterm" name="id2599234"></a>
 
309
        The location at which <code class="literal">smbd</code> expects to find all configuration and control
 
310
        files is determined at the time of compilation of Samba. For versions of Samba prior to
 
311
        3.0, one way to find the expected location of these files is to execute:
 
312
</p><pre class="screen">
 
313
<code class="prompt">root# </code> strings /usr/sbin/smbd | grep conf
 
314
<code class="prompt">root# </code> strings /usr/sbin/smbd | grep secret
 
315
<code class="prompt">root# </code> strings /usr/sbin/smbd | grep smbpasswd
 
316
</pre><p>
 
317
        Note: The <code class="literal">smbd</code> executable may be located in the path
 
318
        <code class="filename">/usr/local/samba/sbin</code>.
 
319
        </p><p>
 
320
        <a class="indexterm" name="id2599292"></a>
 
321
        Samba-3 provides a neat new way to track the location of all control files as well as to
 
322
        find the compile-time options used as the Samba package was built. Here  is how the dark
 
323
        secrets of the internals of the location of control files within Samba executables can
 
324
        be uncovered:
 
325
</p><pre class="screen">
 
326
<code class="prompt">root# </code> smbd -b | less
 
327
Build environment:
 
328
   Built by:    root@frodo
 
329
   Built on:    Mon Apr 11 20:23:27 MDT 2005
 
330
   Built using: gcc
 
331
   Build host:  Linux frodo 2.6...
 
332
   SRCDIR:      /usr/src/packages/BUILD/samba-3.0.20/source
 
333
   BUILDDIR:    /usr/src/packages/BUILD/samba-3.0.20/source
 
334
 
 
335
Paths:
 
336
   SBINDIR: /usr/sbin
 
337
   BINDIR: /usr/bin
 
338
   SWATDIR: /usr/share/samba/swat
 
339
   CONFIGFILE: /etc/samba/smb.conf
 
340
   LOGFILEBASE: /var/log/samba
 
341
   LMHOSTSFILE: /etc/samba/lmhosts
 
342
   LIBDIR: /usr/lib/samba
 
343
   SHLIBEXT: so
 
344
   LOCKDIR: /var/lib/samba
 
345
   PIDDIR: /var/run/samba
 
346
   SMB_PASSWD_FILE: /etc/samba/smbpasswd
 
347
   PRIVATE_DIR: /etc/samba
 
348
 ... 
 
349
</pre><p>
 
350
        </p><p>
 
351
        <a class="indexterm" name="id2599330"></a>
 
352
        It is important that both the <code class="filename">smb.conf</code> file and the <code class="filename">secrets.tdb</code>
 
353
        be backed up before attempting any upgrade. The <code class="filename">secrets.tdb</code> file
 
354
        is version-encoded, and therefore a newer version may not work with an older version
 
355
        of Samba. A backup means that it is always possible to revert a failed or problematic
 
356
        upgrade.
 
357
        </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2599360"></a>International Language Support</h4></div></div></div><p>
 
358
        <a class="indexterm" name="id2599368"></a>
 
359
        <a class="indexterm" name="id2599375"></a>
 
360
        <a class="indexterm" name="id2599382"></a>
 
361
        <a class="indexterm" name="id2599388"></a>
 
362
        Samba-2.x had no support for Unicode; instead, all national language character-set support in file names
 
363
        was done using particular locale codepage mapping techniques. Samba-3 supports Unicode in file names, thus
 
364
        providing true internationalization support.
 
365
        </p><p>
 
366
        <a class="indexterm" name="id2599403"></a>
 
367
        Non-English users whose national language character set has special characters and who upgrade naively will 
 
368
        find that many files that have the special characters in the file name will see them garbled and jumbled up.
 
369
        This typically happens with umlauts and accents because these characters were particular to the codepage
 
370
        that was in use with Samba-2.x using an 8-bit encoding scheme.
 
371
        </p><p>
 
372
        <a class="indexterm" name="id2599420"></a>
 
373
        Files that are created with Samba-3 will use UTF-8 encoding. Should the file system ever end up with a
 
374
        mix of codepage (unix charset)-encoded file names and UTF-8-encoded file names, the mess will take some
 
375
        effort to set straight.
 
376
        </p><p>
 
377
        <a class="indexterm" name="id2599434"></a>
 
378
        A very helpful tool is available from Bjorn Jacke's <a class="ulink" href="http://j3e.de/linux/convmv/" target="_top">convmv</a>
 
379
        work. Convmv is a tool that can be used to convert file and directory names from one encoding method to
 
380
        another. The most common use for this tool is to convert locale-encoded files to UTF-8 Unicode encoding.
 
381
        </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2599454"></a>Updates and Changes in Idealx smbldap-tools</h4></div></div></div><p>
 
382
        The smbldap-tools have been maturing rapidly over the past year. With maturation comes change.
 
383
        The location of the <code class="filename">smbldap.conf</code> and the <code class="filename">smbldap_bind.conf</code>
 
384
        configuration files have been moved from the directory <code class="filename">/etc/smbldap-tools</code> to
 
385
        the new location of <code class="filename">/etc/opt/IDEALX/smblda-tools</code> directory.
 
386
        </p><p>
 
387
        The smbldap-tools maintains an entry in the LDAP directory in which it stores the next
 
388
        values that should be used for UID and GID allocation for POSIX accounts that are created
 
389
        using this tool. The DIT location of these values has changed recently. The original
 
390
        <code class="constant">sambaUnixIdPooldn object</code> entity was stored in a directory entry (DIT object)
 
391
        called <code class="constant">NextFreeUnixId</code>, this has been changed to the DIT object
 
392
        <code class="constant">sambaDomainName</code>. Anyone who updates from an older version to the
 
393
        current release should note that the information stored under <code class="constant">NextFreeUnixId</code>
 
394
        must now be relocated to the DIT object <code class="constant">sambaDomainName</code>.
 
395
        </p></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2599525"></a>Upgrading from Samba 1.x and 2.x to Samba-3</h2></div></div></div><p>
 
396
Sites that are being upgraded from Samba-2 (or earlier versions) to Samba-3
 
397
may experience little difficulty or may require a lot of effort, depending
 
398
on the complexity of the configuration. Samba-1.9.x upgrades to Samba-3 will
 
399
generally be simple and straightforward, although no upgrade should be
 
400
attempted without proper planning and preparation.
 
401
</p><p>
 
402
There are two basic modes of use of Samba versions prior to Samba-3. The first
 
403
does not use LDAP, the other does. Samba-1.9.x did not provide LDAP support.
 
404
Samba-2.x could be compiled with LDAP support.
 
405
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="sbeug2"></a>Samba 1.9.x and 2.x Versions Without LDAP</h3></div></div></div><p>
 
406
        Where it is necessary to upgrade an old Samba installation to Samba-3,
 
407
        the following procedure can be followed:
 
408
        </p><div class="procedure"><a name="id2599563"></a><p class="title"><b>Procedure�8.1.�Upgrading from a Pre-Samba-3 Version</b></p><ol type="1"><li><p>
 
409
                <a class="indexterm" name="id2599574"></a>
 
410
                <a class="indexterm" name="id2599581"></a>
 
411
                <a class="indexterm" name="id2599588"></a>
 
412
                Stop Samba. This can be done using the appropriate system tool
 
413
                that is particular for each operating system or by executing the
 
414
                <code class="literal">kill</code> command on <code class="literal">smbd</code>,
 
415
                <code class="literal">nmbd</code>, and <code class="literal">winbindd</code>.
 
416
                </p></li><li><p>
 
417
                Find the location of the Samba <code class="filename">smb.conf</code> file and back it up to a
 
418
                safe location.
 
419
                </p></li><li><p>
 
420
                Find the location of the <code class="filename">smbpasswd</code> file and
 
421
                back it up to a safe location.
 
422
                </p></li><li><p>
 
423
                Find the location of the <code class="filename">secrets.tdb</code> file and
 
424
                back it up to a safe location.
 
425
                </p></li><li><p>
 
426
                <a class="indexterm" name="id2599669"></a>
 
427
                <a class="indexterm" name="id2599676"></a>
 
428
                <a class="indexterm" name="id2599683"></a>
 
429
                <a class="indexterm" name="id2599690"></a>
 
430
                Find the location of the lock directory. This is the directory
 
431
                in which Samba stores all its tdb control files. The default
 
432
                location used by the Samba Team is in
 
433
                <code class="filename">/usr/local/samba/var/locks</code> directory,
 
434
                but on Linux systems the old location was under the
 
435
                <code class="filename">/var/cache/samba</code> directory. However, the
 
436
                Linux Standards Base specified location is now under the
 
437
                <code class="filename">/var/lib/samba</code> directory. Copy all the
 
438
                tdb files to a safe location.
 
439
                </p></li><li><p>
 
440
                <a class="indexterm" name="id2599728"></a>
 
441
                It is now safe to upgrade the Samba installation. On Linux systems
 
442
                it is not necessary to remove the Samba RPMs because a simple
 
443
                upgrade installation will automatically remove the old files.
 
444
                </p><p>
 
445
                On systems that do not support a reliable package management system
 
446
                it is advisable either to delete the Samba old installation or to
 
447
                move it out of the way by renaming the directories that contain the
 
448
                Samba binary files.
 
449
                </p></li><li><p>
 
450
                When the Samba upgrade has been installed, the first step that should
 
451
                be completed is to identify the new target locations for the control
 
452
                files. Follow the steps shown in <a class="link" href="upgrades.html#sbeug1" title="Location of config files">&#8220;Location of config files&#8221;</a> to locate
 
453
                the correct directories to which each control file must be moved.
 
454
                </p></li><li><p>
 
455
                Do not change the hostname.
 
456
                </p></li><li><p>
 
457
                Do not change the workgroup name.
 
458
                </p></li><li><p>
 
459
                <a class="indexterm" name="id2599784"></a>
 
460
                Execute the <code class="literal">testparm</code> to validate the <code class="filename">smb.conf</code> file.
 
461
                This process will flag any parameters that are no longer supported.
 
462
                It will also flag configuration settings that may be in conflict.
 
463
                </p><p>
 
464
                One solution that may be used to clean up and to update the <code class="filename">smb.conf</code>
 
465
                file involves renaming it to <code class="filename">smb.conf.master</code> and 
 
466
                then executing the following:
 
467
</p><pre class="screen">
 
468
<code class="prompt">root# </code> cd /etc/samba
 
469
<code class="prompt">root# </code> testparm -s smb.conf.master &gt; smb.conf
 
470
</pre><p>
 
471
        <a class="indexterm" name="id2599841"></a>
 
472
                The resulting <code class="filename">smb.conf</code> file will be stripped of all comments
 
473
                and of all nonconforming configuration settings.
 
474
                </p></li><li><p>
 
475
                <a class="indexterm" name="id2599863"></a>
 
476
                It is now safe to start Samba using the appropriate system tool.
 
477
                Alternately, it is possible to just execute <code class="literal">nmbd</code>,
 
478
                <code class="literal">smbd</code>, and <code class="literal">winbindd</code> for the command
 
479
                line while logged in as the root user.
 
480
                </p></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2599894"></a>Applicable to All Samba 2.x to Samba-3 Upgrades</h3></div></div></div><p>
 
481
        <a class="indexterm" name="id2599902"></a>
 
482
        <a class="indexterm" name="id2599908"></a>
 
483
        <a class="indexterm" name="id2599915"></a>
 
484
        Samba 2.x servers that were running as a domain controller (PDC)
 
485
        require changes to the configuration of the scripting interface
 
486
        tools that Samba uses to perform OS updates for
 
487
        users, groups, and trust accounts (machines and interdomain).
 
488
        </p><p>
 
489
        <a class="indexterm" name="id2599930"></a>
 
490
        The following parameters are new to Samba-3 and should be correctly configured.
 
491
        Please refer to <a class="link" href="secure.html" title="Chapter�3.�Secure Office Networking">&#8220;Secure Office Networking&#8221;</a> through <a class="link" href="2000users.html" title="Chapter�6.�A Distributed 2000-User Network">&#8220;A Distributed 2000-User Network&#8221;</a>
 
492
        in this book for examples of use of the new parameters shown here:
 
493
        <a class="indexterm" name="id2599951"></a>
 
494
        <a class="indexterm" name="id2599958"></a>
 
495
        <a class="indexterm" name="id2599964"></a>
 
496
        <a class="indexterm" name="id2599972"></a>
 
497
        <a class="indexterm" name="id2599978"></a>
 
498
        <a class="indexterm" name="id2599986"></a>
 
499
        <a class="indexterm" name="id2599993"></a>
 
500
        </p><p>
 
501
        </p><table class="simplelist" border="0" summary="Simple list"><tr><td><p>add group script</p></td></tr><tr><td><p>add machine script</p></td></tr><tr><td><p>add user to group script</p></td></tr><tr><td><p>delete group script</p></td></tr><tr><td><p>delete user from group script</p></td></tr><tr><td><p>passdb backend</p></td></tr><tr><td><p>set primary group script</p></td></tr></table><p>
 
502
        </p><p>
 
503
        <a class="indexterm" name="id2600045"></a>
 
504
        <a class="indexterm" name="id2600052"></a>
 
505
        The <em class="parameter"><code>add machine script</code></em> functionality was previously
 
506
        handled by the <em class="parameter"><code>add user script</code></em>, which in Samba-3 is
 
507
        used exclusively to add user accounts.
 
508
        </p><p>
 
509
        <a class="indexterm" name="id2600076"></a>
 
510
        <a class="indexterm" name="id2600083"></a>
 
511
        <a class="indexterm" name="id2600090"></a>
 
512
        <a class="indexterm" name="id2600096"></a>
 
513
        <a class="indexterm" name="id2600103"></a>
 
514
        <a class="indexterm" name="id2600110"></a>
 
515
        <a class="indexterm" name="id2600117"></a>
 
516
        <a class="indexterm" name="id2600124"></a>
 
517
        <a class="indexterm" name="id2600130"></a>
 
518
        Where the <em class="parameter"><code>passdb backend</code></em> used is either <code class="constant">smbpasswd</code>
 
519
        (the default) or the new <code class="constant">tdbsam</code>, the system interface scripts
 
520
        are typically used. These involve use of OS tools such as <code class="literal">useradd</code>,
 
521
        <code class="literal">usermod</code>, <code class="literal">userdel</code>, <code class="literal">groupadd</code>,
 
522
        <code class="literal">groupmod</code>, <code class="literal">groupdel</code>, and so on.
 
523
        </p><p>
 
524
        <a class="indexterm" name="id2600191"></a>
 
525
        <a class="indexterm" name="id2600198"></a>
 
526
        <a class="indexterm" name="id2600205"></a>
 
527
        Where the <em class="parameter"><code>passdb backend</code></em> makes use of an LDAP directory,
 
528
        it is necessary either to use the <code class="constant">smbldap-tools</code> provided
 
529
        by Idealx or to use an alternate toolset provided by a third
 
530
        party or else home-crafted to manage the LDAP directory accounts.
 
531
        </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2600227"></a>Samba-2.x with LDAP Support</h3></div></div></div><p>
 
532
        Samba version 2.x could be compiled for use either with or without LDAP.
 
533
        The LDAP control settings in the <code class="filename">smb.conf</code> file in this old version are
 
534
        completely different (and less complete) than they are with Samba-3. This
 
535
        means that after migrating the control files, it is necessary to reconfigure
 
536
        the LDAP settings entirely.
 
537
        </p><p>
 
538
        Follow the procedure outlined in <a class="link" href="upgrades.html#sbeug2" title="Samba 1.9.x and 2.x Versions Without LDAP">&#8220;Samba 1.9.x and 2.x Versions Without LDAP&#8221;</a> to affect a migration
 
539
        of all files to the correct locations.
 
540
        </p><p>
 
541
        <a class="indexterm" name="id2600262"></a>
 
542
        <a class="indexterm" name="id2600268"></a>
 
543
        The Samba SAM schema required for Samba-3 is significantly different from that
 
544
        used with Samba 2.x. This means that the LDAP directory must be updated
 
545
        using the procedure outlined in the Samba WHATSNEW.txt file that accompanies
 
546
        all releases of Samba-3. This information is repeated here directly from this
 
547
        file:
 
548
</p><pre class="screen">
 
549
This is an extract from the Samba-3.0.x WHATSNEW.txt file:
 
550
==========================================================
 
551
Changes in Behavior
 
552
-------------------
 
553
 
 
554
The following issues are known changes in behavior between Samba 2.2 and
 
555
Samba 3.0 that may affect certain installations of Samba.
 
556
 
 
557
  1)  When operating as a member of a Windows domain, Samba 2.2 would
 
558
      map any users authenticated by the remote DC to the 'guest account'
 
559
      if a uid could not be obtained via the getpwnam() call.  Samba 3.0
 
560
      rejects the connection as NT_STATUS_LOGON_FAILURE.  There is no
 
561
      current work around to re-establish the 2.2 behavior.
 
562
 
 
563
  2)  When adding machines to a Samba 2.2 controlled domain, the
 
564
      'add user script' was used to create the UNIX identity of the
 
565
      machine trust account.  Samba 3.0 introduces a new 'add machine
 
566
      script' that must be specified for this purpose.  Samba 3.0 will
 
567
      not fall back to using the 'add user script' in the absence of
 
568
      an 'add machine script'
 
569
 
 
570
######################################################################
 
571
Passdb Backends and Authentication
 
572
##################################
 
573
 
 
574
There have been a few new changes that Samba administrators should be
 
575
aware of when moving to Samba 3.0.
 
576
 
 
577
  1) encrypted passwords have been enabled by default in order to
 
578
     inter-operate better with out-of-the-box Windows client
 
579
     installations.  This does mean that either (a) a samba account
 
580
     must be created for each user, or (b) 'encrypt passwords = no'
 
581
     must be explicitly defined in smb.conf.
 
582
 
 
583
  2) Inclusion of new 'security = ads' option for integration
 
584
     with an Active Directory domain using the native Windows
 
585
     Kerberos 5 and LDAP protocols.
 
586
 
 
587
     MIT kerberos 1.3.1 supports the ARCFOUR-HMAC-MD5 encryption
 
588
     type which is necessary for servers on which the
 
589
     administrator password has not been changed, or kerberos-enabled
 
590
     SMB connections to servers that require Kerberos SMB signing.
 
591
     Besides this one difference, either MIT or Heimdal Kerberos
 
592
     distributions are usable by Samba 3.0.
 
593
 
 
594
 
 
595
Samba 3.0 also includes the possibility of setting up chains
 
596
of authentication methods (auth methods) and account storage
 
597
backends (passdb backend).  Please refer to the smb.conf(5)
 
598
man page for details.  While both parameters assume sane default
 
599
values, it is likely that you will need to understand what the
 
600
values actually mean in order to ensure Samba operates correctly.
 
601
 
 
602
The recommended passdb backends at this time are
 
603
 
 
604
  * smbpasswd - 2.2 compatible flat file format
 
605
  * tdbsam - attribute rich database intended as an smbpasswd
 
606
    replacement for stand alone servers
 
607
  * ldapsam - attribute rich account storage and retrieval
 
608
    backend utilizing an LDAP directory.
 
609
  * ldapsam_compat - a 2.2 backward compatible LDAP account
 
610
    backend
 
611
 
 
612
Certain functions of the smbpasswd(8) tool have been split between the
 
613
new smbpasswd(8) utility, the net(8) tool, and the new pdbedit(8)
 
614
utility.  See the respective man pages for details.
 
615
 
 
616
######################################################################
 
617
LDAP
 
618
####
 
619
 
 
620
This section outlines the new features affecting Samba / LDAP
 
621
integration.
 
622
 
 
623
New Schema
 
624
----------
 
625
 
 
626
A new object class (sambaSamAccount) has been introduced to replace
 
627
the old sambaAccount.  This change aids us in the renaming of
 
628
attributes to prevent clashes with attributes from other vendors.
 
629
There is a conversion script (examples/LDAP/convertSambaAccount) to
 
630
modify and LDIF file to the new schema.
 
631
 
 
632
Example:
 
633
 
 
634
  $ ldapsearch .... -b "ou=people,dc=..." &gt; sambaAcct.ldif
 
635
  $ convertSambaAccount --sid=&lt;Domain SID&gt; \
 
636
    --input=sambaAcct.ldif --output=sambaSamAcct.ldif \
 
637
    --changetype=[modify|add]
 
638
 
 
639
The &lt;DOM SID&gt; can be obtained by running 'net getlocalsid
 
640
&lt;DOMAINNAME&gt;' on the Samba PDC as root.  The changetype determines
 
641
the format of the generated LDIF output--either create new entries
 
642
or modify existing entries.
 
643
 
 
644
The old sambaAccount schema may still be used by specifying the
 
645
"ldapsam_compat" passdb backend.  However, the sambaAccount and
 
646
associated attributes have been moved to the historical section of
 
647
the schema file and must be uncommented before use if needed.
 
648
The 2.2 object class declaration for a sambaAccount has not changed
 
649
in the 3.0 samba.schema file.
 
650
 
 
651
Other new object classes and their uses include:
 
652
 
 
653
  * sambaDomain - domain information used to allocate rids
 
654
    for users and groups as necessary.  The attributes are added
 
655
    in 'ldap suffix' directory entry automatically if
 
656
    an idmap uid/gid range has been set and the 'ldapsam'
 
657
    passdb backend has been selected.
 
658
 
 
659
  * sambaGroupMapping - an object representing the
 
660
    relationship between a posixGroup and a Windows
 
661
    group/SID.  These entries are stored in the 'ldap
 
662
    group suffix' and managed by the 'net groupmap' command.
 
663
 
 
664
  * sambaUnixIdPool - created in the 'ldap idmap suffix' entry
 
665
    automatically and contains the next available 'idmap uid' and
 
666
    'idmap gid'
 
667
 
 
668
  * sambaIdmapEntry - object storing a mapping between a
 
669
    SID and a UNIX uid/gid.  These objects are created by the
 
670
    idmap_ldap module as needed.
 
671
 
 
672
  * sambaSidEntry - object representing a SID alone, as a Structural
 
673
    class on which to build the sambaIdmapEntry.
 
674
 
 
675
 
 
676
New Suffix for Searching
 
677
------------------------
 
678
 
 
679
The following new smb.conf parameters have been added to aid in directing
 
680
certain LDAP queries when 'passdb backend = ldapsam://...' has been
 
681
specified.
 
682
 
 
683
  * ldap suffix         - used to search for user and computer accounts
 
684
  * ldap user suffix    - used to store user accounts
 
685
  * ldap machine suffix - used to store machine trust accounts
 
686
  * ldap group suffix   - location of posixGroup/sambaGroupMapping entries
 
687
  * ldap idmap suffix   - location of sambaIdmapEntry objects
 
688
 
 
689
If an 'ldap suffix' is defined, it will be appended to all of the
 
690
remaining sub-suffix parameters.  In this case, the order of the suffix
 
691
listings in smb.conf is important.  Always place the 'ldap suffix' first
 
692
in the list.
 
693
 
 
694
Due to a limitation in Samba's smb.conf parsing, you should not surround
 
695
the DN's with quotation marks.
 
696
</pre><p>
 
697
        </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2600409"></a>Updating a Samba-3 Installation</h2></div></div></div><p>
 
698
The key concern in this section is to deal with the changes that have been
 
699
affected in Samba-3 between the Samba-3.0.0 release and the current update.
 
700
Network administrators have expressed concerns over the steps that should be
 
701
taken to update Samba-3 versions.
 
702
</p><p>
 
703
<a class="indexterm" name="id2600425"></a>
 
704
The information in <a class="link" href="upgrades.html#sbeug1" title="Location of config files">&#8220;Location of config files&#8221;</a> would not be necessary if every
 
705
person who has ever produced Samba executable (binary) files could agree on
 
706
the preferred location of the <code class="filename">smb.conf</code> file and other Samba control files.
 
707
Clearly, such agreement is further away than a pipedream.
 
708
</p><p>
 
709
<a class="indexterm" name="id2600451"></a>
 
710
Vendors and packagers who produce Samba binary installable packages do not,
 
711
as a rule, use the default paths used by the Samba-Team for the location of
 
712
the binary files, the <code class="filename">smb.conf</code> file, and the Samba control files (tdb's
 
713
as well as files such as <code class="filename">secrets.tdb</code>). This means that
 
714
the network or UNIX administrator who sets out to build the Samba executable
 
715
files from the Samba tarball must take particular care. Failure to take care
 
716
will result in both the original vendor's version of Samba remaining installed
 
717
and the new version being installed in the default location used
 
718
by the Samba-Team. This can lead to confusion and to much lost time as the
 
719
uninformed administrator deals with apparent failure of the update to take
 
720
effect.
 
721
</p><p>
 
722
<a class="indexterm" name="id2600484"></a>
 
723
The best advice for those lacking in code compilation experience is to use
 
724
only vendor (or Samba-Team) provided binary packages. The Samba packages
 
725
that are provided by the Samba-Team are generally built to use file paths
 
726
that are compatible with the original OS vendor's practices.
 
727
</p><p>
 
728
<a class="indexterm" name="id2600499"></a>
 
729
<a class="indexterm" name="id2600506"></a>
 
730
If you are not sure whether a binary package complies with the OS
 
731
vendor's practices, it is better to ask the package maintainer via
 
732
email than to waste much time dealing with the nuances.
 
733
Alternately, just diagnose the paths specified by the binary files following
 
734
the procedure outlined above.
 
735
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2600519"></a>Samba-3 to Samba-3 Updates on the Same Server</h3></div></div></div><p>
 
736
        The guidance in this section deals with updates to an existing
 
737
        Samba-3 server installation.
 
738
        </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2600530"></a>Updating from Samba Versions Earlier than 3.0.5</h4></div></div></div><p>
 
739
        With the provision that the binary Samba-3 package has been built
 
740
        with the same path and feature settings as the existing Samba-3
 
741
        package that is being updated, an update of Samba-3 versions 3.0.0
 
742
        through 3.0.4 can be updated to 3.0.5 without loss of functionality
 
743
        and without need to change either the <code class="filename">smb.conf</code> file or, where
 
744
        used, the LDAP schema.
 
745
        </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2600553"></a>Updating from Samba Versions between 3.0.6 and 3.0.10</h4></div></div></div><p>
 
746
        <a class="indexterm" name="id2600561"></a>
 
747
        <a class="indexterm" name="id2600568"></a>
 
748
        When updating versions of Samba-3 prior to 3.0.6 to 3.0.6 through 3.0.10,
 
749
        it is necessary only to update the LDAP schema (where LDAP is used).
 
750
        Always use the LDAP schema file that is shipped with the latest Samba-3
 
751
        update.
 
752
        </p><p>
 
753
        <a class="indexterm" name="id2600585"></a>
 
754
        <a class="indexterm" name="id2600591"></a>
 
755
        <a class="indexterm" name="id2600598"></a>
 
756
        Samba-3.0.6 introduced the ability to remember the last <span class="emphasis"><em>n</em></span> number
 
757
        of passwords a user has used. This information will work only with
 
758
        the <code class="constant">tdbsam</code> and <code class="constant">ldapsam</code>
 
759
        <em class="parameter"><code>passdb backend</code></em> facilities.
 
760
        </p><p>
 
761
        After updating the LDAP schema, do not forget to re-index the LDAP database.
 
762
        </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2600632"></a>Updating from Samba Versions after 3.0.6 to a Current Release</h4></div></div></div><p>
 
763
        <a class="indexterm" name="id2600640"></a>
 
764
        Samba-3.0.8 introduced changes in how the <em class="parameter"><code>username map</code></em>
 
765
        behaves. It also included a change in behavior of <code class="literal">winbindd</code>.
 
766
        Please refer to the man page for <code class="filename">smb.conf</code> before implementing any update
 
767
        from versions prior to 3.0.8 to a current version.
 
768
        </p><p>
 
769
        <a class="indexterm" name="id2600672"></a>
 
770
        In Samba-3.0.11 a new privileges interface was implemented. Please
 
771
        refer to <a class="link" href="happy.html#sbehap-ppc" title="Addition of Machines to the Domain">&#8220;Addition of Machines to the Domain&#8221;</a> for information regarding this new
 
772
        feature. It is not necessary to implement the privileges interface, but it
 
773
        is one that has been requested for several years and thus may be of interest
 
774
        at your site.
 
775
        </p><p>
 
776
        In Samba-3.0.11 there were some functional changes to the <em class="parameter"><code>ldap user
 
777
        suffix</code></em> and to the <em class="parameter"><code>ldap machine suffix</code></em> behaviors.
 
778
        The following information has been extracted from the WHATSNEW.txt file from this
 
779
        release:
 
780
</p><pre class="screen">
 
781
============
 
782
LDAP Changes
 
783
============
 
784
 
 
785
If "ldap user suffix" or "ldap machine suffix" are defined in
 
786
smb.conf, all user-accounts must reside below the user suffix,
 
787
and all machine and inter-domain trust-accounts must be located
 
788
below the machine suffix.  Previous Samba releases would fall
 
789
back to searching the 'ldap suffix' in some cases.
 
790
</pre><p>
 
791
        </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2600723"></a>Migrating Samba-3 to a New Server</h3></div></div></div><p>
 
792
        The two most likely candidates for replacement of a server are
 
793
        domain member servers and domain controllers. Each needs to be
 
794
        handled slightly differently.
 
795
        </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2600735"></a>Replacing a Domain Member Server</h4></div></div></div><p>
 
796
        <a class="indexterm" name="id2600743"></a>
 
797
        Replacement of a domain member server should be done
 
798
        using the same procedure as outlined in <a class="link" href="unixclients.html" title="Chapter�7.�Adding Domain Member Servers and Clients">&#8220;Adding Domain Member Servers and Clients&#8221;</a>.
 
799
        </p><p>
 
800
        Usually the new server will be introduced with a temporary name. After
 
801
        the old server data has been migrated to the new server, it is customary
 
802
        that the new server be renamed to that of the old server. This will
 
803
        change its SID and will necessitate rejoining to the domain.
 
804
        </p><p>
 
805
        <a class="indexterm" name="id2600768"></a>
 
806
        <a class="indexterm" name="id2600775"></a>
 
807
        <a class="indexterm" name="id2600782"></a>
 
808
        <a class="indexterm" name="id2600789"></a>
 
809
        <a class="indexterm" name="id2600795"></a>
 
810
        <a class="indexterm" name="id2600802"></a>
 
811
        Following a change of hostname (NetBIOS name) it is a good idea on all servers
 
812
        to shut down the Samba <code class="literal">smbd</code>, <code class="literal">nmbd</code>, and
 
813
        <code class="literal">winbindd</code> services, delete the <code class="filename">wins.dat</code>
 
814
        and <code class="filename">browse.dat</code> files, then restart Samba. This will ensure
 
815
        that the old name and IP address information is no longer able to interfere with
 
816
        name to IP address resolution.  If this is not done, there can be temporary name
 
817
        resolution problems. These problems usually clear within 45 minutes of a name
 
818
        change, but can persist for a longer period of time.
 
819
        </p><p>
 
820
        <a class="indexterm" name="id2600850"></a>
 
821
        <a class="indexterm" name="id2600856"></a>
 
822
        <a class="indexterm" name="id2600863"></a>
 
823
        <a class="indexterm" name="id2600870"></a>
 
824
        If the old domain member server had local accounts, it is necessary to create
 
825
        on the new domain member server the same accounts with the same UID and GID
 
826
        for each account. Where the <em class="parameter"><code>passdb backend</code></em> database
 
827
        is stored in the <code class="constant">smbpasswd</code> or in the
 
828
        <code class="constant">tdbsam</code> format, the user and group account information
 
829
        for UNIX accounts that match the Samba accounts will reside in the system
 
830
        <code class="filename">/etc/passwd</code>, <code class="filename">/etc/shadow</code>, and
 
831
        <code class="filename">/etc/group</code> files. In this case, be sure to copy these
 
832
        account entries to the new target server.
 
833
        </p><p>
 
834
        <a class="indexterm" name="id2600918"></a>
 
835
        Where the user accounts for both UNIX and Samba are stored in LDAP, the new
 
836
        target server must be configured to use the <code class="literal">nss_ldap</code> tool set.
 
837
        This will automatically ensure that the appropriate user entities are
 
838
        available on the new server.
 
839
        </p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2600937"></a>Replacing a Domain Controller</h4></div></div></div><p>
 
840
        <a class="indexterm" name="id2600945"></a>
 
841
        In the past, people who replaced a Windows NT4 domain controller typically
 
842
        installed a new server, created printers and file shares on it, then migrate across
 
843
        all data that was destined to reside on it. The same can of course be done with
 
844
        Samba.
 
845
        </p><p>
 
846
        From recent mailing list postings it would seem that some administrators
 
847
        have the intent to just replace the old Samba server with a new one with
 
848
        the same name as the old one. In this case, simply follow the same process
 
849
        as for upgrading a Samba 2.x system and do the following:
 
850
        </p><div class="itemizedlist"><ul type="disc"><li><p>
 
851
                Where UNIX (POSIX) user and group accounts are stored in the system
 
852
                <code class="filename">/etc/passwd</code>, <code class="filename">/etc/shadow</code>, and 
 
853
                <code class="filename">/etc/group</code> files, be sure to add the same accounts
 
854
                with identical UID and GID values for each user.
 
855
                </p><p>
 
856
                Where LDAP is used, if the new system is intended to be the LDAP server,
 
857
                migrate it across by configuring the LDAP server 
 
858
                (<code class="filename">/etc/openldap/slapd.conf</code>). The directory can
 
859
                be populated either initially by setting this LDAP server up as a slave or
 
860
                by dumping the data from the old LDAP server using the <code class="literal">slapcat</code>
 
861
                command and then reloading the same data into the new LDAP server using the
 
862
                <code class="literal">slapadd</code> command. Do not forget to install and configure
 
863
                the <code class="literal">nss_ldap</code> tool and the <code class="filename">/etc/nsswitch.conf</code>
 
864
                (as shown in <a class="link" href="happy.html" title="Chapter�5.�Making Happy Users">&#8220;Making Happy Users&#8221;</a>).
 
865
                </p></li><li><p>
 
866
                Copy the <code class="filename">smb.conf</code> file from the old server to the new server into the correct
 
867
                location as indicated previously in this chapter.
 
868
                </p></li><li><p>
 
869
                Copy the <code class="filename">secrets.tdb</code> file, the <code class="filename">smbpasswd</code>
 
870
                file (if it is used), the <code class="filename">/etc/samba/passdb.tdb</code> file (only
 
871
                used by the <code class="constant">tdbsam</code> backend), and all the tdb control files
 
872
                from the old system to the correct location on the new system.
 
873
                </p></li><li><p>
 
874
                Before starting the Samba daemons, verify that the hostname of the new server
 
875
                is identical to that of the old one. Note: The IP address can be different
 
876
                from that of the old server.
 
877
                </p></li><li><p>
 
878
                Copy all files from the old server to the new server, taking precaution to
 
879
                preserve all file ownership and permissions as well as any POSIX ACLs that
 
880
                may have been created on the old server.
 
881
                </p></li></ul></div><p>
 
882
        When replacing a Samba domain controller (PDC or BDC) that uses LDAP, the new server
 
883
        need simply be configured to use the LDAP directory, and for the rest it should just
 
884
        work. The domain SID is obtained from the LDAP directory as part of the first connect
 
885
        to the LDAP directory server.
 
886
        </p><p>
 
887
        All Samba servers, other than one that uses LDAP, depend on the tdb files, and
 
888
        particularly on the <code class="filename">secrets.tdb</code> file. So long as the tdb files are
 
889
        all in place, the <code class="filename">smb.conf</code> file is preserved, and either the hostname is identical
 
890
        or the <em class="parameter"><code>netbios name</code></em> is set to the original server name, Samba
 
891
        should correctly pick up the original SID and preserve all other settings. It is
 
892
        sound advice to validate this before turning the system over to users.
 
893
        </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2601137"></a>Migration of Samba Accounts to Active Directory</h3></div></div></div><p>
 
894
        Yes, it works. The Windows ADMT tool can be used to migrate Samba accounts
 
895
        to MS Active Directory.  There are a few pitfalls to be aware of:
 
896
        </p><div class="procedure"><a name="id2601149"></a><p class="title"><b>Procedure�8.2.�Migration to Active Directory</b></p><ol type="1"><li><p>
 
897
                Administrator password must be THE SAME on the Samba server,
 
898
                the 2003 ADS, and the local Administrator account on the workstations. 
 
899
                Perhaps this goes without saying, but there needs to be an account
 
900
                called <code class="constant">Administrator</code> in your Samba domain, with 
 
901
                full administrative (root) rights to that domain.
 
902
                </p></li><li><p>
 
903
                In the Advanced/DNS section of the TCP/IP settings on your Windows 
 
904
                workstations, make sure the <em class="parameter"><code>DNS suffix for this 
 
905
                connection</code></em> field is blank. 
 
906
                </p></li><li><p>
 
907
                Because you are migrating from Samba, user passwords cannot be 
 
908
                migrated. You'll have to reset everyone's passwords. (If you were 
 
909
                migrating from NT4 to ADS, you could migrate passwords as well.)
 
910
                </p><p>
 
911
                To date this has not been attempted with roaming profile support;
 
912
                it has been documented as working with local profiles.
 
913
                </p></li><li><p>
 
914
                Disable the Windows Firewall on all workstations. Otherwise, 
 
915
                workstations won't be migrated to the new domain.
 
916
                </p></li><li><p>
 
917
                <a class="indexterm" name="id2601216"></a>
 
918
                When migrating machines, always test first (using ADMT's test mode) 
 
919
                and satisfy all errors before committing the migration. Note that the 
 
920
                test will always fail, because the machine will not have been actually 
 
921
                migrated. You'll need to interpret the errors to know whether the 
 
922
                failure was due to a problem or simply to the fact that it was just 
 
923
                a test.
 
924
                </p></li></ol></div><p>
 
925
        <a class="indexterm" name="id2601233"></a>
 
926
        There are some significant benefits of using the ADMT, besides just 
 
927
        migrating user accounts. ADMT can be found on the Windows 2003 CD.
 
928
        </p><div class="itemizedlist"><ul type="disc"><li><p>
 
929
                You can migrate workstations remotely. You can specify that SIDs 
 
930
                be simply added instead of replaced, giving you the option of joining a 
 
931
                workstation back to the old domain if something goes awry. The 
 
932
                workstations will be joined to the new domain.
 
933
                </p></li><li><p>
 
934
                Not only are user accounts migrated from the old domain to the new 
 
935
                domain, but ACLs on the workstations are migrated as well. Like SIDs, 
 
936
                ACLs can be added instead of replaced.
 
937
                </p></li><li><p>
 
938
                Locally stored user profiles on workstations are migrated as well, 
 
939
                presenting almost no disruption to the user. Saved passwords will be 
 
940
                lost, just as when you administratively reset the password in Windows ADS.
 
941
                </p></li><li><p>
 
942
                The ADMT lets you test all operations before actually performing the 
 
943
                migration. Accounts and workstations can be migrated individually or in 
 
944
                batches. User accounts can be safely migrated all at once (since no 
 
945
                changes are made on the original domain). It is recommended to migrate only one 
 
946
                or two workstations as a test before committing them all.
 
947
                </p></li></ul></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="unixclients.html">Prev</a>�</td><td width="20%" align="center"><a accesskey="u" href="DMSMig.html">Up</a></td><td width="40%" align="right">�<a accesskey="n" href="ntmigration.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter�7.�Adding Domain Member Servers and Clients�</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">�Chapter�9.�Migrating NT4 Domain to Samba-3</td></tr></table></div></body></html>