mtpti5iD/redhat-docs_dataset huggingface dataset:
2.8.9.7. Additional Resources There are several aspects to firewalls and the Linux Netfilter subsystem that could not be covered in this chapter. For more information, see the following resources. 2.8.9.7.1. Useful Firewall Websites http://www.netfilter.org/ - The home of the netfilter/iptables project. Contains assorted information about iptables , including a FAQ addressing specific problems and various helpful guides by Rusty Russell, the Linux IP firewall maintainer. The HOWTO documents on the site cover subjects such as basic networking concepts, kernel packet filtering, and NAT configurations. http://www.tldp.org/ - The Linux Documentation Project contains several useful guides relating to firewall creation and administration. http://www.iana.org/assignments/port-numbers - The official list of registered and common service ports as assigned by the Internet Assigned Numbers Authority.

Commands:
Chapter 14. Managing container storage interface (CSI) component placements Each cluster consists of a number of dedicated nodes such as infra and storage nodes. However, an infra node with a custom taint will not be able to use OpenShift Data Foundation Persistent Volume Claims (PVCs) on the node. So, if you want to use such nodes, you can set tolerations to bring up csi-plugins on the nodes. Procedure Edit the configmap to add the toleration for the custom taint. Remember to save before exiting the editor. Display the configmap to check the added toleration. Example output of the added toleration for the taint, nodetype=infra:NoSchedule : Note Ensure that all non-string values in the Tolerations value field has double quotation marks. For example, the values true which is of type boolean, and 1 which is of type int must be input as "true" and "1". Restart the rook-ceph-operator if the csi-cephfsplugin- * and csi-rbdplugin- * pods fail to come up on their own on the infra nodes. Example : Verification step Verify that the csi-cephfsplugin- * and csi-rbdplugin- * pods are running on the infra nodes.

Commands:
oc edit configmap rook-ceph-operator-config -n openshift-storage
oc get configmap rook-ceph-operator-config -n openshift-storage -o yaml
apiVersion: v1 data: [...] CSI_PLUGIN_TOLERATIONS: | - key: nodetype operator: Equal value: infra effect: NoSchedule - key: node.ocs.openshift.io/storage operator: Equal value: "true" effect: NoSchedule [...] kind: ConfigMap metadata: [...]
oc delete -n openshift-storage pod <name of the rook_ceph_operator pod>
oc delete -n openshift-storage pod rook-ceph-operator-5446f9b95b-jrn2j pod "rook-ceph-operator-5446f9b95b-jrn2j" deleted
Linux Domain Identity, Authentication, and Policy Guide Red Hat Enterprise Linux 7 Using Red Hat Identity Management in Linux environments Florian Delehaye Red Hat Customer Content Services fdelehay@redhat.com Marc Muehlfeld Red Hat Customer Content Services Filip Hanzelka Red Hat Customer Content Services Lucie Manaskova Red Hat Customer Content Services Aneta Steflova Petrova Red Hat Customer Content Services Tomas Capek Red Hat Customer Content Services Ella Deon Ballard Red Hat Customer Content Services

Commands:
Chapter 1. Introduction 1.1. About the MTA plugin for Eclipse You can migrate and modernize applications by using the Migration Toolkit for Applications (MTA) plugin for Eclipse. The MTA plugin analyzes your projects using customizable rulesets, marks issues in the source code, provides guidance to fix the issues, and offers automatic code replacement, if possible. 1.2. About the Migration Toolkit for Applications What is the Migration Toolkit for Applications? Migration Toolkit for Applications (MTA) accelerates large-scale application modernization efforts across hybrid cloud environments on Red Hat OpenShift. This solution provides insight throughout the adoption process, at both the portfolio and application levels: inventory, assess, analyze, and manage applications for faster migration to OpenShift via the user interface. In MTA 7.1 and later, when you add an application to the Application Inventory , MTA automatically creates and executes language and technology discovery tasks. Language discovery identifies the programming languages used in the application. Technology discovery identifies technologies, such as Enterprise Java Beans (EJB), Spring, etc. Then, each task assigns appropriate tags to the application, reducing the time and effort you spend manually tagging the application. MTA uses an extensive default questionnaire as the basis for assessing your applications, or you can create your own custom questionnaire, enabling you to estimate the difficulty, time, and other resources needed to prepare an application for containerization. You can use the results of an assessment as the basis for discussions between stakeholders to determine which applications are good candidates for containerization, which require significant work first, and which are not suitable for containerization. MTA analyzes applications by applying one or more rulesets to each application considered to determine which specific lines of that application must be modified before it can be modernized. MTA examines application artifacts, including project source directories and application archives, and then produces an HTML report highlighting areas needing changes. How does the Migration Toolkit for Applications simplify migration? The Migration Toolkit for Applications looks for common resources and known trouble spots when migrating applications. It provides a high-level view of the technologies used by the application. MTA generates a detailed report evaluating a migration or modernization path. This report can help you to estimate the effort required for large-scale projects and to reduce the work involved.

Commands:
Chapter 59. JmxTransQueryTemplate schema reference Used in: JmxTransSpec Property Description targetMBean If using wildcards instead of a specific MBean then the data is gathered from multiple MBeans. Otherwise if specifying an MBean then data is gathered from that specified MBean. string attributes Determine which attributes of the targeted MBean should be included. string array outputs List of the names of output definitions specified in the spec.kafka.jmxTrans.outputDefinitions that have defined where JMX metrics are pushed to, and in which data format. string array

Commands:
14.4. Running Subsystems under a Java Security Manager Java services have the option of having a Security Manager which defines unsafe and safe operations for applications to perform. When the subsystems are installed, they have the Security Manager enabled automatically, meaning each Tomcat instance starts with the Security Manager running. 14.4.1. About the Security Manager Policy Files When the five Java subsystems (the CA, OCSP, KRA, TKS, and TPS) run within the Java Security Manager, they use a combination of three sets of policies: The catalina.policy file from the default Tomcat policy located in the /usr/share/tomcat/conf directory; this is updated whenever the general Tomcat files are updated. A pki.policy file, in the /var/lib/pki/ instance_name / subsystem_type /conf directory, that is supplied with the subsystem instance. A custom.policy file, in the /var/lib/pki/ instance_name / subsystem_type /conf directory, that contains user-defined security policies. These three files are concatenated together whenever the Tomcat service starts to create a revised catalina.policy file, also in the /var/lib/pki/ instance_name / subsystem_type /conf directory, which is used for the instance. The default pki.policy file contains permissions that grant unrestricted access to the Tomcat, LDAP, and symkey services used by the PKI subsystems. For example: // These permissions apply to Tomcat java as utilized by PKI instances grant codeBase "file:/usr/share/java/tomcat/-" { permission java.security.AllPermission; }; The custom.policy file is empty by default; administrators can write policies in that file which will be used in addition to the given PKI policies and Tomcat policies. 14.4.2. Starting a Subsystem Instance without the Java Security Manager All Java subsystems configured under a PKI Tomcat instance are automatically run under a Java Security Manager (unless the instance was created by overriding pki_security_manager=true under the [Tomcat] section in the /etc/pki/default.cfg file). However, it is possible to start or restart an instance and run it without starting the Java Security Manager, as shown below. Procedure 14.1. Starting an Instance Without the Java Security Manager Stop the instance. Edit the /etc/sysconfig/ instance_name file and turn off the security manager: Start the instance.

Commands:
// These permissions apply to Tomcat java as utilized by PKI instances grant codeBase "file:/usr/share/java/tomcat/-" { permission java.security.AllPermission; };
pki-server stop instance_name
SECURITY_MANAGER="false"
pki-server start instance_name
Chapter 84. KafkaClientAuthenticationScramSha256 schema reference Used in: KafkaBridgeSpec , KafkaConnectSpec , KafkaMirrorMaker2ClusterSpec , KafkaMirrorMakerConsumerSpec , KafkaMirrorMakerProducerSpec Full list of KafkaClientAuthenticationScramSha256 schema properties To configure SASL-based SCRAM-SHA-256 authentication, set the type property to scram-sha-256 . The SCRAM-SHA-256 authentication mechanism requires a username and password. Example SASL-based SCRAM-SHA-256 client authentication configuration for Kafka Connect authentication: type: scram-sha-256 username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-connect-password-field In the passwordSecret property, specify a link to a Secret containing the password. You can use the secrets created by the User Operator. If required, you can create a text file that contains the password, in cleartext, to use for authentication: echo -n <password> > <my_password>.txt You can then create a Secret from the text file, setting your own field name (key) for the password: oc create secret generic <my-connect-secret-name> --from-file=<my_password_field_name>=./<my_password>.txt Example secret for SCRAM-SHA-256 client authentication for Kafka Connect apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-connect-password-field: LFTIyFRFlMmU2N2Tm The secretName property contains the name of the Secret , and the password property contains the name of the key under which the password is stored inside the Secret . Important Do not specify the actual password in the password property. 84.1. KafkaClientAuthenticationScramSha256 schema properties Property Property type Description type string Must be scram-sha-256 . username string Username used for the authentication. passwordSecret PasswordSecretSource Reference to the Secret which holds the password.

Commands:
authentication: type: scram-sha-256 username: my-connect-username passwordSecret: secretName: my-connect-secret-name password: my-connect-password-field
echo -n <password> > <my_password>.txt
create secret generic <my-connect-secret-name> --from-file=<my_password_field_name>=./<my_password>.txt
apiVersion: v1 kind: Secret metadata: name: my-connect-secret-name type: Opaque data: my-connect-password-field: LFTIyFRFlMmU2N2Tm
Chapter 13. 4.10 Release Notes 13.1. New Features The following major enhancements have been introduced in Red Hat Update Infrastructure 4.10. Support for on-demand synchronization policy for content It is now possible to set the synchronization of RPM, Source, and Debug repositories separately as either 'immediate' or 'on-demand'. When 'on-demand' is selected, content is downloaded only when requested by the end client. This option is generally useful for source and debug content, as they are not widely used. As a result, the amount of content stored by RHUI can drop significantly. You can configure this in /etc/rhui/rhui-tools.conf . The mandatory option is to set the default_sync_policy to either 'immediate' or 'on-demand'. Optionally, you can override this setting by specifying rpm_sync_policy , source_sync_policy , and/or debug_sync_policy . Note RHUI will need to download missing content on the fly, so a good connection to the Red Hat CDN is preferred to ensure a smooth client experience. Support for CDS in containers added as a TECHNICAL PREVIEW It is now possible to add a CDS node that runs in a container. Use rhui-manager cds add_container --help for more information. Further details will be available in the Administration Guide. Change in nginx SSL certificate naming Previously, the CDS nginx SSL certificate name included the CDS DNS hostname, making it specific to each CDS node. A change has been made so that all CDS nodes now share a common SSL certificate with the same name. 13.2. Known Issues This part describes known issues in Red Hat Update Infrastructure 4.10. Reapplying CDS configurations does not regenerate SSL certificates is a new CA is used Currently, when you reinstall RHUI with a new Certificate Authority (CA) and then you want to reinstall CDS nodes to use the new CA, the SSL certificate for the CDS nodes remains unchanged, whereas it should be regenerated. To work around this problem, remove the old SSL files (everything in /var/lib/rhui/remote_share/cds-config/ssl/ ) and then reinstall the CDS nodes (with rhui-manager cds reinstall --all ).

Commands:
1.9.2.2. Cluster Status Tool You can access the Cluster Status Tool ( Figure 1.29, " Cluster Status Tool " ) through the Cluster Management tab in Cluster Administration GUI. Figure 1.29. Cluster Status Tool The nodes and services displayed in the Cluster Status Tool are determined by the cluster configuration file ( /etc/cluster/cluster.conf ). You can use the Cluster Status Tool to enable, disable, restart, or relocate a high-availability service.

Commands:
7.11. authconfig 7.11.1. RHBA-2015:0760 - authconfig bug fix update Updated authconfig packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The authconfig packages contain a command line utility and a GUI application that can configure a workstation to be a client for certain network user information and authentication schemes and other user information and authentication related options. Bug Fixes BZ# 1145137 Prior to this update, it was not possible to specify multiple Lightweight Directory Access Protocol (LDAP) servers with the authconfig command. This bug has been fixed, and multiple LDAP servers can now be specified as expected. BZ# 1194397 Previously, the authconfig utility did not pass passwords provided by the "--winbindjoin" option when calling "net join". Consequently, the user was asked for a password. Now, passwords are passed by authconfig to "net join" automatically, and users do not have to provide them in this situation. Users of authconfig are advised to upgrade to these updated packages, which fix these bugs.

Commands:
A.4. Enabling/Disabling Quota Enforcement In GFS2 file systems, quota enforcement is disabled by default. To enable quota enforcement for a file system, mount the file system with the quota=on option specified. Usage To mount a file system with quota enforcement disabled, mount the file system with the quota=off option specified. This is the default setting. -o quota={on|off} Specifies that quota enforcement is enabled or disabled when the file system is mounted. BlockDevice Specifies the block device where the GFS2 file system resides. MountPoint Specifies the directory where the GFS2 file system should be mounted. Examples In this example, the GFS2 file system on /dev/vg01/lvol0 is mounted on the /mygfs2 directory with quota enforcement enabled.

Commands:
mount -o quota=on BlockDevice MountPoint
mount -o quota=off BlockDevice MountPoint
mount -o quota=on /dev/vg01/lvol0 /mygfs2
Chapter 9. Monitoring a high availability Red Hat Ceph Storage cluster When you deploy an overcloud with Red Hat Ceph Storage, Red Hat OpenStack Platform uses the ceph-mon monitor daemon to manage the Ceph cluster. Director deploys the daemon on all Controller nodes. View the status of the Ceph Monitoring service On a Controller node, run the service ceph status command to check that the Ceph Monitoring service is running: View Ceph Monitoring configuration On a Controller nodes or on a Ceph node, open the /etc/ceph/ceph.conf file to view the monitoring configuration parameters: This example shows the following information: All three Controller nodes are configured to monitor the Red Hat Ceph Storage cluster with the mon_initial_members parameter. The 172.19.0.11/24 network is configured to provide a communication path between the Controller nodes and the Red Hat Ceph Storage nodes. The Red Hat Ceph Storage nodes are assigned to a separate network from the Controller nodes, and the IP addresses for the monitoring Controller nodes are 172.18.0.15 , 172.18.0.16 , and 172.18.0.17 . View individual Ceph node status Log in to the Ceph node and run the ceph -s command: This example output shows that the health parameter value is HEALTH_OK , which indicates that the Ceph node is active and healthy. The output also shows three Ceph monitor services that are running on the three overcloud-controller nodes and the IP addresses and ports of the services. For more information about Red Hat Ceph Storage, see the Red Hat Ceph product page .

Commands:
sudo service ceph status === mon. overcloud-controller-0 === mon. overcloud-controller-0 : running {"version":"0.94.1"}
[global] osd_pool_default_pgp_num = 128 osd_pool_default_min_size = 1 auth_service_required = cephx mon_initial_members = overcloud-controller-0 , overcloud-controller-1 , overcloud-controller-2 fsid = 8c835acc-6838-11e5-bb96-2cc260178a92 cluster_network = 172.19.0.11/24 auth_supported = cephx auth_cluster_required = cephx mon_host = 172.18.0.17,172.18.0.15,172.18.0.16 auth_client_required = cephx osd_pool_default_size = 3 osd_pool_default_pg_num = 128 public_network = 172.18.0.17/24
ceph -s cluster 8c835acc-6838-11e5-bb96-2cc260178a92 health HEALTH_OK monmap e1: 3 mons at { overcloud-controller-0 =172.18.0.17:6789/0, overcloud-controller-1 =172.18.0.15:6789/0, overcloud-controller-2 =172.18.0.16:6789/0} election epoch 152, quorum 0,1,2 overcloud-controller-1 , overcloud-controller-2 , overcloud-controller-0 osdmap e543: 6 osds: 6 up, 6 in pgmap v1736: 256 pgs, 4 pools, 0 bytes data, 0 objects 267 MB used, 119 GB / 119 GB avail 256 active+clean
23.4. Additional Resources For configuration options not covered here, refer to the following resources. 23.4.1. Installed Documentation dhcpd man page - Describes how the DHCP daemon works. dhcpd.conf man page - Explains how to configure the DHCP configuration file; includes some examples. dhcpd.leases man page - Explains how to configure the DHCP leases file; includes some examples. dhcp-options man page - Explains the syntax for declaring DHCP options in dhcpd.conf ; includes some examples. dhcrelay man page - Explains the DHCP Relay Agent and its configuration options. /usr/share/doc/dhcp-< version >/ - Contains sample files, README files, and release notes for the specific version of the DHCP service.

Commands:
22.3. Booleans SELinux is based on the least level of access required for a service to run. Services can be run in a variety of ways; therefore, you need to specify how you run your services. Use the following Booleans to set up SELinux: rsync_anon_write Having this Boolean enabled allows rsync in the rsync_t domain to manage files, links and directories that have a type of public_content_rw_t . Often these are public files used for public file transfer services. Files and directories must be labeled this type. rsync_client Having this Boolean enabled allows rsync to initiate connections to ports defined as rsync_port_t , as well as allowing the daemon to manage files, links, and directories that have a type of rsync_data_t . Note that rsync must be in the rsync_t domain in order for SELinux to enact its control over it. The configuration example in this chapter demonstrates rsync running in the rsync_t domain. rsync_export_all_ro Having this Boolean enabled allows rsync in the rsync_t domain to export NFS and CIFS volumes with read-only access to clients. Note Due to the continuous development of the SELinux policy, the list above might not contain all Booleans related to the service at all times. To list them, enter the following command: Enter the following command to view description of a particular Boolean: Note that the additional policycoreutils-devel package providing the sepolicy utility is required for this command to work.

Commands:
~]USD getsebool -a | grep service_name
~]USD sepolicy booleans -b boolean_name
Chapter 12. Distribution Options Red Hat Enterprise Linux offers three methods of distribution for third-party applications. RPM Packages RPM Packages are the traditional method of distributing and installing software. RPM Packages are a mature technology with multiple tools and widely disseminated knowledge. Applications are installed as part of the system. The installation tools greatly assist in resolving dependencies. Note Only one version of a package can be installed, making multiple application version installations difficult. To create an RPM package, follow the instructions in the RPM Packaging Guide, Packaging Software . Software Collections A Software Collection is a specially prepared RPM package for an alternative version of an application. A Software Collection is a packaging method used and supported by Red Hat. It is built on top of the RPM package mechanism. Multiple versions of an application can be installed at once. For more information, see Red Hat Software Collections Packaging Guide, What Are Software Collections? To create a software collection package, follow the instructions in the Red Hat Software Collections Packaging Guide, Packaging Software Collections . Containers Docker-formatted containers are a lightweight virtualization method. Applications can be present in multiple independent versions and instances. They can be prepared easily from an RPM package or Software Collection. Interaction with the system can be precisely controlled. Isolation of the application increases security. Containerizing applications or their components enables the orchestration of multiple instances. Additional Resources Red Hat Software Collections Packaging Guide - What Are Software Collections?

Commands:
7.4. Setting Up a Root Certificate Authority The Certificate Authority (CA) subsystem is the prerequisite for all other Certificate System subsystems. Therefore, set up the CA before configuring other subsystems. To set up a root CA in Certificate System, you have the following options: Configuration file-based installation: Use this method for high-level customization. This installation method uses a configuration file that overrides the default installation parameters. You can install Certificate System using a configuration file in a single step or in two steps. For details and examples, see: The pkispawn (8) man page for the single-step installation. Section 7.7, "Two-step Installation" for the two-step installation. Interactive installation: Use the interactive installer if you only want to set the minimum of required configuration options.

Commands:
pkispawn -s CA