Bug 83967 - /etc/X11/xdm/Xsession only execs gnome-session
Summary: /etc/X11/xdm/Xsession only execs gnome-session
Keywords:
Status: CLOSED DUPLICATE of bug 56319
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdm
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact: Mike McLean
URL: http://mail.gnome.org/archives/gnome-...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-10 15:50 UTC by Aaron Sherman
Modified: 2007-04-18 16:50 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-21 18:51:41 UTC
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.