Bug 924362 - New alternatives doesn't verify if /lib*/xtables is symlinked correctly
New alternatives doesn't verify if /lib*/xtables is symlinked correctly
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: iptables (Show other bugs)
6.4
All Linux
urgent Severity high
: rc
: ---
Assigned To: Thomas Woerner
Ales Zelinka
:
Depends On:
Blocks: 835616 947773
  Show dependency treegraph
 
Reported: 2013-03-21 11:44 EDT by Jacob Hunt
Modified: 2014-01-21 17:03 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-21 18:34:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jacob Hunt 2013-03-21 11:44:17 EDT
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 18:34:27 EST
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

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