mtpti5iD/redhat-docs_dataset huggingface dataset:
3.5. devices The devices subsystem allows or denies access to devices by tasks in a cgroup. Important The Device Whitelist ( devices ) subsystem is considered to be a Technology Preview in Red Hat Enterprise Linux 6. Technology Preview features are currently not supported under Red Hat Enterprise Linux 6 subscription services, might not be functionally complete and are generally not suitable for production use. However, Red Hat includes these features in the operating system as a customer convenience and to increase the features' exposure. You might find these features useful in a non-production environment and are also welcome to provide feedback and functionality suggestions for a Technology Preview feature before it becomes fully supported. devices.allow specifies devices to which tasks in a cgroup have access. Each entry has four fields: type , major , minor , and access . The values used in the type , major , and minor fields correspond to device types and node numbers specified in Linux Allocated Devices , otherwise known as the Linux Devices List and available from https://www.kernel.org/doc/html/v4.11/admin-guide/devices.html . type type can have one of the following three values: a - applies to all devices, both character devices and block devices b - specifies a block device c - specifies a character device major, minor major and minor are device node numbers specified by Linux Allocated Devices . The major and minor numbers are separated by a colon. For example, 8 is the major number that specifies Small Computer System Interface (SCSI) disk drives, and the minor number 1 specifies the first partition on the first SCSI disk drive; therefore 8:1 fully specifies this partition, corresponding to a file system location of /dev/sda1 . * can stand for all major or all minor device nodes, for example 9:* (all RAID devices) or *:* (all devices). access access is a sequence of one or more of the following letters: r - allows tasks to read from the specified device w - allows tasks to write to the specified device m - allows tasks to create device files that do not yet exist For example, when access is specified as r , tasks can only read from the specified device, but when access is specified as rw , tasks can read from and write to the device. devices.deny specifies devices that tasks in a cgroup cannot access. The syntax of entries is identical with devices.allow . devices.list reports the devices for which access controls have been set for tasks in this cgroup.

Commands:
Chapter 5. Managing subscriptions in the web console You can manage your Red Hat product subscriptions in the Red Hat Enterprise Linux 8 web console. Prerequisites Your Red Hat Customer Portal or a subscription activation key. 5.1. Subscription management in the web console The RHEL 8 web console provides an interface for using Red Hat Subscription Manager installed on your local system. The Subscription Manager connects to the Red Hat Customer Portal and verifies available: Active subscriptions Expired subscriptions Renewed subscriptions If you want to renew the subscription or get a different one on the Red Hat Customer Portal, you do not have to update the Subscription Manager data manually. The Subscription Manager synchronizes data with the Red Hat Customer Portal automatically. 5.2. Registering subscriptions with credentials in the web console You can register a newly installed Red Hat Enterprise Linux with your account credentials in the RHEL web console. Prerequisites A valid user account on the Red Hat Customer Portal. See the Create a Red Hat Login page. An active subscription for your RHEL system. You have installed the RHEL 8 web console. For instructions, see Installing and enabling the web console . Procedure Log in to the RHEL 8 web console. For details, see Logging in to the web console . In the Health filed in the Overview page, click the Not registered warning, or click Subscriptions in the main menu to move to page with your subscription information. In the Overview field, click Register . In the Register system dialog box, select Account to register by using your account credentials. Enter your username. Enter your password. Optional: Enter your organization's name or ID. If your account belongs to more than one organization on the Red Hat Customer Portal, you must add the organization name or organization ID. To get the org ID, go to your Red Hat contact point. If you do not want to connect your system to Red Hat Insights, clear the Insights check box. Click Register . 5.3. Registering subscriptions with activation keys in the web console You can register a newly installed Red Hat Enterprise Linux with an activation key in the RHEL web console. Prerequisites An activation key of your Red Hat product subscription. You have installed the RHEL 8 web console. For instructions, see Installing and enabling the web console . Procedure Log in to the RHEL 8 web console. For details, see Logging in to the web console . In the Health field on the Overview page, click the Not registered warning, or click Subscriptions in the main menu to move to the page with your subscription information. . In the Overview filed, click Register . In the Register system dialog box, select Activation key to register using an activation key. Enter your key or keys. Enter your organization's name or ID. To get the organization ID, go to your Red Hat contact point. If you do not want to connect your system to Red Hat Insights, clear the Insights check box. Click Register .

Commands:
Chapter 7. Server installation on Microsoft Azure Important If you are using a Red Hat Enterprise Linux On-Demand virtual machine from the Microsoft Azure Marketplace, you must install JBoss EAP using the .zip file or installer methods. You must not register a Red Hat Enterprise Linux On-Demand virtual machine to Red Hat Subscription Management, as you will be billed twice for that virtual machine. Installing JBoss EAP on a virtual machine in a Microsoft Azure environment is no different from a normal JBoss EAP installation. See the Red Hat JBoss Enterprise Application Platform Installation Methods for instructions.

Commands:
Chapter 6. Diagnosing RHEL for Real Time bugs Identifying which kernel, the RHEL for Real Time or the standard kernel, is the source of the problem can increase the chances of having your bug fixed faster. By following the procedure steps, you can diagnose the source of the problem before submitting a bug report. Prerequisite: The latest version of RHEL for Real Time kernel is installed. Procedure: Verify that you have the latest version of the RHEL for Real Time kernel. Boot into RHEL for Real Time kernel using the GRUB menu. If the problem occurs, report a bug against RHEL for Real Time. Try to reproduce the problem with the standard kernel. This troubleshooting step assists in identifying the problem location. Note If the problem does not occur with the standard kernel, then the bug is probably the result of changes introduced in the RHEL for Real Time specific enhancements, which Red Hat has applied on top of the baseline (4.18.0) kernel.

Commands:
Appendix D. Post upgrade playbook This section provides an Ansible Playbook that you should run if you are not able to access the automation controller UI on all automation controller nodes after the migration. This addresses the SELinux context and the certificate mismatch issues that were described in the Chapter 4, Infrastructure Migration section. Copy the below Ansible Playbook content and place it in a file called post_upgrade_playbook.yml inside the untarred installer directory. Note This directory consists of the installer inventory file and this playbook uses the installer inventory to make some changes to your automation controller nodes. post_upgrade_playbook.yml Run the command to execute the playbook on the controller nodes.

Commands:
--- - name: Play to apply workaround to known issues in upgrade hosts: automationcontroller become: true tasks: - block: - name: Remove certs from all the controllers file: name: "{{ item }}" state: absent loop: - /etc/tower/tower.cert - /etc/tower/tower.key - name: Role to create new certs and copy to all controllers include_role: name: ansible.automation_platform_installer.nginx when: - automation_platform_version is version('2.1.1', '<=') - name: Add to targeted policy and apply selinux policy to controller dirs ansible.builtin.command: "{{ item }}" loop: - semodule -s targeted -i /usr/share/selinux/targeted/automation-controller.pp - /sbin/restorecon -R /var/lib/awx/venv /var/lib/awx/job_status /var/run/tower - name: Restart the controller service service: name: automation-controller state: restarted
ansible-playbook -i inventory.new.ini post_upgrade_playbook.yml
25.4. Using Pre-Existing Keys and Certificates If you already have an existing key and certificate (for example, if you are installing the secure server to replace another company's secure server product), you can probably use your existing key and certificate with the secure server. The following two situations provide instances where you are not able to use your existing key and certificate: If you are changing your IP address or domain name - Certificates are issued for a particular IP address and domain name pair. You must get a new certificate if you are changing your IP address or domain name. If you have a certificate from VeriSign and you are changing your server software - VeriSign is a widely used CA. If you already have a VeriSign certificate for another purpose, you may have been considering using your existing VeriSign certificate with your new secure server. However, you are not be allowed to because VeriSign issues certificates for one specific server software and IP address/domain name combination. If you change either of those parameters (for example, if you previously used a different secure server product), the VeriSign certificate you obtained to use with the configuration will not work with the new configuration. You must obtain a new certificate. If you have an existing key and certificate that you can use, you do not have to generate a new key and obtain a new certificate. However, you may need to move and rename the files which contain your key and certificate. Move your existing key file to: Move your existing certificate file to: After you have moved your key and certificate, skip to Section 25.9, "Testing The Certificate" . If you are upgrading from the Red Hat Secure Web Server, your old key ( httpsd.key ) and certificate ( httpsd.crt ) are located in /etc/httpd/conf/ . Move and rename your key and certificate so that the secure server can use them. Use the following two commands to move and rename your key and certificate files: Then, start your secure server with the command: You are prompted to enter your passphrase. After you type it in and press Enter , the server starts.

Commands:
/etc/httpd/conf/ssl.key/server.key
/etc/httpd/conf/ssl.crt/server.crt
mv /etc/httpd/conf/httpsd.key /etc/httpd/conf/ssl.key/server.key mv /etc/httpd/conf/httpsd.crt /etc/httpd/conf/ssl.crt/server.crt
/sbin/service httpd start
Chapter 3. Red Hat build of OpenJDK features The latest Red Hat build of OpenJDK 11 release might include new features. Additionally, this latest release might enhance, deprecate, or remove features that originated from Red Hat build of OpenJDK 11 releases. Note For all the other changes and security fixes, see OpenJDK 11.0.15 Released . 3.1. Red Hat build of OpenJDK new features and enhancements Review the following release notes to understand new features and feature enhancements that have been included with the Red Hat build of OpenJDK 11.0.15 release: SunPKCS11 provider supports new cipher and keygenerator The SunPKCS11 provider now supports the following services and algorithms when the PKCS11 library supports the related PKCS#11 mechanism: If the PKCS11 library supports the CKM_CHACHA20_KEY_GEN mechanism: ChaCha20 KeyGenerator If the PKCS11 library supports the CKM_CHACHA20_POLY1305 mechanism: ChaCha20-Poly1305 Cipher ChaCha20-Poly1305 AlgorithmParameters ChaCha20 SecretKeyFactory JDK-8255410 contains more information. Alternative Data Streams (ADS) behavior on Red Hat build of OpenJDK for Microsoft Windows The Red Hat build of OpenJDK 11 for Microsoft Windows release fixes an issue where some Java applications failed because java.io.FileOutputStream would not open some files containing a colon ( : ) character. This issue occurred because the default value for jdk.io.File.enableADS was set to false . This Red Hat build of OpenJDK 11 for Microsoft Windows release sets the default value for the jdk.io.File.enableADS to true . By default, Red Hat build of OpenJDK can now write to Alternative Data Streams and to special files in Microsoft Windows, such as the NUL: file. You can disable Red Hat build of OpenJDK's capability to write to ADS by choosing one of the following options: Pass the -Djdk.io.File.enableADS=false parameter to your Red Hat build of OpenJDK deployment. Set the JAVA_TOOL_OPTIONS environment variable to JAVA_TOOL_OPTIONS=-Djdk.io.File.enableADS=false . Important Implementing one of these settings might cause issues with how your Java applications write data into files for your Red Hat build of OpenJDK 11 for Microsoft Windows build. See JDK-8285445 (JDK Bug System)

Commands:
Chapter 5. Test the Configured Back End After deploying the back end, test whether you can successfully create volumes on it. Doing so will require loading the necessary environment variables first. These variables are defined in /home/stack/overcloudrc by default. To load these variables, run the following command as the stack user: Note For more information, see Accessing the Overcloud . You should now be logged in to the Controller node. From there, you can create a volume type , which can be used to specify the back end you want to use (in this case, the newly-defined back end in Chapter 3, Define a Single Back End ). This is required in an OpenStack deployment where you have other back ends enabled (preferably, also through Director). To create a volume type named dellsc , run: , map this volume type to the back end defined in ]. Given the back end name tripleo_dellsc (as defined through the CinderDellScBackendName parameter, in xref:edityaml[ ), run: You should now be able to create a 2GB volume on the newly defined back end by invoking its volume type. To do so, run:

Commands:
source /home/stack/overcloudrc
cinder type-create dellsc
cinder type-key dellsc set volume_backend_name=tripleo_dellsc
cinder create --volume-type dellsc 2
Chapter 144. AutoRestart schema reference Used in: KafkaConnectorSpec , KafkaMirrorMaker2ConnectorSpec Full list of AutoRestart schema properties Configures automatic restarts for connectors and tasks that are in a FAILED state. When enabled, a back-off algorithm applies the automatic restart to each failed connector and its tasks. An incremental back-off interval is calculated using the formula n * n + n where n represents the number of restarts. This interval is capped at a maximum of 60 minutes. Consequently, a restart occurs immediately, followed by restarts after 2, 6, 12, 20, 30, 42, 56 minutes, and then at 60-minute intervals. By default, Streams for Apache Kafka initiates restarts of the connector and its tasks indefinitely. However, you can use the maxRestarts property to set a maximum on the number of restarts. If maxRestarts is configured and the connector still fails even after the final restart attempt, you must then restart the connector manually. For Kafka Connect connectors, use the autoRestart property of the KafkaConnector resource to enable automatic restarts of failed connectors and tasks. Enabling automatic restarts of failed connectors for Kafka Connect apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: my-source-connector spec: autoRestart: enabled: true If you prefer, you can also set a maximum limit on the number of restarts. Enabling automatic restarts of failed connectors for Kafka Connect with limited number of restarts apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: my-source-connector spec: autoRestart: enabled: true maxRestarts: 10 For MirrorMaker 2, use the autoRestart property of connectors in the KafkaMirrorMaker2 resource to enable automatic restarts of failed connectors and tasks. Enabling automatic restarts of failed connectors for MirrorMaker 2 apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker2 metadata: name: my-mm2-cluster spec: mirrors: - sourceConnector: autoRestart: enabled: true # ... heartbeatConnector: autoRestart: enabled: true # ... checkpointConnector: autoRestart: enabled: true # ... 144.1. AutoRestart schema properties Property Property type Description enabled boolean Whether automatic restart for failed connectors and tasks should be enabled or disabled. maxRestarts integer The maximum number of connector restarts that the operator will try. If the connector remains in a failed state after reaching this limit, it must be restarted manually by the user. Defaults to an unlimited number of restarts.

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: my-source-connector spec: autoRestart: enabled: true
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: my-source-connector spec: autoRestart: enabled: true maxRestarts: 10
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaMirrorMaker2 metadata: name: my-mm2-cluster spec: mirrors: - sourceConnector: autoRestart: enabled: true # heartbeatConnector: autoRestart: enabled: true # checkpointConnector: autoRestart: enabled: true #
9.5. Configuring Red Hat JBoss Data Grid for Authorization Authorization is configured at two levels: the cache container (CacheManager), and at the single cache. CacheManager The following is an example configuration for authorization at the CacheManager level: Example 9.4. CacheManager Authorization (Declarative Configuration) Each cache container determines: whether to use authorization. a class which will map principals to a set of roles. a set of named roles and the permissions they represent. You can choose to use only a subset of the roles defined at the container level. Roles Roles may be applied on a cache-per-cache basis, using the roles defined at the cache-container level, as follows: Example 9.5. Defining Roles Important Any cache that is intended to require authentication must have a listing of roles defined; otherwise authentication is not enforced as the no-anonymous policy is defined by the cache's authorization. Programmatic CacheManager Authorization (Library Mode) The following example shows how to set up the same authorization parameters for Library mode using programmatic configuration: Example 9.6. CacheManager Authorization Programmatic Configuration Important The REST protocol is not supported for use with authorization, and any attempts to access a cache with authorization enabled will result in a SecurityException . Report a bug

Commands:
<cache-container name="local" default-cache="default"> <security> <authorization> <identity-role-mapper /> <role name="admin" permissions="ALL"/> <role name="reader" permissions="READ"/> <role name="writer" permissions="WRITE"/> <role name="supervisor" permissions="ALL_READ ALL_WRITE"/> </authorization> </security> </cache-container>
<local-cache name="secured"> <security> <authorization roles="admin reader writer supervisor"/> </security> </local-cache>
GlobalConfigurationBuilder global = new GlobalConfigurationBuilder(); global .security() .authorization() .principalRoleMapper(new IdentityRoleMapper()) .role("admin") .permission(CachePermission.ALL) .role("supervisor") .permission(CachePermission.EXEC) .permission(CachePermission.READ) .permission(CachePermission.WRITE) .role("reader") .permission(CachePermission.READ); ConfigurationBuilder config = new ConfigurationBuilder(); config .security() .enable() .authorization() .role("admin") .role("supervisor") .role("reader");
Preface As a developer of business processes, you can use Red Hat Process Automation Manager to develop process services and case definitions using Business Process Model and Notation (BPMN) 2.0 models. BPMN process models are graphical representations of the steps required to achieve a business goal. For more information about BPMN, see the Object Management Group (OMG) Business Process Model and Notation 2.0 specification .

Commands:
Chapter 18. Integrating with cloud management platforms You can integrate Red Hat Advanced Cluster Security for Kubernetes (RHACS) with different cloud management platforms to discover potential clusters to secure. The cluster discovery aims to gain a detailed overview of the cluster assets already or not yet secured by RHACS. The clusters discovered from a cloud management platform are accessible from the Platform Configuration Clusters Discovered clusters page. RHACS matches the discovered clusters against already secured clusters. Based on the result of the matching, a discovered cluster has one of the following statuses: Secured : The cluster is secured by RHACS. Unsecured : The cluster is not secured by RHACS. Undetermined : The metadata collected from secured clusters is not enough for a unique match. The cluster is either secured or unsecured. For successful cluster matching, ensure that the following conditions are met: Sensors running on secured clusters have been updated to the latest version. Access to instance tags via the metadata service has been granted for secured clusters running on AWS. Sensors require access to the AWS EC2 instance tags to determine the cluster status. You can integrate RHACS with the following cloud management platforms: Paladin Cloud OpenShift Cluster Manager 18.1. Configuring Paladin Cloud integration To discover cluster assets from Paladin Cloud, create a new integration in Red Hat Advanced Cluster Security for Kubernetes. Prerequisites A Paladin Cloud account. A Paladin Cloud API token. Procedure In the RHACS portal, go to Platform Configuration Integrations . Scroll down to the Cloud source integrations section and select Paladin Cloud . Click New integration . Enter a name for Integration name . Enter the Paladin Cloud API endpoint for Paladin Cloud endpoint . The default is https://api.paladincloud.io . Enter the Paladin Cloud API token for Paladin Cloud token . Select Test to confirm that authentication is working. Select Create to generate the configuration. Once configured, Red Hat Advanced Cluster Security for Kubernetes discovers cluster assets from your connected Paladin Cloud account. 18.2. Configuring Red Hat OpenShift Cluster Manager integration To discover cluster assets from Red Hat OpenShift Cluster Manager, create a new integration in Red Hat Advanced Cluster Security for Kubernetes. Prerequisites A Red Hat account. A Red Hat service account . Procedure In the RHACS portal, go to Platform Configuration Integrations . Scroll down to the Cloud source integrations section and select Red Hat OpenShift Cluster Manager . Click New integration . Enter a name for Integration name . Enter the Red Hat OpenShift Cluster Manager API endpoint for Endpoint . The default is https://api.openshift.com . Enter the Red Hat service account credentials for Client ID and Client secret . Select Test to confirm that authentication is working. Select Create to generate the configuration. Once configured, Red Hat Advanced Cluster Security for Kubernetes discovers cluster assets from your connected Red Hat account.

Commands: