Bug 243551
Summary: | gdm silently ignores custom.conf file under some situations | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bill C. Riemers <briemers> |
Component: | gdm | Assignee: | Ray Strode [halfline] <rstrode> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 8 | CC: | 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
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 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? 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". 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] Thanks for tracking down the root cause, retitling for clarity I think you misunderstood. server-Standard only appears in the custom file once. Ah, what keys do you have under [server-Standard] ? 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 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. *** Bug 442196 has been marked as a duplicate of this bug. *** *** Bug 243779 has been marked as a duplicate of this bug. *** Any progress on this? It's 100% repeatable and very frustrating. Please check the comments in bug #243779. 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 Given the amount of attention this has failed to receive over the past year, I vote for your free time. :) 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 Hi, this bug isn't on the radar at the moment, so patches would definitely be useful. Putting back to rawhide. FWIW, my original complaint that [servers] 1=Standard doesn't work still holds true too. This is a bug in F8 and earlier. There's a similar issue in F9 and later, but it should be tracked separately. 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. |