mtpti5iD/redhat-docs_dataset huggingface dataset:
22.14.2. Configure the Firewall Using the Command Line To enable NTP to pass through the firewall using the command line, issue the following command as root : Note that this will restart the firewall as long as it has not been disabled with the --disabled option. Active connections will be terminated and time out on the initiating machine. When preparing a configuration file for multiple installations using administration tools, it is useful to edit the firewall configuration file directly. Note that any mistakes in the configuration file could have unexpected consequences, cause an error, and prevent the firewall setting from being applied. Therefore, check the /etc/sysconfig/system-config-firewall file thoroughly after editing. To enable NTP to pass through the firewall, by editing the configuration file, become the root user and add the following line to /etc/sysconfig/system-config-firewall : Note that these changes will not take effect until the firewall is reloaded or the system restarted. 22.14.2.1. Checking Network Access for Incoming NTP Using the Command Line To check if the firewall is configured to allow incoming NTP traffic for clients using the command line, issue the following command as root: In this example taken from a default installation, the firewall is enabled but NTP has not been allowed to pass through. Once it is enabled, the following line appears as output in addition to the lines shown above: To check if the firewall is currently allowing incoming NTP traffic for clients, issue the following command as root :

Commands:
~]# lokkit --port=123:udp --update
--port=123:udp
~]# less /etc/sysconfig/system-config-firewall Configuration file for system-config-firewall --enabled --service=ssh
--port=123:udp
~]# iptables -L -n | grep 'udp.*123' ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:123
Chapter 9. Authorization for Enrolling Certificates (Access Evaluators) This chapter describes the authorization mechanism using access evaluators. Note For instructions on how to edit certificate enrollment profiles, see Section 3.2, "Setting up certificate profiles" . 9.1. Authorization Mechanism In addition to the authentication mechanism, each enrollment profile can be configured to have its own authorization mechanism. The authorization mechanism is executed only after a successful authentication. The authorization mechanism is provided by the Access Evaluator plugin framework. Access evaluators are pluggable classes that are used for evaluating access control instructions (ACI) entries. The mechanism provides an evaluate method that takes a predefined list of arguments (that is, type , op , value ), evaluates an expression such as group='Certificate Manager Agents' and returns a boolean depending on the result of evaluation. 9.2. Default Evaluators Red Hat Certificate System provides four default evaluators. The following entries are listed by default in the CS.cfg file: The group access evaluator evaluates the group membership properties of a user. For example, in the following enrollment profile entry, only the CA agents are allowed to go through enrollment with that profile: The ipaddress access evaluator evaluates the IP address of the requesting subject. For example, in the following enrollment profile entry, only the host bearing the specified IP address can go through enrollment with that profile: The user access evaluator evaluates the user ID for exact match. For example, in the following enrollment profile entry, only the user matching the listed user is allowed to go through enrollment with that profile: The user_origreq access evaluator evaluates the authenticated user against a matching request for equality. This special evaluator is designed specifically for renewal purpose to make sure the user requesting the renewal is the same user that owns the original request. For example, in the following renewal enrollment profile entry, the UID of the authenticated user must match the UID of the user requesting the renewal: New evaluators can be written in the current framework and can be registered through the CS console. The default evaluators can be used as templates to expand and customize into more targeted plugins.

Commands:
accessEvaluator.impl.group.class=com.netscape.cms.evaluators.GroupAccessEvaluator accessEvaluator.impl.ipaddress.class=com.netscape.cms.evaluators.IPAddressAccessEvaluator accessEvaluator.impl.user.class=com.netscape.cms.evaluators.UserAccessEvaluator accessEvaluator.impl.user_origreq.class=com.netscape.cms.evaluators.UserOrigReqAccessEvaluator
authz.acl=group="Certificate Manager Agents"
authz.acl=ipaddress="a.b.c.d.e.f"
authz.acl=user="bob"
authz.acl=user_origreq="auth_token.uid"
5.5. Nautilus The nautilus-open-terminal package provides a right-click Open Terminal option to open a new terminal window in the current directory. Previously, when this option was chosen from the Desktop , the new terminal window location defaulted to the user's home directory. However, in Red Hat Enterprise Linux 6, the default behavior opens the Desktop directory (i.e ~/Desktop/ ). To enable the behavior, use the following command to set the desktop_opens_home_dir GConf Boolean to true:

Commands:
gconftool-2 -s /apps/nautilus-open-terminal/desktop_opens_dir --type=bool true
Chapter 9. Executing the deployment playbook Change into the hc-ansible-deployment directory on the first node: Run the following command as the root user to start the deployment process: Enter the vault password when prompted to start deployment. Important If you are using Red Hat Virtualization Host (RHVH) 4.4 SP1 based on Red Hat Enterprise Linux 8.6 (RHEL 8.6), add the -e 'ansible_python_interpreter=/usr/bin/python3.6' parameter:

Commands:
cd /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment
ansible-playbook -i gluster_inventory.yml hc_deployment.yml --extra-vars='@he_gluster_vars.json' --ask-vault-pass
ansible-playbook -e 'ansible_python_interpreter=/usr/bin/python3.6' -i gluster_inventory.yml hc_deployment.yml --extra-vars='@he_gluster_vars.json' --ask-vault-pass
A.3. Fsync Fsync is known as an I/O expensive operation, but this is is not completely true. Firefox used to call the sqlite library each time the user clicked on a link to go to a new page. Sqlite called fsync and because of the file system settings (mainly ext3 with data-ordered mode), there was a long latency when nothing happened. This could take a long time (up to 30 seconds) if another process was copying a large file at the same time. However, in other cases, where fsync was not used at all, problems emerged with the switch to the ext4 file system. Ext3 was set to data-ordered mode, which flushed memory every few seconds and saved it to a disk. But with ext4 and laptop_mode, the interval between saves was longer and data might get lost when the system was unexpectedly switched off. Now ext4 is patched, but we must still consider the design of our applications carefully, and use fsync as appropriate. The following simple example of reading and writing into a configuration file shows how a backup of a file can be made or how data can be lost: /* open and read configuration file e.g. ./myconfig */ fd = open("./myconfig", O_RDONLY); read(fd, myconfig_buf, sizeof(myconfig_buf)); close(fd); ... fd = open("./myconfig", O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR); write(fd, myconfig_buf, sizeof(myconfig_buf)); close(fd); A better approach would be: /* open and read configuration file e.g. ./myconfig */ fd = open("./myconfig", O_RDONLY); read(fd, myconfig_buf, sizeof(myconfig_buf)); close(fd); ... fd = open("./myconfig.suffix", O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR write(fd, myconfig_buf, sizeof(myconfig_buf)); fsync(fd); /* paranoia - optional */ ... close(fd); rename("./myconfig", "./myconfig~"); /* paranoia - optional */ rename("./myconfig.suffix", "./myconfig");

Commands:
/* open and read configuration file e.g. ./myconfig */ fd = open("./myconfig", O_RDONLY); read(fd, myconfig_buf, sizeof(myconfig_buf)); close(fd); fd = open("./myconfig", O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR); write(fd, myconfig_buf, sizeof(myconfig_buf)); close(fd);
/* open and read configuration file e.g. ./myconfig */ fd = open("./myconfig", O_RDONLY); read(fd, myconfig_buf, sizeof(myconfig_buf)); close(fd); fd = open("./myconfig.suffix", O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR write(fd, myconfig_buf, sizeof(myconfig_buf)); fsync(fd); /* paranoia - optional */ close(fd); rename("./myconfig", "./myconfig~"); /* paranoia - optional */ rename("./myconfig.suffix", "./myconfig");
Chapter 3. Features and benefits 3.1. Current features and benefits .NET 6.0 offers the following features and benefits. Runtime and framework libraries .NET consists of the runtime and the framework libraries as well as compilers, build tools, tools to fetch NuGet packages, and a command-line interface to tie everything together. Benefits include: Automatic memory management Type safety Delegates and lambdas Generic types Language Integrated Query (LINQ) Async programming Native interoperability Source generators .NET 6.0 supports developing applications using ASP.NET Core 6.0 and EF Core 6.0, which bring benefits such as: Lightweight and modular HTTP request pipeline Ability to host on a web server or self-host in your own process Built on .NET, which supports true side-by-side app versioning Integrated support for creating and using NuGet packages Single aligned web stack for web UI and web APIs Cloud-ready environment-based configuration Built-in support for dependency injection Tools that simplify modern web development 3.2. New features and benefits Support for 64-bit Arm (aarch 64), IBM Z, and LinuxONE (s390x) .NET 6.0 introduces support for 64-bit Arm running on Red Hat Enterprise Linux 8. .NET 6.0 introduces support for IBM Z and LinuxONE running on Red Hat Enterprise Linux 8 and OpenShift Container Platform 4.2 or later. .NET 6.0 continues to broaden its support and tools for application development in an open source environment. The latest version of .NET includes the following improvements: Support for C# 10 Support for F# 6 Single-file source programs Performance improvements in base libraries, GC and JIT Source-generators for logging and JSON Better diagnostics with dotnet-monitor

Commands:
Chapter 4. Reviewing and resolving migration issues You can review and resolve migration issues identified by the MTA plugin in the left pane. 4.1. Reviewing issues You can use the MTA plugin icons to prioritize issues based on their severity. You can see which issues have a Quick Fix automatic code replacement and which do not. The results of an analysis are displayed in a directory format, showing the hints and classifications for each application analyzed. A hint is a read-only snippet of code that contains a single issue that you should or must address before you can modernize or migrate an application. Often a Quick Fix is suggested, which you can accept or ignore. A classification is a file that has an issue but does not have any suggested Quick Fixes. You can edit a classification. Procedure In the Migration Toolkit for Applications view, select a run configuration directory in the left pane. Click Results . The modules and applications of the run configuration are displayed, with hints and classifications beneath each application. Prioritize issues based on the following icons, which are displayed to each hint: : You must fix this issue in order to migrate or modernize the application. : You might need to fix this issue in order to migrate or modernize the application Optional: To learn more about a hint, right-click it and select Show More Details . 4.2. Resolving issues You can resolve issues by doing one of the following: Using a Quick Fix to fix a code snippet that has a hint Editing the code of a file that appears in a classification 4.2.1. Using a Quick Fix You can use a Quick Fix automatic code replacement to save time and ensure consistency in resolving repetitive issues. Quick Fixes are available for many issues displayed in the Hints section of the Results directory. Procedure In the left pane, click a hint that has an error indicator. Any Quick Fixes are displayed as child folders with the Quick Fix icon ( ) on their left side. Right-click a Quick Fix and select Preview Quick Fix . The current code and the suggested change are displayed in the Preview Quick Fix window. To accept the suggested fix, click Apply Quick Fix . Optional: Right-click the issue and select Mark As Complete . A green check ( ) is displayed by the hint, replacing the error indicator. 4.2.2. Editing the code of a file You can directly edit a file displayed in the Classifications section of the Results directory. These files do not have any Quick Fixes. Procedure In the left pane, click the file you want to edit. Make any changes needed to the code and save the file. Optional: Right-click the issue and select Mark as Complete or Delete . If you select Mark as Complete , a green check ( ) is displayed by the hint, replacing the error indicator.

Commands:
4.18. RHEA-2012:0823 - new package: subscription-manager-migration-data A new subscription-manager-migration-data package is now available for Red Hat Enterprise Linux 6. The new Subscription Management tooling allows users to understand the specific products, which have been installed on their machines, and the specific subscriptions, which their machines consume. This enhancement update adds the subscription-manager-migration-data package to Red Hat Enterprise Linux 6. The package allows for migrations from Red Hat Network Classic Hosted to hosted certificate-based subscription management. (BZ# 773030 ) All users who require subscription-manager-migration-data are advised to install this new package.

Commands:
Chapter 2. Acknowledgments Red Hat Ceph Storage version 7.1 contains many contributions from the Red Hat Ceph Storage team. In addition, the Ceph project is seeing amazing growth in the quality and quantity of contributions from individuals and organizations in the Ceph community. We would like to thank all members of the Red Hat Ceph Storage team, all of the individual contributors in the Ceph community, and additionally, but not limited to, the contributions from organizations such as: Intel(R) Fujitsu (R) UnitedStack Yahoo TM Ubuntu Kylin Mellanox (R) CERN TM Deutsche Telekom Mirantis (R) SanDisk TM SUSE (R)

Commands:
Chapter 5. Upgrading CodeReady Workspaces This chapter describes how to upgrade a CodeReady Workspaces instance to CodeReady Workspaces 2.1. 5.1. Upgrading CodeReady Workspaces using OperatorHub This section describes how to upgrade from CodeReady Workspaces 2.0 to CodeReady Workspaces 2.1 on OpenShift 4 using the OpenShift web console. This method is using the Operator from OperatorHub. Prerequisites An administrator account on an OpenShift 4 instance. An instance of CodeReady Workspaces 2.0, running on the same instance of OpenShift 4, installed using an Operator from OperatorHub. Procedure Open the OpenShift web console. Navigate to the Operators Installed Operators section. Click Red Hat CodeReady Workspaces in the list of installed operators. Navigate to the Subscription tab and enable the following options: Channel : latest Approval : Automatic Verification steps Log in to the CodeReady Workspaces instance. The 2.1 version number is visible at the bottom of the page. 5.2. Upgrading CodeReady Workspaces using CLI management tool on OpenShift 3 This section describes how to upgrade from CodeReady Workspaces 2.0 to CodeReady Workspaces 2.1 on OpenShift 3 using the CLI management tool. Prerequisites An administrative account on an OpenShift 3 instance. A running instance of Red Hat CodeReady Workspaces running on OpenShift 3, installed using the CLI management tool. The crwctl management tool installed. Procedure In all running workspaces in the CodeReady Workspaces 2.0 instance, save and push changes to Git repositories. Run the following command: Verification steps Log in to the CodeReady Workspaces instance. The 2.1 version number is visible at the bottom of the page. 5.3. Upgrading CodeReady Workspaces from major version This sections describes how to perform an upgrade from the major version of Red Hat CodeReady Workspaces (1.2). Procedure See Upgrading CodeReady Workspaces section in CodeReady Workspaces 2.0 Installation Guide

Commands:
crwctl server:update
8.41. cyrus-sasl 8.41.1. RHBA-2014:1570 - cyrus-sasl bug fix and enhancement update Updated cyrus-sasl packages that fix two bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. The cyrus-sasl packages contain the Cyrus implementation of Simple Authentication and Security Layer (SASL). SASL is a method for adding authentication support to connection-based protocols. Bug Fixes BZ# 838628 A memory leak in the Digest MD5 plugin was discovered. Specifically, the make_client_response() function did not correctly free the output buffer. Consequently, applications that used Digest MD5 with very large datasets could terminate unexpectedly. This update corrects make_client_response() and closes the memory leak. As a result, applications using Digest MD5 as part of authentication with large datasets now work as expected. BZ# 1081445 Previously, unnecessary quote characters were used in the cyrus-sasl.spec file when the user was created using the useradd command. Consequently, the Saslauth user was created with quotes in the comment field ("Saslauthd user"). With this update, unnecessary quotes have been removed from the comment field. In addition, this update adds the following Enhancement BZ# 994242 The ad_compat option has been backported to the cyrus-sasl packages from upstream. This option controls compatibility with AD or similar servers that require both integrity and confidentiality bits selected during security layer negotiation. Users of cyrus-sasl are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
9.2. Starting and Stopping NFS To run an NFS server, the portmap service must be running. To verify that portmap is active, type the following command as root: If the portmap service is running, then the nfs service can be started. To start an NFS server, as root type: To stop the server, as root, type: The restart option is a shorthand way of stopping and then starting NFS. This is the most efficient way to make configuration changes take effect after editing the configuration file for NFS. To restart the server, as root, type: The condrestart ( conditional restart ) option only starts nfs if it is currently running. This option is useful for scripts, because it does not start the daemon if it is not running. To conditionally restart the server, as root, type: To reload the NFS server configuration file without restarting the service, as root, type: By default, the nfs service does not start automatically at boot time. To configure the NFS to start up at boot time, use an initscript utility, such as /sbin/chkconfig , /usr/sbin/ntsysv , or the Services Configuration Tool program. Refer to the chapter titled Controlling Access to Services in the System Administrators Guide for more information regarding these tools.

Commands:
/sbin/service portmap status
/sbin/service nfs start
/sbin/service nfs stop
/sbin/service nfs restart
/sbin/service nfs condrestart
/sbin/service nfs reload
Chapter 4. Creating VolumeReplicationClass resource The VolumeReplicationClass is used to specify the mirroringMode for each volume to be replicated as well as how often a volume or image is replicated (for example, every 5 minutes) from the local cluster to the remote cluster. Note This resource must be created on the Primary managed cluster and the Secondary managed cluster . Procedure Save the following YAML to filename rbd-volumereplicationclass.yaml . Create the file on both the managed clusters. Example output:

Commands:
apiVersion: replication.storage.openshift.io/v1alpha1 kind: VolumeReplicationClass metadata: name: odf-rbd-volumereplicationclass spec: provisioner: openshift-storage.rbd.csi.ceph.com parameters: mirroringMode: snapshot schedulingInterval: "5m" # <-- Must be the same as scheduling interval in the DRPolicy replication.storage.openshift.io/replication-secret-name: rook-csi-rbd-provisioner replication.storage.openshift.io/replication-secret-namespace: openshift-storage
oc create -f rbd-volumereplicationclass.yaml
volumereplicationclass.replication.storage.openshift.io/odf-rbd-volumereplicationclass created
Chapter 2. Determining permission policy and role configuration source You can configure Red Hat Developer Hub policy and roles by using different sources. To maintain data consistency, Developer Hub associates each permission policy and role with one unique source. You can only use this source to change the resource. The available sources are: Configuration file Configure roles and policies in the Developer Hub app-config.yaml configuration file, for instance to declare your policy administrators . The Configuration file pertains to the default role:default/rbac_admin role provided by the RBAC plugin. The default role has limited permissions to create, read, update, delete permission policies or roles, and to read catalog entities. Note In case the default permissions are insufficient for your administrative requirements, you can create a custom admin role with the required permission policies. REST API Configure roles and policies by using the Developer Hub Web UI or by using the REST API. CSV file Configure roles and policies by using external CSV files. Legacy The legacy source applies to policies and roles defined before RBAC backend plugin version 2.1.3 , and is the least restrictive among the source location options. Important Replace the permissions and roles using the legacy source with the permissions using the REST API or the CSV file sources. Procedure To determine the source of a role or policy, use a GET request.

Commands: