Client Configuration Guide
Configuring, registering, and updating your Red Hat Enterprise Linux clients with Red Hat Satellite
Chapter 1. Introduction
Chapter 2. Configuring Client Applications
- Red Hat Update Agent - This is the update mechanism for Red Hat channels. Use of the Update Agent differs for certain operating systems:
- On Red Hat Enterprise Linux 5, 6, and 7 - As a
- On Red Hat Enterprise Linux 3 and 4 - As a standalone application (
- Red Hat Network Registration Client (rhn_register) - This is the mechanism to register clients. By default,
rhn_registerregisters to the main Red Hat Network servers. You need to reconfigure client systems to register to Red Hat Satellite or Red Hat Proxy.
yumcommand on Red Hat Enterprise Linux 5, 6, and 7 uses SSL for communication with remote repositories. Consequently, you should ensure that firewalls allow connections over port 443.
/etc/sysconfig/rhn/up2datefile. Similarly, to use Red Hat Network's Monitoring feature and probes requiring the Red Hat Network Monitoring Daemon, client systems must allow connections on port 4545 (or port 22, if it is using
2.1. Registering Clients with Red Hat Satellite Server
rhn_registercommand to register a system with Red Hat Satellite. Ensure you replace the example host names and domain names with those that apply to your configuration.
Procedure 2.1. To Use rhn_register to Register a System with Red Hat Satellite:
- Change into the
/usr/share/rhn/directory and download the SSL certificate to the client:
# cd /usr/share/rhn/
# wget http://satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
- Edit the
/etc/sysconfig/rhn/up2datefile and ensure that it contains the following entries:
serverURL=https://satellite.example.com/XMLRPC noSSLServerURL=http://satellite.example.com/XMLRPC sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
- Use the
rhn_registercommand to register the machine:
2.2. Using Activation Keys to Register Clients with Red Hat Satellite
Procedure 2.2. To Use Activation Keys to Register a System with Red Hat Satellite:
- Generate an activation key. See "Using Activation Keys" in the Red Hat Satellite Getting Started Guide.)
- Import custom GPG keys.
- Download and install the SSL Certificate RPM from the
/pub/directory of the Red Hat Proxy or Red Hat Satellite. For example (update the URL to suit your environment):
# rpm -Uvh http://satellite.example.com/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
- Register the system with the Red Hat Proxy or Red Hat Satellite:
# rhnreg_ks --activationkey mykey --serverUrl https://satellite.example.com/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
bootstrap.sh) that Satellite generates. The bootstrap script, available for both Red Hat Satellite Server and Red Hat Proxy Server, is such a script. Script generation is discussed more in detail in 4.1.1. Using Red Hat Network Bootstrap to Register a System of the Getting Started Guide.
2.3. Updating the Configuration Files Manually
noSSLServerURLsettings in the
/etc/sysconfig/rhn/up2dateconfiguration file (as root). Replace the default Red Hat Network URL with the fully qualified domain name (FQDN) of the Proxy or Satellite. For example:
serverURL[comment]=Remote server URL serverURL=https://your_primary.your_domain.com/XMLRPC noSSLServerURL[comment]=Remote server URL without SSL noSSLServerURL=http://your_primary.your_domain.com/XMLRPC
/etc/sysconfig/rhn/up2datedoes not refer to the Red Hat Proxy. It is used to configure an optional HTTP proxy for the client. With a Red Hat Proxy in place, the
httpProxysetting must be blank (not set to any value).
2.4. Implementing Server Failover
Procedure 2.3. To Implement Server Failover:
- Ensure that you are running Red Hat Enterprise Linux 5, 6, or 7. For Red Hat Enterprise Linux 3 or 4, use the latest version of
- Manually add the secondary servers to the
noSSLServerURLsettings in the
/etc/sysconfig/rhn/up2dateconfiguration file (as root).
- Add the fully qualified domain names (FQDN) of Red Hat Proxy or Red Hat Satellite immediately after the primary server, separated by a semicolon (;). Your client will attempt to connect to these servers in the order provided here. Include as many servers as necessary. For example:
serverURL[comment]=Remote server URL serverURL=https://satellite.example.com/XMLRPC; https://your_secondary.your_domain.com/XMLRPC; noSSLServerURL[comment]=Remote server URL without SSL noSSLServerURL=http://satellite.example.com/XMLRPC; http://your_secondary.your_domain.com/XMLRPC;
2.5. Enabling Staging Content
- A faster installation than without staging content.
- The ability to spread out client requests to the Satellite server.
- Less time needed for the installation and upgrade of client packages.
Red Hat Enterprise Linux 5.6 or later, or Red Hat Enterprise Linux 6.1 or later, is required on the client.
/etc/sysconfig/rhn/up2datein your text editor. Make the file includes the following lines:
stagingContent[comment]=Retrieve content of future actions in advance stagingContent=1 ... stagingContentWindow[comment]=How much forward we should look for future actions. In hours stagingContentWindow=24
Chapter 3. SSL Infrastructure
3.1. A Brief Introduction to SSL
- Certificate Authority (CA) SSL private key and public certificate: only one set per organization generally generated. The public certificate is digitally signed by its private key. The public certificate is distributed to every system.
- Web server SSL private key and public certificate: one set per application server. The public certificate is digitally signed by both its private key and the CA SSL private key. It is often referred to as a Web server's key set; this is because there is an intermediary SSL certificate request that is generated. The details of what this is used for are not important to this discussion. All three are deployed to a Red Hat Satellite Server.
3.2. The Red Hat Satellite SSL Maintenance Tool
rhn-ssl-tool. This tool is available as part of the
spacewalk-certs-toolspackage. This package can be found within the software channels for the latest Red Hat Proxy Server and Red Hat Satellite Server (as well as the Red Hat Satellite Server ISO). The Red Hat Satellite SSL Tool enables organizations to generate their own Certificate Authority SSL key pair, as well as Web server SSL key sets (sometimes called key pairs).
spacewalk-certs-tools, which contains
rhn-ssl-tool, can be installed and run on any current Red Hat Enterprise Linux system with minimal requirements. This is offered as a convenience for administrators who want to manage their SSL infrastructure from their workstation or another system other than their Satellite or Proxy servers.
- When updating the Certificate Authority (CA) public certificate.
- When installing a Red Hat Proxy Server 3.6 or later that connects to the central Red Hat Satellite Servers as its top-level service. The hosted service, for security reasons, cannot be a repository for the CA SSL key and certificate, which is private to the organization.
- When reconfiguring the Satellite or Proxy infrastructure to use SSL where it previously did not.
- When adding multiple Red Hat Satellite Servers to the Red Hat Satellite infrastructure. Consult with a Red Hat representative for instructions regarding this.
- During installation of a Red Hat Satellite Server. All SSL settings are configured during the installation process. The SSL keys and certificate are built and deployed automatically.
- During installation of a Red Hat Proxy Server 3.6 or later if connected to a Red Hat Satellite Server 3.6 or later as its top-level service. The Red Hat Satellite Server contains all of the SSL information needed to configure, build and deploy the Red Hat Proxy Server's SSL keys and certificates.
/pubdirectory of each server. This public certificate is used by the client systems to connect to the Red Hat Satellite Server. See Section 3.3, “Deploying the CA SSL Public Certificate to Clients” for more information.
3.2.1. Generating SSL Certificates
ssl-buildtree from an archive to the
/rootdirectory and utilize the configuration tools provided within the Red Hat Satellite Server's website.
- Install the spacewalk-certs-tools package on a system within the organization, perhaps but not necessarily the Red Hat Satellite Server or Red Hat Proxy Server.
- Create a single Certificate Authority SSL key pair for the organization and install the resulting RPM or public certificate on all client systems. See Section 3.2.3, “Generating the Certificate Authority SSL Key Pair” for more information.
- Create a Web server SSL key set for each of the Proxy and Satellite servers to be deployed and install the resulting RPM files on the Red Hat Satellite servers.
- Restart the
# service httpd restart
- Back up the SSL build tree - consisting of the primary build directory and all subdirectories and files - to removable media, such as a CD or DVD. (Disk space requirements are insignificant.)
- Verify and then store that archive in a safe location, such as the one described for backups in the Additional Requirements sections of either the Proxy or Satellite installation guide.
- Record and secure the CA password for future use.
- Delete the build tree from the build system for security purposes, but only after the entire Satellite infrastructure is in place and configured.
NoteWhen additional Web server SSL key sets are needed, restore the build tree on a system running the Red Hat Satellite SSL Maintenance Tool and repeat steps 3 through 7.
3.2.2. Red Hat Satellite SSL Maintenance Tool Options
rhn-ssl-toolfor general help.
rhn-ssl-toolfor Certificate Authority help.
rhn-ssl-toolfor Web server help.
man rhn-ssl-tool) for more information.
3.2.3. Generating the Certificate Authority SSL Key Pair
/etc/sysconfig/rhn/sslfor older Satellite and Proxy servers). To generate a CA SSL key pair, run the following command.
# rhn-ssl-tool --gen-ca \ --password=MY_CA_PASSWORD \ --dir="/root/ssl-build" \ --set-state="North Carolina" \ --set-city="Raleigh" \ --set-org="Example Inc." \ --set-org-unit="SSL CA Unit"
RHN-ORG-PRIVATE-SSL-KEY:the CA SSL private key.
RHN-ORG-TRUSTED-SSL-CERT:the CA SSL public certificate.
rhn-org-trusted-ssl-cert-VER-REL.noarch.rpm:the RPM prepared for distribution to client systems.This file contains the CA SSL public certificate (above) and installs it as
rhn-ca-openssl.cnf:the SSL CA configuration file.
latest.txt:lists the latest versions of the relevant files.
3.2.4. Generating Web Server SSL Key Sets
--set-hostnameis therefore different for each server.
/root/ssl-build/MACHINE_NAME. To generate a server certificate, run the following command.
# rhn-ssl-tool --gen-server \ --password=MY_CA_PASSWORD \ --dir="/root/ssl-build" \ --set-state="MY_STATE" \ --set-city="MY_CITY" --set-org="Example Inc." \ --set-org-unit="MY_ORG_UNIT" \ --set-email="email@example.com" \ --set-hostname="machinename.example.com"
server.key:the Web server's SSL private server key.
server.csr:the Web server's SSL certificate request.
server.crt:the web server's SSL public certificate.
rhn-org-httpd-ssl-key-pair-MACHINE_NAME-VER-REL.noarch.rpm:the RPM prepared for distribution to Satellite and Proxy Servers. Its associated
src.rpmfile is also generated.This RPM file contains the
server.crtfiles. These files are installed in the following directories:
rhn-server-openssl.cnf:the Web server's SSL configuration file.
latest.txt:lists the latest versions of the relevant files.
# service httpd restart
3.3. Deploying the CA SSL Public Certificate to Clients
/var/www/html/pub/directory of the Satellite or Proxy Server.
curlcommands to download the CA SSL public certificate to a client system.
# curl -O http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
# wget http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
/pubdirectory, you can use the
rpmcommand to install the package. For example:
# rpm -Uvh http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-VER-REL.noarch.rpm
3.4. Configuring Client Systems to Use Certificates
Chapter 4. Red Hat Satellite and Solaris-specific Information
4.1. UNIX Support Guide
4.1.1. Supported UNIX Variants
Table 4.1. Supported Solaris Architectures and Versions
- Red Hat Satellite 5.0 or later
- A Satellite certificate with Management entitlements
- Management entitlements for each UNIX client
- Red Hat Network packages for UNIX including python, pyOpenSSL, and the Red Hat Network Client packages
- Sunfreeware packages that provide supporting libraries
NoteSome of these packages are available via the Red Hat Satellite. See Section 18.104.22.168, “Downloading and Installing Additional Packages” for the complete list.
4.1.3. Included Features
- The Red Hat Network Service Daemon (
rhnsd), which triggers
rhn_checkaccording to a configurable interval
- The Red Hat Network Configuration Client (
rhncfg-client), which executes all configuration actions scheduled from the Satellite
- The Red Hat Network Configuration Manager (
rhncfg-manager), which allows command line administration of Red Hat Network configuration channels
rhn_checkprogram, which checks in with the Satellite and performs any actions scheduled from the server
- All Management-level functionality, such as system grouping, package profile comparison, and use of the System Set Manager to administer multiple systems at once
- A Provisioning feature called Remote Command which enables users to schedule root-level commands on any managed client through the Satellite's website, if the client allows this action
4.1.4. Differences in Functionality
- The Red Hat Update Agent for UNIX offers a much smaller set of options than its Linux counterpart and relies upon the operating system's native toolset for package installation, rather than
rpm- See Section 22.214.171.124.4, “Updating From the Command Line” for the precise list of options.
- The Red Hat Network Push application has been similarly modified to upload native UNIX file types, including packages, patches, and patch clusters.Since Solaris package, patch and patch cluster files are different from RPM files, the channel upload mechanism is somewhat different.There are two applications in the
rhnpushpackage for Solaris:
- The first,
solaris2mpm, is an Red Hat Network utility that creates an MPM file for each Solaris package or patch. The neutral format of the MPM file allows the Satellite to understand and manage the uploaded files.
- The second,
rhnpush, has been extended so that it can handle MPM as well as RPM files. Otherwise, it operates identically to the Linux version of
- The Channels tab of the Red Hat Network website has been augmented to accommodate the storage and installation of native UNIX file types.
4.1.5. Excluded Features
- All Provisioning-level functionality, such as kickstarting and package rollback, with the exception of configuration file management
- All Errata-related options, since the concept of Errata Updates is not understood in UNIX
- Source files for packages
RHAT*.pkgfiles during installation is not supported.
4.1.6. Satellite Server Preparation and Configuration
- During the Satellite installation:Enable UNIX support on the Satellite by checking the "Enable Solaris Support" box on the Red Hat Satellite configuration screen during the installation process.
- After the Satellite has been installed:Enable UNIX support by configuring the Satellite after it has been installed. To do so, select Enable Solaris Support box.in the top menu bar, then select in the left navigation bar. In the screen that follows, check theClick thebutton to confirm the change.
- Finally, create a base channel to which your client systems may subscribe. Red Hat Network does not provide UNIX content,
satellite-synccannot be used to create the channel.To create a Solaris channel, login to the web interface of the Satellite as either a Satellite Administrator or a certificate authority. Navigate to the Channel tab, followed by the Manage Software Channels from the left navigation bar. Click the create new channel link in the upper right of the resulting screen. Provide a name and label for your new channel, and select either SPARC Solaris or i386 Solaris as the architecture, depending on the architecture of the client.
4.1.7. UNIX Client System Preparation
- Download and install
gzipand the required third-party libraries.
- Download the Red Hat Network application tarball from the Satellite to the client and install the contents.
- Next, deploy the SSL certificates required for a secure connection.
- Configure the client applications to connect to the Red Hat Satellite.
126.96.36.199. Downloading and Installing Additional Packages
up2date), which provides the link between your client systems and Red Hat Network. The UNIX-specific version of the Red Hat Update Agent is limited in functionality compared to its Linux counterpart but still enables system registration and facilitates package installs and patches. See Section 4.1.8, “UNIX Client Registration and Updates” for a full description of the tool's options.
bashwhen first logging into the Solaris client. If the BASH shell is available, it will make the system's behavior as Linux-like as possible.
188.8.131.52.1. Installing Third-Party Packages
gziputility is provided by the SUNW gzip package and may be downloaded from http://www.sunfreeware.com.
pkginfocommand. For example, to check for a package that contains "zlib" in the name, run the following command:
# pkginfo | grep zlib
libgcc<version>-sol<solaris-version>-sparc-local.gzbecomes SMClibgcc after installation
184.108.40.206.2. Configuring the Library Search Path
# crle -c /var/ld/ld.config
-loption resets the value, rather than appending it, so if there already were values set on your system, prepend them to the -l parameter.
# crle -c /var/ld/ld.config -l /other/existing/path:/lib:/usr/lib:/usr/local/lib
# crle -c /var/ld/ld.config -l /other/existing/path:/lib:/usr/lib:/usr/local/lib:/usr/sfw/lib
220.127.116.11.3. Downloading Red Hat Network Client Packages
/var/www/html/pub/directory of your Satellite. If you are able to use a GUI web browser like Mozilla, navigate to the
/pubdirectory of the Satellite and save the appropriate tarball to your client:
ftpto transfer the file from the Satellite to the client.
gzip, decompress the tarball. You should have the following packages:
SMCosslgmay also be included in the tarball.
18.104.22.168.4. Installing the Red Hat Network Packages
pkgaddcommand. Answer "yes" to any prompts during package install.
# pkgadd -d RHATpossl-0.6-1.p24.6.pkg all # pkgadd -d RHATpythn-2.4.1-2.rhn.4.sol9.pkg all # pkgadd -d RHATrhnl-1.8-7.p23.pkg all ...
pkgaddto run the command in non-interactive mode. However, this may cause the installation of some packages to fail silently on Solaris 10.
22.214.171.124.5. Including Red Hat Network Packages in the PATH
# PATH=$PATH:/opt/redhat/rhn/solaris/bin # PATH=$PATH:/opt/redhat/rhn/solaris/usr/bin # PATH=$PATH:/opt/redhat/rhn/solaris/usr/sbin # export PATH
# MANPATH=$MANPATH:/opt/redhat/rhn/solaris/man # export MANPATH
# man -M /opt/redhat/rhn/solaris/man <man page>
crle -c /var/ld/ld.config -l <current library paths>:/opt/redhat/rhn/solaris/lib
126.96.36.199. Deploying Client SSL Certificates
/pub/directory of the Satellite's Web server.
- Download the SSL certificate from the
/var/www/html/pub/directory of the Red Hat Satellite onto the client system. The certificate will be named something similar to
RHN-ORG-TRUSTED-SSL-CERT. It is accessible via the web at the following URL:
- Move the client SSL certificate to the Red Hat Network-specific directory for your UNIX variant. For Solaris, this can be accomplished with a command similar to:
mv /path/to/RHN-ORG-TRUSTED-SSL-CERT /opt/redhat/rhn/solaris/usr/share/rhn/
188.8.131.52. Configuring the Clients
- As root, change to the Red Hat Network configuration directory for the system. For Solaris, the full path is
- Open the
up2dateconfiguration file in a text editor.
- Find the
serverURLentry and set its value to the fully qualified domain name (FQDN) of your Red Hat Satellite:
serverURL[comment]=Remote server URL serverURL=https://your-satellite.example.com/XMLRPC
- Ensure the application refers to the Red Hat Satellite even when SSL is turned off by also setting the
noSSLServerURLvalue to the Satellite:
noSSLServerURL[comment]=Remote server URL without SSL noSSLServerURL=http://your-satellite.example.com/XMLRPC
- With the
up2dateconfiguration file still open, find the
sslCACertentry and set its value to the name and location of the SSL certificate described in Section 184.108.40.206, “Deploying Client SSL Certificates”, for example:
sslCACert[comment]=The CA cert used to verify the ssl server sslCACert=/opt/redhat/rhn/solaris/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
4.1.8. UNIX Client Registration and Updates
220.127.116.11. Registering UNIX Systems
rhnreg_kscommand to accomplish this; the use of activation keys for registering your systems is optional. These keys allow you to predetermine settings within Red Hat Network, such as base channels and system groups, and to apply those automatically to systems during their registration.
- Log into the Satellite's web interface and click the Systems tab in the top navigation bar followed by Activation Keys in the left navigation bar. Then click the create new key link at the top-right corner of the page.
- On the following page, select the base channel you created at the end of Section 4.1.6, “Satellite Server Preparation and Configuration”.
- After creating the key, click its name in the Activation Keys list to enhance its Red Hat Network settings by associating software and configuration channels and system groups.
- Open a terminal on the client system to be registered and switch user to root.
rhnreg_ksalong with the
--activationkeyoption to register the client with the Satellite. The string of characters that make up the key may be copied directly from the Activation Keys list on the website. The resulting command will look something like the following:
- Go back to the website, click the name of the activation key, and ensure the new system appears within the Activated Systems tab.
18.104.22.168. Obtaining Updates
22.214.171.124.1. Uploading Packages to the Satellite
solaris2mpmto translate Solaris packages, patches, and patch clusters to a format that the Satellite can understand.
solaris2mpmis part of Red Hat Network Push for Solaris. The content that is pushed to a Solaris channel on the Satellite must first be in .mpm format.
/tmp/will be used for this purpose. However, the
--tempdiroption allows you to specify another directory if necessary.
# solaris2mpm RHATrpush-3.1.5-21.pkg RHATrpush-3.1.5-23.pkg Opening archive, this may take a while Writing out RHATrpush-3.1.5-21.sparc-solaris.mpm Opening archive, this may take a while Writing out RHATrpush-3.1.5-23.sparc-solaris.mpm
Table 4.2. solaris2mpm options
| || |
Displays the program's version number and exits
| || |
Displays this information and exits
| || |
Prints program usage information and exits
| || |
Temporary directory to work from
| || |
Selects the architecture (i386 or SPARC) for multi-arch packages.
126.96.36.199.1.2. rhnpush with .mpm Files
rhnpushworks like the standard utility, but with the added ability to handle .mpm files. Below is a usage example:
% rhnpush -v --server testbox.example.com --username myuser -c solaris-8 \ RHATrpush-3.1.5-*.mpm Red Hat Network password: Connecting to http://testbox.example.com/APP Uploading package RHATrpush-3.1.5-21.sparc-solaris.mpm Uploading package RHATrpush-3.1.5-23.sparc-solaris.mpm
188.8.131.52.2. Updating Through the Web Interface
rhnsddaemon, which instructs the client system to check in with Red Hat Network, automatically starts at boot time. On Solaris systems,
rhnsddoes not start at boot time by default. It can be started from the command line in this way:
rhnsd --foreground --interval=240
/opt/redhat/rhn/solaris/usr/sbin/rhnsd. Below are the available options for
| || |
Run in foreground
| || |
Connect to Red Hat Network every MINS minutes
| || |
Log all actions to syslog
| || |
Give this help list
| || |
Give this help list
| || |
Print program version
184.108.40.206.4. Updating From the Command Line
up2datecommand. The most significant difference is the absence of all options regarding source files. See Section 220.127.116.11.4, “Updating From the Command Line” for the precise list of options available for UNIX systems.
Table 4.4. Update Agent Command Line Arguments
| ||Show program version information.|
| ||Show this help message and exit.|
| ||Show additional output.|
| ||List the latest versions of all packages installed.|
| ||Update packages associated with this System Profile.|
| ||Update this system's hardware profile on Red Hat Network.|
| ||List all packages available for download.|
| ||List all the packages available that are not currently installed.|
| ||List all the packages currently installed that are not in channels the system is subscribed to.|
| ||Show the channel names along with the package names where appropriate.|
| || Install all available packages. Use with |
| ||Specify which channels to update from using channel labels.|
| ||Fetch the package specified without resolving dependencies.|
4.1.9. Using Remote Commands
18.104.22.168. Enabling Commands
script, the file must be named
run, and both must be located in the
/etc/sysconfig/rhn/allowed-actions/directory specific to your UNIX variant.
mkdir -p /opt/redhat/rhn/solaris/etc/sysconfig/rhn/allowed-actions/script
22.214.171.124. Issuing Commands
Chapter 5. Reporting Software Failures
5.1. Installing Software Failure Reporting Tools
Procedure 5.1. To Use the Software Failure Reporting Functionality:
- Log into your client system as the
- Install the spacewalk-abrt package on your client systems. This package installs the abrt package as a dependency.
# yum install spacewalk-abrt
NoteNeither the abrt nor spacewalk-abrt packages are available for Red Hat Enterprise Linux 5.
5.2. Using Software Failure Reporting Tools
- The configuration file for ABRT:
abrtdaemon to use the
/usr/bin/spacewalk-abrtutility to automatically report every software failure that occurs on the system to your Satellite server. This is a fully automated process and ordinarily does not require any human intervention.
5.3. Manually Reporting Software Failures
spacewalk-abrtutility to manually report software failures to your Satellite server. The following procedure shows how to perform a manually send a software failure report.
Procedure 5.2. To manually report software failures
- Use the
abrt-cli listparameter to display a list of existing failure reports.
# abrt-cli list @0 Directory: /var/tmp/abrt/ccpp-2013-02-28-15:48:50-8820 count: 2 executable: /usr/bin/python2.7 package: python-2.7.3-13.fc16 time: Thu 28 Feb 2013 03:48:50 PM CET uid: 0 @1 Directory: /var/tmp/abrt/oops-2013-02-27-14:16:03-8107-1 count: 3 package: kernel time: Wed 27 Feb 2013 02:16:03 PM CET
- After you have identified the failure that you want to report, use the
--reportoption to send the report to the Satellite server.
# spacewalk-abrt --report /var/tmp/abrt/ccpp-2013-02-28-15:48:50-8820
- To manually report all of the software failures that have occurred on your system, use the
# spacewalk-abrt --sync
5.4. Creating Software Failures for Testing
killcommand to send a signal
11argument (segmentation fault) to an example process:
# abrt-cli list # sleep 600 &  17564 # kill -11 17564 # + Segmentation fault (core dumped) sleep 600 # # abrt-cli list @0 Directory: /var/spool/abrt/ccpp-2013-05-14-04:56:17-17564 count: 1 executable: /bin/sleep package: coreutils-8.4-19.el6 time: Tue 14 May 2013 04:56:17 EDT uid: 0 #
Appendix A. Revision History
|Revision 3-32||Wed Jul 26 2017|
|Revision 3-31||Thu Aug 20 2015|
|Revision 3-30||Tue Aug 11 2015|
|Revision 3-29||Wed May 27 2015|
|Revision 3-28||Tue Feb 17 2015|
|Revision 3-27||Tue Feb 3 2015|
|Revision 3-26||Wed Jan 7 2015|
|Revision 3-25||Thu Jan 1 2015|
|Revision 3-24||Mon Dec 8 2014|
|Revision 3-23||Tues Nov 27 2014|
|Revision 3-22||Wed Oct 8 2014|
|Revision 3-21||Fri Sep 27 2013|
|Revision 3-20||Tue Sep 10 2013|
|Revision 3-19||Mon Sep 2 2013|
|Revision 3-18||Thu Aug 29 2013|
|Revision 3-17||Tue Aug 20 2013|
|Revision 3-16||Mon Jul 29 2013|
|Revision 3-15||Sun Jul 28 2013|
|Revision 3-14||Wed Jul 24 2013|
|Revision 3-13||Tue Jul 23 2013|
|Revision 3-12||Fri Jul 19 2013|
|Revision 3-11||Fri Jul 12 2013|
|Revision 3-10||Fri Jul 12 2013|
|Revision 3-8||Fri Jul 12 2013|
|Revision 3-6||Fri Jul 12 2013|
|Revision 3-5||Wed Sep 19 2012|
|Revision 3-4||Fri Aug 10 2012|
|Revision 3-0||Thu Jun 28 2012|
|Revision 2-2||Mon Aug 15 2011|
|Revision 2-1||Wed Jun 15 2011|
|Revision 2-0||Sat May 7 2011|
|Revision 1-8||Mon Feb 7 2011|
|Revision 1-7||Tue Feb 1 2011|