Product SiteDocumentation Site

Fedora 17

Guía de Administración del Sistema

Despliegue, Configuración, y Administración de Fedora 17

Edición 1

Jaromír Hradílek

Red Hat, Inc. Servicios de ingeniería de contenido

Douglas Silas

Red Hat, Inc. Servicios de ingeniería de contenido

Martin Prpič

Red Hat, Inc. Servicios de ingeniería de contenido

Stephen Wadeley

Red Hat, Inc. Servicios de ingeniería de contenido

Eliška Slobodová

Red Hat, Inc. Servicios de ingeniería de contenido

Tomás capek

Red Hat, Inc. Servicios de ingeniería de contenido

Petr Kovár

Red Hat, Inc. Servicios de ingeniería de contenido

John Ha

Red Hat, Inc. Servicios de ingeniería de contenido

David O'Brien

Red Hat, Inc. Servicios de ingeniería de contenido

Michael Hideo

Red Hat, Inc. Servicios de ingeniería de contenido

Don Domingo

Red Hat, Inc. Servicios de ingeniería de contenido

Aviso Legal

Copyright © 2012 Red Hat, Inc. and others.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/Legal:Trademark_guidelines.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
All other trademarks are the property of their respective owners.
Resumen
La Guía de Administración del Sistema documenta la informatión relacionada con el despliegue, configuración, y administración de Fedora 17. esta orientada hacia los administradores de sistemas con un conocimiento basico del sistema.

Prefacio
1. Público objetivo
2. Cómo leer este libro
3. Convenciones del Documento
3.1. Convenciones Tipográficas
3.2. Convenciones del documento
3.3. Notas y Advertencias
4. Comentarios
5. Agradecimientos
I. Configuración básica del sistema
1. Configurando el Lenguaje y el Teclado
1.1. Cambiando el lenguaje
1.2. Cambiando la Fecha, la Hora y el Formato Numérico
1.3. Cambiando la disposición del teclado
1.4. Viendo la configuración Actual
2. Configuración de la Fecha y Hora
2.1. Usando la herramienta de configuración de fecha y hora
2.2. Usando las herramientas de línea de comando
2.2.1. Cambiando la fecha
2.2.2. Cambiando la hora
2.2.3. Configurando el Protocolo de Tiempo en Red
2.3. Recursos adicionales
2.3.1. Documentación instalada
3. Managing Users and Groups
3.1. Introduction to Users and Groups
3.1.1. Grupos de usuario privado
3.1.2. Contraseñas Shadow
3.2. Using the User Accounts Tool
3.2.1. Configuring an Account
3.2.2. Añadir un nuevo usuario
3.2.3. Removing a User
3.3. Using the User Manager Tool
3.3.1. Viewing Users and Groups
3.3.2. Añadir un nuevo usuario
3.3.3. Añadir un nuevo grupo
3.3.4. Modificar las propiedades del usuario
3.3.5. Modificar las propiedades del grupo
3.4. Using Command Line Tools
3.4.1. Añadir un nuevo usuario
3.4.2. Añadir un nuevo grupo
3.4.3. Enabling Password Aging
3.4.4. Enabling Automatic Logouts
3.4.5. Creating Group Directories
3.5. Recursos adicionales
3.5.1. Documentación instalada
II. Gestión de paquetes
4. Yum
4.1. Para la comprobación y actualización de paquetes
4.1.1. comprobación de actualizaciones
4.1.2. Actualizando paquetes
4.1.3. Conservando cambios en los Archivos de Configuracion
4.2. Paquetes y grupos de paquetes
4.2.1. Buscando paquetes
4.2.2. Listando paquetes
4.2.3. Mostrando información del paquete
4.2.4. Installing Packages
4.2.5. Removing Packages
4.2.6. Working with Transaction History
4.3. Configurando Yum y repositorios de Yum
4.3.1. Setting [main] Options
4.3.2. Setting [repository] Options
4.3.3. Using Yum Variables
4.3.4. Viewing the Current Configuration
4.3.5. Adding, Enabling, and Disabling a Yum Repository
4.3.6. Creating a Yum Repository
4.4. Yum Plug-ins
4.4.1. Enabling, Configuring, and Disabling Yum Plug-ins
4.4.2. Installing Additional Yum Plug-ins
4.4.3. Plug-in Descriptions
4.5. Recursos adicionales
5. PackageKit
5.1. Updating Packages with Software Update
5.1.1. Setting the Update-Checking Interval
5.1.2. Setting the Software Sources
5.2. Using Add/Remove Software
5.2.1. Refreshing Software Sources (Yum Repositories)
5.2.2. Finding Packages with Filters
5.2.3. Installing and Removing Packages (and Dependencies)
5.2.4. Installing and Removing Package Groups
5.2.5. Viewing the Transaction Log
5.3. PackageKit Architecture
5.4. Recursos adicionales
III. Interconexión
6. NetworkManager
6.1. The NetworkManager Daemon
6.2. Interacting with NetworkManager
6.2.1. Connecting to a Network
6.2.2. Configuring New and Editing Existing Connections
6.2.3. Connecting to a Network Automatically
6.2.4. User and System Connections
6.3. Establishing Connections
6.3.1. Establishing a Wired (Ethernet) Connection
6.3.2. Establishing a Wireless Connection
6.3.3. Establishing a Mobile Broadband Connection
6.3.4. Establishing a VPN Connection
6.3.5. Establishing a DSL Connection
6.3.6. Establishing Routes
6.4. Configuring Connection Settings
6.4.1. Configuring 802.1x Security
6.4.2. Configuring Wireless Security
6.4.3. Configuring PPP (Point-to-Point) Settings
6.4.4. Configuring IPv4 Settings
6.4.5. Configuring IPv6 Settings
6.5. NetworkManager Architecture
7. Interfaces de red
7.1. Archivos de configuración de red
7.2. Archivos de configuración de interfaz
7.2.1. Interfaces Ethernet
7.2.2. Interfaces de unión de canales
7.2.3. Network Bridge
7.2.4. Setting up 802.1q VLAN tagging
7.2.5. Archivos alias y clon
7.2.6. Interfaces de acceso telefónico
7.2.7. Otras interfaces
7.3. Scripts de control de interfaz
7.4. Configurando rutas estáticas
7.5. Archivos de funciones de red
7.6. Recursos adicionales
7.6.1. Documentación instalada
IV. Servicios de infraestructura
8. Services and Daemons
8.1. Configuring Services
8.1.1. Enabling the Service
8.1.2. Disabling the Service
8.2. Running Services
8.2.1. Checking the Service Status
8.2.2. Running the Service
8.2.3. Stopping the Service
8.2.4. Restarting the Service
8.3. Recursos adicionales
8.3.1. Documentación instalada
8.3.2. Libros relacionados
9. Configuring Authentication
9.1. La herramienta de configuración de autenticación
9.1.1. Identidad y autenticación
9.1.2. Opciones avanzadas
9.1.3. Versión de línea de comandos
9.2. El Daemon de Servicios de Seguridad del Sistema (SSSD)
9.2.1. ¿Qué es SSSD?
9.2.2. Características de SSSD
9.2.3. Configurando SSSD
9.2.4. Configuring Services
9.2.5. Configuring Domains
9.2.6. Setting Up Kerberos Authentication
9.2.7. Configuring a Proxy Domain
9.2.8. Troubleshooting
9.2.9. SSSD Configuration File Format
10. OpenSSH
10.1. The SSH Protocol
10.1.1. ¿Por qué usar SSH?
10.1.2. Main Features
10.1.3. Protocol Versions
10.1.4. Secuencia de eventos de una conexión SSH
10.2. An OpenSSH Configuration
10.2.1. Archivos de configuración
10.2.2. Starting an OpenSSH Server
10.2.3. Requiriendo SSH para conexiones remotas
10.2.4. Using a Key-Based Authentication
10.3. OpenSSH Clients
10.3.1. Using the ssh Utility
10.3.2. Using the scp Utility
10.3.3. Using the sftp Utility
10.4. Más que un Shell seguro
10.4.1. Reenvío por X11
10.4.2. Reenvío del puerto
10.5. Recursos adicionales
10.5.1. Documentación instalada
10.5.2. Sitios Web útiles
V. Servidores
11. DHCP Servers
11.1. Motivos para usar el protocolo DHCP
11.2. Configuración de un servidor DHCP
11.2.1. Archivo de configuración
11.2.2. Base de datos de arrendamiento
11.2.3. Iniciar y detener el servidor
11.2.4. Agente de transmisión DHCP
11.3. Configuración de un cliente DHCP
11.4. Configuring a Multihomed DHCP Server
11.4.1. Host Configuration
11.5. DHCP for IPv6 (DHCPv6)
11.6. Recursos adicionales
11.6.1. Documentación instalada
12. DNS Servers
12.1. Introducción a DNS
12.1.1. Zonas de servidores de nombres
12.1.2. Tipos de servidores de nombres
12.1.3. BIND as a Nameserver
12.2. BIND
12.2.1. Configuring the named Service
12.2.2. Editing Zone Files
12.2.3. Using the rndc Utility
12.2.4. Using the dig Utility
12.2.5. Características avanzadas de BIND
12.2.6. Errores comunes que debe evitar
12.2.7. Recursos adicionales
13. Servidores web
13.1. The Apache HTTP Server
13.1.1. New Features
13.1.2. Notable Changes
13.1.3. Updating the Configuration
13.1.4. Running the httpd Service
13.1.5. Editing the Configuration Files
13.1.6. Working with Modules
13.1.7. Setting Up Virtual Hosts
13.1.8. Setting Up an SSL Server
13.1.9. Recursos adicionales
14. Mail Servers
14.1. Protocolos de correo electrónico
14.1.1. Protocolos de transporte de correo
14.1.2. Protocolos de acceso a correo
14.2. Clasificaciones de los programas de correo
14.2.1. Mail Transport Agent
14.2.2. Mail Delivery Agent
14.2.3. Mail User Agent
14.3. Agentes de transporte de correo
14.3.1. Postfix
14.3.2. Sendmail
14.3.3. Fetchmail
14.3.4. Configuración del Agente de Transporte de Correo (MTA)
14.4. Agente de entrega de correo
14.4.1. Configuración de Procmail
14.4.2. Recetas de Procmail
14.5. Agentes de usuario de correo
14.5.1. Comunicación segura
14.6. Recursos adicionales
14.6.1. Documentación instalada
14.6.2. Sitios Web útiles
14.6.3. Libros relacionados
15. Servidores de directorio
15.1. OpenLDAP
15.1.1. Introduction to LDAP
15.1.2. Installing the OpenLDAP Suite
15.1.3. Configuring an OpenLDAP Server
15.1.4. Running an OpenLDAP Server
15.1.5. Configurar un sistema para la autenticación mediante OpenLDAP
15.1.6. Recursos adicionales
16. Servidores de archivos e impresoras
16.1. Samba
16.1.1. Introducción a Samba
16.1.2. Demonios Samba y Servicios relacionados
16.1.3. Conexión a un recurso compartido Samba
16.1.4. Configuración del servidor Samba
16.1.5. Arrancar y detener el Samba
16.1.6. Samba Server Types and the smb.conf File
16.1.7. Modos de seguridad Samba
16.1.8. Bases de datos de información de cuentas Samba
16.1.9. Navegación de red con Samba
16.1.10. Samba con soporte para la impresión con CUPS
16.1.11. Programas de distribución Samba
16.1.12. Recursos adicionales
16.2. FTP
16.2.1. El Protocolo de Transferencia de Archivo
16.2.2. Servidores FTP
16.2.3. Archivos instalados con vsftpd
16.2.4. Iniciar y Detener vsftpd
16.2.5. vsftpd Opciones de configuracion
16.2.6. Recursos adicionales
16.3. Configuración de la impresora
16.3.1. Iniciando la herramienta de configuración de impresora
16.3.2. Iniciando ajustes de impresora
16.3.3. Añadir una impresora local
16.3.4. Agregando una impresora AppSocket/HP JetDirect
16.3.5. Añadir una impresora de red IPP
16.3.6. Agregando una impresora o equipo LPD/LPR
16.3.7. Adding a Samba (SMB) printer
16.3.8. Selección del modelo de impresora
16.3.9. Printing a test page
16.3.10. Modificar impresoras existentes
16.3.11. Recursos adicionales
VI. Monitorización y automatizado
17. System Monitoring Tools
17.1. Viewing System Processes
17.1.1. Using the ps Command
17.1.2. Using the top Command
17.1.3. Using the System Monitor Tool
17.2. Viewing Memory Usage
17.2.1. Using the free Command
17.2.2. Using the System Monitor Tool
17.3. Viewing CPU Usage
17.3.1. Using the System Monitor Tool
17.4. Viewing Block Devices and File Systems
17.4.1. Using the lsblk Command
17.4.2. Using the blkid Command
17.4.3. Using the partx Command
17.4.4. Using the findmnt Command
17.4.5. Using the df Command
17.4.6. Using the du Command
17.4.7. Using the System Monitor Tool
17.5. Viewing Hardware Information
17.5.1. Using the lspci Command
17.5.2. Using the lsusb Command
17.5.3. Using the lspcmcia Command
17.5.4. Using the lscpu Command
17.6. Monitoring Performance with Net-SNMP
17.6.1. Installing Net-SNMP
17.6.2. Running the Net-SNMP Daemon
17.6.3. Configuring Net-SNMP
17.6.4. Retrieving Performance Data over SNMP
17.6.5. Extending Net-SNMP
17.7. Recursos adicionales
17.7.1. Documentación instalada
18. Viewing and Managing Log Files
18.1. Configuring rsyslog
18.1.1. Global Directives
18.1.2. Modules
18.1.3. Rules
18.1.4. rsyslog Command Line Configuration
18.2. Localizar archivos de registro
18.2.1. Configuring logrotate
18.3. Visualizar los archivos de registro
18.4. Adding a Log File
18.5. Control de Archivos de Registro
18.6. Recursos adicionales
18.6.1. Documentación instalada
18.6.2. Sitios Web útiles
19. Automating System Tasks
19.1. Cron y Anacron
19.1.1. Iniciar y finalizar el servicio
19.1.2. Configuring Anacron Jobs
19.1.3. Configuring Cron Jobs
19.1.4. Controlando el acceso a Cron
19.1.5. Black/White Listing of Cron Jobs
19.2. At y Batch
19.2.1. Configuración de tareas At
19.2.2. Configuración de tareas Batch
19.2.3. Visualizando las tareas pendientes
19.2.4. Opciones adicionales de la línea de comandos
19.2.5. Control de acceso a At y Batch
19.2.6. Iniciar y finalizar el servicio
19.3. Recursos adicionales
19.3.1. Documentación instalada
20. OProfile
20.1. Descripción general de las herramientas
20.2. Configuración de Oprofile
20.2.1. Especificar el Kernel
20.2.2. Configurar los eventos a supervisar
20.2.3. Separar perfiles del Kernel y del espacio del usuario
20.3. Iniciar y detener Oprofile
20.4. Guardar los datos
20.5. Análisis de los datos
20.5.1. Using opreport
20.5.2. Using opreport on a Single Executable
20.5.3. Obtener salidas más detalladas sobre los módulos
20.5.4. Using opannotate
20.6. Understanding /dev/oprofile/
20.7. Ejemplo de uso
20.8. OProfile Support for Java
20.8.1. Profiling Java Code
20.9. Interfaz gráfica
20.10. OProfile and SystemTap
20.11. Recursos adicionales
20.11.1. Documentos instalados
20.11.2. Sitios Web útiles
VII. Configuración del kernel, módulos y controladores
21. Actualización Manual del Kernel
21.1. Descripción general de los Paquetes del kernel
21.2. Preparación para la actualización
21.3. Descarga el Kernel actualizado
21.4. Realizando la actualización
21.5. Verificación de la imagen de disco RAM inicial
21.6. Configuración del gestor de arranque
21.6.1. Configuring the GRUB 2 Boot Loader
21.6.2. Configurando el gestor de arranque del OS/400
21.6.3. Configurando el gestor de arranque YABOOT
22. Working with Kernel Modules
22.1. Listing Currently-Loaded Modules
22.2. Displaying Information About a Module
22.3. Loading a Module
22.4. Unloading a Module
22.5. Setting Module Parameters
22.6. Carga Persistente de Módulos
22.7. Specific Kernel Module Capabilities
22.7.1. Utilización de Múltiples Tarjetas Ethernet
22.7.2. Using Channel Bonding
22.8. Recursos adicionales
22.8.1. Documentación instalada
22.8.2. Sitios Web útiles
23. The kdump Crash Recovery Service
23.1. Installing the kdump Service
23.2. Configuring the kdump Service
23.2.1. Configuring the kdump at First Boot
23.2.2. Using the Kernel Dump Configuration Utility
23.2.3. Configuring kdump on the Command Line
23.2.4. Testing the Configuration
23.3. Analyzing the Core Dump
23.3.1. Running the crash Utility
23.3.2. Displaying the Message Buffer
23.3.3. Displaying a Backtrace
23.3.4. Displaying a Process Status
23.3.5. Displaying Virtual Memory Information
23.3.6. Displaying Open Files
23.3.7. Exiting the Utility
23.4. Recursos adicionales
23.4.1. Documentación instalada
23.4.2. Sitios Web útiles
A. Nombramiento Consistente de Dispositivos de Red
A.1. Sistemas Afectados
A.2. Requerimientos del Sistema
A.3. Activando y Desactivando la Característica
A.4. Notas para Administradores
B. RPM
B.1. Metas de diseño RPM
B.2. El uso de RPM
B.2.1. Encontrar paquetes RPM
B.2.2. Installing and Upgrading
B.2.3. Configuration File Changes
B.2.4. Desinstalación
B.2.5. Refrescamiento
B.2.6. Consultas
B.2.7. Verificación
B.3. Revisando la firma de los paquetes
B.3.1. Importando llaves
B.3.2. Verificación de la Firma de los Paquetes
B.4. Ejemplos comunes y prácticos sobre el uso de RPM
B.5. Recursos adicionales
B.5.1. Documentación instalada
B.5.2. Sitios Web útiles
B.5.3. Libros relacionados
C. El Sistema X Window
C.1. The X Server
C.2. Entornos de escritorio y gestores de ventanas
C.2.1. Entornos de escritorio
C.2.2. Gestores de ventanas
C.3. Archivos de configuración del servidor X
C.3.1. The Structure of the Configuration
C.3.2. The xorg.conf.d Directory
C.3.3. The xorg.conf File
C.4. Fuentes
C.4.1. Añadir fuentes a Fontconfig
C.5. Runlevels and X
C.5.1. Runlevel 3
C.5.2. Runlevel 5
C.6. Recursos adicionales
C.6.1. Documentación instalada
C.6.2. Sitios Web útiles
D. The sysconfig Directory
D.1. Files in the /etc/sysconfig/ Directory
D.1.1. /etc/sysconfig/arpwatch
D.1.2. /etc/sysconfig/authconfig
D.1.3. /etc/sysconfig/autofs
D.1.4. /etc/sysconfig/clock
D.1.5. /etc/sysconfig/dhcpd
D.1.6. /etc/sysconfig/firstboot
D.1.7. /etc/sysconfig/i18n
D.1.8. /etc/sysconfig/init
D.1.9. /etc/sysconfig/ip6tables-config
D.1.10. /etc/sysconfig/keyboard
D.1.11. /etc/sysconfig/ldap
D.1.12. /etc/sysconfig/named
D.1.13. /etc/sysconfig/network
D.1.14. /etc/sysconfig/ntpd
D.1.15. /etc/sysconfig/quagga
D.1.16. /etc/sysconfig/radvd
D.1.17. /etc/sysconfig/samba
D.1.18. /etc/sysconfig/selinux
D.1.19. /etc/sysconfig/sendmail
D.1.20. /etc/sysconfig/spamassassin
D.1.21. /etc/sysconfig/squid
D.1.22. /etc/sysconfig/system-config-users
D.1.23. /etc/sysconfig/vncservers
D.1.24. /etc/sysconfig/xinetd
D.2. Directories in the /etc/sysconfig/ Directory
D.3. Recursos adicionales
D.3.1. Documentación instalada
E. The proc File System
E.1. A Virtual File System
E.1.1. Viewing Virtual Files
E.1.2. Changing Virtual Files
E.2. Top-level Files within the proc File System
E.2.1. /proc/buddyinfo
E.2.2. /proc/cmdline
E.2.3. /proc/cpuinfo
E.2.4. /proc/crypto
E.2.5. /proc/devices
E.2.6. /proc/dma
E.2.7. /proc/execdomains
E.2.8. /proc/fb
E.2.9. /proc/filesystems
E.2.10. /proc/interrupts
E.2.11. /proc/iomem
E.2.12. /proc/ioports
E.2.13. /proc/kcore
E.2.14. /proc/kmsg
E.2.15. /proc/loadavg
E.2.16. /proc/locks
E.2.17. /proc/mdstat
E.2.18. /proc/meminfo
E.2.19. /proc/misc
E.2.20. /proc/modules
E.2.21. /proc/mounts
E.2.22. /proc/mtrr
E.2.23. /proc/partitions
E.2.24. /proc/slabinfo
E.2.25. /proc/stat
E.2.26. /proc/swaps
E.2.27. /proc/sysrq-trigger
E.2.28. /proc/uptime
E.2.29. /proc/version
E.3. Directories within /proc/
E.3.1. Process Directories
E.3.2. /proc/bus/
E.3.3. /proc/bus/pci
E.3.4. /proc/driver/
E.3.5. /proc/fs
E.3.6. /proc/irq/
E.3.7. /proc/net/
E.3.8. /proc/scsi/
E.3.9. /proc/sys/
E.3.10. /proc/sysvipc/
E.3.11. /proc/tty/
E.3.12. /proc/PID/
E.4. Using the sysctl Command
E.5. Referencias
F. Historial de revisiones
Índice

Prefacio

La Guía del administrador de sistemas contiene información sobre cómo personalizar el sistema Fedora 17 para que se ajuste a sus necesidades. Si está buscando una guía detallada y orientada a tareas para configurar y personalizar su sistema, éste es el manual para usted.
Este manual discute temas de nivel intermedio como:
  • Instalar y gestionar paquetes utilizando la aplicación gráfica PackageKit y el gestor de paquetes por línea de comandos Yum
  • Setting up a network—from establishing an Ethernet connection using NetworkManager to configuring channel bonding interfaces to increase server bandwidth
  • Configuring DHCP, BIND, Apache HTTP Server, Postfix, Sendmail and other enterprise-class servers and software
  • Gathering information about your system, including obtaining user-space crash data with the Automatic Bug Reporting Tool, and kernel-space crash data with kdump
  • Trabajar fácilmente con módulos del núcleo y actualizar el núcleo

1. Público objetivo

The Deployment Guide assumes you have a basic understanding of the Fedora operating system. If you need help with the installation of this system, refer to the Fedora 17 Installation Guide.

2. Cómo leer este libro

Este manual está dividido fundamentalmente en las siguientes categorías:
Parte I, “Configuración básica del sistema”
Esta parte comprende tareas básicas de administración de sistemas como la configuración del teclado, de la fecha y la hora, y gestionar usuarios y grupos.
Capítulo 1, Configurando el Lenguaje y el Teclado covers basic language and keyboard setup. Read this chapter if you need to configure the language of your desktop, change the keyboard layout, or add the keyboard layout indicator to the panel.
Capítulo 2, Configuración de la Fecha y Hora covers the configuration of the system date and time. Read this chapter if you need to change the date and time setup, or configure the system to synchronize the clock with a remote Network Time Protocol (NTP) server.
Capítulo 3, Managing Users and Groups covers the management of users and groups in a graphical user interface and on the command line. Read this chapter if you need to manage users and groups on your system, or enable password aging.
Parte II, “Gestión de paquetes”
Esta parte describe cómo gestionar los paquetes de software en Fedora utilizando Yum y el conjunto de herramientas gráficas de gestión de paquetes PackageKit.
Capítulo 4, Yum describe al gestor de paquetes Yum. Lea este capítulo para obtener información sobre cómo buscar, instalar, actualizar y desinstalar paquetes desde la línea de comandos.
Capítulo 5, PackageKit describe al conjunto de herramientas gráficas para gestionar paquetes PackageKit. Lea este capítulo para obtener información sobre cómo buscar, instalar, actualizar y desinstalar paquetes utilizando una interfaz gráfica de usuario.
Parte III, “Interconexión”
Esta parte describe cómo configurar la red en Fedora.
Capítulo 7, Interfaces de red explores various interface configuration files, interface control scripts, and network function files located in the /etc/sysconfig/network-scripts/ directory. Read this chapter for information how to use these files to configure network interfaces.
Parte IV, “Servicios de infraestructura”
Esta parte proporciona información sobre cómo configurar servicios y demonios, configurar la autenticación y activar el inicio de sesión remoto.
Capítulo 8, Services and Daemons covers the configuration of the services to be run when a system is started, and provides information on how to start, stop, and restart the services on the command line using the systemctl utility.
Capítulo 9, Configuring Authentication describes how to configure user information retrieval from Lightweight Directory Access Protocol (LDAP), Network Information Service (NIS), and Winbind user account databases, and provides an introduction to the System Security Services Daemon (SSSD). Read this chapter if you need to configure authentication on your system.
Capítulo 10, OpenSSH describes how to enable a remote login via the SSH protocol. It covers the configuration of the sshd service, as well as a basic usage of the ssh, scp, sftp client utilities. Read this chapter if you need a remote access to a machine.
Parte V, “Servidores”
Esta parte trata varios temas relacionados a los servidores, como el método para configurar un servidor web o cómo compartir archivos y directorios a través de la red.
Capítulo 11, DHCP Servers guides you through the installation of a Dynamic Host Configuration Protocol (DHCP) server and client. Read this chapter if you need to configure DHCP on your system.
Capítulo 12, DNS Servers introduces you to Domain Name System (DNS), explains how to install, configure, run, and administer the BIND DNS server. Read this chapter if you need to configure a DNS server on your system.
Capítulo 13, Servidores web focuses on the Apache HTTP Server 2.2, a robust, full-featured open source web server developed by the Apache Software Foundation. Read this chapter if you need to configure a web server on your system.
Capítulo 14, Mail Servers reviews modern email protocols in use today, and some of the programs designed to send and receive email, including Postfix, Sendmail, Fetchmail, and Procmail. Read this chapter if you need to configure a mail server on your system.
Capítulo 15, Servidores de directorio covers the installation and configuration of OpenLDAP 2.4, an open source implementation of the LDAPv2 and LDAPv3 protocols. Read this chapter if you need to configure a directory server on your system.
Capítulo 16, Servidores de archivos e impresoras guides you through the installation and configuration of Samba, an open source implementation of the Server Message Block (SMB) protocol, and vsftpd, the primary FTP server shipped with Fedora. Additionally, it explains how to use the Printer Configuration tool to configure printers. Read this chapter if you need to configure a file or print server on your system.
Parte VI, “Monitorización y automatizado”
Esta parte describe varias herramientas que permiten a los administradores de sistemas monitorear el rendimiento del sistema, automatizar tareas del sistema e informar de fallos.
Capítulo 17, System Monitoring Tools discusses applications and commands that can be used to retrieve important information about the system. Read this chapter to learn how to gather essential system information.
Capítulo 18, Viewing and Managing Log Files describes the configuration of the rsyslog daemon, and explains how to locate, view, and monitor log files. Read this chapter to learn how to work with log files.
Capítulo 19, Automating System Tasks provides an overview of the cron, at, and batch utilities. Read this chapter to learn how to use these utilities to perform automated tasks.
Capítulo 20, OProfile covers OProfile, a low overhead, system-wide performance monitoring tool. Read this chapter for information how to use OProfile on your system.
Parte VII, “Configuración del kernel, módulos y controladores”
This part covers various tools that assist administrators with kernel customization.
Capítulo 21, Actualización Manual del Kernel provides important information how to manually update a kernel package using the rpm command instead of yum. Read this chapter if you cannot update a kernel package with the Yum package manager.
Capítulo 22, Working with Kernel Modules explains how to display, query, load, and unload kernel modules and their dependencies, and how to set module parameters. Additionally, it covers specific kernel module capabilities such as using multiple Ethernet cards and using channel bonding. Read this chapter if you need to work with kernel modules.
Capítulo 23, The kdump Crash Recovery Service explains how to configure, test, and use the kdump service in Fedora, and provides a brief overview of how to analyze the resulting core dump using the crash debugging utility. Read this chapter to learn how to enable kdump on your system.
Apéndice A, Nombramiento Consistente de Dispositivos de Red
This appendix covers consistent network device naming for network interfaces, a feature that changes the name of network interfaces on a system in order to make locating and differentiating the interfaces easier. Read this appendix to learn more about this feature and how to enable or disable it.
Apéndice B, RPM
This appendix concentrates on the RPM Package Manager (RPM), an open packaging system used by Fedora, and the use of the rpm utility. Read this appendix if you need to use rpm instead of yum.
Apéndice C, El Sistema X Window
Este apéndice abarca la configuración del Sistema de ventanas X, el entorno gráfico que utiliza Fedora. Lea este apéndice si necesita ajustar la configuración de su Sistema de ventanas X.
Apéndice D, The sysconfig Directory
This appendix outlines some of the files and directories located in the /etc/sysconfig/ directory. Read this appendix if you want to learn more about these files and directories, their function, and their contents.
Apéndice E, The proc File System
This appendix explains the concept of a virtual file system, and describes some of the top-level files and directories within the proc file system (that is, the /proc/ directory). Read this appendix if you want to learn more about this file system.

3. Convenciones del Documento

Este manual utiliza varias convenciones para resaltar algunas palabras y frases y llamar la atención sobre ciertas partes específicas de información.
En ediciones PDF y de papel, este manual utiliza tipos de letra procedentes de Liberation Fonts. Liberation Fonts también se utilizan en ediciones de HTML si están instalados en su sistema. Si no, se muestran tipografías alternativas pero equivalentes. Nota: Red Hat Enterprise Linux 5 y siguientes incluyen Liberation Fonts predeterminadas.

3.1. Convenciones Tipográficas

Se utilizan cuatro convenciones tipográficas para llamar la atención sobre palabras o frases específicas. Dichas convenciones y las circunstancias en que se aplican son las siguientes:
Negrita monoespaciado
Utilizada para resaltar la entrada del sistema, incluyendo comandos de shell, nombres de archivo y rutas. También se utiliza para resaltar teclas claves y combinaciones de teclas. Por ejemplo:
Para ver el contenido del archivo my_next_bestselling_novel en su directorio actual de trabajo, escriba el comando cat my_next_bestselling_novel en el intérprete de comandos de shell y pulse Enter para ejecutar el comando.
El ejemplo anterior incluye un nombre de archivo, un comando de shell y una tecla clave. Todo se presenta en negrita-monoespaciado y distinguible gracias al contexto.
Las combinaciones de teclas se pueden distinguir de las teclas claves mediante el guión que conecta cada parte de una combinación de tecla. Por ejemplo:
Pulse Enter para ejecutar el comando.
Pulse Control+Alt+F2 para cambiar a la primera terminal virtual. Pulse Control+Alt+F1 para volver a su sesión de Ventanas-X.
La primera oración resalta la tecla clave determinada que se debe pulsar. La segunda resalta dos conjuntos de tres teclas claves que deben ser presionadas simultáneamente.
Si se discute el código fuente, los nombres de las clase, los métodos, las funciones, los nombres de variables y valores de retorno mencionados dentro de un párrafo serán presentados en Negrita-monoespaciado. Por ejemplo:
Las clases de archivo relacionadas incluyen filename para sistema de archivos, file para archivos y dir para directorios. Cada clase tiene su propio conjunto asociado de permisos.
Negrita proporcional
Esta denota palabras o frases encontradas en un sistema, incluyendo nombres de aplicación, texto de cuadro de diálogo, botones etiquetados, etiquetas de cajilla de verificación y botón de radio; títulos de menú y títulos del sub-menú. Por ejemplo:
Seleccionar SistemaPreferenciasRatón desde la barra del menú principal para lanzar Preferencias de Ratón. En la pestaña de Botones, haga clic en la cajilla ratón de mano izquierda y luego haga clic en Cerrar para cambiar el botón principal del ratón de la izquierda a la derecha (adecuando el ratón para la mano izquierda).
Para insertar un caracter especial en un archivo de gedit, seleccione desde la barra del menú principal AplicacionesAccessoriesMapa de caracteres. Luego, desde la barra de menúes de mapa de caracteres elija BúsquedaHallar…, teclee el nombre del caracter en el campo Búsqueda y haga clic en Siguiente. El caracter buscado se resaltará en la Tabla de caracteres. Haga doble clic en este caracter resaltado para colocarlo en el campo de Texto para copiar y luego haga clic en el botón de Copiar. Ahora regrese a su documento y elija EditarPegar desde la barra de menú de gedit.
El texto anterior incluye nombres de aplicación; nombres y elementos del menú de todo el sistema; nombres de menú de aplicaciones específicas y botones y texto hallados dentro de una interfaz gráfica de usuario, todos presentados en negrita proporcional y distinguibles por contexto.
Itálicas-negrita monoespaciado o Itálicas-negrita proporcional
Ya sea negrita monoespaciado o negrita proporcional, la adición de itálicas indica texto reemplazable o variable. Las itálicas denotan texto que usted no escribe literalmente o texto mostrado que cambia dependiendo de la circunstancia. Por ejemplo:
Para conectar a una máquina remota utilizando ssh, teclee ssh nombredeusuario@dominio.nombre en un intérprete de comandos de shell. Si la máquina remota es example.com y su nombre de usuario en esa máquina es john, teclee ssh john@example.com.
El comando mount -o remount file-system remonta el sistema de archivo llamado. Por ejemplo, para volver a montar el sistema de archivo /home, el comando es mount -o remount /home.
Para ver la versión de un paquete actualmente instalado, utilice el comando rpm -q paquete. Éste entregará el resultado siguiente: paquete-versión-lanzamiento.
Observe las palabras en itálicas y negrita sobre — nombre de usuario, domain.name, sistema de archivo, paquete, versión y lanzamiento. Cada palabra es un marcador de posición, tanto para el texto que usted escriba al ejecutar un comando como para el texto mostrado por el sistema.
Aparte del uso estándar para presentar el título de un trabajo, las itálicas denotan el primer uso de un término nuevo e importante. Por ejemplo:
Publican es un sistema de publicación de DocBook.

3.2. Convenciones del documento

Los mensajes de salida de la terminal o fragmentos de código fuente se distinguen visualmente del texto circundante.
Los mensajes de salida enviados a una terminal se muestran en romano monoespaciado y se presentan así:
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Los listados de código fuente también se muestran en romano monoespaciado, pero se presentan y resaltan de la siguiente manera:
package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[]) 
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }
}

3.3. Notas y Advertencias

Finalmente, utilizamos tres estilos visuales para llamar la atención sobre la información que de otro modo se podría pasar por alto.

Nota

Una nota es una sugerencia, atajo o enfoque alternativo para una tarea determinada. Ignorar una nota no debería tener consecuencias negativas, pero podría perderse de algunos trucos que pueden facilitarle las cosas.

Importante

Los cuadros con el título de importante dan detalles de cosas que se pueden pasar por alto fácilmente: cambios de configuración únicamente aplicables a la sesión actual, o servicios que necesitan reiniciarse antes de que se aplique una actualización. Ignorar estos cuadros no ocasionará pérdida de datos, pero puede causar enfado y frustración.

Advertencia

Las advertencias no deben ignorarse. Ignorarlas muy probablemente ocasionará pérdida de datos.

4. Comentarios

S usted encuentra un error tipográfico en este manual, o si o ha pensado en una forma de mejorar este manual, nos gustaria escuchar sobre usted! Po favor envie un informe a Bugzilla relacionado al producto Fedora Documentation.
Cuando envíe un informe, asegúrese de proveer la siguiente información:
  • Identificador del Manual: system-administrator's-guide
  • Versión número: 17
Si usted tiene una sugerencia para mejorar la documetación, trate de ser lo más específico posible al describirla. Si usted ha encontrado un error, por favor incluya el número de la secciIón y una sección del texto circundante, para poder localizar el error con facilidad.

5. Agradecimientos

Algunas porciones de este texto aparecieron primero en la Guía de implementación, copyright © 2007 Red Hat, Inc., disponible en http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/index.html.
Sección 17.6, “Monitoring Performance with Net-SNMP” se basa en un artículo escrito por Michael Solberg.
A los autores del presente libro les gustaría agradecer a las siguientes personas por sus valiosas contribuciones: Adam Tkáč, Andrew Fitzsimon, Andrius Benokraitis, Brian Cleary Edward Bailey, Garrett LeSage, Jeffrey Fearn, Joe Orton, Joshua Wulf, Karsten Wade, Lucy Ringland, Marcela Mašláňová, Mark Johnson, Michael Behm, Miroslav Lichvár, Radek Vokál, Rahul Kavalapara, Rahul Sundaram, Sandra Moore, Zbyšek Mráz, Jan Včelák, Peter Hutterer, T.C. Hollingsworth y James Antill, entre muchos otros.

Parte I. Configuración básica del sistema

Capítulo 1. Configurando el Lenguaje y el Teclado

Fedora 17 se distribuye con la herramienta de configuración Región and Lenguajel, la cual le permite configurar las disposiciones del teclado, el lenguaje de su ambiente de escritorio, y otras configuraciones regionales. Para utilizar la herramienta, abra la ventana de Configuraciones del Sistema seleccionando AplicacionesHerramientas del SistemaConfiguraciones del Sistema a partir del menu Actividades, y seleccione Región y Lenguaje.

1.1. Cambiando el lenguaje

Para configurar el lenguaje de su escritorio, selecione la etiqueta Lenguaje en la aplicación Región y Lenguaje. Usted vera una corta lista de lenguajes comunes.
Cambiando el lenguaje
Cambiando el lenguaje
Figura 1.1. Cambiando el lenguaje

Por omisión, esta lista contiene solo unos pocos lenguajes disponibles. Para agregar otros lenguajes haga click en el botón + (el signo de adición) que está debajo de la lista. Se abre una ventana de diálogo, la cual le permite seleccionar el lenguaje deseado. La region de ingreso de datos en la parte inferior de la ventana de diálogo le permite reducir el numero de opciones presentadas al filtrar las primeras letras que forman parte del nombre del lenguaje buscado (por ejemplo, slov por el lenguaje Slovak. Una vez que usted escoge el lenguaje, haga clic en el boton Selecionar para confirmar su opción.
Agregando otro lenguaje
Agregando un lenguaje
Figura 1.2. Agregando otro lenguaje

Para escoger un lenguaje en particular de la lista, haga clic rn su nombre para seleccionarlo. Los cambios se harán efectivos la próxima vez que usted se conecte al sistema.

1.2. Cambiando la Fecha, la Hora y el Formato Numérico

Para cmabiar los formatos de la fecha, la hora, los numéros y la moneda, selecione la etiqueta Formatos de la aplicación Región y Lenguaje. Used verá una corta lista de los formatos disponibles.
Cambiando los formatos de la fecha, la hora y los números
Cambiando los formatos de la fecha, la hora y los números
Figura 1.3. Cambiando los formatos de la fecha, la hora y los números

Por omisión esta lista solo contiene un pequeño número de los formatos disponibles. Para agregar otro formato, haga clic en el botón + (el signo de adición) en la parte inferior de la lista. aparece una ventana de diálogo, que le permite seleccionar el formato deseado de acuerdo con una región. El campo de ingreso de datos en la parte inferior de de la ventana de diálogo le permite, reducir el número de opciones presentadas, esto al introducir unas pocas letras del nombre de la región (por ejemplo, slov por Slovakia). Una vez que usted seleccione un región, haga clic en el botón Select para confirmar la opción seleccionada.
Agregando un formato
Agregando un formato
Figura 1.4. Agregando un formato

Para escoger un formato de la lista en particular, haga clic en su nombre para seleccionarlo. Los cambios serán efectivos la próxima vez que ingrese al sistema.

1.3. Cambiando la disposición del teclado

Aunque el programa de instalación le permite al administrador del sistema configurar una disposición del teclado durante la instalación del sistema, la configuración predefinida puede no siempre satisfacer sus necesidades actuales. Para cambiar el teclado predefinido, selecione la etiqueta Disposiciones de la aplicación Región y Lenguaje. Se le presentará una lista con las disposiciones que estan activadas.
Cambiando la disposición del teclado
Cambiando la disposición del teclado
Figura 1.5. Cambiando la disposición del teclado

Para agregar una disposición a la lista, haga clic en el boton + (el signo de adición) en la parte inférior de la lista. aparece una ventana de diálogo, que le permite seleccionar la disposición de teclado deseada. El campo de ingreso de datos en la parte inférior de la ventana de diálogo le permite reducir el numero de opciones presentadas al introducir algunas letras del nombre de la disposición (por ejemplo, slov por una disposición Slovak ). Una vez que usted seleccione una disposición, haga clic en el botón Agregar para confirmar su selección.
Agregando una disposición de teclado
Agregando una disposición de teclado
Figura 1.6. Agregando una disposición de teclado

La primera disposición en la lista se considera siempre la predefinida. Para mover una disposición particular hacia arriba o hacia abajo en la lista, seleccione y haga clic en los botones (la flecha hacia arriba) o (la flecha hacia abajo) respectivamente. Para borrar una disposición, haga clic en el botón (o sea el signo de suatracción). Adicionalmente, seleccionando un botón de opción en el lado derecho de la ventana, usted puede escoger si quiere usar una disposición diferente en cada ventana en la que este trabajando o si quiere la misma disposición para todas las ventanas.
Cuando hay mas de una disposición activa, aparece un indicador de teclado en el pánel, para permitirle cambiar de una disposición a otra.
El indicador de la disposición del teclado
El indicador de la disposición del teclado
Figura 1.7. El indicador de la disposición del teclado

1.4. Viendo la configuración Actual

Para ver la configuracion actual, seleccione la etiqueta Sistema de la aplicación Region and Lenguaje application. You will be presented with a comparison of your own configuration and system-wide settings.
Viendo la configuración actual
Viendo la configuración actual
Figura 1.8. Viendo la configuración actual

Capítulo 2. Configuración de la Fecha y Hora

Este capitulo cubre la configuración de fecha y hora en el sistema Fedora, tanto manual y utilizando el Protocolo de Tiempo de Red (NTP), así como la configuración de las zonas de tiempo adecuadas. Los dos métodos cubiertos son: la configuración de la fecha y hora usando la herramienta de configuración Fecha y Hora , y realizando esto por la linea de comando.

2.1. Usando la herramienta de configuración de fecha y hora

Fedora 17 se distribuye con la herramienta de configuracion Fecha y Hora, la cual le permite cambiar la fecha y la hora del sistema, para configurar la zona horaria utilizada por el systema, y para activar el daemon del protocolo Network Time para sincronizar el reloj del sistema con un servidor de horario. Para arrancar la herramienta, puede escoger seleccionando AplicacionesHerramienta del SystemaConfiguracion del Systema a partir del menu Actividades y seleccione el icono de Fecha y Hora, o bien seleccione con un clic, la hora en el panel Configuración de Fecha y Hora a partir del menu que se despliega.
Herramienta de configuración de la Fecha y la Hora
Herramienta de configuración de la Fecha y la Hora
Figura 2.1. Herramienta de configuración de la Fecha y la Hora

La herramienta esta preparada para aceptar el cambio de la configuración activa. Est es debido a que solo al usuario root se le permite cambiar la fecha y hora del systema. Para desbloquear la herramienta de configuración para efectuar los cambios, haga clic en el boton Desbloquear en la esquina superior derecha de la ventana, y proveer la contraseña correcta al ser requerida.
Para cambiar la hora actual de su sistema, tiene las opciones de configurar el sistema para que sea sincronizado via red o haciendo clic en el interruptor Hora de Red, o bien colocarla manualmente haciendo clic en las flechas que estan arriba y abajo de los numeros. También puede seleccionar la etiqueta 24-horas o bien AM/PM para activar o desactivar el formato horario de 24 horas.
Para cambiar la zona horaria, haga un clic en el mapa, o seleccione la región y ciudad de las listas desplegables Región y Ciudad.
Para cambiar la fecha actual del sistema, selecciona un mes de la lista abajo de la hora, y use las flechas hacia arriba y abajo para selecionar el día y el año.
Los cambios tomo efecto de inmediato.

2.2. Usando las herramientas de línea de comando

Fedora 17 provee herramientas de consola o terminal que le permiten configurar la fecha y la hora tanto manualmente asi como con la utilización del protocolo NTP.

2.2.1. Cambiando la fecha

Para cambiar la fecha del sistema, escriba lo siguiente en la consola o terminal como usuario root:
date +%D -s YYYY-MM-DD
…donde YYYY es el año escrito con 4 cifras, MM es el mes con dos cifras, y DD es el día del mes con dos cifras. Por ejemplo, para cambiar la fecha al 2 de Junio del 2010, escriba:
~]# date +%D -s 2010-06-02
Usted puede vérificar la fecha actual por medio del comando date sin ningun otro argumento adicional.

2.2.2. Cambiando la hora

Para cambiar la hora actual, utilice el siguiente comando como usuario root:
date +%T -s HH:MM:SS
…donde HH representa una hora, MM es un minuto, y SS es un segundo, todo esto escrito en un formato de dos cifras. Si el reloj de sus sistema esta configurado para utilizar UTC (Coordinated Universal Time - Sistema Coordinado Universal), agregue tambien la suiguiente opción:
date +%T -s HH:MM:SS -u
Para el caso, de configurar el reloj a las 11:26 PM usando el UTC, escriba:
~]# date +%T -s 23:26:00 -u
Usted puede vérificar la fecha actual por medio del comando date sin ningun otro argumento adicional.

2.2.3. Configurando el Protocolo de Tiempo en Red

Opuesto a la configuración manual descrita anteriormente, usted puede sincronizar el reloj con un servidor remoto a travez de la red usando el protocolo (NTP por sus siglas en Ingles). Para una sincronización de sola vez, use el comando ntpdate:
  1. Verifique que el servidor NTP sea accesible ejecutando el comando ntpdate de la siguiente manera:
    ntpdate -q server_address
    Por ejemplo, para conectarse al 0.fedora.pool.ntp.org, escriba:
    ~]$ ntpdate -q 0.fedora.pool.ntp.org
    server 204.15.208.61, stratum 2, offset -39.275438, delay 0.16083
    server 69.65.40.29, stratum 2, offset -39.269122, delay 0.17191
    server 148.167.132.201, stratum 2, offset -39.270239, delay 0.20482
    17 Oct 17:41:09 ntpdate[10619]: step time server 204.15.208.61 offset -39.275438 sec
  2. Cuando encuentre un servidor satisfactorio, en tanto que usuario root, emita el comando ntpdate seguido con una o mas direcciones de servidor:
    ntpdate server_address…
    Por ejemplo:
    ~]# ntpdate 0.fedora.pool.ntp.org 1.fedora.pool.ntp.org
    17 Oct 17:42:13 ntpdate[10669]: step time server 204.15.208.61 offset -39.275436 sec
    Si no se presenta un mensaje de error, el sistema esta configurado. Usted puede verificar la hora actual por medio del comando date sin ningun argumento adicional.
  3. En la mayoria de los casos estos pasos son suficientes. Solamente si usted realmente necesita que uno o mas servicios del sistema utilicen siempre la hora correcta, active ntpdate para que arranque al inicio corriendo el siguiente comando como usuario root:
    systemctl enable ntpdate.service
    Para mayor informacion acerca de los servicios del sistema y su configuración, referirse a Capítulo 8, Services and Daemons.

    Nota

    Si la sincronización con el servidor de tiempo falla al momento de inicio del sistema, usted puede encontrar los mensajes de error en /var/log/boot.log, intente adicionando la siguiente linea en el archivo /etc/sysconfig/network:
    NETWORKWAIT=1
Sin embargo, la manera mas conveniente es configurar el demonio ntpd para sincronizar automaticamente en el momento de inicio:
  1. As root, abra el archivo de configuración NTP /etc/ntp.conf en un editor de texto, si aún no existe se creará un nuevo archivo.
  2. Adiciona o edita la lista de servidores NTP publicos. Si usted esta usando Fedora 17,el archivo deberia contener las siguientes linea, pero usted puede adicionar o crecer la lista de acuerdo a sus necesidades:
    server 0.fedora.pool.ntp.org iburst
    server 1.fedora.pool.ntp.org iburst
    server 2.fedora.pool.ntp.org iburst

    Mejorando el desempeño de la sicronización inicial

    Para iniciar mas rápido la sincronización, se recomienda que la instrucción iburst sea adicionada al final de la linea de cada servidor.
  3. En el mismo archivo, adicione los permisos necesarios, dando uso sin restriciones solo al localhost:
    restrict default kod nomodify notrap nopeer noquery
    restrict -6 default kod nomodify notrap nopeer noquery
    restrict 127.0.0.1
    restrict -6 ::1
  4. Guarde los cambios, salga del editor, y reinicie el demonio NTP:
    systemctl restart ntpd.service
  5. Adicionalmente, asegurece que la instrucción ntpd inicie al encender el sistema:
    systemctl enable ntpd.service

2.3. Recursos adicionales

Para mayor información acerca de la configuración de la fecha y hora referirse a los siguentes recursos:

2.3.1. Documentación instalada

  • date(1) — La pagina del manual de la utilidad date.
  • ntpdate(8) — La pagina del manual de la utilidad ntpdate.
  • ntpd(8) — La pagina del manual del servicio ntpd.

Capítulo 3. Managing Users and Groups

The control of users and groups is a core element of Fedora system administration. This chapter explains how to add, manage, and delete users and groups in the graphical user interface and on the command line, and covers advanced topics, such as enabling password aging or creating group directories.

3.1. Introduction to Users and Groups

While users can be either people (meaning accounts tied to physical users) or accounts which exist for specific applications to use, groups are logical expressions of organization, tying users together for a common purpose. Users within a group can read, write, or execute files owned by that group.
Each user is associated with a unique numerical identification number called a user ID (UID). Likewise, each group is associated with a group ID (GID). A user who creates a file is also the owner and group owner of that file. The file is assigned separate read, write, and execute permissions for the owner, the group, and everyone else. The file owner can be changed only by root, and access permissions can be changed by both the root user and file owner.
Additionally, Fedora supports access control lists (ACLs) for files and directories which allow permissions for specific users outside of the owner to be set. Refer to For more information about this feature, refer to the Access Control Lists chapter of the Storage Administration Guide.

3.1.1. Grupos de usuario privado

Fedora uses a user private group (UPG) scheme, which makes UNIX groups easier to manage. A user private group is created whenever a new user is added to the system. It has the same name as the user for which it was created and that user is the only member of the user private group.
User private groups make it safe to set default permissions for a newly created file or directory, allowing both the user and the group of that user to make modifications to the file or directory.
The setting which determines what permissions are applied to a newly created file or directory is called a umask and is configured in the /etc/bashrc file. Traditionally on UNIX systems, the umask is set to 022, which allows only the user who created the file or directory to make modifications. Under this scheme, all other users, including members of the creator's group, are not allowed to make any modifications. However, under the UPG scheme, this group protection is not necessary since every user has their own private group.

3.1.2. Contraseñas Shadow

Especially in environments with multiple users, it is very important to use shadow passwords provided by the shadow-utils package to enhance the security of system authentication files. For this reason, the installation program enables shadow passwords by default.
The following is a list of the advantages shadow passwords have over the traditional way of storing passwords on UNIX-based systems:
  • Shadow passwords improve system security by moving encrypted password hashes from the world-readable /etc/passwd file to /etc/shadow, which is readable only by the root user.
  • Shadow passwords store information about password aging.
  • Shadow passwords allow the /etc/login.defs file to enforce security policies.
Most utilities provided by the shadow-utils package work properly whether or not shadow passwords are enabled. However, since password aging information is stored exclusively in the /etc/shadow file, any commands which create or modify password aging information do not work. The following is a list of utilities and commands that do not work without first enabling shadow passwords:
  • The chage utility.
  • The gpasswd utility.
  • The usermod command with the -e or -f option.
  • The useradd command with the -e or -f option.

3.2. Using the User Accounts Tool

The User Accounts configuration tool allows you to view, modify, add, and delete local users. To run the tool, select ApplicationsSystem ToolsSystem Settings from the Activities menu and click the User Accounts icon.
The User Accounts configuration tool
The User Accounts configuration tool
Figura 3.1. The User Accounts configuration tool

By default, the tool only allows you to change certain settings regarding your account. This is because only the root user is allowed to configure users and groups. To unlock the configuration tool for all kinds of changes, click the Unlock button in the top-right corner of the window, and provide the correct password when prompted.

3.2.1. Configuring an Account

To change the image associated with an account, click the icon next to the account name and either select a picture from the pulldown list, or click Browse for more pictures... to use an image from your local drive.
To change the name associated with an account, click the name next to the icon to edit it.
To change the account type, click the text next to the Account type label. Note that this change requires the configuration tool to be unlocked even if you are changing your own account.
To change the default language for an account, click the text next to the Language label and select a language from the list.
To change the password, click the field next to the Password label. A dialog box appears, allowing you to set the new password. Note that the current password must be provided in order to confirm the change. Once done, click the Change button to save the change.
Changing the password
Changing the password
Figura 3.2. Changing the password

Password security advice

It is advisable to use a much longer password, as this makes it more difficult for an intruder to guess it and access the account without permission. It is also recommended that the password not be based on a dictionary term: use a combination of letters, numbers and special characters.
Finally, to set up automatic login for a particular account, enable the Automatic Login switch. The configuration tool must be unlocked to make this change.

3.2.2. Añadir un nuevo usuario

To add a new user, make sure the configuration tool is unlocked, and click the + button (that is, the plus sign) below the account list. A dialog window appears, allowing you to supply user details.
Creating a new account
Creating a new account
Figura 3.3. Creating a new account

Take the following steps to create an account:
  1. Select an account type from the Account type pulldown list. Available account types are Administrator and Standard (the default option).
  2. Fill in the Full name input field to set the name associated with the account. This name will be used by the login manager, and will be displayed on the panel.
  3. Either select a suggested username from the Username pulldown list, or fill in the corresponding input field.
  4. Click the Create button to confirm the settings.
Fedora uses a user private group (UPG) scheme. The UPG scheme does not add or change anything in the standard UNIX way of handling groups; it offers a new convention. Whenever you create a new user, a unique group with the same name as the user is created.
When a new account is created, default configuration files are copied from the /etc/skel/ directory into the new home directory.

3.2.3. Removing a User

To remove a user, make sure the configuration tool is unlocked, select the desired account from the account list, and click the button (that is, the minus sign) below the account list. A dialog window appears, allowing you to confirm or cancel the change.
Removing an account
Removing an account
Figura 3.4. Removing an account

To delete files and directories that belong to the user (that is, the home directory, mail spool, and temporary files), click the Delete Files button. To keep these files intact and only delete the user account, click Keep Files. To abort the deletion, click Cancel.

3.3. Using the User Manager Tool

The User Manager application allows you to view, modify, add, and delete local users and groups in the graphical user interface. To start the application, either select ApplicationsOtherUsers and Groups from the Activities menu, or type system-config-users at a shell prompt. Note that unless you have superuser privileges, the application will prompt you to authenticate as root.

3.3.1. Viewing Users and Groups

The main window of the User Manager is divided into two tabs: The Users tab provides a list of local users along with additional information about their user ID, primary group, home directory, login shell, and full name. The Groups tab provides a list of local groups with information about their group ID and group members.
Viewing users and groups
Viewing users and groups
Figura 3.5. Viewing users and groups

To find a specific user or group, type the first few letters of the name in the Search filter field and either press Enter, or click the Apply filter button. You can also sort the items according to any of the available columns by clicking the column header.
Fedora reserves user and group IDs below 1000 for system users and groups. By default, the User Manager does not display the system users. To view all users and groups, select EditPreferences to open the Preferences dialog box, and clear the Hide system users and groups check box.

3.3.2. Añadir un nuevo usuario

To add a new user, click the Add User button. A window as shown in Figura 3.6, “Adding a new user” appears.
Adding a new user
Adding a new user
Figura 3.6. Adding a new user

The Add New User dialog box allows you to provide information about the newly created user. In order to create a user, enter the username and full name in the appropriate fields and then type the user's password in the Password and Confirm Password fields. The password must be at least six characters long.

Password security advice

It is advisable to use a much longer password, as this makes it more difficult for an intruder to guess it and access the account without permission. It is also recommended that the password not be based on a dictionary term: use a combination of letters, numbers and special characters.
The Login Shell pulldown list allows you to select a login shell for the user. If you are not sure which shell to select, accept the default value of /bin/bash.
By default, the User Manager application creates the home directory for a new user in /home/username/. You can choose not to create the home directory by clearing the Create home directory check box, or change this directory by editing the content of the Home Directory text box. Note that when the home directory is created, default configuration files are copied into it from the /etc/skel/ directory.
Fedora uses a user private group (UPG) scheme. Whenever you create a new user, a unique group with the same name as the user is created by default. If you do not want to create this group, clear the Create a private group for the user check box.
To specify a user ID for the user, select Specify user ID manually. If the option is not selected, the next available user ID above 1000 is assigned to the new user. Because Fedora reserves user IDs below 1000 for system users, it is not advisable to manually assign user IDs 1–999.
Clicking the OK button creates the new user. To configure more advanced user properties, such as password expiration, modify the user's properties after adding the user.

3.3.3. Añadir un nuevo grupo

To add a new user group, select Add Group from the toolbar. A window similar to Figura 3.7, “Nuevo grupo” appears. Type the name of the new group. To specify a group ID for the new group, select Specify group ID manually and select the GID. Note that Fedora also reserves group IDs lower than 1000 for system groups.
Nuevo grupo
Crear un nuevo grupo
Figura 3.7. Nuevo grupo

Click OK to create the group. The new group appears in the group list.

3.3.4. Modificar las propiedades del usuario

To view the properties of an existing user, click on the Users tab, select the user from the user list, and click Properties from the menu (or choose FileProperties from the pulldown menu). A window similar to Figura 3.8, “Propiedades del usuario” appears.
Propiedades del usuario
Modificar las propiedades del usuario
Figura 3.8. Propiedades del usuario

The User Properties window is divided into multiple tabbed pages:
  • User Data — Shows the basic user information configured when you added the user. Use this tab to change the user's full name, password, home directory, or login shell.
  • Account Info — Select Enable account expiration if you want the account to expire on a certain date. Enter the date in the provided fields. Select Local password is locked to lock the user account and prevent the user from logging into the system.
  • Password Info — Displays the date that the user's password last changed. To force the user to change passwords after a certain number of days, select Enable password expiration and enter a desired value in the Days before change required: field. The number of days before the user's password expires, the number of days before the user is warned to change passwords, and days before the account becomes inactive can also be changed.
  • Groups — Allows you to view and configure the Primary Group of the user, as well as other groups that you want the user to be a member of.

3.3.5. Modificar las propiedades del grupo

To view the properties of an existing group, select the group from the group list and click Properties from the menu (or choose FileProperties from the pulldown menu). A window similar to Figura 3.9, “Propiedades del grupo” appears.
Propiedades del grupo
Modificar las propiedades del grupo
Figura 3.9. Propiedades del grupo

The Group Users tab displays which users are members of the group. Use this tab to add or remove users from the group. Click OK to save your changes.

3.4. Using Command Line Tools

The easiest say to manage users and groups on Fedora is to use the User Manager application as described in Sección 3.3, “Using the User Manager Tool”. However, if you prefer command line tools or do not have the X Window System installed, you can use command line utilities that are listed in Tabla 3.1, “Command line utilities for managing users and groups”.
Tabla 3.1. Command line utilities for managing users and groups
Utilities Descripción
useradd, usermod, userdel Standard utilities for adding, modifying, and deleting user accounts.
groupadd, groupmod, groupdel Standard utilities for adding, modifying, and deleting groups.
gpasswd Standard utility for administering the /etc/group configuration file.
pwck, grpck Utilities that can be used for verification of the password, group, and associated shadow files.
pwconv, pwunconv Utilities that can be used for the conversion of passwords to shadow passwords, or back from shadow passwords to standard passwords.

3.4.1. Añadir un nuevo usuario

To add a new user to the system, typing the following at a shell prompt as root:
useradd [options] username
…where options are command line options as described in Tabla 3.2, “useradd command line options”.
By default, the useradd command creates a locked user account. To unlock the account, run the following command as root to assign a password:
passwd username
Optionally, you can set password aging policy. Refer to Sección 3.4.3, “Enabling Password Aging” for information on how to enable password aging.
Tabla 3.2. useradd command line options
Opciones Descripción
-c 'comment' comment can be replaced with any string. This option is generally used to specify the full name of a user.
-d home_directory Home directory to be used instead of default /home/username/.
-e date Date for the account to be disabled in the format YYYY-MM-DD.
-f days Number of days after the password expires until the account is disabled. If 0 is specified, the account is disabled immediately after the password expires. If -1 is specified, the account is not be disabled after the password expires.
-g group_name Nombre o número del grupo para el grupo predeterminado del usuario. El grupo debe existir antes de que sea especificado aquí.
-G group_list Lista de nombres de los grupos adicionales (además del predeterminado), separados por comas, de los cuales el usuario es miembro. Los grupos deben existir antes que sea especificado aquí.
-m Crea el directorio principal si no existe
-M No crea el directorio principal.
-N No crea un grupo privado de usuario para el usuario
-p password The password encrypted with crypt.
-r Create a system account with a UID less than 1000 and without a home directory.
-s User's login shell, which defaults to /bin/bash.
-u uid User ID for the user, which must be unique and greater than 999.

Explicación del proceso

The following steps illustrate what happens if the command useradd juan is issued on a system that has shadow passwords enabled:
  1. A new line for juan is created in /etc/passwd:
    juan:x:501:501::/home/juan:/bin/bash
    The line has the following characteristics:
    • It begins with the username juan.
    • There is an x for the password field indicating that the system is using shadow passwords.
    • A UID greater than 999 is created. Under Fedora, UIDs below 1000 are reserved for system use and should not be assigned to users.
    • A GID greater than 999 is created. Under Fedora, GIDs below 1000 are reserved for system use and should not be assigned to users.
    • The optional GECOS information is left blank.
    • The home directory for juan is set to /home/juan/.
    • The default shell is set to /bin/bash.
  2. A new line for juan is created in /etc/shadow:
    juan:!!:14798:0:99999:7:::
    The line has the following characteristics:
    • It begins with the username juan.
    • Two exclamation marks (!!) appear in the password field of the /etc/shadow file, which locks the account.

      Nota

      If an encrypted password is passed using the -p flag, it is placed in the /etc/shadow file on the new line for the user.
    • Se configura la contraseña para que no caduque nunca.
  3. A new line for a group named juan is created in /etc/group:
    juan:x:501:
    A group with the same name as a user is called a user private group. For more information on user private groups, refer to Sección 3.1.1, “Grupos de usuario privado”.
    The line created in /etc/group has the following characteristics:
    • It begins with the group name juan.
    • An x appears in the password field indicating that the system is using shadow group passwords.
    • The GID matches the one listed for user juan in /etc/passwd.
  4. A new line for a group named juan is created in /etc/gshadow:
    juan:!::
    The line has the following characteristics:
    • It begins with the group name juan.
    • An exclamation mark (!) appears in the password field of the /etc/gshadow file, which locks the group.
    • Todos los otros campos quedan en blanco.
  5. A directory for user juan is created in the /home/ directory:
    ~]# ls -l /home
    total 4
    drwx------. 4 juan juan 4096 Mar  3 18:23 juan
    This directory is owned by user juan and group juan. It has read, write, and execute privileges only for the user juan. All other permissions are denied.
  6. The files within the /etc/skel/ directory (which contain default user settings) are copied into the new /home/juan/ directory:
    ~]# ls -la /home/juan
    total 28
    drwx------. 4 juan juan 4096 Mar  3 18:23 .
    drwxr-xr-x. 5 root root 4096 Mar  3 18:23 ..
    -rw-r--r--. 1 juan juan   18 Jun 22  2010 .bash_logout
    -rw-r--r--. 1 juan juan  176 Jun 22  2010 .bash_profile
    -rw-r--r--. 1 juan juan  124 Jun 22  2010 .bashrc
    drwxr-xr-x. 2 juan juan 4096 Jul 14  2010 .gnome2
    drwxr-xr-x. 4 juan juan 4096 Nov 23 15:09 .mozilla
At this point, a locked account called juan exists on the system. To activate it, the administrator must next assign a password to the account using the passwd command and, optionally, set password aging guidelines.

3.4.2. Añadir un nuevo grupo

To add a new group to the system, type the following at a shell prompt as root:
groupadd [options] group_name
…where options are command line options as described in Tabla 3.3, “groupadd command line options”.
Tabla 3.3. groupadd command line options
Opciones Descripción
-f, --force When used with -g gid and gid already exists, groupadd will choose another unique gid for the group.
-g gid Group ID for the group, which must be unique and greater than 999.
-K, --key key=value Override /etc/login.defs defaults.
-o, --non-unique Allow to create groups with duplicate.
-p, --password password Use this encrypted password for the new group.
-r Create a system group with a GID less than 1000.

3.4.3. Enabling Password Aging

For security reasons, it is advisable to require users to change their passwords periodically. This can either be done when adding or editing a user on the Password Info tab of the User Manager application, or by using the chage command.

Shadow passwords must be enabled to use chage

Shadow passwords must be enabled to use the chage command. For more information, see Sección 3.1.2, “Contraseñas Shadow”.
To configure password expiration for a user from a shell prompt, run the following command as root:
chage [options] username
…where options are command line options as described in Tabla 3.4, “chage command line options”. When the chage command is followed directly by a username (that is, when no command line options are specified), it displays the current password aging values and allows you to change them interactively.
Tabla 3.4. chage command line options
Opciones Descripción
-d days Specifies the number of days since January 1, 1970 the password was changed.
-E date Especifica la fecha en la cual la cuenta es bloqueada, en el formato AAAA-MM-DD. También se puede usar el número de días transcurridos desde el 1 de enero de 1970 en lugar de la fecha.
-I days Specifies the number of inactive days after the password expiration before locking the account. If the value is 0, the account is not locked after the password expires.
-l Lists current account aging settings.
-m days Specify the minimum number of days after which the user must change passwords. If the value is 0, the password does not expire.
-M days Specify the maximum number of days for which the password is valid. When the number of days specified by this option plus the number of days specified with the -d option is less than the current day, the user must change passwords before using the account.
-W days Especifica el número de días antes de la fecha de expiración de la contraseña para advertir al usuario.

You can configure a password to expire the first time a user logs in. This forces users to change passwords immediately.
  1. Set up an initial password. There are two common approaches to this step: you can either assign a default password, or you can use a null password.
    To assign a default password, type the following at a shell prompt as root:
    passwd username
    To assign a null password instead, use the following command:
    passwd -d username

    Avoid using null passwords whenever possible

    Using a null password, while convenient, is a highly insecure practice, as any third party can log in first and access the system using the insecure username. Always make sure that the user is ready to log in before unlocking an account with a null password.
  2. Force immediate password expiration by running the following command as root:
    chage -d 0 username
    Este comando coloca el valor para la fecha en que la contraseña fué cambiada la última vez (Enero 1, 1970). Este valor obliga a la expiración inmediata de la contraseña sin tomar en cuenta la política de vencimiento, si existe alguna.
Upon the initial log in, the user is now prompted for a new password.

3.4.4. Enabling Automatic Logouts

Especially when the user is logged in as root, an unattended login session may pose a significant security risk. To reduce this risk, you can configure the system to automatically log out idle users after a fixed period of time:
  1. Make sure the screen package is installed. You can do so by running the following command as root:
    yum install screen
    For more information on how to install packages in Fedora, refer to Sección 4.2.4, “Installing Packages”.
  2. As root, add the following line at the beginning of the /etc/profile file to make sure the processing of this file cannot be interrupted:
    trap "" 1 2 3 15
  3. Add the following lines at the end of the /etc/profile file to start a screen session each time a user logs in to a virtual console or remotely:
    SCREENEXEC="screen"
    if [ -w $(tty) ]; then
      trap "exec $SCREENEXEC" 1 2 3 15
      echo -n 'Starting session in 10 seconds'
      sleep 10
      exec $SCREENEXEC
    fi
    Note that each time a new session starts, a message will be displayed and the user will have to wait ten seconds. To adjust the time to wait before starting a session, change the value after the sleep command.
  4. Add the following lines to the /etc/screenrc configuration file to close the screen session after a given period of inactivity:
    idle 120 quit
    autodetach off
    This will set the time limit to 120 seconds. To adjust this limit, change the value after the idle directive.
    Alternatively, you can configure the system to only lock the session by using the following lines instead:
    idle 120 lockscreen
    autodetach off
    This way, a password will be required to unlock the session.
The changes take effect the next time a user logs in to the system.

3.4.5. Creating Group Directories

System administrators usually like to create a group for each major project and assign people to the group when they need to access that project's files. With this traditional scheme, file managing is difficult; when someone creates a file, it is associated with the primary group to which they belong. When a single person works on multiple projects, it becomes difficult to associate the right files with the right group. However, with the UPG scheme, groups are automatically assigned to files created within a directory with the setgid bit set. The setgid bit makes managing group projects that share a common directory very simple because any files a user creates within the directory are owned by the group which owns the directory.
For example, a group of people need to work on files in the /opt/myproject/ directory. Some people are trusted to modify the contents of this directory, but not everyone.
  1. As root, create the /opt/myproject/ directory by typing the following at a shell prompt:
    mkdir /opt/myproject
  2. Add the myproject group to the system:
    groupadd myproject
  3. Associate the contents of the /opt/myproject/ directory with the myproject group:
    chown root:myproject /opt/myproject
  4. Allow users to create files within the directory, and set the setgid bit:
    chmod 2775 /opt/myproject
At this point, all members of the myproject group can create and edit files in the /opt/myproject/ directory without the administrator having to change file permissions every time users write new files. To verify that the permissions have been set correctly, run the following command:
~]# ls -l /opt
total 4
drwxrwsr-x. 3 root myproject 4096 Mar  3 18:31 myproject

3.5. Recursos adicionales

Refer to the following resources for more information about managing users and groups.

3.5.1. Documentación instalada

For information about various utilities for managing users and groups, refer to the following manual pages:
  • chage(1) — A command to modify password aging policies and account expiration.
  • gpasswd(1) — A command to administer the /etc/group file.
  • groupadd(8) — A command to add groups.
  • grpck(8) — A command to verify the /etc/group file.
  • groupdel(8) — A command to remove groups.
  • groupmod(8) — A command to modify group membership.
  • pwck(8) — A command to verify the /etc/passwd and /etc/shadow files.
  • pwconv(8) — A tool to convert standard passwords to shadow passwords.
  • pwunconv(8) — A tool to convert shadow passwords to standard passwords.
  • useradd(8) — A command to add users.
  • userdel(8) — A command to remove users.
  • usermod(8) — A command to modify users.
For information about related configuration files, see:
  • group(5) — The file containing group information for the system.
  • passwd(5) — The file containing user information for the system.
  • shadow(5) — The file containing passwords and account expiration information for the system.

Parte II. Gestión de paquetes

Todo software en un sistema Fedora está dividido en paquetes RPM, los cuales pueden ser instalados, actualizados o eliminados. Este apartado describe cómo manejar estos paquetes en Fedora usando tanto el gestor de paquetes Yum como PackageKit.

Capítulo 4. Yum

Yum is the The Fedora Project package manager that is able to query for information about packages, fetch packages from repositories, install and uninstall packages using automatic dependency resolution, and update an entire system to the latest available packages. Yum performs automatic dependency resolution on packages you are updating, installing or removing, and thus is able to automatically determine, fetch and install all available dependent packages. Yum can be configured with new, additional repositories, or package sources, and also provides many plug-ins which enhance and extend its capabilities. Yum is able to perform many of the same tasks that RPM can; additionally, many of the command line options are similar. Yum enables easy and simple package management on a single machine or on groups of them.

Gestión segura de paquetes con paquetes firmados con GPG

Yum provides secure package management by enabling GPG (Gnu Privacy Guard; also known as GnuPG) signature verification on GPG-signed packages to be turned on for all package repositories (i.e. package sources), or for individual repositories. When signature verification is enabled, Yum will refuse to install any packages not GPG-signed with the correct key for that repository. This means that you can trust that the RPM packages you download and install on your system are from a trusted source, such as The Fedora Project, and were not modified during transfer. Refer to Sección 4.3, “Configurando Yum y repositorios de Yum” for details on enabling signature-checking with Yum, or Sección B.3, “Revisando la firma de los paquetes” for information on working with and verifying GPG-signed RPM packages in general.
Yum also enables you to easily set up your own repositories of RPM packages for download and installation on other machines.
Learning Yum is a worthwhile investment because it is often the fastest way to perform system administration tasks, and it provides capabilities beyond those provided by the PackageKit graphical package management tools. Refer to Capítulo 5, PackageKit for details on using PackageKit.

Yum y privilegios de superusuario

You must have superuser privileges in order to use yum to install, update or remove packages on your system. All examples in this chapter assume that you have already obtained superuser privileges by using either the su or sudo command.

4.1. Para la comprobación y actualización de paquetes

4.1.1. comprobación de actualizaciones

To see which installed packages on your system have updates available, use the following command:
yum check-update
Por ejemplo:
~]# yum check-update
Loaded plugins: langpacks, presto, refresh-packagekit

PackageKit.x86_64                    0.6.14-2.fc15                 fedora
PackageKit-command-not-found.x86_64  0.6.14-2.fc15                 fedora
PackageKit-device-rebind.x86_64      0.6.14-2.fc15                 fedora
PackageKit-glib.x86_64               0.6.14-2.fc15                 fedora
PackageKit-gstreamer-plugin.x86_64   0.6.14-2.fc15                 fedora
PackageKit-gtk-module.x86_64         0.6.14-2.fc15                 fedora
PackageKit-gtk3-module.x86_64        0.6.14-2.fc15                 fedora
PackageKit-yum.x86_64                0.6.14-2.fc15                 fedora
PackageKit-yum-plugin.x86_64         0.6.14-2.fc15                 fedora
gdb.x86_64                           7.2.90.20110429-36.fc15       fedora
kernel.x86_64                        2.6.38.6-26.fc15              fedora
rpm.x86_64                           4.9.0-6.fc15                  fedora
rpm-libs.x86_64                      4.9.0-6.fc15                  fedora
rpm-python.x86_64                    4.9.0-6.fc15                  fedora
yum.noarch                           3.2.29-5.fc15                 fedora
The packages in the above output are listed as having updates available. The first package in the list is PackageKit, the graphical package manager. The line in the example output tells us:
  • PackageKit — the name of the package
  • x86_64 — the CPU architecture the package was built for
  • 0.6.14 — la versión del paquete actualizado a ser instalado.
  • fedora — the repository in which the updated package is located
The output also shows us that we can update the kernel (the kernel package), Yum and RPM themselves (the yum and rpm packages), as well as their dependencies (such as the kernel-firmware, rpm-libs, and rpm-python packages), all using yum.

4.1.2. Actualizando paquetes

You can choose to update a single package, multiple packages, or all packages at once. If any dependencies of the package (or packages) you update have updates available themselves, then they are updated too.

Actualizando un solo paquete

To update a single package, run the following command as root:
yum update package_name
For example, to update the udev package, type:
~]# yum update udev
Loaded plugins: langpacks, presto, refresh-packagekit
Updating Red Hat repositories.
INFO:rhsm-app.repolib:repos updated: 0
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package gdb.x86_64 0:7.2.90.20110411-34.fc15 will be updated
---> Package gdb.x86_64 0:7.2.90.20110429-36.fc15 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package     Arch         Version                          Repository      Size
================================================================================
Updating:
 gdb         x86_64       7.2.90.20110429-36.fc15          fedora         1.9 M

Transaction Summary
================================================================================
Upgrade       1 Package(s)

Total download size: 1.9 M
Is this ok [y/N]:
Esta salida contiene varios elementos de interés:
  1. Loaded plugins:yum always informs you which Yum plug-ins are installed and enabled. Here, yum is using the langpacks, presto, and refresh-packagekit plug-ins. Refer to Sección 4.4, “Yum Plug-ins” for general information on Yum plug-ins, or to Sección 4.4.3, “Plug-in Descriptions” for descriptions of specific plug-ins.
  2. gdb.x86_64 — you can download and install new gdb package.
  3. yum presents the update information and then prompts you as to whether you want it to perform the update; yum runs interactively by default. If you already know which transactions yum plans to perform, you can use the -y option to automatically answer yes to any questions yum may ask (in which case it runs non-interactively). However, you should always examine which changes yum plans to make to the system so that you can easily troubleshoot any problems that might arise.
    If a transaction does go awry, you can view Yum's transaction history by using the yum history command as described in Sección 4.2.6, “Working with Transaction History”.

Updating and installing kernels with Yum

yum always installs a new kernel in the same sense that RPM installs a new kernel when you use the command rpm -i kernel. Therefore, you do not need to worry about the distinction between installing and upgrading a kernel package when you use yum: it will do the right thing, regardless of whether you are using the yum update or yum install command.
When using RPM, on the other hand, it is important to use the rpm -i kernel command (which installs a new kernel) instead of rpm -u kernel (which replaces the current kernel). Refer to Sección B.2.2, “Installing and Upgrading” for more information on installing/updating kernels with RPM.

Actualizando todos los paquetes y sus dependencias

To update all packages and their dependencies, simply enter yum update (without any arguments):
yum update

Actualizando Paquetes de Seguridad

Discovering which packages have security updates available and then updating those packages quickly and easily is important. Yum provides the plug-in for this purpose. The security plug-in extends the yum command with a set of highly-useful security-centric commands, subcommands and options. Refer to Sección 4.4.3, “Plug-in Descriptions” for specific information.

4.1.3. Conservando cambios en los Archivos de Configuracion

You will inevitably make changes to the configuration files installed by packages as you use your Fedora system. RPM, which Yum uses to perform changes to the system, provides a mechanism for ensuring their integrity. Refer to Sección B.2.2, “Installing and Upgrading” for details on how to manage changes to configuration files across package upgrades.

4.2. Paquetes y grupos de paquetes

4.2.1. Buscando paquetes

You can search all RPM package names, descriptions and summaries by using the following command:
yum search term
This command displays the list of matches for each term. For example, to list all packages that match meld or kompare, type:
~]# yum search meld kompare
Loaded plugins: langpacks, presto, refresh-packagekit
============================== N/S Matched: meld ===============================
meld.noarch : Visual diff and merge tool
python-meld3.x86_64 : HTML/XML templating system for Python

============================= N/S Matched: kompare =============================
komparator.x86_64 : Kompare and merge two folders

  Name and summary matches only, use "search all" for everything.
The yum search command is useful for searching for packages you do not know the name of, but for which you know a related term.

4.2.2. Listando paquetes

yum list and related commands provide information about packages, package groups, and repositories.
All of Yum's list commands allow you to filter the results by appending one or more glob expressions as arguments. Glob expressions are normal strings of characters which contain one or more of the wildcard characters * (which expands to match any character multiple times) and ? (which expands to match any one character).

Filtering results with glob expressions

Be careful to escape the glob expressions when passing them as arguments to a yum command, otherwise the Bash shell will interpret these expressions as pathname expansions, and potentially pass all files in the current directory that match the globs to yum. To make sure the glob expressions are passed to yum as intended, either:
  • escape the wildcard characters by preceding them with a backslash character
  • double-quote or single-quote the entire glob expression.
yum list glob_expression
Lists information on installed and available packages matching all glob expressions.
Ejemplo 4.1. Listing all ABRT addons and plug-ins using glob expressions
Packages with various ABRT addons and plug-ins either begin with abrt-addon-, or abrt-plugin-. To list these packages, type the following at a shell prompt:
~]# yum list abrt-addon\* abrt-plugin\*
Loaded plugins: langpacks, presto, refresh-packagekit
Installed Packages
abrt-addon-ccpp.x86_64               2.0.2-5.fc15     @fedora
abrt-addon-kerneloops.x86_64         2.0.2-5.fc15     @fedora
abrt-addon-python.x86_64             2.0.2-5.fc15     @fedora
abrt-plugin-bugzilla.x86_64          2.0.2-5.fc15     @fedora
abrt-plugin-logger.x86_64            2.0.2-5.fc15     @fedora
Available Packages
abrt-plugin-mailx.x86_64             2.0.2-5.fc15     updates
abrt-plugin-reportuploader.x86_64    2.0.2-5.fc15     updates
abrt-plugin-rhtsupport.x86_64        2.0.2-5.fc15     updates

yum list all
Lists all installed and available packages.
Ejemplo 4.2. Listing all installed and available packages
~]# yum list all
Loaded plugins: langpacks, presto, refresh-packagekit
Installed Packages
ConsoleKit.x86_64                       0.4.4-1.fc15                  @fedora
ConsoleKit-libs.x86_64                  0.4.4-1.fc15                  @fedora
ConsoleKit-x11.x86_64                   0.4.4-1.fc15                  @fedora
GConf2.x86_64                           2.32.3-1.fc15                 @fedora
GConf2-gtk.x86_64                       2.32.3-1.fc15                 @fedora
ModemManager.x86_64                     0.4-7.git20110201.fc15        @fedora
NetworkManager.x86_64                   1:0.8.998-4.git20110427.fc15  @fedora
NetworkManager-glib.x86_64              1:0.8.998-4.git20110427.fc15  @fedora
NetworkManager-gnome.x86_64             1:0.8.998-4.git20110427.fc15  @fedora
NetworkManager-openconnect.x86_64       0.8.1-9.git20110419.fc15      @fedora
[output truncated]

yum list installed
Lists all packages installed on your system. The rightmost column in the output lists the repository from which the package was retrieved.
Ejemplo 4.3. Listing installed packages using a double-quoted glob expression
To list all installed packages that begin with krb followed by exactly one character and a hyphen, type:
~]# yum list installed "krb?-*"
Loaded plugins: langpacks, presto, refresh-packagekit
Installed Packages
krb5-libs.x86_64              1.9-7.fc15              @fedora

yum list available
Lists all available packages in all enabled repositories.
Ejemplo 4.4. Listing available packages using a single glob expression with escaped wildcard characters
To list all available packages with names that contain gstreamer and then plugin, run the following command:
~]# yum list available gstreamer\*plugin\*
Loaded plugins: langpacks, presto, refresh-packagekit
Available Packages
gstreamer-plugin-crystalhd.x86_64               3.5.1-1.fc14       fedora
gstreamer-plugins-bad-free.x86_64               0.10.22-1.fc15     updates
gstreamer-plugins-bad-free-devel.x86_64         0.10.22-1.fc15     updates
gstreamer-plugins-bad-free-devel-docs.x86_64    0.10.22-1.fc15     updates
gstreamer-plugins-bad-free-extras.x86_64        0.10.22-1.fc15     updates
gstreamer-plugins-base.x86_64                   0.10.33-1.fc15     updates
gstreamer-plugins-base-devel.x86_64             0.10.33-1.fc15     updates
gstreamer-plugins-base-devel-docs.noarch        0.10.33-1.fc15     updates
gstreamer-plugins-base-tools.x86_64             0.10.33-1.fc15     updates
gstreamer-plugins-espeak.x86_64                 0.3.3-3.fc15       fedora
gstreamer-plugins-fc.x86_64                     0.2-2.fc15         fedora
gstreamer-plugins-good.x86_64                   0.10.29-1.fc15     updates
gstreamer-plugins-good-devel-docs.noarch        0.10.29-1.fc15     updates

yum grouplist
Lista todos los grupos de paquetes
Ejemplo 4.5. Listando todos los grupos de paquetes
~]# yum grouplist
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Group Process
Installed Groups:
   Administration Tools
   Design Suite
   Dial-up Networking Support
   Fonts
   GNOME Desktop Environment
[output truncated]

yum repolist
Lists the repository ID, name, and number of packages it provides for each enabled repository.
Ejemplo 4.6. Listando repositorios habilitados
~]# yum repolist
Loaded plugins: langpacks, presto, refresh-packagekit
repo id                      repo name                                    status
fedora                       Fedora 15 - i386                             19,365
updates                      Fedora 15 - i386 - Updates                   3,848
repolist: 23,213

4.2.3. Mostrando información del paquete

To display information about one or more packages (glob expressions are valid here as well), use the following command:
yum info package_name
For example, to display information about the abrt package, type:
~]# yum info abrt
Loaded plugins: langpacks, presto, refresh-packagekit
Installed Packages
Name        : abrt
Arch        : x86_64
Version     : 2.0.1
Release     : 2.fc15
Size        : 806 k
Repo        : installed
From repo   : fedora
Summary     : Automatic bug detection and reporting tool
URL         : https://fedorahosted.org/abrt/
License     : GPLv2+
Description : abrt is a tool to help users to detect defects in applications and
            : to create a bug report with all informations needed by maintainer
            : to fix it. It uses plugin system to extend its functionality.
The yum info package_name command is similar to the rpm -q --info package_name command, but provides as additional information the ID of the Yum repository the RPM package is found in (look for the From repo: line in the output).
You can also query the Yum database for alternative and useful information about a package by using the following command:
yumdb info package_name
This command provides additional information about a package, including the checksum of the package (and algorithm used to produce it, such as SHA-256), the command given on the command line that was invoked to install the package (if any), and the reason that the package is installed on the system (where user indicates it was installed by the user, and dep means it was brought in as a dependency). For example, to display additional information about the yum package, type:
~]# yumdb info yum
Loaded plugins: langpacks, presto, refresh-packagekit
yum-3.2.29-4.fc15.noarch
     checksum_data = 249f21fb43c41381c8c9b0cd98d2ea5fa0aa165e81ed2009cfda74c05af67246
     checksum_type = sha256
     from_repo = fedora
     from_repo_revision = 1304429533
     from_repo_timestamp = 1304442346
     installed_by = 0
     reason = user
     releasever = $releasever
For more information on the yumdb command, refer to the yumdb(8) manual page.

4.2.4. Installing Packages

Yum allows you to install both a single package and multiple packages, as well as a package group of your choice.

Instalando paquetes individuales

To install a single package and all of its non-installed dependencies, enter a command in the following form:
yum install package_name
You can also install multiple packages simultaneously by appending their names as arguments:
yum install package_name package_name
If you are installing packages on a multilib system, such as an AMD64 or Intel64 machine, you can specify the architecture of the package (as long as it is available in an enabled repository) by appending .arch to the package name. For example, to install the sqlite2 package for i586, type:
~]# yum install sqlite2.i586
You can use glob expressions to quickly install multiple similarly-named packages:
~]# yum install audacious-plugins-\*
In addition to package names and glob expressions, you can also provide file names to yum install. If you know the name of the binary you want to install, but not its package name, you can give yum install the path name:
~]# yum install /usr/sbin/named
yum then searches through its package lists, finds the package which provides /usr/sbin/named, if any, and prompts you as to whether you want to install it.

Finding which package owns a file

If you know you want to install the package that contains the named binary, but you do not know in which bin or sbin directory is the file installed, use the yum provides command with a glob expression:
~]# yum provides "*bin/named"
Loaded plugins: langpacks, presto, refresh-packagekit
32:bind-9.8.0-3.P1.fc15.i686 : The Berkeley Internet Name Domain (BIND) DNS
                             : (Domain Name System) server
Repo        : fedora
Matched from:
Filename    : /usr/sbin/named
yum provides "*/file_name" is a common and useful trick to find the packages that contain file_name.

Instalando un grupo de paquetes

A package group is similar to a package: it is not useful by itself, but installing one pulls a group of dependent packages that serve a common purpose. A package group has a name and a groupid. The yum grouplist -v command lists the names of all package groups, and, next to each of them, their groupid in parentheses. The groupid is always the term in the last pair of parentheses, such as kde-desktop in the following example:
~]# yum -v grouplist kde\*
Not loading "blacklist" plugin, as it is disabled
Loading "langpacks" plugin
Loading "presto" plugin
Loading "refresh-packagekit" plugin
Not loading "whiteout" plugin, as it is disabled
Adding en_US to language list
Config time: 0.900
Yum Version: 3.2.29
Setting up Group Process
rpmdb time: 0.002
group time: 0.995
Available Groups:
   KDE Software Compilation (kde-desktop)
   KDE Software Development (kde-software-development)
Done
You can install a package group by passing its full group name (without the groupid part) to groupinstall:
yum groupinstall group_name
You can also install by groupid:
yum groupinstall groupid
You can even pass the groupid (or quoted name) to the install command if you prepend it with an @-symbol (which tells yum that you want to perform a groupinstall):
yum install @group
For example, the following are alternative but equivalent ways of installing the KDE Desktop group:
~]# yum groupinstall "KDE Desktop"
~]# yum groupinstall kde-desktop
~]# yum install @kde-desktop

4.2.5. Removing Packages

Similarly to package installation, Yum allows you to uninstall (remove in RPM and Yum terminology) both individual packages and a package group.

Eliminando paquetes individuales

To uninstall a particular package, as well as any packages that depend on it, run the following command as root:
yum remove package_name
As when you install multiple packages, you can remove several at once by adding more package names to the command. For example, to remove totem, rhythmbox, and sound-juicer, type the following at a shell prompt:
~]# yum remove totem rhythmbox sound-juicer
Similar to install, remove can take these arguments:
  • nombres de paquete
  • glob expressions
  • listas de archivos
  • package provides

Eliminando un paquete cuando otros paquetes dependen de él

Yum is not able to remove a package without also removing packages which depend on it. This type of operation can only be performed by RPM, is not advised, and can potentially leave your system in a non-functioning state or cause applications to misbehave and/or crash. For further information, refer to Sección B.2.4, “Desinstalación” in the RPM chapter.

Eliminando un grupo de paquetes

You can remove a package group using syntax congruent with the install syntax:
yum groupremove group
yum remove @group
The following are alternative but equivalent ways of removing the KDE Desktop group:
~]# yum groupremove "KDE Desktop"
~]# yum groupremove kde-desktop
~]# yum remove @kde-desktop

Intelligent package group removal

When you tell yum to remove a package group, it will remove every package in that group, even if those packages are members of other package groups or dependencies of other installed packages. However, you can instruct yum to remove only those packages which are not required by any other packages or groups by adding the groupremove_leaf_only=1 directive to the [main] section of the /etc/yum.conf configuration file. For more information on this directive, refer to Sección 4.3.1, “Setting [main] Options”.

4.2.6. Working with Transaction History

The yum history command allows users to review information about a timeline of Yum transactions, the dates and times on when they occurred, the number of packages affected, whether transactions succeeded or were aborted, and if the RPM database was changed between transactions. Additionally, this command can be used to undo or redo certain transactions.

Listando transacciones

To display a list of twenty most recent transactions, as root, either run yum history with no additional arguments, or type the following at a shell prompt:
yum history list
To display all transactions, add the all keyword:
yum history list all
To display only transactions in a given range, use the command in the following form:
yum history list start_id..end_id
You can also list only transactions regarding a particular package or packages. To do so, use the command with a package name or a glob expression:
yum history list glob_expression
For example, the list of first five transactions may look as follows:
~]# yum history list 1..5
Loaded plugins: langpacks, presto, refresh-packagekit
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
     5 | Jaromir ... <jhradilek>  | 2011-07-29 15:33 | Install        |    1
     4 | Jaromir ... <jhradilek>  | 2011-07-21 15:10 | Install        |    1
     3 | Jaromir ... <jhradilek>  | 2011-07-16 15:27 | I, U           |   73
     2 | System <unset>           | 2011-07-16 15:19 | Update         |    1
     1 | System <unset>           | 2011-07-16 14:38 | Install        | 1106
history list
All forms of the yum history list command produce tabular output with each row consisting of the following columns:
  • ID — an integer value that identifies a particular transaction.
  • Login user — the name of the user whose login session was used to initiate a transaction. This information is typically presented in the Full Name <username> form. For transactions that were not issued by a user (such as an automatic system update), System <unset> is used instead.
  • Date and time — the date and time when a transaction was issued.
  • Action(s) — a list of actions that were performed during a transaction as described in Tabla 4.1, “Possible values of the Action(s) field”.
  • Altered — the number of packages that were affected by a transaction, possibly followed by additional information as described in Tabla 4.2, “Possible values of the Altered field”.
Tabla 4.1. Possible values of the Action(s) field
Action Abbreviation Description
Downgrade D At least one package has been downgraded to an older version.
Erase E At least one package has been removed.
Install I At least one new package has been installed.
Obsoleting O At least one package has been marked as obsolete.
Reinstall R At least one package has been reinstalled.
Update U At least one package has been updated to a newer version.

Tabla 4.2. Possible values of the Altered field
Symbol Description
< Before the transaction finished, the rpmdb database was changed outside Yum.
> After the transaction finished, the rpmdb database was changed outside Yum.
* The transaction failed to finish.
# The transaction finished successfully, but yum returned a non-zero exit code.
E The transaction finished successfully, but an error or a warning was displayed.
P The transaction finished successfully, but problems already existed in the rpmdb database.
s The transaction finished successfully, but the --skip-broken command line option was used and certain packages were skipped.

Yum also allows you to display a summary of all past transactions. To do so, run the command in the following form as root:
yum history summary
To display only transactions in a given range, type:
yum history summary start_id..end_id
Similarly to the yum history list command, you can also display a summary of transactions regarding a certain package or packages by supplying a package name or a glob expression:
yum history summary glob_expression
For instance, a summary of the transaction history displayed above would look like the following:
~]# yum history summary 1..5
Loaded plugins: langpacks, presto, refresh-packagekit
Login user                 | Time                | Action(s)        | Altered 
-------------------------------------------------------------------------------
Jaromir ... <jhradilek>    | Last day            | Install          |        1
Jaromir ... <jhradilek>    | Last week           | Install          |        1
Jaromir ... <jhradilek>    | Last 2 weeks        | I, U             |       73
System <unset>             | Last 2 weeks        | I, U             |     1107
history summary
All forms of the yum history summary command produce simplified tabular output similar to the output of yum history list.
As shown above, both yum history list and yum history summary are oriented towards transactions, and although they allow you to display only transactions related to a given package or packages, they lack important details, such as package versions. To list transactions from the perspective of a package, run the following command as root:
yum history package-list glob_expression
For example, to trace the history of subscription-manager and related packages, type the following at a shell prompt:
~]# yum history package-list subscription-manager\*
Loaded plugins: langpacks, presto, refresh-packagekit
ID     | Action(s)      | Package
-------------------------------------------------------------------------------
     3 | Updated        | subscription-manager-0.95.11-1.el6.x86_64
     3 | Update         |                      0.95.17-1.el6_1.x86_64
     3 | Updated        | subscription-manager-firstboot-0.95.11-1.el6.x86_64
     3 | Update         |                                0.95.17-1.el6_1.x86_64
     3 | Updated        | subscription-manager-gnome-0.95.11-1.el6.x86_64
     3 | Update         |                            0.95.17-1.el6_1.x86_64
     1 | Install        | subscription-manager-0.95.11-1.el6.x86_64
     1 | Install        | subscription-manager-firstboot-0.95.11-1.el6.x86_64
     1 | Install        | subscription-manager-gnome-0.95.11-1.el6.x86_64
history package-list
In this example, three packages were installed during the initial system installation: subscription-manager, subscription-manager-firstboot, and subscription-manager-gnome. In the third transaction, all these packages were updated from version 0.95.11 to version 0.95.17.

Examining Transactions

To display the summary of a single transaction, as root, use the yum history summary command in the following form:
yum history summary id
To examine a particular transaction or transactions in more detail, run the following command as root:
yum history info id
The id argument is optional and when you omit it, yum automatically uses the last transaction. Note that when specifying more than one transaction, you can also use a range:
yum history info start_id..end_id
The following is sample output for two transactions, each installing one new package:
~]# yum history info 4..5
Loaded plugins: langpacks, presto, refresh-packagekit
Transaction ID : 4..5
Begin time     : Thu Jul 21 15:10:46 2011
Begin rpmdb    : 1107:0c67c32219c199f92ed8da7572b4c6df64eacd3a
End time       :            15:33:15 2011 (22 minutes)
End rpmdb      : 1109:1171025bd9b6b5f8db30d063598f590f1c1f3242
User           : Jaromir Hradilek <jhradilek>
Return-Code    : Success
Command Line   : install screen
Command Line   : install yum-plugin-fs-snapshot
Transaction performed with:
    Installed     rpm-4.8.0-16.el6.x86_64
    Installed     yum-3.2.29-17.el6.noarch
    Installed     yum-metadata-parser-1.1.2-16.el6.x86_64
Packages Altered:
    Install screen-4.0.3-16.el6.x86_64
    Install yum-plugin-fs-snapshot-1.1.30-6.el6.noarch
history info
You can also view additional information, such as what configuration options were used at the time of the transaction, or from what repository and why were certain packages installed. To determine what additional information is available for a certain transaction, type the following at a shell prompt as root:
yum history addon-info id
Similarly to yum history info, when no id is provided, yum automatically uses the latest transaction. Another way to refer to the latest transaction is to use the last keyword:
yum history addon-info last
For instance, for the first transaction in the previous example, the yum history addon-info command would provide the following output:
~]# yum history addon-info 4
Loaded plugins: langpacks, presto, refresh-packagekit
Transaction ID: 4
Available additional history information:
  config-main
  config-repos
  saved_tx

history addon-info
In this example, three types of information are available:
  • config-main — global Yum options that were in use during the transaction. Refer to Sección 4.3.1, “Setting [main] Options” for information on how to change global options.
  • config-repos — options for individual Yum repositories. Refer to Sección 4.3.2, “Setting [repository] Options” for information on how to change options for individual repositories.
  • saved_tx — the data that can be used by the yum load-transaction command in order to repeat the transaction on another machine (see below).
To display selected type of additional information, run the following command as root:
yum history addon-info id information

Reverting and Repeating Transactions

Apart from reviewing the transaction history, the yum history command provides means to revert or repeat a selected transaction. To revert a transaction, type the following at a shell prompt as root:
yum history undo id
To repeat a particular transaction, as root, run the following command:
yum history redo id
Both commands also accept the last keyword to undo or repeat the latest transaction.
Note that both yum history undo and yum history redo commands merely revert or repeat the steps that were performed during a transaction: if the transaction installed a new package, the yum history undo command will uninstall it, and vice versa. If possible, this command will also attempt to downgrade all updated packages to their previous version, but these older packages may no longer be available. If you need to be able to restore the system to the state before an update, consider using the fs-snapshot plug-in described in Sección 4.4.3, “Plug-in Descriptions”.
When managing several identical systems, Yum also allows you to perform a transaction on one of them, store the transaction details in a file, and after a period of testing, repeat the same transaction on the remaining systems as well. To store the transaction details to a file, type the following at a shell prompt as root:
yum -q history addon-info id saved_tx > file_name
Once you copy this file to the target system, you can repeat the transaction by using the following command as root:
yum load-transaction file_name
Note, however that the rpmdb version stored in the file must by identical to the version on the target system. You can verify the rpmdb version by using the yum version nogroups command.

Starting New Transaction History

Yum stores the transaction history in a single SQLite database file. To start new transaction history, run the following command as root:
yum history new
This will create a new, empty database file in the /var/lib/yum/history/ directory. The old transaction history will be kept, but will not be accessible as long as a newer database file is present in the directory.

4.3. Configurando Yum y repositorios de Yum

The configuration file for yum and related utilities is located at /etc/yum.conf. This file contains one mandatory [main] section, which allows you to set Yum options that have global effect, and may also contain one or more [repository] sections, which allow you to set repository-specific options. However, best practice is to define individual repositories in new or existing .repo files in the /etc/yum.repos.d/directory. The values you define in the [main] section of the /etc/yum.conf file may override values set in individual [repository] sections.
Esta sección le muestra cómo:
  • set global Yum options by editing the [main] section of the /etc/yum.conf configuration file;
  • set options for individual repositories by editing the [repository] sections in /etc/yum.conf and .repo files in the /etc/yum.repos.d/ directory;
  • use Yum variables in /etc/yum.conf and files in the /etc/yum.repos.d/ directory so that dynamic version and architecture values are handled correctly;
  • add, enable, and disable Yum repositories on the command line; and,
  • set up your own custom Yum repository.

4.3.1. Setting [main] Options

The /etc/yum.conf configuration file contains exactly one [main] section, and while some of the key-value pairs in this section affect how yum operates, others affect how Yum treats repositories. You can add many additional options under the [main] section heading in /etc/yum.conf.
A sample /etc/yum.conf configuration file can look like this:
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3

[comments abridged]

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
The following are the most commonly-used options in the [main] section:
assumeyes=value
…where value is one of:
0yum should prompt for confirmation of critical actions it performs. This is the default.
1 — Do not prompt for confirmation of critical yum actions. If assumeyes=1 is set, yum behaves in the same way that the command line option -y does.
cachedir=directory
…where directory is an absolute path to the directory where Yum should store its cache and database files. By default, Yum's cache directory is /var/cache/yum/$basearch/$releasever.
Refer to Sección 4.3.3, “Using Yum Variables” for descriptions of the $basearch and $releasever Yum variables.
debuglevel=value
…where value is an integer between 1 and 10. Setting a higher debuglevel value causes yum to display more detailed debugging output. debuglevel=0 disables debugging output, while debuglevel=2 is the default.
exactarch=value
…where value is one of:
0 — Do not take into account the exact architecture when updating packages.
1 — Consider the exact architecture when updating packages. With this setting, yum will not install an i686 package to update an i386 package already installed on the system. This is the default.
exclude=package_name [more_package_names]
This option allows you to exclude packages by keyword during installation/updates. Listing multiple packages for exclusion can be accomplished by quoting a space-delimited list of packages. Shell globs using wildcards (for example, * and ?) are allowed.
gpgcheck=value
…where value is one of:
0 — Disable GPG signature-checking on packages in all repositories, including local package installation.
1 — Enable GPG signature-checking on all packages in all repositories, including local package installation. gpgcheck=1 is the default, and thus all packages' signatures are checked.
If this option is set in the [main] section of the /etc/yum.conf file, it sets the GPG-checking rule for all repositories. However, you can also set gpgcheck=value for individual repositories instead; that is, you can enable GPG-checking on one repository while disabling it on another. Setting gpgcheck=value for an individual repository in its corresponding .repo file overrides the default if it is present in /etc/yum.conf.
For more information on GPG signature-checking, refer to Sección B.3, “Revisando la firma de los paquetes”.
groupremove_leaf_only=value
…where value is one of:
0yum should not check the dependencies of each package when removing a package group. With this setting, yum removes all packages in a package group, regardless of whether those packages are required by other packages or groups. groupremove_leaf_only=0 is the default.
1yum should check the dependencies of each package when removing a package group, and remove only those packages which are not not required by any other package or group.
For more information on removing packages, refer to Intelligent package group removal.
installonlypkgs=space separated list of packages
Here you can provide a space-separated list of packages which yum can install, but will never update. Refer to the yum.conf(5) manual page for the list of packages which are install-only by default.
If you add the installonlypkgs directive to /etc/yum.conf, you should ensure that you list all of the packages that should be install-only, including any of those listed under the installonlypkgs section of yum.conf(5). In particular, kernel packages should always be listed in installonlypkgs (as they are by default), and installonly_limit should always be set to a value greater than 2 so that a backup kernel is always available in case the default one fails to boot.
installonly_limit=value
…where value is an integer representing the maximum number of versions that can be installed simultaneously for any single package listed in the installonlypkgs directive.
The defaults for the installonlypkgs directive include several different kernel packages, so be aware that changing the value of installonly_limit will also affect the maximum number of installed versions of any single kernel package. The default value listed in /etc/yum.conf is installonly_limit=3, and it is not recommended to decrease this value, particularly below 2.
keepcache=value
…where value is one of:
0 — Do not retain the cache of headers and packages after a successful installation. This is the default.
1 — Retain the cache after a successful installation.
logfile=file_name
…where file_name is an absolute path to the file in which yum should write its logging output. By default, yum logs to /var/log/yum.log.
multilib_policy=value
…where value is one of:
best — install the best-choice architecture for this system. For example, setting multilib_policy=best on an AMD64 system causes yum to install 64-bit versions of all packages.
all — always install every possible architecture for every package. For example, with multilib_policy set to all on an AMD64 system, yum would install both the i586 and AMD64 versions of a package, if both were available.
obsoletes=value
…where value is one of:
0 — Disable yum's obsoletes processing logic when performing updates.
1 — Enable yum's obsoletes processing logic when performing updates. When one package declares in its spec file that it obsoletes another package, the latter package will be replaced by the former package when the former package is installed. Obsoletes are declared, for example, when a package is renamed. obsoletes=1 the default.
plugins=value
…where value is one of:
0 — Disable all Yum plug-ins globally.

Disabling all plug-ins is not advised

Disabling all plug-ins is not advised because certain plug-ins provide important Yum services. Disabling plug-ins globally is provided as a convenience option, and is generally only recommended when diagnosing a potential problem with Yum.
1 — Enable all Yum plug-ins globally. With plugins=1, you can still disable a specific Yum plug-in by setting enabled=0 in that plug-in's configuration file.
For more information about various Yum plug-ins, refer to Sección 4.4, “Yum Plug-ins”. For further information on controlling plug-ins, see Sección 4.4.1, “Enabling, Configuring, and Disabling Yum Plug-ins”.
reposdir=directory
…where directory is an absolute path to the directory where .repo files are located. All .repo files contain repository information (similar to the [repository] sections of /etc/yum.conf). yum collects all repository information from .repo files and the [repository] section of the /etc/yum.conf file to create a master list of repositories to use for transactions. If reposdir is not set, yum uses the default directory /etc/yum.repos.d/.
retries=value
…where value is an integer 0 or greater. This value sets the number of times yum should attempt to retrieve a file before returning an error. Setting this to 0 makes yum retry forever. The default value is 10.
For a complete list of available [main] options, refer to the [main] OPTIONS section of the yum.conf(5) manual page.

4.3.2. Setting [repository] Options

The [repository] sections, where repository is a unique repository ID such as my_personal_repo (spaces are not permitted), allow you to define individual Yum repositories.
The following is a bare-minimum example of the form a [repository] section takes:
[repository]
name=repository_name
baseurl=repository_url
Every [repository] section must contain the following directives:
name=repository_name
…where repository_name is a human-readable string describing the repository.
baseurl=repository_url
…where repository_url is a URL to the directory where the repodata directory of a repository is located:
  • If the repository is available over HTTP, use: http://path/to/repo
  • Si el repositorio está disponible sobre FTP use: ftp://ruta/al/repo
  • If the repository is local to the machine, use: file:///path/to/local/repo
  • If a specific online repository requires basic HTTP authentication, you can specify your username and password by prepending it to the URL as username:password@link. For example, if a repository on http://www.example.com/repo/ requires a username of user and a password of password, then the baseurl link could be specified as http://user:password@www.example.com/repo/.
Usually this URL is an HTTP link, such as:
baseurl=http://path/to/repo/releases/$releasever/server/$basearch/os/
Note that Yum always expands the $releasever, $arch, and $basearch variables in URLs. For more information about Yum variables, refer to Sección 4.3.3, “Using Yum Variables”.
Another useful [repository] directive is the following:
enabled=value
…where value is one of:
0 — Do not include this repository as a package source when performing updates and installs. This is an easy way of quickly turning repositories on and off, which is useful when you desire a single package from a repository that you do not want to enable for updates or installs.
1 — Include this repository as a package source.
Turning repositories on and off can also be performed by passing either the --enablerepo=repo_name or --disablerepo=repo_name option to yum, or through the Add/Remove Software window of the PackageKit utility.
Many more [repository] options exist. For a complete list, refer to the [repository] OPTIONS section of the yum.conf(5) manual page.

4.3.3. Using Yum Variables

You can use and reference the following built-in variables in yum commands and in all Yum configuration files (that is, /etc/yum.conf and all .repo files in the /etc/yum.repos.d/ directory):
$releasever
You can use this variable to reference the release version of Fedora. Yum obtains the value of $releasever from the distroverpkg=value line in the /etc/yum.conf configuration file. If there is no such line in /etc/yum.conf, then yum infers the correct value by deriving the version number from the redhat-release package.
$arch
You can use this variable to refer to the system's CPU architecture as returned when calling Python's os.uname() function. Valid values for $arch include: i586, i686 and x86_64.
$basearch
You can use $basearch to reference the base architecture of the system. For example, i686 and i586 machines both have a base architecture of i386, and AMD64 and Intel64 machines have a base architecture of x86_64.
$YUM0-9
These ten variables are each replaced with the value of any shell environment variables with the same name. If one of these variables is referenced (in /etc/yum.conf for example) and a shell environment variable with the same name does not exist, then the configuration file variable is not replaced.
To define a custom variable or to override the value of an existing one, create a file with the same name as the variable (without the $ sign) in the /etc/yum/vars/ directory, and add the desired value on its first line.
For example, repository descriptions often include the operating system name. To define a new variable called $osname, create a new file with Fedora on the first line and save it as /etc/yum/vars/osname:
~]# echo "Fedora" > /etc/yum/vars/osname
Instead of Fedora 17, you can now use the following in the .repo files:
name=$osname $releasever

4.3.4. Viewing the Current Configuration

To display the current values of global Yum options (that is, the options specified in the [main] section of the /etc/yum.conf file), run the yum-config-manager with no command line options:
yum-config-manager
To list the content of a different configuration section or sections, use the command in the following form:
yum-config-manager section
You can also use a glob expression to display the configuration of all matching sections:
yum-config-manager glob_expression
For example, to list all configuration options and their corresponding values, type the following at a shell prompt:
~]$ yum-config-manager main \*
Loaded plugins: langpacks, presto, refresh-packagekit
================================== main ===================================
[main]
alwaysprompt = True
assumeyes = False
bandwith = 0
bugtracker_url = https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%206&component=yum
cache = 0
[output truncated]

4.3.5. Adding, Enabling, and Disabling a Yum Repository

Sección 4.3.2, “Setting [repository] Options” described various options you can use to define a Yum repository. This section explains how to add, enable, and disable a repository by using the yum-config-manager command.

Adding a Yum Repository

To define a new repository, you can either add a [repository] section to the /etc/yum.conf file, or to a .repo file in the /etc/yum.repos.d/ directory. All files with the .repo file extension in this directory are read by yum, and best practice is to define your repositories here instead of in /etc/yum.conf.

Be careful when using untrusted software sources

Obtaining and installing software packages from unverified or untrusted software sources constitutes a potential security risk, and could lead to security, stability, compatibility maintainability issues.
Yum repositories commonly provide their own .repo file. To add such a repository to your system and enable it, run the following command as root:
yum-config-manager --add-repo repository_url
…where repository_url is a link to the .repo file. For example, to add a repository located at http://www.example.com/example.repo, type the following at a shell prompt:
~]# yum-config-manager --add-repo http://www.example.com/example.repo
Loaded plugins: langpacks, presto, refresh-packagekit
adding repo from: http://www.example.com/example.repo
grabbing file http://www.example.com/example.repo to /etc/yum.repos.d/example.repo
example.repo                                             |  413 B     00:00
repo saved to /etc/yum.repos.d/example.repo

Enabling a Yum Repository

To enable a particular repository or repositories, type the following at a shell prompt as root:
yum-config-manager --enable repository
…where repository is the unique repository ID (use yum repolist all to list available repository IDs). Alternatively, you can use a glob expression to enable all matching repositories:
yum-config-manager --enable glob_expression
For example, to disable repositories defined in the [example], [example-debuginfo], and [example-source]sections, type:
~]# yum-config-manager --enable example\*
Loaded plugins: langpacks, presto, refresh-packagekit
============================== repo: example ==============================
[example]
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/6Server
baseurl = http://www.example.com/repo/6Server/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/6Server/example
[output truncated]
When successful, the yum-config-manager --enable command displays the current repository configuration.

Disabling a Yum Repository

To disable a Yum repository, run the following command as root:
yum-config-manager --disable repository
…where repository is the unique repository ID (use yum repolist all to list available repository IDs). Similarly to yum-config-manager --enable, you can use a glob expression to disable all matching repositories at the same time:
yum-config-manager --disable glob_expression
When successful, the yum-config-manager --disable command displays the current configuration.

4.3.6. Creating a Yum Repository

To set up a Yum repository, follow these steps:
  1. Instalar el paquete createrepo:
    ~]# yum install createrepo
  2. Copy all of the packages into one directory, such as /mnt/local_repo/.
  3. Run the createrepo --database command on that directory:
    ~]# createrepo --database /mnt/local_repo
This creates the necessary metadata for your Yum repository, as well as the sqlite database for speeding up yum operations.

4.4. Yum Plug-ins

Yum provides plug-ins that extend and enhance its operations. Certain plug-ins are installed by default. Yum always informs you which plug-ins, if any, are loaded and active whenever you call any yum command. For example:
~]# yum info yum
Loaded plugins: langpacks, presto, refresh-packagekit
[output truncated]
Note that the plug-in names which follow Loaded plugins are the names you can provide to the --disableplugins=plugin_name option.

4.4.1. Enabling, Configuring, and Disabling Yum Plug-ins

To enable Yum plug-ins, ensure that a line beginning with plugins= is present in the [main] section of /etc/yum.conf, and that its value is set to 1:
plugins=1
You can disable all plug-ins by changing this line to plugins=0.

Disabling all plug-ins is not advised

Disabling all plug-ins is not advised because certain plug-ins provide important Yum services. Disabling plug-ins globally is provided as a convenience option, and is generally only recommended when diagnosing a potential problem with Yum.
Every installed plug-in has its own configuration file in the /etc/yum/pluginconf.d/ directory. You can set plug-in specific options in these files. For example, here is the refresh-packagekit plug-in's refresh-packagekit.conf configuration file:
[main]
enabled=1
Plug-in configuration files always contain a [main] section (similar to Yum's /etc/yum.conf file) in which there is (or you can place if it is missing) an enabled= option that controls whether the plug-in is enabled when you run yum commands.
If you disable all plug-ins by setting enabled=0 in /etc/yum.conf, then all plug-ins are disabled regardless of whether they are enabled in their individual configuration files.
If you merely want to disable all Yum plug-ins for a single yum command, use the --noplugins option.
If you want to disable one or more Yum plug-ins for a single yum command, add the --disableplugin=plugin_name option to the command. For example, to disable the presto plug-in while updating a system, type:
~]# yum update --disableplugin=presto
The plug-in names you provide to the --disableplugin= option are the same names listed after the Loaded plugins line in the output of any yum command. You can disable multiple plug-ins by separating their names with commas. In addition, you can match multiple plug-in names or shorten long ones by using glob expressions:
~]# yum update --disableplugin=presto,refresh-pack*

4.4.2. Installing Additional Yum Plug-ins

Yum plug-ins usually adhere to the yum-plugin-plugin_name package-naming convention, but not always: the package which provides the presto plug-in is named yum-presto, for example. You can install a Yum plug-in in the same way you install other packages. For instance, to install the security plug-in, type the following at a shell prompt:
~]# yum install yum-plugin-security

4.4.3. Plug-in Descriptions

The following list provides descriptions of a few useful Yum plug-ins:
fs-snapshot (yum-plugin-fs-snapshot)
The fs-snapshot plug-in extends Yum to create a snapshot of a file system before proceeding with a transaction such as a system update or package removal. When a user decides that the changes made by the transaction are unwanted, this mechanism allows the user to roll back to the changes that are stored in a snapshot.
In order for the plug-in to work, the root file system (that is, /) must be on an LVM (Logical Volume Manager) or Btrfs volume. To use the fs-snapshot plug-in on an LVM volume, take the following steps:
  1. Make sure that the volume group with the root file system has enough free extents. The required size is a function of the amount of changes to the original logical volume that is expected during the life of the snapshot. The reasonable default is 50–80 % of the original logical volume size.
    To display detailed information about a particular volume group, run the vgdisplay command in the following form as root:
    vgdisplay volume_group
    The number of free extents is listed on the Free PE / Size line.
  2. If the volume group with the root file system does not have enough free extents, add a new physical volume:
    1. As root, run the pvcreate command in the following form to initialize a physical volume for use with the Logical Volume Manager:
      pvcreate device
    2. Use the vgextend command in the following form as root to add the physical volume to the volume group:
      vgextend volume_group physical_volume
  3. Edit the configuration file located in /etc/yum/pluginconf.d/fs-snapshot.conf, and make the following changes to the [lvm] section:
    1. Change the value of the enabled option to 1:
      enabled = 1
    2. Remove the hash sign (that is, #) from the beginning of the lvcreate_size_args line, and adjust the number of logical extents to be allocated for a snapshot. For example, to allocate 80 % of the size of the original logical volume, use:
      lvcreate_size_args = -l 80%ORIGIN
    Refer to Tabla 4.3, “Supported fs-snapshot.conf directives” for a complete list of available configuration options.
  4. Run the desired yum command, and make sure fs-snapshot is included in the list of loaded plug-ins (the Loaded plugins line) before you confirm the changes and proceed with the transaction. The fs-snapshot plug-in displays a line in the following form for each affected logical volume:
    fs-snapshot: snapshotting file_system (/dev/volume_group/logical_volume): logical_volume_yum_timestamp
  5. Verify that the system is working as expected:
    • If you decide to keep the changes, remove the snapshot by running the lvremove command as root:
      lvremove /dev/volume_group/logical_volume_yum_timestamp
    • If you decide to revert the changes and restore the file system to a state that is saved in a snapshot, take the following steps:
      1. As root, run the command in the following form to merge a snapshot into its original logical volume:
        lvconvert --merge /dev/volume_group/logical_volume_yum_timestamp
        The lvconvert command will inform you that a restart is required in order for the changes to take effect.
      2. Restart the system as instructed. You can do so by typing the following at a shell prompt as root:
        reboot
To use the fs-snapshot plug-in on a Btrfs file system, take the following steps:
  1. Run the desired yum command, and make sure fs-snapshot is included in the list of loaded plug-ins (the Loaded plugins line) before you confirm the changes and proceed with the transaction. The fs-snapshot plug-in displays a line in the following form for each affected file system:
    fs-snapshot: snapshotting file_system: file_system/yum_timestamp
  2. Verify that the system is working as expected:
    • If you decide to keep the changes, you can optionally remove unwanted snapshots. To remove a Btrfs snapshot, use the command in the following form as root:
      btrfs subvolume delete file_system/yum_timestamp
    • If you decide to revert the changes and restore a file system to a state that is saved in a snapshot, take the following steps:
      1. Determine the identifier of a particular snapshot by using the following command as root:
        btrfs subvolume list file_system
      2. As root, configure the system to mount this snapshot by default:
        btrfs subvolume set-default id file_system
      3. Restart the system. You can do so by typing the following at a shell prompt as root:
        reboot
For more information on logical volume management, Btrfs, and file system snapshots, see the Fedora 17 Storage Administration Guide. For additional information about the plug-in and its configuration, refer to the yum-fs-snapshot(1) and yum-fs-snapshot.conf(5) manual pages.
Tabla 4.3. Supported fs-snapshot.conf directives
Section Directive Description
[main] enabled=value Allows you to enable or disable the plug-in. The value must be either 1 (enabled), or 0 (disabled). When installed, the plug-in is enabled by default.
exclude=list Allows you to exclude certain file systems. The value must be a space-separated list of mount points you do not want to snapshot (for example, /srv /mnt/backup). This option is not included in the configuration file by default.
[lvm] enabled=value Allows you to enable or disable the use of the plug-in on LVM volumes. The value must be either 1 (enabled), or 0 (disabled). This option is disabled by default.
lvcreate_size_args=value Allows you to specify the size of a logical volume snapshot. The value must be the -l or -L command line option for the lvcreate utility followed by a valid argument (for example, -l 80%ORIGIN).

presto (yum-presto)
The presto plug-in adds support to Yum for downloading delta RPM packages, during updates, from repositories which have presto metadata enabled. Delta RPMs contain only the differences between the version of the package installed on the client requesting the RPM package and the updated version in the repository.
Downloading a delta RPM is much quicker than downloading the entire updated package, and can speed up updates considerably. Once the delta RPMs are downloaded, they must be rebuilt to apply the difference to the currently-installed package and thus create the full, updated package. This process takes CPU time on the installing machine. Using delta RPMs is therefore a tradeoff between time-to-download, which depends on the network connection, and time-to-rebuild, which is CPU-bound. Using the presto plug-in is recommended for fast machines and systems with slower network connections, while slower machines on very fast connections may benefit more from downloading normal RPM packages, that is, by disabling presto.
refresh-packagekit (PackageKit-yum-plugin)
The refresh-packagekit plug-in updates metadata for PackageKit whenever yum is run. The refresh-packagekit plug-in is installed by default.
rhnplugin (yum-rhn-plugin)
The rhnplugin provides support for connecting to RHN Classic. This allows systems registered with RHN Classic to update and install packages from this system.
Refer to the rhnplugin(8) manual page for more information about the plug-in.
security (yum-plugin-security)
Discovering information about and applying security updates easily and often is important to all system administrators. For this reason Yum provides the security plug-in, which extends yum with a set of highly-useful security-related commands, subcommands and options.
You can check for security-related updates as follows:
~]# yum check-update --security
Loaded plugins: langpacks, presto, refresh-packagekit, security
Limiting package lists to security relevant ones
updates-testing/updateinfo                               | 329 kB     00:00
9 package(s) needed for security, out of 270 available

ConsoleKit.x86_64                    0.4.5-1.fc15                  updates
ConsoleKit-libs.x86_64               0.4.5-1.fc15                  updates
ConsoleKit-x11.x86_64                0.4.5-1.fc15                  updates
NetworkManager.x86_64                1:0.8.999-2.git20110509.fc15  updates
NetworkManager-glib.x86_64           1:0.8.999-2.git20110509.fc15  updates
[output truncated]
You can then use either yum update --security or yum update-minimal --security to update those packages which are affected by security advisories. Both of these commands update all packages on the system for which a security advisory has been issued. yum update-minimal --security updates them to the latest packages which were released as part of a security advisory, while yum update --security will update all packages affected by a security advisory to the latest version of that package available.
En otras palabras, sí:
  • the kernel-2.6.38.4-20 package is installed on your system;
  • the kernel-2.6.38.6-22 package was released as a security update;
  • then kernel-2.6.38.6-26 was released as a bug fix update,
...then yum update-minimal --security will update you to kernel-2.6.38.6-22, and yum update --security will update you to kernel-2.6.38.6-26. Conservative system administrators may want to use update-minimal to reduce the risk incurred by updating packages as much as possible.
Refer to the yum-security(8) manual page for usage details and further explanation of the enhancements the security plug-in adds to yum.

4.5. Recursos adicionales

http://yum.baseurl.org/wiki/Guides
The Yum Guides section of the Yum wiki contains more documentation.

Capítulo 5. PackageKit

Fedora provides PackageKit for viewing, managing, updating, installing and uninstalling packages compatible with your system. PackageKit consists of several graphical interfaces that can be opened from the GNOME panel menu, or from the Notification Area when PackageKit alerts you that updates are available. For more information on PackageKit's architecture and available front ends, refer to Sección 5.3, “PackageKit Architecture”.

5.1. Updating Packages with Software Update

You can open Software Updates by clicking ApplicationsSystem ToolsSoftware Update from the Activities menu, or running the gpk-update-viewer command at the shell prompt. In the Software Updates window, all available updates are listed along with the names of the packages being updated (minus the .rpm suffix, but including the CPU architecture), a short summary of the package, and, usually, short descriptions of the changes the update provides. Any updates you do not wish to install can be de-selected here by unchecking the checkbox corresponding to the update.
Installing updates with Software Update
installing 56 updates with PackageKit's software update window
Figura 5.1. Installing updates with Software Update

The updates presented in the Software Updates window only represent the currently-installed packages on your system for which updates are available; dependencies of those packages, whether they are existing packages on your system or new ones, are not shown until you click Install Updates.
PackageKit utilizes the fine-grained user authentication capabilities provided by the PolicyKit toolkit whenever you request it to make changes to the system. Whenever you instruct PackageKit to update, install or remove packages, you will be prompted to enter the superuser password before changes are made to the system.
If you instruct PackageKit to update the kernel package, then it will prompt you after installation, asking you whether you want to reboot the system and thereby boot into the newly-installed kernel.

5.1.1. Setting the Update-Checking Interval

Selecting ApplicationsOtherSoftware Updates from the Activities menu opens the Software Update Preferences window. The Update Settings tab allows you to define the interval at which PackageKit checks for package updates, as well as whether or not to automatically install all updates or only security updates. Leaving the Check for updates when using mobile broadband box unchecked is handy for avoiding extraneous bandwidth usage when using a wireless connection on which you are charged for the amount of data you download.
Setting PackageKit's update-checking interval
Setting the update-checking interval for PackageKit
Figura 5.2. Setting PackageKit's update-checking interval

5.1.2. Setting the Software Sources

To select which package repositories to use to install software updates, select ApplicationsOtherSoftware Updates from the Activities menu, and click the Software Sources tab of the Software Update Preferences window.
Setting PackageKit's software sources
Setting the software sources for PackageKit
Figura 5.3. Setting PackageKit's software sources

PackageKit refers to Yum repositories as software sources. It obtains all packages from enabled software sources.The Software Sources tab shows the repository name, as written on the name=My Repository Name field of all [repository] sections in the /etc/yum.conf configuration file, and in all repository.repo files in the /etc/yum.repos.d/ directory.
Entries which are checked in the Enabled column indicate that the corresponding repository will be used to locate packages to satisfy all update and installation requests (including dependency resolution). The Enabled column corresponds to the enabled=<1 or 0> field in [repository] sections. Checking an unchecked box enables the Yum repository, and unchecking it disables it. Performing either function causes PolicyKit to prompt for superuser authentication to enable or disable the repository. PackageKit actually inserts the enabled=<1 or 0> line into the correct [repository] section if it does not exist, or changes the value if it does. This means that enabling or disabling a repository through the Software Sources window causes that change to persist after closing the window or rebooting the system. The ability to quickly enable and disable repositories based on our needs is a highly-convenient feature of PackageKit.
Note that it is not possible to add or remove Yum repositories through PackageKit.

Showing source RPM, test, and debuginfo repositories

Checking the box at the bottom of the Software Sources tab causes PackageKit to display source RPM, testing and debuginfo repositories as well. This box is unchecked by default.

5.2. Using Add/Remove Software

PackageKit's Software Update GUI window is a separate application from its Add/Remove Software application, although the two have intuitively similar interfaces. To find and install a new package, select ApplicationsSystem ToolsAdd/Remove Software from the Activities menu, or run the gpk-application command at the shell prompt.
PackageKit's Add/Remove Software window
Viewing PackageKit's Add/Remove Software window
Figura 5.4. PackageKit's Add/Remove Software window

5.2.1. Refreshing Software Sources (Yum Repositories)

To enable or disable a Yum repository, open a dialog box by sclicking SystemSoftware Sources, and select the Software Sources tab. Refer to Sección 5.1.2, “Setting the Software Sources” for more information on available configuration options.
After enabling and/or disabling the correct Yum repositories, make sure that you have the latest list of available packages. Click on SystemRefresh Package Lists and PackageKit will obtain the latest lists of packages from all enabled software sources, that is, Yum repositories.

5.2.2. Finding Packages with Filters

You can view the list of all configured and unfiltered (see below) Yum repositories by opening Add/Remove Software and clicking SystemSoftware Sources. Once the software sources have been updated, it is often beneficial to apply some filters so that PackageKit retrieves the results of our Find queries faster. This is especially helpful when performing many package searches. Four of the filters in the Filters drop-down menu are used to split results by matching or not matching a single criterion. By default when PackageKit starts, these filters are all unapplied (No Filter), but once you do filter by one of them, that filter remains set until you either change it or close PackageKit.
Because you are usually searching for available packages that are not installed on the system, click FiltersInstalled and select the Only Available radio button.
Filtering out already-installed packages
filtering out packages which are already installed
Figura 5.5. Filtering out already-installed packages

Also, unless we require development files such as C header files, we can filter for Only End User Files and, in doing so, filter out all of the package_name-devel packages we are not interested in.
Filtering out development packages from the list of Find results
filtering out development packages from our results
Figura 5.6. Filtering out development packages from the list of Find results

The two remaining filters with submenus are:
Graphical
Narrows the search to either applications which provide a GUI interface (Only Graphical) or those that do not. This filter is useful when browsing for GUI applications that perform a specific function.
Free
Search for packages which are considered to be free software Refer to the Fedora Licensing List for details on approved licenses.
The remaining checkbox filters are always either checked or unchecked. They are:
Hide Subpackages
Checking the Hide Subpackages checkbox filters out generally-uninteresting packages that are typically only dependencies of other packages that we want. For example, checking Hide Subpackages and searching for package would cause the following related packages to be filtered out of the Find results (if it exists):
  • package-devel
  • package-libs
  • package-libs-devel
  • package-debuginfo
Only Newest Packages
Checking Only Newest Packages filters out all older versions of the same package from the list of results, which is generally what we want.

Using the Only Newest Packages filter

Checking Only Newest Packages filters out all but the most recent version of any package from the results list. This filter is often combined with the Only Available filter to search for the latest available versions of new (not installed) packages.
Only native packages
Checking the Only Native Packages box on a multilib system causes PackageKit to omit listing results for packages compiled for the architecture that runs in compatibility mode. For example, enabling this filter on a 64-bit system with an AMD64 CPU would cause all packages built for the 32-bit x86 CPU architecture not to be shown in the list of results, even though those packages are able to run on an AMD64 machine. Packages which are architecture-agnostic (i.e. noarch packages such as crontabs-1.10-32.1.el6.noarch.rpm) are never filtered out by checking Only Native Packages. This filter has no affect on non-multilib systems, such as x86 machines.

5.2.3. Installing and Removing Packages (and Dependencies)

With the two filters selected, Only Available and Only End User Files, search for the htop interactive process viewer and highlight the package. You now have access to some very useful information about it, including: a clickable link to the project homepage; the Yum package group it is found in, if any; the license of the package; a pointer to the GNOME menu location from where the application can be opened, if applicable; and the size of the package, which is relevant when we download and install it.
Viewing and installing a package with PackageKit's Add/Remove Software window
Viewing and installing a package with PackageKit's Add/Remove Software window
Figura 5.7. Viewing and installing a package with PackageKit's Add/Remove Software window

When the checkbox next to a package or group is checked, then that item is already installed on the system. Checking an unchecked box causes it to be marked for installation, which only occurs when the Apply button is clicked. In this way, you can search for and select multiple packages or package groups before performing the actual installation transactions. Additionally, you can remove installed packages by unchecking the checked box, and the removal will occur along with any pending installations when Apply is pressed. Dependency resolution , which may add additional packages to be installed or removed, is performed after pressing Apply. PackageKit will then display a window listing those additional packages to install or remove, and ask for confirmation to proceed.
Check htop and click the Apply button. You will then be prompted for the superuser password; enter it, and PackageKit will install htop. One nice feature of PackageKit is that, following installation, it sometimes presents you with a list of your newly-installed applications and offer you the choice of running them immediately. Alternatively, you will remember that finding a package and selecting it in the Add/Remove Software window shows you the Location of where in the GNOME menus its application shortcut is located, which is helpful when you want to run it.
Once it is installed, you can run htop, a colorful and enhanced version of the top process viewer, by opening a shell prompt and entering:
htop
htop is nifty, but we decide that top is good enough for us and we want to uninstall it. Remembering that we need to change the Only Available filter we recently used to install it to Only Installed in FiltersInstalled, we search for htop again and uncheck it. The program did not install any dependencies of its own; if it had, those would be automatically removed as well, as long as they were not also dependencies of any other packages still installed on our system.

Removing a package when other packages depend on it

Although PackageKit automatically resolves dependencies during package installation and removal, it is unable to remove a package without also removing packages which depend on it. This type of operation can only be performed by RPM, is not advised, and can potentially leave your system in a non-functioning state or cause applications to misbehave and/or crash.
Removing a package with PackageKit's Add/Remove Software window
Removing the htop package with PackageKit's Add/Remove Software window
Figura 5.8. Removing a package with PackageKit's Add/Remove Software window

5.2.4. Installing and Removing Package Groups

PackageKit also has the ability to install Yum package groups, which it calls Package collections. Clicking on Package collections in the top-left list of categories in the Software Updates window allows us to scroll through and find the package group we want to install. In this case, we want to install Czech language support (the Czech Support group). Checking the box and clicking Apply informs us how many additional packages must be installed in order to fulfill the dependencies of the package group.
Installing the Czech Support package group
Using PackageKit to install Czech language support with PackageKit's Add/Remove Software window
Figura 5.9. Installing the Czech Support package group

Similarly, installed package groups can be uninstalled by selecting Package collections, unchecking the appropriate checkbox, and applying.

5.2.5. Viewing the Transaction Log

PackageKit maintains a log of the transactions that it performs. To view the log, from the Add/Remove Software window, click SystemSoftware Log, or run the gpk-log command at the shell prompt.
The Software Log Viewer shows the Action, such as Updated Packages or Installed Packages, the Date on which that action was performed, the Username of the user who performed the action, and the front end Application the user used (such as Add/Remove Software, or Update System). The Details column provides the types of the transactions, such as Updated, Installed, or Removed, as well as the list of packages the transactions were performed on.
Viewing the log of package management transactions with the Software Log Viewer
Viewing the log of package management transactions with PackageKit's Software Log Viewer window
Figura 5.10. Viewing the log of package management transactions with the Software Log Viewer

Typing the name of a package in the top text entry field filters the list of transactions to those which affected that package.

5.3. PackageKit Architecture

Fedora provides the PackageKit suite of applications for viewing, updating, installing and uninstalling packages and package groups compatible with your system. Architecturally, PackageKit consists of several graphical front ends that communicate with the packagekitd daemon back end, which communicates with a package manager-specific back end that utilizes Yum to perform the actual transactions, such as installing and removing packages, etc.
Tabla 5.1, “PackageKit GUI windows, menu locations, and shell prompt commands” shows the name of the GUI window, how to start the window from the GNOME desktop or from the Add/Remove Software window, and the name of the command line application that opens that window.
Tabla 5.1. PackageKit GUI windows, menu locations, and shell prompt commands
Window Title Function How to Open Shell Command
Add/Remove Software Install, remove or view package info
From the GNOME panel: SystemAdministrationAdd/Remove Software
gpk-application
Software Update Perform package updates
From the GNOME panel: SystemAdministrationSoftware Update
gpk-update-viewer
Software Sources Enable and disable Yum repositories
From Add/Remove Software: SystemSoftware Sources
gpk-repo
Software Log Viewer View the transaction log
From Add/Remove Software: SystemSoftware Log
gpk-log
Software Update Preferences Set PackageKit preferences gpk-prefs
(Notification Area Alert) Alerts you when updates are available
From the GNOME panel: SystemPreferencesStartup Applications, Startup Programs tab
gpk-update-icon

The packagekitd daemon runs outside the user session and communicates with the various graphical front ends. The packagekitd daemon[1] communicates via the DBus system message bus with another back end, which utilizes Yum's Python API to perform queries and make changes to the system. On Linux systems other than Red Hat Enterprise Linux and Fedora, packagekitd can communicate with other back ends that are able to utilize the native package manager for that system. This modular architecture provides the abstraction necessary for the graphical interfaces to work with many different package managers to perform essentially the same types of package management tasks. Learning how to use the PackageKit front ends means that you can use the same familiar graphical interface across many different Linux distributions, even when they utilize a native package manager other than Yum.
In addition, PackageKit's separation of concerns provides reliability in that a crash of one of the GUI windows—or even the user's X Window session—will not affect any package management tasks being supervised by the packagekitd daemon, which runs outside of the user session.
All of the front end graphical applications discussed in this chapter are provided by the gnome-packagekit package instead of by PackageKit and its dependencies. Users working in a KDE environment may prefer to install the kpackagekit package, which provides a KDE interface for PackageKit.
Finally, PackageKit also comes with a console-based front end called pkcon.

5.4. Recursos adicionales

PackageKit home page — http://www.packagekit.org/index.html
Information about and mailing lists for PackageKit.
PackageKit FAQ — http://www.packagekit.org/pk-faq.html
An informative list of Frequently Asked Questions for the PackageKit software suite.
PackageKit Feature Matrix — http://www.packagekit.org/pk-matrix.html
Cross-reference PackageKit-provided features with the long list of package manager back ends.


[1] System daemons are typically long-running processes that provide services to the user or to other programs, and which are started, often at boot time. Daemons respond to the systemctl command and can be turned on or off permanently by using the systemctl enable or systemctl disablecommands. They can typically be recognized by a d appended to their name, such as the packagekitd daemon. Refer to Capítulo 8, Services and Daemons for information about system services.

Parte III. Interconexión

Capítulo 6. NetworkManager

NetworkManager is a dynamic network control and configuration system that attempts to keep network devices and connections up and active when they are available. NetworkManager consists of a core daemon, a GNOME Notification Area applet that provides network status information, and graphical configuration tools that can create, edit and remove connections and interfaces. NetworkManager can be used to configure the following types of connections: Ethernet, wireless, mobile broadband (such as cellular 3G), and DSL and PPPoE (Point-to-Point over Ethernet). In addition, NetworkManager allows for the configuration of network aliases, static routes, DNS information and VPN connections, as well as many connection-specific parameters. Finally, NetworkManager provides a rich API via D-Bus which allows applications to query and control network configuration and state.
Previous versions of Fedora included the Network Administration Tool, which was commonly known as system-config-network after its command line invocation. In Fedora 17, NetworkManager replaces the former Network Administration Tool while providing enhanced functionality, such as user-specific and mobile broadband configuration. It is also possible to configure the network in Fedora 17 by editing interface configuration files; refer to Capítulo 7, Interfaces de red for more information.
NetworkManager may be installed by default on Fedora. To ensure that it is, first run the following command as the root user:
~]# yum install NetworkManager

6.1. The NetworkManager Daemon

The NetworkManager daemon runs with root privileges and is usually configured to start up at boot time. You can determine whether the NetworkManager daemon is running by entering this command as root:
~]# service NetworkManager status
NetworkManager (pid  1527) is running...
The service command will report NetworkManager is stopped if the NetworkManager service is not running. To start it for the current session:
~]# service NetworkManager start
Run the chkconfig command to ensure that NetworkManager starts up every time the system boots:
~]# chkconfig NetworkManager on
For more information on starting, stopping and managing services and runlevels, refer to Capítulo 8, Services and Daemons.

6.2. Interacting with NetworkManager

Users do not interact with the NetworkManager system service directly. Instead, you can perform network configuration tasks via NetworkManager's Notification Area applet. The applet has multiple states that serve as visual indicators for the type of connection you are currently using.
NetworkManager applet states
A row of four icons representing NetworkManager applet states
Figura 6.1. NetworkManager applet states

If you do not see the NetworkManager applet in the GNOME panel, and assuming that the NetworkManager package is installed on your system, you can start the applet by running the following command as a normal user (not root):
~]$ nm-applet &
After running this command, the applet appears in your Notification Area.

6.2.1. Connecting to a Network

When you click on the applet icon, you are presented with:
  • a list of categorized networks you are currently connected to (such as Wired and Wireless);
  • a list of all Available Networks that NetworkManager has detected;
  • options for connecting to any configured Virtual Private Networks (VPNs); and,
  • options for connecting to hidden or new wireless networks.
If you are connected to a network, its name is presented first under its network type, such as Wired or Wireless with a bulletpoint to the left. When many networks are available, such as wireless access points, the More networks expandable menu entry appears.
The NetworkManager applet's drop-down menu, showing all available and connected-to networks
A screen shot of the NetworkManager applet's drop-down menu, showing all available and connected-to networks
Figura 6.2. The NetworkManager applet's drop-down menu, showing all available and connected-to networks

6.2.2. Configuring New and Editing Existing Connections

Click on the NetworkManager applet to open the drop-down menu, this is the main point of entry for interacting with NetworkManager to configure connections.
If the system has detected a wired connection, the Wired menu entry will appear. If the system has detected a wireless card, then you will also see a Wireless menu entry. Clicking the Wired and Wireless labels or the associated ON OFF indicator to the right will toggle the status between ON and OFF.
Finally, clicking on the Network Settings menu entry opens the Network window, from where you can view some basic network configuration information and initiate configuration tasks.
Configure networks using the Network window
A screen shot of NetworkManager's Network window.
Figura 6.3. Configure networks using the Network window

Then, to configure:

6.2.3. Connecting to a Network Automatically

For any connection type you add or configure, you can choose whether you want NetworkManager to try to connect to that network automatically when it is available.
Procedimiento 6.1. Configuring NetworkManager to Connect to a Network Automatically When Detected
  1. Click on the NetworkManager applet icon in the Notification Area.
  2. Click Network Settings.
    The Network window appears.
  3. Select the type of connection from the left-hand-side menu.
  4. Click on Configure
  5. Select Connect automatically to cause NetworkManager to auto-connect to the connection whenever NetworkManager detects that it is available. Unselect the checkbox if you do not want NetworkManager to connect automatically. If the box is unchecked, you will have to select that connection manually in the NetworkManager applet's initial menu to cause it to connect.

6.2.4. User and System Connections

NetworkManager connections are always either user connections or system connections. Depending on the system-specific policy that the administrator has configured, users may need root privileges to create and modify system connections. NetworkManager's default policy enables users to create and modify user connections, but requires them to have root privileges to add, modify or delete system connections.
User connections are so-called because they are specific to the user who creates them. In contrast to system connections, whose configurations are stored under the /etc/sysconfig/network-scripts/ directory (mainly in ifcfg-<network_type> interface configuration files), user connection settings are stored in the GConf configuration database and the GNOME keyring, and are only available during login sessions for the user who created them. Thus, logging out of the desktop session causes user-specific connections to become unavailable.

Increase security by making VPN connections user-specific

Because NetworkManager uses the GConf and GNOME keyring applications to store user connection settings, and because these settings are specific to your desktop session, it is highly recommended to configure your personal VPN connections as user connections. If you do so, other non-root users on the system cannot view or access these connections in any way.
System connections, on the other hand, become available at boot time and can be used by other users on the system without first logging in to a desktop session.
NetworkManager can quickly and conveniently convert user to system connections and vice versa. Converting a user connection to a system connection causes NetworkManager to create the relevant interface configuration files under the /etc/sysconfig/network-scripts/ directory, and to delete the GConf settings from the user's session. Conversely, converting a system to a user-specific connection causes NetworkManager to remove the system-wide configuration files and create the corresponding GConf/GNOME keyring settings.
The Available to all users checkbox controls whether connections are user-specific or system-wide
A screen shot of the Available to all users checkbox
Figura 6.4. The Available to all users checkbox controls whether connections are user-specific or system-wide

Procedimiento 6.2. Changing a Connection to be User-Specific instead of System-Wide, or Vice-Versa

Root privileges may be required

Depending on the system's policy, you may need root privileges on the system in order to change whether a connection is user-specific or system-wide.
  1. Click on the NetworkManager applet icon in the Notification Area and click Network Settings. The Network window appears.
  2. Select the menu entry for the type of network connection you want to configure.
  3. Select the Configure button.
  4. Check the Available to all users checkbox to ask NetworkManager to make the connection a system-wide connection. Depending on system policy, you may then be prompted for the root password by the PolicyKit application. If so, enter the root password to finalize the change.
    Conversely, uncheck the Available to all users checkbox to make the connection user-specific.

6.3. Establishing Connections

6.3.1. Establishing a Wired (Ethernet) Connection

To establish a wired network connection, click on the NetworkManager applet to open its menu, then click on Network Settings. This opens the Network window.
Select the Wired menu entry and then click Configure.
Editing the newly-created Wired connection 1
A screen shot of Network Manager's Wired tab
Figura 6.5. Editing the newly-created Wired connection 1

The system startup scripts create and configure a single wired connection called System eth0 by default on all systems. Although you can edit System eth0, creating a new wired connection for your custom settings is recommended. You can create a new wired connection by selecting the Wired tab and clicking the Add button.

The dialog for adding and editing connections is the same

When you add a new connection by clicking the Add button, NetworkManager creates a new configuration file for that connection and then opens the same dialog that is used for editing an existing connection. There is no difference between these dialogs. In effect, you are always editing a connection; the difference only lies in whether that connection previously existed or was just created by NetworkManager when you clicked Add.

Configuring the Connection Name, Auto-Connect Behavior, and Availability Settings

Three settings in the Editing dialog are common to all connection types:
  • Connection name — Enter a descriptive name for your network connection. This name will be used to list this connection in the Wired tab of the Network Connections window.
  • Connect automatically — Check this box if you want NetworkManager to auto-connect to this connection when it is available. Refer to Sección 6.2.3, “Connecting to a Network Automatically” for more information.
  • Available to all users — Check this box to create a connection available to all users on the system. Changing this setting may require root privileges. Refer to Sección 6.2.4, “User and System Connections” for details.

Configuring the Wired Tab

The final two configurable settings are located within the Wired tab itself: the first is a text-entry field where you can specify a MAC (Media Access Control) address, and the second allows you to specify the MTU (Maximum Transmission Unit) value. Normally, you can leave the MAC address field blank and the MTU set to automatic. These defaults will suffice unless you are associating a wired connection with a second or specific NIC, or performing advanced networking. In such cases, refer to the following descriptions:
MAC Address
Network hardware such as a Network Interface Card (NIC) has a unique MAC address (Media Access Control; also known as a hardware address) that identifies it to the system. Running the ip addr command will show the MAC address associated with each interface. For example, in the following ip addr output, the MAC address for the eth0 interface (which is 52:54:00:26:9e:f1) immediately follows the link/ether keyword:
~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 52:54:00:26:9e:f1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.251/24 brd 192.168.122.255 scope global eth0
    inet6 fe80::5054:ff:fe26:9ef1/64 scope link
       valid_lft forever preferred_lft forever
A single system can have one or more NICs installed on it. The MAC address field therefore allows you to associate a specific NIC with a specific connection (or connections). As mentioned, you can determine the MAC address using the ip addr command, and then copy and paste that value into the MAC address text-entry field.
MTU
The MTU (Maximum Transmission Unit) value represents the size in bytes of the largest packet that the connection will use to transmit. This value defaults to 1500 when using IPv4, or a variable number 1280 or higher for IPv6, and does not generally need to be specified or changed.

Saving Your New (or Modified) Connection and Making Further Configurations

Once you have finished editing your wired connection, click the Apply button and NetworkManager will immediately save your customized configuration. Given a correct configuration, you can connect to your new or customized connection by selecting it from the NetworkManager Notification Area applet. See Sección 6.2.1, “Connecting to a Network” for information on using your new or altered connection.
You can further configure an existing connection by selecting it in the Network Connections window and clicking Edit to return to the Editing dialog.
Then, to configure:

6.3.2. Establishing a Wireless Connection

This section explains how to use NetworkManager to configure a wireless (also known as Wi-Fi or 802.1a/b/g/n) connection to an Access Point.
To configure a mobile broadband (such as 3G) connection, refer to Sección 6.3.3, “Establishing a Mobile Broadband Connection”.

Quickly Connecting to an Available Access Point

The easiest way to connect to an available access point is to click on the NetworkManager applet, locate the Service Set Identifier (SSID) of the access point in the list of available networks, and click on it. If the access point is secured, a dialog prompts you for authentication.
NetworkManager tries to auto-detect the type of security used by the access point. If there are multiple possibilities, NetworkManager guesses the security type and presents it in the Wireless security dropdown menu. To see if there are multiple choices, click the Wireless security dropdown menu and select the type of security the access point is using. If you are unsure, try connecting to each type in turn. Finally, enter the key or passphrase in the Password field. Certain password types, such as a 40-bit WEP or 128-bit WPA key, are invalid unless they are of a requisite length. The Connect button will remain inactive until you enter a key of the length required for the selected security type. To learn more about wireless security, refer to Sección 6.4.2, “Configuring Wireless Security”.
If NetworkManager connects to the access point successfully, its applet icon will change into a graphical indicator of the wireless connection's signal strength.
Applet icon indicating wireless connection signal strength
A screen shot of the Signal Strength Applet icon indicating wireless connection signal strength
Figura 6.6. Applet icon indicating wireless connection signal strength

Connecting to a Hidden Wireless Network

All access points have a Service Set Identifier (SSID) to identify them. However, an access point may be configured not to broadcast its SSID, in which case it is hidden, and will not show up in NetworkManager's list of Available networks. You can still connect to a wireless access point that is hiding its SSID as long as you know its SSID, authentication method, and secrets.
To connect to a hidden wireless network, click NetworkManager's applet icon and then click Network Settings. The Network window appears. Select the Wireless menu entry and then click to the right of the Network Name to activate the drop-down list. Select Other. The Hidden wireless network dialog window appears.
Hidden wireless network dialog window
A screen shot of NetworkManager's Hidden wireless network dialog window
Figura 6.7. Hidden wireless network dialog window

If you have connected to the hidden network before, use the Connection drop-down list to select it, and click Connect. If you have not, leave the Connection dropdown as New..., enter the SSID of the hidden network, select its Wireless security method, enter the correct authentication secrets, and click Connect.
For more information on wireless security settings, refer to Sección 6.4.2, “Configuring Wireless Security”.

Editing a Connection, or Creating a Completely New One

You can create a new connection by clicking on the NetworkManager applet to open its menu.
  1. Click on the NetworkManager applet icon in the Notification Area and click Network Settings. The Network window appears.
  2. Select the Wireless menu entry.
  3. Click to the right of the Network Name to activate the drop-down list.
  4. Select the SSID you want to connect to.
  5. Click the Configure button. The editing a wireless connection window appears.
Editing the newly-created Wireless connection
A screen shot of the NetworkManager's editing a wireless connection window. The Wireless tab has been selected on the left.
Figura 6.8. Editing the newly-created Wireless connection

Configuring the Connection Name, Auto-Connect Behavior, and Availability Settings

Three settings in the Editing dialog are common to all connection types:
  • Connection name — Enter a descriptive name for your network connection. This name will be used to list this connection in the Wireless tab of the Network Connections window. By default, wireless connections are named the same as the SSID of the wireless access point. You can rename the wireless connection without affecting its ability to connect, as in the example above, but it is recommended to retain the SSID name.
  • Connect automatically — Check this box if you want NetworkManager to auto-connect to this connection when it is available. Refer to Sección 6.2.3, “Connecting to a Network Automatically” for more information.
  • Available to all users — Check this box to create a connection available to all users on the system. Changing this setting may require root privileges. Refer to Sección 6.2.4, “User and System Connections” for details.

Configuring the Wireless Tab

SSID
All access points have a Service Set identifier to identify them. However, an access point may be configured not to broadcast its SSID, in which case it is hidden, and will not show up in NetworkManager's list of Available networks. You can still connect to a wireless access point that is hiding its SSID as long as you know its SSID (and authentication secrets).
For information on connecting to a hidden wireless network, refer to Sección 6.3.2, “Connecting to a Hidden Wireless Network”.
Mode
Infrastructure — Set Mode to Infrastructure if you are connecting to a dedicated wireless access point or one built into a network device such as a router or a switch.
Ad-hoc — Set Mode to Ad-hoc if you are creating a peer-to-peer network for two or more mobile devices to communicate directly with each other. If you use Ad-hoc mode, referred to as Independent Basic Service Set (IBSS) in the 802.11 standard, you must ensure that the same SSID is set for all participating wireless devices, and that they are all communicating over the same channel.
BSSID
The Basic Service Set Identifier (BSSID) is the MAC address of the specific wireless access point you are connecting to when in Infrastructure mode. This field is blank by default, and you are able to connect to a wireless access point by SSID without having to specify its BSSID. If the BSSID is specified, it will force the system to associate to a specific access point only.
For ad-hoc networks, the BSSID is generated randomly by the mac80211 subsystem when the ad-hoc network is created. It is not displayed by NetworkManager
MAC address
Like an Ethernet Network Interface Card (NIC), a wireless adapter has a unique MAC address (Media Access Control; also known as a hardware address) that identifies it to the system. Running the ip addr command will show the MAC address associated with each interface. For example, in the following ip addr output, the MAC address for the wlan0 interface (which is 00:1c:bf:02:f8:70) immediately follows the link/ether keyword:
~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 52:54:00:26:9e:f1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.251/24 brd 192.168.122.255 scope global eth0
    inet6 fe80::5054:ff:fe26:9ef1/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1c:bf:02:f8:70 brd ff:ff:ff:ff:ff:ff
    inet 10.200.130.67/24 brd 10.200.130.255 scope global wlan0
    inet6 fe80::21c:bfff:fe02:f870/64 scope link
       valid_lft forever preferred_lft forever
A single system could have one or more wireless network adapters connected to it. The MAC address field therefore allows you to associate a specific wireless adapter with a specific connection (or connections). As mentioned, you can determine the MAC address using the ip addr command, and then copy and paste that value into the MAC address text-entry field.
MTU
The MTU (Maximum Transmission Unit) value represents the size in bytes of the largest packet that the connection will use to transmit. If set to a non-zero number, only packets of the specified size or smaller will be transmitted. Larger packets are broken up into multiple Ethernet frames. It is recommended to leave this setting on automatic.

Saving Your New (or Modified) Connection and Making Further Configurations

Once you have finished editing the wireless connection, click the Apply button and NetworkManager will immediately save your customized configuration. Given a correct configuration, you can successfully connect to your the modified connection by selecting it from the NetworkManager Notification Area applet. See Sección 6.2.1, “Connecting to a Network” for details on selecting and connecting to a network.
You can further configure an existing connection by selecting it in the Network Connections window and clicking Edit to return to the Editing dialog.
Then, to configure:

6.3.3. Establishing a Mobile Broadband Connection

You can use NetworkManager's mobile broadband connection abilities to connect to the following 2G and 3G services:
  • 2G — GPRS (General Packet Radio Service) or EDGE (Enhanced Data Rates for GSM Evolution)
  • 3G — UMTS (Universal Mobile Telecommunications System) or HSPA (High Speed Packet Access)
Your computer must have a mobile broadband device (modem), which the system has discovered and recognized, in order to create the connection. Such a device may be built into your computer (as is the case on many notebooks and netbooks), or may be provided separately as internal or external hardware. Examples include PC card, USB Modem or Dongle, mobile or cellular telephone capable of acting as a modem.
Procedimiento 6.3. Adding a New Mobile Broadband Connection
You can configure a mobile broadband connection by opening the Network Connections window and selecting the Mobile Broadband tab.
  1. Open the Network Connections window by running, as a normal user:
    ~]$ nm-connection-editor &
    
    The Network Connections window appears.
  2. Select the Mobile Broadband tab.
  3. Click the Add button to open the Set up a Mobile Broadband Connection assistant.
  4. Under Create a connection for this mobile broadband device, choose the 2G- or 3G-capable device you want to use with the connection. If the dropdown menu is inactive, this indicates that the system was unable to detect a device capable of mobile broadband. In this case, click Cancel, ensure that you do have a mobile broadband-capable device attached and recognized by the computer and then retry this procedure. Click the Forward button.
  5. Select the country where your service provider is located from the list and click the Forward button.
  6. Select your provider from the list or enter it manually. Click the Forward button.
  7. Select your payment plan from the dropdown menu and confirm the Access Point Name (APN) is correct. Click the Forward button.
  8. Review and confirm the settings and then click the Apply button.
  9. Edit the mobile broadband-specific settings by referring to the Configuring the Mobile Broadband Tab description below .
Procedimiento 6.4. Editing an Existing Mobile Broadband Connection
Follow these steps to edit an existing mobile broadband connection.
  1. Open the Network Connections window by running, as a normal user:
    ~]$ nm-connection-editor &
    
    The Network Connections window appears.
  2. Select the Mobile Broadband tab.
  3. Select the connection you wish to edit and click the Edit button.
  4. Configure the connection name, auto-connect behavior, and availability settings.
    Three settings in the Editing dialog are common to all connection types:
    • Connection name — Enter a descriptive name for your network connection. This name will be used to list this connection in the Mobile Broadband tab of the Network Connections window.
    • Connect automatically — Check this box if you want NetworkManager to auto-connect to this connection when it is available. Refer to Sección 6.2.3, “Connecting to a Network Automatically” for more information.
    • Available to all users — Check this box to create a connection available to all users on the system. Changing this setting may require root privileges. Refer to Sección 6.2.4, “User and System Connections” for details.
  5. Edit the mobile broadband-specific settings by referring to the Configuring the Mobile Broadband Tab description below .

Saving Your New (or Modified) Connection and Making Further Configurations

Once you have finished editing your mobile broadband connection, click the Apply button and NetworkManager will immediately save your customized configuration. Given a correct configuration, you can connect to your new or customized connection by selecting it from the NetworkManager Notification Area applet. See Sección 6.2.1, “Connecting to a Network” for information on using your new or altered connection.
You can further configure an existing connection by selecting it in the Network Connections window and clicking Edit to return to the Editing dialog.
Then, to configure:

Configuring the Mobile Broadband Tab

If you have already added a new mobile broadband connection using the assistant (refer to Procedimiento 6.3, “Adding a New Mobile Broadband Connection” for instructions), you can edit the Mobile Broadband tab to disable roaming if home network is not available, assign a network ID, or instruct NetworkManager to prefer a certain technology (such as 3G or 2G) when using the connection.
Number
The number that is dialed to establish a PPP connection with the GSM-based mobile broadband network. This field may be automatically populated during the initial installation of the broadband device. You can usually leave this field blank and enter the APN instead.
Username
Enter the username used to authenticate with the network. Some providers do not provide a username, or accept any username when connecting to the network.
Password
Enter the password used to authenticate with the network. Some providers do not provide a password, or accept any password.
APN
Enter the Access Point Name (APN) used to establish a connection with the GSM-based network. Entering the correct APN for a connection is important because it often determines:
  • how the user is billed for their network usage; and/or
  • whether the user has access to the Internet, an intranet, or a subnetwork.
Network ID
Entering a Network ID causes NetworkManager to force the device to register only to a specific network. This can be used to ensure the connection does not roam when it is not possible to control roaming directly.
Type
Any — The default value of Any leaves the modem to select the fastest network.
3G (UMTS/HSPA) — Force the connection to use only 3G network technologies.
2G (GPRS/EDGE) — Force the connection to use only 2G network technologies.
Prefer 3G (UMTS/HSPA) — First attempt to connect using a 3G technology such as HSPA or UMTS, and fall back to GPRS or EDGE only upon failure.
Prefer 2G (GPRS/EDGE) — First attempt to connect using a 2G technology such as GPRS or EDGE, and fall back to HSPA or UMTS only upon failure.
Allow roaming if home network is not available
Uncheck this box if you want NetworkManager to terminate the connection rather than transition from the home network to a roaming one, thereby avoiding possible roaming charges. If the box is checked, NetworkManager will attempt to maintain a good connection by transitioning from the home network to a roaming one, and vice versa.
PIN
If your device's SIM (Subscriber Identity Module) is locked with a PIN (Personal Identification Number), enter the PIN so that NetworkManager can unlock the device. NetworkManager must unlock the SIM if a PIN is required in order to use the device for any purpose.

6.3.4. Establishing a VPN Connection

Establishing an encrypted Virtual Private Network (VPN) enables you to communicate securely between your Local Area Network (LAN), and another, remote LAN. After successfully establishing a VPN connection, a VPN router or gateway performs the following actions upon the packets you transmit:
  1. it adds an Authentication Header for routing and authentication purposes;
  2. it encrypts the packet data; and,
  3. it encloses the data with an Encapsulating Security Payload (ESP), which constitutes the decryption and handling instructions.
The receiving VPN router strips the header information, decrypts the data, and routes it to its intended destination (either a workstation or other node on a network). Using a network-to-network connection, the receiving node on the local network receives the packets already decrypted and ready for processing. The encryption/decryption process in a network-to-network VPN connection is therefore transparent to clients.
Because they employ several layers of authentication and encryption, VPNs are a secure and effective means of connecting multiple remote nodes to act as a unified intranet.
Procedimiento 6.5. Adding a New VPN Connection
  1. You can configure a new VPN connection by opening the Network window and selecting the VPN menu entry.
  2. Click on the NetworkManager applet icon in the Notification Area. Clicking on the Network Settings menu entry opens the Network window, from where you can view some basic network configuration information and initiate configuration tasks.
  3. Click on the VPN menu entry followed by Configure and proceed to Sección 6.3.4, “Establishing a VPN Connection”. If there is no VPN menu entry click on the plus sign at the bottom. A dialog box appears. Ensure the interface is set to VPN.

    A VPN plug-in is required

    The appropriate NetworkManager VPN plug-in for the VPN type you want to configure must be installed. (refer to Sección 4.2.4, “Installing Packages” for more information on how to install new packages in Fedora 17).
  4. Click the Create button to open the Choose a VPN Connection Type assistant.
  5. Select the VPN protocol for the gateway you are connecting to from the dropdown menu. The VPN protocols available for selection in the dropdown menu corresponds to the NetworkManager VPN plug-ins installed. For example, if the NetworkManager VPN plug-in for openswanis installed then the IPsec based VPN will be selectable from the dropdown menu.
    After selecting the correct one, press the Create... button.
  6. The Editing VPN Connection 1 window then appears. This window presents settings customized for the type of VPN connection you selected in Paso 5.
You can configure an existing VPN connection by opening the Network window and selecting the VPN menu entry.
  1. Click on the NetworkManager applet icon in the Notification Area and click Network Settings. The Network window appears.
  2. Select the VPN menu entry.
  3. Select the connection you wish to edit and click the Configure button.
Editing the newly-created VPN connection 1.
A screenshot of the Editing VPN connection 1 window. The VPN tab is on the left and in the foreground
Figura 6.9. Editing the newly-created VPN connection 1.

Configuring the Connection Name, Auto-Connect Behavior, and Availability Settings

Three settings in the Editing dialog are common to all connection types:
  • Connection name — Enter a descriptive name for your network connection. This name will be used to list this connection in the VPN tab of the Network Connections window.
  • Connect automatically — Check this box if you want NetworkManager to auto-connect to this connection when it is available. Refer to Sección 6.2.3, “Connecting to a Network Automatically” for more information.
  • Available to all users — Check this box to create a connection available to all users on the system. Changing this setting may require root privileges. Refer to Sección 6.2.4, “User and System Connections” for details.

Configuring the VPN Tab

Gateway
The name or IP address of the remote VPN gateway.
Group name
The name of a VPN group configured on the remote gateway.
User password
If required, enter the password used to authenticate with the VPN.
Group password
If required, enter the password used to authenticate with the VPN.
User name
If required, enter the username used to authenticate with the VPN.
Phase1 Algorithms
If required, enter the algorithms to be used to authenticate and set up an encrypted channel.
Phase2 Algorithms
If required, enter the algorithms to be used for the IPsec negotiations.
Domain
If required, enter the Domain Name.
NAT traversal
Cisco UDP (default) — IPsec over UDP.
NAT-T — ESP encapsulation and IKE extensions are used to handle NAT Traversal.
Disabled — No special NAT measures required.
Disable Dead Peer Detection — Disable the sending of probes to the remote gateway or endpoint.

Saving Your New (or Modified) Connection and Making Further Configurations

Once you have finished editing your new VPN connection, click the Apply button and NetworkManager will immediately save your customized configuration. Given a correct configuration, you can connect to your new or customized connection by selecting it from the NetworkManager Notification Area applet. See Sección 6.2.1, “Connecting to a Network” for information on using your new or altered connection.
You can further configure an existing connection by selecting it in the Network Connections window and clicking Edit to return to the Editing dialog.
Then, to configure:

6.3.5. Establishing a DSL Connection

Open the Network Connections window by running, as a normal user:
~]$ nm-connection-editor &
Select the DSL tab and click Add.
Username
Enter the username used to authenticate with the service provider.
Service
Leave blank unless otherwise directed.
Password
Enter the password supplied by the service provider.

6.3.6. Establishing Routes

Configuring static network routes
A screen shot of the static routes window
Figura 6.10. Configuring static network routes

Addresses
Address — The IP address of a network, sub-net or host.
Netmask — The netmask or prefix length of the IP address just entered.
Gateway — The IP address of the gateway leading to the network, sub-net or host.
Metric — A network cost, that is to say a preference value to give to this route. Lower values will be preferred over higher values.
Ignore automatically obtained routes
Select this check box to only use manually entered routes for the VPN tunnel.
Use this connection only for resources on its network
Select this checkbox to prevent the VPN from becoming the default route. Then only the specific routes sent by the VPN server (or routes entered here manually) will be routed over the VPN tunnel.

6.4. Configuring Connection Settings

6.4.1. Configuring 802.1x Security

802.1x security is the name of the IEEE standard for port-based Network Access Control (PNAC). Simply put, 802.1x security is a way of defining a logical network out of a physical one. All clients who want to join the logical network must authenticate with the server (a router, for example) using the correct 802.1x authentication method.
802.1x security is most often associated with securing wireless networks (WLANs), but can also be used to prevent intruders with physical access to the network (LAN) from gaining entry. In the past, DHCP servers were configured not to lease IP addresses to unauthorized users, but for various reasons this practice is both impractical and insecure, and thus is no longer recommended. Instead, 802.1x security is used to ensure a logically-secure network through port-based authentication.
802.1x provides a framework for WLAN and LAN access control and serves as an envelope for carrying one of the Extensible Authentication Protocol (EAP) types. An EAP type is a protocol that defines how WLAN security is achieved on the network.
You can configure 802.1x security for a wired or wireless connection type by opening the Network Connections window (refer to Sección 6.2.2, “Configuring New and Editing Existing Connections”) and following the applicable procedure:
Procedimiento 6.6. For a wired connection...
  1. Select the Wired tab.
  2. Either click on Add to add a new network connection for which you want to configure 802.1x security, or select an existing connection and click Edit.
  3. Then select the 802.1x Security tab and check the Use 802.1x security for this connection checkbox to enable settings configuration.
Procedimiento 6.7. For a wireless connection...
  1. Select the Wireless tab.
  2. Either click on Add to add a new network connection for which you want to configure 802.1x security, or select an existing connection and click Edit.
  3. Then click the Security dropdown and choose one of the following security methods: LEAP, Dynamic WEP (802.1x), or WPA & WPA2 Enterprise.
  4. Refer to Sección 6.4.1.1, “Configuring TLS (Transport Layer Security) Settings” for descriptions of which EAP types correspond to your selection in the Security dropdown.

6.4.1.1. Configuring TLS (Transport Layer Security) Settings

With Transport Layer Security, the client and server mutually authenticate using the TLS protocol. The server demonstrates that it holds a digital certificate, the client proves its own identity using its client-side certificate, and key information is exchanged. Once authentication is complete, the TLS tunnel is no longer used. Instead, the client and server use the exchanged keys to encrypt data using AES, TKIP or WEP.
The fact that certificates must be distributed to all clients who want to authenticate means that the EAP-TLS authentication method is very strong, but also more complicated to set up. Using TLS security requires the overhead of a public key infrastructure (PKI) to manage certificates. The benefit of using TLS security is that a compromised password does not allow access to the (W)LAN: an intruder must also have access to the authenticating client's private key.
Network Manger does not determine the version of TLS supported. Network Manager gathers the parameters entered by the user and passes them to the daemon, wpa_supplicant, that handles the procedure. It, in turn, uses OpenSSL to establish the TLS tunnel. OpenSSL itself negotiates the SSL/TLS protocol version. It uses the highest version both ends support.
Identity
Identity string for EAP authentication methods, such as a username or login name.
User certificate
Click to browse for, and select, a user's certificate.
CA certificate
Click to browse for, and select, a Certificate Authority's certificate.
Private key
Click to browse for, and select, a user's private key file.
Private key password
Enter the user password corresponding to the user's private key.

6.4.1.2. Configuring Tunneled TLS Settings

Anonymous identity
This value is used as the unencrypted identity.
CA certificate
Click to browse for, and select, a Certificate Authority's certificate.
Inner authentication
PAP — Password Authentication Protocol.
MSCHAP — Challenge Handshake Authentication Protocol.
MSCHAPv2 — Microsoft Challenge Handshake Authentication Protocol version 2.
CHAP — Challenge Handshake Authentication Protocol.
Username
Enter the username to be used in the authentication process.
Password
Enter the password to be used in the authentication process.

6.4.1.3. Configuring Protected EAP (PEAP) Settings

Anonymous Identity
This value is used as the unencrypted identity.
CA certificate
Click to browse for, and select, a Certificate Authority's certificate.
PEAP version
The version of Protected EAP to use. Automatic, 0 or 1.
Inner authentication
MSCHAPv2 — Microsoft Challenge Handshake Authentication Protocol version 2.
MD5 — Message Digest 5, a cryptographic hash function.
GTC — Generic Token Card.
Username
Enter the username to be used in the authentication process.
Password
Enter the password to be used in the authentication process.

6.4.2. Configuring Wireless Security

Security
None — Do not encrypt the Wi-Fi connection.
WEP 40/128-bit Key — Wired Equivalent Privacy (WEP), from the IEEE 802.11 standard. Uses a single pre-shared key (PSK).
WEP 128-bit Passphrase — An MD5 hash of the passphrase will be used to derive a WEP key.
LEAP — Lightweight Extensible Authentication Protocol, from Cisco Systems.
Dynamic WEP (802.1x) — WEP keys are changed dynamically.
WPA & WPA2 Personal — Wi-Fi Protected Access (WPA), from the draft IEEE 802.11i standard. A replacement for WEP. Wi-Fi Protected Access II (WPA2), from the 802.11i-2004 standard. Personal mode uses a pre-shared key (WPA-PSK).
WPA & WPA2 Enterprise — WPA for use with a RADUIS authentication server to provide IEEE 802.1x network access control.
Password
Enter the password to be used in the authentication process.

6.4.3. Configuring PPP (Point-to-Point) Settings

Configure Methods
Use point-to-point encryption (MPPE)
Microsoft Point-To-Point Encryption protocol (RFC 3078).
Allow BSD data compression
PPP BSD Compression Protocol (RFC 1977).
Allow Deflate data compression
PPP Deflate Protocol (RFC 1979).
Use TCP header compression
Compressing TCP/IP Headers for Low-Speed Serial Links (RFC 1144).
Send PPP echo packets
LCP Echo-Request and Echo-Reply Codes for loopback tests (RFC 1661).

6.4.4. Configuring IPv4 Settings

Editing the IPv4 Settings Tab
A screen shot of NetworkManager's IPv4 Settings Tab
Figura 6.11. Editing the IPv4 Settings Tab

The IPv4 Settings tab allows you to configure the method by which you connect to the Internet and enter IP address, route, and DNS information as required. The IPv4 Settings tab is available when you create and modify one of the following connection types: wired, wireless, mobile broadband, VPN or DSL.
If you are using DHCP to obtain a dynamic IP address from a DHCP server, you can simply set Method to Automatic (DHCP).

Setting the Method

Available IPv4 Methods by Connection Type
When you click the Method dropdown menu, depending on the type of connection you are configuring, you are able to select one of the following IPv4 connection methods. All of the methods are listed here according to which connection type or types they are associated with.
Method
Automatic (DHCP) — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses. You do not need to fill in the DHCP client ID field.
Automatic (DHCP) addresses only — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses but you want to assign DNS servers manually.
Link-Local Only — Choose this option if the network you are connecting to does not have a DHCP server and you do not want to assign IP addresses manually. Random addresses will be selected as per RFC 3927.
Shared to other computers — Choose this option if the interface you are configuring is for sharing an Internet or WAN connection.
Wired, Wireless and DSL Connection Methods
Manual — Choose this option if the network you are connecting to does not have a DHCP server and you want to assign IP addresses manually.
Mobile Broadband Connection Methods
Automatic (PPP) — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses.
Automatic (PPP) addresses only — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses but you want to assign DNS servers manually.
VPN Connection Methods
Automatic (VPN) — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses.
Automatic (VPN) addresses only — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses but you want to assign DNS servers manually.
DSL Connection Methods
Automatic (PPPoE) — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses.
Automatic (PPPoE) addresses only — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses but you want to assign DNS servers manually.

6.4.5. Configuring IPv6 Settings

Method
Ignore — Choose this option if you want to disable IPv6 settings.
Automatic — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses.
Automatic, addresses only — Choose this option if the network you are connecting to uses a DHCP server to assign IP addresses but you want to assign DNS servers manually.
Manual — Choose this option if the network you are connecting to does not have a DHCP server and you want to assign IP addresses manually.
Link-Local Only — Choose this option if the network you are connecting to does not have a DHCP server and you do not want to assign IP addresses manually. Random addresses will be selected as per RFC 4862.
Shared to other computers — Choose this option if the interface you are configuring is for sharing an Internet or WAN connection.
Addresses
DNS servers — Enter a comma separated list of DNS servers.
Search domains — Enter a comma separated list of domain controllers.

6.5. NetworkManager Architecture

Capítulo 7. Interfaces de red

En Fedora, todas las comunicaciones de red ocurren entre las interfaces de software configuradas y los dispositivos físicos de red conectados al sistema.
The configuration files for network interfaces are located in the /etc/sysconfig/network-scripts/ directory. The scripts used to activate and deactivate these network interfaces are also located here. Although the number and type of interface files can differ from system to system, there are three categories of files that exist in this directory:
  1. Archivo de configuración de interfaces
  2. Scripts de control de interfaces
  3. Archivos de funciones de red
Los archivos en cada una de estas categorías trabajan juntos para habilitar varios dispositivos de red.
Este capítulo explora la relación entre estos archivos y cómo son utilizados.

7.1. Archivos de configuración de red

Antes de ingresar a la interfaz de configuración, permítanos enumerar los archivos primarios utilizados en la configuración de red. Entender la función que estos archivos desarrollan en la configuración de la red puede ser de mucha utilidad a la hora de personalizar un sistema Fedora
Los principales archivos de configuración de la red son los siguientes:
/etc/hosts
The main purpose of this file is to resolve hostnames that cannot be resolved any other way. It can also be used to resolve hostnames on small networks with no DNS server. Regardless of the type of network the computer is on, this file should contain a line specifying the IP address of the loopback device (127.0.0.1) as localhost.localdomain. For more information, refer to the hosts(5) manual page.
/etc/resolv.conf
This file specifies the IP addresses of DNS servers and the search domain. Unless configured to do otherwise, the network initialization scripts populate this file. For more information about this file, refer to the resolv.conf(5) manual page.
/etc/sysconfig/network
Este archivo especifica la información de enrutamiento y equipo para todas las interfaces de red. Para más información sobre este archivo y las directivas que acepta, consulte Sección D.1.13, “ /etc/sysconfig/network ”.
/etc/sysconfig/network-scripts/ifcfg-interface-name
Para cada interfaz de red existe un script de configuración de interfaz correspondiente. Cada uno de esos archivos ofrece información específica a una determinada interfaz de red. Consulte Sección 7.2, “Archivos de configuración de interfaz” para obtener mayor información relacionada con este tipo de archivos y sobre los directorios que acepta.

Nombres de las interfaces de red

Los nombres de las interfaces de red pueden ser diferentes de acuerdo al tipo de harware. Consulte Apéndice A, Nombramiento Consistente de Dispositivos de Red para obtener mayor información.

El directorio /etc/sysconfig/networking/

The /etc/sysconfig/networking/ directory is used by the now deprecated Network Administration Tool (system-config-network). Its contents should not be edited manually. Using only one method for network configuration is strongly encouraged, due to the risk of configuration deletion. For more information about configuring network interfaces using graphical configuration tools, refer to Capítulo 6, NetworkManager.

7.2. Archivos de configuración de interfaz

Los archivos de configuración de interfaz controlan las interfaces de software de los dispositivos de red individuales. Cuando el sistema se inicia utiliza estos archivos para determinar qué interfaces levantar y de qué manera configurarlas. Estos archivos por lo general son denominados ifcfg-nombre , donde nombre indica el nombre del dispositivo que es controlado por el archivo de configuración.

7.2.1. Interfaces Ethernet

One of the most common interface files is /etc/sysconfig/network-scripts/ifcfg-eth0, which controls the first Ethernet network interface card or NIC in the system. In a system with multiple NICs, there are multiple ifcfg-ethX files (where X is a unique number corresponding to a specific interface). Because each device has its own configuration file, an administrator can control how each interface functions individually.
El siguiente es un archivo ifcfg-eth0 de ejemplo para un sistema usando dirección IP fija:
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
NETMASK=255.255.255.0
IPADDR=10.0.1.27
USERCTL=no
Los valores necesarios en un archivo de configuración de interfaz pueden modificarse de acuerdo a otros valores diferentes. Por ejemplo, el archivo ifcfg-eth0 de una interfaz que esté utilizando DHCP luce diferente de acuerdo a la información IP ofrecida por el servidor DHCP:
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
NetworkManager is graphical configuration tool which provides an easy way to make changes to the various network interface configuration files (refer to Capítulo 6, NetworkManager for detailed instructions on using this tool).
Sin embargo, también es posible modificar manualmente los archivos de configuración para una interfaz de red dada.
Abajo hay un listado de los parámetros configurables en un archivo de configuración de interfaz Ethernet.
BONDING_OPTS=parameters
sets the configuration parameters for the bonding device, and is used in /etc/sysconfig/network-scripts/ifcfg-bondN (see Sección 7.2.2, “Interfaces de unión de canales”). These parameters are identical to those used for bonding devices in /sys/class/net/bonding_device/bonding, and the module parameters for the bonding driver as described in bonding Module Directives.
This configuration method is used so that multiple bonding devices can have different configurations. It is highly recommended to place all of your bonding options after the BONDING_OPTS directive in ifcfg-name. Do not specify options for the bonding device in /etc/modprobe.d/bonding.conf, or in the deprecated /etc/modprobe.conf file.
BOOTPROTO=protocol
where protocol is one of the following:
  • none — No boot-time protocol should be used.
  • bootp — The BOOTP protocol should be used.
  • dhcp — The DHCP protocol should be used.
BROADCAST=address
where address is the broadcast address. This directive is deprecated, as the value is calculated automatically with ipcalc.
DEVICE=name
where name is the name of the physical device (except for dynamically-allocated PPP devices where it is the logical name).
DHCP_HOSTNAME=name
donde nombre es un pequeño nombre de equipo que será enviado al servidor DHCP. Utilice esta opción sólo si el servidor DHCP necesita que el cliente indique un nombre de equipo antes de recibir una dirección IP.
DNS{1,2}=address
where address is a name server address to be placed in /etc/resolv.conf if the PEERDNS directive is set to yes.
ETHTOOL_OPTS=options
where options are any device-specific options supported by ethtool. For example, if you wanted to force 100Mb, full duplex:
ETHTOOL_OPTS="autoneg off speed 100 duplex full"
Instead of a custom initscript, use ETHTOOL_OPTS to set the interface speed and duplex settings. Custom initscripts run outside of the network init script lead to unpredictable results during a post-boot network service restart.

Set autoneg off before changing speed or duplex settings

Changing speed or duplex settings almost always requires disabling autonegotiation with the autoneg off option. This option needs to be stated first, as the option entries are order-dependent.
GATEWAY=address
donde address es la dirección IP del enrutador o dispositivo de puerta de enlace (si existe).
HOTPLUG=answer
donde answer es una de las siguientes:
  • yes — This device should be activated when it is hot-plugged (this is the default option).
  • no — This device should not be activated when it is hot-plugged.
La opción HOTPLUG=no puede ser utilizada para prevenir que una interfaz de enlace de canales sea activada cada vez que se cargue un módulo de enlace del kernel.
Consulte xref linkend="s2-networkscripts-interfaces-chan" /> para obtener mayor información acerca de las interfaces de enlace de canales.
HWADDR=MAC-address
where MAC-address is the hardware address of the Ethernet device in the form AA:BB:CC:DD:EE:FF. This directive must be used in machines containing more than one NIC to ensure that the interfaces are assigned the correct device names regardless of the configured load order for each NIC's module. This directive should not be used in conjunction with MACADDR.

Nota

Persistent device names are now handled by /etc/udev/rules.d/70-persistent-net.rules.
IPADDR=address
where address is the IP address.
LINKDELAY=time
donde tiempo es la cantidad de segundos a esperar la negociación del enlace antes de configurar este dispositivo.
MACADDR=MAC-address
where MAC-address is the hardware address of the Ethernet device in the form AA:BB:CC:DD:EE:FF.
This directive is used to assign a MAC address to an interface, overriding the one assigned to the physical NIC. This directive should not be used in conjunction with the HWADDR directive.
MASTER=bond-interface
where bond-interface is the channel bonding interface to which the Ethernet interface is linked.
This directive is used in conjunction with the SLAVE directive.
Consulte xref linkend="s2-networkscripts-interfaces-chan" /> para obtener mayor información acerca de las interfaces de enlace de canales.
NETMASK=mask
where mask is the netmask value.
NETWORK=address
where address is the network address. This directive is deprecated, as the value is calculated automatically with ipcalc.
NM_CONTROLLED=answer
donde answer es una de las siguientes:
  • yes — NetworkManager is permitted to configure this device.This is the default behavior and can be omitted.
  • no — NetworkManager is not permitted to configure this device.
ONBOOT=answer
donde answer es una de las siguientes:
  • yes — This device should be activated at boot-time.
  • no — This device should not be activated at boot-time.
PEERDNS=answer
donde answer es una de las siguientes:
  • yes — Modify /etc/resolv.conf if the DNS directive is set. If using DHCP, then yes is the default.
  • no — Do not modify /etc/resolv.conf.
SLAVE=answer
donde answer es una de las siguientes:
  • yes — This device is controlled by the channel bonding interface specified in the MASTER directive.
  • no — This device is not controlled by the channel bonding interface specified in the MASTER directive.
This directive is used in conjunction with the MASTER directive.
Refer to Sección 7.2.2, “Interfaces de unión de canales” for more about channel bonding interfaces.
SRCADDR=address
where address is the specified source IP address for outgoing packets.
USERCTL=answer
donde answer es una de las siguientes:
  • yes — Non-root users are allowed to control this device.
  • no — Non-root users are not allowed to control this device.

7.2.2. Interfaces de unión de canales

Fedora allows administrators to bind multiple network interfaces together into a single channel using the bonding kernel module and a special network interface called a channel bonding interface. Channel bonding enables two or more network interfaces to act as one, simultaneously increasing the bandwidth and providing redundancy.
To create a channel bonding interface, create a file in the /etc/sysconfig/network-scripts/ directory called ifcfg-bondN, replacing N with the number for the interface, such as 0.
The contents of the file can be identical to whatever type of interface is getting bonded, such as an Ethernet interface. The only difference is that the DEVICE directive is bondN, replacing N with the number for the interface.
A continuación se muestra un ejemplo de un archivo de configuración de unión de canales:
Ejemplo 7.1. Sample ifcfg-bond0 interface configuration file
DEVICE=bond0
IPADDR=192.168.1.1
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
BONDING_OPTS="bonding parameters separated by spaces"

After the channel bonding interface is created, the network interfaces to be bound together must be configured by adding the MASTER and SLAVE directives to their configuration files. The configuration files for each of the channel-bonded interfaces can be nearly identical.
For example, if two Ethernet interfaces are being channel bonded, both eth0 and eth1 may look like the following example:
DEVICE=ethN
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
En este ejemplo, reemplace N con un valor numérico para la interfaz.
For a channel bonding interface to be valid, the kernel module must be loaded. To ensure that the module is loaded when the channel bonding interface is brought up, create a new file as root named bonding.conf in the /etc/modprobe.d/ directory. Note that you can name this file anything you like as long as it ends with a .conf extension. Insert the following line in this new file:
alias bondN bonding
Replace N with the interface number, such as 0. For each configured channel bonding interface, there must be a corresponding entry in your new /etc/modprobe.d/bonding.conf file.

Put all bonding module parameters in ifcfg-bondN files

Parameters for the bonding kernel module must be specified as a space-separated list in the BONDING_OPTS="bonding parameters" directive in the ifcfg-bondN interface file. Do not specify options for the bonding device in /etc/modprobe.d/bonding.conf, or in the deprecated /etc/modprobe.conf file. For further instructions and advice on configuring the bonding module and to view the list of bonding parameters, refer to Sección 22.7.2, “Using Channel Bonding”.

7.2.3. Network Bridge

A network bridge is a Link Layer device which forwards traffic between networks based on MAC addresses and is therefore also referred to as a Layer 2 device. It makes forwarding decisions based on tables of MAC addresses which it builds by learning what hosts are connected to each network. A software bridge can be used within a Linux host in order to emulate a hardware bridge, for example in virtualization applications for sharing a NIC with one or more virtual NICs. This case will be illustrated here as an example.
To create a network bridge, create a file in the /etc/sysconfig/network-scripts/ directory called ifcfg-brN, replacing N with the number for the interface, such as 0.
The contents of the file is similar to whatever type of interface is getting bridged to, such as an Ethernet interface. The differences in this example are as follows:
  • The DEVICE directive is given an interface name as its argument in the format brN, where N is replaced with the number of the interface.
  • The TYPE directive is given an argument Bridge or Ethernet. This directive determines the device type and the argument is case sensitive.
  • The bridge interface configuration file now has the IP address and the physical interface has only a MAC address.
  • An extra directive, DELAY=0, is added to prevent the bridge from waiting while it monitors traffic, learns where hosts are located, and builds a table of MAC addresses on which to base its filtering decisions. The default delay of 30 seconds is not needed if no routing loops are possible.
  • The NM_CONTROLLED=no should be added to the Ethernet interface to prevent NetworkManager from altering the file. It can also be added to the bridge configuration file in case future versions of NetworkManager support bridge configuration.
The following is a sample bridge interface configuration file using a static IP address:
Ejemplo 7.2. Sample ifcfg-br0 interface configuration file
DEVICE=br0
TYPE=Bridge
IPADDR=192.168.1.1
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=static
NM_CONTROLLED=no
DELAY=0

To complete the bridge another interface is created, or an existing interface is modified, and pointed to the bridge interface. The following is a sample Ethernet interface configuration file pointing to a bridge interface. Configure your physical interface in /etc/sysconfig/network-scripts/ifcfg-ethX, where X is a unique number corresponding to a specific interface, as follows:
Ejemplo 7.3. Sample ifcfg-ethX interface configuration file
DEVICE=ethX
TYPE=Ethernet
HWADDR=AA:BB:CC:DD:EE:FF
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
BRIDGE=br0

Note

For the DEVICE directive, almost any interface name could be used as it does not determine the device type. Other commonly used names include tap, dummy and bond for example. TYPE=Ethernet is not strictly required. If the TYPE directive is not set, the device is treated as an Ethernet device (unless it's name explicitly matches a different interface configuration file.)
You can refer to Sección 7.2, “Archivos de configuración de interfaz” for a review of the directives and options used in network interface config files.

Warning

If you are configuring bridging on a remote host, and you are connected to that host over the physical NIC you are configuring, please consider the implications of losing connectivity before proceeding. You will lose connectivity when restarting the service and may not be able to regain connectivity if any errors have been made. Console, or out-of-band access is advised.
Restart the networking service, in order for the changes to take effect by running as root:
 systemctl restart network.service 
An example of a network bridge formed from two or more bonded Ethernet interfaces will now be given as this is another common application in a virtualization environment. If you are not very familiar with the configuration files for bonded interfaces then please refer to Sección 7.2.2, “Interfaces de unión de canales”
Create or edit two or more Ethernet interface configuration files, which are to be bonded, as follows:
DEVICE=ethX
TYPE=Ethernet
USERCTL=no
SLAVE=yes
MASTER=bond0
BOOTPROTO=none
HWADDR=AA:BB:CC:DD:EE:FF
NM_CONTROLLED=no

Note

Using ethX as the interface name is common practice but almost any name could be used. Names such as tap, dummy and bond are commonly used.
Create or edit one interface configuration file, /etc/sysconfig/network-scripts/ifcfg-bond0, as follows:
DEVICE=bond0
ONBOOT=yes
BONDING_OPTS='mode=1 miimon=100'
BRIDGE=brbond0
NM_CONTROLLED=no
For further instructions and advice on configuring the bonding module and to view the list of bonding parameters, refer to Sección 22.7.2, “Using Channel Bonding”.
Create or edit one interface configuration file, /etc/sysconfig/network-scripts/ifcfg-brbond0, as follows:
DEVICE=brbond0
ONBOOT=yes
TYPE=Bridge
IPADDR=192.168.1.1
NETMASK=255.255.255.0
NM_CONTROLLED=no
A network bridge consisting of two bonded Ethernet interfaces.
A diagram of two Ethernet interfaces on the left feeding into a virtual interface labeled bond 0. This in turn leads to a virtual interface called BR Bond 0 on the right. From there a path leads to a virtual network below.
Figura 7.1. A network bridge consisting of two bonded Ethernet interfaces.

We now have two or more interface configuration files with the MASTER=bond0 directive. These point to the configuration file named /etc/sysconfig/network-scripts/ifcfg-bond0, which contains the DEVICE=bond0 directive. This ifcfg-bond0 in turn points to the /etc/sysconfig/network-scripts/ifcfg-brbond0 configuration file, which contains the IP address, and acts as an interface to the virtual networks inside the host.
Restart the networking service, in order for the changes to take effect by running as root:
 systemctl restart network.service 

7.2.4. Setting up 802.1q VLAN tagging

  1. Ensure that the module is loaded by entering the following command:
     lsmod | grep 8021q
  2. If the module is not loaded, load it with the following command:
    modprobe 8021q
  3. Configure your physical interface in /etc/sysconfig/network-scripts/ifcfg-ethX, where X is a unique number corresponding to a specific interface, as follows:
    DEVICE=ethX
    TYPE=Ethernet
    BOOTPROTO=none
    ONBOOT=yes
  4. Configure the VLAN interface configuration in /etc/sysconfig/network-scripts. The configuration filename should be the physical interface plus a . character plus the VLAN ID number. For example, if the VLAN ID is 192, and the physical interface is eth0, then the configuration filename should be ifcfg-eth0.192:
    DEVICE=ethX.192
    BOOTPROTO=static
    ONBOOT=yes
    IPADDR=192.168.1.1
    NETMASK=255.255.255.0
    USERCTL=no
    NETWORK=192.168.1.0
    VLAN=yes
    If there is a need to configure a second VLAN, with for example, VLAN ID 193, on the same interface, eth0 , add a new file with the name eth0.193 with the VLAN configuration details.
  5. Restart the networking service, in order for the changes to take effect by running as root:
     systemctl restart network.service 

7.2.5. Archivos alias y clon

Two lesser-used types of interface configuration files are alias and clone files. As the ip command of the iproute package now supports assigning multiple address to the same interface it is no longer necessary to use this method of binding multiple addresses to the same interface.

Note

At the time of writing, NetworkManager does not detect IP aliases in ifcfg files. For example, if ifcfg-eth0 and ifcfg-eth0:1 files are present, NetworkManager creates two connections, which will cause confusion.
For new installations, users should select the Manual method on the IPv4 or IPv6 tab in NetworkManager to assign multiple IP address to the same interface. For more information on using this tool, refer to Capítulo 6, NetworkManager.
Alias interface configuration files, which are used to bind multiple addresses to a single interface, use the ifcfg-if-name:alias-value naming scheme.
For example, an ifcfg-eth0:0 file could be configured to specify DEVICE=eth0:0 and a static IP address of 10.0.0.2, serving as an alias of an Ethernet interface already configured to receive its IP information via DHCP in ifcfg-eth0. Under this configuration, eth0 is bound to a dynamic IP address, but the same physical network card can receive requests via the fixed, 10.0.0.2 IP address.

Warning

Los alias de interfaces no soportan DHCP.
A clone interface configuration file should use the following naming convention: ifcfg-if-name-clone-name. While an alias file allows multiple addresses for an existing interface, a clone file is used to specify additional options for an interface. For example, a standard DHCP Ethernet interface called eth0, may look similar to this:
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
Since the default value for the USERCTL directive is no if it is not specified, users cannot bring this interface up and down. To give users the ability to control the interface, create a clone by copying ifcfg-eth0 to ifcfg-eth0-user and add the following line to ifcfg-eth0-user:
USERCTL=yes
This way a user can bring up the eth0 interface using the /sbin/ifup eth0-user command because the configuration options from ifcfg-eth0 and ifcfg-eth0-user are combined. While this is a very basic example, this method can be used with a variety of options and interfaces.
It is no longer possible to create alias and clone interface configuration files using a graphical tool. However, as explained at the beginning of this section, it is no longer necessary to use this method as it is now possible to directly assign multiple IP address to the same interface. For new installations, users should select the Manual method on the IPv4 or IPv6 tab in NetworkManager to assign multiple IP address to the same interface. For more information on using this tool, refer to Capítulo 6, NetworkManager.

7.2.6. Interfaces de acceso telefónico

Si se conecta a una red, como Internet, a través de la conexión de acceso telefónico, necesitará un archivo de configuración para la interfaz.
Los archivos de interfaz PPP son nombrados utilizando el siguiente formato:
ifcfg-pppX
donde X es un número único correspondiente a la interfaz específica.
El archivo de configuración de interfaz PPP es creado automáticamente cuando wvdial, Configuración de red o Kppp son usados para crear una cuenta de marcado. También es posible crearlo o editarlo manualmente.
El siguiente es un archivo ifcfg-ppp0 típico:
DEVICE=ppp0
NAME=test
WVDIALSECT=test
MODEMPORT=/dev/modem
LINESPEED=115200
PAPNAME=test
USERCTL=true
ONBOOT=no
PERSIST=no
DEFROUTE=yes
PEERDNS=yes
DEMAND=no
IDLETIMEOUT=600
Serial Line Internet Protocol (SLIP) is another dialup interface, although it is used less frequently. SLIP files have interface configuration file names such as ifcfg-sl0.
Otras opciones que se pueden utilizar en estos archivos incluyen:
DEFROUTE=answer
donde answer es una de las siguientes:
  • yes — Set this interface as the default route.
  • no — Do not set this interface as the default route.
DEMAND=answer
donde answer es una de las siguientes:
  • yes — This interface allows pppd to initiate a connection when someone attempts to use it.
  • no — A connection must be manually established for this interface.
IDLETIMEOUT=value
where value is the number of seconds of idle activity before the interface disconnects itself.
INITSTRING=string
where string is the initialization string passed to the modem device. This option is primarily used in conjunction with SLIP interfaces.
LINESPEED=value
where value is the baud rate of the device. Possible standard values include 57600, 38400, 19200, and 9600.
MODEMPORT=device
where device is the name of the serial device that is used to establish the connection for the interface.
MTU=value
where value is the Maximum Transfer Unit (MTU) setting for the interface. The MTU refers to the largest number of bytes of data a frame can carry, not counting its header information. In some dialup situations, setting this to a value of 576 results in fewer packets dropped and a slight improvement to the throughput for a connection.
NAME=name
where name is the reference to the title given to a collection of dialup connection configurations.
PAPNAME=name
where name is the username given during the Password Authentication Protocol (PAP) exchange that occurs to allow connections to a remote system.
PERSIST=answer
donde answer es una de las siguientes:
  • yes — This interface should be kept active at all times, even if deactivated after a modem hang up.
  • no — This interface should not be kept active at all times.
REMIP=address
where address is the IP address of the remote system. This is usually left unspecified.
WVDIALSECT=name
where name associates this interface with a dialer configuration in /etc/wvdial.conf. This file contains the phone number to be dialed and other important information for the interface.

7.2.7. Otras interfaces

Los siguientes son otros archivos de configuración de interfaces comunes:
ifcfg-lo
A menudo se usa una interfaz loopback para realizar pruebas y con una variedad de aplicaciones que requieren una dirección IP que apunte al mismo sistema. Todos los datos que se mandan al dispositivo loopback vuelven inmediatamente a la capa de red del host.

No editar manualmente el script ifcfg-lo

El script de interfaz loopback, /etc/sysconfig/network-scripts/ifcfg-lo, nunca debe ser editado manualmente. Hacerlo puede impedir el correcto funcionamiento del sistema.
ifcfg-irlan0
Una interfaz de infrarrojo permite que se transmita información a través de un enlace infrarrojo entre dispositivos, tal como un portátil y una impresora. Esto funciona de forma similar a un dispositivo Ethernet excepto que se da comúnmente en una conexión punto a punto.
ifcfg-plip0
A Parallel Line Interface Protocol (PLIP) connection works much the same way as an Ethernet device, except that it utilizes a parallel port.

7.3. Scripts de control de interfaz

The interface control scripts activate and deactivate system interfaces. There are two primary interface control scripts that call on control scripts located in the /etc/sysconfig/network-scripts/ directory: /sbin/ifdown and /sbin/ifup.
The ifup and ifdown interface scripts are symbolic links to scripts in the /sbin/ directory. When either of these scripts are called, they require the value of the interface to be specified, such as:
ifup eth0

Use los scripts de interfaz ifup e ifdown

The ifup and ifdown interface scripts are the only scripts that the user should use to bring up and take down network interfaces.
Los siguientes scripts son descritos como referencia únicamente.
Two files used to perform a variety of network initialization tasks during the process of bringing up a network interface are /etc/rc.d/init.d/functions and /etc/sysconfig/network-scripts/network-functions. Refer to Sección 7.5, “Archivos de funciones de red” for more information.
After verifying that an interface has been specified and that the user executing the request is allowed to control the interface, the correct script brings the interface up or down. The following are common interface control scripts found within the /etc/sysconfig/network-scripts/ directory:
ifup-aliases
Configura los alias IP desde los archivos de configuración de la interfaz cuando se asocia más de una dirección IP con una interfaz.
ifup-ippp e ifdown-ippp
Activa y desactiva una interfaz ISDN.
ifup-ipv6 e ifdown-ipv6
Se usa para activar y desactivar una interfaz IPv6.
ifup-plip
Activa y desactiva una interfaz PLIP.
ifup-plusb
Activa y desactiva una interfaz USB para conexiones de red.
ifup-post e ifdown-post
Contiene comandos que son ejecutados después de que una interfaz ha sido activada o desactivada.
ifup-ppp e ifdown-ppp
Activa o desactiva una interfaz PPP.
ifup-routes
Añade rutas estáticas para un dispositivo como si se activase su interfaz.
ifdown-sit e ifup-sit
Contiene llamadas de funciones relacionadas con la activación y desactivación de un túnel IPv6 dentro de una conexión IPv4.
ifup-wireless
Activa una interfaz inalámbrica.

¡Sea cuidadoso cuando elimine o modifique scripts de red!

Removing or modifying any scripts in the /etc/sysconfig/network-scripts/ directory can cause interface connections to act irregularly or fail. Only advanced users should modify scripts related to a network interface.
The easiest way to manipulate all network scripts simultaneously is to use the systemctl command on the network service (/etc/rc.d/init.d/network), as illustrated by the following command:
systemctl action network.service
Here, action can be either start, stop, or restart.
Para ver una lista de los dispositivos configurados y las interfaces de red actualmente activas, utilice el comando:
 systemctl status network.service

Nota

The older SysV service commands, such as service network status are considered deprecated but will still work. The SysV services can define their status in an arbitrary fashion so the output of the status command is not considered predictable over time. The SysV commands are retained for compatibility purposes. The /sbin/service utility will call systemctl when necessary.

7.4. Configurando rutas estáticas

Static routes are for traffic that must not, or should not, go through the default route. Use the route command to display the IP routing table. If static routes are required, they can be specified by means of the GATEWAY directive, either globally or in interface-specific configuration files. There is also the GATEWAYDEV directive, which is a global option. If multiple devices specify GATEWAY, and one interface is specified using the GATEWAYDEV directive, that directive will take precedence. This option is not recommend. Specifying an exit interface is optional. It can be useful if you want to force traffic out of a specific interface. For example, in the case of a VPN, you can force traffic to a remote network to pass through a tun0 interface even when the interface is in a different sub-net to the destination network.
Global static route configuration is stored in the /etc/sysconfig/network file. This file specifies routing and host information for all network interfaces. For more information about this file and the directives it accepts, refer to Sección D.1.13, “ /etc/sysconfig/network ”.
Per-interface static route configuration is stored in a /etc/sysconfig/network-scripts/route-interface file. For example, static routes for the eth0 interface would be stored in the /etc/sysconfig/network-scripts/route-eth0 file. The route-interface file has two formats: IP command arguments and network/netmask directives.

IP Command Arguments Format

Defina una puerta de enlace predeterminada en la primera línea. Ésto es requerido sólo si la puerta de enlace predeterminada no es ajustada vía DHCP:
default via X.X.X.X dev interface
X.X.X.X is the IP address of the default gateway. The interface is the interface that is connected to, or can reach, the default gateway. The dev option can be omitted.
Defina una ruta estática. Cada línea es analizada como una ruta individual:
X.X.X.X/X via X.X.X.X dev interface
X.X.X.X/X is the network number and netmask for the static route. X.X.X.X and interface are the IP address and interface for the default gateway respectively. The X.X.X.X address does not have to be the default gateway IP address. In most cases, X.X.X.X will be an IP address in a different subnet, and interface will be the interface that is connected to, or can reach, that subnet. Add as many static routes as required.
The following is a sample route-eth0 file using the IP command arguments format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks:
default via 192.168.0.1 dev eth0
10.10.10.0/24 via 192.168.0.1 dev eth0
172.16.1.0/24 via 192.168.0.1 dev eth0
Static routes should only be configured for other subnets. The above example is not necessary, since packets going to the 10.10.10.0/24 and 172.16.1.0/24 networks will use the default gateway anyway. Below is an example of setting static routes to a different subnet, on a machine in a 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:
10.10.10.0/24 via 10.10.10.1 dev eth1

Duplicar puerta de enlace predeterminada

If the default gateway is already assigned from DHCP, the IP command arguments format can cause one of two errors during start-up, or when bringing up an interface from the down state using the ifup command: "RTNETLINK answers: File exists" or 'Error: either "to" is a duplicate, or "X.X.X.X" is a garbage.', where X.X.X.X is the gateway, or a different IP address. These errors can also occur if you have another route to another network using the default gateway. Both of these errors are safe to ignore.

Network/Netmask Directives Format

You can also use the network/netmask directives format for route-interface files. The following is a template for the network/netmask format, with instructions following afterwards:
 ADDRESS0=X.X.X.X NETMASK0=X.X.X.X GATEWAY0=X.X.X.X 
  • ADDRESS0=X.X.X.X is the network number for the static route.
  • NETMASK0=X.X.X.X is the netmask for the network number defined with ADDRESS0=X.X.X.X.
  • GATEWAY0=X.X.X.X is the default gateway, or an IP address that can be used to reach ADDRESS0=X.X.X.X
The following is a sample route-eth0 file using the network/netmask directives format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks. However, as mentioned before, this example is not necessary as the 10.10.10.0/24 and 172.16.1.0/24 networks would use the default gateway anyway:
ADDRESS0=10.10.10.0
NETMASK0=255.255.255.0
GATEWAY0=192.168.0.1
ADDRESS1=172.16.1.0
NETMASK1=255.255.255.0
GATEWAY1=192.168.0.1
Subsequent static routes must be numbered sequentially, and must not skip any values. For example, ADDRESS0, ADDRESS1, ADDRESS2, and so on.
Below is an example of setting static routes to a different subnet, on a machine in the 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:
ADDRESS0=10.10.10.0
NETMASK0=255.255.255.0
GATEWAY0=10.10.10.1
Note that if DHCP is used, it can assign these settings automatically.

7.5. Archivos de funciones de red

Fedora makes use of several files that contain important common functions used to bring interfaces up and down. Rather than forcing each interface control file to contain these functions, they are grouped together in a few files that are called upon when necessary.
The /etc/sysconfig/network-scripts/network-functions file contains the most commonly used IPv4 functions, which are useful to many interface control scripts. These functions include contacting running programs that have requested information about changes in the status of an interface, setting hostnames, finding a gateway device, verifying whether or not a particular device is down, and adding a default route.
As the functions required for IPv6 interfaces are different from IPv4 interfaces, a /etc/sysconfig/network-scripts/network-functions-ipv6 file exists specifically to hold this information. The functions in this file configure and delete static IPv6 routes, create and remove tunnels, add and remove IPv6 addresses to an interface, and test for the existence of an IPv6 address on an interface.

7.6. Recursos adicionales

Los siguientes son recursos que explican más detalladamente las interfaces de red.

7.6.1. Documentación instalada

/usr/share/doc/initscripts-version/sysconfig.txt
Un manual que estudia las opciones disponibles para los archivos de configuración de red, incluidas las opciones IPv6 que no son cubiertas en este capítulo.
/usr/share/doc/iproute-version/ip-cref.ps
This file contains a wealth of information about the ip command, which can be used to manipulate routing tables, among other things. Use the ggv or kghostview application to view this file.

Parte IV. Servicios de infraestructura

Este apartado proporciona información sobre cómo configurar servicios y demonios, configurar la autenticación y habilitar el inicio de sesión remoto

Capítulo 8. Services and Daemons

Maintaining security on your system is extremely important, and one approach for this task is to manage access to system services carefully. Your system may need to provide open access to particular services (for example, httpd if you are running a web server). However, if you do not need to provide a service, you should turn it off to minimize your exposure to possible bug exploits.
This chapter covers the configuration of the services to be run when a system is started, and provides information on how to start, stop, and restart the services on the command line using the systemctl utility.

Keep the system secure

When you allow access for new services, always remember that both the firewall and SELinux need to be configured as well. One of the most common mistakes committed when configuring a new service is neglecting to implement the necessary firewall configuration and SELinux policies to allow access for it. For more information, refer to the Fedora 17 Security Guide.

8.1. Configuring Services

To allow you to configure which services are started at boot time, Fedora is shipped with the systemctl command line tool.

Do not use the ntsysv and chkconfig utilities

Although it is still possible to use the ntsysv and chkconfig utilities to manage services that have init scripts installed in the /etc/rc.d/init.d/ directory, it is advised that you use the systemctl utility.

Enabling the irqbalance service

To ensure optimal performance on POWER architecture, it is recommended that the irqbalance service is enabled. In most cases, this service is installed and configured to run during the Fedora 17 installation. To verify that irqbalance is running, type the following at a shell prompt:
systemctl status irqbalance.service

8.1.1. Enabling the Service

To configure a service to be automatically started at boot time, use the systemctl command in the following form:
systemctl enable service_name.service
The service will be started the next time you boot the system. For information on how to start the service immediately, refer to Sección 8.2.2, “Running the Service”.
Ejemplo 8.1. Enabling the httpd service
Imagine you want to run the Apache HTTP Server on your system. Provided that you have the httpd package installed, you can enable the httpd service by typing the following at a shell prompt as root:
~]# systemctl enable httpd.service

8.1.2. Disabling the Service

To disable starting a service at boot time, use the systemctl command in the following form:
systemctl disable service_name.service
The next time you boot the system, the service will not be started. For information on how to stop the service immediately, refer to Sección 8.2.3, “Stopping the Service”.
Ejemplo 8.2. Disabling the telnet service
In order to secure the system, users are advised to disable insecure connection protocols such as Telnet. You can make sure that the telnet service is disabled by running the following command as root:
~]# systemctl disable telnet.service

8.2. Running Services

The systemctl utility also allows you to determine the status of a particular service, as well as to start, stop, or restart a service.

Do not use the service utility

Although it is still possible to use the service utility to manage services that have init scripts installed in the /etc/rc.d/init.d/ directory, it is advised that you use the systemctl utility.

8.2.1. Checking the Service Status

To determine the status of a particular service, use the systemctl command in the following form:
systemctl status service_name.service
This command provides detailed information on the service's status. However, if you merely need to verify that a service is running, you can use the systemctl command in the following form instead:
systemctl is-active service_name.service
Ejemplo 8.3. Checking the status of the httpd service
Ejemplo 8.1, “Enabling the httpd service” illustrated how to enable starting the httpd service at boot time. Imagine that the system has been restarted and you need to verify that the service is really running. You can do so by typing the following at a shell prompt:
~]$ systemctl is-active httpd.service
active
You can also display detailed information about the service by running the following command:
~]$ systemctl status httpd.service
httpd.service - LSB: start and stop Apache HTTP Server
          Loaded: loaded (/etc/rc.d/init.d/httpd)
          Active: active (running) since Mon, 23 May 2011 21:38:57 +0200; 27s ago
         Process: 2997 ExecStart=/etc/rc.d/init.d/httpd start (code=exited, status=0/SUCCESS)
        Main PID: 3002 (httpd)
          CGroup: name=systemd:/system/httpd.service
                  ├ 3002 /usr/sbin/httpd
                  ├ 3004 /usr/sbin/httpd
                  ├ 3005 /usr/sbin/httpd
                  ├ 3006 /usr/sbin/httpd
                  ├ 3007 /usr/sbin/httpd
                  ├ 3008 /usr/sbin/httpd
                  ├ 3009 /usr/sbin/httpd
                  ├ 3010 /usr/sbin/httpd
                  └ 3011 /usr/sbin/httpd

To display a list of all active system services, use the following command:
systemctl list-units --type=service
This command provides a tabular output with each line consisting of the following columns:
  • UNIT — A systemd unit name. In this case, a service name.
  • LOAD — Information whether the systemd unit was properly loaded.
  • ACTIVE — A high-level unit activation state.
  • SUB — A low-level unit activation state.
  • JOB — A pending job for the unit.
  • DESCRIPTION — A brief description of the unit.
Ejemplo 8.4. Listing all active services
You can list all active services by using the following command:
~]$ systemctl list-units --type=service
UNIT                      LOAD   ACTIVE SUB     JOB DESCRIPTION
abrt-ccpp.service         loaded active exited      LSB: Installs coredump handler which saves segfault data
abrt-oops.service         loaded active running     LSB: Watches system log for oops messages, creates ABRT dump directories for each oops
abrtd.service             loaded active running     ABRT Automated Bug Reporting Tool
accounts-daemon.service   loaded active running     Accounts Service
atd.service               loaded active running     Job spooling tools
[output truncated]
In the example above, the abrtd service is loaded, active, and running, and it does not have any pending jobs.

8.2.2. Running the Service

To run a service, use the systemctl command in the following form:
systemctl start service_name.service
This will start the service in the current session. To configure the service to be started at boot time, refer to Sección 8.1.1, “Enabling the Service”.
Ejemplo 8.5. Running the httpd service
Ejemplo 8.1, “Enabling the httpd service” illustrated how to run the httpd service at boot time. You can start the service immediately by typing the following at a shell prompt as root:
~]# systemctl start httpd.service

8.2.3. Stopping the Service

To stop a service, use the systemctl command in the following form:
systemctl stop service_name.service
This will stop the service in the current session. To disable starting the service at boot time, refer to Sección 8.1.1, “Enabling the Service”.
Ejemplo 8.6. Stopping the telnet service
Ejemplo 8.2, “Disabling the telnet service” illustrated how to disable starting the telnet service at boot time. You can stop the service immediately by running the following command as root:
~]# systemctl stop telnet.service

8.2.4. Restarting the Service

To restart a service, use the systemctl command in the following form:
systemctl restart service_name.service
Ejemplo 8.7. Restarting the sshd service
For any changes in the /etc/ssh/sshd_config configuration file to take effect, it is required that you restart the sshd service. You can do so by typing the following at a shell prompt as root:
~]# systemctl restart httpd.service

8.3. Recursos adicionales

8.3.1. Documentación instalada

  • systemctl(1) — The manual page for the systemctl utility.

8.3.2. Libros relacionados

Fedora 17 Security Guide
A guide to securing Fedora. It contains valuable information on how to set up the firewall, as well as the configuration of SELinux.

Capítulo 9. Configuring Authentication

9.1. La herramienta de configuración de autenticación

When a user logs in to a Fedora system, the username and password combination must be verified, or authenticated, as a valid and active user. Sometimes the information to verify the user is located on the local system, and other times the system defers the authentication to a user database on a remote system.
The Authentication Configuration Tool provides a graphical interface for configuring user information retrieval from Lightweight Directory Access Protocol (LDAP), Network Information Service (NIS), and Winbind user account databases. This tool also allows you to configure Kerberos to be used as the authentication protocol when using LDAP or NIS.

Using a high or medium security level

If you configured a medium or high security level during installation (or with the Security Level Configuration Tool), then the firewall will prevent NIS authentication. For more information about firewalls, refer to the "Firewalls" section of the Fedora 17 Security Guide.
To start the graphical version of the Authentication Configuration tool from the desktop, select ApplicationsOtherAuthentication form the Activities menu or type the command system-config-authentication at a shell prompt (for example, in an XTerm or a GNOME terminal).

Your changes are immediately applied

After exiting the authentication program, any changes you made take effect immediately.

9.1.1. Identidad y autenticación

The Identity & Authentication tab allows you to configure how users should be authenticated, and has several options for each method of authentication. To select which user account database should be used, select an option from the drop-down list.
Identity & Authentication; changing the option in the User Account Database drop-down list changes the contents of the tab
Figura 9.1. Identity & Authentication; changing the option in the User Account Database drop-down list changes the contents of the tab

La lista siguiente explica lo que configura cada una de las opciones:

LDAP

The LDAP option instructs the system to retrieve user information via LDAP. It contains the following specifications:
  • LDAP Search Base DN — Specifies that user information should be retrieved using the listed Distinguished Name (DN).
  • LDAP Server — Specifies the address of the LDAP server.
  • Use TLS to encrypt connections — When enabled, Transport Layer Security (TLC) will be used to encrypt passwords sent to the LDAP server. The Download CA Certificate option allows you to specify a URL from which to download a valid Certificate Authority certificate (CA). A valid CA certificate must be in the Privacy Enhanced Mail (PEM) format.

    Using ldaps:// in the LDAP Server field

    The Use TLS to encrypt connections option must not be ticked if an ldaps:// server address is specified in the LDAP Server field.
    For more information about CA Certificates, refer to Sección 13.1.8.1, “An Overview of Certificates and Security”.
The openldap-clients package must be installed for this option to work.
For more information about LDAP, refer to Sección 15.1, “OpenLDAP”.
LDAP provides the following methods of authentication:
  • Kerberos password — This option enables Kerberos authentication. It contains the following specifications:
    • Realm — Configures the realm for the Kerberos server. The realm is the network that uses Kerberos, composed of one or more KDCs and a potentially large number of clients.
    • KDCs — Defines the Key Distribution Centers (KDC), which are servers that issue Kerberos tickets.
    • Admin Servers — Specifies the administration server(s) running kadmind.
    The Kerberos Settings dialog also allows you to use DNS to resolve hosts to realms and locate KDCs for realms.
    The krb5-libs and krb5-workstation packages must be installed for this option to work. For more information about Kerberos, refer to section Using Kerberos of the Fedora 17 Managing Single Sign-On and Smart Cards guide.
  • LDAP password — This option instructs standard PAM-enabled applications to use LDAP authentication with options specified in the User Account Configuration of LDAP. When using this option, you must provide an ldaps:// server address or use TLS for LDAP authentication.

Setting up the SSSD service

The SSSD service is used as a client for LDAP and Kerberos servers. Thus, offline login is enabled and supported by default. No user interaction is needed to set up the SSSD service with the Authentication Configuration Tool. For more information about the SSSD service, refer to Sección 9.2, “El Daemon de Servicios de Seguridad del Sistema (SSSD)”

NIS

The NIS option configures the system to connect to a NIS server (as an NIS client) for user and password authentication. To configure this option, specify the NIS domain and NIS server. If the NIS server is not specified, the daemon attempts to find it via broadcast.
The ypbind package must be installed for this option to work. If the NIS user account database is used, the portmap and ypbind services are started and are also enabled to start at boot time.
For more information about NIS, refer to section "Securing NIS" of the Fedora 17 Security Guide.
NIS provides the following methods of authentication:
  • Kerberos password — This option enables Kerberos authentication. For more information about configuration of the Kerberos authentication method, refer to the previous section on LDAP.
  • NIS password — This option enables NIS authentication. NIS can provide authentication information to outside processes to authenticate users.

Winbind

The Winbind option configures the system to connect to a Windows Active Directory or a Windows domain controller. User information from the specified directory or domain controller can then be accessed, and server authentication options can be configured. It contains the following specifications:
  • Winbind Domain — Specifies the Windows Active Directory or domain controller to connect to.
  • Security Model — Allows you to select a security model, which configures the Samba client mode of operation. The drop-down list allows you to select any of the following:
    • ads — This mode instructs Samba to act as a domain member in an Active Directory Server (ADS) realm. To operate in this mode, the krb5-server package must be installed, and Kerberos must be configured properly.
    • domain — In this mode, Samba will attempt to validate the username/password by authenticating it through a Windows NT Primary or Backup Domain Controller, similar to how a Windows NT Server would.
    • server — In this mode, Samba will attempt to validate the username/password by authenticating it through another SMB server (for example, a Windows NT Server). If the attempt fails, the user mode will take effect instead.
    • user — This is the default mode. With this level of security, a client must first log in with a valid username and password. Encrypted passwords can also be used in this security mode.
  • Winbind ADS Realm — When the ads Security Model is selected, this allows you to specify the ADS Realm the Samba server should act as a domain member of.
  • Winbind Domain Controllers — Use this option to specify which domain controller winbind should use. For more information about domain controllers, please refer to Sección 16.1.6.3, “Domain Controller”.
  • Template Shell — When filling out the user information for a Windows NT user, the winbindd daemon uses the value chosen here to specify the login shell for that user.
  • Allow offline login — By checking this option, you allow authentication information to be stored in a local cache (provided by SSSD). This information is then used when a user attempts to authenticate while offline.
For more information about the winbindd service, refer to Sección 16.1.2, “Demonios Samba y Servicios relacionados”.
Winbind provides only one method of authentication, Winbind password. This method of authentication uses the options specified in the User Account Configuration of Winbind to connect to a Windows Active Directory or a Windows domain controller.

9.1.2. Opciones avanzadas

This tab allows you to configure advanced options, as listed below.
Opciones avanzadas
Figura 9.2. Opciones avanzadas

Opciones de autenticación local

  • Enable fingerprint reader support — By checking this option, you enable fingerprint authentication to log in by scanning your finger with the fingerprint reader.
  • Enable local access control — When enabled, /etc/security/access.conf is consulted for authorization of a user.
  • Password Hashing Algorithm — This option lets you specify which hashing or cryptographic algorithm should be used to encrypt locally stored passwords.

Otras opciones de autenticación

Create home directories on the first login — When enabled, the user's home directory is automatically created when they log in if it does not already exist.

Smart Card Authentication Options

Enable smart card support — This option enables smart card authentication. Smart card authentication allows you to log in using a certificate and a key associated with a smart card.
When the Enable smart card support option is checked, the following options can be specified:
  • Card Removal Action — This option defines what action the system performs when the card is removed from the card reader during an active session. Two alternatives are available:
    • Ignore — The card removal is ignored and the system continues to function as normal.
    • Lock — The current session is immediately locked.
  • Require smart card login — Requires the user to login and authenticate with a smart card. It essentially disables any other type of password authentication. This option should not be selected until after you have successfully logged in using a smart card.
The pam_pkcs11 and the coolkey packages must be installed for this option to work. For more information about smart cards, refer to the Red Hat Enterprise Linux 6 Managing Single Sign-On and Smart Cards Guide.

Click Revert to restore the previous configuration

You can restore all of the options specified in the Authentication Configuration Tool to the previous configuration setup by clicking Revert.

9.1.3. Versión de línea de comandos

The Authentication Configuration tool also supports a command line interface. The command line version can be used in a configuration script or a kickstart script. The authentication options are summarized in Tabla 9.1, “Command line options”.

Getting the list of supported authentication options

These options can also be found in the authconfig man page or by typing authconfig --help at the shell prompt.
Tabla 9.1. Command line options
Opciones Descripción
--enableshadow, --useshadow Habilitar contraseñas shadow
--disableshadow Desactivar contraseñas shadow
--passalgo=descrypt|bigcrypt|md5|sha256|sha512 Hash/crypt algorithm to be used
--enablenis Enable NIS for user account configuration
--disablenis Disable NIS for user account configuration
--nisdomain=domain Especificar un dominio NIS
--nisserver=server Especificar un servidor NIS
--enableldap Habilitar LDAP para configuración de cuentas de usuario
--disableldap Deshabilitar LDAP para configuración de cuentas de usuario
--enableldaptls Habilitar el uso de TLS con LDAP
--disableldaptls Inhabilitar el uso de TLS con LDAP
--enablerfc2307bis Enable use of RFC-2307bis schema for LDAP user information lookups
--disablerfc2307bis Disable use of RFC-2307bis schema for LDAP user information lookups
--enableldapauth Habilitar LDAP para la autenticación
--disableldapauth Inhabilitar LDAP para la autenticación
--ldapserver=server Especificar un servidor LDAP
--ldapbasedn=dn Specify an LDAP base DN (Distinguished Name)
--ldaploadcacert=URL Load a CA certificate from the specified URL
--enablekrb5 Habilitar Kerberos para autenticación
--disablekrb5 Deshabilitar Kerberos para autenticación
--krb5kdc=server Especificar un servidor Kerberos KDC
--krb5adminserver=server Especifica un servidor de administración Kerberos
--krb5realm=realm Especifica el entorno Kerberos
--enablekrb5kdcdns Habilitar el uso de DNS para encontrar Kerberos KDCs
--disablekrb5kdcdns Deshabilitar el uso de DNS para encontrar Kerberos KDCs
--enablekrb5realmdns Habilitar el uso de DNS para encontrar Kerberos realms
--disablekrb5realmdns Deshabilitar el uso de DNS para encontrar Kerberos realms
--enablewinbind Habilitar winbind para configuración de cuentas de usuario
--disablewinbind Deshabilitar winbind para configuración de cuentas de usuario
--enablewinbindauth Habilitar winbindauth para autenticación
--disablewinbindauth Deshabilitar winbindauth para autenticación
--winbindseparator=\ Character used to separate the domain and user part of winbind usernames if winbindusedefaultdomain is not enabled
--winbindtemplatehomedir=/home/%D/%U Directorio de inicio de los usuarios winbind
--winbindtemplateprimarygroup=nobody Grupo primario de los usuarios winbind
--winbindtemplateshell=/bin/false Shell por defecto de los usuarios winbind
--enablewinbindusedefaultdomain Configurar winbind para asumir que los usuarios sin dominio en sus nombres de usuarios son usuarios con dominio
--disablewinbindusedefaultdomain Configurar winbind para asumir que los usuarios sin dominio en sus nombres de usuarios son usuarios sin dominio
--winbindjoin=Administrator Joins the winbind domain or ADS realm as the specified administrator
--enablewinbindoffline Configures winbind to allow offline login
--disablewinbindoffline Configures winbind to prevent offline login
--smbsecurity=user|server|domain|ads Security mode to use for the Samba and Winbind services
--smbrealm=realm Default realm for Samba and Winbind services when security is set to ads
--enablewins Enable Wins for hostname resolution
--disablewins Disable Wins for hostname resolution
--enablesssd Enable SSSD for user information
--disablesssd Disable SSSD for user information
--enablecache Habilitar nscd
--disablecache Deshabilitar nscd
--enablelocauthorize Local authorization is sufficient for local users
--disablelocauthorize Local users are also authorized through a remote service
--enablesysnetauth Authenticate system accounts with network services
--disablesysnetauth Authenticate system accounts with local files only
--enablepamaccess Check /etc/security/access.conf during account authorization
--disablepamaccess Do not check /etc/security/access.conf during account authorization
--enablemkhomedir Create a home directory for a user on the first login
--disablemkhomedir Do not create a home directory for a user on the first login
--enablesmartcard Enable authentication with a smart card
--disablesmartcard Disable authentication with a smart card
--enablerequiresmartcard Require smart card for authentication
--disablerequiresmartcard Do not require smart card for authentication
--smartcardmodule=module Default smart card module to use
--smartcardaction=0=Lock|1=Ignore Action to be taken when smart card removal is detected
--enablefingerprint Enable fingerprint authentication
--disablefingerprint Disable fingerprint authentication
--nostart Do not start or stop the portmap, ypbind, or nscd services even if they are configured
--test Do not update the configuration files, only print the new settings
--update, --kickstart Opposite of --test, update configuration files with changed settings
--updateall Update all configuration files
--probe Verificar y muestrar las fallas de red
--savebackup=name Save a backup of all configuration files
--restorebackup=name Restore a backup of all configuration files
--restorelastbackup Restore the backup of configuration files saved before the previous configuration change

9.2. El Daemon de Servicios de Seguridad del Sistema (SSSD)

Esta sección provee una introducción al Daemon* de Servicios de Seguridad del Sistema (SSSD) (Daemon es una aplicación que corre en segundo plano)
Esta sección también describe como configurar SSSD, para utilizar las características que provee. Proporciona información en los tipos de servicios que soporta y como configurarlos, así mismo introduce y describe las opciones de configuración más importantes. También se proporcionan muestras de archivos de configuración para ayudarlo a optimizar la instalación de su sistema.

9.2.1. ¿Qué es SSSD?

El Daemon de los Servicios de Seguridad del Sistema (SSSD) es un servicio que proporciona acceso a proveedores distintos de identidad e identificación. Usted puede econfigurar SSSD para que utilice un dominio LDAP (esto es, un proveedor nativo de indentidad LDAP con identificación LDAP), o bien un proveedor de identidad LDAP con identificación kerberos. Proporciona al sistema interfases NSS y PAM asi como un sistema conectable de back-end para conectar fuentes de cuentas distintas.
SSSD es también extensible; usted puede configurarla para que utilice nuevas fuentes de mecanismos de identidad e identificación si estos estuvieran disponibles. Además, SSSD es completamente compatible con IPV6, simepre y cuando sea contruido utilizando c-ares 1.7.1 o superior y krb5-libs 1.8.1 o superior.

9.2.2. Características de SSSD

9.2.2.1. Identificación sin conexión

Uno de los primeros beneficios de SSSD es la identificación sin conexión. Esto resuelve el caso de usuarios que tienen una cuenta corporativa por separado y una cuenta de maquina local debido al requerimiento común de implementar una Red Virtual Privada (VPN).
SSSD puede guardar identidades remotas y credenciales de identificación. Esto quiere decir que usted puede aún identificarse con esas identidades remotas aún cuando una máquina esté sin conexión. En un sistema SSSD, usted solo necesita manejar una cuenta.

9.2.2.2. Reducción de la Carga del Servidor

El uso de SSSD ayuda también a reducir la carga en los servidores de identificación. Por ejemplo, utilizando nss_ldap, cada aplicación cliente que necesita solicitar información abre su propia conexión en el servidor LDAP. El manejo de esas conexiones múltiples puede llevar a un pesada carga en el servidor LDAP. En un sistema SSSD, solo el Proveedor de Datos SSSD se comunica realmente con el servidor LDAP, reduciendo la carga del sistema a una conexión por cliente.

9.2.2.3. Soporte para Dominios Múltiples

Usted puede utilizar SSSD para especificar dominios múltiples del mismo tipo. Compare esto a un archivo de configuración nsswitch.conf, con el cual usted puede pedir solo información de un solo servidor de cualquier tipo (LDAP, NIS, etc.). Con SSSD, usted puede crear dominios múltiples de proveedores de identidad del mismo o diferente tipo.
Comenzando con la version 0.6.0, SSSD mantiene un archivo de base de datos separado por cada dominio. Esto quiere decir que cada dominio tiene su propio archivo de memoria temporal, y en el la eventualidad que ocurra un problema y sea necesario el mantenimiento, es muy fácil borrar el archivo de memoria temporal de un solo dominio, deteniendo sssd y borrando el archivo de memoria temporal correspondiente.
Todos los archivos de memoria temporal (caché) se nombran de acuerdo al dominio que ellos representan, por ejemplo cache_DOMAINNAME.ldb.
Consideraciones Asociadas al Borrado de los Archivos de Memoria Temporal (caché)
Borrar el archivo de memoria temporal de un dominio puede producir algunos efectos secundarios. Usted debe tener precaución de lo siguiente antes de proceder:
  • El borrado del archivo de memoria temporal (caché) borra también todos los datos del usuario (tanto la identificación como las credenciales que se encuentran en ese archivo). Es por eso que usted no debe proceder a menos que usted este conectado y pueda identificarse con su nombre de usuario en esos servidores de dominio, ya que la identificación fuera de conexión fallará.
  • Si usted está conectado y cambia su configuración para que haga referencia a un proveedor de identidad diferente, SSSD reconocerá a los usuarios de ambos proveedores hasta que la información que se encuentra en la memoria temporal (caché) del proveedor original llegue a su termino.
    Para evitar esta situación, usted puede sea borrar el caché o utilizar un nombre de dominio diferente para el nuevo proveedor (esto es lo que se recomienda hacer), El cambiar el nombre de dominio quiere decir que cuando usted reinicia SSSD creara un nuevo archivo caché (con el nuevo nombre) y el viejo archivo caché será ignorado.

9.2.2.4. Soporte para remisiones LDAP

SSSD soporta dos tipos de remisiones: remisiones object-level (a nivel de objeto) y remisiones subtree (bajo el arbol). Esos tipos de remisión y la extensión de soporte de SSSD se describen en seguida.
9.2.2.4.1. Remisiones de nivel objeto (object-level)
SSSD provee soporte completo para las remisiones de nivel objeto dentro del mismo servidor LDAP, manejando correctamente cualquier diferencia en el nombre distinguido (DN) que pueda existir como parte de la configuración de remisión del servidor LDAP.
SSSD provee soporte parcial para las remisiones object-level entre los diferentes servidores LDAP, y requiere que los pedidos completos DN y LDAP sean idénticos en cada servidor. SSSD no soporta remisiones a caminos diferentes DN en otros servidores.
9.2.2.4.2. Remisiones bajo árbol (subtree)
SSSD provee un nivel similar de soporte para remisiones bajo árbol (subtree) como lo hace para las remisiones nivel objeto (object-level). Esto es, soporta remisiones a un DN cambiado en el sistema local o a un DN idéntico en un sistema remoto. Sin embargo La diferencia con las remisiones bajo árbol (subtree), es la abilidad de configurar bajo árbol (subtrees) idénticos en cada servidor LDAP y para entonces configurar las remisiones entre esos bajo árboles (subtrees).
9.2.2.4.3. Activación de remisiones LDAP
Para tomar ventajas de las las funcionalidades de remisión SSSD LDAP, usted necesita configurar la opción ldap_referrals a TRUE en la sección de configuración de dominio LDAP del archivo /etc/sssd/sssd.conf. Esto activara ella acceso anónimo a el segundo servidor LDAP.

Asegurese que SSSD esta compilada con la version OpenLDAP 2.4.13 o superior

SSSD solo soporta remisiones LDAP cuando esta compilada con OpenLDAP 2.4.13 o superior.

9.2.2.5. Diferenciando usuarios con nombres similares (like-named)

SSSD soporta la diferenciación de usuarios (like-named) en diferentes dominios. Por ejemplo, usted puede diferenciar el usuario kate en el dominio ldap.example.com del usuario kate en el dominio ldap.myhome.com. Usted puede utilizar SSSD para hacer solicitudes utilizando nombres de usuario completamente calificados. Si usted solicita información de cualquier para el usuario kate, recibirá la información a partir de cualquier dominio que este de primero en la lista de búsqueda. Sin embargo si usted solicita información para kate@ldap.myhome.com, recibirá la información correcta de ese usuario.
SSSD también provee una opción filter_users, en la cual usted puede excluir ciertos usuarios para que no sean buscados en la base de datos. Para detalles completos acerca de esta opción refiérase al manual sssd.conf(5)

9.2.2.6. Integración con IPA

Mas allá de la identificación fuera de conexión, el manejo múltiple de dominios y otras características que ya se describieron, SSSD esta también designado para integrarse y mejorar la funcionalidad de los clientes IPA instalados, SSSD provee funcionalidades adicionales, incluyendo soporte para actualizaciones dinámicas DNS, control de accesos basados en servidor, y migración de contraseñas a partir de un ambiente que sea solo LDAP dentro del ambiente LDAP/Kerberos 5 ambiente empleado por IPA.
9.2.2.6.1. Soporte para Actualizaciones Dinamicas DNS
Debido a que las direcciones IP de los clientes IPA puede cambiar, SSSD provee la abilidad de actualizar dinamicamente una entrada del cliente DNS en el servidor IPA, Utilizando una combinacin de Kerberos y GSS-TSIG (Servicion de Algoritmo Generico para llave secreta de Transaccion), IPA puede determinar la identidad de la maquina servidor, identificarla, y permite a esa maquina de editar su propio registro DNS. Esos cambios se almacenan entonces en el LDAP back end.

Cada cliente IPA solo puede editar su propio registro DNS

Utilizar este sistema de identificación quiere decir que cada cliente IPA puede editar su propio registro DNA; no puede editar el registro DNS de ningún otro cliente.
Configurando Actualizaciones Dinámicas DNS
El archivo de configuración DNS provee dos opciones que se utilizan para configurar las actualizaciones dinámicas DNS: ipa_dyndns_update, utilizada para activar las actualizaciones dinamicas DNS; y ipa_dyndns_iface, que especifica la interfaz cuya direccion IP debe ser utilizada para las actualizaciones dinámicas DNS,
Para mas información acerca de estas opciones, y como configurar las actualizaciones dinámicas DNS, refiérase a la pagina sssd-ipa

Soporte para actualizaciones dinámicas DNS

El soporte para actualizaciones dinámicas DNS sol esta disponibles en la versión 2 o superior de IPA, y con el DNS configurado correctamente.

9.2.3. Configurando SSSD

Esta sección describe como instalar SSSD, como correr el servicio, y como configurarlo para cada tipo de proveedor de información soportado.

9.2.3.1. Instalando de SSSD

Corra el siguiente comando para instalar SSSD y sus dependencias, incluyendo el cliente SSSD:
# yum install sssd
SSSD requiere muy pocas dependencias y debería instalarse mu rapidamente, dependiendo de la velocidad de su conexión de red
9.2.3.1.1. Actualizando de una Versión anterior
Actualizando con paquetes RPM
Si usted hace la actualización utilizando paquetes RPM, el script se ejecutara automáticamente cuando usted actualice a la nueva versión. Esto actualizara el archivo /etc/sssd/sssd.conf al nuevo formato, y copia la versión existente a /etc/sssd/sssd.conf.bak.
Actualizando Manualmente
Puede ser necesario ejecutar el script de actualización manualmente, ya sea porque usted creo el SSSD a partir de los archivos fuente, o bien porque usted esta utilizando una plataforma que no soporta el uso de paquetes RPM. La sinopsis para el script es como sigue

upgrade_config.py [ -f INFILE ] [ -o OUTFILE ] [ -verbose ] [ --no-backup ]

  • -f INFILE — es el archivo de confguracion a ser actualizado. Si no es especificado, se predefine como /etc/sssd/sssd.conf
  • -o OUTFILE — el nombre del archivo de configuración actualizado. Si no es especificado, se predefine como /etc/sssd/sssd.conf
  • -verbose — produce mas salidas de información durante el proceso de actualización
  • --no-backup — no produce un archivo de respaldo. Si no se especifica se predefine como INFILE.bak
9.2.3.1.2. Iniciando y Deteniendo SSSD

Iniciando SSSD por primera vez

Antes que usted inicie SSSD por la primera vez, puede necesitar configurar al menos un dominio. Para información de como configurar un dominio SSSD referase a Sección 9.2.5, “Configuring Domains”
Usted puede utilizar cualquier comando service o el script /etc/init.d/sssd para controlar SSSD. Por ejemplo, ejecute el siguiente comando para iniciar sssd:
# systemctl start sssd.service
Por predefinicion, SSSD esta configurado para iniciar automaticamente. Hay dos formas para cambiar este comportamiento; si usted utiliza la herramienta de Configuracion de Idenificacion para configurar SSSD, esta reconfigura el comportamiento predefinido asi que SSSD inicia cuando la maquina arranca. Alternativamente, usted puede utilizar el comando systemctl, como sigue:
# systemctl enable sssd.service

9.2.3.2. Configurando SSSD

La configuracion global de SSSD se almacena en el archivo /etc/sssd/sssd.conf, Este archivo consiste de varias secciones, cada una de las cuales contiene unos pares de llave/valor. Algunas llaves aceptan valores multiples; para esas llaves utilice comas para separar los valores multiples. Este archivo de configuracion utiliza tipos de datos string (no requiere comillas), integer and Boolean (con valores TRUE o FALSE). Los comentarios se indican ya sea con un símbolo numeral (#) o punto y coma (;) en la primera columna. El ejemplo siguiente ilustra algo de la sintaxis.
[section]
# Keys with single values
key1 = value
key2 = val2

# Keys with multiple values
key10 = val10,val11

Especificando un archivo de configuración diferente

Usted puede utilizar el parámetro -c (o --config) en el terminal para especificar un archivo de configuración SSSD diferente.
El formato del archivo de configuracion se describe en Sección 9.2.9, “SSSD Configuration File Format”
Para mayor información sobre las opciones globales de configuracion de SSSD refiérase a la pagina sssd.conf(5) del manual.
9.2.3.2.1. Configurando NSS
SSSD provee un nuevo modulo NSS sssd_nss, de tal forma que usted pueda configurar su sistema para utilizar SSSD para recuperar información del usuario. Edite el archivo /etc/nsswitch.conf de sus sistema para que utilice el nombre sss
passwd: files sss
group: files sss
9.2.3.2.2. Configurando PAM

Sea cuidadoso cuando cambie su configuración PAM

Tenga extrema precaución cuando cambie su configuración PAM. Un error en el archivo de configuración PAM puede bloquearlo del sistema completamente. Respalde siempre sus archivos de configuración antes de hacer cualquier cambio, y mantenga la sesión abierta de tal forma que pueda revertir cualquier cambio que usted halla realizado si la necesidad así lo requiere.
Para habilitar el sistema a que utilice SSSD para PAM, usted necesita editar el archivo predefinido de configuración PAM. En sistemas basados en Fedora—, es el archivo /etc/pam.d/system-auth.
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     required      pam_mkhomedir.so umask=0022 skel=/etc/skel/
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     sufficient    pam_sss.so
session     required      pam_unix.so
9.2.3.2.2.1. Utilizando Directorios Home Especiales con SSSD
Si sus usuarios LDAP tienen directorios home que no están en /home, y si sus sistema esta configurado para crear directorios home la primera vez que los usuarios ingresen, entonces esos directorios serán creados con los permisos equivocados. Por ejemplo, en lugar de un directorio home típico tal como /home/<username>, sus usuarios podrian tener directorios home que incluyan lenguaje de preferencia (locale), por ejemplo, tal como /home/<locale>/<username>. Si esto es cierto en su sistema, se necesitan realizar los pasos siguientes (preventivamente)
  1. Aplicar el contexto correcto SELinux y los permisos del directorio /home al directorio home que usted utiliza en su sistema. En el ejemplo anterior, las instrucciones siguientes alcanzarían estos resultados (el remplazo de los nombres de directorios con los que se aplican a su sistema)
    # semanage fcontext -a -e /home /home/locale
  2. Asegurese que el paquete oddjob-mkhomedir esta instalado en su sistema y vuelva a correr la herramienta de Configuración de Identificación
    Este paquete provee la biblioteca pam_oddjob_mkhomedir.so, la cual sera utilizada por la herramienta de configuración de identificación para crear sus directorios home personalizados. Usted necesita esta biblioteca para crear sus directorios home, y no la biblioteca predeterminada pam_mkhomedir.so porque esta ultima no puede crear etiquetas SELinux.

    Las bibliotecas pam_oddjob_mkhomedir and pam_mkhomedir

    La herramienta de Configuracion de Identificación utilizara automaticamente la biblioteca pam_oddjob_mkhomedir.so si esta esta disponible. De otra manera, quedara predeterminada a utilizar pam_mkhomedir.so.
Si no se hubieran realizado los pasos precedentes antes de la creacion de los directorios home personalizados, usted puede utilizar las siguientes instrucciones para corregir los permisos y contextos SELinux (otra vez, remplace el los nombres de directorios con los nombres que se aplican a su sistema):
# semanage fcontext -a -e /home /home/locale
# restorecon -R -v /home/locale
9.2.3.2.2.2. Utilizando statements "include" en Configuraciones PAM
La reciente implementación de PAM le permite a usted utilizar declaraciones include en las configuraciones PAM. Por ejemplo:
...
session     include      system-auth
session     optional     pam_console.so
...
En el ejemplo precedente, si se recibe una condicion sufficient a partir de system-auth PAM_SUCCESS, no se ejecutara pam_console.so.
9.2.3.2.3. Configurando Control de Acceso
SSSD provee un mecanismo de control de acceso rudimentario, ofreciendo dos soluciones basadas en el valor de la opcion access_provider en la seccion [domain/<NAME>] del archivo /etc/sssd/sssd.conf.
9.2.3.2.3.1. El proveedor de Acceso Único
La primera de esas soluciones se conoce como Proveedor de Acceso Unico,y se basa en la implementación de listas de acceso o negación de usuarios. Para habilitar el Proveedor de Acceso Único, usted necesita configurar la opción access_provider a simple, y luego agregar los nombres de usuarios en una lista separada por comas sea para las opciones simple_allow_users o simple_deny_users.
Utilizando el proveedor de Acceso Único
Al utilizar el Proveedor de Acceso Único, usted puede continuar soportando un numero determindado de ingresos para mantener las cuentas comunes de una empresa o un departamento de computadores portátiles, pero usted puede querer restringir la utilización de un computador portátil en particular a uno o dos usuarios. Esto quiere decir que aun si un usuario distinto se se ha identificado con éxito con el mismo proveedor de identificación, el Proveedor de Acceso Único prevendría a ese usuario de ingresar al sistema
El ejemplo siguiente demuestra la utilización del Proveedor de Acceso Único para permitir el acceso a dos usuarios. Este ejemplo asume que SSSD esta configurado correctamente y que example.com es uno de los dominios especificados en la sección [sssd] sección, y solo muestra las opciones especificas del Proveedor de Acceso Único.
[domain/example.com]
access_provider = simple
simple_allow_users = user1, user2

Utilizando el proveedor de ID local

The Local ID provider does not support simple as an access provider.
Reglas de Control de Acceso
The Simple Access Provider adheres to the following three rules to determine which users should or should not be granted access:
  • If both lists are empty, access is granted.
  • If simple_allow_users is set, only users from this list are allowed access. This setting supersedes the simple_deny_users list (which would be redundant).
  • If the simple_allow_users list is empty, users are allowed access unless they appear in the simple_deny_users list.

Do not define both simple_allow_users and simple_deny_users

Defining both simple_allow_users and simple_deny_users is a configuration error. If this occurs, SSSD will output an error to the /var/log/sssd/sssd_default.log log file when loading the back end, but continue to start normally. Future versions of SSSD will output an error and fail to start.
9.2.3.2.3.2. EL proveedor de Acceso LDAP
The second access control solution uses the LDAP server itself as the access provider (access_provider=ldap) and the associated filter option (ldap_access_filter) to specify which users are granted access to the specified host. Note that these two options are codependent; if you use LDAP as your access provider then you must specify a value for the ldap_access_filter option, otherwise all users will be denied access. If you are not using LDAP as your access provider, then the ldap_access_filter option has no effect.
Utilizando el proveedor de Acceso LDAP
The following example demonstrates the use of the LDAP Access Provider to grant access to members of the "allowedusers" group in LDAP. This example assumes that SSSD is correctly configured and example.com is one of the domains specified in the [sssd] section, and only shows the LDAP Access Provider-specific options.
[domain/example.com]
access_provider = ldap
ldap_access_filter = memberOf=cn=allowedusers,ou=Groups,dc=example,dc=com

Utilizando los archivos temporales fuera de linea

Offline caching for this feature is limited to determining whether or not the user's last online login attempt was successful. If they were granted access during their last login, they will continue to be granted access while offline, and vice-versa.
Refer to the sssd-ldap manual page for more information about using the LDAP Access Provider.
9.2.3.2.4. Configurando Failover
The failover feature allows back ends to automatically switch to a different server if the primary server fails. These servers are entered as a case-insensitive, comma-separated list in the [domain/<NAME>] sections of the /etc/sssd/sssd.conf file, and listed in order of preference. This list can contain any number of servers.
For example, if you have configured a native LDAP domain, you could specify the following as your ldap_uri values:
ldap_uri = ldap://ldap0.mydomain.org, ldap://ldap1.mydomain.org, ldap://ldap2.mydomain.org
In this configuration, ldap://ldap0.mydomain.org functions as the primary server. If this server fails, the SSSD failover mechanism first attempts to connect to ldap1.mydomain.org, and if that server is unavailable, it then attempts to connect to ldap2.mydomain.org.
If the parameter that specifies which server to connect to for the specific domain (for example, ldap_uri, krb5_server, …) is not specified, the back end defaults to using Use service discovery. Refer to Sección 9.2.3.2.4.1, “Using SRV Records with Failover” for more information on service discovery.

No utilice parámetros múltiples ldap_uri

Do not use multiple ldap_uri parameters to specify your failover servers. The failover servers must be entered as a comma-separated list of values for a single ldap_uri parameter. If you enter multiple ldap_uri parameters, SSSD only recognizes the last entry.
Future versions of SSSD will throw an error upon receiving additional ldap_uri entries.
9.2.3.2.4.1. Using SRV Records with Failover
SSSD also supports the use of SRV records in its failover configuration. This means that you can specify a server that is later resolved into a list of specific servers using SRV requests. The priority and weight attributes of SRV records provide further opportunity for specifying which servers should be contacted first in the event that the primary server fails.
For every service with which you want to use service discovery, you need to add a special DNS record to your DNS server using the following form:
_service._protocol._domain TTL priority weight port hostname
A typical configuration would contain multiple such records, each with a different priority (for failover) and different weights (for load balancing).
The client then makes an SRV DNS query to retrieve a list of host names, their priorities, and weights. These queries are of the form _service._protocol._domain, for example, _ldap._tcp._redhat.com. The client then sorts this list according to the priorities and weights, and connects to the first server in this sorted list.
For more information on SRV records, refer to RFC 2782.
9.2.3.2.4.2. How the Failover Mechanism Works
The failover mechanism distinguishes between machines and services. The back end first tries to resolve the hostname of a given machine; if this resolution attempt fails, the machine is considered offline. No further attempts are made to connect to this machine for any other service. If the resolution attempt succeeds, the back end tries to connect to a service on this machine. If the service connection attempt fails, then only this particular service is considered offline and the back end automatically switches over to the next service. The machine is still considered online and might still be tried for another service.
The failover mechanism does not handle DNS A records with multiple IP addresses; instead it only uses the first address. DNS round-robin cannot be used for failover. Further, providing multiple A records does not provide failover. Only the first A record is used, and if a lookup attempt on the first record fails then the system attempts no further lookups. To find multiple servers with a single request, and thus implementing failover, SSSD relies on SRV resource records, as explained in Sección 9.2.3.2.4.1, “Using SRV Records with Failover”.
Further connection attempts are made to machines or services marked as offline after a specified period of time; this is currently hard coded to 30 seconds. If there are no more machines to try, the back end as a whole switches to offline mode, and then attempts to reconnect every 30 seconds.

9.2.4. Configuring Services

Individual pieces of SSSD functionality are provided by special SSSD services that are started and stopped together with SSSD. The services provided by SSSD have their own configuration sections. The [sssd] section also lists the services that are active and should be started when sssd starts within the services directive.
SSSD currently provides several services:
  • NSS — An NSS provider service that answers NSS requests from the sssd_nss module.
  • PAM — A PAM provider service that manages a PAM conversation through the sssd_pam PAM module.
  • monitor — A special service that monitors all other SSSD services, and starts or restarts them as needed. Its options are specified in the [sssd] section of the /etc/sssd/sssd.conf configuration file.

9.2.4.1. Configuration Options

The following sections cover the most important SSSD configuration options. Refer to the sssd.conf(5) manual page that ships with SSSD for information on all the available configuration options.
9.2.4.1.1. General Configuration Options
  • debug_level (integer)
    Sets the debug level for a particular service. This is a per-service setting (that is, it can appear in any of the [service/<NAME>] sections in the SSSD configuration file).
  • reconnection_retries (integer)
    In the event of a data provider crash or restart, this specifies the number of times that a service should attempt to reconnect.

    DNS lookup of IPv6 addresses

    If a DNS lookup fails to return an IPv4 address for a hostname, SSSD attempts to look up an IPv6 address before returning a failure. Note that this only ensures that the async resolver identifies the correct address; there is currently a bug in the LDAP code that prevents SSSD from connecting to an LDAP server over IPv6. This is being investigated separately.
9.2.4.1.2. NSS Configuration Options
Use the following options to configure the Name Service Switch (NSS) service. Refer to the sssd.conf(5) manual page for full details about each option.
  • enum_cache_timeout (integer)
    Specifies for how long (in seconds) sssd_nss should cache enumerations (requests for information about all users).
  • entry_cache_nowait_percentage (integer)
    Specifies for how long sssd_nss should return cached entries before initiating an out-of-band cache refresh (0 disables this feature).
    You can configure the entry cache to automatically update entries in the background if they are requested beyond a percentage of the entry_cache_timeout value for the domain.
    Valid values for this option are 0-99, and represent a percentage of the entry_cache_timeout value for each domain.
  • entry_negative_timeout (integer)
    Specifies for how long (in seconds) sssd_nss should cache negative cache hits (that is, queries for invalid database entries, such as nonexistent ones) before asking the back end again.
  • filter_users, filter_groups (string)
    Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts such as root.
  • filter_users_in_groups (Boolean)
    If set to TRUE, specifies that users listed in the filter_users list do not appear in group memberships when performing group lookups. If set to FALSE, group lookups return all users that are members of that group. If not specified, defaults to TRUE.
9.2.4.1.3. PAM Configuration Options
Use the following options to configure the Pluggable Authentication Module (PAM) service.
  • offline_credentials_expiration (integer)
    If the authentication provider is offline, specifies for how long to allow cached log-ins (in days). This value is measured from the last successful online log-in. If not specified, defaults to 0 (no limit).
  • offline_failed_login_attempts (integer)
    If the authentication provider is offline, specifies how many failed log in attempts are allowed. If not specified, defaults to 0 (no limit).
  • offline_failed_login_delay (integer)
    Specifies the time in minutes after the value of offline_failed_login_attempts has been reached before a new log in attempt is possible.
    If set to 0, the user cannot authenticate offline if the value of offline_failed_login_attempts has been reached. Only a successful online authentication can re-enable offline authentication. If not specified, defaults to 5.

9.2.5. Configuring Domains

A domain is a database of user information. SSSD can use more than one domain at the same time, but at least one must be configured for SSSD to start. Using SSSD domains, it is possible to use several LDAP servers providing several unique namespaces. You can specify not only where users' identity information is stored, but how users authenticate against each of the specified domains.
SSSD supports the following identity and authentication combinations:
LDAP/LDAP
This combination uses an LDAP back end as both the identity and authentication provider. For more information, refer to Sección 9.2.5.2, “Configuring an LDAP Domain”.
LDAP/KRB5
This combination uses an LDAP back end as the identity provider, and uses Kerberos to provide authentication. For more information, refer to Sección 9.2.6, “Setting Up Kerberos Authentication”.
proxy
Specifying a proxy identity or an authentication provider uses an existing NSS library or a customized PAM stack, but takes advantage of the SSSD caching mechanism. For more information, refer to Sección 9.2.7, “Configuring a Proxy Domain”.
The following example assumes that SSSD is correctly configured and FOO is one of the domains in the [sssd] section. This example shows only the configuration of Kerberos authentication; it does not include any identity provider.
[domain/FOO]
auth_provider = krb5
krb5_server = 192.168.1.1
krb5_realm = EXAMPLE.COM

9.2.5.1. Domain Configuration Options

You can add new domain configurations to the [domain/<NAME>] sections of the /etc/sssd/sssd.conf file, and then add the list of domains to the domains attribute of the [sssd] section, in the order you want them to be queried.
9.2.5.1.1. General Domain Configuration Options
You can use the following configuration options in a domain configuration section:
  • min_id,max_id (integer)
    Specifies the UID and GID limits for the domain. If a domain contains entries that are outside these limits, they are ignored.
    The default value for min_id is 1; the default value for max_id is 0 (unbounded).

    Avoid conflicts with users in /etc/passwd

    If min_id is unspecified, it defaults to 1 for any back end. This default was chosen to provide compatibility with existing systems and to ease any migration attempts. LDAP administrators should be aware that granting identities in this range may conflict with users in the local /etc/passwd file. To avoid these conflicts, min_id should be set to 1000 or higher wherever possible.
    The min_id option determines the minimum acceptable value for both UID and GID numbers. Accounts with either UID or GID values below the min_id value are filtered out and not made available on the client.
  • enumerate (Boolean)
    Specifies whether or not to enumerate (list) the users and groups of a domain.
    Enumeration means that the entire set of available users and groups on the remote source is cached on the local machine. When enumeration is disabled, users and groups are only cached as they are requested.

    Disable enumeration for domains with many users and groups

    If a client has enumeration enabled, reinitialization of the client results in a complete refresh of the entire set of available users and groups from the remote source. Similarly, when SSSD is connected to a new server, the entire set of available users and groups from the remote source is pulled and cached on the local machine. In a domain with a large amount of clients connected to a remote source, both aforementioned cases can affect the network performance due to frequent queries from the clients. If the set of available users and groups is large enough, it will affect the performance of clients as well. For performance reasons, it is recommended that you disable enumeration for domains with many users and groups.
    The default value for this parameter is FALSE. Set this value to TRUE to enable enumeration of users and groups of a domain.
  • timeout (integer)
    Specifies the timeout in seconds for this particular domain.
    This is used to ensure that the back end process is alive and capable of answering requests. The default value for this parameter is 10 seconds. Raising this timeout might prove useful for slower back ends, such as distant LDAP servers.

    Changing the timeout value to 0

    If you set timeout = 0, SSSD reverts to the default value; you cannot force a timeout value of zero, because this would force the sssd daemon into a loop.
  • cache_credentials (Boolean)
    Specifies whether or not to store user credentials in the local SSSD domain database cache.
    The default value for this parameter is FALSE. You should set this value to TRUE for domains other than local if you want to enable offline authentication.
  • id_provider (string)
    Specifies the data provider identity back end to use for this domain. Currently supported identity back ends are:
    • proxy — Support a legacy NSS provider (for example, nss_nis).

      Changing the id_provider value to proxy

      SSSD needs to know which legacy NSS library to load in order to start successfully. If you set id_provider to proxy, ensure that you also specify a value for proxy_lib_name. Refer to Sección 9.2.7, “Configuring a Proxy Domain” for information on this attribute.
    • local — SSSD internal local provider.
    • ldap — LDAP provider.
  • entry_cache_timeout (integer)
    Specifies for how long the domain's data provider should cache positive cache hits (that is, queries for valid database entries) before asking the database again.
  • use_fully_qualified_names (Boolean)
    Specifies whether or not requests to this domain require fully-qualified domain names.
    If set to TRUE, all requests to this domain must use fully-qualified domain names. It also means that the output from the request displays the fully-qualified name.
    The ability to restrict requests in this way means that if you know you have multiple domains with conflicting usernames, then there is no doubt about which username the query will resolve.
    Consider the following examples, in which the IPA domain database contains a user named ipauser01, and the use_fully_qualified_names attribute is set to TRUE:
    # getent passwd ipauser01
    [no output]
    # getent passwd ipauser01@IPA
    ipauser01@IPA:x:937315651:937315651:ipauser01:/home/ipauser01:/bin/sh
    
    In the following examples, using the same IPA domain and user, the use_fully_qualified_names attribute is set to FALSE:
    # getent passwd ipauser01
    ipauser01:x:937315651:937315651:ipauser01:/home/ipauser01:/bin/sh
    # getent passwd ipauser01@IPA
    ipauser01:x:937315651:937315651:ipauser01:/home/ipauser01:/bin/sh
    

    Changing the use_fully_qualified_names value to FALSE

    If use_fully_qualified_names is set to FALSE, you can continue to use the fully-qualified name in your requests, but only the simplified version is displayed in the output.
    SSSD can only parse name@domain, not name@realm. You can, however, use the same name for both your domain and your realm.
  • auth_provider (string)
    The authentication provider used for the domain. The default value for this option is the value of id_provider if it is set and can handle authentication requests.
    Currently supported authentication providers are:
    • ldap — for native LDAP authentication. Refer to the sssd-ldap(5) manual page for more information on configuring LDAP.
    • krb5 — for Kerberos authentication. Refer to the sssd-krb5(5) manual page for more information on configuring Kerberos.
    • proxy — for relaying authentication to some other PAM target.
    • none — explicitly disables authentication.
9.2.5.1.2. Proxy Configuration Options
  • proxy_pam_target (string)
    This option is only used when the auth_provider option is set to proxy, and specifies the target to which PAM must proxy.
    This option has no default value. If proxy authentication is required, you need to specify your own PAM target. This corresponds to a file containing PAM stack information in the system's default PAM configuration directory. On Fedora-based systems, this is the /etc/pam.d/ directory.

    Avoid recursive inclusion of pam_sss

    Ensure that your proxy PAM stack does not recursively include pam_sss.so.
  • proxy_lib_name (string)
    This option is only used when the id_provider option is set to proxy, and specifies which existing NSS library to proxy identity requests through.
    This option has no default value. You need to manually specify an existing library to take advantage of this option. For example, set this value to nis to use the existing libnss_nis.so file.

9.2.5.2. Configuring an LDAP Domain

An LDAP domain is one where the id_provider option is set to ldap (id_provider = ldap). Such a domain requires a running LDAP server against which to authenticate. This can be an open source LDAP server such as OpenLDAP or Microsoft Active Directory. SSSD currently supports Microsoft Active Directory 2003 (+Services for UNIX) and Active Directory 2008 (+Subsystem for UNIX-based Applications). In all cases, the client configuration is stored in the /etc/sssd/sssd.conf file.
How to Authenticate Against an LDAP Server
SSSD does not support authentication over an unencrypted channel. Consequently, if you want to authenticate against an LDAP server, either TLS/SSL or LDAPS is required. If the LDAP server is used only as an identity provider, an encrypted channel is not needed.
Edit your /etc/sssd/sssd.conf file to include the following settings:
# A native LDAP domain
[domain/LDAP]
enumerate = false
cache_credentials = TRUE

id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307
chpass_provider = ldap

ldap_uri = ldap://ldap.mydomain.org
ldap_search_base = dc=mydomain,dc=org
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt

Creating a certificate with an IP address instead of the server name

If you wish to use an IP address in the ldap_uri option instead of the server name, for example, if GSSAPI is used to avoid time consuming DNS lookups, the TSL/SSL setup might fail. This is due to the fact that TSL/SSL certificates contain the server name only. However, a special field in the certificate, called Subject Alternative Name (subjectAltName), can be used to additionally set the IP address of the server.
The following steps show how to create a certificate with a Subject Alternative Name being the IP address of your server:
  1. Using your command line, execute the following command to convert an existing certificate (previously signed by the key.pem key) into a certificate request:
    openssl x509 -x509toreq -in old_cert.pem -out req.pem -signkey key.pem
    Alternatively, if you are using a self-signed certificate(for example, one created by the Fedora OpenLDAP package in /etc/pki/tls/certs/slapd.pem), execute the following command:
    openssl x509 -x509toreq -in old_cert.pem -out req.pem -signkey old_cert.pem
  2. Edit your /etc/pki/tls/openssl.cnf configuration file to include the following line under the [ v3_ca ] section:
    subjectAltName = IP:10.0.0.10
    Replace the IP address with one of your choice.
  3. By executing the following command, use the previously generated certificate request to generate a new self-signed certificate that will contain your desired IP address:
    openssl x509 -req -in req.pem -out new_cert.pem -extfile ./openssl.cnf -extensions v3_ca -signkey old_cert.pem
    where:
    • The openssl x509 command creates the new certificate.
    • The -req option tells the command to expect a certificate request as an input.
    • The -in and -out options specify the input and output files.
    • The -extfile option expects a file containing certificate extensions to use (in our case the subjectAltName extension).
    • The -extensions option specifies the section of the openssl.cnf file to add certificate extensions from (in this case, the [ v3_ca ] section).
    • The -signkey option tells the command to self-sign the input file using the supplied private key.
    For more information on the x509 utility and its parameters, refer to man x509.
  4. Lastly, copy the private key block from the old_cert.pem file into the new_cert.pem file to keep all relevant information in one file.
When creating a certificate through the certutil utility provided by the nss-utils package, note that certutil supports DNS subject alternative names for certificate creation only.
It is advisable to use a Certificate Authority to issue your certificate. Consider using the Red Hat Certificate System; for more information on managing subject names and subject alternative names in your certificate, refer to the Red Hat Certificate System Admin Guide.
Selecting an LDAP Schema
You can set the ldap_schema attribute to either rfc2307 or rfc2307bis. These schema define how groups in LDAP are specified. In RFC 2307, group objects use a multi-valued attribute, memberuid, which lists the names of the users that belong to that group. In RFC 2307bis, instead of the memberuid, group objects use the member attribute. Rather than just the name of the user, this attribute contains the full Distinguished Name (DN) of another object in the LDAP database. This means that groups can have other groups as members. That is, it adds support for nested groups.
SSSD assumes that your LDAP server is using RFC 2307. If your LDAP server is using RFC 2307bis, and you do not update the /etc/sssd/sssd.conf file accordingly, this can impact how your users and groups are displayed. It also means that some groups will not be available and network resources may be inaccessible even though you have permissions to use them.
For example, when using RFC 2307bis and you have configured both primary and secondary groups, or are using nested groups, you can use the id command to display these groups:
[f12server@ipaserver ~]$ id
uid=500(f12server) gid=500(f12server) groups=500(f12server),510(f12tester)
If instead you have configured your client to use RFC 2307 then only the primary group is displayed.
Changes to this setting only affect how SSSD determines the groups to which a user belongs; there is no negative effect on the actual user data. If you do not know the correct value for this attribute, consult your System Administrator.
Specifying Timeout Values
SSSD supports a number of timeout values that apply when configuring an LDAP domain. These are described below.
  • ldap_search_timeout (integer) — Specifies the timeout (in seconds) that LDAP searches are allowed to run before they are canceled and cached results are returned (and offline mode is entered). If not specified:
    Defaults to five when enumerate = False
    Defaults to 30 when enumerate = True. This option is forced to a minimum of 30 in this case.

    The ldap_network_timeout option is going to be changed

    This option is subject to change in future versions of SSSD, where it may be replaced by a series of timeouts for specific look-up types.
  • ldap_network_timeout (integer) — Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity.
    If not specified, defaults to five.
  • ldap_opt_timeout (integer) — Specifies the timeout (in seconds) after which calls to synchronous LDAP APIs will abort if no response is received. This option also controls the timeout when communicating with the KDC in case of a SASL bind.
    If not specified, defaults to five.

DNS Service Discovery

The DNS service discovery feature allows the LDAP back end to automatically find the appropriate DNS servers to connect to using a special DNS query. For more information on the DNS service discovery feature, refer to Sección 9.2.3.2.4.1, “Using SRV Records with Failover”.

9.2.5.3. Configuring a Microsoft Active Directory Domain

You can configure SSSD to use Microsoft Active Directory as an LDAP back end, providing both identity and authentication services. If you are using Active Directory 2003, SSSD requires that you install Windows Services for UNIX (SFU) on the machine where Active Directory is installed. If instead you are using Active Directory 2008, you need to install the Subsystem for UNIX-based Applications (SUA) on the Active Directory machine.

SFU is not supported on 64-bit systems

SFU is not supported on 64-bit operating systems. Refer to http://support.microsoft.com/kb/920751 for more information about which Windows systems can provide a suitable platform for an SSSD LDAP back end.
9.2.5.3.1. Configuring Active Directory 2003 as an LDAP Back End
The example /etc/sssd/sssd.conf file that ships with SSSD contains the following sample configuration for Active Directory 2003:
# Example LDAP domain where the LDAP server is an Active Directory 2003 server.

[domain/AD]
description = LDAP domain with AD server
enumerate = false
min_id = 1000
;
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://your.ad.server.com
ldap_schema = rfc2307bis
ldap_search_base = dc=example,dc=com
ldap_default_bind_dn = cn=Administrator,cn=Users,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = YOUR_PASSWORD
ldap_user_object_class = person
ldap_user_name = msSFU30Name
ldap_user_uid_number = msSFU30UidNumber
ldap_user_gid_number = msSFU30GidNumber
ldap_user_home_directory = msSFU30HomeDirectory
ldap_user_shell = msSFU30LoginShell
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_group_name = msSFU30Name
ldap_group_gid_number = msSFU30GidNumber
This configuration is specific to Windows Active Directory 2003. Refer to Sección 9.2.5.3.2, “Configuring Active Directory 2003 R2 and 2008 as LDAP Back Ends” for information on how to configure Active Directory 2003 R2 and Active Directory 2008.
Note that the above configuration assumes that the certificates are stored in the default location (that is, in /etc/openldap/cacerts) and that the c_rehash function has been used to create the appropriate symlinks.
More Information
Refer to the sssd-ldap(5) manual page for a full description of all the options that apply to LDAP domains.
9.2.5.3.2. Configuring Active Directory 2003 R2 and 2008 as LDAP Back Ends
The configuration of /etc/sssd/sssd.conf to support Active Directory 2003 R2 or Active Directory 2008 as a back end is similar to that for AD 2003. The following example configuration highlights the necessary changes.
# Example LDAP domain where the LDAP server is an Active Directory 2003 R2 or an Active Directory 2008 server.

[domain/AD]
description = LDAP domain with AD server
; debug_level = 9
enumerate = false

id_provider = ldap
auth_provider = ldap
chpass_provider = ldap

ldap_uri = ldap://your.ad.server.com
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_tls_cacert = /etc/openldap/cacerts/test.cer
ldap_search_base = dc=example,dc=com
ldap_default_bind_dn = cn=Administrator,cn=Users,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = YOUR_PASSWORD
ldap_pwd_policy = none
ldap_user_object_class = user
ldap_group_object_class = group
Note that the above configuration assumes that the certificates are stored in the default location (that is, in /etc/openldap/cacerts) and that the c_rehash function has been used to create the appropriate symlinks.

9.2.6. Setting Up Kerberos Authentication

In order to set up Kerberos authentication, you need to know the address of your key distribution center (KDC) and the Kerberos domain. The client configuration is then stored in the /etc/sssd/sssd.conf file.
The Kerberos 5 authentication back end does not contain an identity provider and must be paired with one in order to function properly (for example, id_provider = ldap). Some information required by the Kerberos 5 authentication back end must be supplied by the identity provider, such as the user's Kerberos Principal Name (UPN). The identity provider configuration should contain an entry to specify this UPN. Refer to the manual page for the applicable identity provider for details on how to configure the UPN.
If the UPN is not available in the identity back end, SSSD will construct a UPN using the format username@krb5_realm.
SSSD assumes that the Kerberos KDC is also a Kerberos kadmin server. However, it is very common for production environments to have multiple, read-only replicas of the KDC, but only a single kadmin server (because password changes and similar procedures are comparatively rare). To manage this type of configuration, you can use the krb5_kpasswd option to specify where your password changing service is running, or if it is running on a non-default port. If the krb5_kpasswd option is not defined, SSSD tries to use the Kerberos KDC in order to change the password. Refer to the sssd-krb5(5) manual page for more information about this and all Kerberos configuration options.
How to Set Up Kerberos Authentication
Edit your /etc/sssd/sssd.conf file to include the following settings:
# A domain with identities provided by LDAP and authentication by Kerberos
[domain/KRBDOMAIN]
enumerate = false
id_provider = ldap
chpass_provider = krb5
ldap_uri = ldap://ldap.mydomain.org
ldap_search_base = dc=mydomain,dc=org
tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt

auth_provider = krb5
krb5_server = 192.168.1.1
krb5_realm = EXAMPLE.COM
krb5_changepw_principal = kadmin/changepw
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
krb5_auth_timeout = 15
This example describes the minimum options that must be configured when using Kerberos authentication. Refer to the sssd-krb5(5) manual page for a full description of all the options that apply to configuring Kerberos authentication.

DNS Service Discovery

The DNS service discovery feature allows the Kerberos 5 authentication back end to automatically find the appropriate DNS servers to connect to using a special DNS query. For more information on the DNS service discovery feature, refer to Sección 9.2.3.2.4.1, “Using SRV Records with Failover”.

9.2.6.1. Setting up SASL/GSSAPI Authentication

GSSAPI (Generic Security Services Application Programming Interface) is a supported SASL (Simple Authentication and Security Layer) authentication method. Kerberos is currently the only commonly used GSSAPI implementation. An LDAP client and an LDAP server use SASL to take advantage of GSSAPI as the authentication method (an alternative to plain text passwords, etc.). The GSSAPI plug-in for SASL is then invoked on the client and server side to use Kerberos to communicate.
Using GSSAPI protected communication for LDAP is an advanced configuration not supported by the Authentication Configuration tool; the following steps show how to manually configure it.
On the KDC
  1. Using kadmin, set up a Kerberos service principal for the directory server. Use the -randkey option for the kadmin's addprinc command to create the principal and assign it a random key:
    kadmin: addprinc -randkey ldap/server.example.com
  2. Use the ktadd command to write the service principal to a file:
    kadmin: ktadd -k /root/ldap.keytab ldap/server.example.com
  3. Using kadmin, set up a Kerberos host principal for the client running SSSD. Use the -randkey option for the kadmin's addprinc command to create the principal and assign it a random key:
    kadmin: addprinc -randkey host/client.example.com
  4. Use the ktadd command to write the host principal to a file:
    kadmin: ktadd -k /root/client.keytab host/client.example.com
On the Directory Server
Complete the following steps for a directory server of your choice:
OpenLDAP
  1. Copy the previously created /root/ldap.keytab file from the KDC to the /etc/openldap/ directory and name it ldap.keytab.
  2. Make the /etc/openldap/ldap.keytab file read-writable for the ldap user and readable for the ldap group only.
Red Hat Directory Server
  1. Copy the previously created /root/ldap.keytab file from the KDC to the /etc/dirsrv/ directory and name it ldap.keytab.
  2. Uncomment the KRB5_KTNAME line in the /etc/sysconfig/dirsrv (or instance-specific) file, and set the keytab location for the KRB5_KTNAME variable. For example:
    # In order to use SASL/GSSAPI the directory
    # server needs to know where to find its keytab
    # file - uncomment the following line and set
    # the path and filename appropriately
    KRB5_KTNAME=/etc/dirsrv/ldap.keytab; export KRB5_KTNAME
On the Client
  1. Copy the previously created /root/client.keytab file from the KDC to the /etc/ directory and name it krb5.keytab. If the /etc/krb5.keytab file exists already, use the ktutil utility to merge both files properly. For more information on the ktutil utility, refer to man ktutil.
  2. Modify your /etc/sssd/sssd.conf file to include the following settings:
    ldap_sasl_mech = gssapi
    ldap_sasl_authid = host/client.example.com@EXAMPLE.COM
    ldap_krb5_keytab = /etc/krb5.keytab (default)
    ldap_krb5_init_creds = true (default)
    ldap_krb5_ticket_lifetime = 86400 (default)
    krb5_realm = EXAMPLE.COM
    

9.2.7. Configuring a Proxy Domain

SSSD currently only supports LDAP and Kerberos as authentication providers. If you prefer to use SSSD (for example, to take advantage of its caching functionality), but SSSD does not support your authentication method, you can set up a proxy authentication provider. This could be the case if you use fingerprint scanners or smart cards as part of your authentication process. Similarly, you can set up proxy to serve as an identity provider.
The following sections cover combinations of identity and authentication providers in which the proxy server takes the role of one.

9.2.7.1. proxy/KRB5

The following configuration is an example of a combination of a proxy identity provider used with Kerberos authentication:
Edit the /etc/sssd/sssd.conf configuration file to include the following settings:
[domain/PROXY_KRB5]
auth_provider = krb5
krb5_server = 192.168.1.1
krb5_realm = EXAMPLE.COM

id_provider = proxy
proxy_lib_name = nis
enumerate = true
cache_credentials = true
For more information on various Kerberos configuration options, refer to Sección 9.2.6, “Setting Up Kerberos Authentication”.

9.2.7.2. LDAP/proxy

An example of a combination of an LDAP identity provider and a proxy authentication provider is the use of the LDAP with a custom PAM stack. To enable authentication via the PAM stack, complete the following steps:
  1. Edit the /etc/sssd/sssd.conf configuration file to include the following settings:
    [domain/LDAP_PROXY]
    id_provider = ldap
    ldap_uri = ldap://example.com
    ldap_search_base = dc=example,dc=com
    
    auth_provider = proxy
    proxy_pam_target = sssdpamproxy
    enumerate = true
    cache_credentials = true
    
    By specifying the options above, authentication requests will be proxied via the /etc/pam.d/sssdpamproxy file which provides the needed module interfaces. Note that the pam_ldap.so file can be substituted with a PAM module of your choice.
    For more information on various LDAP configuration options, refer to Sección 9.2.5.2, “Configuring an LDAP Domain”.
  2. Create a /etc/pam.d/sssdpamproxy file (if not already created) and specify the following settings in it:
    auth          required      pam_ldap.so
    account       required      pam_ldap.so
    password      required      pam_ldap.so
    session       required      pam_ldap.so

9.2.7.3. proxy/proxy

An example of a combination of an proxy identity provider and a proxy authentication provider is the use of the proxy identity provider with a custom PAM stack. To enable authentication via the PAM stack, complete the following steps:

Make sure the nss-pam-ldapd package is installed

In order to use the proxy identity provider, you must have the nss-pam-ldapd package installed.
  1. Edit the /etc/sssd/sssd.conf configuration file to include the following settings:
    [domain/PROXY_PROXY]
    auth_provider = proxy
    id_provider = proxy
    proxy_lib_name = ldap
    proxy_pam_target = sssdproxyldap
    enumerate = true 
    cache_credentials = true
    
    By specifying the options above, authentication requests will be proxied via the /etc/pam.d/sssdproxyldap file which provides the needed module interfaces.
    For more information on the options used in the configuration example above, refer to man sssd.conf
  2. Create a /etc/pam.d/sssdproxyldap file (if not already created) and specify the following settings in it:
    auth          required      pam_ldap.so
    account       required      pam_ldap.so
    password      required      pam_ldap.so
    session       required      pam_ldap.so
  3. Edit the /etc/nslcd.conf file (the default configuration file for the LDAP name service daemon) to include the following settings:
    uid nslcd
    gid ldap
    uri ldaps://ldap.mydomain.org:636
    base dc=mydomain,dc=org
    ssl on
    tls_cacertdir /etc/openldap/cacerts
    For more information on the options used in the configuration example above, refer to man nslcd.conf

9.2.8. Troubleshooting

This section lists some of the issues you may encounter when implementing SSSD, the possible causes of these issues, and how to resolve them. If you find further issues that are not covered here, refer to the We Need Feedback section in the Preface for information on how to file a bug report.

9.2.8.1. Using SSSD Log Files

SSSD uses a number of log files to report information about its operation, and this information can help to resolve issues in the event of SSSD failure or unexpected behavior. The default location for these log files on Fedora—based systems is the /var/log/sssd/ directory.
SSSD produces a log file for each back end (that is, one log file for each domain specified in the /etc/sssd/sssd.conf file), as well as an sssd_pam.log and an sssd_nss.log file. This level of granularity can help you to quickly isolate and resolve any errors or issues you might experience with SSSD.
You should also examine the /var/log/secure file, which logs authentication failures and the reason for the failure. For example, if you see Reason 4: System Error reported against any failure, you should increase the debug level of the log files.
Producing More Verbose Log Files
If you are unable to identify and resolve any problems with SSSD after inspection of the default log files, you can configure SSSD to produce more verbose files. You can set the debug_level option in the /etc/sssd/sssd.conf for the domain that is causing concern, and then restart SSSD. Refer to the sssd.conf(5) manual page for more information on how to set the debug_level for a specific domain.
All log files include timestamps on debug messages by default. This can make it easier to understand any errors that may occur, why they occurred, and how to address them. If necessary, you can disable these timestamps by setting the appropriate parameter to FALSE in the /etc/sssd/sssd.conf file:
--debug-timestamps=FALSE

9.2.8.2. Problems with SSSD Configuration

  • SSSD fails to start
    • SSSD requires at least one properly configured domain before the service will start. Without such a domain, you might see the following error message when trying to start SSSD with the following command:
      # sssd -d4
      [sssd] [ldb] (3): server_sort:Unable to register control with rootdse!
      
      [sssd] [confdb_get_domains] (0): No domains configured, fatal error!
      [sssd] [get_monitor_config] (0): No domains configured.
      
      You can ignore the "Unable to register control with rootdse!" message, as it is erroneous. The other messages, however, indicate that SSSD is unable to locate any properly configured domains.
      Edit your /etc/sssd/sssd.conf file and ensure you have at least one properly configured domain, and then try to start SSSD.
    • SSSD requires at least one available service provider before it will start. With no available service providers, you might see the following error message when trying to start SSSD with the following command:
      # sssd -d4
      [sssd] [ldb] (3): server_sort:Unable to register control with rootdse!
      
      [sssd] [get_monitor_config] (0): No services configured!
      
      You can ignore the "Unable to register control with rootdse!" message, as it is erroneous. The other message, however, indicates that SSSD is unable to locate any available service providers.
      Edit your /etc/sssd/sssd.conf file and ensure you have at least one available service providers, and then try to start SSSD.

      Configuring the service providers

      SSSD requires that service providers be configured as a comma-separated list in a single services entry in the /etc/sssd/sssd.conf file. If services are listed in multiple entries, only the last entry is recognized by SSSD.
    • Refer to the sssd.conf(5) manual page for more options that might assist in troubleshooting issues with SSSD.

9.2.8.3. Problems with SSSD Service Configuration

9.2.8.3.1. Problems with NSS
This section describes some common problems with NSS, their symptoms, and how to resolve them.
  • NSS fails to return user information
    • Ensure that NSS is running
      # systemctl is-active sssd.service
      This command should return results similar to the following:
      sssd (pid 21762) is running...
      
    • Ensure that you have correctly configured the [nss] section of the /etc/sssd/sssd.conf file. For example, ensure that you have not misconfigured the filter_users or filter_groups attributes. Refer to the NSS configuration options section of the sssd.conf(5) manual page for information on how to configure these attributes.
    • Ensure that you have included nss in the list of services that sssd should start
    • Ensure that you have correctly configured the /etc/nsswitch.conf file. Refer to the section Sección 9.2.3.2.1, “Configurando NSS” for information on how to correctly configure this file.
9.2.8.3.2. Problems with PAM
This section describes some common problems with PAM, their symptoms, and how to resolve them.
  • Setting the password for the local SSSD user prompts twice for the password
    When attempting to change a local SSSD user's password, you might see output similar to the following:
    [root@clientF11 tmp]# passwd user1000
    Changing password for user user1000.
    New password:
    Retype new password:
    New Password:
    Reenter new Password:
    passwd: all authentication tokens updated successfully.
    
    This is the result of an incorrect PAM configuration. Refer to Sección 9.2.3.2.2, “Configurando PAM”, and ensure that the use_authtok option is correctly configured in your /etc/pam.d/system-auth file.
9.2.8.3.3. Problems with NFS and NSCD
SSSD is not designed to be used with the nscd daemon, and will likely generate warnings in the SSSD log files. Even though SSSD does not directly conflict with nscd, the use of both at the same time can result in unexpected behavior (specifically with how long entries are being cached).
If you are using Network Manager to manage your network connections, it may take several minutes for the network interface to come up. During this time, various services will attempt to start. If these services start before the network is up (that is, the DNS servers cannot yet be reached) they will fail to identify the forward or reverse DNS entries they might need. These services will be reading an incorrect or possibly empty resolv.conf file. This file is typically only read once, and so any changes made to this file are not automatically applied.
This can result in the failure of some system services, and in particular can cause NFS locking to fail on the machine where the nscd service is running, unless that service is manually restarted.
One method of working around this problem is to enable caching for hosts and services in the /etc/nscd.conf file, and to rely on the SSSD cache for the passwd and group entries. With nscd answering hosts and services requests, these entries would have been cached and returned by nscd during the boot process.

NSCD and later versions of SSSD

Later versions of SSSD should negate any need for NSCD.

9.2.8.4. Problems with SSSD Domain Configuration

  • NSS returns incorrect user information
    • If your search for user information returns incorrect data, ensure that you do not have conflicting usernames in separate domains. If you use multiple domains, it is recommended that you set the use_fully_qualified_domains attribute to TRUE in the /etc/sssd/sssd.conf file.

9.2.8.5. Recursos adicionales

9.2.8.5.1. Manual Pages
SSSD ships with a number of manual pages, all of which provide additional information about specific aspects of SSSD, such as configuration files, commands, and available options. SSSD currently provides the following manual pages:
  • sssd.conf(5)
  • sssd-ipa(5)
  • sssd-krb5(5)
  • sssd-ldap(5)
  • sssd(8)
  • sssd_krb5_locator_plugin(8)
  • pam_sss(8)
You should refer to these manual pages for detailed information about all aspects of SSSD, its configuration, and associated tools and commands.
9.2.8.5.2. Mailing Lists
You can subscribe to the SSSD mailing list to follow and become involved in the development of SSSD, or to ask questions about any issues you may be experiencing with your SSSD deployment.
Visit https://fedorahosted.org/mailman/listinfo/sssd-devel to subscribe to this mailing list.

9.2.9. SSSD Configuration File Format

The following listing describes the current version (Version 2) of the SSSD configuration file format.
[sssd]
config_file_version = 2
services = nss, pam
domains = mybox.example.com, ldap.example.com, ipa.example.com, nis.example.com
# sbus_timeout = 300

[nss]
nss_filter_groups = root
nss_filter_users = root
nss_entry_cache_timeout = 30
nss_enum_cache_timeout = 30

[domain/mybox.example.com]
domain_type = local
enumerate = true
min_id = 1000
# max_id = 2000

local_default_shell = /bin/bash
local_default_homedir = /home

# Possible overrides
# id_provider = local
# auth_provider = local
# authz_provider = local
# passwd_provider = local

[domain/ldap.example.com]
domain_type = ldap
server = ldap.example.com, ldap3.example.com, 10.0.0.2
# ldap_uri = ldaps://ldap.example.com:9093
# ldap_use_tls = ssl
ldap_search_base = dc=ldap,dc=example,dc=com
enumerate = false

# Possible overrides
# id_provider = ldap
# id_server = ldap2.example.com
# auth_provider = krb5
# auth_server = krb5.example.com
# krb5_realm = KRB5.EXAMPLE.COM

[domain/ipa.example.com]
domain_type = ipa
server = ipa.example.com, ipa2.example.com
enumerate = false

# Possible overrides
# id_provider = ldap
# id_server = ldap2.example.com
# auth_provider = krb5
# auth_server = krb5.example.com
# krb5_realm = KRB5.EXAMPLE.COM

[domain/nis.example.com]
id_provider = proxy
proxy_lib = nis
auth_provider = proxy
proxy_auth_target = nis_pam_proxy

Capítulo 10. OpenSSH

SSH (Secure Shell) is a protocol which facilitates secure communications between two systems using a client/server architecture and allows users to log into server host systems remotely. Unlike other remote communication protocols, such as FTP or Telnet, SSH encrypts the login session, rendering the connection difficult for intruders to collect unencrypted passwords.
The ssh program is designed to replace older, less secure terminal applications used to log into remote hosts, such as telnet or rsh. A related program called scp replaces older programs designed to copy files between hosts, such as rcp. Because these older applications do not encrypt passwords transmitted between the client and the server, avoid them whenever possible. Using secure methods to log into remote systems decreases the risks for both the client system and the remote host.
Fedora includes the general OpenSSH package (openssh) as well as the OpenSSH server (openssh-server) and client (openssh-clients) packages. Note that the OpenSSH packages require the OpenSSL package (openssl), which installs several important cryptographic libraries, enabling OpenSSH to provide encrypted communications.

10.1. The SSH Protocol

10.1.1. ¿Por qué usar SSH?

Potential intruders have a variety of tools at their disposal enabling them to disrupt, intercept, and re-route network traffic in an effort to gain access to a system. In general terms, these threats can be categorized as follows:
Interception of communication between two systems
The attacker can be somewhere on the network between the communicating parties, copying any information passed between them. He may intercept and keep the information, or alter the information and send it on to the intended recipient.
This attack is usually performed using a packet sniffer, a rather common network utility that captures each packet flowing through the network, and analyzes its content.
Impersonation of a particular host
Attacker's system is configured to pose as the intended recipient of a transmission. If this strategy works, the user's system remains unaware that it is communicating with the wrong host.
This attack can be performed using a technique known as DNS poisoning, or via so-called IP spoofing. In the first case, the intruder uses a cracked DNS server to point client systems to a maliciously duplicated host. In the second case, the intruder sends falsified network packets that appear to be from a trusted host.
Both techniques intercept potentially sensitive information and, if the interception is made for hostile reasons, the results can be disastrous. If SSH is used for remote shell login and file copying, these security threats can be greatly diminished. This is because the SSH client and server use digital signatures to verify their identity. Additionally, all communication between the client and server systems is encrypted. Attempts to spoof the identity of either side of a communication does not work, since each packet is encrypted using a key known only by the local and remote systems.

10.1.2. Main Features

El protocolo SSH proporciona los siguientes tipos de protección:
No one can pose as the intended server
Después de la conexión inicial, el cliente puede verificar que se está conectando al mismo servidor al que se conectó anteriormente.
No one can capture the authentication information
El cliente transmite su información de autenticación al servidor usando una encriptación robusta de 128 bits.
No one can intercept the communication
Todos los datos enviados y recibidos durante la sesión se transfieren por medio de encriptación de 128 bits, lo cual los hacen extremadamente difícil de descifrar y leer.
Additionally, it also offers the following options:
It provides secure means to use graphical applications over a network
Using a technique called X11 forwarding, the client can forward X11 (X Window System) applications from the server.
It provides a way to secure otherwise insecure protocols
The SSH protocol encrypts everything it sends and receives. Using a technique called port forwarding, an SSH server can become a conduit to securing otherwise insecure protocols, like POP, and increasing overall system and data security.
It can be used to create a secure channel
The OpenSSH server and client can be configured to create a tunnel similar to a virtual private network for traffic between server and client machines.
It supports the Kerberos authentication
OpenSSH servers and clients can be configured to authenticate using the GSSAPI (Generic Security Services Application Program Interface) implementation of the Kerberos network authentication protocol.

10.1.3. Protocol Versions

Two varieties of SSH currently exist: version 1, and newer version 2. The OpenSSH suite under Fedora uses SSH version 2, which has an enhanced key exchange algorithm not vulnerable to the known exploit in version 1. However, for compatibility reasons, the OpenSSH suite does support version 1 connections as well.

Avoid using SSH version 1

To ensure maximum security for your connection, it is recommended that only SSH version 2-compatible servers and clients are used whenever possible.

10.1.4. Secuencia de eventos de una conexión SSH

La siguiente serie de eventos lo ayudan a proteger la integridad de la comunicación SSH entre dos host.
  1. Se lleva a cabo un "apretón de manos" encriptado para que el cliente pueda verificar que se está comunicando con el servidor correcto.
  2. La capa de transporte de la conexión entre el cliente y la máquina remota es encriptada mediante un código simétrico.
  3. El cliente se autentica ante el servidor.
  4. El cliente remoto interactúa con la máquina remota a través de la conexión encriptada.

10.1.4.1. Capa de transporte

El papel principal de la capa de transporte es facilitar una comunicación segura entre los dos hosts durante la autenticación y la subsecuente comunicación. La capa de transporte lleva a cabo esta tarea manejando la encriptación y decodificación de datos y proporcionando protección de integridad de los paquetes de datos mientras son enviados y recibidos. La capa de transporte proporciona compresión de datos, lo que acelera la transmisión de la información.
Al contactar un cliente a un servidor por medio del protocolo SSH se negocian varios puntos importantes para que ambos sistemas puedan construir la capa de transporte correctamente. Durante el intercambio se producen los siguientes pasos:
  • Intercambio de claves
  • Se determina el algoritmo de encriptación de la clave pública
  • Se determina el algoritmo de la encriptación simétrica
  • Se determina el algoritmo autenticación de mensajes
  • Se determina el algoritmo del hash
El servidor se identifica ante el cliente con una llave de host única durante el intercambio de llaves. Obviamente, si este cliente nunca se había comunicado antes con este determinado servidor, la llave del servidor le resultará desconocida al cliente y no lo conectará. OpenSSH evita este problema permitiendo que el cliente acepte la llave del host del servidor después de que el usuario es notificado y verifica la aceptación de la nueva llave del host. Para las conexiones posteriores, la llave del host del servidor se puede verificar con la versión guardada en el cliente, proporcionando la confianza de que el cliente se está comunicando con el servidor deseado. Si en el futuro, la llave del host ya no coincide, el usuario debe eliminar la versión guardada antes de que una conexión pueda ocurrir.

Always verify the integrity of a new SSH server

Un atacante podría enmascararse como servidor SSH durante el contacto inicial ya que el sistema local no conoce la diferencia entre el servidor en cuestión y el servidor falso configurado por un agresor. Para evitar que esto ocurra, debería verificar la integridad del nuevo servidor SSH contactando con el administrador del servidor antes de conectarse por primera vez o en el evento de que no coincidan las claves.
SSH fue ideado para funcionar con casi cualquier tipo de algoritmo de clave pública o formato de codificación. Después del intercambio de claves inicial se crea un valor hash usado para el intercambio y un valor compartido secreto, los dos sistemas empiezan inmediatamente a calcular claves y algoritmos nuevos para proteger la autenticación y los datos que se enviarán a través de la conexión en el futuro.
Después de que una cierta cantidad de datos haya sido transmitida con un determinado algoritmo y clave (la cantidad exacta depende de la implementación de SSH), ocurre otro intercambio de claves, el cual genera otro conjunto de valores de hash y un nuevo valor secreto compartido. De esta manera aunque un agresor lograse determinar los valores de hash y de secreto compartido, esta información sólo será válida por un periodo de tiempo limitado.

10.1.4.2. Autenticación

Cuando la capa de transporte haya construido un túnel seguro para transmitir información entre los dos sistemas, el servidor le dirá al cliente de los diferentes métodos de autenticación soportados, tales como el uso de firmas privadas codificadas con claves o la inserción de una contraseña. El cliente entonces intentará autenticarse ante el servidor mediante el uso de cualquiera de los métodos soportados.
Los servidores y clientes SSH se pueden configurar para permitir varios tipos de autenticación, lo cual le concede a cada lado la cantidad óptima de control. El servidor podrá decidir qué métodos de encriptación soportará basado en su pauta de seguridad; el cliente puede elegir el orden en que intentará utilizar los métodos de autenticación entre las opciones a disposición.

10.1.4.3. Canales

After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called multiplexing[2]. Each of these channels handles communication for different terminal sessions and for forwarded X11 sessions.
Ambos clientes y servidores pueden crear un canal nuevo. Luego se le asigna un número diferente a cada canal en cada punta de la conexión. Cuando el cliente intenta abrir un nuevo canal, los clientes envían el número del canal junto con la petición. Esta información es almacenada por el servidor y usada para dirigir la comunicación a ese canal. Esto es hecho para que diferentes tipos de sesión no afecten una a la otra y así cuando una sesión termine, su canal pueda ser cerrado sin interrumpir la conexión SSH primaria.
Los canales también soportan el control de flujo, el cual les permite enviar y recibir datos ordenadamente. De esta manera, los datos no se envían a través del canal sino hasta que el host haya recibido un mensaje avisando que el canal está abierto y puede recibirlos.
El cliente y el servidor negocian las características de cada canal automáticamente, dependiendo del tipo de servicio que el cliente solicita y la forma en que el usuario está conectado a la red. Esto otorga una gran flexibilidad en el manejo de diferentes tipos de conexiones remotas sin tener que cambiar la infraestructura básica del protocolo.

10.2. An OpenSSH Configuration

In order to perform tasks described in this section, you must have superuser privileges. To obtain them, log in as root by typing:
su -

10.2.1. Archivos de configuración

There are two different sets of configuration files: those for client programs (that is, ssh, scp, and sftp), and those for the server (the sshd daemon).
System-wide SSH configuration information is stored in the /etc/ssh/ directory. See Tabla 10.1, “System-wide configuration files” for a description of its content.
Tabla 10.1. System-wide configuration files
Archivo de configuración Descripción
/etc/ssh/moduli Contains Diffie-Hellman groups used for the Diffie-Hellman key exchange which is critical for constructing a secure transport layer. When keys are exchanged at the beginning of an SSH session, a shared, secret value is created which cannot be determined by either party alone. This value is then used to provide host authentication.
/etc/ssh/ssh_config The default SSH client configuration file. Note that it is overridden by ~/.ssh/config if it exists.
/etc/ssh/sshd_config The configuration file for the sshd daemon.
/etc/ssh/ssh_host_dsa_key The DSA private key used by the sshd daemon.
/etc/ssh/ssh_host_dsa_key.pub The DSA public key used by the sshd daemon.
/etc/ssh/ssh_host_key The RSA private key used by the sshd daemon for version 1 of the SSH protocol.
/etc/ssh/ssh_host_key.pub The RSA public key used by the sshd daemon for version 1 of the SSH protocol.
/etc/ssh/ssh_host_rsa_key The RSA private key used by the sshd daemon for version 2 of the SSH protocol.
/etc/ssh/ssh_host_rsa_key.pub The RSA public key used by the sshd for version 2 of the SSH protocol.

User-specific SSH configuration information is stored in the user's home directory within the ~/.ssh/ directory. See Tabla 10.2, “User-specific configuration files” for a description of its content.
Tabla 10.2. User-specific configuration files
Archivo de configuración Descripción
~/.ssh/authorized_keys Holds a list of authorized public keys for servers. When the client connects to a server, the server authenticates the client by checking its signed public key stored within this file.
~/.ssh/id_dsa Contains the DSA private key of the user.
~/.ssh/id_dsa.pub The DSA public key of the user.
~/.ssh/id_rsa The RSA private key used by ssh for version 2 of the SSH protocol.
~/.ssh/id_rsa.pub The RSA public key used by ssh for version 2 of the SSH protocol
~/.ssh/identity The RSA private key used by ssh for version 1 of the SSH protocol.
~/.ssh/identity.pub The RSA public key used by ssh for version 1 of the SSH protocol.
~/.ssh/known_hosts Contains DSA host keys of SSH servers accessed by the user. This file is very important for ensuring that the SSH client is connecting the correct SSH server.

Refer to the ssh_config and sshd_config man pages for information concerning the various directives available in the SSH configuration files.

10.2.2. Starting an OpenSSH Server

Make sure you have relevant packages installed

To run an OpenSSH server, you must have the openssh-server and openssh packages installed. Refer to Sección 4.2.4, “Installing Packages” for more information on how to install new packages in Fedora.
To start the sshd daemon, type the following at a shell prompt:
systemctl start sshd.service
To stop the running sshd daemon, use the following command:
systemctl stop sshd.service
If you want the daemon to start automatically at the boot time, type:
systemctl enable sshd.service
Refer to Capítulo 8, Services and Daemons for more information on how to configure services in Fedora.
Note that if you reinstall the system, a new set of identification keys will be created. As a result, clients who had connected to the system with any of the OpenSSH tools before the reinstall will see the following message:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
To prevent this, you can back up the relevant files from the /etc/ssh/ directory (see Tabla 10.1, “System-wide configuration files” for a complete list), and restore them whenever you reinstall the system.

10.2.3. Requiriendo SSH para conexiones remotas

For SSH to be truly effective, using insecure connection protocols should be prohibited. Otherwise, a user's password may be protected using SSH for one session, only to be captured later while logging in using Telnet. Some services to disable include telnet, rsh, rlogin, and vsftpd.
To make sure these services are not running, type the following commands at a shell prompt:
systemctl stop telnet.service
systemctl stop rsh.service
systemctl stop rlogin.service
systemctl stop vsftpd.service
To disable running these services at startup, type:
systemctl disable telnet.service
systemctl disable rsh.service
systemctl disable rlogin.service
systemctl disable vsftpd.service
Refer to Capítulo 8, Services and Daemons for more information on how to configure services in Fedora.

10.2.4. Using a Key-Based Authentication

To improve the system security even further, you can enforce the key-based authentication by disabling the standard password authentication. To do so, open the /etc/ssh/sshd_config configuration file in a text editor, and change the PasswordAuthentication option as follows:
PasswordAuthentication no
To be able to use ssh, scp, or sftp to connect to the server from a client machine, generate an authorization key pair by following the steps below. Note that keys must be generated for each user separately.
Fedora 17 uses SSH Protocol 2 and RSA keys by default (see Sección 10.1.3, “Protocol Versions” for more information).

Do not generate key pairs as root

If you complete the steps as root, only root will be able to use the keys.

Backup your ~/.ssh/ directory

If you reinstall your system and want to keep previously generated key pair, backup the ~/.ssh/ directory. After reinstalling, copy it back to your home directory. This process can be done for all users on your system, including root.

10.2.4.1. Generar pares de claves

To generate an RSA key pair for version 2 of the SSH protocol, follow these steps:
  1. Generate an RSA key pair by typing the following at a shell prompt:
    ~]$ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/john/.ssh/id_rsa):
  2. Press Enter to confirm the default location (that is, ~/.ssh/id_rsa) for the newly created key.
  3. Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log in to your account.
    After this, you will be presented with a message similar to this:
    Your identification has been saved in /home/john/.ssh/id_rsa.
    Your public key has been saved in /home/john/.ssh/id_rsa.pub.
    The key fingerprint is:
    e7:97:c7:e2:0e:f9:0e:fc:c4:d7:cb:e5:31:11:92:14 john@penguin.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |             E.  |
    |            . .  |
    |             o . |
    |              . .|
    |        S .    . |
    |         + o o ..|
    |          * * +oo|
    |           O +..=|
    |           o*  o.|
    +-----------------+
  4. Change the permissions of the ~/.ssh/ directory:
    ~]$ chmod 755 ~/.ssh
  5. Copy the content of ~/.ssh/id_rsa.pub into the ~/.ssh/authorized_keys on the machine to which you want to connect, appending it to its end if the file already exists.
  6. Change the permissions of the ~/.ssh/authorized_keys file using the following command:
    ~]$ chmod 644 ~/.ssh/authorized_keys
To generate a DSA key pair for version 2 of the SSH protocol, follow these steps:
  1. Generate a DSA key pair by typing the following at a shell prompt:
    ~]$ ssh-keygen -t dsa
    Generating public/private dsa key pair.
    Enter file in which to save the key (/home/john/.ssh/id_dsa):
  2. Press Enter to confirm the default location (that is, ~/.ssh/id_dsa) for the newly created key.
  3. Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log in to your account.
    After this, you will be presented with a message similar to this:
    Your identification has been saved in /home/john/.ssh/id_dsa.
    Your public key has been saved in /home/john/.ssh/id_dsa.pub.
    The key fingerprint is:
    81:a1:91:a8:9f:e8:c5:66:0d:54:f5:90:cc:bc:cc:27 john@penguin.example.com
    The key's randomart image is:
    +--[ DSA 1024]----+
    |   .oo*o.        |
    |  ...o Bo        |
    | .. . + o.       |
    |.  .   E o       |
    | o..o   S        |
    |. o= .           |
    |. +              |
    | .               |
    |                 |
    +-----------------+
  4. Change the permissions of the ~/.ssh/ directory:
    ~]$ chmod 775 ~/.ssh
  5. Copy the content of ~/.ssh/id_dsa.pub into the ~/.ssh/authorized_keys on the machine to which you want to connect, appending it to its end if the file already exists.
  6. Change the permissions of the ~/.ssh/authorized_keys file using the following command:
    ~]$ chmod 644 ~/.ssh/authorized_keys
To generate an RSA key pair for version 1 of the SSH protocol, follow these steps:
  1. Generate an RSA key pair by typing the following at a shell prompt:
    ~]$ ssh-keygen -t rsa1
    Generating public/private rsa1 key pair.
    Enter file in which to save the key (/home/john/.ssh/identity):
  2. Press Enter to confirm the default location (that is, ~/.ssh/identity) for the newly created key.
  3. Enter a passphrase, and confirm it by entering it again when prompted to do so. For security reasons, avoid using the same password as you use to log into your account.
    After this, you will be presented with a message similar to this:
    Your identification has been saved in /home/john/.ssh/identity.
    Your public key has been saved in /home/john/.ssh/identity.pub.
    The key fingerprint is:
    cb:f6:d5:cb:6e:5f:2b:28:ac:17:0c:e4:62:e4:6f:59 john@penguin.example.com
    The key's randomart image is:
    +--[RSA1 2048]----+
    |                 |
    |     . .         |
    |    o o          |
    |     + o E       |
    |    . o S        |
    |       = +   .   |
    |      . = . o . .|
    |       . = o o..o|
    |       .o o  o=o.|
    +-----------------+
  4. Change the permissions of the ~/.ssh/ directory:
    ~]$ chmod 755 ~/.ssh
  5. Copy the content of ~/.ssh/identity.pub into the ~/.ssh/authorized_keys on the machine to which you want to connect, appending it to its end if the file already exists.
  6. Change the permissions of the ~/.ssh/authorized_keys file using the following command:
    ~]$ chmod 644 ~/.ssh/authorized_keys
Refer to Sección 10.2.4.2, “Configuring ssh-agent” for information on how to set up your system to remember the passphrase.

Never share your private key

The private key is for your personal use only, and it is important that you never give it to anyone.

10.2.4.2. Configuring ssh-agent

To store your passphrase so that you do not have to enter it each time you initiate a connection with a remote machine, you can use the ssh-agent authentication agent. To save your passphrase for a certain shell prompt, use the following command:
~]$ ssh-add
Enter passphrase for /home/john/.ssh/id_rsa:
Note that when you log out, your passphrase will be forgotten. You must execute the command each time you log in to a virtual console or a terminal window.

10.3. OpenSSH Clients

Make sure you have relevant packages installed

To connect to an OpenSSH server from a client machine, you must have the openssh-clients and openssh packages installed. Refer to Sección 4.2.4, “Installing Packages” for more information on how to install new packages in Fedora.

10.3.1. Using the ssh Utility

ssh allows you to log in to a remote machine and execute commands there. It is a secure replacement for the rlogin, rsh, and telnet programs.
Similarly to telnet, to log in to a remote machine named penguin.example.com, type the following command at a shell prompt:
~]$ ssh penguin.example.com
This will log you in with the same username you are using on a local machine. If you want to specify a different one, use a command in the ssh username@hostname form. For example, to log in as john, type:
~]$ ssh john@penguin.example.com
The first time you initiate a connection, you will be presented with a message similar to this:
The authenticity of host 'penguin.example.com' can't be established.
RSA key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c.
Are you sure you want to continue connecting (yes/no)?
Type yes to confirm. You will see a notice that the server has been added to the list of known hosts, and a prompt asking for your password:
Warning: Permanently added 'penguin.example.com' (RSA) to the list of known hosts.
john@penguin.example.com's password:

Updating the host key of an SSH server

If the SSH server's host key changes, the client notifies the user that the connection cannot proceed until the server's host key is deleted from the ~/.ssh/known_hosts file. To do so, open the file in a text editor, and remove a line containing the remote machine name at the beginning. Before doing this, however, contact the system administrator of the SSH server to verify the server is not compromised.
After entering the password, you will be provided with a shell prompt for the remote machine.
Alternatively, the ssh program can be used to execute a command on the remote machine without logging in to a shell prompt. The syntax for that is ssh [username@]hostname command. For example, if you want to execute the whoami command on penguin.example.com, type:
~]$ ssh john@penguin.example.com whoami
john@penguin.example.com's password:
john
After you enter the correct password, the username will be displayed, and you will return to your local shell prompt.

10.3.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:
scp localfile username@hostname:remotefile
For example, if you want to transfer taglist.vim to a remote machine named penguin.example.com, type the following at a shell prompt:
~]$ 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
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:
~]$ 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
To transfer a remote file to the local system, use the following syntax:
scp username@hostname:remotefile localfile
For instance, to download the .vimrc configuration file from the remote machine, type:
~]$ scp john@penguin.example.com:.vimrc .vimrc
john@penguin.example.com's password:
.vimrc                                        100% 2233     2.2KB/s   00:00

10.3.3. Using the sftp Utility

The sftp utility can be used to open a secure, interactive FTP session. In its design, it is similar to ftp except that it uses a secure, encrypted connection.
To connect to a remote system, use a command in the following form:
sftp username@hostname
For example, to log in to a remote machine named penguin.example.com with john as a username, type:
~]$ sftp john@penguin.example.com
john@penguin.example.com's password:
Connected to penguin.example.com.
sftp>
After you enter the correct password, you will be presented with a prompt. The sftp utility accepts a set of commands similar to those used by ftp (see Tabla 10.3, “A selection of available sftp commands”).
Tabla 10.3. A selection of available sftp commands
Comando Descripción
ls [directory] List the content of a remote directory. If none is supplied, a current working directory is used by default.
cd directory Change the remote working directory to directory.
mkdir directory Create a remote directory.
rmdir path Remove a remote directory.
put localfile [remotefile] Transfer localfile to a remote machine.
get remotefile [localfile] Transfer remotefile from a remote machine.

For a complete list of available commands, refer to the sftp man page.

10.4. Más que un Shell seguro

Una interfaz de línea de comandos segura es sólo el inicio de las muchas maneras de usar SSH. Dada una cantidad apropiada de ancho de banda, las sesiones X11 se pueden dirigir por un canal SSH. O usando reenvío TCP/IP, se pueden asignar conexiones de puerto entre sistemas que previamente eran inseguras a canales SSH específicos.

10.4.1. Reenvío por X11

To open an X11 session over an SSH connection, use a command in the following form:
ssh -Y username@hostname
For example, to log in to a remote machine named penguin.example.com with john as a username, type:
~]$ ssh -Y john@penguin.example.com
john@penguin.example.com's password:
Cuando un programa X se ejecuta desde un intérprete de comandos de shell segura, el cliente y el servidor SSH crean un nuevo canal seguro; los datos del programa X se envían a través de ese canal a la máquina cliente de forma transparente.
X11 forwarding can be very useful. For example, X11 forwarding can be used to create a secure, interactive session of the Printer Configuration utility. To do this, connect to the server using ssh and type:
~]$ system-config-printer &
The Printer Configuration Tool will appear, allowing the remote user to safely configure printing on the remote system.

10.4.2. Reenvío del puerto

SSH can secure otherwise insecure TCP/IP protocols via port forwarding. When using this technique, the SSH server becomes an encrypted conduit to the SSH client.
Port forwarding works by mapping a local port on the client to a remote port on the server. SSH can map any port from the server to any port on the client. Port numbers do not need to match for this technique to work.

Using reserved port numbers

La configuración del reenvío de puertos para escuchar puertos bajo 1024 requiere acceso de root.
To create a TCP/IP port forwarding channel which listens for connections on the localhost, use a command in the following form:
ssh -L local-port:remote-hostname:remote-port username@hostname
For example, to check email on a server called mail.example.com using POP3 through an encrypted connection, use the following command:
~]$ ssh -L 1100:mail.example.com:110 mail.example.com
Once the port forwarding channel is in place between the client machine and the mail server, direct a POP3 mail client to use port 1100 on the localhost to check for new email. Any requests sent to port 1100 on the client system will be directed securely to the mail.example.com server.
If mail.example.com is not running an SSH server, but another machine on the same network is, SSH can still be used to secure part of the connection. However, a slightly different command is necessary:
~]$ ssh -L 1100:mail.example.com:110 other.example.com
In this example, POP3 requests from port 1100 on the client machine are forwarded through the SSH connection on port 22 to the SSH server, other.example.com. Then, other.example.com connects to port 110 on mail.example.com to check for new email. Note that when using this technique, only the connection between the client system and other.example.com SSH server is secure.
Port forwarding can also be used to get information securely through network firewalls. If the firewall is configured to allow SSH traffic via its standard port (that is, port 22) but blocks access to other ports, a connection between two hosts using the blocked ports is still possible by redirecting their communication over an established SSH connection.

A connection is only as secure as a client system

Si se utiliza el reenvío de puerto para reenviar conexiones de este modo, cualquier usuario en el sistema cliente puede conectarse a ese servicio. Si el cliente está en riesgo o está comprometido, un agresor puede también acceder a los servicios reenviados.
System administrators concerned about port forwarding can disable this functionality on the server by specifying a No parameter for the AllowTcpForwarding line in /etc/ssh/sshd_config and restarting the sshd service.

10.5. Recursos adicionales

Los proyectos OpenSSH y OpenSSL están en constante desarrollo. La información más actualizada está disponible desde sus sitios web. Las páginas de manuales para las herramientas OpenSSH y OpenSSL también son una buena fuente de información detallada.

10.5.1. Documentación instalada

man ssh
The manual page for ssh containing the full documentation on its usage.
man scp
The manual page for scp containing the full documentation on its usage.
man sftp
The manual page for sftp containing the full documentation on its usage.
man sshd
The manual page for sshd containing the full documentation on its usage.
man ssh-keygen
The manual page for ssh-keygen containing the full documentation on its usage.
man ssh_config
The manual page with full description of available SSH client configuration options.
man sshd_config
The manual page with full description of available SSH daemon configuration options.

10.5.2. Sitios Web útiles

http://www.openssh.com/
The OpenSSH home page containing further documentation, frequently asked questions, links to the mailing lists, bug reports, and other useful resources.
http://www.openssl.org/
The OpenSSL home page containing further documentation, frequently asked questions, links to the mailing lists, and other useful resources.
http://www.freesshd.com/
Another implementation of an SSH server.


[2] A multiplexed connection consists of several signals being sent over a shared, common medium. With SSH, different channels are sent over a common secure connection.

Parte V. Servidores

Este apartado trata varios temas relacionados con servidores como la puesta a punto de un servidor web o la compartición de ficheros en una red.

Tabla de contenidos

11. DHCP Servers
11.1. Motivos para usar el protocolo DHCP
11.2. Configuración de un servidor DHCP
11.2.1. Archivo de configuración
11.2.2. Base de datos de arrendamiento
11.2.3. Iniciar y detener el servidor
11.2.4. Agente de transmisión DHCP
11.3. Configuración de un cliente DHCP
11.4. Configuring a Multihomed DHCP Server
11.4.1. Host Configuration
11.5. DHCP for IPv6 (DHCPv6)
11.6. Recursos adicionales
11.6.1. Documentación instalada
12. DNS Servers
12.1. Introducción a DNS
12.1.1. Zonas de servidores de nombres
12.1.2. Tipos de servidores de nombres
12.1.3. BIND as a Nameserver
12.2. BIND
12.2.1. Configuring the named Service
12.2.2. Editing Zone Files
12.2.3. Using the rndc Utility
12.2.4. Using the dig Utility
12.2.5. Características avanzadas de BIND
12.2.6. Errores comunes que debe evitar
12.2.7. Recursos adicionales
13. Servidores web
13.1. The Apache HTTP Server
13.1.1. New Features
13.1.2. Notable Changes
13.1.3. Updating the Configuration
13.1.4. Running the httpd Service
13.1.5. Editing the Configuration Files
13.1.6. Working with Modules
13.1.7. Setting Up Virtual Hosts
13.1.8. Setting Up an SSL Server
13.1.9. Recursos adicionales
14. Mail Servers
14.1. Protocolos de correo electrónico
14.1.1. Protocolos de transporte de correo
14.1.2. Protocolos de acceso a correo
14.2. Clasificaciones de los programas de correo
14.2.1. Mail Transport Agent
14.2.2. Mail Delivery Agent
14.2.3. Mail User Agent
14.3. Agentes de transporte de correo
14.3.1. Postfix
14.3.2. Sendmail
14.3.3. Fetchmail
14.3.4. Configuración del Agente de Transporte de Correo (MTA)
14.4. Agente de entrega de correo
14.4.1. Configuración de Procmail
14.4.2. Recetas de Procmail
14.5. Agentes de usuario de correo
14.5.1. Comunicación segura
14.6. Recursos adicionales
14.6.1. Documentación instalada
14.6.2. Sitios Web útiles
14.6.3. Libros relacionados
15. Servidores de directorio
15.1. OpenLDAP
15.1.1. Introduction to LDAP
15.1.2. Installing the OpenLDAP Suite
15.1.3. Configuring an OpenLDAP Server
15.1.4. Running an OpenLDAP Server
15.1.5. Configurar un sistema para la autenticación mediante OpenLDAP
15.1.6. Recursos adicionales
16. Servidores de archivos e impresoras
16.1. Samba
16.1.1. Introducción a Samba
16.1.2. Demonios Samba y Servicios relacionados
16.1.3. Conexión a un recurso compartido Samba
16.1.4. Configuración del servidor Samba
16.1.5. Arrancar y detener el Samba
16.1.6. Samba Server Types and the smb.conf File
16.1.7. Modos de seguridad Samba
16.1.8. Bases de datos de información de cuentas Samba
16.1.9. Navegación de red con Samba
16.1.10. Samba con soporte para la impresión con CUPS
16.1.11. Programas de distribución Samba
16.1.12. Recursos adicionales
16.2. FTP
16.2.1. El Protocolo de Transferencia de Archivo
16.2.2. Servidores FTP
16.2.3. Archivos instalados con vsftpd
16.2.4. Iniciar y Detener vsftpd
16.2.5. vsftpd Opciones de configuracion
16.2.6. Recursos adicionales
16.3. Configuración de la impresora
16.3.1. Iniciando la herramienta de configuración de impresora
16.3.2. Iniciando ajustes de impresora
16.3.3. Añadir una impresora local
16.3.4. Agregando una impresora AppSocket/HP JetDirect
16.3.5. Añadir una impresora de red IPP
16.3.6. Agregando una impresora o equipo LPD/LPR
16.3.7. Adding a Samba (SMB) printer
16.3.8. Selección del modelo de impresora
16.3.9. Printing a test page
16.3.10. Modificar impresoras existentes
16.3.11. Recursos adicionales

Capítulo 11. DHCP Servers

DHCP (Dynamic Host Configuration Protocol) es un protocolo de red para asignar automáticamente información TCP/IP a equipos cliente. Cada cliente DHCP se conecta a un servidor DHCP centralizado que devuelve la configuración de red del cliente (incluyendo la dirección IP, la puerta de enlace y los servidores DNS).

11.1. Motivos para usar el protocolo DHCP

DHCP es útil para proporcionar de un modo rápido la configuración de la interfaz de red del cliente. Al configurar el sistema cliente, el administrador puede seleccionar el protocolo DHCP y no especificar una dirección IP, una máscara de red, una puerta de enlace o servidores DNS. El cliente recupera esta información desde el servidor DHCP. DHCP también es útil si un administrador desea cambiar las direcciones IP de muchos sistemas. En lugar de volver a configurar todos los sistemas, puede modificar un archivo de configuración DHCP en el servidor para establecer el nuevo conjunto de direcciones IP. Si los servidores DNS de una organización cambian, los cambios son hechos en el servidor DHCP, no en los clientes DHCP. Una vez que se reinicie la red en los clientes (o se reinicien los clientes), se aplicarán los cambios.
Si una organización tiene un servidor DHCP funcional conectado correctamente a una red, los usuarios de portátiles pueden mover estas máquinas de oficina a oficina.

11.2. Configuración de un servidor DHCP

The dhcp package contains an ISC DHCP server. First, install the package as root:
yum install dhcp
Installing the dhcp package creates a file, /etc/dhcp/dhcpd.conf, which is merely an empty configuration file:
#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#   see dhcpd.conf(5) man page
#
The sample configuration file can be found at /usr/share/doc/dhcp-version/dhcpd.conf.sample. You should use this file to help you configure /etc/dhcp/dhcpd.conf, which is explained in detail below.
DHCP also uses the file /var/lib/dhcpd/dhcpd.leases to store the client lease database. Refer to Sección 11.2.2, “Base de datos de arrendamiento” for more information.

11.2.1. Archivo de configuración

The first step in configuring a DHCP server is to create the configuration file that stores the network information for the clients. Use this file to declare options and global options for client systems.
The configuration file can contain extra tabs or blank lines for easier formatting. Keywords are case-insensitive and lines beginning with a hash sign (#) are considered comments.
El archivo de configuración posee dos tipos de información:
  • Parameters — State how to perform a task, whether to perform a task, or what network configuration options to send to the client.
  • Declarations — Describe the topology of the network, describe the clients, provide addresses for the clients, or apply a group of parameters to a group of declarations.
The parameters that start with the keyword option are referred to as options. These options control DHCP options; whereas, parameters configure values that are not optional or control how the DHCP server behaves.
Los parámetros (incluidas las opciones) declarados antes de una sección encerrada entre paréntesis ({ }) se consideran parámetros globales. Los parámetros globales se aplican a todas las secciones situadas debajo de ellos.

Restart the DHCP daemon for the changes to take effect

If the configuration file is changed, the changes do not take effect until the DHCP daemon is restarted. To do so, type the following at a shell prompt as root:
systemctl restart dhcpd.service

Use the omshell command

Instead of changing a DHCP configuration file and restarting the service each time, using the omshell command provides an interactive way to connect to, query, and change the configuration of a DHCP server. By using omshell, all changes can be made while the server is running. For more information on omshell, refer to the omshell man page.
In Ejemplo 11.1, “Subnet declaration”, the routers, subnet-mask, domain-search, domain-name-servers, and time-offset options are used for any host statements declared below it.
Additionally, a subnet can be declared, a subnet declaration must be included for every subnet in the network. If it is not, the DHCP server fails to start.
In this example, there are global options for every DHCP client in the subnet and a range declared. Clients are assigned an IP address within the range.
Ejemplo 11.1. Subnet declaration
subnet 192.168.1.0 netmask 255.255.255.0 {
        option routers                  192.168.1.254;
        option subnet-mask              255.255.255.0;
        option domain-search              "example.com";
        option domain-name-servers       192.168.1.1;
        option time-offset              -18000;     # Eastern Standard Time
	range 192.168.1.10 192.168.1.100;
}

To configure a DHCP server that leases a dynamic IP address to a system within a subnet, modify Ejemplo 11.2, “Range parameter” with your values. It declares a default lease time, maximum lease time, and network configuration values for the clients. This example assigns IP addresses in the range 192.168.1.10 and 192.168.1.100 to client systems.
Ejemplo 11.2. Range parameter
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-search "example.com";
subnet 192.168.1.0 netmask 255.255.255.0 {
   range 192.168.1.10 192.168.1.100;
}

To assign an IP address to a client based on the MAC address of the network interface card, use the hardware ethernet parameter within a host declaration. As demonstrated in Ejemplo 11.3, “Static IP address using DHCP”, the host apex declaration specifies that the network interface card with the MAC address 00:A0:78:8E:9E:AA always receives the IP address 192.168.1.4.
Note that the optional parameter host-name can also be used to assign a host name to the client.
Ejemplo 11.3. Static IP address using DHCP
host apex {
   option host-name "apex.example.com";
   hardware ethernet 00:A0:78:8E:9E:AA;
   fixed-address 192.168.1.4;
}

All subnets that share the same physical network should be declared within a shared-network declaration as shown in Ejemplo 11.4, “Shared-network declaration”. Parameters within the shared-network, but outside the enclosed subnet declarations, are considered to be global parameters. The name of the shared-network must be a descriptive title for the network, such as using the title 'test-lab' to describe all the subnets in a test lab environment.
Ejemplo 11.4. Shared-network declaration
shared-network name {
    option domain-search              "test.redhat.com";
    option domain-name-servers      ns1.redhat.com, ns2.redhat.com;
    option routers                  192.168.0.254;
    more parameters for EXAMPLE shared-network
    subnet 192.168.1.0 netmask 255.255.252.0 {
        parameters for subnet
        range 192.168.1.1 192.168.1.254;
    }
    subnet 192.168.2.0 netmask 255.255.252.0 {
        parameters for subnet
        range 192.168.2.1 192.168.2.254;
    }
}

As demonstrated in Ejemplo 11.5, “Group declaration”, the group declaration is used to apply global parameters to a group of declarations. For example, shared networks, subnets, and hosts can be grouped.
Ejemplo 11.5. Group declaration
group {
   option routers                  192.168.1.254;
   option subnet-mask              255.255.255.0;
   option domain-search              "example.com";
   option domain-name-servers       192.168.1.1;
   option time-offset              -18000;     # Eastern Standard Time
   host apex {
      option host-name "apex.example.com";
      hardware ethernet 00:A0:78:8E:9E:AA;
      fixed-address 192.168.1.4;
   }
   host raleigh {
      option host-name "raleigh.example.com";
      hardware ethernet 00:A1:DD:74:C3:F2;
      fixed-address 192.168.1.6;
   }
}

Using the sample configuration file

The sample configuration file provided can be used as a starting point and custom configuration options can be added to it. To copy it to the proper location, use the following command:
cp /usr/share/doc/dhcp-version-number/dhcpd.conf.sample /etc/dhcp/dhcpd.conf
... where version-number is the DHCP version number.
For a complete list of option statements and what they do, refer to the dhcp-options man page.

11.2.2. Base de datos de arrendamiento

On the DHCP server, the file /var/lib/dhcpd/dhcpd.leases stores the DHCP client lease database. Do not change this file. DHCP lease information for each recently assigned IP address is automatically stored in the lease database. The information includes the length of the lease, to whom the IP address has been assigned, the start and end dates for the lease, and the MAC address of the network interface card that was used to retrieve the lease.
Todas las horas de la base de datos de arrendamiento se expresan según el Tiempo Universal Coordinado (UTC por sus siglas en inglés), no con la hora local.
The lease database is recreated from time to time so that it is not too large. First, all known leases are saved in a temporary lease database. The dhcpd.leases file is renamed dhcpd.leases~ and the temporary lease database is written to dhcpd.leases.
The DHCP daemon could be killed or the system could crash after the lease database has been renamed to the backup file but before the new file has been written. If this happens, the dhcpd.leases file does not exist, but it is required to start the service. Do not create a new lease file. If you do, all old leases are lost which causes many problems. The correct solution is to rename the dhcpd.leases~ backup file to dhcpd.leases and then start the daemon.

11.2.3. Iniciar y detener el servidor

Starting the DHCP server for the first time

When the DHCP server is started for the first time, it fails unless the dhcpd.leases file exists. Use the command touch /var/lib/dhcpd/dhcpd.leases to create the file if it does not exist.
If the same server is also running BIND as a DNS server, this step is not necessary, as starting the named service automatically checks for a dhcpd.leases file.
To start the DHCP service, use the following command:
systemctl start dhcpd.service
To stop the DHCP server, type:
systemctl stop dhcpd.service
By default, the DHCP service does not start at boot time. To configure the daemon to start automatically at boot time, run:
systemctl enable dhcpd.service
Refer to Capítulo 8, Services and Daemons for more information on how to configure services in Fedora.
If more than one network interface is attached to the system, but the DHCP server should only be started on one of the interfaces, configure the DHCP server to start only on that device. In /etc/sysconfig/dhcpd, add the name of the interface to the list of DHCPDARGS:
# Command line options here
DHCPDARGS=eth0
Esto es útil si tiene una máquina cortafuegos con dos tarjetas de red. Se puede configurar una tarjeta de red como cliente DHCP para recuperar una dirección IP en Internet y la otra tarjeta de red puede utilizarse como servidor DHCP para la red interna detrás del cortafuegos. Su sistema será más seguro si sólo especifica la tarjeta de red conectada a la red interna ya que los usuarios no pueden conectarse al demonio vía Internet.
Other command line options that can be specified in /etc/sysconfig/dhcpd include:
  • -p portnum — Specifies the UDP port number on which dhcpd should listen. The default is port 67. The DHCP server transmits responses to the DHCP clients at a port number one greater than the UDP port specified. For example, if the default port 67 is used, the server listens on port 67 for requests and responses to the client on port 68. If a port is specified here and the DHCP relay agent is used, the same port on which the DHCP relay agent should listen must be specified. Refer to Sección 11.2.4, “Agente de transmisión DHCP” for details.
  • -f — Runs the daemon as a foreground process. This is mostly used for debugging.
  • -d — Logs the DHCP server daemon to the standard error descriptor. This is mostly used for debugging. If this is not specified, the log is written to /var/log/messages.
  • -cf filename — Specifies the location of the configuration file. The default location is /etc/dhcp/dhcpd.conf.
  • -lf filename — Specifies the location of the lease database file. If a lease database file already exists, it is very important that the same file be used every time the DHCP server is started. It is strongly recommended that this option only be used for debugging purposes on non-production machines. The default location is /var/lib/dhcpd/dhcpd.leases.
  • -q — Do not print the entire copyright message when starting the daemon.

11.2.4. Agente de transmisión DHCP

The DHCP Relay Agent (dhcrelay) allows for the relay of DHCP and BOOTP requests from a subnet with no DHCP server on it to one or more DHCP servers on other subnets.
Cuando un cliente DHCP pide información, el agente de transmisión DHCP reenvía la petición a la lista de servidores DHCP especificada cuando se inicia el agente de transmisión DHCP. Cuando un servidor DHCP devuelve una respuesta, la respuesta puede ser broadcast o unicast en la red que ha enviado la petición original.
The DHCP Relay Agent listens for DHCP requests on all interfaces unless the interfaces are specified in /etc/sysconfig/dhcrelay with the INTERFACES directive.
To start the DHCP Relay Agent, use the following command:
systemctl start dhcrelay.service

11.3. Configuración de un cliente DHCP

To configure a DHCP client manually, modify the /etc/sysconfig/network file to enable networking and the configuration file for each network device in the /etc/sysconfig/network-scripts directory. In this directory, each device should have a configuration file named ifcfg-eth0, where eth0 is the network device name.
The /etc/sysconfig/network-scripts/ifcfg-eth0 file should contain the following lines:
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
Necesita un archivo de configuración para cada dispositivo que desee configurar para el uso de DHCP.
Otras opciones para el script de la red incluyen:
  • DHCP_HOSTNAME — Only use this option if the DHCP server requires the client to specify a hostname before receiving an IP address. (The DHCP server daemon in Fedora does not support this feature.)
  • PEERDNS=answer , where answer is one of the following:
    • yes — Modify /etc/resolv.conf with information from the server. If using DHCP, then yes is the default.
    • no — Do not modify /etc/resolv.conf.

Advanced configurations

For advanced configurations of client DHCP options such as protocol timing, lease requirements and requests, dynamic DNS support, aliases, as well as a wide variety of values to override, prepend, or append to client-side configurations, refer to the dhclient and dhclient.conf man pages.

11.4. Configuring a Multihomed DHCP Server

A multihomed DHCP server serves multiple networks, that is, multiple subnets. The examples in these sections detail how to configure a DHCP server to serve multiple networks, select which network interfaces to listen on, and how to define network settings for systems that move networks.
Before making any changes, back up the existing /etc/sysconfig/dhcpd and /etc/dhcp/dhcpd.conf files.
The DHCP daemon listens on all network interfaces unless otherwise specified. Use the /etc/sysconfig/dhcpd file to specify which network interfaces the DHCP daemon listens on. The following /etc/sysconfig/dhcpd example specifies that the DHCP daemon listens on the eth0 and eth1 interfaces:
DHCPDARGS="eth0 eth1";
If a system has three network interfaces cards -- eth0, eth1, and eth2 -- and it is only desired that the DHCP daemon listens on eth0, then only specify eth0 in /etc/sysconfig/dhcpd:
DHCPDARGS="eth0";
The following is a basic /etc/dhcp/dhcpd.conf file, for a server that has two network interfaces, eth0 in a 10.0.0.0/24 network, and eth1 in a 172.16.0.0/24 network. Multiple subnet declarations allow different settings to be defined for multiple networks:
default-lease-time 600;
max-lease-time 7200;
subnet 10.0.0.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option routers 10.0.0.1;
	range 10.0.0.5 10.0.0.15;
}
subnet 172.16.0.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option routers 172.16.0.1;
	range 172.16.0.5 172.16.0.15;
}
subnet 10.0.0.0 netmask 255.255.255.0;
A subnet declaration is required for every network your DHCP server is serving. Multiple subnets require multiple subnet declarations. If the DHCP server does not have a network interface in a range of a subnet declaration, the DHCP server does not serve that network.
If there is only one subnet declaration, and no network interfaces are in the range of that subnet, the DHCP daemon fails to start, and an error such as the following is logged to /var/log/messages:
dhcpd: No subnet declaration for eth0 (0.0.0.0).
dhcpd: ** Ignoring requests on eth0.  If this is not what
dhcpd:    you want, please write a subnet declaration
dhcpd:    in your dhcpd.conf file for the network segment
dhcpd:    to which interface eth1 is attached. **
dhcpd:
dhcpd:
dhcpd: Not configured to listen on any interfaces!
option subnet-mask 255.255.255.0;
The option subnet-mask option defines a subnet mask, and overrides the netmask value in the subnet declaration. In simple cases, the subnet and netmask values are the same.
option routers 10.0.0.1;
The option routers option defines the default gateway for the subnet. This is required for systems to reach internal networks on a different subnet, as well as external networks.
range 10.0.0.5 10.0.0.15;
The range option specifies the pool of available IP addresses. Systems are assigned an address from the range of specified IP addresses.
For further information, refer to the dhcpd.conf(5) man page.

Do not use alias interfaces

Alias interfaces are not supported by DHCP. If an alias interface is the only interface, in the only subnet specified in /etc/dhcp/dhcpd.conf, the DHCP daemon fails to start.

11.4.1. Host Configuration

Before making any changes, back up the existing /etc/sysconfig/dhcpd and /etc/dhcp/dhcpd.conf files.
Configuring a single system for multiple networks
The following /etc/dhcp/dhcpd.conf example creates two subnets, and configures an IP address for the same system, depending on which network it connects to:
default-lease-time 600;
max-lease-time 7200;
subnet 10.0.0.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option routers 10.0.0.1;
	range 10.0.0.5 10.0.0.15;
}
subnet 172.16.0.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option routers 172.16.0.1;
	range 172.16.0.5 172.16.0.15;
}
host example0 {
	hardware ethernet 00:1A:6B:6A:2E:0B;
	fixed-address 10.0.0.20;
}
host example1 {
	hardware ethernet 00:1A:6B:6A:2E:0B;
	fixed-address 172.16.0.20;
}
host example0
The host declaration defines specific parameters for a single system, such as an IP address. To configure specific parameters for multiple hosts, use multiple host declarations.
Most DHCP clients ignore the name in host declarations, and as such, this name can anything, as long as it is unique to other host declarations. To configure the same system for multiple networks, use a different name for each host declaration, otherwise the DHCP daemon fails to start. Systems are identified by the hardware ethernet option, not the name in the host declaration.
hardware ethernet 00:1A:6B:6A:2E:0B;
The hardware ethernet option identifies the system. To find this address, run the ip link command.
fixed-address 10.0.0.20;
The fixed-address option assigns a valid IP address to the system specified by the hardware ethernet option. This address must be outside the IP address pool specified with the range option.
If option statements do not end with a semicolon, the DHCP daemon fails to start, and an error such as the following is logged to /var/log/messages:
/etc/dhcp/dhcpd.conf line 20: semicolon expected.
dhcpd: }
dhcpd: ^
dhcpd: /etc/dhcp/dhcpd.conf line 38: unexpected end of file
dhcpd:
dhcpd: ^
dhcpd: Configuration file errors encountered -- exiting
Configuring systems with multiple network interfaces
The following host declarations configure a single system, that has multiple network interfaces, so that each interface receives the same IP address. This configuration will not work if both network interfaces are connected to the same network at the same time:
host interface0 {
	hardware ethernet 00:1a:6b:6a:2e:0b;
	fixed-address 10.0.0.18;
}
host interface1 {
	hardware ethernet 00:1A:6B:6A:27:3A;
	fixed-address 10.0.0.18;
}
For this example, interface0 is the first network interface, and interface1 is the second interface. The different hardware ethernet options identify each interface.
If such a system connects to another network, add more host declarations, remembering to:
  • assign a valid fixed-address for the network the host is connecting to.
  • make the name in the host declaration unique.
When a name given in a host declaration is not unique, the DHCP daemon fails to start, and an error such as the following is logged to /var/log/messages:
dhcpd: /etc/dhcp/dhcpd.conf line 31: host interface0: already exists
dhcpd: }
dhcpd: ^
dhcpd: Configuration file errors encountered -- exiting
This error was caused by having multiple host interface0 declarations defined in /etc/dhcp/dhcpd.conf.

11.5. DHCP for IPv6 (DHCPv6)

The ISC DHCP includes support for IPv6 (DHCPv6) since the 4.x release with a DHCPv6 server, client and relay agent functionality. The server, client and relay agents support both IPv4 and IPv6. However, the client and the server can only manage one protocol at a time — for dual support they must be started separately for IPv4 and IPv6.
The DHCPv6 server configuration file can be found at /etc/dhcp/dhcpd6.conf.
The sample server configuration file can be found at /usr/share/doc/dhcp-version/dhcpd6.conf.sample.
To start the DHCPv6 service, use the following command:
systemctl start dhcpd6.service
A simple DHCPv6 server configuration file can look like this:
subnet6 2001:db8:0:1::/64 {
        range6 2001:db8:0:1::129 2001:db8:0:1::254;
        option dhcp6.name-servers fec0:0:0:1::1;
        option dhcp6.domain-search "domain.example";
}

11.6. Recursos adicionales

For additional information, refer to The DHCP Handbook; Ralph Droms and Ted Lemon; 2003 or the following resources.

11.6.1. Documentación instalada

  • dhcpd man page — Describes how the DHCP daemon works.
  • dhcpd.conf man page — Explains how to configure the DHCP configuration file; includes some examples.
  • dhcpd.leases man page — Describes a persistent database of leases.
  • dhcp-options man page — Explains the syntax for declaring DHCP options in dhcpd.conf; includes some examples.
  • dhcrelay man page — Explains the DHCP Relay Agent and its configuration options.
  • /usr/share/doc/dhcp-version/ — Contains sample files, README files, and release notes for current versions of the DHCP service.

Capítulo 12. DNS Servers

DNS (Sistema de nombres de dominio), también conocidos como nameserver, es un sistema de red que asocia los nombres de las computadores con su dirección de IP. Para los usuarios, esto tiene una ventaja ya que se puede referir a una maquina por su nombre en lugar de tener que recordar su dirección numérica. Para un administrador de sistemas, usar el servidor de nombres le permite cambiar la dirección de IP de una dispositivo sin afectar las consultas basadas en el nombre, o decidir que maquinas pueden manejar estas consultas.

12.1. Introducción a DNS

El servidor de DNS se implimenta utilizando uno o mas servidores centralizados que son autoritarios para algunos dominios. Cuando un cliente requiere información de un servidor de nombre, el usualmente se conecta por el puerto 53. El servidor de nombre intenta resolver el nombre solicitado. Si el no posee una respuesta autoritaria, o no tiene la respuesta almacenada en su cache por una consulta anterior, el consulta otro servidor de nombre, llamando root nameservers, para determinar cual es servidor de nombre autoritario para el nombre consultado, luego consulta para obtener el nombre solicitado.

12.1.1. Zonas de servidores de nombres

In a DNS server such as BIND, all information is stored in basic data elements called resource records (RR). The resource record is usually a fully qualified domain name (FQDN) of a host, and is broken down into multiple sections organized into a tree-like hierarchy. This hierarchy consists of a main trunk, primary branches, secondary branches, and so on. The following is an example of a resource record:
bob.sales.example.com
Each level of the hierarchy is divided by a period (that is, .). In the example above, com defines the top-level domain, example its subdomain, and sales the subdomain of example. In this case, bob identifies a resource record that is part of the sales.example.com domain. With the exception of the part furthest to the left (that is, bob), each of these sections is called a zone and defines a specific namespace.
Zones are defined on authoritative nameservers through the use of zone files, which contain definitions of the resource records in each zone. Zone files are stored on primary nameservers (also called master nameservers), where changes are made to the files, and secondary nameservers (also called slave nameservers), which receive zone definitions from the primary nameservers. Both primary and secondary nameservers are authoritative for the zone and look the same to clients. Depending on the configuration, any nameserver can also serve as a primary or secondary server for multiple zones at the same time.

12.1.2. Tipos de servidores de nombres

There are two nameserver configuration types:
authoritative
Authoritative nameservers answer to resource records that are part of their zones only. This category includes both primary (master) and secondary (slave) nameservers.
recursive
Recursive nameservers offer resolution services, but they are not authoritative for any zone. Answers for all resolutions are cached in a memory for a fixed period of time, which is specified by the retrieved resource record.
Although a nameserver can be both authoritative and recursive at the same time, it is recommended not to combine the configuration types. To be able to perform their work, authoritative servers should be available to all clients all the time. On the other hand, since the recursive lookup takes far more time than authoritative responses, recursive servers should be available to a restricted number of clients only, otherwise they are prone to distributed denial of service (DDoS) attacks.

12.1.3. BIND as a Nameserver

BIND consists of a set of DNS-related programs. It contains a monolithic nameserver called named, an administration utility called rndc, and a debugging tool called dig. Refer to Capítulo 8, Services and Daemons for more information on how to configure services in Fedora.

12.2. BIND

Este capitulo cubre BIND (Berkeley Internet Name Domain), el servidor de DNS incluido en Fedora. Se enfoca en la estructura y la configuración de sus archivos, y describe como administrarlo tanto local como remoto.

12.2.1. Configuring the named Service

When the named service is started, it reads the configuration from the files as described in Tabla 12.1, “The named service configuration files”.
Tabla 12.1. The named service configuration files
Path Descripción
/etc/named.conf The main configuration file.
/etc/named/ An auxiliary directory for configuration files that are included in the main configuration file.

The configuration file consists of a collection of statements with nested options surrounded by opening and closing curly brackets (that is, { and }). Note that when editing the file, you have to be careful not to make any syntax error, otherwise the named service will not start. A typical /etc/named.conf file is organized as follows:
statement-1 ["statement-1-name"] [statement-1-class] {
  option-1;
  option-2;
  option-N;
};
statement-2 ["statement-2-name"] [statement-2-class] {
  option-1;
  option-2;
  option-N;
};
statement-N ["statement-N-name"] [statement-N-class] {
  option-1;
  option-2;
  option-N;
};

Running BIND in a chroot environment

If you have installed the bind-chroot package, the BIND service will run in the /var/named/chroot environment. In that case, the initialization script will mount the above configuration files using the mount --bind command, so that you can manage the configuration outside this environment.

12.2.1.1. Tipos de declaraciones comúnes

The following types of statements are commonly used in /etc/named.conf:
acl
The acl (Access Control List) statement allows you to define groups of hosts, so that they can be permitted or denied access to the nameserver. It takes the following form:
acl acl-name {
  match-element;
  ...
};
The acl-name statement name is the name of the access control list, and the match-element option is usually an individual IP address (such as 10.0.1.1) or a CIDR network notation (for example, 10.0.1.0/24). For a list of already defined keywords, see Tabla 12.2, “Predefined access control lists”.
Tabla 12.2. Predefined access control lists
Keyword Descripción
any Matches every IP address.
localhost Matches any IP address that is in use by the local system.
localnets Matches any IP address on any network to which the local system is connected.
none Does not match any IP address.

The acl statement can be especially useful with conjunction with other statements such as options. Ejemplo 12.1, “Using acl in conjunction with options” defines two access control lists, black-hats and red-hats, and adds black-hats on the blacklist while granting red-hats a normal access.
Ejemplo 12.1. Using acl in conjunction with options
acl black-hats {
  10.0.2.0/24;
  192.168.0.0/24;
  1234:5678::9abc/24;
};
acl red-hats {
  10.0.1.0/24;
};
options {
  blackhole { black-hats; };
  allow-query { red-hats; };
  allow-query-cache { red-hats; };
};

include
The include statement allows you to include files in the /etc/named.conf, so that potentially sensitive data can be placed in a separate file with restricted permissions. It takes the following form:
include "file-name"
The file-name statement name is an absolute path to a file.
Ejemplo 12.2. Including a file to /etc/named.conf
include "/etc/named.rfc1912.zones";

options
The options statement allows you to define global server configuration options as well as to set defaults for other statements. It can be used to specify the location of the named working directory, the types of queries allowed, and much more. It takes the following form:
options {
  option;
  ...
};
For a list of frequently used option directives, see Tabla 12.3, “Commonly used options” below.
Tabla 12.3. Commonly used options
Opciones Descripción
allow-query Specifies which hosts are allowed to query the nameserver for authoritative resource records. It accepts an access control lists, a collection of IP addresses, or networks in the CIDR notation. All hosts are allowed by default.
allow-query-cache Specifies which hosts are allowed to query the nameserver for non-authoritative data such as recursive queries. Only localhost and localnets are allowed by default.
blackhole Specifies which hosts are not allowed to query the nameserver. This option should be used when particular host or network floods the server with requests. The default option is none.
directory Specifies a working directory for the named service. The default option is /var/named/.
dnssec-enable Specifies whether to return DNSSEC related resource records. The default option is yes.
dnssec-validation Specifies whether to prove that resource records are authentic via DNSSEC. The default option is yes.
forwarders Specifies a list of valid IP addresses for nameservers to which the requests should be forwarded for resolution.
forward
Specifies the behavior of the forwarders directive. It accepts the following options:
  • first — The server will query the nameservers listed in the forwarders directive before attempting to resolve the name on its own.
  • only — When unable to query the nameservers listed in the forwarders directive, the server will not attempt to resolve the name on its own.
listen-on Specifies the IPv4 network interface on which to listen for queries. On a DNS server that also acts as a gateway, you can use this option to answer queries originating from a single network only. All IPv4 interfaces are used by default.
listen-on-v6 Specifies the IPv6 network interface on which to listen for queries. On a DNS server that also acts as a gateway, you can use this option to answer queries originating from a single network only. All IPv6 interfaces are used by default.
max-cache-size Specifies the maximum amount of memory to be used for server caches. When the limit is reached, the server causes records to expire prematurely so that the limit is not exceeded. In a server with multiple views, the limit applies separately to the cache of each view. The default option is 32M.
notify
Specifies whether to notify the secondary nameservers when a zone is updated. It accepts the following options:
  • yes — The server will notify all secondary nameservers.
  • no — The server will not notify any secondary nameserver.
  • master-only — The server will notify primary server for the zone only.
  • explicit — The server will notify only the secondary servers that are specified in the also-notify list within a zone statement.
pid-file Specifies the location of the process ID file created by the named service.
recursion Specifies whether to act as a recursive server. The default option is yes.
statistics-file Specifies an alternate location for statistics files. The /var/named/named.stats file is used by default.

Restrict recursive servers to selected clients only

To prevent distributed denial of service (DDoS) attacks, it is recommended that you use the allow-query-cache option to restrict recursive DNS services for a particular subset of clients only.
Refer to the BIND 9 Administrator Reference Manual referenced in Sección 12.2.7.1, “Documentación instalada”, and the named.conf manual page for a complete list of available options.
Ejemplo 12.3. Using the options statement
options {
  allow-query       { localhost; };
  listen-on port    53 { 127.0.0.1; };
  listen-on-v6 port 53 { ::1; };
  max-cache-size    256M;
  directory         "/var/named";
  statistics-file   "/var/named/data/named_stats.txt";

  recursion         yes;
  dnssec-enable     yes;
  dnssec-validation yes;
};

zone
The zone statement allows you to define the characteristics of a zone, such as the location of its configuration file and zone-specific options, and can be used to override the global options statements. It takes the following form:
zone zone-name [zone-class] {
  option;
  ...
};
The zone-name attribute is the name of the zone, zone-class is the optional class of the zone, and option is a zone statement option as described in Tabla 12.4, “Commonly used options”.
The zone-name attribute is particularly important, as it is the default value assigned for the $ORIGIN directive used within the corresponding zone file located in the /var/named/ directory. The named daemon appends the name of the zone to any non-fully qualified domain name listed in the zone file. For example, if a zone statement defines the namespace for example.com, use example.com as the zone-name so that it is placed at the end of hostnames within the example.com zone file.
For more information about zone files, refer to Sección 12.2.2, “Editing Zone Files”.
Tabla 12.4. Commonly used options
Opciones Descripción
allow-query Specifies which clients are allowed to request information about this zone. This option overrides global allow-query option. All query requests are allowed by default.
allow-transfer Specifies which secondary servers are allowed to request a transfer of the zone's information. All transfer requests are allowed by default.
allow-update
Specifies which hosts are allowed to dynamically update information in their zone. The default option is to deny all dynamic update requests.
Note that you should be careful when allowing hosts to update information about their zone. Do not set IP addresses in this option unless the server is in the trusted network. Instead, use TSIG key as described in Sección 12.2.5.3, “Transaction SIGnatures (TSIG)”.
file Specifies the name of the file in the named working directory that contains the zone's configuration data.
masters Specifies from which IP addresses to request authoritative zone information. This option is used only if the zone is defined as type slave.
notify
Specifies whether to notify the secondary nameservers when a zone is updated. It accepts the following options:
  • yes — The server will notify all secondary nameservers.
  • no — The server will not notify any secondary nameserver.
  • master-only — The server will notify primary server for the zone only.
  • explicit — The server will notify only the secondary servers that are specified in the also-notify list within a zone statement.
type
Specifies the zone type. It accepts the following options:
  • delegation-only — Enforces the delegation status of infrastructure zones such as COM, NET, or ORG. Any answer that is received without an explicit or implicit delegation is treated as NXDOMAIN. This option is only applicable in TLDs or root zone files used in recursive or caching implementations.
  • forward — Forwards all requests for information about this zone to other nameservers.
  • hint — A special type of zone used to point to the root nameservers which resolve queries when a zone is not otherwise known. No configuration beyond the default is necessary with a hint zone.
  • master — Designates the nameserver as authoritative for this zone. A zone should be set as the master if the zone's configuration files reside on the system.
  • slave — Designates the nameserver as a slave server for this zone. Master server is specified in masters directive.

Most changes to the /etc/named.conf file of a primary or secondary nameserver involve adding, modifying, or deleting zone statements, and only a small subset of zone statement options is usually needed for a nameserver to work efficiently.
In Ejemplo 12.4, “A zone statement for a primary nameserver”, the zone is identified as example.com, the type is set to master, and the named service is instructed to read the /var/named/example.com.zone file. It also allows only a secondary nameserver (192.168.0.2) to transfer the zone.
Ejemplo 12.4. A zone statement for a primary nameserver
zone "example.com" IN {
  type master;
  file "example.com.zone";
  allow-transfer { 192.168.0.2; };
};

A secondary server's zone statement is slightly different. The type is set to slave, and the masters directive is telling named the IP address of the master server.
In Ejemplo 12.5, “A zone statement for a secondary nameserver”, the named service is configured to query the primary server at the 192.168.0.1 IP address for information about the example.com zone. The received information is then saved to the /var/named/slaves/example.com.zone file. Note that you have to put all slave zones to /var/named/slaves directory, otherwise the service will fail to transfer the zone.
Ejemplo 12.5. A zone statement for a secondary nameserver
zone "example.com" {
  type slave;
  file "slaves/example.com.zone";
  masters { 192.168.0.1; };
};

12.2.1.2. Otros tipos de declaraciones

The following types of statements are less commonly used in /etc/named.conf:
controls
The controls statement allows you to configure various security requirements necessary to use the rndc command to administer the named service.
Refer to Sección 12.2.3, “Using the rndc Utility” for more information on the rndc utility and its usage.
key
The key statement allows you to define a particular key by name. Keys are used to authenticate various actions, such as secure updates or the use of the rndc command. Two options are used with key:
  • algorithm algorithm-name — The type of algorithm to be used (for example, hmac-md5).
  • secret "key-value" — The encrypted key.
Refer to Sección 12.2.3, “Using the rndc Utility” for more information on the rndc utility and its usage.
logging
The logging statement allows you to use multiple types of logs, so called channels. By using the channel option within the statement, you can construct a customized type of log with its own file name (file), size limit (size), versioning (version), and level of importance (severity). Once a customized channel is defined, a category option is used to categorize the channel and begin logging when the named service is restarted.
By default, named sends standard messages to the rsyslog daemon, which places them in /var/log/messages. Several standard channels are built into BIND with various severity levels, such as default_syslog (which handles informational logging messages) and default_debug (which specifically handles debugging messages). A default category, called default, uses the built-in channels to do normal logging without any special configuration.
Customizing the logging process can be a very detailed process and is beyond the scope of this chapter. For information on creating custom BIND logs, refer to the BIND 9 Administrator Reference Manual referenced in Sección 12.2.7.1, “Documentación instalada”.
server
The server statement allows you to specify options that affect how the named service should respond to remote nameservers, especially with regard to notifications and zone transfers.
The transfer-format option controls the number of resource records that are sent with each message. It can be either one-answer (only one resource record), or many-answers (multiple resource records). Note that while the many-answers option is more efficient, it is not supported by older versions of BIND.
trusted-keys
The trusted-keys statement allows you to specify assorted public keys used for secure DNS (DNSSEC). Refer to Sección 12.2.5.4, “DNS Security Extensions (DNSSEC)” for more information on this topic.
view
The view statement allows you to create special views depending upon which network the host querying the nameserver is on. This allows some hosts to receive one answer regarding a zone while other hosts receive totally different information. Alternatively, certain zones may only be made available to particular trusted hosts while non-trusted hosts can only make queries for other zones.
Multiple views can be used as long as their names are unique. The match-clients option allows you to specify the IP addresses that apply to a particular view. If the options statement is used within a view, it overrides the already configured global options. Finally, most view statements contain multiple zone statements that apply to the match-clients list.
Note that the order in which the view statements are listed is important, as the first statement that matches a particular client's IP address is used. For more information on this topic, refer to Sección 12.2.5.1, “Vistas múltiples”.

12.2.1.3. Etiquetas de comentarios

Additionally to statements, the /etc/named.conf file can also contain comments. Comments are ignored by the named service, but can prove useful when providing additional information to a user. The following are valid comment tags:
//
Any text after the // characters to the end of the line is considered a comment. For example:
notify yes;  // notify all secondary nameservers
#
Any text after the # character to the end of the line is considered a comment. For example:
notify yes;  # notify all secondary nameservers
/* and */
Any block of text enclosed in /* and */ is considered a comment. For example:
notify yes;  /* notify all secondary nameservers */

12.2.2. Editing Zone Files

As outlined in Sección 12.1.1, “Zonas de servidores de nombres”, zone files contain information about a namespace. They are stored in the named working directory located in /var/named/ by default, and each zone file is named according to the file option in the zone statement, usually in a way that relates to the domain in question and identifies the file as containing zone data, such as example.com.zone.
Tabla 12.5. The named service zone files
Path Descripción
/var/named/ The working directory for the named service. The nameserver is not allowed to write to this directory.
/var/named/slaves/ The directory for secondary zones. This directory is writable by the named service.
/var/named/dynamic/ The directory for other files, such as dynamic DNS (DDNS) zones or managed DNSSEC keys. This directory is writable by the named service.
/var/named/data/ The directory for various statistics and debugging files. This directory is writable by the named service.

A zone file consists of directives and resource records. Directives tell the nameserver to perform tasks or apply special settings to the zone, resource records define the parameters of the zone and assign identities to individual hosts. While the directives are optional, the resource records are required in order to provide name service to a zone.
Todas las directivas y registros de recursos deberían ir en sus propias líneas individuales.

12.2.2.1. Common Directives

Directives begin with the dollar sign character (that is, $) followed by the name of the directive, and usually appear at the top of the file. The following directives are commonly used in zone files:
$INCLUDE
The $INCLUDE directive allows you to include another file at the place where it appears, so that other zone settings can be stored in a separate zone file.
Ejemplo 12.6. Using the $INCLUDE directive
$INCLUDE /var/named/penguin.example.com

$ORIGIN
The $ORIGIN directive allows you to append the domain name to unqualified records, such as those with the hostname only. Note that the use of this directive is not necessary if the zone is specified in /etc/named.conf, since the zone name is used by default.
In Ejemplo 12.7, “Using the $ORIGIN directive”, any names used in resource records that do not end in a trailing period (that is, the . character) are appended with example.com.
Ejemplo 12.7. Using the $ORIGIN directive
$ORIGIN example.com.

$TTL
The $TTL directive allows you to set the default Time to Live (TTL) value for the zone, that is, how long is a zone record valid. Each resource record can contain its own TTL value, which overrides this directive.
Cuando se decide aumentar este valor, permite a los servidores de nombres remotos hacer caché a la información de zona para un período más largo de tiempo, reduciendo el número de consultas para la zona y alargando la cantidad de tiempo requerido para proliferar cambios de registros de recursos.
Ejemplo 12.8. Using the $TTL directive
$TTL 1D

12.2.2.2. Common Resource Records

The following resource records are commonly used in zone files:
A
The Address record specifies an IP address to be assigned to a name. It takes the following form:
hostname IN A IP-address
If the hostname value is omitted, the record will point to the last specified hostname.
In Ejemplo 12.9, “Using the A resource record”, the requests for server1.example.com are pointed to 10.0.1.3 or 10.0.1.5.
Ejemplo 12.9. Using the A resource record
server1  IN  A  10.0.1.3
         IN  A  10.0.1.5

CNAME
The Canonical Name record maps one name to another. Because of this, this type of record is sometimes referred to as an alias record. It takes the following form:
alias-name IN CNAME real-name
CNAME records are most commonly used to point to services that use a common naming scheme, such as www for Web servers. However, there are multiple restrictions for their usage:
  • CNAME records should not point to other CNAME records. This is mainly to avoid possible infinite loops.
  • CNAME records should not contain other resource record types (such as A, NS, MX, etc.). The only exception are DNSSEC related records (that is, RRSIG, NSEC, etc.) when the zone is signed.
  • Other resource record that point to the fully qualified domain name (FQDN) of a host (that is, NS, MX, PTR) should not point to a CNAME record.
In Ejemplo 12.10, “Using the CNAME resource record”, the A record binds a hostname to an IP address, while the CNAME record points the commonly used www hostname to it.
Ejemplo 12.10. Using the CNAME resource record
server1  IN  A      10.0.1.5
www      IN  CNAME  server1

MX
The Mail Exchange record specifies where the mail sent to a particular namespace controlled by this zone should go. It takes the following form:
IN MX preference-value email-server-name
The email-server-name is a fully qualified domain name (FQDN). The preference-value allows numerical ranking of the email servers for a namespace, giving preference to some email systems over others. The MX resource record with the lowest preference-value is preferred over the others. However, multiple email servers can possess the same value to distribute email traffic evenly among them.
In Ejemplo 12.11, “Using the MX resource record”, the first mail.example.com email server is preferred to the mail2.example.com email server when receiving email destined for the example.com domain.
Ejemplo 12.11. Using the MX resource record
example.com.  IN  MX  10  mail.example.com.
              IN  MX  20  mail2.example.com.

NS
The Nameserver record announces authoritative nameservers for a particular zone. It takes the following form:
IN NS nameserver-name
The nameserver-name should be a fully qualified domain name (FQDN). Note that when two nameservers are listed as authoritative for the domain, it is not important whether these nameservers are secondary nameservers, or if one of them is a primary server. They are both still considered authoritative.
Ejemplo 12.12. Using the NS resource record
IN  NS  dns1.example.com.
IN  NS  dns2.example.com.

PTR
The Pointer record points to another part of the namespace. It takes the following form:
last-IP-digit IN PTR FQDN-of-system
The last-IP-digit directive is the last number in an IP address, and the FQDN-of-system is a fully qualified domain name (FQDN).
PTR records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. Refer to Sección 12.2.2.4.2, “A Reverse Name Resolution Zone File” for more examples of PTR records in use.
SOA
The Start of Authority record announces important authoritative information about a namespace to the nameserver. Located after the directives, it is the first resource record in a zone file. It takes the following form:
@  IN  SOA  primary-name-server hostmaster-email (
       serial-number
       time-to-refresh
       time-to-retry
       time-to-expire
       minimum-TTL )
The directives are as follows:
  • The @ symbol places the $ORIGIN directive (or the zone's name if the $ORIGIN directive is not set) as the namespace being defined by this SOA resource record.
  • The primary-name-server directive is the hostname of the primary nameserver that is authoritative for this domain.
  • The hostmaster-email directive is the email of the person to contact about the namespace.
  • The serial-number directive is a numerical value incremented every time the zone file is altered to indicate it is time for the named service to reload the zone.
  • The time-to-refresh directive is the numerical value secondary nameservers use to determine how long to wait before asking the primary nameserver if any changes have been made to the zone.
  • The time-to-retry directive is a numerical value used by secondary nameservers to determine the length of time to wait before issuing a refresh request in the event that the primary nameserver is not answering. If the primary server has not replied to a refresh request before the amount of time specified in the time-to-expire directive elapses, the secondary servers stop responding as an authority for requests concerning that namespace.
  • In BIND 4 and 8, the minimum-TTL directive is the amount of time other nameservers cache the zone's information. In BIND 9, it defines how long negative answers are cached for. Caching of negative answers can be set to a maximum of 3 hours (that is, 3H).
When configuring BIND, all times are specified in seconds. However, it is possible to use abbreviations when specifying units of time other than seconds, such as minutes (M), hours (H), days (D), and weeks (W). Tabla 12.6, “Segundos comparados a otras unidades de tiempo” shows an amount of time in seconds and the equivalent time in another format.
Tabla 12.6. Segundos comparados a otras unidades de tiempo
Segundos Otras unidades de tiempo
60 1M
1800 30M
3600 1H
10800 3H
21600 6H
43200 12H
86400 1D
259200 3D
604800 1W
31536000 365D

Ejemplo 12.13. Using the SOA resource record
@  IN  SOA  dns1.example.com.  hostmaster.example.com. (
       2001062501  ; serial
       21600       ; refresh after 6 hours
       3600        ; retry after 1 hour
       604800      ; expire after 1 week
       86400 )     ; minimum TTL of 1 day

12.2.2.3. Etiquetas de comentarios

Additionally to resource records and directives, a zone file can also contain comments. Comments are ignored by the named service, but can prove useful when providing additional information to the user. Any text after the semicolon character (that is, ;) to the end of the line is considered a comment. For example:
   604800  ; expire after 1 week

12.2.2.4. Ejemplo de uso

The following examples show the basic usage of zone files.
12.2.2.4.1. A Simple Zone File
Ejemplo 12.14, “A simple zone file” demonstrates the use of standard directives and SOA values.
Ejemplo 12.14. A simple zone file
$ORIGIN example.com.
$TTL 86400
@         IN  SOA  dns1.example.com.  hostmaster.example.com. (
              2001062501  ; serial
              21600       ; refresh after 6 hours
              3600        ; retry after 1 hour
              604800      ; expire after 1 week
              86400 )     ; minimum TTL of 1 day
;
;
          IN  NS     dns1.example.com.
          IN  NS     dns2.example.com.
dns1      IN  A      10.0.1.1
          IN  AAAA   aaaa:bbbb::1
dns2      IN  A      10.0.1.2
          IN  AAAA   aaaa:bbbb::2
;
;
@         IN  MX     10  mail.example.com.
          IN  MX     20  mail2.example.com.
mail      IN  A      10.0.1.5
          IN  AAAA   aaaa:bbbb::5
mail2     IN  A      10.0.1.6
          IN  AAAA   aaaa:bbbb::6
;
;
; This sample zone file illustrates sharing the same IP addresses
; for multiple services:
;
services  IN  A      10.0.1.10
          IN  AAAA   aaaa:bbbb::10
          IN  A      10.0.1.11
          IN  AAAA   aaaa:bbbb::11

ftp       IN  CNAME  services.example.com.
www       IN  CNAME  services.example.com.
;
;

In this example, the authoritative nameservers are set as dns1.example.com and dns2.example.com, and are tied to the 10.0.1.1 and 10.0.1.2 IP addresses respectively using the A record.
The email servers configured with the MX records point to mail and mail2 via A records. Since these names do not end in a trailing period (that is, the . character), the $ORIGIN domain is placed after them, expanding them to mail.example.com and mail2.example.com.
Services available at the standard names, such as www.example.com (WWW), are pointed at the appropriate servers using the CNAME record.
This zone file would be called into service with a zone statement in the /etc/named.conf similar to the following:
zone "example.com" IN {
  type master;
  file "example.com.zone";
  allow-update { none; };
};
12.2.2.4.2. A Reverse Name Resolution Zone File
A reverse name resolution zone file is used to translate an IP address in a particular namespace into an fully qualified domain name (FQDN). It looks very similar to a standard zone file, except that the PTR resource records are used to link the IP addresses to a fully qualified domain name as shown in Ejemplo 12.15, “A reverse name resolution zone file”.
Ejemplo 12.15. A reverse name resolution zone file
$ORIGIN 1.0.10.in-addr.arpa.
$TTL 86400
@  IN  SOA  dns1.example.com.  hostmaster.example.com. (
       2001062501  ; serial
       21600       ; refresh after 6 hours
       3600        ; retry after 1 hour
       604800      ; expire after 1 week
       86400 )     ; minimum TTL of 1 day
;
@  IN  NS   dns1.example.com.
;
1  IN  PTR  dns1.example.com.
2  IN  PTR  dns2.example.com.
;
5  IN  PTR  server1.example.com.
6  IN  PTR  server2.example.com.
;
3  IN  PTR  ftp.example.com.
4  IN  PTR  ftp.example.com.

In this example, IP addresses 10.0.1.1 through 10.0.1.6 are pointed to the corresponding fully qualified domain name.
This zone file would be called into service with a zone statement in the /etc/named.conf file similar to the following:
zone "1.0.10.in-addr.arpa" IN {
  type master;
  file "example.com.rr.zone";
  allow-update { none; };
};
There is very little difference between this example and a standard zone statement, except for the zone name. Note that a reverse name resolution zone requires the first three blocks of the IP address reversed followed by .in-addr.arpa. This allows the single block of IP numbers used in the reverse name resolution zone file to be associated with the zone.

12.2.3. Using the rndc Utility

The rndc utility is a command line tool that allows you to administer the named service, both locally and from a remote machine. Its usage is as follows:
rndc [option...] command [command-option]

12.2.3.1. Configuring the Utility

To prevent unauthorized access to the service, named must be configured to listen on the selected port (that is, 953 by default), and an identical key must be used by both the service and the rndc utility.
Tabla 12.7. Relevant files
Path Descripción
/etc/named.conf The default configuration file for the named service.
/etc/rndc.conf The default configuration file for the rndc utility.
/etc/rndc.key The default key location.

The rndc configuration is located in /etc/rndc.conf. If the file does not exist, the utility will use the key located in /etc/rndc.key, which was generated automatically during the installation process using the rndc-confgen -a command.
The named service is configured using the controls statement in the /etc/named.conf configuration file as described in Sección 12.2.1.2, “Otros tipos de declaraciones”. Unless this statement is present, only the connections from the loopback address (that is, 127.0.0.1) will be allowed, and the key located in /etc/rndc.key will be used.
For more information on this topic, refer to manual pages and the BIND 9 Administrator Reference Manual listed in Sección 12.2.7, “Recursos adicionales”.

Set the correct permissions

To prevent unprivileged users from sending control commands to the service, make sure only root is allowed to read the /etc/rndc.key file:
~]# chmod o-rwx /etc/rndc.key

12.2.3.2. Checking the Service Status

To check the current status of the named service, use the following command:
~]# rndc status
version: 9.7.0-P2-RedHat-9.7.0-5.P2.el6
CPUs found: 1
worker threads: 1
number of zones: 16
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

12.2.3.3. Reloading the Configuration and Zones

To reload both the configuration file and zones, type the following at a shell prompt:
~]# rndc reload
server reload successful
This will reload the zones while keeping all previously cached responses, so that you can make changes to the zone files without losing all stored name resolutions.
To reload a single zone, specify its name after the reload command, for example:
~]# rndc reload localhost
zone reload up-to-date
Finally, to reload the configuration file and newly added zones only, type:
~]# rndc reconfig

Modifying zones with dynamic DNS

If you intend to manually modify a zone that uses Dynamic DNS (DDNS), make sure you run the freeze command first:
~]# rndc freeze localhost
Once you are finished, run the thaw command to allow the DDNS again and reload the zone:
~]# rndc thaw localhost
The zone reload and thaw was successful.

12.2.3.4. Updating Zone Keys

To update the DNSSEC keys and sign the zone, use the sign command. For example:
~]# rndc sign localhost
Note that to sign a zone with the above command, the auto-dnssec option has to be set to maintain in the zone statement. For instance:
zone "localhost" IN {
  type master;
  file "named.localhost";
  allow-update { none; };
  auto-dnssec maintain;
};

12.2.3.5. Enabling the DNSSEC Validation

To enable the DNSSEC validation, type the following at a shell prompt:
~]# rndc validation on
Similarly, to disable this option, type:
~]# rndc validation off
Refer to the options statement described in Sección 12.2.1.1, “Tipos de declaraciones comúnes” for information on how configure this option in /etc/named.conf.

12.2.3.6. Enabling the Query Logging

To enable (or disable in case it is currently enabled) the query logging, run the following command:
~]# rndc querylog
To check the current setting, use the status command as described in Sección 12.2.3.2, “Checking the Service Status”.

12.2.4. Using the dig Utility

The dig utility is a command line tool that allows you to perform DNS lookups and debug a nameserver configuration. Its typical usage is as follows:
dig [@server] [option...] name type
Refer to Sección 12.2.2.2, “Common Resource Records” for a list of common types.

12.2.4.1. Looking Up a Nameserver

To look up a nameserver for a particular domain, use the command in the following form:
dig name NS
In Ejemplo 12.16, “A sample nameserver lookup”, the dig utility is used to display nameservers for example.com.
Ejemplo 12.16. A sample nameserver lookup
~]$ dig example.com NS

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> example.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57883
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            99374   IN      NS      a.iana-servers.net.
example.com.            99374   IN      NS      b.iana-servers.net.

;; Query time: 1 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:04:06 2010
;; MSG SIZE  rcvd: 77

12.2.4.2. Looking Up an IP Address

To look up an IP address assigned to a particular domain, use the command in the following form:
dig name A
In Ejemplo 12.17, “A sample IP address lookup”, the dig utility is used to display the IP address of example.com.
Ejemplo 12.17. A sample IP address lookup
~]$ dig example.com A

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4849
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            155606  IN      A       192.0.32.10

;; AUTHORITY SECTION:
example.com.            99175   IN      NS      a.iana-servers.net.
example.com.            99175   IN      NS      b.iana-servers.net.

;; Query time: 1 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:07:25 2010
;; MSG SIZE  rcvd: 93

12.2.4.3. Looking Up a Hostname

To look up a hostname for a particular IP address, use the command in the following form:
dig -x address
In Ejemplo 12.18, “A sample hostname lookup”, the dig utility is used to display the hostname assigned to 192.0.32.10.
Ejemplo 12.18. A sample hostname lookup
~]$ dig -x 192.0.32.10

; <<>> DiG 9.7.1-P2-RedHat-9.7.1-2.P2.fc13 <<>> -x 192.0.32.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29683
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6

;; QUESTION SECTION:
;10.32.0.192.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
10.32.0.192.in-addr.arpa. 21600 IN      PTR     www.example.com.

;; AUTHORITY SECTION:
32.0.192.in-addr.arpa.  21600   IN      NS      b.iana-servers.org.
32.0.192.in-addr.arpa.  21600   IN      NS      c.iana-servers.net.
32.0.192.in-addr.arpa.  21600   IN      NS      d.iana-servers.net.
32.0.192.in-addr.arpa.  21600   IN      NS      ns.icann.org.
32.0.192.in-addr.arpa.  21600   IN      NS      a.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     13688   IN      A       192.0.34.43
b.iana-servers.org.     5844    IN      A       193.0.0.236
b.iana-servers.org.     5844    IN      AAAA    2001:610:240:2::c100:ec
c.iana-servers.net.     12173   IN      A       139.91.1.10
c.iana-servers.net.     12173   IN      AAAA    2001:648:2c30::1:10
ns.icann.org.           12884   IN      A       192.0.34.126

;; Query time: 156 msec
;; SERVER: 10.34.255.7#53(10.34.255.7)
;; WHEN: Wed Aug 18 18:25:15 2010
;; MSG SIZE  rcvd: 310

12.2.5. Características avanzadas de BIND

Most BIND implementations only use the named service to provide name resolution services or to act as an authority for a particular domain. However, BIND version 9 has a number of advanced features that allow for a more secure and efficient DNS service.

Make sure the feature is supported

Before attempting to use advanced features like DNSSEC, TSIG, or IXFR, make sure that the particular feature is supported by all nameservers in the network environment, especially when you use older versions of BIND or non-BIND servers.
All of the features mentioned are discussed in greater detail in the BIND 9 Administrator Reference Manual referenced in Sección 12.2.7.1, “Documentación instalada”.

12.2.5.1. Vistas múltiples

Optionally, different information can be presented to a client depending on the network a request originates from. This is primarily used to deny sensitive DNS entries from clients outside of the local network, while allowing queries from clients inside the local network.
To configure multiple views, add the view statement to the /etc/named.conf configuration file. Use the match-clients option to match IP addresses or entire networks and give them special options and zone data.

12.2.5.2. Incremental Zone Transfers (IXFR)

Incremental Zone Transfers (IXFR) allow a secondary nameserver to only download the updated portions of a zone modified on a primary nameserver. Compared to the standard transfer process, this makes the notification and update process much more efficient.
Note that IXFR is only available when using dynamic updating to make changes to master zone records. If manually editing zone files to make changes, Automatic Zone Transfer (AXFR) is used.

12.2.5.3. Transaction SIGnatures (TSIG)

Transaction SIGnatures (TSIG) ensure that a shared secret key exists on both primary and secondary nameserver before allowing a transfer. This strengthens the standard IP address-based method of transfer authorization, since attackers would not only need to have access to the IP address to transfer the zone, but they would also need to know the secret key.
Since version 9, BIND also supports TKEY, which is another shared secret key method of authorizing zone transfers.

Secure the transfer

When communicating over an insecure network, do not rely on IP address-based authentication only.

12.2.5.4. DNS Security Extensions (DNSSEC)

Domain Name System Security Extensions (DNSSEC) provide origin authentication of DNS data, authenticated denial of existence, and data integrity. When a particular domain is marked as secure, the SERFVAIL response is returned for each resource record that fails the validation.
Note that to debug a DNSSEC-signed domain or a DNSSEC-aware resolver, you can use the dig utility as described in Sección 12.2.4, “Using the dig Utility”. Useful options are +dnssec (requests DNSSEC-related resource records by setting the DNSSEC OK bit), +cd (tells recursive nameserver not to validate the response), and +bufsize=512 (changes the packet size to 512B to get through some firewalls).

12.2.5.5. Internet Protocol version 6 (IPv6)

Internet Protocol version 6 (IPv6) is supported through the use of AAAA resource records, and the listen-on-v6 directive as described in Tabla 12.3, “Commonly used options”.

12.2.6. Errores comunes que debe evitar

The following is a list of advices how to avoid common mistakes users make when configuring a nameserver:
Use semicolons and curly brackets correctly
An omitted semicolon or unmatched curly bracket in the /etc/named.conf file can prevent the named service from starting.
Use period (that is, the . character) correctly
In zone files, a period at the end of a domain name denotes a fully qualified domain name. If omitted, the named service will append the name of the zone or the value of $ORIGIN to complete it.
Increment the serial number when editing a zone file
If the serial number is not incremented, the primary nameserver will have the correct, new information, but the secondary nameservers will never be notified of the change, and will not attempt to refresh their data of that zone.
Configure the firewall
If a firewall is blocking connections from the named service to other nameservers, the recommended best practice is to change the firewall settings whenever possible.

Avoid using fixed UDP source ports

According to the recent research in DNS security, using a fixed UDP source port for DNS queries is a potential security vulnerability that could allow an attacker to conduct cache-poisoning attacks more easily. To prevent this, configure your firewall to allow queries from a random UDP source port.

12.2.7. Recursos adicionales

Las siguientes fuentes de información le proporcionarán recursos adicionales relacionados a BIND.

12.2.7.1. Documentación instalada

BIND features a full range of installed documentation covering many different topics, each placed in its own subject directory. For each item below, replace version with the version of the bind package installed on the system:
/usr/share/doc/bind-version/
The main directory containing the most recent documentation.
/usr/share/doc/bind-version/arm/
The directory containing the BIND 9 Administrator Reference Manual in HTML and SGML formats, which details BIND resource requirements, how to configure different types of nameservers, how to perform load balancing, and other advanced topics. For most new users of BIND, this is the best place to start.
/usr/share/doc/bind-version/draft/
The directory containing assorted technical documents that review issues related to the DNS service, and propose some methods to address them.
/usr/share/doc/bind-version/misc/
The directory designed to address specific advanced issues. Users of BIND version 8 should consult the migration document for specific changes they must make when moving to BIND 9. The options file lists all of the options implemented in BIND 9 that are used in /etc/named.conf.
/usr/share/doc/bind-version/rfc/
The directory providing every RFC document related to BIND.
There is also a number of man pages for the various applications and configuration files involved with BIND:
man rndc
The manual page for rndc containing the full documentation on its usage.
man named
The manual page for named containing the documentation on assorted arguments that can be used to control the BIND nameserver daemon.
man lwresd
The manual page for lwresd containing the full documentation on the lightweight resolver daemon and its usage.
man named.conf
The manual page with a comprehensive list of options available within the named configuration file.
man rndc.conf
The manual page with a comprehensive list of options available within the rndc configuration file.

12.2.7.2. Sitios Web útiles

http://www.isc.org/software/bind
The home page of the BIND project containing information about current releases as well as a PDF version of the BIND 9 Administrator Reference Manual.

Capítulo 13. Servidores web

Un servidor HTTP (Hypertext Transfer Protocol, protocolo de transferencia hipertexto), o un servidor web, es un servicio de red que sirve contenido a un cliente a través de la web. Esto típicamente significa páginas web, pero cualquier tipo de documento pueden ser servidos también.

13.1. The Apache HTTP Server

This section focuses on the Apache HTTP Server 2.2, a robust, full-featured open source web server developed by the Apache Software Foundation, that is included in Fedora 17. It describes the basic configuration of the httpd service, and covers advanced topics such as adding server modules, setting up virtual hosts, or configuring the secure HTTP server.
There are important differences between the Apache HTTP Server 2.2 and version 2.0, and if you are upgrading from a previous release of Fedora, you will need to update the httpd service configuration accordingly. This section reviews some of the newly added features, outlines important changes, and guides you through the update of older configuration files.

13.1.1. New Features

The Apache HTTP Server version 2.2 introduces the following enhancements:
  • Improved caching modules, that is, mod_cache and mod_disk_cache.
  • Support for proxy load balancing, that is, the mod_proxy_balancer module.
  • Support for large files on 32-bit architectures, allowing the web server to handle files greater than 2GB.
  • A new structure for authentication and authorization support, replacing the authentication modules provided in previous versions.

13.1.2. Notable Changes

Since version 2.0, few changes have been made to the default httpd service configuration:
  • The following modules are no longer loaded by default: mod_cern_meta and mod_asis.
  • The following module is newly loaded by default: mod_ext_filter.

13.1.3. Updating the Configuration

To update the configuration files from the Apache HTTP Server version 2.0, take the following steps:
  1. Make sure all module names are correct, since they may have changed. Adjust the LoadModule directive for each module that has been renamed.
  2. Recompile all third party modules before attempting to load them. This typically means authentication and authorization modules.
  3. If you use the mod_userdir module, make sure the UserDir directive indicating a directory name (typically public_html) is provided.
  4. If you use the Apache HTTP Secure Server, edit the /etc/httpd/conf.d/ssl.conf to enable the Secure Sockets Layer (SSL) protocol.
Note that you can check the configuration for possible errors by using the following command:
service httpd configtest
For more information on upgrading the Apache HTTP Server configuration from version 2.0 to 2.2, refer to http://httpd.apache.org/docs/2.2/upgrading.html.

13.1.4. Running the httpd Service

This section describes how to start, stop, restart, and check the current status of the Apache HTTP Server. To be able to use the httpd service, make sure you have the httpd installed. You can do so by using the following command as root:
yum install httpd
For more information on the concept of runlevels and how to manage system services in Fedora in general, refer to Capítulo 8, Services and Daemons.

13.1.4.1. Starting the Service

To run the httpd service, type the following at a shell prompt as root:
systemctl start httpd.service
If you want the service to start automatically at the boot time, use the following command:
systemctl enable httpd.service
Refer to Capítulo 8, Services and Daemons for more information on how to configure services in Fedora.

Using the secure server

If running the Apache HTTP Server as a secure server, a password may be required after the machine boots if using an encrypted private SSL key.

13.1.4.2. Stopping the Service

To stop the running httpd service, type the following at a shell prompt as root:
systemctl stop httpd.service
To prevent the service from starting automatically at the boot time, type:
systemctl disable httpd.service
Refer to Capítulo 8, Services and Daemons for more information on how to configure services in Fedora.

13.1.4.3. Restarting the Service

There are two different ways to restart the running httpd service:
  1. To restart the service completely, type the following at a shell prompt as root:
    systemctl restart httpd.service
    This will stop the running httpd service, and then start it again. Use this command after installing or removing a dynamically loaded module such as PHP.
  2. To only reload the configuration, as root, type:
    systemctl reload httpd.service
    This will cause the running httpd service to reload the configuration file. Note that any requests being currently processed will be interrupted, which may cause a client browser to display an error message or render a partial page.
  3. To reload the configuration without affecting active requests, run the following command as root:
    service httpd graceful
    This will cause the running httpd service to reload the configuration file. Note that any requests being currently processed will use the old configuration.
Refer to Capítulo 8, Services and Daemons for more information on how to configure services in Fedora.

13.1.4.4. Checking the Service Status

To check whether the service is running, type the following at a shell prompt:
systemctl is-active httpd.service
Refer to Capítulo 8, Services and Daemons for more information on how to configure services in Fedora.

13.1.5. Editing the Configuration Files

When the httpd service is started, by default, it reads the configuration from locations that are listed in Tabla 13.1, “The httpd service configuration files”.
Tabla 13.1. The httpd service configuration files
Path Descripción
/etc/httpd/conf/httpd.conf The main configuration file.
/etc/httpd/conf.d/ An auxiliary directory for configuration files that are included in the main configuration file.

Although the default configuration should be suitable for most situations, it is a good idea to become at least familiar with some of the more important configuration options. Note that for any changes to take effect, the web server has to be restarted first. Refer to Sección 13.1.4.3, “Restarting the Service” for more information on how to restart the httpd service.
To check the configuration for possible errors, type the following at a shell prompt:
service httpd configtest
To make the recovery from mistakes easier, it is recommended that you make a copy of the original file before editing it.

13.1.5.1. Common httpd.conf Directives

The following directives are commonly used in the /etc/httpd/conf/httpd.conf configuration file:
<Directory>
The <Directory> directive allows you to apply certain directives to a particular directory only. It takes the following form:
<Directory directory>
  directive
  …
</Directory>
The directory can be either a full path to an existing directory in the local file system, or a wildcard expression.
This directive can be used to configure additional cgi-bin directories for server-side scripts located outside the directory that is specified by ScriptAlias. In this case, the ExecCGI and AddHandler directives must be supplied, and the permissions on the target directory must be set correctly (that is, 0755).
Ejemplo 13.1. Using the <Directory> directive
<Directory /var/www/html>
  Options Indexes FollowSymLinks
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

<IfDefine>
The IfDefine directive allows you to use certain directives only when a particular parameter is supplied on the command line. It takes the following form:
<IfDefine [!]parameter>
  directive
  …
</IfDefine>
The parameter can be supplied at a shell prompt using the -Dparameter command line option (for example, httpd -DEnableHome). If the optional exclamation mark (that is, !) is present, the enclosed directives are used only when the parameter is not specified.
Ejemplo 13.2. Using the <IfDefine> directive
<IfDefine EnableHome>
  UserDir public_html
</IfDefine>

<IfModule>
The <IfModule> directive allows you to use certain directive only when a particular module is loaded. It takes the following form:
<IfModule [!]module>
  directive
  …
</IfModule>
The module can be identified either by its name, or by the file name. If the optional exclamation mark (that is, !) is present, the enclosed directives are used only when the module is not loaded.
Ejemplo 13.3. Using the <IfModule> directive
<IfModule mod_disk_cache.c>
  CacheEnable disk /
  CacheRoot /var/cache/mod_proxy
</IfModule>

<Location>
The <Location> directive allows you to apply certain directives to a particular URL only. It takes the following form:
<Location url>
  directive
  …
</Location>
The url can be either a path relative to the directory specified by the DocumentRoot directive (for example, /server-info), or an external URL such as http://example.com/server-info.
Ejemplo 13.4. Using the <Location> directive
<Location /server-info>
  SetHandler server-info
  Order deny,allow
  Deny from all
  Allow from .example.com
</Location>

<Proxy>
The <Proxy> directive allows you to apply certain directives to the proxy server only. It takes the following form:
<Proxy pattern>
  directive
  …
</Proxy>
The pattern can be an external URL, or a wildcard expression (for example, http://example.com/*).
Ejemplo 13.5. Using the <Proxy> directive
<Proxy *>
  Order deny,allow
  Deny from all
  Allow from .example.com
</Proxy>

<VirtualHost>
The <VirtualHost> directive allows you apply certain directives to particular virtual hosts only. It takes the following form:
<VirtualHost address[:port]…>
  directive
  …
</VirtualHost>
The address can be an IP address, a fully qualified domain name, or a special form as described in Tabla 13.2, “Available <VirtualHost> options”.
Tabla 13.2. Available <VirtualHost> options
Opciones Descripción
* Represents all IP addresses.
_default_ Represents unmatched IP addresses.

Ejemplo 13.6. Using the <VirtualHost> directive
<VirtualHost *:80>
  ServerAdmin webmaster@penguin.example.com
  DocumentRoot /www/docs/penguin.example.com
  ServerName penguin.example.com
  ErrorLog logs/penguin.example.com-error_log
  CustomLog logs/penguin.example.com-access_log common
</VirtualHost>

AccessFileName
The AccessFileName directive allows you to specify the file to be used to customize access control information for each directory. It takes the following form:
AccessFileName filename
The filename is a name of the file to look for in the requested directory. By default, the server looks for .htaccess.
For security reasons, the directive is typically followed by the Files tag to prevent the files beginning with .ht from being accessed by web clients. This includes the .htaccess and .htpasswd files.
Ejemplo 13.7. Using the AccessFileName directive
AccessFileName .htaccess

<Files ~ "^\.ht">
  Order allow,deny
  Deny from all
  Satisfy All
</Files>

Action
The Action directive allows you to specify a CGI script to be executed when a certain media type is requested. It takes the following form:
Action content-type path
The content-type has to be a valid MIME type such as text/html, image/png, or application/pdf. The path refers to an existing CGI script, and must be relative to the directory specified by the DocumentRoot directive (for example, /cgi-bin/process-image.cgi).
Ejemplo 13.8. Using the Action directive
Action image/png /cgi-bin/process-image.cgi

AddDescription
The AddDescription directive allows you to specify a short description to be displayed in server-generated directory listings for a given file. It takes the following form:
AddDescription "description" filename
The description should be a short text enclosed in double quotes (that is, "). The filename can be a full file name, a file extension, or a wildcard expression.
Ejemplo 13.9. Using the AddDescription directive
AddDescription "GZIP compressed tar archive" .tgz

AddEncoding
The AddEncoding directive allows you to specify an encoding type for a particular file extension. It takes the following form:
AddEncoding encoding extension
The encoding has to be a valid MIME encoding such as x-compress, x-gzip, etc. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .gz).
This directive is typically used to instruct web browsers to decompress certain file types as they are downloaded.
Ejemplo 13.10. Using the AddEncoding directive
AddEncoding x-gzip .gz .tgz

AddHandler
The AddHandler directive allows you to map certain file extensions to a selected handler. It takes the following form:
AddHandler handler extension
The handler has to be a name of previously defined handler. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .cgi).
This directive is typically used to treat files with the .cgi extension as CGI scripts regardless of the directory they are in. Additionally, it is also commonly used to process server-parsed HTML and image-map files.
Ejemplo 13.11. Using the AddHandler option
AddHandler cgi-script .cgi

AddIcon
The AddIcon directive allows you to specify an icon to be displayed for a particular file in server-generated directory listings. It takes the following form:
AddIcon path pattern
The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/folder.png). The pattern can be a file name, a file extension, a wildcard expression, or a special form as described in the following table:
Tabla 13.3. Available AddIcon options
Opciones Descripción
^^DIRECTORY^^ Represents a directory.
^^BLANKICON^^ Represents a blank line.

Ejemplo 13.12. Using the AddIcon directive
AddIcon /icons/text.png .txt README

AddIconByEncoding
The AddIconByEncoding directive allows you to specify an icon to be displayed for a particular encoding type in server-generated directory listings. It takes the following form:
AddIconByEncoding path encoding
The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/compressed.png). The encoding has to be a valid MIME encoding such as x-compress, x-gzip, etc.
Ejemplo 13.13. Using the AddIconByEncoding directive
AddIconByEncoding /icons/compressed.png x-compress x-gzip

AddIconByType
The AddIconByType directive allows you to specify an icon to be displayed for a particular media type in server-generated directory listings. It takes the following form:
AddIconByType path content-type
The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/text.png). The content-type has to be either a valid MIME type (for example, text/html or image/png), or a wildcard expression such as text/*, image/*, etc.
Ejemplo 13.14. Using the AddIconByType directive
AddIconByType /icons/video.png video/*

AddLanguage
The AddLanguage directive allows you to associate a file extension with a specific language. It takes the following form:
AddLanguage language extension
The language has to be a valid MIME language such as cs, en, or fr. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .cs).
This directive is especially useful for web servers that serve content in multiple languages based on the client's language settings.
Ejemplo 13.15. Using the AddLanguage directive
AddLanguage cs .cs .cz

AddType
The AddType directive allows you to define or override the media type for a particular file extension. It takes the following form:
AddType content-type extension
The content-type has to be a valid MIME type such as text/html, image/png, etc. The extension is a case sensitive file extension, and is conventionally written with a leading dot (for example, .cs).
Ejemplo 13.16. Using the AddType directive
AddType application/x-gzip .gz .tgz

Alias
The Alias directive allows you to refer to files and directories outside the default directory specified by the DocumentRoot directive. It takes the following form:
Alias url-path real-path
The url-path must be relative to the directory specified by the DocumentRoot directive (for example, /images/). The real-path is a full path to a file or directory in the local file system.
This directive is typically followed by the Directory tag with additional permissions to access the target directory. By default, the /icons/ alias is created so that the icons from /var/www/icons/ are displayed in server-generated directory listings.
Ejemplo 13.17. Using the Alias directive
Alias /icons/ /var/www/icons/

<Directory "/var/www/icons">
  Options Indexes MultiViews FollowSymLinks
  AllowOverride None
  Order allow,deny
  Allow from all
<Directory>

Allow
The Allow directive allows you to specify which clients have permission to access a given directory. It takes the following form:
Allow from client
The client can be a domain name, an IP address (both full and partial), a network/netmask pair, or all for all clients.
Ejemplo 13.18. Using the Allow directive
Allow from 192.168.1.0/255.255.255.0

AllowOverride
The AllowOverride directive allows you to specify which directives in a .htaccess file can override the default configuration. It takes the following form:
AllowOverride type
The type has to be one of the available grouping options as described in Tabla 13.4, “Available AllowOverride options”.
Tabla 13.4. Available AllowOverride options
Opciones Descripción
All All directives in .htaccess are allowed to override earlier configuration settings.
None No directive in .htaccess is allowed to override earlier configuration settings.
AuthConfig Allows the use of authorization directives such as AuthName, AuthType, or Require.
FileInfo Allows the use of file type, metadata, and mod_rewrite directives such as DefaultType, RequestHeader, or RewriteEngine, as well as the Action directive.
Indexes Allows the use of directory indexing directives such as AddDescription, AddIcon, or FancyIndexing.
Limit Allows the use of host access directives, that is, Allow, Deny, and Order.
Options[=option,…] Allows the use of the Options directive. Additionally, you can provide a comma-separated list of options to customize which options can be set using this directive.

Ejemplo 13.19. Using the AllowOverride directive
AllowOverride FileInfo AuthConfig Limit

BrowserMatch
The BrowserMatch directive allows you to modify the server behavior based on the client's web browser type. It takes the following form:
BrowserMatch pattern variable
The pattern is a regular expression to match the User-Agent HTTP header field. The variable is an environment variable that is set when the header field matches the pattern.
By default, this directive is used to deny connections to specific browsers with known issues, and to disable keepalives and HTTP header flushes for browsers that are known to have problems with these actions.
Ejemplo 13.20. Using the BrowserMatch directive
BrowserMatch "Mozilla/2" nokeepalive

CacheDefaultExpire
The CacheDefaultExpire option allows you to set how long to cache a document that does not have any expiration date or the date of its last modification specified. It takes the following form:
CacheDefaultExpire time
The time is specified in seconds. The default option is 3600 (that is, one hour).
Ejemplo 13.21. Using the CacheDefaultExpire directive
CacheDefaultExpire 3600

CacheDisable
The CacheDisable directive allows you to disable caching of certain URLs. It takes the following form:
CacheDisable path
The path must be relative to the directory specified by the DocumentRoot directive (for example, /files/).
Ejemplo 13.22. Using the CacheDisable directive
CacheDisable /temporary

CacheEnable
The CacheEnable directive allows you to specify a cache type to be used for certain URLs. It takes the following form:
CacheEnable type url
The type has to be a valid cache type as described in Tabla 13.5, “Available cache types”. The url can be a path relative to the directory specified by the DocumentRoot directive (for example, /images/), a protocol (for example, ftp://), or an external URL such as http://example.com/.
Tabla 13.5. Available cache types
Type Descripción
mem The memory-based storage manager.
disk The disk-based storage manager.
fd The file descriptor cache.

Ejemplo 13.23. Using the CacheEnable directive
CacheEnable disk /

CacheLastModifiedFactor
The CacheLastModifiedFactor directive allows you to customize how long to cache a document that does not have any expiration date specified, but that provides information about the date of its last modification. It takes the following form:
CacheLastModifiedFactor number
The number is a coefficient to be used to multiply the time that passed since the last modification of the document. The default option is 0.1 (that is, one tenth).
Ejemplo 13.24. Using the CacheLastModifiedFactor directive
CacheLastModifiedFactor 0.1

CacheMaxExpire
The CacheMaxExpire directive allows you to specify the maximum amount of time to cache a document. It takes the following form:
CacheMaxExpire time
The time is specified in seconds. The default option is 86400 (that is, one day).
Ejemplo 13.25. Using the CacheMaxExpire directive
CacheMaxExpire 86400

CacheNegotiatedDocs
The CacheNegotiatedDocs directive allows you to enable caching of the documents that were negotiated on the basis of content. It takes the following form:
CacheNegotiatedDocs option
The option has to be a valid keyword as described in Tabla 13.6, “Available CacheNegotiatedDocs options”. Since the content-negotiated documents may change over time or because of the input from the requester, the default option is Off.
Tabla 13.6. Available CacheNegotiatedDocs options
Opciones Descripción
On Enables caching the content-negotiated documents.
Off Disables caching the content-negotiated documents.

Ejemplo 13.26. Using the CacheNegotiatedDocs directive
CacheNegotiatedDocs On

CacheRoot
The CacheRoot directive allows you to specify the directory to store cache files in. It takes the following form:
CacheRoot directory
The directory must be a full path to an existing directory in the local file system. The default option is /var/cache/mod_proxy/.
Ejemplo 13.27. Using the CacheRoot directive
CacheRoot /var/cache/mod_proxy

CustomLog
The CustomLog directive allows you to specify the log file name and the log file format. It takes the following form:
CustomLog path format
The path refers to a log file, and must be relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The format has to be either an explicit format string, or a format name that was previously defined using the LogFormat directive.
Ejemplo 13.28. Using the CustomLog directive
CustomLog logs/access_log combined

DefaultIcon
The DefaultIcon directive allows you to specify an icon to be displayed for a file in server-generated directory listings when no other icon is associated with it. It takes the following form:
DefaultIcon path
The path refers to an existing icon file, and must be relative to the directory specified by the DocumentRoot directive (for example, /icons/unknown.png).
Ejemplo 13.29. Using the DefaultIcon directive
DefaultIcon /icons/unknown.png

DefaultType
The DefaultType directive allows you to specify a media type to be used in case the proper MIME type cannot be determined by the server. It takes the following form:
DefaultType content-type
The content-type has to be a valid MIME type such as text/html, image/png, application/pdf, etc.
Ejemplo 13.30. Using the DefaultType directive
DefaultType text/plain

Deny
The Deny directive allows you to specify which clients are denied access to a given directory. It takes the following form:
Deny from client
The client can be a domain name, an IP address (both full and partial), a network/netmask pair, or all for all clients.
Ejemplo 13.31. Using the Deny directive
Deny from 192.168.1.1

DirectoryIndex
The DirectoryIndex directive allows you to specify a document to be served to a client when a directory is requested (that is, when the URL ends with the / character). It takes the following form:
DirectoryIndex filename
The filename is a name of the file to look for in the requested directory. By default, the server looks for index.html, and index.html.var.
Ejemplo 13.32. Using the DirectoryIndex directive
DirectoryIndex index.html index.html.var

DocumentRoot
The DocumentRoot directive allows you to specify the main directory from which the content is served. It takes the following form:
DocumentRoot directory
The directory must be a full path to an existing directory in the local file system. The default option is /var/www/html/.
Ejemplo 13.33. Using the DocumentRoot directive
DocumentRoot /var/www/html

ErrorDocument
The ErrorDocument directive allows you to specify a document or a message to be displayed as a response to a particular error. It takes the following form:
ErrorDocument error-code action
The error-code has to be a valid code such as 403 (Forbidden), 404 (Not Found), or 500 (Internal Server Error). The action can be either a URL (both local and external), or a message string enclosed in double quotes (that is, ").
Ejemplo 13.34. Using the ErrorDocument directive
ErrorDocument 403 "Access Denied"
ErrorDocument 404 /404-not_found.html

ErrorLog
The ErrorLog directive allows you to specify a file to which the server errors are logged. It takes the following form:
ErrorLog path
The path refers to a log file, and can be either absolute, or relative to the directory that is specified by the ServerRoot directive (that is, /etc/httpd/ by default). The default option is logs/error_log
Ejemplo 13.35. Using the ErrorLog directive
ErrorLog logs/error_log

ExtendedStatus
The ExtendedStatus directive allows you to enable detailed server status information. It takes the following form:
ExtendedStatus option
The option has to be a valid keyword as described in Tabla 13.7, “Available ExtendedStatus options”. The default option is Off.
Tabla 13.7. Available ExtendedStatus options
Opciones Descripción
On Enables generating the detailed server status.
Off Disables generating the detailed server status.

Ejemplo 13.36. Using the ExtendedStatus directive
ExtendedStatus On

Group
The Group directive allows you to specify the group under which the httpd service will run. It takes the following form:
Group group
The group has to be an existing UNIX group. The default option is apache.
Note that Group is no longer supported inside <VirtualHost>, and has been replaced by the SuexecUserGroup directive.
Ejemplo 13.37. Using the Group directive
Group apache

HeaderName
The HeaderName directive allows you to specify a file to be prepended to the beginning of the server-generated directory listing. It takes the following form:
HeaderName filename
The filename is a name of the file to look for in the requested directory. By default, the server looks for HEADER.html.
Ejemplo 13.38. Using the HeaderName directive
HeaderName HEADER.html

HostnameLookups
The HostnameLookups directive allows you to enable automatic resolving of IP addresses. It takes the following form:
HostnameLookups option
The option has to be a valid keyword as described in Tabla 13.8, “Available HostnameLookups options”. To conserve resources on the server, the default option is Off.
Tabla 13.8. Available HostnameLookups options
Opciones Descripción
On Enables resolving the IP address for each connection so that the hostname can be logged. However, this also adds a significant processing overhead.
Double Enables performing the double-reverse DNS lookup. In comparison to the above option, this adds even more processing overhead.
Off Disables resolving the IP address for each connection.

Note that when the presence of hostnames is required in server log files, it is often possible to use one of the many log analyzer tools that perform the DNS lookups more efficiently.
Ejemplo 13.39. Using the HostnameLookups directive
HostnameLookups Off

Include
The Include directive allows you to include other configuration files. It takes the following form:
Include filename
The filename can be an absolute path, a path relative to the directory specified by the ServerRoot directive, or a wildcard expression. All configuration files from the /etc/httpd/conf.d/ directory are loaded by default.
Ejemplo 13.40. Using the Include directive
Include conf.d/*.conf

IndexIgnore
The IndexIgnore directive allows you to specify a list of file names to be omitted from the server-generated directory listings. It takes the following form:
IndexIgnore filename
The filename option can be either a full file name, or a wildcard expression.
Ejemplo 13.41. Using the IndexIgnore directive
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

IndexOptions
The IndexOptions directive allows you to customize the behavior of server-generated directory listings. It takes the following form:
IndexOptions option
The option has to be a valid keyword as described in Tabla 13.9, “Available directory listing options”. The default options are Charset=UTF-8, FancyIndexing, HTMLTable, NameWidth=*, and VersionSort.
Tabla 13.9. Available directory listing options
Opciones Descripción
Charset=encoding Specifies the character set of a generated web page. The encoding has to be a valid character set such as UTF-8 or ISO-8859-2.
Type=content-type Specifies the media type of a generated web page. The content-type has to be a valid MIME type such as text/html or text/plain.
DescriptionWidth=value Specifies the width of the description column. The value can be either a number of characters, or an asterisk (that is, *) to adjust the width automatically.
FancyIndexing Enables advanced features such as different icons for certain files or possibility to re-sort a directory listing by clicking on a column header.
FolderFirst Enables listing directories first, always placing them above files.
HTMLTable Enables the use of HTML tables for directory listings.
IconsAreLinks Enables using the icons as links.
IconHeight=value Specifies an icon height. The value is a number of pixels.
IconWidth=value Specifies an icon width. The value is a number of pixels.
IgnoreCase Enables sorting files and directories in a case-sensitive manner.
IgnoreClient Disables accepting query variables from a client.
NameWidth=value Specifies the width of the file name column. The value can be either a number of characters, or an asterisk (that is, *) to adjust the width automatically.
ScanHTMLTitles Enables parsing the file for a description (that is, the title element) in case it is not provided by the AddDescription directive.
ShowForbidden Enables listing the files with otherwise restricted access.
SuppressColumnSorting Disables re-sorting a directory listing by clicking on a column header.
SuppressDescription Disables reserving a space for file descriptions.
SuppressHTMLPreamble Disables the use of standard HTML preamble when a file specified by the HeaderName directive is present.
SuppressIcon Disables the use of icons in directory listings.
SuppressLastModified Disables displaying the date of the last modification field in directory listings.
SuppressRules Disables the use of horizontal lines in directory listings.
SuppressSize Disables displaying the file size field in directory listings.
TrackModified Enables returning the Last-Modified and ETag values in the HTTP header.
VersionSort Enables sorting files that contain a version number in the expected manner.
XHTML Enables the use of XHTML 1.0 instead of the default HTML 3.2.

Ejemplo 13.42. Using the IndexOptions directive
IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable Charset=UTF-8

KeepAlive
The KeepAlive directive allows you to enable persistent connections. It takes the following form:
KeepAlive option
The option has to be a valid keyword as described in Tabla 13.10, “Available KeepAlive options”. The default option is Off.
Tabla 13.10. Available KeepAlive options
Opciones Descripción
On Enables the persistent connections. In this case, the server will accept more than one request per connection.
Off Disables the keep-alive connections.

Note that when the persistent connections are enabled, on a busy server, the number of child processes can increase rapidly and eventually reach the maximum limit, slowing down the server significantly. To reduce the risk, it is recommended that you set KeepAliveTimeout to a low number, and monitor the /var/log/httpd/logs/error_log log file carefully.
Ejemplo 13.43. Using the KeepAlive directive
KeepAlive Off

KeepAliveTimeout
The KeepAliveTimeout directive allows you to specify the amount of time to wait for another request before closing the connection. It takes the following form:
KeepAliveTimeout time
The time is specified in seconds. The default option is 15.
Ejemplo 13.44. Using the KeepAliveTimeout directive
KeepAliveTimeout 15

LanguagePriority
The LanguagePriority directive allows you to customize the precedence of languages. It takes the following form:
LanguagePriority language
The language has to be a valid MIME language such as cs, en, or fr.
This directive is especially useful for web servers that serve content in multiple languages based on the client's language settings.
Ejemplo 13.45. Using the LanguagePriority directive
LanguagePriority sk cs en

Listen
The Listen directive allows you to specify IP addresses or ports to listen to. It takes the following form:
Listen [ip-address:]port [protocol]
The ip-address is optional and unless supplied, the server will accept incoming requests on a given port from all IP addresses. Since the protocol is determined automatically from the port number, it can be usually omitted. The default option is to listen to port 80.
Note that if the server is configured to listen to a port under 1024, only superuser will be able to start the httpd service.
Ejemplo 13.46. Using the Listen directive
Listen 80

LoadModule
The LoadModule directive allows you to load a Dynamic Shared Object (DSO) module. It takes the following form:
LoadModule name path
The name has to be a valid identifier of the required module. The path refers to an existing module file, and must be relative to the directory in which the libraries are placed (that is, /usr/lib/httpd/ on 32-bit and /usr/lib64/httpd/ on 64-bit systems by default).
Refer to Sección 13.1.6, “Working with Modules” for more information on the Apache HTTP Server's DSO support.
Ejemplo 13.47. Using the LoadModule directive
LoadModule php5_module modules/libphp5.so

LogFormat
The LogFormat directive allows you to specify a log file format. It takes the following form:
LogFormat format name
The format is a string consisting of options as described in Tabla 13.11, “Common LogFormat options”. The name can be used instead of the format string in the CustomLog directive.
Tabla 13.11. Common LogFormat options
Opciones Descripción
%b Represents the size of the response in bytes.
%h Represents the IP address or hostname of a remote client.
%l Represents the remote log name if supplied. If not, a hyphen (that is, -) is used instead.
%r Represents the first line of the request string as it came from the browser or client.
%s Represents the status code.
%t Represents the date and time of the request.
%u If the authentication is required, it represents the remote user. If not, a hyphen (that is, -) is used instead.
%{field} Represents the content of the HTTP header field. The common options include %{Referer} (the URL of the web page that referred the client to the server) and %{User-Agent} (the type of the web browser making the request).

Ejemplo 13.48. Using the LogFormat directive
LogFormat "%h %l %u %t \"%r\" %>s %b" common

LogLevel
The LogLevel directive allows you to customize the verbosity level of the error log. It takes the following form:
LogLevel option
The option has to be a valid keyword as described in Tabla 13.12, “Available LogLevel options”. The default option is warn.
Tabla 13.12. Available LogLevel options
Opciones Descripción
emerg Only the emergency situations when the server cannot perform its work are logged.
alert All situations when an immediate action is required are logged.
crit All critical conditions are logged.
error All error messages are logged.
warn All warning messages are logged.
notice Even normal, but still significant situations are logged.
info Various informational messages are logged.
debug Various debugging messages are logged.

Ejemplo 13.49. Using the LogLevel directive
LogLevel warn

MaxKeepAliveRequests
The MaxKeepAliveRequests directive allows you to specify the maximum number of requests for a persistent connection. It takes the following form:
MaxKeepAliveRequests number
A high number can improve the performance of the server. Note that using 0 allows unlimited number of requests. The default option is 100.
Ejemplo 13.50. Using the MaxKeepAliveRequests option
MaxKeepAliveRequests 100

NameVirtualHost
The NameVirtualHost directive allows you to specify the IP address and port number for a name-based virtual host. It takes the following form:
NameVirtualHost ip-address[:port]
The ip-address can be either a full IP address, or an asterisk (that is, *) representing all interfaces. Note that IPv6 addresses have to be enclosed in square brackets (that is, [ and ]). The port is optional.
Name-based virtual hosting allows one Apache HTTP Server to serve different domains without using multiple IP addresses.

Using secure HTTP connections

Name-based virtual hosts only work with non-secure HTTP connections. If using virtual hosts with a secure server, use IP address-based virtual hosts instead.
Ejemplo 13.51. Using the NameVirtualHost directive
NameVirtualHost *:80