Bug 1226819
| Summary: | gnome-initial-setup cannot be disabled, forces user creation | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Alexander Todorov <atodorov> | |
| Component: | gnome-initial-setup | Assignee: | Rui Matos <rmatos> | |
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | |
| Severity: | medium | Docs Contact: | Marie Hornickova <mdolezel> | |
| Priority: | medium | |||
| Version: | 7.1 | CC: | atodorov, bburke264, ben.stanley, bloch, cww, dmaziuk, edgar.hoch, evilc, extras-qa, g.kaviyarasu, jakubr, jonathan, jyundt, mclasen, mkolman, pyuan, ralacroix, ricardo.arguello, rmatos, sagardeshmukh505, somlo, tiagomatos, tom, tpelka, troels, vanmeeuwen+fedora | |
| Target Milestone: | rc | Keywords: | Reopened | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | gnome-initial-setup-3.22.1-2.el7 | Doc Type: | Release Note | |
| Doc Text: |
Gnome Initial Setup can now be disabled by the "firstboot --disable" command in kickstart
With this update, the _gnome-initial-setup_ package has been fixed to respect the "firstboot --disable" kickstart command. As a result, Gnome Initial Setup can be robustly turned off during a kickstart installation and users are no longer forced to create user account on the first boot under the described circumstances as long as the installation kickstart contains the "firstboot --disable" command.
|
Story Points: | --- | |
| Clone Of: | 1067653 | |||
| : | 1422867 1428471 (view as bug list) | Environment: | ||
| Last Closed: | 2017-08-01 10:06:04 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 1067653 | |||
| Bug Blocks: | 1298243, 1422867 | |||
|
Description
Alexander Todorov
2015-06-01 08:38:52 UTC
This problem also affects RHEL 7.2
My setup:
- using "text" install rather than "graphical" in kickstart.
- kickstart file satisfies all items that would generate prompts.
- no users are created locally (using Enterprise logins).
- users will have a graphical environment (%packages section contains the environment group @^graphical-server-environment).
My requirements:
A) Do not run gnome-initial-setup on first boot, which prompts for user creation.
B) Do not run gnome-initial-setup on a user's first login, which localizes the user's desktop. The desktop is already customized globally for all users.
My findings:
- "firstboot --disable" in kickstart doesn't prevent gnome-initial-setup from running, so not using this as it might affect something else.
- allowing gnome-initial-setup on first boot to create a local user localizes only that user. Additional users still run gnome-initial-setup on first login.
- My requirements are met in varying degrees by the following 4 methods which have been documented elsewhere, which I tested with these results.
1) Add "InitialSetupEnable=False" under [daemon] in /etc/gdm/custom.conf
This method satisfies requirement A, but not requirement B.
2) Exclude the gnome-initial-setup package in kickstart and blacklist it from the gnome-desktop package group so that it is not reinstalled by an update of gnome-desktop.
%packages
-gnome-initial-setup
%end
%post
yum group mark blacklist gnome-desktop
%end
This method satisfies both requirements A and B. It's an unusual package setup and might affect future dependencies unless it becomes the de-facto standard way.
3) Remove gnome-initial-setup-*.desktop items from XDG autostart.
%post
rm /etc/xdg/autostart/gnome-initial-setup-{copy-worker,first-login}.desktop
%end
This method does nothing for requirement A, and only temporarily satisfies requirement B (the files might be reinstalled by an update of the gnome-initial-setup package). This is unacceptable.
4) Set up a template for new user home directories in /etc/skel that stops gnome-initial-setup from running. This affects only locally created users and may do nothing for an enterprise setup, which likely has remote home directories that are mounted on-the-fly; the same file needs to be created in pre-existing remote home directories. The contents of the file do not matter. This example template uses an empty file, which works.
%post
mkdir -p /etc/skel/.config && touch /etc/skel/.config/gnome-initial-setup-done
%end
This method satisfies requirement B, but not requirement A. Note that root's home directory is not set up by /etc/skel so if you insist on logging into root with a GUI and don't want localization to happen you would need instead to use
%post
mkdir -p /etc/skel/.config /root/.config && touch /etc/skel/.config/gnome-initial-setup-done /root/.config/gnome-initial-setup-done
%end
Conclusion:
The choices that work are: method 2 by itself, or methods 1 and 4 together. Method 2 never allows a user to reconfigure localization, while the latter combination allows a user to reconfigure localization by removing the file ~/.config/gnome-initial-setup-done (which is noticed almost immediately by GNOME).
Using method 2 (removing the package) makes the most sense to me only for my requirements, but it's exposed to the risk of new dependencies down the road.
If I was to suggest a software solution, it would be to modify gnome-initial-setup. In InitialSetup mode allow it to modify only global configuration settings like Time Zone (but that setting is debatable for a multiuser system) and make creation of the first local user optional (but surely some novices will use the wrong workflow and fail to create a local user). Also add a new control item under [daemon] in /etc/gdm/custom.conf, say UserInitialSetupEnable, that globally controls gnome-initial-setup for individual login mode. Existing behaviour with ~/.config/gnome-initial-setup-done can be retained to override UserInitialSetupEnable=true
"firstboot --disable" is necessary to skip the prompts for accepting the EULA and creating a local user. I think I am also seeing this issue. Setting up RHEL 7.3, and picking the KDE Gui from the package options. Upon startup, I get to a first use wizard that is non-dismissable. I hit Next through to the "About You" page. There is also a "Set Up Enterprise Login" button. If you click this button, and attempt to enter windows domain details, then it informs you that samba and sssd is not installed. Hitting Back does not allow you to exit "Enterprise Login". It does seem, however, that if you click "Set Up Enterprise Login" again, you go back to the "About You" page. I then reinstalled RedHat, and checked the "File Server" option in installed packages (I do not want a file SERVER, I want to use SAMBA to access windows shares). Repeated, and it still said that SSSD was not installed. So I just set up the user anyway, and finished the wizard. Yet STILL, on startup, I cannot access my windows fileshares from nautilus. I get "Unable to access location - Failed to retrieve share list from server: No such file or directory". Epic Fail. I have now tried RHEL 7.1, 7.3 beta and 7.3 and spent numerous days trying to get RHEL installed with working SAMBA. I have spent DAYS trying to do this. Exactly how many years do you need to fix this? Beyond a joke. Not a joke. Management has officially cancelled our RHEL 7 deployment for taking too long. Maybe we will skip to RHEL 8, but seriously looking at porting our application to Windows. We are a Windows and Active Directory shop and this application was an outlier, originally running on Apollo workstations, then HP PA-RISC, and finally RHEL 4 and 6 for the last 10+ years. RHEL 7 is OK as a server O/S but too much stuff is broken in a desktop deployment. The Anaconda-side functionality needed for this is ready to be merged: https://github.com/rhinstaller/anaconda/pull/973 Once that's in, everything should be in place. *** Bug 1144623 has been marked as a duplicate of this bug. *** Verified with gnome-initial-setup-3.22.1-4.el7 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2318 (In reply to ralacroix from comment #1) > This problem also affects RHEL 7.2 > > My setup: > > - using "text" install rather than "graphical" in kickstart. > - kickstart file satisfies all items that would generate prompts. > - no users are created locally (using Enterprise logins). > - users will have a graphical environment (%packages section contains the > environment group @^graphical-server-environment). > > My requirements: > > A) Do not run gnome-initial-setup on first boot, which prompts for user > creation. > > B) Do not run gnome-initial-setup on a user's first login, which localizes > the user's desktop. The desktop is already customized globally for all users. > > My findings: > > - "firstboot --disable" in kickstart doesn't prevent gnome-initial-setup > from running, so not using this as it might affect something else. > > - allowing gnome-initial-setup on first boot to create a local user > localizes only that user. Additional users still run gnome-initial-setup on > first login. > > - My requirements are met in varying degrees by the following 4 methods > which have been documented elsewhere, which I tested with these results. > > 1) Add "InitialSetupEnable=False" under [daemon] in /etc/gdm/custom.conf > > This method satisfies requirement A, but not requirement B. > > 2) Exclude the gnome-initial-setup package in kickstart and blacklist it > from the gnome-desktop package group so that it is not reinstalled by an > update of gnome-desktop. > > %packages > -gnome-initial-setup > %end > %post > yum group mark blacklist gnome-desktop > %end > > This method satisfies both requirements A and B. It's an unusual package > setup and might affect future dependencies unless it becomes the de-facto > standard way. > > 3) Remove gnome-initial-setup-*.desktop items from XDG autostart. > > %post > rm /etc/xdg/autostart/gnome-initial-setup-{copy-worker,first-login}.desktop > %end > > This method does nothing for requirement A, and only temporarily satisfies > requirement B (the files might be reinstalled by an update of the > gnome-initial-setup package). This is unacceptable. > > 4) Set up a template for new user home directories in /etc/skel that stops > gnome-initial-setup from running. This affects only locally created users > and may do nothing for an enterprise setup, which likely has remote home > directories that are mounted on-the-fly; the same file needs to be created > in pre-existing remote home directories. The contents of the file do not > matter. This example template uses an empty file, which works. > > %post > mkdir -p /etc/skel/.config && touch > /etc/skel/.config/gnome-initial-setup-done > %end > > This method satisfies requirement B, but not requirement A. Note that root's > home directory is not set up by /etc/skel so if you insist on logging into > root with a GUI and don't want localization to happen you would need instead > to use > > %post > mkdir -p /etc/skel/.config /root/.config && touch > /etc/skel/.config/gnome-initial-setup-done > /root/.config/gnome-initial-setup-done > %end > > Conclusion: > > The choices that work are: method 2 by itself, or methods 1 and 4 together. > Method 2 never allows a user to reconfigure localization, while the latter > combination allows a user to reconfigure localization by removing the file > ~/.config/gnome-initial-setup-done (which is noticed almost immediately by > GNOME). > > Using method 2 (removing the package) makes the most sense to me only for my > requirements, but it's exposed to the risk of new dependencies down the road. > > If I was to suggest a software solution, it would be to modify > gnome-initial-setup. In InitialSetup mode allow it to modify only global > configuration settings like Time Zone (but that setting is debatable for a > multiuser system) and make creation of the first local user optional (but > surely some novices will use the wrong workflow and fail to create a local > user). Also add a new control item under [daemon] in /etc/gdm/custom.conf, > say UserInitialSetupEnable, that globally controls gnome-initial-setup for > individual login mode. Existing behaviour with > ~/.config/gnome-initial-setup-done can be retained to override > UserInitialSetupEnable=true Adding one more solution to this: If we create /root/.config/gnome-initial-setup-done having content as yes. Then the gnome-initial-setup will not be launched |