RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 980861 - authconfig overwrites sss changes /etc/nsswitch.conf during installation
Summary: authconfig overwrites sss changes /etc/nsswitch.conf during installation
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: authconfig
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: David Spurek
URL:
Whiteboard:
: 1003981 (view as bug list)
Depends On: 867473 1000348
Blocks: 917655 1000349
TreeView+ depends on / blocked
 
Reported: 2013-07-03 11:31 UTC by Kaleem
Modified: 2015-03-02 05:27 UTC (History)
15 users (show)

Fixed In Version: authconfig-6.2.7-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 867473
: 1000349 (view as bug list)
Environment:
Last Closed: 2014-06-13 11:52:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
nsswitch configuration file (1.79 KB, text/plain)
2013-07-03 11:31 UTC, Kaleem
no flags Details
Fedora 20 TC2 anaconda-ks.cfg (1.39 KB, text/plain)
2013-11-26 21:12 UTC, Dean Hunter
no flags Details
Fedora 20 TC2 nsswitch.conf (1.68 KB, text/plain)
2013-11-26 21:13 UTC, Dean Hunter
no flags Details

Description Kaleem 2013-07-03 11:31:06 UTC
Created attachment 768206 [details]
nsswitch configuration file

sssd does not exits in nsswitch.conf by default on fresh installs.

Please find attached nsswitch.conf for reference.

+++ This bug was initially created as a clone of Bug #867473 +++

In Fedora 17 and 18 we have a problem where remote users are unable to log in until the machine has been rebooted. This used to work previously. To fix this we probably need to:

Include 'sss' in /etc/nsswitch.conf by default and have the small sssd-client package (with just thepam, nss plugins) installed on all but minimal Fedora installs.

This happens after configuration using authconfig to change /etc/nsswitch.conf (or doing it manually). The changes are not picked up by long running processes like dbus-daemon --system. As far as I can see dbus-daemon then refuses to allow connections from these users. As might be expected, gnome-shell crashes hard when this happens.

There are some other ways to fix this problem, but these do not scale to fix the problem for every possible affected process:

http://sourceware.org/bugzilla/show_bug.cgi?id=12459

I'm filing this against the authconfig component, but in reality I think it affects more things like comps and anaconda.


TEST CASE:

* This should be ideally run on a freshly installed system or at
  least a system without sss in /etc/nsswitch.conf since last boot.

$ grep sss /etc/nsswitch.conf && "ALREADY HAVE sss"
$ sudo -s
# yum install sssd-tools pamtester
# test -f /etc/sssd/sssd.conf && mv /etc/sssd/sssd.conf /etc/sssd/sssd.conf.bak
# echo -e "[sssd]\ndomains=local\nconfig_file_version=2\nservices=nss,pam\n[domain/local]\nid_provider=local" > /etc/sssd/sssd.conf
# chmod 0600 /etc/sssd/sssd.conf
# systemctl start sssd.service
# authconfig --update --enablesssd --enablesssdauth
# sss_useradd --uid=2121 --gecos=Zapp zapp
# passwd zapp # set password for zapp
# pamtester zapp authenticate   # type password, should succeed

* Now go to gdm by logging out or switch user.
* Try to log in as zapp.
* Hang.
* Reboot
* Try to log in as zapp.
* Success

--- Additional comment from Stephen Gallagher on 2012-10-19 10:39:04 EDT ---

Stef, this worked previously because Ray and I hacked GDM to call out to the 'id' command in a separate process to look up the users. This worked around the fact that changes to nsswitch.conf weren't applied to running processes.

However, this always basically hid the fact that it wasn't updating systemd, messagebus etc.

This bug doesn't belong to authconfig. It should be reassigned to glibc. There are two ways to fix it. One is to have the Fedora package ship 'sss' as you suggest.

The better solution would be for glibc to provide a mechanism for nsswitch.conf to be reread somehow, though this has been suggested in the past and rebuffed before, because it would require either polling or an inotify watch on the file (or else checking the file directly on every lookup, thereby slowing ID lookups down significantly.

So I suppose a temporary solution would be to put 'sss' in the default config. It will have no effect if SSSD is not installed or not running. (I have tested this just now).

--- Additional comment from Stef Walter on 2012-10-22 05:36:35 EDT ---

Jeff, I'm trying to generate a patch for this. Wondering where glibc-2.16-75f0d304-fedora.tar.gz comes from? It contains the default nsswitch.conf. Is it in git somewhere?

Or should I instead make a patch?

--- Additional comment from Stef Walter on 2012-10-22 07:59:02 EDT ---

This is a patch to the f18 glibc fedora package.

--- Additional comment from Stef Walter on 2012-10-22 09:14:28 EDT ---

This is a patch to the f19 glibc fedora package

--- Additional comment from Jeff Law on 2012-10-22 11:26:05 EDT ---

Stef,

As far as I can tell neither patch does what you claim it does.  You claim it adds "sss" to nsswitch.conf.  However, both patches simply remove passwd, shadow, group, services and netgroup from nsswitch.conf and do not add sss anywhere.

--- Additional comment from Stef Walter on 2012-10-22 11:39:50 EDT ---

(In reply to comment #5)
> As far as I can tell neither patch does what you claim it does.  You claim
> it adds "sss" to nsswitch.conf.  However, both patches simply remove passwd,
> shadow, group, services and netgroup from nsswitch.conf and do not add sss
> anywhere.

There's something very strange going on with bugzilla.redhat.com here. It somehow modified my patches.

These are the patches I attached, and can be accessed by clicking on the big descriptive links under the 'Attachments' column in the table above. 

For f18: https://bugzilla.redhat.com/attachment.cgi?id=631443

For f19: https://bugzilla.redhat.com/attachment.cgi?id=631478

I have no idea what's going on with the munged patches linked from in comments 3 and 4. :S

--- Additional comment from Jeff Law on 2012-10-22 11:51:11 EDT ---

It's the &action=diff appearing on the link in c#3 and c#4 that triggers the problem.   No clue why though.  They're referencing the same underlying attachment, BZ just munges them.

I'll add these to Fedora.   We already ship a hacked up nsswitch.conf, so this isn't really going to add to our long term maintenance cost.


Jeff

--- Additional comment from Jeff Law on 2012-10-22 12:07:04 EDT ---

nsswitch.conf for F18 and rawhide has been updated.  Builds will spin today.

--- Additional comment from Ray Strode [halfline] on 2012-10-25 10:39:35 EDT ---

note nss-mdns munges /etc/nsswith.conf hosts line to put

 mdns4_minimal [NOTFOUND=return]

on it (in %post).  Two thoughts:

1) is [NOTFOUND=return] important for sss too?
2) Should nsswitch.conf include mdns4_minimal by default as well?

--- Additional comment from Stef Walter on 2012-10-26 15:46:02 EDT ---

(In reply to comment #9)
> note nss-mdns munges /etc/nsswith.conf hosts line to put
> 
>  mdns4_minimal [NOTFOUND=return]
> 
> on it (in %post).  Two thoughts:
> 
> 1) is [NOTFOUND=return] important for sss too?

Why? First of all it's last in the list. And secondly, why would we want to not continue to other modules sss returns NOTFOUND?

> 2) Should nsswitch.conf include mdns4_minimal by default as well?

mdns4_minimal [NOTFOUND=return] breaks domains that end in .local, at least it used to. libnss_sss has been designed to not have any impact if sssd is not running, is that the case for libnss_mdns4_minimal?

--- Additional comment from Fedora Update System on 2012-11-17 00:03:16 EST ---

glibc-2.16-24.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/glibc-2.16-24.fc18

--- Additional comment from Fedora Update System on 2012-11-26 23:51:12 EST ---

glibc-2.16-24.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 2 Siddhesh Poyarekar 2013-07-03 13:43:32 UTC
Which compose have you tried?  RHEL-7.0-20130628.0 has the latest bits and should work fine.  Closing this as a duplicate of an existing bug 917655.  If the latest compose doesn't work then we'll see what's wrong in that bug.

*** This bug has been marked as a duplicate of bug 917655 ***

Comment 3 Kaleem 2013-07-04 06:58:02 UTC
I tried with compose RHEL-7.0-20130624.n.0. I will check this in latest compose.

Comment 4 Siddhesh Poyarekar 2013-07-04 07:02:15 UTC
Please post your observations on bug 917655.

Comment 5 Siddhesh Poyarekar 2013-07-04 17:38:37 UTC
Reopening this bug.  See bug 917655 comment 5.

Comment 6 Siddhesh Poyarekar 2013-08-20 11:17:13 UTC
It looks like authconfig assumes USESSSD=no by default and whenever `authconfig --update` is called, sssd is disabled and subsequently sss is removed from /etc/nsswitch.conf.

My theory is that anaconda calls `authconfig --update --nostart` but not --enablesssd, due to which the 'sss' is removed from nsswitch.conf.

Comment 7 Stephen Gallagher 2013-08-20 13:35:29 UTC
I can confirm from anaconda logs that the following is invoked:

anaconda.program.log:13:02:44,265 INFO program: Running... /usr/sbin/authconfig --update --nostart --enableshadow --passalgo=sha512

So this is the source of the problem. So now the question becomes: do we treat this as an anaconda bug or an authconfig bug?

Comment 8 Tomas Mraz 2013-08-20 14:02:16 UTC
I need to investigate why authconfig drops it because it should read the presence of sss in nsswitch.conf.

What is the contents of nsswitch.conf before authconfig overwrites it? It should be saved in /var/lib/authconfig/last

Comment 9 Stephen Gallagher 2013-08-20 14:31:41 UTC
Tomas, I can reproduce the issue simply by editing /etc/nsswitch.conf and adding 'sss' manually to the passwd: line after 'files' and then running:

/usr/sbin/authconfig --update --nostart --enableshadow --passalgo=sha512


After that, the 'sss' has been stripped back out again.

Comment 10 Stef Walter 2013-09-03 16:33:11 UTC
*** Bug 1003981 has been marked as a duplicate of this bug. ***

Comment 13 Dean Hunter 2013-11-22 18:35:32 UTC
Please note that on Fedora 19 and 20 Beta authconfig behavior is the same as noted in comments 6 through 9.

Comment 14 Stephen Gallagher 2013-11-26 13:18:09 UTC
(In reply to Dean Hunter from comment #13)
> Please note that on Fedora 19 and 20 Beta authconfig behavior is the same as
> noted in comments 6 through 9.

I just tried to reproduce this with authconfig-6.2.6-4.fc20.x86_64 and it appears to be working just fine.

Comment 15 Dean Hunter 2013-11-26 21:11:14 UTC
(In reply to Stephen Gallagher from comment #14)
> (In reply to Dean Hunter from comment #13)
> > Please note that on Fedora 19 and 20 Beta authconfig behavior is the same as
> > noted in comments 6 through 9.
> 
> I just tried to reproduce this with authconfig-6.2.6-4.fc20.x86_64 and it
> appears to be working just fine.

After your comment I built a new VM using Fedora 20 TC2. I used Anaconda, but not Kickstart. The Kickstart and Name Service Switch confiiguration files built by Anaconda are attached. There are no reference to SSS in either file. I was expecting the following references in the NSS configuration file:

passwd:     files sss
shadow:     files sss
group:      files sss
services:   files sss
sudoers:    files sss
netgroup:   files sss
automount:  files sss

Comment 16 Dean Hunter 2013-11-26 21:12:22 UTC
Created attachment 829491 [details]
Fedora 20 TC2 anaconda-ks.cfg

Comment 17 Dean Hunter 2013-11-26 21:13:13 UTC
Created attachment 829492 [details]
Fedora 20 TC2 nsswitch.conf

Comment 18 Ludek Smid 2014-06-13 11:52:30 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


Note You need to log in before you can comment on or make changes to this bug.