Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Despliegue de diferentes tipos de servidores

Red Hat Enterprise Linux 8

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

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.

Hacer que el código abierto sea más inclusivo
Copiar enlace

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.

Proporcionar comentarios sobre la documentación de Red Hat
Copiar enlace

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.

Capítulo 1. Configuración del servidor web Apache HTTP
Copiar enlace

1.1. Introducción al servidor web Apache HTTP
Copiar enlace

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
Copiar enlace

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 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:

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

    ListenFree [dirección IP:]número de puerto [protocolo]

    MPM

    evento, trabajador, prefork, mpm_winnt, mpm_netware, mpmt_os2

Otros cambios notables son:

  • Se han eliminado los siguientes módulos:

  • 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.

  • 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
Copiar enlace

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
Copiar enlace

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”.

Expand
Tabla 1.2. Los archivos de configuración del servicio httpd
RutaDescripció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.

/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
Copiar enlace

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
Copiar enlace

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 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
Copiar enlace

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:

    1. 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>
    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: 

    # firewall-cmd --permanent --add-port=80/tcp
# firewall-cmd --reload

  7. Habilite e inicie el servicio httpd: 

    # systemctl enable --now httpd

Pasos de verificación

  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.

Recursos adicionales

1.6. Configuración del cifrado TLS en un servidor HTTP Apache
Copiar enlace

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
Copiar enlace

Esta sección describe cómo activar el cifrado TLS en un servidor HTTP Apache para el dominio example.com.

Requisitos previos

  • El servidor HTTP Apache está instalado y funcionando.

  • 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>:

    1. 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.

    2. 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

    3. 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
# firewall-cmd --reload

  5. Reinicie el servicio httpd: 

    # systemctl restart httpd
    Nota

    Si protegió el archivo de clave privada con una contraseña, deberá introducirla cada vez que se inicie el servicio httpd.

Pasos de verificación

  • Utilice un navegador y conéctese a https://example.com.

Recursos adicionales

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

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

  2. Reinicie el servicio httpd: 

    # systemctl restart httpd

Pasos de verificación

  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
  3. Opcional: Repita el comando para otras versiones del protocolo TLS.

Recursos adicionales

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.

  2. Reinicie el servicio httpd: 

    # systemctl restart httpd

Pasos de verificación

  1. Para mostrar la lista de cifrados que soporta el servidor HTTP Apache:

    1. Instale el paquete nmap: 

      # yum install nmap

    2. Utiliza la utilidad nmap para mostrar los cifrados soportados: 

      # nmap --script ssl-enum-ciphers -p 443 example.com
...
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
...

Recursos adicionales

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 /var/www/html/Example/.

  2. Reinicie el servicio httpd: 

    # systemctl restart httpd

Pasos de verificación

  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 /var/www/html/Example/.

Recursos adicionales

1.8. Instalación del manual del servidor HTTP Apache
Copiar enlace

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

  • El servidor HTTP Apache está instalado y funcionando.

Procedimiento

  1. Instale el paquete httpd-manual: 

    # yum install httpd-manual

  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>

  3. Reinicie el servicio httpd: 

    # systemctl restart httpd

Pasos de verificación

  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
Copiar enlace

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
Copiar enlace

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
Copiar enlace

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: 

# 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.

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:

    1. 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.

    2. Exporte la clave privada del archivo PKCS #12: 

      # openssl pkcs12 -in /etc/pki/tls/private/export.p12 -out /etc/pki/tls/private/server.key -nocerts -nodes
Enter Import Password: password
MAC verified OK

    3. 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.

Recursos adicionales

  • 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
Copiar enlace

  • 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.
  • 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.

Capítulo 2. Instalación y configuración de NGINX
Copiar enlace

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
Copiar enlace

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

  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}
# firewall-cmd --reload

  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.

Pasos de verificación

  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

Recursos adicionales

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:

    1. 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.

    2. Añade un bloque similar server para el dominio example.com al bloque http: 

      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.

    3. 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

Pasos de verificación

  1. Cree un archivo de ejemplo diferente en la raíz de documentos de cada host virtual: 

    # 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
Copiar enlace

Esta sección describe cómo habilitar el cifrado TLS en un servidor web NGINX para el dominio example.com.

Requisitos previos

  • NGINX se instala como se describe en Sección 2.1, “Instalación y preparación de NGINX”.

  • 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: 

    # 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.

  3. Reinicie el servicio nginx: 

    # systemctl restart nginx

Pasos de verificación

  • Utilice un navegador y conéctese a https://example.com

2.4. Configurar NGINX como proxy inverso para el tráfico HTTP
Copiar enlace

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

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 https://example.com.

  2. Establezca el parámetro booleano httpd_can_network_connect SELinux en 1 para configurar que SELinux permita a NGINX reenviar el tráfico: 

    # setsebool -P httpd_can_network_connect 1

  3. Reinicie el servicio nginx: 

    # systemctl restart nginx

Pasos de verificación

  • Utilice un navegador y conéctese a http://host_name/example y se muestra el contenido de https://example.com.

2.5. Configuración de NGINX como equilibrador de carga HTTP
Copiar enlace

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:

    • 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.

  2. Reinicie el servicio nginx: 

    # systemctl restart nginx

2.6. Recursos adicionales
Copiar enlace

  • 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.

Capítulo 3. Uso de Samba como servidor
Copiar enlace

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
Copiar enlace

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

3.1.1. Los servicios de Samba
Copiar enlace

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.

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
Copiar enlace

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, establezca security = 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, configure security = 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, configure security = user
En este modo, Samba autentifica a los usuarios en una base de datos local o LDAP.
En un miembro del dominio NT4, configure security = 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”.

Recursos adicionales

  • Consulte la descripción del parámetro security en la página de manual smb.conf(5).

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.

3.1.4. Editar la configuración de Samba de forma guardada
Copiar enlace

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

3.2. Verificación de la configuración de Samba
Copiar enlace

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.

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.

  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
Copiar enlace

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
Copiar enlace

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:

  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: 

    # firewall-cmd --permanent --add-port={139/tcp,445/tcp}
# firewall-cmd --reload

  7. Habilite e inicie el servicio smb: 

    # systemctl enable --now smb

Recursos adicionales

  • 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
Copiar enlace

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
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
Copiar enlace

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:

Expand
Parte traseraCaso 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
Copiar enlace

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.

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
Copiar enlace

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.

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: 

idmap config * : backend = tdb
idmap config * : range = 10000-999999

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
idmap config * : range = 10000-999999

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
Copiar enlace

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: 

idmap config * : backend = tdb
idmap config * : range = 10000-999999

Recursos adicionales

3.4.4. Utilización del back end de mapeo de ID de anuncios
Copiar enlace

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 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:

Expand
Nombre del atributo ADTipo de objetoAsignado a

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 [a]

Usuario

Ruta de acceso al directorio principal del usuario

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
  • Has instalado Samba.
  • La configuración de Samba, excepto la asignación de ID, existe en el archivo /etc/samba/smb.conf.

Procedimiento

  1. Edite la sección [global] en el archivo /etc/samba/smb.conf:

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

      idmap config * : backend = tdb
idmap config * : range = 10000-999999

    2. Habilite el back end de asignación de ID de ad para el dominio de AD: 

      idmap config DOMAIN: backend = ad

    3. 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”.

    4. Establezca que Samba utilice el esquema RFC 2307 cuando lea los atributos de AD: 

      idmap config DOMAIN: schema_mode = rfc2307

    5. 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

    6. 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

  2. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  3. Recarga la configuración de Samba: 

    # smbcontrol all reload-config

Recursos adicionales

  • 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
Copiar enlace

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 duplicados en entornos multidominio si los objetos de diferentes dominios tienen el mismo RID.

Requisitos previos

  • Has instalado Samba.
  • La configuración de Samba, excepto la asignación de ID, existe en el archivo /etc/samba/smb.conf.

Procedimiento

  1. Edite la sección [global] en el archivo /etc/samba/smb.conf:

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

      idmap config * : backend = tdb
idmap config * : range = 10000-999999

    2. Habilite el back end de asignación de ID de rid para el dominio: 

      idmap config DOMAIN: backend = rid

    3. 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”.

    4. Establezca una ruta de acceso al shell y al directorio principal que se asignará a todos los usuarios asignados. Por ejemplo: 

      template shell = /bin/bash
template homedir = /home/%U

  2. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  3. Recarga la configuración de Samba: 

    # smbcontrol all reload-config

    Recursos adicionales

    • Sección 3.4.2, “The * default domain”
    • 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).
    • 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
Copiar enlace

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

  • Has instalado Samba.
  • La configuración de Samba, excepto la asignación de ID, existe en el archivo /etc/samba/smb.conf.

Procedimiento

  1. Edite la sección [global] en el archivo /etc/samba/smb.conf:

    1. Habilite el back end de mapeo de ID de autorid para el dominio por defecto *: 

      idmap config * : backend = autorid

    2. Establezca un rango lo suficientemente grande como para asignar IDs para todos los objetos existentes y futuros. Por ejemplo: 

      idmap config * : range = 10000-999999

      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.

    3. 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.

    4. Establezca una ruta de acceso al shell y al directorio principal que se asignará a todos los usuarios asignados. Por ejemplo: 

      template shell = /bin/bash
template homedir = /home/%U

    5. 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”.

  2. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  3. Recarga la configuración de Samba: 

    # smbcontrol all reload-config

Recursos adicionales

  • 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).
  • 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.5. Configuración de Samba como servidor miembro del dominio AD
Copiar enlace

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
Copiar enlace

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 /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”.

Pasos de verificación

  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: 

    # 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:

    1. En el miembro del dominio AD, obtenga un ticket para la entidad de crédito administrator@AD.EXAMPLE.COM: 

      # kinit administrator@AD.EXAMPLE.COM

    2. 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

Recursos adicionales

3.5.2. Uso del complemento de autorización local para MIT Kerberos
Copiar enlace

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 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
}

Recursos adicionales

  • Consulte la página de manual winbind_krb5_localauth(8).

3.6. Configuración de Samba en un miembro del dominio IdM
Copiar enlace

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.

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]:

  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)
...

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 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

Esta sección describe cómo instalar y configurar Samba en un cliente inscrito en un dominio IdM.

Requisitos previos

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:

 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:

  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

Pasos de verificación

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
lp_load_ex: changing to config backend registry

    Sharename       Type      Comment
    ---------       ----      -------
    example         Disk
    IPC$            IPC       IPC Service (Samba 4.12.3)
...

Recursos adicionales

  • 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).

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

    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

Pasos de verificación

  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
lp_load_ex: changing to config backend registry

    Sharename       Type      Comment
    ---------       ----      -------
    example         Disk
    IPC$            IPC       IPC Service (Samba 4.12.3)
...

3.6.5. Recursos adicionales
Copiar enlace

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 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
Copiar enlace

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:

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:

  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.

  5. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  6. Abra los puertos necesarios y recargue la configuración del cortafuegos mediante la utilidad firewall-cmd: 

    # firewall-cmd --permanent --add-service=samba
# firewall-cmd --reload

  7. Reinicie el servicio smb: 

    # systemctl restart smb

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.

Recursos adicionales

  • Para más detalles sobre los permisos, consulte las páginas de manual chown(1) y chmod(1).

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
  • 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).

  2. Reinicie el servicio smb: 

    # systemctl restart smb

  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:

      1. Conceda permisos de lectura, escritura y ejecución al grupo Domain Admins: 

        # setfacl -m group:"DOMAIN\Domain Admins":rwx /srv/samba/example/

      2. Concede permisos de lectura y ejecución al grupo Domain Users: 

        # setfacl -m group:"DOMAIN\Domain Users":r-x /srv/samba/example/

      3. 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:

    Expand
    PrincipalAcceda aSe aplica a

    Domain\N - Administradores de dominio

    Control total

    Esta carpeta, subcarpetas y archivos

    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 User\primary_group) [c]

    Ninguno

    Esta carpeta sólo

    CREATOR OWNER [d] [e]

    Control total

    Sólo subcarpetas y archivos

    CREATOR GROUP [e] [f]

    Ninguno

    Sólo subcarpetas y archivos

    [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.

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.

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: 

    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.

  2. Recarga la configuración de Samba: 

    # smbcontrol all reload-config

Recursos adicionales

  • 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
Copiar enlace

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 /etc/samba/smb.conf: 

    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.

  2. Recarga la configuración de Samba: 

    # smbcontrol all reload-config

Recursos adicionales

  • Para más detalles, consulte las descripciones de los parámetros en la página de manual smb.conf(5).

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
Copiar enlace

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
Copiar enlace

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

  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.

  2. Reinicie el servicio smb: 

    # systemctl restart smb

3.9.3. Añadir un recurso compartido que utiliza las ACL de Windows
Copiar enlace

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/

  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. 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

  5. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  6. Abra los puertos necesarios y recargue la configuración del cortafuegos mediante la utilidad firewall-cmd: 

    # firewall-cmd --permanent --add-service=samba
# firewall-cmd --reload

  7. Reinicie el servicio smb: 

    # systemctl restart smb

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.

Recursos adicionales

3.10. Gestión de ACLs en un recurso compartido SMB mediante smbcacls
Copiar enlace

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
Copiar enlace

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, 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:

Expand
Tabla 3.1. Configuración de la herencia
ValorDescripciónMapas 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:

Expand
Tabla 3.2. Combinaciones de ajustes de la herencia
Combinaciones de valoresCorresponde 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:

  • 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:

    Expand
    Tabla 3.3. Permisos de Windows y su correspondiente valor smbcacls en formato hexadecimal
    Permisos de WindowsValores 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:

    Expand
    Tabla 3.4. Alias smbcacls existentes y su correspondiente permiso de Windows
    smbcacls aliasMapas para el permiso de Windows

    R

    Leer

    READ

    Leer & ejecutar

    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
Copiar enlace

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"
Enter DOMAIN\administrator's password:
REVISION:1
CONTROL:SR|PD|DI|DP
OWNER:AD\Administrators
GROUP:AD\Domain Users
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
Copiar enlace

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
Copiar enlace

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: 

# 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

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
Copiar enlace

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:

    1. Crea el directorio: 

      # mkdir -p /var/lib/samba/usershares/

    2. Establezca los permisos de escritura para el grupo example: 

      # chgrp example /var/lib/samba/usershares/
# chmod 1770 /var/lib/samba/usershares/
    3. 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]:

    1. 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/

    2. 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.

    3. 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).

  4. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  5. Recarga la configuración de Samba: 

    # smbcontrol all reload-config

    Ahora los usuarios pueden crear acciones de usuario.

3.11.2. Añadir una cuota de usuario
Copiar enlace

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.

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
Copiar enlace

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”.

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

  • Se configura un recurso compartido de usuario en el servidor Samba.

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
Copiar enlace

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

  • Se configura un recurso compartido de usuario en el servidor Samba.

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
Copiar enlace

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

  • Se configura un recurso compartido de usuario en el servidor Samba.

Procedimiento

$ net usershare delete share_name

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.

3.12.1. Habilitar el acceso de invitados a un recurso compartido
Copiar enlace

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:

    1. Si este es el primer recurso compartido para invitados que configuras en este servidor:

      1. 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.

      2. 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.

    2. Añade la configuración de guest ok = yes a la sección de acciones de [example]: 

      [example]
        ...
        guest ok = yes

  2. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  3. Recarga la configuración de Samba: 

    # smbcontrol all reload-config

3.13. Configuración de Samba para clientes de macOS
Copiar enlace

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.

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 compartido, añada el siguiente ajuste a la configuración del recurso compartido en el archivo /etc/samba/smb.conf: 

    fruta:máquina del tiempo = sí

  3. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  4. Recarga la configuración de Samba: 

    # smbcontrol all reload-config

Recursos adicionales

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
Copiar enlace

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: 

smb: \N > help

Para mostrar la ayuda de un comando específico, introduzca: 

smb: \N > help command_name

Recursos adicionales

  • 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
Copiar enlace

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
Copiar enlace

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 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
Copiar enlace

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:

3.15.1. El servicio Samba spoolssd
Copiar enlace

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

  1. Edite la sección [global] en el archivo /etc/samba/smb.conf:

    1. Añade los siguientes parámetros: 

      rpc_server:spoolss = external
rpc_daemon:spoolssd = fork

    2. Opcionalmente, puede establecer los siguientes parámetros:

      Expand
      ParámetroPor defectoDescripción

      spoolssd:prefork_min_children

      5

      Número mínimo de procesos hijos

      spoolssd:prefork_max_children

      25

      Número máximo de procesos hijos

      spoolssd:prefork_spawn_rate

      5

      Samba bifurca el número de nuevos procesos hijos establecidos en este parámetro, hasta el valor establecido en spoolssd:prefork_max_children, si se establece una nueva conexión

      spoolssd:prefork_max_allowed_clients

      100

      Número de clientes a los que sirve un proceso infantil

      spoolssd:prefork_child_min_life

      60

      Duración mínima de un proceso hijo en segundos. 60 segundos es el mínimo.

  2. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  3. Reinicie el servicio smb: 

    # systemctl restart smb

    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
Copiar enlace

Esta sección explica cómo habilitar el soporte del servidor de impresión en Samba.

Procedimiento

  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.

  2. Edite el archivo /etc/samba/smb.conf:

    1. 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

    2. 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.

  3. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  4. Abra los puertos necesarios y recargue la configuración del cortafuegos mediante la utilidad firewall-cmd: 

    # firewall-cmd --permanent --add-service=samba
# firewall-cmd --reload

  5. Reinicie el servicio smb: 

    # systemctl restart smb

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
Copiar enlace

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.

Requisitos previos

  • Samba está configurado como servidor de impresión

Procedimiento

  1. Edite el archivo /etc/samba/smb.conf:

    1. En la sección [global], desactive el uso compartido automático de la impresora mediante la configuración: 

      cargar impresoras = no

    2. 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].

  2. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  3. Recarga la configuración de Samba: 

    # smbcontrol all reload-config

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
Copiar enlace

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:

    1. Inicie el instalador.
    2. Copie los archivos de la carpeta temporal a una nueva ubicación.
    3. 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.

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 "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
Successfully granted rights.
    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$
Copiar enlace

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.

  3. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  4. Recargar la configuración de Samba 

    # smbcontrol all reload-config

  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 "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
Successfully granted rights.

  7. Si ejecuta SELinux en modo enforcing, establezca el contexto samba_share_t en el directorio: 

    # 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:

      Expand
      PrincipalAcceda aSolicitar a

      CREATOR OWNER

      Control total

      Sólo subcarpetas y archivos

      Authenticated Users

      Leer & ejecutar, Listar el contenido de la carpeta, Leer

      Esta carpeta, subcarpetas y archivos

      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.

Recursos adicionales

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 documentación de Windows.

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.

    samba create new GPO
  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.

    samba select printer GPO group

  7. En la parte derecha de la ventana, haga doble clic en Point and Print Restriction para editar la política:

    1. Habilite la política y configure las siguientes opciones:

      1. 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.

      2. En las dos casillas de Security Prompts, seleccione Do not show warning or elevation prompt.

        samba GPO point and print
    2. Haga clic en Aceptar.

  8. Haga doble clic en Package Point and Print - Approved servers para editar la política:

    1. Habilite la política y haga clic en el botón Show.

    2. Introduzca el FQDN del servidor de impresión Samba.

      samba GPO approved servers
    3. 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.

Recursos adicionales

  • 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
Copiar enlace

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 documentación de Windows.

3.17. Ajuste del rendimiento de un servidor Samba
Copiar enlace

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
Copiar enlace

Cada nueva versión de SMB añade funciones y mejora el rendimiento del protocolo. Los recientes 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 /etc/samba/smb.conf.

  2. Recargar la configuración de Samba 

    # smbcontrol all reload-config

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 smb.conf(5).

  3. Verifique el archivo /etc/samba/smb.conf: 

    # testparm

  4. Recarga la configuración de Samba: 

    # smbcontrol all reload-config

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
Copiar enlace

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.

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.

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.

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

  2. Reinicie el servicio smb: 

    # systemctl restart smb

Recursos adicionales

  • 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
Copiar enlace

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
Copiar enlace

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 que desea unirse a la sección [global] en el archivo /etc/samba/smb.conf.

  3. Verifique 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.

Recursos adicionales

3.19.2. Uso del comando net rpc rights
Copiar enlace

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"
Enter DOMAIN\administrator's password:
     SeMachineAccountPrivilege  Add machines to domain
      SeTakeOwnershipPrivilege  Take ownership of files or other objects
             SeBackupPrivilege  Back up files and directories
            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 "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
Successfully granted rights.
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 "DOMAIN\administrator"
Enter DOMAIN\administrator's password:
Successfully revoked rights.

3.19.3. Utilizando el comando net rpc share
Copiar enlace

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
Enter DOMAIN\administrator's password:
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 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
Copiar enlace

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 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
Copiar enlace

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

  • El paquete samba-client está instalado.
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'
Enter DOMAIN\administrators password:
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'
Enter DOMAIN\administrators password:
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.

Recursos adicionales

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
Copiar enlace

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.

samba regedit

Requisitos previos

  • El paquete samba-client está instalado.

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
Copiar enlace

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

# smbcontrol all reload-config

Recursos adicionales

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
Copiar enlace

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: 

      [root@server ~]# smbpasswd -x user_name
Deleted user user_name.

Recursos adicionales

Para más detalles, consulte la página de manual smbpasswd(8).

3.19.9. Uso de la utilidad smbstatus
Copiar enlace

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

Recursos adicionales

Para más detalles, consulte la página de manual smbstatus(1).

3.19.10. Uso de la utilidad smbtar
Copiar enlace

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

  • El paquete samba-client está instalado.

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

Recursos adicionales

Para más detalles, consulte la página de manual smbtar(1).

3.19.11. Uso de la utilidad wbinfo
Copiar enlace

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: 

    # 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

Recursos adicionales

Para más detalles, consulte la página de manual wbinfo(1).

Capítulo 4. Exportación de recursos compartidos NFS
Copiar enlace

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
Copiar enlace

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
Copiar enlace

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 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
Copiar enlace

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
Copiar enlace

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 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.

Recursos adicionales

4.5. Formatos de nombres de host NFS
Copiar enlace

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:

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
Copiar enlace

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
Copiar enlace

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)

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.
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
Copiar enlace

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 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.

Recursos adicionales

  • 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
Copiar enlace

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. Alternativamente, es posible especificar reglas de control de acceso para cada uno de los demonios RPC de NFS.

Recursos adicionales

  • 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
Copiar enlace

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
Copiar enlace

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

Recursos adicionales

4.10. Solución de problemas de NFS y rpcbind
Copiar enlace

Debido a que el servicio rpcbind proporciona la coordinación entre los servicios RPC y los números de 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    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   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    3   udp  56691  nlockmgr
    100021    4   udp  56691  nlockmgr
    100021    1   tcp  46193  nlockmgr
    100021    3   tcp  46193  nlockmgr
    100021    4   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

Recursos adicionales

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: 

    #  systemctl restart nfs-server

    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.

  6. Confirme que los cambios han surtido efecto: 

    # rpcinfo -p

Recursos adicionales

4.12. Exportación de la cuota RPC a través de un cortafuegos
Copiar enlace

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)
Copiar enlace

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

  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: 

    # systemctl restart nfs-server

Recursos adicionales

4.14. Configuración de un servidor sólo NFSv4
Copiar enlace

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
Copiar enlace

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
Copiar enlace

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. Alternativamente, es posible especificar reglas de control de acceso para cada uno de los demonios RPC de NFS.

Recursos adicionales

  • 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
Copiar enlace

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: 

    # systemctl restart nfs-server

Los cambios surten efecto en cuanto se inicia o reinicia el servidor NFS.

4.14.4. Verificación de la configuración NFSv4-only
Copiar enlace

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: 

    # 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: 

    # netstat --listening --tcp --udp

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: 

    # netstat --listening --tcp --udp

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              [::]:*

Capítulo 5. Asegurar NFS
Copiar enlace

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
Copiar enlace

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.

Recursos adicionales

  • 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
Copiar enlace

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.

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

    • 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

Recursos adicionales

  • 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
Copiar enlace

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.

5.5. Permisos de archivos en exportaciones NFS montadas
Copiar enlace

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.

Capítulo 6. Habilitación de disposiciones SCSI pNFS en NFS
Copiar enlace

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
Copiar enlace

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
Copiar enlace

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”.

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
Copiar enlace

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
      Exclusive Access: 1
      Write Exclusive: 1
      Exclusive Access, all registrants: 1

Recursos adicionales

  • La página de manual sg_persist(8)

6.4. Configuración de pNFS SCSI en el servidor
Copiar enlace

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)

Recursos adicionales

6.5. Configuración de pNFS SCSI en el cliente
Copiar enlace

Este procedimiento configura un cliente NFS para montar una disposición SCSI pNFS.

Requisitos previos

Procedimiento

  • 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.

Recursos adicionales

6.6. Liberación de la reserva SCSI pNFS en el servidor
Copiar enlace

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
  Peripheral device type: disk
  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

    # sg_persist --out \
             --release \
             --param-rk=0x100000000000000 \
             --prout-type=6 \
             /dev/sda

  LIO-ORG   block_1           4.0
  Peripheral device type: disk

Recursos adicionales

  • La página de manual sg_persist(8)

6.7. Supervisión de la funcionalidad de los diseños SCSI de PNFS
Copiar enlace

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.

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 están realizando peticiones de E/S directamente a los dispositivos SCSI.

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.

Capítulo 7. Configuración del servidor proxy de caché Squid
Copiar enlace

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
Copiar enlace

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:

    1. 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.

    2. 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

    3. 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
acl Safe_ports port 80
acl Safe_ports port 443

      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.

    4. 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:

    1. Crear el directorio de la caché: 

      # mkdir -p path_to_cache_directory

    2. Configure los permisos para el directorio de la caché: 

      # chown squid:squid path_to_cache_directory

    3. 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: 

    # firewall-cmd --permanent --add-port=3128/tcp
# firewall-cmd --reload

  5. Habilite e inicie el servicio squid: 

    # systemctl enable --now squid

Pasos de verificación

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.

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

  • 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.
  • 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

  2. Edite el archivo /etc/squid/squid.conf:

    1. 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 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.

    2. 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.

    3. 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

    4. 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 número_de_puerto

    5. 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
acl Safe_ports port 80
acl Safe_ports port 443

      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 Safe_ports ACLs.

    6. 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:

    1. Crear el directorio de la caché: 

      # mkdir -p path_to_cache_directory

    2. Configure los permisos para el directorio de la caché: 

      # chown squid:squid path_to_cache_directory

    3. 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. 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

  5. Abra el puerto 3128 en el cortafuegos: 

    # firewall-cmd --permanent --add-port=3128/tcp
# firewall-cmd --reload

  6. Habilite e inicie el servicio squid: 

    # systemctl enable --now squid

Pasos de verificación

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 "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.

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

  • 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.
  • 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: 

    # 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
...

  7. Edite el archivo /etc/squid/squid.conf:

    1. 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.

    2. Añade la siguiente ACL y regla para configurar que Squid sólo permita a los usuarios autentificados utilizar el proxy: 

      acl kerb-auth proxy_auth REQUIRED
http_access allow kerb-auth
      Importante

      Especifique estos ajustes antes de la regla http_access deny all.

    3. 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

    4. 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

    5. 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
acl Safe_ports port 80
acl Safe_ports port 443

      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.

    6. 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.

  8. Si establece un directorio de caché diferente a /var/spool/squid/ en el parámetro cache_dir:

    1. Crear el directorio de la caché: 

      # mkdir -p path_to_cache_directory

    2. Configure los permisos para el directorio de la caché: 

      # chown squid:squid path_to_cache_directory

    3. 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.

  9. Abra el puerto 3128 en el cortafuegos: 

    # firewall-cmd --permanent --add-port=3128/tcp
# firewall-cmd --reload

  10. Habilite e inicie el servicio squid: 

    # systemctl enable --now squid

Pasos de verificación

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" --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: 

    Ficha: YIIFTAYGKwYBBQUCoIIFqDC...

7.4. Configuración de una lista de denegación de dominio en Squid
Copiar enlace

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

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

  • El paquete squid está instalado.

Procedimiento

  1. Edite el archivo /etc/squid/squid.conf:

    • 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):

    1. Abre el puerto en el firewall: 

      # firewall-cmd --permanent --add-port=port_number/tcp
# firewall-cmd --reload

    2. 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

      Si la utilidad semanage no está disponible en su sistema, instale el paquete policycoreutils-python-utils.

  3. Reinicie el servicio squid: 

    # systemctl restart squid

7.6. Recursos adicionales
Copiar enlace

  • 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.

Capítulo 8. Servidores de bases de datos
Copiar enlace

8.1. Introducción a los servidores de bases de datos
Copiar enlace

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
Copiar enlace

8.2.1. Introducción a MariaDB
Copiar enlace

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
Copiar enlace

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

  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
Copiar enlace

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
Copiar enlace

8.2.3.1. Configurar el servidor MariaDB para la red
Copiar enlace

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
Copiar enlace

Hay dos formas principales de hacer una copia de seguridad de los datos de una base de datos MariaDB:

  • 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
Copiar enlace

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
  • Copia de seguridad de varias bases de datos
  • Haga una copia de seguridad de todas las bases de datos

Procedimiento

  • Para hacer una copia de seguridad de una base de datos completa, ejecute 

    # mysqldump [options] db_name > backup-file.sql

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 ...]

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
Copiar enlace

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
Copiar enlace

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
Copiar enlace

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
Copiar enlace

Procedimiento

  • Para ver una lista de las opciones que soporta mysqldump, ejecute 

    $ mysqldump --help
8.2.4.1.8. Recursos adicionales
Copiar enlace

Para más información sobre la copia de seguridad lógica con mysqldumpconsulte la documentación de MariaDB.

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

    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.

Recursos adicionales

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
Copiar enlace

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.

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.

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/

  3. Inicie el servicio mariadb: 

    # systemctl start mariadb.service

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.

    Por ejemplo, para cambiar recursivamente la propiedad de los archivos al usuario y grupo mysql: 

    # chown -R mysql:mysql /var/lib/mysql/

  3. Inicie el servicio mariadb: 

    # systemctl start mariadb.service
8.2.4.3.3. Recursos adicionales
Copiar enlace

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
Copiar enlace

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: 

    # systemctl stop mariadb.service

  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

  5. Inicie el servicio mariadb: 

    # systemctl start mariadb.service

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.

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.

Recursos adicionales

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
Copiar enlace

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.

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
Copiar enlace

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.

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:

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.

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.0 (ya no es compatible)
    • MariaDB 10.1 (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

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: 

    # systemctl stop mariadb.service
  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: 

    # systemctl start mariadb.service

  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
Copiar enlace

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
Copiar enlace

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

Recursos adicionales

Para obtener información más detallada, consulte la documentación de la corriente ascendente:

8.2.6.2. Componentes para construir el clúster MariaDB Galera
Copiar enlace

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.

Recursos adicionales

Para obtener información más detallada, consulte la documentación de la corriente ascendente:

8.2.6.3. Despliegue del clúster MariaDB Galera
Copiar enlace

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:

  • 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.

    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.

Recursos adicionales

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
Copiar enlace

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.

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.

Recursos adicionales

8.2.6.5. Reinicio del clúster MariaDB Galera
Copiar enlace

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.

Recursos adicionales

Para más información, vea Cómo empezar con MariaDB Galera Cluster.

8.3. Uso de PostgreSQL
Copiar enlace

8.3.1. Introducción a PostgreSQL
Copiar enlace

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
Copiar enlace

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: 

    # 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
Copiar enlace

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
Copiar enlace

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
Copiar enlace

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.1. Realización de un volcado SQL
Copiar enlace

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

Para restaurar una base de datos a partir de un volcado SQL:

  1. Crear una nueva base de datos (dbname): 

    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
Copiar enlace

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
Copiar enlace

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

    o 

    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.

8.3.4.1.3. Ventajas y desventajas de un volcado SQL
Copiar enlace

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.

8.3.4.1.4. Recursos adicionales
Copiar enlace

Para más información sobre el volcado de SQL, consulte la documentación de PostgreSQL.

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: 

    # systemctl start postgresql.service

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 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.

Los enfoques alternativos a la copia de seguridad del sistema de archivos incluyen:

  • Una instantánea coherente del directorio de datos
  • La utilidad rsync
8.3.4.2.4. Recursos adicionales
Copiar enlace

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.1. Introducción al archivo continuo
Copiar enlace

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

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
Copiar enlace

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
Copiar enlace

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.

Para restaurar una base de datos utilizando una copia de seguridad continua:

  1. Detener el servidor: 

    # systemctl stop postgresql.service

  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: 

    # systemctl start postgresql.service

    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.

8.3.4.3.3. Ventajas y desventajas del archivo continuo
Copiar enlace

El archivo continuo tiene las siguientes ventajas en comparación con otros métodos de copia de seguridad de PostgreSQL:

  • 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 seguridad de PostgreSQL:

  • 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.
8.3.4.3.4. Recursos adicionales
Copiar enlace

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
Copiar enlace

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:

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:

  • 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
Copiar enlace

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: 

    # 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. 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. 

    # systemctl stop postgresql.service
  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: 

    # systemctl start postgresql.service

  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
Copiar enlace

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: 

    # systemctl start postgresql.service

  2. En el sistema RHEL 7, vuelque el contenido de todas las bases de datos en el archivo pgdump_file.sql: 

    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: 

    # 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.

  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: 

    # systemctl start postgresql.service

  10. En el sistema RHEL 8, importe los datos del archivo sql volcado: 

    su - postgres -c 'psql -f ~/pgdump_file.sql postgres'
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"'

Capítulo 9. Configuración de la impresión
Copiar enlace

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
Copiar enlace

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.3. Acceso y configuración de la interfaz web de CUPS
Copiar enlace

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.

    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/.

    cups ui intro

    Ya están disponibles todos los menús, excepto el de Administration.

    Si hace clic en el menú Administration, recibirá el mensaje Forbidden:

    forbidden message

    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
Copiar enlace

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 /etc/cups/cupsd.conf: 

    <Location /admin>
Allow from <your_ip_address>
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 archivo /etc/cups/cupsd.conf: 

    <Location /admin/conf>
AuthType Default
Require user @SYSTEM
Allow from <your_ip_address>
Order allow,deny
</Location>
    Nota

    Sustituya <your_ip_address> por la dirección IP real de su sistema.

  3. Para poder acceder a los archivos de registro en el CUPS web UIincluya lo siguiente en el archivo /etc/cups/cupsd.conf: 

    <Location /admin/log>
AuthType Default
Require user @SYSTEM
Allow from <your_ip_address>
Order allow,deny
</Location>
    Nota

    Sustituya <your_ip_address> por la dirección IP real de su sistema.

  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: 

    # 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.

Recursos adicionales

  • 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
Copiar enlace

Esta sección describe cómo añadir una nueva impresora utilizando la opción CUPS web user interface.

Requisitos previos

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

    add printer in cups ui 1
    add printer in cups ui 2

  3. Autenticación por nombre de usuario y contraseña:

    add printer in cups ui auth n
    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.

    add printer in cups ui 4 new

  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.

    add printer in cups ui 5 new

  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.

    add printer in cups ui 6 new

  7. Seleccione el fabricante de la impresora y haga clic en Continue.

    add printer in cups ui 7 new

    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.

    add printer in cups ui 8 new

  9. Una vez añadida la impresora, la siguiente ventana permite establecer las opciones de impresión por defecto.

    cups web ui set defaults n2

Tras hacer clic en Set Default Options, recibirá una confirmación de que la nueva impresora se ha añadido correctamente.

add printer in cups ui final confirm

9.5. Configurar una impresora en la interfaz web de CUPS
Copiar enlace

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

Procedimiento

  1. Haga clic en el menú Printers para ver las impresoras disponibles que puede configurar.

    conf printer cups 1

  2. Elija una impresora que desee configurar.

    conf printer cups 2

  3. Realice la tarea seleccionada utilizando uno de los menús disponibles:

    • Vaya a Maintenance para las tareas de mantenimiento.

      conf printer cups 3

    • Vaya a Administration para las tareas de administración.

      conf printer cups 4
    • 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.

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.

    printing test page cups web ui

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.

    cups web ui set defaults n1

  2. Configure las opciones de impresión.

    cups web ui set defaults n2

9.8. Instalación de certificados para un servidor de impresión
Copiar enlace

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

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…​.

    cups ui certificate warning

  3. Haga clic en Accept the Risk and Continue.

    cups ui certificate warning2

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
    • # 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

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

	Sharename       Type      Comment
	---------       ----      -------
	...
	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.

Pasos de verificación

  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
Copiar enlace

9.10.1. Tipos de registros CUPS
Copiar enlace

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 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
Copiar enlace

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
Copiar enlace

Procedimiento

  • Filtrar los registros de CUPS desde systemd-journald: 
$ journalctl -u cups

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.

Procedimiento

  • Filtra los registros dentro del marco de tiempo especificado: 
$ 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.3. Configuración de la ubicación del registro de CUPS
Copiar enlace

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

Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red HatVolver arriba