mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 12. Editing applications You can edit the configuration and the source code of the application you create using the Topology view. 12.1. Prerequisites You have the appropriate roles and permissions in a project to create and modify applications in OpenShift Container Platform. You have created and deployed an application on OpenShift Container Platform using the Developer perspective . You have logged in to the web console and have switched to the Developer perspective . 12.2. Editing the source code of an application using the Developer perspective You can use the Topology view in the Developer perspective to edit the source code of your application. Procedure In the Topology view, click the Edit Source code icon, displayed at the bottom-right of the deployed application, to access your source code and modify it. Note This feature is available only when you create applications using the From Git , From Catalog , and the From Dockerfile options. If the Eclipse Che Operator is installed in your cluster, a Che workspace ( ) is created and you are directed to the workspace to edit your source code. If it is not installed, you will be directed to the Git repository ( ) your source code is hosted in. 12.3. Editing the application configuration using the Developer perspective You can use the Topology view in the Developer perspective to edit the configuration of your application. Note Currently, only configurations of applications created by using the From Git , Container Image , From Catalog , or From Dockerfile options in the Add workflow of the Developer perspective can be edited. Configurations of applications created by using the CLI or the YAML option from the Add workflow cannot be edited. Prerequisites Ensure that you have created an application using the From Git , Container Image , From Catalog , or From Dockerfile options in the Add workflow. Procedure After you have created an application and it is displayed in the Topology view, right-click the application to see the edit options available. Figure 12.1. Edit application Click Edit application-name to see the Add workflow you used to create the application. The form is pre-populated with the values you had added while creating the application. Edit the necessary values for the application. Note You cannot edit the Name field in the General section, the CI/CD pipelines, or the Create a route to the application field in the Advanced Options section. Click Save to restart the build and deploy a new image. Figure 12.2. Edit and redeploy application

Commands:
Chapter 1. Red Hat Enterprise Linux 6.7 International Languages Red Hat Enterprise Linux 6.7 supports installation of multiple languages and changing of languages based on your requirements. The following languages are supported in Red Hat Enterprise Linux 6.7: East Asian Languages - Japanese, Korean, Simplified Chinese, and Traditional Chinese European Languages - English, German, Spanish, French, Portuguese Brazilian, and Russian, Indic Languages - Assamese, Bengali, Gujarati, Hindi, Kannada, Malayalam, Marathi, Oriya, Punjabi, Tamil, and Telugu The table below summarizes the currently supported languages, their locales, default fonts installed and packages required for some of the supported languages Table 1.1. Red Hat Enterprise Linux 6 International Languages Territory Language Locale Fonts Package Names China Simplified Chinese zh_CN.UTF-8 AR PL (ShanHeiSun and Zenkai) Uni fonts-chinese, scim-pinyin, scim-tables Japan Japanese ja_JP.UTF-8 Sazanami (Gothic and Mincho) fonts-japanese, scim-anthy Korea Hangul ko_KR.UTF-8 Baekmuk (Batang, Dotum, Gulim, Headline) fonts-korean, scim-hangul Taiwan Traditional Chinese zh_TW.UTF-8 AR PL (ShanHeiSun and Zenkai) Uni fonts-chinese, scim-chewing, scim-tables Brazil Portuguese pt_BR.UTF-8 standard latin fonts France French ft_FR.UTF-8 standard latin fonts Germany German de_DE.UTF-8 standard latin fonts Italy Italy it_IT.UTF-8 standard latin fonts Russia Russian ru_RU.UTF-8 Cyrillic dejavu-lgc-sans-fonts, dejavu-lgc-sans-mono-fonts, dejavu-lgc-serif-fonts, xorg-x11-fonts-cyrillic Spain Spanish es_ES.UTF-8 standard latin fonts India Assamese as_IN.UTF-8 Lohit Bengali fonts-bengali, scim-m17n, m17n-db-assamese Bengali bn_IN.UTF-8 Lohit Bengali fonts-bengali, scim-m17n, m17n-db-bengali Gujarati gu_IN.UTF-8 Lohit Gujarati fonts-gujarati, scim-m17n, m17n-db-gujarati Hindi hi_IN.UTF-8 Lohit Hindi fonts-hindi, scim-m17n, m17n-db-hindi Kannada kn_IN.UTF-8 Lohit Kannada fonts-kannada, scim-m17n, m17n-db-kannada Malayalam ml_IN.UTF-8 Lohit Malayalam fonts-malayalam, scim-m17n, m17n-db-malayalam Marathi mr_IN.UTF-8 Lohit Hindi fonts-hindi, scim-m17n, m17n-db-marathi Oriya or_IN.UTF-8 Lohit Oriya fonts-oriya, scim-m17n, m17n-db-oriya Punjabi pa_IN.UTF-8 Lohit Punjabi fonts-punjabi, scim-m17n, m17n-db-punjabi Tamil ta_IN.UTF-8 Lohit Tamil fonts-tamil, scim-m17n, m17n-db-tamil Telugu te_IN.UTF-8 Lohit Telugu fonts-telugu, scim-m17n, m17n-db-telugu

Commands:
Chapter 28. Installing DNS on an existing IdM server Install the DNS service on an Identity Management (IdM) server that was originally installed without it. Prerequisites You understand the advantages and limitations of using IdM with integrated DNS as described in Installing an IdM server: With integrated DNS, with an integrated CA as the root CA . You have root access to the IdM server. Procedure Optional: Verify that DNS is not already installed on the IdM server. The output confirms that IdM DNS is not available on the server. Download the ipa-dns-server package and its dependencies: Start the script to install DNS on the server: The script prompts for per-server DNS forwarders. To configure per-server DNS forwarders, enter yes , and then follow the instructions on the command line. The installation process will add the forwarder IP addresses to the IdM LDAP. For the forwarding policy default settings, see the --forward-policy description in the ipa-dns-install (1) man page. If you do not want to use DNS forwarding, enter no . With no DNS forwarders, hosts in your IdM domain will not be able to resolve names from other, internal, DNS domains in your infrastructure. The hosts will only be left with public DNS servers to resolve their DNS queries. The script prompts to check if any DNS reverse (PTR) records for the IP addresses associated with the server need to be configured. If you run the search and missing reverse zones are discovered, the script asks you whether to create the reverse zones along with the PTR records. Note Using IdM to manage reverse zones is optional. You can use an external DNS service for this purpose instead. Additional resources man ipa-dns-install(1)

Commands:
ipa server-role-show r8server.idm.example.com Role name: DNS server Server name: r8server.idm.example.com Role name: DNS server Role status: absent
dnf install ipa-server-dns
ipa-dns-install
Do you want to configure DNS forwarders? [yes]:
Do you want to search for missing reverse zones? [yes]:
Do you want to create reverse zone for IP 192.0.2.1 [yes]: Please specify the reverse zone name [2.0.192.in-addr.arpa.]: Using reverse zone(s) 2.0.192.in-addr.arpa.
Chapter 1. Server Best Practices The following tasks and tips can assist you with increasing the performance of your Red Hat Enterprise Linux host. Additional tips can be found in the Red Hat Enterprise Linux Virtualization Tuning and Optimization Guide Run SELinux in enforcing mode. Set SELinux to run in enforcing mode with the setenforce command. Remove or disable any unnecessary services such as AutoFS , NFS , FTP , HTTP , NIS , telnetd , sendmail and so on. Only add the minimum number of user accounts needed for platform management on the server and remove unnecessary user accounts. Avoid running any unessential applications on your host. Running applications on the host may impact virtual machine performance and can affect server stability. Any application which may crash the server will also cause all virtual machines on the server to go down. Use a central location for virtual machine installations and images. Virtual machine images should be stored under /var/lib/libvirt/images/ . If you are using a different directory for your virtual machine images make sure you add the directory to your SELinux policy and relabel it before starting the installation. Use of shareable, network storage in a central location is highly recommended.

Commands:
setenforce 1
10.3.5. The "drive must have a GPT disk label" Error Message When installing Red Hat Enterprise Linux on a system with UEFI system and using a disk with an existing partitioning layout as the boot drive (the drive where the boot loader is installed), you may encounter the following error message during custom partitioning: This happens because the boot drive (in this case, sda ) has a Master Boot Record (MBR) label, but UEFI systems require a GUID Partition Table (GPT) label. Therefore you can not reuse an existing partitioning layout on a MBR-labeled drive; the disk must be relabeled, which means you will have to create a new partition layout and lose all existing data. To work around this problem, go back to the screen where you select your partitioning strategy. Select an option other than custom partitioning (for example Use All Space ). Make sure to check the Review and modify partitioning layout check box, and click . On the following screen, modify the automatically created layout so it suits your needs. After you finish and click , Anaconda will use your layout and relabel the drive automatically. You can also solve this issue by using a Kickstart file or by relabeling the disk using a different system before you begin the installation. See Section 3.5.2, "Disk Drives with MBR on UEFI Systems" for details. Also see Section A.1.2, "Partitions: Turning One Drive Into Many" for additional information about MBR and GPT.

Commands:
sda must have a GPT disk label
7.155. pcre 7.155.1. RHEA-2015:1374 - pcre enhancement update Updated pcre packages that add one enhancement are now available for Red Hat Enterprise Linux 6. PCRE is a Perl-compatible regular expression library. Enhancement BZ# 1193524 To allow the grep utility to recover from PCRE matching failures if the binary file is not a valid UTF-8 sequence, the following features have been backported to the PCRE library: - The pcre_exec() function now checks for out-of-range starting offset values and reports PCRE_ERROR_BADOFFSET errors instead of reporting PCRE_ERROR_NOMATCH errors or looping infinitely. - If the pcre_exec() function is called to perform a UTF-8 match on an invalid UTF-8 subject string and the ovector array argument is large enough, the offset of the first subject string in the invalid UTF-8 byte, as well as the detailed reason code, are returned in the ovector array element. In addition, the "pcretest" utility can now be used to display these details. Note that with this update, the pcre_compile() function reports first invalid UTF-8 byte instead of the last byte. Also note that the signature of the pcre_valid_utf8() function, which is not intended for public use, has been changed. Finally, note that "pcretest" now appends human-readable error messages to error codes. Users of pcre are advised to upgrade to these updated packages, which add this enhancement.

Commands:
Chapter 13. Setting Breakpoints Overview To set breakpoints, your project's routing context .xml file must be open in the route editor's Design tab. The Camel debugger supports two types of breakpoints: Unconditional breakpoints - triggered whenever one is encountered during a debugging session Conditional breakpoints - triggered only when the breakpoint's specified condition is met during a debugging session Note You cannot set breakpoints on consumer endpoints or on when or otherwise nodes. Setting unconditional breakpoints With your routing context displayed on the canvas in the Design tab: Select a node whose state you want to examine during the debugging session. Click its icon to set an unconditional breakpoint. Repeat these steps for each node on which you want to set an unconditional breakpoint. Setting conditional breakpoints With your routing context displayed on the canvas in the Design tab: Select a node whose state you want to examine during the debugging session. Click its icon to set a conditional breakpoint and to open the Edit the condition and language of your breakpoint... dialog: Click the Language drop-down menu and select the expression language to use to create the condition that will trigger the breakpoint. Fuse Tooling supports twenty-four expression languages. Some of these languages provide variables for creating conditional expressions, while others do not. Click Variables to display a list of the selected language's supported variables. If a list appears, select in sequence one or more of the variables to create the condition for triggering the breakpoint. The variables you select appear in the Condition text box. If appears, enter the expression directly into the Condition text box. Repeat steps [condBpFirst] through [condBpLast] for each node on which you want to set a conditional breakpoint. Disabling breakpoints You can temporarily disable a breakpoint, leaving it in place, then enable it again later. The button skips over disabled breakpoints during debugging sessions. To disable a breakpoint, select the node on the canvas and click its icon. The breakpoint turns gray, indicating that it has been disabled. To enable a disabled breakpoint, select the node on the canvas and click its icon. Depending on whether the disabled breakpoint is conditional or unconditional, it turns yellow or red, respectively, to indicate that it has been re-enabled. Note You can also disable and re-enable breakpoints during debugging sessions. For details, see Chapter 18, Disabling Breakpoints in a Running Context . Deleting breakpoints You can delete individual breakpoints or all breakpoints. To delete individual breakpoints - in a route container, select the node whose breakpoint you want to delete, and click its icon. To delete all breakpoints in a particular route - right-click the target route's container, and select Delete all breakpoints . To delete all breakpoints in all routes - right-click the canvas, and select Delete all breakpoints . Related topics Chapter 14, Running the Camel Debugger

Commands:
35.2. Configuring the Directory Server Component To configure DS automatically using the ldapmodify utility: Use ldapmodify to make the configuration changes for you: Restart DS to load the new configuration: To configure Directory Server (DS) manually: Stop DS: Open the /etc/dirsrv/slapd- EXAMPLE-COM /dse.ldif file, and modify the cn=encryption,cn=config entry to set the following: Start DS: Important Make sure you shut down the server first before editing the dse.ldif file manually. DS reads this file only once at startup, therefore any manual changes while the server is running will be lost if the configuration changes through LDAP. Editing the dse.ldif file is recommended only for changes to attributes which cannot be altered dynamically.

Commands:
ldapmodify -h localhost -p 389 -D 'cn=directory manager' -W << EOF dn: cn=encryption,cn=config changeType: modify replace: sslVersionMin sslVersionMin: TLS1.2 EOF
systemctl restart dirsrv@ EXAMPLE-COM .service
systemctl stop dirsrv@ EXAMPLE-COM .service
sslVersionMin: TLS1.2
systemctl start dirsrv@ EXAMPLE-COM .service
Chapter 18. Configuring Dead Letter Addresses A dead letter address is defined in the address-setting element of the messaging-activemq subsystem configuration. To read the current configuration for a given address-setting , use the following management CLI command as an example. If a dead-letter-address is not specified, messages are removed after trying to deliver max-delivery-attempts times. By default, messages delivery is attempted 10 times. Setting max-delivery-attempts to -1 allows infinite redelivery attempts. The example management CLI commands below illustrate how to set the dead-letter-address and the max-delivery-attempts attributes for a given address-setting . For example, a dead letter can be set globally for a set of matching addresses and you can set max-delivery-attempts to -1 for a specific address setting to allow infinite redelivery attempts only for this address. Address wildcards can also be used to configure dead letter settings for a set of addresses. See Address Settings for details on creating and configuring an address-setting .

Commands:
/subsystem=messaging-activemq/server=default/address-setting= ADDRESS_SETTING :read-attribute(name=dead-letter-address)
/subsystem=messaging-activemq/server=default/address-setting= ADDRESS_SETTING :write-attribute(name=dead-letter-address,value= NEW_VALUE ) /subsystem=messaging-activemq/server=default/address-setting= ADDRESS_SETTING :write-attribute(name=max-delivery-attempts,value= NEW_VALUE )
4.262. qt3 4.262.1. RHBA-2011:1269 - qt3 bug fix update Updated qt3 packages that fix one bug are now available for Red Hat Enterprise Linux 6. Qt is a software toolkit that simplifies the task of writing and maintaining GUI (Graphical User Interface) applications for the X Window System. Bug Fix BZ# 651426 Prior to this update, the 64-bit architecture was not preferred over the 32-bit architecture when setting the PATH environment variable on the 64-bit PowerPC platform. This bug has been fixed in this update so that the 64-bit architecture is now preferred. All users of qt3 are advised to upgrade to these updated packages, which fix this bug.

Commands:
Providing feedback on Red Hat JBoss Web Server documentation To report an error or to improve our documentation, log in to your Red Hat Jira account and submit an issue. If you do not have a Red Hat Jira account, then you will be prompted to create an account. Procedure Click the following link to create a ticket . Enter a brief description of the issue in the Summary . Provide a detailed description of the issue or enhancement in the Description . Include a URL to where the issue occurs in the documentation. Clicking Create creates and routes the issue to the appropriate documentation team.

Commands:
7.2.2. Daisy-Wheel Printers If you have ever worked with a manual typewriter before, then you understand the technological concept behind daisy-wheel printers. These printers have printheads composed of metallic or plastic wheels cut into petals . Each petal has the form of a letter (in capital and lower-case), number, or punctuation mark on it. When the petal is struck against the printer ribbon, the resulting shape forces ink onto the paper. Daisy-wheel printers are loud and slow. They cannot print graphics, and cannot change fonts unless the print wheel is physically replaced. With the advent of laser printers, daisy-wheel printers are generally not used in modern computing environments.

Commands:
Chapter 5. Container images with Go Toolset You can build your own Go Toolset containers from either Red Hat Enterprise Linux container images or Red Hat Universal Base Images (UBI). 5.1. Red Hat Enterprise Linux Go Toolset container images contents The Red Hat Enterprise Linux 8 and Red Hat Enterprise Linux 9 container images of Go Toolset contain the following packages: Component Version Package Go 1.20 RHEL 8 - go-toolset-1.20.10 RHEL 9 - go-toolset-1.20.10 5.2. Accessing Red Hat Enterprise Linux container images Pull the container image from the Red Hat registry before running your container and performing actions. Procedure To pull the required image, run: For an image based on Red Hat Enterprise Linux 8: For an image based on Red Hat Enterprise Linux 9: 5.3. Accessing the UBI Go Toolset container image on RHEL 8 On RHEL 8, install the UBI Go Toolset container image to access Go Toolset. Alternatively, you can install Go Toolset to the RHEL 8 base UBI container image. For further information, see Accessing Go Toolset from the base UBI container image on RHEL 8 . Procedure To pull the UBI Go Toolset container image from the Red Hat registry, run: 5.4. Accessing Go Toolset from the base UBI container image on RHEL 8 On RHEL 8, Go Toolset packages are part of the Red Hat Universal Base Images (UBIs) repositories, which means you can install Go Toolset as an addition to the base UBI container image. To keep the container image size small, install only individual packages instead of the entire Go Toolset. Alternatively, you can install the UBI Go Toolset container image to access Go Toolset. For further information, see Accessing the UBI Go Toolset container image on RHEL 8 . Prerequisites An existing Containerfile. For information on creating Containerfiles, see the Dockerfile reference page. Procedure To create a container image containing Go Toolset, add the following lines to your Containerfile: To create a container image containing an individual package only, add the following lines to your Containerfile: Replace < package-name > with the name of the package you want to install. 5.5. Additional resources Go Toolset Container Images in the Red Hat Container Registry . For more information on Red Hat UBI images, see Working with Container Images . For more information on Red Hat UBI repositories, see Universal Base Images (UBI): Images, repositories, packages, and source code .

Commands:
podman pull registry.redhat.io/rhel8/go-toolset
podman pull registry.redhat.io/rhel9/go-toolset
podman pull registry.access.redhat.com/ubi8/go-toolset
FROM registry.access.redhat.com/ubi8/ubi: latest RUN yum module install -y go-toolset
RUN yum install -y < package-name >
Chapter 14. Tuning serving configuration 14.1. Overriding Knative Serving system deployment configurations You can override the default configurations for some specific deployments by modifying the workloads spec in the KnativeServing custom resources (CRs). 14.1.1. Overriding system deployment configurations Currently, overriding default configuration settings is supported for the resources , replicas , labels , annotations , and nodeSelector fields, as well as for the readiness and liveness fields for probes. In the following example, a KnativeServing CR overrides the webhook deployment so that: The readiness probe timeout for net-kourier-controller is set to be 10 seconds. The deployment has specified CPU and memory resource limits. The deployment has 3 replicas. The example-label: label label is added. The example-annotation: annotation annotation is added. The nodeSelector field is set to select nodes with the disktype: hdd label. Note The KnativeServing CR label and annotation settings override the deployment's labels and annotations for both the deployment itself and the resulting pods. KnativeServing CR example apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: ks namespace: knative-serving spec: high-availability: replicas: 2 workloads: - name: net-kourier-controller readinessProbes: 1 - container: controller timeoutSeconds: 10 - name: webhook resources: - container: webhook requests: cpu: 300m memory: 60Mi limits: cpu: 1000m memory: 1000Mi replicas: 3 labels: example-label: label annotations: example-annotation: annotation nodeSelector: disktype: hdd 1 You can use the readiness and liveness probe overrides to override all fields of a probe in a container of a deployment as specified in the Kubernetes API except for the fields related to the probe handler: exec , grpc , httpGet , and tcpSocket . Additional resources Probe configuration section of the Kubernetes API documentation

Commands:
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: ks namespace: knative-serving spec: high-availability: replicas: 2 workloads: - name: net-kourier-controller readinessProbes: 1 - container: controller timeoutSeconds: 10 - name: webhook resources: - container: webhook requests: cpu: 300m memory: 60Mi limits: cpu: 1000m memory: 1000Mi replicas: 3 labels: example-label: label annotations: example-annotation: annotation nodeSelector: disktype: hdd