initial message

[seth vidal <skvidal phy duke edu>]

Hi everyone,
 Thanks for signing up to the list - I'm going to type a preliminary
list of problems/issues we've encountered deploying gnome in our
environment and hope this will stir up some discussion of other problems
or solutions.

First off - our environment is of two types: 1. nis + nfs red hat linux
servers and clients - rhl 9 on the clients 7.3 on the servers. 2.
kerberos+ldap+afs sun solaris running openafs for the servers and red
hat linux 9 and solaris 9 gnome-based  clients.

The problems are similar in both
1. simultaneous logins are not possible: If a user logs into a
workstation running gnome then w/o logging out, logs into another
workstation running gnome they will, in the best case, receive a gconf
message warning them that their lock will be overridden and that they
could lose some configuration. This isn't a terribly functional state
for most networks. In our case university networks mean an enormous
number of roaming users so it is terribly likely for a user to login and
stay logged in while attempting to login somewhere else.

2. roaming logins frequently fail after logout. Evolution, in
particular, leaves some processes open after you logout. If this
happens, then gconfd won't exit, if gconfd won't exit then you're in the
same condition as above.

3. gconfd logs errors/reports to the system logs in the language
selected by the user at login. So if a user of mine logs in and selects
chinese in the gdm menu, then all the gconfd error logs will be in
chinese. Not terribly useful for error reporting or debugging. If these
logs were logged to the user's home directory it would  make complete
sense for them to be in the user's selected language but as they are
going to syslog it makes much less sense. It would probably be best if
these messages obeyed the system default language and not the currently
selected user language.

4. Many applications assume local access == file access. Many programs,
evolution most notably, seem to assume that if you have privilege to be
userX on the workstation then you have privileges to write to userX's
home dir. This is not true with ticket-oriented user-authenticated
filesystems (like afs and eventually nfsv4). This is a bad assumption.

5. Gnome (and kde) both behave VERY badly when the user is out of quota
space. Commonly on large networks home directory quotas are put in place
to keep the system more-sane. When a user hits their hard quota or
expires their quota grace period gnome will attempt to run and exit w/o
an error message visible to the user at all. Minimally, an error,
explaining that the encountered a quota or diskfull error would be
terribly helpful.

6. gnome needs system-wide logout scripts. To help deal with many of the
above problems we determined that it would be handy to, before logging
the user out, have a set of scripts that the administrator could force a
user electing to run gnome-session to run.
 The scripts could clean up various problems or processes left around
that can't be killed easily by the logout itself.


This is a short list of problems and issues I've seen in deploying gnome
2.X (and to some extent 1.4) on a network.

what do y'all think?
-sv