mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 147. Hessian DataFormat (deprecated) Available as of Camel version 2.17 Hessian is Data Format for marshalling and unmarshalling messages using Caucho's Hessian format. If you want to use Hessian Data Format from Maven, add the following dependency to your pom.xml : <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-hessian</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency> 147.1. Options The Hessian dataformat supports 4 options, which are listed below. Name Default Java Type Description whitelistEnabled true Boolean Define if Whitelist feature is enabled or not allowedUnmarshallObjects String Define the allowed objects to be unmarshalled deniedUnmarshallObjects String Define the denied objects to be unmarshalled 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. 147.2. Spring Boot Auto-Configuration The component supports 5 options, which are listed below. Name Description Default Type camel.dataformat.hessian.allowed-unmarshall-objects Define the allowed objects to be unmarshalled String camel.dataformat.hessian.content-type-header 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. false Boolean camel.dataformat.hessian.denied-unmarshall-objects Define the denied objects to be unmarshalled String camel.dataformat.hessian.enabled Enable hessian dataformat true Boolean camel.dataformat.hessian.whitelist-enabled Define if Whitelist feature is enabled or not true Boolean ND 147.3. Using the Hessian data format in Java DSL from("direct:in") .marshal().hessian(); 147.4. Using the Hessian data format in Spring DSL <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring"> <route> <from uri="direct:in"/> <marshal ref="hessian"/> </route> </camelContext>

Commands:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-hessian</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
from("direct:in") .marshal().hessian();
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring"> <route> <from uri="direct:in"/> <marshal ref="hessian"/> </route> </camelContext>
18.2.2. Enabling and Disabling the Firewall Select one of the following options for the firewall: Disabled - Disabling the firewall provides complete access to your system and does no security checking. This should only be selected if you are running on a trusted network (not the Internet) or need to configure a custom firewall using the iptables command line tool. Warning Firewall configurations and any customized firewall rules are stored in the /etc/sysconfig/iptables file. If you choose Disabled and click OK , these configurations and firewall rules will be lost. Enabled - This option configures the system to reject incoming connections that are not in response to outbound requests, such as DNS replies or DHCP requests. If access to services running on this machine is needed, you can choose to allow specific services through the firewall. If you are connecting your system to the Internet, but do not plan to run a server, this is the safest choice.

Commands:
Chapter 11. Auditing listening endpoints Red Hat Advanced Cluster Security for Kubernetes (RHACS) provides the ability to audit the processes that are listening on ports in your secured clusters and filter this data by deployment, namespace, or cluster. You can view information about processes and ports that they are listening on by using the following methods: In the RHACS web portal, go to Network Listening Endpoints . Connect to the ListeningEndpointsService object in the API. For more information on the API, go to Help API reference in the RHACS web portal. The page provides a list of processes by deployment, with the following information displayed for each process on the list: Deployment name Cluster Namespace Count, or the number of processes listening on the ports in the deployment You can further filter the information displayed on the page by using the filter field and entering individual deployments, namespaces, and clusters. Click the expand icon at the top of the list to expand all sections for all deployments listed, or click the expand icon on a single deployment line to view additional information about that deployment. The following information is provided: Exec file path: Location of the process PID: System ID of the process Port: Port on which the process is listening Protocol: Protocol in use by the process Pod ID: Name of the pod where the process is contained Container name: Name of the container in which the process that is listening is located Clicking on a deployment name brings you to the Risk page in the RHACS web portal, where you can view information about the deployment, including risk indicators such as policy violations and additional deployment details.

Commands:
5.4. Device Assignment and SR-IOV The following diagram demonstrates the involvement of the kernel in the Device Assignment and SR-IOV architectures. Figure 5.2. Device assignment and SR-IOV Device assignment presents the entire device to the guest. SR-IOV needs support in drivers and hardware, including the NIC and the system board and allows multiple virtual devices to be created and passed into different guests. A vendor-specific driver is required in the guest, however, SR-IOV offers the lowest latency of any network option.

Commands:
1.2. Download JBoss Data Virtualization Installer The JBoss Data Virtualization installer archive is available on the Red Hat Customer portal at https://access.redhat.com/ . Prerequisites Set up an account on the Red Hat Customer Portal at https://access.redhat.com/ . Ensure your Red Hat subscriptions are up to date. Review the supported configurations and ensure your system is supportable. Ensure that you have administration privileges for the installation directory. Ensure that JAVA_HOME and PATH have been set in the Environment properties for shortcuts to work on Microsoft Windows servers. A Java 7 or 8 JDK is required. Note If you intend to use Red Hat SSO, you must have at least Java 7. Java 7 is also a minimum requirement for the Impala, Hive and HBase data sources. Java 1.7 or greater is also required if you wish to use the file translator or Data Services Builder. Also note that if you intend to access Red Hat JBoss Data Grid 7.1, Red Hat JDV must be running JDK 1.8. Optional: Red Hat JBoss Enterprise Application Platform 6.4.x if you do not want to use the version of Red Hat JBoss EAP that comes bundled with the Data Virtualization installer. Procedure 1.1. Download JBoss Data Virtualization Installer Go to https://access.redhat.com/ . Click Log in and enter your Red Hat Login and Password to access the Customer Portal . Click Downloads -> Red Hat JBoss Data Virtualization . Click Download to the Red Hat JBoss Data Virtualization [Version] Installer option. Save the file.

Commands:
5.4.2. Beware of Syntax Errors The NFS server determines which file systems to export and which hosts to export these directories to via the /etc/exports file. Be careful not to add extraneous spaces when editing this file. For instance, the following line in the /etc/exports file shares the directory /tmp/nfs/ to the host bob.example.com with read/write permissions. This line in the /etc/exports file, on the other hand, shares the same directory to the host bob.example.com with read-only permissions and shares it to the world with read/write permissions due to a single space character after the hostname. It is good practice to check any configured NFS shares by using the showmount command to verify what is being shared:

Commands:
/tmp/nfs/ bob.example.com(rw)
/tmp/nfs/ bob.example.com (rw)
showmount -e <hostname>
5.2.6. /proc/devices This file displays the various character and block devices currently configured (not including devices whose modules are not loaded). Below is a sample output from this file: The output from /proc/devices includes the major number and name of the device, and is broken into two major sections: Character devices and Block devices . Character devices are similar to block devices , except for two basic differences: Character devices do not require buffering. Block devices have a buffer available, allowing them to order requests before addressing them. This is important for devices designed to store information - such as hard drives - because the ability to order the information before writing it to the device allows it to be placed in a more efficient order. Character devices send data with no preconfigured size. Block devices can send and receive information in blocks of a size configured per device. For more information about devices refer to the following installed documentation:

Commands:
Character devices: 1 mem 4 /dev/vc/0 4 tty 4 ttyS 5 /dev/tty 5 /dev/console 5 /dev/ptmx 7 vcs 10 misc 13 input 29 fb 36 netlink 128 ptm 136 pts 180 usb Block devices: 1 ramdisk 3 ide0 9 md 22 ide1 253 device-mapper 254 mdp
/usr/share/doc/kernel-doc- <version> /Documentation/devices.txt
10.4. Investigating the Incident Investigating a computer breach is like investigating a crime scene. Detectives collect evidence, note any strange clues, and take inventory on loss and damage. An analysis of a computer compromise can either be done as the attack is happening or post-mortem. Although it is unwise to trust any system log files on an exploited system, there are other forensic utilities to aid in the analysis. The purpose and features of these tools vary, but they commonly create bit-image copies of media, correlate events and processes, show low level file system information, and recover deleted files whenever possible. It is also a good idea to record of all of the investigatory actions executed on a compromised system by using the script command, as in the following example: Replace <file-name> with file name for the script log. Always save the log file on media other than the hard drive of the compromised system - a floppy disk or CD-ROM works particularly well for this purpose. By recording all your actions, an audit trail is created that may prove valuable if the attacker is ever caught. 10.4.1. Collecting an Evidential Image Creating a bit-image copy of media is a feasible first step. If performing data forensic work, it is a requirement. It is recommended to make two copies: one for analysis and investigation, and a second to be stored along with the original for evidence in any legal proceedings. You can use the dd command that is part of the coreutils package in Red Hat Enterprise Linux to create a monolithic image of an exploited system as evidence in an investigation or for comparison with trusted images. Suppose there is a single hard drive from a system you want to image. Attach that drive as a slave to the system and then use dd to create the image file, such as the following: This command creates a single file named image1 using a 1k block size for speed. The conv=noerror,sync options force dd to continue reading and dumping data even if bad sectors are encountered on the suspect drive. It is now possible to study the resulting image file or even attempt to recover deleted files.

Commands:
script -q <file-name>
dd if=/dev/hdd bs=1k conv=noerror,sync of=/home/evidence/image1
8.119. ModemManager 8.119.1. RHBA-2013:1672 - ModemManager bug fix update Updated ModemManager packages that fix one bug are now available for Red Hat Enterprise Linux 6. The ModemManager packages provide a consistent application programming interface (API) to operate a wide variety of modems, including mobile broadband (3G) devices. Bug Fix BZ# 883079 Previously, some broadband devices were not covered by the "udev" rules in the /lib/udev/rules.d/77-mm-*.rules files. As a consequence, the broadband connection was either not established at all, or failed after communicating a few packages. Additional "udev" rules have been included to ensure that ModemManager uses the correct serial port. As a result, more broadband devices, such as ZTE, LG, and Sierra Wireless modems, are now supported. Users of ModemManager are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 1. Introduction to Federal Information Processing Standards (FIPS) The Federal Information Processing Standards (FIPS) provides guidelines and requirements for improving security and interoperability across computer systems and networks. The FIPS 140-2 and 140-3 series apply to cryptographic modules at both the hardware and software levels. The National Institute of Standards and Technology in the United States implements a cryptographic module validation program with searchable lists of both in-process and approved cryptographic modules. Red Hat Enterprise Linux (RHEL) brings an integrated framework to enable FIPS 140 compliance system-wide. When operating under FIPS mode, software packages using cryptographic libraries are self-configured according to the global policy. Most of the packages provide a way to change the default alignment behavior for compatibility or other needs. Red Hat build of OpenJDK 11 is a FIPS policy-aware package. Additional resources For more information on how to install RHEL with FIPS mode enabled, see Installing a RHEL 8 system with FIPS mode enabled . For more information on how to enable FIPS mode after installing RHEL, see Switching the system to FIPS mode . For more information on how to run Red Hat build of OpenJDK in FIPS mode on RHEL. See Running OpenJDK in FIPS mode on RHEL . For more information on Red Hat compliance with Government Standards, see Government Standards .

Commands:
7.16. biosdevname 7.16.1. RHBA-2013:0434 - biosdevname bug fix and enhancement update Updated biosdevname packages that fix multiple bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The biosdevname packages contain a udev helper utility which provides an optional convention for naming network interfaces; it assigns names to network interfaces based on their physical location. The utility is disabled by default, except for on a limited set of Dell PowerEdge, C Series and Precision Workstation systems. Note The biosdevname packages have been upgraded to upstream version 0.4.1, which provides a number of bug fixes and enhancements over the version. (BZ#825142) Bug Fixes BZ#751373 The biosdevname utility ignored the SMBIOS version check for PCI network adapters. Consequently, PCI network adapter interfaces were renamed according to PCI slot and port numbers on systems with unsupported SMBIOS versions. With this update, the new biosdevname utility ensures that if the SMBIOS version is not supported, PCI network adapter interfaces are not renamed. As a result, PCI network adapters are named with the kernel default name in the scenario described. BZ#804754 When using Single Root I/O Virtualization (SR-IOV) with embedded network interface devices, the biosdevname utility did not check the System Management BIOS (SMBIOS) type of the physical function for corresponding virtual functions. Consequently, biosdevname did not find SMBIOS type 41 structure for the device virtual functions and did not suggest interface names for these onboard network interfaces. With this update, biosdevname now looks up the SMBIOS type 41 structure for the device virtual functions in the corresponding physical function table. As a result, onboard network devices with virtual network interfaces are now renamed according to the biosdevname naming scheme. BZ#815724 The biosdevname utility did not handle PCI cards with multiple ports. Consequently, only the network interface of the first port of these cards was renamed according to the biosdevname naming scheme. An upstream patch has been applied and biosdevname now handles PCI cards with multiple ports. As a result, all ports of multiple port PCI cards are now renamed according to the biosdevname naming scheme. All users of biosdevname are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 4. Developer previews This section describes the developer preview features introduced in Red Hat OpenShift Data Foundation 4.17. Important Developer preview feature is subject to Developer preview support limitations. Developer preview releases are not intended to be run in production environments. The clusters deployed with the developer preview features are considered to be development clusters and are not supported through the Red Hat Customer Portal case management system. If you need assistance with developer preview features, reach out to the ocs-devpreview@redhat.com mailing list and a member of the Red Hat Development Team will assist you as quickly as possible based on availability and work schedules. 4.1. Multi-Volume Consistency for Backup - CephFS Provides crash consistent multi-volume consistency groups for backup solutions to be used by applications that are deployed over multiple volumes. This provides support for OpenShift Virtualization and helps to better support applications. For an example, see the knowledgebase article, Enabling Consistency Groups for CephFS Workloads . 4.2. Efficient SELinux volume relabelling for all access modes OpenShift Data Foundation now supports efficient SELinux volume relabelling for all access modes. The context set for SELinux in the PodSpec or container is used by the driver to mount the volume directly with the correct SELinux labels. This feature helps to eliminate the need to recursively relabel the volume and pod startup can be significantly faster. For more information, see the knowledgebase article, SELinux relabeling using mount options (RWX) . 4.3. CephFS based Persistent Volumes to be shared with concurrent IOs across clusters OpenShift Data Foundation supports Active-Active High Availability between the multi-instances of the application. Also, supports shared volume for multi-instance applications that are running on different clusters. Ceph-FS based RWX volume is simultaneously mounted on different Pods in different clusters with concurrent IOs from multiple instances of the application. For more information, see the knowledgebase article Enabling Consistency Groups for CephFS Workloads . 4.4. Access buckets with DNS subdomain style (Virtual host style) for RGW Virtual-host-style S3 bucket addressing can be configured for OpenShift Data Foundation internal mode object stores and ObjectBucketClaims. The client access is secured with TLS using OpenShift builtin platform certificates.

Commands:
5.98. grub 5.98.1. RHBA-2012:0892 - grub bug fix update Updated grub packages that fix one bug are now available for Red Hat Enterprise Linux 6. The GRUB utility is responsible for booting the operating system kernel. Bug Fix BZ# 670266 Due to an error in the underlying source code, versions of GRUB sometimes failed to boot in Unified Extensible Firmware Interface (UEFI) mode when booting from the network on systems with multiple Pre-boot Execution Environment (PXE) network interface cards (NICs). This update ensures that GRUB attempts to identify and use an active interface that has already successfully acquired an address via Dynamic Host Configuration Protocol (DHCP) instead of using the one suggested by the system. As a result, booting from the network in UEFI mode now works as expected on systems with multiple NICs. All users of GRUB are advised to upgrade to these updated packages, which fix this bug.

Commands:
4.5. Creating Snapshot Volumes Use the -s argument of the lvcreate command to create a snapshot volume. A snapshot volume is writeable. LVM snapshots are not cluster-aware, so they require exclusive access to a volume. For information on activating logical volumes on individual nodes in a cluster, see Section 4.8, "Activating Logical Volumes on Individual Nodes in a Cluster" . The following command creates a snapshot logical volume that is 100 megabytes in size named /dev/vg00/snap . This creates a snapshot of the origin logical volume named /dev/vg00/lvol1 . If the original logical volume contains a file system, you can mount the snapshot logical volume on an arbitrary directory in order to access the contents of the file system to run a backup while the original file system continues to get updated. After you create a snapshot logical volume, specifying the origin volume on the lvdisplay command yields output that includes a a list of all snapshot logical volumes and their status (active or inactive). The following example shows the status of the logical volume /dev/new_vg/lvol0 , for which a snapshot volume /dev/new_vg/newvgsnap has been created. The lvs command, by default, displays the origin volume and the current percentage of the snapshot volume being used for each snapshot volume. The following example shows the default output for the lvs command for a system that includes the logical volume /dev/new_vg/lvol0 , for which a snapshot volume /dev/new_vg/newvgsnap has been created. Note Because the snapshot increases in size as the origin volume changes, it is important to monitor the percentage of the snapshot volume regularly with the lvs command to be sure it does not fill. A snapshot that is 100% full is lost completely, as a write to unchanged parts of the origin would be unable to succeed without corrupting the snapshot.

Commands:
lvcreate --size 100M --snapshot --name snap /dev/vg00/lvol1
lvdisplay /dev/new_vg/lvol0 --- Logical volume --- LV Name /dev/new_vg/lvol0 VG Name new_vg LV UUID LBy1Tz-sr23-OjsI-LT03-nHLC-y8XW-EhCl78 LV Write Access read/write LV snapshot status source of /dev/new_vg/newvgsnap1 [active] LV Status available # open 0 LV Size 52.00 MB Current LE 13 Segments 1 Allocation inherit Read ahead sectors 0 Block device 253:2
lvs LV VG Attr LSize Origin Snap% Move Log Copy% lvol0 new_vg owi-a- 52.00M newvgsnap1 new_vg swi-a- 8.00M lvol0 0.20