mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. Security content automation protocol Satellite uses the Security Content Automation Protocol (SCAP) standard to define security policies. SCAP is a framework of several specifications based on XML, such as checklists described in the Extensible Checklist Configuration Description Format (XCCDF) and vulnerabilities described in the Open Vulnerability and Assessment Language (OVAL). These specifications are encapsulated as data stream files. Checklist items in XCCDF, also known as rules , express the desired configuration of a system item. For example, a rule may specify that no one can log in to a host over SSH using the root user account. Rules can be grouped into one or more XCCDF profiles , which allows multiple profiles to share a rule. The OpenSCAP scanner tool evaluates system items on a host against the rules and generates a report in the Asset Reporting Format (ARF), which is then returned to Satellite for monitoring and analysis. Table 2.1. Specifications in the SCAP framework 1.3 supported by the OpenSCAP scanner Title Description Version SCAP Security Content Automation Protocol 1.3 XCCDF Extensible Configuration Checklist Description Format 1.2 OVAL Open Vulnerability and Assessment Language 5.11 - Asset Identification 1.1 ARF Asset Reporting Format 1.1 CCE Common Configuration Enumeration 5.0 CPE Common Platform Enumeration 2.3 CVE Common Vulnerabilities and Exposures 2.0 CVSS Common Vulnerability Scoring System 2.0 Additional resources For more information about SCAP, see the OpenSCAP project .

Commands:
Appendix A. List of Bugzillas by Component Table A.1. List of Bugzillas by Component Component Release Notes Technical Notes New Features Known Issues Notable Bug Fixes bind BZ# 1452639 binutils BZ# 1427285 , BZ# 1476412 clufter BZ# 1526494 freerdp BZ# 1347920 gcc BZ# 1535656 BZ# 1104812 gcc-libraries BZ# 1465568 git BZ# 1430723 glib2 BZ# 1154183 glibc BZ# 1437147 gmp BZ# 1430873 grub BZ# 1227194 , BZ# 1573121 , BZ# 1598553 hwdata BZ# 1489294 initscripts BZ# 1440888 BZ# 1436061 , BZ# 1518429 iproute BZ# 1476664 iptables BZ# 1459673 BZ# 1210563 kernel BZ# 1073220 , BZ# 1544565 BZ# 1146727 , BZ# 1212959 , BZ# 1274139 , BZ# 1427036 , BZ# 1445919 , BZ# 1459263 , BZ# 1463754 , BZ# 1488822 , BZ# 1492220 , BZ# 1496105 , BZ# 1535024 libica BZ# 1490894 other BZ# 1497859 , BZ# 1588352 pacemaker BZ# 1427643 , BZ# 1513199 preupgrade-assistant-el6toel7 BZ# 1366671 BZ# 1388967 selinux-policy BZ# 1558428 subscription-manager BZ# 1581359 systemtap BZ# 1525651

Commands:
9.7. Configuring Startup Order for Resource Dependencies not Managed by Pacemaker (Red Hat Enterprise Linux 7.4 and later) It is possible for a cluster to include resources with dependencies that are not themselves managed by the cluster. In this case, you must ensure that those dependencies are started before Pacemaker is started and stopped after Pacemaker is stopped. As of Red Hat Enterprise Linux 7.4, you can configure your startup order to account for this situation by means of the systemd resource-agents-deps target. You can create a systemd drop-in unit for this target and Pacemaker will order itself appropriately relative to this target. For example, if a cluster includes a resource that depends on the external service foo that is not managed by the cluster, you can create the drop-in unit /etc/systemd/system/resource-agents-deps.target.d/foo.conf that contains the following: After creating a drop-in unit, run the systemctl daemon-reload command. A cluster dependency specified in this way can be something other than a service. For example, you may have a dependency on mounting a file system at /srv , in which case you would create a systemd file srv.mount for it according to the systemd documentation, then create a drop-in unit as described here with srv.mount in the .conf file instead of foo.service to make sure that Pacemaker starts after the disk is mounted.

Commands:
[Unit] Requires=foo.service After=foo.service
Chapter 46. Red Hat Enterprise Linux System Roles Powered by Ansible The postfix role of Red Hat Enterprise Linux System Roles as a Technology Preview Red Hat Enterprise Linux System Roles provides a configuration interface for Red Hat Enterprise Linux subsystems, which makes system configuration easier through the inclusion of Ansible Roles. This interface enables managing system configurations across multiple versions of Red Hat Enterprise Linux, as well as adopting new major releases. Since Red Hat Enterprise Linux 7.4, the Red Hat Enterprise Linux System Roles packages have been distributed through the Extras channel. For details regarding Red Hat Enterprise Linux System Roles, see https://access.redhat.com/articles/3050101 . Red Hat Enterprise Linux System Roles currently consists of five roles: selinux kdump network timesync postfix The postfix role has been available as a Technology Preview since Red Hat Enterprise Linux 7.4. The remaining roles have been fully supported since Red Hat Enterprise Linux 7.6. (BZ#1439896)

Commands:
7.50. ethtool 7.50.1. RHEA-2015:1306 - ethtool enhancement update Updated ethtool packages that add one enhancement are now available for Red Hat Enterprise Linux 6. The ethtool packages provide the ethtool utility that enables querying and changing settings such as speed, port, autonegotiation, PCI locations, and checksum offload on many network devices, especially of Ethernet devices. Enhancement BZ# 1066605 This update enables the ethtool utility to accept a user-defined Receive-Side Scaling (RSS) hash key value for the Ethernet driver, which improves the performance and security of RSS. As a result, the user can set the RSS hash key value for the Ethernet driver with ethtool. Users of ethtool are advised to upgrade to these updated packages, which add this enhancement.

Commands:
Chapter 3. API index API API group APIService apiregistration.k8s.io/v1 Binding v1 CertificateSigningRequest certificates.k8s.io/v1 ClusterRole rbac.authorization.k8s.io/v1 ClusterRoleBinding rbac.authorization.k8s.io/v1 ComponentStatus v1 ConfigMap v1 ControllerRevision apps/v1 CronJob batch/v1 CSIDriver storage.k8s.io/v1 CSINode storage.k8s.io/v1 CSIStorageCapacity storage.k8s.io/v1 CustomResourceDefinition apiextensions.k8s.io/v1 DaemonSet apps/v1 Deployment apps/v1 Endpoints v1 EndpointSlice discovery.k8s.io/v1 Event v1 Event events.k8s.io/v1 Eviction policy/v1 FlowSchema flowcontrol.apiserver.k8s.io/v1beta3 HorizontalPodAutoscaler autoscaling/v2 Ingress networking.k8s.io/v1 IngressClass networking.k8s.io/v1 Job batch/v1 Lease coordination.k8s.io/v1 LimitRange v1 LocalSubjectAccessReview authorization.k8s.io/v1 LogicalVolume topolvm.io/v1 MutatingWebhookConfiguration admissionregistration.k8s.io/v1 Namespace v1 NetworkPolicy networking.k8s.io/v1 Node v1 PersistentVolume v1 PersistentVolumeClaim v1 Pod v1 PodDisruptionBudget policy/v1 PodTemplate v1 PriorityClass scheduling.k8s.io/v1 PriorityLevelConfiguration flowcontrol.apiserver.k8s.io/v1beta3 RangeAllocation security.internal.openshift.io/v1 ReplicaSet apps/v1 ReplicationController v1 ResourceQuota v1 Role rbac.authorization.k8s.io/v1 RoleBinding rbac.authorization.k8s.io/v1 Route route.openshift.io/v1 RuntimeClass node.k8s.io/v1 Scale autoscaling/v1 Secret v1 SecurityContextConstraints security.openshift.io/v1 SelfSubjectAccessReview authorization.k8s.io/v1 SelfSubjectRulesReview authorization.k8s.io/v1 Service v1 ServiceAccount v1 StatefulSet apps/v1 StorageClass storage.k8s.io/v1 StorageVersionMigration migration.k8s.io/v1alpha1 SubjectAccessReview authorization.k8s.io/v1 TokenRequest authentication.k8s.io/v1 TokenReview authentication.k8s.io/v1 ValidatingWebhookConfiguration admissionregistration.k8s.io/v1 VolumeAttachment storage.k8s.io/v1 VolumeSnapshot snapshot.storage.k8s.io/v1 VolumeSnapshotClass snapshot.storage.k8s.io/v1 VolumeSnapshotContent snapshot.storage.k8s.io/v1

Commands:
8.100. libvirt-snmp 8.100.1. RHBA-2013:1666 - libvirt-snmp bug fix update Updated libvirt-snmp packages that fix one bug are now available for Red Hat Enterprise Linux 6. The libvirt-snmp packages allow users to control and monitor the libvirt virtualization management tool through Simple Network Management Protocol (SNMP). Bug Fix BZ# 736258 Previously, closing the libvirtMib_subagent using the Ctrl+C key combination led to a memory leak. The libvirtd daemon could be also terminated sometimes. A patch has been applied to address this issue, and a memory leak no longer occurs in this scenario. Users of libvirt-snmp are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 24. Clustering Pacemaker Remote may shut down, even if its connection to the cluster is unmanaged Previously, if a Pacemaker Remote connection was unmanaged, the Pacemaker Remote daemon would never receive a shutdown acknowledgment from the cluster. As a result, Pacemaker Remote would be unable to shut down. With this fix, if a Pacemaker Remote connection is unmanaged, the cluster now immediately sends a shutdown acknowledgement to Pacemaker Remote nodes that request shutdown, rather than wait for resources to stop. As a result, Pacemaker Remote may shut down, even if its connection to the cluster is unmanaged. (BZ#1388489) pcs now validates the name and the host of a remote and guest node Previously, the pcs command did not validate whether the name or the host of a remote or guest node conflicted with a resource ID or with a cluster node, a situation that would cause the cluster not to work correctly. With this fix, validation has been added to the relevant commands and pcs does not allow a user to configure a cluster with a conflicting name or conflicting host of a remote or guest node. (BZ# 1386114 ) New syntax of master option in pcs resource create command allows correct creation of meta attributes Previously, when a pcs resource creation command included the --master flag, all options after the keyword meta were interpreted as master meta attributes. This made it impossible to create meta attributes for the primitive when the --master flag was specified. This fix provides a new syntax for specifying a resource as a master slave clone by using the following format for the command: This allows you to specify meta options as follows: Additionally, with this fix, you specify a clone resource with the clone option rather than the --clone flag, as in releases. The new format for specifying a clone resource is as follows: (BZ# 1378107 )

Commands:
pcs resource create resource_id standard:provider:type|type [resource options] master [master_options...]
pcs resource create resource_id standard:provider:type|type [resource_options] meta meta_options... master [master_options...]
pcs resource create resource_id standard:provider:type|type [resource_options] clone
9.2. pNFS Support for Parallel NFS (pNFS) as part of the NFS v4.1 standard is available starting with Red Hat Enterprise Linux 6.4. The pNFS architecture improves the scalability of NFS, with possible improvements to performance. That is, when a server implements pNFS as well, a client is able to access data through multiple sources concurrently. To enable this functionality, use the -o v4.1 mount option on mounts from a pNFS-enabled server. After the server is pNFS-enabled, the nfs_layout_nfsv41_files kernel is automatically loaded on the first mount. If the module is successfully loaded, the following message is logged in the /var/log/messages file: To verify a successful NFSv4.1 mount, run: Important Once server and client negotiate NFS v4.1 or higher, they automatically take advantage of pNFS if available. Both client and server need to support the same "layout type". Possible layout types include files , blocks , objects , flexfiles , and SCSI . Starting with Red Hat Enterprise Linux 6.4, the client only supports the files layout type and uses pNFS only when the server also supports the files layout type. Red Hat recommends using the files profiles only with Red Hat Enterprise Linux 6.6 and later. For more information on pNFS, see http://www.pnfs.com .

Commands:
kernel: nfs4filelayout_init: NFSv4 File Layout Driver Registering
mount | grep /proc/mounts
Chapter 8. Troubleshooting The following chapter describes what happens when SELinux denies access; the top three causes of problems; where to find information about correct labeling; analyzing SELinux denials; and creating custom policy modules with audit2allow . 8.1. What Happens when Access is Denied SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). Denial messages are logged when SELinux denies access. These denials are also known as "AVC denials", and are logged to a different location, depending on which daemons are running: Daemon Log Location auditd on /var/log/audit/audit.log auditd off; rsyslogd on /var/log/messages setroubleshootd, rsyslogd, and auditd on /var/log/audit/audit.log . Easier-to-read denial messages also sent to /var/log/messages If you are running the X Window System, have the setroubleshoot and setroubleshoot-server packages installed, and the setroubleshootd and auditd daemons are running, a warning is displayed when access is denied by SELinux: Clicking on 'Show' presents a detailed analysis of why SELinux denied access, and a possible solution for allowing access. If you are not running the X Window System, it is less obvious when access is denied by SELinux. For example, users browsing your website may receive an error similar to the following: For these situations, if DAC rules (standard Linux permissions) allow access, check /var/log/messages and /var/log/audit/audit.log for "SELinux is preventing" and "denied" errors respectively. This can be done by running the following commands as the Linux root user:

Commands:
Forbidden You don't have permission to access file name on this server
~]# grep "SELinux is preventing" /var/log/messages
~]# grep "denied" /var/log/audit/audit.log
Chapter 51. Securing passwords with a keystore You can use a keystore to encrypt passwords that are used for communication between Business Central and KIE Server. You should encrypt both controller and KIE Server passwords. If Business Central and KIE Server are deployed to different application servers, then both application servers should use the keystore. Use Java Cryptography Extension KeyStore (JCEKS) for your keystore because it supports symmetric keys. Note If KIE Server is not configured with JCEKS, KIE Server passwords are stored in system properties in plain text form. Prerequisites KIE Server is installed in IBM WebSphere Application Server. A KIE Server user with the kie-server role has been created, as described in Section 48.1, "Creating the KIE Server group and role" . Java 8 or higher is installed. Procedure Create a JCEKS keystore. When prompted, enter the password for the KIE Server user that you created. Set the system properties listed in the following table: Table 51.1. System properties used to load a KIE Server JCEKS System property Placeholder Description kie.keystore.keyStoreURL <KEYSTORE_URL> URL for the JCEKS that you want to use, for example file:///home/kie/keystores/keystore.jceks kie.keystore.keyStorePwd <KEYSTORE_PWD> Password for the JCEKS kie.keystore.key.server.alias <KEY_SERVER_ALIAS> Alias of the key for REST services where the password is stored kie.keystore.key.server.pwd <KEY_SERVER_PWD> Password of the alias for REST services with the stored password kie.keystore.key.ctrl.alias <KEY_CONTROL_ALIAS> Alias of the key for default REST Process Automation Controller where the password is stored kie.keystore.key.ctrl.pwd <KEY_CONTROL_PWD> Password of the alias for default REST Process Automation Controller with the stored password Start KIE Server to verify the configuration.

Commands:
Chapter 17. Telemetry 17.1. Telemetry Red Hat uses telemetry to collect anonymous usage data from Migration Toolkit for Virtualization (MTV) installations to help us improve the usability and efficiency of MTV. MTV collects the following data: Migration plan status: The number of migrations. Includes those that failed, succeeded, or were canceled. Provider: The number of migrations per provider. Includes Red Hat Virtualization, vSphere, OpenStack, OVA, and OpenShift Virtualization providers. Mode: The number of migrations by mode. Includes cold and warm migrations. Target: The number of migrations by target. Includes local and remote migrations. Plan ID: The ID number of the migration plan. The number is assigned by MTV. Metrics are calculated every 10 seconds and are reported per week, per month, and per year.

Commands:
Chapter 1. Introduction to Content Management In the context of Satellite, content is defined as the software installed on systems. This includes, but is not limited to, the base operating system, middleware services, and end-user applications. With Red Hat Satellite, you can manage the various types of content for Red Hat Enterprise Linux systems at every stage of the software life cycle. Red Hat Satellite manages the following content: Subscription management This provides organizations with a method to manage their Red Hat subscription information. Content management This provides organizations with a method to store Red Hat content and organize it in various ways.

Commands:
6.4.2. Moving Extents to a New Disk In this example, the logical volume is distributed across three physical volumes in the volume group myvg as follows: We want to move the extents of /dev/sdb1 to a new device, /dev/sdd1 . 6.4.2.1. Creating the New Physical Volume Create a new physical volume from /dev/sdd1 .

Commands:
pvs -o+pv_used PV VG Fmt Attr PSize PFree Used /dev/sda1 myvg lvm2 a- 17.15G 7.15G 10.00G /dev/sdb1 myvg lvm2 a- 17.15G 15.15G 2.00G /dev/sdc1 myvg lvm2 a- 17.15G 15.15G 2.00G
pvcreate /dev/sdd1 Physical volume "/dev/sdd1" successfully created
1.2. SystemTap Capabilities Flexibility: SystemTap's framework allows users to develop simple scripts for investigating and monitoring a wide variety of kernel functions, system calls, and other events that occur in kernel-space. With this, SystemTap is not so much a tool as it is a system that allows you to develop your own kernel-specific forensic and monitoring tools. Ease-Of-Use: as mentioned earlier, SystemTap allows users to probe kernel-space events without having to resort to the lengthy instrument, recompile, install, and reboot the kernel process. Most of the SystemTap scripts enumerated in Chapter 4, Useful SystemTap Scripts demonstrate system forensics and monitoring capabilities not natively available with other similar tools (such as top , oprofile , or ps ). These scripts are provided to give readers extensive examples of the application of SystemTap, which in turn will educate them further on the capabilities they can employ when writing their own SystemTap scripts.

Commands:
Chapter 3. Insights for Red Hat Enterprise Linux advisor service weekly-report email subscription The advisor service Weekly Report email provides a quick view of the health of your environment. The email is informative yet unobtrusive; all of the included information can be consumed at a glance. 3.1. Overview of the advisor service weekly-report email subscription The email is sent every Sunday night (United States Eastern Standard Time, UTC -05:00; Eastern Daylight Time, UTC-4:00) to the email address associated with your individual Red Hat Customer Portal user account. This enables you to begin your week well informed. You are automatically subscribed to the Weekly Report email the first time you visit the advisor service. The email provides the following information about systems registered to your account: Number of critical rule hits in your infrastructure Number of impacted systems in your infrastructure Total number of recommendations impacting your infrastructure 3.2. Unsubscribing/Subscribing to the advisor service Weekly Report email Note You are automatically subscribed to the Weekly Report email the first time you visit the advisor service. Procedure Use the following procedure to unsubscribe or subscribe to the advisor Weekly Report email: Navigate to the Notification Preferences page and log in if necessary. Locate the Red Hat Enterprise Linux heading halfway down the page on the left and click Advisor just under the heading. Under the Reports heading to the right, select or clear the Weekly Report option based on your preferences. Click Save . You will receive the email each Sunday night from the sender, Red Hat Insights noreply@redhat.com , with the subject line, Weekly Insights summary report .

Commands:
Chapter 1. Red Hat Ansible Automation Platform installation overview The Red Hat Ansible Automation Platform installation program offers you flexibility, allowing you to install Ansible Automation Platform by using a number of supported installation scenarios. Starting with Ansible Automation Platform 2.4, the installation scenarios include the optional deployment of Event-Driven Ansible controller, which introduces the automated resolution of IT requests. Regardless of the installation scenario you choose, installing Ansible Automation Platform involves the following steps: Editing the Red Hat Ansible Automation Platform installer inventory file The Ansible Automation Platform installer inventory file allows you to specify your installation scenario and describe host deployments to Ansible. The examples provided in this document show the parameter specifications needed to install that scenario for your deployment. Running the Red Hat Ansible Automation Platform installer setup script The setup script installs your private automation hub by using the required parameters defined in the inventory file. Verifying automation controller installation After installing Ansible Automation Platform, you can verify that the installation has been successful by logging in to the automation controller. Verifying automation hub installation After installing Ansible Automation Platform, you can verify that the installation has been successful by logging in to the automation hub. Verifying Event-Driven Ansible controller installation After installing Ansible Automation Platform, you can verify that the installation has been successful by logging in to the Event-Driven Ansible controller. Additional resources For more information about the supported installation scenarios, see the Red Hat Ansible Automation Platform Planning Guide . 1.1. Prerequisites You chose and obtained a platform installer from the Red Hat Ansible Automation Platform Product Software . You are installing on a machine that meets base system requirements. You have updated all of the packages to the recent version of your RHEL nodes. Warning To prevent errors, upgrade your RHEL nodes fully before installing Ansible Automation Platform. You have created a Red Hat Registry Service Account, by using the instructions in Creating Registry Service Accounts . Additional resources For more information about obtaining a platform installer or system requirements, see the Red Hat Ansible Automation Platform system requirements in the Red Hat Ansible Automation Platform Planning Guide .

Commands: