Bug 1489648

Summary: autofs missing dependency with libsss_autofs cause missing file messages during boot
Product: Red Hat Enterprise Linux 7 Reporter: masanari iida <masanari.iida>
Component: autofsAssignee: Ian Kent <ikent>
Status: CLOSED ERRATA QA Contact: xiaoli feng <xifeng>
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.4CC: knoha, xifeng, xzhou
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: autofs-5.0.7-73.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 18:17:12 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:    
Bug Blocks: 1553558    
Attachments:
Description Flags
Patch - fix nisplus lookup init not configured check
none
Patch - make open_lookup() error handling more consistent
none
Patch - be silent about sss library not found
none
Patch - be silent about nis domain not set
none
Patch - make map source reference message debug only none

Description masanari iida 2017-09-08 02:52:56 UTC
Description of problem:
autofs should have dependency setting with libsss_autofs

Version-Release number of selected component (if applicable):
autofs-5.0.7-69.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. Install minimum OS (RHEL7)
2. Install autofs and libtirpc manually from DVD.
   autofs RPM require libtirpc as dependency package.
   But it doesn't require any other packages
3. Enable autofs
   # systemctl enable autofs.service
4. Reboot OS

Actual results:

automount[1258]: open_sss_lib:78: lookup(sss): failed to open /usr/lib64/sssd/modules/libsss_autofs.so: /usr/lib64/sssd/modules/libsss_autofs.so: cannot open shared object file: No such file or directory

Expected results:
auotfs RPM should ask user to install libsss_autofs as dependency in
step 2. 

Additional info:
After install libsss_auofs RPM and reboot the system, the autofs output
no more warnings.

Comment 2 Ian Kent 2017-10-03 04:02:56 UTC
(In reply to masanari iida from comment #0)
> Description of problem:
> autofs should have dependency setting with libsss_autofs
> 
> Version-Release number of selected component (if applicable):
> autofs-5.0.7-69.el7.x86_64
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. Install minimum OS (RHEL7)
> 2. Install autofs and libtirpc manually from DVD.
>    autofs RPM require libtirpc as dependency package.
>    But it doesn't require any other packages
> 3. Enable autofs
>    # systemctl enable autofs.service
> 4. Reboot OS
> 
> Actual results:
> 
> automount[1258]: open_sss_lib:78: lookup(sss): failed to open
> /usr/lib64/sssd/modules/libsss_autofs.so:
> /usr/lib64/sssd/modules/libsss_autofs.so: cannot open shared object file: No
> such file or directory

Yes, I see that "something" has added sss to the automount line
in /etc/nsswitch.conf even though sssd is not installed. And that
is what's causing the error.

> 
> Expected results:
> auotfs RPM should ask user to install libsss_autofs as dependency in
> step 2. 

autofs doesn't require sssd or any of it's sub-packages so asking
to install them is the wrong thing to do.

The fact is that autofs does not change the /etc/nsswitch.conf file.
autofs doesn't own /etc/nsswicth.conf so it requires the user change
it to what is required.

> 
> Additional info:
> After install libsss_auofs RPM and reboot the system, the autofs output
> no more warnings.

Just because some other package has set the value of the automount
line in /etc/nsswitch.conf to something that isn't sensible doesn't
mean autofs should request the install of packages that might not be
needed or wanted.

In this case I'm more inclined to silently fail rather than add a
dependency to the package.

Unfortunately, due to other recent changes that might not be quite
as simple as one would hope, I'll need to check the implications
of that.

Ian

Comment 3 masanari iida 2017-10-03 05:00:13 UTC
glibc-2.17-196.el7.x86_64

* Tue Feb 28 2017 Florian Weimer <fweimer> - 2.17-166
- Add "sss" service to the automount database in nsswitch.conf (#1392540)

Comment 4 Ian Kent 2017-10-03 06:22:29 UTC
(In reply to masanari iida from comment #3)
> glibc-2.17-196.el7.x86_64
> 
> * Tue Feb 28 2017 Florian Weimer <fweimer> - 2.17-166
> - Add "sss" service to the automount database in nsswitch.conf (#1392540)

I don't understand what your trying to say.

The glibc package owns /etc/nsswitch.conf so it can do whatever
it likes to it and installs and upgrades of glibc will be ok but
that doesn't make the change sensible or make it valid for autofs
to change it.

The default installed /etc/nsswitch.conf also has nisplus which
is virtually useless, and has been for years, and also gets in
the way of autofs.

Silently failing is I think the only sensible way to deal with
this even though it could be a bit hard to do.

Comment 5 Ian Kent 2017-10-09 08:42:47 UTC
(In reply to Ian Kent from comment #4)
> (In reply to masanari iida from comment #3)
> > glibc-2.17-196.el7.x86_64
> > 
> > * Tue Feb 28 2017 Florian Weimer <fweimer> - 2.17-166
> > - Add "sss" service to the automount database in nsswitch.conf (#1392540)
> 
> I don't understand what your trying to say.
> 
> The glibc package owns /etc/nsswitch.conf so it can do whatever
> it likes to it and installs and upgrades of glibc will be ok but
> that doesn't make the change sensible or make it valid for autofs
> to change it.
> 
> The default installed /etc/nsswitch.conf also has nisplus which
> is virtually useless, and has been for years, and also gets in
> the way of autofs.
> 
> Silently failing is I think the only sensible way to deal with
> this even though it could be a bit hard to do.

After investigating this further I see that libsss_autofs is
actually a separate package. I thought it had been taken into
the sssd (or the sssd-common) package and I thought that adding
a dependency would require installing far more than should be
needed. So adding the requested dependency would probably have
been ok.

But we have another problem present in RHEL-7.4 that resulted
when other changes were made in an attempt to fix some startup
problems (including a sss behaviour problem) where autofs will
now block for 10 seconds during startup when nsswitch.conf has
unconfigured sources in its automount line (as sss is in this
case).

It looks like failures in the lookup library open and its
initialization are mostly due to unconfigured sources so I
think I cab use this to help with the above problem.

But if a dependency is added that's no longer possible.

If the changes to essentially ignore failures in the lookup
library open and its initialization don't have adverse side
effects I'd rather do this to resolve this problem.

I'll see how it goes in testing.

Ian

Comment 6 Ian Kent 2017-10-11 01:32:42 UTC
Created attachment 1336951 [details]
Patch - fix nisplus lookup init not configured check

Comment 7 Ian Kent 2017-10-11 01:33:48 UTC
Created attachment 1336952 [details]
Patch - make open_lookup() error handling more consistent

Comment 8 Ian Kent 2017-10-11 01:35:07 UTC
Created attachment 1336953 [details]
Patch - be silent about sss library not found

Comment 9 Ian Kent 2017-10-11 01:36:01 UTC
Created attachment 1336954 [details]
Patch - be silent about nis domain not set

Comment 10 Ian Kent 2017-10-11 01:36:58 UTC
Created attachment 1336955 [details]
Patch - make map source reference message debug only

Comment 11 Ian Kent 2017-10-11 06:14:02 UTC
A package with the above changes can be found at:
http://people.redhat.com/~ikent/autofs-5.0.7-73.el7/

Please check if this package resolves the problem you were
seeing.

Comment 16 errata-xmlrpc 2018-04-10 18:17:12 UTC
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-2018:0977