Bug 243551

Summary: gdm silently ignores custom.conf file under some situations
Product: [Fedora] Fedora Reporter: Bill C. Riemers <briemers>
Component: gdmAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED WONTFIX QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 8CC: andrewz, mattdm, philec
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-09 07:08:02 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 Bill C. Riemers 2007-06-09 17:00:19 UTC
Description of problem:

I have a custom.conf file I used with Fedora Core 6 to start Xvnc instead of
Xorg at run level 5.  When I try installing the same file on a Fedora 7 install,
it has no effect.  Xorg is still started.  I ran an strace of gdm-binary, and it
seems custom.conf is read, but then it is completely ignored.

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


How reproducible:

Always.


Steps to Reproduce:
1. Add rules to /etc/gdm/custom.conf that override /usr/share/gdm/defaults.conf
2. Restart gdm.
3. Watch the results.
  
Actual results:


Expected results:


Additional info:

The custom.conf file I am using is available at:

http://colinux.wikia.com/wiki/FedoraCore6TipsAndTricks#Starting_Xvnc

As a workaround, I edited my changes into defaults.conf, but this file will be
overwritten next time there is an update to the gdm package.

Comment 1 Bill C. Riemers 2007-07-17 14:52:02 UTC
It would really help if someone could look into this.  The latest Fedora updates
overwrite the /usr/share/gdm/defaults.conf on my coLinux image.  So far I have
gotten three bug reports on this.

If you don't have time to work on this, let me know the correct cvs or svn
repository to use, and I will try generating a patch to fix this.

Bill


Comment 2 Ray Strode [halfline] 2007-07-18 14:40:18 UTC
what permissions are you installing the file with?

if you run gdmsetup and make changes does the resulting custom.conf file reflect
your changes and also work?  

Comment 3 Bill C. Riemers 2007-07-18 20:47:36 UTC
The file permissions are 644, owned by user root and group root.  If I run
gdmsetup, the changes are saved into custom.conf.  However, when I run gdmsetup
again, it does not show my previous changes.  For example, if I change use 24
hour clock from "auto" to "yes", I will see the change in /etc/gdm/custom.conf.
 But when I run gdmsetup again it still shows "auto".



Comment 4 Bill C. Riemers 2007-07-19 14:15:03 UTC
I just spend ten minutes or so playing around, to find what lines cause the
custom.conf to be ignored.  It turns out custom.conf is ignored whenever there
is an attempt to redefine a section-foo.  For example, if I append the following
to any custom.conf, all values in the file will be ignored:

[server-Standard]


Comment 5 Ray Strode [halfline] 2007-07-22 22:41:29 UTC
Thanks for tracking down the root cause, retitling for clarity

Comment 6 Bill C. Riemers 2007-07-23 13:42:09 UTC
I think you misunderstood.  server-Standard only appears in the custom file once.


Comment 7 Ray Strode [halfline] 2007-07-23 17:23:56 UTC
Ah, what keys do you have under [server-Standard] ?

Comment 8 Bill C. Riemers 2007-07-24 01:25:20 UTC
It doesn't seem to matter what keys I add under [server-Standard], just adding
the group is enough for all the settings to be ignored.  

But, if it is helpful, they keys I need to work (and did work with FC6) are name
and command  as in:

[server-Standard]
name=Standard server
command=/usr/bin/Xvnc -audit 0 -geometry 1024x768 -depth 16 -SecurityTypes None
flexible=true


 

Comment 9 Andrew 2007-11-19 15:12:31 UTC
I am not sure whether this is exactly the same bug, but I have a similar
problem.  I do not have a server-foo, but I cannot increase MaxSessions in
[xdmcp].   It's always 16.  However, this is a terminal server with 20+ users.

The problem started after upgrading from FC6 to F8.

Comment 10 Philippe Leclercq 2008-04-12 23:56:25 UTC
*** Bug 442196 has been marked as a duplicate of this bug. ***

Comment 11 Matthew Miller 2008-05-13 19:19:45 UTC
*** Bug 243779 has been marked as a duplicate of this bug. ***

Comment 12 Matthew Miller 2008-05-13 19:21:48 UTC
Any progress on this? It's 100% repeatable and very frustrating. Please check
the comments in bug #243779.

Comment 13 Bill C. Riemers 2008-05-13 19:47:29 UTC
Yeah.  I never built a copy of Fedora 8 for coLinux, because I was waiting on
this issue to get fixed.  The hack I did for Fedora 7 of overwriting the
defaults.conf caused too many problems when users did updates and the
overwritten file was replaced...   If nobody else has time to work in this let
me know, and I will spend some of my free time creating a patch to fix this.

Bill


Comment 14 Matthew Miller 2008-05-13 20:05:15 UTC
Given the amount of attention this has failed to receive over the past year, I
vote for your free time. :)

Comment 15 Bug Zapper 2008-05-14 02:58:54 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 16 Ray Strode [halfline] 2008-05-14 05:02:08 UTC
Hi, this bug isn't on the radar at the moment, so patches would definitely be
useful.

Comment 17 Matthew Miller 2008-05-14 11:43:06 UTC
Putting back to rawhide.

FWIW, my original complaint that

[servers]
1=Standard

doesn't work still holds true too.

Comment 18 Ray Strode [halfline] 2008-11-12 15:38:16 UTC
This is a bug in F8 and earlier.  There's a similar issue in F9 and later, but it should be tracked separately.

Comment 19 Bug Zapper 2009-01-09 07:08:02 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.