mtpti5iD/redhat-docs_dataset huggingface dataset:
19.2. Using volume_key as an individual user As an individual user, volume_key can be used to save encryption keys by using the following procedure. Note For all examples in this file, /path/to/volume is a LUKS device, not the plaintext device contained within. blkid -s type /path/to/volume should report type ="crypto_LUKS" . Procedure 19.1. Using volume_key stand-alone Run: A prompt will then appear requiring an escrow packet passphrase to protect the key. Save the generated escrow-packet file, ensuring that the passphrase is not forgotten. If the volume passphrase is forgotten, use the saved escrow packet to restore access to the data. Procedure 19.2. Restore access to data with escrow packet Boot the system in an environment where volume_key can be run and the escrow packet is available (a rescue mode, for example). Run: A prompt will appear for the escrow packet passphrase that was used when creating the escrow packet, and for the new passphrase for the volume. Mount the volume using the chosen passphrase. To free up the passphrase slot in the LUKS header of the encrypted volume, remove the old, forgotten passphrase by using the command cryptsetup luksKillSlot .

Commands:
volume_key --save /path/to/volume -o escrow-packet
volume_key --restore /path/to/volume escrow-packet
Chapter 1. Introduction Before using this guide to configure JBoss EAP, it is assumed that the latest version of JBoss EAP has been downloaded and installed. For installation instructions, see Red Hat JBoss Enterprise Application Platform Installation Methods . Important Since the installation location of JBoss EAP will vary between host machines, this guide refers to the installation location as EAP_HOME . The actual location of the JBoss EAP installation should be used instead of EAP_HOME when performing administrative tasks.

Commands:
Chapter 13. Uninstalling a cluster on vSphere that uses installer-provisioned infrastructure You can remove a cluster that you deployed in your VMware vSphere instance by using installer-provisioned infrastructure. Note When you run the openshift-install destroy cluster command to uninstall OpenShift Container Platform, vSphere volumes are not automatically deleted. The cluster administrator must manually find the vSphere volumes and delete them. 13.1. Removing a cluster that uses installer-provisioned infrastructure You can remove a cluster that uses installer-provisioned infrastructure from your cloud. Note After uninstallation, check your cloud provider for any resources not removed properly, especially with User Provisioned Infrastructure (UPI) clusters. There might be resources that the installer did not create or that the installer is unable to access. Prerequisites You have a copy of the installation program that you used to deploy the cluster. You have the files that the installation program generated when you created your cluster. Procedure From the directory that contains the installation program on the computer that you used to install the cluster, run the following command: USD ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info 1 2 1 For <installation_directory> , specify the path to the directory that you stored the installation files in. 2 To view different details, specify warn , debug , or error instead of info . Note You must specify the directory that contains the cluster definition files for your cluster. The installation program requires the metadata.json file in this directory to delete the cluster. Optional: Delete the <installation_directory> directory and the OpenShift Container Platform installation program.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
Appendix A. Revision History 0.1-2 Wed May 15 2024, Gabriela Necasova ( gnecasov@redhat.com ) Release of the Red Hat Enterprise Linux 8.10 Package manifest. 0.1-1 Wed Nov 15 2023, Jana Heves ( jheves@redhat.com ) Release of the Red Hat Enterprise Linux 8.9 Package manifest. 0.1-0 Thu Apr 27 2023, Jana Heves ( jheves@redhat.com ) Release of the Red Hat Enterprise Linux 8.8 Package manifest. 0.0-9 Thu Oct 26 2022, Jana Heves ( jheves@redhat.com ) Release of the Red Hat Enterprise Linux 8.7 Package manifest. 0.0-8 Thu Apr 28 2022, Jana Heves ( jheves@redhat.com ) Release of the Red Hat Enterprise Linux 8.6 Package manifest. 0.0-7 Wed Nov 10 2021, Jana Heves ( jheves@redhat.com ) Release of the Red Hat Enterprise Linux 8.5 Package manifest. 0.0-6 Wed May 12 2021, Lenka Spackova ( lspackova@redhat.com ) Release of the Red Hat Enterprise Linux 8.4 Package manifest. 0.0-5 Tue Nov 03 2020, Lenka Spackova ( lspackova@redhat.com ) Release of the Red Hat Enterprise Linux 8.3 Package manifest. 0.0-4 Tue Apr 28 2020, Lenka Spackova ( lspackova@redhat.com ) Release of the Red Hat Enterprise Linux 8.2 Package manifest. 0.0-3 Tue Nov 05 2019, Lenka Spackova ( lspackova@redhat.com ) Release of the Red Hat Enterprise Linux 8.1 Package manifest. 0.0-2 Tue Sep 24 2019, Lenka Spackova ( lspackova@redhat.com ) Minor formal improvements. 0.0-1 Tue May 07 2019, Lenka Spackova ( lspackova@redhat.com ) Release of the Red Hat Enterprise Linux 8.0 Package manifest.

Commands:
Chapter 3. About the History Database 3.1. History Database Overview Red Hat Virtualization includes a comprehensive management history database, which can be used by reporting applications to generate reports at data center, cluster and host levels. This chapter provides information to enable you to set up queries against the history database. Red Hat Virtualization Manager uses PostgreSQL 12.x as a database platform to store information about the state of the virtualization environment, its configuration and performance. At install time, Red Hat Virtualization Manager creates a PostgreSQL database called engine . Installing the ovirt-engine-dwh package creates a second database called ovirt_engine_history , which contains historical configuration information and statistical metrics collected every minute over time from the engine operational database. Tracking the changes to the database provides information on the objects in the database, enabling the user to analyze activity, enhance performance, and resolve difficulties. Warning The replication of data in the ovirt_engine_history database is performed by the Red Hat Virtualization Manager Extract Transform Load Service, ovirt-engine-dwhd . The service is based on Talend Open Studio, a data integration tool. This service is configured to start automatically during the data warehouse package setup. It is a Java program responsible for extracting data from the engine database, transforming the data to the history database standard and loading it to the ovirt_engine_history database. The ovirt-engine-dwhd service must not be stopped. The ovirt_engine_history database schema changes over time. The database includes a set of database views to provide a supported, versioned API with a consistent structure. A view is a virtual table composed of the result set of a database query. The database stores the definition of a view as a SELECT statement. The result of the SELECT statement populates the virtual table that the view returns. A user references the view name in PL/PGSQL statements the same way a table is referenced.

Commands:
2.6.4. xinetd Configuration Files The configuration files for xinetd are as follows: /etc/xinetd.conf - The global xinetd configuration file. /etc/xinetd.d/ - The directory containing all service-specific files. 2.6.4.1. The /etc/xinetd.conf File The /etc/xinetd.conf file contains general configuration settings which affect every service under xinetd 's control. It is read when the xinetd service is first started, so for configuration changes to take effect, you need to restart the xinetd service. The following is a sample /etc/xinetd.conf file: These lines control the following aspects of xinetd : instances - Specifies the maximum number of simultaneous requests that xinetd can process. log_type - Configures xinetd to use the authpriv log facility, which writes log entries to the /var/log/secure file. Adding a directive such as FILE /var/log/xinetdlog would create a custom log file called xinetdlog in the /var/log/ directory. log_on_success - Configures xinetd to log successful connection attempts. By default, the remote host's IP address and the process ID of the server processing the request are recorded. log_on_failure - Configures xinetd to log failed connection attempts or if the connection was denied. cps - Configures xinetd to allow no more than 25 connections per second to any given service. If this limit is exceeded, the service is retired for 30 seconds. includedir /etc/xinetd.d/ - Includes options declared in the service-specific configuration files located in the /etc/xinetd.d/ directory. Refer to Section 2.6.4.2, "The /etc/xinetd.d/ Directory" for more information. Note Often, both the log_on_success and log_on_failure settings in /etc/xinetd.conf are further modified in the service-specific configuration files. More information may therefore appear in a given service's log file than the /etc/xinetd.conf file may indicate. Refer to Section 2.6.4.3.1, "Logging Options" for further information.

Commands:
defaults { instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST cps = 25 30 } includedir /etc/xinetd.d
probe::signal.send Name probe::signal.send - Signal being sent to a process Synopsis signal.send Values send2queue Indicates whether the signal is sent to an existing sigqueue (deprecated in SystemTap 2.1) pid_name The name of the signal recipient task A task handle to the signal recipient sig_name A string representation of the signal sinfo The address of siginfo struct shared Indicates whether the signal is shared by the thread group si_code Indicates the signal type name The name of the function used to send out the signal sig The number of the signal sig_pid The PID of the process receiving the signal Context The signal's sender.

Commands:
Chapter 4. Creating a custom Puppet environment You can create a Puppet environment within your Satellite. Procedure In the Satellite web UI, navigate to Configure > Puppet Environments . Click Create Puppet Environment to create a Puppet environment. Enter a Name , alphanumeric characters and underscores are allowed, such as example_environment . Optional: Set a location context. Optional: Set an organization context. Click Submit to create the Puppet environment. Note that before you run an import of Puppet modules into Satellite, the environment must already exist as the folder /etc/puppetlabs/code/environments/ example_environment on the Puppet server and contain installed Puppet modules.

Commands:
26.4. VNC and X11 Parameters The following parameters can be defined in a parameter file but do not work in a CMS configuration file. With these parameters you control what interface will be used for anaconda . To use an X11 user interface without X11 forwarding, specify the following X11 parameter: display= IP / hostname : display Sets the hostname or IP address and the X11 display where the installer should connect to and display its graphical user interface. To use a VNC server instead of an X11 user interface, specify the following VNC parameters: vnc Specify vnc to use the VNC graphical user interface later in the installation process. vncpassword= This parameter sets the password used to connect to the VNC server. The password parameter is optional. If not used, the VNC server does not use a password and anybody can connect to the VNC server. vncconnect= IP / hostname [: port ] When used in addition to vnc and vncpassword= , this optional parameter specifies the hostname or IP address (and optionally, a TCP port) where a VNC client is running in listening mode. The installer connects to and displays its graphical user interface on this VNC client.

Commands:
Preface When Red Hat Trusted Application Pipeline builds your application images, it also provides a software bill of materials (SBOM). The SBOM lists all the software libraries that the image uses. You can use the SBOM to identify security vulnerabilities. However, the SBOM is long and difficult to read. To turn the raw SBOM into actionable information, you can use Trusted Profile Analyzer (TPA). For example, TPA can identify dependencies in your image that are targets of known Common Vulnerabilities and Exploits (CVEs).

Commands:
4.2. Default Policy The default configuration now allows members of the wheel group to authenticate for administrative actions using their own password instead of asking for the root password. The default policy is defined in /etc/polkit-1/rules.d/50-default.rules . In the users panel of GNOME Settings, you can configure an account to an Administrator . When you first create the user during the GNOME Initial Setup , by default, you will create an Administrator account (a member of the wheel group). Note While sudo users are allowed to run programs with the security privileges of another user, Administrator is a member of the wheel group providing additional special system privileges that empower a user to execute restricted commands.

Commands:
Chapter 5. Reviewing OpenStack Networking router ports Virtual routers in OpenStack Networking use ports to interconnect with subnets. You can review the state of these ports to determine whether they connect as expected. 5.1. Viewing current port status Complete the following steps to lists all of the ports that attach to a particular router and to retrieve the current state of a port (DOWN or ACTIVE): To view all the ports that attach to the router named r1 , run the following command: Example result: To view the details of each port, run the following command. Include the port ID of the port that you want to view. The result includes the port status, indicated in the following example as having an ACTIVE state: Example result: Perform step 2 for each port to retrieve its status.

Commands:
neutron router-port-list r1
+--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+ | id | name | mac_address | fixed_ips | +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+ | b58d26f0-cc03-43c1-ab23-ccdb1018252a | | fa:16:3e:94:a7:df | {"subnet_id": "a592fdba-babd-48e0-96e8-2dd9117614d3", "ip_address": "192.168.200.1"} | | c45e998d-98a1-4b23-bb41-5d24797a12a4 | | fa:16:3e:ee:6a:f7 | {"subnet_id": "43f8f625-c773-4f18-a691-fd4ebfb3be54", "ip_address": "172.24.4.225"} | +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
openstack port show b58d26f0-cc03-43c1-ab23-ccdb1018252a
+-----------------------+--------------------------------------------------------------------------------------+ | Field | Value | +-----------------------+--------------------------------------------------------------------------------------+ | admin_state_up | True | | allowed_address_pairs | | | binding:host_id | node.example.com | | binding:profile | {} | | binding:vif_details | {"port_filter": true, "ovs_hybrid_plug": true} | | binding:vif_type | ovs | | binding:vnic_type | normal | | device_id | 49c6ebdc-0e62-49ad-a9ca-58cea464472f | | device_owner | network:router_interface | | extra_dhcp_opts | | | fixed_ips | {"subnet_id": "a592fdba-babd-48e0-96e8-2dd9117614d3", "ip_address": "192.168.200.1"} | | id | b58d26f0-cc03-43c1-ab23-ccdb1018252a | | mac_address | fa:16:3e:94:a7:df | | name | | | network_id | 63c24160-47ac-4140-903d-8f9a670b0ca4 | | security_groups | | | status | ACTIVE | | tenant_id | d588d1112e0f496fb6cac22f9be45d49 | +-----------------------+--------------------------------------------------------------------------------------+
14.5. DHCP for IPv6 (DHCPv6) The ISC DHCP includes support for IPv6 ( DHCPv6 ) since the 4.x release with a DHCPv6 server, client, and relay agent functionality. The agents support both IPv4 and IPv6 , however the agents can only manage one protocol at a time; for dual support they must be started separately for IPv4 and IPv6 . For example, configure both DHCPv4 and DHCPv6 by editing their respective configuration files /etc/dhcp/dhcpd.conf and /etc/dhcp/dhcpd6.conf and then issue the following commands: The DHCPv6 server configuration file can be found at /etc/dhcp/dhcpd6.conf . The example server configuration file can be found at /usr/share/doc/dhcp- version /dhcpd6.conf.example . A simple DHCPv6 server configuration file can look like this: To assign a fixed-address to a client, based on the MAC address of the network interface card, use the hardware ethernet parameter: The configuration options in the shared-network , and group declaration for IPv6 are the same as IPV4. For more details, see the examples as demonstrated in Example 14.5, "Shared-network Declaration" , and Example 14.6, "Group Declaration" .

Commands:
~]# systemctl start dhcpd ~]# systemctl start dhcpd6
subnet6 2001:db8:0:1::/64 { range6 2001:db8:0:1::129 2001:db8:0:1::254; option dhcp6.name-servers fec0:0:0:1::1; option dhcp6.domain-search "domain.example"; }
host otherclient { hardware ethernet 01:00:80:a2:55:67; fixed-address6 3ffe:501:ffff:100::4321; }
Chapter 131. KafkaConnectorSpec schema reference Used in: KafkaConnector Property Description class The Class for the Kafka Connector. string tasksMax The maximum number of tasks for the Kafka Connector. integer autoRestart Automatic restart of connector and tasks configuration. AutoRestart config The Kafka Connector configuration. The following properties cannot be set: connector.class, tasks.max. map pause Whether the connector should be paused. Defaults to false. boolean

Commands:
7.3. Comparison with Virtual Machines Virtual machines represent an entire server with all of the associated software and maintenance concerns. Docker containers provide application isolation and can be configured with minimum run-time environments. In a Docker container, the kernel and parts of the operating system infrastructure are shared. For the virtual machine, a full operating system must be included. You can create or destroy containers quickly and easily. Virtual Machines require full installations and require more computing resources to execute. Containers are lightweight, therefore, more containers than virtual machines can run simultaneously on a host machine. Containers share resources efficiently. Virtual machines are isolated. Therefore multiple variations of an application running in containers are also able to be very lightweight. For example, shared binaries are not duplicated on the system. Virtual machines can be migrated while still executing, however containers cannot be migrated while executing and must be stopped before moving from host machine to host machine. Containers do not replace virtual machines for all use cases. Careful evaluation is still required to determine what is best for your application. To quickly get up-and-running with Docker Containers, refer to Get Started with Docker Containers . The Docker FAQ contains more information about Linux Containers, Docker, subscriptions and support.

Commands:
Chapter 5. Deprecated functionality This section provides an overview of functionality that has been deprecated in all minor releases up to this release of Red Hat Ceph Storage. Ubuntu is no longer supported Installing a Red Hat Ceph Storage 4 cluster on Ubuntu is no longer supported. Use Red Hat Enterprise Linux as the underlying operating system. Configuring iSCSI gateway using ceph-ansible is no longer supported Configuring the Ceph iSCSI gateway by using the ceph-ansible utility is no longer supported. Use ceph-ansible to install the gateway and then use the gwcli utility of the to configure the Ceph iSCSI gateway. For details, see the The Ceph iSCSI Gateway chapter in the Red Hat Ceph Storage Block Device Guide . ceph-disk is deprecated With this release, the ceph-disk utility is no longer supported. The ceph-volume utility is used instead. For details, see the Why does ceph-volume replace `ceph-disk` section in the Administration Guide for Red Hat Ceph Storage 4. FileStore is no longer supported in production The FileStore OSD back end is now deprecated because the new BlueStore back end is now fully supported in production. For details, see the How to migrate the object store from FileStore to BlueStore section in the Red Hat Ceph Storage Installation Guide . Ceph configuration file is now deprecated The Ceph configuration file ( ceph.conf ) is now deprecated in favor of new centralized configuration stored in Ceph Monitors. For details, see the The Ceph configuration database section in the Red Hat Ceph Storage Configuration Guide . 5.1. The Ceph Volume utility Deploying an OSD on a device setup for dm-cache is unsupported Deploying an OSD with dm-cache is no longer supported. Use the Bluestore backend instead of dm-cache . For more information, see the How to migrate the object store from FileStore to BlueStore section in the Red Hat Ceph Storage Installation Guide .

Commands:
32.3. Standard Users Table 32.4, "Standard Users" lists the standard users configured in the /etc/passwd file by an Everything installation. The groupid (GID) in this table is the primary group for the user. See Section 32.4, "Standard Groups" for a listing of standard groups. Table 32.4. Standard Users User UID GID Home Directory Shell root 0 0 /root /bin/bash bin 1 1 /bin /sbin/nologin daemon 2 2 /sbin /sbin/nologin adm 3 4 /var/adm /sbin/nologin lp 4 7 /var/spool/lpd /sbin/nologin sync 5 0 /sbin /bin/sync shutdown 6 0 /sbin /sbin/shutdown halt 7 0 /sbin /sbin/halt mail 8 12 /var/spool/mail /sbin/nologin news 9 13 /etc/news uucp 10 14 /var/spool/uucp /sbin/nologin operator 11 0 /root /sbin/nologin games 12 100 /usr/games /sbin/nologin gopher 13 30 /var/gopher /sbin/nologin ftp 14 50 /var/ftp /sbin/nologin nobody 99 99 / /sbin/nologin rpm 37 37 /var/lib/rpm /sbin/nologin vcsa 69 69 /dev /sbin/nologin dbus 81 81 / /sbin/nologin ntp 38 38 /etc/ntp /sbin/nologin canna 39 39 /var/lib/canna /sbin/nologin nscd 28 28 / /sbin/nologin rpc 32 32 / /sbin/nologin postfix 89 89 /var/spool/postfix /sbin/nologin mailman 41 41 /var/mailman /sbin/nologin named 25 25 /var/named /bin/false amanda 33 6 var/lib/amanda/ /bin/bash postgres 26 26 /var/lib/pgsql /bin/bash exim 93 93 /var/spool/exim /sbin/nologin sshd 74 74 /var/empty/sshd /sbin/nologin rpcuser 29 29 /var/lib/nfs /sbin/nologin nsfnobody 65534 65534 /var/lib/nfs /sbin/nologin pvm 24 24 /usr/share/pvm3 /bin/bash apache 48 48 /var/www /sbin/nologin xfs 43 43 /etc/X11/fs /sbin/nologin gdm 42 42 /var/gdm /sbin/nologin htt 100 101 /usr/lib/im /sbin/nologin mysql 27 27 /var/lib/mysql /bin/bash webalizer 67 67 /var/www/usage /sbin/nologin mailnull 47 47 /var/spool/mqueue /sbin/nologin smmsp 51 51 /var/spool/mqueue /sbin/nologin squid 23 23 /var/spool/squid /sbin/nologin ldap 55 55 /var/lib/ldap /bin/false netdump 34 34 /var/crash /bin/bash pcap 77 77 /var/arpwatch /sbin/nologin radiusd 95 95 / /bin/false radvd 75 75 / /sbin/nologin quagga 92 92 /var/run/quagga /sbin/login wnn 49 49 /var/lib/wnn /sbin/nologin dovecot 97 97 /usr/libexec/dovecot /sbin/nologin

Commands:
7.3. alsa-utils 7.3.1. RHBA-2013:0318 - alsa-utils bug fix and enhancement update Updated alsa-utils packages that fix numerous bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The alsa-utils package contains command line utilities for the Advanced Linux Sound Architecture (ALSA). Note The alsa-utils package has been upgraded to upstream version 1.0.22, which provides a number of bug fixes and enhancements over the version. (BZ#838951) Enhancement BZ# 814832 The alsa-utils package has been enhanced to work better with the GNOME volume control applet and sound preferences user interface. Users of alsa-utils are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands: