Petit texte (en anglais) avec quelques pistes vers quelques outils et
concepts quand il s'agit de mettre en oeuvre une aborescence r�seau:
1. Introduction to the UNIX paradigm of file sharing
Most today computer users have a notion of `the network', this magic
entity that links computers together and sometimes fails to work
properly.
There are however two paradigms that evolved differently:
The UNIX paradigm is more that every computer is a multiuser machine
and that all files are to be available within a namespace, independant
from machine names. This usually requires one or more file servers.
For example, you can implement a network with one file servers
and 10 workstations, where every workstation and server has
a /home directory that contains all the users of the system.
Each user has a subdirectory in this namespace, and users can
navigate into other's directories, providing permissions allow so.
On the server, /home is really located on a UNIX filesystem
on a physical drive. On the clients, /home is a NFS mount from
the server. NFS is a filesystem that supports most of the POSIX
features of usual UNIX filesystems, including UNIX permissions.
NFS is mostly stateless: the server can crash or reboot without
the clients making the difference between a slow server, a broken
network cable, or a server crash.
User names are known to the server, and login verifies that the
password is correct, using either a centrally maintained database,
or a local copy of it (the latter being LDAP, NIS, NIS+ or Kerberos;
the former a rsync or scp of /etc/passwd, shadow, group, and gshadow).
UIDs and GIDs will normally be uniform if tricks want to be avoided.
Users will never mount filesystems (namespaces) themselves: those are
either hard-mounted during the workstation boot process, or automounted
using `on-demand' mounting.
The standard version of NFS (using normal RPC) is very insecure:
all operations are done in clear, there isn't any protection against
replay attacks, and authentification is basically client-side.
All this doesn't map well to a network of mixed UNIX/non UNIX systems,
or a network where the UNIX root password is widely known. Some
very poor security mechanisms (root_squash) will mildly help, but
in general don't assume NFS is inherently secure -- some implementations
are however worse that others.
There exist newer versions of NFS/RPC that are much better in term
of authentification.
The `user' paradigm (we will call it like this) is that every user
decides what it sees from the network, and directly accesses namespaces
by using, in general, machine names. The pure `user' paradigm doesn't
require servers.
Users will have to mount the namespaces they have access to manually,
in `login scripts', or using a simplified GUI that browses through
the available resources.
No uniformity in the namespace will be ensured, unless explicitely
enforced (and unless the users can't `map shares' or `browse the
network' you can't really enforce this).
There are variations of course, and it is possible to tweak the UNIX
paradigm to more ressemble the `user' paradigm, but the countrary is
nearly impossible, except maybe in the surface.
2. The automounter concept
The automounter, developped initially on BSD/UNIX, and whose name is usually
`autofs' on Linux, has the following goals:
- allows to handle much better than stock NFS hard/soft mounts the cases
of server failures.
The automounter will not mount directory that aren't used, and
will dismount currently unused directories after a timeout. Thus
a `df' command (and others) won't hang because of a rarely used
imported filesystem.
- will diminush the load on the server (this is probably more relevant
in the case of SMB filesystems, than in NFS because it uses UDP and
is mostly stateless).
- can use NIS to be configured.
- can also be used to do tricks such as automatic floppy mount/umount.
- allows to host a namespace on more than one server.
Some automount versions will even select the less loaded server
to mount it.
Beware that this only works for read-only namespaces: NFS in itself
doesn't include support for replication!
The obvious disadvantages of the automounter are that you can no
longer `ls' around to find out what is available, you need to access
it, and that sometimes it will take some time to access an automounted
directory, because a mount must be done. You can simulate a complete
environment by using symlinks, however that's not the point of it,
especially since some software could dereferences the symlink and
activate the mounting.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
