[OpenAFS-devel] Re: on sockets and devices in AFS

[Derrick Brashear]

On Sep 20, 2010, at 10:04 AM, Rune <u-openafsdev-t07O@aetey.se> wrote:

> Hi Chas,
>=20
> On Sat, Sep 18, 2010 at 07:09:58PM -0400, Chas Williams (CONTRACTOR) wrote=
:
>> In message <4C93A15E.4070708@secure-endpoints.com>,Jeffrey Altman writes:=

>>> I believe that the proper behavior for today's
>>> clients is to maintain the object locally and mask it from the file
>>> server.
>=20
>> like i said before i am not sure this is a good idea.  for instance,
>> google chrome creates a named socket in your home directory in
>> .config/google-chrome.   if you run chrome again on another machine so
>> google chrome might think that no one else is using that .config director=
y
>> since named sockets are only maintained locally.  but the other files in
>> .config/google-chrome would appear to be global.  this is inconsistent
>> and possibly confusing to an application.
>=20
> The problem is not the file system but the applications. They are not
> expecting home directories being shared, even less expecting them
> to be global (i.e. not obeying the local *nix uig/gid space, possibly not
> being exactly in sync on different hosts).
>=20
> Naturally application-specific local sockets should be created in a
> local user-specific directory (not /tmp as it is open for attacks) -
> but the *nix tradition unfortunately does not offer such a directory.
>=20
> Some distros may use pam_tmpdir or alike which set up TMPDIR in the right w=
ay
> (isolated between users) but this is not standard.
>=20

and things also hardcore and don't use TMPDIR in many cases

> (Of course the presence of the sockets should never be used for "locking"
> either...)
>=20
> Unfortunately a lot of design of "desktop"-applications is modelled after
> Windows, which translates to "a single host", and then after single-host U=
nix
> which implied "local home directories".
>=20
> No such application I know of (an application maintaning its state like
> the list of visited files or the preferences) is capable of gracefully
> handling multiple instances of itself running on different hosts sharing
> the users's home directory with delayed replication (like disconnected
> mode).
>=20
> So, they will lose no matter what, unless a nice
> "persistent-state-with-lock-free-asynchronous-updates"-library would
> be written and used by the applications, implementing transaction-like
> updates with automated merges - taking into account the semantics of
> the data to be merged. Alas, such a library does not yet exist (or at
> least apparently is not being used :)
>=20
> [as a side note, Coda file system provides hooks to support
> application-specific conflict resolution and automated merges, which
> may be a right idea of where to put the corresponding intelligence -
> or may be not?..]
>=20

I wrote one in perl (4!) many years ago. no one seemed overly interested in t=
he concept. There is room in OpenAFS several places for this sort of 'decisi=
on engine'

> As a result:
>=20
> according to my experience, letting applications to be unaware of their
> multiple instances may certainly lead to corruptions but most of the
> time it makes them work better than otherwise.
>=20

Coming around a bit, this proposal was seasoned by Wolfgang Gehrke's talk on=
 booting from AFS at the European AFS Conference which has just passed, rath=
er than the 'how can I corrupt my browser cache' idea=