mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 19. General Updates resource-agents-sap-hana shipped in an incorrect channel The resource-agents-sap-hana package has been available as part of the High Availability Add-On in Red Hat Enterprise Linux 6.7 and 6.8. However, asynchronous updates for this package were made available through the Red Hat Enterprise Linux for SAP HANA repository. Consequently, package updates on systems that do not enable both the Red Hat Enterprise Linux High Availability Add-On and Red Hat Enterprise Linux for SAP HANA repositories can fail. To avoid this problem, enable both the RHEL for SAP HANA and Red Hat Enterprise Linux High Availability channels in Red Hat Subscription Manager, Red Hat Network, or Red Hat Network Satellite prior to updating any applicable systems. If you do not have access to SAP HANA content, remove the resource-agents-sap-hana package by running the rpm -e command. (BZ#1334776) Incorrect information about the expected default settings of services in Red Hat Enterprise Linux 7 The module of Preupgrade Assistant that handles initscripts provides incorrect information about the expected default settings of the services in Red Hat Enterprise Linux 7 according to the /usr/lib/systemd/system-preset/90-default.preset file in Red Hat Enterprise Linux 7 and according to the current settings of the Red Hat Enterprise Linux 6 system. In addition, the module does not check the default settings of the system but only the settings for the runlevel used during the processing of the check script, which might not be the default runlevel of the system. As a consequence, initscripts are not handled in the anticipated way and the new system needs more manual action than expected. However, the user is informed about the settings that will be chosen for relevant services, despite the presumable default settings. (BZ#1366671) The default value of first_valid_uid in Dovecot has changed in Red Hat Enterprise Linux 7 Since Red Hat Enterprise Linux 7.3, the default value of the first_valid_uid configuration option of Dovecot has changed from 500 in Red Hat Enterprise Linux 6 to 1000 in Red Hat Enterprise Linux 7. Consequently, if a Red Hat Enterprise Linux 6 installation does not have first_valid_uid explicitly defined, the Dovecot configuration will not allow users with UID less than 1000 to log in after the update to Red Hat Enterprise Linux 7. To avoid breaking of the configuration, redefine first_valid_uid to 500 after the upgrade in the /etc/dovecot/conf.d/10-mail.conf file. Note that only installations where first_valid_uid is not explicitly defined are affected by this problem. (BZ# 1388967 )

Commands:
Chapter 9. Using Samba to print to a Windows print server with Kerberos authentication With the samba-krb5-printing wrapper, Active Directory (AD) users who are logged in to Red Hat Enterprise Linux (RHEL) can authenticate to Active Directory (AD) by using Kerberos and then print to a local CUPS print server that forwards the print job to a Windows print server. The benefit of this configuration is that the administrator of CUPS on RHEL does not need to store a fixed user name and password in the configuration. CUPS authenticates to AD with the Kerberos ticket of the user that sends the print job. Note Red Hat supports only submitting print jobs to CUPS from your local system, and not to re-share a printer on a Samba print server. Prerequisites The printer that you want to add to the local CUPS instance is shared on an AD print server. You joined the RHEL host as a member to the AD. CUPS is installed on RHEL, and the cups service is running. The PostScript Printer Description (PPD) file for the printer is stored in the /usr/share/cups/model/ directory. Procedure Install the samba-krb5-printing , samba-client , and krb5-workstation packages: Optional: Authenticate as a domain administrator and display the list of printers that are shared on the Windows print server: Optional: Display the list of CUPS models to identify the PPD name of your printer: You require the name of the PPD file when you add the printer in the step. Add the printer to CUPS: The command uses the following options: -p printer_name sets the name of the printer in CUPS. -v URI_to_Windows_printer sets the URI to the Windows printer. Use the following format: smb:// host_name / printer_share_name . -m PPD_file sets the PPD file the printer uses. -o auth-info-required=negotiate configures CUPS to use Kerberos authentication when it forwards print jobs to the remote server. -E enables the printer and CUPS accepts jobs for the printer. Verification Log into the RHEL host as an AD domain user. Authenticate as an AD domain user: Print a file to the printer you added to the local CUPS print server:

Commands:
dnf install samba-krb5-printing samba-client krb5-workstation
smbclient -L win_print_srv.ad.example.com -U administrator @ AD_KERBEROS_REALM --use-kerberos=required Sharename Type Comment --------- ---- ------- Example Printer Example
lpinfo -m samsung.ppd Samsung M267x 287x Series PXL
lpadmin -p " example_printer " -v smb:// win_print_srv.ad.example.com / Example -m samsung.ppd -o auth-info-required=negotiate -E
kinit domain_user_name @ AD_KERBEROS_REALM
lp -d example_printer file
8.4. Network Function Files Red Hat Enterprise Linux makes use of several files that contain important common functions used to bring interfaces up and down. Rather than forcing each interface control file to contain these functions, they are grouped together in a few files that are called upon when necessary. The /etc/sysconfig/network-scripts/network-functions file contains the most commonly used IPv4 functions, which are useful to many interface control scripts. These functions include contacting running programs that have requested information about changes in an interface's status, setting hostnames, finding a gateway device, verifying whether or not if a particular device is down, and adding a default route. As the functions required for IPv6 interfaces are different than IPv4 interfaces, a /etc/sysconfig/network-scripts/network-functions-ipv6 file exists specifically to hold this information. The functions in this file configure and delete static IPv6 routes, create and remove tunnels, add and remove IPv6 addresses to an interface, and test for the existence of an IPv6 address on an interface.

Commands:
4.8. Data Journaling Ordinarily, GFS2 writes only metadata to its journal. File contents are subsequently written to disk by the kernel's periodic sync that flushes file system buffers. An fsync() call on a file causes the file's data to be written to disk immediately. The call returns when the disk reports that all data is safely written. Data journaling can result in a reduced fsync() time for very small files because the file data is written to the journal in addition to the metadata. This advantage rapidly reduces as the file size increases. Writing to medium and larger files will be much slower with data journaling turned on. Applications that rely on fsync() to sync file data may see improved performance by using data journaling. Data journaling can be enabled automatically for any GFS2 files created in a flagged directory (and all its subdirectories). Existing files with zero length can also have data journaling turned on or off. Enabling data journaling on a directory sets the directory to "inherit jdata", which indicates that all files and directories subsequently created in that directory are journaled. You can enable and disable data journaling on a file with the chattr command. The following commands enable data journaling on the /mnt/gfs2/gfs2_dir/newfile file and then check whether the flag has been set properly. The following commands disable data journaling on the /mnt/gfs2/gfs2_dir/newfile file and then check whether the flag has been set properly. You can also use the chattr command to set the j flag on a directory. When you set this flag for a directory, all files and directories subsequently created in that directory are journaled. The following set of commands sets the j flag on the gfs2_dir directory, then checks whether the flag has been set properly. After this, the commands create a new file called newfile in the /mnt/gfs2/gfs2_dir directory and then check whether the j flag has been set for the file. Since the j flag is set for the directory, then newfile should also have journaling enabled.

Commands:
chattr +j /mnt/gfs2/gfs2_dir/newfile lsattr /mnt/gfs2/gfs2_dir ---------j--- /mnt/gfs2/gfs2_dir/newfile
chattr -j /mnt/gfs2/gfs2_dir/newfile lsattr /mnt/gfs2/gfs2_dir ------------- /mnt/gfs2/gfs2_dir/newfile
chattr -j /mnt/gfs2/gfs2_dir lsattr /mnt/gfs2 ---------j--- /mnt/gfs2/gfs2_dir touch /mnt/gfs2/gfs2_dir/newfile lsattr /mnt/gfs2/gfs2_dir ---------j--- /mnt/gfs2/gfs2_dir/newfile
7.149. module-init-tools 7.149.1. RHBA-2013:0442 - module-init-tools bug fix update Updated module-init-tools packages that fix one bug are now available for Red Hat Enterprise Linux 6. The module-init-tools packages include various programs needed for automatic loading and unloading of modules under kernels version 2.6 and later, as well as other module management programs. Device drivers and file systems are two examples of loaded and unloaded modules. Bug Fix BZ#670653 Previously, the rpmbuild utility received warnings about specific tags being deprecated for module-init-tools. This update fixes the module-init-tools spec file and rpmbuild no longer receives warnings. Users of module-init-tools are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 7. Modifying existing projects in Business Central Business Central includes a number of sample projects that you can use to get familiar with the product and its features. The sample projects have been designed and created to demonstrate a variety of business scenarios. You can modify the sample projects to meet your specific business needs. For example, Red Hat Process Automation Manager 7.13 contains the Mortgage_Process sample project, which consists of predefined data objects, guided decision tables, guided rules, forms, and a business process. You can edit the sample to refine your business process. If none of the existing Business Central project samples align with your requirements, you can create a new project or import one from a Git repository. For more information, see Chapter 9, Importing projects from Git repositories . You can import any other project from Git. For example, a project that was developed in another Business Central instance.

Commands:
Chapter 11. Network Configuration This chapter provides an introduction to the common networking configurations used by libvirt based guest virtual machines. For additional information, consult the libvirt network architecture documentation: http://libvirt.org/intro.html . Red Hat Enterprise Linux 6 supports the following networking setups for virtualization: virtual networks using Network Address Translation ( NAT ) directly allocated physical devices using PCI device assignment directly allocated virtual functions using PCIe SR-IOV bridged networks You must enable NAT, network bridging or directly assign a PCI device to allow external hosts access to network services on guest virtual machines. 11.1. Network Address Translation (NAT) with libvirt One of the most common methods for sharing network connections is to use Network Address Translation (NAT) forwarding (also known as virtual networks). Host Configuration Every standard libvirt installation provides NAT-based connectivity to virtual machines as the default virtual network. Verify that it is available with the virsh net-list --all command. If it is missing, the example XML configuration file can be reloaded and activated: The default network is defined from /usr/share/libvirt/networks/default.xml Mark the default network to automatically start: Start the default network: Once the libvirt default network is running, you will see an isolated bridge device. This device does not have any physical interfaces added. The new device uses NAT and IP forwarding to connect to the physical network. Do not add new interfaces. libvirt adds iptables rules which allow traffic to and from guest virtual machines attached to the virbr0 device in the INPUT , FORWARD , OUTPUT and POSTROUTING chains. libvirt then attempts to enable the ip_forward parameter. Some other applications may disable ip_forward , so the best option is to add the following to /etc/sysctl.conf . Guest Virtual Machine Configuration Once the host configuration is complete, a guest virtual machine can be connected to the virtual network based on its name. To connect a guest to the 'default' virtual network, the following could be used in the XML configuration file (such as /etc/libvirtd/qemu/myguest.xml ) for the guest: Note Defining a MAC address is optional. If you do not define one, a MAC address is automatically generated and used as the MAC address of the bridge device used by the network. Manually setting the MAC address may be useful to maintain consistency or easy reference throughout your environment, or to avoid the very small chance of a conflict.

Commands:
virsh net-list --all Name State Autostart ----------------------------------------- default active yes
virsh net-define /usr/share/libvirt/networks/default.xml
virsh net-autostart default Network default marked as autostarted
virsh net-start default Network default started
brctl show bridge name bridge id STP enabled interfaces virbr0 8000.000000000000 yes
net.ipv4.ip_forward = 1
<interface type='network'> <source network='default'/> </interface>
<interface type='network'> <source network='default'/> <mac address='00:16:3e:1a:b3:4a'/> </interface>
18.2. ACI Placement Directory Server stores ACIs in the multi-valued aci operational attribute in directory entries. To set an ACI, add the aci attribute to the corresponding directory entry. Directory Server applies the ACIs: Only to the entry that contains the ACI, if it does not have any child entries. For example, if a client requires access to the uid= user_name ,ou=People,dc=example,dc=com object, and an ACI is only set on dc=example,dc=com and not on any child entries, only this ACI is applied. Note ACIs with add permissions also apply to child entries created in future. To the entry that contains the ACI and to all entries below it, if it has child entries. As a direct consequence, when the server evaluates access permissions to any given entry, it verifies the ACIs for every entry between the one requested and the directory suffix, as well as the ACIs on the entry itself. For example, ACIs are set on the dc=example,dc=com and the ou=People,dc=example,dc=com entry: If a client wants to access the uid= user_name ,ou=People,dc=example,dc=com object, which has no ACI set, Directory Server first creates a set with the ACIs from dc=example,dc=com and ou=People,dc=example,dc=com . Directory Server builds the list of applicable ACIs bottom-up from the target entry up to the top suffix. However, consider this list as a set, and the client application should not anticipate any order into ACI evaluation. The server selects the ACIs that match the resource entry that creates the final set of applicable ACIs from this initial set. Then it first evaluates the ACIs that deny permission. If a DENY ACI has been successfully evaluated, the operation fails. If no DENY ACI is found, Directory Server checks if an ACI exists that grants ALLOW permissions. If at least one of the ACIs allows access, Directory Server grants access. If no ACI grants ALLOW permissions, Directory Server refuses access, and the operation fails. Note ACIs set in the rootDSE entry apply only to this entry. An ACI created on an entry can be set not to apply directly to that entry but rather to some or all of the entries in the subtree below. The advantage of this approach is that general ACIs can be placed higher in the directory tree to have effect on entries located lower in the tree. For example, an ACI that targets entries that include the inetOrgPerson object class can be created at the level of an organizationalUnit entry or a locality entry. Note Minimize the number of ACIs in the directory tree by placing general rules at high level branch points. To limit the scope of more specific rules, place them to leaf entries as closely as possible.

Commands:
4.2. Configuration File Blacklist The devnode_blacklist section of the multipath configuration file specifies the devices that will not be used when the system configures multipath devices. Devices that are blacklisted will not be grouped into a multipath device. By default, all devices are blacklisted, since the following lines appear in the initial configuration file. To enable multipathing on all of the devices that are supported by default, comment out those lines, as described in Section 3.1, "Setting Up DM-Multipath" . After commenting out the universal blacklist, you can specify general device types and individual devices to blacklist. You can blacklist devices according to the following criteria: By WWID, as described in Section 4.2.1, "Blacklisting By WWID" By device name, as described in Section 4.2.2, "Blacklisting By Device Name" By default, a variety of device types are blacklisted, even after you comment out the initial devnode_blacklist section of the configuration file. For information, see Section 4.2.2, "Blacklisting By Device Name" . 4.2.1. Blacklisting By WWID You can specify individual devices to blacklist by their World-Wide IDentification with a wwid entry in the blacklist section of the configuration file. The following example shows the lines in the configuration file that would blacklist a device with a WWID of 26353900f02796769.

Commands:
devnode_blacklist { devnode "*" }
blacklist { wwid 26353900f02796769 }
Preface Welcome to the Red Hat JBoss Core Services version 2.4.57 Service Pack 1 release. Red Hat JBoss Core Services Apache HTTP Server is an open source web server developed by the Apache Software Foundation . The Apache HTTP Server includes the following features: Implements the current HTTP standards, including HTTP/1.1 and HTTP/2 Supports Transport Layer Security (TLS) encryption through OpenSSL , which provides secure connections between the web server and web clients Supports extensible functionality through the use of modules, some of which are included with the Red Hat JBoss Core Services Apache HTTP Server

Commands:
Appendix A. MSI-based installer properties The Red Hat build of OpenJDK for Windows MSI-based installer includes the JDK Files component and the following optional properties: Table A.1. Red Hat build of OpenJDK for Windows MSI-based installer properties Property Description Default value OpenJDK Runtime - Windows Registry The following registry keys are set HKLM\Software\JavaSoft\JDK\<version>, entries: JavaHome: <INSTALLDIR> RuntimeLib: <INSTALLDIR>\bin\server\jvm.dll HKLM\Software\JavaSoft\JDK, entries: CurrentVersion: <version> Yes OpenJDK Runtime - Path Variable Adds the Runtime to the Path variable so it is available from the command line. Yes OpenJDK Runtime - JAVA_HOME System Variable JAVA_HOME is used by some programs to find the Java runtime. No OpenJDK Runtime - REDHAT_JAVA_HOME System Variable REDHAT_JAVA_HOME can be used by some programs to find the Red Hat build of OpenJDK runtime. No OpenJDK Runtime - Jar Files Association This enables Jar files to be run from within Windows Explorer. No Mission Control - Files Contains files that are installed in the <installdir> \missioncontrol directory. No Mission Control - Path Variable Appends <installdir> \missioncontrol to the system PATH environment variable. No Web Start - JNLP File Association Enables the launching of JNLP files downloaded from the web. No Web Start - PATH Variable Enables the launching of JNLP files downloaded from the web from the local file system. No Web Start - Keep Settings and Cache Keeps settings and caches on the local file system. No Web Start - Install plugin.jar Installs plugin.jar into the jre\lib directory. No Revised on 2024-05-10 09:09:00 UTC

Commands:
4.2. Mapping Properties Multiple Times Properties may need to be mapped multiple times per index, using different indexing strategies. For example, sorting a query by field requires that the field is not analyzed. To search by words in this property and also sort it, the property will need to be indexed it twice - once analyzed and once un-analyzed. @Fields can be used to perform this search. For example: Example 4.3. Using @Fields to map a property multiple times In the example above, the field summary is indexed twice - once as summary in a tokenized way, and once as summary_forSort in an untokenized way. @Field supports 2 attributes useful when @Fields is used: analyzer: defines a @Analyzer annotation per field rather than per property bridge: defines a @FieldBridge annotation per field rather than per property Report a bug

Commands:
@Indexed(index = "Book") public class Book { @Fields( { @Field, @Field(name = "summary_forSort", analyze = Analyze.NO, store = Store.YES) }) public String getSummary() { return summary; } }
17.2. remote-viewer The remote-viewer is a simple remote desktop display client that supports SPICE and VNC. It shares most of the features and limitations with virt-viewer . However, unlike virt-viewer, remote-viewer does not require libvirt to connect to the remote guest display. As such, remote-viewer can be used for example to connect to a virtual machine on a remote host that does not provide permissions to interact with libvirt or to use SSH connections. To install the remote-viewer utility, run: Syntax The basic remote-viewer command-line syntax is as follows: To see the full list of options available for use with remote-viewer, use man remote-viewer . Connecting to a guest virtual machine If used without any options, remote-viewer lists guests that it can connect to on the default URI of the local system. To connect to a specific guest using remote-viewer, use the VNC/SPICE URI. For information about obtaining the URI, see Section 14.5.19, "Displaying a URI for Connection to a Graphical Display" . Example 17.3. Connecting to a guest display using SPICE Use the following to connect to a SPICE server on a machine called "testguest" that uses port 5900 for SPICE communication: Example 17.4. Connecting to a guest display using VNC Use the following to connect to a VNC server on a machine called testguest2 that uses port 5900 for VNC communication: Interface By default, the remote-viewer interface provides only the basic tools for interacting with the guest: Figure 17.2. Sample remote-viewer interface

Commands:
sudo yum install virt-viewer
remote-viewer [OPTIONS] {guest-name|id|uuid}
remote-viewer spice:// testguest : 5900
remote-viewer vnc:// testguest2 : 5900