summaryrefslogtreecommitdiff
path: root/docs/Samba-Guide
diff options
context:
space:
mode:
Diffstat (limited to 'docs/Samba-Guide')
-rw-r--r--docs/Samba-Guide/SBE-AddingUNIXClients.xml8
-rw-r--r--docs/Samba-Guide/SBE-MakingHappyUsers.xml185
-rw-r--r--docs/Samba-Guide/SBE-MigrateNT4Samba3.xml25
-rw-r--r--docs/Samba-Guide/SBE-MigrateNW4Samba3.xml2
4 files changed, 101 insertions, 119 deletions
diff --git a/docs/Samba-Guide/SBE-AddingUNIXClients.xml b/docs/Samba-Guide/SBE-AddingUNIXClients.xml
index 4e2f840d72..4fa1e8c715 100644
--- a/docs/Samba-Guide/SBE-AddingUNIXClients.xml
+++ b/docs/Samba-Guide/SBE-AddingUNIXClients.xml
@@ -523,8 +523,8 @@
<para>
The instructions given here apply to the Samba environment as shown in Chapters 6 and 7.
- If your network does not have an LDAP slave server (i.e., Chapter 6 configuration), you
- must change the target LDAP server from <constant>lapdc</constant> to <constant>massive.</constant>
+ If the network does not have an LDAP slave server (i.e., Chapter 6 configuration),
+ change the target LDAP server from <constant>lapdc</constant> to <constant>massive.</constant>
</para>
<procedure>
@@ -605,7 +605,7 @@ sammy:x:4321:
<primary>group membership</primary>
</indexterm>
This shows that all is working as it should. Notice that in the LDAP database
- the users primary and secondary group memberships are identical. It is not
+ the users' primary and secondary group memberships are identical. It is not
necessary to add secondary group memberships (in the group database) if the
user is already a member via primary group membership in the password database.
When using winbind, it is in fact undesirable to do this as it results in
@@ -705,7 +705,7 @@ Join to 'MEGANET2' failed.
<step><para>
<indexterm><primary>wbinfo</primary></indexterm>
- Just joining the Domain is not quite enough, you must now provide a privilidged set
+ Just joining the Domain is not quite enough, you must now provide a priviledged set
of credentials through which <command>winbindd</command> can interact with the ADS
Domain servers. Execute the following to implant the necessary credentials:
<screen>
diff --git a/docs/Samba-Guide/SBE-MakingHappyUsers.xml b/docs/Samba-Guide/SBE-MakingHappyUsers.xml
index 3ddf3305c1..e3396635d4 100644
--- a/docs/Samba-Guide/SBE-MakingHappyUsers.xml
+++ b/docs/Samba-Guide/SBE-MakingHappyUsers.xml
@@ -38,17 +38,12 @@ clients is conservative and if followed will minimize problems - but it is not a
<varlistentry>
<term>Users experiencing difficulty logging onto the network</term>
<listitem><para>
- <indexterm>
- <primary>network</primary>
- <secondary>logon</secondary>
- </indexterm>
+ <indexterm><primary>network</primary><secondary>logon</secondary></indexterm>
+ <indexterm><primary>multiple domain controllers</primary></indexterm>
When a Windows client logs onto the network, many data packets are exchanged
between the client and the server that is providing the network logon services.
Each request between the client and the server must complete within a specific
time limit. This is one of the primary factors that govern the installation of
- <indexterm>
- <primary>multiple domain controllers</primary>
- </indexterm>
multiple domain controllers (usually called secondary or backup controllers).
As a rough rule, there should be one such backup controller for every
30 to 150 clients. The actual limits are determined by network operational
@@ -65,47 +60,38 @@ clients is conservative and if followed will minimize problems - but it is not a
print server, the number of clients it can service reliably is reduced
and a common rule is not to exceed 30 machines (Windows workstations plus
Domain Member servers) per Domain Controller.
- </para></listitem></varlistentry>
+ </para></listitem>
+ </varlistentry>
<varlistentry>
<term>Slow logons and log-offs</term>
<listitem><para>
- <indexterm>
- <primary>slow logon</primary>
- </indexterm>
+ <indexterm><primary>slow logon</primary></indexterm>
Slow logons and log-offs may be caused by many factors that include:
<itemizedlist>
- <listitem><para><indexterm>
- <primary>NetBIOS</primary>
- <secondary>name resolution</secondary>
- <tertiary>delays</tertiary>
- </indexterm><indexterm>
- <primary>WINS</primary>
- <secondary>server</secondary>
- </indexterm>
+ <listitem><para>
+ <indexterm><primary>NetBIOS</primary><secondary>name resolution</secondary>
+ <tertiary>delays</tertiary></indexterm>
+ <indexterm><primary>WINS</primary><secondary>server</secondary></indexterm>
Excessive delays in the resolution of a NetBIOS name to its IP
address. This may be observed when an overloaded domain controller
is also the WINS server. Another cause may be the failure to use
a WINS server (this assumes that there is a single network segment).
</para></listitem>
- <listitem><para><indexterm>
- <primary>traffic collisions</primary>
- </indexterm><indexterm>
- <primary>HUB</primary>
- </indexterm><indexterm>
- <primary>Etherswitch</primary>
- </indexterm>
+ <listitem><para>
+ <indexterm><primary>traffic collisions</primary></indexterm>
+ <indexterm><primary>HUB</primary></indexterm>
+ <indexterm><primary>Etherswitch</primary></indexterm>
Network traffic collisions due to overloading of the network
segment &smbmdash; one short-term workaround to this may be to replace
network HUBs with Ether-switches.
</para></listitem>
- <listitem><para><indexterm>
- <primary>networking hardware</primary>
- <secondary>defective</secondary>
- </indexterm>
+ <listitem><para>
+ <indexterm><primary>networking hardware</primary>
+ <secondary>defective</secondary></indexterm>
Defective networking hardware. Over the past few years, we have seen
on the Samba mailing list a significant increase in the number of
problems that were traced to a defective network interface controller,
@@ -114,13 +100,11 @@ clients is conservative and if followed will minimize problems - but it is not a
the cause of the problem.
</para></listitem>
- <listitem><para><indexterm>
- <primary>profile</primary>
- <secondary>roaming</secondary>
- </indexterm><indexterm>
- <primary>MS Outlook</primary>
- <secondary>PST file</secondary>
- </indexterm>
+ <listitem><para>
+ <indexterm><primary>profile</primary>
+ <secondary>roaming</secondary></indexterm>
+ <indexterm><primary>MS Outlook</primary>
+ <secondary>PST file</secondary></indexterm>
Excessively large roaming profiles. This type of problem is typically
the result of poor user eduction, as well as poor network management.
It can be avoided by users not storing huge quantities of email in
@@ -129,16 +113,15 @@ clients is conservative and if followed will minimize problems - but it is not a
on the part of network management.
</para></listitem>
- <listitem><para><indexterm>
- <primary>WebClient</primary>
- </indexterm>
+ <listitem><para>
+ <indexterm><primary>WebClient</primary></indexterm>
You should verify that the Windows XP WebClient service is not running.
The use of the WebClient service has been implicated in many Windows
networking related problems.
</para></listitem>
</itemizedlist>
-
- </para></listitem></varlistentry>
+ </para></listitem>
+ </varlistentry>
<varlistentry>
<term>Loss of access to network drives and printer resources</term>
@@ -148,10 +131,8 @@ clients is conservative and if followed will minimize problems - but it is not a
</para>
<itemizedlist>
- <listitem><para><indexterm>
- <primary>network</primary>
- <secondary>overload</secondary>
- </indexterm>
+ <listitem><para>
+ <indexterm><primary>network</primary><secondary>overload</secondary></indexterm>
Network overload (typically indicated by a high network collision rate)
</para></listitem>
@@ -159,39 +140,32 @@ clients is conservative and if followed will minimize problems - but it is not a
Server overload
</para></listitem>
- <listitem><para><indexterm>
- <primary>network</primary>
- <secondary>timeout</secondary>
- </indexterm>
+ <listitem><para>
+ <indexterm><primary>network</primary><secondary>timeout</secondary></indexterm>
Timeout causing the client to close a connection that is in use, but has
been latent (no traffic) for some time (5 minutes or more)
</para></listitem>
- <listitem><para><indexterm>
- <primary>network hardware</primary>
- <secondary>defective</secondary>
- </indexterm>
+ <listitem><para>
+ <indexterm><primary>network hardware</primary><secondary>defective</secondary></indexterm>
Defective networking hardware
</para></listitem>
</itemizedlist>
- <para><indexterm>
- <primary>data</primary>
- <secondary>corruption</secondary>
- </indexterm>
+ <para>
+ <indexterm><primary>data</primary><secondary>corruption</secondary></indexterm>
No matter what the cause, a sudden operational loss of access to network resources can
result in BSOD (blue screen of death) situations that necessitate rebooting of the client
workstation. In the case of a mild problem, retrying to access the network drive of printer
may restore operations, but in any case this is a serious problem as it may lead to the next
problem, data corruption.
- </para></listitem></varlistentry>
+ </para></listitem>
+ </varlistentry>
<varlistentry>
<term>Potential data corruption</term>
- <listitem><para><indexterm>
- <primary>data</primary>
- <secondary>corruption</secondary>
- </indexterm>
+ <listitem><para>
+ <indexterm><primary>data</primary><secondary>corruption</secondary></indexterm>
Data corruption is one of the most serious problems. It leads to uncertainty, anger, and
frustration, and generally precipitates immediate corrective demands. Management response
to this type of problem may be rational, as well as highly irrational. There have been
@@ -200,7 +174,8 @@ clients is conservative and if followed will minimize problems - but it is not a
out and replaced, only to find the problem caused by a low-cost network hardware item. There
have been cases where server operating systems were replaced, or where Samba was updated,
only to later isolate the problem due to defective client software.
- </para></listitem></varlistentry>
+ </para></listitem>
+ </varlistentry>
</variablelist>
<para>
@@ -842,15 +817,12 @@ clients is conservative and if followed will minimize problems - but it is not a
<sect3 id="sbehap-locgrppol">
<title>The Local Group Policy</title>
- <para><indexterm>
- <primary>Group Policy Objects</primary>
- </indexterm><indexterm>
- <primary>Active Directory</primary>
- </indexterm><indexterm>
- <primary>PDC</primary>
- </indexterm><indexterm>
- <primary>Group Policy editor</primary>
- </indexterm>
+
+ <para>
+ <indexterm><primary>Group Policy Objects</primary></indexterm>
+ <indexterm><primary>Active Directory</primary></indexterm>
+ <indexterm><primary>PDC</primary></indexterm>
+ <indexterm><primary>Group Policy editor</primary></indexterm>
Without an Active Directory PDC, you cannot take full advantage of Group Policy
Objects. However, you can still make changes to the Local Group Policy by using
the Group Policy editor (<command>gpedit.msc</command>).
@@ -879,11 +851,10 @@ clients is conservative and if followed will minimize problems - but it is not a
<sect3>
<title>Profile Changes</title>
- <para><indexterm>
- <primary>NTUSER.DAT</primary>
- </indexterm><indexterm>
- <primary>%USERNAME%</primary>
- </indexterm>
+
+ <para>
+ <indexterm><primary>NTUSER.DAT</primary></indexterm>
+ <indexterm><primary>%USERNAME%</primary></indexterm>
There are two changes that should be done to each user's profile. Move each of
the directories that you have excluded from being copied back and forth out of
the usual profile path. Modify each user's <filename>NTUSER.DAT</filename> file
@@ -891,17 +862,14 @@ clients is conservative and if followed will minimize problems - but it is not a
path (<filename>C:\Documents and Settings\%USERNAME%</filename>).
</para>
- <para><indexterm>
- <primary>Default User</primary>
- </indexterm><indexterm>
- <primary>regedt32</primary>
- </indexterm>
+ <para>
+ <indexterm><primary>Default User</primary></indexterm>
+ <indexterm><primary>regedt32</primary></indexterm>
The above modifies existing user profiles. So that newly created profiles have
these settings, you will need to modify the <filename>NTUSER.DAT</filename> in
the <filename>C:\Documents and Settings\Default User</filename> folder on each
client machine, changing the same registry keys. You could do this by copying
- <filename>NTUSER.DAT</filename> to a Linux box and using
- <command>regedt32</command>.
+ <filename>NTUSER.DAT</filename> to a Linux box and using <command>regedt32</command>.
The basic method is described under <link linkend="redirfold"/>.
</para>
@@ -910,19 +878,16 @@ clients is conservative and if followed will minimize problems - but it is not a
<sect3>
<title>Using a Network Default User Profile</title>
- <para><indexterm>
- <primary>NETLOGON</primary>
- </indexterm><indexterm>
- <primary>NTUSER.DAT</primary>
- </indexterm>
+ <para>
+ <indexterm><primary>NETLOGON</primary></indexterm>
+ <indexterm><primary>NTUSER.DAT</primary></indexterm>
If you are using Samba as your PDC, you should create a file-share called
<constant>NETLOGON</constant> and within that create a directory called
<filename>Default User</filename>, which is a copy of the desired default user
configuration (including a copy of <filename>NTUSER.DAT</filename>.
If this share exists and the <filename>Default User</filename> folder exists,
the first login from a new account pulls its configuration from it.
- See also: <ulink
- url="http://isg.ee.ethz.ch/tools/realmen/det/skel.en.html">
+ See also: <ulink url="http://isg.ee.ethz.ch/tools/realmen/det/skel.en.html">
the Real Men Don't Click</ulink> Web site.
</para>
@@ -931,14 +896,10 @@ clients is conservative and if followed will minimize problems - but it is not a
<sect3>
<title>Installation of Printer Driver Auto-Download</title>
- <para><indexterm>
- <primary>printing</primary>
- <secondary>dumb</secondary>
- </indexterm><indexterm>
- <primary>dumb printing</primary>
- </indexterm><indexterm>
- <primary>Raw Print Through</primary>
- </indexterm>
+ <para>
+ <indexterm><primary>printing</primary><secondary>dumb</secondary></indexterm>
+ <indexterm><primary>dumb printing</primary></indexterm>
+ <indexterm><primary>Raw Print Through</primary></indexterm>
The subject of printing is quite topical. Printing problems run second place to name
resolution issues today. So far in this book, you have experienced only what is generally
known as <quote>dumb</quote> printing. Dumb printing is the arrangement where all drivers
@@ -948,13 +909,9 @@ clients is conservative and if followed will minimize problems - but it is not a
<command>Raw Print Through</command> printing.
</para>
- <para><indexterm>
- <primary>printing</primary>
- <secondary>drag-and-drop</secondary>
- </indexterm><indexterm>
- <primary>printing</primary>
- <secondary>point-n-click</secondary>
- </indexterm>
+ <para>
+ <indexterm><primary>printing</primary><secondary>drag-and-drop</secondary></indexterm>
+ <indexterm><primary>printing</primary><secondary>point-n-click</secondary></indexterm>
Samba permits the configuration of <command>Smart</command> printing using the Microsoft
Windows point-and-click (also called drag-and-drop) printing. What this provides is
essentially the ability to print to any printer. If the local client does not yet have a
@@ -1049,6 +1006,18 @@ clients is conservative and if followed will minimize problems - but it is not a
</sect4>
<sect4>
+ <title>The Name Service Caching Daemon (nscd)</title>
+
+ <para>
+ The Name Service Caching Daemon (nscd) is a primary cause of diffculties with name
+ resolution, particularly where <command>winbind</command> is used. Winbind does its
+ own caching, thus nscd causes double caching which can lead to peculiar problems during
+ debugging. As a rule it is a good idea to turn off the name service caching daemon.
+ </para>
+
+ </sect4>
+
+ <sect4>
<title>Debugging LDAP</title>
<para>
@@ -2491,7 +2460,7 @@ Starting ldap-server done
<step><para>
Execute the script that will populate the LDAP database as shown here:
<screen>
-&rootprompt; ./smbldap-populate -a root -k 0
+&rootprompt; ./smbldap-populate -a root -k 0 -m 0
</screen>
The expected output from this is:
<screen>
diff --git a/docs/Samba-Guide/SBE-MigrateNT4Samba3.xml b/docs/Samba-Guide/SBE-MigrateNT4Samba3.xml
index e0697ec24d..e4075799da 100644
--- a/docs/Samba-Guide/SBE-MigrateNT4Samba3.xml
+++ b/docs/Samba-Guide/SBE-MigrateNT4Samba3.xml
@@ -397,7 +397,6 @@
[global]
workgroup = DAMNATION
netbios name = MERLIN
- interfaces = eth0, lo
passdb backend = ldapsam:ldap://localhost
username map = /etc/samba/smbusers
log level = 1
@@ -418,7 +417,7 @@
set primary group script = \
/opt/IDEALX/sbin/smbldap-usermod -g '%g' '%u'
add machine script = /opt/IDEALX/sbin/smbldap-useradd -w '%u'
- logon script = scripts\logon.bat
+ logon script = scripts\logon.cmd
logon path = \\%L\profiles\%U
logon home = \\%L\%U
logon drive = X:
@@ -646,11 +645,25 @@ rtt min/avg/max/mdev = 0.141/0.164/0.192/0.021 ms
</para></step>
<step><para>
- Obtain the domain SID from the target NT4 domain that is being
+ Pull the Domain SID from the NT4 Domain that is being migrated as follows:
+<screen>
+&rootprompt; net rpc getsid -S TRANGRESSION -U Administrator%not24get
+Storing SID S-1-5-21-1385457007-882775198-1210191635 \
+ for Domain DAMNATION in secrets.tdb
+</screen>
+ </para>
+
+ <para>
+ Another way to obtain the domain SID from the target NT4 domain that is being
migrated to Samba-3 by executing the following:
<screen>
&rootprompt; net rpc info -S TRANSGRESSION
</screen>
+ If this method is used, do not forget to store the SID obtained into the
+ <filename>secrets.tdb</filename> file. This can be done by executing:
+<screen>
+&rootprompt; net setlocalsid S-1-5-21-1385457007-882775198-1210191635
+</screen>
</para></step>
<step><para>
@@ -714,7 +727,7 @@ Let's start configuring the smbldap-tools scripts ...
. sambaUnixIdPooldn: object where you want to store the next uidNumber
and gidNumber available for new users and groups
sambaUnixIdPooldn object (relative to ${suffix})
- [cn=NextFreeUnixId] &gt; sambaDomainName=DAMNATION
+ [cn=NextFreeUnixId] &gt; sambaDomainName=DAMNATION
. ldap master server:
IP adress or DNS name of the master (writable) ldap server
ldap master server [] &gt; 127.0.0.1
@@ -802,7 +815,7 @@ Setting stored password for
<step><para>
Populate the LDAP directory as shown here:
<screen>
-&rootprompt; /opt/IDEALX/sbin/smbldap-populate -a root -u 0
+&rootprompt; /opt/IDEALX/sbin/smbldap-populate -a root -k 0 -m 0
Using workgroup name from sambaUnixIdPooldn (smbldap.conf):
sambaDomainName=DAMNATION
Using builtin directory structure
@@ -848,7 +861,7 @@ man:x:13:62:Manual pages viewer:/var/cache/man:/bin/bash
news:x:9:13:News system:/etc/news:/bin/bash
uucp:x:10:14:Unix-to-Unix CoPy system:/etc/uucp:/bin/bash
+::0:0:::
-root:x:998:512:Netbios Domain Administrator:/home/users/root:/bin/false
+root:x:0:0:Netbios Domain Administrator:/home/users/root:/bin/false
nobody:x:999:514:nobody:/dev/null:/bin/false
</screen>
Now repeat this for the group accounts as shown here:
diff --git a/docs/Samba-Guide/SBE-MigrateNW4Samba3.xml b/docs/Samba-Guide/SBE-MigrateNW4Samba3.xml
index d74f9ec954..4a1e70bc25 100644
--- a/docs/Samba-Guide/SBE-MigrateNW4Samba3.xml
+++ b/docs/Samba-Guide/SBE-MigrateNW4Samba3.xml
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
<chapter id="nw4migration">
- <title>Migrating NetWare 4.11 Server to Samba-3</title>
+ <title>Migrating NetWare Server to Samba-3</title>
<para>
<indexterm><primary>Novell</primary></indexterm>