mtpti5iD/redhat-docs_dataset huggingface dataset:
17.3. Methods 17.3.1. Creating a New Template Creation of a new template requires the name and vm elements. Identify the vm with the id attribute or name element. Example 17.2. Creating a template from a virtual machine 17.3.2. Creating a New Template Sub Version Creation of a new template sub version requires the name and vm elements for the new template, and the base_template and version_name elements for the new template version. The base_template and version_name elements must be specified within a version section enclosed in the template section. Identify the vm with the id attribute or name element. Example 17.3. Creating a template sub version from a virtual machine 17.3.3. Updating a Template The name , description , type , memory , cpu topology , os , high_availability , display , stateless , usb and timezone elements can be updated after a template has been created. Example 17.4. Updating a virtual machine template to contain 1 GB of memory 17.3.4. Updating a Template Sub Version Only the version_name element can be updated after a template sub version has been created. Example 17.5. Updating a virtual machine template sub version name 17.3.5. Removing a Template Removal of a virtual machine template requires a DELETE request. Example 17.6. Removing a virtual machine template

Commands:
POST /ovirt-engine/api/templates HTTP/1.1 Accept: application/xml Content-type: application/xml <template> <name>template1</name> <vm id="00000000-0000-0000-0000-000000000000"/> </template>
POST /ovirt-engine/api/templates HTTP/1.1 Accept: application/xml Content-type: application/xml <template> <name>template1_001</name> <vm id="00000000-0000-0000-0000-000000000000"/> <version> <base_template id="00000000-0000-0000-0000-000000000000"/> <version_name>"template1_001"</version_name> </version> </template>
PUT /ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000 HTTP/1.1 Accept: application/xml Content-type: application/xml <template> <memory>1073741824</memory> </template>
PUT /ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000 HTTP/1.1 Accept: application/xml Content-type: application/xml <template> <version> <version_name>template1_002</version_name> </version> </template>
DELETE /ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000 HTTP/1.1 HTTP/1.1 204 No Content
1.5. Materialization Table A Materialization Table is a cached view of a virtual table. When a query is issued against this virtual table, the contents can be served from memory space or redirected to a another table so results can be fetched from the original sources. Internal materialization creates temporary tables to hold the materialized table. While these tables are not fully durable, they perform well in most circumstances and the data is present in each Red Hat JBoss Data Virtualiation instance, removing the risk of a single point of failure and the network overhead of an external database. External materialized views cache their data in a matgerialization table in an external database system.

Commands:
Chapter 2. Logging in to the Argo CD server in the default mode Important The Red Hat OpenShift GitOps argocd CLI tool is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . You can log in to the Argo CD server in the default mode using the GitOps argocd CLI and your Argo CD credentials to execute commands. 2.1. Logging in to the Argo CD server After you install and configure the GitOps argocd CLI, you must log in to the Argo CD server to execute commands in the default mode. Prerequisites You must have the GitOps argocd CLI tool installed and configured. Procedure You must use your credentials to log in and remain logged in throughout the session. Important Get the admin account password for the Argo CD server: USD ADMIN_PASSWD=USD(oc get secret openshift-gitops-cluster -n openshift-gitops -o jsonpath='{.data.admin\.password}' | base64 -d) Get the Argo CD server URL: USD SERVER_URL=USD(oc get routes openshift-gitops-server -n openshift-gitops -o jsonpath='{.status.ingress[0].host}') Log in to the Argo CD server by using the admin account password and enclosing it in single quotes: Important Enclosing the password in single quotes ensures that special characters, such as USD , are not misinterpreted by the shell. Always use single quotes to enclose the literal value of the password. USD argocd login --username admin --password USD{ADMIN_PASSWD} USD{SERVER_URL} Example USD argocd login --username admin --password '<password>' openshift-gitops.openshift-gitops.apps-crc.testing After a successful login, the session context will be displayed as follows: Example output 'admin:login' logged in successfully Context '<server_url>' updated 2.2. Additional resources Installing the GitOps CLI Configuring the GitOps CLI Basic GitOps argocd commands

Commands:
If the login session times out, you can use the `relogin` command to log in again. When done using the `argocd` commands, you can log out using the `logout` command.
ADMIN_PASSWD=USD(oc get secret openshift-gitops-cluster -n openshift-gitops -o jsonpath='{.data.admin\.password}' | base64 -d)
SERVER_URL=USD(oc get routes openshift-gitops-server -n openshift-gitops -o jsonpath='{.status.ingress[0].host}')
argocd login --username admin --password USD{ADMIN_PASSWD} USD{SERVER_URL}
argocd login --username admin --password '<password>' openshift-gitops.openshift-gitops.apps-crc.testing
'admin:login' logged in successfully Context '<server_url>' updated
21.3.6. Adding an LPD/LPR Host or Printer Follow this procedure to add an LPD/LPR host or printer: Open the New Printer dialog (see Section 21.3.2, "Starting Printer Setup" ). In the list of devices on the left, select Network Printer LPD/LPR Host or Printer . On the right, enter the connection settings: Host The host name of the LPD/LPR printer or host. Optionally, click Probe to find queues on the LPD host. Queue The queue name to be given to the new queue (if the box is left empty, a name based on the device node will be used). Figure 21.7. Adding an LPD/LPR printer Click Forward to continue. Select the printer model. See Section 21.3.8, "Selecting the Printer Model and Finishing" for details.

Commands:
7.249. system-config-users 7.249.1. RHBA-2012:1387 - system-config-users bug fix update Updated system-config-users packages that fix three bugs are now available for Red Hat Enterprise Linux 6. The system-config-users packages provide a graphical utility for administrating users and groups. Bug Fixes BZ# 736037 Prior to this update, expiration dates at or before January 1, 1970 were not correctly calculated. As a consequence, the system-config-users utility stored expiration dates off by one day into /etc/shadow. This update modifies the underlying code so that account expiration dates are calculated and stored correctly. BZ#801652 Prior to this update, a string in the user interface was not correctly localized into Japanese. This update modifies the string so that the text is now correct. BZ#841886 Prior to this update, the system-config-users utility determined incorrectly whether to set an account as inactive if an expired password was not reset during a specified period. This update modifies the underlying code to check for this condition by hard-coding the value which indicates this condition. All users of system-config-users are advised to upgrade to these updated packages, which fix these bugs.

Commands:
C.3.3. Creating and Saving Backup Passphrases If you use a kickstart file during installation, anaconda can add a randomly generated backup passphrase to each block device on the system and save each passphrase to an encrypted file on the local file system. Specify the URL of this certificate with the --escrowcert parameter as described in Section C.3.2, "Saving Passphrases" , followed by the --backuppassphrase parameter for each of the kickstart commands that relate to the devices for which you want to create backup passphrases. Note that this feature is available only while performing a kickstart installation. Refer to Chapter 32, Kickstart Installations for more detail.

Commands:
Chapter 14. Shared File Service (manila) Parameters Parameter Description CephClusterName The Ceph cluster name. The default value is ceph . ManilaCephClientUserName Ceph client username for manila integration. The default value is manila . ManilaCephFSCephFSProtocolHelperType Protocol type ( CEPHFS or NFS ) when cephfs back end is enabled. Set via manila cephfs environment files. The default value is CEPHFS . ManilaIPv6 Set to True to enable IPv6 access in manila. The default value is False . ManilaPassword The password for the shared file service account. ManilaWorkers Set the number of workers for manila::wsgi::apache. The default value is equal to the number of vCPU cores on the physical node. NotificationDriver Driver or drivers to handle sending notifications. The default value is messagingv2 .

Commands:
Chapter 8. Backing OpenShift Container Platform applications with OpenShift Data Foundation You cannot directly install OpenShift Data Foundation during the OpenShift Container Platform installation. However, you can install OpenShift Data Foundation on an existing OpenShift Container Platform by using the Operator Hub and then configure the OpenShift Container Platform applications to be backed by OpenShift Data Foundation. Prerequisites OpenShift Container Platform is installed and you have administrative access to OpenShift Web Console. OpenShift Data Foundation is installed and running in the openshift-storage namespace. Procedure In the OpenShift Web Console, perform one of the following: Click Workloads Deployments . In the Deployments page, you can do one of the following: Select any existing deployment and click Add Storage option from the Action menu (...). Create a new deployment and then add storage. Click Create Deployment to create a new deployment. Edit the YAML based on your requirement to create a deployment. Click Create . Select Add Storage from the Actions drop-down menu on the top right of the page. Click Workloads Deployment Configs . In the Deployment Configs page, you can do one of the following: Select any existing deployment and click Add Storage option from the Action menu (...). Create a new deployment and then add storage. Click Create Deployment Config to create a new deployment. Edit the YAML based on your requirement to create a deployment. Click Create . Select Add Storage from the Actions drop-down menu on the top right of the page. In the Add Storage page, you can choose one of the following options: Click the Use existing claim option and select a suitable PVC from the drop-down list. Click the Create new claim option. Select the appropriate CephFS or RBD storage class from the Storage Class drop-down list. Provide a name for the Persistent Volume Claim. Select ReadWriteOnce (RWO) or ReadWriteMany (RWX) access mode. Note ReadOnlyMany (ROX) is deactivated as it is not supported. Select the size of the desired storage capacity. Note You can expand the block PVs but cannot reduce the storage capacity after the creation of Persistent Volume Claim. Specify the mount path and subpath (if required) for the mount path volume inside the container. Click Save . Verification steps Depending on your configuration, perform one of the following: Click Workloads Deployments . Click Workloads Deployment Configs . Set the Project as required. Click the deployment for which you added storage to display the deployment details. Scroll down to Volumes and verify that your deployment has a Type that matches the Persistent Volume Claim that you assigned. Click the Persistent Volume Claim name and verify the storage class name in the Persistent Volume Claim Overview page.

Commands:
5.4.8. Merging Snapshot Volumes As of the Red Hat Enterprise Linux 6 release, you can use the --merge option of the lvconvert command to merge a snapshot into its origin volume. If both the origin and snapshot volume are not open, the merge will start immediately. Otherwise, the merge will start the first time either the origin or snapshot are activated and both are closed. Merging a snapshot into an origin that cannot be closed, for example a root file system, is deferred until the time the origin volume is activated. When merging starts, the resulting logical volume will have the origin's name, minor number and UUID. While the merge is in progress, reads or writes to the origin appear as they were directed to the snapshot being merged. When the merge finishes, the merged snapshot is removed. The following command merges snapshot volume vg00/lvol1_snap into its origin. You can specify multiple snapshots on the command line, or you can use LVM object tags to specify that multiple snapshots be merged to their respective origins. In the following example, logical volumes vg00/lvol1 , vg00/lvol2 , and vg00/lvol3 are all tagged with the tag @some_tag . The following command merges the snapshot logical volumes for all three volumes serially: vg00/lvol1 , then vg00/lvol2 , then vg00/lvol3 . If the --background option were used, all snapshot logical volume merges would start in parallel. For information on tagging LVM objects, see Appendix D, LVM Object Tags . For further information on the lvconvert --merge command, see the lvconvert (8) man page.

Commands:
lvconvert --merge vg00/lvol1_snap
lvconvert --merge @some_tag
8.8. Language Support To install support for additional locales and language dialects, select Language Support from the Installation Summary screen. Use your mouse to select the language for which you would like to install support. In the left panel, select your language of choice, for example Espanol . Then you can select a locale specific to your region in the right panel, for example Espanol (Costa Rica) . You can select multiple languages and multiple locales. The selected languages are highlighted in bold in the left panel. Figure 8.6. Configuring Language Support Once you have made your selections, click Done to return to the Installation Summary screen. Note To change your language support configuration after you have completed the installation, visit the Region & Language section of the Settings dialog window.

Commands:
Chapter 3. Installing an IdM Server The IdM domain is defined and managed by an IdM server which is essentially a domain controller. There can be multiple domain controllers within a domain for load-balancing and failover tolerance. These additional servers are called replicas of the master IdM server. Both IdM servers and replicas only run on Red Hat Enterprise Linux systems. For both servers and replicas, the necessary packages must be installed and then the IdM server or replica itself is configured through setup scripts, which configure all of the requisite services. 3.1. Installing the IdM Server Packages Installing only the IdM server requires a single package, ipa-server . If the IdM server will also manage a DNS server, then it requires two additional packages to set up the DNS. All of these packages can be installed using the yum command: [root@server ~]# yum install ipa-server bind bind-dyndb-ldap Installing the ipa-server also installs a large number of dependencies, such as 389-ds-base for the LDAP service and krb5-server for the Kerberos service, along with IdM tools. After the packages are installed, the server instance must be created using the ipa-server-install command. The options for configuring the new server instance are described in Section 3.2, "About ipa-server-install" .

Commands:
yum install ipa-server bind bind-dyndb-ldap
7.2. Creating a Red Hat Enterprise Linux 6 Guest with a Network Installation Tree Procedure 7.2. Creating a Red Hat Enterprise Linux 6 guest with virt-manager Optional: Preparation Prepare the storage environment for the guest virtual machine. For more information on preparing storage, refer to the Red Hat Enterprise Linux 6 Virtualization Administration Guide . Important Various storage types may be used for storing guest virtual machines. However, for a virtual machine to be able to use migration features the virtual machine must be created on networked storage. Red Hat Enterprise Linux 6 requires at least 1GB of storage space. However, Red Hat recommends at least 5GB of storage space for a Red Hat Enterprise Linux 6 installation and for the procedures in this guide. Open virt-manager and start the wizard Open virt-manager by executing the virt-manager command as root or opening Applications System Tools Virtual Machine Manager . Figure 7.11. The main virt-manager window Click on the Create a new virtual machine button to start the new virtual machine wizard. Figure 7.12. The Create a new virtual machine button The Create a new virtual machine window opens. Name the virtual machine Virtual machine names can contain letters, numbers and the following characters: ' _ ', ' . ' and ' - '. Virtual machine names must be unique for migration and cannot consist only of numbers. Choose the installation method from the list of radio buttons. Figure 7.13. The New VM window - Step 1 Click Forward to continue. Provide the installation URL, and the Kickstart URL and Kernel options if required. Figure 7.14. The New VM window - Step 2 Click Forward to continue. The remaining steps are the same as the ISO installation procedure. Continue from Step 5 of the ISO installation procedure.

Commands:
1.4. Differences between GFS and GFS2 This section lists the improvements and changes that GFS2 offers over GFS. Migrating from GFS to GFS2 requires that you convert your GFS file systems to GFS2 with the gfs2_convert utility. For information on the gfs2_convert utility, see Appendix B, Converting a File System from GFS to GFS2 . 1.4.1. GFS2 Command Names In general, the functionality of GFS2 is identical to GFS. The names of the file system commands, however, specify GFS2 instead of GFS. Table 1.1, "GFS and GFS2 Commands" shows the equivalent GFS and GFS2 commands and functionality. Table 1.1. GFS and GFS2 Commands GFS Command GFS2 Command Description mount mount Mount a file system. The system can determine whether the file system is a GFS or GFS2 file system type. For information on the GFS2 mount options see the gfs2_mount(8) man page. umount umount Unmount a file system. fsck gfs_fsck fsck fsck.gfs2 Check and repair an unmounted file system. gfs_grow gfs2_grow Grow a mounted file system. gfs_jadd gfs2_jadd Add a journal to a mounted file system. gfs_mkfs mkfs -t gfs mkfs.gfs2 mkfs -t gfs2 Create a file system on a storage device. gfs_quota gfs2_quota Manage quotas on a mounted file system. As of the Red Hat Enterprise Linux 6.1 release, GFS2 supports the standard Linux quota facilities. For further information on quota management in GFS2, see Section 4.5, "GFS2 Quota Management" . gfs_tool tunegfs2 mount parameters dmsetup suspend Configure, tune, or gather information about a file system. The tunegfs2 command is supported as of the Red Hat Enterprise Linux 6.2 release. There is also a gfs2_tool command. gfs_edit gfs2_edit Display, print, or edit file system internal structures. The gfs2_edit command can be used for GFS file systems as well as GFS2 file system. gfs_tool setflag jdata/inherit_jdata chattr +j (preferred) Enable journaling on a file or directory. setfacl/getfacl setfacl/getfacl Set or get file access control list for a file or directory. setfattr/getfattr setfattr/getfattr Set or get the extended attributes of a file. For a full listing of the supported options for the GFS2 file system commands, see the man pages for those commands.

Commands:
Chapter 4. Sizing requirements for Red Hat Developer Hub Scaling the Red Hat Developer Hub requires significant resource allocation. The following table lists the sizing requirements for installing and running Red Hat Developer Hub, including Developer Hub application, database components, and Operator. Table 4.1. Recommended sizing for running Red Hat Developer Hub Components Red Hat Developer Hub application Red Hat Developer Hub database Red Hat Developer Hub Operator Central Processing Unit (CPU) 4 vCPU 2 vCPU 1 vCPU Memory 16 GB 8 GB 1500 Mi Storage size 2 GB 20 GB 50 Mi Replicas 2 or more 3 or more 1 or more

Commands:
Chapter 44. Using the standalone editor perspective You can use the standalone editor perspective of Business Central to access an asset's specific editor. By using this perspective, you can open an asset's editor and can modify the asset as required. The web address for accessing an asset's standalone editor perspective contains the standalone and path parameters. The path parameter must contain the complete path to the asset and the web address can end with #StandaloneEditorPerspective string. Also, by varying the path parameter, you can access a specific asset's editor in the standalone mode. Procedure Log in to Business Central. In a web browser, enter the appropriate web address as required, for example, For editing a process: http://localhost:8080/business-central/kie-wb.jsp?standalone&path=default://master@MySpace/Shop/src/main/resources/com/purchase.bpmn#StandaloneEditorPerspective The Process Designer opens in the standalone mode. For editing a form: http://localhost:8080/business-central/kie-wb.jsp?standalone&path=default://master@MySpace/Mortgage_Process/src/main/resources/ApplicationMortgage.frm#StandaloneEditorPerspective The Form Modeler opens in the standalone mode.

Commands:
Chapter 13. DHCP DHCPD is the daemon used in Red Hat Enterprise Linux to dynamically deliver and configure Layer 3 TCP/IP details for clients. The dhcp package provides the DHCP server, dhcpd . Run the rpm -q dhcp command to see if the dhcp package is installed. If it is not installed, run the following command as the root user to install it: 13.1. DHCP and SELinux When DHCPD is enabled, it runs confined by default. Confined processes run in their own domains, and are separated from other confined processes. If a confined process is compromised by an attacker, depending on SELinux policy configuration, an attacker's access to resources and the possible damage they can do is limited. The following example demonstrates the DHCPD and related processes running in their own domain. This example assumes the dhcp package is installed and that the DHCPD service has been started: Run the getenforce command to confirm SELinux is running in enforcing mode: The getenforce command returns Enforcing when SELinux is running in enforcing mode. Run the service dhcpd start command as the root user to start DHCPD : Run the ps -eZ | grep dhcpd command to view the dhcpd processes: The SELinux context associated with the dhcpd process is unconfined_u:system_r:dhcpd_t:s0 .

Commands:
~]# yum install dhcp
~]USD getenforce Enforcing
~]# service dhcpd start Starting dhcpd: [ OK ]
~]USD ps -eZ | grep dhcpd unconfined_u:system_r:dhcpd_t:s0 5483 ? 00:00:00 dhcpd
Chapter 22. rsync The rsync utility performs fast file transfer and it is used for synchronizing data between systems. [20] When using Red Hat Enterprise Linux, the rsync package provides rsync. Enter the following command to see if the rsync package is installed: If it is not installed, use the yum utility as root to install it: 22.1. rsync and SELinux SELinux requires files to have an extended attribute to define the file type. Policy governs the access daemons have to these files. If you want to share files using the rsync daemon, you must label the files and directories with the public_content_t type. Like most services, correct labeling is required for SELinux to perform its protection mechanisms over rsync . [21] [20] See the Rsync project page for more information. [21] See the rsync_selinux (8) manual page for more information about rsync and SELinux.

Commands:
~]USD rpm -q rsync package rsync is not installed
~]# yum install rsync