mtpti5iD/redhat-docs_dataset huggingface dataset:
Appendix A. Revision History Revision History Revision 2-82 Mon Jun 4 2018 Marek Suchanek Asynchronous update Revision 2-81 Wed Mar 21 2018 Marek Suchanek Asynchronous update Revision 2-70 Mon Mar 13 2017 Milan Navratil Preparing document for 6.9 GA publication. Revision 2-64 Thu May 10 2016 Milan Navratil Preparing document for 6.8 GA publication. Revision 2-63 Thu Mar 31 2016 Milan Navratil Asynchronous update with multiple minor improvements. Revision 2-52 Wed Mar 25 2015 Jacquelynn East Added ext back up and restore chapters Revision 2-51 Thu Oct 9 2014 Jacquelynn East Version for 6.6 GA release Revision 2-38 Mon Nov 18 2013 Jacquelynn East Build for 6.5 GA Revision 2-35 Thu Sep 05 2013 Jacquelynn East Added a section documenting fsck. Revision 2-11 Mon Feb 18 2013 Jacquelynn East Version for 6.4 GA release. Revision 2-1 Fri Oct 19 2012 Jacquelynn East Branched for 6.4 Beta. Created new edition based on significant structual reordering. Revision 1-45 Mon Jun 18 2012 Jacquelynn East Version for 6.3 release.

Commands:
function::sprint_ubacktrace Name function::sprint_ubacktrace - Return stack back trace for current task as string. EXPERIMENTAL! Synopsis Arguments None Description Returns a simple backtrace for the current task. One line per address. Includes the symbol name (or hex address if symbol couldn't be resolved) and module name (if found). Includes the offset from the start of the function if found, otherwise the offset will be added to the module (if found, between brackets). Returns the backtrace as string (each line terminated by a newline character). Note that the returned stack will be truncated to MAXSTRINGLEN, to print fuller and richer stacks use print_ubacktrace . Equivalent to sprint_ustack( ubacktrace ), but more efficient (no need to translate between hex strings and final backtrace string). Note To get (full) backtraces for user space applications and shared shared libraries not mentioned in the current script run stap with -d /path/to/exe-or-so and/or add --ldd to load all needed unwind data.

Commands:
function sprint_ubacktrace:string()
10.3.2. Saving Traceback Messages If anaconda encounters an error during the graphical installation process, it presents you with a crash reporting dialog box: Figure 10.1. The Crash Reporting Dialog Box Details shows you the details of the error: Figure 10.2. Details of the Crash Save saves details of the error locally or remotely: Exit exits the installation process. If you select Save from the main dialog, you can choose from the following options: Figure 10.3. Select reporter Logger saves details of the error as a log file to the local hard drive at a specified location. Red Hat Customer Support submits the crash report to Customer Support for assistance. Report uploader uploads a compressed version of the crash report to Bugzilla or a URL of your choice. Before submitting the report, click Preferences to specify a destination or provide authentication details. Select the reporting method you need to configure and click Configure Event . Figure 10.4. Configure reporter preferences Logger Specify a path and a filename for the log file. Check Append if you are adding to an existing log file. Figure 10.5. Specify local path for log file Red Hat Customer Support Enter your Red Hat Network username and password so your report reaches Customer Support and is linked with your account. The URL is prefilled and Verify SSL is checked by default. Figure 10.6. Enter Red Hat Network authentication details Report uploader Specify a URL for uploading a compressed version of the crash report. Figure 10.7. Enter URL for uploading crash report Bugzilla Enter your Bugzilla username and password to lodge a bug with Red Hat's bug-tracking system using the crash report. The URL is prefilled and Verify SSL is checked by default. Figure 10.8. Enter Bugzilla authentication details Once you have entered your preferences, click OK to return to the report selection dialog. Select how you would like to report the problem and then click Forward . Figure 10.9. Confirm report data You can now customize the report by checking and unchecking the issues that will be included. When finished, click Apply . Figure 10.10. Report in progress This screen displays the outcome of the report, including any errors in sending or saving the log. Click Forward to proceed. Figure 10.11. Reporting done Reporting is now complete. Click Forward to return to the report selection dialog. You can now make another report, or click Close to exit the reporting utility and then Exit to close the installation process.

Commands:
1.2.2. Creating a New Repository A Subversion repository is a central place to store files and directories that are under revision control, as well as additional data such as a complete history of changes or information about who made those changes and when. A typical Subversion repository stores multiple projects in separate subdirectories. When publicly accessible, it allows several developers to create a working copy of any of the subdirectories, make changes, and share these changes with others by committing them back to the repository. Initializing an Empty Repository To create a new, empty Subversion repository in a directory of your choice, run the following command: svnadmin create path Note that path is an absolute or relative path to the directory in which you want to store the repository (for example, /var/svn/ ). If the directory does not exist, svnadmin create creates it for you. Example 1.4. Initializing a new Subversion repository To create an empty Subversion repository in the ~/svn/ directory, type: Importing Data to a Repository To put an existing project under revision control, run the following command: svn import local_path svn_repository / remote_path [ -m " commit message " ] Note that local_path is an absolute or relative path to the directory in which you keep the project (use . for the current working directory), svn_repository is a URL of the Subversion repository, and remote_path is the target directory in the Subversion repository (for example, project/trunk ). Example 1.5. Importing a project to a Subversion repository Imagine that the directory with your project has the following contents: Also imagine that you have an empty Subversion repository in ~/svn/ (in this example, /home/john/svn/ ). To import the project under project/trunk in this repository, type:

Commands:
~]USD svnadmin create svn
~]USD ls myproject AUTHORS doc INSTALL LICENSE Makefile README src TODO
~]USD svn import myproject file:///home/john/svn/project/trunk -m "Initial import." Adding project/AUTHORS Adding project/doc Adding project/doc/index.html Adding project/INSTALL Adding project/src
Chapter 14. Managing GNOME Shell extensions by using the command line The gnome-extensions utility is a command-line tool that allows you to manage GNOME Shell extensions from the terminal. It provides various commands to list, install, enable, disable, remove, and get information about extensions. Each GNOME Shell extension has a UUID (Universally Unique Identifier). You can find the UUID of an extension on its GNOME Shell Extensions website page. Procedure To list the installed GNOME Shell extensions, use: To install a GNOME Shell extension, use: To enable a GNOME Shell extension, use: To show information about a GNOME Shell extension, use: To disable a GNOME Shell extension, use: To remove a GNOME Shell extension, use: Replace the <UUIDs> with the unique identifier assigned to the GNOME Shell extension you want to install. Additional resources The gnome-extensions --help page.

Commands:
gnome-extensions list
gnome-extensions install <UUID>
gnome-extensions enable <UUID>
gnome-extensions info <UUID>
gnome-extensions disable <UUID>
gnome-extensions uninstall <UUID>
14.4.2. Using the scp Utility scp can be used to transfer files between machines over a secure, encrypted connection. In its design, it is very similar to rcp . To transfer a local file to a remote system, use a command in the following form: For example, if you want to transfer taglist.vim to a remote machine named penguin.example.com , type the following at a shell prompt: Multiple files can be specified at once. To transfer the contents of .vim/plugin/ to the same directory on the remote machine penguin.example.com , type the following command: To transfer a remote file to the local system, use the following syntax: For instance, to download the .vimrc configuration file from the remote machine, type:

Commands:
scp localfile username @ hostname : remotefile
~]USD scp taglist.vim john@penguin.example.com:.vim/plugin/taglist.vim john@penguin.example.com's password: taglist.vim 100% 144KB 144.5KB/s 00:00
~]USD scp .vim/plugin/* john@penguin.example.com:.vim/plugin/ john@penguin.example.com's password: closetag.vim 100% 13KB 12.6KB/s 00:00 snippetsEmu.vim 100% 33KB 33.1KB/s 00:00 taglist.vim 100% 144KB 144.5KB/s 00:00
scp username @ hostname : remotefile localfile
~]USD scp john@penguin.example.com:.vimrc .vimrc john@penguin.example.com's password: .vimrc 100% 2233 2.2KB/s 00:00
5.346. vino 5.346.1. RHSA-2013:0169 - Moderate: vino security update An updated vino package that fixes several security issues is now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Vino is a Virtual Network Computing (VNC) server for GNOME. It allows remote users to connect to a running GNOME session using VNC. Security Fixes CVE-2012-4429 It was found that Vino transmitted all clipboard activity on the system running Vino to all clients connected to port 5900, even those who had not authenticated. A remote attacker who is able to access port 5900 on a system running Vino could use this flaw to read clipboard data without authenticating. CVE-2011-0904 , CVE-2011-0905 Two out-of-bounds memory read flaws were found in the way Vino processed client framebuffer requests in certain encodings. An authenticated client could use these flaws to send a specially-crafted request to Vino, causing it to crash. CVE-2011-1164 In certain circumstances, the vino-preferences dialog box incorrectly indicated that Vino was only accessible from the local network. This could confuse a user into believing connections from external networks are not allowed (even when they are allowed). With this update, vino-preferences no longer displays connectivity and reachable information. CVE-2011-1165 There was no warning that Universal Plug and Play (UPnP) was used to open ports on a user's network router when the "Configure network automatically to accept connections" option was enabled (it is disabled by default) in the Vino preferences. This update changes the option's description to avoid the risk of a UPnP router configuration change without the user's consent. All Vino users should upgrade to this updated package, which contains backported patches to resolve these issues. The GNOME session must be restarted (log out, then log back in) for this update to take effect.

Commands:
Preface Red Hat Enterprise Linux (RHEL) minor releases are an aggregation of individual enhancement, security, and bug fix errata. The Red Hat Enterprise Linux 6.10 Release Notes document describes the major changes made to the Red Hat Enterprise Linux 6 operating system and its accompanying applications for this minor release, as well as known problems. The Technical Notes document provides a list of notable bug fixes, all currently available Technology Previews, deprecated functionality, and other information. Capabilities and limits of Red Hat Enterprise Linux 6 as compared to other versions of the system are available in the Red Hat Knowledgebase article available at https://access.redhat.com/articles/rhel-limits . Packages distributed with this release are listed in Red Hat Enterprise Linux 6 Package Manifest . Migration to Red Hat Enterprise Linux 7 is documented in the Migration Planning Guide. For information regarding the Red Hat Enterprise Linux life cycle, refer to https://access.redhat.com/support/policy/updates/errata/ .

Commands:
4.61. filesystem 4.61.1. RHBA-2011:0966 - filesystem bug fix update An updated filesystem package that fixes one bug is now available for Red Hat Enterprise Linux 6. The filesystem package is one of the basic packages that is installed on a Red Hat Enterprise Linux system. The filesystem package contains the basic directory layout for the Linux operating system, including the correct permissions for directories. Bug Fix BZ# 620063 Prior to this update, certain locale subdirectories in the /usr/share/locale/ directory did not have any owner set. With this update, this bug has been fixed so that the filesystem package now owns the subdirectories of the following locales: bg_BG (Bulgarian), en_NZ (New Zealand English), fi_FI (Finnish), gl_ES (Galician), lv_LV (Latvian), ms_MY (Malaysian), sr_RS (Serbian), en@shaw (Shavian), zh_CN.GB2312 (Chinese Simplified), sr@ijekavian (Serbian Jekavian), and sr@ijekavianlatin (Serbian Jekavian Latin). All users of filesystem are advised to upgrade to this updated package, which fixes this bug.

Commands:
Chapter 3. Using Keycloak The Keycloak backend plugin, which integrates Keycloak into Developer Hub, has the following capabilities: Synchronization of Keycloak users in a realm. Synchronization of Keycloak groups and their users in a realm. 3.1. Importing users and groups in Developer Hub using the Keycloak plugin After configuring the plugin successfully, the plugin imports the users and groups each time when started. Note If you set up a schedule, users and groups will also be imported. After the first import is complete, you can select User to list the users from the catalog page: You can see the list of users on the page: When you select a user, you can see the information imported from Keycloak: You can also select a group, view the list, and select or view the information imported from Keycloak for a group:

Commands:
Chapter 3. A practical example of an Ansible Playbook Ansible can communicate with many different device classifications, from cloud-based REST APIs, to Linux and Windows systems, networking hardware, and much more. The following is a sample of two Ansible modules automatically updating two types of servers. 3.1. Playbook execution A playbook runs in order from top to bottom. Within each play, tasks also run in order from top to bottom. Playbooks with multiple 'plays' can orchestrate multi-machine deployments, running one play on your webservers, then another play on your database servers, then a third play on your network infrastructure, and so on. At a minimum, each play defines two things: the managed nodes to target, using a pattern at least one task to execute Note In Ansible 2.10 and later, use the fully-qualified collection name in your playbooks to ensure the correct module is selected, because multiple collections can contain modules with the same name (for example, user ). For further information, see Using collections in a playbook . In this example, the first play targets the web servers; the second play targets the database servers. --- - name: Update web servers hosts: webservers become: true tasks: - name: Ensure apache is at the latest version ansible.builtin.yum: name: httpd state: latest - name: Write the apache config file ansible.builtin.template: src: /srv/httpd.j2 dest: /etc/httpd.conf mode: "0644" - name: Update db servers hosts: databases become: true tasks: - name: Ensure postgresql is at the latest version ansible.builtin.yum: name: postgresql state: latest - name: Ensure that postgresql is started ansible.builtin.service: name: postgresql state: started The playbook contains two plays: The first checks if the web server software is up to date and runs the update if necessary. The second checks if database server software is up to date and runs the update if necessary. Your playbook can include more than just a hosts line and tasks. For example, this example playbook sets a remote_user for each play. This is the user account for the SSH connection. You can add other Playbook Keywords at the playbook, play, or task level to influence how Ansible behaves. Playbook keywords can control the connection plugin, whether to use privilege escalation, how to handle errors, and more. To support a variety of environments, Ansible enables you to set many of these parameters as command-line flags, in your Ansible configuration, or in your inventory. Learning the precedence rules for these sources of data can help you as you expand your Ansible ecosystem

Commands:
--- - name: Update web servers hosts: webservers become: true tasks: - name: Ensure apache is at the latest version ansible.builtin.yum: name: httpd state: latest - name: Write the apache config file ansible.builtin.template: src: /srv/httpd.j2 dest: /etc/httpd.conf mode: "0644" - name: Update db servers hosts: databases become: true tasks: - name: Ensure postgresql is at the latest version ansible.builtin.yum: name: postgresql state: latest - name: Ensure that postgresql is started ansible.builtin.service: name: postgresql state: started
2.3. Starting the Piranha Configuration Tool Service After you have set the password for the Piranha Configuration Tool , start or restart the piranha-gui service located in /etc/rc.d/init.d/piranha-gui . To do this, type the following command as root: /sbin/service piranha-gui start or /sbin/service piranha-gui restart Issuing this command starts a private session of the Apache HTTP Server by calling the symbolic link /usr/sbin/piranha_gui -> /usr/sbin/httpd . For security reasons, the piranha-gui version of httpd runs as the piranha user in a separate process. The fact that piranha-gui leverages the httpd service means that: The Apache HTTP Server must be installed on the system. Stopping or restarting the Apache HTTP Server by means of the service command stops the piranha-gui service. Warning If the command /sbin/service httpd stop or /sbin/service httpd restart is issued on an LVS router, you must start the piranha-gui service by issuing the following command: /sbin/service piranha-gui start The piranha-gui service is all that is necessary to begin configuring Load Balancer Add-On. However, if you are configuring Load Balancer Add-On remotely, the sshd service is also required. You do not need to start the pulse service until configuration using the Piranha Configuration Tool is complete. See Section 4.8, "Starting the Load Balancer Add-On" for information on starting the pulse service. 2.3.1. Configuring the Piranha Configuration Tool Web Server Port The Piranha Configuration Tool runs on port 3636 by default. To change this port number, change the line Listen 3636 in Section 2 of the piranha-gui Web server configuration file /etc/sysconfig/ha/conf/httpd.conf . To use the Piranha Configuration Tool you need at minimum a text-only Web browser. If you start a Web browser on the primary LVS router, open the location http:// localhost :3636 . You can reach the Piranha Configuration Tool from anywhere by means of a Web browser by replacing localhost with the host name or IP address of the primary LVS router. When your browser connects to the Piranha Configuration Tool , you must login to access the configuration services. Enter piranha in the Username field and the password set with piranha-passwd in the Password field. Now that the Piranha Configuration Tool is running, you may wish to consider limiting who has access to the tool over the network. The section reviews ways to accomplish this task.

Commands:
Chapter 6. Synchronizing Active Directory and Identity Management Users This chapter describes synchronization between Active Directory and Red Hat Enterprise Linux Identity Management. Synchronization is one of the two methods for indirect integration of the two environments. For details on the cross-forest trust, which is the other, recommended method, see Chapter 5, Creating Cross-forest Trusts with Active Directory and Identity Management . If you are unsure which method to choose for your environment, read Section 1.3, "Indirect Integration" . Identity Management uses synchronization to combine the user data stored in an Active Directory domain and the user data stored in the IdM domain. Critical user attributes, including passwords, are copied and synchronized between the services. Entry synchronization is performed through a process similar to replication, which uses hooks to connect to and retrieve directory data from the Windows server. Password synchronization is performed through a Windows service which is installed on the Windows server and then communicates to the Identity Management server. 6.1. Supported Windows Platforms Synchronization is supported with Active Directory forests that use the following forest and domain functional levels: Forest functional level range: Windows Server 2008 - Windows Server 2012 R2 Domain functional level range: Windows Server 2008 - Windows Server 2012 R2 The following operating systems are explicitly supported and tested for synchronization using the mentioned functional levels: Windows Server 2012 R2 Windows Server 2016 PassSync 1.1.5 or later is compatible with all supported Windows Server versions.

Commands: