mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 24. Storage dm-era Device Mapper The device-mapper-persistent-data package now provides tools to help use the new dm-era device mapper functionality released as a Technology Preview. The dm-era functionality keeps track of which blocks on a device were written within user-defined periods of time called an era . This functionality allows backup software to track changed blocks or restore the coherency of a cache after reverting changes. DIF/DIX support DIF/DIX, is a new addition to the SCSI Standard and a Technology Preview in Red Hat Enterprise Linux 6. DIF/DIX increases the size of the commonly used 512-byte disk block from 512 to 520 bytes, adding the Data Integrity Field (DIF). The DIF stores a checksum value for the data block that is calculated by the Host Bus Adapter (HBA) when a write occurs. The storage device then confirms the checksum on receive, and stores both the data and the checksum. Conversely, when a read occurs, the checksum can be checked by the storage device, and by the receiving HBA. The DIF/DIX hardware checksum feature must only be used with applications that exclusively issue O_DIRECT I/O. These applications may use the raw block device, or the XFS file system in O_DIRECT mode. (XFS is the only file system that does not fall back to buffered I/O when doing certain allocation operations.) Only applications designed for use with O_DIRECT I/O and DIF/DIX hardware should enable this feature. For more information, refer to section Block Devices with DIF/DIX Enabled in the Storage Administration Guide . Package: kernel-2.6.32-642 LVM Application Programming Interface (API) Red Hat Enterprise Linux 6 features the new LVM application programming interface (API) as a Technology Preview. This API is used to query and control certain aspects of LVM. Package: lvm2-2.02.143-7

Commands:
Chapter 48. Mirroring a network interface by using nmcli Network administrators can use port mirroring to replicate inbound and outbound network traffic being communicated from one network device to another. Mirroring traffic of an interface can be helpful in the following situations: To debug networking issues and tune the network flow To inspect and analyze the network traffic To detect an intrusion Prerequisites A network interface to mirror the network traffic to. Procedure Add a network connection profile that you want to mirror the network traffic from: Attach a prio qdisc to enp1s0 for the egress (outgoing) traffic with the 10: handle: The prio qdisc attached without children allows attaching filters. Add a qdisc for the ingress traffic, with the ffff: handle: Add the following filters to match packets on the ingress and egress qdiscs , and to mirror them to enp7s0 : The matchall filter matches all packets, and the mirred action redirects packets to destination. Activate the connection: Verification Install the tcpdump utility: Display the traffic mirrored on the target device ( enp7s0 ): Additional resources How to capture network packets using tcpdump (Red Hat Knowledgebase)

Commands:
nmcli connection add type ethernet ifname enp1s0 con-name enp1s0 autoconnect no
nmcli connection modify enp1s0 +tc.qdisc "root prio handle 10:"
nmcli connection modify enp1s0 +tc.qdisc "ingress handle ffff:"
nmcli connection modify enp1s0 +tc.tfilter "parent ffff: matchall action mirred egress mirror dev enp7s0 " nmcli connection modify enp1s0 +tc.tfilter "parent 10: matchall action mirred egress mirror dev enp7s0 "
nmcli connection up enp1s0
yum install tcpdump
tcpdump -i enp7s0
3.2. JDBC Statement Extensions The JBoss Data Virtualization statement interface, org.teiid.jdbc.TeiidStatement , provides functionality beyond the JDBC standard. To use this interface, cast or unwrap the statement returned by the connection. The interface provides the following methods for setting and retrieving statement properties: Table 3.1. Statement Properties Method Name Description getAnnotations This method has been deprecated. Use the SHOW statement. getDebugLog This method has been deprecated. Use the SHOW statement. getExecutionProperty This method has been deprecated. Use the SHOW statement. getPlanDescription Get the query plan description if the statement was last executed with SHOWPLAN ON|DEBUG. The plan is a tree made up of org.teiid.client.plan.PlanNode objects. Typically PlanNode.toString() or PlanNode.toXml() will be used to convert the plan into a textual form. getRequestIdentifier Get an identifier for the last command executed on this statement. If no command has been executed yet, null is returned. setExecutionProperty Note This method has been deprecated. Use the SET statement. setPayload Set a per-command payload to pass to translators. Currently the only built-in use is for sending hints for an Oracle data source.

Commands:
3.5.2. Creating GPG Keys in KDE To create a GPG Key in KDE, follow these steps: Start the KGpg program from the main menu by selecting Applications Utilities Encryption Tool . If you have never used KGpg before, the program walks you through the process of creating your own GPG keypair. A dialog box appears prompting you to create a new key pair. Enter your name, email address, and an optional comment. You can also choose an expiration time for your key, as well as the key strength (number of bits) and algorithms. Enter your passphrase in the dialog box. At this point, your key appears in the main KGpg window. Warning If you forget your passphrase, you will not be able to decrypt the data. To find your GPG key ID, look in the Key ID column to the newly created key. In most cases, if you are asked for the key ID, prepend 0x to the key ID, as in 0x6789ABCD . You should make a backup of your private key and store it somewhere secure.

Commands:
18.14. Setting vLAN Tags virtual local area network (vLAN) tags are added using the virsh net-edit command. This tag can also be used with PCI device assignment with SR-IOV devices. For more information, refer to Section 9.1.7, "Configuring PCI Assignment (Passthrough) with SR-IOV Devices" . <network> <name>ovs-net</name> <forward mode='bridge'/> <bridge name='ovsbr0'/> <virtualport type='openvswitch'> <parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/> </virtualport> <vlan trunk='yes'> <tag id='42' nativeMode='untagged'/> <tag id='47'/> </vlan> <portgroup name='dontpanic'> <vlan> <tag id='42'/> </vlan> </portgroup> </network> Figure 18.30. vSetting VLAN tag (on supported network types only) If (and only if) the network type supports vlan tagging transparent to the guest, an optional <vlan> element can specify one or more vlan tags to apply to the traffic of all guests using this network. (openvswitch and type='hostdev' SR-IOV networks do support transparent VLAN tagging of guest traffic; everything else, including standard linux bridges and libvirt's own virtual networks, do not support it. 802.1Qbh (vn-link) and 802.1Qbg (VEPA) switches provide their own way (outside of libvirt) to tag guest traffic onto specific vlans.) As expected, the tag attribute specifies which vlan tag to use. If a network has more than one <vlan> element defined, it is assumed that the user wants to do VLAN trunking using all the specified tags. In the case that VLAN trunking with a single tag is desired, the optional attribute trunk='yes' can be added to the VLAN element. For network connections using openvswitch it is possible to configure the 'native-tagged' and 'native-untagged' VLAN modes. This uses the optional nativeMode attribute on the <tag> element: nativeMode may be set to 'tagged' or 'untagged'. The id attribute of the element sets the native vlan. <vlan> elements can also be specified in a <portgroup> element, as well as directly in a domain's <interface> element. In the case that a vlan tag is specified in multiple locations, the setting in <interface> takes precedence, followed by the setting in the <portgroup> selected by the interface config. The <vlan> in <network> will be selected only if none is given in <portgroup> or <interface> .

Commands:
<network> <name>ovs-net</name> <forward mode='bridge'/> <bridge name='ovsbr0'/> <virtualport type='openvswitch'> <parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/> </virtualport> <vlan trunk='yes'> <tag id='42' nativeMode='untagged'/> <tag id='47'/> </vlan> <portgroup name='dontpanic'> <vlan> <tag id='42'/> </vlan> </portgroup> </network>
Chapter 3. Dynamically provisioned OpenShift Data Foundation deployed on Microsoft Azure 3.1. Replacing operational or failed storage devices on Azure installer-provisioned infrastructure When you need to replace a device in a dynamically created storage cluster on an Azure installer-provisioned infrastructure, you must replace the storage node. For information about how to replace nodes, see: Replacing operational nodes on Azure installer-provisioned infrastructure . Replacing failed nodes on Azure installer-provisioned infrastructures .

Commands:
8.5. Disabling a Monitor Operation The easiest way to stop a recurring monitor is to delete it. However, there can be times when you only want to disable it temporarily. In such cases, add enabled="false" to the operation's definition with the pcs resource update command. When you want to reinstate the monitoring operation, set enabled="true" to the operation's definition. When you update a resource's operation with the pcs resource update command, any options you do not specifically call out are reset to their default values. For example, if you have configured a monitoring operation with a custom timeout value of 600, running the following commands will reset the timeout value to the default value of 20 (or whatever you have set the default value to with the pcs resource ops default command). In order to maintain the original value of 600 for this option, when you reinstate the monitoring operation you must specify that value, as in the following example.

Commands:
pcs resource update resourceXZY op monitor enabled=false pcs resource update resourceXZY op monitor enabled=true
pcs resource update resourceXZY op monitor timeout=600 enabled=true
B.16.2. RHSA-2011:0256 - Moderate: dhcp security update Updated dhcp packages that fix one security issue are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. A 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 Dynamic Host Configuration Protocol (DHCP) is a protocol that allows individual devices on an IP network to get their own network configuration information, including an IP address, a subnet mask, and a broadcast address. DHCPv6 is the DHCP protocol version for IPv6 networks. CVE-2011-0413 A flaw was found in the way the dhcpd daemon processed certain DHCPv6 messages for addresses that had previously been declined and marked as abandoned internally. If a remote attacker sent such messages to dhcpd, it could cause dhcpd to crash due to an assertion failure if it was running as a DHCPv6 server. Red Hat would like to thank Internet Systems Consortium for reporting this issue. Users running dhcpd as a DHCPv6 server should upgrade to these updated packages, which contain a backported patch to correct this issue. After installing this update, all DHCP servers will be restarted automatically.

Commands:
10.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. 10.2.1. Creating Self-Service Rules from the Web UI On the IPA Server tab in the top menu, select the Role-Based Access Control Self Service Permissions subtab. Click Add at the top of the list of the self-service access control instructions. Figure 10.1. Adding a Current Self-Service Rule Enter the name of the rule in the pop-up window. Spaces are allowed. Figure 10.2. Form for Adding a Self-Service Rule Select the check boxes by the attributes which this ACI will permit users to edit. Click the Add button to save the new self-service ACI. 10.2.2. Creating Self-Service Rules from the Command Line A new self-service rule can be added using the selfservice-add command. These two options are required: --permissions to set which permissions - such as write, add, or delete - the ACI grants --attrs to give the full list of attributes which this ACI grants permission to. 10.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 check boxes can be selected or deselected. Figure 10.3. 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:
[jsmith@server ~]USD ipa selfservice-add "Users can manage their own name details" --permissions=write --attrs=givenname --attrs=displayname --attrs=title --attrs=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
[jsmith@server ~]USD ipa selfservice-mod "Users can manage their own name details" --attrs=givenname --attrs=displayname --attrs=title --attrs=initials --attrs=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
2.6.3. xinetd The xinetd daemon is a TCP-wrapped super service which controls access to a subset of popular network services, including FTP, IMAP, and Telnet. It also provides service-specific configuration options for access control, enhanced logging, binding, redirection, and resource utilization control. When a client attempts to connect to a network service controlled by xinetd , the super service receives the request and checks for any TCP Wrappers access control rules. If access is allowed, xinetd verifies that the connection is allowed under its own access rules for that service. It also checks that the service is able to have more resources assigned to it and that it is not in breach of any defined rules. If all these conditions are met (that is, access is allowed to the service; the service has not reached its resource limit; and the service is not in breach of any defined rule), xinetd then starts an instance of the requested service and passes control of the connection to it. After the connection has been established, xinetd takes no further part in the communication between the client and the server.

Commands:
Chapter 5. Certification workflow for non-containerized application Note Red Hat recommends that you are a Red Hat Certified Engineer or hold equivalent experience before starting the certification process. Task Summary The certification workflow includes three primary stages - Section 5.1, "Certification onboarding" Section 5.2, "Certification testing" Section 5.3, "Publishing the certified or validated application" 5.1. Certification onboarding Perform the steps outlined for certification onboarding: Join the Red Hat Connect for Technology Partner Program. Agree to the program terms and conditions. Create your product listing by selecting your desired product category. You can select from the available product categories: Containerized Application Standalone Application OpenStack Infrastructure Complete your company profile. Add components to the product listing. Certify components for your product listing. Additional resources For detailed instructions about creating your first product listing, see Creating a product . 5.2. Certification testing Follow these high-level steps to run a certification test: Log in to the Red Hat Certification portal . Download the test plan. Configure the system under test (SUT) for running the tests. Download the test plan to our SUT. Run the certification tests on your system. Review and upload the test results to the certification portal. Additional resources For detailed instructions about certification testing, see Setting up the test environment for non-containerized application testing . 5.3. Publishing the certified or validated application The Partner Validated or Certified application must be added to your product's Product Listing page on the Red Hat Partner Connect portal. Once published, your product listing is displayed on the Red Hat Ecosystem Catalog , by using the product information that you provide. You can publish both the Partner Validated and Certified application on the Red Hat Ecosystem Catalog with the respective labels.

Commands:
Chapter 1. Prerequisites to get started This guide covers concepts as well as practical details needed by developers to use the Eclipse Vert.x runtime. As an application developer, you can use Eclipse Vert.x to create microservices-based applications written in Java that run in OpenShift environments. This guide shows you how to create, package, run and test a simple Eclipse Vert.x project. Prerequisites OpenJDK 8 or OpenJDK 11 is installed and the JAVA_HOME environment variable specifies the location of the Java SDK. Log in to the Red Hat Customer Portal to download Red Hat build of Open JDK from the Software Downloads . Apache Maven 3.6.0 or higher is installed. You can download Maven from the Apache Maven Project website.

Commands:
26.7. Configuring OCSP Responders Every CA integrated with the IdM server uses an internal online certificate status protocol (OCSP) responder. The IdM service allowing to access the OCSP responders is available at http:// ca-server.example.com /ca/ocsp . Clients can connect to this URL to check the validity of a certificate. Note For details on OCSP, see the Red Hat Certificate System documentation. For example, 2.2.4. Revoking Certificates and Checking Status in the Planning, Installation, and Deployment Guide . 26.7.1. Changing the CRL Update Interval The CRL file is automatically generated by the IdM CA every four hours by default. To change this interval: Stop the CA server. Open the /var/lib/pki/pki-tomcat/conf/ca/CS.cfg file, and change the ca.crl.MasterCRL.autoUpdateInterval value to the new interval setting. For example, to generate the CRL every 60 minutes: Note If you update the ca.crl.MasterCRL.autoUpdateInterval parameter, the change will become effective after the already scheduled CRL update. Start the CA server.

Commands:
systemctl stop pki-tomcatd@pki-tomcat.service
ca.crl.MasterCRL.autoUpdateInterval=60
systemctl start pki-tomcatd@pki-tomcat.service
Appendix B. Revision History The revision numbers below relate to the edition of this manual, not to version numbers of Red Hat Enterprise Linux. Version Date and change Author 7.0-11 Oct 15 2019: Added troubleshooting appendix. Marc Muehlfeld 7.0-10 Sep 26 2019: Added Granting and Restricting Access to SSSD Containers Using HBAC Rules . Marc Muehlfeld 7.0-9 Aug 23 2019: Updated introduction of Configuring the SSSD Container to Provide Identity and Authentication Services on Atomic Host . Marc Muehlfeld 7.0-8 Apr 05 2018: Preparing document for 7.5 GA publication. Lucie Manaskova 7.0-7 Mar 19 2018: Updated Deploying sssd containers with different configurations. Lucie Manaskova 7.0-6 Jan 29 2018: Minor fixes. Aneta Steflova Petrova 7.0-5 Nov 20 2017: Updated Enrolling to an Identity Management Domain Using an SSSD Container . Aneta Steflova Petrova 7.0-4 Sep 12 2017: Added a procedure for uninstalling an SSSD container joined to an AD domain. Aneta Steflova Petrova 7.0-3 Aug 28 2017: Updated part Using the sssd container with more user stories and fixes. Aneta Steflova Petrova 7.0-2 Aug 14 2017: Updated sections Available Container Images and Joining an Active Directory Domain Using an SSSD Container . Aneta Steflova Petrova 7.0-1 Jul 18 2017: Document version for 7.4 GA publication. Aneta Steflova Petrova

Commands:
function::regparm Name function::regparm - Specify regparm value used to compile function Synopsis Arguments n original regparm value Description Call this function with argument n before accessing function arguments using the *_arg function is the function was build with the gcc -mregparm=n option. (The i386 kernel is built with \-mregparm=3, so systemtap considers regparm(3) the default for kernel functions on that architecture.) Only valid on i386 and x86_64 (when probing 32bit applications). Produces an error on other architectures.

Commands:
regparm(n:long)
Chapter 15. Disabling Multicloud Object Gateway external service after deploying OpenShift Data Foundation When you deploy OpenShift Data Foundation, public IPs are created even when OpenShift is installed as a private cluster. However, you can disable the Multicloud Object Gateway (MCG) load balancer usage by using the disableLoadBalancerService variable in the storagecluster CRD. This restricts MCG from creating any public resources for private clusters and helps to disable the NooBaa service EXTERNAL-IP . Procedure Run the following command and add the disableLoadBalancerService varialbe in the storagecluster YAML to set the service to ClusterIP: Note To undo the changes and set the service to LoadBalancer, set the disableLoadBalancerService variable to false or remove that line completely.

Commands:
oc edit storagecluster -n openshift-storage <storagecluster_name> [...] spec: arbiter: {} encryption: kms: {} externalStorage: {} managedResources: cephBlockPools: {} cephCluster: {} cephConfig: {} cephDashboard: {} cephFilesystems: {} cephNonResilientPools: {} cephObjectStoreUsers: {} cephObjectStores: {} cephRBDMirror: {} cephToolbox: {} mirroring: {} multiCloudGateway: disableLoadBalancerService: true <--------------- Add this endpoints: [...]