mtpti5iD/redhat-docs_dataset huggingface dataset:
10.2.2. Configuring New and Editing Existing Connections , right-click on the NetworkManager applet to open its context menu, which is the main point of entry for interacting with NetworkManager to configure connections. Figure 10.3. The NetworkManager applet's context menu Ensure that the Enable Networking box is checked. If the system has detected a wireless card, then you will also see an Enable Wireless menu option. Check the Enable Wireless check box as well. NetworkManager notifies you of network connection status changes if you check the Enable Notifications box. Clicking the Connection Information entry presents an informative Connection Information window that lists the connection type and interface, your IP address and routing details, and so on. Finally, clicking on Edit Connections opens the Network Connections window, from where you can perform most of your network configuration tasks. Note that this window can also be opened by running, as a normal user: Figure 10.4. Configure networks using the Network Connections window There is an arrow head symbol to the left which can be clicked to hide and reveal entries as needed. To create a new connection, click the Add button to view the selection list, select the connection type and click the Create button. Alternatively, to edit an existing connection select the interface name from the list and click the Edit button. Then, to configure: wired Ethernet connections, proceed to Section 10.3.1, "Establishing a Wired (Ethernet) Connection" ; wireless connections, proceed to Section 10.3.2, "Establishing a Wireless Connection" ; or, mobile broadband connections, proceed to Section 10.3.3, "Establishing a Mobile Broadband Connection" ; or, VPN connections, proceed to Section 10.3.4, "Establishing a VPN Connection" .

Commands:
~]USD nm-connection-editor &
Chapter 8. Running and interpreting system latency tests RHEL for Real Time provides the rteval utility to test the system real-time performance under load. 8.1. Running system latency tests With the rteval utility, you can test a system's real-time performance under load. Prerequisites The RHEL for Real Time package group is installed. You have root permissions on the system. Procedure Run the rteval utility. The rteval utility starts a heavy system load of SCHED_OTHER tasks. It then measures real-time response on each online CPU. The loads are a parallel make of the Linux kernel tree in a loop and the hackbench synthetic benchmark. The goal is to bring the system into a state, where each core always has a job to schedule. The jobs perform various tasks, such as memory allocation/free, disk I/O, computational tasks, memory copies, and other. Once the loads start, rteval starts the cyclictest measurement program. This program starts the SCHED_FIFO real-time thread on each online core. It then measures the real-time scheduling response time. Each measurement thread takes a timestamp, sleeps for an interval, then takes another timestamp after waking up. The latency measured is t1 - (t0 + i) , which is the difference between the actual wakeup time t1 , and the theoretical wakeup time of the first timestamp t0 plus the sleep interval i . The details of the rteval run are written to an XML file along with the boot log for the system. This report is displayed on the screen and saved to a compressed file. The file name is in the form rteval- <date>-N -tar.bz2 , where <date> is the date the report was generated, N is a counter for the Nth run on <date> . The following is an example of an rteval report: The report includes details about the system hardware, length of the run, options used, and the timing results, both per-cpu and system-wide. Note To regenerate an rteval report from its generated file, run # rteval --summarize rteval- <date> - N .tar.bz2

Commands:
rteval
System: Statistics: Samples: 1440463955 Mean: 4.40624790712us Median: 0.0us Mode: 4us Range: 54us Min: 2us Max: 56us Mean Absolute Dev: 1.0776661507us Std.dev: 1.81821060672us CPU core 0 Priority: 95 Statistics: Samples: 36011847 Mean: 5.46434910711us Median: 4us Mode: 4us Range: 38us Min: 2us Max: 40us Mean Absolute Dev: 2.13785341159us Std.dev: 3.50155558554us
Chapter 3. Checking disk space using IdM Healthcheck You can monitor the Identity Management server's free disk space using the Healthcheck tool. For details, see Healthcheck in IdM . Prerequisites The Healthcheck tool is only available on RHEL 8.1 and newer. 3.1. Disk space healthcheck test The Healthcheck tool includes a test for checking available disk space. Insufficient free disk space can cause issues with: Logging Execution Backups The test checks the following paths: Table 3.1. Tested paths Paths checked by the test Minimal disk space in MB /var/lib/dirsrv/ 1024 /var/lib/ipa/backup/ 512 /var/log/ 1024 var/log/audit/ 512 /var/tmp/ 512 /tmp/ 512 To list all tests, run the ipa-healthcheck with the --list-sources option: You can find the file system space check test under the ipahealthcheck.system.filesystemspace source: FileSystemSpaceCheck This test checks available disk space in the following ways: The minimum raw free bytes needed. The percentage - the minimum free disk space is hardcoded to 20%. 3.2. Screening disk space using the healthcheck tool Follow this procedure to run a standalone manual test of available disk space on an Identity Management (IdM) server using the Healthcheck tool. Since Healthcheck includes many tests, you can narrow the results by: Excluding all successful test: --failures-only Including only space check tests: --source=ipahealthcheck.system.filesystemspace Procedure To run Healthcheck with warnings, errors and critical issues regarding available disk space, enter: A successful test displays empty brackets: As an example, a failed test can display: The failed test informs you that the /var/lib/dirsrv directory has run out of space. Additional resources See man ipa-healthcheck .

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source=ipahealthcheck.system.filesystemspace --failures-only
{ "source": "ipahealthcheck.system.filesystemspace", "check": "FileSystemSpaceCheck", "result": "ERROR", "kw": { "msg": "/var/lib/dirsrv: free space under threshold: 0 MiB < 1024 MiB", "store": "/var/lib/dirsrv", "free_space": 0, "threshold": 1024 } }
7.308. chkconfig 7.308.1. RHBA-2013:1276 - chkconfig bug fix update Updated chkconfig packages that fix one bug are now available for Red Hat Enterprise Linux 6. The basic system utility chkconfig updates and queries runlevel information for system services. Bug Fix BZ# 1007372 Previously, the readServices() function returned a wrong value when the /etc/init.d directory was not readable. As a consequence, a segmentation fault occurred. With this update, when the /etc/init.d directory is not readable, the readServices() function properly detects the situation and exits with a failure message. As a result, a segmentation fault no longer occurs. Users of chkconfig are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 8. Volume size overrides You can specify the desired size of storage resources provisioned for managed components. The default size for Clair and the PostgreSQL databases is 50Gi . You can now choose a large enough capacity upfront, either for performance reasons or in the case where your storage backend does not have resize capability. In the following example, the volume size for the Clair and the Quay PostgreSQL databases has been set to 70Gi : apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: quay-example namespace: quay-enterprise spec: configBundleSecret: config-bundle-secret components: - kind: objectstorage managed: false - kind: route managed: true - kind: tls managed: false - kind: clair managed: true overrides: volumeSize: 70Gi - kind: postgres managed: true overrides: volumeSize: 70Gi - kind: clairpostgres managed: true overrides: volumeSize: 70Gi

Commands:
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: quay-example namespace: quay-enterprise spec: configBundleSecret: config-bundle-secret components: - kind: objectstorage managed: false - kind: route managed: true - kind: tls managed: false - kind: clair managed: true overrides: volumeSize: 70Gi - kind: postgres managed: true overrides: volumeSize: 70Gi - kind: clairpostgres managed: true overrides: volumeSize: 70Gi
Chapter 12. Servers and Services A DHCP client hook example added for DDNS for Microsoft Azure cloud An example of the DHCP client hook for Dynamic DNS (DDNS) for Microsoft Azure cloud has been added to the dhcp package. The administrator can now easily enable this hook, and register Red Hat Enterprise Linux clients with a DDNS server. (BZ#1321945) postfix now supports user-controlled configuration of TLS With this update, postfix offers configuration options for more precise control of the Transport Layer Security (TLS) protocol version. For example, you can now disable TLS v1.1 while having TLS v1.2 enabled. To do this, add the following line to the main.cf file: (BZ# 1287192 )

Commands:
smtpd_tls_mandatory_protocols = !TLSv1.1
25.2. Adding FCP-Attached Logical Units (LUNs) The following is an example of how to add an FCP LUN. Note If running under z/VM, make sure the FCP adapter is attached to the z/VM guest virtual machine. For multipathing in production environments there would be at least two FCP devices on two different physical adapters (CHPIDs). For example: 25.2.1. Dynamically Activating an FCP LUN Follow these steps to activate a LUN: Use the cio_ignore command to remove the FCP adapter from the list of ignored devices and make it visible to Linux: Replace DeviceNumber with the device number of the FCP adapter. For example: To bring the FCP adapter device online, use the following command: Verify that the required WWPN was found by the automatic port scanning of the zfcp device driver: Activate the FCP LUN by adding it to the port (WWPN) through which you would like to access the LUN: Find out the assigned SCSI device name: For more information, refer to the chapter on SCSI-over-Fibre Channel in Linux on System z Device Drivers, Features, and Commands on Red Hat Enterprise Linux 6 .

Commands:
CP ATTACH FC00 TO * CP ATTACH FCD0 TO *
cio_ignore -r DeviceNumber
chccwdev -e fc00
ls -l /sys/bus/ccw/drivers/zfcp/0.0.fc00/ drwxr-xr-x. 3 root root 0 Apr 28 18:19 0x500507630040710b drwxr-xr-x. 3 root root 0 Apr 28 18:19 0x50050763050b073d drwxr-xr-x. 3 root root 0 Apr 28 18:19 0x500507630e060521 drwxr-xr-x. 3 root root 0 Apr 28 18:19 0x500507630e860521 -r--r--r--. 1 root root 4096 Apr 28 18:17 availability -r--r--r--. 1 root root 4096 Apr 28 18:19 card_version -rw-r--r--. 1 root root 4096 Apr 28 18:17 cmb_enable -r--r--r--. 1 root root 4096 Apr 28 18:17 cutype -r--r--r--. 1 root root 4096 Apr 28 18:17 devtype lrwxrwxrwx. 1 root root 0 Apr 28 18:17 driver -> ../../../../bus/ccw/drivers/zfcp -rw-r--r--. 1 root root 4096 Apr 28 18:17 failed -r--r--r--. 1 root root 4096 Apr 28 18:19 hardware_version drwxr-xr-x. 35 root root 0 Apr 28 18:17 host0 -r--r--r--. 1 root root 4096 Apr 28 18:17 in_recovery -r--r--r--. 1 root root 4096 Apr 28 18:19 lic_version -r--r--r--. 1 root root 4096 Apr 28 18:17 modalias -rw-r--r--. 1 root root 4096 Apr 28 18:17 online -r--r--r--. 1 root root 4096 Apr 28 18:19 peer_d_id -r--r--r--. 1 root root 4096 Apr 28 18:19 peer_wwnn -r--r--r--. 1 root root 4096 Apr 28 18:19 peer_wwpn --w-------. 1 root root 4096 Apr 28 18:19 port_remove --w-------. 1 root root 4096 Apr 28 18:19 port_rescan drwxr-xr-x. 2 root root 0 Apr 28 18:19 power -r--r--r--. 1 root root 4096 Apr 28 18:19 status lrwxrwxrwx. 1 root root 0 Apr 28 18:17 subsystem -> ../../../../bus/ccw -rw-r--r--. 1 root root 4096 Apr 28 18:17 uevent
echo 0x4020400100000000 > /sys/bus/ccw/drivers/zfcp/0.0.fc00/0x50050763050b073d/unit_add
lszfcp -DV /sys/devices/css0/0.0.0015/0.0.fc00/0x50050763050b073d/0x4020400100000000 /sys/bus/ccw/drivers/zfcp/0.0.fc00/host0/rport-0:0-21/target0:0:21/0:0:21:1089355792
Chapter 4. Managing build output Use the following sections for an overview of and instructions for managing build output. 4.1. Build output Builds that use the docker or source-to-image (S2I) strategy result in the creation of a new container image. The image is then pushed to the container image registry specified in the output section of the Build specification. If the output kind is ImageStreamTag , then the image will be pushed to the integrated OpenShift image registry and tagged in the specified imagestream. If the output is of type DockerImage , then the name of the output reference will be used as a docker push specification. The specification may contain a registry or will default to DockerHub if no registry is specified. If the output section of the build specification is empty, then the image will not be pushed at the end of the build. Output to an ImageStreamTag spec: output: to: kind: "ImageStreamTag" name: "sample-image:latest" Output to a docker Push Specification spec: output: to: kind: "DockerImage" name: "my-registry.mycompany.com:5000/myimages/myimage:tag" 4.2. Output image environment variables docker and source-to-image (S2I) strategy builds set the following environment variables on output images: Variable Description OPENSHIFT_BUILD_NAME Name of the build OPENSHIFT_BUILD_NAMESPACE Namespace of the build OPENSHIFT_BUILD_SOURCE The source URL of the build OPENSHIFT_BUILD_REFERENCE The Git reference used in the build OPENSHIFT_BUILD_COMMIT Source commit used in the build Additionally, any user-defined environment variable, for example those configured with S2I] or docker strategy options, will also be part of the output image environment variable list. 4.3. Output image labels docker and source-to-image (S2I)` builds set the following labels on output images: Label Description io.openshift.build.commit.author Author of the source commit used in the build io.openshift.build.commit.date Date of the source commit used in the build io.openshift.build.commit.id Hash of the source commit used in the build io.openshift.build.commit.message Message of the source commit used in the build io.openshift.build.commit.ref Branch or reference specified in the source io.openshift.build.source-location Source URL for the build You can also use the BuildConfig.spec.output.imageLabels field to specify a list of custom labels that will be applied to each image built from the build configuration. Custom Labels to be Applied to Built Images spec: output: to: kind: "ImageStreamTag" name: "my-image:latest" imageLabels: - name: "vendor" value: "MyCompany" - name: "authoritative-source-url" value: "registry.mycompany.com"

Commands:
spec: output: to: kind: "ImageStreamTag" name: "sample-image:latest"
spec: output: to: kind: "DockerImage" name: "my-registry.mycompany.com:5000/myimages/myimage:tag"
spec: output: to: kind: "ImageStreamTag" name: "my-image:latest" imageLabels: - name: "vendor" value: "MyCompany" - name: "authoritative-source-url" value: "registry.mycompany.com"
7.186. pm-utils 7.186.1. RHBA-2012:1094 - pm-utils bug fix update Updated pm-utils packages that fix one bug are now available for Red Hat Enterprise Linux 6. The pm-utils packages contain a set of utilities and scripts for tasks related to power management. Bug Fix BZ# 800630 Prior to this update, the RPM description contained wrong product names. This update removes all wrong information. All users of pm-utils are advised to upgrade to these updated packages, which fix this bug.

Commands:
12.3. Delegating Host or Service Management in the Web UI Each host and service entry has a configuration tab that indicates what hosts have been delegated management control over that host or service. Open the Identity tab, and select the Hosts or Services subtab. Click the name of the host or service that you are going to grant delegated management to . Click the Hosts subtab on the far right of the host/service entry. This is the tab which lists hosts which can manage the selected host/service. Click the Add link at the top of the list. Click the checkbox by the names of the hosts to which to delegate management for the host/service. Click the right arrows button, >> , to move the hosts to the selection box. Click the Add button to close the selection box and to save the delegation settings.

Commands:
27.4. Making Files Accessible From the Console In /etc/security/console.perms , there is a section with lines like: You can add your own lines to this section, if necessary. Make sure that any lines you add refer to the appropriate device. For example, you could add the following line: (Of course, make sure that /dev/scanner is really your scanner and not, say, your hard drive.) That is the first step. The second step is to define what is done with those files. Look in the last section of /etc/security/console.perms for lines similar to: and add a line like: Then, when you log in at the console, you are given ownership of the /dev/scanner device with the permissions of 0600 (readable and writable by you only). When you log out, the device is owned by root and still has the permissions 0600 (now readable and writable by root only).

Commands:
<floppy>=/dev/fd[0-1]* /dev/floppy/* /mnt/floppy* <sound>=/dev/dsp* /dev/audio* /dev/midi* /dev/mixer* /dev/sequencer /dev/sound/* /dev/beep /dev/snd/* <cdrom>=/dev/cdrom* /dev/cdroms/* /dev/cdwriter* /mnt/cdrom*
<scanner>=/dev/scanner /dev/usb/scanner*
<console> 0660 <floppy> 0660 root.floppy <console> 0600 <sound> 0640 root <console> 0600 <cdrom> 0600 root.disk
<console> 0600 <scanner> 0600 root
8.98. irqbalance 8.98.1. RHBA-2014:1504 - irqbalance bug fix update Updated irqbalance packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The irqbalance packages provide a daemon that evenly distributes the interrupt request (IRQ) load across multiple CPUs for enhanced performance. Bug Fixes BZ# 1039178 Previously, the irqbalance daemon did not consider the NUMA node assignment for an interrupt request (IRQ) for the banned CPU set. Consequently, irqbalance set the affinity incorrectly when the IRQBALANCE_BANNED_IRQS variable was set to a single CPU. In addition, IRQs could be assigned to a node that had no eligible CPUs. Node assignment has been restricted to nodes that have eligible CPUs as defined by the unbanned_cpus bitmask, thus fixing the bug. As a result, irqbalance now sets the affinity properly, and IRQs are assigned to the respective nodes correctly. BZ# 987801 Prior to this update, the dependency of the irqbalance daemon was set incorrectly referring to a wrong kernel version. As a consequence, irqbalance could not balance IRQs on NUMA systems. With this update, the dependency has been fixed, and IRQs are now balanced correctly on NUMA systems. Note that users of irqbalance packages have to update the kernel to 2.6.32-358.2.1 or later in order to use the irqbalance daemon in the correct manner. BZ# 1079109 Prior to this update, irqbalance could not accurately determine the NUMA node it was local to or the device to which an IRQ was sent. The kernel affinity_hint values were created to work around this issue. With this update, irqbalance is now capable of parsing all information about an IRQ provided by the sysfs() function. IRQ balancing now works correctly, and the affinity_hint values are now ignored by default not to distort the irqbalance functionality. Users of irqbalance are advised to upgrade to these updated packages, which fix these bugs.

Commands:
F.2.5. Job Definitions Previously, the sysvinit package provided the init daemon for the default configuration. When the system started, this init daemon ran the /etc/inittab script to start system processes defined for each runlevel. The default configuration now uses an event-driven init daemon provided by the upstart package. Whenever particular events occur, the init daemon processes jobs stored in the /etc/event.d directory. The init daemon recognizes the start of the system as such an event. Each job typically specifies a program, and the events that trigger init to run or to stop the program. Some jobs are constructed as tasks , which perform actions and then terminate until another event triggers the job again. Other jobs are constructed as services , which init keeps running until another event (or the user) stops it. For example, the /etc/events.d/tty2 job is a service to maintain a virtual terminal on tty2 from the time that the system starts until the system shuts down, or another event (such as a change in runlevel) stops the job. The job is constructed so that init will restart the virtual terminal if it stops unexpectedly during that time:

Commands:
tty2 - getty # This service maintains a getty on tty2 from the point the system is started until it is shut down again. start on stopped rc2 start on stopped rc3 start on stopped rc4 start on started prefdm stop on runlevel 0 stop on runlevel 1 stop on runlevel 6 respawn exec /sbin/mingetty tty2
4.3. Managing High-Availability Services You can perform the following management functions for high-availability services through the luci server component of Conga : Configure a service. Stop or start a service. Restart a service. Delete a service To perform one the functions in the preceding list, follow the steps in this section. The starting point of the procedure is at the cluster-specific page that you navigate to from Choose a cluster to administer displayed on the cluster tab. At the detailed menu for the cluster (below the clusters menu), click Services . Clicking Services causes the display of services for the cluster in the center of the page. At the right of each service listed on the page, click the Choose a task drop-down box. Clicking Choose a task drop-down box reveals the following selections depending on if the service is running: If service is running - Configure this service , Restart this service , and Stop this service . If service is not running - Configure this service , Start this service , and Delete this service . The actions of each function are summarized as follows: Configure this service - Configure this service is available when the service is running or not running. Selecting Configure this service causes the services configuration page for the service to be displayed. On that page, you can change the configuration of the service. For example, you can add a resource to the service. (For more information about adding resources and services, refer to Section 3.8, "Adding Cluster Resources" and Section 3.9, "Adding a Cluster Service to the Cluster" .) In addition, a drop-down box on the page provides other functions depending on if the service is running. When a service is running, the drop-down box provides the following functions: restarting, disabling, and relocating the service. When a service is not running, the drop-down box on the configuration page provides the following functions: enabling and deleting the service. If you are making configuration changes, save the changes by clicking Save . Clicking Save causes a progress page to be displayed. When the change is complete, another page is displayed showing a list of services for the cluster. If you have selected one of the functions in the drop-down box on the configuration page, click Go . Clicking Go causes a progress page to be displayed. When the change is complete, another page is displayed showing a list of services for the cluster. Restart this service and Stop this service - These selections are available when the service is running. Select either function and click Go to make the change take effect. Clicking Go causes a progress page to be displayed. When the change is complete, another page is displayed showing a list of services for the cluster. Start this service and Delete this service - These selections are available when the service is not running. Select either function and click Go to make the change take effect. Clicking Go causes a progress page to be displayed. When the change is complete, another page is displayed showing a list of services for the cluster.

Commands: