Linux Guía de Administración

Linux
GUÍA DE ADMINISTRACIÓN - 1
Fabian Mestre Socarras

Copyright © 2021 Aptiva Labs SAS
Los textos relacionados en este material hacen parte de la Propiedad

Intelectual de Aptiva Labs SAS en la República de Colombia y fuera de ella;
su distribución y uso está bajo la autorización de Aptiva Labs SAS. Este
material está cobijado bajo licencia Creative Commons CC-BY-NC-ND.
Red Hat Inc, Red Hat Enterprise Linux, sus logos y demás elementos
identificativos, están registrados en los Estados Unidos de América y otros
países.
Linux es una marca registra de Linus Torvalds en los Estados Unidos de

America y otros países.
XFS es una marca registrada de Silicon Graphics International Corp y

sus subsidiarias en los Estados Unidos de América y otros países.
PostgreSQL, Microsoft Windows Server, Oracle, Ubuntu, Debian,

CentOs, Ansible son marcas registradas de sus respectivos fabricantes.
Dedicatoria
Este libro está dedicado a Dios, fuente de todo conocimiento y fuente de
toda inspiración, quien me ha dado la capacidad intelectual para abordar
estas temáticas y poder compartirlas con otras personas.
Dedico esta obra a mi esposa Gina, por su respaldo y su motivación para

iniciar y terminar este libro.
A mi mamá, Elsy, por su esfuerzo y empeño para que sus hijos fueran
personas de bien. A mi papá, Neil, en la presencia de Dios, ejemplo de
resiliencia.
A mis hijas y sobrinas, el futuro de la familia.
Mi familia, mi respaldo.
Reconocimientos
Quiero agradecer a todos aquellos que me han acompañado en el

transcurrir profesional en cada una de las empresas donde he sido
colaborador, la compañía de cada uno de ellos ha sido para crecimiento y
formación del background que hoy me permite publicar esta obra.
Especial reconocimiento para Farid Boudez, Miguel Higuera, Jairo

Rodríguez, Fause Rizcala, Fabio Ramírez, Freddy Mosquera, Helmuth
Corzo, Edgard Polo y Gerardo Solorzano, quienes en varios momentos de la
vida han creído en mis calidades profesionales y me han confiado
responsabilidades importantes.
Gracias especiales a Juan Carlos Velez y Liliana Hoyos, por su cuidado y

oraciones durante tantos años.
Perfil del Lector
Este libro está dirigido a:
Administradores de Infraestructura de Tecnología de

Información que cuenten o proyecten su ecosistema tecnológico
con herramientas Linux.
Formadores de talento humano en Tecnologías de Información

cuyo foco está relacionado con la enseñanza de sistemas
operativos.
Integradores de Soluciones de Infraestructura que soporten sus

servicios sobre plataformas Linux.
Arquitectos de Tecnologías de Información responsables de la

operación tecnológica en empresas e instituciones en cualquier
sector.
Estudiantes que se forman para administrar plataformas de

Tecnologías de Información.
Acerca del Libro
Cada uno de los capítulos de este libro están organizados en función de
evidenciar el día a día de la administración de servidores Linux según las
mejores practicas de administración las cuales están definidas por los
fabricantes de software, en este caso Red Hat Inc, empresa que ha tomado la
batuta para sacar al mercado un sistema operativo que brinda la garantía para
que grandes despliegues de Infraestructura se ejecuten sobre él.
Si usted detalla la tabla de contenido de este libro podrá observar que

hay temas que no aparecen, temáticas que debe haber conocido el
Administrador de Infraestructura Tecnológica para entrar en los ítems que se
desarrollan en este libro, esas temáticas se encuentran en los cursos de
fundamentos del sistema operativo Linux.
Los laboratorios y actividades desarrolladas fueron desplegadas sobre la

herramienta Red Hat Enterprise Linux 8.3, Oracle Linux 8 y CentOS 8, sin
embargo, muchos de los temas son compartidos con otras distribuciones
Linux como Debian y Ubuntu Server, distribuciones que usan componentes
similares para interactuar con el Kernel de Linux. Usted podrá instalar y
suscribir una versión de Red Hat Enterprise Linux 8.3 registrándose en el
programa Red Hat Developer el cual le permite a través de una sola
suscripción registrar 16 sistemas entre físicos y virtuales (característica
disponible a la fecha en que se escribió esta documentación) y gozar de una
serie de funcionalidades que le ayudaran a conocer este sistema operativo y
adentrarse si así lo quiere en el mundo de desarrollo de software para Red
Hat Linux.
Se ha escogido realizar este material sobre Red Hat Linux debido a que
es un sistema operativo que a lo largo de los años ha brindado calidad y
estabilidad para montar sobre él diversos tipos de sistemas de información y
aplicaciones utilitarias. Esto no quiere decir que sistemas como Debian
Linux y Ubuntu Server no cuenten con estas características, el tema pasa a
un desarrollo comercial y de gestión de mercado corporativo dado a que las
empresas hoy día buscan implementar sus sistemas sobre ambientes que
tengan respaldo de fabricantes y en ese sentido tanto Red Hat como Oracle
han desarrollado una estrategia hace varios años. Oracle Linux se muestra
hoy día como un sistema interesante para desplegar plataformas
tecnológicas; es una buena idea indagar sobre que puede lograr con cada una
de estas empresas cuando despliegue sus sistemas operativos. Para el caso
de Ubuntu Server se visualiza un buen sistema sin embargo el despliegue
comercial del fabricante hoy día parece ir en una línea diferente a la que van
empresas como Oracle y Red Hat.
Este libro se mantiene en constante actualización, para ser notificado al

momento que exista una actualización, envíe un email con sus datos a
info@aptivalabs.com.
Acerca del Autor
Fabian Mestre Socarras es Consultor Estratégico en Tecnologías de la
Información y Linux Technical Writer. Ingeniero de Sistemas con Postgrado
en Dirección de Tecnologías de Información, con certificaciones RHCSA,
RHCVA, ITIL, Xorcom entre otras. Implementador de soluciones de
Telefonía IP y Almacenamiento de Datos sobre sistemas Linux. CEO &
Founder en Aptiva Labs SAS donde ha desarrollado actividades de
consultoría para empresas como Bioagricola del Llano SA ESP, Emdupar
SA ESP, Compgenioss SAS, Ejercito Nacional del Colombia, Electrocom
SAS, SINGS SAS, Thomas Processing Systems SAS, AppFuture SAS, entre
otras.
TABLA DE CONTENIDOS
INTRODUCCIÓN
HERRAMIENTAS BÁSICAS DE ADMINISTRACIÓN
AGRUPAMIENTO DE ARCHIVOS Y DIRECTORIOS
COMPRESIÓN Y DESCOMPRESIÓN DE DATOS
TRANSFERENCIA DE ARCHIVOS ENTRE SISTEMAS
MANEJO DE HORA Y FECHA
MANEJO DE LOCALES
ESTABLECIENDO EL MAPA DE TECLADO
PROGRAMACIÓN DE TAREAS
USANDO EL SERVICIO atd
TAREAS PROGRAMADAS CON crond
CRONS DEL SISTEMA
GESTIÓN DEL SISTEMA CON SYSTEMD
ADMINISTRANDO SERVICIOS CON SYSTEMD
HABILITANDO SERVICIOS DESDE SYSTEMD
ADMINISTRANDO TARGETS CON SYSTEMD
BOOT EN MODO DE RESCATE
BOOT EN MODO DE EMERGENCIA
APAGANDO, REINICIANDO Y SUSPENDIENDO EL SISTEMA
MODOS DE APAGADO
MODOS DE REINICIO – SUSPENSIÓN
MANEJO DE ARCHIVOS DE UNIDADES
CREANDO UN ARCHIVO DE UNIDAD
TUNING A SYSTEMD PARA MINIMIZAR EL TIEMPO DE BOOTEO
GESTIÓN DE PROCESOS
ESTADO DE LOS PROCESOS
VISUALIZANDO PROCESOS DEL SISTEMA
ENVÍO DE SEÑALES A LOS PROCESOS
ADMINISTRACIÓN DE LA PRIORIDAD
MONITOREANDO LA ACTIVIDAD DE LOS PROCESOS
ADMINISTRACIÓN DE JOBS
AJUSTES AL RENDIMIENTO DEL SISTEMA
GESTIÓN DEL KERNEL
ADMINISTRACIÓN DE MODULOS DEL KERNEL
DEPENDENCIA EN LOS MODULOS DEL KERNEL
MÓDULOS DEL KERNEL EN BLACKLIST
ESTABLECIENDO UN KERNEL POR DEFAULT PARA EL ARRANQUE
ENTENDIENDO EL PROCESO DE BOOT
GESTIÓN DE USUARIOS Y GRUPOS EN LINUX
GESTIÓN DE OPERACIONES SOBRE USUARIOS DEL SISTEMA
ADICIONANDO UN USUARIO ESTANDAR
ACTUALIZACION DE DATOS USUARIOS
ELIMINACION DE USUARIOS DEL SISTEMA
LINEA DE TIEMPO DE LOS PASSWORDS
OPERACIONES SOBRE GRUPOS DEL SISTEMA
SUPLANTACIÓN DE IDENTIDADES
DELEGANDO FUNCIONES DE ADMINISTRACIÓN - SUDO
LIMITANDO LA DELEGACIÓN DE FUNCIONES
PERMISOS ESTANDARES Y EXCEPCIONALES
ESTABLECIMIENTO DE PROPIETARIO Y GRUPO A UN RECURSO
CAMBIO DE GRUPO A UN ARCHIVO O DIRECTORIO
UTILIZANDO LETRAS Y SIMBOLOS PARA ASIGNACIÓN DE PERMISOS
LISTA DE CONTROL DE ACCESO - ACL’s
OPERACIONES COMUNES CON ACL’s
RECURSIVIDAD EN ACL`s
GESTÓN DE ACL’s POR DEFAULT
MASCARAS PARA LIMITAR ACL’s
PERMISOS ESPECIALES - SETUID, SETGID, STICKY
PERMISO SETUID
PERMISO SETGID
PERMISO STICKY
TROUBLESHOOTING CON ARCHIVOS DE LOG
TIPOS DE MENSAJES EN RSYSLOG
REGLAS DE SYSLOG
ROTACION DE LOS ARCHIVOS DE LOG
FORMATO DE LAS ENTRADAS EN LOS ARCHIVOS DE LOG
MONITORIZANDO REGISTROS CON JOURNALCTL
ADMINISTRACIÓN DEL NETWORKING
NOMBRANDO LAS INTERFACES DE RED DEL SISTEMA
GESTIÓN DE INTERFACES CON NETWORK MANAGER
CONFIGURACIÓN DE INTERFACES DE RED
CONFIGURANDO INTERFACES DE RED UTILIZANDO “nmtui”
CONFIGURANDO UNA CONEXIÓN POR DHCP CON NMCLI
DESACTIVANDO IPv6 SOBRE LA CONFIGURACIÓN DE LA INTERFAZ
CONFIGURANDO NOMBRE DE HOST
CAPTURA DE PAQUETES EN LA INTERFAZ DE RED – TCPDUMP
ORDEN DE CONSULTA DE DNS DEL NETWORK MANAGER
CONFIGURACIÓN DE RUTAS ESTÁTICAS
AGRUPAMIENTO DE INTERFACES DE RED – TEAMING
CREANDO INTERFACES TIPO BRIDGE
ADMINISTRACIÓN DE PAQUETES DE SOFTWARE
GESTIÓN DE REPOSITORIOS DE SOFTWARE
CREANDO UN REPOSITORIO CON MEDIOS LOCALES
GESTIÓN DE MODULOS Y STREAMS
EJERCICIO DE INSTALACIÓN DE MODULOS Y SUS STREAMS
DETALLANDO PAQUETES DE SOFTWARE
BUSCANDO, LISTANDO Y VISUALIZANDO INFORMACIÓN DE PAQUETES
GRUPOS DE PAQUETES
INSTALANDO PAQUETES DE SOFTWARE
ACTUALIZACIÓN DE PAQUETES y GRUPOS DE SOFTWARE
ACTUALIZACIONES AUTOMÁTICAS DE SOFTWARE
DESINSTALAR PAQUETES DE SOFTWARE
HISTORIAL EN LA GESTIÓN DE PAQUETES
RPM – GESTIÓN DE PAQUETES
CONFIGURACIÓN DE YUM/DNF
ADMINISTRACIÓN DE CAPAS DE SEGURIDAD
SELINUX COMO CAPA DE SEGURIDAD
MODOS DE OPERACIÓN Y CONFIGURACIÓN
MANEJO DE LABELS Y CONTEXTOS EN SELINUX
MANEJO DE VARIABLES BOOLEANAS
GESTIÓN DE USUARIOS CONFINADOS
TROUBLESHOOTING CON SELINUX
FILTRADO DE PAQUETES CON FIREWALLD
FIREWALLD, NFTABLES O IPTABLES
CONCEPTUALIZANDO A FIREWALLD
FAMILIARIZANDONOS CON INSTRUCCIONES EN FIREWALLD
FILTRANDO PAQUETES POR ORIGEN DE TRÁFICO
FIREWALLD EN PÁNICO
REGLAS ENRIQUECIDAS CON FIREWALLD
AUDITORIA EN SISTEMAS LINUX
REGLAS DE AUDITORIA CON AUDIT
REGLAS PERSISTENTES DE AUTORÍA
REGLAS PRECONFIGURADAS EN AUDIT
GENERACIÓN DE REPORTES CON AUDIT
HARDENING DEL SERVICIO SSH
AUTENTICACIÓN POR LLAVES DE USUARIO
CAMBIANDO EL PUERTO DE CONEXIÓN POR DEFAULT
DESACTIVANDO LOGIN DE USUARIO ROOT
PERMITIENDO LOGIN DE USUARIOS AUTORIZADOS
ADMINISTRACIÓN DEL STORAGE
PARTICIONAMIENTO DE DISPOSITIVOS
PARTICIONANDO UN DISPOSITIVO DE BLOQUE
ASIGNACIÓN DE FILESYSTEMS Y MONTAJE PERSISTENTE
CHEQUEO DE FILESYSTEMS TIPO XFS
ADMINISTRACIÓN DE SWAP
DECLARANDO UN ARCHIVO DE SWAP
DECLARANDO UNA PARTICIÓN TIPO SWAP
GESTIÓN DE LVM
CREANDO LA ESTRUCTURA LVM
EXTENDIENDO UN ESTRUCTURA LVM
REDUCIENDO LA ESTRUCTURA LVM – MOVIENDO DATA ENTRE PV’S
ELIMINANDO UNA ESTRUCTURA LVM
EXTENDIENDO LA SWAP BASADA EN LVM
CREANDO LV’s THIN
DESPLIEGUE DE RAID POR SOFTWARE
OPTIMIZACIÓN DEL ALMACENAMIENTO CON STRATIS
SNAPSHOTS CON STRATIS
OPTIMIZACIÓN DEL ALMACENAMIENTO CON VDO
IMPLEMENTANDO EL SERVICIO NFS
MONTAJE TEMPORAL Y PERMANENTE – EN EL CLIENTE
MONTAJE POR AUTOFS - EN EL CLIENTE
AUTOMATIZACIÓN CON ANSIBLE
¿QUÉ ES ANSIBLE?
ANSIBLE o RED HAT ANSIBLE AUTOMATION?
INSTALACIÓN DE ANSIBLE – HOST DE CONTROL
ADMINISTRAR HOSTS
GESTIÓN DE INVENTARIOS
INVENTARIOS ESTATICOS
DESCRIPCIÓN DE UN INVENTARIO DINÁMICO
ARCHIVOS DE CONFIGURACIÓN DE ANSIBLE
AJUSTES EN EL ARCHIVO DE CONFIGURACIÓN
COMANDOS AD-HOC
CONEXIÓN A HOSTS ADMINISTRADOS
ANSIBLE PLAYBOOKS
VERIFICACIÓN DE SINTAXIS Y VERBOSIDAD
ENSAYO DE PLAYBOOKS
IMPLEMENTANDO MULTIPLES PLAYS EN UN PLAYBOOK
DOCUMENTACIÓN DE MODULOS
MIX DE LABORATORIOS
RECUPERANDO EL ACCESO COMO USUARIO “root”
VOLCADO DE DATA DEL KERNEL PARA ANÁLISIS POSTERIOR
RELAX & RECOVER - RESPALDAR Y RESTAURAR UN SISTEMA LINUX
INSTALACIÓN DE CAPACIDADES DE VIRTUALIZACIÓN(KVM/VIRT-MANAGER)
INSTALANDO UNA MAQUINA VIRTUAL POR VIRT-MANAGER
INSTALANDO Y CONFIGURANDO UN WEBSERVER – NGINX
VIRTUAL HOSTS EN NGINX
PROXY REVERSO PARA TRAFICO HTTP
BALANCEO DE CARGA HTTP CON NGINX
CIFRANDO LA COMUNICACIÓN CON TLS
INSTALACIONES DESATENTIDAS - KICKSTART
IMPLEMENTANDO UN SERVIDOR DE ARCHIVOS CON SAMBA
DESPLIEGUE DE CLIENTES SMB
INGRESO COMO MIEMBRO EN DOMINIO DE WINDOWS SERVER
IMPLEMENTANDO UN RELAY DE CORREO CON POSTFIX Y GMAIL
MONTAJE DE OBJETOS DE AMAZON WEB SERVICES - S3 EN LINUX
INSTALACIÓN Y PUESTA EN PRODUCCIÓN DE POSTGRESQL
POSTGRESQL – CREACIÓN DE BASE DE DATOS Y VOLCADO
EJERCICIO DE RESTAURACIÓN DE BASE DE DATOS
CONSULTAS DE METADATA EN POSTGRESQL
INSTALACIÓN DE POSTGRESQL EN UN FILESYSTEM SECUNDARIO
DEFINICIÓN DE ACCESO A LAS BASES DE DATOS
GRABACIÓN DE SESIONES DE USUARIO
PLATAFORMA PARA CONTAINERS LINUX – PODMAN/SKOPEO
INTRODUCCIÓN
En el año 2000 se me presenta el desafío importante de presentar mi
proyecto de grado para titularme como Ingeniero de Sistemas; recuerdo muy
claramente que la gran mayoría de mis compañeros de universidad tomaron
como opción desarrollar algún tipo de software aplicando los conceptos
desarrollados a lo largo de la carrera; a mi en realidad no me llamaba la
atención esa línea de desarrollo de software aunque me ha había involucrado
plenamente en los temas que perfilan muy claramente a un desarrollador:
lógica y cálculos matemáticos, estructuras de datos, grafos, bases de datos,
análisis y desarrollo de sistemas de información, estadística, etc.
Todo empieza entonces cuando en alguna parte del programa académico

aparecen unos temas relacionados con sistemas operativos y redes de datos
que para mi fueron toda una novedad después de varios semestres
académicos trabajando temas de desarrollo de software; en algunas visitas
técnicas a la Empresa Nacional de Telecomunicaciones (Telecom Colombia)
pude ver una pantalla negra y un cursor titilando, digamos que fue un
momento mágico, algo así parecido a lo que llaman amor a primera vista, no
sabía que era pero me proyecté inmediatamente en ello; preguntando e
investigando me enteré que era algo que se llamaba Solaris, un sistema
operativo de Sun Microsystems de la línea de los UNIX, un sistema
operativo que cumplía con eso que me enseñaban en la asignatura de
sistemas operativos, sin imaginarme que años mas adelante ya en el ejercicio
profesional estaría vinculado a esta empresa (Telefónica - Telecom) como
colaborador participando en actividades sobre este sistema sobre el cual
estaban desplegados los sistemas de información de la compañía en todo el
país.
Internet para el año 2000 no era lo que es hoy, mucha agua ha pasado por
debajo del puente desde entonces. Los contenidos multimedia no eran
abundantes y las herramientas de colaboración no tenían el alcance a lo que
hoy podría ser la mensajería para dispositivos móviles, aun así el email tenía
auge y los grupos de discusión estaban ahí, fue así como decidí trabajar mi
proyecto de grado en algo que se llamaba Linux y una base de datos que se
conocía como PostgreSQL, apoyándome en los conceptos y
recomendaciones de un Ingeniero en Centro America que tenía la
experiencia con este tipo de tecnologías. La empresa de
Telecomunicaciones de Valledupar (TeleUpar), mi ciudad de nacimiento, fue
mi escenario de proyecto de grado, recuerdo claramente el requerimiento de
esa época y los tiempos de despliegue; en aquella oportunidad la empresa me
brindó un equipo tecnológico donde puede realizar el despliegue, recuerdo
tanto que para usar PostgreSQL sobre Linux fue necesario compilar e
instalar la herramienta en tres días, inició un viernes en horas de la tarde y
terminó el siguiente lunes pasada las 10 de la mañana, que alegría, que
emoción !!!, hoy día es una actividad que se realiza en 10 minutos.
Linux es un sistema operativo que está en todo, lo que menos se piensa

tiene un Linux como sistema base. Alguna vez pude conocer que los
vehículos de Formula 1 del equipo Ferrari llevan computadoras a bordo con
sistemas Linux, este sistema operativo también se puede ver en los sistemas
de entretenimiento a bordo de muchas aerolíneas, su aplicabilidad y casos de
usos son múltiples, sin embargo, su mayor despliegue se encuentra en el
corporativo. Los sistemas de información de muchas empresas a nivel
mundial tienen como base Linux, servicios de la vida diaria como las líneas
1XY (líneas publicas y privadas de atención al usuario) están sobre Linux,
sistemas de monitoreo de infraestructura tecnológica, sistemas de seguridad
perimetral, PBX empresariales, sistemas de almacenamiento de datos, etc,
están sobre Linux.
Particularmente he sentido un llamado a aportar un grano de arena en las

actividades de evangelización, adopción, acompañamiento y soporte en la
administración de este sistema operativo. Este libro cumple con la primera
parte, la evangelización, la multiplicación del conocimiento, todo esto
debido a que tantos sistemas desplegados sobre Linux requieren
profesionales con un alto grado de conocimientos y habilidades para
administrar de la mejor forma sistemas críticos. Siempre he dicho que una
instrucción mal digitada trae consigo unos problemas terribles. Sobre
sistemas Linux están plataformas de facturación de empresas de Servicios
Públicos y en ese sentido un mal Administrador Linux podría fácilmente
generar un caos social en una ciudad cualquiera.
Aunque hoy día existen diferentes distribuciones Linux en el ámbito

tecnológico, mi formación ha sido basada en el conocimiento y metodología
de Red Hat Inc, empresa de los Estados Unidos de América que tiene como
producto base el sistema llamado Red Hat Enterprise Linux (RHEL) sobre el
cual se despliegan tecnologías importantes de Contenedores, Virtualización,
Almacenamiento, etc. Es así como he podido recibir sus cursos de
formación, certificarme en su línea de entrenamiento, implementar su
modelo de academia para una entidad del Estado Colombiano y convertirme
en consultor del uso de sus productos en importantes empresas y entidades
estatales.
Este libro está basado en la visión de Red Hat para administrar diferentes
componentes del sistema operativo, sin embargo, conceptos explicados y
procedimientos de gestión pueden ser aplicados en sistemas como Oracle
Linux, CentOS o Fedora; algunas temáticas son aplicables en sistemas
Debian Linux y derivados, como es el caso de Ubuntu Server; en realidad
Linux es uno solo, un núcleo llamado el “Kernel de Linux”, a partir de ahí
parten las distribuciones anteriormente mencionadas y muchas otras que no
he mencionado. Este material ha sido elaborado en parte gracias al aporte de
la documentación de Red Hat el cual está liberado bajo el licenciamiento
Creative Commons Attribution–Share Alike 3.0, teniendo como origen de la
información presentada el portal de aprendizaje de productos Access Red
Hat, en su URL: https://access.redhat.com/products/red-hat-enterprise-linux/
.
El desarrollo de contenidos de este libro asume que por parte del lector
existen unos conocimientos muy básicos del sistema operativo Linux; este
material parte de la base que el usuario conoce temáticas como el manejo de
la ayuda, la edición de archivos de textos, entre otros conocimientos
esenciales. Si usted no cuenta con ese conocimiento le invito a inscribirse a
los cursos de Linux elaborados por Network Development Group (NDG)
para la academia de Cisco Systems, cursos que son gratuitos, de auto
inscripción online, los cuales cuentan con certificación por parte de Cisco
Academy y están enfocados para iniciar un camino en el Linux Professional
Institute, sin embargo sepa usted que las líneas de certificaciones del LPI son
de distinto enfoque respecto a las de Red Hat, teniendo Red Hat un enfoque
mucho más practico en su formación.
Elaborar este libro ha sido un gran placer intelectual y emocional, cada

temática abordada ha sido desarrollada en función de las actividades del día
a día de los Administradores de sistemas Linux Red Hat. Este documento es
el primero de varios, seguidamente estarán presentándose material
especializado en función de temáticas como el afinamiento, la solución de
problemas, la gestión de la seguridad, el almacenamiento y el manejo de
redes, entre otras. Este documento está pensado con un enfoque practico,
por cada tema se presentan los conceptos claves de entendimiento para luego
evidenciar en la practica la aplicación de cada concepto. Espero que pueda
disfrutar de este material así como yo he disfrutado su producción.
HERRAMIENTAS BÁSICAS DE
ADMINISTRACIÓN
AGRUPAMIENTO DE ARCHIVOS Y
DIRECTORIOS
Archivar y comprimir archivos es útil al crear copias de seguridad y
transferir datos entre una red. El comando “tar” ha estado durante mucho
tiempo ligado a este tipo de actividades, usando diferentes algoritmos que
realizan las dos actividades en una sola operación. El comando “tar” le
permitirá reunir grandes conjuntos de archivos en un solo archivo
comprimido usando los algoritmos de compresión gzip, bzip2 o xz. En los
siguientes apartes realizaremos una descripción demostrativa de su uso para
un mejor entendimiento.
En el siguiente ejercicio agruparemos en un solo archivo varios archivos

del siguiente listado, como se muestra:
[root@pruebas ~]# ll
total 39836
-rw-------. 1 root root 1275 Dec 17 17:21 anaconda-ks.cfg
-rw-r--r--. 1 root root 1616 Dec 17 17:23 initial-setup-ks.cfg
drwxr-x---. 2 root root 83 Feb 22 16:46 pruebas
-rw-r--r--. 1 root root 40780168 Jan 5 23:44 webmin-1.970-1.noarch.rpm
Se ejecuta el proceso de agrupación a un solo archivo llamado

“agrupado1.tar”, de los tres (3) archivos relacionados en la siguiente
instrucción:
[root@pruebas ~]# tar -cf agrupado1.tar anaconda-ks.cfg initial-

setup-ks.cfg webmin-1.970-1.noarch.rpm
[root@pruebas ~]# ll -h agrupado1.tar

total 78M
-rw-r--r--. 1 root root 39M Mar 16 08:39 agrupado1.tar
En el siguiente ejemplo agrupamos a un solo archivo llamado “carpeta-

etc” todo el contenido de la carpeta /etc, como se muestra:
[root@pruebas ~]# tar -cf /root/carpeta-etc.tar /etc

[root@pruebas ~]# ll -h carpeta-etc.tar
-rw-r--r--. 1 root root 32M Mar 16 08:41 carpeta-etc.tar
De la siguiente forma es posible listar el contenido de un archivo

agrupado:
[root@pruebas ~]# tar -tf agrupado1.tar

anaconda-ks.cfg
initial-setup-ks.cfg
webmin-1.970-1.noarch.rpm
De la siguiente forma se realiza el desacople de los archivos agrupados

con el comando “tar”:
[root@pruebas ~]# cd /datos/
[root@pruebas datos]# tar xvf /root/agrupado1.tar

anaconda-ks.cfg
initial-setup-ks.cfg
webmin-1.970-1.noarch.rpm
[root@pruebas datos]# ll
total 39848
Si lo ha podido notar, por organización y tratando de hacer un trabajo

limpio, nos hemos posicionado en la ruta /datos y desde ahí se realizó la
tarea de extracción del archivo agrupado haciendo un posterior listado.
COMPRESIÓN Y DESCOMPRESIÓN DE
DATOS
Se comentaba en la sección anterior que con el comando “tar” es posible
agrupar y comprimir la data utilizando diferentes algoritmos de compresión,
esto a través del uso de parámetros relacionados con el respectivo comando.
Los parámetros que usa el comando “tar” para comprimir son los siguientes:
PARÁMETRO ALGORITMO NOMBRE DE ARCHIVO

-z gzip archivo.tar.gz
-j bzip2 archivo.tar.bz2
-J xz archivo.tar.xz
En cuanto al nombre de archivo lo que se detalla es una recomendación

para tener siempre una indicación del archivo resultante. Miremos algunos
ejemplos:
[root@pruebas ~]# tar -czf /datos/gz-etcbackup.tar.gz /etc

tar: Removing leading `/' from member names
[root@pruebas ~]# tar -cjf /datos/bzip2-etcbackup.tar.bz2 /etc

[root@pruebas ~]# tar -cJf /datos/xz-etcbackup.tar.xz /etc

Tenga presente que la sintaxis del comando “tar” indica que primero se
definen los parámetros, seguido de la ruta donde quedará el archivo
resultante, y por último lo que se va a agrupar o comprimir. El resultado de
la compresión de la carpeta /etc en cada uno de los algoritmos de
compresión es el siguiente:
[root@pruebas ~]# ll -trh /datos/

total 59M
-rw-r--r--. 1 root root 7.9M Mar 16 09:04 gz-etcbackup.tar.gz
-rw-r--r--. 1 root root 5.3M Mar 16 09:05 xz-etcbackup.tar.xz
-rw-r--r--. 1 root root 6.1M Mar 16 09:08 bzip2-etcbackup.tar.bz2
A la vista es posible ver que el algoritmo que mas comprime es xz,

seguido de bzip2 y por último es el algoritmo “gzip”, sin embargo como
nada es gratis, los tiempos de compresión son distintos en el uso de ellos,
siendo el más rápido el algoritmo “gzip”, seguido por “bzip2” y “xz”
respectivamente. Podemos de la siguiente forma relacionar los tiempos que
toma cada algoritmo de compresión realizando la actividad correspondiente:
[root@pruebas datos]# time tar -czf /datos/gz-etcbackup.tar.gz /etc

real0m1.414s
user0m1.358s
sys0m0.133s
[root@pruebas datos]# time tar -cjf /datos/bzip2-etcbackup.tar.bz2

/etc
real0m3.620s
user0m3.527s
sys0m0.096s
[root@pruebas datos]# time tar -cJf /datos/xz-etcbackup.tar.xz /etc

real0m14.483s
user0m14.291s
sys0m0.196s
Una vez comprimidos los archivos será mas fácil una transferencia de
datos de un servidor a otro, temática que será abordada en la siguiente
sección, sin embargo, antes de eso es necesario que aprendamos a
descomprimir estos archivos, como se muestra a continuación:
[root@pruebas datos]# mkdir /descomprimidos

[root@pruebas ~]# cd /descomprimidos/
[root@pruebas descomprimidos]# tar xzf /datos/gz-etcbackup.tar.gz
[root@pruebas descomprimidos]# ll -tr

total 12
drwxr-xr-x. 156 root root 8192 Mar 16 08:07 etc
Por limpieza en el trabajo, se ha creado la ruta /descomprimidos para

hacer las extracciones de los archivos comprimidos, donde al comando “tar”
se le pasa el parámetro “x” de extracción, la “z” correspondiente al
algoritmo y la “f” que indica que es un archivo de extracción. Antes de
descomprimir usted podría ver el contenido del archivo de la siguiente
forma:
[root@pruebas descomprimidos]# tar --list -f /datos/xz-

etcbackup.tar.xz | more
TRANSFERENCIA DE ARCHIVOS ENTRE
SISTEMAS
Aprovechando que hemos aprendido a comprimir archivos para la
realización de transferencias de datos rápidas y consistentes, detallaremos las
diferentes formas de compartir data entre distintos sistemas utilizando
diferentes métodos para ello.
Iniciamos entonces utilizando la aplicación “scp”, la cual hace parte de la

suite de aplicaciones proporcionadas por OpenSSH. “scp” copia archivos
entre hosts en una red. Utiliza ssh para la transferencia de datos
proporcionando la misma seguridad que ssh. “scp” le pedirá contraseñas o
frases de contraseña si es necesario para la autenticación.
[root@pruebas datos]# scp xz-etcbackup.tar.xz

root@192.168.0.46:/root
The authenticity of host '192.168.0.46 (192.168.0.46)' can't be

established.
ECDSA key fingerprint is
SHA256:7k2tX7dJP7imd4BgTAZ/fWUkzTcD8VMYS9WxXqjOyYs.
Are you sure you want to continue connecting
(yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.0.46' (ECDSA) to the list of
known hosts.
root@192.168.0.46's password:
xz-etcbackup.tar.xz 100%
5382KB 44.3MB/s 00:00
Registrados en el servidor 192.168.0.46 realizamos un listado para

confirmar que la data ha llegado:
[root@s1 ~]# ll xz-etcbackup.tar.xz

total 5392
-rw-r--r--. 1 root root 5511060 Mar 16 09:49 xz-etcbackup.tar.xz
Es importante aclarar que es necesario validar que la información
enviada como la recibida sean integras, que lo que se envíe corresponda con
lo que se reciba; usted podrá hacer esta comprobación de diferentes formas,
acá se comparte una de ellas utilizando la aplicación “sha256sum” en ambos
servidores y comparando el hash generado en cada host buscando sean
iguales:
[root@pruebas datos]# sha256sum xz-etcbackup.tar.xz

a36c3739dc45f736583bbb83f5c0c00b3fddb5d78718b0672763c4acfbd3612e xz-
etcbackup.tar.xz
[root@s1 ~]# sha256sum xz-etcbackup.tar.xz

a36c3739dc45f736583bbb83f5c0c00b3fddb5d78718b0672763c4acfbd3612e xz-
etcbackup.tar.xz
Otra forma de transferir data entre servidores es trayendo data del

servidor remoto; en este caso en el servidor remoto creamos la carpeta
/carpeta-remota creando dentro de ella algunos archivos vacios:
[root@s1 ~]# mkdir /carpeta-remota

[root@s1 ~]# cd /carpeta-remota/
[root@s1 carpeta-remota]# touch 1 2 3 4 5 6
[root@s1 carpeta-remota]#
Seguidamente traemos los archivos remotos a la carpeta /datos:
[root@pruebas datos]# scp -r root@192.168.0.46:/carpeta-remota

/datos
1 100% 0 0.0KB/s 00:00
2 100% 0 0.0KB/s 00:00
3 100% 0 0.0KB/s 00:00
4 100% 0 0.0KB/s 00:00
5 100% 0 0.0KB/s 00:00
6 100% 0 0.0KB/s 00:00
Muchas son las formas para transferir archivos entre servidores usando el
comando “scp”, para ampliar mas sobre ellas le invito a observar las paginas
de manual de este comando.
Otra opción para transferir archivos entre sistemas remotos es a través de
la herramienta “sftp”. Una sesión con el comando sftp utiliza el mecanismo
de autenticación segura y transferencia de datos cifrados hacia y desde el
servidor SSH. Un ejemplo de este método es el siguiente:
[root@pruebas ~]# sftp 192.168.0.46

Connected to 192.168.0.46.
sftp> ?
Available commands:
bye Quit sftp
cd path Change remote directory to 'path'
--- salida omitida
sftp> cd /carpeta-remota
sftp> pwd
Remote working directory: /carpeta-remota
sftp> ls
1 2 3 4 5 6
sftp> get 6
Fetching /carpeta-remota/6 to 6
El comando “rsync” es otra forma de copiar archivos de forma segura de

un sistema a otro. La herramienta utiliza un algoritmo que minimiza la
cantidad de datos copiados sincronizando solo las porciones de archivos que
han cambiado. Se diferencia de “scp” en que si dos archivos o directorios
son similares entre dos servidores, “rsync” copia las diferencias entre los
sistemas de archivos en los dos servidores, mientras que “scp” necesitaría
copiar todo. Algunos ejemplos en el uso de “rsync” son los siguientes:
[root@pruebas datos]# rsync -av /var/log 192.168.0.46:/tmp

sending incremental file list
log/
log/Xorg.9.log
--- salida omitida ---
sent 31,999,834 bytes received 2,303 bytes 5,818,570.36 bytes/sec
total size is 31,983,412 speedup is 1.00
El ejemplo anterior muestra como se sincroniza la ruta local /var/log en

el servidor remoto dentro de la carpeta /tmp; listando esta carpeta en el
servidor remoto podemos ver los siguiente:
[root@s1 carpeta-remota]# ll /tmp/
total 4
drwxr-xr-x. 22 root root 4096 Mar 16 09:45 log
Validando la utilidad de esta aplicación, podemos revisar si la

sincronización es efectiva creando un archivo nuevo en el servidor origen y
volviendo a sincronizar las dos carpetas, como se muestra a continuación:
[root@pruebas datos]# touch /var/log/fmestre
[root@pruebas datos]# rsync -av /var/log 192.168.0.46:/tmp

sending incremental file list
log/
log/fmestre
sent 4,009 bytes received 63 bytes 1,163.43 bytes/sec

total size is 31,983,412 speedup is 7,854.47
Como el único nuevo movimiento sobre la ruta /var/log fue la creación

del archivo llamado “fmestre”, “rsync” solo sincronizó este archivo en el
servidor destino, como se valida a continuación:
[root@s1 carpeta-remota]# ll /tmp/log/fmestre

-rw-r--r--. 1 root root 0 Mar 16 10:41 /tmp/log/fmestre
“rsync” cuenta con una amplia documentación donde usted podrá

encontrar diferentes formas de transferir datos de un host a otro, el propósito
principal de esta demostración era validar su diferencia con “scp”, mas
información acerca de “rsync” podrá ser consultada en sus paginas de
manual.
MANEJO DE HORA Y FECHA
Configurar la fecha y la hora precisa es importante por varias razones.
En Red Hat Enterprise Linux, el cronometraje es asegurado por el protocolo
NTP, que es implementado por un servicio que se ejecuta en el userspace. El
servicio en el userspace actualiza el reloj del sistema que se ejecuta en el
kernel. El reloj del sistema puede mantener la hora usando varias fuentes de
reloj.
Red Hat Enterprise Linux 8 usa el servicio chronyd para implementar

NTP. Chronyd está disponible en el paquete chrony.
Para mostrar la fecha y hora actuales, siga cualquiera de estos pasos:
[root@pruebas ~]# date

Thu Feb 18 12:54:25 EST 2021
[root@pruebas ~]# timedatectl

Local time: Thu 2021-02-18 12:54:32 EST
Universal time: Thu 2021-02-18 17:54:32 UTC
RTC time: Thu 2021-02-18 17:54:32
Time zone: America/New_York (EST, -0500)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
timedatectl puede usarse para consultar y cambiar el reloj del sistema y

su configuración.
[root@pruebas ~]# timedatectl list-timezones

Africa/Abidjan
Africa/Accra
…
De la siguiente forma establecemos la zona de tiempo a America/Bogota,

confirmándolo con el comando “timedatectl”:
[root@pruebas ~]# timedatectl set-timezone America/Bogota
Local time: Thu 2021-02-18 13:04:42 -05
RTC time: Thu 2021-02-18 18:04:42
Time zone: America/Bogota (-05, -0500)
NTP service: active
RTC in local TZ: no
A continuación se genera un reinicio para verificar que el cambio ha sido

permanente, tal como se muestra a continuación:
[root@pruebas ~]# reboot

Connection to 192.168.0.200 closed by remote host.
Connection to 192.168.0.200 closed.
Generamos nuevamente una conexión ssh para verificar los cambios

realizados previamente:
$ ssh -l root 192.168.0.200

Last login: Thu Feb 18 12:58:02 2021 from 192.168.0.35

Local time: Thu 2021-02-18 13:08:14 -05
RTC time: Thu 2021-02-18 18:08:14
NTP service: active
RTC in local TZ: no
A continuación, cambiaremos la zona de tiempo a

America/Buenos_Aires y reiniciaremos para confirmar el cambio, debe
visualizarse una diferencia de dos horas entre Bogotá y Buenos Aires, como
se muestra a continuación:
Thu Feb 18 13:15:47 -05 2021

Local time: Thu 2021-02-18 13:15:58 -05
RTC time: Thu 2021-02-18 18:15:57
NTP service: active
RTC in local TZ: no
[root@pruebas ~]# timedatectl set-timezone America/Buenos_Aires

Local time: Thu 2021-02-18 15:16:07 -03
RTC time: Thu 2021-02-18 18:16:06
Time zone: America/Buenos_Aires (-03, -0300)
NTP service: active
RTC in local TZ: no
Thu Feb 18 15:16:18 -03 2021

Connection to 192.168.0.200 closed by remote host.
$ ssh -l root 192.168.0.200

Last login: Thu Feb 18 15:10:42 2021 from 192.168.0.35

Local time: Thu 2021-02-18 15:18:17 -03
RTC time: Thu 2021-02-18 18:18:16
Time zone: America/Buenos_Aires (-03, -0300)
NTP service: active
RTC in local TZ: no
MANEJO DE LOCALES
La configuración regional de todo el sistema se almacena en el archivo
/etc/locale.conf, la cual es leida por systemd. Cada servicio o usuario hereda
la configuración regional configurada en /etc/locale.conf, a menos que los
programas individuales o los usuarios individuales los anulan.
Para listar los locales disponibles ejecute la siguiente instrucción:
[root@pruebas ~]# localectl list-locales
C.utf8
en_AG
en_AU
en_AU.utf8
en_BW
en_BW.utf8
en_CA
en_CA.utf8
en_DK
en_DK.utf8
en_GB
en_GB.iso885915
en_GB.utf8
en_HK
en_HK.utf8
en_IE
en_IE.utf8
en_IE@euro
en_IL
en_IN
en_NG
en_NZ
en_NZ.utf8
en_PH
en_PH.utf8
en_SC.utf8
en_SG
en_SG.utf8
en_US
en_US.iso885915
en_US.utf8
en_ZA
en_ZA.utf8
Para listar el locale actual (en uso) ejecute la siguiente instrucción:
[root@pruebas ~]# localectl status

System Locale: LANG=en_US.UTF-8
VC Keymap: us
X11 Layout: us
Para cambiar la configuración de los locales a una de preferencia ejecute

una instrucción como la que se muestra a continuación, con su respectiva
verificación:
[root@pruebas ~]# localectl set-locale LANG=en_GB.utf8
La verificación la puede realizar de la siguiente forma:
[root@pruebas ~]# cat /etc/locale.conf

LANG=en_GB.utf8
O con el comando localectl status, tal como se muestra a continuación:

System Locale: LANG=en_GB.utf8
VC Keymap: us
X11 Layout: us
De la siguiente forma se puede instalar el locale del pack de lenguaje

español:
[root@pruebas ~]# yum install langpacks-es.noarch

…
A comparación con el listado previo de locales, en esta oportunidad

podemos ver como se listan los locales del idioma español y los diferentes
países tal como se muestra a continuación:
[root@pruebas ~]# localectl list-locales
es_AR
es_AR.utf8
es_BO
es_BO.utf8
es_CL
es_CL.utf8
es_CO
es_CO.utf8
…
Aprovechando esta configuración estableceremos en el sistema el local

es_CO.utf8 de la siguiente forma:
[root@pruebas ~]# localectl set-locale LANG= es_CO.utf8
La verificación la puede realizar de la siguiente forma:
[root@pruebas ~]# cat /etc/locale.conf

LANG= es_CO.utf8
[root@pruebas ~]# yum list available langpacks*

Updating Subscription Management repositories.
Última comprobación de caducidad de metadatos hecha hace 0:23:53, el jue 18 feb 2021 16:37:34 -03.
Paquetes disponibles
langpacks-af.noarch 1.0-12.el8 rhel-8-for-x86_64-appstream-rpms
langpacks-am.noarch 1.0-12.el8 rhel-8-for-x86_64-appstream-rpms
En el anterior comando se pudo apreciar como empiezan a generarse

salidas en idioma español debido al cambio del locale que previamente se
ejecutó.
ESTABLECIENDO EL MAPA DE TECLADO
Es momento de establecer si es necesario, la configuración del teclado
que estará definido en el sistema operativo, para ello listamos los mapas de
teclado disponible de forma inicial, como se muestra a continuación:
[root@pruebas ~]# localectl list-keymaps

ANSI-dvorak
al
al-plisi
amiga-de
amiga-us
applkey
at
at-mac
at-nodeadkeys
at-sundeadkeys
atari-de
Se ha podido visualizar algunas mapas de teclado, de los cuales se

tomará el mapa “es” como mapa de teclado por default:
[root@pruebas ~]# localectl set-keymap es
Verificamos tal cambio mirando el estado actual del locale, como se

detalla a continuación:

System Locale: LANG=en-US
VC Keymap: es
X11 Layout: es
X11 Model: pc105
X11 Options: terminate:ctrl_alt_bksp
PROGRAMACIÓN DE TAREAS
Hablar de tareas programadas es hablar de actividades que se ejecutarán
en algún punto del tiempo. Para esto RHEL 8 y derivados, así como otras
distribuciones Linux utilizan un par de herramientas que pueden realizar este
tipo de programaciones.
USANDO EL SERVICIO atd
Una de las herramientas para la programación de tareas es la aplicación

“at”, utilizada para crear tareas programadas con ejecución de una única vez,
si, una sola vez, para las tareas de programación periódica usaremos
“crontabs”, temática que será abordada en posterior sección.
El paquete “at” proporciona el servicio del sistema (atd) junto con un

conjunto de herramientas de línea de comandos para interactuar con el
servicio (at, atq y más). En una instalación predeterminada de RHEL, el
servicio “atd” se instala y se habilita automáticamente. Para verificar su
estado y si está habilitado en el arranque del sistema operativo haremos lo
siguiente:
[root@pruebas ~]# systemctl is-enabled atd

enabled
[root@pruebas ~]# systemctl is-active atd

active
Algunos ejemplos en la definición de tareas con la herramienta “at” son

los siguientes:
[root@pruebas ~]# at teatime tomorrow

warning: commands will be executed using /bin/sh
at> date >> /datos/hora.txt
at> <EOT>
job 4 at Wed Mar 17 16:00:00 2021
Tue Mar 16 11:28:44 -05 2021
[root@pruebas ~]# atq

4Wed Mar 17 16:00:00 2021 a root
En el ejemplo anterior podemos ver como es programada una tarea para

ejecutarse en la famosa hora del té, o sea a las 16:00 del día siguiente
(tomorrow); la tarea programada consiste en generar un “date” y
redireccionar su resultado a /datos/hora.txt; luego de definir la tarea
presionamos “ENTER” y para finalizar digitamos CTRL+D; en el ejemplo
se visualiza la fecha y hora actual así como con el comando “atq” se lista la
tarea programada. Otro ejemplo de una tarea programada es el siguiente:

Tue Mar 16 11:33:48 -05 2021
[root@pruebas ~]# at 5pm march 16 2021

warning: commands will be executed using /bin/sh
at> date >> /datos/hora.txt
at> <EOT>
job 5 at Tue Mar 16 17:00:00 2021

4Wed Mar 17 16:00:00 2021 a root
5Tue Mar 16 17:00:00 2021 a root
Esta tarea ha quedado programada como la tarea número cinco (5) en el

sistema; para ese momento podrá entonces conocer el resultado de la
operación. La especificación del tiempo para este comando “at” es conocida
como el TIMESPEC. Los usuarios (incluido el root) pueden poner en cola
trabajos para el servicio “atd” usando el comando at. El servicio atd
establece 26 colas, de la A a la Z para encolar las tareas, para los ejemplos
anteriormente visualizados la cola utilizada es la “a”, como le define el
penúltimo campo del comando “atq”.
De la siguiente forma usted podrá eliminar los trabajos encolados:
[root@pruebas ~]# atrm 5

4Wed Mar 17 16:00:00 2021 a root
Con el ejemplo anterior, el commando “atrm” eliminó la tarea

programada número cinco (5), como se valida en el listado que nos permite
ver “atq”. Otra forma de visualizar las tareas que el servicio “atd” tiene
programadas es como se muestra a continuación:
[root@pruebas ~]# at -c 4
#!/bin/sh
# atrun uid=0 gid=0
# mail root 0
umask 22
${SHELL:-/bin/sh} << 'marcinDELIMITER57db4900'
date >> /datos/hora.txt
marcinDELIMITER57db4900
TAREAS PROGRAMADAS CON crond
La segunda forma que tiene un Administrador Linux para programar

tareas es a través del uso del servicio “crond”, el cual es proporcionado por
el paquete “cronie”, el cual le permite programar tareas para ejecutarse de
forma periódica a diferencia del servicio “atd”. Para verificar si el servicio
está activo y habilitado para el arranque del sistema operativo detalle lo
siguiente:
[root@pruebas ~]# systemctl is-enabled crond.service

enabled
[root@pruebas ~]# systemctl is-active crond.service

active
El servicio “crond” lee varios archivos de configuración: uno por usuario

(editados con el comando crontab) y un conjunto de archivos de todo el
sistema. Estos archivos de configuración proporcionan a los usuarios y
administradores un control detallado sobre cuándo deben realizarse sus
trabajos recurrentes.
Una particularidad de “crond” es que si una tarea programada produce

algún resultado o error que no se redirige, el servicio “crond” intenta enviar
por correo electrónico esa salida o error al usuario propietario de esa tarea (a
menos que se anule) utilizando el servicio de correo configurado en el
sistema.
Para usar el servicio “crond” se establecen tareas programadas con el

programa “crontab”, el cual trae algunos parámetros como los que se
muestra a continuación:
[root@pruebas ~]# crontab -l
[root@pruebas ~]# crontab -r
[root@pruebas ~]# crontab -e
El parámetro “l” permite listar las tareas programadas por el usuario; el

parámetro “r” remueve todas las tareas programadas por el usuario y el
parámetro “e” permite editar las tareas programadas usando el editor de
texto por default, en este caso la aplicación “vi”.
El formato para que “crond” entienda las tareas programadas se explica

con el siguiente ejemplo:
0 23 * * * /root/backup.sh
El ejemplo anterior le dice a “crond” que a las 23:00, todos los días,
todos los meses, todos los días de la semana, ejecute el script llamado
“/root/backup.sh”. Claramente se aprecia que el número 0 indica el minuto
exacto en que se va a ejecutar la tarea, lo mismo pasa con el número 23 el
cual indica la hora de ejecución, el siguiente campo es el día exacto del mes,
el siguiente campo es el mes, el siguiente campo hace referencia a que si se
desea ejecutar la tarea en un día en particular (lunes, martes, miércoles,
jueves, viernes, sábado o domingo), y por ultimo, lo que se requiere ejecutar,
o un script o un comando.
Teniendo en cuenta el ejemplo anterior, un “*” indica todos los valores

posibles, por ejemplo, para el tercer campo de la instrucción anterior se
necesita que se haga todos los días. Una mejor descripción es la siguiente:
0 : ejecución en el minuto 0
23: ejecución en la hora 23
* : ejecución todos los días del mes
* : ejecución todos los mese del año
* : ejecución todos los días de la semana
/root/backup.sh : comando o script a ejecutar
Los valores permitidos que podrían tener estos campos se relacionan a

continuación:
minutos 0-59
horas 0-23
días del mes 1-31
meses 1-12
días de la semana 0-7
Otros ejemplos de posibles ediciones de “crontab” son los siguientes:
0 11 30 1 * /datos/backup.sh → ejecución para las 11:00 am del 30

de enero, no importa el día.
*/2 10-16 * Jul 5 /datos/backup.sh → ejecución cada dos minutos

entre las 10 am y 4 pm todos los días viernes del mes de Julio.
59 23 * * 6 /datos/backup.sh → ejecución para las 11:59 pm todos

los días del año que sean sábado.
0 17 * * 1-5 /datos/backup.sh → ejecución a las 5:00 pm para todos

los días del año de lunes a viernes.
La visualización de todas estas tareas programadas resultaría en el

siguiente detalle:
[root@pruebas ~]# crontab -l

0 11 30 1 * /datos/backup.sh
*/2 10-16 * Jul 5 /datos/backup.sh
59 23 * * 6 /datos/backup.sh
0 17 * * 1-5 /datos/backup.sh
Cualquier modificación que usted requiera hacer sobre una tarea

programada debería hacerse utilizando el parámetro de edición. Recuerde
que el programa por default para editar “crontabs” es la aplicación “vi”, a no
ser que se requiera su cambio.
CRONS DEL SISTEMA
Las tareas recurrentes del sistema son definidas en dos ubicaciones, el

archivo /etc/crontab y los archivos ubicados en /etc/cron.d, como se muestra
a continuación:
[root@pruebas ~]# cat /etc/crontab

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# For details see man 4 crontabs
# Example of job definition:

# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR
sun,mon,tue,wed,thu,fri,sat
#| | | | |
# * * * * * user-name command to be executed
[root@pruebas ~]# ll /etc/cron.d

total 12
-rw-r--r--. 1 root root 128 Jun 12 2019 0hourly
-rw-r--r--. 1 root root 108 Jun 5 2020 raid-check
-rw-r--r--. 1 root root 70 Aug 10 2020 rear
Un ejemplo de “cron” personalizado utilizando el archivo /etc/crontab

puede ser el que se muestra a continuación:
Cree la carpeta /datos y posiciónese en ella:
[root@pruebas ~]# mkdir /datos
[root@pruebas ~]# cd /datos
Con el editor de su preferencia, cree un archivo llamado “tareas.sh” y

adicione la línea “date >> /datos/hora.txt”:
[root@pruebas datos]# vim tareas.sh

Establezca permisos de ejecución sobre el archivo de script creado:
[root@pruebas datos]# chmod 770 tareas.sh
En el archivo /etc/crontab adicione la siguiente línea, tenga presente el

uso de comillas sencillas:
[root@pruebas datos]# echo ‘*/1 * * * * root /datos/./tareas.sh’ >>
/etc/crontab
Relea los archivos de configuración del servicio “cron”:
[root@pruebas datos]# systemctl reload crond.service
Revise el contenido del archivo /datos/hora.txt, cada minuto se agregará

una línea de texto, como se muestra a continuación:
[root@pruebas datos]# cat hora.txt

Tue Mar 16 13:16:01 -05 2021
Tue Mar 16 13:17:01 -05 2021
Tue Mar 16 13:18:01 -05 2021
Tue Mar 16 13:19:01 -05 2021
Tue Mar 16 13:20:01 -05 2021
Tue Mar 16 13:21:01 -05 2021
Tenga presenta que el archivo /etc/crontab puede ser sobre escrito por
alguna aplicación del sistema, por lo que podrá perder la programación
generada, por lo tanto la forma aconsejable de usar “crons” personalizados
es ubicarlos en la ruta /etc/cron.d, como se muestra a continuación:
Cree la carpeta /datos y posiciónese en ella:
[root@pruebas ~]# cd /datos
Con el editor de su preferencia, cree un archivo llamado “tareas.sh” y

adicione la línea “date >> /datos/hora.txt”:
[root@pruebas datos]# vim tareas.sh

Establezca permisos de ejecución sobre el archivo de script creado:
[root@pruebas datos]# chmod 770 tareas.sh
Posiciónese en la ruta /etc/cron.d y liste el contenido de la carpeta:

[root@s1 cron.d]# cd /etc/cron.d
[root@s1 cron.d]# pwd

/etc/cron.d
Liste el contenido de la carpeta:

[root@s1 cron.d]# ll
total 16
-rw-r--r--. 1 root root 128 Nov 11 2019 0hourly
-rw-r--r--. 1 root root 108 Aug 2 2020 raid-check
-rw-r--r--. 1 root root 70 Nov 5 20:58 rear
Cree un archivo llamado tareas y adicione la siguiente línea:
[root@s1 cron.d]# vim tareas

*/1 * * * * root /datos/./tareas.sh
Un nuevo archivo debe aparecer en el listado de /etc/cron.d, como se

[root@s1 cron.d]# ll
total 16
-rw-r--r--. 1 root root 128 Nov 11 2019 0hourly
-rw-r--r--. 1 root root 108 Aug 2 2020 raid-check
-rw-r--r--. 1 root root 70 Nov 5 20:58 rear
-rw-r--r--. 1 root root 36 Mar 16 13:36 tareas
Relea los archivos de configuración de “crond”
[root@s1 cron.d]# systemctl reload crond.service
Por último solo espere que cada minuto se adicione una línea al archivo
/datos/hora.txt:
[root@s1 cron.d]# tail -f /datos/hora.txt

Tue Mar 16 13:37:01 -05 2021
Tue Mar 16 13:38:01 -05 2021
Tue Mar 16 13:39:01 -05 2021
Tue Mar 16 13:40:01 -05 2021
Tue Mar 16 13:41:01 -05 2021
Tue Mar 16 13:42:01 -05 2021
Tue Mar 16 13:43:01 -05 2021
Tue Mar 16 13:44:01 -05 2021
Tue Mar 16 13:45:01 -05 2021
En las rutas /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, and

/etc/cron.monthly/ usted va a encontrar scripts que tienen ejecución en los
periodos establecidos en los nombres de las carpetas.
Un comando llamado “run-parts” llamado desde el archivo

“/etc/cron.d/0hourly” ejecuta los archivos en /etc/cron.hourly/. El comando
run-parts también ejecuta los trabajos diarios, semanales y mensuales, pero
este programa “run-parts” es llamado desde el archivo de configuración
/etc/anacrontab:
[root@pruebas ~]# cat /etc/anacrontab

# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22
#period in days delay in minutes job-identifier command

15cron.dailynice run-parts /etc/cron.daily
725cron.weeklynice run-parts /etc/cron.weekly
@monthly 45cron.monthlynice run-parts /etc/cron.monthly
En versiones 6 de RHEL y derivados, un servicio llamado “anacron”

solía manejar el /etc/anacrontab, pero en Red Hat Enterprise Linux 7 y
versiones posteriores, el servicio “crond” analiza este archivo.
GESTIÓN DEL SISTEMA CON SYSTEMD
Systemd administra el inicio del sistema operativo Linux. Systemd es un
administrador de sistemas y servicios para sistemas operativos Linux. Está
diseñado para ser compatible con los scripts de inicio de SysV (usado en
anteriores versiones de Red Hat y derivados), y tiene como características las
siguientes:
Se desarrolló systemd para reemplazar el sistema de inicio

(init)
En el proceso de arranque en Linux, es el primer proceso que
se ejecuta en el espacio de usuario
Es el proceso padre de todos los procesos hijos en el espacio de
usuario.
systemd se diseñó para el núcleo Linux y programado
exclusivamente para la API de Linux.
Fue escrito por Lennart Poettering y se publica como software
libre y de código abierto bajo los términos de la GNU General
Public License (LGPL) versión 2.1 o posterior.
Systemd inicia varios servicios al mismo tiempo (paralelismo)
Evitar tiempos de espera prolongados. Por ejemplo, un servicio
dependiente de otro, no intentará iniciarse hasta que el servicio del
que depende esté disponible.
Si usted verifica los procesos en el sistema verá que Systemd es el

primer proceso en ejecutarse, como se muestra a continuación:
[root@pruebas ~]# ps -fe

UID PID PPID C STIME TTY TIME CMD
root 1 0 0 08:49 ? 00:00:06 /usr/lib/systemd/systemd --switched-root --
system --deserializ
Systemd introduce el concepto de unidades systemd. Estas unidades

están representadas por archivos de configuración ubicados en uno de los
siguientes directorios:
/usr/lib/systemd/system/
/run/systemd/system/
/etc/systemd/system/
Una unidad como “.service” es usada para iniciar daemons como un Web
Server. Una unidad “.socket” es usada para conexiones sobre demanda,
como es el caso de un cliente que requiere un servicio que no se está
ejecutando, cuando el cliente requiere de un servicio el socket inicia el
servicio que no se está ejecutando; también están las unidades “.path” que
son usadas para iniciar la activación de un servicio cuando ocurra un cambio
en el sistema de archivos.
Usted puede listar las unidades tipo socket de la siguiente forma:
[root@pruebas ~]# systemctl list-units --type=socket

UNIT LOAD ACTIVE SUB DESCRIPTION
avahi-daemon.socket loaded active running Avahi mDNS/DNS-SD Stack

Activation Socket
cockpit.socket loaded active listening Cockpit Web Service Socket
cups.socket loaded active running CUPS Scheduler
dbus.socket loaded active running D-Bus System Message Bus Socket
dm-event.socket loaded active listening Device-mapper event daemon FIFOs
iscsid.socket loaded active listening Open-iSCSI iscsid Socket

iscsiuio.socket loaded active listening Open-iSCSI iscsiuio Socket
libvirtd-admin.socket loaded active listening Libvirt admin socket
libvirtd-ro.socket loaded active listening Libvirt local read-only socket
libvirtd.socket loaded active listening Libvirt local socket
lvm2-lvmpolld.socket loaded active listening LVM2 poll daemon socket
multipathd.socket loaded active listening multipathd control socket

rpcbind.socket loaded active running RPCbind Server Activation Socket
sssd-kcm.socket loaded active listening SSSD Kerberos Cache Manager
responder socket
systemd-coredump.socket loaded active listening Process Core Dump Socket
systemd-initctl.socket loaded active listening initctl Compatibility Named Pipe

systemd-journald-dev-log.socket loaded active running Journal Socket (/dev/log)
systemd-journald.socket loaded active running Journal Socket

systemd-udevd-control.socket loaded active running udev Control Socket
systemd-udevd-kernel.socket loaded active running udev Kernel Socket

virtlockd.socket loaded active listening Virtual machine lock manager socket
virtlogd.socket loaded active listening Virtual machine log manager socket
LOAD = Reflects whether the unit definition was properly loaded.

ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
En este caso las unidades de servicio tipo socket listadas son las que
están activas, usted podría al finalizar el comando enviar el parámetro “--all”
para visualizar las no activas. De igual forma puede digitar el comando
“systemctl” para ver la totalidad de las unidades de servicio.
ADMINISTRANDO SERVICIOS CON
SYSTEMD
Las versiones anteriores de Red Hat Enterprise Linux (RHEL6), que se
distribuyeron con SysV init o Upstart, usaban init scripts ubicados en el
directorio /etc/rc.d/init.d/. Estos scripts de inicialización se escribían
normalmente en Bash y permitía al administrador del sistema controlar el
estado de los servicios y daemons en su sistema. A partir de con Red Hat
Enterprise Linux 7, estos scripts de inicio han sido reemplazados por
unidades de servicio. Las unidades de servicio terminan con la extensión de
archivo .service y tienen un propósito similar al de los scripts de inicio.
Para ver, iniciar, detener, reiniciar, habilitar o deshabilitar los servicios

del sistema, use el comando “systemctl”. Los comandos service y chkconfig
todavía están disponibles en el sistema y funcionan como se esperaba, pero
solo se incluyen por razones de compatibilidad y se debe evitar su uso. La
siguiente tabla muestra parte de la compatibilidad con los sistemas anteriores
para el manejo de servicios, en este caso el servicio httpd:
SysV SystemD
service httpd start systemctl start httpd.service
service httpd stop systemctl stop httpd.service
service httpd restart systemctl restart httpd.service
service httpd condrestart systemctl try-restart httpd.service
service httpd reload systemctl reload httpd.service
service httpd status systemctl status httpd.service
El “systemctl try-restart httpd.service” le permite al sistema recargar la

configuración sin interrumpir la ejecución del servicio. Para evitar que los
usuarios encuentren mensajes de error innecesarios, el servidor HTTP
Apache le permite editar y recargar su configuración sin la necesidad de
reinicio e interrupción de las solicitudes al HTTP Server.
En lo que respecta a la activación de servicios en el momento del
arranque del sistema operativo la comparación es la siguiente:
SysV SystemD Descripción

chkconfig systemctl enable Activa el servicio en el
httpd on httpd.service arranque
chkconfig systemctl disable Desactiva el servicio en el
httpd off httpd.service arranque
systemctl is-enable
chkconfig – httpd.service Verifica si el servicio se
list httpd systemctl status active en el arranque.
httpd.service
Usted también puede usar el comando “systemctl reenable

httpd.service”, el reenable le permite deshabilitar el enable y volverlo a
habilitar, como se muestra a continuación:
[root@pruebas ~]# systemctl reenable atd.service

Removed /etc/systemd/system/multi-user.target.wants/atd.service.
Created symlink /etc/systemd/system/multi-
user.target.wants/atd.service → /usr/lib/systemd/system/atd.service.
Pueden existir casos donde existan conflictos al iniciar servicios, como

son es el caso de las aplicaciones Postfix y Sendmail que usan el mismo
puerto de conexión, ambas aplicaciones pueden estar instaladas en sus
sistema Linux pero si usan los mismos puertos de conexión SystemD no
ejecutará una de ellas, para que eso sea posible debe cambiar los puertos,
hacerlos diferentes para que SystemD pueda iniciar estos servicios.
SystemD le permite anular servicios en forma de enmascaramiento;

teniendo en cuenta el caso anterior, usted podría enmascar Postfix o
Sendmail (el que no vaya a usar) para habilitar el contrario, como se muestra
a continuación:
[root@pruebas ~]# systemctl mask sendmail.service

Unit sendmail.service does not exist, proceeding anyway.
Created symlink /etc/systemd/system/sendmail.service → /dev/null.
[root@pruebas ~]# systemctl unmask sendmail.service
Removed /etc/systemd/system/sendmail.service.
Si usted observa, el servicio sendmail no está instalado pero si se llegase

a instalar de entrada estaría deshabilitado. También se detalla como quitar
esa restricción. Usted podría detallar las unidades de servicios del cual
depende un servicio, como lo muestra el ejemplo para el servicio “atd”,
como se relaciona a continuación:
[root@pruebas ~]# systemctl list-dependencies atd.service

atd.service
● ├─system.slice
● └─sysinit.target
● ├─dev-hugepages.mount
● ├─dev-mqueue.mount
● ├─dracut-shutdown.service
● ├─import-state.service
● ├─iscsi-onboot.service
● ├─kmod-static-nodes.service
HABILITANDO SERVICIOS DESDE
SYSTEMD
En este apartado obtendremos información para asegurar que un servicio
esté habilitado o deshabilitado en el momento del arranque del sistema
operativo Linux.
Es importante aclarar que para realizar estas actividades, es necesario

autenticarse como usuario root. En este ejemplo tomaremos como ejemplo
el servicio generado por la instalación del Apache Web Server para publicar
contenido vía paginas web; el servicio que se instala en el sistema se conoce
como httpd, a continuación la forma de habilitar y deshabilitar el servicio:
Para habilitar en el arranque del sistema operativo la activación

del servicio httpd use algunas de las siguientes opciones:
[root@pruebas ~]# systemctl enable httpd
[root@pruebas ~]# systemctl enable httpd --now

user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
Esta ultima opción le permitirá iniciar el servicio de forma inmediata, tal

como se muestra a continuación:

…
root 2707 1 0 16:36 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 2708 2707 0 16:36 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
Para deshabilitar la activación del servicio en el momento del
arranque del Sistema Linuxes necesario hacer como sigue:
[root@pruebas ~]# systemctl disable httpd

Removed /etc/systemd/system/multi-user.target.wants/httpd.service.
Usted le podría consultar al sistema acerca del estatus del servicio httpd
[root@pruebas ~]# systemctl is-enabled httpd

disabled
ADMINISTRANDO TARGETS CON
SYSTEMD
La palabra “targets” en este contexto podría significar el a donde se
quiere que SystemD llegue, cual es el objetivo para el arranque del sistema
Linux.
Los “targets” de Systemd están representados por unidades tipo “.target”.

El propósito es agrupar otras unidades systemd a través de una cadena de
dependencias. Por ejemplo, la unidad graphical.target, que se utiliza para
iniciar una sesión gráfica, inicia servicios del sistema como el Administrador
de visualización de GNOME (gdm.service) o el Servicio de cuentas
(accounts-daemon.service) y también activa la unidad multiusuario.target.
Del mismo modo, la unidad multi-user.target inicia otros servicios del
sistema como NetworkManager (NetworkManager.service) o D-Bus
(dbus.service) y activa otra unidad tipo “target” llamada basic.target.
En sistemas anteriores a Red Hat 7, SystemV usaba los famosos niveles

de ejecución, que erán del 0 al 6, sin embargo de eso ya no queda nada desde
RHEL 7, SystemD trabaja con targets, objetivos de adonde debe llegar el
arranque del sistema.
SystemV SystemD
0 runlevel0.target - poweroff.target
1 runlevel1.target - rescue.target
2 runlevel2.target - multiuser.target
5 runlevel5.target - graphical.target
6 runlevel6.target - reboot.target
Los “targets” a donde puede llegar el sistema se pueden listar de la

siguiente forma:
[root@pruebas ~]# systemctl list-units --type target
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
cryptsetup.target loaded active active Local Encrypted Volumes
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical Interface
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target loaded active active Local File Systems
multi-user.target loaded active active Multi-User System
network-online.target loaded active active Network is Online
network-pre.target loaded active active Network (Pre)
network.target loaded active active Network
nfs-client.target loaded active active NFS client services
nss-user-lookup.target loaded active active User and Group Name Lookups
paths.target loaded active active Paths
remote-fs-pre.target loaded active active Remote File Systems (Pre)
remote-fs.target loaded active active Remote File Systems
rpc_pipefs.target loaded active active rpc_pipefs.target
rpcbind.target loaded active active RPC Port Mapper
slices.target loaded active active Slices
sockets.target loaded active active Sockets
sshd-keygen.target loaded active active sshd-keygen.target
swap.target loaded active active Swap
sysinit.target loaded active active System Initialization
timers.target loaded active active Timers
Usted puede visualizar el “target” por defecto para saber que tiene
definido SystemD al momento de arrancar el sistema operativo, tal como se
[root@pruebas ~]# systemctl get-default

graphical.target
En este caso SystemD va a llevar el sistema hasta el target llamado

“graphical.target”, el cual le permite llegar hasta la interfaz grafica del
sistema operativo. Si por ejemplo usted no desea que su sistema Linux inicie
con interfaz grafica usted podría cambiar el target por default de la siguiente
forma:
[root@pruebas ~]# systemctl set-default multi-user.target

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target →
/usr/lib/systemd/system/multi-user.target.
[root@pruebas ~]# systemctl get-default
multi-user.target
Para comprobar este cambio usted podría hacer un “reboot” del sistema y
el arranque solo debería de ser por Interfaz de Línea de Comandos. En el
momento en que usted desee cambiarse de target sin cambiar el target por
default, usted podría usar la siguiente instrucción:
[root@pruebas ~]# systemctl isolate multi-user.target
Si usted estaba en la interfaz grafica del sistema verá como esta se va de

su pantalla y solo verá la interfaz de línea de comandos.
BOOT EN MODO DE RESCATE
El modo de rescate proporciona un entorno conveniente para un solo

usuario y le permite reparar su sistema en situaciones en las que no puede
completar un proceso de arranque normal. En modo de rescate, el sistema
intenta montar todos los sistemas de archivos locales e iniciar algunos
servicios importantes del sistema, pero no se activan las interfaces de red o
se permite que los demás usuarios inicien sesión en el sistema. Para entrar
en modo de rescate usted puede realizar lo siguiente (como usuario root):
Al realizar esta operación el sistema pasa a este target y nos muestra una
pantalla como la siguiente:
Para salir de este modo usted podría realizar un reboot o cambiar al
target deseado.
BOOT EN MODO DE EMERGENCIA
El modo de emergencia proporciona el entorno más mínimo posible y le

permite reparar su sistema incluso en situaciones en las que el sistema no
puede ingresar al modo de rescate. En modo de emergencia, el sistema
monta el sistema de archivos raíz solo para lectura, no intenta montar ningún
otro sistema de archivos local, no activa las interfaces de red y solo inicia
algunos servicios esenciales. Para llegar el target de emergencia usted
podría hacer lo siguiente:
Al realizar esta operación el sistema pasa a este target y nos muestra una
pantalla como la siguiente:
Para salir de este modo usted podría realizar un reboot o cambiar al
target deseado.
APAGANDO, REINICIANDO Y
SUSPENDIENDO EL SISTEMA
Las formas como se apaga, reinicia y se envía a hibernación pueden
variar; acá intentaremos abordar algunas de ellas, iniciando con el apagado.
MODOS DE APAGADO
Se detallan diferenten formas para detener y apagar el sistema, como se

# systemctl poweroff --> Apagar el sistema apagando la

maquina
# systemctl halt --> Detiene el sistema sin apagar la maquina
# systemctl --no-wall poweroff --> apaga el sistema sin enviar
mensajes
# shutdown --poweroff 10:18 --> apaga el sistema a una hora
definida
[root@pruebas ~]# shutdown --poweroff 10:18

Shutdown scheduled for Thu 2021-02-25 10:18:00 -05, use
'shutdown -c' to cancel.
# shutdown --halt +2 --> detiene el sistema sin apagar la

maquina a partir de 2 minutos

Thu Feb 25 10:20:52 -05 2021
[root@pruebas ~]# shutdown --halt +2

Shutdown scheduled for Thu 2021-02-25 10:22:52 -05, use
'shutdown -c' to cancel.
# shutdown -c --> cancelar un shutdown pendiente
MODOS DE REINICIO – SUSPENSIÓN
Se detallan diferentes formas de reiniciar el sistema, como se muestra a

continuación:
# systemctl reboot --> reinicia y envía información a los usuarios

conectados.
# systemctl reboot --no-wall --> reinicia y no envía información a
los usuarios conectados.
# systemctl suspend --> Este comando guarda el estado del
sistema en la RAM y, con la excepción del módulo RAM, se apaga
la mayoría de los dispositivos de la máquina. Cuando vuelve a
encender la máquina, el sistema restaura su estado de la RAM sin
tener que arrancar de nuevo. Debido a que el estado del sistema se
guarda en la RAM y no en el disco duro, restaurar el sistema desde
el modo de suspensión es significativamente más rápido que
restaurarlo desde hibernación, pero como consecuencia, un estado
del sistema suspendido también es vulnerable a cortes de energía.
MANEJO DE ARCHIVOS DE UNIDADES
El archivo de unidad describe a una unidad como tal y su
comportamiento. Si es necesario realizar ajustes sobre tales archivos el
administrador del sistema tendrá que entrar a cada archivo de unidad y
realizar las tareas que corresponden. A continuación, se muestra la ruta de
ubicación y el contenido del archivo de unidad del servicio sshd, como
sigue:
[root@pruebas system]# pwd

/usr/lib/systemd/system
[root@pruebas system]# cat sshd.service

[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.target
Wants=sshd-keygen.target
[Service]
Type=notify
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target
Si usted ve la línea After, esta define el orden en que se inician las

unidades. La unidad comienza sólo después de que las unidades
especificadas en After se encuentren activas, como se muestra en la lista de
dependencias del servicio:
[root@pruebas system]# systemctl list-dependencies sshd.service

sshd.service
● ├─system.slice
├
● ├─sshd-keygen.target
● │ ├─sshd-keygen@ecdsa.service
● │ ├─sshd-keygen@ed25519.service
● │ └─sshd-keygen@rsa.service
Tambien puede observar la sección “Want”. Esta línea indica las

dependencias (unidades) más débiles que requiere. Si cualquiera de las
unidades enumeradas no se inicia correctamente, no tiene ningún impacto en
la activación de la unidad. Esta es la forma recomendada de establecer
dependencias en una unidad personalizada. El parámetro ExecStart indica
el comando que debe ejecutarse para iniciar el servicio. Usted podrá realizar
un “man 5 systemd.unit” para ver al detalle la configuración de las unidades
en sus respectivos archivos.
CREANDO UN ARCHIVO DE UNIDAD
Los administradores del sistema a menudo necesitan configurar y

ejecutar varias instancias de un servicio. Esto puede usarse para implementar
escenarios de aplicación diferentes y así evitar entrar en conflicto con el
servicio principal. En el siguiente procedimiento se detalla cómo crear una
segunda instancia del servicio sshd.
1. Crear una copia del archivo sshd_config que será usada por el
servicio:
[root@pruebas ~]# cp /etc/ssh/sshd{,-second}_config
Realizar un listado para verificar que haya sido copiado el archivo:
[root@pruebas ~]# ll -ltr /etc/ssh/ssh*

-rw-------. 1 root root 4269 Mar 27 2020 /etc/ssh/sshd_config
-rw-r--r--. 1 root root 1770 Mar 27 2020 /etc/ssh/ssh_config
-rw-------. 1 root root 4269 Feb 26 11:10 /etc/ssh/sshd-second_config
2. Editar el archivo sshd-second_config y asignarle un puerto de

escucha al servicio diferente al de la instancia principal y un
archivo de PID distinto:
Port 22220
PidFile /var/run/sshd-second.pid
Si las líneas están comentadas con el caractér #, usted podría quitar

tal caractér.
3. Crear una copia del archivo de unidad del servicio SSHD y

verifique:
[root@pruebas ~]# cp /usr/lib/systemd/system/sshd.service

/etc/systemd/system/sshd-second.service
[root@pruebas ssh]# ll /etc/systemd/system/sshd-second.service
-rw-r--r--. 1 root root 456 Feb 26 11:14 /etc/systemd/system/sshd-
second.service
4. Modificar el archivo previamente copiado

(/etc/systemd/system/sshd-second.service) con los siguientes datos
en las líneas mencionadas:
a. Modificar la descripción del servicio:
Description=OpenSSH server second instance daemon
b. Adicionar sshd.service a la sección After, significa que esta

instancia inicia solo después que se inicie la primera instancia del
servicio, esa línea debe quedar asi:
After=syslog.target network.target auditd.service sshd.service
c. Quitar (si existe) la siguiente línea del archivo, la primera

instancia incluye la creación de la llave:
ExecStartPre=/usr/sbin/sshd-keygen
d. Adicionar el parámetro -f /etc/ssh/sshd-second_config al

comando sshd
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config
$OPTIONS
e. Después de las configuraciones realizadas, el archivo sshd-

second.service debe lucir así:
[Unit]
Description=OpenSSH server second instance daemon
After=syslog.target network.target auditd.service sshd.service
[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config
$OPTIONS
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
5. Si usa SELinux, adicionar para control el puerto en el que el

segundo servicio SSHD va a escuchar:
[root@pruebas ~]# semanage port -a -t ssh_port_t -p tcp 22220
6. Activar de forma inmediata y para el inicio del sistema Linux

el servicio sshd-second.service
[root@pruebas ~]# systemctl enable sshd-second.service --now

Created symlink /etc/systemd/system/multi-user.target.wants/sshd-
second.service → /etc/systemd/system/sshd-second.service.
7. Verificar que el servicio sshd-second.service se esté

ejecutando:
[root@pruebas ~]# systemctl status sshd-second.service

● sshd-second.service - OpenSSH segundo server daemon
Loaded: loaded (/etc/systemd/system/sshd-second.service; enabled;
vendor preset: disabled)
Active: active (running) since Fri 2021-02-26 11:20:33 -05; 33s ago
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 4043 (sshd)
Tasks: 1 (limit: 186748)
Memory: 1.1M
CGroup: /system.slice/sshd-second.service
└
└─4043 /usr/sbin/sshd -D -f /etc/ssh/sshd-second_config -
oCiphers=aes256-gcm@openssh.com,chacha20-poly1305@openss>
Feb 26 11:20:33 pruebas.aptivalabs systemd[1]: Starting OpenSSH

segundo server daemon...
Feb 26 11:20:33 pruebas.aptivalabs sshd[4043]: Server listening on
0.0.0.0 port 22220.
Feb 26 11:20:33 pruebas.aptivalabs sshd[4043]: Server listening on
:: port 22220.
Feb 26 11:20:33 pruebas.aptivalabs systemd[1]: Started OpenSSH
segundo server daemon.
8. Agregar el puerto para que el firewall permita escuchar

peticiones en el puerto 22220/tcp de la zona activa
[root@pruebas ~]# firewall-cmd --permanent --add-

port=22220/tcp
Success
[root@pruebas ssh]# firewall-cmd --reload

success
9. Desde un cliente SSH, verificar la funcionalidad creando una

conexión a esta segunda instancia del servicio SSHD la cual
escucha en el puerto 22220/tcp
$ ssh -l root -p 22220 192.168.0.200

Web console: https://pruebas.aptivalabs:9090/ or
https://192.168.0.200:9090/
Last login: Fri Feb 26 11:01:41 2021 from 192.168.0.35

TUNING A SYSTEMD PARA MINIMIZAR
EL TIEMPO DE BOOTEO
Los archivos de unidad se ejecutan automáticamente en el arranque, lo
que influye en el tiempo de arranque. Hay una lista de archivos de unidad
que están habilitados de forma predeterminada, servicios del sistema que son
definidos por estos archivos de unidad.
Para examinar el rendimiento de arranque del sistema, puede utilizar el

comando “systemd-analyse”. Esta herramienta tiene muchas opciones
disponibles. Sin embargo, este apartado cubre solo los parámetros pueden
ser importantes para el tuning, con el cual systemd puede acortar el tiempo
de arranque del sistema Linux.
Para empezar, listemos algunos de los servicios que se están ejecutando

en el sistema:
[root@pruebas ~]# systemctl list-unit-files --state=enabled

UNIT FILE STATE
cups.path enabled
bluetooth.service enabled
chronyd.service enabled
crond.service enabled
cups.service enabled
firewalld.service enabled
selinux-autorelabel-mark.service enabled
smartd.service enabled
sshd-second.service enabled
sshd.service enabled
sssd.service enabled
syslog.service enabled
timedatex.service enabled
tuned.service enabled
Su listado puede mostrarle una gran cantidad de servicios. A

continuación digite la instrucción “systemd-analyze” para visualizar la
información por default, como se muestra a continuación:
[root@pruebas ~]# systemd-analyze
Startup finished in 1.489s (kernel) + 7.341s (initrd) + 1min 3.037s
(userspace) = 1min 11.868s
graphical.target reached after 35.081s in userspace
De la siguiente forma es posible ver cuanto tiempo se toma cada unidad

de systemd en el proceso de arranque del sistema Linux:
[root@pruebas ~]# systemd-analyze blame

47.591s dnf-automatic-install.service
19.492s plymouth-quit-wait.service
13.912s insights-client-results.service
12.390s kdump.service
6.063s dnf-makecache.service
5.223s initrd-switch-root.service
2.966s vdo.service
2.878s udisks2.service
2.820s lvm2-monitor.service
2.657s systemd-udev-settle.service
2.552s libvirtd.service
2.519s NetworkManager-wait-online.service
2.296s sssd.service
2.167s httpd.service
2.142s firewalld.service
2.117s polkit.service
2.033s tuned.service
1.908s unbound-anchor.service
1.853s dracut-initqueue.service
Para identificar las unidades que tardaron más en inicializarse en el

último arranque exitoso, use la siguiente instrucción:
La salida de la anterior instrucción detalla las unidades que ralentizan
críticamente el arranque del sistema Linux destacándolas con el color rojo.
El tuning para optimizar resulta en deshabilitar (haciendo un “systemctl
disable service_name”) un servicio para que no se active en el arranque del
sistema Linux, sin embargo, no todos los servicios se pueden deshabilitar.
Los servicios que NO se pueden deshabilitar dado a que son claves para
un arranque seguro del sistema operativo son los siguientes: autovt@.service
, getty@.service, microcode.service, rhsmcertd.servic2. El resto de los
servicios listados previamente, son susceptibles de activación en el arranque
de la maquina pero se debe validar si la funcionalidad se está usando en el
sistema operativo antes de entra a desactivar, por ejemplo los servicios:
LVM, SELinux, Syslog, SSH, etc.
Usted podría encontrar información sobre un servicio utilizando las

siguientes instrucciones:
[root@pruebas ssh]# systemctl cat sshd-second.service
# /etc/systemd/system/sshd-second.service
[Unit]
Description=OpenSSH segundo server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.target sshd.service
Wants=sshd-keygen.target
[Service]
Type=notify
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
$CRYPTO_POLICY
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
[root@pruebas ssh]# systemctl help sshd-second.service

GESTIÓN DE PROCESOS
Un proceso es una instancia en ejecución de un programa. Cuando
usted ejecuta un programa, este programa puede generar procesos
asociados. Cuando se ejecuta un proceso por cada uno de ellos se generan:
Un espacio de direcciones de memoria asignada

Propiedades de seguridad, incluidas las credenciales de propiedad
y los privilegios.
Uno o más subprocesos de ejecución de código de programa
Estado del proceso
A cada nuevo proceso se le asigna un ID de proceso único (PID) para el

seguimiento y seguridad. El PID y el ID de proceso principal (PPID) son
elementos del nuevo entorno de proceso. Cualquier proceso puede crear un
proceso hijo. Todos los procesos son descendientes del primer proceso del
sistema, en este caso “SystemD”.
ESTADO DE LOS PROCESOS
Los siguientes son los estados en los cuales usted puede encontrar los
procesos en el sistema:
ESTADO FLAG DESCRIPCIÓN

El proceso se está ejecutando
en una CPU o está esperando para
ejecutarse. El proceso puede
ejecutar rutinas de usuario o
Running R
rutinas del kernel (llamadas al
sistema), o estar en cola y listo
cuando esté en el estado En
ejecución (o Ejecutable).
El proceso está esperando
Sleeping S alguna condición para volver al
estado Running.
Este proceso también
está durmiendo, pero a
D
diferencia del estado S,
no responde a las señales.
Idéntico al estado D,
pero modificado para
permitir que una tarea en
K
espera responda a la señal
de que debe ser
eliminada.
I Un subconjunto del
estado D. El kernel no
cuenta estos procesos al
calcular el promedio de
carga. Se utiliza para
subprocesos del núcleo.
Acepta señales
enviadas por Kill.
El proceso ha sido detenido
(suspendido), generalmente por
un usuario u otro proceso. El
Stopped T
proceso puede puede ser
reanudado por otra señal para
volver a Running.
Un proceso que se
está en modo debug
también es
T
temporalmente detenido y
comparte la misma
bandera del estado T.
Un proceso hijo señala a su
padre cuando termina su
Zombie Z ejecución. Todos los recursos
excepto el identificador del
proceso (PID) se liberan.
Cuando el proceso
padre limpia los procesos
hijos en ejecución, los
procesos hijos se liberan
X
por completo. Este estado
nunca será observado en
las utilidades de listado
de procesos.
VISUALIZANDO PROCESOS DEL
SISTEMA
Es posible visualizar los procesos que el sistema está ejecutando de
varias maneras, como se irá demostrando de forma progresiva; iniciaremos a
ver los procesos de forma básica, todo con el comando “ps”, como se
Visualización de procesos de usuario:
[root@pruebas datos]# ps
PID TTY TIME CMD
4803 pts/0 00:00:00 bash
6388 pts/0 00:00:00 ps
Visualización de procesos de todos los usuarios:
[root@pruebas datos]# ps -fe

root 1 0 0 08:43 ? 00:00:06 /usr/lib/systemd/systemd --switched-root --
system --deserializ
root 2 0 0 08:43 ? 00:00:00 [kthreadd]
El programa “ps” tiene cantidad de variantes que usted puede usar para
visualizar los procesos del sistema.
[root@pruebas datos]# ps lax

F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY
TIME COMMAND
4 0 1 0 20 0 246196 14824 do_epo Ss ? 0:06 /usr/lib/systemd/systemd --
switched-root
1 0 2 0 20 0 0 0 - S ? 0:00 [kthreadd]
1 0 3 2 0 -20 0 0- I< ? 0:00 [rcu_gp]
Un listado personalizado podría generarse de la siguiente forma:

[root@pruebas ~]# ps -eo pid,nice,comm,%cpu,%mem
PID NI COMMAND %CPU %MEM
1 0 systemd 0.0 0.0
2 0 kthreadd 0.0 0.0
3 -20 rcu_gp 0.0 0.0
4 -20 rcu_par_gp 0.0 0.0
6 -20 kworker/0:0H-kb 0.0 0.0
8 -20 mm_percpu_wq 0.0 0.0
En el anterior listado se puede visualizar el identificador del proceso

(PID), la prioridad del proceso (NICE), el programa que generó el proceso
(COMM), y los procentajes de uso y consumo de CPU y memoria del
sistema. Una forma de visualizar los procesos asociados al usuario “root”
podría ser la siguiente:
[root@pruebas ~]# pgrep -u root

1
2
3
4
De la siguiente forma es posible listar los procesos asociados a un

usuario y servicio en particular, como se muestra a continuación:
[root@pruebas ~]# pgrep -u root sshd

1670
1678
4776
4801
Para visualizar los procesos en forma de árbol usted podría realizar lo

siguiente:
[root@pruebas ~]# ps -ejH

PID PGID SID TTY TIME CMD
2 0 0? 00:00:00 kthreadd
3 0 0? 00:00:00 rcu_gp
4 0 0? 00:00:00 rcu_par_gp
6 0 0? 00:00:00 kworker/0:0H-kblockd
Otra forma para apreciar la salida de un proceso en forma de árbol es la
que sigue:
[root@pruebas ~]# ps axjf

PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1670 4776 4776 4776 ? -1 Ss 0 0:00 \_ sshd: root [priv]
4776 4801 4776 4776 ? -1 S 0 0:00 | \_ sshd: root@pts/0
4801 4803 4803 4803 pts/0 6681 Ss 0 0:00 | \_ -bash
4803 6681 6681 4803 pts/0 6681 R+ 0 0:00 | \_ ps axjf
1670 6567 6567 6567 ? -1 Ss 0 0:00 \_ sshd: root [priv]
6567 6570 6567 6567 ? -1 S 0 0:00 \_ sshd: root@pts/1
6570 6572 6572 6572 pts/1 6644 Ss 0 0:00 \_ -bash
6572 6644 6644 6572 pts/1 6644 S+ 0 0:00 \_ man ps
6644 6658 6644 6572 pts/1 6644 S+ 0 0:00 \_ less
En todo caso, usted debe tener presente que los procesos tienen un
identificador (PID), un proceso padre que es el que lo soporta (PPID), una
hora de inicio, una prioridad, un sitio de ejecución (TTY= consola Linux,
pseudo terminal), un usuario que lo genera, entre otros. El tener esta
información permitirá gestionar los procesos al acomodo del administrador
del sistema. todas las consultas realizadas a procesos son hechas al “kernel”
de Linux, esta información generalmente viene de un sistema de archivos
virtual montado en /proc.
Para visualizar los procesos en ejecución de una forma distinta, el

sistema Linux le proporciona la herramienta “top”, la cual le permitirá
conocer otra información que el comando “ps” no le puede mostrar:
Información relacionada con los promedios de uso de CPU, tiempo de
encendido, usuarios conectados, prioridades, usuario propietario del proceso,
PID, uso de memoria SWAP, entre otras, es posible visualizar gracias al
comando “top”.
ENVÍO DE SEÑALES A LOS PROCESOS
A través del comando “kill” es posible enviar los diferentes tipos de
señales a los procesos. Normalmente algunas personas con conocimientos
básicos en administración de sistemas Linux utilizan este comando para
eliminar procesos y se ha creado una idea generalizada que este es el único
uso que tan aplicación tiene, cuanto la función principal es el envío de
señales, que en total son 64, como se muestra a continuación:
[root@pruebas ~]# kill -l

1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL10) SIGUSR1
11) SIGSEGV12) SIGUSR213) SIGPIPE14) SIGALRM15) SIGTERM
16) SIGSTKFLT17) SIGCHLD18) SIGCONT19) SIGSTOP20) SIGTSTP
21) SIGTTIN22) SIGTTOU23) SIGURG24) SIGXCPU25) SIGXFSZ
26) SIGVTALRM27) SIGPROF28) SIGWINCH29) SIGIO30) SIGPWR
31) SIGSYS34) SIGRTMIN35) SIGRTMIN+136) SIGRTMIN+237) SIGRTMIN+3
38) SIGRTMIN+439) SIGRTMIN+540) SIGRTMIN+641) SIGRTMIN+742) SIGRTMIN+8
43) SIGRTMIN+944) SIGRTMIN+1045) SIGRTMIN+1146) SIGRTMIN+1247) SIGRTMIN+13
48) SIGRTMIN+1449) SIGRTMIN+1550) SIGRTMAX-1451) SIGRTMAX-1352) SIGRTMAX-12
53) SIGRTMAX-1154) SIGRTMAX-1055) SIGRTMAX-956) SIGRTMAX-857) SIGRTMAX-7
58) SIGRTMAX-659) SIGRTMAX-560) SIGRTMAX-461) SIGRTMAX-362) SIGRTMAX-2
63) SIGRTMAX-164) SIGRTMAX
Realicemos una demostración en dos consolas como usuario “root” para

lograr un mejor entendimiento, como se muestra a continuación:
Envíe el siguiente comando como sigue en la primera consola (déjelo

ejecutarse):
[root@pruebas ~]# yes hola
En la segunda consola identifique el número del proceso relacionado

como el comando “yes”:
[root@pruebas ~]# ps -e
7210 pts/0 00:00:06 yes
El PID 7210 es el proceso por trabajar en esta demostración. A

continuación detendremos el proceso enviando una señal:
[root@pruebas ~]# kill -19 7210

La ejecución de esta instrucción en la consola donde se ejecuta el
comando “yes” nos mostrará una salida como esta:

hola
hola
[1]+ Stopped yes hola
El proceso 7210 aun sigue con vida, pero está en estado suspendido. Si
usted desea que este proceso continúe en ejecución podría enviarle la señal
18:
La forma adecuada de terminar un proceso es enviándole la señal 15:
Esto provocará la terminación normal del mismo, como se visualiza a

continuación en la primera consola donde se envió el comando “yes hola”:
hola
hola
hola
[1]+ Terminated yes hola
Otra forma de enviar señales a los procesos es utilizando combinaciones

de teclas como CTRL+Z, el cual detiene un proceso, o CTRL+C, el cual
elimina un proceso en ejecución. Muchas personas eliminan los procesos
enviando la señal 9, el uso sin control de esta señal podría traer corrupción
en bases de datos, sistemas de archivos, etc, use la señal 9 cuando la opción
15 no sea satisfactoria y sepa usted que va a pasar cuando envíe esta señal.
El comando “kill” le permite enviar señales a procesos con el uso de las

palabras obtenidas en un “kill -l”, como se muestra a continuación:
[root@pruebas ~]# kill -SIGTERM 7364

En este caso SIGTERM es el equivalente a la señal 15. A continuación
se muestra como eliminar todos los procesos generados por un usuario en
particular, en este caso los procesos generados por el usuario “fmestre”:
En una consola se genera un proceso, en este caso uno generado por el

comando “yes”, como se muestra a continuación:
[fmestre@pruebas ~]$ yes
Seguidamente usted podrá enviar la señal de eliminación correspondiente

a través del comando “killall” para que elimine todo lo relacionado con el
usuario “fmestre”, como se detalla:
[root@pruebas ~]# killall -u fmestre -s 15
Una salida como esta es la resultante del comando anterior, en la cual se

evidencia inclusive la eliminación del proceso “bash” de ese usuario y su
inmediata salida del sistema:

y
y
packet_write_wait: Connection to 192.168.0.200 port 22: Broken
pipe
ADMINISTRACIÓN DE LA PRIORIDAD
La ejecución de un proceso dentro del sistema tiene como atributo la
prioridad de ejecución de este. Normalmente cuando un proceso es lanzado
en su ejecución se define una prioridad frente a los otros procesos que están
ejecución. Lo podemos ver en la siguiente demostración, donde en una
consola se envía el programa “fdisk” en la forma tradicional, visualizándose
su prioridad, la cual por default inidica que es “0”, como se muestra a
continuación:
[root@pruebas ~]# fdisk /dev/sdc
[root@pruebas ~]# ps -eo pid,nice,comm | more

PID NI COMMAND
8820 0 fdisk
Es posible entonces definir la prioridad para un proceso en el momento

de su lanzamiento, como es el caso del siguiente ejemplo, donde se define
una prioridad “5” frente a los otros procesos del sistema, verificando
entonces con un “ps” personalizado:
[root@pruebas ~]# nice -n 5 fdisk /dev/sdc
Welcome to fdisk (util-linux 2.32.1).

Changes will remain in memory only, until you decide to write
them.
Be careful before using the write command.

PID NI COMMAND
8942 5 fdisk
Aunque no es común usar el comando “nice” para el particionamiento de

un dispositivo de bloque si es útil en otros casos donde usted sabe que
ejecutará un proceso que se tomará un tiempo prudente para ejecutarse. Los
valores de “nice” van de -20 (más prioridad al proceso) a 19 (menos
prioridad al proceso); entre mas negativo sea el número mayor prioridad
tendrá frente al uso de CPU. Usted podrá ver la prioridad frente a la CPU de
un proceso en ejecución a través del uso del comando “top”.
Se presenta el caso donde se manifiesta la necesidad de cambiar la

prioridad a un proceso que está en plena ejecución, por ejemplo, un backup
que ya está lanzado o algún otro proceso similar; en este caso el sistema nos
brinda la posibilidad de usar el comando “renice” para alterar la prioridad
del proceso, como se ve en esta demostración:
Se envía con una prioridad 10 el comando “yes”, como se evidencia en el

listado personalizado de los procesos:
[root@pruebas ~]# nice -n 10 yes hola

PID NI COMMAND
9066 10 yes
Una vez se ha obtenido el PID 9066 es posible cambiar la prioridad de la

instrucción anteriormente definida, sea para darle mayor o menos prioridad
frente a la CPU , como se muestra a continuación:
[root@pruebas ~]# renice -n 5 9066

9066 (process ID) old priority 10, new priority 5

PID NI COMMAND
9066 5 yes
MONITOREANDO LA ACTIVIDAD DE LOS
PROCESOS
Diversas estadísticas se pueden obtener a través de la interacción con los
procesos del sistema, el siguiente comando nos permitirá conocer el
promedio de carga del sistema, el número de usuarios conectados, la hora
actual asi como el tiempo de encendido del sistema:
[root@pruebas ~]# uptime

13:41:14 up 4:57, 2 users, load average: 0.34, 0.36, 0.38
Los tres valores para el promedio de carga representan la carga durante

los últimos 1, 5 y 15 minutos. Un vistazo indica nos muestra que la carga del
sistema parece estar disminuyendo. El promedio de carga es una medida
aproximada de cuántos procesos están esperando actualmente una solicitud
para completar antes de que puedan realizar otra cosa.
Para el monitoreo de procesos se cuenta con la aplicación “lscpu”, la

cual nos muestra información relacionada con nuestro procesador, como se
[root@pruebas ~]# lscpu

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 8
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 44
Model name: Intel(R) Xeon(R) CPU X5670 @
2.93GHz
Stepping: 2
CPU MHz: 2925.998
BogoMIPS: 5851.99
Hypervisor vendor: KVM
Virtualization type: full
Para este caso en particular podemos observar un sistema con un solo

procesador y ocho (8) cores y un hilo por cada core. El comando “w” nos
muestra información parecida a “uptime” así como de usuarios conectados al
sistema Linux:
[root@pruebas ~]# w
13:59:57 up 5:16, 2 users, load average: 0.29, 0.25, 0.29
USER TTY FROM LOGIN@ IDLE JCPU PCPU
WHAT
fmestre pts/0 192.168.0.35 13:59 4.00s 0.02s 0.02s -bash
root pts/1 192.168.0.35 13:12 0.00s 0.09s 0.02s w
ADMINISTRACIÓN DE JOBS
El control de tareas es una característica del “shell” el cual le permite a
una instancia de “shell” administrar múltiples comandos. Se podría
considerar un “job” como un proceso que se ejecuta en una terminal, el cual
queda en ejecución hasta determinado momento; este proceso puede
enviarse a ejecución en un segundo plano (background) o permitir que se
ejecute en la terminal hasta que finalice. A continuación veremos algunas
demostraciones que nos amplían esta conceptualización:
Utilizaremos para esta demostración inicial el comando “sleep”, sea esta

la oportunidad para “dormir” el Shell por 30 segundos como se muestra:
[root@pruebas ~]# sleep 30s
Si ha ejecutado el comando previamente ha debido de haber “perdido” el

shell por 30 segundos, durante ese tiempo no tuvo la oportunidad de volver a
enviar otro comando en el sistema pues la terminal estaba ocupada, cosa
diferente si lo hubiese hecho de la siguiente forma:
[root@pruebas ~]# sleep 30s &

[1] 10253
El símbolo “&” envió la ejecución del comando “sleep” a lo que se

conoce como background, mostrándonos por pantalla el número del proceso,
en este caso el PID 10253. Al haber enviado este proceso para al
background se ha generado un proceso como lo muestra la siguiente salida:
[root@pruebas ~]# jobs

[1]+ Running sleep 30s &
Se observa que al listar los “jobs” hemos podido visualizar en la salida el

dato “[1]+” lo que quiere decir que se ha generado para esta terminal el job #
1 y como el proceso se estableció para 30 segundos, una vez transcurrido ese
tiempo, el “job” se da por finalizado, como se muestra:
[1]+ Done sleep 30s
Con la siguiente instrucción, generaremos otro “job” que ejecute el

comando “sleep” por 60 segundos en el background, luego con el comando
“fg” traeremos el “job” al foreground, como se muestra a continuación:
[root@pruebas ~]# sleep 60s &

[1] 10338
[root@pruebas ~]# fg %1
sleep 60s
Al traer la tarea para el foreground perderemos el control de la consola

por los segundos restantes, hasta que el comando “sleep” la libere. En vista
de la perdida de la terminal, usted podría recuperarla suspendiendo la tarea
como se muestra:
[root@pruebas ~]# fg %1
sleep 60s
^Z
[1]+ Stopped sleep 60s
Al suspender la tarea este proceso queda “dormido” esperando

instrucción por parte del usuario, usuario que recupera la terminal y puede
enviar el proceso a un segundo plano tal como se muestra a continuación:
[root@pruebas ~]# bg %1
[1]+ sleep 60s &

[1]+ Done sleep 60s
Para explicar de forma clara esta temática hemos utilizado el comando

“sleep”, sin embargo, el uso mas común de esta conceptualización se aplica
en la ejecución de scripts que realizan tareas que demoran un tiempo
prudente en ejecutarse.
Para finalizar esta temática, es importante hablar del comando “nohup” y
se lo voy a explicar con un caso de la vida real: usted es un Linux Admin y
necesita ejecutar un script desde su casa pero usted tiene una conexión a
Internet no muy estable, cuando usted ejecuta un script con “nohup” puede
estar tranquilo de que el script se ejecuta en su servidor remoto sin importar
que su conexión se caiga, como se muestra en este ejemplo:
[root@pruebas ~]# nohup /root/./calcula-salarios.sh &

AJUSTES AL RENDIMIENTO DEL
SISTEMA
Los administradores de sistemas Linux pueden optimizar el rendimiento
de éste ajustando varias configuraciones en función de diversas cargas de
trabajo. El servicio “tuned” permite aplicar ajustes de tuning de forma
estática y dinámicamente, utilizando perfiles que reflejan requerimientos
particulares de estas cargas de trabajo.
Cuando se habla de tuning estático, el servicio “tuned” aplica

configuraciones cuando el sistema inicia o en el momento de la selección de
un nuevo perfil de rendimiento, estos son parámetros predefinidos para el
kernel que el servicio “tuned” aplica en el momento de la ejecución. Con el
ajuste estático, los parámetros del kernel se establecen para el rendimiento
general y no se ajustan a medida que cambian los niveles de actividad.
Con el ajuste dinámico, el servicio “tuned” supervisa la actividad del

sistema y ajusta la configuración según el comportamiento en tiempo de
ejecución. Con el servicio “tuned” en aplicación dinámica el sistema se está
ajustando continuamente para adaptarse a las cargas de trabajo en ejecución,
iniciando con la configuración declarada en el perfil de ajuste elegido.
Antes de aplicar configuraciones sobre los perfiles es necesario saber si

el servicio “tuned” se encuentra activo y si está definido para iniciar en el
arranque de la maquina:
[root@pruebas ~]# systemctl is-active tuned

active
[root@pruebas ~]# systemctl is-enabled tuned

enabled
El servicio “tuned” proporciona perfiles en las categorías de ahorro de

energía y mejora en el rendimiento del sistema. Los perfiles para mejora del
rendimiento del sistema tienen como foco principal lograr una baja latencia
para almacenamiento y red, un alto rendimiento para almacenamiento y red,
un buen performance para operaciones en maquinas virtuales y los hosts que
soportan la virtualización.
El sistema Linux nos da la posibilidad de conocer los diferentes perfiles

que se pueden aplicar para optimizar su rendimiento dependiendo de la carga
de trabajo que se requiera ejecutar, como se muestra a continuación:
[root@pruebas ~]# tuned-adm list

Available profiles:
- accelerator-performance - Throughput performance based tuning with disabled higher
latency STOP states
- balanced - General non-specialized tuned profile
- desktop - Optimize for the desktop use-case
- hpc-compute - Optimize for HPC compute workloads
- intel-sst - Configure for Intel Speed Select Base Frequency
- latency-performance - Optimize for deterministic performance at the cost of
increased power consumption
- network-latency - Optimize for deterministic performance at the cost of increased
power consumption, focused on low latency network performance
- network-throughput - Optimize for streaming network throughput, generally only
necessary on older CPUs or 40G+ networks
- optimize-serial-console - Optimize for serial console use.
- powersave - Optimize for low power consumption
- throughput-performance - Broadly applicable tuning that provides excellent
performance across a variety of common server workloads
- virtual-guest - Optimize for running inside a virtual guest
- virtual-host - Optimize for running KVM guests
Current active profile: virtual-guest
Esta última instrucción nos permite ver los perfiles que se pueden aplicar
en los sistemas Linux junto con sus respectivas descripciones; la siguiente
instrucción nos permitirá visualizar el perfil activo, el cual está definido al
momento de ejecución:
[root@pruebas ~]# tuned-adm active

Current active profile: virtual-guest
Si en algún momento se hace necesario cambiar el perfil activo por otro

requerido para mejorar el rendimiento del sistema en función de la carga de
trabajo, usted podría hacer lo siguiente:
[root@pruebas ~]# tuned-adm profile virtual-host

Current active profile: virtual-host
Se ha cambiado el perfil a “virtual-host” suponiendo que el hosts Linux

se dedica a hospedar maquinas virtuales, sin embargo el servicio “tuned” le
puede recomendar cual es el perfil indicado para ejecutar en su sistema,
[root@pruebas ~]# tuned-adm recommend

virtual-guest

Current active profile: virtual-host
Usted podría desactivar el servicio “tuned” de la siguiente manera:
[root@pruebas ~]# tuned-adm off

No current active profile.
GESTIÓN DEL KERNEL
El kernel es la parte central de un sistema operativo Linux que
administra los recursos del sistema y proporciona una interfaz entre las
aplicaciones de hardware y software. Antes de que Red Hat lance una nueva
versión del kernel, este debe pasar un conjunto de rigurosos requisitos de
calidad en pruebas de aseguramiento. Los kernels de Red Hat están
empaquetados en formato RPM para que sean fáciles de actualizar y
verificar por el administrador de paquetes yum.
El kernel RPM es un metapaquete que no contiene ningún archivo, sino

que garantiza que las siguientes sub-aplicaciones estén instaladas
correctamente:
kernel-core: contiene una cantidad mínima de módulos del

kernel necesarios para la funcionalidad del núcleo.
kernel-modules: contiene más módulos del kernel.
kernel-modules-extra: contiene módulos del kernel para
hardware poco común.
kernel-debug: contiene un kernel con numerosas opciones de
depuración habilitadas para su diagnóstico.
kernel-tools: contiene herramientas para manipular el kernel
además de documentación de apoyo.
kernel-devel: contiene los encabezados del kernel y los
“makefiles” para compilar módulos del kernel.
kernel-abi-whitelists: contiene información relacionada con el
kernel RHEL ABI
kernel-headers: incluye los archivos de encabezado que
especifican la interfaz entre las aplicaciones Linux, bibliotecas de
kernel y el espacio de usuario. Los archivos de encabezado definen
estructuras que son necesarias para crear la mayoría de los
programas en el sistema.
Si listamos los paquetes instalados asociados al kernel podemos ver la

siguiente salida:
[root@pruebas Packages]# yum list installed | grep kernel
kernel.x86_64 4.18.0-240.8.1.el8_3 @rhel-8-for-
x86_64-baseos-rpms
x86_64-baseos-rpms
x86_64-baseos-rpms
kernel-core.x86_64 4.18.0-240.8.1.el8_3 @rhel-8-for-
x86_64-baseos-rpms
x86_64-baseos-rpms
x86_64-baseos-rpms
kernel-headers.x86_64 4.18.0-240.15.1.el8_3 @rhel-8-
for-x86_64-baseos-rpms
kernel-modules.x86_64 4.18.0-240.8.1.el8_3 @rhel-8-
kernel-tools.x86_64 4.18.0-240.15.1.el8_3 @rhel-8-for-
x86_64-baseos-rpms
kernel-tools-libs.x86_64 4.18.0-240.15.1.el8_3 @rhel-8-
Después de detallar el listado anterior podemos observar que existen

varios kernel instalados, sin embargo, solo se permite uno en ejecución; los
kernels instalados y su respectivo versionamiento son los siguientes:
kernel.x86_64 4.18.0-240.8.1.el8_3 @rhel-8-for-x86_64-baseos-rpms
Otra forma de visualizar los kernels disponibles para ejecutar en su

sistema es la siguiente:
[root@pruebas ~]# grubby --info=ALL | grep title

title="Red Hat Enterprise Linux (4.18.0-240.15.1.el8_3.x86_64) 8.3 (Ootpa)"
title="Red Hat Enterprise Linux (0-rescue-0592fcddc9a04f118fa2e5538498f91f) 8.3 (Ootpa)"
Usted podrá conocer información mas a profundidad como se muestra a

continuación:
[root@pruebas Packages]# yum info kernel-core.x86_64

Last metadata expiration check: 0:36:52 ago on Thu 18 Mar 2021 03:04:06 PM -05.
Installed Packages
Name : kernel-core
Version : 4.18.0
Release : 240.10.1.el8_3
Architecture : x86_64
Size : 62 M
Source : kernel-4.18.0-240.10.1.el8_3.src.rpm
Realizar operaciones relacionadas con la gestión del kernel tiene su

riesgo pues alguna mala configuración vuelve inoperable el sistema
operativo. Los archivos del kernel que haya instalado en su servidor se
guardarán en el directorio /boot, GRUB2 toma todos los kernels que
encuentran en este directorio para la gestión del arranque.
[root@pruebas ~]# ll -h /boot/

total 424M
-rw-------. 1 root root 101M Dec 17 17:17 initramfs-0-rescue-0592fcddc9a04f118fa2e5538498f91f.img
-rw-------. 1 root root 51M Feb 3 18:24 initramfs-4.18.0-240.10.1.el8_3.x86_64.img
-rw-------. 1 root root 19M Feb 18 14:41 initramfs-4.18.0-240.10.1.el8_3.x86_64kdump.img
-rw-------. 1 root root 101M Mar 9 11:43 initramfs-4.18.0-240.15.1.el8_3.x86_64.img
-rw-------. 1 root root 19M Mar 3 11:34 initramfs-4.18.0-240.15.1.el8_3.x86_64kdump.img
-rw-------. 1 root root 51M Dec 17 17:32 initramfs-4.18.0-240.8.1.el8_3.x86_64.img
-rw-------. 1 root root 19M Dec 18 09:51 initramfs-4.18.0-240.8.1.el8_3.x86_64kdump.img
-rw-------. 1 root root 19M Dec 17 17:31 initramfs-4.18.0-240.el8.x86_64kdump.img
drwxr-xr-x. 3 root root 21 Dec 17 17:14 loader
-rw-r--r--. 1 root root 15K Jun 24 2020 tboot-syms
-rw-r--r--. 1 root root 112K Jun 24 2020 tboot.gz
-rwxr-xr-x. 1 root root 9.1M Dec 17 17:16 vmlinuz-0-rescue-0592fcddc9a04f118fa2e5538498f91f
-rwxr-xr-x. 1 root root 9.1M Dec 16 03:48 vmlinuz-4.18.0-240.10.1.el8_3.x86_64
-rwxr-xr-x. 1 root root 9.1M Feb 3 03:21 vmlinuz-4.18.0-240.15.1.el8_3.x86_64
ADMINISTRACIÓN DE MODULOS DEL
KERNEL
El kernel de Red Hat Enterprise Linux se puede ampliar con funciones
adicionales gracias a los módulos del kernel, todo esto sin la necesidad de
tener que reiniciar el sistema. En RHEL 8 los modulos del kernel son código
extra integrado en archivos comprimidos como el ejemplo que se lista, un
modulo asociado al sistema de archivos XFS:
[root@pruebas ~]# ll /lib/modules/4.18.0-

240.8.1.el8_3.x86_64/kernel/fs/xfs/
total 436
-rw-r--r--. 1 root root 442488 Dec 4 12:50 xfs.ko.xz
Las funcionalidades más comunes habilitadas por los módulos del kernel
son:
Control de los dispositivos de hardware

Soporte para un sistema de archivos como GFS2 o NFS
Administración de los “syscalls”
En los sistemas modernos, los módulos del kernel se cargan

automáticamente cuando es necesario, sin embargo, en algunos casos es
necesario cargar o descargar módulos de forma manual, estos módulos
pueden tomar parámetros que personalicen su comportamiento si es
necesario.
Usted podrá listar los módulos del kernel de la siguiente forma:
[root@pruebas ~]# lsmod

ModuleSize Used by
binfmt_misc 20480 1
xt_CHECKSUM 16384 1
ipt_MASQUERADE 16384 3
xt_conntrack 16384 1
ipt_REJECT 16384 2
nf_nat_tftp 16384 0
nft_objref 16384 1
nf_conntrack_tftp16384 3 nf_nat_tftp
nft_counter 16384 33
tun 53248 1
La primera columna en el listado visualiza el nombre del modulo del

kernel que está cargado. La segunda columna muestra la cantidad de
memoria (kilobytes) en uso ocupada por ese modulo. La última columna
muestra el número y opcionalmente el nombre de los módulos que son
dependientes.
Para conocer a profundidad la información de un modulo usted podrá
realizar lo siguiente:
[root@pruebas ~]# modinfo xfs

filename:/lib/modules/4.18.0-240.15.1.el8_3.x86_64/kernel/fs/xfs/xfs.ko.xz
license:GPL
description: SGI XFS with ACLs, security attributes, no debug enabled
author: Silicon Graphics, Inc.
alias:fs-xfs
rhelversion:8.3
srcversion: CF1ACE4802B08318ACE63CF
depends:libcrc32c
intree:Y
name:xfs
vermagic: 4.18.0-240.15.1.el8_3.x86_64 SMP mod_unload modversions
sig_id:PKCS#7
signer:Red Hat Enterprise Linux kernel signing key
sig_key:25:D1:E4:42:29:FE:4A:1B:1A:8F:76:33:4E:12:A1:A7:F6:B4:A2:67
sig_hashalgo:sha256
signature:65:13:2D:FB:13:D1:27:DE:20:A9:78:61:EF:67:E7:84:43:67:DF:D9:
7A:BA:BE:59:0E:76:D5:7C:1E:CE:C6:38:DC:22:FC:80:63:3A:EB:48:
7C:7A:48:40:58:02:3D:1E:C4:34:C1:AC:98:EC:78:92:35:F0:29:B6:
Es posible deshabilitar un modulo del kernel como se muestra a
continuación:
[root@pruebas ~]# lsmod

Module Size Used by
iscsi_tcp 24576 0
[root@pruebas ~]# modprobe -r iscsi_tcp
[root@pruebas ~]# lsmod | grep iscsi_tcp

libiscsi_tcp 28672 2 libcxgbi,cxgb4i
De la siguiente forma habilitamos nuevamente el modulo del kernel

anteriormente deshabilitado:
[root@pruebas ~]# modprobe iscsi_tcp
[root@pruebas ~]# lsmod | grep iscsi_tcp

iscsi_tcp 24576 0
DEPENDENCIA EN LOS MODULOS DEL
KERNEL
Tocamos previamente el tema de las dependencias. Para ampliar el
tema, algunos módulos del kernel requieren de otros módulos para aplicar su
funcionalidad; esa dependencia es posible visualizarla tal como se muestra,
entrando a la ruta donde se guardan los archivos de cada kernel:
[root@pruebas 4.18.0-240.15.1.el8_3.x86_64]# pwd
/lib/modules/4.18.0-240.15.1.el8_3.x86_64
[root@pruebas 4.18.0-240.15.1.el8_3.x86_64]# ll
total 17204
---- salida omitida
-rw-r--r--. 1 root root 297491 Feb 18 14:41 modules.dep
Un vistazo general al archivo “modules.dep” nos permitiría observar esas

dependencias, como se muestra a continuación:
[root@pruebas 4.18.0-240.15.1.el8_3.x86_64]# more

modules.dep
kernel/arch/x86/events/amd/power.ko.xz:
kernel/arch/x86/events/intel/intel-rapl-perf.ko.xz:
kernel/arch/x86/events/intel/intel-uncore.ko.xz:
kernel/arch/x86/events/intel/intel-cstate.ko.xz:
kernel/arch/x86/kernel/cpu/mce/mce-inject.ko.xz:
kernel/arch/x86/crypto/des3_ede-x86_64.ko.xz: kernel/crypto/des_generic.ko.xz
kernel/arch/x86/crypto/camellia-x86_64.ko.xz:
kernel/arch/x86/crypto/blowfish-x86_64.ko.xz: kernel/crypto/blowfish_common.ko.xz
kernel/arch/x86/crypto/twofish-x86_64.ko.xz: kernel/crypto/twofish_common.ko.xz
Otra forma de listar las dependencias de un módulo en específico es la

siguiente:
[root@pruebas ~]# modprobe --show-depends xfs

insmod /lib/modules/4.18.0-240.15.1.el8_3.x86_64/kernel/arch/x86/crypto/crc32c-
intel.ko.xz
insmod /lib/modules/4.18.0-240.15.1.el8_3.x86_64/kernel/lib/libcrc32c.ko.xz
insmod /lib/modules/4.18.0-240.15.1.el8_3.x86_64/kernel/fs/xfs/xfs.ko.xz
MÓDULOS DEL KERNEL EN BLACKLIST
Se ha comentado que en el momento del arranque, una de las funciones
del kernel es establecerse en el sistema e ir cargando los módulos necesarios
para el funcionamiento estable del mismo. En ese sentido existen casos
donde necesitamos que algunos módulos no se habiliten en ese inicio. A
continuación se explica como limitar al kernel para que ciertos módulos no
se habiliten en el momento del arranque:
Nos posicionamos en la ruta correspondiente para realizar esta actividad:
[root@pruebas ~]# cd /etc/modprobe.d/
[root@pruebas modprobe.d]# pwd

/etc/modprobe.d
Se crea el archivo “blacklist.conf” con el siguiente contenido dentro de

él:
[root@pruebas modprobe.d]# vim blacklist.conf

blacklist fuse
install fuse /bin/false
Es necesario realizar una copia del archivo “initramfs” que es el archivo

“pareja” del archivo “vmlinuz”; recuerde que los kernels se encuentran en la
ruta /boot e inician su nombre con la palabra “vmlinuz” seguido de el
versionamiento establecido; este archivo “vmlinuz” + versión cuenta igual
con su archivo pareja llamado “initramfs” + versión, que es sobre el cual
vamos a realizar el procedimiento:
[root@pruebas boot]# cp /boot/initramfs-$(uname -r).img

/boot/initramfs-$(uname -r).bak.$(date +%m-%d-%H%M%S).img
Se genera un nuevo archivo “initramfs”, como sigue:
[root@pruebas boot]# dracut -fv

dracut: *** Including module: shutdown ***
dracut: *** Including modules done ***
dracut: *** Installing kernel module dependencies ***
dracut: *** Installing kernel module dependencies done ***
dracut: *** Resolving executable dependencies ***
dracut: *** Resolving executable dependencies done***
dracut: *** Hardlinking files ***
dracut: *** Hardlinking files done ***
dracut: *** Generating early-microcode cpio image ***
dracut: *** Constructing AuthenticAMD.bin ****
dracut: *** Constructing GenuineIntel.bin ****
dracut: *** Store current command line parameters ***
dracut: *** Stripping files ***
dracut: *** Stripping files done ***
dracut: *** Creating image file '/boot/initramfs-4.18.0-240.15.1.el8_3.x86_64.img' ***
dracut: *** Creating initramfs image file '/boot/initramfs-4.18.0-
240.15.1.el8_3.x86_64.img' done ***
Al finalizar la operación podemos generar un listado de la carpeta /boot

para confirmar esta operación de generación del nuevo archivo pareja del
kernel, como se muestra:
[root@pruebas boot]# ll -htr

total 525M
-rw-------. 1 root root 101M Mar 19 08:43 initramfs-4.18.0-240.15.1.el8_3.x86_64.bak.03-
19-084319.img
Al hacer un “reboot” del sistema debemos apreciar que el modulo puesto

en blacklist no debería de estar cargado:
[root@pruebas modprobe.d]# modprobe --show-depends fuse
install /bin/false
Realizando esta misma consulta en un sistema con el modulo habilitado

para cargarse en el arranque veremos la siguiente salida:
[root@ap2 ~]# modprobe --show-depends fuse

insmod /lib/modules/4.18.0-
240.el8.x86_64/kernel/fs/fuse/fuse.ko.xz
Si usted desea revertir este procedimiento debe renombrar los archivos
“initramfs”, el que se ha generado con el programa “dracut” debe cambiarle
el nombre, quedando como archivo original la copia previamente realizada;
de igual forma, debe mover o cambiarle el nombre al archivo
/etc/modprobe.d/blacklist.conf, seguido a esto se reinicia y ya podrá ver una
salida simiar a la instrucción anterior.
ESTABLECIENDO UN KERNEL POR
DEFAULT PARA EL ARRANQUE
En apartes anteriores hemos usado la herramienta “grubby”, la cual es
una aplicación que permite gestionar el arranque del sistema realizado por el
GRUB (bootloader). Si miramos la sintaxis de esta aplicación vemos que a
través de ella se hace posible establecer el kernel a usar en el arranque del
sistema operativo. En el siguiente ejercicio explicaremos como establecer el
kernel por default entre diferentes kernels instalados en el sistema. Los
kernels a trabajar son los siguientes:
4.18.0-240.15.1.el8_3.x86_64
4.18.0-240.10.1.el8_3.x86_64
De la siguiente forma podemos ver el kernel por default que está

tomando GRUB para iniciar el sistema Linux:
[root@pruebas ~]# grubby --default-kernel

/boot/vmlinuz-4.18.0-240.15.1.el8_3.x86_64
El comando “uname” también nos muestra la versión del kernel que se

está utilizando en tiempo de ejecución:
[root@pruebas ~]# uname -a

Linux pruebas.aptivalabs 4.18.0-240.15.1.el8_3.x86_64 #1 SMP
Wed Feb 3 03:12:15 EST 2021 x86_64 x86_64 x86_64 GNU/Linux
De la siguiente forma se hace posible establecer el kernel que tomará el

GRUB en su próximo arranque:
[root@pruebas ~]# grubby --set-default /boot/vmlinuz-4.18.0-

240.10.1.el8_3.x86_64
The default is
/boot/loader/entries/0592fcddc9a04f118fa2e5538498f91f-4.18.0-
240.10.1.el8_3.x86_64.conf with index 1 and kernel /boot/vmlinuz-
4.18.0-240.10.1.el8_3.x86_64
El cambio anteriormente realizado no forza la utilización del kernel
establecido en tiempo de ejecución. El comando “uname” seguirá mostrando
el kernel con el que se inició:

Linux pruebas.aptivalabs 4.18.0-240.15.1.el8_3.x86_64 #1 SMP Wed Feb 3 03:12:15 EST
2021 x86_64 x86_64 x86_64 GNU/Linux
En la siguiente instrucción vemos el kernel por default a usar en el

próximo boot:
[root@pruebas ~]# grubby --default-kernel

/boot/vmlinuz-4.18.0-240.10.1.el8_3.x86_64
Reiniciamos el sistema para tener la salida del comando “uname”, como


Linux pruebas.aptivalabs 4.18.0-240.10.1.el8_3.x86_64 #1 SMP Wed Dec 16 03:30:52
EST 2020 x86_64 x86_64 x86_64 GNU/Linux
ENTENDIENDO EL PROCESO DE BOOT
Un buen administrador de Sistemas Operativos debe entender todo el
proceso que ocurre desde que se oprime el botón de encendido hasta que se
llega al objetivo deseado, en el caso de RHEL 8 o cualquier sistema que use
SystemD, hasta llegar al “target” deseado. Los siguientes son los hitos
generales por los cuales va pasando el control de arranque hasta llegar a
proporcionar una interfaz para la comunicación con los usuarios:
1. El servidor es encendido, en ese momento el firmware del

servidor (UEFI o BIOS) es encendido y ejecuta actividades de
testeo sobre el hardware instalado.
2. El firmware del sistema busca por un dispositivo booteable.
3. Una vez encontrado, el firmware pasa el control del arranque

al bootloader, en este caso RHEL 8 ha definido como gestor de
arranque a GRUB2 (GRand Unified Bootloader versión 2).
4. GRUB2 carga su configuración la cual se encuentra definida

en /boot/grub2/grub.cfg, mostrando un menú donde de forma
automática o manual se selecciona el kernel para bootear.
5. Una vez seleccionado el kernel (manual o automático), GRUB

carga el kernel (archivos en /boot/, vmlinuz e initramfs) en la
memoria. El archivo “initramfs” contiene módulos del kernel
relacionados con el hardware donde está instalado el sistema
operativo. La aplicación “dracut” realiza una validación del
archivo “initramfs” correspondiente al kernel elegido, trabajan en
pareja.
[root@pruebas ~]# ll -lh /boot/

total 525M
-rw-------. 1 root root 51M Feb 3 18:24 initramfs-4.18.0-240.10.1.el8_3.x86_64.img
-rw-------. 1 root root 19M Mar 18 17:58 initramfs-4.18.0-
240.10.1.el8_3.x86_64kdump.img
240.15.1.el8_3.x86_64.img.nuevo
240.15.1.el8_3.x86_64kdump.img
-rw-------. 1 root root 51M Dec 17 17:32 initramfs-4.18.0-240.8.1.el8_3.x86_64.img
-rw-------. 1 root root 19M Dec 18 09:51 initramfs-4.18.0-
240.8.1.el8_3.x86_64kdump.img
-rw-------. 1 root root 19M Dec 17 17:31 initramfs-4.18.0-240.el8.x86_64kdump.img
-rwxr-xr-x. 1 root root 9.1M Feb 3 03:21 vmlinuz-4.18.0-240.15.1.el8_3.x86_64
6. GRUB2 entrega el control al kernel quien ya está posicionado

en memoria para gobernar.
7. El kernel inicializa todo el hardware para el cual puede

encontrar módulos en el archivo “initramfs”, luego de ello ejecuta
“SystemD”.
8. La instancia SystemD de “initramfs” ejecuta todas las unidades

requeridas para el target “initird.target”, como se muestra a
continuación:
[root@pruebas ~]# systemctl list-dependencies initrd.target

initrd.target
● ├─dracut-cmdline.service
● ├─dracut-initqueue.service
● ├─dracut-mount.service
├
● ├─dracut-pre-mount.service
● ├─dracut-pre-pivot.service
● ├─dracut-pre-trigger.service
● ├─dracut-pre-udev.service
● ├─initrd-parse-etc.service
● ├─basic.target
● │ ├─-.mount
9. El kernel monta el sistema de archivos raíz en “/”, seguido a

eso “SystemD” se relanza a si mismo.
10. “SystemD” busca el target definido por default ejecutando cada

una de sus unidades para llegar al estado deseado.
GESTIÓN DE USUARIOS Y GRUPOS EN
LINUX
Red Hat Enterprise Linux es un sistema operativo multiusuario, permite
a varios usuarios en diferentes computadoras acceder a un sistema Linux.
Cada usuario opera bajo su propia cuenta, por lo tanto, la gestión de las
cuentas de usuario representa un elemento central de la administración del
sistema Red Hat Enterprise Linux. Cabe destacar que los sistemas Linux
administrar usuarios locales y también cuentan con la capacidad de delegar
la autenticación en sistemas externos lo cual resulta útil cuando su centro de
datos cuenta con mas de dos servidores Linux y quiere estandarizar el
manejo de los usuarios.
Usted puede apreciar las cuentas de usuario en el archivo /etc/passwd,

[root@pruebas ~]# cat /etc/passwd

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
…
fmestre:x:1000:1000:Fabian Mestre:/home/fmestre:/bin/bash
apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin
Podemos encontrar diferentes tipos de cuentas:
Usuario root: también conocido como superusuario, cuenta

con todos los permisos necesarios para administrar el sistema.
Cuentas de Usuario estandar: Las cuentas normales se crean

para usuarios de un sistema en particular. Estas cuentas se pueden
agregar, eliminar y modificar durante la administración del
sistema.
Cuentas de Usuario del Sistema: Las cuentas de usuario del

sistema generalmente se agregan o gestionan en el momento de la
instalación del software y normalmente no se modifican más
adelante.
Cada usuario cuenta con un identificador en el sistema, para el usuario

estándar este identificador inicia en el número 1000 sin embargo se aconseja
por parte del fabricante iniciar desde el número 5000. Las cuentas de
usuario del sistema inician en 1 y van hasta el 999; el usuario root tiene
como ID el número 0; cuando un sistema Linux está conectado a un servicio
externo de autenticación, los ID generalmente inician en 10000.
Los sistemas Red Hat Linux como muchas otras distribuciones permiten
crear grupos. Un conjunto de cuentas se integra en un grupo con un
propósito especifico, como por ejemplo acceder a un recurso (archivo o
directorio).
La asignación de ID’s se puede visualizar en el archivo /etc/login.defs,

tal como se muestra a continuación:
[root@pruebas ~]# cat /etc/login.defs

…
# Min/max values for automatic uid selection in useradd
#
UID_MIN 1000
UID_MAX 60000
# System accounts
SYS_UID_MIN 201
SYS_UID_MAX 999
#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN 1000
GID_MAX 60000
# System accounts
SYS_GID_MIN 201
SYS_GID_MAX 999
…
GESTIÓN DE OPERACIONES SOBRE
USUARIOS DEL SISTEMA
Sobre las cuentas de usuario es posible generar diferentes tipos de
operaciones, como lo es la adición, la asignación de contraseña, la
modificación de datos, así como su eliminación; en esta sección
trabajaremos sobre ellas para lograr un mejor entendimiento.
Iniciamos esta temática mostrando como identificar a un usuario del

sistema, utilizando el comando “id”:
[root@pruebas ~]# id fmestre

uid=1000(fmestre) gid=1000(fmestre) groups=1000(fmestre)
La operación anterior muestra los datos de identificación del usuario

“fmestre”, acá es posible validar que su identificador de usuario es 1000, que
pertenece al grupo 1000 como grupo primario, siendo posible ver los otros
grupos en los cuales se encuentra vinculado (grupos secundarios) en este
caso vuelve a indicar el grupo 1000.
Esta visualización ha sido realizada con el usuario “root”, el cual puede

de igual forma visualizar sus propios datos:
[root@pruebas ~]# id
uid=0(root) gid=0(root) groups=0(root)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
ADICIONANDO UN USUARIO ESTANDAR
Es posible adicionar usuarios estándar gracias al uso de los comandos

“useradd” o “adduser”, aplicaciones que ejecutan una serie de actividades
agregando un nuevo usuario al sistema operativo, sin embargo para que
usted dimensione todo lo que implica la creación de un usuario, tenga
presente lo que ocurre cuando uno de estos es adicionado al sistema, como
[root@pruebas ~]# adduser test
Se ha creado el usuario llamado “test”, una vez ha sido creado podemos

ver que se ha adicionado una entrada en el archivo /etc/passwd, el cual
muestra los datos relacionados con el usuario en el orden siguiente:
login:contraseña:id:gid:gecos:rutadeusuario:shell. En este formato:
login: hace referencia al nombre del usuario

contraseña: no se indica acá sino en el archivo /etc/shadow
id: identificador de usuario
gid: identificador del grupo primario del usuario
gecos: usado para colocar alguna descripción general del
usuario
ruta de usuario: ruta en el sistema de archivos destinada al
usuario
bash: define la aplicación que el usuario usará para
comunicarse con el kernel
[root@pruebas ~]# cat /etc/passwd | grep test

test:x:1001:1001::/home/test:/bin/bash
A no ser que sea necesario, no es una buena practica otorgarle un Shell a

un usuario, de igual forma también es importante mencionar que se puede
crear un usuario sin grupo y decirle al sistema que lo incluya en un grupo
definido; son diferentes las opciones que tiene al momento de la creación de
usuario, lo veremos mas adelante. A continuación visualizamos el grupo
que se creó cuando se adicionó el usuario:
[root@pruebas ~]# cat /etc/group | grep test

test:x:1001:
De la siguiente forma observamos que se ha creado una entrada en

/etc/shadow sin la información de contraseña del usuario por que aun no se
ha asignado:
[root@pruebas ~]# cat /etc/shadow | grep test

test:!!:18696:0:99999:7:::
Es momento de asignar la contraseña del usuario, como se muestra:
[root@pruebas ~]# passwd test

Changing password for user test.
New password:
BAD PASSWORD: The password is shorter than 8 characters
Retype new password:
passwd: all authentication tokens updated successfully.
Una vez asignada la contraseña es posible ver el cambio que se da en

/etc/shadow, vemos que se presentan unos caracteres como estos:

test:$6$G7IPmMKwkpibDq5T$ouQqvR88ItQgjekau3lkAoiA2BPl
o7cWRLhCBphDRZriBEkEGA4tTtfNzh5tAEWMz0ZIDPYqJQ.5kxl7
yMDxn.:18696:0:99999:7:::
$6$G7IPmMKwkpibDq5T$ouQqvR88ItQgjekau3lkAoiA2BPl
o7cWRLhCBphDRZriBEkEGA4tTtfNzh5tAEWMz0ZIDPYqJQ.5
kxl7yMDxn.
El $6 indica el algoritmo hash utilizado para esta contraseña.

El número 6 indica que es un hash SHA-512, que es el
predeterminado en Red Hat Enterprise Linux 8.
El siguiente dato, $G7IPmMKwkpibDq5T indica la semilla

utilizada para cifrar la contraseña. Esto se elige originalmente al
azar.
El dato $ouQqvR88ItQgjekau3lk --- salida omitida --- indica el

hash cifrado de la contraseña del usuario. La semilla y la
contraseña (introducida por el usuario) sin cifrar son combinadas y
cifrados para generar el hash cifrado de la contraseña. Si esta
combinación es efectiva entonces se autoriza el registro del
usuario al sistema Linux.
Al crearse el usuario se creo en /home/ su ruta de trabajo, en este caso

/home/test/:
[root@pruebas ~]# ll /home/

total 4
drwx------. 16 fmestre fmestre 4096 Mar 9 11:55 fmestre
drwx------. 3 test test 92 Mar 10 10:57 test
De igual manera se ha creado un archivo en /var/spool/mail, relacionado

con el servicio de correo electrónico:
[root@pruebas ~]# ll /var/spool/mail/

total 0
-rw-rw----. 1 fmestre mail 0 Dec 17 17:20 fmestre
-rw-rw----. 1 rpc mail 0 Dec 17 17:11 rpc
-rw-rw----. 1 test mail 0 Mar 10 10:57 test
Aunque será tema tratado en posterior sección, este usuario ha sido

mapeado con un usuario SELinux para efectos de control:
[root@pruebas ~]# semanage login -l

Login Name SELinux User MLS/MCS Range Service
__default__ user_u s0 *
--- salida omitida
Todas estas cosas surgen al momento de crear un usuario de la forma

tradicional, sin embargo, hay parámetros que se pueden usar para restringir o
controlar mas la cuenta en el sistema, como lo muestran los ejemplos a
continuación:
[root@pruebas ~]# useradd -e 2021-12-31 -s /sbin/nologin -N -M -
G ingenieria test
En el anterior ejemplo se muestra como se le ha definido una fecha de

expiración al usuario y se le ha dejado sin shell; de la misma forma el
parámetro -N permite crear el usuario sin crear un grupo con el mismo
nombre, el parámetro -M no le crea carpeta en /home y el parámetro -G le
asigna como grupo secundario el grupo “ingenieria”, como se muestra:
[root@pruebas ~]# cat /etc/group | grep ingenieria

ingenieria:x:1003:test
Es posible utilizar el parámetro “--selinux-user” para indicar con que

usuario SELinux estará mapeado este usuario estándar. De igual forma el
parámetro “--skel” indica cual es la carpeta esqueleto que se tomaría para
heredarle archivos o directorios a un usuario nuevo que se cree. La carpeta
esqueleto por default es /etc/skel, si usted tiene un archivo o directorio
dentro de esa carpeta y crea un nuevo usuario, este nuevo usuario heredará
tal data:
[root@pruebas ~]# ll /etc/skel/
ACTUALIZACION DE DATOS USUARIOS
Una vez creado el usuario se puede hacer necesario modificar sus

propiedas dependiendo del requerimiento, como los ejemplos que se
muestran a continuación:
En el primer ejemplo se crea el grupo llamado “contabilidad” y se

adiciona al usuario “test” al grupo contabilidad, listando posteriormente los
grupos a los que pertenece el usuario “test”:
[root@pruebas ~]# groupadd contabilidad

[root@pruebas ~]# usermod -aG contabilidad test
[root@pruebas ~]# cat /etc/group | grep test

ingenieria:x:1003:test
contabilidad:x:1004:test
En el siguiente ejemplo se modifican las fechas de expiración de la
cuenta el shell a utilizar por parte del usuario:
[root@pruebas ~]# usermod -e 2022-12-31 -s /bin/bash test
El siguiente ejemplo muestra como se define una ruta de trabajo

diferente para el usuario “test” y que sucede cuando se registra en el sistema:
[root@pruebas ~]# usermod --home /tmp test
[root@pruebas ~]# su - test

[test@pruebas ~]$ pwd
/tmp
El siguiente ejemplo muestra una de las formas de bloquear el acceso al

sistema Linux y se detalla la línea en /etc/shadow que presenta el caractér
“!” antes del algoritmo que genera el hash, ese caractér indica que la cuenta
está bloqueda:
[root@pruebas ~]# usermod -L test
test:!$6$//.u15dcDvh19xvP$Z101Z9okz8zGZ4GtszF2DkD.rdyu36s
7BuOSubYjRrrUIG49H2mJsnstQopoAHgTCd7JrpWlLgO3JfLfQw.Sg.
:18696:0:99999:7::19357:
De la siguiente forma es posible desbloquear la cuenta de un usuario,

también se visualiza la entrada en /etc/shadow, donde no se debe de apreciar
el caractér “!” pues la cuenta ha sido desbloqueada:
[root@pruebas ~]# usermod -U test
test:$6$//.u15dcDvh19xvP$Z101Z9okz8zGZ4GtszF2DkD.rdyu36s
7BuOSubYjRrrUIG49H2mJsnstQopoAHgTCd7JrpWlLgO3JfLfQw.Sg.
:18696:0:99999:7::19357:
ELIMINACION DE USUARIOS DEL SISTEMA
En ocasiones se hace necesario eliminar un usuario del sistema y que

este no aparezca mas en las cuentas, sin embargo una buena practica antes de
esta eliminación de un usuario es guardar todo lo que el usuario generó
dentro del filesystem, usted podría guardar esa información siguiendo los
pasos simulados en este ejercicio:
Se crearán cinco archivos vacíos desde la cuenta del usuario test:
[test@pruebas ~]$ touch 1 2 3 4 5

[test@pruebas ~]$ ll
total 8
-rw-r--r--. 1 test users 0 Mar 10 12:45 1
Como usuario “root” se crea una carpeta para almacenar la información

creada con el usuario “test”:
[root@pruebas ~]# mkdir /f-test
Se realiza una búsqueda de todos los archivos en el sistema que

pertenecen al usuario “test” y se copian a la carpeta /f-test:
[root@pruebas ~]# find / -user test 2> /dev/null -exec cp -R '{}'

/f-test \;
[root@pruebas ~]# ll /f-test/

total 0
-rw-r--r--. 1 root root 0 Mar 10 12:53 1
-rw-r-----. 1 root root 0 Mar 10 12:53 test
Con la seguridad de haber respaldado la información es posible eliminar
la cuenta de usuario de manera recursiva y forzada, como se muestra a
continuación:
[root@pruebas ~]# userdel -rf test

LINEA DE TIEMPO DE LOS PASSWORDS
El archivo /etc/shadows nos muestra información relacionada con cada

una de las cuentas de usuario, entre ellas la semilla, el algoritmo y el hash
que combinado con la semilla permite o no el ingreso de una cuenta al
sistema. Además de esta data tan importante, este es el archivo donde se
establecen las edades de los passwords del sistema, que viene siendo la
estructura de tiempos o ciclo de vida por donde un password normalmente
pasa. La imagen a continuación nos muestra de forma estructurada la línea
de tiempo por donde transitan las cuentas de usuario en relación a su
password.
Visualizando al detalle una línea del archivo /etc/shadow podemos

observar lo siguiente:
login:hash:18696:0:99999:7::19357:
Fecha de último Cambio. El campo que indica el número

18696, define el día en que se cambió la contraseña por última vez.
Esto se establece en días desde 1970-01-01, y es calculado en la
zona horaria UTC. Parámetro “-d”.
Días mínimos. El campo que indica el número 0, define el

número mínimo de días que deben transcurrir desde el último
cambio de contraseña antes que el usuario la pueda volver a
cambiar de nuevo. Una expresión de ejemplo: “como mínimo debe
esperar 30 días para un cambio de password”. Parámetro “-m”.
Días máximos. El campo que indica el número 99999, define
el número máximo de días que pueden pasar sin un cambio de
contraseña antes de la contraseña expire. Un campo vacío significa
que no caduca. Una expresión de ejemplo: “como máximo esa
contraseña tendrá una duración de 90 días”. Parámetro “-M”.
Días de Warning. El campo que indica el número 7, define el

período de advertencia donde se estará notificando al usuario sobre
la caducidad de su contraseña cada vez que inicie sesión en el
sistema. Una expresión de ejemplo: “7 días antes de la expiración
de la cuenta se le avisa al usuario que su cuenta quedará inactiva”.
Parámetro “-W”.
Días Inactivos. Una vez que la contraseña haya expirado, aún

se aceptarán intentos de login. Una vez transcurrido este período,
la cuenta se bloqueará. Una expresión de ejemplo: “30 días
después de la expiración de la cuenta se le permitirá a la cuenta
intentos de login”. Parámetro “-I”.
Fecha de Inactividad. El día en que el password expira de

forma total. Se establece en días desde el 1 de enero de 1970 y se
calcula en la zona horaria UTC. Un campo vacío significa que no
caduca en una fecha determinada.
El último campo es no usado.
Usted podrá cambiar estas edades de passwords utilizando el comando

“chage”, tal como se muestra a continuación para la contraseña del usuario
“test”:
[root@pruebas ~]# chage -m 0 -M 90 -W 7 -I 14 test
Para el caso de la instrucción anterior, se establece que la contraseña del

usuario “test” tiene una expiración en 90 días, puede cambiar su contraseña
en cualquier momento y siete (7) días antes de la expiración de la cuenta se
le estará notificando de la expiración; tendrá 14 días de inactividad
establecida antes que la cuenta sea bloqueada. Después de ejecutar la
anterior instrucción la entrada en /etc/shadow quedará así:

---salida omitida---:18696:0:90:7:14::
OPERACIONES SOBRE GRUPOS DEL
SISTEMA
El manejo que se le da a los grupos del sistema está relacionado con las
operaciones de creación, modificación y eliminación de grupos; con
ejemplos que se muestran a continuación evidenciaremos tales operaciones.
Se inicia con la creación y validación de un grupo llamado “tecnologia”:
[root@pruebas ~]# groupadd -g 20000 tecnologia
[root@pruebas ~]# cat /etc/group | grep tecnologia

tecnologia:x:20000:
Seguidamente cambiamos el nombre del grupo a “agricultura” y

verificamos:
[root@pruebas ~]# groupmod -n agricultura tecnología
[root@pruebas ~]# cat /etc/group | grep tecnologia
[root@pruebas ~]# cat /etc/group | grep agricultura

agricultura:x:20000:
Por último, borramos el grupo previamente creado:
[root@pruebas ~]# groupdel agricultura

SUPLANTACIÓN DE IDENTIDADES
Generalmente todo sistema operativo tiene un superusuario el cual tiene
la responsabilidad de velar por la integridad y estabilidad del sistema.
Técnicamente hablando es en realidad la responsabilidad como tal de un ser
humano que debe registrarse en el sistema con su cuenta de usuario estándar
para que una vez registrado suplante al superusario, en este caso el usuario
“root” y ejecute labores de Administración.
Esta suplantación no es solamente realizada por un usuario estándar al

usuario “root”, también puede ser entre usuarios estándares. Usted puede
utilizar el comando “su” para suplantar a un usuario, como se muestra a
continuación:
$ ssh -l fmestre 192.168.0.200

fmestre@192.168.0.200's password:
https://192.168.0.200:9090/
Este servidor es de Aptiva Labs SAS

Last login: Wed Mar 10 10:53:16 2021
[fmestre@pruebas ~]$ su - root
Password:
[root@pruebas ~]#
Una vez registrado usted puede ejecutar las actividades que necesite
como superusuario. Esta suplantación al usuario “root” podría ser hecha sin
colocar el nombre de usuario, solo colocando “su -”.
DELEGANDO FUNCIONES DE
ADMINISTRACIÓN - SUDO
En muchas ocasiones se hace necesario que diferentes labores de
administración del sistema sean realizadas por personas especializadas en
cada una de ellas. Puede ser el caso de tener un grupo de personas
especializadas en labores de administración de almacenamiento y otro grupo
enfocado en la administración de los procesos del sistema; para la
realización de estas actividades seguramente algunos pensarían que es
necesario que cada una de estas personas debería tener acceso a las
credenciales del usuario “root”, sin embargo esto no es así.
En RHEL 8 y derivados, así como en otros sistemas Linux se permite

esta delegación de funciones sin necesidad de pasarle a usuarios estándares
las credenciales del usuario “root”. El archivo /etc/sudoers es utilizado para
establecer estas delegaciones de funciones y su edición es recomandable
hacerla con el programa “visudo”, pues si una línea está mal definida de
forma inmediata este programa nos avisará para entrar a la corrección.
Para hacer uso de estas delegaciones se utiliza la instrucción “sudo”

precedida del comando que se puede digitar como superusuario, como se
[fmestre@pruebas ~]$ sudo fdisk -l

sudo: unable to open /run/sudo/ts/fmestre: Permission denied
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.

#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for fmestre:

sudo: unable to stat /var/db/sudo: Permission denied
fmestre is not in the sudoers file. This incident will be reported.
En este caso se necesita conocer el esquema de partición del sistema, una
labor propia del usuario “root”, actividad que requiere conocer la cuenta
“fmestre”. Digitada la instrucción previa, se muestra una notificación al
usuario acerca de las implicaciones del uso de este poder delegado y por
último la salida nos indica que el usuario “fmestre” no cuenta con los
permisos necesarios para realizar esta actividad y que el incidente será
reportado.
Algunos administradores recurren a la forma fácil de solucionar el

problema. El archivo /etc/sudoers cuenta con una línea como esta: “root
ALL=(ALL) ALL”, muchos simplemente hacen algo como agregar una
línea cambiando solo el nombre del usuario, dejando una línea como por
ejemplo “fmestre ALL=(ALL) ALL”
Es importante aclarar acá que cuando un usuario estándar de Linux es

creado sin definirse con que usuario SELinux estará mapeado, este nuevo
usuario estará vinculado al grupo de usuarios SELinux por default,
técnicamente conocidos como “__default__”. Esta agrupación de usuarios
(“__default__”) estará mapeada a un usuario SELinux, el cual permitirá o no
realizar labores delegadas. En la sección SELinux se tocará este tema mas a
fondo.
Si usted confía en las labores de administración de una persona se

recomienda que por cada usuario estándar en el que quiera delegar funciones
de administración crearle un archivo en /etc/sudoers.d, como se muestra a
continuación:
[root@pruebas sudoers.d]# pwd

/etc/sudoers.d
[root@pruebas sudoers.d]# visudo fmestre

fmestre ALL=(ALL) ALL
[root@pruebas sudoers.d]# visudo test

test ALL=(ALL) ALL
[root@pruebas sudoers.d]# ll
total 8
-r--r-----. 1 root root 22 Mar 12 09:21 fmestre
-r--r-----. 1 root root 19 Mar 12 09:22 test
Suponga que tiene un script que realiza tareas de forma automática y

requiere pasar de largo sin la necesidad de pasar contraseña alguna en sus
ejecuciones, usted podría configurar la línea de delegación como se muestra
a continuación:
[root@pruebas sudoers.d]# cat fmestre

fmestre ALL=(ALL) NOPASSWD:ALL
Hemos establecido un poder enorme sobre los usuarios “fmestre” y

“test”, los cuales podrán realizar cualquier actividad de administración sobre
el sistema. Lo mismo podría hacerse sobre los grupos creando un archivo
con el nombre del grupo en la misma ruta y estableciendo los permisos,
[root@pruebas sudoers.d]# visudo ingenieria

%ingenieria ALL=(ALL) ALL
A manera de ejemplo integraremos al usuario “fmestre” dentro del grupo

“ingenieria” para que pueda realizar labores de administración. Inicialmente
visualizamos la identidad del usuario “fmestre”:
[root@pruebas sudoers.d]# id fmestre

uid=1000(fmestre) gid=1000(fmestre) groups=1000(fmestre)
Se establece como grupo secundario del usuario “fmestre” el grupo

“ingenieria”:
[root@pruebas sudoers.d]# usermod -aG ingenieria fmestre
Se visualiza nuevamente la identidad del usuario “fmestre” para verificar

que esté vinculado dentro del grupo “ingenieria”:
[root@pruebas sudoers.d]# id fmestre

uid=1000(fmestre) gid=1000(fmestre)
groups=1000(fmestre),1003(ingenieria)
Se realiza una suplantación al usuario “fmestre” y se le requiere al kernel
el particionamiento del dispositivo de bloque /dev/sdc:
[root@pruebas sudoers.d]# su - fmestre
[fmestre@pruebas ~]$ sudo fdisk /dev/sc

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.

#2) Think before you type.
#3) With great power comes great responsibility.

LIMITANDO LA DELEGACIÓN DE FUNCIONES
En sintonía con el ejercicio planteado en el aparte anterior, se detalla una

tarea de superusuario que ahora un usuario estándar puede realizar, sin
embargo sigue siendo un poco arriesgado otorgar tantos permisos a un
usuario o a un grupo. Para solucionar este dilema usted podría crear un alias
de comando, asignarlo a un grupo en vez de los permisos totales, como se
[root@pruebas sudoers.d]# which fdisk

/usr/sbin/fdisk
En la instrucción anterior identificamos cual es la ruta real del programa

“fdisk”, en esta demostración solo vamos a permitir que los usuarios del
grupo “ingenieria” usen el programa “fdisk”. Seguidamente editamos el
archivo que se ha definido para el grupo:
[root@pruebas sudoers.d]# visudo ingenieria
Cmnd_Alias ALMACENAMIENTO = /usr/sbin/fdisk

%ingenieria ALL = ALMACENAMIENTO
Este archivo de dos líneas visualiza el alias de comando llamando

“ALMACENAMIENTO”, al cual se le ha relacionado únicamente el uso del
programa “fdisk”, seguido a ello, se relaciona el alias de comando con el
grupo “ingenieria”. Para comprobar esta configuración inicie una sesión con
el usuario “fmestre” y trate de usar “fdisk” con el objetivo de particionar
/dev/sdc, notará que podrá hacerlo, como muestra la siguiente salida:
[fmestre@pruebas ~]$ sudo fdisk /dev/sdc


Changes will remain in memory only, until you decide to write
them.
The old LVM2_member signature will be removed by a write

command.
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0xfbd7e301.
Command (m for help): ^C

Do you really want to quit? y
Cancelaremos la operación para intentar realizar otra tarea de

administración donde veremos como no tenemos permitido realizarla, tal
[fmestre@pruebas ~]$ sudo yum update

Sorry, user fmestre is not allowed to execute '/bin/yum update' as root on
pruebas.aptivalabs.
De esta forma usted restringe la delegación de funciones para que las

personas en las cuales usted confía la administración del sistema solo hagan
con sus usuarios estándares lo que usted necesita que hagan.
PERMISOS ESTANDARES Y
EXCEPCIONALES
Las medidas relacionadas al control de la data dentro del sistema
operativo están dadas por varias capas de seguridad, la gestión de usuarios,
las reglas de firewall, la configuración de SELinux, etc, hacen parte de los
recursos que Linux pone a disposición de los administradores para ejercer
control sobre los datos en el sistema. Una de estas capas de seguridad que
puede permitir quien puede leer, escribir o ejecutar un archivo, o listar,
escribir sobre un directorio, o posicionarse en él, está determinada sobre los
permisos estándares y excepcionales que se establecen en el sistema de
archivos.
Como se mencionó anteriormente se pueden definir permisos sobre

archivos y directorios, estos permisos están definidos en letras (r, w, x). Para
el caso de los archivos cada una de estas letras significan lo siguiente:
r : permiso de lectura del archivo

w: permiso para escribir en el archivo
x: permiso para ejecutar el archivo
Para el caso de los directorios, estas letras significan lo siguiente:
r : permiso de listar el contenido de un directorio

w: permiso para escribir datos en el directorio
x: permiso para posicionarse sobre el directorio
Cada una de estas letras tiene asignado un valor numérico para propósito
de asignación de permisos en archivos o directorios; la letra “r” tiene un
valor de 4, la letra “w” un valor de 2 y la letra “x” tiene un valor de 1.
Miremos entonces el siguiente listado vertical para aprender un poco más:
total 39836
drwxr-x---. 2 root root 83 Feb 22 16:46 pruebas
El listado anterior nos muestra tres (3) archivos y el directorio llamado

“pruebas”. Tomemos la línea “-rw-r--r--. 1 root root 40780168 Jan 5 23:44
webmin-1.970-1.noarch.rpm” para enseñar varias cosas:
1. Estamos tomando como objeto de muestra el archivo

“webmin-1.970-1.noarch.rpm”
2. Este archivo es propiedad del usuario “root” y los usuarios del
grupo “root” son los que podrán actuar sobre él, visualizados en el
orden que son mostrado (primero usuario propietario, luego grupo
relacionado). Además del usuario propietario y el grupo, podrían
haber “otros” interesados sobre este archivo, estos otros se llaman
“otros”
3. Vemos un grupo de nueve (9) caracteres (rw-r--r--), esos son

los permisos definidos para el usuario propietario (root), grupo
relacionado (root), y para los otros; en el caso del ejemplo están
definidos así:
rw- : indica que el usuario root puede leer, escribir y ejecutar

este archivo
r-- : indica que los usuarios relacionados al grupo root podrían

leer el contenido del archivo
r-- : indica que los “otros” usuarios podrían leer el contenido
del archivo
Veremos siempre que los permisos se listan con nueve (9)

caracteres, los cuales serán definidos en estricto orden: propietario –
grupos – otros.
4. Aunque existe el permiso de lectura definido para los otros,
estos no podrán alcanzar a ver este archivo pues es la carpeta de
trabajo del usuario root la cual tiene sus permisos definidos así:
dr-xr-x---. 8 root root 4096 Mar 12 11:55 root
Viendo este listado podemos observar que los últimos tres

caracteres en los permisos son “---”, o sea que los “otros” no podrán
llegar a esa carpeta (/root). Se concluye entonces que los permisos son
detallados en grupos de a tres (3), los tres primeros caracteres son los
permisos del propietario, los siguientes tres del grupo relacionado y los
tres últimos son los permisos para los “otros”.
5. Teniendo en cuenta los valores numéricos asociados a las

letras, el permiso numérico de este archivo se establece a 644,
teniendo en cuenta el permiso “rw-r--r--” el cual dividimos en
grupos de a tres, donde los tres primeros caracteres suman 6 (r=4 +
w=2), el siguiente grupo suma 4 (solo se define el permiso “r”),
ocurriendo lo mismo en el último grupo.
Así las cosas el archivo “webmin-1.970-1.noarch.rpm” pertenece al

usuario “root”, al grupo relacionado llamado root y tiene definido los
permisos 644 para cada uno de los actores. Veamos otro ejemplo para
detallar de mejor forma este concepto creando la carpeta /ingenieria:
[root@pruebas ~]# mkdir /ingeniería

ESTABLECIMIENTO DE PROPIETARIO Y
GRUPO A UN RECURSO
Establezcamos el propietario y el grupo asociado a esta carpeta como se
[root@pruebas ~]# chown fmestre.ingenieria /ingeniería
Vemos entonces que la carpeta /ingenieria pertenece ahora al usuario

“fmestre” los usuarios que están asociados al grupo “ingenieria” podrán
realizar tareas con ellas, como se muestra:
[root@pruebas ~]# ll /
total 34
---
drwxr-xr-x. 2 fmestre ingenieria 6 Mar 12 12:32 ingenieria
Se concluye que el permiso numérico establecido es 7(propietario),5

(grupo asociado), 5 (otros interesados sobre la carpeta), siendo 7 la suma de
r+w+x (4+2+1), y siendo 5 la suma de r+x (4+1). Para este caso los “otros”
podrán incluso posicionarse sobre esa carpeta y hacer un listado de su
contenido.
Imagine ahora que hay usuarios de otras áreas de la empresa, ahora

mismo estos podrían ver el contenido de la carpeta /ingenieria, pero resulta
que dentro de ella hay información importante que usted no quiere ellos
vean; usted podría cerrar esos accesos utilizando el comando “chmod” como
[root@pruebas ~]# chmod 770 /ingenieria/
total 34
drwxrwx---. 2 fmestre ingenieria 6 Mar 12 12:32 ingenieria
Con la instrucción anterior se ha cerrado el acceso a los “otros” a
/ingeniería, solo queda disponible para el usuario “fmestre” con todos los
permisos (7), y para los usuarios del grupo “ingenieria” con todos los
permisos (7), los “otros” no tiene acceso a la carpeta, es el caso del usuario
“test”, que si intenta posicionarse sobre la carpeta tendrá una salida como
esta:
[test@pruebas ~]$ cd /ingenieria/

-bash: cd: /ingenieria/: Permission denied
Caso contrario sucedería con el usuario llamado “curri” cuando lo

creamos y lo agregamos al grupo “ingenieria”, mire lo que sucede:
[root@pruebas ~]# adduser curri
[root@pruebas ~]# passwd curri

Changing password for user curri.
New password:
[root@pruebas ~]# usermod -aG ingenieria curri
En una nueva consola realizamos el login con el usuario “curri”:
$ ssh -l curri 192.168.0.200

curri@192.168.0.200's password:
https://192.168.0.200:9090/
[curri@pruebas ~]$ cd /ingenieria/
[curri@pruebas ingenieria]$
CAMBIO DE GRUPO A UN ARCHIVO O
DIRECTORIO
Hemos visto el uso de los comandos “chmod” para modificar el permiso
establecido sobre un archivo o directorio, también hemos visto el comando
“chown” para establecer propietario y grupo asociado a un archivo o
directorio. Podríamos también hacer uso del comando “chgrp” para realizar
un cambio de grupo a un archivo o directorio, como se muestra:
[root@pruebas ~]# groupadd legal
[root@pruebas ~]# chgrp legal /ingenieria/
total 34
drwxrwx---. 2 fmestre legal 6 Mar 12 12:32 ingenieria
Con el cambio realizado con anterioridad los usuarios del grupo “legal”
tiene acceso a los recursos de /ingeniería. Para efectos del entendimiento de
los siguientes temas volvemos a colocar como grupo principal asociado a la
carpeta /ingeniera a el grupo “ingenieria”:
[root@pruebas ~]# chgrp ingenieria /ingenieria/
[root@pruebas ~]# ll -d /ingenieria/

drwxrwx---. 2 fmestre ingenieria 6 Mar 12 12:32 ingenieria
UTILIZANDO LETRAS Y SIMBOLOS PARA
ASIGNACIÓN DE PERMISOS
Es posible establecer permisos utilizando algunas letras del alfabeto para
tal fin, como se muestra en los siguientes ejemplos:
En este primer ejemplo le quitaremos todos (letra “a”) a la carpeta

/ingenieria y listaremos:
[root@pruebas ~]# chmod a=--- /ingenieria/

d---------. 2 fmestre ingenieria 6 Mar 12 12:32 /ingenieria/
A continuación para el propietario (letra “u”) sumaremos todos los

permisos sobre la carpeta /ingenieria y listaremos:
[root@pruebas ~]# chmod u+rwx /ingenieria/

drwx------. 2 fmestre ingenieria 6 Mar 12 12:32 /ingenieria/
A continuación para el grupo (letra “g”) sumaremos los permisos de

lectura y posicionamiento sobre la carpeta /ingeniería y listaremos:
[root@pruebas ~]# chmod g+rx /ingenieria/

drwxr-x---. 2 fmestre ingenieria 6 Mar 12 12:32 /ingenieria/
A continuación para los “otros” (letra “o”) sumaremos el permisos de

posicionamiento sobre la carpeta /ingeniería y listaremos:
[root@pruebas ~]# chmod o+x /ingenieria/

drwxr-x--x. 2 fmestre ingenieria 6 Mar 12 12:32 /ingenieria/
Se han utilizado los símbolos “=” y “+”; de la misma forma es posible
utilizar el símbolo “-” para quitar permisos otorgados.
LISTA DE CONTROL DE ACCESO - ACL’s
A lo largo de esta sección hemos trabajado sobre la carpeta /ingenieria de
la cual listamos los permisos otorgados:

drwxrwx---. 2 fmestre ingenieria 6 Mar 12 12:32 /ingenieria/
Se puede visualizar entonces que el propietario es el usuario “fmestre” y

solo las cuentas de usuario asociadas en el grupo “ingenieria” podrán
trabajar con esta carpeta; cada uno de ellos tienen permisos sobre /ingenieria,
sin embargo que pasa con los usarios “test” ?, ellos hacen parte de los
“otros” y los “otros” no cuentan con ningún tipo de permiso sobre esta
carpeta.
Suponga que /ingenieria debe ser visualizada por el usuario “test”; los
permisos estándares antes vistos no permitirían generar un permiso para que
el usuario “test” pueda por lo menos listar el contenido de /ingeniería, siendo
“test” para de los “otros”, si usted define un permiso para los “otros” abre la
puerta a quien no debe abrírsela; ante esta situación Linux le permite definir
un permiso excepcional con tal de lograr este cometido a través de la
generación de una ACL como se muestra a continuación:
[root@pruebas ~]# setfacl -m u:test:rwx /ingenieria/
Si se lista los atributos asociados a la carpeta /ingenieria podemos ver

algo como lo que sigue:

drwxrwx---+ 2 fmestre ingenieria 6 Mar 12 12:32 /ingenieria/
Se observa el símbolo “+” en los atributos, esto quiere decir que una
regla excepcional tiene este directorio, la forma de saber cual es la regla se
[root@pruebas ~]# getfacl /ingenieria/

getfacl: Removing leading '/' from absolute path names
# file: ingenieria/
# owner: fmestre
# group: ingenieria
user::rwx
user:test:rwx
group::rwx
mask::rwx
other::---
Es posible ver dentro de las reglas listadas aquella que contiene

“user:test:rwx”, gracias a esta regla el usuario “test” podrá posicionarse
dentro de la carpeta, como se muestra a continuación:

[test@pruebas ingenieria]$
El poder o no trabajar con ACL’s es una posibilidad propia del sistema

de archivos con el cual se esté trabajando, en este caso XFS.
OPERACIONES COMUNES CON ACL’s
Claramente el usuario “test” no es el propietario de /ingenieria y mucho
menos hace parte del grupo “ingenieria”, sin embargo este permiso
excepcional le permite posicionarse dentro de ella y ver su contenido. Para
eliminar las ACL generadas sobre un recurso usted podría realizar lo
siguiente:
[root@pruebas ~]# setfacl -b /ingenieria/

drwxrwx---. 2 fmestre ingenieria 6 Mar 12 12:32 /ingenieria/
Si el usuario “test” intenta nuevamente posicionarse en el recurso vería

un mensaje como el siguiente:
[test@pruebas ingenieria]$ cd /ingenieria/

Con la instrucción anterior se eliminó la ACL sobre la carpeta

/ingenieria, sin embargo si mas de una ACL hubiese estado definida se
hubiesen borrado todas, por lo que se hace necesario aprender a borrarlas de
forma individual, como se muestra:
[root@pruebas ~]# setfacl -x u:test /ingenieria/

drwxrwx---+ 2 fmestre ingenieria 6 Mar 12 12:32 /ingenieria/

# file: ingenieria/
# owner: fmestre
# group: ingenieria
user::rwx
group::rwx
mask::rwx
other::---
Una ACL producida para un grupo llamado por ejemplo “gerencia”
sobre el recurso /ingenieria podría ser el siguiente:
[root@pruebas ~]# setfacl -m g:gerencia:rx /ingenieria/

# file: ingenieria/
# owner: fmestre
# group: ingenieria
user::rwx
group::rwx
group:gerencia:r-x
mask::rwx
other::---
Usted podrá si lo prefiere crear ACL’s con varias reglas en una sola
instrucción, tal como se muestra:
[root@pruebas ~]# setfacl -m u:test:rwx,g:gerencia:r,o:r /ingenieria/

# file: ingenieria/
# owner: fmestre
# group: ingenieria
user::rwx
user:test:rwx
group::rwx
group:gerencia:r--
mask::rwx
other::r--
Con la siguiente instrucción usted podría copiar la ACL definida en un

archivo, y pasársela a otro archivo:
root@pruebas ~]# getfacl /ingenieria/file1 | setfacl --set-file=-

/ingenieria/file2
RECURSIVIDAD EN ACL`s
Linux le brinda la posibilidad de crear ACL’s recursivas, entiéndanse
estas como aquellas que se crean para que apliquen a todos los recursos
dentro de un directorio, las cuales se pueden definir de la siguiente forma:
Se inicia el ejercicio eliminando cualquier ACL establecida sobre

/ingenieria:
Seguidamente se crean las carpetas “alfa” y “beta” dentro de /ingenieria:
[root@pruebas ~]# cd /ingenieria/

[root@pruebas ingenieria]# mkdir alfa
[root@pruebas ingenieria]# mkdir beta
Estas carpetas creadas se le colocan todos los permisos para dueño y

grupo, y nada para otros, como se muestra:
[root@pruebas ingenieria]# chmod 770 *
[root@pruebas ingenieria]# ll
total 0
drwxrwx---. 2 root root 6 Mar 13 08:36 alfa
drwxrwx---. 2 root root 6 Mar 13 08:37 beta
Intentando acceder a /ingenieria como usuario “test” nos encontramos

con la siguiente salida:

Seguidamente se establece una ACL recursiva para que el usuario “test”

pueda posicionarse sobre /ingenieria y cualquier otro directorio incluido
dentro de él, como se muestra a continuación:
[root@pruebas ~]# setfacl -R -m u:test:rX /ingenieria/

# file: ingenieria/
# owner: fmestre
# group: ingenieria
user::rwx
user:test:r-x
group::rwx
mask::rwx
other::r--
Es momento de intentar posicionarse dentro de /ingenieria con el usuario

“test”:

[test@pruebas ingenieria]$ ll
total 0
drwxrwx---+ 2 root root 6 Mar 13 08:36 alfa
drwxrwx---+ 2 root root 6 Mar 13 08:37 beta
La instrucción anterior establece para el usuario “test” una excepción

sobre todos los recursos directorios dentro de /ingenieria, por ejemplo, si
/ingenieria cuenta con directorios el usuario “test” podrá entrar a cada uno de
ellos. Note que los directorios “alfa” y “beta” cuentan con el símbolo “+”, el
cual indica que una ACL está definida para el recurso.
GESTÓN DE ACL’s POR DEFAULT
Aprovechando el escenario planteado es importante comentar que la
recursividad ha sido establecida para los directorios actuales dentro de
/ingenieria, sin embargo si nuevos directorios son creados, el usuario “test”
no podría acceder a ellos si así se requiera. Para solucionar esta limitación
se permite la creación de las ACL por default como un método para heredar
las propiedades del recurso padre en los nuevos recursos creados dentro de
él. La implementación de una ACL por default podrá detallarse de la
siguiente forma:
Crear una ACL por default resultaría en este caso en la adición del
parámetro “d:” a una regla tradicional creada, como se muestra en el
siguiente ejemplo:
[root@pruebas ingenieria]# setfacl -R -m d:u:test:rX /ingenieria/
Una vez creada la regla, dentro de /alfa creamos una carpeta llamada
“futbol” y revisamos sus atributos, como se muestra:
[root@pruebas ingenieria]# cd alfa/
[root@pruebas alfa]# mkdir futbol
[root@pruebas alfa]# ll
total 0
drwxrwx---+ 2 root root 6 Mar 13 08:56 futbol
[root@pruebas alfa]# getfacl futbol/

# file: futbol/
# owner: root
# group: root
user::rwx
user:test:r-x
group::rwx
mask::rwx
other::---
default:user::rwx
default:user:test:r-x
default:group::rwx
default:mask::rwx
default:other::---
Se puede observar que futbol cuenta entonces con una ACL heredada de
su carpeta padre llamada “/ingenieria/alfa”. De la siguiente forma usted
podría eliminar la ACL por default creada previamente:
[root@pruebas ~]# setfacl -x d:u:test /ingenieria/

# file: ingenieria/
# owner: fmestre
# group: ingenieria
user::rwx
group::rwx
other::r--
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::r--
MASCARAS PARA LIMITAR ACL’s
Un tema a considerar en el uso de las ACL’s tiene que ver con las
mascaras, las cuales definen el permiso máximo que puede existir sobre un
recurso; posiblemente para el usuario “test” exista un permiso “rwx”sobre la
carpeta /ingenieria, sin embargo el permiso máximo sobre este directorio
estará definido por la mascara. Visualizando la información del directorio
/ingenieria sin ningún tipo de ACL establecido podemos observar lo
siguiente:

# file: ingenieria/
# owner: fmestre
# group: ingenieria
user::rwx
group::rwx
other::r--
Es claro que ninguna mascara se encuentra establecida para el recurso.

Distinta situación se puede apreciar cuando se establece una ACL sobre el
directorio, tal como se muestra a continuación:
[root@pruebas ~]# setfacl -m u:test:rwx /ingenieria/

# file: ingenieria/
# owner: fmestre
# group: ingenieria
user::rwx
user:test:rwx
group::rwx
mask::rwx
other::r--
La configuración de la máscara muestra los permisos máximos posibles
para todos los usuarios nombrados, el grupo propietario y grupos
nombrados. La mascara no restringe los permisos del propietario del archivo
ni de otros usuarios. Todos los archivos y directorios que implementan ACL
tendrán una máscara de ACL. La máscara se puede ver con “getfacl” y
establecerse con “setfacl”. La mascara se calcula y se establece
automáticamente si no se establece por parte del Administrador, pero
también podría heredarse de un directorio principal.
PERMISOS ESPECIALES - SETUID,
SETGID, STICKY
Los permisos especiales constituyen un cuarto tipo de permiso además
de los permisos estipulados para el propietario, grupo y “otros”. Como su
nombre lo indica, estos permisos proporcionan funciones adicionales
relacionadas con el acceso más allá de lo que permiten los tipos de permisos
básicos.
PERMISO SETUID
Cuando se define el permiso especial “setuid”, es posible ejecutar un

archivo como el usuario propietario del archivo y no como el usuario que lo
ejecutó. Si miramos como ejemplo el programa “passwd”, utilizado para
cambiar las contraseñas de los usuario podemos ver lo siguiente:
[test@pruebas ~]$ ls -l /usr/bin/passwd

-rwsr-xr-x. 1 root root 33544 Dec 13 2019 /usr/bin/passwd
Se observa en el primer grupo de permisos el caractér “s”, esto significa

que tiene el permiso “setuid” establecido. Con este permiso definido
cualquier usuario dentro del sistema podría ejecutar este comando sin
importar que este programa sea de propiedad del usuario “root”. Para
asignar o quitar este permiso especial sobre un archivo usted podría hacerlo
de la siguiente manera:
[root@pruebas tmp]# chmod u+s programa.sh

[root@pruebas tmp]# chmod u-s programa.sh
También podría hacerlo utilizando notación octal, como se muestra a

continuación:
[root@pruebas tmp]# ll programa.sh

-rwxrwx---. 1 root root 11 Mar 15 09:07 programa.sh
[root@pruebas tmp]# chmod 4770 programa.sh

[root@pruebas tmp]# ll programa.sh
-rwsrwx---. 1 root root 11 Mar 15 09:07 programa.sh
Se observa el número “4” como parte del permiso, este número indica el
“setuid”.
PERMISO SETGID
El permiso especial “setgid” en un directorio significa que los archivos

creados en el directorio heredan su propiedad de grupo del directorio, en
lugar de heredarlo del usuario que lo creó. Este permiso se usa comúnmente
en caso de implementar directorios colaborativos grupales. Se realiza la
siguiente demostración para comprobar esta funcionalidad:
Se crea la carpeta /datos como carpeta que se va a compartir entre los

usuarios del grupo “ingenieria”:
[root@pruebas ~]#mkdir /datos
Se establece el propietario y grupo asociados de /datos:
[root@pruebas ~]# chown fmestre.ingenieria /datos
[root@pruebas ~]# ll -d /datos/

drwxr-xr-x. 4 fmestre ingenieria 30 Mar 1 17:33 /datos/
Se establece a /datos como carpeta colaborativa utilizando números y

símbolos (también podría utilizar el número “2”, ejemplo “chmod 2770”)
[root@pruebas ~]# chmod g+s /datos/
Creamos la ACL que le permitirá al usuario “test” acceder a la carpeta

compartida, creando inmediatamente la ACL por default para heredar los
permisos:
[root@pruebas ~]# setfacl -m u:test:rwx /datos/
[root@pruebas ~]# setfacl -m d:u:test:rwx /datos/
[root@pruebas ~]# getfacl /datos/

# file: datos/
# owner: fmestre
# group: ingenieria
# flags: -s-
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:test:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
Una vez realizada la configuración de la carpeta compartida, nos

registramos en el sistema con el usuario “test” y creamos un archivo llamado
“hora.txt”, este archivo debe pertenecer al grupo “ingenieria” así el usuario
“test” no haga parte de el, como se muestra:
$ ssh -l test 192.168.0.200

test@192.168.0.200's password:
https://192.168.0.200:9090/

Last login: Mon Mar 15 09:38:20 2021 from 192.168.0.35
[test@pruebas ~]$ cd /datos/
[test@pruebas datos]$ ll
total 0
drwxr-xr-x. 2 root root 6 Mar 1 17:33 app2
[test@pruebas datos]$ date > hora.txt
total 4
-rw-rw-r--+ 1 test ingenieria 29 Mar 15 09:43 hora.txt
PERMISO STICKY
El permiso “sticky” sobre un directorio establece una restricción especial

sobre la eliminación de archivos; solo el dueño de el archivo puede eliminar
archivos dentro del directorio, como se muestra a continuación:
Se crea /datos como carpeta que podrá ser accedida por cualquier usuario
en el sistema:
Se declara la carpeta con todos los permisos, incluido el “1” que declara
la carpeta con el permiso “sticky”; también pudo haberse hecho con una
instrucción como “chmod o+t”, importante haber concedido todos los
permisos estándares previamente.
[root@pruebas ~]# chmod 1777 /datos/
[root@pruebas ~]# ll -d /datos/

drwsrwxrwt. 2 root root 6 Mar 15 09:58 /datos/
Con el usuario “test” se crea un archivo llamado “calendario”:
[test@pruebas datos]$ cal -3 > calendario

total 8
-rw-rw-r--. 1 test test 520 Mar 15 10:01 calendario
-rw-r--r--. 1 root root 29 Mar 15 10:00 fecha.txt
Registrándonos con el usuario “fmestre” trataremos de eliminar el

archivo llamado “calendario”, donde debemos de recibir una salida
indicando que no será posible realizar esta operación, como se muestra a
continuación:
[fmestre@pruebas datos]$ rm calendario

rm: remove write-protected regular file 'calendario'? y
rm: cannot remove 'calendario': Operation not permitted
TROUBLESHOOTING CON ARCHIVOS DE
LOG
Los archivos de log contienen mensajes sobre el sistema, incluido el
kernel, los servicios y las aplicaciones que se ejecutan. Estos contienen
información que ayuda a solucionar problemas o monitorear las funciones
del sistema. Red Hat Enterprise Linux se basa en el protocolo syslog el cual
está incorporado. Algunas aplicaciones usan este sistema para registrar
eventos y organizarlos en archivos de log, que son útiles al auditar el sistema
operativo y la resolución de problemas.
Los servicios que manejan los mensajes de syslog son systemd-journald

y rsyslog. systemd-journald recopila mensajes de varias fuentes y los
reenvía a rsyslog para su posterior procesamiento. El servicio systemd-
journald recopila mensajes de las siguientes fuentes de datos:
Kernel
Primeras etapas del proceso de arranque
Salida estándar y de error de los servicios cuando se inician y
se ejecutan
Syslog
TIPOS DE MENSAJES EN RSYSLOG
El servicio “rsyslog” clasifica los mensajes de syslog por “facilities” y
nivel de prioridad, y los escribe en los archivos del directorio /var/log/. A
continuación se presenta la tabla con la descripción de los niveles de
prioridad:
CODIGO NIVEL SEVERIDAD

0 emerg El sistema es inutilizable
1 alert Se deben tomar medidas de inmediato
2 crit Condición crítica
3 err Condición de error no crítico
4 warning Condición de Advertencia
5 notice Evento normal pero significativo
6 info Evento informativo
7 debug Mensaje de nivel de depuración
A continuación se listan los “facilities” que son usados para la

generación de las entradas de logs: auth, authpriv, cron, daemon, ftp, kern
(solo los genera el kernel), lpr, mail, news, syslog, user, uucp, local0 a
local7 y security.
El servicio rsyslog utiliza la parametrización anterior en función de los

mensajes de registro para determinar cómo manejarlos. Esto se configura
mediante reglas en el archivo /etc/rsyslog.conf y cualquier archivo de
configuración ubicado en /etc/rsyslog.d/ directorio donde se deben ubicar
archivos cuya terminación sea “.conf”.
El directorio /var/log almacena de forma persistente los mensajes de log.

Los siguientes archivos del directorio /var/log almacenan mensajes de
syslog:
/var/log/messages: todos los mensajes de syslog excepto los
siguientes
/var/log/secure: mensajes y errores relacionados con la
seguridad y la autenticación
/var/log/maillog - mensajes y errores relacionados con el
servidor de correo
/var/log/cron: archivos de log relacionados con tareas
ejecutadas periódicamente
/var/log/boot.log – archivos delog relacionados con el arranque
del sistema
REGLAS DE SYSLOG
Dando una mirada al archivo /etc/rsyslog.conf es posible ver las reglas
definidas que están en operación y algunas otras que están comentadas. Una
regla es la combinación de un “facility” y un nivel de prioridad, además del
archivo donde se va a guardar la entrada de log, por ejemplo cron.* indica
que se deben registrar todos los niveles de prioridad para el “facility” cron;
otro ejemplo puede ser ftp.notice, que indica que se deben registrar los
eventos significativos del “facility” ftp.
Una línea en uno de los archivos de configuración es una regla que le

dice a “rsyslog” como organizar la información, como se muestra a
continuación:
[root@pruebas ~]# more /etc/rsyslog.conf

#### RULES ####
*.info;mail.none;authpriv.none;cron.none
/var/log/messages
# The authpriv file has restricted access.

authpriv.* /var/log/secure
# Log all the mail messages in one place.

mail.* -/var/log/maillog
# Log cron stuff

cron.* /var/log/cron
El lado izquierdo de cada línea indica el “facility” y el nivel de prioridad

de los mensajes de Syslog con los que coincide la regla. El lado derecho de
cada línea indica en qué archivo debe guardarse el mensaje de registro. Un
asterisco (*) es un comodín donde coinciden con todos los valores. Así las
cosas tenemos por ejemplo la línea “cron.* /var/log/cron” que nos indica
que el servicio “cron” en cualquier tipo de nivel de prioridad (emerg, alert,
notice, etc) debe registrarse en /var/log/cron.
Además de guardar la información en archivos, usted podría

parametrizar “rsyslog” para que utilice la salida estándar como mecanismo
de visualización de información, de hecho, en el archivo de configuración
usted podrá ver la línea “*.emerg :omusrmsg:*”, la cual ya se encuentra
definida.
ROTACION DE LOS ARCHIVOS DE LOG
Para efectos de gestión del almacenamiento y operatividad del sistema,
“rsyslog” administra los archivos de log, rotando su nombre cuando criterios
y parametrizaciones se cumplen. La herramienta “logrotate” rota los
archivos de registro para evitar que ocupen demasiado espacio en el archivo.
Cuando un archivo de registro rota, se le cambia el nombre adicionando al
final de este la fecha en que se rotó, como se muestra a continuación:
[root@pruebas log]# cd /var/log/
[root@pruebas log]# ll
-rw-------. 1 root root 1415115 Mar 10 08:44 messages
-rw-------. 1 root root 457005 Feb 18 14:42 messages-20210218
-rw-------. 1 root root 823795 Feb 21 08:02 messages-20210221
-rw-------. 1 root root 2745039 Mar 1 08:44 messages-20210301
-rw-------. 1 root root 2834381 Mar 8 09:13 messages-20210308
“logrotate” está diseñado para facilitar la administración de sistemas que

generan una gran cantidad de archivos de registro. Eso permite la rotación,
compresión, eliminación y envío automático de archivos de registro. Cada
archivo de registro se puede manejar diariamente, semanalmente,
mensualmente o cuando crece demasiado. Normalmente, “logrotate” se
ejecuta como una tarea definida en un cron diario.
“logrotate” no modificará un registro más de una vez al día a menos que

el criterio para ese registro se base en el tamaño del registro y logrotate se
esté ejecutando más de una vez cada día, o a menos que se utilice la opción -
f o --force. Si usted requiere conocer mas a fondo como es el
funcionamiento de “logrotate” se le invita revisar sus paginas de manual
(man 8 logrotate).
FORMATO DE LAS ENTRADAS EN LOS
ARCHIVOS DE LOG
Al revisar alguna de las entradas en los archivos de log usted podrá
detallar el formato que utiliza rsyslog para generarlas, tal como se muestra a
continuación:
[root@pruebas log]# tail -n 1 secure

Mar 10 08:02:05 pruebas sshd[4574]: pam_unix(sshd:session):
session opened for user root by (uid=0)
[root@pruebas log]# tail -n 1 messages

Mar 10 09:00:15 pruebas qemu-ga[1493]: info: guest-ping called
[root@pruebas log]# tail -n 1 cron

Mar 10 09:01:01 pruebas run-parts[5212]: (/etc/cron.hourly)
finished 0anacron
Se puede apreciar entonces como patrón general en cada una de estas

líneas en su respectivo orden los siguientes campos: marca de tiempo,
nombre del host, programa o proceso que genera la entrada con su respectivo
PID (identificador de proceso) y por último el mensaje que genera.
Usted puede utilizar el programa “logger” para enviar mensajes a rsyslog

tal como sigue:
[root@pruebas ~]# logger -p authpriv.notice "esta es una

prueba"
[root@pruebas ~]# tail -n 1 /var/log/secure

Mar 10 09:38:06 pruebas root[5755]: esta es una prueba
[root@pruebas log]# logger -p local7.notice "Una nueva

entrada de Log"
[root@pruebas log]# tail -n 1 boot.log

Mar 10 09:07:11 pruebas root[5295]: Una nueva entrada de Log
MONITORIZANDO REGISTROS CON
JOURNALCTL
Es importante mencionar que “journal” es un componente de systemd
que ayuda a ver y administrar los archivos de registro. Puede usar el
comando journalctl para ver mensajes de logs del sistema, por ejemplo:
[root@pruebas ~]# journalctl -b | grep kvm

Feb 22 08:53:37 pruebas.aptivalabs kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00
Feb 22 08:53:37 pruebas.aptivalabs kernel: kvm-clock: cpu 0, msr 6b1a01001, primary cpu clock
Feb 22 08:53:37 pruebas.aptivalabs kernel: kvm-clock: using sched offset of 12860236764 cycles
Feb 22 08:53:37 pruebas.aptivalabs kernel: clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
Feb 22 08:53:37 pruebas.aptivalabs kernel: kvm-stealtime: cpu 0, msr 77542c080
Feb 22 08:53:37 pruebas.aptivalabs kernel: clocksource: Switched to clocksource kvm-clock
Feb 22 08:53:37 pruebas.aptivalabs systemd[1]: Detected virtualization kvm.
Feb 22 08:53:48 pruebas.aptivalabs systemd[1]: Detected virtualization kvm.
Para ver todos los mensajes de logs usted puede hacer lo siguiente:
[root@pruebas ~]# journalctl

-- Logs begin at Mon 2021-02-22 08:53:37 -05, end at Mon 2021-02-22 13:41:02 -05. --
Feb 22 08:53:37 pruebas.aptivalabs kernel: Linux version 4.18.0-240.15.1.el8_3.x86_64
(mockbuild@x86-vm-0>
Feb 22 08:53:37 pruebas.aptivalabs kernel: Command line: BOOT_IMAGE=
(hd0,msdos1)/vmlinuz-4.18.0-240.15.1.>
Feb 22 08:53:37 pruebas.aptivalabs kernel: x86/fpu: x87 FPU will use FXSAVE
Feb 22 08:53:37 pruebas.aptivalabs kernel: BIOS-provided physical RAM map:
Para ver los logs relacionados a un dispositivo es posible hacer lo

siguiente:
[root@pruebas ~]# journalctl /dev/sda

Feb 22 08:53:37 pruebas.aptivalabs kernel: pci 0000:00:05.0: [1af4:1004] type 00 class 0x010000
Feb 22 08:53:37 pruebas.aptivalabs kernel: pci 0000:00:05.0: reg 0x10: [io 0xe040-0xe07f]
Feb 22 08:53:37 pruebas.aptivalabs kernel: pci 0000:00:05.0: reg 0x14: [mem 0xfead1000-0xfead1fff]
Feb 22 08:53:37 pruebas.aptivalabs kernel: pci 0000:00:05.0: reg 0x20: [mem 0xfe404000-0xfe407fff 64bit p>
Feb 22 08:53:39 pruebas.aptivalabs kernel: scsi host0: Virtio SCSI HBA
Feb 22 08:53:39 pruebas.aptivalabs kernel: scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK 2.5+>
Feb 22 08:53:39 pruebas.aptivalabs kernel: scsi 0:0:0:0: Attached scsi generic sg0 type 0
Feb 22 08:53:39 pruebas.aptivalabs kernel: sd 0:0:0:0: Power-on or device reset occurred
Feb 22 08:53:39 pruebas.aptivalabs kernel: sd 0:0:0:0: [sda] 104857600 512-byte logical blocks: (53.7 GB/>
Feb 22 08:53:39 pruebas.aptivalabs kernel: sd 0:0:0:0: [sda] Write Protect is off
Feb 22 08:53:39 pruebas.aptivalabs kernel: sd 0:0:0:0: [sda] Mode Sense: 63 00 00 08
Feb 22 08:53:39 pruebas.aptivalabs kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, d>
Feb 22 08:53:39 pruebas.aptivalabs kernel: sd 0:0:0:0: [sda] Attached SCSI disk
Para ver logs asociados al proceso de boot, realice lo siguiente:
[root@pruebas ~]# journalctl -b

Feb 22 08:53:37 pruebas.aptivalabs kernel: Linux version 4.18.0-240.15.1.el8_3.x86_64
(mockbuild@x86-vm-0>
Feb 22 08:53:37 pruebas.aptivalabs kernel: Command line: BOOT_IMAGE=
(hd0,msdos1)/vmlinuz-4.18.0-240.15.1.>
Feb 22 08:53:37 pruebas.aptivalabs kernel: x86/fpu: x87 FPU will use FXSAVE
Feb 22 08:53:37 pruebas.aptivalabs kernel: BIOS-provided physical RAM map:
ADMINISTRACIÓN DEL NETWORKING
NOMBRANDO LAS INTERFACES DE RED
DEL SISTEMA
Red Hat Enterprise Linux 8 proporciona métodos para nombrar
dispositivos de red. Estos métodos ayudan a localizar y diferenciar las
interfaces de red. El kernel asigna nombres a las interfaces de red
concatenando un prefijo fijo y un número que aumenta a medida que el
kernel inicializa los dispositivos de red. De forma predeterminada, “udev”
asigna nombres fijos según el firmware, la topología y la información de
ubicación. La siguiente tabla detalla el esquema como “udev” realiza este
nombramiento a las interfaces de red:
Esquema Descripción Ejemplo
El nombre del dispositivo

incorpora información que es
proporcionada por el firmware o la
BIOS. Si esta información no está
1 eno1
disponible o no es aplicable, “udev”
usa el esquema 2. La letra “o” indica
que esta tarjeta puede estar integrada
en la tarjeta madre (on-board).
2 ens1
incorpora información que es
proporcionada por el firmware o por la
BIOS en relación con los números de
índice de ranura de conexión de las
tarjetas PCI Express. Si esta
información no está disponible o no es
aplicable, “udev” usa el esquema 3.
La letra “s” indica que esta tarjeta
puede estar integrada en la tarjeta
madre en un puerto PCI Express.
El dispositivo es nombrado por la
ubicación física del conector de
3 hardware. Si esta información no está enp2s0
disponible o no es aplicable, “udev”
usa el esquema 5.

4 enx525400d5e0fb
incorpora la dirección MAC.
Si udev no puede aplicar

cualquiera de los otros esquemas
5 eth0
anteriores, el administrador de
dispositivos usa este esquema.
En el caso del servidor RHEL 8 donde se están realizando las pruebas de

todas las temáticas, tenemos la información relacionada para las interfaces
de red, donde inicialmente vemos a través del comando “lspci” que nuestras
tarjetas de red están consideradas como si estuvieran conectadas a puertos
PCI Express, como se muestra en el comando a continuación:
[root@pruebas ~]# lspci -vmm
Slot:00:12.0
Class:Ethernet controller
Vendor:Red Hat, Inc.
Device:Virtio network device
SVendor:Red Hat, Inc.
SDevice:Device 0001
PhySlot:18
Slot:00:13.0
Class:Ethernet controller
Vendor:Intel Corporation
Device:82540EM Gigabit Ethernet Controller
SVendor:Red Hat, Inc.
SDevice:QEMU Virtual Machine
PhySlot:19
Rev:03
Este servidor donde se están realizando las pruebas es una maquina

virtual sobre KVM el cual está integrado a QEMU, siendo QEMU quien
administra la información de las interfaces y la ubicación de las posiciones
según el hardware emulado. Para QEMU las dos (2) interfaces de red que
hay sobre esta maquina virtual están en las posiciones físicas 18 y 19
respectivamente, debido a ello el nombre de las tarjetas.
[root@pruebas ~]# ip add
--- salid omitida --

2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP group default qlen 1000

state UP group default qlen 1000
--- salida omitida
GESTIÓN DE INTERFACES CON
NETWORK MANAGER
De forma predeterminada, RHEL 8 usa Network Manager para
administrar la configuración y las conexiones de la red. Utilizar Network
Manager le permitirá configurar las interfaces de red desde herramientas
como el CLI de Linux, la herramienta “nmtui”, o a través de la interfaz
grafica del sistema operativo.
Network Manager es un servicio controlado desde su archivo de unidad,

tal como se muestra a continuación:
[root@pruebas ~]# systemctl list-units | grep Network

NetworkManager.serviceloaded active running Network Manager
Para su información, Network Manager coloca sus scripts de

configuración en /etc/sysconfig/network-scripts/, como se muestra a
continuación:
[root@pruebas ~]# ll /etc/sysconfig/network-scripts/

total 8
-rw-r--r--. 1 root root 365 Feb 21 22:11 ifcfg-c1
-rw-r--r--. 1 root root 344 Dec 18 10:03 ifcfg-ens18
Es importante señalar que para Network Manager existen los

dispositivos y las conexiones, un dispositivo es la interfaz de red con la que
cuenta el sistema Linux, esta interfaz de red puede tener varias conexiones
asociadas pero solamente una de ellas será la que esté activa. La
información de estas conexiones es almacenada en /etc/sysconfig/network-
scripts/.
Este material utiliza la herramienta “nmcli” para comunicarse con

Network Manager y ajustar las configuraciones que se requieran sobre las
interfaces de red del sistema. A continuación, se detalla como observa
Network Manager a las interfaces de red, por ejemplo, a la interfaz llamada
“ens18”:
[root@pruebas ~]# nmcli device show

GENERAL.DEVICE: ens18
GENERAL.TYPE: ethernet
GENERAL.HWADDR: 42:E5:C0:DB:FF:2B
GENERAL.MTU: 1500
GENERAL.STATE: 100 (connected)
GENERAL.CONNECTION: ens18
GENERAL.CON-PATH:
/org/freedesktop/NetworkManager/ActiveConnection/1
WIRED-PROPERTIES.CARRIER: on
IP4.ADDRESS[1]: 192.168.0.200/24
IP4.GATEWAY: 192.168.0.1
IP4.ROUTE[1]: dst = 192.168.0.0/24, nh = 0.0.0.0, mt = 100
IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.0.1, mt = 100
IP4.DNS[1]: 8.8.8.8
IP6.ADDRESS[1]: fe80::de85:641c:6cbb:8d7/64
IP6.GATEWAY: --
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 100
IP6.ROUTE[2]: dst = ff00::/8, nh = ::, mt = 256, table=255
Se observa los datos de configuración IPv6 e IPv4 asi como que la

interfaz cuenta con un nombre, el cual es “ens18” y su conexión es llamada
“ens18”
CONFIGURACIÓN DE INTERFACES DE
RED
Configurando una interfaz estática usando “nmcli”
Este procedimiento describe como adicionar una conexión Ethernet con

los siguientes datos de configuración a través de la herramienta nmcli:
Una dirección IPv4 estática - 192.168.0.201 con mascara /24

Una IP de Gateway - 192.168.0.1
Una dirección IPv4 para DNS – 8.8.8.8
Un dominio de búsqueda DNS – aptivalabs.local
Inicialmente identificamos el dispositivo de red donde se aplicarán las

configuraciones:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 42:e5:c0:db:ff:2b brd ff:ff:ff:ff:ff:ff
inet 192.168.0.200/24 brd 192.168.0.255 scope global noprefixroute ens18
inet6 fe80::de85:641c:6cbb:8d7/64 scope link noprefixroute
link/ether 62:15:38:28:16:0e brd ff:ff:ff:ff:ff:ff
Como se visualiza en el listado de dispositivos, el dispositivo para

establecer la configuración es el “ens19”. A continuación vamos configurar
la interfaz de red:
1. Se creará la conexión, la cual llamaremos “c1”
[root@pruebas ~]# nmcli connection add con-name c1 ifname

ens19 type ethernet
2. Se realiza un listado de las conexiones para verificar:
[root@pruebas ~]# nmcli connection show

NAME UUID TYPE DEVICE
ens18 89ff7d5f-fce4-437f-b828-a5d700c8c8a2 ethernet ens18
c1 beb2ec70-e965-4ed7-b394-78c6a2479a94 ethernet ens19
3. Se establece la dirección IP de la conexión:
[root@pruebas ~]# nmcli connection modify c1 ipv4.addresses

192.168.0.201/24
4. Se establece el método de la conexión a manual:
[root@pruebas ~]# nmcli connection modify c1 ipv4.method

manual
5. Se establece la dirección IP del gateway
[root@pruebas ~]# nmcli connection modify c1 ipv4.gateway

192.168.0.1
6. Se establece el DNS usado para la interfaz:
[root@pruebas ~]# nmcli connection modify c1 ipv4.dns "8.8.8.8"
7. Se establece el dominio de busqueda de DNS:
[root@pruebas ~]# nmcli connection modify c1 ipv4.dns-search

aptivalabs.local
8. Se activa la conexión:
[root@pruebas ~]# nmcli connection up c1
Para verificar que la configuración ha sido satisfactoria se realizan los

siguientes pasos:
1. Detallar el estatus del dispositivo y conexión:
[root@pruebas ~]# nmcli device status

DEVICE TYPE STATE CONNECTION
ens19 ethernet connected c1
virbr0 bridge connected (externally) virbr0
ens18 ethernet disconnected --
lo loopback unmanaged --
virbr0-nic tun unmanaged --
2. Detallar las configuraciones de la conexión:
[root@pruebas ~]# nmcli connection show c1
3. Usar el comando ping para verificar que se pueden enviar

paquetes a otros hosts:
[root@pruebas ~]# ping 192.168.0.1

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=2.62 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.739 ms
^C
--- 192.168.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 0.739/1.681/2.623/0.942 ms
[root@pruebas ~]# ping redhat.com

PING redhat.com (209.132.183.105) 56(84) bytes of data.
64 bytes from redirect.redhat.com (209.132.183.105): icmp_seq=1 ttl=235 time=117 ms
^C
--- redhat.com ping statistics ---
Network Manager le permite crear las conexiones editando directamente

sobre los archivos de configuración, como se muestra a continuación:
[root@pruebas ~]# cat /etc/sysconfig/network-scripts/ifcfg-

fmestre
TYPE=Ethernet
BOOTPROTO=none
NAME=fmestre
DEVICE=ens19
ONBOOT=yes
IPADDR=192.168.0.220
PREFIX=24
GATEWAY=192.168.0.1
DNS1=8.8.8.8
La anterior configuración obedece a una conexión personalizada llamada

“fmestre”, la cual actuará sobre el dispositivo de red “ens19” con los datos
de configuración previamente definidos. El siguiente listado nos permite
observar que existen tres conexiones, dos de ellas (“fmestre” y “dinámica”)
actuando sobre el dispositivo “ens19”.
[root@pruebas network-scripts]# ll
total 12
-rw-r--r--. 1 root root 208 Mar 8 12:05 ifcfg-dinamica
-rw-r--r--. 1 root root 131 Mar 9 09:06 ifcfg-fmestre
Validando los archivos de configuración “ifcfg-dinamica” y “ifcfg-

fmestre” es posible ver que ambas conexiones actúan sobre una sola interfaz,
como vemos a continuación.
[root@pruebas network-scripts]# cat ifcfg-dinamica ifcfg-fmestre |
grep DEVICE
DEVICE=ens19
DEVICE=ens19
A continuación cargaremos en el sistema la conexión “fmestre”, creada

de forma manual en el archivo de configuración “ifcfg-fmestre”, bajando la
configuración previa en la conexión llamada “dinamica”:
[root@pruebas network-scripts]# nmcli connection up fmestre

Connection successfully activated (D-Bus active path:
/org/freedesktop/NetworkManager/ActiveConnection/4)
[root@pruebas network-scripts]# ip add

link/ether 4a:bf:c6:6b:4f:5e brd ff:ff:ff:ff:ff:ff
inet6 fe80::48bf:c6ff:fe6b:4f5e/64 scope link
Usted puede subir o bajar conexiones con “nmcli connection up” e

“nmcli connection down” respectivamente. Solo coloque el archivo con la
configuración de la conexión según lo explicado en esta sección.
CONFIGURANDO INTERFACES DE RED UTILIZANDO “nmtui”
Para entrar a configurar interfaces con nmtui es necesario verificar que el

paquete se encuentre instalado en el sistema, como se muestra a
continuación:
[root@pruebas ~]# yum list installed | grep NetworkManager-tui
NetworkManager-tui.x86_64 1:1.26.0-13.el8_3 @rhel-8-
Si el paquete no está instalado usted podría realizar un # yum -y install

NetworkManager-tui, después de eso para activar la herramienta usted podrá
ejecutar el comando nmtui, donde verá las siguientes pantallas:
CONFIGURANDO UNA CONEXIÓN POR
DHCP CON NMCLI
Para configurar una conexión dinámica es necesario que exista en su red
de datos un servicio DHCP recibiendo solicitudes. Para este caso en
particular se eliminará una conexión existente llamada “c1”, podrá notar que
cuando la conexión es eliminada, el archivo de configuración previamente
creado desaparece de la ruta /etc/sysconfig/network-scripts/.
[root@pruebas ~]# nmcli connection delete c1

Connection 'c1' (029928bd-00ba-4914-a65c-16cdc3da5129)
successfully deleted.
total 4
Si hemos estado siguiendo los ejercicios previos, en estos momentos

contamos con una interfaz de red libre para configurar y sin archivo de
conexión, en este caso “ens19”:

ens18 ethernet connected ens18

Procedemos entonces a crear una conexión para que la interfaz “ens19”

tome una dirección IP desde un servicio DHCP, como se muestra a
continuación:
[root@pruebas ~]# nmcli connection add con-name dinamica

ifname ens19 type ethernet
Connection 'dinamica' (b72fdf08-dde8-43e6-9879-f91841133b5b)
successfully added.

ens18 ethernet connected ens18
ens19 ethernet connected dinamica

dinamica b72fdf08-dde8-43e6-9879-f91841133b5b ethernet ens19
Con las instrucciones anteriores Network Manager ha creado una

conexión llamada “dinamica” que utiliza la interfaz “ens19”, como se detalla
a continuación:
[root@pruebas ~]# nmcli device show ens19

GENERAL.HWADDR: 4A:BF:C6:6B:4F:5E
GENERAL.MTU: 1500
GENERAL.CONNECTION: dinamica
GENERAL.CON-PATH:
IP4.ADDRESS[1]: 192.168.0.29/24
IP4.GATEWAY: 192.168.0.1
IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.0.1, mt = 101
IP4.ROUTE[2]: dst = 192.168.0.0/24, nh = 0.0.0.0, mt = 101
IP4.DNS[1]: 190.157.8.100
IP4.DNS[2]: 190.157.8.109
IP6.ADDRESS[1]: fe80::3b6:5025:93f:fca8/64
IP6.GATEWAY: --
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 101
IP6.ROUTE[2]: dst = ff00::/8, nh = ::, mt = 256, table=255
Network Manager creó la conexión e inmediatamente la activó, si

necesidad de realizar otras configuraciones, al mismo tiempo ha creado el
archivo correspondiente en /etc/sysconfig/network-scripts/ como se muestra
a continuación:
total 8
-rw-r--r--. 1 root root 283 Mar 8 11:44 ifcfg-dinamica
DESACTIVANDO IPv6 SOBRE LA
CONFIGURACIÓN DE LA INTERFAZ
Como pasa en muchos escenarios de redes LAN, el uso del protocolo
IPv6 es nulo por lo tanto no es necesario que la interfaz de red tome
configuraciones de este tipo, sería incluso una buena practica de seguridad
deshabilitar este tipo de configuraciones si no se van a usar, como se muestra
a continuación:
[root@pruebas ~]# nmcli connection modify dinamica ipv6.method

"disabled"
[root@pruebas ~]# nmcli connection down dinamica

Connection 'dinamica' successfully deactivated (D-Bus active path:
[root@pruebas ~]# nmcli connection up dinamica

[root@pruebas ~]# nmcli device show ens19

GENERAL.HWADDR: 4A:BF:C6:6B:4F:5E
GENERAL.MTU: 1500
GENERAL.CONNECTION: dinamica
GENERAL.CON-PATH:
IP4.ADDRESS[1]: 192.168.0.29/24
IP4.GATEWAY: 192.168.0.1
IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.0.1,
mt = 101
IP4.ROUTE[2]: dst = 192.168.0.0/24, nh = 0.0.0.0,
mt = 101
IP4.DNS[1]: 190.157.8.100
IP4.DNS[2]: 190.157.8.109
IP6.GATEWAY: --
Es necesario entonces “bajar” la conexión y después subirla para que los

cambios surtan efecto.
CONFIGURANDO NOMBRE DE HOST
Debido a que los nombres de host se utilizan para acceder a los
servidores y los servicios que ofrecen, es importante saber cómo configurar
el nombre de host del sistema. Por lo general, un nombre de host consta de
diferentes partes. Estos son el nombre del host y el dominio DNS en el que
reside el host. Estas dos partes juntas forman el nombre de dominio
completo (FQDN), que se parece a pruebas.aptivalabs. Es una buena
práctica especificar siempre un FQDN, y no solo el nombre de host, porque
el FQDN proporciona una identidad única en Internet.
Existen diferentes formas para cambiar el nombre de un host. Usted

podrá utilizar la aplicación “nmtui”, podrá editar el archivo /etc/hostname o
podrá utilizar la herramienta “hostnamectl” para ello. Resulta importante
que los hosts donde se realizan operaciones estén identificados con un
FQDN (Fully Qualified Domain Name).
Para conocer información relacionada con el host podría hacer lo

siguiente:
[root@pruebas ~]# hostnamectl status

Static hostname: pruebas.aptivalabs
Icon name: computer-vm
Chassis: vm
Machine ID: 0592fcddc9a04f118fa2e5538498f91f
Boot ID: ae54eb1126c749788b8392fba61f2b78
Virtualization: kvm
Operating System: Red Hat Enterprise Linux 8.3 (Ootpa)
CPE OS Name: cpe:/o:redhat:enterprise_linux:8.3:GA
Kernel: Linux 4.18.0-240.15.1.el8_3.x86_64
Architecture: x86-64
Para cambiar el nombre del host con “hostnamectl” usted podría hacer
como sigue a continuación:
[root@pruebas ~]# hostnamectl set-hostname
server1.aptivalabs
Para ver el cambio en el “shebang” a algo como [root@server1 ~]# será

necesario que usted cierre su sesión en su sistema Linux. Si está ejecutando
actividades de administración en la consola física y quiere ver el cambio
deberá cerrar la sesión y volver a registrarse.
Aprovechando este apartado, es importante mencionar que en el archivo

/etc/hosts se guarda información relacionada con el propio host y con otros
hosts dentro de su red. Una muestra del archivo es la siguiente:
[root@pruebas ~]# cat /etc/hosts

127.0.0.1 localhost localhost.localdomain localhost4
localhost4.localdomain4
::1 localhost localhost.localdomain localhost6
localhost6.localdomain6
Usted puede agregar entradas a este archivo para mapear (relacionar)

direcciones IP y nombres de hosts, para asi alcanzarlos a ellos por el nombre
y no por dirección IP, como se muestra a continuación:
[root@pruebas ~]# echo "192.168.0.1 router router.aptivalabs" >>

/etc/hosts
[root@pruebas ~]# ping router

PING router (192.168.0.1) 56(84) bytes of data.
64 bytes from router (192.168.0.1): icmp_seq=1 ttl=64 time=1.51 ms
^C
--- router ping statistics ---
CAPTURA DE PAQUETES EN LA
INTERFAZ DE RED – TCPDUMP
En ocasiones puede ser necesario por actividades de depuración realizar
procedimientos de captura de paquetes en función de detallar y analizar el
trafico que está pasando por las interfaces de red conectadas a los sistemas
Linux. Es aquí donde la herramienta “tcpdump” resulta de gran utilidad para
este tipo de tareas, dado a que puede capturar paquetes a un archivo y
llevarlos a un programa como “wireshark” para su respectivo análisis.
“tcpdump” imprime una descripción del contenido de los paquetes de

una interfaz de red; la descripción está precedida por una marca de tiempo,
impresa de forma predeterminada, como horas, minutos, segundos y
fracciones de segundo. También se puede ejecutar con el parámetro -w, el
cual permite guardar los datos del paquete en un archivo para su posterior
análisis. Para iniciar con el proceso de captura de paquetes detallemos las
interfaces desde donde “tcpdump” podría capturar paquetes, tal como sigue:
[root@pruebas ~]# tcpdump --list-interfaces

1.ens18 [Up, Running]
2.ens19 [Up, Running]
3.lo [Up, Running, Loopback]
4.any (Pseudo-device that captures on all interfaces) [Up, Running]
5.bluetooth-monitor (Bluetooth Linux Monitor) [none]
6.nflog (Linux netfilter log (NFLOG) interface) [none]
7.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
8.usbmon0 (Raw USB traffic, all USB buses) [none]
9.usbmon1 (Raw USB traffic, bus number 1)
Usted podrá capturar los paquetes que transitan por sus interfaces de red
como sigue:
[root@pruebas ~]# tcpdump -A

...$t.......e..g.gV.1=..^..U..Q.7.^F.J.V6....9..>H.2.Bq......5...H....2.E.)#..../..b.`n..'S4|...C%./e^
U.2yt...._n.?
&...Z..}.3....\.]....K:........V.7.....,.4.X..6..w.....&$.K#.9..T.Y*...oAehr1..Y..........^..U...VW.r"F..8.u
^_...l... t.P...@9\[&e..`..>.d.p.j..s........^.f..?Jd.:.x0.fCG..v._.t4.l..]t..).........p...2zm.........k..I(C%..h.
30132 packets captured
36607 packets received by filter
6443 packets dropped by kernel
Si lo que usted prefiere es capturar paquetes de una interfaz de red en

específico y guardar esos paquetes a un archivo, la siguiente instrucción le
puede ser de utilidad:
[root@pruebas ~]# tcpdump -i ens18 -w /root/captura-ens18-

09032021-803am.cap
dropped privs to tcpdump
tcpdump: listening on ens18, link-type EN10MB (Ethernet), capture
size 262144 bytes
^C172 packets captured
Para detener la captura de paquetes usted puede utilizar la combinación

de teclas CTRL+C. a continuación revisemos la captura de paquetes de la
instrucción anterior, la cual inicialmente podrá no ser legible para su
entendimiento:
[root@pruebas ~]# more captura-ens18-09032021-803am.cap

?ò?
30Q?t‫??ڑ‬U?kĕ?t?HL?q ȜY??~?Ί?L#h?`????ˡ???t??????|??-.QC?
oF☐?? y?A?H?r{?W ??????[?[a^L???T??Tjᾴ??n;?8??? ee???????x
Ver los paquetes capturados por “tcpdump” de una forma humanamente

leíble es posible con la siguiente instrucción:
[root@pruebas ~]# tcpdump -l

334, options [nop,nop,TS val 859363138 ecr 243091656], length 540
08:16:14.902309 IP 192.168.0.35.59243 > pruebas.aptivalabs.ssh: Flags [.], ack 19890608,
win 4084, options [nop,nop,TS val 243091656 ecr 859363138], length 0
08:16:14.902437 IP pruebas.aptivalabs.ssh > 192.168.0.35.59243: Flags [P.], seq
19891148:19891528, ack 13069, win 334, options [nop,nop,TS val 859363138 ecr 243091656],
length 380
^C
106026 packets captured
La siguiente instrucción captura los paquetes en un forma humanamente

leíble y los guarda en un archivo llamado “dat”, mostrando por la salida
estándar las últimos líneas del archivo:
[root@pruebas ~]# tcpdump -l > dat & tail -f dat

08:18:56.528694 IP 192.168.0.35.59243 > pruebas.aptivalabs.ssh: Flags [.], ack 13756,
win 4084, options [nop,nop,TS val 243251747 ecr 859524754], length 0
08:18:57.552043 IP pruebas.aptivalabs.ssh > 192.168.0.35.59243: Flags [P.], seq
13756:14120, ack 1, win 334, options [nop,nop,TS val 859525778 ecr 243251747], length 364
ORDEN DE CONSULTA DE DNS DEL
NETWORK MANAGER
Network Manager ordena las consultas de DNS según configuración
definida en el archivo /etc/resolv.conf. Este orden de consulta obedece a
varias reglas, las cuales se comparten a continuación:
Si una sola conexión existe en el sistema Linux, Network

Manager usa la dirección IPv4 o IPv6 definida en esa conexión.
Si existen multiples conexiones definidas en el sistema Linux,

Network Manager realiza consultas de DNS basadas en valores de
prioridad definidas en el archivo
/etc/NetworkManager/NetworkManager.conf en la sección
“[main]”.
Si usted no estableció valores de prioridad o los definió en 0,

Network Manager usa los valores definidos en la configuración
global (/etc/resolv.conf).
A continuación se visualiza el contenido de /etc/resolv.conf y el archivo

de configuración de la conexión “ens18”, donde se puede apreciar el detalle
de los DNS:
[root@pruebas ~]# cat /etc/resolv.conf

# Generated by NetworkManager
search aptivalabs
nameserver 8.8.8.8

ens18
TYPE=Ethernet
DEVICE=ens18
ONBOOT=yes
IPADDR=192.168.0.200
PREFIX=24
GATEWAY=192.168.0.1
DNS1=8.8.8.8
Usted podrá obtener mas información de Network Manager como se

[root@pruebas ~]# journalctl -u NetworkManager

-- Logs begin at Tue 2021-03-09 06:54:40 -05, end at Tue 2021-03-09 08:54:31 -05. --
Mar 09 06:55:02 pruebas.aptivalabs systemd[1]: Starting Network Manager...
Mar 09 06:55:02 pruebas.aptivalabs NetworkManager[1225]: <info> [1615290902.1838]
Read config: /etc/NetworkManag>
Mar 09 06:55:02 pruebas.aptivalabs systemd[1]: Started Network Manager.
CONFIGURACIÓN DE RUTAS ESTÁTICAS
La puerta de enlace predeterminada es un router que reenvía paquetes de
red cuando ninguna otra ruta coincide con el destino de un paquete. En una
red local, la puerta de enlace predeterminada suele ser el host que está un
salto más cerca a la Internet, pero no necesariamente debe de ser así,
posiblemente usted no requiere que su Linux Server salga a Internet, solo
que se comunique con otros equipos en la red, fuera de la subred donde se
encuentra.
La configuración de la ruta estática normalmente es definida en la

configuración de cada conexión de red que usa direccionamiento estático,
por que si el direccionamiento es asignado por DHCP, seguramente ahí
vendrá definido el Gateway por default. Una vez usted ha creado una
conexión podría actualizar la puerta de enlace predeterminada modificando
los datos de la conexión, como se muestra a continuación:
[root@pruebas ~]# nmcli connection modify fmestre ipv4.gateway

"192.0.2.1"

fmestre
TYPE=Ethernet
BOOTPROTO=none
NAME=fmestre
DEVICE=ens19
ONBOOT=yes
IPADDR=192.168.0.220
PREFIX=24
GATEWAY=192.0.2.1
DNS1=8.8.8.8
PROXY_METHOD=none
BROWSER_ONLY=no
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
UUID=bf82469a-5737-a618-9bff-513ddb330ede
En un escenario de un sistema Linux con dos interfaces de red podemos

ver como este cambio altera las rutas por default de cada una de las
interfaces, como se muestra a continuación:
[root@pruebas ~]# ip route

default via 192.168.0.1 dev ens18 proto static metric 100
default via 192.0.2.1 dev ens19 proto static metric 101
AGRUPAMIENTO DE INTERFACES DE
RED – TEAMING
El agrupamiento de tarjetas de red es útil a la hora de colocar servidores
en operación con aplicaciones que representan misión crítica para las
organizaciones. La formación de un agrupamiento de interfaces es una
función que combina o agrega interfaces de red para proporcionar una
interfaz con mayor rendimiento o redundancia.
El siguiente procedimiento tiene como objetivo implementar un

agrupamiento de tres tarjetas de red con el fin de proporcionar mecanismos
de disponibilidad de conexión a la red y aumento en la transferencia de
datos. Iniciamos creando la interfaz virtual de red, llamada “team0”, interfaz
que será del tipo “team”, asignando el “runner”, que hace referencia a la
forma como se va a comportar el trafico de los paquetes. Los “runners”
mencionados anteriormente permiten darle tratamiento a los paquetes como
se lista a continuación:
broadcast: transmite datos a través de todos los puertos.

roundrobin: transmite datos a través de todos los puertos a su
vez.
activebackup: Transmite datos a través de un puerto mientras
que los otros se mantienen como respaldo.
loadbalance: transmite datos a través de todos los puertos con
equilibrio de carga activo.
random: transmite datos en un puerto seleccionado al azar.
lacp: implementa el protocolo de control de agregación de
enlaces 802.3ad (LACP).
Debe ser una decisión coordinada el hecho de escoger el “runner” a

utilizar, esto se podría consensuar con quien administre la red de datos de la
compañía. Creamos la interfaz:
[root@pruebas ~]# nmcli connection add type team con-name

team0 ifname team0 autoconnect yes config '{"runner": {"name":
"roundrobin"}}'
Connection 'team0' (7c56312c-9eef-4ec3-b141-683d0b15d634)
successfully added.
Se le asigna dirección IPv4 a la interfaz:
[root@pruebas ~]# nmcli connection modify team0 ipv4.addresses

'192.168.0.33/24'
Se establece el método de conexión a estático:
[root@pruebas ~]# nmcli connection modify team0 ipv4.method

manual
Se crean las conexiones tipo esclavas, que usan las tres interfaces
definidas para este laboratorio (ens19, ens20 y ens21):
[root@pruebas ~]# nmcli connection add type team-slave con-name

team0-port1 ifname ens19 master team0
Connection 'team0-port1' (6f27d697-41cf-4480-8c9f-b25744baaa47) successfully added.

Connection 'team0-port2' (6426cc8a-1ea8-4750-9e5d-57d9c492a98f) successfully added.

Connection 'team0-port3' (5158cda8-975a-4e10-ade1-844099962059) successfully added.
Se verifica si ha sido la interfaz “team0”:

master team0 state UP group default qlen 1000
7: team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
inet 192.168.0.30/24 brd 192.168.0.255 scope global dynamic noprefixroute team0
valid_lft 604684sec preferred_lft 604684sec
inet6 fe80::f9aa:a5a5:85be:26c0/64 scope link noprefixroute
Para adicionar el resto de los parámetros sobre la interfaz esta se desactiva

temporalmente:
[root@pruebas ~]# nmcli connection down team0

Connection 'team0' successfully deactivated (D-Bus active path:
Se modifican los parametros requeridos, como dirección IP, DNS

primario y secundario:
[root@pruebas ~]# nmcli connection modify team0 ipv4.gateway

192.168.0.1
[root@pruebas ~]# nmcli connection modify team0 ipv4.dns 8.8.8.8
[root@pruebas ~]# nmcli connection modify team0 +ipv4.dns

190.157.8.1
Se lista nuevamente información de la interfaz, como previamente se le

hizo un “down” no debe de mostrarnos información relacionada.

link/ether 22:f7:fa:d0:09:1e brd ff:ff:ff:ff:ff:ff
link/ether 52:dd:21:3d:71:0c brd ff:ff:ff:ff:ff:ff
Seguidamente activamos una de las conexiones esclavas al master
“team0”, en específico subimos la conexión “team0-port2”, al subir esta
conexión automáticamente sube el team y las otras conexiones esclavas,
como lo muestra el comando “ip add”:
[root@pruebas ~]# nmcli connection up team0-port2


8: team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
inet 192.168.0.33/24 brd 192.168.0.255 scope global noprefixroute team0
inet6 fe80::f9aa:a5a5:85be:26c0/64 scope link noprefixroute
Seguido a esto revisamos el estado del “team” y esperamos que las

interfaces se encuentren en el estado UP, como se muestra a continuación:
[root@pruebas ~]# teamdctl team0 state

setup:
runner: roundrobin
ports:
ens19
link watches:
link summary: up
instance[link_watch_0]:
name: ethtool
link: up
down count: 0
ens20
link watches:
link summary: up
name: ethtool
link: up
down count: 0
ens21
link watches:
link summary: up
name: ethtool
link: up
down count: 0
Para finalizar miramos los conexiones activas en el sistema con el

objetivo de verificar que la conexiones masters y esclavas del team estén
referenciadas:
[root@pruebas ~]# nmcli connection show --active

team0 7c56312c-9eef-4ec3-b141-683d0b15d634 team team0
team0-port1 6f27d697-41cf-4480-8c9f-b25744baaa47 ethernet ens19
team0-port2 6426cc8a-1ea8-4750-9e5d-57d9c492a98f ethernet ens20
team0-port3 5158cda8-975a-4e10-ade1-844099962059 ethernet ens21
Para este momento la interfaz team se encuentra activa, podría usted

conectar tres cables del servidor al switch y aprovechar esta funcionalidad
que le da Linux. En versiones anteriores a RHEL 7 y aun en sistemas Linux
nuevos como Debian o Ubuntu Server usan el procedimiento para crear un
concepto similar llamado “bonding”, sin embargo “teaming” llegó para
reemplazarlo por completo, trayendo consigo ventajas de consideración,
motivo por el cual no se detalla el despliegue de un “bonding” en este
material.
CREANDO INTERFACES TIPO BRIDGE
Un “bridge” es un dispositivo en la capa de enlace que reenvía el tráfico
entre redes basándose en una tabla de MAC direcciones. El bridge crea la
tabla de direcciones MAC escuchando el tráfico de la red y, por lo tanto,
aprende qué hosts están conectados a cada red. Por ejemplo, puede utilizar
un bridge en un host RHEL 8 para emular un bridge de hardware o en
entornos de virtualización, para integrar máquinas virtuales (VM) a la misma
red que el host, las maquinas virtuales que se creen quedarán en el mismo
segmento de red que el host que las hospeda.
Un bridge requiere un dispositivo de red en cada red que el puente debe

conectar. Cuando configura un puente, el bridge se llama “controlador” y los
dispositivos que utiliza se conocen como “puertos”. Para crear una interfaz
tipo “bridge” haga lo siguiente:
[root@pruebas ~]# nmcli connection add type bridge con-name br0

ifname br0
Connection 'br0' (ac199e07-83cb-41b3-af5a-2cd9ed4ca1b1) successfully added.
Seguidamente agregue las interfaces esclavas del bridge, como se

[root@pruebas ~]# nmcli connection add type ethernet slave-

type bridge con-name br0-port1 ifname ens19 master br0
Connection 'br0-port1' (705486cf-ed90-474a-ae1e-a30187ca40a6) successfully added.

Connection 'br0-port2' (0db3f295-6b02-4566-b5ef-b41262b399bb) successfully added.

Connection 'br0-port3' (67ab1fed-4654-4cde-9567-0113cec2231f) successfully added.
A continuación, parametrice las interfaces asociadas como esclavas al

bridge:
[root@pruebas ~]# nmcli connection modify br0 ipv4.addresses
'192.168.0.33/24'
[root@pruebas ~]# nmcli connection modify br0 ipv4.gateway

'192.168.0.1'
[root@pruebas ~]# nmcli connection modify br0 ipv4.dns '8.8.8.8'
[root@pruebas ~]# nmcli connection modify br0 ipv4.dns-search

'aptivalabs.net'
[root@pruebas ~]# nmcli connection modify br0 ipv4.method

manual
Para finalizar active el “bridge” como se muestra a continuación:
[root@pruebas ~]# nmcli connection up br0

Connection successfully activated (master waiting for slaves) (D-Bus active path:
Para visualizar el estado del bridge haga como se muestra a

continuación:
[root@pruebas ~]# ip link

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
UP mode DEFAULT group default qlen 1000
link/ether 42:e5:c0:db:ff:2b brd ff:ff:ff:ff:ff:ff
master br0 state UP mode DEFAULT group default qlen 1000
link/ether 52:dd:21:3d:71:0c brd ff:ff:ff:ff:ff:ff
11: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP mode DEFAULT group default qlen 1000
ADMINISTRACIÓN DE PAQUETES DE
SOFTWARE
Para realizar las tareas de gestión de la paquetería, Red Hat Linux 8
integra YUMversión 4, el cual es basado sobre la tecnología DNF. Aunque
YUM v4 en RHEL 8 se basa en DNF, es compatible con YUM v3 usado en
RHEL 7. Para la instalación de software, el comando yum y la mayoría de
sus opciones funcionan de la misma manera en RHEL 8 que en RHEL 7.
Usted como administrador del sistema podrá observar en ocasiones en la
salida estándar información relacionada con DNF.
YUM está diseñado para trabajar con repositorios, los cuales son
depósitos online con software disponible. El software en las distribuciones
Red Hat y derivados es proporcionado en el formato RPM (Red Hat Package
Manager), este es un formato donde se integran binarios y metadata para
hacer la rutina de administración de software mas llevadera para el
administrador.
Uno de los beneficios al usar repositorios resulta en administrar las

dependencias. Cuando usted requiere instalar un paquete, YUM consulta las
dependencias del mismo en los repositorios y las instala previamente antes
de instalar el paquete objetivo, actividad que no tiene que hacer el
administrador.
Tenga en cuenta que los repositorios son específicos para cada sistema
operatvo. Por lo tanto, si usted está usando Red Hat Linux, usted debería
usar repositorios para RHEL, se podrían usar repos de CentOS en Red Hat
pero no es lo recomendado, siendo CentOS una distribución donde se
realizarán pruebas de software que una vez testeado iría a RHEL como
software validado, no como se hacía en el pasado donde todo se probaba en
Fedora, llegaba a Red Hat Linux y de ahí se liberaba el código y salía
CentOS. Si usted necesita software adicional podría adicionar (por razones
de soporte no es recomendado) el repositorio EPEL, el cual es un proyecto
en Fedora que cuenta con importante software de gestión.
Red Hat Linux es un sistema operativo con soporte y gestión de
actualizacines, este derecho se obtiene adquiriendo una suscripción a RHEL
o uniéndose al programa Red Hat Developer, que le da acceso a la
suscripción gratuita de Red Hat Enterprise Developer. Puede registrarse para
obtener la suscripción de desarrollador de Red Hat en
https://developers.redhat.com. Después de obtener una suscripción válida
para Red Hat Enterprise Linux, puede usar las herramientas de
administración de suscripción de Red Hat (RHSM) para administrar su
suscripción.
Una vez usted cuente con una suscripción asociada a su sistema

operativo usted podrá usar los repositorios oficiales de Red Hat,
normalmente son dos repos activos pero usted podrá ir activando los que
requiera a medida que los vaya necesitando. Usted puede administrar su
suscripción a través de la interfaz grafica con la que viene el sistema dentro
de la sección “settings” o ajustes o a través del CLI con el programa
subscription-manager.
Después de registrarse y adjuntar una suscripción, los certificados de

autorización se escriben en el directorio /etc/pki. En /etc/pki/product, se
almacenan certificados que indican qué productos Red Hat están instalados
en este sistema. El directorio /etc/pki/entity contiene información sobre las
suscripciones adjuntas a este sistema. Se muestra un listado de los
directorios de /etc/pki:
[root@pruebas ~]# cd /etc/pki/
[root@pruebas pki]# ll
total 0
drwxr-xr-x. 4 root root 73 Dec 17 17:10 ca-trust
drwxr-xr-x. 2 root root 37 Feb 3 10:51 consumer
drwxr-xr-x. 2 root root 70 Feb 3 10:51 entitlement
drwxr-xr-x. 2 root root 142 Dec 17 17:13 fwupd
drwxr-xr-x. 2 root root 111 Dec 17 17:13 fwupd-metadata
drwxr-xr-x. 2 root root 21 Dec 17 17:10 java
drwxr-xr-x. 2 root root 103 Dec 14 14:41 nssdb
drwxr-xr-x. 2 root root 6 Dec 17 17:23 product
drwxr-xr-x. 2 root root 21 Dec 17 17:09 product-default
drwxr-xr-x. 2 root root 71 Dec 17 17:09 rpm-gpg
drwx------. 2 root root 6 Jun 18 2020 rsyslog
drwxr-xr-x. 3 root root 16 Dec 17 17:09 swid
drwxr-xr-x. 5 root root 104 Dec 4 09:53 tls
GESTIÓN DE REPOSITORIOS DE
SOFTWARE
La información de configuración de YUM y las utilidades relacionadas
se almacenan en el archivo /etc/yum.conf. Este archivo contiene una o más
secciones que le permiten establecer opciones específicas de sus
repositorios, sin embargo, se recomienda definir repositorios individuales
en archivos .repo que deben ser ubicados en el directorio /etc/yum.repos.d/.
Tenga en cuenta que los valores que defina en las secciones individuales
[repository] del archivo /etc/yum.conf anulan valores establecidos en la
sección principal [main].
Muchas empresas compran suscripciones a Red Hat para usar su sistema

operativo. Una vez descargada la imagen ISO del sistema, es posible
suscribir este sistema y tomar ventaja de lo que representa esta suscripción,
entre ellas, el uso de los repositorios oficiales de software.
De la siguiente forma podemos ver los repositorios donde el sistema

Linux va a buscar paquetes para instalar o actualizar:
[root@pruebas ~]# yum repolist

repo id repo name
rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for x86_64 -
AppStream (RPMs)
rhel-8-for-x86_64-baseos-rpms Red Hat Enterprise Linux 8 for x86_64 -
BaseOS (RPMs)
Para listar todos aquellos repositorios que no están disponibles

(deshabilitados) para este sistema Linux usted puede hacer lo siguiente:
[root@pruebas ~]# yum repolist --disabled

repo id repo name
ansible-2-for-rhel-8-x86_64-debug-rpms Red Hat Ansible Engine 2 for
RHEL 8 x86_64 (Debug RPMs)
ansible-2-for-rhel-8-x86_64-rpms Red Hat Ansible Engine 2 for
RHEL 8 x86_64 (RPMs)
ansible-2-for-rhel-8-x86_64-source-rpms Red Hat Ansible Engine 2 for
RHEL 8 x86_64 (Source RPMs)
ansible-2.8-for-rhel-8-x86_64-debug-rpms Red Hat Ansible Engine 2.8 for
RHEL 8 x86_64 (Debug RPMs)
ansible-2.8-for-rhel-8-x86_64-rpms Red Hat Ansible Engine 2.8 for
RHEL 8 x86_64 (RPMs)
ansible-2.8-for-rhel-8-x86_64-source-rpms Red Hat Ansible Engine 2.8 for
RHEL 8 x86_64 (Source RPMs)
Para listar los repositorios deshabilitados y en uso usted puede hacer

como sigue:
[root@pruebas ~]# yum repolist --all

repo id repo name status
ansible-2-for-rhel-8-x86_64-debug-rpms Red Hat Ansible Engine 2
for RHEL 8 x86_64 disabled
ansible-2-for-rhel-8-x86_64-rpms Red Hat Ansible Engine 2 for
RHEL 8 x86_64 disabled
ansible-2-for-rhel-8-x86_64-source-rpms Red Hat Ansible Engine 2
ansible-2.8-for-rhel-8-x86_64-debug-rpms Red Hat Ansible Engine
2.8 for RHEL 8 x86_6 disabled
ansible-2.8-for-rhel-8-x86_64-rpms Red Hat Ansible Engine 2.8
ansible-2.8-for-rhel-8-x86_64-source-rpms Red Hat Ansible Engine 2.8
ansible-2.9-for-rhel-8-x86_64-debug-rpms Red Hat Ansible Engine
2.9 for RHEL 8 x86_6 disabled
ansible-2.9-for-rhel-8-x86_64-rpms Red Hat Ansible Engine 2.9
ansible-2.9-for-rhel-8-x86_64-source-rpms Red Hat Ansible Engine 2.9
automation-hub-4-beta-for-rhel-8-x86_64-debug-rpms Red Hat Automation
Hub 4 Beta for RHEL 8 x8 disabled
…
…
rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8
for x86_64 - App enabled
rhel-8-for-x86_64-appstream-source-rpms Red Hat Enterprise Linux 8
for x86_64 - App disabled
rhel-8-for-x86_64-baseos-debug-rpms Red Hat Enterprise Linux 8
for x86_64 - Bas disabled
rhel-8-for-x86_64-baseos-e4s-debug-rpms Red Hat Enterprise Linux
8 for x86_64 - Bas disabled
rhel-8-for-x86_64-baseos-e4s-rpms Red Hat Enterprise Linux 8
rhel-8-for-x86_64-baseos-e4s-source-rpms Red Hat Enterprise Linux 8
rhel-8-for-x86_64-baseos-eus-debug-rpms Red Hat Enterprise Linux
8 for x86_64 - Bas disabled
rhel-8-for-x86_64-baseos-eus-rpms Red Hat Enterprise Linux 8
rhel-8-for-x86_64-baseos-eus-source-rpms Red Hat Enterprise Linux 8
rhel-8-for-x86_64-baseos-rpms Red Hat Enterprise Linux 8 for
x86_64 - Bas enabled
rhel-8-for-x86_64-baseos-source-rpms Red Hat Enterprise Linux 8
Para tener información de los repositorios disponibles, ejecute la

siguiente instrucción:
[root@pruebas ~]# yum repoinfo

Last metadata expiration check: 1:17:37 ago on Tue 23 Feb 2021 08:59:35 AM -05.
Repo-id : rhel-8-for-x86_64-appstream-rpms
Repo-name : Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
Repo-revision : 1613659785
Repo-updated : Thu 18 Feb 2021 09:49:44 AM -05
Repo-pkgs : 16,468
Repo-available-pkgs: 14,678
Repo-size : 37 G
Repo-baseurl : https://cdn.redhat.com/content/dist/rhel8/8/x86_64/appstream/os
Repo-expire : 86,400 second(s) (last: Tue 23 Feb 2021 08:59:34 AM -05)
Repo-filename : /etc/yum.repos.d/redhat.repo
Repo-id : rhel-8-for-x86_64-baseos-rpms
Repo-name : Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)
Repo-updated : Mon 22 Feb 2021 05:45:37 AM -05
Repo-pkgs : 6,587
Repo-size : 9.4 G
Repo-baseurl : https://cdn.redhat.com/content/dist/rhel8/8/x86_64/baseos/os
Repo-expire : 86,400 second(s) (last: Tue 23 Feb 2021 08:59:35 AM -05)
Repo-filename : /etc/yum.repos.d/redhat.repo
Total packages: 23,055
Como se comentaba en apartados anteriores, la ruta /etc/yum.repos.d es

la ubicación indicada para colocar los archivos de repositorios. Al usted
suscribir un sistema en Red Hat, usted podrá usar los repositorios oficiales
de Red Hat. A continuación se detalla el repositorio que está en la ruta
/etc/yum.repos.d/, que es el archivo redhat.repo :
[root@pruebas yum.repos.d]# pwd

/etc/yum.repos.d
[root@pruebas yum.repos.d]# ll
total 92
-rw-r--r--. 1 root root 93790 Feb 18 14:33 redhat.repo
[root@pruebas yum.repos.d]# more redhat.repo

#
# Certificate-Based Repositories
# Managed by (rhsm) subscription-manager
#
# *** This file is auto-generated. Changes made here will be over-written. ***
# *** Use "subscription-manager repo-override --help" if you wish to make changes. ***
#
# If this file is empty and this system is subscribed consider
# a "yum repolist" to refresh available repos
#
…
…
[rhel-8-for-x86_64-appstream-rpms]
name = Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
baseurl = https://cdn.redhat.com/content/dist/rhel8/$releasever/x86_64/appstream/os
enabled = 1
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
sslverify = 1
sslcacert = /etc/rhsm/ca/redhat-uep.pem
sslclientkey = /etc/pki/entitlement/857675445084215268-key.pem
sslclientcert = /etc/pki/entitlement/857675445084215268.pem
metadata_expire = 86400
enabled_metadata = 1
En este archivo solo encontraremos dos líneas con la declaración

“enabled = 1”, que significa que el repositorio se encuentra activo, como se
[root@pruebas yum.repos.d]# grep "enabled = 1" redhat.repo
enabled = 1
enabled = 1
Los demás repositorios están presentes en el archivo pero no están

activos. Para activar un repositorio que quiera usar usted podría inicialmente
instalar el software “yum-utils”:
[root@pruebas ~]# yum install yum-utils

Last metadata expiration check: 3:02:32 ago on Tue 23 Feb 2021 03:01:46 PM -05.
Dependencies resolved.
======================================================
Package Architecture Version Repository
Size
======================================================
Installing:
yum-utils noarch 4.0.17-5.el8 rhel-8-for-x86_64-baseos-rpms
68 k
Transaction Summary
======================================================
Install 1 Package
Total download size: 68 k

Installed size: 20 k
Is this ok [y/N]: y
Downloading Packages:
yum-utils-4.0.17-5.el8.noarch.rpm 81 kB/s | 68 kB
00:00
------------------------------------------------------------------------------------------
Total 81 kB/s | 68 kB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : yum-utils-4.0.17-5.el8.noarch 1/1
Running scriptlet: yum-utils-4.0.17-5.el8.noarch 1/1
Verifying : yum-utils-4.0.17-5.el8.noarch 1/1
Installed products updated.
Installed:
yum-utils-4.0.17-5.el8.noarch
Complete!
Seguido a esta instalación, podría activar un repositorio de la siguiente

forma:
[root@pruebas ~]# yum-config-manager --enable ansible-2-for-

rhel-8-x86_64-rpms
[root@pruebas ~]# grep "enabled = 1"

/etc/yum.repos.d/redhat.repo
enabled = 1
enabled = 1
enabled = 1
Como ha podido ver, se ha activado el repositorio “ansible-2-for-rhel-8-

x86_64-rpms” el cual seguramente traerá paquetes de software relacionado
con la herramienta de automatización Ansible. La ultima instrucción
enviada simplemente es para listar que se tienen activos tres repositorios.
Para desactivar un repositorio, usted podría revisar la siguiente instrucción:
[root@pruebas ~]# yum-config-manager --disable ansible-2-for-

rhel-8-x86_64-rpms
[root@pruebas ~]# grep "enabled = 1"

/etc/yum.repos.d/redhat.repo
enabled = 1
enabled = 1
Para agregar un nuevo repositorio a su listado de repos, podría ejecutar la

[root@pruebas~]# yum-config-manager –add
repo=http://dl.fedoraproject.org/pub/epel/8/x86_64/
El resultado de la anterior instrucción (genera un archivo repo) es posible

detallarlo de la siguiente manera:
[root@pruebas ~]# cd /etc/yum.repos.d/
[root@pruebas yum.repos.d]# ll
total 96
-rw-r--r--. 1 root root 196 Feb 23 18:12
dl.fedoraproject.org_pub_epel_8_x86_64_.repo
-rw-r--r--. 1 root root 93608 Feb 23 18:10 redhat.repo
Por organización es posible renombrar el archivo a “epel.repo”,

organizar el archivo en su contenido por si viene mal formateado y listar los
repositorios del sistema
[root@pruebas yum.repos.d]# mv
dl.fedoraproject.org_pub_epel_8_x86_64_.repo epel.repo
[root@pruebas yum.repos.d]# vim epel.repo
[root@pruebas yum.repos.d]# yum repolist

repo id repo name
dl.fedoraproject.org_pub_epel_8_x86_64_ created by dnf config-manager from
http://dl.fedoraproject.org/pub/epel/8/x86_64/
AppStream (RPMs)
rhel-8-for-x86_64-baseos-rpms Red Hat Enterprise Linux 8 for x86_64 - BaseOS
(RPMs)
Para eliminar la cache de repositorios que reconoce el sistema Linux

(esto elimina todos los listados de software que el sistema conoce), usted lo
puede hacer de la siguiente forma:
[root@pruebas yum.repos.d]# yum clean all

17 files removed
En este momento el Sistema Linux ha quedado sin conocimiento de

donde ir a buscar software, sin embargo, el hacer un “yum repolist” haría el
que sistema Linux se sincronizara nuevamente con Red Hat y descargara el
listado de paquetes disponible.
El uso de repositorios le permite instalar de forma transparente paquetes

de software desde Internet. Esto es conveniente, pero también implica un
riesgo de seguridad. Al instalar paquetes RPM, lo hace con permisos de root,
y si en el paquete RPM existe código malicioso su sistema puede estar
comprometido. Por esa razón, debe asegurarse de que puede confiar en los
paquetes de software que está intentando instalar.
Para proteger los paquetes en un repositorio, estos paquetes a menudo se

firman con una clave GPG. Esto permite comprobar si los paquetes se han
modificado desde que el propietario del repositorio los proporcionó. La
clave GPG que se utiliza para firmar los paquetes de software también suele
estar disponible a través del repositorio. Los usuarios del repositorio pueden
descargar esa clave y almacenarla localmente para que la verificación de la
firma del paquete se pueda realizar automáticamente cada vez que se
descargue un paquete del repositorio.
Las claves GPG que se utilizaron para la firma de paquetes se instalan en
el directorio /etc/pki/rpm-gpg/ de forma predeterminada. En el primer
contacto con un repositorio, se descarga la clave GPG.
CREANDO UN REPOSITORIO CON
MEDIOS LOCALES
De la siguiente forma, es posible establecer un repositorio de software
local utilizando la imagen ISO con la que instaló el sistema operativo:
1. Cree la carpeta /repo en su sistema
[root@pruebas ~]# mkdir /repo
2. Inserte el medio de instalación, sea la USB o el DVD.
[root@pruebas ~]# lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 50G 0 disk
|-sda1 8:1 0 1G 0 part /boot
`-sda2 8:2 0 49G 0 part
|-rhel-root 253:0 0 44G 0 lvm /
`-rhel-swap 253:1 0 5G 0 lvm [SWAP]
sr0 11:0 1 8.8G 0 rom
Después de realizar la verificación de los dispositivos reconocidos por el

sistema Linux, se nos indica que el dispositivo /dev/sr0 es el que tiene el ISO
de instalación.
3. Adicione la siguiente línea al archivo /etc/fstab: “/dev/sr0

/repo iso9660 defaults 0 0” y luego digite “mount -a”
[root@pruebas ~]# echo "/dev/sr0 /repo iso9660 defaults 0 0" >> /etc/fstab
[root@pruebas ~]# cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Thu Dec 17 22:08:06 2020
#
…
…
/dev/sr0 /repo iso9660 defaults 0 0
[root@pruebas ~]# mount -a
mount: /repo: WARNING: device write-protected, mounted read-only.
Este ultimo mensaje nos indica que la carpeta /repo está disponible
como solo lectura. Si se realiza un listado de la carpeta obtendremos la
siguiente información:
[root@pruebas ~]# ll /repo/

total 48
dr-xr-xr-x. 4 root root 2048 Oct 9 05:40 AppStream
dr-xr-xr-x. 4 root root 2048 Oct 9 05:40 BaseOS
dr-xr-xr-x. 3 root root 2048 Oct 9 05:40 EFI
-r--r--r--. 1 root root 8266 Oct 9 05:37 EULA
-r--r--r--. 1 root root 18092 Oct 9 05:37 GPL
-r--r--r--. 1 root root 1669 Oct 9 05:37 RPM-GPG-KEY-redhat-beta
-r--r--r--. 1 root root 5134 Oct 9 05:37 RPM-GPG-KEY-redhat-release
-r--r--r--. 1 root root 1796 Oct 9 05:40 TRANS.TBL
-r--r--r--. 1 root root 1455 Oct 9 05:37 extra_files.json
dr-xr-xr-x. 3 root root 2048 Oct 9 05:40 images
dr-xr-xr-x. 2 root root 2048 Oct 9 05:40 isolinux
-r--r--r--. 1 root root 103 Oct 9 05:37 media.repo
Este “mount -a” deja de forma permanente en su sistema el enlace

entre la carpeta /repo y el dispositivo, en este caso una unidad de
CD/DVD. Si usted retira este medio e ingresa otro, la carpeta /repo
mostrará otro tipo de información.
4. Cree un archivo en /etc/yum.repos.d/ llamado repo1.repo e

introduzca la siguiente información:
[BaseOS]
name=BaseOS
baseurl=file:///repo/BaseOS
gpgcheck=0
5. Cree un archivo en /etc/yum.repos.d/ llamado repo2.repo e

introduzca la siguiente información:
[AppStream]
name=AppStream
baseurl=file:///repo/AppStream
gpgcheck=0
6. Digite “yum repolist” para verificar el reconocimiento del

repositorio.
[root@pruebas ~]# cd /etc/yum.repos.d/

[root@pruebas yum.repos.d]# vim repo1.repo
[root@pruebas yum.repos.d]# vim repo2.repo
[root@pruebas yum.repos.d]# yum repolist

repo id repo name
AppStream AppStream
BaseOS BaseOS
AppStream (RPMs)
(RPMs)
Aunque en este ejercicio se están repitiendo repositorios, este escenario

es ideal cuando pierda conexión a Internet y no pueda alcanzar los
repositorios oficiales de Red Hat pues estará usando el software que viene en
el ISO de instalación.
[root@pruebas yum.repos.d]# yum repoinfo

BaseOS 44 MB/s | 2.3 MB 00:00
AppStream 60 MB/s | 6.3 MB 00:00
Last metadata expiration check: 0:00:01 ago on Wed 24 Feb 2021 09:35:55 AM -05.
Repo-id : AppStream
Repo-name : AppStream
Repo-updated : Fri 09 Oct 2020 05:34:17 AM -05
Repo-pkgs : 5,802
Repo-size : 7.1 G
Repo-baseurl : file:///repo/AppStream
Repo-expire : 172,800 second(s) (last: Wed 24 Feb 2021 09:35:55 AM -05)
Repo-filename : /etc/yum.repos.d/repo2.repo
Repo-id : BaseOS
Repo-name : BaseOS
Repo-updated : Fri 09 Oct 2020 05:34:52 AM -05
Repo-pkgs : 1,696
Repo-size : 1.1 G
Repo-baseurl : file:///repo/BaseOS
Repo-expire : 172,800 second(s) (last: Wed 24 Feb 2021 09:35:54 AM -05)
Repo-filename : /etc/yum.repos.d/repo1.repo
GESTIÓN DE MODULOS Y STREAMS
Los módulos son colecciones de paquetes que representan una unidad
lógica: una aplicación, un stack de idiomas, una base de datos o un conjunto
de herramientas. Estos paquetes se crean, prueban y lanzan juntos. A manera
de ejemplo, dos versiones del servidor de base de datos PostgreSQL están
disponibles en el módulo postgresql: PostgreSQL 10 (stream
predeterminado) y PostgreSQL 9.6. Solo se puede instalar un stream de
módulo en el sistema.
En RHEL 8, Red Hat ha introducido Package Module Streams. En

versiones anteriores de RHEL, era difícil trabajar con diferentes versiones de
paquetes. Por ejemplo, RHEL 7 siempre ha proporcionado Python 2.x como
la versión predeterminada de Python, aunque Python 3.x ya estaba
disponible. Usar una versión diferente de paquetes en el espacio de usuario
como Python fue muy difícil, ya que se tuvieron que agregar diferentes
repositorios para ofrecer Python 3 en su lugar, lo que a su vez volvería a
crear problemas para los usuarios que preferirían usar una versión anterior
de Python.
En RHEL 8, se pueden ofrecer diferentes versiones del mismo paquete

mediante Package Module Streams. Además, Package Module Streams
permite actualizar aplicaciones críticas con más frecuencia de la que se
actualiza el sistema operativo base. Para separar los paquetes principales del
sistema operativo de los paquetes de espacio de usuario, RHEL 8
proporciona dos repositorios principales, mencionados anteriormente:
BaseOS y Application Stream. En BaseOS, encontrará paquetes de sistema
operativo centrales como paquetes RPM. El ciclo de vida de estos paquetes
es comparable al ciclo de vida de las versiones anteriores de RHEL.
Un módulo describe un conjunto de paquetes RPM que están juntos. Por

lo general, los módulos se organizan alrededor de una versión específica de
una aplicación, y en un módulo encontrará paquetes de módulos, junto con
todas las dependencias para esa versión específica. Cada módulo puede tener
uno o más streams de aplicaciones como se aplicó anteriormente en el caso
de PostgreSQL.
De la siguiente forma es posible ver el modulo PostgreSQL y sus
streams:
[root@pruebas ~]# yum module list postgresql

AppStream
Name Stream Profiles Summary
postgresql 9.6 client, server [d] PostgreSQL server and client module
postgresql 10 [d] client, server [d] PostgreSQL server and client

module
postgresql 12 client, server [d] PostgreSQL server and client module
Usted podría ver información relacionada a un modulo en especifico,
[root@pruebas ~]# yum module info postgresql

Name : postgresql
Stream : 10 [d]
Version : 8020020200825115746
Context : 4cda2c84
Profiles : client, server [d]
Default profiles : server
Repo : AppStream
Summary : PostgreSQL server and client module
Description : PostgreSQL is an advanced Object-Relational database management system (DBMS). The postgresql-server package contains the programs
needed to create and run a PostgreSQL server, which will in turn allow you to create and maintain PostgreSQL databases. The base postgresql package contains the client
programs that you'll need to access a PostgreSQL DBMS server.
Requires : platform:[el8]
Artifacts : postgresql-0:10.14-1.module+el8.2.0+7801+be0fed80.src
: postgresql-0:10.14-1.module+el8.2.0+7801+be0fed80.x86_64
: postgresql-contrib-0:10.14-1.module+el8.2.0+7801+be0fed80.x86_64
: postgresql-contrib-debuginfo-0:10.14-1.module+el8.2.0+7801+be0fed80.x86_64
…
EJERCICIO DE INSTALACIÓN DE
MODULOS Y SUS STREAMS
El ejercicio a continuación muestra la forma para instalar módulos con
streams específicos y perfiles específicos de esos streams, en este caso
usaremos como ejemplo el modulo de PHP que cuenta con varios streams
para activar e instalar:
1. Listemos los streams asociados al modulo PHP:
[root@pruebas ~]# yum module list php

AppStream
php 7.2 [d] common [d], devel, minimal PHP scripting language
php 7.3 common [d], devel, minimal PHP scripting language
php 7.4 common [d], devel, minimal PHP scripting language
2. Para investigar un poco mas sobre los perfiles de la versión 7.2

de PHP a instalar usted puede hacer lo siguiente:
[root@pruebas ~]# yum module info php:7.2 --profile
Name : php:7.2:8010020190515110014:2430b045:x86_64
common : php-cli
: php-common
: php-fpm
: php-json
: php-mbstring
: php-xml
devel : libzip
: php-cli
: php-common
: php-devel
: php-fpm
: php-json
: php-mbstring
: php-pear
: php-pecl-zip
: php-process
: php-xml
minimal : php-cli
: php-common
Esto mostrará los diferentes perfiles con los que cuenta este stream
7.2
3. Para instalar específicamente PHP 7.2 con su perfil “devel ”se

puede hacer de la siguiente forma:
[root@pruebas ~]# yum module install php:7.2/devel
=========================================================
Package Arch Version Repository Size
=========================================================
Installing group/module packages:
libzip x86_64 1.5.1-2.module+el8.1.0+3202+af5476b9 rhel-8-for-x86_64-
appstream-rpms 63 k
php-cli x86_64 7.2.24-1.module+el8.2.0+4601+7c76a223 rhel-8-for-x86_64-
appstream-rpms 3.1 M
php-common x86_64 7.2.24-1.module+el8.2.0+4601+7c76a223 rhel-8-for-
x86_64-appstream-rpms 662 k
php-devel x86_64 7.2.24-1.module+el8.2.0+4601+7c76a223 rhel-8-for-x86_64-
appstream-rpms 712 k
php-fpm x86_64 7.2.24-1.module+el8.2.0+4601+7c76a223 rhel-8-for-x86_64-
appstream-rpms 1.6 M
php-json x86_64 7.2.24-1.module+el8.2.0+4601+7c76a223 rhel-8-for-x86_64-
appstream-rpms 73 k
php-mbstring x86_64 7.2.24-1.module+el8.2.0+4601+7c76a223 rhel-8-for-
php-pear noarch 1:1.10.5-9.module+el8.1.0+3202+af5476b9 rhel-8-for-x86_64-
php-pecl-zip x86_64 1.15.3-1.module+el8+2561+1aca3413 rhel-8-for-x86_64-
appstream-rpms 51 k
php-process x86_64 7.2.24-1.module+el8.2.0+4601+7c76a223 rhel-8-for-
php-xml x86_64 7.2.24-1.module+el8.2.0+4601+7c76a223 rhel-8-for-x86_64-
Installing dependencies:
autoconf noarch 2.69-27.el8 rhel-8-for-x86_64-appstream-rpms
710 k
automake noarch 1.16.1-6.el8 rhel-8-for-x86_64-appstream-
rpms 713 k
cpp x86_64 8.3.1-5.1.el8 rhel-8-for-x86_64-appstream-rpms
10 M
gcc x86_64 8.3.1-5.1.el8 rhel-8-for-x86_64-appstream-rpms
23 M
gcc-c++ x86_64 8.3.1-5.1.el8 rhel-8-for-x86_64-appstream-
rpms 12 M
glibc-devel x86_64 2.28-127.el8_3.2 rhel-8-for-x86_64-baseos-
rpms 1.0 M
glibc-headers x86_64 2.28-127.el8_3.2 rhel-8-for-x86_64-baseos-
rpms 476 k
isl x86_64 0.16.1-6.el8 rhel-8-for-x86_64-appstream-rpms
841 k
kernel-headers x86_64 4.18.0-240.15.1.el8_3 rhel-8-for-x86_64-baseos-
rpms 5.6 M
libstdc++-devel x86_64 8.3.1-5.1.el8 rhel-8-for-x86_64-appstream-rpms
2.0 M
libtool x86_64 2.4.6-25.el8 rhel-8-for-x86_64-appstream-rpms
709 k
libxcrypt-devel x86_64 4.1.1-4.el8 rhel-8-for-x86_64-baseos-rpms
25 k
m4 x86_64 1.4.18-7.el8 rhel-8-for-x86_64-baseos-rpms
223 k
nginx-filesystem noarch 1:1.14.1-9.module+el8.0.0+4108+af250afe rhel-8-for-
pcre-cpp x86_64 8.42-4.el8 rhel-8-for-x86_64-baseos-rpms 47
k
pcre-devel x86_64 8.42-4.el8 rhel-8-for-x86_64-baseos-rpms
551 k
pcre-utf16 x86_64 8.42-4.el8 rhel-8-for-x86_64-baseos-rpms
195 k
pcre-utf32 x86_64 8.42-4.el8 rhel-8-for-x86_64-baseos-rpms
186 k
perl-Thread-Queue noarch 3.13-1.el8 rhel-8-for-x86_64-appstream-
rpms 24 k
Installing module profiles:
php/devel
Enabling module streams:
nginx 1.14
php 7.2
Transaction Summary
================================================================
==================================
Install 30 Packages
Total download size: 66 M

Installed size: 178 M
Is this ok [y/N]:
Como resultado de la instalación usted podrá observar la versión de PHP
instalada, tal como se muestra a continuación:
[root@pruebas ~]# php --version

PHP 7.2.24 (cli) (built: Oct 22 2019 08:28:36) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
4. Para cambiar la versión de PHP 7.2 a 7.3 usted podría hacerlo de

la siguiente forma:

The operation would result in switching of module 'php' stream '7.2' to stream '7.3'
Error: It is not possible to switch enabled streams of a module.
It is recommended to remove all installed content from the module, and reset the module
using 'yum module reset <module_name>' command. After you reset the module, you can
install the other stream.
Como se evidencia, el paso a seguir es eliminar la instalación del

stream 7.2 y resetar el modulo de PHP 7.2
[root@pruebas ~]# yum module reset php:7.2

Only module name is required. Ignoring unneeded information in argument: 'php:7.2'
================================================================
====================================
Package Architecture Version Repository Size
================================================================
====================================
Disabling module profiles:
php/devel
Resetting modules:
php
Transaction Summary
================================================================
====================================
Is this ok [y/N]: y
Complete!
Seguidamente se instala el stream con la versión 7.3, perfil “devel”

del modulo de PHP, como se detalla a continuación:
================================================================
====================================
================================================================
====================================
Upgrading:
libzip x86_64 1.5.2-1.module+el8.1.0+3189+a1bff096 rhel-8-for-x86_64-appstream-rpms 63 k
php-cli x86_64 7.3.20-1.module+el8.2.0+7373+b272fdef rhel-8-for-x86_64-appstream-rpms 3.0 M
php-common x86_64 7.3.20-1.module+el8.2.0+7373+b272fdef rhel-8-for-x86_64-appstream-rpms 669 k
php-devel x86_64 7.3.20-1.module+el8.2.0+7373+b272fdef rhel-8-for-x86_64-appstream-rpms 736 k
php-fpm x86_64 7.3.20-1.module+el8.2.0+7373+b272fdef rhel-8-for-x86_64-appstream-rpms 1.6 M
php-json x86_64 7.3.20-1.module+el8.2.0+7373+b272fdef rhel-8-for-x86_64-appstream-rpms 73 k
php-mbstring x86_64 7.3.20-1.module+el8.2.0+7373+b272fdef rhel-8-for-x86_64-appstream-rpms 618 k
php-pear noarch 1:1.10.9-1.module+el8.1.0+3189+a1bff096 rhel-8-for-x86_64-appstream-rpms 359 k
php-pecl-zip x86_64 1.15.4-1.module+el8.1.0+3189+a1bff096 rhel-8-for-x86_64-
appstream-rpms 51 k
php-process x86_64 7.3.20-1.module+el8.2.0+7373+b272fdef rhel-8-for-x86_64-appstream-rpms 84 k
php-xml x86_64 7.3.20-1.module+el8.2.0+7373+b272fdef rhel-8-for-x86_64-appstream-rpms 187 k
pcre2-devel x86_64 10.32-2.el8 rhel-8-for-x86_64-baseos-rpms 605 k
pcre2-utf16 x86_64 10.32-2.el8 rhel-8-for-x86_64-baseos-rpms 229 k
pcre2-utf32 x86_64 10.32-2.el8 rhel-8-for-x86_64-baseos-rpms 220 k
php/devel
Enabling module streams:
php 7.3
Transaction Summary
====================================================================================================
Install 3 Packages
Upgrade 11 Packages
Total download size: 8.4 M

Is this ok [y/N]: y
(1/14): pcre2-utf16-10.32-2.el8.x86_64.rpm 498 kB/s | 229 kB 00:00
(2/14): pcre2-utf32-10.32-2.el8.x86_64.rpm 308 kB/s | 220 kB 00:00
(3/14): pcre2-devel-10.32-2.el8.x86_64.rpm 694 kB/s | 605 kB 00:00
Por ultimo se valida la versión de PHP instalada, como se muestra a

continuación:
[root@pruebas ~]# php --version

PHP 7.3.20 (cli) (built: Jul 7 2020 07:53:49) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.20, Copyright (c) 1998-2018 Zend Technologies
DETALLANDO PAQUETES DE SOFTWARE
BUSCANDO, LISTANDO Y VISUALIZANDO INFORMACIÓN DE
PAQUETES
En los siguientes apartes, veremos como buscar paquetes, generar

listados, visualizar información relacionada con los paquetes, etc.
De la siguiente forma es posible buscar software en el sistema:
[root@pruebas ~]# yum search nano

===========Name Exactly Matched: nano =====================
nano.x86_64 : A small text editor
=========== Summary Matched: nano ========================
spacewalk-usix.noarch : Spacewalk server and client nano six library
El Sistema está indicando que encontró una coincidencia con el paquete

que se llama “nano” disponible dentro del repositorio.
[root@pruebas ~]# yum search --all nano

===========Name & Description & URL Matched: nano =================
nano.x86_64 : A small text editor
===========Summary Matched: nano ===============================
spacewalk-usix.noarch : Spacewalk server and client nano six library
===========Description Matched: nano =============================
perl-Time-HiRes.x86_64 : High resolution alarm, sleep, gettimeofday, interval timers
Tenga en cuenta que yum search --all permite una búsqueda más
exhaustiva pero más lenta. A continuación, listaremos todos los paquetes
instalados y disponibles para instalar en nuestro sistema, esto generará un
gran listado en pantalla, como se muestra de la siguiente forma:
[root@pruebas ~]# yum list all

Installed Packages
GConf2.x86_64 3.2.6-22.el8 @AppStream
ModemManager.x86_64 1.10.8-2.el8 @anaconda
ModemManager-glib.x86_64 1.10.8-2.el8 @anaconda
NetworkManager.x86_64 1:1.26.0-13.el8_3 @rhel-8-for-x86_64-baseos-rpms
NetworkManager-adsl.x86_64 1:1.26.0-13.el8_3 @rhel-8-for-x86_64-baseos-rpms
NetworkManager-bluetooth.x86_64 1:1.26.0-13.el8_3 @rhel-8-for-x86_64-baseos-rpms
…
De la siguiente forma podemos ver todos los paquetes instalados, un gran
listado se genera:
[root@pruebas ~]# yum list installed

Installed Packages
GConf2.x86_64 3.2.6-22.el8 @AppStream
ModemManager.x86_64 1.10.8-2.el8 @anaconda
ModemManager-glib.x86_64 1.10.8-2.el8 @anaconda
NetworkManager.x86_64 1:1.26.0-13.el8_3 @rhel-8-for-

x86_64-baseos-rpms
NetworkManager-adsl.x86_64 1:1.26.0-13.el8_3 @rhel-8-
NetworkManager-bluetooth.x86_64 1:1.26.0-13.el8_3 @rhel-8-
…
De la siguiente forma podemos ver todos los paquetes disponibles para

instalar, un gran listado se genera:
[root@pruebas ~]# yum list available

Available Packages
CUnit.i686 2.1.3-17.el8 rhel-8-for-x86_64-
appstream-rpms
CUnit.x86_64 2.1.3-17.el8 rhel-8-for-x86_64-
appstream-rpms
GConf2.i686 3.2.6-22.el8 rhel-8-for-x86_64-
appstream-rpms
HdrHistogram.noarch 2.1.11-2.module+el8.2.1+6346+3bc8dea2
rhel-8-for-x86_64-appstream-rpms
HdrHistogram-javadoc.noarch 2.1.11-2.module+el8.2.1+6346+3bc8dea2
rhel-8-for-x86_64-appstream-rpms
HdrHistogram_c.i686 0.9.13-2.el8 rhel-8-for-
x86_64-appstream-rpms
HdrHistogram_c.x86_64 0.9.13-2.el8 rhel-8-for-
x86_64-appstream-rpms
…
Para encontrar información relacionada a un paquete, siga el siguiente

comando:
[root@pruebas ~]# yum info nano

Last metadata expiration check: 1:20:31 ago on Tue 23 Feb 2021
08:59:35 AM -05.
Installed Packages
Name : nano
Version : 2.9.8
Release : 1.el8
Size : 2.2 M
Source : nano-2.9.8-1.el8.src.rpm
Repository : @System
From repo : anaconda
Summary : A small text editor
URL : https://www.nano-editor.org
License : GPLv3+
Description : GNU nano is a small and friendly text editor.
GRUPOS DE PAQUETES
En Red Hat Linux existe el concepto de grupo de paquetes, donde

paquetes particulares están agrupados por un criterio en particular, por
ejemplo, el grupo de paquetes de la virtualización, el grupo de paquetes de
las herramientas de desarrollo, etc; a continuación veremos una serie de
instrucciones relacionadas con esta agrupación de paquetes.
[root@pruebas ~]# yum group summary

Installed Groups: 2
Available Groups: 10
Como podemos observar se cuenta con dos grupos de paquetes instaladas

y 10 disponibles para instalar. De la siguiente forma podemos detallar los
grupos de paquetes instalados y disponibles para instalar:
[root@pruebas ~]# yum group list

Available Environment Groups:
Server
Minimal Install
Workstation
Virtualization Host
Custom Operating System
Installed Environment Groups:
Server with GUI
Installed Groups:
Container Management
Headless Management
Available Groups:
RPM Development Tools
.NET Core Development
Scientific Support
Legacy UNIX Compatibility
System Tools
Development Tools
Security Tools
Smart Card Support
Network Servers
Graphical Administration Tools
Para listar los paquetes que se instalan por default en un grupo y los
paquetes opciones observe a continuación:
[root@pruebas ~]# yum group info "Development tools"

Group: Development Tools

Description: A basic development environment.
Mandatory Packages:
autoconf
automake
binutils
bison
flex
gcc
gcc-c++
gdb
glibc-devel
libtool
make
pkgconf
pkgconf-m4
pkgconf-pkg-config
redhat-rpm-config
rpm-build
rpm-sign
strace
Default Packages:
asciidoc
byacc
ctags
diffstat
git
intltool
jna
ltrace
patchutils
perl-Fedora-VSP
perl-generators
pesign
source-highlight
systemtap
valgrind
valgrind-devel
Optional Packages:
cmake
expect
rpmdevtools
rpmlint
Otra forma de listar los paquetes de un grupo se muestra a continuación,

mostrando los id’s de grupo:
[root@pruebas ~]# yum grouplist --ids

Available Environment Groups:
Server (server-product-environment)
Minimal Install (minimal-environment)
Workstation (workstation-product-environment)
Virtualization Host (virtualization-host-environment)
Custom Operating System (custom-environment)
Installed Environment Groups:
Server with GUI (graphical-server-environment)
Installed Groups:
Container Management (container-management)
Headless Management (headless-management)
Available Groups:
RPM Development Tools (rpm-development-tools)
.NET Core Development (dotnet-core)
Scientific Support (scientific)
Legacy UNIX Compatibility (legacy-unix)
System Tools (system-tools)
Development Tools (development)
Security Tools (security-tools)
Smart Card Support (smart-card)
Network Servers (network-server)
Graphical Administration Tools (graphical-admin-tools)
INSTALANDO PAQUETES DE SOFTWARE
A continuación, se demostrará como instalar paquetes de software en
Red Hat Linux (y derivados). Para instalar un paquete en particular, detalle
a continuación:
[root@pruebas ~]# yum install nano

================================================================
========================
Size
================================================================
========================
Installing:
nano x86_64 2.9.8-1.el8 rhel-8-for-x86_64-baseos-rpms
580 k
Transaction Summary
================================================================
========================
Install 1 Package

Installed size: 2.2 M
Is this ok [y/N]: y
nano-2.9.8-1.el8.x86_64.rpm 657 kB/s | 580 kB
00:00
-------------------------------------------------------------------------------------------------------------
----------------
Total 656 kB/s | 580 kB 00:00
Running transaction
Preparing : 1/1
Installing : nano-2.9.8-1.el8.x86_64 1/1
Running scriptlet: nano-2.9.8-1.el8.x86_64
1/1
Verifying : nano-2.9.8-1.el8.x86_64 1/1
Installed:
nano-2.9.8-1.el8.x86_64
Complete!
Usted puede instalar varios paquetes al mismo tiempo, únicamente

indique que paquetes requiere instalar presentando la lista separada por un
espacio. De la siguiente forma es posible instalar grupos de paquetes:
[root@pruebas ~]# yum groupinstall "Development Tools"

================================================================
==================================
Package Arch Version Repository
Size
================================================================
==================================
asciidoc noarch 8.6.10-0.5.20180627gitf7c2274.el8 rhel-8-for-x86_64-
…
Installing weak dependencies:
gcc-gdb-plugin x86_64 8.3.1-5.1.el8 rhel-8-for-x86_64-
…
Installing Groups:
Development Tools
Transaction Summary
================================================================
==================================
Install 88 Packages
Total download size: 158 M

Is this ok [y/N]:
Usted podría también instalar un grupo de paquetes por ID de grupo,

[root@pruebas ~]# yum groupinstall rpm-development-tools

…
Instalar y remover software con YUM puede complementarse con el uso
de prefijos, los cuales ayudarán a realizar estas actividades a especificar
sobre que paquetes con exactitud deben de trabajar. Por ejemplo, detalle la
siguiente expresión:
# yum install-na name.architecture
Acá, mediante el “-na” se le está especificando a YUM que utilice a

exactitud el nombre y la arquitectura del paquete a instalar. El siguiente
ejemplo lo muestra un poco mas claro:
[root@pruebas ~]# yum -y install-na nano.x86_64

================================================================
=========
Size
================================================================
=========
Installing:
nano x86_64 2.9.8-1.el8 rhel-8-for-x86_64-baseos-rpms
580 k
Transaction Summary
================================================================
=========
Install 1 Package

nano-2.9.8-1.el8.x86_64.rpm 642 kB/s | 580 kB
00:00
-------------------------------------------------------------------------------------------------------------
----------
Total 641 kB/s | 580 kB 00:00
Running transaction
Preparing : 1/1
Installing : nano-2.9.8-1.el8.x86_64 1/1
Running scriptlet: nano-2.9.8-1.el8.x86_64
1/1
Verifying : nano-2.9.8-1.el8.x86_64 1/1
Installed:
nano-2.9.8-1.el8.x86_64
Complete!
ACTUALIZACIÓN DE PAQUETES y
GRUPOS DE SOFTWARE
YUM le permite verificar si el sistema tiene actualizaciones pendientes.
Usted puede enumerar los paquetes que necesitan actualizarse y elegir
actualizar un solo paquete, varios paquetes o todos los paquetes a la vez. Si
alguno de los paquetes que elige actualizar tienen dependencias, éstas
también se actualizan. En ese orden de ideas trataremos en este ítem los
temas relacionados a:
Busqueda de actualizaciones.
Actualización de un solo paquete.
Actualización de un grupo de paquetes y sus dependencias.
Aplicar actualizaciones de seguridad.
Automatización de las actualizaciones de software.
Para visualizar las actualizaciones pendientes, detalle la siguiente

instrucción:
[root@pruebas ~]# yum check-update

microcode_ctl.x86_64 4:20200609-2.20210216.1.el8_3 rhel-

8-for-x86_64-baseos-rpms
Podemos ver como está pendiente de actualización la aplicación

“microcode_ctl”. Ahora, se detalla como se actualiza un solo paquete:
[root@pruebas ~]# yum update microcode_ctl

================================================================
=========
Size
================================================================
=========
Upgrading:
microcode_ctl x86_64 4:20200609-2.20210216.1.el8_3 rhel-8-for-
x86_64-baseos-rpms 4.6 M
Transaction Summary
================================================================
=========
Upgrade 1 Package

Is this ok [y/N]:
Para actualizar un grupo de paquetes usted podría realizar algo como lo

que se muestra a continuación:
[root@pruebas ~]# yum group update "Development tools"

Module or Group 'Development tools' is not installed.
Error: Nothing to do.
Si ha podido observar este grupo de paquetes no está instalado,

podríamos como un “yum group list installed” revisar que grupos tenemos
instalados y que podrían ser susceptibles de actualización, como se muestra a
continuación:
[root@pruebas ~]# yum group update "Container

Management"
================================================================
=========
Size
================================================================
=========
Upgrading Groups:
Transaction Summary
================================================================
=========
Is this ok [y/N]:
Usted podría actualizar todos los paquetes del Sistema y sus
dependencias de la siguiente forma:
[root@pruebas ~]# yum update

================================================================
=========
Size
================================================================
=========
Upgrading:
Transaction Summary
================================================================
=========
Upgrade 1 Package

Is this ok [y/N]:
Para actualizar el sistema Linux con paquetes relacionados con la

seguridad usted podría hacer lo siguiente:
[root@pruebas ~]# yum update --security

================================================================
=========
Size
================================================================
=========
Upgrading:
Transaction Summary
================================================================
=========
Upgrade 1 Package

Is this ok [y/N]:
ACTUALIZACIONES AUTOMÁTICAS DE SOFTWARE
Para comprobar y descargar actualizaciones de paquetes de forma

automática y periódica, puede utilizar DNF Automatic, herramienta que es
proporcionada por el paquete dnf-automatic. DNF Automatic es una
herramienta para la interfaz de línea de comandos alternativa a yum que es
adecuada para aplicaciones automáticas y regulares de actualizaciones
utilizando temporizadores systemd, Jobs de cron y otras herramientas
similares.
DNF Automatic sincroniza los metadatos del paquete según sea

necesario y luego busca actualizaciones disponibles. Después, la
herramienta puede realizar una de las siguientes acciones dependiendo de
cómo se configure:
Salir
Descargar paquetes actualizados
Descargar y aplicar las actualizaciones
El resultado de la operación se informa luego mediante un mecanismo

seleccionado, como la salida estándar o Email. Para instalar esta
herramienta es necesario hacer lo siguiente:
[root@pruebas ~]# yum install dnf-automatic

================================================================
=========
Size
================================================================
=========
Installing:
dnf-automatic noarch 4.2.23-4.el8 rhel-8-for-x86_64-baseos-
rpms 144 k
Transaction Summary
================================================================
=========
Install 1 Package
Is this ok [y/N]: y
dnf-automatic-4.2.23-4.el8.noarch.rpm 187 kB/s | 144
kB 00:00
-------------------------------------------------------------------------------------------------------------
----------------
Total 186 kB/s | 144 kB 00:00
Running transaction
Preparing : 1/1
Installing : dnf-automatic-4.2.23-4.el8.noarch
1/1
Running scriptlet: dnf-automatic-4.2.23-4.el8.noarch
1/1
Verifying : dnf-automatic-4.2.23-4.el8.noarch
1/1
Installed:
dnf-automatic-4.2.23-4.el8.noarch
Complete!
Usted podría verificar que la instalación ha sido satisfactoria de la

siguiente forma:
[root@pruebas ~]# rpm -qi dnf-automatic

Name : dnf-automatic
Version : 4.2.23
Release : 4.el8
Architecture: noarch
Install Date: Tue Feb 23 12:29:00 2021
Group : Unspecified
Size : 47701
License : GPLv2+ and GPLv2 and GPL
Signature : RSA/SHA256, Wed Jul 29 11:21:19 2020, Key ID 199e2f91fd431d51
Source RPM : dnf-4.2.23-4.el8.src.rpm
Build Date : Wed Jul 29 07:23:18 2020
Build Host : ppc-044.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor : Red Hat, Inc.
URL : https://github.com/rpm-software-management/dnf
Summary : Package manager - automated upgrades
Description :
Systemd units that can periodically download package upgrades and apply them.
Una vez instalado el software se ha generado el archivo

/etc/dnf/automatic.conf . El archivo /etc/dnf/automatic.conf guarda la
configuración de las actualizaciones automáticas; este archivo está dividido
en secciones como se muestra a continuación:
[commands] – Establece el modo de operación de DNF Automatic.

[emitters] – Define como los resultados de DNF Automatic son
reportados.
[command_email] – Define el comando que envía el Email con sus
parametros.
[email] - Provee la configuración del emisor del email. Dirección,
destinatario y host.
[base] – Sobre escribe algunas configuraciones que están en el
archive principal de configuración de YUM.
Con la configuración predeterminada del archivo

/etc/dnf/automatic.conf, DNF Automatic comprueba si hay actualizaciones
disponibles, las descarga e informa los resultados como salida estándar. Para
ejecutar DNF Automatic, siempre debe habilitar e iniciar una unidad de
temporizador de systemd. Puedes usar una de las unidades de temporizador
proporcionadas en el paquete dnf-automatic, o puede escribir su propia
unidad de temporizador dependiendo de sus necesidades.
Las unidades de temporizador que están en DNF Automatic son las

siguientes, será necesario utilizar una de ellas:
dnf-automatic-download.timer
dnf-automatic-install.timer
dnf-automatic-notifyonly.timer
dnf-automatic.timer
Para descargar actualizaciones disponibles tenga presente lo siguiente:
[root@pruebas ~]# systemctl enable dnf-automatic-download.timer

[root@pruebas ~]# systemctl start dnf-automatic-download.timer
Para descargar actualizaciones disponibles e instalarlas tenga presente lo

siguiente:
[root@pruebas ~]# systemctl enable dnf-automatic-install.timer
[root@pruebas ~]# systemctl start dnf-automatic-install.timer
Para reportar actualizaciones disponibles usted podría habilitar e iniciar

estos units:
[root@pruebas ~]# systemctl enable dnf-automatic-notifyonly.timer
[root@pruebas ~]# systemctl start dnf-automatic-notifyonly.timer
Opcionalmente, usted puede usar la unidad dnf-automatic.timer:
[root@pruebas ~]# systemctl enable dnf-automatic.timer
[root@pruebas ~]# systemctl start dnf-automatic.timer
En la practica, es necesario primeramente escoger el timer unit y luego

entrar a configurar el archivo automatic.conf para que DNF Automatic
ejecute las actualizaciones de forma automática.
Para efectos de laboratorio se escoge habilitar la unidad de descargar e

instalar las actualizaciones disponibles (en el archivo automatic.conf se
habilita para descargar solo las relacionadas con seguridad), como se
[root@pruebas dnf]# systemctl enable dnf-automatic-

install.timer
Created symlink /etc/systemd/system/timers.target.wants/dnf-automatic-install.timer →
/usr/lib/systemd/system/dnf-automatic-install.timer.
[root@pruebas dnf]# systemctl start dnf-automatic-install.timer
Usted podría verificar si su unidad de timer se encuentra activa, como se

[root@pruebas dnf]# systemctl status dnf-automatic-

install.timer
● dnf-automatic-install.timer - dnf-automatic-install timer
Loaded: loaded (/usr/lib/systemd/system/dnf-automatic-install.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Tue 2021-02-23 13:12:05 -05; 5min ago
Trigger: Wed 2021-02-24 06:34:06 -05; 17h left
Feb 23 13:12:05 pruebas.aptivalabs systemd[1]: Started dnf-automatic-install timer.
Una vez escogido el timer unit, entramos a modificar el archivo de

configuración. Como con cualquier otro archivo de configuración, la buena
practica es hacer una copia de este y después si empezar a configurar, como
[root@pruebas ~]# cd /etc/dnf/

[root@pruebas dnf]# cp automatic.conf automatic.conf.ori
[root@pruebas dnf]# vim automatic.conf
La sección command del archive automatic.conf la he dejado como

sigue:
[commands]
# What kind of upgrade to perform:
# default = all available upgrades
# security = only the security upgrades
upgrade_type = security
random_sleep = 0
# To just receive updates use dnf-automatic-notifyonly.timer
# Whether updates should be downloaded when they are available, by

# dnf-automatic.timer. notifyonly.timer, download.timer and
# install.timer override this setting.
download_updates = yes
# Whether updates should be applied when they are available, by

# dnf-automatic.timer. notifyonly.timer, download.timer and
# install.timer override this setting.
apply_updates = yes
La sección “[emitters]” la he dejado con el valor por default, que en este
caso es “emit_via = stdio”. Dejarla asi le indica a DNF Automatic que la
notificación de la actividad saldrá por la salida estándar (por default, la
pantalla).
DESINSTALAR PAQUETES DE SOFTWARE
Usted puede eliminar software de su sistema Linux como se detalla a
continuación:
[root@pruebas ~]# yum remove nano

================================================================
=========
Size
================================================================
=========
Removing:
nano x86_64 2.9.8-1.el8 @rhel-8-for-x86_64-baseos-rpms
2.2 M
Transaction Summary
================================================================
=========
Remove 1 Package
Freed space: 2.2 M

Is this ok [y/N]:
Así como eliminó el paquete “nano”, puede eliminar otro paquete en la

misma instrucción, solo es necesario relacionar los paquetes separados por
un espacio. De igual forma también es posible eliminar grupos de paquetes
[root@pruebas ~]# yum group remove "Container

Management"
================================================================
==================================
Size
================================================================
==================================
Removing:
buildah x86_64 1.16.7-4.module+el8.3.1+9857+68fb1526 @rhel-8-for-
x86_64-appstream-rpms 29 M
Removing Groups:
Transaction Summary
================================================================
==================================
Remove 1 Package
Freed space: 29 M
Is this ok [y/N]:
HISTORIAL EN LA GESTIÓN DE
PAQUETES
La gestión del historial es útil cuando usted requiere conocer que
transacciones fueron ejecutadas con anterioridad, cuando usted quiere
revertir esas transacciones o cuando usted quiere repetir ciertas
transacciones, es muy útil según el escenario que esté manejando.
Para ver el historial de transacciones realizadas en YUM detalle el

siguiente comando:
[root@pruebas ~]# yum history

ID | Command line | Date and time | Action(s) | Altered
------------------------------------------------------------------------------------------------------
16 | install dnf-automatic | 2021-02-23 12:29 | Install | 1
15 | -y install-na nano.x86_64 | 2021-02-23 11:18 | Install | 1
14 | remove nano | 2021-02-23 10:56 | Removed | 1
13 | install nano | 2021-02-23 10:53 | Install | 1
11 | install -y rear genisoimage syslinux | 2021-02-22 16:35 | Install | 5
10 | -y install httpd | 2021-02-21 22:35 | Install | 9
9 | history undo 8 | 2021-02-21 22:32 | Removed | 9
8 | install httpd -y | 2021-02-19 14:36 | Install | 9
7 | install langpacks-es.noarch | 2021-02-18 14:52 | Install | 26
6 | update | 2021-02-18 14:39 | E, I, U | 107
5 | groupinstall Virtualization Client -y --with-optional | 2021-02-03 18:31 | Install | 53
4 | groupinstall Virtualization Hypervisor -y | 2021-02-03 18:30 | Install | 8
3 | update | 2021-02-03 18:21 | I, U | 17
2 | update | 2020-12-17 17:29 | I, U | 77
1 | | 2020-12-17 17:08 | Install | 1381 EE
Para relacionar el historial de transacciones para un determinado

paquete, por favor vea el ejemplo a continuación:
[root@pruebas ~]# yum history list nano

ID | Command line | Date and time | Action(s) | Altered
------------------------------------------------------------------------------------------------------
15 | -y install-na nano.x86_64 | 2021-02-23 11:18 | Install | 1
13 | install nano | 2021-02-23 10:53 | Install | 1
12 | remove nano | 2021-02-23 10:53 | Removed | 1 <
1 | | 2020-12-17 17:08 | Install | 1381 >E
Como usted puede observar, cada transacción cuenta con un

identificador (ID); usted puede conocer al detalle lo que ocurrió con esa
transacción, tal como se muestra en el siguiente ejemplo, donde se requiere
conocer mas sobre la transacción 14:
[root@pruebas ~]# yum history info 14

Transaction ID : 14
Begin time : Tue 23 Feb 2021 10:56:59 AM -05
Begin rpmdb : 1469:91d649301c28f21bcdf9c37aa1d652749409a2ad
End time : Tue 23 Feb 2021 10:56:59 AM -05 (0 seconds)
End rpmdb : 1468:88f9fedce2f3c7ef78dc018111150a249443b51f
User : root <root>
Return-Code : Success
Releasever : 8
Command Line : remove nano
Comment :
Packages Altered:
Removed nano-2.9.8-1.el8.x86_64 @@System
YUM le permite reversar las transacciones realizadas con anterioridad,

tal como se detalla a continuación:
[root@pruebas ~]# yum history undo 15

Undoing transaction 15, from Tue 23 Feb 2021 11:18:21 AM -05
Install nano-2.9.8-1.el8.x86_64 @rhel-8-for-x86_64-baseos-rpms
================================================================
==============
Size
================================================================
==============
Removing:
nano x86_64 2.9.8-1.el8 @rhel-8-for-x86_64-baseos-rpms
2.2 M
Transaction Summary
================================================================
==============
Remove 1 Package
Freed space: 2.2 M

Is this ok [y/N]:
YUM también le permite reversar la ultima transacción si colocarle

identicador, asi como se muestra:
[root@pruebas ~]# yum history undo last

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) 8.1
kB/s | 4.5 kB 00:00
Undoing transaction 16, from Tue 23 Feb 2021 12:29:00 PM -05
Install dnf-automatic-4.2.23-4.el8.noarch @rhel-8-for-x86_64-baseos-rpms
================================================================
=========
Size
================================================================
=========
Removing:
dnf-automatic noarch 4.2.23-4.el8 @rhel-8-for-x86_64-baseos-
rpms 47 k
Transaction Summary
================================================================
=========
Remove 1 Package
Freed space: 47 k
Is this ok [y/N]:
YUM además de reversar también le permite repetir las transacciones,

[root@pruebas ~]# yum history redo last

Repeating transaction 16, from Tue 23 Feb 2021 12:29:00 PM -05
Install dnf-automatic-4.2.23-4.el8.noarch @rhel-8-for-x86_64-baseos-rpms
Package dnf-automatic-4.2.23-4.el8.noarch is already installed.
Nothing to do.
Para el caso anterior, YUM intentó instalar al software DNF Automatic

como ultima transacción realizada, pero como el paquete ya estaba instalado
reporta la salida presentada previamente.
RPM – GESTIÓN DE PAQUETES
Como se comentaba en párrafos anteriores, RPM (Red Hat Packet
Manager) es la forma como en sistemas RHEL y derivados se gestionan los
binarios de software y su metadata; usted puede manejar estos archivos de
forma individual usando YUM o podría usar el comando “rpm” para tal fin;
sin embargo el uso de “rpm” puede ser insuficiente para evitar molestias a la
hora de la administración de paquetes, como este ejemplo que se relaciona a
continuación:
1. Descarguemos la aplicación webmin (para hacer una

administración grafica del sistema Linux):
[root@pruebas ~]# wget http://prdownloads.sourceforge.net/webadmin/webmin-1.970-
1.noarch.rpm
Resolving netactuate.dl.sourceforge.net (netactuate.dl.sourceforge.net)... 104.225.3.66
Connecting to netactuate.dl.sourceforge.net
(netactuate.dl.sourceforge.net)|104.225.3.66|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 40780168 (39M) [application/octet-stream]
Saving to: 'webmin-1.970-1.noarch.rpm'
webmin-1.970-1.noarch.rpm 100%
[============================================>] 38.89M 3.90MB/s in 10s
2021-02-24 11:01:29 (3.81 MB/s) - 'webmin-1.970-1.noarch.rpm' saved

[40780168/40780168]
2. A continuación usaremos el comando “rpm” y sus parámetros

“ivh” para realizar la instalación:
[root@pruebas ~]# rpm -ivh webmin-1.970-1.noarch.rpm

warning: webmin-1.970-1.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID
11f63c51: NOKEY
error: Failed dependencies:
perl(Encode::Detect) is needed by webmin-1.970-1.noarch
Como puede observar ha generado una molestia relacionada con
una dependencia, esta debería estar instalada previamente para poder
ser instalada por RPM.
3. Si usted tratara de realizar esta instalación con YUM mire lo

que pasaría:
[root@pruebas ~]# yum install webmin-1.970-1.noarch.rpm

================================================================
==================================
================================================================
==================================
Installing:
webmin noarch 1.970-1 @commandline 39
M
perl-Encode-Detect x86_64 1.01-28.el8 rhel-8-for-x86_64-appstream-
rpms 90 k
Transaction Summary
================================================================
==================================
Install 2 Packages
Total size: 39 M
Is this ok [y/N]:
De forma automática YUM detecta la dependencia y la instala, motivo

por el cual he decidido no dedicarle mucho tiempo al manejo del comando
“rpm” pues YUM le soluciona todo el problema de forma integral
(consultas, update, metadata, eliminación, etc), sin embargo, lo invito a que
revise el manual del paquete RPM (man rpm) para que observe todas las
opciones utilizadas por este comando.
Con los siguientes apartes quiero evidenciar que usted puede gestionar
paquetes individuales con YUM, como se muestra a continuación:
[root@pruebas ~]# yum info webmin.noarch
Installed Packages
Name : webmin
Version : 1.970
Release :1
Architecture : noarch
Size : 123 M
Source : webmin-1.970-1.src.rpm
From repo : @commandline
Summary : A web-based administration interface for Unix systems.
License : Freeware
Description : A web-based administration interface for Unix systems. Using Webmin you
can
: configure DNS, Samba, NFS, local/remote filesystems and more using your
: web browser.
:
: After installation, enter the URL http://localhost:10000/ into your
: browser and login as root with your root password.
De la siguiente forma podemos eliminar el paquete instalado (también

haciendo un yum history undo):
[root@pruebas ~]# yum remove webmin

================================================================
==================================
================================================================
==================================
Removing:
webmin noarch 1.970-1 @@commandline
123 M
Removing unused dependencies:
perl-Encode-Detect x86_64 1.01-28.el8 @rhel-8-for-x86_64-appstream-
rpms 216 k
Transaction Summary
================================================================
==================================
Remove 2 Packages
Freed space: 123 M

Is this ok [y/N]:
Algunos ejemplos de comandos “rpm” son los siguientes, iniciando por
el siguiente, que intenta visualizar la documentación del archivo “webmin-
1.973-1.noarch.rpm”:
[root@pruebas ~]# rpm -qd webmin-1.973-1.noarch.rpm

11f63c51: NOKEY
La siguiente instrucción nos permite detallar los archivos de

configuración del archivo “webmin-1.973-1.noarch.rpm”:
[root@pruebas ~]# rpm -qc webmin-1.973-1.noarch.rpm

11f63c51: NOKEY
/etc/pam.d/webmin
/etc/sysconfig/daemons/webmin
La siguiente instrucción nos permite conocer información del archivo

“webmin-1.973-1.noarch.rpm”:
[root@pruebas ~]# rpm -qi webmin-1.973-1.noarch.rpm

11f63c51: NOKEY
Name : webmin
Version : 1.973
Release : 1
Architecture: noarch
Install Date: (not installed)
Group : System/Tools
Size : 129001737
License : Freeware
Signature : DSA/SHA1, Sun Mar 7 17:24:10 2021, Key ID d97a3ae911f63c51
Source RPM : webmin-1.973-1.src.rpm
Build Date : Sun Mar 7 17:23:27 2021
Build Host : fudu2
Relocations : (not relocatable)
Vendor : Jamie Cameron
Summary : A web-based administration interface for Unix systems.
Description :
A web-based administration interface for Unix systems. Using Webmin you can
configure DNS, Samba, NFS, local/remote filesystems and more using your
web browser.
After installation, enter the URL http://localhost:10000/ into your

browser and login as root with your root password.
Si usted requiere conocer las dependencias necesarias para instalar el
aplicativo “webmin-1.973-1.noarch.rpm” puede digitar una instrucción
como la siguiente:
[root@pruebas ~]# rpm -q -R webmin-1.973-1.noarch.rpm

11f63c51: NOKEY
/bin/sh
/usr/bin/perl
/bin/rm
perl(Net::SSLeay)
perl(Time::Local)
perl(Encode::Detect)
perl(Data::Dumper)
openssl
unzip
tar
/bin/sh
/bin/sh
/bin/sh
/bin/sh
/bin/sh
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsXz) <= 5.2-1
Para instalar la aplicación “webmin-1.973-1.noarch.rpm” haga lo

siguiente:
[root@pruebas ~]# rpm -ivh webmin-1.973-1.noarch.rpm --test

11f63c51: NOKEY
Verifying... ################################# [100%]
Preparing... ################################# [100%]
Para desinstalar haga lo siguiente:
[root@pruebas ~]# rpm -e webmin

Running uninstall scripts ..
CONFIGURACIÓN DE YUM/DNF
De la siguiente forma podemos ver la configuración general de YUM
que tiene alcance global a toda el sistema:
[root@pruebas ~]# yum config-manager --dump

======================================= main
======================================================
[main]
assumeno = 0
assumeyes = 0
autocheck_running_kernel = 1
bandwidth = 0
best = 1
bugtracker_url = https://bugzilla.redhat.com/enter_bug.cgi?
product=Fedora&component=dnf
cachedir = /var/cache/dnf
cacheonly = 0
check_config_file_age = 1
clean_requirements_on_remove = 1
color = auto
proxy_auth_method = any
recent = 7
repo_gpgcheck = 0
reposdir = /etc/yum.repos.d, /etc/yum/repos.d, /etc/distro.repos.d
reset_nice = 1
retries = 10
rpmverbosity = info
showdupesfromrepos = 0
skip_broken = 0
skip_if_unavailable = 0
sslcacert =
sslclientcert =
sslclientkey =
sslverify = 1
strict = 1
system_cachedir = /var/cache/dnf
throttle = 0
timeout = 30
transformdb = 1
tsflags =
upgrade_group_objects_upgrade = 1
user_agent = libdnf (Red Hat Enterprise Linux 8.3; generic; Linux.x86_64)
username =
varsdir = /etc/yum/vars, /etc/dnf/vars
zchunk = 1
Usted podría ver la información de configuración de estas variables

globales de la siguiente forma:
[root@pruebas ~]# man 5 yum.conf
YUM proporciona plugins que amplían y mejoran sus capacidades.

Algunos plugins se instalan de forma predeterminada. Los archivos de
configuración del plugin siempre contienen una sección [mail] donde la
opción enabled = controla si el plugin está habilitado cuando se ejecuta los
comandos yum. Cada plugin instalado tiene su propio archivo de
configuración en el directorio /etc/dnf/plugins/. Puede habilitar o deshabilitar
las opciones específicas del plugin en estos archivos.
Un listado de la ruta /etc/dnf/plugins nos muestra lo siguiente:
[root@pruebas ~]# cd /etc/dnf/plugins/

[root@pruebas plugins]# ll
total 16
-rw-r--r--. 1 root root 351 Jun 10 2020 copr.conf
drwxr-xr-x. 2 root root 6 Aug 5 2020 copr.d
-rw-r--r--. 1 root root 30 Jun 10 2020 debuginfo-install.conf
-rw-r--r--. 1 root root 17 Feb 3 10:51 product-id.conf
-rw-r--r--. 1 root root 213 Feb 3 10:51 subscription-manager.conf
Revisando la configuración principal de YUM/DNF, podemos ver la

siguiente configuración respecto a YUM y los plugins:
[root@pruebas plugins]# yum config-manager --dump | grep

plu
pluginconfpath = /etc/dnf/plugins
pluginpath = /usr/lib/python3.6/site-packages/dnf-plugins
plugins = 1
Revisando uno de los plugins en el sistema podemos ver su contenido:
[root@pruebas plugins]# more subscription-manager.conf

[main]
enabled=1
# When following option is set to 1, then all repositories defined outside redhat.repo will
be disabled
# every time subscription-manager plugin is triggered by dnf or yum
disable_system_repos=0
Si usted edita el archivo /etc/yum.conf y adiciona la línea “plugins = 0”

acontecerá lo siguiente:
[root@pruebas plugins]# nano /etc/yum.conf

plugins
No such command: config-manager. Please use /usr/bin/yum --help
It could be a YUM plugin command, but loading of plugins is currently disabled.
El resultado anterior obedece a que desactivado los plugins; para

volverlos a activar edite nuevamente el archivo /etc/yum.conf modificando
la línea a “plugins = 1”, teniendo como resultado que ya puede ejecutar la
instrucción “yum config-manager --dump | grep plu”
[root@pruebas plugins]# nano /etc/yum.conf

plu
pluginconfpath = /etc/dnf/plugins
pluginpath = /usr/lib/python3.6/site-packages/dnf-plugins
plugins = 1
ADMINISTRACIÓN DE CAPAS DE
SEGURIDAD
SELINUX COMO CAPA DE SEGURIDAD
SELinux es un módulo de seguridad de Linux que está integrado en el
kernel de Linux. El subsistema SELinux en el kernel está impulsado por una
política de seguridad que es controlada por el administrador y se carga en el
arranque. Todas las operaciones de acceso a nivel del kernel que se
consideren relevantes para la seguridad en el sistema son interceptadas por
SELinux y examinadas en el contexto de la política de seguridad cargada. Si
la política cargada permite la operación, esta continúa, de lo contrario, la
operación se bloquea y el proceso falla, generándose si es el caso la
respectiva alerta de seguridad.
Para su conocimiento, SELinux no es un Firewall, viene cargado con

RHEL, usted no tiene necesidad de instalarlo. Security-Enhanced Linux
(SELinux) es una capa adicional de seguridad que determina cuales procesos
pueden trabajar sobre archivos, directorios y puertos; estos permisos son
definidos en las políticas SELinux. Una política es un conjunto de reglas
que guían al motor de seguridad de SELinux.
MODOS DE OPERACIÓN Y CONFIGURACIÓN
Los dos posibles estados de SELinux son Activo/No Activo (enabled,

disabled); cuando SELinux está activo se ejecuta en los modos de operación
Enforcing y Permissive. En el modo Enforcing, SELinux carga sus políticas
y las hace cumplir a cabalidad, siendo el modo Enforcing el modo mas
seguro para la operación del sistema operativo Linux. En el modo
Permissive (permisivo), SELinux no ejerce control alguno, pero registra las
acciones sospechosas en el archivo /var/log/audit/audit.log
El modo de operación de SELinux que el sistema Linux adopta cuando

se se presenta un booteo se encuentra establecido en el archivo
/etc/selinux/config, como se muestra a continuación:
[root@pruebas ~]# cat /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these three values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
Podemos observar la línea con la declaración SELINUX=enforcing, esta

nos muestra que SELinux iniciará en modo activo, y una vez iniciado el
sistema, con la siguiente expresión podemos ver el modo de operación en
que se está ejecutando:
[root@pruebas ~]# getenforce

Enforcing
Usted podría cambiar el modo de operación de forma temporal con

instrucciones como las que siguen:
[root@pruebas ~]# setenforce 0

Permissive
[root@pruebas ~]# setenforce 1

Enforcing
En el primer grupo de instrucciones se estableció SELinux en el modo

Permissive, seguidamente establecimos SELinux al modo Enforcing, todo
esto para cambios de forma temporal, pues al momento de bootear el sistema
el valor tomado es el que está en /etc/selinux/config.
La revisión del archivo /etc/selinux/config, también nos indica que

existen tres estados de la política SELinux, como se detalla:
# SELINUXTYPE= can take one of these three values:

# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected
processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
El estado escogido es “targeted”, que significa mayor seguridad,

protegiendo todos los servicios del sistema. SELINUXTYPE define la
política SELinux en el arranque del sistema.
MANEJO DE LABELS Y CONTEXTOS EN SELINUX
SELinux protege los datos de los usuarios de los servicios

comprometidos. SELinux determina que procesos pueden acceder a
determinados archivos, directorios y procesos; los archivos, directorios y
procesos cuentan con algo que se llama etiqueta (labels), una especie de
marca que hace que SELinux los pueda identificar cuando lo requiera. Estos
labels son de usuario, de rol y de tipo; estos labels son usadas para crear
reglas que definen que objeto puede comunicarse con otro objeto. Los labels
también son conocidos como “types”.
Si usted ejecuta un "ll -Z" verá los contextos de archivos y directorios, si

ejecuta un "ps -efZ" podrá ver los contextos de los procesos.
[root@pruebas ~]# ll -hZ

total 1016M
-rw-------. 1 root root system_u:object_r:admin_home_t:s0 1.3K Dec 17 17:21
anaconda-ks.cfg
-rw-r--r--. 1 root root unconfined_u:object_r:admin_home_t:s0 977M Mar 2 13:49
archivo
-rw-r--r--. 1 root root system_u:object_r:admin_home_t:s0 1.6K Dec 17 17:23 initial-
setup-ks.cfg
drwxr-x---. 2 root root unconfined_u:object_r:admin_home_t:s0 83 Feb 22 16:46
pruebas
Como lo muestra la salida anterior, cada archivo en el listado maneja

unos contextos; tomando como muestra el archivo llamado “archivo”, vemos
en esta línea los contextos “unconfined_u:object_r:admin_home_t” de
Usuario SELinux, Rol Selinux y Tipo. Normalmente este contexto de tipo
es el que administramos la mayoría de las veces, a no ser que la gestión sea
sobre los usuarios.
Usted podrá ver al detalle el contexto de tipo como se muestran en los

siguientes ejemplos:
[root@pruebas ~]# ls -lZ /usr/sbin/httpd

-rwxr-xr-x. 1 root root system_u:object_r:httpd_exec_t:s0 579952
Jun 15 2020 /usr/sbin/httpd
[root@pruebas ~]# ls -dZ /etc/httpd/

system_u:object_r:httpd_config_t:s0 /etc/httpd/
[root@pruebas ~]# ls -dZ /var/log/httpd/
system_u:object_r:httpd_log_t:s0 /var/log/httpd/
[root@pruebas ~]# ls -dZ /var/www/html/

system_u:object_r:httpd_sys_content_t:s0 /var/www/html/
Como se puede apreciar, cada archivo y directorio emplea un contexto de

tipo diferente para el funcionamiento de un solo servicio, en este caso el
servico “httpd”. De igual forma es posible visualizar el contexto de tipo
asociado al puerto relacionado con el servicio “http”, como se visualiza a
continuación:
[root@pruebas ~]# netstat -lZ | grep httpd

tcp6 0 0 [::]:http [::]:* LISTEN 2881/httpd
system_u:system_r:httpd_t:s0
unix 2 [ ACC ] STREAM LISTENING 44155 3410/httpd
system_u:system_r:httpd_t:s0 /etc/httpd/run/cgisock.2881
unix 2 [ ACC ] STREAM LISTENING 29094 1374/php-fpm: maste
system_u:system_r:httpd_t:s0 /run/php-fpm/www.sock
La forma para visualizar el contexto de tipo relacionado a los procesos

para este ejemplo del servicio “http” es la siguiente:
[root@pruebas ~]# ps axZ | grep http

system_u:system_r:httpd_t:s0 1374 ? Ss 0:00 php-fpm: master process
(/etc/php-fpm.conf)
system_u:system_r:httpd_t:s0 1409 ? S 0:00 php-fpm: pool www
system_u:system_r:httpd_t:s0 2881 ? Ss 0:00 /usr/sbin/httpd -
DFOREGROUND
system_u:system_r:httpd_t:s0 3410 ? S 0:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0 3411 ? Sl 0:00 /usr/sbin/httpd -DFOREGROUND
A manera de ejemplo, para implementar un servidor de archivos como

corresponde, debemos saber dos cosas: que los directorios que vamos a
compartir deben tener un contexto determinado y que se le debe decir a
SELinux que permita ciertas configuraciones a nivel de activación de
variables booleanas.
Respecto a los directorios que se quieren compartir, el directorio tiene
que estar marcado con el contexto “samba_share_t”, tal como se muestra:
# chcon -t samba_share_t /datos/tesoreria
Este cambio realizado sobre el directorio “/datos/tesoreria” es temporal,

si reinicia el sistema operativo, el directorio volverá con el contexto
predeterminado; para hacerlo como política y que sea persistente es
necesario realizar las siguientes operaciones:
# semanage fcontext -a -t samba_share_t '/datos/tesoreria(/.*)?'
# restorecon -vFR /datos/tesoreria
El comando crea una política permanente de contexto para esa carpeta, el

segundo aplica la política de forma inmediata para continuar configurando el
servidor de archivos. Usted podrá digitar el comando “semanage fcontex -l”
para listar las políticas establecidas para archivos y directorios. Usted
encontrará incluso políticas para aplicaciones que aun no han sido instaladas
en su sistema, como esta que encontré:
[root@pruebas ~]# semanage fcontext -l

SELinux fcontext type Context
/usr/share/wordpress-mu/wp-config\.php regular file
system_u:object_r:httpd_sys_script_exec_t:s0
Lo ideal sería que cada aplicación que estuviese en un sistema Linux

manejara contextos para el control de puertos, directorios y procesos, así
como booleanos, tema que trataremos a a continuación. He visto algunos
como algunas aplicaciones no pueden funcionar con SELinux, sus manuales
solicitan apagar SELinux antes de iniciar con la instalación y configuración.
En los tiempos cuando trabaja con Asterisk como SIP Server, era necesario
hacer esto, desconozco si a la fecha esto continua así.
MANEJO DE VARIABLES BOOLEANAS
Lo siguiente tiene que ver con las variables booleanas; siguiendo con el
ejemplo del servidor de archivos tendríamos que activar tres variables
booleanas para que el servidor de archivos funcione de manera apropiada;
estas variables booleanas están prendidas o apagadas (on/off). Para cambiar
el valor de una variable de forma permanente se hace lo siguiente:
# setsebool -P samba_export_all_rw on
# setsebool -P samba_export_all_ro
# setsebool -P samba_enable_home_dirs
En el ejemplo anterior se cambió el valor de tres variables necesarias

para implementar nuestro servidor de archivos. Usted podría listar todas las
variables booleanas del sistema de la siguiente forma:
[root@pruebas ~]# getsebool -a

abrt_anon_write --> off
abrt_handle_event --> off
abrt_upload_watch_anon_write --> on
antivirus_can_scan_system --> off
antivirus_use_jit --> off
O relacionar una información mas completa de las variables como se

[root@pruebas ~]# semanage boolean -l

SELinux boolean State Default Description
abrt_anon_write (off , off) Allow abrt to anon write

abrt_handle_event (off , off) Allow abrt to handle event
abrt_upload_watch_anon_write (on , on) Allow abrt to upload watch anon write
antivirus_can_scan_system (off , off) Allow antivirus to can scan system
antivirus_use_jit (off , off) Allow antivirus to use jit
GESTIÓN DE USUARIOS CONFINADOS
En RHEL 8 y derivados, todos los usuarios están mapeados

(relacionados) a una cuenta de usuario SELinux. Esas cuentas de usuario
SELinux se pueden visualizar de la siguiente forma:

__default__ unconfined_u s0-s0:c0.c1023 *

root unconfined_u s0-s0:c0.c1023 *
Si usted quiere saber con que usuario de SELinux está mapeado el

usuario “root” o un usuario estándar observe con detenimiento:
[root@pruebas ~]# id --context

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[root@pruebas ~]# su – fmestre
[fmestre@pruebas ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Los usuarios estándar de Linux quedan mapeados al usuario

“unconfined_u” cuando no se define un usuario SELinux para el usuario
estándar en el momento de la creación. Como para que lo vaya viendo un
poco mas claro, “unconfined_u” significa “usuario sin restricciones”, sin
control, por lo tanto, usted puede ver necesario en algún momento cambiar el
mapeo de estos nuevos usuarios como se muestra a continuación:
[root@pruebas ~]# semanage login -m -S targeted -s "user_u" -r s0

__default__
En la instrucción anterior vemos por ejemplo que los usuarios estándares

que se creen sin usuario SELinux (estarán todos relacionados a
“__default__”) quedarán mapeados con el usuario SELinux “user_u”, esto
podría generar algunas limitaciones por ejemplo con la delegación de
funciones (SUDO) donde usted se preguntará el porque un usuario no puede
realizar una tarea delegada si está correctamente definida la configuración en
/etc/sudoers. Es aquí entonces donde SELinux empieza a controlar
situaciones con los usuarios estándares del sistema.
Si se lista nuevamente los usuarios SELinux podremos observar que el

mapeo ha sido cambiado a “user_u”, como se muestra a continuación:

De la siguiente forma usted puede cambiar el mapeo de un usuario

individual a un usuario de SELinux, agregando un nuevo registro, como se
[root@pruebas ~]# semanage login -a -s user_u fmestre
Para verificar que tal mapeo ha quedado registrado observe la siguiente

instrucción:
[root@pruebas ~]# semanage login --list

fmestre user_u s0 *
Usted podrá listar los usuarios predefinidos por SELinux de la siguiente:
[root@pruebas ~]# seinfo -u

Users: 8
guest_u
root
staff_u
sysadm_u
system_u
unconfined_u
user_u
xguest_u
Si la aplicación “seinfo” no está instalada, RHEL le da oportunidad de
instalar una serie de herramientas para la interacción con SELinux que están
integradas en el paquete “setools-console”, el cual podrá instalar con la
herramienta YUM/DNF. Al momento de agregar un usuario al sistema usted
podría definir con que usuario SELinux se puede mapear, como se muestra a
continuación:
[root@pruebas ~]# useradd --selinux-user user_u curri

curri user_u s0 *
fmestre user_u s0 *
Para visualizar que efectivamente el usuario “curri” se registra en el

sistema mapeado al usuario “user_u” de SELinux usted puede registrarse por
consola física y evidenciar, tal como muestra a continuación:
TROUBLESHOOTING CON SELINUX
Una de las funciones principales en la seguridad es monitorear lo que

está pasando en el sistema Linux. Para ello RHEL y sus derivados le
proponen diferentes herramientas de monitoreo las cuales usted puede
instalar desde el paquete “setroubleshoot-server”, en este caso el paquete se
instaló desde el momento de la instalación inicial del sistema, como se
observa a continuación:
[root@pruebas ~]# yum install setroubleshoot-server -y
Last metadata expiration check: 0:16:25 ago on Wed 03 Mar 2021 11:43:41 AM -05.
Package setroubleshoot-server-3.3.24-1.el8.x86_64 is already installed.
Nothing to do.
Complete!
En el siguiente ejemplo vamos a realizar una acción que va a alertar a

SELinux por que se va a realizar un intento de visualización a un recurso, en
este caso el servidor HTTP. Iniciamos creando un archivo vacio llamado
“pagina” en /root:
[root@pruebas ~]# touch pagina
[root@pruebas ~]# pwd

/root
Después de haber sido creado observemos el contexto del archivo:
[root@pruebas ~]# ll -Z
total 1039836
-rw-r--r--. 1 root root unconfined_u:object_r:admin_home_t:s0
0 Mar 3 12:05 pagina
Cuando crea un archivo, éste toma el contexto del directorio donde se

creó, si usted lo mueve a otra ruta, el archivo se lleva el contexto del
directorio donde fue creado. Es el caso que sigue a continuación:
[root@pruebas ~]# mv pagina /var/www/html/
[root@pruebas ~]# cd /var/www/html/

El archivo ha sido movido a la ruta de publicación del servidor HTTP
con un contexto (admin_home_t) que no pertenece a /var/www/html (usa el
contexto httpd_sys_content_t), como se muestra a continuación:
[root@pruebas html]# ll -Z
total 0
-rw-r--r--. 1 root root unconfined_u:object_r:admin_home_t:s0 0
Mar 3 12:05 pagina
[root@pruebas html]# curl http://localhost/pagina

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access this resource.</p>
</body></html>
Al esperar ver el contenido (comando “curl”) de la pagina web en el

archivo que se llama “pagina” y que está en la ruta de publicación del
servidor web vemos un error, éste error ha alertado a SELinux y en el
archivo /var/log/audit.log nos ha dejado un mensaje como este:
[root@pruebas html]# tail /var/log/audit/audit.log

type=PROCTITLE msg=audit(1614791178.777:164):
proctitle=2F7573722F7362696E2F6874747064002D44464F52454752
4F554E44
type=AVC msg=audit(1614791178.777:165): avc: denied { getattr
} for pid=6649 comm="httpd" path="/var/www/html/pagina"
dev="dm-0" ino=67974962 scontext=system_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
permissive=0
El archivo /var/log/message también tiene una alerta generada que la

podemos ver como sigue a continuación:
[root@pruebas html]# tail -f /var/log/messages

Mar 3 12:06:38 pruebas setroubleshoot[6912]: SELinux is
preventing httpd from getattr access on the file
/var/www/html/pagina.#012#012***** Plugin restorecon (99.5
confidence) suggests ************************#012#012If you
want to fix the label. #012/var/www/html/pagina default label should be
httpd_sys_content_t.#012Then you can run restorecon. The access
attempt may have been stopped due to insufficient permissions to
access a parent directory in which case try to change the following
command accordingly.#012Do#012# /sbin/restorecon -v
/var/www/html/pagina#012#012***** Plugin catchall (1.49
confidence) suggests **************************#012#012If you
believe that httpd should be allowed getattr access on the pagina file by
default.#012Then you should report this as a bug.#012You can generate
a local policy module to allow this access.#012Do#012allow this access
for now by executing:#012# ausearch -c 'httpd' --raw | audit2allow -M
my-httpd#012# semodule -X 300 -i my-httpd.pp#012
Mar 3 12:06:38 pruebas setroubleshoot[6912]: SELinux is

preventing httpd from getattr access on the file /var/www/html/pagina.
For complete SELinux messages run: sealert -l cde9337a-4e2e-4f47-
81f6-284d7517ac81
Se nos presenta entonces una de las líneas del archivo que nos indica que
podemos ejecutar el comando “sealert” para obtener información relacionada
con el intento de violación de la seguridad al servicio HTTP, tal como se
[root@pruebas html]# sealert -l cde9337a-4e2e-4f47-81f6-

284d7517ac81
SELinux is preventing httpd from getattr access on the file /var/www/html/pagina.
***** Plugin restorecon (99.5 confidence) suggests ************************
If you want to fix the label.

/var/www/html/pagina default label should be httpd_sys_content_t.
Then you can run restorecon. The access attempt may have been stopped due to
insufficient permissions to access a parent directory in which case try to change the following
command accordingly.
Do
# /sbin/restorecon -v /var/www/html/pagina
***** Plugin catchall (1.49 confidence) suggests **************************
If you believe that httpd should be allowed getattr access on the pagina file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'httpd' --raw | audit2allow -M my-httpd
# semodule -X 300 -i my-httpd.pp
Additional Information:
Source Context system_u:system_r:httpd_t:s0
Target Context unconfined_u:object_r:admin_home_t:s0
Target Objects /var/www/html/pagina [ file ]
Source httpd
Source Path httpd
Port <Unknown>
Host pruebas.aptivalabs
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-3.14.3-54.el8_3.2.noarch
Local Policy RPM selinux-policy-targeted-3.14.3-54.el8_3.2.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name pruebas.aptivalabs
Platform Linux pruebas.aptivalabs
4.18.0-240.15.1.el8_3.x86_64 #1 SMP Wed Feb 3
03:12:15 EST 2021 x86_64 x86_64
Alert Count 2
First Seen 2021-03-03 12:06:18 -05
Last Seen 2021-03-03 12:06:18 -05
Local ID cde9337a-4e2e-4f47-81f6-284d7517ac81
Raw Audit Messages

type=AVC msg=audit(1614791178.777:165): avc: denied { getattr } for pid=6649
comm="httpd" path="/var/www/html/pagina" dev="dm-0" ino=67974962
scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0
tclass=file permissive=0
Hash: httpd,httpd_t,admin_home_t,file,getattr
La salida de este comando nos muestra incluso una opción de

remediación para este caso, que consiste en la restauración del contexto de
tipo de este archivo, como se detalla:
[root@pruebas html]# /sbin/restorecon -v

/var/www/html/pagina
Relabeled /var/www/html/pagina from
unconfined_u:object_r:admin_home_t:s0 to
unconfined_u:object_r:httpd_sys_content_t:s0
[root@pruebas html]# curl http://localhost/pagina
[root@pruebas html]#
FILTRADO DE PAQUETES CON
FIREWALLD
Garantizar la seguridad informática es una tarea esencial, en particular en
las empresas que procesan datos sensibles y manejan transacciones
comerciales. Desde la versión 7, Red Hat ha incorporado Firewalld como
aquel servicio que se comunica con el modulo del kernel (Netfilter) que hace
las funciones de filtrado de paquetes.
Un firewall es un sistema de seguridad de red que monitorea y controla

el tráfico entrante y saliente según las reglas de seguridad configuradas. Un
firewall normalmente establece una barrera entre una zona segura de red
interna y otra red externa. El servicio firewalld, que proporciona un firewall
en Red Hat Enterprise Linux, se habilita automáticamente durante la
instalación.
Para conocer el estatus del servicio de Firewall siga la siguiente

instrucción:
[root@pruebas ~]# systemctl status firewalld

● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-02-19 16:35:10 -03; 24min ago
Docs: man:firewalld(1)
Main PID: 903 (firewalld)
Memory: 31.5M
CGroup: /system.slice/firewalld.service
└─903 /usr/libexec/platform-python -s /usr/sbin/firewalld --nofork --nopid
Feb 19 16:35:07 pruebas.aptivalabs systemd[1]: Starting firewalld - dynamic firewall

daemon...
Feb 19 16:35:10 pruebas.aptivalabs systemd[1]: Started firewalld - dynamic firewall
daemon.
Feb 19 16:35:11 pruebas.aptivalabs firewalld[903]: WARNING: AllowZoneDrifting is
enabled. This is considered an insecure con>
lines 1-13/13 (END)
Para saber si el servicio se activa en el momento de arranque del sistema

operativo siga la siguiente instrucción:
[root@pruebas ~]# systemctl is-enabled firewalld
enabled
Si lo que desea es deshabilitar el Firewall, usted podría usar la siguiente

instrucción:
[root@pruebas ~]# systemctl disable firewalld

Removed /etc/systemd/system/multi-
user.target.wants/firewalld.service.
Removed /etc/systemd/system/dbus-
org.fedoraproject.FirewallD1.service.
Si usted no tiene el Firewall activo en el momento del arranque del

sistema operativo, lo podría activar de la siguiente forma:
[root@pruebas ~]# systemctl enable firewalld

Created symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service →
/usr/lib/systemd/system/firewalld.service.
Created symlink /etc/systemd/system/multi-user.target.wants/firewalld.service →
/usr/lib/systemd/system/firewalld.service.
Se ha mencionado previamente que es posible deshabilitar la activación

del firewall del sistema sin embargo esta es una medida no recomendada,
pues tener el firewall activo permitirá proteger el sistema operativo, sin
embargo, pueden existir despliegues que necesiten tener el sistema Linux
con sus capas de seguridad desactivadas, en ese caso cerciórese de que
existan otros mecanismos de protección a nivel de networking o de
seguridad perimetral.
Así las cosas, Netfilter permite que los módulos del kernel inspeccionen
cada entrada, salida, o paquete reenviado y actuar sobre dicho paquete:
permitiéndolo o bloqueándolo, además, el firewall del kernel permite la
inspección de paquetes entrantes, salientes y paquetes que atraviesan de una
interfaz de red a otra si el servidor RHEL proporciona funcionalidad de
enrutamiento. En el pasado, “iptables” fue la solución predeterminada para
comunicarse con netfilter en el proceso de filtración de paquetes, sin
embargo, el servicio “iptables” no se ofrece en Red Hat Enterprise Linux 8,
se ha reemplazado con nftables, una versión con opciones más avanzadas
que las que ofrece iptables.
FIREWALLD, NFTABLES O IPTABLES
A continuación, se ofrece una breve descripción general en la que se

debe utilizar una de las siguientes utilidades:
Firewalld: use firewalld para casos de uso de firewall simples.

La utilidad es fácil de usar y cubre los casos de uso típicos.
nftables: use nftables para configurar firewalls complejos y
críticos, como para toda una red.
iptables: la utilidad iptables en Red Hat Enterprise Linux 8 usa
la API del kernel nf_tables en lugar del back-end heredado. La
API nf_tables proporciona compatibilidad con versiones anteriores
para que Los scripts que usan comandos iptables aún funcionan en
Red Hat Enterprise Linux 8. Para un nuevo firewall scripts, Red
Hat recomienda utilizar nftables.
A manera de recomendación y para evitar que los diferentes servicios de

Firewall se combinen entre sí, ejecute solo uno de ellos y deshabilite los
demás servicios.
CONCEPTUALIZANDO A FIREWALLD
Antes de escribir algún tipo de instrucción o enviar algún comando

relacionado con FirewallD, es importante contextualizarnos acerca de su
modo de operación. Para iniciar miremos como es posible interactuar con
esta herramienta. La imagen a continuación nos muestra las diferentes
formas como es posible interactuar con FirewallD:
Acá podemos ver que es posible usar FirewallD desde la consola de
usuario, si esta ha sido instalada, desde la aplicación “firewall-cmd”;
también se nota que las aplicaciones podrían interactuar con FirewallD en
tiempo de ejecución asi como le herramienta Cockpit, que también cuenta
con unas funcionalidades para integrarse con FirewallD.
FirewallD filtra los paquetes en la maquina según su origen de

procedencia, una vez verificado su origen el paquete llega a una zona donde
es tratado en función de las reglas definidas para cada zona; como se aprecia
en la imagen, existe una zona default para recibir los paquetes, en este caso
esa zona default es la zona pública. La siguiente ilustración nos permitirá
conocer las zonas por default (se pueden agregar más) que se establecen en
FirewallD:
Una conexión en FirewalD solo puede ser parte de una zona, pero una
zona se puede utilizar para tratar con muchas conexiones de red.
Las zonas predefinidas en FirewallD están representadas en archivos

XML, como se visualiza a continuación:
[root@pruebas ~]# cd /usr/lib/firewalld/zones/
[root@pruebas zones]# ll
total 44
-rw-r--r--. 1 root root 299 Aug 7 2020 block.xml
-rw-r--r--. 1 root root 293 Aug 7 2020 dmz.xml
-rw-r--r--. 1 root root 291 Aug 7 2020 drop.xml
-rw-r--r--. 1 root root 304 Aug 7 2020 external.xml
-rw-r--r--. 1 root root 397 Aug 7 2020 home.xml
-rw-r--r--. 1 root root 412 Aug 7 2020 internal.xml
-rw-r--r--. 1 root root 809 Nov 26 2019 libvirt.xml
-rw-r--r--. 1 root root 729 Jan 20 03:56 nm-shared.xml
-rw-r--r--. 1 root root 343 Aug 7 2020 public.xml
-rw-r--r--. 1 root root 162 Aug 7 2020 trusted.xml
-rw-r--r--. 1 root root 339 Aug 7 2020 work.xml
[root@pruebas zones]# cat public.xml

<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not
harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<service name="dhcpv6-client"/>
<service name="cockpit"/>
</zone>
Los siguientes servicios están pre-configurados para filtrarse en las zonas

que se muestran en la gráfica que se presenta:
Significa esto por ejemplo que si usted declara como zona activa la zona
“block”, no podrá recibir peticiones al servicio SSH, servicio que si acepta
peticiones en la gran mayoría de zonas. De la siguiente forma usted podría
saber cual es la zona activa que FirewallD está usando por default:
[root@pruebas ~]# firewall-cmd --get-active-zones

public
interfaces: ens18
Podría listar el filtrado de paquetes que se está dando sobre la zona

activa:
[root@pruebas ~]# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: ens18
sources:
services: cockpit dhcpv6-client ssh
ports: 22220/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Para destacar, se observa que la zona publica está filtrando los paquetes
que entran por la interfaz ens18, filtra los paquetes asociados con los
servicios cockpit, dhcpv6-client, ssh; filtra los paquetes al puerto 22220 en
protocolo TCP y no tiene otras reglas de filtrado adicionales. Usted podría
visualizar información individual para la zona activa de la siguiente forma:
[root@pruebas ~]# firewall-cmd --list-services

cockpit dhcpv6-client ssh
[root@pruebas ~]# firewall-cmd --list-ports

22220/tcp
[root@pruebas ~]# firewall-cmd --list-interfaces

ens18
FirewallD maneja servicios predefinidos, esto le permite a usted incluso

olvidarse (no es aconsejable) de cosas como los números de puertos de
escucha y tipo de protocolo al momento de definir las reglas de Firewall.
Usted podrá ubicar estos servicios y los archivos relacionado con la
información individual de cada uno de ellos como se detalla:
[root@pruebas firewalld]# cd /usr/lib/firewalld/services

[root@pruebas services]# pwd
/usr/lib/firewalld/services
[root@pruebas services]# ll
total 676
-rw-r--r--. 1 root root 737 Aug 7 2020 RH-Satellite-6.xml
-rw-r--r--. 1 root root 399 Aug 7 2020 amanda-client.xml
-rw-r--r--. 1 root root 427 Aug 7 2020 amanda-k5-client.xml
En ese mismo sentido, visualizaremos uno de los archivos de servicio

para ver su contenido:
[root@pruebas services]# cat postgresql.xml

<service>
<short>PostgreSQL</short>
<description>PostgreSQL Database Server</description>
<port protocol="tcp" port="5432"/>
</service>
Se observa que el servicio de motor de base de datos PostgreSQL usa el

protocolo TCP y escucha peticiones en el puerto 5432. En este caso, si en
algún momento usted tendría la necesidad de instalar este servicio de base de
datos solo tendría que ejecutar una regla como la siguiente:

service=postgresql
success
[root@pruebas ~]# firewall-cmd --reload

success
[root@pruebas ~]# firewall-cmd --info-zone=public

public (active)
services: cockpit dhcpv6-client postgresql ssh
En las anteriores instrucciones se adicionó el servicio PostgreSQL para

que FirewallD filtrara sus paquetes desde la zona publica; en versiones
anteriores de RHEL 7 esto se tenía que realizar con “iptables” para redes
IPv4 e IPv6, FirewallD llega para solucionarle la vida a muchos
Administradores Linux. Para complementar un poco mas acerca de este
beneficio, para servicios que trabajan en los protocolos de transporte TCP y
UDP, y con diferentes puertos de conexión, como es el caso del servicio
“samba”, FirewallD es de gran ayuda; detalle el archivo de configuración del
servicio “samba”:
[root@pruebas services]# cat samba.xml

<service>
<short>Samba</short>
<description>This option allows you to access and participate in Windows file and printer
sharing networks. You need the samba package installed for this option to be useful.
</description>
<port protocol="udp" port="137"/>
<port protocol="udp" port="138"/>
<helper name="netbios-ns"/>
</service>
Si estuviera usando iptables tendría que adicionar cuatro reglas para el

filtrado, con FirewallD solo debería hacer algo como:
[root@pruebas services]# firewall-cmd --permanent --add-

service=samba
[root@pruebas services]# firewall-cmd --reload

FAMILIARIZANDONOS CON INSTRUCCIONES EN FIREWALLD
Las siguientes instrucciones pasadas a FirewallD se realizan con el único

propósito de generar entendimiento de la herramienta. Para saber cual es la
zona por default se utiliza la siguiente orden:
[root@pruebas ~]# firewall-cmd --get-default-zone

public
Para conocer la zona activa use la siguiente instrucción:
[root@pruebas ~]# firewall-cmd --get-active-zones

public
interfaces: ens18
Para conocer los servicios que FirewallD puede administrar use la

[root@pruebas ~]# firewall-cmd --get-services

RH-Satellite-6 amanda-client amanda-k5-client amqp amqps apcupsd audit bacula bacula-
client bb bgp bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc bittorrent-lsd ceph ceph-mon
cfengine cockpit condor-collector ctdb dhcp dhcpv6 dhcpv6-client distcc dns dns-over-tls
docker-registry docker-swarm dropbox-lansync elasticsearch etcd-client etcd-server finger
freeipa-4 --- salida omitida ---
Para visualizar información adicional del servicio Samba establezca la

siguiente orden:
[root@pruebas ~]# firewall-cmd --info-service=samba

samba
ports: 137/udp 138/udp 139/tcp 445/tcp
Para adicionar el servicio MySQL a la zona “internal” haga lo siguiente:
[root@pruebas ~]# firewall-cmd --permanent --zone=internal --

add-service=mysql
success

success
Cuando una modificación ha sido realizada es necesario que FirewallD
lea de nuevo la configuración. Para visualizar información de la zona
“internal” procesa como se visualiza:
[root@pruebas ~]# firewall-cmd --info-zone=internal

internal
services: cockpit dhcpv6-client mdns mysql samba-client ssh
Para eliminar el servicio MySQL de la zona “internal” por favor detalle

la siguiente instrucción:
[root@pruebas ~]# firewall-cmd --permanent --zone=internal --

remove-service=mysql
success

success
Si existe el requerimiento de agregar el puerto 4040 sobre TCP para

habilitar un servicio que usa tal puerto para comunicarse con sus cliente haga
como sigue:
[root@pruebas ~]# firewall-cmd --add-port=4040/tcp --permanent

success

success
A continuación se muestra como listar los filtros asociados a la zona

activa:

public (active)
target: default
interfaces: ens18
sources:
ports: 22220/tcp 4040/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
De la siguiente forma usted puede cambiar la zona por default:
[root@pruebas ~]# firewall-cmd --set-default-zone=internal

success

success
Usted puede listar los filtros que se realizan en la zona activa:

internal (active)
target: default
interfaces: ens18
sources:
services: cockpit dhcpv6-client mdns samba-client ssh
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

internal
A continuación se presenta el caso de tener como zona default la zona

“block”, donde todo se rechaza, se adiciona el servicio HTTP a la zona
pública y se valida en un cliente HTTP si hay servicio en la IP del servidor
RHEL; es claro que aunque el servicio esté agregado a una de las zonas de
FirewallD, el servicio HTTP no estará disponible por la zona activa, en este
caso la zona block, tal como se muestra en las siguientes instrucciones:

block
[root@pruebas ~]# firewall-cmd --permanent --zone=public --add-

service=http
success

success
[root@pruebas ~]# firewall-cmd --info-zone=public

public
target: default
interfaces:
sources:
services: cockpit dhcpv6-client http postgresql ssh
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Para el caso que se aborda, solo cuando cambie la zona por default a
public o a alguna otra que reciba peticiones al servicio HTTP podrá tener
resultados satisfactorios.
FILTRANDO PAQUETES POR ORIGEN DE TRÁFICO
El siguiente ejercicio solo pretende demostrar como FirewallD filtra el

tráfico de red dependiendo del origen de este. Para este caso en particular
simulamos que se requiere habilitar un servidor web para que solamente
desde la IP 192.168.0.35 se pueda visualizar su contenido. Una posible
solución a este requerimiento es habilitar el filtrado de tráfico por origen
para una zona diferente a la zona por default, en este caso la zona por default
es la zona publica. Vamos entonces a adicionar el “source” y el servicio a la
zona “trusted”, una zona diferente a la zona por default.
Iniciamos consultándole a FirewallD cual es la zona por default, a lo que

nos contesta que es la zona publica; seguidamente le solicitamos que nos
liste que está filtrando en esa zona, como se muestra a continuación:

public

public (active)
target: default
interfaces: ens18
sources:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Verificado el reglado de la zona publica, se adiciona a la zona “trusted”

de forma permanente el filtrado por origen a la IP del requerimiento así
como el servicio a permitir:
[root@pruebas ~]# firewall-cmd --zone=trusted --add-
source=192.168.0.35 --permanent
success
[root@pruebas ~]# firewall-cmd --zone=trusted --add-

service=http --permanent
success

success
Se lista el reglado de la zona “trusted” para evidenciar que

efectivamente tiene el source y el servicio requerido:
[root@pruebas ~]# firewall-cmd --list-all --zone=trusted

trusted (active)
target: ACCEPT
interfaces:
sources: 192.168.0.35
services: http
Se verifica que el servicio “httpd” está en ejecución:

Para verificar este procedimiento se valida desde el propio host

192.168.0.35 y desde un cliente HTTP en un dispositivo móvil conectado
por WiFi a la red de datos. La imagen a continuación nos muestra la
conexión satisfactoria, esta es la IP del requerimiento.
La siguiente imagen nos muestra la conexión desde un dispositivo móvil
conectado a la red de datos vía WiFi. Este dispositivo cuenta con otra IP de
host por lo tanto no puede acceder al servicio HTTP, ya que solamente está
definido en la zona “trusted” para la IP 192.168.0.35.
FIREWALLD EN PÁNICO
Si usted cree que su servidor está bajo algún tipo de ataque informático
FirewallD le permite resguardarlo colocando el firewall en modo pánico el
cual deshabilita todo el trafico de red hacia el servidor. Este procedimiento
debe ejecutarse en la consola física de su servidor para que una vez se
controle el ataque apagar el modo pánico y tener nuevamente conectividad
en la red.
Para indagar si su servidor está en modo pánico usted podrá hacer lo

siguiente:
[root@pruebas ~]# firewall-cmd --query-panic

no
Para habilitar el modo pánico usted puede hacer lo siguiente:
[root@pruebas ~]# firewall-cmd --panic-on
Para deshabilitar el modo pánico usted puede hacer lo siguiente:
[root@pruebas ~]# firewall-cmd --panic-off

REGLAS ENRIQUECIDAS CON FIREWALLD
Las reglas enriquecidas le permiten a un Administrador Linux escribir

reglas personalizadas que no podría generar en la sintaxis básica de escritura,
por ejemplo, denegar conexiones al servicio “http” a una IP en específico,
instrucción que se muestra a continuación:
[root@pruebas ~]# firewall-cmd --permanent --add-rich-

rule='rule family=ipv4 source address=192.168.0.35/32 service
name=http reject'
success

success

public (active)
target: default
interfaces: ens18
sources:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="192.168.0.35/32" service
name="http" reject
La instrucción anterior permitirá a todos los hosts en la 192.168.0.0/24

acceder al contenido publicado por el servidor web, excluyendo al host
192.168.0.35, en este caso para la zona por default. Para eliminar esta
instrucción es necesario realizar lo siguiente:
[root@pruebas ~]# firewall-cmd --permanent --remove-rich-
name=http reject'
Es importante mencionar que se debe nombrar los servicios tal como los
detecta FirewallD. Una cosa es como SystemD nombra al servicio y otra
como lo haga FirewallD; es el caso del servicio http, SystemD lo llama
“httpd” y FirewallD lo nombra “http”; si usted agrega la regla anterior
usando “httpd” la regla de FirewallD no va a funcionar. Cuando en las
reglas enriquecidas se usan los parámetros “source” y “destination” siempre
va a ser necesario agregar el parámetro “family=”.
Usted podrá listar las reglas enriquecidas como se muestra a

continuación:
[root@pruebas ~]# firewall-cmd --list-rich-rules --zone=public

name="http" reject
Un ejemplo que involucra el uso de puertos, rangos y protocolo puede

ser como el que se muestra a continuación:

rule='rule family=ipv4 source address=192.168.0.0/24 port
port=7900-7905 protocol=tcp accept'
success

success

public (active)
target: default
interfaces: ens18
sources:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="192.168.0.35/32" service name="http" reject
rule family="ipv4" source address="192.168.0.0/24" port port="7900-7905"
protocol="tcp" accept
Nuevamente se listan las reglas enriquecidas para la zona:
[root@pruebas ~]# firewall-cmd --list-rich-rules --zone=public

name="http" reject
rule family="ipv4" source address="192.168.0.0/24" port
port="7900-7905" protocol="tcp" accept
Escribir una regla enriquecida puede ser tan personalizada como se

requiera, sin embargo un patrón para su escritura puede seguir las siguientes
reglas:
# firewall-cmd --permanent --add-rich-rule='rule [origen][destino]

[service,port,protocol,icmp-block,masquerade,forward-port][log][audit]
[accept,reject,drop]
La expresión “firewall-cmd --permanent --add-rich-rule='rule” es

obligatoria, lo restante ya es personalizado sin embargo tenga presente que la
regla debe terminar con el símbolo “’” (comilla sencilla) para terminar de
escribir la regla, como se aprecia en el siguiente ejemplo:
[root@pruebas ~]# firewall-cmd --permanent --add-rich-rule='rule

family=ipv4 source address=192.168.0.0/24 port port=7900-7905
protocol=tcp accept'
Por medio de las reglas enriquecidas es posible decirle a FirewallD que

registre en los logs del sistema cada cierto tiempo uno que otro movimiento
de tráfico que pasa a través de él. Siguiendo con el ejemplo anterior
relacionado con la exclusión del host 192.168.0.35 para que no visualice el
contenido del servidor web en ejecución en el host 192.168.0.200, podemos
agregar una regla enriquecida que registre en /var/log/messages cada vez que
exista un intento de este host por visualizar el contenido, tal como se muestra
a continuación:

name=http log level=notice prefix=" ATENTO-AMIGO -" limit
value="3/s" reject'
[root@pruebas ~]# firewall-cmd –reload
[root@pruebas ~]# cat /var/log/messages

Mar 4 09:58:07 pruebas kernel: ATENTO-AMIGO-IN=ens18 OUT=
MAC=42:e5:c0:db:ff:2b:40:6c:8f:03:57:f9:08:00 SRC=192.168.0.35 DST=192.168.0.200
LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=50880 DPT=80
WINDOW=65535 RES=0x00 SYN URGP=0
Usted podría registrar estas notificaciones en el archivo

/var/log/audit/audit.log con una instrucción como esta:
[root@pruebas ~]# firewall-cmd --permanent --add-rich-rule='rule

family=ipv4 source address=192.168.0.35/32 service name=http audit
limit value="3/s" reject'
Lo que generaría una salida como la que se muestra a continuación:
[root@pruebas ~]# tail -f /var/log/audit/audit.log
type=NETFILTER_PKT msg=audit(1614870435.234:147):
mark=0x0 saddr=192.168.0.35 daddr=192.168.0.200 proto=6
AUDITORIA EN SISTEMAS LINUX
La auditoria a los sistemas Linux representa una gran oportunidad para
registrar los eventos relacionados con la seguridad del sistema. Estas
auditorias le permiten a un Administrador Linux monitorear el acceso a los
archivos que decida, a las llamadas del sistema (syscall), grabar comandos
ejecutados por un usuario, así como monitorear temas relacionados con el
firewall del sistema. Una de las herramientas que usaremos para realizar
labores de auditoría será “Audit”. Esta aplicación compara los eventos
registrados en el sistema con reglas que tiene previamente preestablecidas.
Una llamada al sistema (syscall - systemcall) hace referencia a los

método utilizados por una aplicación para comunicarse con el Kernel de
Linux y tener información relacionada con la gestión de archivos, procesos
del sistema y dispositivos.
Audit permite generar reglas y escribirlas en la consola del sistema,

reglas que no son persistentes, pero que pueden serlo, quedando registradas
en /etc/autid/audit.rules. Para instalar “audit” usted puede hacerlo de la
siguiente forma:
[root@pruebas ~]# yum install audit -y

Last metadata expiration check: 0:53:36 ago on Thu 04 Mar 2021 10:29:20 AM -05.
Package audit-3.0-0.17.20191104git1c2f876.el8.x86_64 is already installed.
Nothing to do.
Complete!
Como pudo observar, el paquete “audit-3.0-0.17” ya se encuentra

instalado desde el despliegue del sistema operativo. El archivo de
configuración de este software se encuentra en /etc/audit/audit.conf.
[root@pruebas audit]# pwd

/etc/audit
[root@pruebas audit]# ll
total 12
-rw-r-----. 1 root root 127 Jan 8 2020 audit-stop.rules
-rw-r-----. 1 root root 107 Dec 17 17:13 audit.rules
-rw-r-----. 1 root root 856 Jan 8 2020 auditd.conf
drwxr-x---. 2 root root 49 Dec 17 17:13 plugins.d
drwxr-x---. 2 root root 25 Dec 17 17:11 rules.d
Este archivo define los parámetros de la aplicación, parámetros que

estaremos usando a medida avancemos en la temática.
La instalación de Audit genera en el sistema el servicio “audit”, como se

muestra:
[root@pruebas ~]# systemctl --type service | grep audit

auditd.service loaded active running Security Auditing
Service
[root@pruebas ~]# systemctl status auditd.service

● auditd.service - Security Auditing Service
Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2021-03-04 07:17:53 -05; 4h 10min ago
Mar 04 07:17:53 pruebas.aptivalabs augenrules[1081]: lost 0
Mar 04 07:17:53 pruebas.aptivalabs augenrules[1081]: backlog 4
Mar 04 07:17:53 pruebas.aptivalabs augenrules[1081]: backlog_wait_time 60000
Mar 04 07:17:53 pruebas.aptivalabs systemd[1]: Started Security Auditing Service.
Audit provee una forma para registrar información relevante del

sistema. Basado en reglas preconfiguradas, Audit genera entradas de
registro para registrar la mayor cantidad de información como sea posible
sobre los eventos que están sucediendo en su sistema. Esta información es
crucial en los entornos de misión crítica para identificar infractores de la
política de seguridad y las acciones que realizó en el sistema. La siguiente
lista resume parte de la información que Audit es capaz de registrar en los
archivos de log:
Fecha y hora, tipo y resultado de un evento.

Asociación de un evento con la identidad del usuario que
desencadenó el evento.
Todas las modificaciones a la configuración de Audit e intentos
para acceder a /var/log/audit/audit.log.
Todos los usos de los mecanismos de autenticación, como
SSH, Kerberos y otros.
Cambios en cualquier base de datos confiable, como
/etc/passwd.
Intenta importar o exportar información hacia o desde el
sistema.
Incluir o excluir eventos basados en la identidad del usuario y
otros atributos.
Audit consta de dos partes principales: las aplicaciones y utilidades en el

espacio de usuario, y en el lado del kernel, el procesamiento de llamadas al
sistema (systemcalls). El componente del kernel recibe llamadas al sistema
desde las aplicaciones en el espacio de usuario y los filtra a través de uno de
los siguientes filtros: user, task, fstype o exit.
De forma predeterminada, Audit almacena las entradas de registro en el

archivo /var/log/audit/audit.log; si la rotación está actividad en el archivo de
configuración, los archivos audit.log rotados se almacenan en el mismo
directorio.
REGLAS DE AUDITORIA CON AUDIT
Para el establecimiento de reglas, Audit utiliza el comando “auditctl”,

miremos un ejemplo:
[root@pruebas ~]# auditctl -w /etc/ssh/sshd_config -p warx -k

sshd_config
La anterior instrucción utiliza ciertos parámetros del comando “auditctl”,

los cuales se explican a continuación:
-w indica el archivo o directorio objeto de auditoria

-p indica las acciones que se van a auditar sobre el objeto de
auditoria (w-escritura, r-lectura, x-ejecución y a-cambio de
atributos)
-k indica una palabra clave para el reporte de resultados
Intentaremos ver el contenido de este archivo desde un usuario estándar,

en este caso el usuario “fmestre”; si el servicio Audit se encuentra en
ejecución, en /var/log/audit/audit.log debemos observar el registro de que el
usuario “fmestre” intentó leer el contenido del archivo; veamos:
[root@pruebas ~]# su - fmestre
[fmestre@pruebas ~]$ cat /etc/ssh/sshd_config

cat: /etc/ssh/sshd_config: Permission denied
Este evento de auditoria debería generar cuatro (4) registros en el archivo

de log, como se muestra a continuación:
[root@pruebas ~]# tail -n 4 /var/log/audit/audit.log

type=SYSCALL msg=audit(1614886599.538:116): arch=c000003e
syscall=257 success=no exit=-13 a0=ffffff9c a1=7ffce1e84647 a2=0 a3=0 items=1
ppid=2622 pid=2668 auid=0 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000
sgid=1000 fsgid=1000 tty=pts1 ses=3 comm="cat" exe="/usr/bin/cat"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
key="sshd_config"ARCH=x86_64 SYSCALL=openat AUID="root" UID="fmestre"
GID="fmestre" EUID="fmestre" SUID="fmestre" FSUID="fmestre" EGID="fmestre"
SGID="fmestre" FSGID="fmestre"
type=CWD msg=audit(1614886599.538:116):
cwd="/home/fmestre"
type=PATH msg=audit(1614886599.538:116): item=0

name="/etc/ssh/sshd_config" inode=1993961 dev=fd:00 mode=0100600 ouid=0
ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0
cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="root"
type=PROCTITLE msg=audit(1614886599.538:116):
proctitle=636174002F6574632F7373682F737368645F636F6E666967
El evento anterior consta de cuatro registros, que comparten la misma

marca de tiempo (en formato unixtime) y número de serie. Los registros
siempre inician con la palabra clave “type =”. Cada registro consta de varios
pares de nombre = valor separados por un espacio en blanco o una coma,
como por ejemplo la línea “ type=CWD msg=audit(1614886599.538:116):
cwd="/home/fmestre" ”.
En el sitio web https://www.unixtimestamp.com/ usted podrá convertir

esta marca de tiempo a un formato humanamente leíble, mostrándole un
resultado como el siguiente:
type=SYSCALL → En este ejemplo, el valor SYSCALL especifica que
este registro fue generado por un syscall al kernel.
type=CWD →. Este tipo se utiliza para registrar el directorio de trabajo

desde el cual el proceso que invocó la llamada al sistema especificada en el
se ejecutó el primer registro.
type=PATH → Un evento de auditoría contiene un registro de tipo PATH

para cada ruta que se pasa al syscall como argumento. En este evento de
auditoría, solo una ruta (/etc/ssh/sshd_config) se usó como argumento.
type=PROCTITLE → el valor PROCTITLE especifica que este registro

proporciona el comando que desencadenó este evento de auditoría, este
número está en hexadecimal. Una mirada en este comando podría ampliar
un poco mas el reporte:
[root@pruebas ~]# ausearch -i | grep PROCTITLE

type=PROCTITLE msg=audit(03/04/21 14:36:39.538:116) :
proctitle=cat /etc/ssh/sshd_config
Podemos observar que el comando que generó el evento de seguridad fue

el “cat /etc/ssh/sshd_config”.
Usted podría crear diversas reglas de auditoría sobre los archivos

importantes de su sistema de archivos, así como reglas en función de auditar
las llamadas al sistema por parte de las aplicaciones, como utilice Audit
depende del escenario que quiera contemplar. Algunas reglas de ejemplo
podrían ser las siguientes:
[root@pruebas ~]# auditctl -w /etc/passwd -p wa -k

passwd_changes
[root@pruebas ~]# auditctl -w /etc/selinux/ -p wa -k

selinux_changes
[root@pruebas ~]# auditctl -a always,exit -F arch=b64 -S adjtimex -

S settimeofday -k time_change
La última instrucción le dice a Audit que genere un evento de auditoría
cada vez que una aplicación use las “system call” llamadas “adjtimex” y
“settimeofday” en sistemas que usan arquitecturas de 64Bits. Para listar las
reglas cargadas a Audit usted podría enviar la siguiente instrucción:
[root@pruebas ~]# auditctl -l

-w /etc/passwd -p wa -k passwd_changes
Para eliminar una regla temporal realizada con Autid mire las siguientes
instrucciones:

[root@pruebas ~]# auditctl -W /etc/passwd -p wa -k

passwd_changes

No rules
En la anterior instrucción, el parámetro “-W” fue utilizado para dejar de

observar sobre el archivo /etc/passwd.
REGLAS PERSISTENTES DE AUTORÍA
Si usted requiere que las reglas establecidas para Audit sean persistentes
debe insertarlas dentro del archivo /etc/audit/rules.d/audit.rules, sin ,
ubicación que se muestra como sigue:
[root@pruebas rules.d]# pwd

/etc/audit/rules.d
[root@pruebas rules.d]# ll
total 4
-rw-------. 1 root root 244 Dec 17 17:11 audit.rules
Un vistazo al archivo “audit.rules” nos muestra algunas reglas

persistentes:
[root@pruebas rules.d]# cat audit.rules

## Set failure mode to syslog

-f 1
-w /etc/selinux/ -p wa -k selinux_changes
-w /sbin/insmod -p x -k module_insertion
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k
time_change
REGLAS PRECONFIGURADAS EN AUDIT
En la ruta /usr/share/audit/sample-rules es posible observar archivos

cuyo contenido resulta en reglas preconfiguradas para insertarlas a Autid y
que el software empiece a realizar auditorías en función de ellas, como se
[root@pruebas ~]# cd /usr/share/audit/sample-rules
[root@pruebas sample-rules]# ll
total 156
-rw-r--r--. 1 root root 244 Jan 8 2020 10-base-config.rules
-rw-r--r--. 1 root root 284 Jan 8 2020 10-no-audit.rules
-rw-r--r--. 1 root root 93 Jan 8 2020 11-loginuid.rules
-rw-r--r--. 1 root root 333 Jan 8 2020 12-cont-fail.rules
-rw-r--r--. 1 root root 327 Jan 8 2020 12-ignore-error.rules
Podemos ver el contenido de alguno de estos archivos como sigue:
[root@pruebas sample-rules]# cat 30-stig.rules

## The purpose of these rules is to meet the stig auditing requirements
## These rules depends on having 10-base-config.rules & 99-finalize.rules
## installed.
-a always,exit -F arch=b32 -S adjtimex,settimeofday,stime -F

key=time-change
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=time-
change
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F
key=time-change
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F
key=time-change
Para que Audit reconozca el contenido de estas reglas, solo es necesario

copiar el archivo correspondiente a /etc/audit/rules.d y recargar la
configuración, como se muestra en la siguiente instrucción:
[root@pruebas sample-rules]# cp 30-stig.rules /etc/audit/rules.d

[root@pruebas sample-rules]# augenrules --load
No rules
enabled 1
failure 1
pid 1061
rate_limit 0
backlog_limit 8192
lost 0
backlog 4
backlog_wait_time 60000
[root@pruebas sample-rules]# auditctl -l

-a always,exit -F arch=b32 -S stime,settimeofday,adjtimex -F key=time-change
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=time-change
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
-w /etc/localtime -p wa -k time-change
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity
-a always,exit -F arch=b32 -S sethostname,setdomainname -F key=system-locale
GENERACIÓN DE REPORTES CON AUDIT
Para generar reportes de auditoria, Audit cuenta con la herramienta

“aureport”. “aureport” es una herramienta que produce informes resumidos
de los registros del sistema de auditoría. Se visualizaran diferentes tipos de
reportes para que se haga a una idea de los tipos de reportes que puede
generar:
Reporte en función de la autenticación de los usuarios:
[root@pruebas ~]# aureport -au

Authentication Report
============================================
# date time acct host term exe success event
============================================
159. 03/03/21 11:37:22 fmestre pruebas.aptivalabs pts/0 /usr/bin/su yes 93
160. 03/03/21 11:41:10 curri pruebas.aptivalabs pts/0 /usr/bin/su yes 103
161. 03/03/21 11:42:40 root 192.168.0.35 ssh /usr/sbin/sshd yes 119
162. 03/03/21 11:45:17 curri pruebas.aptivalabs tty1 /usr/bin/login yes 143
163. 03/03/21 14:34:17 root ? ? /usr/libexec/cockpit-session yes 71
--- salida omitida
Reporte de eventos del sistema:

Fri Mar 5 07:57:29 -05 2021
[root@pruebas ~]# systemctl start httpd
[root@pruebas ~]# aureport -e

Event Report
===================================
# date time event type auid success
===================================
--- salida omitida
13857. 03/05/21 07:58:13 137 SERVICE_START -1 yes
13858. 03/05/21 07:58:13 138 SERVICE_START -1 yes
Resumen de uso de archivos ejecutables:
[root@pruebas ~]# aureport -x --summary

Executable Summary Report
=================================
total file
=================================
9540 /usr/lib/systemd/systemd
2359 /usr/sbin/sshd
496 /usr/libexec/platform-python3.6
306 /usr/libexec/gdm-session-worker
173 /usr/sbin/auditctl
166 /usr/lib/systemd/systemd-update-utmp
98 /usr/bin/su
64 /usr/bin/pidof
Informe resumen de Eventos Fallidos:
[root@pruebas ~]# aureport --failed

Failed Summary Report
======================
Range of time in logs: 12/17/20 17:22:49.437 - 03/05/21 08:04:07.724
Selected time for report: 12/17/20 17:22:49 - 03/05/21 08:04:07.724
Number of changes in configuration: 0
Number of changes to accounts, groups, or roles: 2
Number of logins: 0
Number of failed logins: 5
Number of authentications: 0
Number of failed authentications: 0
Number of users: 3
Number of terminals: 8
Number of host names: 3
Number of executables: 17
Number of commands: 12
Number of files: 12
Number of AVC's: 143
Number of MAC events: 0
Number of failed syscalls: 149
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of integrity events: 0
Number of virt events: 0
Number of keys: 2
Number of process IDs: 50
Number of events: 172
Resumen de eventos fallidos por Usuario:
[root@pruebas ~]# aureport -u --failed --summary -i

Failed User Summary Report
===========================
total auid
===========================
83 unset
80 fmestre
9 root
HARDENING DEL SERVICIO SSH
Cuando se instala un servidor RHEL, alguno de sus derivados o
distribuciones como Debian o Ubuntu server, normalmente el único servicio
de red habilitado para administración remota es el servicio SSH, el cual muy
posiblemente vendrá con una configuración estándar como por ejemplo
recibir conexiones en el puerto 22, aceptar el registro directo del usuario
“root”, por mencionar algunas. Es el caso de Red Hat Enterprise Linux y sus
derivados.
SSH (Secure Shell) es un programa para iniciar sesión en una máquina

remota y ejecutar comandos en esa máquina. El protocolo SSH proporciona
comunicaciones cifradas entre dos hosts que no son de confianza a través de
una red insegura. En Linux se ejecuta como un servicio tal como se muestra
a continuación:
[root@pruebas sample-rules]# systemctl status sshd.service

● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-03-05 07:31:35 -05; 1h 56min ago
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 1227 (sshd)
Memory: 7.7M
CGroup: /system.slice/sshd.service
└─1227 /usr/sbin/sshd -D -oCiphers=aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes>
Mar 05 07:31:35 pruebas.aptivalabs systemd[1]: Starting OpenSSH server daemon...

Mar 05 07:31:35 pruebas.aptivalabs sshd[1227]: Server listening on 0.0.0.0 port 22.
Mar 05 07:31:35 pruebas.aptivalabs sshd[1227]: Server listening on :: port 22.
Mar 05 07:31:35 pruebas.aptivalabs systemd[1]: Started OpenSSH server daemon.
Mar 05 07:39:26 pruebas.aptivalabs sshd[3355]: Accepted password for root from 192.168.0.35 port 54908 ssh2
Mar 05 07:39:26 pruebas.aptivalabs sshd[3355]: pam_unix(sshd:session): session opened for user root by (uid=0)
Mar 05 07:53:46 pruebas.aptivalabs sshd[3656]: Accepted password for root from 192.168.0.35 port 55077 ssh2
Mar 05 07:53:46 pruebas.aptivalabs sshd[3656]: pam_unix(sshd:session): session opened for user root by (uid=0)
Y como es un servicio es objeto de todas las operaciones que se

requirean utilizar con él a través de SystemD (enable, disable, start, stop,
reload, restart, etc). Una conexión al servicio podrá realizarse por medio de
diferentes clientes SSH existentes, como la terminal en Mac OSX, la
aplicación Putty para Microsoft Windows, entre muchas otras; funciona en el
modelo cliente/servidor.
El protocolo SSH mitiga las amenazas a la seguridad, como la

interceptación de la comunicación entre dos sistemas y la suplantación de un
host en particular, cuando lo usa para iniciar sesión de shell remoto o copiar
archivos. Esto se debe a que el cliente y el servidor SSH utilizan firmas
digitales para verificar sus identidades. Además, toda la comunicación entre
los sistemas cliente y servidor está cifrada.
OpenSSH es un software que implementa el protocolo SSH; es

compatible con varios sistemas Linux, UNIX y sistemas operativos
similares. Incluye los archivos necesarios tanto para la configuración del
cliente como para el servidor OpenSSH. Tener instalado OpenSSH es
contar con las herramientas para cliente y servidor. En RHEL 8, OpenSSH
es el servidor ssh y cliente ssh que ejecuta la versión dos (2), con mejoras de
seguridad para evitar exploits del servicio.
La suite OpenSSH utiliza dos conjuntos diferentes de archivos de

configuración: los de los programas cliente (es decir, ssh, scp y sftp) y los
del servidor (el servicio sshd). La configuración de SSH se almacena en el
directorio /etc/ssh/. La información de configuración SSH específica de un
usuario se almacena en ~/.ssh/, por ejemplo, /home/fmestre/.ssh/, aparece
como un directorio oculto y se crea en el momento de la generación de las
llaves del usuario.
A continuación se lista el contenido del directorio con los archivos de

configuración de la herramientas OpenSSH:
[root@pruebas ~]# cd /etc/ssh/
[root@pruebas ssh]# pwd

/etc/ssh
[root@pruebas ssh]# ll
total 608
-rw-r--r--. 1 root root 577388 Mar 27 2020 moduli
-rw-r--r--. 1 root root 1770 Mar 27 2020 ssh_config
drwxr-xr-x. 2 root root 28 Dec 17 17:11 ssh_config.d
-rw-r-----. 1 root ssh_keys 480 Dec 17 17:22 ssh_host_ecdsa_key
-rw-r--r--. 1 root root 162 Dec 17 17:22 ssh_host_ecdsa_key.pub
-rw-r-----. 1 root ssh_keys 387 Dec 17 17:22 ssh_host_ed25519_key
-rw-r--r--. 1 root root 82 Dec 17 17:22 ssh_host_ed25519_key.pub
-rw-r-----. 1 root ssh_keys 2578 Dec 17 17:22 ssh_host_rsa_key
-rw-r--r--. 1 root root 554 Dec 17 17:22 ssh_host_rsa_key.pub
-rw-------. 1 root root 4277 Feb 26 11:14 sshd-second_config
-rw-------. 1 root root 4269 Mar 27 2020 sshd_config
Antes de entrar a configurar cualquier servicio de red es una buena

práctica hacer una copia del archivo que requiere configurar, con eso si cree
que se ha equivocado en la edición del archivo simplemente usted puede
volver al archivo original. Para evidenciar alguna modificación básica a la
configuración del servicio SSH, podemos cambiar el mensaje de bienvenida
a las conexiones nuevas como se muestra a continuación:
Adicione una línea con un texto al archivo /etc/issue:
[root@pruebas ssh]# echo “Este servidor es seguro” >> /etc/issue
Seguidamente edite el archivo de configuración del servicio, buscando la

línea con el parámetro de configuración “Banner” (si está comentada,
descomentela quitando el carácter #), debe quedar de la siguiente forma:
[root@pruebas ssh]# vim /etc/ssh sshd_config
Banner /etc/issue
Se hace necesario decirle a servicio que lea nuevamente su archivo de

configuración como se muestra a continuación:
[root@pruebas ssh]# systemctl reload sshd
Para evidenciar este cambio, solo es necesario intentar conectarse al

servicio desde un cliente (aplicación “Terminal” en Mac OSX) y probar,
$ ssh -l root 192.168.0.200

\S
Kernel \r on an \m
Este servidor es seguro
https://192.168.0.200:9090/
Last login: Fri Mar 5 07:53:46 2021 from 192.168.0.35
De igual forma si usted requiere que los usuarios que se conecten a un

servidor vía SSH visualicen un mensaje cualquiera, puede agregar un
archivo de texto a /etc/motd.d, como se muestra:
[root@pruebas motd.d]# pwd

/etc/motd.d
[root@pruebas motd.d]# ll
total 4
-rw-r--r--. 1 root root 36 Mar 5 10:06 aptivalabs
lrwxrwxrwx. 1 root root 17 Aug 20 2020 cockpit -> /run/cockpit/motd
lrwxrwxrwx. 1 root root 9 Mar 5 07:33 insights-client -> /dev/null
AUTENTICACIÓN POR LLAVES DE USUARIO
Una de las formas de endurecer el servicio SSH es cambiar la forma

como se autentican los usuarios, que por default está configurado para que
introduzcan una contraseña. El ejercicio por implementar consiste en
cambiar la forma como se autentican los usuarios frente al servidor Linux,
en vez de hacerlo pasando una contraseña, los usuarios se autenticarán
usando una llave de conexión.
Antes de iniciar es importante que usted sepa que la autenticación por

llaves está habilitada de forma paralela a la autenticación por introducción
de contraseña. En las instrucciones a continuación se evidencia el caso de
un usuario (llaves generadas en Mac OSX) que generó sus llaves y se las
copió al servidor 192.168.0.200, como se muestra a continuación:
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/fabianmestresocarras/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/fabianmestresocarras/.ssh/id_rsa.
Your public key has been saved in /Users/fabianmestresocarras/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:R97jyJUH1cRV2+qwcLtPC9vnu2uYP+RvrMEwtSrLhk4
fabianmestresocarras@Usuarios-MacBook-Pro.local
The key's randomart image is:
+---[RSA 2048]----+
| .+*. |
| . =. |
| . . ... |
| o.+o |
| S + X +. |
| o*%. |
| E.+ * X. |
| ....o O *+. |
| ...o o.BXO |
+----[SHA256]-----+
$ ssh-copy-id -i id_rsa.pub root@192.168.0.200

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that
are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is
to install the new keys
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'root@192.168.0.200'"

and check to make sure that only the key(s) you wanted were added.
$ ssh root@192.168.0.200
Web console: https://pruebas.aptivalabs:9090/ or https://192.168.0.200:9090/

[root@pruebas ~]#
Tenga presente que la copia de la llave se ha hecho hacia el usuario

“root” del servidor Linux, solicitando la contraseña del usuario root para
poder almacenarla, si esta es introducida correctamente la llave se
almacenará en el directorio personal de trabajo del usuario “root”, mas
exactamente en la ruta /root/.ssh/authorized_keys, como se muestra a
continuación:
[root@pruebas ~]# cd .ssh/
[root@pruebas .ssh]# ll
total 4
-rw-------. 1 root root 429 Mar 5 10:46 authorized_keys
[root@pruebas .ssh]# cat authorized_keys

ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQC/EopKArp5C9WwUdkZwkOtXPzbrEdEDdI
kaZ2fnbZrkFKC5BwZNDEazJGbWoH542yBwpcVdE6WV1aZsWI/AeDG5QIANUoJ7/ulCjn
Y77BKJaGdsj08H1EPOZ+pq0e1c5bN92LM8UdZ/lFcy3Sgh9QkTKZSl7f23IIuLy8r7+Am8TA
Mg+MTjWHah7v5ZfKBlbO/dOYh4IR2HYP2BwW5EP/nerVvrrsYyOIDaDMadDzx8KC1Kbs
inQnox0/O+Em7pftAerWc4MHxkUSUET1lB+SlQLl7ZZREmMNHDh8aL7ELiRcszi3UQd61
BtV1SbzQwbz/HiF2nh4N6CeBn8kzhZ/V fabianmestresocarras@Usuarios-MacBook-Pro.local
De esta forma este usuario tendrá acceso al servidor sin hacer uso de una
contraseña, registrándose directamente como usuario “root” en el servidor
remoto. Si el archivo “authorized_keys” es eliminado del sistema el servidor
Linux nuevamente solicitará contraseña para el ingreso.
En función de desactivar el ingreso de contraseñas, edite la línea en
“/etc/ssh/sshd_config” que permite la autenticación por contraseña,
asignándole el valor “no”, reinicie el servicio una vez finalizada la edición
del archivo, como se muestra a continuación:
[root@pruebas ssh]# vim /etc/ssh/sshd_config
PasswordAuthentication no
[root@pruebas ssh]# systemctl reload sshd.service
Intente conectarse nuevamente desde el cliente SSH, debe de obtener una

respuesta de conexión rechazada, como la que se muestra:
$ ssh -l root 192.168.0.200

root@192.168.0.200: Permission denied (publickey,gssapi-
keyex,gssapi-with-mic).
Como ya se tenia una llave generada y almacenada en el servidor Linux,

usted podrá autenticarse frente al servidor Linux utilizando esa llave de
conexión, tenga cuidado en no perderla pues podría tener inconvenientes
para acceder nuevamente en el servidor remoto. Evidencia que el archivo de
configuración del servicio SSH tiene la autenticación por contraseña cerrada
es esta:
[root@pruebas ~]# cat /etc/ssh/sshd_config | grep

PasswordAuthentication
#PasswordAuthentication yes
PasswordAuthentication no
Como detalle adicional y no menos importante, usted podría crear sus

llaves utilizando un algoritmo mas fuerte que RSA. RHEL recomienda usar
los algoritmos ECDSA o Ed25519. ECDSA (Elliptic Curve Digital
Signature Algorithm) ofrece mejor performance que RSA y Ed25519 es mas
mucho mas seguro y rápido que RSA, DSA y ECDSA. Tenga presente en el
archivo de configuración se encuentran las líneas que le permiten este tipo
de llaves, como se muestra:
[root@pruebas ~]# cat /etc/ssh/sshd_config | grep HostKey
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
Si usted quiere desactivar alguna de ellas simplemente coloque el

simbolo # para comentar la línea y reinice o haga un reload al servicio.
CAMBIANDO EL PUERTO DE CONEXIÓN POR DEFAULT
El puerto por default para la conexión vía SSH es el puerto “bien

conocido” 22. Endurecer el servicio implica como buena práctica cambiar
este número a uno diferente y libre, como se muestra en el siguiente
procedimiento.
Revisemos en que puerto está escuchando el servicio, la lógica nos

indica que el puerto es el 22, sin embargo evidenciemos:
[root@pruebas ssh]# cat sshd_config | grep Port

#Port 22
Para cambiar el puerto de conexión editemos la línea correspondiente a

5022 (puerto aleatorio) en el archivo de configuración, reiniciamos el
servicio e informemos a FirewallD y a SELinux de los cambios efectuados,
como se detalla a continuación:
Port 5022
[root@pruebas ssh]# systemctl reload sshd.service
[root@pruebas ssh]# semanage port -a -t ssh_port_t -p tcp 5022
[root@pruebas ssh]# firewall-cmd --add-port=5022/tcp --permanent

success
[root@pruebas ssh]# firewall-cmd –reload

success
Al intentar conectarse desde el lado del cliente de la forma tradicional

usted podrá observar un error como el siguiente:
Usuarios-MacBook-Pro:.ssh fabianmestresocarras$ ssh -l root

192.168.0.200
ssh: connect to host 192.168.0.200 port 22: Connection refused
Esto debido a que ya no se está usando el puerto por default y es
necesario indicarle el nuevo puerto, como se observa:
Usuarios-MacBook-Pro:.ssh fabianmestresocarras$ ssh -l root

192.168.0.200 -p 5022
https://192.168.0.200:9090/
DESACTIVANDO LOGIN DE USUARIO ROOT
OpenSSH en su archivo de configuración le permitirá desactivar la

opción de registrarse en el sistema como usuario “root” editando el
parámetro “PermitRootLogin” en el archivo de configuración el cual debe
estar en “no”. Con esto el usuario administrador debe ingresar con una
cuenta estándar para luego suplantar al usuario “root”. Si este es su deseó
ejecute el respectivo cambio y reinice o haga un reload del servicio.
PERMITIENDO LOGIN DE USUARIOS AUTORIZADOS
Las directivas AllowUsers y AllowGroups en el archivo de

configuración /etc/ssh/sshd_config le da la opción de que solo ciertos
usuarios, dominios o grupos se conecten al servicio OpenSSH. Puede
combinar AllowUsers y AllowGroups para restringir el acceso con mayor
precisión. El siguiente procedimiento muestra como OpenSSH puede
permitir el ingreso única y exclusivamente a los usuarios del grupo
“ingenieria”.
Se crea el grupo “ingenieria”:
[root@pruebas ssh]# groupadd ingenieria
Se crea un usuario estándar llamado “curri” y se le asigna su respectiva

contraseña:
[root@pruebas ssh]# useradd curri
[root@pruebas ~]# passwd curri

Changing password for user curri.
New password:
Una vez el usuario ha sido creado se actualiza el grupo secundario del
usuario, en este caso el usuario pertenecerá al grupo “ingenieria”:
[root@pruebas ssh]# usermod -aG ingenieria curri
[root@pruebas ssh]# cat /etc/group | grep curri

curri:x:1002:
ingenieria:x:1003:curri
A continuación se adiciona la línea (puede ser al final del archivo)

“AllowGroups ingenieria” al archivo de configuración del servicio SSH
“AllowGroups ingenieria”
Es necesario hacer un reload del servicio para que los cambios surtan
efecto:
[root@pruebas ssh]# systemctl reload sshd
Para evidenciar este ejercicio previamente se había creado el usuario

“fmestre”, el cual intentará conectarse al servidor SSH como se muestra:
$ ssh -l fmestre 192.168.0.200

Permission denied, please try again.
Como el usuario “fmestre” no hace parte del grupo “ingenieria” no

tendrá acceso al servidor, caso contrario para el usuario “curri”, como se
detalla:
$ ssh -l curri 192.168.0.200

curri@192.168.0.200's password:
https://192.168.0.200:9090/

[curri@pruebas ~]$
ADMINISTRACIÓN DEL STORAGE
PARTICIONAMIENTO DE DISPOSITIVOS
Partir un dispositivo de bloques trae una serie de ventajas en función de
la estabilidad y confiablidad de los sistemas Linux, como limitar el espacio
de uso de las aplicaciones, separar datos de sistema operativo y filesystems
de usuario, evitar llenados de filesystems que puedan detener la operación
del sistema, etc.
Linux Red Hat le permite manejar los esquemas de particionamiento

MBR y GPT, cada uno con sus características, ventajas y desventajas.
Desde MBR es posible manejar cuatro (4) particiones principales y máximo
15 particiones entre primarias y lógicas. MBR permite un tamaño de disco y
partición máximo de 2 TiB. Debido a que los discos físicos son cada vez
más grandes el límite de tamaño de partición y disco de 2 TiB del esquema
de partición MBR ya no es un límite teórico, sino un problema del mundo
real que los administradores de sistemas encuentran cada vez con más
frecuencia en entornos de producción. Como resultado, el esquema MBR
está en proceso de ser reemplazado por GPT.
Utilizando GPT es posible administrar un máximo de 128 particiones y

discos de hasta 8 Zebibytes (8 ZiB). Además de abordar las limitaciones del
esquema de partición MBR, un GPT también ofrece algunas características y
beneficios adicionales. Un GPT utiliza un identificador único global (GUID)
para identificar cada disco y partición a diferencia de un MBR, que tiene un
solo punto de información, un GPT ofrece redundancia de la información de
su tabla de particiones.
La siguiente ilustración permite detallar un sistema con dos dispositivos

de bloque, uno llamado /dev/sda y el otro llamado /dev/sdb. Vemos para
/dev/sda cuatro particiones primarias, y para /dev/sdb se observa que el
dispositivo de bloque tiene una partición extendida y dentro de esa partición
extendida, dos particiones lógicas. A nivel de administración del storage,
solo las particiones primarias y lógicas son susceptibles de asignación de
filesystem o declaración tipo SWAP. Las particiones extendidas solo
funcionan como contenedores de las particiones lógicas.
PARTICIONANDO UN DISPOSITIVO DE
BLOQUE
Para particionar los dispositivos de bloques se utilizan programas
editores de particiones, estas son aplicaciones que permiten a los
administradores realizar cambios en las particiones de un disco, como crear
particiones, eliminar particiones y cambiar tipos de partición. Para realizar
estas operaciones, los administradores pueden usar el programa “parted”
tanto en esquemas de particionamiento MBR o GPT.
Antes de entrar en actividades de particionamiento necesitamos conocer

sobre que dispositivo de bloques vamos a particionar, como se muestra a
continuación:

`-sda2 8:2 0 49G 0 part
|-rhel-root 253:0 0 44G 0 lvm /
sdb 8:16 0 50G 0 disk
La salida del anterior comando nos muestra el dispositivo /dev/sdb de

50GB como libre para particionar, no lo está utilizando del sistema para
ningún tipo de operación, por tanto lo utilizaremos como dispositivo de
pruebas para nuestros laboratorios. Para declarar un dispositivo de bloques
en el equema de particionamiento GPT podemos hacer lo siguiente:
[root@pruebas ~]# parted /dev/sdb mklabel gpt

Information: You may need to update /etc/fstab.
La siguiente instrucción usa el commando “fdisk”, también usado para

particionar discos, sin embargo, lo utilizaremos para listas los dispositivos en
el sistema y sus esquemas de particionamiento, como se muestra a
continuación:
[root@pruebas ~]# fdisk -l

Disk /dev/sda: 50 GiB, 53687091200 bytes, 104857600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3a91d65d
Disk /dev/sdb: 50 GiB, 53687091200 bytes, 104857600 sectors

Disklabel type: gpt
Disk identifier: 25F3E57C-3909-4300-AD5F-C56EE46A66A4
Vemos como /dev/sdb usa el esquema de particionamiento GPT. Utilice

únicamente mklabel cuando la intención es reutilizar el disco sin tener en
cuenta los datos existentes. El programa “parted” al contrario de “fdisk”
escribe de forma automática las tablas de partición en los dispositivos de
bloque (de cuidado) actualizando la información con el kernel en tiempo
real. Un ejemplo de particionamiento es el que sigue:
[root@pruebas ~]# parted /dev/sdb

GNU Parted 3.2
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mkpart
Partition name? []? aptivalabs1
File system type? [ext2]? xfs
Start? 2048s
End? 2000MB
(parted) quit
Information: You may need to update /etc/fstab.
En el ejemplo anterior se ha particionado el dispositivo /dev/sdb,

colocándole un nombre a la partición, un sector de inicio y un sector final
establecido en tamaño de 2GB, un sistema de archivos para la partición, en
este caso XFS; por ultimo se le dio la instrucción de salir. Una vez fuera de
la herramienta es posible confirmar que “parted” ha asignado un filesystems
con la siguiente instrucción:
[root@pruebas ~]# blkid

/dev/sda1: UUID="7f2877fe-11eb-4249-8aaa-c7427996f704" BLOCK_SIZE="512"
TYPE="xfs" PARTUUID="3a91d65d-01"
/dev/sda2: UUID="IwurLn-Wgds-Qykj-Q0oo-8g5n-3dAe-hsSfpi"
TYPE="LVM2_member" PARTUUID="3a91d65d-02"
/dev/sdb1: PARTLABEL="aptivalabs1" PARTUUID="862e541b-7097-4b3d-819a-
e8994c39e91b"
/dev/mapper/rhel-root: UUID="42b3b135-dda6-4318-aae7-e7bf9f077ad8"
BLOCK_SIZE="512" TYPE="xfs"
/dev/mapper/rhel-swap: UUID="6bb565d3-b3dd-4c31-a345-88668e6e7857"
TYPE="swap"
Una vez terminada la operación, desde Red Hat hacen la recomendación

de ejecutar la instrucción “udevadm settle”. Este comando espera a que el
sistema detecte la nueva partición y la creación del archivo de dispositivo
asociado en el directorio /dev, dispositivo que se muestra a continuación:
[root@pruebas ~]# ll /dev/ | grep sdb

brw-rw----. 1 root disk 8, 16 Feb 26 14:48 sdb
brw-rw----. 1 root disk 8, 17 Feb 26 14:48 sdb1
El procedimiento anterior pudo haber sido realizado utilizando una

instrucción como la que se muestra a continuación:
[root@pruebas ~]# parted /dev/sdb mkpart aptivalabs1 xfs 2048s

2000MB
El ejercicio también es posible hacerlo con “fdisk”. En el siguiente

aparte se muestra como se agrega otra partición al disco utilizando “fdisk”,
tal como sigue:
[root@pruebas ~]# fdisk /dev/sdb

Changes will remain in memory only, until you decide to write them.
Command (m for help): p

Disklabel type: gpt
Device Start End Sectors Size Type

/dev/sdb1 2048 3905535 3903488 1.9G Linux filesystem
Command (m for help): n
Partition number (2-128, default 2):
First sector (3905536-104857566, default 3905536):
Last sector, +sectors or +size{K,M,G,T,P} (3905536-104857566, default 104857566):
+1G
Created a new partition 2 of type 'Linux filesystem' and of size 1 GiB.

Disklabel type: gpt

/dev/sdb2 3905536 6002687 2097152 1G Linux filesystem
Command (m for help): w

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
[root@pruebas ~]# udevadm settle
A diferencia de “parted”, “fdisk” no le da la opción de adicionar un

sistema de archivos para asignarle a la segunda partición que se acaba de
crear, procedimiento que necesita ejecutar en el siguiente paso, pues de nada
le sirve tener una participación sin asignarle un filesystems, que es donde se
estructuran los datos (donde se guardan los datos). Sea con “fdisk” o
“parted” usted puede realizar operaciones sobre las particiones de los discos:
crearlas, cambiarles el tipo, eliminarlas, etc, sin embargo tenga presente lo
siguiente: en el entorno empresarial lo mas normal es manejar LVM (tema
que trataremos mas adelante), esquema de manejo de discos que
“normalmente” usa discos completos donde no hay necesidad de partir los
dispositivos; en cualquier caso, usted debe conocer el manejo de “fdisk” o
“parted” a la hora de administrar discos.
ASIGNACIÓN DE FILESYSTEMS Y
MONTAJE PERSISTENTE
Si usted tiene quiere guardar datos usted necesita un disco, sencillo. El
ejercicio completo es que usted particione un dispositivo de bloque o tome
un disco entero, le asigne un sistema de archivos y haga disponible ese
sistema de archivos para poder guardar datos en él. Ese hacer disponible en
el lenguaje Linux se conoce como “montar”, y ese montar significa que un
sistema de archivos se enlaza con otro sistema de archivos. Aprovechando
el ejercicio anterior, tenemos un par de dispositivos de bloques sin formatear,
vamos a realizar la operación completa sobre ellos (ya vienen particionados);
se realizará siguiendo el siguiente procedimiento en su respectivo orden:
1. Identificar el dispositivo de bloque sobre el cual se desea

trabajar
2. Asignar el sistema de archivos de preferencia (cada uno de
ellos tiene sus características)
3. Definir el punto de montaje
4. Verificar el UID del sistema de archivos
5. Hacer persistente el sistema de archivos (montarlo sobre el
sistema de archivo principal, ese que se creó cuando se instaló el
sistema operativo)
6. Comprobar el montaje persistente y el punto de montaje valido
Demos inicio a este laboratorio, ejecutando cada uno de los pasos

explicados anteriormente:
1. Identificando el dispositivo donde se va a trabajar:

`-sda2 8:2 0 49G 0 part
|-rhel-root 253:0 0 44G 0 lvm /
sdb 8:16 0 50G 0 disk
|-sdb1 8:17 0 1.9G 0 part
`-sdb2 8:18 0 1G 0 part
sr0 11:0 1 8.8G 0 rom /repo
tomaremos como dispositivo de trabajo el dispositvo /dev/sdb1, con

1.9 GB disponibles para guardar datos.
2. Asignaremos formato a ese dispositivo de bloques, como sigue

a continuación:
[root@pruebas ~]# mkfs.xfs /dev/sdb1

meta-data=/dev/sdb1 isize=512 agcount=4, agsize=121984 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1
data = bsize=4096 blocks=487936, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Discarding blocks...Done.
Red Hat Linux le da la opción de asignar diferentes sistemas de

archivos, siendo XFS el sistema nativo, sin embargo, usted podrá
asignar los siguientes sistemas de archivos a su dispositivo de bloque:
[root@pruebas ~]# mkfs.

mkfs.cramfs mkfs.ext2 mkfs.ext3 mkfs.ext4 mkfs.fat mkfs.minix mkfs.msdos
mkfs.vfat mkfs.xfs
el sistema de archivos que escoja tendrá sus funcionalidades y

características. Desde la versión 7 de RHEL XFS es el sistema nativo y
este es el que se ha escogido para asignarle al dispositivo de bloque.
3. Definiendo el punto de montaje creando la carpeta /datos :

Tenga presente que esta nueva carpeta llamada “datos” está ubicada
en “/” el cual ya tiene un sistema de archivos asignado, como se
[root@pruebas ~]# df -hT

Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/rhel-root xfs 44G 11G 34G 25% /
Debido a esto es que se usa la palabra montaje, por que se hace que
un sistema de archivos se monte sobre otro, en este caso un XFS nuevo
y asignado, montado sobre el filesystem que se eligió en el momento de
la instalación del sistema operativo.
4. Es momento entonces de verificar que el filesystem creado

haya sido asignado sobre el dispositivo de bloques:

/dev/sdb1: UUID="aa0f5e04-4355-4dc2-b540-bc3509ec8a2d"
BLOCK_SIZE="512" TYPE="xfs" PARTLABEL="aptivalabs1"
PARTUUID="862e541b-7097-4b3d-819a-e8994c39e91b"
5. Es momento entonces de hacer persistente el montaje del

sistema de archivos. Que significa esto ? Necesitamos que
cuando el sistema inicie enlace los dos sistemas de archivos, el
principal, y el que se asignó a /dev/sdb1; esto se consigue editando
el archivo /etc/fstab, agregando la siguiente línea, de la siguiente
forma:
[root@pruebas ~]# echo 'UUID="aa0f5e04-4355-4dc2-b540-

bc3509ec8a2d" /datos xfs defaults 0 0' >> /etc/fstab
#
# /etc/fstab
# Created by anaconda on Thu Dec 17 22:08:06 2020
--- salida omitida --
UUID="aa0f5e04-4355-4dc2-b540-bc3509ec8a2d" /datos xfs
defaults 0 0
/datos es la carpeta que nos dará entrada al sistema de archivos

asignado a /dev/sdb1. De igual forma usted ha visto el UUID del
sistema de archivos, este lo vimos en la salida del comando “blkid”, ese
es el identificador del sistema de archivos. Cuando el sistema inicie
verificará esa línea en el archivo /etc/fstab y enlazará los dos sistemas
de archivos. Todo lo que usted guarde en /datos quedará guardado en
/dev/sdb1 a no ser que usted defina otra carpeta para ello.
Tenga presente que si el archivo /etc/fstab queda mal editado existe

un riesgo que en el momento de un reinicio el sistema Linux no pueda
bootear. Cuando esta situación ocurre su sistema pasa a modo de
rescate.
6. Cuando usted modifique el archivo /etc/fstab debe decirle a

SystemD que reconozca el cambio, lo puede hacer de la siguiente
forma:
[root@pruebas ~]# systemctl daemon-reload
Inmediatamente ejecute un “mount -a” para validar que lo que

guardó en el archivo /etc/fstab quedó correctamente editado, de la
siguiente forma:

[root@pruebas ~]#
Si el “mount -a” le genera alguna salida es por que la edición del

archivo quedó mal realizada. Si el “mount -a” no le genera ninguna
salida significa que el archivo quedó bien editado y usted ya puede
reiniciar el sistema con confianza.
Este es un procedimiento para realizar en menos de dos minutos,

importante a la hora realizar el examen de certificación para RHCSA, sin
embargo, si usted está empezando en temas de administración Linux solo
tenga presente el orden, no se equivoque (por favor), practique las veces que
sea necesario hasta dominar el procedimiento pues es una actividad clave
para que los sistemas funcionen. A manera de caso de uso, usted puede
adjuntar a su sistema un disco nuevo, a ese disco le puede asignar un
filesystem para luego realizarle un montaje persistente y tenerlo disponible
para guardar ahí los datos de una base de datos.
A manera de ilustración gráfica, podemos observar en la siguiente

imagen el concepto de punto de montaje; en este caso tenemos el dispositivo
/dev/sda que cuenta con dos particiones primarias, en una de ellas se creó el
sistema de archivos principal (XFS) en el momento de la instalación del
sistema, dentro de ese filesystem creado está la carpeta /mnt; la gráfica nos
muestra que existe el dispositivo de bloque /dev/sdb, el cual tiene una
partición extendida y una partición lógica dentro de ella; se observa que
/dev/sdb5 (partición lógica) cuenta con un sistema de archivos XFS el cual
necesita ser utilizado, para esto se establece un enlace entro los dos sistemas
de archivos a partir de /mnt, quiere decir que si existe un enlace entre estos
filesystems usted podrá guardar datos en /dev/sdb5, todo lo que usted guarde
en /mnt quedará en el sistema de archivos XFS asignado a /dev/sdb5.
CHEQUEO DE FILESYSTEMS TIPO XFS
Los filesystems son suceptibles de revisión, el procedimiento a
continuación realiza una verificación de solo lectura de un sistema de
archivos XFS mediante la utilidad “xfs_repair”. Usted debe usar
manualmente la utilidad xfs_repair para reparar cualquier daño. A diferencia
de otras utilidades de reparación del sistema de archivos, xfs_repair no se
ejecuta en el momento del arranque.
El sistema de Journalling mantiene un registro transaccional de los

cambios de metadatos que ocurren en el sistema de archivos. En el caso de
una falla del sistema, falla de energía u otro desmontaje no apropiado, XFS
usa el log para recuperar el sistema de archivos. La corrupción significa que
existen errores en el sistema de archivos causados por fallos de hardware o
errores en el firmware de almacenamiento asociados a los controladores de
dispositivos. Cuando XFS detecta daños en el sistema de archivos o en los
metadatos del sistema de archivos, puede desmontar el filesystem e informar
el incidente en el registro del sistema.
Para entrar a chequear el filesystem, inicialmente se verifica el sistema

de archivos que se desea chequear, para este ejercicio se chequeará el
filesystem que está sobre /dev/mapper/datos-app3:

/dev/sr0 iso9660 8.9G 8.9G 0 100% /repo
/dev/sda1 xfs 1014M 420M 595M 42% /boot
/dev/mapper/datos-app2 xfs 100G 747M 100G 1% /datos/app2
/dev/mapper/datos-app3 xfs 10G 105M 9.9G 2% /datos/app3
tmpfs tmpfs 2.9G 1.2M 2.9G 1% /run/user/42
tmpfs tmpfs 2.9G 0 2.9G 0% /run/user/0
Es necesario desmontar el punto de montaje, como sigue:
[root@pruebas ~]# umount /datos/app3

Seguidamente se realiza el chequeo, utilizando el parámetro “-n” del
comando xfs_repair:
[root@pruebas ~]# xfs_repair -n /dev/mapper/datos-app3

Phase 1 - find and verify superblock...
- reporting progress in intervals of 15 minutes
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- 09:18:55: scanning filesystem freespace - 16 of 16 allocation groups done
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- 09:18:55: scanning agi unlinked lists - 16 of 16 allocation groups done
- process known inodes and perform inode discovery...
- agno = 0
- agno = 15
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- 09:18:55: process known inodes and inode discovery - 64 of 64 inodes done
- process newly discovered inodes...
- 09:18:55: process newly discovered inodes - 16 of 16 allocation groups done
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- 09:18:55: setting up duplicate extent list - 16 of 16 allocation groups done
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- agno = 15
- 09:18:55: check for inodes claiming duplicate blocks - 64 of 64 inodes done
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
- 09:18:55: verify and correct link counts - 16 of 16 allocation groups done
No modify flag set, skipping filesystem flush and exiting.
Una vez chequeado realizamos un “mount” para tener nuevamente

disponible el filesystem en el punto de montaje:
Para finalizar, se verifica que el punto de montaje quede activo:

ADMINISTRACIÓN DE SWAP
Un espacio de intercambio es un área de un disco bajo el control de la
administración de memoria del kernel de Linux. El kernel utiliza espacio de
intercambio para complementar la RAM del sistema. La RAM del sistema
combinada más el espacio de intercambio se denomina memoria virtual.
Debido a que las áreas de intercambio residen en el disco, el swapping es
lento en comparación con la RAM.
Usted puede agregar espacio de intercambio (swap) de varias formas:

declarando un archivo de swap, declarando una partición adicional para
swap, o si la swap de su sistema está declarada como un volumen lógico,
usted puede ampliar ese volumen lógico, procedimiento que se detallará en
los temas relacionados a LVM.
Para conocer el espacio de intercambio declarado en su sistema usted

puede proceder como se muestra a continuación:
[root@pruebas ~]# swapon -s

FilenameTypeSizeUsedPriority
/dev/dm-1 partition52428760-2
En esta oportunidad se observa una sola partición como parte del espacio
de intercambio del sistema; iremos agregando a medida que se expliquen los
temas y esta lista irá creciendo.
DECLARANDO UN ARCHIVO DE SWAP
Linux le permite crear un archivo cualquiera y declararlo como archivo

de intercambio del sistema, tal como se muestra en el siguiente
procedimiento, donde se crea un archivo de 1GB para espacio de
intercambio:
[root@pruebas ~]# dd if=/dev/zero of=/mnt/archivo-intercambio

bs=1024 count=1000000
1000000+0 records in
1000000+0 records out
1024000000 bytes (1.0 GB, 977 MiB) copied, 2.4711 s, 414 MB/s
[root@pruebas ~]# ll -h /mnt/

total 977M
-rw-r--r--. 1 root root 977M Feb 27 10:01 archivo-intercambio
Una vez creado el archivo, es necesario declararlo como archivo de

intercambio de la siguiente forma:
[root@pruebas ~]# mkswap /mnt/archivo-intercambio
mkswap: /mnt/archivo-intercambio: insecure permissions 0644, 0600 suggested.
Setting up swapspace version 1, size = 976.6 MiB (1023995904 bytes)
no label, UUID=1c8ce9b2-ccf9-4fc0-bc4b-d1ba11e8c6f9
Declaramos los permisos apropiados sobre el archivo de intercambio:
[root@pruebas ~]# chmod 600 /mnt/archivo-intercambio
Adicionamos a /etc/fstab la linea correspondiente para que este archivo

de intercambio sea reconocido en el inicio del sistema:
[root@pruebas ~]# echo '/mnt/archivo-intercambio swap swap

defaults 0 0' >> /etc/fstab
Verificamos que la línea haya sido agregada al archivo /etc/fstab:
#
# /etc/fstab
---salida omitida ---
/mnt/archivo-intercambio swap swap defaults 0 0
Cuando usted modifique el archivo /etc/fstab debe decirle a SystemD que

reconozca el cambio, lo puede hacer de la siguiente forma:
Se activa el archivo de intercambio de forma inmediata, como se muestra

a continuación:
[root@pruebas ~]# swapon /mnt/archivo-intercambio
Por último, se verifica que el sistema haya reconocido este espacio de

intercambio:
[root@pruebas ~]# cat /proc/swaps

/mnt/archivo-intercambio file9999960-3
DECLARANDO UNA PARTICIÓN TIPO SWAP
El proceso consiste en reservar una partición del sistema (en este caso
crearemos una nueva partición sobre /dev/sdb), declararla como partición de
intercambio y activarla, tal como se muestra a continuación:
1. Editamos con “fdisk” la tabla de particionamiento del

dispositivo de bloque /dev/sdb.
[root@pruebas ~]# fdisk /dev/sdb

Changes will remain in memory only, until you decide to write them.
Creamos una nueva partición y se le define el tamaño de 1GB:

Command (m for help): n
Partition number (3-128, default 3):
First sector (6002688-104857566, default 6002688):
Last sector, +sectors or +size{K,M,G,T,P} (6002688-104857566, default 104857566):
+1G
Created a new partition 3 of type 'Linux filesystem' and of size 1 GiB.
Siguiendo en “fdisk”, es necesario cambiar el tipo de partición,

como se muestra:
Command (m for help): t
Partition number (1-3, default 3): 3
Partition type (type L to list all types): 19

Changed type of partition 'Linux filesystem' to 'Linux swap'.
Se ha cambiado el tipo de partición a 19, llamada Linux swap. Por

último, se lista la tabla de particionamiento y se guarda:
Disklabel type: gpt

/dev/sdb2 3905536 6002687 2097152 1G Linux filesystem
/dev/sdb3 6002688 8099839 2097152 1G Linux swap
Command (m for help): w

The partition table has been altered.
Syncing disks.
Esperamos a que el sistema detecte la nueva partición y la creación del

archivo de dispositivo asociado en el directorio /dev usando:
Se verifica que el kernel de Linux reconozca la nueva partición creada:
[root@pruebas ~]# cat /proc/partitions

major minor #blocks name

8 16 52428800 sdb
8 17 1951744 sdb1
8 18 1048576 sdb2
8 19 1048576 sdb3
Se declara /dev/sdb3 como partición de intercambio:
[root@pruebas ~]# mkswap /dev/sdb3

Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes)
no label, UUID=9d8dce4d-5916-4435-85c4-c72033d68067
Se imprimen los atributos del dispositivo de bloque para verificar que
/dev/sdb3 haya sido declarado como del tipo swap:

/dev/sdb3: UUID="9d8dce4d-5916-4435-85c4-c72033d68067"
TYPE="swap" PARTUUID="1f48c8af-cadd-6945-8e3a-
a10c13e917b1"
Se agrega la línea a /etc/fstab para que en el reinicio del sistema se active

este espacio de intercambio (y se verifica):
[root@pruebas ~]# echo 'UUID="9d8dce4d-5916-4435-85c4-

c72033d68067" swap swap defaults 0 0' >> /etc/fstab
#
# /etc/fstab
UUID="9d8dce4d-5916-4435-85c4-c72033d68067" swap swap

defaults 0 0
Cuando modifique el archivo /etc/fstab debe decirle a SystemD que

reconozca el cambio, lo puede hacer de la siguiente forma:
Verifique la correcta edición del archivo /etc/fstab (en realidad el “mount

-a” lo que hace es realizar un montaje preventivo y si todo está bien no
muestra nada en pantalla):

[root@pruebas ~]#
Active a /dev/sdb3 como partición de intercambio:
[root@pruebas ~]# swapon /dev/sdb3

Verifique que el sistema reconoce a /dev/sdb3 como partición de
intercambio:
[root@pruebas ~]# cat /proc/swaps

/mnt/archivo-intercambio file9999960-3
/dev/sdb3 partition10485720-4
GESTIÓN DE LVM
El Administrador de volumen lógico (LVM) proporciona herramientas
para crear dispositivos de bloques virtuales a partir de dispositivos físicos.
Los dispositivos pueden ser más fáciles de administrar que los dispositivos
físicos y pueden tener capacidades más allá de lo que los dispositivos físicos
proporcionan. La administración de volúmenes crea una capa de abstracción
sobre el almacenamiento físico, lo que le permite crear volúmenes de
almacenamiento, esto proporciona una flexibilidad mucho mayor y la
reducción los costos operativos sobre la administración del almacenamiento.
LVM
El manejo de una estructura de particionamiento básico es importante

conocerlo, pero trae sus limitaciones. ¿ Si una partición primaria con un
sistema de archivos XFS se llena con los datos de la operación diaria de una
base de datos usted que haría ?, miremos la siguiente ilustración gráfica para
conocer un poco mas lo que es LVM:
LVM se construye de abajo haca arriba. La gráfica presentada nos

muestra en la parte inferior tres dispositivos de bloque (/dev/sdb, /dev/sdc y
/dev/sdd); vamos a tomar los dispositivos dev/sdb y/dev/sdc, y los vamos a
declarar volúmenes físicos (PV – physical volume). Una vez declarados los
PV’s se hace posible unirlos en un volumen de grupo (VG – volumen
group), este volumen de grupo es la unión de sus PV’s en cuanto a tamaño;
el volumen de grupo cuenta con un nombre además de estar dividido en
pequeños pedazos conocidos como PE (physical extends). A partir de un
volumen de grupo se crean los LV (logical volume) que vienen siendo un
dispositivo de bloque virtual que es el que usarán las aplicaciones para
almacenar datos, previa asignación de un sistema de archivos.
En el modelo anterior (sin tener en cuenta /dev/sdd), tenemos entonces

inicialmente dos PV’s cada uno de 1TB de almacenamiento, habiéndose
declarados como PV’s, se crea un VG llamado “datos” con un tamaño de
2TB (la suma de sus PV’s). Ese VG datos, está entonces formado por PE’s
cada uno de ellos de un tamaño de 4Mb; suponga que una aplicación
requiere 400 Mb de almacenamiento, el VG llamado datos está en capacidad
de proporcionar un LV generado por 100 PE’s para suplir las necesidades de
la aplicación. Si el tamaño de un PE es de 4Mb y usted asigna 100 PE usted
tiene un LV de 400Mb; al usted crear un LV (requiere un nombre) es como si
creara un nuevo dispositivo de bloques usando el nombre del VG y el
nombre del LV, algo así como por ejemplo /dev/datos/app1.
Siguiendo con el ejemplo, /dev/datos/app1 es reconocido por el sistema

Linux como un dispositivo de bloque al cual se le puede asignar un
filesystems (XFS por ejemplo). Este nuevo dispositivo tendrá un tamaño de
400Mb, sin embargo con el pasar del tiempo la aplicación fue llenando el
sistema de archivos y ya está en su limite, suponga que ha llegado a 390Mb.
Administrar LVM nos permite tomar el disco /dev/sdd, declararlo como un
PV, extender el VG (llegaría a los 3TB) y extender el LV llamado “app1”, he
aquí la flexibilidad que se había comentado en apartados previos, el poder ir
creciendo de forma virtual a partir de los discos físicos declarados
inicialmente como PV’s. Vamos a detallar esto llevando a la practica el
escenario anteriormente explicado, antes de eso, mostrando primero que
LVM es un servicio de sistema administrado por SystemD:
[root@pruebas ~]# systemctl | grep LVM

lvm2-monitor.service loaded active exited Monitoring of LVM2 mirrors,
snapshots etc. using dmeventd or progress polling
lvm2-pvscan@8:2.service loaded active exited LVM event activation on device 8:2
lvm2-lvmpolld.socket loaded active listening LVM2 poll daemon socket

CREANDO LA ESTRUCTURA LVM
Es momento de crear la estructura de LVM, inicialmente se comprueban

los discos en los cuales se va a trabajar, en este caso serán los dispositivos
/dev/sdc, /dev/sdd y /dev/sde, como se muestra a continuación:

sdc 8:32 0 50G 0 disk
sdd 8:48 0 50G 0 disk
sde 8:64 0 50G 0 disk
sr0 11:0 1 8.8G 0 rom /repo
Como la estructura de LVM se crea de abajo para arriba, iniciemos

declarando los dispositivos de bloque en physical volumen (PV), como se
[root@pruebas ~]# pvcreate /dev/sdc /dev/sdd /dev/sde

Physical volume "/dev/sdc" successfully created.
Physical volume "/dev/sdd" successfully created.
Physical volume "/dev/sde" successfully created.
De la siguiente forma es posible listar los PV’s que tiene nuestro sistema:
[root@pruebas ~]# pvs

PV VG Fmt Attr PSize PFree
/dev/sda2 rhel lvm2 a-- <49.00g 0
/dev/sdc lvm2 --- 50.00g 50.00g
/dev/sdd lvm2 --- 50.00g 50.00g
/dev/sde lvm2 --- 50.00g 50.00g
De la siguiente forma se detalle mas a profundidad unos de los PV’s, en

este caso /dev/sdc:
[root@pruebas ~]# pvdisplay /dev/sdc

"/dev/sdc" is a new physical volume of "50.00 GiB"
--- NEW Physical volume ---
PV Name /dev/sdc
VG Name
PV Size 50.00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID Xg34nB-M0GK-TzXs-rqWe-Kb39-rCdL-3Rmm8Y
Una vez declarados los PV’s es posible crear el volumen de grupo (VG),
[root@pruebas ~]# vgcreate datos /dev/sdc /dev/sdd

Volume group "datos" successfully created
Para listar los VG’s del sistema podemos hacer lo siguiente:
[root@pruebas ~]# vgs

VG #PV #LV #SN Attr VSize VFree
datos 2 0 0 wz--n- 99.99g 99.99g
rhel 1 2 0 wz--n- <49.00g 0
Como puede observar, el sistema Linux reconoce dos VG’s, uno llamado
“datos” y el otro llamado “rhel”, este ultimo corresponde a una estructura LV
que se creó cuando se instaló el sistema Linux. A continuación detallamos
únicamente el VG llamado “datos”:
[root@pruebas ~]# vgdisplay datos

--- Volume group ---
VG Name datos
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 2
Act PV 2
VG Size 99.99 GiB
PE Size 4.00 MiB
Total PE 25598
Alloc PE / Size 0/0
Free PE / Size 25598 / 99.99 GiB
VG UUID 6ymc1a-38Tu-FYET-Lq9I-9iUb-BDRt-DUBDgB
Podemos ver que el tamaño del VG “datos” es de 99.99 GiB, la suma de
sus dos PV’s, cada uno de ellos de 50 GiB (se toma datos para metadata),
también se aprecia el tamaño del PE, en este caso de 4MiB y se nota también
la cantidad de PE’s, en este caso 25598; si usted multiplica 25598 por 4
tendrá los 99.99 GiB disponibles en el VG.
Existen diferentes tipos de volúmenes lógicos, sin embargo para efectos

de este material trabajaremos con los volúmenes lógicos lineales. Un
volumen lógico lineal toma almacenamiento de uno o mas volúmenes
físicos. Por ejemplo, si usted tiene dos discos de 50 GB, usted puede crear
un volumen lógico de 100 GB.
A continuación se crea el volumen lógico llamado “app1”, formado por

100 PE’s (usted puede usar el parámetro -L para crear un tamaño fijo), el
nuevo dispositivo de bloque virtual tomará los PE’s del grupo de volumen
llamado “datos”:
[root@pruebas ~]# lvcreate -l 100 -n app1 datos

Logical volume "app1" created.
De la siguiente forma se listan los LV’s reconocidos por el sistema

Linux, en este caso es posible ver el LV llamado “app1”, proveniente del VG
llamado “datos”, con un tamaño de 400MiB:
[root@pruebas ~]# lvs

LV VG Attr LSize Pool Origin Data% Meta% Move Log
Cpy%Sync Convert
app1 datos -wi-a----- 400.00m
root rhel -wi-ao---- <44.00g
swap rhel -wi-ao---- 5.00g
Usted podrá confirmar la creación de este dispositivo de bloques virtual

listado las siguientes carpetas:
[root@pruebas ~]# ll /dev/

total 0
drwxr-xr-x. 2 root root 60 Mar 1 09:08 datos
[root@pruebas ~]# ll /dev/datos/
total 0
lrwxrwxrwx. 1 root root 7 Mar 1 09:08 app1 -> ../dm-2
[root@pruebas ~]# ll /dev/mapper/datos-app1

lrwxrwxrwx. 1 root root 7 Mar 1 09:08 /dev/mapper/datos-app1 ->
../dm-2
Al crearse un LV se crea un dispositivo de bloque virtual, usted puede

referirse a el como /dev/datos/app1 o /dev/mapper/datos-app1. Este
dispositivo virtual se ha creado con el fin de almacenar datos de forma
flexible, por lo tanto es necesario asignarle un filesystem y hacerlo
persistente en el arranque del sistema operativo, como se muestra a
continuación:
[root@pruebas ~]# mkfs.xfs /dev/datos/app1

meta-data=/dev/datos/app1 isize=512 agcount=4, agsize=25600 blks
= reflink=1
A continuación listamos todos los dispositivos de bloque con sus

atributos, filtrando para que solo nos liste el dispositivo virtual nuevo,
utilizando la palabra “app1”:
[root@pruebas ~]# blkid | grep app1

/dev/mapper/datos-app1: UUID="eda68ed6-f127-48c1-90f0-
e66d21c3beae" BLOCK_SIZE="512" TYPE="xfs"
Si la carpeta /datos no está creada, es necesario crearla, esta será el punto

de montaje para el filesystem asignado al volumen lógico:

Podemos ver el UUID del filesystem asignado al dispositivo de bloques
con el comando “blkid”, útil para adicionar la línea (en /etc/fstab) que nos
asegura la persistencia del filesystem cuando el sistema reinicie, como se
[root@pruebas ~]# echo 'UUID="eda68ed6-f127-48c1-90f0-

e66d21c3beae" /datos xfs defaults 0 0' >> /etc/fstab
Es necesario decirle a SystemD que ha cambiado la configuración para el

arranque del sistema:
Por último, y para asegurarnos que nuestro sistema reiniciará sin

inconveniente realizamos un montaje de lo que esté en /etc/fstab, esperando
que esta instrucción no nos reporte salida alguna:
Si la anterior instrucción no reportó salida alguna, usted puede reiniciar

su sistema si es viable y probar esta configuración. Verifique el sistema de
archivos y el punto de montaje:

/dev/mapper/datos-app1 xfs 395M 24M 372M 6% /datos
EXTENDIENDO UN ESTRUCTURA LVM
Utilizando el esquema planteado en esta sección de LVM, se comentó

que una de las principales características de LVM es la flexibilidad para
crecer. En este caso vamos a crecer la estructura previamente formada
teniendo en cuenta que /dev/sde ya está declarado como un PV, siendo
entonces necesario extender el VG (ya está creado), el tamaño del LV según
requerimiento y limite del tamaño del VG, así como el filesystem asignado
al LV, tal como se muestra a continuación:
[root@pruebas ~]# pvs

/dev/sdb lvm2 --- 50.00g 50.00g
/dev/sdc datos lvm2 a-- <50.00g <50.00g
/dev/sdd datos lvm2 a-- <50.00g <49.61g
Si usted va sincronizado con las guías que se están publicando, habrá

notado que se había declarado como PV a /dev/sde, sin embargo la anterior
instrucción no lo listó como un PV debido a memorias que guarda el sistema
de sus tablas de particionamiento, razón por la cual el siguiente comando
que es el que extiende su volumen de grupo no funciona como es debido,
pues dice que /dev/sde ha sido excluido:
[root@pruebas ~]# vgextend datos /dev/sde

Device /dev/sde excluded by a filter.
Si este dispositivo de bloque ha sido usado por el sistema para alguna

otra operación y usted tiene la completa seguridad de que puede usar este
disco, usted puede limpiar cualquier configuración existente sobre el
dispositivo de bloque, como se muestra a continuación:
[root@pruebas ~]# wipefs -a /dev/sde

/dev/sde: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
/dev/sde: 8 bytes were erased at offset 0xc7ffffe00 (gpt): 45 46 49 20 50 41 52 54
/dev/sde: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
/dev/sde: calling ioctl to re-read partition table: Success
Una vez limpiado la configuración sobre /dev/sde, es posible declararlo
como un PV, tal como se muestra a continuación:
[root@pruebas ~]# pvcreate /dev/sde

En estos momentos se puede contar con el dispositivo /dev/sde y es
posible extender el volumen de grupo 50GiB más, tenía 99.99 GiB:
[root@pruebas ~]# vgextend datos /dev/sde

Volume group "datos" successfully extended
[root@pruebas ~]# vgs

datos 3 1 0 wz--n- <149.99g <149.60g
rhel 1 2 0 wz--n- <49.00g 0
[root@pruebas ~]# vgdisplay datos

--- Volume group ---
VG Name datos
System ID
Format lvm2
Metadata Areas 3
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 3
Act PV 3
VG Size <149.99 GiB
PE Size 4.00 MiB
Total PE 38397
Alloc PE / Size 100 / 400.00 MiB
Free PE / Size 38297 / <149.60 GiB
VG UUID 6ymc1a-38Tu-FYET-Lq9I-9iUb-BDRt-DUBDgB
El volumen de grupo llamado “datos” ha sido extendido en 50GiB, la

línea VGSize nos dice que se ha incrementado a 149.99 GiB, también se han
incrementado la cantidad de PE’s a 38397. Aunque en el esquema anterior
existía capacidad para extender el LV se quiso mostrar un hipotético
escenario de la vida diaria, donde los discos no son suficientes y se integra
uno nuevo. Una vez extendido el VG, extendemos el LV como se muestra a
continuación:
[root@pruebas ~]# lvextend -l +100 /dev/datos/app1

Size of logical volume datos/app1 changed from 400.00 MiB (100 extents) to 800.00 MiB
(200 extents).
Logical volume datos/app1 successfully resized.
La salida de esta instrucción ha extendido el tamaño del LV de 400 MiB

a 800MiB, como se muestra a continuación:

Cpy%Sync Convert
app1 datos -wi-ao---- 800.00m
Crear y extender el LV ha sido utilizando como base los PE (physical

extends, parámetro “-l”), usted puede hacerlo usando el parámetro “-L” para
realizar asignaciones fijas sin embargo le podría acontecer que el sistema no
le permita asignar espacios definidos debido a la escasez de PE’s, es por esa
razón que el ejercicio se ha hecho completamente usando Physical Extends.
Es importante aclarar que la instrucción “lvextend -l +100

/dev/datos/app1” utiliza el símbolo “+”, esto indica que se está agregando
PE’s al LV, si usted colocara algo como “lvextend -l 100 /dev/datos/app1”, el
sistema entiende que le está asignando 100 PE’s al LV y acá pudiese estar
cometiendo un error, imagine que tenga 150 PE’s en su LV y ejecuta esta
instrucción, estaría reduciendo el tamaño de los PE’s a 100, perdiendo 50
PE’s equivalentes a 200MiB de almacenamiento (recuerde que el tamaño por
default de un PE es de 4 MiB).
Una vez extendido el LV de la manera correcta, podemos ver como

queda la tabla de sistemas de archivos y puntos de montaje:

En este caso se aprecia que el filesystem aun cree que tiene 395Mib
(asignar el filesystem tomó 5MiB para metadata), osea, se tiene con un
dispositivo de bloques de 800MiB pero el filesystem aun cree que tiene 400
MiB; para esto es necesario decirle al filesystem XFS que crezca, como lo
hace la siguiente instrucción:
[root@pruebas ~]# xfs_growfs /datos/

meta-data=/dev/mapper/datos-app1 isize=512 agcount=4, agsize=25600 blks
= reflink=1
data blocks changed from 102400 to 204800
Después de haberle informado al sistema de archivos que era necesario

crecer, se verifica de nuevo listado los sistemas de archivos y sus puntos de
montajes:

Tenga presente que este ejercicio ha usado desde el inicio el sistema de

archivos XFS, hoy día muchos sistemas Linux aun tienen EXT4, EXT3 o
incluso EXT2 como sistema de archivos para sus sistemas, extender estos
sistemas de archivos usan un procedimiento distinto. Para el caso de los LV
(Logical Volume), el comando “lvextend” cuenta con el parámetro “-r”, el
cual es usado para que al momento de extender el volumen lógico, extienda
también el sistema de archivos, esta información la puede complementar
usando un “man lvextend” o un man “resize2fs”.
REDUCIENDO LA ESTRUCTURA LVM – MOVIENDO DATA
ENTRE PV’S
Reducir una estructura LVM resulta en una operación para pensar

detenidamente por todo lo que significa, especialmente por la perdida de
datos que esto pueda traer. Normalmente se considera que estas estructuras
están hechas para crecer y no para reducirse o destruirse, sin embargo estas
operaciones son posibles. Acá se mostrará como reducir y destruir una
estructura de estas. Empecemos inicialmente con la reducción.
Es posible ver en que PV’s se encuentra la información que guarda el

sistema de archivos, como se muestra a continuación:
[root@pruebas /]# pvdisplay /dev/sdc

--- Physical volume ---
PV Name /dev/sdc
VG Name datos
PV Size 50.00 GiB / not usable 4.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 12799
Free PE 12799
Allocated PE 0
PV UUID EwppLh-MBOD-QS8E-1Dw9-GLUz-SIbV-R3y12d
[root@pruebas /]# pvdisplay /dev/sdd

PV Name /dev/sdd
VG Name datos
Allocatable yes
PE Size 4.00 MiB
Total PE 12799
Free PE 12599
Allocated PE 200
[root@pruebas /]# pvdisplay /dev/sde

PV Name /dev/sde
VG Name datos
Allocatable yes
PE Size 4.00 MiB
Total PE 12799
Free PE 12799
Allocated PE 0
PV UUID c20ezT-62lW-ULUx-DKyn-RdOu-gNYH-rk8i2p
En este caso podemos ver que cada disco de 50GiB tiene la capacidad de
guardar hasta 12799 PE, y solo el PV /dev/sdd tiene el campo “Allocated
PE” en 200, los PV’s /dev/sdc y /dev/sde tienen ese campo en 0, significa
que aun esos PV’s no han sido utilizados para guardar datos, por lo tanto
imagine que /dev/sdd es un disco que tiene problemas físicos, el sistema
Linux le permite mover esa data de ese PV (/dev/sdd) a otro PV del mismo
grupo de volúmenes, como se muestra a continuación:
[root@pruebas /]# pvmove /dev/sdd

/dev/sdd: Moved: 3.50%
/dev/sdd: Moved: 100.00%
El sistema ha permitido mover la data del PV /dev/sdd, note que no se le

proporcionó un PV destino, pero este comando “pvmove” le da la
posibilidad de hacerlo, sin embargo mover los datos fue hecho de forma
aleatoria, como se puede visualizar a continuación:
[root@pruebas /]# pvdisplay /dev/sdc

PV Name /dev/sdc
VG Name datos
Allocatable yes
PE Size 4.00 MiB
Total PE 12799
Free PE 12599
Allocated PE 200
PV UUID EwppLh-MBOD-QS8E-1Dw9-GLUz-SIbV-R3y12d
[root@pruebas /]# pvdisplay /dev/sdd

PV Name /dev/sdd
VG Name datos
Allocatable yes
PE Size 4.00 MiB
Total PE 12799
Free PE 12799
Allocated PE 0
[root@pruebas /]# pvdisplay /dev/sde
PV Name /dev/sde
VG Name datos
Allocatable yes
PE Size 4.00 MiB
Total PE 12799
Free PE 12799
Allocated PE 0
PV UUID c20ezT-62lW-ULUx-DKyn-RdOu-gNYH-rk8i2p
El campo “Allocated PE” está en valor 0 para los PV’s /dev/sdd y

/dev/sde ahora /dev/sdc es quien tiene la data del filesystem. Como se había
comentado en el apartado anterior, se dijo que /dev/sdd cuenta con
problemas físicos y que era necesario sacarlo de la estructura de LVM, para
ellos vamos a reducir el VG llamado “datos” aprovechando que la data que
había en el PV /dev/sdd se ha movido para otro PV dentro del mismo VG, tal
[root@pruebas /]# vgs datos

datos 3 1 0 wz--n- <149.99g <149.21g
[root@pruebas /]# pvs

/dev/sdb lvm2 --- 50.00g 50.00g
/dev/sdc datos lvm2 a-- <50.00g 49.21g
/dev/sdd datos lvm2 a-- <50.00g <50.00g
/dev/sde datos lvm2 a-- <50.00g <50.00g
Se visualiza que el VG “datos” cuenta con 3 PV’s, ahora vamos a

reducirlo a 2 PV’s, quitaremos /dev/sdd de la siguiente forma:
[root@pruebas /]# vgreduce datos /dev/sdd

Removed "/dev/sdd" from volume group "datos"
Se aprovecha para eliminar del sistema de PV’s al PV /dev/sdd:
[root@pruebas /]# pvremove /dev/sdd

Labels on physical volume "/dev/sdd" successfully wiped.
La carpeta /datos que es el punto de montaje hacia el filesystems XFS

que está asignado a /dev/datos/app1 no sufre con la operación que se acaba
de realizar, los datos continúan ahí:
[root@pruebas /]# ll /datos/

total 0
Se observa en el listado de PV’s que /dev/sdd ya no aparece como tal:

/dev/sdb lvm2 --- 50.00g 50.00g
/dev/sdc datos lvm2 a-- <50.00g 49.21g
/dev/sde datos lvm2 a-- <50.00g <50.00g
De la misma forma, al listar los VG’s del sistema es posible ver que el
VG “datos” solo es alimentado por 2 PV’s:
[root@pruebas /]# vgs

datos 2 1 0 wz--n- 99.99g 99.21g
rhel 1 2 0 wz--n- <49.00g 0
ELIMINANDO UNA ESTRUCTURA LVM
El ejercicio a continuación permitirá eliminar la estructura creada en las

secciones anteriores; se ha dicho que es una operación de riesgo por que los
datos que almacenan los filesystem asignados a los LV pueden tener valor,
es una operación bajo la responsabilidad del administrador Linux, que se
puede realizar de la siguiente forma:
Iniciamos desmontando el punto de montaje para seguidamente editar el

archivo /etc/fstab y quitar la línea correspondiente a /dev/datos/app1, como
[root@pruebas /]# umount /datos
[root@pruebas /]# vim /etc/fstab
[root@pruebas /]# systemctl daemon-reload
Se elimina el volumen lógico como se muestra a continuación:
[root@pruebas /]# lvremove /dev/datos/app1

Do you really want to remove active logical volume datos/app1?
[y/n]: y
Logical volume "app1" successfully removed
Habiendo borrado el LV, es posible eliminar el VG, tal como sigue:
[root@pruebas /]# vgremove datos

Volume group "datos" successfully removed
Por ultimo eliminamos los PV’s que estaban asociados al VG, tal como
sigue:
[root@pruebas /]# pvremove /dev/sdc /dev/sde

Labels on physical volume "/dev/sdc" successfully wiped.
Labels on physical volume "/dev/sde" successfully wiped.
Para verificar, se listan los LV’s, los VG’s y los PV’s del sistema, no
debe existir nada de lo previamente creado:
[root@pruebas /]# lvs
Cpy%Sync Convert

rhel 1 2 0 wz--n- <49.00g 0

/dev/sdb lvm2 --- 50.00g 50.00g
EXTENDIENDO LA SWAP BASADA EN LVM
Al momento de la instalación de los sistemas Linux, tanto la distribución

RHEL como otras definen un almacenamiento tipo LVM para la gestión. Es
así como se define que el espacio de intercambio del sistema se establece a
partir de un LV que es formado del particionamiento que se hace del disco,
[root@pruebas /]# fdisk -l /dev/sda

Disk /dev/sda: 50 GiB, 53687091200 bytes, 104857600 sectors
Disklabel type: dos
Disk identifier: 0x3a91d65d
Device Boot Start End Sectors Size Id Type

/dev/sda1 * 2048 2099199 2097152 1G 83 Linux
/dev/sda2 2099200 104857599 102758400 49G 8e Linux LVM
Como se puede observar, del dispositivo de bloques /dev/sda se han

generado dos particiones, una de ellas, /dev/sda2, ha sido declarada como
Linux LVM en el esquema MBR, a partir de ella se creó una estructura de
LVM como se muestra a continuación

/dev/sdb lvm2 --- 50.00g 50.00g

rhel 1 2 0 wz--n- <49.00g 0

Cpy%Sync Convert
Se puede identificar entonces que /dev/rhel/swap es el dispositivo virtual
(5GiB) donde reside el espacio de intercambio del sistema, dispositivo
virtual el cual es posible extender, utilizando el PV /dev/sdb (tiene 50 GiB);
el nuevo LV dedicado a la SWAP quedaría con 9 GiB; en este procedimiento
se extiende el VG llamado RHEL adicionando el PV /dev/sdb al volumen de
grupo, tal como se muestra a continuación:
[root@pruebas /]# lsblk

`-sda2 8:2 0 49G 0 part
|-rhel-root 253:0 0 44G 0 lvm /
sdb 8:16 0 50G 0 disk
Vemos a /dev/sdb como un dispositivo de 50GiB disponible y declarado

como un PV:

/dev/sdb lvm2 --- 50.00g 50.00g
Se extiende el VG llamado “rhel” con el PV /dev/sdb, tal como sigue:
[root@pruebas /]# vgextend rhel /dev/sdb

Volume group "rhel" successfully extended
Se puede apreciar entonces que se ha extendido el VG llamado “rhel” en

50GiB adicionales:

rhel 2 2 0 wz--n- 98.99g <50.00g
Es momento entonces de desactivar de forma provisional el espacio de

intercambio, como se muestra a continuación:
[root@pruebas /]# swapoff -v /dev/rhel/swap

Seguidamente se extiende en 1000 PE (4GiB) el LV que se utiliza para el
intercambio:
[root@pruebas /]# lvextend -l +1000 /dev/rhel/swap

Size of logical volume rhel/swap changed from 5.00 GiB (1280 extents) to <8.91 GiB (2280
extents).
Logical volume rhel/swap successfully resized.
Esta instrucción adiciona 4GiB al LV /dev/rhel/swap, pasa de tener 5GiB

a los casi 9GiB, como se muestra a continuación:

Cpy%Sync Convert
swap rhel -wi-a----- <8.91g
Una vez extendido el LV se procede a declarar a /dev/rhel/swap como

partición de intercambio, como sigue a continuación:
[root@pruebas /]# mkswap /dev/rhel/swap

mkswap: /dev/rhel/swap: warning: wiping old swap signature.
Setting up swapspace version 1, size = 8.9 GiB (9563009024 bytes)
no label, UUID=5801d33f-b3d7-4233-bf35-85db7d3d12db
Por último, se activa el LV como espacio de intercambio:
[root@pruebas /]# swapon -va /dev/rhel/swap

swapon: /dev/mapper/rhel-swap: found signature [pagesize=4096, signature=swap]
swapon: /dev/mapper/rhel-swap: pagesize=4096, swapsize=9563013120,
devsize=9563013120
swapon /dev/mapper/rhel-swap
swapon: /dev/mapper/rhel-swap: found signature [pagesize=4096, signature=swap]
swapon: /dev/mapper/rhel-swap: pagesize=4096, swapsize=9563013120,
devsize=9563013120
swapon /dev/mapper/rhel-swap
swapon: /dev/mapper/rhel-swap: swapon failed: Device or resource busy
Y se le consulta al sistema por lo que ve como espacio de intercambio:
[root@pruebas /]# cat /proc/swaps

CREANDO LV’s THIN
Los bloques en un volumen lógico (LV) estándar se asignan cuando se

crea el LV, pero los bloques en un LV tipo Thin se asignan a medida se
escriben, indiscutiblemente uno de los propósitos de los LV tipo Thin es el
ahorro en espacio en disco. El procedimiento para crear un LV Thin es el
siguiente:
1. Defina las PV’s de su estructura LVM

2. Cree un grupo de volúmenes
3. Cree un Thin Pool
4. Cree un Thin Volume
Aunque es posible realizar los pasos 3 y 4 en una única instrucción, esta

práctica se hará por separado para una mejor comprensión de la temática. Se
inicia declarando los PV’s para la estructura LVM:
[root@pruebas ~]# pvcreate /dev/sdc /dev/sdd /dev/sde

Physical volume "/dev/sdd" successfully created.
Seguidamente se crea el volumen de grupo con los PV’s previamente

declarados:
[root@pruebas ~]# vgcreate datos /dev/sdc /dev/sdd /dev/sde

Es momento de crear el LV tipo Pool, utilizando en él todos los extends

disponibles; este pool será llamado “pool” y a apartir de él se crearán los
LV’s a los que se les asignarán sistemas de archivos, como sigue a
continuación:
[root@pruebas ~]# lvcreate -l 100%FREE -T datos/pool

Thin pool volume with chunk size 128.00 KiB can address at most
31.62 TiB of data.
Logical volume "pool" created.
Se visualiza la creación del LV tipo pool:

Cpy%Sync Convert
pool datos twi-a-tz-- <149.84g 0.00 10.43
swap rhel -wi-ao---- <8.91g
Una vez definido el LV tipo pool se crean los LV’s a partir del pool, en
este caso se crearán tres (LV’s) para guardar los datos de tres aplicaciones
distintas; el primer LV será de un tamaño virtual de 100 GiB:
[root@pruebas ~]# lvcreate -V 100G -T datos/pool -n app2

Visualizamos el LV anteriormente creado y podemos observar que

“app2” se creó a partir del pool llamado “pool”, visualizándose también que
su consumo es de un 0% de la capacidad del pool:

LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
app2 datos Vwi-a-tz-- 100.00g pool 0.00
pool datos twi-aotz-- <149.84g 0.00 10.44
De igual forma se crean el LV’s “app3” con un tamaño de 10 GiB:
[root@pruebas ~]# lvcreate -V 10G -T datos/pool -n app3

Al listar los LV’s del sistema podemos ver que “app2”, “app3” y “app4”
son LV’s generados a partir del pool llamado “pool”, y ninguno de ellos está
consumiendo data:

Cpy%Sync Convert
pool datos twi-aotz-- <149.84g 0.00 10.45
Es momento entonces de asignar filesystems sobre estos nuevos LV’s

para poder ser usados y escribir datos sobre ellos:

meta-data=/dev/datos/app2 isize=512 agcount=16,
agsize=1638400 blks

meta-data=/dev/datos/app3 isize=512 agcount=16,
agsize=163840 blks
Para hacer persistentes en el inicio del sistema tomamos de cada

dispositivo de bloque virtual su identificador (UUID) y los adicionamos en
/etc/fstab para establecer la persistencia:

/dev/mapper/datos-app2: UUID="7fabcfee-40a7-4b09-b219-d289cf8a27e5"

/dev/mapper/datos-app3: UUID="0f99f018-6646-4752-8efb-0a9a4838fce0"
[root@pruebas ~]# echo 'UUID="7fabcfee-40a7-4b09-b219-

d289cf8a27e5" /datos/app2 xfs defaults 0 0' >> /etc/fstab
[root@pruebas ~]# echo 'UUID="0f99f018-6646-4752-8efb-

0a9a4838fce0" /datos/app3 xfs defaults 0 0' >> /etc/fstab
Como se ha modificado el archive /etc/fstab es necesario decirle a

SystemD que este cambio se ha efectuado:

Se crean los puntos de montaje para que cada aplicación escriba datos en
ellos:
[root@pruebas ~]# mkdir /datos/app2
[root@pruebas ~]# mkdir /datos/app3
Por último se realizan los montajes y si todo está bien no debemos

obtener ningún error por parte del sistema:
Para finalizar se verifican los puntos de montaje:

/dev/sr0 iso9660 8.9G 8.9G 0 100% /repo
/dev/mapper/datos-app2 xfs 100G 747M 100G 1% /datos/app2
Como se mencionó al inicio del procedimiento, una vez las aplicaciones

inicien a guardar datos en los puntos de montaje, se iniciará a usar los
bloques de disco, diferente a la declaración de un LV estándar, que asigna el
tamaño definido una vez es creado.
DESPLIEGUE DE RAID POR SOFTWARE
La implementación de un arreglo de discos tiene como objetivo
combinar varios dispositivos de almacenamiento en una sola única lógica
para lograr los objetivos de rendimiento o redundancia que nos permitan
respaldar los datos de una organización. El establecimiento de un arreglo de
dispositivos de bloque aparece en un servidor como una única unidad de
almacenamiento lógico la cual es susceptible de asignación de sistema de
archivos y montaje persistente.
El procedimiento que se va a desarrollar implica la integración de dos

dispositivos de bloque en un RAID tipo “mirror” (espejo o Nivel 1), aunque
existen diferentes tipos de RAID su implementación será realizada en
función de la alta disponibilidad de los datos utilizando los dispositivos de
bloque /dev/sdb y /dev/sdc los cuales se identifican de la siguiente manera:
[root@sr1 ~]# lsblk

`-sda2 8:2 0 49G 0 part
|-rhel-root 253:0 0 44G 0 lvm /
sdb 8:16 0 50G 0 disk
sdc 8:32 0 50G 0 disk
La utilidad “mdadm” ya instalada en RHEL permitirá crear el RAID 1

con los dispositivos de bloque anteriormente mencionados, como se muestra
a continuación:
[root@sr1 ~]# mdadm --create /dev/md0 --level=1 --raid-

devices=2 /dev/sdb /dev/sdc
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
Una vez definido el arreglo podemos detallar la información de los
discos nuevamente:
[root@sr1 ~]# lsblk

`-sda2 8:2 0 49G 0 part
|-rhel-root 253:0 0 44G 0 lvm /
sdb 8:16 0 50G 0 disk
`-md0 9:0 0 50G 0 raid1
sdc 8:32 0 50G 0 disk
`-md0 9:0 0 50G 0 raid1
Otra forma de visualizar con mayor detalle el arreglo que se acaba de

crear es el siguiente
[root@sr1 ~]# mdadm --detail /dev/md0

/dev/md0:
Version : 1.2
Creation Time : Thu Mar 25 17:50:15 2021
Raid Level : raid1
Array Size : 52395008 (49.97 GiB 53.65 GB)
Used Dev Size : 52395008 (49.97 GiB 53.65 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Thu Mar 25 17:50:32 2021

State : clean, resyncing
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : resync
Resync Status : 11% complete
Name : sr1.aptivalabs.net:0 (local to host sr1.aptivalabs.net)

UUID : 0f9bcfc4:31d10bb8:c3b56b36:c4c3d4e5
Events : 1
Number Major Minor RaidDevice State

0 8 16 0 active sync /dev/sdb
1 8 32 1 active sync /dev/sdc
El anterior es un resumen de la formación del RAID donde se puede

observar los dispositivos activos, el estatus de la sincronización de discos,
los discos que están fallando, etc; otra forma adicional de profundizar al
detalle la información del RAID es la siguiente:
[root@sr1 ~]# mdadm --examine /dev/sdb /dev/sdc

/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 0f9bcfc4:31d10bb8:c3b56b36:c4c3d4e5
Name : sr1.aptivalabs.net:0 (local to host sr1.aptivalabs.net)
Creation Time : Thu Mar 25 17:50:15 2021
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 104790016 sectors (49.97 GiB 53.65 GB)

Array Size : 52395008 KiB (49.97 GiB 53.65 GB)
Data Offset : 67584 sectors
Super Offset : 8 sectors
Unused Space : before=67432 sectors, after=0 sectors
State : active
Device UUID : 04d11205:fdc7cb7f:32964c59:e3f0512f
Update Time : Thu Mar 25 17:51:37 2021

Bad Block Log : 512 entries available at offset 136 sectors
Checksum : b6753589 - correct
Events : 5
Device Role : Active device 0

Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Con el dispositivo lógico ya formado es necesario asignar un sistema de

archivos para estructurar los datos en el arreglo de discos; el sistema de
archivos que se instala es el XFS:
[root@sr1 ~]# mkfs.xfs /dev/md0
meta-data=/dev/md0 isize=512 agcount=4, agsize=3274688 blks
= reflink=1
Es momento de crear el punto de montaje y establecer el montaje

persistente para el nuevo dispositivo lógico de almacenamiento:
[root@sr1 ~]# mkdir /mnt/raid1
[root@sr1 ~]# blkid | grep md0 >> /etc/fstab
Con el filtro de información realizado el archivo para montajes

persistente debe quedar como se muestra:
[root@sr1 ~]# vim /etc/fstab

UUID="c5999d31-5b62-41fd-a977-8b40668c1f08" /mnt/raid1 xfs defaults 0 0
Se notifica al sistema de los cambios realizados y se procede al montaje

del Sistema de archivos asignado al RAID creado:
[root@sr1 ~]# udevadm settle

[root@sr1 ~]# systemctl daemon-reload
[root@sr1 ~]# mount -a
Para finalizar se verifican los puntos de montajes dentro de los cuales

debe aparecer el dispositivo lógico de almacenamiento:
[root@sr1 ~]# df -hT

/dev/md0 xfs 50G 389M 50G 1% /mnt/raid1
El resultado del comando anterior permite observar que el tamaño del
RAID no es la suma de los dos discos que se usaron sino que se define el del
disco de menor tamaño, en este caso como los discos son de 50GB ese
mismo tamaño se define para el RAID.
Realizar RAID por Software es una alternativa a considerar frente al uso

de hardware costoso para tal fin, sin embargo debe tener presente que su
implementación implica el uso de recursos del sistema para sostener esta
funcionalidad, debido a esto los que definen que hardware de servidor
comprar tienen dentro de sus criterios de selección que los nuevos servidores
cuenten con esta funcionalidad en el hardware, obviamente esto implica un
adicional en el precio.
OPTIMIZACIÓN DEL ALMACENAMIENTO
CON STRATIS
Stratis es una solución de gestión de almacenamiento presentada en
RHEL 8. Stratis se ejecuta como un servicio que administra “pools” de
dispositivos de almacenamiento físico y crea y gestiona de forma
transparente filesystems que se crean a partir de estos pools. Una de las
características de Stratis es que varios sistemas de archivos pueden residir en
el mismo pool, compartiendo el espacio disponible.
Stratis utiliza metadatos almacenados para administrar pooles,

volúmenes y sistemas de archivos. Por lo tanto, los sistemas de archivos
creados por Stratis nunca deben formatearse o reconfigurarse
manualmente; Ellos deberían solo poder administrarse con las herramientas
y los comandos de Stratis. Configurar manualmente los sistemas de archivos
de Stratis podría causar la pérdida de esos metadatos e impedir que Stratis
reconozca los sistemas de archivos que tiene creados. Stratis de cada Pool
puede crear uno o más sistemas de archivos teniendo la posibilidad de crear
hasta 224 sistemas de archivos por pool.
La siguiente imagen muestra de forma grafica lo que representa la

conceptualización de Stratis:
Implementaremos a continuación un laboratorio para la comprensión de
esta utilidad de almacenamiento que presenta Red Hat desde la versión 8 del
sistema operativo Linux.
Empecemos por identificar el dispositivo de bloque que le presentaremos

a Stratis, en este caso se trabajará con el dispositivo /dev/sdf, el cual cuenta
con 100 GiB de almacenamiento, tal como se muestra a continuación:

`-sda2 8:2 0 49G 0 part
|-rhel-root 253:0 0 44G 0 lvm /
`-rhel-swap 253:1 0 8.9G 0 lvm [SWAP]
sdb 8:16 0 50G 0 disk
`-rhel-swap 253:1 0 8.9G 0 lvm [SWAP]
sdf 8:80 0 100G 0 disk
sr0 11:0 1 8.8G 0 rom /repo
Es necesario instalar Stratis, para ello haremos lo siguiente:
[root@pruebas ~]# yum -y install stratisd stratis-cli

Last metadata expiration check: 2:36:25 ago on Tue 02 Mar 2021 09:02:28 AM -05.
================================================================
========
Size
================================================================
========
Installing:
stratis-cli noarch 2.1.1-6.el8 rhel-8-for-x86_64-appstream-
rpms 75 k
stratisd x86_64 2.1.0-1.el8 rhel-8-for-x86_64-appstream-
rpms 1.4 M
python3-dbus-client-gen noarch 0.4-1.el8 rhel-8-for-x86_64-
appstream-rpms 26 k
python3-dbus-python-client-gen noarch 0.7-3.el8 rhel-8-for-x86_64-
appstream-rpms 28 k
python3-dbus-signature-pyparsing noarch 0.03-2.el8 rhel-8-for-x86_64-
appstream-rpms 19 k
python3-into-dbus-python noarch 0.06-2.el8 rhel-8-for-x86_64-
appstream-rpms 27 k
python3-justbases noarch 0.14-4.el8 rhel-8-for-x86_64-
appstream-rpms 46 k
python3-justbytes noarch 0.14-2.el8 rhel-8-for-x86_64-
appstream-rpms 43 k
python3-psutil x86_64 5.4.3-10.el8 rhel-8-for-x86_64-
python3-pyparsing noarch 2.1.10-7.el8 rhel-8-for-x86_64-baseos-
rpms 142 k
python3-semantic_version noarch 2.6.0-5.el8 rhel-8-for-x86_64-
appstream-rpms 30 k
Transaction Summary
=====================================================
Install 11 Packages

(8/11): python3-justbases-0.14-4.el8.noarch.rpm 87 kB/s | 46
kB 00:00
(9/11): stratisd-2.1.0-1.el8.x86_64.rpm 1.7 MB/s | 1.4
MB 00:00
(10/11): python3-justbytes-0.14-2.el8.noarch.rpm 133 kB/s |
43 kB 00:00
(11/11): python3-pyparsing-2.1.10-7.el8.noarch.rpm 450 kB/s |
142 kB 00:00
-----------------------------------------------------------------------------------------
Total 1.0 MB/s | 2.2 MB 00:02
Seguido a esta instalación es necesario habilitar el servicio para el

arranque del sistema y de forma inmediata, como se muestra:
[root@pruebas ~]# systemctl enable --now stratisd
[root@pruebas ~]# systemctl status stratisd

● stratisd.service - Stratis daemon
Loaded: loaded (/usr/lib/systemd/system/stratisd.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2021-03-02 11:42:16 -05; 9s ago
Docs: man:stratisd(8)
Main PID: 10628 (stratisd)
Memory: 1.2M
CGroup: /system.slice/stratisd.service
└─10628 /usr/libexec/stratisd --debug
Mar 02 11:42:16 pruebas.aptivalabs systemd[1]: Started Stratis daemon.

Mar 02 11:42:16 pruebas.aptivalabs stratisd[10628]: DEBUG libstratis::stratis::buff_log:
BuffLogger: pass_through: true
Mar 02 11:42:16 pruebas.aptivalabs stratisd[10628]: INFO stratisd: stratis daemon version
2.1.0 started
Mar 02 11:42:16 pruebas.aptivalabs stratisd[10628]: INFO stratisd: Using StratEngine
Mar 02 11:42:16 pruebas.aptivalabs stratisd[10628]: INFO
libstratis::engine::strat_engine::backstore::identify:
Mar 02 11:42:16 pruebas.aptivalabs stratisd[10628]: INFO stratisd: D-Bus API is
available
Se crea el pool de stratis basados en el dispositivo /dev/sdf:
[root@pruebas ~]# stratis pool create mypool /dev/sdf
[root@pruebas ~]# stratis pool list

Name Total Physical Properties
mypool 100 GiB / 45.66 MiB / 99.96 GiB ~Ca,~Cr
Es momento entonces de crear un filesystem sobre el pool llamado

“mypool”, llamaremos a ese filesystem “fs1” y lo listaremos:
[root@pruebas ~]# stratis fs create mypool fs1
[root@pruebas ~]# stratis fs list

Pool Name Name Used Created Device
UUID
mypool fs1 546 MiB Mar 02 2021 11:45 /stratis/mypool/fs1
713ad7cda3eb4d0288ca6993abc7efca
Ejecute un “blkid” para observar los atributos asociados a los

dispositivos de bloque, en este caso nos interesa /dev/sdf:

/dev/sdf: UUID="275dd5739bbe49ff8c22cfe91fffeba9"
POOL_UUID="a39bc2b16a7a4fd1b728e0310704c02d"
BLOCKDEV_SECTORS="209715200" BLOCKDEV_INITTIME="1614703435"
TYPE="stratis"
/dev/mapper/stratis-1-a39bc2b16a7a4fd1b728e0310704c02d-thin-fs-
713ad7cda3eb4d0288ca6993abc7efca: UUID="713ad7cd-a3eb-4d02-88ca-6993abc7efca"
Es necesario crear el punto de montaje para acceder a este filesystem

previamente creado:
[root@pruebas ~]# mkdir /mypool
Realizaremos el montaje persistente en /etc/fstab, para ello haremos lo

siguiente:
[root@pruebas ~]# echo 'UUID="713ad7cd-a3eb-4d02-88ca-

6993abc7efca" /mypool xfs defaults,x-systemd.requires=stratisd.service
0 0' >> /etc/fstab
Para el montaje en /mypool se le ha solicitado a SystemD iniciar en el

momento del arranque la unidad de servicio llamada “stratisd.service”, si
esta no está activada podría haber fallas en el inicio del sistema y enviarnos a
un modo de emergencia o rescate.
Si ha podido observar, hemos tomado el UUID del dispositivo llamado
/dev/mapper/stratis-1”---salida—omitida” el cual se ha creado como un
dispositivo de bloques virtual con sistema de archivos XFS. Es necesario
avisar a SystemD del cambio y realizar el montaje, luego revisar los puntos
de montaje, como se muestra a continuación:

Filesystem Type Size Used Avail
Use% Mounted on
/dev/mapper/stratis-1-a39bc2b16a7a4fd1b728e0310704c02d-thin-fs-
713ad7cda3eb4d0288ca6993abc7efca xfs 1.0T 7.2G 1017G 1% /mypool
Es entonces el directorio /mypool el punto de montaje del filesystem

creado vía Stratis. Al crear el filesystem de Stratis usted pudo notar que no
se especificó tamaño, es por que Stratis lo alimenta del Pool (en este caso
“mypool”) y los datos se escriben a disco a medida que se van generando,
muy parecido a los LV Thin.
SNAPSHOTS CON STRATIS
Una de las características de Stratis es poder generar instantáneas de sus

filesystems, como se explica en el siguiente procedimiento, aprovechando la
estructura creada previamente; copiaremos unos archivos al punto de
montaje /mypool:
[root@pruebas ~]# cp /etc/[a-f]* /mypool/
[root@pruebas ~]# ll /mypool/

total 184
-rw-r--r--. 1 root root 5214 Mar 2 12:11 DIR_COLORS.256color
-rw-r--r--. 1 root root 4618 Mar 2 12:11 DIR_COLORS.lightbgcolor
-rw-r--r--. 1 root root 16 Mar 2 12:11 adjtime
--- salida omitida --
Seguidamente se lista el filesystem de Stratis para observar sus

propiedades y estadística antes de crear el Snapshot:

UUID
mypool fs1 546 MiB Mar 02 2021 11:45 /stratis/mypool/fs1
713ad7cda3eb4d0288ca6993abc7efca
Se crea el snapshot del filesystem y se listan nuevamente los filesystems

de Stratis:
[root@pruebas ~]# stratis filesystem snapshot mypool fs1 fs1-snap

UUID
mypool fs1 546 MiB Mar 02 2021 11:45
/stratis/mypool/fs1 713ad7cda3eb4d0288ca6993abc7efca
mypool fs1-snap 546 MiB Mar 02 2021 12:15

/stratis/mypool/fs1-snap d8a5195a154d4d8688fcab8506c35e35
Para demostrar que el snapshot ha sido realizado de forma satisfactoria,

realizaremos un borrado de archivos (inician con la letra “a”) en el punto de
montaje del filesystem “fs1”, luego se montará el snapshot y se listará,
deberíamos ver los archivos eliminados en el punto de montaje del snapshot:
[root@pruebas ~]# ll /mypool/a*
-rw-r--r--. 1 root root 16 Mar 2 12:11 /mypool/adjtime
-rw-r--r--. 1 root root 1529 Mar 2 12:11 /mypool/aliases
-rw-r-----. 1 root root 12288 Mar 2 12:11 /mypool/aliases.db
-rw-r--r--. 1 root root 541 Mar 2 12:11 /mypool/anacrontab
-rw-r--r--. 1 root root 55 Mar 2 12:11 /mypool/asound.conf
-rw-r--r--. 1 root root 1 Mar 2 12:11 /mypool/at.deny
[root@pruebas ~]# rm -rf /mypool/a*
[root@pruebas ~]# ll /mypool/a*

ls: cannot access '/mypool/a*': No such file or directory
[root@pruebas ~]# mount /stratis/mypool/fs1-snap /mnt/
[root@pruebas ~]# ll /mnt/a*

-rw-r--r--. 1 root root 16 Mar 2 12:11 /mnt/adjtime
-rw-r--r--. 1 root root 1529 Mar 2 12:11 /mnt/aliases
-rw-r-----. 1 root root 12288 Mar 2 12:11 /mnt/aliases.db
-rw-r--r--. 1 root root 541 Mar 2 12:11 /mnt/anacrontab
-rw-r--r--. 1 root root 55 Mar 2 12:11 /mnt/asound.conf
-rw-r--r--. 1 root root 1 Mar 2 12:11 /mnt/at.deny
La salida de la ultima instrucción evidencia que el tomar el snapshot

guardó la data del filesystem “fs1”. Si usted asi lo desea, podría en /etc/fstab
hacer persistente este sistema de archivos generado a partir del snapshot.
Usted puede destruir los filesystem de Stratis y el pool creado

anteriormente de la siguiente forma:
[root@pruebas ~]# umount /mypool

[root@pruebas ~]# umount /mnt
[root@pruebas ~]# stratis filesystem destroy mypool fs1-snap
[root@pruebas ~]# stratis filesystem destroy mypool fs1
[root@pruebas ~]# nano /etc/fstab → elimine la línea agregada a
este archivo
OPTIMIZACIÓN DEL ALMACENAMIENTO
CON VDO
Se ha buscado con LV Thin y Stratis optimizar el almacenamiento en los
dispositivos de bloques adscritos al sistema. Red Hat Enterprise Linux 8 nos
propone entonces el uso de VDO como una herramienta adicional para
lograr el propósito de optimizar el espacio en disco, haciendo un
aprovisionamiento Thin y eliminando la duplicación de bloques de disco
además de ejecutar un proceso de compresión; VDO es un controlador
mapeador de dispositivos de Linux que reduce el uso de espacio de
almacenamiento en dispositivos de bloque y minimiza la replicación de
datos, ahorrando espacio en disco e incluso aumentando el rendimiento del
sistema.
El trabajo que hace VDO se resume en las siguientes actividades:
1. Filtra los bloques de datos que contienen solo ceros (0) y

registra la información de esos bloques solo en los metadatos.
2. La deduplicación elimina los bloques de datos redundantes.
3. La compresión es la última fase. El módulo del kernel kvdo

comprime los bloques de datos usando Compresión LZ4 y los
agrupa en bloques de 4 KB.
Los dispositivos lógicos que crea con VDO se denominan volúmenes

VDO. Los volúmenes de VDO son similares a particiones de disco puesto
que los puede formatear con el tipo de sistema de archivos que requiera y
montarlo como un sistema de archivos regular. También puede utilizar un
volumen VDO como un PV para generar la estructura de LVM. El
procedimiento para lograr estos beneficios sobre un dispositivo de bloque
(en este caso usaremos /dev/sdb) el siguiente:
[root@pruebas ~]# yum install -y vdo kmod-kvdo

Last metadata expiration check: 1:09:45 ago on Tue 02 Mar 2021 12:02:44 PM -05.
Package vdo-6.2.3.114-14.el8.x86_64 is already installed.
Package kmod-kvdo-6.2.3.114-74.el8.x86_64 is already installed.
Nothing to do.
Complete!
Se ha intentado instalar VDO sin embargo el sistema nos dice que las
herramientas ya están instaladas. Una de las formas que usted puede usar
para verificar si VDO está instalado en su sistema es preguntándole a
SystemD si tiene algo relacionado en sus unidades de servicio, como se
[root@pruebas ~]# systemctl list-units --type service | grep vdo

vdo.service loaded active exited VDO volume
services
Con la salida anterior podemos ver que SystemD tiene un servicio activo
llamado “vdo.service”, el cual, servicio que fue instalado con la instalación
del sistema. Se inicia entonces limpiando el dispositivo de bloque donde se
realizaran las acciones para luego crear el volumen de VDO llamado
“vdo1”:
[root@pruebas ~]# wipefs -a /dev/sdb
[root@pruebas ~]# vdo create --name vdo1 --device /dev/sdb --

vdoLogicalSize 50G
Creating VDO vdo1
The VDO volume can address 96 GB in 48 data slabs, each 2 GB.
It can grow to address at most 16 TB of physical storage in 8192 slabs.
If a larger maximum size might be needed, use bigger slabs.
Starting VDO vdo1
Starting compression on VDO vdo1
VDO instance 0 volume is ready at /dev/mapper/vdo1
[root@pruebas ~]# ll /dev/mapper/vdo1

lrwxrwxrwx. 1 root root 7 Mar 2 13:27 /dev/mapper/vdo1 -> ../dm-
9
[root@pruebas ~]# vdo list

vdo1
[root@pruebas ~]# vdo status --name=vdo1 | grep Deduplication

Deduplication: enabled
Se formatea el nuevo dispositivo creado sin descartar bloques en el

dispositivo:
[root@pruebas ~]# mkfs.xfs -K /dev/mapper/vdo1

meta-data=/dev/mapper/vdo1 isize=512 agcount=4, agsize=3276800 blks
= reflink=1
Es necesario crear el punto de montaje para el filesystem que se le asignó

al volumen de VDO:
[root@pruebas ~]# mkdir /vdo1
Se copia un archivo de unidad de SystemD en /etc/systemd/system/

llamado “vdo1.mount” para luego proceder en su edición:
[root@pruebas ~]# cp
/usr/share/doc/vdo/examples/systemd/VDO.mount.example
/etc/systemd/system/vdo1.mount
El archivo debe quedar como se detalla a continuación:
[Unit]
Description = Mount filesystem that lives on VDO
name = VDO.mount
Requires = vdo.service systemd-remount-fs.service
After = multi-user.target
Conflicts = umount.target
[Mount]
What = /dev/mapper/vdo1
Where = /vdo1
Type = xfs
Options = discard
[Install]
WantedBy = multi-user.target
El sistema en el arranque leerá el contenido de este archivo y hará el

montaje en /vdo1, sin embargo es necesario decirle a SystemD que habilite
el montaje de forma inmediata, como se muestra a continuación:
[root@pruebas ~]# systemctl enable --now vdo1.mount

Created symlink /etc/systemd/system/multi-user.target.wants/vdo1.mount →
/etc/systemd/system/vdo1.mount.
Usted podrá observar que se activan procesos del sistema en función de

VDO, como se muestra a continuación:
[root@pruebas ~]# ps -fe | grep vdo

root 6807 2 0 13:27 ? 00:00:00 [kvdo0:dedupeQ]
root 6808 2 0 13:27 ? 00:00:00 [kvdo0:journalQ]
root 6809 2 0 13:27 ? 00:00:00 [kvdo0:packerQ]
root 6810 2 0 13:27 ? 00:00:00 [kvdo0:logQ0]
root 6811 2 0 13:27 ? 00:00:00 [kvdo0:physQ0]
root 6812 2 0 13:27 ? 00:00:00 [kvdo0:hashQ0]
root 6814 2 0 13:27 ? 00:00:00 [kvdo0:bioQ0]
root 6815 2 0 13:27 ? 00:00:00 [kvdo0:bioQ1]
root 6816 2 0 13:27 ? 00:00:00 [kvdo0:bioQ2]
root 6818 2 0 13:27 ? 00:00:00 [kvdo0:bioQ3]
root 6819 2 0 13:27 ? 00:00:00 [kvdo0:ackQ]
root 6820 2 0 13:27 ? 00:00:00 [kvdo0:cpuQ0]
root 6821 2 0 13:27 ? 00:00:00 [kvdo0:cpuQ1]
root 6827 2 1 13:27 ? 00:00:13 [kvdo0:indexW]
root 6830 2 0 13:27 ? 00:00:00 [kvdo0:reader]
root 6832 2 0 13:27 ? 00:00:00 [kvdo0:reader]
root 6835 2 0 13:27 ? 00:00:00 [kvdo0:writer]
Si su escenario se lo permite, usted podría reiniciar su servidor Linux y
verificar realizando un “ps -fe” y detallando los procesos de VDO. Para ver
estadísticas iniciales de VDO usted podría realizar la siguiente operación:
[root@pruebas ~]# vdostats --hu

Device Size Used Available Use% Space saving%
/dev/mapper/vdo1 100.0G 4.1G 95.9G 4% 99%
Sin haber iniciado a utilizar esta funcionalidad, usted puede observar que
VDO está tomando 4.1G de espacio del almacenamiento. Observemos ahora
cuando se empiece a meter data en el punto de montaje del volumen de VDO
(/vdo1); crearemos un archivo de tamaño de 1G llamado “archivo” y lo
copiaremos a /vdo1, como se muestra a continuación:
[root@pruebas ~]# dd if=/dev/urandom of=/root/archivo

bs=1024 count=1000000
1000000+0 records in
1000000+0 records out
1024000000 bytes (1.0 GB, 977 MiB) copied, 6.32358 s, 162 MB/s
[root@pruebas ~]# ll -h
total 1016M
-rw-------. 1 root root 1.3K Dec 17 17:21 anaconda-ks.cfg
-rw-r--r--. 1 root root 977M Mar 2 13:49 archivo
Este archivo creado llamado “archivo” se copiará varias veces en /vdo1

con un nombre diferente, como se muestra a continuación:



[root@pruebas ~]# cp archivo /vdo1/a2
El archivo creado es de 1GB y teniendo en cuenta que VDO ya había

usado 4G sin haber copiado nada al punto de montaje, y que se copió el
mismo archivo con nombres distintos, se presume que el tamaño de la data
en /vdo1 es de 8GB (4GB de uso de VDO + 4GB por los 4 archivos en el
punto de montaje), sin embargo el sistema muestra algo como esto:
[root@pruebas ~]# du -sh /vdo1/

3.9G/vdo1/

Lo que ha pasado es que VDO tomó nota de que así los archivos tengan
nombres distintos representan la misma información, lo que la hace
susceptible de eliminación del bloque zero, eliminación de la deduplicación
y compresión de bloque.
IMPLEMENTANDO EL SERVICIO NFS
En esta sección vamos a detallar como hace un sistema RHEL 8 para
acceder a recursos compartidos en red a través del protocolo NFS, esto nos
lleva a desplegar un servicio NFS en un sistema externo (usted lo verá en
este lab identificado como el host 192.168.0.46). Quisiera mencionar que
este despliegue del servicio NFS está planteado de forma básica, solo con la
intención de exportar un recurso para que los sistemas RHEL puedan
acceder a él. Iniciemos entonces con la instalación y configuración del
servicio en el host externo (en mi caso el 192.168.0.46):
[root@s1 ~]# yum install nfs-utils -y
Se crea la carpeta /datos, como carpeta que será compartida con el host
RHEL:
[root@s1 ~]# mkdir /datos
[root@s1 ~]# chmod 777 /datos
Una vez instalado el servicio y definido el recurso a compartir es

necesario comunicarle a NFS cual recurso se va a compartir, esto se hace
editando el archivo /etc/exports, proporcionándole los datos de que se va a
compartir y con que seguridad, en este caso se adiciona una configuración
muy básica:
[root@s1 ~]# vim /etc/exports
/datos *(rw)
Es necesario entonces iniciar el servicio y decirle a FirewallD que reciba

conexiones de los servicios NFS, RPC Bind y Mountd, asi como se hace
necesario recargar las reglas del Firewall del sistema:
[root@s1 ~]# systemctl enable nfs-server.service --now
[root@s1 ~]# firewall-cmd --permanent --add-service=nfs

success
[root@s1 ~]# firewall-cmd --permanent --add-service=rpc-bind

success
[root@s1 ~]# firewall-cmd --permanent --add-service=mountd

success
[root@s1 ~]# firewall-cmd --reload

success
Desde el servidor externo está ya definida la configuración, /datos será

un recurso compartido vía NFS y sistemas remotos podrán acceder a él para
leer y escribir archivos.
MONTAJE TEMPORAL Y PERMANENTE – EN EL CLIENTE
Es momento de pasar a las actividades por parte del cliente NFS, en este
caso un host con RHEL 8 donde se realizarán montajes temporales y
permanentes del recurso compartido desde el host externo previamente
configurado como servidor NFS. Iniciamos entonces con el montaje
temporal, este tipo de montaje se pierde cuando el sistema se reinicia:
[root@pruebas ~]# mount -t nfs 192.168.0.46:/datos /mnt/
Hemos visto como el parámetro “-t” le indica a “mount” que el enlace de

filesystem viene de un sistema externo a través del protocolo NFS.
Detallemos entonces los puntos de montaje para evidenciar tal montaje
temporal:

192.168.0.46:/datos nfs4 44G 20G 25G 44% /mnt
Para realizar el montaje persistente, es necesario entonces agregar la

línea correspondiente en /etc/fstab, informar a SystemD, realizar el montaje
previo e identificar el punto de montaje asociado con el sistema remoto,
[root@pruebas ~]# echo '192.168.0.46:/datos /mnt nfs rw,soft 0 0'
>> /etc/fstab

192.168.0.46:/datos nfs4 44G 20G 25G 44% /mnt
Este montaje persistente está realizándose en /mnt, si usted crea un

archivo vacio en /mnt, en realidad lo está creando en el sistema remoto:
[root@pruebas ~]# cd /mnt/
[root@pruebas mnt]# touch 1
Ingrese al servidor externo y liste el contenido de la carpeta /datos:
[root@s1 ~]# cd /datos/
[root@s1 datos]# ll
total 0
-rw-r--r--. 1 nobody nobody 0 Mar 2 14:39 1
El listado en el sistema remoto muestra el archivo creado desde el RHEL

8 que en esta oportunidad está actuando como cliente del protocolo NFS.
MONTAJE POR AUTOFS - EN EL CLIENTE
Una forma de realizar montajes de NFS sin tener que realizar las
configuraciones anteriores resulta en usar AutoFS, para practicidad en la
explicación, usted simplemente se ubicará en un ruta del sistema y con eso
ya ha activado el montaje; se explica a continuación el procedimiento para
activar AutoFS en los sistemas RHEL:
[root@pruebas ~]# yum install autofs

Last metadata expiration check: 2:42:21 ago on Tue 02 Mar 2021 12:02:44 PM -05.
================================================================
=========
Size
================================================================
=========
Installing:
autofs x86_64 1:5.1.4-43.el8 rhel-8-for-x86_64-baseos-rpms
781 k
Transaction Summary
================================================================
=========
Install 1 Package

Is this ok [y/N]: y
autofs-5.1.4-43.el8.x86_64.rpm 739 kB/s | 781 kB
00:01
-------------------------------------------------------------------------------------------------------------
----------
Total 738 kB/s | 781 kB 00:01
Running transaction
Preparing : 1/1
Installing : autofs-1:5.1.4-43.el8.x86_64 1/1
Running scriptlet: autofs-1:5.1.4-43.el8.x86_64
1/1
Verifying : autofs-1:5.1.4-43.el8.x86_64 1/1
Installed:
autofs-1:5.1.4-43.el8.x86_64
Complete!
Una vez instalado es necesario editar el archivo /etc/auto.demo y

adicionar los datos del recurso externo; para este caso, se tiene estipulado
que cuando un usuario se ubique en /compartida/datos active la
comunicación con el servicio NFS, como se muestra:
[root@pruebas ~]# vim /etc/auto.demo
datos -rw,sync 192.168.0.46:/datos → adicionar esta línea
Crear la carpeta local para el montaje automático:
[root@pruebas ~]# mkdir /compartida
Editar el archivo del montaje automático:
[root@pruebas ~]# vim /etc/auto.master.d/datos.autofs

/compartida /etc/auto.demo → adicionar esta línea
Activar el servicio AutoFS de forma inmediata y persistente en el

arranque:
[root@pruebas ~]# systemctl enable --now autofs

Created symlink /etc/systemd/system/multi-user.target.wants/autofs.service →
/usr/lib/systemd/system/autofs.service.
Activar el servicio compartido accediendo al recurso, aprovechando para

listar el contenido del recurso:
[root@pruebas /]# cd compartida/datos
[root@pruebas datos]# ll
total 0
-rw-r--r--. 1 nobody nobody 0 Mar 2 14:39 1
Para finalizar, simplemente se lista los puntos de montaje para evidenciar

el montaje NFS con el sistema externo:
[root@pruebas datos]# df -hT

192.168.0.46:/datos nfs4 44G 20G 25G 44% /compartida/datos
RHEL 8 presenta una herramienta de configuración llamada “nfsconf”,

usted la podrá usar para configurar parámetros como la versión del protocolo
y demás, para mas información acerca de la herramienta puede digitar “man
nfsconf”.
AUTOMATIZACIÓN CON ANSIBLE
¿QUÉ ES ANSIBLE?
Ansible es una plataforma de automatización de código abierto. Ansible
puede gestionar potentes tareas de automatización y puede adaptarse a
muchos flujos de trabajo en ambientes diferentes. Ansible es simple, el
desarrollo de Playbooks de Ansible proporciona una automatización legible
por humanos. Esto significa que los Playbooks son fáciles de leer,
comprender y cambiar para los humanos, para lo cual se requieren
habilidades de codificación para escribirlos.
Ansible se basa en una arquitectura sin agentes. Normalmente, Ansible

se conecta a los hosts que administra mediante el uso de OpenSSH o
WinRM y ejecuta tareas implementando pequeños programas llamados
módulos Ansible en esos hosts. Estos programas se utilizan para poner el
sistema en un estado deseado específico. Todos los módulos que se insertan
se eliminan cuando Ansible termina con sus tareas. Puede comenzar a usar
Ansible casi de inmediato porque no es necesario que haya agentes
especiales para su uso y luego implementarlos en los hosts administrados.
Porque no hay agentes y no hay infraestructura de seguridad adicional,
Ansible es más eficiente y más seguro que otras alternativas.
ANSIBLE o RED HAT ANSIBLE
AUTOMATION?
Red Hat proporciona Ansible en diferentes modelos de despliegue, sin
embargo, si desea soporte formal para Ansible y sus módulos, Red Hat
ofrece una suscripción para esto, Red Hat Ansible Automation. Esta
suscripción incluye soporte para Ansible en sí, como Red Hat Ansible
Engine además de un soporte técnico formal con SLA.
INSTALACIÓN DE ANSIBLE – HOST DE
CONTROL
Si está utilizando la versión con soporte limitado proporcionada con su
Red Hat Enterprise Linux, utilice el siguiente procedimiento, iniciando con
la verificación de la instalación de la plataforma de Python:
[root@bd1 ~]# yum list installed platform-python

Installed Packages
platform-python.x86_64 3.6.8-23.el8
@anaconda
Actualice la información relacionada con su suscripción:
[root@bd1 ~]# subscription-manager refresh

All local data refreshed
Habilite el repositorio [ansible-2-for-rhel-8-x86_64-rpms] en

/etc/yum.repos.d/ para la posterior instalación de Ansible:
[root@bd1 ~]# subscription-manager repos --enable ansible-2-for-

rhel-8-x86_64-rpms
Repository 'ansible-2-for-rhel-8-x86_64-rpms' is enabled for this system.
En la interfaz grafica del RHEL verá lo siguiente en la aplicación que

gestiona las suscripciones:
O podría verificarlo de la siguiente forma:
[root@bd1 yum.repos.d]# subscription-manager list

+-------------------------------------------+
Installed Product Status
+-------------------------------------------+
Product Name: Red Hat Ansible Engine
Product ID: 408
Version: 2.9
Arch: x86_64
Status: Subscribed
Status Details:
Starts: 02/18/2021
Ends: 02/17/2022
Product Name: Red Hat Enterprise Linux for x86_64

Product ID: 479
Version: 8.3
Arch: x86_64
Status: Subscribed
Status Details:
Starts: 02/18/2021
Ends: 02/17/2022
A continuación, instale Ansible:

[root@bd1 ~]# yum install ansible
Red Hat Ansible Engine 2 for RHEL 8 x86_64 (RPMs)
1.1 MB/s | 1.8 MB 00:01
Installed:
ansible-2.9.19-1.el8ae.noarch python3-babel-2.5.1-5.el8.noarch python3-
jinja2-2.10.1-2.el8_0.noarch
python3-jmespath-0.9.0-11.el8.noarch python3-markupsafe-0.23-19.el8.x86_64
sshpass-1.06-3.el8ae.x86_64
Complete!
Para finalizar verique que Ansible esté instalado como se muestra a

continuación:
[root@bd1 ~]# ansible --version

ansible 2.9.19
config file = /etc/ansible/ansible.cfg
configured module search path = ['/root/.ansible/plugins/modules',
'/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.6/site-packages/ansible
executable location = /usr/bin/ansible
python version = 3.6.8 (default, Aug 18 2020, 08:33:21) [GCC 8.3.1 20191121 (Red Hat
8.3.1-5)]
Verifique ansible_python_version en el host local mediante el módulo de

configuración:
[root@bd1 ~]# ansible -m setup localhost | more

localhost | SUCCESS => {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"192.168.122.1",
"192.168.0.200"
],
"ansible_all_ipv6_addresses": [
"fe80::de85:641c:6cbb:8d7",
"fe80::5656:8910:c93f:4318"
],
"ansible_apparmor": {
"status": "disabled"
},
"ansible_architecture": "x86_64",
"ansible_bios_date": "04/01/2014",
"ansible_bios_version": "rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org",
"ansible_cmdline": {
"BOOT_IMAGE": "(hd0,msdos1)/vmlinuz-4.18.0-240.15.1.el8_3.x86_64",
"crashkernel": "auto",
"quiet": true,
"rd.lvm.lv": "rhel/swap",
"resume": "/dev/mapper/rhel-swap",
"rhgb": true,
"ro": true,
"root": "/dev/mapper/rhel-root"
},
ADMINISTRAR HOSTS
Uno de los beneficios de Ansible es que los hosts administrados no
necesitan tener un agente especial instalado. El nodo de control de Ansible
se conecta a los hosts administrados mediante el protocolo de red estándar
SSH para garantizar que los sistemas están en el estado especificado. Los
hosts administrados pueden tener algunos requisitos según cómo se conecte
el nodo de control hacia ellos y qué módulos se ejecutarán en ellos.
Los hosts administrados de Linux y UNIX deben tener Python 2 (versión

2.6 o posterior) o Python 3 (versión 3.5 o posterior) instalado para que la
mayoría de los módulos funcionen. Para Red Hat Enterprise Linux 8, es
posible que pueda depender del paquete platform-python, por lo tanto es
necesario que tal paquete se encuentre instalado:
[root@bd2 ~]# yum list installed platform-python

Installed Packages
platform-python.x86_64 3.6.8-31.el8
@anaconda
Es necesario habilitar e instalar el stream python36 como se muestra a

continuación:
[root@localhost ~]# yum module install python36

Last metadata expiration check: 0:49:15 ago on Tue 20 Oct 2020 10:46:16 AM EDT.
================================================================
==================================
Size
================================================================
==================================
python36/common
Transaction Summary
================================================================
==================================
Is this ok [y/N]: y
Complete!
Si SELinux está habilitado en los hosts administrados, también debe

asegurarse de que python3-libselinux se encuentre instalado antes de usar
módulos relacionados con cualquier función de copia, archivos o plantillas.
Tenga en cuenta que si los otros componentes de Python están instalados,
puede usar módulos de Ansible como “yum” o “package” para asegurarse de
que este paquete también esté instalado. En el host (en este caso un Linux
CentOS 8) que vaya a administrar por favor verifique de la siguiente manera:
[root@localhost ~]# yum info python3-libselinux

Installed Packages
Name : python3-libselinux
Version : 2.9
Release : 3.el8
Size : 874 k
Source : libselinux-2.9-3.el8.src.rpm
From repo : anaconda
Summary : SELinux python 3 bindings for libselinux
URL : https://github.com/SELinuxProject/selinux/wiki
License : Public Domain
Description : The libselinux-python3 package contains python 3 bindings for developing
: SELinux applications.
[root@localhost ~]# yum info python3-dnf

Installed Packages
Name : python3-dnf
Version : 4.2.17
Release : 7.el8_2
Architecture : noarch
Size : 1.7 M
Source : dnf-4.2.17-7.el8_2.src.rpm
From repo : BaseOS
Summary : Python 3 interface to DNF
URL : https://github.com/rpm-software-management/dnf
License : GPLv2+ and GPLv2 and GPL
Description : Python 3 interface to DNF.
GESTIÓN DE INVENTARIOS
Un inventario define un grupo de hosts que administrará Ansible. Estos
hosts también pueden ser asignados a grupos, que se pueden gestionar de
forma colectiva. Los grupos pueden contener grupos secundarios y los hosts
pueden ser miembros de varios grupos. El inventario también puede
establecer variables que se apliquen a los hosts y a los grupos que se definen.
Los inventarios se pueden definir de dos formas diferentes. Un

inventario de host estático se puede definir mediante un archivo de texto.
También es posible generar un inventario de host dinámico mediante un
script u otro programa según sea necesario, utilizando proveedores de
información externos ejemplo, utilizando modulos/scrips es posible listar el
inventario de instancias en AWS EC2.
INVENTARIOS ESTATICOS
Un archivo de inventario estático es un archivo de texto que especifica

los hosts administrados a los que se dirige Ansible. Usted puede escribir
este archivo utilizando varios formatos diferentes, incluido el estilo INI o
YAML. El estilo INI es el formato más común y se utilizará para la mayoría
de los ejemplos de esta documentación.
En su forma más simple, un archivo de inventario estático estilo INI es

una lista de nombres de host o direcciones IP de hosts administrados, cada
uno en una sola línea:
apache-spark-1.aptivalabs.net
postgresql.aptivalabs.net
192.168.0.54
Otro ejemplo de configuración puede ser visto en la siguiente opción:
[sparks]
[webservers]
nginx1. aptivalabs.net
[basesdedatos]
db1. aptivalabs.net
db2. aptivalabs.net
[desarrollo]
192.168.0.201
En esta configuración se ve como se crean los grupos de nodos y como

un nodo puede pertenecer a varios grupos. Ansible le permite crear grupos
de grupos tal como se muestra a continuación:
[webservers]
[basesdedatos]
db1. aptivalabs.net
db2. aptivalabs.net
[servidores:children]
webservers
basesdedatos
De igual forma es posible manejar rangos en los inventarios, como se

[webservers]
nginx[1:2]. aptivalabs.net
A continuación ingresaremos dos hosts para administrar en el archivo de

inventario estático; así quedará el archivo “/etc/ansible/hosts”:
[root@bd1 ~]# vim /etc/ansible/hosts
192.168.0.201
192.168.0.46
[servidores]
192.168.0.201
192.168.0.46
De la siguiente forma será posible listar los hosts del inventario:
[root@bd1 ~]# ansible all --list-hosts

hosts (2):
192.168.0.201
192.168.0.46
De la siguiente forma podemos listar los grupos que hacen parte del
inventario:
[root@bd1 ~]# ansible servidores --list-hosts

hosts (2):
192.168.0.201
192.168.0.46
El archivo “/etc/ansible/hosts” se considera el archivo de inventario

estático predeterminado del sistema. Sin embargo, la práctica normal es
no usar ese archivo, sino definir una ubicación diferente para los archivos
de inventario en su archivo de configuración de Ansible.
Los comandos ansible y ansible-playbook que se usan para ejecutar

comandos ad hoc de Ansible y playbooks también pueden especificar la
ubicación de un archivo de inventario en el comando línea con la opción -
-inventory PATHNAME o -i PATHNAME, donde PATHNAME es la ruta del
archivo de inventario deseado.
El comando ansible debe incluir la opción de inventario “-i”. Esto hace

que Ansible use su archivo de inventario que está en el directorio de trabajo
actual (CWD) en lugar de /etc/ansible/hosts; el ejemplo siguiente podemos
ver el archivo llamado “fm” en la carpeta personal del usuario “root”, en su
CWD, podemos ver que se está listado el inventario del CWD y no del
archivo /etc/ansible/hosts como se muestra a continuación:
[root@bd1 ~]# vim fm

192.168.0.201
192.168.0.46
[servidores]
192.168.0.201
192.168.0.46
[root@bd1 ~]# ansible -i fm servidores --list-hosts

hosts (2):
192.168.0.201
192.168.0.46
DESCRIPCIÓN DE UN INVENTARIO DINÁMICO
La información de inventario de Ansible también se puede generar

dinámicamente, utilizando la información proporcionada por bases de datos
externas. La comunidad de código abierto ha escrito una serie de scripts
para generar inventarios dinámicos que están disponibles en el proyecto
Ansible Upstream. Si esos scripts no cumplen con sus necesidades, también
puede escribir los suyos. Por ejemplo, un programa de inventario dinámico
podría ponerse en contacto con su cuenta de Amazon Webservices y utilizar
la información almacenada allí para construir un inventario de Ansible.
Debido a que el programa hace esto cuando ejecuta Ansible, puede
completar el inventario con información actualizada de los host agregados o
los host eliminados en AWS EC2.
ARCHIVOS DE CONFIGURACIÓN DE
ANSIBLE
El comportamiento de una instalación de Ansible se puede personalizar
modificando la configuración en el archivo de configuración de Ansible.
Ansible elige su archivo de configuración de varias ubicaciones posibles en
el nodo de control. Estas son las ubicaciones:
/etc/ansible/ansible.cfg → archivo por default donde Ansible lee su

configuración
~/.ansible.cfg → Ansible busca un archivo .ansible.cfg en el CWD

del usuario. Esta configuración se utiliza en lugar del archivo
/etc/ansible/ansible.cfg y si no hay un archivo ansible.cfg en el
directorio de trabajo actual (.).
./ansible.cfg
El orden de búsqueda de un archivo de configuración es el inverso de la

lista anterior. El primer archivo ubicado en el orden de búsqueda es el que
selecciona Ansible. Ansible solo usa los ajustes de configuración del primer
archivo que encuentra.
Cualquier archivo especificado por la variable de entorno

ANSIBLE_CONFIG anula todas los demás archivos de configuración. Si
esa variable no está configurada, el directorio en el que se ejecutó el
comando ansible es comprobado si hay un archivo ansible.cfg. Si ese
archivo no está presente, se verifica el directorio de inicio del usuario para
un archivo .ansible.cfg. El archivo global /etc/ansible/ansible.cfg solo se usa
si no hay otro se encuentra el archivo de configuración. Si el archivo de
configuración /etc/ansible/ansible.cfg no está presente, Ansible contiene los
valores predeterminados que utiliza. En resumen, la búsqueda se realiza con
la siguiente prioridades:
1. Verificación de variable ANSIBLE_CONFIG, sino está
configurada
2. Se comprueba el directorio donde se ejecutó el comando Ansible
(busca ansible.cfg)
3. Se comprueba en el CWD si existe “.ansible.cfg”, el archivo
está oculto
4. Si no encuentra archivos de configuración, Ansible utiliza el
archivo /etc/ansible/ansible.cfg
5. Si el archivo /etc/ansible/ansible.cfg no está presente, Ansible usa
una configuración por defecto.
Debido a la multitud de ubicaciones en las que se pueden colocar los

archivos de configuración de Ansible, es posible confundirse acerca de qué
archivo de configuración está utilizando Ansible.
La práctica recomendada es crear un archivo ansible.cfg en el

directorio desde donde se ejecutan los comandos de Ansible. Este directorio
también contendría los archivos utilizados por su proyecto Ansible, como un
inventario y un playbooks. Podemos ver que archivo de configuración se
está usando de la siguiente forma:

ansible 2.9.19
config file = /etc/ansible/ansible.cfg
[root@bd1 ~]# ansible servidores --list-hosts -v

Using /etc/ansible/ansible.cfg as config file
hosts (2):
192.168.0.201
192.168.0.46
Para comprobar la teoría anteriormente explicada se crea un archivo

oculto en “/root” llamado “ansible.cfg”, para luego verificar que archivo de
configuración está tomando Ansible:
[root@bd1 ~]# vim .ansible.cfg

ansible 2.9.19
config file = /root/.ansible.cfg
AJUSTES EN EL ARCHIVO DE CONFIGURACIÓN
El archivo de configuración de Ansible consta de varias secciones, y

cada sección contiene configuraciones definidos como pares clave-valor. Los
títulos de las secciones se incluyen entre corchetes. Para uso de operación
básica las siguientes dos secciones:
[defaults]
# some basic default values...
inventory = /etc/ansible/hosts → archivo de Inventario de Ansible
remote_user = root → El nombre del usuario para iniciar sesión en los hosts
administrados. Si no es especificado, se utiliza el nombre del usuario actual.
ask_pass = True → Si solicita o no una contraseña SSH. Puede ser falso si usa
autenticación de clave pública.
[privilege_escalation]
become = True → para convertirse de usuario de forma automática en el host administrado

una vez conectado.
become_method = sudo
become_user= root
become_ask_pass = False
En el siguiente ejemplo veremos como Ansible registra un archivo de

configuración diferente a los convencionales:
[root@bd1 ~]# mkdir ~/deploy-manage

[root@bd1 ~]# ll
total 16
drwxr-xr-x. 2 root root 6 Apr 2 09:05 deploy-manage
[root@bd1 ~]# cd deploy-manage/
[root@bd1 deploy-manage]# vim ansible.cfg

[root@bd1 deploy-manage]# cat ansible.cfg
[defaults]
inventory = ./inventory
[root@bd1 deploy-manage]# vim inventory

[root@bd1 deploy-manage]# cat inventory
[myself]
192.168.0.200
[servidores]
192.168.0.201
192.168.0.26
A continuación listaremos los host pertenecientes a los grupos de

Ansible:
[root@bd1 deploy-manage]# ansible myself --list-hosts

hosts (1):
192.168.0.200
[root@bd1 deploy-manage]# ansible --version

ansible 2.9.19
config file = /root/deploy-manage/ansible.cfg
executable location = /usr/bin/ansible
python version = 3.6.8 (default, Aug 18 2020, 08:33:21) [GCC 8.3.1 20191121 (Red Hat
8.3.1-5)]
A continuación agregaremos al archivo ansible.cfg los privilegios de

escalamiento:

[defaults]
become = true
become_user = root
become_ask_pass = true
[root@bd1 deploy-manage]# ansible servidores --list-hosts

BECOME password:
hosts (2):
192.168.0.201
192.168.0.46
Podemos ver como falla la sintaxis cuando salimos de la carpeta donde

se encuentran los archivos ansible.cfg e inventory personalizados:
[root@bd1 deploy-manage]# cd ..
[root@bd1 ~]# ansible servidores --list-hosts

[WARNING]: provided hosts list is empty, only localhost is available. Note that the
implicit localhost does not match 'all'
[WARNING]: Could not match supplied host pattern, ignoring: servidores
hosts (0):
COMANDOS AD-HOC
Un comando ad hoc es una forma de ejecutar una sola tarea de Ansible,
una que no necesita guardar información para ejecutarse de nuevo más tarde.
Son operaciones simples en línea que se pueden ejecutar sin escribir un
playbook.
Los comandos ad hoc son útiles para pruebas y cambios rápidos. Por
ejemplo, puede utilizar un comando ad-hoc para asegurarse de que existe
una determinada línea en el archivo /etc/hosts. Usted podría usar otro
comando ad-hoc para reiniciar de manera eficiente un servicio en muchas
máquinas diferentes, o para asegurarse de que un paquete de software en
particular esté actualizado.
La sintaxis para su uso es la siguiente:
ansible host-pattern -m module [-a 'module arguments'] [-i

inventory]
host-pattern → sobre que hosts se realiza la operación
-m module → modulo a usar. Los módulos son pequeños

programas que se ejecutan para implementar una tarea.
Ejemplo de uso:
[root@bd1 deploy-manage]# ansible servidores -m ping

BECOME password:
The authenticity of host '192.168.0.201 (192.168.0.201)' can't be established.
SHA256:ZfVcS9SS+4JXKQLTR3hQrcC4lSfSo17WgaQffxL9YYw.
Are you sure you want to continue connecting (yes/no/[fingerprint])? 192.168.0.46 |
UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: root@192.168.0.46: Permission denied
(publickey,gssapi-keyex,gssapi-with-mic,password).",
"unreachable": true
}
^C [ERROR]: User interrupted execution
Usted podría obtener ayuda para el uso de los módulos, como se muestra
a continuación:
[root@bd1 deploy-manage]# ansible-doc ping

> PING (/usr/lib/python3.6/site-packages/ansible/modules/system/ping.py)
A trivial test module, this module always returns `pong' on successful contact. It does not
make sense in playbooks, but it is useful from `/usr/bin/ansible' to verify the ability to login and
that a usable Python is configured. This is NOT ICMP ping, this is just a trivial test module that
requires Python on the remote-node. For Windows targets, use the [win_ping] module instead.
For Network targets, use the [net_ping] module instead.
La siguiente tabla lista algunos de los módulos de Ansible mas

utilizados:
CATEGORÍA MODULOS
copy: copia un archivo local en un host
administrado
file: establece permisos y propiedades sobre
Gestión de archivos
Archivos lineinfile: asegura que una línea esté o no en un
archivo
synchronize: sincroniza contenido usando
“rsync”
package: administración de paquetes
yum: administra paquetes usando yum
Gestión de apt: administra paquetes usando apt
Software dnf: administra paquetes usando dnf
gem: administra Ruby gems
pip: administra paquetes Python desde PyPI
firewalld: administra servicios y puetos con
FirewallD
Modulos del reboot: hace reboot en un host administrado
Sistema service: administra servicios en hosts
administrados
user: adiciona, remueve y administra usuarios
El siguiente comando adhoc nos permitirá hacer reboot en los nodos que
hagan parte del grupo CentOS:
[root@bd1 deploy-manage]# ansible servidores -m reboot

BECOME password:
Are you sure you want to continue connecting (yes/no/[fingerprint])? 192.168.0.46 |
UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: root@192.168.0.46: Permission denied
(publickey,gssapi-keyex,gssapi-with-mic,password).",
"unreachable": true
}
192.168.0.201 | UNREACHABLE! => {

"changed": false,
"msg": "Failed to connect to the host via ssh: Host key verification failed.",
"unreachable": true
}
CONEXIÓN A HOSTS ADMINISTRADOS
Hasta el momento hemos visto como tenemos respuestas no
satisfactorias al no habernos conectado con los nodos donde vamos a realizar
las pruebas y su documentación. Es la actividad que nos corresponde
adelantar como se verá a continuación, iniciando en el host de control con la
creación de las llaves públicas y privadas:
[root@bd1 deploy-manage]# ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:FWb7g5nYxNBKSIuZHcSgWPgOUcy7uzmHOOxQ5tt5gyo
root@bd1.aptivalabs.net
The key's randomart image is:
+---[RSA 3072]----+
| =o .=+...+ |
|ooo. =oo.=.o |
|.o..+ o. .= |
|. o .= = |
| oo. S = o |
| +o . |
|o..o . |
|E.++o.o |
|.+==o. . |
+----[SHA256]-----+
Es momento de copiar esta llave pública en los hosts a administrar, en

este caso el host 192.168.0.201 (RHEL 8.3) y el host 192.168.0.46 (Oracle
Linux):
[root@bd1 deploy-manage]# cd /root/.ssh/
[root@bd1 .ssh]# ssh-copy-id -i id_rsa.pub root@192.168.0.201

Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

[root@bd1 .ssh]# ssh 'root@192.168.0.201'

Web console: https://bd2.aptivalabs.net:9090/ or https://192.168.0.201:9090/
Last login: Fri Apr 2 08:09:57 2021 from 192.168.0.35
[root@bd2 ~]# exit

logout
Se agrega llave pública en el host Oracle Linux (192.168.0.46):
[root@bd1 .ssh]# ssh-copy-id -i id_rsa.pub root@192.168.0.46


[root@bd1 .ssh]# ssh 'root@192.168.0.46'

Web console: https://s1.ora-aptivalabs:9090/ or
https://192.168.0.46:9090/
[root@s1 ~]# exit

logout
Utilizando la ruta “/root/deploy-manage” donde previamente se definió
un archivo de configuración (ansible.cfg) y un archivo de inventario
(inventory), validaremos la conexión a los hosts administrados:
[root@bd1 ~]# cd deploy-manage/

BECOME password:
192.168.0.201 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/libexec/platform-python"
},
"changed": false,
"ping": "pong"
}
192.168.0.46 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3.6"
},
"changed": false,
"ping": "pong"
}
Con el siguiente comando ad-hoc podemos reiniciar los hosts que hagan
parte del grupo “servidores”:
[root@bd1 deploy-manage]# ansible servidores -m reboot

BECOME password:
192.168.0.201 | CHANGED => {
"changed": true,
"elapsed": 39,
"rebooted": true
}
192.168.0.46 | CHANGED => {
"changed": true,
"elapsed": 136,
"rebooted": true
}
La anterior salida se dá cuando los hosts del grupo “servidores” han

reiniciado de forma satisfactoria.
En el archivo de configuración ansible.cfg hemos cambiado el parámetro

become_ask_pass a “false” para que no nos solicite contraseña cuando se realice
la conexión con el host a administrar, como se muestra a continuación:
[defaults]
become = true
become_user = root
become_ask_pass = false
Una vez realizado estos pasos es posible utilizar el modulo “ping” para
comprobar la conectividad:

192.168.0.201 | SUCCESS => {
"ansible_facts": {
},
"changed": false,
"ping": "pong"
}
En los ejercicios anteriores se está utilizando el grupo “servidores” para

realizar las demostraciones necesarias para el entendimiento de este
material. Algunos otros ejemplos de comandos ad-hoc son los siguientes:
[root@bd1 deploy-manage]# ansible localhost -m command -a

'id'
localhost | CHANGED | rc=0 >>
uid=0(root) gid=0(root) groups=0(root)
Para conocer los repositorios de los hosts que hacen parte del grupo
“servidores” se ejecuta la siguiente instrucción:
[root@bd1 deploy-manage]# ansible servidores -m command -a

'yum repolist'
192.168.0.46 | CHANGED | rc=0 >>
repo id repo name
ol8_UEKR6 Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8
(x86_64)
ol8_appstream Oracle Linux 8 Application Stream (x86_64)
ol8_baseos_latest Oracle Linux 8 BaseOS Latest (x86_64)
192.168.0.201 | CHANGED | rc=0 >>

repo id repo name
anydesk AnyDesk RHEL - stable
pgdg-common PostgreSQL common RPMs for RHEL/CentOS 8 - x86_64
pgdg10 PostgreSQL 10 for RHEL/CentOS 8 - x86_64
pgdg95 PostgreSQL 9.5 for RHEL/CentOS 8 - x86_64
rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for x86_64 - AppStream
(RPMs)
(RPMs)
Para conocer las interfaces de red de los hosts que hacen parte del grupo
“servidores” se ejecuta la siguiente instrucción:

'ip add'
192.168.0.201 | CHANGED | rc=0 >>
link/ether ae:8e:38:26:26:6a brd ff:ff:ff:ff:ff:ff
192.168.0.46 | CHANGED | rc=0 >>

link/ether ae:36:da:5f:c9:47 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.46/24 brd 192.168.0.255 scope global dynamic noprefixroute ens18
Para conocer el estado de SELinux de los hosts que hacen parte del
grupo “servidores” se ejecuta la siguiente instrucción:

'getenforce'
192.168.0.201 | CHANGED | rc=0 >>
Enforcing
192.168.0.46 | CHANGED | rc=0 >>
Enforcing
El siguiente ejemplo muestra el uso del modulo “copy” con un parámetro

para agregar contenido en los hosts administrados:
[root@bd1 deploy-manage]# ansible servidores -m copy -a

'content="Aptiva Labs - Administrado desde Ansible\n"
dest=/etc/motd'
192.168.0.201 | CHANGED => {
"ansible_facts": {
},
"changed": true,
"checksum": "1dabfd531c204faeffcfe36d1ffe7e7775ffeb03",
"dest": "/etc/motd",
"gid": 0,
"group": "root",
"md5sum": "4916b78d0d7f5a17235bd47bd5b7d799",
"mode": "0644",
"owner": "root",
"secontext": "system_u:object_r:etc_t:s0",
"size": 41,
"src": "/root/.ansible/tmp/ansible-tmp-1617376706.4926713-11421-
102531044825571/source",
"state": "file",
"uid": 0
}
Verificando en uno de los hosts remotos al realizar un “login” en el

sistema nos muestra el siguiente resultado:
$ ssh -l root 192.168.0.201

Aptiva Labs - Administrado desde Ansible

[root@bd2 ~]#
ANSIBLE PLAYBOOKS
Los comandos ad-hoc pueden ejecutar una sola tarea simple contra un
conjunto de hosts específicos una sola vez. Sin embargo, el verdadero poder
de Ansible está en aprender a usar los playbooks para ejecutar múltiples
tareas complejas contra un conjunto de hosts específicos de una manera
repetible.
Un playbook es un conjunto ordenado de tareas que se ejecutan contra

los hosts del inventario. Un playbook es un archivo de texto que contiene
una lista de una o más tareas para ejecutar en un orden específico. Los
playbooks le permiten cambiar un conjunto largo y complejo de tareas
administrativas manuales por una rutina repetible con resultados predecibles
y exitosos. En un playbook puede guardar la secuencia de tareas en una
forma legible por humanos. Las tareas documentan los pasos necesarios para
implementar su aplicación o infraestructura.
Un playbook es un archivo de texto escrito en formato YAML y

normalmente se guarda con la extensión “yml”. Los playbooks usan sangría
con caracteres de espacio para indicar la estructura de sus datos. YAML NO
impone requisitos estrictos sobre cuántos espacios se utilizan para la sangría,
pero hay dos reglas básicas:
Los elementos de datos del mismo nivel en la jerarquía deben

tener la misma identación.
Los elementos que son hijos de otros elementos deben tener
más identación que sus padres.
Veremos como la siguiente instrucción Ansible puede ser llevada a un

Playbook:
[root@bd1 deploy-manage]# ansible servidores -m user -a

"name=newbie uid=4000 state=present"
192.168.0.46 | CHANGED => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3.6"
},
"changed": true,
"comment": "",
"create_home": true,
"group": 4000,
"home": "/home/newbie",
"name": "newbie",
"shell": "/bin/bash",
"state": "present",
"system": false,
"uid": 4000
}
192.168.0.201 | CHANGED => {
"ansible_facts": {
},
"changed": true,
"comment": "",
"create_home": true,
"group": 4000,
"home": "/home/newbie",
"name": "newbie",
"shell": "/bin/bash",
"state": "present",
"system": false,
"uid": 4000
}
[root@bd2 ~]# tail -f /etc/passwd

newbie:x:4000:4000::/home/newbie:/bin/bash
[root@s1 ~]# tail -f /etc/passwd

Solo se puede usar el carácter de espacio para la identación; el carácter

de tabulación no es permitido. Crearemos un Playbook equivalente y lo
ejecutaremos, el archivo se llamará prueba.yml:
Para ejecutar el playbook haga como sigue:
[root@bd1 deploy-manage]# ansible-playbook prueba.yml

PLAY [Configure important user consistently]
*****************************************************************************
*********************
TASK [Gathering Facts]

*****************************************************************************
*********************
ok: [192.168.0.46]
ok: [192.168.0.201]
TASK [aptivalabs exists with UID 4001]

*****************************************************************************
*********************
changed: [192.168.0.46]
changed: [192.168.0.201]
PLAY RECAP
*****************************************************************************
*********************
192.168.0.201 : ok=2 changed=1 unreachable=0 failed=0 skipped=0
rescued=0 ignored=0
rescued=0 ignored=0
Podemos observar el resultado de la ejecución del anterior Playbook en

el servidor Oracle Linux como se muestra a continuación:
[root@s1 ~]# tail -f /etc/passwd

aptivalabs:x:4001:4001::/home/aptivalabs:/bin/bash
A continuación se presenta un playbook que hace un reboot de los nodos

de un grupo:
[root@bd1 deploy-manage]# cat prueba.yml

---
- name: genera un reboot en cada uno de los nodos del grupo
hosts: servidores
tasks:
- name: aptivalabs reboot de servidores
reboot:

*****************************************************************************
*****************

*****************************************************************************
*********************
ok: [192.168.0.46]
ok: [192.168.0.201]
TASK [reboot de los host del grupo servidores]

***************************************************
changed: [192.168.0.201]
changed: [192.168.0.46]
PLAY RECAP
*****************************************************************************
*********************
rescued=0 ignored=0
rescued=0 ignored=0
En el siguiente playbook podemos ver el uso de dos módulos (ping y

reboot) en un solo playbook, tal como se muestra a continuación
[root@bd1 deploy-manage]# cat prueba.yml

---
- name: genera un ping y un reboot en cada uno de los nodos del
grupo
hosts: servidores
tasks:
- name: ping a servidores
ping:
- name: reboot de servidores
reboot:

*****************************************************************************
*****************

*****************************************************************************
*********************
ok: [192.168.0.201]
ok: [192.168.0.46]
TASK [ping a servidores]

*****************************************************************************
*********************
ok: [192.168.0.201]
ok: [192.168.0.46]
TASK [reboot de servidores]

*****************************************************************************
*********************
changed: [192.168.0.46]
changed: [192.168.0.201]
PLAY RECAP
*****************************************************************************
*********************
rescued=0 ignored=0
rescued=0 ignored=0
A continuación veremos un playbook que instala unos servicios y los

activa en el momento del incio de los nodos administrados:
[root@bd1 deploy-manage]# cat servicios.yml

---
- name: manejo de servicios
hosts: servidores
tasks:
- name: instala la última version de Apache

yum:
name: httpd
state: latest
- name: web server is enabled

service:
name: httpd
enabled: true
- name: NTP server is enabled

service:
name: chronyd
enabled: true
- name: Postfix is enabled

service:
name: postfix
enabled: true
[root@bd1 deploy-manage]# ansible-playbook servicios.yml

PLAY [manejo de servicios]
*****************************************************************************
*********************

*****************************************************************************
*********************
ok: [192.168.0.201]
ok: [192.168.0.46]
TASK [instala la ultima versión de Apache]

*****************************************************************************
******************
changed: [192.168.0.46]
changed: [192.168.0.201]
TASK [web server is enabled]
*****************************************************************************
*********************
changed: [192.168.0.46]
changed: [192.168.0.201]
TASK [NTP server is enabled]

*****************************************************************************
*********************
ok: [192.168.0.46]
ok: [192.168.0.201]
TASK [Postfix is enabled]

*****************************************************************************
*********************
fatal: [192.168.0.46]: FAILED! => {"changed": false, "msg": "Could not find the
requested service postfix: host"}
fatal: [192.168.0.201]: FAILED! => {"changed": false, "msg": "Could not find the
requested service postfix: host"}
PLAY RECAP
*****************************************************************************
*********************
rescued=0 ignored=0
rescued=0 ignored=0
La anterior salida nos detalla el uso de los módulos “yum” y “service”;

se puede observar también la falla que presenta cuando se trata de activar el
servicio “postfix” , el cual no se encuentra instalado en ninguno de los
servidores.
VERIFICACIÓN DE SINTAXIS Y VERBOSIDAD
Ansible le permite verificar la sintaxis de los playbooks antes de

ejecutarlos, como se muestra a continuación:
[root@bd1 deploy-manage]# ansible-playbook --syntax-check

servicios.yml
playbook: servicios.yml
Ansible le permite aumentar la verbosidad en la salida de los resultados

de la ejecución de los playbooks, como se muestra a continuación:
[root@bd1 deploy-manage]# ansible-playbook servicios.yml -

vvvvvv
ansible-playbook 2.9.14
config file = /root/deploy-manage/ansible.cfg
executable location = /usr/bin/ansible-playbook
python version = 3.6.8 (default, Dec 5 2019, 15:45:45) [GCC 8.3.1 20191121 (Red Hat 8.3.1-
5)]
Using /root/deploy-manage/ansible.cfg as config file
setting up inventory plugins
host_list declined parsing /root/deploy-manage/inventory as it did not pass its verify_file()
method
script declined parsing /root/deploy-manage/inventory as it did not pass its verify_file()
method
auto declined parsing /root/deploy-manage/inventory as it did not pass its verify_file()
method
Parsed /root/deploy-manage/inventory inventory source with ini plugin
Loading callback plugin default of type stdout, v2.0 from /usr/lib/python3.6/site-
packages/ansible/plugins/callback/default.py
PLAYBOOK: servicios.yml
*****************************************************************************
*************
Positional arguments: servicios.yml
ENSAYO DE PLAYBOOKS
Puede usar la opción -C para realizar un ensayo de la ejecución de un

playbook y asi saber que esperar en la ejecución real, como se muestra a
continuación:
[root@bd1 deploy-manage]# ansible-playbook prueba.yml -C

PLAY [genera un reboot en cada uno de los nodos del grupo]
*********************************************

*****************************************************************************
****
ok: [192.168.0.201]
ok: [192.168.0.46]
TASK [hace un ping]

*****************************************************************************
****
ok: [192.168.0.201]
ok: [192.168.0.46]
TASK [reboot]
*****************************************************************************
****
changed: [192.168.0.201]
changed: [192.168.0.46]
PLAY RECAP
*****************************************************************************
****
rescued=0 ignored=0
rescued=0 ignored=0
IMPLEMENTANDO MULTIPLES PLAYS EN UN PLAYBOOK
El siguiente ejemplo muestra un playbook con dos plays:
[root@bd1 deploy-manage]# cat tercero.yml
---
- name: Primer Juego
hosts: 192.168.0.46
tasks:
- name: primera tarea
yum:
name: postfix
state: latest
- name: segunda tarea

service:
name: postfix
enabled: true
- name: tercera tarea

service:
name: postfix
daemon_reload: true
- name: Segundo Juego

hosts: 192.168.0.201
tasks:
- name: primera tarea

yum:
name: mariadb
state: latest
- name: segunda tarea

service:
name: mariadb
daemon_reload: true
A continuación se muestra la ejecución del Playbook:
[root@bd1 deploy-manage]# ansible-playbook tercero.yml

PLAY [Primer Juego]
*****************************************************************************
*********************

*****************************************************************************
*********************
[WARNING]: Platform linux on host 192.168.0.46 is using the discovered Python
interpreter at /usr/bin/python3.6, but future installation
of another Python interpreter could change this. See
https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html
for more information.
ok: [192.168.0.46]
TASK [primera tarea]

*****************************************************************************
*********************
changed: [192.168.0.46]
TASK [segunda tarea]

*****************************************************************************
*********************
changed: [192.168.0.46]
TASK [tercera tarea]

*****************************************************************************
*********************
ok: [192.168.0.46]
PLAY [Segundo Juego]

*****************************************************************************
*********************

*****************************************************************************
*********************
ok: [192.168.0.201]
TASK [primera tarea]

*****************************************************************************
*********************
changed: [192.168.0.201]
TASK [segunda tarea]
*****************************************************************************
*********************
ok: [192.168.0.201]
PLAY RECAP
*****************************************************************************
*********************
rescued=0 ignored=0
rescued=0 ignored=0
Es importante mencionar que dentro de un playbook se puede definir un

escalamiento de usuarios y privilegios como se presenta a continuación:
---
- name: /etc/hosts is up to date
hosts: servidores
remote_user: automation
become: yes
tasks:
- name: server.example.com in /etc/hosts

lineinfile:
path: /etc/hosts
line: '192.168.0.46 server.example.com server'
state: present
DOCUMENTACIÓN DE MODULOS
En párrafos anteriores pudimos ver como encontrar ayuda para un
módulo, de esta forma es posible listar los módulos de Ansible:
[root@bd1 deploy-manage]# ansible-doc -l

a10_serverManage A10 Networks AX/SoftAX/Thunder/vThunder devices' server object
a10_server_axapi3 Manage A10 Networks AX/SoftAX/Thunder/vThunder devices
a10_service_group Manage A10 Networks AX/SoftAX/Thunder/vThunder devices' service groups
a10_virtual_serverManage A10 Networks AX/SoftAX/Thunder/vThunder devices' virtual servers
aci_aaa_user Manage AAA users (aaa:User)
Usted podrá usar el parámetro -s para ver ejemplos de como se usa un

módulo de Ansible, tal como se muestra a continuación:
[root@bd1 deploy-manage]# ansible-doc -s yum

- name: Manages packages with the `yum' package manager
yum:
allow_downgrade: # Specify if the named package and version is allowed to
downgrade a maybe already installed higher version of that package. Note that setting
allow_downgrade=True can make this module
MIX DE LABORATORIOS
RECUPERANDO EL ACCESO COMO USUARIO “root”
El tener que llegar a recuperar la contraseña del usuario “root” es un

evento desafortunado pero que tiene un procedimiento definido para tal fin.
Recuperar la contraseña del usuario “root” es algo fácil de hacer cuando el
administrador del sistema se encuentra aun “logeado” en consola o desde
cualquier tipo de terminal; diferente es el caso cuando aun no se ha
ingresado al sistema y se requiere ejecutar labores de administración.
Cuando el GRUB2 le invite a escoger un kernel a iniciar, usted debe

detener el proceso de inicio del kernel por defautl presionando cualquier
tecla en el teclado; con las teclas de posicicionamiento (“flechas”), escogerá
el kernel a ejecutar, en este ejemplo se escoge el “4.18.0-240.15.1”; una vez
escogido se presiona la letra “e”, como lo indica el menú en parte de abajo:
Una vez presionada la letra “e” (edición), ubique la línea con la palabra
“linux” como primera palabra de una línea; desplácese hacia el final de esa
línea y agregue un espacio , como se muestra a continuación:
Esta es la línea donde se le envían parámetros al kernel. Ubíquese hasta

el final de esa línea y adicione la expresión “rd.break” para iniciar en modo
consola. Al final presione CTRL + X para bootear.
Una vez el sistema ha booteado, Linux nos ha dejado en un prompt

similar al de la siguiente imagen:
En este momento el sistema de archivos estándar está montado sobre

/sysroot en forma de solo lectura lo que hace necesario realizar cambios para
remontar en modo de lecto-escritura, de la siguiente forma:
Es necesario hacer un Jail (enjaulamiento del sistema de archivos, para
que nadie moleste al mismo mientras se ejecuta la operación) del sistema de
archivos del root (/sysroot) para luego si cambiar el password del
administrador.
Es necesario crear el archivo vacio “/.autorelabel”. Seguido a esto es

necesario salir del modo donde estuvimos (chroot y modo GRUB)
escribiendo dos veces “exit”:
Esto inmediatamente hará que el sistema reinicie, donde inicialmente

SELinux hará el trabajo de re-etiquetar los contextos correspondientes donde
corresponda (archivos, directorios, puertos y procesos), si es que esta
funcionalidad del sistema operativo está habilitada.
VOLCADO DE DATA DEL KERNEL PARA
ANÁLISIS POSTERIOR
Para analizar por qué falló un sistema, puede utilizar el servicio kdump
para guardar el contenido de la memoria del sistema para un análisis
posterior. En esta sub sección veremos una breve introducción a kdump
mediante la Consola web RHEL.
Kdump es un servicio que provee un mecanismo de volcado de datos

ante fallas del kernel. El servicio permite guardar el contenido de la
memoría. Kdump usa el system call kexec para bootear dentro de un
segundo kernel sin hacer un reboot, capturando asi el contenido del kernel en
falla y salvar la data para el análisis. El segundo kernel reside en una parte
reservada de la memoria.
Un volcado por caída del kernel puede ser la única información

disponible en caso de una falla del sistema (un error crítico), por lo tanto,
asegurar que kdump esté operativo es importante en ambientes de misión
crítica.
El procedimiento a continuación le muestra cómo usar la pestaña Kernel

Dump en la herramienta Cockpit para configurar la cantidad de memoria
reservada para el kernel kdump. El procedimiento también describe cómo
especificar la ubicación de destino del archivo de volcado de vmcore y cómo
probar su configuración.
Una vez registrados en Cockpit se procede a ir a sección del Kernel
Dump:
A través de las siguientes instrucciones se puede observar el resultado de
este volcado de prueba (se presionó en el botón “Test Configuration”)
[root@pruebas ~]# cd /var/crash/

total 0
drwxr-xr-x. 2 root root 44 Feb 20 11:53 127.0.0.1-2021-02-20-09:53:46
Como se detalla, el volcado generó una carpeta con la dirección IP de

localhost y la fecha y hora cuando se originó la caída simulada. Entraremos
en esa carpeta y observaremos su contenido, como se muestra a
continuación:
[root@pruebas ~]# cd 127.0.0.1-2021-02-20-09\:53\:46/
[root@pruebas 127.0.0.1-2021-02-20-09:53:46]# ll -h
total 172M
-rw-------. 1 root root 172M Feb 20 11:53 vmcore
-rw-r--r--. 1 root root 45K Feb 20 11:53 vmcore-dmesg.txt
[root@pruebas ~]# more vmcore-dmesg.txt
[ 0.000000] Linux version 4.18.0-240.15.1.el8_3.x86_64 (mockbuild@x86-vm-

07.build.eng.bos.redhat.com) (gcc version 8.3.1 2
0191121 (Red Hat 8.3.1-5) (GCC)) #1 SMP Wed Feb 3 03:12:15 EST 2021
[ 0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-
240.15.1.el8_3.x86_64 root=/dev/mapper/rhel-root ro crash
kernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb
quiet
[ 0.000000] x86/fpu: x87 FPU will use FXSAVE
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000bffd9fff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000bffda000-0x00000000bfffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000792ffffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] SMBIOS 2.8 present.
[ 0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-
gd9c812dda519-prebuilt.qemu.org 04/01/2014
[ 0.000000] Hypervisor detected: KVM
[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[ 0.000000] kvm-clock: cpu 0, msr 2a2601001, primary cpu clock
[ 0.000000] kvm-clock: using sched offset of 13033004839 cycles
…
Esta es parte de la data es la que se utiliza para los análisis posteriores

por parte de los expertos en troubleshooting. También se observa un archivo
binario de 172Mb el cual es fundamental para el análisis posterior.
RELAX & RECOVER - RESPALDAR Y
RESTAURAR UN SISTEMA LINUX
Para recuperar y restaurar un sistema utilizando una copia de seguridad
existente, Red Hat Enterprise Linux (otras distribuciones también lo pueden
instalar) proporciona la opción Relax-and-Recover (ReaR). Puede utilizar la
utilidad como solución de recuperación ante desastres y también para la
migración del sistema.
La utilidad le permite realizar las siguientes tareas:
Genere una imagen de arranque y restaure el sistema a partir

de una copia de seguridad existente, utilizando la imagen.
Replicar el diseño del almacenamiento original.
Restaurar archivos de usuario y del sistema.
Restaurar el sistema a un hardware diferente.
Además, para la recuperación de desastres, también puede integrar cierto

software de respaldo con ReaR. Los siguientes pasos son utilizados para
crear una imagen de rescate de su sistema Linux junto con un backup de la
data, el tiempo de esta operación depende de la cantidad de data a guardar.
Es importante mencionar que este backup queda en un archivo ISO en la ruta
que el Administrador establezca.
Inicialmente se instalan las aplicaciones necesarias para la realización de

esta actividad:
[root@pruebas ~]# yum install rear genisoimage syslinux
Una vez instalado el software es necesario decirle a “rear” como generar

el disco de rescate y el backup del sistema, editando su archivo de
configuración y agregando las siguientes declaraciones:
[root@pruebas ~]# vim /etc/rear/local.conf

OUTPUT=ISO
OUTPUT_URL=file:///root
BACKUP=NETFS
BACKUP_URL=iso:///root
Es interesante antes de enviar el backup saber el tamaño total del sistema

a respaldar:
[root@s1 rear]# df -hT

devtmpfs devtmpfs 15G 0 15G 0% /dev
tmpfs tmpfs 15G 0 15G 0% /dev/shm
tmpfs tmpfs 15G 9.2M 15G 1% /run
tmpfs tmpfs 15G 0 15G 0% /sys/fs/cgroup
/dev/mapper/ol-root xfs 44G 20G 25G 44% /
tmpfs tmpfs 2.9G 1.2M 2.9G 1% /run/user/42
tmpfs tmpfs 2.9G 0 2.9G 0% /run/user/0
Seguido a esto es necesario realizar el ISO de rescate y backup del

sistema Linux (un solo archivo), este ISO quedará en la ruta /root/nombre-
sistema, como se muestra a continuación:
[root@s1 rear]# rear -d -v mkbackup

Relax-and-Recover 2.4 / Git
Using log file: /var/log/rear/rear-s1.log
Using backup archive '/tmp/rear.w0E22PfRdLwJCFg/tmp/isofs/root/backup.tar.gz'
Creating disk layout
Using guessed bootloader 'GRUB' (found in first bytes on /dev/sda)
Creating root filesystem layout
Handling network interface 'ens18'
ens18 is a physical device
Handled network interface 'ens18'
Skipping 'virbr0': not bound to any physical interface.
To log into the recovery system via ssh set up /root/.ssh/authorized_keys or specify
SSH_ROOT_PASSWORD
Copying logfile /var/log/rear/rear-s1.log into initramfs as '/tmp/rear-s1-partial-2021-02-
22T10:47:38-05:00.log'
Copying files and directories
Copying binaries and libraries
Copying kernel modules
Copying all files in /lib*/firmware/
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (340662414 bytes) in 35 seconds
Creating tar archive '/tmp/rear.w0E22PfRdLwJCFg/tmp/isofs/root/backup.tar.gz'
Archived 3282 MiB [avg 6654 KiB/sec] OK
Archived 3282 MiB in 506 seconds [avg 6641 KiB/sec]
Making ISO image
Wrote ISO image: /var/lib/rear/output/rear-s1.iso (3.6G)
Copying resulting files to file location
Saving /var/log/rear/rear-s1.log as rear-s1.log to file location
Exiting rear mkbackup (PID 63025) and its descendant processes
Running exit tasks
You should also rm -Rf /tmp/rear.w0E22PfRdLwJCFg
Se verifica la ubicación del archivo ISO:
[root@s1 ~]# pwd

/root
[root@s1 ~]# ll
total 8
-rw-------. 1 root root 1279 Feb 15 10:15 anaconda-ks.cfg
-rw-r--r--. 1 root root 1566 Feb 15 10:17 initial-setup-ks.cfg
drwxr-x---. 2 root root 73 Feb 22 10:57 s1
[root@s1 ~]# cd s1/
[root@s1 s1]# ll -h
total 3.6G
-rw-------. 1 root root 202 Feb 22 10:57 README
-rw-------. 1 root root 274 Feb 22 10:57 VERSION
-rw-------. 1 root root 3.6G Feb 22 10:57 rear-s1.iso
-rw-------. 1 root root 967K Feb 22 10:57 rear-s1.log
La aplicación “rear” ha generado un archivo ISO, del cual se puede

generar una USB booteable o llevarlo a un sistema de Virtualización, como
sea de preferencia, en este ejercicio se utilizará una plataforma de
virtualización.
Cuando se bootea desde el ISO resulta la siguiente imagen:
Se escoge la primera opción e inicia el proceso de recuperación del

sistema Linux, como se muestra a continuación:
Como podemos observar, se solicita un “login”, en este caso se introduce
“root” y se presiona enter. Seguidame se observa el promp para introducir
un comando que en este caso será “rear -v recover”, que dispara la
restauración del sistema operativo, como se detalla a continuación:
Seguido a esto es necesario esperar que se ejecute la restauración. Una

vez terminado el procedo de restauración, veremos una imagen como la
siguiente:
Acá el sistema nos devuelve un prompt, donde enviaremos un “reboot” e
iniciará el proceso del sistema restaurado. Es importante aclarar que
SELinux re-etiquetará el sistema y demorará un poco el proceso mientras
esto ocurre.
Una vez terminado este proceso, el sistema se reinicia e inicia en su

funcionamiento normal, igual al momento en que fue generado el “rear -v
mkbackup”.
INSTALACIÓN DE CAPACIDADES DE
VIRTUALIZACIÓN(KVM/VIRT-MANAGER)
En el siguiente material se podrá apreciar la forma para convertir un host
RHEL 8 en hypervisor grueso de Virtualización. Es importante aclarar que
“libvirt” es el que hace que toda la magia alrededor de la Virtualización
suceda, a partir de ahí es que herramientas como virsh, virt-manager,
Cockpit y OVirt, pueden hacer su trabajo.
Desde la versión 2.6 del kernel de Linux, ya están integradas las

funcionalidades de virtualización, no es necesario instalar un nuevo kernel
para contar con estas capacidades.
El ejercicio a continuación muestra primeramente una verificación previa

en el procesador del host, para establecer si es posible o no Virtualizalizar
sobre él; este procesador debe soportar los flags de virtualización activos,
siendo el flag “vmx” para procesadores Intel y “svm” para procesadores
AMD. Si alguno de estos flags está presente, es posible virtualizar sobre el
host. Una vez validado los flags se procede con la instalación inicialmente
de “libvirt” para luego seguir con las funcionalidades de Hypervisor y
cliente, que en este caso es el virt-manager. El procedimiento utilizado para
realizar la instalación es el siguiente:
[root@pruebas ~]# yum groupinfo Virtualization*

Last metadata expiration check: 0:12:38 ago on Sun 21 Mar 2021 12:13:24 PM EDT.
Environment Group: Virtualization Host
Description: Minimal virtualization host.
Mandatory Groups:
Base
Core
Standard
Virtualization Hypervisor
Virtualization Tools
Optional Groups:
Debugging Tools
Network File System Client
Remote Management for Linux
Virtualization Platform
Group: Virtualization Hypervisor
Description: Smallest possible virtualization host installation.
Mandatory Packages:
libvirt
qemu-kvm
Group: Virtualization Client

Description: Clients for installing and managing virtualization instances.
Mandatory Packages:
gnome-boxes
virt-install
virt-manager
virt-viewer
Default Packages:
virt-top
Optional Packages:
libguestfs-inspect-icons
libguestfs-tools
libguestfs-tools-c
Group: Virtualization Tools

Description: Tools for offline virtual image management.
Default Packages:
libguestfs
virtio-win
Optional Packages:
libguestfs-inspect-icons
libguestfs-java
libguestfs-tools
libguestfs-tools-c
Group: Virtualization Platform

Description: Provides an interface for accessing and controlling virtualized guests and
containers.
Mandatory Packages:
libvirt
libvirt-client
virt-who
Optional Packages:
fence-virtd-libvirt
fence-virtd-multicast
fence-virtd-serial
perl-Sys-Virt
Se verifica el flag de virtualización en el procesador:
[root@pruebas ~]# cat /proc/cpuinfo

processor: 0
cpuid level: 11
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush
mmx fxsr sse sse2 ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl
xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes vmx lahf_lm cpuid_fault pti tsc_adjust arat umip arch_capabilities
Otra forma de validar si el host tiene las capacidades para virtualizar es

la siguiente:
[root@pruebas ~]# virt-host-validate

QEMU: Checking for hardware virtualization : PASS
QEMU: Checking if device /dev/vhost-net exists : PASS
QEMU: Checking if device /dev/net/tun exists : PASS
QEMU: Checking for cgroup 'cpu' controller support : PASS
QEMU: Checking for cgroup 'cpuacct' controller support : PASS
QEMU: Checking for cgroup 'cpuset' controller support : PASS
QEMU: Checking for cgroup 'memory' controller support : PASS
QEMU: Checking for cgroup 'devices' controller support : PASS
QEMU: Checking for cgroup 'blkio' controller support : PASS
QEMU: Checking for secure guest support : PASS
Es momento de instalar las capacidades de Hypermisor sobre el host:
[root@pruebas ~]# yum groupinstall "Virtualization

Hypervisor" -y
Installed:
autogen-libopts-5.18.12-8.el8.x86_64
gnutls-dane-3.6.14-7.el8_3.x86_64
gnutls-utils-3.6.14-7.el8_3.x86_64
libvirt-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-bash-completion-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-client-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
libvirt-daemon-config-nwfilter-6.0.0-28.module+el8.3.0+7827+5e65edd7.x86_64
Complete!
Se hace necesario instalar las herramientas de comunicación con
“libvirt”, como sigue a continuación:
[root@pruebas ~]# yum groupinstall "Virtualization Client" -y

--with-optional
Installed:
hexedit-1.2.13-12.el8.x86_64
hivex-1.3.18-20.module+el8.3.0+6423+e4cb6418.x86_64
icoutils-0.32.3-2.el8.x86_64
libgovirt-0.3.7-3.el8.x86_64
libguestfs-1:1.40.2-25.module+el8.3.0+7421+642fe24f.x86_64
libguestfs-inspect-icons-1:1.40.2-25.module+el8.3.0+7421+642fe24f.noarch
libguestfs-tools-1:1.40.2-25.module+el8.3.0+7421+642fe24f.noarch
libguestfs-tools-c-1:1.40.2-25.module+el8.3.0+7421+642fe24f.x86_64
libguestfs-xfs-1:1.40.2-25.module+el8.3.0+7421+642fe24f.x86_64
netpbm-10.82.00-6.el8.x86_64
netpbm-progs-10.82.00-6.el8.x86_64
perl-Class-Inspector-1.32-2.el8.noarch
perl-Compress-Raw-Bzip2-2.081-1.el8.x86_64
perl-Compress-Raw-Zlib-2.081-1.el8.x86_64
perl-Data-Dump-1.23-7.module+el8.3.0+6498+9eecfe51.noarch
perl-Digest-HMAC-1.03-17.module+el8.3.0+6498+9eecfe51.noarch
perl-Digest-SHA-1:6.02-1.el8.x86_64
perl-Encode-Locale-1.05-10.module+el8.3.0+6498+9eecfe51.noarch
perl-File-Listing-6.04-17.module+el8.3.0+6498+9eecfe51.noarch
perl-File-ShareDir-1.104-3.el8.noarch
perl-HTML-Parser-3.72-15.module+el8.3.0+6498+9eecfe51.x86_64
perl-HTML-Tagset-3.20-34.module+el8.3.0+6498+9eecfe51.noarch
perl-HTTP-Cookies-6.04-2.module+el8.3.0+6498+9eecfe51.noarch
perl-HTTP-Date-6.02-19.module+el8.3.0+6498+9eecfe51.noarch
perl-HTTP-Message-6.18-1.module+el8.3.0+6498+9eecfe51.noarch
perl-HTTP-Negotiate-6.01-19.module+el8.3.0+6498+9eecfe51.noarch
perl-IO-Compress-2.081-1.el8.noarch
perl-IO-HTML-1.001-11.module+el8.3.0+6498+9eecfe51.noarch
perl-LWP-MediaTypes-6.02-15.module+el8.3.0+6498+9eecfe51.noarch
perl-NTLM-1.09-17.module+el8.3.0+6498+9eecfe51.noarch
perl-Net-HTTP-6.17-2.module+el8.3.0+6498+9eecfe51.noarch
perl-Sys-Guestfs-1:1.40.2-25.module+el8.3.0+7421+642fe24f.x86_64
perl-Sys-Virt-6.0.0-1.module+el8.3.0+6423+e4cb6418.x86_64
perl-TimeDate-1:2.30-15.module+el8.3.0+6498+9eecfe51.noarch
perl-Try-Tiny-0.30-7.module+el8.3.0+6498+9eecfe51.noarch
perl-WWW-RobotRules-6.02-18.module+el8.3.0+6498+9eecfe51.noarch
perl-hivex-1.3.18-20.module+el8.3.0+6423+e4cb6418.x86_64
perl-libintl-perl-1.29-2.el8.x86_64
perl-libwww-perl-6.34-1.module+el8.3.0+6498+9eecfe51.noarch
python3-argcomplete-1.9.3-6.el8.noarch
python3-libvirt-6.0.0-1.module+el8.3.0+6423+e4cb6418.x86_64
scrub-2.5.2-14.el8.x86_64
supermin-5.1.19-10.module+el8.3.0+6423+e4cb6418.x86_64
syslinux-6.04-4.el8.x86_64
syslinux-extlinux-6.04-4.el8.x86_64
syslinux-extlinux-nonlinux-6.04-4.el8.noarch
syslinux-nonlinux-6.04-4.el8.noarch
virt-install-2.2.1-3.el8.noarch
virt-manager-2.2.1-3.el8.noarch
virt-manager-common-2.2.1-3.el8.noarch
virt-top-1.0.8-32.el8.x86_64
virt-viewer-9.0-4.el8.x86_64
Al finalizar esta instalación usted cuenta con las capacidades necesarias

para hospedar maquinas virtuales gracias a la plataforma de virtualización,
para ello puede hacer uso de las aplicaciones “virsh”, “virt-manager”
(interfaz gráfica) o cockpit (consola web).
INSTALANDO UNA MAQUINA VIRTUAL POR VIRT-MANAGER
El ejercicio que a continuación se realizará corresponde a la instalación

de una maquina virtual del ISO “proxmox-ve_6.3-1.iso” ubicado en la ruta
“/tmp”. La instalación de esta maquina virtual será realizada en un
filesystems XFS montado (/maquinas) sobre una estructura LVM. Iniciamos
verificando la existencia del ISO de instalación:
[root@bd2 ~]# ll -h /tmp/proxmox-ve_6.3-1.iso

-rw-r--r--. 1 root root 813M Mar 28 10:41 /tmp/proxmox-ve_6.3-
1.iso
Se identifica y se crea la estructura de LVM para hospedar las maquinas

virtuales:
[root@bd2 ~]# lsblk

NAME MAJ:MIN RM SIZE RO TYPE
sdc 8:32 0 100G 0 disk
[root@bd2 ~]# pvcreate /dev/sdc

[root@bd2 ~]# vgcreate mv /dev/sdc

Volume group "mv" successfully created
[root@bd2 ~]# lvcreate -l 100%free -n kvm mv

Logical volume "kvm" created.
Se asigna el sistema de archivos XFS y se establece su disponibilidad de

forma persistente:
[root@bd2 ~]# mkfs.xfs /dev/mv/kvm

[root@bd2 ~]# blkid | grep sdc >> /etc/fstab
[root@bd2 ~]# mkdir /maquinas

[root@bd2 ~]# vim /etc/fstab
UUID="be82828b-ce08-4a38-bc1c-093284b1464c" /maquinas xfs

defaults 0 0
[root@bd2 ~]# udevadm settle
[root@bd2 ~]# systemctl daemon-reload
Finalizado el proceso queda definido que “/maquinas” es un punto de

montaje donde se podrá guardar maquinas virtuales creadas desde el virt-
manager, como se muestra a continuación:
[root@bd2 ~]# df -hT

/dev/mapper/mv-kvm xfs 100G 746M 100G 1% /maquinas
A continuación a través de “virt-manager”se agrega el punto de montaje,

en “virt-manager” esto se conoce como agregar un “pool”:
En la pestaña superior se observa la opción “storage”, habiéndola
escogido se presiona en el icono “+” donde se presenta una pantalla que
brinda la posibilidad de colocarle el nombre al “pool” y escoger el punto de
montaje:
Al agregar el pool (filesystem en el punto de montaje) se debe observar

una pantalla como la siguiente:
A continuación se crea la maquina virtual buscando el ISO de instalación
en /tmp definiendo Linux Debian 10 como sistema operativo a instalar:
Es necesario establecer la memoria RAM a utilizar, como se detalla:
Seguidamente se define el sitio de hospedaje de la maquina virtual,

tomando la opción “Select or créate custom storage”:
Se nos presenta una pantalla donde en el icono “+” se escoge para crear
el archivo de la maquina virtual:
Al finalizar el proceso de definir el nombre, formato y tamaño del
archivo de maquina virtual se debe observar una imagen como la anterior y
al dar click sobre la opción “Choose Volume” se debe observar una imagen
como la siguiente:
La última pantalla nos permitirá colocarle el nombre a la maquina virtual
y definir la red:
Por último al dar click en el botón “Finish” iniciará la instalación del
ISO de preferencia, en este caso la plataforma Proxmox:
INSTALANDO Y CONFIGURANDO UN
WEBSERVER – NGINX
Se listan los diferentes módulos para instalar Nginx:
[root@pruebas ~]# yum module list nginx

Last metadata expiration check: 0:44:06 ago on Mon 22 Mar 2021 08:46:03 AM EDT.
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
nginx 1.14 [d] common [d] nginx webserver
nginx 1.16 common [d] nginx webserver
nginx 1.18 common [d] nginx webserver
Se revisan los perfiles disponibles para este modulo:
[root@pruebas ~]# yum module info nginx:1.14 --profile

Name : nginx:1.14:8000020190830002848:f8e95b4e:x86_64
common : nginx
: nginx-all-modules
: nginx-filesystem
: nginx-mod-http-image-filter
: nginx-mod-http-perl
: nginx-mod-http-xslt-filter
: nginx-mod-mail
: nginx-mod-stream
Es momento de realizar la instalación “nginx:1.14”, usted podrá instalar

la versión que corresponda a sus requerimientos:
[root@pruebas ~]# yum module install nginx:1.14

================================================================
==================================
================================================================
=========
nginx x86_64 1:1.14.1-9.module+el8.0.0+4108+af250afe rhel-8-for-x86_64-
nginx-all-modules noarch 1:1.14.1-9.module+el8.0.0+4108+af250afe rhel-8-for-
Installed:
nginx-1:1.14.1-9.module+el8.0.0+4108+af250afe.x86_64
nginx-all-modules-1:1.14.1-9.module+el8.0.0+4108+af250afe.noarch
nginx-filesystem-1:1.14.1-9.module+el8.0.0+4108+af250afe.noarch
nginx-mod-http-image-filter-1:1.14.1-9.module+el8.0.0+4108+af250afe.x86_64
nginx-mod-http-perl-1:1.14.1-9.module+el8.0.0+4108+af250afe.x86_64
nginx-mod-http-xslt-filter-1:1.14.1-9.module+el8.0.0+4108+af250afe.x86_64
nginx-mod-mail-1:1.14.1-9.module+el8.0.0+4108+af250afe.x86_64
nginx-mod-stream-1:1.14.1-9.module+el8.0.0+4108+af250afe.x86_64
Es necesario abrir los puertos en FirewallD para recibir solicitudes de

conexión:

service=http
success

success
Habilite en el inicio del sistema el servicio “nginx” y ejecútelo de forma

inmediata:
[root@pruebas ~]# systemctl enable nginx --now

Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service →
/usr/lib/systemd/system/nginx.service.
Se verifica el servicio “nginx” en operación listando los procesos del

sistema:

root 10798 1 0 09:03 ? 00:00:00 nginx: master process /usr/sbin/nginx
nginx 10799 10798 0 09:03 ? 00:00:00 nginx: worker process
Finalizando el procedimiento y para comprobar la puesta en marcha del

servidor web “nginx”, tome la dirección IP del servidor RHEL y abra el
cliente HTTP de su preferencia en un equipo diferente al RHEL 8, verá una
imagen similar a la siguiente:
El servicio “nginx” usa la ruta “/usr/share/nginx/html” como directorio

de publicación de contenido, si usted requiere publicar algun tipo de
contenido puede ubicar sus archivos HTML ahí, como se muestra a
continuación:
[root@pruebas html]# pwd

/usr/share/nginx/html
[root@pruebas html]# ll
total 24
-rw-r--r--. 1 root root 3971 Aug 30 2019 404.html
-rw-r--r--. 1 root root 4020 Aug 30 2019 50x.html
-rw-r--r--. 1 root root 4057 Aug 30 2019 index.html
-rw-r--r--. 1 root root 368 Aug 30 2019 nginx-logo.png
-rw-r--r--. 1 root root 4148 Aug 30 2019 poweredby.png
Para configurar el servicio “nginx” utilice el archivo
/etc/nginx/nginx.conf:
[root@pruebas ~]# ll /etc/nginx/nginx.conf

-rw-r--r--. 1 root root 2469 Aug 30 2019 /etc/nginx/nginx.conf
VIRTUAL HOSTS EN NGINX
Una de las grandes utilidades de utilizar un servidor web, sea Apache

Web Server o Nginx, es poder tomar este servicio para configurar diferentes
sitios web dentro de un mismo host; el procedimiento a ejecutar tiene como
escenario el esquema tradicional de la gran mayoría de las empresas donde
he realizado consultorías: una red con un servidor Microsoft Windows
Server realizando las funciones de Active Directory y DNS, en este caso con
la zona directa “aptivalabs.net” y los registros en DNS w1.aptivalabs.net,
w2.aptivalabs.net y w3.aptivalabs.net apuntando al host 192.168.1.201. El
host 192.168.1.201 será en este caso quien hospede los diferentes sitios web.
El procedimiento inicia creando las carpetas que hospedarán los archivos

html:
[root@pruebas ~]# mkdir /w1

Seguidamente, se crean los directorios para hospedar los logs en función

del acceso a los virtual host:
[root@pruebas ~]# mkdir /var/log/nginx/w1/

Se hace necesario cambiar la política SELinux para los directorios que

hospedarán los sitios web y aplicarla inmediatamente sobre ellos:
[root@pruebas ~]# semanage fcontext -a -t httpd_sys_content_t

"/w1(/.*)?"

"/w2(/.*)?"

"/w3(/.*)?"
[root@pruebas ~]# restorecon -Rv /w1
Relabeled /w1 from unconfined_u:object_r:default_t:s0 to


Antes de editar el archivo de configuración del servicio “nginx” genere

una copia de este:
[root@pruebas ~]# cp /etc/nginx/nginx.conf

/etc/nginx/nginx.conf.ori
En el archivo de configuración de “nginx” usted encontrará una sección

como la que se muestra:
Adicione el siguiente contenido al archivo “/etc/nginx/nginx.conf” como
bloques debajo de la sección “server”, la cual se muestra a continuación:
[root@pruebas ~]# vim /etc/nginx/nginx.conf
server {
server_name w1.aptivalabs.net;
root /w1;
access_log /var/log/nginx/w1/access.log;
error_log /var/log/nginx/w1/error.log;
}
server {
root /w2;
}
server {
root /w3;
}
Reinice el servicio “nginx”:
[root@pruebas ~]# systemctl restart nginx.service
A continuación se crean tres (3) archivos “html” como archivos índice de

cada uno de los sitios web, estos serán los archivos o paginas por default
para mostrar una vez los clientes hagan peticiones sobre estos:
[root@pruebas ~]# echo "<h1>Yo soy el server 1 </h1>" >>

/w1/index.html
/w2/index.html
/w3/index.html
Para verificar que el procedimiento ha sido efectivo y exitoso por favor

valide en su propio servidor de la siguiente forma:
[root@pruebas ~]# curl w1.aptivalabs.net

<h1>Yo soy el server 1 </h1>


Utilice un navegador web para verificar la respuesta de cada uno de estos

sitios web.
PROXY REVERSO PARA TRAFICO HTTP
Puede configurar el servidor web NGINX para que actúe como un proxy
inverso para el tráfico HTTP. Usted puede utilizar esta funcionalidad para
reenviar solicitudes a un subdirectorio específico en un servidor remoto, el
cliente asume que carga el contenido desde el host al que accede, sin
embargo, el servicio “nginx” carga el contenido real del servidor remoto y lo
reenvía al cliente.
Para el ejemplo a continuación, se cuenta con dos web servers

ejecutándose en 192.168.1.202 y 192.168.1.201; el ejercicio consiste en que
si un usuario solicita ver el contenido en el servidor 192.168.1.201/test, este
servidor en realidad va a mostrar el contenido público en la URL
http://192.168.1.202/test.html; en este sentido ejecutemos el servidor web
en 192.168.1.202 creando el archivo “test.html”:
[root@ap2 ~]# cd /usr/share/nginx/

[root@ap2 nginx]# ll
total 0
drwxr-xr-x. 2 root root 99 Mar 22 09:44 html
drwxr-xr-x. 2 root root 143 Mar 22 09:44 modules
[root@ap2 nginx]# cd html/
[root@ap2 html]# echo "<h1>Contenido 1 en 192.168.1.202</h1>"
>> test.html
>> test.html
>> test.html
Se verifica que el servidor 192.168.1.202 esté publicando el recurso

(test.html), como sigue:
Seguidamente en el servidor 192.168.1.201 editamos el archivo de

configuración de “nginx” para agregar las siguientes líneas:
[root@pruebas html]# vim /etc/nginx/nginx.conf

location /test {
proxy_pass http://192.168.1.202/test.html;
}
En el archivo de configuración de “nginx” el bloque de configuración

debe quedar así:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
root /usr/share/nginx/html;
# Load configuration files for the default server block.

include /etc/nginx/default.d/*.conf;
#location / {
#}
location /test {
proxy_pass http://192.168.1.202/test.html;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;

}
}
Seguidamente se habilita la variable booleana

“httpd_can_network_connect” en SELinux y se lanza el servicio
nuevamente:
[root@pruebas html]# setsebool -P httpd_can_network_connect

1
[root@pruebas html]# systemctl restart nginx.service
Para confirmar esta configuración en un cliente HTTP haga una solicitud

en http://192.168.1.201/test, como se muestra a continuación:
Con el ejercicio anteriormente desarrollado, de una u otra forma se ha

escondido el servidor que en realidad da la respuesta al cliente, siendo este el
192.168.1.202; los usuarios van a buscar respuestas en el servidor web
192.168.1.201 y este muestra el contenido de otro servidor web.
BALANCEO DE CARGA HTTP CON NGINX
Este procedimiento describe la configuración del servicio NGINX como

un balanceador de carga HTTP que envía solicitudes a diferentes servidores,
según cuál de ellos tiene el menor número de conexiones activas, o sea, se
trata de determinar cuál de los servidores dentro del grupo de balanceo tiene
mejor estado de salud para enviarle peticiones http. Es un escenario útil
cuando se manejan aplicaciones web dentro de una empresa y se necesita al
menos contar con escenario en alta disponibilidad para esa aplicación.
Para desarrollar esta funcionalidad se cuenta con el siguiente grupo de

servidores:
192.168.1.201 = balanceador
192.168.1.202 = servidor del grupo
192.168.1.203 = servidor del grupo
En aras de validar que el balanceador efectivamente está realizando su

trabajo, en los servidores 192.168.1.202 y 192.168.1.203 (con el servicio
“nginx” ejecutandose) cambie la pagina índice por defecto (index.html),
[root@sr2 ~]# cd /usr/share/nginx/html/

[root@sr2 html]# mv index.html index.html.ori
[root@sr2 html]# echo "<h1>soy 192.168.1.202</h1>" >>
index.html
Se ejecutan las mismas instrucciones en el servidor 192.168.1.203:
[root@sr3 ~]# cd /usr/share/nginx/html/

[root@sr3 html]# mv index.html index.html.ori
[root@sr3 html]# echo "<h1>soy 192.168.1.203</h1>" >>
index.html
En el servidor que hará el balanceo de carga, el archivo de configuración

de “nginx” debería ser similar a este:
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
# Load modular configuration files from the /etc/nginx/conf.d directory.

# See http://nginx.org/en/docs/ngx_core_module.html#include
# for more information.
include /etc/nginx/conf.d/*.conf;
upstream loadbalancer.aptivalabs.net {
least_conn;
server 192.168.1.202;
server 192.168.1.203;
}
server {
server_name _;

#location / {
#}
location / {
proxy_pass http://loadbalancer.aptivalabs.net;
}

}
error_page 500 502 503 504 /50x.html;

}
}
# Settings for a TLS enabled server.

#
# server {
# listen 443 ssl http2 default_server;
# listen [::]:443 ssl http2 default_server;
# server_name _;
# root /usr/share/nginx/html;
#
# ssl_certificate "/etc/pki/nginx/server.crt";
# ssl_certificate_key "/etc/pki/nginx/private/server.key";
# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 10m;
# ssl_ciphers PROFILE=SYSTEM;
# ssl_prefer_server_ciphers on;
#
# # Load configuration files for the default server block.
# include /etc/nginx/default.d/*.conf;
#
# location / {
# }
#
# error_page 404 /404.html;
# location = /40x.html {
# }
#
# error_page 500 502 503 504 /50x.html;
# location = /50x.html {
# }
# }
Se puede resaltar entonces del contenido del archivo las líneas

“upstream” y “location”, que nos indican que en el momento que cualquier
usuario que intente llegar a http://loadbalancer.aptivalabs.net (registro DNS
previamente configurado apuntando a 192.168.1.201), la ip 192.168.1.201
balanceará la carga de peticiones que reciba; se relacionan las líneas:
upstream loadbalancer.aptivalabs.net {
least_conn;
server 192.168.1.202;
server 192.168.1.203;
}
location / {
proxy_pass http://loadbalancer.aptivalabs.net;
}
Una forma de validar esta configuración es utilizando la aplicación

“curl”, como se muestra a continuación:
[root@sr1 ~]# curl http://loadbalancer.aptivalabs.net

<h1>soy 192.168.1.202</h1>

<h1>soy 192.168.1.203</h1>

<h1>soy 192.168.1.202</h1>

<h1>soy 192.168.1.203</h1>

<h1>soy 192.168.1.202</h1>
Se puede entonces evidenciar que al requerir con el comando “curl” la

URL http://loadbalancer.aptivalabs.net el servicio “nginx” muestra siempre
una pagina distinta. Para una mejor visualización usted podría usar
cualquier cliente HTTP.
CIFRANDO LA COMUNICACIÓN CON TLS
TLS (Transport Layer Security) es un metodo de cifrado para las

comunicaciones en red y es el sucesor de SSL (Secure Socket Layer). TLS
le permite al cliente verificar la identidad del servidor y al servidor verificar
la identidad del cliente.
Características:
TLS está basado en el concepto de certificados.

Un certificado tiene múltiples partes: llave pública, identidad de
servidor y una firma de un certificado de autoridad
La correspondiente llave privada nunca es hecha publica
Cualquier data encriptado con llave privada solo puede ser
desencriptado con llave publica y viceversa
Las etapas de la comunicación implican el desarrollo de diversas

actividades; el cliente y el servidor acuerdan las reglas de encripción
soportadas por ambos e intercambian bits aleatorios de datos. El cliente
utiliza estos datos pare generar una llave de sesión, una llave que será usada
para una encripción simétrica mas rápida, donde la misma llave es usada
para encripcion y desencripción. Para asegurar que esta llave no esté
comprometida se envía al servidor encriptada con la llave pública del
servidor.
A continuación se generan los certificados necesarios para cifrar la

comunicación, como se muestra:
[root@loadbalancer ~]# openssl req -x509 -out localhost.crt -

keyout localhost.key -newkey rsa:2048 -nodes -sha256 -subj
'/CN=localhost' -extensions EXT -config <( \
printf "[dn]\nCN=localhost\n[req]\ndistinguished_name =
dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignat
ure\nextendedKeyUsage=serverAuth")
Se hace necesario copiar los certificados a la ruta correspondiente para

que el servicio “nginx” los lea, esta ruta es necesaria definirlas en el archivo
de configuración de “nginx”;
[root@loadbalancer ~]# cp localhost.crt
/etc/pki/tls/certs/localhost.crt
[root@loadbalancer ~]# cp localhost.key
/etc/pki/tls/private/localhost.key
El archivo de configuración del servicio “nginx” deberá lucir como se

muestra:
[root@loadbalancer ~]# cat /etc/nginx/nginx.conf

server {
listen 443 ssl http2 default_server;

listen [::]:443 ssl http2 default_server;
server_name _;
ssl_certificate "/etc/pki/tls/certs/localhost.crt";
ssl_certificate_key "/etc/pki/tls/private/localhost.key";
#server_name _;
#server_name loadbalancer.aptivalabs.net;
#root /usr/share/nginx/html;

location / {
}

}
error_page 500 502 503 504 /50x.html;

}
}
Se puede apreciar que el servicio “nginx” se deja configurado para que

reciba peticiones en los puertos 80 y 443 utilizando la misma ruta de
publicación, la cual es “/usr/share/nginx/html”. De igual forma se relacionan
las rutas donde “nginx” va a buscar los certificados. La operación indica que
es necesario decirle a FirewallD que acepte peticiones HTTPS en la zona por
default, las peticiones HTTP ya estaban agregadas en FirewallD:
[root@loadbalancer ~]# firewall-cmd --permanent --add-

service=https
success
[root@loadbalancer ~]# firewall-cmd --reload

success
Para verificar la configuración, ejecute un cliente HTTP de su

preferencia e intente comunicarse con el servidor via HTTP, como se
visualiza a continuación:
Seguidamente, en su cliente HTTP intente realizar la comunicación vía

HTTPS:
INSTALACIONES DESATENTIDAS -
KICKSTART
En un entorno donde se hace necesario de manera frecuente realizar
instalaciones de RHEL 8 (procedimiento que también podría ser emulado en
Oracle Linux y CentOS 8), puede resultar un poco desgastante ejecutar un
proceso manual cuando se tratan de instalar muchos sistemas; puede ser el
caso por ejemplo de instalar toda un ambiente de formación para que 20
estudiantes realicen laborotarios Linux, o el caso de una empresa que
requiera implementar un cluster de servicios (almacenamiento,
virtualización, etc) donde intervengan muchas sistemas Linux.
Ante esta situación la herramienta Kickstart permite generar una

instalación desatendida, automatizada, donde solo será necesario indicarle al
instalador donde encontrar el archivo con la definición de la instalación y el
instalador ejecuta esta actividad sin que el Administrador tenga la necesidad
de estar presente en función de la instalación de cada sistema.
Para el desarrollo de esta actividad es necesario ejecutar los siguientes

pasos:
1. Generar el archivo de kickstart (archivo de definición de

instalación)
2. Publicar el archivo de kickstart en un recurso visible
3. Publicar el paquete de instalación
4. Iniciar la instalación desde un ISO de instalación
En escenario del ejercicio a implementar se relaciona en el servidor con

dirección IP 192.168.0.200, el cual tiene implementado el servicio “Nginx”
y el ISO de instalación de RHEL 8 montado dentro de la ruta de publicación
de Nginx.
El primer paso consiste en generar un archivo de kickstart, el cual es un

archivo de texto donde se define en un formato propio las características
requeridas de la instalación. La generación de este archivo podrá realizarse
usando una herramienta que Red Hat proporciona para tal fin, la cual puede
ser encontrada en la URL https://access.redhat.com/labs/kickstartconfig/. De
igual forma los sistemas RHEL 8 y derivados una vez han finalizado su
instalación dejan un archivo en “/root” llamado “anaconda-ks.cfg” el cual es
un archivo de kickstart:
[root@loadbalancer ~]# pwd

/root
[root@loadbalancer ~]# ll anaconda-ks.cfg

En el desarrollo de este ejercicio se ha usado la herramienta

https://access.redhat.com/labs/kickstartconfig/, donde se ha generado un
archivo y se ha descargado al servidor RHEL 8; el archivo que se ha
generado define el despliegue de un ambiente de “instalación mínima”; se
detalla el archivo generado:
[root@loadbalancer html]# cat ks.cfg

lang en_US
keyboard us
timezone America/Bogota --isUtc
rootpw $1$wRe6mImL$eyda8JWudogBZ5pMTTVU9/ --iscrypted
#platform x86, AMD64, or Intel EM64T
reboot
url --url=http://192.168.0.200/repo
bootloader --location=mbr --append="rhgb quiet crashkernel=auto"
zerombr
clearpart --all --initlabel
autopart
auth --passalgo=sha512 --useshadow
selinux --enforcing
firewall --enabled
firstboot --disable
%packages
@^minimal-environment
%end
El archivo puede tomar cualquier nombre, lo importante es que se use la
terminación “.cfg”; en él se define el lenguaje, el password del usuario
“root”, la URL donde están los paquetes de instalación, el
autoparticionamiento, el modo de operación de SELinux y FirewallD, entre
otros datos. Esta configuración puede personalizarse tanto como se requiera.
Este archivo generado debe publicarse en un recurso visible, en este caso

y aprovechando la instalación del servidor web “Nginx”, usaremos la ruta
“/usr/share/nginx/html” para publicar el archivo de kickstart.
El paquete de instalación hace referencia a los instaladores de la

distribución Linux; para este ejercicio se hace uso del servidor web instalado
(Nginx); en este sentido se hará disponible la unidad de DVD dentro la ruta
de publicación del servidor web (“/usr/share/nginx/html/repo):
[root@loadbalancer html]# mkdir /usr/share/nginx/html/repo
[root@loadbalancer html]# echo “/dev/sr0

/usr/share/nginx/html/repo iso9660 defaults 0 0” >> /etc/fstab
[root@loadbalancer html]# udevadm settle
[root@loadbalancer html]# systemctl daemon-reload

[root@loadbalancer html]# mount -a
[root@loadbalancer html]# cat /etc/fstab

/dev/sr0 /usr/share/nginx/html/repo iso9660 defaults 0 0
Antes de enviar la instalación valide que el archivo de kickstart se

encuentra disponible vía HTTP, como se muestra a continuación:
[root@loadbalancer ~]# curl http://192.168.0.200/ks.cfg

lang en_US
keyboard us
timezone America/Bogota --isUtc
rootpw $1$wRe6mImL$eyda8JWudogBZ5pMTTVU9/ --iscrypted
#platform x86, AMD64, or Intel EM64T
reboot
url --url=http://192.168.0.200/repo
bootloader --location=mbr --append="rhgb quiet crashkernel=auto"
zerombr
clearpart --all --initlabel
autopart
auth --passalgo=sha512 --useshadow
selinux --enforcing
firewall --enabled
firstboot --disable
%packages
@^minimal-environment
%end
Es momento entonces de generar la instalación; ingrese el ISO de

instalación de RHEL 8 y encienda su hardware o maquina virtual teniendo
presente bootear por el ISO de instalación. Usted debería ver la conocida
imagen de instalación de los sistemas Red Hat Enterprise Linux. Escoja la
opción “Troubleshooting” y luego presiona la tecla “TAB”, para ese
momento el instalador le mostrará una interfaz de línea de comandos donde
al final agregará los siguientes parámetros:
inst.ks=http://192.168.0.200/ks.cfg
Es todo lo que tendrá necesidad de hacer; si tiene una USB podrá pasar a
otra instalación.
La siguiente imagen muestra el procedimiento anteriormente explicado:
La instalación empezará de forma automática sin necesidad de que usted
esté al tanto de ella, como se muestra en la siguiente imagen:
IMPLEMENTANDO UN SERVIDOR DE
ARCHIVOS CON SAMBA
Samba implementa el protocolo Server Message Block (SMB) en RHEL.
Este protocolo se utiliza para acceder a los recursos de un servidor como
archivos e impresoras compartidas. El despliegue de un servidor SMB como
Samba implica según corresponda algunos de los servicios que Samba tiene
asociados, como lo son el “smbd”, el “nmbd” y el “winbind”.
El servicio “smbd” proporciona servicios de impresión y uso compartido

de archivos mediante el protocolo SMB, además es responsable del bloqueo
de recursos y de la autenticación de los usuarios que se conectan a Samba.
El servicio “nmbd” proporciona el nombre de host y la resolución de IP

utilizando el protocolo NetBIOS sobre IPv4. Adicionalmente a 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.
El servicio “winbind” proporciona una interfaz para que el Servicio de

Intercambio de Nombres (NSS – Network Service Switch) integre los
usuarios y grupos locales y de AD (Active Directory) en el sistema local.
Esto permite que los usuarios del dominio se autentiquen en servicios
administrados por el servidor Samba o en otros servicios locales. Si
configura Samba como miembro de dominio, “winbind” debe iniciarse
antes que el servicio “smbd” de lo contrario, los usuarios y grupos del
dominio no estarán disponibles para el sistema local.
Para un mejor entendimiento de como implementar Samba en su rol de

servidor de archivos, tomaremos el servidor con IP 192.168.0.201 como
servidor Samba; simularemos un escenario de algunos grupos de trabajo
(tesorería y rrhh – recursos humanos) dentro de una empresa que requieren
tener permisos sobre carpetas dentro del sistema para guardar archivos. Las
personas que accederán a estas usarán sistemas Linux Red Hat, Microsoft
Windows 10 y Apple Mac OSX. Estas personas podrán guardar información
personal en carpetas personales y en las carpetas de grupo; en ningún
momento podrán tener acceso a Shell en el servidor Linux.
El ejercicio inicia con la instalación de Samba, como se muestra:
[root@sr1 ~]# yum -y install samba

Last metadata expiration check: 0:35:00 ago on Wed 24 Mar 2021 03:19:16 PM EDT.
================================================================
========
================================================================
========
Installing:
samba x86_64 4.12.3-14.el8_3 rhel-8-for-x86_64-baseos-rpms
840 k
samba-common-tools x86_64 4.12.3-14.el8_3 rhel-8-for-x86_64-baseos-
rpms 484 k
samba-libs x86_64 4.12.3-14.el8_3 rhel-8-for-x86_64-baseos-rpms
188 k
Transaction Summary
================================================================
========
Install 3 Packages

Installed:
samba-4.12.3-14.el8_3.x86_64 samba-common-tools-4.12.3-14.el8_3.x86_64 samba-libs-
4.12.3-14.el8_3.x86_64
Procedemos a crear las carpetas que contendrán la información de los

grupos de trabajo; es importante mencionar que en un escenario real se
recomendaría que /datos sea el punto de montaje de un filesystem XFS
montado sobre una estructura LVM con LV Thin; se crean las carpetas:
[root@sr1 ~]# mkdir -p /datos/tesoreria

[root@sr1 ~]# mkdir /datos/rrhh
Se crean los grupos de trabajo y se asignan los respectivos permisos

sobre las carpetas creadas:
[root@sr1 ~]# groupadd -r tesoreria

[root@sr1 ~]# groupadd -r rrhh
[root@sr1 ~]# chgrp tesoreria /datos/tesoreria
[root@sr1 ~]# chgrp rrhh /datos/rrhh
[root@sr1 ~]# chmod 2770 /datos/tesoreria
[root@sr1 ~]# chmod 2770 /datos/rrhh
Se aprecia en la instrucción anterior la creación de permisos “setgid” con

el fin de que los archivos creados en cada de una de las carpetas de grupos,
sigan perteneciendo al mismo grupo una vez creados; lo mismo se hace
declarando ACL’s por default para que archivos y directorios a futuro
conserven los atributos necesarios para que los usuarios de los grupos
“tesoreria” y “rrhh” sigan teniendo derechos sobre los recursos:
[root@sr1 ~]# setfacl -m g:tesoreria:rwx /datos/tesoreria

[root@sr1 ~]# setfacl -m d:g:tesoreria:rwx /datos/tesoreria
[root@sr1 ~]# setfacl -m g:rrhh:rwx /datos/rrhh
[root@sr1 ~]# setfacl -m d:g:rrhh:rwx /datos/rrhh
Es momento de controlar el acceso a estos directorios mediante

SELinux, el cual debe estar en modo “enforcing”:
[root@sr1 ~]# semanage fcontext -a -t samba_share_t

‘/datos/tesoreria(/.*)?’
[root@sr1 ~]# semanage fcontext -a -t samba_share_t
‘/datos/rrhh(/.*)?’
[root@sr1 ~]# restorecon -vvFR /datos/tesoreria
[root@sr1 ~]# restorecon -vvFR /datos/rrhh
La instrucción anterior crea y aplica de forma inmediata las políticas

SELinux sobre las carpetas que contendrán los datos de los grupos de
trabajo. Seguidamente se activan los booleanos SELinux que permitirán la
exportación de la carpeta /home y las carpetas de los grupos de trabajo:
[root@sr1 ~]# setsebool -P samba_export_all_rw on

[root@sr1 ~]# setsebool -P samba_export_all_ro on
[root@sr1 ~]# setsebool -P samba_enable_home_dirs on
A continuación se crean los usuarios del sistema Linux correspondientes

a cada grupo de trabajo, los cuales deben crearse sin acceso a Shell, sin
grupo primario pues su grupo principal debe ser su grupo de trabajo; de la
misma forma e inmediatamente se crea el usuario Samba con el mismo
nombre que el usuario en Linux y la misma contraseña.
[root@sr1 ~]# adduser -N -s /sbin/nologin -g tesoreria t1
[root@sr1 ~]# smbpasswd -a t1

New SMB password:
Retype new SMB password:
Added user t1.
[root@sr1 ~]# adduser -N -s /sbin/nologin -g rrhh r1
[root@sr1 ~]# smbpasswd -a r1

New SMB password:
Retype new SMB password:
Added user r1.
Si usted da un vistazo a /home, el directorio de los usuarios, podrá ver lo

siguiente:
[root@sr1 ~]# ll /home/

total 4
drwx------. 3 r1 rrhh 78 Mar 24 16:49 r1
drwx------. 3 t1 tesoreria 78 Mar 24 16:48 t1
Una vez definida toda la estructura que soportará el servidor de archivos

se hace necesario guardar una copia del archivo original de Samba por temas
de backup. La instalación de Samba creó la ruta “/etc/samba” que es donde
se hospedan sus archivos de configuración, como se muestra:
[root@sr1 ~]# cd /etc/samba/
[root@sr1 samba]# pwd

/etc/samba
[root@sr1 samba]# mv smb.conf smb.conf.original

[root@sr1 samba]# mv smb.conf.example smb.conf
El archivo “smb.conf.example” es el que contiene la configuración que
necesitamos para Samba, de tal forma que al renombrarse queda como el
archivo principal de configuración, “smb.conf”. Seguido a estos pasos se
hace necesario editar este archivo de configuración para establecer las
siguientes directrices:
[root@sr1 ~]# vim /etc/samba/smb.conf
workgroup = WORKGROUP
interfaces = lo ens18
host allow = 127. 192.168.0.
security = user
passdb backend = tdbsam
En la anterior definición se establecen las siguientes propiedades para

Samba en la sección [global]:
Security: indica como los clientes podrán acceder a los

servicios de Samba, “user” define que será usando username y
passwords.
interfaces: interfaz que usará Samba para escuchar peticiones
host allow: host o redes que podrán usar el servicio
Siguiendo la edición del archivo de configuración de Samba (al final de

éste) es necesario agregar los recursos a compartir, en este caso las carpetas
previamente creadas:
[tesoreria]
comment = Grupo Tesorería
path = /datos/tesoreria
writable = yes
valid users = @tesoreria
[rrhh]
comment = Grupo RRHH
path = /datos/rrhh
writable = yes
valid users = @rrhh
Lo que se manifiesta en este caso son dos recursos, una llamado
“tesoreria” y otro llamado “rrhh”, los cuales estarán permitidos unicay
exclusivamente a los grupos correspondientes, los cuales se escriben con el
caractér “@”. Tenga presente que cada usuario creado, en este caso “t1” y
“r1” tendrán una carpeta en /home donde podrán guardar información que
solo ellos podrán ver y manipular.
Una vez finalizada la edición del archivo de configuración se ejecuta un

“testparm” para validar la edición del archivo de configuración de Samba.
[root@sr1 ~]# testparm
Validada de manera satisfactoria el archivo de configuración de Samba

se inicia y se activa el servicio para el arranque del servidor Linux, así como
se establece la regla de FirewallD para que permita recibir este tipo de
peticiones:
[root@sr1 ~]# systemctl enable smb

[root@sr1 ~]# systemctl start smb
[root@sr1 ~]# firewall-cmd --permanent --add-service=samba
[root@sr1 ~]# firewall-cmd --reload
DESPLIEGUE DE CLIENTES SMB
Para acceder a los servicios de este servidor de archivos usted podrá

desde un equipo con sistema Apple Mac Osx realizar una conexión desde la
aplicación “Finder”, menú “Go / Connect to Server …”; en esta oportunidad
nos registraremos usando el usuario “t1” previamente creado, como se
Para el caso de clientes Microsoft Windows, como es el caso de

Windows 10 usted podrá usar el “Explorador de Windows” para conectarse
con el servidor Samba desde la barra de direcciones de esta herramienta,
introduciendo un \\192.168.0.201, como se aprecia en las siguiente imágen:
Una vez digitadas las credenciales correspondientes usted podrá guardar
archivos según corresponda.
En el caso de que se requiera conectar un servidor Linux RHEL 8 al
servidor de archivos desplegado en Samba previamente, usted deberá
realizar lo siguiente sobre ese servidor:
[root@loadbalancer ~]# yum -y install cifs-utils

Last metadata expiration check: 5:42:05 ago on Wed 24 Mar 2021
10:46:12 AM -05.
Complete!
[root@loadbalancer ~]# mkdir /mnt/t1
[root@loadbalancer ~]# mount -o username=t1

//192.168.0.201/tesoreria /mnt/t1
Password for t1@//192.168.0.201/tesoreria: ******
[root@loadbalancer ~]# df -hT
//192.168.0.201/tesoreria cifs 44G 5.1G 39G 12% /mnt/t1
Para realizar un montaje persistente es necesario crear un archivo con las

credenciales de acceso (en este caso las del usuario “t1”), establecer un
permiso sobre el archivo y editar “/etc/fstab”, como se muestra a
continuación:
[root@loadbalancer ~]# vim credenciales.smb
username=t1
password=123456
[root@loadbalancer ~]# chmod 600 credenciales.smb
[root@loadbalancer ~]# vim /etc/fstab
//192.168.0.201/tesoreria /mnt/t1 cifs

credentials=/root/credenciales.smb 0 0
[root@loadbalancer ~]# udevadm settle
[root@loadbalancer ~]# systemctl daemon-reload
[root@loadbalancer ~]# mount -a
Para verificar la conectividad con el servidor 192.168.0.201 ejecute lo

siguiente:
[root@loadbalancer ~]# df -hT

Filesystem Type Size Used
//192.168.0.201/tesoreria cifs 44G 5.1G 39G 12% /mnt/t1
INGRESO COMO MIEMBRO EN DOMINIO
DE WINDOWS SERVER
Desde RHEL 8 se proveen las herramientas para generar una integración
con Microsoft Windows Server y su Active Directory; el hecho de tener esta
integración permite ofrecer a los usuarios del dominio alguna de las
siguientes características:
Autenticar a los usuarios del dominio en los servicios locales,

como sshd
Compartir directorios e impresoras alojadas en el servidor
Linux para que los usuarios del dominio puedan acceder a estos
recursos.
Sin embargo antes de gozar de estos privilegios es necesario introducir al

servidor RHEL dentro del dominio de Windows Server, procedimiento inicia
declarando la actualización de las políticas criptográficas, como se muestra a
continuación:
[root@loadbalancer ~]# update-crypto-policies --set

DEFAULT:AD-SUPPORT
Setting system policy to DEFAULT:AD-SUPPORT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
Esta actualización solicita un “reboot” del sistema:
[root@loadbalancer ~]# systemctl reboot
Se hace necesario la instalación de algunas aplicaciones, como sigue:
[root@loadbalancer ~]# yum install realmd oddjob-mkhomedir

oddjob samba-winbind-clients samba-winbind samba-common-
tools samba-winbind-krb5-locator
Last metadata expiration check: 0:59:36 ago on Wed 24 Mar 2021 04:33:08 PM -05.
Package realmd-0.16.3-19.el8.x86_64 is already installed.
Package oddjob-mkhomedir-0.34.5-3.el8.x86_64 is already installed.
Package oddjob-0.34.5-3.el8.x86_64 is already installed.
========================================================================
========================================================================
Installing:
samba-common-tools x86_64 4.12.3-14.el8_3 rhel-8-for-x86_64-baseos-rpms 484 k
samba-winbind x86_64 4.12.3-14.el8_3 rhel-8-for-x86_64-baseos-rpms 567 k
samba-winbind-clients x86_64 4.12.3-14.el8_3 rhel-8-for-x86_64-baseos-rpms 149 k
samba-winbind-krb5-locator x86_64 4.12.3-14.el8_3 rhel-8-for-x86_64-baseos-rpms 95 k
samba-libs x86_64 4.12.3-14.el8_3 rhel-8-for-x86_64-baseos-rpms 188 k
samba-winbind-modules x86_64 4.12.3-14.el8_3 rhel-8-for-x86_64-baseos-rpms 124 k
Transaction Summary
==================================================================================================================
Install 6 Packages

Is this ok [y/N]: y
Installed:
samba-common-tools-4.12.3-14.el8_3.x86_64 samba-libs-4.12.3-14.el8_3.x86_64
samba-winbind-4.12.3-14.el8_3.x86_64 samba-winbind-clients-4.12.3-14.el8_3.x86_64
samba-winbind-krb5-locator-4.12.3-14.el8_3.x86_64 samba-winbind-modules-4.12.3-14.el8_3.x86_64
Es necesario instalar Samba para realizar la integración:
[root@loadbalancer ~]# yum install samba

Last metadata expiration check: 1:01:28 ago on Wed 24 Mar 2021 04:33:08 PM -05.
================================================================
================================
================================================================
================================
Installing:
samba x86_64 4.12.3-14.el8_3 rhel-8-for-x86_64-baseos-rpms
840 k
Transaction Summary
================================================================
================================
Install 1 Package

Is this ok [y/N]: y
samba-4.12.3-14.el8_3.x86_64.rpm 602 kB/s | 840 kB
00:01
-------------------------------------------------------------------------------------------------------------
-----
Total 602 kB/s | 840 kB 00:01
Running transaction
Preparing : 1/1
Installing : samba-4.12.3-14.el8_3.x86_64 1/1
Running scriptlet: samba-4.12.3-14.el8_3.x86_64 1/1
Verifying : samba-4.12.3-14.el8_3.x86_64 1/1
Installed:
samba-4.12.3-14.el8_3.x86_64
Complete!
Con la instalación de los paquetes realizada procedemos a renombrar el

archivo de configuración de Samba, en el momento de la integración se nos
genera un nuevo archivo de configuración:
[root@loadbalancer ~]# cd /etc/samba/
[root@loadbalancer samba]# ll
total 20
-rw-r--r--. 1 root root 20 Dec 4 13:04 lmhosts
-rw-r--r--. 1 root root 706 Dec 4 13:04 smb.conf
-rw-r--r--. 1 root root 11327 Dec 4 13:04 smb.conf.example
[root@loadbalancer samba]# mv smb.conf smb.conf.original
[root@loadbalancer samba]# ll
total 20
-rw-r--r--. 1 root root 20 Dec 4 13:04 lmhosts
-rw-r--r--. 1 root root 11327 Dec 4 13:04 smb.conf.example
-rw-r--r--. 1 root root 706 Dec 4 13:04 smb.conf.original
Antes de integrar el servidor RHEL al dominio se verifica por diferentes

métodos que el servidor Linux pueda alcanzar hasta el servidor de Microsoft
Active Directory:
[root@loadbalancer samba]# ping ad1.aptivalabs.net

PING ad1.aptivalabs.net (192.168.1.200) 56(84) bytes of data.
64 bytes from ad1.aptivalabs.net (192.168.1.200): icmp_seq=1 ttl=128 time=0.809 ms
^C
--- ad1.aptivalabs.net ping statistics ---
[root@loadbalancer samba]# nslookup ad1.aptivalabs.net

Server:192.168.1.200
Address:192.168.1.200#53
Name:ad1.aptivalabs.net
Address: 192.168.1.200
Registramos el servidor RHEL dentro del dominio de Windows Server:
[root@loadbalancer samba]# realm join --membership-

software=samba --client-software=winbind ad1.aptivalabs.net
Password for Administrator:
Una vez ingresado al dominio se revisa el estatus del servicio “winbind”

y se relanza, aprovechando para activarlo en el arranque del sistema
operativo:
[root@loadbalancer samba]# systemctl status winbind

● winbind.service - Samba Winbind Daemon
Loaded: loaded (/usr/lib/systemd/system/winbind.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-03-24 17:43:44 -05; 43s ago
Docs: man:winbindd(8)
man:samba(7)
man:smb.conf(5)
Main PID: 9302 (winbindd)
Status: "winbindd: ready to serve connections..."
Memory: 10.8M
CGroup: /system.slice/winbind.service
├─9302 /usr/sbin/winbindd --foreground --no-process-group
└─9367 /usr/sbin/winbindd --foreground --no-process-group
[root@loadbalancer samba]# systemctl enable winbind --now
Ya como miembro del dominio listamos los parámetros de la integración:
[root@loadbalancer ~]# realm list

aptivalabs.net
type: kerberos
realm-name: APTIVALABS.NET
domain-name: aptivalabs.net
configured: kerberos-member
server-software: active-directory
client-software: winbind
required-package: oddjob-mkhomedir
required-package: oddjob
required-package: samba-winbind-clients
required-package: samba-winbind
required-package: samba-common-tools
login-formats: APTIVALABS\%U
login-policy: allow-any-login
Para verificar la conectividad establecida es momento de listar usuarios y

grupos en Microsoft Active Directory, como se muestra a continuación:
[root@loadbalancer samba]# wbinfo -u

APTIVALABS\administrator
APTIVALABS\guest
APTIVALABS\krbtgt
Se listan los grupos definidos en Windows Server:
[root@loadbalancer samba]# wbinfo -g

APTIVALABS\domain computers
APTIVALABS\domain controllers
APTIVALABS\schema admins
APTIVALABS\enterprise admins
APTIVALABS\cert publishers
APTIVALABS\domain admins
APTIVALABS\domain users
APTIVALABS\domain guests
APTIVALABS\group policy creator owners
APTIVALABS\ras and ias servers
APTIVALABS\allowed rodc password replication group
APTIVALABS\denied rodc password replication group
APTIVALABS\read-only domain controllers
APTIVALABS\enterprise read-only domain controllers
APTIVALABS\cloneable domain controllers
APTIVALABS\protected users
APTIVALABS\key admins
APTIVALABS\enterprise key admins
APTIVALABS\dnsadmins
APTIVALABS\dnsupdateproxy
APTIVALABS\dhcp users
APTIVALABS\dhcp administrators
De la siguiente forma es posible conocer la identidad de los usuarios de

Windows Server, incluso podría registrarse en el sistema con el usuario
“Administrator”, como se muestra:
[root@loadbalancer samba]# getent passwd

"ad1\Administrator"
AD1\administrator:*:10000:10000::/home/administrator@AD1:/bin
/bash
[root@loadbalancer samba]# su - "ad1\Administrator"

Creating home directory for AD1\administrator.
[AD1\administrator@loadbalancer ~]$ id
uid=10000(AD1\administrator) gid=10000(AD1\none)
groups=10000(AD1\none)
[AD1\administrator@loadbalancer ~]$ exit
Dentro de Microsoft Active Directory se crea el usuario “jarus” para

verificar que en el servidor Linux pueda ser listado, como se evidencia a
continuación:
[root@loadbalancer samba]# wbinfo -u

APTIVALABS\administrator
APTIVALABS\guest
APTIVALABS\krbtgt
APTIVALABS\jarus
Aprovechamos para conocer un poco mas de la identidad de este usuario

y registrarnos con dentro del sistema Linux:
[root@loadbalancer samba]# getent passwd

"APTIVALABS\jarus"
APTIVALABS\jarus:*:2001106:2000513::/home/jarus@APTIVAL
ABS:/bin/bash
[root@loadbalancer samba]# su - "APTIVALABS\jarus"

Creating home directory for APTIVALABS\jarus.
[APTIVALABS\jarus@loadbalancer ~]$
[APTIVALABS\jarus@loadbalancer ~]$ id
uid=2001106(APTIVALABS\jarus)
gid=2000513(APTIVALABS\domain users)
groups=2000513(APTIVALABS\domain
users),2001106(APTIVALABS\jarus)
[APTIVALABS\jarus@loadbalancer ~]$ exit
Para finalizar, en la carpeta “/root” encontramos un archivo llamado

“credenciales.smb” al cual se le establecerán los permisos para que usuarios
y grupos creados en Microsoft Windows Server puedan actuar sobre él,
como se evidencia:
[root@loadbalancer ~]# ll
total 12
-rw-------. 1 root root 28 Mar 24 16:35 credenciales.smb
[root@loadbalancer ~]# chown

"APTIVALABS\Administrator":"APTIVALABS\Domain Users"
/root/credenciales.smb
[root@loadbalancer ~]# ll
total 12
-rw-------. 1 APTIVALABS\administrator APTIVALABS\domain users 28 Mar 24 16:35
credenciales.smb
IMPLEMENTANDO UN RELAY DE
CORREO CON POSTFIX Y GMAIL
En muchas ocasiones se hace necesario que un servidor Linux pueda
notificar los eventos que ocurren en el sistema a través del correo
electrónico; algunas empresas han adquirido la consola de Gmail con su
gestor empresarial de cuentas de correo electrónico y preferirían utilizar este
servicio para el envío de notificaciones de sus servidores. En este ejercicio
se explica como utilizar un servicio local (Postfix) de correo para que en su
integración Gmail los servidores Linux puedan realizar el envío de correo
electrónico de forma segura.
El procedimiento inicia con la instalación de las aplicaciones necesarias

para lograr el objetivo: Postfix, las herramientas cyrus-sasl y la aplicación
“mailx”:
[root@sr1 ~]# yum install postfix -y

Last metadata expiration check: 0:04:26 ago on Thu 25 Mar 2021 11:59:53 AM EDT.
================================================================
========
Size
================================================================
========
Installing:
postfix x86_64 2:3.3.1-12.el8_3.1 rhel-8-for-x86_64-baseos-
rpms 1.5 M

postfix-2:3.3.1-12.el8_3.1.x86_64
Complete!
Al instalarse Postfix se ha creado la carpeta con los archivos de

configuración del servicio (entre ellos main.cf, el archivo de configuración
de Postfix), como se muestra a continuación:
[root@sr1 ~]# cd /etc/postfix/

[root@sr1 postfix]# ll
total 216
-rw-r--r--. 1 root root 29374 Jan 26 10:39 main.cf
Seguidamente se instalan las herramientas de Cyrus-SASL, la cual es

una implementación de SASL que facilita a los desarrolladores de
aplicaciones la integración de mecanismos de autenticación en sus
aplicaciones:
[root@sr1 postfix]# yum install cyrus-sasl-* -y

Se instala el cliente para el envío de correos y validación de la

configuración:
[root@sr1 postfix]# yum install mailx -y

Es momento de definir las credenciales que usará Postfix para

autenticarse ante Gmail, esta comunicación es cifrada pero es necesario
definir las credenciales (deberá contar con la contraseñadeaplicacion
generada en la plataforma Google Cuenta) en un archivo de texto del cual
Postfix va a generar una tabla de búsqueda, como se muestra a continuación:
[root@sr1 postfix]# vim sasl_passwd

[smtp.gmail.com]:587
username@gmail.com:contraseñadeaplicación
[root@sr1 postfix]# chmod 600 /etc/postfix/sasl_passwd
[root@sr1 postfix]# postmap hash:/etc/postfix/sasl_passwd
Esa tabla de búsqueda queda plasmada en el archivo generado por el

comando “postmap”, como se muestra:
[root@sr2 postfix]# ll sasl_passwd.db

-rw-------. 1 root root 12288 Mar 25 13:46 sasl_passwd.db
Es importante señalar que el campo “contraseñadeaplicación” hace

parte de los mecanismos de seguridad de Gmail; no defina en ese campo su
contraseña de Gmail sino la contraseña de aplicación, la cual debe ser
generada en la plataforma de Google Cuenta, como se relaciona a
continuación:
Es necesario configurar el cifrado TLS como política, para eso se crea el

archivo “tls_policy” y se registra en la tabla de busqueda de Postfix:
[root@sr1 postfix]# vim tls_policy

[smtp.gmail.com]:587 encrypt
[root@sr1 postfix]# postmap /etc/postfix/tls_policy
Es momento de editar el archivo configuración de Postfix el cual es

“main.cf”, sin embargo por temas de respaldo se hace una copia del archivo
original:
[root@sr1 postfix]# cp main.cf main.cf.original
Editando “main.cf” valide que las siguientes líneas se encuentren

relacionadas tal como se indica a continuación:
[root@sr1 postfix]# vim main.cf
#smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
#smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
#smtpd_tls_security_level = may
smtp_tls_CApath = /etc/pki/tls/certs
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
#smtp_tls_security_level = may
meta_directory = /etc/postfix
shlib_directory = /usr/lib64/postfix
relayhost = [smtp.gmail.com]:587
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
Es momento de reiniciar el servicio “postfix” y validar la funcionalidad:
[root@sr2 postfix]# systemctl restart postfix.service
[root@sr2 postfix]# echo mailtest | mail -s mailtest

fmestre@aptivalabs.com
En una segunda consola usted podrá validar que los correos estén
saliendo de manera efectiva hasta smtp.gmail.com:587, como se muestra:
[root@sr1 ~]# tail -f /var/log/maillog

Mar 25 13:15:42 sr1 postfix/pickup[8203]: 656C620AACA7: uid=0 from=<root>
Mar 25 13:15:42 sr1 postfix/cleanup[8209]: 656C620AACA7: message-id=
<20210325171542.656C620AACA7@sr1.aptivalabs.net>
Mar 25 13:15:42 sr1 postfix/qmgr[8204]: 656C620AACA7: from=
<root@sr1.aptivalabs.net>, size=449, nrcpt=1 (queue active)
Mar 25 13:15:44 sr1 postfix/smtp[8211]: 656C620AACA7: to=
<fmestre@aptivalabs.com>, relay=smtp.gmail.com[108.177.11.109]:587, delay=2.1,
delays=0.03/0.05/0.9/1.1, dsn=2.0.0, status=sent (250 2.0.0 OK 1616692544
70sm726442uas.9 - gsmtp)
Mar 25 13:15:44 sr1 postfix/qmgr[8204]: 656C620AACA7: removed
Dentro de las reglas de comunicación del protocolo SMTP está que el

código 250 indica que el correo ha sido enviado a satisfacción.
MONTAJE DE OBJETOS DE AMAZON
WEB SERVICES - S3 EN LINUX
Una funcionalidad interesante para los que están combinando los
entornos On-Premise con los servicios de Nube Pública en especial con los
servicios de almacenamiento que en esas nubes se disponen, es el poder
realizar un montaje local y a través de él colocar la data que se requiera en el
servicio de almacenamiento.
En esta oportunidad se utilizará el servicio de almacenamiento S3 de

Amazon Web Services como servicio para hospedar la data generada en un
servidor RHEL 8, esto es interesante por ejemplo para guardar en AWS S3
mediante un crontab los backups diarios generados por aplicaciones o
volcados realizados sobre las bases de datos, en realidad lo que necesite
guardar, además de aprovechar las funcionalidades de este servicio de
almacenamiento como lo es el ciclo de vida de los datos para la optimización
de los costos, etc.
El ejercicio a desarrollar a continuación nos muestra un objeto (bucket)

en AWS S3 llamado “aptiva” en el cual se pueden guardar datos de cualquier
tipo; lo que se realizará en este procedimiento es que un servidor RHEL
pueda guardar información en ese bucket a través de la definición de un
punto de montaje local. La siguiente imagen nos muestra el bucket de AWS
S3 llamado “aptiva”:
Para realizar la instalación del paquete que nos permitirá realizar el
montaje del bucket de AWS S3 en el servidor Linux es necesario instalar un
repositorio adicional dado a que esta aplicación no hace parte del grupo de
paquetes soportados por Red Hat. Este repositorio se llama EPEL.
Se realiza la instalación de EPEL 8, como se muestra:
[root@sr2 ~]# yum install

https://dl.fedoraproject.org/pub/epel/epel-release-latest-
8.noarch.rpm
Last metadata expiration check: 1:59:33 ago on Thu 25 Mar 2021 01:41:29 PM EDT.
epel-release-latest-8.noarch.rpm 54 kB/s | 22 kB
00:00
================================================================
=========
Size
================================================================
=========
Installing:
epel-release noarch 8-10.el8 @commandline
22 k
Transaction Summary
================================================================
=========
Install 1 Package
Total size: 22 k
Is this ok [y/N]: y
Desplegado el repositorio EPEL es momento de instalar la aplicación

“s3fs” como se muestra a continuación:
[root@sr2 ~]# yum install s3fs-fuse

Extra Packages for Enterprise Linux Modular 8 - x86_64 226 kB/s
| 557 kB 00:02
Extra Packages for Enterprise Linux 8 - x86_64 1.6 MB/s |
9.1 MB 00:05
Last metadata expiration check: 0:00:01 ago on Thu 25 Mar 2021 03:41:32 PM EDT.
================================================================
=========
Size
================================================================
=========
Installing:
s3fs-fuse x86_64 1.89-1.el8 epel 344
k
Transaction Summary
================================================================
=========
Install 1 Package

Is this ok [y/N]: y
AWS a través del servicio de administración de identidad le permite

generar las credenciales de acceso para registrarse en AWS y poder usar sus
servicios. Para el desarrollo de este ejercicio se utilizan una credenciales de
prueba las cuales se deben guardar en el archivo “/etc/passwd-s3fs” en el
formato que se describe a continuación:
[root@sr2 s3fs-fuse]# echo

"AKIA2IXLZ7Q4EDGEEC73:W0c/PWvHbn8liNj2BNN869JhdvP
aRtXj8SSsmm1J" > /etc/passwd-s3fs
Se verifica que el archivo efectivamente se haya creado con las
siguientes instrucciones:
[root@sr2 s3fs-fuse]# ll /etc/passwd-s3fs

-rw-r--r--. 1 root root 62 Mar 25 15:22 /etc/passwd-s3fs
[root@sr2 s3fs-fuse]# cat /etc/passwd-s3fs

AKIA2IXLZ7Q4EDGEEC73:W0c/PWvHbn8liNj2BNN869Jhd
vPaRtXj8SSsmm1J
Es necesario establecer permisos de lectura y escritura al propietario del

archivo:
[root@sr2 s3fs-fuse]# chmod 600 /etc/passwd-s3fs
Se crea el punto de montaje a través del cual se va a acceder al bucket de

AWS S3:
[root@sr2 s3fs-fuse]# mkdir /mnt/aptiva
Se define el montaje persistente del bucket en “/etc/fstab” y se verifica,

[root@sr2 s3fs-fuse]# echo "s3fs#aptiva /mnt/aptiva fuse

_netdev,rw,nosuid,nodev,allow_other,nonempty 0 0" >> /etc/fstab
[root@sr2 s3fs-fuse]# cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Thu Mar 18 14:56:05 2021
s3fs#aptiva /mnt/aptiva fuse _netdev,rw,nosuid,nodev,allow_other,nonempty 0 0
A continuación se realizan las actividades para el montaje
[root@sr2 s3fs-fuse]# udevadm settle

[root@sr2 s3fs-fuse]# systemctl daemon-reload
[root@sr1 ~]# mount -a
Una vez realizado el montaje se verifica éste con la siguiente instrucción:
[root@sr1 ~]# df -hT

s3fs fuse.s3fs 256T 0 256T 0% /mnt/aptiva
Con la instrucción anterior se puede detallar que el punto de montaje ha

sido definido en /mnt/aptiva con una disponibilidad de 256T de
almacenamiento; en este momento usted como Administrador Linux podrá
colocar data en ese punto de montaje teniendo en cuenta la calidad y la
velocidad en la transferencia de información está definida por la conexión a
Internet que usted tenga contratada con su proveedor de servicio. Un vistazo
al contenido del bucket de S3 es el siguiente:
[root@sr1 ~]# ll /mnt/aptiva/

total 1581057
-rw-r--r--. 1 root root 0 Feb 19 2020 1
-rw-r--r--. 1 root root 136882 Feb 19 2020 archivo.tar
-rw-r-----. 1 root root 11894 Feb 19 2020 synologic.jpg
Para finalizar el ejercicio se creará dentro del punto de montaje la carpeta

“pruebas” y se crearán archivos vacios desde la interfaz de línea de
comandos, el objetivo con esto es comprobar que efectivamente los datos se
están guardando en el bucket de S3, como se detalla a continuación:
[root@sr1 ~]# cd /mnt/aptiva/

[root@sr1 aptiva]# mkdir pruebas
[root@sr1 aptiva]# cd pruebas/
[root@sr1 pruebas]# touch 1 2 3 4 5 6
Presentando una captura de pantalla de la consola de administración web

de AWS podemos comprobar que ha sido satisfactoria la practica al ver la
misma data en los dos escenarios:
INSTALACIÓN Y PUESTA EN
PRODUCCIÓN DE POSTGRESQL
Es recurrente en el escenario corporativo encontrar sistemas de
información desplegados en servidores de aplicaciones que realizan
transacciones sobre bases de datos locales, en este caso bases de datos
instaladas y configuradas sobre RHEL 8 o algún sistema derivado. En este
ejercicio se desplegará el motor de base de datos PostgreSQL versión 10, el
cual es el stream por default ya que existe la opción de instalar la versión 9.6
o 12.
Iniciamos cambiando el nombre del host:
[root@loadbalancer ~]# hostnamectl set-hostname

bd1.aptivalabs.net
[root@loadbalancer ~]# exit
logout
$ ssh -l root 192.168.0.200

[root@bd1 ~]#
Se listan los diferentes streams del modulo PostgreSQL
[root@bd1 ~]# yum module list postgresql

Last metadata expiration check: 0:06:02 ago on Fri 26 Mar 2021 09:31:55 AM -05.
postgresql 9.6 client, server [d] PostgreSQL server and client

module
postgresql 10 [d] client, server [d] PostgreSQL server and client
module
postgresql 12 client, server [d] PostgreSQL server and client
module
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

Se verifica si el stream “postgresql:10” cuenta con “profiles” que
especifiquen la instalación:
[root@bd1 ~]# yum module info postgresql:10 --profile

Name : postgresql:10:8020020200825115746:4cda2c84:x86_64
client : postgresql
server : postgresql-server
Definida la preferencia de instalar el stream “postgresql:10”, procedemos

a instalar PostgreSQL en esa versión:
[root@bd1 ~]# yum install postgresql-server

Installed:
libpq-12.5-1.el8_3.x86_64 postgresql-10.15-
1.module+el8.3.0+8944+1ca16b1f.x86_64
postgresql-server-10.15-1.module+el8.3.0+8944+1ca16b1f.x86_64
Complete!
Paso siguiente es necesario inicializar la base de datos, iniciar el servicio

y activar en el arranque del sistema operativo el inicio del motor de base de
datos, como se muestra a continuación:
[root@bd1 ~]# postgresql-setup --initdb

* Initializing database in '/var/lib/pgsql/data'
* Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log
[root@bd1 ~]# systemctl enable postgresql.service --now

Created symlink /etc/systemd/system/multi-user.target.wants/postgresql.service →
/usr/lib/systemd/system/postgresql.service.
Se verifican los procesos del sistema para validar que el servicio esté
ejecutándose:
[root@bd1 ~]# ps -fe

postgres 5973 1 0 09:41 ? 00:00:00 /usr/bin/postmaster -D /var/lib/pgsql/data
postgres 5974 5973 0 09:41 ? 00:00:00 postgres: logger process
postgres 5976 5973 0 09:41 ? 00:00:00 postgres: checkpointer process
postgres 5977 5973 0 09:41 ? 00:00:00 postgres: writer process
postgres 5978 5973 0 09:41 ? 00:00:00 postgres: wal writer process
postgres 5979 5973 0 09:41 ? 00:00:00 postgres: autovacuum launcher process
postgres 5980 5973 0 09:41 ? 00:00:00 postgres: stats collector process
postgres 5981 5973 0 09:41 ? 00:00:00 postgres: bgworker: logical replication launcher
Se establecen la reglas de FirewallD para recibir conexiones al motor de

base de datos:
[root@bd1 ~]# firewall-cmd --add-service=postgresql --

permanent
success
[root@bd1 ~]# firewall-cmd --reload

success
Antes de poner la base de datos en producción verificamos que en un

posible boot del sistema el motor de base de datos inicie con el sistema
operativo:
[root@sr2 ~]# systemctl reboot
[root@bd1 ~]# systemctl status postgresql.service

● postgresql.service - PostgreSQL database server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled;
vendor preset: disabled)
Active: active (running) since Fri 2021-03-26 09:43:18 -05; 33s ago
Se valida que el usuario “postgres” el cual es el superusuario pueda

acceder al servicio, como se muestra a continuación:
[root@bd1 ~]# su - postgres
[postgres@bd1 ~]$ psql

psql (10.15)
Type "help" for help.
postgres=# \q
[postgres@bd1 ~]$ exit
logout
POSTGRESQL – CREACIÓN DE BASE DE DATOS Y VOLCADO
Aprovechando el despliegue anteriormente generado, se creará una base

de datos de pruebas y se realizará un respaldo para efectos de comprobación,
teniendo presente que este procedimiento se realizará con el super usuario de
la base de datos, como se muestra a continuación:

Last login: Fri Mar 26 09:44:24 -05 2021 on pts/0
Se crea una nueva base de datos llamada “test”:

[postgres@bd1 ~]$ createdb test
Ingresamos a la CLI de PostgreSQL, exactamente a la base de datos que

se acaba de crear:
[postgres@bd1 ~]$ psql test

psql (10.15)
La siguiente instrucción crea la tabla “usuarios” y su respectiva

estructura, después listaremos esta estructura del catalogo:
test=# create table usuarios ( nombre varchar(30), clave varchar(10)

);
CREATE TABLE
test=# select
table_name,column_name,udt_name,character_maximum_length from
information_schema.columns where table_name = 'usuarios';
table_name | column_name | udt_name |
character_maximum_length
------------+-------------+----------+--------------------------
usuarios | nombre | varchar | 30
usuarios | clave | varchar | 10
(2 rows)
Las siguientes instrucciones insertarán registros en la base de datos para

después listarlos:
test=# insert into usuarios (nombre, clave) values
('Mariano','payaso');
INSERT 0 1
test=# insert into usuarios (nombre, clave) values ('Pablo','jfx344');

INSERT 0 1
test=# insert into usuarios (nombre, clave) values ('Ana','tru3fal');

INSERT 0 1
test=# select * from usuarios;

nombre | clave
---------+---------
Mariano | payaso
Pablo | jfx344
Ana | tru3fal
(3 rows)
Es necesario salir del CLI del PostgreSQL:
test=# \q
A continuación se genera un volcado de la base de datos y se lista el

contenido del archivo:
[postgres@bd1 ~]$ pg_dump test > /tmp/backup.sql
[postgres@bd1 ~]$ cat /tmp/backup.sql

--
-- PostgreSQL database dump
--
-- Dumped from database version 10.15

-- Dumped by pg_dump version 10.15
SET statement_timeout = 0;
SET lock_timeout = 0;
EJERCICIO DE RESTAURACIÓN DE BASE DE DATOS
Una actividad común en la administración de base de datos PostgreSQL

es la restauración de una base de datos de gran tamaño, actividad que podría
durar horas en su implementación. En el siguiente ejercicio se restarurará un
backup realizado a nivel de volcado el cual tiene un tamaño de 1.56; para la
realización de esta actividad se creará una nueva base de datos en la cual se
restaurará el volcado, como se muestra a continuación:
[postgres@bd1 ~]$ ll -h /tmp/BD-historico20180828.sql

-rw-r--r--. 1 root root 1.6G Mar 26 10:45 /tmp/BD-
historico20180828.sql
Se crea la base de datos llamada “empresa”:
[postgres@bd1 ~]$ createdb empresa
Se lanza el proceso de restauración en la base de datos “empresa” del

volcado previamente generado:
[postgres@bd1 ~]$ pg_restore -d empresa /tmp/BD-

historico20180828.sql
Una vez finalizada la restauración se verifica que las tablas hayan sido
creadas, como se muestra a continuación:
[postgres@bd1 ~]$ psql empresa

psql (10.15)
empresa=# \d
List of relations
Schema | Name | Type | Owner
--------+------------------------+----------+----------
public | cartera | table | postgres
public | ciudades | table | postgres
public | departamentos| table | postgres
public | barrios | table | postgres
CONSULTAS DE METADATA EN POSTGRESQL
Realizada la restauración es posible preguntar al motor de base de datos

información relacionada con los espacios ocupados en la misma, como se
realiza en la siguiente instrucción donde se pregunta por los tamaños de
todas las bases de datos en el motor:
empresa=# SELECT pg_database.datname,

pg_size_pretty(pg_database_size(pg_database.datname)) AS SIZE
FROM pg_database;
datname | size
-----------+---------
postgres | 7335 kB
test | 7343 kB
template1 | 7201 kB
template0| 7201 kB
empresa| 15 GB
De la siguiente forma se consulta por el tamaño de una base de datos en

específico:
empresa=# SELECT pg_size_pretty( pg_database_size('empresa') );

pg_size_pretty
----------------
15 GB
(1 row)
De la siguiente forma podemos ver el tamaño de las tablas en una base

de datos:
empresa=# SELECT schemaname,

tablename,pg_size_pretty(pg_total_relation_size(tablename::regclass::o
id))
FROM pg_tables
WHERE schemaname NOT IN('pg_catalog',
'information_schema')
;
schemaname | tablename | pg_size_pretty
------------+------------------------+----------------
public | cartera | 357 MB
public | ciudades| 240 kB
public | departamentos| 608 kB
public | barrios| 96 kB
INSTALACIÓN DE POSTGRESQL EN UN FILESYSTEM
SECUNDARIO
En el siguiente ejercicio se instalará PostgreSQL utilizando una ruta

distinta para el almacenamiento de datos, la ruta por default para la creación
del “cluster” de PostgreSQL es /var/lib/pgsql/data, la ruta que se usará en
este ejercicio es /pgsql-data; para el desarrollo de esta practica se agrega un
nuevo disco (aparecerá como /dev/sdb) al sistema el cual es llevado a un LV
formateado con XFS y establecido sobre el punto de montaje /pgsql-data; tal
preparación se ejecuta como sigue a continuación:
Se identifica el disco de 100GB que será llevado a la estructura de

LVM2, como se visualiza en las siguientes instrucciones:
[root@bd2 ~]# lsblk

sdb 8:16 0 100G 0 disk
[root@bd2 ~]# pvcreate /dev/sdb

Physical volume "/dev/sdb" successfully created.
[root@bd2 ~]# vgcreate datos /dev/sdb

[root@bd2 ~]# lvcreate -l 100%free -n bd2 datos

Logical volume "bd2" created.
[root@bd2 ~]# lvs

Cpy%Sync Convert
bd2 datos -wi-a----- <100.00g
Se asigna el sistema de archivos XFS al nuevo dispositivo lógico creado:
[root@bd2 ~]# mkfs.xfs /dev/datos/bd2

meta-data=/dev/datos/bd2 isize=512 agcount=4, agsize=6553344 blks
Se crea “/pgsql-data” como punto de montaje del sistema de archivos

creado previamente:
[root@bd2 ~]# mkdir /pgsql-data
Es momento de establecer de forma persistente el punto de montaje

establecido para alojar los datos de PostgreSQL:
[root@bd2 ~]# blkid | grep bd2 >> /etc/fstab
[root@bd2 ~]# vim /etc/fstab
UUID="f32b947b-5203-43dd-9751-c81980584207" /pgsql-data xfs

defaults 0 0
[root@bd2 ~]# udevadm settle

[root@bd2 ~]# systemctl daemon-reload
[root@bd2 ~]# mount -a
Se verifica que el punto de montaje se encuentre disponible para la

inicialización de la base de datos:
[root@bd2 ~]# df -hT

/dev/mapper/datos-bd2 xfs 100G 746M 100G 1% /pgsql-data
Es necesario deshabilitar el modulo de RHEL que instala PostgreSQL

debido a que la instalación se hará agregando el repositorio oficial de los
desarrolladores de PostgreSQL:
[root@bd2 ~]# yum module disable postgresql

Last metadata expiration check: 0:19:53 ago on Fri 26 Mar 2021
01:07:38 PM EDT.
Se instala el repositorio oficial de los desarrolladores de PostgreSQL:
[root@bd2 ~]# yum -y install

https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-
x86_64/pgdg-redhat-repo-latest.noarch.rpm
Last metadata expiration check: 0:20:55 ago on Fri 26 Mar 2021 01:07:38 PM EDT.
pgdg-redhat-repo-latest.noarch.rpm 1.2 kB/s | 6.8 kB
00:05
================================================================
=========
Size
================================================================
=========
Installing:
pgdg-redhat-repo noarch 42.0-14 @commandline
6.8 k
Se visualiza en “/etc/yum.repos.d/” el nuevo repositorio del sistema;
desplazándonos a esta ruta se edita tal archivo de repositorio para solo
habilitar el repo de PostgreSQL versión 10.
[root@bd2 ~]# cd /etc/yum.repos.d/
[root@bd2 yum.repos.d]# ll
total 104
-rw-r--r--. 1 root root 9738 Sep 24 2020 pgdg-redhat-all.repo
-rw-r--r--. 1 root root 94154 Mar 26 13:05 redhat.repo
En la edición del archivo de repositorio “pgdg-redhat-all.repo” es

necesario llevar el campo “enabled=0” para aquellos repositorios de la
versiones 12, 11 y 9.6 de PostgreSQL, solo el repositorio de la versión 10
debe tener “enabled=1”; se muestra como debe quedar los repos a no
utilizar:
[root@bd2 yum.repos.d]# vim pgdg-redhat-all.repo

[pgdg12]
name=PostgreSQL 12 for RHEL/CentOS $releasever - $basearch
baseurl=https://download.postgresql.org/pub/repos/yum/12/redhat/rhel-$releasever-$basea
rch
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG
Es momento de instalar PostgreSQL, como se detalla a continuación:
[root@bd2 yum.repos.d]# yum install -y postgresql10-server

postgresql10-contrib
PostgreSQL common RPMs for RHEL/CentOS 8 - x86_64 172
kB/s | 461 kB 00:02
PostgreSQL 10 for RHEL/CentOS 8 - x86_64 201 kB/s |
448 kB 00:02
PostgreSQL 9.5 for RHEL/CentOS 8 - x86_64 223 kB/s |
384 kB 00:01
================================================================
=====================================
Size
================================================================
=====================================
Installing:
postgresql10-contrib x86_64 10.16-1PGDG.rhel8 pgdg10
619 k
postgresql10-server x86_64 10.16-1PGDG.rhel8 pgdg10
4.7 M
postgresql10 x86_64 10.16-1PGDG.rhel8 pgdg10
1.6 M
postgresql10-libs x86_64 10.16-1PGDG.rhel8 pgdg10
384 k
Antes de inicializar la base de datos es necesario asignar los permisos a

la carpeta para hospedar la data:
[root@bd2 ~]# chown postgres:postgres /pgsql-data
Se inicializa PostgreSQL observando un mesaje “failed” en la actividad,

sin embargo esto está relacionado con la ruta por default la cual no se va a
utilizar:
[root@bd2 ~]# sudo PGSETUP_INITDB_OPTIONS="-D

/pgsql-data/" /usr/pgsql-10/bin/postgresql-10-setup initdb
Initializing database ... failed, see /var/lib/pgsql/10/initdb.log
Dandole un vistazo al log de creación del cluster podemos observar el
detalle de la inicialización:
[root@bd2 ~]# more /var/lib/pgsql/10/initdb.log

The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.UTF-8".

The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /pgsql-data ... ok

creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default timezone ... America/New_York
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
/usr/pgsql-10/bin/pg_ctl -D /pgsql-data/ -l logfile start
La creación del cluster nos deja el siguiente contenido en /pgsql-data :
[root@bd2 ~]# ll /pgsql-data/

total 48
-rw-------. 1 postgres postgres 3 Mar 26 13:35 PG_VERSION
drwx------. 5 postgres postgres 41 Mar 26 13:35 base
drwx------. 2 postgres postgres 4096 Mar 26 13:35 global
drwx------. 2 postgres postgres 6 Mar 26 13:35 pg_commit_ts
drwx------. 2 postgres postgres 6 Mar 26 13:35 pg_dynshmem
-rw-------. 1 postgres postgres 4269 Mar 26 13:35 pg_hba.conf
-rw-------. 1 postgres postgres 1636 Mar 26 13:35 pg_ident.conf
Se edita la unidad “postgresql-10.service” para que el sistema en los

reinicios tome la ruta /pgsql-data :
[root@bd2 ~]# systemctl edit postgresql-10.service

[Service]
Environment=PGDATA=/pgsql-data/
[root@bd2 ~]# cat /etc/systemd/system/postgresql-

10.service.d/override.conf
[Service]
Environment=PGDATA=/pgsql-data/sudo systemctl daemon-reload
Iniciamos PostgreSQL y activamos el inicio del servicio en el arranque

del sistema operativo:
[root@bd2 ~]# systemctl enable postgresql-10.service --now

user.target.wants/postgresql-10.service →
/usr/lib/systemd/system/postgresql-10.service.
Al consultar el status podemos observar que el servicio “postgresql-

10.service” se encuentra activo:
[root@bd2 ~]# systemctl status postgresql-10.service

● postgresql-10.service - PostgreSQL 10 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-10.service;
enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/postgresql-10.service.d
└─override.conf
Active: active (running) since Fri 2021-03-26 13:39:55 EDT; 9s ago
Se le informa a FirewallD que acepte peticiones en la zona por default:
[root@bd2 pgsql-data]# firewall-cmd --add-service=postgresql --

permanent
success
[root@bd2 pgsql-data]# firewall-cmd --reload

success
Es momento de suplantar al usuario “postgres” y conectarnos a la base

de datos:
[postgres@bd2 ~]$ psql
psql (10.16)
postgres=# \q
[postgres@bd2 ~]$ exit
logout
El propósito de reiniciar es validar que cuando el sistema operativo inicie

el motor de base de datos lo haga con él de forma satisfactoria, como es el
caso en este ejercicio:
[root@bd2 ~]# systemctl reboot
[root@bd2 ~]# systemctl status postgresql-10.service

● postgresql-10.service - PostgreSQL 10 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-10.service; enabled; vendor preset:
disabled)
Drop-In: /etc/systemd/system/postgresql-10.service.d
└─override.conf
Active: active (running) since Fri 2021-03-26 13:42:30 EDT; 40s ago
Docs: https://www.postgresql.org/docs/10/static/
Process: 1013 ExecStartPre=/usr/pgsql-10/bin/postgresql-10-check-db-dir ${PGDATA}
(code=exited, status=0/SUCCESS)
Main PID: 1033 (postmaster)
Memory: 23.9M
CGroup: /system.slice/postgresql-10.service
├─1033 /usr/pgsql-10/bin/postmaster -D /pgsql-data/
├─1045 postgres: logger process
├─1047 postgres: checkpointer process
├─1048 postgres: writer process
├─1049 postgres: wal writer process
├─1050 postgres: autovacuum launcher process
├─1051 postgres: stats collector process
└─1052 postgres: bgworker: logical replication launcher
DEFINICIÓN DE ACCESO A LAS BASES DE DATOS
En las secciones anteriores se ha instalado PostgreSQL de diversas

formas, se han creado bases de datos, se han realizado volcados, se realizó
una restauración y se ha instalado el motor de base de datos utilizando un
sistema de archivos secundario, sin embargo, la base de datos está cerrada
para sus clientes, lo que es necesario cambiar para que el motor pueda recibir
solicitudes y realizar transacciones.
En este sentido revisaremos primeramente a FirewallD para comprobar

que la zona por default está permitiendo la entrada de peticiones, como se
[root@bd2 pgsql-data]# firewall-cmd --list-all

public (active)
target: default
interfaces: ens18
sources:
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
En la ruta donde se inicializó PostgreSQL (/pgsql-data) existen los

archivos para configurar el motor de base de datos; ahí se encontrarán los
archivos “postgresql.conf” y “pg_hba.conf”, el primero administra la
configuración general del motor de base de datos y el segundo administra los
accesos a las bases de datos. Para recibir solicitudes es necesario editarlos,
[root@bd2 pgsql-data]# pwd

/pgsql-data
[root@bd2 pgsql-data]# ll postgresql.conf

-rw-------. 1 postgres postgres 22982 Mar 26 15:41 postgresql.conf
En el archivo postgresql.conf se deben activar los parámetros
“listen_addresses” y “port = 5432”:
[root@bd2 pgsql-data]# vim postgresql.conf

listen_addresses = '*'# what IP address(es) to listen on;
port = 5432# (change requires restart)
Seguido a esto el archivo “pg_hba.conf” debe contener las autorizaciones

pertinentes a o a las bases de datos del motor:
[root@bd2 pgsql-data]# ll pg_hba.conf

-rw-------. 1 postgres postgres 4305 Mar 26 15:38 pg_hba.conf
El caso puntual que se observa en la siguiente instrucción es una

autorización tipo “host” a todas las bases de datos gobernadas por
PostgreSQL, permitiendo el acceso a todos los usuarios pero cerrando la
conexión al host 192.168.0.200 a través de un método cifrado de ingreso de
contraseña:
[root@bd2 pgsql-data]# vim pg_hba.conf

# TYPE DATABASE USER ADDRESS METHOD
hostallall192.168.0.200/32md5
Despues de los cambios realizados es necesario reinciar el servicio

“postgresql-10.service”:
[root@bd2 pgsql-data]# systemctl restart postgresql-10.service

GRABACIÓN DE SESIONES DE USUARIO
La funcionalidad de grabación de sesiones es posible gracias al paquete
“tlog” el cual brinda la capacidad de grabar y reproducir sesiones de la
terminal del usuario; “tlog” brinda la capacidad de realizar esta grabación
por usuario o grupos de usuarios, almacenando en un archivo de texto el
estándar input y output. Es importante aclarar que la grabación está
desactivada de forma predeterminada por lo que interceptaría información
sensible. Esta solución es útil para casos de auditorias a usuarios, revisión
de incidentes de seguridad o cualquier eventualidad relacionada con
procedimientos forenses. Los componentes claves de la solución de
grabación son la aplicación “tlog”, el servicio SSSD y Cockpit. El
procedimiento inicia con la instalación de las aplicación “tlog” y “cockpit-
session-recording”:
[root@bd2 ~]# yum install tlog

Installed:
tlog-8-2.el8.x86_64
[root@bd2 ~]# yum install cockpit-session-recording

Installed:
cockpit-session-recording-4-2.el8.noarch
Una vez instaladas las aplicaciones desde la consolo de Cockpit

visualizaremos en el menú izquierdo el ítem “Session Recording”:
Se creará un usuario para la demostración de la grabación de la sesión:
[root@bd2 ssh]# useradd admin-backups
[root@bd2 ssh]# passwd admin-backups

Changing password for user admin-backups.
New password:
A través de Cockpit se definen los parámetros de la grabación de

sesiones. En la consola gráfica en la sección “Session Recording” ubique el
icono del “piñón” lo que lo llevará a la sección de configuración:
En la sección “SSSD Configuration” se escribe el nombre de usuario o
grupos que se desean monitorear y se guarda, esa configuración queda
registrada en /etc/sssd/conf.d/sssd-session-recording.conf. Seguido a esto en
el archivo de configuración de SSH se comentan las líneas que se detallan a
continuación:
[root@bd2 ~]# vim /etc/ssh/sshd_config

# Accept locale-related environment variables
#AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE
LC_MONETARY LC_MESSAGES
#AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE
LC_MEASUREMENT
#AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
#AcceptEnv XMODIFIERS
Estas lineas están relacionadas con las variables de ambiente que toma
cada usuario cuando hace login via SSH y se ha descubierto que “tlog” entra
en conflicto con la configuración por default. Una vez comentadas las líneas
permita que SSH relea su archivo de configuración:
[root@bd2 ~]# systemctl reload sshd.service
Para comprobar la funcionalidad se intenta el registro en el sistema del

usuario “admin-backups” y una vez digitada la credencial de acceso el
usuario podrá ver un mensaje como el siguiente:
$ ssh -l admin-backups 192.168.0.201

admin-backups@192.168.0.201's password:
Locale charset is ANSI_X3.4-1968 (ASCII)

Assuming locale environment is lost and charset is UTF-8
ATTENTION! Your session is being recorded!
[admin-backups@bd2 ~]$
Todo lo que el usuario “admin-backups” realice sobre el sistema será

grabado y esa grabación se podrá visualizar en cockpit o mediante la
aplicación “tlog-play”.
PLATAFORMA PARA CONTAINERS LINUX
– PODMAN/SKOPEO
Un contenedor es un proceso en ejecución, aislado, que toma recursos de
red y se integra con el almacenamiento que le integren; algunos llegan a
compararlo con maquinas virtuales pues el objetivo es el mismo sin embargo
están significativamente lejos de ser tecnologías similares.
La gestión de contenedores en RHEL8 se realiza gracias a aplicaciones

como “podman”, “skopeo” y “buildah”; el programa “podman” es utilizado
para administrar containers e imágenes, la aplicación “skopeo” inspecciona,
copia, elimina y firma imágenes de contenedores, y la aplicación “buildah”
es usada para crear nuevos containers, todo esto representa la nueva forma
como se gestionan containers ya que en versiones anteriores la herramienta
para esta gestión era hecho por Docker.
El siguiente ejercicio nos permitirá instalar la plataforma de

contenedores, descargar una imagen para luego lanzarla como contenedor,
gestionar ese contenedor y gestionar su imagen, el fin de esto es
contextualizarnos de las capacidades para el manejo individual de containers
pues la gestión clusterizada y de alta disponibilidad está dada con
plataformas como Kubernetes y Openshift; iniciamos listando los modulos
asociados a la plataforma de contenedores:
[root@bd1 ~]# yum module list --available container-tools

Last metadata expiration check: 0:19:21 ago on Thu 08 Apr 2021 05:18:38 PM -03.
container-tools rhel8 [d][e] common [ Most recent (rolling) versions of podman, buildah,
skopeo, runc, conmon, runc, conmon,
d] CRIU, Udica, etc as well as dependencies such as container-selinux
built and tested tog
ether, and updated as frequently as every 12 weeks.
container-tools 1.0 common [ Stable versions of podman 1.0, buildah 1.5, skopeo
0.1, runc, conmon, CRIU, Udica, etc
d] as well as dependencies such as container-selinux built and tested
together, and suppor
ted for 24 months.
container-tools 2.0 common [ Stable versions of podman 1.6, buildah 1.11, skopeo
0.1, runc, conmon, etc as well as d
d] ependencies such as container-selinux built and tested together, and
supported as docum
ented on the Application Stream lifecycle page.
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
Para este caso se observa que el modulo “container-tools” presenta

diversos streams; instalaremos el stream por default:
[root@bd1 ~]# yum module install container-tools -y

Last metadata expiration check: 0:22:47 ago on Thu 08 Apr 2021 05:18:38 PM -03.
================================================================
============================================
Package Arch Version Repository
Size
================================================================
============================================
crun x86_64 0.16-2.module+el8.3.1+9857+68fb1526 rhel-8-for-
python-podman-api noarch 1.2.0-0.2.gitd0a45fe.module+el8.3.1+9857+68fb1526
rhel-8-for-x86_64-appstream-rpms 43 k
skopeo x86_64 1:1.2.0-9.module+el8.3.1+9857+68fb1526 rhel-8-for-
x86_64-appstream-rpms 7.1 M
toolbox noarch 0.0.8-1.module+el8.3.1+9857+68fb1526 rhel-8-for-
udica noarch 0.2.4-1.module+el8.3.1+9857+68fb1526 rhel-8-for-
python3-psutil x86_64 5.4.3-10.el8 rhel-8-for-x86_64-
container-tools/common
Transaction Summary
===========================================================
Install 6 Packages

Una vez instalado el modulo podemos validar que las herramientas de
contenedores se encuentrén disponibles, como es el caso de la aplicación
“podman”, validando su disponibilidad de la siguiente forma:
[root@bd1 ~]# podman –help | more

Manage pods, containers and images
Usage:
podman [options] [command]
Available Commands:
attach Attach to a running container
auto-update Auto update containers according to their auto-update policy
build Build an image using instructions from Containerfiles
commit Create new image based on the changed container
container Manage containers
cp Copy files/folders between a container and the local filesystem
create Create but do not start a container
[root@bd1 ~]# podman info

host:
arch: amd64
buildahVersion: 1.18.0
cgroupManager: 1ystem
cgroupVersion: v1
conmon:
package: conmon-2.0.22-3.module+el8.3.1+9857+68fb1526.x86_64
path: /usr/bin/conmon
version: ‘conmon version 2.0.22, commit: a40e3092dbe499ea1d85ab339caea023b74829b9’
cpus: 8
distribution:
distribution: ‘”rhel”’
version: “8.3”
eventLogger: file
hostname: bd1.aptivalabs.net
El trabajo con contenedores requiere del uso de un registro donde se

almacenan las imágenes que después son desplegadas como contenedores,
en este caso Red Hat proporciona el registro “registry.access.redhat.com” el
cual usted puede usar utilizando sus credenciales de acceso al portal de Red
Hat, este registro se realiza de la siguiente forma:
[root@bd1 ~]# podman login registry.access.redhat.com

Username: su.usuario
Password:
Login Succeeded!
Una vez registrado usted podrá buscar imágenes de contenedores, en este

caso nos interesa la imagen llamada “ubi8”, como se muestra a continuación:
[root@bd1 ~]# podman search registry.access.redhat.com/ubi8 |

more
INDEX NAME DESCRIPTION
STARS OFFICIAL A
UTOMATED
redhat.com registry.access.redhat.com/ubi8/ubi-minimal Provides the latest release of the
Minimal R... 0
redhat.com registry.access.redhat.com/ubi8 The Universal Base Image is
designed and eng... 0
redhat.com registry.access.redhat.com/ubi7/ubi The Universal Base Image is
designed and eng... 0
redhat.com registry.access.redhat.com/ubi8/ubi-init Provides the latest release of the
Red Hat U... 0
redhat.com registry.access.redhat.com/ubi8-minimal The Universal Base Image
Minimal is a stripp... 0
redhat.com registry.access.redhat.com/ubi8-init The Universal Base Image Init is
designed to... 0
Identificada la imagen, se trae al entorno local con el parámetro “pull”

del comando “podman”, tal como se muestra:
[root@bd1 ~]# podman pull

registry.access.redhat.com/ubi8/ubi:latest
Trying to pull registry.access.redhat.com/ubi8/ubi:latest...
Getting image source signatures
Copying blob 13897c84ca57 done
Copying blob 64607cc74f9c done
Copying config 9992f11c61 done
Writing manifest to image destination
Storing signatures
9992f11c61c5fa38a691f80c7e13b75960b536aade4cce8543433b24623bce68
Descargada la imagen la podemos listar como se muestra:
[root@bd1 ~]# podman images

REPOSITORY TAG IMAGE ID CREATED SIZE
registry.access.redhat.com/ubi8/ubi latest 9992f11c61c5 9 days ago 213 MB
Se utiliza la aplicación “skopeo” para inspeccionar la imagen que se

utilizará:
[root@bd1 ~]# skopeo inspect
docker://registry.access.redhat.com/ubi8/ubi:latest | more
{
"Name": "registry.access.redhat.com/ubi8/ubi",
"Digest":
"sha256:17ff29c0747eade777e8b9868f97ba37e6b8b43f5ed2dbf504ff9277e1c1d1ca",
"RepoTags": [
"8.2-343-source",
"8.1-328",
"8.2-265-source",
"8.2-347-source",
"8.2-299.1592810498",
Despues de haber realizado la inspección se despliega el contenedor

desde la imagen preferida, logrando obtener acceso por CLI al mismo, como
lo muestra la siguiente instrucción:
[root@bd1 ~]# podman run -it

[root@f1103f0c82ed /]#
[root@f1103f0c82ed /]# exit

exit
Con el contenedor en ejecución es posible realizar las actividades de

stop, eliminación, visualización, etc, en este caso se procede a visualizar el
contenedor en ejecución para luego eliminarlo y seguidamente volver a listar
con el fin de validar que el contenedor se haya eliminado, como se muestra:
[root@bd1 ~]# podman ps --all

CONTAINER ID IMAGE COMMAND CREATED
STATUS PORTS NAMES
f1103f0c82ed registry.access.redhat.com/ubi8/ubi:latest /bin/bash About a minute ago
Exited (127) 9 seconds ago reverent_varahamihira
[root@bd1 ~]# podman rm -a

f1103f0c82ed107c4b4a887d31eeb3b9b8a1727938971f2da3581bb75107db13
[root@bd1 ~]# podman ps --all

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Seguidamente se lista la imagen de contenedor previamente descargada

para después eliminarla con el subcomando “rmi” de “podman”:
registry.access.redhat.com/ubi8/ubi latest 9992f11c61c5 9 days ago 213 MB
[root@bd1 ~]# podman rmi

Untagged: registry.access.redhat.com/ubi8/ubi:latest
Deleted: 9992f11c61c5fa38a691f80c7e13b75960b536aade4cce8543433b24623bce68

Como se mencionaba en apartes anteriores, Red Hat ha dejado Docker

como plataforma para gestión de containers y ha traido otras herramientas
para tal fin, el motivo pasa a ser una decisión en función de proporcionar
mejor funcionalidades para los que administran plataformas de contenedores
como para aquellos que desarrollan aplicaciones sobre estas plataformas.

Linux Guía de Administración

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Linux Guía de Administración

Cargado por

Copyright:

Formatos disponibles

Linux

Fabian Mestre Socarras

Los textos relacionados en este material hacen parte de la Propiedad

Linux es una marca registra de Linus Torvalds en los Estados Unidos de

XFS es una marca registrada de Silicon Graphics International Corp y

PostgreSQL, Microsoft Windows Server, Oracle, Ubuntu, Debian,

Dedico esta obra a mi esposa Gina, por su respaldo y su motivación para

A mis hijas y sobrinas, el futuro de la familia.

Quiero agradecer a todos aquellos que me han acompañado en el

Especial reconocimiento para Farid Boudez, Miguel Higuera, Jairo

Gracias especiales a Juan Carlos Velez y Liliana Hoyos, por su cuidado y

Administradores de Infraestructura de Tecnología de

Formadores de talento humano en Tecnologías de Información

Integradores de Soluciones de Infraestructura que soporten sus

Arquitectos de Tecnologías de Información responsables de la

Estudiantes que se forman para administrar plataformas de

Si usted detalla la tabla de contenido de este libro podrá observar que

Los laboratorios y actividades desarrolladas fueron desplegadas sobre la

Este libro se mantiene en constante actualización, para ser notificado al

Todo empieza entonces cuando en alguna parte del programa académico

Linux es un sistema operativo que está en todo, lo que menos se piensa

Particularmente he sentido un llamado a aportar un grano de arena en las

Aunque hoy día existen diferentes distribuciones Linux en el ámbito

Elaborar este libro ha sido un gran placer intelectual y emocional, cada

En el siguiente ejercicio agruparemos en un solo archivo varios archivos

Se ejecuta el proceso de agrupación a un solo archivo llamado

[root@pruebas ~]# tar -cf agrupado1.tar anaconda-ks.cfg initial-

[root@pruebas ~]# ll -h agrupado1.tar

En el siguiente ejemplo agrupamos a un solo archivo llamado “carpeta-

[root@pruebas ~]# tar -cf /root/carpeta-etc.tar /etc

De la siguiente forma es posible listar el contenido de un archivo

[root@pruebas ~]# tar -tf agrupado1.tar

De la siguiente forma se realiza el desacople de los archivos agrupados

[root@pruebas ~]# cd /datos/

[root@pruebas datos]# tar xvf /root/agrupado1.tar

Si lo ha podido notar, por organización y tratando de hacer un trabajo

PARÁMETRO ALGORITMO NOMBRE DE ARCHIVO

En cuanto al nombre de archivo lo que se detalla es una recomendación

[root@pruebas ~]# tar -czf /datos/gz-etcbackup.tar.gz /etc

[root@pruebas ~]# tar -cjf /datos/bzip2-etcbackup.tar.bz2 /etc

[root@pruebas ~]# tar -cJf /datos/xz-etcbackup.tar.xz /etc

[root@pruebas ~]# ll -trh /datos/

A la vista es posible ver que el algoritmo que mas comprime es xz,

[root@pruebas datos]# time tar -czf /datos/gz-etcbackup.tar.gz /etc

[root@pruebas datos]# time tar -cjf /datos/bzip2-etcbackup.tar.bz2

[root@pruebas datos]# time tar -cJf /datos/xz-etcbackup.tar.xz /etc

[root@pruebas datos]# mkdir /descomprimidos

[root@pruebas descomprimidos]# tar xzf /datos/gz-etcbackup.tar.gz

[root@pruebas descomprimidos]# ll -tr

Por limpieza en el trabajo, se ha creado la ruta /descomprimidos para

[root@pruebas descomprimidos]# tar --list -f /datos/xz-

Iniciamos entonces utilizando la aplicación “scp”, la cual hace parte de la

[root@pruebas datos]# scp xz-etcbackup.tar.xz

The authenticity of host '192.168.0.46 (192.168.0.46)' can't be

Registrados en el servidor 192.168.0.46 realizamos un listado para

[root@s1 ~]# ll xz-etcbackup.tar.xz

[root@pruebas datos]# sha256sum xz-etcbackup.tar.xz

[root@s1 ~]# sha256sum xz-etcbackup.tar.xz

Otra forma de transferir data entre servidores es trayendo data del

[root@s1 ~]# mkdir /carpeta-remota

Seguidamente traemos los archivos remotos a la carpeta /datos:

[root@pruebas datos]# scp -r root@192.168.0.46:/carpeta-remota

[root@pruebas ~]# sftp 192.168.0.46

El comando “rsync” es otra forma de copiar archivos de forma segura de