- With the RHBA-2011-1028 advisory, the sosreport utility introduced the "--tmp-dir" command option allowing the sosreport tarballs to be stored in a user-specified directory. After this change, sosreport no longer determined a directory for the tarballs from the TMP environment variable. The Red Hat Enterprise Virtualization 2.2. Log Collector application expected sosreport to use the TMP variable therefore Log Collector failed to collect the tarballs correctly from hosts. With this update, sosreport relies on the TMP environment variable again if the directory is not specified by the "--tmp-dir" option. Log Collector now works as expected.
- The sosreport utility incorrectly included Certificate-based Red Hat Network private entitlement keys in the resulting archive of debugging information. An attacker able to access the archive could use the keys to access Red Hat Network content available to the host. This issue did not affect users of Red Hat Network Classic.
- With the RHBA-2011-1028 advisory, the sosreport utility introduced the
--tmp-dircommand option allowing the sosreport tarballs to be stored in a user-specified directory. After this change, sosreport no longer determined a directory for the tarballs from the
TMPenvironment variable. The Red Hat Enterprise Virtualization 2.2 Log Collector application expected sosreport to use the
TMPvariable therefore Log Collector failed to collect the tarballs correctly from hosts. With this update, sosreport relies on the
TMPenvironment variable again if the directory is not specified by the
--tmp-diroption and Log Collector now works as expected.
- Prior versions of the sos cluster module incorrectly used the python
lstrip()method to extract the release number of the kernel package from the complete NVR (Name, Version, Release) string. This resulted in invalid release strings for certain kernel versions. As a result, sos incorrectly reported warnings for valid
gfs2kernel module configurations. The cluster module has been modified to correctly obtain the release substring from the complete package NVR and false positives are no longer reported for valid package combinations.
- The internal API used by sos modules to collect files and directories handled symbolic links with a relative target path incorrectly. Due to this bug only the symbolic links were copied to the sosreport tarball and the linked files were omitted. With this update, the file and directory copying routines have been modified to correctly copy and adjust symbolic link targets within the sosreport tree and targets of relative symbolic links are properly included in the generated report.
- Previously, sosreport used by default a threaded execution model to invoke plug-in modules. Consequently, a keyboard interrupt (Ctrl+c) failed to terminate the program due to improper synchronization between the main and child threads. The
sosreportcommand now runs in single-threaded mode by default. This behavior was previously enabled by running the command with the
--no-multithreadoption. This update adds the
--multithreadoption to allow the previous behavior. As a result, sosreport now behaves more consistently when keyboard interrupts or other signals are received.
NoteOccasionally, sos can fail to respond to the keyboard interrupt (Ctrl+C). In such a case, the user is advised to suspend the process (press the Ctrl+Z keys in the interactive shell running sosreport) and kill the sosreport process: issue the
kill pidcommands where pid is the PID of the sosreport process. In the case the command fails, send the process the
SIGKILLsignal: issue the
kill -9 pidcommand.
- Previously, sos attempted to determine whether the system is configured to use the traditional
rsyslogddaemon for logging. However, the used heuristic incorrectly identified an installed rsyslog as being used even though it was not configured. As a result, sos failed to collect custom-defined log destinations specified in the
syslog.conffile of the host. The general module no longer attempts to determine, which log daemon is in use and collects any user-defined log destinations present in either the rsyslog or syslog configuration file.
sosreportcommand allows the user to restrict the maximum size of log files collected by the general plug-in using the
general.syslogsizeoption. If the limit is exceeded, a portion of the log file is stored in the report in the plug-in sos_commands directory. Prior sos versions did not create a symbolic link from the default location for the size-limited log file to the location in the plug-in commands directory. If the user was unaware that log size limiting was applied, they may have assumed that the file was missing. With this release, sosreport creates symbolic links that point from the default location to the size-limited log file. Users can now find the expected content at the default location within sosreport regardless of the applied log file size limits.
- Due to an incorrect translation in the French locale files, sos printed the following confusing prompt when run in interactive mode:
Voulez vous continuer (y/n)?Attempting to enter the suggested prompt response (
y) resulted in an error. The expected response string has been changed to match the translated prompt and the program now suggests the correct response.
- Prior to this update, sos suppressed exceptions raised by plug-ins so that a bug in one plug-in would not prevent generation of the entire sosreport. Since plug-in exceptions are caught internally and not reported to the user or logged, this mechanism could conceal problems in the default plug-in set. The
sosreportcommand has been modified to report any exceptions raised during plug-in processing to the sos log file or to the terminal output when run in verbose mode. Plug-in exceptions can now be discovered with the normal sos logging mechanisms while retaining the previous behavior of not permitting such exceptions to prematurely terminate the sos process.
sosreportcommand uses the Python libxml2 bindings to parse XML-formatted files such as
/etc/cluster/cluster.conf. A malformed XML markup triggers a parser exception. This exception was caught by the generic module handling routines and was not reported to the user. Systems with a malformed
cluster.confreported no errors but the cluster module terminated abnormally without collecting the full set of data. The cluster module has been modified to catch parser exceptions internally and print a diagnostic message to alert the user to the problem.
- Veritas storage devices and high-availability products are commonly deployed on Red Hat Enterprise Linux systems, and provide scripts to collect configuration and status information for support purposes. Prior releases of sos were not able to include their output in sosreports. This update adds a new sos module, which collects output from Veritas scripts and Veritas support data is now collected automatically when sosreport is executed on qualified systems.
- Prior versions of sos did not collect the libvirt configuration or log files requiring administrators to manually collect and submit these files. A new sos module has been included and the libvirt configuration files in the
/etc/libvirt/directory and log files in the
/var/log/libvirt/directory are now collected when present.
- Prior to this update, sos did not support collection of gfs2-specific configuration and debugging information. A new sos module has been added that collects detailed configuration and debug information for this subsystem: file system metadata, dlm (distributed lock manager) state, journal sizes and counts, and gfs2 glock debugging data.
- The sos certificate system module did not support Red Hat Certificate System later than the 7.3 version. As a result, on Red Hat Certificate System 8.0 or later, the configuration and log files for these versions were not collected automatically. The
csmodule has now been updated to include support for the later versions, and collection of configuration and log data on the later Red Hat Certificate System works as expected. In addition, the functionality of the
dogtagmodule has been merged to the revised
csmodule and the
dogtagmodule has been removed from the sos package.
- Prior versions of sos only collected basic configuration information for Red Hat Enterprise MRG components and the user of these components had to retrieve the required data manually. This update expands the set of data collected by the
mrggridmodule and sos now collects the full logs, configuration, and status information from MRG components automatically.
- Prior versions of sos did not capture InfiniBand-specific information. This update adds a new module to sos that captures this information and the
sosreportcommand now automatically collects the output of the
ibv_devinfocommands on appropriately equipped systems.
- Systems using the software iSCSI target may require specific additional information to be collected in order to diagnose problems with these storage components. Prior versions of the sos package did not support collecting of this information and the user had to retrieve the details manually. This update adds the
iscsimodule that collects configuration and debugging output from the scsi-target-utils package and the information about configured software iSCSI targets is collected automatically.