mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. Required Infrastructure Component Versions When you work with Red Hat build of Eclipse Vert.x, you can use the following components. However, Red Hat does not provide support for components listed below except Red Hat OpenShift cluster and Red Hat OpenJDK. Required components The following components are required to build and develop applications using Eclipse Vert.x. Component name Version Maven 3.6.0 or later JDK [a] 8, 11 or 17 [a] A full JDK installation is required, because JRE does not provide tools for compiling Java applications from source. Optional components Red Hat recommends using the following components depending on your development and production environments. Component name Version git 2.0 or later OpenShift Maven Plugin 1.1.1 oc command line tool 3.11 or later [a] Access to a Red Hat OpenShift cluster [b] 3.11 or later [a] The version of the oc CLI tool should correspond to the version of OCP that you are using. [b] OpenShiftCluster is supported by Red Hat

Commands:
5.164. libvirt-java 5.164.1. RHBA-2012:1075 - libvirt-java bug fix Updated libvirt-java packages that fix one bug are now available for Red Hat Enterprise Linux 6. The libvirt-java packages provide Java bindings to use libvirt, which is the virtualization API to manage and interact with virtualization capabilities. Bug Fix BZ# 836920 Prior to this update, the "setSchedulerParameters()" method for domains did not work as expected because the jna conversion was failing. This update modifies the conversion process. Now, the given parameter is used as expected. All users of libvirt-java are advised to upgrade to these updated packages, which fix this bug.

Commands:
23.2.3. Starting and Stopping the Server Important When the DHCP server is started for the first time, it fails unless the dhcpd.leases file exists. Use the command touch /var/lib/dhcp/dhcpd.leases to create the file if it does not exist. If the same server is also running BIND as a DNS server, this step is not necessary, as starting the named service automatically checks for a dhcpd.leases file. To start the DHCP service, use the command /sbin/service dhcpd start . To stop the DHCP server, use the command /sbin/service dhcpd stop . By default, the DHCP service does not start at boot time. To configure the daemon to start automatically at boot time, refer to Chapter 19, Controlling Access to Services for information on how to manage services. If more than one network interface is attached to the system, but the DHCP server should only be started on one of the interfaces, configure the DHCP server to start only on that device. In /etc/sysconfig/dhcpd , add the name of the interface to the list of DHCPDARGS : This is useful for a firewall machine with two network cards. One network card can be configured as a DHCP client to retrieve an IP address to the Internet. The other network card can be used as a DHCP server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users can not connect to the daemon via the Internet. Other command line options that can be specified in /etc/sysconfig/dhcpd include: -p <portnum> - Specify the UDP port number on which dhcpd should listen. The default is port 67. The DHCP server transmits responses to the DHCP clients at a port number one greater than the UDP port specified. For example, if the default port 67 is used, the server listens on port 67 for requests and responses to the client on port 68. If a port is specified here and the DHCP relay agent is used, the same port on which the DHCP relay agent should listen must be specified. Refer to Section 23.2.4, "DHCP Relay Agent" for details. -f - Run the daemon as a foreground process. This is mostly used for debugging. -d - Log the DHCP server daemon to the standard error descriptor. This is mostly used for debugging. If this is not specified, the log is written to /var/log/messages . -cf <filename> - Specify the location of the configuration file. The default location is /etc/dhcpd.conf . -lf <filename> - Specify the location of the lease database file. If a lease database file already exists, it is very important that the same file be used every time the DHCP server is started. It is strongly recommended that this option only be used for debugging purposes on non-production machines. The default location is /var/lib/dhcp/dhcpd.leases . -q - Do not print the entire copyright message when starting the daemon.

Commands:
Command line options here DHCPDARGS=eth0
7.227. setup 7.227.1. RHBA-2012:1367 - setup bug fix update Updated setup packages that fix three bugs are now available for Red Hat Enterprise Linux 6. The setup packages provide a set of important system configuration and setup files, such as passwd, group, and profile. Bug Fixes BZ#791140 Prior to this update, the "/etc/profile" script used a non-portable method for undefining the pathmunge() function. As a consequence, the script could encounter problems when using the korn shell (ksh). This update modifies the undefining method of the function to work more efficiently with alternative shells. BZ# 839410 , BZ# 860221 Prior to this update, the accounts for the haproxy system user, the jbosson-agentsystem user, and the jbosson system group were created with dynamic uid/gid assignment, which is not recommended for network daemons and for sensitive data. With this update, the static uid/gid pair 188:188 can be used to create these users and groups. All users of setup are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 1. About this tutorial The tutorial includes the following steps: Deploy a MySQL database server with a simple example database to OpenShift. Apply a custom resource in Streams for Apache Kafka to automatically build a Kafka Connect container image that includes the Debezium MySQL connector plug-in. Create the Debezium MySQL connector resource to capture changes in the database. Verify the connector deployment. View the change events that the connector emits to a Kafka topic from the database. Prerequisites You are familiar with OpenShift and Streams for Apache Kafka. You have access to an OpenShift cluster on which the cluster Operator is installed. The Streams for Apache Kafka Operator is running. An Apache Kafka cluster is deployed as documented in Deploying and Managing Streams for Apache Kafka on OpenShift . You have a Red Hat build of Debezium license. You know how to use OpenShift administration tools. The OpenShift oc CLI client is installed or you have access to the OpenShift Container Platform web console. Depending on how you intend to store the Kafka Connect build image, you must either have permission to access a container registry, or you must create an ImageStream resource on OpenShift: To store the build image in an image registry, such as Red Hat Quay.io or Docker Hub An account and permissions to create and manage images in the registry. To store the build image as a native OpenShift ImageStream An ImageStream resource is deployed to the cluster for storing new container images. You must explicitly create an ImageStream for the cluster. ImageStreams are not available by default. Additional resources: Managing image streams on OpenShift Container Platform .

Commands:
25.16. Logging in to an iSCSI Target As mentioned in Section 25.7, "iSCSI" , the iSCSI service must be running in order to discover or log into targets. To start the iSCSI service, run: When this command is executed, the iSCSI init scripts will automatically log into targets where the node.startup setting is configured as automatic . This is the default value of node.startup for all targets. To prevent automatic login to a target, set node.startup to manual . To do this, run the following command: Deleting the entire record will also prevent automatic login. To do this, run: To automatically mount a file system from an iSCSI device on the network, add a partition entry for the mount in /etc/fstab with the _netdev option. For example, to automatically mount the iSCSI device sdb to /mount/iscsi during startup, add the following line to /etc/fstab : To manually log in to an iSCSI target, use the following command: Note The proper_target_name and target_IP:port refer to the full name and IP address/port combination of a target. For more information, refer to Section 25.7.1, "iSCSI API" and Section 25.15, "Scanning iSCSI Interconnects" .

Commands:
systemctl start iscsi
iscsiadm -m node --targetname proper_target_name -p target_IP:port -o update -n node.startup -v manual
iscsiadm -m node --targetname proper_target_name -p target_IP:port -o delete
/dev/sdb /mnt/iscsi ext3 _netdev 0 0
iscsiadm -m node --targetname proper_target_name -p target_IP:port -l
7.92. iptables 7.92.1. RHBA-2013:0332 - iptables bug fix and enhancement update Updated iptables packages that fix several bugs and add two enhancements are now available for Red Hat Enterprise Linux 6. The iptables utility controls the network packet filtering code in the Linux kernel. Bug Fixes BZ#800208 The sysctl values for certain netfilter kernel modules, such as nf_conntrack and xt_conntrack, were not restored after a firewall restart. Consequently, the firewall did not always perform as expected after a restart. This update allows iptables to load sysctl settings on start if specified by the user in the /etc/sysctl.conf file. Users can now define sysctl settings to load on start and restart. BZ# 809108 The iptables(8) and ip6tables(8) man pages were previously missing information about the AUDIT target module, which allows creating audit records of the packet flow. This update adds the missing description of the audit support to these man pages. BZ#821441 The iptables and ip6tables commands did not correctly handle calculation of the maximum length of iptables chains. Consequently, when assigning a firewall rule to an iptables chain with a name longer than 28 characters, the iptables or ip6tables command terminated with a buffer overflow and the rule was not assigned. This update corrects the related code so that iptables and ip6tables now handle names of iptable chains correctly and a firewall rule is assigned in the described scenario as expected. BZ# 836286 The iptables init script calls the /sbin/restorecon binary when saving firewall rules so that the iptables packages depend on the policycoreutils packages. However, the iptables packages previously did not require the policycoreutils as a dependency. Consequently, the "/etc/init.d/iptables save" command failed if the policycoreutils packages were not installed on the system. This update modifies the iptables spec file to require the policycoreutils packages as its prerequisite and thus prevents this problem from occurring. Enhancements BZ#747068 The iptables packages has been modified to support the update-alternatives mechanism to allow easier delivery of new iptables versions for the MRG Realtime kernel. BZ#808272 Fallback mode has been added for the iptables and ip6tables services. A fallback firewall configuration can be stored in the /etc/sysconfig/iptables.fallback and /etc/sysconfig/ip6tables.fallback files in the iptables-save file format. The firewall rules from the fallback file are used if the service fails to apply the firewall rules from the /etc/sysconfig/iptables file (or the /etc/sysconfig/ip6tables file in case of ip6tables). All users of iptables are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
14.8. Displaying Image Information The info parameter displays information about a disk image filename . The format for the info option is as follows: This command is often used to discover the size reserved on disk which can be different from the displayed size. If snapshots are stored in the disk image, they are displayed also. This command will show for example, how much space is being taken by a qcow2 image on a block device. This is done by running the qemu-img . You can check that the image in use is the one that matches the output of the qemu-img info command with the qemu-img check command.

Commands:
qemu-img info [-f format ] filename
qemu-img info /dev/vg-90.100-sluo/lv-90-100-sluo image: /dev/vg-90.100-sluo/lv-90-100-sluo file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 0 cluster_size: 65536
B.15. device-mapper-multipath B.15.1. RHBA-2011:1485 - device-mapper-multipath bug fix update Updated device-mapper-multipath packages that fix one bug are now available for Red Hat Enterprise Linux 6 Extended Update Support. The device-mapper-multipath packages provide tools to manage multipath devices using the device-mapper multipath kernel module. Bug Fix BZ# 751079 If the multipath device was deleted while a path was being checked, multipathd did not abort the path check and terminated unexpectedly when trying to access the multipath device information. The multipathd daemon now aborts any path checks when the multipath device is removed and the problem no longer occurs. All users of device-mapper-multipath are advised to upgrade to these updated packages, which fix this bug.

Commands:
Preface Red Hat Enterprise Linux minor releases are an aggregation of individual enhancement, security and bug fix errata. The Red Hat Enterprise Linux 6.4 Release Notes documents the major changes made to the Red Hat Enterprise Linux 6 operating system and its accompanying applications for this minor release. Detailed notes on changes (that is, bugs fixed, enhancements added, and known issues found) in this minor release are available in the Technical Notes . The Technical Notes document also contains a complete list of all currently available Technology Previews along with packages that provide them. Important The online Red Hat Enterprise Linux 6.4 Release Notes , which are located online here , are to be considered the definitive, up-to-date version. Customers with questions about the release are advised to consult the online Release and Technical Notes for their version of Red Hat Enterprise Linux. Should you require information regarding the Red Hat Enterprise Linux life cycle, refer to https://access.redhat.com/support/policy/updates/errata/ .

Commands:
Chapter 9. Run Red Hat JBoss Data Grid in Library Mode This part includes information about using Red Hat JBoss Data Grid in Library Mode. As a prerequisite for the subsequent chapters, set up a new project using the instructions in Section 9.1, "Create a New Red Hat JBoss Data Grid Project" . , use JBoss Data Grid either as an embedded cache (see Chapter 10, Run Red Hat JBoss Data Grid in Library Mode (Single-Node Setup) for more information) or as a clustered cache (see Chapter 11, Run Red Hat JBoss Data Grid in Library Mode (Multi-Node Setup) . Each tutorial is based on an Infinispan quickstart. Finally, monitor Red Hat JBoss EAP applications using JBoss Data Grid using the instructions in Chapter 12, Monitor Red Hat JBoss Data Grid Applications in Red Hat JBoss EAP Report a bug 9.1. Create a New Red Hat JBoss Data Grid Project This chapter is a guide to creating a new Red Hat JBoss Data Grid project. The tasks prescribed are a prerequisite for the quickstart tasks provided in Chapter 10, Run Red Hat JBoss Data Grid in Library Mode (Single-Node Setup) and Chapter 11, Run Red Hat JBoss Data Grid in Library Mode (Multi-Node Setup) Report a bug

Commands:
8.3.2. Examining Transactions To display the summary of a single transaction, as root , use the yum history summary command in the following form: yum history summary id To examine a particular transaction or transactions in more detail, run the following command as root : yum history info id The id argument is optional and when you omit it, yum automatically uses the last transaction. Note that when specifying more than one transaction, you can also use a range: yum history info start_id .. end_id The following is sample output for two transactions, each installing one new package: You can also view additional information, such as what configuration options were used at the time of the transaction, or from what repository and why were certain packages installed. To determine what additional information is available for a certain transaction, type the following at a shell prompt as root : yum history addon-info id Similarly to yum history info , when no id is provided, yum automatically uses the latest transaction. Another way to see the latest transaction is to use the last keyword: yum history addon-info last For instance, for the first transaction in the example, the yum history addon-info command would provide the following output: In this example, three types of information are available: config-main - global Yum options that were in use during the transaction. See Section 8.4.1, "Setting [main] Options" for information on how to change global options. config-repos - options for individual Yum repositories. See Section 8.4.2, "Setting [repository] Options" for information on how to change options for individual repositories. saved_tx - the data that can be used by the yum load-transaction command in order to repeat the transaction on another machine (see below). To display selected type of additional information, run the following command as root : yum history addon-info id information

Commands:
~]# yum history info 4..5 Loaded plugins: product-id, refresh-packagekit, subscription-manager Transaction ID : 4..5 Begin time : Thu Jul 21 15:10:46 2011 Begin rpmdb : 1107:0c67c32219c199f92ed8da7572b4c6df64eacd3a End time : 15:33:15 2011 (22 minutes) End rpmdb : 1109:1171025bd9b6b5f8db30d063598f590f1c1f3242 User : Jaromir Hradilek <jhradilek> Return-Code : Success Command Line : install screen Command Line : install yum-plugin-security Transaction performed with: Installed rpm-4.8.0-16.el6.x86_64 Installed yum-3.2.29-17.el6.noarch Installed yum-metadata-parser-1.1.2-16.el6.x86_64 Packages Altered: Install screen-4.0.3-16.el6.x86_64 Install yum-plugin-security-1.1.30-17.el6.noarch history info
~]# yum history addon-info 4 Loaded plugins: product-id, refresh-packagekit, subscription-manager Transaction ID: 4 Available additional history information: config-main config-repos saved_tx history addon-info
9.4.3. Overriding or Augmenting Site Configuration Files It can be useful to override site defaults for a specific mount point on a client system. For example, consider the following conditions: Automounter maps are stored in NIS and the /etc/nsswitch.conf file has the following directive: The auto.master file contains the following The NIS auto.master map file contains the following: The NIS auto.home map contains the following: The file map /etc/auto.home does not exist. Given these conditions, let's assume that the client system needs to override the NIS map auto.home and mount home directories from a different server. In this case, the client will need to use the following /etc/auto.master map: The /etc/auto.home map contains the entry: Because the automounter only processes the first occurrence of a mount point, /home will contain the contents of /etc/auto.home instead of the NIS auto.home map. Alternatively, to augment the site-wide auto.home map with just a few entries, create an /etc/auto.home file map, and in it put the new entries. At the end, include the NIS auto.home map. Then the /etc/auto.home file map will look similar to: Given the NIS auto.home map listed above, ls /home would now output: This last example works as expected because autofs does not include the contents of a file map of the same name as the one it is reading. As such, autofs moves on to the map source in the nsswitch configuration.

Commands:
automount: files nis
+auto.master
/home auto.home
beth fileserver.example.com:/export/home/beth joe fileserver.example.com:/export/home/joe * fileserver.example.com:/export/home/&
/home \u00ad/etc/auto.home +auto.master
* labserver.example.com:/export/home/&
mydir someserver:/export/mydir +auto.home
beth joe mydir
2.6.5. Additional Resources More information about TCP Wrappers and xinetd is available from system documentation and on the Internet. 2.6.5.1. Installed TCP Wrappers Documentation The documentation on your system is a good place to start looking for additional configuration options for TCP Wrappers, xinetd , and access control. /usr/share/doc/tcp_wrappers- <version> / - This directory contains a README file that discusses how TCP Wrappers work and the various hostname and host address spoofing risks that exist. /usr/share/doc/xinetd- <version> / - This directory contains a README file that discusses aspects of access control and a sample.conf file with various ideas for modifying service-specific configuration files in the /etc/xinetd.d/ directory. TCP Wrappers and xinetd -related man pages - A number of man pages exist for the various applications and configuration files involved with TCP Wrappers and xinetd . The following are some of the more important man pages: Server Applications man xinetd - The man page for xinetd . Configuration Files man 5 hosts_access - The man page for the TCP Wrappers hosts access control files. man hosts_options - The man page for the TCP Wrappers options fields. man xinetd.conf - The man page listing xinetd configuration options.

Commands:
Chapter 28. File Systems NFS shares no longer become unresponsive after a TCP connection is closed Previously, NFS clients sometimes entered a 60 second TIME_WAIT period after initiating the TCP disconnect sequence. This happened only when TCP timestamps were disabled on the connection. During the waiting period, the client was unable to reconnect the NFS TCP connection. Due to waiting in the TIME_WAIT period, the NFS mount points were unresponsive, an rpciod kernel thread was using 100% CPU, and the retrans number in the output of the nfsstat -r command was becoming a very large number. In addition, NFS mounts with lower values of the timeo and retrans options could cause I/O errors. With this update, the NFS TCP connection is able to reconnect immediately after a disconnect sequence using a different source port. As a result, NFS mounts no longer become unresponsive and rpciod no longer causes a high system load after a connection is closed. (BZ#1479043)

Commands:
18.5.2. Prerouting If you have a server on your internal network that you want make available externally, you can use the -j DNAT target of the PREROUTING chain in NAT to specify a destination IP address and port where incoming packets requesting a connection to your internal service can be forwarded. For example, if you want to forward incoming HTTP requests to your dedicated Apache HTTP Server at 172.31.0.23, use the following command: This rule specifies that the nat table use the built-in PREROUTING chain to forward incoming HTTP requests exclusively to the listed destination IP address of 172.31.0.23. Note If you have a default policy of DROP in your FORWARD chain, you must append a rule to forward all incoming HTTP requests so that destination NAT routing is possible. To do this, use the following command: This rule forwards all incoming HTTP requests from the firewall to the intended destination; the Apache HTTP Server behind the firewall.

Commands:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 172.31.0.23:80
iptables -A FORWARD -i eth0 -p tcp --dport 80 -d 172.31.0.23 -j ACCEPT