Actually, thinking about it, it could be a bug in rpm, couldn't it? Who decides that *.rpm{save,old,new} copies are created?

*** Bug 867445 has been marked as a duplicate of this bug. ***

BTW, authconfig rewrites this file. Maybe worth investigating if 'authconfig --update --enablesssd' or something like that causes your changes to be lost.

For me, "authconfig --update --enablesssd' did change the file (without making backup), but with the options you suggested it didn't break mdns.

# diff nsswitch.conf.bak nsswitch.conf
35,36c35,36
< group:      files
< initgroups: files
---
> group:      files sss
> #initgroups: files
40c40
< hosts:      files mdns4_minimal [NOTFOUND=return] dns mdns myhostname
---
> hosts:      files mdns4_minimal [NOTFOUND=return] dns
57c57
< services:   files
---
> services:   files sss
59c59
< netgroup:   nisplus
---
> netgroup:   files sss
63c63
< automount:  files nisplus
---
> automount:  files

I don't understand why is this assigned to authconfig. Its purpose is to update config files so updating nsswitch.conf is definitely not a bug. And when it updates them it makes a backup in /var/lib/authconfig.

BTW glibc calls authconfig --update in rpm %post? It probably shouldn't. There was an authconfig --update call in systemd %post, but that was already removed. I do not know of any other rpm package that would do it.

(In reply to comment #5)
> BTW glibc calls authconfig --update in rpm %post? It probably shouldn't.

I don't think it does:

wycliff:hesla (master) $ rpm -q --scripts glibc
preinstall scriptlet (using <lua>):
-- Check that the running kernel is new enough
required = '2.6.32'
rel = posix.uname("%r")
if rpm.vercmp(rel, required) < 0 then
  error("FATAL: kernel too old", 0)
end
postinstall program: /usr/sbin/glibc_post_upgrade.x86_64
postuninstall program: /sbin/ldconfig
preinstall scriptlet (using <lua>):
-- Check that the running kernel is new enough
required = '2.6.32'
rel = posix.uname("%r")
if rpm.vercmp(rel, required) < 0 then
  error("FATAL: kernel too old", 0)
end
postinstall program: /usr/sbin/glibc_post_upgrade.i686
postuninstall program: /sbin/ldconfig
wycliff:hesla (master) $ rpm -q --scripts glibc-common
postinstall scriptlet (using <lua>):
if posix.access("/etc/ld.so.cache") then
  if posix.stat("/usr/lib/locale/locale-archive.tmpl", "size") > 0 then
    pid = posix.fork()
    if pid == 0 then
      posix.exec("/usr/sbin/build-locale-archive")
    elseif pid > 0 then
      posix.wait(pid)
    end
  end
end

Back to glibc then.

Matěj,

Can you get me a list of all the rpms on the system where you saw this behaviour and the output from rpm -q --scripts ?

Most likely some other package is overwriting that file, so it's not a glibc problem.  But without knowing what package is the culprit, I don't know who to reassign this to.

Created attachment 640589 [details]
List of all packages.

Created attachment 640590 [details]
output of rpm -qa --scripts

This is redhat-lsb issue.

# grep mdns /etc/nsswitch.conf
hosts:      files mdns4_minimal [NOTFOUND=return] dns mdns4
# yum reinstall redhat-lsb
Loaded plugins: product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Resolving Dependencies
--> Running transaction check
---> Package redhat-lsb.ppc64 0:4.1-5.el7 will be reinstalled
--> Finished Dependency Resolution

Dependencies Resolved

====================================================================================================================================================================================================================
 Package                                             Arch                                           Version                                            Repository                                              Size
====================================================================================================================================================================================================================
Reinstalling:
 redhat-lsb                                          ppc64                                          4.1-5.el7                                          beaker-Server                                           22 k

Transaction Summary
====================================================================================================================================================================================================================
Reinstall  1 Package

Total download size: 22 k
Installed size: 0  
Is this ok [y/N]: y
Downloading Packages:
redhat-lsb-4.1-5.el7.ppc64.rpm                                                                                                                                                               |  22 kB  00:00:00     
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : redhat-lsb-4.1-5.el7.ppc64                                                                                                                                                                       1/1 
  Verifying  : redhat-lsb-4.1-5.el7.ppc64                                                                                                                                                                       1/1 

Installed:
  redhat-lsb.ppc64 0:4.1-5.el7                                                                                                                                                                                      

Complete!
# grep mdns /etc/nsswitch.conf
# 



---
# rpm -q --scripts redhat-lsb
preinstall scriptlet (using /bin/sh):
# remove the extra symlink /bin/mailx -> /bin/mail
if [ -e /bin/mailx ]; then
   if [ -L /bin/mailx ]; then
     rm -f /bin/mailx
   fi 
fi
postinstall scriptlet (using /bin/sh):
if ! grep -s -q '^hosts: \+files \+dns *$' /etc/nsswitch.conf;then
     cat /etc/nsswitch.conf >/usr/share/lsb/nsswitch.conf.orig
     ed -s /etc/nsswitch.conf <<EOF
/^hosts: \+files \+/s/.*/hosts:      files dns/
w
q
EOF
cat /etc/nsswitch.conf >/usr/share/lsb/nsswitch.conf
fi
preuninstall scriptlet (using /bin/sh):
if [ $1 -eq 0 ];then
    if [ -e /usr/share/lsb/nsswitch.conf -a -e  /usr/share/lsb/nsswitch.conf.orig ];then
        if cmp -s /usr/share/lsb/nsswitch.conf /etc/nsswitch.conf;then
            cat /usr/share/lsb/nsswitch.conf.orig >/etc/nsswitch.conf
        fi
        rm -f /usr/share/lsb/{nsswitch.conf,nsswitch.conf.orig}
    fi
fi

Thanks Miroslav.  I hadn't had the time to wander through the attachments yet.  I agree, this looks like a redhat-lsb package issue to me.

Matej, do you think that the solution with .rpmnew file would be sufficient?

(In reply to comment #16)
> Matej, do you think that the solution with .rpmnew file would be sufficient?

Well, it would be better than the current situation, but why in the first place anything has a need to change my configuration file? If somebody needs to changing something there, they have as much sed as I have.

Yes, this may be probably done better way with respect to user's modifications. Still, IMHO the change should not be silent (or there should be a file left after the change - either rpmnew or rpmsave) - as it modifies the configuration file (owned by other package). Reasons for these changes are in https://bugzilla.redhat.com/show_bug.cgi?id=825261 and https://bugzilla.redhat.com/show_bug.cgi?id=806190.

(In reply to comment #18)
> Still, IMHO the change should not be silent (or there should
> be a file left after the change - either rpmnew or rpmsave)

Quite certainly.

Created attachment 731961 [details]
list of the complete update originating the modification

extract from /var/log/yum.log with all the updates that in the end resulted
in a modified /etc/nsswitch.conf

As noted in the previous post I have the same problem, but redhat-lsb does not
seem to be the culprit.
I remember that the modification time of /etc/nsswitch.conf was something
like "Apr 05 13:10:10" which would place it in between the kernel Install and
the smokegen install:

[...]
Apr 05 13:09:23 Updated: 1:nfs-utils-1.2.7-5.fc18.i686
Apr 05 13:09:31 Installed: kernel-PAE-3.8.5-201.fc18.i686
Apr 05 13:12:15 Installed: smokegen-4.10.1-1.fc18.i686
[...]

I already re-modified /etc/nsswitch.conf, so that I cannot be completely 
sure of the modification time.

Created attachment 731977 [details]
/var/log/yum.log with the whole "yum update" transaction

Comment on attachment 731977 [details]
/var/log/yum.log with the whole "yum update" transaction

this the result of a "yum update" that resulted in a modification of the
"hosts:" entry in /etc/nsswitch.conf
More details in another attachment

Created attachment 731978 [details]
stat of /etc/nsswitch.conf and other data

The result of "stat /etc/nsswitch.conf" suggests that the culprit is some
"posttransaction" scriptlet...

Well, it could also be a pre- or postuninstall script, I guess.  Another
possibly important information:

in /usr/share/lsb I find:

# ls /usr/share/lsb/ -l                                                                                                         
total 12                                                                                                                                           
drwxr-xr-x 4 root root 4096 Jan 16 15:50 4.1                                                                                                       
-rw-r--r-- 1 root root 1714 Apr  5 18:28 nsswitch.conf                                                                                             
-rw-r--r-- 1 root root 1729 Apr  5 18:28 nsswitch.conf.orig

they actually coincide with the original and modified nsswitch.conf; and
the creation date is exactly the same as the modification time of /etc/nsswith.conf.  Definitely there is something related to lsb going on.

Here is a strong hint on the problem: "redhat-lsb" contains a "trigger"
associated to the "glibc" package, which is invoked at every "uninstall" of glibc:

--- sniplet from redhat-lsb.spec ---
[...]
%triggerpostun -- glibc
if [ -x /usr/sbin/redhat_lsb_trigger.%{_target_cpu} ]; then
  /usr/sbin/redhat_lsb_trigger.%{_target_cpu}
fi

%ifnarch %{ix86}
  /sbin/sln %{ldso} /%{_lib}/%{lsbldso} || :
%else
  if [ -f /emul/ia32-linux/lib/%{ldso} ]; then
    for LSBVER in %{lsbsover}; do
      /sbin/sln /emul/ia32-linux/lib/%{ldso} /%{_lib}/%{lsbldso}.$LSBVER || :
    done
  else
    for LSBVER in %{lsbsover}; do
      /sbin/sln %{ldso} /%{_lib}/%{lsbldso}.$LSBVER || :
    done
  fi
%endif
if ! grep -s -q '^hosts: \+files \+dns *$' /etc/nsswitch.conf;then
    cat /etc/nsswitch.conf >%{_datadir}/lsb/nsswitch.conf.orig
    ed -s /etc/nsswitch.conf <<EOF
/^hosts: \+files \+/s/.*/hosts:      files dns/
w
q
EOF
    cat /etc/nsswitch.conf > %{_datadir}/lsb/nsswitch.conf
fi
[...]
------------------------------------

*** no comment! ***

The trigger script in the new redhat-lsb.spec is just the same, in particular:

%triggerpostun -- glibc
[...]
if ! grep -s -q '^hosts: \+files \+dns *$' /etc/nsswitch.conf;then
    cat /etc/nsswitch.conf >%{_datadir}/lsb/nsswitch.conf.orig
    ed -s /etc/nsswitch.conf <<EOF
/^hosts: \+files \+/s/.*/hosts:      files dns mdns4_minimal/
w
q
EOF

which means that whenever glibc gets updated AND the the /etc/nsswitch.conf
contains anything different from (essentially) "hosts: files dns" it gets
rewritten into "hosts: files dns mdns4_minimal".
In particular if "nis" is originally present, it disappears :-(

In which version? Recently, in the latest builds in el7 I removed the black magic of nsswitch.conf at all - however, you have probably older version, as these builds are not yet public.
As the problem is in redhat-lsb %postun scriptlet as well, I can't fix this for released Fedoras - as the update will actually break the things again.

Silly me... I just downloaded the latest rpm source from the standard fc19 repos, which happens to be redhat-lsb-4.1-14.fc19.src.rpm.  Sorry about the confusion.

(In reply to Ondrej Vasik from comment #38)
> In which version? Recently, in the latest builds in el7 I removed the black
> magic of nsswitch.conf at all - however, you have probably older version, as
> these builds are not yet public.
> As the problem is in redhat-lsb %postun scriptlet as well, I can't fix this
> for released Fedoras - as the update will actually break the things again.

You mean that removing the %postun scriptlet (the nsswitch.conf part) from redhat-lsb would not fix the problem?

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.