Description of problem: It seems to be a general problem, which shows eg in general plugin: - there is addCopySpec("/etc/sysconfig") statement - /etc/sysconfig/selinux is a link to /etc/selinux/config - because of this bug, only link is copied, resulting in missing real file and having broken link in report Version-Release number of selected component (if applicable): sos-1.7-9.54.el5 How reproducible: Always Steps to Reproduce: 1. sosreport -o general 2. unpack report and list etc/sysconfig/selinux 3. Actual results: link is broken, destination file not present in report Expected results: destination file should be gathered, too Additional info: This is probably primary cause of somehow badly written bug report: bug 674717
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