이 콘텐츠는 선택한 언어로 제공되지 않습니다.
3.12. Tools
mataharicomponent- The Matahari agent framework (matahari-*) packages are deprecated starting with the Red Hat Enterprise Linux 6.3 release. Focus for remote systems management has shifted towards the use of the CIM infrastructure. This infrastructure relies on an already existing standard which provides a greater degree of interoperability for all users. It is strongly recommended that users discontinue the use of the matahari packages and other packages which depend on the Matahari infrastructure (specifically, libvirt-qmf and fence-virtd-libvirt-qpid). It is recommended that users uninstall Matahari from their systems to remove any possibility of security issues being exposed.Users who choose to continue to use the Matahari agents should note the following:
- The matahari packages are not installed by default starting with Red Hat Enterprise Linux 6.3 and are not enabled by default to start on boot when they are installed. Manual action is needed to both install and enable the
matahariservices. - The default configuration for qpid (the transport agent used by Matahari) does not enable access control lists (ACLs) or SSL. Without ACLs/SSL, the Matahari infrastructure is not secure. Configuring Matahari without ACLs/SSL is not recommended and may reduce your system's security.
- The matahari-services agent is specifically designed to allow remote manipulation of services (start, stop). Granting a user access to Matahari services is equivalent to providing a remote user with root access. Using Matahari agents should be treated as equivalent to providing remote root SSH access to a host.
- By default in Red Hat Enterprise Linux, the Matahari broker (
qpiddrunning on port49000) does not require authentication. However, the Matahari broker is not remotely accessible unless the firewall is disabled, or a rule is added to make it accessible. Given the capabilities exposed by Matahari agents, if Matahari is enabled, system administrators should be extremely cautious with the options that affect remote access to Matahari.
Note that Matahari will not be shipped in future releases of Red Hat Enterprise Linux (including Red Hat Enterprise Linux 7), and may be considered for formal removal in a future release of Red Hat Enterprise Linux 6. libreportcomponent- An error in the default libreport configuration causes the following warning message to appear during problem reporting:
/bin/sh: line 4: reporter-bugzilla: command not found
This warning message has no effect on the functionality of libreport. To prevent the warning message from being displayed, replace the following lines in the/etc/libreport/events.d/ccpp_event.conffile:abrt-action-analyze-backtrace && ( bug_id=$(reporter-bugzilla -h `cat duphash`) && if test -n "$bug_id"; then abrt-bodhi -r -b $bug_id fi )with:abrt-action-analyze-backtrace
irqbalancecomponent, BZ#813078- The
irqbalance(1)man page does not contain documentation for theIRQBALANCE_BANNED_CPUSandIRQBALANCE_BANNED_INTERRUPTSenvironment variables. The following documentation will be added to this man page in a future release:IRQBALANCE_BANNED_CPUSProvides a mask of cpus which irqbalance should ignore and never assign interrupts to. This is a hex mask without the leading '0x', on systems with large numbers of processors each group of eight hex digits is sepearated ba a comma ','. i.e. `export IRQBALANCE_BANNED_CPUS=fc0` would prevent irqbalance from assigning irqs to the 7th-12th cpus (cpu6-cpu11) or `export IRQBALANCE_BANNED_CPUS=ff000000,00000001` would prevent irqbalance from assigning irqs to the 1st (cpu0) and 57th-64th cpus (cpu56-cpu63).
IRQBALANCE_BANNED_INTERRUPTSSpace seperated list of integer irq's which irqbalance should ignore and never change the affinity of. i.e. export IRQBALANCE_BANNED_INTERRUPTS="205 217 225"
rsyslogcomponent- rsyslog does not reload its configuration after a
SIGHUPsignal is issued. To reload the configuration, thersyslogdaemon needs to be restarted:~]#
service rsyslog restart partedcomponent- The parted utility in Red Hat Enterprise Linux 6 cannot handle Extended Address Volumes (EAV) Direct Access Storage Devices (DASD) that have more than 65535 cylinders. Consequently, EAV DASD drives cannot be partitioned using parted, and installation on EAV DASD drives will fail. To work around this issue, complete the installation on a non EAV DASD drive, then add the EAV device after the installation using the tools provided in the s390-utils package.
