mtpti5iD/redhat-docs_dataset huggingface dataset:
5.2. Configure CXF for a Web Service Data Source Prerequisites You must have configured a web service data source. Procedure 5.1. Configure CXF for a Web Service Data Source Specify the Web Service CXF ConfigFile Run the following command from within the Management CLI, specifying the CXF configuration file for the data source: Specify the Web Service CXF EndPointName Specify the port configuration by running the following command from within the Management CLI, using the port QName (local part only) for the value: Create/Edit the CXF Configuration File Open/create the EAP_HOME / MODE /configuration/ CONFIG-FILE .xml configuration file. Note CONFIG-NAME is the same as that specified above, with a default value of teiid . NAMESPACE is the namespace URI for the QName in your config file, which should match your WSDL/namespace setting on the data source or use the default of "http://teiid.org". The namespace may be set via the namespace datasource property. Typically that will only need done when also supplying the WSDL setting. The following is an example of a CXF file configuring timeouts: Note For web service data sources, CXF configuration is only applicable to non-binary calls.

Commands:
/subsystem=resource-adapters/resource-adapter=webservice/connection-definitions=wsDS/config-properties=ConfigFile:add(value= CONFIG-FILE .xml)
/subsystem=resource-adapters/resource-adapter=webservice/connection-definitions=wsDS/config-properties=EndPointName:add(value= CONFIG-NAME )
<http-conf:conduit name="{NAMESPACE} CONFIG-NAME .http-conduit"> </http-conf:conduit>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:http-conf="http://cxf.apache.org/transports/http/configuration" xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> <http-conf:conduit name="{NAMESPACE}CONFIG-NAME.http-conduit"> <http-conf:client ConnectionTimeout="120000" ReceiveTimeout="240000"/> </http-conf:conduit> </beans>
8.4.2.4. The Advanced Maryland Automatic Network Disk Archiver (AMANDA) AMANDA is a client/server based backup application produced by the University of Maryland. By having a client/server architecture, a single backup server (normally a fairly powerful system with a great deal of free space on fast disks and configured with the desired backup device) can back up many client systems, which need nothing more than the AMANDA client software. This approach to backups makes a great deal of sense, as it concentrates those resources needed for backups in one system, instead of requiring additional hardware for every system requiring backup services. AMANDA's design also serves to centralize the administration of backups, making the system administrator's life that much easier. The AMANDA server manages a pool of backup media and rotates usage through the pool in order to ensure that all backups are retained for the administrator-dictated retention period. All media is pre-formatted with data that allows AMANDA to detect whether the proper media is available or not. In addition, AMANDA can be interfaced with robotic media changing units, making it possible to completely automate backups. AMANDA can use either tar or dump to do the actual backups (although under Red Hat Enterprise Linux using tar is preferable, due to the issues with dump raised in Section 8.4.2.3, " dump / restore : Not Recommended for Mounted File Systems!" ). As such, AMANDA backups do not require AMANDA in order to restore files -- a decided plus. In operation, AMANDA is normally scheduled to run once a day during the data center's backup window. The AMANDA server connects to the client systems and directs the clients to produce estimated sizes of the backups to be done. Once all the estimates are available, the server constructs a schedule, automatically determining the order in which systems are to be backed up. Once the backups actually start, the data is sent over the network from the client to the server, where it is stored on a holding disk. Once a backup is complete, the server starts writing it out from the holding disk to the backup media. At the same time, other clients are sending their backups to the server for storage on the holding disk. This results in a continuous stream of data available for writing to the backup media. As backups are written to the backup media, they are deleted from the server's holding disk. Once all backups have been completed, the system administrator is emailed a report outlining the status of the backups, making review easy and fast. Should it be necessary to restore data, AMANDA contains a utility program that allows the operator to identify the file system, date, and file name(s). Once this is done, AMANDA identifies the correct backup media and then locates and restores the desired data. As stated earlier, AMANDA's design also makes it possible to restore data even without AMANDA's assistance, although identification of the correct media would be a slower, manual process. This section has only touched upon the most basic AMANDA concepts. To do more research on AMANDA, start with the amanda(8) man page.

Commands:
Chapter 298. Java Object Serialization DataFormat Available as of Camel version 2.12 Serialization is a Data Format which uses the standard Java Serialization mechanism to unmarshal a binary payload into Java objects or to marshal Java objects into a binary blob. For example the following uses Java serialization to unmarshal a binary file then send it as an ObjectMessage to ActiveMQ from("file://foo/bar"). unmarshal().serialization(). to("activemq:Some.Queue"); 298.1. Options The Java Object Serialization dataformat supports 1 options, which are listed below. Name Default Java Type Description contentTypeHeader false Boolean Whether the data format should set the Content-Type header with the type from the data format if the data format is capable of doing so. For example application/xml for data formats marshalling to XML, or application/json for data formats marshalling to JSon etc. 298.2. Dependencies This data format is provided in camel-core so no additional dependencies is needed.

Commands:
from("file://foo/bar"). unmarshal().serialization(). to("activemq:Some.Queue");
5.250. postgresql-jdbc 5.250.1. RHEA-2012:0991 - postgresql-jdbc enhancement update An updated postgresql-jdbc package that adds various enhancements is now available. PostgreSQL is an advanced Object-Relational database management system. The postgresql-jdbc package includes the .jar files needed for Java programs to access a PostgreSQL database. Enhancement BZ# 816731 This update enables support for the JDBC 4 and JDBC 4.1 extensions of the JDBC API specification. Among other advantages, these additions are necessary for proper functioning of the PostgreSQL JDBC driver under JDK version 6 and later (including JDK 7). This update also converts the driver from a GCJ build to a pure jar (noarch) build. Users of postgresql-jdbc are advised to upgrade to this updated package, which adds these enhancements.

Commands:
8.156. policycoreutils 8.156.1. RHBA-2013:1608 - policycoreutils bug fix and enhancement update Updated policycoreutils packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The policycoreutils packages contain the core utilities that are required for the basic operation of a Security-Enhanced Linux (SELinux) system and its policies. Bug Fixes BZ# 860506 Previously, several semanage command-line options did not work as expected. With this update, these options have been corrected and now work proprerly. BZ# 868218 With this update, the semanage man page has been updated to be consistent with information contained in the semanage help page. BZ# 886059 Due to a bug in the policycoreutils package, installation of the ipa-server-selinux package failed. This bug has been fixed and ipa-server-selinux can now be installed without complications. BZ# 913175 Prior to this update, the sandbox utility did not accept symbolic links specified in the /etc/sysconfig/sandbox file. Consequently, executing the "sandbox -M" command failed with a "No such file or directory" message. The underlying source code has been modified and symlinks can now be configured in /etc/sysconfig/sandbox without complications. BZ# 916727 Previously, the fixfiles script did not recognize a change in the regular expression describing the /sbin/ip6?tables-multi* files. Consequently, these files were labeled incorrectly after updating the system with the yum update command. With this update, fixfiles has been corrected to accept the change of regular expression. BZ# 918460 Prior to this update, after executing the "semanage boolean -m" command, a traceback was returned. This bug has been fixed and tracebacks are no longer displayed in the aforementioned scenario. BZ# 928320 , BZ# 947504 Previously, the semanage utility did not allow to set the "none" context on directories and files. Consequently, the following message was displayed when attempting to do so: /usr/sbin/semanage: Type none is invalid, must be a file or device type This bug has been fixed, and it is now possible to set the "none" context without complications. BZ# 967728 Prior to this update, the "-o" option of the audit2allow command overwrote the contents of the output file instead of just appending the new content. This bug has been fixed, and "audit2allow -o" now works as expected. BZ# 984484 After attempting to enable a SELinux boolean that did not exist, a brief error message was generated. This update modifies this message to be more informative. BZ# 998974 After attempting to permanently change a boolean that did not exist, an incorrect error message was generated. This message has been modified to provide correct information about the cause of the problem. Enhancement BZ# 916734 This update adds a possibility to exclude selected files when running the restorecon utility, which can significantly reduce execution times. Users of policycoreutils are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Chapter 62. Test scenarios Test scenarios in Red Hat Process Automation Manager enable you to validate the functionality of business rules and business rule data (for rules-based test scenarios) or of DMN models (for DMN-based test scenarios) before deploying them into a production environment. With a test scenario, you use data from your project to set given conditions and expected results based on one or more defined business rules. When you run the scenario, the expected results and actual results of the rule instance are compared. If the expected results match the actual results, the test is successful. If the expected results do not match the actual results, then the test fails. Red Hat Process Automation Manager includes both the new Test Scenarios designer and the former Test Scenarios (Legacy) designer. The default designer is the new test scenarios designer, which supports the testing of both rules and DMN models and provides an enhanced overall user experience with test scenarios. If required, you can continue to use the legacy test scenarios designer, which supports rule-based test scenarios only. Important The legacy test scenarios designer is deprecated from Red Hat Process Automation Manager version 7.3.0. It will be removed in a future Red Hat Process Automation Manager release. Use the new test scenarios designer instead. You can run the defined test scenarios in a number of ways, for example, you can run available test scenarios at the project level or inside a specific test scenario asset. Test scenarios are independent and cannot affect or modify other test scenarios. You can run test scenarios at any time during project development in Business Central. You do not have to compile or deploy your decision service to run test scenarios. You can import data objects from different packages to the same project package as the test scenario. Assets in the same package are imported by default. After you create the necessary data objects and the test scenario, you can use the Data Objects tab of the test scenarios designer to verify that all required data objects are listed or to import other existing data objects by adding a New item . Important Throughout the test scenarios documentation, all references to test scenarios and the test scenarios designer are for the new version, unless explicitly noted as the legacy version.

Commands:
36.3. Using Rescue Mode to Fix or Work Around Driver Problems A malfunctioning or missing driver can prevent a system from booting normally. Rescue mode provides an environment in which you can add, remove, or replace a driver even when the system fails to boot. Wherever possible, we recommend that you use the RPM package manager to remove malfunctioning drivers or to add updated or missing drivers. If you cannot remove a malfunctioning driver for some reason, you can instead blacklist the driver so that it does not load at boot time. Note that when you install a driver from a driver disc, the driver disc updates all initramfs images on the system to use this driver. If a problem with a driver prevents a system from booting, you cannot rely on booting the system from another initramfs image. 36.3.1. Using RPM to Add, Remove, or Replace a Driver In rescue mode, you can use RPM to install, remove, or update packages from the installed system, even though you did not boot the installed system. To remove a malfunctioning driver: Boot the system into rescue mode with the linux rescue command at the boot prompt, or the linux rescue dd command if you need to load a third-party driver from a driver disc. Follow the instructions in Section 36.1.2, "Booting into Rescue Mode" and do not choose to mount the installed system as read only. Change the root directory to /mnt/sysimage/ : Use the rpm -e command to remove the driver package. For example, to remove the kmod-foobar driver package, run: Exit the chroot environment: Installing a driver is a similar process, but the RPM package that contains the driver must be available on the system. Boot the system into rescue mode with the linux rescue command at the boot prompt, or the linux rescue dd command if you need to load a third-party driver from a driver disc. Follow the instructions in Section 36.1.2, "Booting into Rescue Mode" and do not choose to mount the installed system as read only. Make the RPM package that contains the driver available. For example, mount a CD or USB flash drive and copy the RPM package to a location of your choice under /mnt/sysimage/ , for example: /mnt/sysimage/root/drivers/ . Change the root directory to /mnt/sysimage/ : Use the rpm -ivh command to install the driver package. For example, to install the kmod-foobar driver package from /root/drivers/ , run: Note that /root/drivers/ in this chroot environment is /mnt/sysimage/root/drivers/ in the original rescue environment. When you have finished removing and installing drivers, reboot the system.

Commands:
chroot /mnt/sysimage/
-e kmod-foobar
exit
chroot /mnt/sysimage/
-\u00adivh /root/drivers/kmod-foobar-\u00ad1.2.0\u00ad4.17.el6.i686
Chapter 6. Managing usability analytics and data collection from automation controller You can change how you participate in usability analytics and data collection from automation controller by opting out or changing your settings in the automation controller user interface. 6.1. Usability analytics and data collection Usability data collection is included with automation controller to collect data to better understand how automation controller users specifically interact with automation controller, to help enhance future releases, and to continue streamlining your user experience. Only users installing a trial of automation controller or a fresh installation of automation controller are opted-in for this data collection. Additional resources For more information, see the Red Hat privacy policy . 6.1.1. Controlling data collection from automation controller You can control how automation controller collects data by setting your participation level in the User Interface tab in the Settings menu. Procedure Log in to your automation controller. Navigate to Settings and select User Interface settings from the User Interface option. Select the desired level of data collection from the User Analytics Tracking State drop-down list: Off : Prevents any data collection. Anonymous : Enables data collection without your specific user data. Detailed : Enables data collection including your specific user data. Click Save to apply the settings or Cancel to discard the changes.

Commands:
14.2. Configuring OpenSSH 14.2.1. Configuration Files There are two different sets of configuration files: those for client programs (that is, ssh , scp , and sftp ), and those for the server (the sshd daemon). System-wide SSH configuration information is stored in the /etc/ssh/ directory as described in Table 14.1, "System-wide configuration files" . User-specific SSH configuration information is stored in ~/.ssh/ within the user's home directory as described in Table 14.2, "User-specific configuration files" . Table 14.1. System-wide configuration files File Description /etc/ssh/moduli Contains Diffie-Hellman groups used for the Diffie-Hellman key exchange which is critical for constructing a secure transport layer. When keys are exchanged at the beginning of an SSH session, a shared, secret value is created which cannot be determined by either party alone. This value is then used to provide host authentication. /etc/ssh/ssh_config The default SSH client configuration file. Note that it is overridden by ~/.ssh/config if it exists. /etc/ssh/sshd_config The configuration file for the sshd daemon. /etc/ssh/ssh_host_dsa_key The DSA private key used by the sshd daemon. /etc/ssh/ssh_host_dsa_key.pub The DSA public key used by the sshd daemon. /etc/ssh/ssh_host_key The RSA private key used by the sshd daemon for version 1 of the SSH protocol. /etc/ssh/ssh_host_key.pub The RSA public key used by the sshd daemon for version 1 of the SSH protocol. /etc/ssh/ssh_host_rsa_key The RSA private key used by the sshd daemon for version 2 of the SSH protocol. /etc/ssh/ssh_host_rsa_key.pub The RSA public key used by the sshd daemon for version 2 of the SSH protocol. /etc/pam.d/sshd The PAM configuration file for the sshd daemon. /etc/sysconfig/sshd Configuration file for the sshd service. Table 14.2. User-specific configuration files File Description ~/.ssh/authorized_keys Holds a list of authorized public keys for servers. When the client connects to a server, the server authenticates the client by checking its signed public key stored within this file. ~/.ssh/id_dsa Contains the DSA private key of the user. ~/.ssh/id_dsa.pub The DSA public key of the user. ~/.ssh/id_rsa The RSA private key used by ssh for version 2 of the SSH protocol. ~/.ssh/id_rsa.pub The RSA public key used by ssh for version 2 of the SSH protocol. ~/.ssh/identity The RSA private key used by ssh for version 1 of the SSH protocol. ~/.ssh/identity.pub The RSA public key used by ssh for version 1 of the SSH protocol. ~/.ssh/known_hosts Contains DSA host keys of SSH servers accessed by the user. This file is very important for ensuring that the SSH client is connecting the correct SSH server. For information concerning various directives that can be used in the SSH configuration files, see the ssh_config (5) and sshd_config (5) manual pages.

Commands:
Chapter 4. Configuring traffic ingress 4.1. Configuring SSL/TLS and Routes Support for OpenShift Container Platform Edge-Termination Routes has been added by way of a new managed component, tls . This separates the route component from SSL/TLS and allows users to configure both separately. EXTERNAL_TLS_TERMINATION: true is the opinionated setting. Managed tls means that the default cluster wildcard certificate is used. Unmanaged tls means that the user provided key and certificate pair is be injected into the Route . The ssl.cert and ssl.key are now moved to a separate, persistent secret, which ensures that the key and certificate pair are not re-generated upon every reconcile. The key and certificate pair are now formatted as edge routes and mounted to the same directory in the Quay container. Multiple permutations are possible when configuring SSL/TLS and Routes, but the following rules apply: If SSL/TLS is managed , then your route must also be managed If SSL/TLS is unmanaged then you must supply certificates, either with the config tool or directly in the config bundle The following table describes the valid options: Table 4.1. Valid configuration options for TLS and routes Option Route TLS Certs provided Result My own load balancer handles TLS Managed Managed No Edge Route with default wildcard cert Red Hat Quay handles TLS Managed Unmanaged Yes Passthrough route with certs mounted inside the pod Red Hat Quay handles TLS Unmanaged Unmanaged Yes Certificates are set inside the quay pod but route must be created manually Note Red Hat Quay 3.7 does not support builders when TLS is managed by the Operator. 4.1.1. Creating the config bundle secret with the SSL/TLS cert and key pair Use the following procedure to create a config bundle secret that includes your own SSL/TLS certificate and key pair. Procedure Enter the following command to create config bundle secret that includes your own SSL/TLS certificate and key pair: USD oc create secret generic --from-file config.yaml=./config.yaml --from-file ssl.cert=./ssl.cert --from-file ssl.key=./ssl.key config-bundle-secret

Commands:
oc create secret generic --from-file config.yaml=./config.yaml --from-file ssl.cert=./ssl.cert --from-file ssl.key=./ssl.key config-bundle-secret