mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Enabling and giving access to the Role-Based Access Control (RBAC) feature The Role-Based Access Control (RBAC) feature is disabled by default. Enable the RBAC plugin and declare policy administrators to start using RBAC features. The permission policies for users and groups in the Developer Hub are managed by permission policy administrators. Only permission policy administrators can access the Role-Based Access Control REST API. Prerequisites You have added a custom Developer Hub application configuration , and have necessary permissions to modify it. You have enabled an authentication provider . Procedure The RBAC plugin is installed but disabled by default. To enable the ./dynamic-plugins/dist/backstage-community-plugin-rbac plugin, edit your dynamic-plugins.yaml with the following content. dynamic-plugins.yaml fragment plugins: - package: ./dynamic-plugins/dist/backstage-community-plugin-rbac disabled: false See Installing and viewing dynamic plugins . Declare policy administrators to enable a select number of authenticated users to configure RBAC policies through the REST API or Web UI, instead of modifying the CSV file directly. The permissions can be specified in a separate CSV file referenced in the app-config-rhdh ConfigMap, or permissions can be created using the REST API or Web UI. To declare users such as <your_policy_administrator_name> as policy administrators, edit your custom Developer Hub ConfigMap, such as app-config-rhdh , and add following code to the app-config.yaml content: app-config.yaml fragment permission: enabled: true rbac: admin: users: - name: user:default/ <your_policy_administrator_name> In order for the Developer Hub Web UI to display available permissions provided by installed plugins, add the corresponding plugin IDs to your custom app-config.yaml Developer Hub configuration file . To display available permissions in RBAC UI, edit your custom Developer Hub ConfigMap, such as app-config-rhdh , and add following code to the app-config.yaml content: app-config.yaml fragment permission: enabled: true rbac: admin: users: - name: user:default/ <your_policy_administrator_name> pluginsWithPermission: - catalog - scaffolder - permission Verification Sign out from the existing Red Hat Developer Hub session and log in again using the declared policy administrator account. With RBAC enabled, most features are disabled by default. Navigate to the Catalog page in RHDH. The Create button is not visible. You cannot create new components. Navigate to the API page. The Register button is not visible. steps Explicitly enable permissions to resources in Developer Hub.

Commands:
plugins: - package: ./dynamic-plugins/dist/backstage-community-plugin-rbac disabled: false
permission: enabled: true rbac: admin: users: - name: user:default/ <your_policy_administrator_name>
permission: enabled: true rbac: admin: users: - name: user:default/ <your_policy_administrator_name> pluginsWithPermission: - catalog - scaffolder - permission
25.2. XML Representation of the Events Collection Example 25.1. An XML representation of the events collection

Commands:
<events> <event id="537" href="/ovirt-engine/api/events/537"> <description>User vdcadmin logged in.</description> <code>30</code> <severity>normal</severity> <time>2011-01-12T10:48:27.827+02:00</time> <user id="9b9002d1-ec33-4083-8a7b-31f6b8931648" href="/ovirt-engine/api/users/9b9002d1-ec33-4083-8a7b-31f6b8931648"/> </event> </events>
Chapter 107. Checking disk space using IdM Healthcheck You can monitor the Identity Management server's free disk space using the Healthcheck tool. For details, see Healthcheck in IdM . Prerequisites The Healthcheck tool is only available on RHEL 8.1 and newer. 107.1. Disk space healthcheck test The Healthcheck tool includes a test for checking available disk space. Insufficient free disk space can cause issues with: Logging Execution Backups The test checks the following paths: Table 107.1. Tested paths Paths checked by the test Minimal disk space in MB /var/lib/dirsrv/ 1024 /var/lib/ipa/backup/ 512 /var/log/ 1024 var/log/audit/ 512 /var/tmp/ 512 /tmp/ 512 To list all tests, run the ipa-healthcheck with the --list-sources option: You can find the file system space check test under the ipahealthcheck.system.filesystemspace source: FileSystemSpaceCheck This test checks available disk space in the following ways: The minimum raw free bytes needed. The percentage - the minimum free disk space is hardcoded to 20%. 107.2. Screening disk space using the healthcheck tool Follow this procedure to run a standalone manual test of available disk space on an Identity Management (IdM) server using the Healthcheck tool. Since Healthcheck includes many tests, you can narrow the results by: Excluding all successful test: --failures-only Including only space check tests: --source=ipahealthcheck.system.filesystemspace Procedure To run Healthcheck with warnings, errors and critical issues regarding available disk space, enter: A successful test displays empty brackets: As an example, a failed test can display: The failed test informs you that the /var/lib/dirsrv directory has run out of space. Additional resources See man ipa-healthcheck .

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source=ipahealthcheck.system.filesystemspace --failures-only
{ "source": "ipahealthcheck.system.filesystemspace", "check": "FileSystemSpaceCheck", "result": "ERROR", "kw": { "msg": "/var/lib/dirsrv: free space under threshold: 0 MiB < 1024 MiB", "store": "/var/lib/dirsrv", "free_space": 0, "threshold": 1024 } }
20.16.9.10. Setting NIC driver-specific options Some NICs may have tunable driver-specific options. These options are set as attributes of the driver sub-element of the interface definition. These options are set by using management tools to configuring the following sections of the domain XML: <devices> <interface type='network'> <source network='default'/> <target dev='vnet1'/> <model type='virtio'/> <driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='off'/> </interface> </devices> ... Figure 20.47. Devices - network interfaces- setting NIC driver-specific options Currently the following attributes are available for the "virtio" NIC driver: Table 20.19. virtio NIC driver elements Parameter Description name The optional name attribute forces which type of back-end driver to use. The value can be either qemu (a user-space back end) or vhost (a kernel back end, which requires the vhost module to be provided by the kernel); an attempt to require the vhost driver without kernel support will be rejected. The default setting is vhost if the vhost driver present, but will silently fall back to qemu if not. txmode Specifies how to handle transmission of packets when the transmit buffer is full. The value can be either iothread or timer . If set to iothread , packet tx is all done in an iothread in the bottom half of the driver (this option translates into adding "tx=bh" to the qemu commandline -device virtio-net-pci option). If set to timer , tx work is done in qemu, and if there is more tx data than can be sent at the present time, a timer is set before qemu moves on to do other things; when the timer fires, another attempt is made to send more data. In general you should leave this option alone, unless you are very certain you that changing it is an absolute necessity. ioeventfd Allows users to set domain I/O asynchronous handling for interface device. The default is left to the discretion of the hypervisor. Accepted values are on and off . Enabling this option allows qemu to execute a guest virtual machine while a separate thread handles I/O. Typically guest virtual machines experiencing high system CPU utilization during I/O will benefit from this. On the other hand, overloading the physical host physical machine may also increase guest virtual machine I/O latency. Therefore, you should leave this option alone, unless you are very certain you that changing it is an absolute necessity. event_idx The event_idx attribute controls some aspects of device event processing. The value can be either on or off . Choosing on , reduces the number of interrupts and exits for the guest virtual machine. The default is on . In case there is a situation where this behavior is suboptimal, this attribute provides a way to force the feature off. You should leave this option alone, unless you are very certain you that changing it is an absolute necessity.

Commands:
<devices> <interface type='network'> <source network='default'/> <target dev='vnet1'/> <model type='virtio'/> <driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='off'/> </interface> </devices>
18.2.6. Activating the IPTables Service The firewall rules are only active if the iptables service is running. To manually start the service, use the following command: To ensure that iptables starts when the system is booted, use the following command: The ipchains service is not included in Red Hat Enterprise Linux. However, if ipchains is installed (for example, an upgrade was performed and the system had ipchains previously installed), the ipchains and iptables services should not be activated simultaneously. To make sure the ipchains service is disabled and configured not to start at boot time, use the following two commands:

Commands:
service iptables restart
chkconfig --level 345 iptables on
service ipchains stop chkconfig --level 345 ipchains off
1.3. Management CLI 1.3.1. Launch the Management CLI Procedure 1.1. Launch CLI in Linux or Microsoft Windows Server Launch the CLI in Linux Run the EAP_HOME /bin/jboss-cli.sh file by entering the following at a command line: Launch the CLI in Microsoft Windows Server Run the EAP_HOME \bin\jboss-cli.bat file by double-clicking it, or by entering the following at a command line: 1.3.2. Quit the Management CLI From the Management CLI, enter the quit command: 1.3.3. Connect to a Managed Server Instance Using the Management CLI Prerequisites Section 1.3.1, "Launch the Management CLI" Procedure 1.2. Connect to a Managed Server Instance Run the connect command From the Management CLI, enter the connect command: Alternatively, to connect to a managed server when starting the Management CLI on a Linux system, use the --connect parameter: The --connect parameter can be used to specify the host and port of the server. To connect to the address 192.168.0.1 with the port value 9999 the following would apply: 1.3.4. Obtain Help with the Management CLI Summary Sometimes you might need guidance if you need to learn a CLI command or feel unsure about what to do. The Management CLI features a help dialog with general and context-sensitive options. (Note that the help commands dependent on the operation context require an established connection to either a standalone or domain controller. These commands will not appear in the listing unless the connection has been established.) Prerequisites Section 1.3.1, "Launch the Management CLI" For general help From the Management CLI, enter the help command: Obtain context-sensitive help From the Management CLI, enter the help -commands extended command: For a more detailed description of a specific command, enter the command, followed by --help . Result The CLI help information is displayed.

Commands:
EAP_HOME /bin/jboss-cli.sh
C:\> EAP_HOME \bin\jboss-cli.bat
[domain@localhost:9999 /] quit
[disconnected /] connect Connected to domain controller at localhost:9999
EAP_HOME /bin/jboss-cli.sh --connect
EAP_HOME /bin/jboss-cli.sh --connect --controller=192.168.0.1:9999
[standalone@localhost:9999 /] help
[standalone@localhost:9999 /] help --commands
[standalone@localhost:9999 /] deploy --help
35.5. Automating the Initial Configuration of Cloud Instances Using cloud-init For the initial configuration of cloud instances, you can use the cloud-init package. On a new cloud instance, cloud-init can automatically: set the default locale configure the host name configure network interfaces generate private SSH keys add SSH keys to the user's .ssh/authorized_keys directory set up ephemeral mount points Cloud-init is used with Red Hat's cloud products. See documentation on using cloud-init with Red Hat products: Red Hat Enterprise Linux Atomic Host 7 Installation and Configuration Guide Red Hat OpenStack Platform 8 Instances and Images Guide Red Hat Enterprise Virtualization Virtual Machine Management Guide Red Hat CloudForms Provisioning Virtual Machines and Hosts Guide See also upstream cloud-init documentation

Commands:
Chapter 4. Sample applications 4.1. Red Hat build of Quarkus Examples The Red Hat build of Quarkus examples repository contains a number of examples on how to integrate with Camel for a variety of use cases. They provide best practice advice and describe common patterns that we see in integration and messaging problems. The examples can be run using Maven. When using the mvn command, Maven will attempt to download the required dependencies from a central repository to your local repository. 4.2. Examples repository Example Description Artemis to ElasticSearch Shows how the message is consumed from the Apache Artemis broker using MQTT protocol, transformed, and loaded into ElasticSearch. Leader election in Kubernetes Shows how to use Camel's master component for Kubernetes leader election. Custom main() Shows how to start Camel from a custom main() method. Camel Quarkus CXF SOAP example Shows how to use Camel CXF SOAP component. Extract, Transform, and Load between DBs Shows how to extract, transform, and load between two databases. File consumer with Bindy & FTP Shows how to consume CSV files, marshal & unmarshal the data, and send it via FTP. Health Shows how to use Camel health-checks with Quarkus. HTTP with vanilla JAX-RS or Camel HTTP Shows how to create HTTP endpoints using either platform-http or RESTEasy. JMS and JPA Demonstrates a Camel Quarkus application supporting JTA transactions across multiple transactional resources. JPA idempotent repository Shows how to consume a message only once, even when delivered multiple times. JTA and JPA Demonstrates JTA transactions across MySQL and a simulated XAResource. Kafka example Shows how to produce and consume messages in a Kafka topic using Strimzi Operator. Kamelet Chuck Norris Shows how to build a simple Kamelet for use in Camel applications. Message Bridge Demonstrates AMQ and IBM MQ clients with connection pooling and XA transactions. Observability Demonstrates adding metrics, health checks, and distributed tracing support. OpenAPI Contract First Shows how to run with Contract First OpenAPI. Platform HTTP security with Keycloak Shows how to secure platform HTTP with Keycloak. REST with Jackson Demonstrates creating a REST service using Camel REST DSL and Jackson. Saga and LRA Shows how to use saga and LRA patterns. Timer to Log Uses the Camel timer component to output a Hello world message to the console. Tokenize a CSV file Shows how to define a Camel route in XML for tokenizing a CSV file. Vertx-Websocket Chat Shows how to configure a WebSocket server and interact with connected peers.

Commands:
probe::socket.create.return Name probe::socket.create.return - Return from Creation of a socket Synopsis Values success Was socket creation successful? (1 = yes, 0 = no) protocol Protocol value err Error code if success == 0 name Name of this probe requester Requested by user process or the kernel (1 = kernel, 0 = user) type Socket type value family Protocol family value Context The requester (user process or kernel) Description Fires at the conclusion of creating a socket.

Commands:
socket.create.return
30.7. Listing and Displaying sudo Commands, Command Groups, and Rules Listing and Displaying sudo Commands, Command Groups, and Rules in the Web UI Under the Policy tab, click Sudo and select Sudo Rules , Sudo Commands , or Sudo Command Groups . Click the name of the rule, command, or command group to display its configuration page. Listing and Displaying sudo Commands, Command Groups, and Rules from the Command Line To list all commands, command groups, and rules, use the following commands: ipa sudocmd-find ipa sudocmdgroup-find ipa sudorule-find To display information about a particular command, command group, or rule, use the following commands: ipa sudocmd-show ipa sudocmdgroup-show ipa sudorule-show For example, to display information about the /usr/bin/less command: For more information about these commands and the options they accept, run them with the --help option added.

Commands:
ipa sudocmd-show /usr/bin/less Sudo Command: /usr/bin/less Description: For reading log files. Sudo Command Groups: files
4.7. Creating a VM Instance to Configure the Disks for Red Hat Gluster Storage Instances In the Google Developers Console, click Compute > Compute Engine > VM instances > Create Instance . The Create Instance window is displayed. Enter the following in the Create a new instance window and click Create . Name: rhgs-primary-n01 Zone: us-central1-a Machine type: n1-highmem-4 (4 vCPUs, 26 GB memory) Boot disk: New 20 GB standard persistent disk Image: rhgs31 (our uploaded image file)

Commands:
3.9. Additional Resources The definitive documentation for cgroup commands can be found in the manual pages provided with the libcgroup package. Installed Documentation The libcgroup-related Man Pages cgclassify (1) - the cgclassify command is used to move running tasks to one or more cgroups. cgclear (1) - the cgclear command is used to delete all cgroups in a hierarchy. cgconfig.conf (5) - cgroups are defined in the cgconfig.conf file. cgconfigparser (8) - the cgconfigparser command parses the cgconfig.conf file and mounts hierarchies. cgcreate (1) - the cgcreate command creates new cgroups in hierarchies. cgdelete (1) - the cgdelete command removes specified cgroups. cgexec (1) - the cgexec command runs tasks in specified cgroups. cgget (1) - the cgget command displays cgroup parameters. cgsnapshot (1) - the cgsnapshot command generates a configuration file from existing subsystems. cgred.conf (5) - cgred.conf is the configuration file for the cgred service. cgrules.conf (5) - cgrules.conf contains the rules used for determining when tasks belong to certain cgroups. cgrulesengd (8) - the cgrulesengd service distributes tasks to cgroups. cgset (1) - the cgset command sets parameters for a cgroup. lscgroup (1) - the lscgroup command lists the cgroups in a hierarchy. lssubsys (1) - the lssubsys command lists the hierarchies containing the specified subsystems.

Commands:
Chapter 9. Removing the kubeadmin user 9.1. The kubeadmin user OpenShift Container Platform creates a cluster administrator, kubeadmin , after the installation process completes. This user has the cluster-admin role automatically applied and is treated as the root user for the cluster. The password is dynamically generated and unique to your OpenShift Container Platform environment. After installation completes the password is provided in the installation program's output. For example: INFO Install complete! INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI. INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes). INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com INFO Login to the console with user: kubeadmin, password: <provided> 9.2. Removing the kubeadmin user After you define an identity provider and create a new cluster-admin user, you can remove the kubeadmin to improve cluster security. Warning If you follow this procedure before another user is a cluster-admin , then OpenShift Container Platform must be reinstalled. It is not possible to undo this command. Prerequisites You must have configured at least one identity provider. You must have added the cluster-admin role to a user. You must be logged in as an administrator. Procedure Remove the kubeadmin secrets: USD oc delete secrets kubeadmin -n kube-system

Commands:
INFO Install complete! INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI. INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes). INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com INFO Login to the console with user: kubeadmin, password: <provided>
oc delete secrets kubeadmin -n kube-system
B.14. Migration Fails with Unable to allow access for disk path: No such file or directory Symptom A guest virtual machine (or domain) cannot be migrated because libvirt cannot access the disk image(s): For example, if the destination host name is "newyork", the error message will appear as: Investigation By default, migration only transfers the in-memory state of a running guest (such as memory or CPU state). Although disk images are not transferred during migration, they need to remain accessible at the same path by both hosts. Solution Set up and mount shared storage at the same location on both hosts. The simplest way to do this is to use NFS: Procedure B.5. Setting up shared storage Set up an NFS server on a host serving as shared storage. The NFS server can be one of the hosts involved in the migration, as long as all hosts involved are accessing the shared storage through NFS. Mount the exported directory at a common location on all hosts running libvirt . For example, if the IP address of the NFS server is 192.168.122.1, mount the directory with the following commands: Note It is not possible to export a local directory from one host using NFS and mount it at the same path on another host - the directory used for storing disk images must be mounted from shared storage on both hosts. If this is not configured correctly, the guest virtual machine may lose access to its disk images during migration, because the source host's libvirt daemon may change the owner, permissions, and SELinux labels on the disk images after it successfully migrates the guest to its destination. If libvirt detects that the disk images are mounted from a shared storage location, it will not make these changes.

Commands:
virsh migrate qemu qemu+tcp:// name_of_host /system error: Unable to allow access for disk path /var/lib/libvirt/images/qemu.img: No such file or directory
virsh migrate qemu qemu+tcp:// newyork /system error: Unable to allow access for disk path /var/lib/libvirt/images/qemu.img: No such file or directory
mkdir -p /exports/images cat >>/etc/exports <<EOF /exports/images 192.168.122.0/24(rw,no_root_squash) EOF
cat >>/etc/fstab <<EOF 192.168.122.1:/exports/images /var/lib/libvirt/images nfs auto 0 0 EOF mount /var/lib/libvirt/images