Despliegue de Diferentes Tipos de Servidores

Red Hat Enterprise Linux 8
Despliegue de diferentes tipos de servidores
Guía para la implantación de diferentes tipos de servidores en Red Hat Enterprise

Linux 8
Last Updated: 2021-02-28

Red Hat Enterprise Linux 8 Despliegue de diferentes tipos de servidores
Guía para la implantación de diferentes tipos de servidores en Red Hat Enterprise Linux 8
Enter your first name here. Enter your surname here.

Enter your organisation's name here. Enter your organisational division here.
Enter your email address here.
Legal Notice
Copyright © 2021 | You need to change the HOLDER entity in the en-
US/Deploying_different_types_of_servers.ent file |.
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/
. 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, the Red Hat logo, JBoss, OpenShift,
Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States
and other countries.
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.
Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the
official Joyent Node.js open source or commercial project.
The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marks
or trademarks/service marks of the OpenStack Foundation, in the United States and other
countries and are used with the OpenStack Foundation's permission. We are not affiliated with,
endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Resumen
Este documento describe cómo configurar y ejecutar diferentes tipos de servidores en Red Hat
Enterprise Linux 8, incluyendo el servidor web Apache HTTP, el servidor Samba, el servidor NFS, los
servidores de bases de datos disponibles y el servidor CUPS.
Table of Contents
Table of Contents
. . . . . . . . QUE
HACER . . . . . .EL
. . .CÓDIGO
. . . . . . . . .ABIERTO
. . . . . . . . . .SEA
. . . . .MÁS
. . . . .INCLUSIVO
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .COMENTARIOS
PROPORCIONAR . . . . . . . . . . . . . . . . SOBRE
. . . . . . . .LA
. . . DOCUMENTACIÓN
. . . . . . . . . . . . . . . . . . . . DE
. . . .RED
. . . . .HAT
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. . . . . . . . . . . . .
.CAPÍTULO
. . . . . . . . . . .1.. .CONFIGURACIÓN
. . . . . . . . . . . . . . . . . . .DEL
. . . . SERVIDOR
. . . . . . . . . . . .WEB
. . . . . APACHE
. . . . . . . . . .HTTP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
..............
1.1. INTRODUCCIÓN AL SERVIDOR WEB APACHE HTTP 10
1.1.1. Cambios notables en el servidor HTTP Apache 10
1.1.2. Actualización de la configuración 12
1.2. LOS ARCHIVOS DE CONFIGURACIÓN DE APACHE 12
1.3. GESTIÓN DEL SERVICIO HTTPD 13
1.4. CONFIGURACIÓN DE UN SERVIDOR HTTP APACHE DE UNA SOLA INSTANCIA 13
1.5. CONFIGURACIÓN DE HOSTS VIRTUALES BASADOS EN NOMBRES DE APACHE 14
1.6. CONFIGURACIÓN DEL CIFRADO TLS EN UN SERVIDOR HTTP APACHE 17
1.6.1. Cómo añadir el cifrado TLS a un servidor HTTP Apache 17
1.6.2. Configuración de las versiones de protocolo TLS admitidas en un servidor HTTP Apache 19
1.6.3. Cómo configurar los cifrados admitidos en un servidor HTTP Apache 20
1.7. CONFIGURACIÓN DE LA AUTENTICACIÓN DEL CERTIFICADO DE CLIENTE TLS 21
1.8. INSTALACIÓN DEL MANUAL DEL SERVIDOR HTTP APACHE 22
1.9. TRABAJAR CON MÓDULOS 23
1.9.1. Cargar un módulo 23
1.9.2. Escribir un módulo 23
1.10. EXPORTACIÓN DE UNA CLAVE PRIVADA Y DE CERTIFICADOS DE UNA BASE DE DATOS NSS PARA
UTILIZARLOS EN UNA CONFIGURACIÓN DE SERVIDOR WEB APACHE 24
1.11. RECURSOS ADICIONALES 25
. . . . . . . . . . . .2.
CAPÍTULO . . INSTALACIÓN
...............Y
. . CONFIGURACIÓN
. . . . . . . . . . . . . . . . . . . DE
. . . .NGINX
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
..............
2.1. INSTALACIÓN Y PREPARACIÓN DE NGINX 27
2.2. CONFIGURAR NGINX COMO UN SERVIDOR WEB QUE PROPORCIONA DIFERENTES CONTENIDOS PARA
DIFERENTES DOMINIOS 29
2.3. AÑADIR ENCRIPTACIÓN TLS A UN SERVIDOR WEB NGINX 31
2.4. CONFIGURAR NGINX COMO PROXY INVERSO PARA EL TRÁFICO HTTP 32
2.5. CONFIGURACIÓN DE NGINX COMO EQUILIBRADOR DE CARGA HTTP 33
.CAPÍTULO
. . . . . . . . . . .3.
. . USO
. . . . . DE
. . . .SAMBA
. . . . . . . .COMO
. . . . . . . SERVIDOR
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
..............
3.1. ENTENDER LOS DIFERENTES SERVICIOS Y MODOS DE SAMBA 35
3.1.1. Los servicios de Samba 35
3.1.2. Los servicios de seguridad de Samba 36
3.1.3. Escenarios cuando los servicios de Samba y las utilidades de cliente de Samba cargan y recargan su
configuración 36
3.1.4. Editar la configuración de Samba de forma guardada 37
3.2. VERIFICACIÓN DE LA CONFIGURACIÓN DE SAMBA 38
3.2.1. Verificación del archivo smb.conf mediante la utilidad testparm 38
3.3. CONFIGURACIÓN DE SAMBA COMO SERVIDOR INDEPENDIENTE 39
3.3.1. Establecimiento de la configuración del servidor independiente 39
3.3.2. Creación y habilitación de cuentas de usuario locales 40
3.4. COMPRENDER Y CONFIGURAR LA ASIGNACIÓN DE ID DE SAMBA 41
3.4.1. Planificación de rangos de ID de Samba 41
3.4.2. The * default domain 42
3.4.3. Utilizar el back end de mapeo de ID de tdb 43
3.4.4. Utilización del back end de mapeo de ID de anuncios 43
3.4.5. Utilización del back end de asignación de ID de crestas 46
Ventajas de utilizar el back end de rid 46
1
Inconvenientes de utilizar el back end de rid 46

3.4.6. Utilizar el back end de mapeo de autorid ID 48
Ventajas de utilizar el back end de autorid 48
Inconvenientes 48
3.5. CONFIGURACIÓN DE SAMBA COMO SERVIDOR MIEMBRO DEL DOMINIO AD 50
3.5.1. Unir un sistema RHEL a un dominio AD 50
3.5.2. Uso del complemento de autorización local para MIT Kerberos 52
3.6. CONFIGURACIÓN DE SAMBA EN UN MIEMBRO DEL DOMINIO IDM 53
3.6.1. Preparación del dominio IdM para instalar Samba en los miembros del dominio 54
3.6.2. Habilitación del tipo de cifrado AES en Active Directory mediante un GPO 55
3.6.3. Instalación y configuración de un servidor Samba en un cliente IdM 56
3.6.4. Añadir manualmente una configuración de asignación de ID si IdM confía en un nuevo dominio 58
3.6.5. Recursos adicionales 59
3.7. CONFIGURACIÓN DE UN ARCHIVO COMPARTIDO SAMBA QUE UTILIZA ACLS POSIX 59
3.7.1. Añadir un recurso compartido que utiliza ACLs POSIX 60
3.7.2. Establecer ACLs estándar de Linux en un recurso compartido de Samba que utiliza ACLs POSIX 61
3.7.3. Configuración de ACLs extendidas en un recurso compartido de Samba que utiliza ACLs POSIX 61
3.8. ESTABLECIMIENTO DE PERMISOS EN UN RECURSO COMPARTIDO QUE UTILIZA ACLS POSIX 64
3.8.1. Configurar el acceso a los recursos compartidos basado en usuarios y grupos 64
3.8.2. Configuración del acceso compartido basado en el host 65
3.9. CONFIGURACIÓN DE UN RECURSO COMPARTIDO QUE UTILIZA LAS ACL DE WINDOWS 65
3.9.1. Concesión del privilegio SeDiskOperatorPrivilege 66
3.9.2. Habilitación de la compatibilidad con ACL de Windows 66
3.9.3. Añadir un recurso compartido que utiliza las ACL de Windows 67
3.9.4. Gestión de los permisos del recurso compartido y de las ACL del sistema de archivos de un recurso
compartido que utiliza las ACL de Windows 68
3.10. GESTIÓN DE ACLS EN UN RECURSO COMPARTIDO SMB MEDIANTE SMBCACLS 68
3.10.1. Entradas de control de acceso 68
3.10.2. Visualización de ACLs con smbcacls 71
3.10.3. Cálculo de la máscara ACE 72
3.10.4. Añadir, actualizar y eliminar una ACL con smbcacls 72
Añadir una ACL 72
Actualización de una ACL 73
Borrar una ACL 73
3.11. PERMITIR A LOS USUARIOS COMPARTIR DIRECTORIOS EN UN SERVIDOR SAMBA 73
3.11.1. Habilitación de la función de acciones de los usuarios 73
3.11.2. Añadir una cuota de usuario 74
3.11.3. Actualización de la configuración de una cuota de usuario 75
3.11.4. Mostrar información sobre las acciones de los usuarios existentes 75
3.11.5. Listado de acciones de usuarios 75
3.11.6. Borrar una cuota de usuario 76
3.12. CONFIGURAR UN RECURSO COMPARTIDO PARA PERMITIR EL ACCESO SIN AUTENTICACIÓN 76
3.12.1. Habilitar el acceso de invitados a un recurso compartido 77
3.13. CONFIGURACIÓN DE SAMBA PARA CLIENTES DE MACOS 78
3.13.1. Optimización de la configuración de Samba para proporcionar recursos compartidos de archivos para
clientes de macOS 78
3.14. USO DE LA UTILIDAD SMBCLIENT PARA ACCEDER A UN RECURSO COMPARTIDO SMB 79
3.14.1. Cómo funciona el modo interactivo de smbclient 79
3.14.2. Uso de smbclient en modo interactivo 80
3.14.3. Uso de smbclient en modo scripting 80
3.15. CONFIGURACIÓN DE SAMBA COMO SERVIDOR DE IMPRESIÓN 81
3.15.1. El servicio Samba spoolssd 81
3.15.2. Activación del soporte del servidor de impresión en Samba 82
2
Table of Contents
3.15.3. Compartir manualmente impresoras específicas 83

3.16. CONFIGURACIÓN DE DESCARGAS AUTOMÁTICAS DE CONTROLADORES DE IMPRESORA PARA
CLIENTES DE WINDOWS EN SERVIDORES DE IMPRESIÓN SAMBA 84
3.16.1. Información básica sobre los controladores de impresora 84
Versión del modelo de controlador compatible 85
Controladores compatibles con los paquetes 85
Preparación de un controlador de impresora para ser cargado 85
Suministro de controladores de 32 y 64 bits para una impresora a un cliente 85
3.16.2. Permitir a los usuarios cargar y preconfigurar los controladores 85
3.16.3. Configuración de la acción print$ 86
3.16.4. Creación de un GPO para que los clientes confíen en el servidor de impresión Samba 87
3.16.5. Carga de controladores y preconfiguración de impresoras 91
3.17. AJUSTE DEL RENDIMIENTO DE UN SERVIDOR SAMBA 91
3.17.1. Configuración de la versión del protocolo SMB 91
3.17.2. Ajuste de los recursos compartidos con directorios que contienen un gran número de archivos 92
3.17.3. Ajustes que pueden tener un impacto negativo en el rendimiento 93
3.18. CONFIGURAR SAMBA PARA QUE SEA COMPATIBLE CON CLIENTES QUE REQUIEREN UNA VERSIÓN
DE SMB INFERIOR A LA PREDETERMINADA 93
3.18.1. Establecer la versión mínima del protocolo SMB soportada por un servidor Samba 93
3.19. UTILIDADES DE LÍNEA DE COMANDOS DE SAMBA DE USO FRECUENTE 94
3.19.1. Uso de los comandos net ads join y net rpc join 94
3.19.2. Uso del comando net rpc rights 95
Los privilegios de la lista se pueden establecer 95
Concesión de privilegios 96
Revocación de privilegios 96
3.19.3. Utilizando el comando net rpc share 96
Acciones de la lista 96
Añadir una acción 96
Eliminar una acción 97
3.19.4. Uso del comando net user 97
Listado de cuentas de usuario del dominio 98
Añadir una cuenta de usuario al dominio 98
Eliminar una cuenta de usuario del dominio 98
3.19.5. Uso de la utilidad rpcclient 98
Ejemplos 99
3.19.6. Uso de la aplicación samba-regedit 99
3.19.7. Uso de la utilidad smbcontrol 100
3.19.8. Uso de la utilidad smbpasswd 101
3.19.9. Uso de la utilidad smbstatus 102
3.19.10. Uso de la utilidad smbtar 102
3.19.11. Uso de la utilidad wbinfo 103
3.20. INFORMACIÓN RELACIONADA 104
. . . . . . . . . . . .4.
CAPÍTULO . . EXPORTACIÓN
. . . . . . . . . . . . . . . . .DE
. . . RECURSOS
. . . . . . . . . . . . COMPARTIDOS
. . . . . . . . . . . . . . . . .NFS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
...............
4.1. INTRODUCCIÓN A NFS 105
4.2. VERSIONES DE NFS COMPATIBLES 105
Versión NFS por defecto 105
Características de las versiones menores de NFS 105
4.3. LOS PROTOCOLOS TCP Y UDP EN NFSV3 Y NFSV4 106
4.4. SERVICIOS REQUERIDOS POR NFS 106
Los servicios RPC con NFSv4 107
4.5. FORMATOS DE NOMBRES DE HOST NFS 107
4.6. CONFIGURACIÓN DEL SERVIDOR NFS 108
3
4.6.1. El archivo de configuración /etc/exports 108

Entrada de exportación 108
Opciones por defecto 109
Opciones por defecto y anuladas 110
4.6.2. La utilidad exportfs 110
Opciones comunes de exportfs 110
4.7. NFS Y RPCBIND 111
4.8. INSTALACIÓN DE NFS 112
4.9. INICIAR EL SERVIDOR NFS 112
4.10. SOLUCIÓN DE PROBLEMAS DE NFS Y RPCBIND 112
4.11. CONFIGURAR EL SERVIDOR NFS PARA QUE FUNCIONE DETRÁS DE UN CORTAFUEGOS 114
4.12. EXPORTACIÓN DE LA CUOTA RPC A TRAVÉS DE UN CORTAFUEGOS 115
4.13. ACTIVACIÓN DE NFS SOBRE RDMA (NFSORDMA) 115
4.14. CONFIGURACIÓN DE UN SERVIDOR SÓLO NFSV4 116
4.14.1. Ventajas e inconvenientes de un servidor sólo NFSv4 116
4.14.2. NFS y rpcbind 116
4.14.3. Configurar el servidor NFS para que sólo admita NFSv4 117
4.14.4. Verificación de la configuración NFSv4-only 117
4.15. INFORMACIÓN RELACIONADA 118
. . . . . . . . . . . .5.
CAPÍTULO . . ASEGURAR
. . . . . . . . . . . . .NFS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
...............
5.1. SEGURIDAD NFS CON AUTH_SYS Y CONTROLES DE EXPORTACIÓN 120
5.2. SEGURIDAD NFS CON AUTH_GSS 120
5.3. CONFIGURACIÓN DE UN SERVIDOR Y UN CLIENTE NFS PARA UTILIZAR KERBEROS 120
5.4. OPCIONES DE SEGURIDAD DE NFSV4 121
5.5. PERMISOS DE ARCHIVOS EN EXPORTACIONES NFS MONTADAS 122
. . . . . . . . . . . .6.
CAPÍTULO . . HABILITACIÓN
. . . . . . . . . . . . . . . . DE
. . . .DISPOSICIONES
. . . . . . . . . . . . . . . . .SCSI
. . . . . PNFS
. . . . . . .EN
. . .NFS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
...............
6.1. LA TECNOLOGÍA PNFS 123
6.2. DISPOSICIONES SCSI PNFS 123
Operaciones entre el cliente y el servidor 123
Reservas de dispositivos 124
6.3. COMPROBACIÓN DE UN DISPOSITIVO SCSI COMPATIBLE CON PNFS 124
6.4. CONFIGURACIÓN DE PNFS SCSI EN EL SERVIDOR 125
6.5. CONFIGURACIÓN DE PNFS SCSI EN EL CLIENTE 125
6.6. LIBERACIÓN DE LA RESERVA SCSI PNFS EN EL SERVIDOR 126
6.7. SUPERVISIÓN DE LA FUNCIONALIDAD DE LOS DISEÑOS SCSI DE PNFS 127
6.7.1. Comprobación de las operaciones SCSI pNFS desde el servidor mediante nfsstat 127
6.7.2. Comprobación de las operaciones SCSI de pNFS desde el cliente mediante mountstats 128
. . . . . . . . . . . .7.
CAPÍTULO . . CONFIGURACIÓN
. . . . . . . . . . . . . . . . . . . DEL
. . . . .SERVIDOR
. . . . . . . . . . . PROXY
. . . . . . . . .DE
. . .CACHÉ
. . . . . . . .SQUID
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
...............
7.1. CONFIGURACIÓN DE SQUID COMO PROXY DE CACHÉ SIN AUTENTICACIÓN 129
7.2. CONFIGURACIÓN DE SQUID COMO PROXY DE CACHÉ CON AUTENTICACIÓN LDAP 131
7.3. CONFIGURACIÓN DE SQUID COMO PROXY DE CACHÉ CON AUTENTICACIÓN KERBEROS 134
7.4. CONFIGURACIÓN DE UNA LISTA DE DENEGACIÓN DE DOMINIO EN SQUID 138
7.5. CONFIGURAR EL SERVICIO SQUID PARA QUE ESCUCHE EN UN PUERTO O DIRECCIÓN IP ESPECÍFICOS
138
. . . . . . . . . . . .8.
CAPÍTULO . . SERVIDORES
. . . . . . . . . . . . . . .DE
. . .BASES
. . . . . . . DE
. . . .DATOS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
...............
8.1. INTRODUCCIÓN A LOS SERVIDORES DE BASES DE DATOS 140
8.2. USO DE MARIADB 140
8.2.1. Introducción a MariaDB 140
8.2.2. Instalación de MariaDB 140
4
Table of Contents
8.2.2.1. Mejora de la seguridad de la instalación de MariaDB 141

8.2.3. Configuración de MariaDB 141
8.2.3.1. Configurar el servidor MariaDB para la red 141
8.2.4. Copia de seguridad de los datos de MariaDB 141
8.2.4.1. Realizando una copia de seguridad lógica con mysqldump 142
8.2.4.1.1. Copia de seguridad de una base de datos completa con mysqldump 143
8.2.4.1.2. Uso de mysqldump para hacer una copia de seguridad de un conjunto de tablas de una base de
datos 143
8.2.4.1.3. Usando mysqldump para cargar el archivo de volcado de nuevo en un servidor 143
8.2.4.1.4. Usando mysqldump para copiar datos entre dos bases de datos 143
8.2.4.1.5. Volcado de múltiples bases de datos con mysqldump 143
8.2.4.1.6. Volcado de todas las bases de datos con mysqldump 143
8.2.4.1.7. Revisando las opciones de mysqldump 144
8.2.4.1.8. Recursos adicionales 144
8.2.4.2. Realización de una copia de seguridad física en línea con la herramienta Mariabackup 144
8.2.4.3. Restauración de datos con la herramienta Mariabackup 145
8.2.4.3.1. Restauración de datos con Mariabackup conservando los archivos de copia de seguridad 146
8.2.4.3.2. Restauración de datos con Mariabackup mientras se eliminan los archivos de copia de seguridad
146
8.2.4.4. Realizar una copia de seguridad del sistema de archivos 147
8.2.4.5. Introducción a la replicación como solución de copia de seguridad 147
8.2.5. Migración a MariaDB 10.3 148
8.2.5.1. Diferencias notables entre las versiones RHEL 7 y RHEL 8 de MariaDB 148
8.2.5.2. Cambios de configuración 148
8.2.5.3. Actualización en el lugar utilizando la herramienta mysql_upgrade 149
8.2.6. Replicar MariaDB con Galera 150
8.2.6.1. Introducción al clúster MariaDB Galera 151
8.2.6.2. Componentes para construir el clúster MariaDB Galera 152
8.2.6.3. Despliegue del clúster MariaDB Galera 152
8.2.6.4. Añadir un nuevo nodo al clúster MariaDB Galera 153
8.2.6.5. Reinicio del clúster MariaDB Galera 154
8.3. USO DE POSTGRESQL 154
8.3.1. Introducción a PostgreSQL 154
8.3.2. Instalación de PostgreSQL 155
8.3.3. Configuración de PostgreSQL 156
8.3.3.1. Inicialización de un clúster de bases de datos 156
8.3.4. Copia de seguridad de los datos de PostgreSQL 156
8.3.4.1. Copia de seguridad de los datos de PostgreSQL con un volcado SQL 157
8.3.4.1.1. Realización de un volcado SQL 157
8.3.4.1.2. Restauración de la base de datos a partir de un volcado SQL 157
8.3.4.1.3. Ventajas y desventajas de un volcado SQL 159
8.3.4.2. Copia de seguridad de los datos de PostgreSQL con una copia de seguridad a nivel de sistema de
archivos 159
8.3.4.2.1. Realización de una copia de seguridad a nivel de sistema de archivos 159
8.3.4.2.2. Ventajas y desventajas de una copia de seguridad a nivel de sistema de archivos 159
8.3.4.2.3. Enfoques alternativos a la copia de seguridad a nivel de sistema de archivos 160
8.3.4.3. Copia de seguridad de los datos de PostgreSQL mediante archivo continuo 160
8.3.4.3.1. Introducción al archivo continuo 160
8.3.4.3.2. Realización de copias de seguridad de archivo continuo 161
8.3.4.3.3. Ventajas y desventajas del archivo continuo 163
5

8.3.5. Migración a la versión RHEL 8 de PostgreSQL 163
8.3.5.1. Actualización rápida con la herramienta pg_upgrade 164
8.3.5.2. Actualización de volcado y restauración 166
.CAPÍTULO
. . . . . . . . . . .9.
. . CONFIGURACIÓN
. . . . . . . . . . . . . . . . . . . DE
. . . .LA
. . .IMPRESIÓN
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .169
...............
9.1. ACTIVACIÓN DEL SERVICIO DE COPAS 169
9.2. HERRAMIENTAS DE CONFIGURACIÓN DE LA IMPRESIÓN 169
9.3. ACCESO Y CONFIGURACIÓN DE LA INTERFAZ WEB DE CUPS 170
9.3.1. Adquirir acceso de administración a la interfaz web de CUPS 171
9.4. AÑADIR UNA IMPRESORA EN LA INTERFAZ WEB DE CUPS 173
9.5. CONFIGURAR UNA IMPRESORA EN LA INTERFAZ WEB DE CUPS 177
9.6. IMPRESIÓN DE UNA PÁGINA DE PRUEBA MEDIANTE LA INTERFAZ WEB DE CUPS 179
9.7. CONFIGURACIÓN DE LAS OPCIONES DE IMPRESIÓN MEDIANTE LA INTERFAZ WEB DE CUPS 179
9.8. INSTALACIÓN DE CERTIFICADOS PARA UN SERVIDOR DE IMPRESIÓN 180
9.9. USO DE SAMBA PARA IMPRIMIR EN UN SERVIDOR DE IMPRESIÓN DE WINDOWS CON AUTENTICACIÓN
KERBEROS 183
9.10. TRABAJAR CON LOS REGISTROS DE CUPS 184
9.10.1. Tipos de registros CUPS 184
9.10.2. Acceso a los registros de CUPS 185
9.10.2.1. Acceso a todos los registros de CUPS 185
9.10.2.2. Acceso a los registros de CUPS para un trabajo de impresión específico 185
9.10.2.3. Acceder a los registros de CUPS por un periodo de tiempo específico 185
9.10.2.4. Información relacionada 186
9.10.3. Configuración de la ubicación del registro de CUPS 186
6
Table of Contents
7
HACER QUE EL CÓDIGO ABIERTO SEA MÁS INCLUSIVO

Red Hat se compromete a sustituir el lenguaje problemático en nuestro código, documentación y
propiedades web. Estamos empezando con estos cuatro términos: maestro, esclavo, lista negra y lista
blanca. Debido a la enormidad de este esfuerzo, estos cambios se implementarán gradualmente a lo
largo de varias versiones próximas. Para más detalles, consulte el mensaje de nuestro CTO Chris Wright .
8
PROPORCIONAR COMENTARIOS SOBRE LA DOCUMENTACIÓN DE RED HAT
PROPORCIONAR COMENTARIOS SOBRE LA

DOCUMENTACIÓN DE RED HAT
Agradecemos su opinión sobre nuestra documentación. Por favor, díganos cómo podemos mejorarla.
Para ello:
Para comentarios sencillos sobre pasajes concretos:
1. Asegúrese de que está viendo la documentación en el formato Multi-page HTML. Además,

asegúrese de ver el botón Feedback en la esquina superior derecha del documento.
2. Utilice el cursor del ratón para resaltar la parte del texto que desea comentar.
3. Haga clic en la ventana emergente Add Feedback que aparece debajo del texto resaltado.
4. Siga las instrucciones mostradas.
Para enviar comentarios más complejos, cree un ticket de Bugzilla:
1. Vaya al sitio web de Bugzilla.
2. Como componente, utilice Documentation.
3. Rellene el campo Description con su sugerencia de mejora. Incluya un enlace a la(s)

parte(s) pertinente(s) de la documentación.
4. Haga clic en Submit Bug.
9
CAPÍTULO 1. CONFIGURACIÓN DEL SERVIDOR WEB APACHE

HTTP
1.1. INTRODUCCIÓN AL SERVIDOR WEB APACHE HTTP

Un web server es un servicio de red que sirve contenidos a un cliente a través de la web. Normalmente
se trata de páginas web, pero también se puede servir cualquier otro documento. Los servidores web
también se conocen como servidores HTTP, ya que utilizan la dirección hypertext transport protocol
(HTTP).
El Apache HTTP Server, httpd, es un servidor web de código abierto desarrollado por la Apache
Software Foundation.
Si está actualizando desde una versión anterior de Red Hat Enterprise Linux, necesitará actualizar la
configuración del servicio httpd en consecuencia. Esta sección revisa algunas de las nuevas
características añadidas y le guía a través de la actualización de los archivos de configuración anteriores.
1.1.1. Cambios notables en el servidor HTTP Apache

El sitio web Apache HTTP Serverse ha actualizado de la versión 2.4.6 a la versión 2.4.37 entre RHEL 7 y
RHEL 8. Esta versión actualizada incluye varias características nuevas, pero mantiene la compatibilidad
con la versión RHEL 7 a nivel de configuración y de la interfaz binaria de aplicación (ABI) de los módulos
externos.
Las nuevas características incluyen:
la compatibilidad conHTTP/2 la proporciona ahora el paquete mod_http2, que forma parte del
módulo httpd.
se admite la activación de sockets systemd. Consulte la página de manual httpd.socket(8) para

obtener más detalles.
Se han añadido varios módulos nuevos:
mod_proxy_hcheck - un módulo de comprobación de la salud del proxy
mod_proxy_uwsgi - un proxy de la Interfaz del Servidor Web (WSGI)
mod_proxy_fdpass - proporciona soporte para pasar el socket del cliente a otro proceso
mod_cache_socache - una caché HTTP que utiliza, por ejemplo, memcache backend
mod_md - un servicio de certificados SSL/TLS de protocolo ACME
Los siguientes módulos ahora se cargan por defecto:
mod_request
mod_macro
mod_watchdog
Se ha añadido un nuevo subpaquete, httpd-filesystem, que contiene la disposición básica de

los directorios para el Apache HTTP Server incluyendo los permisos correctos para los
directorios.
Se ha introducido el soporte de servicios instanciados, httpd@.service. Consulte la página de

10
CAPÍTULO 1. CONFIGURACIÓN DEL SERVIDOR WEB APACHE HTTP
Se ha introducido el soporte de servicios instanciados, httpd@.service. Consulte la página de

manual httpd.service para obtener más información.
Un nuevo httpd-init.service sustituye al %post script para crear un par de claves autofirmadas
mod_ssl.
El aprovisionamiento y la renovación automatizados de certificados TLS mediante el protocolo

Automatic Certificate Management Environment (ACME) son ahora compatibles con el
paquete mod_md (para su uso con proveedores de certificados como Let’s Encrypt).
El sitio web Apache HTTP Server ahora soporta la carga de certificados TLS y claves privadas
de tokens de seguridad de hardware directamente desde los módulos PKCS#11. Como
resultado, una configuración de mod_ssl puede ahora utilizar URLs de PKCS#11 para
identificar la clave privada TLS y, opcionalmente, el certificado TLS en las directivas
SSLCertificateKeyFile y SSLCertificateFile.
Ahora se admite una nueva directiva ListenFree en el archivo /etc/httpd/conf/httpd.conf.

De forma similar a la directiva Listen, ListenFree proporciona información sobre las direcciones
IP, los puertos o las combinaciones de dirección IP y puerto que escucha el servidor. Sin
embargo, con ListenFree, la opción de socket IP_FREEBIND está habilitada por defecto. Por
lo tanto, a httpd se le permite enlazar con una dirección IP no local o con una dirección IP que
aún no existe. Esto permite que httpd escuche en un socket sin requerir que la interfaz de red
subyacente o la dirección IP dinámica especificada estén activas en el momento en que httpd
intenta enlazarse a ella.
Tenga en cuenta que la directiva ListenFree sólo está disponible actualmente en RHEL 8.
Para más detalles sobre ListenFree, consulte la siguiente tabla:
Tabla 1.1. Sintaxis, estado y módulos de la directiva ListenFree
Sintaxis Estado Módulos
ListenFree [dirección MPM evento, trabajador, prefork,

IP:]número de puerto mpm_winnt, mpm_netware,
[protocolo] mpmt_os2
Otros cambios notables son:
Se han eliminado los siguientes módulos:
mod_file_cache
mod_nss
Utilice mod_ssl en su lugar. Para más detalles sobre la migración desde mod_nss, consulte
Sección 1.10, “Exportación de una clave privada y de certificados de una base de datos NSS
para utilizarlos en una configuración de servidor web Apache”.
mod_perl
El tipo por defecto de la base de datos de autenticación DBM utilizada por el Apache HTTP
Server en RHEL 8 se ha cambiado de SDBM a db5.
El módulo mod_wsgi para el Apache HTTP Server ha sido actualizado a Python 3. Las
aplicaciones WSGI ahora sólo son compatibles con Python 3, y deben ser migradas desde
Python 2.
11
El módulo de multiprocesamiento (MPM) configurado por defecto con el Apache HTTP Server
ha cambiado de un modelo multiproceso y bifurcado (conocido como prefork) a un modelo
multihilo de alto rendimiento, event.
Cualquier módulo de terceros que no sea seguro para los hilos debe ser reemplazado o
eliminado. Para cambiar el MPM configurado, edite el archivo /etc/httpd/conf.modules.d/00-
mpm.conf. Consulte la página man httpd.service(8) para obtener más información.
Los UID y GID mínimos permitidos para los usuarios por suEXEC son ahora 1000 y 500,
respectivamente (antes 100 y 100).
El archivo /etc/sysconfig/httpd ya no es una interfaz compatible para establecer variables de

entorno para el servicio httpd. Se ha añadido la página man httpd.service(8) para el servicio
systemd.
Al detener el servicio httpd se utiliza ahora una "parada elegante" por defecto.
El módulo mod_auth_kerb ha sido sustituido por el módulo mod_auth_gssapi.
1.1.2. Actualización de la configuración

Para actualizar los archivos de configuración desde la Apache HTTP Server versión utilizada en Red
Hat Enterprise Linux 7, elija una de las siguientes opciones:
Si se utiliza /etc/sysconfig/httpd para establecer variables de entorno, cree un archivo drop-in

systemd en su lugar.
Si se utilizan módulos de terceros, asegúrese de que son compatibles con un MPM roscado.
Si se utiliza suexec, asegúrese de que los identificadores de usuario y grupo cumplen los nuevos
mínimos.
Puede comprobar la configuración en busca de posibles errores utilizando el siguiente comando:
# apachectl configtest
Syntax OK
1.2. LOS ARCHIVOS DE CONFIGURACIÓN DE APACHE

Cuando el servicio httpd se inicia, por defecto, lee la configuración de las ubicaciones que se enumeran
en Tabla 1.2, “Los archivos de configuración del servicio httpd” .
Tabla 1.2. Los archivos de configuración del servicio httpd
Ruta Descripción
/etc/httpd/conf/httpd.conf El archivo de configuración principal.
/etc/httpd/conf.d/ Un directorio auxiliar para los archivos de

configuración que se incluyen en el archivo de
configuración principal.
12
Ruta Descripción
/etc/httpd/conf.modules.d/ Un directorio auxiliar para los archivos de

configuración que cargan los módulos dinámicos
instalados y empaquetados en Red Hat Enterprise
Linux. En la configuración por defecto, estos archivos
de configuración se procesan primero.
Aunque la configuración por defecto es adecuada para la mayoría de las situaciones, puede utilizar
también otras opciones de configuración. Para que cualquier cambio surta efecto, reinicie primero el
servidor web. Consulte Sección 1.3, “Gestión del servicio httpd” para obtener más información sobre
cómo reiniciar el servicio httpd.
Para comprobar la configuración en busca de posibles errores, escriba lo siguiente en un prompt del
shell:
# apachectl configtest
Syntax OK
Para facilitar la recuperación de los errores, haga una copia del archivo original antes de editarlo.
1.3. GESTIÓN DEL SERVICIO HTTPD

Esta sección describe cómo iniciar, detener y reiniciar el servicio httpd.
Requisitos previos
El servidor HTTP Apache está instalado.
Procedimiento
Para iniciar el servicio httpd, introduzca:
# systemctl start httpd
Para detener el servicio httpd, introduzca:
# systemctl stop httpd
Para reiniciar el servicio httpd, introduzca:
# systemctl restart httpd
1.4. CONFIGURACIÓN DE UN SERVIDOR HTTP APACHE DE UNA SOLA

INSTANCIA
Esta sección describe cómo configurar un servidor HTTP Apache de una sola instancia para servir
contenido HTML estático.
Siga el procedimiento de esta sección si el servidor web debe proporcionar el mismo contenido para
13
todos los dominios asociados al servidor. Si desea proporcionar un contenido diferente para diferentes
dominios, configure hosts virtuales basados en nombres. Para más detalles, consulte Sección 1.5,
“Configuración de hosts virtuales basados en nombres de Apache”.
Procedimiento
1. Instale el paquete httpd:
# yum install httpd
2. Abra el puerto TCP 80 en el firewall local:
# firewall-cmd --permanent --add-port=80/tcp

# firewall-cmd --reload
3. Habilite e inicie el servicio httpd:
# systemctl enable --now httpd
4. Opcional: Añada los archivos HTML al directorio /var/www/html/.
NOTA
Al añadir contenido a /var/www/html/, los archivos y directorios deben ser

legibles por el usuario bajo el cual se ejecuta httpd por defecto. El propietario del
contenido puede ser el usuario root y el grupo de usuarios root, u otro usuario o
grupo a elección del administrador. Si el propietario del contenido es el usuario
root y el grupo de usuarios root, los archivos deben poder ser leídos por otros
usuarios. El contexto SELinux para todos los archivos y directorios debe ser
httpd_sys_content_t, que se aplica por defecto a todo el contenido dentro del
directorio /var/www.
Pasos de verificación
Conéctese con un navegador web para http://server_IP_or_host_name/.

Si el directorio /var/www/html/ está vacío o no contiene un archivo index.html o index.htm,
Apache muestra el Red Hat Enterprise Linux Test Page. Si /var/www/html/ contiene archivos
HTML con un nombre diferente, puede cargarlos introduciendo la URL de ese archivo, como
http://server_IP_or_host_name/example.html.
Recursos adicionales
Para más detalles sobre la configuración de Apache y la adaptación del servicio a su entorno,
consulte el manual de Apache. Para más detalles sobre la instalación del manual, consulte
Sección 1.8, “Instalación del manual del servidor HTTP Apache” .
Para más detalles sobre el uso o el ajuste del servicio httpd systemd , consulte la página man
httpd.service(8).
1.5. CONFIGURACIÓN DE HOSTS VIRTUALES BASADOS EN NOMBRES

DE APACHE
Los hosts virtuales basados en nombres permiten a Apache servir diferentes contenidos para diferentes
14
Los hosts virtuales basados en nombres permiten a Apache servir diferentes contenidos para diferentes
dominios que se resuelven a la dirección IP del servidor.
El procedimiento en esta sección describe la configuración de un host virtual para el dominio

example.com y example.net con directorios raíz de documentos separados. Ambos hosts virtuales
sirven contenido HTML estático.
Requisitos previos
Los clientes y el servidor web resuelven el dominio example.com y example.net a la dirección

IP del servidor web.
Tenga en cuenta que debe añadir manualmente estas entradas a su servidor DNS.
Procedimiento
1. Instale el paquete httpd:
# yum install httpd
2. Edite el archivo /etc/httpd/conf/httpd.conf:
a. Añada la siguiente configuración de host virtual para el dominio example.com:
<VirtualHost *:80>
DocumentRoot "/var/www/example.com/"
ServerName example.com
CustomLog /var/log/httpd/example.com_access.log combined
ErrorLog /var/log/httpd/example.com_error.log
</VirtualHost>
Estos ajustes configuran lo siguiente:
Todos los ajustes de la directiva <VirtualHost *:80> son específicos para este host
virtual.
DocumentRoot establece la ruta del contenido web del host virtual.
ServerName establece los dominios para los que este host virtual sirve contenido.
Para establecer varios dominios, añada el parámetro ServerAlias a la configuración y
especifique los dominios adicionales separados con un espacio en este parámetro.
CustomLog establece la ruta del registro de acceso del host virtual.
ErrorLog establece la ruta del registro de errores del host virtual.
NOTA
Apache utiliza el primer host virtual encontrado en la configuración

también para las peticiones que no coinciden con ningún dominio
establecido en los parámetros ServerName y ServerAlias. Esto también
incluye las peticiones enviadas a la dirección IP del servidor.
3. Añada una configuración de host virtual similar para el dominio example.net:
<VirtualHost *:80>
15
DocumentRoot "/var/www/example.net/"
ServerName example.net
CustomLog /var/log/httpd/example.net_access.log combined
ErrorLog /var/log/httpd/example.net_error.log
</VirtualHost>
4. Cree las raíces de los documentos para ambos hosts virtuales:
# mkdir /var/www/example.com/
# mkdir /var/www/example.net/
5. Si establece rutas en los parámetros de DocumentRoot que no están dentro de /var/www/,

establezca el contexto httpd_sys_content_t en ambas raíces del documento:
# semanage fcontext -a -t httpd_sys_content_t "/srv/example.com(/.*)?"

# restorecon -Rv /srv/example.com/
# semanage fcontext -a -t httpd_sys_content_t "/srv/example.net(/.\*)?"
# restorecon -Rv /srv/example.net/
Estos comandos establecen el contexto httpd_sys_content_t en el directorio

/srv/example.com/ y /srv/example.net/.
Tenga en cuenta que debe instalar el paquete policycoreutils-python-utils para ejecutar el

comando restorecon.
6. Abra el puerto 80 en el firewall local:

7. Habilite e inicie el servicio httpd:
# systemctl enable --now httpd
1. Cree un archivo de ejemplo diferente en la raíz de documentos de cada host virtual:
# echo "vHost example.com" > /var/www/example.com/index.html

# echo "vHost example.net" > /var/www/example.net/index.html
2. Utilice un navegador y conéctese a http://example.com. El servidor web muestra el archivo de

ejemplo del host virtual example.com.
3. Utilice un navegador y conéctese a http://example.net. El servidor web muestra el archivo de

ejemplo del host virtual example.net.
Para más detalles sobre la configuración de los hosts virtuales de Apache, consulte la
documentación de Virtual Hosts en el manual de Apache. Para más detalles sobre la instalación
del manual, consulte Sección 1.8, “Instalación del manual del servidor HTTP Apache” .
16
1.6. CONFIGURACIÓN DEL CIFRADO TLS EN UN SERVIDOR HTTP

APACHE
Por defecto, Apache proporciona contenido a los clientes utilizando una conexión HTTP sin cifrar. Esta
sección describe cómo habilitar el cifrado TLS y configurar las opciones más frecuentes relacionadas
con el cifrado en un servidor HTTP Apache.
Requisitos previos
El servidor HTTP Apache está instalado y funcionando.
1.6.1. Cómo añadir el cifrado TLS a un servidor HTTP Apache

Esta sección describe cómo activar el cifrado TLS en un servidor HTTP Apache para el dominio
example.com.
Requisitos previos
La clave privada se almacena en el archivo /etc/pki/tls/private/example.com.key.

Para obtener detalles sobre la creación de una clave privada y una solicitud de firma de
certificado (CSR), así como para solicitar un certificado a una autoridad de certificación (CA),
consulte la documentación de su CA. Como alternativa, si su CA admite el protocolo ACME,
puede utilizar el módulo mod_md para automatizar la recuperación y el aprovisionamiento de
certificados TLS.
El certificado TLS se almacena en el archivo /etc/pki/tls/private/example.com.crt. Si utiliza una

ruta diferente, adapte los pasos correspondientes del procedimiento.
El certificado CA se almacena en el archivo /etc/pki/tls/private/ca.crt. Si utiliza una ruta

diferente, adapte los pasos correspondientes del procedimiento.
Los clientes y el servidor web resuelven el nombre de host del servidor a la dirección IP del
servidor web.
Procedimiento
1. Instale el paquete mod_ssl:
# dnf install mod_ssl
2. Edite el archivo /etc/httpd/conf.d/ssl.conf y añada la siguiente configuración a la directiva

<VirtualHost _default_:443>:
a. Establezca el nombre del servidor:
Nombre del servidor example.com
IMPORTANTE
El nombre del servidor debe coincidir con la entrada establecida en el campo

Common Name del certificado.
b. Opcional: Si el certificado contiene nombres de host adicionales en el campo Subject Alt

17
b. Opcional: Si el certificado contiene nombres de host adicionales en el campo Subject Alt

Names (SAN), puede configurar mod_ssl para que proporcione cifrado TLS también para
estos nombres de host. Para configurarlo, añada el parámetro ServerAliases con los
nombres correspondientes:
ServidorAlias www.example.com server.example.com
c. Establezca las rutas de acceso a la clave privada, el certificado del servidor y el certificado
de la CA:
SSLCertificateKeyFile "/etc/pki/tls/private/example.com.key"
SSLCertificateFile "/etc/pki/tls/certs/example.com.crt"
SSLCACertificateFile "/etc/pki/tls/certs/ca.crt"
3. Por razones de seguridad, configure que sólo el usuario root pueda acceder al archivo de la
clave privada:
# chown root:root /etc/pki/tls/private/example.com.key

# chmod 600 /etc/pki/tls/private/example.com.key

AVISO
Si los usuarios no autorizados accedieron a la clave privada, revoque el

certificado, cree una nueva clave privada y solicite un nuevo certificado. En
caso contrario, la conexión TLS deja de ser segura.
4. Abra el puerto 443 en el firewall local:
# firewall-cmd --permanent --add-port=443

5. Reinicie el servicio httpd:
NOTA
Si protegió el archivo de clave privada con una contraseña, deberá introducirla

cada vez que se inicie el servicio httpd.
Utilice un navegador y conéctese a https://example.com.
Para más detalles sobre la configuración de TLS, consulte la documentación de SSL/TLS
18
Para más detalles sobre la configuración de TLS, consulte la documentación de SSL/TLS

Encryption en el manual de Apache. Para más detalles sobre la instalación del manual, consulte
Sección 1.8, “Instalación del manual del servidor HTTP Apache” .
1.6.2. Configuración de las versiones de protocolo TLS admitidas en un servidor

HTTP Apache
Por defecto, el servidor HTTP Apache en RHEL 8 utiliza la política crypto de todo el sistema que define
valores seguros por defecto, que además son compatibles con los navegadores recientes. Por ejemplo,
la política DEFAULT define que sólo las versiones del protocolo TLSv1.2 y TLSv1.3 están habilitadas
en apache.
Esta sección describe cómo configurar manualmente las versiones del protocolo TLS que soporta su
servidor HTTP Apache. Siga el procedimiento si su entorno requiere habilitar sólo versiones específicas
del protocolo TLS, por ejemplo:
Si su entorno requiere que los clientes también puedan utilizar el protocolo débil TLS1
(TLSv1.0) o TLS1.1.
Si quiere configurar que Apache sólo soporte el protocolo TLSv1.2 o TLSv1.3.
Requisitos previos
El cifrado TLS está habilitado en el servidor como se describe en Sección 1.6.1, “Cómo añadir el
cifrado TLS a un servidor HTTP Apache”.
Procedimiento
1. Edite el archivo /etc/httpd/conf/httpd.conf y añada la siguiente configuración a la directiva

<VirtualHost> para la que desea establecer la versión del protocolo TLS. Por ejemplo, para
habilitar sólo el protocolo TLSv1.3:
SSLProtocolo -Todo TLSv1.3
1. Utilice el siguiente comando para verificar que el servidor soporta TLSv1.3:
# openssl s_client -connect example.com:443 -tls1_3
2. Utilice el siguiente comando para verificar que el servidor no soporta TLSv1.2:
# openssl s_client -connect example.com:443 -tls1_2
Si el servidor no soporta el protocolo, el comando devuelve un error:
140111600609088:error:1409442E:Rutinas SSL:ssl3_read_bytes:versión del protocolo de

alerta tlsv1:ssl/record/rec_layer_s3.c:1543:Número de alerta SSL 70
19
3. Opcional: Repita el comando para otras versiones del protocolo TLS.
Para más detalles sobre la política criptográfica a nivel de sistema, consulte la página man
update-crypto-policies(8) y Using system-wide cryptographic policies .
Para más detalles sobre el parámetro SSLProtocol, consulte la documentación de mod_ssl en

el manual de Apache. Para más detalles sobre la instalación del manual, consulte Sección 1.8,
“Instalación del manual del servidor HTTP Apache”.
1.6.3. Cómo configurar los cifrados admitidos en un servidor HTTP Apache

Por defecto, el servidor HTTP Apache en RHEL 8 utiliza la política de cifrado de todo el sistema que
define valores seguros por defecto, que también son compatibles con los navegadores recientes. Para
ver la lista de cifrados que permite la política de cifrado de todo el sistema, consulte el archivo
/etc/crypto-policies/back-ends/openssl.config.
Esta sección describe cómo configurar manualmente los cifrados que soporta su servidor HTTP Apache.
Siga el procedimiento si su entorno requiere cifrados específicos.
Requisitos previos
Procedimiento
1. Edite el archivo /etc/httpd/conf/httpd.conf y añada el parámetro SSLCipherSuite a la directiva

<VirtualHost> para la que desea establecer los cifrados TLS:
SSLCipherSuite \ "EECDH AESGCM:EDH AESGCM:AES256 EECDH:AES256

EDH:!SHA1:!SHA256"
Este ejemplo activa sólo los cifrados EECDH AESGCM, EDH AESGCM, AES256 EECDH, y
AES256 EDH y desactiva todos los cifrados que utilizan el código de autenticación de mensajes
(MAC) SHA1 y SHA256.
1. Para mostrar la lista de cifrados que soporta el servidor HTTP Apache:
a. Instale el paquete nmap:
# yum install nmap
b. Utiliza la utilidad nmap para mostrar los cifrados soportados:
# nmap --script ssl-enum-ciphers -p 443 example.com

...
20
PORT STATE SERVICE

443/tcp open https
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
...
Para más detalles sobre la política criptográfica a nivel de sistema, consulte la página man
update-crypto-policies(8) y Using system-wide cryptographic policies .
Para más detalles sobre el parámetro SSLCipherSuite, consulte la documentación de mod_ssl

en el manual de Apache. Para más detalles sobre la instalación del manual, consulte Sección 1.8,
“Instalación del manual del servidor HTTP Apache”.
1.7. CONFIGURACIÓN DE LA AUTENTICACIÓN DEL CERTIFICADO DE

CLIENTE TLS
La autenticación de certificados de cliente permite a los administradores permitir que sólo los usuarios
que se autentiquen utilizando un certificado puedan acceder a los recursos del servidor web. Esta
sección describe cómo configurar la autenticación de certificados de cliente para el directorio
/var/www/html/Example/.
Si el servidor HTTP Apache utiliza el protocolo TLS 1.3, algunos clientes requieren una configuración
adicional. Por ejemplo, en Firefox, establezca el parámetro security.tls.enable_post_handshake_auth
en el menú about:config a true. Para más detalles, consulte Transport Layer Security versión 1.3 en Red
Hat Enterprise Linux 8.
Requisitos previos
Procedimiento
1. Edite el archivo /etc/httpd/conf/httpd.conf y añada la siguiente configuración a la directiva

<VirtualHost> para la que desea configurar la autenticación del cliente:
<Directory "/var/www/html/Example/">
SSLVerifyClient require
</Directory>
La configuración SSLVerifyClient require define que el servidor debe validar con éxito el
certificado del cliente antes de que éste pueda acceder al contenido del directorio
21
1. Utilice la utilidad curl para acceder a la URL https://example.com/Example/ sin autenticación

de cliente:
$ curl https://example.com/Example/
curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert
certificate required, errno 0
El error indica que el servidor web requiere un certificado de autentificación del cliente.
2. Pase la clave privada y el certificado del cliente, así como el certificado de la CA a curl para
acceder a la misma URL con autenticación de cliente:
$ curl --cacert ca.crt --key client.key --cert client.crt https://example.com/Example/
Si la solicitud tiene éxito, curl muestra el archivo index.html almacenado en el directorio

Para más detalles sobre la autenticación de clientes, consulte la documentación de mod_ssl

Configuration How-To en el manual de Apache. Para más detalles sobre la instalación del
manual, consulte Sección 1.8, “Instalación del manual del servidor HTTP Apache” .
1.8. INSTALACIÓN DEL MANUAL DEL SERVIDOR HTTP APACHE

Esta sección describe cómo instalar el manual del servidor HTTP Apache. Este manual proporciona una
documentación detallada de, por ejemplo:
Parámetros y directivas de configuración
Ajuste del rendimiento
Configuración de la autenticación
Módulos
Caché de contenidos
Consejos de seguridad
Configuración del cifrado TLS
Después de instalar el manual, puede visualizarlo mediante un navegador web.
Requisitos previos
Procedimiento
1. Instale el paquete httpd-manual:
# yum install httpd-manual
22
2. Opcional: Por defecto, todos los clientes que se conectan al servidor HTTP Apache pueden
mostrar el manual. Para restringir el acceso a un rango IP específico, como la subred
192.0.2.0/24, edite el archivo /etc/httpd/conf.d/manual.conf y añada la configuración Require
ip 192.0.2.0/24 a la directiva <Directory "/usr/share/httpd/manual">:
<Directory "/usr/share/httpd/manual">
...
Require ip 192.0.2.0/24
...
</Directory>
1. Para visualizar el manual del servidor HTTP Apache, conéctese con un navegador web a
http://host_name_or_IP_address/manual/
1.9. TRABAJAR CON MÓDULOS

Al tratarse de una aplicación modular, el servicio httpd se distribuye junto con una serie de Dynamic
Shared Objects (DSOs), que pueden cargarse o descargarse dinámicamente en tiempo de ejecución,
según sea necesario. Estos módulos se encuentran en el directorio /usr/lib64/httpd/modules/.
1.9.1. Cargar un módulo

Para cargar un módulo DSO concreto, utilice la directiva LoadModule. Tenga en cuenta que los
módulos proporcionados por un paquete independiente suelen tener su propio archivo de configuración
en el directorio /etc/httpd/conf.modules.d/.
Ejemplo 1.1. Carga del DSO mod_ssl
LoadModule ssl_module modules/mod_ssl.so
Después de cargar el módulo, reinicie el servidor web para recargar la configuración. Consulte
Sección 1.3, “Gestión del servicio httpd” para obtener más información sobre cómo reiniciar el servicio
httpd.
1.9.2. Escribir un módulo

Para crear un nuevo módulo DSO, asegúrese de tener instalado el paquete httpd-devel. Para ello,
introduzca el siguiente comando como root:
# yum install httpd-devel
Este paquete contiene los archivos de inclusión, los archivos de cabecera y la utilidad APache
eXtenSion (apxs) necesarios para compilar un módulo.
Una vez escrito, puedes construir el módulo con el siguiente comando:
23
# apxs -i -a -c nombre_del_módulo.c
Si la compilación fue exitosa, debería poder cargar el módulo de la misma manera que cualquier otro
módulo que se distribuya con el archivo Apache HTTP Server.
1.10. EXPORTACIÓN DE UNA CLAVE PRIVADA Y DE CERTIFICADOS DE

UNA BASE DE DATOS NSS PARA UTILIZARLOS EN UNA
CONFIGURACIÓN DE SERVIDOR WEB APACHE
RHEL 8 ya no proporciona el módulo mod_nss para el servidor web Apache y Red Hat recomienda
utilizar el módulo mod_ssl. Si almacena su clave privada y sus certificados en una base de datos de
Servicios de Seguridad de Red (NSS), por ejemplo, porque migró el servidor web de RHEL 7 a RHEL 8,
siga este procedimiento para extraer la clave y los certificados en formato de Correo de Privacidad
Mejorado (PEM). A continuación, puede utilizar los archivos en la configuración de mod_ssl como se
describe en Sección 1.6, “Configuración del cifrado TLS en un servidor HTTP Apache” .
Este procedimiento asume que la base de datos NSS está almacenada en /etc/httpd/alias/ y que usted
almacena la clave privada y los certificados exportados en el directorio /etc/pki/tls/.
Requisitos previos
La clave privada, el certificado y el certificado de la autoridad de certificación (CA) se

almacenan en una base de datos del NSS.
Procedimiento
1. Enumerar los certificados en la base de datos del NSS:
# certutil -d /etc/httpd/alias/ -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Example CA C,,
Example Server Certificate u,u,u
En los próximos pasos necesitará los nombres de los certificados.
2. Para extraer la clave privada, debe exportar temporalmente la clave a un archivo PKCS #12:
a. Utilice el apodo del certificado asociado a la clave privada, para exportar la clave a un
archivo PKCS #12:
# pk12util -o /etc/pki/tls/private/export.p12 -d /etc/httpd/alias/ -n "Example Server

Certificate"
Enter password for PKCS12 file: password
Re-enter password: password
pk12util: PKCS12 EXPORT SUCCESSFUL
Tenga en cuenta que debe establecer una contraseña en el archivo PKCS #12. Necesitará
esta contraseña en el siguiente paso.
b. Exporte la clave privada del archivo PKCS #12:
# openssl pkcs12 -in /etc/pki/tls/private/export.p12 -out
24
/etc/pki/tls/private/server.key -nocerts -nodes

Enter Import Password: password
MAC verified OK
c. Eliminar el archivo temporal PKCS #12:
# rm /etc/pki/tls/private/export.p12
3. Establezca los permisos en /etc/pki/tls/private/server.key para garantizar que sólo el usuario

root pueda acceder a este archivo:
# chown root:root /etc/pki/tls/private/server.key

# chmod 0600 /etc/pki/tls/private/server.key
4. Utilice el apodo del certificado del servidor en la base de datos del NSS para exportar el
certificado de la CA:
# certutil -d /etc/httpd/alias/ -L -n "Example Server Certificate" -a -o

/etc/pki/tls/certs/server.crt
5. Establezca los permisos en /etc/pki/tls/certs/server.crt para garantizar que sólo el usuario root
pueda acceder a este archivo:
# chown root:root /etc/pki/tls/certs/server.crt

# chmod 0600 /etc/pki/tls/certs/server.crt
6. Utilice el apodo del certificado CA en la base de datos NSS para exportar el certificado CA:
# certutil -d /etc/httpd/alias/ -L -n "Example CA" -a -o /etc/pki/tls/certs/ca.crt
7. Siga Sección 1.6, “Configuración del cifrado TLS en un servidor HTTP Apache” para configurar
el servidor web Apache, y:
Ajuste el parámetro SSLCertificateKeyFile a /etc/pki/tls/private/server.key.
Ajuste el parámetro SSLCertificateFile a /etc/pki/tls/certs/server.crt.
Ajuste el parámetro SSLCACertificateFile a /etc/pki/tls/certs/ca.crt.
La página de manual certutil(1)
La página de manual pk12util(1)
La página de manual pkcs12(1ssl)
1.11. RECURSOS ADICIONALES

httpd(8) - La página del manual del servicio httpd que contiene la lista completa de sus
opciones de línea de comandos.
httpd.service(8) - La página del manual del archivo de la unidad httpd.service, que describe
cómo personalizar y mejorar el servicio.
25
httpd.conf(5) - La página del manual de configuración de httpd, que describe la estructura y la

ubicación de los archivos de configuración de httpd.
apachectl(8) - La página del manual de la Apache HTTP Server Interfaz de control.
26
CAPÍTULO 2. INSTALACIÓN Y CONFIGURACIÓN DE NGINX

NGINX es un servidor de alto rendimiento y modular que puede utilizar, por ejemplo, como:
Servidor web
Proxy inverso
Equilibrador de carga
Esta sección describe cómo NGINX en estos escenarios.
2.1. INSTALACIÓN Y PREPARACIÓN DE NGINX

Red Hat utiliza Application Streams para proporcionar diferentes versiones de NGINX. Esta sección
describe cómo:
Seleccione un flujo e instale NGINX
Abra los puertos necesarios en el cortafuegos
Habilitar e iniciar el servicio nginx
Utilizando la configuración por defecto, NGINX se ejecuta como un servidor web en el puerto 80 y
proporciona contenido desde el directorio /usr/share/nginx/html/.
Requisitos previos
RHEL 8 está instalado.
El host está suscrito al Portal del Cliente de Red Hat.
El servicio firewalld está activado e iniciado.
Procedimiento
1. Muestra los flujos de módulos NGINX disponibles:
# yum module list nginx

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
Name Stream Profiles Summary
nginx 1.14 [d] common [d] nginx webserver
nginx 1.16 common [d] nginx webserver
...
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
2. Si desea instalar un flujo diferente al predeterminado, seleccione el flujo:
# yum module enable nginx:stream_version
3. Instale el paquete nginx:
# yum install nginx
27
4. Abra los puertos en los que NGINX debe prestar su servicio en el cortafuegos. Por ejemplo, para
abrir los puertos por defecto para HTTP (puerto 80) y HTTPS (puerto 443) en firewalld,
introduzca:
# firewall-cmd --permanent --add-port={80/tcp,443/tcp}

5. Habilite el servicio nginx para que se inicie automáticamente al arrancar el sistema:
# systemctl enable nginx
6. Opcionalmente, inicie el servicio nginx:
# systemctl start nginx
Si no desea utilizar la configuración por defecto, sáltese este paso y configure NGINX como
corresponda antes de iniciar el servicio.
1. Utilice la utilidad yum para verificar que el paquete nginx está instalado:
# yum list installed nginx

Installed Packages
nginx.x86_64 1:1.14.1-9.module+el8.0.0+4108+af250afe @rhel-8-for-x86_64-appstream-
rpms
2. Asegúrese de que los puertos en los que NGINX debe prestar su servicio están abiertos en el
firewalld:
# firewall-cmd --list-ports
80/tcp 443/tcp
3. Compruebe que el servicio nginx está activado:
# systemctl is-enabled nginx

enabled
Para más detalles sobre el Gestor de Suscripciones , consulte la guía Uso y configuración del
Gestor de Suscripciones.
Para obtener más detalles sobre los flujos de aplicaciones, los módulos y la instalación de
paquetes, consulte la guía Instalación, gestión y eliminación de componentes del espacio de
usuario.
Para más detalles sobre la configuración de los cortafuegos, consulte la guía sobre la seguridad
de las redes.
2.2. CONFIGURAR NGINX COMO UN SERVIDOR WEB QUE

28
2.2. CONFIGURAR NGINX COMO UN SERVIDOR WEB QUE

PROPORCIONA DIFERENTES CONTENIDOS PARA DIFERENTES
DOMINIOS
Por defecto, NGINX actúa como un servidor web que proporciona el mismo contenido a los clientes para
todos los nombres de dominio asociados a las direcciones IP del servidor. Este procedimiento explica
cómo configurar NGINX:
Para servir peticiones al dominio example.com con contenido del directorio

/var/www/example.com/
Para servir peticiones al dominio example.net con contenido del directorio

/var/www/example.net/
Servir todas las demás solicitudes, por ejemplo, a la dirección IP del servidor o a otros dominios
asociados a la dirección IP del servidor, con contenido del directorio /usr/share/nginx/html/
Requisitos previos
NGINX se instala como se describe en Sección 2.1, “Instalación y preparación de NGINX” .
Los clientes y el servidor web resuelven el dominio example.com y example.net a la dirección

IP del servidor web.
Tenga en cuenta que debe añadir manualmente estas entradas a su servidor DNS.
Procedimiento
1. Edite el archivo /etc/nginx/nginx.conf:
a. Por defecto, el archivo /etc/nginx/nginx.conf ya contiene una configuración de tipo catch-

all. Si ha eliminado esta parte de la configuración, vuelva a añadir el siguiente bloque server
al bloque http del archivo /etc/nginx/nginx.conf:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
root /usr/share/nginx/html;
}
Estos ajustes configuran lo siguiente:
La directiva listen define qué dirección IP y qué puertos escucha el servicio. En este
caso, NGINX escucha en el puerto 80 en todas las direcciones IPv4 e IPv6. El
parámetro default_server indica que NGINX utiliza este bloque server por defecto
para las peticiones que coincidan con las direcciones IP y los puertos.
El parámetro server_name define los nombres de host de los que es responsable este
bloque server. Establecer server_name a _ configura a NGINX para aceptar cualquier
nombre de host para este bloque server.
La directiva root establece la ruta del contenido web para este bloque server.
b. Añade un bloque similar server para el dominio example.com al bloque http:
29
server {
server_name example.com;
root /var/www/example.com/;
access_log /var/log/nginx/example.com/access.log;
error_log /var/log/nginx/example.com/error.log;
}
La directiva access_log define un archivo de registro de acceso independiente para

este dominio.
La directiva error_log define un archivo de registro de errores separado para este

dominio.
c. Añade un bloque similar server para el dominio example.net al bloque http:
server {
server_name example.net;
root /var/www/example.net/;
access_log /var/log/nginx/example.net/access.log;
error_log /var/log/nginx/example.net/error.log;
}
2. Cree los directorios raíz de ambos dominios:
# mkdir -p /var/www/example.com/
# mkdir -p /var/www/example.net/
3. Establezca el contexto httpd_sys_content_t en ambos directorios raíz:
# semanage fcontext -a -t httpd_sys_content_t "/var/www/example.com(/.*)?"

# restorecon -Rv /var/www/example.com/
# semanage fcontext -a -t httpd_sys_content_t "/var/www/example.net(/.\*)?"
# restorecon -Rv /var/www/example.net/
Estos comandos establecen el contexto httpd_sys_content_t en los directorios

/var/www/example.com/ y /var/www/example.net/.
Tenga en cuenta que debe instalar el paquete policycoreutils-python-utils para ejecutar los
comandos de restorecon.
4. Cree los directorios de registro para ambos dominios:
# mkdir /var/log/nginx/example.com/
# mkdir /var/log/nginx/example.net/
5. Reinicie el servicio nginx:
# systemctl restart nginx
1. Cree un archivo de ejemplo diferente en la raíz de documentos de cada host virtual:
30
# echo "Content for example.com" > /var/www/example.com/index.html

# echo "Content for example.net" > /var/www/example.net/index.html
# echo "Catch All content" > /usr/share/nginx/html/index.html
2. Utilice un navegador y conéctese a http://example.com. El servidor web muestra el contenido

de ejemplo del archivo /var/www/example.com/index.html.
3. Utilice un navegador y conéctese a http://example.net. El servidor web muestra el contenido de

ejemplo del archivo /var/www/example.net/index.html.
4. Utilice un navegador y conéctese a http://IP_address_of_the_server. El servidor web muestra

el contenido de ejemplo del archivo /usr/share/nginx/html/index.html.
2.3. AÑADIR ENCRIPTACIÓN TLS A UN SERVIDOR WEB NGINX

Esta sección describe cómo habilitar el cifrado TLS en un servidor web NGINX para el dominio
example.com.
Requisitos previos
La clave privada se almacena en el archivo /etc/pki/tls/private/example.com.key.

Para obtener detalles sobre la creación de una clave privada y una solicitud de firma de
certificado (CSR), así como para solicitar un certificado a una autoridad de certificación (CA),
consulte la documentación de su CA.
El certificado TLS se almacena en el archivo /etc/pki/tls/certs/example.com.crt. Si utiliza una

ruta diferente, adapte los pasos correspondientes del procedimiento.
El certificado de la CA se ha añadido al archivo de certificados TLS del servidor.
Los clientes y el servidor web resuelven el nombre de host del servidor a la dirección IP del
servidor web.
El puerto 443 está abierto en el firewall local.
Procedimiento
1. Edite el archivo /etc/nginx/nginx.conf y añada el siguiente bloque server al bloque http en la

configuración:
server {
listen 443 ssl;
server_name example.com;
root /usr/share/nginx/html;
ssl_certificate /etc/pki/tls/certs/example.com.crt;
ssl_certificate_key /etc/pki/tls/private/example.com.key;
}
2. Por razones de seguridad, configure que sólo el usuario root pueda acceder al archivo de la
clave privada:
31
# chown root:root /etc/pki/tls/private/example.com.key

# chmod 600 /etc/pki/tls/private/example.com.key

AVISO
Si los usuarios no autorizados accedieron a la clave privada, revoque el

certificado, cree una nueva clave privada y solicite un nuevo certificado. En
caso contrario, la conexión TLS deja de ser segura.
Utilice un navegador y conéctese a https://example.com
2.4. CONFIGURAR NGINX COMO PROXY INVERSO PARA EL TRÁFICO

HTTP
Puede configurar el servidor web NGINX para que actúe como proxy inverso para el tráfico HTTP. Por
ejemplo, puede utilizar esta funcionalidad para reenviar las peticiones a un subdirectorio específico en
un servidor remoto. Desde la perspectiva del cliente, éste carga el contenido del host al que accede. Sin
embargo, NGINX carga el contenido real del servidor remoto y lo reenvía al cliente.
Este procedimiento explica cómo reenviar el tráfico al directorio /example del servidor web a la URL
https://example.com.
Requisitos previos
Opcional: El cifrado TLS está activado en el proxy inverso.
Procedimiento
1. Edite el archivo /etc/nginx/nginx.conf y añada la siguiente configuración al bloque server que

debe proporcionar el proxy inverso:
location /example {
proxy_pass https://example.com;
}
El bloque location define que NGINX pase todas las peticiones en el directorio /example a
2. Establezca el parámetro booleano httpd_can_network_connect SELinux en 1 para configurar

que SELinux permita a NGINX reenviar el tráfico:
32
# setsebool -P httpd_can_network_connect 1
Utilice un navegador y conéctese a http://host_name/example y se muestra el contenido de

2.5. CONFIGURACIÓN DE NGINX COMO EQUILIBRADOR DE CARGA

HTTP
Puede utilizar la función de proxy inverso de NGINX para equilibrar la carga del tráfico. Este
procedimiento describe cómo configurar NGINX como un equilibrador de carga HTTP que envía las
peticiones a diferentes servidores, basándose en cuál de ellos tiene el menor número de conexiones
activas. Si ambos servidores no están disponibles, el procedimiento también define un tercer host por
razones de fallback.
Requisitos previos
Procedimiento
1. Edite el archivo /etc/nginx/nginx.conf y añada la siguiente configuración:
http {
upstream backend {
least_conn;
server server1.example.com;
server server2.example.com;
server server3.example.com backup;
}
server {
location / {
proxy_pass http://backend;
}
}
}
La directiva least_conn en el grupo de hosts llamado backend define que NGINX envíe las
peticiones a server1.example.com o server2.example.com, dependiendo del host que tenga
el menor número de conexiones activas. NGINX utiliza server3.example.com solo como
respaldo en caso de que los otros dos hosts no estén disponibles.
Con la directiva proxy_pass establecida en http://backend, NGINX actúa como un proxy

inverso y utiliza el grupo de hosts backend para distribuir las peticiones basándose en la
configuración de este grupo.
En lugar del método de equilibrio de carga least_conn, puede especificar:
33
No hay método para utilizar round robin y distribuir las peticiones de manera uniforme entre
los servidores.
ip_hash para enviar solicitudes de una dirección de cliente al mismo servidor basándose en
un hash calculado a partir de los tres primeros octetos de la dirección IPv4 o de la dirección
IPv6 completa del cliente.
hash para determinar el servidor basándose en una clave definida por el usuario, que puede
ser una cadena, una variable o una combinación de ambas. El parámetro consistent
configura que NGINX distribuya las peticiones entre todos los servidores basándose en el
valor de la clave hash definida por el usuario.
random para enviar solicitudes a un servidor seleccionado al azar.

Para la documentación oficial de NGINX consulte https://nginx.org/en/docs/. Tenga en cuenta
que Red Hat no mantiene esta documentación y que podría no funcionar con la versión de
NGINX que tiene instalada.
34
CAPÍTULO 3. USO DE SAMBA COMO SERVIDOR

Samba implementa el protocolo Server Message Block (SMB) en Red Hat Enterprise Linux. El protocolo
SMB se utiliza para acceder a los recursos de un servidor, como archivos compartidos e impresoras
compartidas. Además, Samba implementa el protocolo DCE RPC (Distributed Computing Environment
Remote Procedure Call) utilizado por Microsoft Windows.
Puedes ejecutar Samba como:
Un miembro del dominio de Active Directory (AD) o NT4
Un servidor independiente
Un controlador de dominio primario (PDC) o un controlador de dominio de respaldo (BDC) de

NT4
NOTA
Red Hat soporta los modos PDC y BDC sólo en instalaciones existentes con
versiones de Windows que soportan dominios NT4. Red Hat recomienda no
configurar un nuevo dominio Samba NT4, porque los sistemas operativos de
Microsoft posteriores a Windows 7 y Windows Server 2008 R2 no admiten
dominios NT4.
Red Hat no soporta la ejecución de Samba como controlador de dominio (DC)

de AD.
Independientemente del modo de instalación, puede compartir opcionalmente directorios e impresoras.

Esto permite a Samba actuar como un servidor de archivos e impresiones.
3.1. ENTENDER LOS DIFERENTES SERVICIOS Y MODOS DE SAMBA

Esta sección describe los diferentes servicios incluidos en Samba y los diferentes modos que puede
configurar.
3.1.1. Los servicios de Samba

Samba proporciona los siguientes servicios:
smbd
Este servicio proporciona servicios de compartición e impresión de archivos utilizando el protocolo
SMB. Además, el servicio es responsable del bloqueo de recursos y de la autenticación de los
usuarios que se conectan. El servicio smb systemd inicia y detiene el demonio smbd.
Para utilizar el servicio smbd, instale el paquete samba.
nmbd
Este servicio proporciona la resolución de nombres de host e IP utilizando el protocolo NetBIOS
sobre IPv4. Además de la resolución de nombres, el servicio nmbd permite navegar por la red SMB
para localizar dominios, grupos de trabajo, hosts, archivos compartidos e impresoras. Para ello, el
servicio comunica esta información directamente al cliente emisor o la reenvía a un navegador local
o principal. El servicio nmb systemd inicia y detiene el demonio nmbd.
Tenga en cuenta que las redes SMB modernas utilizan DNS para resolver los clientes y las
direcciones IP.
35
Para utilizar el servicio nmbd, instale el paquete samba.
winbindd
Este servicio proporciona una interfaz para que el conmutador de servicio de nombres (NSS) utilice
usuarios y grupos de dominio AD o NT4 en el sistema local. Esto permite, por ejemplo, que los
usuarios del dominio se autentiquen en servicios alojados en un servidor Samba o en otros servicios
locales. El servicio winbind systemd inicia y detiene el demonio winbindd.
Si configura Samba como miembro del dominio, winbindd debe iniciarse antes que el servicio smbd.
De lo contrario, los usuarios y grupos del dominio no están disponibles para el sistema local..
Para utilizar el servicio winbindd, instale el paquete samba-winbind.
IMPORTANTE
Red Hat sólo soporta la ejecución de Samba como servidor con el servicio winbindd
para proporcionar usuarios y grupos de dominio al sistema local. Debido a ciertas
limitaciones, tales como la falta de soporte de la lista de control de acceso (ACL) de
Windows y de la recuperación de NT LAN Manager (NTLM), SSSD no es compatible.
3.1.2. Los servicios de seguridad de Samba

El parámetro security en la sección [global] del archivo /etc/samba/smb.conf gestiona cómo Samba
autentifica a los usuarios que se conectan al servicio. Dependiendo del modo en el que se instale Samba,
el parámetro debe establecerse con valores diferentes:
En un miembro del dominio AD, establezcasecurity = ads

En este modo, Samba utiliza Kerberos para autenticar a los usuarios de AD.
Para más detalles sobre la configuración de Samba como miembro del dominio, consulte
Sección 3.5, “Configuración de Samba como servidor miembro del dominio AD” .
En un servidor independiente, configuresecurity = user

En este modo, Samba utiliza una base de datos local para autenticar a los usuarios que se conectan.
Para más detalles sobre la configuración de Samba como servidor independiente, consulte
Sección 3.3, “Configuración de Samba como servidor independiente” .
En un PDC o BDC NT4, configuresecurity = user

En este modo, Samba autentifica a los usuarios en una base de datos local o LDAP.
En un miembro del dominio NT4, configuresecurity = domain
En este modo, Samba autentifica a los usuarios que se conectan a un PDC o BDC de NT4. No se
puede utilizar este modo en los miembros del dominio AD.
Para más detalles sobre la configuración de Samba como miembro del dominio, consulte
Sección 3.5, “Configuración de Samba como servidor miembro del dominio AD” .
Consulte la descripción del parámetro security en la página de manual smb.conf(5).
3.1.3. Escenarios cuando los servicios de Samba y las utilidades de cliente de Samba
cargan y recargan su configuración
36
A continuación se describe cuándo los servicios y utilidades de Samba cargan y recargan su

configuración:
Los servicios de Samba recargan su configuración:
Automáticamente cada 3 minutos
A petición manual, por ejemplo, cuando se ejecuta el comando smbcontrol all reload-
config.
Las utilidades de los clientes de Samba leen su configuración sólo cuando usted las inicia.
Tenga en cuenta que ciertos parámetros, como security, requieren un reinicio del servicio smb para
que surta efecto y no basta con una recarga.
La sección How configuration changes are applied en la página man smb.conf(5)
Las páginas de manual smbd(8), nmbd(8), y winbindd(8)
3.1.4. Editar la configuración de Samba de forma guardada

Los servicios Samba recargan automáticamente su configuración cada 3 minutos. Este procedimiento
describe cómo editar la configuración de Samba de forma que se evite que los servicios recarguen los
cambios antes de que usted haya verificado la configuración mediante la utilidad testparm.
Requisitos previos
Samba está instalado.
Procedimiento
1. Cree una copia del archivo /etc/samba/smb.conf:
# cp /etc/samba/smb.conf /etc/samba/samba.conf.copy
2. Edite el archivo copiado y realice los cambios deseados.
3. Verifique la configuración en el /etc/samba/samba.conf.copy archivo:
# testparm -s /etc/samba/samba.conf.copy
Si testparm informa de errores, arréglelos y vuelva a ejecutar el comando.
4. Anule el archivo /etc/samba/smb.conf con la nueva configuración:
# mv /etc/samba/samba.conf.copy /etc/samba/smb.conf
5. Espere a que los servicios Samba recarguen automáticamente su configuración o recargue

manualmente la configuración:
# smbcontrol all reload-config
37
Sección 3.1.3, “Escenarios cuando los servicios de Samba y las utilidades de cliente de Samba
cargan y recargan su configuración”
3.2. VERIFICACIÓN DE LA CONFIGURACIÓN DE SAMBA

Red Hat recomienda que verifique la configuración de Samba cada vez que actualice el archivo
/etc/samba/smb.conf. Esta sección proporciona detalles al respecto.
3.2.1. Verificación del archivo smb.conf mediante la utilidad testparm

La utilidad testparm verifica que la configuración de Samba en el archivo /etc/samba/smb.conf es
correcta. La utilidad detecta parámetros y valores no válidos, pero también configuraciones incorrectas,
como por ejemplo para el mapeo de ID. Si testparm no informa de ningún problema, los servicios Samba
cargarán con éxito el archivo /etc/samba/smb.conf. Tenga en cuenta que testparm no puede verificar
que los servicios configurados estarán disponibles o funcionarán como se espera.
IMPORTANTE
Red Hat recomienda verificar el archivo /etc/samba/smb.conf utilizando testparm

después de cada modificación de este archivo.
Requisitos previos
Has instalado Samba.
El archivo /etc/samba/smb.conf sale.
Procedimiento
1. Ejecute la utilidad testparm como el usuario root:
# testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Unknown parameter encountered: "log levell"
Processing section "[example_share]"
Loaded services file OK.
ERROR: The idmap range for the domain * (tdb) overlaps with the range of DOMAIN
(ad)!
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions
# Global parameters
[global]
...
[example_share]
...
La salida del ejemplo anterior informa de un parámetro inexistente y de una configuración

incorrecta del mapeo de ID.
38
2. Si testparm informa de parámetros o valores incorrectos, o de otros errores en la configuración,

solucione el problema y vuelva a ejecutar la utilidad.
3.3. CONFIGURACIÓN DE SAMBA COMO SERVIDOR INDEPENDIENTE

Puede configurar Samba como un servidor que no es miembro de un dominio. En este modo de
instalación, Samba autentifica a los usuarios en una base de datos local en lugar de en un DC central.
Además, puede habilitar el acceso de invitados para permitir que los usuarios se conecten a uno o varios
servicios sin autenticación.
3.3.1. Establecimiento de la configuración del servidor independiente

Esta sección describe cómo establecer la configuración del servidor para un servidor autónomo Samba.
Procedimiento
1. Instale el paquete samba:
# yum install samba
2. Edite el archivo /etc/samba/smb.conf y establezca los siguientes parámetros:
[global]
workgroup = Example-WG
netbios name = Server
security = user
log file = /var/log/samba/%m.log

log level = 1
Esta configuración define un servidor independiente llamado Server dentro del grupo de
trabajo Example-WG. Además, esta configuración permite el registro en un nivel mínimo ( 1) y
los archivos de registro se almacenarán en el directorio /var/log/samba/. Samba expandirá la
macro %m en el parámetro log file al nombre NetBIOS de los clientes conectados. Esto
permite archivos de registro individuales para cada cliente.
3. Opcionalmente, configure el uso compartido de archivos o impresoras. Ver:
Sección 3.7, “Configuración de un archivo compartido Samba que utiliza ACLs POSIX”
Sección 3.9, “Configuración de un recurso compartido que utiliza las ACL de Windows”
Sección 3.15, “Configuración de Samba como servidor de impresión”
4. Verifique el archivo /etc/samba/smb.conf:
# testparm
5. Si configura recursos compartidos que requieren autenticación, cree las cuentas de usuario.
Para más detalles, consulte Sección 3.3.2, “Creación y habilitación de cuentas de usuario
locales”.
6. Abra los puertos necesarios y recargue la configuración del cortafuegos mediante la utilidad
firewall-cmd:
39
# firewall-cmd --permanent --add-port={139/tcp,445/tcp}

7. Habilite e inicie el servicio smb:
# systemctl enable --now smb
Para más detalles sobre los parámetros utilizados en el procedimiento, consulte las
descripciones de los parámetros en la página man smb.conf(5).
3.3.2. Creación y habilitación de cuentas de usuario locales

Para permitir que los usuarios se autentiquen cuando se conectan a un recurso compartido, debe crear
las cuentas en el host Samba tanto en el sistema operativo como en la base de datos de Samba. Samba
requiere la cuenta del sistema operativo para validar las listas de control de acceso (ACL) en los objetos
del sistema de archivos y la cuenta de Samba para autenticar a los usuarios que se conectan.
Si utiliza la configuración por defecto passdb backend = tdbsam, Samba almacena las cuentas de
usuario en la base de datos /var/lib/samba/private/passdb.tdb.
El procedimiento de esta sección describe cómo crear un usuario local de Samba llamado example.
Requisitos previos
Samba se instala configurado como un servidor independiente.
Procedimiento
1. Crear la cuenta del sistema operativo:
# useradd -M -s /sbin/nologin example
Este comando añade la cuenta example sin crear un directorio de inicio. Si la cuenta sólo se
utiliza para autenticarse en Samba, asigne el comando /sbin/nologin como shell para evitar que
la cuenta se registre localmente.
2. Establezca una contraseña a la cuenta del sistema operativo para habilitarla:
# passwd example
Enter new UNIX password: password
Retype new UNIX password: password
passwd: password updated successfully
Samba no utiliza la contraseña establecida en la cuenta del sistema operativo para autenticarse.
Sin embargo, es necesario establecer una contraseña para habilitar la cuenta. Si una cuenta está
deshabilitada, Samba deniega el acceso si este usuario se conecta.
3. Añade el usuario a la base de datos Samba y establece una contraseña para la cuenta:
# smbpasswd -a example
New SMB password: password
Retype new SMB password: password
40
Added user example.
Utilice esta contraseña para autenticarse cuando utilice esta cuenta para conectarse a un
recurso compartido de Samba.
4. Habilitar la cuenta Samba:
# smbpasswd -e example
Enabled user example.
3.4. COMPRENDER Y CONFIGURAR LA ASIGNACIÓN DE ID DE SAMBA

Los dominios de Windows distinguen a los usuarios y grupos mediante identificadores de seguridad
(SID) únicos. Sin embargo, Linux requiere UIDs y GIDs únicos para cada usuario y grupo. Si ejecuta
Samba como miembro de un dominio, el servicio winbindd es responsable de proporcionar información
sobre los usuarios y grupos del dominio al sistema operativo.
Para que el servicio winbindd proporcione a Linux identificadores únicos para usuarios y grupos, debe
configurar la asignación de identificadores en el archivo /etc/samba/smb.conf para:
La base de datos local (dominio por defecto)
El dominio AD o NT4 del que es miembro el servidor Samba
Cada dominio de confianza desde el que los usuarios deben poder acceder a los recursos de
este servidor Samba
Samba proporciona diferentes back ends de mapeo de ID para configuraciones específicas. Los back
ends más utilizados son:
Parte trasera Caso de uso
tdb El dominio por defecto * sólo
ad Sólo dominios AD
rid Dominios AD y NT4
autorid AD, NT4 y el dominio por defecto *
3.4.1. Planificación de rangos de ID de Samba

Independientemente de si almacena los UIDs y GIDs de Linux en AD o si configura Samba para
generarlos, cada configuración de dominio requiere un rango de IDs único que no debe solaparse con
ninguno de los otros dominios.
41

AVISO
Si se establecen rangos de ID que se solapan, Samba no funciona correctamente.
Ejemplo 3.1. Rangos de identificación únicos
A continuación se muestran los rangos de asignación de ID no superpuestos para los dominios por
defecto (*), AD-DOM, y el TRUST-DOM.
[global]
...
idmap config * : backend = tdb
idmap config * : range = 10000-999999
idmap config AD-DOM:backend = rid

idmap config AD-DOM:range = 2000000-2999999
idmap config TRUST-DOM:backend = rid

idmap config TRUST-DOM:range = 4000000-4999999
IMPORTANTE
Sólo puede asignar un rango por dominio. Por lo tanto, deje suficiente espacio entre los
rangos de los dominios. Esto le permite ampliar el rango más adelante si su dominio crece.
Si más adelante asigna un rango diferente a un dominio, se perderá la propiedad de los

archivos y directorios creados previamente por estos usuarios y grupos.
3.4.2. The * default domain

En un entorno de dominio, se añade una configuración de asignación de ID para cada uno de los
siguientes elementos:
El dominio al que pertenece el servidor Samba
Cada dominio de confianza que debe poder acceder al servidor Samba
Sin embargo, para todos los demás objetos, Samba asigna IDs del dominio por defecto. Esto incluye:
Usuarios y grupos locales de Samba
Cuentas y grupos incorporados a Samba, como BUILTIN\Administrators
IMPORTANTE
Debe configurar el dominio por defecto como se describe en esta sección para que
Samba funcione correctamente.
42
El back end del dominio por defecto debe ser escribible para almacenar permanentemente los IDs
asignados.
Para el dominio por defecto, puede utilizar uno de los siguientes back ends:
tdb
Cuando configure el dominio por defecto para utilizar el back end tdb, establezca un rango de ID lo
suficientemente grande como para incluir los objetos que se crearán en el futuro y que no forman
parte de una configuración de asignación de ID de dominio definida.
Por ejemplo, establezca lo siguiente en la sección [global] del archivo /etc/samba/smb.conf:

Para más detalles, consulte Sección 3.4.3, “Utilizar el back end de mapeo de ID de tdb” .
autorid
Cuando se configura el dominio por defecto para utilizar el back end autorid, añadir configuraciones
adicionales de mapeo de ID para los dominios es opcional.
Por ejemplo, establezca lo siguiente en la sección [global] del archivo /etc/samba/smb.conf:
idmap config * : backend = autorid

Para más detalles, consulte Sección 3.4.6, “Utilizar el back end de mapeo de autorid ID” .
3.4.3. Utilizar el back end de mapeo de ID de tdb

El servicio winbindd utiliza por defecto el back-end de mapeo de ID de escritura tdb para almacenar las
tablas de mapeo de Identificador de Seguridad (SID), UID y GID. Esto incluye a los usuarios locales, los
grupos y los directores incorporados.
Utilice este back end sólo para el dominio por defecto *. Por ejemplo:

Sección 3.4.2, “The * default domain” .
3.4.4. Utilización del back end de mapeo de ID de anuncios

Esta sección describe cómo configurar un miembro de Samba AD para utilizar el back end de mapeo de
IDs ad.
El back end de mapeo de ID de ad implementa una API de sólo lectura para leer la información de
cuentas y grupos de AD. Esto proporciona los siguientes beneficios:
Todas las configuraciones de usuarios y grupos se almacenan de forma centralizada en AD.
Los ID de usuario y grupo son consistentes en todos los servidores Samba que utilizan este back
43
Los ID de usuario y grupo son consistentes en todos los servidores Samba que utilizan este back
end.
Las identificaciones no se almacenan en una base de datos local que pueda corromperse, y por
lo tanto no se pueden perder las titularidades de los archivos.
NOTA
El back-end de asignación de ID ad no es compatible con los dominios de Active

Directory con confianzas unidireccionales. Si configura un miembro del dominio en un
Directorio Activo con confianzas unidireccionales, utilice en su lugar uno de los siguientes
back-ends de asignación de ID: tdb, rid, o autorid.
El back end del anuncio lee los siguientes atributos del AD:
Nombre del atributo Tipo de objeto Asignado a

AD
sAMAccountName Usuario y grupo Nombre de usuario o de grupo, según el objeto
uidNumber Usuario ID de usuario (UID)
gidNumber Grupo ID de grupo (GID)
loginShell [a] Usuario Ruta de acceso al shell del usuario
unixHomeDirectory Usuario Ruta de acceso al directorio principal del usuario

[a]
primaryGroupID [b] Usuario ID del grupo primario
[a] Samba sólo lee este atributo si se establece idmap config DOMAIN:unix_nss_info = yes.
[b] Samba sólo lee este atributo si se establece idmap config DOMAIN:unix_primary_group = yes.
Requisitos previos
Tanto los usuarios como los grupos deben tener IDs únicos establecidos en AD, y los IDs deben
estar dentro del rango configurado en el archivo /etc/samba/smb.conf. Los objetos cuyos IDs
estén fuera del rango no estarán disponibles en el servidor Samba.
Los usuarios y grupos deben tener todos los atributos requeridos en AD. Si faltan los atributos
requeridos, el usuario o grupo no estará disponible en el servidor Samba. Los atributos
requeridos dependen de su configuración. Requisitos previos
La configuración de Samba, excepto la asignación de ID, existe en el archivo

/etc/samba/smb.conf.
44
Procedimiento
1. Edite la sección [global] en el archivo /etc/samba/smb.conf:
a. Añada una configuración de asignación de ID para el dominio por defecto (*) si no existe. Por
ejemplo:

b. Habilite el back end de asignación de ID de ad para el dominio de AD:
idmap config DOMAIN: backend = ad
c. Establezca el rango de IDs que se asigna a los usuarios y grupos en el dominio AD. Por
ejemplo:
idmap config DOMAIN: rango = 2000000-2999999
IMPORTANTE
El rango no debe solaparse con ninguna otra configuración de dominio en

este servidor. Además, el rango debe ser lo suficientemente grande como
para incluir todos los IDs asignados en el futuro. Para más detalles, consulte
Sección 3.4.1, “Planificación de rangos de ID de Samba” .
d. Establezca que Samba utilice el esquema RFC 2307 cuando lea los atributos de AD:
idmap config DOMAIN: schema_mode = rfc2307
e. Para permitir que Samba lea el shell de inicio de sesión y la ruta de acceso al directorio
personal de los usuarios desde el atributo AD correspondiente, establezca:
idmap config DOMAIN: unix_nss_info = yes
Como alternativa, puede establecer una ruta de directorio principal y un shell de inicio de
sesión uniformes para todo el dominio que se apliquen a todos los usuarios. Por ejemplo:
template shell = /bin/bash

template homedir = /home/%U
f. Por defecto, Samba utiliza el atributo primaryGroupID de un objeto de usuario como grupo
principal del usuario en Linux. Como alternativa, puede configurar Samba para que utilice el
valor establecido en el atributo gidNumber en su lugar:
idmap config DOMAIN: unix_primary_group = yes
# testparm
3. Recarga la configuración de Samba:
45
Sección 3.4.2, “The * default domain”
Para más detalles sobre los parámetros utilizados en el procedimiento, consulte las páginas de
manual smb.conf(5) y idmap_ad(8).
Para más detalles sobre la sustitución de variables, consulte la sección VARIABLE

SUBSTITUTIONS en la página de manual smb.conf(5).
3.4.5. Utilización del back end de asignación de ID de crestas

Esta sección describe cómo configurar un miembro del dominio Samba para utilizar el back end de
mapeo de IDs rid.
Samba puede utilizar el identificador relativo (RID) de un SID de Windows para generar un ID en Red Hat
Enterprise Linux.
NOTA
El RID es la última parte de un SID. Por ejemplo, si el SID de un usuario es S-1-5-21-

5421822485-1151247151-421485315-30014, entonces 30014 es el RID correspondiente.
El back end de mapeo de ID de rid implementa una API de sólo lectura para calcular la información de
cuentas y grupos basada en un esquema de mapeo algorítmico para dominios AD y NT4. Cuando
configure el back end, debe establecer el RID más bajo y el más alto en el idmap config DOMAIN :
range parámetro. Samba no mapeará usuarios o grupos con un RID inferior o superior al establecido en
este parámetro.
IMPORTANTE
Como back end de sólo lectura, rid no puede asignar nuevos IDs, como por ejemplo para
los grupos de BUILTIN. Por lo tanto, no utilice este back end para el dominio por defecto
*.
Ventajas de utilizar el back end de rid
Todos los usuarios y grupos del dominio que tienen un RID dentro del rango configurado están
automáticamente disponibles en el miembro del dominio.
No es necesario asignar manualmente IDs, directorios de inicio y shells de inicio de sesión.
Inconvenientes de utilizar el back end de rid
Todos los usuarios del dominio tienen asignados el mismo shell de inicio de sesión y el mismo
directorio personal. Sin embargo, se pueden utilizar variables.
Los ID de usuario y grupo sólo son iguales entre los miembros del dominio Samba si todos
utilizan el back end rid con la misma configuración de rango de ID.
No se puede excluir a usuarios o grupos individuales de estar disponibles en el miembro del

dominio. Sólo se excluyen los usuarios y grupos fuera del rango configurado.
Según las fórmulas que utiliza el servicio winbindd para calcular los ID, pueden producirse
46
Según las fórmulas que utiliza el servicio winbindd para calcular los ID, pueden producirse
duplicados en entornos multidominio si los objetos de diferentes dominios tienen el mismo RID.
Requisitos previos

Procedimiento
a. Añada una configuración de asignación de ID para el dominio por defecto (*) si no existe. Por
ejemplo:

b. Habilite el back end de asignación de ID de rid para el dominio:
idmap config DOMAIN: backend = rid
c. Establezca un rango lo suficientemente grande como para incluir todos los RID que se
asignarán en el futuro. Por ejemplo:
idmap config DOMAIN: rango = 2000000-2999999
Samba ignora a los usuarios y grupos cuyos RIDs en este dominio no están dentro del rango.
IMPORTANTE
El rango no debe solaparse con ninguna otra configuración de dominio en

este servidor. Para más detalles, consulte Sección 3.4.1, “Planificación de
rangos de ID de Samba”.
d. Establezca una ruta de acceso al shell y al directorio principal que se asignará a todos los
usuarios asignados. Por ejemplo:

# testparm
47
Sección 3.4.2, “The * default domain”

Para más detalles sobre cómo Samba calcula el ID local a partir de un RID, consulte la página
man idmap_rid(8).
3.4.6. Utilizar el back end de mapeo de autorid ID

Esta sección describe cómo configurar un miembro del dominio Samba para utilizar el back end de
mapeo de IDs autorid.
El back end autorid funciona de forma similar al back end de mapeo de ID rid, pero puede asignar
automáticamente IDs para diferentes dominios. Esto le permite utilizar el back end autorid en las
siguientes situaciones:
Sólo para el dominio por defecto *
Para el dominio por defecto * y los dominios adicionales, sin necesidad de crear configuraciones
de asignación de ID para cada uno de los dominios adicionales
Sólo para dominios específicos
NOTA
Si utiliza autorid para el dominio por defecto, añadir la configuración de asignación de ID

adicional para los dominios es opcional.
Partes de esta sección fueron adoptadas de la documentación de idmap config autorid publicada en el
Wiki de Samba. Licencia: CC BY 4.0. Autores y colaboradores: Ver la pestaña de historia en la página de
la Wiki.
Ventajas de utilizar el back end de autorid
Todos los usuarios y grupos del dominio cuyo UID y GID calculados están dentro del rango
configurado están automáticamente disponibles en el miembro del dominio.
No es necesario asignar manualmente IDs, directorios de inicio y shells de inicio de sesión.
No se duplican los ID, aunque varios objetos en un entorno multidominio tengan el mismo RID.
Inconvenientes
Los ID de usuario y de grupo no son los mismos en todos los miembros del dominio Samba.
Todos los usuarios del dominio tienen asignados el mismo shell de inicio de sesión y el mismo
directorio personal. Sin embargo, se pueden utilizar variables.
No se puede excluir a usuarios o grupos individuales de estar disponibles en el miembro del

dominio. Sólo se excluyen los usuarios y grupos cuyo UID o GID calculado está fuera del rango
configurado.
Requisitos previos
48

Procedimiento
a. Habilite el back end de mapeo de ID de autorid para el dominio por defecto *:
idmap config * : backend = autorid
b. Establezca un rango lo suficientemente grande como para asignar IDs para todos los objetos
existentes y futuros. Por ejemplo:
Samba ignora a los usuarios y grupos cuyos IDs calculados en este dominio no están dentro
del rango.

AVISO
Después de establecer el rango y de que Samba comience a utilizarlo,

sólo puede aumentar el límite superior del rango. Cualquier otro cambio
en el rango puede dar lugar a nuevas asignaciones de ID, y por lo tanto
a la pérdida de la propiedad de los archivos.
c. Opcionalmente, establezca un tamaño de rango. Por ejemplo:
idmap config * : rangesize = 200000
Samba assigns this number of continuous IDs for each domain’s object until all IDs from the
range set in the idmap config * : range parameter are taken.
d. Establezca una ruta de acceso al shell y al directorio principal que se asignará a todos los
usuarios asignados. Por ejemplo:

e. Opcionalmente, añada una configuración adicional de mapeo de ID para los dominios. Si no

hay ninguna configuración para un dominio individual, Samba calcula el ID utilizando la
configuración del back-end autorid en el dominio por defecto previamente configurado *.
IMPORTANTE
Si se configuran extremos posteriores adicionales para dominios individuales,

los rangos para toda la configuración de mapeo de ID no deben
superponerse. Para más detalles, consulte Sección 3.4.1, “Planificación de
rangos de ID de Samba”.
49
# testparm
Para obtener detalles sobre cómo el back end calculó los IDs, consulte la sección THE
MAPPING FORMULAS en la página man idmap_autorid(8).
Para más detalles sobre el uso del parámetro idmap config rangesize , consulte la descripción
del parámetro rangesize en la página de manual idmap_autorid(8).

3.5. CONFIGURACIÓN DE SAMBA COMO SERVIDOR MIEMBRO DEL

DOMINIO AD
Si está ejecutando un dominio AD o NT4, utilice Samba para añadir su servidor Red Hat Enterprise Linux
como miembro del dominio para obtener lo siguiente:
Acceder a los recursos del dominio en otros miembros del dominio
Autenticar a los usuarios del dominio en los servicios locales, como sshd
Compartir directorios e impresoras alojados en el servidor para actuar como servidor de

archivos e impresión
3.5.1. Unir un sistema RHEL a un dominio AD

Esta sección describe cómo unir un sistema Red Hat Enterprise Linux a un dominio AD utilizando realmd
para configurar Samba Winbind.
Procedimiento
1. Si su AD requiere el tipo de cifrado RC4 obsoleto para la autenticación Kerberos, habilite el

soporte para estos cifrados en RHEL:
# update-crypto-policies --set DEFAULT:AD-SUPPORT
2. Instale los siguientes paquetes:
# yum install realmd oddjob-mkhomedir oddjob samba-winbind-clients \ samba-

winbind samba-common-tools samba-winbind-krb5-locator
3. Para compartir directorios o impresoras en el miembro del dominio, instale el paquete samba:
# yum install samba
4. Realice una copia de seguridad del archivo de configuración de Samba existente en

50
4. Realice una copia de seguridad del archivo de configuración de Samba existente en

/etc/samba/smb.conf:
# mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
5. Únase al dominio. Por ejemplo, para unirse a un dominio llamado ad.example.com:
# realm join --membership-software=samba --client-software=winbind ad.example.com
Utilizando el comando anterior, la utilidad realm automáticamente:
Crea un archivo /etc/samba/smb.conf para un miembro del dominio ad.example.com
Añade el módulo winbind para la búsqueda de usuarios y grupos en el archivo

/etc/nsswitch.conf
Actualiza los archivos de configuración del Pluggable Authentication Module (PAM) en el

directorio /etc/pam.d/
Inicia el servicio winbind y permite que el servicio se inicie al arrancar el sistema
6. Opcionalmente, establezca un back end de mapeo de ID alternativo o ajustes de mapeo de ID

personalizados en el archivo /etc/samba/smb.conf. Para más detalles, consulte Sección 3.4,
“Comprender y configurar la asignación de ID de Samba”.
7. Compruebe que el servicio winbind está en funcionamiento:
# systemctl status winbind

...
Active: active (running) since Tue 2018-11-06 19:10:40 CET; 15s ago
IMPORTANTE
Para que Samba pueda consultar la información de los usuarios y grupos del
dominio, el servicio winbind debe estar funcionando antes de iniciar smb.
8. Si ha instalado el paquete samba para compartir directorios e impresoras, active e inicie el

servicio smb:
# systemctl enable --now smb
9. Opcionalmente, si está autenticando inicios de sesión locales en Active Directory, habilite el

complemento winbind_krb5_localauth. Véase Sección 3.5.2, “Uso del complemento de
autorización local para MIT Kerberos”.
1. Muestra los detalles de un usuario AD, como la cuenta de administrador AD en el dominio AD:
# getent passwd "AD\administrator"

AD\administrator:*:10000:10000::/home/administrator@AD:/bin/bash
2. Consultar los miembros del grupo de usuarios del dominio en el dominio AD:
51
# getent group "AD\Domain Users"

AD\domain users:x:10000:user1,user2
3. Opcionalmente, verifique que puede utilizar los usuarios y grupos del dominio cuando
establezca los permisos de los archivos y directorios. Por ejemplo, para establecer el propietario
del archivo /srv/samba/example.txt como AD\administrator y el grupo como AD\Domain
Users:
# chown "AD\administrator":"AD\Domain Users" /srv/samba/example.txt
4. Verifique que la autenticación Kerberos funciona como se espera:
a. En el miembro del dominio AD, obtenga un ticket para la entidad de crédito

administrator@AD.EXAMPLE.COM:
# kinit administrator@AD.EXAMPLE.COM
b. Muestra el ticket de Kerberos en caché:
# klist
Ticket cache: KCM:0
Default principal: administrator@AD.EXAMPLE.COM
Valid starting Expires Service principal

01.11.2018 10:00:00 01.11.2018 20:00:00
krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM
renew until 08.11.2018 05:00:00
5. Muestra los dominios disponibles:
# wbinfo --all-domains
BUILTIN
SAMBA-SERVER
AD
Si no desea utilizar los cifrados RC4 obsoletos, puede activar el tipo de cifrado AES en AD.
Consulte Sección 3.6.2, “Habilitación del tipo de cifrado AES en Active Directory mediante un
GPO”. Tenga en cuenta que esto puede tener un impacto en otros servicios de su AD.
Para más detalles sobre la utilidad realm, consulte la página de manual realm(8).
3.5.2. Uso del complemento de autorización local para MIT Kerberos

El servicio winbind proporciona usuarios de Active Directory al miembro del dominio. En determinadas
situaciones, los administradores desean permitir que los usuarios del dominio se autentiquen en servicios
locales, como un servidor SSH, que se ejecutan en el miembro del dominio. Si utiliza Kerberos para
autenticar a los usuarios del dominio, habilite el complemento winbind_krb5_localauth para asignar
correctamente los principales de Kerberos a las cuentas de Active Directory a través del servicio
winbind.
Por ejemplo, si el atributo sAMAccountName de un usuario de Active Directory está configurado como
EXAMPLE y el usuario intenta iniciar sesión con el nombre de usuario en minúsculas, Kerberos devuelve
52
el nombre de usuario en mayúsculas. Como consecuencia, las entradas no coinciden y la autenticación

falla.
Utilizando el complemento winbind_krb5_localauth, los nombres de las cuentas se asignan

correctamente. Tenga en cuenta que esto sólo se aplica a la autenticación GSSAPI y no para obtener el
ticket inicial de concesión (TGT).
Requisitos previos
Samba está configurado como miembro de un Directorio Activo.
Red Hat Enterprise Linux autentifica los intentos de inicio de sesión contra Active Directory.
El servicio winbind está funcionando.
Procedimiento
Edite el archivo /etc/krb5.conf y añada la siguiente sección:
[plugins]
localauth = {
module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so
enable_only = winbind
}
Consulte la página de manual winbind_krb5_localauth(8).
3.6. CONFIGURACIÓN DE SAMBA EN UN MIEMBRO DEL DOMINIO IDM

Esta sección describe cómo configurar Samba en un host que está unido a un dominio de Red Hat
Identity Management (IdM). Los usuarios de IdM y también, si están disponibles, de los dominios de
confianza de Active Directory (AD), pueden acceder a los recursos compartidos y a los servicios de
impresión proporcionados por Samba.
IMPORTANTE
El uso de Samba en un miembro del dominio IdM es una característica de Technology

Preview no soportada y contiene ciertas limitaciones. Por ejemplo, debido a que los
controladores de confianza de IdM no admiten el servicio de catálogo global, los hosts de
Windows inscritos en AD no pueden encontrar usuarios y grupos de IdM en Windows.
Además, los controladores de confianza de IdM no admiten la resolución de grupos de
IdM mediante los protocolos Distributed Computing Environment / Remote Procedure
Calls (DCE/RPC). Como consecuencia, los usuarios de AD sólo pueden acceder a los
recursos compartidos e impresoras de Samba desde los clientes de IdM.
Se anima a los clientes que despliegan Samba en los miembros del dominio IdM a que
proporcionen sus comentarios a Red Hat.
Requisitos previos
El host se une como cliente al dominio IdM.
Tanto los servidores de IdM como el cliente deben ejecutarse en RHEL 8.1 o posterior.
53
3.6.1. Preparación del dominio IdM para instalar Samba en los miembros del dominio
Antes de establecer una confianza con AD y si desea configurar Samba en un cliente IdM, debe
preparar el dominio IdM mediante la utilidad ipa-adtrust-install en un servidor IdM. Sin embargo,
aunque se den ambas situaciones, debe ejecutar ipa-adtrust-install sólo una vez en un maestro de IdM.
Requisitos previos
El IdM está instalado.
Procedimiento
1. Instale los paquetes necesarios:
[root@ipaserver ~]# yum install ipa-server ipa-server-trust-ad samba-client
2. Autenticarse como usuario administrativo de IdM:
[root@ipaserver ~]# kinit admin
3. Ejecute la utilidad ipa-adtrust-install:
[root@ipaserver ~]# ipa-adtrust-install
Los registros de servicio DNS se crean automáticamente si IdM se ha instalado con un servidor
DNS integrado.
Si IdM se instaló sin un servidor DNS integrado, ipa-adtrust-install imprime una lista de
registros de servicio que deben añadirse manualmente al DNS antes de poder continuar.
4. El script le indica que el /etc/samba/smb.conf ya existe y será reescrito:
WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing
Samba configuration.
Do you wish to continue? [no]: yes
5. El script le pide que configure el complemento slapi-nis, un complemento de compatibilidad

que permite a los clientes de Linux más antiguos trabajar con usuarios de confianza:
Do you want to enable support for trusted domains in Schema Compatibility plugin?
This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.
Enable trusted domains support in slapi-nis? [no]: yes
6. Cuando se le solicite, introduzca el nombre NetBIOS del dominio IdM o pulse Enter para
aceptar el nombre propuesto:
Trust is configured but no NetBIOS domain name found, setting it now.

Enter the NetBIOS name for the IPA domain.
Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
Example: EXAMPLE.
NetBIOS domain name [IDM]:
54
7. Se le pide que ejecute la tarea de generación de SID para crear un SID para cualquier usuario
existente:
¿Desea ejecutar la tarea ipa-sidgen? [no] yes
Cuando el directorio se instala por primera vez, existe al menos un usuario (el administrador de
IdM) y como esta es una tarea que consume muchos recursos, si tienes un número elevado de
usuarios, puedes ejecutarla en otro momento.
8. (Optional) Por defecto, el rango de puertos RPC dinámicos está definido como 49152-65535
para Windows Server 2008 y posteriores. Si necesita definir un rango de puertos RPC
dinámicos diferente para su entorno, configure Samba para utilizar puertos diferentes y abra
esos puertos en la configuración de su cortafuegos. El siguiente ejemplo establece el rango de
puertos en 55000-65000.
[root@ipaserver ~]# net conf setparm global 'rpc server dynamic port range' 55000-
65000
[root@ipaserver ~]# firewall-cmd --add-port=55000-65000/tcp
[root@ipaserver ~]# firewall-cmd --runtime-to-permanent
9. Reinicie el servicio ipa:
[root@ipaserver ~]# ipactl restart
10. Utilice la utilidad smbclient para verificar que Samba responde a la autenticación Kerberos
desde el lado de IdM:
[root@ipaserver ~]# smbclient -L server.idm.example.com -k

lp_load_ex: changing to config backend registry
Sharename Type Comment
--------- ---- -------
IPC$ IPC IPC Service (Samba 4.12.3)
...
3.6.2. Habilitación del tipo de cifrado AES en Active Directory mediante un GPO
Esta sección describe cómo habilitar el tipo de cifrado AES en Active Directory (AD) mediante un objeto
de política de grupo (GPO). Algunas características de RHEL 8, como la ejecución de un servidor
Samba en un cliente IdM, requieren este tipo de cifrado.
Tenga en cuenta que RHEL 8 no soporta los tipos de cifrado débil DES y RC4.
Requisitos previos
Usted está conectado a AD como un usuario que puede editar las políticas de grupo.
El Group Policy Management Console está instalado en el ordenador.
Procedimiento
1. Abra la página web Group Policy Management Console.
2. Haga clic con el botón derecho del ratón en Default Domain Policy, y seleccione Edit. Se abre
55
2. Haga clic con el botón derecho del ratón en Default Domain Policy, y seleccione Edit. Se abre
la página Group Policy Management Editor.
3. Navegue hasta Computer Configuration → Policies → Windows Settings → Security

Settings → Local Policies → Security Options.
4. Haga doble clic en la política Network security: Configure encryption types allowed for
Kerberos.
5. Seleccione AES256_HMAC_SHA1 y, opcionalmente, Future encryption types.
6. Haga clic en Aceptar.
7. Cierre la página Group Policy Management Editor.
8. Repita los pasos para el Default Domain Controller Policy.
9. Espere a que los controladores de dominio (DC) de Windows apliquen la política de grupo
automáticamente. Como alternativa, para aplicar la GPO manualmente en un DC, introduzca el
siguiente comando utilizando una cuenta que tenga permisos de administrador:
C:\N> gpupdate /force /target:computer
3.6.3. Instalación y configuración de un servidor Samba en un cliente IdM

Esta sección describe cómo instalar y configurar Samba en un cliente inscrito en un dominio IdM.
Requisitos previos
Tanto los servidores de IdM como el cliente deben ejecutarse en RHEL 8.1 o posterior.
El dominio IdM se prepara como se describe en Sección 3.6.1, “Preparación del dominio IdM para
instalar Samba en los miembros del dominio”.
Si IdM tiene una confianza configurada con AD, habilite el tipo de cifrado AES para Kerberos. Por
ejemplo, utilice un objeto de política de grupo (GPO) para habilitar el tipo de cifrado AES. Para
obtener más información, consulte Sección 3.6.2, “Habilitación del tipo de cifrado AES en Active
Directory mediante un GPO”.
Procedimiento
1. Instale el paquete ipa-client-samba:
[root@idm_client]# yum install ipa-client-samba
2. Utilice la utilidad ipa-client-samba para preparar el cliente y crear una configuración inicial de
Samba:
[root@idm_client]# ipa-client-samba
Searching for IPA server...
IPA server: DNS discovery
Chosen IPA master: idm_server.idm.example.com
SMB principal to be created: cifs/idm_client.idm.example.com@IDM.EXAMPLE.COM
NetBIOS name to be used: IDM_CLIENT
Discovered domains to use:
56
Domain name: idm.example.com

NetBIOS name: IDM
SID: S-1-5-21-525930803-952335037-206501584
ID range: 212000000 - 212199999
Domain name: ad.example.com

NetBIOS name: AD
SID: None
ID range: 1918400000 - 1918599999
Continue to configure the system with these values? [no]: yes

Samba domain member is configured. Please check configuration at /etc/samba/smb.conf
and start smb and winbind services
3. Por defecto, ipa-client-samba añade automáticamente la sección [homes] al archivo

/etc/samba/smb.conf que comparte dinámicamente el directorio personal de un usuario
cuando éste se conecta. Si los usuarios no tienen directorios personales en este servidor, o si no
desea compartirlos, elimine las siguientes líneas de /etc/samba/smb.conf:
[homes]
read only = no
4. Compartir directorios e impresoras. Para más detalles, consulte:
Sección 3.9, “Configuración de un recurso compartido que utiliza las ACL de Windows”
Sección 3.15, “Configuración de Samba como servidor de impresión”
5. Abra los puertos necesarios para un cliente Samba en el firewall local:
[root@idm_client]# firewall-cmd --permanent --add-service=samba-client

[root@idm_client]# firewall-cmd --reload
6. Habilite e inicie los servicios smb y winbind:
[root@idm_client]# systemctl enable --now smb winbind
Ejecute los siguientes pasos de verificación en otro miembro del dominio IdM que tenga instalado el
paquete samba-client:
1. Autenticar y obtener un ticket de Kerberos:
$ kinit example_user
2. Enumerar los recursos compartidos en el servidor Samba utilizando la autenticación Kerberos:
$ smbclient -L idm_client.idm.example.com -k
57
--------- ---- -------

example Disk
...
Para obtener detalles sobre los pasos que ipa-client-samba realiza durante la configuración,
consulte la página de manual ipa-client-samba(1).
3.6.4. Añadir manualmente una configuración de asignación de ID si IdM confía en

un nuevo dominio
Samba requiere una configuración de asignación de ID para cada dominio desde el que los usuarios
acceden a los recursos. En un servidor Samba existente que se ejecuta en un cliente IdM, debe añadir
manualmente una configuración de asignación de ID después de que el administrador haya añadido una
nueva confianza a un dominio de Active Directory (AD).
Requisitos previos
Has configurado Samba en un cliente IdM. Después, se añadió una nueva confianza a IdM.
Los tipos de cifrado DES y RC4 para Kerberos deben estar desactivados en el dominio AD de
confianza. Por razones de seguridad, RHEL 8 no admite estos tipos de cifrado débil.
Procedimiento
1. Autenticar usando el keytab del host:
[root@idm_client]# kinit -k
2. Utilice el comando ipa idrange-find para mostrar tanto el ID base como el tamaño del rango de
ID del nuevo dominio. Por ejemplo, el siguiente comando muestra los valores del dominio
ad.example.com:
[root@idm_client]# ipa idrange-find --name="AD.EXAMPLE.COM_id_range" --raw

---------------
1 range matched
---------------
cn: AD.EXAMPLE.COM_id_range
ipabaseid: 1918400000
ipaidrangesize: 200000
ipabaserid: 0
ipanttrusteddomainsid: S-1-5-21-968346183-862388825-1738313271
iparangetype: ipa-ad-trust
----------------------------
Number of entries returned 1
----------------------------
Los valores de los atributos ipabaseid y ipaidrangesize son necesarios en los siguientes pasos.
3. Para calcular el ID utilizable más alto, utilice la siguiente fórmula:
rango_máximo = ipabaseid ipaidrangesize - 1
58
Con los valores del paso anterior, el mayor ID utilizable para el dominio ad.example.com es
1918599999 (1918400000 200000 - 1).
4. Edite el archivo /etc/samba/smb.conf y añada la configuración de la asignación de ID para el

dominio en la sección [global]:
idmap config AD : range = 1918400000 - 1918599999

idmap config AD : backend = sss
Especifique el valor del atributo ipabaseid como el más bajo y el valor calculado del paso
anterior como el valor más alto del rango.
5. Reinicie los servicios smb y winbind:
[root@idm_client]# systemctl restart smb winbind
1. Autentifíquese como usuario del nuevo dominio y obtenga un ticket Kerberos:
$ kinit example_user
2. Enumerar los recursos compartidos en el servidor Samba utilizando la autenticación Kerberos:
$ smbclient -L idm_client.idm.example.com -k

--------- ---- -------
example Disk
...
3.6.5. Recursos adicionales

Para obtener más detalles sobre cómo unir RHEL 8 a un dominio IdM, consulte la sección
Installing an Identity Management client sección de la guía Installing Identity Management.
3.7. CONFIGURACIÓN DE UN ARCHIVO COMPARTIDO SAMBA QUE

UTILIZA ACLS POSIX
Como servicio de Linux, Samba soporta recursos compartidos con ACLs POSIX. Éstas le permiten
gestionar los permisos localmente en el servidor Samba utilizando utilidades, como chmod. Si el recurso
compartido se almacena en un sistema de archivos que soporta atributos extendidos, puede definir
ACLs con múltiples usuarios y grupos.
NOTA
Si necesita utilizar ACLs de Windows de grano fino en su lugar, consulte Sección 3.9,
“Configuración de un recurso compartido que utiliza las ACL de Windows”.
Partes de esta sección fueron adoptadas de la documentación Setting up a Share Using POSIX ACLs
59
Partes de esta sección fueron adoptadas de la documentación Setting up a Share Using POSIX ACLs
publicada en el Wiki de Samba. Licencia: CC BY 4.0. Autores y colaboradores: Ver la pestaña de historia
en la página de la Wiki.
3.7.1. Añadir un recurso compartido que utiliza ACLs POSIX

Esta sección describe cómo crear un recurso compartido llamado example que proporciona el
contenido del directorio /srv/samba/example/, y utiliza ACLs POSIX.
Requisitos previos
Samba se ha configurado en uno de los siguientes modos:
Servidor autónomo
Miembro del dominio
Procedimiento
1. Cree la carpeta si no existe. Por ejemplo:
# mkdir -p /srv/samba/example/
2. Si ejecuta SELinux en modo enforcing, establezca el contexto samba_share_t en el directorio:
# semanage fcontext -a -t samba_share_t "/srv/samba/example(/.*)?"

# restorecon -Rv /srv/samba/example/
3. Establezca las ACL del sistema de archivos en el directorio. Para más detalles, consulte:
Sección 3.7.2, “Establecer ACLs estándar de Linux en un recurso compartido de Samba que
utiliza ACLs POSIX”
Sección 3.7.3, “Configuración de ACLs extendidas en un recurso compartido de Samba que

utiliza ACLs POSIX”.
4. Añada el ejemplo de recurso compartido al archivo /etc/samba/smb.conf. Por ejemplo, para

añadir el recurso compartido de escritura:
[example]
path = /srv/samba/example/
read only = no
NOTA
Independientemente de las ACL del sistema de archivos; si no se establece read

only = no, Samba comparte el directorio en modo de sólo lectura.
# testparm
firewall-cmd:
60
# firewall-cmd --permanent --add-service=samba

7. Reinicie el servicio smb:
# systemctl restart smb
3.7.2. Establecer ACLs estándar de Linux en un recurso compartido de Samba que

utiliza ACLs POSIX
Las ACLs estándar en Linux soportan el establecimiento de permisos para un propietario, un grupo y
para todos los demás usuarios no definidos. Puede utilizar las utilidades chown, chgrp, y chmod para
actualizar las ACLs. Si requiere un control preciso, entonces utilice las ACLs POSIX más complejas, vea
Sección 3.7.3, “Configuración de ACLs extendidas en un recurso compartido de Samba que utiliza ACLs
POSIX”. Configuración de ACLs extendidas en un recurso compartido de Samba que utiliza AC Ls
POSIX en la documentación de Deploying different types of servers.
El siguiente procedimiento establece el propietario del directorio /srv/samba/example/ al usuario root,

concede permisos de lectura y escritura al grupo Domain Users y deniega el acceso a todos los demás
usuarios.
Requisitos previos
El recurso compartido de Samba en el que desea establecer las ACL existe.
Procedimiento
# chown root:"Domain Users" /srv/samba/example/

# chmod 2770 /srv/samba/example/
NOTA
La activación del bit set-group-ID (SGID) en un directorio establece automáticamente el

grupo por defecto para todos los nuevos archivos y subdirectorios al del grupo del
directorio, en lugar del comportamiento habitual de establecerlo al grupo primario del
usuario que creó la nueva entrada del directorio.
Para más detalles sobre los permisos, consulte las páginas de manual chown(1) y chmod(1).
3.7.3. Configuración de ACLs extendidas en un recurso compartido de Samba que

utiliza ACLs POSIX
Si el sistema de archivos en el que se almacena el directorio compartido soporta ACLs extendidas,
puede utilizarlas para establecer permisos complejos. Las ACLs extendidas pueden contener permisos
para múltiples usuarios y grupos.
Las ACLs POSIX extendidas permiten configurar ACLs complejas con múltiples usuarios y grupos. Sin
embargo, sólo puede establecer los siguientes permisos:
No hay acceso
61
Leer el acceso
Acceso de escritura
Control total
Si necesita los permisos finos de Windows, como Create folder / append data, configure el recurso
compartido para utilizar las ACL de Windows. Consulte Sección 3.9, “Configuración de un recurso
compartido que utiliza las ACL de Windows”.
El siguiente procedimiento muestra cómo habilitar las ACL extendidas en un recurso compartido.
Además, contiene un ejemplo sobre la configuración de ACL extendidas.
Requisitos previos
El recurso compartido de Samba en el que desea establecer las ACL existe.
Procedimiento
1. Habilite el siguiente parámetro en la sección del recurso compartido en el archivo

/etc/samba/smb.conf para habilitar la herencia de ACLs extendidas:
heredar acls = si
Para más detalles, consulte la descripción del parámetro en la página de manual smb.conf(5).
3. Establezca las ACL en el directorio. Por ejemplo:

Ejemplo 3.2. Configuración de ACLs extendidas
El siguiente procedimiento establece permisos de lectura, escritura y ejecución para el grupo

Domain Admins, permisos de lectura y ejecución para el grupo Domain Users y deniega el
acceso a todos los demás en el directorio /srv/samba/example/:
1. Desactivar la concesión automática de permisos al grupo principal de cuentas de

usuario:
# setfacl -m group::--- /srv/samba/example/

# setfacl -m default:group::--- /srv/samba/example/
El grupo primario del directorio se asigna adicionalmente a la entidad de seguridad

dinámica CREATOR GROUP. Cuando se utilizan ACLs POSIX extendidas en un recurso
compartido de Samba, esta entidad de seguridad se añade automáticamente y no se
puede eliminar.
2. Establezca los permisos del directorio:
a. Conceda permisos de lectura, escritura y ejecución al grupo Domain Admins:
# setfacl -m group:"DOMAIN\Domain Admins":rwx /srv/samba/example/
b. Concede permisos de lectura y ejecución al grupo Domain Users:
62
# setfacl -m group:"DOMAIN\Domain Users":r-x /srv/samba/example/
c. Establezca los permisos de la entrada ACL other para denegar el acceso a los
usuarios que no coincidan con las demás entradas ACL:
# setfacl -R -m other::--- /srv/samba/example/
Estos ajustes se aplican sólo a este directorio. En Windows, estas ACL se asignan al
modo This folder only.
3. Para permitir que los permisos establecidos en el paso anterior sean heredados por los
nuevos objetos del sistema de archivos creados en este directorio:
# setfacl -m default:group:"DOMAIN\Domain Admins":rwx /srv/samba/example/

# setfacl -m default:group:"DOMAIN\Domain Users":r-x /srv/samba/example/
# setfacl -m default:other::--- /srv/samba/example/
Con estos ajustes, el modo This folder only para los directores está ahora establecido
en This folder, subfolders, and files.
Samba asigna los permisos establecidos en el procedimiento a las siguientes ACL de

Windows:
Principal Acceda a Se aplica a
Domain\N - Administradores de Control total Esta carpeta, subcarpetas y archivos

dominio
Domain\N - Usuarios del dominio Leer & ejecutar Esta carpeta, subcarpetas y archivos
Everyone [a] Ninguno Esta carpeta, subcarpetas y archivos
owner (Unix User\owner) [b] Control total Esta carpeta sólo
primary_group (Unix Ninguno Esta carpeta sólo

User\primary_group) [c]
CREATOR OWNER [d] [e] Control total Sólo subcarpetas y archivos
CREATOR GROUP [e] [f] Ninguno Sólo subcarpetas y archivos
63
Principal Acceda a Se aplica a
[a] Samba asigna los permisos para esta entidad de seguridad desde la entrada ACL de other.
[b] Samba asigna el propietario del directorio a esta entrada.
[c] Samba asigna el grupo primario del directorio a esta entrada.
[d] En los nuevos objetos del sistema de archivos, el creador hereda automáticamente los permisos de este
principal.
[e] La configuración o la eliminación de estas entidades de seguridad de las ACL no es compatible con los
recursos compartidos que utilizan ACL POSIX.
[f] En los nuevos objetos del sistema de archivos, el grupo principal del creador hereda automáticamente los
permisos de este principal.
3.8. ESTABLECIMIENTO DE PERMISOS EN UN RECURSO

COMPARTIDO QUE UTILIZA ACLS POSIX
Opcionalmente, para limitar o conceder el acceso a un recurso compartido de Samba, puede establecer
ciertos parámetros en la sección del recurso compartido en el archivo /etc/samba/smb.conf.
NOTA
Los permisos basados en acciones gestionan si un usuario, grupo o host puede acceder a
un recurso compartido. Estos ajustes no afectan a las ACL del sistema de archivos.
Utilice la configuración basada en los recursos compartidos para restringir el acceso a los recursos
compartidos, por ejemplo, para denegar el acceso desde determinados hosts.
Requisitos previos
Se ha configurado un recurso compartido con ACLs POSIX.
3.8.1. Configurar el acceso a los recursos compartidos basado en usuarios y grupos

El control de acceso basado en usuarios y grupos permite conceder o denegar el acceso a un recurso
compartido a determinados usuarios y grupos.
Requisitos previos
El recurso compartido de Samba en el que desea establecer el acceso basado en usuarios o

grupos existe.
Procedimiento
1. Por ejemplo, para permitir que todos los miembros del grupo Domain Users accedan a un
recurso compartido mientras se deniega el acceso a la cuenta user, añada los siguientes
parámetros a la configuración del recurso compartido:
64
valid users = +DOMAIN\"Domain Users"

invalid users = DOMAIN\user
El parámetro invalid users tiene mayor prioridad que el parámetro valid users. Por ejemplo, si
la cuenta user es miembro del grupo Domain Users, el acceso se deniega a esta cuenta
cuando se utiliza el ejemplo anterior.
Para más detalles, consulte las descripciones de los parámetros en la página de manual
smb.conf(5).
3.8.2. Configuración del acceso compartido basado en el host

El control de acceso basado en el host le permite conceder o denegar el acceso a un recurso compartido
en función de los nombres de host, las direcciones IP o el rango de IP de los clientes.
El siguiente procedimiento explica cómo habilitar la dirección IP 127.0.0.1, el rango IP 192.0.2.0/24 y el

host client1.example.com para acceder a un recurso compartido, y además denegar el acceso al host
client2.example.com:
Requisitos previos
El recurso compartido de Samba en el que desea establecer el acceso basado en el host existe.
Procedimiento
1. Añada los siguientes parámetros a la configuración del recurso compartido en el archivo

hosts allow = 127.0.0.1 192.0.2.0/24 client1.example.com

hosts deny = client2.example.com
El parámetro hosts deny tiene mayor prioridad que hosts allow. Por ejemplo, si
client1.example.com resuelve a una dirección IP que aparece en el parámetro hosts allow, se
deniega el acceso a este host.
Para más detalles, consulte las descripciones de los parámetros en la página de manual
smb.conf(5).
3.9. CONFIGURACIÓN DE UN RECURSO COMPARTIDO QUE UTILIZA

LAS ACL DE WINDOWS
65
Samba admite la configuración de ACL de Windows en los recursos compartidos y en el objeto del
sistema de archivos. Esto le permite:
Utilizar las ACLs de Windows de grano fino
Gestionar los permisos de uso compartido y las ACL del sistema de archivos mediante Windows
Alternativamente, puede configurar un recurso compartido para utilizar ACLs POSIX. Para más detalles,
consulte Sección 3.7, “Configuración de un archivo compartido Samba que utiliza ACLs POSIX” .
Partes de esta sección fueron adoptadas de la documentación Setting up a Share Using Windows ACLs
publicada en el Wiki de Samba. Licencia: CC BY 4.0. Autores y colaboradores: Ver la pestaña de historia
en la página de la Wiki.
3.9.1. Concesión del privilegio SeDiskOperatorPrivilege

Sólo los usuarios y grupos que tengan concedido el privilegio SeDiskOperatorPrivilege pueden
configurar los permisos en los recursos compartidos que utilizan las ACL de Windows.
Procedimiento
1. Por ejemplo, para conceder el privilegio SeDiskOperatorPrivilege al grupo DOMAIN\Domain

Admins grupo:
# net rpc rights grant "DOMAIN\Domain Admins" SeDiskOperatorPrivilege -U

"DOMAIN\administrator"
Enter DOMAIN\administrator's password:
Successfully granted rights.
NOTA
En un entorno de dominio, conceda SeDiskOperatorPrivilege a un grupo de

dominio. Esto le permite gestionar de forma centralizada el privilegio mediante la
actualización de la pertenencia a un grupo de usuarios.
2. Para listar todos los usuarios y grupos que tienen SeDiskOperatorPrivilege concedido:
# net rpc rights list privileges SeDiskOperatorPrivilege -U "DOMAIN\administrator"

Enter administrator's password:
SeDiskOperatorPrivilege:
BUILTIN\Administrators
DOMAIN\Domain Admins
3.9.2. Habilitación de la compatibilidad con ACL de Windows

Para configurar los recursos compartidos que admiten las ACL de Windows, debe habilitar esta función
en Samba.
Requisitos previos
Se configura un recurso compartido de usuario en el servidor Samba.
Procedimiento
66
1. Para habilitarlo globalmente para todos los recursos compartidos, añada la siguiente
configuración a la sección [global] del archivo /etc/samba/smb.conf:
vfs objects = acl_xattr

map acl inherit = yes
store dos attributes = yes
Como alternativa, puede habilitar el soporte de ACL de Windows para acciones individuales,
añadiendo los mismos parámetros a la sección de una acción.
3.9.3. Añadir un recurso compartido que utiliza las ACL de Windows

Esta sección describe cómo crear un recurso compartido llamado example, que comparte el contenido
del directorio /srv/samba/example/, y utiliza las ACL de Windows.
Procedimiento
1. Cree la carpeta si no existe. Por ejemplo:
# mkdir -p /srv/samba/example/
# semanage fcontext -a -t samba_share_t "/srv/samba/example(/.*)?"

# restorecon -Rv /srv/samba/example/
3. Añada el ejemplo de recurso compartido al archivo /etc/samba/smb.conf. Por ejemplo, para

añadir el recurso compartido de escritura:
[example]
path = /srv/samba/example/
read only = no
NOTA
Independientemente de las ACL del sistema de archivos; si no se establece read

only = no, Samba comparte el directorio en modo de sólo lectura.
4. Si no ha habilitado la compatibilidad con ACL de Windows en la sección [global] para todos los
recursos compartidos, añada los siguientes parámetros a la sección [example] para habilitar
esta función para este recurso compartido:
vfs objects = acl_xattr

map acl inherit = yes
store dos attributes = yes
67
# testparm
firewall-cmd:

3.9.4. Gestión de los permisos del recurso compartido y de las ACL del sistema de
archivos de un recurso compartido que utiliza las ACL de Windows
Para gestionar los permisos de uso compartido y las ACL del sistema de archivos en un recurso
compartido de Samba que utiliza ACL de Windows, utilice una aplicación de Windows, como Computer
Management. Para más detalles, consulte la documentación de Windows. Como alternativa, utilice la
utilidad smbcacls para gestionar las ACL.
NOTA
Para modificar los permisos del sistema de archivos desde Windows, debe utilizar una
cuenta que tenga concedido el privilegio SeDiskOperatorPrivilege.
Sección 3.10, “Gestión de ACLs en un recurso compartido SMB mediante smbcacls”
Sección 3.9.1, “Concesión del privilegio SeDiskOperatorPrivilege”
3.10. GESTIÓN DE ACLS EN UN RECURSO COMPARTIDO SMB

MEDIANTE SMBCACLS
La utilidad smbcacls puede listar, establecer y eliminar ACLs de archivos y directorios almacenados en
un recurso compartido SMB. Puede utilizar smbcacls para gestionar las ACL del sistema de archivos:
En un servidor Samba local o remoto que utiliza ACLs avanzadas de Windows o ACLs POSIX
En Red Hat Enterprise Linux para gestionar remotamente las ACL en un recurso compartido
alojado en Windows
3.10.1. Entradas de control de acceso

Cada entrada ACL de un objeto del sistema de archivos contiene entradas de control de acceso (ACE)
con el siguiente formato:
security_principal:access_right/inheritance_information/permissions
Ejemplo 3.3. Entradas de control de acceso
Si el grupo AD\Domain Users tiene permisos de Modify que se aplican a This folder, subfolders,
68
Si el grupo AD\Domain Users tiene permisos de Modify que se aplican a This folder, subfolders,
and files en Windows, la ACL contiene la siguiente ACE:
AD\N-Domain Users:ALLOWED/OI|CI/CHANGE
Una ACE contiene las siguientes partes:
Seguridad principal
El principal de seguridad es el usuario, grupo o SID al que se aplican los permisos en la ACL.
Derecho de acceso
Define si se concede o se deniega el acceso a un objeto. El valor puede ser ALLOWED o DENIED.
Información sobre la herencia
Existen los siguientes valores:
Tabla 3.1. Configuración de la herencia
Valor Descripción Mapas a
OI Heredar objeto Esta carpeta y archivos
CI Heredar el contenedor Esta carpeta y sus subcarpetas
IO Sólo heredar La ACE no se aplica al archivo o

directorio actual
ID Heredado La ACE fue heredada del

directorio principal
Además, los valores pueden combinarse de la siguiente manera:
Tabla 3.2. Combinaciones de ajustes de la herencia
Combinaciones de valores Corresponde a la configuración de Windows

Applies to
OI|CI Esta carpeta, subcarpetas y archivos
OI|CI|IO Sólo subcarpetas y archivos
CI|IO Sólo subcarpetas
OI|IO Sólo archivos
Permisos
Este valor puede ser un valor hexadecimal que representa uno o más permisos de Windows o un alias
de smbcacls:
69
Un valor hexadecimal que representa uno o más permisos de Windows.

La siguiente tabla muestra los permisos avanzados de Windows y su correspondiente valor
en formato hexadecimal:
Tabla 3.3. Permisos de Windows y su correspondiente valor smbcacls en formato

hexadecimal
Permisos de Windows Valores hexadecimales
Control total 0x001F01FF
Recorrer la carpeta / ejecutar el archivo 0x00100020
Listar carpeta / leer datos 0x00100001
Leer atributos 0x00100080
Leer atributos extendidos 0x00100008
Crear archivos / escribir datos 0x00100002
Crear carpetas / añadir datos 0x00100004
Escribir atributos 0x00100100
Escribir atributos extendidos 0x00100010
Eliminar subcarpetas y archivos 0x00100040
Borrar 0x00110000
Leer permisos 0x00120000
Cambiar los permisos 0x00140000
Asumir la responsabilidad 0x00180000
Se pueden combinar varios permisos como un único valor hexadecimal utilizando la

operación bit a bit OR. Para más detalles, véase Sección 3.10.3, “Cálculo de la máscara ACE” .
Un alias de smbcacls. La siguiente tabla muestra los alias disponibles:
Tabla 3.4. Alias smbcacls existentes y su correspondiente permiso de Windows
smbcacls alias Mapas para el permiso de Windows
R Leer
READ Leer & ejecutar
70
smbcacls alias Mapas para el permiso de Windows
W Especial:
Crear archivos / escribir datos
Crear carpetas / añadir datos
Escribir atributos
Escribir atributos extendidos
Leer permisos
D Borrar
P Cambiar los permisos
O Asumir la responsabilidad
X Atravesar/ejecutar
CHANGE Modificar
FULL Control total
NOTA
Puede combinar alias de una sola letra cuando establezca los permisos. Por
ejemplo, puede establecer RD para aplicar el permiso de Windows Read y
Delete. Sin embargo, no puede combinar varios alias que no sean de una sola
letra ni combinar alias y valores hexadecimales.
3.10.2. Visualización de ACLs con smbcacls

Para mostrar las ACL de un recurso compartido SMB, utilice la utilidad smbcacls. Si ejecuta smbcacls
sin ningún parámetro de operación, como --add, la utilidad muestra las ACL de un objeto del sistema de
archivos.
Procedimiento
Por ejemplo, para listar las ACL del directorio raíz del recurso compartido //server/example:
# smbcacls //server/example / -U "DOMAIN\administrator"

REVISION:1
CONTROL:SR|PD|DI|DP
OWNER:AD\Administrators
GROUP:AD\Domain Users
71
ACL:AD\Administrator:ALLOWED/OI|CI/FULL
ACL:AD\Domain Users:ALLOWED/OI|CI/CHANGE
ACL:AD\Domain Guests:ALLOWED/OI|CI/0x00100021
La salida del comando se muestra:
REVISION: La revisión interna de la ACL de Windows NT del descriptor de seguridad
CONTROL: Control del descriptor de seguridad
OWNER: Nombre o SID del propietario del descriptor de seguridad
GROUP: Nombre o SID del grupo del descriptor de seguridad
ACL entradas. Para más detalles, véase Sección 3.10.1, “Entradas de control de acceso” .
3.10.3. Cálculo de la máscara ACE

En la mayoría de las situaciones, cuando se añade o actualiza una ACE, se utilizan los alias de smbcacls
que aparecen en Tabla 3.4, “Alias smbcacls existentes y su correspondiente permiso de Windows” .
Sin embargo, si desea establecer los permisos avanzados de Windows, como se indica en Tabla 3.3,
“Permisos de Windows y su correspondiente valor smbcacls en formato hexadecimal”, debe utilizar la
operación de bit a bit OR para calcular el valor correcto. Puede utilizar el siguiente comando del shell
para calcular el valor:
# echo $(printf '0x%X' $(( hex_value_1 | hex_value_2 | ... )))
Ejemplo 3.4. Cálculo de una máscara ACE
Usted quiere establecer los siguientes permisos:
Recorrer carpeta / ejecutar archivo (0x00100020)
Listar carpeta / leer datos (0x00100001)
Leer atributos (0x00100080)
Para calcular el valor hexadecimal de los permisos anteriores, introduzca:
# echo $(printf '0x%X' $(( 0x00100020 | 0x00100001 | 0x00100080 )))

0x1000A1
Utilice el valor devuelto cuando establezca o actualice una ACE.
3.10.4. Añadir, actualizar y eliminar una ACL con smbcacls

Dependiendo del parámetro que pase a la utilidad smbcacls, puede añadir, actualizar y eliminar las ACL
de un archivo o directorio.
Añadir una ACL

Para añadir una ACL a la raíz del recurso compartido //server/example que conceda permisos a
CHANGE para This folder, subfolders, and files al grupo AD\Domain Users:
72
# smbcacls //server/example / -U "DOMAIN\administrator --add ACL:"AD\Domain

Users":ALLOWED/OI|CI/CHANGE
Actualización de una ACL

La actualización de una ACL es similar a la adición de una nueva ACL. Se actualiza una ACL anulando la
ACL mediante el parámetro --modify con una entidad de seguridad existente. Si smbcacls encuentra la
entidad de seguridad en la lista de ACL, la utilidad actualiza los permisos. De lo contrario, el comando
falla con un error:
ACL para SID principal_name no se encuentra
Por ejemplo, para actualizar los permisos del grupo AD\Domain Users y establecerlos en READ para
This folder, subfolders, and files:
# smbcacls //server/example / -U "DOMAIN\administrator --modify ACL:"AD\Domain

Users":ALLOWED/OI|CI/READ
Borrar una ACL

Para eliminar una ACL, pase el parámetro --delete con la ACL exacta a la utilidad smbcacls. Por
ejemplo:
# smbcacls //server/example / -U "DOMAIN\administrator --delete ACL:"AD\Domain

Users":ALLOWED/OI|CI/READ
3.11. PERMITIR A LOS USUARIOS COMPARTIR DIRECTORIOS EN UN

SERVIDOR SAMBA
En un servidor Samba, puede configurar que los usuarios puedan compartir directorios sin permisos de
root.
3.11.1. Habilitación de la función de acciones de los usuarios

Antes de que los usuarios puedan compartir directorios, el administrador debe habilitar los recursos
compartidos de los usuarios en Samba.
Por ejemplo, para permitir que sólo los miembros del grupo local example puedan crear recursos
compartidos de usuario.
Procedimiento
1. Cree el grupo local example, si no existe:
# groupadd example
2. Prepare el directorio para que Samba almacene las definiciones de recursos compartidos de los
usuarios y establezca sus permisos correctamente. Por ejemplo:
a. Crea el directorio:
# mkdir -p /var/lib/samba/usershares/
b. Establezca los permisos de escritura para el grupo example:
73
# chgrp example /var/lib/samba/usershares/

# chmod 1770 /var/lib/samba/usershares/
c. Establece el bit sticky para evitar que los usuarios renombren o borren los archivos
almacenados por otros usuarios en este directorio.
3. Edite el archivo /etc/samba/smb.conf y añada lo siguiente a la sección [global]:
a. Establezca la ruta del directorio que configuró para almacenar las definiciones de recursos
compartidos de los usuarios. Por ejemplo:
ruta de usuarios compartidos = /var/lib/samba/usershares/
b. Establece el número de recursos compartidos de usuario que Samba permite crear en este
servidor. Por ejemplo:
usershare max shares = 100
Si utilizas el valor por defecto de 0 para el parámetro usershare max shares, los recursos
compartidos de los usuarios están deshabilitados.
c. Opcionalmente, establezca una lista de rutas de directorio absolutas. Por ejemplo, para
configurar que Samba sólo permita compartir subdirectorios del directorio /data y /srv a
compartir, establezca:
usershare prefix allow list = /data /srv
Para obtener una lista de otros parámetros relacionados con el uso compartido de usuarios que
puede establecer, consulte la sección USERSHARES en la página de manual smb.conf(5).
# testparm
Ahora los usuarios pueden crear acciones de usuario.
3.11.2. Añadir una cuota de usuario

Después de activar la función de compartir usuarios en Samba, los usuarios pueden compartir
directorios en el servidor Samba sin root permisos ejecutando el comando net usershare add.
Sinopsis del comando net usershare add:
net usershare add nombre_compartido ruta [[ comentario ] | [ ACLs ]] [ guest_ok=y|n ]
IMPORTANTE
Si establece ACLs cuando crea un recurso compartido de usuario, debe especificar el

parámetro de comentario antes de las ACLs. Para establecer un comentario vacío, utilice
una cadena vacía entre comillas dobles.
74
Tenga en cuenta que los usuarios sólo pueden habilitar el acceso de invitados en un recurso compartido
de usuario, si el administrador establece usershare allow guests = yes en la sección [global] en el
archivo /etc/samba/smb.conf.
Ejemplo 3.5. Añadir una cuota de usuario
Un usuario quiere compartir el directorio /srv/samba/ en un servidor Samba. El recurso compartido

debe llamarse example, no debe tener ningún comentario y debe ser accesible para los usuarios
invitados. Además, los permisos del recurso compartido deben ser de acceso total para el grupo
AD\Domain Users y de lectura para los demás usuarios. Para añadir este recurso compartido,
ejecute como usuario:
$ net usershare add example /srv/samba/ "" "AD\Domain Users":F,Everyone:R

guest_ok=yes
3.11.3. Actualización de la configuración de una cuota de usuario

Para actualizar la configuración de un recurso compartido de usuario, anule el recurso compartido
utilizando el comando net usershare add con el mismo nombre de recurso compartido y la nueva
configuración. Véase Sección 3.11.2, “Añadir una cuota de usuario” .
3.11.4. Mostrar información sobre las acciones de los usuarios existentes

Los usuarios pueden introducir el comando net usershare info en un servidor Samba para mostrar los
recursos compartidos de los usuarios y su configuración.
Requisitos previos
Procedimiento
1. Para mostrar todas las acciones creadas por cualquier usuario:
$ net usershare info -l

[share_1]
path=/srv/samba/
comment=
usershare_acl=Everyone:R,host_name\user:F,
guest_ok=y
...
Para listar sólo los recursos compartidos creados por el usuario que ejecuta el comando, omita
el parámetro -l.
2. Para mostrar sólo la información sobre acciones específicas, pase el nombre de la acción o los
comodines al comando. Por ejemplo, para mostrar la información sobre los recursos
compartidos cuyo nombre empieza por share_:
$ net usershare info -l share_*
3.11.5. Listado de acciones de usuarios
75
Si quiere listar sólo los recursos compartidos de usuario disponibles sin su configuración en un servidor
Samba, utilice el comando net usershare list.
Requisitos previos
Procedimiento
1. Para listar las acciones creadas por cualquier usuario:
$ net usershare list -l

share_1
share_2
...
Para listar sólo los recursos compartidos creados por el usuario que ejecuta el comando, omita
el parámetro -l.
2. Para listar sólo acciones específicas, pase el nombre de la acción o los comodines al comando.
Por ejemplo, para listar sólo los recursos compartidos cuyo nombre empiece por share_:
$ net usershare list -l share_*
3.11.6. Borrar una cuota de usuario

Para eliminar un recurso compartido de usuario, utilice el comando net usershare delete como el
usuario que creó el recurso compartido o como el usuario root.
Requisitos previos
Procedimiento
$ net usershare delete share_name
3.12. CONFIGURAR UN RECURSO COMPARTIDO PARA PERMITIR EL

ACCESO SIN AUTENTICACIÓN
En determinadas situaciones, se desea compartir un directorio al que los usuarios puedan conectarse sin
autenticación. Para configurarlo, active el acceso de invitados en un recurso compartido.

AVISO
Las acciones que no requieren autenticación pueden ser un riesgo para la

seguridad.
76
3.12.1. Habilitar el acceso de invitados a un recurso compartido

Si se habilita el acceso de invitados en un recurso compartido, Samba asigna las conexiones de invitados
a la cuenta del sistema operativo establecida en el parámetro guest account. Los usuarios invitados
pueden acceder a los archivos de este recurso compartido si se cumple al menos una de las siguientes
condiciones:
La cuenta aparece en las ACL del sistema de archivos
Los permisos POSIX para los usuarios de other permiten
Ejemplo 3.6. Permisos de uso compartido para invitados
Si ha configurado Samba para asignar la cuenta de invitado a nobody, que es el valor

predeterminado, las ACL del siguiente ejemplo:
Permitir que los usuarios invitados lean file1.txt
Permitir a los usuarios invitados leer y modificar file2.txt
Impedir que los usuarios invitados lean o modifiquen file3.txt
-rw-r--r--. 1 root root 1024 1. Sep 10:00 file1.txt

-rw-r-----. 1 nobody root 1024 1. Sep 10:00 file2.txt
-rw-r-----. 1 root root 1024 1. Sep 10:00 file3.txt
Procedimiento
1. Edite el archivo /etc/samba/smb.conf:
a. Si este es el primer recurso compartido para invitados que configuras en este servidor:
i. Establezca map to guest = Bad User en la sección [global]:
[global]
...
map to guest = Bad User
Con esta configuración, Samba rechaza los intentos de inicio de sesión que utilizan una
contraseña incorrecta a menos que el nombre de usuario no exista. Si el nombre de
usuario especificado no existe y el acceso de invitados está habilitado en un recurso
compartido, Samba trata la conexión como un inicio de sesión de invitado.
ii. Por defecto, Samba asigna la cuenta de invitado a la cuenta nobody en Red Hat
Enterprise Linux. Alternativamente, puede establecer una cuenta diferente. Por
ejemplo:
[global]
...
guest account = user_name
La cuenta establecida en este parámetro debe existir localmente en el servidor Samba.

Por razones de seguridad, Red Hat recomienda utilizar una cuenta que no tenga
asignada una shell válida.
77
b. Añade la configuración de guest ok = yes a la sección de acciones de [example]:
[example]
...
guest ok = yes
# testparm
3.13. CONFIGURACIÓN DE SAMBA PARA CLIENTES DE MACOS

El módulo Samba del sistema de archivos virtual (VFS) fruit proporciona una mayor compatibilidad con
los clientes de bloque de mensajes de servidor (SMB) de Apple.
3.13.1. Optimización de la configuración de Samba para proporcionar recursos

compartidos de archivos para clientes de macOS
Esta sección describe cómo configurar el módulo fruit para todos los recursos compartidos de Samba
alojados en el servidor para optimizar los recursos compartidos de Samba para los clientes de macOS.
NOTA
Red Hat recomienda habilitar el módulo fruit de forma global. Los clientes que utilizan
macOS negocian las extensiones del protocolo Apple (AAPL) del bloque de mensajes del
servidor versión 2 (SMB2) cuando el cliente establece la primera conexión con el
servidor. Si el cliente se conecta por primera vez a un recurso compartido sin las
extensiones AAPL habilitadas, el cliente no utiliza las extensiones para ningún recurso
compartido del servidor.
Requisitos previos
Samba está configurado como servidor de archivos.
Procedimiento
1. Edite el archivo /etc/samba/smb.conf y habilite los módulos VFS fruit y streams_xattr en la

sección [global]:
vfs objects = fruit streams_xattr
IMPORTANTE
Debe activar el módulo fruit antes de activar streams_xattr. El módulo fruit

utiliza flujos de datos alternativos (ADS). Por este motivo, también debe habilitar
el módulo streams_xattr.
2. Opcionalmente, para proporcionar compatibilidad con macOS Time Machine en un recurso
78
2. Opcionalmente, para proporcionar compatibilidad con macOS Time Machine en un recurso

compartido, añada el siguiente ajuste a la configuración del recurso compartido en el archivo
fruta:máquina del tiempo = sí
# testparm
Para más detalles sobre el módulo VFS fruit, consulte la página man vfs_fruit(8).
Para más detalles sobre la configuración de los archivos compartidos, véase:
Sección 3.9, “Configuración de un recurso compartido que utiliza las ACL de Windows” .
3.14. USO DE LA UTILIDAD SMBCLIENT PARA ACCEDER A UN

RECURSO COMPARTIDO SMB
La utilidad smbclient le permite acceder a los recursos compartidos de un servidor SMB, de forma similar
a un cliente FTP de línea de comandos. Puede utilizarla, por ejemplo, para cargar y descargar archivos
hacia y desde un recurso compartido.
Requisitos previos
El paquete samba-client está instalado.
3.14.1. Cómo funciona el modo interactivo de smbclient

Por ejemplo, para autenticarse en el recurso compartido example alojado en server utilizando la
DOMAIN\user cuenta:
# smbclient -U "DOMAIN\user" //server/example

Enter domain\user's password:
Try "help" to get a list of possible commands.
smb: \>
Después de que smbclient se haya conectado con éxito al recurso compartido, la utilidad entra en el
modo interactivo y muestra el siguiente aviso:
smb: \N >
Para mostrar todos los comandos disponibles en el shell interactivo, introduzca:
79
smb: \N > help
Para mostrar la ayuda de un comando específico, introduzca:
smb: \N > help command_name
Para más detalles y descripciones de los comandos disponibles en el shell interactivo, consulte
la página de manual smbclient(1).
3.14.2. Uso de smbclient en modo interactivo

Si utiliza smbclient sin el parámetro -c, la utilidad entra en el modo interactivo. El siguiente
procedimiento muestra cómo conectarse a un recurso compartido SMB y descargar un archivo de un
subdirectorio.
Procedimiento
1. Conéctate a la acción:
# smbclient -U "DOMAIN\user_name" //server_name/share_name
2. Cambia al directorio /example/:
smb: \N > d /example/
3. Enumera los archivos del directorio:
smb: \example\> ls
. D 0 Thu Nov 1 10:00:00 2018
.. D 0 Thu Nov 1 10:00:00 2018
example.txt N 1048576 Thu Nov 1 10:00:00 2018
9950208 blocks of size 1024. 8247144 blocks available
4. Descargue el archivo example.txt:
smb: \example\> get example.txt

getting file \directory\subdirectory\example.txt of size 1048576 as example.txt (511975,0
KiloBytes/sec) (average 170666,7 KiloBytes/sec)
5. Desconéctate de la acción:
smb: \N - ejemplo > exit
3.14.3. Uso de smbclient en modo scripting

Si pasa el parámetro -c a smbclient, puede ejecutar automáticamente los comandos en el recurso
compartido SMB remoto. Esto le permite utilizar smbclient en los scripts.
El siguiente procedimiento muestra cómo conectarse a un recurso compartido SMB y descargar un

80
El siguiente procedimiento muestra cómo conectarse a un recurso compartido SMB y descargar un

archivo de un subdirectorio.
Procedimiento
Utilice el siguiente comando para conectarse al recurso compartido, cambiar al directorio

example y descargar el archivo example.txt:
# smbclient -U DOMAIN\user_name //server_name/share_name -c "cd /example/ ; get

example.txt ; exit"
3.15. CONFIGURACIÓN DE SAMBA COMO SERVIDOR DE IMPRESIÓN

Si configura Samba como servidor de impresión, los clientes de su red pueden utilizar Samba para
imprimir. Además, los clientes de Windows pueden, si están configurados, descargar el controlador
desde el servidor Samba.
Partes de esta sección han sido adoptadas de la documentación de Configuración de Samba como
servidor de impresión publicada en el Wiki de Samba. Licencia: CC BY 4.0. Autores y colaboradores: Ver
la pestaña de historia en la página de la Wiki.
Requisitos previos
Samba se ha configurado en uno de los siguientes modos:
Servidor autónomo
Miembro del dominio
3.15.1. El servicio Samba spoolssd

El servicio Samba spoolssd está integrado en el servicio smbd. Habilite spoolssd en la configuración
de Samba para aumentar significativamente el rendimiento en los servidores de impresión con un
elevado número de trabajos o impresoras.
Sin spoolssd, Samba bifurca el proceso smbd e inicializa la caché printcap para cada trabajo de
impresión. En el caso de un gran número de impresoras, el servicio smbd puede dejar de responder
durante varios segundos mientras se inicializa la caché. El servicio spoolssd permite iniciar procesos
smbd preforkados que están procesando trabajos de impresión sin ningún retraso. El proceso principal
spoolssd smbd utiliza una cantidad baja de memoria, y bifurca y termina los procesos hijos.
El siguiente procedimiento explica cómo activar el servicio spoolssd.
Procedimiento
a. Añade los siguientes parámetros:
rpc_server:spoolss = external
rpc_daemon:spoolssd = fork
b. Opcionalmente, puede establecer los siguientes parámetros:
81
Parámetro Por defecto Descripción
spoolssd:prefork_min_c 5 Número mínimo de procesos

hildren hijos
spoolssd:prefork_max_c 25 Número máximo de procesos

hildren hijos
spoolssd:prefork_spawn 5 Samba bifurca el número de

_rate nuevos procesos hijos
establecidos en este
parámetro, hasta el valor
establecido en
spoolssd:prefork_max_c
hildren , si se establece una
nueva conexión
spoolssd:prefork_max_al 100 Número de clientes a los que

lowed_clients sirve un proceso infantil
spoolssd:prefork_child_ 60 Duración mínima de un

min_life proceso hijo en segundos. 60
segundos es el mínimo.
# testparm
Después de reiniciar el servicio, Samba inicia automáticamente los procesos hijos de smbd:
# ps axf
...
30903 smbd
30912 \_ smbd
30913 \_ smbd
30914 \_ smbd
30915 \_ smbd
...
3.15.2. Activación del soporte del servidor de impresión en Samba

Esta sección explica cómo habilitar el soporte del servidor de impresión en Samba.
Procedimiento
82
1. En el servidor Samba, configure CUPS y añada la impresora al back end de CUPS. Para más
detalles sobre la configuración de impresoras en CUPS; consulte la documentación
proporcionada en la consola web de CUPS (https://print_server_host_name:631/help) en el
servidor de impresión.
NOTA
Samba sólo puede reenviar los trabajos de impresión a CUPS si éste está
instalado localmente en el servidor de impresión Samba.
a. Si desea activar el servicio spoolssd, añada los siguientes parámetros a la sección [global]:
rpc_server:spoolss = external
rpc_daemon:spoolssd = fork
b. Para configurar el back end de impresión, añada la sección [printers]:
[printers]
comment = All Printers
path = /var/tmp/
printable = yes
create mask = 0600
IMPORTANTE
El nombre de la acción de [printers] está codificado y no se puede cambiar.
# testparm
firewall-cmd:

Después de reiniciar el servicio, Samba comparte automáticamente todas las impresoras que están
configuradas en el back-end de CUPS. Si desea compartir manualmente sólo impresoras específicas,
consulte Sección 3.15.3, “Compartir manualmente impresoras específicas” .
3.15.3. Compartir manualmente impresoras específicas

Si ha configurado Samba como servidor de impresión, por defecto, Samba comparte todas las
impresoras que están configuradas en el back-end de CUPS. El siguiente procedimiento explica cómo
compartir sólo impresoras específicas.
83
Requisitos previos
Samba está configurado como servidor de impresión
Procedimiento
a. En la sección [global], desactive el uso compartido automático de la impresora mediante la

configuración:
cargar impresoras = no
b. Añade una sección para cada impresora que quieras compartir. Por ejemplo, para compartir
la impresora llamada example en el back end de CUPS como Example-Printer en Samba,
añada la siguiente sección:
[Example-Printer]
path = /var/tmp/
printable = yes
printer name = example
No necesita directorios de spool individuales para cada impresora. Puede establecer el

mismo directorio de spool en el parámetro path para la impresora que estableció en la
sección [printers].
# testparm
3.16. CONFIGURACIÓN DE DESCARGAS AUTOMÁTICAS DE

CONTROLADORES DE IMPRESORA PARA CLIENTES DE WINDOWS EN
SERVIDORES DE IMPRESIÓN SAMBA
Si está ejecutando un servidor de impresión Samba para clientes de Windows, puede cargar los
controladores y preconfigurar las impresoras. Si un usuario se conecta a una impresora, Windows
descarga e instala automáticamente el controlador de forma local en el cliente. El usuario no necesita
permisos de administrador local para la instalación. Además, Windows aplica los ajustes preconfigurados
del controlador, como el número de bandejas.
Partes de esta sección fueron adoptadas de la documentación Configuración de la descarga

automática de controladores de impresora para clientes de Windows publicada en el Wiki de Samba.
Licencia: CC BY 4.0. Autores y colaboradores: Ver la pestaña de historia en la página de la Wiki.
Requisitos previos
Samba está configurado como servidor de impresión
3.16.1. Información básica sobre los controladores de impresora
84
Esta sección proporciona información general sobre los controladores de la impresora.
Versión del modelo de controlador compatible

Samba sólo es compatible con el modelo de controlador de impresora versión 3 que se admite en
Windows 2000 y posteriores, y Windows Server 2000 y posteriores. Samba no es compatible con la
versión 4 del controlador, introducida en Windows 8 y Windows Server 2012. Sin embargo, estas
versiones de Windows y las posteriores también son compatibles con los controladores de la versión 3.
Controladores compatibles con los paquetes

Samba no es compatible con los controladores de paquetes.
Preparación de un controlador de impresora para ser cargado

Antes de poder cargar un controlador en un servidor de impresión Samba:
Descomprimir el controlador si se proporciona en un formato comprimido.
Algunos controladores requieren el inicio de una aplicación de configuración que instala el

controlador localmente en un host de Windows. En ciertas situaciones, el instalador extrae los
archivos individuales en la carpeta temporal del sistema operativo durante la ejecución de la
instalación. Para utilizar los archivos del controlador para la carga:
a. Inicie el instalador.
b. Copie los archivos de la carpeta temporal a una nueva ubicación.
c. Cancelar la instalación.
Pregunte al fabricante de su impresora por los controladores que admiten la carga en un servidor de
impresión.
Suministro de controladores de 32 y 64 bits para una impresora a un cliente

Para proporcionar el controlador de una impresora para clientes de Windows de 32 y 64 bits, debe
cargar un controlador con exactamente el mismo nombre para ambas arquitecturas. Por ejemplo, si
carga el controlador de 32 bits denominado Example PostScript y el de 64 bits denominado Example
PostScript (v1.0), los nombres no coinciden. En consecuencia, sólo podrá asignar uno de los
controladores a una impresora y el controlador no estará disponible para ambas arquitecturas.
3.16.2. Permitir a los usuarios cargar y preconfigurar los controladores

Para poder cargar y preconfigurar los controladores de impresora, un usuario o un grupo debe tener
concedido el privilegio SePrintOperatorPrivilege. Un usuario debe ser agregado al grupo printadmin.
Red Hat Enterprise Linux crea automáticamente este grupo cuando se instala el paquete samba. Al
grupo printadmin se le asigna el GID de sistema dinámico más bajo disponible que sea inferior a 1000.
Procedimiento
1. Por ejemplo, para conceder el privilegio SePrintOperatorPrivilege al grupo printadmin:
# net rpc rights grant "printadmin" SePrintOperatorPrivilege -U

NOTA
85
NOTA
En un entorno de dominio, conceda SePrintOperatorPrivilege a un grupo de

dominio. Esto le permite gestionar de forma centralizada el privilegio mediante la
actualización de la pertenencia a un grupo de usuarios.
2. Para listar todos los usuarios y grupos que tienen SePrintOperatorPrivilege concedido:
# net rpc rights list privileges SePrintOperatorPrivilege -U "DOMAIN\administrator"

Enter administrator's password:
SePrintOperatorPrivilege:
BUILTIN\Administrators
DOMAIN\printadmin
3.16.3. Configuración de la acción print$

Los sistemas operativos Windows descargan los controladores de la impresora desde un recurso
compartido llamado print$ de un servidor de impresión. Este nombre de recurso compartido está
codificado en Windows y no se puede cambiar.
El siguiente procedimiento explica cómo compartir el directorio /var/lib/samba/drivers/ como print$, y

permitir a los miembros del grupo local printadmin cargar los controladores de la impresora.
Procedimiento
1. Añada la sección [print$] al archivo /etc/samba/smb.conf:
[print$]
path = /var/lib/samba/drivers/
read only = no
write list = @printadmin
force group = @printadmin
create mask = 0664
directory mask = 2775
Utilizando estos ajustes:
Sólo los miembros del grupo printadmin pueden cargar controladores de impresora en el
recurso compartido.
El grupo de archivos y directorios recién creados se establecerá en printadmin.
Los permisos de los nuevos archivos se establecerán en 664.
Los permisos de los nuevos directorios se establecerán en 2775.
2. Para cargar sólo los controladores de 64 bits para todas las impresoras, incluya esta
configuración en la sección [global] del archivo /etc/samba/smb.conf:
spoolss: arquitectura = Windows x64
Sin esta configuración, Windows sólo muestra los controladores para los que se ha cargado al
menos la versión de 32 bits.
86
# testparm
4. Recargar la configuración de Samba
5. Cree el grupo printadmin si no existe:
# groupadd printadmin
6. Conceda el privilegio SePrintOperatorPrivilege al grupo printadmin.
# net rpc rights grant "printadmin" SePrintOperatorPrivilege -U

# semanage fcontext -a -t samba_share_t "/var/lib/samba/drivers(/.*)?"

# restorecon -Rv /var/lib/samba/drivers/
8. Establezca los permisos del directorio /var/lib/samba/drivers/:
Si utiliza ACLs POSIX, configure:
# chgrp -R "printadmin" /var/lib/samba/drivers/

# chmod -R 2775 /var/lib/samba/drivers/
Si utiliza las ACL de Windows, configure:
Principal Acceda a Solicitar a
CREATOR Control total Sólo subcarpetas y archivos

OWNER
Authenticated Leer & ejecutar, Listar el contenido Esta carpeta, subcarpetas y archivos
Users de la carpeta, Leer
printadmin Control total Esta carpeta, subcarpetas y archivos
Para más detalles sobre la configuración de las ACL en Windows, consulte la

documentación de Windows.
Sección 3.16.2, “Permitir a los usuarios cargar y preconfigurar los controladores” .
3.16.4. Creación de un GPO para que los clientes confíen en el servidor de impresión
Samba
Por razones de seguridad, los sistemas operativos Windows más recientes impiden que los clientes
87
Por razones de seguridad, los sistemas operativos Windows más recientes impiden que los clientes
descarguen controladores de impresora no compatibles con el paquete desde un servidor no fiable. Si
su servidor de impresión es miembro de un AD, puede crear un objeto de directiva de grupo (GPO) en
su dominio para confiar en el servidor Samba.
Requisitos previos
El servidor de impresión Samba es miembro de un dominio AD.
El ordenador con Windows que utilice para crear el GPO debe tener instaladas las Herramientas
de Administración Remota de Servidores de Windows (RSAT). Para más detalles, consulte la
Procedimiento
1. Inicie sesión en un equipo Windows con una cuenta que tenga permiso para editar las políticas
de grupo, como el usuario del dominio AD Administrator.
2. Abra la página web Group Policy Management Console.
3. Haga clic con el botón derecho del ratón en su dominio AD y seleccione Create a GPO in this
domain, and Link it here.
4. Introduzca un nombre para el GPO, como Legacy Printer Driver Policy y haga clic en OK. El
nuevo GPO aparecerá bajo la entrada del dominio.
5. Haga clic con el botón derecho del ratón en el GPO recién creado y seleccione Edit para abrir la
página Group Policy Management Editor.
6. Navegue hasta Configuración del equipo → Políticas → Plantillas administrativas →

Impresoras.
88
7. En la parte derecha de la ventana, haga doble clic en Point and Print Restriction para editar la
política:
a. Habilite la política y configure las siguientes opciones:
i. Seleccione Users can only point and print to these servers e introduzca el nombre
de dominio completo (FQDN) del servidor de impresión Samba en el campo situado
junto a esta opción.
ii. En las dos casillas de Security Prompts, seleccione Do not show warning or
elevation prompt.
89
b. Haga clic en Aceptar.
8. Haga doble clic en Package Point and Print - Approved servers para editar la política:
a. Habilite la política y haga clic en el botón Show.
b. Introduzca el FQDN del servidor de impresión Samba.
90
c. Cierre tanto la ventana Show Contents como la de propiedades de la política haciendo clic
en OK.
9. Cierre la página Group Policy Management Editor.
10. Cierre la página Group Policy Management Console.
Después de que los miembros del dominio de Windows aplicaran la política de grupo, los controladores
de impresora se descargan automáticamente del servidor Samba cuando un usuario se conecta a una
impresora.
Para más detalles sobre el uso de las políticas de grupo, consulte la documentación de Windows.
3.16.5. Carga de controladores y preconfiguración de impresoras

Utilice la aplicación Print Management en un cliente Windows para cargar los controladores y
preconfigurar las impresoras alojadas en el servidor de impresión Samba. Para más detalles, consulte la
3.17. AJUSTE DEL RENDIMIENTO DE UN SERVIDOR SAMBA

Este capítulo describe qué ajustes pueden mejorar el rendimiento de Samba en ciertas situaciones, y
qué ajustes pueden tener un impacto negativo en el rendimiento.
Partes de esta sección han sido adoptadas de la documentación de Performance Tuning publicada en el
Wiki de Samba. Licencia: CC BY 4.0. Autores y colaboradores: Ver la pestaña de historia en la página de
la Wiki.
Requisitos previos
Samba se configura como servidor de archivos o de impresión
3.17.1. Configuración de la versión del protocolo SMB

Cada nueva versión de SMB añade funciones y mejora el rendimiento del protocolo. Los recientes
91
sistemas operativos Windows y Windows Server siempre admiten la última versión del protocolo. Si
Samba también utiliza la última versión del protocolo, los clientes de Windows que se conectan a Samba
se benefician de las mejoras de rendimiento. En Samba, el valor por defecto del protocolo máximo del
servidor se establece en la última versión estable del protocolo SMB soportada.
NOTA
Para tener siempre habilitada la última versión estable del protocolo SMB, no configure
el parámetro server max protocol. Si establece el parámetro manualmente, tendrá que
modificar la configuración con cada nueva versión del protocolo SMB, para tener
habilitada la última versión del protocolo.
El siguiente procedimiento explica cómo utilizar el valor por defecto en el parámetro server max
protocol.
Procedimiento
1. Eliminar el parámetro server max protocol de la sección [global] en el archivo

2. Recargar la configuración de Samba
3.17.2. Ajuste de los recursos compartidos con directorios que contienen un gran
número de archivos
Linux admite nombres de archivo que distinguen mayúsculas y minúsculas. Por esta razón, Samba
necesita escanear los directorios en busca de nombres de archivo en mayúsculas y minúsculas cuando
busca o accede a un archivo. Puede configurar un recurso compartido para crear nuevos archivos sólo
en minúsculas o mayúsculas, lo que mejora el rendimiento.
Requisitos previos
Samba está configurado como servidor de archivos
Procedimiento
1. Cambia el nombre de todos los archivos del recurso compartido a minúsculas.
NOTA
Utilizando los ajustes de este procedimiento, los archivos con nombres que no
estén en minúsculas ya no se mostrarán.
2. Establezca los siguientes parámetros en la sección de la acción:
case sensitive = true

default case = lower
preserve case = no
short preserve case = no
Para más detalles sobre los parámetros, consulte sus descripciones en la página man
92
Para más detalles sobre los parámetros, consulte sus descripciones en la página man
smb.conf(5).
# testparm
Después de aplicar estos ajustes, los nombres de todos los archivos recién creados en este recurso
compartido utilizan minúsculas. Debido a estos ajustes, Samba ya no necesita escanear el directorio en
busca de mayúsculas y minúsculas, lo que mejora el rendimiento.
3.17.3. Ajustes que pueden tener un impacto negativo en el rendimiento

Por defecto, el kernel de Red Hat Enterprise Linux está ajustado para un alto rendimiento de la red. Por
ejemplo, el kernel utiliza un mecanismo de auto-ajuste para los tamaños de búfer. El ajuste del
parámetro socket options en el archivo /etc/samba/smb.conf anula estos ajustes del kernel. Como
resultado, el establecimiento de este parámetro disminuye el rendimiento de la red Samba en la mayoría
de los casos.
Para utilizar la configuración optimizada del Kernel, elimine el parámetro socket options de la sección
[global] en el sitio web /etc/samba/smb.conf.
3.18. CONFIGURAR SAMBA PARA QUE SEA COMPATIBLE CON

CLIENTES QUE REQUIEREN UNA VERSIÓN DE SMB INFERIOR A LA
PREDETERMINADA
Samba utiliza un valor razonable y seguro por defecto para la versión mínima de bloque de mensajes de
servidor (SMB) que soporta. Sin embargo, si tiene clientes que requieren una versión SMB más antigua,
puede configurar Samba para que la soporte.
3.18.1. Establecer la versión mínima del protocolo SMB soportada por un servidor
Samba
En Samba, el parámetro server min protocol en el archivo /etc/samba/smb.conf define la versión
mínima del protocolo de bloque de mensajes del servidor (SMB) que soporta el servidor Samba. Esta
sección describe cómo cambiar la versión mínima del protocolo SMB.
NOTA
Por defecto, Samba en RHEL 8.2 y posteriores sólo soporta el protocolo SMB2 y
versiones más recientes. Red Hat recomienda no utilizar el protocolo obsoleto SMB1. Sin
embargo, si su entorno requiere SMB1, puede establecer manualmente el parámetro
server min protocol a NT1 para volver a habilitar SMB1.
Requisitos previos
Samba está instalado y configurado.
93
Procedimiento
1. Edite el archivo /etc/samba/smb.conf, añada el parámetro server min protocol y establezca el

parámetro a la versión mínima del protocolo SMB que el servidor debe soportar. Por ejemplo,
para establecer la versión mínima del protocolo SMB en SMB3, añada:
protocolo mínimo del servidor = SMB3
Para obtener una lista de las versiones de protocolo que puede establecer en el parámetro
server min protocol, consulte la descripción del parámetro server max protocol en la página
de manual smb.conf(5).
3.19. UTILIDADES DE LÍNEA DE COMANDOS DE SAMBA DE USO

FRECUENTE
En este capítulo se describen los comandos más utilizados cuando se trabaja con un servidor Samba.
3.19.1. Uso de los comandos net ads join y net rpc join
Utilizando el subcomando join de la utilidad net, puede unir Samba a un dominio AD o NT4. Para unirse
al dominio, debe crear el archivo /etc/samba/smb.conf manualmente y, opcionalmente, actualizar las
configuraciones adicionales, como PAM.
IMPORTANTE
Red Hat recomienda utilizar la utilidad realm para unirse a un dominio. La utilidad realm
actualiza automáticamente todos los archivos de configuración involucrados.
Procedimiento
1. Cree manualmente el archivo /etc/samba/smb.conf con la siguiente configuración:
Para un miembro del dominio AD:
[global]
workgroup = domain_name
security = ads
passdb backend = tdbsam
realm = AD_REALM
Para un miembro del dominio NT4:
[global]
workgroup = domain_name
security = user
passdb backend = tdbsam
2. Añada una configuración de asignación de ID para el dominio por defecto * y para el dominio al
94
2. Añada una configuración de asignación de ID para el dominio por defecto * y para el dominio al
que desea unirse a la sección [global] en el archivo /etc/samba/smb.conf.
# testparm
4. Únase al dominio como administrador del mismo:
Para unirse a un dominio AD:
# net ads join -U "DOMAIN\administrator"
Para unirse a un dominio NT4:
# net rpc join -U "DOMAIN\administrator"
5. Añada la fuente winbind a la entrada de la base de datos passwd y group en el archivo

/etc/nsswitch.conf:
passwd: files winbind

group: files winbind
6. Habilite e inicie el servicio winbind:
# systemctl enable --now winbind
7. Opcionalmente, configure PAM utilizando la utilidad authselect.

Para más detalles, consulte la página man authselect(8).
8. Opcionalmente para entornos AD, configure el cliente Kerberos.

Para más detalles, consulte la documentación de su cliente Kerberos.
Sección 3.5.1, “Unir un sistema RHEL a un dominio AD” .
Sección 3.4, “Comprender y configurar la asignación de ID de Samba” .
3.19.2. Uso del comando net rpc rights

En Windows, puede asignar privilegios a cuentas y grupos para realizar operaciones especiales, como
establecer ACL en un recurso compartido o cargar controladores de impresora. En un servidor Samba,
puede utilizar el comando net rpc rights para gestionar los privilegios.
Los privilegios de la lista se pueden establecer

Para enumerar todos los privilegios disponibles y sus propietarios, utilice el comando net rpc rights list.
Por ejemplo:
# net rpc rights list -U "DOMAIN\administrator"

SeMachineAccountPrivilege Add machines to domain
SeTakeOwnershipPrivilege Take ownership of files or other objects
SeBackupPrivilege Back up files and directories
95
SeRestorePrivilege Restore files and directories

SeRemoteShutdownPrivilege Force shutdown from a remote system
SePrintOperatorPrivilege Manage printers
SeAddUsersPrivilege Add users and groups to the domain
SeDiskOperatorPrivilege Manage disk shares
SeSecurityPrivilege System security
Concesión de privilegios
Para conceder un privilegio a una cuenta o grupo, utilice el comando net rpc rights grant.
Por ejemplo, conceda el privilegio SePrintOperatorPrivilege al grupo DOMAIN\printadmin grupo:
# net rpc rights grant "DOMAIN\printadmin" SePrintOperatorPrivilege -U

Revocación de privilegios
Para revocar un privilegio de una cuenta o grupo, utilice el comando net rpc rights revoke.
Por ejemplo, para revocar el privilegio SePrintOperatorPrivilege del DOMAIN\printadmin grupo:
# net rpc rights remoke "DOMAIN\printadmin" SePrintOperatorPrivilege -U

Successfully revoked rights.
3.19.3. Utilizando el comando net rpc share

El comando net rpc share proporciona la capacidad de listar, añadir y eliminar recursos compartidos en
un servidor Samba o Windows local o remoto.
Acciones de la lista
Para listar los recursos compartidos de un servidor SMB, utilice el comando net rpc share list.
Opcionalmente, pase el parámetro -S server_name al comando para listar los recursos compartidos de
un servidor remoto. Por ejemplo:
# net rpc share list -U "DOMAIN\administrator" -S server_name

IPC$
share_1
share_2
...
NOTA
Los recursos compartidos alojados en un servidor Samba que tienen browseable = no

establecido en su sección en el archivo /etc/samba/smb.conf no se muestran en la
salida.
Añadir una acción

El comando net rpc share add permite añadir un recurso compartido a un servidor SMB.
Por ejemplo, para añadir un recurso compartido llamado example en un servidor Windows remoto que
96
Por ejemplo, para añadir un recurso compartido llamado example en un servidor Windows remoto que
comparte el directorio C:\example\:
# net rpc share add example="C:\example" -U "DOMAIN\administrator" -S server_name
NOTA
Debe omitir la barra invertida final en la ruta cuando especifique un nombre de directorio
de Windows.
Para utilizar el comando para añadir un recurso compartido a un servidor Samba:
El usuario especificado en el parámetro -U debe tener el privilegio SeDiskOperatorPrivilege

concedido en el servidor de destino.
Debe escribir un script que añada una sección de recursos compartidos al archivo
/etc/samba/smb.conf y recargue Samba. El script debe establecerse en el parámetro add
share command en la sección [global] en /etc/samba/smb.conf. Para más detalles, consulte la
descripción de add share command en la página man de smb.conf(5).
Eliminar una acción

El comando net rpc share delete permite eliminar un recurso compartido de un servidor SMB.
Por ejemplo, para eliminar el recurso compartido llamado ejemplo de un servidor Windows remoto:
# net rpc share delete example -U "DOMAIN\administrator" -S server_name
Para utilizar el comando para eliminar un recurso compartido de un servidor Samba:
El usuario especificado en el parámetro -U debe tener concedido el privilegio

SeDiskOperatorPrivilege.
Debe escribir un script que elimine la sección del recurso compartido del archivo
/etc/samba/smb.conf y vuelva a cargar Samba. El script debe establecerse en el parámetro
delete share command de la sección [global] en /etc/samba/smb.conf. Para más detalles,
consulte la descripción de delete share command en la página man de smb.conf(5).
3.19.4. Uso del comando net user

El comando net user le permite realizar las siguientes acciones en un DC de AD o un PDC de NT4:
Lista de todas las cuentas de usuario
Añadir usuarios
Eliminar usuarios
NOTA
Especificar un método de conexión, como ads para dominios AD o rpc para dominios
NT4, sólo es necesario cuando se listan cuentas de usuario de dominio. Otros
subcomandos relacionados con los usuarios pueden autodetectar el método de conexión.
Pase el parámetro -U user_name al comando para especificar un usuario que esté autorizado a realizar
97
Pase el parámetro -U user_name al comando para especificar un usuario que esté autorizado a realizar
la acción solicitada.
Listado de cuentas de usuario del dominio

Para listar todos los usuarios de un dominio AD:
# net ads user -U "DOMAIN\administrator"
Para listar todos los usuarios de un dominio NT4:
# net rpc user -U "DOMAIN\administrator"
Añadir una cuenta de usuario al dominio

En un miembro del dominio Samba, puede utilizar el comando net user add para añadir una cuenta de
usuario al dominio.
Por ejemplo, añada la cuenta user al dominio:
1. Añade la cuenta:
# net user add user password -U "DOMAIN\administrator"

User user added
2. Opcionalmente, utilice el shell de llamada a procedimiento remoto (RPC) para habilitar la cuenta
en el DC de AD o en el PDC de NT4. Por ejemplo:
# net rpc shell -U DOMAIN\administrator -S DC_or_PDC_name

Talking to domain DOMAIN (S-1-5-21-1424831554-512457234-5642315751)
net rpc> user edit disabled user: no

Set user's disabled flag from [yes] to [no]
net rpc> exit
Eliminar una cuenta de usuario del dominio

En un miembro del dominio Samba, puede utilizar el comando net user delete para eliminar una cuenta
de usuario del dominio.
Por ejemplo, para eliminar la cuenta user del dominio:
# net user delete user -U "DOMAIN\administrator"

User user deleted
3.19.5. Uso de la utilidad rpcclient

La utilidad rpcclient permite ejecutar manualmente las funciones de Microsoft Remote Procedure Call
(MS-RPC) del lado del cliente en un servidor SMB local o remoto. Sin embargo, la mayoría de las
funciones están integradas en utilidades separadas proporcionadas por Samba. Utilice rpcclient sólo
para probar las funciones MS-RPC.
Requisitos previos
98
Ejemplos
Por ejemplo, puede utilizar la utilidad rpcclient para:
Gestionar el subsistema de carrete de la impresora (SPOOLSS).

Ejemplo 3.7. Asignación de un controlador a una impresora
# rpcclient server_name -U "DOMAIN\administrator" -c 'setdriver "printer_name"

"driver_name"'
Enter DOMAIN\administrators password:
Successfully set printer_name to driver driver_name.
Recuperar información sobre un servidor SMB.

Ejemplo 3.8. Listado de todos los archivos compartidos e impresoras compartidas
# rpcclient server_name -U "DOMAIN\administrator" -c 'netshareenum'

netname: Example_Share
remark:
path: C:\srv\samba\example_share\
password:
netname: Example_Printer
remark:
path: C:\var\spool\samba\
password:
Realizar acciones mediante el protocolo Security Account Manager Remote (SAMR).

Ejemplo 3.9. Listado de usuarios en un servidor SMB
# rpcclient server_name -U "DOMAIN\administrator" -c 'enumdomusers'

user:[user1] rid:[0x3e8]
user:[user2] rid:[0x3e9]
Si ejecuta el comando contra un servidor independiente o un miembro del dominio, se enumeran

los usuarios de la base de datos local. Si ejecuta el comando contra un DC de AD o un PDC de
NT4, se enumeran los usuarios del dominio.
Para obtener una lista completa de los subcomandos admitidos, consulte la sección COMMANDS en la
página de manual rpcclient(1).
3.19.6. Uso de la aplicación samba-regedit

Algunos ajustes, como la configuración de las impresoras, se almacenan en el registro del servidor
Samba. Puede utilizar la aplicación samba-regedit basada en ncurses para editar el registro de un
servidor Samba.
99
Requisitos previos
Procedimiento
Para iniciar la aplicación, introduzca:
# samba-regedit
Utilice las siguientes teclas:
Cursor arriba y cursor abajo: Navegar por el árbol del registro y los valores.
Introducir: Abre una tecla o edita un valor.
Pestaña: Cambia entre el panel Key y Value.
Ctrl+C: Cierra la aplicación.
3.19.7. Uso de la utilidad smbcontrol

La utilidad smbcontrol le permite enviar mensajes de control a los servicios smbd, nmbd, winbindd, o a
todos ellos. Estos mensajes de control ordenan al servicio, por ejemplo, que recargue su configuración.
El procedimiento de esta sección muestra cómo recargar la configuración de los servicios smbd, nmbd,
winbindd enviando el tipo de mensaje reload-config al destino all.
Requisitos previos
El paquete samba-common-tools está instalado.
Procedimiento
100
Para más detalles y una lista de los tipos de mensajes de comando disponibles, consulte la página de
manual smbcontrol(1).
3.19.8. Uso de la utilidad smbpasswd

La utilidad smbpasswd gestiona las cuentas de usuario y las contraseñas en la base de datos local de
Samba.
Requisitos previos
El paquete samba-common-tools está instalado.
Procedimiento
1. Si ejecuta el comando como usuario, smbpasswd cambia la contraseña de Samba del usuario
que ejecuta el comando. Por ejemplo:
[user@server ~]$ smbpasswd

New SMB password: password
Retype new SMB password: password
2. Si ejecuta smbpasswd como usuario de root, puede utilizar la utilidad, por ejemplo, para
Crear un nuevo usuario:
[root@server ~]# smbpasswd -a user_name

New SMB password: password` Retype new SMB password: [command]password`
Added user user_name.
NOTA
Antes de poder añadir un usuario a la base de datos Samba, debe crear la

cuenta en el sistema operativo local. Consulte la sección Añadir un nuevo
usuario desde la línea de comandos en la guía Configurar los ajustes básicos
del sistema.
Habilitar un usuario de Samba:
[root@server ~]# smbpasswd -e user_name

Enabled user user_name.
Desactivar un usuario de Samba:
[root@server ~]# smbpasswd -x user_name

Disabled user ser_name
Eliminar un usuario:
101
[root@server ~]# smbpasswd -x user_name

Deleted user user_name.
Para más detalles, consulte la página de manual smbpasswd(8).
3.19.9. Uso de la utilidad smbstatus

La utilidad smbstatus informa sobre:
Conexiones por PID de cada demonio smbd al servidor Samba. Este informe incluye el nombre
de usuario, el grupo principal, la versión del protocolo SMB, el cifrado y la información de firma.
Conexiones por recurso compartido Samba. Este informe incluye el PID del demonio smbd, la
IP de la máquina que se conecta, la marca de tiempo cuando se estableció la conexión, el
cifrado y la información de firma.
Una lista de archivos bloqueados. Las entradas del informe incluyen más detalles, como los tipos
de bloqueo oportunista (oplock)
Requisitos previos
El paquete samba está instalado.
El servicio smbd está funcionando.
Procedimiento
# smbstatus
Samba version 4.12.3

PID Username Group Machine Protocol Version Encryption
Signing
....------------------------------------------------------------------------------------------------------------------------
-
963 DOMAIN\administrator DOMAIN\domain users client-pc (ipv4:192.0.2.1:57786) SMB3_02
- AES-128-CMAC
Service pid Machine Connected at Encryption Signing:

....---------------------------------------------------------------------------
example 969 192.0.2.1 Thu Nov 1 10:00:00 2018 CEST - AES-128-CMAC
Locked files:
Pid Uid DenyMode Access R/W Oplock SharePath Name Time
....--------------------------------------------------------------------------------------------------------
969 10000 DENY_WRITE 0x120089 RDONLY LEASE(RWH) /srv/samba/example file.txt Thu
Nov 1 10:00:00 2018
Para más detalles, consulte la página de manual smbstatus(1).
3.19.10. Uso de la utilidad smbtar
102
La utilidad smbtar hace una copia de seguridad del contenido de un recurso compartido SMB o de un
subdirectorio del mismo y almacena el contenido en un archivo tar. Como alternativa, puede escribir el
contenido en un dispositivo de cinta.
Requisitos previos
Procedimiento
Utilice el siguiente comando para hacer una copia de seguridad del contenido del directorio
demo en el recurso compartido //server/example/ y almacenar el contenido en el archivo
/root/example.tar:
# smbtar -s server -x example -u user_name -p password -t /root/example.tar
Para más detalles, consulte la página de manual smbtar(1).
3.19.11. Uso de la utilidad wbinfo

La utilidad wbinfo consulta y devuelve la información creada y utilizada por el servicio winbindd.
Requisitos previos
El paquete samba-winbind-clients está instalado.
Procedimiento
Puede utilizar wbinfo, por ejemplo, para:
Lista de usuarios del dominio:
# wbinfo -u
AD\administrator
AD\guest
...
Lista de grupos de dominios:
# wbinfo -g
AD\domain computers
AD\domain admins
AD\domain users
...
Muestra el SID de un usuario:
# wbinfo --name-to-sid="AD\administrator"
S-1-5-21-1762709870-351891212-3141221786-500 SID_USER (1)
Muestra información sobre dominios y fideicomisos:
103
# wbinfo --trusted-domains --verbose

Domain Name DNS Domain Trust Type Transitive In Out
BUILTIN None Yes Yes Yes
server None Yes Yes Yes
DOMAIN1 domain1.example.com None Yes Yes Yes
DOMAIN2 domain2.example.com External No Yes Yes
Para más detalles, consulte la página de manual wbinfo(1).
3.20. INFORMACIÓN RELACIONADA

Los paquetes Red Hat Samba incluyen páginas de manual para todos los comandos Samba y
archivos de configuración que el paquete instala. Por ejemplo, para mostrar la página de manual
del archivo /etc/samba/smb.conf que explica todos los parámetros de configuración que puede
establecer en este archivo:
# man smb.conf
El directorio /usr/share/docs/samba-version/ contiene documentación general, scripts de

ejemplo y archivos de esquema LDAP, proporcionados por el proyecto Samba.
Guía de administración de Red Hat Cluster Storage : Proporciona información sobre la

configuración de Samba y la base de datos trivial en clúster (CDTB) para compartir los
directorios almacenados en un volumen GlusterFS.
Para más detalles sobre el montaje de un recurso compartido SMB en Red Hat Enterprise Linux,
consulte Montaje de un recurso compartido SMB en Red Hat Enterprise Linux .
104
CAPÍTULO 4. EXPORTACIÓN DE RECURSOS COMPARTIDOS NFS
CAPÍTULO 4. EXPORTACIÓN DE RECURSOS COMPARTIDOS

NFS
Como administrador del sistema, puede utilizar el servidor NFS para compartir un directorio en su
sistema a través de la red.
4.1. INTRODUCCIÓN A NFS

Esta sección explica los conceptos básicos del servicio NFS.
Un sistema de archivos de red (NFS) permite a los hosts remotos montar sistemas de archivos a través
de una red e interactuar con esos sistemas de archivos como si estuvieran montados localmente. Esto
permite consolidar los recursos en servidores centralizados en la red.
El servidor NFS consulta el archivo de configuración /etc/exports para determinar si el cliente puede
acceder a cualquier sistema de archivos exportado. Una vez verificado, todas las operaciones de
archivos y directorios están disponibles para el usuario.
4.2. VERSIONES DE NFS COMPATIBLES

Esta sección lista las versiones de NFS soportadas en Red Hat Enterprise Linux y sus características.
Actualmente, Red Hat Enterprise Linux 8 soporta las siguientes versiones principales de NFS:
La versión 3 de NFS (NFSv3) admite escrituras asíncronas seguras y es más robusta en la

gestión de errores que la anterior NFSv2; también admite tamaños de archivo y
desplazamientos de 64 bits, lo que permite a los clientes acceder a más de 2 GB de datos de
archivo.
La versión 4 de NFS (NFSv4) funciona a través de cortafuegos y en Internet, ya no requiere un

servicio rpcbind, admite listas de control de acceso (ACL) y utiliza operaciones con estado.
La versión 2 de NFS (NFSv2) ya no es soportada por Red Hat.
Versión NFS por defecto

La versión NFS por defecto en Red Hat Enterprise Linux 8 es la 4.2. Los clientes NFS intentan montar
usando NFSv4.2 por defecto, y vuelven a NFSv4.1 cuando el servidor no soporta NFSv4.2. El montaje
vuelve a ser NFSv4.0 y luego NFSv3.
Características de las versiones menores de NFS

A continuación se presentan las características de NFSv4.2 en Red Hat Enterprise Linux 8:
Copia del lado del servidor

Permite que el cliente NFS copie datos de forma eficiente sin desperdiciar recursos de red utilizando
la llamada al sistema copy_file_range().
Archivos dispersos
Permite que los archivos tengan uno o más holes, que son bloques de datos no asignados o no
inicializados que constan sólo de ceros. La operación lseek() en NFSv4.2 admite seek_hole() y
seek_data(), lo que permite a las aplicaciones trazar la ubicación de los huecos en el archivo disperso.
Reserva de espacio
Permite a los servidores de almacenamiento reservar espacio libre, lo que impide que los servidores
se queden sin espacio. NFSv4.2 admite la operación allocate() para reservar espacio, la operación
deallocate() para desreservar espacio y la operación fallocate() para preasignar o desasignar espacio
105
en un archivo.
Etiquetado NFS
Aplica los derechos de acceso a los datos y habilita las etiquetas SELinux entre un cliente y un
servidor para archivos individuales en un sistema de archivos NFS.
Mejoras en el diseño
Proporciona la operación layoutstats(), que permite a algunos servidores NFS paralelos (pNFS)
recoger mejores estadísticas de rendimiento.
A continuación se detallan las características de NFSv4.1:
Mejora el rendimiento y la seguridad de la red, y también incluye soporte del lado del cliente
para pNFS.
Ya no se requiere una conexión TCP independiente para las devoluciones de llamada, lo que
permite a un servidor NFS conceder delegaciones incluso cuando no puede contactar con el
cliente: por ejemplo, cuando interfiere NAT o un cortafuegos.
Proporciona la semántica de "exactamente una vez" (excepto para las operaciones de reinicio),
evitando un problema anterior por el que ciertas operaciones devolvían a veces un resultado
inexacto si se perdía una respuesta y la operación se enviaba dos veces.
4.3. LOS PROTOCOLOS TCP Y UDP EN NFSV3 Y NFSV4

NFSv4 requiere el Protocolo de Control de Transmisión (TCP) que se ejecuta en una red IP.
NFSv3 también podía utilizar el Protocolo de Datagrama de Usuario (UDP) en versiones anteriores de
Red Hat Enterprise Linux. En Red Hat Enterprise Linux 8, NFS sobre UDP ya no está soportado. Por
defecto, UDP está desactivado en el servidor NFS.
4.4. SERVICIOS REQUERIDOS POR NFS

Esta sección enumera los servicios del sistema que se requieren para ejecutar un servidor NFS o montar
recursos compartidos NFS. Red Hat Enterprise Linux inicia estos servicios automáticamente.
Red Hat Enterprise Linux utiliza una combinación de soporte a nivel de kernel y procesos de servicio
para proporcionar el intercambio de archivos NFS. Todas las versiones de NFS se basan en llamadas de
procedimiento remoto (RPC) entre clientes y servidores. Para compartir o montar sistemas de archivos
NFS, los servicios siguientes trabajan juntos dependiendo de la versión de NFS implementada:
nfsd
El módulo del núcleo del servidor NFS que atiende las solicitudes de sistemas de archivos NFS
compartidos.
rpcbind
Acepta las reservas de puertos de los servicios RPC locales. Estos puertos se ponen a disposición (o
se anuncian) para que los servicios RPC remotos correspondientes puedan acceder a ellos. El servicio
rpcbind responde a las solicitudes de servicios RPC y establece conexiones con el servicio RPC
solicitado. Esto no se utiliza con NFSv4.
rpc.mountd
Este proceso es utilizado por un servidor NFS para procesar las solicitudes MOUNT de los clientes
NFSv3. Comprueba que el recurso compartido NFS solicitado está actualmente exportado por el
servidor NFS y que el cliente puede acceder a él. Si la solicitud de montaje está permitida, el servicio
106
nfs-mountd responde con un estado de éxito y proporciona el File-Handle de este recurso

compartido NFS al cliente NFS.
rpc.nfsd
Este proceso permite definir las versiones y protocolos NFS explícitos que el servidor anuncia.
Trabaja con el kernel de Linux para satisfacer las demandas dinámicas de los clientes NFS, como
proporcionar hilos del servidor cada vez que un cliente NFS se conecta. Este proceso se
corresponde con el servicio nfs-server.
lockd
Es un hilo del núcleo que se ejecuta tanto en los clientes como en los servidores. Implementa el
protocolo Network Lock Manager (NLM), que permite a los clientes NFSv3 bloquear archivos en el
servidor. Se inicia automáticamente siempre que se ejecuta el servidor NFS y siempre que se monta
un sistema de archivos NFS.
rpc.statd
Este proceso implementa el protocolo RPC Network Status Monitor (NSM), que notifica a los
clientes NFS cuando un servidor NFS se reinicia sin que se caiga. El servicio rpc-statd es iniciado
automáticamente por el servicio nfs-server, y no requiere la configuración del usuario. No se utiliza
con NFSv4.
rpc.rquotad
Este proceso proporciona información sobre las cuotas de los usuarios remotos. El servicio rpc-
rquotad es iniciado automáticamente por el servicio nfs-server y no requiere configuración por
parte del usuario.
rpc.idmapd
Este proceso proporciona llamadas ascendentes al cliente y al servidor NFSv4, que mapean entre los
nombres NFSv4 on-the-wire (cadenas en forma de user@domain) y los UID y GID locales. Para que
idmapd funcione con NFSv4, el archivo /etc/idmapd.conf debe estar configurado. Como mínimo,
debe especificarse el parámetro Domain, que define el dominio de mapeo NFSv4. Si el dominio de
mapeo NFSv4 es el mismo que el nombre de dominio DNS, este parámetro puede omitirse. El
cliente y el servidor deben estar de acuerdo con el dominio de mapeo NFSv4 para que el mapeo de
ID funcione correctamente.
Sólo el servidor NFSv4 utiliza rpc.idmapd, que es iniciado por el servicio nfs-idmapd. El cliente
NFSv4 utiliza la utilidad basada en llaveros nfsidmap, que es llamada por el kernel bajo demanda
para realizar el mapeo de ID. Si hay un problema con nfsidmap, el cliente vuelve a utilizar
rpc.idmapd.
Los servicios RPC con NFSv4

Los protocolos de montaje y bloqueo se han incorporado al protocolo NFSv4. El servidor también
escucha en el conocido puerto TCP 2049. Así, NFSv4 no necesita interactuar con los servicios rpcbind,
lockd y rpc-statd. El servicio nfs-mountd sigue siendo necesario en el servidor NFS para configurar las
exportaciones, pero no interviene en ninguna operación over-the-wire.
Para configurar un servidor sólo NFSv4, que no requiere rpcbind, consulte Sección 4.14,
“Configuración de un servidor sólo NFSv4”.
4.5. FORMATOS DE NOMBRES DE HOST NFS

En esta sección se describen diferentes formatos que se pueden utilizar para especificar un host al
montar o exportar un recurso compartido NFS.
Puede especificar el host en los siguientes formatos:
107
Máquina individual
Cualquiera de los siguientes:
Un nombre de dominio completamente calificado (que pueda ser resuelto por el servidor)
Nombre de host (que puede ser resuelto por el servidor)
Una dirección IP.
Redes IP
Cualquiera de los siguientes formatos es válido:
a.b.c.d/zdonde a.b.c.d es la red y z es el número de bits de la máscara de red; por ejemplo

192.168.0.0/24.
a.b.c.d/netmaskdonde a.b.c.d es la red y netmask es la máscara de red; por ejemplo,

192.168.100.8/255.255.255.0.
Netgroups
El formato @group-name formato , donde group-name es el nombre del grupo de red NIS.
4.6. CONFIGURACIÓN DEL SERVIDOR NFS

Esta sección describe la sintaxis y las opciones de dos formas de configurar las exportaciones en un
servidor NFS:
Edición manual del archivo de configuración /etc/exports
Utilizando la utilidad exportfs en la línea de comandos
4.6.1. El archivo de configuración /etc/exports

El archivo /etc/exports controla qué sistemas de archivos se exportan a los hosts remotos y especifica
las opciones. Sigue las siguientes reglas de sintaxis:
Las líneas en blanco se ignoran.
Para añadir un comentario, inicie una línea con la marca de almohadilla (#).
Puede envolver las líneas largas con una barra invertida (\).
Cada sistema de archivos exportado debe estar en su propia línea individual.
Cualquier lista de hosts autorizados colocada después de un sistema de archivos exportado

debe estar separada por caracteres de espacio.
Las opciones para cada uno de los hosts deben colocarse entre paréntesis directamente
después del identificador del host, sin espacios de separación entre el host y el primer
paréntesis.
Entrada de exportación
Cada entrada de un sistema de archivos exportado tiene la siguiente estructura:
export host(options)
108
También es posible especificar varios hosts, junto con opciones específicas para cada uno de ellos. Para
ello, escríbalos en la misma línea como una lista delimitada por espacios, con cada nombre de host
seguido de sus respectivas opciones (entre paréntesis), como en:
export host1(options1) host2(options2) host3(options3)
En esta estructura:
export
El directorio que se exporta
host
El host o la red a la que se comparte la exportación
options
Las opciones que se utilizarán para el anfitrión
Ejemplo 4.1. Un simple archivo /etc/exports
En su forma más simple, el archivo /etc/exports sólo especifica el directorio exportado y los hosts
autorizados a acceder a él:
/exportado/directorio bob.ejemplo.com
Aquí, bob.example.com puede montar /exported/directory/ desde el servidor NFS. Como no se

especifican opciones en este ejemplo, NFS utiliza las opciones por defecto.
IMPORTANTE
El formato del archivo /etc/exports es muy preciso, sobre todo en lo que respecta al uso
del carácter de espacio. Recuerde que siempre debe separar los sistemas de archivos
exportados de los hosts y los hosts entre sí con un carácter de espacio. Sin embargo, no
debe haber ningún otro carácter de espacio en el archivo, excepto en las líneas de
comentario.
Por ejemplo, las dos líneas siguientes no significan lo mismo:
/home bob.example.com(rw)
/home bob.example.com (rw)
La primera línea permite que sólo los usuarios de bob.example.com tengan acceso de
lectura y escritura al directorio /home. La segunda línea permite a los usuarios de
bob.example.com montar el directorio como sólo lectura (el valor predeterminado),
mientras que el resto del mundo puede montarlo como lectura/escritura.
Opciones por defecto

Las opciones por defecto para una entrada de exportación son:
ro
El sistema de archivos exportado es de sólo lectura. Los hosts remotos no pueden cambiar los datos
compartidos en el sistema de archivos. Para permitir a los hosts realizar cambios en el sistema de
archivos (es decir, leer y escribir), especifique la opción rw.
109
sync
El servidor NFS no responderá a las solicitudes antes de que los cambios realizados por las
solicitudes anteriores se escriban en el disco. Para habilitar las escrituras asíncronas en su lugar,
especifique la opción async.
wdelay
El servidor NFS retrasará la escritura en el disco si sospecha que otra petición de escritura es
inminente. Esto puede mejorar el rendimiento, ya que reduce el número de veces que se debe
acceder al disco mediante comandos de escritura separados, reduciendo así la sobrecarga de
escritura. Para desactivar esto, especifique la opción no_wdelay, que sólo está disponible si también
se especifica la opción de sincronización por defecto.
root_squash
Esto evita que los usuarios root conectados remotamente (en lugar de localmente) tengan privilegios
de root; en su lugar, el servidor NFS les asigna el ID de usuario nobody. Esto efectivamente "aplasta"
el poder del usuario root remoto al usuario local más bajo, evitando posibles escrituras no
autorizadas en el servidor remoto. Para desactivar el aplastamiento de la raíz, especifique la opción
no_root_squash.
Para aplastar a todos los usuarios remotos (incluido el root), utilice la opción all_squash. Para
especificar los identificadores de usuario y grupo que el servidor NFS debe asignar a los usuarios
remotos de un determinado host, utilice las opciones anonuid y anongid, respectivamente, como
en:
export host(anonuid=uid,anongid=gid)
Aquí, uid y gid son el número de identificación del usuario y el número de identificación del grupo,
respectivamente. Las opciones anonuid y anongid permiten crear una cuenta especial de usuario y
de grupo para que los usuarios remotos de NFS la compartan.
Por defecto, las listas de control de acceso (ACL) son soportadas por NFS bajo Red Hat Enterprise
Linux. Para desactivar esta función, especifique la opción no_acl al exportar el sistema de archivos.
Opciones por defecto y anuladas

Cada valor por defecto para cada sistema de archivos exportado debe ser anulado explícitamente. Por
ejemplo, si no se especifica la opción rw, el sistema de archivos exportado se comparte como de sólo
lectura. La siguiente es una línea de ejemplo de /etc/exports que anula dos opciones por defecto:
/otro/exportado/directorio 192.168.0.3(rw,async)
En este ejemplo, 192.168.0.3 puede montar /another/exported/directory/ lectura y escritura, y todas

las escrituras en disco son asíncronas.
4.6.2. La utilidad exportfs

La utilidad exportfs permite al usuario root exportar o desexportar directorios selectivamente sin
reiniciar el servicio NFS. Cuando se le dan las opciones adecuadas, la utilidad exportfs escribe los
sistemas de archivos exportados en /var/lib/nfs/xtab. Dado que el servicio nfs-mountd hace referencia
al archivo xtab cuando decide los privilegios de acceso a un sistema de archivos, los cambios en la lista
de sistemas de archivos exportados tienen efecto inmediato.
Opciones comunes de exportfs

A continuación se presenta una lista de las opciones más utilizadas disponibles para exportfs:
-r
Hace que se exporten todos los directorios listados en /etc/exports construyendo una nueva lista de
110
Hace que se exporten todos los directorios listados en /etc/exports construyendo una nueva lista de
exportación en /etc/lib/nfs/xtab. Esta opción actualiza efectivamente la lista de exportación con
cualquier cambio realizado en /etc/exports.
-a
Hace que se exporten o no todos los directorios, dependiendo de qué otras opciones se pasen a
exportfs. Si no se especifican otras opciones, exportfs exporta todos los sistemas de archivos
especificados en /etc/exports.
-o file-systems
Especifica los directorios a exportar que no aparecen en /etc/exports. Sustituya file-systems con los
sistemas de archivos adicionales que se van a exportar. Estos sistemas de archivos deben tener el
mismo formato que el especificado en /etc/exports. Esta opción suele utilizarse para probar un
sistema de archivos exportado antes de añadirlo permanentemente a la lista de sistemas de archivos
exportados.
-i
Ignora /etc/exports; sólo se utilizan las opciones dadas desde la línea de comandos para definir los
sistemas de archivos exportados.
-u
Desexporta todos los directorios compartidos. El comando exportfs -ua suspende la compartición
de archivos NFS mientras mantiene todos los servicios NFS activos. Para volver a habilitar el uso
compartido de NFS, utilice exportfs -r.
-v
Operación verbosas, donde los sistemas de archivos que se exportan o no se exportan se muestran
con mayor detalle cuando se ejecuta el comando exportfs.
Si no se pasan opciones a la utilidad exportfs, ésta muestra una lista de los sistemas de archivos
exportados actualmente.
Para obtener información sobre los diferentes métodos para especificar los nombres de host,
consulte Sección 4.5, “Formatos de nombres de host NFS” .
Para obtener una lista completa de las opciones de exportación, consulte la página de manual
exports(5).
Para más información sobre la utilidad exportfs, consulte la página de manual exportfs(8).
4.7. NFS Y RPCBIND

Esta sección explica el propósito del servicio rpcbind, que es requerido por NFSv3.
El servicio rpcbind asigna los servicios de llamada a procedimiento remoto (RPC) a los puertos en los
que escuchan. Los procesos RPC notifican a rpcbind cuando se inician, registrando los puertos en los
que escuchan y los números de programa RPC que esperan servir. A continuación, el sistema cliente se
pone en contacto con rpcbind en el servidor con un número de programa RPC concreto. El servicio
rpcbind redirige al cliente al número de puerto adecuado para que pueda comunicarse con el servicio
solicitado.
Dado que los servicios basados en RPC dependen de rpcbind para realizar todas las conexiones con las
solicitudes de los clientes entrantes, rpcbind debe estar disponible antes de que se inicie cualquiera de
estos servicios.
Las reglas de control de acceso para rpcbind afectan a todos los servicios basados en RPC.
111
Alternativamente, es posible especificar reglas de control de acceso para cada uno de los demonios
RPC de NFS.
Para conocer la sintaxis precisa de las reglas de control de acceso, consulte las páginas de
manual rpc.mountd(8) y rpc.statd(8).
4.8. INSTALACIÓN DE NFS

Este procedimiento instala todos los paquetes necesarios para montar o exportar recursos compartidos
NFS.
Procedimiento
Instale el paquete nfs-utils:
# yum install nfs-utils
4.9. INICIAR EL SERVIDOR NFS

Este procedimiento describe cómo iniciar el servidor NFS, que es necesario para exportar los recursos
compartidos NFS.
Requisitos previos
En el caso de los servidores que admiten conexiones NFSv2 o NFSv3, el servicio rpcbind debe
estar en funcionamiento. Para comprobar que rpcbind está activo, utilice el siguiente comando:
$ systemctl status rpcbind
Si el servicio está detenido, inícielo y actívelo:
$ systemctl enable --now rpcbind
Procedimiento
Para iniciar el servidor NFS y permitir que se inicie automáticamente en el arranque, utilice el
siguiente comando:
# systemctl enable --now nfs-server
4.10. SOLUCIÓN DE PROBLEMAS DE NFS Y RPCBIND

Debido a que el servicio rpcbind proporciona la coordinación entre los servicios RPC y los números de
112
puerto utilizados para comunicarse con ellos, es útil ver el estado de los servicios RPC actuales
utilizando rpcbind cuando se solucionan problemas. La utilidad rpcinfo muestra cada servicio basado
en RPC con números de puerto, un número de programa RPC, un número de versión y un tipo de
protocolo IP (TCP o UDP).
Procedimiento
1. Para asegurarse de que los servicios basados en NFS RPC están habilitados para rpcbind,
utilice el siguiente comando:
# rpcinfo -p
Ejemplo 4.2. salida del comando rpcinfo -p
La siguiente es una muestra de la salida de este comando:
program vers proto port service

100000 4 tcp 111 portmapper
100000 4 udp 111 portmapper
100005 1 udp 20048 mountd
100005 1 tcp 20048 mountd
100005 2 udp 20048 mountd
100005 2 tcp 20048 mountd
100005 3 udp 20048 mountd
100005 3 tcp 20048 mountd
100024 1 udp 37769 status
100024 1 tcp 49349 status
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 3 tcp 2049 nfs_acl
100021 1 udp 56691 nlockmgr
100021 1 tcp 46193 nlockmgr
Si uno de los servicios NFS no se inicia correctamente, rpcbind no podrá asignar las peticiones
RPC de los clientes para ese servicio al puerto correcto.
2. En muchos casos, si NFS no está presente en la salida de rpcinfo, reiniciar NFS hace que el
servicio se registre correctamente en rpcbind y comience a funcionar:
# systemctl restart nfs-server
Para obtener más información y una lista de opciones de rpcinfo, consulte la página de manual
rpcinfo(8).
113
4.11. CONFIGURAR EL SERVIDOR NFS PARA QUE FUNCIONE DETRÁS

DE UN CORTAFUEGOS
NFS requiere el servicio rpcbind, que asigna dinámicamente los puertos para los servicios RPC y puede
causar problemas para configurar las reglas del cortafuegos. Este procedimiento describe cómo
configurar el servidor NFS para que funcione detrás de un cortafuegos.
Procedimiento
1. Para permitir que los clientes accedan a los recursos compartidos NFS detrás de un
cortafuegos, establezca en qué puertos se ejecutan los servicios RPC en la sección [mountd]
del archivo /etc/nfs.conf:
[mountd]
port=port-number
Esto añade la opción -p port-number a la línea de comandos rpc.mount rpc.mount -p port-

number.
2. Para permitir que los clientes accedan a los recursos compartidos de NFS detrás de un firewall,
configure el firewall ejecutando los siguientes comandos en el servidor NFS:
firewall-cmd --permanent --add-service mountd

firewall-cmd --permanent --add-service rpc-bind
firewall-cmd --permanent --add-service nfs
firewall-cmd --permanent --add-port=<mountd-port>/tcp
firewall-cmd --permanent --add-port=<mountd-port>/udp
firewall-cmd --reload
En los comandos, sustituya <mountd-port> por el puerto previsto o un rango de puertos. Al

especificar un rango de puertos, utilice la sintaxis --add-port=<mountd-port>-<mountd-
port>/udp.
3. Para permitir que las devoluciones de llamada de NFSv4.0 atraviesen los cortafuegos, configure
/proc/sys/fs/nfs/nfs_callback_tcpport y permita que el servidor se conecte a ese puerto en el
cliente.
Este paso no es necesario para NFSv4.1 o superior, y los otros puertos para mountd, statd, y
lockd no son necesarios en un entorno NFSv4 puro.
4. Para especificar los puertos que utilizará el servicio RPC nlockmgr, establezca el número de
puerto para las opciones nlm_tcpport y nlm_udpport en el archivo
/etc/modprobe.d/lockd.conf.
5. Reinicie el servidor NFS:
Si NFS no se inicia, compruebe /var/log/messages. Normalmente, NFS no se inicia si se

especifica un número de puerto que ya está en uso.
114
6. Confirme que los cambios han surtido efecto:
# rpcinfo -p
4.12. EXPORTACIÓN DE LA CUOTA RPC A TRAVÉS DE UN

CORTAFUEGOS
Si exporta un sistema de archivos que utiliza cuotas de disco, puede utilizar el servicio de llamada a
procedimiento remoto (RPC) de cuotas para proporcionar datos de cuotas de disco a los clientes NFS.
Procedimiento
1. Habilite e inicie el servicio rpc-rquotad:
# systemctl enable --now rpc-rquotad
NOTA
El servicio rpc-rquotad, si está activado, se inicia automáticamente después de

iniciar el servicio nfs-server.
2. Para que el servicio RPC de cuotas sea accesible detrás de un cortafuegos, el puerto TCP (o
UDP, si está habilitado) 875 debe estar abierto. El número de puerto por defecto se define en el
archivo /etc/services.
Puede anular el número de puerto por defecto añadiendo -p port-number a la variable
RPCRQUOTADOPTS en el archivo /etc/sysconfig/rpc-rquotad.
3. Por defecto, los hosts remotos sólo pueden leer las cuotas. Si desea permitir que los clientes
establezcan cuotas, añada la opción -S a la variable RPCRQUOTADOPTS en el archivo
/etc/sysconfig/rpc-rquotad.
4. Reinicie rpc-rquotad para que los cambios en el archivo /etc/sysconfig/rpc-rquotad surtan

efecto:
# systemctl restart rpc-rquotad
4.13. ACTIVACIÓN DE NFS SOBRE RDMA (NFSORDMA)

El servicio de acceso directo a memoria remota (RDMA) funciona automáticamente en Red Hat
Enterprise Linux 8 si hay hardware compatible con RDMA.
Procedimiento
1. Instale el paquete rdma-core:
# yum install rdma-core
115
2. Para activar la carga automática de los módulos NFSoRDMA server, añada la opción
SVCRDMA_LOAD=yes en una nueva línea del archivo de configuración /etc/rdma/rdma.conf.
La opción rdma=20049 en la sección [nfsd] del archivo /etc/nfs.conf especifica el número de
puerto en el que el servicio NFSoRDMA escucha a los clientes. El estándar RFC 5667 especifica
que los servidores deben escuchar en el puerto 20049 cuando proporcionan servicios NFSv4
sobre RDMA.
El archivo /etc/rdma/rdma.conf contiene una línea que establece la opción

XPRTRDMA_LOAD=yes por defecto, que solicita al servicio rdma que cargue el módulo
NFSoRDMA client.
3. Reinicie el servicio nfs-server:
La norma RFC 5667: https://tools.ietf.org/html/rfc5667.
4.14. CONFIGURACIÓN DE UN SERVIDOR SÓLO NFSV4

Como administrador del servidor NFS, puede configurar el servidor NFS para que sólo admita NFSv4, lo
que minimiza el número de puertos abiertos y servicios en ejecución en el sistema.
4.14.1. Ventajas e inconvenientes de un servidor sólo NFSv4

En esta sección se explican las ventajas e inconvenientes de configurar el servidor NFS para que sólo
admita NFSv4.
Por defecto, el servidor NFS soporta conexiones NFSv3 y NFSv4 en Red Hat Enterprise Linux 8. Sin
embargo, también puede configurar NFS para que sólo soporte la versión 4.0 y posteriores. Esto
minimiza el número de puertos abiertos y servicios en ejecución en el sistema, porque NFSv4 no
requiere que el servicio rpcbind escuche en la red.
Cuando su servidor NFS está configurado como NFSv4 solamente, los clientes que intentan montar
recursos compartidos usando NFSv3 fallan con un error como el siguiente:
La versión de NFS solicitada o el protocolo de transporte no son compatibles.
Opcionalmente, también puede deshabilitar la escucha de las llamadas de protocolo RPCBIND,

MOUNT, y NSM, que no son necesarias en el caso de NFSv4 solamente.
Los efectos de desactivar estas opciones adicionales son:
Los clientes que intentan montar recursos compartidos desde su servidor utilizando NFSv3 no
responden.
El propio servidor NFS no puede montar sistemas de archivos NFSv3.
4.14.2. NFS y rpcbind

Esta sección explica el propósito del servicio rpcbind, que es requerido por NFSv3.
El servicio rpcbind asigna los servicios de llamada a procedimiento remoto (RPC) a los puertos en los
116
que escuchan. Los procesos RPC notifican a rpcbind cuando se inician, registrando los puertos en los
que escuchan y los números de programa RPC que esperan servir. A continuación, el sistema cliente se
pone en contacto con rpcbind en el servidor con un número de programa RPC concreto. El servicio
rpcbind redirige al cliente al número de puerto adecuado para que pueda comunicarse con el servicio
solicitado.
Dado que los servicios basados en RPC dependen de rpcbind para realizar todas las conexiones con las
solicitudes de los clientes entrantes, rpcbind debe estar disponible antes de que se inicie cualquiera de
estos servicios.
Alternativamente, es posible especificar reglas de control de acceso para cada uno de los demonios
RPC de NFS.
Para conocer la sintaxis precisa de las reglas de control de acceso, consulte las páginas de
manual rpc.mountd(8) y rpc.statd(8).
4.14.3. Configurar el servidor NFS para que sólo admita NFSv4

Este procedimiento describe cómo configurar el servidor NFS para que sólo admita la versión 4.0 y
posteriores de NFS.
Procedimiento
1. Desactive NFSv3 añadiendo las siguientes líneas a la sección [nfsd] del archivo de
configuración /etc/nfs.conf:
[nfsd]
vers3=no
2. Opcionalmente, desactive la escucha de las llamadas de protocolo RPCBIND, MOUNT, y NSM,

que no son necesarias en el caso de NFSv4 solamente. Desactive los servicios relacionados:
# systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket
3. Reinicie el servidor NFS:
Los cambios surten efecto en cuanto se inicia o reinicia el servidor NFS.
4.14.4. Verificación de la configuración NFSv4-only

Este procedimiento describe cómo verificar que su servidor NFS está configurado en el modo NFSv4-
only utilizando la utilidad netstat.
Procedimiento
Utilice la utilidad netstat para listar los servicios que escuchan en los protocolos TCP y UDP:
117
# netstat --listening --tcp --udp
Ejemplo 4.3. Salida en un servidor sólo NFSv4
El siguiente es un ejemplo de salida de netstat en un servidor NFSv4-only; la escucha de

RPCBIND, MOUNT, y NSM también está deshabilitada. Aquí, nfs es el único servicio NFS a la
escucha:
Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:nfs 0.0.0.0:* LISTEN
tcp6 0 0 [::]:ssh [::]:* LISTEN
tcp6 0 0 [::]:nfs [::]:* LISTEN
udp 0 0 localhost.locald:bootpc 0.0.0.0:*
Ejemplo 4.4. Resultado antes de configurar un servidor sólo NFSv4
En comparación, la salida de netstat antes de configurar un servidor sólo NFSv4 incluye los
servicios sunrpc y mountd:
Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:40189 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:46813 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:nfs 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:sunrpc 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:mountd 0.0.0.0:* LISTEN
tcp6 0 0 [::]:ssh [::]:* LISTEN
tcp6 0 0 [::]:51227 [::]:* LISTEN
tcp6 0 0 [::]:nfs [::]:* LISTEN
tcp6 0 0 [::]:sunrpc [::]:* LISTEN
tcp6 0 0 [::]:mountd [::]:* LISTEN
tcp6 0 0 [::]:45043 [::]:* LISTEN
udp 0 0 localhost:1018 0.0.0.0:*
udp 0 0 localhost.locald:bootpc 0.0.0.0:*
udp 0 0 0.0.0.0:mountd 0.0.0.0:*
udp 0 0 0.0.0.0:46672 0.0.0.0:*
udp 0 0 0.0.0.0:sunrpc 0.0.0.0:*
udp 0 0 0.0.0.0:33494 0.0.0.0:*
udp6 0 0 [::]:33734 [::]:*
udp6 0 0 [::]:mountd [::]:*
udp6 0 0 [::]:sunrpc [::]:*
udp6 0 0 [::]:40243 [::]:*
4.15. INFORMACIÓN RELACIONADA
118
El wiki de NFS de Linux: https://linux-nfs.org
119
CAPÍTULO 5. ASEGURAR NFS

Para minimizar los riesgos de seguridad de NFS y proteger los datos en el servidor, tenga en cuenta las
siguientes secciones cuando exporte sistemas de archivos NFS en un servidor o los monte en un cliente.
5.1. SEGURIDAD NFS CON AUTH_SYS Y CONTROLES DE

EXPORTACIÓN
NFS ofrece las siguientes opciones tradicionales para controlar el acceso a los archivos exportados:
El servidor restringe qué hosts pueden montar qué sistemas de archivos, ya sea por dirección IP
o por nombre de host.
El servidor aplica los permisos del sistema de archivos para los usuarios de los clientes NFS de la
misma manera que lo hace para los usuarios locales. Tradicionalmente, NFS hace esto utilizando
el mensaje de llamada AUTH_SYS (también llamado AUTH_UNIX), que depende de que el
cliente indique el UID y el GID del usuario. Ten en cuenta que esto significa que un cliente
malicioso o mal configurado podría fácilmente equivocarse y permitir a un usuario el acceso a
archivos que no debería.
Para limitar los riesgos potenciales, los administradores a menudo limitan el acceso a sólo lectura o
aplastan los permisos de usuario a un ID de usuario y grupo común. Lamentablemente, estas soluciones
impiden que el recurso compartido NFS se utilice de la forma prevista originalmente.
Además, si un atacante se hace con el control del servidor DNS utilizado por el sistema que exporta el
sistema de archivos NFS, puede apuntar el sistema asociado a un determinado nombre de host o
nombre de dominio completo a una máquina no autorizada. En este punto, la máquina no autorizada is el
sistema permitido para montar el recurso compartido NFS, porque no se intercambia información de
nombre de usuario o contraseña para proporcionar seguridad adicional para el montaje NFS.
Los comodines deben utilizarse con moderación al exportar directorios a través de NFS, ya que es
posible que el alcance del comodín abarque más sistemas de los previstos.
Para asegurar NFS y rpcbind, utilice, por ejemplo, nftables y firewalld. Para obtener detalles
sobre la configuración de estos marcos, consulte las páginas de manual nft(8) y firewalld-
cmd(1).
5.2. SEGURIDAD NFS CON AUTH_GSS

Todas las versiones de NFS soportan RPCSEC_GSS y el mecanismo Kerberos.
A diferencia de AUTH_SYS, con el mecanismo RPCSEC_GSS Kerberos, el servidor no depende del

cliente para representar correctamente qué usuario está accediendo al archivo. En su lugar, se utiliza la
criptografía para autenticar a los usuarios en el servidor, lo que evita que un cliente malicioso se haga
pasar por un usuario sin tener las credenciales Kerberos de ese usuario. El uso del mecanismo
RPCSEC_GSS Kerberos es la forma más directa de asegurar los montajes porque después de configurar
Kerberos, no se necesita ninguna configuración adicional.
5.3. CONFIGURACIÓN DE UN SERVIDOR Y UN CLIENTE NFS PARA

UTILIZAR KERBEROS
Kerberos es un sistema de autenticación de red que permite a los clientes y a los servidores autenticarse
120
CAPÍTULO 5. ASEGURAR NFS
Kerberos es un sistema de autenticación de red que permite a los clientes y a los servidores autenticarse
entre sí mediante el uso de encriptación simétrica y una tercera parte de confianza, el KDC. Red Hat
recomienda utilizar Identity Management (IdM) para configurar Kerberos.
Requisitos previos
El Centro de Distribución de Claves Kerberos (KDC) está instalado y configurado.
Procedimiento
1. Cree la nfs/hostname.domain@REALM principal en el lado del servidor NFS.
Cree la host/hostname.domain@REALM principal tanto en el lado del servidor como en el

del cliente.
Añade las claves correspondientes a los keytabs del cliente y del servidor.
2. En el lado del servidor, utilice la opción sec= para habilitar los tipos de seguridad deseados.
Para habilitar todos los tipos de seguridad, así como los montajes no criptográficos:
/export *(sec=sys:krb5:krb5i:krb5p)
Los sabores de seguridad válidos para usar con la opción sec= son:
sys: sin protección criptográfica, por defecto
krb5: sólo autenticación
krb5i: protección de la integridad
krb5p: protección de la intimidad
3. En el lado del cliente, añada sec=krb5 (o sec=krb5i, o sec=krb5p, dependiendo de la

configuración) a las opciones de montaje:
# mount -o sec=krb5 server:/export /mnt
Si necesita escribir archivos como root en el recurso compartido NFS protegido por Kerberos y
mantener la propiedad de root sobre estos archivos, consulte
https://access.redhat.com/articles/4040141. Tenga en cuenta que esta configuración no se
recomienda.
Para más información sobre la configuración de NFS, consulte las páginas de manual
exports(5) y nfs(5).
5.4. OPCIONES DE SEGURIDAD DE NFSV4

NFSv4 incluye soporte ACL basado en el modelo de Microsoft Windows NT, no en el modelo POSIX,
debido a las características del modelo de Microsoft Windows NT y a su amplia implantación.
Otra característica de seguridad importante de NFSv4 es la eliminación del uso del protocolo MOUNT
para montar sistemas de archivos. El protocolo MOUNT presentaba un riesgo de seguridad debido a la
forma en que el protocolo procesaba los manejadores de archivos.
121
5.5. PERMISOS DE ARCHIVOS EN EXPORTACIONES NFS MONTADAS

Una vez que el sistema de archivos NFS es montado como lectura o lectura y escritura por un host
remoto, la única protección que tiene cada archivo compartido son sus permisos. Si dos usuarios que
comparten el mismo valor de ID de usuario montan el mismo sistema de archivos NFS en diferentes
sistemas cliente, pueden modificar los archivos del otro. Además, cualquier persona que haya iniciado
sesión como root en el sistema cliente puede utilizar el comando su - para acceder a cualquier archivo
con el recurso compartido NFS.
Por defecto, las listas de control de acceso (ACLs) son soportadas por NFS bajo Red Hat Enterprise
Linux. Red Hat recomienda mantener esta característica habilitada.
Por defecto, NFS utiliza root squashing al exportar un sistema de archivos. Esto establece el ID de
usuario de cualquiera que acceda al recurso compartido NFS como usuario root en su máquina local en
nobody. El aplastamiento de la raíz se controla con la opción por defecto root_squash; para más
información sobre esta opción, consulte Sección 4.6, “Configuración del servidor NFS” .
Al exportar un recurso compartido NFS como de sólo lectura, considere el uso de la opción all_squash.
Esta opción hace que todos los usuarios que accedan al sistema de archivos exportado tomen el ID del
usuario de nobody.
122
CAPÍTULO 6. HABILITACIÓN DE DISPOSICIONES SCSI PNFS EN NFS
CAPÍTULO 6. HABILITACIÓN DE DISPOSICIONES SCSI PNFS

EN NFS
Puede configurar el servidor y el cliente NFS para que utilicen la disposición SCSI pNFS para acceder a
los datos. SCSI pNFS es beneficioso en los casos de uso que implican un acceso de larga duración de un
solo cliente a un archivo.
Requisitos previos
Tanto el cliente como el servidor deben poder enviar comandos SCSI al mismo dispositivo de
bloque. Es decir, el dispositivo de bloque debe estar en un bus SCSI compartido.
El dispositivo de bloque debe contener un sistema de archivos XFS.
El dispositivo SCSI debe ser compatible con las reservas persistentes SCSI, como se describe
en la especificación de comandos primarios SCSI-3.
6.1. LA TECNOLOGÍA PNFS

La arquitectura pNFS mejora la escalabilidad de NFS. Cuando un servidor implementa pNFS, el cliente
puede acceder a los datos a través de varios servidores de forma simultánea. Esto puede suponer una
mejora del rendimiento.
pNFS admite los siguientes protocolos o disposiciones de almacenamiento en RHEL:
Archivos
Flexfiles
SCSI
6.2. DISPOSICIONES SCSI PNFS

El diseño SCSI se basa en el trabajo de los diseños de bloques pNFS. La disposición se define a través
de los dispositivos SCSI. Contiene una serie secuencial de bloques de tamaño fijo como unidades lógicas
(LUs) que deben ser capaces de soportar reservas persistentes SCSI. Los dispositivos LU se identifican
por su identificación de dispositivo SCSI.
pNFS SCSI funciona bien en casos de uso que implican el acceso de un solo cliente de larga duración a
un archivo. Un ejemplo podría ser un servidor de correo o una máquina virtual que albergue un clúster.
Operaciones entre el cliente y el servidor

Cuando un cliente NFS lee de un archivo o escribe en él, el cliente realiza una operación LAYOUTGET.
El servidor responde con la ubicación del archivo en el dispositivo SCSI. Es posible que el cliente tenga
que realizar una operación adicional de GETDEVICEINFO para determinar qué dispositivo SCSI debe
utilizar. Si estas operaciones funcionan correctamente, el cliente puede emitir peticiones de E/S
directamente al dispositivo SCSI en lugar de enviar las operaciones READ y WRITE al servidor.
Los errores o la contención entre clientes pueden hacer que el servidor recupere los diseños o no los
emita a los clientes. En esos casos, los clientes vuelven a emitir READ y WRITE operaciones al servidor
en lugar de enviar solicitudes de E/S directamente al dispositivo SCSI.
Para supervisar las operaciones, consulte Sección 6.7, “Supervisión de la funcionalidad de los diseños
SCSI de PNFS”.
123
Reservas de dispositivos
pNFS SCSI maneja el cercado a través de la asignación de reservas. Antes de que el servidor emita
distribuciones a los clientes, reserva el dispositivo SCSI para garantizar que sólo los clientes registrados
puedan acceder al dispositivo. Si un cliente puede emitir comandos a ese dispositivo SCSI pero no está
registrado en el dispositivo, muchas operaciones del cliente en ese dispositivo fallan. Por ejemplo, el
comando blkid en el cliente falla al mostrar el UUID del sistema de archivos XFS si el servidor no ha
dado una distribución para ese dispositivo al cliente.
El servidor no elimina su propia reserva persistente. Esto protege los datos dentro del sistema de
archivos del dispositivo a través de los reinicios de los clientes y servidores. Para reutilizar el dispositivo
SCSI, es posible que tenga que eliminar manualmente la reserva persistente en el servidor NFS.
6.3. COMPROBACIÓN DE UN DISPOSITIVO SCSI COMPATIBLE CON

PNFS
Este procedimiento comprueba si un dispositivo SCSI es compatible con la disposición SCSI pNFS.
Requisitos previos
Instale el paquete sg3_utils:
# yum install sg3_utils
Procedimiento
Tanto en el servidor como en el cliente, compruebe que el dispositivo SCSI es compatible:
sg_persist --in --report-capabilities --verbose path-to-scsi-device
Asegúrese de que el bit Persist Through Power Loss Active (PTPL_A) está activado.
Ejemplo 6.1. Un dispositivo SCSI compatible con SCSI pNFS
El siguiente es un ejemplo de la salida de sg_persist para un dispositivo SCSI que soporta

pNFS SCSI. El bit PTPL_A informa de 1.
inquiry cdb: 12 00 00 00 24 00
Persistent Reservation In cmd: 5e 02 00 00 00 00 00 20 00 00
LIO-ORG block11 4.0
Peripheral device type: disk
Report capabilities response:
Compatible Reservation Handling(CRH): 1
Specify Initiator Ports Capable(SIP_C): 1
All Target Ports Capable(ATP_C): 1
Persist Through Power Loss Capable(PTPL_C): 1
Type Mask Valid(TMV): 1
Allow Commands: 1
Persist Through Power Loss Active(PTPL_A): 1
Support indicated in Type mask:
Write Exclusive, all registrants: 1
Exclusive Access, registrants only: 1
Write Exclusive, registrants only: 1
124
Exclusive Access: 1
Write Exclusive: 1
Exclusive Access, all registrants: 1
La página de manual sg_persist(8)
6.4. CONFIGURACIÓN DE PNFS SCSI EN EL SERVIDOR

Este procedimiento configura un servidor NFS para exportar una disposición SCSI pNFS.
Procedimiento
1. En el servidor, monte el sistema de archivos XFS creado en el dispositivo SCSI.
2. Configure el servidor NFS para exportar la versión 4.1 o superior de NFS. Establezca la siguiente
opción en la sección [nfsd] del archivo /etc/nfs.conf:
[nfsd]
vers4.1=y
3. Configure el servidor NFS para exportar el sistema de archivos XFS a través de NFS con la
opción pnfs:
Ejemplo 6.2. Una entrada en /etc/exports para exportar pNFS SCSI
La siguiente entrada en el archivo de configuración /etc/exports exporta el sistema de

archivos montado en /exported/directory/ al cliente allowed.example.com como una
disposición SCSI pNFS:
/exportado/directorio permitido.ejemplo.com(pnfs)
Para más información sobre la configuración de un servidor NFS, consulte Capítulo 4,

Exportación de recursos compartidos NFS.
6.5. CONFIGURACIÓN DE PNFS SCSI EN EL CLIENTE

Este procedimiento configura un cliente NFS para montar una disposición SCSI pNFS.
Requisitos previos
El servidor NFS está configurado para exportar un sistema de archivos XFS sobre SCSI pNFS.
Véase Sección 6.4, “Configuración de pNFS SCSI en el servidor” .
Procedimiento
En el cliente, monte el sistema de archivos XFS exportado utilizando la versión 4.1 o superior de
125
En el cliente, monte el sistema de archivos XFS exportado utilizando la versión 4.1 o superior de
NFS:
# mount -t nfs -o nfsvers=4.1 host:/remote/export /local/directory
No monte el sistema de archivos XFS directamente sin NFS.
Para obtener más información sobre el montaje de recursos compartidos NFS, consulte
Montaje de recursos compartidos NFS .
6.6. LIBERACIÓN DE LA RESERVA SCSI PNFS EN EL SERVIDOR

Este procedimiento libera la reserva persistente que un servidor NFS mantiene en un dispositivo SCSI.
Esto le permite reutilizar el dispositivo SCSI cuando ya no necesite exportar pNFS SCSI.
Debe eliminar la reserva del servidor. No se puede eliminar de otro IT Nexus.
Requisitos previos
Instale el paquete sg3_utils:
# yum install sg3_utils
Procedimiento
1. Consultar una reserva existente en el servidor:
# sg_persist --read-reservation path-to-scsi-device
Ejemplo 6.3. Consulta de una reserva en /dev/sda
# sg_persist --read-reservation /dev/sda
LIO-ORG block_1 4.0

PR generation=0x8, Reservation follows:
Key=0x100000000000000
scope: LU_SCOPE, type: Exclusive Access, registrants only
2. Eliminar el registro existente en el servidor:
# sg_persist --out \
--release \
--param-rk=reservation-key \
--prout-type=6 \
path-to-scsi-device
Ejemplo 6.4. Eliminación de una reserva en /dev/sda
126
# sg_persist --out \
--release \
--param-rk=0x100000000000000 \
--prout-type=6 \
/dev/sda
LIO-ORG block_1 4.0

La página de manual sg_persist(8)
6.7. SUPERVISIÓN DE LA FUNCIONALIDAD DE LOS DISEÑOS SCSI DE

PNFS
Puede supervisar si el cliente y el servidor pNFS intercambian operaciones SCSI pNFS adecuadas o si
recurren a operaciones NFS normales.
Requisitos previos
Un cliente y un servidor SCSI pNFS están configurados.
6.7.1. Comprobación de las operaciones SCSI pNFS desde el servidor mediante

nfsstat
Este procedimiento utiliza la utilidad nfsstat para supervisar las operaciones SCSI de pNFS desde el
servidor.
Procedimiento
1. Supervisar las operaciones atendidas desde el servidor:
# watch --differences \
"nfsstat --server | egrep --after-context=1 read\|write\|layout"
Every 2.0s: nfsstat --server | egrep --after-context=1 read\|write\|layout
putrootfh read readdir readlink remove rename

2 0% 0 0% 1 0% 0 0% 0 0% 0 0%
--
setcltidconf verify write rellockowner bc_ctl bind_conn
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
--
getdevlist layoutcommit layoutget layoutreturn secinfononam sequence
0 0% 29 1% 49 1% 5 0% 0 0% 2435 86%
2. El cliente y el servidor utilizan operaciones SCSI pNFS cuando:
Los contadores layoutget, layoutreturn, y layoutcommit se incrementan. Esto significa

que el servidor está sirviendo diseños.
Los contadores del servidor read y write no se incrementan. Esto significa que los clientes
127
Los contadores del servidor read y write no se incrementan. Esto significa que los clientes
están realizando peticiones de E/S directamente a los dispositivos SCSI.
6.7.2. Comprobación de las operaciones SCSI de pNFS desde el cliente mediante

mountstats
Este procedimiento utiliza el archivo /proc/self/mountstats para supervisar las operaciones SCSI de
pNFS desde el cliente.
Procedimiento
1. Enumerar los contadores de operaciones por monte:
# cat /proc/self/mountstats \
| awk /scsi_lun_0/,/^$/ \
| egrep device\|READ\|WRITE\|LAYOUT
device 192.168.122.73:/exports/scsi_lun_0 mounted on /mnt/rhel7/scsi_lun_0 with fstype

nfs4 statvers=1.1
nfsv4:
bm0=0xfdffbfff,bm1=0x40f9be3e,bm2=0x803,acl=0x3,sessions,pnfs=LAYOUT_SCSI
READ: 0 0 0 0 0 0 0 0
WRITE: 0 0 0 0 0 0 0 0
READLINK: 0 0 0 0 0 0 0 0
READDIR: 0 0 0 0 0 0 0 0
LAYOUTGET: 49 49 0 11172 9604 2 19448 19454
LAYOUTCOMMIT: 28 28 0 7776 4808 0 24719 24722
LAYOUTRETURN: 0 0 0 0 0 0 0 0
LAYOUTSTATS: 0 0 0 0 0 0 0 0
2. En los resultados:
Las estadísticas de LAYOUT indican las peticiones en las que el cliente y el servidor utilizan
operaciones SCSI pNFS.
Las estadísticas READ y WRITE indican las solicitudes en las que el cliente y el servidor
vuelven a las operaciones NFS.
128
CAPÍTULO 7. CONFIGURACIÓN DEL SERVIDOR PROXY DE CACHÉ SQUID
CAPÍTULO 7. CONFIGURACIÓN DEL SERVIDOR PROXY DE

CACHÉ SQUID
Squid es un servidor proxy que almacena en caché el contenido para reducir el ancho de banda y cargar
las páginas web más rápidamente. Este capítulo describe cómo configurar Squid como proxy para el
protocolo HTTP, HTTPS y FTP, así como la autenticación y la restricción de acceso.
7.1. CONFIGURACIÓN DE SQUID COMO PROXY DE CACHÉ SIN

AUTENTICACIÓN
Esta sección describe una configuración básica de Squid como proxy de caché sin autenticación. El
procedimiento limita el acceso al proxy basándose en rangos de IP.
Requisitos previos
El procedimiento asume que el archivo /etc/squid/squid.conf es el proporcionado por el

paquete squid. Si ha editado este archivo anteriormente, elimine el archivo y vuelva a instalar el
paquete.
Procedimiento
1. Instale el paquete squid:
# yum install squid
2. Edite el archivo /etc/squid/squid.conf:
a. Adapte las listas de control de acceso (ACL) de localnet para que coincidan con los rangos
de IP a los que se debe permitir el uso del proxy:
acl localnet src 192.0.2.0/24

acl localnet 2001:db8:1::/64
Por defecto, el archivo /etc/squid/squid.conf contiene la regla http_access allow

localnet que permite utilizar el proxy desde todos los rangos de IP especificados en las
ACLs localnet. Tenga en cuenta que debe especificar todas las ACL de localnet antes de
la regla de http_access allow localnet.
IMPORTANTE
Elimine todas las entradas existentes en acl localnet que no coincidan con
su entorno.
b. La siguiente ACL existe en la configuración por defecto y define 443 como un puerto que
utiliza el protocolo HTTPS:
acl puertos_SSL puerto 443
Si los usuarios deben poder utilizar el protocolo HTTPS también en otros puertos, añada
una ACL para cada uno de estos puertos:
acl Puerto SSL port_number
129
c. Actualice la lista de reglas de acl Safe_ports para configurar a qué puertos puede
establecer una conexión Squid. Por ejemplo, para configurar que los clientes que utilicen el
proxy sólo puedan acceder a los recursos del puerto 21 (FTP), 80 (HTTP) y 443 (HTTPS),
mantenga sólo las siguientes declaraciones de acl Safe_ports en la configuración:
acl Safe_ports port 21

Por defecto, la configuración contiene la regla http_access deny !Safe_ports que define
la denegación de acceso a los puertos que no están definidos en las ACL de Safe_ports.
d. Configure el tipo de caché, la ruta del directorio de la caché, el tamaño de la caché y otros
ajustes específicos del tipo de caché en el parámetro cache_dir:
cache_dir ufs /var/spool/squid 10000 16 256
Con estos ajustes:
Squid utiliza el tipo de caché ufs.
Squid almacena su caché en el directorio /var/spool/squid/.
El caché crece hasta 10000 MB.
Squid crea 16 subdirectorios de nivel 1 en el directorio /var/spool/squid/.
Squid crea subdirectorios 256 en cada directorio de nivel 1.

Si no se establece una directiva cache_dir, Squid almacena la caché en la memoria.
3. Si establece un directorio de caché diferente a /var/spool/squid/ en el parámetro cache_dir:
a. Crear el directorio de la caché:
# mkdir -p path_to_cache_directory
b. Configure los permisos para el directorio de la caché:
# chown squid:squid path_to_cache_directory
c. Si ejecuta SELinux en modo enforcing, establezca el contexto squid_cache_t para el

directorio de la caché:
# semanage fcontext -a -t squid_cache_t "path_to_cache_directory(/.*)?"

# restorecon -Rv path_to_cache_directory
Si la utilidad semanage no está disponible en su sistema, instale el paquete

policycoreutils-python-utils.
4. Abra el puerto 3128 en el cortafuegos:

5. Habilite e inicie el servicio squid:
130
# systemctl enable --now squid
Para comprobar que el proxy funciona correctamente, descargue una página web utilizando la utilidad
curl:
# curl -O -L "https://www.redhat.com/index.html" -x "proxy.example.com:3128"
Si curl no muestra ningún error y el archivo index.html se ha descargado en el directorio actual, el proxy
funciona.
7.2. CONFIGURACIÓN DE SQUID COMO PROXY DE CACHÉ CON

AUTENTICACIÓN LDAP
Esta sección describe una configuración básica de Squid como proxy de caché que utiliza LDAP para
autenticar a los usuarios. El procedimiento configura que sólo los usuarios autenticados puedan utilizar el
proxy.
Requisitos previos

paquete.
Un usuario de servicio, como uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com

existe en el directorio LDAP. Squid utiliza esta cuenta sólo para buscar al usuario autentificador.
Si el usuario de autenticación existe, Squid se vincula como este usuario al directorio para
verificar la autenticación.
Procedimiento
1. Instale el paquete squid:
# yum install squid
a. Para configurar la utilidad de ayuda basic_ldap_auth, añada la siguiente entrada de

configuración en la parte superior de /etc/squid/squid.conf:
auth_param programa básico /usr/lib64/squid/basic_ldap_auth -b

"cn=users,cn=accounts,dc=example,dc=com" -D
"uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com" -W
/etc/squid/ldap_password -f "(&(objectClass=person)(uid=%s))" -ZZ -H
ldap://ldap_server.example.com:389
A continuación se describen los parámetros pasados a la utilidad de ayuda

basic_ldap_auth en el ejemplo anterior:
-B base_DN establece la base de búsqueda LDAP.
-D proxy_service_user_DN establece el nombre distinguido (DN) de la cuenta que

Squid utiliza para buscar al usuario autentificado en el directorio.
-W path_to_password_file establece la ruta del archivo que contiene la contraseña del
131
-W path_to_password_file establece la ruta del archivo que contiene la contraseña del

usuario del servicio proxy. El uso de un archivo de contraseña evita que la contraseña
sea visible en la lista de procesos del sistema operativo.
-f LDAP_filter especifica el filtro de búsqueda LDAP. Squid sustituye la variable %s por

el nombre de usuario proporcionado por el usuario autentificador.
El filtro (&(objectClass=person)(uid=%s)) del ejemplo define que el nombre de
usuario debe coincidir con el valor establecido en el atributo uid y que la entrada del
directorio contiene la clase de objeto person.
-ZZ impone una conexión cifrada por TLS sobre el protocolo LDAP mediante el
comando STARTTLS. Omita el -ZZ en las siguientes situaciones:
El servidor LDAP no admite conexiones cifradas.
El puerto especificado en la URL utiliza el protocolo LDAPS.
El parámetro -H LDAP_URL especifica el protocolo, el nombre del host o la dirección IP

y el puerto del servidor LDAP en formato URL.
b. Añade la siguiente ACL y regla para configurar que Squid sólo permita a los usuarios
autentificados utilizar el proxy:
acl ldap-auth proxy_auth REQUIRED

http_access allow ldap-auth
IMPORTANTE
Especifique estos ajustes antes de la regla http_access deny all.
c. Elimine la siguiente regla para desactivar la omisión de la autenticación del proxy desde los
rangos de IP especificados en las ACL de localnet:
http_access allow localnet
d. La siguiente ACL existe en la configuración por defecto y define 443 como un puerto que
acl puerto_SSL número_de_puerto
e. Actualice la lista de reglas de acl Safe_ports para configurar a qué puertos puede

132
la denegación de acceso a los puertos que no están definidos en Safe_ports ACLs.
f. Configure el tipo de caché, la ruta del directorio de la caché, el tamaño de la caché y otros
Con estos ajustes:




4. Guarde la contraseña del usuario del servicio LDAP en el archivo /etc/squid/ldap_password, y

establezca los permisos adecuados para el archivo:
# echo "password" > /etc/squid/ldap_password

# chown root:squid /etc/squid/ldap_password
# chmod 640 /etc/squid/ldap_password

133
curl:
# curl -O -L "https://www.redhat.com/index.html" -x
"user_name:password@proxy.example.com:3128"
Si curl no muestra ningún error y el archivo index.html se ha descargado en el directorio actual, el proxy
funciona.
Pasos para la resolución de problemas

Para verificar que la utilidad de ayuda funciona correctamente:
1. Inicie manualmente la utilidad de ayuda con la misma configuración que utilizó en el parámetro
auth_param:
# /usr/lib64/squid/basic_ldap_auth -b "cn=users,cn=accounts,dc=example,dc=com" -D
"uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com" -W /etc/squid/ldap_password -
f "(&(objectClass=person)(uid=%s))" -ZZ -H ldap://ldap_server.example.com:389
2. Introduzca un nombre de usuario y una contraseña válidos, y pulse Intro:
user_name password
Si la utilidad de ayuda devuelve OK, la autenticación tuvo éxito.
7.3. CONFIGURACIÓN DE SQUID COMO PROXY DE CACHÉ CON

AUTENTICACIÓN KERBEROS
Esta sección describe una configuración básica de Squid como proxy de caché que autentifica a los
usuarios en un Directorio Activo (AD) utilizando Kerberos. El procedimiento configura que sólo los
usuarios autenticados pueden utilizar el proxy.
Requisitos previos

paquete.
El servidor en el que desea instalar Squid es un miembro del dominio AD. Para más detalles,
consulte Configuración de Samba como miembro del dominio en la documentación de Red Hat
Enterprise Linux 8 Deploying different types of servers.
Procedimiento
1. Instale los siguientes paquetes:
yum install squid krb5-workstation
2. Autenticarse como administrador del dominio AD:
134
# kinit administrator@AD.EXAMPLE.COM
3. Cree un keytab para Squid y almacénelo en el archivo /etc/squid/HTTP.keytab:
# export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab
# net ads keytab CREATE -U administrator
4. Añade la entidad de crédito del servicio HTTP al keytab:
# net ads keytab ADD HTTP -U administrador
5. Establezca el propietario del archivo keytab al usuario squid:
# chown squid /etc/squid/HTTP.keytab
6. Opcionalmente, verifique que el archivo keytab contiene el principal de servicio HTTP para el
nombre de dominio completamente calificado (FQDN) del servidor proxy:
# klist -k /etc/squid/HTTP.keytab
Keytab name: FILE:/etc/squid/HTTP.keytab
KVNO Principal
---- ---------------------------------------------------
...
2 HTTP/proxy.ad.example.com@AD.EXAMPLE.COM
...
a. Para configurar la utilidad de ayuda negotiate_kerberos_auth, añada la siguiente entrada

de configuración en la parte superior de /etc/squid/squid.conf:
auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k

/etc/squid/HTTP.keytab -s HTTP/proxy.ad.example.com@AD.EXAMPLE.COM
A continuación se describen los parámetros pasados a la utilidad de ayuda

negotiate_kerberos_auth en el ejemplo anterior:
-k file establece la ruta de acceso al archivo de tabulación de claves. Tenga en cuenta

que el usuario squid debe tener permisos de lectura en este archivo.
-s HTTP/host_name@kerberos_realm establece el principal de Kerberos que utiliza

Squid.
Opcionalmente, puede activar el registro pasando uno o ambos de los siguientes
parámetros a la utilidad de ayuda:
-i registra mensajes informativos, como el usuario que se autentifica.
-d activa el registro de depuración.

Squid registra la información de depuración de la utilidad de ayuda en el archivo
/var/log/squid/cache.log.
b. Añade la siguiente ACL y regla para configurar que Squid sólo permita a los usuarios
autentificados utilizar el proxy:
135
acl kerb-auth proxy_auth REQUIRED

http_access allow kerb-auth
IMPORTANTE
Especifique estos ajustes antes de la regla http_access deny all.
c. Elimine la siguiente regla para desactivar la omisión de la autenticación del proxy desde los
rangos de IP especificados en las ACL de localnet:
http_access allow localnet
d. La siguiente ACL existe en la configuración por defecto y define 443 como un puerto que
acl Puerto SSL port_number
e. Actualice la lista de reglas de acl Safe_ports para configurar a qué puertos puede

la denegación de acceso a los puertos que no están definidos en las ACL de Safe_ports.
f. Configure el tipo de caché, la ruta del directorio de la caché, el tamaño de la caché y otros
Con estos ajustes:

136




curl:
# curl -O -L "https://www.redhat.com/index.html" --proxy-negotiate -u : -x

"proxy.ad.example.com:3128"
Si curl no muestra ningún error y el archivo index.html existe en el directorio actual, el proxy funciona.
Pasos para la resolución de problemas

Para probar manualmente la autenticación Kerberos:
1. Obtenga un ticket Kerberos para la cuenta AD:
# kinit user@AD.EXAMPLE.COM
2. Opcionalmente, mostrar el billete:
# klist
3. Utilice la utilidad negotiate_kerberos_auth_test para probar la autenticación:
# /usr/lib64/squid/negotiate_kerberos_auth_test proxy.ad.example.com
Si la utilidad de ayuda devuelve un token, la autenticación tuvo éxito:
137
Ficha: YIIFTAYGKwYBBQUCoIIFqDC...
7.4. CONFIGURACIÓN DE UNA LISTA DE DENEGACIÓN DE DOMINIO

EN SQUID
Con frecuencia, los administradores quieren bloquear el acceso a dominios específicos. Esta sección
describe cómo configurar una lista de denegación de dominio en Squid.
Requisitos previos
Squid está configurado y los usuarios pueden utilizar el proxy.
Procedimiento
1. Edite el archivo /etc/squid/squid.conf y añada la siguiente configuración:
acl domain_deny_list dstdomain "/etc/squid/domain_deny_list.txt"

http_access deny all domain_deny_list
IMPORTANTE
Añada estas entradas antes de la primera declaración http_access allow que

permite el acceso a los usuarios o clientes.
2. Cree el archivo /etc/squid/domain_deny_list.txt y añada los dominios que desea bloquear. Por
ejemplo, para bloquear el acceso a example.com incluyendo subdominios y para bloquear
example.net, añada:
.example.com
example.net
IMPORTANTE
Si ha hecho referencia al archivo /etc/squid/domain_deny_list.txt en la

configuración de Squid, este archivo no debe estar vacío. Si el archivo está vacío,
Squid falla al iniciarse.
3. Reinicie el servicio squid:
# systemctl restart squid
7.5. CONFIGURAR EL SERVICIO SQUID PARA QUE ESCUCHE EN UN

PUERTO O DIRECCIÓN IP ESPECÍFICOS
Por defecto, el servicio proxy Squid escucha en el puerto 3128 en todas las interfaces de red. Esta
sección describe cómo cambiar el puerto y configurar Squid para que escuche en una dirección IP
específica.
Requisitos previos
138
El paquete squid está instalado.
Procedimiento
Para establecer el puerto en el que escucha el servicio Squid, establezca el número de

puerto en el parámetro http_port. Por ejemplo, para establecer el puerto en 8080,
establezca:
puerto_http 8080
Para configurar en qué dirección IP escucha el servicio Squid, establezca la dirección IP y el

número de puerto en el parámetro http_port. Por ejemplo, para configurar que Squid
escuche sólo en la dirección IP 192.0.2.1 en el puerto 3128, establezca:
puerto_http 192.0.2.1:3128
Añade múltiples parámetros de http_port al archivo de configuración para configurar que

Squid escuche en múltiples puertos y direcciones IP:
http_port 192.0.2.1:3128
http_port 192.0.2.1:8080
2. Si ha configurado que Squid utilice un puerto diferente al predeterminado (3128):
a. Abre el puerto en el firewall:
# firewall-cmd --permanent --add-port=port_number/tcp

b. Si ejecuta SELinux en modo de aplicación, asigne el puerto a la definición del tipo de puerto
squid_port_t:
# semanage port -a -t squid_port_t -p tcp port_number

3. Reinicie el servicio squid:
# systemctl restart squid

Consulte el archivo usr/share/doc/squid-<version>/squid.conf.documented para obtener una
lista de todos los parámetros de configuración que puede establecer en el archivo
/etc/squid/squid.conf junto con una descripción detallada.
139
CAPÍTULO 8. SERVIDORES DE BASES DE DATOS
8.1. INTRODUCCIÓN A LOS SERVIDORES DE BASES DE DATOS

Un servidor de base de datos es un dispositivo de hardware que tiene una cierta cantidad de memoria
principal, y una aplicación de base de datos (DB) instalada. Esta aplicación de base de datos proporciona
servicios como medio para escribir los datos almacenados en la memoria principal, que suele ser
pequeña y costosa, en archivos de base de datos (DB). Estos servicios se prestan a múltiples clientes en
una red. Puede haber tantos servidores de BD como lo permita la memoria principal y el
almacenamiento de una máquina.
Red Hat Enterprise Linux 8 proporciona las siguientes aplicaciones de bases de datos:
MariaDB 10.3
MySQL 8.0
PostgreSQL 10
PostgreSQL 9.6
PostgreSQL 12 - disponible desde RHEL 8.1.1
8.2. USO DE MARIADB
8.2.1. Introducción a MariaDB

El servidor MariaDB es un servidor de bases de datos de código abierto rápido y robusto que se basa en
la tecnología MySQL.
MariaDB es una base de datos relacional que convierte los datos en información estructurada y
proporciona una interfaz SQL para acceder a los datos. Incluye múltiples motores de almacenamiento y
complementos, así como funciones de sistema de información geográfica (GIS) y de notación de
objetos de JavaScript (JSON).
Esta sección describe cómo instalar el servidor MariaDB en Instalación de MariaDB o cómo migrar
desde la versión por defecto de Red Hat Enterprise Linux 7, MariaDB 5.5, a la versión por defecto de
Red Hat Enterprise Linux 8, MariaDB 10.3, en Migración a MariaDB 10.3, y también cómo hacer una
copia de seguridad de los datos de MariaDB. Realizar una copia de seguridad de los datos es uno de los
prerrequisitos para la migración de MariaDB.
8.2.2. Instalación de MariaDB

Para instalar MariaDB, siga este procedimiento:
1. Asegúrese de que todos los paquetes necesarios para el servidor MariaDB están disponibles en
el sistema mediante la instalación del módulo mariadb utilizando un flujo específico:
# yum module install mariadb:10.3/server
2. Inicie el servicio mariadb:
# systemctl start mariadb.service
140
3. Habilitar el servicio mariadb para que se inicie en el arranque:
# systemctl enable mariadb.service
NOTA
Tenga en cuenta que los servidores de bases de datos MariaDB y MySQL no pueden
instalarse en paralelo en Red Hat Enterprise Linux 8.0 debido a que los paquetes RPM
entran en conflicto. La instalación paralela de componentes es posible en Red Hat
Software Collections para Red Hat Enterprise Linux 6 y Red Hat Enterprise Linux 7. En
Red Hat Enterprise Linux 8, se pueden utilizar diferentes versiones de servidores de
bases de datos en contenedores.
8.2.2.1. Mejora de la seguridad de la instalación de MariaDB
Para mejorar la seguridad al instalar MariaDB, ejecute el siguiente comando.
El comando lanza un script totalmente interactivo, que solicita cada paso del proceso.
# mysql_secure_installation
El script permite mejorar la seguridad de las siguientes maneras:
Establecer una contraseña para las cuentas root
Eliminación de usuarios anónimos
No permitir los inicios de sesión remotos (fuera del host local) de root
8.2.3. Configuración de MariaDB
8.2.3.1. Configurar el servidor MariaDB para la red
Para configurar el servidor MariaDB para su conexión en red, utilice la sección [mysqld] del archivo
/etc/my.cnf.d/mariadb-server.cnf, donde puede establecer las siguientes directivas de configuración:
bind-address
Bind-address es la dirección en la que escuchará el servidor.
Las opciones posibles son: un nombre de host, una dirección IPv4 o una dirección IPv6.
skip-networking
Los valores posibles son:
0 - para escuchar a todos los clientes
1 - para escuchar sólo a los clientes locales
port
El puerto en el que MariaDB escucha las conexiones TCP/IP.
8.2.4. Copia de seguridad de los datos de MariaDB

Hay dos formas principales de hacer una copia de seguridad de los datos de una base de datos MariaDB:
141
Copia de seguridad lógica
Copia de seguridad física
Logical backup consiste en las sentencias SQL necesarias para restaurar los datos. Este tipo de copia
de seguridad exporta la información y los registros en archivos de texto plano.
La principal ventaja de la copia de seguridad lógica sobre la física es la portabilidad y la flexibilidad. Los
datos se pueden restaurar en otras configuraciones de hardware, versiones de MariaDB o sistema de
gestión de bases de datos (DBMS), lo que no es posible con las copias de seguridad físicas.
Tenga en cuenta que la copia de seguridad lógica se puede realizar si el mariadb.service está en
funcionamiento. La copia de seguridad lógica no incluye los archivos de registro y configuración.
Physical backup consiste en copias de archivos y directorios que almacenan el contenido.
La copia de seguridad física tiene las siguientes ventajas en comparación con la copia de seguridad
lógica:
La salida es más compacta.
La copia de seguridad es de menor tamaño.
La copia de seguridad y la restauración son más rápidas.
La copia de seguridad incluye archivos de registro y de configuración.
Tenga en cuenta que la copia de seguridad física debe realizarse cuando el mariadb.service no está en
funcionamiento o todas las tablas de la base de datos están bloqueadas para evitar cambios durante la
copia de seguridad.
Puede utilizar uno de los siguientes enfoques de copia de seguridad de MariaDB para hacer una copia
de seguridad de los datos de una base de datos MariaDB:
Copia de seguridad lógica con mysqldump
Copia de seguridad física en línea con la herramienta Mariabackup
Copia de seguridad del sistema de archivos
La replicación como solución de copia de seguridad
8.2.4.1. Realizando una copia de seguridad lógica con mysqldump
El cliente mysqldump es una utilidad de copia de seguridad, que puede utilizarse para volcar una base
de datos o una colección de bases de datos con el fin de realizar una copia de seguridad o transferirla a
otro servidor de bases de datos. La salida de mysqldump suele consistir en sentencias SQL para recrear
la estructura de las tablas del servidor, rellenarlas con datos, o ambas cosas. Como alternativa,
mysqldump también puede generar archivos en otros formatos, incluyendo CSV u otros formatos de
texto delimitados, y XML.
Para realizar la mysqldump copia de seguridad, puede utilizar una de las siguientes opciones:
Copia de seguridad de una base de datos seleccionada
Copia de seguridad de un subconjunto de tablas de una base de datos
142
Copia de seguridad de varias bases de datos
Haga una copia de seguridad de todas las bases de datos
8.2.4.1.1. Copia de seguridad de una base de datos completa con mysqldump
Procedimiento
Para hacer una copia de seguridad de una base de datos completa, ejecute
# mysqldump [options] db_name > backup-file.sql
8.2.4.1.2. Uso de mysqldump para hacer una copia de seguridad de un conjunto de tablas de una
base de datos
Procedimiento
Para hacer una copia de seguridad de un subconjunto de tablas de una base de datos, añada una
lista de las tablas elegidas al final del comando mysqldump:
# mysqldump [opciones] db_name [tbl_name ...]
8.2.4.1.3. Usando mysqldump para cargar el archivo de volcado de nuevo en un servidor
Procedimiento
Para cargar el archivo de volcado de nuevo en un servidor, utilice cualquiera de estas opciones:
# mysql db_name < backup-file.sql
# mysql -e \ "source /path-to-backup/backup-file.sql" db_name
8.2.4.1.4. Usando mysqldump para copiar datos entre dos bases de datos
Procedimiento
Para rellenar las bases de datos copiando los datos de un servidor MariaDB a otro, ejecute
# mysqldump --opt db_name | mysql --host=remote_host -C db_name
8.2.4.1.5. Volcado de múltiples bases de datos con mysqldump
Procedimiento
Para volcar varias bases de datos a la vez, ejecute
# mysqldump [opciones] --bases de datos db_nombre1 [db_nombre2 ...] >

mis_bases_de_datos.sql
8.2.4.1.6. Volcado de todas las bases de datos con mysqldump
143
Procedimiento
Para volcar todas las bases de datos, ejecute
# mysqldump [options] --all-databases > all_databases.sql
8.2.4.1.7. Revisando las opciones de mysqldump
Procedimiento
Para ver una lista de las opciones que soporta mysqldump, ejecute
$ mysqldump --help
8.2.4.1.8. Recursos adicionales
Para más información sobre la copia de seguridad lógica con mysqldumpconsulte la documentación de
MariaDB.
8.2.4.2. Realización de una copia de seguridad física en línea con la herramienta

Mariabackup
Mariabackup es una herramienta basada en la tecnología Percona XtraBackup, que permite realizar
copias de seguridad físicas en línea de tablas InnoDB, Aria y MyISAM.
Mariabackup, proporcionado por el paquete mariadb-backup del repositorio de AppStream, admite la

capacidad de realizar copias de seguridad completas para el servidor MariaDB, que incluye datos
cifrados y comprimidos.
Requisitos previos
El paquete mariadb-backup está instalado en el sistema:
# yum install mariadb-backup
Mariabackup necesita que se le proporcionen las credenciales del usuario con el que se
ejecutará la copia de seguridad. Puede proporcionar las credenciales en la línea de comandos,
como se muestra en el procedimiento, o mediante un archivo de configuración antes de aplicar
el procedimiento. Para establecer las credenciales utilizando el archivo de configuración,
primero cree el archivo (por ejemplo, /etc/my.cnf.d/mariabackup.cnf), y luego añada las
siguientes líneas en la sección [xtrabackup] o [mysqld] del nuevo archivo:
[xtrabackup]
user=myuser
password=mypassword
IMPORTANTE
144
IMPORTANTE
Mariabackup no lee las opciones de la sección [mariadb] de los archivos de

configuración. Si se especifica un directorio de datos no predeterminado en un
servidor MariaDB, debe especificar este directorio en las secciones
[xtrabackup] o [mysqld] de los archivos de configuración, para que
Mariabackup sea capaz de encontrar el directorio de datos.
Para especificar dicho directorio de datos, incluya la siguiente línea en las

secciones [xtrabackup] o [mysqld] de los archivos de configuración de
MariaDB:
datadir=/var/miadatadir
NOTA
Los usuarios de Mariabackup deben tener los privilegios RELOAD, LOCK

TABLES, y REPLICATION CLIENT para poder trabajar con la copia de
seguridad.
Para crear una copia de seguridad de una base de datos con Mariabackuputilice el siguiente
procedimiento:
Procedimiento
Ejecute el siguiente comando:
$ mariabackup --backup --target-dir <backup_directory> --user <backup_user> --password

<backup_passwd>
La opción target-dir define el directorio donde se almacenan los archivos de la copia de

seguridad. Si desea realizar una copia de seguridad completa, el directorio de destino debe estar
vacío o no existir.
Las opciones user y password permiten configurar el nombre de usuario y la contraseña. No

utilice estas opciones si ya ha configurado el nombre de usuario y la contraseña en el archivo de
configuración como se describe en los requisitos previos.
Para más información sobre cómo realizar copias de seguridad con Mariabackupvea Copia de
seguridad completa y restauración con Mariabackup.
8.2.4.3. Restauración de datos con la herramienta Mariabackup
Una vez finalizada la copia de seguridad, puedes restaurar los datos de la misma utilizando el comando
mariabackup con una de las siguientes opciones:
--copy-back
--move-back
La opción --copy-back permite mantener los archivos originales de la copia de seguridad. La opción --
move-back mueve los archivos de copia de seguridad al directorio de datos, y elimina los archivos de
copia de seguridad originales.
145
Requisitos previos
Asegúrese de que el servicio mariadb no está funcionando:
# systemctl stop mariadb.service
Asegúrese de que el directorio de datos está vacío.
8.2.4.3.1. Restauración de datos con Mariabackup conservando los archivos de copia de seguridad
Para restaurar los datos manteniendo los archivos originales de la copia de seguridad, utilice el siguiente
procedimiento.
Procedimiento
1. Ejecute el comando mariabackup con la opción --copy-back:
$ mariabackup --copy-back --target-dir=/var/mariadb/backup/
2. Arregla los permisos de los archivos.

Al restaurar una base de datos, Mariabackup conserva los privilegios de archivo y directorio de
la copia de seguridad. Sin embargo, Mariabackup escribe los archivos en el disco como el
usuario y el grupo que restaura la base de datos. En consecuencia, después de restaurar una
copia de seguridad, es posible que tenga que ajustar el propietario del directorio de datos para
que coincida con el usuario y el grupo del servidor MariaDB, normalmente mysql para ambos.
Por ejemplo, para cambiar recursivamente la propiedad de los archivos al usuario y grupo
mysql:
# chown -R mysql:mysql /var/lib/mysql/
8.2.4.3.2. Restauración de datos con Mariabackup mientras se eliminan los archivos de copia de
seguridad
Para restaurar los datos, y no conservar los archivos originales de la copia de seguridad, utilice el
siguiente procedimiento.
Procedimiento
1. Ejecute el comando mariabackup con la opción --move-back:
$ mariabackup --move-back --target-dir=/var/mariadb/backup/
2. Arregla los permisos de los archivos.

Al restaurar una base de datos, Mariabackup conserva los privilegios de archivo y directorio de
la copia de seguridad. Sin embargo, Mariabackup escribe los archivos en el disco como el
usuario y el grupo que restaura la base de datos. En consecuencia, después de restaurar una
copia de seguridad, es posible que tenga que ajustar el propietario del directorio de datos para
que coincida con el usuario y el grupo del servidor MariaDB, normalmente mysql para ambos.
146
Por ejemplo, para cambiar recursivamente la propiedad de los archivos al usuario y grupo
mysql:
# chown -R mysql:mysql /var/lib/mysql/
Para más información, consulte Copia de seguridad y restauración completa con Mariabackup .
8.2.4.4. Realizar una copia de seguridad del sistema de archivos
Para crear una copia de seguridad del sistema de archivos de MariaDB, cambie al usuario root y copie el
contenido del directorio de datos MariaDB a la ubicación de la copia de seguridad.
Para hacer una copia de seguridad también de la configuración actual o de los archivos de registro,
utilice los pasos opcionales del siguiente procedimiento.
Procedimiento
1. Detenga el servicio mariadb:
2. Copie los archivos de datos en la ubicación requerida:
# cp -r /var/lib/mysql /ubicación de la copia de seguridad
3. Opcionalmente, copie los archivos de configuración en la ubicación requerida:
# cp -r /etc/mi.cnf /etc/mi.cnf.d /backup-location/configuration
4. Opcionalmente, copie los archivos de registro en la ubicación requerida:
# cp /var/log/mariadb/* /backup-location/logs
8.2.4.5. Introducción a la replicación como solución de copia de seguridad
La replicación es una solución de copia de seguridad alternativa para los servidores maestros. Si un
servidor maestro se replica a un servidor esclavo, las copias de seguridad pueden ejecutarse en el
esclavo sin ningún impacto en el maestro. El maestro puede seguir funcionando mientras se apaga el
esclavo y se hace una copia de seguridad de los datos desde él.
147

AVISO
La replicación en sí misma no es una solución de copia de seguridad suficiente. La

replicación protege a los servidores maestros contra los fallos de hardware, pero no
garantiza la protección contra la pérdida de datos. Se recomienda utilizar cualquier
otra solución de copia de seguridad en el esclavo de replicación junto con este
método.
Para más información sobre la replicación como solución de copia de seguridad, consulte la
documentación de MariaDB.
8.2.5. Migración a MariaDB 10.3

Red Hat Enterprise Linux 7 contiene MariaDB 5.5 como implementación por defecto de un servidor de
la familia de bases de datos MySQL. Las versiones posteriores del servidor de bases de datos MariaDB
están disponibles como Software Collections para Red Hat Enterprise Linux 6 y Red Hat Enterprise
Linux 7. Red Hat Enterprise Linux 8 proporciona MariaDB 10.3 y MySQL 8.0.
8.2.5.1. Diferencias notables entre las versiones RHEL 7 y RHEL 8 de MariaDB
Los cambios más importantes entre MariaDB 5.5 y MariaDB 10.3 son los siguientes:
MariaDB Galera Cluster, un clúster multimaster síncrono, es una parte estándar de MariaDB
desde 10.1.
El motor de almacenamiento ARCHIVE ya no está habilitado por defecto, y es necesario

habilitar el complemento específicamente.
El motor de almacenamiento de BLACKHOLE ya no está habilitado por defecto, y es necesario

habilitar el complemento específicamente.
Se utiliza InnoDB como motor de almacenamiento por defecto en lugar de XtraDB, que se
utilizaba en MariaDB 10.1 y versiones anteriores.
Para más detalles, consulte ¿Por qué MariaDB 10.2 utiliza InnoDB en lugar de XtraDB?
Los nuevos paquetes mariadb-connector-c proporcionan una biblioteca cliente común para
MySQL y MariaDB. Esta biblioteca es utilizable con cualquier versión de los servidores de bases
de datos MySQL y MariaDB. Como resultado, el usuario es capaz de conectar una compilación
de una aplicación a cualquiera de los servidores MySQL y MariaDB distribuidos con Red Hat
Enterprise Linux 8.
Para migrar de MariaDB 5.5 a MariaDB 10.3, es necesario realizar varios cambios de configuración
como se describe en Sección 8.2.5.2, “Cambios de configuración”.
8.2.5.2. Cambios de configuración
La ruta de migración recomendada de MariaDB 5.5 a MariaDB 10.3 es actualizar primero a MariaDB
10.0, y luego actualizar una versión sucesivamente.
148
La principal ventaja de actualizar una por una las versiones es una mejor adaptación de la base de datos,
tanto de los datos como de la configuración a los cambios. La actualización termina en la misma versión
principal que está disponible en RHEL 8 (MariaDB 10.3), lo que reduce significativamente los cambios de
configuración u otros problemas.
Para más información sobre los cambios de configuración al migrar de MariaDB 5.5 a MariaDB 10.0,
consulte Migración a MariaDB 10. 0 en la documentación de Red Hat Software Collections.
La migración a las siguientes versiones sucesivas de MariaDB y los cambios de configuración necesarios
se describen en estos documentos:
Migración a MariaDB 10.1 en la documentación de Red Hat Software Collections.
NOTA
La migración directamente de MariaDB 5.5 a MariaDB 10.3 también es posible, pero

debe realizar todos los cambios de configuración que se requieren por las diferencias
descritas en los documentos de migración anteriores.
8.2.5.3. Actualización en el lugar utilizando la herramienta mysql_upgrade
Para migrar los archivos de la base de datos a Red Hat Enterprise Linux 8, los usuarios de MariaDB en
Red Hat Enterprise Linux 7 necesitan realizar la actualización in situ utilizando la herramienta
mysql_upgrade. La herramienta mysql_upgrade es proporcionada por el subpaquete mariadb-server-
utils, que se instala como una dependencia del paquete mariadb-server.
Para realizar una actualización in situ, debe copiar los archivos de datos binarios al directorio de datos
/var/lib/mysql/ en el sistema Red Hat Enterprise Linux 8 y utilizar la herramienta mysql_upgrade.
Puede utilizar este método para migrar datos de:
La versión de Red Hat Enterprise Linux 7 de MariaDB 5.5
Las versiones de Red Hat Software Collections de:
MariaDB 5.5 (ya no es compatible)
MariaDB 10.2
Tenga en cuenta que se recomienda actualizar a MariaDB 10.2 por una versión sucesivamente. Consulte
los respectivos capítulos de migración en las Notas de la versión de Red Hat Software Collections .
NOTA
149
NOTA
Si está actualizando desde la versión de Red Hat Enterprise Linux 7 de MariaDB, los
datos de origen se almacenan en el directorio /var/lib/mysql/. En el caso de las versiones
de Red Hat Software Collections de MariaDB, el directorio de datos fuente es
/var/opt/rh/<collection_name>/lib/mysql/ (con la excepción de mariadb55, que utiliza el
directorio de datos /opt/rh/mariadb55/root/var/lib/mysql/ ).
IMPORTANTE
Antes de realizar la actualización, haga una copia de seguridad de todos sus datos
almacenados en las bases de datos de MariaDB.
Para realizar la actualización in situ, cambie al usuario root y utilice el siguiente procedimiento:
1. Asegúrese de que el paquete mariadb-server está instalado en el sistema Red Hat Enterprise
Linux 8:
# yum install mariadb-server
2. Asegúrese de que el demonio mariadb no se está ejecutando en ninguno de los sistemas de

origen y destino en el momento de copiar los datos:
3. Copie los datos de la ubicación de origen al directorio /var/lib/mysql/ en el sistema de destino

de Red Hat Enterprise Linux 8.
4. Establezca los permisos adecuados y el contexto SELinux para los archivos copiados en el
sistema de destino:
# restorecon -vr /var/lib/mysql
5. Inicie el servidor MariaDB en el sistema de destino:
6. Ejecute el comando mysql_upgrade para comprobar y reparar las tablas internas:
# systemctl mysql_upgrade
7. Una vez completada la actualización, asegúrese de que todos los archivos de configuración
dentro del directorio /etc/my.cnf.d/ incluyan sólo opciones válidas para MariaDB 10.3.
IMPORTANTE
Existen ciertos riesgos y problemas conocidos relacionados con la actualización in situ.

Por ejemplo, es posible que algunas consultas no funcionen o que se ejecuten en un
orden diferente al de antes de la actualización. Para más información sobre estos riesgos
y problemas, y para información general sobre la actualización in situ, consulte las Notas
de la versión de MariaDB 10.3.
8.2.6. Replicar MariaDB con Galera
150
Esta sección describe cómo replicar una base de datos MariaDB utilizando la solución Galera.
8.2.6.1. Introducción al clúster MariaDB Galera
La replicación de Galera se basa en la creación de un multimaster síncrono MariaDB Galera Cluster

compuesto por varios servidores MariaDB.
La interfaz entre la replicación de Galera y una base de datos MariaDB está definida por la API de
replicación de conjuntos de escritura (wsrep API).
Las principales características de MariaDB Galera Cluster son:
Replicación sincrónica
Topología multimaster activa-activa
Leer y escribir en cualquier nodo del clúster
Control automático de los miembros, los nodos que fallan se retiran del clúster
Unión automática de nodos
Replicación paralela a nivel de filas
Conexiones directas de clientes (los usuarios pueden conectarse a los nodos del clúster y
trabajar con los nodos directamente mientras se ejecuta la replicación)
La replicación sincrónica significa que un servidor replica una transacción en el momento de la

confirmación, transmitiendo el conjunto de escritura asociado a la transacción a todos los nodos del
clúster. El cliente (aplicación de usuario) se conecta directamente al sistema de gestión de bases de
datos (DBMS), y experimenta un comportamiento similar al de MariaDB nativo.
La replicación sincrónica garantiza que un cambio ocurrido en un nodo del clúster ocurra en otros nodos
del clúster al mismo tiempo.
Por lo tanto, la replicación sincrónica tiene las siguientes ventajas sobre la asincrónica:
No hay retraso en la propagación de los cambios entre los nodos de cluster particulares
Todos los nodos del clúster son siempre coherentes
Los últimos cambios no se pierden si uno de los nodos del clúster se bloquea
Las transacciones en todos los nodos del clúster se ejecutan en paralelo
Causalidad en toda la agrupación
Para obtener información más detallada, consulte la documentación de la corriente ascendente:
Acerca de la replicación de Galera
Qué es el clúster MariaDB Galera
Introducción al clúster MariaDB Galera
151
8.2.6.2. Componentes para construir el clúster MariaDB Galera
Para poder construir MariaDB Galera Cluster, los siguientes paquetes deben estar instalados en su
sistema:
mariadb-server-galera
mariadb-server
galera
El paquete mariadb-server-galera contiene archivos de apoyo y scripts para MariaDB Galera Cluster.
MariaDB upstream parchea el paquete mariadb-server para incluir la API de replicación de conjuntos de
escritura (wsrep API). Esta API proporciona la interfaz entre la replicación de Galera y MariaDB.
MariaDB upstream también parchea el paquete galera para añadir soporte completo para MariaDB. El
paquete galera contiene la herramienta Galera Replication Library y la Galera Arbitrator. Galera
Replication Library proporciona toda la funcionalidad de replicación. Galera Arbitrator puede utilizarse
como miembro del clúster que participa en la votación en los escenarios de cerebro dividido. Sin
embargo, Galera Arbitrator no puede participar en la replicación real.
Para obtener información más detallada, consulte la documentación de la corriente ascendente:
Biblioteca de réplicas de Galera
Árbitro Galera
proyecto mysql-wsrep
8.2.6.3. Despliegue del clúster MariaDB Galera
Requisitos previos
Todo el software necesario para construir MariaDB Galera Cluster debe estar instalado en el
sistema. Para asegurarse de ello, instale el perfil galera del módulo mariadb:10.3:
# yum module install mariadb:10.3/galera
Como resultado, se instalan los siguientes paquetes:
mariadb-server-galera
mariadb-server
galera
El paquete mariadb-server-galera tiene como dependencia los paquetes mariadb-server y
galera.
Para más información sobre los componentes para construir MariaDB Galera Cluster,
consulte Sección 8.2.6.2, “Componentes para construir el clúster MariaDB Galera” .
La configuración de replicación del servidor MariaDB debe actualizarse antes de añadir el

sistema a un clúster por primera vez.
La configuración por defecto se incluye en el archivo /etc/my.cnf.d/galera.cnf.
152
Antes de desplegar MariaDB Galera Cluster, configure la opción wsrep_cluster_address en

el archivo /etc/my.cnf.d/galera.cnf en todos los nodos para que comience con la siguiente
cadena:
gcomm://
Para el nodo inicial, es posible establecer wsrep_cluster_address como una lista vacía:
wsrep_cluster_address="gcomm://\_"
Para todos los demás nodos, configure wsrep_cluster_address para incluir una dirección a
cualquier nodo que ya forme parte del clúster en ejecución. Por ejemplo:
wsrep_cluster_address="gcomm://10.0.0.10"
Para obtener más información sobre cómo establecer la dirección del clúster de Galera,
consulte Dirección del clúster de Galera .
Procedimiento
1. Arranca el primer nodo de un nuevo cluster ejecutando el siguiente wrapper en ese nodo:
$ galera_new_cluster
Esta envoltura asegura que el demonio del servidor MariaDB (mysqld) se ejecuta con la opción
--wsrep-new-cluster. Esta opción proporciona la información de que no hay un cluster
existente al que conectarse. Por lo tanto, el nodo crea un nuevo UUID para identificar el nuevo
cluster.
NOTA
El servicio mariadb soporta un método systemd para interactuar con múltiples

procesos del servidor MariaDB. Por lo tanto, en casos con múltiples servidores
MariaDB en ejecución, puede arrancar una instancia específica especificando el
nombre de la instancia como sufijo:
$ galera_new_cluster mariadb@node1
2. Conecte otros nodos al clúster ejecutando el siguiente comando en cada uno de los nodos:
# systemctl start mariadb
Como resultado, el nodo se conecta al clúster y se sincroniza con el estado del clúster.
Para más información, vea Cómo empezar con MariaDB Galera Cluster .
8.2.6.4. Añadir un nuevo nodo al clúster MariaDB Galera
Para añadir un nuevo nodo a MariaDB Galera Cluster, utilice el siguiente procedimiento.
Tenga en cuenta que también puede utilizar este procedimiento para reconectar un nodo ya existente.
153
Procedimiento
En el nodo concreto, proporcione una dirección a uno o más miembros del clúster existentes en
la opción wsrep_cluster_address dentro de la sección [mariadb] del archivo de configuración
/etc/my.cnf.d/galera.cnf:
[mariadb]
wsrep_cluster_address="gcomm://192.168.0.1"
Cuando un nuevo nodo se conecta a uno de los nodos existentes del clúster, puede ver todos
los nodos del clúster.
Sin embargo, es preferible enumerar todos los nodos del clúster en wsrep_cluster_address.
Como resultado, cualquier nodo puede unirse a un clúster conectándose a cualquier otro nodo
del clúster, incluso si uno o más nodos del clúster están caídos. Cuando todos los miembros
están de acuerdo con la adhesión, se cambia el estado del clúster. Si el estado del nuevo nodo
es diferente al del clúster, solicita una Transferencia de Estado Incremental (IST) o una
Transferencia de Estado Instantánea (SST) para ser coherente con los demás nodos.
Para obtener información detallada sobre las transferencias instantáneas de estado (SST),
consulte Introducción a las transferencias instantáneas de estado .
8.2.6.5. Reinicio del clúster MariaDB Galera
Si se apagan todos los nodos al mismo tiempo, se termina el clúster, y el clúster en funcionamiento deja
de existir. Sin embargo, los datos del clúster siguen existiendo.
Para reiniciar el clúster, inicie un primer nodo como se describe en Sección 8.2.6.3, “Despliegue del
clúster MariaDB Galera”.

AVISO
Si el cluster no está arrancado, y mysqld en el primer nodo se inicia sólo con el

comando systemctl start mariadb, el nodo intenta conectarse al menos a uno de
los nodos listados en la opción wsrep_cluster_address del archivo
/etc/my.cnf.d/galera.cnf. Si no hay ningún nodo en funcionamiento, el reinicio falla.
8.3. USO DE POSTGRESQL
8.3.1. Introducción a PostgreSQL
El servidor PostgreSQL es un servidor de bases de datos de código abierto, robusto y altamente

154
El servidor PostgreSQL es un servidor de bases de datos de código abierto, robusto y altamente

extensible, basado en el lenguaje SQL. Proporciona un sistema de base de datos relacional con objetos,
que permite gestionar amplios conjuntos de datos y un elevado número de usuarios simultáneos. Por
estas razones, los servidores PostgreSQL pueden utilizarse en clusters para gestionar grandes
cantidades de datos.
El servidor PostgreSQL incluye funciones para garantizar la integridad de los datos, construir entornos
tolerantes a fallos o crear aplicaciones. Permite ampliar una base de datos con tipos de datos propios
del usuario, funciones personalizadas o código de diferentes lenguajes de programación sin necesidad
de recompilar la base de datos.
Esta sección describe cómo instalar PostgreSQL en Instalación de PostgreSQL o cómo migrar a una
versión diferente de PostgreSQL en Migración a una versión RHEL 8 de PostgreSQL . Uno de los
requisitos previos a la migración es realizar una copia de seguridad de los datos.
8.3.2. Instalación de PostgreSQL

En RHEL 8, el servidor PostgreSQL está disponible en varias versiones, cada una de ellas proporcionada
por una corriente independiente:
PostgreSQL 10 - el flujo por defecto
PostgreSQL 9.6
PostgreSQL 12 - disponible desde RHEL 8.1.1
NOTA
Por diseño, es imposible instalar más de una versión (stream) del mismo módulo en
paralelo. Por lo tanto, debe elegir sólo uno de los flujos disponibles del módulo
postgresql. La instalación paralela de componentes es posible en Red Hat Software
Collections para RHEL 7 y RHEL 6. En RHEL 8, se pueden utilizar diferentes versiones de
servidores de bases de datos en contenedores.
Para instalar PostgreSQL:
1. Habilite el flujo (versión) que desea instalar:
# yum module enable postgresql:stream
Sustituya stream por la versión seleccionada del servidor PostgreSQL.
Puede omitir este paso si desea utilizar el flujo por defecto, que proporciona PostgreSQL 10.
2. Asegúrese de que el paquete postgresql-server, disponible en el repositorio de AppStream,

está instalado en el servidor requerido:
# yum install postgresql-server
3. Inicializar el directorio de datos
postgresql-setup --initdb
4. Inicie el servicio postgresql:
155
# systemctl start postgresql.service
5. Habilitar el servicio postgresql para que se inicie en el arranque:
# systemctl enable postgresql.service
Para obtener información sobre el uso de flujos de módulos, consulte Instalación, gestión y eliminación
de componentes del espacio de usuario.
IMPORTANTE
Si desea actualizar desde un flujo anterior de postgresql dentro de RHEL 8, siga los dos
procedimientos descritos en Cambiar a un flujo posterior y en Sección 8.3.5, “Migración a
la versión RHEL 8 de PostgreSQL”.
8.3.3. Configuración de PostgreSQL

Para cambiar la configuración de PostgreSQL, utilice el archivo /var/lib/pgsql/data/postgresql.conf.
Después, reinicie el servicio postgresql para que los cambios se hagan efectivos:
systemctl restart postgresql.service
Aparte de /var/lib/pgsql/data/postgresql.conf, existen otros archivos para cambiar la configuración de

PostgreSQL:
postgresql.auto.conf
pg_ident.conf
pg_hba.conf
El archivo postgresql.auto.conf contiene los ajustes básicos de PostgreSQL de forma similar a

/var/lib/pgsql/data/postgresql.conf. Sin embargo, este archivo está bajo el control del servidor. Es
editado por las consultas de ALTER SYSTEM, y no puede ser editado manualmente.
El archivo pg_ident.conf se utiliza para mapear las identidades de usuario de los mecanismos de
autenticación externos en las identidades de usuario de postgresql.
El archivo pg_hba.conf se utiliza para configurar los permisos detallados de los usuarios para las bases
de datos PostgreSQL.
8.3.3.1. Inicialización de un clúster de bases de datos
En una base de datos PostgreSQL, todos los datos se almacenan en un único directorio, que se
denomina clúster de base de datos. Usted puede elegir dónde almacenar sus datos, pero Red Hat
recomienda almacenar los datos en el directorio por defecto /var/lib/pgsql/data.
Para inicializar este directorio de datos, ejecute
postgresql-setup --initdb
8.3.4. Copia de seguridad de los datos de PostgreSQL
156
Para hacer una copia de seguridad de los datos de PostgreSQL, utilice uno de los siguientes métodos:
Volcado SQL
Copia de seguridad a nivel de sistema de archivos
Archivo continuo
8.3.4.1. Copia de seguridad de los datos de PostgreSQL con un volcado SQL
8.3.4.1.1. Realización de un volcado SQL
El método de volcado SQL se basa en la generación de un archivo con comandos SQL. Cuando este
archivo se vuelve a cargar en el servidor de la base de datos, recrea la base de datos en el mismo estado
en el que se encontraba en el momento del volcado. El volcado de SQL está garantizado por la utilidad
pg_dump que es una aplicación cliente de PostgreSQL. El uso básico del comando pg_dump es tal que
el comando escribe su resultado en la salida estándar:
pg_dump dbname > dumpfile
El archivo SQL resultante puede estar en formato de texto o en otros formatos diferentes, lo que
permite el paralelismo y un control más detallado de la restauración de objetos.
Puede realizar el volcado SQL desde cualquier host remoto que tenga acceso a la base de datos. La
utilidad pg_dump utilidad no opera con permisos especiales, pero debe tener un acceso de lectura a
todas las tablas de las que quiera hacer una copia de seguridad. Para realizar una copia de seguridad de
toda la base de datos, debe ejecutarla como superusuario de la base de datos.
Para especificar con qué servidor de bases de datos pg_dump contactará, utilice las siguientes
opciones de la línea de comandos:
La opción -h para definir el host.

El host por defecto es el local o el especificado por la variable de entorno PGHOST.
La opción -p para definir el puerto.

El puerto por defecto está indicado por la variable de entorno PGPORT o por el puerto por
defecto compilado.
NOTA
Tenga en cuenta que pg_dump vuelca sólo una base de datos. No vuelca la información
sobre los roles o los tablespaces porque dicha información se refiere a todo el clúster.
Para hacer una copia de seguridad de cada base de datos de un clúster determinado y
conservar los datos de todo el clúster, como las definiciones de roles y espacios de tablas,
utilice el comando pg_dumpall:
pg_dumpall > dumpfile
8.3.4.1.2. Restauración de la base de datos a partir de un volcado SQL
Para restaurar una base de datos a partir de un volcado SQL:
1. Crear una nueva base de datos (dbname):
157
creadob dbname
2. Asegúrese de que todos los usuarios que poseen objetos o a los que se les concedieron
permisos sobre objetos en la base de datos volcada ya existen.
Si estos usuarios no existen, la restauración no consigue recrear los objetos con la propiedad y
los permisos originales.
3. Ejecute la psql utilidad para restaurar un volcado de archivos de texto creado por la pg_dump
utilidad:
psql dbname < dumpfile
donde dumpfile es la salida del comando pg_dump.
Si desea restaurar un volcado de archivos que no sean de texto, utilice la utilidad pg_restore:
pg_restore archivo de texto no plano
8.3.4.1.2.1. Restaurar una base de datos en otro servidor
El volcado de una base de datos directamente de un servidor a otro es posible porque pg_dump y psql
pueden escribir en y leer de tuberías.
Para volcar una base de datos de un servidor a otro, ejecute
pg_dump -h host1 dbname | psql -h host2 dbname
8.3.4.1.2.2. Manejo de errores SQL durante la restauración
Por defecto, psql continúa ejecutándose si se produce un error SQL. En consecuencia, la base de datos
se restaura sólo parcialmente.
Si quiere cambiar este comportamiento por defecto, utilice uno de los siguientes métodos:
Haga que psql salga con un estado de salida de 3 si se produce un error SQL estableciendo la
variable ON_ERROR_STOP:
psql --set ON_ERROR_STOP=on dbname < dumpfile
Especifique que todo el volcado se restaura como una única transacción para que la
restauración se complete o se cancele por completo utilizando psql con una de las siguientes
opciones:
psql -1
psql --single-transaction
Tenga en cuenta que cuando se utiliza este enfoque, incluso un error menor puede cancelar una
operación de restauración que ya se ha ejecutado durante muchas horas.
158
8.3.4.1.3. Ventajas y desventajas de un volcado SQL
Un volcado de SQL tiene las siguientes ventajas en comparación con otros métodos de copia de
seguridad de PostgreSQL:
Un volcado SQL es el único método de copia de seguridad de PostgreSQL que no es

específico de la versión del servidor. La salida de la utilidad pg_dump puede recargarse en
versiones posteriores de PostgreSQL, lo que no es posible para las copias de seguridad a nivel
de sistema de archivos o el archivado continuo.
Un volcado de SQL es el único método que funciona cuando se transfiere una base de datos a
una arquitectura de máquina diferente, como pasar de un servidor de 32 bits a uno de 64 bits.
Un volcado SQL proporciona volcados internamente consistentes. Un volcado representa una

instantánea de la base de datos en el momento en que pg_dump comenzó a ejecutarse.
La utilidad pg_dump utilidad no bloquea otras operaciones en la base de datos cuando se está
ejecutando.
Una desventaja de un volcado de SQL es que lleva más tiempo en comparación con la copia de
seguridad a nivel de sistema de archivos.
Para más información sobre el volcado de SQL, consulte la documentación de PostgreSQL.
8.3.4.2. Copia de seguridad de los datos de PostgreSQL con una copia de seguridad a nivel
de sistema de archivos
8.3.4.2.1. Realización de una copia de seguridad a nivel de sistema de archivos
Para realizar una copia de seguridad a nivel de sistema de archivos, es necesario copiar los archivos que
PostgreSQL utiliza para almacenar los datos de la base de datos en otra ubicación:
1. Elija la ubicación de un clúster de base de datos e inicialice este clúster como se describe en
Sección 8.3.3.1, “Inicialización de un clúster de bases de datos” .
2. Detenga el servicio postgresql:
# systemctl stop postgresql.service
3. Utilice cualquier método para hacer una copia de seguridad del sistema de archivos, por
ejemplo:
tar -cf backup.tar /var/lib/pgsql/data
4. Inicie el servicio postgresql:
8.3.4.2.2. Ventajas y desventajas de una copia de seguridad a nivel de sistema de archivos
Una copia de seguridad a nivel de sistema de archivos tiene la siguiente ventaja en comparación con
otros métodos de copia de seguridad de PostgreSQL:
La copia de seguridad a nivel de sistema de archivos suele ser más rápida que el volcado de
159
La copia de seguridad a nivel de sistema de archivos suele ser más rápida que el volcado de
SQL.
La copia de seguridad a nivel de sistema de archivos tiene las siguientes desventajas en comparación
con otros métodos de copia de seguridad de PostgreSQL:
La copia de seguridad es específica de la arquitectura y de Red Hat Enterprise Linux 7. Sólo se

puede utilizar como copia de seguridad para volver a Red Hat Enterprise Linux 7 si la
actualización no fue exitosa, pero no se puede utilizar con PostgreSQL 10.0.
El servidor de la base de datos debe apagarse antes de la copia de seguridad de los datos y
también antes de la restauración de los mismos.
La copia de seguridad y restauración de ciertos archivos o tablas individuales es imposible. Las

copias de seguridad del sistema de archivos sólo funcionan para una copia de seguridad y
restauración completa de un clúster de bases de datos.
8.3.4.2.3. Enfoques alternativos a la copia de seguridad a nivel de sistema de archivos
Los enfoques alternativos a la copia de seguridad del sistema de archivos incluyen:
Una instantánea coherente del directorio de datos
La utilidad rsync
Para más información sobre la copia de seguridad a nivel de sistema de archivos, consulte la
documentación de PostgreSQL.
8.3.4.3. Copia de seguridad de los datos de PostgreSQL mediante archivo continuo
8.3.4.3.1. Introducción al archivo continuo
PostgreSQL registra todos los cambios realizados en los archivos de datos de la base de datos en un
archivo de registro de escritura (WAL) que está disponible en el subdirectorio pg_wal/ del directorio de
datos del clúster. Este registro está pensado principalmente para la recuperación de un fallo. Después
de una caída, las entradas del registro realizadas desde el último punto de control pueden utilizarse para
restaurar la consistencia de la base de datos.
El método de archivo continuo, también conocido como online backup, combina los archivos WAL con
una copia de seguridad a nivel del sistema de archivos. Si se necesita una recuperación de la base de
datos, se puede restaurar la base de datos a partir de la copia de seguridad del sistema de archivos y, a
continuación, reproducir el registro de los archivos WAL respaldados para llevar el sistema al estado
actual.
Para este método de copia de seguridad, se necesita una secuencia continua de archivos WAL
archivados que se remonte al menos a la hora de inicio de la copia de seguridad.
Si quiere empezar a utilizar el método de copia de seguridad de archivo continuo, asegúrese de

configurar y probar su procedimiento para archivar los archivos WAL antes de realizar su primera copia
de seguridad base.
NOTA
160
NOTA
No se puede utilizar pg_dump y pg_dumpall como parte de una solución de copia de

seguridad de archivo continuo. Estos volcados producen copias de seguridad lógicas, no
copias de seguridad a nivel de sistema de archivos. Como tal, no contienen suficiente
información para ser utilizada por una repetición de WAL.
8.3.4.3.2. Realización de copias de seguridad de archivo continuo
Para realizar una copia de seguridad y restauración de la base de datos utilizando el método de archivo
continuo, siga estos pasos:
1. Sección 8.3.4.3.2.1, “Hacer una copia de seguridad de la base”
2. Sección 8.3.4.3.2.2, “Restauración de la base de datos mediante una copia de seguridad de

archivo continuo”
8.3.4.3.2.1. Hacer una copia de seguridad de la base
Para realizar una copia de seguridad base, utilice la herramienta pg_basebackup que puede crear una
copia de seguridad base en forma de archivos individuales o de un archivo tar.
Para utilizar la copia de seguridad básica, es necesario conservar todos los archivos de segmentos WAL
generados durante y después de la copia de seguridad del sistema de archivos. El proceso de copia de
seguridad básica crea un archivo de historial de copias de seguridad que se almacena en el área de
archivo WAL y recibe el nombre del primer archivo de segmentos WAL que se necesita para la copia de
seguridad del sistema de archivos. Cuando haya archivado de forma segura la copia de seguridad del
sistema de archivos y los archivos de segmentos WAL utilizados durante la copia de seguridad, que se
especifican en el archivo de historial de copias de seguridad, puede eliminar todos los segmentos WAL
archivados con nombres numéricamente menores porque ya no son necesarios para recuperar la copia
de seguridad del sistema de archivos. Sin embargo, considere la posibilidad de mantener varios
conjuntos de copias de seguridad para estar seguro de que puede recuperar sus datos.
El archivo del historial de la copia de seguridad es un pequeño archivo de texto, que contiene la cadena
de etiquetas que le diste a pg_basebackupla hora de inicio y de finalización, y los segmentos WAL de la
copia de seguridad. Si utilizó la cadena de etiquetas para identificar el archivo de volcado asociado,
entonces el archivo de historial archivado es suficiente para indicarle qué archivo de volcado debe
restaurar.
Con el método de archivo continuo, es necesario mantener todos los archivos WAL archivados hasta la
última copia de seguridad base. Por lo tanto, la frecuencia ideal de las copias de seguridad base
depende de:
El volumen de almacenamiento disponible para los archivos WAL archivados.
La duración máxima posible de la recuperación de datos en situaciones en las que es necesaria

la recuperación.
En los casos en los que ha transcurrido un largo periodo desde la última copia de seguridad, el
sistema vuelve a reproducir más segmentos WAL, por lo que la recuperación tarda más tiempo.
Para más información sobre cómo hacer una copia de seguridad de la base, consulte la documentación
de PostgreSQL.
8.3.4.3.2.2. Restauración de la base de datos mediante una copia de seguridad de archivo continuo
Para restaurar una base de datos utilizando una copia de seguridad continua:
161
1. Detener el servidor:
2. Copie los datos necesarios en una ubicación temporal.

Preferiblemente, copie todo el directorio de datos del clúster y cualquier tablespace. Tenga en
cuenta que esto requiere suficiente espacio libre en su sistema para mantener dos copias de su
base de datos existente.
Si no tiene suficiente espacio, guarde el contenido del directorio pg_wal del clúster, que puede
contener registros que no fueron archivados antes de que el sistema se cayera.
3. Elimine todos los archivos y subdirectorios existentes en el directorio de datos del clúster y en
los directorios raíz de los tablespaces que esté utilizando.
4. Restaurar los archivos de la base de datos desde la copia de seguridad del sistema de archivos.
Asegúrate de que:
Los archivos se restauran con la propiedad correcta (el usuario del sistema de la base de
datos, no root)
Los archivos se restauran con los permisos correctos
Los enlaces simbólicos en el subdirectorio pg_tblspc/ se han restaurado correctamente
5. Eliminar los archivos presentes en el subdirectorio pg_wal/

Estos archivos proceden de la copia de seguridad del sistema de archivos y, por tanto, son
obsoletos. Si no archivó pg_wal/, vuelva a crearlo con los permisos adecuados.
6. Copie los archivos de segmentos de WAL no archivados que guardó en el paso 2 en pg_wal/, si
es que existen tales archivos.
7. Cree el archivo de comandos de recuperación recovery.conf en el directorio de datos del

clúster.
8. Inicie el servidor:
El servidor entrará en el modo de recuperación y procederá a leer los ficheros WAL archivados
que necesite.
Si la recuperación se interrumpe debido a un error externo, basta con reiniciar el servidor para
que continúe la recuperación. Cuando el proceso de recuperación finaliza, el servidor cambia el
nombre de recovery.conf a recovery.done para evitar que se vuelva a entrar accidentalmente
en el modo de recuperación más adelante, cuando el servidor inicie las operaciones normales de
la base de datos.
9. Compruebe el contenido de la base de datos para asegurarse de que la base de datos se ha

recuperado en el estado requerido.
Si la base de datos no se ha recuperado en el estado requerido, vuelva al paso 1. Si la base de
datos se ha recuperado en el estado requerido, permita que los usuarios se conecten
restaurando el archivo pg_hba.conf a la normalidad.
Para obtener más información sobre la restauración mediante la copia de seguridad continua, consulte
la documentación de PostgreSQL.
162
8.3.4.3.3. Ventajas y desventajas del archivo continuo
El archivo continuo tiene las siguientes ventajas en comparación con otros métodos de copia de
Con el método de copia de seguridad continua, es posible utilizar una copia de seguridad del
sistema de archivos que no sea totalmente consistente porque cualquier inconsistencia interna
en la copia de seguridad es corregida por la repetición del registro. No se necesita una
instantánea del sistema de archivos; basta con tar o una herramienta de archivo similar.
Se puede conseguir una copia de seguridad continua si se siguen archivando los archivos WAL,
ya que la secuencia de archivos WAL para la repetición del registro puede ser indefinidamente
larga. Esto es especialmente valioso para las grandes bases de datos.
La copia de seguridad continua admite la recuperación puntual. No es necesario reproducir las

entradas WAL hasta el final. La reproducción puede detenerse en cualquier punto y la base de
datos puede restaurarse a su estado en cualquier momento desde que se tomó la copia de
seguridad base.
Si la serie de archivos WAL está continuamente disponible para otra máquina que ha sido
cargada con el mismo archivo de copia de seguridad base, es posible restaurar la otra máquina
con una copia casi actual de la base de datos en cualquier momento.
El archivo continuo tiene las siguientes desventajas en comparación con otros métodos de copia de
El método de copia de seguridad continua sólo admite la restauración de todo un clúster de

bases de datos, no de un subconjunto.
Las copias de seguridad continuas requieren un amplio almacenamiento de archivos.
Para más información sobre el método de archivo continuo, consulte la documentación de PostgreSQL.
8.3.5. Migración a la versión RHEL 8 de PostgreSQL

Red Hat Enterprise Linux 7 contiene PostgreSQL 9.2 como versión por defecto del servidor
PostgreSQL. Además, se proporcionan varias versiones de PostgreSQL como Software Collections
para RHEL 7 y RHEL 6.
Red Hat Enterprise Linux 8 proporciona PostgreSQL 10 (el flujo por defecto postgresql ),
PostgreSQL 9.6, y PostgreSQL 12.
Los usuarios de PostgreSQL en Red Hat Enterprise Linux pueden utilizar dos rutas de migración para
los archivos de la base de datos:
Actualización rápida con la herramienta pg_upgrade
Actualización de volcado y restauración
Utilice preferentemente el método de actualización rápida, que es más rápido que el proceso de volcado
y restauración.
Sin embargo, en ciertos casos, la actualización rápida no funciona, y sólo se puede utilizar el proceso de
volcado y restauración. Estos casos incluyen:
163
Actualizaciones entre arquitecturas
Sistemas que utilizan las extensiones plpython o plpython2. Tenga en cuenta que el repositorio
de RHEL 8 AppStream sólo incluye el paquete postgresql-plpython3, no el paquete
postgresql-plpython2.
La actualización rápida no es compatible con la migración desde las versiones de Red Hat
Software Collections de PostgreSQL.
Como requisito previo a la migración a una versión posterior de PostgreSQL, haga una copia de
seguridad de todas sus bases de datos de PostgreSQL.
El volcado de las bases de datos y la realización de copias de seguridad de los archivos SQL es una parte
necesaria del proceso de volcado y restauración. Sin embargo, se recomienda hacerlo también si se
realiza la actualización rápida.
Antes de migrar a una versión posterior de PostgreSQL, consulte las notas de compatibilidad de la
versión de PostgreSQL a la que desea migrar, así como de todas las versiones de PostgreSQL omitidas
entre la que está migrando y la versión de destino.
8.3.5.1. Actualización rápida con la herramienta pg_upgrade
Durante una actualización rápida, es necesario copiar los archivos de datos binarios en el directorio
/var/lib/pgsql/data/ y utilizar la herramienta pg_upgrade.
Puede utilizar este método para migrar datos:
De la versión del sistema RHEL 7 de PostgreSQL 9.2 a la versión RHEL 8 de PostgreSQL 10
De la versión RHEL 8 de PostgreSQL 10 a la versión RHEL 8 de PostgreSQL 12
Si desea actualizar desde un flujo anterior de postgresql dentro de RHEL 8, siga el procedimiento
descrito en Cambio a un flujo posterior y luego migre sus datos de PostgreSQL.
Para migrar entre otras combinaciones de versiones de PostgreSQL dentro de RHEL, y para la
migración desde las versiones de Red Hat Software Collections de PostgreSQL a RHEL, utilice Dump
and restore upgrade.
IMPORTANTE
Antes de realizar la actualización, haga una copia de seguridad de todos sus datos
almacenados en las bases de datos de PostgreSQL.
Por defecto, todos los datos se almacenan en el directorio /var/lib/pgsql/data/ en los sistemas RHEL 7 y
RHEL 8.
El siguiente procedimiento describe la migración de la versión del sistema RHEL 7 de Postgreql 9.2 a
una versión RHEL 8 de PostgreSQL.
Para realizar una actualización rápida:
1. En el sistema RHEL 8, active el flujo (versión) al que desea migrar:
164
2. En el sistema RHEL 8, instale los paquetes postgresql-server y postgresql-upgrade:
# yum install postgresql-server postgresql-upgrade
Opcionalmente, si ha utilizado algún módulo de servidor PostgreSQL en RHEL 7, instálelo

también en el sistema RHEL 8 en dos versiones, compiladas tanto contra PostgreSQL 9.2
(instalado como paquete postgresql-upgrade ) como contra la versión de destino de
PostgreSQL (instalado como paquete postgresql-server ). Si necesita compilar un módulo de
servidor PostgreSQL de terceros, constrúyalo tanto contra los paquetes postgresql-devel
como postgresql-upgrade-devel.
3. Compruebe los siguientes elementos:
Configuración básica: En el sistema RHEL 8, compruebe si su servidor utiliza el directorio

por defecto /var/lib/pgsql/data y si la base de datos está correctamente inicializada y
habilitada. Además, los archivos de datos deben almacenarse en la misma ruta mencionada
en el archivo /usr/lib/systemd/system/postgresql.service.
servidoresPostgreSQL: Su sistema puede ejecutar varios servidores PostgreSQL.

Asegúrese de que los directorios de datos de todos estos servidores se manejan de forma
independiente.
módulos del servidorPostgreSQL: Asegúrese de que los módulos del servidor PostgreSQL
que utilizó en RHEL 7 están instalados también en su sistema RHEL 8. Tenga en cuenta que
los complementos se instalan en el directorio /usr/lib64/pgsql/ (o en el directorio
/usr/lib/pgsql/ en los sistemas de 32 bits).
4. Asegúrese de que el servicio postgresql no se está ejecutando en ninguno de los sistemas de

origen y destino en el momento de copiar los datos.
5. Copie los archivos de la base de datos desde la ubicación de origen al directorio

/var/lib/pgsql/data/ en el sistema RHEL 8.
6. Realice el proceso de actualización ejecutando el siguiente comando como usuario de

PostgreSQL:
$ /bin/postgresql-setup --upgrade
Esto lanza el proceso pg_upgrade en segundo plano.
En caso de fallo, postgresql-setup proporciona un mensaje de error informativo.
7. Copie la configuración anterior de /var/lib/pgsql/data-old al nuevo clúster.

Tenga en cuenta que la actualización rápida no reutiliza la configuración anterior en la pila de
datos más nueva y la configuración se genera desde cero. Si quieres combinar la configuración
antigua y la nueva manualmente, utiliza los archivos *.conf en los directorios de datos.
8. Inicie el nuevo servidor PostgreSQL:
9. Ejecute el script analyze_new_cluster.sh que se encuentra en el directorio principal

165
9. Ejecute el script analyze_new_cluster.sh que se encuentra en el directorio principal

PostgreSQL:
su postgres -c '~/analyze_new_cluster.sh'
10. Si quieres que el nuevo servidor PostgreSQL se inicie automáticamente al arrancar, ejecuta:
# systemctl enable postgresql.service
8.3.5.2. Actualización de volcado y restauración
Cuando se utiliza la actualización de volcado y restauración, es necesario volcar el contenido de todas

las bases de datos en un archivo de volcado de archivos SQL.
Tenga en cuenta que la actualización de volcado y restauración es más lenta que el método de
actualización rápida y puede requerir alguna corrección manual en el archivo SQL generado.
Puede utilizar este método para migrar datos de:
La versión del sistema Red Hat Enterprise Linux 7 de PostgreSQL 9.2
Cualquier versión anterior de Red Hat Enterprise Linux 8 de PostgreSQL
Una versión anterior o igual de PostgreSQL de Red Hat Software Collections:
PostgreSQL 9.2 (ya no es compatible)
PostgreSQL 9.4 (ya no es compatible)
PostgreSQL 9.6
PostgreSQL 10
PostgreSQL 12
En los sistemas Red Hat Enterprise Linux 7 y Red Hat Enterprise Linux 8, los datos de PostgreSQL se
almacenan por defecto en el directorio /var/lib/pgsql/data/. En el caso de las versiones de Red Hat
Software Collections de PostgreSQL, el directorio de datos por defecto es
/var/opt/rh/collection_name/lib/pgsql/data/ (con la excepción de postgresql92, que utiliza el
directorio /opt/rh/postgresql92/root/var/lib/pgsql/data/ ).
Si desea actualizar desde un flujo anterior de postgresql dentro de RHEL 8, siga el procedimiento
descrito en Cambio a un flujo posterior y luego migre sus datos de PostgreSQL.
Para realizar la actualización de volcado y restauración, cambie el usuario a root.
El siguiente procedimiento describe la migración de la versión del sistema RHEL 7 de Postgreql 9.2 a
una versión RHEL 8 de PostgreSQL.
1. En su sistema RHEL 7, inicie el servidor PostgreSQL 9.2:
2. En el sistema RHEL 7, vuelque el contenido de todas las bases de datos en el archivo

pgdump_file.sql:
166
su - postgres -c \ "pg_dumpall > ~/pgdump_file.sql"
3. Asegúrese de que las bases de datos se han volcado correctamente:
su - postgres -c 'less \ "$HOME/pgdump_file.sql"'
Como resultado, se muestra la ruta del archivo sql volcado: /var/lib/pgsql/pgdump_file.sql.
4. En el sistema RHEL 8, active el flujo (versión) al que desea migrar:
5. En el sistema RHEL 8, instale el paquete postgresql-server:
# yum install postgresql-server
Opcionalmente, si ha utilizado algún módulo de servidor PostgreSQL en RHEL 7, instálelo

también en el sistema RHEL 8. Si necesita compilar un módulo de servidor PostgreSQL de un
tercero, constrúyalo con el paquete postgresql-devel.
6. En el sistema RHEL 8, inicialice el directorio de datos para el nuevo servidor PostgreSQL:
# postgresql-setup --initdb
7. En el sistema RHEL 8, copie el pgdump_file.sql en el directorio principal PostgreSQL y

compruebe que el archivo se ha copiado correctamente:
su - postgres -c 'test -e \ "$HOME/pgdump_file.sql" && echo exists'
8. Copie los archivos de configuración del sistema RHEL 7:
su - postgres -c 'ls -1 $PGDATA/*.conf'
Los archivos de configuración que deben copiarse son:
/var/lib/pgsql/data/pg_hba.conf
/var/lib/pgsql/data/pg_ident.conf
/var/lib/pgsql/data/postgresql.conf
9. En el sistema RHEL 8, inicie el nuevo servidor PostgreSQL:
10. En el sistema RHEL 8, importe los datos del archivo sql volcado:
su - postgres -c 'psql -f ~/pgdump_file.sql postgres'
NOTA
167
NOTA
Cuando se actualice desde una versión de Red Hat Software Collections de

PostgreSQL, ajuste los comandos para incluir scl enable collection_name.. Por ejemplo,
para volcar los datos de la Colección de Software rh-postgresql96, utilice el siguiente
comando:
su - postgres -c 'scl enable rh-postgresql96 \ "pg_dumpall > ~/pgdump_file.sql"'
168
CAPÍTULO 9. CONFIGURACIÓN DE LA IMPRESIÓN

La impresión en Red Hat Enterprise Linux 8 se basa en el sistema de impresión común de Unix (CUPS).
Esta documentación describe cómo configurar una máquina para que pueda funcionar como servidor
CUPS.
9.1. ACTIVACIÓN DEL SERVICIO DE COPAS

Esta sección describe cómo activar el servicio cups en su sistema.
Requisitos previos
El paquete cups, que está disponible en el repositorio de Appstream, debe estar instalado en tu
sistema:
# yum install cups
Procedimiento
1. Inicie el servicio cups:
# systemctl start cups
2. Configure el servicio cups para que se inicie automáticamente en el momento del arranque:
# systemctl enable cups
3. Opcionalmente, compruebe el estado del servicio cups:
$ systemctl status cups
9.2. HERRAMIENTAS DE CONFIGURACIÓN DE LA IMPRESIÓN

Para realizar diversas tareas relacionadas con la impresión, puede elegir una de las siguientes
herramientas:
CUPS web user interface (UI)
GNOME Control center

AVISO
La herramienta de configuración Print Settings herramienta de configuración, que

se utilizaba en Red Hat Enterprise Linux 7, ya no está disponible.
Entre las tareas que puedes realizar con estas herramientas se encuentran:
169
Añadir y configurar una nueva impresora
Mantener la configuración de la impresora
Gestión de las clases de impresoras
Tenga en cuenta que esta documentación sólo cubre la impresión en CUPS web user interface (UI). Si
quiere imprimir con GNOME Control centernecesita tener una GUI disponible. Para más información
sobre la impresión con GNOME Control centervea Manejo de la impresión a partir de GNOME .
9.3. ACCESO Y CONFIGURACIÓN DE LA INTERFAZ WEB DE CUPS

Esta sección describe el acceso a la CUPS web user interface)(web UI) y la configuración para poder
gestionar la impresión a través de esta interfaz.
Procedimiento
Para acceder a la página web CUPS web UI:
1. Permita que el servidor CUPS escuche las conexiones de la red estableciendo Port 631 en el
archivo /etc/cups/cupsd.conf:
#Listen localhost:631
Port 631

AVISO
Al habilitar el servidor CUPS para que escuche en el puerto 631 se abre este
puerto para cualquier dirección accesible por el servidor. Por lo tanto, utilice
esta configuración sólo en redes locales que sean inalcanzables desde una
red externa. Si un servidor necesita ser accesible desde una red externa,
pero quiere abrir el puerto 631 sólo para su red local, configure lo siguiente
en el archivo /etc/cups/cupsd.conf: #Listen
<server_local_IP_address>:631, donde <server_local_IP_address> es una
dirección IP inalcanzable desde una red externa, pero está disponible para
las máquinas locales.
2. Permita que su sistema acceda al servidor CUPS incluyendo lo siguiente en el archivo

/etc/cups/cupsd.conf:
<Location />
Allow from <your_ip_address>
Order allow,deny
</Location>
donde <your_ip_address> es la dirección IP real de su sistema. También puede utilizar

expresiones regulares para las subredes.
170

AVISO
La configuración de CUPS ofrece la directiva Allow from all en las

etiquetas <Location>, pero Red Hat no recomienda usarla, a menos que
quiera abrir CUPS a la red externa de Internet, o si el servidor está en una
red privada. La configuración Allow from all permite el acceso a todos los
usuarios que puedan conectarse al servidor a través del puerto 631. Si
establece la directiva Port en 631, y el servidor es accesible desde una red
externa, cualquier persona en Internet puede acceder al servicio CUPS en
su sistema.
3. Reinicie el servicio cups.service:
# systemctl restart cups
4. Abra su navegador y vaya a http://<IP_address_of_the_CUPS_server>:631/.
Ya están disponibles todos los menús, excepto el de Administration.
Si hace clic en el menú Administration, recibirá el mensaje Forbidden:
Para adquirir el acceso al menú Administration, siga las instrucciones de Sección 9.3.1, “Adquirir
acceso de administración a la interfaz web de CUPS”.
9.3.1. Adquirir acceso de administración a la interfaz web de CUPS

Esta sección describe cómo adquirir acceso de administración al CUPS web UI.
Procedimiento
1. Para poder acceder al menú Administation en el CUPS web UIincluya lo siguiente en el archivo
171
1. Para poder acceder al menú Administation en el CUPS web UIincluya lo siguiente en el archivo
/etc/cups/cupsd.conf:
<Location /admin>
Order allow,deny
</Location>
NOTA
Sustituya <your_ip_address> por la dirección IP real de su sistema.
2. Para poder acceder a los archivos de configuración en el CUPS web UIincluya lo siguiente en el
<Location /admin/conf>
AuthType Default
Require user @SYSTEM
Order allow,deny
</Location>
NOTA
3. Para poder acceder a los archivos de registro en el CUPS web UIincluya lo siguiente en el
<Location /admin/log>
AuthType Default
Require user @SYSTEM
Order allow,deny
</Location>
NOTA
4. Para especificar el uso de la encriptación para las peticiones autenticadas en el CUPS web
UIincluya DefaultEncryption en el archivo /etc/cups/cupsd.conf:
Encriptación por defecto IfRequested
Con esta configuración, recibirá una ventana de autenticación para introducir el nombre de
usuario de un usuario autorizado a añadir impresoras cuando intente acceder al menú
Administration. Sin embargo, también hay otras opciones cómo configurar DefaultEncryption.
Para más detalles, consulte la página man de cupsd.conf.
5. Reinicie el servicio cups:
172
# systemctl restart cups

AVISO
Si no reinicia el servicio cups, los cambios en /etc/cups/cupsd.conf no se

aplicarán. Por lo tanto, no podrá obtener acceso de administración al
servicio CUPS web UI.
Para más información sobre cómo configurar un servidor CUPS utilizando el archivo
/etc/cups/cupsd.conf, consulte la página de manual cupsd.conf.
9.4. AÑADIR UNA IMPRESORA EN LA INTERFAZ WEB DE CUPS

Esta sección describe cómo añadir una nueva impresora utilizando la opción CUPS web user interface.
Requisitos previos
Usted ha adquirido el acceso de administración al CUPS web UI como se describe en

Sección 9.3.1, “Adquirir acceso de administración a la interfaz web de CUPS” .
Procedimiento
1. Inicie el CUPS web UI como se describe en Sección 9.3, “Acceso y configuración de la interfaz
web de CUPS”
2. Ir a Adding Printers and Classes - Add printer
173
3. Autenticación por nombre de usuario y contraseña:
IMPORTANTE
Para poder añadir una nueva impresora mediante el botón CUPS web UIdebe
autenticarse como uno de los siguientes usuarios:
Superusuario
Cualquier usuario con el acceso de administración proporcionado por el

comando sudo (usuarios listados en /etc/sudoers)
Cualquier usuario perteneciente al grupo printadmin en /etc/group
4. Si hay una impresora local conectada, o CUPS encuentra una impresora de red disponible,
seleccione la impresora. Si no hay ninguna impresora local ni de red disponible, seleccione uno
de los tipos de impresora de Other Network Printers, por ejemplo APP Socket/HP Jet direct,
introduzca la dirección IP de la impresora y haga clic en Continue.
174
5. Si ha seleccionado, por ejemplo, APP Socket/HP Jet direct como se muestra arriba, introduzca
la dirección IP de la impresora y, a continuación, haga clic en Continue.
6. Puede añadir más detalles sobre la nueva impresora, como el nombre, la descripción y la
ubicación. Para configurar una impresora para que se comparta en la red, utilice Share This
Printer como se muestra a continuación.
7. Seleccione el fabricante de la impresora y haga clic en Continue.
175
También puede proporcionar un archivo de descripción de impresora postscript (PPD) que se

utilizará como controlador para la impresora, haciendo clic en Browse… en la parte inferior.
8. Seleccione el modelo de la impresora y, a continuación, haga clic en Add Printer.
9. Una vez añadida la impresora, la siguiente ventana permite establecer las opciones de impresión
por defecto.
176
Tras hacer clic en Set Default Options, recibirá una confirmación de que la nueva impresora se ha
añadido correctamente.
9.5. CONFIGURAR UNA IMPRESORA EN LA INTERFAZ WEB DE CUPS

Esta sección describe cómo configurar una nueva impresora, y cómo mantener la configuración de una
impresora utilizando el CUPS web UI.
Requisitos previos
Usted ha adquirido el acceso de administración al CUPS web UI como se describe en

Sección 9.3.1, “Adquirir acceso de administración a la interfaz web de CUPS” .
Procedimiento
1. Haga clic en el menú Printers para ver las impresoras disponibles que puede configurar.
2. Elija una impresora que desee configurar.
177
3. Realice la tarea seleccionada utilizando uno de los menús disponibles:
Vaya a Maintenance para las tareas de mantenimiento.
Vaya a Administration para las tareas de administración.
También puede comprobar los trabajos de impresión completados o todos los trabajos de
impresión activos haciendo clic en los botones Show Completed Jobs o Show All Jobs.
9.6. IMPRESIÓN DE UNA PÁGINA DE PRUEBA MEDIANTE LA INTERFAZ

178
9.6. IMPRESIÓN DE UNA PÁGINA DE PRUEBA MEDIANTE LA INTERFAZ

WEB DE CUPS
Esta sección describe cómo imprimir una página de prueba para asegurarse de que la impresora
funciona correctamente.
Es posible que desee imprimir una página de prueba si se cumple una de las siguientes condiciones.
Se ha instalado una impresora.
Se ha modificado la configuración de una impresora.
Requisitos previos
Usted ha adquirido el acceso de administración al CUPS web UI como se describe en Sección 9.3.1,
“Adquirir acceso de administración a la interfaz web de CUPS”.
Procedimiento
Vaya al menú Printers y haga clic en Maintenance → Print Test Page.
9.7. CONFIGURACIÓN DE LAS OPCIONES DE IMPRESIÓN MEDIANTE

LA INTERFAZ WEB DE CUPS
Esta sección describe cómo configurar las opciones de impresión más comunes, como el tamaño y el
tipo de soporte, la calidad de impresión o el modo de color, en el CUPS web UI.
Requisitos previos
Usted ha adquirido el acceso de administración al CUPS web UI como se describe en Sección 9.3.1,
“Adquirir acceso de administración a la interfaz web de CUPS”.
Procedimiento
1. Vaya al menú Administration y haga clic en Maintenance → Set Default Options.
179
2. Configure las opciones de impresión.
9.8. INSTALACIÓN DE CERTIFICADOS PARA UN SERVIDOR DE

IMPRESIÓN
Para instalar certificados para un servidor de impresión, puede elegir una de las siguientes opciones:
Instalación automática mediante un certificado autofirmado
Instalación manual utilizando un certificado y una clave privada generados por una Autoridad de
Certificación
Requisitos previos
Para el demonio cupsd en el servidor:
1. Establezca la siguiente directiva en el archivo /etc/cups/cupsd.conf:

Encryption Required
2. Reinicie el servicio de tazas:
$ sudo systemctl restart cups
Automatic installation using a self-signed certificate
180
Con esta opción, CUPS genera el certificado y la clave automáticamente.
NOTA
El certificado autofirmado no proporciona una seguridad tan fuerte como los certificados
generados por las Autoridades de Certificación de Gestión de Identidades (IdM),
Directorio Activo (AD) o Red Hat Certificate System (RHCS), pero puede ser utilizado
para servidores de impresión ubicados dentro de una red local segura.
Procedimiento
1. Para acceder a la interfaz web de CUPS, abra su navegador y vaya a https://<server>:631

donde <server> es la dirección IP o el nombre del servidor.
NOTA
Cuando CUPS se conecta a un sistema por primera vez, el navegador muestra

una advertencia acerca de que el certificado autofirmado es un riesgo potencial
para la seguridad.
2. Para confirmar que es seguro proceder, haga clic en Advanced… .
3. Haga clic en Accept the Risk and Continue.
181
CUPS comienza ahora a utilizar el certificado autogenerado y la clave.
NOTA
Cuando accede a la interfaz web de CUPS después de la instalación automática, el

navegador muestra un icono de advertencia en la barra de direcciones. Esto se debe a
que ha añadido la excepción de seguridad confirmando la advertencia de riesgo de
seguridad. Si desea eliminar este icono de advertencia de forma permanente, realice la
instalación manual con un certificado y una clave privada generados por una Autoridad de
Certificación.
Manual installation using a certificate and a private key generated by a Certification

Authority
Para los servidores de impresión situados en una red pública o para eliminar permanentemente la
advertencia en el navegador, importe el certificado y la clave manualmente.
Requisitos previos
Tiene archivos de certificados y claves privadas generados por IdM, AD o por las Autoridades de
Certificación RHCS.
Procedimiento
1. Copie los archivos .crt y .key en el directorio /etc/cups/ssl del sistema en el que desea utilizar la
interfaz web de CUPS.
2. Cambie el nombre de los archivos copiados a <hostname>.crt y <hostname>.key.

Sustituya <hostname> por el nombre del sistema al que desea conectar la interfaz web de
CUPS.
3. Establezca los siguientes permisos para los archivos renombrados:
# chmod 644 /etc/cups/ssl/<hostname>.crt
182
# chmod 644 /etc/cups/ssl/<hostname>.key
# chown root:root /etc/cups/ssl/<hostname>.crt
# chown root:root /etc/cups/ssl/<hostname>.key
4. Reinicie el servicio de tazas:
# systemctl restart cupsd
9.9. USO DE SAMBA PARA IMPRIMIR EN UN SERVIDOR DE IMPRESIÓN

DE WINDOWS CON AUTENTICACIÓN KERBEROS
Con la envoltura samba-krb5-printing, los usuarios de Active Directory (AD) que han iniciado sesión en
Red Hat Enterprise Linux pueden autenticarse en Active Directory (AD) utilizando Kerberos y luego
imprimir en un servidor de impresión CUPS local que reenvía el trabajo de impresión a un servidor de
impresión Windows.
El beneficio de esta configuración es que el administrador de CUPS en Red Hat Enterprise Linux no
necesita almacenar un nombre de usuario y contraseña fijos en la configuración. CUPS se autentifica en
AD con el ticket Kerberos del usuario que envía el trabajo de impresión.
Esta sección describe cómo configurar CUPS para este escenario.
NOTA
Red Hat sólo soporta el envío de trabajos de impresión a CUPS desde su sistema local, y
no para volver a compartir una impresora en un servidor de impresión Samba.
Requisitos previos
La impresora que desea añadir a la instancia local de CUPS está compartida en un servidor de
impresión de AD.
Usted se unió al host de Red Hat Enterprise Linux como miembro del AD. Para más detalles,
consulte Sección 3.5.1, “Unir un sistema RHEL a un dominio AD” .
CUPS está instalado en Red Hat Enterprise Linux y el servicio cups está funcionando. Para más
detalles, consulte Sección 9.1, “Activación del servicio de copas” .
El archivo PostScript Printer Description (PPD) de la impresora se almacena en el directorio

/usr/share/cups/model/.
Procedimiento
1. Instale los paquetes samba-krb5-printing, samba-client, y krb5-workstation:
# yum install samba-krb5-printing samba-client krb5-workstation
2. Opcional: Autenticarse como administrador de dominio y mostrar la lista de impresoras que se

comparten en el servidor de impresión de Windows:
# kinit administrator@AD_KERBEROS_REALM
# smbclient -L win_print_srv.ad.example.com -k
183

--------- ---- -------
...
Example Printer Example
...
3. Opcional: Muestra la lista de modelos CUPS para identificar el nombre PPD de su impresora:
lpinfo -m
...
samsung.ppd Samsung M267x 287x Series PXL
...
Necesitará el nombre del archivo PPD cuando añada la impresora en el siguiente paso.
4. Añade la impresora a CUPS:
# lpadmin -p "example_printer" -v smb://win_print_srv.ad.example.com/Example -m

samsung.ppd -o auth-info-required=negotiate -E
El comando utiliza las siguientes opciones:
-p printer_name establece el nombre de la impresora en CUPS.
-v URI_to_Windows_printer establece el URI de la impresora de Windows. Utilice el

siguiente formato smb://host_name/printer_share_name.
-m PPD_file establece el archivo PPD que utiliza la impresora.
-o auth-info-required=negotiate configura CUPS para que utilice la autenticación Kerberos

cuando reenvíe los trabajos de impresión al servidor remoto.
-E habilita la impresora y CUPS acepta trabajos para la impresora.
1. Inicie sesión en el host de Red Hat Enterprise Linux como usuario de dominio de AD.
2. Autenticarse como un usuario del dominio AD:
# kinit domain_user_name@AD_KERBEROS_REALM
3. Imprime un archivo en la impresora que has añadido al servidor de impresión local CUPS:
# lp -d example_printer file
9.10. TRABAJAR CON LOS REGISTROS DE CUPS
9.10.1. Tipos de registros CUPS

CUPS proporciona tres tipos diferentes de registros:
Registro de errores - Almacena mensajes de error, advertencias y mensajes de depuración.
Registro de acceso - Almacena mensajes sobre el número de veces que se ha accedido a los
184
Registro de acceso - Almacena mensajes sobre el número de veces que se ha accedido a los
clientes CUPS y a la interfaz web.
Registro de páginas - Almacena mensajes sobre el número total de páginas impresas para cada
trabajo de impresión.
En Red Hat Enterprise Linux 8, los tres tipos se registran de forma centralizada en systemd-journald
junto con los registros de otros programas.

AVISO
En Red Hat Enterprise Linux 8, los registros ya no se almacenan en archivos

específicos dentro del directorio /var/log/cups, que se utilizaba en Red Hat
Enterprise Linux 7.
9.10.2. Acceso a los registros de CUPS

Esta sección describe cómo acceder:
Todos los registros de CUPS
Registros de CUPS para un trabajo de impresión específico
Registros CUPS en un plazo determinado
9.10.2.1. Acceso a todos los registros de CUPS
Procedimiento
Filtrar los registros de CUPS desde systemd-journald:
$ journalctl -u cups
9.10.2.2. Acceso a los registros de CUPS para un trabajo de impresión específico
Procedimiento
Filtrar los registros de un trabajo de impresión específico:
$ journalctl -u cups JID=N
Donde N es el número de un trabajo de impresión.
9.10.2.3. Acceder a los registros de CUPS por un periodo de tiempo específico
Procedimiento
Filtra los registros dentro del marco de tiempo especificado:
185
$ journalctl -u cups --since=YYY-MM-DD --until=YYY-MM-DD
Donde YYYY es el año, MM es el mes y DD es el día.
9.10.2.4. Información relacionada
Para obtener información más detallada sobre el acceso a los registros de CUPS, consulte la página man
journalctl.
9.10.3. Configuración de la ubicación del registro de CUPS

Esta sección describe cómo configurar la ubicación de los registros de CUPS.
En Red Hat Enterprise Linux 8, los registros de CUPS se registran por defecto en systemd-journald, lo
que se asegura mediante la siguiente configuración por defecto en el archivo /etc/cups/cups-files.conf:
ErrorLog syslog
IMPORTANTE
Red Hat recomienda mantener la ubicación por defecto de los registros de CUPS.
Si desea enviar los registros a una ubicación diferente, debe cambiar la configuración en el archivo
/etc/cups/cups-files.conf de la siguiente manera:
ErrorLog <su_ubicación_requerida>

AVISO
Si cambia la ubicación por defecto del registro de CUPS, puede experimentar un

comportamiento inesperado o problemas con SELinux.
contexto: configuración-impresión
contexto: Desplegando-diferentes-tipos-de-servidores
186

Despliegue de Diferentes Tipos de Servidores

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Despliegue de Diferentes Tipos de Servidores

Uploaded by

Copyright:

Available Formats

Red Hat Enterprise Linux 8

Despliegue de diferentes tipos de servidores

Guía para la implantación de diferentes tipos de servidores en Red Hat Enterprise

Last Updated: 2021-02-28

Enter your first name here. Enter your surname here.

Java ® is a registered trademark of Oracle and/or its affiliates.

All other trademarks are the property of their respective owners.

Inconvenientes de utilizar el back end de rid 46

3.15.3. Compartir manualmente impresoras específicas 83

4.6.1. El archivo de configuración /etc/exports 108

8.2.2.1. Mejora de la seguridad de la instalación de MariaDB 141

8.3.4.3.4. Recursos adicionales 163

HACER QUE EL CÓDIGO ABIERTO SEA MÁS INCLUSIVO

PROPORCIONAR COMENTARIOS SOBRE LA

Para comentarios sencillos sobre pasajes concretos:

1. Asegúrese de que está viendo la documentación en el formato Multi-page HTML. Además,

4. Siga las instrucciones mostradas.

Para enviar comentarios más complejos, cree un ticket de Bugzilla:

1. Vaya al sitio web de Bugzilla.

2. Como componente, utilice Documentation.

3. Rellene el campo Description con su sugerencia de mejora. Incluya un enlace a la(s)

4. Haga clic en Submit Bug.

CAPÍTULO 1. CONFIGURACIÓN DEL SERVIDOR WEB APACHE

1.1. INTRODUCCIÓN AL SERVIDOR WEB APACHE HTTP

1.1.1. Cambios notables en el servidor HTTP Apache

Las nuevas características incluyen:

se admite la activación de sockets systemd. Consulte la página de manual httpd.socket(8) para

Se han añadido varios módulos nuevos:

mod_proxy_hcheck - un módulo de comprobación de la salud del proxy

mod_proxy_uwsgi - un proxy de la Interfaz del Servidor Web (WSGI)

mod_md - un servicio de certificados SSL/TLS de protocolo ACME

Los siguientes módulos ahora se cargan por defecto:

Se ha añadido un nuevo subpaquete, httpd-filesystem, que contiene la disposición básica de

Se ha introducido el soporte de servicios instanciados, httpd@.service. Consulte la página de

Se ha introducido el soporte de servicios instanciados, httpd@.service. Consulte la página de

El aprovisionamiento y la renovación automatizados de certificados TLS mediante el protocolo

Ahora se admite una nueva directiva ListenFree en el archivo /etc/httpd/conf/httpd.conf.

Para más detalles sobre ListenFree, consulte la siguiente tabla:

Tabla 1.1. Sintaxis, estado y módulos de la directiva ListenFree

Sintaxis Estado Módulos

ListenFree [dirección MPM evento, trabajador, prefork,

Otros cambios notables son:

Se han eliminado los siguientes módulos:

El archivo /etc/sysconfig/httpd ya no es una interfaz compatible para establecer variables de

El módulo mod_auth_kerb ha sido sustituido por el módulo mod_auth_gssapi.

1.1.2. Actualización de la configuración

Si se utiliza /etc/sysconfig/httpd para establecer variables de entorno, cree un archivo drop-in

Puede comprobar la configuración en busca de posibles errores utilizando el siguiente comando:

1.2. LOS ARCHIVOS DE CONFIGURACIÓN DE APACHE

Tabla 1.2. Los archivos de configuración del servicio httpd

/etc/httpd/conf/httpd.conf El archivo de configuración principal.

/etc/httpd/conf.d/ Un directorio auxiliar para los archivos de

/etc/httpd/conf.modules.d/ Un directorio auxiliar para los archivos de

1.3. GESTIÓN DEL SERVICIO HTTPD

El servidor HTTP Apache está instalado.

Para iniciar el servicio httpd, introduzca:

# systemctl start httpd

Para detener el servicio httpd, introduzca:

# systemctl stop httpd

Para reiniciar el servicio httpd, introduzca:

# systemctl restart httpd

1.4. CONFIGURACIÓN DE UN SERVIDOR HTTP APACHE DE UNA SOLA

1. Instale el paquete httpd: