That's the best I could do for the subject line. Apologies if it doesn't
convey the idea properly.
Symptoms:
We have two (database and file)-servers in one building and one in
another. When the network between the two buildings fails, users in
the second building cannot access AFS volumes.
One of the main reasons we use AFS is to provide redundancy in exactly
this sort of situation. To circumvent this behavior, we would have to
provide every workstation in the second building with a resident copy
of all necessary files. Avoiding this kind of thing is another of the
main reasons we use AFS.
Cause (I think):
When the network partitions, the servers try to reestablish a "sync
site". In the above situation, the sync site ends up being in the
first building. If a database server is unable to communicate with a
sync site, it prohibits _both_ write _and_ read access to the databases.
The logic behind prohibiting write access is fairly obvious. The
logic behind prohibiting read access is that someone could take
advantage of the inability to propagate database changes
(e.g. disabling an account) from the sync site to the isolated server.
Thus, allowing read access to the databases under these circumstances
constitutes a security hole.
My contention is that in an environment where things like 'rlogin -l
-froot' go undetected for years, security holes like the above are a
non-problem.
I propose that the database server policy be changed so that a system
administrator can optionally configure a server to allow read access
to server databases when communication with the sync site is broken.
I would like to hear how other AFS sites have dealt with this problem.
-Rick
--
|Rick Cochran 607-255-7223|
|Cornell Materials Science Center [EMAIL PROTECTED]|
|E20 Clark Hall, Ithaca, N.Y. 14853 cornell!msc.cornell.edu!rick|
