mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 48. module This chapter describes the commands under the module command. 48.1. module list List module versions Usage: Table 48.1. Command arguments Value Summary -h, --help Show this help message and exit --all Show all modules that have version information Table 48.2. Output formatter options Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated to show multiple columns Table 48.3. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 48.4. Shell formatter options Value Summary --prefix PREFIX Add a prefix to all variable names Table 48.5. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack module list [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty] [--all]
Chapter 15. Configuring API tokens Red Hat Advanced Cluster Security for Kubernetes (RHACS) requires API tokens for some system integrations, authentication processes, and system functions. You can configure tokens using the RHACS web interface. Note To prevent privilege escalation, when you create a new token, your role's permissions limit the permission you can assign to that token. For example, if you only have read permission for the Integration resource, you cannot create a token with write permission. If you want a custom role to create tokens for other users to use, you must assign the required permissions to that custom role. Use short-lived tokens for machine-to-machine communication, such as CI/CD pipelines, scripts, and other automation. Also, use the roxctl central login command for human-to-machine communication, such as roxctl CLI or API access. The majority of cloud service providers support OIDC identity tokens, for example, Microsoft Entra ID, Google Cloud Identity Platform, and AWS Cognito. OIDC identity tokens issued by these services can be used for RHACS short-lived access. 15.1. Creating an API token Procedure In the RHACS portal, go to Platform Configuration Integrations . Scroll to the Authentication Tokens category, and then click API Token . Click Generate Token . Enter a name for the token and select a role that provides the required level of access (for example, Continuous Integration or Sensor Creator ). Click Generate . Important Copy the generated token and securely store it. You will not be able to view it again. Additional resources Using an authentication provider to authenticate with roxctl Configuring short-lived access 15.2. About API token expiration API tokens expire one year from the creation date. RHACS alerts you in the web interface and by sending log messages to Central when a token will expire in less than one week. The log message process runs once an hour. Once a day, the process lists the tokens that are expiring and creates a log message for each one. Log messages are issued once a day and appear in Central logs. Logs have the format as shown in the following example: Warn: API Token [token name] (ID [token ID]) will expire in less than X days. You can change the default settings for the log message process by configuring the environment variables shown in the following table: Environment variable Default value Description ROX_TOKEN_EXPIRATION_NOTIFIER_INTERVAL 1h (1 hour) The frequency at which the log message background loop that lists tokens and creates the logs will run. ROX_TOKEN_EXPIRATION_NOTIFIER_BACKOFF_INTERVAL 24h (1 day) The frequency at which the loop lists tokens and issues notifications. ROX_TOKEN_EXPIRATION_DETECTION_WINDOW 168h (1 week) The time period before expiration of the token that will cause the notification to be generated.

Commands:
Warn: API Token [token name] (ID [token ID]) will expire in less than X days.
Chapter 2. Managing users As a cloud administrator, you can add, modify, and delete users in the dashboard. Users can be members of one or more projects. You can manage projects and users independently from each other. 2.1. Creating users with the dashboard You can assign a primary project and role to the user. Users that you create with OpenStack Dashboard (horizon) are Identity service users by default. You can integrate Active Directory users by configuring the LDAP provider included with the Identity service. Procedure Log in to the Dashboard as an admin user. Select Identity > Users . Click Create User . Enter a user name, email, and preliminary password for the user. Select a project from the Primary Project list. Select a role for the user from the Role list. The default role is member . Click Create User . 2.2. Editing users with the dashboard You can update user details, including the primary project. Procedure Log in to the dashboard as an admin user. Select Identity > Users . In the Actions column, click Edit . In the Update User window, you can update the User Name , Email , and Primary Project . Click Update User . 2.3. Enabling or disabling users with the dashboard You can disable a user with the dashboard. This action is reversible, unlike deleting a user. Limitations: You cannot disable or enable more than one user at a time. You cannot set the primary project of a user to active. The result is that the user you have disabled cannot: Log in to the dashboard. Get access to RHOSP services. Do any user-project action in the dashboard. Procedure As an admin user in the dashboard, select Identity > Users . In the Actions column, click the arrow, and select Enable User or Disable User . In the Enabled column, the value then updates to either True or False . 2.4. Deleting a user with the dashboard You must be a user with an administrative role to delete other users. This action cannot be reversed. Procedure As an admin user in the dashboard, select Identity > Users . Select the users you want to delete. Click Delete Users . The Confirm Delete Users window is displayed. Click Delete Users to confirm the action.

Commands:
1.6. Pre-installation Script You can add commands to run on the system immediately after the ks.cfg has been parsed. This section must be at the end of the kickstart file (after the commands) and must start with the %pre command. You can access the network in the %pre section; however, name service has not been configured at this point, so only IP addresses work. Note Note that the pre-install script is not run in the change root environment. --interpreter /usr/bin/python Allows you to specify a different scripting language, such as Python. Replace /usr/bin/python with the scripting language of your choice. 1.6.1. Example Here is an example %pre section: This script determines the number of hard drives in the system and writes a text file with a different partitioning scheme depending on whether it has one or two drives. Instead of having a set of partitioning commands in the kickstart file, include the line: The partitioning commands selected in the script are used. Note The pre-installation script section of kickstart cannot manage multiple install trees or source media. This information must be included for each created ks.cfg file, as the pre-installation script occurs during the second stage of the installation process.

Commands:
%pre #!/bin/sh hds="" mymedia="" for file in /proc/ide/h* do mymedia=`cat USDfile/media` if [ USDmymedia == "disk" ] ; then hds="USDhds `basename USDfile`" fi done set USDhds numhd=`echo USD#` drive1=`echo USDhds | cut -d' ' -f1` drive2=`echo USDhds | cut -d' ' -f2` #Write out partition scheme based on whether there are 1 or 2 hard drives if [ USDnumhd == "2" ] ; then #2 drives echo "#partitioning scheme generated in %pre for 2 drives" > /tmp/part-include echo "clearpart --all" >> /tmp/part-include echo "part /boot --fstype ext3 --size 75 --ondisk hda" >> /tmp/part-include echo "part / --fstype ext3 --size 1 --grow --ondisk hda" >> /tmp/part-include echo "part swap --recommended --ondisk USDdrive1" >> /tmp/part-include echo "part /home --fstype ext3 --size 1 --grow --ondisk hdb" >> /tmp/part-include else #1 drive echo "#partitioning scheme generated in %pre for 1 drive" > /tmp/part-include echo "clearpart --all" >> /tmp/part-include echo "part /boot --fstype ext3 --size 75" >> /tmp/part-includ echo "part swap --recommended" >> /tmp/part-include echo "part / --fstype ext3 --size 2048" >> /tmp/part-include echo "part /home --fstype ext3 --size 2048 --grow" >> /tmp/part-include fi
%include /tmp/part-include
function::user_string_n_quoted Name function::user_string_n_quoted - Retrieves and quotes string from user space Synopsis Arguments addr the user space address to retrieve the string from n the maximum length of the string (if not null terminated) Description Returns up to n characters of a C string from the given user space memory address where any ASCII characters that are not printable are replaced by the corresponding escape sequence in the returned string. Note that the string will be surrounded by double quotes. On the rare cases when userspace data is not accessible at the given address, the address itself is returned as a string, without double quotes.

Commands:
user_string_n_quoted:string(addr:long,n:long)
4.6.3. EDIT MONITORING SCRIPTS Subsection Click on the MONITORING SCRIPTS link at the top of the page. The EDIT MONITORING SCRIPTS subsection allows the administrator to specify a send/expect string sequence to verify that the service for the virtual server is functional on each real server. It is also the place where the administrator can specify customized scripts to check services requiring dynamically changing data. Figure 4.9. The EDIT MONITORING SCRIPTS Subsection Sending Program For more advanced service verification, you can use this field to specify the path to a service-checking script. This functionality is especially helpful for services that require dynamically changing data, such as HTTPS or SSL. To use this functionality, you must write a script that returns a textual response, set it to be executable, and type the path to it in the Sending Program field. Note To ensure that each server in the real server pool is checked, use the special token %h after the path to the script in the Sending Program field. This token is replaced with each real server's IP address as the script is called by the nanny daemon. The following is a sample script to use as a guide when composing an external service-checking script: Note If an external program is entered in the Sending Program field, then the Send field is ignored. Send Enter a string for the nanny daemon to send to each real server in this field. By default the send field is completed for HTTP. You can alter this value depending on your needs. If you leave this field blank, the nanny daemon attempts to open the port and assume the service is running if it succeeds. Only one send sequence is allowed in this field, and it can only contain printable, ASCII characters as well as the following escape characters: \n for new line. \r for carriage return. \t for tab. \ to escape the character which follows it. Expect Enter a the textual response the server should return if it is functioning properly. If you wrote your own sending program, enter the response you told it to send if it was successful. Note To determine what to send for a given service, you can open a telnet connection to the port on a real server and see what is returned. For instance, FTP reports 220 upon connecting, so could enter quit in the Send field and 220 in the Expect field. 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. Once you have configured virtual servers using the Piranha Configuration Tool , you must copy specific configuration files to the backup LVS router. See Section 4.7, "Synchronizing Configuration Files" for details.

Commands:
#!/bin/sh TEST=`dig -t soa example.com @USD1 | grep -c dns.example.com if [ USDTEST != "1" ]; then echo "OK else echo "FAIL" fi
14.13.7. Configuring Memory Allocation To modify a guest virtual machine's memory allocation with virsh : You must specify the count in kilobytes. The new count value cannot exceed the amount you specified when you created the guest virtual machine. Values lower than 64 MB are unlikely to work with most guest virtual machine operating systems. A higher maximum memory value does not affect active guest virtual machines. If the new value is lower than the available memory, it will shrink possibly causing the guest virtual machine to crash. This command has the following options: [--domain] <string> domain name, id or uuid [--size] <number> new memory size, as scaled integer (default KiB) Valid memory units include: b or bytes for bytes KB for kilobytes (10 3 or blocks of 1,000 bytes) k or KiB for kibibytes (2 10 or blocks of 1024 bytes) MB for megabytes (10 6 or blocks of 1,000,000 bytes) M or MiB for mebibytes (2 20 or blocks of 1,048,576 bytes) GB for gigabytes (10 9 or blocks of 1,000,000,000 bytes) G or GiB for gibibytes (2 30 or blocks of 1,073,741,824 bytes) TB for terabytes (10 12 or blocks of 1,000,000,000,000 bytes) T or TiB for tebibytes (2 40 or blocks of 1,099,511,627,776 bytes) Note that all values will be rounded up to the nearest kibibyte by libvirt, and may be further rounded to the granularity supported by the hypervisor. Some hypervisors also enforce a minimum, such as 4000KiB (or 4000 x 2 10 or 4,096,000 bytes). The units for this value are determined by the optional attribute memory unit , which defaults to the kibibytes (KiB) as a unit of measure where the value given is multiplied by 2 10 or blocks of 1024 bytes. --config takes affect boot --live controls the memory of the running domain --current controls the memory on the current domain

Commands:
virsh setmem {domain-id or domain-name} count
virsh setmem vr-rhel6u1-x86_64-kvm --kilobytes 1025000
5.4.15. Shrinking Logical Volumes You can reduce the size of a logical volume with the lvreduce command. Note Shrinking is not supported on a GFS2 or XFS file system, so you cannot reduce the size of a logical volume that contains a GFS2 or XFS file system. If the logical volume you are reducing contains a file system, to prevent data loss you must ensure that the file system is not using the space in the logical volume that is being reduced. For this reason, it is recommended that you use the --resizefs option of the lvreduce command when the logical volume contains a file system. When you use this option, the lvreduce command attempts to reduce the file system before shrinking the logical voume. If shrinking the file sytem fails, as can occur if the file system is full or the file system does not support shrinking, then the lvreduce command will fail and not attempt to shrink the logical volume. Warning In most cases, the lvreduce command warns about possible data loss and asks for a confirmation. However, you should not rely on these confirmation prompts to prevent data loss because in some cases you will not see these prompts, such as when the logical volume is inactive or the --resizefs option is not used. Note that using the --test option of the lvreduce command does not indicate where the operation is safe, as this option does not check the file system or test the file system resize. The following command shrinks the logical volume lvol1 in volume group vg00 to be 64 megabytes. In this example, lvol1 contains a file system, which this command resizes together with the logical volume. This example shows the output to the command. Specifying the - sign before the resize value indicates that the value will be subtracted from the logical volume's actual size. The following example shows the command you would use if, instead of shrinking a logical volume to an absolute size of 64 megabytes, you wanted to shrink the volume by a value 64 megabytes.

Commands:
lvreduce --resizefs -L 64M vg00/lvol1 fsck from util-linux 2.23.2 /dev/mapper/vg00-lvol1: clean, 11/25688 files, 8896/102400 blocks resize2fs 1.42.9 (28-Dec-2013) Resizing the filesystem on /dev/mapper/vg00-lvol1 to 65536 (1k) blocks. The filesystem on /dev/mapper/vg00-lvol1 is now 65536 blocks long. Size of logical volume vg00/lvol1 changed from 100.00 MiB (25 extents) to 64.00 MiB (16 extents). Logical volume vg00/lvol1 successfully resized.
lvreduce --resizefs -L -64M vg00/lvol1
Appendix A. Using your subscription AMQ Streams is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. Accessing Your Account Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. Activating a Subscription Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. Downloading Zip and Tar Files To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the AMQ Streams for Apache Kafka entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ Streams product. The Software Downloads page opens. Click the Download link for your component. Installing packages with DNF To install a package and all the package dependencies, use: dnf install <package_name> To install a previously-downloaded package from a local directory, use: dnf install <path_to_download_package> Revised on 2024-08-12 11:05:05 UTC

Commands:
dnf install <package_name>
dnf install <path_to_download_package>
Chapter 9. Networking iptables supports -C option This update adds support for the -C check option to the iptables commands. Previously, there was no simple way to check if a certain rule existed. Now, the -C option can be used in a rule to check if a rule exists. Support for IPv6 IP sets This update adds support for IPv6 IP sets, as IP sets were not previously usable in IPv6 firewall rules.

Commands:
A.2. Displaying Quota Limits and Usage with the gfs2_quota Command Quota limits and current usage can be displayed for a specific user or group using the gfs2_quota get command. The entire contents of the quota file can also be displayed using the gfs2_quota list command, in which case all IDs with a non-zero hard limit, soft limit, or value are listed. Usage Displaying Quota Limits for a User Displaying Quota Limits for a Group Displaying Entire Quota File User A user ID to display information about a specific user. It can be either a user name from the password file or the UID number. Group A group ID to display information about a specific group. It can be either a group name from the group file or the GID number. MountPoint Specifies the GFS2 file system to which the actions apply. Command Output GFS2 quota information from the gfs2_quota command is displayed as follows: The LimitSize , WarnSize , and Value numbers (values) are in units of megabytes by default. Adding the -k , -s , or -b flags to the command line change the units to kilobytes, sectors, or file system blocks, respectively. User A user name or ID to which the data is associated. Group A group name or ID to which the data is associated. LimitSize The hard limit set for the user or group. This value is zero if no limit has been set. Value The actual amount of disk space used by the user or group. Comments When displaying quota information, the gfs2_quota command does not resolve UIDs and GIDs into names if the -n option is added to the command line. Space allocated to GFS2's hidden files can be left out of displayed values for the root UID and GID by adding the -d option to the command line. This is useful when trying to match the numbers from gfs2_quota with the results of a du command. Examples This example displays quota information for all users and groups that have a limit set or are using any disk space on file system /mygfs2 . This example displays quota information in sectors for group users on file system /mygfs2 .

Commands:
gfs2_quota get -u User -f MountPoint
gfs2_quota get -g Group -f MountPoint
gfs2_quota list -f MountPoint
user User : limit: LimitSize warn: WarnSize value: Value group Group : limit: LimitSize warn: WarnSize value: Value
gfs2_quota list -f /mygfs2
gfs2_quota get -g users -f /mygfs2 -s
Chapter 3. Creating a GitOps git token In this procedure and the one, you create two more values that you need in your ~/install_values.txt file to complete installation. Prerequisites: A GitHub account Procedure: In your web browser, go to your Developer Settings page in GitHub. In the left panel, under Personal access tokens , select Tokens (classic) . From the Generate new token drop down menu under the page banner, select Generate new token (classic) . You may need to authenticate to continue. Enter a name, select an expiration date, and under Select scopes , select repo (which should automatically include all scopes from repo: status to security_events ). Select Generate token . GitHub redirects you to a new page, where your token is visible. Make sure to label and save this token in ~/install_values.txt .

Commands:
2.3. The Software Collection Root Directory You can change the location of the root directory by setting the %_scl_prefix macro in the spec file, as in the following example: %global _scl_prefix /opt/ provider where provider is the provider (vendor) name registered, where applicable, with the Linux Foundation and the subordinated Linux Assigned Names and Numbers Authority (LANANA), in conformance with the Filesystem Hierarchy Standard. Each organization or project that builds and distributes Software Collections should use its own provider name, which conforms to the Filesystem Hierarchy Standard (FHS) and avoids possible conflicts between Software Collections and the base system installation. You are advised to make the file system hierarchy conform to the following layout: Note You must define the _scl_prefix macro above the %scl_package macro in the spec file. For more information on the Filesystem Hierarchy Standard, see http://www.pathname.com/fhs/ . For more information on the Linux Assigned Names and Numbers Authority, see http://www.lanana.org/ .

Commands:
%global _scl_prefix /opt/ provider
/opt/ provider / prefix-application-version /