>Are you the guy who reported to me to this list the problem
>with AFS backup?  If you are, let me know.  I am visiting
>AFS client development in April and will voice your complaint
>if I understand it.  Do you have a problem tracking number or PTF
>number for the problem?

In our AFS cell in every user directory there is a mountpoint called
$HOME/.OldFiles for the backup volume of the user reflecting a snapshot of
the user's directory and therefore containing almost all files/dirs a
second time. This is a common way in AFS world to provide users with an
interface to get back files they have casually deleted or damaged.

ADSM is not aware that .OldFiles is a mountpoint neither does the
specification in an exclude list prevent ADSM to run into .OldFiles. This
way all user directories are examined twice.

There are several other problems regarding AFS and ADSM. I have written
a few PMRs which I append to this letter. In February I have visited some
people of SSD at San Jose. We have discussed these topics. I assume you will
talk with the same guys. Although I mean it's very helpful if you bring up
these items again at your visit. Please let me know the results.

Thank you and good luck,
Werner

--
 ===========================================================================
 ===========================================================================
Werner Baur
Leibniz-Rechenzentrum     X.400:  S=Baur;OU=lrz;P=lrz-muenchen;A=d400;C=de
Barer Str. 21            RFC822:  Werner.Baur AT lrz-muenchen DOT de
D-80333 Muenchen           Tel.:  ++49-89-2105-8781
Germany                     Fax:  ++49-89-2809460
 ===========================================================================



PMR 4388x: AFS does not recognize AFS mountpoints

Authentication to ADSM from a Unix client is based on the password associated
with a node and the uid of the user. In case of password mode equals generate
the user does not even know the password. This provides a certain level
of security, if you have trusted clients. In an environment where a lot of
client workstation with many users are sharing the same node, this is a
security whole as everybody who succeeds to become root gains access to all
files of the node adn therefore of the cluster.

In case of AFS the situation becomes even worse: Because of other deficiencies
in ADSM we are forced to associate all AFS data to one single node.
Because access control is based on uid not on tokens, resp. Unix users not
AFS principals, the AFS security which represents a key feature of AFS
provided by the integrated kerberos server, is reduced to the standard unix
security which is a big step backwards.

PMR 4390x: ADSM cannot backup AFS volumes

ADSM cannot be used for backup of AFS volumes. ADSM does not save volume
header and mountpoint information, I can only backup files and ACLs.
This is not sufficient for desaster recovery. If a disk fails I can get
back the AFS files, but I cannot restore the volume structure.

A workaround could be to provide an interface to the native AFS
backup utility which allows to do volume backups by butc.

PMR 4391x: Exclude option does not exclude

The exclude option of the incl/excl-File of ADSM provides a way to exclude
files or subtrees from backup, but it does not prevent dsm traversing the
excluded subtree.
We need a way to definitely exclude that ADSM is running into a specified
subtree, for example an additional switch for the exclude option.

This feature gains special importance for the backup of the AFS tree:
At our site the AFS backup volume is mounted in the home directory of the user.
Files inside backup volumes are no candidates for ADSM backup,
they are excluded in the inclexcl list. Although ADSM runs through the
backup subtree considering several hundred thousands of files for election
in vain.

PMR 4394x: Sessions not kerberos authenticated

Authentication to ADSM from a Unix client is based on the password associated
with a node and the uid of the user. In case of password mode equals generate
the user does not even know the password. This provides a certain level
of security, if you have trusted clients. In an environment where a lot of
client workstation with many users are sharing the same node, this is a
security whole as everybody who succeeds to become root gains access to all
files of the node adn therefore of the cluster.

In case of AFS the situation becomes even worse: Because of other deficiencies
in ADSM we are forced to associate all AFS data to one single node.
Because access control is based on uid not on tokens, resp. Unix users not
AFS principals, the AFS security which represents a key feature of AFS
provided by the integrated kerberos server, is reduced to the standard unix
security which is a big step backwards.