mtpti5iD/redhat-docs_dataset huggingface dataset:
30.5. Deployment Scenarios VDO can be deployed in a variety of ways to provide deduplicated storage for both block and file access and for both local and remote storage. Because VDO exposes its deduplicated storage as a standard Linux block device, it can be used with standard file systems, iSCSI and FC target drivers, or as unified storage. 30.5.1. iSCSI Target As a simple example, the entirety of the VDO storage target can be exported as an iSCSI Target to remote iSCSI initiators. Figure 30.3. Deduplicated Block Storage Target For more information on iSCSI Target, Section 25.1, "Target Setup" 30.5.2. File Systems If file access is desired instead, file systems can be created on top of VDO and exposed to NFS or CIFS users via either the Linux NFS server or Samba. Figure 30.4. Deduplicated NAS 30.5.3. LVM More feature-rich systems may make further use of LVM to provide multiple LUNs that are all backed by the same deduplicated storage pool. In Figure 30.5, "Deduplicated Unified Storage" , the VDO target is registered as a physical volume so that it can be managed by LVM. Multiple logical volumes ( LV1 to LV4 ) are created out of the deduplicated storage pool. In this way, VDO can support multiprotocol unified block/file access to the underlying deduplicated storage pool. Figure 30.5. Deduplicated Unified Storage Deduplicated unified storage design allows for multiple file systems to collectively use the same deduplication domain through the LVM tools. Also, file systems can take advantage of LVM snapshot, copy-on-write, and shrink or grow features, all on top of VDO. 30.5.4. Encryption Data security is critical today. More and more companies have internal policies regarding data encryption. Linux Device Mapper mechanisms such as DM-Crypt are compatible with VDO. Encrypting VDO volumes will help ensure data security, and any file systems above VDO still gain the deduplication feature for disk optimization. Note that applying encryption above VDO results in little if any data deduplication; encryption renders duplicate blocks different before VDO can deduplicate them. Figure 30.6. Using VDO with Encryption

Commands:
Chapter 20. Deleting the Bootstrap User Important Before you delete the bootstrap user, create a real PKI administrative user as described in Chapter 19, Creating a Role User . To delete the bootstrap user, follow the procedure described in the Deleting a Certificate System User section in the Red Hat Certificate System Administration Guide . 20.1. Disabling Multi-roles Support By default, users can belong to more than one subsystem group at once, allowing the user to act as more than one role. For example, John Smith could belong to both an agent and an administrator group. However, for highly secure environments, the subsystem roles should be restricted so that a user can only belong to one role. This can be done by disabling the multirole attribute in the instance's configuration. For all subsystems: Stop the server: OR (if using nuxwdog watchdog ) Open the CS.cfg file: Change the multiroles.enable parameter value from true to false . Add or edit the list of default roles in Certificate System that are affected by the multi-roles setting. If multi-roles is disabled and a user belongs to one of the roles listed in the multiroles.false.groupEnforceList parameter, then the user cannot be added to any group for any of the other roles in the list. Restart the server: OR (if using nuxwdog watchdog )

Commands:
systemctl stop pki-tomcatd@ instance_name .service
systemctl stop pki-tomcatd-nuxwdog@ instance_name .service
vim /var/lib/pki/ instance_name /ca/conf/CS.cfg
multiroles.false.groupEnforceList =Administrators,Auditors,Trusted Managers,Certificate Manager Agents,Registration Manager Agents,Key Recovery Authority Agents,Online Certificate Status Manager Agents,Token Key Service Manager Agents,Enterprise CA Administrators,Enterprise KRA Adminstrators,Enterprise OCSP Administrators,Enterprise TKS Administrators,Enterprise TPS Administrators,Security Domain Administrators,Subsystem Group
systemctl start pki-tomcatd@ instance_name .service
systemctl start pki-tomcatd-nuxwdog@ instance_name .service
14.2.5. Adding a New Volume Group Once initialized, LVM will add the new volume to the list of unallocated volumes where you can add it to an existing volume group or create a new volume group. You can also remove the volume from LVM. If the volume is removed from LVM, it will be added to the 'Uninitialized Entities' list, as illustrated in Figure 14.13, "Uninitialized hard disk" . Example 14.4. Create a new volume group In this example, a new volume group was created as illustrated below. Once created a new volume group will be displayed in the list of existing volume groups as illustrated below. The logical view will display the new volume group with unused space as no logical volumes have been created. To create a logical volume, select the volume group and click on the Create New Logical Volume button as illustrated below. Select the extents you wish to use on the volume group. Example 14.5. Select the extents In this example, all the extents in the volume group were used to create the new logical volume. The figure below illustrates the physical view of the new volume group. The new logical volume named 'Backups' in this volume group is also listed. Figure 14.14. Physical view of new volume group

Commands:
5.215. nss 5.215.1. RHBA-2012:1003 - nss bug fix update Updated nss packages that fix one bug are now available for Red Hat Enterprise Linux 6. Network Security Services (NSS) is a set of libraries designed to support the cross-platform development of security-enabled client and server applications. Bug Fix BZ# 828679 Due to a missing out-of-memory (OOM) check and improper freeing of allocated memory, the Privacy Enhanced Mail (PEM) module did not fully validate the encoding of certificates stored in a PEM-formatted file. As a consequence, error handling tests failed. With this update, the PEM module correctly validates the encoding, handles memory deallocation consistently, and error handling tests pass as expected. All users of nss are advised to upgrade to these updated packages, which fix this bug.

Commands:
8.2.3. Evolving Rules and Broken Applications Applications may be broken, causing SELinux to deny access. Also, SELinux rules are evolving - SELinux may not have seen an application running in a certain way, possibly causing it to deny access, even though the application is working as expected. For example, if a new version of PostgreSQL is released, it may perform actions the current policy has not seen before, causing access to be denied, even though access should be allowed. For these situations, after access is denied, use audit2allow to create a custom policy module to allow access. Refer to Section 8.3.8, "Allowing Access: audit2allow" for information about using audit2allow .

Commands:
18.12.9. Filter Rules The following XML shows a simple example of a network traffic filter implementing a rule to drop traffic if the IP address (provided through the value of the variable IP) in an outgoing IP packet is not the expected one, thus preventing IP address spoofing by the VM. Example 18.8. Example of network traffic filtering The traffic filtering rule starts with the rule node. This node may contain up to three of the following attributes: action is mandatory can have the following values: drop (matching the rule silently discards the packet with no further analysis) reject (matching the rule generates an ICMP reject message with no further analysis) accept (matching the rule accepts the packet with no further analysis) return (matching the rule passes this filter, but returns control to the calling filter for further analysis) continue (matching the rule goes on to the rule for further analysis) direction is mandatory can have the following values: in for incoming traffic out for outgoing traffic inout for incoming and outgoing traffic priority is optional. The priority of the rule controls the order in which the rule will be instantiated relative to other rules. Rules with lower values will be instantiated before rules with higher values. Valid values are in the range of -1000 to 1000. If this attribute is not provided, priority 500 will be assigned by default. Note that filtering rules in the root chain are sorted with filters connected to the root chain following their priorities. This allows to interleave filtering rules with access to filter chains. Refer to Section 18.12.3, "Filtering Chain Priorities" for more information. statematch is optional. Possible values are '0' or 'false' to turn the underlying connection state matching off. The default setting is 'true' or 1 For more information see Section 18.12.11, "Advanced Filter Configuration Topics" . The above example Example 18.7, "An Example of a clean traffic filter" indicates that the traffic of type ip will be associated with the chain ipv4 and the rule will have priority= 500 . If for example another filter is referenced whose traffic of type ip is also associated with the chain ipv4 then that filter's rules will be ordered relative to the priority= 500 of the shown rule. A rule may contain a single rule for filtering of traffic. The above example shows that traffic of type ip is to be filtered.

Commands:
<filter name='no-ip-spoofing' chain='ipv4'> <uuid>fce8ae33-e69e-83bf-262e-30786c1f8072</uuid> <rule action='drop' direction='out' priority='500'> <ip match='no' srcipaddr='USDIP'/> </rule> </filter>
20.2. SSH Protocol Versions The SSH protocol allows any client and server programs built to the protocol's specifications to communicate securely and to be used interchangeably. Two varieties of SSH (version 1 and version 2) currently exist. SSH version 1 makes use of several patented encryption algorithms (however, some of these patents have expired) and is vulnerable to a well known security exploit that allows an attacker to insert data into the communication stream. The OpenSSH suite under Red Hat Enterprise Linux uses SSH version 2 which has an enhanced key exchange algorithm not vulnerable to the exploit in version 1. However, the OpenSSH suite does support version 1 connections. Important It is recommended that only SSH version 2-compatible servers and clients are used whenever possible.

Commands:
5.3. Reverting to an Ext2 File System In order to revert to an ext2 file system, use the following procedure. For simplicity, the sample commands in this section use the following value for the block device: /dev/mapper/VolGroup00-LogVol02 Procedure 5.2. Revert from ext3 to ext2 Unmount the partition by logging in as root and typing: Change the file system type to ext2 by typing the following command: Check the partition for errors by typing the following command: Then mount the partition again as ext2 file system by typing: In the above command, replace /mount/point with the mount point of the partition. Note If a .journal file exists at the root level of the partition, delete it. To permanently change the partition to ext2, remember to update the /etc/fstab file, otherwise it will revert back after booting.

Commands:
umount /dev/mapper/VolGroup00-LogVol02
tune2fs -O ^has_journal /dev/mapper/VolGroup00-LogVol02
e2fsck -y /dev/mapper/VolGroup00-LogVol02
mount -t ext2 /dev/mapper/VolGroup00-LogVol02 /mount/point
8.110. less 8.110.1. RHBA-2014:0755 - less bug fix update Updated less packages that fix one bug are now available for Red Hat Enterprise Linux 6. The "less" utility is a text file browser that resembles "more", but allows users to move backwards in the file as well as forwards. Since "less" does not read the entire input file at startup, it also starts more quickly than ordinary text editors. Bug Fix BZ# 615303 Previously, the lesspipe script returned incorrect exit status codes. As a consequence, the less utility failed to decompress empty files that had been compressed with the gzip utility, and an unwanted message was displayed. With this update, a pipe character ("|") has been added in front of the LESSOPEN environment variable to enforce a new default behavior of lesspipe. For backward compatibility, lesspipe has the same behavior if LESSOPEN remains unchanged. As a result, the less utility now detects and displays empty files correctly. Users of less are advised to upgrade to these updated packages, which fix this bug.

Commands:
4.17. RHEA-2012:0806 - new packages: scl-utils New scl-utils packages are now available for Red Hat Enterprise Linux 6. The scl-utils packages provide a runtime utility and RPM packaging macros for packaging Software Collections. Software Collections allow users to concurrently install multiple versions of the same RPM packages on the system. Using the scl utility, users may enable specific versions of RPMs, which are installed into the /opt directory. This enhancement update adds the scl-utils packages to Red Hat Enterprise Linux 6. (BZ# 713147 ) All users who require scl-utils should install these new packages.

Commands:
Preface Thank you for your interest in Red Hat Ansible Automation Platform. Ansible Automation Platform is a commercial offering that helps teams manage complex multi-tier deployments by adding control, knowledge, and delegation to Ansible-powered environments. This guide describes how to develop Ansible automation content and how to use it to run automation jobs from Red Hat Ansible Automation Platform. This document has been updated to include information for the latest release of Ansible Automation Platform.

Commands:
8.5. Getting Information of all the Available Snapshots The following command provides the basic information of all the snapshots taken. By default the information of all the snapshots in the cluster is displayed: where, snapname - This is an optional field. If the snapname is provided then the information about the specified snap is displayed. VOLNAME - This is an optional field. If the VOLNAME is provided the information about all the snaps in the specified volume is displayed. For Example:

Commands:
gluster snapshot info [(< snapname > | volume VOLNAME )]
gluster snapshot info snap3 Snapshot : snap3 Snap UUID : b2a391ce-f511-478f-83b7-1f6ae80612c8 Created : 2014-06-13 09:40:57 Snap Volumes: Snap Volume Name : e4a8f4b70a0b44e6a8bff5da7df48a4d Origin Volume name : test_vol1 Snaps taken for test_vol1 : 1 Snaps available for test_vol1 : 255 Status : Started
5.169. libxslt 5.169.1. RHSA-2012:1265 - Important: libxslt security update Updated libxslt packages that fix several security issues are now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having important 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. libxslt is a library for transforming XML files into other textual formats (including HTML, plain text, and other XML representations of the underlying data) using the standard XSLT stylesheet transformation mechanism. Security Fixes CVE-2012-2871 A heap-based buffer overflow flaw was found in the way libxslt applied templates to nodes selected by certain namespaces. An attacker could use this flaw to create a malicious XSL file that, when used by an application linked against libxslt to perform an XSL transformation, could cause the application to crash or, possibly, execute arbitrary code with the privileges of the user running the application. CVE-2012-2825 , CVE-2012-2870 , CVE-2011-3970 Several denial of service flaws were found in libxslt. An attacker could use these flaws to create a malicious XSL file that, when used by an application linked against libxslt to perform an XSL transformation, could cause the application to crash. CVE-2011-1202 An information leak could occur if an application using libxslt processed an untrusted XPath expression, or used a malicious XSL file to perform an XSL transformation. If combined with other flaws, this leak could possibly help an attacker bypass intended memory corruption protections. All libxslt users are advised to upgrade to these updated packages, which contain backported patches to resolve these issues. All running applications linked against libxslt must be restarted for this update to take effect.

Commands:
22.2. XML representation of a User Resource Example 22.1. An XML representation of a user resource

Commands:
GET /ovirt-engine/api/users HTTP/1.1 Accept: application/xml <user id="225f15cd-e891-434d-8262-a66808fcb9b1" href="/ovirt-engine/api/users/225f15cd-e891-434d-8262-a66808fcb9b1"> <name>RHEV-M Admin</name> <actions/> <link rel="roles" href="/ovirt-engine/api/users/225f15cd-e891-434d-8262-a66808fcb9b1/roles"/> <link rel="tags" href="/ovirt-engine/api/users/225f15cd-e891-434d-8262-a66808fcb9b1/tags"/> <domain>domain.example.com</domain> <logged_in>false</logged_in> <user_name>rhevmadmin@domain.example.com</user_name> <groups> <group>Group Policy Creator Owners@domain.example.com/Users</group> <group>Domain Admins@domain.example.com/Users</group> <group>Enterprise Admins@domain.example.com/Users</group> <group>Schema Admins@domain.example.com/Users</group> <group>Administrators@domain.example.com/Builtin</group> </groups> </user>
5.3.6. Scanning Disks for Volume Groups to Build the Cache File The vgscan command scans all supported disk devices in the system looking for LVM physical volumes and volume groups. This builds the LVM cache file in the /etc/lvm/cache/.cache file, which maintains a listing of current LVM devices. LVM runs the vgscan command automatically at system startup and at other times during LVM operation, such as when you execute a vgcreate command or when LVM detects an inconsistency. Note You may need to run the vgscan command manually when you change your hardware configuration and add or delete a device from a node, causing new devices to be visible to the system that were not present at system bootup. This may be necessary, for example, when you add new disks to the system on a SAN or hotplug a new disk that has been labeled as a physical volume. You can define a filter in the lvm.conf file to restrict the scan to avoid specific devices. For information on using filters to control which devices are scanned, see Section 5.5, "Controlling LVM Device Scans with Filters" . The following example shows the output of a vgscan command.

Commands:
vgscan Reading all physical volumes. This may take a while Found volume group "new_vg" using metadata type lvm2 Found volume group "officevg" using metadata type lvm2
5.4. Determining Device Mapper Entries with the dmsetup Command You can use the dmsetup command to find out which device mapper entries match the multipathed devices. The following command displays all the device mapper devices and their major and minor numbers. The minor numbers determine the name of the dm device. For example, a minor number of 3 corresponds to the multipathed device /dev/dm-3 .

Commands:
dmsetup ls mpath2 (253, 4) mpath4p1 (253, 12) mpath5p1 (253, 11) mpath1 (253, 3) mpath6p1 (253, 14) mpath7p1 (253, 13) mpath0 (253, 2) mpath7 (253, 9) mpath6 (253, 8) VolGroup00-LogVol01 (253, 1) mpath5 (253, 7) VolGroup00-LogVol00 (253, 0) mpath4 (253, 6) mpath1p1 (253, 10) mpath3 (253, 5)
3.7.2. Modifying a Failover Domain To modify a failover domain, follow the steps in this section. The starting point of the procedure is at the cluster-specific page that you navigate to from Choose a cluster to administer displayed on the cluster tab. At the detailed menu for the cluster (below the clusters menu), click Failover Domains . Clicking Failover Domains causes the display of failover domains with related services and the display of menu items for failover domains: Add a Failover Domain and Configure a Failover Domain . Click Configure a Failover Domain . Clicking Configure a Failover Domain causes the display of failover domains under Configure a Failover Domain at the detailed menu for the cluster (below the clusters menu). At the detailed menu for the cluster (below the clusters menu), click the failover domain to modify. Clicking the failover domain causes the display of the Failover Domain Form page. At the Failover Domain Form page, you can modify the failover domain name, prioritize failover, restrict failover to this domain, and modify failover domain membership. Modifying failover name - To change the failover domain name, modify the text at the Failover Domain Name text box. Note The name should be descriptive enough to distinguish its purpose relative to other names used in your cluster. Failover priority - To enable or disable prioritized failover in this failover domain, click the Prioritized checkbox. With Prioritized checked, you can set the priority value, Priority , for each node selected as members of the failover domain. With Prioritized not checked, setting priority levels is disabled for this failover domain. Restricted failover - To enable or disable restricted failover for members in this failover domain, click the checkbox to Restrict failover to this domain's members . With Restrict failover to this domain's members checked, services assigned to this failover domain fail over only to nodes in this failover domain. With Restrict failover to this domain's members not checked, services assigned to this failover domain can fail over to nodes outside this failover domain. Modifying failover domain membership - Under Failover domain membership , click the Member checkbox for each node that is to be a member of the failover domain. A checked box for a node means that the node is a member of the failover domain. If Prioritized is checked, you can adjust the priority in the Priority text box for each member of the failover domain. Click Submit . Clicking Submit causes a progress page to be displayed followed by the display of the Failover Domain Form page. That page displays the added resource and includes the failover domain in the cluster menu to the left under Domain . To make additional changes to the failover domain, continue modifications at the Failover Domain Form page and click Submit when you are done.

Commands: