Re: gconfd errors w/nfs mounted homedirs

[seth vidal <skvidal phy duke edu>]

> Well, basically because evolution, sawfish, and anything else that has
> multiple things writing to the same config file without locking causes
> corruption!  There's no way I'd use two copies of evolution pointing
> to the same directory at once.
> 

I understand that - but most users, me included, do not think of
"logging in" as something that involves a config file change.

> You can usually get away with it in simple cases where configuration
> is saved only when the user requests it explicitily, but once you have
> complicatd situations, with lots of updates, things _will_ break.
> 

break how? Will the files become unusable or will users get unexpected
results? Why can my users login to kde on multiple systems w/o things
breaking? I've got about 75-100 users logging into systems all day long
and I've never had things "break" before,  is it the "Every login is a
config change" that is causing things to break now?

> If you are willing to give up change notification (and change
> notification on config keys is proving to be one of the really cool
> features of the GNOME-2.0 desktop), then you probably can get away
> with a Berkeley DB style on disk database. But the gconfd approach is
> a lot more flexible.
 

what is the change notification feature? What does it buy me the
sysadmin and what does it do for my users? What is wrong with just a
config file? Most of the things in gnome's config seems to be a
relatively simple config file - human readable and editable. I've
noticed that evolution's config is base64 encoded (I think) and that has
lead to some frustration for me b/c I can't grep through it as easily
for something I want to change from a script.

> If you start talk about sharing configuration beyond a local cluster
> of machines, then you probably would want to not make gconfd the
> central configuration server, but use a configuration database like
> ACAP and use multiple gconfd's There was some thought in the gconfd
> design to allowing this, but it would probably wouldn't be a complete
> drop-in to get it working.

Would it be possible to make gconfd support an option? Put it someplace
in /etc, so I could toggle it off. The problem I have right now is if my
users login on two systems its almost entirely unusable. Or if the
system locks up for some reason and they attempt to login after it comes
back up; the lock is still outstanding in ~/.gconfd/lock and they can't
access their normal apps until they remove that lock/ dir.

If gconf could notice a stale lock and remove it then the latter problem
would go away.

I guess I'd be more happy to take the chance on config file corruption
rather than have my users bitching b/c they can't login at two places.

Or would it be horrible to do something like wu-imap does? ie: if two
sessions attempt to lock the same file the newest connection wins and
the older connection gets a popup saying "no more write access to this
file, you need to logout and back in to reenable it." I guess that is
the perk of ACAP b/c a single server on a single port negotiates who has
access to what and when.

In my environment, a university, it is entirely possible that a student,
from their room will login to their linux box using their afs homedir as
their homedir, they'll leave themselves login, login to a linux box in a
public cluster, also using afs, and be stuck until they either force the
removal of the lock or they login to their linux box in their room and
kill their session. And opening up tcp/ip on orbit won't work b/c I can
guarantee any ports not explicitly allowed from the dorm network will be
STRICTLY disallowed to the clusters.

Hell, maybe just making the "gconfd has a locking problem and the
"galeon cannot find its schema" errors to tell the user something more
useful would be enough.


-sv