mtpti5iD/redhat-docs_dataset huggingface dataset:
7.21. certmonger 7.21.1. RHBA-2015:1379 - certmonger bug fix and enhancement update Updated certmonger packages that fix two bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The certmonger service monitors certificates, warns of their impending expiration, and optionally attempts to renew certificates by enrolling the system with a certificate authority (CA). Bug Fixes BZ# 1163023 Prior to this update, after the user upgraded from Red Hat Enterprise Linux 6.5 to Red Hat Enterprise Linux 6.6 and rebooted the system, certmonger in some cases erroneously exited shortly after starting or performed a series of unnecessary checks for new certificates. A patch has been applied to fix this bug, and these problems no longer occur in the described situation. BZ# 1178190 Previously, the "getcert list" command did not display the "pre-save command" and "post-save command" values. As a consequence, running "getcert list" could return incomplete results. With this update, the problem has been fixed, and running "getcert list" displays the "pre-save command" and "post-save command" values as expected. Enhancements BZ# 1161768 The certmonger service now supports the Simple Certificate Enrollment Protocol (SCEP). For obtaining certificates from servers, the user can now offer enrollment over SCEP. BZ# 1169806 Requesting a certificate using the getcert utility during an IdM client kickstart enrollment no longer requires certmonger to be running. Previously, an attempt to do this failed because certmonger was not running. With this update, getcert can successfully request a certificate in the described situation, on the condition that the D-Bus daemon is not running. Note that certmonger requires a system reboot to start monitoring the certificate obtained in this way. BZ# 1222595 Previously, after the user ran the "getcert list" command, the output included the PIN value if it was set for the certificate. Consequently, the user could unintentionally expose the PIN, for example by publicly sharing the output of the command. With this update, the "getcert list" output only contains a note that a PIN is set for the certificate. As a result, the PIN value itself is no longer displayed in the "getcert list" output. Users of certmonger are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
18.6. The Default Configuration When the libvirtd daemon ( libvirtd ) is first installed, it contains an initial virtual network switch configuration in NAT mode. This configuration is used so that installed guests can communicate to the external network, through the host physical machine. The following image demonstrates this default configuration for libvirtd : Figure 18.7. Default libvirt network configuration Note A virtual network can be restricted to a specific physical interface. This may be useful on a physical system that has several interfaces (for example, eth0 , eth1 and eth2 ). This is only useful in routed and NAT modes, and can be defined in the dev=<interface> option, or in virt-manager when creating a new virtual network.

Commands:
Chapter 5. Kafka Bridge interface The Kafka Bridge provides a RESTful interface that allows HTTP-based clients to interact with a Kafka cluster. It offers the advantages of a HTTP API connection to Streams for Apache Kafka for clients to produce and consume messages without the requirement to use the native Kafka protocol. The API has two main resources - consumers and topics - that are exposed and made accessible through endpoints to interact with consumers and producers in your Kafka cluster. The resources relate only to the Kafka Bridge, not the consumers and producers connected directly to Kafka. 5.1. HTTP requests The Kafka Bridge supports HTTP requests to a Kafka cluster, with methods to perform operations such as the following: Send messages to a topic. Retrieve messages from topics. Retrieve a list of partitions for a topic. Create and delete consumers. Subscribe consumers to topics, so that they start receiving messages from those topics. Retrieve a list of topics that a consumer is subscribed to. Unsubscribe consumers from topics. Assign partitions to consumers. Commit a list of consumer offsets. Seek on a partition, so that a consumer starts receiving messages from the first or last offset position, or a given offset position. The methods provide JSON responses and HTTP response code error handling. Messages can be sent in JSON or binary formats. Additional resources To view the API documentation, including example requests and responses, see Using the Kafka Bridge . 5.2. Supported clients for the Kafka Bridge You can use the Kafka Bridge to integrate both internal and external HTTP client applications with your Kafka cluster. Internal clients Internal clients are container-based HTTP clients running in the same OpenShift cluster as the Kafka Bridge itself. Internal clients can access the Kafka Bridge on the host and port defined in the KafkaBridge custom resource. External clients External clients are HTTP clients running outside the OpenShift cluster in which the Kafka Bridge is deployed and running. External clients can access the Kafka Bridge through an OpenShift Route, a loadbalancer service, or using an Ingress. HTTP internal and external client integration

Commands:
Chapter 7. Enabling notifications and integrations You can enable the notifications service on Red Hat Hybrid Cloud Console to send notifications whenever a compliance policy is triggered. For example, you can configure the notifications service to automatically send an email message whenever a compliance policy falls below a certain threshold, or to send an email digest of all the compliance policy events that take place each day. Using the notifications service frees you from having to continually check the Red Hat Insights for RHEL dashboard for compliance event-triggered notifications. Enabling the notifications service requires three main steps: First, an Organization Administrator creates a User access group with the Notifications administrator role, and then adds account members to the group. , a Notifications administrator sets up behavior groups for events in the notifications service. Behavior groups specify the delivery method for each notification. For example, a behavior group can specify whether email notifications are sent to all users, or just to Organization administrators. Finally, users who receive email notifications from events must set their user preferences so that they receive individual emails for each event or a daily digest of all compliance events. In addition to sending email messages, you can configure the notifications service to send event data in other ways: Using an authenticated client to query Red Hat Insights APIs for event data Additional resources For more information about how to set up notifications for compliance events, see Configuring notifications on the Red Hat Hybrid Cloud Console with FedRAMP .

Commands:
12.3. Requesting a CA-signed Certificate Through SCEP The Simple Certificate Enrollment Protocol (SCEP) automates and simplifies the process of certificate management with the CA. It lets a client request and retrieve a certificate over HTTP directly from the CA's SCEP service. This process is secured by a one-time PIN that is usually valid only for a limited time. The following example adds a SCEP CA configuration to certmonger , requests a new certificate, and adds it to the local NSS database. Add the CA configuration to certmonger : -c : Mandatory nickname for the CA configuration. The same value can later be passed to other getcert commands. -u : URL to the server's SCEP interface. Mandatory parameter when using an HTTPS URL: -R CA_Filename : Location of the PEM-formatted copy of the SCEP server's CA certificate, used for the HTTPS encryption. Verify that the CA configuration has been successfully added: The CA configuration was successfully added, when the CA certificate thumbprints were retrieved over SCEP and shown in the command's output. When accessing the server over unencrypted HTTP, manually compare the thumbprints with the ones displayed at the SCEP server to prevent a Man-in-the-middle attack. Request a certificate from the CA: -I : Name of the task. The same value can later be passed to the getcert list command. -c : CA configuration to submit the request to. -d : Directory with the NSS database to store the certificate and key. -n : Nickname of the certificate, used in the NSS database. -N : Subject name in the CSR. -L : Time-limited one-time PIN issued by the CA. Right after submitting the request, you can verify that a certificate was issued and correctly stored in the local database: The status MONITORING signifies a successful retrieval of the issued certificate. The getcert-list(1) man page lists other possible states and their meanings.

Commands:
getcert add-scep-ca -c CA_Name -u SCEP_URL
getcert list-cas -c CA_Name CA 'CA_Name': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/scep-submit -u http://SCEP_server_enrollment_interface_URL SCEP CA certificate thumbprint (MD5): A67C2D4B 771AC186 FCCA654A 5E55AAF7 SCEP CA certificate thumbprint (SHA1): FBFF096C 6455E8E9 BD55F4A5 5787C43F 1F512279
getcert request -I Task_Name -c CA_Name -d /etc/pki/nssdb -n Certificate_Name -N cn=" Subject Name " -L one-time_PIN
getcert list -I TaskName Request ID 'Task_Name': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='TestCert',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='TestCert',token='NSS Certificate DB' signing request thumbprint (MD5): 503A8EDD DE2BE17E 5BAA3A57 D68C9C1B signing request thumbprint (SHA1): B411ECE4 D45B883A 75A6F14D 7E3037F1 D53625F4 CA: AD-Name issuer: CN=windows-CA,DC=ad,DC=example,DC=com subject: CN=Test Certificate expires: 2018-05-06 10:28:06 UTC key usage: digitalSignature,keyEncipherment eku: iso.org.dod.internet.security.mechanisms.8.2.2 certificate template/profile: IPSECIntermediateOffline pre-save command: post-save command: track: yes auto-renew: yes
Chapter 1. Overview The Ruby software development kit is a Ruby gem that allows you to interact with the Red Hat Virtualization Manager in Ruby projects. By downloading these classes and adding them to your project, you can access a range of functionality for high-level automation of administrative tasks. 1.1. Prerequisites To install the Ruby software development kit, you must have: A system with Red Hat Enterprise Linux 7 installed. Both the Server and Workstation variants are supported. A subscription to Red Hat Virtualization entitlements.

Commands:
Chapter 13. Troubleshooting builds Use the following to troubleshoot build issues. 13.1. Resolving denial for access to resources If your request for access to resources is denied: Issue A build fails with: requested access to the resource is denied Resolution You have exceeded one of the image quotas set on your project. Check your current quota and verify the limits applied and storage in use: USD oc describe quota 13.2. Service certificate generation failure If your request for access to resources is denied: Issue If a service certificate generation fails with (service's service.beta.openshift.io/serving-cert-generation-error annotation contains): Example output secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60 Resolution The service that generated the certificate no longer exists, or has a different serviceUID . You must force certificates regeneration by removing the old secret, and clearing the following annotations on the service: service.beta.openshift.io/serving-cert-generation-error and service.beta.openshift.io/serving-cert-generation-error-num . To clear the annotations, enter the following commands: USD oc delete secret <secret_name> USD oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error- USD oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num- Note The command removing an annotation has a - after the annotation name to be removed.

Commands:
requested access to the resource is denied
oc describe quota
secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60
oc delete secret <secret_name>
oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-
oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-
14.5. More Than a Secure Shell A secure command-line interface is just the beginning of the many ways SSH can be used. Given the proper amount of bandwidth, X11 sessions can be directed over an SSH channel. Or, by using TCP/IP forwarding, previously insecure port connections between systems can be mapped to specific SSH channels. 14.5.1. X11 Forwarding To open an X11 session over an SSH connection, use a command in the following form: For example, to log in to a remote machine named penguin.example.com with john as a user name, type: When an X program is run from the secure shell prompt, the SSH client and server create a new secure channel, and the X program data is sent over that channel to the client machine transparently. X11 forwarding can be very useful. For example, X11 forwarding can be used to create a secure, interactive session of the Printer Configuration utility. To do this, connect to the server using ssh and type: The Printer Configuration Tool will appear, allowing the remote user to safely configure printing on the remote system. Please note that X11 Forwarding does not distinguish between trusted and untrusted forwarding.

Commands:
ssh -Y username @ hostname
~]USD ssh -Y john@penguin.example.com john@penguin.example.com's password:
~]USD system-config-printer &
Preface Red Hat OpenShift Data Foundation 4.8 supports deployment on existing Red Hat OpenShift Container Platform (RHOCP) Azure clusters. Note Only internal OpenShift Data Foundation clusters are supported on Microsoft Azure. See Planning your deployment for more information about deployment requirements. To deploy OpenShift Data Foundation, start with the requirements in Preparing to deploy OpenShift Data Foundation chapter and then follow the appropriate deployment process based on your requirement: Deploy OpenShift Data Foundation on Microsoft Azure Deploy standalone Multicloud Object Gateway component

Commands:
4.10. attr 4.10.1. RHBA-2011:1272 - attr bug fix update Updated attr packages that fix multiple bugs are now available for Red Hat Enterprise Linux 6. The attr packages provide extended attributes, which can be used to store system objects like capabilities of executables and access control lists, as well as user objects. Bug Fixes BZ# 651119 Prior to this update, the setfattr utility could not restore the original values of the attributes when the "getfattr -e text" or "getfattr --encoding=text" command was used to dump attributes with embedded null characters. This update fixes the encoding of these values in getfattr to prevent information loss. BZ# 665049 Prior to this update, the getfattr utility followed symbolic links to directories even if the "-h" or "--no-dereference" option was specified. Additionally, the description in the getfattr(1) man page that related to this functionality was misleading. This update fixes getfattr with the "-h" option so that it no longer follows the symbolic links and the related content of the getfattr(1) man page is now correct. BZ# 665050 Prior to this update, the getfattr utility did not return a non-zero exit code when an attribute specified in the "getfattr" command did not exist. This update fixes getfattr so that it now returns a non-zero exit code when an attribute does not exist. BZ# 674870 Prior to this update, supported methods for encoding values of the extended attributes were not properly described in the setfattr(1) man page. This update adds the appropriate descriptions of the encoding methods to the setfattr(1) man page. BZ# 702639 Prior to this update, the project web page address as stated in the package specification did not reflect the change of the upstream project web page address. This update corrects the project web page address in the package specification. BZ# 727307 Prior to this update, the attr library was built without support for read-only relocations (RELRO) flags. With this update, the library is now built with partial RELRO support. All users of attr are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 5. Deploying the all-in-one Red Hat OpenStack Platform environment Before you deploy your all-in-one Red Hat OpenStack Platform environment, ensure that your system is up to date: To deploy your all-in-one environment, complete the following steps: Log in to registry.redhat.io with your Red Hat credentials: Export the environment variables that the deployment command uses. In this example, deploy the all-in-one environment with the eth1 interface that has the IP address 192.168.25.2 on the management network: Run the deploy command. Ensure that you include all .yaml files relevant to your environment: After a successful deployment, you can use the clouds.yaml configuration file in the /home/USDUSER/.config/openstack directory to query and verify the OpenStack services: To access the dashboard, use the default username admin and the undercloud_admin_password from the ~/standalone-passwords.conf file:

Commands:
[stack@all-in-one]USD sudo dnf update [stack@all-in-one]USD sudo reboot
[stack@all-in-one]USD sudo podman login registry.redhat.io
[stack@all-in-one]USD export IP=192.168.25.2 [stack@all-in-one]USD export NETMASK=24 [stack@all-in-one]USD export INTERFACE=eth1
[stack@all-in-one]USD sudo openstack tripleo deploy --templates --local-ip=USDIP/USDNETMASK -e /usr/share/openstack-tripleo-heat-templates/environments/standalone/standalone-tripleo.yaml -r /usr/share/openstack-tripleo-heat-templates/roles/Standalone.yaml -e USDHOME/containers-prepare-parameters.yaml -e USDHOME/standalone_parameters.yaml --output-dir USDHOME --standalone
[stack@all-in-one]USD export OS_CLOUD=standalone [stack@all-in-one]USD openstack endpoint list
[stack@all-in-one]USD cat standalone-passwords.conf | grep undercloud_admin_password:
Chapter 2. Architectures Red Hat Enterprise Linux 8.0 is distributed with the kernel version 4.18.0-80, which provides support for the following architectures: AMD and Intel 64-bit architectures The 64-bit ARM architecture IBM Power Systems, Little Endian 64-bit IBM Z Make sure you purchase the appropriate subscription for each architecture. For more information, see Get Started with Red Hat Enterprise Linux - additional architectures . For a list of available subscriptions, see Subscription Utilization on the Customer Portal.

Commands:
4.10. Suspending Activity on a File System You can suspend write activity to a file system by using the gfs_tool freeze command. Suspending write activity allows hardware-based device snapshots to be used to capture the file system in a consistent state. The gfs_tool unfreeze command ends the suspension. Usage Start Suspension End Suspension MountPoint Specifies the file system. Examples This example suspends writes to file system /gfs . This example ends suspension of writes to file system /gfs .

Commands:
gfs_tool freeze MountPoint
gfs_tool unfreeze MountPoint
gfs_tool freeze /gfs
gfs_tool unfreeze /gfs
Chapter 2. Configuring hosted control planes To get started with hosted control planes for OpenShift Container Platform, you first configure your hosted cluster on the provider that you want to use. Then, you complete a few management tasks. Important Hosted control planes is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . You can view the procedures by selecting from one of the following providers: 2.1. Amazon Web Services (AWS) Configuring the hosting cluster on AWS (Technology Preview) : The tasks to configure a hosted cluster on AWS include creating the AWS S3 OIDC secret, creating a routable public zone, enabling external DNS, enabling AWS PrivateLink, enabling the hosted control planes feature, and installing the hosted control planes CLI. Managing hosted control plane clusters on AWS (Technology Preview) : Management tasks include creating, importing, accessing, or deleting a hosted cluster on AWS. 2.2. Bare metal Configuring the hosting cluster on bare metal (Technology Preview) : Configure DNS before you create a hosted cluster. Managing hosted control plane clusters on bare metal (Technology Preview) : Create a hosted cluster, create an InfraEnv resource, add agents, access the hosted cluster, scale the NodePool object, handle Ingress, enable node auto-scaling, or delete a hosted cluster. 2.3. OpenShift Virtualization Managing hosted control plane clusters on OpenShift Virtualization (Technology Preview) : Create OpenShift Container Platform clusters with worker nodes that are hosted by KubeVirt virtual machines.

Commands:
Chapter 5. Building functions To run a function, you first must build the function project. This happens automatically when using the kn func run command, but you can also build a function without running it. 5.1. Building a function Before you can run a function, you must build the function project. If you are using the kn func run command, the function is built automatically. However, you can use the kn func build command to build a function without running it, which can be useful for advanced users or debugging scenarios. The kn func build command creates an OCI container image that can be run locally on your computer or on an OpenShift Container Platform cluster. This command uses the function project name and the image registry name to construct a fully qualified image name for your function. 5.1.1. Image container types By default, kn func build creates a container image by using Red Hat Source-to-Image (S2I) technology. Example build command using Red Hat Source-to-Image (S2I) USD kn func build 5.1.2. Image registry types The OpenShift Container Registry is used by default as the image registry for storing function images. Example build command using OpenShift Container Registry USD kn func build Example output Building function image Function image has been built, image: registry.redhat.io/example/example-function:latest You can override using OpenShift Container Registry as the default image registry by using the --registry flag: Example build command overriding OpenShift Container Registry to use quay.io USD kn func build --registry quay.io/username Example output Building function image Function image has been built, image: quay.io/username/example-function:latest 5.1.3. Push flag You can add the --push flag to a kn func build command to automatically push the function image after it is successfully built: Example build command using OpenShift Container Registry USD kn func build --push 5.1.4. Help command You can use the help command to learn more about kn func build command options: Build help command USD kn func help build

Commands:
kn func build
kn func build
Building function image Function image has been built, image: registry.redhat.io/example/example-function:latest
kn func build --registry quay.io/username
Building function image Function image has been built, image: quay.io/username/example-function:latest
kn func build --push
kn func help build