Reservoir Setup

Since the ARPA2 authentication infrastructure is based on Kerberos5, the integration between OpenAFS and the identity provider for a realm, or user domain, is trivial. Any newly created users are immediately available for use in the Reservoir.

Administrators can assign parts of the Reservoir storage space to users, may impose size restrictions, and users may open parts of their storage space to other users if they choose to. This provides an excellent basis for collaborative work on documents.

On the Desktop

Any desktop, laptop or even tablet can be setup with access to the Reservoir portion of any given user. To do this, it needs client software; the most direct is to use OpenAFS, but Reservoir also has an SMB wrapper to permit users to access files, which is in many cases possible without even installing software!

What is required for access control, is that the machine logs on using Kerberos5; this is already installed on many platforms, and is an easy extension on others. Kerberos5 is a system for single sign-on; this means that a login is only needed once per period; it is common to require a daily login and have everything else follow from that automatically. So this is clearly useful software to have on board, and to get used to. ARPA2 uses this mechanism throughout, as a replacement for the nuisance and insecurity of most password-based mechanisms.

After Kerberos5 login, the client can now access the storage space of the Reservoir, cache items locally and have them transmitted to the file server automatically. Everything acts just like a local filesystem, so locally started document processing tools can be used to edit documents, and so on.

In comparison to cloud-based storage, the pure filesystem approach of Reservoir is advantageous through things like locking; if your program ensures through locking that you cannot edit the same document twice, then it will do the same accross the multiple points of presence of the OpenAFS filesystem of Reservoir. This means that others can edit your documents, but not at the same time as you. There are bound to be more advantages from the more direct approach of Reservoir.

Web Accessible Documents

There exist web frameworks for editing all sorts of documents; for instance, WebODF can edit the same documents that are locally processed with LibreOffice. The difference is that WebODF comes as a browser application and does not require installtion of software. It can be very useful on mobile devices or machines that are only used temporarily.

Consider a service provider, or a component in an ARPA2 domain infrastructure, who offers such WebODF facilities. Or perhaps you simply set it up on your webserver. In either case, you will have a web address to go to.

Upon entry to the website, you need to login. This can be done using any of the web mechanisms; on account of its support for single sign-on and its sublime security properties, the ARPA2 advise is to use TLS-KDH for that. The web environment can use this to obtain a Kerberos5 ticket that it can use in your name.

The web environment should have the Reservoir mounted through an OpenAFS client, which means the same as on the desktop -- local caches, full file system access, and support for advanced facilities such as distributed locks on documents. The web environment can use the Kerberos5 ticket that it got in your name to access the Reservoir in your name. This means that it can do what you are able to do, so the files shown through the web interface are the same ones you could access on your desktop, and whether you can write to them or in what directories you can add new documents is also the same.

Collaborative Editing

As a final way to approach your documents, you might even consider a collaborative editor; this is a system, often run in a web environment, that permits multiple users to edit the same document, and see each other make modifications. The system integrates the edits and shows each participant a live view on the developing document. As a wild example, such systems have been used by attendees of lectures for live note-taking!

The locking mentioned above aims to prevents simultaneous access to documents as a protection of overwriting one person's work with that of another who was working at the same time. This would also apply between a collaborative editor and a desktop editor accessing the same document; but the collaborative editor is able to merge changes live, thanks to offering an interaction with a user working on a displayed document rather than working at the filesystem level.

The resulting setup permits many OpenAFS clients, each doing their thing to the document collection, but locks can be used to avoid that they interfere at the document level; higher up there can be a plethora of facilities to make life easier on users than a mere storage server could do. The trick however, is that Reservoir is clever enough as a storage system to support these higher layers without interference.