[KLUG Members] Re: fs permissions with smb/nfs/ldap -- NIS + NFS/SambaDFS example

Bryan J. Smith members@kalamazoolinux.org
Sun, 13 Jan 2002 12:01:32 -0500


"Bryan J. Smith" wrote:
> If you have multiple servers, go ahead and use /server/bob,
> /server/mary, etc... as the actual server directory and client
> mountpoint.  You can then symlink various user home directories into
> /home/(user), etc...  There a few issues with symlinks, but they are
> usually manageable (as long as /etc/password or whatever their user
> record points to a real home directory that is not a symlink).

Being an old NIS guy, here's an example of what I do for NFS/Samba
networks.  I would eventually like to get to LDAP for this, possibly
integrating in Kerberos for tighter security as well as AFS for
failover.

SERVERS:

   Server 1:  Main, DNS/NIS pri/mas, smbpasswd orig
   Server 2:  Acct/Admin, DNS/NIS sec/slv, smbpasswd copy
   Server 3:  Engineering, DNS/NIS sec/slv, smbpasswd copy

I basically designate all my systems to be DNS/NIS servers, with one
that does little actual file serving as the primary/master, all others
as secondary/slaves.  I automate smbpasswd creation on one, and then
simply use NFS to distribute copies to all other systems (yes, I know
there is a way to get smbpasswd to distribute itself, but I cannot
figure it out).

SERVER DIRECTORIES:

I always try to group my users of the same "primary group" on the same
server.  Note this _can_ include more than one group on a server (like
accounting and administration on the same server), but I want to avoid
vice-versa (one group spread over multiple servers, I'll "sub-group"
instead).

   server2:/home/acc/(user)
   server2:/home/adm/(user)
   server3:/home/eng/(user)

I also create a "symlink share" called "all" on server1
[server1:/home/all/(user)->.../(group)/(user)], although it is _rarely_
used (and should *NOT* be used).  UNIX users should be using "~(user)"
instead of it, and Windows transparently use DFS (see below).

I just share out acc, adm and eng from each system directly.  If you
wanted to, you could do it on a per-user basis, but maintenance could
get tedious and doesn't improve security at all.

UNIX MOUNTING:

I put acc, adm and eng in an NIS automounter map.  On the local systems,
the "root" of this automounter map is at /home.  Again, if you wanted
to, you could automount each individual user (and make each "group"
their own automounter map at /home/(group)) but, again, that gets
tedious and really doesn't improve security at all.

Because of the automounter, accessing different servers is completely
transparent.

WINDOWS MOUNTING:

I highly recommend Samba 2.2 for the DFS (distributed filesystem)
capabilities.  DFS is not really DFS, but it *DOES* solve the issue with
mounts/symlinks between NFS mounts on NFS servers.

Before Samba 2.2 w/DFS support, if I had server3 (with /home/eng) also
mounting server2 (either /home/acc or /home/adm), and I had Samba just
share out /home (let's say a "read-only" share), unless I informed Samba
of my automounter map (which is a bit tricky, and one type isn't
supported), the SMB traffice would go client -> server3 -> server2 ->
server3 -> client.  That's less than ideal!  This is where DFS comes in.

   server1:/dfsroot

I create a directory called /dfsroot on server1.  All this share
contains is symlinks -- but "special" symlinks that are of significance
to Samba.  ;-P  They point to true Samba shares on servers 2 and 3. 
When a user accesses these "special" symlinks, Samba's DFS capabilities
complete pass off all the SMB traffic for the connection to the actual
server where the share is located.

Unlike UNIX, we don't the nice "transparent" directory mounting in
Windows.  So, thanks to DFS, my users just access their shares from
\\server1\(resource).  You may need to do a little "scripting" to
maintain the DFS symlinks, but it's not too terribly difficult.

-- Bryan

-- 
Bryan J. Smith, Engineer          mailto:b.j.smith@ieee.org
AbsoluteValue Systems, Inc.       http://www.linux-wlan.org
SmithConcepts, Inc.            http://www.SmithConcepts.com