<simplelist>
<member>http://www.craigelachie.org/rhacer/ntlogon</member>
<member>http://www.kixtart.org</member>
+ <member>http://support.microsoft.com/default.asp?scid=kb;en-us;189105</member>
</simplelist>
+<sect2>
+<title>Adding printers without user intervention</title>
+
+<para>
+Printers may be added automatically during logon script processing through the use of:
+
+<programlisting>
+ rundll32 printui.dll,PrintUIEntry /?
+</programlisting>
+
+See the documentation in the Microsoft knowledgebase article no: 189105 referred to above.
+</para>
+</sect2>
+
</sect1>
</chapter>
<title>Planning and Getting Started</title>
<para>
-You must use at least the following ...
+In the IT world there is often a saying that all problems are encountered because of
+poor planning. The corrollary to this saying is that not all problems can be anticpated
+and planned for. Then again, good planning will anticpate most show stopper type situations.
+</para>
+
+<para>
+Those wishing to migrate from MS Windows NT4 domain control to a Samba-3 domain control
+environment would do well to develop a detailed migration plan. So here are a few pointers to
+help migration get under way.
</para>
<sect2>
<title>Objectives</title>
<para>
-Blah blah objectives here.
+The key objective for most organisations will be to make the migration from MS Windows NT4
+to Samba-3 domain control as painless as possible. One of the challenges you may experience
+in your migration process may well be one of convincing management that the new environment
+should remain in place. Many who have introduced open source technologies have experienced
+pressure to return to a Microsoft based platform solution at the first sign of trouble.
</para>
-</sect2>
-<sect2>
-<title>Steps In Migration Process</title>
+<para>
+It is strongly advised that before attempting a migration to a Samba-3 controlled network
+that every possible effort be made to gain all-round commitment to the change. Firstly, you
+should know precisely <emphasis>why</emphasis> the change is important for the organisation.
+Possible motivations to make a change include:
+</para>
+
+<itemizedlist>
+<listitem>
+ <para>Improve network manageability</para>
+</listitem>
+<listitem>
+ <para>Obtain better user level functionality</para>
+</listitem>
+<listitem>
+ <para>Reduce network operating costs</para>
+</listitem>
+<listitem>
+ <para>Reduce exposure caused by Microsoft withdrawal of NT4 support</para>
+</listitem>
+<listitem>
+ <para>Avoid MS License 6 implications</para>
+</listitem>
+<listitem>
+ <para>Reduce organisation's dependency on Microsoft</para>
+</listitem>
+</itemizedlist>
<para>
-This is not a definitive ste-by-step process yet - just a place holder so the info
-is not lost.
+It is vital that it be well recognised that Samba-3 is NOT MS Windows NT4. Samba-3 offers
+an alternative solution that is both different from MS Windows NT4 and that offers some
+advantages compared with it. It should also be recognised that Samba-3 lacks many of the
+features that Microsoft has promoted as core values in migration from MS Windows NT4 to
+MS Windows 2000 and beyond (with or without Active Directory services).
+</para>
-1. You will have an NT4 PDC that has the users, groups, policies and profiles to be migrated
+<para>
+What are the features that Samba-3 can NOT provide?
+</para>
-2. Samba-3 set up as a DC with netlogon share, profile share, etc.
+<itemizedlist>
+<listitem>
+ <para>Active Directory Server<para>
+</listitem>
+<listitem>
+ <para>Group Policy Objects (in Active Direcrtory)<para>
+</listitem>
+<listitem>
+ <para>Machine Policy objects<para>
+</listitem>
+<listitem>
+ <para>Logon Scripts in Active Directorty<para>
+</listitem>
+<listitem>
+ <para>Software Application and Access Controls in Active Directory<para>
+</listitem>
+</itemizedlist>
-3. Process:
- a. Create a BDC account for the samba server using NT Server Manager
- - Samba must NOT be running
+<para>
+The features that Samba-3 DOES provide and that may be of compelling interest to your site
+includes:
+</para>
- b. rpcclient NT4PDC -U Administrator%passwd
- lsaquery
+<itemizedlist>
+<listitem>
+ <para>Lower Cost of Ownership</para>
+</listitem>
+<listitem>
+ <para>Global availability of support with no strings attached</para>
+</listitem>
+<listitem>
+ <para>Dynamic SMB Servers (ie:Can run more than one server per Unix/Linux system)</para>
+</listitem>
+<listitem>
+ <para>Creation of on-the-fly logon scripts</para>
+</listitem>
+<listitem>
+ <para>Creation of on-the-fly Policy Files</para>
+</listitem>
+<listitem>
+ <para>Greater Stability, Reliability, Performance and Availability</para>
+</listitem>
+<listitem>
+ <para>Manageability via an ssh connection</para>
+</listitem>
+<listitem>
+ <para>Flexible choices of back-end authentication technologies (tdbsam, ldapsam, mysqlsam)</para>
+</listitem>
+<listitem>
+ <para>Ability to implement a full single-signon architecture</para>
+</listitem>
+<listitem>
+ <para>Ability to distribute authentication systems for absolute minimum wide are network bandwidth demand</para>
+</listitem>
+</itemizedlist>
- Note the SID returned by step b.
+<para>
+Before migrating a network from MS Windows NT4 to Samba-3 it is vital that all necessary factors are
+considered. Users should be educated about changes they may experience so that the change will be a
+welcome one and not become an obstacle to the work they need to do. The following are some of the
+factors that will go into a successful migration:
+</para>
- c. net getsid -S NT4PDC -w DOMNAME -U Administrator%passwd
+<sect3>
+<title>Domain Layout</title>
- Note the SID in step c.
+<para>
+Samba-3 can be configured as a domain controller, a back-up domain controller (probably best called
+a secondary controller), a domain member, or as a stand-alone server. The Windows network security
+domain context should be sized and scoped before implementation. Particular attention needs to be
+paid to the location of the primary domain controller (PDC) as well as backup controllers (BDCs).
+It should be noted that one way in which Samba-3 differs from Microsoft technology is that if one
+chooses to use an LDAP authentication backend then the same database can be used by several different
+domains. This means that in a complex organisation there can be a single LDAP database, that itself
+can be distributed, that can simultaneously serve multiple domains (that can also be widely distributed).
+</para>
- d. net getlocalsid
+<para>
+It is recommended that from a design perspective, the number of users per server, as well as the number
+of servers, per domain should be scaled according to needs and should also consider server capacity
+and network bandwidth.
+</para>
- Note the SID, now check that all three SIDS reported are the same!
+<para>
+A physical network segment may house several domains, each of which may span multiple network segments.
+Where domains span routed network segments it is most advisable to consider and test the performance
+implications of the design and layout of a network. A Centrally located domain controller that is being
+designed to serve mulitple routed network segments may result in severe performance problems if the
+response time (eg: ping timing) between the remote segment and the PDC is more than 100 ms. In situations
+where the delay is too long it is highly recommended to locate a backup controller (BDC) to serve as
+the local authentication and access control server.
+</para>
+</sect3>
- e. net rpc join -S NT4PDC -w DOMNAME -U Administrator%passwd
+<sect3>
+<title>Server Share and Directory Layout</title>
- f. net rpc vampire -S NT4PDC -U administrator%passwd
+<para>
+There are few cardinal rules to effective network design that can be broken with impunity.
+The most important rule of effective network management is that simplicity is king in every
+well controlled network. Every part of the infrastructure must be managed, the more complex
+it is, the greater will be the demand of keeping systems secure and functional.
+</para>
- g. pdbedit -l
+<para>
+The nature of the data that must be stored needs to be born in mind when deciding how many
+shares must be created. The physical disk space layout should also be taken into account
+when designing where share points will be created. Keep in mind that all data needs to be
+backed up, thus the simpler the disk layout the easier it will be to keep track of what must
+be backed up to tape or other off-line storage medium. Always plan and implement for minimum
+maintenance. Leave nothing to chance in your design, above all, do not leave backups to chance:
+Backup and test, validate every backup, create a disaster recovery plan and prove that it works.
+</para>
- Note - did the users migrate?
+<para>
+Users should be grouped according to data access control needs. File and directory access
+is best controlled via group permissions and the use of the "sticky bit" on group controlled
+directories may substantially avoid file access complaints from samba share users.
+</para>
- h. initGrps.sh DOMNAME
+<para>
+Many network administrators who are new to the game will attempt to use elaborate techniques
+to set access controls, on files, directories, shares, as well as in share definitions.
+There is the ever present danger that that administrator's successor will not understand the
+complex mess that has been inherited. Remember, apparent job security through complex design
+and implementation may ultimately cause loss of operations and downtime to users as the new
+administrator learns to untangle your web. Keep access controls simple and effective and
+make sure that users will never be interrupted by the stupidity of complexity.
+</para>
+</sect3>
- i. smbgroupedit -v
+<sect3>
+<title>Logon Scripts</title>
- Now check that all groups are recognised
+<para>
+Please refer to the section of this document on Advanced Network Adminsitration for information
+regarding the network logon script options for Samba-3. Logon scripts can help to ensure that
+all users gain share and printer connections they need.
+</para>
- j. net rpc campire -S NT4PDC -U administrator%passwd
+<para>
+Logon scripts can be created on-the-fly so that all commands executed are specific to the
+rights and privilidges granted to the user. The preferred controls should be affected through
+group membership so that group information can be used to custom create a logong script using
+the <filename>root preexec</filename> parameters to the <filename>NETLOGON</filename> share.
+</para>
+
+<para>
+Some sites prefer to use a tool such as <filename>kixstart</filename> to establish a controlled
+user environment. In any case you may wish to do a google search for logon script process controls.
+In particular, you may wish to explore the use of the Microsoft knowledgebase article KB189105 that
+deals with how to add printers without user intervention via the logon script process.
+</para>
+</sect3>
+
+<sect3>
+<title>Profile Migration/Creation</title>
- k. pdbedit -lv
+<para>
+User and Group Profiles may be migrated using the tools described in the section titled Desktop Profile
+Management.
+</para>
- Note - check that all group membership has been migrated.
+<para>
+Profiles may also be managed using the Samba-3 tool <filename>profiles</filename>. This tool allows
+the MS Windows NT style security identifiers (SIDs) that are stored inside the profile NTuser.DAT file
+to be changed to the SID of the Samba-3 domain.
+</para>
+</sect3>
+<sect3>
+<title>User and Group Accounts</title>
-Now it is time to migrate all the profiles, then migrate all policy files.
+<para>
+It is possible to migrate all account settings from an MS Windows NT4 domain to Samba-3. Before
+attempting to migrate user and group accounts it is STRONGLY advised to create in Samba-3 the
+groups that are present on the MS Windows NT4 domain <emphasis>AND</emphasis> to connect these to
+suitable Unix/Linux groups. Following this simple advice will mean that all user and group attributes
+should migrate painlessly.
+</para>
+</sect3>
+
+</sect2>
-Moe later.
+<sect2>
+<title>Steps In Migration Process</title>
+
+<para>
+The approximate migration process is described below.
+</para>
+
+<itemizedlist>
+<listitem><para>
+You will have an NT4 PDC that has the users, groups, policies and profiles to be migrated
+</para></listitem>
+
+<listitem><para>
+Samba-3 set up as a DC with netlogon share, profile share, etc.
+</para></listitem>
+</itemizedlist>
+
+<procedure><title>The Account Migration Process</title>
+ <step><para>Create a BDC account for the samba server using NT Server Manager</para>
+ <substeps><step><para>Samba must NOT be running</para></step></substeps></step>
+
+ <step>
+ <para>rpcclient NT4PDC -U Administrator%passwd</para>
+ <substeps><step><para>lsaquery</para></step>
+ <step><para>Note the SID returned</para></step>
+ </substeps>
+ </step>
+
+ <step><para>net getsid -S NT4PDC -w DOMNAME -U Administrator%passwd</para>
+ <substeps><step><para>Note the SID</para></step></substeps>
+ </step>
+
+ <step><para>net getlocalsid</para>
+ <substeps>
+ <step><para>Note the SID, now check that all three SIDS reported are the same!</para></step>
+ </substeps>
+ </step>
+
+ <step><para>net rpc join -S NT4PDC -w DOMNAME -U Administrator%passwd</para></step>
+
+ <step><para>net rpc vampire -S NT4PDC -U administrator%passwd</para></step>
+
+ <step><para>pdbedit -l</para>
+ <substeps><step><para>Note - did the users migrate?</para></step></substeps>
+ </step>
+
+ <step><para>initGrps.sh DOMNAME</para></step>
+
+ <step><para>smbgroupedit -v</para>
+ <substeps><step><para>Now check that all groups are recognised</para></step></substeps>
+ </step>
+
+ <step><para>net rpc campire -S NT4PDC -U administrator%passwd</para></step>
+
+ <step><para>pdbedit -lv</para>
+ <substeps><step>
+ <para>Note - check that all group membership has been migrated</para>
+ </step></substeps>
+ </step>
+</procedure>
+
+<para>
+Now it is time to migrate all the profiles, then migrate all policy files.
+More later.
</para>
</sect2>
</sect1>
<sect1>
-<title>Managing Samba-3 Domain Control</title>
+<title>Migration Options</title>
<para>
-Lots of blah blah here.
+Based on feedback from many sites as well as from actual installation and maintenance
+experience sites that wish to migrate from MS Windows NT4 Domain Control to a Samba
+based solution fit into three basic categories.
+</para>
+
+<table frame="all"><title>The 3 Major Site Types</title>
+<tgroup cols="2" align="center">
+ <thead>
+ <row><entry align="center">Number of Users</entry><entry>Description</entry></row>
+ </thead>
+ <tbody>
+ <row><entry align="center">< 50</entry><entry><para>Want simple conversion with NO pain</para></entry></row>
+ <row><entry align="center">50 - 250</entry><entry><para>Want new features, can manage some in-house complexity</para></entry></row>
+ <row><entry align="center">> 250</entry><entry><para>Solution/Implementation MUST scale well, complex needs. Cross departmental decision process. Local expertise in most areas</para></entry></row>
+ </tbody>
+</tgroup>
+</table>
+
+<sect2>
+<title>Planning for Success</title>
+
+<para>
+There are three basic choices for sites that intend to migrate from MS Windwows NT4
+to Samba-3.
+</para>
+
+<itemizedlist>
+ <listitem><para>
+ Simple Conversion (total replacement)
+ </para></listitem>
+
+ <listitem><para>
+ Upgraded Conversion (could be one of integration)
+ </para></listitem>
+
+ <listitem><para>
+ Complete Redesign (completely new solution)
+ </para></listitem>
+</itemizedlist>
+
+<para>
+No matter what choice you make, the following rules will minimise down-stream problems:
+</para>
+
+<itemizedlist>
+ <listitem><para>
+ Take sufficient time
+ </para></listitem>
+
+ <listitem><para>
+ Avoid Panic
+ </para></listitem>
+
+ <listitem><para>
+ Test ALL assumptions
+ </para></listitem>
+
+ <listitem><para>
+ Test full roll-out program, including workstation deployment
+ </para></listitem>
+</itemizedlist>
+
+<table frame="top"><title>Nature of the Conversion Choices</title>
+<tgroup cols="3" align="center">
+ <thead>
+ <row><entry>Simple</entry><entry>Upgraded</entry><entry>Redesign</entry></row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><para>Make use of minimal OS specific features</para></entry>
+ <entry><para>Translate NT4 features to new host OS features</para></entry>
+ <entry><para>Decide:</para></entry>
+ </row>
+ <row>
+ <entry><para>Suck all accounts from NT4 into Samba-3</para></entry>
+ <entry><para>Copy and improve:</para></entry>
+ <entry><para>Authentication Regime (database location and access)</para></entry>
+ </row>
+ <row>
+ <entry><para>Make least number of operational changes</para></entry>
+ <entry><para>Make progressive improvements</para></entry>
+ <entry><para>Desktop Management Methods</para></entry>
+ </row>
+ <row>
+ <entry><para>Take least amount of time to migrate</para></entry>
+ <entry><para>Minimise user impact</para></entry>
+ <entry><para>Better Control of Desktops / Users</para></entry>
+ </row>
+ <row>
+ <entry><para>Live versus Isolated Conversion</para></entry>
+ <entry><para>Maximise functionality</para></entry>
+ <entry><para>Identify Needs for: Manageability, Scalability, Security, Availability</para></entry>
+ </row>
+ <row>
+ <entry><para>Integrate Samba-3 then migrate while users are active, then Change of control (ie: swap out)</para></entry>
+ <entry><para>Take advantage of lower maintenance opportunity</para></entry>
+ <entry><para></para></entry>
+ </row>
+ </tbody>
+</tgroup>
+</table>
+</sect2>
+
+<sect2>
+<title>Samba Implementation Choices</title>
+
+<para><programlisting>
+Authentication database back end
+ Winbind (external Samba or NT4/200x server)
+ Can use pam_mkhomedir.so to auto-create home dirs
+ External server could use Active Directory or NT4 Domain
+
+Database type
+ smbpasswd, tdbsam, ldapsam, MySQLsam
+
+Access Control Points
+ On the Share itself (Use NT4 Server Manager)
+ On the file system
+ Unix permissions on files and directories
+ Posix ACLs enablement in file system?
+ Through Samba share parameters
+ Not recommended - except as only resort
+
+Policies (migrate or create new ones)
+ Group Policy Editor (NT4)
+ Watch out for Tattoo effect
+
+User and Group Profiles
+ Platform specific so use platform tool to change from a Local to a Roaming profile
+ Can use new profiles tool to change SIDs (NTUser.DAT)
+
+Logon Scripts (Know how they work)
+
+User and Group mapping to Unix/Linux
+ username map facility may be needed
+ Use smbgroupedit to connect NT4 groups to Unix groups
+ Use pdbedit to set/change user configuration
+NOTE:
+If migrating to LDAP back end it may be easier to dump initial LDAP database to LDIF, then edit, then reload into LDAP
+
+ OS specific scripts / programs may be needed
+ Add / delete Users
+ Note OS limits on size of name (Linux 8 chars)
+ NT4 up to 254 chars
+ Add / delete machines
+ Applied only to domain members (note up to 16 chars)
+ Add / delete Groups
+ Note OS limits on size and nature
+ Linux limit is 16 char, no spaces and no upper case chars (groupadd)
+
+Migration Tools
+ Domain Control (NT4 Style)
+ Profiles, Policies, Access Controls, Security
+
+Migration Tools
+ Samba: net, rpcclient, smbpasswd, pdbedit, smbgroupedit, profiles
+ Windows: NT4 Domain User Manager, Server Manager (NEXUS)
+
+Authentication
+ New SAM back end (smbpasswd, tdbsam, ldapsam, mysqlsam)
+</programlisting>
</para>
</sect1>
+
</chapter>
<title>Use latest TCP/IP stack from Microsoft</title>
<para>Use the latest TCP/IP stack from microsoft if you use Windows
-for workgroups.</para>
+for workgroups.
+</para>
<para>The early TCP/IP stacks had lots of bugs.</para>
it may break the print queue reporting on some systems.
It is presumably a WfWg bug.</para>
+</sect2>
+
+<sect2>
+<title>Speed improvement</title>
+
+<para>
+Note that some people have found that setting DefaultRcvWindow in
+the [MSTCP] section of the SYSTEM.INI file under WfWg to 3072 gives a
+big improvement. I don't know why.
+</para>
+
+<para>
+My own experience wth DefaultRcvWindow is that I get much better
+performance with a large value (16384 or larger). Other people have
+reported that anything over 3072 slows things down enourmously. One
+person even reported a speed drop of a factor of 30 when he went from
+3072 to 8192. I don't know why.
+</para>
</sect2>
</sect1>
neighborhood services.
</para>
+<sect2>
+<title>Speed improvement</title>
+
+<para>
+Configure the win95 TCPIP registry settings to give better
+performance. I use a program called MTUSPEED.exe which I got off the
+net. There are various other utilities of this type freely available.
+</para>
+
+</sect2>
+
</sect1>
<sect1>
<sect3>
<title>Administration of Win2K / XP Policies</title>
+<procedure>
<title>Instructions</title>
<para>
Instead of using the tool called "The System Policy Editor", commonly called Poledit (from the
executable name poledit.exe), GPOs are created and managed using a Microsoft Management Console
(MMC) snap-in as follows:</para>
-<procedure>
<step>
<para>
<sect1>
<title>Solaris</title>
+<sect2>
+<title>Locking improvements</title>
+
<para>Some people have been experiencing problems with F_SETLKW64/fcntl
when running samba on solaris. The built in file locking mechanism was
not scalable. Performance would degrade to the point where processes would
</para>
<para>Thanks to Joe Meslovich for reporting</para>
+
+</sect2>
+
+<sect2 id="winbind-solaris9">
+<title>Winbind on Solaris 9</title>
+<para>
+Nsswitch on Solaris 9 refuses to use the winbind nss module. This behavior
+is fixed by Sun in patch 113476-05 which as of March 2003 is not in any
+roll-up packages.
+</para>
</sect1>
</chapter>
<chapter id="SWAT">
<chapterinfo>
&author.jht;
- <pubdate>April 3, 2003</pubdate>
+ <pubdate>April 21, 2003</pubdate>
</chapterinfo>
<title>SWAT - The Samba Web Admininistration Tool</title>
<para>
-This is a rough guide to SWAT.
+There are many and varied opinions regarding the usefulness or otherwise of SWAT.
+No matter how hard one tries to produce the perfect configuration tool it remains
+an object of personal taste. SWAT is a tool that will allow web based configuration
+of samba. It has a wizard that may help to get samba configured quickly, it has context
+sensitive help on each smb.conf parameter, it provides for monitoring of current state
+of connection information, and it allows network wide MS Windows network password
+management.
</para>
<sect1>
<title>SWAT Features and Benefits</title>
-<para>You must use at least the following ...</para>
+<para>
+There are network administrators who believe that it is a good idea to write systems
+documentation inside configuration files, for them SWAT will aways be a nasty tool. SWAT
+does not store the configuration file in any intermediate form, rather, it stores only the
+parameter settings, so when SWAT writes the smb.conf file to disk it will write only
+those parameters that are at other than the default settings. The result is that all comments
+will be lost from the smb.conf file. Additionally, the parameters will be written back in
+internal ordering.
+</para>
+
+<note><para>
+So before using SWAT please be warned - SWAT will completely replace your smb.conf with
+a fully optimised file that has been stripped of all comments you might have placed there
+and only non-default settings will be written to the file.
+</para></note>
+
+<para>
+SWAT should be installed to run via the network super daemon. Depending on which system
+your Unix/Linux system has you will have either an <filename>inetd</filename> or
+<filename>xinetd</filename> based system.
+</para>
+
+<para>
+The nature and location of the network super-daemon varies with the operating system
+implementation. The control file (or files) can be located in the file
+<filename>/etc/inetd.conf</filename> or in the directory <filename>/etc/[x]inet.d</filename>
+or similar.
+</para>
+
+<para>
+The control entry for the older style file might be:
+</para>
+
+<para><programlisting>
+ # swat is the Samba Web Administration Tool
+ swat stream tcp nowait.400 root /usr/sbin/swat swat
+</programlisting></para>
+
+<para>
+A control file for the newer style xinetd could be:
+</para>
+
+<para>
+<programlisting>
+ # default: off
+ # description: SWAT is the Samba Web Admin Tool. Use swat \
+ # to configure your Samba server. To use SWAT, \
+ # connect to port 901 with your favorite web browser.
+ service swat
+ {
+ port = 901
+ socket_type = stream
+ wait = no
+ only_from = localhost
+ user = root
+ server = /usr/sbin/swat
+ log_on_failure += USERID
+ disable = yes
+ }
+</programlisting>
+</para>
+
+<para>
+Both the above examples assume that the <filename>swat</filename> binary has been
+located in the <filename>/usr/sbin</filename> directory. In addition to the above
+SWAT will use a directory access point from which it will load all it's help files,
+as well as other control information. The default location for this on most Linux
+systems is in the directory <filename>/usr/share/samba/swat</filename>.
+</para>
+
+<para>
+Access to SWAT will prompt for a logon. If you log onto SWAT as any non-root user
+the only permission allowed is to view certain aspects of configuration as well as
+access to the password change facility.
+</para>
+
+<para>
+So long as you log onto SWAT as the user <command>root</command> you should obtain
+full change and commit ability.
+</para>
<sect2>
<title>The SWAT Home Page</title>
<para>
-Blah blah here.
+The SWAT title page provides access to the latest Samba documentation. The manual page for
+each samba component is accessible from this page as are the Samba-HOWTO-Collection (this
+document) as well as the O'Reilly book "Using Samba".
</para>
</sect2>
</para>
<para>
-The "socket options" section of the smb.conf manual page describes how
+The <command>socket options</command> section of the &smb.conf; manual page describes how
to set these and gives recommendations.
</para>
<para>
The socket option TCP_NODELAY is the one that seems to make the
biggest single difference for most networks. Many people report that
-adding "socket options = TCP_NODELAY" doubles the read performance of
-a Samba drive. The best explanation I have seen for this is that the
-Microsoft TCP/IP stack is slow in sending tcp ACKs.
+adding <command>socket options = TCP_NODELAY</command> doubles the read
+performance of a Samba drive. The best explanation I have seen for this is
+that the Microsoft TCP/IP stack is slow in sending tcp ACKs.
</para>
</sect1>
<title>Read size</title>
<para>
-The option "read size" affects the overlap of disk reads/writes with
-network reads/writes. If the amount of data being transferred in
-several of the SMB commands (currently SMBwrite, SMBwriteX and
+The option <command>read size</command> affects the overlap of disk
+reads/writes with network reads/writes. If the amount of data being
+transferred in several of the SMB commands (currently SMBwrite, SMBwriteX and
SMBreadbraw) is larger than this value then the server begins writing
the data before it has received the whole packet from the network, or
in the case of SMBreadbraw, it begins writing to the network before
<title>Max xmit</title>
<para>
-At startup the client and server negotiate a "maximum transmit" size,
+At startup the client and server negotiate a <command>maximum transmit</command> size,
which limits the size of nearly all SMB commands. You can set the
-maximum size that Samba will negotiate using the "max xmit = " option
-in smb.conf. Note that this is the maximum size of SMB request that
+maximum size that Samba will negotiate using the <command>max xmit = </command> option
+in &smb.conf;. Note that this is the maximum size of SMB request that
Samba will accept, but not the maximum size that the *client* will accept.
The client maximum receive size is sent to Samba by the client and Samba
honours this limit.
<title>Log level</title>
<para>
-If you set the log level (also known as "debug level") higher than 2
+If you set the log level (also known as <command>debug level</command>) higher than 2
then you may suffer a large drop in performance. This is because the
server flushes the log file after each operation, which can be very
expensive.
<title>Read raw</title>
<para>
-The "read raw" operation is designed to be an optimised, low-latency
+The <command>read raw</command> operation is designed to be an optimised, low-latency
file read operation. A server may choose to not support it,
-however. and Samba makes support for "read raw" optional, with it
+however. and Samba makes support for <command>read raw</command> optional, with it
being enabled by default.
</para>
<para>
-In some cases clients don't handle "read raw" very well and actually
+In some cases clients don't handle <command>read raw</command> very well and actually
get lower performance using it than they get using the conventional
read operations.
</para>
<para>
-So you might like to try "read raw = no" and see what happens on your
+So you might like to try <command>read raw = no</command> and see what happens on your
network. It might lower, raise or not affect your performance. Only
testing can really tell.
</para>
<title>Write raw</title>
<para>
-The "write raw" operation is designed to be an optimised, low-latency
+The <command>write raw</command> operation is designed to be an optimised, low-latency
file write operation. A server may choose to not support it,
-however. and Samba makes support for "write raw" optional, with it
+however. and Samba makes support for <command>write raw</command> optional, with it
being enabled by default.
</para>
<para>
-Some machines may find "write raw" slower than normal write, in which
+Some machines may find <command>write raw</command> slower than normal write, in which
case you may wish to change this option.
</para>
</sect1>
-<sect1>
-<title>Slow Clients</title>
-
-<para>
-One person has reported that setting the protocol to COREPLUS rather
-than LANMAN2 gave a dramatic speed improvement (from 10k/s to 150k/s).
-</para>
-
-<para>
-I suspect that his PC's (386sx16 based) were asking for more data than
-they could chew. I suspect a similar speed could be had by setting
-"read raw = no" and "max xmit = 2048", instead of changing the
-protocol. Lowering the "read size" might also help.
-</para>
-
-</sect1>
-
<sect1>
<title>Slow Logins</title>
<para>
Slow logins are almost always due to the password checking time. Using
-the lowest practical "password level" will improve things a lot. You
-could also enable the "UFC crypt" option in the Makefile.
+the lowest practical <command>password level</command> will improve things.
</para>
</sect1>
<para>
Often a speed problem can be traced to the client. The client (for
example Windows for Workgroups) can often be tuned for better TCP
-performance.
-</para>
-
-<para>
-See your client docs for details. In particular, I have heard rumours
-that the WfWg options TCPWINDOWSIZE and TCPSEGMENTSIZE can have a
-large impact on performance.
-</para>
-
-<para>
-Also note that some people have found that setting DefaultRcvWindow in
-the [MSTCP] section of the SYSTEM.INI file under WfWg to 3072 gives a
-big improvement. I don't know why.
-</para>
-
-<para>
-My own experience wth DefaultRcvWindow is that I get much better
-performance with a large value (16384 or larger). Other people have
-reported that anything over 3072 slows things down enourmously. One
-person even reported a speed drop of a factor of 30 when he went from
-3072 to 8192. I don't know why.
-</para>
-
-<para>
-It probably depends a lot on your hardware, and the type of unix box
-you have at the other end of the link.
-</para>
-
-<para>
-Paul Cochrane has done some testing on client side tuning and come
-to the following conclusions:
-</para>
-
-<para>
-Install the W2setup.exe file from www.microsoft.com. This is an
-update for the winsock stack and utilities which improve performance.
-</para>
-
-<para>
-Configure the win95 TCPIP registry settings to give better
-perfomance. I use a program called MTUSPEED.exe which I got off the
-net. There are various other utilities of this type freely available.
-The setting which give the best performance for me are:
-</para>
-
-<orderedlist>
-<listitem><para>
-MaxMTU Remove
-</para></listitem>
-<listitem><para>
-RWIN Remove
-</para></listitem>
-<listitem><para>
-MTUAutoDiscover Disable
-</para></listitem>
-<listitem><para>
-MTUBlackHoleDetect Disable
-</para></listitem>
-<listitem><para>
-Time To Live Enabled
-</para></listitem>
-<listitem><para>
-Time To Live - HOPS 32
-</para></listitem>
-<listitem><para>
-NDI Cache Size 0
-</para></listitem>
-</orderedlist>
-
-<para>
-I tried virtually all of the items mentioned in the document and
-the only one which made a difference to me was the socket options. It
-turned out I was better off without any!!!!!
-</para>
-
-<para>
-In terms of overall speed of transfer, between various win95 clients
-and a DX2-66 20MB server with a crappy NE2000 compatible and old IDE
-drive (Kernel 2.0.30). The transfer rate was reasonable for 10 baseT.
-</para>
-
-<para>
-<programlisting>
-The figures are: Put Get
-P166 client 3Com card: 420-440kB/s 500-520kB/s
-P100 client 3Com card: 390-410kB/s 490-510kB/s
-DX4-75 client NE2000: 370-380kB/s 330-350kB/s
-</programlisting>
-</para>
-
-<para>
-I based these test on transfer two files a 4.5MB text file and a 15MB
-textfile. The results arn't bad considering the hardware Samba is
-running on. It's a crap machine!!!!
-</para>
-
-<para>
-The updates mentioned in 1 and 2 brought up the transfer rates from
-just over 100kB/s in some clients.
-</para>
-
-<para>
-A new client is a P333 connected via a 100MB/s card and hub. The
-transfer rates from this were good: 450-500kB/s on put and 600+kB/s
-on get.
-</para>
-
-<para>
-Looking at standard FTP throughput, Samba is a bit slower (100kB/s
-upwards). I suppose there is more going on in the samba protocol, but
-if it could get up to the rate of FTP the perfomance would be quite
-staggering.
+performance. Check the sections on the various clients in
+<link linkend="Other-Clients">Samba and Other Clients</link>.
</para>
</sect1>
Samba has been successfully installed at thousands of sites worldwide,
so maybe someone else has hit your problem and has overcome it. </para>
- <sect2>
- <title>Scope IDs</title>
-
- <para>By default Samba uses a blank scope ID. This means
- all your windows boxes must also have a blank scope ID.
- If you really want to use a non-blank scope ID then you will
- need to use the 'netbios scope' smb.conf option.
- All your PCs will need to have the same setting for
- this to work. I do not recommend scope IDs.</para>
- </sect2>
-
- <sect2>
- <title>Locking</title>
-
- <para>One area which sometimes causes trouble is locking.</para>
-
- <para>There are two types of locking which need to be
- performed by a SMB server. The first is "record locking"
- which allows a client to lock a range of bytes in a open file.
- The second is the "deny modes" that are specified when a file
- is open.</para>
-
- <para>Record locking semantics under Unix is very
- different from record locking under Windows. Versions
- of Samba before 2.2 have tried to use the native
- fcntl() unix system call to implement proper record
- locking between different Samba clients. This can not
- be fully correct due to several reasons. The simplest
- is the fact that a Windows client is allowed to lock a
- byte range up to 2^32 or 2^64, depending on the client
- OS. The unix locking only supports byte ranges up to
- 2^31. So it is not possible to correctly satisfy a
- lock request above 2^31. There are many more
- differences, too many to be listed here.</para>
-
- <para>Samba 2.2 and above implements record locking
- completely independent of the underlying unix
- system. If a byte range lock that the client requests
- happens to fall into the range 0-2^31, Samba hands
- this request down to the Unix system. All other locks
- can not be seen by unix anyway.</para>
-
- <para>Strictly a SMB server should check for locks before
- every read and write call on a file. Unfortunately with the
- way fcntl() works this can be slow and may overstress the
- rpc.lockd. It is also almost always unnecessary as clients
- are supposed to independently make locking calls before reads
- and writes anyway if locking is important to them. By default
- Samba only makes locking calls when explicitly asked
- to by a client, but if you set "strict locking = yes" then it will
- make lock checking calls on every read and write. </para>
-
- <para>You can also disable by range locking completely
- using "locking = no". This is useful for those shares that
- don't support locking or don't need it (such as cdroms). In
- this case Samba fakes the return codes of locking calls to
- tell clients that everything is OK.</para>
-
- <para>The second class of locking is the "deny modes". These
- are set by an application when it opens a file to determine
- what types of access should be allowed simultaneously with
- its open. A client may ask for DENY_NONE, DENY_READ, DENY_WRITE
- or DENY_ALL. There are also special compatibility modes called
- DENY_FCB and DENY_DOS.</para>
-
- <!-- FIXME: Sync this with oplocks.sgml -->
- </sect2>
</sect1>
</chapter>
<para>
The second item can be accomplished by using LDAP NSS and PAM modules. LGPL
versions of these libraries can be obtained from PADL Software
-(<ulink url="http://www.padl.com/">http://www.padl.com/</ulink>). However,
-the details of configuring these packages are beyond the scope of this document.
+(<ulink url="http://www.padl.com/">http://www.padl.com/</ulink>). More
+information about the configuration of these packages may be found at "LDAP,
+System Administration; Gerald Carter, O'Reilly; Chapter 6: Replacing NIS".
</para>
</sect2>
</para>
<para><programlisting>
-objectclass ( 1.3.1.5.1.4.1.7165.2.2.2 NAME 'sambaAccount' SUP top STRUCTURAL
+objectclass ( 1.3.1.5.1.4.1.7165.2.2.2 NAME 'sambaAccount' SUP top AUXILIARY
DESC 'Samba Account'
MUST ( uid $ rid )
MAY ( cn $ lmPassword $ ntPassword $ pwdLastSet $ logonTime $
##index gidNumber eq
##index cn eq
##index memberUid eq
+
+# (both fetched via ldapsearch):
+index primaryGroupID eq
+index displayName pres,eq
+
</programlisting></para>
</sect3>
<para>
The following parameters are available in smb.conf only with <parameter>--with-ldapsam</parameter>
-was included with compiling Samba.
+was included when compiling Samba.
</para>
<itemizedlist>
+ <listitem><para><ulink url="smb.conf.5.html#PASSDBBACKEND">passdb backend [ldapsam|ldapsam_nua]:url</ulink></para></listitem>
<listitem><para><ulink url="smb.conf.5.html#LDAPSSL">ldap ssl</ulink></para></listitem>
- <listitem><para><ulink url="smb.conf.5.html#LDAPSERVER">ldap server</ulink></para></listitem>
<listitem><para><ulink url="smb.conf.5.html#LDAPADMINDN">ldap admin dn</ulink></para></listitem>
<listitem><para><ulink url="smb.conf.5.html#LDAPSUFFIX">ldap suffix</ulink></para></listitem>
<listitem><para><ulink url="smb.conf.5.html#LDAPFILTER">ldap filter</ulink></para></listitem>
<listitem><para><ulink url="smb.conf.5.html#LDAPPORT">ldap port</ulink></para></listitem>
+ <listitem><para><ulink url="smb.conf.5.html#LDAPMACHINSUFFIX">ldap machine suffix</ulink></para></listitem>
+ <listitem><para><ulink url="smb.conf.5.html#LDAPUSERSUFFIX">ldap user suffix</ulink></para></listitem>
+ <listitem><para><ulink url="smb.conf.5.html#LDAPDELETEDN">ldap delete dn</ulink></para></listitem>
+
</itemizedlist>
<para>
# changes, this password will need to be reset.
ldap admin dn = "cn=Samba Manager,ou=people,dc=samba,dc=org"
- # specify the LDAP server's hostname (defaults to locahost)
- ldap server = ahab.samba.org
-
# Define the SSL option when connecting to the directory
# ('off', 'start tls', or 'on' (default))
ldap ssl = start tls
+ passdb backend ldapsam:ldap://ahab.samba.org
+
+ # smbpasswd -x delete the entire dn-entry
+ ldap delete dn = no
+
+ # the machine and user suffix added to the base suffix
+ # wrote WITHOUT quotes. NULL siffixes by default
+ ldap user suffix = ou=People
+ ldap machine suffix = ou=Systems
+
# define the port to use in the LDAP session (defaults to 636 when
# "ldap ssl = on")
ldap port = 389
<editor>&person.jht;</editor>
<editor>&person.jerry;</editor>
- <pubdate>Sunday 6 April</pubdate>
+ <pubdate>Monday April 21, 2003</pubdate>
<abstract>
<para>
This book is a collection of HOWTOs added to Samba documentation over the years.
-Samba is always under development, and so is it's documentation.
-The most recent version of this document
-can be found at <ulink url="http://www.samba.org/">http://www.samba.org/</ulink>
-on the "Documentation" page. Please send updates to <ulink
-url="mailto:jerry@samba.org">jerry@samba.org</ulink> or
-<ulink url="mailto:jelmer@samba.org">jelmer@samba.org</ulink>.
+Samba is always under development, and so is it's documentation. This release of the
+documentation represents a major revision or layout as well as contents.
+The most recent version of this document can be found at
+<ulink url="http://www.samba.org/">http://www.samba.org/</ulink>
+on the "Documentation" page. Please send updates to
+<ulink url="mailto:jelmer@samba.org">jelmer@samba.org</ulink>,
+<ulink url="mailto:jht@samba.org">jht@samba.org</ulink> or
+<ulink url="mailto:jerry@samba.org">jerry@samba.org</ulink>.
+</para>
+
+<para>
+The Samba-Team would like to express sincere thanks to the many people who have with
+or without their knowledge contributed to this update. The size and scope of this
+project would not have been possible without significant community contribution. A not
+insignificant number of ideas for inclusion (if not content itself) has been obtained
+from a number of Unofficial HOWTOs - to each such author a big "Thank-you" is also offered.
+Please keep publishing you Unofficial HOWTO's - they are a source of inspiration and
+application knowledge that is most to be desired by may Samba users and administrators.
</para>
</abstract>
<!-- Chapters -->
<part id="introduction">
-<title>General installation</title>
+<title>General Installation</title>
<partintro>
-<title>Introduction</title>
-<para>This part contains general info on how to install samba
+<title>Preparing Samba for Configuration</title>
+<para>This section of the Samba-HOWTO-Collection contains general info on how to install samba
and how to configure the parts of samba you will most likely need.
PLEASE read this.</para>
</partintro>
&IntroSMB;
&UNIX-INSTALL;
-&BROWSING-Quick;
-&Passdb;
</part>
<part id="type">
-<title>Type of installation</title>
+<title>Server Configuration Basics</title>
<partintro>
-<title>Introduction</title>
+<title>First Steps in Server Configuration</title>
<para>
-Samba can operate in various SMB networks. This part contains information on configuring samba
-for various environments.
+Samba can operate in various modes within SMB networks. This HOWTO section contains information on
+configuring samba to function as the type of server your network requires. Please read this
+section carefully.
</para>
</partintro>
&ServerType;
<part id="optional">
<title>Advanced Configuration</title>
<partintro>
-<title>Introduction</title>
-<para>Samba has several features that you might want or might not want to use. The chapters in this part each cover one specific feature.</para>
+<title>Valuable Nuts and Bolts Information</title>
+<para>
+Samba has several features that you might want or might not want to use. The chapters in this part each cover specific Samba features.
+</para>
</partintro>
+&NetworkBrowsing;
+&Passdb;
&NT-Security;
&GROUP-MAPPING-HOWTO;
&PRINTER-DRIVER2;
&VFS;
&MS-Dfs-Setup;
&IntegratingWithWindows;
-&BROWSING;
&SecuringSamba;
&unicode;
+&locking;
+</part>
+
+<part id="troubleshooting">
+<title>Troubleshooting</title>
+&Diagnosis;
+&problems;
+&BUGS;
</part>
<part id="Appendixes">
&Other-Clients;
&SWAT;
&SPEED;
-&Diagnosis;
-&problems;
-&BUGS;
-&MANUALPAGES;
</part>
</book>
<chapter id="unicode">
<chapterinfo>
&author.jelmer;
+ <author>
+ <firstname>TAKAHASHI</firstname><surname>Motonobu</surname>
+ <affiliation>
+ <address><email>monyo@home.monyo.com</email></address>
+ </affiliation>
+ </author>
<pubdate>25 March 2003</pubdate>
</chapterinfo>
</userinput>
</para>
</sect1>
+
+<sect1>
+<title>Japanese charsets</title>
+
+<para>Samba doesn't work correctly with Japanese charsets yet. Here are points of attention when setting it up:</para>
+
+<simplelist>
+<member>You should set <command>mangling method = hash</command></member>
+<member>There are various iconv() implementations around and not all of
+them work equally well. glibc2's iconv() has a critical problem in CP932.
+libiconv-1.8 works with CP932 but still has some problems and does not
+work with EUC-JP. </member>
+<member>You should set <command>dos charset = CP932</command>, not Shift_JIS, SJIS...</member>
+<member>Currently only <command>unix charset = CP932</command> will work (but still has some problems...) because of iconv() issues. <command>unix charset = EUC-JP</command> doesn't work well because of iconv() issues.</member>
+<member>Currently Samba 3.0 does not support <command>unix charset = UTF8-MAC/CAP/HEX/JIS*</command></member>
+</simplelist>
+
+<para>More information (in Japanese) is available at: <ulink url="http://www.atmarkit.co.jp/flinux/special/samba3/samba3a.html">http://www.atmarkit.co.jp/flinux/special/samba3/samba3a.html</ulink>.</para>
+</sect1>
+
</chapter>
<sect4>
<title>Solaris</title>
+<para>Winbind doesn't work on solaris 9, see the <link linkend="winbind-solaris9">Portability</link> chapter for details.</para>
+
<para>On solaris, you need to modify the
<filename>/etc/init.d/samba.server</filename> startup script. It usually
only starts smbd and nmbd but should now start winbindd too. If you
git.samba.org / ira / wip.git / commitdiff