Search

3.12. Tools

download PDF
matahari component
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 matahari services.
  • 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 (qpidd running on port 49000) 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.
libreport component
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.conf file:
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
irqbalance component, BZ#813078
The irqbalance(1) man page does not contain documentation for the IRQBALANCE_BANNED_CPUS and IRQBALANCE_BANNED_INTERRUPTS environment variables. The following documentation will be added to this man page in a future release:
IRQBALANCE_BANNED_CPUS
Provides 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_INTERRUPTS
Space 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"
rsyslog component
rsyslog does not reload its configuration after a SIGHUP signal is issued. To reload the configuration, the rsyslog daemon needs to be restarted:
~]# service rsyslog restart
parted component
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.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.