mtpti5iD/redhat-docs_dataset huggingface dataset:
25.5. Types of Certificates If you installed your secure server from the RPM package provided by Red Hat, a random key and a test certificate are generated and put into the appropriate directories. Before you begin using your secure server, however, you must generate your own key and obtain a certificate which correctly identifies your server. You need a key and a certificate to operate your secure server - which means that you can either generate a self-signed certificate or purchase a CA-signed certificate from a CA. What are the differences between the two? A CA-signed certificate provides two important capabilities for your server: Browsers (usually) automatically recognize the certificate and allow a secure connection to be made, without prompting the user. When a CA issues a signed certificate, they are guaranteeing the identity of the organization that is providing the webpages to the browser. If your secure server is being accessed by the public at large, your secure server needs a certificate signed by a CA so that people who visit your website know that the website is owned by the organization who claims to own it. Before signing a certificate, a CA verifies that the organization requesting the certificate was actually who they claimed to be. Most Web browsers that support SSL have a list of CAs whose certificates they automatically accept. If a browser encounters a certificate whose authorizing CA is not in the list, the browser asks the user to either accept or decline the connection. You can generate a self-signed certificate for your secure server, but be aware that a self-signed certificate does not provide the same functionality as a CA-signed certificate. A self-signed certificate is not automatically recognized by most Web browsers and does not provide any guarantee concerning the identity of the organization that is providing the website. A CA-signed certificate provides both of these important capabilities for a secure server. If your secure server is to be used in a production environment, a CA-signed certificate is recommended. The process of getting a certificate from a CA is fairly easy. A quick overview is as follows: Create an encryption private and public key pair. Create a certificate request based on the public key. The certificate request contains information about your server and the company hosting it. Send the certificate request, along with documents proving your identity, to a CA. Red Hat does not make recommendations on which certificate authority to choose. Your decision may be based on your past experiences, on the experiences of your friends or colleagues, or purely on monetary factors. Once you have decided upon a CA, you need to follow the instructions they provide on how to obtain a certificate from them. When the CA is satisfied that you are indeed who you claim to be, they provide you with a digital certificate. Install this certificate on your secure server and begin handling secure transactions. Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key. Refer to Section 25.6, "Generating a Key" for instructions.

Commands:
25.3. An Overview of Certificates and Security Your secure server provides security using a combination of the Secure Sockets Layer (SSL) protocol and (in most cases) a digital certificate from a Certificate Authority (CA). SSL handles the encrypted communications as well as the mutual authentication between browsers and your secure server. The CA-approved digital certificate provides authentication for your secure server (the CA puts its reputation behind its certification of your organization's identity). When your browser is communicating using SSL encryption, the https:// prefix is used at the beginning of the Uniform Resource Locator (URL) in the navigation bar. Encryption depends upon the use of keys (think of them as secret encoder/decoder rings in data format). In conventional or symmetric cryptography, both ends of the transaction have the same key, which they use to decode each other's transmissions. In public or asymmetric cryptography, two keys co-exist: a public key and a private key. A person or an organization keeps their private key a secret and publishes their public key. Data encoded with the public key can only be decoded with the private key; data encoded with the private key can only be decoded with the public key. To set up your secure server, use public cryptography to create a public and private key pair. In most cases, you send your certificate request (including your public key), proof of your company's identity, and payment to a CA. The CA verifies the certificate request and your identity, and then sends back a certificate for your secure server. A secure server uses a certificate to identify itself to Web browsers. You can generate your own certificate (called a "self-signed" certificate), or you can get a certificate from a CA. A certificate from a reputable CA guarantees that a website is associated with a particular company or organization. Alternatively, you can create your own self-signed certificate. Note, however, that self-signed certificates should not be used in most production environments. Self-signed certificates are not automatically accepted by a user's browser - users are prompted by the browser to accept the certificate and create the secure connection. Refer to Section 25.5, "Types of Certificates" for more information on the differences between self-signed and CA-signed certificates. Once you have a self-signed certificate or a signed certificate from the CA of your choice, you must install it on your secure server.

Commands:
29.5.4. Using opannotate The opannotate tool tries to match the samples for particular instructions to the corresponding lines in the source code. The resulting files generated should have the samples for the lines at the left. It also puts in a comment at the beginning of each function listing the total samples for the function. For this utility to work, the appropriate debuginfo package for the executable must be installed on the system. On Red Hat Enterprise Linux, the debuginfo packages are not automatically installed with the corresponding packages that contain the executable. You have to obtain and install them separately. The general syntax for opannotate is as follows: The directory containing the source code and the executable to be analyzed must be specified. See the opannotate man page for a list of additional command-line options.

Commands:
~]# opannotate --search-dirs src-dir --source executable
Chapter 1. What is API controller? API controller enables you to manage the lifecycle of schemas and API definitions. You can design artifacts using Apicurio Studio and manage those artifacts using Apicurio Registry. This release is a Developer Preview of API controller. Important Developer Preview features are not supported by Red Hat in any way and are not functionally complete or production-ready. Do not use Developer Preview features for production or business-critical workloads. Developer Preview features provide early access to functionality in advance of possible inclusion in a Red Hat product offering. Customers can use these features to test functionality and provide feedback during the development process. Developer Preview features might not have any documentation, are subject to change or removal at any time, and have received limited testing. Red Hat might provide ways to submit feedback on Developer Preview features without an associated SLA. For more information, see Red Hat Developer Preview - Scope of Support . 1.1. Integration of API controller with Connectivity Link After you have created an API or schema with API controller, you can use that artifact with Connectivity Link to: Secure your applications with TLSPolicy Protect your applications with AuthPolicy Protect your applications with RateLimitPolicy Connect your applications with DNSPolicy Connectivity Link also provides observability using Grafana, Prometheus, and Alertmanager. Additional information Connectivity Link policy APIs and observability 1.2. Integration of Apicurio Studio with Apicurio Registry Apicurio Studio provides a UI to collaborate on draft artifacts as you design APIs and schemas. After you finalize a design, you can further manage that artifact in Apicurio Registry. Additional information Chapter 3, Getting started with Apicurio Studio Apicurio Registry documentation

Commands:
Chapter 2. General Information Table 2.1. General Information Subcommand Description and tasks --help Display hammer commands and options, append after a subcommand to get more information org The setting is organization-specific, append --organization org_name , or set default organization with: loc The setting is location-specific, append --location loc_name , or set default location with: Note: This cheat sheet assumes saved credentials in ~/.hammer/cli_config.yml . For more information, see Authentication in the Red Hat Hammer CLI Guide .

Commands:
hammer defaults add --param-name organization_id --param-value org_ID
hammer defaults add --param-name location_id --param-value loc_ID
Chapter 9. User statistics in Red Hat Developer Hub In Red Hat Developer Hub, the licensed-users-info-backend plugin provides statistical information about the logged-in users using the Web UI or REST API endpoints. The licensed-users-info-backend plugin enables administrators to monitor the number of active users on Developer Hub. Using this feature, organizations can compare their actual usage with the number of licenses they have purchased. Additionally, you can share the user metrics with Red Hat for transparency and accurate licensing. The licensed-users-info-backend plugin is enabled by default. This plugin enables a Download User List link at the bottom of the Administration RBAC tab. 9.1. Downloading active users list in Red Hat Developer Hub You can download the list of users in CSV format using the Developer Hub web interface. Prerequisites RBAC plugins ( @backstage-community/plugin-rbac and @backstage-community/plugin-rbac-backend ) must be enabled in Red Hat Developer Hub. An administrator role must be assigned. Procedure In Red Hat Developer Hub, navigate to Administration and select the RBAC tab. At the bottom of the RBAC page, click Download User List . Optional: Modify the file name in the Save as field and click Save . To access the downloaded users list, go to the Downloads folder on your local machine and open the CSV file.

Commands:
Chapter 3. Converting virtual machines to run on KVM managed by libvirt Warning The Red Hat Enterprise Linux 6 version of the virt-v2v utility has been deprecated. Users of Red Hat Enterprise Linux 6 are advised to create a Red Hat Enterprise 7 virtual machine, and install virt-v2v in that virtual machine. The Red Hat Enterprise Linux 7 version is fully supported and documented in virt-v2v Knowledgebase articles . virt-v2v can convert virtual machines to run on Red Hat Enterprise Linux, using KVM managed by libvirt. Virtual machines can be converted from Xen, KVM, VMware ESX / ESX(i), and Hyper-V environments. The libvirt and virsh commands are documented in the Red Hat Enterprise Linux Virtualization Administration Guide . You may also use the command man virsh for more information. 3.1. Introduction The virt-v2v command converts virtual machines from a foreign hypervisor to run on KVM, managed by libvirt. The following guest operating systems are supported by virt-v2v : Red Hat Enterprise Linux 3.9 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 Red Hat Enterprise Linux 6 Windows XP Windows Vista Windows 7 Windows Server 2003 Windows Server 2008 The following hypervisors are supported: KVM libvirt-managed Xen VMware ESX / ESX(i) - versions 3.5, 4.0, 4.1, 5.0, 5.1 The virt-v2v command enables paravirtualized ( virtio ) drivers in the converted guest, if possible. virt-v2v is available on Red Hat Customer Portal in the Red Hat Enterprise Linux Server (v.6 for 64-bit x86_64) or Red Hat Enterprise Linux Workstation (v.6 for x86_64) channel. The virt-v2v tool requires root access to the host system. Some of the new features for virt-v2v starting with Red Hat Enterprise Linux 6 are: The -op and -osd command line options continue to be supported, but are deprecated in favor of -os . There is no deprecation warning when they are used. The -of command line option allows specification of the file format to be used for target storage: raw or qcow2 . This feature allows for the conversion of a virtual machine with raw storage to qcow2 and vice versa. The -oa command line option allows the allocation policy of the target storage to be specified: sparse or preallocated . This can be used to convert between sparse and preallocated. Underlying this change, sparse volumes are now supported. The configuration file can now contain target profiles, which specify the storage location, output format and allocation policy for a target. This allows the user to specify --profile<foo> rather than -os<a> -op<b> -oa<oc> . The conversion of Windows virtual machines to libvirt targets is supported. Refer to the virt-v2v man page for further details on these and other features. To install virt-v2v from the Red Hat Customer Portal, ensure the system is subscribed to the appropriate channel, then run:

Commands:
yum install virt-v2v
Chapter 1. Understanding image builds 1.1. Builds A build is the process of transforming input parameters into a resulting object. Most often, the process is used to transform input parameters or source code into a runnable image. A BuildConfig object is the definition of the entire build process. OpenShift Dedicated uses Kubernetes by creating containers from build images and pushing them to a container image registry. Build objects share common characteristics including inputs for a build, the requirement to complete a build process, logging the build process, publishing resources from successful builds, and publishing the final status of the build. Builds take advantage of resource restrictions, specifying limitations on resources such as CPU usage, memory usage, and build or pod execution time. The resulting object of a build depends on the builder used to create it. For docker and S2I builds, the resulting objects are runnable images. For custom builds, the resulting objects are whatever the builder image author has specified. Additionally, the pipeline build strategy can be used to implement sophisticated workflows: Continuous integration Continuous deployment 1.1.1. Docker build OpenShift Dedicated uses Buildah to build a container image from a Dockerfile. For more information on building container images with Dockerfiles, see the Dockerfile reference documentation . Tip If you set Docker build arguments by using the buildArgs array, see Understand how ARG and FROM interact in the Dockerfile reference documentation. 1.1.2. Source-to-image build Source-to-image (S2I) is a tool for building reproducible container images. It produces ready-to-run images by injecting application source into a container image and assembling a new image. The new image incorporates the base image, the builder, and built source and is ready to use with the buildah run command. S2I supports incremental builds, which re-use previously downloaded dependencies, previously built artifacts, and so on. 1.1.3. Pipeline build Important The Pipeline build strategy is deprecated in OpenShift Dedicated 4. Equivalent and improved functionality is present in the OpenShift Dedicated Pipelines based on Tekton. Jenkins images on OpenShift Dedicated are fully supported and users should follow Jenkins user documentation for defining their jenkinsfile in a job or store it in a Source Control Management system. The Pipeline build strategy allows developers to define a Jenkins pipeline for use by the Jenkins pipeline plugin. The build can be started, monitored, and managed by OpenShift Dedicated in the same way as any other build type. Pipeline workflows are defined in a jenkinsfile , either embedded directly in the build configuration, or supplied in a Git repository and referenced by the build configuration.

Commands:
Chapter 2. Tapset Development Guidelines This chapter describes the upstream guidelines on proper tapset documentation. It also contains information on how to properly document your tapsets, to ensure that they are properly defined in this guide. 2.1. Writing Good Tapsets The first step to writing good tapsets is to create a simple model of your subject area. For example, a model of the process subsystem might include the following: Key Data process ID parent process ID process group ID State Transitions forked exec'd running stopped terminated Note Both lists are examples, and are not meant to represent a complete list. Use your subsystem expertise to find probe points (function entries and exits) that expose the elements of the model, then define probe aliases for those points. Be aware that some state transitions can occur in more than one place. In those cases, an alias can place a probe in multiple locations. For example, process execs can occur in either the do_execve() or the compat_do_execve() functions. The following alias inserts probes at the beginning of those functions: Try to place probes on stable interfaces (i.e., functions that are unlikely to change at the interface level) whenever possible. This will make the tapset less likely to break due to kernel changes. Where kernel version or architecture dependencies are unavoidable, use preprocessor conditionals (see the stap(1) man page for details). Fill in the probe bodies with the key data available at the probe points. Function entry probes can access the entry parameters specified to the function, while exit probes can access the entry parameters and the return value. Convert the data into meaningful forms where appropriate (e.g., bytes to kilobytes, state values to strings, etc). You may need to use auxiliary functions to access or convert some of the data. Auxiliary functions often use embedded C to do things that cannot be done in the SystemTap language, like access structure fields in some contexts, follow linked lists, etc. You can use auxiliary functions defined in other tapsets or write your own. In the following example, copy_process() returns a pointer to the task_struct for the new process. Note that the process ID of the new process is retrieved by calling task_pid() and passing it the task_struct pointer. In this case, the auxiliary function is an embedded C function defined in task.stp . It is not advisable to write probes for every function. Most SystemTap users will not need or understand them. Keep your tapsets simple and high-level.

Commands:
probe kprocess.exec = kernel.function("do_execve"), kernel.function("compat_do_execve") { probe body }
probe kprocess.create = kernel.function("copy_process").return { task = USDreturn new_pid = task_pid(task) }
Chapter 2. Generating and maintaining the diagnostic reports using the RHEL web console Generate, download, and delete the diagnostic reports in the RHEL web console. 2.1. Generating diagnostic reports using the RHEL web console Prerequisites The RHEL web console has been installed. For details, see Installing the web console . The cockpit-storaged package is installed on your system. You have administrator privileges. Procedure Log in to the RHEL web console. For details, see Logging in to the web console . In the left side menu, select Tools >> Diagnostic reports . To generate a new diagnostic report, click the Run report button. Enter the label for the report you want to create. Optional: Customize your report. Enter the encryption passphrase to encrypt your report. If you want to skip the encryption of the report, leave the field empty. Check the checkbox Obfuscate network addresses, hostnames, and usernames to obfuscate certain data. Check the checkbox Use verbose logging to increase logging verbosity. Click the Run report button to generate a report and wait for the process to complete. You can stop generating the report using the Stop report button. 2.2. Downloading diagnostic reports in the RHEL web console You can select and download diagnostic reports in the RHEL web console graphical user interface. Prerequisites You have installed the RHEL 9 web console. You have enabled the cockpit service. Your user account is allowed to log in to the web console. For instructions, see Installing and enabling the web console . You have administrator privileges. One or more diagnostic reports have been generated. Procedure Log in to the RHEL 9 web console. For details, see Logging in to the web console . In the left-side menu, select Tools >> Diagnostic reports . Click the Download button to the report that you want to download. The download starts automatically. steps For the methods on how to provide Red Hat Technical Support team with your diagnostic report, see Methods for providing an sos report to Red Hat technical support . 2.3. Deleting diagnostic reports using the RHEL web console Prerequisites The RHEL web console has been installed. For details, see Installing the web console . You have administrator privileges. One or more diagnostic reports have been generated. Procedure Log in to the RHEL web console. For details, see Logging in to the web console . In the left side menu, select Tools >> Diagnostic reports . Click the vertical ellipsis by the Download button to the report that you want to delete, then click on the Delete button. In the Delete report permanently? window, click the Delete button to delete the report.

Commands:
Appendix C. Using AMQ Broker with the examples The AMQ JMS examples require a running message broker with a queue named queue . Use the procedures below to install and start the broker and define the queue. C.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . C.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... C.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named queue . USD <broker-instance-dir> /bin/artemis queue create --name queue --address queue --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. C.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2020-10-08 11:24:40 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name queue --address queue --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop