"Local" data in home directories
jub at sun.com
Fri Nov 19 14:10:40 EET 2004
The recent discussion on home directories (and subdirectories) on this
list reminded me of an issue I have encountered repeately in recent times.
There are several occasions where I need a local place to store per-user
data. I'll explain what this mean and try present a suggestion how to
address this requirement.
Any comments are welcome.
"Local" here occurs in two different meanings:
(A) a physically "local" file system. The underlying requirement is that
this file system offers high performance. So a local disk would be nice
and NFS over a WAN would be undesirable.
(B) a "private" location that is unshareable between hosts.
These two meanings are related in that per-host storage is typically
placed so it can be accessed performantly from the host, and that
conversely the most performant and efficient file systems are often
those directly attached to a host, so they can easily be configured to
offer private storage.
In the FHS similar characteristics are typically needed for /var. But
/var is typically not writable for users. The closest approximation for
the desired semantics is probably offered by /var/tmp.
I need such a place for the following kinds of data:
1. user settings that are host specific (-> requires (B))
There are various preferences and other settings that are specific to a
certain host,site,architecture,etc.. This includes (but is not limited
to) settings involving absolute file pathes or that are related to the
identity or network location of the host.
Storing this data in a well-known location in the home directory breaks
scenarios where a NFS home directory is shared between hosts, archs and
2. local replicas/caches of user data and configuration that are
available on a large network or the internet (-> requires A)
This concerns e.g. application caches (e.g. of internet files). One
scenario which I encounter sufficiently often has a shared/networked
home directory, which is accessible widely but can be rather slow in
return. In such a case caching to that home directory misses the purpose
of the cache - namely to avoid the slow, inefficient network access for
repeated accesses. There may even be cases where I want be able to
create a local replica of something in the home directory to ensure fast
access. There are other cases where the slow resource is e.g. a databse
or LDAP server. Note that such replicas may not only be needed for
performance reasons, but also to enable offline operation.
3. A combination of 1. and 2.: data that is derived from a network
resource and modified in a host-specific way.
I don't have a good example of this yet, but I'm working on stuff that
needs this :-o
Only for (2) there is a usable place now, namely /var/tmp. But using the
'raw' /var/tmp has some problems of its own. Two that come to mind are
security and namespace. Every client dealing with user-specific data in
a world-writable location has to do things properly to maintain privacy
and security. And naming schemes that avoid collisions when multiple
users and applications are sharing such a space are difficult to find
and enforce. Additionally the requirements and schedules for occasional
deletion of temporary files of system-wide services from /var/tmp may
not apply to semi-temporary per-user data. For example, things that are
replicated for offline use should not simply be deleted. Thus mixing
these two categories in one location makes administering the location
harder. Summarizing: even in this case /var/tmp is not a good solution.
Some additional considerations:
- Many current applications don't distinguish properly between
user-specific data that should follow the user whereever she goes and
'local' data. But then this couldn't be done easily so far, because
suitable interfaces were not in place. Of course fixing all the
applications will take time, but we need a usable interface now just to
- Others apparently had similar requirements: MS Windows offers a
"LocalSettings" subdirectory in each user profile, which does not roam
with 'roaming profiles'.
- There needs to be a defined (dot-) location within $HOME that is
considered unsharable (between hosts, as defined in the FHS spec).
My preferred naming for this would be $HOME/.local. Unfortunately this
interferes with the XDG basedir spec. I would like to hear alternative
suggestions. I don't really like $HOME/.var, but it could be a last resort.
This location is the interface used by software that needs a location
for per-user data that either is unsharable (B) or that is performant
(A) and need not be shared.
- There is an optional unsharable directory in the file system
hierarchy, into which user-specific subdirectories should be placed. I
suggest using /var/users.
If this location is used, then $HOME/.local should be a link to the
corresponding subdirectory of /var/users (e.g. /var/users/$USER).
- There needs to be a tool to properly and securely set up the user
directories in /var/users (and the links). Probably this should be
hooked into useradd/usermod as an extra option. I haven't thought about
this very deeply yet, so I'm open for suggestions.
Conclusion: I am aware that my proposal should also be discussed on the
FHS lists. As all my requirements originate in the sphere of desktop
applications and as this interacts (or interferes?) with the XDG basedir
spec [*] I wanted to get some discussion here first.
[*] Unfortunately I could not recheck the basedir spec as I wrote this,
due to the site outage.
So all kinds of flames, comments and suggestions are welcome.
I'd appreciate to hear if other people have similar needs. I'd also be
glad to hear that another solution for my issues already exists or has
Joerg Barfurth Sun Microsystems - Desktop - Hamburg
>>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer joerg.barfurth at sun.com
OpenOffice.org Configuration http://util.openoffice.org
More information about the xdg