On 5/4/2016 10:29 PM, Benjamin Kaduk wrote: > On Wed, 16 Mar 2016, Nicolas Melot wrote: > >> Hi, >> >> I'm trying to setup and use openafs for mobile nodes, not always having a >> connection to the openAFS server. I would like to use the openAFS caching >> mechanism as an offline disk that synchronizes everything once online again. >> >> I installed an openAFS 1.6.9 server and client, together with a kerberos >> server on debian jessie. Everything works great, including offline operations >> and synch after the client is back online. However, I fail of open a afs >> session on the client machine while it is offline. To rule out a lack of >> kerberos ticket, I installed a kerberos replica on the client machine and I >> can get a ticket offline. However, even with a valid ticket, AFS's cache >> manager doesn't give access to the files. >> >> Investigating more and reading the doc, my understanding is that the cache >> manager doesn't look for anything to confirm the authorization granted by the >> kerberos ticket presented. However, I still fail to open an AFS session with >> an offline machine. I think this is because the cache manager requests >> information from the protection database (I guess some kind of ACLs) and >> since >> it can't contact it, then it doesn't give access to files at all. > > This is not exactly true; in normal operation, it is the fileserver that > consults the protection database and determines whether a user is > authorized to access a given resource.
More to the point. The cache manager doesn't have any access to the Access Control List data. All the cache manager has is the set of permissions that were granted to a particular AFS token. If that token was associated with a particular local uid then the cache manager in the absence of an AFS token or connectivity to a file server *might* be configured to continue to offer access to the data by that particular uid. If the token was obtained with an arbitrary Process Authentication Group and that PAG no longer exists, there is nothing for the cache manager to use in deciding what permissions to grant. >> In a desperate attempt to reach my goal, I started to set up at protection >> database replication into the client and see what happens.. well, it looks >> like I need to identify protection database server (including the replication >> installed in my client machine) with ip addresses. The problem is that both >> databases (the original and replica) check if the ip address of machines are >> the same in both ends before allowing a replication to happen. That means I >> can't configure the client so it connects to 127.0.0.1, which would be the >> only way t contact the local protection database when offline, so this >> solution doesn't seem to work either. > > I don't think that having a local protection database is a fruitful area > of research; the ubik database synchronization protocol is not really > scalable, and is generally used with only 3 or 5 peers. (There is also a > hard cap in the current implementation, which might be 16; I forget the > exact number.) The protection database contains the memberships of groups and the mapping of user names and group names to ID numbers that are stored in the Access Control Entries. The protection database doesn't store any of the ACL data. The ACL data is private metadata stored on the file server and is not exposed to the cache manager. Therefore, there is no benefit to local copies of this data. >> Then, finally my question (s): is it possible at all to have openafs working >> in offline mode, including opening a session, even if I need to run a >> Kerberos >> and a protection database replica on the client for it (even if that sounds >> like a bad idea). Is it possible to prevent the original and the replica >> protection databases from checking if the ip addresses are the same, so that >> I >> can have the client machine to contact its local replica of the protection >> database on 127.0.0.1 and the original protection database server to contact >> the replica through its ip address on the network; better: through its dns >> name only. > > I think what you want would require further development on the offline > mode, which in its current state remains an experimental feature but has > not seen any significant resources invested in it for several years. > > I do not have an estimate for the amount of work that would be necessary, > but will say that I expect it to be measured in man-years. There are two broad sets of problems that must be designed for before disconnected mode can be truly functional: 1. What are the access control semantics of offline usage? The Windows offline mode for CIFS provides a local disk per user cache of the files and directories that are to be available offline. As long as the local copy is being used the user has full permissions on the file regardless of what the network permissions were. The network permissions only matter when an attempt to sync changes back to the network occurs. The cloud file services (Dropbox, OneDrive, ...) also work on whole files and do not worry about the network permissions except when storing changes back to the network. This model is inconsistent with the present day behavior of the AFS cache manager which caches partial file ranges and assumes file system semantics and not whole file copy & sync semantics. 2. User interface issues There must be some mechanism for deciding when sets of files, directories, directory trees, and/or whole volumes should be pinned to the cache. This mechanism will require some form of interaction with the OS file browser/explorer. There will also need to be some user interface to decide what should be done when a merge conflict occurs. I agree with the person-years estimate. Jeffrey Altman
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
