mtpti5iD/redhat-docs_dataset huggingface dataset:
13.9. Single-application Mode Single-application mode is a modified shell which reconfigures the shell into an interactive kiosk. The administrator locks down some behavior to make the standard desktop more restrictive for the user, letting them focus on selected features. Set up single-application mode for a wide range of functions in a number of fields (from communication to entertainment or education) and use it as a self-serve machine, event manager, registration point, etc. Procedure 13.9. Set Up Single-application Mode Create the following files with the following content: /usr/bin/redhat-kiosk Important The /usr/bin/redhat-kiosk file must be executable. Replace the gedit ~/.local/bin/redhat-kiosk code by the commands that you want to execute in the kiosk session. This example launches a full-screen application designed for the kiosk deployment named http://mine-kios-web-app : /usr/share/applications/com.redhat.Kiosk.Script.desktop /usr/share/applications/com.redhat.Kiosk.WindowManager.desktop /usr/share/gnome-session/sessions/redhat-kiosk.session /usr/share/xsessions/com.redhat.Kiosk.desktop Restart the GDM service: Create a separate user for the kiosk session and select Kiosk as the session type for the user of the kiosk session. Figure 13.1. Selecting the kiosk session By starting the Kiosk session, the user launches a full screen application designed for the kiosk deployment.

Commands:
#!/bin/sh if [ ! -e ~/.local/bin/redhat-kiosk ]; then mkdir -p ~/.local/bin ~/.config cat > ~/.local/bin/redhat-kiosk << EOF #!/bin/sh This script is located in ~/.local/bin. It's provided as an example script to show how the kiosk session works. At the moment, the script just starts a text editor open to itself, but it should get customized to instead start a full screen application designed for the kiosk deployment. The "while true" bit just makes sure the application gets restarted if it dies for whatever reason. while true; do gedit ~/.local/bin/redhat-kiosk done EOF chmod +x ~/.local/bin/redhat-kiosk touch ~/.config/gnome-initial-setup-done fi exec ~/.local/bin/redhat-kiosk "USD@"
[...] while true; do firefox --kiosk http://mine-kios-web-app done [...]
[Desktop Entry] Name=Kiosk Type=Application Exec=redhat-kiosk
[Desktop Entry] Type=Application Name=Mutter Comment=Window manager Exec=/usr/bin/mutter Categories=GNOME;GTK;Core; OnlyShowIn=GNOME; NoDisplay=true X-GNOME-Autostart-Phase=DisplayServer X-GNOME-Provides=windowmanager; X-GNOME-Autostart-Notify=true X-GNOME-AutoRestart=false X-GNOME-HiddenUnderSystemd=true
[GNOME Session] Name=Kiosk RequiredComponents=com.redhat.Kiosk.WindowManager;com.redhat.Kiosk.Script;
[Desktop Entry] Name=Kiosk Comment=Kiosk mode Exec=/usr/bin/gnome-session --session=redhat-kiosk DesktopNames=Red-Hat-Kiosk;GNOME;
systemctl restart gdm.service
Chapter 4. Installing and Uninstalling Identity Management Replicas Replicas are created by cloning the configuration of existing Identity Management servers. Therefore, servers and their replicas share identical core configuration. The replica installation process copies the existing server configuration and installs the replica based on that configuration. Maintaining several server replicas is a recommended backup solution to avoid data loss, as described in the "Backup and Restore in IdM/IPA" Knowledgebase solution . Note Another backup solution, recommended primarily for situations when rebuilding the IdM deployment from replicas is not possible, is the ipa-backup utility, as described in Chapter 9, Backing Up and Restoring Identity Management . 4.1. Explaining IdM Replicas To provide service availability and redundancy for large numbers of clients, you can deploy multiple IdM servers, called replicas , in a single domain. Replicas are clones of the initial IdM server that are functionally identical to each other: they share the same internal information about users, machines, certificates, and configured policies. There are, however, two unique server roles that only one server in the environment can fulfill at a time: CA Renewal Server : this server manages renewal of Certificate Authority (CA) subsystem certificates CRL Generation Server : this server generates certificate revocation lists (CRLs). By default, the first CA server installed fulfills both CA Renewal Server and CRL Generation Server roles. You can transition these roles to any other CA server in the topology, for example if you need to decommission the initially installed server. Both roles do not have to be fulfilled by the same server. Note For more information on the types of machines in the IdM topology, see Section 1.2, "The Identity Management Domain" . Replication is the process of copying data between replicas. The information between replicas is shared using multi-master replication : all replicas joined through a replication agreement receive updates and are therefore considered data masters. Figure 4.1. Server and Replica Agreements

Commands:
Chapter 13. High availability configuration for Knative Serving 13.1. High availability for Knative services High availability (HA) is a standard feature of Kubernetes APIs that helps to ensure that APIs stay operational if a disruption occurs. In an HA deployment, if an active controller crashes or is deleted, another controller is readily available. This controller takes over processing of the APIs that were being serviced by the controller that is now unavailable. HA in OpenShift Serverless is available through leader election, which is enabled by default after the Knative Serving or Eventing control plane is installed. When using a leader election HA pattern, instances of controllers are already scheduled and running inside the cluster before they are required. These controller instances compete to use a shared resource, known as the leader election lock. The instance of the controller that has access to the leader election lock resource at any given time is called the leader. 13.2. High availability for Knative deployments High availability (HA) is available by default for the Knative Serving activator , autoscaler , autoscaler-hpa , controller , webhook , domain-mapping , domainmapping-webhook , kourier-control , and kourier-gateway components, which are configured to have two replicas each. You can change the number of replicas for these components by modifying the spec.high-availability.replicas value in the KnativeServing custom resource (CR). 13.2.1. Configuring high availability replicas for Knative Serving To specify three minimum replicas for the eligible deployment resources, set the value of the field spec.high-availability.replicas in the custom resource to 3 . Prerequisites You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated. The OpenShift Serverless Operator and Knative Serving are installed on your cluster. Procedure In the OpenShift Container Platform web console Administrator perspective, navigate to OperatorHub Installed Operators . Select the knative-serving namespace. Click Knative Serving in the list of Provided APIs for the OpenShift Serverless Operator to go to the Knative Serving tab. Click knative-serving , then go to the YAML tab in the knative-serving page. Modify the number of replicas in the KnativeServing CR: Example YAML apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: high-availability: replicas: 3

Commands:
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: high-availability: replicas: 3
20.2.2. Host Physical Machine Boot Loader Hypervisors employing paravirtualization do not usually emulate a BIOS, but instead the host physical machine is responsible for the operating system boot. This may use a pseudo-bootloader in the host physical machine to provide an interface to choose a kernel for the guest virtual machine. An example is pygrub with Xen. ... <bootloader>/usr/bin/pygrub</bootloader> <bootloader_args>--append single</bootloader_args> ... Figure 20.3. Host physical machine boot loader domain XML The components of this section of the domain XML are as follows: Table 20.3. BIOS boot loader elements Element Description <bootloader> provides a fully qualified path to the boot loader executable in the host physical machine OS. This boot loader will choose which kernel to boot. The required output of the boot loader is dependent on the hypervisor in use. <bootloader_args> allows command line arguments to be passed to the boot loader (optional command)

Commands:
<bootloader>/usr/bin/pygrub</bootloader> <bootloader_args>--append single</bootloader_args>
B.96. thunderbird B.96.1. RHSA-2010:0896 - Moderate: thunderbird security update An updated thunderbird package that fixes several security issues is now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. Common Vulnerability Scoring System (CVSS) base scores, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Mozilla Thunderbird is a standalone mail and newsgroup client. CVE-2010-3765 A race condition flaw was found in the way Thunderbird handled Document Object Model (DOM) element properties. An HTML mail message containing malicious content could cause Thunderbird to crash or, potentially, execute arbitrary code with the privileges of the user running Thunderbird. CVE-2010-3175 , CVE-2010-3176 , CVE-2010-3179 , CVE-2010-3180 , CVE-2010-3183 Several flaws were found in the processing of malformed HTML mail content. An HTML mail message containing malicious content could cause Thunderbird to crash or, potentially, execute arbitrary code with the privileges of the user running Thunderbird. CVE-2010-3178 A same-origin policy bypass flaw was found in Thunderbird. Remote HTML content could steal private data from different remote HTML content Thunderbird had loaded. Note Note that JavaScript support is disabled by default in Thunderbird. The above issues are not exploitable unless JavaScript is enabled. CVE-2010-3182 A flaw was found in the script that launches Thunderbird. The LD_LIBRARY_PATH variable was appending a "." character, which could allow a local attacker to execute arbitrary code with the privileges of a different user running Thunderbird, if that user ran Thunderbird from within an attacker-controlled directory. All Thunderbird users should upgrade to this updated package, which resolves these issues. All running instances of Thunderbird must be restarted for the update to take effect.

Commands:
20.2.3. Direct kernel boot When installing a new guest virtual machine OS, it is often useful to boot directly from a kernel and initrd stored in the host physical machine OS, allowing command line arguments to be passed directly to the installer. This capability is usually available for both para and full virtualized guest virtual machines. ... <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <kernel>/root/f8-i386-vmlinuz</kernel> <initrd>/root/f8-i386-initrd</initrd> <cmdline>console=ttyS0 ks=http://example.com/f8-i386/os/</cmdline> <dtb>/root/ppc.dtb</dtb> </os> ... Figure 20.4. Direct Kernel Boot The components of this section of the domain XML are as follows: Table 20.4. Direct kernel boot elements Element Description <type> same as described in the BIOS boot section <loader> same as described in the BIOS boot section <kernel> specifies the fully-qualified path to the kernel image in the host physical machine OS <initrd> specifies the fully-qualified path to the (optional) ramdisk image in the host physical machine OS. <cmdline> specifies arguments to be passed to the kernel (or installer) at boot time. This is often used to specify an alternate primary console (eg serial port), or the installation media source / kickstart file

Commands:
<os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <kernel>/root/f8-i386-vmlinuz</kernel> <initrd>/root/f8-i386-initrd</initrd> <cmdline>console=ttyS0 ks=http://example.com/f8-i386/os/</cmdline> <dtb>/root/ppc.dtb</dtb> </os>
18.12.10. Supported Protocols The following sections list and give some details about the protocols that are supported by the network filtering subsystem. This type of traffic rule is provided in the rule node as a nested node. Depending on the traffic type a rule is filtering, the attributes are different. The above example showed the single attribute srcipaddr that is valid inside the ip traffic filtering node. The following sections show what attributes are valid and what type of data they are expecting. The following datatypes are available: UINT8 : 8 bit integer; range 0-255 UINT16: 16 bit integer; range 0-65535 MAC_ADDR: MAC address in dotted decimal format, such as 00:11:22:33:44:55 MAC_MASK: MAC address mask in MAC address format, such as FF:FF:FF:FC:00:00 IP_ADDR: IP address in dotted decimal format, such as 10.1.2.3 IP_MASK: IP address mask in either dotted decimal format (255.255.248.0) or CIDR mask (0-32) IPV6_ADDR: IPv6 address in numbers format, such as FFFF::1 IPV6_MASK: IPv6 mask in numbers format (FFFF:FFFF:FC00::) or CIDR mask (0-128) STRING: A string BOOLEAN: 'true', 'yes', '1' or 'false', 'no', '0' IPSETFLAGS: The source and destination flags of the ipset described by up to 6 'src' or 'dst' elements selecting features from either the source or destination part of the packet header; example: src,src,dst. The number of 'selectors' to provide here depends on the type of ipset that is referenced Every attribute except for those of type IP_MASK or IPV6_MASK can be negated using the match attribute with value no . Multiple negated attributes may be grouped together. The following XML fragment shows such an example using abstract attributes. Rules behave evaluate the rule as well as look at it logically within the boundaries of the given protocol attributes. Thus, if a single attribute's value does not match the one given in the rule, the whole rule will be skipped during the evaluation process. Therefore, in the above example incoming traffic will only be dropped if: the protocol property attribute1 does not match both value1 and the protocol property attribute2 does not match value2 and the protocol property attribute3 matches value3 . 18.12.10.1. MAC (Ethernet) Protocol ID: mac Rules of this type should go into the root chain. Table 18.3. MAC protocol types Attribute Name Datatype Definition srcmacaddr MAC_ADDR MAC address of sender srcmacmask MAC_MASK Mask applied to MAC address of sender dstmacaddr MAC_ADDR MAC address of destination dstmacmask MAC_MASK Mask applied to MAC address of destination protocolid UINT16 (0x600-0xffff), STRING Layer 3 protocol ID. Valid strings include [arp, rarp, ipv4, ipv6] comment STRING text string up to 256 characters The filter can be written as such:

Commands:
[...] <rule action='drop' direction='in'> <protocol match='no' attribute1='value1' attribute2='value2'/> <protocol attribute3='value3'/> </rule> [...]
[...] <mac match='no' srcmacaddr='USDMAC'/> [...]
22.2. Enabling Tracking of Last Successful Kerberos Authentication For performance reasons, IdM running on Red Hat Enterprise Linux 7.4 and later does not store the time stamp of the last successful Kerberos authentication of a user. As a consequence, certain commands, such as ipa user-status do not display the time stamp. To enable tracking of the last successful Kerberos authentication of a user: Display the currently enabled password plug-in features: You require the names of the features, except KDC:Disable Last Success , in the following step. Pass the --ipaconfigstring= feature parameter for every feature to the ipa config-mod command that is currently enabled, except for KDC:Disable Last Success : This command enables only the AllowNThash plug-in. To enable multiple features, specify the --ipaconfigstring= feature parameter multiple times. For example, to enable the AllowNThash and KDC:Disable Lockout feature: Restart IdM:

Commands:
ipa config-show | grep "Password plugin features" Password plugin features: AllowNThash , KDC:Disable Last Success
ipa config-mod --ipaconfigstring='AllowNThash'
ipa config-mod --ipaconfigstring='AllowNThash' --ipaconfigstring='KDC:Disable Lockout'
ipactl restart
3.14. RHEA-2012:0022 - new package: python-suds The python-suds package is now available for Red Hat Enterprise Linux 6 Server and Red Hat Enterprise Linux High Performance Compute Node. The python-suds package provides a lightweight implementation of the Simple Object Access Protocol (SOAP) for the Python programming environment. This enhancement update adds the python-suds package to Red Hat Enterprise Linux 6 Server and Red Hat Enterprise Linux High Performance Compute Node. Previously it was only available with the Red Hat Enterprise Linux High Availability and Red Hat Enterprise Linux Resilient Storage add-on products. (BZ# 765896 ) All users who require python-suds are advised to install this new package.

Commands:
Chapter 57. File Systems NetApp storage appliances serving NFSv4 are advised to check their configuration Note that features can be enabled or disabled on a per-minor version basis when using NetApp storage appliances that serve NFSv4. It is recommended to verify the configuration to ensure that the appropriate features are enabled as desired, for example by using the following Data ONTAP command: (BZ# 1450447 )

Commands:
vserver nfs show -vserver <vserver-name> -fields v4.0-acl,v4.0-read-delegation,v4.0-write-delegation,v4.0-referrals,v4.0-migration,v4.1-referrals,v4.1-migration,v4.1-acl,v4.1-read-delegation,v4.1-write-delegation
D.2. Metadata Contents The volume group metadata contains: Information about how and when it was created Information about the volume group: The volume group information contains: Name and unique id A version number which is incremented whenever the metadata gets updated Any properties: Read/Write? Resizeable? Any administrative limit on the number of physical volumes and logical volumes it may contain The extent size (in units of sectors which are defined as 512 bytes) An unordered list of physical volumes making up the volume group, each with: Its UUID, used to determine the block device containing it Any properties, such as whether the physical volume is allocatable The offset to the start of the first extent within the physical volume (in sectors) The number of extents An unordered list of logical volumes. each consisting of An ordered list of logical volume segments. For each segment the metadata includes a mapping applied to an ordered list of physical volume segments or logical volume segments

Commands:
Chapter 63. HashLoginServiceApiUsers schema reference Used in: CruiseControlSpec The type property is a discriminator that distinguishes use of the HashLoginServiceApiUsers type from other subtypes which may be added in the future. It must have the value hashLoginService for the type HashLoginServiceApiUsers . Property Property type Description type string Must be hashLoginService . valueFrom PasswordSource Secret from which the custom Cruise Control API authentication credentials are read.

Commands:
B.74. psmisc B.74.1. RHBA-2011:0171 - psmisc bug fix update An updated psmisc package that fixes two bugs is now available for Red Hat Enterprise Linux 6. The psmisc package contains utilities for managing processes on your system: pstree, killall, fuser and peekfd. The pstree command displays a tree structure of all of the running processes on your system. The killall command sends a specified signal (SIGTERM if nothing is specified) to processes identified by name. The fuser command identifies the PIDs of processes that are using specified files or file systems. The peekfd command attaches to a running process and intercepts all reads and writes to file descriptors. Bug Fixes BZ# 668989 Due to an error in memory allocation, an attempt to kill a process group by using the "killall -g" command could fail. With this update, the memory allocation has been corrected, and the killall utility now works as expected. BZ# 668992 When parsing a list of command line arguments, the peekfd utility incorrectly used a wrong index. As a result, running the peekfd command with a file descriptor specified caused the utility to terminate unexpectedly with a segmentation fault. This update corrects this error, and the peekfd utility no longer fails to run. All users of psmisc are advised to upgrade to this updated package, which resolves these issues.

Commands:
25.9.3. Monitoring Log Files Log File Viewer monitors all opened logs by default. If a new line is added to a monitored log file, the log name appears in bold in the log list. If the log file is selected or displayed, the new lines appear in bold at the bottom of the log file. Figure 25.7, "Log File Viewer - new log alert" illustrates a new alert in the cron log file and in the messages log file. Clicking on the cron log file displays the logs in the file with the new lines in bold. Figure 25.7. Log File Viewer - new log alert

Commands:
8.3.2. Running SCAP Workbench After a successful installation of both, the SCAP Workbench utility and SCAP content, you can start using SCAP Workbench on your systems. For running SCAP Workbench from the GNOME Classic desktop environment, press the Super key to enter the Activities Overview , type scap-workbench , and then press Enter . The Super key appears in a variety of guises, depending on the keyboard and other hardware, but often as either the Windows or Command key, and typically to the left of the Spacebar key. Figure 8.1. Open SCAP Security Guide Window As soon as you start the utility, the Open SCAP Security Guide window appears. After a selection one of the guides, the SCAP Workbench window appears. This window consists of several interactive components, which you should become familiar with before you start scanning your system: File This menu list offers several options to load or save a SCAP-related content. To show the initial Open SCAP Security Guide window, click the menu item with the same name. Alternatively, load another customization file in the XCCDF format by clicking Open Other Content . To save your customization as an XCCDF XML file, use the Save Customization Only item. The Save All allows you to save SCAP files either to the selected directory or as an RPM package. Customization This combo box informs you about the customization used for the given security policy. You can select custom rules that will be applied for the system evaluation by clicking this combo box. The default value is (no customization) , which means that there will be no changes to the used security policy. If you made any changes to the selected security profile, you can save those changes as an XML file by clicking the Save Customization Only item in the File menu. Profile This combo box contains the name of the selected security profile. You can select the security profile from a given XCCDF or data-stream file by clicking this combo box. To create a new profile that inherits properties of the selected security profile, click the Customize button. Target The two radio buttons enable you to select whether the system to be evaluated is a local or remote machine. Selected Rules This field displays a list of security rules that are subject of the security policy. Expanding a particular security rule provides detailed information about that rule. Status bar This is a graphical bar that indicates status of an operation that is being performed. Fetch remote resources This check box allows to instruct the scanner to download a remote OVAL content defined in an XML file. Remediate This check box enables the remediation feature during the system evaluation. If you check this box, SCAP Workbench will attempt to correct system settings that would fail to match the state defined by the policy. Scan This button allows you to start the evaluation of the specified system. Figure 8.2. SCAP Workbench Window

Commands: