mtpti5iD/redhat-docs_dataset huggingface dataset:
8.233. system-config-firewall 8.233.1. RHBA-2014:0837 - system-config-firewall bug fix update Updated system-config-firewall packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The system-config-firewall packages contain a graphical user interface for basic firewall setup. Bug Fixes BZ# 634857 Previously, the default iptables rules for IPv6 did not allow the DHCPv6 configuration. Consequently, the DHCPv6 responses were blocked. With this update, the rules enabling DHCPv6 have been added, so that network environments using DHCPv6 are now supported as expected. BZ# 682391 Recently, some arbitrary names for network devices have been changed. As a consequence, it was impossible to find such devices by name. This update provides a patch that reflects the name change, so that it is now easy to find the renamed devices. BZ# 711231 Under certain circumstances, an attempt to execute the system-config-firewall utility failed with the following error: "shutil.py:50:copyfile:IOError: [Errno 13] Permission denied: '/etc/sysconfig/iptables-config'" The underlying source code has been modified to fix this bug and system-config-firewall now works as expected in the described scenario. BZ# 720831 Previously, the "eth+" GUI option could not be expanded to show individual network interfaces. Consequently, the user was unable to specify a rule for a particular interface. With this update, the particular entries have been added to the list of interfaces, thus allowing to specify a rule for a single interface. BZ# 756048 Due to a missing dependency, an attempt to run the system-config-firewall-tui utility on a system with a minimal installation of Red Hat Enterprise Linux 6 failed. The missing dependency has been added to the system-config-firewall-tui dependency list and the utility now works correctly. BZ# 819809 Previously, the localization of the system-config-firewall utility was not complete. This update completes translations for all languages supported by Red Hat. Users of system-config-firewall are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Appendix B. Maven Configuration Information B.1. Install the JBoss Enterprise Application Platform Repository Using Nexus This example outlines the steps to install the JBoss Enterprise Application Platform 6 Maven Repository using Sonatype Nexus Maven Repository Manager. For further instructions, see http://www.sonatype.org/nexus/ . Procedure B.1. Download the JBoss Enterprise Application Platform 6 Maven Repository ZIP archive Open a web browser and access the following URL: https://access.redhat.com/jbossnetwork/restricted/listSoftware.html?product=appplatform . Find Application Platform 6 Maven Repository in the list. Click Download to download a ZIP file that contains the repository. Unzip the files into the desired target directory. Procedure B.2. Add the JBoss Enterprise Application Platform 6 Maven Repository using Nexus Maven Repository Manager Log into Nexus as an Administrator. Select the Repositories section from the Views Repositories menu to the left of your repository manager. Click the Add... drop-down menu, then select Hosted Repository . Provide a name and ID for the new repository. Enter the unzipped repository path in the Override Local Storage Location field. Continue if the artifact must be available in a repository group. If not, do not continue with this procedure. Select the repository group. Click on the Configure tab. Drag the new JBoss Maven repository from the Available Repositories list to the Ordered Group Repositories list on the left. Note The order of this list determines the priority for searching Maven artifacts. Result The repository is configured using Nexus Maven Repository Manager. Report a bug

Commands:
12.2. Setup Follow these steps to enable, configure, and start using nested virtualization: Enable : The feature is disabled by default. To enable it, use the following procedure on the L0 host physical machine. For Intel: Check whether nested virtualization is available on your host system. If this command returns Y or 1 , the feature is enabled. If the command returns 0 or N , use steps ii and iii . Unload the kvm_intel module: Activate the nesting feature: The nesting feature is now enabled only until the reboot of the L0 host. To enable it permanently, add the following line to the /etc/modprobe.d/kvm.conf file: For AMD: Check whether nested virtualization is available on your system: If this command returns Y or 1 , the feature is enabled. If the command returns 0 or N , use steps ii and iii . Unload the kvm_amd module Activate the nesting feature The nesting feature is now enabled only until the reboot of the L0 host. To enable it permanently, add the following line to the /etc/modprobe.d/kvm.conf file: Configure your L1 virtual machine for nested virtualization using one of the following methods: virt-manager Open the GUI of the intended guest and click the Show Virtual Hardware Details icon. Select the Processor menu, and in the Configuration section, type host-passthrough in the Model field (do not use the drop-down selection), and click Apply . Domain XML Add the following line to the domain XML file of the guest: If the guest's XML configuration file already contains a <cpu> element, rewrite it. To start using nested virtualization, install an L2 guest within the L1 guest. To do this, follow the same procedure as when installing the L1 guest - see Chapter 3, Creating a Virtual Machine for more information.

Commands:
cat /sys/module/kvm_intel/parameters/nested
modprobe -r kvm_intel
modprobe kvm_intel nested=1
options kvm_intel nested=1
cat /sys/module/kvm_amd/parameters/nested
modprobe -r kvm_amd
modprobe kvm_amd nested=1
options kvm_amd nested=1
<cpu mode='host-passthrough'/>
13.2.2. Reporting on Disk Quotas Creating a disk usage report entails running the repquota utility. For example, the command repquota /home produces this output: To view the disk usage report for all (option -a ) quota-enabled file systems, use the command: While the report is easy to read, a few points should be explained. The -- displayed after each user is a quick way to determine whether the block or inode limits have been exceeded. If either soft limit is exceeded, a + appears in place of the corresponding - ; the first - represents the block limit, and the second represents the inode limit. The grace columns are normally blank. If a soft limit has been exceeded, the column contains a time specification equal to the amount of time remaining on the grace period. If the grace period has expired, none appears in its place.

Commands:
*** Report for user quotas on device /dev/mapper/VolGroup00-LogVol02 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 36 0 0 4 0 0 kristin -- 540 0 0 125 0 0 testuser -- 440400 500000 550000 37418 0 0
repquota -a
Chapter 6. Upgrading to the latest version You can upgrade your private automation hub to the latest version using the Ansible Automation Platform setup bundle installer. Perform this upgrade using the inventory file configured when you installed private automation hub. Navigate to Download Red Hat Ansible Automation Platform . Click Download Now for the Ansible Automation Platform <latest-version> Setup Bundle . Extract the files: USD tar xvzf ansible-automation-platform-setup-bundle-<latest-version>.tar.gz Copy the configuration information from your initial installation to the inventory file. Run the setup.sh script USD ./setup.sh Verifying your upgrade You can verify a successful upgrade to your private automation hub by reviewing the Server version information. Log in to your private automation hub. Click the ? icon in the navigation bar. Click About . Verify that the server version matches the version you upgraded to.

Commands:
tar xvzf ansible-automation-platform-setup-bundle-<latest-version>.tar.gz
./setup.sh
Chapter 1. What is GitOps? GitOps is a declarative way to implement continuous deployment for cloud native applications. You can use GitOps to create repeatable processes for managing OpenShift Container Platform clusters and applications across multi-cluster Kubernetes environments. GitOps handles and automates complex deployments at a fast pace, saving time during deployment and release cycles. The GitOps workflow pushes an application through development, testing, staging, and production. GitOps either deploys a new application or updates an existing one, so you only need to update the repository; GitOps automates everything else. GitOps is a set of practices that use Git pull requests to manage infrastructure and application configurations. In GitOps, the Git repository is the only source of truth for system and application configuration. This Git repository contains a declarative description of the infrastructure you need in your specified environment and contains an automated process to make your environment match the described state. Also, it contains the entire state of the system so that the trail of changes to the system state are visible and auditable. By using GitOps, you resolve the issues of infrastructure and application configuration sprawl. GitOps defines infrastructure and application definitions as code. Then, it uses this code to manage multiple workspaces and clusters to simplify the creation of infrastructure and application configurations. By following the principles of the code, you can store the configuration of clusters and applications in Git repositories, and then follow the Git workflow to apply these repositories to your chosen clusters. You can apply the core principles of developing and maintaining software in a Git repository to the creation and management of your cluster and application configuration files.

Commands:
5.6. Creating Distributed Replicated Volumes Use distributed replicated volumes in environments where the requirement to scale storage, and high-reliability is critical. Distributed replicated volumes also offer improved read performance in most environments. Note The number of bricks must be a multiple of the replica count for a distributed replicated volume. Also, the order in which bricks are specified has a great effect on data protection. Each replica_count consecutive bricks in the list you give will form a replica set, with all replica sets combined into a distribute set. To ensure that replica-set members are not placed on the same node, list the first brick on every server, then the second brick on every server in the same order, and so on. Prerequisites A trusted storage pool has been created, as described in Section 4.1, "Adding Servers to the Trusted Storage Pool" . Understand how to start and stop volumes, as described in Section 5.10, "Starting Volumes" . 5.6.1. Creating Three-way Distributed Replicated Volumes Three-way distributed replicated volume distributes and creates three copies of files across multiple bricks in the volume. The number of bricks must be equal to the replica count for a replicated volume. To protect against server and disk failures, it is recommended that the bricks of the volume are from different servers. Synchronous three-way distributed replication is now fully supported in Red Hat Gluster Storage. It is recommended that three-way distributed replicated volumes use JBOD, but use of hardware RAID with three-way distributed replicated volumes is also supported. Figure 5.3. Illustration of a Three-way Distributed Replicated Volume Creating three-way distributed replicated volumes Run the gluster volume create command to create the distributed replicated volume. The syntax is # gluster volume create NEW-VOLNAME [replica COUNT ] [transport tcp | rdma (Deprecated) | tcp,rdma] NEW-BRICK... The default value for transport is tcp . Other options can be passed such as auth.allow or auth.reject . See Section 11.1, "Configuring Volume Options" for a full list of parameters. Example 5.5. Six Node Distributed Replicated Volume with a Three-way Replication The order in which bricks are specified determines how bricks are replicated with each other. For example, first 3 bricks, where 3 is the replica count forms a replicate set. Run # gluster volume start VOLNAME to start the volume. Run gluster volume info command to optionally display the volume information. Important By default, the client-side quorum is enabled on three-way distributed replicated volumes. You must also set server-side quorum on the distributed-replicated volumes to prevent split-brain scenarios. For more information on setting quorums, see Section 11.15.1, "Preventing Split-brain" .

Commands:
gluster v create glustervol replica 3 transport tcp server1:/rhgs/brick1 server2:/rhgs/brick1 server3:/rhgs/brick1 server4:/rhgs/brick1 server5:/rhgs/brick1 server6:/rhgs/brick1 volume create: glutervol: success: please start the volume to access data
gluster v start glustervol volume start: glustervol: success
function::print_stack Name function::print_stack - Print out kernel stack from string Synopsis Arguments stk String with list of hexadecimal addresses Description This function performs a symbolic lookup of the addresses in the given string, which is assumed to be the result of a prior call to backtrace . Print one line per address, including the address, the name of the function containing the address, and an estimate of its position within that function. Return nothing. NOTE it is recommended to use print_syms instead of this function.

Commands:
print_stack(stk:string)
probe::sunrpc.svc.process Name probe::sunrpc.svc.process - Process an RPC request Synopsis sunrpc.svc.process Values rq_prog the program number in the request rq_vers the program version in the request peer_ip the peer address where the request is from rq_proc the procedure number in the request sv_prog the number of the program rq_prot the IP protocol of the reqeust sv_name the service name rq_xid the transmission id in the request sv_nrthreads the number of concurrent threads

Commands:
Chapter 1. Understanding Red Hat OpenStack Platform Red Hat OpenStack Platform (RHOSP) provides the foundation to build a private or public Infrastructure-as-a-Service (IaaS) cloud on top of Red Hat Enterprise Linux. It is a scalable, fault-tolerant platform for the development of cloud-enabled workloads. RHOSP delivers an integrated foundation to create, deploy, and scale a secure and reliable public or private OpenStack cloud. RHOSP is packaged so that you can create private, public, or hybrid cloud platforms from your available physical hardware. RHOSP clouds include the following components: Fully distributed object storage Persistent block-level storage Virtual machine provisioning engine and image storage Authentication and authorization mechanisms Integrated networking Web browser-based interface accessible to users and administrators The RHOSP IaaS cloud is implemented by a collection of interacting services that control its computing, storage, and networking resources. You can manage the cloud with a web-based interface to control, provision, and automate RHOSP resources. Additionally, an extensive API controls the RHOSP infrastructure and this API is also available to end users of the cloud. 1.1. Advantages of using Red Hat OpenStack Platform You can use Red Hat OpenStack Platform to combine virtualization, networking, and storage based on your requirements. The following capabilities are some of the advantages of the Red Hat OpenStack Platform: You can create public, private, or hybrid clouds that you can scale up or down based on your requirements. You can deploy cloud-enabled workloads based on your needs. You can address customer demands in hours or minutes instead of weeks or days, without sacrificing security, performance, or budget. You can implement stability and agility for your cloud environments, using hybrid cloud management, monitoring, and reporting with Red Hat CloudForms. 1.2. Relationship between RDO and OpenStack Foundation OpenStack Foundation promotes the global development, distribution, and adoption of the OpenStack cloud operating system. The goal of the OpenStack Foundation is to serve developers, users, and the entire ecosystem globally by providing a set of shared resources to grow the footprint of public and private OpenStack clouds, enable technology vendors targeting the platform and assist developers to produce the best cloud software in the industry. RPM Distribution of OpenStack (RDO) is a free, community-supported distribution of the Red Hat version of OpenStack that runs on Red Hat Enterprise Linux (RHEL) and its derivatives, such as CentOS. RDO also makes the latest OpenStack development release available for Fedora. In addition to providing a set of software packages, RDO is a community of users of cloud computing platforms on Red Hat-based operating systems to get help and compare notes on running OpenStack. For enterprise-level support or information on partner certification, Red Hat offers Red Hat OpenStack Platform. For more information, see Red Hat OpenStack Platform .

Commands:
Chapter 1. Installing Red Hat Developer Hub on OpenShift Dedicated on GCP using the Operator You can install Developer Hub on OpenShift Dedicated on GCP using the Red Hat Developer Hub Operator. Prerequisites You have a valid GCP account. Your OpenShift Dedicated cluster is running on GCP. For more information, see Creating a cluster on GCP in Red Hat OpenShift Dedicated documentation. You have administrator access to OpenShift Dedicated cluster and GCP project. Procedure In the Administrator perspective of the OpenShift Container Platform web console, click Operators > OperatorHub . In the Filter by keyword box, enter Developer Hub and click the Red Hat Developer Hub Operator card. On the Red Hat Developer Hub Operator page, click Install . In the OpenShift Container Platform console, navigate to Installed Operators and select Red Hat Developer Hub Operator . From the Developer Hub Operator page, click Create New Instance and specify the name and namespace where you want to deploy Developer Hub. Configure the required settings such as Git integration, secret management, and user permissions. Review the configuration, select deployment options, and click Create . Verification To access the Developer Hub, navigate to the Developer Hub URL provided in the OpenShift Container Platform web console. Additional resources Configuring Customizing

Commands:
2.2. Packages Required to Install an IdM Server To install the packages required for a server without integrated DNS services: To install the packages required for a server with integrated DNS services: Note To determine whether DNS is right for your use case, see Section 2.3.1, "Determining Whether to Use Integrated DNS" . The ipa-server package automatically installs other required packages as dependencies, such as: 389-ds-base for the Directory Server LDAP service krb5-server package for the Kerberos service various IdM-specific tools

Commands:
yum install ipa-server
yum install ipa-server ipa-server-dns
12.6. Starting CTDB and Samba Services After starting up the cluster, you must mount the GFS2 file systems that you created, as described in Section 12.3, "GFS2 Configuration" . The permissions on the Samba share directory and user accounts on the cluster nodes should be set up for client access. Execute the following command on all of the nodes to start up the ctdbd daemon. Since this example configured CTDB with CTDB_MANAGES_SAMBA=yes , CTDB will also start up the Samba service on all nodes and export all configured Samba shares. It can take a couple of minutes for CTDB to start Samba, export the shares, and stabilize. Executing ctdb status shows the status of CTDB, as in the following example: When you see that all nodes are "OK", it is safe to move on to use the clustered Samba server, as described in Section 12.7, "Using the Clustered Samba Server" .

Commands:
service ctdb start
ctdb status Number of nodes:3 pnn:0 192.168.1.151 OK (THIS NODE) pnn:1 192.168.1.152 OK pnn:2 192.168.1.153 OK Generation:1410259202 Size:3 hash:0 lmaster:0 hash:1 lmaster:1 hash:2 lmaster:2 Recovery mode:NORMAL (0) Recovery master:0
Chapter 5. Setting up an automation controller token Automation controller must contain a project based on a repository with certain playbooks designed to work with the Event-Driven Ansible rulebooks. Automation controller must also have corresponding job templates set up based on the playbooks in that project. 5.1. Setting up a token to authenticate to automation controller Prerequisites You are logged in to the Event-Driven Ansible controller Dashboard as a Content Consumer. You have created a user. You can log in to the Event-Driven Ansible controller Dashboard or you are added as a user in the organization. Procedure Go to the Event-Driven Ansible controller Dashboard. From the top navigation panel, select your profile. Go to User details . Select Controller Tokens Create controller token . Insert the following: Name Insert the name. Description This field is optional. Token Create the token in automation controller. For more information about creating the token, see the Users - Tokens section of the Automation controller User Guide. Note Your token must be in write-scope and if you are the assigned user, you must have permission to execute job and workflow templates. Select Create controller token . After saving the new token, you are brought to the Controller Tokens tab where you can delete the token.

Commands:
Preface This guide provides information on updating Red Hat Fuse and Fuse applications: Note If you want to migrate from Fuse 6 to the latest Fuse 7 release, before you follow the instructions in this guide, you should follow the instructions in the Red Hat Fuse 7.0 Migration Guide . Chapter 2, Upgrading Fuse Online Chapter 5, Upgrading Fuse applications on Spring Boot standalone Chapter 4, Migrating from Fabric8 Maven plugin to Openshift Maven plugin Chapter 6, Upgrading Fuse applications on JBoss EAP standalone Chapter 7, Upgrading Fuse applications on Karaf standalone Chapter 8, Upgrading Fuse Standalone on Karaf

Commands:
14.3. Attaching Interface Devices The virsh attach-interface domain type source command can take the following options: --live - get value from running domain --config - get value to be used on boot --current - get value according to current domain state --persistent - behaves like --config for an offline domain, and like --live for a running domain. --target - indicates the target device in the guest virtual machine. --mac - use this to specify the MAC address of the network interface --script - use this to specify a path to a script file handling a bridge instead of the default one. --model - use this to specify the model type. --inbound - controls the inbound bandwidth of the interface. Acceptable values are average , peak , and burst . --outbound - controls the outbound bandwidth of the interface. Acceptable values are average , peak , and burst . The type can be either network to indicate a physical network device, or bridge to indicate a bridge to a device. source is the source of the device. To remove the attached device, use the virsh detach-device .

Commands: