mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 4. YAML creation practices for optimizing model performance The guidelines referenced in Adding knowledge to your taxonomy tree and Adding skills to your taxonomy tree provide standard instructions on creating skills and knowledge YAML files. However, there are ways you can to improve your YAML file to optimize the synthetic data generated and create a higher quality model. Diverse and comprehensive content in the context field of the YAML file Each context block should contain a variety information and format types from your document. This allows the model to learn different methods of presenting information. These different information presentation types can include: paragraphs, different types tables, lists, procedures and definitions. The context block should be a comprehensive example from your document. The total length of the context content and the Q&A pairs should not exceed 750 tokens. Writing effective questions The questions should align with the type of questions you want the model to be capable of answering. Each question should be unique and reference the information in the context field. Including full sentence questions improves the generated synthetic data and improves model response quality. Writing effective answers The answer directly responds to the question and should reflect the type of answer you want the model to be capable of providing. Answers should be in complete sentences and reference the original question. Including full sentence answers improves the generated synthetic data and improves model response quality. The answer should not be directly copied from the the context block, this can cause the model to learn extraction instead of reasoning. The information to answer the question must be in the context block. If the information is in a separate context block, or is not referenced at all, the model can hallucinate. Example of a high-quality question-and-answer pair - question: How many eggs are needed to make roughly 24 chocolate chip cookies? answer: You need around two eggs to make 24 chocolate chip cookies. When to use multiple documents or multiple qna.yaml files If multiple documents are related to a similar subject or domain, it is recommended to use a single qna.yaml file. Each qna.yaml file must contain a singular document type, you cannot mix document types in your YAML file. If the documents are not related, it is recommended to to use separate qna.yaml files. Adding Links in your YAML file Models can memorize link, so you can add them to your YAML file. However, its recommended to avoid adding hyperlinks if they change frequently.

Commands:
- question: How many eggs are needed to make roughly 24 chocolate chip cookies? answer: You need around two eggs to make 24 chocolate chip cookies.
Chapter 7. Data Centers 7.1. Introduction to Data Centers A data center is a logical entity that defines the set of resources used in a specific environment. A data center is considered a container resource, in that it is comprised of logical resources, in the form of clusters and hosts; network resources, in the form of logical networks and physical NICs; and storage resources, in the form of storage domains. A data center can contain multiple clusters, which can contain multiple hosts; it can have multiple storage domains associated to it; and it can support multiple virtual machines on each of its hosts. A Red Hat Virtualization environment can contain multiple data centers; the data center infrastructure allows you to keep these centers separate. All data centers are managed from the single Administration Portal. Figure 7.1. Data Centers Red Hat Virtualization creates a default data center during installation. You can configure the default data center, or set up new appropriately named data centers.

Commands:
4.321. texlive 4.321.1. RHSA-2012:0137 - Moderate: texlive security update Updated texlive packages that fix multiple security issues are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. TeX Live is an implementation of TeX. TeX takes a text file and a set of formatting commands as input, and creates a typesetter-independent DeVice Independent (DVI) file as output. The texlive packages provide a number of utilities, including dvips. Security Fixes CVE-2010-2642 , CVE-2011-0433 TeX Live embeds a copy of t1lib. The t1lib library allows you to rasterize bitmaps from PostScript Type 1 fonts. The following issues affect t1lib code: Two heap-based buffer overflow flaws were found in the way t1lib processed Adobe Font Metrics (AFM) files. If a specially-crafted font file was opened by a TeX Live utility, it could cause the utility to crash or, potentially, execute arbitrary code with the privileges of the user running the utility. CVE-2011-0764 An invalid pointer dereference flaw was found in t1lib. A specially-crafted font file could, when opened, cause a TeX Live utility to crash or, potentially, execute arbitrary code with the privileges of the user running the utility. CVE-2011-1553 A use-after-free flaw was found in t1lib. A specially-crafted font file could, when opened, cause a TeX Live utility to crash or, potentially, execute arbitrary code with the privileges of the user running the utility. CVE-2011-1554 An off-by-one flaw was found in t1lib. A specially-crafted font file could, when opened, cause a TeX Live utility to crash or, potentially, execute arbitrary code with the privileges of the user running the utility. CVE-2011-1552 An out-of-bounds memory read flaw was found in t1lib. A specially-crafted font file could, when opened, cause a TeX Live utility to crash. Red Hat would like to thank the Evince development team for reporting CVE-2010-2642 . Upstream acknowledges Jon Larimer of IBM X-Force as the original reporter of CVE-2010-2642 . All users of texlive are advised to upgrade to these updated packages, which contain backported patches to correct these issues.

Commands:
Appendix B. Updating the deployment configuration of an example application The deployment configuration for an example application contains information related to deploying and running the application in OpenShift, such as route information or readiness probe location. The deployment configuration of an example application is stored in a set of YAML files. For examples that use the Fabric8 Maven Plugin, the YAML files are located in the src/main/fabric8/ directory. For examples using Nodeshift, the YAML files are located in the .nodeshift directory. Important The deployment configuration files used by the Fabric8 Maven Plugin and Nodeshift do not have to be full OpenShift resource definitions. Both Fabric8 Maven Plugin and Nodeshift can take the deployment configuration files and add some missing information to create a full OpenShift resource definition. The resource definitions generated by the Fabric8 Maven Plugin are available in the target/classes/META-INF/fabric8/ directory. The resource definitions generated by Nodeshift are available in the tmp/nodeshift/resource/ directory. Prerequisites An existing example project. The oc CLI client installed. Procedure Edit an existing YAML file or create an additional YAML file with your configuration update. For example, if your example already has a YAML file with a readinessProbe configured, you could change the path value to a different available path to check for readiness: spec: template: spec: containers: readinessProbe: httpGet: path: /path/to/probe port: 8080 scheme: HTTP ... If a readinessProbe is not configured in an existing YAML file, you can also create a new YAML file in the same directory with the readinessProbe configuration. Deploy the updated version of your example using Maven or npm. Verify that your configuration updates show in the deployed version of your example. USD oc export all --as-template='my-template' apiVersion: template.openshift.io/v1 kind: Template metadata: creationTimestamp: null name: my-template objects: - apiVersion: template.openshift.io/v1 kind: DeploymentConfig ... spec: ... template: ... spec: containers: ... livenessProbe: failureThreshold: 3 httpGet: path: /path/to/different/probe port: 8080 scheme: HTTP initialDelaySeconds: 60 periodSeconds: 30 successThreshold: 1 timeoutSeconds: 1 ... Additional resources If you updated the configuration of your application directly using the web-based console or the oc CLI client, export and add these changes to your YAML file. Use the oc export all command to show the configuration of your deployed application.

Commands:
spec: template: spec: containers: readinessProbe: httpGet: path: /path/to/probe port: 8080 scheme: HTTP
oc export all --as-template='my-template' apiVersion: template.openshift.io/v1 kind: Template metadata: creationTimestamp: null name: my-template objects: - apiVersion: template.openshift.io/v1 kind: DeploymentConfig spec: template: spec: containers: livenessProbe: failureThreshold: 3 httpGet: path: /path/to/different/probe port: 8080 scheme: HTTP initialDelaySeconds: 60 periodSeconds: 30 successThreshold: 1 timeoutSeconds: 1
8.248. zsh 8.248.1. RHEA-2013:1557 - zsh enhancement update Updated zsh packages that add one enhancement are now available for Red Hat Enterprise Linux 6. The zsh shell is a command interpreter which can be used as an interactive login shell and as a shell script command processor. Zsh resembles the ksh shell (the Korn shell), but includes many enhancements. Zsh supports command line editing, built-in spelling correction, programmable command completion, shell functions (with autoloading), a history mechanism, and more. Enhancement BZ# 820530 This update adds the USD{NAME:OFFSET:LENGTH} substitution to zsh, which enables users to use the syntax USD{NAME:OFFSET:LENGTH} to display a substring. Users of zsh are advised to upgrade to these updated packages, which add this enhancement.

Commands:
Appendix F. Revision History Revision History Revision 4.0-2 Wed Aug 7 2019 Steven Levine Preparing document for 7.7 GA publication. Revision 3.0-2 Thu Oct 4 2018 Steven Levine Preparing document for 7.6 GA publication. Revision 2.0-2 Thu Mar 15 2018 Steven Levine Preparing document for 7.5 GA publication. Revision 2.0-1 Thu Dec 14 2017 Steven Levine Preparing document for 7.5 Beta publication. Revision 1.0-11 Wed Jul 19 2017 Steven Levine Document version for 7.4 GA publication. Revision 1.0-9 Mon May 15 2017 Steven Levine Preparing document for 7.4 Beta publication. Revision 1.0-7 Mon Mar 27 2017 Steven Levine Updated Version for 7.3 Revision 1.0-5 Mon Oct 17 2016 Steven Levine Version for 7.3 GA publication Revision 1.0-4 Wed Aug 17 2016 Steven Levine Preparing document for 7.3 Beta publication. Revision 0.3-4 Mon Nov 9 2015 Steven Levine Preparing document for 7.2 GA publication Revision 0.3-2 Wed Aug 19 2015 Steven Levine Preparing document for 7.2 Beta publication. Revision 0.2-7 Mon Feb 16 2015 Steven Levine Version for 7.1 GA release Revision 0.2-6 Thu Dec 11 2014 Steven Levine Version for 7.1 Beta release Revision 0.1-22 Mon Jun 2 2014 Steven Levine Version for 7.0 GA release Revision 0.1-1 Wed Jan 16 2013 Steven Levine Branched from the Red Hat Enterprise Linux 6 version of the document.

Commands:
Chapter 3. Exporting the report in CSV format Migration Toolkit for Runtimes (MTR) provides the ability to export the report data, including the classifications and hints, to a flat file on your local file system. The export function currently supports the CSV file format, which presents the report data as fields separated by commas ( , ). The CSV file can be imported and manipulated by spreadsheet software such as Microsoft Excel, OpenOffice Calc, or LibreOffice Calc. Spreadsheet software provides the ability to sort, analyze, evaluate, and manage the result data from an MTR report. 3.1. Exporting the report To export the report as a CSV file, run MTR with the exportCSV argument set to true . A CSV file is created in the directory specified by the --output argument for each application analyzed. All discovered issues, spanning all the analyzed applications, are included in AllIssues.csv file. The CSV files are exported to the directory specified by the outputDirectory argument. 3.2. Importing the CSV file into a spreadsheet program Launch the spreadsheet software, for example, Microsoft Excel. Choose File Open . Browse to the CSV exported file and select it. The data is now ready to analyze in the spreadsheet software. 3.3. About the CSV data structure The CSV formatted output file contains the following data fields: Rule Id The ID of the rule that generated the given item. Problem type hint or classification Title The title of the classification or hint . This field summarizes the issue for the given item. Description The detailed description of the issue for the given item. Links URLs that provide additional information about the issue. A link consists of two attributes: the link and a description of the link. Application The name of the application for which this item was generated. File Name The name of the file for the given item. File Path The file path for the given item. Line The line number of the file for the given item. Story points The number of story points, which represent the level of effort, assigned to the given item.

Commands:
Chapter 148. AutoRestartStatus schema reference Used in: KafkaConnectorStatus , KafkaMirrorMaker2Status Property Property type Description count integer The number of times the connector or task is restarted. connectorName string The name of the connector being restarted. lastRestartTimestamp string The last time the automatic restart was attempted. The required format is 'yyyy-MM-ddTHH:mm:ssZ' in the UTC time zone.

Commands:
Chapter 5. Viewing logs for a resource You can view the logs for various resources, such as builds, deployments, and pods by using the OpenShift CLI (oc) and the web console. Note Resource logs are a default feature that provides limited log viewing capability. To enhance your log retrieving and viewing experience, it is recommended that you install OpenShift Logging . The logging subsystem aggregates all the logs from your OpenShift Container Platform cluster, such as node system audit logs, application container logs, and infrastructure logs, into a dedicated log store. You can then query, discover, and visualize your log data through the Kibana interface . Resource logs do not access the logging subsystem log store. 5.1. Viewing resource logs You can view the log for various resources in the OpenShift CLI (oc) and web console. Logs read from the tail, or end, of the log. Prerequisites Access to the OpenShift CLI (oc). Procedure (UI) In the OpenShift Container Platform console, navigate to Workloads Pods or navigate to the pod through the resource you want to investigate. Note Some resources, such as builds, do not have pods to query directly. In such instances, you can locate the Logs link on the Details page for the resource. Select a project from the drop-down menu. Click the name of the pod you want to investigate. Click Logs . Procedure (CLI) View the log for a specific pod: USD oc logs -f <pod_name> -c <container_name> where: -f Optional: Specifies that the output follows what is being written into the logs. <pod_name> Specifies the name of the pod. <container_name> Optional: Specifies the name of a container. When a pod has more than one container, you must specify the container name. For example: USD oc logs ruby-58cd97df55-mww7r USD oc logs -f ruby-57f7f4855b-znl92 -c ruby The contents of log files are printed out. View the log for a specific resource: USD oc logs <object_type>/<resource_name> 1 1 Specifies the resource type and name. For example: USD oc logs deployment/ruby The contents of log files are printed out.

Commands:
oc logs -f <pod_name> -c <container_name>
oc logs ruby-58cd97df55-mww7r
oc logs -f ruby-57f7f4855b-znl92 -c ruby
oc logs <object_type>/<resource_name> 1
oc logs deployment/ruby
13.3. Enabling the Compose Key The Compose key is a feature that enables you to type special symbols or characters not found on your keyboard. In GNOME Desktop, you can define one of the existing keys on your keyboard as the Compose key . The Compose key is used in combination with other keys, known as Compose key sequences, to enter special characters you type frequently. Example 13.1. Using Compose Key If you press and release the Compose key , then type AE (in capitals), you will get "AE". If you type the letters in lower case, you get "ae". To enable the Compose key and configure a certain key on your keyboard as the Compose key , set the org.gnome.desktop.input-sources.xkb-options GSettings key. That way, the setting will be enabled by default for all users on your system. (For more information on GSettings keys, see Section 9.6, "GSettings Keys Properties" .) Procedure 13.3. Setting the Right Alt Key as the Compose Key Create a local database for machine-wide settings in /etc/dconf/db/local.d/00-input-sources : If you want to set a different key than Right Alt , replace ralt with the name of that key as specified in the xkeyboard-config (7) man page, section Compose key position . Override the user's setting and prevent the user from changing it in /etc/dconf/db/local.d/locks/input-sources : Update the system databases for the changes to take effect: Users must log out and back in again before the system-wide settings take effect. Now, you can start using the Right Alt key as the Compose key . Just press and release the Compose key and then type the key combination to get the specific symbol. Note If you, as a system administrator, set the lock on after editing the local database, users will not be able to add other xkb options. The lock prevents users from setting a key combination like Alt + Shift to switch keyboard layouts.

Commands:
Set the Right Alt key as the Compose key and enable it xkb-options=['compose: ralt ']
Lock the list of enabled XKB options /org/gnome/desktop/input-sources/xkb-options
dconf update
15.6. Booting the Manager Virtual Machine in Rescue Mode This topic describes how to boot the Manager virtual machine into rescue mode when it does not start. For more information, see Booting to Rescue Mode in the Red Hat Enterprise Linux System Administrator's Guide . Connect to one of the hosted-engine nodes: Put the self-hosted engine in global maintenance mode: Check if there is already a running instance of the Manager virtual machine: If a Manager virtual machine instance is running, connect to its host: Shut down the virtual machine: Note If the virtual machine does not shut down, execute the following command: Start the Manager virtual machine in pause mode: Set a temporary VNC password: The command outputs the necessary information you need to log in to the Manger virtual machine with VNC. Log in to the Manager virtual machine with VNC. The Manager virtual machine is still paused, so it appears to be frozen. Resume the Manager virtual machine with the following command on its host: Warning After running the following command, the boot loader menu appears. You need to enter into rescue mode before the boot loader proceeds with the normal boot process. Read the step about entering into rescue mode before proceeding with this command. Boot the Manager virtual machine in rescue mode. Disable global maintenance mode You can now run rescue tasks on the Manager virtual machine.

Commands:
ssh root@ host_address
hosted-engine --set-maintenance --mode=global
hosted-engine --vm-status
ssh root@ host_address
hosted-engine --vm-shutdown
hosted-engine --vm-poweroff
hosted-engine --vm-start-paused
hosted-engine --add-console-password
/usr/bin/virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf resume HostedEngine
hosted-engine --set-maintenance --mode=none
Chapter 17. EphemeralStorage schema reference Used in: JbodStorage , KafkaClusterSpec , KafkaNodePoolSpec , ZookeeperClusterSpec The type property is a discriminator that distinguishes use of the EphemeralStorage type from PersistentClaimStorage . It must have the value ephemeral for the type EphemeralStorage . Property Property type Description id integer Storage identification number. It is mandatory only for storage volumes defined in a storage of type 'jbod'. sizeLimit string When type=ephemeral, defines the total amount of local storage required for this EmptyDir volume (for example 1Gi). type string Must be ephemeral .

Commands:
Chapter 101. JarArtifact schema reference Used in: Plugin Property Property type Description type string Must be jar . url string URL of the artifact which will be downloaded. Streams for Apache Kafka does not do any security scanning of the downloaded artifacts. For security reasons, you should first verify the artifacts manually and configure the checksum verification to make sure the same artifact is used in the automated build. Required for jar , zip , tgz and other artifacts. Not applicable to the maven artifact type. sha512sum string SHA512 checksum of the artifact. Optional. If specified, the checksum will be verified while building the new container. If not specified, the downloaded artifact will not be verified. Not applicable to the maven artifact type. insecure boolean By default, connections using TLS are verified to check they are secure. The server certificate used must be valid, trusted, and contain the server name. By setting this option to true , all TLS verification is disabled and the artifact will be downloaded, even when the server is considered insecure.

Commands:
Chapter 10. Viewing and managing Quartz Schedules Quartz is a richly featured, open source job scheduling library that you can integrate within most Java applications. You can use Quartz to create simple or complex schedules for executing jobs. A job is defined as a standard Java component that can execute virtually anything that you program it to do. HawtIO shows the Quartz tab if your Camel route deploys the camel-quartz component. Note that you can alternately access Quartz mbeans through the JMX tree view. Procedure : In HawtIO, click the Quartz tab. The Quartz page includes a tree view of the Quartz Schedulers and Scheduler , Triggers , and Jobs tabs. To pause or start a scheduler, click the buttons on the Scheduler tab. Click the Triggers tab to view the triggers that determine when jobs will run. For example, a trigger can specify to start a job at a certain time of day (to the millisecond), on specified days, or repeated a specified number of times or at specific times. To filter the list of triggers select State , Group , Name , or Type from the drop-down list. You can then further filter the list by selecting or typing in the fill-on field. To pause, resume, update, or manually fire a trigger, click the options in the Action column. Click the Jobs tab to view the list of running jobs. You can sort the list by the columns in the table: Group , Name , Durable , Recover , Job ClassName , and Description .

Commands:
Chapter 1. About Serverless 1.1. OpenShift Serverless overview OpenShift Serverless provides Kubernetes native building blocks that enable developers to create and deploy serverless, event-driven applications on OpenShift Dedicated. OpenShift Serverless is based on the open source Knative project , which provides portability and consistency for hybrid and multi-cloud environments by enabling an enterprise-grade serverless platform. Note Because OpenShift Serverless releases on a different cadence from OpenShift Dedicated, the OpenShift Serverless documentation is now available as a separate documentation set at Red Hat OpenShift Serverless .

Commands: