Hi,
It looks like the upgrade to CentOS 7.6 has been unusually disruptive with the GNOME desktop version bump and a series of moving targets under the hood. The result is some wreckage at my client's desktop installations, which I've been busy to repair since yesterday. First things first.
I have a custom configuration of GDM, which consists mainly of two things.
1. Display my company's logo instead of the CentOS logo.
2. Disable the user list (since I have about 100 users here).
Until CentOS 7.5, here's what I did.
1. Create a file /etc/dconf/profile/gdm :
user-db:user system-db:gdm file-db:/usr/share/gdm/greeter-dconf-defaults
2. Create a file /etc/dconf/db/gdm.d/01-logo :
[org/gnome/login-screen] logo='/usr/share/pixmaps/microlinux-logo.png'
3. Create a file /etc/dconf/db/gdm.d/00-login-screen :
[org/gnome/login-screen] disable-user-list=true
4. Update dconf :
# dconf update
Now with CentOS 7.6 this doesn't work anymore. The /etc/dconf/db/gdm.d directory is nowhere to be found, and I'm currently mildly cursing the GNOME developers' (and Red Hat's) policy of releasing moving targets. Until now, the whole purpose of Enterprise Linux seemed to be low-risk updates. </rant>
I've documented the whole GDM customization process until CentOS 7.5 in a short article on my french blog :
* https://blog.microlinux.fr/gdm-centos/
Any idea how I can configure GDM with the new version ?
Cheers,
Niki
On Thu, Dec 06, 2018 at 10:01:25AM +0100, Nicolas Kovacs wrote:
Now with CentOS 7.6 this doesn't work anymore. The /etc/dconf/db/gdm.d directory is nowhere to be found, and I'm currently mildly cursing the GNOME developers' (and Red Hat's) policy of releasing moving targets. Until now, the whole purpose of Enterprise Linux seemed to be low-risk updates. </rant>
While the /etc/dconf/db/gdm.d/ directory doesn't exist, I've got many RHEL7.6 and CentOS 7.6 systems where GDM behaves the same way as before, as long as you create /etc/dconf/db/gdm.d/ and put the files in there, and as soon as you run 'dconf update', you see it change.
I'm not sure why the /etc/dconf/db/gdm.d/ and /etc/dconf/db/gdm.d/locks/ directory aren't owned by a package anymore, that seems like a bug, but as far as I can tell, GDM continues to get its information from there.
Jonathan Billings wrote:
On Thu, Dec 06, 2018 at 10:01:25AM +0100, Nicolas Kovacs wrote:
Now with CentOS 7.6 this doesn't work anymore. The /etc/dconf/db/gdm.d directory is nowhere to be found, and I'm currently mildly cursing the GNOME developers' (and Red Hat's) policy of releasing moving targets. Until now, the whole purpose of Enterprise Linux seemed to be low-risk updates. </rant>
While the /etc/dconf/db/gdm.d/ directory doesn't exist, I've got many RHEL7.6 and CentOS 7.6 systems where GDM behaves the same way as before, as long as you create /etc/dconf/db/gdm.d/ and put the files in there, and as soon as you run 'dconf update', you see it change.
I'm not sure why the /etc/dconf/db/gdm.d/ and /etc/dconf/db/gdm.d/locks/ directory aren't owned by a package anymore, that seems like a bug, but as far as I can tell, GDM continues to get its information from there.
I suspect it might be something that has been left out in the rebase to GDM 3.28.1 - an earlier change log for GDM has:
* Thu Jun 25 2015 Ray Strode rstrode@redhat.com 3.14.2-4 - Make sure user customizations to gdm via /etc/dconf/db/gdm.d continue to work following rebase. Related: #1174564
So, I'm guessing that something similar was left out with this change from 3.26 to 3.28 ?
Maybe a bug report to https://bugzilla.redhat.com is needed ?
James Pearson
Le 06/12/2018 à 15:24, James Pearson a écrit :
I suspect it might be something that has been left out in the rebase to GDM 3.28.1 - an earlier change log for GDM has:
On a side note, I've now spent a day and a half trying to recover my wrecked desktop profiles, with only a partial success. As it looks now, I'll probably move all my desktop installations to openSUSE Leap 15 and KDE 5 in the near future.
As far as I can tell, rebasing GNOME in the middle of a minor update was not a good idea.
Cheers,
Niki
On 12/06/2018 08:10 AM, Nicolas Kovacs wrote:
Le 06/12/2018 à 15:24, James Pearson a écrit :
I suspect it might be something that has been left out in the rebase to GDM 3.28.1 - an earlier change log for GDM has:
On a side note, I've now spent a day and a half trying to recover my wrecked desktop profiles, with only a partial success. As it looks now, I'll probably move all my desktop installations to openSUSE Leap 15 and KDE 5 in the near future.
As far as I can tell, rebasing GNOME in the middle of a minor update was not a good idea.
Cheers,
Niki
They did a similar thing with NetworkManager few releases ago that caused all my servers to start grabbing randomized IPv6 addresses instead of static they previously grabbed.
I don't understand why Red Hat makes these kind of changes in point releases - yet they won't update OpenSSL or PHP or Postfix in a point release.
It's like they use /dev/random to determibe where they require API stability between point releases.
On Thu, 6 Dec 2018, Alice Wonder wrote:
I don't understand why Red Hat makes these kind of changes in point releases
- yet they won't update OpenSSL or PHP or Postfix in a point release.
Rebasing Gnome3 regularly I think has been one of Red Hat's best decisions, and one I can easily imagine a committee deciding against for reasons of wanting to minimise risk.
Do you remember just how bad Gnome3 was in RHEL 7.0? It was unstable and insecure, certainly when used with nvidia drivers. I can't see how you could justify the effort it would have required to effectively support an unsupported version of Gnome3, and backporting I think would have been more than deeply unpleasant.
They made a mistake in omitting a patch that wasn't caught in qa, and that's a shame. But then let's be honest, how many Red Hat customers actually use this feature? I do use it, and I didn't pick it up in my own testing, as our deployment must have created the directories as we had no issues.
jh
Le 06/12/2018 à 18:54, John Hodrien a écrit :
Do you remember just how bad Gnome3 was in RHEL 7.0? It was unstable and insecure, certainly when used with nvidia drivers. I can't see how you could justify the effort it would have required to effectively support an unsupported version of Gnome3, and backporting I think would have been more than deeply unpleasant.
Or they could simply have gone with KDE 4, a stable and mature desktop at the time RHEL 7.0 was out. And not an abomination that had to be potty-trained from scratch again while steadily losing features every other minor upgrade.
Niki
On 12/6/18 2:30 PM, Nicolas Kovacs wrote:
Le 06/12/2018 à 18:54, John Hodrien a écrit :
Do you remember just how bad Gnome3 was in RHEL 7.0? It was unstable and insecure, certainly when used with nvidia drivers. I can't see how you could justify the effort it would have required to effectively support an unsupported version of Gnome3, and backporting I think would have been more than deeply unpleasant.
Or they could simply have gone with KDE 4, a stable and mature desktop at the time RHEL 7.0 was out. And not an abomination that had to be potty-trained from scratch again while steadily losing features every other minor upgrade.
Well that is one person's opinion on the KDE/GNOME debate .. mine would be slightly different (OK , completely opposite :)
To each his own :)
Johnny Hughes wrote:
On 12/6/18 2:30 PM, Nicolas Kovacs wrote:
Le 06/12/2018 à 18:54, John Hodrien a écrit :
Do you remember just how bad Gnome3 was in RHEL 7.0? It was unstable and insecure, certainly when used with nvidia drivers. I can't see how you could justify the effort it would have required to effectively support an unsupported version of Gnome3, and backporting I think would have been more than deeply unpleasant.
Or they could simply have gone with KDE 4, a stable and mature desktop at the time RHEL 7.0 was out. And not an abomination that had to be potty-trained from scratch again while steadily losing features every other minor upgrade.
Well that is one person's opinion on the KDE/GNOME debate .. mine would be slightly different (OK , completely opposite :)
To each his own :)
I'm in the gnome is crap camp. Bloatware (which is what kde used to be...), and it looks like it's trying, real hard, to make users think of Windows 10 (which, having had to deal with, I LOATHE!!!!!)
Kde looks like *Nix. I like things wo work the way I want, and no, the way they want to do it isn't how I want it... which, of course, is the *Nix Way.
mark
-
Alice Wonder -
James Pearson -
John Hodrien -
Johnny Hughes -
Jonathan Billings -
mark -
Nicolas Kovacs