mtpti5iD/redhat-docs_dataset huggingface dataset:
3.2.2. Adding a New User If there is a new user you need to add to the system, follow this procedure: Click the Add User button. Enter the user name and full name in the appropriate fields Type the user's password in the Password and Confirm Password fields. The password must be at least six characters long. Note For safety reasons, choose a long password not based on a dictionary term; use a combination of letters, numbers, and special characters. Select a login shell for the user from the Login Shell drop-down list or accept the default value of /bin/bash . Clear the Create home directory check box if you choose not to create the home directory for a new user in /home/ username / . You can also change this home directory by editing the content of the Home Directory text box. Note that when the home directory is created, default configuration files are copied into it from the /etc/skel/ directory. Clear the Create a private group for the user check box if you do not want a unique group with the same name as the user to be created. User private group (UPG) is a group assigned to a user account to which that user exclusively belongs, which is used for managing file permissions for individual users. Specify a user ID for the user by selecting Specify user ID manually . If the option is not selected, the available user ID above 500 is assigned to the new user. Click the OK button to complete the process. Look at the sample Add New User dialog box configuration: To configure more advanced user properties, such as password expiration, modify the user's properties after adding the user.

Commands:
Chapter 13. Getting started with kernel logging Log files provide messages about the system, including the kernel, services, and applications running on it. The logging system in Red Hat Enterprise Linux is provided by the built-in syslog protocol. Various utilities use this system to record events and organize them into log files. These files are useful when auditing the operating system or troubleshooting problems. 13.1. What is the kernel ring buffer During the boot process, the console provides important information about the initial phase of the system startup. To avoid loss of the early messages the kernel utilizes a ring buffer. This buffer stores all messages, including boot messages, generated by the printk() function within the kernel code. The messages from the kernel ring buffer are then read and stored in log files on permanent storage, for example, by the syslog service. The ring buffer is a cyclic data structure that has a fixed size, and is hard-coded into the kernel. Users can display data stored in the kernel ring buffer through the dmesg command or the /var/log/boot.log file. When the ring buffer is full, the new data overwrites the old. Additional resources syslog(2) and dmesg(1) manual page 13.2. Role of printk on log-levels and kernel logging Each message the kernel reports has a log-level associated with it that defines the importance of the message. The kernel ring buffer, as described in What is the kernel ring buffer , collects kernel messages of all log-levels. It is the kernel.printk parameter that defines what messages from the buffer are printed to the console. The log-level values break down in this order: 0 Kernel emergency. The system is unusable. 1 Kernel alert. Action must be taken immediately. 2 Condition of the kernel is considered critical. 3 General kernel error condition. 4 General kernel warning condition. 5 Kernel notice of a normal but significant condition. 6 Kernel informational message. 7 Kernel debug-level messages. By default, kernel.printk in RHEL 8 has the following values: The four values define the following, in order: Console log-level, defines the lowest priority of messages printed to the console. Default log-level for messages without an explicit log-level attached to them. Sets the lowest possible log-level configuration for the console log-level. Sets default value for the console log-level at boot time. Each of these values defines a different rule for handling error messages. Important The default 7 4 1 7 printk value allows for better debugging of kernel activity. However, when coupled with a serial console, this printk setting might cause intense I/O bursts that might lead to a RHEL system becoming temporarily unresponsive. To avoid these situations, setting a printk value of 4 4 1 7 typically works, but at the expense of losing the extra debugging information. Also note that certain kernel command line parameters, such as quiet or debug , change the default kernel.printk values. Additional resources syslog(2) manual page

Commands:
sysctl kernel.printk kernel.printk = 7 4 1 7
13.5. Clone Project Because each instance of a model contains a unique ID and each object in each model contains a unique ID, copying a project is a delicate task. For this reason, the Clone Project action was created to manage the creation of exact structural copies of all models in the source project. The following lists specific rules and limitations for this action. This action clones a complete model project containing any number of model (XMI or XSD) files organized in a user defined directory structure. All object references (UUIDs) within the original project will be replaced with new unique references. Any model dependencies or internal object references are refactored to reflect the dependencies within the cloned project. Any model references to models in projects external to the original project will NOT be replaced. Only XMI and XSD files are cloned. All other file types in your project will NOT be processed nor copied into your newly cloned project including VDBs. If one or more editors that require save are open, the user will be asked to save them before continuing with the cloning process. To clone a model project: Select an existing model project in the Model Explorer view. Right-click, then select Model Project > Clone in the context menu. Otherwise you can select the Project > Clone Project action located in the Teiid Designer 's main menu bar. Figure 13.7. Clone Project In Project Menu On the Clone Project wizard page, provide a name for your new project. Figure 13.8. Clone Project In Project Menu (Optional) If you wish to create your cloned project in a location other than your default workspace location, clear the Use default location checkbox and specify (type in or browse to) a new directory location on your local file system. Click Finish to generate your new project.

Commands:
Chapter 7. The fed_variables file

Commands:
FQDN of IPA server FED_IPA_HOST="jdennis-ipa.example.com" Base DN of IPA server FED_IPA_BASE_DN="dc=example,dc=com" IPA administrator password FED_IPA_ADMIN_PASSWD="FreeIPA4All" Password used by RH-SSO service to authenticate to IPA when RH-SSO obtains user/group information from IPA as part of RH-SSO's User Federation. FED_IPA_RHSSO_SERVICE_PASSWD="rhsso-passwd" RH-SSO server IP address FED_RHSSO_IP_ADDR="10.0.0.12" RH-SSO server FQDN FED_RHSSO_FQDN="jdennis-rhsso-7" URL used to access the RH-SSO server FED_RHSSO_URL="https://USDFED_RHSSO_FQDN" Administrator password for RH-SSO server FED_RHSSO_ADMIN_PASSWORD=FreeIPA4All Name of the RH-SSO realm FED_RHSSO_REALM="openstack" Host name of the mellon server Note, this is identical to the Keystone server since Keystone is being front by Apache which is protecting it's resources with mellon. FED_KEYSTONE_HOST="overcloud.localdomain" Port number mellon is running on the FED_KEYSTONE_HOST Note, this is identical to the Keystone server port FED_KEYSTONE_HTTPS_PORT=13000 Name assigned in OpenStack to our IdP FED_OPENSTACK_IDP_NAME="rhsso" Name of our Keystone mapping rules FED_OPENSTACK_MAPPING_NAME="USD{FED_OPENSTACK_IDP_NAME}_mapping"
8.146. mutt 8.146.1. RHBA-2014:0945 - mutt bug fix update Updated mutt packages that fix several bugs are now available for Red Hat Enterprise Linux 6. Mutt is a low resource, highly configurable, text-based MIME e-mail client. Mutt supports most e-mail storing formats, such as mbox and Maildir, as well as most protocols, including POP3 and IMAP. Bug Fixes BZ# 674271 Prior to this update, an internal hash referencing a specific subject in each envelope referenced a non-existent one. As a consequence, mutt terminated with a segmentation fault when the user attempted to synchronize mailbox after removing one or more messages in threaded mode. With this update, the subject hash updates correctly and the crash no longer occurs. BZ# 690409 Previously, the array that stores mutt message headers did not properly handle empty header entries. This could cause mutt to terminate unexpectedly with a segmentation fault when a change of message IDs occurred on the IMAP server, for example when the IMAP server was connected with multiple clients while removing messages through one of them. In this update, the handling of empty headers has been optimized and sorting messages in the array has been streamlined. As a result, multiple connected clients now synchronize correctly. BZ# 750929 Prior to this update, mutt did not correctly parse certificate files when accessing accounts through IMAP and POP3 protocols. Consequently, mutt terminated unexpectedly with a segmentation fault when attempting to access an IMAP or POP3 account. This update fixes the parsing process and accessing an IMAP or POP3 account now functions as intended. BZ# 1083524 Previously, a bug prevented mutt's interactive certificate verification from working properly. As a consequence, mutt terminated unexpectedly with a segmentation fault when the user tried to send an e-mail message from the command line to a TLS server, for which mutt had not received the certificate yet. With this update, mutt's interactive certificate verification has been fixed and the described crash no longer occurs. Users of mutt are advised to upgrade to these updated packages, which fix these bugs.

Commands:
14.6. Ensuring That ID Values Are Unique It is recommended to avoid conflicting UIDs or GIDs. UIDs and GIDs should always be unique: two users should not have the same UID, and two groups should not have the same GID. Automatic ID assignment When a user or a group is created interactively or without a manually specified ID number, the server assigns the available ID number from the ID range to the user account. This ensures that the UID or GID is always unique. Manual ID assignment When you assign an ID to a user or a group entry manually, the server does not verify that the specified UID or GID is unique; it does not warn you of a conflict if you choose a value that is already used by another entry. As explained in Section 14.7, "Repairing Changed UID and GID Numbers" , the SSSD service does not handle entries with identical IDs. If two entries share the same ID number, a search for this ID only returns the first entry. However, if you search for other attributes or run the ipa user-find --all command, both entries are returned. UIDs and GIDs are both selected from the same ID range. A user and a group can have the same ID; no conflict arises in this situation because the UID and the GID are set in two different attributes: uidNumber and gidNumber . Note Setting the same ID for both a user and a group allows you to configure user private groups. To create a unique system group for a user in this way, set the same ID value for a user and also for a group, in which the only member is the mentioned user.

Commands:
Chapter 13. Configuring alert notifications In OpenShift Container Platform, an alert is fired when the conditions defined in an alerting rule are true. An alert provides a notification that a set of circumstances are apparent within a cluster. Firing alerts can be viewed in the Alerting UI in the OpenShift Container Platform web console by default. After an installation, you can configure OpenShift Container Platform to send alert notifications to external systems. 13.1. Sending notifications to external systems In OpenShift Container Platform 4.15, firing alerts can be viewed in the Alerting UI. Alerts are not configured by default to be sent to any notification systems. You can configure OpenShift Container Platform to send alerts to the following receiver types: PagerDuty Webhook Email Slack Microsoft Teams Routing alerts to receivers enables you to send timely notifications to the appropriate teams when failures occur. For example, critical alerts require immediate attention and are typically paged to an individual or a critical response team. Alerts that provide non-critical warning notifications might instead be routed to a ticketing system for non-immediate review. Checking that alerting is operational by using the watchdog alert OpenShift Container Platform monitoring includes a watchdog alert that fires continuously. Alertmanager repeatedly sends watchdog alert notifications to configured notification providers. The provider is usually configured to notify an administrator when it stops receiving the watchdog alert. This mechanism helps you quickly identify any communication issues between Alertmanager and the notification provider. 13.2. Additional resources About OpenShift Container Platform monitoring Configuring alert notifications

Commands:
2.2. Java Virtual Machine A Java Virtual Machine (JVM) is a virtual environment that runs and executes Java programs on a host operating system. The JVM acts as an abstract computer and is a platform-independent execution environment that converts the Java programming code into machine language. A Java Virtual Machine (JVM) makes Java portable by providing an abstraction layer between the compiled Java program and the underlying hardware platform and operating system. Red Hat recommends using OpenJDK Java platform as it is an open source, supported Java Virtual Machine that runs well on Red Hat Enterprise Linux systems. For Windows users, Oracle JDK 1.6 installation is recommended. 23154%2C+Getting+Started+Guide-6.608-09-2016+09%3A22%3A31JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
23.9.3. Configuring timemaster Options Procedure 23.1. Editing the timemaster Configuration File To change the default configuration, open the /etc/timemaster.conf file for editing as root : For each NTP server you want to control using timemaster , create [ntp_server address ] sections . Note that the short polling values in the example section are not suitable for a public server, see Chapter 22, Configuring NTP Using ntpd for an explanation of suitable minpoll and maxpoll values. To add interfaces that should be used in a domain, edit the #[ptp_domain 0] section and add the interfaces. Create additional domains as required. For example: If required to use ntpd as the NTP daemon on this system, change the default entry in the [timemaster] section from chronyd to ntpd . See Configuring NTP Using the chrony Suite for information on the differences between ntpd and chronyd. If using chronyd as the NTP server on this system, add any additional options below the default include /etc/chrony.conf entry in the [chrony.conf] section. Edit the default include entry if the path to /etc/chrony.conf is known to have changed. If using ntpd as the NTP server on this system, add any additional options below the default include /etc/ntp.conf entry in the [ntp.conf] section. Edit the default include entry if the path to /etc/ntp.conf is known to have changed. In the [ptp4l.conf] section, add any options to be copied to the configuration file generated for ptp4l . This chapter documents common options and more information is available in the ptp4l(8) manual page. In the [chronyd] section, add any command line options to be passed to chronyd when called by timemaster . See Configuring NTP Using the chrony Suite for information on using chronyd . In the [ntpd] section, add any command line options to be passed to ntpd when called by timemaster . See Chapter 22, Configuring NTP Using ntpd for information on using ntpd . In the [phc2sys] section, add any command line options to be passed to phc2sys when called by timemaster . This chapter documents common options and more information is available in the phy2sys(8) manual page. In the [ptp4l] section, add any command line options to be passed to ptp4l when called by timemaster . This chapter documents common options and more information is available in the ptp4l(8) manual page. Save the configuration file and restart timemaster by issuing the following command as root :

Commands:
~]# vi /etc/timemaster.conf
[ptp_domain 0] interfaces eth0 [ptp_domain 1] interfaces eth1
~]# service timemaster restart
20.2. Setting Kerberos Ticket Policies The Kerberos ticket policy sets basic restrictions on managing tickets within the Kerberos realm, such as the maximum ticket lifetime and the maximum renewal age (the period during which the ticket is renewable). The Kerberos ticket policy is set globally so that it applies to every ticket issued within the realm. IdM also has the ability to set user-level ticket policies which override the global policies. This can be used, for example, to set extended expiration times for administrators or to set shorter expiration times for some employees. 20.2.1. Setting Global Ticket Policies 20.2.1.1. From the Web UI Click the Policy tab, and then click the Kerberos Ticket Policy subtab. Change the ticket lifetime policies. Max renew sets the period after a ticket expires that it can be renewed. Max life sets the active period (lifetime) of a Kerberos ticket. Click the Update link at the top of the policy page. Restart the KDC. Important Any change to the global Kerberos ticket policy requires a restart of the KDC for the changes to take effect. 20.2.1.2. From the Command Line The ipa krbtpolicy-mod command modifies the policy, while the ipa krbtpolicy-reset command resets the policy to the default values. For example: Important Any change to the global Kerberos ticket policy requires a restart of the KDC for the changes to take effect. Restart the KDC: 20.2.2. Setting User-Level Ticket Policies User-level Kerberos ticket policies are set using the same commands as global policies, but the user is specified in the command. For example: Important User-level policies take effect immediately on the requested ticket (such as running kinit ), without having to restart the KDC service.

Commands:
service krb5kdc restart
ipa krbtpolicy-mod --maxlife=3600 --maxrenew=18000 Max life: 3600 Max renew: 18000
service krb5kdc restart
ipa krbtpolicy-mod jsmith --maxlife=3600 Max life: 3600
Assessing and Monitoring Security Policy Compliance of RHEL Systems Red Hat Insights 1-latest Understanding the Security Compliance Status of your Red Hat Enterprise Linux Infrastructure Red Hat Customer Content Services

Commands:
[user@insights]USD cat /etc/redhat-release
dnf info scap-security-guide-0.1.57-3.el8_4
dnf install scap-security-guide-0.1.57-3.el8_4
insights-client --compliance
insights-client --compliance insights-client --collector malware-detection
crontab -e
10 20 * * * /bin/insights-client --compliance 10 21 * * * /bin/insights-client --collector malware-detection
insights-client --compliance-policies
insights-client --compliance-assign <ID>.
insights-client --compliance-unassign <ID>
USE [master] GO CREATE LOGIN [assessmentLogin] with PASSWORD= N'<*PASSWORD*>' ALTER SERVER ROLE [sysadmin] ADD MEMBER [assessmentLogin] GO
echo "assessmentLogin" > /var/opt/mssql/secrets/assessment echo "<*PASSWORD*>" >> /var/opt/mssql/secrets/assessment
chmod 0600 /var/opt/mssql/secrets/assessment chown mssql:mssql /var/opt/mssql/secrets/assessment
yum -y install powershell
su mssql -c "/usr/bin/pwsh -Command Install-Module SqlServer"
/bin/curl -LJ0 -o /opt/mssql/bin/runassessment.ps1 https://raw.githubusercontent.com/microsoft/sql-server-samples/master/samples/manage/sql-assessment-api/RHEL/runassessment.ps1 chown mssql:mssql /opt/mssql/bin/runassessment.ps1 chmod 0700 /opt/mssql/bin/runassessment.ps1
mkdir /var/opt/mssql/log/assessments/ chown mssql:mssql /var/opt/mssql/log/assessments/ chmod 0700 /var/opt/mssql/log/assessments/
su mssql -c "pwsh -File /opt/mssql/bin/runassessment.ps1"
insights-client
cp mssql-runassessment.service /etc/systemd/system/ cp mssql-runassessment.timer /etc/systemd/system/ chmod 644 /etc/systemd/system/
systemctl enable --now mssql-runassessment.timer
insights-client --group=<name-you-choose>
tags --- group: eastern-sap name: Jane Example contact: jexample@corporate.com Zone: eastern time zone Location: - gray_rack - basement Application: SAP
tags --- group: eastern-sap location: Boston description: - RHEL8 - SAP key 4: value
insights-client
vi /etc/insights-client/tags.yaml
cat /etc/insights-client/tags.yaml group: redhat location: Brisbane/Australia description: - RHEL8 - SAP security: strict network_performance: latency
insights-client
Chapter 3. Managing RAID devices using the Web Console 3.1. Configuring a new RAID Device using the Web Console Log in to the Web Console. Click the hostname Storage . Click the + button beside RAID Devices . Figure 3.1. RAID Devices The Create RAID Device window opens. Figure 3.2. Create Raid Device window Specify a Name for your RAID device. Specify the RAID Level to use. Note Only RAID5 and RAID6 are supported for RHHI for Virtualization. Leave the Chunk Size as the default value. Check the Disks to use in creating the RAID device. Click Create .

Commands:
Chapter 19. Domains 19.1. Domain Elements The API provides the ability to access user and group information from the organization's directory service using the domains collection. Domain information is referenced with the rel="domains" link. Table 19.1. Domain elements Element Type Description name string The domain name. link rel="users" relationship A link to the sub-collection for users associated with this domain. link rel="groups" relationship A link to the sub-collection for groups associated with this domain. The links to users and groups sub-collections also accept search queries. Note The domains collection and its sub-collections are read-only.

Commands:
Chapter 1. HawtIO release notes HawtIO 4.1 / HawtIO-Online 2.1 This chapter provides release information about HawtIO Diagnostic Console Guide. 1.1. HawtIO Features The HawtIO Diagnostic Console includes the following main features: Runtime management of JVM via JMX, especially that of Camel applications with specialised views Visualisation and debugging/tracing of Camel routes Simple managing and monitoring of application metrics 1.2. Release features HawtIO UI PatternFly upgraded to v5 HawtIO Operator Support for s390x and ppc64le architectures; Addition of default text for console launcher in OpenShift dashboard HawtIO Online Upgrade of container web server to nginx 1.22.1 Replacement of nginx njs module with separate gateway container Gateway container acts as side-car to main application container, running Express 4.21.0 Node-js application server Gateway is responsible for the following functions: Limit access to OpenShift cluster interfaces Manage connection requests to jolokia interfaces on applicable OpenShift pods Upgrade of UI components to Patternfly 5 Discovery: Separate pods by namespace into their own tabs Limit the display of pods from each namespace to a default number (3) Adds pagination for navigating to the set of applicable pods in a namespace Option to modify the number of pods displayed per namespace Option to modify the polling interval between checks on pod jolokia interfaces Discover plugin only displayed if no connection to a pod has yet been requested Support for IBM Power and IBM Z This release of Red Hat build of HawtIO adds support for IBM Power and IBM Z. 1.3. HawtIO known issues The following issue remain with HawtIO for this release: HAWNG-767 Cannot inject custom icons as Application Menu entry The imageRelativePath property must be relative to the route host hence is currently limited as to what icons can be used (the poweredby icon is a Red Hat branded image). Need a way to inject such icons into the path, maybe via including them in a configmap (another one??) or including them directly in the CR using base64 (CSVs do it). Revised on 2024-12-12 11:05:02 UTC

Commands: