switch to Antora part

This commit is contained in:
Adam Samalik 2018-07-27 16:38:30 +02:00
parent bc7bb84562
commit cf5acc8f3a
317 changed files with 432 additions and 1453 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 229 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 86 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 362 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 45 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 10 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.2 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.9 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.7 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.7 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.6 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.2 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.3 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.8 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 26 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 10 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 84 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 62 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 191 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 873 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 8 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 37 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 37 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 35 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 57 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 145 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 62 KiB

57
modules/ROOT/nav.adoc Normal file
View file

@ -0,0 +1,57 @@
* xref:using-aide.adoc[Checking integrity with AIDE]
* xref:anaconda/anaconda.adoc[Anaconda]
** xref:anaconda/anaconda_distros.adoc[Anaconda-based Distributions]
** xref:anaconda/anaconda_updates.adoc[Anaconda Updates]
** xref:anaconda/anaconda_logging.adoc[Anaconda Logging]
** xref:anaconda/anaconda_product_image.adoc[Anaconda Product Image]
* xref:getting-started-with-apache-http-server.adoc[Getting started with Apache HTTP Server]
* xref:finding-and-installing-linux-applications.adoc[Finding and installing Linux applications]
* xref:installing-chromium-or-google-chrome-browsers.adoc[Installing Chromium or Google Chrome browsers]
* xref:switching-desktop-environments.adoc[Switching desktop environments]
* xref:fedora-and-red-hat-enterprise-linux.adoc[Difference between Fedora and Red Hat Enterprise Linux]
* xref:dnf.adoc[Using the DNF software package manager]
* xref:dnf-system-upgrade.adoc[Upgrading Fedora using the DNF system upgrade]
* xref:securing-the-system-by-keeping-it-up-to-date.adoc[Securing the system by keeping it up-to-date]
* xref:fedora-life-cycle.adoc[Fedora Release Life Cycle]
* xref:upgrading.adoc[Upgrading to a new release of Fedora]
* xref:firewalld.adoc[Controlling network traffic with firewalld]
* xref:adding-new-fonts-fedora.adoc[Adding new fonts in Fedora]
* xref:create-gpg-keys.adoc[Creating GPG Keys]
* xref:bootloading-with-grub2.adoc[Bootloading with GRUB2]
* xref:creating-and-using-a-live-installation-image.adoc[Creating and using a live installation image]
* xref:installing-java.adoc[Installing Java]
* xref:kernel/overview.adoc[Kernel]
** xref:kernel/troubleshooting.adoc[Troubleshooting]
** xref:kernel/build-custom-kernel.adoc[Building a Custom Kernel]
* xref:managing-keyboard-shortcuts-for-running-app-in-gnome.adoc[Managing keyboard shortcuts for running an application in GNOME]
* xref:proc_setting-key-shortcut.adoc[Setting a key shortcut to run an application in GNOME]
* xref:disabling-automatic-screenlock.adoc[Disabling the GNOME automatic screen locking]
* xref:viewing-logs.adoc[Viewing logs in Fedora]
* xref:assembly_installing-plugins-for-playing-movies-and-music.adoc[Installing plugins for playing movies and music]
* xref:installing-and-running-vlc.adoc[Installing and running the VLC player]
* xref:configuring-ip-networking-with-nmcli.adoc[Configuring networking with NetworkManager CLI (nmcli)]
* xref:creating-a-disk-partition-in-linux.adoc[Creating disk partitions]
* xref:bumblebee.adoc[NVIDIA Optimus Bumblebee]
* xref:raspberry-pi.adoc[Raspberry Pi]
* xref:repositories.adoc[Fedora Repositories]
* xref:adding-or-removing-software-repositories-in-fedora.adoc[Adding or removing software repositories in Fedora]
* xref:reset-root-password.adoc[Resetting a root password]
* xref:creating-rpm-packages.adoc[Creating RPM packages]
* xref:create-hello-world-rpm.adoc[Creating a GNU Hello World RPM Package]
* xref:getting-started-with-selinux.adoc[Getting started using SELinux]
* xref:changing-selinux-states-and-modes.adoc[Changing SELinux states and modes]
* xref:troubleshooting_selinux.adoc[Troubleshooting SELinux]
* xref:using-shared-system-certificates.adoc[Using shared system certificates]
* xref:installing-software-from-source.adoc[Installing software from source code]
* xref:installing-spotify.adoc[Installing Spotify on Fedora]
* xref:performing-administration-tasks-using-sudo.adoc[Performing administration tasks using sudo]
* xref:understanding-and-administering-systemd.adoc[Understanding and administering systemd]
* xref:displaying_user_prompt_on_gnome_login_screen.adoc[Displaying a user prompt on the GNOME login screen]
* xref:installing-virtual-systems-with-gnome-boxes.adoc[Installing virtual operating systems with GNOME Boxes]
* xref:qemu.adoc[Using virtualization emulation in QEMU]
* xref:getting-started-with-virtualization.adoc[Getting started with virtualization (libvirt)]
* xref:using-nested-virtualization-in-kvm.adoc[Using nested virtualization in KVM]
* xref:creating-windows-virtual-machines-using-virtio-drivers.adoc[Creating Windows virtual machines using virtIO drivers]
* xref:wine.adoc[Running Windows applications with Wine]
* xref:configuring-x-window-system-using-the-xorg-conf-file.adoc[Configuring X Window System using the xorg.conf file]
* xref:configuring-xorg-as-default-gnome-session.adoc[Configuring X.org as the default GNOME session]

View file

@ -0,0 +1,17 @@
////
This message needs to be included on any document referencing third party software
repositories. Add the following line verbatim to the top of any such document:
include::{partialsdir}/3rdparty-message.adoc[]
Please do not change this message without consultation. Thanks!
////
[CAUTION]
====
This page discusses third-party software sources not officially affiliated with or endorsed by the Fedora Project.
Use them at your own discretion.
Fedora recommends the use of free and open source software and avoidance of software encumbered by patents.
====

View file

@ -0,0 +1,13 @@
[[how-does-lack-of-whql-signature-affect-use-of-these-drivers]]
How does lack of WHQL signature affect use of these drivers?
IXME: Lack of WHQL signature on virtio-win packages causes Windows to complain, need to explicitly document how.
The RPMs from the stable repository are the same driver builds as what
is shipped in Red Hat Enterprise Linux. However, the public drivers are not signed with
https://msdn.microsoft.com/en-us/library/windows/hardware/ff553976%28v=vs.85%29.aspx[Microsoft's
WHQL signature].
F

View file

@ -0,0 +1,7 @@
:MAJOROSVER: 27
:WRPM: link:https://docs.fedoraproject.org/quick-docs/en-US/creating-rpm-packages.html
:WPACKAGE: link:https://fedoraproject.org/wiki/Join_the_package_collection_maintainers[How to join the Fedora Package Collection Maintainers]
:RPMSCHAT: https://fedoraproject.org/wiki/Building_RPM_packages_(20090405)
:MOCKTEST: https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds
:KOJIBUILD: https://fedoraproject.org/wiki/Using_the_Koji_build_system
:YUM: https://fedoraproject.org/wiki/Yum

View file

@ -0,0 +1,122 @@
// Module included in the following assemblies:
//
// assembly_Configuring-networking-with-nmcli.adoc
[id='Getting-started-with-nmcli']
= Getting started with nmcli
The [application]*nmcli* (NetworkManager Command Line Interface) command-line utility is used for controlling NetworkManager and reporting network status. It can be utilized as a replacement for [application]*nm-applet* or other graphical clients. [application]*nmcli* is used to create, display, edit, delete, activate, and deactivate network connections, as well as control and display network device status.
The [application]*nmcli* utility can be used by both users and scripts for controlling [application]*NetworkManager*:
* For servers, headless machines, and terminals, [application]*nmcli* can be used to control [application]*NetworkManager* directly, without GUI, including creating, editing, starting and stopping network connections and viewing network status.
* For scripts, [application]*nmcli* supports a terse output format which is better suited for script processing. It is a way to integrate network configuration instead of managing network connections manually.
The basic format of a [application]*nmcli* command is as follows:
[literal,subs="+quotes,verbatim"]
....
nmcli [OPTIONS] OBJECT { COMMAND | help }
....
where OBJECT can be one of the following options: `general`, `networking`, `radio`, `connection`, `device`, `agent`, and `monitor`. You can use any prefix of these options in your commands. For example, [command]`nmcli con help`, [command]`nmcli c help`, [command]`nmcli connection help` generate the same output.
Some of useful optional OPTIONS to get started are:
-t, terse::
+
This mode can be used for computer script processing as you can see a terse output displaying only the values.
+
[[ex-Viewing_a_terse_output_for_scripts]]
.Viewing a terse output
====
[literal,subs="+quotes,verbatim,macros"]
....
~]$ pass:attributes[{blank}][command]`nmcli -t device`
ens3:ethernet:connected:Profile 1
lo:loopback:unmanaged:
....
====
-f, field::
+
This option specifies what fields can be displayed in output. For example, NAME,UUID,TYPE,AUTOCONNECT,ACTIVE,DEVICE,STATE. You can use one or more fields. If you want to use more, do not use space after comma to separate the fields.
+
[[ex-Specifying_Fields_in_the_output]]
.Specifying Fields in the output
====
[literal,subs="+quotes,verbatim,macros"]
....
~]$ pass:attributes[{blank}][command]`nmcli -f DEVICE,TYPE device`
DEVICE TYPE
ens3 ethernet
lo loopback
....
or even better for scripting:
[literal,subs="+quotes,verbatim,macros"]
....
~]$ pass:attributes[{blank}][command]`nmcli -t -f DEVICE,TYPE device`
ens3:ethernet
lo:loopback
....
====
-p, pretty::
+
This option causes [application]*nmcli* to produce human-readable output. For example, values are aligned and headers are printed.
+
[[ex-Viewing_an_output_in_pretty_Mode]]
.Viewing an output in pretty mode
====
[literal,subs="+quotes,verbatim,macros"]
....
~]$ pass:attributes[{blank}][command]`nmcli -p device`
=====================
Status of devices
=====================
DEVICE TYPE STATE CONNECTION
--------------------------------------------------------------
ens3 ethernet connected Profile 1
lo loopback unmanaged --
....
====
-h, help::
+
Prints help information.
The [application]*nmcli* tool has some built-in context-sensitive help. To list the available options and object names:
[literal,subs="+quotes,verbatim,macros"]
....
~]$ [command]`nmcli help`
....
To list available actions related to a specified object:
[literal,subs="+quotes,verbatim,macros"]
....
~]$ [command]`nmcli _object_ help`
....
For example,
[literal,subs="+quotes,verbatim,macros"]
....
~]$ [command]`nmcli c help`
....
[discrete]
== Additional resources
* link:++https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-introduction_to_networkmanager++[Introduction to NetworkManager]
* link:++https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-installing_networkmanager#sec-Interacting_with_NetworkManager[Interacting with NetworkManager]

View file

@ -0,0 +1,65 @@
// Module included in the following assemblies:
//
// assembly_Configuring-networking-with-nmcli.adoc
[id='Understanding-the-nmcli-options']
= The nmcli options
Following are some of the important [application]*nmcli* property options:
[option]`connection.type`::
+
A connection type. Allowed values are: adsl, bond, bond-slave, bridge, bridge-slave, bluetooth, cdma, ethernet, gsm, infiniband, olpc-mesh, team, team-slave, vlan, wifi, wimax. Each connection type has type-specific command options. For example:
+
** A `gsm` connection requires the access point name specified in an [option]`apn`.
+
[literal,subs="+quotes,verbatim,macros"]
....
nmcli c add connection.type gsm apn pass:quotes[_access_point_name_]
....
+
** A `wifi` device requires the service set identifier specified in a [option]`ssid`.
+
[literal,subs="+quotes,verbatim,macros"]
....
nmcli c add connection.type wifi ssid
_My identifier_
....
You can see the `TYPE_SPECIFIC_OPTIONS` list in the [citetitle]_pass:attributes[{blank}]*nmcli*(1)_ man page.
[option]`connection.interface-name`::
+
A device name relevant for the connection.
+
[literal,subs="+quotes,verbatim,macros"]
....
nmcli con add connection.interface-name _eth0_ type _ethernet_
....
[option]`connection.id`::
+
A name used for the connection profile. If you do not specify a connection name, one will be generated as follows:
+
[literal,subs="+quotes,verbatim,macros"]
....
_connection.type -connection.interface-name_
....
+
The [option]`connection.id` is the name of a _connection profile_ and should not be confused with the interface name which denotes a device (`wlan0`, `ens3`, `em1`). However, users can name the connections after interfaces, but they are not the same thing. There can be multiple connection profiles available for a device. This is particularly useful for mobile devices or when switching a network cable back and forth between different devices. Rather than edit the configuration, create different profiles and apply them to the interface as needed. The [option]`id` option also refers to the connection profile name.
The most important options for [application]*nmcli* commands such as `show`, `up`, `down` are:
[option]`id`::
+
An identification string assigned by the user to a connection profile. Id can be used in nmcli connection commands to identify a connection. The NAME field in the command output always denotes the connection id. It refers to the same connection profile name that the con-name does.
[option]`uuid`::
+
A unique identification string assigned by the system to a connection profile. The `uuid` can be used in [command]`nmcli connection` commands to identify a connection.
[discrete]
== Additional resources
* See the comprehensive list in the [citetitle]_pass:attributes[{blank}]*nmcli*(1)_ man page.

View file

@ -0,0 +1,10 @@
[id='about-java']
= About Java
Java is a popular programming language that allows you run programs on many platforms, including Fedora. If you want to create Java programs, you need to install a JDK (Java Development Kit). If you want to run a Java program, you can do that on a JVM (Java Virtual Machine), which is provided with the JRE (Java Runtime Environment). If in doubt, install the JDK because this is sometimes required even if the intention is not to write Java programs.
Many flavors of Java exist and also many versions of each flavor. If you want to just run a specific application, check the documentation of that software to see what versions of Java are supported or have been tested. Most Java applications run on one of the following:
* OpenJDK -- an open-source implementation of the Java Platform, Standard Edition
* Oracle Java SE -- a free JDK from Oracle

View file

@ -0,0 +1,29 @@
// Module included in the following assemblies:
//
// getting-started-with-selinux.adoc
:experimental:
[#{context}-benefits-of-selinux]
= Benefits of running SELinux
SELinux provides the following benefits:
* All processes and files are labeled. SELinux policy rules define how processes interact with files, as well as how processes interact with each other. Access is only allowed if an SELinux policy rule exists that specifically allows it.
* Fine-grained access control. Stepping beyond traditional UNIX permissions that are controlled at user discretion and based on Linux user and group IDs, SELinux access decisions are based on all available information, such as an SELinux user, role, type, and, optionally, a security level.
* SELinux policy is administratively-defined and enforced system-wide.
* Improved mitigation for privilege escalation attacks. Processes run in domains, and are therefore separated from each other. SELinux policy rules define how processes access files and other processes. If a process is compromised, the attacker only has access to the normal functions of that process, and to files the process has been configured to have access to. For example, if the Apache HTTP Server is compromised, an attacker cannot use that process to read files in user home directories, unless a specific SELinux policy rule was added or configured to allow such access.
* SELinux can be used to enforce data confidentiality and integrity, as well as protecting processes from untrusted inputs.
However, SELinux is not:
* antivirus software,
* replacement for passwords, firewalls, and other security systems,
* all-in-one security solution.
SELinux is designed to enhance existing security solutions, not replace them. Even when running SELinux, it is important to continue to follow good security practices, such as keeping software up-to-date, using hard-to-guess passwords, or firewalls.

View file

@ -0,0 +1,13 @@
// Module included in the following assemblies:
//
// firewalld.adoc
[id='controlling-ports-firewalld-fedora']
= Controlling ports using firewalld
== What are ports?
Ports are logical devices that enable an operating system to receive and distinguish network traffic and forward it accordingly to system services. These are usually represented by a daemon that listens on the port, that is it waits for any traffic coming to this port.
Normally, system services listen on standard ports that are reserved for them. The httpd daemon, for example, listens on port 80. However, system administrators may configure daemons to listen on different ports to enhance security.

View file

@ -0,0 +1,9 @@
// Module included in the following assemblies:
//
// creating-a-disk-partition-in-linux-using-the-parted-command.adoc
:experimental:
[#{context}-disk-partition-linux]
= Disk Partitioning in Linux
Creating and deleting partitions in Linux is a regular practice because storage devices (such as hard drives and USB drives) must be structured in some way before they can be used. In most cases, large storage devices are divided into separate sections called partitions. Partitioning also allows you to divide your hard drive into isolated sections, where each section behaves as its own hard drive. Partitioning is particularly useful if you run multiple operating systems.

View file

@ -0,0 +1,22 @@
// Module included in the following assemblies:
//
// firewalld.adoc
[id='concept-firewalld-fedora']
= Using firewalld
== What is firewalld?
A _firewall_ is a way to protect machines from any unwanted traffic from outside. It enables users to control incoming network traffic on host machines by defining a set of _firewall rules_. These rules are used to sort the incoming traffic and either block it or allow through.
`firewalld` is a firewall service daemon that provides a dynamic customizable host-based firewall with a `D-Bus` interface. Being dynamic, it enables creating, changing, and deleting the rules without the necessity to restart the firewall daemon each time the rules are changed.
`firewalld` uses the concepts of _zones_ and _services_, that simplify the traffic management.
`_Zones_` are predefined sets of rules. Network interfaces and sources can be assigned to a zone. The traffic allowed depends on the network your computer is connected to and the security level this network is assigned. Firewall services are predefined rules that cover all necessary settings to allow incoming traffic for a specific service and they apply within a zone.
`_Services_` use one or more ports or addresses for network communication. Firewalls filter communication based on ports. To allow network traffic for a service, its ports must be open. `firewalld` blocks all traffic on ports that are not explicitly set as open. Some zones, such as trusted, allow all traffic by default.
.Additional resources
For more information about using firewalld and configuring zones and services, see link:https://firewalld.org/documentation/[firewalld documentation] or link:https://fedoraproject.org/wiki/Firewalld[Fedora wiki:firewalld]

View file

@ -0,0 +1,39 @@
// Module included in the following assemblies:
//
// getting-started-with-selinux.adoc
[#{context}-introduction-to-selinux]
= Introduction to SELinux
Security Enhanced Linux (SELinux) provides an additional layer of system security. SELinux fundamentally answers the question: _May <subject> do <action> to <object>?_, for example: _May a web server access files in users' home directories?_
The standard access policy based on the user, group, and other permissions, known as Discretionary Access Control (DAC), does not enable system administrators to create comprehensive and fine-grained security policies, such as restricting specific applications to only viewing log files, while allowing other applications to append new data to the log files.
SELinux implements Mandatory Access Control (MAC). Every process and system resource has a special security label called a _SELinux context_. A SELinux context, sometimes referred to as a _SELinux label_, is an identifier which abstracts away the system-level details and focuses on the security properties of the entity. Not only does this provide a consistent way of referencing objects in the SELinux policy, but it also removes any ambiguity that can be found in other identification methods; for example, a file can have multiple valid path names on a system that makes use of bind mounts.
The SELinux policy uses these contexts in a series of rules which define how processes can interact with each other and the various system resources. By default, the policy does not allow any interaction unless a rule explicitly grants access.
[NOTE]
====
It is important to remember that SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first, which means that no SELinux denial is logged if the traditional DAC rules prevent the access.
====
SELinux contexts have several fields: user, role, type, and security level. The SELinux type information is perhaps the most important when it comes to the SELinux policy, as the most common policy rule which defines the allowed interactions between processes and system resources uses SELinux types and not the full SELinux context. SELinux types usually end with `_t`. For example, the type name for the web server is `httpd_t`. The type context for files and directories normally found in `/var/www/html/` is `httpd_sys_content_t`. The type contexts for files and directories normally found in `/tmp` and `/var/tmp/` is `tmp_t`. The type context for web server ports is `http_port_t`.
For example, there is a policy rule that permits Apache (the web server process running as `httpd_t`) to access files and directories with a context normally found in `/var/www/html/` and other web server directories (`httpd_sys_content_t`). There is no allow rule in the policy for files normally found in `/tmp` and `/var/tmp/`, so access is not permitted. With SELinux, even if Apache is compromised, and a malicious script gains access, it is still not able to access the `/tmp` directory.
[#fig-intro-httpd-mysqld]
.SELinux allows the Apache process running as httpd_t to access the /var/www/html/ directory and it denies the same process to access the /data/mysql/ directory because there is no allow rule for the httpd_t and mysqld_db_t type contexts). On the other hand, the MariaDB process running as mysqld_t is able to access the /data/mysql/ directory and SELinux also correctly denies the process with the mysqld_t type to access the /var/www/html/ directory labeled as httpd_sys_content_t.
image::../images/selinux-intro-apache-mariadb.png[SELinux_Apache_MariaDB_example]
[discrete]
== Additional resources
To better understand SELinux basic concepts, see the following documentation:
* link:++https://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf++[The SELinux Coloring Book]
* link:++https://people.redhat.com/tcameron/Summit2012/SELinux/cameron_w_120_selinux_for_mere_mortals.pdf++[SELinux for Mere Mortals]
* link:++http://selinuxproject.org/page/FAQ++[SELinux Wiki FAQ]
* link:++http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf++[The SELinux Notebook]

View file

@ -0,0 +1,21 @@
[id="concept-logging-sudo-commands"]
= Logging sudo commands
Each successful authentication using the [command]`sudo` command is logged to the [filename]`/var/log/messages` file. For each authentication, the [filename]`/var/log/secure` file lists the user name and the command that was executed.
For additional logging, use the `pam_tty_audit` module to enable TTY auditing for specific users. TTY auditing prints the file name of the terminal connected to the standard I/O. To enable TTY auditing, add the following line to your [filename]`/etc/pam.d/system-auth` file:
[subs=quotes]
----
session required pam_tty_audit.so disable=pattern enable=_PATTERN_
----
Replace `_PATTERN_` with a comma-separated list of users (and globs, if needed).
For example, the following command enables TTY auditing for the root user and disables it for all other users:
----
session required pam_tty_audit.so disable=* enable=root
----
Using the `pam_tty_audit` PAM module for auditing only records TTY input. As a result, when the audited user logs in, `pam_tty_audit` records the users exact keystrokes and saves them in [filename]`/var/log/audit/audit.log`. For more information, see the *pam_tty_audit(8)* manual page.

View file

@ -0,0 +1,57 @@
[[package-management-in-fedora]]
= Package management in Fedora
Like most modern Linux distributions, Fedora uses a _package management_ system. Package management tools automate installation, upgrading, and removing of software applications and components.
Each application or component is defined as a _package_. When the package is installed, all code, configuration, and other files are deployed on the system.
IMPORTANT: A single package is not necessarily the same as an application. Some applications can be shipped as several packages. Moreover, shared code (libraries) in Linux is normally shipped as separate packages, while in other systems applications often ship their own versions of required libraries and install them if necessary.
== File placement
The package management tools track which files on your Fedora installation belong to each package; normally, every file that is installed in the `/usr` tree as well as most configuration files under `/etc` are installed by one of the packages. When installing a package, the package management system verifies its integrity; if any files are missing or corrupted, the package is not installed.
== Resolving dependencies
The package management system also tracks all _dependencies_ between the packages. For example, if an application requires some libraries, the package for this application lists the libraries as dependencies. When you install the application package, the package management tools automatically install the library packages. If a dependency is not available, the tools do not install the package, so you can avoid a sudden malfunction.
When you want to remove a package, package management tools cleanly delete all code files for this package without affecting other packages. By default, configuration files are not removed, so you can install the package again and keep the configuration that you have set up earlier.
== Updating packages
Updating any package is entirely automatic with the package management system. The system replaces all the necessary code files and preserves existing configuration.
In fact, for most Linux distributions, including Fedora, all of the system installation except the earliest part is performed by installing various packages. Security updates and upgrades to a next release are performed entirely by package management tools.
== RPM
Fedora's package management system uses the http://rpm.org[RPM] package format. The application that manages packages in Fedora (since version 22) is https://fedoraproject.org/wiki/DNF[DNF]. Graphical package management is provided by the Gnome Software utility. For automatic updates, Fedora uses the PackageKit utility. Command-line and graphical tools provide the same results.
== Repositories
To get packages, DNF uses _repositories_. A repository is an organized collection of packages. Repositories can be kept on any data media; notably, the Fedora installation image contains a repository. However, most up-to-date repositories are normally maintained online.
Each Fedora release has an official _fedora_ repository and an _updates_ repository (which contains critical updates since the release). In these repositories, you can find most common Linux open-source software. You can also install packages from other repositories, not maintained by the Fedora project and known as _third-party repositories_.
Most of the time, it is best practice to install software on your Fedora Linux system using only the Fedora package management system. In this case, packages are installed in the most reliable way and automatic updates can be provided.
== Installing from source code
While many Linux applications can be built and installed from from source code, using such builds can make your system much harder to manage. For example, automatic updates to system packages (especially when updating to the next release) might impact an application that was installed from source. And, of course, no automatic security updates are available for the application.
== Other installation methods
Sometimes you might need to install software using other package management systems. Notably:
* https://www.cpan.org/[CPAN] for libraries for the Perl language
* https://pypi.python.org/pypi[PyPI] for libraries (and sometimes applications) for the Python language
* Commercial repositories for games
However, installing applications using the Fedora package management systems is the preferred option.

View file

@ -0,0 +1,32 @@
// Module included in the following assemblies:
//
// changing-selinux-states-and-modes.adoc
[#{context}-changing-selinux-modes]
= Permanent changes in SELinux states and modes
As discussed in link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/chap-security-enhanced_linux-introduction[Introduction to SELinux], SELinux can be enabled or disabled. When enabled, SELinux has two modes: enforcing and permissive.
Use the [command]`getenforce` or [command]`sestatus` commands to check in which mode SELinux is running. The [command]`getenforce` command returns `Enforcing`, `Permissive`, or `Disabled`.
The [command]`sestatus` command returns the SELinux status and the SELinux policy being used:
[source,bash]
----
~]$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 31
----
[NOTE]
====
When systems run SELinux in permissive mode, users are able to label files incorrectly. Files created while SELinux is disabled are not labeled at all. This behavior causes problems when changing to enforcing mode because files are labeled incorrectly or are not labeled at all. To prevent incorrectly labeled and unlabeled files from causing problems, file systems are automatically relabeled when changing from the disabled state to permissive or enforcing mode.
====

View file

@ -0,0 +1,71 @@
[id='relation-between-fedora-and-red-hat-enterprise-linux']
= Relation between Fedora and Red Hat Enterprise Linux
Open source allows user to modify the software and make it redistributable as and when required. The open source license requires improved versions of the software to carry a different name or version from the original software. Red Hat Enterprise Linux, and Fedora both are open source products. If a product or a software is upstream that means it allows the origin author/s to maintain it or perform any bug fixes. Fedora is an upstream of Red Hat Enterprise Linux.
== Red Hat Enterprise Linux
Red Hat Enterprise Linux is a commercial enterprise operating system and has its own set of test phases including alpha and beta releases.The cost of Red Hat Enterprise Linux comes from the subscription,which provides assorted certifications and support for additional architectures. You can download the https://www.redhat.com/rhel/details/eval/[evaluation version] for free and https://www.redhat.com/apps/store/developers/rhel_developer_suite.html[developer version] for $99.
Download academic editions at low cost http://www.redhat.com/solutions/education/academic/[academic version] and
http://www.redhat.com/solutions/education/academic/individual/[academic individual version]
== Fedora
Fedora is based on Linux kernel and GNU programs. Fedora is developed and sponsored by Fedora Project and Red Hat. Fedora is a general purpose system that gives Red Hat and the rest of its contributor community the chance to innovate rapidly with new technologies. In order to focus Red Hat's efforts and limit support costs, only a selected subset of packages found in Fedora are included in the commercially supported product line. The Fedora Project has a community of people maintaining add-on packages for Red Hat Enterprise Linux and compatible rebuilds called https://fedoraproject.org/wiki/About_EPEL[Extra Packages for Enterprise Linux], or EPEL.
== History of Red Hat Enterprise Linux and Fedora
Red Hat first offered an enterprise Linux support subscription for Red Hat Linux 6.1. It was not a separate product but the subscription level was branded as Red Hat 6.2E. Subsequently, Red Hat started creating a separate product with commercial service level agreements and longer
lifecyle based on Red Hat Linux and later on Fedora. This was initially called as Advanced Server and rebranded as Red Hat Enterprise Linux in 2003. The following table gives the lineage:
.Red Hat Enterprise Linux and Fedora Lineage
[options="header"]
|=======================================================================
|Release |Codename |Release Date |Based on
|Red Hat Linux 6.2E |Zoot |2000-03-27 |Red Hat Linux 6.2
|Red Hat Enterprise Linux 2.1 |Pensacola (AS)/ Panama (ES) |2002-03-26
(AS) |Red Hat Linux 7.2
|Red Hat Enterprise Linux 3 |Taroon |2003-10-22 |Red Hat Linux 9
|Red Hat Enterprise Linux 4 |Nahant |2005-02-15 |Fedora Core 3
|Red Hat Enterprise Linux 5 |Tikanga |2007-03-14 |Fedora Core 6
|Red Hat Enterprise Linux 6 |Santiago |2010-11-10 |Mix of Fedora 12
Fedora 13 and several modifications
|Red Hat Enterprise Linux 7 |Maipo |2014-06-10 |Primarily Fedora 19 with
several changes from 20 and later
|=======================================================================
== Difference between Red Hat Enterprise Linux and Fedora
When you purchase Red Hat Enterprise Linux, you are also helping to support Fedora. Since Red Hat sponsors Fedora, what is good for Red Hat is usually good for Fedora. However, following are few differences between both the products:
.Difference between Red Hat Enterprise Linux and Fedora
[cols="1,3,3",options="header"]
|===
|
|Red Hat Enterprise Linux
|Fedora
|support
|Red Hat Enterprise Linux is a commercially supported product by Red Hat and provides service level agreements that is important for enterprise customers. This support involves product assistance as well as prioritization of bug fixes, feature requests, certified hardware and software.
|Fedora is supported by a wide community of developers and users but it is not commercially supported by Red Hat. Red Hat does http://fedoraproject.org/sponsors[sponsor] a large number of resources and link.
|releases
|A new version of Red Hat Enterprise Linux comes out every few years and is supported for up to 10 years and can
even be http://www.redhat.com/rhel/server/extended_lifecycle_support/[extended] to 13 years or more with additional subscriptions.
|New Fedora releases are available about every six months and every release gets updates for about 13 months.
|available software
|Software in Red Hat Enterprise Linux is a limited subset of Fedora and has about 4000 binary packages (RHEL 6). These are the ones enterprise customers demand and are supported by Red Hat.
|Fedora offers a wide range of software packages and the latest release has well over 25000 unique (not counting updates in Fedora 15) binary software packages available in the repository.
|update policy
|Red Hat Enterprise Linux updates are more conservative and generally focus on security and bug fixes.
|Fedora's Updates Policy is more liberal compared to Red Hat Enterprise Linux.
|===

View file

@ -0,0 +1,49 @@
[[rpm-packaging-overview]]
= RPM Packaging Overview
Use this guide to create RPM packages and `.spec` files. Despite the focus on Fedora, you can apply much of this document to other RPM-based distributions.
NOTE: For a general-purpose RPM building guide for packagers on Fedora, CentOS, and Red Hat Enterprise Linux, see the https://rpm-packaging-guide.github.io/[RPM Packaging Guide].
For more information about packaging guidelines, see the following guides:
* https://fedoraproject.org/wiki/Packaging:Guidelines[Packaging Guidelines]
* http://fedoraproject.org/wiki/Packaging:LicensingGuidelines[Licensing Guidelines]
* http://fedoraproject.org/wiki/Packaging:Naming[Package Naming Guidelines]
* http://fedoraproject.org/wiki/Packaging:DistTag[Dist Tag Guidelines]
* http://fedoraproject.org/wiki/Packaging:ReviewGuidelines[Package Review Guidelines]
* http://fedoraproject.org/wiki/Packaging:Scriptlets[Recipes for RPM scriptlets]
If you plan to submit a package to the official Fedora repository, follow the procedure in http://fedoraproject.org/wiki/Join_the_package_collection_maintainers[Join the package collection maintainers].
Before you begin, select a text editor that you want to use, and ensure that you understand the following terminology.
[[rpm-terminology]]
== RPM terminology
RPM::
The package manager used by Fedora, Red Hat Enterprise Linux, Mageia, OpenSUSE and others. Originally RPM stood for "Red Hat Package Manager" but now it is a recursive acronym "RPM Package Manager".
spec file::
A plain text file that contains information about a package and instructions that RPM uses for compiling the package's software. To name the file, use the name of the package with the file extension `.spec`.
tag::
A string, generally capitalized and followed by a colon, which appears at the top of the `.spec` file to provide some important data about the RPM, such as `Name:`, `Version:` or `Summary:`.
section::
A segment of the `.spec` file that tells RPM how to perform some portion of the package construction process. Many, but not all, sections contain code that is simply passed to the shell, though RPM has significant flexibility around this that is outside of the scope of this document.
section header::
A short string, starting with `%` at the beginning of a line, which introduces a section. Examples include `%description`, `%prep` and `%files`.
macro::
A short string, always prefixed by `%` and generally surrounded by curly brackets `{}` which RPM converts to a different and usually longer string. Some macros can take arguments and some arguments are quite complex. Some macros are provided by RPM, some are part of https://apps.fedoraproject.org/packages/redhat-rpm-config[redhat-rpm-config] and https://apps.fedoraproject.org/packages/fedora-rpm-macros[fedora-rpm-macros] packages, but many other packages also provide macros. You can run `rpm --showrc` to view all of the macros currently available on your system, but you do not need to run most of the macros you see there.
+
For a full list of guidelines related to macros, see http://fedoraproject.org/wiki/Packaging:Guidelines#Macros[Macros] in the Packaging Guidelines.
mock::
A system for building RPMs locally within your own Fedora installation. This avoids the need to install a full set of build dependencies on your operating system installation, and allows you to build packages for different Fedora releases.
koji::
The main Fedora build system: https://koji.fedoraproject.org[1].

View file

@ -0,0 +1,106 @@
[[con_rpm-spec-file-overview]]
= RPM spec file overview
Use this guide for information about the specific macros in a `.spec` file.
NOTE: You can use the macros `%{name}`, `%{version}` and `%{release}` to refer to the Name, Version and Release tags respectively. When you change the tag, the macros automatically update to use the new value.
`Name`::
Add the base name of the package, which must match the `.spec` file name. Follow the http://fedoraproject.org/wiki/Packaging:Naming[Package Naming Guidelines] and write the file name in lower-case letters.
`Version`::
Add the upstream version number. See http://fedoraproject.org/wiki/Packaging:Versioning[Package Versioning]. If the version contains tags that are non-numeric, you might need to include the non-numeric characters in the `Release` tag. If upstream uses full dates to distinguish versions, consider using version numbers of the form. For example, `yy.mm[dd]` where `2008-05-01` becomes `8.05`.
`Release`::
Set the initial value to `1%{?dist}`. Increment the number every time you release a new package for the same version of software. When a new upstream version is released, change the `Version` tag to match and reset the `Release` number to `1`. For more information, see the http://fedoraproject.org/wiki/Packaging:Versioning[Versioning Guide] of the packaging guidelines.
`Summary`::
Enter a brief, one-line summary of the package. Use American English. Do not end with a period.
`Group`::
This tag is deprecated since Fedora 17. See https://docs-old.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/chap-Packagers_Guide-Spec_File_Reference-Preamble.html[Spec
File Reference Preamble]
`License`::
Enter an open source software license. Do not use the old Copyright tag. Use a standard abbreviation, for example, `GPLv2+` and be specific. For example, use `GPLv2+` for GPL version 2 or greater rather than `GPL` or `GPLv2` where it's true). For more information, see the http://fedoraproject.org/wiki/Packaging:LicensingGuidelines[Licensing Guidelines].
+
You can list multiple licenses by combining them with `and` and `or` (e.g. `GPLv2 and BSD`).
`URL`::
The full URL for more information about the program. For example, the project website.
+
NOTE: Do not add a link to the original source code. Add the link to the source code to the `Source0` tag.
`Source0`::
Enter the full URL for the compressed archive that contains the original, pristine source code, as upstream released it. "`Source`" is synonymous with "`Source0`".
+
The full URL basename is used when looking in the `SOURCES` directory. If possible, embed `%{name}` and `%{version}`, so that changes to the go to the right place. Preserve the timestamps when downloading source files. For more information, see http://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps[Preserve timestamps].
+
If there is more than one source, name them `Source1`, `Source2`.
+
If you add whole new files in addition to the pristine sources, list them as sources after the pristine sources. A copy of each of these sources is included in any source RPM (SRPM) you create, unless you specifically direct otherwise. For more information on special cases, for example, revision control, see https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL[Source URL].
`Patch0`::
Enter the name of the first patch to apply to the source code. If you must patch the files after you extract them, edit the files and save their differences as a `.patch` file in your `~/rpmbuild/SOURCES` directory. Patches must make only one logical change each, so it's quite possible to have multiple patch files.
`BuildArch`::
If you package files that are architecture-independent, for example shell scripts, data files, then add `BuildArch: noarch`. The architecture for the binary RPM is then `noarch`.
`BuildRoot`::
This is now redundant in Fedora and is only needed for EPEL5. By default, the build root is placed in `%{_topdir}/BUILDROOT/`.
+
In EPEL5, this is where files are installed during the %install process (after the %build process).
`BuildRequires`::
Add a comma-separated list of packages that are required for compiling the program. Usually, this field is repeated on multiple lines. These dependencies are not automatically determined. You must include everything that the package needs to build the program.
+
Verify that you have specified all the necessary build requirements by performing a "mock build" of your package. You can specify a minimum version if necessary, for example, `ocaml >= 3.08`.
+
If you need the file `/EGGS`, determine the package that owns it by running `rpm -qf /EGGS`.
+
If you need the program `EGGS`, determine the package that owns it by running `rpm -qf \`which EGGS\``. Keep dependencies to a minimum. For example, use `sed` instead of `perl` if you do not need Perl, but note that some applications permanently disable functions if the associated dependency is not present; in those cases you might need to include the additional packages.
`Requires`::
Enter a comma-separate list of packages that are required when the program is installed. Note that the `BuildRequires` tag lists what is required to build the binary RPM, while the `Requires` tag lists what is required when installing and running the program; a package may be in one list or in both.
`%description`::
Enter a longer, multi-line description of the program. Use American English. All lines must be 80 characters or less. Blank lines indicate a new paragraph.
+
Some graphical user interface installation programs reformat paragraphs; lines that start with whitespace might be treated as preformatted text and displayed as is, normally with a fixed-width font.
`%prep`::
Add script commands to "prepare" the program. For example, to extract the program, so that it is ready for building. Typically this is just `%autosetup`; a common variation is `%autosetup -n NAME` if the source file unpacks into `NAME`.
`%build`::
Add script commands to compile the program and get it ready for installing. The program must come with instructions on how to do this.
`%install`::
Add script commands to "install" the program. The commands must copy the files from the `BUILD` directory `%{_builddir}` into the buildroot directory, `%{buildroot}`.
`%check`::
Add script commands to "test" the program. This is run after the `%install` procedure, so place it there if you have this section. Often it contains `make test` or `make check`. This is separated from `%build` so that people can skip the self-test if they desire.
`%clean`::
Note that this section is now redundant in Fedora and is only necessary for EPEL. Typically this contains only the following command: `rm -rf %{buildroot}`.
`%files`::
Add the list of files to be installed.
`%changelog`::
Add changes in the package. Use the format example above. Do not put software's change log here. This change log is only for the RPM.
`ExcludeArch`::
If the package does not successfully compile, build or work on a particular architecture, list those architectures under this tag.
RPM also supports the creation of several packages called subpackages from a single `.spec` file, such as `name-libs` and `name-devel` packages.
Do *not* create a "relocatable" package; they do not add value in Fedora and make things more complicated.
.Inserting comments
* Insert comments with a leading `#` character, and beware of macros (beginning with `%`) that are potentially multi-line, as they are expanded first.
* When commenting out a line, double the percent signs (`%%`) of the macros appearing after the `#`.
* Avoid inline comments on the same line as script commands.

View file

@ -0,0 +1,15 @@
// Module included in the following assemblies:
//
// firewalld.adoc
[id='concept-runtime-and-permanent-firewalld-fedora']
= Runtime and permanent settings
Any changes made while firewalld is running will be lost when firewalld is restarted. When firewalld is restarted, the settings revert to their permanent values.
These changes are said to be made in _runtime mode_.
To make the changes persistent across reboots, apply them again using the `--permanent` option. Alternatively, to make changes persistent while firewalld is running, use the `--runtime-to-permanent _firewall-cmd_` option.
If you make changes while firewalld is running using only the `--permanent` option, they do not become effective until firewalld is restarted. However, restarting firewalld briefly stops the networking traffic, causing disruption to your system.

View file

@ -0,0 +1,11 @@
// Module included in the following assemblies:
//
// getting-started-with-selinux.adoc
:experimental:
[#{context}-selinux-architecture]
= SELinux architecture
SELinux is a Linux Security Module (LSM) that is built into the Linux kernel. The SELinux subsystem in the kernel is driven by a security policy which is controlled by the administrator and loaded at boot. All security-relevant, kernel-level access operations on the system are intercepted by SELinux and examined in the context of the loaded security policy. If the loaded policy allows the operation, it continues. Otherwise, the operation is blocked and the process receives an error.
SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). When using these cached decisions, SELinux policy rules need to be checked less, which increases performance. Remember that SELinux policy rules have no effect if DAC rules deny access first.

View file

@ -0,0 +1,19 @@
// Module included in the following assemblies:
//
// getting-started-with-selinux.adoc
:experimental:
[#{context}-selinux-examples]
= SELinux examples
The following examples demonstrate how SELinux increases security:
* The default action is deny. If an SELinux policy rule does not exist to allow access, such as for a process opening a file, access is denied.
* SELinux can confine Linux users. A number of confined SELinux users exist in SELinux policy. Linux users can be mapped to confined SELinux users to take advantage of the security rules and mechanisms applied to them. For example, mapping a Linux user to the SELinux `user_u` user, results in a Linux user that is not able to run (unless configured otherwise) set user ID (setuid) applications, such as [command]`sudo` and [command]`su`, as well as preventing them from executing files and applications in their home directory. If configured, this prevents users from executing malicious files from their home directories.
* Increased process and data separation. Processes run in their own domains, preventing processes from accessing files used by other processes, as well as preventing processes from accessing other processes. For example, when running SELinux, unless otherwise configured, an attacker cannot compromise a Samba server, and then use that Samba server as an attack vector to read and write to files used by other processes, such as MariaDB databases.
* SELinux helps mitigate the damage made by configuration mistakes. Domain Name System (DNS) servers often replicate information between each other in what is known as a zone transfer. Attackers can use zone transfers to update DNS servers with false information. When running the Berkeley Internet Name Domain (BIND) as a DNS server in Fedora, even if an administrator forgets to limit which servers can perform a zone transfer, the default SELinux policy prevents zone files footnote:[Text files that include information, such as host name to IP address mappings, that are used by DNS servers.] from being updated using zone transfers, by the BIND `named` daemon itself, and by other processes.
* See the link:++http://www.networkworld.com++[NetworkWorld.com] article, link:++http://www.networkworld.com/article/2283723/lan-wan/a-seatbelt-for-server-software--selinux-blocks-real-world-exploits.html++[A seatbelt for server software: SELinux blocks real-world exploits]footnote:[Marti, Don. "A seatbelt for server software: SELinux blocks real-world exploits". Published 24 February 2008. Accessed 27 August 2009: link:++http://www.networkworld.com/article/2283723/lan-wan/a-seatbelt-for-server-software--selinux-blocks-real-world-exploits.html++[].], for background information about SELinux, and information about various exploits that SELinux has prevented.

View file

@ -0,0 +1,47 @@
// Module included in the following assemblies:
//
// getting-started-with-selinux.adoc
:experimental:
[#{context}-selinux-states-and-modes]
= SELinux states and modes
SELinux can run in one of three modes: disabled, permissive, or enforcing.
Disabled mode is strongly discouraged; not only does the system avoid enforcing the SELinux policy, it also avoids labeling any persistent objects such as files, making it difficult to enable SELinux in the future.
In permissive mode, the system acts as if SELinux is enforcing the loaded security policy, including labeling objects and emitting access denial entries in the logs, but it does not actually deny any operations. While not recommended for production systems, permissive mode can be helpful for SELinux policy development.
Enforcing mode is the default, and recommended, mode of operation; in enforcing mode SELinux operates normally, enforcing the loaded security policy on the entire system.
Use the [command]`setenforce` utility to change between enforcing and permissive mode. Changes made with [command]`setenforce` do not persist across reboots. To change to enforcing mode, enter the [command]`setenforce 1` command as the Linux root user. To change to permissive mode, enter the [command]`setenforce 0` command. Use the [command]`getenforce` utility to view the current SELinux mode:
----
~]# getenforce
Enforcing
----
----
~]# setenforce 0
~]# getenforce
Permissive
----
----
~]# setenforce 1
~]# getenforce
Enforcing
----
In Fedora, you can set individual domains to permissive mode while the system runs in enforcing mode. For example, to make the `httpd_t` domain permissive:
----
~]# semanage permissive -a httpd_t
----
// See <<sect-Security-Enhanced_Linux-Fixing_Problems-Permissive_Domains>> for more information.
// [NOTE]
// ====
// Persistent states and modes changes are covered in <<sect-Security-Enhanced_Linux-Working_with_SELinux-Changing_SELinux_Modes>>.
// ====

View file

@ -0,0 +1,15 @@
[[concept-sudo-timeout]]
= sudo timeout
By default, [command]`sudo` stores the password for a five minute timeout period. Any subsequent uses of the command during this period will not prompt you for a password. This could be exploited by an attacker if you leave your workstation unattended and unlocked while still being logged in. You can change this behavior by adding the following line to the `/etc/sudoers` configuration file:
[subs=quotes]
------------
Defaults timestamp_timeout=_VALUE_
------------
Here, `_VALUE_` is the desired timeout length in minutes. Setting the value to 0 causes [command]`sudo` to require a password every time.
If an account is compromised, an attacker can use [command]`sudo` to open a new shell with administrative privileges.
Opening a new shell as a root user in this way allows an attacker administrative access for a theoretically unlimited period of time and bypasses the timeout period specified in the `/etc/sudoers` file. Using this method, the attacker *does not* need to provide a password for [command]`sudo` again until the session ends.

View file

@ -0,0 +1,39 @@
// Module included in the following assemblies:
//
// <List assemblies here, each on a new line>
// This module can be included from assemblies using the following include statement:
// include::modules/<subsystem>/con_the-purpose-of-rpm-fusion.adoc[leveloffset=+1]
// The file name and the ID are based on the module title. For example:
// * file name: con_my-concept-module-a.adoc
// * ID: [id='con_my-concept-module-a_{context}']
// * Title: = My concept module A
//
// The ID is used as an anchor for linking to the module. Avoid changing
// it after the module has been published to ensure existing links are not
// broken.
//
// The `context` attribute enables module reuse. Every module's ID includes
// {context}, which ensures that the module has a unique ID even if it is
// reused multiple times in a guide.
//
// In the title, include nouns that are used in the body text. This helps
// readers and search engines find information quickly.
// Do not start the title with a verb. See also _Wording of headings_
// in _The IBM Style Guide_.
[id="con_the-purpose-of-rpm-fusion_{context}"]
= The purpose of RPM Fusion
The RPM Fusion project is community-maintained software repository providing additional packages that cannot be distributed in Fedora for legal reasons. Software patents apply to some of the packages in RPM Fusion, and as a consequence, it might not be legal to install these packages in certain countries: for example, in the United States or in Japan.
RPM Fusion also provides packages for Red Hat Enterprise Linux.
[discrete]
== Additional resources
* RPM Fusion home page: link:https://rpmfusion.org/[]
* For more information on what packages are allowed to be distributed with Fedora, see the following wiki page: link:https://fedoraproject.org/wiki/Forbidden_items[]
* You can buy multimedia codecs from Fluendo. This is a legal solution for users from countries where software patents apply. For more information, see: link:https://fluendo.com/en/products/enterprise/fluendo-codec-pack/[].

View file

@ -0,0 +1,51 @@
[id='understanding-systemd']
= Understanding systemd
systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides:
* Aggressive parallelization capabilities
* Uses socket and D-Bus activation for starting services
* Offers on-demand starting of daemons, keeps track of processes using Linux cgroups
* Supports snapshotting and restoring of the system state
* Maintains mount and automount points
* Implements an elaborate transactional dependency-based service control logic.
The `systemctl` command is the primary tool to manage systemd. It combines the functionality of SysVinit's `service` and `chkconfig` commands into a single tool you can use to enable and disable services permanently or only for the current session.
systemd manages _units_, which are representations of system resources and services. This following list shows the unit types that systemd can manage:
service::
A service on the system, including instructions for starting, restarting, and stopping the service.
socket::
A network socket associated with a service.
device::
A device specifically managed with systemd.
mount::
A mountpoint managed with systemd.
automount::
A mountpoint automatically mounted on boot.
swap::
Swap space on the system.
target::
A synchronization point for other units. Usually used to start enabled services on boot.
path::
A path for path-based activation. For example, you can start services based on the state of a certain path, such as whether it exists or not.
timer::
A timer to schedule activation of another unit.
snapshot::
A snapshot of the current systemd state. Usually used to rollback after making temporary changes to systemd.
slice::
Restrivtion of resources through Linux Control Group nodes (cgroups).
scope::
Information from systemd bus interfaces. Usually used to manage external system processes.

View file

@ -0,0 +1,8 @@
[id="concept-using-sudo-access-docker"]
= Using sudo to access Docker
Docker has the ability to change the group ownership of the Docker socket to allow users added to the Docker group to be able to run Docker containers without having to execute the [command]`sudo` or [command]`su` command to become root.
Enabling access to the Docker daemon from non-root users is a problem from a security perspective. It is a security issue for Fedora, because if a user can talk to the Docker socket they can execute a command which gives them full root access to the host system. Docker has no auditing or logging built in, while [command]`sudo` does.
It is recommended that sudo rules are implemented to permit access to the Docker daemon. This allows [command]`sudo` to provide logging and audit functionality.

View file

@ -0,0 +1,26 @@
[id="con_using-sudo-assign-admin-privileges"]
= Using sudo to assign administrator privileges
Add users to the [directory]`/etc/sudoers` configuration file to allow them to use the [command]`sudo` command. For these users, the [command]`sudo` command is run in the users shell instead of in a root shell. As a result, the root shell can be disabled for increased security.
The administrator can also allow different users access to specific commands using the sudo configuration. Administrators must use the [command]`visudo` command to edit the [directory]`/etc/sudoers` configuration file.
To assign full administrative privileges to a user, type [command]`visudo` and add the following line to the user privilege section after replacing `_USERNAME_` with the target user name:
[subs=quotes]
----
_USERNAME_ ALL=(ALL) ALL
----
This line allows the specified user to use [command]`sudo` from any host and execute any command.
To allow a user access to specific commands, use the following example after replacing `_USERS_` with a target system group:
[subs=quotes]
----
_%USERS_ localhost=/usr/sbin/shutdown -h now
----
This command allows all members of the `_USERS_` system group to issue the [command]`/sbin/shutdown -h` as long as the command is issued from the console.
The man page for [command]`sudoers` has a detailed listing of options for this file.

View file

@ -0,0 +1,13 @@
[[concept-using-sudo-without-password]]
= Using sudo without a password
You can enable `root` access without a password specified, allowing any process on your system to become `root`. Add the following line to your `/etc/sudoers` file:
[subs=quotes]
------------
_user_ ALL=(ALL) NOPASSWD: /usr/bin/docker
------------
This will allow `_user_` to access docker without a password.
IMPORTANT: For security reasons, it is recommended that you always use [command]`sudo` with a password.

View file

@ -0,0 +1,18 @@
[[using-the-system-wide-trust-store]]
= Using the System-wide Trust Store
In Fedora, the consolidated system-wide trust store is located in the `/etc/pki/ca-trust/` and `/usr/share/pki/ca-trust-source/` directories. The trust settings in `/usr/share/pki/ca-trust-source/` are processed with lower priority than settings in `/etc/pki/ca-trust/`.
Certificate files are treated depending on the subdirectory they are installed to the following directories:
* for trust anchors
** `/usr/share/pki/ca-trust-source/anchors/` or
** `/etc/pki/ca-trust/source/anchors/`
* for distrusted certificates
** `/usr/share/pki/ca-trust-source/blacklist/` or
** `/etc/pki/ca-trust/source/blacklist/`
* for certificates in the extended BEGIN TRUSTED file format
** `/usr/share/pki/ca-trust-source/` or
** `/etc/pki/ca-trust/source/`
NOTE: In a hierarchical cryptographic system, a trust anchor is an authoritative entity which is assumed to be trustworthy. For example, in X.509 architecture, a root certificate is a trust anchor from which a chain of trust is derived. The trust anchor must be put in the possession of the trusting party beforehand to make path validation possible.

View file

@ -0,0 +1,27 @@
[id='viewing-logs']
= Viewing logs
Log files contain messages about the system, including the kernel, services, and applications running on it. There are different log files for different information. For example, there is a default system log file, a log file for security messages, and a log file for cron tasks.
[id='locating-log-files']
== Locating log files
Most log files are located in the `/var/log/` directory.
`Rsyslog` is a system utility that provides support for logging. To install the _rsyslog_ package:
----
$ sudo dnf install rsyslog
----
To view a list of log files maintained by the related daemon, `rsyslogd`, enter the following command:
----
$ less /etc/rsyslog.conf
----
[id='viewing-log-files']
== Viewing log files
In Fedora, there are two ways to open the log files:
* The command line
* A GUI application

View file

@ -0,0 +1,15 @@
[id='con_what-is-sudo']
= What is sudo?
The [command]`sudo` command allows users to gain administrative or root access. When trusted users precede an administrative command with [command]`sudo`, they are prompted for their own password. Then, when they have been authenticated and assuming that the command is permitted, the administrative command is executed as if they were the root user.
Only users listed in the [filename]`/etc/sudoers` configuration file are allowed to use the [command]`sudo` command. The command is executed in the user's shell, not a root shell.
The syntax for the sudo command is as follows:
[subs=quotes]
----
sudo _COMMAND_
----
Replace `_COMMAND_` with the command to run as the root user.

View file

@ -0,0 +1,8 @@
[id='why-it-is-important-to-keep-your-system-up-to-date']
= Why it is important to keep your system up-to-date
// Bara: This section is based on https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-keeping_your_system_up-to-date
This section briefly explains the importance of updating your system on a regular basis.
All software contains bugs. Often, these bugs can result in a vulnerability that can expose your system to malicious users. Packages that have not been updated are a common cause of computer intrusions. Implement a plan for installing security patches in a timely manner to quickly eliminate discovered vulnerabilities, so they cannot be exploited.

View file

@ -0,0 +1,6 @@
[id='con_about-xorg-conf']
= About xorg.conf
Traditionally, the xorg.conf file is used to configure the X server. In Fedora, the X configuration is determined automatically each time X is started. As a result, no xorg.conf file is created. In most cases, this works well and there is no need to manually specify X configuration.
If you need to make manual changes to your X configuration for any reason, you will first need to create an `xorg.conf` file.

View file

@ -0,0 +1,20 @@
[id='chromium-web-browser']
= Chromium and Google Chrome web browsers
Only the Chromium browser is available from official Fedora repositories.
[id='chromium']
== Chromium
Chromium is the upstream project for Google Chrome.
NOTE: As of August 2016, Chromium is included in the Fedora Repositories. If you were using the old Chromium http://copr.fedoraproject.org/coprs/spot/chromium/[Copr] repository, upgrade your Chromium.
Fedora's Chromium package does not support h264, mp3, or aac because of legal concerns. It is built to support the *widevine* plugin (but does not include it).
[id='google-chrome']
== Google Chrome
Chromium is upstream for Google Chrome. Fedora does not include Google Chrome because it is a proprietary product and bundles other proprietary software, such as Adobe Flash plugin. However, Google does maintain a DNF or YUM repository for Fedora at link:https://www.google.com/chrome/[google.com/chrome]. The given link also includes downloadable RPMs that you can use to install Chrome.

View file

@ -0,0 +1,15 @@
[[fedora-virtio-drivers-vs-rhel]]
= Fedora VirtIO Drivers vs. RHEL VirtIO Drivers
The RPMs in the *virtio-win-stable* repository are the same driver builds as what is shipped with Red Hat Enterprise Linux. All the Windows binaries are from builds done on Red Hat's internal build system, which are generated using publicly available code. For more details about how the RPM and repo are built, see the https://github.com/crobinso/virtio-win-pkg-scripts[README for this repo].
The drivers are cryptographically signed with Red Hat's vendor signature. However they are not signed with Microsoft's https://docs.microsoft.com/en-us/windows-hardware/drivers/install/whql-release-signature[WHQL signature].
NOTE: Historically the .iso files shipped on alt.fedoraproject.org did _not_ match the layout of the .iso shipped with Red Hat Enterprise Linux. This changed in April 2015.
The current Fedora RPM/ISO directory structure is laid out to mirror exactly the layout that is shipped with the latest release of Red Hat Enterprise Linux. This is so that users and developers don't seen any differences between the two distros.
* The `.iso` directories are named after the driver code directories from the upstream driver git tree.
* Below the driver directories, the `$winversion/$arch/` directory naming
is a Windows convention.
* The RPM layout is arbitrary in that it ships the `.vfd` content in the `drivers/` dir, but not many of the other drivers from the `.iso`. This seems to be an historical oversight and should probably be fixed.

View file

@ -0,0 +1,14 @@
[id='third-party-repositories']
= Third party repositories
There are a number of third-party software repositories for Fedora. They have more liberal licensing policies and provide software packages that Fedora excludes for various reasons. These software repositories are not officially affiliated or endorsed by the Fedora Project. Use them at your own discretion. For complete list, see https://rpmfusion.org/FedoraThirdPartyRepos[FedoraThirdPartyRepos]
The following repositories are commonly used by end users and do not conflict with each other:
* http://rpmfusion.org
* http://rpm.livna.org (Complementary to RPM Fusion)
== Mixing third party software repositories
Mixing a lot of third party repositories is not recommended since they might conflict with each other causing instability and hard to debug issues. If you are not a technical user, one way is to not enable the third-party repo by default and instead use the *--enablerepo* switch for yum or dnf, or a similar method configurable in the graphical package manager.

View file

@ -0,0 +1,10 @@
[[virtio-win-repo-overview]]
= VirtIO-Win Repo Overview
There is a yum|dnf repo available via the RPM package manager (RPM) that ships virtio-win packages. You can use these RPMs to install driver binaries and agent installers into the `/usr/share` directory on your host machine. You can then share the bits with Windows VMs running on the host.
The .repo file provides two different repositories:
* *virtio-win-stable* - This repository provides builds of virtio-win that roughly correlate to what was shipped with the most recent Red Hat Enterprise Linux release, meaning these builds have undergone testing and are considered stable. This repo is enabled by default.
* *virtio-win-latest* - This repository provides the latest driver builds. The builds may be bug free, development quality, or completely broken. https://en.wikipedia.org/wiki/Caveat_emptor[Caveat emptor]. This repo is disabled by default.

View file

@ -0,0 +1,108 @@
// Module included in the following assemblies:
//
// assembly_Configuring-networking-with-nmcli.adoc
[id='Brief-selection-of-nmcli-examples']
= Brief Selection of nmcli Examples
This section provides a brief selection of [application]*nmcli* examples.
[discrete]
== Prerequisites
<<Getting-started-with-nmcli>>
.Checking the overall status of NetworkManager
====
[literal,subs="+quotes,verbatim,macros"]
....
~]$ pass:attributes[{blank}][command]`nmcli general status`
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN
connected full enabled enabled enabled enabled
....
In terse mode:
[literal,subs="+quotes,verbatim,macros"]
....
~]$ pass:attributes[{blank}][command]`nmcli -t -f STATE general`
connected
....
====
.Viewing NetworkManager logging status
====
[literal,subs="+quotes,verbatim"]
....
~]$ [command]`nmcli general logging`
LEVEL DOMAINS
INFO PLATFORM,RFKILL,ETHER,WIFI,BT,MB,DHCP4,DHCP6,PPP,WIFI_SCAN,IP4,IP6,A
UTOIP4,DNS,VPN,SHARING,SUPPLICANT,AGENTS,SETTINGS,SUSPEND,CORE,DEVICE,OLPC,
WIMAX,INFINIBAND,FIREWALL,ADSL,BOND,VLAN,BRIDGE,DBUS_PROPS,TEAM,CONCHECK,DC
B,DISPATCH
....
====
.Viewing all connections
====
[literal,subs="+quotes,verbatim,macros"]
....
~]$ pass:attributes[{blank}][command]`nmcli connection show`
NAME UUID TYPE DEVICE
Profile 1 db1060e9-c164-476f-b2b5-caec62dc1b05 ethernet ens3
ens3 aaf6eb56-73e5-4746-9037-eed42caa8a65 ethernet --
....
====
.Viewing only currently active connections
====
[literal,subs="+quotes,verbatim,macros"]
....
~]$ pass:attributes[{blank}][command]`nmcli connection show --active`
NAME UUID TYPE DEVICE
Profile 1 db1060e9-c164-476f-b2b5-caec62dc1b05 ethernet ens3
....
====
.Viewing only devices recognized by [application]*NetworkManager* and their state
====
[literal,subs="+quotes,verbatim,macros"]
....
~]$ pass:attributes[{blank}][command]`nmcli device status`
DEVICE TYPE STATE CONNECTION
ens3 ethernet connected Profile 1
lo loopback unmanaged --
....
====
You can also use the following abbreviations of the [application]*nmcli* commands:
[[tabl-nmcli_examples]]
.Abbreviations of some nmcli commands
[options="header"]
|===
|nmcli command|abbreviation
|nmcli general status|nmcli g
|nmcli general logging|nmcli g log
|nmcli connection show|nmcli con show
|nmcli connection show --active|nmcli con show -a
|nmcli device status|nmcli dev
|===
[discrete]
== Additional resources
* For more examples, see the
[citetitle]_pass:attributes[{blank}]*nmcli-examples*(5)_
man page.

View file

@ -0,0 +1,20 @@
[id='proc_adding-new-certificates']
= Adding New Certificates
To add a certificate in the simple PEM or DER file formats to the list of CAs trusted on the system, copy the certificate file to the `/usr/share/pki/ca-trust-source/anchors/` or `/etc/pki/ca-trust/source/anchors/` directory, for example:
[subs="+quotes,macros"]
----
# cp _~/certificate-trust-examples/Cert-trust-test-ca.pem_ _/usr/share/pki/ca-trust-source/anchors/_
----
To update the system-wide trust store configuration, use the [command]`update-ca-trust` command:
----
# update-ca-trust
----
[NOTE]
====
While the Firefox browser is able to use an added certificate without executing [command]`update-ca-trust`, it is recommended to run [command]`update-ca-trust` after a CA change. Also note that browsers, such as Firefox, Epiphany, or Chromium, cache files, and you might need to clear the browser's cache or restart your browser to load the current system certificates configuration.
====

View file

@ -0,0 +1,81 @@
[[adding-new-fonts-as-superuser]]
= Adding new fonts as the superuser
System fonts are available to all system users. If you need to add system fonts, there are two ways:
. Use the `dnf` package manager to install font packages,
. Manually add fonts to the system and update the font cache to make them available to the users.
[WARNING]
====
If you manually add system-wide fonts, you will not be able to control them with the package manager. If the font is provided as a distribution package, you should always use the package manager to install it.
====
[[installing-new-fonts-with-dnf]]
== Installing new fonts with dnf
Whenever you can add new fonts by installing a font package with the `dnf` package manager, you should do so. This method gives you control over the font package in the future, such as updating the package and removing it from the system.
To install a font package with `dnf`:
[discrete]
=== Before you start
* Add and enable repositories with font packages.
+
[NOTE]
====
A lot of fonts are available from the RPMfusion repository. To enable the repository on your system, follow the instructions on link:https://rpmfusion.org/Configuration[the RPMfusion webpage].
====
[discrete]
=== Procedure
. List all available font packages from enabled repositories.
+
----
# dnf search fonts
----
. Install the package you need.
+
----
# dnf install libreoffice-opensymbol-fonts.noarch
----
[discrete]
=== More information
* The `dnf search fonts` command lists all available font packages, as well as their descriptions.
[[installing-new-fonts-manually]]
== Installing new fonts manually
When you need to install fonts that are not available in a repository, you can install them manually by copying the font files into a system font directory and updating the font cache.
[discrete]
== Procedure
. Create a new directory in the system's font directory `/usr/share/fonts`, where you will place the font files.
+
----
# mkdir /usr/share/fonts/robofont
----
. Copy the font file to the font's directory created in the previous step.
+
----
# cp ~/fonts/robofont.ttf /usr/share/fonts/robofont
----
. Update the font cache.
+
----
# fc-cache -v
----

View file

@ -0,0 +1,71 @@
[[adding-new-fonts-as-user]]
= Adding new fonts as a user
When you do not have superuser access to install fonts on the system level, or you only need to install a font that will be available to your user account only, there are two methods to do it.
[[adding-new-local-fonts-with-gfv]]
== Adding new local fonts with the Gnome Font Viewer
The *Gnome Font Viewer* is an application to display the fonts installed on the system. It also allows you to locally install fonts. To add a new font file with *Gnome Font Viewer*:
[discrete]
=== Before you start
* Make sure you have installed the `gnome-font-viewer` package.
[discrete]
=== Procedure
. Open a file manager.
. Double-click on a font file to open it in the *Gnome Font Viewer*.
. Click on the blue btn:[Install] button on the top bar.
+
[NOTE]
====
Currently, there is a bug in the application. When you click on the btn:[Install] button, it does not inform whether the installation succeeded.
====
[discrete]
=== More information
* *Gnome Font Viewer* copies the font files to a font directory in the current user's directory `.local/share/fonts` and updates the font cache.
[[adding-new-local-fonts-manually]]
== Adding new local fonts manually
If you do not want to use any tools to add new fonts, you can do it manually. Copy the font files in the `.fonts` directory placed in the user's directory and update the font cache.
[discrete]
=== Before you start
* If it does not exist, create a `.fonts` directory in your user's home directory.
[discrete]
=== Procedure
. In the `.local/share/fonts` directory, create a new directory to place your fonts files.
+
----
$ mkdir ~/.local/share/fonts/robofont
----
. Copy the font file into the newly created directory.
+
----
$ cp robofont.ttf ~/.local/share/fonts/robofont
----
. Update the font cache.
+
----
$ fc-cache -v
----

View file

@ -0,0 +1,31 @@
[[adding-other-operating-systems-grub2]]
= Adding other operating systems to the GRUB2 menu
Normally, *GRUB2* is preset to boot multiple operating systems during the Fedora installation process. If you can, it is advisable to install non-Linux operating systems first. Then, during the installation process, all those operating systems and their locations will be discovered and properly set.
Adding other records into the *GRUB2* menu only means to run `grub2-mkconfig` command to regenerate the configuration files. During this process, all operating systems known to the system will be added into the configuration. By reinstalling *GRUB2* into the MBR, this configuration will be used for further boots.
.Before you start
* Make sure that the operating systems are on disks, connected to the system.
* You have the `os-prober` package installed.
.Procedure
. Recreate the *GRUB2* configuration file.
+
----
# grub2-mkconfig -o /boot/grub2/grub.cfg
----
. Install *GRUB2* into the MBR of your primary hard disk.
+
----
# grub2-install /dev/sda
----
.More information
* The `grub2-mkconfig` command will add entries for all operating systems it can find.
* When problems appear, see the link:http://www.gnu.org/software/grub/manual/grub.html#Multi_002dboot-manual-config[GRUB manual] to solve issues with booting secondary operating systems.

View file

@ -0,0 +1,21 @@
[id='adding-repositories']
= Adding repositories
This section describes how to add software repositories with the `dnf config-manger` command.
Use the following commands as the `root` user or under the `sudo` utility.
. Define a new repository by adding a new file with the `.repo` suffix to the [filename]`/etc/yum.repos.d/` directory. For details about various options to use in the `.repo` file, see the link:https://docs-old.fedoraproject.org/en-US/Fedora/26/html/System_Administrators_Guide/sec-Setting_repository_Options.html[Setting [repository\] Options] section in the System Administrator's Guide
. Add the newly created repository.
+
[literal,subs="+quotes,attributes"]
----
# dnf config-manger --add-repo _repository_
----
+
Replace `_repository_` with the path to the created `.repo` file, for example:
+
----
# dnf config-manager --add-repo /etc/yum.repos.d/fedora_extras.repo
----

Some files were not shown because too many files have changed in this diff Show more