mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 10. HTTP configuration 10.1. Global HTTPS redirection HTTPS redirection provides redirection for incoming HTTP requests. These redirected HTTP requests are encrypted. You can enable HTTPS redirection for all services on the cluster by configuring the httpProtocol spec for the KnativeServing custom resource (CR). 10.1.1. HTTPS redirection global settings Example KnativeServing CR that enables HTTPS redirection apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: network: httpProtocol: "redirected" ... 10.2. HTTPS redirection per service You can enable or disable HTTPS redirection for a service by configuring the networking.knative.dev/http-option annotation. 10.2.1. Redirecting HTTPS for a service The following example shows how you can use this annotation in a Knative Service YAML object: apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example namespace: default annotations: networking.knative.dev/http-protocol: "redirected" spec: ... 10.3. Full duplex support for HTTP/1 You can enable the HTTP/1 full duplex support for a service by configuring the features.knative.dev/http-full-duplex annotation. Note Verify your HTTP clients before enabling, as earlier version clients might not provide support for HTTP/1 full duplex. The following example shows how you can use this annotation in a Knative Service YAML object at the revision spec level: Example KnativeServing CR that provides full duplex support for HTTP/1 apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: metadata: annotations: features.knative.dev/http-full-duplex: "Enabled" ...

Commands:
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: network: httpProtocol: "redirected"
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example namespace: default annotations: networking.knative.dev/http-protocol: "redirected" spec:
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: example-service namespace: default spec: template: metadata: annotations: features.knative.dev/http-full-duplex: "Enabled"
1.9. Changing the LDAP and LDAPS Port Numbers By default, Directory Server uses port 389 for the LDAP and, if enabled, port 636 for the LDAPS protocol. You can change these port numbers, for example, to run multiple Directory Server instances on one host. Important The new ports you assign to the protocols for an instance must not be in use by any other service. 1.9.1. Changing the Port Numbers Using the Command Line To change the port numbers using the command line, update the following parameters: nsslapd-port : Stores the port number the instance uses for the LDAP protocol. nsslapd-secureport : Stores the port number the instance uses for the LDAPS protocol. To change the port numbers of the LDAP and LDAPS protocol using the command line: Optionally, display the currently configured port numbers for the instance: To change the LDAP port: Set the port for the LDAP protocol. For example, to set it to 1389 : Set the ldap_port_t type for the LDAP port you assigned in the step: To change the LDAPS port: Set the port for the LDAPS protocol. For example, to set it to 1636 : Set the ldap_port_t type for the LDAPS port you assigned in the step: Restart the instance: 1.9.2. Changing the Port Numbers Using the Web Console To change the port numbers of the LDAP and LDAPS protocol using the web console: Open the Directory Server user interface in the web console. See Section 1.4, "Logging Into Directory Server Using the Web Console" . Select the instance. To change the LDAP port: Open the Server Settings menu. On the Server Settings tab, fill the new port number into the LDAP Port field. Click Save . To change the LDAPS port: Open the Server Settings menu. On the General Settings tab, fill the new port number into the LDAPS Port field. Click Save . Restart the instance. See Section 1.5.2, "Starting and Stopping a Directory Server Instance Using the Web Console" .

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com config get nsslapd-port nsslapd-secureport nsslapd-port: 389 nsslapd-secureport: 636
dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-port= 1389 Successfully replaced "nsslapd-port"
semanage port -a -t ldap_port_t -p tcp 1389
dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-secureport= 1636 Successfully replaced "nsslapd-secureport"
semanage port -a -t ldap_port_t -p tcp 1636
dsctl instance_name restart
Chapter 35. Setting up and evaluating the 3scale API Management response codes log for your API To see how your clients are using the API, and see in real time if your servers are running as expected, set up and use the response codes log in 3scale. Procedure You have deployed the APIcast gateway: on a Docker containerized environment . Set the APICAST_RESPONSE_CODES environment variable to 1 or true . with the self-managed operator . Set the responseCodesIncluded to true in the APIcast CR. Example: Example When enabled, APIcast gateway captures the HTTP status code of API responses returned by the upstream service for authorized calls, and sends them to the Service Management API (in authrep call). Example: In this example, log[code]=200 is sent, which means that the API responded with a 200 status code. Verification To verify the integration, perform a call to your API product with valid 3scale credentials, and then verify that the call was correctly reported on the Analytics > Usage page. Note Response Code Tracking is not intended to be an accurate count of all responses. The value of this view is to provide a visual representation of the trend over a period of time. Response Code Tracking and 3scale Auth Caching mode: None is not a supported combination. If everything is going well so far, go to the Analytics >Response codes page. You should be able to see a graph with your latest traffic divided by colors, depending if the response was 2xx, 4xx, or 5xx. The graph tool gives you the ability to view the history of response codes. You can also check the response code statistics for different periods of time and different levels of granularity. Click the time selection bar and define the time period and granularity that meets your needs.

Commands:
apiVersion: apps.3scale.net/v1alpha1 kind: APIcast metadata: name: example-apicast spec: responseCodesIncluded: true
https://su1.3scale.net/transactions/authrep.xml?service_token={SERVICE_TOKEN}&service_id={SERVICE_ID}&user_key={USER_KEY}&usage%5Bhits%5D=1&log%5Bcode%5D=200"
5.12. axis 5.12.1. RHSA-2013:0269 - Moderate: axis security update Updated axis packages that fix one security issue are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. A 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. Apache Axis is an implementation of SOAP (Simple Object Access Protocol). It can be used to build both web service clients and servers. Security Fix CVE-2012-5784 Apache Axis did not verify that the server hostname matched the domain name in the subject's Common Name (CN) or subjectAltName field in X.509 certificates. This could allow a man-in-the-middle attacker to spoof an SSL server if they had a certificate that was valid for any domain name. All users of axis are advised to upgrade to these updated packages, which correct this issue. Applications using Apache Axis must be restarted for this update to take effect.

Commands:
5.268. qpid-cpp, python-qpid, and saslwrapper 5.268.1. RHBA-2012:0764 - qpid-cpp, python-qpid and saslwrapper bug fix and enhancement update Updated qpid-cpp, python-qpid, and saslwrapper packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. Qpid provides a message broker daemon that receives, stores and routes messages using the open AMQP messaging protocol along with run-time libraries for AMQP client applications developed using Qpid C++. Clients exchange messages with an AMQP message broker using the AMQP protocol. All qpid packages have been upgraded to upstream version 0.14, which provides a number of bug fixes and enhancements over the version. (BZ# 765803 , BZ# 765863 ) Bug Fixes BZ# 785919 Prior to this update, the spec file incorrectly used the "Vendor" tag. As a consequence, rebuilds could, under certain circumstances, incorrectly label packages. This update removes the "Vendor" tag. BZ# 788901 Prior to this update, the qpid daemon could, under certain circumstances, abort with a segmentation fault when attempting to shut down the SslPlugin if the plug-in was loaded without setting the "--ssl-cert-db" option. This update modifies the ssl.so module so that the SslPlugin shuts now down as expected. BZ# 799269 Prior to this update, the service qpid daemon was always enabled by default, which was not required. This update modifies the service settings so that the qpidd service is no longer enabled by default but only when required. Enhancements BZ# 703563 This update provides the environment variable "QPIDC_CONF_FILE" to allow to specify the location to look for the configuration file of the client. BZ# 749600 This update adds the python-saslwrapper package as a dependency for qpid-stat so that qpid-stat can use the DIGEST-MD5 module to authenticate to a broker. BZ# 771961 With this update, the spec file depends on specific boost-* packages instead of the boost metapackage. BZ# 808783 This update adds support for 64-bit PowerPC and IBM System z platforms to the python-saslwrapper package. All users of qpid-cpp are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
3.6. Listing ISO Files in the ISO Storage Domain This Ruby example lists the ISO files in the ISO storage domain, myiso . # Get the reference to the root of the services tree: system_service = connection.system_service # Find the service that manages the collection of storage domains: sds_service = system_service.storage_domains_service # Find the ISO storage domain: sd = sds_service.list(search: 'name=myiso').first # Find the service that manages the ISO storage domain: sd_service = sds_service.storage_domain_service(sd.id) # Find the service that manages the collection of files available in the storage domain: files_service = sd_service.files_service # List the names of the files. Note that the name of the .iso file is contained # in the `id` attribute. files = files_service.list files.each do |file| puts file.id end For more information, see FilesService:list . If you do not know the name of the ISO storage domain, this Ruby example retrieves all the ISO storage domains. # Find the ISO storage domain: iso_sds = sds_service.list.select { |sd| sd.type == OvirtSDK4::StorageDomainType::ISO } For more information, see StorageDomainsService:list .

Commands:
Get the reference to the root of the services tree: system_service = connection.system_service Find the service that manages the collection of storage domains: sds_service = system_service.storage_domains_service Find the ISO storage domain: sd = sds_service.list(search: 'name=myiso').first Find the service that manages the ISO storage domain: sd_service = sds_service.storage_domain_service(sd.id) Find the service that manages the collection of files available in the storage domain: files_service = sd_service.files_service List the names of the files. Note that the name of the .iso file is contained in the `id` attribute. files = files_service.list files.each do |file| puts file.id end
Find the ISO storage domain: iso_sds = sds_service.list.select { |sd| sd.type == OvirtSDK4::StorageDomainType::ISO }
7.244. syslinux 7.244.1. RHBA-2013:0473 - syslinux bug fix update Updated syslinux packages that fix one bug are now available for Red Hat Enterprise Linux 6. The syslinux utility is responsible for booting the operating system kernel. Bug Fix BZ#812034 A Coverity test revealed several static overruns in the creation of "hybrid" ISO images, which could lead to incorrect images being created. This bug has been fixed to correctly produce "hybrid" ISO images. All users of syslinux are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 4. Application Streams Multiple versions of user-space components are delivered as Application Streams and updated more frequently than the core operating system packages. This provides greater flexibility to customize RHEL without impacting the underlying stability of the platform or specific deployments. Each Application Stream component has a given life cycle, either the same as RHEL 9 or shorter. For RHEL life cycle information, see Red Hat Enterprise Linux Life Cycle and Red Hat Enterprise Linux Application Streams Life Cycle . Application Streams are available in the following formats: the familiar RPM format as an extension to the RPM format called modules as Software Collections as Flatpaks. RHEL 9 improves the Application Streams experience by providing initial Application Stream versions that can be installed as RPM packages using the traditional dnf install command. Note Certain initial Application Streams in the RPM format have a shorter life cycle than Red Hat Enterprise Linux 9. Some additional Application Stream versions will be distributed as modules with a shorter life cycle in future minor RHEL 9 releases. It is recommended to review the Red Hat Enterprise Linux Application Stream Lifecycle definitions for any content life cycle considerations. Always determine what version of an Application Stream you want to install and make sure to review the Red Hat Enterprise Linux Application Stream Lifecycle first. Content that needs rapid updating, such as alternate compilers and container tools, is available in rolling streams that will not provide alternative versions in parallel. Rolling streams can be packaged as RPMs or modules. For information about Application Streams available in RHEL 9 and their application compatibility level, see the Package manifest . Application compatibility levels are explained in the Red Hat Enterprise Linux 9: Application Compatibility Guide document. Additional resources Red Hat Enterprise Linux Life Cycle Red Hat Enterprise Linux Application Stream Lifecycle Red Hat Enterprise Linux 9: Application Compatibility Guide Managing software with the DNF tool Package manifest

Commands:
6.4. Custom Externalizer ID Values Advanced externalizers can be assigned custom IDs if desired. Some ID ranges are reserved for other modules or frameworks and must be avoided: Table 6.1. Reserved Externalizer ID Ranges ID Range Reserved For 1000-1099 The Infinispan Tree Module 1100-1199 Red Hat JBoss Data Grid Server modules 1200-1299 Hibernate Infinispan Second Level Cache 1300-1399 JBoss Data Grid Lucene Directory 1400-1499 Hibernate OGM 1500-1599 Hibernate Search 1600-1699 Infinispan Query Module 1700-1799 Infinispan Remote Query Module Report a bug 6.4.1. Customize the Externalizer ID (Declaratively) Customize the advanced externalizer ID declaratively (via XML) as follows: Procedure 6.2. Customizing the Externalizer ID (Declaratively) Add the global element to the infinispan element. Add the serialization element to the global element. Add the advancedExternalizer element to add information about the new advanced externalizer. Define the externalizer ID using the id attribute. Ensure that the selected ID is not from the range of IDs reserved for other modules. Define the externalizer class using the externalizerClass attribute. Replace the USDIdViaAnnotationObj and USDAdvancedExternalizer values as required. Report a bug 6.4.2. Customize the Externalizer ID (Programmatically) Use the following configuration to programmatically assign a specific ID to the externalizer: Example 6.5. Assign an ID to the Externalizer Replace the USDID with the desired ID. Report a bug

Commands:
<infinispan> <global> <serialization> <advancedExternalizers> <advancedExternalizer id="USDID" externalizerClass="org.infinispan.marshall.AdvancedExternalizerTestUSDIdViaConfigObjUSDExternalizer"/> </advancedExternalizers> </serialization> </global> </infinispan>
GlobalConfiguration globalConfiguration = new GlobalConfigurationBuilder() .serialization() .addAdvancedExternalizer(USDID, new Person.PersonExternalizer()) .build();
Chapter 2. Updating your playbook set_stats fields to support integration with Automation Services Catalog You can update your playbooks to pass information to Automation Services Catalog and support substitutable variables across the product in your order process workflow. 2.1. Writing playbook that return values to Automation Services Catalog You can write playbooks designed to return values to Automation Services Catalog. Prefixing set_stats parameters with expose_to_cloud_redhat_com_ will return that value to Automation Services Catalog. You can then pass those values through additional playbooks using substitutable variables. Use the playbook examples below to learn now about set_stats values and to pass values back to Automation Services Catalog and use them as substitutable values in subsequent playbooks in your order processes. Example before order playbook This before order playbook returns to Automation Services Catalog set_stats values for a favorite color: # This playbook prints a simple debug message and set_stats - name: Echo Hello, world! hosts: localhost gather_facts: yes tasks: - debug: msg: "Hello, world!" - set_stats: data: expose_to_cloud_redhat_com_favorite_color: "orange" Example product order playbook This playbook passes a substitutable value back to Automation Services Catalog as an artifact value. # This playbook prints a simple debug message with given information - name: Echo Hello, world! hosts: localhost gather_facts: yes tasks: - debug: msg: "Hello, {{favorite_color}} world!" - set_stats: data: expose_to_cloud_redhat_com_after_data: "{{favorite_color}}" Example after order playbook The after order playbook example below includes the artifact after_data value that was passed by the product playbook. # This playbook prints a simple debug message with given information - name: Echo Hello, world! hosts: localhost gather_facts: yes tasks: - debug: msg: "{{after_data}}" ~

Commands:
This playbook prints a simple debug message and set_stats - name: Echo Hello, world! hosts: localhost gather_facts: yes tasks: - debug: msg: "Hello, world!" - set_stats: data: expose_to_cloud_redhat_com_favorite_color: "orange"
This playbook prints a simple debug message with given information - name: Echo Hello, world! hosts: localhost gather_facts: yes tasks: - debug: msg: "Hello, {{favorite_color}} world!" - set_stats: data: expose_to_cloud_redhat_com_after_data: "{{favorite_color}}"
This playbook prints a simple debug message with given information - name: Echo Hello, world! hosts: localhost gather_facts: yes tasks: - debug: msg: "{{after_data}}" ~
4.3. acl 4.3.1. RHBA-2011:0924 - acl bug fix update Updated acl packages that fix two bugs are now available for Red Hat Enterprise Linux 6. Access Control Lists (ACLs) are used to define finer-grained discretionary access rights for files and directories. The acl packages contain the getfacl and setfacl utilities needed for manipulating access control lists. Bug Fixes BZ# 674883 Prior to this update, the setfacl.1 man page was not intelligible in that it did not state that removing a non-existent ACL entry is not considered to be an error. With this update, the setfacl.1 man page has been updated so that its content is now intelligible and exactly specifies the aforementioned behavior with regard to removing a non-existent ACL entry. BZ# 702638 Prior to this update, the package specification did not reflect a change of the upstream project web page address. This update corrects the respective address in the package specification. All users of Access Control Lists should upgrade to these updated packages, which fix these bugs. 4.3.2. RHEA-2011:1657 - acl enhancement update Updated acl packages that add two enhancements are now available for Red Hat Enterprise Linux 6. Access Control Lists (ACLs) are used to define finer-grained discretionary access rights for files and directories. The acl packages contain the getfacl and setfacl utilities needed for manipulating access control lists. Enhancements BZ# 720318 Prior to this update, the ACL library did not provide any function to check for extended ACLs of a file without following symbolic links. The only available function, acl_extended_file(), used to cause unnecessary mounts of autofs. This update introduces a new function, acl_extended_file_nofollow(), that checks for extended ACLs of a file without following symbolic links. BZ# 723998 Previously, the ACL library was linked without support for RELRO (read-only relocations) flags. With this update, the library is now linked with partial RELRO support. Users of acl are advised to upgrade to these updated packages, which add these enhancements.

Commands:
Argo CD application sets Red Hat OpenShift GitOps 1.15 Managing the application set resources in non-control plane namespaces Red Hat OpenShift Documentation Team

Commands:
apiVersion: argoproj.io/v1beta1 kind: ArgoCD metadata: name: example namespace: spring-petclinic spec: applicationSet: sourceNamespaces: 1 - dev 2
apiVersion: argoproj.io/v1beta1 kind: ArgoCD metadata: name: example-argocd spec: applicationSet: sourceNamespaces: - dev scmProviders: 1 - https://git.mydomain.com/ - https://gitlab.mydomain.com/
Appendix C. Using AMQ Broker with the examples The AMQ Ruby examples require a running message broker with a queue named examples . 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 examples . USD <broker-instance-dir> /bin/artemis queue create --name examples --address examples --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:25:48 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 examples --address examples --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop