mtpti5iD/redhat-docs_dataset huggingface dataset:
8.222. spice-server 8.222.1. RHBA-2014:1435 - spice-server bug fix update Updated spice-server packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The Simple Protocol for Independent Computing Environments (SPICE) is a remote display protocol for virtual environments. SPICE users can access a virtualized desktop or server from the local system or any system with network access to the server. SPICE is used in Red Hat Enterprise Linux for viewing virtualized guests running on the Kernel-based Virtual Machine (KVM) hypervisor or on Red Hat Enterprise Virtualization Hypervisors. Bug Fixes BZ# 994175 Previously, the SPICE server assumed that the SPICE client was connected until it became disconnected. However, when the client became unresponsive, or did not disconnect explicitly, the server kept trying to communicate with it. Consequently, queues, such as a driver commands ring, filled up, and the guest display driver hung. With this update, the SPICE server monitors if the client is responsive and disconnect if it is not. BZ# 1004443 Previously, pending data from the client were cleaned inappropriately. As a consequence, QEMU could terminate unexpectedly when a VM was rebooting while being migrated. This update ensures that the pending client data are cleaned appropriately, and QEMU crashes no longer occur. BZ# 1035695 Prior to this update, the SPICE server used exclusively Transport Layer Security (TLS) version 1.0 for encrypted connections no matter what version(s) the client advertised. Consequently, the SPICE client could not use newer versions of TLS. To fix this bug, the SPICE server code has been changed to allow for TLS 1.0 and above, and clients can now connect using TLS version 1.0 or newer. BZ# 1072700 Due to an integer overflow on a 32 bit timer value, infinite loop in the SPICE server on long running VMs longer than 46 days caused SPICE sessions to become unresponsive. Where appropriate, 64 bit timer values are now used, and SPICE sessions no longer crash. BZ# 1086820 Due to invalid assertion in the video streaming code, the SPICE hypervisor could terminate unexpectedly when the assert was triggered. The following error message was returned in the log file: qemu sometimes crashes in spice-server with "rate_control->num_recent_enc_frames" assertion The invalid assertion has been fixed, and the hypervisor no longer crashes. Users of spice-server are advised to upgrade to these updated packages, which fix these bugs.

Commands:
2.7.9. Additional Resources The following sources of information provide additional resources regarding Libreswan and the ipsec daemon. 2.7.9.1. Installed Documentation ipsec(8) man page - Describes command options for ipsec . ipsec.conf(5) man page - Contains information on configuring ipsec . ipsec.secrets(5) man page - Describes the format of the ipsec.secrets file. ipsec_auto(8) man page - Describes the use of the auto command line client for manipulating Libreswan IPsec connections established using automatic exchanges of keys. ipsec_rsasigkey(8) man page - Describes the tool used to generate RSA signature keys. /usr/share/doc/libreswan- version /README.nss - Describes the commands for using raw RSA keys and certificates with the NSS crypto library used with the Libreswan pluto daemon.

Commands:
1.6. Updating a Red Hat Enterprise Linux High Availability Cluster Updating packages that make up the RHEL High Availability and Resilient Storage Add-Ons, either individually or as a whole, can be done in one of two general ways: Rolling Updates : Remove one node at a time from service, update its software, then integrate it back into the cluster. This allows the cluster to continue providing service and managing resources while each node is updated. Entire Cluster Update : Stop the entire cluster, apply updates to all nodes, then start the cluster back up. Warning It is critical that when performing software update procedures for Red Hat Enterprise LInux High Availability and Resilient Storage clusters, you ensure that any node that will undergo updates is not an active member of the cluster before those updates are initiated. For a full description of each of these methods and the procedures to follow for the updates, see Recommended Practices for Applying Software Updates to a RHEL High Availability or Resilient Storage Cluster .

Commands:
5.14. Using the Direct Interface It is possible to add and remove chains during runtime by using the --direct option with the firewall-cmd tool. A few examples are presented here. See the firewall-cmd(1) man page for more information. It is dangerous to use the direct interface if you are not very familiar with iptables as you could inadvertently cause a breach in the firewall. The direct interface mode is intended for services or applications to add specific firewall rules during runtime. The rules can be made permanent by adding the --permanent option using the firewall-cmd --permanent --direct command or by modifying /etc/firewalld/direct.xml . See man firewalld.direct(5) for information on the /etc/firewalld/direct.xml file. 5.14.1. Adding a Rule using the Direct Interface To add a rule to the " IN_public_allow " chain, enter the following command as root : Add the --permanent option to make the setting persistent. 5.14.2. Removing a Rule using the Direct Interface To remove a rule from the " IN_public_allow " chain, enter the following command as root : Add the --permanent option to make the setting persistent. 5.14.3. Listing Rules using the Direct Interface To list the rules in the " IN_public_allow " chain, enter the following command as root : Note that this command (the --get-rules option) only lists rules previously added using the --add-rule option. It does not list existing iptables rules added by other means.

Commands:
~]# firewall-cmd --direct --add-rule ipv4 filter IN_public_allow 0 -m tcp -p tcp --dport 666 -j ACCEPT
~]# firewall-cmd --direct --remove-rule ipv4 filter IN_public_allow 0 -m tcp -p tcp --dport 666 -j ACCEPT
~]# firewall-cmd --direct --get-rules ipv4 filter IN_public_allow
26.6. Parameters for Kickstart Installations The following parameters can be defined in a parameter file but do not work in a CMS configuration file. ks= URL References a kickstart file, which usually resides on the network for Linux installations on System z. Replace URL with the full path including the file name of the kickstart file. This parameter activates automatic installation with kickstart. Refer to Section 28.4, "Automating the Installation with Kickstart" and Section 32.11, "Starting a Kickstart Installation" for more details.] RUNKS= value Where value is defined as 1 if you want to run the loader automatically on the Linux console without having to log in over the network with SSH. To use RUNKS=1 , the console must either support full-screen or the cmdline option below should be used. The latter applies for the 3270 terminal under z/VM or the operating system messages console for LPAR. We recommend RUNKS=1 for fully automatic installations with kickstart. When RUNKS=1 is set, linuxrc automatically continues in case of parameter errors and does not interrupt unattended installations by prompting for user interaction. Leave out the parameter or specify RUNKS=0 otherwise. cmdline When cmdline is specified, output on line-mode terminals (such as 3270 under z/VM or operating system messages for LPAR) becomes readable, as the installer disables escape terminal sequences that are only applicable to UNIX-like consoles. This requires installation with a kickstart file that answers all questions, since the installer does not support interactive user input in cmdline mode. Ensure that your kickstart file contains all required parameters before you use either the RUNKS or cmdline options. Refer to Chapter 32, Kickstart Installations for details.

Commands:
Windows Integration Guide Red Hat Enterprise Linux 7 Integrating Linux systems with Active Directory environments Florian Delehaye Red Hat Customer Content Services fdelehay@redhat.com Marc Muehlfeld Red Hat Customer Content Services Filip Hanzelka Red Hat Customer Content Services Lucie Manaskova Red Hat Customer Content Services Aneta Steflova Petrova Red Hat Customer Content Services Tomas Capek Red Hat Customer Content Services Ella Deon Ballard Red Hat Customer Content Services

Commands:
2.5. Renaming a Server It is not possible to change the host name of an IdM server after it was set up. However, you can replace the server with a replica with a different name. Create a new replica of the server, with a CA and with the new required host name or IP address. This is described in Chapter 4, Installing and Uninstalling Identity Management Replicas . Stop the initial IdM server instance. Verify that all other replicas and clients are working as before. Uninstall the initial IdM server, as described in Section 2.4, "Uninstalling an IdM Server"

Commands:
ipactl stop
3.7.2.2. Working with Cipher Suites in GnuTLS GnuTLS is a communications library that implements the SSL and TLS protocols and related technologies. Note The GnuTLS installation on Red Hat Enterprise Linux offers optimal default configuration values that provide sufficient security for the majority of use cases. Unless you need to satisfy special security requirements, it is recommended to use the supplied defaults. Use the gnutls-cli command with the -l (or --list ) option to list all supported cipher suites: To narrow the list of cipher suites displayed by the -l option, pass one or more parameters (referred to as priority strings and keywords in GnuTLS documentation) to the --priority option. See the GnuTLS documentation at http://www.gnutls.org/manual/gnutls.html#Priority-Strings for a list of all available priority strings. For example, issue the following command to get a list of cipher suites that offer at least 128 bits of security: To obtain a list of cipher suites that satisfy the recommendations outlined in Section 3.7.1, "Choosing Algorithms to Enable" , use a command similar to the following: The above command limits the output to ciphers with at least 128 bits of security while giving preference to the stronger ones. It also forbids RSA key exchange and DSS authentication. Note that this is a rather strict configuration, and it might be necessary to relax the conditions in real-world scenarios to allow for a compatibility with a broader range of clients.

Commands:
~]USD gnutls-cli -l
~]USD gnutls-cli --priority SECURE128 -l
~]USD gnutls-cli --priority SECURE256:+SECURE128:-VERS-TLS-ALL:+VERS-TLS1.2:-RSA:-DHE-DSS:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC -l Cipher suites for SECURE256:+SECURE128:-VERS-TLS-ALL:+VERS-TLS1.2:-RSA:-DHE-DSS:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 0xc0, 0x2c TLS1.2 TLS_ECDHE_ECDSA_AES_256_CBC_SHA384 0xc0, 0x24 TLS1.2 TLS_ECDHE_ECDSA_AES_256_CBC_SHA1 0xc0, 0x0a SSL3.0 TLS_ECDHE_ECDSA_AES_128_GCM_SHA256 0xc0, 0x2b TLS1.2 TLS_ECDHE_ECDSA_AES_128_CBC_SHA256 0xc0, 0x23 TLS1.2 TLS_ECDHE_ECDSA_AES_128_CBC_SHA1 0xc0, 0x09 SSL3.0 TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30 TLS1.2 TLS_ECDHE_RSA_AES_256_CBC_SHA1 0xc0, 0x14 SSL3.0 TLS_ECDHE_RSA_AES_128_GCM_SHA256 0xc0, 0x2f TLS1.2 TLS_ECDHE_RSA_AES_128_CBC_SHA256 0xc0, 0x27 TLS1.2 TLS_ECDHE_RSA_AES_128_CBC_SHA1 0xc0, 0x13 SSL3.0 TLS_DHE_RSA_AES_256_CBC_SHA256 0x00, 0x6b TLS1.2 TLS_DHE_RSA_AES_256_CBC_SHA1 0x00, 0x39 SSL3.0 TLS_DHE_RSA_AES_128_GCM_SHA256 0x00, 0x9e TLS1.2 TLS_DHE_RSA_AES_128_CBC_SHA256 0x00, 0x67 TLS1.2 TLS_DHE_RSA_AES_128_CBC_SHA1 0x00, 0x33 SSL3.0 Certificate types: CTYPE-X.509 Protocols: VERS-TLS1.2 Compression: COMP-NULL Elliptic curves: CURVE-SECP384R1, CURVE-SECP521R1, CURVE-SECP256R1 PK-signatures: SIGN-RSA-SHA384, SIGN-ECDSA-SHA384, SIGN-RSA-SHA512, SIGN-ECDSA-SHA512, SIGN-RSA-SHA256, SIGN-DSA-SHA256, SIGN-ECDSA-SHA256
Chapter 55. Installing and running Oracle WebLogic Server Oracle WebLogic Server must be installed and running for you to apply many of the configurations that accommodate KIE Server. This section describes how to install and start Oracle WebLogic Server in a standalone Oracle WebLogic Server domain. For the most up-to-date and detailed installation instructions, see the Oracle WebLogic Server product page . Note If you are already running an instance of Oracle WebLogic Server that uses the same listener port as the one to be used by the server you are starting, you must stop the first server before starting the second server. Procedure Download Oracle WebLogic Server 12.2.1.3.0 or later from the Oracle WebLogic Server Downloads page . Sign in to the target system and verify that a certified JDK already exists on your system. The installer requires a certified JDK. For system requirements, see Oracle Fusion Middleware Systems Requirements and Specifications . To download the JDK, see the "About JDK Requirements for an Oracle Fusion Middleware Installation" section in Planning an Installation of Oracle Fusion Middleware . Navigate to the directory where you downloaded the installation program. To launch the installation program, run java -jar from the JDK directory on your system, as shown in the following examples: On UNIX-based operating systems, enter the following command: On Windows operating systems, enter the following command: Replace the JDK location in these examples with the actual JDK location on your system. Follow the installation wizard prompts to complete the installation. After the installation is complete, navigate to the WLS_HOME /user_projects/<DOMAIN_NAME> directory where <DOMAIN_NAME> is the domain directory. In the following example, mydomain is the domain directory: Enter one of the following commands to start Oracle WebLogic Server: On UNIX-based operating systems, enter the following command: On Windows operating systems, enter the following command: The startup script displays a series of messages, and finally displays a message similar to the following: Open the following URL in a web browser: In this command, replace the following place holders: Replace <HOST> with the system name or IP address of the host server. Replace <PORT> with the number of the port on which the host server is listening for requests (7001 by default). For example, to start the Administration Console for a local instance of Oracle WebLogic Server running on your system, enter the following URL in a web browser: If you started the Administration Console using secure socket layer (SSL), you must add s after http , as follows: https://<HOST>:<PORT>/console When the login page of the WebLogic Administration Console appears, enter your administrative credentials.

Commands:
/home/Oracle/jdk/jdk1.8.0_131/bin/java -jar fmw_12.2.1.3.0_wls_generic.jar
C:\Program Files\Java\jdk1.8.0_131\bin\java -jar fmw_12.2.1.3.0_wls_generic.jar
WLS\user_projects\mydomain
startWebLogic.sh
startWebLogic.cmd
<Dec 8, 2017 3:50:42 PM PDT> <Notice> <WebLogicServer> <000360> <Server started in RUNNING mode>
http://<HOST>:<PORT>/console
http://localhost:7001/console/
5.2. Routing with Camel in JBoss Data Grid Camel routing is a chain of processors that move messages in the background. The following is an example of a route that retrieves a value from the cache for a specific key. Routing can also be performed using XML configuration. The following example demonstrates camel-jbossdatagrid's local-camel-producer , a camel route that uses the camel-jbossdatagrid component to send data to an embedded cache created by the local-cache module. The provided example requires the cacheManager to be instantiated. The cacheManager bean for Spring XML can be instantiated as follows: The following demonstrates how to instantiate the cacheManager bean using Blueprint XML. Note Both the Spring XML and Blueprint XML examples use the configuration file infinispan.xml for configuration of the cache. This file must be present on the classpath. Report a bug

Commands:
from("direct:start") .setHeader(InfinispanConstants.OPERATION, constant(InfinispanConstants.GET)) .setHeader(InfinispanConstants.KEY, constant("123")) .to("infinispan://localhost?cacheContainer=#cacheContainer");
<camelContext id="local-producer" xmlns="http://camel.apache.org/schema/blueprint"> <route> <from uri="timer://local?fixedRate=true&amp;period=5000"/> <setHeader headerName="CamelInfinispanKey"> <constant>CamelTimerCounter</constant> </setHeader> <setHeader headerName="CamelInfinispanValue"> <constant>CamelTimerCounter</constant> </setHeader> <to uri="infinispan://foo?cacheContainer=#cacheManager"/> <to uri="log:local-put?showAll=true"/> </route> </camelContext>
<bean id="cacheManager" class="org.infinispan.manager.DefaultCacheManager" init-method="start" destroy-method="stop"> <constructor-arg type="java.lang.String" value="infinispan.xml"/> </bean>
<bean id="cacheManager" class="org.infinispan.manager.DefaultCacheManager" init-method="start" destroy-method="stop"> <argument value="infinispan.xml" /> </bean>
Chapter 2. Multicluster storage health To view the overall storage health status across all the clusters with OpenShift Data Foundation and manage its capacity, you must first enable the multicluster dashboard on the Hub cluster. 2.1. Enabling multicluster dashboard on Hub cluster You can enable the multicluster dashboard on the install screen either before or after installing ODF Multicluster Orchestrator with the console plugin. Prerequisites Ensure that you have installed OpenShift Container Platform version 4.17 and have administrator privileges. Ensure that you have installed Multicluster Orchestrator 4.17 operator with plugin for console enabled. Ensure that you have installed Red Hat Advanced Cluster Management for Kubernetes (RHACM) 2.11 from Operator Hub. For instructions on how to install, see Installing RHACM . Ensure you have enabled observability on RHACM. See Enabling observability guidelines . Procedure Create the configmap file named observability-metrics-custom-allowlist.yaml and add the name of the custom metric to the metrics_list.yaml parameter. You can use the following YAML to list the OpenShift Data Foundation metrics on Hub cluster. For details, see Adding custom metrics . Run the following command in the open-cluster-management-observability namespace: After observability-metrics-custom-allowlist yaml is created, RHACM will start collecting the listed OpenShift Data Foundation metrics from all the managed clusters. If you want to exclude specific managed clusters from collecting the observability data, add the following cluster label to your clusters: observability: disabled . To view the multicluster health, see chapter verifying multicluster storage dashboard . 2.2. Verifying multicluster storage health on hub cluster Prerequisites Ensure that you have enabled multicluster monitoring. For instructions, see chapter Enabling multicluster dashboard . Procedure In the OpenShift web console of Hub cluster, ensure All Clusters is selected. Navigate to Data Services and click Storage System . On the Overview tab, verify that there are green ticks in front of OpenShift Data Foundation and Systems . This indicates that the operator is running and all storage systems are available. In the Status card, Click OpenShift Data Foundation to view the operator status. Click Systems to view the storage system status. The Storage system capacity card shows the following details: Name of the storage system Cluster name Graphical representation of total and used capacity in percentage Actual values for total and used capacity in TiB

Commands:
kind: ConfigMap apiVersion: v1 metadata: name: observability-metrics-custom-allowlist Namespace: open-cluster-management-observability data: metrics_list.yaml: | names: - odf_system_health_status - odf_system_map - odf_system_raw_capacity_total_bytes - odf_system_raw_capacity_used_bytes matches: - __name__="csv_succeeded",exported_namespace="openshift-storage",name=~"odf-operator.*"
oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml
Chapter 13. Creating a Container with an Application This section describes how to create a docker-formatted container image from a locally built application. Making your application available as a container is advantageous when you wish to use orchestration for deployment. Alternatively, containerizing effectively solves conflicts of dependencies. Prerequisites Understanding of containers An application built locally from source Procedure Decide which base image to use. Note Red Hat recommends starting with a base image that uses Red Hat Enterprise Linux as its foundation. Refer to the Base Image in the Red Hat Container Catalog for further information. Create a workspace directory. Prepare your application as a directory containing all of the application's required files. Place this directory inside the workspace directory. Write a Dockerfile that describes the steps required to create the container. Refer to the Dockerfile Reference for information about how to create a Dockerfile that includes your content, sets default commands to run, and opens necessary ports and other features. This example shows a minimal Dockerfile that contains the my-program/ directory: FROM registry.access.redhat.com/rhel7 USER root ADD my-program/ . Place this Dockerfile into the workspace directory. Build a container image from the Dockerfile: During this step, note the container-id of the newly created container image. Add a tag to the image to identify the registry where you want the container image to be stored. See Getting Started with Containers - Tagging Images . Replace container-id with the value shown in the output of the step. Replace registry with the address of the registry you want to push the image to, port with the port of the registry (omit if not needed), and name with the name of the image. For example, if you are running a registry using the docker-distribution service on your local system with an image named myimage , the tag localhost:5000/myimage would enable that image to be pushed to the registry. Push the image to the registry so it can be pulled from that registry later. Replace the tag parts with the same values as the ones used in the step. To run your own Docker registry, see Getting Started with Containers - Working with Docker registries. Additional Resources OpenShift Container Platform - Develop: Images Red Hat Enterprise Linux Atomic Host - Recommended Practices for Container Development Dockerfile Reference Docker Documentation - Get Started, Part 2: Containers Red Hat Enterprise Linux Atomic Host - Getting Started with Containers Red Hat Container Catalog listing - Base Images

Commands:
FROM registry.access.redhat.com/rhel7 USER root ADD my-program/ .
docker build . (...) Successfully built container-id
docker tag container-id registry : port / name
docker push registry : port / name
8.60. grubby 8.60.1. RHBA-2013:1713 - grubby bug fix update Updated grubby packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The grubby packages provide grubby, a command-line tool for displaying and editing GRUB (GRand Unified Bootloader) configuration files. Bug Fixes BZ# 991197 Previously, the grub.conf file was not properly updated after a kernel update with the tboot bootloader. This was due to a bug in the grubby tool which caused it to improperly interpret the grub.conf stanzas that had tboot in them. This update enables grubby to read the HYPERVISOR and HYPERVISOR_ARGS parameters from the /etc/sysconfig/kernel file in order for tboot to perform as intended. BZ# 999908 Prior to this update, yum and anaconda upgrades could have failed with a kernel panic on the AMD64 and Intel 64 architectures due to the RAM disk image not being found. This only happened when tboot was installed, and the kernel "%post" or "%posttrans" scripts were run. This update adds the initramfs disk image to the grub entry, and kernel panic failures no longer occur in the described scenario. Users of grubby are advised to upgrade to these updated packages, which fix these bugs.

Commands: