mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 153. iCal DataFormat Available as of Camel version 2.12 The ICal dataformat is used for working with iCalendar messages. A typical iCalendar message looks like: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Events Calendar//iCal4j 1.0//EN CALSCALE:GREGORIAN BEGIN:VEVENT DTSTAMP:20130324T180000Z DTSTART:20130401T170000 DTEND:20130401T210000 SUMMARY:Progress Meeting TZID:America/New_York UID:00000000 ATTENDEE;ROLE=REQ-PARTICIPANT;CN=Developer 1:mailto:dev1@mycompany.com ATTENDEE;ROLE=OPT-PARTICIPANT;CN=Developer 2:mailto:dev2@mycompany.com END:VEVENT END:VCALENDAR 153.1. Options The iCal dataformat supports 2 options, which are listed below. Name Default Java Type Description validating false Boolean Whether to validate. 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. 153.2. Spring Boot Auto-Configuration The component supports 3 options, which are listed below. Name Description Default Type camel.dataformat.ical.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.ical.enabled Enable ical dataformat true Boolean camel.dataformat.ical.validating Whether to validate. false Boolean ND 153.3. Basic Usage To unmarshal and marshal the message shown above, your route will look like the following: from("direct:ical-unmarshal") .unmarshal("ical") .to("mock:unmarshaled") .marshal("ical") .to("mock:marshaled"); Maven users will need to add the following dependency to their pom.xml for this component: <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-ical</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency> 153.4. See Also Configuring Camel Component Endpoint Getting Started

Commands:
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Events Calendar//iCal4j 1.0//EN CALSCALE:GREGORIAN BEGIN:VEVENT DTSTAMP:20130324T180000Z DTSTART:20130401T170000 DTEND:20130401T210000 SUMMARY:Progress Meeting TZID:America/New_York UID:00000000 ATTENDEE;ROLE=REQ-PARTICIPANT;CN=Developer 1:mailto:dev1@mycompany.com ATTENDEE;ROLE=OPT-PARTICIPANT;CN=Developer 2:mailto:dev2@mycompany.com END:VEVENT END:VCALENDAR
from("direct:ical-unmarshal") .unmarshal("ical") .to("mock:unmarshaled") .marshal("ical") .to("mock:marshaled");
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-ical</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
4.125. less 4.125.1. RHBA-2011:1575 - less bug fix and enhancement update An updated less package that fixes two bugs and adds one enhancement is now available for Red Hat Enterprise Linux 6. The less package contains a text file browser that is similar to the more browser, but with more features ("less is more"). The less text file browser allows users to move backwards in the file as well as forwards. Because the less utility does not need to read the entire input file before it starts, it starts up faster than text editors. Bug Fixes BZ# 644858 Prior to this update, the online help for the less utility contained incorrect descriptions for several options. With this update, the descriptions have been corrected and the online help describes now all options correctly. BZ# 729025 Prior to this update, a debuginfo file for a binary was missing from the less-debuginfo package. As a result, the crash analysis via the Automatic Bug-Reporting Tool (ABRT) did not work as expected and debugging via GNU Debugger (GDB) could fail. This update modifies the spec file so that the crash analysis via ABRT and debugging via GDB work as expected. Enhancement BZ# 718498 Prior to this update, the less utility could not view its compressed .xz files.This update adds support for .xz files to lesspipe.sh. All users of the less text file browser are advised to upgrade to this updated package, which fixes these bugs and adds this enhancement.

Commands:
25.2.2.2. FCP LUNs That Are Not Part of the Root File System FCP LUNs that are not part of the root file system, such as data disks, are persistently configured in the file /etc/zfcp.conf . It contains one FCP LUN per line. Each line contains the device bus ID of the FCP adapter, the WWPN as 16 digit hexadecimal number prefixed with 0x , and the FCP LUN prefixed with 0x and padded with zeroes to the right to have 16 hexadecimal digits, separated by a space or tab. Entries in /etc/zfcp.conf are activated and configured by udev when an FCP adapter is added to the system. At boot time, all FCP adapters visible to the system are added and trigger udev . Example content of /etc/zfcp.conf: Modifications of /etc/zfcp.conf only become effective after a reboot of the system or after the dynamic addition of a new FCP channel by changing the system's I/O configuration (for example, a channel is attached under z/VM). Alternatively, you can trigger the activation of a new entry in /etc/zfcp.conf for an FCP adapter which was previously not active, by executing the following commands: Use the cio_ignore command to remove the FCP adapter from the list of ignored devices and make it visible to Linux: Replace DeviceNumber with the device number of the FCP adapter. For example: To trigger the uevent that activates the change, issue: For example:

Commands:
0.0.fc00 0x5105074308c212e9 0x401040a000000000 0.0.fc00 0x5105074308c212e9 0x401040a100000000 0.0.fc00 0x5105074308c212e9 0x401040a300000000 0.0.fcd0 0x5105074308c2aee9 0x401040a000000000 0.0.fcd0 0x5105074308c2aee9 0x401040a100000000 0.0.fcd0 0x5105074308c2aee9 0x401040a300000000
cio_ignore -r DeviceNumber
cio_ignore -r fcfc
echo add > /sys/bus/ccw/devices/ Device.Bus.ID /uevent
echo add > /sys/bus/ccw/devices/0.0.fcfc/uevent
Chapter 3. Configuring the .kantra directory Starting from Migration Toolkit for Applications (MTA) 7.2.0, you can perform an application analysis in the containerless mode. Before running the analysis, you must create and configure the .kantra directory. Prerequisites You installed the MTA extension version 7.2.0 or later on your system. For more information, see Installing the MTA extension for Visual Studio Code . You installed the MTA distribution version 7.2.0 or later. For more information, see Installing the CLI .zip file . Procedure Create a directory named .kantra in your USDHOME directory: USD mkdir ~/.kantra/ Move all the files from the extracted MTA directory , except the mta-cli binary, into the ~/.kantra directory. USD mv !(mta-cli) ~/.kantra/ Verification Verify that you created and configured the .kantra directory correctly by running the application analysis. For more information, see Analyzing your projects with the MTA extension .

Commands:
mkdir ~/.kantra/
mv !(mta-cli) ~/.kantra/
3.2. Virtual Database Deployment A virtual database (VDB) must be deployed before it can be accessed by client applications. A VDB can be deployed by the following means: File Deployment File deployment is recommended for quick deployment during development, when the server is running locally on the developer's workstation. Management Console Deployment via the web-based Management Console is recommended for a simple way of deploying a VDB to a remote server. Management Command Line Interface Deployment via the EAP Management Command Line Interface (CLI) is another simple option for deployment. AdminShell Deployment via the AdminShell is recommended for more advanced deployments such as when you want to automate the deployment of artifacts in your environment. Admin API Deployment via the Admin API is recommended for more advanced deployments such as when you want to deploy a VDB from within other applications. Note A VDB can also be deployed within the Teiid Designer. See the Red Hat JBoss Data Virtualization User Guide . Important Removal of a VDB cleans up all of its resources automatically; however, existing sessions will not be terminated automatically. Warning When deploying a VDB, overwriting a VDB with one of the same name will terminate all connections to the old VDB unless VDB versioning is used. Red Hat recommends the use of VDB versioning on production systems. Warning You can locally name VDB artifacts as you wish, but the runtime names of your deployed VDB artifacts must have an extension of *.vdb for a zip file or *-vdb.xml for an xml file. Failure to name your file correctly will result in a deployment failure as the Teiid subsystem will not know how to handle it.

Commands:
4.109. java-1.6.0-sun 4.109.1. RHSA-2012:0734 - Critical: java-1.6.0-sun security update Updated java-1.6.0-sun packages that fix several security issues are now available for Red Hat Enterprise Linux 5 and 6 Supplementary. The Red Hat Security Response Team has rated this update as having critical security impact. 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. The Sun 1.6.0 Java release includes the Sun Java 6 Runtime Environment and the Sun Java 6 Software Development Kit. Security Fixes CVE-2012-0551 , CVE-2012-1711 , CVE-2012-1713 , CVE-2012-1716 , CVE-2012-1717 , CVE-2012-1718 , CVE-2012-1719 , CVE-2012-1721 , CVE-2012-1722 , CVE-2012-1723 , CVE-2012-1724 , CVE-2012-1725 This update fixes several vulnerabilities in the Sun Java 6 Runtime Environment and the Sun Java 6 Software Development Kit. Further information about these flaws can be found on the Oracle Java SE Critical Patch page. All users of java-1.6.0-sun are advised to upgrade to these updated packages, which provide JDK and JRE 6 Update 33 and resolve these issues. All running instances of Sun Java must be restarted for the update to take effect. 4.109.2. RHSA-2012:0139 - Critical: java-1.6.0-sun security update Updated java-1.6.0-sun packages that fix several security issues are now available for Red Hat Enterprise Linux 4 Extras, and Red Hat Enterprise Linux 5 and 6 Supplementary. The Red Hat Security Response Team has rated this update as having critical security impact. 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. The Sun 1.6.0 Java release includes the Sun Java 6 Runtime Environment and the Sun Java 6 Software Development Kit. Security Fixes CVE-2011-3563 , CVE-2011-3571 , CVE-2011-5035 , CVE-2012-0498 , CVE-2012-0499 , CVE-2012-0500 , CVE-2012-0501 , CVE-2012-0502 , CVE-2012-0503 , CVE-2012-0505 , CVE-2012-0506 This update fixes several vulnerabilities in the Sun Java 6 Runtime Environment and the Sun Java 6 Software Development Kit. Further information about these flaws can be found on the Oracle Java SE Critical Patch page: http://www.oracle.com/technetwork/topics/security/javacpufeb2012-366318.html http://www.oracle.com/technetwork/java/javase/6u31-relnotes-1482342.html All users of java-1.6.0-sun are advised to upgrade to these updated packages, which provide JDK and JRE 6 Update 31 and resolve these issues. All running instances of Sun Java must be restarted for the update to take effect.

Commands:
Chapter 3. Software requirements Supported platforms for Directory Server Red Hat supports Red Hat Directory Server if it runs on the following platforms: Red Hat Directory Server 12.5 runs on a Red Hat Enterprise Linux 9.5. Red Hat Directory Server 12.4 runs on a Red Hat Enterprise Linux 9.4. Red Hat Directory Server 12.3 runs on a Red Hat Enterprise Linux 9.3. Red Hat Directory Server 12.2 runs on a Red Hat Enterprise Linux 9.2. Red Hat Directory Server 12.1 runs on a Red Hat Enterprise Linux 9.1. Red Hat Directory Server 12.0 runs on a Red Hat Enterprise Linux 9.0. A Red Hat Enterprise Linux is built for AMD64 and Intel 64 architectures. A Red Hat Enterprise Linux virtual guest runs on a certified hypervisor. For details, see the Which hypervisors are certified to run Red Hat Enterprise Linux? solution article. Supported platforms for the Directory Server user interface in the web console Red Hat supports the browser-based Directory Server user interface in the web console in the following environments: Operating system Browser Red Hat Enterprise Linux 9.5 Mozilla Firefox 115 and later Chrome 88 and later Windows Server 2016 and 2019: Mozilla Firefox 115 and later Chrome 88 and later Windows 10 Mozilla Firefox 115 and later Microsoft Edge 88 and later Chrome 88 and later Supported platforms for the Windows Synchronization utility Red Hat supports the Windows Synchronization utility for Active Directory running on: Microsoft Windows Server 2019 Microsoft Windows Server 2016

Commands:
10.2. Trouble Beginning the Installation 10.2.1. Problems with Booting into the Graphical Installation There are some video cards that have trouble booting into the graphical installation program. If the installation program does not run using its default settings, it tries to run in a lower resolution mode. If that still fails, the installation program attempts to run in text mode. One possible solution is to use only a basic video driver during installation. You can do this either by selecting Install system with basic video driver on the boot menu, or using the xdriver=vesa boot option at the boot prompt. Alternatively, you can force the installer to use a specific screen resolution with the resolution= boot option. This option may be most helpful for laptop users. Another solution to try is the driver= option to specify the driver that should be loaded for your video card. If this works, you should report it as a bug, because the installer failed to detect your video card automatically. Refer to Chapter 28, Boot Options for more information on boot options. Note To disable frame buffer support and allow the installation program to run in text mode, try using the nofb boot option. This command may be necessary for accessibility with some screen reading hardware.

Commands:
Chapter 2. About migrating from OpenShift Container Platform 3 to 4 OpenShift Container Platform 4 contains new technologies and functionality that result in a cluster that is self-managing, flexible, and automated. OpenShift Container Platform 4 clusters are deployed and managed very differently from OpenShift Container Platform 3. The most effective way to migrate from OpenShift Container Platform 3 to 4 is by using a CI/CD pipeline to automate deployments in an application lifecycle management framework. If you do not have a CI/CD pipeline or if you are migrating stateful applications, you can use the Migration Toolkit for Containers (MTC) to migrate your application workloads. To successfully transition to OpenShift Container Platform 4, review the following information: Differences between OpenShift Container Platform 3 and 4 Architecture Installation and upgrade Storage, network, logging, security, and monitoring considerations About the Migration Toolkit for Containers Workflow File system and snapshot copy methods for persistent volumes (PVs) Direct volume migration Direct image migration Advanced migration options Automating your migration with migration hooks Using the MTC API Excluding resources from a migration plan Configuring the MigrationController custom resource for large-scale migrations Enabling automatic PV resizing for direct volume migration Enabling cached Kubernetes clients for improved performance

Commands:
7.114. linuxptp 7.114.1. RHBA-2015:1321 - linuxptp bug fix and enhancement update Updated linuxptp packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The linuxptp packages provide Precision Time Protocol (PTP) implementation for Linux according to IEEE standard 1588 for Linux. The dual design goals are to provide a robust implementation of the standard and to use the most relevant and modern Application Programming Interfaces (API) offered by the Linux kernel. Note The linuxptp packages have been upgraded to upstream version 1.5, which provides a number of bug fixes and enhancements over the version. (BZ# 1190222 ) Enhancement BZ# 1085584 This update adds support for failover between Precision Time Protocol (PTP) domains or Network Time Protocol (NTP) sources. The system is now able to fall back to an alternate time source if PTP becomes unavailable, or maintain PTP synchronization in the event of Network Interface Controller (NIC) failure by using another NIC in the system. Users of linuxptp are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
8.199. setuptool 8.199.1. RHBA-2013:0891 - setuptool bug fix update Updated setuptool packages that fix one bug are now available for Red Hat Enterprise Linux 6. Setuptool is a user-friendly text mode menu utility which allows the user to access all of the text mode configuration programs included in the operating system distribution. Bug Fix BZ# 883581 The /usr/share/man/man1/setup.1.gz file no longer has the executable flags set. Users of setuptool are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 3. Understanding How SystemTap Works SystemTap allows users to write and reuse simple scripts to deeply examine the activities of a running Linux system. These scripts can be designed to extract data, filter it, and summarize it quickly (and safely), enabling the diagnosis of complex performance (or even functional) problems. The essential idea behind a SystemTap script is to name events , and to give them handlers . When SystemTap runs the script, SystemTap monitors for the event; once the event occurs, the Linux kernel then runs the handler as a quick sub-routine and then resumes its normal operation. There are several kinds of events; entering or exiting a function, timer expiration, session termination, etc. A handler is a series of script language statements that specify the work to be done whenever the event occurs. This work normally includes extracting data from the event context, storing them into internal variables, and printing results. 3.1. Architecture A SystemTap session begins when you run a SystemTap script. This session occurs in the following fashion: Procedure 3.1. SystemTap Session First, SystemTap checks the script against the existing tapset library (normally in the /usr/share/systemtap/tapset/ directory) for any tapsets used. SystemTap will then substitute any located tapsets with their corresponding definitions in the tapset library. SystemTap then translates the script to C, running the system C compiler to create a kernel module from it. The tools that perform this step are contained in the systemtap package (see Section 2.1.1, "Installing SystemTap" for more information). SystemTap loads the module, then enables all the probes (events and handlers) in the script. The staprun in the systemtap-runtime package (see Section 2.1.1, "Installing SystemTap" for more information) provides this functionality. As the events occur, their corresponding handlers are executed. Once the SystemTap session is terminated, the probes are disabled, and the kernel module is unloaded. This sequence is driven from a single command-line program: stap . This program is SystemTap's main front-end tool. For more information about stap , see the stap (1) manual page (once SystemTap is properly installed on your machine).

Commands:
3.3.7. Thinly-Provisioned Snapshot Volumes The Red Hat Enterprise Linux release 6.4 version of LVM provides support for thinly-provisioned snapshot volumes. Thin snapshot volumes allow many virtual devices to be stored on the same data volume. This simplifies administration and allows for the sharing of data between snapshot volumes. As for all LVM snapshot volumes, as well as all thin volumes, thin snapshot volumes are not supported across the nodes in a cluster. The snapshot volume must be exclusively activated on only one cluster node. Thin snapshot volumes provide the following benefits: A thin snapshot volume can reduce disk usage when there are multiple snapshots of the same origin volume. If there are multiple snapshots of the same origin, then a write to the origin will cause one COW operation to preserve the data. Increasing the number of snapshots of the origin should yield no major slowdown. Thin snapshot volumes can be used as a logical volume origin for another snapshot. This allows for an arbitrary depth of recursive snapshots (snapshots of snapshots of snapshots...). A snapshot of a thin logical volume also creates a thin logical volume. This consumes no data space until a COW operation is required, or until the snapshot itself is written. A thin snapshot volume does not need to be activated with its origin, so a user may have only the origin active while there are many inactive snapshot volumes of the origin. When you delete the origin of a thinly-provisioned snapshot volume, each snapshot of that origin volume becomes an independent thinly-provisioned volume. This means that instead of merging a snapshot with its origin volume, you may choose to delete the origin volume and then create a new thinly-provisioned snapshot using that independent volume as the origin volume for the new snapshot. Although there are many advantages to using thin snapshot volumes, there are some use cases for which the older LVM snapshot volume feature may be more appropriate to your needs: You cannot change the chunk size of a thin pool. If the thin pool has a large chunk size (for example, 1MB) and you require a short-living snapshot for which a chunk size that large is not efficient, you may elect to use the older snapshot feature. You cannot limit the size of a thin snapshot volume; the snapshot will use all of the space in the thin pool, if necessary. This may not be appropriate for your needs. In general, you should consider the specific requirements of your site when deciding which snapshot format to use. For information on configuring thin snapshot volumes, see Section 5.4.6, "Creating Thinly-Provisioned Snapshot Volumes" .

Commands:
7.305. busybox 7.305.1. RHBA-2013:1165 - busybox bug fix update Updated busybox packages that fix one bug are now available for Red Hat Enterprise Linux 6. BusyBox is a binary that combines a large number of common system utilities into a single executable. BusyBox provides replacements for most GNU file utilities, shell utilities, and other command-line tools. Bug Fix BZ# 981178 Prior to this update, the "mknod" command was unable to create device nodes with a major or minor number larger than 255. Consequently, the kdump utility failed to handle such a device. The underlying source code has been modified, and it is now possible to use the "mknod" command to create device nodes with a major or minor number larger than 255. Users of busybox are advised to upgrade to these updated packages, which fix this bug.

Commands: