mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 16. Auto Scaling Kubernetes includes the HorizontalPodAutoscaler which allows StatefulSets or Deployments to be automatically scaled up or down based upon specified metrics. The Infinispan CR exposes the .status.scale sub-resource, which enables HorizontalPodAutoscaler resources to target the Infinispan CR. Before defining a HorizontalPodAutoscaler configuration, consider the types of Data Grid caches that you define. Distributed and Replicated caches have very different scaling requirements, so defining a HorizontalPodAutoscaler for server's running a combination of these cache types may not be advantageous. For example, defining a HorizontalPodAutoscaler that scales when memory usage reaches a certain percentage will allow overall cache capacity to be increased when defining Distributed caches as cache entries are spread across pods, however it will not work with replicated cache as every pod hosts all cache entries. Conversely, configuring a HorizontalPodAutoscaler based upon CPU usage will be more beneficial for clusters with replicated cache as every pod contains all cache entries and so distributing read requests across additional nodes will allow a greater number of requests to be processed simultaneously. 16.1. Configuring HorizontalPodAutoscaler Create a HorizontalPodAutoScaler resource that targets your Infinispan CR. Procedure Define a HorizontalPodAutoscaler resource in the same namespace as your Infinispan CR 1 The name of your Infinispan CR Note If using metric resource of type cpu or memory , you must configure request/limits for this resource in your Infinispan CR. Important HorizontalPodAutoscaler should be removed when upgrading a Data Grid cluster, as the automatic scaling will cause the upgrade process to enter unexpected state, as the Operator needs to scale the cluster down to 0 pods.

Commands:
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: infinispan-auto spec: scaleTargetRef: apiVersion: infinispan.org/v1 kind: Infinispan name: example 1 minReplicas: 1 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50
15.3. Checking a Package's Signature If you wish to verify that a package has not been corrupted or tampered with, examine only the md5sum by typing the following command at a shell prompt ( <rpm-file> with file name of the RPM package): The message <rpm-file> : md5 OK is displayed. This brief message means that the file was not corrupted by the download. To see a more verbose message, replace -K with -Kvv in the command. On the other hand, how trustworthy is the developer who created the package? If the package is signed with the developer's GnuPG key , you know that the developer really is who they say they are. An RPM package can be signed using Gnu Privacy Guard (or GnuPG), to help you make certain your downloaded package is trustworthy. GnuPG is a tool for secure communication; it is a complete and free replacement for the encryption technology of PGP, an electronic privacy program. With GnuPG, you can authenticate the validity of documents and encrypt/decrypt data to and from other recipients. GnuPG is capable of decrypting and verifying PGP 5. x files as well. During installation, GnuPG is installed by default. That way you can immediately start using GnuPG to verify any packages that you receive from Red Hat. First, you must import Red Hat's public key. 15.3.1. Importing Keys To verify Red Hat packages, you must import the Red Hat GPG key. To do so, execute the following command at a shell prompt: To display a list of all keys installed for RPM verification, execute the command: For the Red Hat key, the output includes: To display details about a specific key, use rpm -qi followed by the output from the command:

Commands:
-K --nosignature <rpm-file>
--import /usr/share/rhn/RPM-GPG-KEY
-qa gpg-pubkey*
gpg-pubkey-db42a60e-37ea5438
-qi gpg-pubkey-db42a60e-37ea5438
4.344. which 4.344.1. RHBA-2011:0911 - which bug fix update An updated which package that fixes one bug is now available for Red Hat Enterprise Linux 6. The "which" package includes the "which" command that shows the full pathname of a specified program, if the specified program is in your PATH. Bug Fix BZ# 671289 Prior to this update, the /etc/profile.d/which2.csh file caused an alias for the "which" command to be created. As a result, the "which" command included in the "which" package was used instead of the built-in "which" command as included in the C shell (csh). The problem has been fixed in this update by removing the /etc/profile.d/which2.csh file so that the "which" command included in csh is now used as expected. All users of "which" should upgrade to this updated package, which fixes this bug.

Commands:
B.87. spice-client B.87.1. RHEA-2010:0932 - spice-client enhancement update An enhanced spice-client package is now available for Red Hat Enterprise Linux 6. The Simple Protocol for Independent Computing Environments (SPICE) is a remote display protocol designed for virtual environments. SPICE users can view a virtualized desktop or server from the local system or any system with network access to the server. SPICE is available for a variety of machine architectures and operating systems. SPICE is used in Red Hat Enterprise Linux for viewing virtualized guests running on the KVM hypervisor or on Red Hat Enterprise Virtualization Hypervisors. The spice-client package provides the client side of the SPICE protocol. Enhancement BZ# 644840 This update rebases spice-client to the 0.6.3 version. It is compatible with future spice protocol changes, it adds copy and paste support between guest and client (when used together with an updated agent), and supports fullscreen mode under window-managers other then the default Gnome window manager metacity (especially compiz and kde are now also supported). All users requiring spice-client are advised to upgrade to this updated package, which adds this enhancement.

Commands:
Chapter 5. Debugging issues Central saves information to its container logs. 5.1. Prerequisites You have configured the ROX_ENDPOINT environment variable using the following command: USD export ROX_ENDPOINT= <host:port> 1 1 The host and port information that you want to store in the ROX_ENDPOINT environment variable. 5.2. Viewing the logs You can use either the oc or kubectl command to view the logs for the Central pod. Procedure To view the logs for the Central pod by using kubectl , run the following command : USD kubectl logs -n stackrox <central_pod> To view the logs for the Central pod by using oc , run the following command : USD oc logs -n stackrox <central_pod> 5.3. Viewing the current log level You can change the log level to see more or less information in Central logs. Procedure Run the following command to view the current log level: USD roxctl central debug log Additional resources roxctl central debug 5.4. Changing the log level Procedure Run the following command to change the log level: USD roxctl central debug log --level= <log_level> 1 1 The acceptable values for <log_level> are Panic , Fatal , Error , Warn , Info , and Debug . Additional resources roxctl central debug 5.5. Retrieving debugging information Procedure Run the following command to gather the debugging information for investigating issues: USD roxctl central debug dump To generate a diagnostic bundle with the RHACS administrator password or API token and central address, follow the procedure in Generating a diagnostic bundle by using the roxctl CLI . Additional resources roxctl central debug

Commands:
export ROX_ENDPOINT= <host:port> 1
kubectl logs -n stackrox <central_pod>
oc logs -n stackrox <central_pod>
roxctl central debug log
roxctl central debug log --level= <log_level> 1
roxctl central debug dump
6.6. btrfs References The man page btrfs(8) covers all important management commands. In particular this includes: All the subvolume commands for managing snapshots. The device commands for managing devices. The scrub , balance , and defragment commands. The man page mkfs.btrfs(8) contains information on creating a btrfs file system including all the options regarding it. The man page btrfsck(8) for information regarding fsck on btrfs systems.

Commands:
14.12.2. Deleting Storage Volumes The vol-delete --pool pool-or-uuid vol-name-or-key-or-path command deletes a given volume. The command requires a specific --pool pool-or-uuid which is the name or UUID of the storage pool the volume is in. The vol-name-or-key-or-path option specifies the name or key or path of the volume to delete. The vol-wipe --pool pool-or-uuid --algorithm algorithm vol-name-or-key-or-path command wipes a volume, to ensure data previously on the volume is not accessible to future reads. The command requires a --pool pool-or-uuid , which is the name or UUID of the storage pool the volume is in. The vol-name-or-key-or-path contains the name or key or path of the volume to wipe. Note it is possible to choose different wiping algorithms instead of the default (where every sector of the storage volume is written with value "0"). To specify a wiping algorithm, use the --algorithm option with one of the following supported algorithm types: zero - 1-pass all zeroes nnsa - 4-pass NNSA Policy Letter NAP-14.1-C (XVI-8) for sanitizing removable and non-removable hard disks: random x2, 0x00, verify. dod - 4-pass DoD 5220.22-M section 8-306 procedure for sanitizing removable and non-removable rigid disks: random, 0x00, 0xff, verify. bsi - 9-pass method recommended by the German Center of Security in Information Technologies (http://www.bsi.bund.de): 0xff, 0xfe, 0xfd, 0xfb, 0xf7, 0xef, 0xdf, 0xbf, 0x7f. gutmann - The canonical 35-pass sequence described in Gutmann's paper. schneier - 7-pass method described by Bruce Schneier in "Applied Cryptography" (1996): 0x00, 0xff, random x5. pfitzner7 - Roy Pfitzner's 7-random-pass method: random x7 pfitzner33 - Roy Pfitzner's 33-random-pass method: random x33. random - 1-pass pattern: random. Note The version of the scrub binary installed on the host will limit the algorithms that are available.

Commands:
5. Examples The following examples demonstrate how to pass the authentication token through a bearer header using cURL. Example 1. List Cases Return 10 cases from the logged-in user's account Example 2. Filter by last update date Example 3. List Case Comments This example lists case comments for case 0000000. Replace 0000000 with the number of a case to which you have access. Example 4. Create a Case The POST operation is used in this example, which creates a case under the RHEL 6 product using the default group, severity level, and type. Example 5. Update a Case The PUT method is used here to update data on an existing case. Most fields can be updated in this way. Case 000000's product is changed to Red Hat Enterprise Linux. Example 6. Escalate a Case for Management Attention This will escalate a case for management attention: Example 7. Add a New Case Comment This example uses the POST method to add a new comment to case 0000000. Example 8. Add a File Attachment to a Case File attachments are unique because they carry no XML payload. This example uses a form-encoded POST to transmit a file named test.txt to case 0000000. API supports file upload till 1GB.

Commands:
curl -X POST -H 'Content-Type: application/json' -H 'Authorization: Bearer USDtoken' --data '{ "offset" : 1, "maxResults": 10 }' https://api.access.redhat.com/support/v1/cases/filter
curl -X POST -H 'Content-Type: application/json' -H 'Authorization: Bearer USDtoken' --data '{ "startDate" : "2021-01-01", "endDate": "2021-12-31" }' https://api.access.redhat.com/support/v1/cases/filter
curl -H 'Authorization: Bearer USDtoken' https://api.access.redhat.com/support/v1/cases/0000000/comments
curl -X POST -H 'Content-Type: application/json -H 'Authorization: Bearer USDtoken' --data '{ "product":"Red Hat Enterprise Linux", "version":"7.0", "summary": "Example Case", "description": "Example Case created with cURL" }' https://api.access.redhat.com/support/v1/cases
curl -X PUT -H 'Content-Type: application/json -H 'Authorization: Bearer USDtoken' --data '{ "product": "Red Hat Enterprise Linux", "version":"7.0" }' https://api.access.redhat.com/support/v1/cases/0000000
curl -X PUT -H 'Content-Type: application/json -H 'Authorization: Bearer USDtoken' --data '{ "requestManagementEscalation": true }' https://api.access.redhat.com/support/v1/cases/0000000
curl -X POST -H 'Content-Type: application/json -H 'Authorization: Bearer USDtoken' --data '{ "commentBody": "Test comment! This can contain lots of information, etc." }' https://api.access.redhat.com/support/v1/cases/0000000/comments
curl -X POST -F 'file=@test.txt' -H 'Authorization: Bearer USDtoken' https://api.access.redhat.com/support/v1/cases/0000000/attachments
Chapter 13. Remotely accessing an X11-based application You can remotely launch a graphical X11-based application on a RHEL server and use it from the remote client using X11 forwarding. Note This procedure works for legacy X11 applications, that is, applications that support the X11 display protocol. 13.1. Enabling X11 forwarding on the server Configure a RHEL server so that remote clients can use graphical applications on the server over SSH. Procedure Install basic X11 packages: Note Your applications might rely on additional graphical libraries. Enable the X11Forwarding option in the /etc/ssh/sshd_config configuration file: The option is disabled by default in RHEL. Restart the sshd service: 13.2. Launching an application remotely using X11 forwarding Access a graphical application on a RHEL server from a remote client using SSH. Prerequisites X11 forwarding over SSH is enabled on the server. For details, see Section 13.1, "Enabling X11 forwarding on the server" . Ensure that an X11 display server is running on your system: On RHEL, X11 is available by default in the graphical interface. On Microsoft Windows, install an X11 server such as Xming. On macOS, install the XQuartz X11 server. You have configured and restarted an OpenSSH server. For details, see Configuring and starting an OpenSSH server . Procedure Log in to the server using SSH: Confirm that a server key is valid by checking its fingerprint. Note If you plan to log in to the server on a regular basis, add the user's public key to the server using the ssh-copy-id command. Continue connecting by typing yes . When prompted, type the server password. Launch the application from the command line: Tip To skip the intermediate terminal session, use the following command: 13.3. Additional resources Remotely accessing an individual application on Wayland . Key differences between the Wayland and X11 protocol .

Commands:
dnf install xorg-x11-xauth xorg-x11-fonts-\* xorg-x11-utils dbus-x11
X11Forwarding yes
systemctl restart sshd.service
[local-user]USD ssh -X -Y remote-server The authenticity of host 'remote-server (192.168.122.120)' can't be established. ECDSA key fingerprint is SHA256: uYwFlgtP/2YABMHKv5BtN7nHK9SHRL4hdYxAPJVK/kY . Are you sure you want to continue connecting (yes/no/[fingerprint])?
Warning: Permanently added ' remote-server ' (ECDSA) to the list of known hosts.
local-user's password: [local-user ~]USD
[remote-user]USD application-binary
ssh user@server -X -Y -C binary_application
Chapter 1. RBAC APIs 1.1. ClusterRoleBinding [rbac.authorization.k8s.io/v1] Description ClusterRoleBinding references a ClusterRole, but not contain it. It can reference a ClusterRole in the global namespace, and adds who information via Subject. Type object 1.2. ClusterRole [rbac.authorization.k8s.io/v1] Description ClusterRole is a cluster level, logical grouping of PolicyRules that can be referenced as a unit by a RoleBinding or ClusterRoleBinding. Type object 1.3. RoleBinding [rbac.authorization.k8s.io/v1] Description RoleBinding references a role, but does not contain it. It can reference a Role in the same namespace or a ClusterRole in the global namespace. It adds who information via Subjects and namespace information by which namespace it exists in. RoleBindings in a given namespace only have effect in that namespace. Type object 1.4. Role [rbac.authorization.k8s.io/v1] Description Role is a namespaced, logical grouping of PolicyRules that can be referenced as a unit by a RoleBinding. Type object

Commands:
6.7. Displaying Configured Resources To display a list of all configured resources, use the following command. For example, if your system is configured with a resource named VirtualIP and a resource named WebSite , the pcs resource show command yields the following output. To display the configured parameters for a resource, use the following command. For example, the following command displays the currently configured parameters for resource VirtualIP .

Commands:
pcs resource show
pcs resource show VirtualIP (ocf::heartbeat:IPaddr2): Started WebSite (ocf::heartbeat:apache): Started
pcs resource show resource_id
pcs resource show VirtualIP Resource: VirtualIP (type=IPaddr2 class=ocf provider=heartbeat) Attributes: ip=192.168.0.120 cidr_netmask=24 Operations: monitor interval=30s
5.61. expect 5.61.1. RHBA-2012:0456 - expect bug fix update An updated expect package that fixes multiple bugs is now available for Red Hat Enterprise Linux 6. The "expect" package contains a tool for automating and testing interactive command line programs and Tk applications. Tcl is a portable and widely used scripting language, while Tk is a graphical toolkit that eases development of text-based and GUI applications. Bug Fixes BZ# 674866 Prior to this update, the expect(1) manual page was not formatted properly. As a result, the content of the manual page was not readable. The formatting has been corrected to ensure easy readability. BZ# 735962 Prior to this update, the passmass script did not call the "su" binary with the full path (/bin/su). The passmass script has been modified to call "/bin/su" rather than "su", which is more secure. BZ# 742911 Due to incorrect characters matching, applications created by the autoexpect utility could terminate unexpectedly with a segmentation fault. With this update, the number of characters is matched correctly and applications created by autoexpect run successfully. BZ# 782859 Previously, the expect-devel subpackage contained a symbolic link to the expect library, which led to an unnecessary dependency. With this update, the link is located in the expect package. All users of expect are advised to upgrade to this updated package, which fixes these bugs.

Commands:
4.4.7. Displaying Logical Volumes There are three commands you can use to display properties of LVM logical volumes: lvs , lvdisplay , and lvscan . The lvs command provides logical volume information in a configurable form, displaying one line per logical volume. The lvs command provides a great deal of format control, and is useful for scripting. For information on using the lvs command to customize your output, see Section 4.9, "Customized Reporting for LVM" . The lvdisplay command displays logical volume properties (such as size, layout, and mapping) in a fixed format. The following command shows the attributes of lvol2 in vg00 . If snapshot logical volumes have been created for this original logical volume, this command shows a list of all snapshot logical volumes and their status (active or inactive) as well. The lvscan command scans for all logical volumes in the system and lists them, as in the following example.

Commands:
lvdisplay -v /dev/vg00/lvol2
lvscan ACTIVE '/dev/vg0/gfslv' [1.46 GB] inherit
Appendix A. Collecting Information for Troubleshooting IdM and SSSD Running in a Container This appendix describes procedures that help you to troubleshoot IdM and SSSD running in a container, as well as collecting important configuration and log files that you can attach to Red Hat support tickets. A.1. Creating an sosreport on Atomic Host This section describes how to install and start the rhel7/rhel-tools container, as well as creating an sosreport . The rhel7/rhel-tools container uses privileged security switches that enables processes running in this container: To interact with all semaphores and shared memory segments on the host To listen to ports and raw IP traffic on the host's network Interact with all processes on the host Note that rhel7/rhel-tools runs without any separation from the host. Using the utilities provided by this container is similar as running them as the root user directly on the system. Procedure Install the rhel7/rhel-tools container: Start the rhel7/rhel-tools container: Run the sosreport utility: The utility stores the archive of the collected information in the /host/var/tmp/sos_tal4k_* file. Enter exit to leave the container. Attach the sosreport archive to a support request. A.2. Displaying the versions of IdM and SSSD containers This section describes how to display the version of installed IdM and SSSD containers. For example, use this information to search the Red Hat Enterprise Linux Release Notes if a problem has been fixed in a newer version. Procedure Display the version of the rhel7/ipa-server container: Display the version of the rhel7/sssd container: A.3. Creating debug logs for SSSD running in a container This section describes how to create an archive with important SSSD configuration and log files. Procedure Stop the sssd container: Remove the contents of the SSSD cache and log directories: Edit the /etc/sssd/sssd.conf file, and set the debug_level parameters to 9 : Start the sssd container: Create the /tmp/sssd-debug.tar.gz archive that contains the relevant SSSD configuration and log files: Attach the /tmp/sssd-debug.tar.gz file to the support case. A.4. Displaying the IdM client installation log This section describes how you display the IdM client installation log. The log files help you to debug the problem if the client installation fails. Procedure To display the IdM client installation log:

Commands:
docker pull rhel7/rhel-tools
atomic run rhel7/rhel-tools
sosreport
exit
atomic images version rhel7/ipa-server IMAGE NAME VERSION IMAGE ID registry.access.redhat.com/rhel7/ipa-server:latest 4.6.5-29 9d500a8e4296
atomic images version rhel7/sssd IMAGE NAME VERSION IMAGE ID registry.access.redhat.com/rhel7/sssd:latest 7.7-12 19e5cab1c905
docker stop sssd
rm -rf /var/lib/sss/db/* /var/lib/sss/mc/* /var/log/sssd/*
[domain/ dockerlab.local ] debug_level = 9 [nss] debug_level = 9
docker start sssd
tar czvf /tmp/sssd-debug.tar.gz /etc/sssd/sssd.conf /etc/nsswitch.conf /etc/krb5.conf /etc/pam.d /etc/samba/smb.conf /var/log/secure /var/log/messages /var/log/sssd
cat /var/log/sssd/install/ipaclient-install.log