mtpti5iD/redhat-docs_dataset huggingface dataset:
14.5. Samba Account Information Databases The latest release of Samba offers many new features including new password database backends not previously available. Samba version 3.0.0 fully supports all databases used in versions of Samba. However, although supported, many backends may not be suitable for production use. 14.5.1. Backward Compatible Backends Plain Text Plain text backends are nothing more than the /etc/passwd type backends. With a plain text backend, all usernames and passwords are sent unencrypted between the client and the Samba server. This method is very insecure and is not recommended for use by any means. It is possible that different Windows clients connecting to the Samba server with plain text passwords cannot support such an authentication method. smbpasswd A popular backend used in Samba packages, the smbpasswd backend utilizes a plain ASCII text layout that includes the MS Windows LanMan and NT account, and encrypted password information. The smbpasswd backend lacks the storage of the Windows NT/2000/2003 SAM extended controls. The smbpasswd backend is not recommended because it does not scale well or hold any Windows information, such as RIDs for NT-based groups. The tdbsam backend solves these issues for use in a smaller database (250 users), but is still not an enterprise-class solution. Warning This type of backend may be deprecated for future releases and replaced by the tdbsam backend, which does include the SAM extended controls. ldapsam_compat The ldapsam_compat backend allows continued OpenLDAP support for use with upgraded versions of Samba. This option is ideal for migration, but is not required. This tool will eventually be deprecated.

Commands:
7.3. RHBA-2014:1498 - new packages: gdisk New gdisk packages are now available for Red Hat Enterprise Linux 6. The gdisk packages provide a fdisk-like partitioning tool for GPT disks. GPT fdisk features a command-line interface, fairly direct manipulation of partition table structures, recovery tools fort dealing with corrupt partition tables, and the ability to convert MBR disks to GPT format. This enhancement update adds the gdisk packages to Red Hat Enterprise Linux 6. (BZ# 1015157 ) All users who require gdisk are advised to install these new packages.

Commands:
16.18. Write Changes to Disk The installer prompts you to confirm the partitioning options that you selected. Click Write changes to disk to allow the installer to partition your hard drive and install Red Hat Enterprise Linux. Figure 16.46. Writing storage configuration to disk If you are certain that you want to proceed, click Write changes to disk . Warning Up to this point in the installation process, the installer has made no lasting changes to your computer. When you click Write changes to disk , the installer will allocate space on your hard drive and start to transfer Red Hat Enterprise Linux into this space. Depending on the partitioning option that you chose, this process might include erasing data that already exists on your computer. To revise any of the choices that you made up to this point, click Go back . To cancel installation completely, switch off your computer. After you click Write changes to disk , allow the installation process to complete. If the process is interrupted (for example, by you switching off or resetting the computer, or by a power outage) you will probably not be able to use your computer until you restart and complete the Red Hat Enterprise Linux installation process, or install a different operating system.

Commands:
3.11. Creating a vNIC To ensure that a newly created virtual machine has network access you must create and attach a vNIC. This Ruby example creates a vNIC and attaches it to an existing virtual machine, myvm . # Find the root of the tree of services: system_service = connection.system_service # Find the virtual machine: vms_service = system_service.vms_service vm = vms_service.list(search: 'name=myvm').first # In order to specify the network that the new NIC will be connected to, you must # specify the identifier of the vNIC profile. However, there may be multiple # profiles with the same name (for different data centers, for example), so first # you must find the networks that are available in the cluster that the # virtual machine belongs to. cluster = connection.follow_link(vm.cluster) networks = connection.follow_link(cluster.networks) network_ids = networks.map(&:id) # Now that you know what networks are available in the cluster, you can select a # vNIC profile that corresponds to one of those networks, and has the # name that you want to use. The system automatically creates a vNIC # profile for each network, with the same name as the network. profiles_service = system_service.vnic_profiles_service profiles = profiles_service.list profile = profiles.detect { |p| network_ids.include?(p.network.id) && p.name == 'myprofile' } # Locate the service that manages the network interface cards collection of the # virtual machine: nics_service = vms_service.vm_service(vm.id).nics_service # Add the new network interface card: nics_service.add( OvirtSDK4::Nic.new( name: 'mynic', description: 'My network interface card', vnic_profile: { id: profile.id } ) ) For more information, see VmsService:add .

Commands:
Find the root of the tree of services: system_service = connection.system_service Find the virtual machine: vms_service = system_service.vms_service vm = vms_service.list(search: 'name=myvm').first In order to specify the network that the new NIC will be connected to, you must specify the identifier of the vNIC profile. However, there may be multiple profiles with the same name (for different data centers, for example), so first you must find the networks that are available in the cluster that the virtual machine belongs to. cluster = connection.follow_link(vm.cluster) networks = connection.follow_link(cluster.networks) network_ids = networks.map(&:id) Now that you know what networks are available in the cluster, you can select a vNIC profile that corresponds to one of those networks, and has the name that you want to use. The system automatically creates a vNIC profile for each network, with the same name as the network. profiles_service = system_service.vnic_profiles_service profiles = profiles_service.list profile = profiles.detect { |p| network_ids.include?(p.network.id) && p.name == 'myprofile' } Locate the service that manages the network interface cards collection of the virtual machine: nics_service = vms_service.vm_service(vm.id).nics_service Add the new network interface card: nics_service.add( OvirtSDK4::Nic.new( name: 'mynic', description: 'My network interface card', vnic_profile: { id: profile.id } ) )
Chapter 8. Host management and monitoring using the RHEL web console You can use the RHEL web console interactive web interface to perform actions and monitor Red Hat Enterprise Linux hosts. You can enable a remote-execution feature to integrate Satellite with the RHEL web console. When you install the RHEL web console on a host that you manage with Satellite, you can view the RHEL web console dashboards of that host from within the Satellite web UI. You can also use the features that are integrated with the RHEL web console, for example, Red Hat Image Builder. 8.1. Enabling the RHEL web console on Satellite By default, RHEL web console integration is disabled in Satellite. If you want to access RHEL web console features for your hosts from within Satellite, you must first enable the RHEL web console on Satellite Server. Procedure Enable the RHEL web console on your Satellite Server: 8.2. Managing and monitoring hosts using the RHEL web console You can access the RHEL web console UI through the Satellite web UI and use the functionality to manage and monitor hosts in Satellite. Prerequisites You have enabled the RHEL web console in Satellite. You have installed the RHEL web console on the host that you want to view: For Red Hat Enterprise Linux 8, see Installing the web console in the Managing systems using the RHEL 8 web console guide. For Red Hat Enterprise Linux 7, see Installing the web console in the Managing systems using the RHEL 7 web console guide. Satellite or Capsule can authenticate to the host with SSH keys. For more information, see Section 12.14, "Distributing SSH keys for remote execution" . Procedure In the Satellite web UI, navigate to Hosts > All Hosts and select the host that you want to manage and monitor with the RHEL web console. In the upper right of the host window, click the vertical ellipsis and select Web Console . You can now access the full range of features available for host monitoring and management, for example, Red Hat Image Builder, through the RHEL web console. For more information about getting started with Red Hat web console, see the Managing systems using the RHEL 8 web console guide or the Managing systems using the RHEL 7 web console guide. For more information about using Red Hat Image Builder through the RHEL web console, see Accessing Image Builder GUI in the RHEL 8 web console or Accessing Image Builder GUI in the RHEL 7 web console . 8.3. Disabling the RHEL web console on Satellite Perform the following procedure if you want to disable the RHEL web console on Satellite. Procedure Disable the RHEL web console on your Satellite Server: Important You can enable or disable RHEL web console integration independently on Capsule Servers. To prevent enabling RHEL web console integration on a Capsule Server, enter the following command after completing the procedure:

Commands:
satellite-installer --enable-foreman-plugin-remote-execution-cockpit --reset-foreman-plugin-remote-execution-cockpit-ensure
satellite-installer --foreman-plugin-remote-execution-cockpit-ensure absent
satellite-installer --foreman-proxy-plugin-remote-execution-script-cockpit-integration false
6.3. Removing Subscriptions To remove a particular subscription, complete the following steps. Determine the serial number of the subscription you want to remove by listing information about already attached subscriptions: subscription-manager list --consumed The serial number is the number listed as serial . For instance, 744993814251016831 in the example below: Enter a command as follows to remove the selected subscription: subscription-manager remove --serial= serial_number Replace serial_number with the serial number you determined in the step. To remove all subscriptions attached to the system, run the following command: subscription-manager remove --all

Commands:
SKU: ES0113909 Contract: 01234567 Account: 1234567 Serial: 744993814251016831 Pool ID: 8a85f9894bba16dc014bccdd905a5e23 Active: False Quantity Used: 1 Service Level: SELF-SUPPORT Service Type: L1-L3 Status Details: Subscription Type: Standard Starts: 02/27/2015 Ends: 02/27/2016 System Type: Virtual
3.6. Moving a Process to a Control Group Move a process into a cgroup by running the cgclassify command: where: controllers is a comma-separated list of resource controllers, or /* to launch the process in the hierarchies associated with all available subsystems. Note that if there are multiple cgroups of the same name, the -g option moves the processes in each of those groups. path_to_cgroup is the path to the cgroup within the hierarchy; pidlist is a space-separated list of process identifier (PIDs). If the -g option is not specified, cgclassify automatically searches /etc/cgrules.conf and uses the first applicable configuration line. According to this line, cgclassify determines the hierarchies and cgroups to move the process under. Note that for the move to be successful, the destination hierarchies have to exist. The subsystems specified in /etc/cgrules.conf has to be also properly configured for the corresponding hierarchy in /etc/cgconfig.conf . You can also add the --sticky option before the pid to keep any child processes in the same cgroup. If you do not set this option and the cgred service is running, child processes will be allocated to cgroups based on the settings found in /etc/cgrules.conf . The process itself, however, will remain in the cgroup in which you started it. It is also possible to use the cgred service (which starts the cgrulesengd service) that moves tasks into cgroups according to parameters set in the /etc/cgrules.conf file. Use cgred only to manage manually attached controllers. Entries in the /etc/cgrules.conf file can take one of the two forms: user subsystems control_group ; user : command subsystems control_group . For example: This entry specifies that any processes that belong to the user named maria access the devices subsystem according to the parameters specified in the /usergroup/staff cgroup. To associate particular commands with particular cgroups, add the command parameter, as follows: The entry now specifies that when the user named maria uses the ftp command, the process is automatically moved to the /usergroup/staff/ftp cgroup in the hierarchy that contains the devices subsystem. Note, however, that the daemon moves the process to the cgroup only after the appropriate condition is fulfilled. Therefore, the ftp process can run for a short time in an incorrect group. Furthermore, if the process quickly spawns children while in the incorrect group, these children might not be moved. Entries in the /etc/cgrules.conf file can include the following extra notation: @ - when prefixed to user , indicates a group instead of an individual user. For example, @admins are all users in the admins group. \* - represents "all". For example, \* in the subsystem field represents all subsystems. % - represents an item the same as the item on the line above. For example:

Commands:
~]# cgclassify -g controllers : path_to_cgroup pidlist
maria net_prio /usergroup/staff
maria:ftp devices /usergroup/staff/ftp
@adminstaff net_prio /admingroup @labstaff % %
Chapter 33. Security CardOS 5.3 smart cards with ECDSA support work correctly in OpenSC Previously, OpenSC did not correctly parse the ECDSA algorithm in the TokenInfo information provided by CardOS 5.3 smart cards. As a consequence, OpenSC did not detect these cards. The TokenInfo parser has been updated and now complies with the PKCS #15 specification. As a result, CardOS 5.3 smart cards with ECDSA support work correctly in OpenSC. (BZ# 1562277 ) Non-CCID-compliant smart card readers work in OpenSC Certain smart card readers implement PIN pad functionality that does not follow the chip card interface device (CCID) specification. Previously, OpenSC detected the PIN pad of such smart card readers, but the reader could not be used with OpenSC. With this update, the PIN pad detection has been disabled in OpenSC by default. As a result, non-CCID-compliant smart card readers can be used, but without the PIN pad feature. (BZ#1547117) The pkcs11-tool utility now supports mechanism IDs and handles ECDSA keys correctly Previously, the pkcs11-tool utility incorrectly handled EC_POINT values and support for certain vendor-specific mechanisms was missing. As a consequence, these mechanisms and certain ECDSA keys in hardware security modules (HSM) and smart cards were not supported by pkcs11-tool . With this update, the pkcs11-tool now handles EC_POINT values and vendor-specific mechanisms correctly. As a result, the utility now supports mechanism IDs and handles ECDSA keys correctly. (BZ# 1562572 ) OpenSCAP RPM verification rules no longer work incorrectly with VM and container file systems Previously, the rpminfo , rpmverify , and rpmverifyfile probes did not fully support offline mode. As a consequence, OpenSCAP RPM verification rules did not work correctly when scanning virtual machine (VM) and container file systems in offline mode. With this update, support for offline mode has been fixed, and results of scanning VM and container file systems in offline mode no longer contain false negatives. (BZ# 1556988 ) sudo no longer blocks poll() for /dev/ptmx Previously, when running a command through sudo that had the I/O logging enabled, a parent process of the command was occasionally blocked in the poll() function execution, waiting for an event on the /dev/ptmx file descriptor. Consequently, a deadlock occurred and sudo might leave the process of the command in an unresponsive state. This update adds a pseudoterminal cleanup logic, and sudo no longer causes a deadlock in the described scenario. (BZ# 1560657 )

Commands:
Chapter 2. Eclipse Temurin features Eclipse Temurin does not contain structural changes from the upstream distribution of OpenJDK. For the list of changes and security fixes that the latest OpenJDK 8 release of Eclipse Temurin includes, see OpenJDK 8u442 Released . New features and enhancements Eclipse Temurin 8.0.442 includes the following new features and enhancements. Option for jar command to avoid overwriting files when extracting an archive In earlier OpenJDK releases, when the jar tool extracted files from an archive, the jar tool overwrote any existing files with the same name in the target directory. OpenJDK 8.0.442 adds a new ‐k option that you can use to ensure that the jar tool does not overwrite existing files. For example: Note In OpenJDK 8.0.442, the jar tool retains the old behavior by default. If you do not explicitly specify the ‐k option, the jar tool automatically overwrites any existing files with the same name. See JDK-8335912 (JDK Bug System) and JDK bug system reference ID: JDK-8337499. Revised on 2025-01-30 11:19:31 UTC

Commands:
jar xkf myfile.jar
4.197. nmap 4.197.1. RHBA-2011:0967 - nmap bug fix update An updated nmap package that fixes one bug is now available for Red Hat Enterprise Linux 6. The nmap package provides a network exploration utility and a security scanner. Bug Fix BZ# 621045 Prior to this update, the output of the "nmap -h" (or "nmap --help") command did not describe all the available nmap options that begin with the "-s" or "-P" prefix. As a result, a user could have been unable to research what options can be used to perform specific tasks with nmap. With this update, the bug has been fixed so that the output of "nmap -h" now describes all the aforementioned nmap options that were previously missing from the output. All users of nmap are advised to upgrade to this updated package, which fixes this bug.

Commands:
7.113. libxml2 7.113.1. RHSA-2015:1419 - Low: libxml2 security and bug fix update Updated libxml2 packages that fix one security issue and one bug are now available for Red Hat Enterprise Linux 6. Red Hat Product Security has rated this update as having Low security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link in the References section. The libxml2 library is a development toolbox providing the implementation of various XML standards. Security Fix CVE-2015-1819 A denial of service flaw was found in the way the libxml2 library parsed certain XML files. An attacker could provide a specially crafted XML file that, when parsed by an application using libxml2, could cause that application to use an excessive amount of memory. This issue was discovered by Florian Weimer of Red Hat Product Security. Users of libxml2 are advised to upgrade to these updated packages, which contain backported patches to correct these issues. The desktop must be restarted (log out, then log back in) for this update to take effect.

Commands:
4.6.2. REAL SERVER Subsection Clicking on the REAL SERVER subsection link at the top of the panel displays the EDIT REAL SERVER subsection. It displays the status of the physical server hosts for a particular virtual service. Figure 4.7. The REAL SERVER Subsection Click the ADD button to add a new server. To delete an existing server, select the radio button beside it and click the DELETE button. Click the EDIT button to load the EDIT REAL SERVER panel, as seen in Figure 4.8, "The REAL SERVER Configuration Panel" . Figure 4.8. The REAL SERVER Configuration Panel This panel consists of three entry fields: Name A descriptive name for the real server. Note This name is not the host name for the machine, so make it descriptive and easily identifiable. Address The real server's IP address. Since the listening port is already specified for the associated virtual server, do not add a port number. Weight An integer value indicating this host's capacity relative to that of other hosts in the pool. The value can be arbitrary, but treat it as a ratio in relation to other real servers in the pool. For more on server weight, see Section 1.3.2, "Server Weight and Scheduling" . Warning Remember to click the ACCEPT button after making any changes in this panel. To make sure you do not lose any changes when selecting a new panel.

Commands:
Chapter 5. Checking DNS records using IdM Healthcheck You can identify issues with DNS records in Identity Management (IdM) using the Healthcheck tool. Prerequisites The DNS records Healthcheck tool is only available on RHEL 8.2 or newer. 5.1. DNS records healthcheck test The Healthcheck tool includes a test for checking that the expected DNS records required for autodiscovery are resolvable. To list all tests, run the ipa-healthcheck with the --list-sources option: You can find the DNS records check test under the ipahealthcheck.ipa.idns source. IPADNSSystemRecordsCheck This test checks the DNS records from the ipa dns-update-system-records --dry-run command using the first resolver specified in the /etc/resolv.conf file. The records are tested on the IPA server. 5.2. Screening DNS records using the healthcheck tool Follow this procedure to run a standalone manual test of DNS records on an Identity Management (IdM) server using the Healthcheck tool. The Healthcheck tool includes many tests. Results can be narrowed down by including only the DNS records tests by adding the --source ipahealthcheck.ipa.idns option. Prerequisites You must perform Healthcheck tests as the root user. Procedure To run the DNS records check, enter: If the record is resolvable, the test returns SUCCESS as a result: The test returns a WARNING when, for example, the number of records does not match the expected number: Additional resources See man ipa-healthcheck .

Commands:
ipa-healthcheck --list-sources
ipa-healthcheck --source ipahealthcheck.ipa.idns
{ "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "SUCCESS", "uuid": "eb7a3b68-f6b2-4631-af01-798cac0eb018", "when": "20200415143339Z", "duration": "0.210471", "kw": { "key": "_ldap._tcp.idm.example.com.:server1.idm.example.com." } }
{ "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "972b7782-1616-48e0-bd5c-49a80c257895", "when": "20200409100614Z", "duration": "0.203049", "kw": { "msg": "Got {count} ipa-ca A records, expected {expected}", "count": 2, "expected": 1 } }