diff options
author | John Terpstra <jht@samba.org> | 2005-04-22 01:46:37 +0000 |
---|---|---|
committer | Gerald W. Carter <jerry@samba.org> | 2008-04-23 08:46:29 -0500 |
commit | 09e6ae739eba0cf9f930bb649372aadc39725e80 (patch) | |
tree | b15abef3a5d99f85a8831cfb1f26b78cc6c78934 | |
parent | 767b9865400ab8185d4a5fe7887a2805692655e4 (diff) | |
download | samba-09e6ae739eba0cf9f930bb649372aadc39725e80.tar.gz samba-09e6ae739eba0cf9f930bb649372aadc39725e80.tar.bz2 samba-09e6ae739eba0cf9f930bb649372aadc39725e80.zip |
More updates from feedback.
(This used to be commit ec27e365ae0798d836acf11bece1dccc25a4c2c7)
-rw-r--r-- | docs/Samba-Guide/SBE-AddingUNIXClients.xml | 8 | ||||
-rw-r--r-- | docs/Samba-Guide/SBE-MakingHappyUsers.xml | 185 | ||||
-rw-r--r-- | docs/Samba-Guide/SBE-MigrateNT4Samba3.xml | 25 | ||||
-rw-r--r-- | docs/Samba-Guide/SBE-MigrateNW4Samba3.xml | 2 |
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] > sambaDomainName=DAMNATION + [cn=NextFreeUnixId] > sambaDomainName=DAMNATION . ldap master server: IP adress or DNS name of the master (writable) ldap server ldap master server [] > 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> |