mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 24. Activity stream From the navigation panel, select Automation Execution Administration Activity Stream . An Activity Stream shows all changes for a particular object. For each change, the Activity Stream shows the time of the event, the user that initiated the event, and the action. The information displayed varies depending on the type of event. Click the icon to display the event log for the change. You can filter the Activity Stream by the initiating user, by system (if it was system initiated), or by any related object, such as a credential, job template, or schedule. The Activity Stream shows the Activity Stream for the entire instance. Most pages permit viewing an activity stream filtered for that specific object. You can view the activity stream on any page by clicking the Activity Stream icon.

Commands:
Chapter 1. Recommendations for large deployments Use the following undercloud and overcloud recommendations, specifications, and configuration for deploying a large Red Hat OpenStack Platform (RHOSP) environment. RHOSP 17.1 deployments that include more than 100 overcloud nodes are considered large environments. Red Hat has tested and validated optimum performance on a large scale environment of 750 overcloud nodes using RHOSP 17.1 without using minion. For DCN-based deployments, the number of nodes from the central and edge sites can be very high. For recommendations about DCN deployments, contact Red Hat Global Support Services.

Commands:
Chapter 4. Additional Configuration 4.1. Configuring Operating Systems with osinfo Red Hat Virtualization stores operating system configurations for virtual machines in /etc/ovirt-engine/osinfo.conf.d/00-defaults.properties . This file contains default values such as os.other.devices.display.protocols.value = spice/qxl,vnc/vga,vnc/qxl . There are only a limited number of scenarios in which you would change these values: Adding an operating system that does not appear in the list of supported guest operating systems Adding a product key (for example, os.windows_10x64.productKey.value = ) Configuring the sysprep path for a Windows virtual machine (for example, os.windows_10x64.sysprepPath.value = USD{ENGINE_USR}/conf/sysprep/sysprep.w10x64 ) Important Do not edit the actual 00-defaults.properties file. Changes will be overwritten if you upgrade or restore the Manager. Do not change values that come directly from the operating system or the Manager, such as maximum memory size. To change the operating system configurations, create an override file in /etc/ovirt-engine/osinfo.conf.d/ . The file name must begin with a value greater than 00 , so that the file appears after /etc/ovirt-engine/osinfo.conf.d/00-defaults.properties , and ends with the extension, .properties . For example, 10-productkeys.properties overrides the default file, 00-defaults.properties . The last file in the file list has precedence over earlier files. For virtual machines with Windows Server 2016 , on each RHV host, modify the /etc/modprobe.d/kvm.conf configuration file by adding the line: options kvm ignore_msrs=1

Commands:
Chapter 2. Performance tuning quickstart You can tune your Satellite Server based on expected host counts and hardware allocation using built in tuning profiles included in Satellite that are available using the installation routine's tuning flag. For more information, see Tuning Satellite Server with Predefined Profiles in Installing Satellite Server in a connected network environment . There are four sizes provided based on estimates of the number of hosts your Satellite manages. You can find the specific tuning settings for each profile in the configuration files contained in /usr/share/foreman-installer/config/foreman.hiera/tuning/sizes . Name Number of hosts Recommend RAM Recommend Cores default 0 - 5000 20 GiB 4 medium 5000 - 10000 32 GiB 8 large 10000 - 20000 64 GiB 16 extra-large 20000 - 60000 128 GiB 32 extra-extra-large 60000+ 256 GiB+ 48+ Procedure Select an installation size: default , medium , large , extra-large , or extra-extra-large . The default value is default . Run satellite-installer : Optional: Run a health check. For more information, see Section 5.1, "Applying configurations" . Optional: Tune the Ruby app server directly using the Puma Tuning section. For more information, see Section 5.2, "Puma tunings" .

Commands:
satellite-installer --tuning " My_Installation_Size "
Chapter 26. Improving CPU performance by using RCU callbacks The Read-Copy-Update ( RCU ) system is a lockless mechanism for mutual exclusion of threads inside the kernel. As a consequence of performing RCU operations, call-backs are sometimes queued on CPUs to be performed at a future moment when removing memory is safe. To improve CPU performance using RCU callbacks: You can remove CPUs from being candidates for running CPU callbacks. You can assign a CPU to handle all RCU callbacks. This CPU is called the housekeeping CPU. You can relieve CPUs from the responsibility of awakening RCU offload threads. This combination reduces the interference on CPUs that are dedicated for the user's workload. Prerequisites You have administrator privileges. The tuna package is installed 26.1. Offloading RCU callbacks You can offload RCU callbacks using the rcu_nocbs and rcu_nocb_poll kernel parameters. Procedure To remove one or more CPUs from the candidates for running RCU callbacks, specify the list of CPUs in the rcu_nocbs kernel parameter, for example: or The second example instructs the kernel that CPU 3 is a no-callback CPU. This means that RCU callbacks will not be done in the rcuc/USDCPU thread pinned to CPU 3, but in the rcuo/USDCPU thread. You can move this trhead to a housekeeping CPU to relieve CPU 3 from being assigned RCU callback jobs. 26.2. Moving RCU callbacks You can assign a housekeeping CPU to handle all RCU callback threads. To do this, use the tuna command and move all RCU callbacks to the housekeeping CPU. Procedure Move RCU callback threads to the housekeeping CPU: where x is the CPU number of the housekeeping CPU. This action relieves all CPUs other than CPU X from handling RCU callback threads. 26.3. Relieving CPUs from awakening RCU offload threads Although the RCU offload threads can perform the RCU callbacks on another CPU, each CPU is responsible for awakening the corresponding RCU offload thread. You can relieve a CPU from this responsibility, Procedure Set the rcu_nocb_poll kernel parameter. This command causes a timer to periodically raise the RCU offload threads to check if there are callbacks to run. 26.4. Additional resources Avoiding RCU Stalls in the real-time kernel (Red Hat Knowledgebase)

Commands:
rcu_nocbs=1,4-6
rcu_nocbs=3
tuna --threads=rcu --cpus=x --move
10.4. Exporting and Importing an Encrypted Database Exporting and importing encrypted databases is similar to exporting and importing regular databases. However, the encrypted information must be decrypted when you export the data and re-encrypted when you reimport it to the database. 10.4.1. Exporting an Encrypted Database To export data from an encrypted database, pass the -E parameter to the dsconf command. For example, to export the complete userRoot database with decrypted attributes: Alternatively, you can export only a specific subtree. For example, to export all data from the ou=People,dc=example,dc=com entry: For further details about using dsconf to export data, see Section 6.2.1.1.1, "Exporting a Databases Using the dsconf backend export Command" . 10.4.2. Importing an LDIF File into an Encrypted Database To import data to a database when attribute encryption is enabled: Stop the Directory Server instance: If you replaced the certificate database between the last export and this import, edit the /etc/dirsrv/slapd- instance_name /dse.ldif file, and remove the following entries including their attributes: cn=AES,cn=encrypted attribute keys,cn= database_name ,cn=ldbm database,cn=plugins,cn=config cn=3DES,cn=encrypted attribute keys,cn= database_name ,cn=ldbm database,cn=plugins,cn=config Important Remove the entries for all databases. If any entry that contains the nsSymmetricKey attribute is left in the /etc/dirsrv/slapd- instance_name /dse.ldif file, Directory Server will fail to start. Import the LDIF file. For example, to import the /tmp/example.ldif into the userRoot database: The --encrypted parameter enables the script to encrypt attributes configured for encryption during the import. Start the instance:

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com backend export -E userRoot
dsconf -D "cn=Directory Manager" ldap://server.example.com backend export -E -s "ou=People,dc=example,dc=com" userRoot
dsctl instance_name stop
dsctl instance_name ldif2db --encrypted userRoot /tmp/example.ldif
dsctl instance_name start
2.3.2. Unpatched Services Most server applications that are included in a default installation are solid, thoroughly tested pieces of software. Having been in use in production environments for many years, their code has been thoroughly refined and many of the bugs have been found and fixed. However, there is no such thing as perfect software and there is always room for further refinement. Moreover, newer software is often not as rigorously tested as one might expect, because of its recent arrival to production environments or because it may not be as popular as other server software. Developers and system administrators often find exploitable bugs in server applications and publish the information on bug tracking and security-related websites such as the Bugtraq mailing list ( http://www.securityfocus.com ) or the Computer Emergency Response Team (CERT) website ( http://www.cert.org ). Although these mechanisms are an effective way of alerting the community to security vulnerabilities, it is up to system administrators to patch their systems promptly. This is particularly true because crackers have access to these same vulnerability tracking services and will use the information to crack unpatched systems whenever they can. Good system administration requires vigilance, constant bug tracking, and proper system maintenance to ensure a more secure computing environment. Refer to Chapter 3, Security Updates for more information about keeping a system up-to-date.

Commands:
Chapter 3. Launching a Non-clustered JBoss EAP Instance This chapter lists the steps to launch a non-clustered instance of JBoss EAP on a Red Hat Amazon Machine Image (AMI) created through a private AMI or public Marketplace listing. Prerequisites A suitable Red Hat AMI. See Supported Red Hat AMIs for more information. A pre-configured Security Group that allows incoming requests on at least ports 22, 8080, and 9990. Launch a Non-Clustered JBoss EAP Instance Note You can connect to an EC2 instance through ssh as the ec2-user user. If you need administrative privileges, you can change to root user later. For example, Launch the Red Hat AMI instance. A non-clustered instance of JBoss EAP has been configured and launched on a Red Hat AMI. To configure JBoss EAP, you can pass arguments to the service directly. Some arguments may not be handled in this way. The location of the service configuration files is: RHEL 6: /etc/sysconfig/eap7-standalone RHEL 7: /etc/opt/rh/eap7/wildfly/eap7-standalone.conf See System Paths for more details about system paths. Note For complex configuration, you can either use the standalone.conf file in the JBoss EAP bin directory: /opt/rh/eap7/root/usr/share/wildfly/bin/ , or you can start the JBoss EAP service and configure the server using CLI. The script can be found in the bin directory. Then, reload the configuration. You must regularly run the yum -y update to apply security fixes and enhancements. To start JBoss EAP on RHEL 6, run the following command: To start JBoss EAP on RHEL 7, run the following command: To stop JBoss EAP on RHEL 6, run the following command: To stop JBoss EAP on RHEL 7, run the following command: Note The systemctl command is relevant to only RHEL 7. Note If you want to bind JBoss EAP to a different IP address, add the following line in the /etc/opt/rh/eap7/wildfly/eap7-standalone.conf file on RHEL 7. The internal IP address is translated into a public IP address by EC2.

Commands:
ssh -l ec2-user USD{INSTANCE_PUBLIC_IP} sudo su -
service eap7-standalone start
systemctl start eap7-standalone
service eap7-standalone stop
systemctl stop eap7-standalone
WILDFLY_BIND=USDYOUR_PRIVATE_IP_ADDRESS
9.7. Enabling a Publishing Queue Part of the enrollment process includes publishing the issued certificate to any directories or files. This, essentially, closes out the initial certificate request. However, publishing a certificate to an external network can significantly slow down the issuance process - which leaves the request open. To avoid this situation, administrators can enable a publishing queue . The publishing queue separates the publishing operation (which may involve an external LDAP directory) from the request and enrollment operations, which uses a separate request queue. The request queue is updated immediately to show that the enrollment process is complete, while the publishing queue sends the information at the pace of the network traffic. The publishing queue sets a defined, limited number of threads that publish generated certificates, rather than opening a new thread for each approved certificate. The publishing queue is disabled by default. It can be enabled in the CA Console, along with enabling publishing. Note pkiconsole is being deprecated. Note While the publishing queue is disabled by default, the queue is automatically enabled if LDAP publishing is enabled in the Console . Otherwise, the queue can be enabled manually. Figure 9.1. Enabling the Publishing Queue Note Enabling the publishing queue by editing the CS.cfg file allows administrators to set other options for publishing, like the number of threads to use for publishing operations and the queue page size. For instruction on how to configure this feature by editing the CS.cfg file, see the Enabling and Configuring a Publishing Queue section in the Red Hat Certificate System Planning, Installation, and Deployment Guide .

Commands:
C.7. Bmap tracepoints Block mapping is a task central to any file system. GFS2 uses a traditional bitmap-based system with two bits per block. The main purpose of the tracepoints in this subsystem is to allow monitoring of the time taken to allocate and map blocks. The gfs2_bmap tracepoint is called twice for each bmap operation: once at the start to display the bmap request, and once at the end to display the result. This makes it easy to match the requests and results together and measure the time taken to map blocks in different parts of the file system, different file offsets, or even of different files. It is also possible to see what the average extent sizes being returned are in comparison to those being requested. To keep track of allocated blocks, gfs2_block_alloc is called not only on allocations, but also on freeing of blocks. Since the allocations are all referenced according to the inode for which the block is intended, this can be used to track which physical blocks belong to which files in a live file system. This is particularly useful when combined with blktrace , which will show problematic I/O patterns that may then be referred back to the relevant inodes using the mapping gained by means of this tracepoint.

Commands:
16.14.2. Upgrading Using the Installer Note In general, Red Hat recommends that you keep user data on a separate /home partition and perform a fresh installation. For more information on partitions and how to set them up, refer to Section 9.13, "Disk Partitioning Setup" . If you choose to upgrade your system using the installation program, any software not provided by Red Hat Enterprise Linux that conflicts with Red Hat Enterprise Linux software is overwritten. Before you begin an upgrade this way, make a list of your system's current packages for later reference: After installation, consult this list to discover which packages you may need to rebuild or retrieve from sources other than Red Hat. , make a backup of any system configuration data: Make a complete backup of any important data before performing an upgrade. Important data may include the contents of your entire /home directory as well as content from services such as an Apache, FTP, or SQL server, or a source code management system. Although upgrades are not destructive, if you perform one improperly there is a small possibility of data loss. Warning Note that the above examples store backup materials in a /home directory. If your /home directory is not a separate partition, you should not follow these examples verbatim! Store your backups on another device such as CD or DVD discs or an external hard disk. For more information on completing the upgrade process later, refer to Section 35.2, "Finishing an Upgrade" .

Commands:
-qa --qf '%{NAME} %{VERSION}-%{RELEASE} %{ARCH}\n' > ~/old-pkglist.txt
su -c 'tar czf /tmp/etc-`date +%F`.tar.gz /etc' su -c 'mv /tmp/etc-*.tar.gz /home'
6.3. Rebooting or Resetting a Virtual Machine You can restart your virtual machines in two different ways; either using reboot or reset. Several situations can occur where you need to reboot the virtual machine, such as after an update or configuration change. When you reboot, the virtual machine's console remains open while the guest operating system is restarted. If a guest operating system can not be loaded or has become unresponsive, you need to reset the virtual machine. When you reset, the virtual machine's console remains open while the guest operating system is restarted. Note The reset reset operation can only be performed from the Administration Portal. Rebooting a Virtual Machine To reboot a virtual machine: Click Compute Virtual Machines and select a running virtual machine. Click Reboot or right-click the virtual machine and select Reboot from the pop-up menu. Click OK in the Reboot Virtual Machine(s) confirmation window. Resetting a Virtual Machine To reset a virtual machine: Click Compute Virtual Machines and select a running virtual machine. Click the down arrow to Reboot , then click Reset , or right-click the virtual machine and select Reset from the pop-up menu. Click OK in the Reset Virtual Machine(s) confirmation window. During reboot and reset operations, the Status of the virtual machine changes to Reboot In Progress before returning to Up .

Commands:
Chapter 22. KafkaAuthorizationOpa schema reference Used in: KafkaClusterSpec Full list of KafkaAuthorizationOpa schema properties Configures the Kafka custom resource to use Open Policy Agent authorization. To use Open Policy Agent authorization, set the type property in the authorization section to the value opa , and configure OPA properties as required. Streams for Apache Kafka uses the Open Policy Agent plugin for Kafka authorization as the authorizer. For more information about the format of the input data and policy examples, see Open Policy Agent plugin for Kafka authorization . Example Open Policy Agent authorizer configuration apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster namespace: myproject spec: kafka: # ... authorization: type: opa url: http://opa:8181/v1/data/kafka/allow allowOnError: false initialCacheCapacity: 1000 maximumCacheSize: 10000 expireAfterMs: 60000 superUsers: - CN=user-1 - user-2 - CN=user-3 # ... 22.1. KafkaAuthorizationOpa schema properties The type property is a discriminator that distinguishes use of the KafkaAuthorizationOpa type from KafkaAuthorizationSimple , KafkaAuthorizationKeycloak , KafkaAuthorizationCustom . It must have the value opa for the type KafkaAuthorizationOpa . Property Property type Description type string Must be opa . url string The URL used to connect to the Open Policy Agent server. The URL has to include the policy which will be queried by the authorizer. This option is required. allowOnError boolean Defines whether a Kafka client should be allowed or denied by default when the authorizer fails to query the Open Policy Agent, for example, when it is temporarily unavailable). Defaults to false - all actions will be denied. initialCacheCapacity integer Initial capacity of the local cache used by the authorizer to avoid querying the Open Policy Agent for every request Defaults to 5000 . maximumCacheSize integer Maximum capacity of the local cache used by the authorizer to avoid querying the Open Policy Agent for every request. Defaults to 50000 . expireAfterMs integer The expiration of the records kept in the local cache to avoid querying the Open Policy Agent for every request. Defines how often the cached authorization decisions are reloaded from the Open Policy Agent server. In milliseconds. Defaults to 3600000 . tlsTrustedCertificates CertSecretSource array Trusted certificates for TLS connection to the OPA server. superUsers string array List of super users, which is specifically a list of user principals that have unlimited access rights. enableMetrics boolean Defines whether the Open Policy Agent authorizer plugin should provide metrics. Defaults to false .

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster namespace: myproject spec: kafka: # authorization: type: opa url: http://opa:8181/v1/data/kafka/allow allowOnError: false initialCacheCapacity: 1000 maximumCacheSize: 10000 expireAfterMs: 60000 superUsers: - CN=user-1 - user-2 - CN=user-3 #
Chapter 1. About Red Hat Insights Powered by predictive analytics, Red Hat Insights gets smarter with every additional piece of intelligence and data. It can automatically discover relevant insights, recommend tailored, proactive, actions, and even automate tasks. Using Red Hat Insights, customers can benefit from the experience and technical knowledge of Red Hat Certified Engineers, making it easier to identify, prioritize and resolve issues before business operations are affected. As a SaaS offering, Red Hat Insights is regularly updated. Regular updates expand the Insights knowledge archive in real time to reflect new IT challenges that can impact the stability of mission-critical systems.

Commands: