mtpti5iD/redhat-docs_dataset huggingface dataset:
7.5. Opening and Updating Support Cases Using Interactive Mode Procedure 7.2. Opening a New Support Case Using Interactive Mode To open a new support case using interactive mode, proceed as follows: Start the tool by entering the following command: Enter the opencase command: Follow the on screen prompts to select a product and then a version. Enter a summary of the case. Enter a description of the case and press Ctrl + D on an empty line when complete. Select a severity of the case. Optionally chose to see if there is a solution to this problem before opening a support case. Confirm you would still like to open the support case. Optionally chose to attach an SOS report. Optionally chose to attach a file. Procedure 7.3. Viewing and Updating an Existing Support Case Using Interactive Mode To view and update an existing support case using interactive mode, proceed as follows: Start the tool by entering the following command: Enter the getcase command: Where case-number is the number of the case you want to view and update. Follow the on screen prompts to view the case, modify or add comments, and get or add attachments. Procedure 7.4. Modifying an Existing Support Case Using Interactive Mode To modify the attributes of an existing support case using interactive mode, proceed as follows: Start the tool by entering the following command: Enter the modifycase command: Where case-number is the number of the case you want to view and update. The modify selection list appears: Follow the on screen prompts to modify one or more of the options. For example, to modify the status, enter 3 :

Commands:
~]# redhat-support-tool
Command (? for help): opencase
Support case 0123456789 has successfully been opened
~]# redhat-support-tool
Command (? for help): getcase case-number
~]# redhat-support-tool
Command (? for help): modifycase case-number
Type the number of the attribute to modify or 'e' to return to the previous menu. 1 Modify Type 2 Modify Severity 3 Modify Status 4 Modify Alternative-ID 5 Modify Product 6 Modify Version End of options.
Selection: 3 1 Waiting on Customer 2 Waiting on Red Hat 3 Closed Please select a status (or 'q' to exit):
11.14. Alter Statement ALTER statements currently primarily support adding OPTIONS properties to Tables, Views and Procedures. Using a ALTER statement, you can either add, modify or remove a property. See "alter column options", "alter options", and "alter options list" in Section A.7, "Productions" . Example 11.6. Example ALTER ALTER statements are especially useful, when user would like to modify/enhance the metadata that has been imported from a NATIVE datasource. For example, if you have a database called "northwind", and you imported that metadata and would like to add CARDINALITY to its "customer" table, you can use ALTER statement, along with "chainable" metadata repositories feature to add this property to the desired table. The below shows an example -vdb.xml file, that illustrates the usage. Example 11.7. Example VDB

Commands:
ALTER FOREIGN TABLE "customer" OPTIONS (ADD CARDINALITY 10000); ALTER FOREIGN TABLE "customer" ALTER COLUMN "name" OPTIONS(SET UPDATABLE FALSE)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <vdb name="northwind" version="1"> <model name="nw"> <property name="importer.importKeys" value="true"/> <property name="importer.importProcedures" value="true"/> <source name="northwind-connector" translator-name="mysql" connection-jndi-name="java:/nw-ds"/> <metadata type = "NATIVE,DDL"><![CDATA[ ALTER FOREIGN TABLE "customer" OPTIONS (ADD CARDINALITY 10000); ALTER FOREIGN TABLE "customer" ALTER COLUMN "name" OPTIONS(SET UPDATABLE FALSE); ]]> </metadata> </model> </vdb>
5.2. Entitlement subscription-manager component When firstboot is running in text mode, the user can only register via Red Hat Network Register, not with subscription-manager . Both are available in GUI mode. subscription-manager component If multiple repositories are enabled, subscription-manager installs product certificates from all repositories instead of installing the product certificate only from the repository from which the RPM package was installed. subscription-manager component firstboot fails to provide Red Hat Network registration to a virtual machine in a NAT-based network; for example, in the libvirt environment. Note that this problem only occurs during the first boot after installation. If you run firstboot manually later, the registration finishes successfully.

Commands:
8.67. ibus-hangul 8.67.1. RHBA-2013:1036 - ibus-hangul bug fix update Updated ibus-hangul packages that fix one bug are now available. The ibus-hangul package is a Korean language input engine platform for the IBus input method (IM). Bug Fix BZ#965554 Previously, the Hangul engine for IBus did not function properly. If a preedit string was available, and the input focus was moved to another window, then the preedit string was committed. After that, when the input focus was moved back to the window, the X Input Method (XIM) could not handle the first key input. This update resolves this issue with a change in the code, and key press inputs after a focus change are no longer lost in the described scenario. Users of ibus-hangul are advised to upgrade to these updated packages, which fix this bug.

Commands:
8.113. mcelog 8.113.1. RHBA-2013:1658 - mcelog bug fix and enhancement update Updated mcelog packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The mcelog packages contain a daemon that collects and decodes Machine Check Exception (MCE) data on AMD64 and Intel 64 machines. Bug Fixes BZ# 875824 Previously, mcelog packages installed a cron job to report the status of mce logs, which conflicted with running the mclogd service as default mode. Consequently, mcelog competed with the cron job and did not collect complete data. With this update, cron job is not installed in case mcelogd is running, thus fixing this bug. BZ# 919999 Due to a bug in mcelog packages, the AMD Family 15 architecture was not supported. The bug has been fixed and mcelog now supports AMD Family 15 as expected. BZ# 996634 Previously, support for extended logging was enabled by default in mcelog packages. Consequently, on systems with processors without support for extended logging, the mcelog service terminated unexpectedly with the following message: mcelog: Cannot open /dev/cpu/0/msr to set imc_log: Permission denied With this update, extended logging is disabled by default in mcelog packages, and the mcelog service no longer crashes in the aforementioned scenario. Enhancement BZ# 881555 , BZ# 922873 , BZ# 991079 With this update, mcelog packags support Intel Xeon Processor E5-XXXX v3, Intel Xeon Processor E5-XXXX, and Intel Xeon Processor E3-XXXX v3 architectures. Users of mcelog are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
28.4.7. Configuring Automatic Reporting for Specific Types of Crashes ABRT can be configured to report any detected issues or crashes automatically without any user interaction. This can be achieved by specifying an analyze-and-report rule as a post-create rule. For example, you can instruct ABRT to report Python crashes to Bugzilla immediately without any user interaction by enabling the rule and replacing the EVENT=report_Bugzilla condition with the EVENT=post-create condition in the /etc/libreport/events.d/python_event.conf file. The new rule will look like the follows: EVENT=post-create analyzer=Python test -f component || abrt-action-save-package-data reporter-bugzilla -c /etc/abrt/plugins/bugzilla.conf Warning Please note that the post-create event is run by abrtd , which usually runs with root privileges.

Commands:
EVENT=post-create analyzer=Python test -f component || abrt-action-save-package-data reporter-bugzilla -c /etc/abrt/plugins/bugzilla.conf
Chapter 1. About the Migration Toolkit for Virtualization You can use the Migration Toolkit for Virtualization (MTV) to migrate virtual machines from the following source providers to OpenShift Virtualization destination providers: VMware vSphere Red Hat Virtualization (RHV) OpenStack Open Virtual Appliances (OVAs) that were created by VMware vSphere Remote OpenShift Virtualization clusters Additional resources Performance recommendations for migrating from VMware vSphere to OpenShift Virtualization . Performance recommendations for migrating from Red Hat Virtualization to OpenShift Virtualization . 1.1. About cold and warm migration MTV supports cold migration from: VMware vSphere Red Hat Virtualization (RHV) OpenStack Remote OpenShift Virtualization clusters MTV supports warm migration from VMware vSphere and from RHV. 1.1.1. Cold migration Cold migration is the default migration type. The source virtual machines are shut down while the data is copied. 1.1.2. Warm migration Most of the data is copied during the precopy stage while the source virtual machines (VMs) are running. Then the VMs are shut down and the remaining data is copied during the cutover stage. Precopy stage The VMs are not shut down during the precopy stage. The VM disks are copied incrementally using changed block tracking (CBT) snapshots. The snapshots are created at one-hour intervals by default. You can change the snapshot interval by updating the forklift-controller deployment. Important You must enable CBT for each source VM and each VM disk. A VM can support up to 28 CBT snapshots. If the source VM has too many CBT snapshots and the Migration Controller service is not able to create a new snapshot, warm migration might fail. The Migration Controller service deletes each snapshot when the snapshot is no longer required. The precopy stage runs until the cutover stage is started manually or is scheduled to start. Cutover stage The VMs are shut down during the cutover stage and the remaining data is migrated. Data stored in RAM is not migrated. You can start the cutover stage manually by using the MTV console or you can schedule a cutover time in the Migration manifest.

Commands:
27.2. Defining Self-Service Settings Self-service access control rules define the operations that an entity can perform on itself. These rules define only what attributes a user (or other IdM entity) can edit on their personal entries. Three self-service rules exist by default: A rule for editing some general attributes in the personal entry, including given name and surname, phone numbers, and addresses. A rule to edit personal passwords, including two Samba passwords, the Kerberos password, and the general user password. A rule to manage personal SSH keys. 27.2.1. Creating Self-Service Rules from the Web UI Open the IPA Server tab in the top menu, and select the Self Service Permissions subtab. Click the Add link at the top of the list of self-service ACIs. Enter the name of the rule in the pop-up window. Spaces are allowed. Select the checkboxes by the attributes which this ACI will permit users to edit. Click the Add button to save the new self-service ACI. 27.2.2. Creating Self-Service Rules from the Command Line A new self-service rule can be added using the selfservice-add command. There are two required options, --permissions to set whether the ACI grants write, add, or delete permission and --attrs to give the full list of attributes which this ACI grants permission to. 27.2.3. Editing Self-Service Rules In the self-service entry in the web UI, the only element that can be edited is the list of attributes that are included in the ACI. The checkboxes can be selected or deselected. Figure 27.1. Self-Service Edit Page With the command line, self-service rules are edited using the ipa selfservice-mod command. The --attrs option overwrites whatever the list of supported attributes was, so always include the complete list of attributes along with any new attributes. Important Include all of the attributes when modifying a self-service rule, including existing ones.

Commands:
ipa selfservice-add "Users can manage their own name details" --permissions=write --attrs=givenname,displayname,title,initials ----------------------------------------------------------- Added selfservice "Users can manage their own name details" ----------------------------------------------------------- Self-service name: Users can manage their own name details Permissions: write Attributes: givenname, displayname, title, initials
ipa selfservice-mod "Users can manage their own name details" --attrs=givenname,displayname,title,initials,surname -------------------------------------------------------------- Modified selfservice "Users can manage their own name details" -------------------------------------------------------------- Self-service name: Users can manage their own name details Permissions: write Attributes: givenname, displayname, title, initials
Chapter 30. Customizing project preferences In Business Central, a project is a part of your space and stores the related assets. You can add multiple projects in a space. For example, an organization includes various departments, such as HR, Payroll, Engineering, and R&D. You can map each department to a space in Business Central, along with adding respective projects. You can customize the project settings in Business Central. Also, you can create a new project or clone projects from an existing Git repository. Procedure In Business Central, select the Admin icon in the upper-right corner and select Projects . In the Project Preferences panel, select the preference you want to modify. The project preferences include: Project Importing : This preference consists of the following property: Select the Allow multiple projects to be imported on cluster to import multiple projects on a cluster. File exporting : This preference consists of the following properties: Table 30.1. File exporting properties Field Description PDF orientation Determines whether the PDF orientation is portrait or landscape. PDF units Determines whether the PDF unit is PT , MM , CN , or IN . PDF page format Determines whether the PDF page format is A[0-10] , B[0-10] , or C[0-10] . Spaces : This preference consists of the following properties: Table 30.2. Spaces properties Field Description Name The default name of the space that is created automatically if none exists. Owner The default owner of the space that is created automatically if none exists. Group ID The default group ID of the space that is created automatically if none exists. Alias (in singular) Determines the customized alias (singular) of the space. Alias (in plural) Determines the customized alias (plural) of the space. Default values : This preference consists of the following properties: Table 30.3. Default values properties Field Description Version The default version number of a project when creating projects. Description The default description of a project when creating projects. Branch The default branch to be used when using a Git repository. Assets Per Page Used to customize the number of assets per page in the project. The default value is 15 . Advanced GAV preferences : This preference consists of the following properties: Table 30.4. Advanced GAV preference properties Field Description Disable GAV conflict check? Determines whether to enable or disable the GAV conflict check. Disabling this checkbox enables the projects to contain the same GAV (group ID, artifact, and version). Allow child GAV edition? Determines whether to allow child or subprojects to contain GAV edition. Note Duplicate GAV detection is disabled for projects in the development mode. To enable duplicate GAV detection for a project in Business Central, go to project Settings General Settings Version and toggle the Development Mode option to OFF (if applicable). Click Save .

Commands:
Appendix B. Revision History Revision History Revision 1.3-7 Fri Mar 7 2014 Eliska Slobodova Updated a note about pNFS. Revision 1.3-4 Tue Feb 18 2014 Eliska Slobodova Added a note about Mellanox SR-IOV support. Revision 1.3-3 Wed Jan 15 2014 Eliska Slobodova Updated a note about the Hyper-V balloon driver. Revision 1.3-2 Mon Feb 25 2013 Martin Prpic Added Subscription Asset Manager release notes. Revision 1.2-1 Thu Feb 21 2013 Martin Prpic Release of the Red Hat Enterprise Linux 6.4 Release Notes. Revision 1.1-14 Wed Dec 4 2012 Martin Prpic Release of the Red Hat Enterprise Linux 6.4 Beta Release Notes.

Commands:
1.3. Setting Up Hardware Setting up hardware consists of connecting cluster nodes to other hardware required to run the Red Hat High Availability Add-On. The amount and type of hardware varies according to the purpose and availability requirements of the cluster. Typically, an enterprise-level cluster requires the following type of hardware (see Figure 1.1, "Red Hat High Availability Add-On Hardware Overview" ). For considerations about hardware and other cluster configuration concerns, see Chapter 3, Before Configuring the Red Hat High Availability Add-On or check with an authorized Red Hat representative. Cluster nodes - Computers that are capable of running Red Hat Enterprise Linux 6 software, with at least 1GB of RAM. Network switches for public network - This is required for client access to the cluster. Network switches for private network - This is required for communication among the cluster nodes and other cluster hardware such as network power switches and Fibre Channel switches. Fencing device - A fencing device is required. A network power switch is recommended to perform fencing in an enterprise-level cluster. For information about supported fencing devices, see Appendix A, Fence Device Parameters . Storage - Some type of storage is required for a cluster. Figure 1.1, "Red Hat High Availability Add-On Hardware Overview" shows shared storage, but shared storage may not be required for your specific use. Figure 1.1. Red Hat High Availability Add-On Hardware Overview

Commands:
Chapter 4. Installing a cluster 4.1. Deploying the cluster via the OpenShift Container Platform installer Run the OpenShift Container Platform installer: USD ./openshift-baremetal-install --dir ~/clusterconfigs --log-level debug create cluster 4.2. Following the progress of the installation During the deployment process, you can check the installation's overall status by issuing the tail command to the .openshift_install.log log file in the install directory folder: USD tail -f /path/to/install-dir/.openshift_install.log 4.3. Verifying static IP address configuration If the DHCP reservation for a cluster node specifies an infinite lease, after the installer successfully provisions the node, the dispatcher script checks the node's network configuration. If the script determines that the network configuration contains an infinite DHCP lease, it creates a new connection using the IP address of the DHCP lease as a static IP address. Note The dispatcher script might run on successfully provisioned nodes while the provisioning of other nodes in the cluster is ongoing. Verify the network configuration is working properly. Procedure Check the network interface configuration on the node. Turn off the DHCP server and reboot the OpenShift Container Platform node and ensure that the network configuration works properly. 4.4. Preparing to reinstall a cluster on bare metal Before you reinstall a cluster on bare metal, you must perform cleanup operations. Procedure Remove or reformat the disks for the bootstrap, control plane node, and worker nodes. If you are working in a hypervisor environment, you must add any disks you removed. Delete the artifacts that the installation generated: USD cd ; /bin/rm -rf auth/ bootstrap.ign master.ign worker.ign metadata.json \ .openshift_install.log .openshift_install_state.json Generate new manifests and Ignition config files. See "Creating the Kubernetes manifest and Ignition config files" for more information. Upload the new bootstrap, control plane, and compute node Ignition config files that the installation program created to your HTTP server. This will overwrite the Ignition files. 4.5. Additional resources Creating the Kubernetes manifest and Ignition config files Understanding update channels and releases

Commands:
./openshift-baremetal-install --dir ~/clusterconfigs --log-level debug create cluster
tail -f /path/to/install-dir/.openshift_install.log
cd ; /bin/rm -rf auth/ bootstrap.ign master.ign worker.ign metadata.json .openshift_install.log .openshift_install_state.json
5.3.3. Profiling Heap and Stack Space with Massif Massif measures the heap space used by a specified program; both the useful space, and any additional space allocated for book-keeping and alignment purposes. It can help you reduce the amount of memory used by your program, which can increase your program's speed, and reduce the likelihood that your program will exhaust the swap space of the machine on which it executes. Massif can also provide details about which parts of your program are responsible for allocating heap memory. Programs run with Massif run about twenty times more slowly than their normal execution speed. To profile the heap usage of a program, specify massif as the Valgrind tool you wish to use: Profiling data gathered by Massif is written to a file, which by default is called massif.out. pid , where pid is the process ID of the specified program . This profiling data can also be graphed with the ms_print command, like so: This produces a graph showing memory consumption over the program's execution, and detailed information about the sites responsible for allocation at various points in the program, including at the point of peak memory allocation. Massif provides a number of command line options that can be used to direct the output of the tool. Some of the available options are: --heap Specifies whether to perform heap profiling. The default value is yes . Heap profiling can be disabled by setting this option to no . --heap-admin Specifies the number of bytes per block to use for administration when heap profiling is enabled. The default value is 8 bytes per block. --stacks Specifies whether to perform stack profiling. The default value is no (disabled). To enable stack profiling, set this option to yes , but be aware that doing so will greatly slow Massif. Also note that Massif assumes that the main stack has size zero at start-up in order to better indicate the size of the stack portion over which the program being profiled has control. --time-unit Specifies the unit of time used for the profiling. There are three valid values for this option: instructions executed ( i ), the default value, which is useful in most cases; real time ( ms , in milliseconds), which can be useful in certain instances; and bytes allocated/deallocated on the heap and/or stack ( B ), which is useful for very short-run programs, and for testing purposes, because it is the most reproducible across different machines. This option is useful when graphing Massif output with ms_print . For a full list of options, refer to the documentation included at /usr/share/doc/valgrind- version /valgrind_manual.pdf .

Commands:
valgrind --tool=massif program
ms_print massif.out. pid