Re: initial message

[Mark Finlay <sisob-lists tuxfamily org>]

Hey everyone,

Great idea for a list. Hope to see lots of good ideas coming out of
here. Gnome has great potential for deployment - but this really needs
to be capitalised.

There are also the issues running a mixed 2.0/2.2/2.4 environment that I
pointed out on desktop-devel recently.

To summarise: 
- 2.2 and 2.4 use a different desktop location - this can be fixed with
a system link. 
- 2.2 and 2.4 store launchers differently so launchers created in one
cannot be seen in the other. There is one-time migration code, so it may
be possible to patch this to synchronise every time one logs into 2.4.
As yet I have not solved this and it is preventing me from deploying
both 2.2 and 2.4 in the same environment.
- Custom emblems changed location from 2.0 to 2.2 - it is possible to
synchronise or system like the two locations

Also there are the problems with absolute paths being stored in gconf,
which is presently being discussed in gconf. The problems is that $HOME
and $PREFIX as stored as absolute paths, so if one changes to different
workstation with a different $HOME or $PREFIX (eg. BSD) this can cause
problems.

Thanks

MArk

On Tue, 2003-09-09 at 00:26, seth vidal wrote:
> 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
> 
> 
> _______________________________________________
> Gnome-deployment-list mailing list
> Gnome-deployment-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-deployment-list
-- 
Mark Finlay 
Computer Science Student

E-Mail:	sisob_AT_tuxfamily_DOT_org
Jabber:	sisob_AT_jabber_DOT_org
Blog:	http://sisob.tuxfamily.org
 	http://advogato.org/person/sisob