1
0
mirror of https://github.com/samba-team/samba.git synced 2025-01-08 21:18:16 +03:00

Another little edit. Still much more to be done.

(This used to be commit d6b8a8ab49)
This commit is contained in:
John Terpstra 2003-05-27 07:08:04 +00:00
parent b68e0b3aae
commit 6647e15cc7
5 changed files with 493 additions and 221 deletions

View File

@ -7,11 +7,30 @@
<title>Advanced Network Manangement</title>
<para>
This section attempts to document peripheral issues that are of great importance to network
This section documents peripheral issues that are of great importance to network
administrators who want to improve network resource access control, to automate the user
environment, and to make their lives a little easier.
</para>
<sect1>
<title>Features and Benefits</title>
<para>
Often the difference between a working network environment and a well appreciated one can
best be measured by the <emphasis>little things</emphasis> that makes everything work more
harmoniously. A key part of every network environment solution is the ability to remotely
manage MS Windows workstations, to remotely access the Samba server, to provide customised
logon scripts, as well as other house keeping activities that help to sustain more reliable
network operations.
</para>
<para>
This chapter presents information on each of these area. They are placed here, and not in
other chapters, for ease of reference.
</para>
</sect1>
<sect1>
<title>Remote Server Administration</title>
@ -47,6 +66,151 @@ from <ulink url="ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE">ftp://ft
</para>
</sect1>
<sect1>
<title>Remote Desktop Management</title>
<para>
There are a number of possible remote desktop management solutions that range from free
through costly. Do not let that put you off. Sometimes the most costly solutions is the
most cost effective. In any case, you will need to draw your own conclusions as to which
is the best tool in your network environment.
</para>
<sect2>
<title>Remote Management from NoMachines.Com</title>
<para>
The following information was posted to the Samba mailing list at Apr 3 23:33:50 GMT 2003.
It is presented in full (with author details omitted for privacy reasons).
<para>
<para>
<screen>
&gt; I have a wounderfull linux/samba server running as pdc for a network.
&gt; Now I would like to add remote desktop capabilites so that
&gt; users outside could login to the system and get their desktop up from
&gt; home or another country..
&gt;
&gt; Is there a way to acomplish this? Do I need a windows terminal server?
&gt; Do I need to configure it so that it is a member of the domain or a
&gt; BDC,PDC? Are there any hacks for MS Windows XP to enable remote login even if
&gt; the computer is in a domain?
&gt;
&gt; Any ideas/experience would be appreciated :)
</screen>
</para>
<para>
Answer provided: Check out the new offer from NoMachine, "NX" software:
<ulink url="http://www.nomachine.com/">http://www.nomachine.com/</ulink>.
</para>
<para>
It implements a very easy-to-use interface to the remote X protocol as
well as incorporating VNC/RFB and rdesktop/RDP into it, but at a speed
performance much better than anything you may have ever seen...
</para>
<para>
Remote X is not new at all -- but what they did achieve successfully is
a new way of compression and caching technologies which makes the thing
fast enough to run even over slow modem/ISDN connections.
</para>
<para>
I could testdrive their (public) RedHat machine in Italy, over a loaded
internet connection, with enabled thumbnail previews in KDE konqueror
which popped up immediately on "mouse-over". From inside that (remote X)
session I started a rdesktop session on another, a Windows XP machine.
To test the performance, I played Pinball. I am proud to announce here
that my score was 631750 points at first try...
</para>
<para>
NX performs better on my local LAN than any of the other "pure"
connection methods I am using from time to time: TightVNC, rdesktop or
remote X. It is even faster than a direct crosslink connection between
two nodes.
</para>
<para>
I even got sound playing from the remote X app to my local boxes, and
had a working "copy'n'paste" from an NX window (running a KDE session
in Italy) to my Mozilla mailing agent... These guys are certainly doing
something right!
</para>
<para>
I recommend to testdrive NX to anybody with a only a remote interest
in remote computing
<ulink url="http://www.nomachine.com/testdrive.php">http://www.nomachine.com/testdrive.php</ulink>.
</para>
<para>
Just download the free of charge client software (available for RedHat,
SuSE, Debian and Windows) and be up and running within 5 minutes (they
need to send you your account data, though, because you are assigned
a real Unix account on their testdrive.nomachine.com box...
</para>
<para>
They plan to get to the point were you can have NX application servers
running as a cluster of nodes, and users simply start an NX session locally,
and can select applications to run transparently (apps may even run on
another NX node, but pretend to be on the same as used for initial login,
because it displays in the same window.... well, you also can run it
fullscreen, and after a short time you forget that it is a remote session
at all).
</para>
<para>
Now the best thing at the end: all the core compression and caching
technologies are released under the GPL and available as source code
to anybody who wants to build on it! These technolgies are working,
albeit started from the command line only (and very inconvenient to
use in order to get a fully running remote X session up and running....)
</para>
<para>
To answer your questions:
</para>
<itemizedlist>
<listitem><para>
You don't need to install a terminal server; XP has RDP support built in.
</para></listitem>
<listitem><para>
NX is much cheaper than Citrix -- and comparable in performance, probably faster
</para></listitem>
<listitem><para>
You don't need to hack XP -- it just works
</para></listitem>
<listitem><para>
You log into the XP box from remote transparently (and I think there is no
need to change anything to get a connection, even if authentication is against a domain)
</para></listitem>
<listitem><para>
The NX core technologies are all Open Source and released under the GPL --
you can today use a (very inconvenient) commandline to use it at no cost,
but you can buy a comfortable (proprietary) NX GUI frontend for money
</para></listitem>
<listitem><para>
NoMachine are encouraging and offering help to OSS/Free Software implementations
for such a frontend too, even if it means competition to them (they have written
to this effect even to the LTSP, KDE and GNOME developer mailing lists)
</para></listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1>
<title>Network Logon Script Magic</title>
@ -181,4 +345,14 @@ See the documentation in the <ulink url="http://support.microsoft.com/default.as
</sect2>
</sect1>
<sect1>
<title>Common Errors</title>
<para>
Stuff goes here.
</para>
</sect1>
</chapter>

View File

@ -573,7 +573,7 @@ carelessness. Of course, noone is every deliberately careless!
</para>
<sect2>
<title>My Boomerang Won't Come Back<title>
<title>My Boomerang Won't Come Back</title>
<para>
Well, the real complaint said, "I can ping my samba server from Windows, but I can
@ -584,7 +584,7 @@ carelessness. Of course, noone is every deliberately careless!
The Windows machine was at IP Address 192.168.1.2 with netmask 255.255.255.0, the
Samba server (Linux) was at IP Address 192.168.1.130 with netmast 255.255.255.128.
The machines were on a local network with no external connections.
<para>
</para>
<para>
Due to inconsistent netmasks, the Windows machine was on network 192.168.1.0/24, while
@ -610,6 +610,67 @@ carelessness. Of course, noone is every deliberately careless!
</sect2>
<sect2>
<title>Samba server name change problem</title>
<para>
The name of the samba server was changed, samba was restarted, samba server can not be
pinged by new name from MS Windows NT4 Workstation, but it does still respond to ping using
the old name. Why?
</para>
<para>
From this description three (3) things are rather obvious:
</para>
<itemizedlist>
<listitem><para>WINS is NOT in use, only broadcast based name resolution is used</para></listitem>
<listitem><para>The samba server was renamed and restarted within the last 10-15 minutes</para></listitem>
<listitem><para>The old samba server name is still in the NetBIOS name cache on the MS Windows NT4 Workstation</para></listitem>
</itemizedlist>
<para>
To find what names are present in the NetBIOS name cache on the MS Windows NT4 machine,
open a cmd shell, then:
</para>
<para>
<screen>
C:\temp\&gt;nbtstat -n
NetBIOS Local Name Table
Name Type Status
------------------------------------------------
SLACK &lt;03&gt; UNIQUE Registered
ADMININSTRATOR &lt;03&gt; UNIQUE Registered
SLACK &lt;00&gt; UNIQUE Registered
SARDON &lt;00&gt; GROUP Registered
SLACK &lt;20&gt; UNIQUE Registered
SLACK &lt;1F&gt; UNIQUE Registered
C:\Temp\&gt;nbtstat -c
NetBIOS Remote Cache Name Table
Name Type Host Address Life [sec]
--------------------------------------------------------------
FRODO &lt;20&gt; UNIQUE 192.168.1.1 240
C:\Temp\&gt;
</screen>
</para>
<para>
In the above example, FRODO is the Samba server and SLACK is the MS Windows NT4 Workstation.
The first listing shows the contents of the Local Name Table (ie: Identity information on
the MS Windows workstation), the second shows the NetBIOS name in the NetBIOS name cache.
The name cache contains the remote machines known to this workstation.
</para>
</sect2>
</sect1>
</chapter>

View File

@ -9,19 +9,25 @@
<title>Stackable VFS modules</title>
<sect1>
<title>Introduction and configuration</title>
<title>Features and Benefits</title>
<para>
Since samba 3.0, samba supports stackable VFS(Virtual File System) modules.
Since Samba-3, there is support for stackable VFS(Virtual File System) modules.
Samba passes each request to access the unix file system thru the loaded VFS modules.
This chapter covers all the modules that come with the samba source and references to
some external modules.
</para>
</sect1>
<sect1>
<title>Discussion</title>
<para>
You may have problems to compile these modules, as shared libraries are
compiled and linked in different ways on different systems.
They currently have been tested against GNU/linux and IRIX.
If not supplied with your platform distribution binary Samba package you may have problems
to compile these modules, as shared libraries are compiled and linked in different ways
on different systems. They currently have been tested against GNU/Linux and IRIX.
</para>
<para>
@ -30,14 +36,14 @@ important parameter is the <command>vfs object</command> parameter which must po
the exact pathname of the shared library objects. For example, to log all access
to files and use a recycle bin:
<programlisting>
<screen>
[audit]
comment = Audited /data directory
path = /data
vfs object = /path/to/audit.so /path/to/recycle.so
writeable = yes
browseable = yes
</programlisting>
</screen>
</para>
<para>
@ -54,117 +60,135 @@ the Samba Developers Guide.
<sect1>
<title>Included modules</title>
<sect2>
<title>audit</title>
<para>A simple module to audit file access to the syslog
facility. The following operations are logged:
<simplelist>
<member>share</member>
<member>connect/disconnect</member>
<member>directory opens/create/remove</member>
<member>file open/close/rename/unlink/chmod</member>
</simplelist>
</para>
</sect2>
<sect2>
<title>audit</title>
<sect2>
<title>extd_audit</title>
<para>
This module is identical with the <emphasis>audit</emphasis> module above except
that it sends audit logs to both syslog as well as the smbd log file/s. The
loglevel for this module is set in the smb.conf file.
</para>
<para>
A simple module to audit file access to the syslog
facility. The following operations are logged:
<simplelist>
<member>share</member>
<member>connect/disconnect</member>
<member>directory opens/create/remove</member>
<member>file open/close/rename/unlink/chmod</member>
</simplelist>
</para>
<para>
The logging information that will be written to the smbd log file is controlled by
the <emphasis>log level</emphasis> parameter in <filename>smb.conf</filename>. The
following information will be recorded:
</para>
</sect2>
<table frame="all"><title>Extended Auditing Log Information</title>
<tgroup cols="2" align="center">
<thead>
<row><entry align="center">Log Level</entry><entry>Log Details - File and Directory Operations</entry></row>
</thead>
<tbody>
<row><entry align="center">0</entry><entry align="left">Creation / Deletion</entry></row>
<row><entry align="center">1</entry><entry align="left">Create / Delete / Rename / Permission Changes</entry></row>
<row><entry align="center">2</entry><entry align="left">Create / Delete / Rename / Perm Change / Open / Close</entry></row>
</tbody>
</tgroup>
</table>
<sect2>
<title>extd_audit</title>
</sect2>
<para>
This module is identical with the <emphasis>audit</emphasis> module above except
that it sends audit logs to both syslog as well as the smbd log file/s. The
loglevel for this module is set in the smb.conf file.
</para>
<sect2>
<title>recycle</title>
<para>
A recycle-bin like module. When used any unlink call
will be intercepted and files moved to the recycle
directory instead of being deleted.
</para>
<para>
The logging information that will be written to the smbd log file is controlled by
the <emphasis>log level</emphasis> parameter in <filename>smb.conf</filename>. The
following information will be recorded:
</para>
<para>Supported options:
<variablelist>
<varlistentry>
<term>vfs_recycle_bin:repository</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
<table frame="all"><title>Extended Auditing Log Information</title>
<tgroup cols="2" align="center">
<thead>
<row><entry align="center">Log Level</entry><entry>Log Details - File and Directory Operations</entry></row>
</thead>
<tbody>
<row><entry align="center">0</entry><entry align="left">Creation / Deletion</entry></row>
<row><entry align="center">1</entry><entry align="left">Create / Delete / Rename / Permission Changes</entry></row>
<row><entry align="center">2</entry><entry align="left">Create / Delete / Rename / Perm Change / Open / Close</entry></row>
</tbody>
</tgroup>
</table>
<varlistentry>
<term>vfs_recycle_bin:keeptree</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
<varlistentry>
<term>vfs_recycle_bin:versions</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
</sect2>
<varlistentry>
<term>vfs_recycle_bin:touch</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
<sect2>
<title>fake_perms</title>
<varlistentry>
<term>vfs_recycle_bin:maxsize</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
<para>
This module was created to allow Roaming Profile files and directories to be set (on the Samba server
under Unix) as read only. This module will if installed on the Profiles share will report to the client
that the Profile files and directories are writable. This satisfies the client even though the files
will never be overwritten as the client logs out or shuts down.
</para>
<varlistentry>
<term>vfs_recycle_bin:exclude</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
</sect2>
<varlistentry>
<term>vfs_recycle_bin:exclude_dir</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
<sect2>
<title>recycle</title>
<varlistentry>
<term>vfs_recycle_bin:noversions</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
</variablelist>
</para>
<para>
A recycle-bin like module. When used any unlink call
will be intercepted and files moved to the recycle
directory instead of being deleted.
</para>
</sect2>
<para>Supported options:
<variablelist>
<varlistentry>
<term>vfs_recycle_bin:repository</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
<sect2>
<title>netatalk</title>
<para>
A netatalk module, that will ease co-existence of samba and
netatalk file sharing services.
</para>
<varlistentry>
<term>vfs_recycle_bin:keeptree</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
<varlistentry>
<term>vfs_recycle_bin:versions</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
<para>Advantages compared to the old netatalk module:
<simplelist>
<member>it doesn't care about creating of .AppleDouble forks, just keeps them in sync</member>
<member>if share in smb.conf doesn't contain .AppleDouble item in hide or veto list, it will be added automatically</member>
</simplelist>
</para>
<varlistentry>
<term>vfs_recycle_bin:touch</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
</sect2>
<varlistentry>
<term>vfs_recycle_bin:maxsize</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
<varlistentry>
<term>vfs_recycle_bin:exclude</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
<varlistentry>
<term>vfs_recycle_bin:exclude_dir</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
<varlistentry>
<term>vfs_recycle_bin:noversions</term>
<listitem><para>FIXME</para></listitem>
</varlistentry>
</variablelist>
</para>
</sect2>
<sect2>
<title>netatalk</title>
<para>
A netatalk module, that will ease co-existence of samba and
netatalk file sharing services.
</para>
<para>Advantages compared to the old netatalk module:
<simplelist>
<member>it doesn't care about creating of .AppleDouble forks, just keeps them in sync</member>
<member>if share in smb.conf doesn't contain .AppleDouble item in hide or veto list, it will be added automatically</member>
</simplelist>
</para>
</sect2>
</sect1>
@ -183,48 +207,56 @@ No statemets about the stability or functionality of any module
should be implied due to its presence here.
</para>
<sect2>
<title>DatabaseFS</title>
<sect2>
<title>DatabaseFS</title>
<para>
URL: <ulink url="http://www.css.tayloru.edu/~elorimer/databasefs/index.php">http://www.css.tayloru.edu/~elorimer/databasefs/index.php</ulink>
</para>
<para>
URL: <ulink url="http://www.css.tayloru.edu/~elorimer/databasefs/index.php">http://www.css.tayloru.edu/~elorimer/databasefs/index.php</ulink>
</para>
<para>By <ulink url="mailto:elorimer@css.tayloru.edu">Eric Lorimer</ulink>.</para>
<para>By <ulink url="mailto:elorimer@css.tayloru.edu">Eric Lorimer</ulink>.</para>
<para>
I have created a VFS module which implements a fairly complete read-only
filesystem. It presents information from a database as a filesystem in
a modular and generic way to allow different databases to be used
(originally designed for organizing MP3s under directories such as
"Artists," "Song Keywords," etc... I have since applied it to a student
roster database very easily). The directory structure is stored in the
database itself and the module makes no assumptions about the database
structure beyond the table it requires to run.
</para>
<para>
I have created a VFS module which implements a fairly complete read-only
filesystem. It presents information from a database as a filesystem in
a modular and generic way to allow different databases to be used
(originally designed for organizing MP3s under directories such as
"Artists," "Song Keywords," etc... I have since applied it to a student
roster database very easily). The directory structure is stored in the
database itself and the module makes no assumptions about the database
structure beyond the table it requires to run.
</para>
<para>
Any feedback would be appreciated: comments, suggestions, patches,
etc... If nothing else, hopefully it might prove useful for someone
else who wishes to create a virtual filesystem.
</para>
<para>
Any feedback would be appreciated: comments, suggestions, patches,
etc... If nothing else, hopefully it might prove useful for someone
else who wishes to create a virtual filesystem.
</para>
</sect2>
</sect2>
<sect2>
<title>vscan</title>
<para>URL: <ulink url="http://www.openantivirus.org/">http://www.openantivirus.org/</ulink></para>
<sect2>
<title>vscan</title>
<para>
samba-vscan is a proof-of-concept module for Samba, which
uses the VFS (virtual file system) features of Samba 2.2.x/3.0
alphaX. Of couse, Samba has to be compiled with VFS support.
samba-vscan supports various virus scanners and is maintained
by Rainer Link.
</para>
<para>URL: <ulink url="http://www.openantivirus.org/">http://www.openantivirus.org/</ulink></para>
</sect2>
<para>
samba-vscan is a proof-of-concept module for Samba, which
uses the VFS (virtual file system) features of Samba 2.2.x/3.0
alphaX. Of couse, Samba has to be compiled with VFS support.
samba-vscan supports various virus scanners and is maintained
by Rainer Link.
</para>
</sect2>
</sect1>
<sect1>
<title>Common Errors</title>
<para>
There must be some gotchas we should record here! Jelmer???
</para>
</sect1>
</chapter>

View File

@ -14,103 +14,108 @@
<pubdate>12 Jul 2000</pubdate>
</chapterinfo>
<title>Hosting a Microsoft Distributed File System tree on Samba</title>
<sect1>
<title>Features and Benefits</title>
<title>Instructions</title>
<para>
The Distributed File System (or DFS) provides a means of separating the logical
view of files and directories that users see from the actual physical locations
of these resources on the network. It allows for higher availability, smoother
storage expansion, load balancing etc.
</para>
<para>The Distributed File System (or Dfs) provides a means of
separating the logical view of files and directories that users
see from the actual physical locations of these resources on the
network. It allows for higher availability, smoother storage expansion,
load balancing etc. For more information about Dfs, refer to <ulink
url="http://www.microsoft.com/NTServer/nts/downloads/winfeatures/NTSDistrFile/AdminGuide.asp">
Microsoft documentation</ulink>. </para>
<para>
For information about DFS, refer to
<ulink url="http://www.microsoft.com/NTServer/nts/downloads/winfeatures/NTSDistrFile/AdminGuide.asp">
Microsoft documentation at http://www.microsoft.com/NTServer/nts/downloads/winfeatures/NTSDistrFile/AdminGuide.asp</ulink>.
</para>
<para>This document explains how to host a Dfs tree on a Unix
machine (for Dfs-aware clients to browse) using Samba.</para>
<para>
This document explains how to host a DFS tree on a Unix machine (for DFS-aware
clients to browse) using Samba.
</para>
<para>To enable SMB-based DFS for Samba, configure it with the
<parameter>--with-msdfs</parameter> option. Once built, a
Samba server can be made a Dfs server by setting the global
boolean <ulink url="smb.conf.5.html#HOSTMSDFS"><parameter>
host msdfs</parameter></ulink> parameter in the <filename>smb.conf
</filename> file. You designate a share as a Dfs root using the share
level boolean <ulink url="smb.conf.5.html#MSDFSROOT"><parameter>
msdfs root</parameter></ulink> parameter. A Dfs root directory on
Samba hosts Dfs links in the form of symbolic links that point
to other servers. For example, a symbolic link
<filename>junction-&gt;msdfs:storage1\share1</filename> in
the share directory acts as the Dfs junction. When Dfs-aware
clients attempt to access the junction link, they are redirected
to the storage location (in this case, \\storage1\share1).</para>
<para>
To enable SMB-based DFS for Samba, configure it with the <parameter>--with-msdfs</parameter>
option. Once built, a Samba server can be made a DFS server by setting the global
boolean <ulink url="smb.conf.5.html#HOSTMSDFS"><parameter> host msdfs</parameter></ulink>
parameter in the <filename>smb.conf </filename> file. You designate a share as a DFS
root using the share level boolean <ulink url="smb.conf.5.html#MSDFSROOT"><parameter>
msdfs root</parameter></ulink> parameter. A DFS root directory on Samba hosts DFS
links in the form of symbolic links that point to other servers. For example, a symbolic link
<filename>junction-&gt;msdfs:storage1\share1</filename> in the share directory acts
as the DFS junction. When DFS-aware clients attempt to access the junction link,
they are redirected to the storage location (in this case, \\storage1\share1).
</para>
<para>Dfs trees on Samba work with all Dfs-aware clients ranging
from Windows 95 to 2000.</para>
<para>
DFS trees on Samba work with all DFS-aware clients ranging from Windows 95 to 200x.
</para>
<para>Here's an example of setting up a Dfs tree on a Samba
server.</para>
<para>
Here's an example of setting up a DFS tree on a Samba server.
</para>
<para><programlisting>
<para><screen>
# The smb.conf file:
[global]
netbios name = SAMBA
netbios name = SMOKEY
host msdfs = yes
[dfs]
path = /export/dfsroot
msdfs root = yes
</programlisting></para>
</screen></para>
<para>
In the /export/dfsroot directory we set up our dfs links to other servers on the network.
</para>
<para>In the /export/dfsroot directory we set up our dfs links to
other servers on the network.</para>
<para><prompt>root# </prompt><userinput>cd /export/dfsroot</userinput></para>
<para><prompt>root# </prompt><userinput>chown root /export/dfsroot</userinput></para>
<para><prompt>root# </prompt><userinput>chmod 755 /export/dfsroot</userinput></para>
<para><prompt>root# </prompt><userinput>ln -s msdfs:storageA\\shareA linka</userinput></para>
<para><prompt>root# </prompt><userinput>ln -s msdfs:serverB\\share,serverC\\share linkb</userinput></para>
<para>
<screen>
&rootprompt;<userinput>cd /export/dfsroot</userinput>
&rootprompt;<userinput>chown root /export/dfsroot</userinput>
&rootprompt;<userinput>chmod 755 /export/dfsroot</userinput>
&rootprompt;<userinput>ln -s msdfs:storageA\\shareA linka</userinput>
&rootprompt;<userinput>ln -s msdfs:serverB\\share,serverC\\share linkb</userinput>
</screen>
</para>
<para>You should set up the permissions and ownership of
the directory acting as the Dfs root such that only designated
the directory acting as the DFS root such that only designated
users can create, delete or modify the msdfs links. Also note
that symlink names should be all lowercase. This limitation exists
to have Samba avoid trying all the case combinations to get at
the link name. Finally set up the symbolic links to point to the
network shares you want, and start Samba.</para>
<para>Users on Dfs-aware clients can now browse the Dfs tree
<para>Users on DFS-aware clients can now browse the DFS tree
on the Samba server at \\samba\dfs. Accessing
links linka or linkb (which appear as directories to the client)
takes users directly to the appropriate shares on the network.</para>
<sect2>
<title>Notes</title>
<itemizedlist>
<listitem><para>Windows clients need to be rebooted
if a previously mounted non-dfs share is made a dfs
root or vice versa. A better way is to introduce a
new share and make it the dfs root.</para>
</listitem>
<listitem><para>Currently there's a restriction that msdfs
symlink names should all be lowercase.</para>
</listitem>
<listitem><para>For security purposes, the directory
acting as the root of the Dfs tree should have ownership
and permissions set so that only designated users can
modify the symbolic links in the directory.</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1>
<title>Common Errors</title>
<itemizedlist>
<listitem><para>Windows clients need to be rebooted
if a previously mounted non-dfs share is made a dfs
root or vice versa. A better way is to introduce a
new share and make it the dfs root.</para>
</listitem>
<listitem><para>Currently there's a restriction that msdfs
symlink names should all be lowercase.</para>
</listitem>
<listitem><para>For security purposes, the directory
acting as the root of the DFS tree should have ownership
and permissions set so that only designated users can
modify the symbolic links in the directory.</para>
</listitem>
</itemizedlist>
</sect1>
</chapter>

View File

@ -18,6 +18,7 @@
</affiliation>
</author>
&author.jelmer;
&author.jht;
</authorgroup>
<pubdate>27 June 2002</pubdate>
</chapterinfo>
@ -25,7 +26,7 @@
<title>Unified Logons between Windows NT and UNIX using Winbind</title>
<sect1>
<title>Abstract</title>
<title>Features and Benefits</title>
<para>Integration of UNIX and Microsoft Windows NT through
a unified logon has been considered a "holy grail" in heterogeneous
@ -337,8 +338,8 @@ the winbind services which come with SAMBA 3.0.
<title>Introduction</title>
<para>
This HOWTO describes the procedures used to get winbind up and
running on my RedHat 7.1 system. Winbind is capable of providing access
This section describes the procedures used to get winbind up and
running on a RedHat 7.1 system. Winbind is capable of providing access
and authentication control for Windows Domain users through an NT
or Win2K PDC for 'regular' services, such as telnet a nd ftp, as
well for SAMBA services.
@ -1124,7 +1125,19 @@ configured in the pam.conf.
</sect1>
<sect1>
<title>Limitations</title>
<title>Conclusion</title>
<para>The winbind system, through the use of the Name Service
Switch, Pluggable Authentication Modules, and appropriate
Microsoft RPC calls have allowed us to provide seamless
integration of Microsoft Windows NT domain users on a
UNIX system. The result is a great reduction in the administrative
cost of running a mixed UNIX and NT network.</para>
</sect1>
<sect1>
<title>Common Errors</title>
<para>Winbind has a number of limitations in its current
released version that we hope to overcome in future
@ -1153,17 +1166,4 @@ configured in the pam.conf.
</itemizedlist>
</sect1>
<sect1>
<title>Conclusion</title>
<para>The winbind system, through the use of the Name Service
Switch, Pluggable Authentication Modules, and appropriate
Microsoft RPC calls have allowed us to provide seamless
integration of Microsoft Windows NT domain users on a
UNIX system. The result is a great reduction in the administrative
cost of running a mixed UNIX and NT network.</para>
</sect1>
</chapter>