GNOME Bugzilla – Bug 333327
GDM should migrate users from gdm.conf to custom.conf
Last modified: 2010-06-04 19:57:35 UTC
Please describe the problem: My gdm setup includes Gentoo's Emergence theme, circles in password entry and autologin with my normal user account. Since updating gdm to 2.13.0.10, I've had the Happy Gnome theme, no circles and no autologin. If I use gdmsetup, it looks like it is accepting my changes but the changes are not reflected in gdm's behavior. If I edit /etc/X11/gdm/custom.conf directly and use 'gdmflexiserver --command="UPDATE_CONFIG <key>"' my changes are still not reflected. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Yes Other information: Gentoo 2006.0/AMD64/Gnome 2.14RC
Hmmm. I'm not sure what the best thing to do here is. This problem is probably caused because you still have an old /etc/gdm/gdm.conf file. Now gdm uses /usr/share/gdm/defaults.conf for system-wide defaults and /etc/gdm/custom.conf for storing your config changes. However, if you still have an old gdm.conf file on your system, the daemon will use that instead of the custom.conf file. gdmsetup is modifying your custom.conf file. I'd recommend copying the gdm.conf to custom.conf, or perhaps better, moving the gdm.conf aside and remaking the changes to custom.conf. The problem with just copying gdm.conf to custom.conf is that then you aren't taking advantage of the feature that really you should default to the defaults.conf file unless you really want the key to be customized. Perhaps gdmsetup should edit the gdm.conf file instead of custom.conf file if it exists. But this might be a good way for users to realize that it is a good idea to upgrade their config to the new system. Either way, I'm happy to change the code if people want, but I'll wait for some feedback on this. Or if this generates lots of complaints, I'll probably just make gdmsetup work this way.
That was the problem, and moving gdm.conf out of that directory and restarting gdm took care of it. My take on what to do: check for gdm.conf. If it exists, diff it against defaults.conf, move any modifications into custom.conf, delete gdm.conf and leave a custom.example file that informs the user of the conf file changes. Those users who use gdmsetup and may not even know about the conf files won't know the difference. And you have a slight, one-time slowdown on gdm startup until gdm.conf is gone. Better than using gdmsetup or editing conf files and not having the changes work!
Yes - that would be better. However, GDM 2.14 has entered hard code freeze, so it may be hard to get this change in. This might be an annoying thing that will have to wait until the next round before it can be fixed.
I can confirm this problem. I was also suffering from an old /etc/X11/gdm/gdm.conf file and couldn't find out why my changes never did get applied. removing that file fixed the problem though.
(In reply to comment #3) > Yes - that would be better. However, GDM 2.14 has entered hard code freeze, > so it may be hard to get this change in. This might be an annoying thing > that will have to wait until the next round before it can be fixed. > I understand you have to keep to your release schedule. Still, I can't help but think that being unable to save login preferences with no error messages to indicate what the problem is will make some upgraders unhappy with 2.14.
Unfortunately it is too late in the 2.14 release cycle to consider adding migration code to automatically migrate users from gdm.conf to custom.conf. However, to address the immediate issue of users finding gdmsetup not working, I have fixed 2.14 so that it will continue to edit gdm.conf if it is being used by the daemon as the custom config file. User's can choose to move aside their gdm.conf file and start using custom.conf when they feel ready. I will leave this bug open and change the subject line to indicate that we should add code so that the GDM daemon will automatically migrate the user from gdm.conf to custom.conf in GDM 2.15. I would prefer for this sort of migration code to be well tested rather than trying to throw it in at the last minute of the 2.14 cycle.
I just helped out another user on the Gentoo forums who didn't understand why his changes weren't being saved. This has happened more than once since I filed this bug during the 2.14 release cycle. Any chance of migration code being added and gdm.conf being dumped completely? The current situation really doesn't work for users.
If the gdm.conf file exists on the system, then the daemon should use the gdm.conf file as the "custom config file", and gdmsetup should edit it. You should not find that the daemon uses one file and gdmsetup uses another - unless the Gentoo distro is doing something really strange with the way they configure and set up GDM. Do you know why GDM isn't working this way on Gentoo? Are the users using the latest version of GDM? Some versions of GDM (especially GDM 2.13 unstable releases) had bugs that caused the GDM daemon and gdmsetup to not use the same file. I'd not recommend trying to support users if they are using an unstable release of GDM, really. But you are right, it would be better to enhance the GDM daemon to migrate the file. However, this would be a bit tricky to do properly. 1) Handling the key/value pairs in the file wouldn't be so hard since simply loading them and comparing them to the values in defaults.conf is fairly straightforward. 2) The "[servers]" section would be more tricky to migrate. It probably isn't appropriate to just assume that the CVS default of setting "0=Standard" is the default on all distros, so it would be necessary to walk the servers list and compare the defaults with gdm.conf and figure out what the right values to put into custom.conf would be. 3) More complicated would be the [server-foo] sections. Some distros may change the key/value pairs in the default sections (server-Standard, server-Chooser, and server-Terminal). There may be additional or custom server-foo sections added by the user. Also some of the default ones could be removed. So again it would be necessary to walk through these and make sure any changes from the default values are captured in the custom.conf file. In other words, it is a bit of work to fully implement the migration code. I don't think I'll have time to address this in the 2.16 release, though I'd be happy to provide guidance and help.
I believe the user I just helped out was manually editing custom.conf and wondering why the changes weren't being applied. The situation you describe is what I first ran into which caused me to open this bug, but that was with a 2.13 gdm. This user would have been using 2.14.9 as that's the version that entered Gentoo's stable tree a month or so ago. I understand your point about the work involved. I am not a coder, so I can't help you out there. Still, it would be good to see this changed sometime as using different config files under different circumstances is not the most transparent method possible.
Yes, I totally agree. This is something that really should be done. The code isn't really that hard - since much of the logic for reading/parsing the files is already in daemon/gdmconfig.c. The time-consuming part of this change would be testing it and making sure it would work properly in all sorts of cases. I don't like the idea of trying to hack something together quickly, because any errors in this code could be serious. It would be bad if GDM automatically messed up the user's configuration, especially if it impacted security. In some ways, it may be better to force the user to migrate their config by hand when dealing with configuration settings that would mess up security if not done properly. It also might be better for distros to deal with this on upgrade. It would be fairly simple, for example, to move the "gdm.conf" file to "custom.conf" when the user upgrades their package - if the gdm.conf file exists then custom.conf is being ignored anyway - so it would be okay to overwrite it if it exists, I'd think. This would ensure that the system only has one configuration file for user editing. And this might be a bit safer than trying to not mess up the users configuration when migration. Sorry, I'm just trying to offer some other suggestions since I am being lame and don't have time to really fix this properly now. I'd definately accept a patch if this issue is causing anybody enough problems that it is worth the time coding and testing. I'd also be happy to explain how to write the code, since I'm fairly familiar with how the logic for reading/writing the config data works. I'd say it would only take a few days to do the coding, but testing would probably be time-consuming since you'ld have to test add/change/delete for all 3 types of configuration mentioned in comment #8 above.
Your idea about having distros do this seems like the simplest solution. I have a pretty good idea of how this would be done in a Gentoo ebuild, and I'm sure other distros have their own ways of accomplishing this. The 2.14->2.16 upgrade would be the logical time to do it. If you choose to go forward with that approach, I will be glad to start the ball rolling by opening a Gentoo bug requesting that with 2.16 any existing gdm.conf be renamed to custom.conf, overwriting any existing (ignored) custom.conf. I will reference this bug for the rationale. Just let me know if that's how you want to resolve this.
I think it is a simpler and easier solution for distros to address this, and also safer since there would be no worries about a bug in the migration logic messing up the users configuration. I'd recommend filing a bug with Gentoo as you suggest.
This was implemented in Gentoo with 2.16 (see http://bugs.gentoo.org/show_bug.cgi?id=142687 for details). I don't know if you are tracking this for other distros and want to leave this bug open for other's benefit?
Thanks for taking the time to report this bug. However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.