mtpti5iD/redhat-docs_dataset huggingface dataset:
8.164. pam 8.164.1. RHBA-2014:1579 - pam bug fix update Updated pam packages that fix several bugs are now available for Red Hat Enterprise Linux 6. Pluggable Authentication Modules (PAM) provide a system to set up authentication policies without the need to recompile programs to handle authentication. Bug Fixes BZ# 947011 The pam_unix module contained an "off-by-one" error when comparing the date of user account expiration with the current date. In this situation, the real expiration of the account happened a day after the date specified by the "chage -E" command. This update fixes the "off-by-one" error and user accounts now expire on the date set by the "chage -E" command. BZ# 1120099 The pam_unix and pam_pwhistory modules did not properly handle missing fields in the entries in the /etc/security/opasswd file. As a consequence, if some of the fields were not present in a user's entry, changing the password for example with the passwd command could result in a segmentation fault. This bug has been fixed and pam_unix and pam_pwhistory now properly handle missing fields in the entries in /etc/security/opasswd. BZ# 1054936 Previously, the pam_limits module did not verify whether the process referenced in the /var/run/utmp file as the login process still existed. As a consequence, when the user had the "maxlogins" limit set in the limits.conf file and the login session process terminated unexpectedly and also did not update the utmp file correctly, the user did not have access to the system even if some of his login session no longer existed due to the crash. After this update, pam_limits tests whether the login process still exists on the system. As a result, the number of existing login sessions is counted more precisely when the "maxlogins" limit is applied by the pam_limits module. BZ# 1119289 Previously, the pam_userdb module handled the call to the crypt() function too strictly not to expect modern crypt hash formats. As a consequence, pam_userdb was not able to support any other hash algorithms supported by the glibc library for the user password hashes. This update improves the code handling the crypt() function. Now, pam_userdb supports any password hash formats supported by the glibc crypt() function. Users of pam are advised to upgrade to these updated packages, which fix these bugs.

Commands:
B.108.2. RHBA-2011:0453 - xorg-x11-server-utils bug fix update An updated xorg-x11-server-utils package that fixes one bug is now available for Red Hat Enterprise Linux 6. The xorg-x11-server-utils package contains a collection of utilities used to modify and query the runtime configuration of the X.Org server. X.Org is an open source implementation of the X Window System. Bug Fix BZ# 696310 A advisory, the RHSA-2011:0433 xorg-x11-server-utils security update, applied a backported patch to fix a flaw in the X server resource database utility, xrdb. While this patch resolved the security issue, it also introduced an error in the macro expansion mechanism. Consequent to this, an attempt to run the xrdb utility could fail with the following messages written to standard error: With this update, the underlying source code has been adapted to correct the macro expansion mechanism, and the xrdb utility now works as expected. All users of xorg-x11-server-utils are advised to upgrade to this updated package, which fixes this bug. Note that all running instances of the X.Org server must be restarted for this update to take effect.

Commands:
sh: -c: line 0: unexpected EOF while looking for matching `"' sh: -c: line 1: syntax error: unexpected end of file
Chapter 11. Uninstalling OpenShift AI You can use Red Hat OpenShift Cluster Manager to safely uninstall Red Hat OpenShift AI from your OpenShift cluster. Prerequisites Credentials for Red Hat OpenShift Cluster Manager ( https://console.redhat.com/openshift/ ). Administrator access to the OpenShift cluster. For AWS clusters, you have backed up the EBS volume containing your Persistent Volume Claims (PVCs). See Amazon Web Services documentation: Create Amazon EBS snapshots for more information. For GCP clusters, you have backed up the persistent disk containing your Persistent Volume Claims (PVCs). See Google Cloud documentation: Create and manage disk snapshots for more information. Procedure Log in to Red Hat OpenShift Cluster Manager ( https://console.redhat.com/openshift/ ). Click Clusters . The Clusters page opens. Click the name of the cluster that hosts the instance OpenShift AI to uninstall. The Details page for the cluster opens. Click the Add-ons tab and locate the Red Hat OpenShift Data Science tile. Click Uninstall . This process takes approximately 30 minutes to complete. Do not manually delete any resources while uninstalling OpenShift AI, as this can interfere with the uninstall process. OpenShift AI is uninstalled and any persistent volume claims (PVCs) associated with your OpenShift AI instance are deleted. However, any user groups for OpenShift AI that you previously created remain on your cluster. Verification In Red Hat OpenShift Cluster Manager, on the Add-ons tab for the cluster, confirm that the OpenShift Data Science tile does not show the Installed state. In your OpenShift cluster, click Home Projects and confirm that the following project namespaces are not visible: redhat-ods-applications redhat-ods-monitoring redhat-ods-operator Additional resources Amazon Web Services documentation: Create Amazon EBS snapshots Google Cloud documentation: Create and manage disk snapshots Deleting users and user resources

Commands:
9.6. Graphics Devices The SPICE or VNC graphics protocols can be used to connect to the emulated graphics devices. You can select a Video Type in the Administration Portal: QXL : Emulates a para-virtualized video card that works best with QXL guest drivers VGA : Emulates a dummy VGA card with Bochs VESA extensions BOCHS : Emulates a dummy VGA card without legacy emulation for guest machines that that run with UEFI. This is the default display video card emulator for UEFI servers. Note For a virtual machine of type server that is set with UEFI and uses compatibility level 4.6 or above, BOCHS is the default value of Video Type . In Red Hat Virtualization 4.4.5, you must do the following to enable this feature: Run the following command: where <version> is the compatibility version. Restart the engine. Set Video Type to BOCHS manually.

Commands:
engine-config --set EnableBochsDisplay=true --cver=<version>
10.2. Registering a New Guest Virtual Machine In cases where a new guest virtual machine is to be created on a host that is already registered and running, the virt-who service must also be running. This ensures that the virt-who service maps the guest to a hypervisor, so the system is properly registered as a virtual system. To register the virtual machine, enter the following command:

Commands:
subscription-manager register --username=admin --password=secret --auto-attach
8.4. LDAP 8.4.1. OpenLDAP The configuration required for the OpenLDAP service has changed in Red Hat Enterprise Linux 6. In versions, slapd was configured using the /etc/openldap/slapd.conf file. The slapd configuration in Red Hat Enterprise Linux 6 is now stored in a special LDAP directory ( /etc/openldap/slapd.d/ ) with a pre-defined schema and Directory Information Tree (DIT). Further details of this configuration schema can be found at openldap.org . The following section details an example on how to convert the old configuration file to work with the new directory:

Commands:
Chapter 80. Data Format Component Available as of Camel version 2.12 The dataformat: component allows to use Data Format as a Camel Component. 80.1. URI format Where name is the name of the Data Format. And then followed by the operation which must either be marshal or unmarshal . The options is used for configuring the Data Format in use. See the Data Format documentation for which options it support. 80.2. DataFormat Options The Data Format component has no options. The Data Format endpoint is configured using URI syntax: with the following path and query parameters: 80.2.1. Path Parameters (2 parameters): Name Description Default Type name Required Name of data format String operation Required Operation to use either marshal or unmarshal String 80.2.2. Query Parameters (1 parameters): Name Description Default Type synchronous (advanced) Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported). false boolean 80.3. Samples For example to use the JAXB Data Format we can do as follows: from("activemq:My.Queue"). to("dataformat:jaxb:unmarshal?contextPath=com.acme.model"). to("mqseries:Another.Queue"); And in XML DSL you do: <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring"> <route> <from uri="activemq:My.Queue"/> <to uri="dataformat:jaxb:unmarshal?contextPath=com.acme.model"/> <to uri="mqseries:Another.Queue"/> </route> </camelContext>

Commands:
dataformat:name:(marshal|unmarshal)[?options]
dataformat:name:operation
from("activemq:My.Queue"). to("dataformat:jaxb:unmarshal?contextPath=com.acme.model"). to("mqseries:Another.Queue");
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring"> <route> <from uri="activemq:My.Queue"/> <to uri="dataformat:jaxb:unmarshal?contextPath=com.acme.model"/> <to uri="mqseries:Another.Queue"/> </route> </camelContext>
14.8.6. pdbedit pdbedit <options> The pdbedit program manages accounts located in the SAM database. All backends are supported including smbpasswd , LDAP, NIS+, and the tdb database library. The following are examples of adding, deleting, and listing users:

Commands:
~]# pdbedit -a kristin new password: retype new password: Unix username: kristin NT username: Account Flags: [U ] User SID: S-1-5-21-1210235352-3804200048-1474496110-2012 Primary Group SID: S-1-5-21-1210235352-3804200048-1474496110-2077 Full Name: Home Directory: \\wakko\kristin HomeDir Drive: Logon Script: Profile Path: \\wakko\kristin\profile Domain: WAKKO Account desc: Workstations: Munged dial: Logon time: 0 Logoff time: Mon, 18 Jan 2038 22:14:07 GMT Kickoff time: Mon, 18 Jan 2038 22:14:07 GMT Password last set: Thu, 29 Jan 2004 08:29:28 GMT Password can change: Thu, 29 Jan 2004 08:29:28 GMT Password must change: Mon, 18 Jan 2038 22:14:07 GMT ~]# pdbedit -v -L kristin Unix username: kristin NT username: Account Flags: [U ] User SID: S-1-5-21-1210235352-3804200048-1474496110-2012 Primary Group SID: S-1-5-21-1210235352-3804200048-1474496110-2077 Full Name: Home Directory: \\wakko\kristin HomeDir Drive: Logon Script: Profile Path: \\wakko\kristin\profile Domain: WAKKO Account desc: Workstations: Munged dial: Logon time: 0 Logoff time: Mon, 18 Jan 2038 22:14:07 GMT Kickoff time: Mon, 18 Jan 2038 22:14:07 GMT Password last set: Thu, 29 Jan 2004 08:29:28 GMT Password can change: Thu, 29 Jan 2004 08:29:28 GMT Password must change: Mon, 18 Jan 2038 22:14:07 GMT ~]# pdbedit -L andriusb:505: joe:503: lisa:504: kristin:506: ~]# pdbedit -x joe ~]# pdbedit -L andriusb:505: lisa:504: kristin:506:
Chapter 2. Red Hat Ansible Automation Platform Service on AWS PULL and PUSH models 2.1. Automation using the Red Hat Ansible Automation Platform Service on AWS control plane The Red Hat Ansible Automation Platform Service on AWS offers a deployment of Ansible Automation Platform deployment purchased through AWS Marketplace. Red Hat configures and provisions an Ansible Automation Platform. The Red Hat team handles the setup and maintenance of the Ansible Automation Platform, ensuring reliability and security. While Red Hat manages the control plane, the execution plane is spread across your domains using automation mesh hop nodes and execution nodes. For help with configuring execution nodes see Automation mesh for managed cloud or operator environments . There are two ways to configure the communication between control nodes and execution nodes: The PULL connectivity model (recommended) The PUSH connectivity model 2.2. PULL connectivity Remote automation mesh nodes can access Ansible Automation Platform using a 'polling' or 'pull' model, which does not require opening ingress ports in the firewall. This model eliminates the need for hop nodes from your demilitarized zone (DMZ) to private networks if private networks have outbound internet connectivity. Figure 1 Pull model 2.3. PUSH connectivity You can design their automation mesh architecture using the push model and configure the communication ports. The default port is 27199, which must not conflict with other traffic, such as HTTPS. Ansible Automation Platform Service on AWS supports current automation mesh features that push communication to both hop nodes and execution nodes. Figure 1 Push model

Commands:
2.3. Clustering and High Availability Utilizing CPG API for inter-node locking Rgmanager includes a feature which enables it to utilize Corosync's Closed Process Group (CPG) API for inter-node locking. This feature is automatically enabled when Corosync's RRP feature is enabled. Corosync's RRP feature is considered fully supported. However, when used with the rest of the High-Availability Add-Ons, it is considered a Technology Preview. Package: rgmanager-3.0.12.1-12 Support for redundant ring for standalone Corosync, BZ# 722469 Red Hat Enterprise Linux 6.3 includes support for redundant ring with autorecovery feature as a Technology Preview. Refer to Section 3.7, "Clustering" for a list of known issues associated with this Technology Preview. Package: corosync-1.4.1-7 corosync-cpgtool, BZ# 688260 The corosync-cpgtool now specifies both interfaces in a dual ring configuration. This feature is a Technology Preview. Package: corosync-1.4.1-7 Disabling rgmanager in /etc/cluster.conf, BZ# 723925 As a consequence of converting the /etc/cluster.conf configuration file to be used by pacemaker , rgmanager must be disabled. The risk of not doing this is high; after a successful conversion, it would be possible to start rgmanager and pacemaker on the same host, managing the same resources. Consequently, Red Hat Enterprise Linux 6 includes a feature (as a Technology Preview) that forces the following requirements: rgmanager must refuse to start if it sees the <rm disabled="1"> flag in /etc/cluster.conf . rgmanager must stop any resources and exit if the <rm disabled="1"> flag appears in /etc/cluster.conf during a reconfiguration. Package: rgmanager-3.0.12.1-12 libqb package The libqb package provides a library with the primary purpose of providing high performance client server reusable features, such as high performance logging, tracing, inter-process communication, and polling. This package is introduced as a dependency of the pacemaker package, and is considered a Technology Preview in Red Hat Enterprise Linux 6.3. Package: libqb-0.9.0-2 pacemaker, BZ# 456895 Pacemaker, a scalable high-availability cluster resource manager, is included in Red Hat Enterprise Linux 6 as a Technology Preview. Pacemaker is not fully integrated with the Red Hat cluster stack. Package: pacemaker-1.1.7-6

Commands:
5.5. Securing the Apache HTTP Server The Apache HTTP Server is one of the most stable and secure services that ships with Red Hat Enterprise Linux. There are an overwhelming number of options and techniques available to secure the Apache HTTP Server - too numerous to delve into deeply here. It is important when configuring the Apache HTTP Server to read the documentation available for the application. This includes the chapter titled Apache HTTP Server in the Reference Guide , the chapter titled Apache HTTP Server Configuration in the System Administrators Guide . Below is a list of configuration options administrators should be careful using. 5.5.1. FollowSymLinks This directive is enabled by default, be sure to use caution when creating symbolic links to the document root of the Web server. For instance, it is a bad idea to provide a symbolic link to / .

Commands:
16.4. Retrieve Existing Keytabs for Multiple Servers In some scenarios, like in a cluster environment, the same keytab file is required for a service represented on one common host name by different machines. IdM commands can be used to retrieve the same keytab on each of the hosts. To prepare the common host name and the service principal, run the following commands on an IdM server: Authenticate as admin user: Add a common forward DNS record for all IP addresses that share this host name: Create a new host entry object for the common DNS name: Add the service principal for the host: Add the hosts to the service, that should be able to retrieve the keytab from IdM: Grant permission to create a new keytab to one host: On the clients, follow these steps: Authenticate with the hosts Kerberos keytab: On the client you granted the respective permission to, generate a new keytab and store it in a file: On all other clients, retrieve the existing keytab from the IdM server by adding the -r option to the command: Warning Be aware that if you omit the -r option, a new keytab will be generated. This invalidates all previously retrieved keytabs for this service principal.

Commands:
kinit admin
ipa dnsrecord-add idm.example.com cluster --a-rec={192.0.2.40,192.0.2.41} Record name: cluster A record: 192.0.2.40, 192.0.2.41
ipa host-add cluster.idm.example.com ------------------------------------ Added host "cluster.idm.example.com" ------------------------------------ Host name: cluster.idm.example.com Principal name: host/cluster.idm.example.com@IDM.EXAMPLE.COM Password: False Keytab: False Managed by: cluster.idm.example.com
ipa service-add HTTP/cluster.idm.example.com ------------------------------------------------------------ Added service "HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM" ------------------------------------------------------------ Principal: HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM Managed by: cluster.idm.example.com
ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com --hosts={node01.idm.example.com,node02.idm.example.com} Principal: HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM Managed by: cluster.idm.example.com Hosts allowed to retrieve keytab: node01.idm.example.com, node02.idm.example.com ------------------------- Number of members added 2 -------------------------
ipa service-allow-create-keytab HTTP/cluster.idm.example.com --hosts=node01.idm.example.com Principal: HTTP/cluster.idm.example.com@IDM.EXAMPLE.COM Managed by: cluster.idm.example.com Hosts allowed to retrieve keytab: node01.idm.example.com, node02.idm.example.com Hosts allowed to create keytab: node01.idm.example.com ------------------------- Number of members added 1 -------------------------
kinit -kt /etc/krb5.keytab
ipa-getkeytab -s ipaserver.idm.example.com -p HTTP/cluster.idm.example.com -k /tmp/client.keytab
ipa-getkeytab -r -s ipaserver.idm.example.com -p HTTP/cluster.idm.example.com -k /tmp/client.keytab
Chapter 5. Container images with Go Toolset You can build your own Go Toolset containers from either Red Hat Enterprise Linux container images or Red Hat Universal Base Images (UBI). 5.1. Red Hat Enterprise Linux Go Toolset container images contents The Red Hat Enterprise Linux 8 and Red Hat Enterprise Linux 9 container images of Go Toolset contain the following packages: Component Version Package Go 1.21 RHEL 8 - go-toolset-1.21.0 RHEL 9 - go-toolset-1.21.0 5.2. Accessing Red Hat Enterprise Linux container images Pull the container image from the Red Hat registry before running your container and performing actions. Procedure To pull the required image, run: For an image based on Red Hat Enterprise Linux 8: For an image based on Red Hat Enterprise Linux 9: 5.3. Accessing the UBI Go Toolset container image on RHEL 8 On RHEL 8, install the UBI Go Toolset container image to access Go Toolset. Alternatively, you can install Go Toolset to the RHEL 8 base UBI container image. For further information, see Accessing Go Toolset from the base UBI container image on RHEL 8 . Procedure To pull the UBI Go Toolset container image from the Red Hat registry, run: On Red Hat Enterprise Linux 8 On Red Hat Enterprise Linux 9 5.4. Accessing Go Toolset from the base UBI container image on RHEL 8 On RHEL 8, Go Toolset packages are part of the Red Hat Universal Base Images (UBIs) repositories, which means you can install Go Toolset as an addition to the base UBI container image. To keep the container image size small, install only individual packages instead of the entire Go Toolset. Alternatively, you can install the UBI Go Toolset container image to access Go Toolset. For further information, see Accessing the UBI Go Toolset container image on RHEL 8 . Prerequisites An existing Containerfile. For information on creating Containerfiles, see the Dockerfile reference page. Procedure To create a container image containing Go Toolset, add the following lines to your Containerfile: To create a container image containing an individual package only, add the following lines to your Containerfile: Replace < package-name > with the name of the package you want to install. 5.5. Additional resources Go Toolset Container Images in the Red Hat Container Registry . For more information on Red Hat UBI images, see Working with Container Images . For more information on Red Hat UBI repositories, see Universal Base Images (UBI): Images, repositories, packages, and source code .

Commands:
podman pull registry.redhat.io/rhel8/go-toolset
podman pull registry.redhat.io/rhel9/go-toolset
podman pull registry.access.redhat.com/ubi8/go-toolset
podman pull registry.access.redhat.com/ubi9/go-toolset
FROM registry.access.redhat.com/ubi8/ubi: latest RUN yum module install -y go-toolset
RUN yum install -y < package-name >
Chapter 27. Console Access When normal (non-root) users log into a computer locally, they are given two types of special permissions: They can run certain programs that they would not otherwise be able to run They can access certain files (normally special device files used to access diskettes, CD-ROMs, and so on) that they would not otherwise be able to access Since there are multiple consoles on a single computer and multiple users can be logged into the computer locally at the same time, one of the users has to essentially win the race to access the files. The first user to log in at the console owns those files. Once the first user logs out, the user who logs in owns the files. In contrast, every user who logs in at the console is allowed to run programs that accomplish tasks normally restricted to the root user. If X is running, these actions can be included as menu items in a graphical user interface. As shipped, the console-accessible programs include halt , poweroff , and reboot . 27.1. Disabling Shutdown Via Ctrl + Alt + Del By default, /etc/inittab specifies that your system is set to shutdown and reboot in response to a Ctrl + Alt + Del key combination used at the console. To completely disable this ability, comment out the following line in /etc/inittab by putting a hash mark ( # ) in front of it: Alternatively, you may want to allow certain non-root users the right to shutdown or reboot the system from the console using Ctrl + Alt + Del . You can restrict this privilege to certain users, by taking the following steps: Add the -a option to the /etc/inittab line shown above, so that it reads: The -a flag tells shutdown to look for the /etc/shutdown.allow file. Create a file named shutdown.allow in /etc . The shutdown.allow file should list the usernames of any users who are allowed to shutdown the system using Ctrl + Alt + Del . The format of the shutdown.allow file is a list of usernames, one per line, like the following: According to this example shutdown.allow file, the users stephen, jack, and sophie are allowed to shutdown the system from the console using Ctrl + Alt + Del . When that key combination is used, the shutdown -a command in /etc/inittab checks to see if any of the users in /etc/shutdown.allow (or root) are logged in on a virtual console. If one of them is, the shutdown of the system continues; if not, an error message is written to the system console instead. For more information on shutdown.allow , refer to the shutdown man page.

Commands:
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
ca::ctrlaltdel:/sbin/shutdown -a -t3 -r now
stephen jack sophie