mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 10. Integrating by using the syslog protocol Syslog is an event logging protocol that applications use to send messages to a central location, such as a SIEM or a syslog collector, for data retention and security investigations. With Red Hat Advanced Cluster Security for Kubernetes, you can send alerts and audit events using the syslog protocol. Note Forwarding events by using the syslog protocol requires the Red Hat Advanced Cluster Security for Kubernetes version 3.0.52 or newer. When you use the syslog integration, Red Hat Advanced Cluster Security for Kubernetes forwards both violation alerts that you configure and all audit events. Currently, Red Hat Advanced Cluster Security for Kubernetes only supports CEF (Common Event Format). The following steps represent a high-level workflow for integrating Red Hat Advanced Cluster Security for Kubernetes with a syslog events receiver: Set up a syslog events receiver to receive alerts. Use the receiver's address and port number to set up notifications in the Red Hat Advanced Cluster Security for Kubernetes. After the configuration, Red Hat Advanced Cluster Security for Kubernetes automatically sends all violations and audit events to the configured syslog receiver. 10.1. Configuring syslog integration with Red Hat Advanced Cluster Security for Kubernetes Create a new syslog integration in Red Hat Advanced Cluster Security for Kubernetes (RHACS). Procedure In the RHACS portal, go to Platform Configuration Integrations . Scroll down to the Notifier Integrations section and select Syslog . Click New Integration (add icon). Enter a name for Integration Name . Select the Logging Facility value from local0 through local7 . Enter your Receiver Host address and Receiver Port number. If you are using TLS, turn on the Use TLS toggle. If your syslog receiver uses a certificate that is not trusted, turn on the Disable TLS Certificate Validation (Insecure) toggle. Otherwise, leave this toggle off. Click Add new extra field to add extra fields. For example, if your syslog receiver accepts objects from multiple sources, type source and rhacs in the Key and Value fields. You can filter using the custom values in your syslog receiver to identify all alerts from RHACS. Select Test ( checkmark icon) to send a test message to verify that the integration with your generic webhook is working. Select Create ( save icon) to create the configuration.

Commands:
Chapter 1. Overview Red Hat Ansible Automation Platform simplifies the development and operation of automation workloads for managing enterprise application infrastructure lifecycles. It works across multiple IT domains including operations, networking, security, and development, as well as across diverse hybrid environments. Simple to adopt, use, and understand, Red Hat Ansible Automation Platform provides the tools needed to rapidly implement enterprise-wide automation, no matter where you are in your automation journey. 1.1. What's included in Ansible Automation Platform Ansible Automation Platform Automation controller Automation hub Automation services catalog Insights for Ansible Automation Platform 2.3 4.3 4.6 hosted service 1.0 Private (Technology Preview) hosted service (Retired) hosted service 1.2. Red Hat Ansible Automation Platform life cycle Red Hat publishes a product life cycle page that identifies the levels of maintenance for each Ansible Automation Platform release. Refer to Red Hat Ansible Automation Platform Life Cycle . 1.3. Upgrading Ansible Automation platform Use installer to perform upgrades to maintenance versions of Ansible Automation Platform. The installer performs all necessary actions required to upgrade to the latest versions of Ansible Automation Platform, including Ansible Tower and Private Automation Hub. Important Do not use yum update to run upgrades. Use installer instead. Additional resources Refer to the table in What's included in Ansible Automation Platform for information on maintenance releases of Ansible Automation Platform. For more information on upgrading your Ansible Automation Platform, see the Red Hat Ansible Automation Platform Upgrade and Migration Guide . For procedures related to using the Ansible Automation Platform installer, see the Ansible Automation Platform Installation Guide .

Commands:
8.244. xorg-x11-server 8.244.1. RHSA-2013:1620 - Low: xorg-x11-server security and bug fix update Updated xorg-x11-server packages that fix one security issue and several bugs are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having low security impact. Common Vulnerability Scoring System (CVSS) base scores, which give detailed severity ratings, are available for each vulnerability from the CVE links associated with each description below. X.Org is an open source implementation of the X Window System. It provides the basic low-level functionality that full-fledged graphical user interfaces are designed upon. Security Fix CVE-2013-1940 A flaw was found in the way the X.org X11 server registered new hot plugged devices. If a local user switched to a different session and plugged in a new device, input from that device could become available in the session, possibly leading to information disclosure. This issue was found by David Airlie and Peter Hutterer of Red Hat. Bug Fixes BZ# 915202 A upstream patch modified the Xephyr X server to be resizeable, however, it did not enable the resize functionality by default. As a consequence, X sandboxes were not resizeable on Red Hat Enterprise Linux 6.4 and later. This update enables the resize functionality by default so that X sandboxes can now be resized as expected. BZ# 957298 In Red Hat Enterprise Linux 6, the X Security extension (XC-SECURITY) has been disabled and replaced by X Access Control Extension (XACE). However, XACE does not yet include functionality that was previously available in XC-SECURITY. With this update, XC-SECURITY is enabled in the xorg-x11-server spec file on Red Hat Enterprise Linux 6. BZ# 969538 Upstream code changes to extension initialization accidentally disabled the GLX extension in Xvfb (the X virtual frame buffer), rendering headless 3D applications not functional. An upstream patch to this problem has been backported so the GLX extension is enabled again, and applications relying on this extension work as expected. All xorg-x11-server users are advised to upgrade to these updated packages, which contain backported patches to correct these issues.

Commands:
Chapter 6. Configuring Redis storage for rate limiting To configure persistence for rate limit counters in a multicluster environment, you must configure the connection details for your shared Redis-based datastore. This datastore is used to persist shared rate limit counters for the Limitador component of Connectivity Link. Note You must configure connection details for your shared Redis-based datastore on each OpenShift cluster that you want to use Connectivity Link for rate limiting. Prerequisites See Chapter 1, Connectivity Link prerequisites and permissions . Procedure Set the following environment variable to your shared Redis-based instance URL: Ensure that you include the appropriate URI scheme for your environment: Secure Redis: rediss:// Standard Redis: redis:// Create a Secret resource for your Redis URL as follows: Update your Limitador custom resource to use the secret that you created as follows: Additional resources For details on how to set up your shared Redis-based datastore, see your Redis-compatible product documentation: Redis documentation . AWS ElastiCache (Redis OSS) User Guide . Dragonfly documentation .

Commands:
export REDIS_URL=rediss://user:xxxxxx@some-redis.com:10340
-n kuadrant-system create secret generic redis-config --from-literal=URL=USDREDIS_URL
patch limitador limitador --type=merge -n kuadrant-system -p ' spec: storage: redis: configSecretRef: name: redis-config '
Chapter 7. Uninstalling a cluster on Azure Stack Hub You can remove a cluster that you deployed to Azure Stack Hub. 7.1. Removing a cluster that uses installer-provisioned infrastructure You can remove a cluster that uses installer-provisioned infrastructure from your cloud. Note After uninstallation, check your cloud provider for any resources not removed properly, especially with User Provisioned Infrastructure (UPI) clusters. There might be resources that the installer did not create or that the installer is unable to access. Prerequisites You have a copy of the installation program that you used to deploy the cluster. You have the files that the installation program generated when you created your cluster. Procedure From the directory that contains the installation program on the computer that you used to install the cluster, run the following command: USD ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info 1 2 1 For <installation_directory> , specify the path to the directory that you stored the installation files in. 2 To view different details, specify warn , debug , or error instead of info . Note You must specify the directory that contains the cluster definition files for your cluster. The installation program requires the metadata.json file in this directory to delete the cluster. Optional: Delete the <installation_directory> directory and the OpenShift Container Platform installation program.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
Appendix D. Overriding Ceph Default Settings Unless otherwise specified in the Ansible configuration files, Ceph uses its default settings. Because Ansible manages the Ceph configuration file, edit the /usr/share/ceph-ansible/group_vars/all.yml file to change the Ceph configuration. Use the ceph_conf_overrides setting to override the default Ceph configuration. Ansible supports the same sections as the Ceph configuration file; [global] , [mon] , [osd] , [mds] , [rgw] , and so on. You can also override particular instances, such as a particular Ceph Object Gateway instance. For example: Note Do not use a variable as a key in the ceph_conf_overrides setting. You must pass the absolute label for the host for the section(s) for which you want to override particular configuration value. Note Ansible does not include braces when referring to a particular section of the Ceph configuration file. Sections and settings names are terminated with a colon. Important Do not set the cluster network with the cluster_network parameter in the CONFIG OVERRIDE section because this can cause two conflicting cluster networks being set in the Ceph configuration file. To set the cluster network, use the cluster_network parameter in the CEPH CONFIGURATION section. For details, see Installing a Red Hat Ceph Storage cluster in the Red Hat Ceph Storage Installation Guide .

Commands:
################### CONFIG OVERRIDE # ################### ceph_conf_overrides: client.rgw.server601.rgw1: rgw_enable_ops_log: true log_file: /var/log/ceph/ceph-rgw-rgw1.log
20.16.14. Consoles, Serial, Parallel, and Channel Devices A character device provides a way to interact with the virtual machine. Paravirtualized consoles, serial ports, parallel ports and channels are all classed as character devices and so represented using the same syntax. To specify the consols, channel and other devices configuration settings, use a management tool to make the following changes to the domain XML: ... <devices> <parallel type='pty'> <source path='/dev/pts/2'/> <target port='0'/> </parallel> <serial type='pty'> <source path='/dev/pts/3'/> <target port='0'/> </serial> <console type='pty'> <source path='/dev/pts/4'/> <target port='0'/> </console> <channel type='unix'> <source mode='bind' path='/tmp/guestfwd'/> <target type='guestfwd' address='10.0.2.1' port='4600'/> </channel> </devices> ... Figure 20.59. Consoles, serial, parallel, and channel devices In each of these directives, the top-level element name (parallel, serial, console, channel) describes how the device is presented to the guest virtual machine. The guest virtual machine interface is configured by the target element. The interface presented to the host physical machine is given in the type attribute of the top-level element. The host physical machine interface is configured by the source element. The source element may contain an optional seclabel to override the way that labelling is done on the socket path. If this element is not present, the security label is inherited from the per-domain setting. Each character device element has an optional sub-element address which can tie the device to a particular controller or PCI slot.

Commands:
<devices> <parallel type='pty'> <source path='/dev/pts/2'/> <target port='0'/> </parallel> <serial type='pty'> <source path='/dev/pts/3'/> <target port='0'/> </serial> <console type='pty'> <source path='/dev/pts/4'/> <target port='0'/> </console> <channel type='unix'> <source mode='bind' path='/tmp/guestfwd'/> <target type='guestfwd' address='10.0.2.1' port='4600'/> </channel> </devices>
3.13. Required Networks, Optional Networks, and Virtual Machine Networks A required network is a logical network that must be available to all hosts in a cluster. When a host's required network becomes non-operational, virtual machines running on that host are migrated to another host; the extent of this migration is dependent upon the chosen scheduling policy. This is beneficial if you have virtual machines running mission critical workloads. An optional network is a logical network that has not been explicitly declared as Required . Optional networks can be implemented on only the hosts that use them. The presence or absence of optional networks does not affect the Operational status of a host. When a non-required network becomes non-operational, the virtual machines running on the network are not migrated to another host. This prevents unnecessary I/O overload caused by mass migrations. Note that when a logical network is created and added to clusters, the Required box is checked by default. To change a network's Required designation, from the Administration Portal, select a network, click the Cluster tab, and click the Manage Networks button. Virtual machine networks (called a VM network in the user interface) are logical networks designated to carry only virtual machine network traffic. Virtual machine networks can be required or optional. Virtual machines that uses an optional virtual machine network will only start on hosts with that network.

Commands:
34.3. Split Brain Timing: Recovering From a Split After a split occurs JBoss Data Grid will merge the partitions back, and the maximum time to detect a merge after the network partition is healed is: In some cases multiple merges will occur after a split so that the cluster may contain all available partitions. In this case, where multiple merges occur, time should be allowed for all of these to complete, and as there may be as many as three merges occurring sequentially the total delay should be no more than the following: Important The amount of time taken in the formulas above is how long it takes JBoss Data Grid to install a cluster view without the leavers; however, as JBoss Data Grid runs inside a JVM excessive Garbage Collection (GC) times can increase this time beyond the failure detection outlined above. JBoss Data Grid has no control over these GC times, and excessive GC on the coordinator can delay this detection by an amount equal to the GC time. In addition, when merging cluster views JBoss Data Grid tries to confirm all members are present; however, there is no upper bound on waiting for these responses, and merging the cluster views may be delayed due to networking issues. Report a bug

Commands:
3.1 * MERGE3.max_interval
10 * MERGE3.max_interval
Chapter 336. Options The OpenApi module can be configured using the following options. To configure using a servlet you use the init-param as shown above. When configuring directly in the rest-dsl, you use the appropriate method, such as enableCORS , host,contextPath , dsl. The options with api.xxx is configured using apiProperty dsl. Option Type Description cors Boolean Whether to enable CORS. Notice this only enables CORS for the api browser, and not the actual access to the REST services. Is default false. openapi.version String OpenApi spec version. Is default 3.0. host String To setup the hostname. If not configured camel-openapi-java will calculate the name as localhost based. schemes String The protocol schemes to use. Multiple values can be separated by comma such as "http,https". The default value is "http". base.path String Required : To setup the base path where the REST services is available. The path is relative (eg do not start with http/https) and camel-openapi-java will calculate the absolute base path at runtime, which will be protocol://host:port/context-path/base.path api.path String To setup the path where the API is available (eg /api-docs). The path is relative (eg do not start with http/https) and camel-openapi-java will calculate the absolute base path at runtime, which will be protocol://host:port/context-path/api.path So using relative paths is much easier. See above for an example. api.version String The version of the api. Is default 0.0.0. api.title String The title of the application. api.description String A short description of the application. api.termsOfService String A URL to the Terms of Service of the API. api.contact.name String Name of person or organization to contact api.contact.email String An email to be used for API-related correspondence. api.contact.url String A URL to a website for more contact information. api.license.name String The license name used for the API. api.license.url String A URL to the license used for the API. apiContextIdListing boolean Whether to allow listing all the CamelContext names in the JVM that has REST services. When enabled then the root path of the api-doc will list all the contexts. When disabled then no context ids is listed and the root path of the api-doc lists the current CamelContext. Is default false. apiContextIdPattern String A pattern that allows to filter which CamelContext names is shown in the context listing. The pattern is using regular expression and * as wildcard. Its the same pattern matching as used by Intercept

Commands:
5.8.4. Multiple NFS Mounts When mounting multiple mounts from the same NFS export, attempting to override the SELinux context of each mount with a different context, results in subsequent mount commands failing. In the following example, the NFS server has a single export, /export , which has two subdirectories, web/ and database/ . The following commands attempt two mounts from a single NFS export, and try to override the context for each one: The second mount command fails, and the following is logged to /var/log/messages : To mount multiple mounts from a single NFS export, with each mount having a different context, use the -o nosharecache,context options. The following example mounts multiple mounts from a single NFS export, with a different context for each mount (allowing a single service access to each one): In this example, server:/export/web is mounted locally to /local/web/ , with all files being labeled with the httpd_sys_content_t type, allowing Apache HTTP Server access. server:/export/database is mounted locally to /local/database , with all files being labeled with the mysqld_db_t type, allowing MySQL access. These type changes are not written to disk. Important The nosharecache options allows you to mount the same subdirectory of an export multiple times with different contexts (for example, mounting /export/web multiple times). Do not mount the same subdirectory from an export multiple times with different contexts, as this creates an overlapping mount, where files are accessible under two different contexts.

Commands:
~]# mount server:/export/web /local/web -o context="system_u:object_r:httpd_sys_content_t:s0" ~]# mount server:/export/database /local/database -o context="system_u:object_r:mysqld_db_t:s0"
kernel: SELinux: mount invalid. Same superblock, different security settings for (dev 0:15, type nfs)
~]# mount server:/export/web /local/web -o nosharecache,context="system_u:object_r:httpd_sys_content_t:s0" ~]# mount server:/export/database /local/database -o \ nosharecache,context="system_u:object_r:mysqld_db_t:s0"
Chapter 12. Monitor Red Hat JBoss Data Grid Applications in Red Hat JBoss EAP Red Hat JBoss Data Grid library applications (in the form of WAR or EAR files) can be deployed within JBoss Enterprise Application Server 6 (or better) and then monitored using JBoss Operations Network. Report a bug 12.1. Prerequisites The following are prerequisites to monitor a Red Hat JBoss Data Grid library application in JBoss Enterprise Application Platform: Install and configure JBoss Enterprise Application Platform 6 (or better). Install and configure JBoss Operations Network 3.2.2 (or better). Install and configure JBoss Data Grid (6.3 or better) Library mode plug-in. Report a bug

Commands:
Preface Thank you for your interest in Red Hat Ansible Automation Platform automation controller. Automation controller helps teams manage complex multitiered deployments by adding control, knowledge, and delegation to Ansible-powered environments. The Automation controller User Guide describes all of the functionality available in automation controller. It assumes moderate familiarity with Ansible, including concepts such as playbooks, variables, and tags. For more information about these and other Ansible concepts, see the Ansible documentation .

Commands:
7.100. kdelibs3 7.100.1. RHBA-2012:1244 - kdelibs3 bug fix update Updated kdelibs3 packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The kdelibs3 packages provide libraries for the K Desktop Environment (KDE). Bug Fixes BZ# 681901 Prior to this update, the kdelibs3 libraries caused a conflict for the subversion version control tool. As a consequence, subvervision was not correctly built if the kdelibs3 libraries were installed. This update modifies the underlying code to avoid this conflict. Now, subversion builds as expected with kdelibs3. BZ# 734447 kdelibs3 provided its own set of trusted Certificate Authority (CA) certificates. This update makes kdelibs3 use the system set from the ca-certificates package, instead of its own copy. All users of kdelibs3 are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 14. Containerizing an Application from Packages For multiple reasons, it may be advantageous to distribute an application packaged in an RPM package as a container. Prerequisites Understanding of containers An application packaged as one or more RPM packages Procedure To containerize an application from RPM packages, see Getting Started with Containers - Creating Docker images . Additional Information OpenShift Container Platform - Creating Images Red Hat Enterprise Linux Atomic Host - Getting Started with Containers Product Documentation for Red Hat Enterprise Linux Atomic Host Docker Documentation - Get Started, Part 2: Containers Docker Documentation - Dockerfile reference Red Hat Container Catalog listing - Base Images

Commands: