Bug 83967

Summary:	/etc/X11/xdm/Xsession only execs gnome-session
Product:	[Retired] Red Hat Linux	Reporter:	Aaron Sherman <ajs>
Component:	gdm	Assignee:	Havoc Pennington <hp>
Status:	CLOSED DUPLICATE	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	jirka, otaylor
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
URL:	http://mail.gnome.org/archives/gnome-announce-list/2001-July/msg00019.html
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-02-21 18:51:41 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Aaron Sherman 2003-02-10 15:50:47 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020913

Description of problem:
NOTE: I'm treading on a lot of questionable ground here. It could be that I just
don't get the Red Hat Plan(tm). If that's the case, please consider this bug
report in terms of an experienced users' inability to find the correct
documentation in the man pages and Red Hat bug reports.

According to the release notes (URL cited in this bug) for the current version
of gdm as installed by Red Hat 7.3 (gdm 2.2.3.1 on my system):

"Note3:  Distributors, packagers.  Please, PLEASE use the standard Gnome script
[...] It should never be OK to just exec gnome-session, that is considered bad
form. The script needs to read (if available) the ~/.gnomerc and otherwise read
the <sysconfdir>/gdm/gnomerc file"

Am I missreading these release notes or does Red Hat fail to match the release
notes for GDM in this respect?

/etc/X11/xdm/Xsession certainly does quite a few things, but ". $HOME/.gnomerc"
is never one of them. This causes me no end of trouble because I cannot start my
ssh-agent and affect the environment of gnome-session without creating a global
configuration file in /etc/X11/xinit/xinitrc.d/ssh. Since this is a laptop,
that's exactly what I've done, but on other systems that I have access to,
that's not acceptable, as it would interfere with other users who log in.

This gets even stranger to me because the Red Hat system gnomerc (which appears
to never be looked at) in /etc/X11/gdm/gnomerc *also* just execs
gnome-session... that can't be what you intended! gnomerc is supposed to be file
that system administrators can put global configuration into (e.g. loading gnome
defaults from a per-user LDAP store to cite a really wacky, but plausible example).

I understand the urge to unify these behaviors between desktops, but please do
not stray too far from the gdm behavior that long-time users or newbie users who
actually read release notes will come to expect.

Thank you.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Change $HOME/.gnomerc
2. Log out
3. Log in using gdm Gnome session


Actual Results:  No .gnomerc actions performed


Expected Results:  .gnomerc actions should be performed.


Additional info:

Comment 1 Havoc Pennington 2003-02-11 15:19:34 UTC

I think George added that note to the release notes for our benefit. 
.gnomerc sounds a bit silly to me, really, but I do think there's some cleanup
to be done here.

The workaround for now is probably to use ~/.Xclients to run your own 
"exec ssh-agent gnome-session" for example.

Comment 2 Owen Taylor 2003-02-11 16:31:16 UTC

Since Red Hat 8.0, the X init scripts, by default, run the X sessions
under ssh-agent, so you shouldn't have to do anything at all.

In the future, we hope to work out a setup for the X init scripts
that is unified with what the upstream KDM and GDM maintainers
expect, but right now, you should just cinsider the Red  Hat 
init script setup to be distinct and different than what is
referred to in the GDM release notes.


*** This bug has been marked as a duplicate of 56319 ***

Comment 3 Red Hat Bugzilla 2006-02-21 18:51:41 UTC

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.