mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 9. Reporting on user access on hosts using SSSD The Security System Services Daemon (SSSD) tracks which users can or cannot access clients. This chapter describes creating access control reports and displaying user data using the sssctl tool. Prerequisites SSSD packages are installed in your network environment 9.1. The sssctl command sssctl is a command-line tool that provides a unified way to obtain information about the Security System Services Daemon (SSSD) status. You can use the sssctl utility to gather information about: Domain state Client user authentication User access on clients of a particular domain Information about cached content With the sssctl tool, you can: Manage the SSSD cache Manage logs Check configuration files Note The sssctl tool replaces sss_cache and sss_debuglevel tools. Additional resources sssctl --help 9.2. Generating access control reports using sssctl You can list the access control rules applied to the machine on which you are running the report because SSSD controls which users can log in to the client. Note The access report is not accurate because the tool does not track users locked out by the Key Distribution Center (KDC). Prerequisites You must be logged in with administrator privileges The sssctl tool is available on RHEL 7 and RHEL 8 systems. Procedure To generate a report for the idm.example.com domain, enter: 9.3. Displaying user authorization details using sssctl The sssctl user-checks command helps debug problems in applications that use the System Security Services Daemon (SSSD) for user lookup, authentication, and authorization. The sssctl user-checks [USER_NAME] command displays user data available through Name Service Switch (NSS) and the InfoPipe responder for the D-Bus interface. The displayed data shows whether the user is authorized to log in using the system-auth Pluggable Authentication Module (PAM) service. The command has two options: -a for a PAM action -s for a PAM service If you do not define -a and -s options, the sssctl tool uses default options: -a acct -s system-auth . Prerequisites You must be logged in with administrator privileges The sssctl tool is available on RHEL 7 and RHEL 8 systems. Procedure To display user data for a particular user, enter: Additional resources sssctl user-checks --help

Commands:
sssctl access-report idm.example.com 1 rule cached Rule name: example.user Member users: example.user Member services: sshd
sssctl user-checks -a acct -s sshd example.user user: example.user action: acct service: sshd .
Chapter 27. JvmOptions schema reference Used in: CruiseControlSpec , EntityTopicOperatorSpec , EntityUserOperatorSpec , KafkaBridgeSpec , KafkaClusterSpec , KafkaConnectSpec , KafkaMirrorMaker2Spec , KafkaMirrorMakerSpec , KafkaNodePoolSpec , ZookeeperClusterSpec Property Description -XX A map of -XX options to the JVM. map -Xms -Xms option to to the JVM. string -Xmx -Xmx option to to the JVM. string gcLoggingEnabled Specifies whether the Garbage Collection logging is enabled. The default is false. boolean javaSystemProperties A map of additional system properties which will be passed using the -D option to the JVM. SystemProperty array

Commands:
5. Feedback If you spot a typo, or if you have thought of a way to make this manual better, we would love to hear from you. Please submit a report in Bugzilla ( http://bugzilla.redhat.com/bugzilla/ ) against the component rh-cs . Be sure to mention the manual's identifier: By mentioning this manual's identifier, we know exactly which version of the guide you have. If you have a suggestion for improving the documentation, try to be as specific as possible. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.

Commands:
rh-gfs(EN)-4.8 (2009-05-15T15:10)
Chapter 1. Migration Overview When you specify a backup file during self-hosted engine deployment, the Manager backup is restored on a new virtual machine, with a dedicated self-hosted engine storage domain. Deploying on a fresh host is highly recommended; if the host used for deployment existed in the backed up environment, it will be removed from the restored database to avoid conflicts in the new environment. If you deploy on a new host, you must assign a unique name to the host. Reusing the name of an existing host included in the backup can cause conflicts in the new environment. At least two self-hosted engine nodes are required for the Manager virtual machine to be highly available. You can add new nodes, or convert existing hosts. The migration involves the following key steps: Install a new host to deploy the self-hosted engine on. You can use either host type: Red Hat Virtualization Host Red Hat Enterprise Linux Prepare storage for the self-hosted engine storage domain. You can use one of the following storage types: NFS iSCSI Fibre Channel (FCP) Red Hat Gluster Storage Update the original Manager to the latest minor version before you back it up. Back up the original Manager using the engine-backup tool. Deploy a new self-hosted engine and restore the backup. Enable the Manager repositories on the new Manager virtual machine. Convert regular hosts to self-hosted engine nodes that can host the new Manager. This procedure assumes that you have access and can make changes to the original Manager. Prerequisites FQDNs prepared for your Manager and the deployment host. Forward and reverse lookup records must both be set in the DNS. The new Manager must have the same FQDN as the original Manager. The management network ( ovirtmgmt by default) must be configured as a VM network , so that it can manage the Manager virtual machine.

Commands:
Chapter 4. Setting up Enterprise Security Client The following sections contain basic instructions on using the Enterprise Security Client for token enrollment, formatting, and password reset operations. 4.1. Installing the Smart Card Package Group Packages used to manage smart cards, such as esc , should already be installed on the Red Hat Enterprise Linux system. If the packages are not installed or need to be updated, all of the smart card-related packages can be pulled in by installing the Smart card support package group. For example:

Commands:
groupinstall "Smart card support"
4.6. iSCSI and DM Multipath overrides The recovery_tmo sysfs option controls the timeout for a particular iSCSI device. The following options globally override recovery_tmo values: The replacement_timeout configuration option globally overrides the recovery_tmo value for all iSCSI devices. For all iSCSI devices that are managed by DM Multipath, the fast_io_fail_tmo option in DM Multipath globally overrides the recovery_tmo value. The fast_io_fail_tmo option in DM Multipath also overrides the fast_io_fail_tmo option in Fibre Channel devices. The DM Multipath fast_io_fail_tmo option takes precedence over replacement_timeout . Red Hat does not recommend using replacement_timeout to override recovery_tmo in devices managed by DM Multipath because DM Multipath always resets recovery_tmo when the multipathd service reloads.

Commands:
18.2. Consoles and Logging During the Installation The following sections describe how to access logs and an interactive shell during the installation. This is useful when troubleshooting problems, but should not be necessary in most cases. 18.2.1. Accessing Consoles The Red Hat Enterprise Linux installer uses the tmux terminal multiplexer to display and control several windows you can use in addition to the main interface. Each of these windows serves a different purpose - they display several different logs, which can be used to troubleshoot any issues during the installation, and one of the windows provides an interactive shell prompt with root privileges, unless this prompt was specifically disabled using a boot option or a Kickstart command. Note In general, there is no reason to leave the default graphical installation environment unless you need to diagnose an installation problem. The terminal multiplexer is running in virtual console 1. To switch from the graphical installation environment to tmux , press Ctrl + Alt + F1 . To go back to the main installation interface which runs in virtual console 6, press Ctrl + Alt + F6 . Note If you choose text mode installation, you will start in virtual console 1 ( tmux ), and switching to console 6 will open a shell prompt instead of a graphical interface. The console running tmux has 5 available windows; their contents are described in the table below, along with keyboard shortcuts used to access them. Note that the keyboard shortcuts are two-part: first press Ctrl + b , then release both keys, and press the number key for the window you want to use. You can also use Ctrl + b n and Ctrl + b p to switch to the or tmux window, respectively. Table 18.1. Available tmux Windows Shortcut Contents Ctrl + b 1 Main installation program window. Contains text-based prompts (during text mode installation or if you use VNC Direct Mode), and also some debugging information. Ctrl + b 2 Interactive shell prompt with root privileges. Ctrl + b 3 Installation log; displays messages stored in /tmp/anaconda.log . Ctrl + b 4 Storage log; displays messages related storage devices from kernel and system services, stored in /tmp/storage.log . Ctrl + b 5 Program log; displays messages from other system utilities, stored in /tmp/program.log . In addition to displaying diagnostic information in tmux windows, Anaconda also generates several log files, which can be transferred from the installation system. These log files are described in Table 19.1, "Log Files Generated During the Installation" , and directions for transferring them from the installation system are available in Chapter 19, Troubleshooting Installation on IBM Z . 18.2.2. Saving Screenshots You can press Shift + Print Screen at any time during the graphical installation to capture the current screen. These screenshots are saved to /tmp/anaconda-screenshots/ . Additionally, you can use the autostep --autoscreenshot command in a Kickstart file to capture and save each step of the installation automatically. See Section 27.3.1, "Kickstart Commands and Options" for details.

Commands:
Chapter 4. Clustering systemd and pacemaker now coordinate correctly during system shutdown Previously, systemd and pacemaker did not coordinate correctly during system shutdown, which caused pacemaker resources not to be terminated properly. With this update, pacemaker is ordered to stop before dbus and other systemd services that pacemaker started. This allows both pacemaker and the resources that pacemaker manages to shut down properly. The pcs resource move and pcs resource ban commands now display a warning message to clarify the commands' behavior The pcs resource move command and the pcs resource ban commands create location constraints that that effectively ban the resource from running on the current node until the constraint is removed or until the constraint lifetime expires. This behavior had previously not been clear to users. These commands now display a warning message explaining this behavior, and the help screens and documentation for these commands have been clarified. New command to move a Pacemaker resource to its preferred node After a Pacemaker resource has moved, either due to a failover or to an administrator manually moving the node, it will not necessarily move back to its original node even after the circumstances that caused the failover have been corrected. You can now use the pcs resource relocate run command to move a resource to its preferred node, as determined by current cluster status, constraints, location of resources and other settings. You can also use the pcs resource relocate show command to display migrated resources. For information on these commands, see the High Availability Add-On Reference. Simplified method for configuring fencing for redundant power supplies in a cluster When configuring fencing for redundant power supplies, you must ensure that when the power supplies are rebooted both power supplies are turned off before either power supply is turned back on. If the node never completely loses power, the node may not release its resources. This opens up the possibility of nodes accessing these resources simultaneously and corrupting them. Prior to Red Hat Enterprise Linux 7.2, you needed to explicitly configure different versions of the devices which used either the 'on' or 'off' actions. Since Red Hat Enterprise Linux 7.2, it is now only required to define each device once and to specify that both are required to fence the node. For information on configuring fencing for redundant power supplies, see the Fencing: Configuring STONITH chapter of the High Availability Add-On Reference manual. New --port-as-ip option for fencing agents Fence agents used only with single devices required complex configuration in pacemaker. It is now possible to use the --port-as-ip option to enter the IP address in the port option.

Commands:
4.8. The file_t and default_t Types When using a file system that supports extended attributes (EA), the file_t type is the default type of a file that has not yet been assigned EA value. This type is only used for this purpose and does not exist on correctly-labeled file systems, because all files on a system running SELinux should have a proper SELinux context, and the file_t type is never used in file-context configuration [4] . The default_t type is used on files that do not match any pattern in file-context configuration, so that such files can be distinguished from files that do not have a context on disk, and generally are kept inaccessible to confined domains. For example, if you create a new top-level directory, such as mydirectory/ , this directory may be labeled with the default_t type. If services need access to this directory, you need to update the file-contexts configuration for this location. See Section 4.7.2, "Persistent Changes: semanage fcontext" for details on adding a context to the file-context configuration. [4] Files in the /etc/selinux/targeted/contexts/files/ directory define contexts for files and directories. Files in this directory are read by the restorecon and setfiles utilities to restore files and directories to their default contexts.

Commands:
Chapter 1. Overview Cockpit is a system administration tool that provides a user interface for monitoring and administering servers through a web browser. It allows you to monitor current values and adjust limits on system resources, control life cycle on container instances, and manipulate container images. Here are a few important facts about Cockpit: Cockpit does not add a layer of other functionalities that are not present on your systems. It exposes user interface elements that enable you to interact with the system. Cockpit does not take control over your servers, in a way that when you configure something from Cockpit, you can only manage it from there. You can effectively move away from Cockpit to the command-line and come back to it at any point. Cockpit does not require configuration or infrastructure, and once you install it, it is ready for use. You could, however, configure it to make use of the authentication infrastructure that is available to you, for example a single sign-on system like Kerberos. Cockpit has zero memory and process footprint on the server when not in use. Cockpit does not store data or policy. This also means it does not have its own users. The users from the systems can authenticate in Cockpit using their system credentials and they keep the same permissions. Cockpit dynamically updates itself to reflect the current state of the server, within a time frame of a few seconds. Cockpit is not intended for configuration management. This means that Cockpit itself does not have a predefined template or state for the server that it then imposes on the server. Cockpit can interact with other configuration management systems or custom tools that are manipulating server configuration. This document provides instructions on how to install and enable Cockpit so you can monitor your servers, describes basic configuration, and walks you through the interface. Both Red Hat Enterprise Linux and Red Hat Enterprise Linux Atomic Host can be used for the role of a Cockpit server and that of a secondary server. In this document, all monitored systems are Atomic, but the instructions also cover how to set up Red Hat Enterprise Linux as a primary server. Note Cockpit does not yet have support for Kubernetes on Red Hat Enterprise Linux or Red Hat Enterprise Linux Atomic Host servers.

Commands:
Chapter 16. Uninstalling Certificate System subsystems It is possible to remove individual subsystems or to uninstall all packages associated with an entire subsystem. Subsystems are installed and uninstalled individually. For example, it is possible to uninstall a KRA subsystem while leaving an installed and configured CA subsystem. It is also possible to remove a single CA subsystem while leaving other CA subsystems on the machine. 16.1. Removing a subsystem Removing a subsystem requires specifying the subsystem type and the name of the server in which the subsystem is running. This command removes all files associated with the subsystem (without removing the subsystem packages). The -s option specifies the subsystem to be removed (such as CA, KRA, OCSP, TKS, or TPS). The -i option specifies the instance name, such as pki-tomcat . For example, to remove a CA subsystem: The pkidestroy utility removes the subsystem and any related files, such as the certificate databases, certificates, keys, and associated users. It does not uninstall the subsystem packages. If the subsystem is the last subsystem on the server instance, the server instance is removed as well. 16.2. Removing Certificate System subsystem packages A number of subsystem-related packages and dependencies are installed with Red Hat Certificate System; these are listed in Section 6.9, "Installing RHCS and RHDS packages" . Removing a subsystem removes only the files and directories associated with that specific subsystem. It does not remove the actual installed packages that are used by that instance. Completely uninstalling Red Hat Certificate System or one of its subsystems requires using package management tools, like yum , to remove each package individually. To uninstall an individual Certificate System subsystem package: Remove all the associated subsystems. For example: Run the uninstall utility. For example: The subsystem type can be ca , kra , ocsp , tks , or tps . To remove other packages and dependencies, remove the packages specifically, using yum . The complete list of installed packages is at Section 6.9, "Installing RHCS and RHDS packages" .

Commands:
pkidestroy -s subsystem_type -i instance_name
pkidestroy -s CA -i pki-tomcat Loading deployment configuration from /var/lib/pki/pki-tomcat/ca/registry/ca/deployment.cfg. Uninstalling CA from /var/lib/pki/pki-tomcat. Removed symlink /etc/systemd/system/multi-user.target.wants/pki-tomcatd.target. Uninstallation complete.
pkidestroy -s CA -i pki-tomcat
yum remove pki-subsystem_type
17.13. Dynamically Changing a Host Physical Machine or a Network Bridge that is Attached to a Virtual NIC This section demonstrates how to move the vNIC of a guest virtual machine from one bridge to another while the guest virtual machine is running without compromising the guest virtual machine Prepare guest virtual machine with a configuration similar to the following: Prepare an XML file for interface update: Start the guest virtual machine, confirm the guest virtual machine's network functionality, and check that the guest virtual machine's vnetX is connected to the bridge you indicated. Update the guest virtual machine's network with the new interface parameters with the following command: On the guest virtual machine, run service network restart . The guest virtual machine gets a new IP address for virbr1. Check the guest virtual machine's vnet0 is connected to the new bridge(virbr1)

Commands:
<interface type='bridge'> <mac address='52:54:00:4a:c9:5e'/> <source bridge='virbr0'/> <model type='virtio'/> </interface>
cat br1.xml
<interface type='bridge'> <mac address='52:54:00:4a:c9:5e'/> <source bridge='virbr1'/> <model type='virtio'/> </interface>
brctl show bridge name bridge id STP enabled interfaces virbr0 8000.5254007da9f2 yes virbr0-nic vnet0 virbr1 8000.525400682996 yes virbr1-nic
virsh update-device test1 br1.xml Device updated successfully
brctl show bridge name bridge id STP enabled interfaces virbr0 8000.5254007da9f2 yes virbr0-nic virbr1 8000.525400682996 yes virbr1-nic vnet0
Chapter 8. Managing projects A Project is a logical collection of Ansible playbooks, represented in automation controller. You can manage playbooks and playbook directories different ways: By placing them manually under the Project Base Path on your automation controller server. By placing your playbooks into a source code management (SCM) system supported by the automation controller. These include Git, Subversion, and Mercurial. Note This Getting Started Guide uses lightweight examples to get you up and running. But for production purposes, you must use source control to manage your playbooks. The best practice is to treat your infrastructure as code which is in line with DevOps ideals. 8.1. Setting up a project Automation controller simplifies the startup process by providing you with a Demo Project that you can work with initially. Procedure To review existing projects, select Resources Projects from the navigation panel. Click Demo Project to view its details. 8.2. Editing a project As part of the initial setup you can leave the default Demo Project as it is. You can edit it later. Procedure Open the project to edit it by using one of these methods: Go to the project Details page and click Edit . From the navigation panel, select Resources Projects . Click Edit to the project name and edit the appropriate details. Save your changes 8.3. Syncing a project If you want to fetch the latest changes in a project, you can manually start an SCM sync for this project. Procedure Open the project to update the SCM-based demo project by using one of these methods: Go to the project Details page and click Sync . From the navigation panel, select Resources Projects and click Sync Project . Note When you add a project set up to use source control, a "sync" starts. This fetches the project details from the configured source control.

Commands: