Bug 924362

Summary: New alternatives doesn't verify if /lib*/xtables is symlinked correctly
Product: Red Hat Enterprise Linux 6 Reporter: Jacob Hunt <jhunt>
Component: iptablesAssignee: Thomas Woerner <twoerner>
Status: CLOSED ERRATA QA Contact: Ales Zelinka <azelinka>
Severity: high Docs Contact:
Priority: urgent    
Version: 6.4CC: azelinka, ccheney, iptables-maint-list, jwest, lnovich, pchavan
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 23:34:27 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: 835616, 947773    

Description Jacob Hunt 2013-03-21 15:44:17 UTC
Description of problem:

The iptables-1.4.7-9.el6 RPM added "alternatives" functionality to the package moving its /lib*/xtables directory.  Normally upon upgrading to this package, the old /lib*/xtables directory is replaced with a symlink pointing to /etc/alternatives/lib-xtables.%{_arch}.

However, if we install custom iptables plugin files in /lib*/xtables, when we do "yum upgrade" that upgrades us to iptables-1.4.7-9.el6, the /lib*/xtables symlink does not get created.

The "alternatives" command should have failed when it couldn't create the slave symlink?  The iptables package should detect that all of its symlinks weren't created.


Why doesn't "alternatives" report this failure to create some of the package's slave symlinks?

Version-Release number of selected component (if applicable):

iptables-1.4.7-9.el6

How reproducible:

Always
  
Actual results:

Here's showing the alternatives command not detecting the problem:
========
$ ls -l /lib64/xtables
lrwxrwxrwx. 1 root root 36 Mar 16 13:25 /lib64/xtables -> /etc/alternatives/lib-xtables.x86_64/
$ sudo rm /lib64/xtables
$ sudo mkdir /lib64/xtables
$ sudo alternatives --auto iptables.x86_64
$ echo $?
0
$ ls -l /lib64/xtables
total 0
========

Expected results:

I can put it back with:
========
$ sudo rmdir /lib64/xtables
$ sudo alternatives --auto iptables.x86_64
$ ls -l /lib64/xtables
lrwxrwxrwx. 1 root root 36 Mar 16 13:38 /lib64/xtables -> /etc/alternatives/lib-xtables.x86_64/
========

Comment 12 errata-xmlrpc 2013-11-21 23:34:27 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.

http://rhn.redhat.com/errata/RHBA-2013-1710.html