Bug 717962

Actually the links are copied exactly as they appear in the file system (i.e. there's no adjustment of the link target). This means that relative symlinks work fine but breaks absolute links.

On my RHEL5 test machines /etc/sysconfig links like selinux are all relative so I've not seen the problem in testing.

I'm still puzzled by bug 674717 though since that report shows a relative symlink:

Actual results:
lrwxrwxrwx 1 root root    17  2月  3 11:01 selinux -> ../selinux/config

In my testing I don't see a problem for this case:

# tar xf sosreport-pe1950-1-644170-cd9b6a.tar.bz2
# ls -l pe1950-1-644170/etc/sysconfig/selinux
lrwxrwxrwx 1 root root 17 Nov  9 11:51 pe1950-1-644170/etc/sysconfig/selinux -> ../selinux/config
# cat pe1950-1-644170/etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
SELINUX=permissive
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

sos has code to handle absolute symlinks that it encounters when processing addCopySpec'd paths:

    # Methods for copying files and shelling out
    def doCopyFileOrDir(self, srcpath):
[...]
            if os.path.isabs(link):
                # the link was an absolute path, and will not point to the new
                # tree. We must adjust it.
                rpth = sosRelPath(os.path.dirname(dstslname), os.path.join(self.cInfo['dstroot'], link.lstrip(os.path.sep)))
            else:
                # no adjustment, symlink is the relative path
                rpth = link
[...]

But this isn't working correctly for links that are added recursively (i.e. contained in a directory passed to addCopySpec - glob matches are handled correctly).

This is why I hadn't seen this in my testing - with all plugins enabled the general plugin will collect the symlink (but no target) and the selinux plugin will then finish the job since it calls addCopySpec("/etc/sysconfig/selinux") and triggers a copy of the target.

Hmm, no it's actually simpler than that. The symlink handling is just broken (just adjusts abs->rel but does not add the link target to the file set).

Other plugins only mask the behaviour if they coincidentally pull in the target path - e.g. selinux does addCopySpec("/etc/selinux") which will include the /etc/selinux/config file that the general plugin references as ../selinux/config.

Turns out to be a one-line fix:
 
diff -up sos/plugintools.py.orig sos/plugintools.py
--- sos/plugintools.py.orig     2011-11-09 18:04:34.000000000 +0000
+++ sos/plugintools.py  2011-11-09 18:04:17.000000000 +0000
@@ -174,6 +174,7 @@ class PluginBase:
 
             self.soslog.log(logging.VERBOSE3, "creating symlink %s -> %s" % (dstslname, rpth))
             os.symlink(rpth, dstslname)
+            self.doCopyFileOrDir(link)
             self.copiedFiles.append({'srcpath':srcpath, 'dstpath':rpth, 'symlink':"yes", 'pointsto':link})
             return

We need to explicitly request collection of the original symlink target path from the system.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: the internal API used by sos modules to collect files and directories incorrectly handled symbolic links with a relative target path.

Consequence: due to this bug only the symbolic link (and not the file to which it refers) were copied into the sosreport tarball.

Fix: the file and directory copying routines have been modified to correctly copy and adjust symbolic link targets within the sosreport tree.

Result: Relative symbolic links are now handled correctly and their targets are properly included in the generated report.

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/RHSA-2012-0153.html