Manual Ultra Secreto

Linux for SysAdmins
OpenSourceCollege - 1ra. edición
OpenSourceCollege
Linux for SysAdmins
Primer centro de capacitación Open www.opensourcecollege.com
Página 1
Source Linux
Tabla de contenidos
Linux for SysAdmins
Unidad 1: Introducción al mundo Linux
Objetivos
Conceptos básicos
Definición de Linux y distribuciones, usuarios y permisos, el sistema de archivos, gestión de software. Ventajas, desventajas y
escenarios comunes de uso.
Entorno gráfico
Elementos principales de un entorno gráfico GNOME. Aplicaciones comunes de escritorio. Tareas esenciales de manejo de una
sesión gráfica y servidor X.
Entorno de línea de comandos

Uso de las consolas virtuales, rotación entre ellas y el entorno gráfico. Operaciones básicas de la shell y comandos comunes. Inicio
y cierre de sesión, apagado y reinicio del sistema, consulta de información del sistema, pruebas básicas de conectividad. Conexión
segura en la red usando OpenSSH. Consulta de páginas man.
Laboratorio N° 1
Ejercicios prácticos de acceso a un sistema Linux de manera local y remota, labores rutinarias de escritorio, ofimática y acceso a
Internet.
Unidad 2: Comandos GNU y Unix
Objetivos
La Shell BASH
Manejo de comodines de expansión, meta caracteres y variables. Salida estándar, salida de error y entrada estándar.
Redirecciones y tuberías. Secuencialidad de comandos y operadores. Manejo de historial de comandos.
Manejo de archivos
Desplazamiento a través del sistema de archivos. Listar, copiar, renombrar, mover, crear, eliminar, buscar archivos y directorios.
Enlaces simbólicos y enlaces duros. Empaquetamiento y compresión.
Procesamiento simple de texto

Herramientas de filtrado en tuberías: visualización, filtrado, ordenamiento y modificación de texto. Utilitarios complementarios de
manejo de flujos de texto.
Administración de procesos
Visualización de procesos, sus atributos y estados. Envío de señales y manejo de prioridades. Control de procesos en primer y
segundo plano desde la shell.
El editor de archivos VIM

Los 3 modos de VIM: comandos, inserción y visual. Comandos de movimiento, edición. Salir, guardar y guardar como.
Combinación de comandos de edición y el modo visual. Buscar y reemplazar. Preferencias de VIM.
Laboratorio N° 2
Ejercicios prácticos de manejo de flujos de texto, manipulación de archivos y/o directorios comprimidos. Monitoreo de procesos y
uso conjunto desde el VIM en primer y segundo plano.
Unidad 3: Administración de sistemas de archivos
Objetivos
Particionamiento simple
Identificación y nomenclatura de dispositivos. Conceptos de particionamiento en discos IDE y SCSI, tipos de particiones. Creación y
eliminación de particiones.
Formato de dispositivos
Gestión de dispositivos para SWAP. Creación de sistemas de archivos ext3 y vfat. Asignación de etiquetas y consulta de
OpenSourceCollege
Linux for SysAdmins
Página 2
Source Linux
información de dispositivos.
Montaje
Conceptos fundamentales. Montaje manual de dispositivos. Montaje automático y simplificado basado en /etc/fstab. Opciones
especiales de montaje según sistema de archivos.
Laboratorio N° 3
Ejercicios prácticos de asignación de espacio libre en disco para creación de sistemas de archivos adicionales.
Unidad 4: Administración de usuarios
Objetivos
Control de contraseñas
Bloqueo y desbloqueo de cuentas de usuarios. Asignación de contraseñas de usuario y grupo. Políticas de expiración de
contraseñas.
Gestión de usuarios y grupos

Atributos de usuarios y grupos. Creación, eliminación y modificación de usuarios y grupos. Cuotas de recuento de elementos y
espacio en disco.
Laboratorio N° 4
Ejercicios prácticos de administración de usuarios y grupos con cuotas y políticas de contraseñas.
Unidad 5: Seguridad local
Objetivos
Permisos y propietarios
Conceptos fundamentales previos. Modificación de permisos básicos, propiedad de objetos y permisos por defecto. Permisos
especiales de SUID, SGID y Sticky Bit. Gestión avanzada de permisos con ACL (Access Control List).
Ejecución privilegiada
Convertirse a root en la shell. Ejecución de aplicaciones como root con control granular.
Laboratorio N° 5
Ejercicios prácticos de ejecución de comandos con privilegios escalados.
Unidad 6: Particionamiento avanzado
Objetivos
RAID por software

Conceptos básicos de RAID. Creación, modificación y eliminación de dispositivos RAID. Monitoreo y restauración de dispositivos
RAID.
Logical Volume Management (LVM)

Conceptos básicos de LVM. Preparación de particiones para LVM, creación, eliminación y modificación de Volume Groups y Logical
Volumes. Formateo y montaje de Logical Volumes. Restauración de datos usando snapshots LVM.
Laboratorio N° 6
Ejercicios prácticos de gestión de Logical Volumes redundantes (configuración de espejo) y redimensionamiento 'en caliente'.
Unidad 7: Instalación
Objetivos
Instalación de Red Hat Enterprise Linux 5 / CentOS 5

Métodos de instalación. Configuración de idioma, zona horaria. Particionamiento, memoria SWAP y sistemas de archivos.
Selección de paquetes. Primer arranque y configuración post instalación. Instalación automática.
Resolución de problemas comunes
OpenSourceCollege
Linux for SysAdmins
Página 3
Source Linux
Servidor gráfico X, instalación de Linux y sesiones en consolas virtuales.
Laboratorio N° 7
Instalación desde red vía HTTP. Instalación automatizada usando Kickstart.
Unidad 8: Administración de software
Objetivos
Sistema de paquetes RPM

Instalación manual de binarios .rpm. Búsqueda, instalación y eliminación simplificada de software usando YUM. Configuración de
repositorios. Registro en Red Hat Network y manejo de la herramienta up2date.
Sistema de paquetes DEB

Instalación manual de binarios .deb. Búsqueda, instalación y eliminación simplificada de software usando APT. Configuración de
repositorios.
Instalación desde código fuente

Conceptos básicos de software distribuido en tarballs. Lineamientos generales de configuración, compilación e instalación de
software desde código fuente.
Laboratorio N° 8
Ejercicios prácticos de instalación manual de Webmin y software adicional desde repositorios de Internet. Compilación e instalación
de Apache y PHP.
Unidad 9: Otros tópicos de administración del sistema
Objetivos
El kernel y sus módulos

Consulta de información y ajustes de configuración del kernel. Listado, consulta, carga y descarga de módulos.
Arranque del sistema

El gestor de arranque GRUB. Niveles de ejecución, scripts de inicialización System V e invocación de servicios al arranque del
sistema operativo en sistemas Red Hat y Debian.
Programación de tareas
Tareas periódicas con cron, configuración global de /etc/crontab y tareas por usuario. Tareas postergadas con at, configuración de
fecha y hora de ejecución de aplicaciones.
Logs del sistema

Configuración del demonio syslog. Lectura y escritura dinámica de logs desde línea de comandos.
Shell scripting básico

Creación de scripts en BASH. Sentencias de ejecución fundamentales: if, while, for, read, case, entre otros. Funciones y códigos de
retorno de aplicaciones.
Laboratorio N° 9
Ejercicios prácticos de instalación de un módulo de kernel desde las fuentes y automatización de tareas con cron y scripts de shell.
Unidad 10: Administración de red
Objetivos
Configuración de parámetros red

Configuración de archivos de direccionamiento IP, enrutamiento y resolución DNS en sistemas Red Hat y Debian.
Utilitarios de red
Herramientas de configuración y consulta manual de parámetros de red, conexiones activas, trazado de rutas, escaneo de puertos
y análisis de tráfico con promiscuidad de interfaz de red. Shell y copia remota de archivos usando OpenSSH. SSH basado en
llaves.
Aplicaciones gráficas remotas
OpenSourceCollege
Linux for SysAdmins
Página 4
Source Linux
Ejecución de aplicaciones GUI remotas usando SSH X11 Forwarding. Configuración de servidor VNC/XDMCP. Conexión a
plataformas Windows usando escritorio remoto.
Laboratorio N° 10
Ejercicios prácticos de configuración de un escenario de red para producción y ajustes para entorno. Resolución de problemas
comunes.
Unidad 11: Servicios de infraestructura de red
Objetivos
Servicio DHCP
Conceptos básicos de DHCP. Instalación y configuración de servicio DHCP. Asignación de direcciones IP por rangos y otros
parámetros de configuración de red. Reserva de direcciones IP basados en dirección MAC de cliente. Administración del servicio
DHCP desde Webmin.
Servicio DNS
Conceptos básicos de DNS. Instalación y configuración de servicio DNS con BIND. Configuración de zonas de búsqueda directa y
reversa con rol de maestro y esclavo. Edición de archivos de zonas. Administración del servicio DNS/BIND desde Webmin.
Herramientas DNS de línea de comandos.
Servicio NTP
Conceptos básicos de NTP. Instalación y configuración del servicio NTP como cliente y servidor. Sincronización NTP manual desde
línea de comandos.
Laboratorio N° 11
Taller práctico de configuraciones diversas de asignación dinámica de direcciones IP, sincronización de tiempo y administración de
zonas DNS.
Unidad 12: Servidor de archivos e impresión
Objetivos
Samba y CUPS para redes Microsoft

Instalación y configuración básica de Samba bajo rol standalone y controlador PDC. Permisos granulares por usuarios y grupos
basados en ACLs. Configuración de impresoras con CUPS e integración con Samba. Configuración de Kerberos y Winbind para
integración de Samba como miembro de dominios Active Directory.
Compartición de archivos con NFS

Instalación y configuración del servicio NFS, compartición de recursos y seguridad de usuarios.
Servidor FTP seguro

Instalación y configuración básica del servicio FTP con vsftpd. FTP anónimo y autenticado con soporte de enjaulamiento de
usuarios.
Reportes de tráfico FTP

Instalación y configuración básica de AWStats para generación de reportes estadísticos de tráfico FTP. Administración de AWStats
desde Webmin.
Laboratorio N° 12
Taller práctico de compartición de impresoras con Samba e instalación automática de drivers desde estaciones Windows. Mapeo
de usuarios de Active Directory como cuentas locales de Linux.
Unidad 13: Servidor Web y OpenSSL
Objetivos
Certificados digitales
Conceptos básicos de criptografía, OpenSSL, certificados digitales y sus usos comunes. Gestión de autoridades certificadoras
certificados digitales.
Servidor Web Apache

Instalación y configuración básica de Apache. Dominios virtuales basados en nombre. Protección de recursos Web bajo control de
OpenSourceCollege
Linux for SysAdmins
Página 5
Source Linux
usuarios y hosts. Configuración por directorio con archivos .htaccess. Publicación de recursos bajo conexiones seguras (HTTPS)
con certificados digitales. Dominios virtuales basados en IP para sitios Web seguros. Administración de Apache desde Webmin.
Reportes de tráfico Web

Administración de AWStats desde Webmin para generación de reportes estadísticos de tráfico Web.
Laboratorio N° 13
Taller práctico de publicación de diversos Websites y dominios virtuales con URLs protegidas bajo conexiones seguras.
Unidad 14: Firewall seguro
Objetivos
Shoreline Firewall "Shorewall"

Conceptos básicos de Firewall, netfilter, iptables y Shorewall. Instalación de Shorewall, configuración de zonas, políticas, interfaces,
enmascaramiento y reglas. NAT de destino, NAT 1 a 1 y redirección para proxy transparente. Configuraciones de QoS y múltiples
proveedores de Internet. Administración de Shorewall desde Webmin.
Laboratorio N° 14
Taller práctico de implementación de reglas de Firewall.
Unidad 15: Proxy de control de navegación Web
Objetivos
Squid como proxy caché

Conceptos básicos de proxy HTTP. Instalación de Squid. Configuración básica de Squid y proxy transparente. Explicación de la
lógica de las ACL y reglas de control de acceso. ACLs de control comunes. Control de almacenamiento de objetos en caché,
regulación de ancho de banda y proxy autenticado. Administración de Squid desde Webmin.
Reporte de tráfico de usuarios

Instalación de SARG desde las fuentes. Administración de SARG desde Webmin para generación y visualización de reportes.
Laboratorio N° 15
Taller práctico de implementación de un Proxy transparente para controlar por horarios el MSN y otros tipos de chat. Control de
sitios Web genéricos de contenido multimedia (música y/o video en línea). Integración con Active Directory.
Unidad 16: Túneles VPN
Objetivos
VPN Open Source, "OpenVPN"

Conceptos básicos de VPN. Instalación y configuración de OpenVPN en modo routing con conexiones de roadwarriors y net-to-net.
Gestión de autoridades certificadoras (CA) y certificados digitales para usuarios. Conexión de OpenVPN en modo cliente desde
Linux y Windows. Autenticación de OpenVPN contra módulos PAM del sistema. Administración de OpenVPN desde Webmin.
Laboratorio N° 16
Implementación de OpenVPN con conexión net-to-net. Integración de OpenVPN con Active Directory para validación de
credenciales de usuarios. Configuración de reglas necesarias de Shorewall para un correcto funcionamiento del sistema VPN con
OpenVPN.
Unidad 17: Servidor de mensajería instantánea
Objetivos
Servidor Jabber Open Source, "Openfire"

Conceptos básicos de un sistema Jabber. Instalación y configuración de Openfire. Administración Web simplificada de usuarios,
grupos, sesiones, salas de conferencias y plugins de extensión.
Laboratorio N° 17
Taller práctico de implementación de Openfire utilizando MySQL como backend e integrado con Active Directory para la validación
OpenSourceCollege
Linux for SysAdmins
Página 6
Source Linux
de credenciales de usuarios. Conexión desde estaciones Windows.
Unidad 18: Servicio de directorios LDAP
Objetivos
Servidor LDAP Open Source, "OpenLDAP"

Conceptos básicos sobre servicios de directorios y LDAP. Instalación y configuración básica de OpenLDAP. Administración Web del
servicio de directorios con phpLDAPadmin. Herramientas LDAP de línea de comandos.
Laboratorio N° 18
Taller práctico de implementación de una libreta de direcciones con OpenLDAP y su integración desde un cliente de correo como
Microsoft Outlook o Mozilla Thunderbird.
Unidad 19: Servidor de Correo Electrónico
Objetivos
Servicios de autenticación, POP3, IMAP y SMTP

Conceptos básicos sobre el funcionamiento de los servicios de correo electrónico, sus componentes y trabajo conjunto entre ellos.
Instalación y configuración de Cyrus SASL. Configuración de saslauthd utilizando PAM y un servidor LDAP como backends.
Pruebas de validación de usuarios vía SASL desde línea de comandos.
Instalación y configuración de Cyrus IMAP con los servicios POP3 e IMAP. Conexiones seguras POP3S e IMAPS con certificados
digitales. Pruebas de validación de usuarios vía IMAP desde línea de comandos. Administración de buzones desde línea de
comandos y vía interfaz Web con Webmin.
Instalación y configuración básica de Postfix. Directivas de configuración de alias y buzones virtuales, autenticación de usuarios
contra SASL, integración con Cyrus IMAP y MailScanner. Herramientas de monitoreo y control de rutina.
Filtro de contenidos, Antispam, Antivirus

Instalación y configuración de ClamAV como antivirus Open Source; actualización de firmas propias y de terceros.
Instalación y configuración de SpamAssassin como herramienta de detección de spam; ajuste básico de reglas y plugins.
Instalación y configuración de MailScanner como filtro de contenidos; integración con ClamAV, SpamAssassin y Postfix.
Webmail y monitoreo
Instalación y configuración de Webmail Horde integrado con Cyrus IMAP y Postfix usando MySQL como backend. Módulos de
gestión de contraseñas y mensajes de vacaciones.
Instalación y configuración de MailWatch como herramienta de monitoreo y administración de rutina del correo electrónico.
Laboratorio N° 19
Taller práctico de implementación de un sistema de correo electrónico completo basado utilizando los componentes aprendidos.
Unidad 20: Virtualización Open Source
Objetivos
Virtualización Open Source, "Xen"

Conceptos básicos de virtualización y sus técnicas comunes. Instalación de Xen y utilitarios. Administración básica de guests desde
línea de comandos y GUI. Asignación de recursos a guests paravirtualizados: dispositivos de red, almacenamiento, procesadores y
memoria.
Laboratorio N° 20
Taller práctico de instalación de Red Hat Enterprise Linux 5 / CentOS 5 como guest paravirtualizado.
OpenSourceCollege
Linux for SysAdmins
Página 7
Source Linux
Convenciones usadas en el libro
Este libro utiliza ciertas convenciones en cuanto a tipografía y símbolos para la enseñanza de ciertos temas que requieren ser
enfatizados. Esto incluye palabras con significados especiales, comandos de consola, parámetros de comandos, contenidos de
archivos de configuración, entre otros, los cuales tienen por objetivo facilitar la lectura y el aprendizaje acorde a las explicaciones de
abajo.
Tipo de fuente usada
• Texto Arial y cursiva hace referencia a texto que tiene cierto significado especial que lo diferencia del párrafo.
• Texto Courier New y negrita hace referencia a comandos de Shell.
• Texto Courier New y normal hace referencia a caracteres especiales y texto que arrojan los comandos de Shell.
• Texto Courier New y subrayado hace referencia al texto que debe ser ingresado por el usuario en la Shell.
• Texto Times New Roman y cursiva hace referencia a rutas de archivos y/o directorios.
Sintaxis de comandos
Adicionalmente, será muy común dar detalles sobre el uso de comandos y sus parámetros para lo cual se usarán expresiones del tipo:
ssh [-afg] <host>
Donde:
ssh : Es el nombre del comando o aplicación a ejecutar

[-afg] : -a, -f y -g son parámetros opcionales. Los signos [ ] siempre significan opcional
<host> : host es un parámetro obligatorio. Los signos < > siempre significa obligatorio
Caracteres especiales
Existen ciertos caracteres que tienen especial significado dependiendo del ámbito donde se les haga referencia. Estos son:
• ^ : Referencia abreviada a la tecla Control o Ctrl.

• $ : Shell de usuario común, cualquiera distinto de root
• # : Shell del usuario root
Ejemplos:
1. ^c y â significan Ctrl + c y Ctrl + a respectivamente

2. $ mkdir -p significa que el comando mkdir y sus parámetros son ejecutados por un usuario distinto de root
3. # pvcreate /dev/sda1 significa que el comando pvcreate y sus parámetros son ejecutados por el usuario root
Referencia a documentación
A menudo cuando se dan explicaciones en este documento se suele hacer mención a la posibilidad de consultar fuentes adicionales de
documentación sobre el tema tratado, y muchas de esas están disponibles en las páginas man (documentación del sistema) las cuales
están organizadas por secciones numéricas y cada una lleva un nombre particular.
Es así que la documentación completa del comando mkdir está disponible en su página man, la cual desde una shell de comandos se
consulta así:
$ man 1 mkdir
o simplemente
$ man mkdir
Pero por brevedad se ha de mencionar esto como mkdir(1). Por ejemplo se puede expresar lo siguiente: "para más información
consulte mkdir(1)" que quiere decir que debe revisarse la página man de mkdir en la sección 1, tal como se mostró en el ejemplo de
arriba.
OpenSourceCollege
Linux for SysAdmins
Página 8
Source Linux
Unidad 1: Introducción al Mundo Linux
1.1. Objetivos
Al finalizar esta unidad Ud. estará en la capacidad de:
✔ Entender qué es Linux como sistema operativo, sus orígenes, su estado actual y los usos más comunes en el mercado.
✔ Comprender las características básicas del sistema operativo que lo diferencian con sistemas Microsoft Windows.
✔ Conocer las dos interfaces comunes de un sistema Linux y los entornos de escritorio disponibles
✔ Desempeñar tareas esenciales de uso del sistema en una sesión gráfica
✔ Desenvolverse por primera vez ante un sistema Linux a través de las consolas virtuales usando comandos básicos
1.2. Conceptos básicos

Reseña histórica de UNIX
Unix fue un sistema operativo creado por AT&T en los laboratorios Bell a fines de la década de los 60 como continuación de un ya
fracasado proyecto Multics el cual buscaba solucionar las incompatibilidades entre los diferentes sistemas operativos creados por cada
empresa de hardware. Tenía entre sus principales funcionalidades el de ser multitarea, multiusuario entre otras características
avanzadas.
Empresas y universidades empezaron a adoptar distintas versiones de UNIX modificándolas según sus necesidades debido a que
hasta ese entonces AT&T proveía el código fuente de su sistema operativo.
Posteriormente AT&T buscó lograr ventajas competitivas sobre otros cerrando el código de UNIX y poniendo trabas a quien quisiera
continuar con sus propias versiones del SO modificadas, como en el caso de la universidad de Berkeley quienes se vieron en la
necesidad de reconstruir desde cero su sistema UNIX conocido como BSD del cual más tarde nacería FreeBSD.
¿Qué es GNU?
Richard Stallman, fundador del proyecto GNU y la FSF (Free Software Foundation) buscaba la creación de un sistema UNIX que fuese
libre, que encajase en la definición de software libre y es así como nace el proyecto GNU, "GNU is not UNIX". Los integrantes de este
proyecto empezaron así entonces a crear herramientas para ese futuro sistema operativo como editores de texto, compiladores,
debuggers entre otros.
Crearon muchas herramientas pero no la parte más importante que es el kernel, el núcleo...
¿Qué es Linux?
En el año 1991, un estudiante finlandés llamado Linus Torvalds, empezó a querer crear una versión de Minix, otro sistema UNIX, para
computadoras personales, lográndolo y llamándolo Linux. Linux era entonces solamente un kernel, un núcleo de sistema operativo el
cual requería obviamente otras herramientas para su funcionamiento.
¿Qué es entonces GNU/Linux?

Linus Torvalds finalmente decide mostrar Linux al mundo a través de Internet solicitando la ayuda de todos los programadores
interesados en mejorarlo. De este modo Linux llega a convertirse en aquel kernel del cual carecía el proyecto GNU. Es por esto que el
sistema operativo completo se le denomina GNU/Linux para ser justos y hacer referencia tanto al kernel Linux como a las herramientas
que sobre él corren desarrolladas por el proyecto GNU.
Distribuciones
Una distribución es una variante del sistema GNU/Linux que se enfoca a satisfacer las necesidades de un grupo especifico de
usuarios. De este modo hay distribuciones para hogares, empresas y servidores. Algunas distribuciones son completamente libres,
pero muchas no lo son.
Las distribuciones son ensambladas por individuos, empresas u otros organismos. Cada distribución puede incluir cualquier número de
software adicional, incluyendo software que facilite la instalación del sistema. La base del software incluido con cada distribución
incluye el núcleo Linux y las herramientas GNU, al que suelen añadirse también varios paquetes de software.
Las herramientas que suelen incluirse en la distribución de este sistema operativo se obtienen de diversas fuentes, y en especial de
proyectos de software libre, como: GNU , BSD, GNOME y KDE. También se incluyen utilidades de otros proyectos como Mozilla, Perl,
Ruby, Python, PostgreSQL, MySQL, Xorg, casi todas con licencia GPL o compatibles con ésta (LGPL, MPL).
Usualmente se utiliza la plataforma X.Org Server, basada en la antigua XFree86, para sostener la interfaz gráfica.
Con la adopción por numerosas empresas fabricantes, un buen número de computadoras se venden con distribuciones pre-instaladas,
y GNU/Linux ha comenzado a tomar su lugar en el vasto mercado de las computadoras de escritorio.
Entre las distribuciones Linux más populares se encuentran Debian, Ubuntu, Red Hat, Fedora, CentOS, Mandriva, SuSE, Gentoo, etc.
Usos y mercado
En entornos de escritorio, GNU/Linux ofrece una interfaz gráfica alternativa a la tradicional interfaz de línea de comandos de Unix.
Existen en la actualidad numerosas aplicaciones gráficas que ofrecen la funcionalidad que está permitiendo que GNU/Linux se adapte
OpenSourceCollege
Linux for SysAdmins
Página 9
Source Linux
como herramienta de escritorio.
Muchas distribuciones permiten el arranque del sistema directamente desde un CD/DVD (llamados CD/DVD autónomos o "vivos") sin
modificar en absoluto el disco duro del ordenador en el que se ejecuta GNU/Linux. Para este tipo de distribuciones, en general, los
archivos de imagen (archivos ISO) están disponibles en Internet para su descarga.
Otras posibilidades incluyen iniciar el arranque desde una red (ideal para sistemas con requerimientos mínimos), desde un disco
flexible o disquete o desde unidades de almacenamiento USB.
Documentación adicional
Historia de Linux
http://es.wikipedia.org/wiki/Historia_de_Linux
El sistema de archivos
 En un sistema UNIX, la base de la estructura de directorios es la raíz "/" así como en sistemas Windows lo son C:\, D:\, E:\. A
diferencia de Windows, en un sistema UNIX no se usan letras ni diferentes símbolos para representar las distintas
particiones.
 Todo el sistema de archivos cuelga bajo la raíz / y así sus ficheros y directorios. Así, los siguientes son ejemplos de
representación de rutas de archivos y/o directorios:
/dev (Directorio)
/etc/login.defs (Archivo)
 A diferencia de Windows en donde puede usarse indistintamente los símbolos \ ó / para representar las rutas, en un sistema
UNIX solamente se permite el símbolo /
 La partición en la cual se instala la base del sistema de archivos se conoce como la partición root, la que conocíamos como
raíz / también
 Una partición swap es un espacio reservado para intercambio que será usado como memoria virtual cuando se acabe la
memoria RAM del sistema. Se recomienda que su tamaño sea aproximadamente el doble de la cantidad de memoria RAM
del computador.
 Los dispositivos así como todo lo que existe en un sistema UNIX se maneja como archivos. La carpeta donde se ubican los
ficheros para acceder a los dispositivos es /dev, así el dispositivo que reconoce la lectora de CD-ROM es /dev/cdrom, el
dispositivo que reconoce la primera unidad de floppy es /dev/fd0
 La sensibilidad a mayúsculas sí es válida en cualquier sistema UNIX, tanto en los nombres de archivos como en las órdenes
de línea de comandos (que a fin de cuentas no son más que archivos también). Por ejemplo hacen referencia a distintos
archivos /tmp/makefile y /tmp/Makefile
 Los archivos ocultos en un sistema UNIX se les identifica cuando llevan un punto '.' por delante. Por ejemplo .xinitrc en
nuestro directorio personal es un archivo oculto.
Usuarios y permisos
 Linux al igual que otros sistemas UNIX se caracterizan por ser multiusuarios, esto quiere decir que el sistema operativo tiene
la capacidad de atender de manera concurrente las tareas de múltiples usuarios a él conectados.
 También existen grupos que no son más que un conjunto de usuarios reunidos bajo una única instancia con nombre y
atributos propios.
 Existe un único usuario denominado root el cual es el administrador del sistema. Este usuario tiene permiso sobre todo, se le
permite ejecutar cualquier acción o cambio en el sistema operativo. La cuenta de este usuario debe ser usada con recelo
solamente en operaciones administrativas.
 El hecho que existan diversos usuarios obliga la existencia de mecanismos de control que preserven el orden y consistencia
del sistema entero. Este mecanismo son los permisos que permiten asignar niveles granulares de control sobre archivos,
procesos, dispositivos y otros objetos para cada usuario de modo tal que uno de ellos no interfiera con las tareas u objetos
de otros.
Disponibilidad del software
 Para Linux como también para otros sistemas UNIX siempre hay software disponible en formato binario, es decir software
que está listo para ser instalado y usado. Este tipo de software binario viene empaquetado en formatos específicos
generalmente propios de cada sistema operativo; así por ejemplo Red Hat y SuSE manejan sus paquetes binarios en
formato RPM que son archivos de extensión .rpm, mientras que Debian maneja el formato DEB que son archivos de
extensión .deb.
 Pero también es muy común que se distribuya el software en código fuente a través de tarballs (archivos empaquetados y/o
comprimidos que por lo general contienen código fuente de algún software). Estos tarballs están disponibles comúnmente en
el sitio Web oficial del proyecto de software desde el cual podemos descargarlo para luego desempauetarlo/descomprimirlo,
OpenSourceCollege
Linux for SysAdmins
Página 10
Source Linux
compilarlo e instalar en el sistema los binarios producidos producto del proceso de la compilación.
1.3. Entorno gráfico

Introducción
Los sistemas Linux como el resto de sistemas operativos UNIX utiliza un esquema Cliente/Servidor para la implementación de un
entorno gráfico visual. Esto es posible a través de la ejecución de un servidor gráfico (llamado comúnmente Servidor X) y las distintas
aplicaciones gráficas (un editor de texto, navegador de Internet, cliente de correo, etc) ejecutadas como clientes gráficos.
Tanto los clientes como el servidor trabajan interconectados de manera permanente y transparente al usuario final.
Gracias a este modelo cliente/servidor bajo el cual trabaja el sistema gráfico en Linux es posible por ejemplo ejecutar una aplicación
(digamos el Mozilla Firefox) en una PC y ser mostrada/visualizada en otra PC donde corre el servidor X.
Cuando se hable del entorno gráfico de un sistema Linux se hará mención a menudo a una serie de términos cuya definición abajo se
detalla:
• X Window System (sistema de ventanas X): Protocolo diseñado para proveer de una interfaz gráfica a sistemas de
computadora en red. Este protocolo brinda las primitivas básicas (dibujar y mover ventanas, y la interacción con el ratón y
teclado) para construir entornos de escritorio completos mas no tiene como función la realización de tareas específicas o
personalizadas sobre las ventanas (estilo y/o color de ventanas, combinación de teclas para rotar/minimizar ventanas,
protector y/o fondo de pantalla).
Generalmente se hace referencia a este protocolo en su versión 11 como X11.
• Xfree86 y X.Org: Ambos son implementaciones Open Source de X Window System diseñadas para sistemas operativos
UNIX y clónicos (incluye Linux). X.Org nace como una derivación del proyecto XFree86 debido a un cambio de
licenciamiento y es el más utilizado por los sistemas Linux (Debian, Red Hat, Slackware, Mandriva, openSUSE, etc) en la
actualidad.
• Window Manager (administrador de ventanas): Aplicación que corre bajo un sistema de ventanas encargada de controlar
la ubicación y apariencia de ventanas como funciones básicas del sistema operativo. Ejemplo de algunas de las tareas de las
cuales es responsable son: abrir, cerrar, minimizar, maximizar, rotar (Alt+Tab). También un Window Manager puede incluir
elementos adicionales tales como una barra de tareas, bandeja de sistema, reloj, iconos, fondo de escritorio, entre otros.
Algunos de los Window Manager más comunes son: Enlightenment, Fluxbox, Kwin (forma parte de KDE), Metacity (forma
parte de GNOME), WindowMaker, IceWM.
• Display Manager (administrador de pantalla): Aplicación que corre sobre un servidor gráfico y es un complemento común
de todo sistema de ventanas. Tiene como función el controlar el inicio de sesión en una computadora local o remota a través
de una pantalla gráfica en la cual se pide un nombre de usuario y su respectiva contraseña del sistema.
Algunos de los Display Manager más comunes son: XDM (forma parte de un X Window System), GDM (forma parte de
GNOME), KDM (forma parte de KDM).
• Desktop Environment (entorno de escritorio): Conjunto de aplicaciones que corren sobre un sistema de ventanas que
tiene como función el brindar una sesión gráfica interactiva, amigable y cómoda a los usuarios finales de computadoras.
Agrupa de forma global funcionalidades que van desde el manejo de ventanas (abrir, cerrar, minimizar, etc, a través de su
propio window manager), inclusión de elementos variados de escritorio (barras de tarea, menú de aplicaciones, applets como
reloj, monitor de batería, etc) y preferencias avanzadas (fondo y protector de pantalla, temas/skins de escritorio, arrastrar y
soltar elementos, etc).
Algunos de los Desktop Environment más comunes son: GNOME, KDE, XFCE, LXDE, CDE (común en sistemas Solaris).
Combinaciones de tecla
importante tener en cuenta las siguientes combinaciones de teclas de uso común en un entorno gráfico Linux:
• Ctrl + Alt + Supr : Comúnmente en KDE y GNOME permite cerrar la sesión, reiniciar y/o apagar el sistema.
• Ctrl + Alt + L : Comúnmente en KDE y GNOME permite bloquear la sesión.
• Alt + F2 : Comúnmente en KDE y GNOME abre el díalogo 'Ejecutar' para correr un comando.
• Ctrl + Alt + D : Comúnmente en KDE y GNOME muestra el escritorio (minimiza todas las ventanas).
• Ctrl + Alt + Escape : Reiniciar la sesión X. Es un cierre brusco que mata todas las aplicaciones gráficas de inmediato.
El entorno gráfico también ofrece facilidades para el manejo de ventanas y portapapeles a través del uso conjunto del teclado y ratón:
• Alt + Clic izquierdo + Movimiento : Manteniendo presionados el botón izquierdo del ratón y la tecla Alt, se puede
desplazar la ventana según el movimiento del ratón.
• Alt + Clic derecho + Movimiento : Manteniendo presionados el botón derecho del ratón y la tecla Alt, se puede
redimensionar la ventana según el movimiento del ratón (Sólo en KDE).
• Alt + Clic central + Movimiento : Manteniendo presionados el botón central del ratón (cuando existen 3 botones) y la
tecla Alt, se puede redimensionar la ventana según el movimiento del ratón (Sólo en GNOME).
• Selección de texto con clic izquierdo : Copia al portapapeles el texto seleccionado con el botón izquierdo del ratón.
• Clic central : Pega el texto guardado en el portapapeles
OpenSourceCollege
Linux for SysAdmins
Página 11
Source Linux
Es importante tener en cuenta que en equipos con ratones de 2 botones es posible emular el funcionamiento de un 3er. botón
presionando a la vez los dos botones (izquierdo y derecho).
OpenSourceCollege
Linux for SysAdmins
Página 12
Source Linux
1.4. Entorno de línea de comandos
Introducción
Los sistemas operativos Linux así como cualquier otro UNIX se caracterizan por disponer de dos interfaces de usuario: la interfaz
gráfica y la interfaz de línea de comandos (conocido también comúnmente también sólo como modo texto, shell o consola).
Si bien es cierto que la interfaz gráfica de las versiones más modernas de distribuciones Linux son cada vez más amigables e intuitivas
es necesario reconocer que el máximo potencial administrativo de este sistema operativo no es a través de herramientas GUI sino por
el contrario a través del manejo directo de la línea de comandos.
Es por ello que prácticamente la totalidad de este curso se centra en la enseñanza de labores de administración a través de la línea de
comandos para lo cual podremos trabajar en una de las consolas virtuales o en una terminal de comandos desde una sesión gráfica en
GNOME o KDE.
Consolas virtuales
Linux implementa por defecto seis consolas virtuales. Éstas funcionan como emulaciones de terminal conectados al sistema que
permiten interactuar con éste a través del teclado y ratón.
Sin embargo son muy pocas las aplicaciones ejecutadas en consolas virtuales (o terminal de comandos) que permiten aprovechar la
funcionalidad del ratón.
Inicio de sesión
Dependiendo de los paquetes que hayan sido seleccionados en el momento de la instalación de Linux es posible que éste arranque
por defecto en modo texto o modo gráfico. Sin importar cuál sea el modo de arranque por defecto es cierto que al situarnos en una de
las consolas virtuales tendremos una pantalla similar a una de las siguientes:
Debian GNU/Linux consultorianet tty1 CentOS Release 5.3 (Final)

kernel 2.6.18.el5 on a i686
consultorianet login:
consultorianet login:
Los ejemplos arriba mostrado representan la pantalla de inicio de sesión en una consola virtual de un sistema Linux, el de la izquierda
correspondiente a un sistema con Debian y el de la derecha al de un sistema CentOS.
No importa cómo muestren la información de inicio de sesión hay que rescatar que siempre:
• Se muestra el nombre del sistema operativo en la parte superior (Debian o CentOS) y otros datos adicionales (1)
• A la izquierda de la palabra login se muestra el nombre del sistema (hostname)
Esta pantalla nos dice que el sistema está listo para que nosotros iniciemos sesión para lo cual debemos escribir nuestro nombre de
usuario (a la derecha de la palabra login) y luego de presionar [Enter] escribiremos la contraseña respectiva.
Cabe resaltar que mientras escribimos la contraseña ésta no se hará notar en la pantalla como caracteres asterisco (*****), sino que
quedará oculto a nuestra vista, por lo que no debemos asombrarnos si no vemos nada mientras escribimos la contraseña.
Prompt de Shell
Luego de iniciar sesión en una consola virtual podremos observar lo siguiente:
Last login: Thu Oct 8 21:17:13 PET 2009 on tty1 < Último login
Linux angel 2.6.26-2-amd64 #1 SMP Wed Aug 19 22:33:18 UTC 2009 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright. < Message of the day
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.
arengifo@consultorianet:~$ < Prompt de shell
Donde:
• La primera línea corresponde a la fecha y hora del último inicio de sesión en la consola virtual número 1 (tty1)
• Desde la segunda hasta la penúltima línea hasta corresponde al mensaje de bienvenida del sistema o message of the day (2)
que puede estar existir o no por defecto en algunas distribuciones Linux.
• La última línea es el prompt de Shell, que muestra información tal como el usuario logueado, nombre del sistema, ubicación
actual en el sistema de archivos, indicador de usuario $ o # (consultar pag. 8) u otra información personalizable (consultar La
Shell Bash en la Unidad 2 de este manual)
OpenSourceCollege
Linux for SysAdmins
Página 13
Source Linux
(1) El texto mostrado en este indicador de entrada puede ser personalizado en el archivo /etc/issue. Consultar también issue(5) y
getty(8) o mingetty(8)
(2) El texto mostrado como bienvenida o message of the day (motd) es puede ser personalizado en el archivo /etc/motd.
Consultar también motd(5)
Es importante tener en cuenta las siguientes combinaciones de teclas de uso común en un entorno de línea de comandos Linux:
• Alt + FN : Cambia desde una consola a hacia la consola virtual número N (cualquier número entre 1 y 6).
• Ctrl + Alt + F7 : Cambia desde cualquiera de las consolas virtuales hacia la sesión gráfica.
• Ctrl + Alt + FN : Cambia de la sesión gráfica a la consola virtual número N (cualquier número entre 1 y 6).
* El comando chvt N (ejecutado como root) también permite cambiar a la consola virtual número N
Cierre de sesión
Una sesión de línea de comandos puede ser cerrada de una de las siguientes formas:
• ^D : Combinación de teclas Ctrl+D

• Comando : A través de los comandos logout o exit
Apagado y reinicio del sistema

El sistema puede ser apagado o reiniciado de las siguientes maneras:
• Ctrl + Alt + Supr : Reinicia el sistema (3)

• Comando : El comando shutdown permiten reiniciar y/o apagar el sistema.
shutdown [opciones] <tiempo> [mensaje]

Reinicia y/o apaga el sistema
-r : Reinicia el sistema
-h : Apaga el sistema
-c : Cancela un apagado en curso ya programado
-k : No reinicia ni apaga, sólo envía un mensaje a todos los usuarios del sistema
tiempo : Indica cuándo reiniciar/apagar el sistema

mensaje : Mensaje de aviso enviado a los usuarios previo al reinicio/apagado del sistema
tiempo puede especificarse usando el formato hh:mm (hora y minuto) o +N (N minutos a esperar). La palabra now es sinónimo de +0
* Sólo el usuario root puede ejecutar este comando
De manera alterna se puede utilizar el comando reboot para reiniciar y poweroff o halt para apagar el sistema.
(3) Se puede desactivar esta combinación de teclas a través de la configuración del archivo /etc/inittab (Comentar la línea que
empieza con ca:12345:ctrlaltdel)
Ejemplos:
1. Apagar el sistema dentro de 10 minutos:
# shutdown -h +10
2. Reiniciar el sistema a las 21:00 horas con un aviso de advertencia:
# shutdown -r 21:00 "El sistema se apagara a las 09:00 pm"
3. Reiniciar el sistema ahora mismo:
# shutdown -r now
Consulta de páginas man

La documentación en línea de sistema es conocida también como las páginas man (en referencia al comando que invoca a la lectura
de la documentación). Estas páginas son documentos incluidos por defecto con toda instalación de un sistema Linux e incluyen la
OpenSourceCollege
Linux for SysAdmins
Página 14
Source Linux
explicación muchas veces bien detallada de una serie de aspectos importantes del sistema los cuales están clasificados por secciones
como se muestra a continuación:
Sección Descripción
1 Programas ejecutables y guiones del intérprete de órdenes
2 Llamadas del sistema (funciones servidas por el núcleo)
3 Llamadas de la biblioteca (funciones contenidas en las bibliotecas del sistema)
4 Ficheros especiales (se encuentran generalmente en /dev)
5 Formato de ficheros y convenios p.ej. I/etc/passwd
6 Juegos
7 Paquetes de macros y convenios p.ej. man(7), groff(7).
8 Órdenes de admistración del sistema (generalmente solo son para root)
9 Rutinas del núcleo [No es estándar]
Forma de uso:
• Invocar la página man de interés (Ejm: man crontab)

• Presionar las teclas flecha Arriba y flecha Abajo para desplazarse a lo largo del contenido mostrado.
• Presionar la tecla q para salir
man [opciones] [sección] <tema>

Consulta de documentación en línea del sistema
-P paginador : Utiliza el comando paginador para mostrar el contenido de la página. Por defecto se usa less como paginador.
-w : Sólo muestra la ruta del archivo que contiene la página man
-a : Muestra todas las páginas man que coincidan con el tema buscado
sección : Sección en la que se buscará la página man acorde a la tabla arriba mostrada. Si se omite este parámetro se
buscará automáticamente la primera página man que coincida con el criterio buscado.
tema : Patrón de texto que define el tema de interés a buscar en la documentación
Ejemplos:
1. Consultar la página man de crontab buscada en la sección 1:
# man 1 crontab
2. Consultar todas las páginas man que coincidan con crontab y mostrarlo usando el comando cat:
# man -P cat -a crontab
Comandos comunes
• $ clear
Limpia la pantalla
• $ reset
Resetea la pantalla cuando ésta se avería con caracteres ilegibles (Por ejm. al correr $ cat /bin/ls).
• $ free -m
Muestra la información de memoria disponible del sistema.
• $ uname -a
Muestra información del sistema como kernel, arquitectura, nombre de host, entre otros.
• $ lspci
Muestra información de los buses PCI y dispositivos conectados a ellos. El parámetro -k informa su driver asociado.
• $ cat /proc/cpuinfo
Consulta información del procesador del sistema.
OpenSourceCollege
Linux for SysAdmins
Página 15
Source Linux
• $ dmesg
Muestra los últimos eventos reportados por el kernel.
• $ whoami
Indica qué usuario es con el cual estamos actualmente logueados
• $ who
Muestra los usuarios actualmente logueados al sistema
• $ last
Muestra los últimos accesos al sistema
• $ date
Muestra la fecha y hora del sistema
Consultar la documentación (páginas man) de cada uno de los comandos listados para tener información completa sobre sus
parámetros y forma de uso, en especial del comando date
Pruebas básicas de conectividad y red

Normalmente luego de instalar un sistema Linux se suele desear acceder a una red local o Internet. Los siguientes son pasos de
verificación que deberían ser realizados:
1. Verificar qué interfaces de red tenemos activas:
# ifconfig
2. Consultar cuál de ellas está conectada físicamente a la red:
# ethtool eth0
3. Probar conectividad con otro host en la red (se cancela el comando con ^C)
$ ping 192.168.1.1
4. Realizar una consulta DNS:
$ host www.kernel.org
Inicio de sesión remoto

Es muy común en sistemas UNIX y Linux el acceso a éstos de forma remota a través de una línea de comandos. Esto es posible
gracias al uso de conexiones seguras usando OpenSSH.
El siguiente ejemplo intenta iniciar una sesión remota como el usuario admin en el host 192.168.1.30:
$ ssh admin@192.168.1.30
The authenticity of host '192.168.1.30 (192.168.1.30)' can't be established.
RSA key fingerprint is 6d:1b:bc:18:9a:81:11:1d:e4:97:52:40:1e:7c:72:8a.
Are you sure you want to continue connecting (yes/no)
El mismo procedimiento puede ser logrado de otra forma similar:
$ ssh -l admin 192.168.1.30

Are you sure you want to continue connecting (yes/no)
En ambos casos si nos conectamos por primera vez a dicho host se nos preguntará si deseamos proceder (aún no conoce la identidad
de ese host y nos advierte) a lo cual nosotros responderemos escribiendo 'yes' (almacenando su identidad para no consultarnos en el
futuro) y luego introduciremos el password del usuario respectivo
$ ssh -l admin 192.168.1.30

Are you sure you want to continue connecting (yes/no) yes
Password:
OpenSourceCollege
Linux for SysAdmins
Página 16
Source Linux
Last login: Mon Oct 8 19:22:32 2009
$ admin@mailserver:~$
OpenSourceCollege
Linux for SysAdmins
Página 17
Source Linux
1.5. Laboratorio N° 1
A continuación se presenta una serie de tareas prácticas a ejecutar en el laboratorio acorde a lo aprendido en esta unidad.
1. Inicie una sesión gráfica a través del Display Manager con el usuario y contraseña sin privilegios especificado por el docente,
luego inicie sesión también con el mismo usuario desde una de las consolas virtuales. Analice la lista de usuarios logueados
al sistema antes y después de cerrar alguna de las sesiones abiertas.
2. Tras iniciar una sesión gráfica identifique los elementos del escritorio, agregue un acceso directo en el escrito para el
navegador Mozilla Firefox e intente navegar por algún sitio de Internet.
3. Analice el hardware del equipo (memoria, arquitectura y características del procesador, dispositivos PCI), e investigue qué
controladores o drivers están asociados a cada uno de ellos.
4. Inicie una sesión remota vía SSH con un usuario sin privilegios en otro ordenador de la red local. Analice los usuarios
logueados al sistema y el registro de los últimos inicios de sesión de ese host remoto.
5. Reinicie el sistema con una programación postergada de cinco minutos. Intente hacerlo como un usuario sin privilegios y
analice el problema ocurrido. Intente nuevamente realizar la tarea como usuario root.
6. Inicie una sesión gráfica como el usuario root y personalice el indicador de entrada (el que se muestra en la pantalla de inicio
de sesión de las consolas virtuales) de modo tal que se muestre siempre la versión del kernel, la fecha y la hora actual.
Compruebe que los cambios se hayan aplicado tras cerrar y abrir sesión en una consola virtual.
Apóyese de issue(5), getty(8) o mingetty(8).
7. En la sesión gráfica ya iniciada anteriormente modifique también el mensaje de bienvenida o motd (message of the day) para
incluir una advertencia personalizada que sea de su agrado. Compruebe que los cambios se hayan aplicado tras cerrar y
abrir sesión en una consola virtual.
Apóyese de motd(5).
OpenSourceCollege
Linux for SysAdmins
Página 18
Source Linux
1.5.1 Solución del laboratorio N° 1
1. Inicie una sesión gráfica a través del Display Manager con el usuario y contraseña sin privilegios especificado por el docente,
luego inicie sesión también con el mismo usuario desde una de las consolas virtuales. Analice la lista de usuarios logueados
al sistema antes y después de cerrar alguna de las sesiones abiertas.
+ Presionar Ctrl+Alt+F1 para ir a la consola virtual N° 1 para iniciar sesión
+ Usuarios logueados al sistema:
$ who
2. Tras iniciar una sesión gráfica identifique los elementos del escritorio, agregue un acceso directo en el escrito para el
navegador Mozilla Firefox e intente navegar por algún sitio de Internet.
+ En GNOME: Ir al menú "Aplicaciones -> Internet -> Firefox Web Browser", dar clic derecho y elegir la opción "Añadir este
lanzador al escritorio"
3. Analice el hardware del equipo (memoria, arquitectura y características del procesador, dispositivos PCI), e investigue qué
controladores o drivers están asociados a cada uno de ellos.
+ Información de memoria del sistema:
$ free -m
+ Información de la arquitectura del procesador mostrada en:
$ uname -a
+ Características del procesador:
$ cat /proc/cpuinfo
+ Dispositivos PCI y sus drivers asociados a cada uno de ellos (no disponible en sistemas Red Hat):
$ lspci -k
4. Inicie una sesión remota vía SSH con un usuario sin privilegios en otro ordenador de la red local. Analice los usuarios
logueados al sistema y el registro de los últimos inicios de sesión de ese host remoto.
+ Iniciar sesión en un host remoto con un usuario distinto de root:
$ ssh -l jgarcia 192.168.1.32
+ Listado de los usuarios logueados al sistema:
$ who
+ Listado de los últimos inicios de sesión:
$ last
5. Reinicie el sistema con una programación postergada de cinco minutos. Intente hacerlo como un usuario sin privilegios y
analice el problema ocurrido. Intente nuevamente realizar la tarea como usuario root y cancele el reinicio.
+ Reiniciar el sistema dentro de 5 minutos:
$ shutdown -r +5
-bash: shutdown: command not found
$ /sbin/shutdown -r +5
shutdown: you must be root to do that!!
# shutdown -r +5
Broadcast message from root (pts/1) (Tue Oct 10 10:20:32 2009)
The system is going DOWN for reboot in 5 minutes!
OpenSourceCollege
Linux for SysAdmins
Página 19
Source Linux
^C
6. Inicie una sesión gráfica como el usuario root y personalice el indicador de entrada (el que se muestra en la pantalla de inicio
de sesión de las consolas virtuales) de modo tal que se muestre siempre la versión del kernel, la fecha y la hora actual.
Compruebe que los cambios se hayan aplicado tras cerrar y abrir sesión en una consola virtual.
Apóyese de issue(5), getty(8) o mingetty(8).
+ En GNOME: Ir al menú "Aplicaciones -> Accesorios -> Editor de textos", y dar clic. Abrir el archivo /etc/issue y editarlo como
sigue:
CentOS Release 5.3 (Final)

Kernel \r on a \m - \d \t
7. En la sesión gráfica ya iniciada anteriormente modifique también el mensaje de bienvenida o motd (message of the day) para
incluir una advertencia personalizada que sea de su agrado. Compruebe que los cambios se hayan aplicado tras cerrar y
abrir sesión en una consola virtual.
Apóyese de motd(5).
+ En GNOME: Ir al menú "Aplicaciones -> Accesorios -> Editor de textos", y dar clic. Abrir el archivo /etc/motd y editarlo como
sigue:
Bienvenidos a CentOS 5.3
Por favor realice sólo actividades relacionadas a su trabajo. Toda accion estara siendo
registrada en el sistema.
OpenSourceCollege
Linux for SysAdmins
Página 20
Source Linux
Unidad 2: Comandos GNU y Unix
2.1. Objetivos
✔ Comprender qué es una Shell y desenvolverse sin problemas en la shell Bash.

✔ Entender y manejar con facilidad las redirecciones y tuberías en la shell Bash.
✔ Realizar las operaciones comunes de manejo de archivo tales como crear, eliminar, mover, buscar, comprimir, etc.
✔ Utilizar los filtros básicos de texto en tuberías tales como sort, cut, grep, less, cat, etc.
✔ Gestionar correctamente los procesos del sistema, controlar su ejecución a través de señales y la shell bash.
✔ Aprender el modo de funcionamiento del editor VIM, sus comandos básicos y funciones más importantes de usuario diario.
2.2. La Shell BASH

Introducción
Una Shell, también conocida como intérprete de órdenes o intérprete de comandos, es una aplicación que actúa como una interfaz de
comunicación entre el usuario y el sistema operativo para ordenar a éste las tareas a ejecutarse.
Es a través de una pantalla que el usuario usando un teclado y ratón (opcionalmente) puede ingresar las órdenes al sistema operativo
y recibir las respuestas de resultado. Al culminar de atender una orden del usuario la Shell se queda en espera de más órdenes.
La shell es quizás la interface de comunicación más antigua que existen en los sistemas informáticos, disponibles en la actualidad para
sistemas operativos Unix, Windows, Solaris, equipos embebidos como routers, switches, etc.
BASH
Bash es quizás la Shell más popular entre sistemas operativos Linux, incluida como shell por defecto en distribuciones como Red Hat,
openSUSE, Debian, entre otros.
Se caracteriza por ser muy flexible, dotado de características avanzadas y muchas de ellas no disponibles en otras shell tal como
autocompletado de nombres de archivos/programas con TAB, acceso a parámetros pasados por shell, operaciones matemáticas con
enteros, redirecciones de entrada/salida, comparación de texto en expresiones regulares, entre otros.
Es por ello que este manual asumirá en su totalidad que la shell a estudiar y usar es BASH.
Variables
Bash maneja variables de manera similar a como cualquier lenguaje de programación, con la limitación del nombre de ellas a valores a
caracteres alfanuméricos.
Las variables no tienen un tipo asociado a ellas (entero, punto flotante, cadena, etc) ni tampoco se les requiere definir antes de usarlas.
Simplemente se les asigna un valor en cualquier momento dado para empezar a trabajar con ella.
La forma de uso de las variables se muestra a continuación:
Acciones Cómo referenciarlas Ejemplos

$ NOMBRE="Juan Rosales"
Asignar un valor NOMBRE_VARIABLE $ A=300
$ B=200
$ echo $NOMBRE
Leer su valor $NOMBRE_VARIABLE $ SUMA=$(($A + $B))
$ echo $SUMA
Variables globales
Por defecto cualquier variable que nosotros definamos tiene un ámbito local a no ser que especifiquemos lo contrario. Las variables
locales son aquellas que existen sólo desde la visión del actual proceso en ejecución pero inaccesible totalmente por otros procesos.
Por ejemplo las variables NOMBRE, A y B definidas arriba pueden ser visualizadas en nuestra sesión de shell actual pero no pueden ser
vistas por un script que nosotros invoquemos desde esta shell en uso.
En cambio las variables globales tienen la particularidad que son accesibles no sólo desde el proceso actual que las inicializó, sino
también desde todos sus procesos hijo. Esto quiere decir que los procesos que se invoquen desde dicho proceso (la shell actual por
ejemplo) también podrán hacer uso de dichas variables.
Algunos de los comandos que están relacionados al uso de las variables son los siguientes:
• $ echo
Muestra texto en pantalla, incluyendo el resultado de lectura de variables.
• $ export
Permite inicializar y/o convertir en global las variables
OpenSourceCollege
Linux for SysAdmins
Página 21
Source Linux
• $ set
Imprime un listado de las variables definidas en nuestra sesión de shell actual. Incluye las variables locales y globales.
• $ env
Imprime un listado de las variables definidas en nuestra sesión de shell actual. Incluye sólo las variables globales.
• $ unset
Elimina el valor de una variable
Ejemplo 1:
Consultar el valor de la variable EDITOR, asignarle como valor el nombre de un programa de edición (nano, vim, kate, gedit, u
otros) y analizar el comportamiento del comando crontab (proceso invocado desde la shell) cuando la variable tiene un ámbito local y
global.
a) Consultamos el valor con una de las dos alternativas:
$ echo $EDITOR
$ set
b) Ejecutemos el comando crontab e identifiquemos qué editor de texto se nos presenta en pantalla:
$ crontab -e
c) La aplicación crontab por defecto ejecutará el editor definido en la variable EDITOR, sólo si ésta está exportada (es global). Así que
probaremos darle un valor sin exportarla y luego ejecutar crontab nuevamente:
$ EDITOR=vim
$ crontab -e
d) Resulta que el mismo editor que la vez anterior es el que se nos mostró. Ahora exportemos la variable:
$ export EDITOR=vim
$ crontab -e
e) ¿Se ha notado qué editor se ejecutó ahora? ¿Qué editor se muestra ahora en el próximo ejemplo?
$ export EDITOR=gedit
$ crontab -e
f) Ahora fijémonos el listado de las variables:
$ set
$ env
g) Eliminemos la variable EDITOR y volvamos a lanzar el crontab:
$ unset EDITOR
$ crontab -e
Variables importantes
El siguiente es un listado de algunas de las variables más importantes en la shell Bash.
Variable Significado
HOME Directorio personal del usuario
SHELL Ruta de la shell o intérprete de órdenes en ejecución
USER Usuario actual logueado en la shell.
OpenSourceCollege
Linux for SysAdmins
Página 22
Source Linux
PATH Lista de directorios separados por dos puntos ":" donde la shell buscará las aplicaciones a ejecutar cuando éstas se
invocan sin incluir la ruta absoluta.
PWD Nuestra ubicación en el sistema de archivos
HOSTNAME Nombre del sistema
PPID El PID del proceso padre
PS1 Define la forma que tiene el prompt de la línea de comandos cuando la Shell está lista para aceptar órdenes
PS2 Define el caracter que se muestra como prompt secundario al partir una sentencia en múltiples líneas con \
Define el programa de edición que por defecto se utilizará para herramientas tales como crontab, edquota u
EDITOR
otros que en su ejecución necesitan utilizar algún editor de textos.
Cabe resaltar que la variable PS1 puede incluir en su definición ciertos caracteres especiales con significados particulares como se
describe abajo:
• \u El nombre del usuario actual

• \h Nombre de host del sistema
• \t La hora actual en formato de 24 horas
• \w La ruta absoluta de la ubicación actual (pwd) dentro del sistema de archivos
• \W La ruta base de la ubicación actual (pwd) dentro del sistema de archivos
Existen otros caracteres especiales que están documentados en bash(1) sección PROMPTING.
La entrada estándar (STDIN), salida estándar (STDOUT) y salida de error (STDERR)

Estos tres son conceptos típicos de todo sistema UNIX. Son descriptores de archivo que son abiertos siempre al inicio de ejecución de
cada proceso. Cada uno de estos descriptores tiene un identificador numérico que por convención son los siguientes:
Número de descriptor Tipo de descriptor de archivo

0 Entrada estándar
1 Salida estándar
2 Salida de error
Esto permite que los procesos tomen datos por el descriptor 0 (entrada estándar), arrojen los resultados por el descriptor 1 (salida
estándar) y muestren los errores por el descriptor 2 (salida de error).
En la práctica esto significa que la entrada estándar se toma desde el teclado mientras que la salida estándar y salida de error son
mostrados a través de la pantalla.
Visualmente no es fácil distinguir una salida estándar de una salida de error, pues ambos se ven como texto en la pantalla. Sin
embargo es importante comprender que la salida de error es usado por las aplicaciones para mostrar mensajes de error, advertencia o
diagnóstico, generalmente para informar que algo no está funcionando como se esperaba.
Redirecciones
Una redirección es un mecanismo que consiste en enviar la salida (estándar o de error) u obtener la entrada de una aplicación
hacia/desde un archivo.
Las redirecciones de entrada anula la intervención del usuario (desde teclado) para ingresar datos a una aplicación dando lugar a que
dicha entrada sea obtenida desde un archivo.
Las redirecciones de salida (estándar o de error) anulan la muestra de datos en pantalla dando lugar a que dicha salida sea enviada a
un archivo.
El uso de las redirecciones es importante en casos que requerimos cierto nivel de automatización de tareas, por ejemplo cuando
usamos comandos cuya salida es abundante, tal como dmesg, es importante poder capturar esa información en un archivo para
poderla leer con calma.
La sintaxis de las redirecciones simples y dobles se muestra a continuación:
Símbolos de
Tipo de redirección Modo de uso Descripción
redirección
< ó 0< Redirección de entrada $ comando < archivo Toma la entrada de datos desde un archivo
estándar
> ó 1> Redirección simple de $ comando > archivo Envía la salida estándar hacia un archivo
salida estándar sobreescribiendo su contenido
OpenSourceCollege
Linux for SysAdmins
Página 23
Source Linux
Envía la salida estándar hacia un archivo
>> ó 1>> Redirección doble de salida $ comando >> archivo
agregándolo al final del mismo (no
estándar
sobreescribe)
2> Redirección simple de $ comando 2> archivo Envía la salida de error hacia un archivo
salida de error sobreescribiendo su contenido
Envía la salida de error hacia un archivo
2>> Redirección doble de salida $ comando 2>> archivo
agregándolo al final del mismo (no
de error
sobreescribe)
&> Redirección simple de $ comando &> archivo Envía la salida estándar y de error hacia un
salida estándar y de error archivo sobreescribiendo su contenido
Las siguientes son las transformaciones de redirecciones de salida estándar y salida de error:
Símbolos de
Modo de uso Descripción
transformación
2>&1 $ comando 2>&1 Transforma la salida de error en salida estándar
1>&2 $ comando 1>&2 Transforma la salida estándar en salida de error
Ejemplo 2:
a) Captura la salida del comando dmesg en archivo1.txt, y los comandos df -h y free -m en archivo2.txt. Visualizar luego los archivos
creados.
$ dmesg > archivo1.txt

$ df -h > archivo2.txt
$ free -m >> archivo2.txt
$ cat archivo1.txt
$ cat archivo2.txt
b) Enviar un correo a info@consultorianet.com con un mensaje de prueba:
$ mail -s "Mensaje de prueba 1" info@consultorianet.com

Hola, este es un mensaje de prueba
.
Cc:[Enter]
c) Ahora enviar otro correo tomando el contenido del archivo /etc/fstab como entrada (cuerpo del mensaje):
$ mail -s "Mensaje de prueba 2" info@consultorianet.com < /etc/fstab
d) El comando ssh sin ningún parámetro nos muestra una salida estándar la que debemos redireccionar hacia archivo2.txt al final de
éste (no sobreescribir):
$ ssh 2>> archivo2.txt
e) La misma salida del comando anterior convertirla en salida estándar y redireccionarla hacia archivo1.txt:
$ ssh > archivo1.txt 2>&1
f) La salida del comando fdisk -l ejecutado como usuario sin privilegios (salida de error) y ejecutado como root (salida estándar)
redireccionarlo hacia el archivo /tmp/test. Visualizar luego el contenido del archivo creado.
$ fdisk -l &> /tmp/test

# fdisk -l &> /tmp/test
# cat /tmp/test
Tuberías
Las tuberías también conocidas como pipes, es aquella acción en la cual dos o más aplicaciones se conectan de forma tal que la salida
del primero se convierte en la entrada del siguiente. Esto es posible gracias a la conexión directa de la entrada estándar de un proceso
con la salida estándar de otro que le antecede. La salida de error no pasa a través de una tubería a menos que se transforme a salida
estándar.
OpenSourceCollege
Linux for SysAdmins
Página 24
Source Linux
Las tuberías son extremadamente útiles en todo sistema UNIX para maximizar los beneficios de la Shell a través del trabajo conjunto
de múltiples aplicaciones para resolver tareas complejas a través del intercambio de información de cada uno de los procesos
participantes en la cadena.
El símbolo de tubería es el "|" (código ASCII 124) y la forma de crear una tubería es como sigue:
$ comando1 | comando2 | comando3 | ...
Ejemplo 3:
a) Calcular cuántas líneas posee la salida del comando dmesg:
$ dmesg | wc -l
b) Enumerar cada una de las líneas de la salida del comando dmesg y filtrar aquellas que contengan la palabra kernel:
$ dmesg | cat -n | grep -i --color kernel
c) Pasar a mayúsculas la salida de error del comando ssh:
$ ssh 2>&1 | tr a-z A-Z
Comodines
La shell Bash tiene reservados ciertos caracteres llamados comodines los cuales se usan para sustitución de patrones de texto como:
Caracter Descripción
* Coincidencia con cualquier caracter 0, 1 o más veces
? Coincidencia con cualquier caracter 1 sola vez
[ ] Coincidencia con cualquier caracter encerrado en los corchetes [ ]
[! ] Coincidencia con cualquier caracter excepto los encerrado en los corchetes [ ] luego del !
{ } Coincidencia con grupos encerrados dentro de las llaves { } cada uno separado por coma
Ejemplo 4:
a) Listar los programas que empiecen con una 'b':
$ ls /usr/bin/b*
b) Listar todos los programas que contienen una 'b' como segundo caracter:
$ ls /usr/bin/?b*
c) Listar todos los programas que comiencen con una 'a' y el segundo caracter sea 'c', 'd', 'e' o 'f' (dos alternativas equivalentes):
$ ls /usr/bin/a[cdef]*
$ ls /usr/bin/a[c-f]*
d) Listar todos los programas que comiencen con una 'a' y el segundo caracter no sea cualquiera entre la 'g' y la 'z':
$ ls /usr/bin/a[!g-z]*
e) Listar todos los archivos de extensión .conf o cualquier otra extensión de 3 caracteres dentro del directorio /etc:
$ ls /etc/*.{conf,???}
Variables especiales
La siguiente tabla resume las variables especiales más importantes:
OpenSourceCollege
Linux for SysAdmins
Página 25
Source Linux
Variable Significado
$$ PID de la shell en ejecución
$! PID del último proceso ejecutado en segundo plano (background)
$? El código de estado retornado por la última aplicación ejecutada
$0 Nombre del script de shell en ejecución
$# Número de parámetros pasados a un script
$1, $2, $3, Parámetro N° 1, N° 2, N°3, y así sucesivamente
...
$@ Todos los parámetros pasados al script
Operadores
La siguiente tabla resume algunos de los operadores más importantes:
Operador Significado
$( ) Captura el resultado (salida estándar) de una aplicación o conjunto de ellas en tubería
$(( )) Operación aritmética simple
&& AND lógico. Permite ejecutar aplicaciones de manera secuencial si la anterior terminó correctamente.
|| OR lógico. Permite ejecutar aplicaciones de manera secuencial si la anterior no terminó correctamente.
; Separador de sentencias. Permite ejecutar aplicaciones de manera secuencial sin importar cómo terminó la
aplicación anterior.
& Ejecutar un proceso en segundo plano (background)
Ejemplo 5:
a) Mostrar el producto de los números 34 y 29, y el resultado dividirlo entre 10:
$ PRODUCTO=$((34*29))
$ echo $PRODUCTO
$ PRODUCTO=$(($PRODUCTO/10))
b) Consultar la hora y fecha actual del sistema, el resultado almacenarlo en la variable DATE y mostrarlo en pantalla convertido en
mayúsculas; todo realizado desde una única línea de comandos secuencial:
$ DATE=$(date); echo $DATE | tr a-z A-Z
c) Ejecutar el comando date, luego free -m, luego mkdir y luego df -h uno tras otro con la condición de ejecutar el próximo si el
anterior terminó correctamente. ¿Qué comando no se llegó a ejecutar?
$ date && free -m && mkdir && df -h
d) Realizar el mismo procedimiento anterior excepto que df -h se debe ejecutar sólo si mkdir no terminó correctamente. ¿Faltó
ejecutar algún comando?
$ date && free -m && mkdir || df -h
Comillas y caracter de escape

Las comillas tienen un tratamiento especial de la mano con el caracter de escape tal como se muestra en la siguiente tabla:
Caracter Significado
` ` Captura el resultado (salida estándar) de una aplicación o conjunto de ellas en tubería. Igual que el operador $( )
" " Anula el significado de todos los caracteres excepto $, ` y \
' ' Anula el significado de todos los caracteres excepto \
OpenSourceCollege
Linux for SysAdmins
Página 26
Source Linux
\ Caracter de escape que precede a otros especiales como $, |, \, *, >, <, etc. También se usa como una forma de
romper una línea larga de comandos en varias de menor tamaño continuadas una debajo de otra.
Ejemplo 6:
a) Mostrar la salida del comando date junto al valor de la variable HOME, todo encerrado entre doble comillas. Analice los resultados:
$ echo "`date` $HOME"
b) Intentar hacer el procedimiento anterior pero encerrado en comillas simples. Analice los resultados y diferencias encontradas:
$ echo '`date` $HOME'
c) Ejecutar una sentencia de comandos dividida en 3 líneas:
$ dm\
> es\
> g
Historial de comandos
Bash al igual que otras Shell, cuenta con una característica que permite almacenar un historial de todos las órdenes o comandos
ingresados. Este historial puede ser consultado, limpiado y desactivado desde la línea de comandos así como también cuenta con
parámetros personalizables los cuales se detallan a continuación:
• El comando history imprime el historial de comandos del usuario, y history -c lo limpia.
• La variable HISTFILE contiene la ruta del archivo de historial de comandos del usuario.
• La variable HISTSIZE determina la cantidad máxima de comandos que se recordarán en el historial.
• El historial de comandos se desactiva ejecutando set +o history y se vuelve a activar ejecutando set -o history
• Las siguientes son formas de consulta rápida del historial de comandos:
$ !!
Ejecuta el último comando usado.
$ !texto1
Ejecuta el último comando que empieza con texto1
$ !?texto2
Ejecuta el último comando (entre el comando y todos sus parámetros) que contiene texto2
Alias de comandos
Bash permite personalizar y 'crear' nuestros propios comandos a través del uso de alias. Éstos permiten definir uno o más comandos
en serie a ser ejecutados tras la invocación de un nombre que nosotros elijamos.
El uso de los alias se explica a continuación:
• Usamos el comando alias de manera similar a la asignación de una variable cuyo contenido es el(los) comandos a ejecutar.
Ejemplo:
$ alias lh='ls -lhSr'

$ alias dm='dmesg | cat -n'
• Una vez definidos simplemente nos queda invocarlos como lh o dm. Cualquier parámetro que le pasemos a los alias se
transmitirán como tales al último comando que forma parte del alias.
$ lh /boot
drwxr-xr-x 2 root root 1.0K oct 12 18:57 grub
-rw-r--r-- 1 root root 84K ago 19 19:42 config-2.6.26-2-amd64
-rw-r--r-- 1 root root 1.2M ago 19 19:42 System.map-2.6.26-2-amd64
-rw-r--r-- 1 root root 1.7M ago 19 19:41 vmlinuz-2.6.26-2-amd64
-rw-r--r-- 1 root root 8.5M sep 22 09:02 initrd.img-2.6.26-2-amd64
OpenSourceCollege
Linux for SysAdmins
Página 27
Source Linux
$ dm | tail -3
741 [ 1005.143725] device eth0 entered promiscuous mode
742 [ 5511.291881] device eth0 left promiscuous mode
743 [ 6783.599910] device eth0 entered promiscuous mode
• La forma de consultar los alias existentes es usando el comando alias sin ningún parámetro:
$ alias
alias dm='dmesg | cat -n'
alias lh='ls -lhSr'
alias ls='ls –color=auto'
• Asimismo usamos el comando unalias para eliminar un alias ya existente:
$ unalias dm lh
Las siguientes son combinaciones de gran utilidad en el uso diario cuando se ponen en práctica:
• ^P : Busca el comando anterior en el historial

• ^N : Busca el comando siguiente en el historial
• ^K : Borra de la ubicación actual hasta el fin de línea
• Û : Borra de la ubicación actual hasta el inicio de línea
• ^D : Borra un caracter hacia la derecha
• ^H : Borra un caracter hacia la izquierda
• ^F : Avanza un caracter hacia la derecha
• ^B : Avanza un caracter hacia la izquierda
• ^W : Borra una palabra hacia la izquierda
• Alt+D : Borra una palabra hacia la derecha
• Alt+B : Retrocede una palabra hacia la derecha
• Alt+F : Avanza una palabra hacia la derecha
Autocompletado
Bash provee una funcionalidad muy práctica que consiste en el completado automático de nombres de archivos, directorios o
comandos mientras vamos escribiéndolos en el intérprete de órdenes haciendo uso de la tecla [Tab] (tabulador).Esto tiene por
objetivo abreviar la cantidad de texto que escribimos dejando que Bash adivine el resto de caracteres faltantes.
Para eso debemos escribir parte de un texto y presionar una vez la tecla [Tab] donde por defecto sucederá una de dos posibilidades:
(a) Se realiza el autocompletado total con el nombre del comando o ruta del archivo/directorio.
(b) Se realiza el autocompletado parcial del nombre del comando o ruta del archivo/directorio.
(c) No aparece nada en pantalla, nada sucede.
Si ocurre (a) entonces no hay más nada que hacer. Si ocurre (b) quizás el autocompletado parcial ya satisface nuestra expectativa del
comando o archivo que buscábamos, sino podremos seguir intentando autocompletar según (c).
Si ocurre (b) no es porque el autocompletado no funcionó, sino porque Bash encontró más de una coincidencia con parte del texto que
escribimos, así que nos queda una de dos posibilidades:
(1) Escribir algo más de texto de modo tal que las coincidencias se reduzcan e incluso quede sólo una
(2) Presionar por segunda vez la tecla [Tab] y dejar que Bash nos muestre todas las alternativas que existen actualmente
Si optamos por (1) entonces ese proceso puede seguir repitiéndose sucesivamente entre los casos (a), (b) y (c) de la mano con
escritura adicional de texto por nuestra parte hasta lograr que la coincidencia sea única y se de finalmente el autocompletado.
Si optamos por (2) entonces Bash muestra en pantalla todas las coincidencias con el texto que hemos logrado escribir con el propósito
que nos demos cuenta cuál es el comando o archivo que nos interesa y escribamos tanto como sea necesario para eliminar
coincidencias adicionales de la mano con la tecla [Tab].
Ejemplo 7:
a) En la línea de comandos, escribir "cl" y tipear la tecla [Tab] tantas veces como se crea conveniente y apreciar qué sucede en
cada presión de dicha tecla:
$ cl[Tab]
$ clea
$ clea[Tab][Tab]
cleanlinks clear clear_console
OpenSourceCollege
Linux for SysAdmins
Página 28
Source Linux
b) Hagamos algo similar con listando un archivo, escribiendo primero "/et" y [Tab], luego "X" y [Tab], luego "x" y [Tab][Tab]:
$ ls /et[Tab]
$ ls /etc/
$ ls /etc/X[Tab]
$ ls /etc/X11/
$ ls /etc/X11/x[Tab][Tab]
xkb/ xorg.conf xorg.conf.backup xserver/
2.3. Manejo de archivos
Estructura de directorios
La siguiente tabla muestra los directorios comunes en todo sistema Linux y una descripción del propósito de cada uno de ellos:
Directorio Descripción
/ Jerarquía primaria y raíz del sistema de archivos entero
/bin Comandos binarios esenciales que por lo general no requieren privilegios de administrador para ser ejecutados
/boot Archivos requeridos para el arranque del sistema operativo. Aquí se encuentra el kernel
/dev Dispositivos esenciales
/etc Archivos de configuración del sistema
/home Directorio de los usuarios (contiene sus datos personales). Ubicada normalmente en una partición separada
/lib Archivos de biblioteca esenciales requeridos por los binarios de /bin y /sbin
/media Contiene los puntos de montaje para dispositivos removibles (CDROM, memorias USB, discos externos, etc)
/mnt Punto de montaje temporal de otros sistemas de archivos
/opt Directorio de instalación de software opcional
/proc Sistema de archivos virtual que contiene información de procesos y el kernel
/root Directorio del usuario root (contiene sus datos personales)
/sbin Comandos binarios esenciales que por lo general requieren privilegios de administrador para ser ejecutados
/srv Directorio de datos servidos por el sistema
/tmp Temporales del sistema
/usr Jerarquía secundaria del sistema que contiene aplicaciones de uso para todos los usuarios
/var Archivos variables y abundantes tal como logs, buzones de correo, temporales, etc.
* Tabla acorde al Filesystem Hierarchy Standard (http://es.wikipedia.org/wiki/Filesystem_Hierarchy_Standard)
El caracter ~
Este caracter tiene un significado especial cuando trabajamos en un sistema de archivos, y es que hace referencia al directorio
personal de un usuario. Tiene dos formas de usarlo:
• ~ : Hace referencia al directorio personal del usuario con el cual estamos actualmente trabajando
• ~USER : Hace referencia al directorio personal del usuario USER
Ejemplo 8:
a) Asumiendo que actualmente trabajamos como el usuario root los siguientes comandos ejecutados son equivalentes:
# mkdir ~/prueba1
# mkdir /root/prueba1
# mkdir ~root/prueba1
b) De manera similar asumiendo que actualmente trabajamos como el usuario consultorianet, los siguientes comandos son
equivalentes:
$ cd ~/Desktop
$ cd /home/consultorianet/Desktop
$ cd ~consultorianet/Desktop
OpenSourceCollege
Linux for SysAdmins
Página 29
Source Linux
Rutas relativas y rutas absolutas
Dado que en gran parte de este curso se enseñan herramientas de línea de comandos que trabajan con archivos y directorios, es
importante conocer la diferencia entre dos formas de hacer referencia a las rutas tal como se detalla a continuación:
• Ruta absoluta : Es una ruta que apunta siempre a una misma ubicación sin importar cuál sea nuestra ubicación actual.
Usualmente es escrita en referencia a la raíz (/). También son absolutas aquellas que empiezan con la invocación a un
directorio de usuario con el caracter ~
• Ruta relativa : Es una ruta relativa al directorio actual de trabajo y por lo tanto no inician desde la raíz (/).
En esta sección es importante resaltar un par de comandos útiles como son basename y dirname:
basename <archivo/directorio> [sufijo]

Elimina directorios base y sufijos de rutas de archivos y/o directorios
dirname <archivo/directorio> [sufijo]

Muestra sólo directorios base de rutas de archivos y/o directorios
Ejemplo 9:
a) Las siguientes son rutas absolutas válidas:
• /etc
• /usr/local/share
• ~root/Desktop/tarball.zip
b) Asumiendo que nuestro directorio de trabajo actual es /usr las siguientes son rutas relativas válidas:
• share/icons/gnome/
• lib/openssh/
• include/linux/fcntl.h
c) Observar el resultado y comprender el uso de los comandos basename y dirname en los ejemplos mostrados:
$ basename /usr/local/share
share
$ basename /etc/X11/xorg.conf
xorg.conf
$ basename /etc/X11/xorg.conf .conf

xorg
$ basename /usr/include/linux/sysctl.h .h
sysctl
$ dirname /usr/local/share
/usr/local
$ dirname /usr/include/linux/sysctl.h
/usr/include/linux
Control de archivos
A continuación estudiaremos algunos de los comandos más importantes y comunes en el uso diario para el buen desenvolvimiento en
un sistema de archivos Linux. Primero presentamos una tabla resumida para luego ir por el detalle de cada uno de ellos:
Comando Descripción
pwd Informa de nuestra ubicación (o directorio de trabajo) actual en el sistema de archivos
cd Nos cambia hacia otro directorio
file Informa tipos de archivo
touch Crea archivos y/o altera sus fechas de modificación
OpenSourceCollege
Linux for SysAdmins
Página 30
Source Linux
rmdir Elimina directorios
ls Imprime un listado de archivos y/o directorios
cp Copia archivos y/o directorios
mv Mueve o renombra archivos y/o directorios
mkdir Crea directorios
rm Elimina archivos y/o directorios
du Calcula el espacio utilizado por archivos y/o directorios
find Busca archivos y/o directorios
which Busca la ubicación de comandos
whereis Busca la ubicación de comandos, fuentes y documentación
ln Crea enlaces duros y/o simbólicos
El detalle de los comandos que aceptan una o más opciones se muestra a continuación:
cd [directorio]
Cambia de directorio
Si directorio se omite entonces por defecto se cambia hacia el directorio personal del usuario
touch [opciones] <archivo/directorio> [archivo/directorio] ...

Crea archivos y altera la fecha de modificación de archivos y/o directorios
Opciones:
-a : Cambia sólo la fecha de acceso

-m : Cambia sólo la fecha de modificación
Si el archivo/directorio indicado como parámetro no existe entonces touch lo crea
ls [opciones] <archivo/directorio> ... [archivo/directorio]

Lista archivos y/o directorios
Opciones:
-a : Mostrar archivos ocultos

-l : Listado detallado en columnas
-h : Muestra tamaño de archivos con prefijos KB, MB, GB, ... Válido en conjunto con -l
-i : Muestra el i-nodo de cada archivo
-S : Ordena los archivos por tamaño
-t : Ordena los archivos por fecha de modificación
-r : Invierte el criterio de ordenamiento
-d : Lista el directorio en sí mas no su contenido
-R : Lista recursivamente un directorio
-F : Muestra los tipos de archivo según los caracteres @, /, *
cp [opciones] <origen1> [origen 2] ... <destino>

Copia archivos y/o directorios
Opciones:
-r : Copia recursiva. Parámetro obligatorio para copiar directorios.

-p : Preserva los permisos y propietarios de lo que copia
-d : Copia un enlace simbólico y no a donde apunta
-l : No copia, crea enlaces duros
-i : Interactivo, consulta antes de sobreescribir
-f : No interactivo, fuerza la sobreescritura. Lo opuesto de -i
-v : Muestra cada archivo copiado
Si el destino no existe entonces el origen debe ser único y crea una copia de éste con el nombre y ruta del destino
Si el destino ya existe y es un directorio entonces copia el(los) origen(es) a la ruta del destino
Si el destino ya existe y es un archivo entonces el origen debe ser único y éste sobreescribe al destino
OpenSourceCollege
Linux for SysAdmins
Página 31
Source Linux
mv [opciones] <origen1> [origen 2] ... <destino>
Mueve y renombra archivos y/o directorios
Opciones:
-i : Interactivo, consulta antes de sobreescribir

-f : No interactivo, fuerza la sobreescritura. Lo opuesto de -i
-v : Muestra cada archivo copiado
Si el destino no existe entonces el origen debe ser único y mueve el origen renombrándolo con el nombre y ruta del destino
Si el destino ya existe y es un directorio entonces mueve el(los) origen(es) a la ruta del destino
Si el destino ya existe y es un archivo entonces el origen debe ser único y éste sobreescribe al destino
mkdir[opciones] <directorio1> [directorio2] ...

Crea directorios
Opciones:
-m modo : Establece los permisos del directorio creado segun el valor de modo
-p : Crea los directorios de nivel superior que aún no existiesen
rm [opciones] <directorio1> [directorio2] ...

Elimina archivos y/o directorios
Opciones:
-f : No pide confirmación, no escribe mensajes de diagnóstico, ni avisa de errores por archivos que no existiesen
-i : Pide confirmación
-r : Borrado recursivo. Parámetro obligatorio para borrar directorios.
du [opciones] [archivo/directorio] ...

Calcula el espacio utilizado por archivos y/o directorios
Opciones:
-c : Muestra un total para todos los argumentos (después de ser procesador) pasados al comando
-h : Muestra los tamaños con sufijos de fácil identificación (K para KB, M para MB, G para GB)
-s : Muestra solamente un total para cada argumento
find <directorio> [opciones <patron>]

Busca archivos y/o directorios
Opciones:
-name patron : Busca archivos que coincidan con patrón (Ejm: "*.conf", "*mk*")
-iname patron : Igual que -name pero insensible a mayúsculas
-user usuario : Busca archivos cuyo propietario sea usuario
-size tamaño : Busca archivos según tamaño (Ejm: +400k, -10M, 2G)
-type tipo : Busca según el tipo de archivo (f: archivo, d: directorio, l: enlace simbólico, etc)
Este comando dispone de múltiples parámetros de interés los cuales deben ser revisados a detalle en find(1)
Enlaces duros y simbólicos
A) Los enlaces simbólicos son accesos directos hacia archivos o directorios. Estos enlaces no son archivos reales, por lo tanto
cualquier acción de modificación que se pretenda hacer sobre ellos se realiza realmente sobre el archivo o directorio al que
apuntan, pero sin embargo cuando los eliminamos no se borra la referencia al que apunta sino se elimina el mismo enlace.
Una peculiaridad es que el tamaño de un enlace simbólico siempre es igual a la cantidad de caracteres que contiene la ruta a
la que apunta.
B) Los enlaces duros son referencias o punteros a otros archivos existentes en el sistema. Se visualizan como archivos reales,
idénticos al archivo original al que referencian en todos sus atributos, sin embargo no son archivos nuevos sino tan sólo una
especie de clones abstractos que se caracterizan por tener el mismo número de inodo (identificador numérico siempre único
para todo archivo y directorio en un sistema de archivos).
Esto trae conlleva a peculiaridades como el hecho que todos los enlaces duros creados no ocupan más espacio en disco, o
el hecho que cualquier modificación hecha sobre un enlace duro se aplica igual e inmediatamente a todos los demás enlaces
OpenSourceCollege
Linux for SysAdmins
Página 32
Source Linux
y el original.
Esto es posible si tenemos en cuenta que los nombres de archivos son sólo etiquetas hacia cierta porción del sistema de
archivos, por lo tanto cualquier manipulación que hacemos sobre los archivos se realizan en realidad sólo sobre esas
etiquetas que apuntan a los datos reales almacenados en el sistema de archivos.
Por ello tanto el archivo original como cualquiera de los enlaces duros no son más que etiquetas, todos iguales, llegando
incluso a la conclusión de razonamiento que cualquier archivo creado en el sistema no es más que el primer enlace duro a
los datos que existen sólo 1 vez (número de inodo siempre es único).
Cabe tener en cuenta que los enlaces duros a directorios no están permitidos en Linux (aunque ln(1) pueda decir lo
contrario). Tampoco es posible crear enlaces duros hacia archivos que estén en otro sistema de archivos diferente al archivo
original (otra partición, otro dispositivo).
ln [opciones] <origen> <destino>

Crea enlaces simbólicos y duros
Opciones:
-f : Borra los archivos de destino que pudiesen ya existir

-i : Interactivo, consulta antes de borrar archivos de destino que pudiesen ya existir
-s : Crea enlaces simbólicos en lugar de enlaces duros
Ejemplo 10:
a) Desplazarse por el sistema de archivos, consultar la ubicación actual dentro del mismo luego de cada cambio y averiguar el tipo de
algunos archivos encontrados dentro:
$ cd /usr/local
$ pwd
/usr/local
$ file bin/
bin/: directory
$ cd /etc/X11/
$ pwd
/etc/X11
$ file xorg.conf
xorg.conf: ASCII text
b) Crearemos algunos archivos (archivo1 y archivo2) y directorios (dir1 y dir2), copiaremos información (los archivos fstab y hosts de /etc/)
y finalmente los eliminaremos:
$ touch archivo1 archivo2 # creamos los archivos archivo1 y archivo2

$ mkdir dir1 dir2 # creamos los directorios dir1 y dir2
$ cp /etc/{fstab,hosts} dir1/ # copiamos /etc/fstab y /etc/hosts a dir1
$ cp archivo* dir2/ # copiamos archivo1 y archivo2 a dir2
$ ls dir2/ # vemos el contenido de dir2
$ rm -rfv dir* # eliminamos dir1 y dir2
«dir1/fstab» borrado
«dir1/hosts» borrado
directorio borrado: «dir1»
«dir2/archivo2» borrado
«dir2/archivo1» borrado
directorio borrado: «dir2»
$ rm -v archivo[12] # eliminamos archivo1 y archivo2
«archivo1» borrado
«archivo2» borrado
c) Crearemos archivos (archivo3 y archivo4) y directorios nuevamente (dir3 y dir4), moveremos y renombraremos algunos de ellos para
finalmente eliminarlos:
$ touch archivo3 archivo4 # creamos los archivos archivo3 y archivo4

$ mkdir dir3 dir4 # creamos los directorios dir3 y dir4
$ mv archivo3 dir3/ # movemos archivo3 a dir3
$ mv archivo4 dir4/ARCHIVO4 # movemos archivo4 a dir4 y lo renombramos a ARCHIVO4
$ mv dir3 DIR3 # renombramos dir3 a DIR3
$ mv dir4/ DIR3/DIR4 # movemos dir4 a DIR3 y lo renombramos a DIR4
$ rm -rf DIR3/ # eliminamos DIR3
OpenSourceCollege
Linux for SysAdmins
Página 33
Source Linux
d) Crearemos enlaces duro al archivo /etc/fstab de estas dos formas equivalentes:
$ cp -l /etc/fstab fstab_2
$ ln /etc/fstab fstab_3
e) Crear un enlace simbólico al archivo /etc/fstab:
$ ln -s /etc/fstab fstab_4
f) Buscar enlaces simbólicos de extensión .conf dentro de /etc y suprimir la salida de error:
$ find /etc -type l -name "*.conf" 2> /dev/null
g) Buscar imágenes dentro de /usr que sean mayores a 300 KB:
$ find /usr $ -name "*.jpg" -o -name "*.gif" -o -name "*.png" $ -size +300k
h) Ubicar referencias del comando mkdir y archivo fstab:
$ which mkdir
$ whereis mkdir
$ whereis fstab
Empaquetamiento y compresión
El empaquetamiento es el procedimiento por el cual se agrupan varios archivos y/o directorios en un único archivo sin aplicar sobre
ellos un algoritmo de compresión. El encargado de hacer esta función es el comando tar.
Los procesos de compresión en Linux se hacen a través de los comandos gzip y bzip2 de los cuales el segundo se caracteriza por
ofrecer un mejor nivel de compresión pero mucho mayor carga del CPU (consume mucho más tiempo). Ambos son capaces de
comprimir sólo 1 archivo, y no comprimen directorios. Para lograr comprimir varios archivos y directorios a la vez se requiere usar un
empaquetar y luego comprimir, todo invocar desde el comando tar con ciertos parámetros adecuados que líneas abajo mostramos.
Alternativamente se puede utilizar el comando zip que trabaja casi de igual manera que su equivalente en plataformas Microsoft
Windows, el Winzip, para poder comprimir varios archivos y directorios a la vez. Sin embargo en sistemas UNIX predomina mucho más
el uso de empaquetado y compresión con tar, gzip y bzip2.
gzip [opciones] <archivo1> [archivo2] ...

gunzip [opciones] <archivo1> [archivo2] ...
zcat [opciones] <archivo1> [archivo2] ...
Herramientas de compresión y descompresión de archivos individuales
Opciones:
-d : Descomprime
-c : El resultado de la compresión/descompresión es arrojado a stdout y deja intacto el archivo original
-# : Nivel de compresión: -1 más rápido y de menor compresión, -9 más lento mejor compresión, -6 valor por defecto
gzip por defecto comprime archivos agregándoles la extensión .gz (eliminando el original). gunzip es equivalente a gzip -d y zcat
equivalente a gzip -dc. Ambos aceptan los mismos parámetros que gzip
bzip2 [opciones] <archivo1> [archivo2] ...

bunzip2 [opciones] <archivo1> [archivo2] ...
bzcat [opciones] <archivo1> [archivo2] ...
Herramientas de compresión y descompresión de archivos individuales
Opciones:
-d : Descomprime
-c : El resultado de la compresión/descompresión es arrojado a stdout y deja intacto el archivo original
-# : Nivel de compresión: -1 más rápido y de menor compresión, -9 más lento mejor compresión, -6 valor por defecto
bzip2 por defecto comprime archivos agregándoles la extensión .bz2 (eliminando el original). bunzip2 es equivalente a bzip2 -d y
bzcat equivalente a bzip2 -dc. Ambos aceptan los mismos parámetros que bzip2
OpenSourceCollege
Linux for SysAdmins
Página 34
Source Linux
tar [opciones] <archivo1/directorio1> [archivo2/directorio2] ...
Empaquete archivos y/o directorios
Opciones:
-c : Empaqueta
-x : Desempaqueta
-t : Lista el contenido de un archivo empaquetado
-C DIR : Desempaqueta en el directorio DIR en lugar de hacerlo en el directorio de trabajo actual
-f FILE : Empaqueta/desempaqueta en un archivo o dispositivo indicado en FILE (si se omite -f el resultado se envía a stdout)
-v : Verboso. Muestra archivos procesador
-z : Invoca a gzip para comprimir o descomprimir
-j : Invoca a bzip2 para comprimir o descomprimir
zip [opciones] <archivo-zip> <archivo1/directorio1> [archivo2/directorio2] ...

Comprime archivos y/o directorios
Opciones:
-r : Comprime recursivamente (parámetro obligatorio para directorios)

-e : Encripta el contenido del comprimido con una contraseña
unzip [opciones] <archivo-zip>

Descomprime archivos
Opciones:
-d DIR : Descomprime en el directorio DIR en lugar de hacerlo en el directorio de trabajo actual
Ejemplo 11:
a) Empaquetar en un archivo de nombre paquete 1.tar el directorio /etc, /tmp y los archivos *.log del directorio /var/log. Luego comprimir
con gzip el archivo resultante y visualizar su contenido:
# tar -cvf paquete1.tar /etc /tmp /var/log/*.log

# gzip paquete1.tar
# tar -tzf paquete1.tar.gz
b) Descomprimir y desempaquetar el archivo anterior resultante en el directorio /tmp/prueba que nosotros crearemos. Luego
empaquetar y comprimirlo usando bzip2 hacia un archivo resultante de nombre paquete2.tar.bz2:
# mkdir /tmp/prueba
# tar -xzf paquete1.tar.gz -C /tmp/prueba
# tar -cjf paquete2.tar.bz2 /tmp/prueba
c) Comprimir el directorio /boot usando zip (protegiendo el archivo resultante con contraseña) y descomprimirlo luego con unzip en el
directorio /tmp/prueba que nosotros previamente creamos:
# zip -e -r boot.zip /boot

# unzip boot.zip -d /tmp/prueba
OpenSourceCollege
Linux for SysAdmins
Página 35
Source Linux
2.4. Procesamiento simple de texto
El procesamiento de texto es una tarea muy común en todo sistema UNIX, para facilitar el manejo de información emitida por
aplicaciones y su transformación a formatos particulares requeridos por nosotros.
Este procesamiento por lo general se da a través del uso de herramientas concatenadas en tuberías, donde cada una emite a la salida
estándar la información que otra herramienta ha de procesar.
Es por ello que todas las herramientas estudiadas en este apartado tienen la posibilidad de ser utilizadas como parte de una tubería en
la shell.
Expresiones regulares
Las expresiones regulares, como su nombre lo indica, son expresiones que describen un conjunto de patrones de texto a través de la
interpretación de ciertos caracteres con significado especial. Las expresiones regulares tienen por objetivo el hacer coincidencia con un
conjunto de palabras, frases o partes de ellas según la lógica de la expresión que nosotros creemos con el uso adecuado de caracteres
especiales.
Por ejemplo la expresión regular L[i1]nux{2} ha de coincidir con las palabras Linuxx, L1nuxx, Linuxxx, L1nuxxx, Linuxxxx,
L1nuxxxx, y así sucesivamente con letras 'x' adicionales, pero no coincide con Linux ni con L1nux.
Para entender mejor este ejemplo es necesario estudiar la tabla de expresiones regulares abajo mostrada:
Expresiones regulares básicas
Caracteres Descripción
. Cualquier caracter excepto el salto de línea (\n)
* Cero, una o más veces la expresión ubicada a su izquierda
^ Inicio de línea
$ Fin de línea
< Limita el inicio de una palabra
> Limita el fin de una palabra
[ ] Agrupación de caracteres coincidentes
[^ ] Agrupación de caracteres no coincidentes
\ Escape de caracteres especiales
[:alpha:] Agrupación de caracteres alfabéticos
[:alnum:] Agrupación de caracteres alfanuméricos
[:digit:] Agrupación de caracteres numéricos (dígitos)
[:lower:] Agrupación de caracteres alfabéticos en minúsculas
[:upper:] Agrupación de caracteres alfabéticos en mayúsculas
[:blank:] Agrupación de espacios en blanco y tabulaciones
Expresiones regulares extendidas
Caracteres Descripción
? Cero o una vez la expresión ubicada a su izquierda
+ Una o más veces la expresión ubicada a su izquierda
{ } Cantidad de ocurrencias de la expresión ubicada a su izquierda
| OR lógico de expresiones
( ) Agrupación de expresiones
A continuación se hace la interpretación a modo de ejemplos de varios de los caracteres especiales de las expresiones regulares arriba
vistos:
Expresión regular Coincide con No coincide con

a.b axb a3b aNb a$b a.b aab a32b Amb a9.B a#mb
a..b axyb a3mb a9#b aP.b a$$b A32b abb aMB a#A3b
OpenSourceCollege
Linux for SysAdmins
Página 36
Source Linux
c[aA][sz]a casa cAsa caza cAza Casa cazA cesa cazza
archivo[1-3] archivo1 archivo2 archivo3 archivo4 archivo0 archivoM archivo@
[â-z].txt 1.txt A.txt B.txt ,.txt -.txt {.txt a.txt b.txt m.txt f.txt
^[[:upper:]].*[0-9]$ Hola1 Casa3 Pelota9 Materia8 hola3 CasaA Pelota9B materia8
perr[o0]? perr perro perr0 Perro perra perrito perrO
perr[o0]+ perro perr0 perroo perr00 perrooo perr000 perr Perro perrO pErr0
Casa{2,3} Casaa Casaaa casaa casa casaaa
(pe|he)[sl]ado pesado pelado helado hesado Pelado helado celado Helado
([pm]a){2} papa mama mapa pama Mama paPa maapa pana
Una buena forma de probar estas expresiones regulares es a través del uso del comando grep -o y grep --color como sigue:
$ echo elarchivo17 | grep --color "archivo[1-3]"

$ echo perrooo | grep -oE "perr[o0]?"
$ echo "el helado de vainilla" | grep -E --color "(pe|he)[sl]ado"
Más información sobre el uso del comando grep se muestra líneas debajo.
Herramientas de manejo de texto

A continuación estudiaremos algunos de los comandos más importantes y comunes en el uso diario para lograr un buen manejo de los
flujos de texto en la línea de comandos:
cat Imprime en pantalla el contenido de textos
grep Imprime las líneas que coincidan con un patrón de textos
more Visualiza texto en pantalla dividido en páginas (permite sólo bajar la lectura)
less Visualiza texto en pantalla dividido en páginas (permite bajar y subir la lectura)
head Imprime las primeras líneas de textos
tail Imprime las últimas líneas de textos
wc Contabiliza la cantidad de bytes, palabras y líneas de textos
cut Imprime campos de un texto (cada uno separada por un caracter común)
sort Ordena las líneas de textos
uniq Reporta líneas repetidas de textos ordenados
tr Reemplaza y elimina caracteres de textos de entrada estándar
split Divide un archivo en partes
sed Editor de flujos de texto avanzado que permite filtrado y transformación
cat [opciones] [archivo] ...

Imprime en pantalla el contenido de textos
Opciones:
-n : Muestra números de línea
Si no se especifica al menos un archivo entonces se imprimirá el texto ingresado en la entrada estándar
grep [opciones] <patrón> [archivo] ...

grep [opciones] [ -e <patron>] [archivo] ...
Imprime las líneas que coincidan con un patrón de textos
Opciones:
-E : Interpreta el patrón como una expresión regular extendida
OpenSourceCollege
Linux for SysAdmins
Página 37
Source Linux
-e patrón : Usa patrón como patrón de coincidencia
-i : Ignora la sensibilidad a mayúsculas en la coincidencia de patrones
-w : Coincide con patrones sólo como palabras completas
-c : Sólo imprime el número de líneas coincidentes
--color : Resalta en color el patrón coincidente en las líneas
-n : Antecede cada línea coincidente con el número de línea del texto en el que se da la coincidencia
-o : Sólo imprime el patrón coincidente con la expresión regular
-R : Lee todos los archivos dentro de un directorio de manera recursiva
-v : Invierte el sentido de la coincidencia: imprime sólo las líneas no coincidentes
Si no se especifica al menos un archivo entonces se analizará el texto ingresado en la entrada estándar
more[opciones] [archivo] ...

Visualiza texto en pantalla dividido en páginas (permite sólo bajar la lectura)
La documentación de las opciones de esta herramienta pueden ser encontradas en more(1). Al utilizar more se pueden usar algunos
comandos de control sobre el texto mostrado, las mismas que a continuación se detallan:
Comandos:
h : Muestra la ayuda de la herramienta

SPACE : Avanza una página
ENTER : Avanza una línea
/patron : Busca patrón en la página
n : Encuentra la siguiente coincidencia de patrón de una búsqueda anterior
less[opciones] [archivo] ...

Visualiza texto en pantalla dividido en páginas (permite bajar y subir la lectura)
Opciones:
-N : Antecede cada línea con el número de línea
La documentación de otras opciones de esta herramienta pueden ser encontradas en less(1). Al utilizar less se pueden usar algunos
comandos de control sobre el texto mostrado, las mismas que a continuación se detallan:
Comandos:
h : Muestra la ayuda de la herramienta

SPACE : Avanza una página
ENTER : Avanza una línea
/patron : Busca patrón en la página
n : Encuentra la siguiente coincidencia de patrón de una búsqueda anterior
head [opciones] [archivo] ...

Imprime las primeras líneas de textos
Opciones:
-n [-]N : Imprime las N primeras líneas en vez de las 10 primeras. Si se especifica "-" imprime todo excepto las 10 últimas líneas
-# : Imprime las # primeras líneas en vez de las 10 primeras.
tail [opciones] [archivo] ...

Imprime las últimas líneas de textos
Opciones:
-n [+]N : Imprime las N últimas líneas en vez de las 10 últimas. Si se especifica "+" imprime desde la línea número N hasta el final
-# : Imprime las # últimas líneas en vez de las 10 primeras.
-f : Imprime las últimas líneas de forma dinámica mientras el texto va creciendo
OpenSourceCollege
Linux for SysAdmins
Página 38
Source Linux
wc [opciones] [archivo] ...

Contabiliza la cantidad de bytes, palabras y líneas de textos
Opciones:
-c : Imprime la cantidad de bytes

-w : Imprime la cantidad de palabras
-l : Imprime la cantidad de líneas
Si no se especifica al menos un archivo entonces se analizará el texto ingresado en la entrada estándar. En la ausencia de opciones
se imprime por defecto la cantidad de líneas, palabras y bytes.
cut [opciones] [archivo] ...

Imprime campos de un texto (cada uno separada por un caracter común)
Opciones:
-c LISTA : Selecciona sólo estos caracteres

-f LISTA : Seleccionar sólo estos campos (se requiere especificar un delimitador)
-d DELIM : Usa DELIM como delimitador de campos en lugar de TAB
LISTA es uno o más rangos (cada uno separado por comas) a usarse con los parámetros -c ó -f y que se pueden expresar como
sigue:
N Caracter/campo número N
N- Desde el caracter/campo número N en adelante
-N Desde el inicio hasta el caracter/campo número N
N-M Desde el caracter/campo número N hasta el caracter/campo número M
DELIM debe ser un único caracter que se identifique como delimitador entre los campos. Si no se especifica al menos un archivo
entonces se analizará el texto ingresado en la entrada estándar.
sort [opciones] [archivo] ...

Ordena las líneas de textos
Opciones:
-f : Ignora sensibilidad a mayúsculas en el texto a ordenar

-n : Ordenamiento numérico
-k POS : Realiza el ordenamiento en base al texto de la columna número POS
-t DELIM : Utiliza el caracter DELIM como delimitador de columnas
-r : Invierte el resultado de ordenamiento
-o FILE : Envía el resultado del ordenamiento al archivo FILE en lugar de mostrarlo por la salida estándar
DELIM debe ser un único caracter que se identifique como delimitador entre las columnas. Si no se especifica al menos un archivo
entonces se analizará el texto ingresado en la entrada estándar.
uniq [opciones] [archivo] ...

Reporta líneas repetidas de textos ordenados
Opciones:
-c : Antecede cada línea del resultado con la cantidad de coincidencias

-d : Imprime sólo líneas repetidas
-u : Imprime sólo líneas únicas (no repetidas)
-i : Ignora sensibilidad a mayúsculas en el texto a analizar
Si no se especifica al menos un archivo entonces se analizará el texto ingresado en la entrada estándar.
tr [opciones] <GRUPO1> [GRUPO2] ...

Reemplaza y elimina caracteres de textos de entrada estándar
Opciones:
OpenSourceCollege
Linux for SysAdmins
Página 39
Source Linux
-d : Elimina caracteres presentes en GRUPO1, no reemplaza
Esta herramienta siempre analiza el texto ingresado en la entrada estándar. En la ausencia del parámetro -d se encarga de
reemplazar del flujo de texto de la entrada estándar cada caracter del GRUPO1 con su correspondiente de la misma posición en
GRUPO2 uno a uno.
Cuando se usa de la mano con el parámetro -d el GRUPO2 se ignora, sólo se elimina del flujo de texto de la entrada estándar los
caracteres encontrados en GRUPO1
split [opciones] [archivo [prefijo]]

Divide un archivo en partes
Opciones:
-a N : Usa sufijos de longitud N

-d : Usa sufijos numéricos en lugar de alfabéticos
-b SIZE : Divide el archivo en partes de SIZE bytes cada uno
Esta herramienta produce como salida múltiples archivos producto de la división de archivo en varias partes, usando cada uno 'x'
como prefijo con una longitud de 2 caracteres como sufijo variable.
El valor SIZE que especifica el tamaño de cada parte resultante puede llevar sufijos como k (1024), m (1024*1024) o g
(1024*1024*1024).
sed [opciones] [archivo] ...

Editor de flujos de texto avanzado que permite filtrado y transformación
Opciones:
-n : Suprime la impresión automática del rango analizado

-i : Modifica el archivo original en lugar de imprimir en pantalla los cambios realizados
-r : Interpreta expresiones regulares extendidas en el SCRIPT
-e SCRIPT : Agrega SCRIPT a lista de comandos de sed a ser ejecutados
SCRIPT representa un comando de sed a ejecutarse conformado por un rango, acciones y opcionalmente parámetros de éstas. La
forma que tiene un SCRIPT es como sigue:
[rango]<acción>[parámetros]
rango permite limitar las líneas del texto a analizar -a través de una expresión- y por cada una de ellas se ejecuta una acción
complementada opcionalmente con uno o más parámetros.
El rango puede ser expresado como direcciones de las cuales cada una puede tener la forma siguiente:
/regexp/ Coincide con la expresión regular encerrada entre / /

N Coincide con la línea número N
El rango puede ser delimitado como intervalos marcando un inicio y fin a través de dos direcciones delimitadas por coma. Por ejemplo
el siguiente rango expresado por las direcciones /regexp/ y M permite imprimir las líneas que coinciden desde la expresión regular
regexp hasta la línea número M:
/regexp/,M
Al usar intervalos como rangos se puede especificar la segunda dirección como una expresión numérica de adición usando +M, que
indica que debe imprimirse M líneas después de la coincidencia del primer intervalo.
La acción que forma parte de un SCRIPT puede tener la forma siguiente:
p Imprime la línea coincidente

d Elimina la línea coincidente
i Inserta una línea encima de la coincidente, conteniendo el texto especificado como parámetro
a Agrega una línea debajo de la coincidente, conteniendo el texto especificado como parámetro
s Busca y reemplaza
Ejemplo 12:
a) Mostrar la salida enumerada del archivo /etc/inittab y mostrar sólo los comentarios (aquellas que empiecen con #):
OpenSourceCollege
Linux for SysAdmins
Página 40
Source Linux
$ cat -n /etc/inittab | grep --color '^#'
b) Mostrar la lista de los últimos 5 usuarios del sistema creados y sus directorios personales:
$ cut -d : -f 1,6 /etc/passwd | tail -5
c) Crear una copia del kernel (archivo de nombre vmlinuz* en /boot) y partirlo en pedazos de 100 KB cada uno, usando como sufijo la
palabra 'kernel-' y prefijos numéricos:
$ cp /boot/vmlinuz* .
$ split -d -b 100k vmlinuz* kernel-
d) A todos los usuarios del sistema que tengan /bin/bash como Shell, agregarles el caracter # al inicio de su línea correspondiente en el
archivo /etc/passwd:
$ sed -e "/bash/s/^/#/" /etc/passwd
e) Ordenar de forma descendente la lista de usuarios del sistema en base a su UID (3ra columna del archivo /etc/passwd) y mostrar
luego sólo el nombre de usuario convertido a mayúsculas con su respectivo UID:
$ sort -r -n -k 3 -t : /etc/passwd | cut -d : -f 1,3 | tr a-z A-Z
OpenSourceCollege
Linux for SysAdmins
Página 41
Source Linux
2.5. Administración de procesos
Introducción
La definición de proceso la podemos resumir simplemente en una instancia de una aplicación en ejecución. Cada uno de los procesos
se ejecuta de manera independiente de otros en el sistema.
Como ya se sabe, Linux, es un sistema operativo multitarea, permitiendo que cada proceso pueda correr sin interrupción de otro de
manera simultánea.
Normalmente en el ámbito de los procesos encontraremos cierta terminología como estado, proceso hijo, proceso padre, PID, y otros
más que corresponden a los atributos de un proceso que estudiaremos a continuación:
Atributos
Este es un listado de los atributos más importantes de los procesos en UNIX:
Atributo Descripción
PID Número ID del proceso
Nice Valor nice (prioridad)
Tiempo Tiempo de ejecución acumulado
Usuario Usuario propietario del proceso
Estado Estado en el que se encuentra el proceso
Es importante tener en cuenta que los procesos pueden generar otros procesos, estos últimos llamados procesos hijos y los que lo
generaron son llamados procesos padres.
Todos los procesos tienen siempre un padre a excepción del proceso init, cuyo PID siempre es 1
Algunos de los estados más comunes de los procesos se muestra debajo:
• Corriendo, R (en ejecución) : Proceso en ejecución o listo para ejecutarse

• Interrumpible, S : Proceso en estado bloqueado, a la espera de una señal o evento de otro proceso
• Ininterrumpible, D : Proceso en estado bloqueado, espera condición de hardware, no puede manejar señales.
• Detenido, T : Proceso detenido, normalmente por una señal de control
• Zombie, Z : Proceso que ya terminó, pero su padre aún no ha recogido su estado de salida
Las herramientas disponibles para listar y monitorear los procesos del sistema se detallan a continuación:
ps [opciones]
Imprime un listado actual y estático de procesos
Opciones:
-e : Lista todos los procesos

-f : Muestra información detallada de los procesos
-l : Muestra columnas extra (incluye valor de nice)
-u : Muestra columnas extra (incluye el usuario propietario del proceso)
-w : Muestra la salida con más amplitud cuando no cabe en pantalla
pstree [opciones]
Muestra un árbol de procesos
Opciones:
-a : Muestra los parámetros de los procesos

-p : Muestra el PID de cada proceso
-u : Muestra el usuario propietario del proceso
-l : Muestra la salida con más amplitud cuando no cabe en pantalla
pidof <programa> [programa] ...

Muestra el PID de programas en ejecución
top
Muestra interactivamente un listado de procesos en tiempo real
Esta herramienta de manera similar a los comandos less o more, aceptan comandos de control que modifican la forma de
funcionamiento o modo en el que se muestra la información.
OpenSourceCollege
Linux for SysAdmins
Página 42
Source Linux
Algunos de estos comandos son:
h : Muestra el menú de ayuda

q : Sale de la aplicación
<,> : Cambia la columna de ordenamiento
R : Invierte el ordenamiento
F : Da a elegir la columna de ordenamiento
k : Envia una señal a un proceso
r : Cambia el valor nice de un proceso
s : Cambia el tiempo de refresco de la vista de procesos (por defecto 3 segundos)
Señales
Las señales son mensajes enviados hacia los procesos a modo de órdenes con el propósito que realicen alguna operación. Estas
señales son enviadas usando el comando kill
Algunas de las señales más comunes son:
Nombre de la señal ID Descripción

SIGHUP 1 Fuerza a un proceso a releer su archivo de configuración
SIGINT 2 Interrumpe la ejecución de un proceso (^C)
SIGKILL 9 Termina inmediatamente un proceso
SIGTERM 15 Termina normalmente un proceso. Cierra archivos y/o conexiones abiertas antes de terminar
Las herramientas disponibles para enviar señales a los procesos son las siguientes:
kill <-señal> <pid> [pid] ...

Envía una señal a procesos
Donde señal es un valor numérico tal como 1, 2, 9, 15 (según la tabla antes mencionada).
killall [-señal] [opciones] <programa> [programa] ...

Envía una señal a procesos por su nombre
Opciones:
-I : Ignora la sensibilidad a mayúsculas en los nombres de programas

-i : Pide confirmación antes de enviar la señal a cada proceso
-r : Interpreta el nombre del programa como una expresión regular
-u USER : Envía la señal sólo a todos los procesos del usuario USER
Donde señal es un valor numérico tal como 1, 2, 9, 15 (según la tabla antes mencionada).
Prioridades
Los procesos tienen la particularidad de poseer niveles de prioridad, los mismos que son útiles cuando múltiples procesos están
demandando más recursos de los que el CPU puede ofrecer. Es así que un proceso con mayor prioridad obtiene mayor tiempo de
atención del procesador.
La prioridad de un proceso se manifiesta a través de un atributo llamado nice, el mismo que se puede variar dependiendo de los
requerimientos de un usuario o administrador.
Un valor nice de -20 representa la máxima prioridad, mientras que 19 la más baja prioridad. El valor nice por defecto de todo proceso
recién creado es 0. El usuario administrador (root) es el único capaz de asignar valores nice negativos (más alta prioridad), así como
también de cambiar el valor nice de un proceso en ejecución a uno menor.
Las herramientas disponibles para manipular los valores nice de los procesos son las siguientes:
nice [opciones] <programa [parametros] ...>

Inicia un proceso con un valor nice específico
Opciones:
OpenSourceCollege
Linux for SysAdmins
Página 43
Source Linux
-n N : Aplica N como valor nice del proceso a ejecutar
renice [opciones] <programa [parametros] ...>

Altera el valor nice de procesos en ejecución
Opciones:
-n N : Aplica N como nuevo valor nice del proceso en ejecución

-p PID : Altera el valor nice a los procesos indicados en PID
-u USER : Altera el valor nice a los procesos cuyos propietarios son indicados en USER
Procesos en primer y segundo plano

Los procesos que son invocados desde una terminal de comandos o bien culminan su ejecución en un breve instante, o bien se
mantienen activos. Un proceso que se mantiene activo en nuestra shell se le conoce como un trabajo y puede mantenerse en
ejecución en primer plano o segundo plano.
Un proceso en primer plano mantiene ocupada nuestra shell hasta que culmine su ejecución, pero en cambio un proceso en segundo
plano se ejecuta sin mantener nuestra shell ocupada pudiendo así realizar otras tareas mientras el proceso continúa en su ejecución.
La forma de invocar un proceso en segundo plano se logra agregando el símbolo & al final de la línea de comandos.
Un proceso invocado en primer plano desde la Shell puede ser detenido presionando ^Z, lo que automáticamente nos deja la shell libre
para seguir trabajando en ella.
Los comandos de shell fg, bg y jobs nos permiten tener control sobre los procesos en primer y segundo plano. La forma de uso se
muestra a continuación:
fg [%JobID]
Ejecuta un trabajo en primer plano
Si se ejecuta sin parámetros, es decir sin especificar el JobID, vuelve a ejecutar en primer plano el trabajo más reciente que haya sido
suspendido
bg [%JobID]
Ejecuta un trabajo en segundo plano
Si se ejecuta sin parámetros, es decir sin especificar el JobID, vuelve a ejecutar en segundo plano el trabajo más reciente que haya
sido suspendido
jobs [opciones] [%JobID]

Muestra el listado de trabajos
Opciones:
-l : Incluye el PID de cada proceso en el listado de trabajos
El número de cada uno de los Jobs, conocido como JobID, se muestra en la lista encerrado entre corchetes [ ]
Ejemplo 13:
a) Mostrar un listado detallado actual de todos los procesos en ejecución:
$ ps -efl
b) Mostrar el listado de procesos en vista de árbol, visualizando el PID de cada uno de ellos:
$ pstree -p
c) Averiguar el PID de todos los procesos de la shell Bash en ejecución:
$ pidof bash
d) Invocar con la más baja prioridad la búsqueda de archivos cuya fecha de modificación sea menor a 3 días en nuestro directorio
personal:
OpenSourceCollege
Linux for SysAdmins
Página 44
Source Linux
$ nice -n 19 find ~ -mtime -3
2.6. El editor de archivos VIM

VIM es un editor de texto que nació como una versión mejorada del clásico editor VI, presente en todos los sistemas UNIX. Se
caracteriza por ser muy flexible, funcional, personalizable y potente, tanto para el uso diario en edición sencilla de archivos como
también hasta ser capaz de trabajar como IDE para programadores de distintos lenguajes.
Al igual que su antecesor VI, fue desarrollado inicialmente sobre un entorno de modo texto únicamente -razón por la cual la mayoría de
sus funcionalidades se aprovechan a través del uso del teclado únicamente- pero en la actualidad también existen adaptaciones de
VIM en versiones gráficas como gvim.
VIM tiene la particularidad de poder trabajar bajo distintos modos, cada uno de ellos enfocado en ofrecer funcionalidades para fines
distintos.
Modos de trabajo
Como se comentó, VIM es en editor modal, esto quiere decir que puede trabajar en distintos modos cada uno de ellos enfocado en
propósitos y formas de uso diferentes.
Algunos de los modos más usados a menudo son:
• Modo normal
• Modo inserción
• Modo visual
• Modo de línea de comandos
Por defecto VIM inicia en el modo normal, y es a este modo al cual se regresa cada vez que presionamos la tecla Esc. Es así que para
salir del modo inserción o modo visual presionaremos la tecla Esc quedando finalmente en el modo normal.
Si no estamos seguros en qué modo nos encontramos actualmente, o simplemente deseamos de regresar al modo normal debemos
presionar Esc dos veces.
Modo normal
Este modo permite trabajar con múltiples comandos de combinaciones de teclas para realizar funciones variadas tales como
desplazamiento, copiado, cortado y pegado, eliminar, reemplazar y otras operaciones de formateo de texto en general.
A continuación se muestra una tabla con algunos de los comandos más comunes en este modo:
Comandos de desplazamiento
h Mover el cursor una posición a la izquierda
l Mover el cursor una posición a la derecha
k Mover el cursor una posición hacia arriba
j Mover el cursor una posición hacia abajo
0 Mover el cursor al inicio de la línea
$ Mover el cursor al fin de la línea
e Mover el cursor al fin de la siguiente palabra
w Mover el cursor al inicio de la siguiente palabra
b Mover el cursor al inicio de la palabra anterior
ge Mover el cursor al fin de la palabra anterior
E Mover el cursor al fin de la siguiente palabra ignorando puntuaciones
W Mover el cursor al inicio de la siguiente palabra ignorando puntuaciones
B Mover el cursor al inicio de la palabra anterior ignorando puntuaciones
H Mover el cursor al inicio de la pantalla, en la primera posición
M Mover el cursor a la mitad de la pantalla, en la primera posición
L Mover el cursor al final de la pantalla, en la primera posición
G Ir a línea ... (por defecto va a la última línea)
^d Mueve el cursor media página hacia abajo
OpenSourceCollege
Linux for SysAdmins
Página 45
Source Linux
û Mueve el cursor media página hacia arriba
Importante:
• Todos estos comandos aceptan un modificador de repetición antecediendo un número a cada una de las combinaciones de
teclas a usar. Así, si nosotros podemos ejecutar el comando 10k que significa que se repetirá 10 veces el comando k (subir
10 líneas), o 20e que repetirá 20 veces el comando e (avanzar hacia el último caracter de la palabra N° 20 que viene a
continuación). A continuación se resumen unos ejemplos importantes que merecen ser resaltados en su explicación:
132G : Ir a la línea número 132

40^d : Avanza 40 líneas hacia abajo cada vez que se presione sólo ^d desde la 2da. vez en adelante
50û : Avanza 50 líneas hacia arriba cada vez que se presione sólo ^d desde la 2da. vez en adelante
Comandos de edición
i Inserta texto en la posición del cursor (Cambia el VIM al modo inserción)
I Inserta texto al inicio de la línea (Cambia el VIM al modo inserción)
a Inserta texto una posición delante del cursor (Cambia el VIM al modo inserción)
A Inserta texto al final de la línea (Cambia el VIM al modo inserción)
o Inserta texto creando una nueva línea por debajo de la actual (Cambia el VIM al modo inserción)
O Inserta texto creando una nueva línea por encima de la actual (Cambia el VIM al modo inserción)
cc Elimina una línea entera e inserta (Cambia el VIM al modo inserción)
dd Elimina una línea entera
yy Copia una línea entera
x Elimina un caracter en la posición del cursor
X Elimina un caracter hacia la izquierda del cursor
p Pega el texto -previamente cortado o copiado- una posición a la derecha del cursor
P Pega el texto -previamente cortado o copiado- una posición a la izquierda del cursor
r Reemplaza el caracter actual con el nuevo que se escriba
R Reemplaza texto desde la posición del cursor en adelante (Presionar Esc una vez terminado)
â Incrementa el número debajo del cursor
^x Decrementa el número debajo del cursor
u Deshacer
^r Rehacer
. Repite el último comando de edición de texto ejecutado
~ Convierte el caracter actual de mayúsculas a minúsculas o viceversa
gu Convertir texto a minúsculas (requiere combinación con movimientos o entrar al modo visual)
gU Convertir texto a mayúsculas (requiere combinación con movimientos o entrar al modo visual)
n Encuentra la siguiente coincidencia de un patrón previamente buscado con / o ?
N Encuentra la coincidencia previa de un patrón previamente buscado con / o ?
ZZ Salir del editor guardando los cambios
ZQ Salir del editor sin guardar los cambios
Importante:
• Muchos de estos comandos aceptan un modificador de repetición antecediendo un número a cada una de las combinaciones
OpenSourceCollege
Linux for SysAdmins
Página 46
Source Linux
de teclas a usar. Así, si nosotros podemos ejecutar el comando 8oLinux que significa que se repetirá 8 veces el comando o
(insertando la palabra Linux por encima de la línea actual), o 10dd que repetirá 10 veces el comando dd (eliminará las 10
líneas que vienen debajo de la actual).
• Es posible combinar comandos de edición con comandos de movimientos para obtener operaciones de edición más
específicas, tal como se muestra en los siguientes ejemplos:
d$ : Eliminar el texto comprendido desde la posición actual hasta el fin de línea

y0 : Copiar el texto comprendido desde la posición actual hasta el inicio de línea
cG : Eliminar el texto comprendido desde la posición actual hasta el fin de línea y luego empezar a insertar
gue : Convertir a minúsculas el texto comprendido desde la posición actual hasta el fin de la siguiente palabra
gU$ : Convertir a minúsculas el texto comprendido desde la posición actual hasta el fin de línea
y45G : Copiar el texto comprendido desde la línea actual hasta la número 30
Modo inserción
Este modo es el que permite al usuario modificar el contenido del texto por cada caracter que tipee en el teclado, tal como lo hace
cualquier editor de textos común por defecto.
Para ingresar a este modo sólo es necesario usar algunos de los comandos de edición como i, I, a o A. Una vez que terminemos de
editar el texto de acuerdo a nuestras necesidades ya podemos volver al modo normal presionando la tecla Esc.
Si la opción showmode del VIM está activada (comportamiento por defecto) entonces nosotros podemos saber que estamos en el
modo inserción al notar el texto --INSERTAR-- (o --INSERT-- en inglés) en la esquina inferior izquierda de la pantalla.
Modo visual
Este es un modo intermediario cuando se usa como parte de una operación posterior de edición. Este modo permite seleccionar texto a
nuestra elección para luego aplicar sobre él una operación tal como copiar, reemplazar, cortar, convertir a mayúsculas, etc.
Para ello tenemos tres formas distintas de empezar la selección de texto:
v : Selecciona texto por caracter

V : Selecciona texto por línea
^v : Selecciona texto por áreas rectangulares
Al iniciar una selección visual podemos modificar el área de nuestro interés usando cualquiera de los comandos de movimientos ya
conocidos (0, $, h, b, e, G, etc).
Una vez que ya terminamos de seleccionar el área que nos interesa podemos ejecutar sobre dicho texto una operación de edición tal
como x o d (cortar), y (copiar), c (eliminar e insertar), etc.
Modo de línea de comandos

Este modo permite ingresar una línea de texto entera como un comando para el VIM. Estos comandos se escriben en la esquina
inferior izquierda de la pantalla a través de los operadores /, ?, : y ! más un texto que forme parte del comando y finalmente la tecla
Enter
Los comandos invocados con el operador / y ? se usan para buscar patrones de texto de acuerdo a como se resume debajo:
Búsqueda de texto
/patrón Busca hacia abajo patrón en el texto
?patrón Busca hacia arriba patrón en el texto
Los comandos invocados con el operador : generalmente permiten configurar preferencias del funcionamiento del editor VIM, realizar
operaciones de edición, u otros acorde a la tabla de comandos que debajo se resume:
Comandos de edición
:r FILE Inserta debajo de la línea actual el contenido del archivo FILE
:r! COMANDO Inserta debajo de la línea actual la salida del comando de Shell COMANDO
:w Guardar los cambios en el archivo
:w FILE Guardar como ... en el archivo FILE
:q Salir del editor
OpenSourceCollege
Linux for SysAdmins
Página 47
Source Linux
:q! Salir del editor sin guardar los cambios
:wq Guardar los cambios y salir
Opciones del VIM
:set background=cadena Cambia la combinación de colores apropiada si el fondo es oscuro (cadena = dark) o si es claro
:set bg=cadena (cadena = light). Requiere la opción syntax habilitada
:set hlsearch
Resalta todas las coincidencias de patrones de texto previamente buscados con / o ?
:set hls
:set nohlsearch
Desactiva la opción hlsearch
:set nohls
:set ignorecase
Ignora la sensibilidad a mayúsculas cuando se busca texto con / o ?
:set ic
:set noignorecase
Desactiva la opción ignorecase
:set noic
:set incsearch
Resalta el texto buscado mientras lo escribimos usando / o ?
:set is
:set noincsearch
Desactiva la opción incsearch
:set nois
:set number
:set nu Muestra los números de línea en la parte izquierda de la pantalla
:set nonumber
Desactiva la opción number
:set nonu
:set ruler
:set ru Muestra el número de línea y columna del cursor en la esquina inferior derecha de la pantalla
:set noruler
Desactiva la opción ruler
:set noru
:set showmode
:set smd Muestra el modo actual de funcionamiento del VIM en la esquina inferior izquierda de la pantalla
:set noshowmode
Desactiva la opción showmode
:set nosmd
:syntax on Activa el coloreado de texto según la sintaxis reconocida del contenido
:syntax off Desactiva la opción syntax, apaga el coloreado
Preferencias del VIM en ~/.vimrc

El editor VIM posee la capacidad de personalizar su funcionamiento a través de algunas opciones vistas líneas arriba, sin embargo
normalmente éstas se pierden al cerrar el editor.
Sin embargo es posible aplicar de forma permanente estas opciones de configuración ingresándolas en el archivo ~/.vimrc una a una
por cada línea, como se muestra debajo a modo de ejemplo:
set number
set ruler
set incsearch
syntax on
set background=dark
Nótese que no es necesario incluir el caracter : al inicio.
OpenSourceCollege
Linux for SysAdmins
Página 48
Source Linux
1. Usando sólo comandos de Shell estudiados hasta el momento y a través de una única línea de comandos secuenciales
otener la siguiente información del procesador:
- vendor_id
- cpu MHz
- model name
- cache size
La información debe ser guardada en el archivo /tmp/lab2 y no debe contener líneas repetidas, y sólo debe mostrar la
información requerida mas no la descripción, es decir omitir las palabras vendor_id, cpu MHz, model name y cache size.
2. Listar los procesos del usuario root únicamente y ordenarlo de forma descendente según el valor de su PID, agregando el
resultado convertido todo a mayúsculas al final del archivo /tmp/lab2.
3. Crear un enlace duro /tmp/lab2.1 al archivo /tmp/lab2. Agregar al inicio de cada línea del archivo /tmp/lab2.1 (implica modificar
el archivo original) la hora en formato HH:MM. Analizar finalmente el contenido de los archivos /tmp/lab2 y /tmp/lab2.1
4. Crear un archivo empaquetado y comprimido de nombre lab2.tar.gz que contenga los archivos /tmp/lab2 y /tmp/lab2.1
quedando estos dos intactos. El archivo lab2.tar.gz debe ser creado en el directorio personal del usuario.
5. Como un usuario sin privilegios (distinto de root) enviar la señal KILL al proceso init y guardar la salida de de dicho
comando en el archivo /tmp/lab2 (al final del mismo), luego agregar al final del mismo archivo el código de error retornado por
el comando anterior (aquel que enviaba la señal KILL).
OpenSourceCollege
Linux for SysAdmins
Página 49
Source Linux
2.7.1 Solución del laboratorio N° 2
1. Usando sólo comandos de Shell estudiados hasta el momento y a través de una única línea de comandos secuenciales
obtener la siguiente información del procesador:
- vendor_id
- cpu MHz
- model name
- cache size
La información debe ser guardada en el archivo /tmp/lab2 y no debe contener líneas repetidas, y sólo debe mostrar la
información requerida mas no la descripción, es decir omitir las palabras vendor_id, cpu MHz, model name y cache size.
+ Se puede realizar de una de dos formas. Veamos la primera:
$ grep -E "(vendor_id|cpu MHz|model name|cache size)" /proc/cpuinfo | cut -d : -f 2 \

> | sort | uniq > /tmp/lab2
+ Veamos la segunda forma:
$ grep -e vendor_id -e "cpu MHz" -e "model name" -e "cache size" /proc/cpuinfo \

> | cut -d : -f 2 | sort | uniq > /tmp/lab2
2. Listar los procesos del usuario root únicamente y ordenarlo de forma descendente según el valor de su PID, agregando el
resultado convertido todo a mayúsculas al final del archivo /tmp/lab2.
+ Puede ser resuelto desde una secuencia de comandos como la siguiente:
$ ps -ef | sort -r -n -k 2 | tr a-z A-Z >> /tmp/lab2
3. Crear un enlace duro /tmp/lab2.1 al archivo /tmp/lab2. Agregar al inicio de cada línea del archivo /tmp/lab2.1 (implica modificar
el archivo original) la hora en formato HH:MM. Analizar finalmente el contenido de los archivos /tmp/lab2 y /tmp/lab2.1
+ Creamos primero el enlace duro:
$ ln /tmp/lab2 /tmp/lab2.1
+ Ahora declaramos una variable con el formato de hora requerido:
$ HORA=$(date +%H:%M:%S)
+ Modificamos el archivo según lo requerido:
$ sed -i -e "s/^/$HORA /" /tmp/lab2.1
+ Finalmente comparamos ambos archivos:
$ ls -i /tmp/lab2 /tmp/lab2.1
$ cat /tmp/lab2
$ cat /tmp/lab2.1
4. Crear un archivo empaquetado y comprimido de nombre lab2.tar.gz que contenga los archivos /tmp/lab2 y /tmp/lab2.1
quedando estos dos intactos. El archivo lab2.tar.gz debe ser creado en el directorio personal del usuario.
+ Una sentencia nada más es necesaria:
$ tar -czf lab2.tar.gz /tmp/lab2 /tmp/lab2.1
5. Como un usuario sin privilegios (distinto de root) enviar la señal KILL al proceso init y guardar la salida de de dicho
comando en el archivo /tmp/lab2 (al final del mismo), luego agregar al final del mismo archivo el código de error retornado por
el comando anterior (aquel que enviaba la señal KILL).
+ Intentamos matar el proceso (señal KILL) init pero no podremos hacerlo, agregando la salida de error hacia un archivo:
$ kill -9 $(pidof init) 2>> /tmp/lab2
+ Ahora agregamos el código de error retornado:
$ echo $? >> /tmp/lab2
OpenSourceCollege
Linux for SysAdmins
Página 50
Source Linux
OpenSourceCollege
Linux for SysAdmins
Página 51
Source Linux
Unidad 3: Administración de sistemas de archivos
3.1. Objetivos
✔ Comprender los tipos de discos disponibles, sus características y límites de particionamiento.

✔ Conocer la nomenclatura de los discos y particiones en Linux.
✔ Aprender a manejar las herramientas de creación de sistemas de archivos EXT3, FAT32 y gestión de SWAP.
✔ Comprender la definición de montaje en Linux y cómo usarlo en la práctica para todos los dispositivos.
✔ Estudiar la sintaxis del archivo /etc/fstab para configurar en él los dispositivos y opciones de montaje.
3.2. Particionamiento simple

Conceptos básicos de IDE y SCSI
ATA/IDE es una interfaz estándar diseñada originalmente para la conexión de discos duros a equipos de computo. La primera variante
del estándar ATA se caracterizaba por usar conexiones paralelas (Parallel Ata, PATA) admitiendo 2 dispositivos por bus (maestro y
esclavo) y con la limitación que mientras uno de los dispositivos conectados al bus estaba en uso el otro no podía ser usado.
Posteriormente como una variante remodelada del ATA tradicional aparece el Serial ATA (SATA) que admite velocidades superiores de
transmisión, ancho de banda superior, mayor longitud de cable, topología punto a punto y sobre todo caracterizado por transmitir la
información a través de vínculos seriales, sin sufrir la limitación del ATA/IDE de poder utilizar sólo 1 dispositivo por canal.
De manera análoga, el estándar SCSI que en sus inicios apareció con una naturaleza de comunicación paralela, se caracterizó
siempre por tener mejores prestaciones y rendimientos que ATA/IDE. Igualmente con el paso del tiempo el estándar SCSI evolucionó a
una variante de comunicación serial (SAS, FC-AL).
En los sistemas operativos Linux, sólo se mantiene dos distinciones de dispositivos de almacenamiento: dispositivos IDE y dispositivos
de almacenamiento SCSI. Esto no quiere decir que discos SATA, SAS o Storage de Fibra no puedan ser accedidos desde un sistema
Linux, sino que sólo se les distingue a todos ellos entre una de esas dos categorías.
Es así que los discos ATA/IDE de conector paralelo son reconocidos a modo general como dispositivos IDE, mientras que los discos
SCSI, SATA, SAS y otros dispositivos que sigan el estándar SCSI son reconocidos simplemente como dispositivos SCSI en Linux.
A este último grupo hay que agregar también todos aquellos dispositivos de almacenamiento masivo USB, los cuales son emulados
como SCSI por Linux. Por lo tanto cuando hagamos referencia a una memoria o un disco duro externo USB también los
interpretaremos como un dispositivo SCSI más.
Nomenclatura de dispositivos
La forma en que Linux nombra los dispositivos de almacenamiento como unidades floppy, cdrom, discos duros IDE o SCSI difiere bajo
ciertas reglas comunes que se han de mencionar como ejemplos en la siguiente tabla:
Dispositivo Descripción
/dev/fd0 Primera unidad floppy
/dev/fd1 Segunda unidad floppy
/dev/hda Dispositivo maestro en el primer controlador IDE (primario)
/dev/hdb Dispositivo esclavo en el primer controlador IDE (primario)
/dev/hdc Dispositivo maestro en el segundo controlador IDE (secundario)
/dev/hdd Dispositivo esclavo en el segundo controlador IDE (secundario)
/dev/sda Primer dispositivo SCSI
/dev/sdb Segundo dispositivo SCSI
/dev/sdc Tercer dispositivo SCSI
/dev/hdb2 Partición N° 2 del dispositivo esclavo en el primer controlador IDE
/dev/hdc5 Partición N° 5 del dispositivo maestro en el segundo controlador IDE
/dev/sdb1 Partición N° 1 del segundo dispositivo SCSI
Observaciones:
• Los dispositivos SCSI se van nombrando de acuerdo al orden en el que se conectan al sistema. Si por ejemplo conectamos
una memoria USB que es reconocida como /dev/sdb y luego un disco duro externo reconocido como /dev/sdc, al
OpenSourceCollege
Linux for SysAdmins
Página 52
Source Linux
desconectarlos y conectarnos nuevamente en el orden inverso la memoria USB será /dev/sdc y el disco duro /dev/sdb.
Particiones de disco
Una partición no es más que una división de un dispositivo de almacenamiento físico; esta división posee su propio sistema de
archivos. Comúnmente se crean particiones en los discos duros para tener la posibilidad de instalar más de un sistema operativo, dado
que cada uno por lo general utiliza siempre una la cual no es compartida. Sin embargo existen algunos sistemas operativos (por
ejemplo Linux) que requieren más de una partición para su instalación (al menos 1 para la swap y 1 para la raíz).
Tipos de particiones
Existen tres tipos de particiones que pueden ser creadas en un disco:
• Partición primaria, es una partición básica o cruda, y sólo puede existir 4 de éstas en un disco o 3 primarias y 1 extendida.
Este tipo de partición depende de la existencia de una tabla de particiones alojada en el MBR y sí es capaz de crear un
sistema de archivos en este tipo de partición.
• Partición extendida, es una partición que actúa como una primaria para contener en su interior particiones lógicas. Se creó
con la finalidad de acabar con la limitación de 4 particiones (primarias) por disco. Puede existir sólo una partición extendida
por disco, sólo puede almacenar particiones lógicas y no es posible crear sistemas de archivos en las particiones extendidas.
• Partición lógica, es una partición que forma parte de una partición extendida, preparada para crear en él algún sistema de
archivos para el almacenamiento de datos.
Tabla de particiones
La tabla de particiones es una estructura de datos de 64-bytes que provee información básica al sistema operativo de cómo está
dividido el disco en particiones primarias.
Existen distintos tipos de tablas de particiones cada una orientada a ser usada en distintos sistemas y arquitecturas, tales como msdos,
irix, sun, s390, amiga, bsd, gpt, entre otras. Sin embargo para nuestro escenario común trabajaremos con tablas de tipo msdos, que es
la que entienden todos los sistemas operativos de PC.
Identificador de partición
Un identificador de partición es una pequeña etiqueta asignada a una partición que permite a un sistema operativo saber si puede
leerla o no (entender su contenido).
Existen varios identificadores tales como 7 (HPFS/NTFS), b (W95 FAT32), 82 (Linux swap), 83 (Linux), 8e (Linux LVM), los cuales son
asignados en el momento de creación de una partición.
Sin embargo estos identificadores no deben confundirse con los sistemas de archivos, pues se puede tener por ejemplo una partición
con un ID 83 (Linux) y contener un sistema de archivos tal como ext3, reiserfs, xfs u otros.
Sistema de archivos
Un sistema de archivos es el método utilizado por un sistema operativo para almacenar y organizar ficheros así como la información
que éstos contienen para lograr que sea fácil encontrarlos.
Algunas de las funciones que tiene un sistema de archivos son:
• Reglas de nomenclatura de ficheros y representación de rutas (PATH)

• Control de seguridad a través de permisos
• Mecanismos de control de fragmentación
• Soporte de journaling
• Límites de uso en disco (cuotas)
Existen diversos sistemas de archivos, algunos diseñados a trabajar directamente con dispositivos de almacenamiento (discos duros,
memorias USB, CDROM/CDRW, u otros) así como también otros para trabajar como clientes accediendo a otro sistema en red.
La siguiente tabla resume información de algunos de los sistemas de archivos más comunes:
Sistema de archivos Descripción

Creado por Microsoft y usado generalmente para sus sistemas operativos MS-DOS, Windows 95, Windows
98 y Windows ME. Actualmente soportado por casi todos los sistemas operativos y usado por defecto en
FAT32 gran número de dispositivos de almacenamiento (memorias USB, cámaras digitales, celulares, discos
externos, etc).
Este sistema de archivos no soporta seguridad a través de control de permisos de usuario.
Creado por Microsoft demanera exclusiva para Windows NT y extendido a las versiones superiores de este
sistema operativo como Windows 2000, Windows XP, Windows 2003, Windows 2008, Windows Vista y
Windows 7.
NTFS
Fue creado tomando como base a HPFS de IBM (usado para OS/2) y con un diseño inicial que tiene como
principal objetivo la robustez, seguridad (soporta control de permisos), compresión y cifrado de datos, entre
otros.
OpenSourceCollege
Linux for SysAdmins
Página 53
Source Linux
Sistema de archivos que se creó como evolución de ext2, que a diferencia de este último ya soporta
journaling (registro por diario). No es el sistema de archivos más eficiente y escalable comparado con otros
ext3 (ReiserFS, XFS, JFS) pero es el que exige un menor consumo de CPU, y se le considera ser el más seguro
por ser conocido y probado durante mayor tiempo.
Sistema de archivos creado como evolución de ext3, con características adicionales añadidas y de mejor
ext4
rendimiento que su predecesor.
Sistema de archivos creado por la empresa Namesys, cuyo desarrollo se ha visto interrumpido tras
problemas judiciales que enfrenta su creador Hans Reiser por cargos de asesinato.
ReiserFS
Se caracteriza por soportar journaling y ofrecer un mejor rendimiento que ext2 y ext3 para archivos menores
a 4 KB, por lo que se recomienda su uso para servicios de correo, news o caché HTTP.
Sistema de archivos creado por Sillicon Graphics para su sistema operativo IRIX. Se caracteriza por tener
XFS
soporte de journaling, un alto rendimiento para archivos y sistemas de archivos de gran tamaño.
Sistema de archivos creado por IBM para su sistema operativo AIX y liberado bajo la licencia GNU GPL. Se
JFS caracteriza por tener soporte de journaling, un alto rendimiento para archivos y sistemas de archivos de gran
tamaño.
Normal publicada en el año 1986 como un estándar ISO que define el formato para el almacenamiento de
ISO 9660 archivos en discos compactos. El objetivo es que los medios escritos bajo este formato sean entendibles por
cualquier sistema operativo tal como Windows, Linux, Mac OS, UNIX y otros.
Sistema de archivos con estándar ISO 9660 que fue desarrollado por Adaptec para utilizar las grabadoras de
CD/DVD como dispositivos de almacenamiento lógico. Esto permite que se pueda realizar operaciones de
UDF
lectura, escritura o modificación de datos en un disco compacto reescribible como si se tratase de un disco
duro.
Protocolo de nivel de aplicación que se usa como sistema de archivos distribuido en red. Creado
NFS originalmente por Sun Microsystems, este protocolo (llamado comúnmente sólo sistema de archivos en la
práctica) se usa en gran cantidad de sistemas UNIX y Linux, por lo general para compartición de datos.
Protocolo de nivel de aplicación que permite la compartición de archivos e impresoras en red. Creado
originalmente por IBM, este protocolo se convirtió en la base de las redes Microsoft.
SMB
El protocolo SMB fue modificado inicialmente por Microsoft agregándole características propias que difieren
del SMB original.
Protocolo de nivel de aplicación que surge en 1998 como producto de una serie de modificaciones mayores
CIFS por parte de Microsoft al protocolo SMB para agregarle características adicionales como enlaces simbólicos,
enlaces duros y tamaños de archivos mayores.
Observaciones:
• Cada vez que hacemos mención a un dispositivo como /dev/sda o /dev/hdb nos estamos refiriendo al disco completo, mientras
que al hacer referencia al mismo dispositivo con un número al final como /dev/sda3 o /dev/hdb2 nos estaremos refiriendo a
una de las particiones de dicho disco.
Sin embargo esta numeración al final de los dispositivos no existe para unidades de CDROM o CDRW, dado que éstos no
son capaces de almacenar particiones.
• Los dispositivos SCSI permiten crear sólo un máximo de 15 particiones (considerando 3 primarias, 1 extendida, y 11 lógicas),
mientras que los dispositivos IDE permiten un máximo de 63 particiones (considerando 3 primarias, 1 extendida, y 59
lógicas).
Creación de particiones
Desde la línea de comandos existen dos conocidas herramientas de administración de la tabla de particiones: parted y fdisk. Nos
centraremos en la segunda para crear y eliminar particiones.
La herramienta fdisk debe ser usada con un dispositivo que haga referencia a un disco entero (/dev/sda, /dev/hdb, etc) y no hacia una
partición (/dev/sda1, /dev/hdb3), para lo cual se requiere privilegios de root como se muestra a continuación:
# fdisk /dev/hdb
El número de cilindros para este disco está establecido en 60801.
No hay nada malo en ello, pero es mayor que 1024, y en algunos casos
podría causar problemas con:
1) software que funciona en el inicio (p.ej. versiones antiguas de LILO)
2) software de arranque o particionamiento de otros sistemas operativos
(p.ej. FDISK de DOS, FDISK de OS/2)
Orden (m para obtener ayuda):
OpenSourceCollege
Linux for SysAdmins
Página 54
Source Linux
Como se nota arriba, fdisk ya ha reconocido la geometría del disco duro y nos muestra un prompt listo para aceptar órdenes,
sugiriéndonos que el comando m nos muestra la ayuda de la herramienta, de la cual debajo mostramos los comandos más comunes:
a : Conmuta el indicador de iniciable (marca una partición como activa)

d : Suprime una partición
l : Lista los tipos de particiones conocidos (identificadores de particiones)
m : Imprime este menú
n : Añade una nueva partición
o : Crea una nueva tabla de particiones DOS vacía (una tabla de particiones msdos)
p : Imprime la tabla de particiones
q : Sale sin guardar los cambios
t : Cambia el identificador de sistema de una partición
w : Escribe la tabla en el disco y sale
Cada uno de los cambios que hacemos con fdisk ya sea eliminar, crear o modificar una partición no se hacen efectivos en la tabla de
particiones sino hasta que guardemos los cambios usando el comando w, por ello sólo debemos usar este comando cuando estemos
totalmente seguros de los cambios hechos.
Ejemplo 14:
a) Creación de una tabla de particiones vacía en un disco duro nuevo (en blanco) y luego crear 5 particiones como sigue:
• Partición 1 (primaria) de tipo Linux swap de 500 MB

• Partición 2 (primaria) de tipo Linux de 100 MB
• Partición 3 (extendida) del resto de capacidad del disco
• Partición 5 (logica) de tipo Linux de 1000 MB
• Partición 6 (logica) de tipo Linux del resto de capacidad del disco
+ Invocamos a fdisk hacia el disco duro /dev/hdb:
# fdisk /dev/hdb
El dispositivo no contiene una tabla de particiones DOS válida ni una etiqueta de disco Sun o SGI
o OSF
Se está creando una nueva etiqueta de disco DOS. Los cambios sólo
permanecerán en la memoria, hasta que decida escribirlos. Tras esa
operación, el contenido anterior no se podrá recuperar.
El número de cilindros para este disco está establecido en 8322.

No hay nada malo en ello, pero es mayor que 1024, y en algunos casos
podría causar problemas con:
1) software que funciona en el inicio (p.ej. versiones antiguas de LILO)
2) software de arranque o particionamiento de otros sistemas operativos
(p.ej. FDISK de DOS, FDISK de OS/2)
Atención: el indicador 0x0000 inválido de la tabla de particiones 4 se corregirá mediante w(rite)
+ Creamos la tabla de particiones msdos vacía:
Orden (m para obtener ayuda): o

Se está creando una nueva etiqueta de disco DOS. Los cambios sólo
permanecerán en la memoria, hasta que decida escribirlos. Tras esa
operación, el contenido anterior no se podrá recuperar.
+ Creamos la partición N° 1:
Orden (m para obtener ayuda): n

Acción de la orden
e Partición extendida
p Partición primaria (1-4)
p
Número de partición (1-4): 1
Primer cilindro (1-8322, valor predeterminado 1):(Enter)
Se está utilizando el valor predeterminado 1
Último cilindro o +tamaño o +tamañoM o +tamañoK (1-8322, valor predeterminado 8322):+500M
OpenSourceCollege
Linux for SysAdmins
Página 55
Source Linux

Acción de la orden
p

Acción de la orden
e
Último cilindro o +tamaño o +tamañoM o +tamañoK (1166-8322, valor predeterminado 8322):(Enter)

Acción de la orden
l Partición lógica (5 o superior)
l

Acción de la orden
l
+ Imprimimos la tabla de particiones:
Orden (m para obtener ayuda): p
Disco /dev/hdb: 4294 MB, 4294967296 bytes

16 heads, 63 sectors/track, 8322 cylinders
Unidades = cilindros de 1008 * 512 = 516096 bytes
Disposit. Inicio Comienzo Fin Bloques Id Sistema

/dev/hdb1 1 970 488848+ 83 Linux
/dev/hdb2 971 1165 98280 83 Linux
/dev/hdb3 1166 8322 3607128 5 Extendida
/dev/hdb5 1166 3104 977224+ 83 Linux
/dev/hdb6 3105 8322 2629840+ 83 Linux
Orden (m para obtener ayuda):
+ Como la partición N° 1 aún tiene el identificador Linux lo cambiamos a Linux swap consultando previamente el listado de
OpenSourceCollege
Linux for SysAdmins
Página 56
Source Linux
identificadores disponibles:
Orden (m para obtener ayuda): t

Código hexadecimal (escriba L para ver los códigos): L
0 Vacía 1e Hidden W95 FAT1 80 Old Minix bf Solaris

1 FAT12 24 NEC DOS 81 Minix / old Lin c1 DRDOS/sec (FAT-
2 XENIX root 39 Plan 9 82 Linux swap / So c4 DRDOS/sec (FAT-
3 XENIX usr 3c PartitionMagic 83 Linux c6 DRDOS/sec (FAT-
4 FAT16 <32M 40 Venix 80286 84 Unidad C: ocult c7 Syrinx
5 Extendida 41 PPC PReP Boot 85 Linux extendida da Datos sin SF
6 FAT16 42 SFS 86 Conjunto de vol db CP/M / CTOS / .
7 HPFS/NTFS 4d QNX4.x 87 Conjunto de vol de Utilidad Dell
8 AIX 4e QNX4.x segunda 88 Linux plaintext df BootIt
9 AIX bootable 4f QNX4.x tercera 8e Linux LVM e1 DOS access
a OS/2 Boot Manag 50 OnTrack DM 93 Amoeba e3 DOS R/O
b W95 FAT32 51 OnTrack DM6 Aux 94 Amoeba BBT e4 SpeedStor
c W95 FAT32 (LBA) 52 CP/M 9f BSD/OS eb BeOS fs
e W95 FAT16 (LBA) 53 OnTrack DM6 Aux a0 Hibernación de ee EFI GPT
f W95 Ext'd (LBA) 54 OnTrackDM6 a5 FreeBSD ef EFI (FAT-12/16/
10 OPUS 55 EZ-Drive a6 OpenBSD f0 inicio Linux/PA
11 FAT12 oculta 56 Golden Bow a7 NeXTSTEP f1 SpeedStor
12 Compaq diagnost 5c Priam Edisk a8 UFS de Darwin f4 SpeedStor
14 FAT16 oculta <3 61 SpeedStor a9 NetBSD f2 DOS secondary
16 FAT16 oculta 63 GNU HURD o SysV ab arranque de Dar fb VMware VMFS
17 HPFS/NTFS ocult 64 Novell Netware b7 BSDI fs fc VMware VMKCORE
18 SmartSleep de A 65 Novell Netware b8 BSDI swap fd Linux raid auto
1b Hidden W95 FAT3 70 DiskSecure Mult bb Boot Wizard hid fe LANstep
1c Hidden W95 FAT3 75 PC/IX be arranque de Sol ff BBT
Código hexadecimal (escriba L para ver los códigos): 82

Se ha cambiado el tipo de sistema de la partición 1 por 82 (Linux swap / Solaris)
+ Volvemos a visualizar la tabla de particiones, si todo está correcto guardamos los cambios y salimos:


/dev/hdb1 1 970 488848+ 82 Linux swap / Solaris
/dev/hdb2 971 1165 98280 83 Linux
/dev/hdb5 1166 3104 977224+ 83 Linux
/dev/hdb6 3105 8322 2629840+ 83 Linux
Orden (m para obtener ayuda): w

¡Se ha modificado la tabla de particiones!
Llamando a ioctl() para volver a leer la tabla de particiones.

Se están sincronizando los discos.
b) Vamos a marcar la partición N° 2 como activa (booteable), luego eliminaremos las particiones lógicas 5 y 6 en favor de crear una que
ocupe la capacidad que ambas ocupaban inicialmente:
+ Marcamos como activa la partición N° 2 y luego visualizamos los cambios hechos (apreciar el símbolo *):
# fdisk /dev/hdb
Orden (m para obtener ayuda): a

OpenSourceCollege
Linux for SysAdmins
Página 57
Source Linux
/dev/hdb2 * 971 1165 98280 83 Linux
/dev/hdb5 1166 3104 977224+ 83 Linux
/dev/hdb6 3105 8322 2629840+ 83 Linux
+ Eliminamos las particiones 6 y 5:
Orden (m para obtener ayuda): d

Orden (m para obtener ayuda): d

+ Creamos la partición lógica N° 5 con toda la capacidad restante del disco:

Acción de la orden
l
+ Visualizamos los cambios hechos, si todo está correcto guardamos los cambios y salimos:


/dev/hdb2 * 971 1165 98280 83 Linux
/dev/hdb5 1166 8322 3607096+ 83 Linux


+ Forzamos al sistema operativo a volver a leer la tabla de particiones recién alterada:
# partprobe
+ Finalmente verificamos nuevamente que la tabla de particiones haya quedado como lo queríamos:
# fdisk -l /dev/hdb
Observaciones:
• Normalmente el kernel no es capaz de leer los nuevos cambios hechos a la tabla de particiones sino hasta el próximo
arranque del sistema. Esta limitación no nos permitiría dar formato a ninguna de las nuevas particiones que hayamos podido
crear.
• Sin embargo la herramienta partprobe nos permite forzar la relectura de la tabla de particiones por parte del sistema
operativo para superar la limitación antes mencionada sin necesidad de reiniciar el sistema.
• Para fdisk es indiferente si se usan mayúsculas o minúsculas en sus comandos (a, p, n, l, d, ...)
OpenSourceCollege
Linux for SysAdmins
Página 58
Source Linux
OpenSourceCollege
Linux for SysAdmins
Página 59
Source Linux
3.3. Formato de dispositivos
Memoria SWAP
El término SWAP o espacio de intercambio es una zona del disco que usan los sistemas operativos para almacenar imágenes de
procesos que no se mantienen en memoria física.
También se le suele conocer a la SWAP como memoria virtual, dado que el criterio básico de funcionamiento consiste en hacer creer al
sistema operativo que cuenta con más memoria de la que realmente tiene físicamente (RAM).
Normalmente el sistema operativo puede manejar tantos procesos como su memoria lo permitan. Si ésta se agota no será posible
ejecutar más procesos mientras que otros mantengan usando la memoria del sistema.
Es así que como forma de solucionar estas situaciones el sistema operativo coloca la imagen (o parte de ella) de un proceso por lo
general poco activo en el área de intercambio (disco) para liberar memoria física en la cual ha de colocar otro proceso de mayor
actividad. Mientras no haga falta el proceso inactivo puede permanecer en el espacio de intercambio hasta el momento en que éste
retome actividad pasando nuevamente a memoria física.
El espacio de intercambio en sistemas operativos Linux es común que se coloque en una partición exclusiva, sin embargo esto no es
obligatorio pues también es posible crear un espacio de intercambio en un fichero dentro del sistema de archivos.
Gestión de la SWAP en Linux

El primer paso para la gestión de la swap o área de intercambio en Linux es crear el espacio físico que utilizará. Si se tiene pensado
colocar la swap en una partición entonces debemos crearla a través de la herramienta fdisk como ya se estudió líneas arriba en este
documento.
Si en cambio se decide colocar la swap en un fichero dentro del sistema de archivos, debemos crearlo usando la herramienta dd como
sigue:
# dd if=/dev/zero of=/swap.00 bs=1M count=500
El ejemplo arriba mostrado asume que el archivo de swap será /swap.00 pero bien podría ser cualquier otro distinto que el administrador
decida (Ejm: /root/archivo-swap, /var/swap.1, /boot/swap1, etc)
También podemos notar que se está creando el archivo de swap usando bloques de 1 MB (bs=1M), creando 500 de éstos
(count=500) con lo que conseguiríamos 500 MB de memoria swap.
Una vez creado el espacio físico para la swap es necesario darle formato, es decir prepararla para que el sistema operativo la pueda
usar como área de intercambio. Esto es posible a través de la herramienta mkswap como se muestran debajo:
# mkswap /dev/hdb1
El ejemplo de arriba prepara una partición para ser usada como swap. Se usaría de forma similar para un archivo usado como swap:
# mkswap /swap.00
Ahora que ya se tiene preparado el espacio físico para la swap sólo nos queda activarlo, es decir ordenarle al sistema operativo que lo
use. Para eso usaremos las herramientas swapon y swapoff para activar y desactivar las áreas de intercambio respectivamente:
swapon [opciones] [dispositivo/archivo]

Activa un dispositivo/archivo como área de intercambio
Opciones:
-a : Activa todos los dispositivos/archivos marcados como swap en /etc/fstab excepto quienes usan la opción noauto
-s : Imprime un listado del uso de memoria swap por cada dispositivo/archivo activo
-p PRI : Activa un dispositivo/archivo como swap con una prioridad PRI
La prioridad PRI es un valor numérico que puede variar entre 32767. A mayor valor numérico mayor será la prioridad.
swapoff [opciones] [dispositivo/archivo]

Activa un dispositivo/archivo como área de intercambio
Opciones:
-a : Desactiva todos los dispositivos/archivos marcados como swap en /etc/fstab excepto quienes usan la opción noauto
OpenSourceCollege
Linux for SysAdmins
Página 60
Source Linux
Ejemplo 15:
a) Crear dos archivos, uno de 300 MB y otro de 150 MB y prepararlos para funcionar como área de intercambio:
# dd if=/dev/zero of=/root/swap.01 bs=1M count=300

# dd if=/dev/zero of=/root/swap.02 bs=1M count=150
# mkswap /root/swap.01
# mkswap /root/swap.02
b) Imprimir un listado del uso actual de memoria swap. Activar uno a uno los archivos creados como swap para el sistema e ir
comparando el uso actual de memoria swap del sistema con las herramientas free y swapon:
# swapon -s
# free -m
# swapon -p 10 /root/swap.01
# swapon -p 30 /root/swap.02
# free -m
# swapon -s
c) Desactivar del sistema los archivos creados como swap:
# swapoff /root/swap.01
# swapoff /root/swap.02
Gestión de sistemas de archivos

Como ya lo estudiamos anteriormente, existen una amplia variedad de sistemas de archivos para distintos sistemas operativos y
propósitos. En los sistemas operativos Linux es muy común el uso del sistema de archivos ext3 por defecto, aunque en las
distribuciones más modernas ya se está optando por ext4.
Generalmente otros sistemas de archivos para Linux como ReiserFS, XFS o JFS son usados sólo con propósitos específicos bajo un
conocimiento consciente del administrador de las características que requiere de estos sistemas de archivos.
Sólo los sistemas de archivos de disco (FAT32, ext3, ext4, ReiserFS, etc) son los únicos que se puedan utilizar para dar formato a
dispositivos.
En cambio los sistemas de archivos de red tal como NFS, SMB/CIFS no se usan para dar formato sino sólo para montar un recurso
remoto en la red.
Creando sistemas de archivos

La herramienta en Linux que se encarga de crear sistemas de archivos en dispositivos es mkfs, la misma que a continuación
detallamos:
mkfs [opciones] <dispositivo/archivo>

Crea sistemas de archivos en dispositivos
Opciones:
-t FS : Especifica a través de FS el sistema de archivos a crear

-c : Chequea el dispositivo en busca de sectores defectuosos antes de crear el sistema de archivos
En realidad mkfs es sólo un frontend de distintas herramientas que llevan la forma mkfs.fs donde fs es el sistema de archivos. Por
ello a continuación revisaremos opciones específica de cada uno de los sistemas de archivos.
mke2fs [opciones] <dispositivo/archivo>

Crea sistemas de archivos ext2, ext3 o ext4
Opciones:
-t : Especifica el sistema de archivos a crear: ext2,ext3 o ext4

-L LABEL : Asigna LABEL como etiqueta del sistema de archivos
Si se usa la herramienta mkfs.ext2 se invocará a mke2fs con la opción -t ext2. De manera análoga mkfs.ext3 invoca a mke2fs -t ext3 y
mkfs.ext4 invoca a mke2fs -t ext4
OpenSourceCollege
Linux for SysAdmins
Página 61
Source Linux
mkdosfs [opciones] <dispositivo/archivo>
Crea sistemas de archivos vfat (FAT)
Opciones:
-F SIZE : Especifica el tamaño de FAT (12, 16, o 32)

-n LABEL : Asigna LABEL como etiqueta del sistema de archivos
Esta herramienta se invoca a través del comando mkfs -t vfat o mkfs.vfat
Observaciones:
• Es importante tener en cuenta que se puede crear sistemas de archivos sólo en dispositivos que no estén montados.
Consulta y modificación de sistemas de archivos

Adicionalmente tenemos la herramienta tune2fs para consultar y/o modificar ciertos atributos de los sistemas de archivos ext2, ext3 y
ext4 existentes en dispositivos.
tune2fs [opciones] <dispositivo/archivo>

Consulta y/o modifica atributos de sistemas de archivos ext2, ext3 y ext4
Opciones:
-c MAX : Asigna MAX como número máximo de veces que el sistema de archivos debe ser montado antes de ser chequeado
-C NUM : Asigna NUM como el número de veces que el sistema de archivos ha sido montado
-i INT : Define el máximo intervalo de tiempo entre dos chequeos del sistema de archivos según el valor de INT
-l : Muestra la información completa del sistema de archivos
-L LABEL : Asigna LABEL como etiqueta del sistema de archivos
INT está conformado por un valor numérico y un sufijo como 'd' (días), 'm' (meses) o 'w' (semanas). Ejm: 30d, 4w, 2m, etc.
* El comando e2label también permite manipular la etiqueta de sistemas de archivos ext2 y ext3
Observaciones:
• Es recomendable (por no decir obligatorio) desmontar el dispositivo que contiene un sistema de archivos antes de
chequearlo.
Ejemplo 16:
a) Crear un sistema de archivos ext3 en /dev/hdb2 con una etiqueta denominada BOOT:
# mkfs -t ext3 -L BOOT /dev/hdb2
b) Crear un sistema de archivos FAT32 en /dev/sda5 con una etiqueta denominada DATA:
# mkfs -t vfat -n DATA /dev/sda5
c) Consultar la etiqueta del sistema de archivos en el dispositivo /dev/hdb2:
# tune2fs -l /dev/hdb2
d) Cambiar la etiqueta del sistema de archivos en el dispositivo /dev/hdb2:
# tune2fs -L arranque /dev/hdb2
Chequeo de sistemas de archivos

La herramienta que se encarga de realizar los chequeos de consistencia a los sistemas de archivos es fsck, la misma que a
continuación detallamos:
OpenSourceCollege
Linux for SysAdmins
Página 62
Source Linux
fsck [opciones] <dispositivo/archivo>
Chequea la consistencia de sistemas de archivos en dispositivos
Opciones:
-t FS : Especifica a través de FS el tipo de sistema de archivos a chequear

-C fd : Muestra en fd una barra de progreso de la operación (soportado sólo por ext2 y ext3)
fd es un descriptor de archivo cuyo valor puede estar representado por 1 (stdout) o 2 (stderr).
En realidad fsck es sólo un frontend de distintas herramientas que llevan la forma fsck.fs donde fs es el sistema de archivos. Por
ello a continuación revisaremos opciones específica de cada uno de los sistemas de archivos.
e2fsck [opciones] <dispositivo/archivo>

Chequea la consistencia de sistemas de archivos ext2, ext3 o ext4
Opciones:
-c : Chequea el dispositivo en busca de sectores defectuosos

-f : Fuerza el chequeo del sistema de archivos aún si éste parece limpio
-p : Automáticamente repara problemas que pueden ser corregidos de manera segura sin intervención del usuario.
dosfsck [opciones] <dispositivo/archivo>

Chequea y repera sistemas de archivos vfat (FAT)
Opciones:
-l : Muestra una lista de archivos que están siendo procesados

-r : Repara el sistema de archivos de forma interactiva con el usuario
OpenSourceCollege
Linux for SysAdmins
Página 63
Source Linux
3.4. Montaje
Conceptos básicos
El montaje es una operación del sistema operativo que consiste en proyectar el contenido de un dispositivo de almacenamiento en un
enlace lógico (un directorio).
Como se ha estudiado ya en este documento, los sistemas UNIX mantienen un árbol de directorios con un origen único que es la raíz
(/), y no existen las unidades de disco (C:, D:, E:) como existe en plataformas Windows asociado para cada dispositivo conectado al
sistema.
En cambio los sistemas UNIX acceden al contenido de dispositivos (que contienen un sistema de archivos dentro) a través de un
directorio cualquiera debajo del árbol que empieza por la raíz (/).
Durante el tiempo que el sistema operativo usa el sistema de archivos de un dispositivo se dice que éste está montado. Luego de
terminar las operaciones necesarias sobre ese sistema de archivos es necesario desmontar el dispositivo, momento en el cual el
directorio inicial sobre el cual estaba montado queda libre nuevamente.
Cabe resaltar que si se decide montar un dispositivo bajo un directorio que contiene datos éstos desaparecerán (quedan ocultos)
mientras hay un sistema de archivos montado encima, y esos datos se harán nuevamente visibles al sistema cuando se desmonte el
dispositivo.
El archivo /etc/fstab
Este archivo es el encargado de definir una lista de dispositivos y sistemas de archivos disponibles en el sistema. En este archivo se
define cómo montar cada uno de ellos a través de opciones específicas para cada dispositivo. Debe tenerse en cuenta que este es un
archivo que sólo el usuario root puede editarlo.
Este archivo consta de 6 columna y su sintaxis es la siguiente:
Tipo de sistema de Opciones de

Dispositivo Punto de montaje Volcado de backup Orden de chequeo
archivos montaje
La explicación de cada uno de estos a continuación:
1. Dispositivo : Referencia al dispositivo que contiene el sistema de archivos a montar. Este dispositivo puede ser especificado
de una de 3 formas:
(a) Por su ruta absoluta : Ruta completa del archivo de dispositivo.

(b) Por su etiqueta : Luego del prefijo LABEL= se especifica la etiqueta del dispositivo.
(c) Por su UUID : Luego del prefijo UUID= se especifica el UUID del dispositivo. (1)
2. Punto de montaje : Ruta absoluta del directorio donde se proyecta el contenido del sistema de archivos.
3. Tipo de sistema de archivos : Especifica el tipo específico de sistema de archivos encontrado en el dispositivo. (2)
(3)
4. Opciones de montaje : Opciones de montaje específicas para cada sistema de archivos. Estas opciones están
documentadas en mount(8).
5. Volcado de backup (Dump): Especifica si la herramienta de backup (dumpe2fs para sistemas de archivos ext2, ext3, ext4)
debe o no hacer un volcado del sistema de archivos al arranque. Por lo general este campo debe tener valor 0 (no hace
volcado).
6. Orden de chequeo (Pass): Especifica si se debe chequear (valor 1 ó 2) o no (valor 0) el sistema de archivos con fsck. Si
se desea habilitar el chequeo debe colocarse el valor 1 para el sistema de archivos raíz / (significa que se chequeará
primero) y 2 para otros sistemas de archivos (significa que se chequeará después de la raíz).
(1) Los dispositivos pueden ser identificados también a través de un UUID (Universally Unique Identifier). Se utiliza la
herramienta blkid para consultar el UUID y etiqueta (LABEL) de los dispositivos del sistema:
Listado de información de todos los dispositivos existentes en el sistema:
# blkid
Consultar la información sólo del dispositivo /dev/hdb2:
# blkid /dev/hdb2
(2) El tipo de sistema de archivos se expresa como una única palabra en minúsculas que lleva el nombre del sistema de
archivos tal como ext2,ext3, ext4, reiserfs, xfs, jfs, vfat, ntfs, ntfs-3g, nfs, smbfs, cifs, iso960, entre otros. Si se especifica la
palabra clave auto como tipo de sistema de archivos se instruirá al sistema para que intente detectar de forma automática
OpenSourceCollege
Linux for SysAdmins
Página 64
Source Linux
qué sistema de archivos existe dentro del dispositivo y luego montarlo.
(3) Algunas de las opciones de montaje más comunes se resumen en la siguiente tabla:
Aplicable al sistema
Opción Descripción
de archivos
defaults Cualquiera Equivalente a usar las opciones rw, suid, dev, exec, auto, nouser y async
Todas las operaciones de E/S son hechas de manera síncrona (sync) o asíncrona
sync / async Cualquiera (async). La opción sync es válida sólo para los sistemas de archivos ext2, ext3,
vfat y ufs.
auto / noauto Cualquiera Activa (auto) o desactiva (noauto) la posibilidad de ser montado con mount -a
dev / nodev Cualquiera Activa (dev) o desactiva (nodev) la interpretación de archivos de dispositivos.
exec / noexec Cualquiera Activa (exec) o desactiva (noexec) la ejecución de binarios.
suid / nosuid Cualquiera Activa (suid) o desactiva (nosuid) el efecto de los bits SUID o SGID en archivos.
Activa (user) o desactiva (nouser) la posibilidad de que un usuario ordinario
user / nouser Cualquiera (distinto de root) pueda montar el dispositivo. Esta opción implica las opciones
noexec, nosuid y nodev.
ro Cualquiera Monta el dispositivo en modo de sólo lectura.
rw Cualquiera Monta el dispositivo en modo de lectura y escritura.
remount Permite remontar un dispositivo ya montado para cambiar sus opciones de montaje.
Cualquiera
(No sirve para cambiar el punto de montaje).
Activa la posibilidad de que cualquier dispositivo montado por un usuario pueda ser
users Cualquiera desmontado por cualquier otro usuario. Esta opción implica las opciones noexec,
nosuid y nodev.
user=arg /
username=arg smbfs, cifs Especifica a través de arg el usuario con el cual conectarse.
password=arg smbfs, cifs Especifica a través de arg la contraseña del usuario con el cual conectarse.
Especifica a través de file la ruta del archivo que contiene las credenciales usadas
para la conexión. El contenido del archivo debe tener la forma:
credentials=file smbfs, cifs
username=arg
password=arg
uid=arg smbfs, cifs, vfat, ntfs, Especifica a través de arg el UID del usuario que figurará como propietario del
ntfs-3g, iso9660 sistema de archivos montado.
gid=arg smbfs, cifs, vfat, ntfs, Especifica a través de arg el GID del grupo que figurará como propietario del sistema
ntfs-3g, iso9660 de archivos montado.
domain=arg smbfs, cifs Especifica a través de arg el dominio (o grupo de trabajo) del usuario a conectarse.
umask=arg Especifica a través de arg en formato octal el valor de la máscara (umask) para el
vfat, ntfs, ntfs-3g
sistema de archivos montado.
acl ext2, ext3 Activa (acl) o desactiva (noacl) el soporte de ACL (Access Control List).
Especifica a través de arg el comportamiento a seguir cuando se encuentra un error
al realizar el montaje del dispositivo. Los posibles valores de arg son:
errors=arg ext2, ext3
continue : Ignora los errores y marca el sistema de archivos como erróneo.
remount-ro : Remonta el sistema de archivos en modo de sólo lectura.
panic : Provoca un kernel panic y detiene el sistema.
usrquota /
ext2, ext3 Activa el soporte de cuotas de usuario (usrquota) y/o cuotas de grupo (grpquota).
grpquota
user_xattr / Activa (user_xattr) o desactiva (nouser_xattr) el soporte de atributos
nouser_xattr ext2, ext3
extendidos.
OpenSourceCollege
Linux for SysAdmins
Página 65
Source Linux
Observaciones:
• Más información de opciones de montaje del sistema de archivos smbfs/cifs pueden ser encontraras en mount.cifs(8).
• El sistema operativo al arrancar ejecuta la orden mount -a. Por ello si se desea configurar un dispositivo para que siempre
se monte al arranque del sistema no debe olvidarse incluir la opción auto o defaults (o no incluir noauto) dentro de su
entrada en /etc/fstab.
Ejemplo 17:
a) Este es un contenido ejemplo de un archivo /etc/fstab:
/dev/sda2 / ext3 defaults,acl 1 1

LABEL=/boot /boot ext3 defaults 1 2
/dev/sda3 /tmp ext3 defaults,noexec,nosuid,nodev 0 0
/dev/VolGroup00/LogVol01 swap swap defaults 0 0
/dev/sda1 /win9x vfat defaults,umask=0022 0 0
/dev/sdb1 /winxp ntfs-3g defaults 0 0
/dev/cdrom /cdrom iso9660 ro,defaults 0 0
UUID="f3596660-816c-4a63-9d1d-4a1ee8530021" /var/spool/squid reiserfs defaults 0 0
La herramientas mount y umount

El comando mount es utilizado en sistemas UNIX para montar sistemas de archivos debajo de un directorio del sistema. Esta
herramienta trabaja de la mano con el archivo /etc/fstab del cual coge parámetros por defecto u omitidos en la invocación del comando
mount.
Por defecto cada vez que se monta un sistema de archivos se escribe en el archivo /etc/mtab su información asociada acorde a la
sintaxis del archivo /etc/fstab.
Por otro lado la herramienta umount se encarga de desmontar un sistema de archivos. Este comando recibe como parámetro o bien el
punto de montaje o la ruta de un dispositivo actualmente montado.
La forma de uso del comando mount se muestra a continuación:
mount [opciones] [archivo/dispositivo] [punto de montaje]

Monta un sistema de archivos
Opciones:
-a : Monta todos dispositivos que tengan la opción 'auto' en /etc/fstab

-l : Muestra las etiquetas de los dispositivos montados.
-n : Monta sin escribir su respectiva entrada en /etc/mtab
-r : Monta el sistema de archivos en modo de sólo lectura.
-w : Monta el sistema de archivos en modo de lectura y escritura (comportamiento por defecto)
-L LABEL : Monta el sistema de archivos cuya etiqueta es LABEL
-U UUID : Monta el sistema de archivos cuyo UUID es UUID
-t FS : Especifica el tipo de sistema de archivos con el cual montar el dispositivo.
-o ARG : A través de ARG especifica las opciones de montaje, cada una separada por comas.
--bind : Remonta el sistema de archivos en otro punto de montaje (hace visible el contenido en otro directorio a la vez)
--move : Mueve el sistema de archivos a otro punto de montaje
Normalmente el comando mount requiere se indique tanto el dispositivo a montar como el punto de montaje, como se muestra debajo:
# mount -t <FS> <dispositivo> <punto de montaje>
Sin embargo si ya existe en /etc/fstab una entrada que defina o bien el dispositivo a montar o bien el punto de montaje, entonces se
puede invocar al comando mount de una de las dos formas breves:
# mount <dispositivo>
# mount <punto de montaje>
En cualquiera de ambas formas, el comando mount intentará adivinar cuáles son las opciones de montaje y tipo de sistema de
archivos basado en la información encontrada en /etc/fstab.
Tener en cuenta que esta forma breve de montaje es la única que puede invocar un usuario ordinario (distinto de root) para montar un
OpenSourceCollege
Linux for SysAdmins
Página 66
Source Linux
dispositivo siempre y cuando tenga la palabra user o users entre sus opciones dentro de su entrada correspondiente en /etc/fstab.
Ejemplo 18:
a) Montar el dispositivo /dev/hdb2 como ext3 bajo el directorio /mnt:
# mount -t ext3 /dev/hdb2 /mnt
b) Consultar información de los dispositivos montados:
# mount
# cat /etc/mtab
c) Mostrar todos los dispositivos montados con ext3 mostrando las etiquetas de cada uno:
# mount -t ext3 -l
d) Liberar el punto de montaje /mnt y montar ahí el dispositivo cuya etiqueta es DATA:
# umount /mnt
# mount -L "DATA" /mnt
e) Remontar en modo sólo lectura y activar el soporte ACL del dispositivo anteriormente montado:
# mount -L "DATA" -o remount,ro,acl /mnt
f) Mover el punto de montaje de /mnt hacia /media del dispositivo anteriormente montado y luego reflejar el montaje de manera
concurrente en el directorio /opt evaluando la información de montaje luego de cada operación realizada:
# mount --move /mnt /media

# mount -l
# mount --bind /media /opt
# mount -l
g) Crear la configuración apropiada para que el dispositivo /dev/hdb5 sea montado como ext3 debajo de /data siempre de forma manual
(no debe ser montada automáticamente al arranque del sistema) y sea posible ser montada por un usuario ordinario:
# Agregar la esta línea al archivo /etc/fstab

/dev/hdb5 /data ext3 defaults,noauto,user 0 0
h) Montar como un usuario ordinario el dispositivo previamente definido:
$ mount /data
i) Montar nuestra unidad de CDROM en /media/cdrom:
# mount -t iso9660 -o ro /dev/cdrom /media/cdrom
j) Desmontar la unidad de CDROM, expulsar el disco y luego cerrar la unidad de CDROM:
# umount /dev/cdrom
# eject
# eject -t
Observaciones:
• En realidad cuando se trabajamos con unidades de CDROM no es necesario desmontarlas si deseamos expulsar el disco ya
que el comando eject se encarga de hacerlo antes de expulsarlo.
OpenSourceCollege
Linux for SysAdmins
Página 67
Source Linux
Montaje de dispositivos NTFS
El kernel Linux trae consigo un soporte nativo para montar dispositivos NTFS. Sin embargo el soporte de éste es completo en modo de
sólo lectura, mientras que en modo escritura el soporte es inestable, limitado y prácticamente inservible.
Este soporte nativo se utiliza a través del tipo de sistema de archivos ntfs invocado desde la línea de comandos de mount como sigue:
# mount -t ntfs /dev/sdb1 /windows
Sin embargo si se desea un soporte estable de lectura y escritura de NTFS es necesario utilizar un driver de terceros (no está incluido
en el kernel Linux original). Este driver es conocido como NTFS-3G desarrollado bajo licencia GNU GPL, que se instala generalmente
como un componente aparte del sistema.
Afortunadamente la mayoría de distribuciones Linux modernas ya incluyen entre sus repositorios de paquetes a NTFS-3G (excepto
Red Hat, CentOS), por lo que ya debería estar listo para instalarse y usarse.
Para montar un dispositivo NTFS con el driver NTFS-3G debemos usar el tipo de sistema de archivos ntfs-3g en la línea de comandos
de mount como sigue:
# mount -t ntfs-3g <dispositivo> <punto de montaje>
Más información sobre NTFS-3G o sus opciones de montaje están disponibles en mount.ntfs-3g(8).
Montaje de imágenes ISO

Las imágenes ISO son archivos que se rigen por el estándar ISO 9660 y almacenan una copia de un sistema de archivos. Estas
imágenes se encuentran generalmente como archivos de extensión .iso.
Si por alguna razón deseamos acceder al contenido de una imagen ISO podemos montar el archivo de la siguiente forma:
# mount -o loop <ruta archivo ISO> <punto de montaje>
Cabe resaltar que siempre una imagen ISO se monta en modo sólo lectura, no es posible modificar su contenido. Esto debido a que el
estándar ISO 9660 ha sido diseñado para ser leído únicamente.
Ejemplo 19:
a) Montar la 1ra. partición de nuestro segundo disco SATA que contiene un sistema operativo Windows XP:
# mount -t ntfs-3g /dev/sdb1 /windows
b) Montar la imagen ISO de DVD que acabamos de descargar de Red Hat Enterprise Linux 5.4:
# mount -o loop rhel-server-5.4-i386-dvd.iso /mnt
OpenSourceCollege
Linux for SysAdmins
Página 68
Source Linux
1. Utilizando un disco duro en blanco crear en él 6 particiones como sigue:
(a) 1 partición para instalar Microsoft Windows Server 2003

(b) 1 partición para instalar FreeBSD
(c) 1 partición para instalar Solaris
(d) 1 partición para instalar Debian GNU/Linux con la raíz en un Logical Volume (LVM)
(e) 1 partición para /boot2 del sistema Debian
(f) 1 partición para la SWAP del sistema Debian
El tamaño de cada partición puede quedar a criterio del usuario. No olvidar asignar los identificadores de partición a cada una
de las que se vayan creando.
Tener en cuenta que FreeBSD, Solaris y Windows no se instalan en particiones lógicas.
2. Sin reiniciar el sistema luego de la tarea anterior, preparar la partición para SWAP y crear un sistema de archivos ext3 en la
partición destinada para /boot2, configurándola para que se monte con soporte de ACLs al arrancar el sistema operativo.
3. Asignar la etiqueta "/boot2" a la partición destinada para /boot2 y consultar luego la información de dicho dispositivo para
averiguar su UUID y etiqueta asignada.
4. Activar la partición destinada para SWAP con una prioridad de 10, y configurarla para que se active al arrancar el sistema.
Apoyarse en la documentación de swapon(8) y fstab(5) para configurar correctamente la prioridad y otros parámetros de
activación de la swap según /etc/fstab.
5. Averiguar la cantidad de veces que ha sido montado el dispositivo destinado para /boot2, luego incrementar ese valor en 5 y
definir en 30 la cantidad máxima de montajes que puede hacerse del dispositivo antes de realizarle un chequeo.
6. Configurar el sistema para que los usuarios sin privilegios (distinto de root) puedan montar y desmontar la unidad de
CDROM.
7. Proyectar de manera concurrente el contenido del punto de montaje /boot2 en el directorio /mnt/boot. Luego consultar la
información de dispositivos montados.
8. Nuestro sistema ha sido conectado a una SAN usando Fibre Chanel con una LUN reconocida por Linux como /dev/sde (con 3
particiones dentro), y mantiene también una conexión hacia un NAS vía iSCSI hacia un dispositivo de almacenamiento
reconocido por Linux como /dev/sdf1. Ya se han definido puntos de montaje estáticos a dichos dispositivos a través de sus
rutas absolutas (/dev/sde1, /dev/sde2, /dev/sde3 y /dev/sdf1) en el archivo /etc/fstab.
Luego de una caída del suministro de energía todos los servidores son reiniciados, pero la SAN es restaurada 10 minutos
después que inicia el servidor NAS, trayendo como consecuencia que la LUN ofrecida por el SAN figura ahora como /dev/sdf
en nuestro sistema Linux.
¿Qué solución sugiere dar para que no suceda en el futuro aquel desorden en la nomenclatura de los dispositivos del SAN y
NAS?
OpenSourceCollege
Linux for SysAdmins
Página 69
Source Linux
3.5.1. Solución del laboratorio N° 3
1. Utilizando un disco duro en blanco crear en él 6 particiones como sigue:
a) 1 partición para instalar Microsoft Windows Server 2003

b) 1 partición para instalar FreeBSD
c) 1 partición para instalar Solaris
d) 1 partición para instalar Debian GNU/Linux con la raíz en un Logical Volume (LVM)
e) 1 partición para /boot del sistema Debian
f) 1 partición para la SWAP del sistema Debian
El tamaño de cada partición puede quedar a criterio del usuario. No olvidar asignar los identificadores de partición a cada
una de las que se vayan creando.
Tener en cuenta que FreeBSD, Solaris y Windows no se instalan en particiones lógicas.
+ Usar fdisk como sigue (se asume un disco /dev/sdc):
# fdisk /dev/sdc
+ Crear una tabla de particiones vacía:
Comando y parámetros: o
+ Crear la 1ra. partición:
Comando y parámetros: n, p, 1, (Enter), +1G
+ Crear la 2da. partición:
+ Crear la 3ra. partición:
+ Crear una partición extendida:
Comando y parámetros: n, e, 4, (Enter), (Enter)
+ Crear la 4ta. partición:
Comando y parámetros: n, l, (Enter), +1G
Comando y parámetros: n, l, 1, (Enter), +100M
Comando y parámetros: n, l, 1, (Enter), +1G
+ Asignar el identificador de partición para la 1ra. partición:
Comando y parámetros: t, 1, 7
+ Asignar el identificador de partición para la 2da. partición:
Comando y parámetros: t, 2, a5
+ Asignar el identificador de partición para la 3ra. partición:
Comando y parámetros: t, 3, bf
+ Asignar el identificador de partición para la 4ta. partición:
Comando y parámetros: t, 4, 8e
+ Asignar el identificador de partición para la 6ta. partición:
Comando y parámetros: t, 6, 82
OpenSourceCollege
Linux for SysAdmins
Página 70
Source Linux
+ Guardar los cambios en la tabla de particiones:
Comando y parámetros: w
2. Sin reiniciar el sistema luego de la tarea anterior, preparar la partición para SWAP y crear un sistema de archivos ext3 en la
partición destinada para /boot2, configurándola para que se monte con soporte de ACLs al arrancar el sistema operativo.
+ Invocamos a partprobe para una relectura de la tabla de particiones:
# partprobe
+ Preparar la partición para SWAP:
# mkswap /dev/sdc7
+ Usando mkfs creamos el sistema de archivos:
# mkfs -t ext3 /dev/sda6
+ Configuramos para que se monte al arranque con soporte de ACL agregando la siguiente línea al archivo /etc/fstab:
/dev/sda6 /boot2 ext3 defaults,acl 0 0
3. Asignar la etiqueta "/boot2" a la partición destinada para /boot2 y consultar luego la información de dicho dispositivo para
averiguar su UUID y etiqueta asignada.
+ Asignamos "/boot2" como etiqueta usando tune2fs:
# tune2fs -L "/boot2" /dev/sda6
+ Consultamos la información con blkid:
# blkid /dev/sda6
4. Activar la partición destinada para SWAP con una prioridad de 10, y configurarla para que se active al arrancar el sistema.
Apoyarse en la documentación de swapon(8) y fstab(5) para configurar correctamente la prioridad y otros parámetros de
activación de la swap según /etc/fstab.
+ Activar el dispositivo /dev/sda7 como swap con prioridad 10:
# swapon -p 10 /dev/sda7
+ Configurar para que se active al arranque con dicha prioridad agregando la siguiente línea al archivo /etc/fstab:
/dev/sda7 swap swap defaults,pri=10 0 0
5. Averiguar la cantidad de veces que ha sido montado el dispositivo destinado para /boot2, luego incrementar ese valor en 5 y
definir en 30 la cantidad máxima de montajes que puede hacerse del dispositivo antes de realizarle un chequeo.
+ Consultar la información del sistema de archivos en /dev/sda6 y buscar la línea que diga Mount count:
# tune2fs -l /dev/sda6
+ Del valor obtenido (asumiendo que es 2) incrementarlo en 5 y asignarlo como cantidad de veces montada al dispositivo
/dev/sda6:
# tune2fs -C 7 /dev/sda6
+ Definir en 30 el límite de montajes necesarios para chequear el sistema de archivos:
# tune2fs -c 30 /dev/sda6
OpenSourceCollege
Linux for SysAdmins
Página 71
Source Linux
6. Configurar el sistema para que los usuarios sin privilegios (distinto de root) puedan montar y desmontar la unidad de
CDROM.
+ Agregar la siguiente línea al archivo /etc/fstab:
/dev/cdrom /media/cdrom auto defaults,user 0 0
7. Proyectar de manera concurrente el contenido del punto de montaje /boot2 en el directorio /mnt/boot. Luego consultar la
información de dispositivos montados.
+ Utilizamos la opción --bind con el comando mount como sigue:
# mount --bind /boot2 /mnt/boot

# mount
8. Nuestro sistema ha sido conectado a una SAN usando Fibre Chanel con una LUN reconocida por Linux como /dev/sde (con 3
particiones dentro), y mantiene también una conexión hacia un NAS vía iSCSI hacia un dispositivo de almacenamiento
reconocido por Linux como /dev/sdf1. Ya se han definido puntos de montaje estáticos a dichos dispositivos a través de sus
rutas absolutas (/dev/sde1, /dev/sde2, /dev/sde3 y /dev/sdf1) en el archivo /etc/fstab.
Luego de una caída del suministro de energía todos los servidores son reiniciados, pero la SAN es restaurada 10 minutos
después que inicia el servidor NAS, trayendo como consecuencia que la LUN ofrecida por el SAN figura ahora como /dev/sdf
en nuestro sistema Linux.
¿Qué solución sugiere dar para que no suceda en el futuro aquel desorden en la nomenclatura de los dispositivos del SAN y
NAS?
+ Los dispositivos SCSI son nombrados por el sistema operativo como /dev/sda, /dev/sdb, /dev/sdc y así sucesivamente según
el orden en el que son reconocidos o conectados. Por ello si no tenemos la certeza del orden en el que serán conectados
tanto el SAN como NAS al sistema debemos configurar su montaje en el archivo /etc/fstab en base a un valor invariable en el
arranque: según sus etiquetas o según sus UUID
+ Si deseamos trabajar con etiquetas, primero debemos asignarlas a los dispositivos:
# tune2fs -L "oracle1" /dev/sde1

# tune2fs -L "oracle2" /dev/sde2
# tune2fs -L "oracleBK" /dev/sde3
# tune2fs -L "data" /dev/sdf1
+ Luego definir sus respectivas entradas en /etc/fstab como sigue:
LABEL=oracle1 /u01 ext3 defaults 0 0

LABEL=oracle2 /u02 ext3 defaults 0 0
LABEL=oracleBK /oraBK ext3 defaults 0 0
LABEL=data /datos ext3 defaults 0 0
+ Si deseamos trabajar con etiquetas, debemos averiguar los UUID de los dispositivos:
# blkid
+ Luego definir sus respectivas entradas en /etc/fstab como sigue:
UUID=dce0721d-dca4-4b7a-a55c-bfc49943886f /u01 ext3 defaults 0 0

UUID=1c1d83e1-e475-4d95-917e-fa33e874ca59 /u02 ext3 defaults 0 0
UUID=d30f5499-125a-4921-9f14-0c7449bcbaa2 /oraBK ext3 defaults 0 0
UUID=f1d66799-e1d5-4eb7-b974-30959d57a6c5 /datos ext3 defaults 0 0
OpenSourceCollege
Linux for SysAdmins
Página 72
Source Linux
Unidad 4: Administración de usuarios
4.1. Objetivos
✔ Conocer la sintaxis de los archivos de usuarios, grupos y contraseñas del sistema.

✔ Comprender los atributos asociados a los usuarios y grupos.
✔ Saber gestionar los usuarios, su pertenencia a grupos y configuración de atributos.
✔ Administrar correctamente las políticas de contraseñas de usuarios.
4.2. Control de contraseñas

Conceptos básicos
Los sistemas UNIX desde su creación incluyeron la característica de multiusuario. Esto significa que tienen la capacidad de atender las
tareas de varios usuarios de manera concurrente.
Como una forma de mejor organización de los usuarios se creó el concepto de grupo, que no es más que un conjunto o agrupación de
múltiples usuarios bajo una entidad con nombre y atributos propios.
Un usuario tiene la posibilidad de pertenecer a múltiples grupos, pero siempre sólo uno de ellos representa el grupo primario de dicho
usuario, mientras que los grupos restantes representan sus grupos secundarios.
En Linux los usuarios y sus atributos están definidos en el archivo /etc/passwd, mientras que los grupos en el archivo /etc/group.
El archivo /etc/passwd
Archivo de texto plano que contiene información de las cuentas de usuario del sistema y sus atributos. Este archivo debe tener
permisos de lectura para todos los usuarios, pero es modificable sólo por root. La sintaxis de este archivo es como sigue:
Directorio
Cuenta Contraseña UID GID GECOS Shell
personal
El archivo /etc/passwd separa cada uno de estos campos por dos puntos (:). La explicación de cada uno de ellos a continuación:
1. Cuenta : Nombre de usuario en el sistema. No debería contener mayúsculas.
2. Contraseña : Puede contener la contraseña encriptada del usuario, un asterisco (1) (*) o la letra 'x' (2)
. Si se omite este campo
el usuario podrá iniciar sesión sin password alguno, tan sólo ingresando su cuenta.
3. UID : El identificador (ID) numérico del usuario.
4. GID : El identificador (ID) numérico del grupo primario del usuario.
5. GECOS : Campo opcional. Puede contener una serie de datos (nombre completo, número de oficina, número telefónico u
otros) cada uno separado por comas, pero generalmente sólo suele contener el nombre completo del usuario.
6. Directorio personal : La ruta absoluta del directorio personal del usuario, donde éste es ubicado tras su inicio de sesión.
7. Shell : Programa a ser ejecutado por el usuario tras el inicio de sesión. Si se omite se asume /bin/sh. Si se asigna a este
campo un valor que no represente una shell válida o ejecutable el usuario no será capaz de iniciar sesión.
(1) Un valor de asterisco en el campo de contraseñas deshabilita la autenticación de dicho usuario.

(2) Un valor de 'x' en el campo de contraseñas significa que se utiliza el sistema shadow para la gestión de claves.
A continuación se muestran dos ejemplos de entradas del archivo /etc/passwd, la segunda difiere de la primera en que se usa un
sistema shadow para la gestión de contraseñas.
eramirez:$1$2kQCDMeH$pbYGf5eL.alohiVI7CwRx.:1000:1000:Edson Ramirez:/home/admin:/bin/bash
achang:x:1001:1001::/home/achang:/bin/false
El archivo /etc/group
Archivo de texto plano que contiene información de los grupos a los cuales pertenecen los usuarios del sistema. Este archivo debe
tener permisos de lectura para todos los usuarios, pero es modificable sólo por root. La sintaxis de este archivo es como sigue:
OpenSourceCollege
Linux for SysAdmins
Página 73
Source Linux
Nombre de grupo Contraseña GID Lista de usuarios
El archivo /etc/group separa cada uno de estos campos por dos puntos (:). La explicación de cada uno de ellos a continuación:
1. Nombre de grupo : El nombre del grupo.

(3)
2. Contraseña : Puede contener la contraseña encriptada del grupo, la letra 'x' o si se omite este campo entonces no se
requiere contraseña para el acceso al grupo.
3. GID : El identificador (ID) numérico del grupo.
4. Lista de usuarios : Lista de usuarios separada por coma que son miembros del grupo.
(1) Un valor de 'x' en el campo de contraseñas significa que se utiliza el sistema shadow para la gestión de claves.
A continuación se muestran dos ejemplos de entradas del archivo /etc/group, la segunda difiere de la primera en que se usa un sistema
shadow para la gestión de contraseñas.
sysadmin:$1$2kQCDMeH$pbYGf5eL.alohiVI7CwRx.:500:eramirez,achang,root
guests:x:501:tsoto,guest1,mruiz,esolis
Contraseñas Shadow
En los inicios de UNIX, las contraseñas encriptadas de los usuarios y grupos era almacenada dentro del mismo archivo /etc/passwd y
/etc/group respectivamente, los cuales tienen acceso de lectura para todos los usuarios. Esto representaba cierto nivel de inseguridad
pues cualquier usuario sin privilegios tenía acceso a leer la contraseña encriptada de cualquier otro usuario (incluido root), y esto
conllevaba a un potencial ataque de fuerza bruta para adivinar los passwords.
Es así que como solución a este problema aparece alrededor del año 1988 el sistema de contraseñas Shadow para UNIX, siendo
portado a Linux alrededor del año 1992.
Este sistema de contraseñas Shadow tiene por objetivo almacenar los passwords encriptados de los usuarios en el archivo /etc/shadow
y de los grupos en /etc/gshadow, archivos que sólo usuarios privilegiados (root) tienen acceso de lectura.
Esto trae como consecuencia que los correspondientes campos de contraseñas de los archivos /etc/passwd y /etc/group son
reemplazados por la letra 'x' como se indicó con anterioridad.
Adicionalmente este sistema Shadow trae consigo otras funcionalidad importantes como la gestión de políticas de contraseñas,
expiración de cuentas y administradores de grupos.
El archivo /etc/shadow
Archivo de texto plano que contiene información sobre las contraseñas encriptadas de usuarios, atributos de las políticas de expiración
de cuentas y de contraseñas. Este archivo debe tener permisos de lectura sólo por root, ningún permisos para el resto de usuarios.
La sintaxis de este archivo es como sigue:
Fecha del Advertencia Duración Fecha en

Duración Duración
último de expiración máxima de que la Campo
Cuenta Contraseña mínima de la máxima de la
cambio de de contraseña cuenta es reservado
contraseña contraseña
contraseña contraseña expirada deshabilitada
El archivo /etc/shadow separa cada uno de estos campos por dos puntos (:). La explicación de cada uno de ellos a continuación:
1. Cuenta : Nombre de usuario en el sistema.
2. Contraseña : Contraseña encriptada (4) del usuario. Si este campo contiene un caracter inválido de contraseña (como ! ó *)
entonces queda deshabilitada la autenticación del usuario.
3. Fecha del último cambio de contraseña : Fecha en formato numérico de días (5) en que el usuario cambió por última vez su
contraseña.
4. Duración mínima de la contraseña : Cantidad de días que un usuario debe esperar para cambiar nuevamente su
contraseña desde la fecha del último cambio realizado.
5. Duración máxima de la contraseña : Cantidad máxima de días que puede durar una contraseña antes que expire.
6. Advertencia de expiración de contraseña : Cantidad de días anticipados en que se avisa a un usuario que su contraseña
OpenSourceCollege
Linux for SysAdmins
Página 74
Source Linux
está por expirar.
7. Duración máxima de contraseña expirada : Cantidad de días transcurridos (sin cambio de contraseña) luego de la fecha
de expiración de una contraseña que se considera que el usuario está inactivo y se ha de deshabilitar su cuenta. A este
campo también se le suele conocer como tiempo de inactividad.
(5)
8. Fecha en que la cuenta es deshabilitada : Fecha en formato numérico de días en que la cuenta de usuario será
deshabilitada.
(1) Las contraseñas en un principio fueron encriptadas usando el algoritmo DES, siendo reemplazados poco tiempo despúes por
el algoritmo MD5. Este último no es un algoritmo muy seguro, es vulnerable a un ataque de colisiones al igual que SHA-1,
pero es el que muchas distribuciones Linux aún usan por defecto. Sin embargo algunas distribuciones como openSuSE y
SuSE Linux Enterprise Server ya no usan DES ni MD5 sino Blowfish por defecto, algoritmo del cual aún no se le conocen
vulnerabilidades de colisión.
No obstante cambiar el algoritmo de encriptación de contraseñas desde DES o MD5 hacia Blowfish en otras distribuciones
Linux no es algo nada complicado de lograr.
(2) Este formato numérico de fecha se representa como la cantidad de días transcurridos desde el 1ro. de Enero del año 1970
(inicio del tiempo UNIX) hasta la fecha actual. Este valor se puede obtener así:
$ echo $(( $(date +%s) / 86400 ))
El formato +%s del comando date muestra la cantidad de segundos transcurridos desde el 1ro. de Enero de 1970, y para
hacer el cálculo en días lo dividimos entre 86400 (cantidad de segundos que tiene un día).
Una forma alterna de mostrar el mismo valor es a través del uso de Perl:
$ perl -e '$days=int(time()/86400); print "$days\n";'
El archivo /etc/gshadow
Archivo de texto plano que contiene información sobre las contraseñas encriptadas de usuarios, atributos de las políticas de expiración
de cuentas y de contraseñas. Este archivo debe tener permisos de lectura sólo por root, ningún permisos para el resto de usuarios.
La sintaxis de este archivo es como sigue:
Nombre de grupo Contraseña Lista de administradores Lista de miembros
El archivo /etc/gshadow separa cada uno de estos campos por dos puntos (:). La explicación de cada uno de ellos a continuación:
1. Nombre de grupo : El nombre del grupo.
2. Contraseña : Contraseña encriptada del grupo. Si este campo contiene un caracter inválido de contraseña (como ! ó *)
entonces queda deshabilitada la autenticación de usuarios a este grupo.
3. Lista de administradores : Lista de usuarios separada por coma que son administradores del grupo.
4. Lista de usuarios : Lista de usuarios separada por coma que son miembros del grupo.
Migración al sistema Shadow

Aquellos sistemas que ya tienen instalado el sistema de contraseñas Shadow pero mantienen el archivo /etc/passwd con el formato
antigua, es decir con las contraseñas encriptadas dentro, pueden migrar hacia el formato shadow con el archivo /etc/shadow a través del
uso del comando pwconv ejecutado como root. De manera análoga puede migrarse el archivo de grupos /etc/group al sistema shadow
con el comando grpconv.
El proceso de migración reversa también es posible (aunque no recomendado más allá de propósitos de prueba), es decir convertir los
archivos de usuarios y grupos del sistema shadow al sistema tradicional usando los comandos pwunconv y grpunconv
respectivamente.
OpenSourceCollege
Linux for SysAdmins
Página 75
Source Linux
Herramientas de gestión de contraseñas
Ahora que ya conocemos la sintaxis de los archivos de usuarios y grupos en el sistema es tiempo de aprender a manipularlas desde al
línea de comandos.
El comando passwd es el encargado de asignar y modificar el password de los usuarios. Su sintaxis de uso se muestra a continuación:
passwd [opciones] [usuario]

Modifica contraseñas de los usuarios
Opciones:
-l : Deshabilita una cuenta. Lo hace colocando !! al inicio del campo de la contraseña en /etc/passwd o /etc/shadow
-u : Habilita una cuenta deshabilitada.
-e : Expira una contraseña de usuario inmediatamente. Usado para forzar el cambio de password de un usuario en su próximo
inicio de sesión. (No disponible en Red Hat).
-d : Elimina la contraseña de un usuario.
-x MAX : Define a través de MAX la duración máxima de una contraseña.
-x MIN : Define a través de MIN la duración mínima de una contraseña.
-w NUM : Define a través de NUM la cantidad de días de anticipados que se advierte a un usuario de su clave próxima a expirar.
-i NUM : Define a través de NUM la cantidad de días de días de inactividad permitidos desde la expiración de una contraseña antes
que se deshabilite una cuenta.
-S : Muestra el estado de la contraseña del usuario.
Este comando puede ser usado por usuarios sin privilegios (distintos de root) sólo para cambiar su password personal -invocando a
passwd sin argumentos- y conocer el estado de su contraseña usando el argumento -S (en Red Hat sólo root puede hacerlo).
En cambio el usuario root tiene la posibilidad de utilizar todos los argumentos existentes de esta herramienta, pudiendo modificar su
propio password, así como el de otros usuarios y las políticas de expiración de éstos.
El estado de una contraseña de usuario (opción -S) tiene la siguiente forma:
admin PS 2009-11-13 10 30 7 5
Donde los campos de izquierda a derecha son: nombre de usuario, estado de la cuenta (PS o P cuenta habilitada con password, NP
cuenta habilitada sin password, LK o L cuenta deshabilitada), fecha del último cambio de clave, duración mínima de la contraseña,
duración máxima de la contraseña, días de advertencia previos a la expiración de contraseña y los días de inactividad luego de la
expiración para deshabilitar la cuenta.
El comando chage es otra herramienta especializada sólo en la gestión de políticas de expiración de contraseñas y cuentas. Coincide
en algunos usos que el comando passwd pero incluye otras funcionalidades adicionales como se muestra a continuación:
chage [opciones] <usuario>

Modifica las políticas de expiración de contraseñas y cuentas de usuarios
Opciones:
-d FECH : Define a través de FECH (en formato YYYY-MM-DD) la fecha del último cambio de contraseña del usuario.
-E FECH : Define a través de FECH (en formato YYYY-MM-DD) la fecha de expiración de la cuenta del usuario.
-M MAX : Define a través de MAX la duración máxima de una contraseña.
-m MIN : Define a través de MIN la duración mínima de una contraseña.
-W NUM : Define a través de NUM la cantidad de días de anticipados que se advierte a un usuario de su clave próxima a expirar.
-I NUM : (i mayúscula) Define a través de NUM la cantidad de días de días de inactividad permitidos desde la expiración de una
contraseña antes que se deshabilite una cuenta.
-l : Muestra el estado de la contraseña y cuenta del usuario.
El comando gpasswd es una herramienta encargada de gestionar los miembros, administradores y contraseñas de los grupos. Su
sintaxis de uso de muestra debajo:
gpasswd [opciones] [grupo]

Modifica los miembros, administradores y contraseña de grupos
Opciones:
-A USER : Agrega el usuario USER como administrador (mas no miembro) del grupo. Sólo root puede usar esta opción.
-a USER : Agrega el usuario USER como miembro del grupo. Sólo root o un administrador del grupo pueden usar esta opción.
-d USER : Elimina el usuario USER como miembro del grupo.
-r : Remueve la contraseña del grupo. Nadie puede acceder a él usando el comando newgrp excepto los miembros.
OpenSourceCollege
Linux for SysAdmins
Página 76
Source Linux
El comando newgrp permite ingresar con un nuevo grupo tomando las credenciales de éste:
newgrp [grupo]
Ingresa con un nuevo grupo
Este comando cambia la identificación del grupo primario de quien lo invoca durante la duración de su sesión. Si el usuario ya es
miembro del grupo entonces el ingreso es inmediato, pero si no es miembro entonces el grupo puede solicitar una contraseña para
autorizar el ingreso.
El comando id muestra información de identidad de un usuario:
id [opciones] [usuario]
Muestra la identidad de usuarios
-u : Muestra sólo el UID del usuario

-g : Muestra sólo el GID del grupo primario del usuario
-G : Muestra el GID de todos los grupos a los que pertenece el usuario
-n : Muestra el nombre en lugar de números (UID/GID) para las opciones -u -g -G
Ejemplo 20:
a) Asignar una contraseña al usuario admin:
# passwd admin
b) Bloquear la cuenta del usuario admin:
# passwd -l admin
c) Al usuario admin definirle en 30 la duración máxima de la clave, en 3 la duración mínima, 7 los días de inactividad tolerados tras su
expiración de contraseña y 5 los días de advertencia previos a su expiración de contraseña. Consultar luego el estado de la cuenta:
# passwd -x 30 -n 3 -i 7 -w 5 admin
# passwd -S admin
# chage -M 30 -m 3 -I 7 -W 5 admin
# chage -l admin
d) Habilitar la cuenta del usuario admin y consultar luego su estado:
# passwd -u admin
# passwd -S admin
e) Establecer la fecha del último cambio de clave del usuario admin en un valor que represente 25 días previos a la fecha actual.
Probar luego el inicio de sesión con el usuario admin desde una consola virtual y evaluar los resultados.
# chage -d "2009-10-05" admin
f) Definir al usuario admin como administrador del grupo usuarios:
# gpasswd -A admin usuarios
g) Realizando la siguiente operación como el usuario admin, asignar una contraseña al grupo usuarios y agregar dos miembros:
$ gpasswd usuarios
$ gpasswd -a eflores usuarios
$ gpasswd -a mruiz usuarios
h) Realizando la siguiente operación como el usuario eramirez, intentar ingresar al grupo usuarios:
$ newgrp usuarios
OpenSourceCollege
Linux for SysAdmins
Página 77
Source Linux
OpenSourceCollege
Linux for SysAdmins
Página 78
Source Linux
4.3. Gestión de usuarios y grupos
Dado que ya hemos avanzado con una buena base de los conceptos de usuarios, grupos, sus atributos y políticas de contraseñas, de
ahora en adelante podemos concentrarnos sólo en las herramientas necesarias.
Administración de usuarios
La herramienta useradd nos permite crear usuarios, y su sintaxis de uso es la siguiente:
useradd [opciones] <usuario>

Crea nuevos usuarios
Opciones:
-c ARG : A través del valor de ARG define el atributos GECOS del usuario (comúnmente sus nombres).
-d DIR : A través del valor de DIR define la ruta del directorio personal del usuario.
-m : Usado en conjunto con -d permite crear el directorio personal del usuario si aun no existiese.
-s SH : A través del valor de SH define la ruta del intérprete de órdenes o Shell asignado al usuario.
-g GRP : A través del valor de GRP define el grupo primario del usuario.
-G GRP : A través del valor de GRP define los grupos secundarios del usuario, cada uno separado por comas.
-u UID : A través del valor de UID define el identificador numérico (UID) del usuario. No debe repetirse este valor.
-k SKEL : A través del valor de SKEL define la ruta del directorio esqueleto (skel) desde el cual se copiará la estructura para crear el
directorio personal del usuario.
-D : Muestra los valores por defecto del comando useradd
La herramienta usermod nos permite modificar usuarios, y su sintaxis de uso es la siguiente:
usermod [opciones] <usuario>

Modifica información de usuarios
Opciones:
-c ARG : A través del valor de ARG define el atributos GECOS del usuario (comúnmente sus nombres).
-d DIR : A través del valor de DIR define la ruta del directorio personal del usuario.
-s SH : A través del valor de SH define la ruta del intérprete de órdenes o Shell asignado al usuario.
-g GRP : A través del valor de GRP define el grupo primario del usuario.
-G GRP : A través del valor de GRP define los grupos secundarios del usuario, cada uno separado por comas.
-u UID : A través del valor de UID define el identificador numérico (UID) del usuario. No debe repetirse este valor.
-l LOGIN : A través del valor de LOGIN define el nuevo nombre del usuario.
-L : Deshabilita una cuenta de usuario.
-U : Habilita una cuenta de usuario.
La herramienta userdel nos permite eliminar usuarios, y su sintaxis de uso es la siguiente:
userdel [opciones] <usuario>

Elimina usuarios
Opciones:
-f : Fuerza la eliminación del usuario aún si éste se encuentra logueado al sistema, o si su directorio personal o buzón de
correo tiene un propietario distinto.
-r : Permite eliminar el directorio personal del usuario.
Por defecto esta herramienta no permite eliminar un usuario actualmente logueado al sistema. Es necesario matar primero todos sus
procesos antes de intentar eliminarlo a menos que se use la opción -f
Administración de grupos
La herramienta groupadd nos permite crear grupos, y su sintaxis de uso es la siguiente:
groupadd [opciones] <grupo>

Crea nuevos grupos
Opciones:
-g GID : A través del valor de GID define el identificador numérico (GID) del grupo. No debe repetirse este valor.
OpenSourceCollege
Linux for SysAdmins
Página 79
Source Linux
La herramienta groupmod nos permite modificar grupos, y su sintaxis de uso es la siguiente:
groupmod [opciones] <grupo>

Modifica información de grupos
Opciones:
-g GID : A través del valor de GID define el identificador numérico (GID) del grupo. No debe repetirse este valor.
-n GRP : A través del valor de GRP define el nuevo nombre del grupo.
La herramienta groupdel nos permite eliminar grupos, y su sintaxis de uso es la siguiente:
groupdel <grupo>
Elimina grupos
No se puede eliminar un grupo que representa el grupo primario de algún usuario. Es necesario que primero se elimine el usuario o a
éste se le asigne otro grupo primario.
Cuotas de usuarios y grupos

Las cuotas son un mecanismo de control del sistema operativo para limitar los recursos de almacenamiento que pueden utilizar los
usuarios y/o grupos. Existen dos criterios de cuotas: cuotas por inodos y cuotas por bloques.
Las cuotas por inodos limitan la cantidad de ficheros (archivos y directorios) que un usuario puede crear. Las cuotas por bloques limitan
la cantidad de espacio en disco que un usuario puede utilizar, contabilizado en número de bloques cada uno de 1 KB de capacidad.
Teoría de las cuotas:
En el ámbito de las cuotas existen 3 conceptos importantes por conocer: límite blando, límite duro y tiempo de gracia. El usuario al
cual se le han definido cuotas por inodos o bloques, mantiene un límite blando que es numéricamente menor que el límite duro.
Cuando el usuario alcanza el límite blando (ocupa tantos inodos o bloques igual o mayores que el límite) el sistema le ha de
generar una advertencia, y es a partir de este momento que se inicia el conteo del tiempo de gracia, que significa el plazo que tiene
para reducir sus inodos o bloques usados hasta caer por debajo del límite blando.
Durante el tiempo de gracia el usuario aún podrá aumentar su consumo de inodos o bloques, siempre y cuando no supere el límite
duro (numéricamente mayor).
Si se cumple el tiempo de gracia y el usuario sigue por encima del límite blando entonces este límite se convierte en duro, esto
quiere decir que el usuario no puede incrementar su consumo de inodos o bloques, por más que permanezca por debajo del límite
duro original.
El límite duro no es permisivo, sino siempre más radical en su accionar, pues incluso cuando el usuario no ha cumplido el tiempo
de gracia éste no podrá jamás consumir más inodos o bloques de los que el límite duro le permite.
Finalmente una vez alcanzado el límite duro, el usuario tiene la posibilidad de reducir su consumo de inodos o bloques hasta
decaer por debajo del límite blando momento en el cual se elimina el tiempo de gracia.
Cabe resaltar que las cuotas por inodos o bloques no son aplicables a root, es decir no le afectan, este usuario siempre podrá
consumir por encima de cualquier límite que se le configure.
Configuración de cuotas
Los pasos a seguir para configurar nuestro sistema con soporte de cuotas de usuario y grupo se resumen a continuación:
1. Montar el sistema de archivos con las opciones usrquota y grpquota

2. Inicializar los archivos de cuotas en el sistema de archivos
3. Encender el control de cuotas para el sistema de archivos
4. Editar las cuotas de usuario y/o grupo, y los tiempos de gracia.
Paso 1:
Sobre el sistema de archivos en el cual deseamos activar el soporte de cuotas, configurar su respectiva entrada en /etc/fstab como
sigue:
/dev/hdb2 /datos ext3 defaults,usrquota,grpquota 0 0
OpenSourceCollege
Linux for SysAdmins
Página 80
Source Linux
Paso 2:
La herramienta quotacheck nos permite crear los archivos de cuotas (aquota.user y aquota.group) en la raíz del sistema de archivos.
Asimismo es recomendable ejecutar esta herramienta periódicamente para verificar la consistencia de los archivos de cuota y corregir
en ellos cualquier error encontrado.
La forma en que debemos invocar quotacheck para este propósito es como sigue:
# quotacheck -avug
Tras ejecutar este comando debemos verificar en la raíz del sistema de archivos que se haya creado los archivos aquota.user y
aquota.group. Es necesario mantener las cuotas apagadas en un sistema de archivos antes de ejecutar quotacheck sobre él.
El uso de esta herramienta se puede revisar a detalle en quotacheck(8)
Paso 3:
El procedimiento para encender las cuotas se hace a través de la herramienta quotaon cuya forma de uso para nuestro requerimiento
debe ser:
# quotaon /dev/hdb2
Para apagar las cuotas usamos la herramienta quotaoff. Ambas herramientas tienen una sintaxis de uso como la siguiente:
quotaon, quotaoff [opciones] <sistema de archivos>

Enciende o apaga las cuotas en sistemas de archivos
Opciones:
-a : Encender/apagar las cuotas en todos los sistemas de archivos con la opción auto, usrquota y/o grpquota definidos en
/etc/fstab
-u : Permite encender/apagar cuotas de usuario (por defecto).
-g : Permite encender/apagar cuotas de grupo.
-p : En vez de encender o apagar las cuotas, muestra información de su estado (si están en ON u OFF)
Paso 4:
La edición de cuotas de usuario, grupo y los tiempos de gracia es posible a través del uso de la herramienta edquota, cuya sintaxis de
uso se muestra debajo:
edquota [opciones] <sistema de archivos>

Edita las cuotas de usuarios y/o grupos
Opciones:
-u USER : Edita las cuotas de usuario (por defecto).

-g : Edita las cuotas de grupo.
-f FS : Edita las cuotas únicamente para el sistema de archivos indicado en FS. Si se omite esta opción se edita las cuotas para
todos los sistemas de archivos que tengan soporte de cuotas.
-t : En lugar de editar las cuotas de usuario y/o grupo, permite configurar los tiempos de gracia para cada sistema de archivos.
Esta herramienta utiliza el editor de textos definido en la variable de entorno EDITOR.
Por tanto para editar las cuotas del usuario admin invocaremos el siguiente comando:
# edquota -u admin
El contenido del archivo que se nos abrirá en el editor de textos predeterminado tiene la siguiente forma:
Sistema de Bloques Límite blando de Límite duro de Límite blando de Límite duro de
Inodos utilizados
archivos utilizados bloques bloques inodos inodos
De donde debemos tener en cuenta que:
1. Cada uno de los campos está separado por espacios en blanco o tabulaciones.
2. Las columnas 1 (sistema de archivos), 2 (bloques utilizados) y 5 (inodos utilizados) son sólo informativas, no pueden
modificarse.
Luego que nosotros hagamos los cambios necesarios a las columnas de nuestro interés (límites blandos o duros de inodos y/o
bloques, no necesitamos modificar todos) guardamos los cambios en el editor y salimos de éste, momento en el cual ya se reflejarán
OpenSourceCollege
Linux for SysAdmins
Página 81
Source Linux
en el sistema los cambios hechos con edquota -u.
Para editar el tiempo de gracia invocaremos el siguiente comando:
# edquota -t
El contenido del archivo que se nos abrirá en el editor de textos predeterminado tiene la siguiente forma:
Sistema de archivos Tiempo de gracia para bloques Tiempo de gracia para inodos
De donde debemos tener en cuenta que:
1. Cada uno de los campos está separado por espacios en blanco o tabulaciones.
2. La columna 1 (sistema de archivos) es sólo informativa, no puede modificarse.
Luego que nosotros hagamos los cambios necesarios a las columnas de nuestro interés (tiempo de gracia de bloques y/o inodos, no
necesitamos modificar todos) guardamos los cambios en el editor y salimos de éste, momento en el cual ya se reflejarán en el sistema
los cambios hechos con edquota -t.
OpenSourceCollege
Linux for SysAdmins
Página 82
Source Linux
1. Crear el directorio /tmp/test y copiar dentro el contenido del directorio /boot. Luego crear el usuario alumno que no sea capaz
de iniciar sesión en línea de comandos pero sí vía FTP, además que use el directorio /tmp/test como esqueleto de su
directorio personal.
2. Habilitar el acceso vía Shell al usuario alumno y configurar su cuenta para que cambie su contraseña en el próximo inicio de
sesión.
3. Crear el grupo sistemas, los usuarios docente, invitado y turista. Asignar al usuario alumno como administrador del grupo
sistemas. Luego ejecutando una sesión del usuario alumno incluir a docente e invitado como miembros y además configurar
el acceso de usuarios externos a este grupo a través de una contraseña.
Intentar unir el usuario turista al grupo sistemas tras comprobar la configuración anterior solicitada.
4. Sin cerrar manualmente la sesión abierta del usuario alumno, eliminar a este último usuario y su directorio personal.
5. Asumiendo que el directorio personal del usuario docente es /home/docente y /home está montado como una partición /dev/sda3
separada de la raíz (/dev/sda2), configurarle su cuota de con límites duros de 100 elementos y 10 MB de espacio en disco, y
con límites blandos que sean el 90% de los límites duros.
Iniciar sesión con el usuario docente y someter a prueba los límites de cuota creando archivos de 1 MB, 3 MB, 5 MB y así
sucesivamente archivos mayores hasta alcanzar los límites duros y blandos.
6. Configurar el sistema para que la cuenta del usuario docente expire el 31 de Diciembre del 2009 a través de la edición
manual directa del archivo /etc/shadow. No utilizar los comandos passwd ni chage para lograr este objetivo.
7. Deshabilitar la cuenta del usuario docente a través de la edición manual directa del archivo /etc/shadow. No utilizar los
comandos passwd ni chage para lograr este objetivo.
OpenSourceCollege
Linux for SysAdmins
Página 83
Source Linux
1. Crear el directorio /tmp/test y copiar dentro el contenido del directorio /boot. Luego crear el usuario alumno que no sea capaz
de iniciar sesión en línea de comandos pero sí vía FTP, además que use el directorio /tmp/test como esqueleto de su
directorio personal.
+ Creamos el directorio /tmp/test y su contenido:
# mkdir /tmp/test
# cp -r /boot/* /tmp/test
+ Creamos el usuario con una shell inválida como /bin/false:
# useradd -s /bin/false -md /home/alumno -k /tmp/test alumno
2. Habilitar el acceso vía Shell al usuario alumno y configurar su cuenta para que cambie su contraseña en el próximo inicio de
sesión.
+ Le cambiamos la shell a una válida:
# usermod -s /bin/bash alumno
+ En Debian se puede forzar la expiración inmediata de la contraseña así:
# passwd -e alumno
+ En Red Hat se podría expirar la contraseña asignando un periodo de duración máxima de la contraseña que sea menor a
la cantidad de días transcurridos desde el último cambio de contraseña del usuario que nosotros le alteremos.
El siguiente comando asume que nuestra fecha actual es 15 de Noviembre del 2009:
# chage -d "2009-11-01" -M 10 alumno
3. Crear el grupo sistemas, los usuarios docente, invitado y turista. Asignar al usuario alumno como administrador del grupo
sistemas. Luego ejecutando una sesión del usuario alumno incluir a docente e invitado como miembros y además configurar
el acceso de usuarios externos a este grupo a través de una contraseña.
Intentar unir el usuario turista al grupo sistemas tras comprobar la configuración anterior solicitada.
+ Creamos el grupo y usuarios solicitados:
# groupadd sistemas
# useradd -m docente
# useradd -m invitado
# useradd -m turista
+ Definimos a alumno como administrador de sistemas:
# gpasswd -A alumno sistemas
+ Nos convertimos en el usuario alumno y agregamos miembros al grupo sistemas:
# su – alumno
$ gpasswd -a docente sistemas
$ gpasswd -a invitado sistemas
+ Asignamos un password al grupo:
$ gpasswd sistemas
+ Nos convertimos en el usuario turista e intentamos ingresar a sistemas:
$ exit
# su – turista
$ newgrp sistemas
4. Sin cerrar manualmente la sesión abierta del usuario alumno, eliminar a este último usuario y su directorio personal.
+ Para eliminar el usuario alumno éste debe primero cerrar su sesión o debemos forzar su salida matando sus procesos.
OpenSourceCollege
Linux for SysAdmins
Página 84
Source Linux
Según el requerimiento sólo nos queda optar por lo segundo:
# killall -9 -u alumno
# userdel -r alumno
5. Asumiendo que el directorio personal del usuario docente es /home/docente y /home está montado como una partición /dev/sda3
separada de la raíz (/dev/sda2), configurarle su cuota de con límites duros de 100 elementos y 10 MB de espacio en disco, y
con límites blandos que sean el 90% de los límites duros.
Iniciar sesión con el usuario docente y someter a prueba los límites de cuota creando archivos de 1 MB, 3 MB, 5 MB y así
sucesivamente archivos mayores hasta alcanzar los límites duros y blandos.
+ Remontamos /home con soporte de cuotas:
# mount -o remount,usrquota /home
+ Configuramos la cuota del usuario a los valores requeridos:
# quotacheck -vu /dev/sda3

# quotaon /dev/sda3
# edquota -u docente
Filesystem blocks soft hard inodes soft hard

/dev/hdb2 0 9216 10240 0 90 100
+ Ahora creamos archivos de 1 MB, 3 MB y cada vez mayores hasta alcanzar los límites definidos:
# su – docente
$ pwd
/home/docente
$ dd if=/dev/zero of=archivo.00 bs=1M count=1
6. Configurar el sistema para que la cuenta del usuario docente expire el 31 de Diciembre del 2009 a través de la edición
manual directa del archivo /etc/shadow. No utilizar los comandos passwd ni chage para lograr este objetivo.
+ Dado que los campos de fecha en /etc/shadow está expresado en días desde el 1ro. de Enero de 1970, debemos hacer el
cálculo de días transcurridos desde esa fecha hasta el 31 de Diciembre del 2009 con un formato manual del comando date:
# SEGUNDOS=$(date -d "12/31/2009" +%s)

# echo $(( $SEGUNDOS / 86400))
+ Al ver la salida del comando anterior tenemos ya el valor para colocarlo en el campo número 8 (penúltimo) del archivo
/etc/shadow:
7. Deshabilitar la cuenta del usuario docente a través de la edición manual directa del archivo /etc/shadow. No utilizar los
comandos passwd ni chage para lograr este objetivo.
+ Este procedimiento es tan sencillo como editar el segundo campo del archivo /etc/shadow y colocar al inicio del mismo dos
veces el signo de exclamación (!!).
OpenSourceCollege
Linux for SysAdmins
Página 85
Source Linux
Unidad 5: Seguridad local
5.1. Objetivos
✔ Entender el significado de cada uno de los permisos UNIX básicos.

✔ Comprender la importancia de los permisos especiales SUID, SGID y Sticky Bit.
✔ Utilizar correctamente las herramientas de modificación de permisos y propietarios de archivos.
✔ Entender y manejar correctamente las herramientas de permisos granulares a través de Access Control Lists.
✔ Saber utilizar las herramientas de ejecución de comandos con privilegios distintos, como su y sudo.
5.2. Permisos y propietarios

Antecedentes
Como ya se sabe, los sistemas UNIX son sistemas multitarea/multiusuario. A diferencia del sistema operativo MSDOS (por ejemplo),
estos sistemas operativos tienen la capacidad de tener a más de un usuario dentro del sistema, tanto localmente como remotamente.
Por lo tanto para proteger la privacidad de los archivos y directorios de cada uno de ellos, para proteger ciertos archivos elementales
para el buen funcionamiento de la máquina, y para una buena organización del sistema (aparte de otras muchas razones), tenemos a
nuestra disposición los llamados permisos.
Como se debe recordar, en una computadora con el sistema operativo MSDOS o Windows 9x (95, 98 y Me), cualquier persona que
acceda a ella puede en cualquier momento borrar todo el disco duro.
Conceptos básicos de permisos en UNIX

Es necesario tener en cuenta las siguientes observaciones importantes para lograr una mejor comprensión de los futuros temas a
tratar:
• Cada usuario puede pertenecer a varios grupos, pero sólo uno de ellos representa su grupo primario.
• Cuando un usuario crea un proceso, archivo o directorio se le transmiten a ellos la propiedad del usuario y grupo (primario)
propietario. Así el usuario admin cuyo grupo primario es users, al crear un archivo prueba.txt éste tendrá al usuario admin y
grupo users como propietario.
• La propiedad de usuario y grupo propietario que se aplica sobre procesos, archivos o directorios se da en base al UID y GID
y no en base al nombre del usuario. Un usuario puede ser renombrado sin afectar la propiedad de sus archivos, pero si se le
asigna un nuevo UID será necesario reflejar ese nuevo propietario sobre sus archivos.
• El usuario root pasa por encima de cualquier interpretación de permisos o propietarios. Es decir puede modificar archivos con
permisos de sólo lectura, puede leer y alterar archivos que no son de su propiedad, puede cambiar el propietario de archivos
y directorios que no son suyos, puede eliminar archivos, directorios y procesos ajenos, etc.
• En un sistema UNIX existen tres formas básicas de tratar un archivo: leerlo (read, r), escribirlo (write, w) o ejecutarlo
(execute, x). Estos representan la base de los permisos UNIX tradicionales que estamos próximos a estudiar.
• En un sistema UNIX la interpretación de la propiedad de los archivos y directorios se resume en tres clases: usuario (user),
grupo (group) y otros (others). Para cada una de estas clases de definen permisos de archivos. Así por ejemplo los permisos
de usuario pueden ser de lectura y escritura, los permisos de grupo de sólo lectura y los permisos de otros ser nulos (no
tienen ningún permiso).
• La representación de los permisos se hace generalmente a través de caracteres (r, w, x, s, t) y su equivalente numérico octal,
como se resume en la siguiente tabla:
Permiso Caracter Valor octal

Lectura r 4
Escritura w 2
Ejecución x 1
SUID s 4
SGID s 2
Sticky Bit t 1
OpenSourceCollege
Linux for SysAdmins
Página 86
Source Linux
• Los permisos básicos (r, w y x) se definen siempre como una terna en el orden rwx, no se admite nunca una expresión de
permisos tal como wrx, rrw, xrw o cualquier forma distinta. Su representación octal se hace a través de la suma de los
valores numéricos de cada uno de los permisos. Ejm: rwx = 7, r-- = 4, rw- = 6
• La cadena rwx expresa la presencia de los 3 permisos, pero se puede expresar la ausencia de uno o más de ellos
reemplazando su respectiva letra por el caracter -
• Dado que la propiedad de los archivos se expresa a través de tres clases de usuario (user, group y others) entonces la
expresión completa de los permisos de un archivo se hace a través de tres ternas rwx, como sigue:
Usuario (user) Grupo (group) Otros (others)

rwx rwx rwx
• La expresión completa de los permisos en forma octal se realiza a través de la suma de los valores numéricos de cada uno
de los permisos por clase de usuario. Ejm: rwxrwxrwx = 777, rw-r--r-- = 644, rw-r----- = 640
• Los permisos especiales (SUID = s, SGID = s, y Sticky Bit = t) no se suelen expresar como una cuarta terna visible, sino
como una casi oculta. Se le llama así pues la ubicación de los caracteres que representan estos permisos se da en las
mismas posiciones que las clases de usuarios user, group y others como se muestra en la tabla de abajo:
Permisos
SUID SGID Sticky Bit
especiales
Permisos
Usuario (user) Grupo (group) Otros (others)
básicos
rwx rwx rwx
s s t
Esta tabla no quiere decir que los permisos se muestran en 2 niveles o 2 líneas, sino que se pretende explicar que el permiso
SUID (caracter 's') se coloca en la misma posición que el permiso de ejecución (caracter 'x') de la clase user, el permiso
SGID (caracter 's') se coloca en la misma posición que el permiso de ejecución (caracter 'x') de la clase group y el permiso
Sticky Bit (caracter 't') se coloca en la misma posición que el permiso de ejecución (caracter 'x') de la clase others.
• En ausencia de cualquiera de los permisos especiales su ubicación en las tres ternas no se hace notar. Pero cuando uno de
ellos está presente se reemplaza el caracter 'x' (si es que el permiso de ejecución está presente) por el caracter 's' para SUID
y SGID, o por el caracter 't' para Sticky Bit.
Si en lugar del caracter 'x' existía un guión '-' (si es que el permiso de ejecución estaba ausente) entonces éste se reemplaza
por un caracter 'S' (mayúscula) para SUID y SGID o por un caracter 'T' (mayúscula) para Sticky Bit.
• La notación octal de los permisos normalmente se da a través de 3 números (Ejm: 644) como se explicó líneas arriba cuando
no existe ninguno de los permisos especiales activos. Sin embargo en presencia de alguno de estos permisos especiales la
expresión octal cambia ahora para estar formado por 4 números donde el primero de la izquierda representa la suma de los
permisos SUID, SGID y Sticky Bit. (Ejm: 4750, 6644, 0640).
Cierto es que la interpretación de los caracteres que representan los permisos puede resultar algo confusa o complicada en un inicio,
pero tras una lectura repetida, detallada de este apartado y el análisis de las siguientes imágenes debería quedar más claro la
comprensión de los permisos:
OpenSourceCollege
Linux for SysAdmins
Página 87
Source Linux
Fig. 5.1: Expresión binaria de los permisos básicos y especiales
Fig. 5.2: Cómo la expresión binaria se convierte en el valor octal
Fig. 5.3: Cálculo de los permisos totales en formato octal
Significado de los permisos

Los permisos que hemos visto hasta ahora tienen un significado distinto sobre archivos y directorios como abajo se puede notar:
Permiso Significado aplicado sobre archivos Significado aplicado sobre directorios

Lectura Se puede leer su contenido. Se puede listar los archivos y directorios que hay dentro
Se puede modificar lo que hay dentro: crear, renombrar o
Escritura Se puede modificar su contenido. eliminar archivos y/o directorios que incluso no nos
pertenecen
Se puede entrar en él (comando cd) y consultar la
Ejecución Se puede ejecutar el archivo como una aplicación. información (atributos) de archivos y/o directorios que hay
dentro
OpenSourceCollege
Linux for SysAdmins
Página 88
Source Linux
Se puede ejecutar el archivo con los privilegios de su
SUID No tiene ningún efecto
usuario propietario.
Se puede ejecutar el archivo con los privilegios de su grupo Obliga que los archivos y/o directorios creados dentro
SGID
propietario. hereden el grupo propietario del directorio con SGID.
Previene que usuarios con permiso de escritura en un
Mantiene los archivos executables en memoria, no los directorio borren o eliminen archivos y/o directorios que no
Sticky Bit
manda a memoria de intercambio si están inactivos. les pertenecen. El propietario del directorio sí podrá borrar
y eliminar archivos y/o directorios ajenos.
Listado detallado de archivos:

Este no es el apartado más apropiado para explicar el formato del listado detallado del comando ls pero dada la cercana relación que
existe con la interpretación de permisos UNIX aprovechamos para incluir estas líneas de documentación.
Un listado detallado tiene la siguiente forma:
-rw-r--r-- 1 root root 85660 nov 4 23:33 config-2.6.26-2-amd64

drwxr-xr-x 2 root root 1024 nov 11 00:38 grub
-rw-r--r-- 1 root root 8912521 nov 11 05:44 initrd.img-2.6.26-2-amd64
-rw-r--r-- 1 root root 7883456 nov 11 00:38 initrd.img-2.6.26-2-amd64.bak
drwx------ 2 root root 12288 nov 10 13:23 lost+found
-rw-r--r-- 1 root root 1225639 nov 4 23:33 System.map-2.6.26-2-amd64
-rw-r--r-- 1 root root 1755696 nov 4 23:32 vmlinuz-2.6.26-2-amd64
Donde:
1. La 1ra. columna define el tipo de archivo y los permisos UNIX. El 1er. caracter de esta columna representa el tipo de archivo
cuyos posibles valores son:
d Directorio
b Dispositivo de bloques
c Dispositivo de caracteres
l Enlace simbólico
p Archivo FIFO
s Socket
- Archivo ordinario
Los caracteres desde la 2da. posición hasta la 10ma. (9 en total) representan las ternas de permisos para usuario, grupo y
otros.
2. La 2da. columna indica la cantidad de enlaces duros que tiene el archivo.
3. La 3ra. columna indica el usuario propietario del archivo o directorio.
4. La 4ta. columna indica el grupo propietario del archivo o directorio.
5. La 5ta. columna indica el tamaño del archivo o directorio.
6. La 6ta., 7ma. y 8va. columna indican la fecha y hora de la última modificación del archivo o directorio.
7. La 9na. columna indica el nombre del archivo o directorio.
Ejemplo 21:
Traducción de los permisos a su forma numérica octal:
• rwxrw-r-- = 0764
• rwsr-xr-x = 4755
• rwsr-S--x = 6741
• r-xr-srwt = 3557
• rwxrwxrwt = 1777
• rwsrwSr-T = 7764
Interpretación de permisos asumiendo que el usuario y grupo propietario es admin y users respectivamente:
Permiso Significado aplicado en archivo Significado aplicado en directorio
OpenSourceCollege
Linux for SysAdmins
Página 89
Source Linux
• El usuario admin puede ingresar al directorio, listar su
contenido y crear, eliminar y renombrar lo que hay
dentro.
• El usuario admin puede leer, modificar y ejecutar el
archivo. • El grupo users puede listar los archivos que hay dentro
rwxrw-r-- mas no ver consultar sus atributos. Como carece de
• El grupo users puede leer, modificar mas no ejecutar el
ejecución tampoco puede aprovechar en absoluto el
archivo.
permiso de escritura para crear, eliminar y/o renombrar
• El resto de usuarios (otros) sólo pueden leer el archivo. elementos dentro.
• El resto de usuarios (otros) sólo pueden leer listar los
archivos que hay dentro mas no ver sus atributos.

• El usuario admin puede leer, modificar y ejecutar el contenido y crear, eliminar y renombrar lo que hay
archivo. dentro.
• El grupo users puede leer y ejecutar mas no modificar • El grupo users puede listar los archivos que hay dentro
rwsr-xr-x el archivo. y consultar sus atributos, pero no puede modificar nada
• El resto de usuarios (otros) puede leer y ejecutar mas dentro (ni crear, renombrar ni eliminar).
no modificar el archivo. • El resto de usuarios (otros) puede listar los archivos
• Los usuarios que ejecuten este archivo lo harán con que hay dentro y consultar sus atributos, pero no puede
los privilegios del usuario admin. modificar nada dentro (ni crear, renombrar ni eliminar).
• El permiso SUID es ignorado.
• El usuario admin puede leer, modificar y ejecutar el
contenido y crear, eliminar y renombrar lo que hay
archivo.
dentro.
• El grupo users puede sólo leer, mas no modificar ni
• El grupo users sólo puede leer listar los archivos que
ejecutar el archivo. Cualquier otro usuario que ejecute
rwsr-S--x hay dentro mas no ver sus atributos ni ingresar al
este archivo lo hará con los privilegios del grupo users.
directorio. Cualquier archivo o directorio creado dentro
• El resto de usuarios (otros) puede ejecutar mas no leer heredará el grupo propietario de este directorio padre.
ni modificar el archivo.
• El resto de usuarios (otros) puede sólo puede ingresar
• Los usuarios que ejecuten este archivo lo harán con al directorio, nada más.
los privilegios del usuario admin.
• El permiso SUID es ignorado.
• El usuario admin puede leer y ejecutar el archivo, mas contenido mas no crear, eliminar ni renombrar lo que
no modificarlo. hay dentro.
• El grupo users puede leer y ejecutar el archivo, mas no • El grupo users puede ingresar al directorio y listar su
modificarlo. contenido mas no crear, eliminar ni renombrar lo que
hay dentro. Cualquier archivo o directorio creado dentro
r-xr-srwt • El resto de usuarios (otros) puede leer, modificar y heredará el grupo propietario de este directorio padre.
ejecutar el archivo.
• El resto de usuarios (otros) puede ingresar al directorio,
• Los usuarios que ejecuten este archivo lo harán con los listar su contenido y ver los atributos de lo que hay
privilegios del grupo users. dentro.
• Este archivo se mantendría más tiempo en memoria • Los usuarios con permiso de escritura (otros) pueden
física durante su ejecución. crear archivos o directorios dentro, pero sólo renombrar
y eliminar sus propios archivos mas no ajenos.

contenido y crear, eliminar o renombrar lo que hay
• El usuario admin puede leer, modificar y ejecutar el dentro.
archivo. • El grupo users puede ingresar al directorio, listar su
• El grupo users puede leer, modificar y ejecutar el contenido y crear, eliminar o renombrar lo que hay
rwxrwxrwt archivo. dentro.
• El resto de usuarios (otros) puede leer, modificar y • El resto de usuarios (otros) puede ingresar al directorio,
ejecutar el archivo. listar su contenido y ver los atributos de lo que hay
• Este archivo se mantendría más tiempo en memoria dentro.
física durante su ejecución. • Todos los usuarios pueden crear archivos o directorios
dentro, pero sólo renombrar y eliminar sus propios
archivos mas no ajenos.
rwsrwSr-T • El usuario admin puede leer, modificar y ejecutar el • El usuario admin puede ingresar al directorio, listar su
archivo. Cualquier usuario que ejecute este archivo lo contenido y crear, eliminar o renombrar lo que hay
hará con los privilegios del usuario admin. dentro.
• El grupo users puede leer y modificar el archivo mas no • El grupo users puede listar los archivos que hay dentro
ejecutarlo. mas no ver consultar sus atributos. Como carece de
• El resto de usuarios (otros) puede leer el archivo mas ejecución tampoco puede aprovechar en absoluto el
no modificarlo ni ejecutarlo. permiso de escritura para crear, eliminar y/o renombrar
elementos dentro.
OpenSourceCollege
Linux for SysAdmins
Página 90
Source Linux
• El resto de usuarios (otros) puede listar el contenido del
directorio, pero no ver los atributos de lo que hay
dentro ni ingresar al directorio.
• Este archivo se mantendría más tiempo en memoria • El permiso SUID es ignorado.
física durante su ejecución. • Los usuarios con permiso de escritura (usuario y grupo)
pueden crear archivos o directorios dentro, pero sólo
renombrar y eliminar sus propios archivos mas no
ajenos.
Herramientas de gestión de permisos y propietarios

Las herramientas chmod, umask, chown y chgrp son las que utilizaremos para gestionar correctamente los permisos de los archivos
y sus usuarios o grupos propietarios. El detalle de estas herramientas lo veremos líneas abajo.
La herramienta chmod permite asignar permisos a archivos y/o directorios de la siguiente forma:
chmod [opciones] <modo> <fichero> ...

Modifica los permisos de acceso a ficheros
Opciones:
-c : Muestra un aviso sólo para los ficheros que realmente cambiaron sus permisos.
-f : No muestra mensajes de error por ficheros a los que no se le pudieron cambiar sus permisos.
-v : Informa de cada acción efectuada o no sobre los ficheros.
-R : Cambia de forma recursiva los permisos de directorios y sus contenidos.
La interpretación de los permisos que se asignarán a los ficheros se hace a través de modo que tiene una notación simbólica y una
notación octal.
La notación octal se hace a través de la expresión de un número que tenga entre 1 y 4 dígitos (entre 0 y 7). Los dígitos que falten
para completar el grupo de cuatro se han de completar con ceros iniciales (desde la izquierda).
La notación simbólica tiene la siguiente forma:
[ugoa][+-=][rwxst]
Donde el primer grupo de caracteres hace referencia a la clase de usuario (u = user, g = group, o = other, a = all), el segundo grupo la
operación de modificación de permisos (+ agrega permisos, - remueve permisos, = asigna permisos igual a ...) y el último grupo
representa los permisos a aplicar (r = lectura, w = escritura, x = ejecución, s = SUID/SGID, t = Sticky Bit).
Se pueden representar varios modos en notación simbólica cada uno separado por comas.
La herramienta umask permite definir los permisos que tendrán los archivos y/o directorios automáticamente al crearse. Esto se hace
definiendo un valor de máscara que resta de los permisos por defecto para archivos (0666) o directorios (0777) para así obtener los
permisos resultantes para ficheros a punto de crearse.
umask [opciones] [máscara]

Define la máscara de creación de ficheros
Opciones:
-S : Muestra la máscara con una notación simbólica
Si se omite máscara entonces sólo muestra la actual, no la cambia. Debe tenerse en cuenta que las máscaras cualquiera sea la
combinación creada nunca permite crear archivos con permisos de ejecución, ni archivos y/o directorios con permisos especiales
(SUID, SGID o Sticky Bit).
Las herramientas chown y chgrp permiten cambiar el usuario y/o grupo propietario de archivos como abajo se muestra:
chown [opciones] <usuario>[:grupo] <fichero> ...

Modifica el usuario y/o grupo propietario de ficheros
Opciones:
-c : Muestra un aviso sólo para los ficheros que realmente cambiaron sus propietarios.
-f : No muestra mensajes de error por ficheros a los que no se le pudieron cambiar sus propietarios.
OpenSourceCollege
Linux for SysAdmins
Página 91
Source Linux
-R : Cambia de forma recursiva los propietarios de directorios y sus contenidos.
Como se muestra en la sintaxis esta herramienta permite cambiar el usuario y también el grupo propietario de ficheros usando el
símbolo : como separados entre usuario y grupo.
chgrp [opciones] <grupo> <fichero> ...

Modifica el grupo propietario de ficheros
Opciones:
-c : Muestra un aviso sólo para los ficheros que realmente cambiaron sus propietarios.
-f : No muestra mensajes de error por ficheros a los que no se le pudieron cambiar sus propietarios.
-R : Cambia de forma recursiva los propietarios de directorios y sus contenidos.
Como se muestra en la sintaxis esta herramienta sólo permite cambiar el grupo propietario de ficheros.
Ejemplo 22:
a) Dado el archivo file.txt con permisos 0664, agregarle permisos de ejecución al usuario y al grupo, quitarle escritura al grupo y
remover todo permiso de otros usuarios.
Se puede hacer de la siguientes formas equivalentes:
$ chmod 750 file.txt

$ chmod ug+x,g-w,o-r file.txt
$ chmod u=rwx,g=rx,o= file.txt
b) Quitar todo permiso a todos los archivos del directorio /home a todos los usuarios que no tengan ningún vínculo de propiedad sobre
los ficheros.
# chmod -R o= /home
c) Establecer la máscara de creación de ficheros para nuestro usuario actual de modo que sólo nosotros podamos leerlos y/o
modificarlos (en caso de archivos) o ingresar a ellos (en caso de directorios); ni el grupo ni otros tendrán permiso alguno sobre estos
ficheros próximos a crearse.
Se puede hacer de la siguientes formas equivalentes:
$ umask u=rwx,g=,o=
$ umask 0077
d) Consultamos ahora que la máscara actual sea la adecuada:
$ umask -S
$ umask
e) Cambiamos la propiedad del directorio /home/administrador (y todo su contenido) al usuario admin y grupo usuarios:
# chown -R admin:usuarios /home/administrador
f) Dado que el archivo /etc/shadow puede ser leído sólo por root, intentaremos explicar el uso del SUID con un caso práctico. Primero
consultamos los permisos y propiedad del archivo /bin/cat, luego utilizando esta herramienta procuraremos ver el archivo /etc/shadow:
$ ls -l /bin/cat
-rwxr-xr-x 1 root root 32136 abr 4 2008 /bin/cat
$ cat /etc/shadow
cat: /etc/shadow: Permiso denegado
Ahora como sabemos que el propietario del comando cat es root, podemos aprovechar esto para darle SUID a este binario y permitir
que cualquier usuario que ejecute el comando cat lo haga con privilegios de root para así tener acceso de lectura al archivo
/etc/shadow:
# chmod u+s /bin/cat

$ ls -l /bin/cat
-rwsr-xr-x 1 root root 32136 abr 4 2008 /bin/cat
OpenSourceCollege
Linux for SysAdmins
Página 92
Source Linux
$ cat /etc/shadow
Ahora que comprobamos que resultó el uso del SUID en el binario cat, por seguridad eliminamos este permiso especial:
# chmod u-s /bin/cat

$ cat /etc/shadow
Permisos avanzados con Access Control Lists (ACL)
El sistema tradicional de gestión de permisos en UNIX basados únicamente en el usuario, grupo y otros en muchos casos puede
resultar insuficiente para situaciones en las que se requiere un control más granular y afinado.
Por ejemplo la necesidad de dar permiso de lectura sólo a 3 usuarios y permiso de escritura sólo a 2 grupos específicos no puede ser
atendida con los permisos básicos hasta ahora estudiados.
Es por ello que aparecen las Listas de Control de Acceso (Access Control List en inglés) conocidas comúnmente sólo como ACL, las
que permiten lograr este nivel de permisos granulares en archivos y/o directorios.
Para hacer uso de la funcionalidad de ACL en nuestro sistema requerimos que el kernel lo soporte (viene por defecto activado en toda
distribución Linux moderna), y además el sistema de archivos (sobre el cual queremos hacer uso de las ACL) lo soporte desde el
momento de su montaje (opción acl del comando mount o en el archivo /etc/fstab).
Asumiendo que ambos requisitos ya son cumplidos en el sistema usaremos las herramientas getfacl y setfacl para consultar y
modificar las ACL de ficheros.
Consultas de ACL
A través de un listado detallado (ls -l) podemos saber qué ficheros tienen atributos de ACL al encontrar el símbolo + junto a los
permisos de la primera columna. Nótese el siguiente listado:
$ ls -l
drwx------ 2 angel angel 4096 nov 17 09:20 amsn_received
drwxr-xr-x+ 2 angel angel 4096 oct 17 21:48 compartido
drwxr-x---+ 8 angel angel 12288 nov 18 10:26 Descargas
drwxr----- 2 angel angel 4096 oct 11 15:01 Desktop
drwxr-x---+ 9 angel angel 4096 nov 6 22:05 Documents
lrwxrwxrwx 1 angel angel 22 jul 26 12:50 Imagenes -> /data/varios/Imagenes/
drwxr-x--- 7 angel angel 4096 jul 22 01:54 LimeWire
Podemos apreciar que los directorios compartido, Descargas y Documents poseen ciertos atributos de ACL debido al signo + que figura
junto a sus permisos.
Una vez que deseamos consultar las entradas ACL de los ficheros usaremos la herramienta getfacl cuya sintaxis de uso se muestra
debajo:
getfacl [opciones] <fichero> ...

Consulta las ACL de ficheros
Opciones:
-d : Muestra sólo la ACL por defecto de directorios

-R : Lista de forma recursiva las ACL de archivos, directorios y sus contenidos
La forma que por defecto tiene la salida de esta herramienta es la siguiente:
1: # file: file.txt
2: # owner: admin
3: # group: usuarios
4: user::rwx
5: user:mruiz:rwx #effective:r-x
6: group::rwx #effective:r-x
7: group:alumnos:r-x
8: mask:r-x
9: other:r-x
10: default:user::rwx
11: default:user:mruiz:rwx #effective:r-x
12: default:group::r-x
13: default:mask:r-x
14: default:other:---
Las líneas 1, 2 y 3 corresponden a la cabecera de información que contiene el nombre del archivo, el usuario propietario y grupo
propietario.
Las líneas 4, 6 y 9 corresponden a los permisos de las clases usuario, grupo y otros.
OpenSourceCollege
Linux for SysAdmins
Página 93
Source Linux
Las líneas 5 y 7 representan los permisos para los usuarios (mruiz) y grupos (alumnos) nombrados
La línea 8 representa la máscara de permisos efectivos que puede tener cualquier usuario nombrado o grupo. El usuario propietario y
otros usuarios no son afectados por esta máscara.
Las líneas de la 10 a la 14 representan las entradas ACL por defecto de este directorio. Los directorios pueden tener ACL por defecto,
pero no los archivos.
Modificaciones de ACL
Cuando se desea modificar las entradas ACL de los ficheros usaremos la herramienta setfacl cuya sintaxis de uso se muestra
debajo:
setfacl [opciones] <fichero> ...

Modifica las ACL de ficheros
Opciones:
-b : Remueve todas las entradas ACL de ficheros, preservando los permisos básicos de usuario, grupo y otros.
-k : Remueve las entradas de ACL por defecto de directorios.
-d : Asigna entradas de ACL por defecto a directorios.
-R : Asigna de forma recursiva las ACL de archivos, directorios y sus contenidos
-m ACLS : Define la(s) entrada(s) ACL a asignar a los ficheros
-x ACLS : Define la(s) entrada(s) ACL a remover de los ficheros. El campo perms no debe estar presente en ACLS.
La sintaxis que tiene la definición de entradas a través de ACLS es como sigue:
[d:][ug:][usuario/grupo][:perms]
Donde d, default hace referencia a una ACL por defecto para directorios, u, user o g, group indica si se trata de un usuario o grupo la
entrada ACL, y finalmente el campo perms define en notación simbólica los permisos que se asignarán.
Ejemplo 23:
a) Administrar los permisos del archivo /tmp/test.txt -de propiedad del usuario y grupo root- de modo que el usuario admin tenga
permisos de lectura y escritura, el usuario aperez permisos de lectura, escritura y ejecución y el grupo alumnos tenga permisos de
lectura únicamente.
Comprobar que los permisos realmente se hayan aplicado sobre el archivo.
# setfacl -m u:admin:rw,u:aperez:rwx,g:alumnos:r /tmp/test.txt

# getfacl /tmp/test.txt
b) Configurar el sistema de modo tal que cualquier archivo creado dentro de /tmp (y cualquier directorio dentro) tenga permisos de
lectura y escritura por el usuario mruiz:
# setfacl -dRm u:mruiz:rw /tmp
c) Eliminar cualquier entrada de ACL que exista dentro del directorio /tmp y su contenido:
# setfacl -R -b /tmp
OpenSourceCollege
Linux for SysAdmins
Página 94
Source Linux
5.3. Ejecución privilegiada
En los sistemas UNIX es muy común el trabajar con algún usuario sin privilegios y requerir convertirse en otro usuario -por ejemplo
root- u obtener los privilegios de éste ya sea durante una sesión prolongada, breve o incluso sólo necesaria para la ejecución de uno o
más procesos específicos.
Son estas situaciones en las que un usuario puede realizar una ejecución privilegiada a través del uso de las herramientas su y sudo
que según la configuración adecuada de éstas el usuario puede lograr su propósito.
La herramienta su
Esta herramienta, su, permite ejecutar una shell con las credenciales de usuario y grupo distintas. Si se desea utilizar las credenciales
de un usuario que tiene una contraseña asignada entonces ésta será pedida a quien haga uso de su.
La sintaxis de uso de esta herramienta se muestra a continuación:
su [opciones] [usuario] [argumentos]

Ejecuta una shell con identificadores de grupo y usuario distintos
Opciones:
-c CMD : En lugar de ejecutar una shell interactiva sólo invoca al comando CMD con los privilegios del usuario especificado.
-s SH : Ejecuta la shell SH en lugar de la que tenga asignada a su cuenta el usuario al cual se intenta convertir.
-l, - : Ejecuta la shell de usuario como un inicio de sesión con login. Esto permite ejecutar los shells de inicio de sesión y
variables de entorno del usuario así como también ser ubicado en su directorio personal.
La herramienta sudo
Esta herramienta permite ejecutar un comando con las credenciales de otro usuario. Si el usuario que invoca sudo es root o si el
usuario destino es el mismo que invoca la herramienta entonces no se solicita ningún password.
De lo contrario sudo requiere que los usuarios se autentiquen con un password que por defecto es el de ellos mismos. Una vez que el
usuario se ha autenticado se actualiza una marca de tiempo y el usuario puede seguir invocando sudo sin una contraseña por un corto
periodo de tiempo (que por defecto es 15 minutos a menos que se defina algo distinto en /etc/sudoers)
A través del uso de sudo es posible determinar qué usuarios, en qué hosts, con las credenciales de quién y qué comandos pueden
invocar a través de esta herramienta. Todo esto es posible a través de la configuración del archivo /etc/sudoers.
Se recomienda no editar directamente este archivo sino hacerlo a través de la herramienta visudo la cual es capaz de detectar
sintaxis incorrecta en su contenido para poder corregirla antes de cerrar el editor (el que se defina en la variable de entorno EDITOR).
Tener en cuenta que los cambios al archivo sudoers sólo se hacen efectivos tras cerrar el editor invocado desde visudo.
La sintaxis del archivo /etc/sudoers es como sigue:
# Sección de Aliases
User_Alias <NOMBRE_ALIAS> = [!]<USUARIO|%GRUPO>, ...
Host_Alias <NOMBRE_ALIAS> = [!]<HOSTNAME>, ...
Runas_Alias <NOMBRE_ALIAS> = [!]<RUNAS>, ...
Cmnd_Alias <NOMBRE_ALIAS> = [!]<COMANDO>, ...
# Sección de especificación de usuarios
<user> <hostlist> = [(runaslist)] <[NOPASSWD:] commandlist>
Donde:
• NOMBRE_ALIAS debe ser escrito en mayúsculas.

• user puede ser uno o más nombres de usuario, nombres de grupo precedido por %, o un alias de usuario (User_Alias)
• hostlist puede ser uno o más nombres de host o un alias de host (Host_Alias)
• runaslist puede ser uno o más nombres de usuario, nombres de grupo precedido por %, o un alias de ejecución como
usuario (Runas_Alias)
• commandlist puede ser uno o más comandos o un alias de comando (Cmnd_Alias). La palabra clave NOPASSWD evita que
se pida la contraseña al usuario para ejecutar los comandos.
La sintaxis de especificación de usuarios define que... "los usuarios especificados en user pueden ejecutar comandos en los hosts
especificados en hostlist con las credenciales de los usuarios especificados en runaslist los comandos especificados en
commandlist".
Cualquiera de los campos user, hostlist, runaslist y commandlist pueden ser reemplazados por la palabra ALL que será
equivalente a cualquier valor que tengan estos campos.
OpenSourceCollege
Linux for SysAdmins
Página 95
Source Linux
Por lo general no se suele especificar nombres de hosts distintos al de nuestro propio sistema, o la palabra ALL, a menos que
pretendamos usar una configuración distribuida del archivo sudoers en la red para varios hosts.
El uso de la herramienta sudo en la línea de comandos es como sigue:
sudo [opciones] [usuario] [argumentos]

Ejecuta una shell con identificadores de grupo y usuario distintos
Opciones:
-l : Permite listar los comandos que están permitidos al usuario en el host actual.
-k : Invalida la marca de tiempo del usuario de modo que la próxima vez que se invoque a sudo se requiera contraseña.
-u USER : Especifica a través de USER cómo que usuario invocar los comandos en lugar de root.
Ejemplo 24:
a) Convertirse en el usuario root sólo para ejecutar el comando fdisk -l:
$ su - -c "fdisk -l"
La primera forma no requiere indicar la ruta completa del comando fdisk debido a que con el parámetro - se asigna el valor de PATH
que le corresponde a root y que incluye al directorio /sbin. En cambio si se omite el parámetro - como se ve abajo, sí se requiere
especificar la ruta absoluta del comando fdisk:
$ su -c "/sbin/fdisk -l"
b) Convertirse en el usuario postfix usando la shell /bin/bash sabiendo que este usuario tiene una shell deshabilitada:
# su - -s /bin/bash postfix
c) Configurar restricciones de ejecución privilegiada de modo tal que los usuarios admin y aperez tengan permisos sólo de ejecutar los
comandos shutdown, reboot, poweroff y halt:
Invocamos visudo para editar /etc/sudoers:
# visudo
... y agregamos lo siguiente:
Cmnd_Alias APAGAR = /sbin/shutdown, /sbin/reboot, /sbin/poweroff, /sbin/halt

User_Alias OPERADORES = admin, aperez
OPERADORES ALL = (root) APAGAR
Luego de guardar los cambios y salir del editor los usuarios admin y aperez pueden invocar con sus contraseñas estos comandos
como sigue:
$ sudo /sbin/shutdown -h +30

$ sudo /sbin/reboot
d) Permitir al usuario mruiz ejecutar como el usuario postgre los comandos createdb y psql sin ingresar su contraseña:
Invocamos visudo para editar /etc/sudoers:
# visudo
... y agregamos lo siguiente:
Cmnd_Alias PGCOMMANDS = /usr/bin/createdb, /usr/bin/psql
mruiz ALL = (postgre) NOPASSWD: PGCOMMANDS
Luego de guardar los cambios y salir del editor el usuario mruiz puede invocar sin contraseña los siguientes comandos:
$ sudo createdb
OpenSourceCollege
Linux for SysAdmins
Página 96
Source Linux
$ sudo psql
OpenSourceCollege
Linux for SysAdmins
Página 97
Source Linux
1. Se tiene un binario /bin/install que tiene por objetivo modificar un archivo /etc/install.conf que tiene permisos de sólo lectura y
escritura por el usuario root. Se desea que sólo los usuarios eflores y nalvarez sean los únicos capaces de alterar dicho
archivo de configuración a través del uso de /bin/install.
Indique los comandos necesarios a ejecutar para lograr cumplir este requerimiento.
2. Se tiene una aplicación Web escrita en PHP que es servida por Apache desde el directorio /var/ww//html/website. Esta
aplicación suele crear archivos y/o directorios dentro de esa ruta, y también otros usuarios tales como eflores, nalvarez y admin
suben información dentro a través de un acceso FTP provisto por el administrador.
Indique los comandos necesarios a ejecutar para que se asegure que todo archivo creado dentro de dicho directorio
pertenezca siempre al grupo apache con permisos de lectura y escritura.
3. Luego de un análisis del administrador hacia el directorio servidor por Apache en el ejemplo anterior, encontró que dentro de
esa ruta existen al menos 200 ficheros entre archivos y directorios que no tenían como grupo propietario a apache y la
aplicación Web está generando errores de permisos al intentar acceder a ellos.
Indique los comandos necesarios para corregir de forma directa los permisos sobre esos ficheros considerando que no debe
alterar los permisos de la clase del usuario ni grupo propietario de los mismos.
4. El webmaster indica que la aplicación Web requiere tener acceso a modificar los parámetros de red del sistema operativo
(asignar direcciones IP a las interfaces con ifconfig y definir la puerta de enlace del sistema con route) para lo cual exige
que el servicio Apache no sea ejecutado como el usuario apache sino como root.
¿Qué solución más segura que la solicitada por el webmaster Ud. le daría?
5. Se tiene una configuración centralizada de sudoers a través de LDAP, la cual se distribuye con este protocolo a todos los
hosts de la red dentro del dominio consultorianet.com. Se requiere limitar el acceso a los comandos postsuper y postfix sólo
en el Gateway antispam (antispam.consultorianet.com) y Servidor de Correo (mail.consultorianet.com) para los usuarios
admin y eflores.
Indique los comandos necesarios para lograr este objetivo.
OpenSourceCollege
Linux for SysAdmins
Página 98
Source Linux
1. Se tiene un binario /bin/install que tiene por objetivo modificar un archivo /etc/install.conf que tiene permisos de sólo lectura y
escritura por el usuario root. Se desea que sólo los usuarios eflores y nalvarez sean los únicos capaces de alterar dicho
archivo de configuración a través del uso de /bin/install.
Indique los comandos necesarios a ejecutar para lograr cumplir este requerimiento.
+ El binario /bin/install debería tener como propietario al usuario root y poseer el permiso SUID activo:
# chown root /bin/install

# chmod u+s /bin/install
+ Para limitar la ejecución sólo a eflores y nalvarez se podría incluir a ambos como únicos miembros de un grupo, tal como
install, y sólo a este grupo permitir la ejecución en el binario /bin/install:
# groupadd install
# usermod -g install eflores
# usermod -g install nalvarez
# chgrp install /bin/install
# chmod u=rwx,g=rx,o= /bin/install
+ Otra opción más elegante sería utilizar ACLs para este control granular y quitar el permiso de ejecución a cualquier otro
usuario sobre el binario /bin/install:
# chmod u=rwx,go= /bin/install

# setfacl -m u:eflores:rx,u:nalvarez:rx /bin/install
2. Se tiene una aplicación Web escrita en PHP que es servida por Apache desde el directorio /var/ww//html/website. Esta
aplicación suele crear archivos y/o directorios dentro de esa ruta, y también otros usuarios tales como eflores, nalvarez y admin
suben información dentro a través de un acceso FTP provisto por el administrador.
Indique los comandos necesarios a ejecutar para que se asegure que todo archivo creado dentro de dicho directorio
pertenezca siempre al grupo apache con permisos de lectura y escritura.
+ El directorio /var/www/html/website (y cualquier directorio existente dentro) debería tener como grupo propietario a apache y
poseer el permiso SGID activo para asegurar que los ficheros creados dentro hereden el grupo solicitado:
# find /var/www/html/website -type d -exec chmod g+s {} \;
+ Para asegurar que los nuevos archivos ahí creados tengan permisos de lectura y escritura para el grupo apache, haremos
uso de entradas ACL por defecto:
# setfacl -R -d -m g:apache:rw /var/www/html/website
3. Luego de un análisis del administrador hacia el directorio servidor por Apache en el ejemplo anterior, encontró que dentro de
esa ruta existen al menos 200 ficheros entre archivos y directorios que no tenían como grupo propietario a apache y la
aplicación Web está generando errores de permisos al intentar acceder a ellos.
Indique los comandos necesarios para corregir de forma directa los permisos sobre esos ficheros considerando que no debe
alterar los permisos de la clase del usuario ni grupo propietario de los mismos.
+ Simplemente se debe asignar de forma recursiva las entradas ACL necesarias:
# setfacl -R -m g:apache:rw /var/www/html/website
4. El webmaster indica que la aplicación Web requiere tener acceso a modificar los parámetros de red del sistema operativo
(asignar direcciones IP a las interfaces con ifconfig y definir la puerta de enlace del sistema con route) para lo cual exige
que el servicio Apache no sea ejecutado como el usuario apache sino como root.
¿Qué solución más segura que la solicitada por el webmaster Ud. le daría?
+ Explicar al Webmaster que debe modificar su aplicación Web para que invoque los comandos que necesita con el uso de
sudo.
+ Configurar el archivo /etc/sudoers como sigue:
Cmnd_Alias NETWORK = /sbin/ifconfig, /sbin/route
apache ALL = (root) NOPASSWD: NETWORK
OpenSourceCollege
Linux for SysAdmins
Página 99
Source Linux
5. Se tiene una configuración centralizada de sudoers a través de LDAP, la cual se distribuye con este protocolo a todos los
hosts de la red dentro del dominio consultorianet.com. Se requiere limitar el acceso a los comandos postsuper y postfix sólo
en el Gateway antispam (antispam.consultorianet.com) y Servidor de Correo (mail.consultorianet.com) para los usuarios
admin y eflores.
Indique los comandos necesarios para lograr este objetivo.
+ Configurar sudoers que se distribuye a través de LDAP como sigue:
Host_Alias MAILHOSTS = mail.consultorianet.com, antispam.consultorianet.com

Cmnd_Alias POSTCMD = /usr/sbin/postsuper, /usr/sbin/postfix
User_Alias MAILUSERS = admin, eflores
MAILUSERS MAILHOSTS = (root) POSTCMD
OpenSourceCollege
Linux for SysAdmins
Página 100
Source Linux
Unidad 6: Particionamiento avanzado
6.1. Objetivos
✔ Conocer el concepto de RAID y sus distintos niveles existentes.

✔ Entender la diferencia entre RAID a nivel de hardware y software.
✔ Saber administrar dispositivos RAID por software en Linux.
✔ Conocer el concepto de LVM y sus términos asociados.
✔ Dominar la gestión de Volume Groups, Logical Volumes y snapshots LVM.
6.2. RAID por software

Conceptos básicos de RAID
Este término proveniente de las palabras en inglés Redundant Array of Independent Disks traducido como Conjunto redundante de
discos independientes. RAID hace referencia al uso conjunto de varios discos en una configuración especial, denominada nivel, que
tiene por objetivo crear un sistema de almacenamiento que se caracterize por tener uno o más beneficios como mejor integridad,
tolerancia a fallos, rendimiento y capacidad.
La combinación que hace RAID de varios discos duros se consolida en una unidad lógica, la misma que se muestra al sistema
operativo como un único disco duro cuando trabajamos con un sistema RAID a nivel de hardware, utilizando por lo general de la misma
capacidad.
Esta capacidad de crear arreglos a nivel de hardware requiere que exista un controlador RAID ya sea en la placa madre del sistema o
a través de una tarjeta de expansión conectada a un bus PCI. Es el controlador RAID el que debe ser capaz de entender los niveles de
RAID existentes tales como 0, 1, 5, etc.
De manera alterna al RAID a nivel de hardware existe su equivalente a nivel de software implementado por lo general por un
controlador de bajo nivel del sistema operativo.
El kernel Linux incluye un controlador por software para crear dispositivos RAID conformados ya no por discos duros enteros, sino por
otros dispositivos de bloque tales como particiones de disco, Logical Volumes o incluso otros dispositivos RAID. Este controlador de
Linux soporta los niveles 1, 4, 5, 6 y 10 (1+0).
RAID nivel 0
Este nivel de RAID distribuye los datos entre dos o más dispositivos sin información de paridad que proporcione redundancia. El
objetivo de este nivel de arreglo es tener una unidad lógica de mayor tamaño producto de la agrupación de dispositivos de menor
tamaño. Se caracteriza también por ofrecer un rendimiento superior.
Este nivel de arreglo puede ser creado con dispositivos de distintos tamaños, pero el espacio total añadido a la unidad lógica consiste
de porciones equivalentes al tamaño del menor de todos los dispositivos. Así si se forma un RAID 0 con dispositivos de 300 GB, 400
GB y 500 GB se obtendrá una unidad lógica resultante de 900 GB (300 GB x 3).
RAID nivel 1
Este nivel de RAID crea réplicas exactamente iguales entre cada uno de los dispositivos que conforman el arreglo. El objetivo de este
nivel es principalmente la redundancia y rendimiento a través la lectura concurrente desde dos o más discos.
Este nivel de arreglo puede ser creado con dispositivos de distintos tamaños, pero el espacio total resultante de la unidad lógica será
equivalentes al tamaño del menor de todos los dispositivos. Así si se forma un RAID 1 con dispositivos de 300 GB y 400 GB se
obtendrá una unidad lógica resultante de 300 GB.
RAID nivel 5
Este nivel de RAID usa una división de datos a nivel de bloques con la información de paridad distribuida entre todos los discos. El
objetivo de este nivel es principalmente la redundancia lograda a través de un bajo costo.
Este nivel de arreglo requiere al menos de 3 discos y sólo es capaz de soportar la falla de 1 disco como máximo; la falla de un segundo
disco provocaría la pérdida de datos.
La capacidad total obtenido de un RAID 5 es igual a N-1, donde N es la cantidad total de dispositivos, tomando de ellos sólo la
capacidad correspondiente al menor de todos si se usan dispositivos de distintos tamaños.
RAID nivel 6
Este nivel es similar al RAID 5 pero agrega un segundo bloque de paridad, lo que permite soportar la falla de hasta 2 discos como
máximo; la falla de un tercer disco provocaría la pérdida de datos.
La capacidad total obtenido de un RAID 6 es igual a N-2, donde N es la cantidad total de dispositivos, tomando de ellos sólo la
capacidad correspondiente al menor de todos si se usan dispositivos de distintos tamaños.
RAID nivel 10
Este nivel provee una combinación de RAID 1 y RAID 0. Cada bloque de datos es duplicado y distribuido entre múltiples dispositivos.
OpenSourceCollege
Linux for SysAdmins
Página 101
Source Linux
Esto se logra construyendo arreglos de nivel 1 y sobre las resultantes construir un arreglo de nivel 0. Este tipo de arreglo es
recomendado para el uso intensivo de bases de datos debido a su alto rendimiento tanto en lectura, como escritura, así como también
en los buenos niveles de redundancia que ofrece.
La regla de capacidad del arreglo se rige como las anteriores, de cada dispositivo se usa la capacidad equivalente al menor de todos
los restantes para armar los arreglos de nivel 1 y 0.
Ilustración gráfica de los niveles de RAID
OpenSourceCollege
Linux for SysAdmins
Página 102
Source Linux
Administración de dispositivos RAID en Linux
Vamos a empezar a estudiar el proceso de creación de dispositivos RAID en Linux a través de la línea de comandos. Empezaremos
mencionando que las particiones de disco donde deseamos usar como miembros de un arreglo, deben tener el identificador de
partición fd asignándolo con fdisk como sigue:
# fdisk /dev/sda
Código hexadecimal (escriba L para ver los códigos): fd
Se ha cambiado el tipo de sistema de la partición 1 por fd (Linux raid autodetect)

Código hexadecimal (escriba L para ver los códigos): fd
Se ha cambiado el tipo de sistema de la partición 2 por fd (Linux raid autodetect)


/dev/hdb1 1 195 98248+ fd Linux raid autodetect
/dev/hdb2 196 390 98280 fd Linux raid autodetect


# partprobe
Nótese que hemos elegido trabajar con dos particiones del mismo tamaño (ambos tienen 98280 bloques) y sólo para fines de pruebas
ambas pertenecen al mismo disco. Lo recomendable siempre es poder utilizar particiones en diferentes discos.
Ahora que ya tenemos las particiones listas podemos proceder al estudio de la herramienta mdadm que es la encargada de administrar
los dispositivos RAID, que son de tipo MD en Linux.
mdadm [modo] <dispositivo MD> [opciones] <dispositivos miembros>

Administra dispositivos MD
Opciones:
-A : Ensambla un arreglo pre-existente.

-C : Crea un nuevo arreglo.
-D : Consulta el estado de un dispositivo MD.
-G : Permite cambiar el tamaño de un arreglo, incrementar el número de dispositivos activos.
-n NUM : Define a través de NUM la cantidad de dispositivos activos en el arreglo.
-x NUM : Define a través de NUM la cantidad de dispositivos adicionales inactivos que forman parte del arreglo como repuestos.
-l NIVEL : Define a través de NIVEL el nivel del arreglo a crear.
-a : Agrega dispositivos al arreglo en caliente.
-r : Remueve dispositivos del arreglo en caliente. Los dispositivos a remover deben estar inactivos o fallados.
-f : Marca dispositivos como fallados en el arreglo.
-E DEV : Examina la información de superbloque en el dispositivo DEV para conocer su pertenencia a un arreglo.
-S : Desactiva un arreglo liberando todos sus recursos.
-R : Intenta iniciar un arreglo incluso si se indicó menos dispositivos de los que inicialmente lo conformaban.
Creación de arreglos
La siguiente sintaxis de mdadm es utilizada para crear arreglos:
# mdadm -C <disp. MD> -l <NIVEL> -n <NUM> <disp. miembros> [-x <NUM> <disp. repuesto>]
OpenSourceCollege
Linux for SysAdmins
Página 103
Source Linux
Desactivando arreglos
La siguiente sintaxis de mdadm es utilizada para desactivar arreglos:
# mdadm -S <disp. MD>
Activando arreglos
Es necesario averiguar qué dispositivos conformaban un arreglo para poder activarlo (ensamblar el arreglo pre-existente). Para eso
consultamos el superbloque de uno o más dispositivos y según la información obtenida sabremos los miembros que conformaban el
arreglo.
# mdadm -E /dev/hdb1
# mdadm -E /dev/hdb2
Una vez identificados los miembros del arreglo usaremos la siguiente sintaxis de mdadm para reactivarlo:
# mdadm -A <disp. MD> <disp. miembro>
Simulación de falla de miembros

En caso se requiera probar la correcta configuración y redundancia de nuestro arreglo podemos marcar un miembro como fallado
usando la siguiente sintaxis de mdadm:
# mdadm <disp. MD> -f <disp. miembro>
Eliminación de miembros
La eliminación de miembros de un arreglo puede ser posible cuando éstos no están activos o están marcados como fallados. La
siguiente sintaxis de mdadm para eliminar miembros es como sigue:
# mdadm <disp. MD> -r <disp. miembro>
Adición de miembros
La sintaxis de mdadm para agregar dispositivos como miembros del arreglo es la siguiente:
# mdadm <disp. MD> -a <disp. miembro>
En todo momento el arreglo usará sólo la cantidad de dispositivos que se le definieron como activos (opción -n) en el momento de su
creación. Si al arreglo se le removió un miembro o fue marcado como fallado entonces se considera que el arreglo está incompleto e
intentará automáticamente reemplazar el miembro faltante por algún otro inactivo disponible como repuesto (opción -x).
Si no existen dispositivos activos para ser usados como repuesto entonces apenas se agregue uno como miembro al arreglo éste será
tomado como reemplazo del faltante y marcado como activo para su uso, empezando así el proceso de sincronización respectivo.
Crecimiento de arreglos
Un arreglo puede crecer en tamaño a través del incremento de dispositivos miembros activos. Esto es posible con el uso de mdadm
como sigue:
# mdadm -G <disp. MD> -n <NUM> --backup-file=/root/grow_md.bak
El parámetro numérico de la opción -n debe reflejar la nueva cantidad de miembros activos del arreglo. La opción --backup-file no
es necesaria pero sí recomendable para restaurar el arreglo en caso de corrupción durante el proceso si se interrumpe por alguna
razón (tal como cortes de fluido eléctrico).
Consultando información de un arreglo

La siguiente sintaxis de mdadm permite consultar información y estado de un arreglo:
# mdadm -G <disp. MD> -n <NUM> --backup-file=/root/grow_md.bak
En caso necesitemos ver información sobre el estado de sincronización de miembros de un arreglo lo podemos hacer viendo de forma
OpenSourceCollege
Linux for SysAdmins
Página 104
Source Linux
estática el contenido de /proc/mdstat o de examinando de forma dinámica su avance como sigue:
# watch -n 1 cat /proc/mdstat
Utilizando los arreglos

Una vez creados los dispositivos MD éstos ya están listos para usarse como cualquier otro dispositivo de bloques:
# mkfs -t ext3 /dev/md0

# mount -t ext3 /dev/md0 /mnt
Ejemplo 25:
a) Asumiendo que se tienen a /dev/hdb1, /dev/hdb2 y /dev/hdb3 como particiones del mismo tamaño con identificador fd, crear un RAID 1
con dos de ellos dejando el tercero reservado como repuesto inactivo en el arreglo.
Consultar luego la información del arreglo comprobando que el tercer dispositivo se encuentre inactivo:
# mdadm -C /dev/md0 -l 1 -n 2 /dev/hdb[12] -x 1 /dev/hdb3

# mdadm -D /dev/md0
b) Crear un sistema de archivos ext3 en este primero arreglo creado y montarlo sobre /mnt/raid1. Luego copiar los archivos /etc/*.conf a
dicho sistema de archivos recién montado:
# mkfs -t ext3 /dev/md0

# mkdir /mnt/raid1
# mount -t ext3 /dev/md0 /mnt/raid1
# cp /etc/*.conf /mnt/raid1
# df -h
c) Provocar la falla de uno de los dispositivos activos del arreglo, comprobar que el inactivo haya tomado su posición como reemplazo y
finalmente eliminar el dispositivo fallado. Comprobar que sólo queden dos dispositivos activos y que los datos dentro del sistema de
archivos permanezcan intactos.
# mdadm /dev/md0 -f /dev/hdb1

# mdadm -D /dev/md0
# mdadm /dev/md0 -r /dev/hdb1
# mdadm -D /dev/md0
OpenSourceCollege
Linux for SysAdmins
Página 105
Source Linux
6.3. Logical Volume Management (LVM)
Conceptos básicos
LVM es la implementación para Linux de un administrador de volúmenes lógicos que permite tener una visión del almacenamiento de
disco en un nivel superior que el representado por el esquema tradicional de discos y particiones.
Los volúmenes de almacenamiento creados por LVM permiten aprovechar una serie de ventajas tales como:
✔ Mover volúmenes
✔ Redimensionar volúmenes
✔ Crear instantáneas de volúmenes (snapshots)
Pudiendo todas estas tareas ser realizadas en caliente. Esto representa una solución al problema típico de la difícil decisión de
particionamiento inicial al momento de instalación de un sistema operativo Linux. Es común que en un principio no se sepa cuánto
espacio reservar para cada sistema de archivos (/, /home, /usr; /var, /tmp, etc) por lo que puede suceder que a uno de ellos se reserve
menos espacio de lo debido y se llene rápidamente, o para evitarse problemas se decida asignar todo el espacio a la raíz trayendo
consigo un potencial riesgo de seguridad.
LVM representa una solución ideal permitiendo que cualquiera de esos sistemas de archivos creados sobre volúmenes lógicos sean
capaces de crecer en tamaño cuando se creen nuevas particiones o se conecten discos adicionales al sistema.
Utilizando el esquema tradicional de particionamiento no tendríamos otra opción diferente a utilizar otro punto de montaje para un disco
duro nuevo si pretendíamos expandir la capacidad de /home por ejemplo.
Anatomía de LVM
Para comprender la anatomía de LVM se deben estudiar los conceptos de cada uno de sus componentes los mismos que son
detallados a continuación:
• Physical Volume (PV)

Un PV es un dispositivo de bloques (disco entero, partición de disco o dispositivo MD) que ha sido inicializado por la
herramienta pvcreate para ser usado por LVM.
• Physical Extent (PE)

Un PE representa la porción mínima de datos en la cual se divide la información dentro de un PV. Cada PE suele tener el
mismo tamaño que los LE del mismo VG.
Es así que los PE son asignados de manera secuencial empezando desde el inicio del disco con la dirección 0, luego con la
dirección 1, 2, 3, y así sucesivamente incrementando siempre en 1. Cada una de estos PE por defecto tiene un tamaño de 4
MB y eso determina el tamaño de los LV. Por ejemplo pueden crearse LV de 40 MB, 96 MB o 16 MB pero no de 33 MB (no
es múltiplo de 4).
• Volume Group (VG)

Un VG es el máximo nivel de abstracción usado en LVM. Es la agrupación de Logical Volumes (LV) en una unidad
administrativa con nombre propio.
• Logical Volume (LV)

Un LV es un dispositivo de bloques que forma parte de un VG, preparado para contener un sistema de archivos dentro.
• Logical Extent (LE)

Un LE representa la porción mínima de datos en la cual se divide la información dentro de un LV. Cada LE tiene el mismo
tamaño para todos los LV del VG.
Snapshots de LVM
Esta es quizás la mejor de las funcionalidades ofrecidas por LVM. Consiste en la creación de un dispositivo de bloques adicional que se
presenta como una copia idéntica de un Logical Volume congelando en algún punto del tiempo. Suele ser utilizado generalmente para
poder generar backups de sistemas de archivos en constante y rápida modificación sin detener el sistema generando para ello un
snapshot desde el cual se hace el respaldo de datos.
Una vez que el administrador termina de utilizar el snapshot éste puede ser eliminado sin ningún tipo de alteración sobre los datos del
Logical Volume original desde el cual se hizo la copia.
Un snapshot se crea de forma similar que un Logical Volume, es decir lleva un nombre y tamaño particular. Este último no tiene por qué
ser igual, menor o mayor al tamaño del Logical Volume original pero sí es muy importante tener en cuenta que una vez que el snapshot
se llena (la cantidad de datos escritos supera el tamaño del snapshot) éste queda deshabilitado; puede ser leído aún mientras está
montado pero no hacer ningún cambio dentro, y tras desmontarlo no será posible volver a montarlo más.
OpenSourceCollege
Linux for SysAdmins
Página 106
Source Linux
Ilustración gráfica de componentes de LVM
Administración de LVM en Linux

Vamos a empezar a estudiar las tareas de administración de LVM a través de la línea de comandos. Empezaremos mencionando que
las particiones de disco donde deseamos usar como dispositivos para LVM, deben tener el identificador de partición 8e asignándolo
con fdisk como sigue:
# fdisk /dev/sda
Código hexadecimal (escriba L para ver los códigos): 8e
Se ha cambiado el tipo de sistema de la partición 3 por 8e (Linux LVM)


/dev/hdb1 1 195 98248+ fd Linux raid autodetect
/dev/hdb2 196 390 98280 fd Linux raid autodetect
/dev/hdb3 391 4266 1953504 8e Linux LVM


# partprobe
Gestión de Physical Volumes

Una vez que tenemos lista una partición del disco podemos proceder a inicializarla con pvcreate para trabajar con LVM.
pvcreate <dispositivo> [dispositivo] ...

Inicializa discos o particiones para ser usados por LVM
Otras herramientas relacionadas al manejo de Physical Volumes son las siguientes:
pvscan
Escanea todos los discos en busca de Physical Volumes
pvs <PV> [PV] ...
OpenSourceCollege
Linux for SysAdmins
Página 107
Source Linux
Reporta información sobre Physical Volumes
pvdisplay [opciones] <PV> [PV] ...

Muestra atributos de Physical Volumes
Opciones:
-s : Sólo muestra el tamaño del Physical Volume
pvresize [opciones] <PV>

Redimensiona un Physical Volume
Opciones:
--setphysicalvolumesize SIZE : Define el tamaño del Physical Volume según el valor de SIZE que puede tener sufijos como M, G.
Si no se especifica el tamaño del Physical Volume a través del parámetro arriba mostrado entonces se redimensionará al mismo
tamaño que tiene el dispositivo que lo alberga.
pvmove [opciones] <PV origen> [PV destino]

Permite mover en caliente Physical Extents (PEs) pertenecientes a un mismo Volume Group (VG)
Opciones:
-i SEG : Imprime un reporte del progreso de la tarea cada SEG segundos.

-n VOL : Mueve sólo los PE pertenecientes al LV VOL pertenecientes al PV origen en lugar de mover todos los PE asignados, al PV
destino.
Esta herramienta permite mover los PE asignados en el PV origen hacia uno o más PV. Si se usa la opción -n entonces sólo se
moverán los PE que ocupa el LV especificado. Si se omite el PV destino entonces automáticamente se moverán los PE del PV origen
hacia cualquier otro PV del VG.
pvremove <PV> [PV] ...

Elimina la etiqueta de un dispositivo de modo que LVM no lo reconozca más como un Physical Volume
Gestión de Volume Groups

Una vez que tenemos preparados una o más particiones como Physical Volumes estamos listos para crear Volume Groups a través de
la herramienta vgcreate cuya sintaxis de uso se muestra a continuación:
vgcreate [opciones] <VG> <PV> [PV] ...

Inicializa discos o particiones para ser usados por LVM
Opciones:
-s TAM : Define el tamaño del PE según TAM (debe ser múltiplo de 2) que puede llevar sufijos de tamaño como K, M, G, T.
Esta herramienta crea el VG conformado por uno o más PV especificados en la línea de comandos teniendo una capacidad total a la
suma de tamaños de cada uno de los PV.
Otras herramientas relacionadas al manejo de Volume Groups son las siguientes:
vgscan
Escanea todos los discos en busca de Volume Groups y reconstruye caches
vgs <VG> [VG] ...

Reporta información sobre Volume Groups
vgdisplay [opciones] <VG> [VG] ...

Muestra atributos de Volume Groups
Opciones:
-A : Sólo selecciona Volume Groups activos

-s : Sólo muestra información breve de la existencia y tamaño de Volume Groups
OpenSourceCollege
Linux for SysAdmins
Página 108
Source Linux
vgextend <VG> <PV> [PV] ...
Permite agregar uno o más Physical Volumes a un Volume Group para extender su tamaño
vgreduce <VG> <PV> [PV] ...

Permite remover uno o más Physical Volumes sin uso de un Volume Group para reducir su tamaño
vgchange [opciones] [VG] ...

Cambia atributos de Volume Groups
Opciones:
-a y|n : Activa (y) o desactiva (n) un Volume Group
Si no se especifica ningún VG se asume todos los existentes.
vgremove <VG> [VG] ...

Elimina Volume Groups
Gestión de Logical Volumes

Una vez que tenemos creados uno o más Volume Groups estamos listos para crear Logical Volumes a través de la herramienta
lvcreate cuya sintaxis de uso se muestra a continuación:
lvcreate [opciones] <VG> [PV]

lvcreate -s [opciones] <LV>
Crea un Logical Volume en un Volume Group existente
Opciones:
-l EXT : Define el LV con un tamaño equivalente a la cantidad de PEs indicados en EXT

-L SIZE : Define el LV con un tamaño equivalente a SIZE que puede llevar sufijos de tamaño como K, M, G, T.
Esta herramienta crea el VG conformado por uno o más PV especificados en la línea de comandos teniendo una capacidad total a la
suma de tamaños de cada uno de los PV.
-n : Define el nombre del Logical Volume.
-s : Crea un snapshot Logical Volume de uno existente, llamado Logical Volume original.
Otras herramientas relacionadas al manejo de Logical Volumes son las siguientes:
lvscan
Escanea todos los discos en busca de Logical Volumes
lvs <VG> [VG] ...

Reporta información sobre Logical Volumes
lvdisplay <LV> [LV] ...

Muestra atributos de Logical Volumes
lvresize [opciones] <LV>

Redimensiona un Logical Volume
Opciones:
-l [+/-]EXT : Cambia el tamaño de un LV en unidades de LE expresadas en EXT. Con los signos + ó - el valor es agregado o
sustraído del tamaño actual del LV, y sin estos signos se asigna el valor de EXT como absoluto.
-L [+/-]SIZE : Cambia el tamaño de un LV según el tamaño expresado en SIZE que puede llevar sufijos como K, M, G o T. Con
los signos + ó - el valor es agregado o sustraído del tamaño actual del LV, y sin estos signos se asigna el valor de SIZE como
absoluto.
Si no se especifica ningún VG se asume todos los existentes.
lvchange [opciones] <LV> [LV] ...

Cambia atributos de Logical Volumes
Opciones:
OpenSourceCollege
Linux for SysAdmins
Página 109
Source Linux
-a y|n : Activa (y) o desactiva (n) un Logical Volume
lvremove [opciones] <LV> [LV] ...

Elimina Logical Volumes
Opciones:
-f : Remueve Logical Volumes activos sin solicitar confirmación.
Ejemplo 26:
a) Asumiendo que se tienen a /dev/hdb5, /dev/hdb6 y /dev/hdb7 como particiones de tamaños 300 MB, 500 MB y 900 MB respectivamente
cada uno con el identificador 8e, crear un VG conformado por /dev/hdb5 únicamente y crear dentro 2 LV, uno de 100 MB y otro del
resto de capacidad. El primero de ellos usarla como SWAP adicional para el sistema y al segundo darle formato ext3, moviendo dentro
el contenido actual de /home y luego montándolo bajo esta ruta.
# pvcreate /dev/hdb5
# vgcreate sistema /dev/hdb5
# lvcreate -L 100M -n swap2 sistema
# mkswap /dev/sistema/swap2
# swapon /dev/sistema/swap2
# vgdisplay sistema # Consultamos el valor "Free PE / Size" para crear el siguiente LV
# lvcreate -l 46 -n home sistema
# mkfs -t ext3 /dev/sistema/home
# mkdir -t ext3 /mnt/lvm
# mount -t ext3 /dev/sistema/home /mnt/lvm
# mv -v /home/* /mnt/lvm
# mount --move /mnt/lvm /home
b) Dado que el VG sistema ya ha se llenado en capacidad, extenderlo en tamaño incluyendo a /dev/hdb6 como parte del VG. Luego
redimensionar el LV /dev/sistema/home a 500 MB y también expandir el sistema de archivos que hay dentro comprobando con df que
esto se haya logrado.
# vgextend sistema /dev/hdb6
# vgdisplay sistema
# vgs sistema
# lvresize -L 500M /dev/sistema/home
# df -h /home
# resize2fs /dev/sistema/home
# df -h /home
c) Se requiere utilizar la partición /dev/hdb5 para otro uso por lo que hay que removerla del VG de LVM sin pérdida de datos. Como
prevención a este problema nos han dispuesto utilizar la partición /dev/hdb7 de mayor tamaño a donde debemos mover toda la
información actualmente ocupada. Realizar los pasos necesarios para lograr el objetivo utilizando herramientas de LVM:
# vgextend sistema /dev/hdb7
# vgdisplay sistema
# pvdisplay /dev/hdb5 # Consultamos cuantos PE tiene asignados antes de moverlos
# pvmove -v -i 1 /dev/hdb5 # Movemos los PE de /dev/hdb5 a cualquier otro PV del VG
# df -h /home # Comprobamos la consistencia de /home y swap tras el cambio
# ls /home
# swapon -s
# pvs # Vemos el reporte final de uso de los PV
# vgreduce sistema /dev/hdb5 # Reducimos el VG quitandole el PV /dev/hdb5
# pvremove /dev/hdb5 # Limpiamos el dispositivo quedando listo para otro uso
# vgs sistema # Vemos el reporte final de uso del VG
d) Por mantenimiento del sistema se requiere desmontar todos los sistemas de archivos (excepto los necesarios para el
funcionamiento del sistema como la raíz) y desactivar los VG existentes; luego de 30 minutos se requiere volver a activarlos. Realizar
los pasos necesarios para lograr el objetivo:
OpenSourceCollege
Linux for SysAdmins
Página 110
Source Linux
# swapoff /dev/sistema/swap2
# umount /home
# vgchange -an sistema # Desactivar el VG sistema
# vgchange -ay sistema # Volver a activar el VG sistema
OpenSourceCollege
Linux for SysAdmins
Página 111
Source Linux
1. Utilizando como prueba los discos /dev/hdb, /dev/hdc, /dev/hdd y /dev/hde crear en cada uno de ellos particiones de 200 MB
para crear un arreglo de nivel 10 que a su vez forme parte de un Volume Group de nombre datos.
2. Crear un sistema de archivos ext3 en un LV que ocupe toda la capacidad del VG datos anteriormente creado. Montar dicho
sistema de archivos crear en él un archivo de 50 MB de tamaño.
3. Crear 1 partición de 1 GB en los discos /dev/hdb y /dev/hdc. Con ambas particiones formando un arreglo de nivel 1, expandir la
capacidad del VG.
4. Simular la falla de 3 dispositivos miembro del arreglo de nivel 10. Dada la situación de emergencia por el arreglo 10 en
estado degradado, como medida de precaución mover toda la información almacenada en ese arreglo a otra ubicación libre
dentro del VG datos.
5. Luego de restaurar el arreglo de nivel 10 (remover los dispositivos fallados y volverlos a agregar), crear un snapshot de 100
MB de capacidad del LV que contiene el sistema de archivos ext3. Montar el snapshot y crear tantos archivos en él como
sean necesarios para sobrepasar su capacidad hasta comprobar cómo el sistema lo deshabilita. Luego desmontar, eliminar
el snapshot y verificar si la información contenida en el LV original ha sido alterada o no.
OpenSourceCollege
Linux for SysAdmins
Página 112
Source Linux
1. Utilizando como prueba los discos /dev/hdb, /dev/hdc, /dev/hdd, /dev/hde crear en cada uno de ellos particiones de 200 MB para
crear un arreglo de nivel 10 que a su vez forme parte de un Volume Group de nombre datos.
+ A través de fdisk y las órdenes n y t creamos las particiones requeridas.
# fdisk /dev/hdb
# fdisk /dev/hdc
# fdisk /dev/hdd
# fdisk /dev/hde
+ Creación del arreglo de nivel 10:
# mdadm -C /dev/md0 -l 10 -n 4 /dev/hd[b-e]1
+ Preparamos el dispositivo MD como PV y creamos el VG datos:
# pvcreate /dev/md0
# vgcreate datos /dev/md0
2. Crear un sistema de archivos ext3 en un LV que ocupe toda la capacidad del VG datos anteriormente creado. Montar dicho
sistema de archivos crear en él un archivo de 50 MB de tamaño.
+ Consultamos la cantidad de LE libres en el VG datos y acorde a ese valor creamos el LV solicitado:
# vgdisplay datos
+ Creamos el LV:
# lvcreate -l 47 -n vol1 datos
+ Le damos formato ext3 y creamos dentro el archivo solicitado:
# mkfs -t ext3 /dev/datos/vol1

# mount -t ext3 /dev/datos/vol1 /mnt/lvm
# dd if=/dev/zero of=/mnt/lvm/file.01 bs=1M count=50
3. Crear 1 partición de 1 GB en los discos /dev/hdb y /dev/hdc. Con ambas particiones formando un arreglo de nivel 1, expandir
la capacidad del VG.
+ A través de fdisk y las órdenes n y t creamos las particiones requeridas.
# fdisk /dev/hdb
# fdisk /dev/hdc
+ Creación del arreglo de nivel 1:
# mdadm -C /dev/md1 -l 1 -n 2 /dev/hd[bc]2
+ Preparamos el dispositivo MD como PV y lo usamos para expandir el VG datos:
# pvcreate /dev/md1
# vgextend datos /dev/md1
4. Simular la falla de 3 dispositivos miembro del arreglo de nivel 10. Dada la situación de emergencia por el arreglo 10 en
estado degradado, como medida de precaución mover toda la información almacenada en ese arreglo a otra ubicación libre
dentro del VG datos.
+ A través de mdadm y la opción -f marcamos dispositivos como fallados:
# mdadm /dev/md0 -f /dev/hdb1

# mdadm /dev/md0 -f /dev/hdc1
# mdadm /dev/md0 -f /dev/hdd1
+ Mover los PE asignados en el PV /dev/md0 hacia otra ubicación disponible en el VG:
OpenSourceCollege
Linux for SysAdmins
Página 113
Source Linux
# pvmove -i 1 /dev/md0
5. Luego de restaurar el arreglo de nivel 10 (remover los dispositivos fallados y volverlos a agregar), crear un snapshot de 100
MB de capacidad del LV que contiene el sistema de archivos ext3. Montar el snapshot y crear tantos archivos en él como
sean necesarios para sobrepasar su capacidad hasta comprobar cómo el sistema lo deshabilita. Luego desmontar, eliminar
el snapshot y verificar si la información contenida en el LV original ha sido alterada o no.
+ A través de mdadm eliminamos los dispositivos fallados y los volvemos a insertar en el arreglo:
# mdadm /dev/md0 -r /dev/hdb1

# mdadm /dev/md0 -r /dev/hdc1
# mdadm /dev/md0 -r /dev/hdd1
# mdadm /dev/md0 -a /dev/hdb1
# mdadm /dev/md0 -a /dev/hdc1
# mdadm /dev/md0 -a /dev/hdd1
+ Creamos el snapshot del LV origen /dev/datos/vol1 y lo montamos:
# lvcreate -s -L 100M -n snap1 /dev/datos/vol1

# mkdir /mnt/snapshot
# mount -t ext3 /dev/datos/snap1 /mnt/snapshot
+ Creamos dentro del sistema de archivos que contiene el snapshot archivos de gran tamaño hasta sobrepasar los 100 MB
de su capacidad:
# dd if=/dev/zero of=/mnt/snapshot/snap.1 bs=1M count=30

+ ¿Se observó algún mensaje de error tras la última operación? ¿Alguna información de interés en la salida del comando
dmesg? Desmontemos y eliminemos el snapshot.
# umount /mnt/snapshot
# lvremove -f /dev/sistema/snap1
OpenSourceCollege
Linux for SysAdmins
Página 114
Source Linux
Unidad 7: Instalación
7.1. Objetivos
✔ Considerar los requisitos previos a la instalación de un sistema operativo Linux.

✔ Conocer los métodos de instalación y parámetros de arranque de Red Hat Enterprise Linux 5 / CentOS 5
✔ Aprender los procedimientos generales de instalación.
✔ Saber realizar un correcto particionamiento del sistema con soporte de RAID y/o LVM incluso.
✔ Realizar instalaciones desde la red.
✔ Conocer Kickstart y saber utilizarlo para realizar instalaciones automáticas.
7.2. Instalación de Red Hat Enterprise Linux / CentOS 5

Requerimientos
La instalación de todo sistema operativo requiere siempre ciertos conocimientos fundamentales sobre informática y especial cuidado si
pretendemos compartir el mismo equipo con otros sistemas, por ejemplo Windows. Por ello a continuación se menciona una lista de
consideraciones y requerimientos previos a la instalación de cualquier sistema operativo Linux:
1. Conocer la arquitectura
El kernel Linux en la actualidad ha sido portado a un enorme número de arquitecturas como x86, x86-64, Itanium, Power,
PowerPC, Sparc (32 y 64 bits), Alpha, ARM, PA-RISC, entre muchos otros.
Aunque puede ser poco común que nos crucemos con una arquitectura distinta a x86 o x86-64, siempre es necesario estar
seguros de la arquitectura del hardware sobre el cual vamos a instalar el sistema.
Red Hat Enterprise Linux 5 está disponible para las arquitecturas x86, x86-64, Itanium, Power y zSeries (s/390), en cambio
CentOS 5 sólo para x86 y x86-64.
Debian GNU/Linux 5 está disponible en más arquitecturas que son alpha, amd64 (x86-64), arm, armel, hppa, i386 (x86), ia64
(Itanium), mips, mipsel, powerpc, sparc y s390.
2. Medio de instalación
La fuente de instalación del sistema operativo en la mayoría de casos ha de ser uno o más discos compactos (CDROM,
DVD) los cuales deben ser para la misma arquitectura que tenemos en nuestro hardware. Sólo en el caso puntual de x86-64
tenemos que es posible instalar encima un sistema operativo diseñado para x86 (32 bits) aunque esto implique no
aprovechar los beneficios reales de la arquitectura de 64 bits.
En muchos casos se puede optar por un método de instalación que inicie desde la red a través de PXE, siempre y cuando
sea soportado por nuestro hardware.
3. Recursos mínimos necesarios de hardware

Si bien es cierto que un sistema Linux puede ser instalado sobre equipos de muy bajos requerimientos como un equipo 386
con menos de 16 MB de RAM, no significa que esto será siempre cierto para cualquier escenario.
Cada distribución Linux dependiendo de su complejidad puede requerir más o menos recursos de hardware, tanto en
memoria RAM, procesador y espacio en disco.
El tener un equipo Pentium II con al menos 256 MB de RAM podría bastar para instalar Linux con fines de prueba, sin
embargo debemos ser conscientes que requerimos más que eso para poder tener un sistema eficiente dependiendo de
nuestras expectativas de uso.
Contando con equipos modernos y distribuciones de Linux recientes, una PC Pentium IV o superior, 512 MB de RAM y 40
GB de disco podría ser apropiado para instalar Linux cómodamente y trabajar con él sin mayores complicaciones.
Para tener mayor detalles sobre el hardware soportado por una distribución Linux, es bueno consultar su Lista de
Compatibilidad de Hardware o Hardware Compatibility List.
4. Consideración de espacio en disco

Aunque se mencionó brevemente en el requisito anterior, Linux puede ser instalado en un espacio pequeño como unos 300
MB, claro está dependiendo de la cantidad de software y distribución Linux que instalemos.Sin embargo el espacio apropiado
depende mucho de nuestro criterio y necesidades.
Independientemente del tamaño que queramos darle a nuestro sistema Linux, es importante tener en cuenta que el esquema
actual de particionamiento de nuestro disco permita reservar al menos 2 particiones, sean éstas lógicas o primarias. Sin
contamos con un disco duro entero disponible entonces será mejor aún.
5. Arranque desde el medio de instalación

Es necesario configurar nuestro equipo para que pueda arrancar desde un dispositivo distinto al disco duro, tal como una
lectura CDROM/DVD o desde la red vía PXE. Esta configuración se suele hacer en la BIOS del equipo.
Parámetros de arranque de la instalación

Esta distribución se caracteriza por contar con un sistema de instalación bastante sencillo, completo y flexible llamado Anaconda. Éste
permite elegir la fuente de instalación desde un CDROM/DVD local, disco duro, o desde la red vía NFS, HTTP o FTP.
El método de instalación así como muchos otros parámetros de arranque de Anaconda pueden ser definidos tras cargar la pantalla
OpenSourceCollege
Linux for SysAdmins
Página 115
Source Linux
inicial que tiene una forma como la siguiente:
- To install or upgrade in graphical mode, press the <ENTER> key.
- To install or upgrade in text mode, type: linux text <ENTER>.
- Use the functions keys listed below for more information.
[F1-Main] [F2-Options] [F3-General] [F4-Kernel] [F5-rescue]

boot:
Tras la palabra boot podemos escribir lo siguiente:
• memtes86
• linux [parametros]
La primera de ellas realiza un test de la memoria del sistema. La segunda inicia el proceso de instalación con parámetros específicos,
algunos de los cuales se muestra a continuación:
Parámetro Descripción
text Inicia el proceso de instalación en modo texto, en lugar de hacerlo en modo gráfico (por
defecto).
noprobe Desactiva la detección automática de hardware. En su lugar arranca la instalación en modo

experto que requiere la identificación de dispositivos por parte del usuario de forma manual.
mem=CANT Define a través del valor de CANT (con el sufijo M de MB) la cantidad de memoria a informar
como disponible al sistema de instalación.
dd Se utiliza si se ha de insertar algún driver para el kernel durante el proceso de instalación.
askmethod Consulta el método de instalación a usar (CDROM/DVD, Disco local, NFS, HTTP, FTP) en lugar
de usar por defecto el CDROM/DVD local.
resolution=<W>x<H> Define la resolución de la pantalla a usar según los valores de W y H (Ejm: 1024x768)
No arranca el proceso de instalación sino un entorno de rescate que tiene por objetivo ejecutar
rescue una shell que puede servidor para acceder a un sistema ya instalado con el propósito de
corregir errores.
ip=IP Define la dirección IP que se asignará al sistema durante el proceso de instalación.
netmask=MASCARA Define la máscara de red que se asignará al sistema durante el proceso de instalación.
gateway=GW Define la dirección del gateway que se asignará al sistema durante el proceso de instalación.
dns=DNS1,DNS2 Define las direcciones IP de los servidores DNS que se asignarán al sistema durante el proceso
de instalación.
syslog=IP:PUERTO Guardar el log del proceso de instalación en un servidor syslog en la red
vnc Activa el acceso remoto vía VNC al proceso de instalación
vncpassword=PASSWD Define el password de acceso VNC al proceso de instalación.
mpath Inicia el proceso de instalación con soporte multipath. También instala y configura el sistema
operativo para que pueda arrancar desde una SAN con soporte multipath.
ks=floppy:/ruta/ks.cfg
ks=cdrom:/ruta/ks.cfg
ks=http://URL/ruta/ks.cfg Inicia una instalación automática con Kickstart buscando el archivo ks.cfg en una de las rutas
ks=ftp://URL/ruta/ks.cfg especificadas.
ks=nfs:host:/ruta/ks.cfg
Muchos de estos parámetros pueden combinarse a la vez.
Métodos de instalación
Cuando invocamos el proceso de instalación con la opción askmethod, luego de la opción de configuración de idioma del sistema y
teclado, se nos preguntará qué método de instalación usaremos, entre los que tenemos disponibles:
• CDROM local : Opción por defecto Utiliza el contenido del CDROM/DVD para instalar.
• Disco duro : Busca en un disco duro local las imágenes ISO del CDROM/DVD para instalar desde ahí.
• Imagen NFS : Busca en un servidor NFS las imágenes ISO o el contenido del CDROM/DVD para instalar desde ahí.
• FTP : Busca en un servidor FTP y ruta específica el contenido del CDROM/DVD para instalar desde ahí.
OpenSourceCollege
Linux for SysAdmins
Página 116
Source Linux
• HTTP : Busca en un servidor FTP y ruta específica el contenido del CDROM/DVD para instalar desde ahí.
Pasos del proceso de instalación

Asumiendo que se inicia un proceso de instalación manual, todas las fases que Anaconda ejecuta son las siguientes:
1. Chequeo del medio de instalación

Podemos elegir OK para chequear el CDROM/DVD de instalación, o Skip para omitir este chequeo.
2. Configuración de idioma del instalador

Elegimos en qué idioma deseamos que se nos muestre el proceso de instalación entero.
3. Configuración de idioma del teclado

Elegimos con qué idioma deseamos configurar nuestro teclado.
4. Número de instalación
Este paso que se muestra sólo en Red Hat Enterprise Linux, no en CentOS, solicita que se indique el código de instalación
respectivo que vino con nuestro Media Kit (caja que contiene los DVDs de instalación de Red Hat a quien previamente se les
compró).
La instalación puede continuar si omitimos el número de instalación pero el instalador Anaconda no permitirá la instalación ni
configuración de los grupos de paquetes de Clustering y Virtualización.
5. Elección de la acción del instalador

Elegimos si deseamos hacer una nueva instalación o queremos actualizar el sistema ya existente (debe ser la misma
distribución Linux).
Los pasos siguientes asumen que se eligió hacer una nueva instalación.
6. Configuración de particionamiento
El instalador nos da algunas alternativas que pretenden particionar de forma automática nuestro(s) disco(s) duro(s).
Podemos optar también por configurar manualmente las particiones nosotros mismos. También es posible configurar un
almacenamiento externo a través de iSCSI.
Los pasos siguientes asumen que se eligió un diseño personalizado de la tabla de particiones.
7. Particionamiento manual
A través de una interfaz intuitiva se puede crear y eliminar particiones, definir dispositivos RAID y LVM, dar formato a las
particiones como swap o con un sistema de archivos y definir puntos de montaje.
8. Configuración del gestor de arranque

Podemos elegir si instalar o no el gestor de arranque, y editar las entradas de inicio de cada sistema operativo a ser
mostradas por el GRUB. Opcionalmente se puede proteger el gestor de arranque con una contraseña.
9. Configuración de parámetros de red

Se nos muestra las interfaces de red reconocidas por el sistema y los parámetros de configuración de cada una de ellas, así
como definir el nombre de host, una puerta de enlace y servidores DNS.
10. Configuración de zona horaria

Aquí debemos configurar la zona horaria que corresponda a nuestra ubicación en el mundo. También podemos elegir si
nuestro reloj utilizará el sistema UTC o no, lo cual es recomendable activar sólo si nuestro equipo no será compartido como
arranque dual con Microsoft Windows.
11. Asignación de contraseña de root

Debemos definir la contraseña que tendrá el usuario root, escribiéndola dos veces.
12. Software a instalar

Se nos muestra una visión simplificada de los grupos de paquetes de software que deseamos instalar. Podemos optar por
activar una opción que nos permite personalizar con mayor detalle los paquetes a instalar.
13. Confirmar la configuración e iniciar la instalación

Tras haber configurado ya todos los parámetros generales del sistema operativo, procedemos a iniciar el proceso de
instalación que consiste en la creación y formateo de particiones, instalación de paquetes de software e instalación del gesto
de arranque escribiendo los cambios que sean necesarios en el disco duro.
Pasos del proceso de post-instalación

Asumiendo que se inicia un proceso de instalación manual con servidor gráfico X, los pasos finales de configuración del sistema tras el
primer arranque son los siguientes:
1. Licencia
Este paso que se muestra sólo en Red Hat Enterprise Linux, no en CentOS, solicita leamos y aceptemos la licencia mostrada
para proseguir.
OpenSourceCollege
Linux for SysAdmins
Página 117
Source Linux
2. Configuración del firewall
Podemos elegir qué servicios permitir a través del firewall o simplemente desactivarlo.
3. Configuración de SELinux
Podemos elegir una configuración Estricta o Permisiva de SELinux, o simplemente deshabilitarlo. Si realmente no se conoce
cómo se usa esta funcionalidad es mejor deshabilitarla.
4. Configuración de Kdump
Esta herramienta usada para depuración de errores del kernel debe ser activa sólo si realmente se sabe lo que se está
haciendo.
5. Configuración de hora y fecha

Se puede ajustar la hora y fecha del sistema. Adicionalmente es posible sincronizar la hora con un servidor NTP en la red.
6. Configuración de registro en RHN

Este paso que se muestra sólo en Red Hat Enterprise Linux, no en CentOS, permite registrar el sistema con Red Hat
Network para la descarga de actualizaciones y acceso al soporte de Red Hat en general. Para esto se requiere una licencia
activa asociada a una cuenta, cuyos datos (login o e-mail y la contraseña) se pueden ingresar en este paso.
7. Creación de una cuenta de usuario

Se ofrece la creación de una cuenta de usuario adicional a root. Es posible configurar otro esquema de autenticación distinto
al sistema de passwords locales del sistema, tal como LDAP, NIS, entre otros.
Se puede omitir la creación de esta cuenta si se gusta y proseguir.
8. Detección de la tarjeta de sonido

Se ofrece la detección de tarjetas de sonido, pruebas y ajustes de volumen.
9. Instalación de CDs adicionales

Se consulta al usuario si se desea instalar software adicional desde otros CDs en ese momento. Tras culminar este paso el
sistema ya está listo para ser usado, previo reinicio del equipo si se decidió desactivar SELinux.
Particionamiento apropiado
Dado que el proceso de instalación implica hacer un particionamiento del disco, es importante tener en cuenta algunas
recomendaciones de rendimiento y seguridad.
1. Tipo de dispositivo de almacenamiento

Como ya sabemos, es posible crear sistemas de archivos en particiones de disco, dispositivos MD (arreglos) o Logical
Volumes (LVM). Sin embargo si ya poseemos el conocimiento de la administración de estas dos últimas tecnologías conviene
usarlas en vez de usar sólo particiones de disco, aprovechando así la flexibilidad de redimensionamiento y snapshots
ofrecida por LVM y la redundancia de datos ofrecida por RAID cuando contamos con más de un disco duro.
2. Cantidad de memoria SWAP

La memoria SWAP puede bien estar dedicada en una partición de disco, en un dispositivo MD (sin mucho sentido), o en un
Logical Volume (lo recomendado). Sin embargo el tamaño a reservar no es algo que pueda tomarse con ligereza.
Todos los sistemas por poca o mucha memoria física que tengan siempre requieren utilizar la memoria SWAP, para alojar ahí
los procesos inactivos dando preferencia al uso de RAM por parte de los procesos más activos.
La cantidad de SWAP para un sistema con 2 GB de memoria RAM podría bastar quizás con 250 o 500 MB, siempre que no
se haga un uso intenso de procesos numerosos y concurrentes, sin embargo lo más apropiado es reservar al menos tanta
SWAP como memoria física exista en el sistema. Considerar como sustento este límite inferior si nuestro sistema pretende
en algún momento usar la funcionalidad de hibernación.
Para otros propósitos específicos puede ser necesario reservar incluso mayor SWAP, dependiendo de la naturaleza de las
aplicaciones que tengamos proyectado correr encima, tal como es el caso de Oracle.
3. Número de particiones y puntos de montaje

Si bien es cierto que se puede instalar todo el sistema Linux en una única partición (la raíz, /) es muy recomendable dividir el
sistema operativo en varios puntos de montaje como se resume en la siguiente tabla:
Punto de Opciones de Tamaño

Fundamento
montaje montaje recomendado
GRUB no soporta RAID ni LVM, por lo que es necesario separar a este
/boot - 100 MB directorio en una partición de disco si pretendemos instalar la raíz (/)
sobre un arreglo o un Logical Volume.
- La raíz del sistema, puede ser instalado sobre un arreglo o un Logical

/ 5 GB
Volume
/tmp noexec,nosuid, 3 GB Los temporales del sistema, puede ser instalado sobre un arreglo o un
nodev Logical Volume. Este directorio suele ser aprovechado por atacantes para
descargar software, compilarlo y ejecutarlo desde ahí, por ello las
OpenSourceCollege
Linux for SysAdmins
Página 118
Source Linux
opciones de montaje.
Archivos variables del sistema, puede ser instalado sobre un arreglo o un
Logical Volume. Dado que los datos aquí almacenados pueden crecer
noexec,nosuid, rápidamente podrían llenar y colapsar el sistema si se incluye en una
/var nodev 10 GB
única partición dentro de la raíz.
Dentro de /var/tmp también se almacenan temporales que al igual que
/tmp pueden ser aprovechados para los mismos propósitos.
El directorio de usuarios del sistema, puede ser instalado sobre un arreglo
noexec,nosuid, o un Logical Volume. La cantidad de datos que puede crecer en estos
/home nodev 10 GB directorios, podría llenar y colapsar el sistema.
Al igual que /tmp puede ser usado por usuarios para instalar y/o ejecutar
software potencialmente peligroso, por ello las opciones de montaje.
Observaciones:
• Estas recomendaciones se mencionan con la seguridad en mente. Por ello puede que sean más apropiadas para
instalaciones de servidor, en lugar de instalaciones para desktop o uso personal.
• Para instalaciones de uso personal o desktop también es recomendable separar la partición /home para prevenir que la raíz
llene su capacidad y para facilitar la restauración de datos si se requiere reinstalar el sistema operativo: sólo se requiere
formatear la raíz y no /home.
• Las recomendaciones de tamaño son sólo eso, recomendaciones. Cada escenario es distinto en necesidades y se puede
requerir más o menos espacio dependiendo del rol que vaya a desempeñar nuestro sistema. Puede que se requiera más
espacio en /var si instalamos un servidor de correo, o quizás más espacio en /home si pretendemos implementar un servidor
de archivos y/o FTP para usuarios. Incluso podríamos optar por montar otros sistemas de archivos en directorios distintos
siempre teniendo en cuenta la misma lógica de seguridad arriba mencionada para considerar las opciones de montaje que
sean apropiadas para nuestro caso.
Instalaciones automáticas con Kickstart

Kickstart es el mecanismo soportado por Anaconda para realizar instalaciones automáticas de Red Hat Linux o derivados como Fedora
o CentOS. Esto es posible a través del almacenamiento en un archivo de las respuestas a muchas de las preguntas realizadas durante
un proceso de instalación normal, de modo que el administrador pueda realizar una gran cantidad de instalaciones con un mínimo
esfuerzo y tiempo.
Algunas de las tareas que se puede automatizar usando Kickstart en un proceso de instalación incluye:
✔ Configuración de idioma.
✔ Configuración de mouse y teclado.
✔ Instalación y configuración del gestor de arranque.
✔ Particionamiento y montaje de discos.
✔ Configuración de red.
✔ Autenticación NIS, LDAP, Kerberos y Samba.
✔ Configuración de firewall.
✔ Selección de paquetes a instalar.
✔ Configuración del servidor gráfico X.
El procedimiento para realizar una instalación con Kickstart consiste en los siguientes pasos:
1. Creación de un archivo de configuración Kickstart.

2. Crear un disco de inicio que contenga el archivo Kickstart o publicar éste a través de la red.
3. Iniciar la instalación Kickstart escribiendo linux ks en el prompt de boot cuando carga el CDROM/DVD.
Creación de un archivo Kickstart

Este archivo se caracteriza por tener secciones secuenciales bajo la siguiente forma:
# Comandos de Kickstart
comando 1
comando 2
comando 3
...
...
OpenSourceCollege
Linux for SysAdmins
Página 119
Source Linux
# Paquetes a instalar
%packages [opciones]
@grupo-paquetes 1
@grupo-paquetes 2
@grupo-paquetes 3
...
...
paquete 1
paquete 2
paquete 3
...
...
# Scripts pre-instalación
%pre [opciones]
sentencias de script ...
...
...
# Scripts post-instalación
%post [opciones]
...
...
El orden de estas secciones no puede alterarse, siempre irá primero la sección Comandos, luego los Paquetes a instalar, luego los
Scripts pre-instalación y luego los Scripts post-instalación.
Analicemos con mayor detalle la sintaxis de configuración de cada una de estas secciones:
Sección Comandos
En esta sección podemos definir una serie de comandos Kickstart cada uno con sus propios parámetros. Algunos de los comandos
más importantes se resume debajo:
autopart
Opcional. Crea particiones de forma automática: 1 GB o más para la raíz, una partición swap y otra para /boot
ignoredisk [opciones]
Opcional. Ignora ciertas unidades de disco durante la instalación.
Opciones:
--drives=<disco1>[,disco2],...
Define los discos a ignorar. Ejm: --drives=sdf,sdg,hdc
authconfig [opciones]
Obligatorio. Define las opciones de autenticación para el sistema.
Opciones:
--enablemd5
Usa cifrado MD5 para las contraseñas de usuarios.
--enableshadow
Usa el sistema de contraseñas shadow.
--enableshadow
Usa el sistema de contraseñas shadow.
bootloader [opciones]
Obligatorio. Define cómo debería ser instalado el gestor de arranque.
OpenSourceCollege
Linux for SysAdmins
Página 120
Source Linux
Opciones:
--append=<BOOTPARAM>
Define los parámetros de arranque del kernel en BOOTPARAM. Ejm: --apend="ide=nodma hdd=ide-scsi"
--driveorder=<disco1>[,disco2]
Especifica qué disco es primero en el orden de arranque de la BIOS. Ejm: --driveorder=sda,hda
--location=<mbr|partition|none>
Define dónde instalar el gestor de arranque:
mbr : El MBR del disco..

partition : El primer sector de la partición que contiene el kernel.
none : No se instala el gestor de arranque.
--password=PASSWD
Protege el gestor de arranque con una contraseña PASSWD en texto plano.
--md5pass=PASSWD
Igual que --password pero PASSWD está cifrado en MD5
clearpart [opciones]
Opcional. Elimina particiones del sistema antes de crear otras nuevas. Por defecto ninguna partición es eliminada.
Opciones:
--all
Elimina todas las particiones del sistema
--drives=<disco1>[,disco2],...
Especifica de qué discos eliminar las particiones. Ejm: --drives=sda,sdb
--initlabel
Inicializa la tabla de particiones
--linux
Elimina todas las particiones Linux
--none
No elimina ninguna partición
firewall [opciones]
Opcional. Define la configuración de firewall del sistema.
Opciones:
--enabled
Habilita el firewall en el sistema.
--disabled
Deshabilita el firewall en el sistema.
--trust [interfaz0] --trust [interfaz1] ...

Define las interfaces de las cuales se filtrará con el firewall las conexiones entrantes. Ejm: --trust eth0 –trust eth1
--port=<puerto1:protocolo1>[,puerto2:protocolo2],...
Define las conexiones cuyo puerto y protocolo indicados son permitidos. Ejm: --port=443:tcp –port=http:tcp,domain:udp
firstboot [opciones]
Opcional. Determina si el instalador debe ejecutar el asistente de Primer arranque (post-instalación) una vez culminada la instalación.
Opciones:
--enabled
El instalador sí ejecutará el asistente de Primer arranque.
--disabled
El instalador no ejecutará el asistente de Primer arranque.
OpenSourceCollege
Linux for SysAdmins
Página 121
Source Linux
graphical
Opcional. Ejecuta la instalación en modo gráfico. Esto sucede por defecto.
halt
Opcional. Apaga el sistema tras culminar la instalación.
install
Opcional. Invoca al instalador a hacer una nueva instalación en lugar de una actualización de un sistema existente. Se debe
especificar el método de instalación cdrom, harddrive, nfs o url en una línea distinta al comando install.
cdrom
Instala desde el primer CDROM/DVD local.
harddrive [opciones]
Instala desde un disco duro con ext2 o vfat que almacene el contenido del CDROM/DVD de instalación.
--partition=<partición>
Define la partición desde la cual instalar. Ejm: --partition=hdb2
--dir=<directorio>
Define el directorio que contiene la fuente de instalación. Ejm: --dir=/var/install
nfs [opciones]
Instala desde un servidor NFS.
--server=<host>
Define el servidor NFS desde el cual instalar. Ejm: --server=172.31.0.1
--dir=<directorio>
Define el directorio en el servidor NFS que contiene la fuente de instalación. Ejm: --dir=/nfs/install
url [opciones]
Instala desde un servidor FTP o HTTP.
--url=<URL>
Define la URL fuente de instalación. Ejm: --url=http://10.1.0.1/install –url=ftp://user:pass@10.1.0.1/install
key [num. instal.] [opciones]

Opcional. Define el número de instalación de Red Hat Enterprise Linux. Ignorado en CentOS o Fedora
Opciones:
--skip
Omite el número de instalación. Si no se indica este número entonces Anaconda se detendrá hasta que el usuario lo ingrese.
keyboard <mapa>
Obligatorio. Define el mapa o idioma de teclado. Algunos valores posibles son: es, la-latin1, us
lang <idioma>
Obligatorio. Define el idioma de la instalación e idioma por defecto del sistema instalado. Algunos posibles valores son: en_US,
en_GB, es_ES, es_PE.
logvol <pto. montaje> --vgname=<VG> --size=<TAM> --name=<LV> [opciones]

Opcional. Crea un Logical Volume.
Opciones:
--fstype=<FS>
Define el sistema de archivos. Ejm: --fstype=ext3, --fstype=ext2
--noformat
Usa un Logical Volume existente y no lo formatea.
OpenSourceCollege
Linux for SysAdmins
Página 122
Source Linux
--useexisting
Usa un Logical Volume existente y sí lo formatea.
--grow
Indica que el Logical Volume debe crecer hasta ocupar todo el espacio disponible o hasta el tamaño máximo definido.
--maxsize=<TAM>
Define el tamaño máximo del Logical Volume en MB cuando se le ordena crecer con --grow
--recommended
Define el tamaño del Logical Volume automáticamente.
--percent
Define el tamaño del Logical Volume como un porcentaje del espacio disponible en el Volume Group.
network [opciones]
Opcional. Configura los parámetros de red del sistema.
Opciones:
--bootproto=<dhcp|static>
Define cómo es configurada la interfaz de red.
dhcp : Obtiene una IP de forma dinámica a través de DHCP.

static : Utiliza una dirección IP fija.
--device=<interfaz>
Define la interfaz a la cual asignarle los parámetros de red.
--onboot=<yes|no>
Define si se habilita o no la interfaz de red al arranque.
yes : Activa la interfaz de red al arranque.

static : No activa la interfaz de red al arranque.
--ip=<dirección>
Define la dirección IP
--netmask=<máscara>
Define la máscara de red
--gateway=<gateway>
Define el gateway por defecto o puerta de enlace del sistema.
--nameserver=<dns1>
Define el servidor DNS primario del sistema.
--hostname=<hostname>
Define el nombre de host del sistema.
part <pto. montaje|swap|raid.id|pv.id> [opciones]

Requerido. Crea particiones en el sistema. Si el segundo argumento es un pto. de montaje entonces crea una partición de datos, con
identificador 83 (Linux); si el segundo argumento es swap entonces crea una partición para swap, con identificador 82 (swap); si el
segundo argumento es raid.id o pv.id crea una partición para ser usada para RAID o LVM respectivamente, con identificadores fd o
8e según sea el caso. El valor de id que sigue a la palabra raid corresponde a un identificador numérico único para la instalación.
Opciones:
--size=<TAM>
Define el tamaño del dispositivo en MB según TAM (no lleva sufijos como M, MB o similares)
--grow
Indica que la partición debe crecer hasta ocupar todo el espacio disponible o hasta el tamaño máximo definido.
--maxsize=<TAM>
Define el tamaño máximo de la partición en MB cuando se le ordena crecer con --grow
--noformat
OpenSourceCollege
Linux for SysAdmins
Página 123
Source Linux
Ordena al instalador no formatear la partición para ser usado de la mano con --onpart
--onpart=<partición>
Define el punto de montaje en una partición ya existente. Ejm: part /home --onpart=sda1
--ondisk=<disco>
Fuerza la creación de la partición en un disco específico. Ejm: --ondisk=sdc
--asprimary
Fuerza la creación de la partición como primaria.
--fstype=<FS>
--recommended
Define el tamaño de la partición automáticamente.
raid <pto. montaje> --level=<nivel> --device=<disp. MD> <disp. miembro> [opciones]

Opcional. Crea arreglos según el valor de los argumentos especificados.
Opciones:
--level=<nivel>
Define el nivel del arreglo. Puede ser 0, 1 ó 5. Ejm: --level=1
--device=<disp. MD>
Define el nombre del dispositivo RAID. Ejm: --device=md0
--spares=<CANT>
Define a través de CANT la cantidad de dispositivos inactivos que formarán parte del arreglo como repuestos.
--fstype=<FS>
--noformat
Usa un arreglo existente y no lo formatea.
--useexisting
Usa un arreglo existente y sí lo formatea.
reboot
Opcional. Reinicia el sistema tras culminar la instalación.
rootpw [opciones] <password>

Obligatorio. Define el password de root.
--iscrypted
Indica que el password especificado está ya cifrado.
selinux [opciones]
Opcional. Declara el estado de SELinux en el sistema.
--enforcing
Habilita SELinux con una política estricta (Enforcing).
--permissive
Habilita SELinux con una política permisiva (Permissive), sólo genera advertencias mas no ejerce la política.
--disabled
Deshabilita SELinux por completo en el sistema.
services [opciones] <servicio1>[,servicio2],...

Opcional. Modifica los servicios que por defecto serán habilitados o no en el sistema.
--enabled
Habilita el arranque en el sistema de los servicios especificados en la lista.
OpenSourceCollege
Linux for SysAdmins
Página 124
Source Linux
--disabled
Deshabilita el arranque en el sistema de los servicios especificados en la lista.
text
Opcional. Realiza la instalación en modo texto.
timezone [opciones] <timezone>

Obligatorio. Define la zona horaria del sistema a través de timezone cuyo valor puede ser uno de los listados por el comando
timeconfig en el sistema Linux.
--utc
Permite interpretar la hora del reloj de hardware en el sistema UTC.
user --name=<USER> [opciones]

Opcional. Crea un usuario de nombre USER en el sistema tras la instalación.
--groups=<grupo1>[,grupo2],...
Indica los grupos secundarios a los que pertenecerá el usuario.
--homedir=<dir>
Define a través de dir el directorio personal del usuario.
--password=<password>
Define el password del usuario.
--iscrypted
Indica que el password especificado está ya cifrado.
--shell=<SH>
Define a través de SH la shell del usuario.
--uid=<UID>
Define a través de UID el identificador numérico (UID) del usuario.
vnc [opciones]
Opcional. Permite que la instalación gráfica sea visible a través de VNC.
--port=<PORT>
Especifica a través de PORT el puerto de conexión al servidor VNC.
--password=<PASSWD>
Especifica a través de PASSWD el password de conexión al servidor VNC.
volgroup <VG> <partición> [opciones]

Opcional. Crea un Volume Group de nombre VG en la partición indicada como argumento.
--noformat
Utiliza un Volume Group existente y no lo formatea.
--useexisting
Utiliza un Volume Group existente y sí lo formatea.
--pesize
Define el tamaño del PE en el Volume Group.
xconfig [opciones]
Opcional. Configura el servidor gráfico X.
--driver=<driver>
Define el nombre del driver de X que será usado.
--videoram=<CANT>
Define a través de CANT la cantidad de memoria de video que posee la tarjeta gráfica.
OpenSourceCollege
Linux for SysAdmins
Página 125
Source Linux
--defaultdesktop=<GNOME|KDE>
Define cuál será el entorno gráfico por defecto.
--startxonboot
Define si se iniciará o no el inicio de sesión gráfico al iniciar el sistema.
--resolution=<W>x<H>
Define a través de W (ancho) y H (alto) la resolución de la pantalla. Ejm: --resolution=1024x768
--depth=<DEPTH>
Define a través de DEPTH la profundidad de color predeterminada en el servidor gráfico X.
Dado que los comandos de particionamiento pueden haber resultado poco claros y quizás confusos, se muestra un ejemplo que puede
facilitar su comprensión:
clearpart --drives=hda,hdc --initlabel
part /boot --fstype=ext3 --size=100 –ondisk=hda

part /mnt/boot --fstype=ext3 --size=100 –ondisk=hdb
part swap --size=500 --ondisk=hda

part swap --size=500 --ondisk=hdb
part raid.11 --size 5000 -–asprimary --ondrive=hda

part raid.21 --size 1000 –-asprimary --ondrive=hdb
part pv.11 --size=1 --grow --ondisk=hda

part pv.21 --size=1 --grow --ondisk=hdb
volgroup correo pv.11 pv.21

logvol /var/spool --vgname=correo --size=1 --grow --name=vol1 --fstype=ext3
Sección de paquetes a instalar

En esta sección podemos definir los nombres de grupos de paquetes o paquetes individuales a instalar. Los nombres de los grupos de
paquetes deben ser precedidos por el símbolo @ y los nombres de paquetes sólo ser escritos sin ningún símbolo.
Los nombres de los paquetes así como de los grupos de paquetes están definidos dentro del archivo repodata/comps.xml que está
ubicado en la fuente de instalación, normalmente el CDROM/DVD.
Los nombres de los grupos de paquetes tienen la siguiente forma dentro del archivo XML:
<comps>
<group>
<id>admin-tools</id>
...
...
<id>development-libs</id>
...
...
<id>editors</id>
...
...
<id>gnome-desktop</id>
...
...
Mientras que los nombres de los paquetes individuales tienen la siguiente forma:
<packagelist>
<packagereq type="optional">adjtimex</packagereq>
<packagereq type="optional">arpwatch</packagereq>
<packagereq type="optional">audit</packagereq>
...
...
OpenSourceCollege
Linux for SysAdmins
Página 126
Source Linux
Dado que este es un archivo XML que nos tomaría cierto tiempo leer con rapidez para encontrar los nombres de los paquetes, pero el
siguiente comando nos hace un listado rápido de los grupos existentes:
$ grep '<group>' -A 1 repodata/comps.xml | grep '<id>' | cut -d '>' -f 2 | cut -d '<' -f 1
Así también los nombres de paquetes lo podemos encontrar con la siguiente sentencia:
$ grep '<packagereq>' repodata/comps.xml | cut -d '>' -f 2 | cut -d '<' -f 1
Una vez identificados todos los nombres de paquetes y grupos de paquetes disponibles en una instalación de Red Hat Enterprise
Linux, pasaremos a identificar cómo especificarlos dentro del archivo Kickstart.
Como se mencionó antes, esta es la sintaxis de la sección de paquetes:
%packages [opciones]
@grupo-paquetes 1
@grupo-paquetes 2
...
paquete 1
paquete 2
...
Donde las disponibles de %packages son:
--nobase
No instala el paquete @base si se pretende instalar un sistema realmente pequeño.
--ignoremissing
Ignorar los paquetes y grupos de paquetes faltantes en lugar de detener la instalación pidiendo intervención del usuario.
También es posible eliminar un paquete de la lista de predeterminados en su grupo colocando el signo – al inicio del nombre del
mismo.
Este sería un buen ejemplo de la sección %packages dentro de un archivo Kickstart:
%packages
@office
@development-libs
@editors
@text-internet
@gnome-desktop
@dialup
@core
@base
@games
@base-x
@graphics
@printing
@kde-desktop
@spanish-support
@sound-and-video
@development-tools
@graphical-internet
kdepim
device-mapper-multipath
xorg-x11-server-Xnest
xorg-x11-server-Xvfb
kdegraphics
libsane-hpaio
kdemultimedia
imake
-autofs
Sección de scripts pre-instalación

Esta sección tiene por objetivo ejecutar comandos al inicio de la instalación, apenas termina de ser leído el archivo Kickstart. El inicio
de esta sección se define a través de %pre como sigue en esta porción de archivo Kickstart:
OpenSourceCollege
Linux for SysAdmins
Página 127
Source Linux
%pre [opciones]
...
Donde las disponibles de %pre son:
--interpreter <intérprete>
Especifica el intérprete de scripting a usar. Ejm: %pre --interpreter /usr/bin/python
Este sería un buen ejemplo de la sección %pre dentro de un archivo Kickstart:
%pre
#!/bin/bash
# Agregamos un comentario a /etc/motd
echo "Red Hat Enterprise Linux instalado el $(date)" > /etc/motd
# Definimos un servidor DNS preferido

sed -i -e "1inameserver 10.0.0.3" /etc/resolv.conf
Sección de scripts post-instalación

Esta sección tiene por objetivo ejecutar comandos una vez que la instalación ha culminado El inicio de esta sección se define a través
de %post como sigue en esta porción de archivo Kickstart:
%post [opciones]
...
Donde las disponibles de %post son:
--nochroot
Indica que los comandos deben ser ejecutados fuera del entorno chroot de instalación.
--interpreter <intérprete>
Especifica el intérprete de scripting a usar. Ejm: %post --interpreter /usr/bin/python
Hay que considerar que por defecto el ámbito sobre el cual se ejecutan los scripts es un entorno chroot, es decir está dentro de una
jaula que no permite el acceso al exterior. Si se desea salir del entorno chroot se debe tener en cuenta que la raíz del sistema instalado
está debajo del directorio /mnt/sysimage.
Este sería un buen ejemplo de la sección %post dentro de un archivo Kickstart:
%post
#!/bin/bash
# Definimos un punto de montaje CIFS predeterminado
echo "//10.0.0.10/data /share cifs defaults,credentials=/etc/smb.auth 0 0" >> /etc/fstab
# Definimos las credenciales del montaje anterior

echo "username=operator" > /etc/smb.auth
echo "password=33D3::K" >> /etc/smb.auth
# Protegemos el archivo de credenciales de la lectura indebida

chmod 600 /etc/smb.auth
# Creamos el punto de montaje indicado en /etc/fstab

mkdir /share
OpenSourceCollege
Linux for SysAdmins
Página 128
Source Linux
Configuración gráfica de Kickstart
El proceso de configuración de Kickstart puede ser simplificado a través de una herramienta gráfica llamada Kickstart Configurator.
Esta herramienta está disponible sólo si se instala el paquete system-config-kickstart y se podrá acceder a ella desde un
entorno gráfico como GNOME o KDE.
Puede usarse Kickstart Configurator como reemplazo o complemento del proceso de configuración manual de un archivo Kickstart.
Llevando a la práctica Kickstart

Una vez que ya estudiamos la sintaxis de un archivo Kickstart, nos hace falta crear uno con un contenido apropiado a nuestras
necesidades y publicarlo a través de alguno de los siguientes métodos:
• En un disquete
• En un CDROM
• En la red
Si se usa un disquete, éste debe contener un sistema de archivos vfat o ext2. Se puede publicar el archivo Kickstart en la red a través
de un servicio NFS, HTTP o FTP. El archivo Kickstart siempre debe llevar el nombre ks.cfg.
Podemos crear nuestro archivo ks.cfg a partir de un modelo que se crea automáticamente tras cada instalación. Este modelo es
anaconda-ks.cfg ubicado en /root.
Un buen ejemplo ejemplo de archivo de configuración Kickstart es el que se muestra a continuación:
install
cdrom
lang es_ES.UTF-8
keyboard la-latin1
xconfig --startxonboot
network --device eth0 --bootproto static --ip 172.31.0.19 --netmask 255.255.255.0 –gateway
172.31.0.1 --nameserver 172.31.0.2 --hostname kickstart.consultorianet.com
rootpw --iscrypted $1$sV4KB8DZ$wEGf7LArS67xIMrjOXYPg0
authconfig --enableshadow --enablemd5
timezone --utc America/Lima
bootloader --location=mbr
clearpart --all --initlabel
part /boot --fstype=ext3 --size=100
part pv.01 --size=1 --grow
volgroup sistema pv.01
logvol swap --fstype swap --name swap --vgname=sistema --size=1024
logvol / --fstype ext3 --name=root --vgname=sistema --size=1 --grow
firewall --disabled
selinux --disabled
firstboot --disabled
services --disabled autofs,sendmail,portmap,nfslock,cups,rpcidmapd,pcscd,hplip,hidd,bluetooth
reboot
%packages
@office
@development-libs
@editors
@text-internet
@gnome-desktop
@dialup
@core
@base
@games
@base-x
@graphics
@printing
@kde-desktop
@spanish-support
@sound-and-video
@development-tools
@graphical-internet
kdepim
xorg-x11-server-Xnest
OpenSourceCollege
Linux for SysAdmins
Página 129
Source Linux
xorg-x11-server-Xvfb
kdegraphics
libsane-hpaio
kdemultimedia
imake
screen
%post
#!/bin/bash
cat >> /etc/yum.repos.d/dag.repo << EOF
[dag]
name=dag
gpgcheck=0
baseurl=http://apt.sw.be/redhat/el5/en/i386/dag/
enabled=0
EOF
Este archivo de configuración de indica que:
1. Se hará una instalación nueva, no una actualización.

2. La instalación se hará desde CDROM.
3. El idioma de la instalación y sistema instalado será es_ES con una codificación UTF.8.
4. Se usará Latinoamericano (la-latin1) como idioma de teclado.
5. Se iniciará el servidor gráfico X tras el arranque del sistema operativo.
6. Se configurará la IP del sistema a 172.31.0.19, con máscara 255.255.255.0, puerta de enlace 172.31.0.1, servidor DNS
172.31.0.2 y nombre de host kickstart.consultorianet.com.
7. El password de root se asignará a abc123 (está cifrado).
8. Se utilizará cifrado MD5 y el sistema de contraseñas shadow.
9. La zona horaria será configurada América, Lima.
10. El gestor de arranque se instalará el el MBR del disco que detecte la instalación.
11. Se eliminan todas las particiones del sistema y se crea una nueva tabla de particiones.
12. Se crea una partición de 100 MB para /boot con sistema de archivos ext3.
13. Se crea un PV que ocupa el resto de espacio disponible en el disco del sistema.
14. Se crea un Volume Group usando el PV previamente creado.
15. Se crea un Logical Volume de 1 GB de capacidad para ser usado como swap en el sistema.
16. Se crea un Logical Volume del resto de capacidad disponible en el Volume Group para la raíz (/) con un sistema de archivos
ext3.
17. Se deshabilita el firewall en el sistema.
18. Se deshabilita el SELinux en el sistema.
19. Se deshabilita el asistente de Primer arranque tras la instalación.
20. Se deshabilitan los servicios autofs, sendmail, portmap, nfslock, cups, rpcidmapd, pcscd, hplip, hidd y bluetooth.
21. Se reiniciará el sistema tras culminar la instalación.
22. Se instalarán los paquetes siguientes (@ al inicio indica un grupo de paquetes):
• @office
• @development-libs
• @editors
• @text-internet
• @gnome-desktop
• @dialup
• @core
• @base
• @games
• @base-x
• @graphics
• @printing
• @kde-desktop
• @spanish-support
• @sound-and-video
• @development-tools
• @graphical-internet
• kdepim
• device-mapper-multipath
• xorg-x11-server-Xnest
OpenSourceCollege
Linux for SysAdmins
Página 130
Source Linux
• xorg-x11-server-Xvfb
• kdegraphics
• libsane-hpaio
• kdemultimedia
• imake
• screen
23. Tras culminar la instalación se ejecuta un script en Bash que tiene por objetivo crear un archivo de repositorios .repo para
descargar software adicional de terceros.
Este archivo podríamos publicarlo en un directorio particular con Apache e invocar al proceso de instalación en el prompt boot: como
sigue:
boot: linux ip=172.31.0.23 netmask=255.255.255.0 ks=http://172.31.0.2/ks.cfg
Observaciones:
• Puede que requiera adquirir cierta práctica personalizar archivos de configuración tras un aprendizaje de pruebas y errores.
• El ejemplo arriba mostrado asume que se detectará automáticamente si existe uno o más discos en el sistema y los utilizará
todos para borrarlos por completo. Con un poco de cuidado en la creación del archivo Kickstart se puede detallar qué discos
duros utilizar para la instalación y formatear sólo algunas particiones si se pretende dejar otras intactas.
• Los parámetros de red especificados en el prompt boot: de arranque de la instalación no tienen por qué ser iguales a los
especificados en el archivo Kickstart, pues estos últimos son los que mandarán en la configuración final del sistema ya
instalado.
OpenSourceCollege
Linux for SysAdmins
Página 131
Source Linux
1. Usando un disco duro que se pueda borrar por completo (no menor de 4 GB de capacidad) , realizar una instalación manual
en modo texto por red extrayendo la fuente de instalación desde un servidor HTTP. Seleccionar la instalación mínima (implica
instalar sólo el sistema base). Crear una partición para /boot con ext3, y el resto del disco utilizarlo para LVM creando dentro
un LV para swap de tamaño apropiado y otro LV para la raíz con el resto de capacidad restante dentro del VG de nombre
INSTALL1.
2. Tras culminar la instalación cree un archivo Kickstart basado en anaconda-ks.cfg que se debe haber creado en /root. Edítelo de
modo tal que incluya los comandos de particionamiento (eliminando todas las particiones existentes) acorde a:
• Una partición de 100 MB para /boot con ext3

• Una partición que ocupe el resto del disco para ser utilizado como PV
• Un VG de nombre INSTALL2 que use el PV previamente creado.
• Un LV de 300 MB para swap
• Un LV de 200 MB para /home con ext3
• Un LV de 100 MB para /tmp con ext3
• Un LV con el resto de capacidad disponible del VG para la raíz con ext3
Además el archivo Kickstart debe automatizar lo siguiente:
• Firewall activado que permita el ingreso de conexiones sólo a los puertos TCP 22, 80 y 3128.
• SELinux deshabilitado.
• Deshabilitar los servicios portmap y nfslock.
• Instalar los paquetes adicionales httpd y squid.
• Reiniciar el sistema tras culminar la instalación.
• Agregar las opciones de montaje acl, usrquota y grpquota al sistema de archivos /home.
3. Con la experiencia adquirida en la instalación de sistemas Red Hat Enterprise Linux, realizar una instalación típica de
cualquier otra distribución Linux con el propósito de reforzar los conceptos básicos aprendidos.
Se sugiere instalar Debian GNU/Linux, openSUSE o Slackware por lo diferente que resultan sus procesos de instalación,
mientras que no optar Ubuntu o Fedora por ser éstas muy simples de instalar y no permitirá poner en práctica lo aprendido.
OpenSourceCollege
Linux for SysAdmins
Página 132
Source Linux
1. Usando un disco duro que se pueda borrar por completo (no menor de 4 GB de capacidad) , realizar una instalación manual
en modo texto por red extrayendo la fuente de instalación desde un servidor HTTP. Seleccionar la instalación mínima (implica
instalar sólo el sistema base). Crear una partición para /boot con ext3, y el resto del disco utilizarlo para LVM creando dentro
un LV para swap de tamaño apropiado y otro LV para la raíz con el resto de capacidad restante dentro del VG de nombre
INSTALL1.
+ Iniciar el instalador escribiendo lo siguiente tras el prompt boot (los parámetros de red pueden ser distintos o ser omitidos):
boot: linux ip=172.31.0.34 netmask=255.255.0.0 text askmethod
+ Tras elegir el idioma del sistema y teclado, al ser consultado sobre el método de instalación, elegir HTTP e ingresar el
nombre o IP de un servidor HTTP y debajo la ruta que publica la instalación.
Estos parámetros pueden ser facilitados por el docente durante la clase o desde otro equipo en la red podemos publicar
nosotros mismos el contenido de instalación. En un sistema Red Hat Linux típico se haría de este modo:
# mount -o ro -t iso9660 /dev/cdrom /media/cdrom

# mkdir /var/www/html/install
# cp -av /media/cdrom/* /var/www/html/install
# service httpd start
Esto publicaría el directorio de instalación bajo una URL como http://HOST/install donde HOST corresponde al nombre o IP
de nuestro equipo en la red que ofrece el servicio HTTP.
+ Indicar al instalador que se realizará una instalación nueva y tras continuar se llegará a la fase de particionamiento, donde
debemos elegir un Diseño personalizado para ejecutar lo siguiente:
• Dar clic en el botón Nuevo, elegir /boot como punto de montaje, definir 100 MB de tamaño, escoger ext3 como sistema
de archivos y finalmente dar clic en el botón Aceptar.
• Dar clic en el botón Nuevo, indicar que el tamaño ocupará hasta el máximo permitido, escoger physical volume (LVM)
como sistema de archivos y finalmente dar clic en el botón Aceptar.
• Dar clic en el botón LVM, escribir INSTALL1 como nombre del Volume Group, y luego dar clic sobre el botón Añadir dos
veces, una para crear un LV de nombre swap de 512 MB de tamaño y swap como sistema de archivos, y otra para crear
un LV de nombre root del tamaño restante con sistema de archivos ext3 y punto de montaje /
+ Tras terminar de definir las particiones, continuar con otros parámetros de configuración como la zona horaria, password de
root, gestor de arranque, etc.
+ Al llegar a la instalación de paquetes, elegir una selección personalizada y asegurarnos de desmarcar todos los grupos
(Editores, Sistema X Window, Gráficos, Juegos, etc...) excepto el llamado Base, de modo que nos aseguremos que se instale
un sistema sólo en modo texto.
+ Aceptar las configuraciones hechas al instalador e iniciar la instalación. Reiniciar el sistema y tras el arranque dejar intactas
las configuraciones del Primer arranque, esto implicaría dejar habilitado el Firewall y SELinux; opcionalmente se puede crear
una cuenta de usuario y/o cambiar la fecha y hora del sistema.
2. Tras culminar la instalación cree un archivo Kickstart basado en anaconda-ks.cfg que se debe haber creado en /root. Edítelo de
modo tal que incluya los comandos de particionamiento (eliminando todas las particiones existentes) acorde a:
• Una partición de 100 MB para /boot con ext3

• Una partición que ocupe el resto del disco para ser utilizado como PV
• Un VG de nombre INSTALL2 que use el PV previamente creado.
• Un LV de 300 MB para swap
• Un LV de 200 MB para /home con ext3
• Un LV de 100 MB para /tmp con ext3
• Un LV con el resto de capacidad disponible del VG para la raíz con ext3
Además el archivo Kickstart debe automatizar lo siguiente:
• Firewall activado que permita el ingreso de conexiones sólo a los puertos TCP 22, 80 y 3128.
• SELinux deshabilitado.
• Deshabilitar los servicios portmap y nfslock.
• Instalar los paquetes adicionales httpd y squid.
• Reiniciar el sistema tras culminar la instalación.
OpenSourceCollege
Linux for SysAdmins
Página 133
Source Linux
• Agregar las opciones de montaje acl, usrquota y grpquota al sistema de archivos /home.
+ Creamos una copia del archivo anaconda-ks.cfg como ks.cfg:
# cp /root/anaconda-ks.cfg /root/ks.cfg
+ Nos aseguremos que tenga un contenido similar al siguiente:
install
cdrom
lang es_ES.UTF-8
keyboard es
network --device eth0 --bootproto static --ip 172.31.0.34 --netmask 255.255.255.0 --gateway
172.31.0.1 --nameserver 172.31.0.2 --hostname kickstart.consultorianet.com
rootpw --iscrypted $1$QpaiQwMf$749DsiTXCB8vijhnZOl2u1
firewall --enabled --port=22:tcp
authconfig --enableshadow --enablemd5
timezone --utc America/Lima
bootloader --location=mbr
part /boot --fstype=ext3 --size=100
part pv.1 --size=1 --grow
volgroup INSTALL2 pv.11
logvol swap --fstype swap --name swap --vgname=INSTALL2 --size=300
logvol /home --fstype ext3 --name=home --vgname=INSTALL2 --size=200
logvol /tmp --fstype ext3 --name=tmp --vgname=INSTALL2 --size=100
logvol / --fstype ext3 --name=root --vgname=INSTALL2 --size=1 --grow
firewall --enabled –port=22:tcp,80:tcp,3128:tcp
selinux --disabled
services --disabled portmap,nfslock
reboot
%packages
@base
@core
@spanish-support
keyutils
trousers
fipscheck
httpd
squid
%post
#!/bin/bash
# Utilizando sed identificamos la entrada de montaje de /home y reemplazamos su opción de
# montaje defaults con defaults,acl,usrquota,grpquota
sed -i -e "/\/home/s/defaults/defaults,acl,usrquota,grpquota/" /etc/fstab
3. Con la experiencia adquirida en la instalación de sistemas Red Hat Enterprise Linux, realizar una instalación típica de
cualquier otra distribución Linux con el propósito de reforzar los conceptos básicos aprendidos.
Se sugiere instalar Debian GNU/Linux, openSUSE o Slackware por lo diferente que resultan sus procesos de instalación,
mientras que no optar Ubuntu o Fedora por ser éstas muy simples de instalar y no permitirá poner en práctica lo aprendido.
+ Se puede instalar cualquiera de estas distribuciones con videos o tutoriales didácticos que se pueden encontrar en Internet.
Sin embargo la siguiente URL específica contiene videos de instalación de varias distribuciones Linux:
http://linux.pucp.edu.pe/downloads/videos/video_tutoriales/tutor_online/
OpenSourceCollege
Linux for SysAdmins
Página 134
Source Linux
Unidad 8: Administración de software
8.1. Objetivos
✔ Conocer las distintas modalidades de instalación de software en Linux.

✔ Saber gestionar el sistema de paquetes RPM y DEB
✔ Administrar de forma simplificada el software con YUM para Red Hat / CentOS / Fedora y APT para Debian / Ubuntu.
Introducción
En los sistemas operativos Linux es muy común la instalación de software a través de dos modalidades que son:
• Instalación de paquetes binarios

Esta modalidad consiste en instalar paquetes de contenido binario, listos para usar. Estos deben estar hechos para una
arquitectura específica, por ejemplo el paquete binario de OpenOffice.org para x86 no es el mismo que para la arquitectura
x86-64 o powerpc, debemos instalar sólo el paquete que corresponda a nuestra arquitectura.
Además los paquetes binarios podemos encontrarlos en dos formas:
1. Paquetes binarios con formato definido : Los paquetes binarios con formato definido son típicos de distribuciones Linux
tales como Red Hat, Debian, Slackware, que manejan sus propios formatos de instaladores de software. Por ejemplo
Red Hat utiliza el formato RPM (extensión .rpm) para sus paquetes binarios, Debian usa el formato DEB (extensión
.deb) y Slackware el formato TGZ (extensión .tgz).
Cabe resaltar que otras distribuciones pueden usar estos mismos formatos como por ejemplo CentOS, Fedora, SuSE,
usan RPM, pero Ubuntu utiliza DEB también.
Estos paquetes binarios con formato definido se suelen instalar con una herramienta propia de cada distribución Linux,
tal como el comando rpm o el comando dpkg.
2. Paquetes binarios genéricos : Generalmente se distribuyen a través de archivos con extensión .bin o .run y el propósito
de estos es poder ser instalados de la misma forma en cualquier distribución Linux. La forma de instalar estos paquetes
consiste tan sólo en darles permisos de ejecución e invocarlos desde la línea de comandos.
• Instalación desde código fuente

Esta modalidad de instalación ya no depende de la distribución Linux sobre la cual trabajemos pues el procedimiento
consiste en tres pasos genéricos:
1. Obtener el código fuente de un software (tarball), por lo general desde Internet.

2. Descomprimir y compilar el código fuente.
3. Instalar en el sistema los binarios producto del proceso de compilación del software.
Cabe recalcar que cada uno de estas modalidades de instalación trae consigo ciertas salvedades:
• Los paquetes binarios con formato definido mantienen una base de datos interna que organiza todo el software instalado. Sin
embargo deseamos seguir usando los paquetes del mismo formato para instalar software en el futuro si pretendemos
mantener la organización; y es posible que cierto software publicado por terceros no esté disponible en el formato de
paquetes utilizado por nuestra distribución Linux.
• Los paquetes binarios genéricos ofrecen la ventaja de instalarse de forma sencilla en cualquier distribución Linux, pero no
será posible incluirlo en nuestra base de datos de software instalado debido a que no es compatible con el formato de
paquetes de nuestra distribución.
• El software instalado desde código fuente goza de la misma ventaja y desventaja que los paquetes binarios genéricos, no se
incluyen por defecto en nuestra base de datos de paquetes instalados.
8.2. Sistema de paquetes RPM

Este sistema de paquetes originalmente creado por Red Hat para su distribución Linux que lleva el mismo nombre, es uno de los más
expandidos sistemas de gestión de software y formato de paquetes, usado por muchas distribuciones en la actualidad.
Este sistema se caracteriza por poseer el soporte de identificación de dependencias, es decir nos permite saber qué otros paquetes de
software requerimos instalar antes del software de nuestro interés.
Las tareas de administración de paquetes de software RPM se hace a través del comando rpm el cual permite hacer tareas como:
• Instalar paquetes .rpm

• Consultar información de paquetes .rpm
• Desinstalar paquetes de software RPM
OpenSourceCollege
Linux for SysAdmins
Página 135
Source Linux
• Consultar la lista de paquetes instalados
La sintaxis del comando rpm es la siguiente:
rpm [-iUe] [opciones de instalación] <paquete RPM> [paquete RPM] ...

Instala y desinstala paquetes RPM
-i : Instala un nuevo paquete.

-U : Actualiza un paquete existente o lo instala si no existe.
-e : Elimina un paquete existente.
Opciones de instalación:
--nodeps : No verifica las dependencias antes de instalar o desinstalar un paquete.

--oldpackage : Permite reemplazar un paquete por otro de versión inferior.
--replacepkgs : Permite instalar paquetes que ya se encuentran instalados.
--replacefiles : Permite instalar paquetes incluso si sobreescriben archivos pertenecientes a otros paquetes ya instalados.
-h : Muestra un hash del progreso mientras el paquete es extraído.
rpm [-q] [opciones de selección] [opciones de consulta]

Consulta información de paquetes RPM
-q : Consulta un paquete.
Opciones de selección:
-a : Consulta todos los paquetes instalados.

-f FILE : Consulta qué paquete contiene el archivo FILE.
-p FILE : Consulta un paquete no instalado cuyo archivo es FILE.
Opciones de consulta:
-c : Lista los archivos de configuración del paquete.

-d : Lista los archivos de documentación del paquete.
-i : Lista información del paquete como el nombre, versión y descripción.
-l : Lista los archivos que contiene el paquete.
-R : Lista los archivos de los cuales depende para ser instalado.
Opciones adicionales de RPM:
-V : Verifica los archivos que contiene un paquete contra el estado original de dichos archivo según información en la base de
datos RPM.
-v : Muestra información adicional sobre la tarea que se está realizando.
Opciones de consulta:
--import : Importa un archivo de llaves públicas para verificación de paquetes.
Ejemplo 27:
a) Consultar la información y archivos que contiene el archivo RPM ccze-0.2.1-9.1.i586.rpm:
# rpm -qpi ccze-0.2.1-9.1.i586.rpm

# rpm -qpl ccze-0.2.1-9.1.i586.rpm
b) Instalar el paquete RPM ccze-0.2.1-9.1.i586.rpm
# rpm -ivh ccze-0.2.1-9.1.i586.rpm
c) Consultar el listado de archivos que contiene el paquete ccze:
# rpm -ql ccze
d) Listar la información del paquete:
# rpm -qi ccze
OpenSourceCollege
Linux for SysAdmins
Página 136
Source Linux
d) Eliminar el paquete ccze:
# rpm -e ccze
e) Listar todos los paquetes instalador que coincidan con kernel:
# rpm -qa "*kernel*"
Gestión simplificada de software RPM

El comando rpm no permite automatizar la instalación de paquetes faltantes para cumplir una dependencia, tal como se comentó
anteriormente. Pero tampoco es capaz de poder mostrarnos un listado de el software existente para instalar, ni poder realizar una
actualización automática de uno o más paquetes de software desde un repositorio oficial publicado por el fabricante.
Estas tareas sí son posibles utilizando una herramienta de alto nivel como YUM, la misma que se encarga de simplificar las labores de
instalación de software desde repositorios en red, que por lo general es Internet.
Esta herramienta cuyo comando lleva el mismo nombre, yum, tiene la siguiente sintaxis de uso:
yum [opciones] [comandos] <paquete> [paquete] ...

Administrador de paquetes RPM
Opciones:
-y : Asume yes como respuesta para cualquier pregunta.

--enablerepo REP : Habilta el repositorio REP durante el comando de YUM a ejecutar.
--disablerepo REP : Deshabilita el repositorio REP durante el comando de YUM a ejecutar.
Comandos:
install : Instala la última versión de paquetes y sus dependencias.

update : Si se ejecuta sin parámetros, actualizará todos los paquetes del sistema a su última versión; sino actualiza sólo
los paquetes indicados como parámetros.
check-update : Reporta los paquetes que requieren ser actualizados por existir una nueva versión en repositorios.
remove : Remueve un paquete y otros que dependen de ese.
list : Lista información de los paquetes disponibles en repositorios.
search : Busca paquetes coincidentes con criterios de búsqueda.
info : Muestra información detallada de los paquetes disponibles en repositorios.
groupinstall : Instala los paquetes pertenecientes a un grupo.
grouplist : Lista los paquetes existentes en repositorios.
groupremove : Remueve los paquetes pertenecientes a un grupo.
localinstall : Permite instalar archivos rpm locales y resolver sus dependencias desde repositorios si es necesario.
YUM dispone de muchas más opciones que pueden ser revisadas en yum(8).
Ejemplo 28:
a) Listar todos los paquetes cuyo nombre coincida con *zsh*:
# yum list "*zsh*"
b) Buscar los paquetes que estén relacionados con la palabra mozilla:
# yum search mozilla
c) Instalar el paquete thunderbird (Mozilla Thunderbird):
# yum install thunderbird -y
d) Listar los grupos de paquetes existentes:
# yum grouplist
e) Instalar el grupo de paquetes MySQL Database:
OpenSourceCollege
Linux for SysAdmins
Página 137
Source Linux
# yum groupinstall "mysql database"
f) Instalar todas las actualizaciones de paquetes pendientes:
# yum update -y
g) Eliminar el paquete httpd (Servidor Web Apache):
# yum remove httpd
Repositorios de software para YUM

YUM se basa en el uso de distintos repositorios de software para consultar, descargar e instalar paquetes. Por lo general el fabricante
del sistema operativo o distribución Linux, ofrece unos repositorios por defecto para descargar software oficialmente soportado. Sin
embargo también es posible descargar software de terceros utilizando repositorios adicionales.
Red Hat Enterprise Linux, de manera particular, no habilita la descarga de software a través de repositorios sino hasta que el sistema
haya sido registrado en Red Hat Network con su correspondiente licencia de suscripción.
El procedimiento para realizar este registro es de la siguiente manera:
# rhn_register
Esta herramienta iniciará un asistente que nos consultará paso a paso los datos de nuestra cuenta ya registrada en Red Hat, para así
poder acceder a las actualizaciones y otro software del repositorio utilizando yum.
Asumiendo que trabajamos con CentOS o con un sistema Red Hat Enterprise Linux ya registrado en Red Hat Network, procederemos
con la configuración de repositorios creando uno o más archivos de extensión .repo dentro del directorio /etc/yum.repos.d.
Cada archivo .repo tiene la siguiente forma:
[ID1]
directiva=valor
directiva=valor
...
...
[ID2]
directiva=valor
directiva=valor
...
...
[ID3]
directiva=valor
...
Donde:
ID : Es un nombre identificador del repositorio, debe ser único entre todos los repositorios.
directiva : Es una directiva de configuración.
valor : Es el valor asignado a una directiva.
Algunas de las directivas disponibles son las siguientes:
Directiva Descripción
name Define una descripción del repositorio.
baseurl Define una URL donde la metadata de un repositorio (directorio repodata) está alojada.
mirrorlist Define una URL a un archivo que contiene una lista de repositorios definidos por directivas baseurl.
enabled Si su valor es 1 el repositorio está habilitado, si es 0 está deshabilitado.
gpgcheck Si su valor es 1 se chequea la firma GPG de los paquetes obtenidos de este repositorio, si es 0 no se hace tal
chequeo.
gpgkey Define una URL que apunta a un archivo de llaves GPG para la verificación de paquetes.
proxy Define la URL a un servidor proxy por el cual realizar las operaciones de YUM.
proxy_username Define el usuario de autenticación para el proxy.
OpenSourceCollege
Linux for SysAdmins
Página 138
Source Linux
proxy_password Define el password de autenticación para el proxy.
Más información de parámetros para repositorios pueden ser encontrados en yum.conf(5)
Ejemplo 29:
a) Creamos el archivo de configuración del repositorio DAG:
# vim /etc/yum.repos.d/dag.repo
Incluimos las siguientes líneas como contenido:
[dag]
name=Repositorio DAG para RHEL, CentOS y Fedora
baseurl=http://apt.sw.be/redhat/el5/en/i386/dag
enabled=0
gpgcheck=1
gpgkey=http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt
b) Luego de guardar los cambios usar este repositorio de esta manera:
# yum --enablerepo=dag search openvpn

# yum --enablerepo=dag install openvpn -y
c) Lo anterior importaría el archivo de firmas GPG (tras confirmación del usuario) desde la URL descrita en gpgkey, pero podríamos
haberla importado manualmente de este modo:
# rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt
OpenSourceCollege
Linux for SysAdmins
Página 139
Source Linux
8.3. Sistema de paquetes DEB
Este sistema de paquetes originalmente creado por el proyecto Debian para su distribución Linux que lleva el mismo nombre, es en el
que se basan actualmente muchas distribuciones Linux como Ubuntu para la instalación de paquetes de software.
Este sistema se caracteriza por poseer el soporte de identificación de dependencias, es decir nos permite saber qué otros paquetes de
software requerimos instalar antes del software de nuestro interés.
Las tareas de administración de paquetes de software DEB se hace a través del comando dpkg el cual permite hacer tareas como:
• Instalar paquetes .deb

• Consultar información de paquetes .deb
• Desinstalar paquetes de software DEB.
• Consultar la lista de paquetes instalados
La sintaxis del comando dpkg es la siguiente:
dpkg [opciones] <acción>

Administrador de paquetes para Debian
Opciones:
-i : Instala un nuevo paquete.

-R DIR : De manera recursiva instala los paquetes del directorio DIR.
-r : Elimina un paquete, pero mantiene aún los archivos de configuración del paquete.
-P : Purga un paquete; elimina el paquete y sus archivos de configuración.
-c DEB : Muestra el contenido de un paquete a través del archivo DEB.
-I DEB : Muestra información de un paquete a través del archivo DEB.
-l : Imprime un listado de los paquetes instalados.
-L : Imprime un listado de los archivos que contiene un paquete.
-S FILE : Consulta qué paquete(s) contiene el archivo FILE.
-s : Muestra información de estado de un paquete instalado.
Ejemplo 30:
a) Consultar la información y archivos que contiene el archivo RPM install_flash_player_10_linux.deb:
# dpkg -I install_flash_player_10_linux.deb
# dpkg -c install_flash_player_10_linux.deb
b) Instalar el paquete DEB :
# dpkg -i install_flash_player_10_linux.deb
c) Consultar el listado de archivos que contiene el paquete adobe-flashplugin:
# dpkg -L adobe-flashplugin
d) Listar la información del paquete:
# dpkg -s adobe-flashplugin
d) Eliminar el paquete adobe-flashplugin:
# dpkg -r adobe-flashplugin
e) Listar todos los paquetes instalados que coincidan con core:
# dpkg -l "*core*"
OpenSourceCollege
Linux for SysAdmins
Página 140
Source Linux
Gestión simplificada de software DEB
El comando dpkg de manera análoga como sucede con el comando rpm, no permite automatizar la instalación de paquetes faltantes
para cumplir una dependencia. Para la realización de dicha tarea entre muchas otras como búsqueda de paquetes en repositorios,
actualización de paquetes desde Internet, eliminación de paquetes con sus dependencias, existe APT que a través de herramientas
como apt-cache, apt-get y apt-key se puede facilitar la gestión de administración de software en Debian.
Veamos algunas opciones del comando apt-cache:
apt-cache [opciones] <comandos>

Administrador de la cache de paquetes de APT
Opciones:
-f : Muestra todos los campos al ofrecer resultados de búsquedas con el comando search.
--names-only : Ordena al comando search a buscar sólo en criterio al nombre de los paquetes.
Comandos:
stats : Imprime un resumen estadístico de los paquetes de repositorios.

show : Muestra información de los paquetes indicados como parámetros.
depends : Informa de las dependencias de un paquete, y los paquetes que puedan satisfacerlas.
list : Lista información de los paquetes disponibles en repositorios.
apt-cache dispone de muchas más opciones que pueden ser revisadas en apt-cache(8).
Veamos algunas opciones del comando apt-get:
apt-get [opciones] <comandos>

Administrador de paquetes de APT
Opciones:
-d : Sólo descarga los paquetes mas no los instala.

-f : Intenta reparar un sistema con dependencias rotas cuando se utiliza con el comando install o remove.
-y : Asume yes como respuesta a las preguntas hechas por apt-get
--purge : Al ser usado con el comando remove permite purgar el paquete, eliminando así sus archivos de configuración.
--reinstall : Al ser usado con el comando install permite reinstalar un paquete ya instalado.
-t RELEASE : Controla la versión RELEASE de la distribución desde la cual se instalarán los paquetes por defecto.
Comandos:
update : Actualiza la caché de APT descargando los nuevos índices de paquetes desde repositorios.
upgrade : Actualiza desde repositorios todos los paquetes instalados en el sistema. Este comando no instalará ningún
paquete nuevo ni eliminará tampoco alguno ya instalado. Se obviará la actualización de paquetes que requieran modificar el estado
de instalación de otros paquetes como producto de una dependencia.
dist-upgrade : Similar al comando upgrade, pero será capaz de instalar nuevos paquetes o eliminar otros con tal de cumplir los
cambios de dependencias producto de la actualización.
install : Instala la última versión de un paquete y sus dependencias.
remove : Remueve un paquete y sus dependencias.
clean : Borra la caché de los paquetes descargados desde repositorios.
apt-get dispone de muchas más opciones que pueden ser revisadas en apt-get(8).
Veamos algunas opciones del comando apt-get:
apt-key <comandos> [argumentos]

Administrador de llaves para autenticación de paquetes.
Comandos:
add FILE : Agrega una nueva llave indicada por FILE.

del KEYID : Elimina una llave cuyo ID es KEYID.
list : Lista todas las llaves de confianza.
OpenSourceCollege
Linux for SysAdmins
Página 141
Source Linux
Ejemplo 31:
a) Listar todos los paquetes cuyo nombre coincida con zsh:
$ apt-cache search "*zsh*"
b) Buscar los paquetes que estén relacionados con la palabra mozilla:
$ apt-cache search mozilla
c) Instalar el paquete ccze:
# apt-get install ccze -y
d) Actualizar la caché de paquetes descargando los nuevos índices desde repositorios:
# apt-get update
e) Intentar reparar cualquier dependencia rota en el sistema, mientras se informa de la cantidad de paquetes pendientes por actualizar:
# apt-get install -f
f) Instalar todas las actualizaciones de paquetes pendientes, sin modificar el estado de instalación de otros paquetes:
# apt-get upgrade -y
g) Eliminar el paquete ccze:
# apt-get remove ccze
Repositorios de software para APT

APT se basa en el uso de distintos repositorios de software para consultar, descargar e instalar paquetes. Por lo general el fabricante
del sistema operativo o distribución Linux, ofrece unos repositorios por defecto para descargar software oficialmente soportado. Sin
embargo también es posible descargar software de terceros utilizando repositorios adicionales.
La configuración de repositorios se centraliza en el archivo /etc/apt/sources.list que tiene un contenido similar al siguiente:
deb http://host/debian distribución sección1 sección2 sección3

deb-src http://host/debian distribución sección1 sección2 sección3
Donde:
deb : Hace referencia a un repositorio de paquetes binarios .deb

deb-src : Hace referencia a un repositorio de paquetes fuente .dsc.
http://host/debian : URL de donde obtener los paquetes. Puede ser http, ftp, file o cdrom (apt-cdrom(8))
distribución : Nombre de una distribución que identifica los paquetes. Ejm: sarge, etch, lenny, testing, sid.
sección1,sección2, ...: Secciones de software dentro del repositorio.
Un archivo ejemplo de /etc/apt/sources.list tiene un contenido como el siguiente:
deb http://ftp.us.debian.org/debian lenny main contrib non-free

deb http://security.debian.org lenny/updates main contrib non-free
Más información de parámetros para repositorios pueden ser encontrados en sources.list(5)
Ejemplo 29:
a) Agregamos un repositorio adicional de software de terceros (Debian Multimedia):
OpenSourceCollege
Linux for SysAdmins
Página 142
Source Linux
# vim /etc/apt/sources.list
Incluimos las siguientes líneas como contenido:
deb http://www.debian-multimedia.org lenny main
b) Luego de guardar los cambios descargamos nuevamente los índices de repositorios para tener la información reciente sobre
paquetes:
# apt-get update
c) Podemos agregar repositorios desde CDROM o DVD de la siguiente forma:
# apt-cdrom add
Esto provocaría que APT nos pida el CDROM o DVD necesario cuando intentemos instalar un paquete que se encuentra en este
medio.
OpenSourceCollege
Linux for SysAdmins
Página 143
Source Linux
8.4. Instalación desde código fuente
Introducción
La instalación desde código fuente es un método que se puede seguir casi de manera idéntica en cualquier sistema operativo UNIX,
pues el procedimiento consiste en lo mismo: compilar software e instalarlo.
Razones comunes por las que podríamos desear instalar software desde código fuente pueden ser:
✔ El software no es publicado por el autor en un formato binario para nuestro sistema operativo sino sólo en fuentes.
✔ El software en formato binario sí existe para nuestro sistema operativo, pero no en su versión más reciente.
✔ Deseamos modificar algunos parámetros de funcionamiento del software que no es posible desde su versión binaria sino
sólo tras una recompilación del mismo.
✔ Simplemente para aprender cómo hacerlo.
Podrían existir otras razones distintas pero cada una de ellas sustentada por los mismos usuarios encargados de hacerlo. Lo
importante es conocer los pasos generales para poder hacerlo, los mismos que a continuación resumimos:
1. Preparación: Obtener el tarball del software desde Internet u otro medio, y desempaquetarlo/descomprimirlo.
2. Configuración: Verificar que se cumplan las dependencias para una compilación exitosa y opcionalmente configurar
parámetros de construcción del software.
3. Compilación: Construcción del software con el uso de algún compilador del sistema.
4. Instalación: Colocar los binarios producto de la compilación en directorios específicos del sistema y opcionalmente realizar
algunos procedimientos posteriores de configuración.
Vamos a entrar en detalle de cada uno de estos pasos a continuación.
Paso 1: Preparación
Este paso consiste en el más simple quizás de todos. Tras identificar qué software o conjunto de ellos deseamos instalar desde fuentes
debemos conseguirlos desde algún medio que comúnmente es a través de Internet.
Nosotros obtendremos un tarball el cual por lo general viene empaquetado y/o comprimido, por ello es necesario extraer su contenido
para poder seguir con el paso 2:
# tar xzf software-VERSION.tar.gz -C /usr/src

# cd /usr/src/software-VERSION
Esto genera por lo general un directorio que lleva el mismo nombre del tarball removiéndole la extensión .tar.gz. Procedemos a ingresar
a dicho directorio y explorar su contenido donde por lo general podemos encontrar:
• Un archivo de nombre README o README.txt

• Un archivo de nombre INSTALL o INSTALL.txt
• Un directorio de nombre docs, doc o install con documentación dentro en formato de texto plano o HTML.
Puede que algunas o todas de estos ficheros estén presentes pero en cualquiera de los casos es siempre recomendable leerlos. En
ellos por lo general se encontrará el procedimiento de cómo compilarlo e instalarlo, pues podría el procedimiento de instalación diferir
de los lineamientos generales que aquí mostramos.
Paso 2: Configuración
Este paso consiste en preparar el entorno para la compilación a través de la verificación de dependencias requeridas durante la
construcción del software, así como también la configuración de parámetros del producto final de la compilación.
Esto se suele realizar por lo general a través de la ejecución de un script de nombre configure ubicado en el directorio raíz del código
fuente del software previamente desempaquetado/descomprimido. La forma de ejecutarlo sería así:
# pwd
/usr/src/software-VERSION
# ./configure
El script en su mayoría de casos va a admitir el parámetro --help que mostrará las opciones de configuración del software:
# ./configure --help
Algunos de los parámetros que podría admitir este script permitiría por ejemplo definir la ruta de instalación del software, activar o
desactivar funcionalidades del software una vez compilado, activar el soporte para integración con librerías u otro software, etc.
La ejecución de este script va a verificar que todo el software necesario para una correcta compilación esté instalado en el sistema,
sino por lo general puede generar un error similar a este:
checking for libssl... configure: error: not found. Check your installation and look into
config.log
OpenSourceCollege
Linux for SysAdmins
Página 144
Source Linux
Claro que el mensaje de error puede diferir mucho, pero aquí se requiere mucha atención por parte del usuario para poder apreciar qué
dependencia es la que está faltando. Si se aprecia el mensaje de ejemplo se entiende que la librería libz parece no estar presente.
Con esta información de la dependencia faltante podemos buscarla como:
# apt-cache search libssl dev

# apt-cache seach ssl dev
# yum list "*ssl*dev*"
Nótese que se busca el nombre de la librería seguido de la palabra dev o devel dado que generalmente los paquetes que contienen
la librerías de desarrollo de cierto software requerido para la compilación terminan en esa palabra: Ejm: openssl-devel, libssl-
dev
Luego procedemos a instalar los paquetes que satisfacen las dependencias faltantes:
# apt-get install libssl-dev

# yum install openssl-devel
Paso 3: Compilación
Este paso consiste en iniciar la compilación del software con la ejecución del comando make:
# make
El proceso de compilación puede demorar dependiendo del tamaño del software y su complejidad. Sin embargo es posible que este
procedimiento pueda fallar por un error de dependencias, incompatibilidades con nuestro sistema o simplemente un bug.
Aunque es más difícil depurar los errores en este paso es posible de todos modos entender a veces el error que nos puede informar de
algún archivo de dependencia faltante (sí, incluso el script configure pudo no detectar esta dependencia).
Si todo ha terminado correctamente, podemos ir al siguiente paso.
Paso 4: Instalación
Este paso consiste en instalar el software ya compilado con la ejecución del comando make install:
# make install
Si el software ha sido configurado -previo a la compilación- para ser instalado en un directorio del sistema como /usr o /usr/local
entonces este paso de instalación necesariamente requerirá ser ejecutado como usuario root.
Sin embargo un usuario sin privilegios podría haber definido a través del script configure que el software se instale en su directorio
personal por lo que este paso de instalación no requeriría ningún privilegio superior al que ya actualmente tiene.
OpenSourceCollege
Linux for SysAdmins
Página 145
Source Linux
1. En un sistema Red Hat Enterprise Linux 5/ CentOS 5, instalar el grupo de paquetes "MySQL Database" y "Ruby".
2. Agregar un repositorio local para YUM que apunte a la URL http://172.31.0.1/centos con la verificación de firmas GPG
deshabilitada.
3. Tras descargar el paquete webmin-1.490-1.noarch.rpm consultar los archivos que trae dentro y luego instalarlo.
4. Hacer un listado de todos los paquetes que coincidan con el patrón de texto ssl en un sistema Debian.
5. Descargar e instalar la última versión del servidor Web Apache siguiendo el proceso de construcción del software desde las
fuentes. Instalarlo debajo del directorio /usr/local/apache.
OpenSourceCollege
Linux for SysAdmins
Página 146
Source Linux
1. En un sistema Red Hat Enterprise Linux 5/ CentOS 5, instalar el grupo de paquetes "MySQL Database" y "Ruby".
+ Comprobamos que existan esos grupos de paquetes haciendo un listado de los grupos:
# yum grouplist
+ Instalamos los grupos requeridos:
# yum groupinstall "MySQL Database" "Ruby"
2. Agregar un repositorio local para YUM que apunte a la URL http://172.31.0.1/centos con la verificación de firmas GPG
deshabilitada.
+ Creamos un archivo de nombre local.repo dentro del directorio /etc/yum.repos.d/ con el siguiente contenido:
[local]
name=Repositorio local en la LAN
baseurl=http://172.31.0.1/centos
gpgcheck=0
enabled=1
3. Tras descargar el paquete webmin-1.490-1.noarch.rpm consultar los archivos que trae dentro y luego instalarlo.
+ Examinamos el contenido del archivo RPM:
# rpm -qpl webmin-1.490-1.noarch.rpm
+ Lo instalamos de manera directa:
# rpm -ivh webmin-1.490-1.noarch.rpm
4. Hacer un listado de todos los paquetes que coincidan con el patrón de texto ssl en un sistema Debian.
+ Con apt-cache buscamos los paquetes:
# apt-cache search --names-only ssl
5. Descargar e instalar la última versión del servidor Web Apache siguiendo el proceso de construcción del software desde las
fuentes. Instalarlo debajo del directorio /usr/local/apache.
+ Podemos descargarlo desde un mirror de Apache:
# wget http://mirror.its.uidaho.edu/pub/apache/httpd/httpd-2.2.14.tar.gz
+ Lo descomprimimos y con el script configure verificamos las dependencias así como también definimos el directorio de
instalación:
# tar zxf httpd-2.2.14.tar.gz

# cd httpd-2.2.14
# ./configure --prefix=/usr/local/apache
+ Iniciamos la compilación y una vez terminada instalamos los binarios resultantes:
# make && make install
OpenSourceCollege
Linux for SysAdmins
Página 147
Source Linux
Unidad 9: Otros tópicos de administración del sistema
9.1. Objetivos
✔ Administrar los módulos del kernel.

✔ Conocer el funcionamiento del gestor de arranque GRUB y algunos parámetros de su configuración.
✔ Programar tareas del sistema a través de cron y at.
✔ Conocer el funcionamiento del demonio syslog y su configuración.
✔ Aprender los fundamentos del shell scripting en BASH.
9.2. El kernel y sus módulos

Organización del kernel
El kernel es el núcleo del sistema operativo, es aquel encargado de realizar las tareas más esenciales e importantes del sistema, tal
como gestionar los recursos, control de acceso al hardware, soporte de dispositivos de hardware, entre otros.
El kernel es el que debe estar preparado para soportar el hardware sobre el cual es instalado, así como también soportar los protocolos
de red con los que trabajaremos, los sistemas de archivos a usar en medios de almacenamiento, y muchas otras funcionalidades que
están incluidas en el momento de la compilación del kernel.
El kernel al igual que cualquier otro software se ha de construir a través de un proceso de compilación donde podremos decidir qué
funcionalidades habilitar o deshabilitar, teniendo como resultado un kernel de mayor o menor tamaño.
Justamente en el proceso de configuración y compilación del kernel es donde podemos decidir si la gran mayoría de las
funcionalidades las deseamos incluir en una única gran imagen del kernel, o deseamos dividirlas en porciones pequeñas de código
ejecutable que se carguen en demanda, según sean necesitadas por el sistema operativo. Esta última forma de construcción del kernel
en porciones de código llamados módulos se le conoce como un kernel modular.
Un kernel modular por lo general consiste de una imagen de poco tamaño -no superior a los 2 MB en muchos casos- y un conjunto de
módulos de menor tamaño -entre 9 KB y 1 MB en promedio- que se alojan en un directorio del sistema. Cuando el kernel es cargado
en memoria luego del gestor de arranque, intentará ir cargando otros módulos que sean necesarios en demanda mientras va iniciando
el sistema operativo.
Módulos del kernel y sus dependencias

Los módulos están asociados siempre a la misma versión del kernel y a la misma versión del compilador con el que fueron compilados.
Estos módulos son almacenados en /lib/modules/VERSION donde VERSION representa la versión del kernel (Ejm: 2.6.24), y dentro de
ellos están organizados en directorios pertenecientes a cada una de las categorías de módulos.
Los módulos son archivos de extensión .ko y entre ellos existe en muchos casos una dependencia de funcionamiento: Un módulo para
cargarse puede requerir que uno o más módulos distintos estén previamente cargados. Esta dependencia está definida en el archivo
/lib/modules/VERSION/modules.dep.
Herramientas de manipulación de módulos

Las herramientas modprobe, modinfo y lsmod nos permitirán manipular la carga y descarga de módulos del kernel de acuerdo a la
sintaxis de uso que mostraremos a continuación:
modprobe [opciones] [módulo] [parámetros]

Carga o descarga módulos de kernel
Opciones:
-r : Descarga un módulo.
-l : Imprime un listado de los módulos.
-v : Imprime información de las acciones que está realizando.
Esta herramienta cuando se usa para cargar un módulo puede recibir uno o más parámetros asociados a dicho módulo, los mismos
que por lo general están en la información provista por la herramienta modinfo.
modinfo <módulo> [módulo] ...

Muestra información de módulos
Esta herramienta provee información de un módulo tal como su ubicación, versión, licencia, autor, descripción, dependencias y
parámetros válidos.
OpenSourceCollege
Linux for SysAdmins
Página 148
Source Linux
lsmod
Lista los módulos actualmente cargados en el sistema
Esta herramienta extrae la información desde /proc/modules y la muestra formateada para informar cuáles son los módulos
actualmente cargados, sus tamaños y qué otros módulos están actualmente usándolos.
Información y ajustes del kernel

El kernel Linux es flexible, muchos parámetros que controlan su funcionamiento pueden ser modificados dinámicamente a través de la
herramienta sysctl. Los cambios que se hacen con esta herramienta se reflejan inmediatamente y pueden ser configurados para
ser persistentes tras un reinicio a través de la configuración de parámetros en el archivo /etc/sysctl.conf.
Por lo general muchos de los parámetros configurables del kernel están asociados a un nombre de archivo ubicado bajo /proc/sys,
reemplazando cada separador de directorio (/) por un punto. Por ejemplo la configuración del kernel net.ipv4.ipv4_forward (IP
forwarding) está ubicada en el archivo /proc/sys/net/ipv4/ip_forward.
Algunos parámetros básicos de sysctl se muestran debajo:
sysctl [opciones] [variable]

Configura parámetros de kernel en caliente
Opciones:
-a : Lista todos los parámetros disponibles.

-n : Omite mostrar el nombre de un parámetro, sólo muestra el valor.
-N : Omite mostrar el valor de un parámetro, sólo muestra su nombre.
-p : Aplica todas las configuraciones de parámetros definidas en /etc/sysctl.conf
-w : Permite escribir los cambios hechos a un parámetro con su valor.
Esta herramienta normalmente usa el símbolo punto (.) como separador, pero también puede admitir el símbolo slash (/) de forma
alternativa.
La cantidad de parámetros de configuración del kernel pueden ser variables y por lo general pueden superar fácilmente los 700, de
donde muchos de ellos lamentablemente no están documentados o es muy difícil acceder a la información de los mismos.
Algunos de estos parámetros están escritos como comentarios dentro del archivo /etc/sysctl.conf, muchos otros tantos estarán dentro
del directorio Documentation/sysctl, y otros muy probablemente sean documentados en algún lugar de Internet.
Ejemplo 32:
a) Tras compilar un driver de nombre test para nuestro sistema Linux, comprobar si ya ha sido instalado dentro del directorio de
módulos del kernel:
# modprobe -l | less
b) Consultar información del módulo de nombre msdos:
# modinfo test
c) Cargar el módulo msdos e ir viendo cómo resuelve otras dependencias que sean necesarias para cargarlo:
# modprobe -v msdos
d) Descargar el módulo msdos viendo cómo descarga otras de sus dependencias ya no necesarias:
# modprobe -rv msdos
e) Activar el IP Forwarding en nuestro sistema Linux:
# sysctl -w net.ipv4.ip_forward=1
OpenSourceCollege
Linux for SysAdmins
Página 149
Source Linux
9.3. Arranque del sistema
El gestor de arranque
El arranque de un computador inicia desde el momento en el que éste se enciende, ejecutando por lo general primero una etapa POST
(Power On Self Test) que verifica e inicializa componentes del sistema, luego según la configuración de la BIOS se ha de buscar algún
medio desde el cual arrancar un sistema operativo (floppy, CDROM, USB, Red, etc) cediendo el control a los primeros 512 bytes de
dicho medio donde se espera encontrar código ejecutable de un software llamado gestor de arranque.
El gestor de arranque es una pequeña aplicación que suele estar instalado en el sector de arranque de los discos (MBR) y tiene por
objetivo buscar y elegir un sistema operativo a iniciar en alguno de los medios de almacenamiento instalados. Este proceso de elección
del sistema operativo a arrancar puede hacerse de manera automática o de forma manual tras intervención del usuario.
Para aquellos usuarios que sólo han utilizado un único sistema operativo en su ordenador -comunmente alguna versión de Microsoft
Windows- el gestor de arranque es algo que definitivamente pudo haber pasado desapercibido, dado que esta aplicación no se suele
notar antes del arranque del sistema operativo.
Sin embargo para quienes ya han tenido la experiencia de instalar dos o más sistemas operativos en un único ordenador el gestor de
arranque ya se les habrá hecho notar como un menú de selección entre los sistemas operativos instalados.
Existen en la actualidad muchos gestores de arranque tal como NTLDR (NT Loader, típico de sistemas Microsoft), LILO, GRUB u otros,
pero sin embargo este último GRUB es en el que nos centraremos para estudiar su forma de uso y configuración.
GRUB Legacy
La versión más extendida de GRUB es la perteneciente a la rama 0.9x la cual ya ha sido reemplazada por la versión 2. A la rama
antigua se le suele llamar GRUB Legacy, y simplemente GRUB se le llama a la versión 2 reciente.
Sin embargo este manual ha de basar la documentación en la versión GRUB Legacy, por ser aún la más extendida entre instalaciones
de servidores estables en producción.
Es así que sobre GRUB Legacy es importante tener en cuenta las siguientes características:
• GRUB Legacy no marca diferencias entre discos IDE/ATA, SCSI, SATA o cualquier otro. A todos los nombra de la misma
manera.
• GRUB Legacy identifica los discos duros en el sistema como hdN donde N es el número de disco duro empezando por cero
(0 para el 1er. disco, 1 para el 2do. disco y así sucesivamente).
• Las particiones también son identificadas por un número pero siempre partiendo desde el cero (0 para la 1ra. partición, 3
para la 4ta. partición y así sucesivamente).
• GRUB Legacy entonces identifica una partición específica como (hdN,M) donde hdN representa el disco y M la partición.
GRUB Legacy centra su configuración en el archivo /boot/grub/menu.lst que sólo requiere modificar su contenido para que se hagan
efectivos los cambios a ser apreciados desde el próximo reinicio del sistema. La sintaxis de este archivo es como sigue:
# Directivas globales
directiva1 valor1
directiva2 valor2
...
...
# Directivas de sistemas operativos

directiva1 valor1
directiva2 valor2
...
...
Las directivas globales definen el comportamiento de GRUB Legacy de forma general tal como el tiempo de espera predeterminado, el
sistema operativo a arrancar por defecto, una contraseña de protección del gestor de arranque entre otras. Algunas de estas directivas
son:
Define el sistema operativo por defecto a arrancar según las entradas definidas con la directiva title. La
default
numeración de entradas empieza desde cero aumentando verticalmente hacia abajo.
timeout Tiempo de espera máximo antes de arrancar el sistema operativo por defecto definido con la directiva default.
OpenSourceCollege
Linux for SysAdmins
Página 150
Source Linux
Oculta el menú de selección de entradas de sistemas operativos a arrancar mientras avanza el tiempo de espera
hiddenmenu máximo. Presionando la tecla Esc se muestra el menú oculto. Un valor 1 oculta el menú, mientras que 0 no lo
oculta.
Protege con contraseña la edición de las entradas del gestor de arranque (presionando la tecla e). El password
password puede ser escrito en texto plano o cifrado en MD5 (generado con el comando grub-md5-crypt) especificando
antes la opción --md5
color Define una combinación de colores (de frente y fondo) a utilizar para el menú de GRUB Legacy.
Las directivas de sistemas operativos definen las entradas de acceso a uno o más sistemas operativos que pueden arrancar desde
GRUB Legacy permitiendo asignarles una etiqueta, ubicación del sistema operativo en el disco, protección con contraseña, etc.
Algunas de estas directivas son:
title Define el nombre de la entrada del sistema operativo a arrancar.
root Selecciona la partición de disco desde la cual se supone ha de cargar el kernel para inicializar el sistema
operativo.
Define la ruta de la imagen del kernel (buscada en la partición previamente definida por la directiva root) así
kernel
como también los parámetros pasados a éste para cargar.
Define la ruta de la imagen initrd (buscada en la partición previamente definida por la directiva root) a ser
initrd
cargada después del kernel para lograr un arranque conjunto de ambos archivos.
rootnoverify Selecciona la partición -sin montarla- desde la cual iniciar un sistema operativo. Usado generalmente para
arrancar sistemas operativos Microsoft Windows.
Realiza un arranque en cadena especificando un archivo o el sector de la partición la ubicación de otro gestor de
chainloader arranque ya instalado. Usar un valor como +1 indica que se cederá el arranque en cadena al primer sector de la
partición seleccionada con la directiva root.
Permite proteger el acceso a una entrada con contraseña. El password puede ser escrito en texto plano o cifrado
password
en MD5 (generado con el comando grub-md5-crypt) especificando antes la opción --md5
Shell de GRUB Legacy

GRUB Legacy dispone de una shell propia de comandos que permite administrar el gestor de arranque. Esta shell está disponible en el
momento que se ejecuta el gestor de arranque cuando presionamos la tecla c para ir al modo comandos, o también puede ser
invocada desde nuestro sistema Linux con el comando grub. Algunos comandos admisibles dentro de esta shell son los siguientes:
Comandos de shell de GRUB Legacy:
root : Selecciona una partición sin montarla.

rootnoverify : Selecciona una partición y la monta.
kernel : Define la ruta del kernel y sus parámetros para arrancar.
initird : Define la ruta de un archivo initrd a cargar.
chainloader : Realiza un arranque en cadena.
boot : Arranca un sistema operativo desde una partición previamente
setup : Instala GRUB Legacy en el sector de arranque del disco definido como parámetro. Ejm: setup (hd0)
reboot : Sale de la shell y reinicia el equipo.
quit : Sale de la shell.
Ejemplo 33:
a) Definir un archivo de configuración de GRUB Legacy que permita iniciar Windows XP instalado en /dev/sda1, y Debian Linux en
/dev/sda3 cuya partición /boot está en /dev/sda2. Debian Linux debe ser el sistema operativo predeterminado a arrancar.
timeout 10
default 0
title Debian Linux

root (hd0,1)
kernel /vmlinuz-2.6.26-2-amd64 root=/dev/sda3 ro
initrd /initrd-2.6.26-2-amd64
OpenSourceCollege
Linux for SysAdmins
Página 151
Source Linux
title Windows XP
rootnoverify (hd0,0)
chainloader +1
b) Generar un password MD5 y con ése proteger el gestor de arranque GRUB Legacy:
# grub-md5-crypt
Password:
Retype password:
$1$tmcUK/$dbpSPkV5/57WPsu4r.8X6.
Ahora editamos el archivo de configuración y agregamos la directiva password:
timeout 10
default 0
password --md5 $1$tmcUK/$dbpSPkV5/57WPsu4r.8X6.
title Debian Linux

root (hd0,1)
kernel /vmlinuz-2.6.26-2-amd64 root=/dev/sda3 ro
initrd /initrd-2.6.26-2-amd64
title Windows XP
rootnoverify (hd0,0)
chainloader +1
Niveles de arranque
Los niveles de arranque o ejecución, conocidos también como runlevels, representan fases de inicialización en un sistema UNIX
basado en System V. Estos niveles permiten definir diferentes acciones a ejecutarse en cada uno como por ejemplo el modo
monousuario o multiusuario del sistema, los servicios a levantar en cada uno, el arranque de la interfaz gráfica o no, entre otros.
Por lo general los niveles de arranque estándar son el 0, S y 6, y el resto suele diferir entre un sistema operativo u otro. La siguiente
tabla resume los niveles de ejecución de un sistema Red Hat Linux y Debian GNU/Linux:
Runlevel Descripción en Red Hat Linux Descripción en Debian GNU/Linux

0 Apaga el sistema. Apaga el sistema.
1, s, S Modo monousuario. Modo monousuario.
2 Sin uso, puede ser definido por el administrador. Modo multiusuario; con inicios de sesión en modo texto y
gráfico (si ha sido instalado).
3 Modo multiusuario; sólo inicios de sesión en modo texto. Modo multiusuario; con inicios de sesión en modo texto y
4 Sin uso, puede ser definido por el administrador. Modo multiusuario; con inicios de sesión en modo texto y
5 Modo multiusuario; con inicios de sesión en modo texto y Modo multiusuario; con inicios de sesión en modo texto y
gráfico. gráfico (si ha sido instalado).
6 Reinicia el sistema. Reinicia el sistema.
El comando init permite cambiar de un runlevel a otro y el comando runlevel nos informa del runlevel actual (derecha) y el previo
(izquierda). Por ejemplo las siguientes líneas nos cambiarían al modo monousuario, luego al multiusuario en modo texto, y luego
reiniciaría el sistema en Red Hat Linux:
# init 1
# runlevel
# init 3
# runlevel
# init 6
La interpretación de estos niveles de arranque en Linux está definida en el archivo /etc/iniittab el cual es leído por el proceso init una
vez que éste se ejecuta luego del arranque del kernel.
Este archivo está compuesto de líneas donde cada una tiene la sintaxis siguiente:
id:runlevels:acción:proceso
Donde:
OpenSourceCollege
Linux for SysAdmins
Página 152
Source Linux
• id : Secuencia de caracteres que identifican las entradas.
• runlevels : Niveles de ejecución para los cuales se ejecuta la acción.
• acción : Describe qué acción debe ser tomada.
• proceso : Proceso a ejecutar.
Algunas de las acciones válidas a tomar definidas en /etc/inittab pueden ser:
• respawn : El proceso será reiniciado si éste termina por alguna razón.

• wait : El proceso se inicia una vez e init espera a que finalice.
• once : El proceso se inicia una vez cuando el sistema alcanza el runlevel asociado a la entrada.
• boot : El proceso se ejecuta en el arranque. El runlevel es ignorado.
• bootwait : Igual que boot pero init esperará que el proceso finalice.
• initdefault : Define el runlevel por defecto en el cual arrancará el sistema.
• powerwait : Invoca un proceso cuando se recibe información de un corte de energía cercano (desde un UPS).
Más información de otras acciones pueden ser encontradas en inittab(5).
Los runlevels especificados en /etc/inittab no significan mucho por sí mismos, sino más bien son las acciones que realizan en base a
una serie de scripts localizados en /etc y varios directorios dentro los que le dan significado real a los runlevels. Cuando Linux se inicia
se invocan una serie de scripts para configurar el sistema y cambiar entre los runlevels, aunque la técnica usada difiere entre las
distribuciones Linux.
A continuación se muestra una serie de archivos usados para el arranque en entornos Red Hat Linux y Debian GNU/Linux:
Archivo o directorio en Archivo o directorio en

Descripción
Red Hat Linux Debian GNU/Linux
Script invocado por init que tiene como función la ejecución de tareas
básicas como el montaje de dispositivos, carga de módulos esenciales,
/etc/rc.sysinit /etc/init.d/rcS configuración de hora del sistema, activación de dispositivos RAID y
Logical Volumes, chequeo de sistemas de archivos, y otras acciones que
dejen al sistema listo para su uso.
/etc/rc -> /etc/rc.d/rc /etc/init.d/rc Script que se invoca para cambiar entre runlevels del sistema.
Script ejecutado al finalizar el arranque del sistema, luego de haberse
ejecutado todos los otros scripts de inicialización. Se usa generalmente
/etc/rc.local /etc/rc.local
para que el administrador defina qué comandos desea ejecutar al
arrancar el sistema sin modificar los otros scripts estándar.
Directorio que contiene una serie de scripts individuales de
/etc/init.d/ /etc/init.d/ inicio/apagado de los servicios del sistema, que se invocan por lo general
con parámetros como start, stop, reload, status u otros.
Los scripts de inicialización de /etc/init.d/ no son invocados directamente por el proceso init, sino que en su lugar los directorios
/etc/rc0.d, /etc/rc1.d, ..., /etc/rc6.d, contienen enlaces simbólicos que apuntan a los scripts del directorio /etc/init.d. Así cuando el proceso
init entra al runlevel N examina todos los archivos del directorio /etc/rcN.d.
Cada archivo dentro de /etc/rcN.d tiene la forma [K|S]Nnombre donde:
• K,S : Son los prefijos para Kill y Start respectivamente. Los servicios detenidos invocan a los scripts S para iniciarlo sy
los ya iniciados invocan a los scripts K para apagarlos.
• N : Es el número de secuencia u orden en el que se inician.
• nombre : El nombre del servicio tal como httpd, smb u otros.
Configuración de servicios al arranque

La manipulación de los scripts de inicio en /etc/init.d pueden ser administrador con la herramienta service y chkconfig en RedHat
mientras que en Debian GNU/Linux puede hacerse con invoke-rc.d y update-rc.d.
La sintaxis de uso de estas herramientas se muestra debajo:
service <script> <comando> [opciones]

Ejecuta un script SysV en Red Hat y derivados
Esta herramienta invoca script si éste se encuentra como un fichero dentro de /etc/init.d y le pasa como argumento el comando que
puede ser algo como start, stop, restart, status, u otros dependiendo de los comandos que acepte el script. Adicionalmente podría
recibir una o más opciones luego del comando a ejecutar.
OpenSourceCollege
Linux for SysAdmins
Página 153
Source Linux
chkconfig [opciones] <script> <on|off>
Configura la ejecución de scripts según runlevels
Opciones:
--add : Agrega un nuevo script a la lista de scripts administrados por chkconfig.

--del : Elimina un script de la lista de scripts administrados por chkconfig.
--level NIVELES : Define a través de NIVELES (juntos y sin separadores) los runlevels en los que se ejecutarán los scripts.
--list SCRIPT : Lista todos los runlevels en los que el script SCRIPT ha de ser ejecutado.
invoke-rc.d <script> <comando> [opciones]

Ejecuta un script SysV en Debian y derivados
Esta herramienta invoca script si éste se encuentra como un fichero dentro de /etc/init.d y le pasa como argumento el comando que
puede ser algo como start, stop, restart, status, u otros dependiendo de los comandos que acepte el script. Adicionalmente podría
recibir una o más opciones luego del comando a ejecutar.
update-rc.d [opciones] <script> remove

update-rc.d [opciones] <script> defaults
update-rc.d [opciones] <script> <start|stop> <NN> <RUNLEVELS> .
Configura la ejecución de scripts según runlevels
Opciones:
-n : No hacer nada, sólo informa los cambios que se hubieran hecho.

-f :Remover los enlaces simbólicos dentro de /etc/rcN.d incluso si aún existe el script.
Esta herramienta requiere que se indique a través de NN el número de secuencia u orden en el cual se iniciará o apagará el servicio,
y además los runlevels son especificados cada uno separado de otro por un espacio en blanco, finalizando la definición siempre con
un símbolo punto (.).
Observaciones:
• Es posible invocar los scripts SysV sin depender de los comandos service o invoke-rc.d ejecutándolos directamente
usando su ruta absoluta o relativa. Ejm:
# /etc/init.d/httpd restart
# /etc/init.d/postfix stop
Ejemplo 34:
a) Desactivar el reinicio del sistema con la combinación de teclas Ctrl+Alt+Del. Esto lo hacemos editando /etc/inittab como sigue:
# What to do when CTRL-ALT-DEL is pressed.

# La siguiente línea debe ser comentada
#ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Luego hacemos los cambios efectivos:
# init q
b) Configuramos el runlevel por defecto del sistema a 3. Esto lo hacemos editando /etc/inittab como sigue:
# The default runlevel.

# La siguiente línea debe contener el runlevel por defecto luego del campo id
id:3:initdefault:
Los cambios se notarán sólo en el próximo arranque del sistema.
c) Configuramos en un sistema Red Hat Linux el servicio httpd para que se inicie sólo en los runlevels 3 y 5:
# chkconfig --level 35 httpd on

# chkconfig --level 01246 httpd off
OpenSourceCollege
Linux for SysAdmins
Página 154
Source Linux
d) Apagar el servicio httpd y desactivarlo de cualquier runlevel al arranque:
# service httpd stop

# chkconfig httpd off
e) Configuramos en un sistema Debian GNU/Linux el servicio apache2 para que se inicie sólo en los runlevels 3 y 5:
Primero eliminamos cualquier referencia de enlaces simbólicos al script apache2:
# update-rc.d -f apache2 remove
Luego configuramos el arranque de apache2 con un número de secuencia 10 en los runlevels 3 y 5, y un número de secuencia 40
para el apagado en los runlevels restantes (0, 1, 2, 4 y 6):
# update-rc.d apache2 start 10 3 5 . stop 40 0 1 2 4 6 .
f) Apagar el servicio apache2 y desactivarlo de cualquier runlevel al arranque:
# invoke-rc.d apache2 stop

# update-rc.d -f apache2 remove
OpenSourceCollege
Linux for SysAdmins
Página 155
Source Linux
9.4. Programación de tareas
Introducción
La programación de tareas para su ejecución automática es una función básica que poseen la mayoría de sistemas operativos
modernos. Linux posee dos formas distintas de programación de tareas; una de ellas es a través del demonio cron que permite
programar la ejecución periódica (repetitiva) de tareas, y la otra a través del demonio at que permite programar la ejecución
postergada de tareas de una única ejecución (no repetitiva). Ambas serán estudiadas a continuación:
Tareas programadas con cron

cron es un demonio común en los sistemas Linux que se encarga de monitorear las tareas que han de ejecutarse bajo un periodo de
frecuencia definido.
La configuración de tareas programadas se puede hacer de manera centralizada a través del archivo /etc/crontab o de manera selectiva
a través de archivos cron pertenecientes a cada usuario del sistema.
El archivo /etc/crontab
La configuración centralizada del archivo /etc/crontab se hace siguiendo la sintaxis debajo mostrada:
# Sección variables
VAR1=valor
VAR2=valor
...
...
# Sección tareas
<Minuto> <Hora> <Día_del_mes> <Mes> <Día_de_la_semana> <Usuario> <Comando>
...
...
Donde:
• La sección variables, como su nombre lo dice, define variables con sus respectivos valores que serán usados en el ámbito de
ejecución de las tareas programadas. Algunas variables que comúnmente suelen definirse con HOME (directorio desde el
cual se ejecutan las tareas), SHELL (intérprete de órdenes usado para ejecutar las tareas), PATH y MAILTO (a quién se
enviará un correo reportando el resultado de las tareas ejecutadas).
• La sección tareas, define a través de entradas individuales (una por línea) las tareas a ejecutar en fechas y horas
específicas. Los campos que conforman estas entradas son:
1. Minuto : Valor entre 0 y 59.

2. Hora : Valor entre 0 y 23.
3. Día_del_mes : Valor entre 0 y 31.
4. Mes : Valor entre 1 y 12, o por nombres: jan, feb, mar, ..., nov, dec, etc.
5. Día_de_la_semana : Valor entre 1 y 7 (Domingo es 0 también), o por nombres: mon, tue, wed, ..., sun.
6. Usuario : Nombre de usuario que ejecutará la tarea.
7. Comando : Comando o conjunto de ellos (separado por ;) que se han de ejecutar.
Observaciones:
Los campos de fecha y hora ofrecen ciertas flexibilidades en su configuración como sigue:
• El símbolo asterisco (*) equivale a todos los valores posibles.

• Se puede especificar rangos separados por el símbolo guión (-) para delimitar un inicio y fin.
• Valores específicos de hora y/o fecha o incluso rangos pueden ser especificados cada uno separado por el símbolo coma (,).
• El símbolo slash (/) luego de un rango sirve para marcar una frecuencia repetitiva.
Los siguientes ejemplos deberían terminar de aclarar la sintaxis de este archivo:
Entrada de /etc/crontab Descripción

0 10 * * * root /bin/comando Ejecuta /bin/comando como el usuario root todos los días a las 10:00 am.
30 8,13,18 * * 1 admin /bin/comando Ejecuta /bin/comando como el usuario admin todos los Lunes a las 08:30
am, 01:30 pm y 06:30 pm.
*/15 * 15,30 apr-dec fri admin /bin/comando Ejecuta /bin/comando como el usuario admin los días Viernes o en los
OpenSourceCollege
Linux for SysAdmins
Página 156
Source Linux
días 15 y 30 de cada mes entre Abril y Diciembre durante todo el día cada
15 minutos.
* 8-20/2 * * 1-5 root /usr/bin/comando Ejecuta /bin/comando como el usuario root de Lunes a Viernes cada 2
horas desde las 08:00 am hasta las 08:00 pm
0 9-13,15-19 * * 1,5 admin /usr/bin/comando Ejecuta /bin/comando como el usuario admin los días Lunes y Viernes
cada hora entre las 09:00 am y 01:00 pm y entre las 03:00 pm y 07:00 pm
Tareas cron por usuario

Como se mencionó anteriormente es posible que cada usuario configure sus propias tareas programadas con cron, pero ya no a través
del archivo /etc/crontab (que es modificable sólo por root) sino con archivos cron propios configurables con el comando crontab.
La sintaxis de uso de esta herramienta es como sigue:
crontab [opciones]
Edita los archivos cron personales
Opciones:
-l : Muestra en pantalla el contenido del archivo cron personal.

-e : Abre un editor de textos para modificar el archivo cron personal.
-r : Elimina el archivo cron personal.
-i : Pide confirmación antes de eliminar el archivo cron personal.
-u USER : Edita el archivo cron del usuario USER. Sólo root puede usar esta opción.
Esta herramienta utiliza el editor definido en la variable EDITOR. Una vez que terminamos de editar la(s) entrada(s) de programación
de tareas, guardamos los cambios y salimos del editor con lo que ya quedará lista nuestra tarea.
La sintaxis del archivo cron personal es como sigue:
# Sección tareas
<Minuto> <Hora> <Día_del_mes> <Mes> <Día_de_la_semana> <Comando>
...
...
Como se notará, los campos son los mismos que el archivo /etc/crontab excepto la columna que especifica el usuario por razones
obvias.
Observaciones:
• La creación de archivos cron personales está controlada por los archivo /etc/cron.allow y /etc/cron.deny donde en cada uno de
ellos se puede definir los usuarios (uno por línea) que estarán permitidos o no de crear archivos cron.
Por ello en un entorno de servidor en producción se recomienda permitir la creación de archivos cron personales sólo al
usuario root a menos que de manera explícita otro usuario distinto requiera tal acceso.
• Cualquier cambio hecho a un archivo cron personal o el archivo /etc/crontab reflejará de manera inmediata las modificaciones
realizadas; no es necesario reiniciar el demonio cron (/etc/init.d/cron o /etc/init.d/crond).
Tareas programadas con at

at es un demonio común en los sistemas Linux que se encarga de monitorear las tareas que han de ejecutarse por única vez en una
fecha y hora determinada.
La forma de crear una tarea de ejecución postergada es a través del comando at a través del cual podemos indicar la fecha, hora y
comando(s) a ejecutar por nuestro usuario.
La sintaxis de at es la siguiente:
at [opciones] <TIEMPO>
Programa la ejecución de tareas
Opciones:
-l : Lista las tareas programados pendientes del usuario.

-d ID : Elimina una tarea pendiente del usuario cuyo identificador es ID.
-r : Elimina el archivo cron personal.
-c ID : Visualiza la tarea programada pendiente cuyo identificador es ID.
OpenSourceCollege
Linux for SysAdmins
Página 157
Source Linux
La fecha y hora de ejecución es definida a través de TIEMPO que puede ser especificada de diversas formas como:
• Definiendo la hora y minutos exactos como HH:MM, llevando opcionalmente los sufijos AM o PM para formato de 12 horas.
• Definiendo una palabra que identifica una hora como noon (12:00 horas), midnight (00:00 horas) o teatime (16:00 horas)
• Definiendo la fecha como "MES DIA" donde MES puede ser Aug, Oct, Jan, etc. y DIA un valor entre 0 y 31.
• Definiendo la fecha como MMDDYY, MM/DD/YY o DD.MM.YY, donde DD es el día del mes, MM el mes del año y YY el año.
• Definiendo la fecha y hora como "HORA FECHA", usando HORA y FECHA formatos líneas arriba definidos.
• Definiendo la fecha y hora como "FECHA/HORA + INCREMENTO", donde INCREMENTO está conformado por un valor
numérico y un sufijo de tiempo (minutes, hours, days, weeks, etc).
Esta herramienta tras ser invocada con un formato de TIEMPO lleva al usuario a una shell en la cual se pueden ingresar los
comandos que se desean ejecutar, uno por línea tras presionar la tecla Enter, y cuando finalicemos presionamos ^D para salir de la
shell y dejar encolada la ejecución programada de la tarea.
El comando atq es un alias de at -l y el comando atrm un alias de at -d
Observaciones:
• La programación de tareas con at controlada por los archivo /etc/at.allow y /etc/at.deny donde en cada uno de ellos se puede
definir los usuarios (uno por línea) que estarán permitidos o no de usar este servicio.
Por ello en un entorno de servidor en producción se recomienda permitir la programación de tareas con at sólo al usuario
root a menos que de manera explícita otro usuario distinto requiera tal acceso.
Ejemplo 35:
a) Programar el reinicio del servicio postfix cada 3 horas durante los días de semana. Esto lo logramos agregando la siguiente
entrada a /etc/crontab:
0 */3 * * 1-5 root /etc/init.d/postfix restart
b) Limitar el uso de at y cron al usuario root y admin únicamente:
# echo -e "root\nadmin" > /etc/at.allow

# echo -e "root\nadmin" > /etc/cron.allow
c) Bajo una sesión del usuario admin, crear una tarea programada personal con cron que genere un backup de su directorio personal
dentro de /var/backups los días 1ro. de cada mes a las 02:15 AM:
$ crontab -e
En el editor que se ejecuta agregamos lo siguiente:
15 2 1 * * tar -czf /var/backups/home-backup-$(date +%d%m%y).tar.gz ~
d) Bajo una sesión del usuario root, ejecutar el apagado del sistema el 15 de Diciembre del 2009 a las 17:30 horas. Asumir 01 de
Diciembre como la fecha de hoy, y las 10:30 AM como hora vigente.
Puede hacerse de cualquiera de las formas siguientes equivalentes:
# at 17:30 Dec 15
> shutdown -h now
# at 17:30 + 13 days
> shutdown -h now
# at 17:30 + 13 days
> shutdown -h now
# at Dec 15 + 7 hours
> shutdown -h now
# at 17:30 15.12.2009
OpenSourceCollege
Linux for SysAdmins
Página 158
Source Linux
> shutdown -h now
OpenSourceCollege
Linux for SysAdmins
Página 159
Source Linux
9.5. Logs del sistema
El demonio syslog
En todo sistema UNIX es típico que las aplicaciones instaladas posean siempre cierta capacidad de generar registros (logs) de su
funcionamiento, ya sea a través de una escritura directa en algún archivo y directorio del sistema (por lo general debajo de /var/log) o a
través de la comunicación con un demonio de logs, llamado Syslog.
Syslog es un estándar de facto como demonio de registros para sistemas UNIX, teniendo varias implementaciones de software tales
como sysklogd, rsyslog y syslog-ng.
La documentación de este apartado se basará en sysklogd que es el que vino siendo usado por la mayoría de distribuciones Linux
durante el transcurso de los años.
Para comprender la configuración del demonio syslog es importante conocer los términos siguientes:
facility : Categoría o instalación. Hace referencia al programa que invoca al syslog.

priority : Define la severidad del registro.
Las categorías o facilities que define syslog son:
Facility Descripción
authpriv Mensajes de seguridad o autorización.
cron Mensajes de los demonios cron y at.
daemon Mensajes de demonios independientes del sistema.
ftp Mensajes de demonios ftp.
kern Mensajes del kernel.
local0 a local7 Mensajes reservados para uso local.
lpr Mensajes del sistema de impresión.
mail Mensajes de correo.
news Mensajes de news.
syslog Mensajes generados internamente por el demonio syslog.
user Mensajes genéricos de nivel de usuario.
uucp Mensajes de UUCP.
Las severidades o priorities que define syslog son:
Priority Descripción
emerg Sistema inutilizable.
alert Debe tomarse una acción correctiva inmediatamente.
crit Condiciones críticas.
err Condición de error.
warning Condiciones de advertencia.
notice Condición normal pero significativa.
info Mensaje informativo.
debug Mensaje de nivel de depuración.
El archivo /etc/syslog.conf
El demonio syslog centra su configuración en el archivo /etc/syslog.conf el mismo que consta de está conformado por varias entradas
conformadas por un selector y una acción.
Cada entrada dentro del archivo se especifica como sigue:
selector acción
El selector define la naturaleza del mensaje a registrar (quién lo origina y qué prioridad tiene) y la acción define qué hacer con esos
mensajes (guardarlos en un archivo, mandarlo a otro demonio syslog en la red, enviarlo a un usuario, etc).
El detalle de la sintaxis y reglas que siguen los selectores y acciones se detalla debajo.
OpenSourceCollege
Linux for SysAdmins
Página 160
Source Linux
Sobre los selectores:
• Es posible especificar varios selectores para una acción, separando cada selector por el símbolo punto y coma (;).
• El selector está conformado por uno o más facilities -separados por comas- y priorities -también separados por comas. Los
facilities se separan de los priorities por un punto (.)
• Por defecto todos los mensajes que tenga una prioridad igual o mayor a la especificada en un selector serán guardados
según la acción definida en su respectiva entrada de /etc/syslog.conf.
• Si se desea filtrar sólo una prioridad específica y no ninguna superior (comportamiento por defecto), entonces se debe
colocar el símbolo igual (=) antes del priority.
• Se puede utilizar el símbolo asterisco para expresar todos los facilities o todos los priorities según se coloque este símbolo
antes o luego del punto (.) en un selector.
Sobre las acciones:

Las acciones pueden algunas de estas posibilidades:
• Archivo regular : Los mensajes se guardan en un archivo cuya ruta completa (empezando con /) debe ser especificada. Si
antes de la ruta del archivo se coloca el símbolo guión (-) entonces se omitirá la sincronización del archivo tras cada
escritura de registro, lo cual podría traer una pérdida parcial de datos ante un corte eléctrico por ejemplo pero permite
obtener mejor rendimiento cuando se va a escribir muchos registros de manera intensa en este archivo.
• Terminal y consola : Se puede indicar la ruta de un dispositivo tty u otro dispositivo de terminal donde se mostrarán los
mensajes.
• Equipo remoto : Se puede enviar los mensajes a otro host (corriendo el demonio syslog) a través de la red. Para eso el host
destino debe ser indicado luego del símbolo @ y dicho host debe estar preparado para aceptar logs desde la red.
• Lista de usuarios : Se envía a la pantalla del usuario logueado al sistema el mensaje de registro. Se pueden indicar uno o
más usuarios cada uno separado por comas.
Sobre el demonio syslog:
• Las implementaciones de demonios syslog tienen la posibilidad de funcionar de modo tal que estén a la escucha de recibir
mensajes desde la red (puerto UDP 514)de hosts remotos. En implementaciones como sysklogd o rsyslog es necesario
pasar el parámetro -r al arranque de estos demonios para habilitar esta funcionalidad de escucha en red.
La herramienta logger
El comando logger funciona como una interfaz de comunicación con el demonio syslog para enviarle a él mensajes de registro en una
facility y priority determinadas. Es útil para generar logs de forma manual como parte de alguna otra aplicación tal como un script
escrito en BASH o Perl.
La sintaxis de uso de esta herramienta se muestra debajo:
logger [opciones] [mensaje]

Herramienta de generación de mensajes para syslog
Opciones:
-s : Escribe el mensaje en la salida de error (STDERR), pero también en el demonio syslog.

-f FILE : Escribe en el demonio syslog el contenido del archivo FILE.
-p PRI : Escribe el mensaje con la prioridad PRI que puede tener la forma facility.priority
Los facilities y priorities válidos a usar son los mismos que se documentaron líneas arriba.
Ejemplo 36:
a) Crear una configuración en el demonio syslog de modo tal que los mensajes de facilities mail, cron y kern con prioridad igual o
mayor a warn sean enviados al archivo /var/log/mensajes. Considérese que los mensajes generados en este archivo serán abundantes
y debe procurar optimizar el rendimiento del demonio syslog.
Lo haremos agregando la siguiente entrada al archivo /etc/syslog.conf:
mail,cron,kern.warning -/var/log/mensajes
OpenSourceCollege
Linux for SysAdmins
Página 161
Source Linux
b) Hacer efectivos los cambios anteriores y probar su correcta configuración.
Reiniciamos el demonio syslog:
# /etc/init.d/sysklogd restart
Generamos mensajes de prueba para syslog y analizamos el contenido del archivo /var/log/mensajes:
# logger -p cron.warning "Mensaje de prueba 1 – Facility: cron, Priority: warning"

# logger -p kern.err "Mensaje de prueba 1 – Facility: kern, Priority: err"
# logger -p mail.crit "Mensaje de prueba 1 – Facility: mail, Priority: crit"
# tail /var/log/mensajes
OpenSourceCollege
Linux for SysAdmins
Página 162
Source Linux
9.6. Shell scripting básico
Shell scripting en BASH
La correcta administración de un sistema UNIX requiere un sólido entendimiento de los componentes del sistema operativo, las
herramientas que lo administran y poseer la habilidad de usar eficientemente estas herramientas a nuestro alcance de manera
conjunta.
Esta última habilidad mencionada no podría ser llevada a niveles considerables sin un conocimiento de programación de scripts de
shell, los que tienen por objetivo automatizar muchas de nuestras tareas de administración haciéndolas realmente fáciles y rápidas.
Esto sumado al hecho que BASH es la shell más usada en las distribuciones Linux nos lleva a la necesidad de elegir a esta shell como
la preferida para la programación de nuestros scripts.
Es así que si deseamos perfilar a convertirnos en un buen administrador de sistemas UNIX es necesario desenvolvernos sin problemas
con BASH scripting e ir preparando habilidades de scripting en Perl.
Creación básica de scripts

Crear un script en BASH es muy sencillo, basta con crear un fichero cuya primera línea contenga #!/bin/bash y debajo ir incluyendo
todas la sentencias que formarán parte de este script.
Como sentencias podemos entender cualquiera de los comandos hasta este momento estudiados o cualquier otro comando del
sistema, además de funciones, operadores y otro contenido típico de un script de BASH.
Así, el siguiente puede ser un script muy básico representado por el archivo script1.sh:
#!/bin/bash
# script1.sh
FECHA=$(date)
echo "Hola este es mi primer script"
echo "La fecha y hora actual es: $FECHA"
Tras guardar los cambios en el archivo, procederemos a darle permisos de ejecución e invocarlo desde la shell:
$ chmod +x script1.sh
$ ./script1.sh
Es recomendable dar permiso de ejecución a nuestros scripts, pero no indispensable pues aún sin dicho permiso podríamos ejecutarlo
del siguiente modo:
$ bash script1.sh
Sobre la ejecución de scripts:

Existen dos formas de ejecutar archivos en una shell BASH como si se tratasen de scripts:
1. Ejecución de scripts en el entorno actual de shell : Esto permite cargar las variables o funciones de scripts en nuestra shell
actual como si se tratasen de variables locales. No ejecuta un proceso hijo para la shell invocada.
Este tipo de ejecución se hace de una de las dos formas siguientes:
$ source /ruta/del/script.sh
$ . /ruta/del/script.sh
2. Ejecución de scripts en un nuevo entorno de shell : Esto crea una nueva shell para la ejecución del script en entorno distinto
y propio. Se ejecuta como un proceso hijo y no permite acceder a variables o funciones en el script desde nuestra shell
actual.
Este tipo de ejecución se hace de una de las dos formas siguientes:
$ bash /ruta/del/script.sh
$ /ruta/del/script.sh
Considérese que esta última forma de invocar al script requiere que éste tenga permiso de ejecución.
Funciones en BASH
Las funciones se definen con la palabra clave function seguido del nombre de la función y entre llaves encerradas las sentencias
que conforman la función. También es posible definir la función con tan sólo escribir el nombre de la misma seguida de ( ) y luego las
sentencias encerradas entre llaves.
Una vez definidas las funciones podemos invocarlas desde cualquier parte del script con tan sólo escribir sus nombres y parámetros
opcionales como si se tratase de ejecutar cualquier otra sentencia o comando de shell.
OpenSourceCollege
Linux for SysAdmins
Página 163
Source Linux
Ejemplos de funciones:
#!/bin/bash
function suma {
echo $(( $1 + $2 ))
}
resta( ) {
echo $(( $1 - $2 ))
}
suma 10 20
resta 20 7
Lectura de datos desde STDIN

El comando read nos permite leer un valor ingresado por el usuario asignándolo a una variable. Ejemplo de uso:
#!/bin/bash
echo "Ingrese su edad: "
read EDAD
echo "Ud. ingreso $EDAD como edad"
Expresiones condicionales
Las expresiones condicionales son usadas para evaluar atributos de ficheros, comparaciones aritméticas y de cadena. Algunos de
estos operadores son:
Operadores Descripción
-e FILE Verdadero si el fichero FILE existe.
-d FILE Verdadero si el fichero FILE existe y es un directorio.
-f FILE Verdadero si el fichero FILE existe y es un archivo regular.
-r FILE Verdadero si el fichero FILE existe y tiene permiso de lectura.
-w FILE Verdadero si el fichero FILE existe y tiene permiso de escritura.
-x FILE Verdadero si el fichero FILE existe y tiene permiso de ejecución.
FILE1 -nt FILE2 Verdadero si el fichero FILE1 es más nuevo (respecto a la fecha de modificación) que FILE2.
FILE1 -ot FILE2 Verdadero si el fichero FILE1 es más antiguo (respecto a la fecha de modificación) que FILE2.
-z CADENA Verdadero si el texto CADENA tiene longitud cero.
-n CADENA Verdadero si el texto CADENA tiene longitud mayor que cero.
CAD1 == CAD2 Verdadero si las cadenas CAD1 y CAD2 son iguales.
CAD1 < CAD2 Verdadero si las cadenas CAD1 está alfabéticamente antes que CAD2.
CAD1 > CAD2 Verdadero si las cadenas CAD1 está alfabéticamente después que CAD2.
NUM1 -eq NUM2 Verdadero si los números NUM1 y NUM2 son iguales.
NUM1 -ne NUM2 Verdadero si los números NUM1 y NUM2 no son iguales.
NUM1 -lt NUM2 Verdadero si el número NUM1 es menor que el número NUM2.
NUM1 -le NUM2 Verdadero si el número NUM1 es menor o igual que el número NUM2.
NUM1 -gt NUM2 Verdadero si el número NUM1 es mayor que el número NUM2.
NUM1 -ge NUM2 Verdadero si el número NUM1 es mayor o igual que el número NUM2.
! Antecedido a cualquier evaluación de operadores niega su resultado.
La forma de utilizar estos operadores es a través del operador [ ] o el comando test como sigue:
$ [ expresión ]
$ test expresión
OpenSourceCollege
Linux for SysAdmins
Página 164
Source Linux
Si la expresión evaluada es verdadera entonces el código de estado retornado es 0, de lo contrario es 1. Debemos recordar que dicho
código de estado puede ser conocido consultando el valor de $?
Sentencias de control: if, then, elif, else
La sentencia if evalúa una expresión y si ésta es cierta podrá ejecutar una o más sentencias de comandos. A través del siguiente
ejemplo nótese su forma de uso:
#!/bin/bash
if [ "$1" -gt 10 ]
then
echo "El numero $1 es mayor que 10"
elif [ "$1" -eq 10 ]
then
echo "El numero $1 es igual a 10"
else
echo "El numero $1 es menor que 10"
fi
Sentencias de control: while, do, done

La sentencia while ejecutará una o más sentencias de comandos mientras que la expresión que evalúe sea cierta. A través del
siguiente ejemplo nótese su forma de uso:
#!/bin/bash
NUM=1
while [ $NUM -le 10 ]
do
echo $NUM
NUM=$(($NUM+1))
done
Sentencias de control: for, do, done

La sentencia for ejecutará una o más sentencias de comandos por cada elemento que exista en la lista, cada uno separado del otro
por espacios en blanco por defecto. Sin embargo el valor de la variable IFS redefinida antes de la ejecución de la sentencia for
permite definir el símbolo usado como separador de elementos en la lista en lugar del espacio en blanco.
A través del siguiente ejemplo nótese su forma de uso:
#!/bin/bash
cd /
for i in *
do
echo "Fichero: $i"
done
for nombre in angel luis milagros pedro

do
echo "Nombre: $nombre"
done
IFS=":"
echo "Directorios que conforman el PATH"
for dir in $PATH
do
echo "Directorio: $dir"
done
Sentencias de control: case, in, esac

La sentencia case ejecutará una o más sentencias de comandos por cada coincidencia del valor de una variable contra uno o más
valores definidos en la sentencia.
A través del siguiente ejemplo nótese su forma de uso:
#!/bin/bash
case $1 in
start)
service httpd start
;;
stop)
service httpd stop
OpenSourceCollege
Linux for SysAdmins
Página 165
Source Linux
;;
restart)
service httpd restart
;;
*)
echo "Uso: $(basename $0) start|stop|restart" > /dev/stderr
;;
esac
Preferencias de perfil de usuario

El sistema operativo por defecto mantiene una serie de archivos que deben ser cargados de manera predeterminada al inicio de sesión
de cada usuario. En estos archivos se suelen almacenar preferencias generales del sistema, algunas relacionadas al idioma, a la shell,
a la codificación de caracteres, configuración de la variable PATH, entre otros.
Por lo general dichos archivos son configurables sólo por el usuario root y aplicables a todos los usuarios del sistema, sin embargo
cada usuario también tiene la posibilidad de configurar preferencias propias a través de archivos de inicio de sesión personalizados.
Un resumen de los archivos que se cargan al inicio de una sesión se muestra a continuación:
Archivo Descripción
Contiene configuraciones generales para todos los usuarios. Es ejecutado al inicio de sesión de cada usuario.
/etc/profile
Sólo root puede modificar este archivo.
Archivo personal de usuario que carga sus preferencias. BASH no ejecuta este archivo si ya existe ~/bash_login o
~/.profile
~/.bash_profile. Se carga en cada inicio de sesión del usuario.
~/.bash_profile Archivo personal de usuario que carga sus preferencias. Se carga en cada inicio de sesión del usuario.
Ejecutado por cada usuario cada vez que invoca a una shell BASH. Considérese que en una sesión activa el usuario
~/.bashrc
puede invocar muchas veces a una shell, tantas como ventanas de terminal ejecute.
~/.bash_logout Archivo de preferencias personales de usuario a ejecutarse al cierre de sesión.
En estos archivos pueden definirse y/o sobreescribirse características tales como:
✔ Alias de comandos.
✔ Variables de entorno personalizadas.
✔ Valor de umask que definirá los permisos por defecto de nuevos archivos y directorios.
✔ Definir propiedades del historial de comandos, tal como el tamaño, ruta del archivo o simplemente desactivarlo.
✔ Directorios de búsqueda de binarios para configurar un PATH propio.
✔ Entre otros...
Ejemplo 37:
a) Configurar el perfil de usuario de modo tal que los archivos creados siempre tengan permisos 600 y los directorios 700 por defecto.
Asimismo configuramos parámetros por defecto para el comando grep y ls:
Agregamos lo siguiente en ~/.bash_profile:
umask 077
alias ls='ls --color'
alias grep='ls –color'
b) Listar la ruta absoluta en la que se encuentran cada uno de los módulos actualmente cargados en el sistema.
Utilizaremos lsmod como parte de nuestro script sencillo:
#!/bin/bash
lsmod | awk '{ print $1 }' |
while read modulo
do
modinfo -n $modulo
done
OpenSourceCollege
Linux for SysAdmins
Página 166
Source Linux
OpenSourceCollege
Linux for SysAdmins
Página 167
Source Linux
1. Identificar a todos los usuarios que tienen una shell válida en el sistema (/bin/bash o /bin/sh) y deshabilitarle a cada uno
de ellos la posibilidad de programar tareas con cron o at y también colocarle /bin/false como shell. . No aplicar esta
restricción al usuario root.
2. Generar una tarea que se ejecute entre Lunes y Viernes a las 22:00 horas que se encargue de generar un reporte del uso de
espacio en el directorio personal de cada uno de ellos. El reporte debe ser enviado por correo al usuario root.
Cada línea del reporte debe tener la forma "USUARIO TAMAÑO".
3. Configurar en un sistema Debian que el servicio vsftpd sea iniciado sólo en los niveles 2 y 3, mientras que en el resto de
niveles debería ser apagado dicho servicio.
OpenSourceCollege
Linux for SysAdmins
Página 168
Source Linux
1. Identificar a todos los usuarios que tienen una shell válida en el sistema (/bin/bash o /bin/sh) y deshabilitarle a cada uno de
ellos la posibilidad de programar tareas con cron o at y también colocarle /bin/false como shell. No aplicar esta restricción al
usuario root.
+ Para eso crearemos un script sencillo:
#!/bin/bash
# script1.sh
#
# Filtramos con grep los usuarios que tienen una shell como /bin/*sh y
# obtenemos de cada línea sólo la primera columna
grep '\/bin\/.*sh$' /etc/passwd | cut -d : -f 1 |
while read usuario
do
# Cada usuario lo agregamos a la denegación de cron y at
echo $usuario >> /etc/cron.deny
echo $usuario >> /etc/at.deny
# Cambiamos la shell del usuario
usermod -s /bin/false $usuario
done
+ Procedemos a darle permiso de ejecución e invocarlo desde la shell:
# chmod +x script1.sh
# ./script1.sh
2. Generar una tarea que se ejecute entre Lunes y Viernes a las 22:00 horas que se encargue de generar un reporte del uso de
espacio en el directorio personal de cada uno de ellos. El reporte debe ser enviado por correo al usuario root.
Cada línea del reporte debe tener la forma "USUARIO TAMAÑO".
+ Para eso crearemos un script como este:
#!/bin/bash
# script2.sh
#
# Creamos un archivo temporal
file=$(mktemp)
du -sh /home/* |
while read size home
do
user=$(echo $home | cut -d / -f 3)
echo "$user $size" >> $file
done
# Enviamos el reporte por correo indicando el archivo $file como contenido

mail -s "Reporte de usuarios" root < $file
# Eliminamos el archivo temporal creado

rm -f $file
+ Procedemos a darle permiso de ejecución e invocarlo desde la shell:
# chmod +x script2.sh
# ./script2.sh
3. Configurar en un sistema Debian que el servicio vsftpd sea iniciado sólo en los niveles 2 y 3, mientras que en el resto de
niveles debería ser apagado dicho servicio.
+ Usamos directamente a invoke-rc.d según lo solicitado:
# update-rc.d -f vsftpd remove

# update-rc.d vsftpd start 90 2 3 . stop 10 0 1 4 5 6 .
OpenSourceCollege
Linux for SysAdmins
Página 169
Source Linux
Unidad 10: Administración de red
10.1. Objetivos
✔ Configurar correctamente los parámetros de red de un sistema Red Hat Linux y Debian GNU/Linux.
✔ Saber manejar sin problemas las herramientas de configuración y consulta de parámetros de red.
✔ Desenvolverse en el manejo de utilitarios de red para la ejecución de tareas rutinarias y de diagnóstico.
✔ Manejar aplicaciones de conexión remota gráfica para sistemas Linux y Windows.
10.2. Configuración de parámetros de red

Introducción
Uno de los aspectos que suele diferir a menudo entre una distribución Linux y otra es la configuración de parámetros de red dado que
cada sistema operativo mantiene sus configuraciones en distintos ficheros con formatos y sintaxis propias, cada cual con sus
respectivas ventajas y/o desventajas frente a otras.
Estas configuraciones de red tienen por objetivo simplificar la asignación de parámetros de red de forma persistente entre cada reinicio
del sistema. Se hace esta mención pues existen herramientas de línea de comandos estándar para todas las distribuciones que se
encargan de asignar los parámetros de red pero éstas no aplican los cambios de modo tal que se mantengan aún luego de reiniciar el
equipo.
Por ello nos centraremos en algunos archivos de configuración específicos para cada función según lo mencionemos líneas abajo.
Configuración de la resolución DNS

Los servidores DNS a los que el sistema operativo ha de consultar durante su funcionamiento se definen dentro del archivo
/etc/resolv.conf cuya sintaxis es la siguiente:
search dominio
nameserver host1
nameserver host2
...
...
Donde:
• search : Define el dominio por defecto en el cual se buscarán los nombres de host en cada consulta DNS.
• nameserver : Define la dirección IP o nombre de un servidor DNS, uno por línea. E
La configuración de este archivo es igual en cualquier distribución Linux, por lo que es aplicable tanto para Red Hat como para Debian
GNU/Linux y sus derivados.
El orden vertical (de arriba hacia abajo) de los servidores DNS definidos con la directiva nameserver define el orden de preferencia
para consultas.
Definición manual de nombres de hosts

Si bien es cierto la resolución de nombres es la función principal de los servidores DNS, a quienes comúnmente delegaremos esta
tarea, es importante saber que es posible definir nosotros mismos una asociación de nombre a dirección IP para ciertos equipos ya
sean de nuestra red local o de una red remota.
Esta asociación manual se realiza en el archivo /etc/hosts y la información aquí presente por defecto tiene mayor relevancia la consulta
DNS hecha para dicho host. Esto quiere decir que si al host ftp.dominio.com le asignamos una dirección IP, el sistema utilizará esta
última sin importar cuál sea la dirección IP a la que resuelva dicho host tras una consulta DNS.
Normalmente podemos definir hosts en este archivo cuando no existe un nombre DNS asociado a uno o más equipos particulares, o
simplemente podemos preferir utilizar estas asociaciones manuales sólo por comodidad personal.
La sintaxis del archivo /etc/hosts es la siguiente:
dirección-IP nombre-de-host [alias ...]
Donde:
• dirección-IP : Define la dirección IP de un host.

• nombre-de-host : Define el nombre del host asociada a una dirección IP.
OpenSourceCollege
Linux for SysAdmins
Página 170
Source Linux
• alias : Define uno o más nombres alternos equivalentes para dicho host.
La configuración de este archivo es igual en cualquier distribución Linux, por lo que es aplicable tanto para Red Hat como para Debian
GNU/Linux y sus derivados.
Configuración de parámetros de red – Red Hat Linux

Los parámetros de red asociados a las interfaces de red tal como la dirección IP, máscara de red y una puerta de enlace por defecto se
configuran en archivos distintos los cuales pasamos a detallar a continuación.
El archivo /etc/sysconfig/network
Este archivo es utilizado para especificar parámetros básicos de configuración de red que no están asociados a una interfaz específica.
Dentro de este archivo se admiten las siguientes directivas:
• NETWORKING=<valor> : A través de un valor yes o no se decide si la red debería ser configurada en el sistema.
• HOSTNAME=<valor> : Se define a través de valor el valor del nombre de host del equipo.
• GATEWAY=<valor> : Se define a través de valor la dirección IP del gateway por defecto del sistema.
• GATEWAYDEV=<valor> : Se define a través de valor por qué interfaz de red se accede al gateway por defecto.
Los archivos /etc/sysconfig/network-scripts/ifcfg-*

Dentro del directorio /etc/sysconfig/network-scripts se ubican archivos de configuración independientes, cada uno para una interfaz de red
específica, tal como lo, eth0, eth1, eth0:0, eth0:1, ppp0, etc.
El nombre del archivo siempre ha de llevar el nombre de la interfaz de red después de la palabra ifcfg- tal como por ejemplo los
archivos ifcfg-eth0, ifcfg-eth1, ifcfg-eth0:0, ifcfg-eth0:1, ifcfg-ppp0, etc.
Los archivos de configuración para interfaces de red Ethernet (ifcfg-eth*) pueden admitir las siguientes directivas:
• BOOTPROTO=<valor> : Donde valor es bootp (se usa BOOTP), dhcp (se usa DHCP) o none (no se usa protocolo de
arranque para su configuración).
• DEVICE=<valor> : Define a través de valor el nombre de la interfaz de red.
• IPADDR=<valor> : Define a través de valor la dirección IP de la interfaz.
• NETMASK=<valor> : Define a través de valor la máscara de red.
• NETWORK=<valor> : Define a través de valor la dirección de red.
• BROADCAST=<valor> : Define a través de valor la dirección de broadcast.
• ONBOOT=<valor> : Define a través de valor (yes o no) si la interfaz se activará al arranque del sistema.
• USERCTL=<valor> : Define a través de valor (true o false) si la interfaz puede ser configurada por usuarios
distintos de root.
• HWADDR=<valor> : Identifica a la interfaz de red por la dirección MAC que posee según valor.
Para crear alias es necesario luego del nombre de la interfaz de red el símbolo dos puntos (:) y luego un identificador tal como
eth0:0, eth0:1. Los alias permiten asignar múltiples direcciones IP a una única interfaz de red física.
Utilitarios de línea de comandos para Red Hat

La configuración de red realizada a través de los archivos ya estudiados no se hace efectiva sino hasta que se reinicia el servicio de
red. Red Hat maneja el script SysV /etc/init.d/network para controlar el estado del servicio de red a través de parámetros como start,
stop, restart, los cuales son invocados como cualquier otro servicio como sigue:
# /etc/init.d/network stop
# service network start
Adicionalmente las herramientas ifup e ifdown permiten manipular interfaces de red específicas para activarlas o desactivarlas sin
afectar el resto de la configuración de otras interfaces existentes en el sistema.
Para desactivar una interfaz de red utilizaríamos ifdown como sigue:
# ifdown eth0
Para activar nuevamente una interfaz de red utilizaríamos ifup como sigue:
# ifup eth0
Es necesario tener presente que estas herramientas ifup e ifdown sólo pueden manipular interfaces de red con una configuración ya
OpenSourceCollege
Linux for SysAdmins
Página 171
Source Linux
definida a través de los archivos /etc/sysconfig/network-scripts/ifcfg-*
Finalmente es importante mencionar que Red Hat provee una herramienta de configuración intuitiva que entre otras cosas hace posible
la configuración de la red haciendo uso de menús sencillos de entender. Esta herramienta se invoca con el comando setup.
Configuración de parámetros de red – Debian GNU/Linux

Los parámetros de red asociados a las interfaces de red tal como la dirección IP, máscara de red y una puerta de enlace por defecto se
configuran en archivos distintos los cuales pasamos a detallar a continuación.
El archivo /etc/hostname
Este archivo es utilizado para definir en él el nombre de host del sistema, sin contener un dominio como parte de él (no FQDN).
El archivo /etc/network/interfaces
Dentro de este archivo se define la configuración de todas las interfaces de red y el gateway por defecto del sistema. La sintaxis de
este archivo es como sigue:
auto <interfaz0>
iface <interfaz0> inet <static|dhcp>
[address <dirección ip>]
[netmask <máscara de red>]
[broadcast <dirección de broadcast>]
[network <dirección de red>]
[gateway <dirección ip gateway>]
auto <interfaz1>
iface <interfaz1> inet <static|dhcp>
[address <dirección ip>]
[netmask <máscara de red>]
[broadcast <dirección de broadcast>]
[network <dirección de red>]
[gateway <dirección ip gateway>]
auto <interfaz2>
...
...
Donde:
• interfaz : Define el nombre de la interfaz de red como eth0, eth1, eth0:0, etc.
• static|dhcp : Definen el modo de configuración de la interfaz como dhcp (dinámico) o static (estático).
• address : Define la dirección IP de la interfaz.
• netmask : Define máscara de red de la interfaz.
• broadcast : Define la dirección IP de broadcast de la interfaz.
• network : Define la dirección IP de red de la interfaz.
• gateway : Define el gateway por defecto del sistema.
Para crear alias es necesario luego del nombre de la interfaz de red el símbolo dos puntos (:) y luego un identificador tal como
eth0:0, eth0:1. Los alias permiten asignar múltiples direcciones IP a una única interfaz de red física.
Utilitarios de línea de comandos para Debian GNU/Linux

La configuración de red realizada a través de los archivos ya estudiados no se hace efectiva sino hasta que se reinicia el servicio de
red. Debian GNU/Linux maneja el script SysV /etc/init.d/networking para controlar el estado del servicio de red a través de parámetros
como start, stop, restart, los cuales son invocados como cualquier otro servicio como sigue:
# /etc/init.d/networking stop
# invoke-rc.d networking start
Adicionalmente las herramientas ifup e ifdown permiten manipular interfaces de red específicas para activarlas o desactivarlas sin
afectar el resto de la configuración de otras interfaces existentes en el sistema.
Para desactivar una interfaz de red utilizaríamos ifdown como sigue:
# ifdown eth0
Para activar nuevamente una interfaz de red utilizaríamos ifup como sigue:
OpenSourceCollege
Linux for SysAdmins
Página 172
Source Linux
# ifup eth0
Es necesario tener presente que estas herramientas ifup e ifdown sólo pueden manipular interfaces de red con una configuración ya
definida a través del archivo /etc/network/interfaces.
10.3. Utilitarios de red
En esta sección estudiaremos una serie de herramientas de manipulación de parámetros de red, consulta, diagnóstico, conexión y
copia remota segura que deben ser conocidas por todo administrador de sistemas operativos Linux.
Control de interfaces de red: ifconfig y ethtool

La herramienta ifconfig permite manipular los parámetros de red de una interfaz así como desactivarla y activarla cuando sea
necesario. Por otro lado ethtool permite consultar y manipular ciertos parámetros de la configuración Ethernet de las interfaces.
La sintaxis de uso de estas herramientas se muestra a continuación:
ifconfig [opciones] [interfaz]

ifconfig [opciones] <interfaz> [argumentos]
Configura interfaces de red
Opciones:
-a : Muestra todas las interfaces de red del sistema, incluso aquellas desactivadas.
-s : Muestra una breve estadística de las interfaces.
Argumentos:
up : Activa la interfaz.
down : Desactiva la interfaz.
[-]arp : Activa o desactiva el uso de ARP en la interfaz.
[-]promisc : Activa o desactiva el modo promiscuo en la interfaz.
metric N : Asigna la métrica N a la interfaz.
mtu N : Asigna el MTU N a la interfaz.
[-]pointopoint DIR : Define la dirección destino DIR para conexiones Punto a Punto (como PPP).
netmask DIR : Define la máscara de red según DIR.
[-]broadcast DIR : Define la dirección de broadcast según DIR.
hw CLASE DIR : Define la dirección de hardware según DIR y la CLASE soportada por el driver.
Esta herramienta ejecutada sin parámetros muestra la información de las interfaces de red activas. Las clases de hardware disponible
para interfaces de red son ether (Ethernet), ax25 (AMPR X.25), ARCnet y netrom (AMPR NET/ROM).
ethtool [opciones] [interfaz]

ethtool -s <interfaz> <argumentos>
Muestra o cambia parámetros Ethernet de interfaces
Opciones:
-i : Muestra la información del driver asociado a la interfaz.

-S : Muestra estadísticas de la interfaz.
-s : Utilizado para cambiar parámetros de la interfaz.
Argumentos:
speed VEL : Define la velocidad VEL de la interfaz (10, 100, 1000 ó 2500)
duplex half|full : Define el modo half o full duplex.
autoneg on|off : Activa o desactiva el autonegociado.
Esta herramienta ejecutada sin parámetros muestra la información de una interfaces de red específica, indicando incluso si ésta tiene
conectividad física o no.
Ejemplo 38:
a) Mostrar información de las interfaces de red activas y luego mostrar sólo la de eth0:
# ifconfig
# ifconfig eth0
OpenSourceCollege
Linux for SysAdmins
Página 173
Source Linux
b) Asignarle una dirección IP y máscara a la interfaz eth0 según 192.168.32.4/255.255.255.0. Luego desactivar esa interfaz.
# ifconfig eth0 192.168.32.4 netmask 255.255.255.0

# ifconfig eth0
c) Verificar que dicha interfaz eth0 sea visible con el parámetro -a de ifconfig, luego cambiarle la dirección MAC a un valor distinto al
actual y levantar nuevamente la interfaz de red.
# ifconfig -a
# ifconfig eth0 hw ether 00:34:11:B4:9E:FD
d) Consultar la información de eth0 para conocer qué driver usa, la velocidad a la que actualmente trabaja y si tiene o no conexión
física a la red.
# ethtool -i eth0
# ethtool eth0
Gestión del enruramiento y conectividad: route, traceroute y ping

La herramienta route permite consultar y modificar la tabla de enrutamiento del sistema. Por otro lado traceroute realiza un trazado
de rutas que existe entre dos hosts remotos, con el propósito de depurar problemas de comunicación.
route [opciones]
route <argumentos> <destino>
Manipula la tabla de enrutamiento del sistema
Opciones:
-n : Muestra la información de hosts en modo numérico, no resuelve a sus nombres.

-s : Muestra una breve estadística de las interfaces.
Argumentos:
add : Agrega una ruta.

del : Elimina una ruta.
-net : Define que el destino es una red.
-host : Define que el destino es un host.
netmask DIR : Define la máscara de red según DIR.
gw GW : Define el gateway GW para el destino especificado.
metric N : Asigna la métrica N en la tabla de enrutamiento.
Esta herramienta ejecutada sin parámetros muestra la tabla de enrutamiento principal del sistema.
traceroute [opciones] <host>

Muestra las rutas a seguir para llegar a un host
Opciones:
-f TTL : Define el tiempo de vida en un valor TTL en lugar del predeterminado que es 1.
-i IFACE : Utiliza la interfaz IFACE para enviar los paquetes a través de él.
ping [opciones] <host>

Envía peticiones ECHO a otro host; comprueba la conectividad
Opciones:
-b : Permite hacer ping a la dirección de broadcast.

-c NUM : Tras realizar 3 peticiones ECHO el programa finaliza.
-i INT : Espera INT segundos entre cada petición ECHO. Sólo root puede definir tiempos menores a 0.2 seg.
-I IFACE : Utiliza la interfaz IFACE para el ping.
Ejemplo 39:
a) Consultar la tabla de enrutamiento de identificar el gateway por defecto del sistema:
OpenSourceCollege
Linux for SysAdmins
Página 174
Source Linux
# route -n
b) Agregar una ruta para llegar a la red 172.16.34.0/24 a través del host 172.31.0.1:
# route add -net 172.16.34.0 netmask 255.255.255.0 gw 172.31.0.1

Es importante tener claro que el gateway que nosotros configuremos para un destino debe pertenecer al mismo segmento de red del
cual forma parte alguna de nuestras interfaces de red.
c) Hacer un trazado de rutas hacia algún host de la red hacia la cual agregamos una ruta recientemente; reforzamos nuestras pruebas
de conectividad y rendimiento con 3 peticiones ECHO de ping:
# traceroute 172.16.34.39
# ping -c 3 172.16.34.39
d) Borrar la ruta anteriormente agregada:
# route del -net 172.16.34.0 netmask 255.255.255.0
Análisis de conexiones activas: netstat, nmap y telnet

La herramienta netstat nos muestra información sobre las conexiones activas del sistema y entre una de sus formas de uso también
nos informa cuáles los puertos que mantenemos en estado de escucha o "abiertos". Por otro lado el venerable escáner de puertos
nmap complementa a netstat en nuestro propósito de conocer nuestros puertos en estado de escucha.
netstat [opciones]
Informa sobre las conexiones activas del sistema
Opciones:
-r : Muestra la tabla de enrutamiento del sistema.

-i : Muestra una breve estadística de las interfaces.
-s : Muestra un resumen estadístico de cada protocolo.
-c : Refresca la información de manera continua cada segundo.
-e : Muestra información adicional sobre las conexiones.
-l : Muestra sólo las conexiones en estado de escucha o LISTEN ("puertos abiertos")
-a : Muestra todas las conexiones que están o no en estado de escucha.
-t : Muestra sólo conexiones TCP.
-u : Muestra sólo conexiones UDP.
-p : Muestra el proceso que está haciendo uso de la conexión.
nmap [opciones] <red/host>

Escáner de puertos
Opciones:
-sT : Realiza un escaneo TCP Connect.

-sS : Realiza un escaneo TCP SYN.
-sU : Realiza un escaneo UDP.
-sP : Realiza un escaneo PING sólo para descubrir qué hosts están conectados en la red.
-A : Intenta detectar la versión del sistema operativo del host escaneado.
-n : No intenta resolver los nombres DNS.
-v : Modo verboso o informativo.
La herramienta telnet fue desarrollada como un cliente de shell remoto para el acceso a otros hosts en la red. En la actualidad dada
la inseguridad de esta aplicación la usaremos sólo para evaluar la conectividad hacia un puerto específico de un host.
Ejemplo 40:
a) Mostrar un listado de nuestras conexiones TCP en estado de escucha:
# netstat -tnl
OpenSourceCollege
Linux for SysAdmins
Página 175
Source Linux
b) Comparar los resultados de nuestras conexiones activas del ejercicio anterior contra un escaneo de puertos local:
# nmap -sT -A -v -n localhost
c) Comprobar que los puertos TCP estén realmente en escucha haciendo un telnet a cada uno de ellos:
# telnet localhost 22
d) Mostrar todas las conexiones TCP y UDP activas, mostrando información detallada y el proceso que las origina:
# netstat -tunape
Consultas DNS: host

La herramienta host permite realizar consultas DNS a través de cualquier registro como A, MX, TXT, NS, entre otros. El uso de esta
herramienta es sencilla, tal como se muestra a continuación:
host [opciones] [servidor DNS]

Opciones:
-t RR : Consulta el valor del registro RR.
Esta herramienta por defecto utiliza los servidores DNS definidos en /etc/resolv.conf para realizar las consultas DNS, pero se le puede
indicar como argumento final el nombre de otro servidor DNS distinto al cual dirigir dichas consultas.
Análisis de tráfico de red: tcpdump y iptraf

La herramienta tcpdump es el analizador de paquetes por excelencia para sistemas UNIX, capaz de poder analizar todo lo que
atraviesa por nuestra interfaz de red e incluso analizar tráfico de una red conectada a través de hubs. Más allá de posibles fines
maliciosos de esta herramienta su uso es muy común para labores de depuración e identificación de problemas de conectividad con un
análisis profundo de cada uno de los paquetes enviados y recibidos.
Por otro lado iptraf es otra herramienta que complementa el análisis y monitoreo de redes gracias a sus variadas funciones de
análisis de tráfico, estadísticas de interfaces, filtros de análisis de conexiones y más.
tcpdump [opciones] [expresión]

Opciones:
-i IFACE : Define la interfaz IFACE de escucha de la herramienta.

-A : Muestra los paquetes en ASCII.
-e : Muestra la informació de capa 2 (enlace) de cada paquete.
-n : No convierte hosts a nombres.
Expresiones:
src host HOST : Filtra el host origen.

dst host HOST : Filtra el host origen.
host HOST : Filtra el host origen y/o destino.
ether src MAC : Filtra el host origen con dirección física MAC.
ether dst MAC : Filtra el host destino con dirección física MAC.
ether host MAC : Filtra el host origen y/o destino con dirección física MAC.
src net RED : Filtra el host origen que pertenece a RED.
dst net RED : Filtra el host destino que pertenece a RED.
net RED : Filtra el host origen y/o destino que pertenece a RED.
src port PORT : Filtra las conexiones cuyo puerto origen es PORT.
dst port PORT : Filtra las conexiones cuyo puerto destino es PORT.
port PORT : Filtra las conexiones cuyo puerto origen y/o destino es PORT.
tcp : Filtra las conexiones TCP.
udp : Filtra las conexiones UDP.
icmp : Filtra las conexiones ICMP.
and , && : AND lógico para conjugar expresiones.
or , || : OR lógico para conjugar expresiones.
not , ! : NOT lógico para conjugar expresiones.
OpenSourceCollege
Linux for SysAdmins
Página 176
Source Linux
Las expresiones son filtros para limitar la cantidad de información mostrada por la herramienta. Estas expresiones pueden ser
agrupadas con paréntesis de manera similar a las operaciones matemáticas.
iptraf [opciones]
Herramienta de monitoreo de redes LAN
Opciones:
-i IFACE : Inicia la herramienta en modo monitor de tráfico IP escuchando por la interfaz IFACE
-d IFACE : Inicia la herramienta en modo detalle estadístico de la interfaz IFACE
-s IFACE : Inicia la herramienta en modo monitor de tráfico TCP y UDP escuchando por la interfaz IFACE
-l IFACE : Inicia la herramienta en modo monitor de LAN escuchando por la interfaz IFACE
-z IFACE : Inicia la herramienta en modo contador de paquetes por tamaño escuchando por la interfaz IFACE
Ejemplo 40:
a) Analizar todo el tráfico que atraviesa nuestra interfaz eth0:
# tcpdump -ni eth0
b) Analizar sólo el tráfico generado desde el host 190.41.72.1 que sea TCP del puerto 80:
# tcpdump -ni eth0 src host 190.41.72.1 and port 80 and tcp
c) Analizar sólo el tráfico que atraviesa nuestra interfaz eth0 excepto las conexiones SSH, HTTP y HTTPS:
# tcpdump -ni eth0 not $ port 22 or 80 or 443 $
Shell remota segura con OpenSSH

OpenSSH es un conjunto de aplicaciones desarrolladas para la realización de comunicaciones encriptadas en una red informática, ya
sea para el acceso a una shell en un host remoto o para la transferencia de archivos entre equipos en la red.
OpenSSH utilizado como cliente de línea de comandos reemplaza a rlogin y telnet como aplicaciones de shell remotas debido a la
falta de seguridad (no hay cifrado) de aquellas.
Es por ello que a continuación revisaremos la herramienta ssh como reemplazo seguro de aquellas dos herramientas mencionadas.
ssh [opciones] [usuario@host]

Cliente OpenSSH de shell remota
Opciones:
-1 : Fuerza el uso de la versión 1 del protocolo.

-i FILE : Realiza la autenticación a través de una llave privada FILE.
-l USER : Conecta al host remoto con las credenciales del usuario USER.
-p PORT : Se conecta al puerto PORT del host remoto en vez de hacerlo al 22 (por defecto).
-X : Activa el reenvío X11.
Por defecto la herramienta intenta conectarse al host remoto con el nombre del usuario que actualmente tenemos activo en nuestra
sesión, a menos que se especifique algo distinto con la opción -l o usando la sintaxis user@host en la línea de comandos.
El reenvío X permite poder conectarnos a otro host vía línea de comandos con SSH y desde ahí invocar la ejecución de un comando
que levante una aplicación gráfica (Ejm: Mozilla Firefox) cuya ventana no sea abierta en el host remoto sino en nuestra propia
pantalla. Esto sólo es válido cuando nos conectamos desde un sistema con Linux, aunque desde Windows también sería posible con
la previa instalación del software Xming.
Conexión SSH basada en llaves privadas

Por defecto los servidores SSH están configurados para permitir la autenticación de usuarios basados en contraseña. Sin embargo se
puede elegir un método alterno de autenticación basado en llaves privadas, para lo cual primero es necesario generar un par de llaves:
la pública y la privada, utilizando la herramienta ssh-keygen.
ssh-keygen [opciones]
OpenSourceCollege
Linux for SysAdmins
Página 177
Source Linux
Herramienta de manejo de llaves SSH
Opciones:
-t TIPO : Crea una llave privada con el TIPO indicado. Los tipos válidos son rsa1 (sólo SSH v1), rsa y dsa (SSH v2).
-f FILE : Invoca al archivo FILE como la llave privada.
-p : Ordena el cambio de clave de una llave privada en vez de crear una nueva.
-R HOST : Remueve cualquier coincidencia de HOST en el archivo known_hosts (hosts conocidos)
El procedimiento de manejo de llaves privadas para las conexiones SSH consiste en lo siguiente:
1. Generar un par de llaves, privada y pública, donde se recomienda muy encarecidamente proteger con contraseña la llave
privada.
$ ssh-keygen -t rsa
Tras ingresar una contraseña dos veces, se debe haber creado un par de archivos de nombre id_rsa e id_rsa.pub dentro del
directorio ~/.ssh, donde el primero representa la llave privada y el segundo la llave pública.
2. La llave pública de dicho par debe permanecer en el host al cual nos deseamos conectar. Esta llave pública debería
guardarse con el nombre authorized_keys dentro del directorio .ssh ubicado en el directorio personal del usuario con el cual
deseamos conectarnos.
Asumiendo que deseamos conectarnos con las credenciales del usuario root a este host, entonces en él colocaremos la llave
pública con el nombre /root/.ssh/authorized_keys.
3. La llave privada de dicho par debe ser mantenida con mucho recelo y cuidado sólo por el usuario que pretende conectarse al
host remoto usando dicha llave. Si la llave privada permanece dentro del directorio personal de nuestro usuario con el
nombre ~/.ssh/id_rsa entonces sólo nos bastará conectarnos al host remoto de esta manera:
$ ssh root@host-remoto
Por defecto el comando ssh busca la llave privada en esa ubicación con ese nombre, pero en caso de no encontrarla como
tal será necesario entonces indicarle manualmente la ruta del archivo de al llave privada como sigue:
$ ssh -i /ruta/llave_privada root@host-remoto
Configuraciones básicas de seguridad

Dado que pretendemos aprovechar el uso de las llaves privadas como un método más seguro de conexión a nuestros servidores vía
SSH, será importante tener en cuenta que el servidor SSH aún está aceptando autenticaciones basadas en password como también
las basadas en llaves privadas.
Podemos indicarle al servidor SSH que sólo permita conectarse a él a través de llaves privadas asegurándonos de tener las siguientes
dos directivas son los valores mostrados debajo en el archivo de configuración /etc/ssh/sshd_config:
PasswordAuthentication No
UsePAM No
Como recomendaciones adicionales de seguridad puede ser recomendable cambiar el puerto de escucha por defecto del 22 a otro
valor distinto, deshabilitar el acceso de root por SSH e incluso limitar qué usuarios serán los permitidos a conectarse vía SSH con las
siguientes directivas:
#Port 22
Port 481
#PermitRootLogin Yes
PermitRootLogin No
AllowUsers admin arengifo@190.41.62.* mflores@200.41.34.21
Si se opta por seguir las recomendaciones arriba mostradas (PermitRootLogin No) hay que tener entonces en cuenta que
tendremos que colocar la llave pública ~/.ssh/authorized_keys ya no en el directorio personal del usuario root sino en uno de los usuarios
permitidos a conectarse (según la directiva AllowUsers).
Copia de archivos en red con OpenSSH

Como ya lo mencionamos anteriormente, OpenSSH nos permite utilizar una de sus herramientas como un cliente de transferencia de
archivos en la red donde la comunicación estará cifrada del mismo modo como sucede con la shell remota ssh.
Esta copia remota es posible desde la línea de comandos Linux gracias a la herramienta scp cuya sintaxis de uso se muestra a
continuación:
OpenSourceCollege
Linux for SysAdmins
Página 178
Source Linux
scp [opciones] [usuario@host]:<archivo/directorio>
Copia segura de archivos en red
Opciones:

-i FILE : Realiza la autenticación a través de una llave privada FILE.
-l LIMIT : Limita la copia a una velocidad de LIMIT Kbit/s
-P PORT : Se conecta al puerto PORT del host remoto en vez de hacerlo al 22 (por defecto).
-r : Copia recursiva; parámetro utilizado para copiar directorios y sus contenidos.
Al igual que el comando ssh, por defecto la herramienta intenta conectarse al host remoto con el nombre del usuario que actualmente
tenemos activo en nuestra sesión, a menos que se especifique algo distinto con la opción usando la sintaxis user@host en la línea de
comandos.
Ejemplo 41:
a) Conectarnos al host remoto 172.31.0.1 con las credenciales del usuario root y un archivo de llave privada ~/llave.ssh:
$ ssh -l root -i ~/llave.ssh 172.31.0.1
b) Copiar el directorio ~sergio/notas del host 192.168.10.32 hacia un directorio de nombre ~/temporal en nuestro equipo:
$ scp -r sergio@192.168.10.32:~/notas ~/temporal
10.4. Aplicaciones gráficas remotas

X11 Forwarding
Como se mencionó anteriormente, es posible ejecutar una aplicación gráfica en un servidor remoto pero visualizar su ventana en
nuestro equipo local gracias al reenvío X11 que se puede habilitar con la opción -x del comando ssh.
No hay mucho que comentar al respecto por su simplicidad, así que resumiremos aquí los procedimientos generales para lograrlo:
• Tener acceso vía SSH a un equipo UNIX con una o más aplicaciones gráficas instaladas.
• Verificar que el servidor SSH de aquel host UNIX tenga habilitado el reenvío X11, para lo cual debemos asegurarnos de
encontrar una directiva como X11Forwarding Yes en el archivo /etc/ssh/sshd_config.
• Conectarnos a aquel host UNIX vía SSH desde un equipo donde tengamos en ejecución algún servidor gráfico X11. Si nos
conectamos desde un equipo Linux con entorno gráfico en ejecución damos por hecho este requerimiento, sin embargo en la
plataforma Windows -que no tiene servidor X11- se requerirá primero instalarle uno como Xming
(http://sourceforge.net/projects/xming/)
• En el momento de conectarnos debemos indicar a nuestro cliente SSH que active el reenvío X11. Desde la línea de
comandos Linux lo hacemos con el parámetro -x del comando ssh; sin embargo en Windows podemos encontrar dicha
opción también a través de las secciones de configuración de un cliente como el PuTTY.
• Una vez conectados a una shell vía SSH con el reenvío X11 activo, simplemente procederemos a ejecutar en el host remoto
cualquier comando que lance una aplicación gráfica. Ejemplo:
$ firefox &
Servidor VNC + XDMCP en Linux

Quizás el entorno gráfico no sea el método más común de conectarse a un equipo Linux, dado que la mayoría de labores
administrativas en estos sistemas se hace a través de una shell de comandos.
Sin embargo para quienes requieran de todos modos acceder a través de una sesión gráfica a un equipo Linux, se tienen dos
alternativas:
1. Aprovechando una sesión activa de un usuario, ejecutar un servidor VNC.

2. Configurar el sistema para integrar XDMCP con VNC para permitir el acceso al Display Manager de manera remota desde un
cliente VNC.
Par ambos casos se requiere tener instalado una versión de servidor VNC. Así que procederemos a instalar uno:
# yum install vnc-server xinetd
La configuración de XDMCP con VNC requiere configurarlo con el demonio xinetd, para lo cual crearemos la siguiente configuración al
final del archivo /etc/services:
OpenSourceCollege
Linux for SysAdmins
Página 179
Source Linux
vnc-1024x768 5901/tcp
Luego de guardar los cambios, crearemos el archivo /etc/xinetd.d/vnc con el siguiente contenido:
service vnc-1024x768
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /usr/bin/Xvnc
server_args = :2 -inetd -query localhost -geometry 1024x768 -once securitytypes=none
}
Luego tras iniciar una sesión como el usuario root en el entorno gráfico, ejecutaremos el comando:
# gdmsetup
y vamos a la pestaña "Remota", donde seleccionaremos la opción que dice "Igual que en la entrada local". De manera alternativa en la
pestaña "Seguridad" podemos activar el check que dice "Permitir entrada remota al administrador del sistema" lo cual en términos de
seguridad no es recomendable pero para fines de prueba estará bien.
Tras un reinicio del GDM -podemos matar todos sus procesos- iniciaremos nuevamente este Display Manager y ya lo tendremos listo
para acceder vía VNC.
Sólo necesitaremos acceder desde algún cliente VNC a la dirección 172.31.0.1:1 (asumiendo dicha dirección IP de ejemplo) y se nos
mostrará la pantalla de inicio de sesión GDM.
Conexión a escritorio remoto

El conocido escritorio remoto típico de los sistemas Microsoft Windows utiliza el protocolo RDP, puerto TCP 3389. Normalmente nos
conectamos desde Windows usando su propio cliente de escritorio remoto (mstsc.exe), sin embargo desde sistemas operativos Linux
poseemos también clientes RDP tales como:
• VINO en entorno GNOME

• KRDC en entorno KDE
Ambas son aplicaciones gráficas intuitivas de fácil uso. Si no trabajamos con ninguno de estos entornos de escritorio podemos instalar
simplemente el paquete rdesktop y conectarnos como sigue a un host remoto vía RDP:
$ rdesktop -u administrador 172.31.10.31
OpenSourceCollege
Linux for SysAdmins
Página 180
Source Linux
1. Configurar un sistema Debian GNU/Linux con 3 direcciones IP (192.168.10.3, 192.168.10.4 y 192.168.10.20) asociadas a la
interfaz de red eth0. Asignarle 8.8.8.8 y 8.8.4.4 como servidores DNS y utilizar 192.168.10.1 como gateway por defecto.
2. Configurar un sistema Red Hat Linux para realizar la misma configuración que el ejercicio anterior utilizando los mismos
parámetros de red.
3. Cambiar la dirección MAC de la interfaz de red eth0 al valor 03:BF:3D:8A:D1:FF.
4. Copiar el contenido del directorio /boot hacia el directorio /tmp del host 172.31.0.10 utilizando las credenciales del usuario
root, limitando la transferencia a una tasa no mayor de 20 Kbit/s.
5. Tras averiguar cuáles son todas las direcciones IP a las que resuelve www.yahoo.com cree una expresión apropiada para
tcpdump de modo tal que se muestre sólo el tráfico HTTP y/o HTTPS originado desde y hacia dicho portal de Internet.
OpenSourceCollege
Linux for SysAdmins
Página 181
Source Linux
1. Configurar un sistema Debian GNU/Linux con 3 direcciones IP (192.168.10.3, 192.168.10.4 y 192.168.10.20) asociadas a la
interfaz de red eth0. Asignarle 8.8.8.8 y 8.8.4.4 como servidores DNS y utilizar 192.168.10.1 como gateway por defecto.
+ Creamos un contenido como el siguiente en el archivo /etc/network/interfaces:
auto eth0
iface eth0 inet static
address 192.168.10.3
netmask 255.255.255.0
gateway 192.168.10.1
auto eth0:0
iface eth0:0 inet static
address 192.168.10.4
netmask 255.255.255.0
auto eth0:1
iface eth0 :1inet static
address 192.168.10.20
netmask 255.255.255.0
+ Tras guardar los cambios en el archivo, reiniciamos el servicio de red:
# invoke-rc.d networking restart
2. Configurar un sistema Red Hat Linux para realizar la misma configuración que el ejercicio anterior utilizando los mismos
parámetros de red.
+ Editamos el archivo /etc/sysconfig/network para asegurarnos que tenga la directiva GATEWAY como sigue:
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=redhat.consultorianet.com
GATEWAY=192.168.10.1
+ Creamos los archivos de configuración /etc/sysconfig/network-scripts/ifcfg-eth0, /etc/sysconfig/network-scripts/ifcfg-eth0:0 y

/etc/sysconfig/network-scripts/ifcfg-eth0:1 con un contenido como el siguiente:
# /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.10.255
HWADDR=08:00:27:C0:3D:DD
IPADDR=192.168.10.3
NETMASK=255.255.255.0
NETWORK=192.168.10.0
ONBOOT=yes
# /etc/sysconfig/network-scripts/ifcfg-eth0:0
DEVICE=eth0:0
BOOTPROTO=static
BROADCAST=192.168.10.255
IPADDR=192.168.10.4
NETMASK=255.255.255.0
NETWORK=192.168.10.0
ONBOOT=yes
# /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE=eth0:1
BOOTPROTO=static
BROADCAST=192.168.10.255
OpenSourceCollege
Linux for SysAdmins
Página 182
Source Linux
IPADDR=192.168.10.20
NETMASK=255.255.255.0
NETWORK=192.168.10.0
ONBOOT=yes
+ Tras guardar los cambios en el archivo, reiniciamos el servicio de red:
# service network restart
3. Cambiar la dirección MAC de la interfaz de red eth0 al valor 03:BF:3D:8A:D1:FF.
+ Primero desactivamos la interfaz de red eth0:
# ifconfig eth0 down
+ Ahora asignamos una dirección MAC distinta:
# ifconfig eth0 hw ether 03:BF:3D:8A:D1:FF
+ Luego restablecemos la interfaz de red, opcionalmente con parámetros anteriores que tenía:
# ifconfig eth0 192.168.10.3 up
4. Copiar el contenido del directorio /boot hacia el directorio /tmp del host 172.31.0.10 utilizando las credenciales del usuario
root, limitando la transferencia a una tasa no mayor de 20 Kbit/s.
+ Utilizamos scp para hacer la copia en un único paso:
# scp -r /boot root@172.31.0.10:/tmp -l 20
5. Tras averiguar cuáles son todas las direcciones IP a las que resuelve www.yahoo.com cree una expresión apropiada para
tcpdump de modo tal que se muestre sólo el tráfico HTTP y/o HTTPS originado desde y hacia dicho portal de Internet.
+ Utilizamos host para averiguar las direcciones IP de www.yahoo.com:
# host -t a www.yahoo.com
+ Tras obtener 69.147.76.15 y 209.191.93.52 como resultados, invocamos a tcpdump con los filtros requeridos de análisis
de paquetes:
# tcpdump -ni eth0 $ host 69.147.76.15 and 209.191.93.52 $ and $ port 80 and 443 $
OpenSourceCollege
Linux for SysAdmins
Página 183
Source Linux
Unidad 11: Servicios de infraestructura de red
11.1. Objetivos
✔ Entender los protocolos DHCP, DNS y NTP así como también su importancia en las redes.
✔ Administrar el direccionamiento IP dinámico en una LAN implementando el servicio DHCP.
✔ Saber configurar el servicio DNS con roles de maestro y esclavo para hospedar zonas de resolución directa e inversa.
✔ Manejar el servicio NTP para una correcta sincronización de tiempo en la red.
11.2. Servicio DHCP

El protocolo DHCP
DHCP, Dynamic Host Configuration Protocol, es un protocolo de nivel de aplicación (capa 7), que tiene como función la asignación de
parámetros de red a los hosts de manera automática. Este protocolo funciona bajo un modelo cliente/servidor, en el cual el servidor
mantiene una información sobre los rangos de direcciones IP a asignar, cuáles de ellas están disponibles, cuáles están usadas por
quién y cuanto tiempo, entre otros datos adicionales.
Un servidor DHCP puede proveer de distintos parámetros de red a un equipo, algunos de los cuales son:
• Dirección IP.
• Dirección de broadcast.
• Máscara de red.
• Servidores DNS.
• Gateway por defecto o puerta de enlace.
• Nombre DNS.
• MTU para la interfaz.
• Tiempo de espera máximo para consultas ARP.
• Servidores NTP.
• Servidores WINS.
El funcionamiento de este protocolo se resume a los siguientes pasos:
1. El cliente envía un paquete DHCPDISCOVER a la dirección de broadcast (255.255.255.255 o la que corresponda a su subred)
para descubrir servidores DHCP disponibles.
El cliente también puede solicitar el arrendamiento de la última dirección IP que se le asignó si es que éste permanece
conectado a la misma red inicial, situación en la cual el servidor DHCP si es autoritativo le podrá otorgar dicha dirección
solicitada o si se tratase de otra red distinta el servidor le obligará a solicitar una dirección IP distinta.
2. El servidor DHCP al recibir una solicitud de arrendamiento IP desde un cliente, le reserva una dirección IP y le extiende el
ofrecimiento de arrendamiento a través de un paquete DHCPOFFER al cliente. Este paquete contiene la dirección MAC del
cliente, la dirección IP que el servidor está ofreciendo, la máscara de subred, el tiempo de arrendamiento y la dirección IP del
servidor haciendo el ofrecimiento.
3. El cliente puede recibir ofrecimientos DHCP de múltiples servidores pero sólo aceptará a uno enviando un paquete
DHCPREQUEST a la dirección de broadcast, el cual es recibido por el servidor elegido por el cliente (el cual le brindará
finalmente una dirección IP) y por otros servidores los cuales retirarán la oferta de dirección IP hecha inicialmente y la
devolverán a su grupo original de direcciones disponibles.
4. Cuando el servidor recibe el paquete DHCPREQUEST desde el cliente, el proceso de configuración entra en su fase final. La
fase de reconocimiento implica el envío de un paquete DHCPACK desde el servidor al cliente. Este paquete incluye el tiempo
de arrendamiento y otros parámetros de configuración que haya solicitado el cliente, terminando así el proceso de
configuración de IP.
5. Cuando el tiempo de arrendamiento está por vencer, el cliente puede percatarse de esto y enviar otro paquete
DHCPREQUEST al servidor, o éste notificar al cliente enviando un paquete DHCPNAK para consultar al cliente si desea
extender su tiempo de arrendamiento.
6. Cuando un cliente desea desconectarse puede enviar un paquete DHCPRELEASE al servidor para liberar así dicha dirección
IP.
OpenSourceCollege
Linux for SysAdmins
Página 184
Source Linux
Implementación de un servidor DHCP
Luego de tener una breve introducción teórica del funcionamiento del protocolo, pasamos al proceso de instalación, configuración y
puesta en marcha de un servidor DHCP.
Se requiere instalar el paquete que contiene el software de servidor DHCP y dependiendo en la distribución Linux en la cual trabajemos
procederemos como sigue:
En Red Hat / CentOS y derivados:
# yum install dhcp -y
En Debian y derivados:
# apt-get install dhcp3-server
Observaciones:
• La instalación del servidor DHCP en Red Hat y derivados por defecto no crea un archivo /etc/dhcpd.conf válido, sino que en el
directorio /usr/share/doc/dhcp-*/ existe un archivo modelo de ejemplo, por lo general llamado dhcpd.conf.sample a partir del cual
podemos basarnos para crear nuestro archivo de configuración principal en /etc/dhcpd.conf.
• La instalación del servidor DHCP en Debian y derivados, lanza por defecto un asistente que dice:
✔ Versión no autoritativa del servidor DHCP ... ACEPTAR
En cualquier de los casos, trabajaremos con un archivo de configuración vacío desde el cual podamos empezar con nuestras propias
directivas explicando cada una de las que agreguemos, por ello procederemos a hacer una copia del original y crear uno en blanco:
# mv /etc/dhcpd.conf /etc/dhcpd.conf.orig
# touch /etc/dhcpd.conf
# mv /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.conf.orig
# touch /etc/dhcp3/dhcpd.conf
Antes de crear contenido es importante conocer la estructura del archivo de configuración dhcpd.conf que es como sigue:
# Sección global
parámetros globales...
# Sección de subnets y grupos.

subnet SUBNET1 netmask MÁSCARA1 {
parámetros específicos de la subnet ...
range IP1 IP2;
host HOSTNAME1 {
parámetros específicos de host ...
}
host HOSTNAME2 {
}
}
subnet SUBNET2 netmask MÁSCARA2 {

parámetros específicos de la subnet ...
range IP3 IP4;
host HOSTNAME3 {
}
OpenSourceCollege
Linux for SysAdmins
Página 185
Source Linux
}
Donde...
1. En la sección global es posible definir algunos parámetros generales tal como el dominio de la organización, los servidores
DNS, el tiempo de arrendamiento, soporte de Dynamic DNS, opciones de logging, entre otros. Cualquiera de estos
parámetros serán adoptados por las subnets o grupos definidos en el resto del archivo a menos que en dichas secciones se
sobreescriban con valores distintos.
2. La sección de subnets permite definir los rangos de direcciones IP a ser asignados a hosts, y para cada uno de ellos se
pueden asignar parámetros específicos o sobreescribir algunos declarados en la sección global. Algunos parámetros
configurables en esta sección puede ser la máscara de red, la dirección de broadcast, la puerta de enlace, el rango de
direcciones IP disponibles, servidores NTP, direcciones MAC para asignación estática de IP a hosts, etc.
Es así que ahora podemos crear un archivo de configuración con un contenido como el siguiente:
ddns-update-style none;
ignore client-updates;
option domain-name "consultorianet.com";

option domain-name-servers 172.31.255.254, 8.8.8.8, 8.8.4.4;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
subnet 172.31.0.0 netmask 255.255.0.0 {

range 172.31.21.200 172.31.21.254;
range 172.31.22.200 172.31.22.254;
option subnet-mask 255.255.0.0;
option broadcast-address 172.31.255.255;
option ntp-servers 172.31.255.254;
option netbios-name-servers 172.31.255.250;
option routers 172.31.255.254;
}
host eramirez {
hardware ethernet 00:A3:BF:32:81:E1;
fixed-address 172.31.21.250;
}
host aruiz {
hardware ethernet 03:1B:00:29:2C:CD;
fixed-address 172.31.21.251;
}
De donde a continuación se hace el análisis de las directivas utilizadas:
Define el modo de trabajo de un sistema DNS dinámico. Valores admisibles son ad-hoc,
ddns-update-style
interim y none. Se elige el último para no usar esta funcionalidad.
ignore client-updates Ignora cualquier requerimiento de los clientes de actualizaciones dinámicas de DNS.
default-lease-time Tiempo por defecto de arrendamiento de direcciones IP.
max-lease-time Tiempo máximo de arrendamiento de direcciones IP.
authoritative Configura el servidor como maestro y autoridad de su segmento de red.
log-facility Define la categoría o facility bajo la cual generar logs para el demonio syslog.
subnet ... netmask Define un segmento de red sobre el cual trabajar.
range Define un rango de direcciones IP disponibles para entregar a clientes.
host Asocia un identificador a un nombre de host al cual se le aplicarán directivas específicas.
OpenSourceCollege
Linux for SysAdmins
Página 186
Source Linux
hardware ethernet Identifica la dirección MAC de un host.
fixed-address Define una dirección IP que siempre será asignada (de forma estática) a un host.
option domain-name Define un nombre de dominio.
option subnet-mask Define la maścara de red.
option broadcast-address Define la dirección de broadcast.
option domain-name-servers Define uno o más servidores que usarán los clientes para resolución de nombres DNS.
option netbios-name-servers Define uno o más servidores que usarán los clientes para resolución de nombres NetBIOS.
option ntp-servers Define uno o más servidores que usarán los clientes para sincronizar la hora vía NTP.
option routers Define el gateway por defecto para los clientes.
Nosotros podemos ajustar el archivo de configuración a nuestras necesidades agregando o eliminando algunas de las directivas
descritas. Una vez que terminemos de editar el archivo de configuración dhcpd.conf es necesario verificar si la sintaxis está correcta
ejecutando:
# dhcpd -t
Internet Systems Consortium DHCP Server V3.0.5-RedHat
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
# dhcpd3 -t
Internet Systems Consortium DHCP Server V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
... comprobando que sólo el texto arriba mostrado sin negrita sea lo único que aparezca. En caso de encontrarse algún error o
advertencia, el comando ejecutado mostrará la observación correspondiente debajo.
Antes de iniciar el demonio DHCP es necesario que revisemos un archivo de opciones, en el cual podríamos indicar en qué interfaces
de red deseamos limitar el funcionamiento de este servicio a través de la modificación del archivo debajo indicado:
# vim /etc/sysconfig/dhcpd
... editando como sigue:
# Command line options here

DHCPDARGS=eth1
# vim /etc/default/dhcp3-server
... editando como sigue:
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACES="eth1"
Iniciando y probando el demonio DHCP

Si la revisión de sintaxis del archivo de configuración dhcpd.conf no arrojó ningún error, entonces se puede proceder a iniciar el demonio
DHCP como sigue:
OpenSourceCollege
Linux for SysAdmins
Página 187
Source Linux
# chkconfig dhcpd on
# service dhcpd start
# tail -f /var/log/messages
# update-rc.d dhcpd defaults

# invoke-rc.d dhcp3-server start
# tail -f /var/log/syslog
Estos pasos se aseguran que el servicio DHCP se ejecute al iniciar el sistema, arranca el demonio y empieza a leer los logs para
analizar el funcionamiento del servicio tras hacer pruebas en el lado del cliente.
Un equipo con Linux, puede desde la línea de comandos solicitar una dirección IP vía DHCP como sigue:
# dhclient eth0
Mientras que en un equipo con Windows, desde la línea de comandos se puede realizar una acción similar (siempre y cuando la
interfaz de red esté configurada para obtener sus parámetros automáticamente) como sigue:
C:\> ipconfig /release
Al invocar una petición DHCP, podremos ver logs como los siguientes en el lado del servidor:
dhcpd: DHCPDISCOVER from 08:00:27:f3:4c:7f via eth0

dhcpd: DHCPOFFER on 172.31.21.200 to 08:00:27:f3:4c:7f (pcxp) via eth0
dhcpd: DHCPDISCOVER from 08:00:27:f3:4c:7f (pcxp) via eth0
dhcpd: DHCPDISCOVER from 08:00:27:f3:4c:7f (pcxp) via eth0
dhcpd: DHCPREQUEST for 172.31.21.200 (172.31.0.202) from 08:00:27:f3:4c:7f (pcxp) via eth0
dhcpd: DHCPACK on 172.31.21.200 to 08:00:27:f3:4c:7f (pcxp) via eth0
... donde apreciamos cómo se realiza la negociación de parámetros de red vía el protocolo DHCP, tal como se describió en teoría al
inicio de este apartado.
El servicio DHCP desde Webmin

Webmin es una herramienta de configuración de servicios para plataformas Linux y otros UNIX. A través de esta herramienta podemos
configurar y monitorear el servicio DHCP, siguiendo estos pasos:
1. Descargar Webmin desde http://www.webmin.com
2. Instalar el RPM o DEB de Webmin en nuestro sistema operativo Linux:
# rpm -ivh webmin-VERSION.noarch.rpm
# dpkg -i webmin_VERSION_all.deb
3. Iniciar el servicio Webmin
# service webmin start
# invoke-rc.d webmin start
4. Conectarse a Webmin con credenciales de administración vía la siguiente URL: http://hostname:10000
5. Dentro de Webmin acceder a 'Servers -> DHCP Server' y dentro revisar las opciones de configuración de este servicio.
OpenSourceCollege
Linux for SysAdmins
Página 188
Source Linux
OpenSourceCollege
Linux for SysAdmins
Página 189
Source Linux
11.3. Servicio DNS
El protocolo DNS
El sistema de nombres de dominio, DNS (Domain Name System) es una base de datos distribuida y jerárquica. Este sistema guarda
información de asociación entre nombres de hosts de Internet a direcciones IP y viceversa, información de ruteo de mails y otros datos
usados por aplicaciones de Internet.
DNS es un protocolo de aplicación y usa tanto UDP como TCP. Los clientes solicitan a los servidores de DNS sus consultas por medio
de UDP para hacer mas rápida la comunicación y utilizan TCP sólo en caso de que llegara a ocurrir una respuesta truncada. En este
protocolo no existe diferencia entre minúsculas y mayúsculas.
Un cliente busca información en un DNS llamando a una librería de sistema conocida como resolver, el cual envía consultas a uno o
más servidores DNS e interpreta sus respuestas.
Dominios y nombres de dominio

Los datos almacenados en el DNS son identificados por nombres de dominio que están organizados como un árbol según límites
administrativos u organizacionales. A cada nodo del árbol conocido como dominio, se le asigna una etiqueta distintiva. El nombre de
dominio del nodo es la concatenación de todas las etiquetas en la ruta desde el nodo en mención hasta la raíz '.'
Esto está representado en forma escrita como una cadena de etiquetas distintivas desde la derecha hacia la izquierda separado por
puntos. Una etiqueta solamente necesita ser única dentro de su dominio padre.
Por ejemplo, un nombre de dominio para un host en la compañía 'Kernel' podría ser ftp.kernel.org, donde 'org' es el dominio de nivel
superior al cual pertenece nuestro host .kernel.org
Para fines administrativos, el espacio de nombres de dominio está dividido en áreas llamadas zonas, cada una empezando en un nodo
y extendiéndose hacia abajo hasta los nodos hoja o hasta donde otra zona comience. Los datos para cada zona son almacenados en
un servidor de nombres, el cual responde a las preguntas sobre la zona usando el protocolo DNS.
OpenSourceCollege
Linux for SysAdmins
Página 190
Source Linux
Los datos asociados con cada nombre de dominio es almacenado en la forma de resource records (RRs) o registros de recurso y
algunos de estos pueden ser:
Nombre del Recurso Tipo de Registro Función

Inicio de autoridad SOA Parámetros que gobiernan la zona.
Servidor de nombres NS Identifica el servidor de nombres de una zona.
Dirección A Asocia un nombre con una dirección IP.
Puntero PTR Asocia una dirección IP con un nombre. Búsqueda inversa.
Oficinas de Correo MX Identifica donde deben ser enviados los correos electrónicos del dominio.
Nombre Canónico CNAME Define un alias para un nombre ya definido.
Información de estación HINFO Utilizado para definir el hardware y/o Sistema operativo de un computador.
Servicios ofertados SRV Anuncia los servicios.
Text TXT Almacena cualquier información.
El formato de un registro de recurso es el siguiente:
[NAME] [TTL] IN <TIPO_REGISTRO> <VALOR>
Donde:
• NOMBRE : Es el nombre del objeto referenciado por el registro del recurso. Puede ser un nombre de estación o un
nombre de dominio.
• TTL : Es el tiempo de vida del registro. Define la cantidad de segundos que la información sobre este registro
puede ser mantenida en la memoria de un servidor de dominios. Si el ttl es omitido usa el ttl indicado por el recurso definido
en la sección SOA.
• IN : Identifica la clase del registro como clase Internet.
• TIPO_REGISTRO : Identifica el tipo de recurso de acuerdo a la tabla anterior.
• VALOR : Es la información específica al tipo de recurso.
El dominio in-addr.arpa
Dentro del espacio de nombres de dominio de la red Internet se encuentra el espacio de nombres de dominio in-addr.arpa cuya función
es asociar una dirección IP con un nombre de dominio de esta manera el usuario a partir de una dirección IP puede conocer el nombre
de dominio asociado a dicha dirección IP. En este espacio de nombres de dominios la dirección IP se lee desde lo más especifico a lo
más general; Por ejemplo www.caida.org. (192.172.226.123) se leería 123.226.172.192.in-addr.arpa. lo cual retorna en una búsqueda a
www.caida.org.
Zonas
Para operar apropiadamente un servidor de nombres, es importante conocer la diferencia entre zona y dominio. Como lo mencionamos
anteriormente, una zona es un punto de delegación en el árbol DNS. Una zona consiste de esas partes contiguas del árbol de dominios
para el cual un servidor de nombres tiene información completa y sobre el cual tiene autoridad. Contiene todos los nombres de dominio
desde un cierto punto hacia abajo en el árbol de dominios excepto aquellos que son delegados a otras zonas.
Un punto de delegación es marcado por uno o más registros de recurso NS en la zona padre, el cual debería coincidir con registros de
recurso NS equivalentes en la raíz de la zona delegada.
Por ejemplo, considérese el dominio 'ejemplo.com' el cual incluye nombres como 'host.aaa.ejemplo.com' y 'host.bbb.ejemplo.com',
aunque sin embargo la zona 'ejemplo.com' incluye solamente delegaciones para las zonas 'aaa.ejemplo.com' y 'bbb.ejemplo.com'. Una
zona puede asociarse exactamente a un único dominio, pero podría también incluir solamente información de una parte de un dominio,
el resto del cual podría ser delegado a otros servidores de nombres. Cada nombre en un árbol DNS es un dominio, incluso si es
terminal u hoja (es decir, no tiene subdominios). Cada subdominio es un dominio y cada dominio excepto la raíz es también un
subdominio.
Métodos de búsqueda
Los servidores de nombres de dominio no sólo pueden ofrecer al resolver los datos de la zona que tienen autoridad sino que pueden
buscar a lo largo del espacio de dominios, datos sobre los que no tienen autoridad. A esto se le como conoce como resolución. La
resolución comienza siempre desde los servidores de nombres de dominio superiores "Servidores de nombres de dominio de raíz
primarios" hasta llegar al servidor de nombres de dominio de nivel secundario que tiene la información acerca de la zona solicitada por
el resolver. El proceso de resolución o búsqueda puede ser de tres tipos: Recursiva, Iterativa o Inversa.
OpenSourceCollege
Linux for SysAdmins
Página 191
Source Linux
• Una búsqueda recursiva; consiste en que un servidor de nombres de dominios a medida que obtiene respuestas durante el
proceso de resolución de nombres de dominios este va guardando los nombres y su dirección IP asociada en una memoria
cache con el fin de acelerar el proceso de búsqueda si la misma información es solicitada nuevamente. Este tipo de consulta
es típicamente hecha por un cliente DNS (un resolver) a un servidor DNS.
• Una búsqueda iterativa; consiste en que el servidor de nombres de dominios da la mejor respuesta posible basado en la
información contenida en los archivos de la zona y en la memoria cache. La preguntas solicitadas a los servidores de
nombres de dominio raíz solo pueden ser iterativas. Este tipo de consulta es típicamente hecha por un servidor DNS a otro,
después de recibir una consulta recursiva desde el cliente.
• Una búsqueda inversa; consiste en que el cliente intenta averiguar el nombre de un nodo de un dominio a partir de una
dirección IP consultando el dominio especial in-addr.arpa
Servidores de nombres autoritativos

Cada zona es servida por al menos un servidor de nombres autoritativo, el cual contiene la información completa para la zona. Para
hacer el DNS tolerante a fallas de red y/o servidores, la mayoría de zonas tienen dos o más servidores autoritativos.
Las respuestas desde los servidores autoritativos tienen el bit de respuesta autoritativa (AA, authoritative answer) activado en los
paquetes de respuesta. Esto los hace fácil de identificar cuando se depuran configuraciones DNS usando herramientas como dig.
El maestro maestro (primario)

El servidor autoritativo donde la copia de la información maestra de la zona se almacena es conocido como servidor primario maestro o
simplemente primario. Este servidor carga los contenidos de la zona desde algún archivo local editado por algún humano o quizás
generado mecánicamente por algún otro archivo local el cual fue editado por humanos. Este archivo es llamado archivo de zona o
archivo maestro.
Servidores esclavos (secundarios)

Los otros servidores autoritativos, los servidores esclavos (también conocidos como servidores secundarios) cargan los contenidos de
la zona desde otro servidor usando un proceso de replicación conocido como transferencia de zona. Habitualmente los datos son
transferidos directamente desde el servidor maestro, pero también es posible transferirlos desde otro servidor esclavo. En otras
palabras, un servidor esclavo puede actuar por sí mismo como un maestro para un esclavo subordinado.
Servidores caché
Las librerías resolver provistas por la mayoría de sistemas operativos son por así decirlo limitadas en el aspecto que ellas no son
capaces de realizar el proceso de resolución DNS completo por sí mismos consultándole directamente a los servidores autoritativos.
En cambio, ellas dejan en manos de un servidor de nombres local la resolución. Este tipo de servidor es llamado servidor de nombres
recursivo; realiza búsqueda recursivas para clientes locales.
Para mejorar el rendimiento, los servidores recursivos guardan en caché los resultados de las búsquedas que ellos realizan. Debido a
que los procesos de recursividad y almacenamiento en caché están íntimamente conectados, los términos servidor recursivo y
servidor caché son usados como sinónimos a menudo.
La cantidad de tiempo que un registro de recurso puede ser retenido en la caché de un servidor de nombres caché es controlado por el
campo TTL (Time To Live o Tiempo de vida) asociado con cada registro de recurso.
Reenvío o forwarding
Incluso un servidor de nombres caché no realiza necesariamente la búsqueda recursiva completa por sí mismo. En cambio, puede
reenviar algunas o todas las consultas que no puede satisfacer desde su caché a otros servidores de nombres caché, comúnmente
conocidos como un forwarder.
Puede haber uno o más forwarders, y ellos son consultados en orden hasta que la lista se termine o hasta que se encuentre una
respuesta. Los forwarders son comúnmente usados cuando uno no desea que todos los servidores en un cierto sitio no interactúen
directamente con los servidores de Internet. Un escenario típico sería un número de servidores DNS internos y un firewall de Internet.
Los servidores que están impedidos de enviar paquetes a través del firewall podrían reenviar su consulta a un servidor que sí pueda
atravesar dicho firewall y este último servidor preguntaría a los servidores DNS de Internet para conseguir la consulta requerida en la
red local.
Un beneficio añadido de usar el reenvío es que la máquina central puede realizar una caché de información mucho más completa del
cual los clientes pueden beneficiarse.
Servidores de nombres en múltiples roles

Hablando de BIND como servidor DNS, éste puede actuar simultáneamente como servidor maestro para algunas zonas, como servidor
esclavo para otras y como servidor caché (o recursivo) para un grupo de clientes locales.
Sin embargo, dado que las funciones de un servicio de nombres autoritativo y las de un servicio caché están lógicamente separadas, a
menudo es mejor ejecutarlos en servidores distintos. Un servidor que solamente ofrece un servicio de nombres autoritativo puede
ejecutarse con la característica de recursividad desactivada, mejorando la confiabilidad y seguridad. Un servidor que no es autoritativo
OpenSourceCollege
Linux for SysAdmins
Página 192
Source Linux
para ninguna zona y solamente ofrece servicios recursivos a clientes locales (un servidor de nombres caché) no necesita ser accesible
desde Internet y puede ser colocado dentro de una zona protegida por un firewall.
Implementación de un servidor DNS

puesta en marcha de un servidor DNS.
Se requiere instalar el paquete que contiene el software de servidor DNS y dependiendo en la distribución Linux en la cual trabajemos
procederemos como sigue:
# yum groupinstall "DNS Name Server"
# apt-get install bind9
Observaciones:
• La instalación de BIND en Red Hat y derivados no crea ningún archivo de configuración /etc/named.conf, se debe crear uno
desde cero o basarse en un archivo de configuración de ejemplo ubicado en /usr/share/doc/bind-*/samples/etc/named.conf.
• La instalación de BIND en Debian crea un archivo de configuración válido y usable en /etc/bind/named.conf el cual por defecto
incluye otros archivos de configuración como /etc/bind/named.conf.options y /etc/bind/named.conf.local.
• El software BIND trae consigo el demonio named, que es el nombre del binario que realiza la función real del servidor DNS.
Por ello a partir de ahora cuando se haga mención al demonio named se estará hablando del servidor BIND.
En cualquier de los casos, trabajaremos con un archivo de configuración vacío desde el cual podamos empezar con nuestras propias
directivas explicando cada una de las que agreguemos, por ello procederemos a hacer una copia del original y crear uno en blanco:
# touch /etc/named.conf
# mv /etc/bind/named.conf /etc/bind/named.conf.orig
# touch /etc/bind/named.conf
Antes de crear contenido es importante conocer la estructura del archivo de configuración dhcpd.conf que es como sigue:
# Sección de ACLs
acl ACL { ... ... };
...
...
// Sección de parámetros globales...

options {
...
...
};
/* Sección de configuración de logs */

logging {
...
...
};
// Sección de vistas y zonas

view "VISTA" {
match-clients { ACL; };
...
...
zone "ZONA" in {
OpenSourceCollege
Linux for SysAdmins
Página 193
Source Linux
...
...
};
};
Donde...
1. La sección de ACLs define a través del contenedor acl una o más ACLs que hacen referencia a clientes a través de
direcciones IP o rangos de red específicos.
2. En la sección de parámetros globales es posible definir dentro del contenedor options directivas del funcionamiento
general del demonio named, tal como los puertos y direcciones de escucha, direcciones de los forwarders, restricciones de
consultas de clientes, soporte de recursividad, etc.
3. En la sección de configuración de logs es posible definir dentro del contenedor logging directivas que especifican cómo se
han de clasificar los logs generados por el demonio named.
4. En la sección de vistas es posible definir dentro del contenedor view directivas que controlen como BIND ha de trabajar de
forma distinta según las consultas que hagan los clientes perteneciendo a una u otra vista. Dentro de una vista es posible
redefinir directivas incluidas en el contenedor options, así como también definir todas las zonas que utilizará el servidor.
A pesar que es posible configurar el servicio sin ninguna definición de vistas, cuando se declara al menos una vista es
obligatorio que todas las zonas estén declaradas en una u otra vista.
5. El archivo de configuración reconoce los comentarios en aquellas líneas que empiecen con el símbolo # o también al estilo
del lenguaje C con los símbolos // o los delimitadores /* y */
Configuración de ACLs
Las ACLs permiten identificar a través de un nombre a uno o más clientes, los cuales serán referenciados en otras secciones de
configuración del demonio named.
Las siguientes son las ACLs predeterminadas:
• any : Coincide con todos los hosts.

• none : No coincide con ningún host.
• localhost : Coincide con todas las direcciones IP del sistema.
• localnets : Coincide con todos los hosts en redes para las cuales el sistema tiene una interfaz de red.
Los siguientes son ejemplos válidos de configuraciones de ACLs:
acl lan { 172.31.0.0/16; 192.168.0.192/27; };

acl wan { 172.16.0.0/22; };
acl remotos { 10.255.243.0/24; 10.250.0.0/16; };
Configuraciones globales
Las directivas de configuraciones globales determinan aspectos del funcionamiento del demonio named. Algunas de estas directivas
son las siguientes:
directory Define el directorio de trabajo de BIND. Cualquier referencia no absoluta a archivos será
referenciada en base a este directorio como punto de partida.
Si es yes (lo predeterminado), entonces un servidor maestro notificará a sus servidores
notify esclavo cuando se haya realizado cambios en los datos de la zona para la cual es
autoritativo.
recursion Si es yes, habilita las respuestas a consultas recursivas hechas por los clientes.
forwarders { }; Especifica la dirección IP de uno o más servidores DNS que se utilizarán como forwarders.
Si el valor es first (lo predeterminado), entonces el servidor primero consultará hacia un
forward forwarder y si éste no sabe la respuesta entonces recién se intentará buscar la respuesta
por sí solo.
Si el valor es only entonces el servidor solamente consultará hacia los forwarders.
allow-notify { ACLs; }; Directiva válida sólo para servidores esclavos. Permite definir qué servidores -aparte de los
maestros- están permitidos a enviar notificaciones de cambios de zona a este servidor.
allow-query { ACLs; }; Especifica qué hosts están autorizados a realizar consultas DNS ordinarias a este servidor.
OpenSourceCollege
Linux for SysAdmins
Página 194
Source Linux
allow-recursion{ ACLs; }; Especifica qué hosts están autorizados a realizar consultas DNS recursivas a este servidor.
allow-transfer{ ACLs; }; Especifica qué hosts están autorizados a recibir transferencias de zona desde este servidor.
listen-on { ADDRESSES; }; Especifica las direcciones IPv4 en las que ha de funcionar el demonio named.
listen-on-v6 { ADDRESSES; }; Especifica las direcciones IPv6 en las que ha de funcionar el demonio named.
Con estas directivas, podemos tener una sección de configuración global de ejemplo similar a la siguiente:
options {
directory "/var/cache/bind";
forwarders {
8.8.8.8;
8.8.4.4;
};
forward first;
listen-on { 127.0.0.1; 172.31.0.202; };
allow-query { localhost; lan; };
};
Configuraciones de logs
La configuración de logs del demonio named se hace dentro de un contenedor logging donde se definen canales (los que clasifican
dónde y cómo se almacenan logs) y categorías (que identifican la naturaleza de logs) para poder así organizar el sistema de logs que
genera BIND.
Una configuración de logs se hace a través de un único contenedor logging con el uso conjunto de las directivas channel y
category siguiendo una sintaxis debajo mostrada:
logging {
channel CANAL {
file|syslog|stderr|null <ARGUMENTOS>;
severity <critical|error|warning|notice|info|debug [nivel]|dynamic>;
print-category <yes|no>;
print-severity <yes|no>;
print-time <yes|no>;
};
category CATEGORÍA {
CANAL1; [CANAL2; ... ]
};
};
Las directivas válida dentro de una sección de configuración de logs son las siguientes:
channel contenedor de directivas de logs que permiten configurar dónde se almacenan, control de
versiones y tamaños de ficheros de logs, el formato usado, niveles de severidad, entre otros.
file Destino del log. Define la ruta de un archivo donde se almacenan los logs.
Usado como directiva complementaria de file, define la cantidad de archivos de logs
versions
antiguos que se almacenarán tras alcanzar cada uno de ellos su tamaño límite máximo.
Usado como directiva complementaria de file, define el tamaño máximo que puede tener
size
un archivo de log, pudiendo especificarse con sufijos como 'k' (KB), 'm' (MB) o 'g' (GB).
syslog Destino del log. Define el facility del demonio syslog al cual se enviarán los logs.
Destino del log. Envía los logs a la salida de error cuando named es ejecutado en primer
stderr
plano y no como demonio en background.
null Destino del log. Ignora cualquier log generado por el demonio named.
Define la severidad de los logs. Funciona exactamente igual que los priorities del demonio
severity
syslog.
print-category Si es yes, se incluirá el nombre de la categoría en el log.
print-severity Si es yes, se incluirá la severidad en el log.
print-time Si es yes, se incluirá la fecha y hora en el log.
OpenSourceCollege
Linux for SysAdmins
Página 195
Source Linux
Identifica la naturaleza del log que genera el demonio named. Las categorías están ya
predefinidas y son default, general, database, security, config, resolver, xfer-
category
in, xfer-out, notify, client, unmatched, network, update, update-security,
queries, dispatch, dnssec, lame-servers, delegation-only y.edns-disabled
La descripción de las categorías disponibles se muestra a continuación:
• default : Cualquier otra categoría para la cual no se ha creado una configuración específica aún.
• general : Lo que no coinciden con ninguna de las otras categorías.
• database : Lo relacionado a la base de datos interna que gestiona la información de zona y caché.
• security : Requerimientos aprobados y rechazados por BIND.
• config : Análisis y procesamiento del archivo de configuración.
• resolver : Resoluciones DNS, tales como las consultas recursivas en favor de los clientes.
• xfer-in : Transferencias de zona que el servidor recibe.
• xfer-out : Transferencias de zona que el servidor envía.
• notify : Notificaciones de cambios de información en zona.
• client : Procesamiento de requerimientos de clientes.
: Mensajes para los cuales BIND fue incapaz de determinar la clase o vista coincidente. Por defecto
• unmatched va al canal null.
• network : Operaciones de red.
• update : Actualizaciones dinámicas.
• update-security : Requerimientos de actualización aprobados y rechazados.
• queries : Consultas DNS hechas por los clientes.
• dispatch : Envío de paquetes entrantes a los módulos del servidor donde han de ser procesados.
• dnssec : Procesamiento de los protocolos DNSSEC y TSIC.
: Lame servers (servidores mal configurados), encontrados por BIND al querer hacerles consultas a
• lame-servers
ellos.
• delegation-only : Delegaciones únicamente.
• edns-disabled : Consultas forzadas a usar DNS plano debido a tiempos de espera agotados.
Así con estas directivas, podemos tener una sección de configuración de logs de ejemplo similar a la siguiente:
logging {
channel seguridad {
file "/var/log/named/seguridad.log" versions 3 size 2m;
severity info;
};
channel consultas {
file "/var/log/named/consultas.log" versions 3 size 5m;
severity debug;
};
channel general {
syslog local4;
severity info;
print-category yes;
};
category queries { consultas; default_syslog; };
OpenSourceCollege
Linux for SysAdmins
Página 196
Source Linux
category security { seguridad; default_syslog; };
category xfer-in { general; };
category xfer-out { general; };
category notify { general; };
category lame-servers { general; };
category client { general; };
category resolver { general; };
};
Observaciones:
• El ejemplo arriba mostrado asume que debe existir el directorio /var/log/named (o /var/named/chroot/var/log/named si es que el
demonio named corre en un entorno chroot debajo de /var/named/chroot) y tener permisos de escritura para el usuario con el
cual es ejecutado el demonio named.
• BIND trae consigo cuatro canales predeterminados como los siguientes:
channel default_syslog {
syslog daemon;
severity info;
};
channel default_debug {
file named.run;
severity dynamic;
};
channel default_stderr {
stderr;
severity info;
};
channel null {
null;
};
• Si no se define ningún contenedor logging entonces BIND utiliza la siguiente configuración de logs de manera
predeterminada:
logging {
category default { default_syslog; default_debug; };
category unmatched { null; };
};
Configuración de vistas
Las vistas en BIND son una potente funcionalidad que permite responder consultas DNS de manera diferente dependiendo quién sea
el que haga la consulta.
Una vista se define con el contenedor view y permite definir una vista del espacio de nombres que visualizarán un grupo de clientes.
Un cliente coincide con una vista si la dirección IP origen de su consulta coincide con una de las ACLs declaradas dentro de la directiva
match-clients y la IP destino coincide con una de las ACLs dentro de la directiva match-destinations.
Si no se especifican las directivas match-clients y/o match-destinations entonces ambas por defecto coincidirán con todas las
direcciones.
Debe tenerse en cuenta que el orden en el que se definan las vistas dentro del archivo named.conf es importante ya que un cliente será
tratado en el contexto de la primera vista con la que coincida.
Las zonas definidas dentro de un contenedor view serán visibles sólo a los clientes que coincidan con dicha vista, sin embargo una
zona puede ser definida dentro de más de una vista con igual o distinta información de zona.
Muchas de las directivas globales de BIND definidas dentro de un contenedor options pueden ser definidas dentro de una vista.
Cuando no se defina un valor específico de una directiva en una vista, se usará por defecto el valor definido dentro del contenedor
options.
Si no existen contenedores view declarados en el archivo de configuración entonces una vista por defecto que coincide con todos los
clientes será automáticamente creada. Así, cualquier declaración de zona (contenedor zone) declarada en el archivo de configuración
pertenecerá a esta vista por defecto, y el contenedor options aplicará dicha vista.
Si se declara de manera explícita al menos un contenedor view entonces todas las declaraciones de zona deben hacerse
necesariamente dentro de una de las vistas.
OpenSourceCollege
Linux for SysAdmins
Página 197
Source Linux
Una configuración de vista se hace con una sintaxis como la debajo mostrada:
view VISTA {
match-clients { ACLs; };
match-destinations { ACLs; };
[ directivas-globales; ... ]
[ zone; ... ]
};
Algunas de las directivas que se pueden encontrar en una configuración de vista son las siguientes:
match-clients { ACLs; }; Identifica a los clientes que serán tratados dentro del contexto de la vista a través de la
coincidencia de la dirección IP origen de su consulta con una de las ACLs declaradas.
match-destinations { ACLs; }; Identifica a los clientes que serán tratados dentro del contexto de la vista a través de la
coincidencia de la dirección IP destino de su consulta con una de las ACLs declaradas.
Si es yes, entonces sólo las consultas recursivas de los clientes coincidentes con la vista
match-recursive-only
serán tratadas dentro del contexto de la misma.
Configuración de zonas
La configuración de zonas se hace a través del contenedor zone el cual contiene muchas directivas que definen su comportamiento
dependiendo del tipo de zona como se configure.
Una configuración de zona se hace con una sintaxis como la debajo mostrada:
zone ZONA [CLASS] {

type master|slave|hint;
[ directivas-de-zona; ]
};
Donde algunas de las directivas que se pueden encontrar en una configuración de zona son las siguientes:
Define cómo el demonio named controla una zona ya sea como master (maestro), slave
type
(esclavo) o hint.
file Define la ruta del archivo que contiene la información de zona.
allow-query { ACLs; }; Su significado es el mismo como directiva global dentro de un contenedor options.
allow-transfer { ACLs; }; Su significado es el mismo como directiva global dentro de un contenedor options.
notify Su significado es el mismo como directiva global dentro de un contenedor options.
masters { ACLs; }; Válido sólo para servidores esclavo. Define uno o más servidores maestros para una zona
desde los cuales solicitar transferencias de zona.
Los tipos de zona válidos son:
: El servidor contiene la copia maestra de los datos de zona y podrá dar respuestas autoritativas
• master
sobre ella.
• slave : El servidor contiene una réplica de una zona desde uno o más servidores maestros.
: Define el grupo inicial de servidores DNS raíz para a partir de ellos obtener la lista vigente de
• hint
servidores raíces.
OpenSourceCollege
Linux for SysAdmins
Página 198
Source Linux
Además la clase CLASS que caracteriza una zona puede ser del tipo IN (Internet), HS (Hesiod) o CHAOS (Chaosnet), donde por lo
general se usará siempre la clase IN (a menos que se sepa realmente por qué se requiere usar otra clase distinta). Si no se especifica
la clase se asumirá IN.
Así, con las directivas estudiadas sobre vistas y zonas es posible crear una configuración de ejemplo de dos zonas, una como maestro
y otra como esclavo, ambas sin definiciones explícitas de vistas como sigue:
zone "." {
type hint;
file "db.root";
};
zone "consultorianet.com" IN {
type master;
file "consultorianet.com.db";
allow-transfer { 172.31.0.200; 172.31.0.201; };
};
zone "0.31.172.in-addr.arpa" IN {
type slave;
file "/var/named/0.31.172.in-addr.arpa.db";
masters { 172.31.0.30; };
};
Donde...
1. Los archivos de zona db.root y consultorianet.com.db especificados como rutas no absolutas, se ubican dentro del directorio de
trabajo del demonio named definido en la directiva global directory.
2. El archivo de zona 0.31.172.in-addr.arpa. se almacena específicamente en /var/named/0.31.172.in-addr.arpa.db por haber sido

definido como una ruta absoluta sin importar cuál sea el valor de la directiva global directory.
Además dicho directorio donde se almacenará la réplica de zona, es decir /var/named, debe tener permisos de escritura para
el usuario con el cual es ejecutado el demonio named.
3. A través de la directiva allow-transfer en la zona consultorianet.com se definen las direcciones IP de dos hosts
autorizados a solicitar y recibir transferencias de zona desde este servidor, los mismos que podrían ser casualmente
servidores esclavos de esta zona.
4. A través de la directiva masters se define la IP de un servidor maestro desde el cual se extraerá una réplica de la
información de zona a través de transferencias de zona que dicho servidor maestro debe haber autorizado para nuestro
servidor.
Y la siguiente sería un ejemplo de una configuración de las mismas dos zonas dentro de contextos de vistas:
acl lan { 172.31.0.0/24; };
view "INTERNA" {
match-clients { lan; localhost; };

recursion yes;
notify yes;
zone "." {
type hint;
file "db.root";
};
type master;
file "consultorianet.com.INTERNA.db";
allow-transfer { 172.31.0.200; 172.31.0.201; };
};
type slave;
file "0.31.172.in-addr.arpa.db";
masters { 172.31.0.30; };
};
OpenSourceCollege
Linux for SysAdmins
Página 199
Source Linux
};
view "EXTERNA" {
/* Coincide con cualquier otro cliente que no coincidió con la vista anterior.
En esta vista podrían encajar los clientes de una red WAN o Internet */
match-clients { any; };
recursion no;
notify no;
zone "." {
type hint;
file "db.root";
};
type master;
file "consultorianet.com.EXTERNA.db";
allow-transfer { none; };
};
};
Donde...
1. La zona "INTERNA" tiene por objetivo atender a los clientes "de confianza" pertenecientes a una red LAN y localhost, a los
cuales se les permite hacer consultas recursivas y además se les muestra una información de zona distinta a la mostrada a
los clientes externos. A esto se suma la existencia de una zona de búsqueda inversa visible sólo para los clientes de la LAN.
2. La zona "EXTERNA" tiene por objetivo atender a otros clientes "no confiables" pertenecientes quizás a una WAN o Intenet, a
los cuales por motivos de seguridad no se les permite hacer consultas recursivas ni tampoco transferencias de zona, además
se les muestra una información de zona distinta a la mostrada a los clientes internos o de la red LAN.
Ahora con las principales directivas de configuración de BIND podemos crear un archivo named.conf de ejemplo completo como el
siguiente:
// Definición de ACLs
acl local { localhost; 172.31.0.0/24; };
acl lan { 172.31.0.0/24; };
// Opciones de configuración global

options {
directory "/var/named";
forwarders {
8.8.8.8;
8.8.4.4;
};
forward first;
listen-on { 127.0.0.1; 172.31.0.202; };
allow-query { local; };
};
// Configuración de logs
logging {
channel seguridad {
file "/var/log/named/seguridad.log" versions 3 size 2m;
severity info;
};
channel consultas {
file "/var/log/named/consultas.log" versions 3 size 5m;
severity debug;
};
channel general {
syslog local4;
severity info;
print-category yes;
OpenSourceCollege
Linux for SysAdmins
Página 200
Source Linux
};
category queries { consultas; default_syslog; };

category security { seguridad; default_syslog; };
category xfer-in { general; };
category xfer-out { general; };
category notify { general; };
category lame-servers { general; };
category client { general; };
category resolver { general; };
};
// Una vista interna con declaración de zonas y permisos

view "INTERNA" {
match-clients { lan; localhost; };

recursion yes;
notify yes;
zone "." {
type hint;
file "db.root";
};
type master;
file "consultorianet.com.INTERNA.db";
allow-transfer { 172.31.0.200; 172.31.0.201; };
};
type slave;
masters { 172.31.0.30; };
};
};
// Una vista externa con declaración de zonas y permisos

view "EXTERNA" {
/* Coincide con cualquier otro cliente que no coincidió con la vista anterior.
En esta vista podrían encajar los clientes de una red WAN o Internet */
match-clients { any; };
recursion no;
notify no;
zone "." {
type hint;
file "db.root";
};
type master;
file "consultorianet.com.EXTERNA.db";
allow-transfer { none; };
};
};
El archivo de configuración de zona

Un archivo de zona es un archivo de texto plano que contiene información que define mapeos entre nombres de dominio y direcciones
IP así como también otros recursos RR.
La sintaxis del archivo de zona está gobernada de acuerdo a los RFC 1035 y 1034. Este formato fue utilizado originalmente por BIND y
adoptado posteriormente como un estándar por otros software de servidor DNS.
El archivo de zona está conformado por líneas donde en cada una se define un registro de recurso, RR (resource record), con una
sintaxis como la siguiente (ya anteriormente estudiada):
[NAME] [TTL] [CLASE] <TIPO_REGISTRO> <DATOS>
OpenSourceCollege
Linux for SysAdmins
Página 201
Source Linux
Donde:
• NAME : Un nombre de dominio propietario referenciado por el RR.

: Tiempo de vida (Time to Live, TTL) en segundos que permanece el RR en la caché de servidores
• TTL
recursivos. Puede ser especificado con sufijos de tiempo como 'h' (horas), 'd' (días) o 'w' (semanas).
• CLASE : La clase, IN por lo general.
• TIPO_REGISTRO :El tipo de RR tal como SOA, NS, MX, A, PTR, TXT, etc.
• DATOS : Datos específicos del RR.
En el archivo de zona hay muchas observaciones importantes que tener en cuenta, las cuales se mencionan a continuación:
1. La directiva $TTL al inicio del archivo de zona permite definir un valor TTL por defecto que será aplicado a todos los RR que
no tengan un valor específico de tiempo de vida.
2. La directiva $ORIGIN al inicio del archivo de zona define el nombre de dominio que será agregado al final de otros nombres
de dominio no absolutos o no completamente cualificados (no FQDN, aquellos que no terminan en punto "."). Si no se
especifica esta directiva el valor del dominio por defecto igual al nombre de la zona.
$ORIGIN si se define debe indicar un nombre de dominio que termine en punto "." (Ejm: $ORIGIN midominio.com.)
3. El símbolo @ fuerza la sustitución del valor actual de $ORIGIN.
4. Si una línea de definición de RR valor NAME o nombre de dominio propietario (el primer campo) es omitido (dejado en blanco)
entonces se asumirá que se trata del mismo valor que el RR anterior.
5. El valor NAME -nombre de dominio propietario- puede ser especificado como un valor absoluto, completamente cualificado o
FQDN si éste termina en punto ".", sino entonces se le añadirá automáticamente el valor del dominio por defecto definido
en $ORIGIN y se usará el nombre de dominio resultante como valor NAME del RR.
6. Si una línea de definición de RR el valor de TTL se omite entonces se usará el valor por defecto definido por la directiva
$TTL al inicio del archivo de zona.
7. Si una línea de definición de RR el valor de CLASE se omite entonces se usará por defecto la clase IN.
8. Un RR puede continuar en más de una línea utilizando paréntesis.
9. Los comentarios se caracterizan por empezar con el símbolo punto y coma ";"
Sintaxis de algunos RR más comunes

Cada RR admite valores distintos en tipo como en cantidad, cada uno dependiendo del propósito que sirva. Por ello se va a revisar los
parámetros de cada uno de los RR usados con mayor frecuencia:
Registro SOA
DOMINIO SOA NAMESERVER EMAIL SERIAL REFRESH RETRY EXPIRY NEG_CACHE
Donde:
• DOMINIO : Nombre de dominio propietario del objeto referenciado por el RR.
: El nombre de un servidor DNS autoritativo para la zona, pudiendo ser externo expresado como
• NAMESERVER FQDN o interno que de no ser FQDn se completará con el valor de $ORIGIN.
: Dirección e-mail de un administrador del servidor DNS para la zona. El símbolo @ de la dirección
• EMAIL
e-mail debe ser reemplazado por un punto "."
: Número entero de 32 bits que tiene como propósito servir de indicador de versiones del archivo de
zona, incrementándose en su valor por cada modificación hecha a los datos de la zona. Es una
• SERIAL
convención usar un formato de fecha como YYYYMMDDnn, donde 'nn' representaría un número de
revisión en caso que se realicen modificaciones a la zona en más de una ocasión al día.
OpenSourceCollege
Linux for SysAdmins
Página 202
Source Linux
:Tiempo en segundos que debe esperar un servidor esclavo para consultar al maestro si se ha
• REFRESH incrementado el número serial para entonces iniciar un refresco de los datos con una nueva
transferencia de zona. Puede indicarse con sufijos de tiempo como 'm', 'h', 'd' o 'w'.
: Tiempo en segundos que el esclavo debe esperar para reintentar conectarse al servidor maestro si
• RETRY el número serial se ha incrementado y una conexión previa ha fallado. Puede indicarse con sufijos
de tiempo como 'm', 'h', 'd' o 'w'.
: Tiempo en segundos que debe transcurrir sin comunicación entre el esclavo y el maestro para que
el primero la información de zona como no autoritativa o inválida. Es decir, si por alguna razón un
servidor esclavo ya no puede establecer contacto con un servidor maestro, se inicia un conteo en
• EXPIRY segundos de esta incomunicación mientras el esclavo aún puede responder a consultas de manera
autoritativa, pero al llegar el conteo de segundos al límite impuesto por EXPIRY entonces la
información guardada en caché por el servidor esclavo ya no será válida.
Se recomienda asignar un valor de 2 a 4 semanas.
: Define el tiempo en segundos del TTL de la caché negativa, es decir el tiempo máximo que los
• NEG_CACHE clientes (resolvers) almacenarán en caché las respuestas NXDOMAIN (non-existent domain).
El valor máximo admisible es 3 horas.
Por lo general el registro SOA se define dividido en varias líneas usando los símbolos paréntesis para lograr facilitar la lectura de los
comentarios descriptivos de sus campos, pero nada impide declararlo en una única línea.
Registro NS
DOMINIO NS NAMESERVER
Donde:
: El nombre de un servidor DNS autoritativo para la zona, pudiendo ser externo expresado como
FQDN o interno que de no ser FQDN se completará con el valor de $ORIGIN. Si es interno este
• NAMESERVER nombre de host no puede ser un alias (CNAME) sino tener una dirección propia (registro A).
Se deben definir tantos RR de este tipo como servidores de nombres autoritativos para esta zona
existan.
Registro MX
DOMINIO MX PRIORIDAD HOSTNAME
Donde:
: Valor numérico (de 0 a 65535) que expresa la preferencia relativa a otros registros MX de la zona.
• PRIORIDAD
A menor valor numérico mayor será la preferencia.
: Nombre de host de un servidor de correo que puede ser externo expresado como FQDN o interno
que de no ser FQDN se completará con el valor de $ORIGIN. Si es interno este nombre de host no
• HOSTNAME puede ser un alias (CNAME) sino tener una dirección propia (registro A).
Se pueden crear tantos registros MX como servidores de correo válidos admitan la recepción de
correos electrónicos para el dominio referenciado en la zona.
Registro A
DOMINIO A ADDRESS
Donde:
OpenSourceCollege
Linux for SysAdmins
Página 203
Source Linux
• ADDRESS : Dirección IP a la cual resuelve el nombre de dominio.
Registro CNAME
DOMINIO CNAME ALIAS
Donde:

: Nombre de host alterno que se mapea a un nombre ya existente con un registro A interno al
• ALIAS
dominio.
Registro PTR
ADDRESS PTR DOMINIO
Donde:
: Nombre de dominio propietario (dirección IP) del objeto referenciado por el RR en una zona de
• ADDRESS búsqueda inversa (in-addr.arpa). Si no es FQDN se le agrega el valor de $ORIGIN.
• DOMINIO : Nombre de dominio a la cual resuelve la dirección IP.
Así con la sintaxis de un archivo de zona ya estudiada se puede mostrar dos archivos de ejemplo, uno que corresponda a una zona de
búsqueda directa y otro de una zona de búsqueda inversa acorde a los ejemplos de zonas previamente mostrados líneas arriba.
El siguiente correspondería a la zona consultorianet.com de la vista INTERNA anteriormente declarada como ejemplo:
$ORIGIN consultorianet.com.
$TTL 2h
@ SOA ns1.consultorianet.com. admin.consultorianet.com. (

2009121802 ; Serial
30m ; Refresh
3m ; Retry
4w ; Expiry
1h ) ; Negative cache TTL
NS ns1
NS ns2
ns1 A 172.31.0.201
ns2 A 172.31.0.202
mail A 172.31.0.20
www A 172.31.0.10
ftp A 172.31.0.14
correo CNAME mail
El siguiente correspondería a la zona consultorianet.com de la vista EXTERNA anteriormente declarada como ejemplo:
$ORIGIN consultorianet.com.
$TTL 2h
; Registro SOA escrito en una unica linea

@ SOA ns1.consultorianet.com. admin.consultorianet.com. 2009121802 2h 3m 4w 2h
NS ns1
NS ns2
OpenSourceCollege
Linux for SysAdmins
Página 204
Source Linux
MX 10 mail
MX 20 aspmx.l.google.com.
MX 30 alt1.aspmx.l.google.com.
ns1 A 190.41.62.3
ns2 A 190.41.62.6
mail A 190.41.62.2
www A 190.41.62.4
correo CNAME mail
El siguiente correspondería a la zona de búsqueda inversa 0.31.172.in-addr.arpa de la vista INTERNA anteriormente declarada como
ejemplo:
$ORIGIN 0.31.172.in-addr.arpa.
$TTL 3h
@ SOA ns1.consultorianet.com. admin.consultorianet.com. 2009121801 3h 3m 4w 2h

NS ns1.consultorianet.com.
NS ns2.consultorianet.com.
; 172.31.0.201
201 PTR centos.consultorianet.com.
; 172.31.0.202
202 PTR debian.consultorianet.com.
; 172.31.0.20
20 PTR mail.consultorianet.com.
Finalmente, el archivo de la zona hint que define los servidores de nombres raíz suele tener un contenido predeterminado, no
necesitaremos modificarlo. Su información sería como la debajo mostrada:
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:BA3E::2:30
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2f::f
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::803f:235
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:C27::2:30
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fd::1
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
M.ROOT-SERVERS.NET. 3600000 AAAA 2001:dc3::35
Estos archivos de zona deberían ser creados en las rutas especificadas por las directivas file dentro de un contenedor zone, lo que
puede indicar una ruta específica o una ruta relativa al directorio de trabajo del demonio named (directiva directory).
El directorio de trabajo por defecto en Red Hat / CentOS y derivados es /var/named mientras que en Debian y derivados suele ser
OpenSourceCollege
Linux for SysAdmins
Página 205
Source Linux
/var/cache/bind.
Herramientas administrativas de BIND

El paquete de software BIND trae junto con el demonio named tres herramientas que complementan las tareas administrativas como
son named-checkconf, named-checkzone y rndc, cuya forma de uso de cada una de ellas se muestra a continuación:
named-checkconf [opciones] [archivo named.conf]

Herramienta de chequeo de sintaxis de named
Opciones:
-t DIR : Ingresa al entorno chroot del directorio DIR y en base a él se toman las referencias de rutas de archivos.
-z : Ejecuta una prueba de carga de todas las zonas maestras encontradas en named.conf
Opcionalmente se puede indicar la ruta del archivo named.conf si éste no es encontrado en una ruta predeterminada.
named-checkzone [opciones] <archivo de zona>
Herramienta de chequeo de sintaxis de archivos de zona
rndc [comandos]
Herramienta de control de named
Comandos:
reload : Recarga el archivo de configuración y zonas.

reconfig : Recarga el archivo de configuración y zonas nuevas únicamente.
reload ZONA [CLASE [VISTA]] : Recarga una zona específica.
refresh ZONA [CLASE [VISTA]] : Programa un mantenimiento inmediato para una zona específica.
retransfer ZONA [CLASE [VISTA]] : Realiza una transferencia de zona sin verificar el número serial.
notify ZONA [CLASE [VISTA]] : Vuelve a enviar mensajes NOTIFY para una zona específica.
querylog : Activa el registro de consultas DNS de los clientes.
stop : Detiene el demonio named.
flush : Limpia toda la caché del servidor.
flush [VISTA] : Limpia toda la caché de una vista específica.
status : Muestra información de estado del servidor.
Iniciando named
Luego de haber estudiado la sintaxis de los archivos de configuración, es necesario revisar si éstos no contienen ningún error para
proceder entonces a iniciar el demonio named.
Así, verificaremos la sintaxis del archivo de configuración named.conf ejecutando:
# named-checkconf
... o si se ejecuta BIND en un entorno chroot (comportamiento por defecto en Red Hat / CentOS y derivados), ejecutaremos el comando
de la siguiente forma:
# named-checkconf -t /var/named/chroot
... el cual si no encuentra ningún error de sintaxis no mostrará salida alguna en la pantalla, de lo contrario informará de las advertencias
o errores encontrados en el archivo de configuración.
También es necesario verificar la sintaxis de los archivos de zona ejecutando comandos similares a:
# named-checkzone consultorianet.com /var/named/consultorianet.com.INTERNA.db

zone consultorianet.com/IN: loaded serial 2009121803
OK
... o si BIND corre en un entorno chroot en nuestro sistema (por defecto en Red Hat / CentOS y derivados) se ejecutaría como sigue:
# named-checkzone consultorianet.com /var/named/chroot/var/named/consultorianet.com.INTERNA.db

zone consultorianet.com/IN: loaded serial 2009121803
OK
... lo cual sólo debería mostrarnos una salida como la arriba mostrada. En caso se encuentre alguna inconsistencia o error de sintaxis
en el archivo éste será informado por la herramienta named-checkzone.
Al comprobar que la sintaxis de todos nuestros archivos de configuración son correctos ya es posible iniciar el demonio named como
sigue:
OpenSourceCollege
Linux for SysAdmins
Página 206
Source Linux
# chkconfig named on
# service named restart
# tail -f /var/log/messages
# update-rc.d bind9 defaults

# invoke-rc.d bind9 start
# tail -f /var/log/syslog
Aquí nos aseguramos que el demonio named se ejecute al iniciar el sistema e iniciamos el análisis de los archivos de logs donde de
manera predeterminada se registran los eventos de este demonio. A partir de este momento ya se pueden realizar consultas de prueba
al demonio named referentes a una de las zonas configuradas para averiguar valores de registros NS, MX, PTR, A e incluso
transferencias de zona con el comando host.
El servicio DNS desde Webmin

configurar y monitorear el servicio DNS (BIND, demonio named) siguiendo estos pasos:
3. Iniciar el servicio Webmin
5. Dentro de Webmin acceder a 'Servers -> BIND DNS Server' (o 'Un-used Modules -> BIND DNS Server')y dentro revisar las
opciones de configuración de este servicio.
OpenSourceCollege
Linux for SysAdmins
Página 207
Source Linux
11.4. Servicio NTP
El protocolo NTP
Network Time Protocol (NTP) es un protocolo de capa de aplicación utilizado en Internet para la sincronización de relojes informáticos a
través del ruteo de paquetes en redes con latencia variable. NTP se basa en UDP en su capa de transporte utilizando el puerto 123.
El uso de este protocolo permite mantener sincronizadas la hora y fecha de equipos informáticos de una red tales como computadores
personales, servidores, teléfonos IP, y otros dispositivos capaces de soportar este protocolo.
Los servidores NTP se clasifican en dos categorías:
• Estrato 1 : Sincronizan con algún reloj externo como los atómicos, GPS o de radio. Son los más precisos.
• Estrato 2 : Sincronizan con algún otro servidor de estrato 1. Son menos precisos.
Un listado de servidores NTP de estrato 1 y 2 pueden ser encontrados en http://www.ntp.org. Es buena práctica mantener siempre al
menos un servidor NTP local en nuestra red para así evitar que los equipos informáticos y otros dispositivos consuman ancho de banda
consultando hacia servidores externos.
Implementación de un servidor NTP

puesta en marcha de un servidor NTP.
Se requiere instalar el paquete que contiene el software de servidor NTP y sus herramientas; dependiendo en la distribución Linux en la
cual trabajemos procederemos como sigue:
# yum install ntp
# apt-get install ntp ntpdate
El archivo de configuración del demonio ntp es /etc/ntp.conf en el cual podemos indicar las direcciones IP de servidores NTP de estrato
1 o 2 que deseamos utilizar.
Nos basaremos en el contenido predeterminado de dicho archivo para realizar algunas modificaciones que sean de nuestro interés.
Sincronizando con otros servidores

A través de la directivas server dentro del archivo /etc/ntp.conf es posible indicar los servidores NTP desde los cuales se harán las
sincronizaciones de tiempo.
El siguiente ejemplo asume que nuestra red local es 172.31.0.0/255.255.0.0 y nuestro host (172.31.255.254) va a comportarse como
servidor NTP para dicha red permitiéndole sólo a ésta y localhost para que realicen consultas de tiempo a nuestro demonio ntp:
...
...
server 0.pool.ntp.org
restrict 172.31.0.0 mask 255.255.0.0

restrict 127.0.0.1
...
...
El siguiente ejemplo asume que formamos parte de la red local 172.31.0.0/255.255.0.0 y nuestro host (distinto del arriba mencionado)
va a comportarse como un cliente NTP que pretende sincronizar el tiempo con el servidor local 172.31.255.254 previamente
configurado:
...
...
server 172.31.255.254
OpenSourceCollege
Linux for SysAdmins
Página 208
Source Linux
...
...
Como se muestra en este último ejemplo, para asegurarnos que sincronicemos con el servidor NTP de la red local es importante que
su definición con la directiva server esté en primer lugar.
Iniciando del demonio ntp

Luego de haber estudiado brevemente y ajustado el archivo de configuración /etc/ntp.conf a nuestras necesidades podemos iniciar el
demonio ntp como sigue:
# chkconfig ntpd on
# service ntpd start
# update-rc.d ntp defaults

# invoke-rc.d ntp start
Tras dejar pasar unos 15 a 20 minutos promedio para que nuestro servidor NTP local sincronice con otros servidores de estratos
superiores, ya podremos desde un cliente consultar la fecha y hora actual de nuestro servidor como sigue:
# ntpdate -q 172.31.255.254
Si deseamos modificar el reloj del sistema en base a la hora que se sincronice desde un servidor NTP ejecutaremos:
# ntpdate 172.31.255.254
OpenSourceCollege
Linux for SysAdmins
Página 209
Source Linux
1. Crear una configuración de servidor DHCP que atienda a un segmento de red con los siguientes datos:
• Tiempo de arrendamiento por defecto y máximo: 6 y 24 horas respectivamente.

• Dirección de red: 172.17.30.0
• Máscara de red: 255.255.255.0
• Rango de direcciones IP: 172.17.30.120 172.17.30.180
• Dominio DNS: laboratorio.com
• Servidores DNS: 172.17.30.13 y 172.17.30.14
• Servidor WINS: 172.17.30.21
• Puerta de enlace: 172.17.30.1
2. Configurar un servidor DNS con BIND y crear una zona maestra de búsqueda directa de nombre laboratorio.com que sólo
pueda ser consultada por localhost y el segmento de red al cual pertenece dicho dominio según la configuración anterior del
servicio DHCP.
Este debe ser un servidor DNS autoritativo para su zona y por razones de seguridad no trabajar como servidor caché, es
decir no aceptar consultas recursivas de clientes.
La información de zona a crearse acorde a:
• Un TTL promedio de 1 hora.

• Instruir a los servidores esclavos que refresquen la información cada 30 minutos.
• Asignar 30 minutos como TTL de caché negativa.
• Los servidores autoritativos deben ser orion.laboratorio.com y omega.laboratorio.com
• No debe declararse MX alguno.
• orion.laboratorio.com resuelve a 172.17.30.13
• omega.laboratorio.com resuelve a 172.17.30.14
• ftp.laboratorio.com resuelve a 172.17.30.25
• wpad.laboratorio.com resuelve a 172.17.30.2
3. Actualizar la configuración anterior para permitir al host omega.laboratorio.com recibir transferencias de zona desde nuestro
servidor maestro y desde la dirección de localhost. Comprobar la correcta configuración realizando una transferencia de zona
manual desde la línea de comandos usando el comando host.
4. Actualizar la configuración anterior para permitir sólo a los hosts con un nombre definido (declarados con registro A en el
archivo de zona) y a localhost hacer consultas recursivas al servidor.
Comprobar la correcta configuración realizando una consulta a nombres de dominios para los cuales el servidor configurado
no es autoritativo. Complementar esta comprobación activando el registro de cada consulta DNS hecha por los clientes de
modo tal que sea visualizada en los logs del demonio named.
5. Sobre la configuración actual del servidor BIND, crear una zona maestra de búsqueda inversa para el segmento de red al
cual pertenece el dominio laboratorio.com. En la información de zona debe definirse la resolución inversa sólo para las
direcciones IP a las que resuelven los hosts con nombre definidos en la zona laboratorio.com.
OpenSourceCollege
Linux for SysAdmins
Página 210
Source Linux
1. Crear una configuración de servidor DHCP que atienda a un segmento de red con los siguientes datos:
• Tiempo de arrendamiento por defecto y máximo: 6 y 24 horas respectivamente.

• Dirección de red: 172.17.30.0
• Máscara de red: 255.255.255.0
• Rango de direcciones IP: 172.17.30.120 172.17.30.180
• Dominio DNS: laboratorio.com
• Servidores DNS: 172.17.30.13 y 172.17.30.14
• Servidor WINS: 172.17.30.21
• Puerta de enlace: 172.17.30.1
+ Creamos el archivo de configuración dhcpd.conf con un contenido como el siguiente:
ddns-update-style none;
authoritative;
log-facility local7;
subnet 172.17.30.0 netmask 255.255.255.0 {

default-lease-time 21600;
max-lease-time 86400;
range 172.17.30.120 172.17.30.180;
option subnet-mask 255.255.255.0;
option domain-name "laboratorio.com";
option domain-name-servers 172.17.30.13, 172.17.30.14;
option netbios-name-servers 172.17.30.21;
option routers 172.17.30.1;
}
+ Para asegurarnos que este segmento de red pueda funcionar correctamente con nuestro servicio DHCP es necesario que
la interfaz de red a través de la cual se ofrecerá dicho servicio tenga asignada una IP perteneciente a dicha subnet, si quiera
una IP configurada como alias.
# ifconfig eth0:1 172.17.30.3 netmask 255.255.255.0
+ Tras verificar que no existan errores de sintaxis reiniciaremos el servicio DHCP:
# dhcpd -t
# service dhcpd restart
2. Configurar un servidor DNS con BIND y crear una zona maestra de búsqueda directa de nombre laboratorio.com que sólo
pueda ser consultada por localhost y el segmento de red al cual pertenece dicho dominio según la configuración anterior del
servicio DHCP.
Este debe ser un servidor DNS autoritativo para su zona y por razones de seguridad no trabajar como servidor caché, es
decir no aceptar consultas recursivas de clientes.
La información de zona a crearse acorde a:
• Un TTL promedio de 1 hora.

• Instruir a los servidores esclavos que refresquen la información cada 30 minutos.
• Asignar 30 minutos como TTL de caché negativa.
• Los servidores autoritativos deben ser orion.laboratorio.com y omega.laboratorio.com
• No debe declararse MX alguno.
• orion.laboratorio.com resuelve a 172.17.30.13
• omega.laboratorio.com resuelve a 172.17.30.14
• ftp.laboratorio.com resuelve a 172.17.30.25
• wpad.laboratorio.com resuelve a 172.17.30.2
+ Crear un archivo de configuración named.conf con un contenido como el siguiente:
// Identificamos el segmento de red a través de una ACL

acl lan { 172.17.30.0/24; };
options {
// Opciones generales
OpenSourceCollege
Linux for SysAdmins
Página 211
Source Linux
// Consultas recursivas desactivadas según lo solicitado

recursion no;
};
zone "laboratorio.com" IN {
// Ubicación del archivo de zona relativo al directorio de trabajo
file "laboratorio.com.db";
// Configuración de maestro para la zona

type master;
// Solamente aceptar consultas de localhost y de la red local

};
+ Creamos el archivo /var/named/laboratorio.com.db que contendrá los datos de la zona laboratorio.com, como sigue:
$ORIGIN laboratorio.com.
$TTL 3600
@ SOA orion.laboratorio.com. admin.laboratorio.com. (

2009121801 ; Serial
30m ; Refresh
3m ; Retry
4w ; Expiry
30m ) ; Negative cache TTL
NS orion
NS omega
orion A 172.17.30.13
omega A 172.17.30.14
ftp A 172.17.30.25
wpad A 172.17.30.2
+ Luego de guardar los cambios en los archivos de configuración creados, verificar la correcta sintaxis de ambos y reiniciar el
demonio named si es que no existe ningún error de sintaxis:
# named-checkzone laboratorio.com /var/named/chroot/var/named/laboratorio.com.db
# service named restart
+ Utilizando el comando host verificaremos si es capaz de resolver consultas recursivas obteniendo respuestas erroneas
como prueba:
# host -t ns hotmail.com localhost
+ Utilizando el mismo comando host realizar consultas DNS para verificar si los datos de la zona fueron configurados de
acuerdo a lo solicitado:
# host -t soa laboratorio.com localhost

# host -t ns laboratorio.com localhost
# host -t a orion.laboratorio.com localhost
# host -t a omega.laboratorio.com localhost
# host -t a ftp.laboratorio.com localhost
# host -t a wpad.laboratorio.com localhost
3. Actualizar la configuración anterior para permitir al host omega.laboratorio.com recibir transferencias de zona desde nuestro
servidor maestro y desde la dirección de localhost. Comprobar la correcta configuración realizando una transferencia de
zona manual desde la línea de comandos usando el comando host.
+ Modificaremos el archivo named.conf de acuerdo al texto resaltado en negrita:
...
...
OpenSourceCollege
Linux for SysAdmins
Página 212
Source Linux
zone "laboratorio.com" IN {
// Ubicación del archivo de zona relativo al directorio de trabajo
file "laboratorio.com.db";
// Configuración de maestro para la zona

type master;
// Solamente aceptar consultas de localhost y de la red local

// Permitimos a localhost y omega.laboratorio.com recibir transferencias de zona

allow-transfer { localhost; 172.17.30.14; };
};
+ Tras guardar los cambios en el archivo de configuración, verificamos la correcta sintaxis y recargamos el demonio named:
# named-checkconf
# rndc reload
+ Utilizando el comando host intentaremos hacer una transferencia de zona desde el mismo servidor DNS maestro
(orion.laboratorio.com):
# host -l laboratorio.com localhost
4. Actualizar la configuración anterior para permitir sólo a los hosts con un nombre definido (declarados con registro A en el
archivo de zona) y a localhost hacer consultas recursivas al servidor.
Comprobar la correcta configuración realizando una consulta a nombres de dominios para los cuales el servidor configurado
no es autoritativo. Complementar esta comprobación activando el registro de cada consulta DNS hecha por los clientes de
modo tal que sea visualizada en los logs del demonio named.
+ Modificaremos el archivo named.conf de acuerdo al texto resaltado en negrita:
...
...
// Identificamos en una ACL a los clientes permitidos a hacer consultas recursivas

acl recursive-clients {
172.17.30.13;
172.17.30.14;
172.17.30.25;
172.17.30.2;
};
options {
// Opciones generales
// Habilitamos la recursividad
recursion yes;
// Configuramos de manera selectiva quiénes pueden hacer consultas recursivas

allow-recursion { localhost; recursive-clients; };
/* Para que la recursividad funcione es necesario definir forwarders a quiénes

consultar los dominios para los que no somos autoritativos. Usaremos los DNS
públicos de Google */
forwarders { 8.8.8.8; 8.8.4.4; };
};
...
...
+ Tras guardar los cambios en el archivo de configuración, verificamos la correcta sintaxis y recargamos el demonio named:
# named-checkconf
# rndc reload
+ Activamos el registro de las consultas DNS si es que no está ya activado:
OpenSourceCollege
Linux for SysAdmins
Página 213
Source Linux
# rndc status | grep logging
# rndc querylog
+ Visualizamos los logs mientras hacemos consultas no autoritativas de prueba desde localhost y desde otro equipo no
autorizado (no definido dentro de la ACL recursive-clients):
# tail -f /var/log/messages | grep named
# host -t mx gmail.com localhost

Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
gmail.com mail is handled by 20 alt2.gmail-smtp-in.l.google.com.

gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
$ host -t mx gmail.com 172.17.30.13

gmail.com MX record query refused by debian.consultorianet.com
1. Sobre la configuración actual del servidor BIND, crear una zona maestra de búsqueda inversa para el segmento de red al
cual pertenece el dominio laboratorio.com. En la información de zona debe definirse la resolución inversa sólo para las
direcciones IP a las que resuelven los hosts con nombre definidos en la zona laboratorio.com.
+ Modificaremos el archivo named.conf agregando lo siguiente al contenido actual:
...
...
// Zona de búsqueda inversa para la red 172.17.30.

// Configuración como maestro para la zona

type master;
// Archivo de configuración de zona

};
+ Creamos el archivo /var/named/30.17.172.in-addr.arpa.db que contendrá los datos de la zona 30.17.172.in-addr.arpa, como
sigue:
$ORIGIN 30.17.172.in-addr.arpa.
$TTL 1w
@ SOA orion.laboratorio.com. admin.laboratorio.com. (

2009121801 ; Serial
6h ; Refresh
5m ; Retry
4w ; Expiry
2h ) ; Negative cache TTL
NS orion.laboratorio.com.
NS omega.laboratorio.com.
13 PTR orion.laboratorio.com.
14 PTR omega.laboratorio.com.
25 PTR ftp.laboratorio.com.
2 PTR wpad.laboratorio.com.
+ Luego de guardar los cambios en los archivos de configuración, verificar la correcta sintaxis de ambos y recargar el
demonio named si es que no existe ningún error de sintaxis:
# cd /var/named/chroot/var/named
# named-checkzone 30.17.172.in-addr.arpa 30.17.172.in-addr.arpa.db
OpenSourceCollege
Linux for SysAdmins
Página 214
Source Linux
# rndc reload
+ Utilizando el comando host realizar consultas DNS para verificar si los datos de la zona fueron configurados de acuerdo a
lo solicitado:
# host -t ptr 172.17.30.13 localhost

Name: localhost
Address: 127.0.0.1#53
Aliases:
13.30.17.172.in-addr.arpa domain name pointer orion.laboratorio.com.

Name: localhost
Address: 127.0.0.1#53
Aliases:
14.30.17.172.in-addr.arpa domain name pointer omega.laboratorio.com.

Name: localhost
Address: 127.0.0.1#53
Aliases:
25.30.17.172.in-addr.arpa domain name pointer ftp.laboratorio.com.

Name: localhost
Address: 127.0.0.1#53
Aliases:
2.30.17.172.in-addr.arpa domain name pointer wpad.laboratorio.com.
OpenSourceCollege
Linux for SysAdmins
Página 215
Source Linux
Unidad 12: Servidor de archivos e impresión
12.1. Objetivos
✔ Saber configurar un servidor Samba para que se comporte como servidor de archivos independiente, PDC de dominios al
antiguo estilo NT o como miembro de un dominio Active Directory.
✔ Configurar correctamente el demonio winbind para que sea capaz de mapear usuarios y grupos de un dominio Active
Directory utilizando una configuración de Kerberos.
✔ Conocer las configuraciones básicas necesarias para compartir y usar recursos compartidos de un servidor NFS.
✔ Implementar un servidor FTP básico a través del demonio vsftpd.
✔ Saber generar reportes gráficos amigables sobre el tráfico de las cargas y descargas del servicio FTP.
12.2. Samba y CUPS para redes Microsoft
¿Qué es Samba?
Samba es una implementación libre para sistemas operativos UNIX de los protocolos SMB/CIFS, que permite implementar un servidor
de archivos para redes Microsoft.
Samba permite asumir las funciones de cliente, servidor o ambos en las redes Microsoft para realizar tareas comunes en ellas tales
como resolución de nombres NetBIOS, navegación de equipos en grupos de trabajo, acceder y compartir recursos compartidos,
comportarse como PDC para dominios NT.
En esta sección nos centraremos en aprender los procedimientos de configuración de un servidor Samba para adoptar distintos roles.
Instalación de Samba
El procedimiento de instalación de Samba es sencillo:
# yum groupinstall "Windows File Server"
# apt-get install samba smbfs smbclient
En ambos casos se instala la Suite Samba, que consiste de los programas de servidor y cliente además de otras herramientas útiles
asociadas a este servicio.
Observaciones:
• La instalación de Samba en Debian por defecto lanza un asistente que realiza dos preguntas, en una de ellas nos consulta el
grupo de trabajo por defecto que tenemos en nuestra red, y en la otra pregunta nos pide confirmación si deseamos o no
modificar la configuración de Samba para que se integre con un servicio DHCP.
No importa mucho las respuestas dadas a estas preguntas dado que empezaremos con una configuración desde cero.
Configuración esencial de Samba

Samba basa su configuración en el archivo /etc/samba/smb.conf el cual tiene la siguiente sintaxis:
# Sección global, contiene directivas del funcionamiento general de Samba

[global]
directiva1=VALOR
directiva2=VALOR
directiva3=VALOR
...
...
# Recurso especial que hace referencia al directorio personal de los usuarios

[homes]
directiva1=VALOR
directiva2=VALOR
directiva3=VALOR
...
...
OpenSourceCollege
Linux for SysAdmins
Página 216
Source Linux
# Recurso especial que hace referencia a las impresoras configuradas en el sistema
[printers]
directiva1=VALOR
directiva2=VALOR
directiva3=VALOR
...
...
# Recurso compartido con el nombre RECURSO

[RECURSO]
directiva1=VALOR
directiva2=VALOR
directiva3=VALOR
...
...
Cada una de las secciones de configuración tiene un nombre propio y éste se define dentro de los corchetes [ ], así global,
printers y homes son nombres especiales reservados por Samba para los propósitos arriba mencionados.
Cualquier otro nombre encerrado entre corchetes hace referencia a un recurso compartido, que puede ser un directorio que comparte
datos o una impresora.
Dentro del directorio /etc/samba también existe un archivo de nombre lmhosts el cual tiene por objetivo contener una lista de
asociaciones de nombres NetBIOS a direcciones IP.
Nota importante sobre los usuarios y permisos en Samba:
• Samba tiene la capacidad de controlar los accesos a los recursos compartidos en base a las credenciales de autenticación
provistas por los clientes al conectarse.
Por defecto dichas credenciales no suelen ser las mismas que están asignadas en el sistema UNIX (según /etc/password y
/etc/shadow) sino que utiliza un sistema de gestión de usuarios y contraseñas propio de Samba pero que sin embargo
requiere que existan de todos modos dichos usuarios como cuentas del sistema.
Es decir, si se han de asignar los usuarios eruiz y mflores como los autorizados a acceder a uno o más recursos del servidor,
entonces dichos usuarios deben existir en el sistema operativo Linux en un sistema Shadow, cada uno de ellos con atributos
utilizados por Samba como son el UID, GID de los grupos de los que son miembros y el directorio personal.
• Cuando Samba brinda accesos a un usuario a un recurso, lo hace normalmente con el password asignado por el sistema de
contraseñas de Samba, pero usando los privilegios garantizados por el UID que identifica al usuario.
• Samba a través de su configuración permite brindar permisos de lectura y/o escritura según usuarios y grupos en sus
recursos compartidos, pero dichos permisos están limitados por los permisos UNIX reales que existan en el sistema de
archivos.
Esto quiere decir que si se pretende dar acceso de escritura al usuario eruiz sobre un recurso compartido, éste permiso no
se hará efectivo si es que el directorio que está asociado al recurso no permite escribir al usuario eruiz según la
interpretación vigente de los permisos UNIX tradicionales o ACLs definidas.
Configuración de Samba como servidor independiente o standalone

Samba puede comportarse como un servidor de archivos independiente en una red Microsoft, esto quiere decir que no asume un rol de
PDC ni miembro de algún dominio NT o Active Directory, simplemente se comporta como un servidor capaz de compartir diversos
recursos a los usuarios de una red.
Para ello es importante tener en cuenta que Samba puede soporta en este caso un esquema de seguridad basado en recurso (share) o
usuarios (user).
El esquema de seguridad basado en recurso se caracteriza por no requerir al usuario que inicie sesión en el servidor antes de intentar
conectarse a uno de los recursos compartidos, sino sólo se envían las credenciales de autenticación en base a cada recurso al cual se
conectará.
El esquema de seguridad basado en usuarios se caracteriza por forzar a los clientes que primero inicien sesión en el servidor con
algún juego de credenciales válidas antes de intentar conectarse a uno de los recursos compartidos.
En esta sección asumiremos que se usa este último esquema de seguridad. Para ello empezaremos creando un archivo de
configuración vacío:
# cd /etc/samba
# mv smb.conf smb.conf.orig
# touch smb.conf
OpenSourceCollege
Linux for SysAdmins
Página 217
Source Linux
... y crear como contenido del archivo smb.conf lo siguiente:
[global]
security = user
netbios name = fileserver
netbios aliases = samba servidor
server string = Servidor Samba %v
workgroup = CONSULTORIANET
wins support = yes
log file = /var/log/samba/samba.log
log level = 2
max log size = 2000
[homes]
browseable = no
comment = Directorio personal
writeable = yes
public = no
valid users = @users, admin
[musica]
path = /data/musica
comment = Musica compartida
writeable = no
public = no
valid users = admin, eruiz, mperez
[principal]
path = /data/principal
writable = yes
veto files = /*mp3*/*avi*/*mpg*/*wav*/*wma*/*wmv*/*swf*/*pps*/
valid users = @users @sistemas admin operador
read list = @users operador
write list = @sistemas admin
force group = sistemas
create mask = 0770
directory mask = 0770
inherit acls = yes
inherit owner = yes
Este archivo de configuración de ejemplo contiene sólo algunas de las directivas que posiblemente pueden existir en sus secciones
respectivas.
A continuación se muestra un listado detallado de las directivas más importantes que se pueden encontrar en una configuración de
Samba como servidor independiente:
Directivas de ámbito global
El grupo de trabajo del cual forma parte el servidor. También define el nombre del dominio si se
workgroup
usa el esquema de seguridad domain.
netbios name El nombre NetBIOS principal del servidor.
netbios aliases Nombres NetBIOS alternativos asignados al servidor.
server string Descripción del servidor.
security Esquema de seguridad. Valores posibles son: share, user, domain, ads
SI es yes (por defecto) entonces se utilizan contraseñas encriptadas en la negociación con los
encrypt passwords
clientes.
log file La ruta absoluta del archivo de logs de Samba.
log level El nivel de información de los logs.
max log size El tamaño máximo del archivo de logs en KB.
time server Si es yes entonces Samba se anunciará a los clientes de la red como un servidor de tiempo.
OpenSourceCollege
Linux for SysAdmins
Página 218
Source Linux
wins support Si es yes entonces Samba se comporta como un servidor WINS en la red.
Directivas de ámbito de recurso
path La ruta del directorio que se publica como recurso compartido.
browseable Si es yes entonces Samba hará visible este recurso en la lista de visualización a los clientes.
comment Texto descriptivo asociado al recurso.
valid users Lista de usuarios válidos que pueden conectarse al recurso. Un nombre de grupo se especifica
con un símbolo @ por delante.
invalid users Lista de usuarios válidos que no pueden conectarse al recurso. Un nombre de grupo se
especifica con un símbolo @ por delante.
admin users Lista de usuarios que tendrán privilegios de root al conectarse al recurso. Un nombre de grupo
se especifica con un símbolo @ por delante.
writeable Comparte el recurso en modo lectura/escritura. Es el opuesto de la directiva read only.
write list Lista de usuarios que tienen acceso de lectura/escritura.
read list Lista de usuarios que tienen acceso de sólo lectura.
Permite que se puedan conectar al recurso sin utilizar una contraseña. Sinónimo de la directiva
guest ok
public.
create mask Define los permisos por defecto que se aplicarán a archivos creados en este recurso.
directory mask Define los permisos por defecto que se aplicarán a directorios creados en este recurso.
force group Especifica el nombre de grupo que será asignado como grupo primario por defecto para los
clientes que se conectan al recurso.
force user Especifica el nombre de usuario que será asignado como usuario por defecto para los clientes
que se conectan al recurso.
hide dot files Permite mostrar como archivos ocultos aquellos que empiecen con un punto.
Lista de archivos y directorios que se mostrarán como ocultos en el recurso. Esta lista separa
hide files nombres formados por comodines (* y ?) separados por el símbolo slash.
Ejm: /*.tmp/*.mp3/*musica*/
Lista de archivos y directorios que serán invisibles e inaccesibles en el recurso. Esta lista separa
veto files nombres formados por comodines (* y ?) separados por el símbolo slash.
Ejm: /*.tmp/*.mp3/*musica*/
hosts allow Lista de hosts que sí serán permitidos conectarse al recurso.
hosts deny Lista de hosts que no serán permitidos conectarse al recurso.
inherit acls Permite asignar las ACLs por defecto a los archivos y directorios creados en el recurso.
Permite que los archivos y directorios creados adquieran el mismo usuario propietario que el
inherit owner directorio padre, en lugar que este valor sea gobernado por el nombre de usuario que se
conecta al recurso.
Permite que los archivos y directorios creados adquieran los mismos permisos que su directorio
inherit permissions
padre, en lugar que obedezcan a los valores de create mask y/o directory mask
Muchas de las directivas de configuración de Samba aceptan el uso de variables de las cuales algunas son detalladas a continuación:
• %U : Usuario con el cual el cliente se conecta.
• %G : Grupo primario de %U
• %h : Nombre de host del servidor.
• %m : El nombre NetBIOS del cliente.
• %L : Nombre NetBIOS del servidor.
• %M : Nombre de host del cliente.
OpenSourceCollege
Linux for SysAdmins
Página 219
Source Linux
• %I : Dirección IP del cliente.
• %i : Dirección IP local del servidor hacia la cual el cliente estableció conexión.
• %T : Fecha y hora actual.
• %D : Nombre del grupo de trabajo o dominio del usuario actual.
• %$(VAR) : El valor de la variable de entorno VAR.
• %u : Usuario efectivo que Samba asigna a una conexión.
• %g : Grupo primario de %u
• %H : Directorio personal de %u
Tras terminar de editar el archivo de configuración de Samba es siempre importante verificar la sintaxis del mismo en busca de errores
o inconsistencias ejecutando:
# testparm
... el cual informará a través de la salida estándar de cualquier advertencia o error encontrado en la configuración.
Si todo está correctamente configurado se puede proceder a iniciar el servidor Samba como sigue:
# chkconfig smb on
# service smb start
# update-rc.d samba defaults

# invoke-rc.d samba start
Creación de usuarios y contraseñas Samba

Como se mencionó anteriormente, para dar acceso a un usuario o grupo en Samba, éste debe existir en el sistema Linux. A modo de
ejemplo asumiremos que se crea el grupo sistemas, así como también los usuarios admin y operador:
# groupadd sistemas
# useradd -s /bin/false admin
# useradd -s /bin/false operador
Una vez creados los usuarios en el sistema Shadow, procedemos a crear la cuenta en el sistema de usuarios de Samba como sigue:
# smbpasswd -a admin
# smbpasswd -a operador
... lo cual crea la cuenta y le asigna una contraseña ingresada por el usuario desde el teclado. Este mismo procedimiento debe ser
seguido para todas las cuentas de usuario que pretendamos utilizar en Samba para el acceso a nuestros recursos compartidos.
Configuración de Samba como PDC de un dominio NT

Como se mencionó anteriormente, Samba tiene la capacidad de comportarse como controlador de dominios o PDC para los dominios
Windows al estilo NT. Para ello es importante tener en cuenta que Samba obligatoriamente debe usar un esquema de seguridad
basado en usuarios (user).
Para lograr esta configuración de Samba como PDC, empezaremos creando un archivo de configuración vacío:
# cd /etc/samba
# mv smb.conf smb.conf.standalone
# touch smb.conf
... y crear como contenido del archivo smb.conf lo siguiente:
[global]
security = user
server string = PDC Samba %v
OpenSourceCollege
Linux for SysAdmins
Página 220
Source Linux
wins support = yes
domain master = yes
local master = yes
preferred master = yes
os level = 33
passdb backend = tdbsam
domain logons = yes
logon home = \\%L\%U
logon path = \\%L\profiles\%U
logon script = logon.bat
add machine script = /usr/sbin/useradd -s /bin/false %u
admin users = admin
time server = yes
log level = 2
max log size = 2000
[profiles]
path = /data/profiles
writable = yes
public = no
browsable = no
force group = users
[netlogon]
path = /data/netlogon
writable = no
public = no
browsable = no
[homes]
browseable = no
writable = yes
public = no
Este archivo de configuración de ejemplo muestra algunas directivas no vistas hasta ahora, las mismas que a continuación se pasan a
detallar:
Directivas de ámbito global
Fuerza a que Samba se convierta en el visualizador maestro de dominio, conteniendo las listas
de visualización de todas las subredes existentes mantenidas por visualizadores maestros
domain master locales.
Por lo general este valor se configura por defecto en yes si domain logons = yes, y debe
ser configurado con un valor de no si se ha de configurar Samba como BDC.
local master Instruye a Samba a que intente convertirse en el visualizador maestro local en una subred
procurando ser el ganador en cada una de las elecciones realizadas para asumir este rol.
Instruye a Samba para que se convierta en el visualizador maestro de preferencia para su grupo
preferred master de trabajo, forzando una elección en la cual él se presente con cierta ventaja.
Se recomienda usar esta directiva si se configura domain master = yes
os level Valor entero que representa el nivel de SO con el cual Samba se identifica en la red, lo que le ha
de permitir ganar elecciones de visualizador maestro. El valor puede variar entre 0 y 255.
Backend utilizado para el almacenamiento de passwords de Samba. Se recomienda usar
passdb backend
tdbsam cuando se configure como PDC.
domain logons Instruye a Samba a comportarse como controlador de dominio para servicios de estilo NT4.
logon home La ubicación del directorio personal del usuario cuando un cliente inicia sesión en el PDC
controlado por Samba.
La ubicación donde se almacenan los perfiles móviles. Si se desea deshabilitar la funcionalidad
logon path
de perfiles móviles debe especificarse un valor vacío en esta directiva (logon path = "")
logon script Script a ser descargado y ejecutado por los clientes que inician sesión en el PDC controlado por
Samba. La ruta del archivo especificado en esta directiva se toma como una ruta relativa en
OpenSourceCollege
Linux for SysAdmins
Página 221
Source Linux
base al recurso [netlogon] el cual debe ser declarado. El script debe utilizar saltos de línea
CR/LF al estilo DOS.
Script ejecutado por Samba cuando se agregue una máquina al dominio y aún no exista una
add machine script
cuenta UNIX que coincida con el nombre de máquina agregándole el símbolo $ al final.
Acorde a la configuración realizada, debemos asegurarnos que existan los directorios referenciados por los recursos [profiles] y
[netlogon] así como también considerar los permisos adecuados que el primero de ellos tenga para un correcto funcionamiento.
Es así que creamos los directorios y asignamos los propietarios correspondientes:
# mkdir /data/profiles
# mkdir /data/netlogon
# chown :users /data/profiles
Además dentro del directorio /data/netlogon creamos el script logon.bat con un contenido que permita conectar el directorio personal del
usuario como una unidad de red y transformando su formato al estilo DOS:
# echo "net use H: /HOME" > /data/netlogon/logon.bat

# unix2dos /data/netlogon/logon.bat
unix2dos: converting file logon.bat to DOS format ...
Ahora ya podemos revisar la sintaxis del archivo de configuración de Samba y reiniciar el servicio para hacer efectivos los cambios:
# testparm
# service smb restart
# testparm
A partir de este momento el servidor Samba ya se encuentra listo para unir equipos al dominio.
Compartición de impresoras con Samba y CUPS

Samba ofrece soporte de integración con distintos sistemas de impresión en UNIX tal como BSD, LPRNG, AIX, CUPS, entre otros. Por
otro lado CUPS se ha convertido en el sistema de impresión de mayor uso entre las distintas distribuciones Linux, por lo que el estudio
de la configuración de Samba y CUPS para la compartición de impresoras será la elección apropiada.
El sistema de impresión CUPS administra la configuración de sus impresoras por defecto en el archivo /etc/cups/printers.conf, el cual
puede tener un contenido como el siguiente:
<DefaultPrinter EpsonMatricial>
Info Impresora matricial Epson LQ-1070+
DeviceURI parallel:/dev/lp0
Location Sala de reuniones
Shared Yes
State Idle
Accepting Yes
</Printer>
<Printer HPLaser>
Info Impresora laser HP Laserjet 920c
DeviceURI usb:/dev/usb/lp0
Location Oficina de gerencia
Shared Yes
State Idle
Accepting Yes
</Printer>
Si bien es este un modelo del archivo de configuración de impresoras de CUPS, éstas deben ser configuradas accediendo desde el
mismo servidor que corre CUPS a la URL http://localhost:631 usando un navegador Web. En aquella dirección se puede configurar las
impresoras y otras opciones de impresión de CUPS de una forma bastante amigable e intuitiva.
Configurar Samba para que sea capaz de compartir las impresoras ya definidas en el archivo de configuración de CUPS
OpenSourceCollege
Linux for SysAdmins
Página 222
Source Linux
/etc/cups/printes.conf resulta sencillo creando un contenido como el siguiente en el archivo /etc/samba/smb.conf:
[global]
security = user
server string = Servidor de archivos e impresion
log level = 2
max log size = 2000
load printers = yes
printing = cups
printcap name = cups
[printers]
path = /var/spool/cups
public = no
printable = yes
Tras guardar los cambios, verificar la sintaxis del archivo de configuración y reiniciar el servicio Samba ya podremos acceder a las
impresoras compartidas desde otro equipo, por ejemplo un sistema Microsoft Windows XP:
# testparm
# testparm
Configurando Samba como miembro de un dominio Active Directory

Configurar un servidor Samba para que se integre como miembro de un dominio Active Directory abarca algo más que sólo agregar
unas cuantas directivas en el archivo /etc/samba/smb.conf; implica una correcta configuración de Kerberos, NTP y DNS acorde al
servidor controlador del dominio.
Por ello a continuación se resume los pasos a seguir:
1. Instalar el software necesario.
2. Sincronizar los tiempos del servidor Samba y el AD (una diferencia de tiempos menor a 5 minutos es requisito de Kerberos).
Esto implica configurar el servicio NTP.
3. Configurar la resolución DNS acorde al dominio que controla el servidor AD. Asumimos que se trata del dominio
consultorianet.com y el nombre del servidor AD es win2k3.consultorianet.com.
4. Configurar y probar la autenticación Kerberos con el AD.
5. Configurar Samba para usar el esquema de seguridad basado en Active Directory (ads) y otros parámetros adicionales.
6. Unirse al dominio desde la línea de comandos.
7. Configurar winbind, nsswitch y PAM.
8. Reiniciar Samba, winbind y hacer las pruebas.
Paso 1
Este primer es aplicable únicamente para los sistemas Debian y derivados que no contienen por defecto los paquetes requeridos para
completar esta configuración de Samba y Active Directory.
Desde la línea de comandos instalar todos los paquetes necesarios para este fin:
# apt-get install krb5-config krb5-user winbind
Paso 2
Un servidor AD por defecto trae consigo habilitado el servicio NTP para permitir la sincronización de tiempo con los clientes de la red.
Dado que el protocolo Kerberos se basa en una precisión de tiempo, la diferencia entre el cliente y el servidor no debe superar los 5
OpenSourceCollege
Linux for SysAdmins
Página 223
Source Linux
minutos, así que para ello nos aseguraremos de mantener sincronizado a nuestro servidor Samba como cliente NTP del servidor AD.
Esto lo logramos definiendo una directiva server en /etc/ntp.conf que apunte a la dirección IP del servidor AD, y dicha directiva sea
colocada en el primer nivel sobre todas las demás.
server 172.31.0.203
En la configuración arriba mostrada se asume que 172.31.0.203 es la dirección IP del servidor AD. Ahora detendremos el servicio NTP
por un instante, refrescaremos la hora del servidor Samba desde el servidor AD e iniciaremos nuevamente el servicio NTP:
En Red Hat / CentOS o derivados:
# service ntpd stop

# ntpdate 172.31.0.203
# service ntpd start
En Debian o derivados:
# invoke-rc.d ntp stop

# ntpdate 172.31.0.203
# invoke-rc.d ntp start
También nos aseguraremos de aplicar la hora del sistema al reloj de hardware:
# hwclock --systohc
Paso 3
Es necesario asegurarnos de tener la resolución correcta de los nombres del dominio AD, para lo cual utilizaremos la dirección del
controlador de dominio como el servidor DNS preferido del sistema Samba, editando como sigue el archivo /etc/resolv.conf:
search consultorianet.com
nameserver 172.31.0.203
Además es necesario definir el nombre FQDN de nuestro servidor Samba (samba.consultorianet.com) en el archivo /etc/hosts como
sigue:
127.0.0.1 localhost
172.31.0.20 samba.consultorianet.com samba
El mismo nombre de host debería también ser inscrito en la zona consultorianet.com que administra del servidor AD, con su respectiva
resolución inversa.
Validamos ahora la correcta configuración de resolución de nombres realizando algunas consultas básicas:
# host -t soa consultorianet.com

# host -t ns consultorianet.com
Paso 4
Active Directory utiliza un método de autenticación seguro basado en Kerberos, en base al cual se deben seguir también directivas de
configuración de este protocolo en el servidor Samba.
Para ello es necesario editar el archivo /etc/krb5.conf sobre el contenido que trae por defecto como se muestra a continuación resaltado
con negrita los valores a agregar:
...
...
[libdefaults]
# default_realm = ATHENA.MIT.EDU
default_realm = consultorianet.com
...
...
[realms]
consultorianet.com = {
kdc = win2k3.consultorianet.com:88
admin_server = win2k3.consultorianet.com:749
default_domain = consultorianet.com
}
...
OpenSourceCollege
Linux for SysAdmins
Página 224
Source Linux
...
[domain_realm]
.consultorianet.com = consultorianet.com
consultorianet.com = consultorianet.com
...
...
Para verificar que la configuración de Kerberos es la correcta, haremos una solicitud inicial de ticket como sigue (respetando las
mayúsculas):
# kinit administrador@consultorianet.com
... donde ingresaremos el password del usuario administrador del dominio consultorianet.com del Active Directory. Si esto funcionó
como se esperaba, el comando klist nos ha de brindar la información del ticket adquirido y mantenido en caché:
# klist
Paso 5
Configurar Samba para especifica el esquema de autenticación ads, de modo que las credenciales de usuarios sean validadas por el
controlador Active Directory. Para ello crearemos un archivo vacío y en él colocaremos el siguiente contenido:
# cd /etc/samba
# mv smb.conf smb.conf.cups
# touch smb.conf
[global]
realm = consultorianet.com
preferred master = no
server string = Samba miembro de AD
security = ads
log level = 2
max log size = 1000
[homes]
browsable = no
public = no
writable = yes
comment = Directorio personal de usuarios
Verificamos la correcta sintaxis del archivo de configuración creado:
# testparm
Paso 6
Unirse al dominio desde la línea de comandos es bastante sencillo utilizando el comando net como sigue:
# net ads join -U administrador

Enter administrador's password:
Using short domain name -- CONSULTORIANET
Joined 'SAMBA' to realm 'consultorianet.com'
Si no se obtiene el mensaje 'Joined ... to ream ...' y en su lugar se obtiene algún otro mensaje de error, entonces alguno de los
procedimientos anteriores pudo haberse hecho incorrectamente. Es necesario volver al inicio y repasar cada uno de los pasos.
Paso 7
Winbind es un componente de la suite Samba que se encarga de mapear los usuarios de dominios NT como cuentas locales de un
sistema Linux.
A fin de poder validar los accesos al servidor Samba por usuarios del dominio -dando así permisos sobre los recursos compartidos- se
hace necesario configurar winbind, agregando las líneas resaltadas en negrita dentro del archivo de configuración de Samba como se
muestra debajo:
[global]
...
OpenSourceCollege
Linux for SysAdmins
Página 225
Source Linux
...
idmap uid = 10000-20000

idmap gid = 10000-20000
template shell = /bin/bash
template homedir = /home/%D/%U
winbind use default domain = yes
winbind enum users = yes
winbind enum groups = yes
obey pam restrictions = yes
[homes]
...
...
Creamos el directorio /home/CONSULTORIANET (%D equivale al nombre del dominio):
# mkdir /home/CONSULTORIANET
Además se requiere también actualizar el archivo /etc/nsswitch.conf como sigue (resaltado en negrita):
passwd: compat winbind

group: compat winbind
shadow: compat winbind
...
...
Actualizamos la configuración de los módulos PAM como sigue:
1. Editando el archivo /etc/pam.d/system-auth como sigue (agregar lo resaltado en negrita):
auth sufficient pam_winbind.so

auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account sufficient pam_winbind.so

account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3

password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session required pam_mkhomedir.so skel=/etc/skel umask=0022

session sufficient pam_winbind.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
1. Editando el archivo /etc/pam.d/common-account como sigue (agregar lo resaltado en negrita):

2. Editando el archivo /etc/pam.d/common-auth como sigue (agregar lo resaltado en negrita):

auth required pam_unix.so nullok_secure
OpenSourceCollege
Linux for SysAdmins
Página 226
Source Linux
3. Editando el archivo /etc/pam.d/common-session como sigue (agregar lo resaltado en negrita):

Paso 8
Una vez que se realizaron todos los pasos de configuración, revisamos la correcta sintaxis del archivo /etc/samba/smb.conf como buena
costumbre y de no encontrar errores procedemos a reiniciar el sevicio samba y winbind:
# testparm
# service winbind restart
# testparm
# service winbind restart
Para validar que winbind está trabajando de la manera correcta, los comandos wbinfo -u y wbinfo -g nos deben imprimir la lista
completa de usuarios y grupos disponibles en el dominio Active Directory:
# wbinfo -u
# wbinfo -g
Además para comprobar el correcto mapeo entre los usuarios/grupos del dominio y el sistema Shadow de usuarios/grupos locales, los
comandos getent passwd y getent group nos deben imprimir la lista de usuarios del sistema UNIX sumados a los del dominio
Active Directory, en un formato correspondiente al de los archivos /etc/passwd y /etc/group respectivamente:
# getent passwd
# getent group
Desde este momento el servidor Samba ya corre como miembro de un dominio Active Directory. Esto significa que los usuarios
existentes en el dominio, pueden usar sus credenciales de inicio de sesión ya validadas para acceder a alguno de los recursos
publicados por el servidor Samba ya sean éstos de datos o impresión.
De acuerdo a la configuración de prueba que hemos creado, el recurso especial [homes] está habilitado lo que permitiría a cualquier
usuario ingresar a su directorio personal utilizando su password del dominio Active Directory.
Precisamente esta es la prueba que se debe realizar para comprobar el éxito de esta configuración, accediendo desde un equipo
Windows a nuestro servidor Samba como sigue:
Menú Inicio -> Ejecutar -> \\172.31.0.20\administrador
O desde una línea de comandos de Linux, como sigue:
$ smbclient //172.31.0.20/administrador -U administrador
En cualquier de ambos casos el acceso debe ser exitoso y pudiendo incluso crear archivos y/o directorios dentro sin ningún problema.
Herramientas de línea de comandos de Samba

La suite Samba trae consigo varias herramientas útiles para la realización de tareas diversas en un entorno de redes Microsoft.
Algunas de las herramientas que vamos a estudiar son smbstatus, nmblookup, smbpasswd y smbclient.
smbstatus [opciones]
Imprime un reporte de las conexiones activas de Samba
Opciones:
-S : Sólo muestra recursos compartidos.
OpenSourceCollege
Linux for SysAdmins
Página 227
Source Linux
-u USER : Sólo muestra información relevante al usuario USER.
-p : Imprime una lista de los procesos smbd actuales de Samba.
nmblookup [opciones] <NOMBRE>

Herramienta de consulta de nombres NetBIOS
Opciones:
-M : Busca un visualizador maestro en el dominio especificado por NOMBRE.

-R : Realiza consultas recursivas. Usado junto con -U para consultar nombres a un servidor WINS.
-S : Luego de encontrar la IP de un nombre NetBIOS muestra el estado del nodo.
-A : Interpreta NOMBRE como una dirección IP e imprime el estado de nodo en dicha dirección.
-W DOM : Define el grupo de trabajo o dominio DOM del usuario.
-U ADDR : Realiza una consulta unicast a la dirección ADDR. Se usa con -R para consultar a servidores WINS.
smbpasswd [opciones] [USUARIO]

Herramienta de control de contraseñas de Samba
Opciones:
-a : Agrega un usuario al archivo smbpasswd.

-x : Elimina un usuario del archivo smbpasswd.
-d : Deshabilita un usuario.
-e : Habilita un usuario previamente deshabilitado.
-n : Asigna una contraseña nula a un usuario.
-m : Manipula una cuenta de máquina en lugar de una cuenta de usuario.
smbclient [opciones]
smbclient <SERVICIO> [opciones]
Herramienta cliente SMB/CIFS al estilo ftp
Opciones:
-I ADDR : Define la dirección IP ADDR con la cual conectarse.

-L NAME : Consulta los recursos compartidos al servidor de nombre NetBIOS NAME o a la IP especificada con -I
-N : Intenta establecer una conexión sin usar contraseña.
-k : Intenta autenticarse con Kerberos en un entorno Active Directory.
-U CRED : Conecta al servidor con las credenciales CRED, el que tiene la forma USER[%PASSWORD]
-W DOM : Define el grupo de trabajo o dominio DOM del cliente.
El SERVICIO al cual se puede conectar tiene la forma //servidor/recurso donde servidor puede ser un nombre NetBIOS o dirección IP,
y recurso identifica el nombre del elemento ofrecido para compartición.
Ejemplo 42:
a) Consultar la IP a la que resuelve el nombre NetBIOS win2k3 y consultar el estado del nodo:
# nmblookup -S win2k3
b) Imprimir un reporte de todas las conexiones vigentes a los recursos compartidos:
# smbstatus
c) Consultar el nombre NetBIOS asociado a la dirección IP 172.31.0.20:
# nmblookup -A 172.31.0.20
d) Consultar al servidor WINS 172.31.0.203 la dirección IP a la que resuelve el nombre samba:
# nmblookup -RU 172.31.0.203 samba
e) Imprimir un listado de los recursos compartidos por el host de nombre NetBIOS win2k3 sin usar password de autenticación:
# smbclient -L win2k3 -N
OpenSourceCollege
Linux for SysAdmins
Página 228
Source Linux
f) Conectarse al servicio //win2k3/C$ utilizando las credenciales del usuario administrador:
# smbclient //win2k3/C$ -U administrador

Password:
g) Montar el servicio anterior al cual nos conectamos, en el directorio /mnt:
# mount -t cifs -o username=administrador //win2k3/C$ /mnt
OpenSourceCollege
Linux for SysAdmins
Página 229
Source Linux
12.3. Compartición de archivos con NFS
Introducción a NFS
NFS es un protocolo de capa de aplicación desarrollado por Sun Microsystems con el propósito de ser utilizado como la base de un
servicio de sistemas de archivos distribuidos en red. Esto hace posible que varios clientes puedan acceder a un sistema de archivos
remoto en la red y usarlo como si se tratase de uno local. NFS en la práctica está conformado por un conjunto de servicios
NFS en su versión 2 y 3 basa su funcionamiento en el uso de servicios RPC para enrutar peticiones entre clientes y servidores. Dichos
servicios RPC son controlados por el demonio portmap el cual configura las conexiones para cada una de las llamadas solicitadas.
Los siguientes son los procesos RPC que conforman el servicio NFS en su conjunto:
• rpc.mountd : Administra las peticiones de montaje desde clientes NFS verificando que el sistema de archivos
solicitado esté actualmente exportado.
• rpc.nfsd : El servidor NFS que trabaja a nivel de kernel para satisfacer las demandas de los clientes.
• rpc.lockd : Proceso opcional que permite a los archivos bloquear archivos en el servidor.
• rpc.statd : Proceso que monitorea el servicio NFS informando a los clientes de su estado si éste se reincia de
manera abrupta.
• rpc.quotad : Proceso que brinda información de cuotas de usuarios para los clientes remotos.
• rpc.idmapd : Proceso que brinda al cliente y servidor NFSv4 llamadas que hacen la correspondencia entre sus
nombres NFSv4, los UIDs y GIDs locales.
• rpc.svcgssd : Proporciona al servidor mecanismos de transporte para autenticación Kerberos en NFSv4.
• rpc.gssd : Proporciona al cliente mecanismos de transporte para autenticación Kerberos en NFSv4.
La instancia de servidor NFS implica la ejecución de los procesos rpc.mountd, rpc.nfsd y opcionalmente rpc.rquotad. Mientras
que un servicio opcional se encarga de iniciar los procesos RPC complementarios como rpc.lockd y rpc.statd.
En Red Hat / CentOS y derivados, el script SysV nfs se encarga de lanzar los procesos de servidor NFS como rpc.nfsd,
rpc.mountd, rpc.idmapd y rpc.quotad, mientras que en Debian es el script nfs-kernel-server (que lo contiene el paquete
del mismo nombre) lanza los procesos rpc.nfsd y rpc.mountd.
De manera análoga en Red Hat / CentOS y derivados, el script SysV nfslock se encarga de lanzar los procesos RPC
complementarios como rpc.statd y rpc.lockd, mientras que en Debian el script SysV nfs-common lanza el proceso rpc.statd
únicamente.
Cuando se pretende correr un servidor NFS es recomendable lanzar los procesos RPC de apoyo, con el script nfslock (Red Hat) o
nfs-common (Debian) de la mano con el inicio del script nfs (Red Hat) o nfs-kernel-server (Debian); además también con la
ejecución previa del demonio portmap.
Si se pretende trabajar sólo como un cliente NFS sólo haría falta correr el demonio portmap y los procesos RPC de apoyo como nfslock
o nfs-common.
Implementación de un servidor NFS

En los sistemas Red Hat / CentOS el paquete nfs-utils y portmap (instalados por defecto) son los que contiene los programas
necesarios para correr un servidor NFS y poder trabajar también como cliente NFS.
Sin embargo en Debian y derivados es necesario asegurarnos que los paquetes nfs-common, portmap y nfs-kernel-server
estén instalados para poder correr un servidor NFS o comportarnos como cliente de este servicio:
# apt-get install nfs-common portmap nfs-kernel-server
Así, una vez que ya se cuenta con el software requerido es necesario asegurarnos que los servicios básicos de NFS sean ejecutados
al arranque del sistema, ejecutando:
# chkconfig portmap on
# chkconfig nfslock on
# chkconfig nfs on
En Debian derivados:
# update-rc.d portmap defaults

# update-rc.d nfslock defaults
# update-rc.d nfs-kernel-server defaults
OpenSourceCollege
Linux for SysAdmins
Página 230
Source Linux
De donde los servicios nfs o nfs-kernel-server no serán necesarios si pretendemos sólo trabajar como clientes NFS.
Exportación de directorios
El servidor NFS centra su configuración en el archivo /etc/exports el cual contiene las definiciones de los directorios que serán
exportados (compartidos) hacia la red bajo ciertas condiciones y modificadores.
Este archivo está conformado por entradas (una por línea) donde cada una de ellas tiene el siguiente formato:
<RUTA> <DIRECCCIÓN>[(<OPCIONES>)] [<DIRECCCIÓN>[(<OPCIONES>)]] ...
Donde:
• RUTA : Ruta absoluta del directorio a exportar o compartir.
• DIRECCIÓN : Dirección de uno o más hosts remotos autorizados a usar este recurso.
• OPCIONES : Opciones para clientes.
Las direcciones pueden ser especificadas como hosts únicos (Ejm: 172.10.30.2, sam.georgia.edu), segmentos de red (Ejm:
192.168.32.0/24, 10.32.0.0/16), o expresiones formadas por comodines (Ejm: *.georgia.edu, *.edu.*).
Algunas de las opciones de configuración para clientes son:
• ro : Permiso de montar en modo sólo lectura.

• rw : Permiso de montar en modo lectura/escritura.
• root_squash : Los requerimientos de usuario root son mapeados al usuario anonymous sin privilegios.
• no_root_squash : No mapea los requerimientos de usuario root a otro usuario, simplemente los respeta.
• all_squash : Mapea todos los requerimientos al usuario anonymous sin privilegios.
• subtree_check : Mapea todos los requerimientos al usuario anonymous sin privilegios.
Con la revisión de la sintaxis de este archivo, podemos generar un ejemplo de directorios exportados como sigue:
/data/principal 172.17.30.0/24(ro,root_squash)
/home *.consultorianet.com(rw,no_root_squash) *.unmsm.edu.pe(ro,all_squash)
Una vez que se definimos los directorios a exportar, debemos indicar al servidor NFS que haga efectivas estas exportaciones
ejecutando:
# exportfs -a
Luego desde un equipo cliente podremos consultar los recursos exportados por el servidor NFS:
# showmount -e 172.17.30.1
El ejemplo anterior asume que el servidor NFS tiene IP 172.17.30.1, y una vez que comprobamos qué recursos exportados son
accesibles para nuestro host, podemos proceder a montarlo en un directorio local como sigue:
# mount -t nfs 172.17.30.1:/data/principal /mnt/nfs

# cd /mnt/nfs
# ls
OpenSourceCollege
Linux for SysAdmins
Página 231
Source Linux
12.4. Servidor FTP seguro
El protocolo FTP
File Transfer Protocol (FTP), es un protocolo de nivel de aplicación que utiliza conexiones TCP en la capa de transporte. Este protocolo
es uno de los más antiguos hoy vigentes y fue desarrollado para hacer posible la transferencia de archivos en un modelo
cliente/servidor.
Para hacer posible la comunicación entre un cliente y servidor, el protocolo FTP soporta mecanismos de autenticación con un nombre
de usuario y password. Bajo este modelo de autenticación existe la posibilidad que los servidores FTP acepten un nombre de usuario
válido sólo para conexiones anónimas sin ningún password válido asociado, donde por lo general dicho nombre de usuario suele ser
ftp o anonymous.
Es así que se llama servidor FTP anónimo a aquel que acepta el inicio de sesión de las cuentas ftp o anonymous (o cualquier otra que
se defina como anónima) sin una contraseña asociada a dicho usuario.
El protocolo FTP maneja dos canales de comunicación entre cliente y servidor: el canal de control y el canal de datos. El canal de
control está diseñado para que a través de él se envíen y reciban comandos FTP, instrucciones y información de estado, etc, mientras
que el canal de datos está diseñado exclusivamente para el tránsito de datos que son cargados o descargados del servidor.
FTP en modo activo

En este modo de funcionamiento el servidor FTP abre un canal de datos en su puerto TCP 20, mientras que en el lado del cliente el
canal de datos se asocia a un puerto aleatorio mayor que 1024. Para establecer la transferencia de datos en este canal entre aquellos
puertos, el cliente envía un comando PORT al servidor indicándole cuál es el puerto que ha de utilizar el cliente de modo que el servidor
pueda establecer una conexión hacia dicho puerto del cliente para hacer posible la transferencia de datos durante la conexión FTP.
Este modo representa un problema de seguridad para el cliente pues éste debe aceptar cualquier conexión entrante para un puerto
mayor a 1024, lo que se convierte en un peligro potencial si el cliente está conectado a una red grande como Internet.
FTP en modo pasivo

Este modo se desarrolló para superar la dificultad que implicaba el modo activo. En este modo el cliente envía un comando PASV al
servidor y éste responde al cliente pasándole el número de puerto del servidor (mayor a 1023. Ejm: 2040) al que el cliente debe
conectarse. Así el cliente inicia una conexión desde el puerto siguiente al puerto de control (Ejm: 1036) hacia el puerto del servidor
anteriormente por éste especificado (2040 según el ejemplo) para realizar la transferencia de datos.
Por cada nueva transferencia el cliente debe enviar un comando PASV o PORT al servidor según el modo en el que haya establecido
previa conexión, para así reiniciar el proceso de negociación de puertos de transmisión de datos.
Implementación de un servidor FTP con vsftpd

La puesta en marcha de un servidor FTP es sencilla a través de la instalación, configuración y administración del software vsftpd, que
trae Red Hat / CentOS y Debian en su distribución original de paquetes.
Procederemos así a instalarlo como sigue:
# yum install vsftpd -y
# apt-get install vsftpd -y
La instalación del paquete vsftpd crea por defecto el archivo de configuración /etc/vsftpd/vsftpd.conf en Red Hat y derivados, mientras
que el archivo /etc/vsftpd.conf en Debian y derivados.
Haremos un backup del archivo original y crearemos uno vacío para crear dentro un contenido básico como el mostrado líneas más
abajo:
# mv /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd.conf.orig
# touch /etc/vsftpd/vsftpd.conf
# mv /etc/vsftpd.conf /etc/vsftpd.conf.orig
# touch /etc/vsftpd.conf
OpenSourceCollege
Linux for SysAdmins
Página 232
Source Linux
listen=YES
anonymous_enable=YES
anon_max_rate=30000
ftp_username=ftp
local_enable=YES
write_enable=YES
user_config_dir=/etc/vsftpd_users/
local_umask=0022
xferlog_enable=YES
xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
ftpd_banner=Bienvenidos al servidor FTP de Consultorianet
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list
session_support=YES
El detalle de las directivas de configuración mostradas en el archivo de ejemplo se muestra debajo:
Si es YES entonces vsftpd se ejecuta de forma independiente, si es NO se ejecuta bajo el
listen
control de un demonio como inetd o xinetd.
anonymous_enable Soporte del FTP anónimo.
anon_max_rate Tasa máxima de tranferencia en bytes por segundo, permitida para clientes anónimos.
ftp_username Define el nombre de usuario utilizado para FTP anónimos.
local_enable Soporte del inicio de sesión de usuarios locales del sistema.
write_enable Soporte de operaciones de escritura FTP (Ejm: cargar, renomrar, eliminar, etc).
user_config_dir Directorio donde se han de buscar archivos de configuración cuyos nombres coincidan con los
usuarios que se conectan para definir en ellos directivas específicas de vsftpd por usuario.
local_umask Define la máscara de permisos para archivos y/o directorios recién creados.
xferlog_enable Guarda un registro de archivos cargados/descargados del servidor FTP.
xferlog_file Define la ruta del archivo de registro de cargas/descargas del servidor FTP.
xferlog_std_format Genera el registro de cargas/descargas en un formato estándar común de otros demonios ftp.
ftpd_banner Define un mensaje de bienvenida al servicio FTP.
chroot_list_enable Habilita el enjaulamiento a los usuarios definidos en una lista dentro de un archivo.
chroot_list_file Archivo que contiene la lista de usuarios enjaulados.
Almacena en los logs del sistema los inicios de sesión de los usuarios que pueden ser
session_support
consultados con el comando last
En esta configuración de ejemplo hay que resaltar que:
✔ Se habilita el FTP anónimo sólo para descargar ficheros -no es posible realizar operaciones de escritura- y se les limita la
tasa de transferencia a un límite que no sobrepase los 30 KB/s.
✔ Se habilita el acceso a usuarios locales del sistema Linux.
✔ Se pueden crear archivos de configuración personalizados por usuario creando archivos que lleven sus nombres dentro del
directorio /etc/vsftpd_users y en cada uno de ellos definir directivas que puedan sobreescribir los valores definidos en el archivo
/etc/vsftpd.conf
✔ Se habilita el soporte de enjaulamiento de usuarios definidos en el archivo /etc/vsftpd.chroot_list
Siguiendo con la configuración, podremos crear archivos de configuración personalizados para los usuarios eruiz y admin como sigue:
# mkdir /etc/vsftpd_users
# echo "local_max_rate=50000" > /etc/vsftpd_user/eruiz
# echo "local_max_rate=75000" > /etc/vsftpd_user/admin
OpenSourceCollege
Linux for SysAdmins
Página 233
Source Linux
Además podemos ir definiendo una lista de usuarios (eruiz, mflores, atello y jlora) que deseamos mantener enjaulados en sus
directorios de trabajo cuando inicien sesión en el servidor FTP:
# echo eruiz > /etc/vsftpd.chroot_list

# echo mflores >> /etc/vsftpd.chroot_list
# echo atello >> /etc/vsftpd.chroot_list
# echo jlora >> /etc/vsftpd.chroot_list
Luego de terminar de editar los archivos de configuración se puede proceder a reiniciar el demonio vsftpd y hacer pruebas de acuerdo
a las configuraciones realizadas:
# chkconfig vsftpd on
# service vsftpd restart
# update-rc.d vsftpd defaults

# invoke-rc.d vsftpd restart
OpenSourceCollege
Linux for SysAdmins
Página 234
Source Linux
12.5. Reportes de tráfico FTP
La capacidad de generar reportes de los servicios de red instalados en un servidor resultan ser un requerimiento muy común en la
mayoría de organizaciones, más aún si se tratan de servicios de amplio uso público, tal como es el caso de los servidores FTP.
Por ello, en esta sección revisaremos el proceso de instalación y configuración de una excelente herramienta de generación de
reportes llamada AWStats, la que nos podrá generar informes en formatos bastante amigables para el administrador.
Descarga e instalación
AWStats puede ser descargado desde su sitio Web oficial (http://awstats.sourceforge.net), como un archivo tarball, o podemos
simplificar la instalación desde repositorios.
Este paquete está incluido en los repositorios oficiales para Debian, pero para Red Hat / CentOS no sucede lo mismo aunque no
obstante existe el repositorio DAG que sí incluye este paquete.
En Red Hat / CentOS y derivados, procederemos a crear un archivo de repositorio /etc/yum.repos.d/dag.repo con un contenido como el
siguiente:
[dag]
name=dag
gpgcheck=0
enabled=0
Luego procedemos a instalar el paquete awstats:
# yum --enablerepo=dag install httpd awstats -y
En un sistema Debian y derivados, realizamos la instalación directa:
# apt-get install apache2 libapache2-mod-perl2 awstats -y
Este procedimiento es el recomendado para agilizar el proceso de resolución de dependencias de software y configuración
predeterminada del paquete.
Configuración de AWStats para FTP

AWStats es capaz de reconocer un número limitado de formatos de logs de distintos software de servidor tal como Apache, IIS, wu-
ftpd, etc, sin embargo el formato nativo usado por vsftpd no está entre los soportados.
No obstante en la configuración anterior del demonio vsftpd ya consideramos el uso de un formato estándar de logs del servicio FTP,
por lo que éste archivo (/var/log/vsftpd.log) de registro sí resulta válido para AWStats.
Dentro del directorio /etc/awstats debe existir un archivo de nombre awstats.model.conf (Red Hat / CentOS) o awstats.conf (en Debian) el
cual contiene un modelo de la configuración de AWStats.
Crearemos una copia a partir de éste con un nombre como awstats.ftp.conf:
# cd /etc/awstats
# cp awstats.model.conf awstats.ftp.conf
# cd /etc/awstats
# cp awstats.conf awstats.ftp.conf
Editaremos este archivo awstats.ftp.conf creado y modificaremos su contenido de acuerdo al texto debajo resaltado en negrita :
...
...
LogFile="/var/log/vsftpd.log"
...
...
LogType=F
...
...
OpenSourceCollege
Linux for SysAdmins
Página 235
Source Linux
LogFormat="%time3 %other %host %bytesd %url %other %other %method %other %logname %other %code
%other %other"
...
...
LogSeparator="\s"
...
...
SiteDomain="ftp.consultorianet.com"
...
...
NotPageList=""
...
...
Luego crearemos una configuración de AWStats para Apache como sigue:
En Red Hat / CentOS y derivados
1. El paquete awstats instalado trajo consigo un archivo de configuración modelo para Apache ubicado en
/etc/httpd/conf.d/awstats.conf, del cual debemos modificar su contenido según el texto resaltado en negrita:
Alias /awstats/icon/ /var/www/awstats/icon/
ScriptAlias /awstats/ /var/www/awstats/

<Directory /var/www/awstats/>
DirectoryIndex awstats.pl
Options ExecCGI
order deny,allow
deny from all
# allow from 127.0.0.1
allow from all
</Directory>
#Alias /css/ /var/www/awstats/css/

#Alias /js/ /var/www/awstats/js/
2. Luego de guardar los cambios en el archivo, reiniciar el servidor Apache:
# service httpd restart
En Debian y derivados
1. El paquete awstats instalado trae consigo un archivo de configuración modelo para Apache ubicado en
/usr/share/doc/awstats/examples/apache.conf, del cual debemos crear una copia en /etc/apache2/conf.d/awstats.conf y modificar su
contenido según el texto resaltado en negrita:
# This provides worldwide access to everything below the directory

# Security concerns:
# * Raw log processing data is accessible too for everyone
# * The directory is by default writable by the httpd daemon, so if
# any PHP, CGI or other script can be tricked into copying or
# symlinking stuff here, you have a looking glass into your server,
# and if stuff can be uploaded to here, you have a public warez site!
<Directory /var/lib/awstats>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>

# Security concerns: none known
<Directory /usr/share/awstats/icon>
OpenSourceCollege
Linux for SysAdmins
Página 236
Source Linux
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
# This provides worldwide access to everything in the directory

Alias /awstats-icon/ /usr/share/awstats/icon/
# This (hopefully) enables _all_ CGI scripts in the default directory

# Security concerns: Are you sure _all_ CGI scripts are safe?
# ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
ScriptAlias /awstats/ /usr/lib/cgi-bin/
# invoke-rc.d apache2 restart
Finalmente ya tenemos lista la configuración de AWStats para los logs del servidor FTP, sólo nos resta instruir a través de la línea de
comandos la generación de estadísticas recientes a partir del archivo /var/log/vsftpd.log configurado, haciendo uso del script awstats.pl
que viene con el paquete awstats como sigue:
# /var/www/awstats/awstats.pl -update -config=ftp
# /usr/lib/cgi-bin/awstats.pl -update -config=ftp
El script awstats.pl genera las estadísticas por defecto en /var/www/awstats (en Red Hat / CentOS) o en /var/lib/awstats (en Debian), las
cuales son representadas por archivos de textos poco o nada entendibles.
Por ello la forma correcta de visualizar estas estadísticas generada es a través de la ejecución de un script CGI desde Apache
accediendo con un navegador a una URL como la siguiente:
http://172.17.30.1/awstats/awstats.pl?config=ftp
... donde se asume que el host donde se ejecuta el servidor FTP, Web y la herramienta AWStats, posee la IP 172.17.30.1.
AWStats simplificado desde Webmin

configurar y generar reportes de AWStats siguiendo estos pasos:
1. Iniciar el servicio Webmin:
OpenSourceCollege
Linux for SysAdmins
Página 237
Source Linux
2. Dentro de Webmin acceder a 'Webmin -> Webmin Configuration -> Webmin Modules' e instalar el módulo de AWStats
rellenando con la URL de descarga (link obtenido desde la Web oficial de AWStats) el campo de nombre 'From ftp or http
URL' como sigue:
From ftp or http : http://prdownloads.sourceforge.net/awstats/awstats-1.8.wbm
1. Luego dar clic sobre el botón 'Install Module'.
2. Una vez instalado el módulo acceder a 'System -> AWStats Logfile Analyzer' y revisar las opciones de configuración del
módulo de AWStats a través de su interfaz gráfica amigable.
OpenSourceCollege
Linux for SysAdmins
Página 238
Source Linux
1. Teniendo configurado a Samba como servidor de impresión, configurar el recurso especial [print$] para proveer los
drivers de la impresora compartida de modo tal que estos se puedan instalar de manera automática por las estaciones de
trabajo Windows al conectar con el recurso de impresión compartido.
OpenSourceCollege
Linux for SysAdmins
Página 239
Source Linux
1. Teniendo configurado a Samba como servidor de impresión, configurar el recurso especial [print$] para proveer los
drivers de la impresora compartida de modo tal que estos se puedan instalar de manera automática por las estaciones de
trabajo Windows al conectar con el recurso de impresión compartido.
+ Se requiere obtener dos paquetes por separado:
• Drivers de CUPS para Windows (cups-windows-VERSION-source.tar.bz2)

• Drivers Postcript de Adobe (winsteng.exe)
Del primero de ellos, al extraer su contenido se encontrará dentro el directorio i386 de donde se deben copiar al directorio
/usr/share/cups/drivers los siguientes archivos:
• cups6.inf
• cups6.ini
• cupsps6.dll
• cupsui6.dll
Del segundo paquete tras ser instalado en un sistema Windows, deben encontrarse y copiarse al sistema Linux al directorio
/usr/share/cups/drivers los siguientes archivos:
• ps5ui.dll
• pscript.hlp
• pscript.ntf
• pscript5.dll
Todos estos archivos deben ser copiados con aquellos nombres exactamente iguales, respectando las minúsculas tal como
están, no deben ser alteradas a mayúsculas ninguna de sus letras de esos archivos.
+ Luego crearemos un archivo de configuración de Samba con el siguiente contenido:
[global]
security = user
server string = Servidor de archivos e impresion
log level = 2
max log size = 2000
load printers = yes
printing = cups
printcap name = cups
[printers]
path = /var/spool/cups
public = no
printable = yes
[print$]
path = /etc/samba/drivers
browseable = yes
public = no
read only = yes
write list = root
+ Creamos el directorio al cual se hace referencia en el recurso [print$]:
# mkdir /etc/samba/drivers
+ Ahora será necesario asignar una contraseña de Samba al usuario root, reiniciar el servicio para aplicar los cambios al
fichero de configuración y luego realizar la configuración de drivers CUPS en el recurso compartido como sigue:
# smbpasswd -a root
OpenSourceCollege
Linux for SysAdmins
Página 240
Source Linux
# cupsaddsmb -U root -a -v
# smbpasswd -a root
# invoke-rc.d samba restart
# cupsaddsmb -U root -a -v
Si este último procedimiento no hubiese generado ningún mensaje de error, ya habremos logrado el objetivo deseado. Ahora
tan sólo bastará acceder desde un equipo Windows a nuestro servidor Samba, conectarnos a una de las impresoras
compartidas y veremos cómo se instala automáticamente el driver necesario para dicha impresora, de modo tal que quede
lista para usarla.
OpenSourceCollege
Linux for SysAdmins
Página 241
Source Linux
Unidad 13: Servidor Web y OpenSSL
13.1. Objetivos
✔ Comprender los componentes y forma de trabajo de una Infraestructura de Clave Pública, los certificados digitales y
OpenSSL.
✔ Implementación de un servidor Web básico a través del software Apache.
✔ Configuración de Apache para publicación de Hosts Virtuales y Sitios seguros con OpenSSL.
✔ Saber generar reportes gráficos amigables sobre el tráfico de visitas de los sitios Web publicados por Apache.
13.2. Certificados digitales

PKI, Public Key Infraestructure
En criptografía, una infraestructura de clave publica (o, en inglés, PKI, Public Key Infrastructure) es una combinación de hardware y
software, políticas y procedimientos de seguridad que permiten la ejecución con garantías de operaciones criptográficas como el
cifrado, la firma digital o el no repudio de transacciones electrónicas.
El término PKI se utiliza para referirse tanto a la autoridad de certificación y al resto de componentes, como para referirse, de manera
más amplia y a veces confusa, al uso de algoritmos de clave pública en comunicaciones electrónicas. Este último significado es
incorrecto, ya que no se requieren métodos específicos de PKI para usar algoritmos de clave pública.
Propósito y funcionalidad
La tecnología PKI permite a los usuarios autenticarse frente a otros usuarios y usar la información de los certificados de identidad
(por ejemplo, las claves públicas de otros usuarios) para cifrar y descifrar mensajes, firmar digitalmente información, garantizar el
no repudio de un envío, y otros usos.
En una operación criptográfica que use infraestructura PKI, intervienen conceptualmente como mínimo las siguientes partes:
• Un usuario iniciador de la operación

• Unos sistemas servidores que dan fe de la ocurrencia de la operación y garantizan la validez de los certificados
implicados en la operación (autoridad de certificación, Autoridad de registro y sistema de Sellado de tiempo)
• Un destinatario de los datos cifrados/firmados/enviados garantizados por parte del usuario iniciador de la operación
(puede ser él mismo).
Las operaciones criptográficas de clave pública, son procesos en los que se utilizan unos algoritmos de cifrado que son conocidos
y están accesibles para todos. Por este motivo la seguridad que puede aportar la tecnología PKI, está fuertemente ligada a la
privacidad de la llamada clave privada y los procedimientos operacionales o políticas de seguridad aplicados.
Es de destacar la importancia de las políticas de seguridad en esta tecnología, puesto que ni los dispositivos más seguros ni los
algoritmos de cifrado más fuerte sirven de nada si por ejemplo una copia de la clave privada protegida por una tarjeta criptográfica
(del inglés 'smart card') se guarda en un disco duro convencional de un PC conectado a Internet.
Usos de la tecnología PKI

Algunos de los usos comunes de una infraestructura de clave pública pueden ser los siguientes:
• Autenticación de usuarios y sistemas (login)

• Identificación del interlocutor
• Cifrado de datos digitales
• Firmado digital de datos (documentos, software, etc.)
• Asegurar las comunicaciones
• Garantía de no repudio (negar que cierta transacción tuvo lugar)
Componentes
Los componentes más habituales de una infraestructura de clave pública son:
• La autoridad de certificación (o, en inglés, CA, Certificate Authority): es la encargada de emitir y revocar certificados. Es
la entidad de confianza que da legitimidad a la relación de una clave pública con la identidad de un usuario o servicio.
• La autoridad de registro (o, en inglés, RA, Registration Authority): es la responsable de verificar el enlace entre los
certificados (concretamente, entre la clave pública del certificado) y la identidad de sus titulares.
• Los repositorios: son las estructuras encargadas de almacenar la información relativa a la PKI. Los dos repositorios más
importantes son el repositorio de certificados y el repositorio de listas de revocación de certificados. En una lista de
revocación de certificados (o, en inglés, CRL, Certificate Revocation List) se incluyen todos aquellos certificados que por
algún motivo han dejado de ser válidos antes de la fecha establecida dentro del mismo certificado.
OpenSourceCollege
Linux for SysAdmins
Página 242
Source Linux
• La autoridad de validación (o, en inglés, VA, Validation Authority): es la encargada de comprobar la validez de los
certificados digitales.
• La autoridad de sellado de tiempo (o, en inglés, TSA, TimeStamp Authority): es la encargada de firmar documentos con
la finalidad de probar que existían antes de un determinado instante de tiempo.
• Los usuarios y entidades finales son aquellos que poseen un par de claves (pública y privada) y un certificado asociado a
su clave pública. Utilizan un conjunto de aplicaciones que hacen uso de la tecnología PKI (para validar firmar digitales,
cifrar documentos para otros usuarios, etc.)
Consideraciones sobre PKI

Es importante tener en cuenta estas consideraciones sobre una estructura PKI:
• Todo certificado válido, ha de ser emitido por una Autoridad de certificación reconocida, que garantiza la validez de la
asociación entre el tenedor del certificado y el certificado en sí.
• El poseedor de un certificado es responsable de la conservación y custodia de la clave privada asociada al certificado
para evitar el conocimiento de la misma por terceros.
• Las entidades de registro se encargan de la verificación de la validez y veracidad de los datos del que pide un certificado,
y gestionan el ciclo de vida de las peticiones hacia las AC's.
• El poseedor de un certificado válido puede usar dicho certificado para los usos para los que ha sido creado según las
políticas de seguridad.
• Toda operación que realice el poseedor de un certificado ha de realizarse de forma presencial por parte del poseedor del
certificado y dentro del hardware de cliente (ya sea la tarjeta criptográfica o PKCS#11 u otro dispositivo seguro como el
fichero seguro o PKCS#12, etc.
• Las comunicaciones con seguridad PKI no requieren del intercambio de ningún tipo de clave secreta para su
establecimiento, por lo que se consideran muy seguras si se siguen las políticas de seguridad pertinentes.
Criptografía asimétrica
La criptografía asimétrica es el método criptográfico que usa un par de claves para el envío de mensajes. Las dos claves pertenecen a
la misma persona a la que se ha enviado el mensaje. Una clave es pública y se puede entregar a cualquier persona, la otra clave es
privada y el propietario debe guardarla de modo que nadie tenga acceso a ella. Además, los métodos criptográficos garantizan que esa
pareja de claves sólo se puede generar una vez, de modo que se puede asumir que no es posible que dos personas hayan obtenido
casualmente la misma pareja de claves.
Si el remitente usa la clave pública del destinatario para cifrar el mensaje, una vez cifrado, sólo la clave privada del destinatario podrá
descifrar este mensaje, ya que es el único que la conoce. Por tanto se logra la confidencialidad del envío del mensaje, nadie salvo el
destinatario puede descifrarlo.
Si el propietario del par de claves usa su clave privada para cifrar el mensaje, cualquiera puede descifrarlo utilizando su clave pública.
En este caso se consigue por tanto la identificación y autenticación del remitente, ya que se sabe que sólo pudo haber sido él quien
empleó su clave privada (salvo que alguien se la hubiese podido robar). Esta idea es el fundamento de la firma electrónica.
Los sistemas de cifrado de clave pública o sistemas de cifrado asimétricos se inventaron con el fin de evitar por completo el problema
del intercambio de claves de los sistemas de cifrado simétricos. Con las claves públicas no es necesario que el remitente y el
destinatario se pongan de acuerdo en la clave a emplear. Todo lo que se requiere es que, antes de iniciar la comunicación secreta, el
remitente consiga una copia de la clave pública del destinatario. Es más, esa misma clave pública puede ser usada por cualquiera que
desee comunicarse con su propietario. Por tanto, se necesitarán sólo N pares de claves por cada N personas que deseen comunicarse
entre sí.
OpenSourceCollege
Linux for SysAdmins
Página 243
Source Linux
Algunos de los algoritmos de técnicas de clave asimétrica son:
• Diffie-Hellman
• RSA
• DSA
• ElGamal
Certificados digitales
Un certificado digital es un documento digital mediante el cual un tercero confiable (una autoridad de certificación) garantiza la
vinculación entre la identidad de un sujeto o entidad y su clave pública.
Si bien existen variados formatos para certificados digitales, los más comúnmente empleados se rigen por el estándar UIT-T X.509. El
certificado contiene usualmente el nombre de la entidad certificada, número de serie, fecha de expiración, una copia de la clave pública
del titular del certificado (utilizada para la verificación de su firma digital) y la firma digital de la autoridad emisora del certificado de
forma que el receptor pueda verificar que esta última ha establecido realmente la asociación.
Formato de certificado digital

Un certificado emitido por una entidad de certificación autorizada, además de estar firmado digitalmente por ésta, debe contener
por lo menos lo siguiente:
• Nombre, dirección y domicilio del suscriptor.

• Identificación del suscriptor nombrado en el certificado.
• El nombre, la dirección y el lugar donde realiza actividades la entidad de certificación.
• La clave pública del usuario.
• La metodología para verificar la firma digital del suscriptor impuesta en el mensaje de datos.
• El número de serie del certificado.
• Fecha de emisión y expiración del certificado.
Emisores de certificados
Cualquier individuo o institución puede generar un certificado digital, pero si éste emisor no es reconocido por quienes interactúen
con el propietario del certificado, el valor del mismo es prácticamente nulo. Por ello los emisores deben acreditarse: así se
denomina al proceso por el cuál entidades reconocidas, generalmente públicas, otorgan validez a la institución certificadora, de
forma que su firma pueda ser reconocida como fiable, transmitiendo esa fiabilidad a los certificados emitidos por la citada
institución.
La gran mayoría de los emisores tiene fines comerciales, y otros, gracias al sistema de anillo de confianza pueden otorgar
gratuitamente certificados en todo el mundo, como:
• CAcert.org, emisor administrado por la comunidad con base legal en Australia.

• Thawte, sólo para certificados personales. Emisor propiedad de Verisign.
OpenSourceCollege
Linux for SysAdmins
Página 244
Source Linux
Pero para que un certificado digital tenga validez legal, el prestador de Servicios de Certificación debe acreditarse en cada país de
acuerdo a la normativa que cada uno defina.
OpenSSL
OpenSSL es un proyecto de software desarrollado por los miembros de la comunidad Open Source para libre descarga y está basado
en SSLeay desarrollado por Eric Young y Tim Hudson.
Consiste en un robusto paquete de herramientas de administración y librerías relacionadas con la criptografía, que suministran
funciones criptográficas a otros paquetes como OpenSSH y navegadores web (para acceso seguro a sitios HTTPS).
Estas herramientas ayudan al sistema a implementar el Secure Sockets Layer (SSL), así como otros protocolos relacionados con la
seguridad , como el Transport Layer Security (TLS). Este paquete de software es importante para cualquiera que esté planeando usar
cierto nivel de seguridad en su máquina con un sistema operativo Libre basado en GNU/Linux. OpenSSL también nos permite crear
certificados digitales que podremos aplicar a nuestro servidor, por ejemplo Apache.
El protocolo SSL
Secure Sockets Layer -Protocolo de Capa de Conexión Segura- (SSL) y Transport Layer Security -Seguridad de la Capa de
Transporte- (TLS), su sucesor, son protocolos criptográficos que proporcionan comunicaciones seguras por una red, comúnmente
Internet.
Existen pequeñas diferencias entre SSL 3.0 y TLS 1.0, pero el protocolo permanece sustancialmente igual. El término "SSL" según
se usa aquí, se aplica a ambos protocolos a menos que el contexto indique lo contrario.
SSL proporciona autenticación y privacidad de la información entre extremos sobre Internet mediante el uso de criptografía.
Habitualmente, sólo el servidor es autenticado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin
autenticar; la autenticación mutua requiere un despliegue de infraestructura de claves públicas (o PKI) para los clientes. Los
protocolos permiten a las aplicaciones cliente-servidor comunicarse de una forma diseñada para prevenir escuchas
(eavesdropping), la falsificación de la identidad del remitente (phishing) y alterar la integridad del mensaje.
SSL implica una serie de fases básicas:
• Negociar entre las partes el algoritmo que se usará en la comunicación

• Intercambio de claves públicas y autenticación basada en certificados digitales
• Cifrado del tráfico basado en cifrado simétrico
Durante la primera fase, el cliente y el servidor negocian qué algoritmos criptográficos se van a usar. Las implementaciones
actuales proporcionan las siguientes opciones:
• Para criptografía de clave pública: RSA, Diffie-Hellman, DSA (Digital Signature Algorithm) o Fortezza;
• Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple
DES o AES (Advanced Encryption Standard);
• Con funciones hash: MD5 o de la familia SHA.
Gestión de una CA y certificados digitales

En este apartado se va a estudiar la creación de una Autoridad Certificadora (Certificate Authority) y certificados digitales firmados por
esta CA utilizando para ello OpenSSL que por defecto ya debe venir instalado en cualquier distribución Linux.
Los pasos a seguir se muestran debajo:
1 Creación de la CA (Certification Authority)
Este primer paso debería ser ejecutado sólo una vez por la entidad que pretende ser una Autoridad Certificadora, guardando
con mucho cuidado los archivos creados en los pasos siguientes. Esta entidad será la que posteriormente permite firmar
solicitudes y entregar certificados solicitados por terceras partes.
1.1 Ajustar el archivo de configuración de OpenSSL (/etc/pki/tls/openssl.cnf en Red Hat y derivados, o /etc/ssl/openssl.cnf en
Debian y derivados), ajustando las siguientes directivas debajo resaltadas:
...
...
dir = /root/sslCA
...
...
default_days = 3650
...
...
countryName_default = PE
stateOrProvinceName_default = Lima
localityName_default = Wahoo
OpenSourceCollege
Linux for SysAdmins
Página 245
Source Linux
1.2 Crear los directorios -y ajustar sus permisos- donde se creará la CA y otros archivos de certificados:
# mkdir /root/sslCA
# chmod 700 /root/sslCA
# cd /root/sslCA
# mkdir certs private newcerts
1.3 Crear dos archivos, uno serial y otro index.txt, usados en la creación de certificados:
# echo 1000 > serial

# touch index.txt
1.4 Crear la CA invocando al comando openssl como sigue:
# openssl req -new -x509 -days 3650 -keyout private/cakey.pem -out cacert.pem -config \
> /etc/pki/tls/openssl.cnf
# openssl req -new -x509 -days 3650 -keyout private/cakey.pem -out cacert.pem -config \
> /etc/ssl/openssl.cnf
1.5 Tras la ejecución del comando openssl se debe completar una serie de preguntas como sigue:
Generating a 1024 bit RSA private key

.......................++++++
.++++++
writing new private key to 'private/cakey.pem'
Enter PEM pass phrase: [Escribir password]
Verifying - Enter PEM pass phrase: [Repetir password]
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [PE]:[Enter]
State or Province Name (full name) [Lima]:[Enter]
Locality Name (eg, city) [Lima]:[Enter]
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Consultorianet SRL
Organizational Unit Name (eg, section) []:Sistemas
Common Name (eg, YOUR name) []:Consultorianet Certification Authority
Email Address []:arengifo@consultorianet.com
Lo resaltado en negrita es lo que correspondería ingresar al usuario desde el teclado. El significado de los campos que
forman parte del certificado se describen debajo:
Nombre del campo Descripción Ejemplos

Contraseña con la que se protege la llave privada de la CA. Ésta
es la que será usada para firmar certificados posteriormente.
PEM pass phrase -
Dado que es una frase de paso (pass phrase) esta contraseña
puede constar de varias palabras separadas por espacios.
Country Name La abreviación ISO de 2 letras que identifica al país de la CA. PE
El estado o provincia donde se ubica la organización. No puede
State or Province Name Lima
ser abreviado.
La ciudad donde se ubica la organización. No puede ser
City or Locality Name Lima
abreviado.
OpenSourceCollege
Linux for SysAdmins
Página 246
Source Linux
Organization Name El nombre legal exacto de la organización. No debe ser abreviado. Consultorianet SRL
Opcional para información adicional de la unidad de la
Organizational Unit Sistemas
organización.
Dado que éste es nuestro certificado raíz, nombrarlo de forma Consultorianet Certification
Common Name
similar al ejemplo de al lado. Authority
arengifo@consultorianet.co
Email Address La dirección e-mail de contacto a la CA
m
1.6 Verificar que se haya creado el certificado de la CA correctamente visualizando su contenido como sigue:
# openssl x509 -in cacert.pem -text -noout
2 Creación de solicitudes de certificados
2.1 Crear una llave y solicitud de firma de certificado (CSR, Certificate Signing Request). Este paso debería ser ejecutado
por una tercera parte, que puede estar solicitando un certificado a nuestra CA previamente creada. A continuación
asumiremos que en el mismo host donde se creó la CA se creará también la solicitud:
# openssl req -new -nodes -out apache-req.pem -keyout private/apache-key.pem -config \

> /etc/pki/tls/openssl.cnf
# openssl req -new -nodes -out apache-req.pem -keyout private/apache-key.pem -config \

> /etc/ssl/openssl.cnf
2.2 Tras la ejecución del comando openssl se debe completar una serie de preguntas como sigue:

..................................++++++
................++++++
writing new private key to 'private/apache-key.pem'
-----
-----
State or Province Name (full name) [Lima]:Loreto
Locality Name (eg, city) [Lima]:Iquitos
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Hnos. Soto SRL
Organizational Unit Name (eg, section) []:Gerencia
Common Name (eg, YOUR name) []:www.sotohnos.com.pe
Email Address []:info@sotohnos.com.pe
Please enter the following 'extra' attributes

to be sent with your certificate request
A challenge password []:secret
An optional company name []:[Enter]
Lo resaltado en negrita es lo que correspondería ingresar al usuario desde el teclado. El significado de los campos que
forman parte del certificado se describen debajo:
Nombre del campo Descripción Ejemplos

La abreviación ISO de 2 letras que identifica al país de la entidad
Country Name PE
que solicita el certificado.
El estado o provincia donde se ubica la organización. No puede
State or Province Name Loreto
ser abreviado.
OpenSourceCollege
Linux for SysAdmins
Página 247
Source Linux
La ciudad donde se ubica la organización. No puede ser
City or Locality Name Iquitos
abreviado.
Organization Name El nombre legal exacto de la organización. No debe ser abreviado. Hnos. Soto SRL
Opcional para información adicional de la unidad de la
Organizational Unit Gerencia
organización.
Debe corresponder al nombre de host (Ejm:
www.sotohnos.com.pe) o dirección IP que hará uso del certificado
Common Name www.sotohnos.com.pe
una vez expedido. Si se desea utilizar el certificado para varios
subdominios se puede especificar como *.sotohnos.com.pe
Email Address La dirección e-mail de contacto del administrador. info@sotohnos.com.pe
Opcional. Password que será asociado al certificado para posibles
Challenge Password -
usos futuros en revocaciones. Puede ser dejado en blanco
Opcional. Puede contener un nombre alternativo de la entidad
Company Name -
solicitante de certificados.
2.3 Verificar que se haya creado correctamente el CSR (solicitud de certificado) visualizando su contenido como sigue:
# openssl req -in apache-req.pem -text -noout
2.4 Una vez creado el CSR, éste ya podría ser enviado a la CA para su revisión y correspondiente firma a fin de recibir de
parte de ellos el certificado solicitado.
3 Firma y creación de certificados por una CA
3.1 Este paso debe ser realizado por la CA firmando la solicitud de certificado enviada por una tercera parte y generando el
respectivo certificado que se les enviará de vuelta.
# openssl ca -config /etc/pki/tls/openssl.cnf -policy policy_anything -out \

> apache-cert.pem -infiles apache-req.pem
# openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything -out \

> apache-cert.pem -infiles apache-req.pem
3.2 Tras la ejecución del comando openssl se debe confirmar dos preguntas como sigue:
Using configuration from /etc/ssl/openssl.cnf

Enter pass phrase for /root/sslCA/private/cakey.pem:[Escribir password de CA]
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 4098 (0x1002)
Validity
Not Before: Jan 7 16:01:33 2010 GMT
Not After : Jan 5 16:01:33 2020 GMT
Subject:
countryName = PE
stateOrProvinceName = Loreto
localityName = Iquitos
organizationName = Hnos. Soto SRL
organizationalUnitName = Gerencia
commonName = www.sotohnos.com.pe
emailAddress = info@sotohnos.com.pe
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
B8:4A:0E:74:74:C2:72:C3:9D:03:2C:00:2A:81:48:FB:49:4C:E0:ED
X509v3 Authority Key Identifier:
OpenSourceCollege
Linux for SysAdmins
Página 248
Source Linux
keyid:79:B2:8F:D4:A7:EB:A8:AA:1D:A4:06:08:8B:D6:58:0D:4A:65:91:3B
Certificate is to be certified until Jan 5 16:01:33 2020 GMT (3650 days)

Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries
Data Base Updated
3.3 Verificar que se haya creado correctamente el certificado visualizando su contenido como sigue:
# openssl x509 -in apache-cert.pem -text -noout
3.4 Ahora este certificado creado, apache-cert.pem, ya puede ser utilizado por algún servicio (por ejemplo servicio Web con
Apache) que atienda peticiones bajo el nombre de host www.sotohnos.com.pe
Importante:
• El proceso de creación de una CA, solicitudes y certificados desde línea de comandos según lo estudiado, puede resultar
algo tedioso para algunos usuarios.
Es por ello que de manera alterna se puede utilizar una herramienta gráfica tal como TinyCA, la que nos facilitará la creación
de Autoridades Certificadoras y certificados digitales.
OpenSourceCollege
Linux for SysAdmins
Página 249
Source Linux
13.3. Servidor Web Apache
Introducción
Un servidor web es un programa que implementa el protocolo HTTP (hypertext transfer protocol). Este protocolo está diseñado para
transferir lo que llamamos hipertextos, páginas web o páginas HTML (hypertext markup language): textos complejos con enlaces,
figuras, formularios, botones y objetos incrustados como animaciones o reproductores de musica.
Sin embargo, el hecho de que HTTP y HTML estén íntimamente ligados no debe dar lugar a confundir ambos términos. HTML es un
lenguaje de programación y un formato de archivo y HTTP es un protocolo.
Cabe destacar el hecho de que la palabra servidor identifica tanto al programa como a la máquina en la que dicho programa se ejecuta.
Existe, por tanto, cierta ambigüedad en el término, aunque no será difícil diferenciar a cuál de los dos nos referimos en cada caso. En
este artículo nos referiremos siempre a la aplicación.
Un servidor web se encarga de mantenerse a la espera de peticiones HTTP llevada a cabo por un cliente HTTP que solemos conocer
como navegador. El navegador realiza una petición al servidor y éste le responde con el contenido que el cliente solicita. A modo de
ejemplo, al teclear www.wikipedia.org en nuestro navegador, éste realiza una petición HTTP al servidor de dicha dirección. El servidor
responde al cliente enviando el código HTML de la página; el cliente, una vez recibido el código, lo interpreta y lo muestra en pantalla.
Como vemos con este ejemplo, el cliente es el encargado de interpretar el código HTML, es decir, de mostrar las fuentes, los colores y
la disposición de los textos y objetos de la página; el servidor tan sólo se limita a transferir el código de la página sin llevar a cabo
ninguna interpretación de la misma.
Sobre el servicio web clásico podemos disponer de aplicaciones web. Éstas son fragmentos de código que se ejecutan cuando se
realizan ciertas peticiones o respuestas HTTP. Hay que distinguir entre:
• Aplicaciones en el lado del cliente

El cliente web es el encargado de ejecutarlas en la máquina del usuario. Son las aplicaciones tipo Java o Javascript: el
servidor proporciona el código de las aplicaciones al cliente y éste, mediante el navegador, las ejecuta. Es necesario, por
tanto, que el cliente disponga de un navegador con capacidad para ejecutar aplicaciones (también llamadas scripts).
Normalmente, los navegadores permiten ejecutar aplicaciones escritas en lenguaje javascript y java, aunque pueden
añadirse más lenguajes mediante el uso de plugins.
• Aplicaciones en el lado del servidor

El servidor web ejecuta la aplicación; ésta, una vez ejecutada, genera cierto código HTML; el servidor toma este código
recién creado y lo envía al cliente por medio del protocolo HTTP.
Las aplicaciones de servidor suelen ser la opción por la que se opta en la mayoría de las ocasiones para realizar aplicaciones web. La
razón es que, al ejecutarse ésta en el servidor y no en la máquina del cliente, éste no necesita ninguna capacidad adicional, como sí
ocurre en el caso de querer ejecutar aplicaciones javascript o java. Así pues, cualquier cliente dotado de un navegador web básico
puede utilizar este tipo de aplicaciones.
Algunos conceptos relacionados con las aplicaciones web son:
• PHP
• ASP
• Perl
• CGI
• .NET
• JSP (Tecnología Java )
Algunos servidores web importantes son:

• Apache
• IIS
• Cherokee
Otros servidores, más simples pero más rápidos, son:

• lighttpd
• thttpd
La fundación Apache
La fundación Apache tiene a su cargo el desarrollo y mantenimiento de una serie de proyectos Open Source cuyo sitio Web oficial es:
http://www.apache.org
Si Ud. aprecia con algo de calma el sitio Web apreciará que existen muchos proyectos Geronimo, Jakarta, SpamAssassin, Tomcat,
HTTP Server, entre otros más. Comúnmente se le suele conocer simplemente como Apache al servidor Web por excelencia para
sistemas Unix.
Actualmente se mantienen dos ramas de desarrollo del servidor Web Apache siendo estas la versión 1.3.x y la 2.x (para ser exactos en
realidad se mantienen ya 3 ramas: 1.3.x, 2.0.x y 2.2.x).
La diferencia entre las ramas 1.3.x y la 2.x radica en aspectos técnicos como el modelo de paralelismo que cambió de funcionar bajo
OpenSourceCollege
Linux for SysAdmins
Página 250
Source Linux
múltiples procesos en 1.3.x (prefork) a un nuevo esquema multihebrado en 2.x (worker). Además se cambió también el mecanismo de
encadenamiento de los módulos por filtros que permite ordernar los mismos sabiendo cuál de ellos corre primero sin crear colisiones
posteriores.
Este documento asumirá que se trabaja con la rama 2.0.x del servidor Web Apache.
Instalación de Apache
El procedimiento de instalación de Apache es sencillo:
# yum groupinstall httpd mod_ssl -y
# apt-get install apache2 -y
Arquitectura de Apache
Un cambio resaltante que se introdujo en Apache 2.0.x fue la introducción de los MPMs. Para enteder qué son los MPMs primero debe
entenderse un poco cómo trabajaba Apache en la versión 1.3.x.
En la rama 1.3.x la naturaleza del desarrollo de Apache lo caracterizaba porque el proceso padre se bifurcaba creando así varios
procesos hijos los mismos que se encargaban de atender las solicitudes de clientes. Así, se debían crear tantos procesos hijos como
solicitudes simultáneas se necesitasen atender. Esto tenía como desventaja un mal desempeño en plataformas que no estaban
centradas en proceso tal como es el caso de Windows, creándose así la idea de manejar la arquitectura de Apache a través de los
MPMs.
MPM se entiende como Multi-Processing Modules y son una serie de módulos que se encargarán de monitorear la creación o
eliminación de procesos hijos o hilos dependiendo del MPM usado. Los MPMs existentes son:
• MPM Prefork (prefork)

Asimila la arquitectura de Apache 1.3.x con un proceso padre que se bifurca creando varios procesos hijos para atender
solicitudes. Bajo el esquema de este MPM se tiene que en caso que por alguna razón un proceso hijo muriese entonces
solamente se pierde una conexión, la misma que era atendida por dicho proceso hijo ya muerto.
• MPM threaded (worker)

Este MPM incluye el soporte de hilos. Es similar al MPM Prefork con la diferencia que cada proceso hijo ya no consta de un
único hilo sino de varios, y cada uno de esos hilos es capaz de atender una solicitud distinta dotando de una gran
escalabilidad a Apache. Bajo este esquema se tiene que Apache podría atender hasta 300 solicitudes simultáneas si inicia 30
procesos hijos de 10 hilos cada uno.
Además si por alguna razón alguno de los hilos pertenecientes a un proceso hijo muriese entonces causará la muerte de
todo el proceso junto con sus hilos generando la pérdida de todas las conexiones atendidas por los hilos pertenecientes al
proceso.
En este MPM todos los procesos hijo se ejecutan bajo el mismo usuario y grupo.
• MPM Perchild (perchild)

Este es un MPM muy similar al Threaded con la diferencia que cada proceso hijo puede ejecutarse bajo un usuario y grupo
distinto permitiendo así servir sitios Web virtuales bajo los privilegios de usuario y grupo diferentes.
Estos son los MPMs más resaltantes para la plataforma Unix, sin embargo existen otros más como el MPM winnt para la plataforma
Windows, y algunos otros más que pueden ser especificados en el momento de la compilación: "./configure --help | less"
Estructura de archivos de configuración de Apache

El software de servidor Web Apache, por lo general se identifica bajo distintos nombres de paquete en cada distribución Linux. Así
como vimos el paquete que contiene Apache en Red Hat y derivados es httpd, mientras que en Debian es apache2.
Cada una de estas dos principales distribuciones organiza de forma diferente los archivos de configuración de Apache, como se
muestra en la tabla inferior:
Red Hat / CentOS y derivados Debian y derivados Descripción

/etc/httpd /etc/apache2 Directorio raíz de trabajo de Apache.
/etc/httpd/conf /etc/apache2 Directorio que contiene la configuración principal de Apache.
Directorio que contiene archivos de configuraciones adicionales
/etc/httpd/conf.d /etc/apache2/conf.d
de Apache.
Directorio que contiene archivos *.conf y *.load de configuración
- /etc/apache2/mod-available
de todos los módulos instalados de Apache.
OpenSourceCollege
Linux for SysAdmins
Página 251
Source Linux
Directorio que contiene enlaces simbólicos a los archivos *.conf
y *.load del directorio /etc/apache2/mods-available de modo tal
- /etc/apache2/mod-enabled
que estos enlaces representen los módulos habilitados en la
configuración de Apache.
Directorio que contiene archivos de configuración disponibles
- /etc/apache2/sites-available
de Hosts Virtuales de Apache.
Directorio que contiene enlaces simbólicos a los archivos del
directorio /etc/apache2/sites-available de modo tal que estos
- /etc/apache2/sites-enabled
enlaces representen los Hosts Virtuales habilitados en la
configuración de Apache.
Enlace simbólico al directorio donde se almacenan los logs de
/etc/httpd/logs -
Apache.
Enlace simbólico al directorio donde se almacenan los módulos
/etc/httpd/modules -
de Apache.
Enlace simbólico al directorio donde se almacenan el archivo
/etc/httpd/run -
PID de Apache cuando está en ejecución.
/etc/httpd/conf/httpd.conf /etc/apache2/apache2.conf Archivo de configuración principal de Apache.
Archivo de configuraciones personalizadas de usuarios. Por
- /etc/apache2/httpd.conf
defecto vacío.
- /etc/apache2/ports.conf Archivo de configuración de los puertos de escucha de Apache.
El archivo de configuración principal de Apache suele dividirse en otros que contienen directivas específicas a ciertos propósitos como
sucede en Debian, SuSE u otras distribuciones.
Sin tomar en cuenta la separación en múltiples archivos, la configuración principal de Apache suele organizarse de la siguiente forma
dentro del archivo:
Directivas de configuración
general
Directivas de configuración del

servidor principal
Directivas de configuración de
hosts virtuales
hosts virtuales
...
...
...
hosts virtuales
Es así que nosotros en este documento empezaremos a detallar las directivas de configuración clasificadas en este esquema de modo
tal que pueda facilitarse la lectura y comprensión por parte del lector.
Es importante entender que cada directiva tendrá un contexto bajo el cual funciona. Los contextos existentes son:
Contexto de configuración del servidor

Son las directivas que pueden aparecer en cualquier parte del archivo de configuración fuera de cualquier contenedor y archivo de
configuración de ámbito de directorio (.htaccess). Estas directivas permiten cambiar el comportamiento general del servicio y
afectan a todos los demás contextos.
Contexto de contenedor
Son aquellas directivas que están contenidas dentro de contenedores de similar sintaxis a etiquetas HTML. Existen los siguientes
contenedores:
• <VirtualHost ...> ... </VirtualHost>
OpenSourceCollege
Linux for SysAdmins
Página 252
Source Linux
• <Directory ...> ... </Directory>
• <DirectoryMatch ...> ... </DirectoryMatch>
• <Files ...> ... </Files>
• <FilesMatch ...> ... </FilesMatch>
• <Location ...> ... </Location>
• <LocationMatch ...> ... </LocationMatch>
• <Limit ...> ... </Limit>
Contexto en el ámbito de directorio

Son aquellas directivas que se incluyen en un archivo de configuración de ámbito de directorio, que por defecto suelen tener el
nombre '.htaccess'. Las directivas de configuración contenidas en uno de estos archivos afectan únicamente al directorio en el
que se encuentran.
La directiva AllowOverride permitirá invalidar todo, nada o sólo parte de las directivas que puedan encontrarse en un archivo
'.htaccess' dentro de un directorio en el sistema de archivos.
Directivas de configuración general

Las directivas de esta sección se aplican tanto al servidor principal como a los servidores virtuales. A continuación se presentan las
directivas de configuración y su detalle:
AccessFileName
Permite definir el nombre del archivo de configuración de ámbito de directorio cuyo valor por defecto es .htaccess. Apache
automáticamente verificará la existencia de un archivo con este nombre en cada directorio hacia el cual se dirija una consulta de
acceso por parte de los clientes.
Sintaxis : AccessFileName archivo [archivo] [archivo] ...

Defecto : AccessFileName .htaccess
Contexto : Configuración del servidor, Host Virtual
De este modo si Apache debe servir un archivo index.html ubicado en /var/www/html/htdocs/ entonces automáticamente se realizará
la búsqueda del archivo .htaccess en los siguientes directorios en el orden mostrado:
1. /.htaccess
2. /srv/.htaccess
3. /var/www/html/.htaccess
4. /var/www/html/htdocs/.htaccess
Si se desea deshabilitar la verificación de este archivo por cada directorio recursivo entonces la siguiente configuración se lo
permitiría:
<Directory />
AllowOverrride None
</Directory>
AddDefaultCharset
Esta directiva permite definir el carácter por defecto de la cabecera Content-Type que envía Apache a los clientes.
Sintaxis : AddDefaultCharset On|Off|Juego_de_caracteres

Defecto : AddDefaultCharset Off
Contexto : Todos
Cuando su valor es On entonces por defecto se envía iso-8859-1 como el juego de caracteres a no ser que se especifique otro
valor distinto. Ejemplos:
AddDefaultCharset On
AddDefaultCharset On utf-8
DefaultType
Esta directiva permite definir un tipo de contenido por defecto, de modo que Apache utiliza un tipo MIME determinado cuando
recibe una solicitud de un documento de un tipo de archivo desconocido o cuyo tipo MIME no se pudo asociar con los disponibles
para el servidor.
Sintaxis : DefaultType tipo_MIME

Defecto : DefaultType text/html
OpenSourceCollege
Linux for SysAdmins
Página 253
Source Linux
Contexto : Todos
Si por ejemplo se decide almacenar un gran número de archivos de texto plano que carecen de extensión entonces puede crearse
un contenedor <Directory> y dentro de éste definir la directiva DefaultType como sigue:
DefaultType text/plain
DocumentRoot
Esta directiva define el directorio de mayor nivel para los archivos servidor por Apache.
Sintaxis : DocumentRoot ruta

Ejemplo:
DocumentRoot "/var/www/html/htdocs"
DirectoryIndex
Esta directiva especifica uno o más archivos que Apache intentará servir cuando los clientes solicitan un listado de directorio
poniendo el caracter "/" al final. Si no existe ninguno de los archivos indicados en esta directiva entonces Apache mostrará un
listado del contenido del directorio si se tiene Options +Indexes
Sintaxis : DirectoryIndex archivo [archivo] [archivo] ...

Defecto: DirectoryIndex index.html
Contexto : Configuración del servidor, Host Virtual, Directorio, Archivo de ámbito de directorio
Ejemplo:
DirectoryIndex index.html index.htm index.php
ErrorDocument
Esta directiva permite personalizar los mensajes mostrados ante los diferentes códigos de error HTTP generados por Apache. Es
así que se pueda mostrar una página de mejor apariencia y más intuitiva cuando se intenta acceder a un documento que no existe
en lugar de mostrar el típico error 404 Not Found.
Sintaxis : ErrorDocument Codigo_de_error Nombre_de_archivo|mensaje_de_error|URL

Defecto : Ninguno
Contexto : Todos
El primer ejemplo muestra un mensaje más amigable y la razón específica brindada por Apache contenida en %s. El segundo
ejemplo muestra al usuario una documento específico el cual ya tiene un contenido elaborado.
ErrorDocument 404 "Lo sentimos pero su solicitud no es valida. La razon fue: %s"
ErrorDocument 404 /var/www/html/errors/error-404.html
Alias
Esta directiva permite que Apache sirva documentos ubicados fuera del directorio especificado en DocumentRoot. Tener en
cuenta que si se indica el caracter "/" al final de la ruta_URL entonces se requerirá que el cliente también escriba el caracter "/"
al final de la URL con la que efectúa la solicitud.
Sintaxis : Alias ruta_URL ruta_de_archivo|ruta_de_directorio

Defecto : Ninguno
Ejemplo:
Alias /webmail /var/www/html/htdocs/horde
AliasMatch
Esta directiva es equivalente a la directiva Alias pero permite el uso de expresiones regulares extendidas para indicar la URL
solicitada por el cliente.
OpenSourceCollege
Linux for SysAdmins
Página 254
Source Linux
Sintaxis : Alias regex ruta_de_archivo|ruta_de_directorio
Defecto : Ninguno
Ejemplo:
AliasMatch /(correo|webmail) /var/www/html/htdocs/horde
Redirect
Esta directiva permite redirigir al cliente a una URL distinta a la que intentó acceder inicialmente. La antigua URL está representada
por ruta_URL y no puede ser una ruta relativa, sino absoluta empezando con "/". La nueva URL debe ser absoluta especificando
el protocolo y nombre de host pero también se puede especificar como una ruta absoluta empezando con "/" en cuyo caso se
asumirá que el protocolo y nombre de host son los mismos que atienden la solicitud actual.
Si no se especifica el estado se asume por defecto el valor "temporary" (Estado HTTP 302).
Sintaxis : Redirect [estado] ruta_URL URL

Defecto : Ninguno
Los estados posibles a usar son:
permanent
Retorna el estado 301 indicando que el recurso se ha movido de manera permanente
temp
Retorna el estado 302 indicando que el recurso se ha movido de manera temporal. Valor por
defecto
seeother
Retorna el estado 303 indicando que el recurso se ha reemplazado
gone
Retorna el estado 410 indicando que el recurso se ha eliminado de manera permanente
Ejemplos:
Redirect permanent /webmail http://mail.webdomain.com/correo

Redirect 303 /admin http://www.webdomain.com/login
RedirectMatch
Esta directiva es equivalente a Redirect con la única diferencia que pueden usarse expresiones regulares extendidas para
especificar la URL a la que el cliente intentaba acceder.
Sintaxis : RedirectMatch [estado] regex URL

Defecto : Ninguno
Ejemplos:
RedirectMatch ^/$ http://mail.soporteonline.com/horde
<IfDefine>
Esta directiva permite crear una configuración condicional basado en la la veracidad del parámetro evaluado. El parámetro que se
evalúa puede ser pasado a Apache en la línea de comandos con la opción -D al programa httpd.
Sintaxis : <IfDefine [!]parametro> ... </IfDefine>

Defecto : Ninguno
Contexto : Todos
Puede realizar una prueba invocando a Apache un parámetro con el comando "httpd -D prueba" y la siguiente configuración:
OpenSourceCollege
Linux for SysAdmins
Página 255
Source Linux
<IfDefine prueba>
# Directivas de configuración que podrían aplicarse deben
# escribirse dentro de este contenedor
</IfDefine>
<IfModule>
Esta directiva permite crear una configuración condicional basado en el hecho de que el módulo indicado como parámetro al
contenedor esté actualmente cargado en Apache. Esto permite incluir directivas de configuración que dependen de módulos
específicos.
Sintaxis : <IfModule [!]modulo> ... </IfModule>

Defecto : Ninguno
Contexto : Todos
En el siguiente ejemplo se incluyen las directivas de configuración que trae el módulo mod_userdir solamente si éste está
cargado actualmente en Apache:
<IfModule mod_userdir.c>
UserDir public_html
UserDir disabled root
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
</Directory>
</IfModule>
Include
Esta directiva permite incluir directivas de configuración desde otro archivo externo las cuales serán incluidas inmediatamente
después del punto del archivo de configuración actual desde el que fue llamado.
Sintaxis : Include ruta_del_archivo

Defecto : Ninguno
Contexto : Todos
En el primer ejemplo se llama a un archivo de configuración externo específico, mientras que en el segundo se hace una
invocación a todos aquellos de extensión .conf dentro de un directorio:
Include /etc/apache2/ports.conf
Include /etc/apache2/conf.d/*.conf
Options
Esta directiva permite controlar qué características particulares estarán habilitadas en un directorio determinado.
Sintaxis : Options [+|-]opción [+|-]opción ...

Defecto : Ninguno
Contexto : Todos
La lista de opciones disponibles se muestra debajo:
None
No aplica ninguna de las opciones
All
Aplica todas las opciones
ExecCGI
Permite la ejecución de scripts CGI
FollowSymLinks
Seguirá el destino de los enlaces simbólicos. Ignorada dentro de contenedores <Location>
SymLinksIfOwnerMatch
Se siguen enlaces simbólicos sólo si el destino del enlace y el enlace pertenecen al mismo
usuario
OpenSourceCollege
Linux for SysAdmins
Página 256
Source Linux
Includes
Permite el uso de Server-side Includes
IncludesNOEXEC
Permite el uso de Server-side Includes pero #exec cmd y #exec cgi no se habilitan
Indexes
Muestra un listado del directorio cuando no se encuentra el archivo de la directiva
DirectoryIndex
MultiViews
Permite los MultiViews que es la negociación de contenidos basado en lenguaje de documentos
Listen
Esta directiva define las direcciones y puertos en los que escuchará el servicio. El uso de esta directiva es obligatorio o de lo
contrario Apache se negará a arrancar.
Sintaxis : Listen [dirección-IP:]puerto

Defecto : Ninguno
Contexto : Configuración del servidor
Pueden indicarse múltiples directivas especificando distintas direcciones y/o puertos de escucha como en el siguiente ejemplo:
Listen 80
Listen 192.168.254.13:8080
ServerAdmin
Esta directiva permite definir una dirección de correo electrónico que aparecerá en muchos de los mensajes de error mostrador por
Apache.
Sintaxis : ServerAdmin e-mail

Defecto : Ninguno
Ejemplo:
ServerAdmin webmaster@consultorianet.com
ServerName
Esta directiva permite definir el nombre del host del servidor. Se recomienda usar un FQDN o nombre DNS completo dado que esto
repercutirá directamente en la configuración de Hosts Virtuales debido a que en la versión 1.1 del protocolo HTTP la cabecera
Host permitirá indicarle a Apache qué sitio Web servidor según el valor de esta directiva.
Sintaxis : ServerName nombre_dns

Defecto : Ninguno
Ejemplo:
ServerName httpd.apache.org
ServerRoot
Esta directiva permite definir bajo qué directorio se encuentran los archivos y directorios que conforman la estructura de Apache.
Bajo esta ruta se buscarán los directorios bin, conf, htdocs, icons, cgi-bin y logs. Por lo general no se necesita cambiar
esta directiva del valor que ya se encuentra asignado.
Sintaxis : ServerRoot ruta

Defecto : Ninguno
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Página 257
Source Linux
ServerRoot /etc/httpd
ServerSignature
Esta directiva permite mostrar o no un pie de página en cada mensaje de error y listado de directorios mostrado a los usuarios. Se
recomienda mantener en Off esta directiva a fin de no brindar información de más que pueda serle útil a un potencial atacante.
Sintaxis : ServerSignature On|Off|e-mail

Defecto : Off
Contexto : Todos
Ejemplo:
ServerSignature On
ServerTokens
Esta directiva permite definir los campos que tendrá el identificador que se muestra a los clientes cuando se informa del servidor en
uso en las cabeceras HTTP. Se recomienda brindar la menor cantidad de información posible sobre el servidor.
Sintaxis : ServerTokens Prod[uctOnly]|Major|Minor|Min[imal]|OS|Full

Defecto : ServerTokens Full
El nivel de información que brinda cada opción es como sigue:
ServerTokens Prod : Apache

ServerTokens Major : Apache/2
ServerTokens Minor : Apache/2.0
ServerTokens Minimal : Apache/2.0.41
ServerTokens OS : Apache/2.0.41 (Unix)
ServerTokens Full : Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2
User
Esta directiva asigna el ID de usuario que utilizarán los hijos de Apache durante su ejecución para atender las solicitudes HTTP.
Sintaxis : User usuario

Defecto : User #-1
Ejemplo:
User apache
Group
Esta directiva asigna el ID de grupo que utilizarán los hijos de Apache durante su ejecución para atender las solicitudes HTTP.
Sintaxis : Group grupo

Defecto : Group #-1
Ejemplo:
ServerName httpd.apache.org
Directivas de configuración de recursos y rendimiento
MaxClients
Esta directiva define la cantidad de conexiones simultáneas máximas que pueden atenderse.
Si se usa el MPM Prefork esta directiva resultará en limitar la cantidad máxima de procesos hijo que pueden crearse debido a que
cada proceso hijo es capaz de atender solamente una solicitud. El valor por defecto es 256 bajo este MPM.
Si se usa un MPM hebrado como worker o beos, entonces esta directiva limita la cantidad máxima de hebras que pueden estar
disponibles para servir clientes. Así, el valor por defecto de esta directiva para el MPM worker es 16 el cual multiplicado por el
OpenSourceCollege
Linux for SysAdmins
Página 258
Source Linux
valor de la directiva ThreadsPerChild (Cantidad de hilos por proceso hijo, por defecto en 25) define un máximo de 400 clientes
simultáneos como máximo.
Sintaxis : MaxClients numero

Defecto : MaxClients 256 (prefork)
MaxClients 16 (worker)
Ejemplo:
MaxClients 15
ThreadsPerChild
Esta directiva define la cantidad de hebras o hilos creados por cada proceso hijo. Solamente tiene sentido para los MPM de
naturaleza hebrada como worker.
Sintaxis : ThreadsPerChild numero

Defecto : ThreadsPerChild 25
Ejemplo:
ThreadsPerChild 30
MaxRequestsPerChild
Esta directiva permite definir la cantidad máxima de solicitudes que un proceso hijo puete atender durante toda su existencia. Una
vez que atiende el número de solicitudes indicadas en esta directiva el proceso hijo se eliminará para luego crearse otro. Si el valor
especificado es 0 entonces el proceso hijo nunca morirá lo que signfica que podrá atender un número ilimitado de solicitudes
mientras se mantenga vivo. Se recomienda sin embargo asignar valores distintos de cero.
Sintaxis : MaxRequestsPerChild numero

Defecto : MaxRequestsPerChild 10000
Ejemplo:
MaxRequestsPerChild 9000
MaxRequestsPerThread
Similar a MaxRequestsPerChild pero limitando el número máximo de solicitudes que puede atender cada hebra en un proceso
hijo. Si el número definido es 0 entonces la hebra nunca se elimina y atiende peticiones indefinidamente. Se recomienda sin
embargo asignar valores distintos de cero.
Sintaxis : MaxRequestsPerThread numero

Defecto : MaxRequestsPerThread 0
Ejemplo:
MaxRequestsPerThread 400
StartServers
Esta directiva define la cantidad de procesos hijos a crearse al iniciar Apache. Esto no significa que no puedan existir más o menos
procesos hijo que la cantidad indicada en esta directiva pues el número de dichos procesos es controlado de manera dinámica
según la carga a la que se encuentre expuesta el servidor en un instante determinado.
Sintaxis : StartServers numero

Defecto : StartServers 5 (prefork)
StartServers 3 (worker)
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Página 259
Source Linux
StartServers 4
MaxSpareThreads
Esta directiva define la cantidad máxima de hebras en espera que pueden existir.
Si se usa el MPM worker, leader o threadpool el valor por defecto es 250, que contabilizará el total de hebras que sumen
todos los procesos hijo.
Si se usa el MPM perchild el valor por defecto es 10, y contabilizará el total de hebras que puede tener cada proceso hijo.
Sin importar el MPM usado cuando exista una cantidad de hebras en espera mayor al número definido en esta directiva entonces
se empezarán a eliminar tantas hebras como sean necesarias para llegar al límite deseado.
Sintaxis : MaxSpareThreads numero

Defecto : MaxSpareThreads 10 (perchild)
MaxSpareThreads 250 (worker, leader, threadpool)
Ejemplo:
MaxSpareThreads 200
MinSpareThreads
Esta directiva define la cantidad mínima de hebras en espera que deben existir.
Si se usa el MPM worker, leader o threadpool el valor por defecto es 75, que contabilizará el total de hebras que sumen todos
los procesos hijo.
Si se usa el MPM perchild el valor por defecto es 5, y contabilizará el total de hebras que puede tener cada proceso hijo.
Sin importar el MPM usado cuando exista una cantidad de hebras en espera menor al número definido en esta directiva entonces
se empezarán a crear tantas hebras como sean necesarias para llegar al límite deseado.
Sintaxis : MinSpareThreads numero

Defecto : MinSpareThreads 5 (perchild)
MinSpareThreads 75 (worker, leader, threadpool)
Ejemplo:
MinSpareThreads 80
MaxSpareServers
Esta directiva determina el número máximo de procesos hijo en espera que pueden existir. Debe ajustarse esta directiva sólo en
sitios Web de muchas visitas.
Sintaxis : MaxSpareServers numero

Defecto : MaxSpareServers 10
Ejemplo:
MaxSpareServers 8
MinSpareServers
Esta directiva determina el número mínimo de procesos hijo en espera que deben existir. Debe ajustarse esta directiva sólo en
sitios Web de muchas visitas.
Sintaxis : MinSpareServers numero

Defecto : MinSpareServers 5
Ejemplo:
MinSpareServers 4
Directivas de configuración de registro
OpenSourceCollege
Linux for SysAdmins
Página 260
Source Linux
LogLevel
Esta directiva define el nivel de registro que se almacenará en los logs de error.
Sintaxis : LogLevel nivel

Defecto : LogLevel error
Los niveles existentes que se pueden asignar a esta directiva son:
Emerg
Situación de extrema emergencia
Alert
Se requiere una acción inmediata
Crit
Errores críticos
Error
Condiciones de error
Warn
Mensajes de alerta
Notice
Mensajes de varios tipos
Info
Mensajes de información
Debug
Mensajes de depuración de errores
Ejemplo:
LogLevel warn
ErrorLog
La directiva ErrorLog determina el nombre del fichero en el cual el servidor almacenará los mensajes de error en caso de que
ocurra alguno. Si ruta_archivo no es absoluto, entonces se asume que es relativo al valor especificado en la directiva
ServerRoot.
Sintaxis : ErrorLog ruta_archivo|syslog[:facilidad]

Defecto : ErrorLog logs/error_log
Ejemplo:
ErrorLog /var/log/apache/error.log
Si el ruta_archivo empieza con un barra vertical "|" entonces se asume que es un comando para procesar el registro de
errores. Ejemplo:
ErrorLog "|/usr/local/bin/httpd_errors"
Usar syslog en lugar de un nombre de fichero permite almanecer los mesajes mediante el demonio syslogd si el sistema lo
soporta. Por defecto se usa la utilidad de syslog local7, pero puede cambiar esto usando syslog:facility donde facility es
cualquiera de los nombres normalmente documentados en syslog(1). Ejemplo:
ErrorLog syslog:user
CustomLog
Esta directiva permite guardar registros de las consultas de los clientes al servidor. Se requiere indicar un formato para el archivo
de logs y se puede hacer un registro condicional basado en la existencia de ciertas variables de entorno.
Similar a la directiva ErrorLog el registro puede enviarse a un archivo o hacia una pipe para ser procesado por otra aplicación.
OpenSourceCollege
Linux for SysAdmins
Página 261
Source Linux
El formato puede ser especificado como una serie de caracteres de significado especial tales como %h, %l, %u, %t, %r, etc. Los
mismos que están detallados en la documentación de Apache. Sin embargo se puede optar por especificar un formato ya definido a
través de un nombre conocido como por ejemplo common
Sintaxis : CustomLog archivo|pipe formato|nombre [env=[!]env-var]

Defecto : Ninguno
En el siguiente ejemplo la directiva LogFormat define un formato encerrado entre doble comillas (" ") y a éste le da un nombre, el
mismo que posteriormente es usado en CustomLog:
LogFormat "%h %l %u %t \"%r\" %>s %b" common

CustomLog /var/log/apache/access.log common
PidFile
Esta directiva define la ruta del archivo que contiene el PID del proceso principal de Apache.
Sintaxis : PidFile ruta_del_archivo

Defecto : PidFile logs/httpd.pid
Ejemplo:
PidFile /var/run/httpd.pid
Directivas de configuración de tiempos de conexión
La palabra KeepAlive hace referencia a la característica por la cual se pueden realizar varias transacciones a través de una única
conexión TCP reduciendo así la carga sobre el servidor. Sin esta característica el funcionamiento típico sería abrir y cerrar una
conexión TCP por cada solicitud HTTP, lo que puede disminuir el rendimiento.
Para sacar provecho de esta característica, KeepAlive debe ser soportada tanto por el cliente como por el servidor. Ya al día de
hoy todos los navegadores modernos lo soportan.
KeepAlive
Esta directiva permite activar o desactivar el soporte de KeepAlive en el servidor.
Sintaxis : KeepAlive On|Off

Defecto : KeepAlive On
KeepAliveTimeout
Si la directiva KeepAlive está en On, entonces esta directiva permite definir el número de segundos máximos que Apache
esperará por una nueva transacción HTTP antes de cerrar la conexión. Una vez que se recibe una solicitud, se inicia el conteo de
segundos según el valor especificado en la directiva TimeOut.
Sintaxis : KeepAliveTimeout segundos

Defecto : KeepAliveTimeout 15
Ejemplo:
KeepAliveTimeout 12
MaxKeepAliveRequests
Si la directiva KeepAlive está en On, entonces esta directiva definirá un límite máximo de transacciones HTTP que se permitirán
por conexión TCP. Si el valor para esta directiva es 0 entonces se permitirán infinitas transacciones.
Sintaxis : MaxKeepAliveRequests numero

Defecto : MaxKeepAliveRequests 100
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Página 262
Source Linux
MaxKeepAliveRequests 150
TimeOut
Esta directiva define la cantidad máxima de segundos que Apache esperará por la recepción de datos antes de romper la conexión.
El tiempo definido en esta directiva se aplica a:
✔ El tiempo de duración de una solicitud GET

✔ El tiempo de recepción de paquetes TCP en solicitudes POST o PUT.
✔ El tiempo entre las respuestas ACK de las transmisiones de los paquetes TCP.
Sintaxis : TimeOut segundos

Defecto : TimeOut 300
Ejemplo:
MaxKeepAliveRequests 150
Directivas de configuración de autenticación y seguridad
AllowOverride
Esta directiva permite limitar qué directivas de las encontradas en un archivo de ámbito de directorio (.htaccess) pueden
sobreescribir los valores definidos en las directivas de configuración de ámbito general.
Si su valor se fija en None entonces Apache ya no busca la existencia de los archivos .htaccess en cada directorio recursivo por
cada solicitud de los clientes acelerando así el tiempo de respuesta del servidor.
Sintaxis : AllowOverride All|None|Tipos

Defecto : AllowOverride All
Contexto : Directorio
Los tipos que pueden especificarse en esta directiva son:
AuthConfig
Permite usar directivas de autenticación
FileInfo
Permite usar directivas que controlan los tipos de documento
Indexes
Permite el uso de directivas que controlan el indexado de directorios
Limit
Permite el uso de directivas que controlan el acceso al host
Options
Permite usar directivas que controlan funcionalidades específicas de directorios
Ejemplo:
AllowOverride AuthConfig Options
AuthType
Esta directiva selecciona el tipo de autenticación a usar para proteger un recurso servido por Apache. Los dos tipos de
autenticación incluidos en la distribución base de Apache son Basic y Digest.
Basic transmite el usuario y clave en texto plano pero está soportado por casi todos los navegadores, mientras que Digest es
más segura que Basic pero no todos los navegadores soportan correctamente este esquema de autenticación.
Esta directiva requiere ir acompañada de otras como AuthName, AuthUserFile y/o AuthGroupFile para que la autenticación
funcione correctamente.
Sintaxis : AuthType Basic|Digest

Defecto : Ninguno
Contexto : Directorio, archivo de ámbito de directorios
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Página 263
Source Linux
AuthType Basic
AuthName
Esta directiva el nombre del campo para un recurso protegido determinado. El valor de esta directiva será mostrado al cliente en el
momento que se autentique y el objetivo es informar al usuario sobre el tipo de recurso al que está a punto de acceder.
Sintaxis : AuthName "texto"

Defecto : Ninguno
Ejemplo:
AuthName "Area restringida: Se requiere autenticacion"
AuthUserFile
Esta directiva define la ruta de un archivo que contiene un listado de usuarios y contraseñas de los cuales Apache hará una
comparación al momento que los usuarios se autentiquen.
Este archivo de contraseñas ha de crearse con la herramienta htpasswd si se opta por el esquema de autenticación Basic, o con
la herramienta htdigest si se opta por el esquema Digest.
Sintaxis : AuthUserFile ruta_del_archivo

Defecto : Ninguno
Ejemplo:
AuthUserFile "/etc/apache2/.htpasswd"
AuthGroupFile
Esta directiva define la ruta de un archivo que contiene un listado de los grupos de usuarios que se leerán para la autenticación.
El contenido del archivo debe tener la siguiente forma:
Nombre-grupo: usuario1 usuario2 usuario3 ...
Sintaxis : AuthGroupFile ruta_del_archivo

Defecto : Ninguno
Ejemplo:
AuthGroupFile "/etc/apache2/.htgroups"
Require
Esta directiva define qué usuarios o grupos pueden acceder a un recurso protegido determinado. Se usa en conjunto con un
esquema de autenticación con las directivas AuthType, AuthUserFile y AuthName.
Sintaxis : Require nombre_entidad nombre_entidad ...

Defecto : Ninguno
Los valores posibles de esta directiva son los siguientes:
user
Define una lista de usuarios separados por espacios en blanco que pueden acceder al recurso
group
Define una lista de grupos separados por espacios en blanco que pueden acceder al recurso
valid-user
Permite que cualquier usuario autenticado acceda al recurso
OpenSourceCollege
Linux for SysAdmins
Página 264
Source Linux
Ejemplos:
Require valid-user
Require user achavez psoto ltorres
Require group alumnos docentes gerentes
Allow
Esta directiva permite el acceso a un recurso determinado basándose en la información de Host del cliente que genera la solicitud.
Sintaxis : Allow from all|Host|env=env-variable[all|Host|env=env-variable]

Defecto : Ninguno
Valores posibles para esta directiva son:
All
Permite el acceso a todos
env=variable_entorno
Se permite el acceso sólo si la variable 'env-variable' existe
Host
Permite el acceso solamente al host que coincida con alguna de las siguientes formas válidas:
- Dirección IP completa : 201.230.34.121

- Dirección IP parcial : 192.168.3
- Par red/máscara : 172.16.23.0/255.255.255.0
- Notación CIDR red/N : 10.13.0.0/16
- Nombres DNS parciales : tldp.org
El último de los ejemplos permitirá el acceso a los hosts cuya resolución inversa coincida de manera exacta o parte del dominio
netdomain.com. Es así que coincide con mail.netdomain.com y netdomain.com pero no con smtp.newnetdomain.com
Allow from 192.168.3.2 192.168.3.19

Allow from 200.60.92.32/28
Allow from netdomain.com
Deny
Esta directiva deniega el acceso a un recurso determinado basándose en la información de Host del cliente que genera la solicitud.
Sintaxis : Deny from all|Host|env=env-variable[all|Host|env=env-variable]

Defecto : Ninguno
El modo de funcionamiento de esta directiva es idéntica a Allow. Ejemplos:
Allow from 10.0.0.0/8

Deny from spray.se
Order
Esta directiva usada junto con Allow y Deny define un orden en el que las restricciones se aplicarán para permitir o denegar el
acceso a cierto recurso servido por Apache. La lógica es similar a las reglas de filtrado de iptables y su jerarquía con las políticas
por defecto aplicadas.
Sintaxis : Order orden

Defecto : Order Deny,Allow
Las dos posibles formas de definir esta directiva son:
OpenSourceCollege
Linux for SysAdmins
Página 265
Source Linux
Allow,Deny
Primero se evalúan todas las directivas Allow y se permite el acceso si alguna coincide. Se
deniega el acceso cuando haya coincidencia con alguna directiva Deny o si ninguna directiva
Allow genera coincidencia.
Deny,Allow
Primero se evalúan todas las directivas Deny y se deniega el acceso si alguna coincide. Se
permite el acceso cuando haya coincidencia con alguna directiva Allow o si ninguna directiva
Deny genera coincidencia.
En el siguiente ejemplo se permite el acceso solamente a los hosts de la red 192.168.0.0/24 y se deniega a todos los demás:
Order Allow,Deny
Allow from 192.168.0.0/24
Satisfy
Si se ha creado un esquema de autenticación con AuthType y Require para proteger un recurso y también se ha usado la
directiva Allow para limitar el acceso, entonces la directiva Satisfy permite qué requisitos de autenticación o autorización son
suficientes. Esta directiva es útil solamente si se protege un recurso por autenticación (AuthType) y por acceso (Allow).
Sintaxis : Satisfy Any|All

Defecto : All
Los valores posibles de esta directiva son los siguientes:
Any
Permite el acceso si se cumple Allow o Require tienen éxito
All
Requiere que tanto Allow como Require tengan éxito
Ejemplo:
Satisfy Any
Directivas de configuración de contenedores
<Directory>
Esta directiva permite encerrar una serie de directivas aplicables solamente al directorio especificado incluido sus subdirectorios.
Sintaxis : <Directory directorio> ... </Directory>

Defecto : Ninguno
Estas directivas pueden solapar rutas de modo tal que se anule la herencia de directivas de un directorio padre. Nótese en el
siguiente ejemplo que se permite el indexado del directorio "/var/www/html/htdocs" pero no de "/var/www/html/htdocs/
downloads":
<Directory /var/www/html/htdocs>
Options +Indexes
</Directory>
<Directory /var/www/html/htdocs/downloads>
Options None
</Directory>
Puede hacerse uso también de caracteres comodín como * , ? ó [ ]:
<Directory /var/www/*cgi*>
Options +ExecCGI
</Directory>
<Directory /var/www/htdocs/stats[0-9]>
Options +Indexes +FollowSymLinks
OpenSourceCollege
Linux for SysAdmins
Página 266
Source Linux
</Directory>
Las expresiones regulares extendidas pueden usarse también en la definición de un directorio anteponiendo el caracter ~ a la ruta
como sigue:
<Directory ~ /(var|srv)/w{3}/ht(ml|docs)>
Order Allow,Deny
Allow from 10.0.0.0/8 192.168.0.0/24
</Directory>
<DirectoryMatch>
Esta directiva es similar a <Directory> con la diferencia que el directorio se especifica como una expresión regular extendida sin
necesidad de anteponer el caracter ~
Sintaxis : <DirectoryMatch regex> ... </DirectoryMatch>

Defecto : Ninguno
Ejemplo:
<Directory /var/www/html/htdocs/horde.*>
AllowOverride None
</DirectoryMatch>
<Files>
Esta directiva permite encerrar directivas aplicables a archivos de modo similar como <Directory> funciona con directorios.
También es posible usar comodines de shell (*, ?, [ ]) y expresiones regulares con el caracter ~ antepuesto.
Sintaxis : <Files archivo> ... </Files>

Defecto : Ninguno
Ejemplo:
<Files ~ "\.ht(acce|pa)ss.*">
Deny from all
</Files>
<FilesMatch>
Directiva similar a <Files> que acepta una expresión regular extendida sin necesidad de usar el caracter ~
Sintaxis : <FilesMatch regex> ... </FilesMatch>

Defecto : Ninguno
Ejemplo:
<FilesMatch ~ "\.(doc|ppt|xls|odt|odp|ods)$">
Order Allow,Deny
Allow from 192.168.1.0/24
</FilesMatch>
<Location>
Esta directiva permite controlar el acceso basándose en una URL. Estos contenedores son leídos después de <Directory> y los
archivos .htaccess
Sintaxis : <Location URL> ... </Location>

Defecto : Ninguno
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Página 267
Source Linux
<Location /admin>
AuthType Basic
AuthName "Zona restringida"
AuthUserFile "/etc/httpd/.htpasswd"
Require valid-user
</Location>
<Location ~ "/admin/stat.*">
Order Allow,Deny
Allow from 192.168.1.0/24
</Location>
<LocationMatch>
Esta directiva permite controlar el acceso basándose en una URL haciendo uso de expresiones regulares extendidas.
Sintaxis : <LocationMatch regex> ... </LocationMatch>

Defecto : Ninguno
Ejemplo:
<LocationMatch "/downloads/nota.*">
Order Allow,Deny
Allow from 192.168.1.0/24
</LocationMatch>
Directivas de configuración de Hosts Virtuales
NameVirtualHost
Esta directiva define las direcciones IP y puertos en los que Apache quedará a la escucha de conexiones para Hosts Virtuales
basados en nombre.
Si esta directiva no es usada se asume entonces que los Hosts Virtuales configurados estarán basados en direcciones IP y puerto.
Sintaxis : NameVirtualHost direccion[:puerto]

Defecto : Ninguno
Ejemplos:
NameVirtualHost *:80
NameVirtualHost 192.168.2.3:443
<VirtualHost>
Esta directiva define una configuración para el Host Virtual. Se pueden aplicar todas las directivas válidas para el contexto de Hosts
Virtuales ya estudiadas de modo tal que cuando Apache recibe la solicitud de un documento en un host virtual determinado se
usarán todas las directivas correspondientes a la sección <VirtualHost> respectiva.
Sintaxis : <VirtualHost direccion[:puerto] direccion[:puerto] ...> ... </VirtualHost>

Defecto : Ninguno
La dirección y puerto especifica por dónde funcionará dicha configuración de Host Virtual en particular, debido a que Apache puede
atender por muchas direcciones y puertos las solicitudes de Hosts Virtuales pero no todas pertenecerle a una configuración
específica.
<VirtualHost 192.168.2.3:*>
DocumentRoot /var/www/html/htdocs/mysitioweb
ServerName www.myblogpersonal.com
</VirtualHost>
Puede tambien especificarse _default_ como un nombre especial de Host Virtual el cual coincidirá con cualquier dirección IP y
OpenSourceCollege
Linux for SysAdmins
Página 268
Source Linux
puerto que no esté explícitamente declarada en alguna directiva <VirtualHost>. En caso que no haya coincidencia con ninguna
IP:puerto referida por una configuración de Host Virtual e incluso no exista la configuración para _default_ Apache procederá a
servir la configuración del servidor principal la misma que consta de directivas especificadas fuera de directivas <VirtualHost>
<VirtualHost _default_>
DocumentRoot /var/www/html/htdocs/default
</VirtualHost>
ServerName
La directiva ServerName especifica el nombre de host y el puerto que usa el servidor para identificarse. Esto se usa cuando se
hace redirección de URLs. Por ejemplo, si el nombre de la maquina del servidor web es simple.example.com, pero el la
maquina también tiene el alias DNS www.example.com y quiere que el servidor web se identifique así, debe usar la siguiente
directiva:
Sintaxis : ServerName nombre_DNS

Defecto : Ninguno
Ejemplo:
ServerName www.apache.org
ServerAlias
Esta directiva define nombres alternativos para un Host. Usado en conjunto con ServerName
Sintaxis : ServerAlias nombre_DNS

Defecto : Ninguno
Ejemplo:
ServerAlias apache.org www1.apache.org www2.apache.org www3.apache.org
Directivas de configuración OpenSSL
SSLEngine
Esta directiva habilita el soporte de SSL para el sitio Web ofrecido.
Sintaxis : SSLEngine on|off

Defecto : off
Ejemplos:
SSLEngine On
SSLCertificateFile
Esta directiva define la ruta al archivo de certificado (en formato codificado PEM) para el servidor.
Sintaxis : SSLCertificateFile ruta_del_archivo

Ejemplos:
SSLCertificateFile /etc/httpd/apache-cert.pem
SSLCertificateKeyFile
Esta directiva define la ruta al archivo de llave privada (en formato codificado PEM) para el servidor.
Sintaxis : SSLCertificateKeyFile ruta_del_archivo

OpenSourceCollege
Linux for SysAdmins
Página 269
Source Linux
Ejemplos:
SSLCertificateKeyFile /etc/httpd/apache-key.pem
Ejemplo 43: Protegiendo un recurso

A continuación se generará la configuración necesaria de Apache y los pasos a cumplir para proteger un recurso por autenticación.
a) Crear los usuarios y sus respectivas contraseñas para la autenticación:
# htpasswd -c /etc/httpd/.htpasswd arengifo

New-password:
Re-type new password:
Adding password for user arengifo
b) Para agregar más usuarios simplemente debe usarse el mismo procedimiento pero sin la opción -c:
# htpasswd /etc/httpd/.htpasswd mrios

New-password:
Re-type new password:
Adding password for user mrios
c) Ahora se generará la configuración de Apache para permitir que los usuarios permitan navegar sobre el contenido del directorio e
incluso poder acceder a elementos fuera de la ruta permitida a través de enlaces simbólicos. También se redireccionará a los usuarios
que intenten acceder al recurso a través de una URL antigua (/downloads)la que ha sido reemplazado por otra nueva.
Considerar además que los usuarios de la LAN 192.168.1.0/24 siempre tendrán acceso al recurso mientras que los usuarios
provenientes de otras direcciones requerirán autenticarse primero.
# /etc/apache2/apache2.conf
DocumentRoot /var/www/html
RedirectMatch 301 ^/download.*$ /descargas
<Directory /var/www/html>
Options None
AllowOverride None
Order Allow,Deny
Allow from all
</Directory>
<Directory /var/www/html/descargas>
Options +Indexes +FollowSymLinks
AuthType Basic
AuthName "Zona reservada de descargas"
AuthUserFile "/etc/httpd/.htpasswd"
Require valid-user
Order Allow,Deny
Allow from 127.0.0.0/8 192.168.1.0/24
Satisfy Any
</Directory>
d) Luego de verificar la sintaxis de la configuración de Apache, reiniciar el servicio y hacer las pruebas:
# httpd -t
Ejemplo 44: Hosts Virtuales para una compañía

Se crearán dos Hosts Virtuales para los dominios de una compañía que manejan contenidos distintos. Además se personalizará un
poco la presentación de errores para tener un aspecto más profesional.
a) Primero se muestra la configuración general del servidor aplicando algunos ajustes de seguridad:
# /etc/httpd/conf/httpd.conf
DocumentRoot /var/www/html
OpenSourceCollege
Linux for SysAdmins
Página 270
Source Linux
DirectoryIndex index.html index.htm
ServerAdmin webmaster@newcompany.com
ServerName localhost
ServerSignature Off
ServerTokens Off
User apache
Group apache
LogFormat "%h %l %u %t \"%r\" %>s %b" common
<Directory />
Options None
AllowOverride None
Order Allow,Deny
Deny from all
</Directory>
<Directory /var/www/html/htdocs>
Options None
AllowOverride None
Order Allow,Deny
Allow from all
</Directory>
<Directory /vhosts>
AllowOverride AuthConfig Options
</Directory>
<Directory /var/www/html/errors>
Options None
AllowOverride None
Order Allow,Deny
Allow from all
</Directory>
<FilesMatch "\.ht(acce|pa)ss.*$">
Deny from all
</FilesMatch>
NameVirtualHost *:80
<VirtualHost _default_>
DocumentRoot /vhosts/default
CustomLog /var/log/httpd/default-access.log common
<Directory /vhosts/default>
Options None
Allow from all
</Directory>
</VirtualHost>
Include /etc/httpd/conf/vhosts.d/*.conf
b) Ahora generamos la configuración de los dos Hosts Virtuales en archivos separados:
# /etc/httpd/conf/vhosts.d/vhost1.conf
<VirtualHost *>
ServerName www.cybermatrix.com.pe
ServerAlias cybermatrix.com.pe cybermatrix.com www.cybermatrix.com
ServerAdmin webmaster@cybermatrix.com.pe
DocumentRoot /vhosts/cybermatrix
DirectoryIndex index.php
LogLevel warn
ErrorLog /var/log/httpd/cybermatrix-error.log
CustomLog /var/log/httpd/cybermatrix-access.log common
<Directory /vhosts/cybermatrix>
Options +FollowSymLinks +Multiviews
Allow from all
OpenSourceCollege
Linux for SysAdmins
Página 271
Source Linux
</Directory>
</VirtualHost>
# /etc/httpd/conf/vhosts.d/vhost2.conf
<VirtualHost *>
ServerName www.newtechnologies.net
ServerAdmin webmaster@newtechnologies.net
DocumentRoot /vhosts/newtechnologies
DirectoryIndex index.php
AliasMatch ^/(webmail|correo|correoweb) /var/www/html/htdocs/horde
LogLevel error
ErrorLog /var/log/httpd/newtechnologies-error.log
CustomLog /var/log/httpd/newtechnologies-access.log common
<Directory /vhosts/newtechnologies>
Options +FollowSymLinks +Includes
Allow from all
</Directory>
</VirtualHost>
c) Luego de verificar la sintaxis de la configuración de Apache, reiniciar el servicio y hacer las pruebas:
# httpd -t
Ejemplo 45: Hosts Virtuales basados en IP para sitios Web seguros

Se crearán dos Hosts Virtuales para los dominios www.consultorianet.com y www.sotohnos.com.pe, cada uno de ellos ofreciendo sitios
Web seguros.
a) Dado que se deben crear dos Hosts Virtuales de sitios Web seguros (HTTPS), y debido a la naturaleza del protocolo SSL que no
permite crear hosts virtuales basados en nombre, desactivaremos la directiva NameVirtualHost y crearemos dos contenedores
<VirtualHost> como sigue:
#NameVirtualHost *:80
<VirtualHost 172.31.0.201:443>
ServerName www.consultorianet.com
DocumentRoot /var/www/html/www.consultorianet.com
ErrorLog /var/log/httpd/www.consultorianet.com-error.log
CustomLog /var/log/httpd/www.consultorianet.com-access.log combined
SSLEngine On
<Directory /var/www/html/www.consultorianet.com>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
<VirtualHost 172.31.0.203:443>
ServerName www.sotohnos.com.pe
DocumentRoot /var/www/html/www.sotohnos.com.pe
ErrorLog /var/log/httpd/www.sotohnos.com.pe-error.log
CustomLog /var/log/httpd/www.sotohnos.com.pe-access.log combined
SSLEngine On
<Directory /var/www/html/www.sotohnos.com.pe>
Options None
AllowOverride None
Order allow,deny
OpenSourceCollege
Linux for SysAdmins
Página 272
Source Linux
Allow from all
</Directory>
</VirtualHost>
Al desactivar NameVirtualHost entonces Apache interpreta las configuraciones de VirtualHost basadas en dirección IP y puerto
únicamente. Es así que asociamos la IP 172.31.0.201 a www.consultorianet.com y la IP 172.31.0.203 a www.sotohnos.com.pe
Sin embargo estamos utilizando el mismo certificado apache-cert.pem (anteriormente creado para www.sotohnos.com.pe) para ambos
dominios (lo que no es lo correcto pero para fines de prueba está bien).
b) Asegurarse de copiar los archivos apache-cert.pem y apache-key.pem al directorio /etc/httpd como sigue:
# cd /root/sslCA
# cp -v apache-cert.pem /etc/httpd/
# cp -v private/apache-key.pem /etc/httpd/
c) Utilizando ifconfig asegurarse que el host donde corre Apache tenga asignadas las direcciones IP 172.31.0.201 y 172.31.0.203:
# ifconfig
d) Creamos los directorios servidor por Apache para cada host virtual y dentro creamos también archivos index.html de prueba:
# mkdir /var/www/html/www.consultorianet.com
# mkdir /var/www/html/www.sotohnos.com.pe
# echo "<h1>www.consultorianet.com</h1>" > /var/www/html/www.consultorianet.com/index.html
# echo "<h1>www.sotohnos.com.pe</h1>" > /var/www/html/www.sotohnos.com.pe/index.html
e) Luego de verificar la sintaxis de la configuración de Apache, reiniciar el servicio y hacer las pruebas:
# httpd -t
Las pruebas consistirían en conectarse con un navegador a https://172.31.0.201 y https://172.31.0.203
OpenSourceCollege
Linux for SysAdmins
Página 273
Source Linux
Administración de Apache desde Webmin
configurar y monitorear el servicio Web con Apache siguiendo estos pasos:
2. Dentro de Webmin acceder a 'Servers -> Apache Webserver' y dentro revisar las opciones de configuración de este servicio.
OpenSourceCollege
Linux for SysAdmins
Página 274
Source Linux
13.4. Reportes de tráfico Web
La capacidad de generar reportes de los servicios de red instalados en un servidor resultan ser un requerimiento muy común en la
mayoría de organizaciones, más aún si se tratan de servicios de amplio uso público, tal como es el caso de los servidores Web con
soporte de Hosts Virtuales.
Por ello, en esta sección revisaremos el proceso de instalación y configuración de una excelente herramienta de generación de
reportes llamada AWStats, la que nos podrá generar informes en formatos bastante amigables para el administrador.
Descarga e instalación
AWStats puede ser descargado desde su sitio Web oficial (http://awstats.sourceforge.net), como un archivo tarball, o podemos
simplificar la instalación desde repositorios.
Este paquete está incluido en los repositorios oficiales para Debian, pero para Red Hat / CentOS no sucede lo mismo aunque no
obstante existe el repositorio DAG que sí incluye este paquete.
En Red Hat / CentOS y derivados, procederemos a crear un archivo de repositorio /etc/yum.repos.d/dag.repo con un contenido como el
siguiente:
[dag]
name=dag
gpgcheck=0
enabled=0
Luego procedemos a instalar el paquete awstats:
# yum --enablerepo=dag install awstats -y
En un sistema Debian y derivados, realizamos la instalación directa:
# apt-get install apache2 libapache2-mod-perl2 awstats -y
Este procedimiento es el recomendado para agilizar el proceso de resolución de dependencias de software y configuración
predeterminada del paquete.
Configuración de AWStats para Apache

AWStats es capaz de reconocer un número limitado de formatos de logs de distintos software de servidor tal como Apache, IIS, wu-
ftpd, etc.
Dentro del directorio /etc/awstats debe existir un archivo de nombre awstats.model.conf (Red Hat / CentOS) o awstats.conf (en Debian) el
cual contiene un modelo de la configuración de AWStats.
Crearemos una copia a partir de éste con un nombre como awstats.www.consultorianet.com.conf:
# cd /etc/awstats
# cp awstats.model.conf awstats.www.consultorianet.com.conf
# cd /etc/awstats
# cp awstats.conf awstats.www.consultorianet.com.conf
Editaremos este archivo awstats.www.consultorianet.com.conf creado y modificaremos su contenido de acuerdo al texto debajo resaltado
en negrita :
...
...
LogFile="/var/log/httpd/www.consultorianet.com-access.log"
...
...
LogType=W
...
...
LogFormat=1
OpenSourceCollege
Linux for SysAdmins
Página 275
Source Linux
...
...
LogSeparator=" "
...
...
SiteDomain="www.consultorianet.com"
...
...
Luego crearemos una configuración de AWStats para Apache como sigue:
En Red Hat / CentOS y derivados
1. El paquete awstats instalado trajo consigo un archivo de configuración modelo para Apache ubicado en
/etc/httpd/conf.d/awstats.conf, del cual debemos modificar su contenido según el texto resaltado en negrita:
Alias /awstats/icon/ /var/www/awstats/icon/
ScriptAlias /awstats/ /var/www/awstats/

<Directory /var/www/awstats/>
DirectoryIndex awstats.pl
Options ExecCGI
order deny,allow
deny from all
# allow from 127.0.0.1
allow from all
</Directory>
#Alias /css/ /var/www/awstats/css/

#Alias /js/ /var/www/awstats/js/
En Debian y derivados
1. El paquete awstats instalado trae consigo un archivo de configuración modelo para Apache ubicado en
/usr/share/doc/awstats/examples/apache.conf, del cual debemos crear una copia en /etc/apache2/conf.d/awstats.conf y modificar su
contenido según el texto resaltado en negrita:

# Security concerns:
# * Raw log processing data is accessible too for everyone
# * The directory is by default writable by the httpd daemon, so if
# any PHP, CGI or other script can be tricked into copying or
# symlinking stuff here, you have a looking glass into your server,
# and if stuff can be uploaded to here, you have a public warez site!
<Directory /var/lib/awstats>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>

<Directory /usr/share/awstats/icon>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
# This provides worldwide access to everything in the directory

Alias /awstats-icon/ /usr/share/awstats/icon/
OpenSourceCollege
Linux for SysAdmins
Página 276
Source Linux
# This (hopefully) enables _all_ CGI scripts in the default directory
# Security concerns: Are you sure _all_ CGI scripts are safe?
# ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
ScriptAlias /awstats/ /usr/lib/cgi-bin/
# invoke-rc.d apache2 restart
Finalmente ya tenemos lista la configuración de AWStats para los logs del servidor FTP, sólo nos resta instruir a través de la línea de
comandos la generación de estadísticas recientes a partir del archivo /var/log/vsftpd.log configurado, haciendo uso del script awstats.pl
que viene con el paquete awstats como sigue:
# /var/www/awstats/awstats.pl -update -config=www.consultorianet.com
# /usr/lib/cgi-bin/awstats.pl -update -config=www.consultorianet.com
El script awstats.pl genera las estadísticas por defecto en /var/www/awstats (en Red Hat / CentOS) o en /var/lib/awstats (en Debian), las
cuales son representadas por archivos de textos poco o nada entendibles.
Por ello la forma correcta de visualizar estas estadísticas generada es a través de la ejecución de un script CGI desde Apache
accediendo con un navegador a una URL como la siguiente:
http://172.31.0.201/awstats/awstats.pl?config=www.consultorianet.com
... donde se asume que el host donde se ejecuta el servidor FTP, Web y la herramienta AWStats, posee la IP 172.31.0.201.
AWStats simplificado desde Webmin

configurar y generar reportes de AWStats siguiendo estos pasos:
5. Dentro de Webmin acceder a 'Webmin -> Webmin Configuration -> Webmin Modules' e instalar el módulo de AWStats
rellenando con la URL de descarga (link obtenido desde la Web oficial de AWStats) el campo de nombre 'From ftp or http
URL' como sigue:
From ftp or http : http://prdownloads.sourceforge.net/awstats/awstats-1.8.wbm
Luego dar clic sobre el botón 'Install Module'.
OpenSourceCollege
Linux for SysAdmins
Página 277
Source Linux
6. Una vez instalado el módulo acceder a 'System -> AWStats Logfile Analyzer' y revisar las opciones de configuración del
módulo de AWStats a través de su interfaz gráfica amigable.
1. Crear una configuración de Apache para hospedar dos Hosts Virtuales correspondientes a los dominios www.estadia.com y
www.comunicaciones.net. Ambos deben atender peticiones en los puertos 80 y 443, para lo cual se reservan a cada uno de
los nombres de hosts las direcciones IP 172.31.10.20 y 172.31.10 30.
Sin embargo se requiere que para el dominio www.estadia.com se fuerce la redirección a una conexión segura (HTTPS) de
la URL http://ww.estadia.com/webmail/login.php cuando un cliente intente acceder a ella a través de una conexión insegura
(HTTPS).
OpenSourceCollege
Linux for SysAdmins
Página 278
Source Linux
13.5.1. Solución al laboratorio N° 13
1. Crear una configuración de Apache para hospedar dos Hosts Virtuales correspondientes a los dominios www.estadia.com y
www.comunicaciones.net. Ambos deben atender peticiones en los puertos 80 y 443, para lo cual se reservan a cada uno de
los nombres de hosts las direcciones IP 172.31.10.20 y 172.31.10 30.
Sin embargo se requiere que para el dominio www.estadia.com se fuerce la redirección a una conexión segura (HTTPS) de
la URL http://ww.estadia.com/webmail/login.php cuando un cliente intente acceder a ella a través de una conexión insegura
(HTTPS).
+ Creamos una configuración de Hosts Virtuales en el puerto 80 para los dominios solicitados:
#NameVirtualHost
<VirtualHost 172.31.10.20:80>
ServerName www.estadia.com
DocumentRoot /var/www/html/www.estadia.com
ErrorLog /var/log/httpd/www.estadia.com-error.log
CustomLog /var/log/httpd/www.estadia.com-access.log combined
<Directory /var/www/html/www.estadia.com.pe>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
<VirtualHost 172.31.10.30:80>
ServerName www.comunicaciones.net
DocumentRoot /var/www/html/www.comunicaciones.net
ErrorLog /var/log/httpd/www.comunicaciones.net-error.log
CustomLog /var/log/httpd/www.comunicaciones.net-access.log combined
<Directory /var/www/html/www.comunicaciones.net>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
+ Creamos las configuraciones de Hosts Virtuales de conexiones seguras similares a los ya configurados, definiendo
archivos de certificados y llaves privadas que se asumen ya existen:
<VirtualHost 172.31.10.20:443>
SSLEngine On
SSLCertificateFile /etc/httpd/estadia.com-cert.pem
SSLCertificateKeyFile /etc/httpd/estadia.com-key.pem
<Directory /var/www/html/www.estadia.com.pe>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
<VirtualHost 172.31.10.30:443>
ServerName www.comunicaciones.net
DocumentRoot /var/www/html/www.comunicaciones.net
ErrorLog /var/log/httpd/www.comunicaciones.net-error.log
CustomLog /var/log/httpd/www.comunicaciones.net-access.log combined
SSLEngine On
SSLCertificateFile /etc/httpd/comunicaciones.net-cert.pem
SSLCertificateKeyFile /etc/httpd/comunicaciones.net-key.pem
OpenSourceCollege
Linux for SysAdmins
Página 279
Source Linux
<Directory /var/www/html/www.comunicaciones.net>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
+ Haciendo uso del módulo de Apache mod_rewrite crearemos la regla de redirección en el Host Virtual de conexión
insegura (HTTP) a la URL /webmail/login.php como sigue:
<VirtualHost 172.31.10.20:80>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} \/webmail\/login\.php
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
...
...
...
</VirtualHost>
+ Verificamos la sintaxis de la configuración de Apache y reiniciamos el servicio:
# httpd -t
+ Para realizar las pruebas podríamos crear la ruta de la URL a redireccionar, con un archivo PHP sencillo como debajo se
muestra:
# mkdir -p /var/www/html/www.estadia.com/webmail/login.php
Contenido del archivo /var/www/html/www.estadia.com/webmail/login.php:
<?php
phpinfo();
?>
Ahora bastaría con ingresar a la URL http://www.estadia.com/webmail/login.php y comprobar que se redireccione a la misma
URL bajo una conexión segura HTTPS.
OpenSourceCollege
Linux for SysAdmins
Página 280
Source Linux
Unidad 14: Firewall seguro
14.1. Objetivos
✔ Adquirir los conceptos básicos relacionados a un firewall, netfilter, iptables y Shorewall como frontend.
✔ Realizar una configuración de firewall básico con Shorewall, para filtrar paquetes y realizar operaciones de NAT.
✔ Controlar el tráfico de usuarios con políticas de QoS.
✔ Implementar Shorewall para trabajar con dos o más Proveedores de Internet.
14.2. Certificados digitales

Introducción
Un firewall es un dispositivo que filtra el tráfico entre redes, como mínimo dos. El firewall puede ser un dispositivo físico (por ejemplo un
appliance) o un software sobre un sistema operativo. En general debemos verlo como una caja con dos o más interfaces de red en la
que se establecen una reglas de filtrado con las que se decide si una conexión determinada puede establecerse o no. Incluso puede ir
más allá y realizar modificaciones sobre las comunicaciones, como el NAT.
Esquemas comunes de firewalls

Para que un firewall entre redes funcione como tal debe tener al menos dos tarjetas de red. Esta sería la tipología clásica de un
firewall:
Esquema típico de firewall para proteger una red local conectada a Internet a través de un router. El firewall debe colocarse entre el
router (con un único cable) y la red local (conectado al switch o al hub de la LAN).
Dependiendo de las necesidades de cada red, puede ponerse uno o más firewalls para establecer distintos perímetros de
seguridad en torno a un sistema. Es frecuente también que se necesite exponer algún servidor a Internet (como es el caso de un
servidor web, un servidor de correo, etc..), y en esos casos obviamente en principio se debe aceptar cualquier conexión a ellos. Lo
que se recomienda en esa situación es situar ese servidor en lugar aparte de la red, el que denominamos DMZ o zona
desmilitarizada. El firewall tiene entonces tres entradas:
OpenSourceCollege
Linux for SysAdmins
Página 281
Source Linux
OpenSourceCollege
Linux for SysAdmins
Página 282
Source Linux
En la zona desmilitarizada se pueden poner tantos servidores como se necesiten. Con esta arquitectura, permitimos que el servidor
sea accesible desde Internet de tal forma que si es atacado y se gana acceso a él, la red local sigue protegida por el firewall. Esta
estructura de DMZ puede hacerse también con un doble firewall (aunque como se ve se puede usar un único dispositivo con al
menos tres interfaces de red). Sería un esquema como este:
Los firewalls se pueden usar en cualquier red. Es habitual tenerlos como protección de Internet en las empresas, aunque ahí
también suelen tener una doble función: controlar los accesos externos hacia dentro y también los internos hacia el exterior; esto
último se hace con el firewall o frecuentemente con un proxy (que también utilizan reglas, aunque de más alto nivel).
También, en empresas de hosting con muchos servidores alojados lo normal es encontrarnos uno o más firewalls ya sea filtrando
toda la instalación o parte de ella:
OpenSourceCollege www.opensourcecollege.com Linux for SysAdmins

Primer centro de capacitación Open Página 283
Source Linux
Políticas y reglas de filtrado
Sea el tipo de firewall que sea, generalmente no tendrá mas que un conjunto de reglas en las que se examina el origen y destino
de los paquetes del protocolo TCP/IP. En cuanto a protocolos es probable que sean capaces de filtrar muchos tipos de ellos, no
solo los TCP, también los UDP, los ICMP, los GRE y otros protocolos vinculados a VPNs.
Este podría ser (en pseudo-lenguaje) un el conjunto de reglas de un firewall del primer gráfico:
Politica por defecto ACEPTAR

Todo lo que venga de la red local al firewall ACEPTAR
Todo lo que venga de la ip de mi casa al puerto tcp 22 ACEPTAR
Todo lo que venga de la ip de casa del jefe al puerto tcp 1723 ACEPTAR
Todo lo que venga de hora.rediris.es al puerto udo 123 ACEPTAR
Todo lo que venga de la red local y vaya al exterior ENMASCARAR
Todo lo que venga del exterior al puerto tcp 1 al 1024 DENEGAR
Todo lo que venga del exterior al puerto tcp 3389 DENEGAR
Todo lo que venga del exterior al puerto udp 1 al 1024 DENEGAR
En definitiva lo que se hace es:
i. Habilita el acceso a puertos de administración a determinadas IPs privilegiadas.

ii. Enmascara el tráfico de la red local hacia el exterior (NAT, una petición de un PC de la LAN sale al exterior con la IP
pública), para poder salir a Internet.
iii. Deniega el acceso desde el exterior a puertos de administración y a todo lo que este entre 1 y 1024.
Hay dos maneras de implementar un firewall:
(1) Política por defecto ACEPTAR: en principio todo lo que entra y sale por el firewall se acepta y sólo se denegará lo que se
diga explícitamente.
(2) Política por defecto DENEGAR: todo está denegado, y sólo se permitirá pasar por el firewall a aquellos que se permita
explícitamente.
Como es obvio imaginar, la primera política facilita mucho la gestión del firewall, ya que simplemente nos tenemos que preocupar
de proteger aquellos puertos o direcciones que sabemos que nos interesa; el resto no importa tanto y se deja pasar. Por ejemplo, si
queremos proteger una máquina linux, podemos hacer un netstat -ln y saber que puertos están abiertos, poner reglas para proteger
esos puertos y ya está. ¿Para qué vamos a proteger un puerto que realmente nunca se va a abrir?
El único problema que podemos tener es que no controlemos que es lo que está abierto, o que en un momento dado se instale un
software nuevo que abra un puerto determinado, o que no sepamos que determinados paquetes ICMP son peligrosos. Si la política
por defecto es ACEPTAR y no se protege explícitamente, nos la estamos jugando un poco.
En cambio, si la política por defecto es DENEGAR, a no ser que lo permitamos explícitamente, el firewall se convierte en un
auténtico MURO infranqueable. El problema es que es mucho más difícil preparar un firewall así, y hay que tener muy claro cómo
funciona el sistema (sea iptables o el que sea) y que es lo que se tiene que abrir sin caer en la tentación de empezar a meter reglas
súper permisivas.
Esta configuración de firewall es la recomendada, aunque no es aconsejable usarla si no se domina mínimamente el sistema. Uno
de los objetos principales de este documento es mostrar la forma de crear este tipo de firewalls.
Importante:
• El orden en el que se ponen las reglas de firewall es determinante. Normalmente cuando hay que decidir que se hace
con un paquete se va comparando con cada regla del firewall hasta que se encuentra una que le afecta (match), y se
hace lo que dicte esta regla (aceptar o denegar); después de eso NO SE MIRARÁN MÁS REGLAS para ese paquete.
¿Cuál es el peligro? Si ponemos reglas muy permisivas entre las primeras del firewall, puede que las siguientes no se
apliquen y no sirvan de nada.
Netfilter e iptables
Netfilter es un framework disponible en el núcleo Linux que permite interceptar y manipular paquetes de red. Dicho framework permite
realizar el manejo de paquetes en diferentes estados del procesamiento. Netfilter es también el nombre que recibe el proyecto que se
encarga de ofrecer herramientas libres para cortafuegos basados en Linux.
El componente más popular construido sobre Netfilter es iptables, una herramientas de cortafuegos que permite no solamente filtrar
paquetes, sino también realizar traducción de direcciones de red (NAT) para IPv4 o mantener registros de log. El proyecto ofrecía
OpenSourceCollege
Linux for SysAdmins
Página 284
Source Linux
compatibilidad hacia atrás con ipchains hasta hace relativamente poco, aunque hoy día dicho soporte ya ha sido retirado al
considerarse una herramienta obsoleta. El proyecto Netfilter no sólo ofrece componentes disponibles como módulos del núcleo sino
que también ofrece herramientas de espacio de usuario y librerias.
iptables es el nombre de la herramienta de espacio de usuario mediante la cual el administrador puede definir políticas de filtrado
del tráfico que circula por la red. El nombre iptables se utiliza frecuentemente de forma errónea para referirse a toda la infraestructura
ofrecida por el proyecto Netfilter. Sin embargo, el proyecto ofrece otros subsistemas independientes de iptables tales como el
connection tracking system o sistema de seguimiento de conexiones, o queue, que permite encolar paquetes para que sean tratados
desde espacio de usuario. iptables es un software disponible en prácticamente todas las distribuciones de Linux actuales.
Modo de operación
iptables permite al administrador del sistema definir reglas acerca de qué hacer con los paquetes de red. Las reglas se agrupan
en cadenas: cada cadena es una lista ordenada de reglas. Las cadenas se agrupan en tablas: cada tabla está asociada con un tipo
diferente de procesamiento de paquetes.
Cada regla especifica qué paquetes la cumplen (match) y un destino que indica qué hacer con el paquete si éste cumple la regla.
Cada paquete de red que llega a una computadora o que se envía desde una computadora recorre por lo menos una cadena y
cada regla de esa cadena se comprueba con el paquete. Si la regla cumple con el datagrama, el recorrido se detiene y el destino
de la regla dicta lo que se debe hacer con el paquete. Si el paquete alcanza el fin de una cadena predefinida sin haberse
correspondido con ninguna regla de la cadena, la política de destino de la cadena dicta qué hacer con el paquete. Si el paquete
alcanza el fin de una cadena definida por el usuario sin haber cumplido ninguna regla de la cadena o si la cadena definida por el
usuario está vacía, el recorrido continúa en la cadena que hizo la llamada (lo que se denomina implicit target RETURN o RETORNO
de destino implícito). Solo las cadenas predefinidas tienen políticas.
En iptables, las reglas se agrupan en cadenas. Una cadena es un conjunto de reglas para paquetes IP, que determinan lo que se
debe hacer con ellos. Cada regla puede desechar el paquete de la cadena (cortocircuito), con lo cual otras cadenas no serán
consideradas. Una cadena puede contener un enlace a otra cadena: si el paquete pasa a través de esa cadena entera o si cumple
una regla de destino de retorno, va a continuar en la primera cadena. No hay un limite respecto de cuán anidadas pueden estar las
cadenas. Hay tres cadenas básicas (INPUT, OUTPUT y FORWARD: ENTRADA, SALIDA y REENVÍO) y el usuario puede crear tantas
como desee. Una regla puede ser simplemente un puntero a una cadena.
Las tablas
Hay tres tablas ya incorporadas, cada una de las cuales contiene ciertas cadenas predefinidas. Es posible crear nuevas tablas
mediante módulos de extensión. El administrador puede crear y eliminar cadenas definidas por usuarios dentro de cualquier
tabla. Inicialmente, todas las cadenas están vacías y tienen una política de destino que permite que todos los paquetes pasen
sin ser bloqueados o alterados.
A) filter table (Tabla de filtros) — Esta tabla es la responsable del filtrado (es decir, de bloquear o permitir que un paquete
continúe su camino). Todos los paquetes pasan a través de la tabla de filtros. Contiene las siguientes cadenas predefinidas y
cualquier paquete pasará por una de ellas:
• INPUT chain (Cadena de ENTRADA) — Todos los paquetes destinados a este sistema atraviesan esta cadena (y por
esto se la llama algunas veces LOCAL_INPUT o ENTRADA_LOCAL)
• OUTPUT chain (Cadena de SALIDA) — Todos los paquetes creados por este sistema atraviesan esta cadena (a la
que también se la conoce como LOCAL_OUTPUT o SALIDA_LOCAL)
• FORWARD chain (Cadena de REDIRECCIÓN) — Todos los paquetes que meramente pasan por este sistema (para
ser ruteados) recorren esta cadena
B) nat table (Tabla de traducción de direcciones de red) — Esta tabla es la responsable de configurar las reglas de reescritura
de direcciones o de puertos de los paquetes. El primer paquete en cualquier conexión pasa a través de esta tabla; los
veredictos determinan como van a reescribirse todos los paquetes de esa conexión. Contiene las siguientes cadenas
redefinidas:
• PREROUTING chain (Cadena de PRERUTEO) — Los paquetes entrantes pasan a través de esta cadena antes de
que se consulte la tabla de ruteo local, principalmente para DNAT (destination-NAT o traducción de direcciones de
red de destino)
• POSTROUTING chain (Cadena de POSRUTEO) — Los paquetes salientes pasan por esta cadena después de
haberse tomado la decisión del ruteo, principalmente para SNAT (source-NAT o traducción de direcciones de red de
origen)
• OUTPUT chain (Cadena de SALIDA) — Permite hacer un DNAT limitado en paquetes generados localmente
C) mangle table (Tabla de destrozo) — Esta tabla es la responsable de ajustar las opciones de los paquetes, como por ejemplo
OpenSourceCollege
Linux for SysAdmins
Página 285
Source Linux
la calidad de servicio. Todos los paquetes pasan por esta tabla. Debido a que está diseñada para efectos avanzados, contiene
todas las cadenas predefinidas posibles:
• PREROUTING chain (Cadena de PRERUTEO) — Todos los paquetes que logran entrar a este sistema, antes de que
el ruteo decida si el paquete debe ser reenviado (cadena de REENVÍO) o si tiene destino local (cadena de
ENTRADA)
• INPUT chain (Cadena de ENTRADA) — Todos los paquetes destinados para este sistema pasan a través de esta
cadena
• FORWARD chain (Cadena de REDIRECCIÓN) — Todos los paquetes que meramente pasan por este sistema pasan a
través de esta cadena
• OUTPUT chain (Cadena de SALIDA) — Todos los paquetes creados en este sistema pasan a través de esta cadena
• POSTROUTING chain (Cadena de POSTRUTEO) — Todos los paquetes que abandonan este sistema pasan a través
de esta cadena
Además de las cadenas ya incorporadas, el usuario puede crear todas las cadenas definidas por el usuario que quiera dentro de
cada tabla, las cuales permiten agrupar las reglas en forma lógica.
Cada cadena contiene una lista de reglas. Cuando un paquete se envía a una cadena, se lo compara, en orden, contra cada regla
en la cadena. La regla especifica qué propiedades debe tener el paquete para que la regla lo matchee, como número de puerto o
dirección IP. Si la regla no coincidea, el procesamiento continúa con la regla siguiente. Si la regla, por el contrario, matchea el
paquete, las instrucciones de destino de las reglas se siguen (y cualquier otro procesamiento de la cadena normalmente se aborta).
Algunas propiedades de los paquetes solo pueden examinarse en ciertas cadenas (por ejemplo, la interfaz de red de salida no es
válida en la cadena de ENTRADA). Algunos destinos solo pueden usarse en ciertas cadenas y/o en ciertas tablas (por ejemplo, el
destino SNAT solo puede usarse en la cadena de POSRUTEO de la tabla de traducción de direcciones de red).
La siguiente figura ilustra el modo de operación de las tablas:
Los destinos
El destino de una regla puede ser el nombre de una cadena definida por el usuario o uno de los destinos ya incorporados ACCEPT,
OpenSourceCollege
Linux for SysAdmins
Página 286
Source Linux
DROP, QUEUE, o RETURN (aceptar, descartar, encolar o retornar, respectivamente). Cuando un destino es el nombre de una
cadena definida por el usuario, al paquete se lo dirige a esa cadena para que sea procesado (tal como ocurre con una llamada a
una subrutina en un lenguaje de programación). Si el paquete consigue atravesar la cadena definida por el usuario sin que ninguna
de las reglas de esa cadena actúe sobre él, el procesamiento del paquete continúa donde había quedado en la cadena actual.
Estos llamados entre cadenas se pueden anidar hasta cualquier nivel deseado.
Existen los siguientes destinos ya incorporados:
ACCEPT (aceptar)
Este destino hace que netfilter acepte el paquete. El significado de esto depende de cuál sea la cadena realizando esta
aceptación. De hecho, a un paquete que se lo acepta en la cadena de ENTRADA se le permite ser recibido por la terminal
(host), a un paquete que se lo acepta en la cadena de SALIDA se le permite abandonar la terminal y a un paquete que se lo
acepta en la cadena de REDIRECCIÓN se le permite ser ruteado a través de la terminal.
DROP (descartar)
Este destino hace que netfilter descarte el paquete sin ningún otro tipo de procesamiento. El paquete simplemente desaparece
sin indicación de que fue descartado al ser entregado a la terminal de envio o a una aplicación. Esto se le refleja al que envía, a
menudo, como un communication timeout (alcance del máximo tiempo de espera en la comunicación), lo que puede causar
confusión (aunque el descarte de paquetes entrantes no deseados se considera a veces una buena política de seguridad, pues
no da ni siquiera el indicio a un posible atacante de que la terminal existe).
QUEUE (encolar)
Este destino hace que el paquete sea enviado a una cola en el espacio de usuario. Una aplicación puede usar la biblioteca
libipq, también parte del proyecto netfilter/iptables, para alterar el paquete. Si no hay ninguna aplicación que lea la cola, este
destino es equivalente a DROP.
RETURN (retorno)
Hace que el paquete en cuestión deje de circular por la cadena en cuya regla se ejecutó el destino RETURN. Si dicha cadena
es una subcadena de otra, el paquete continuará por la cadena superior como si nada hubiera pasado. Si por el contrario la
cadena es una cadena principal (por ejemplo la cadena INPUT), al paquete se le aplicará la política por defecto de la cadena
en cuestión (ACCEPT, DROP o similar).
Hay muchos destinos de extensión disponibles. Algunos de los más comunes son:
REJECT (rechazo)
Este destino tiene el mismo efecto que 'DROP', salvo que envía un paquete de error a quien envió originalmente. Se usa
principalmente en las cadenas de ENTRADA y de REDIRECCIÓN de la tabla de filtrado. El tipo de paquete se puede controlar
a través del parámetro '--reject-with'. Un paquete de rechazo puede indicar explícitamente que la conexión ha sido filtrada (un
paquete ICMP filtrado administrativamente por conexión), aunque la mayoría de los usuarios prefieren que el paquete indique
simplemente que la computadora no acepta ese tipo de conexión (tal paquete será un paquete tcp-reset para conexiones TCP
denegadas, un icmp-port-unreachable para sesiones UDP denegadas o un icmp-protocol-unreachable para paquetes no TCP y
no UDP). Si el parámetro '--reject-with' no se especifica, el paquete de rechazo por defecto es siempre icmp-port-unreachable.
LOG (bitácora)
Este destino lleva un log o bitácora del paquete. Puede usarse en cualquier cadena en cualquier tabla, y muchas veces se usa
para debuggear (análisis de fallos, como ser la verificación de qué paquetes están siendo descartados).
ULOG
Este destino lleva un log o bitácora del paquete, pero no de la misma manera que el destino LOG. El destino LOG le envía
información al log del núcleo, pero ULOG hace multidifusión de los paquetes que matchean esta regla a través de un socket
netlink, de manera que programas del espacio de usuario puedan recibir este paquete conectándose al socket.
DNAT
Este destino hace que la dirección (y opcionalmente el puerto) de destino del paquete sean reescritos para traducción de
dirección de red. Mediante la opción '--to-destination' debe indicarse el destino a usar. Esto es válido solamente en las cadenas
de SALIDA y PRERUTEO dentro de la tabla de nat. Esta decisión se recuerda para todos los paquetes futuros que pertenecen
a la misma conexión y las respuestas tendrán su dirección y puerto de origen cambiados al original (es decir, la inversa de este
paquete).
SNAT
Este destino hace que la dirección (y opcionalmente el puerto) de origen del paquete sean reescritos para traducción de
dirección de red. Mediante la opción '--to-source' debe indicarse el origen a usar. Esto es válido solamente en la cadena de
POSRUTEO dentro de la tabla de nat y, como DNAT, se recuerda para todos los paquetes que pertenecen a la misma
conexión.
MASQUERADE
Esta es una forma especial, restringida de SNAT para direcciones IP dinámicas, como las que proveen la mayoría de los
proveedores de servicios de Internet (ISPs) para modems o línea de abonado digital (DSL). En vez de cambiar la regla de
SNAT cada vez que la dirección IP cambia, se calcula la dirección IP de origen a la cual hacer NAT fijándose en la dirección IP
de la interfaz de salida cuando un paquete matchea esta regla. Adicionalmente, recuerda cuales conexiones usan
MASQUERADE y si la dirección de la interfaz cambia (por ejemplo, por reconectarse al ISP), todas las conexiones que hacen
NAT a la dirección vieja se olvidan.
OpenSourceCollege
Linux for SysAdmins
Página 287
Source Linux
Shorewall
Shoreline Firewall, Shorewall, es un Firewall Open Source para Linux construido sobre las bases de Netfilter e iptables, trabajando
en un nivel superior que abstrae la complejidad que puede implicar la sintaxis de iptables así como también el uso de otras
herramientas de red tales como iproute o tc.
La razón principal para el estudio de Shorewall en lugar de iptables puro, es la limpieza, orden y sencillez que caracterizan al primero
para configurar reglas de Firewall y otras tareas asociadas utilizando una interfaz de fácil comprensión a través de archivos de texto
plano.
Instalación de Shorewall
Shorewall puede ser descargado directamente desde su Website http://www.shorewall.net en formatos RPM para distribuciones como
Red Hat y derivados.
En cambio Debian ya incluye los paquetes de shorewall en su distribución pudiendo ser descargada desde los repositorios. Sin
embargo a la fecha que se escribe este documento, la versión estable Debian Lenny incluye la versión 4.0.x de Shorewall. La versión
reciente de Shorewall, la 4.4.5 puede ser encontrada en la distribución testing de Debian.
El material impartido sobre la configuración de Shorewall no representa mayores diferencias entre la 4.0.x y la 4.4.5, por lo que
simplemente asumiremos que se trabaja con cualquiera de esas dos ramas de versiones o superiores.
En Red Hat / CentOS y derivados la instalación sería como sigue:
# rpm -ivh shorewall-4.4.5-1.noarch.rpm
# apt-get install shorewall-perl shorewall-doc
Estructura de la configuración de Shorewall

Shorewall es un software que se encarga de crear reglas de filtrado y NAT basadas en iptables así como también otras operaciones
de gestión de redes como enrutamiento, QoS u otras, todas a través de distintos archivos de configuración para cada propósito.
Es así que Shorewall una vez que crea las reglas, éstas se aplican y se tiene ya listo un sistema Linux funcionando como Firewall, por
lo que debe entenderse que Shorewall no es un servicio o demonio que se debe mantener en ejecución.
La configuración de Shorewall se basa en archivos individuales ubicados en /etc/shorewall de donde algunos de los que necesitaremos
generalmente son:
Archivo Descripción
/etc/shorewall/shorewall.conf Archivo de configuración global de Shorewall.
/etc/shorewall/zones Archivo de declaración de zonas.
/etc/shorewall/interfaces Archivo de declaración de interfaces de red asociadas a zonas.
/etc/shorewall/hosts Archivo de declaración de subredes y direcciones IP asociadas a zonas.
/etc/shorewall/policy Archivo de políticas por defecto.
/etc/shorewall/masq Archivo de reglas de enmascaramiento y SNAT.
/etc/shorewall/rules Archivo de reglas de filtrado y NAT.
/etc/shorewall/nat Archivo de reglas de NAT 1 a 1.
/etc/shorewall/providers Archivo de definición de Proveedores de Internet.
/etc/shorewall/tcclasses Archivo de clases HTB para QoS.
/etc/shorewall/tcdevices Archivo de declaración de interfaces de red para aplicar QoS.
/etc/shorewall/tcrules Archivo de reglas de marcado de paquetes.
Estos no son todos los archivos de configuración disponibles de Shorewall sino sólo los más comunes en los escenarios de
configuración que se han estudiar en este documento.
Debido a que son múltiples los archivos de configuración existentes, cada uno de ellos pudiendo ser conjugado con otros para
escenarios distintos, vamos a proceder con el estudio de configuraciones para casos genéricos que fácilmente podrían adaptarse para
otros entornos según el usuario lo necesite.
Configuración de un Firewall para una red LAN y DMZ

La configuración a estudiar corresponde a un modelo básico de Firewall que pretende proteger a una red LAN y una DMZ (Zona
Desmilitarizada) de la red WAN, controlando el tráfico de salida de los usuarios en la red privada y publicando algunos servicios
alojados en la DMZ.
OpenSourceCollege
Linux for SysAdmins
Página 288
Source Linux
El diagrama debajo mostrado corresponde al modelo de la configuración a seguir a continuación:
Para este escenario asumiremos lo siguiente:
• El firewall cuenta con tres interfaces de red, eth0, eth1 y eth2.

• La interfaz eth0 está conectada al router que da salida a Internet, con las direcciones IP 190.41.62.2/255.255.255.248,
190.41.62.3/255.255.255.248 y 190.41.62.3/255.255.255.248.
• La interfaz eth1 está conectada a un equipo o un switch correspondiente a la DMZ, con una IP 10.20.3.1/255.255.255.0
• La interfaz eth2 está conectada al switch que alimenta a la red privada LAN, con una IP 192.168.0.1/255.255.255.0
• Los clientes de la LAN apuntan a 192.168.0.1 como su puerta de enlace por defecto y servidor DNS primario.
Paso 1: Configuración de zonas

Este primer paso es esencial para indicar a Shorewall cuáles son las zonas que va a proteger, las mismas que se deben definir en
el archivo /etc/shorewall/zones con un contenido como el siguiente:
#ZONE TYPE
fw firewall
LAN ipv4
WAN ipv4
DMZ ipv4
Sobre este archivo es importante comprender que:
1. Por lo general siempre en las primeras líneas del archivo se encuentran comentarios que indican el orden de las
columnas.
2. El archivo sólo define qué zonas existen, mas no las asocia con ninguna interfaz de red aún.
3. Existe una zona implícita de nombre fw (o $FW como nombre alterno) y tipo firewall que hace referencia al mismo
host Linux que se comporta como Firewall.
4. Cualquiera de las otras zonas de red se define con un nombre en la primera columna (LAN, WAN o DMZ) y el tipo ipv4.
5. Por defecto los nombres de zonas no deberían ser mayores a 5 caracteres de longitud, pudiendo ser en mayúsculas o
minúsculas. Las palabras all, none, SOURCE y DEST están reservados por Shorewall y no deberían ser usados como
nombres de zonas.
Importante:
• La documentación completa de este archivo de configuración se puede encontrar en shorewall-zones(5)
Paso 2: Configuración de interfaces

Una vez declaradas las zonas es necesario asociarlas a las distintas interfaces de red con las que cuenta el host Firewall. Esto lo
hacemos editando el archivo /etc/shorewall/interfaces con un contenido como el siguiente:
#ZONE INTERFACE BROADCAST OPTIONS

WAN eth0 detect tcpflags,nosmurfs,routefilter
DMZ eth1 detect tcpflags,nosmurfs,routefilter
LAN eth2 detect tcpflags,nosmurfs,routefilter
OpenSourceCollege
Linux for SysAdmins
Página 289
Source Linux
columnas.
2. El archivo asocia las interfaces de red con zonas ya declaradas anteriormente.
3. La primera columna especifica el nombre de una zona (Ejm: WAN, LAN).
4. La segunda columna especifica el nombre de una interfaz de red (Ejm: eth0, eth1) existente en el sistema. No se admiten
alias de interfaces tales como eth0:0, eth2:1, etc.
5. La tercera columna permite especificar la dirección de broadcast asociada a la interfaz de red. Si la interfaz posee
múltiples direcciones IP, entonces se puede especificar en esta columna cada una de las direcciones de broadcast
separadas por coma.
Si se especifica la palabra especial detect entonces Shorewall automáticamente detectará la dirección o direcciones de
broadcast para la interfaz.
6. La cuarta columna permite especificar distintas opciones a través de palabras clave que las identifican. Algunas de estas
opciones son las siguientes:
• nosmurfs : Rechaza paquetes smurfs, dirigidos a una dirección de broadcast para producir flooding.
• routeback : Permite que el tráfico entrante por una interfaz pueda salir de vuelta por la misma.
• routefilter : Activa el Reverse Path Filtering en la interfaz, como medida anti-spoofing.
• tcpflags : Rechaza paquetes con una combinación ilegal de flags TCP.
• logmartians : Guarda un log de paquetes marcianos, aquellos imposibles de provenir de la interfaz de red.
Importante:
• La documentación completa de este archivo de configuración se puede encontrar en shorewall-interfaces(5)
Paso 3: Configuración de políticas por defecto

En el archivo /etc/shorewall/policy se debe definir las políticas por defecto para la comunicación entre las zonas existentes en
Shorewall. Para ello se debe crear un contenido similar al siguiente:
#SOURCE DEST POLICY LOG

# LEVEL
fw all ACCEPT
all all DROP info
columnas.
2. El archivo define la acción a tomar sobre una zona cuando ninguna regla del archivo /etc/shorewall/rules coincida.
3. La primera columna especifica el nombre de una zona origen (Ejm: all, fw, LAN, DMZ)
4. La segunda columna especifica el nombre de una zona destino (Ejm: all, WAN, LAN).
5. La tercera columna define la acción a tomar como política sobre esta zona. Puede definirsen acciones como ACCEPT,
DROP o REJECT.
6. La cuarta columna define el nivel de registro que se aplicará para el registro de la acción tomada de la política cuando se
envía al demonio syslog como log.
Importante:
• La documentación completa de este archivo de configuración se puede encontrar en shorewall-policy(5)
Paso 4: Configuración de reglas de filtrado y NAT

En el archivo /etc/shorewall/rules se debe definir las reglas de filtrado desde/hacia las diferentes zonas declaradas anteriormente. Es
OpenSourceCollege
Linux for SysAdmins
Página 290
Source Linux
así que en este archivo se pueden controlar las conexiones permitidas desde Internet hacia nuestro host, las conexiones de la LAN
hacia Internet permitidas, la publicación de servicios en una DMZ a través de una operación DNAT (Destination NAT), o
redireccionar el tráfico saliente al puerto 80 hacia nuestro puerto local de un servidor proxy (transparente), entre otros.
El contenido de este archivo puede ser similar al debajo mostrado:
SECTION NEW
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE

# PORT PORT(S) DEST LIMIT
# Accesos desde Internet hacia el Firewall
ACCEPT WAN $FW icmp
ACCEPT WAN $FW:190.41.62.2 tcp 22 - - 3/min:5
ACCEPT WAN $FW:190.41.62.3 tcp 25 - - 8/sec:10
ACCEPT WAN $FW udp 1194
# Accesos de la LAN hacia el Firewall

ACCEPT LAN $FW icmp
ACCEPT LAN $FW tcp 22,25,53,3128
ACCEPT LAN $FW udp 53,123
# Accesos de la LAN hacia Internet

ACCEPT LAN WAN icmp
ACCEPT LAN WAN tcp 53
ACCEPT LAN WAN udp 53,123
ACCEPT LAN:192.168.0.31 WAN all
ACCEPT LAN:192.168.0.42 WAN all
ACCEPT LAN:~08-00-27-50-EC-9FWAN all
# Guardar un log de todas las conexiones SMTP salientes de un host
LOG:info LAN:192.168.0.30 WAN tcp 25
# Accesos de la DMZ hacia Internet

ACCEPT DMZ WAN icmp
ACCEPT DMZ WAN tcp 25,53,80
ACCEPT DMZ WAN udp 53,123
# Accesos de la LAN hacia la DMZ

ACCEPT LAN DMZ:10.20.3.4 tcp 25,80,443
ACCEPT LAN DMZ:10.20.3.5 tcp 21,80,1433,3389
# Publicación de servicios a Internet

# Publicación de los servicios HTTP y HTTPS (Webmail) de un servidor de correo
DNAT WAN DMZ:10.20.3.4 tcp 80,443 - 190.41.62.2 15/sec:18
# Publicación de los servicios FTP y HTTP de un servidor de aplicaciones
DNAT WAN DMZ:10.20.3.5 tcp 21,80 - 190.41.62.4 9/sec:12
# Redireccionar conexiones HTTP a un proxy local (proxy transparente)

# No aplicar la redirección a estos clientes
NONAT LAN:192.168.0.31
NONAT LAN:192.168.0.42
REDIRECT LAN 3128 tcp 80 - !192.168.0.1
columnas.
2. El archivo define las reglas de filtrado y NAT que se aplican a la comunicación entre las distintas zonas declaradas.
3. El orden de las reglas en este archivo tiene importancia, ya que la primera línea coincidente define la acción a aplicar
OpenSourceCollege
Linux for SysAdmins
Página 291
Source Linux
sobre una conexión.
4. Las reglas pueden ser definidas dentro del ámbito de conexiones con estado NEW, STABLISHED o RELATED de acuerdo
a la directiva SECTION como figura en la primera línea del archivo.
5. La primera columna especifica una acción a tomar tal como ACCEPT, DROP, REJECT, NONAT, DNAT, REDIRECT, LOG
acorde a:
• ACCEPT : Acepta la conexión.

• DROP : Ignora la conexión.
• REJECT : Rechaza la conexión enviando un paquete RST o icmp-unreachable.
• NONAT : Excluye la conexión de cualquier regla DNAT o REDIRECT subsiguiente.
• DNAT : Reenvía la conexión a otro host y alternativa a otro puerto.
• REDIRECT : Redirecciona la conexión hacia un servicio corriendo en el mismo Firewall.
• LOG : Guarda un log de la conexión en un nivel o prioridad de syslog específico.
6. La segunda columna define los hosts origen de la conexión hacia la cual se aplica la regla. Se puede especificar aquí una
zona previamente declarada, y seguida de dos puntos (:) una o más direcciones o rangos de direcciones.
7. La tercera columna define los hosts destino (servidores) de la conexión hacia la cual se aplica la regla. Se puede
especificar aquí una zona previamente declarada, y seguida de dos puntos (:) una o más direcciones o rangos de
direcciones.
8. La cuarta columna define el protocolo de la conexión. Puede ser: tcp, udp, icmp u otro definido en /etc/protocols
9. La quinta columna define el(los) puerto(s) o rango de puertos destino de la conexión cuando ésta es de tipo tcp o udp.
10. La sexta columna define el(los) puerto(s) o rango de puertos origen de la conexión cuando ésta es de tipo tcp o udp.
11. La séptima columna, válida sólo para las acciones DNAT y REDIRECT, permite definir la dirección IP original a la cual
estaba destinada la conexión antes de ser manipulada con DNAT o REDIRECT.
12. La octava columna permite definir un límite de las conexiones en intervalos de tiempo. Se especifica como
N/intervalo[:ráfaga] donde N es la cantidad de conexiones, intervalo es una expresión de tiempo como sec
(segundo), min (minuto), hour (hora) o day (día); mientras que ráfaga es la cantidad máxima de conexiones permitidas
antes que se alcance el intervalo de tiempo.
Importante:
• La documentación completa de este archivo de configuración se puede encontrar en shorewall-rules(5)
Paso 5: Configuración de reglas de enmascaramiento

En el archivo /etc/shorewall/masq se debe definir las reglas de enmascaramiento y SNAT a aplicarse a los clientes que pretenden
conectarse de una red hacia otra.
El contenido de este archivo debe ser similar al debajo mostrado:
#INTERFACE SOURCE ADDRESS PROTO PORT(S)

eth0 190.41.62.2 190.41.62.3 tcp 25
eth0 10.20.3.4 190.41.62.3 tcp 25
eth0 10.20.3.0/24 190.41.62.2
eth0 192.168.0.0/24 190.41.62.2
columnas.
2. El archivo define las reglas de enmascaramiento y SNAT que se aplican sobre los clientes que se comunican entre dos
zonas distintas del Firewall.
3. El orden de las reglas en este archivo tiene importancia, ya que la primera línea coincidente define la acción de
traducción o enmascaramiento a aplicar sobre una conexión.
4. La primera columna define la interfaz de red saliente a través de la cual se espera que salgan los paquetes a
OpenSourceCollege
Linux for SysAdmins
Página 292
Source Linux
enmascararse.
5. La segunda columna define las direcciones IP de los hosts origen que se desea enmascarar.
6. La tercera columna define la dirección IP con la que se enmascara a las conexiones salientes de los clientes. Esta
dirección IP debe estar asignada a la interfaz de red definida en la primera columna.
7. La cuarta columna define el protocolo de la conexión. Esto permite aplicar la regla de enmascaramiento cuando la
conexión coincida con cierto tipo de protocolo.
8. La quinta columna define uno o más puertos destino de la conexión. Al igual que en el protocolo, esto permite aplicar el
enmascaramiento a una conexión específica según el número de puerto(s).
Importante:
• La documentación completa de este archivo de configuración se puede encontrar en shorewall-masq(5)
Paso 6: Ajustes de configuración finales y ejecución de reglas

Tras culminar la edición de los archivos de configuración es necesario verificar que Shorewall esté habilitado para ya ser ejecutado,
confirmando que en el archivo /etc/shorewall/shorewall.conf la directiva debajo mostrada tenga un valor como:
STARTUP_ENABLED=Yes
...
...
IP_FORWARDING=On
...
...
En el caso de Debian y derivados, puede ser también necesario que se habilite el inicio de Shorewall editando el archivo
/etc/default/shorewall como sigue:
startup=1
...
...
Al igual que con la mayoría de servicios estudiados, se requiere revisar la correcta sintaxis de los archivos de configuración para lo
cual ejecutaremos la siguiente orden:
# shorewall check
Lo anterior debería resumir de los chequeos hechos a las configuraciones e informar de cualquier error encontrado. Si no se
genera ninguna advertencia ni error, entonces se puede proceder a manipular el inicio, apagado o reinicio de Shorewall con los
siguientes comandos:
# shorewall start
# shorewall stop
# shorewall restart
Importante:
• La documentación completa del archivo de configuración /etc/shorewall/shorewall.conf se puede encontrar en

shorewall.conf(5)
Configuración de NAT 1 a 1
La siguiente configuración tiene por objetivo crear reglas de NAT 1 a 1, asociando una o más direcciones IP externas de un Firewall a
uno o más hosts del segmento de la LAN. Se puede tomar como referencia la siguiente imagen:
OpenSourceCollege www.opensourcecollege.com
Linux for SysAdmins
Primer centro de capacitación Open
Página 293
Source Linux
Este escenario permite que los hosts del segmento IP 10.1.1.* aparenten pertenecer al segmento 130.252.100.*. Para ello asumiremos
que:
• La interfaz de red eth0 del Firewall es la que posee las direcciones IP externas..
• El host 10.1.1.2 aparentaría tener la IP 130.252.100.18.
• El host 10.1.1.3 aparentaría tener la IP 130.252.100.19.
Paso 1: Configuraciones previas requeridas

Es necesario que el(los) host(s) que se configurarán en NAT 1 a 1 no estén incluidos en ninguna especificación en el archivo
/etc/shorewall/masq o /etc/shorewall/proxyarp.
Paso 2: Configuración de NAT

En el archivo /etc/shorewall/nat se define las reglas de NAT 1 a 1, con un contenido como el siguiente:
#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL

130.252.100.18 eth0 10.1.1.2 yes yes
130.252.100.19 eth0 10.1.1.3 yes yes
columnas.
2. Este archivo define la asociación de direcciones IP externas con direcciones IP internas de una LAN tanto para el tráfico
entrante como saliente.
3. La primera columna define una dirección IP externa asociada a la interfaz de red para configurarla en NAT 1 a 1. Esta
dirección IP no debe ser la primera asignada a la interfaz de red externa.
4. La segunda columna define la interfaz de red que posee las direcciones externas. Si la directiva ADD_IP_ALIASES tiene
el valor de Yes en el archivo /etc/shorewall/shorewall.conf entonces Shorewall asignará automáticamente a esta interfaz de
red la dirección IP externa, permitiendo también especificar luego de la interfaz y separado por dos puntos (:) el nombre
que tendrá el alias de la interfaz de red.
5. La tercera columna define la dirección IP interna a la cual se asociará la dirección externa.
6. La cuarta columna si tiene el valor Yes entonces la regla de NAT 1 a 1 será efectiva desde cualquier host, es decir desde
cualquier interfaz de red. Si tiene el valor No entonces la regla NAT funcionará sólo desde la interfaz de red definida enl a
segunda columna.
7. La quinta columna si tiene el valor Yes entonces la regla de NAT será efectiva desde el mismo host del Firewall, de lo
contrario (valor No) sólo funcionará desde otros hosts distintos al Firewall.
8. Las reglas de NAT 1 a 1 sólo involucran las tareas de traducción mas no la permisividad de las conexiones. Esto quiere
decir que si por ejemplo alguno de estos hosts (10.1.1.3) ofreciese un servicio FTP, sería necesario de todos modos crear
una regla correspondiente en /etc/shorewall/rules como sigue:
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL

# PORT(s) PORT(s) DEST
DNAT WAN LAN:10.1.1.3 tcp 21 - 130.252.100.19
OpenSourceCollege
Linux for SysAdmins
Página 294
Source Linux
Importante:
• La documentación completa de este archivo de configuración se puede encontrar en shorewall-nat(5)
Paso 3: Verificación de sintaxis y refresco de reglas

Ahora se requiere revisar la correcta sintaxis de los archivos de configuración para lo cual ejecutaremos la siguiente orden:
# shorewall check
Si no se encontró ningún error en la configuración procedemos a aplicar los cambios reiniciando Shorewall:
# shorewall restart
Configuración de QoS entre una LAN e Internet

La siguiente configuración tiene por objetivo crear las reglas básicas de Firewall para permitir el acceso de la LAN hacia la WAN, y con
políticas de QoS para controlar el ancho de banda utilizado para tráfico de subida y bajada. Esta sería la figura del escenario:
Para este escenario asumiremos lo siguiente:
• El firewall cuenta con dos interfaces de red, eth0 y eth1.

• La interfaz eth0 está conectada al router que da salida a Internet, con la dirección IP 172.31.0.2.
• La interfaz eth1 está conectada al switch que alimenta a la red privada LAN, con una IP 192.168.0.1/255.255.255.0.
• El router conecta a una línea ADSL de 1 Mbps (1 Mbps de bajada y 200 kbps de subida).
Paso 1: Configuración básica previa

Vamos a realizar una configuración básica de zonas, interfaces, políticas, reglas y enmascaramiento de acuerdo a los siguientes
archivos de configuración:
/etc/shorewall/zones
#ZONE TYPE
fw firewall
WAN ipv4
LAN ipv4
/etc/shorewall/interfaces
WAN eth0 detect tcpflags,routefilter,nosmurfs
LAN eth1 detect tcpflags,routefilter,nosmurfs
/etc/shorewall/policy
#SOURCE DEST POLICY
fw all ACCEPT
all all DROP
/etc/shorewall/rules
ACCEPT WAN $FW icmp
ACCEPT LAN $FW icmp

ACCEPT LAN $FW tcp 22
ACCEPT LAN WAN icmp

OpenSourceCollege
Linux for SysAdmins
Página 295
Source Linux
/etc/shorewall/masq
eth0 192.168.0.0/24
Paso 2: Configuración de las interfaces de red a configurar con QoS

Se requiere declarar las interfaces de red participarán en las reglas de QoS y definir en cada una de ellas las capacidades de
ancho de banda disponibles. Para ello debemos editar el archivo /etc/shorewall/tcdevices como sigue:
#NUMBER: IN-BANDWITH OUT-BANDWIDTH

#INTERFACE
eth0 0mbit 200kbit
eth1 - 100mbit
columnas.
2. Este archivo define las interfaces de red a aplicar QoS y las características de ancho de banda de cada una de ellas.
3. En este archivo las definiciones de ancho de banda se deben expresar acorde a:
• kbps : Kilobytes por segundo.

• mbps : Megabytes por segundo.
• kbit : Kilobits por segundo.
• mbit : Megabits por segundo.
4. La primera columna define la interfaz de red. No se admiten alias de interfaces de red como eth0:0, eth1:2, etc.
5. La segunda columna define el ancho de banda máximo soportado por la interfaz para tráfico entrante. Esto no implica
que se controlará la velocidad del tráfico entrante en esta interfaz (no es posible hacerlo) sino sólo sirve para poder
rechazar paquetes que intenten ingresar a una tasa de transferencia mayor a la soportada por la interfaz.
Si no se desea rechazar ninguna conexión entrante sin importar su velocidad se puede colocar un valor 0 (cero) en esta
columna.
6. La tercera columna define el ancho de banda máximo soportado por la interfaz para tráfico saliente.
Importante:
• Las herramientas de traffic shaping en Linux no permiten por defecto controlar el tráfico entrante a una interfaz sino sólo
el saliente. Esto se debe a que las conexiones entrantes a una interfaz corresponden a tráfico que ya llegó y es muy
tarde ya para ejercer cualquier control de velocidad.
Esto significa que normalmente sólo podríamos controlar la velocidad del tráfico de "subida" mas no la de "bajada".
• Sin embargo para superar la anterior limitación del tráfico entrante, se puede utilizar dos interfaces de red, en la cual eth0
-conectada a Internet- será usada para limitar el tráfico saliente (de subida), y eth1 -conectada a la LAN- será usada para
limitar el tráfico saliente (simulando tráfico de bajada para los usuarios de la LAN). Sin embargo hay que considerar que
el tráfico saliente de eth1 no siempre corresponderá a tráfico reenviado de bajada de los usuarios de la LAN, sino que
también puede corresponder a tráfico generado por el mismo Firewall hacia los hosts de la LAN y en este caso no se
debería limitar la velocidad.
• Acorde a la información dada, el tráfico máximo de subida (200 kbps) se define como OUT-BANDWIDTH en la interfaz
eth0, pero el tráfico máximo de bajada (1 mbps) no se ha definido ni en eth0 ni eth1. Esto se debe a que eth1 debe
trabajar a su máxima velocidad (100 Mbps siendo una interfaz Fast Ethernet) para la comunicación entre el Firewall y la
LAN.
El tráfico saliente de eth1 que corresponda a las descargas de los usuarios se controlará en otro archivo.
• La documentación completa del archivo /etc/shorewall/tcdevices se puede encontrar en shorewall-tcdevices(5)
Paso 3: Configuración de las clases QoS

El control de ancho de banda se hace a través de la clasificación de las conexiones en distintas categorías llamadas clases. Estas
clases permiten definir la prioridad, el ancho de banda mínimo y máximo dentro del cual se organizarán las conexiones de acuerdo
a las reglas que posteriormente nosotros creemos.
Para eso es necesario editar el archivo /etc/shorewall/tcclasses como sigue:
OpenSourceCollege
Linux for SysAdmins
Página 296
Source Linux
#INTERFACE:CLASS MARK RATE: CEIL PRIORITY OPTIONS
# DMAX:UMAX
eth0 1 20*full/100 full 1 tcp-ack,tos-minimize-delay
eth0 2 20*full/100 full 2
eth0 4 10*full/100 full 4 default
eth1 2 40kbit 1mbit 2

eth1 5 99mbit full 5
eth1 6 160kbit 1mbit 6 default
columnas.
2. Este archivo define las clases de control de ancho de banda, con sus prioridades, tasas de transferencia mínimas y
máximas así como otros atributos.
3. Se han de seguir las mismas convenciones que en el archivo /etc/shorewall/tcdevices sobre kbps, mbps, kbit y mbit.
4. La primera columna define la interfaz de red. No se admiten alias de interfaces de red como eth0:0, eth1:2, etc.
5. La segunda columna define la marca asociada a la clase; debe ser un valor entre 1 y 255. En el archivo
/etc/shorewall/tcrules se definen las marcas asociadas a ciertos paquetes que caerán dentro de esta clase si corresponde
con la misma marca.
6. La tercera columna define el ancho de banda mínimo que esta clase debería tener asegurada cuando el tráfico total se
incrementa. La suma de todos los valores de esta columna pertenecientes a una misma interfaz debe ser igual al valor de
la columna OUT-BANDWIDTH de la misma interfaz en el archivo /etc/shorewall/tcdevices.
7. La cuarta columna define el ancho de banda máximo que esta clase debería recibir cuando la línea se encuentra inactiva
o no utilizada por otras clases. Se puede usar valores especificados con sufijos kbps, kbit u otros, o se puede especificar
la palabra especial full que hará referencia al máximo de ancho de banda declarado para la interfaz de red en
/etc/shorewall/tcdevices (OUT-BANDWIDTH).
También es posible especificar valores porcentuales respecto a full con operadores matemáticos. Por ejemplo 20% de
full se expresaría como 20*full/100.
8. La quinta columna define la prioridad en la que se atiende a esta clase sobre otras. A menor valor numérico mayor será la
prioridad, siendo 1 la máxima posible.
9. La sexta columna define ciertas opciones disponibles para las clases, de acuerdo a lo debajo indicado:
• default : Convierte a la clase en la predeterminada o por defecto para aquellos paquetes que no han
sido clasificados por ninguna regla en /etc/shorewall/tcrules. Se debe definir sólo una clase con esta opción por cada
interfaz.
• tcp-ack : Clasifica en esta clase a los paquetes TCP ACK de tamaño menor o igual a 64 bytes. Si se
especifica esta opción entonces se ignorará la marca (segunda columna), es decir se incluye en esta clase al
paquete ACK (menor a 64 bytes) sin importar con qué marca haya podido ser clasificado anteriormente.
Se debe definir sólo una clase con esta opción por cada interfaz.
• tos-TOS : Clasifica en esta clase a los paquetes que tengan el campo TOS (Type of Service) igual a uno
de los aquí especificados con tos-TOS. TOS puede ser: minimize-delay, maximize-throughput, minimize-
cost o normal-service.
Se debe definir sólo una clase con esta opción por cada interfaz.
Importante:
• La documentación completa del archivo /etc/shorewall/tcclasses se puede encontrar en shorewall-tcclasses(5)
Paso 4: Configuración de las reglas de clasificación

Una vez que se definieron las clases con sus respectivos anchos de banda y prioridades cada una, es momento de decidir qué
paquetes irán a cada una de ellas basadas en nuestras necesidades.
Esta clasificación se hace aplicando marcas a los paquetes que coincidan con ciertos criterios definidos en el archivo
OpenSourceCollege
Linux for SysAdmins
Página 297
Source Linux
/etc/shorewall/tcrules el cual debería tener un contenido como el siguiente:
#MARK SOURCE DEST PROTO DEST SOURCE

# PORT(S) PORT(S)
2 0.0.0.0/0 0.0.0.0/0 icmp
2 0.0.0.0/0 0.0.0.0/0 tcp 22
3 192.168.0.0/24 0.0.0.0/0 tcp 25
2:F eth0 192.168.0.0/24 tcp - 22,53

2:F eth0 192.168.0.0/24 udp - 53
3:F eth0 192.168.0.0/24 tcp - 80,443
4:F eth0 192.168.0.2 tcp - 21,110,143,993,995
5 $FW 192.168.0.0/24
columnas.
2. Este archivo define las clases de control de ancho de banda, con sus prioridades, tasas de transferencia mínimas y
máximas así como otros atributos.
3. Al contrario de lo que sucede en /etc/shorewall/rules las reglas en este archivo se continúan leyendo aún luego de una
coincidencia, de modo tal que la regla que se aplicará sobre un paquete será la última que coincida en la lectura vertical
(desde arriba hacia abajo).
4. La primera columna define la marca que se debe aplicar al paquete. Luego de los dos puntos (:) se puede especificar
una letra que identifica la cadena de netfilter en la cual se hará el marcado. Las letras posibles son F (FORWARD), P
(PREROUTING) y T (POSTROUTING). El marcar los paquetes en la cadena POSTROUTING permite aplicar la regla tanto a
paquetes originados en el mismo Firewall así como también aquellos que se reenvíen a través del Firewall.
5. La segunda columna define la dirección origen de la conexión. Puede ser un host o una dirección de red especificada con
su máscara de red.
6. La tercera columna define la dirección destino de la conexión. De igual sintaxis que la columna anterior.
7. La cuarta columna permite especificar el protocolo de la conexión. Puede ser tcp, udp, icmp u otro protocolo existente
en /etc/protocols.
8. La quinta columna define el puerto destino de la conexión. Válido sólo para protocolos tcp y udp.
9. La sexta columna define el puerto origen de la conexión. De igual sintaxis que la columna anterior.
Acorde a esta clasificación de paquetes se tendría que:
• A todos los paquetes ICMP se les aplica la marca número 2.

• A todos los paquetes TCP destinados al puerto 22 se les aplica la marca número 2.
• A todos los paquetes originados en la LAN (192.168.0.0/24) destinados al puerto SMTP (TCP 25) se les aplica la marca
número 3.
• A los paquetes que ingresan por eth0 y van hacia la LAN (provenientes de Internet, tráfico de bajada) originados desde
puertos TCP 22 y 53 se les aplica la marca número 2. Lo mismo con los paquetes UDP 53 en el mismo sentido de la
conexión.
• A los paquetes que ingresan por eth0 y van hacia la LAN (provenientes de Internet, tráfico de bajada) originados desde
puertos TCP 80 y 443 (navegación Web de usuarios) se les aplica la marca número 3.
• A los paquetes que ingresan por eth0 y van hacia el host de la LAN 192.168.0.2 (provenientes de Internet, tráfico de bajada)
originados desde puertos TCP 21, 110, 143, 993 y 995 y 443 (tráfico de FTP y lectura de correo) se les aplica la marca
número 4.
• Al tráfico que genera el mismo Firewall hacia la LAN 192.168.0.0/24 se le aplica la marca número 5.
Ahora con sólo analizar qué paquetes han sido marcados con qué números y comparándolos con la información definida en
/etc/shorewall/tcclasses se puede saber el ancho de banda que se reserva para las conexiones arriba descritas.
Importante:
• La documentación completa del archivo /etc/shorewall/tcrules se puede encontrar en shorewall-tcrules(5)
OpenSourceCollege
Linux for SysAdmins
Página 298
Source Linux
# shorewall check
# shorewall restart
Configuración de un Firewall y dos Proveedores de Internet

La siguiente configuración tiene por objetivo crear una configuración donde el Firewall que correo Shorewall está conectado a dos
routers pertenecientes a líneas de Internet distintas.
El objetivo de esta configuración es poder clasificar las conexiones de los clientes para que sean enrutadas a través de uno u otro
router dependiendo de nuestras necesidades.
La figura de este escenario a configurar sería como sigue:
Para este escenario se asumirá que:
• eth0 está conectado al ISP1. La IP de eth0 es 206.124.146.176 y del router del ISP1 es 206.124.146.254.
• eth1 está conectado al ISP2. La IP de eth1 es 130.252.99.27 y del router del ISP1 es 130.252.99.254.
• eth2 está conectada a LAN. Su dirección IP no es relevante a esta configuración.
Paso 1: Configuración básica previa

Vamos a realizar una configuración básica de zonas, interfaces, políticas, reglas y enmascaramiento de acuerdo a los siguientes
archivos de configuración:
/etc/shorewall/zones
#ZONE TYPE
fw firewall
WAN ipv4
LAN ipv4
Se recomienda definir ambas interfaces conectadas a los proveedores ISP1 e ISP2 como miembros de la zona WAN:
OpenSourceCollege
Linux for SysAdmins
Página 299
Source Linux
/etc/shorewall/interfaces
LAN eth2 detect tcpflags,routefilter,nosmurfs
Por seguridad se recomienda que cualquier posible tráfico que ingrese por uno de los proveedores y pretenda salir por el otro
(desde WAN hacia WAN) sea denegado:
/etc/shorewall/policy
#SOURCE DEST POLICY
fw all ACCEPT
WAN WAN DROP
all all DROP
/etc/shorewall/rules
ACCEPT WAN $FW icmp
ACCEPT LAN $FW icmp

ACCEPT LAN $FW tcp 22
ACCEPT LAN WAN icmp

/etc/shorewall/masq
eth0 192.168.0.0/24
Paso 2: Configuración de proveedores

Se requiere configurar los proveedores disponibles que están conectados al host corriendo Shorewall. Para ello debe editarse el
archivo /etc/shorewall/providers como sigue:
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY

ISP1 1 10 main eth0 206.124.146.254 track,balance eth2
ISP2 2 20 main eth1 130.252.99.254 track,balance eth2
columnas.
2. Este archivo define los distintos proveedores (enrutadores) existentes, dándoles a cada una un nombre, identificador
numérico propio y número de marca que clasificará los paquetes en cada uno de ellos.
3. La primera columna define un nombre del proveedor, el mismo que también será asignado como nombre a su respectiva
tabla de enrutamiento.
4. La segunda columna asigna un identificador numérico único al proveedor, asociado también a su respectiva tabla de
enrutamiento.
5. La tercera columna define un número de marca que deben tener los paquetes para ser enrutados por este proveedor.
6. La cuarta columna define el nombre de una tabla de enrutamiento existente en el sistema desde la cual se debe copiar
su contenido (sus rutas) para crear la tabla de rutas de este proveedor. Por lo general aquí se debería especificar el
nombre main que corresponde a la tabla de enrutamiento principal predeterminada del sistema.
7. La quinta columna define la interfaz de red que conecta al proveedor.
8. La sexta columna define la dirección IP de la puerta de enlace que ofrece el proveedor (dirección del router).
9. La séptima columna define opciones de las cuales sólo track y balance deberían incluirse. La explicación de éstas se
muestra debajo:
OpenSourceCollege
Linux for SysAdmins
Página 300
Source Linux
• track : Las respuestas (salientes) de conexiones previas entrantes deben enrutarse por la misma interfaz que
ingresó. Se recomienda siempre incluir esta opción.
• balance : El tráfico saliente debe ser balanceado entre ambos proveedores. Se recomienda activar esta opción
incluso si algunos paquetes serán enrutados siempre por un mismo proveedor de acuerdo a las reglas de
clasificación en /etc/shorewall/tcrules.
10. La octava columna define las interfaces adicionales en las cuales se copiará la tabla de enrutamiento de este proveedor.
Se recomienda incluir aquí todas las interfaces de red del sistema excepto aquellas ya declaradas en este archivo.
Importante:
• La documentación completa del archivo /etc/shorewall/providers se puede encontrar en shorewall-providers(5)
Paso 3: Configuración de las reglas de clasificación

Una vez que se definieron las proveedores existentes se debe configurar la clasificación de los paquetes para ser enrutados por
cada uno de estos proveedores.
Esta clasificación se hace aplicando marcas a los paquetes que coincidan con ciertos criterios definidos en el archivo
/etc/shorewall/tcrules el cual debería tener un contenido como el siguiente:

# PORT(S) PORT(S)
10 192.168.0.0/24 0.0.0./0
20 192.168.0.3 0.0.0.0/0
20 $FW 0.0.0.0/0
10 $FW 0.0.0.0/0 tcp 25
La sintaxis de este archivo ya se debe conocer por lo que se pasará a analizar el significado de esta configuración:
• Todo el tráfico proveniente de la red 192.168.0.0/24 (vía eth2) será enrutado por defecto por el ISP1.
• El host 192.168.0.3 será enrutado por el ISP2.
• Todo el tráfico originado por el mismo Firewall será enrutado por el proveedor ISP2.
• Sólo el tráfico SMTP saliente originado por el mismo Firewall se enrutará por el proveedor ISP1.
Paso 4: Ajustes de enmascaramiento

Dado que los clientes podrán ser enrutados por cualquiera de los proveedores ISP1 o ISP2, es necesario asegurarse que se
enmascare con las respectivas direcciones IP públicas actualizando /etc/shorewall/masq como sigue:

eth0 192.168.0.0/24 206.124.146.176
eth1 192.168.0.0/24 130.252.99.27
Paso 5: Especificación de reglas de NAT

Este paso es opcional y pretende sólo resaltar la posibilidad que ofrece Shorewall de publica servicios de una red local (acción
DNAT) a través de sólo uno de los proveedores existentes. Nótese la siguiente línea de configuración del archivo /etc/shorewall/rules:

DNAT WAN:eth0 LAN:192.168.0.5 tcp 80
Aquí se especifica que la publicación (DNAT) del servicio Web (TCP 80) se hará sólo a través del proveedor ISP1, conectado vía
eth0.

# shorewall check
# shorewall restart
OpenSourceCollege
Linux for SysAdmins
Página 301
Source Linux
OpenSourceCollege
Linux for SysAdmins
Página 302
Source Linux
Administración de Shorewall desde Webmin
configurar y monitorear la configuración del Firewall con Shorewall siguiendo estos pasos:
5. Dentro de Webmin acceder a 'Servers -> Shoreline Firewall' y dentro revisar las opciones de configuración de este servicio.
OpenSourceCollege
Linux for SysAdmins
Página 303
Source Linux
1. Se tiene un Firewall con dos interfaces de red, eth0 y eth1. La primera está conectada a un router Cisco que provee una
línea simétrica de 1 Mbps (overbooking 1:1) y la segunda a un switch que alimenta a una red LAN 192.168.10.0/24. Además
en el Firewall está ejecutándose un servidor SSH, un servidor Proxy con Squid, un servidor DNS caché con BIND, un
servidor NTP y una instancia del servidor OpenVPN el mismo que ha creado una interfaz de red tun0 para la conexión de
túneles remotos.
Se requiere crear las reglas básicas de Firewall de modo que se cumplan los siguientes requisitos:
a) El Firewall debe atender sólo a las conexiones SSH y OpenVPN (puerto UDP 1194) desde Internet.
b) Se debe controlar las conexiones SSH entrantes a un límite de 5 conexiones por minuto como máximo, con una ráfaga
de 7 que invoque al bloqueo de los siguientes intentos de conexión.
c) Los usuarios de la LAN deben poder acceder a los servicios Proxy, DNS y NTP que ofrece el Firewall.
d) Sólo el host de la LAN con dirección MAC 00:24:81:35:2B:6E podrá conectarse por SSH al Firewall, y también tendrá
acceso libre a Internet (sin restricciones) a todos los puertos.
e) Cualquier consulta DNS hecha por los clientes a servidores externos debe ser interceptada por el Firewall y procesada
por el servidor DNS local que ahí corre como caché.
f) Los clientes de la LAN sólo podrán acceder hacia Internet para enviar paquetes ICMP y conexiones SMTP salientes.
g) Los clientes VPN sólo podrán comunicarse con el Firewall para enviar paquetes ICMP y sincronizar el tiempo vía NTP.
h) Se debe permitir acceso total (permitir todo el tráfico) entre los clientes remotos VPN y la red LAN.
i) Se ha de enmascarar a todos los clientes de la LAN con la primera dirección asignada a la interfaz eth0.
j) Redireccionar las conexiones HTTP salientes al proxy local (proxy transparente)
k) Se debe reservar el 10% del ancho de banda para paquetes TCP ACK (de subida), un 30% para tráfico SMTP saliente
(de subida), un 20% para conexiones SSH del exterior hacia el Firewall (de subida) y el resto ser asignado a libre
demanda. El tráfico de bajada no será controlado debido a que los usuarios sólo navegarán por la Web vía proxy el cual
ya implementará los controles de ancho de banda necesarios.
OpenSourceCollege
Linux for SysAdmins
Página 304
Source Linux
1. Se tiene un Firewall con dos interfaces de red, eth0 y eth1. La primera está conectada a un router Cisco que provee una
línea simétrica de 1 Mbps (overbooking 1:1) y la segunda a un switch que alimenta a una red LAN 192.168.10.0/24. Además
en el Firewall está ejecutándose un servidor SSH, un servidor Proxy con Squid, un servidor DNS caché con BIND, un
servidor NTP y una instancia del servidor OpenVPN el mismo que ha creado una interfaz de red tun0 para la conexión de
túneles remotos.
Se requiere crear las reglas básicas de Firewall de modo que se cumplan los siguientes requisitos:
a) El Firewall debe atender sólo a las conexiones SSH y OpenVPN (puerto UDP 1194) desde Internet.
b) Se debe controlar las conexiones SSH entrantes a un límite de 5 conexiones por minuto como máximo, con una ráfaga
de 7 que invoque al bloqueo de los siguientes intentos de conexión.
c) Los usuarios de la LAN deben poder acceder a los servicios Proxy, DNS y NTP que ofrece el Firewall.
d) Sólo el host de la LAN con dirección MAC 00:24:81:35:2B:6E podrá conectarse por SSH al Firewall, y también tendrá
acceso libre a Internet (sin restricciones) a todos los puertos.
e) Cualquier consulta DNS hecha por los clientes a servidores externos debe ser interceptada por el Firewall y procesada
por el servidor DNS local que ahí corre como caché.
f) Los clientes de la LAN sólo podrán acceder hacia Internet para enviar paquetes ICMP y conexiones SMTP salientes.
g) Los clientes VPN sólo podrán comunicarse con el Firewall para enviar paquetes ICMP y sincronizar el tiempo vía NTP.
h) Se debe permitir acceso total (permitir todo el tráfico) entre los clientes remotos VPN y la red LAN.
i) Se ha de enmascarar a todos los clientes de la LAN con la primera dirección asignada a la interfaz eth0.
j) Redireccionar las conexiones HTTP salientes al proxy local (proxy transparente)
k) Se debe reservar el 10% del ancho de banda para paquetes TCP ACK (de subida), un 30% para tráfico SMTP saliente
(de subida), un 20% para conexiones SSH del exterior hacia el Firewall (de subida) y el resto ser asignado a libre
demanda. El tráfico de bajada no será controlado debido a que los usuarios sólo navegarán por la Web vía proxy el cual
ya implementará los controles de ancho de banda necesarios.
+ Creamos la configuración apropiada de zonas en /etc/shorewall/zones:
#ZONE TYPE
fw firewall
WAN ipv4
LAN ipv4
# La zona para los clientes VPN de OpenVPN

VPN ipv4
+ Creamos la configuración apropiada de interfaces en /etc/shorewall/interfaces:

WAN eth0 detect nosmurfs,tcpflags,routefilter
LAN eth1 detect nosmurfs,tcpflags,routefilter
# Asociamos tun0 a la zona VPN

VPN tun0 detect nosmurfs,tcpflags,routefilter
+ Creamos la configuración apropiada de políticas por defecto en /etc/shorewall/policy:
#SOURCE DEST POLICY LOG

# LEVEL
$FW all ACCEPT
# Acceso total de VPN hacia LAN según requerimiento (h)

VPN LAN ACCEPT
all all DROP
+ Creamos la configuración apropiada de enmascaramiento en /etc/shorewall/masq:

# Se enmascara a todos según requerimiento (i)
eth0 192.168.10.0/24
+ Creamos la configuración apropiada de reglas de filtrado y NAT en /etc/shorewall/rules:
OpenSourceCollege
Linux for SysAdmins
Página 305
Source Linux
# Permitir acceso al servicio OpenVPN desde Internet según requerimiento (a)
ACCEPT WAN $FW udp 1194
# Permitir acceso al servicio SSH desde Internet con límites según requerimiento (b)
ACCEPT WAN $FW tcp 22 - - 5/min:7
#ACTION SOURCE DEST PROTO

DEST SOURCE ORIGINAL RATE
# Los clientes de la LAN acceden a los servicios Proxy, DNS y NTP según requerimiento (c)
ACCEPT LAN $FW tcp 53,3128
ACCEPT LAN $FW udp 53,123
# Los clientes VPN acceden a los servicios NTP y envían paquetes al firewall únicamente
# según requerimiento (g)
ACCEPT VPN $FW icmp
ACCEPT VPN FW udp 53
#ACTION SOURCE DEST PROTO DEST

# PORT
# Sólo el host de MAC 00:24:81:35:2B:6E puede acceder al servicio SSH del Firewall
# y salir libre a Internet según requerimiento (d)
ACCEPT LAN:~00-24-81-35-2B-6E $FW tcp 22
ACCEPT LAN:~00-24-81-35-2B-6E WAN all
# Los clientes de la LAN acceden hacia Internet con paquetes ICMP y SMTP según
# requerimiento (f)
ACCEPT LAN WAN icmp

# Redireccionamos las consultas DNS a nuestro servidor BIND local según requerimiento (e)
REDIRECT LAN 53 udp 53
# Redireccionamos a los clientes al proxy local (proxy transparente) según requerimiento

# (j)
REDIRECT LAN 3128 tcp 80
+ Creamos la configuración de dispositivos QoS y sus capacidades en /etc/shorewall/tcdevices:
#NUMBER: IN-BANDWITH OUT-BANDWIDTH

#INTERFACE
eth0 0mbit 1mbit
+ Creamos las clases QoS y sus capacidades en /etc/shorewall/tcclasses:
#INTERFACE:CLASS MARK RATE: CEIL PRIORITY OPTIONS

# DMAX:UMAX
eth0 1 10*full/100 full 1 tcp-ack
eth0 4 40*full/100 full 4 default
+ Creamos las reglas de clasificación de paquetes en /etc/shorewall/tcclasses:

# PORT(S) PORT(S)
2 192.168.10.0/24 0.0.0.0/0 tcp 25
3 $FW 0.0.0.0/0 tcp - 22
+ Verificamos la sintaxis y aplicamos los cambios:
# shorewall check
# shorewall restart
OpenSourceCollege
Linux for SysAdmins
Página 306
Source Linux
Unidad 15: Proxy de control de navegación Web
15.1. Objetivos
✔ Conocer el propósito de un servidor proxy en las redes informáticas.

✔ Configurar el proxy Squid para realizar filtrado variado de navegación Web por criterios variados.
✔ Saber controlar el ancho de banda utilizado por cada cliente en la navegación Web a través de Squid.
✔ Configurar métodos de autenticación de usuarios para la navegación a través de proxy.
15.2. Squid como proxy caché

Introducción
¿Qué es un proxy?
El término proxy hace referencia a un programa o dispositivo que realiza una acción en representación de otro. La finalidad más
habitual es la del servidor proxy, que sirve para permitir el acceso a Internet a todos los equipos de una organización cuando sólo
se puede disponer de un único equipo conectado, esto es, una única dirección IP.
Se tiene que existen varios tipos de proxies según los protocolos que atienden, así hay proxies Web como Squid, proxies FTP
como Frox, proxies SIP como SER, entre otros.
El objetivo de esta parte del documento es estudiar el proxy Web Squid.
Proxy Web y proxy caché

Un proxy Web permite a otros equipos conectarse a una red de forma indirecta a través de él. Cuando un equipo de la red desea
acceder a una información o recurso, es realmente el proxy quien realiza la comunicación y a continuación traslada el resultado al
equipo inicial. En unos casos esto se hace así porque no es posible la comunicación directa y en otros casos porque el proxy
añade una funcionalidad adicional, como puede ser la de mantener los resultados obtenidos (p.ej.: una página web) en una cache
que permita acelerar sucesivas consultas coincidentes. Con esta denominación general de proxy se agrupan diversas técnicas.
Aparte de la utilidad general de un proxy, proporciona una cache para las páginas web y los contenidos descargados, que es
compartida por todos los equipos de la red, con la consiguiente mejora en los tiempos de acceso para consultas coincidentes. Al
mismo tiempo libera la carga de los enlaces hacia Internet.
Funcionamiento:
1. El cliente realiza una petición (p.e. mediante un navegador web) de un recurso de Internet (una página web o cualquier
otro archivo) especificado por una URL.
2. Cuando el proxy caché recibe la petición, busca la URL resultante en su caché local. Si la encuentra, devuelve el
documento inmediatamente, si no es así, lo captura del servidor remoto, lo devuelve al que lo pidió y guarda una copia en
su caché para futuras peticiones.
El caché utiliza normalmente un algoritmo para determinar cuándo un documento está obsoleto y debe ser eliminado de la caché,
dependiendo de su antigüedad, tamaño e histórico de acceso. Dos de esos algoritmos básicos son el LRU (el usado menos
recientemente, en inglés "Least Recently Used") y el LFU (el usado menos frecuentemente, "Least Frequently Used").
Los proxies web también pueden filtrar el contenido de las páginas Web servidas. Algunas aplicaciones que intentan bloquear
contenido Web ofensivo están implementadas como proxies Web. Otros tipos de proxy cambian el formato de las páginas web para
un propósito o una audiencia específicos, para, por ejemplo, mostrar una página en un teléfono móvil o una PDA. Algunos
operadores de red también tienen proxies para interceptar virus y otros contenidos hostiles servidos por páginas Web remotas.
Proxies transparentes
Muchas organizaciones (incluyendo empresas, colegios y familias) usan los proxies para reforzar las políticas de uso de la red o
para proporcionar seguridad y servicios de caché. Normalmente, un proxy Web o NAT no es transparente a la aplicación cliente:
debe ser configurada para usar el proxy, manualmente. Por lo tanto, el usuario puede evadir el proxy cambiando simplemente la
configuración.
Un proxy transparente combina un servidor proxy con NAT de manera que las conexiones son enrutadas dentro del proxy sin
configuración por parte del cliente, y habitualmente sin que el propio cliente conozca de su existencia. Este es el tipo de proxy que
utilizan los proveedores de servicios de internet (ISP). En España, la compañía más expandida en cuanto a ADSL se refiere, ISP
Telefónica, dejó de utilizar proxy transparente con sus clientes a partir de Febrero de 2006.
¿Por qué y cuando usar proxies?

Un breve listado de algunas ventajas y desventajas podría ayudarle a tomar la decisión de implementar o no un proxy para la red
de su organización.
Ventajas:
OpenSourceCollege
Linux for SysAdmins
Página 307
Source Linux
• Control: Sólo el intermediario hace el trabajo real, por tanto se pueden limitar y restringir los derechos de los usuarios, y
dar permisos sólo al proxy.
• Anonimato: Si todos los usuarios se identifican como uno sólo, es difícil que el recurso accedido pueda diferenciarlos.
Pero esto puede ser malo, por ejemplo cuando hay que hacer necesariamente la identificación.
• Ahorro de Tráfico: Las peticiones de páginas Web se hacen al servidor Proxy y no a Internet directamente. Por lo tanto,
aligera el tráfico en la red y descarga los servidores destino, a los que llegan menos peticiones.
• Velocidad en Tiempo de respuesta: El servidor Proxy crea un caché que evita transferencias idénticas de la información
entre servidores durante un tiempo (configurado por el administrador) así que el usuario recibe una respuesta más
rápida.
• Demanda a Usuarios: Puede cubrir a un gran número de usuarios, para solicitar, a través de él, los contenidos Web.
• Filtrado de contenidos: El servidor proxy puede hacer un filtrado de páginas o contenidos basándose en criterios de
restricción establecidos por el administrador dependiendo valores y características de lo que no se permite, creando una
restricción cuando sea necesario.
• Modificación de contenidos: Basándose en la misma función del filtrado, y llamado Privoxy, tiene el objetivo de proteger la
privacidad en Internet, puede ser configurado para bloquear direcciones y Cookies por expresiones regulares y modifica
en la petición el contenido.
Desventajas:
• Abuso: Al estar dispuesto a recibir peticiones de muchos usuarios y responderlas, es posible que haga algún trabajo que
no toque. Por tanto, ha de controlar quién tiene acceso y quién no a sus servicios, cosa que normalmente es muy difícil.
• Carga: Un proxy ha de hacer el trabajo de muchos usuarios.
• Intromisión: Es un paso más entre origen y destino, y algunos usuarios pueden no querer pasar por el proxy. Y menos si
hace de caché y guarda copias de los datos.
• Incoherencia: Si hace de caché, es posible que se equivoque y dé una respuesta antigua cuando hay una más reciente
en el recurso de destino.
• Irregularidad: El hecho de que el proxy represente a más de un usuario da problemas en muchos escenarios, en concreto
los que presuponen una comunicación directa entre 1 emisor y 1 receptor (como TCP/IP).
• Las páginas mostradas pueden no estar actualizadas si éstas han sido modificadas desde la última carga que realizó el
proxy caché.
Un diseñador de páginas web puede indicar en el contenido de su web que los navegadores no hagan una caché de sus
páginas, pero este método no funciona habitualmente para un proxy.
• El hecho de acceder a Internet a través de un Proxy, en vez de mediante conexión directa, impide realizar operaciones
avanzadas a través de algunos puertos o protocolos.
• Almacenar las páginas y objetos que los usuarios solicitan puede suponer una violación de la intimidad para algunas
personas.
Squid como proxy Web

Squid es un popular programa de software libre que implementa un servidor Proxy y un demonio para Web caché, publicado bajo
licencia GPL. Tiene una amplia variedad de utilidades, desde acelerar un Servidor Web, guardando en caché peticiones repetidas a
DNS y otras búsquedas para un grupo de gente que comparte recursos de la red, hasta caché de Web, además de añadir
seguridad filtrando el tráfico. Está especialmente diseñado para ejecutarse bajo entornos Unix-like.
Squid ha sido desarrollado durante muchos años y se le considera muy completo y robusto. Soporta muchos protocolos, aunque se
usa principalmente para HTTP y FTP. Se añade soporte también a TLS, SSL, Internet Gopher y HTTPS.
Características:
1. Proxy y Caché de HTTP, FTP, y otras URLs

2. Proxy para SSL
3. Jerarquías de Caché
4. ICP, HTCP, CARP, Caché Digests
5. Caché transparente
6. WCCP (Squid v2.3 y superior)
7. Control de acceso
8. Aceleración de servidores HTTP
9. SNMP
10. Caché de resolución DNS
Instalación de Squid
El procedimiento de instalación de Squid es sencillo:
# yum groupinstall squid -y
OpenSourceCollege
Linux for SysAdmins
Página 308
Source Linux
# apt-get install squid squidclient
Configuración de Squid
Squid centraliza su configuración en un único archivo de texto plano el cual es /etc/squid/squid.conf. La sintaxis de todo el archivo es
bastante simple y se ajusta al siguiente formato:
directiva VALOR [PARAMETRO1] [PARAMETRO2]
Además al igual que en muchos ficheros de configuración se tiene que el caracter # sirve para dar inicio a un comentario y todo el texto
que venga a continuación a su derecha será simplemente ignorado por el programa Squid.
A continuación detallaremos una serie de directivas de configuración de Squid que son por lo general algunas de las más comunes e
importantes.
http_port
Permite especificar las direcciones de escucha del servicio por las diferentes interfaces existentes en el sistema. La opción
transparent le da soporte a Squid para aceptar conexiones de proxy transparente.
Sintaxis : http_port [direccion:]puerto [transparent]
Ejemplos:
http_port 8080 transparent

http_port 10.0.0.1:3128
http_port 192.168.2.1:3128 transparent
cache_dir
Define cual es el directorio para almacenamiento de objetos de caché. Este directorio usa un tipo de almacenamiento que puede
ser ufs (mayormente usado), aufs (usado con Async I/O).
El tamaño es la capacidad máxima de objetos de caché que pueden almacenarse expresado en Mbytes en el directorio
especificado. Ndir1 y Ndir2 definen la cantidad de directorios de primer y segundo nivel respectivamente que se crean en el
directorio de la caché.
Sintaxis : cache_dir ALMACENAMIENTO DIRECTORIO TAMAÑO Ndir1 Ndir2
Ejemplo:
cache_dir ufs /var/spool/squid 4000 16 256
cache_access_log
Ruta del archivo de registro de consultas de los clientes conteniendo todas las páginas visitadas.
Sintaxis : cache_access_log ruta_directorio
Ejemplo:
cache_access_log /var/log/squid/access.log
cache_log
Ruta de archivo de registro del desempeño y comportamiento de la caché y en general del servicio Squid.
Sintaxis : cache_log ruta_directorio
Ejemplo:
cache_log /var/log/squid/cache.log
cache_store_log
OpenSourceCollege
Linux for SysAdmins
Página 309
Source Linux
Ruta del archivo de registro de los objetos guardados y removidos de la caché.
Sintaxis : cache_store_log ruta_directorio
Ejemplo:
cache_store_log /var/log/squid/store.log
cache_swap_log
Ruta del archivo que contiene los metadatos de objetos guardados en el disco. Este archivo es usado para reconstruir la caché en
el arranque de Squid.
Sintaxis : cache_swap_log ruta_directorio
Ejemplo:
cache_swap_log /var/log/squid/swap.log
useragent_log
Ruta del archivo de registro del campo User-Agent para todas las peticiones HTTP. Ejemplo:
Sintaxis : useragent_log ruta_directorio
Ejemplo:
useragent_log /var/log/squid/useragent.log
log_mime_hdrs
Registrar los tipos MIME en cada petición HTTP.
Sintaxis : log_mime_hrds on|off
Ejemplo:
log_mimre_hdrs off
pid_filename
Ruta del archivo que contiene el PID de Squid en ejecución.
Sintaxis : pid_filename ruta_directorio
Ejemplo:
pid_filename /var/run/squid.pid
mime_table
Ruta del archivo de los tipos MIME reconocidos.
Sintaxis : mime_table ruta_directorio
Ejemplo:
mime_table /etc/squid/mime.conf
no_cache
Permite que ciertos objetos que coincidan con una ACL sean o no sean almacenados en la caché (allow o deny).
Sintaxis : no_cache allow|deny ACL
En el siguiente ejemplo se define una ACL de nombre "QUERY" la cual coincide con URLs que terminen con las extensiones .php,
OpenSourceCollege
Linux for SysAdmins
Página 310
Source Linux
.asp o contengan "?" siendo típicos de sitios dinámicos. Así se evita que se almacene sitios dinámicos en la caché:
acl QUERY urlpath_regex cgi-bin \? \.php \.asp

no_cache deny QUERY
cache_mem
Cantidad de memoria que se usa para objetos en transito de la caché. Se recomienda un aproximado de la tercera parte de la
cantidad total de RAM del sistema.
Sintaxis : cache_mem tamaño
Ejemplo:
cache_mem 78 MB
cache_swap_low
cache_swap_high
Marca inferior y superior de la cantidad de espacio en uso de la caché que determina cuando deben eliminarse objetos de la caché
con mayor o menor intensidad; todo esto a fin de no llegar al límite de la capacidad máxima de almacenamiento provocando la falla
en el servicio Squid.
Sintaxis : cache_swap_low porcentaje(0-100)

Sintaxis : cache_swap_high porcentaje(0-100)
El siguiente ejemplo intentará mantener el directorio de la caché en un uso entre 90% y 95% de modo que cuando esté más cerca
al límite inferior la eliminación de objetos será algo moderada mientras que cuando esté más cerca al límite superior la eliminación
de objetos se hará más agresiva a fin de mantenerse dentro de los límites establecidos:
cache_swap_low 90
cache_swap_high 95
cache_effective_user
cache_effective_group
Usuario y grupo bajo el cual se ejecuta el servicio Squid.
Sintaxis : cache_effective_user usuario

Sintaxis : cache_effective_group grupo
Ejemplo:
cache_effective_user squid
cache_effective_group squid
cache_mgr
Dirección e-mail del administrador del servidor proxy. Esta dirección figurará en los mensajes de error generados por Squid
mostrados a los clientes.
Sintaxis : cache_mgr e-mail
Ejemplo:
cache_mgr soporte@consultorianet.com
visible_hostname
Nombre FQDN que identifica al servidor proxy. Este valor será mostrado como pie de página en cada uno de los mensajes de error
generados por Squid mostrados a los clientes.
Sintaxis : visible_hostname hostname
Ejemplo:
visible_hostname proxy.consultorianet.com
OpenSourceCollege
Linux for SysAdmins
Página 311
Source Linux
ftp_passive
Activar o desactivar el comportamiento pasivo en las conexiones FTP.
Sintaxis : ftp_passive on|off
Ejemplo:
ftp_passive on
ftp_user
Dirección e-mail a ser validada por los servidores FTP con los cuales se establecen conexiones anónimas.
Sintaxis : ftp_user e-mail
Ejemplo:
ftp_user soporte@consultorianet.com
dns_nameservers
Especifica una lista de servidores DNS a usar para la resolución de nombres en lugar de los que están especificados en el archivo
"/etc/resolv.conf".
Sintaxis : dns_nameservers direccion [direccion] [direccion] ...
Ejemplo:
dns_nameservers 208.67.222.222 208.67.220.220
auth_param
Define los parámetros para varios esquemas de autenticación soportados por Squid. Los esquemas de autenticación soportados
son basic, digest y ntlm.
Sintaxis : auth_param esquema parámetro [valor]
Los parámetros pueden ser distintos dependiendo del esquema de autenticación usado, pero los del esquema basic son:
program comando
Especifica el programa externo para realizar la autenticación. En la distribución original obtenida del tarball de squid dentro del
directorio 'helpers' se encuentran varios directorios con el código fuente de los programas disponibles para ser usados
categorizados según el esquema elegido.
children N°
La cantidad de instancias del programa a iniciar para la autenticación.
realm texto
Especifica un texto mostrado al cliente en el momento al que éste se le pide autenticarse.
casesensitive on|off
Indica si los nombres de usuario son sensibles a mayúsculas o no.
credentialsttl TTL
Especifica por cuánto tiempo Squid cree que las credenciales de un usuario son válidas luego de haberse autenticado. Esto se
refleja en cuán seguido Squid pedirá al usuario volver a autenticarse.
Ejemplo:
auth_param basic program /usr/sbin/pam_auth

auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic casesensitive off
auth_param basic credentialsttl 2 hours
OpenSourceCollege
Linux for SysAdmins
Página 312
Source Linux
logfile_rotate
Especifica la cantidad de logs antiguos que se han de mantener en cada rotación de los logs cuando se invoque a "squid -k
rotate". En cada rotación un archivo de log se renombra a su similar de extensión ".0", y el anterior de extensión ".0" pasa a
ser ahora de extensión ".1", éste último pasa a ser ".2" en extensión y así sucesivamente hasta la cantidad de veces
especificada en esta directiva.
Sintaxis : logfile_rotate número
Ejemplo:
logfile_rotate 2
error_directory
Ruta del directorio que contiene los mensajes de error en distintos idiomas mostrados por Squid a los clientes. Estos directorios por
defecto suelen ubicarse en "/usr/share/squid/errors".
Sintaxis : error_directory ruta_directorio
Ejemplo:
error_directory /usr/share/squid/errors/Spanish
forwarded_for
Activar o desactivar el uso de la cabecera X-Forwarded-For para las peticiones de los clientes conteniendo la dirección IP de
origen o del cliente. Esta directiva con su valor en off evita que servicios Web en Internet como http://checkip.dyndns.org, http://
www.cual-es-mi-ip.net o http://www.myip.dk muestren la dirección IP privada del cliente en lugar de mostrar la dirección IP
pública enmascarada a través de la cual se conectan.
Sintaxis : forwarded_for on|off
Ejemplo:
forwarded_for off
redirect_program
Especifica la ruta de un programa y sus respectivos parámetros al que Squid cederá el control en cada consulta de los clientes para
realizar operaciones de filtrado.
Sintaxis : redirect_program programa
Un ejemplo de esto es la integración de Squid con squidGuard como se muestra a continuación:
redirect_program /usr/sbin/squidGuard -c /etc/squidGuard.conf
redirect_children
Número de instancias del programa de redirección que se van a iniciar.
Sintaxis : redirect_children número
Ejemplo:
redirect_children 8
acl
Define un Access Control List (Lista de control de acceso) con un nombre determinado y de un tipo especificado el cual puede
aceptar una serie de parámetros. Estos parámetros pueden ser especificados al lado derecho a continuación del tipo de la ACL o
bien pueden ser especificados como la ruta de un archivo (encerrado entre doble comillas) que contiene dichos parámetros.
Sintaxis : acl nombre tipo parámetros
Algunos de los tipos de ACL más comunes son los siguientes:
OpenSourceCollege
Linux for SysAdmins
Página 313
Source Linux
src dirección[/máscara]
Consulta la dirección IP del cliente. Ejemplos:
acl redlocal src 192.168.254.0/24

acl gerentes src 192.168.254.13 192.168.254.19
acl alumnos src 192.168.254.121-192.168.254.126
acl ilimitado src "/etc/squid/ilimitado.txt"
dst dirección[/máscara]
Consulta la dirección IP destino de la consulta. Ejemplos:
acl dmz dst 10.3.2.0/24

acl hosting dst 201.230.34.32/28
srcdomain nombre_dominio
Consulta el nombre de host o dominio del cliente. Ejemplos:
acl lan-chincha srcdomain .chincha.consultorianet.com

acl lan-pisco srcdomain .pisco.consultorianet.com
dstdomain nombre_dominio
Consulta el nombre de host o dominio destino de la consulta. Ejemplos:
acl webchat dstdomain .meebo.com .e-messenger.net .ebuddy.com .imhaha.com

acl winupdates dstdomain .download.microsoft.com .update.microsoft.com
time [dias] [H1:M1-H2:M2]

Consulta la fecha y/o hora en la que coincide la ACL. Los días y hora pueden especificarse como sigue:
• S – Sunday
• M – Monday
• T – Tuesday
• W – Wednesday
• H – Thursday
• F – Friday
• A – Saturday
H1:M1 debe ser menor que H2:M2 en referencia de horas.
acl oficina time MTWHF 09:00-18:00

acl findesemana time AS
url_regex [-i] patrón

Busca en la URL completa (dominio + ruta) la coincidencia de un patrón que tiene la forma de una expresión regular. La
coincidencia con el patrón es sensible a mayúsculas a menos que se use la opción "-i" antes del patrón.
acl messenger url_regex messenger.* msn

acl porn url_regex -i <xxx> s[e3]x p[o0]rn
urlpath_regex [-i] patrón

Busca sólo en la ruta de la URL la coincidencia de un patrón que tiene la forma de una expresión regular. La coincidencia con el
patrón es sensible a mayúsculas a menos que se use la opción "-i" antes del patrón.
acl descargas urlpath_regex -i \.exe$ \.zip$ \.rar$ \.mp3$ \.avi$ \.mpg$

acl webmail urlpath_regex -i webmail correoweb horde exchange
port puertos
Consulta el puerto al que el cliente realiza la conexión. Ejemplos:
acl Safe_ports 80 81 8080

acl Safe_ports 7777 7778 88
acl SSL_ports 443 563
method métodos
Hace referencia al método usado por el cliente para hacer sus peticiones. Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Página 314
Source Linux
acl metodospermitidos method GET POST HEAD
acl metodosprohibidos method TRACE
browser [-i] patrón

Coincide un patrón que formado por una expresión regular con la cabecera User-Agent enviada en la petición del cliente. La
coincidencia con el patrón es sensible a mayúsculas a menos que se use la opción "-i" antes del patrón.
acl browser wmp -i Windows-Media-Player

acl browser mozilla -i Mozilla\/4\.0
proxy_auth usuarios
Coincide con uno o más usuarios los cuales son autenticados por una aplicación externa definida en auth_param. Si se usa la
palabra REQUIRED en lugar de una lista de usuarios entonces coincide con cualquier usuario válido autenticado.
acl gerentes proxy_auth achavez arengifo nroldan lsosa

acl empleados proxy_auth REQUIRED
proxy_auth_regex [-i] patrón

Igual que proxy_auth con la diferencia que coincide con usuarios expresados bajo un patrón en forma de expresión regular. Acepta
la opción "-i" para ser insensible a mayúsculas.
acl ventas proxy_auth_regex -i vendedor[0-9]*
req_mime_type [-i] patrón

Coincide la cabecera Content-Type de la petición del cliente con un patrón definido como una expresión regular. Acepta la opción
"-i" para ser insensible a mayúsculas.
acl messenger req_mime_type -i âpplication/x-msn-messenger$

acl imagenes req_mime_type -i îmage/jpeg$
rep_mime_type [-i] patrón

Coincide con el tipo MIME de la respuesta recibida por Squid. Puede ser usado para detectar la descarga de ciertos archivos o
algunas peticiones bajo túneles HTTP. Acepta la opción "-i" para ser insensible a mayúsculas. Estas ACLs no se usan con las
directivas http_access sino con http_reply_access.
acl musica rep_mime_type -i âudio/mpeg$
arp mac
Coincide con la dirección MAC del cliente que solicita las conexiones. Ejemplo:
acl aperez arp 00:11:D8:06:7E:06
http_access
Permite o deniega el acceso a una ACL previamente definida. Si no existen líneas de acceso entonces la acción por defecto es la
denegación. Si existen varias líneas de acceso pero ninguna causa genera coincidencias entonces la acción a tomar es el opuesto
a lo expresado en la última línea de acceso. Es decir si la última línea era allow entonces la acción por defecto final será deny, y
si la última era deny entonces la acción por defecto será allow.
Tener en cuenta también que todas las directivas http_access funcionan en jerarquía trayendo como consecuencia que si una de
estas directivas genera una coincidencia entonces se ejecuta su acción determinada y ya no se analizán otras líneas más abajo,
por lo tanto las líneas más restrictivas deben estar colocadas al inicio y las más permisivas hacia el final.
Sintaxis : http_access allow|deny [!]ACL
Ejemplo:
http_access deny !Safe_ports

http_access allow gerentes
http_access deny msn
http_access deny porn
http_access allow lan
http_access deny all
En el ejemplo de arriba a todos los usuarios se les deniega el acceso a otros puertos que no sean los definidos en la ACL
OpenSourceCollege
Linux for SysAdmins
Página 315
Source Linux
Safe_ports, luego los gerentes tienen todo el acceso libre hacia Internet y al resto de usuarios que coinciden con la ACL lan se
les da libre acceso primero denegandole el chat con MSN (ACL msn)y contenidos pornográficos (ACL porn). Finalmente a
cualquier usuario que no esté definido sobre ninguna de las ACL (all = 0.0.0.0) se le denegará el acceso por completo.
http_reply_access
Similar a http_access pero los accesos están aplicados ya no a las consultas de los clientes sino a las respuestas enviadas por
parte del servidor remoto ante previas peticiones de los clientes. Esto es más útil para controlar el tráfico de audio y video online
dada que su naturaleza es como una respuesta del servidor hacia el cliente que no podría ser controlado con http_access.
Sintaxis : http_reply_access allow|deny [!]ACL
Ejemplo:
acl audio rep_mime_type -i âudio/mpeg$
http_reply_access deny audio

http_reply_access allow all
Lógica de las reglas de Squid: http_access

Quizás sea éste el punto más importante de la configuración del proxy. Es aquí donde recién toma relevancia y verdadera validez
cualquier tipo de restricción que deseemos aplicar haciendo uso de una o más ACLs conjugadas.
Para ello necesitamos entender los siguientes puntos:
1. Las restricciones se representan como una conjugación de reglas y ACLs.

2. Una regla define una acción a ejecutar (Permitir o Denegar) sobre el resultado de la evaluación de una o más ACLs.
3. Las ACLs en una regla se evalúan de manera lógica con el operador AND (horizontalmente).
4. La evaluación de todas las ACLs de una regla deben dar un resultado verdadero en conjunto para así ejecutar la acción
especificada: "Permitir" o "Denegar"
5. Múltiples reglas se evalúan de manera lógica con el operador OR (verticalmente). Esto quiere decir que las reglas tienen
un orden jerárquico de vital importancia.
6. Si la evaluación de ACLs de una regla no da un resultado verdadero en conjunto entonces se procede a evaluar la
siguiente regla que viene debajo, y si tampoco obtiene un resultado verdadero en conjunto seguirá analizando reglas que
vengan debajo.
7. En la primera regla que se obtenga un resultado verdadero de la evaluación conjunta de todas sus ACLs se procederá a
ejecutar la acción "Permitir" o "Denegar" y ya no se analizarán más reglas que pudiesen existir debajo.
A continuación se muestra un ejemplo de reglas:
1) Permitir gerencia
2) Denegar messenger
3) Permitir correos !horario-oficina
4) Permitir contabilidad paginas-contables
5) Permitir red
6) Denegar Todos
De lo anterior se asume que 'gerencia', 'messenger', 'correos', 'horario-oficina', 'contabilidad', 'paginas-contables' y 'Todos' son
ACLs previamente definidas.
Analizaremos estas reglas de manera jerárquica para deducir lo siguiente:
(a) Los usuarios del grupo gerencia tienen acceso total sin ninguna restricción.
(b) A todos los demás usuarios (excepto gerencia) se les deniega el acceso al MSN (ACL 'messenger')
(c) A todos los demás usuarios se les permite el acceso a correos gratuitos tipo Hotmail, Yahoo, etc (ACL 'correos') sólo
fuera del horario de oficina (Negación de ACL 'horario-oficina').
(d) A los usuarios del área de contabilidad (ACL 'contabilidad') se les permitirá navegar sólo por páginas Web relacionadas a
su interés (ACL 'paginas-contables'). Además también del acceso a correos gratuitos según la regla anterior.
(e) A todos los usuarios de la organización (ACL 'red') se les permite libre acceso excepto a recursos afectos por
restricciones de reglas anteriores.
(f) Finalmente por defecto se deniega el acceso a cualquier otro usuario no definido en ningún grupo de usuarios (ACL
Todos). Esto es por una medida de seguridad imprescindible.
Analice la correcta interpretación de estas reglas de ejemplo con sumo cuidado para que sepa entenderlas y sobre todo crear sus
propias reglas acorde a sus necesidades.
Control de ancho de banda con Squid

Los Delay Pools son la herramienta para llevar a cabo el control de ancho de banda del Proxy (rate limiting y traffic shaping). La belleza
de estos radica en que controlan el ancho de banda, sin causar penalidades sobre los objetos traídos desde el caché. En lenguaje
OpenSourceCollege
Linux for SysAdmins
Página 316
Source Linux
técnico de Proxy, los Delay Pools afectan los cache misses, no los cache hits.
Existen tres clases de Delay Pool lo que nos permite tener cierta flexibilidad en su uso. Antes de hablar sobre ellas imagine que un
Delay Pool, especialmente uno de la clase 1, es como un tanque de agua el cual tiene un tubo de entrada y otro de salida. El tubo de
entrada debido a su diámetro y a la apertura de la llave de paso solo permite que el agua entre a una tasa fija. El tubo de salida debido
a su gran diámetro no tiene estas limitaciones y puede vaciar el tanque inmediatamente si la llave de paso se abre lo suficiente.
Finalmente, el tanque siempre almacena una cantidad máxima de agua. Una vez hecho esto asocie:
1. El diámetro del tubo de entrada representa el ancho de banda disponible en total. Usted puede abrir la llave tanto como
pueda pero la cantidad máxima de agua que sale no sobrepasa un tope máximo.
2. La apertura de la llave de paso de entrada representa el canal destinado para uso del Proxy/Delay Pool respectivo. Esta es la
tasa [de llenado] del Delay Pool.
3. La cantidad máxima de agua que almacena el tanque es el tamaño (size) del Delay Pool. Esta es la parte menos
comprendida: el size del Delay Pool permite ráfagas (burst) de descarga mientras el Delay Pool se vacía. Cuando el Delay
Pool queda con un tamaño de cero solo es posible descargar a la rata definida (de nuevo imagine un caso de uso intensivo
del agua del tanque y después de un tiempo piense qué sucede).
4. La apertura de la llave de salida representa su demanda de canal. Entre más abre la llave, más agua intenta obtener. Entre
más archivos trate de traer desde Internet, más canal consume.
Ya con esto usted está en total capacidad de usar Delay Pools clase 1. En Squid 2.x existen tres clases de Delay Pool.
Clase 1:
El Delay Pool clase 1 define una única estructura de control (en nuestra abstracción un único tanque). Este limita el uso del canal de
manera global sin importar cómo lo usan los clientes internamente o cómo esta definida lógicamente la LAN. En el inglés técnico se
habla de la definición de un único aggregate bucket. Esta es la opción indicada si usted desea limitar el ancho de banda que usa Squid,
sin importar cómo lo emplean los usuarios.
Clase 2:
Este es un Delay clase 1 con 256 Delay Pools clase 1 subordinados a éste. En inglés técnico se trata de 1 aggregate bucket y 256
individual buckets. En nuestra abstracción un tanque principal y 256 tanques secundarios alimentados por el tanque principal. Con este
Delay Pool es posible controlar el canal que usan 256 clientes.
¿Cómo se asigna el canal a cada cliente? Squid asume que su LAN es una LAN clase C y usa los últimos 8 bits del número IP del
cliente para identificarlo y manejarlo en su individual bucket correspondiente. En la práctica sólo se pueden controlar 253 clientes
descontando la dirección de red, la dirección de broadcast y la dirección del proxy. Note que aquí se empiezan a enredar las cosas: es
muy diferente hablar de un cliente, un host y un usuario. Squid puede tener 230 clientes en una red de 600 hosts (equipos) y unos 700
usuarios. Jamás confunda estos conceptos aunque pueden ser equivalentes dependiendo de la situación.
Clase 3:
Este es un Delay Pool clase 1 con 256 Delay Pools clase 2 subordinados a éste. En ingles técnico se trata de 1 aggregate bucket, 256
network buckets, y 65,536 individual buckets. Está orientado para manejar la asignación de ancho de banda en redes clase B. Los bits
17 a 24 del número IP identifican la red y los bits 17 a 32 el cliente.
delay_pools
Define la cantidad de Delay Pools a usar.
Sintaxis : delay_pools número
En el ejemplo siguiente especificaremos usar 3 delay pools:
delay_pools 3
delay_class
Permite especificar la clase de Delay Pool. El ID es el orden de la Delay Pool y la clase puede ser 1, 2 ó 3.
Sintaxis : delay_pools id clase
Ejemplo:
delay_class 1 3
delay_class 2 1
delay_class 3 2
Del ejemplo se tiene que el Delay Pool 1 es de clase 3, el Delay Pool 2 de clase 1 y el Delay Pool 3 de clase 2. Los Delay Pools no
tienen nombre, se identifican con un número que empieza en 1 y termina en N°.
delay_parameters
Los parámetros de cada Delay Pool se definen por medio de esta directiva. Los valores de RATE y SIZE son dados en Bytes. Por
OpenSourceCollege
Linux for SysAdmins
Página 317
Source Linux
ende no olvide hacer la conversión respectiva de Kbits como le venden el canal a Bytes. SIZE es dos o tres veces el valor de
RATE.
Sintaxis : delay_parameters id rate/size [rate/size [rate/size]]
Ejemplos:
delay_parameters 1 76800/230400 42800/100000 10000/70000
Un Delay clase 3 con 600Kb/s (76800B/s) en total para navegación, con un tamaño para ráfagas (burst) globales de 1800Kb
(230400Bytes). Para cada subred se asigna un canal máximo de 334.3Kb/s un tamaño para ráfagas de 781.2Kb (100000Bytes)
con un ancho de banda para cada host de 78.1Kb/s (10000B/s) con la posibilidad de ráfagas de descargas de 546.8Kb
(70000Bytes). Note que los valores para cada subred y host exceden los límites de canal disponible si hay más de 4 clientes
navegando en una subred o dos subredes demandan todo el canal asignado. En este caso se produce una condición de
competencia y el primero que solicita el canal es el que lo obtiene. Es de suponer que esta asignación es para una organización
con usuarios que navegan poco y requieren un buen desempeño al momento de solicitar un archivo. Este es un buen ejemplo de
cómo se puede jugar con los parámetros del Delay Pool teniendo en cuenta las costumbres de navegación de la organización.
delay_parameters 1 76800/230400
Un Delay clase 1. Se usan máximo 600Kb/s de ancho de banda con ráfagas de descarga de 1800Kb. Solo se limita el ancho de
banda que usa en total sin importar cómo se distribuye el canal entre los clientes, lo cual da la posibilidad a condiciones de
competencia por el ancho de banda en todo momento.
delay_parameters 1 340787/1022361 10000/200000
Un Delay clase 2. Define que se usarán máximo 2.6Mb/s para navegación con ráfagas de 7.8Mb para una asignación de canal a
máximo 256 clientes de 78.1Kb/s con ráfagas de descarga de 195.3Kb (esto es, pueden descargar 195.3Kb a todo lo que de el
canal si tienen el individual bucket lleno). Este montaje es para una organización cuyos usuarios demandan una gran cantidad de
canal. Aquí el peor caso se presenta cuando hay 34 clientes demandando todo el canal asignado de forma continua.
En los Delay Pools clase 2 y clase 3 es posible deshabilitar los buckets que no se desea utilizar colocando -1/-1 en el bucket
correspondiente.
delay_access
Definen por medio de ACLs cuáles peticiones pasan por el Delay y cuáles no.
Sintaxis : delay_access id allow|deny [!]ACL
Ejemplo:
delay_access 1 allow empleados

delay_access 1 deny all
Puesta en marcha de Squid

Una vez concluida la configuración de Squid es necesario conocer la forma de detectar los problemas más comunes, así como también
saber realizar una serie de tareas administrativas que permitan mantener en buen estado el servicio así como también verificar la
existencia de posibles errores.
Empezaremos iniciando el servicio:
# /etc/init.d/squid start
Es normal cometer errores y la forma de enterarnos qué hicimos mal es darle una mirada al archivo de log cache.log de Squid como
sigue:
# tail -f /var/log/squid/cache.log
En el ejemplo anterior podríamos apreciar si Squid no pudo iniciarse por un error de sintaxis en su configuración, vez por un problema
de permisos, quizás por falta de espacio en disco o cualquiera que sea la causa del problema.
Desde el momento en que Squid ya inicia su funcionamiento sin problemas es posible también que cometamos errores en el orden y
jerarquía de las ACLs de modo tal que un usuario pueda tener acceso a un recurso al que supuestamente habíamos restringido. La
mejor forma de monitorear esto es ver de manera continua el archivo de log access.log de Squid:
# tail -f /var/log/squid/access.log
OpenSourceCollege
Linux for SysAdmins
Página 318
Source Linux
Si ya logramos darnos cuenta de nuestro error respecto a la configuración de las ACLs entonces como se espera editaremos el archivo
/etc/squid/squid.conf y luego tendríamos que decirle a Squid que haga efectivo dichos cambios. ¿Reiniciamos Squid? Es una opción pero
no la más eficiente, en su lugar debería ejecutarse el comando squid -k reconfigure. Veamos qué nos ofrece el comando squid:
-k check
Verifica si Squid está en ejecución
-k parse
Realiza un chequeo en la sintaxis de configuración de Squid
-k reconfigure
Hace efectivo los cambios hechos en la configuración de manera inmediata
-k rotate
Realiza una rotación de todos los archivos de log de Squid
-k shutdown
Instruye a Squid a terminar de manera normal luego de unos segundos al cerrar sus conexiones
-k kill
Detiene Squid de manera inmediata y abrupta sin esperar a cerrar conexión alguna de los clientes
-z
Crea la estructura de directorios para la caché de Squid según el valor de cache_dir
Para que Squid pueda iniciarse normalmente es necesario que la estructura de directorios de la caché esté correctamente creada, por
lo tanto será necesario ejecutar squid -z si el directorio especificado en la directiva cache_dir se encuentra vacío.
Es común que la caché de Squid nos resulte problemática cuando por alguna razón deseamos ver la versión actualizada de un sitio
Web y Squid aún nos sigue mostrando una versión antigua del mismo. Como alternativa válida podríamos crear una ACL para decirle a
Squid que no guarde en caché su contenido con la directiva no_cache.
Sin embargo la mejor opción es forzar a Squid a cargar refrescar la caché de una URL específica como sigue a continuación:
# squidclient -r http://www.newdomains.com
Como último recurso al lector le podría interesar borrar toda la caché del proxy en un momento determinado pero en realidad no existe
un comando específico para ello. En cambio se debe proceder como sigue:
# squid -k shutdown && rm -rf /var/cache/squid/* && squid -z && /etc/init.d/squid start
La única observación sobre la secuencia de comandos de arriba es que se asume que el directorio de la caché de Squid es
/var/cache/squid pudiendo ser una ruta distinta en realidad para el caso de cada sistema operativo.
Administración de Squid desde Webmin

configurar y monitorear el servicio Proxy con Squid siguiendo estos pasos:
OpenSourceCollege
Linux for SysAdmins
Página 319
Source Linux
5. Dentro de Webmin acceder a 'Servers -> Squid Proxy Server' y dentro revisar las opciones de configuración de este servicio.
OpenSourceCollege
Linux for SysAdmins
Página 320
Source Linux
15.3. Reporte de tráfico de usuarios
Introducción
SARG es una herramienta que permite crear reportes sobre la navegación que realizaron los usuarios a través de un proxy Squid. Para
eso esta herramienta necesita leer el archivo de log de Squid /var/log/squid/access.log y de acuerdo a un archivo de configuración
procesará su contenido para generar estadísticas en formato HTML de fácil comprensión los cuales pueden ser publicados en algún
servidor Web.
Instalación desde código fuente

SARG debe ser descargado desde su sitio Web oficial http://sarg.sourceforge.net/sarg.php donde podremos obtener su tarball para
proceder a compilarlo e instalarlo como sigue:
# tar zxf sarg-2.2.6.tar.gz -C /usr/src

# /usr/src/sarg-2.2.6
# ./configure && make && make install
Por defecto SARG tras ser compilado se instala debajo del directorio /usr/local, ubicando así el binario en /usr/local/bin/sarg y su archivo
de configuración principal en /usr/local/etc/sarg.conf.
Instalación desde binarios

En Red Hat / CentOS y derivados, si se tiene configurado el repositorio DAG (http://dag.wieers.com) se puede proceder a hacer la
instalación desde su versión binaria como sigue:
# yum install sarg -y
En Debian y derivados, SARG ya está incluido en los repositorios oficiales por lo que la instalación del paquete binario de este software
se haría como sigue:
# apt-get install sarg -y
Configuración de SARG
El archivo de configuración es sarg.conf y suele ser ubicado en distintos directorios dependiendo del método de instalación, pudiendo
ser común /usr/local/etc/sarg.conf, /etc/sarg/sarg.conf o /etc/squid/sarg.conf.
Sin importar cual sea su ubicación editaremos este archivo debemos tener en cuenta que su contenido predeterminado por lo general
ya viene listo para usarse sin requerir ninguna modificación. Sin embargo puede ser importante ajustar algunos parámetros como los
siguientes:
# Define el idioma del reporte

language Spanish
# Define la ruta del archivo access.log de Squid

access_log /var/log/squid/access.log
# Titulo del reporte

title "Squid User Access Reports"
# El directorio donde se generarán los reportes de SARG

output_dir /var/www/html/squid-reports
# Mostrar las direcciones IP en lugar de los nombres de usuario (yes)

user_ip no
# Intentar resolver las direcciones IP a nombres de host (yes)

resolve_ip no
# Formato de fecha utilizado

# e (Europeo) : dd/mm/yy
# u (Americano) : mm/dd/yy
date_format e
# Cantidad de reportes antiguos a mantener; los más antiguos se borrarán

lastlog 30
Todas las directivas de este archivo de configuración vienen documentadas cada una con sus comentarios, lo que facilita el estudio y
comprensión de todos los parámetros de configuración de SARG.
Una vez que se terminó de editar la configuración se puede invocar ya a SARG y luego analizar los archivos generados en
/var/www/html/squid-reports:
OpenSourceCollege
Linux for SysAdmins
Página 321
Source Linux
# sarg -zx -c /usr/local/etc/sarg.conf
OpenSourceCollege
Linux for SysAdmins
Página 322
Source Linux
Administración de SARG desde Webmin
configurar y monitorear el reporteador de tráfico de Squid con SARG siguiendo estos pasos:
3. En Red Hat / CentOS y derivados:
6. Dentro de Webmin acceder a 'Servers -> Squid Report Generator' y dentro revisar las opciones de configuración de esta
herramienta.
OpenSourceCollege
Linux for SysAdmins
Página 323
Source Linux
1. Implementar una configuración de proxy con Squid que cumpla con los siguientes requisitos:
a) Aceptar conexiones de proxy transparente.

b) Existirán dos grupos: gerencia y empleados.
c) Los miembros del grupo gerencia serán los usuarios aperez, mtello y nruiz.
d) Los miembros del grupo empleados serán los usuarios mprieto, cvega, bchaupis y oquispe.
e) El grupo gerencia tiene acceso libre a Internet sin restricciones.
f) El grupo empleados tiene acceso total a Internet excepto páginas de Chat, música y video en línea.
g) El grupo empleados tiene acceso al MSN sólo de 13:00 a 14:00 y de 18:00 a 22:00 horas.
h) A todos los usuarios, excepto gerentes se les controlará el ancho de banda a una tasa de transferencia de 30 KB/s.
Para estos se debe considerar que:
• Los usuarios mencionados son cuentas de un dominio Active Directory con el cual el servidor Linux debe integrarse.
• La configuración de integración con Active Directory se asume ya lista. Esto implica que la configuración de Winbind,
PAM y otros servicios ya han sido completados completamente y los comandos wbinfo -u y getent passwd retornan
ya la lista completa de usuarios de Linux y del dominio Active Directory.
OpenSourceCollege
Linux for SysAdmins
Página 324
Source Linux
15.4.1. Solución al laboratorio N° 15
1. Implementar una configuración de proxy con Squid que cumpla con los siguientes requisitos:
a) Aceptar conexiones de proxy transparente.

b) Existirán dos grupos: gerencia y empleados.
c) Los miembros del grupo gerencia serán los usuarios aperez, mtello y nruiz.
d) Los miembros del grupo empleados serán los usuarios mprieto, cvega, bchaupis y oquispe.
e) El grupo gerencia tiene acceso libre a Internet sin restricciones.
f) El grupo empleados tiene acceso total a Internet excepto páginas de Chat, música y video en línea.
g) El grupo empleados tiene acceso al MSN sólo de 13:00 a 14:00 y de 18:00 a 22:00 horas.
h) A todos los usuarios, excepto gerentes se les controlará el ancho de banda a una tasa de transferencia de 30 KB/s.
+ Iniciando sobre una configuración predeterminada de /etc/squid/squid.conf editaremos este archivo para cumplir cada uno de
los requisitos.
El primero de ellos (requerimiento (a))concerniente al soporte de proxy transparente se hace configurando como sigue la
siguiente directiva:
...
...
http_port 3128 transparent

...
...
+ Según el requerimiento (b), (c) y (d) y las consideraciones de integración con Active Directory, creamos los grupos gerencia
y empleados con sus respectivos miembros:
...
...
auth_param basic program /usr/lib/squid/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param basic children 5
auth_param basic realm Squid Proxy Server
auth_param basic credentialsttl 2 hours
acl proxy_auth gerencia aperez mtello nruiz

acl proxy_auth empleados mprieto cvega bchaupis oquispe
...
...
+ Creamos las categorías de restricciones que afectarán al grupo empleados:
...
...
# Lista de dominios conocidos de ofrecer servicios de chat en linea (Meebo, E-messenger,

# Ebuddy, etc)
acl webchat dstdomain "/etc/squid/webchat.txt"
# Patrones que identifican al chat MSN

acl msn1 req_mime_type -i âpplication/x-msn-messenger$
acl msn2 url_regex -i gateway.dll
acl msn3 browser -i msnmsgr\.exe Messenger
# Horarios permitidos para el MSN

acl horario-msn time 13:00-14:00
acl horario-msn time 18:00-22:00
# ACLs de control multimedia (musica y video en linea)

acl multimedia-tipos rep_mime_type -i "/etc/squid/multimedia-tipos.txt"
acl multimedia-descargas urlpath_regex -i "/etc/squid/multimedia-descargas.txt"
OpenSourceCollege
Linux for SysAdmins
Página 325
Source Linux
El archivo /etc/squid/webchat.txt al cual se hace referencia en una ACL tendría un contenido como:
.ebuddy.com
.elchat.com
.e-messenger.net
.emessenger.net
.express.instan-t.com
.icq.com
.iloveim.com
.imo.im
.imvu.com
.interlatin.com
.koolim.com
.latinchat.com
.meebo.com
.messengerfx.com
.messenger.yahoo.com
.msn2go.com
.msn2go.com.br
.msn2go.nl
.pager.yahoo.com
.photobucket.com
.pixparty.com
.secretosdelmsn.com
.webmessenger.com
.webmessenger.msn.com
.webmessenger.msn.es
.webmessenger.passport.uni.cc
.imhaha.com
.shttp.msg.yahoo.com
.chatenabled.mail.google.com
.talkgadget.google.com
.pager.yahoo.com
.shttp.msg.yahoo.com
.update.messenger.yahoo.com
El archivo /etc/squid/multimedia-tipos.txt al cual se hace referencia en una ACL tendría un contenido como:
application/vnd.ms.wms-hdr.asfv1
application/vnd.koan
application/x-mms-framed
audio/x-pn-realaudio
audio/mid
audio/mpeg.*
video/flv
video/x-flv
video/x-ms-asf
video/x-ms-asf
video/x-ms-wma
video/x-ms-wmv
video/x-msvideo
video/x-shockwave-flash
El archivo /etc/squid/multimedia-descargas.txt al cual se hace referencia en una ACL tendría un contenido como:
# Muchas de estas extensiones suelen ser utilizadas por sitios Web como Bateriafina,
# Fulltono, entre otros.
\.abc\>
\.asf\>
\.avi\>
\.bat\>
\.m1v\>
\.m3u\>
\.mca\>
\.med\>
\.mid\>
\.midi\>
\.mov\>
\.mp2\>
OpenSourceCollege
Linux for SysAdmins
Página 326
Source Linux
\.mp2v\>
\.mp3\>
\.mpa\>
\.mpe\>
\.mpeg\>
\.mpg\>
\.msi\>
\.ogg\>
\.pps\>
\.skm\>
\.snd\>
\.wma\>
\.wvx\>
+ Creamos la configuración de restricciones de acceso basados en las ACLs previamente creadas:
...
...
# Acceso total a gerencia de acuerdo al requerimiento (e)

http_access allow gerencia
# Acceso por horarios al MSN para empleados según requerimiento (g)

http_access allow empleados msn1 horario-msn
# Acceso a Internet excepto Chat y Multimedia para empleados según requerimiento (f)
http_access allow empleados !msn1 !msn2 !msn3 !webchat !multimedia-descargas
# En conexiones de respuesta HTTP se filtra el trafico multimedia, exonerando a gerentes

# y restringiendo a empleados segun requerimientos (e) y (f)
http_reply_access allow gerencia
http_reply_access deny multimedia-tipos empleados
+ Creamos la configuración de control de ancho de banda:
...
...
# Creamos un único Delay Pool

delay_pools 1
# Definición de las clases de cada Delay Pool

delay_class 1 2
# Parámetros de control de cada Delay Pool definida

delay_parameters 1 -1/-1 30000/30000
# Control de accesos al control de las Delay Pools

delay_access 1 deny gerencia
delay_access 1 allow empleados
+ Luego de guardar los cambios, verificamos la sintaxis, refrescamos los cambios en el servicio Squid en ejecución y
analizamos los logs para depuración tras las pruebas a realizar por parte de los clientes:
# squid -k parse
# squid -k reconfigure
# tail -f /var/log/squid/access.log
OpenSourceCollege
Linux for SysAdmins
Página 327
Source Linux
Unidad 16: Túneles VPN
16.1. Objetivos
✔ Conocer los conceptos básicos de las Redes Privadas Virtuales o VPN.

✔ Saber configurar OpenVPN como servidor VPN sobre un servidor Linux.
✔ Conocer cómo configurar OpenVPN como cliente desde una estación Linux.
✔ Integrar mecanismos de autenticación externa para la conexión a un servidor OpenVPN.
16.2. VPN Open Source, "OpenVPN"

¿Qué es una VPN?
El acrónimo VPN, correspondiente a Virtual Private Network son conocidas a veces también como RPV (Redes Privadas Virtuales). La
VPN es una tecnología de red que permite una extensión de la red local sobre una red pública o no controlada, como por ejemplo
Internet.
El ejemplo más común es la posibilidad de conectar dos o más sucursales de una empresa utilizando como vínculo Internet, permitir a
los miembros del equipo de soporte técnico la conexión desde su casa al centro de cómputo, o que un usuario pueda acceder a su
equipo doméstico desde un sitio remoto, como por ejemplo un hotel. Todo esto utilizando la infraestructura de Internet.
Para hacerlo posible de manera segura es necesario proveer los medios para garantizar la autenticación, integridad y confidencialidad
de toda la comunicación:
 Autenticación y autorización
¿Quién está del otro lado? Usuario/equipo y qué nivel de acceso debe tener
 Integridad
La garantía de que los datos enviados no han sido alterados. Para ello se utiliza un metodo de comparación (Hash).Los
algoritmos comunes de comparacion son Message Digest(MD) y Secure Hash Algorithm (SHA).
 Confidencialidad
Dado que los datos viajan a través de un medio potencialmente hostil como Internet, los mismos son susceptibles de
intercepción, por lo que es fundamental el cifrado de los mismos. De este modo, la información no debe poder ser
interpretada por nadie más que los destinatarios de la misma.Se hace uso de algoritmos de cifrado como Data Encryption
Standard (DES),Triple DES(3DES) y Advanced Encryption Standard (AES).
 No repudio
Es decir un mensaje tiene que ir firmado, y el que lo firma no puede negar que el mensaje lo envió él.
Requerimientos Básicos
 Identificación de Usuario
Las VPN's (Redes Virtuales Privadas) deben verificar la identidad de los usuarios y restringir su acceso a aquellos que no
se encuentren autorizados.
 Codificación de Datos
Los datos que se van a transmitir a través de la red pública (Internet), antes deben ser cifrados, para que así no puedan
ser leídos. Esta tarea se realiza con algoritmos de cifrado como DES o 3DES.
 Administración de claves
Las VPN's deben actualizar las claves de cifrado para los usuarios.
 Soporte a protocolos múltiples

Las VPN's deben manejar los protocolos comunes, como son el Protocolo de Internet (IP), intercambio de paquetes
interred (IPX), etc.
Tipos de VPN
Básicamente existen tres arquitecturas de conexión VPN:
VPN de acceso remoto

Éste es quizás el modelo más usado si actualmente y consiste en usuarios o proveedores que se conectan con la empresa desde
sitios remotos (oficinas comerciales, domicilios, hotel, aviones, etcétera) utilizando Internet como vínculo de acceso. Una vez
autenticados tienen un nivel de acceso muy similar al que tienen en la red local de la empresa. Muchas empresas han reemplazado
con esta tecnología su infraestructura 'dial-up' (módems y líneas telefónicas), aunque por razones de contingencia todavía
OpenSourceCollege
Linux for SysAdmins
Página 328
Source Linux
conservan sus viejos modems. Existen excelentes equipos en el mercado.
VPN punto a punto

Este esquema se utiliza para conectar oficinas remotas con la sede central de organización. El servidor VPN, que posee un vínculo
permanente a Internet, acepta las conexiones vía Internet provenientes de los sitios y establece el túnel VPN. Los servidores de las
sucursales se conectan a Internet utilizando los servicios de su proveedor local de Internet, típicamente mediante conexiones de
banda ancha. Esto permite eliminar los costosos vínculos punto a punto tradicionales, sobre todo en las comunicaciones
internacionales.... Es más común el punto anterior, también llamada tecnología de túnel o tunneling:
Tunneling
Internet se construyó desde un principio como un medio inseguro. Muchos de los protocolos utilizados hoy en día para transferir
datos de una máquina a otra a través de la red carecen de algún tipo de cifrado o medio de seguridad que evite que nuestras
comunicaciones puedan ser interceptadas y espiadas. HTTP, FTP, POP3 y otros muchos protocolos ampliamente usados, utilizan
comunicaciones que viajan en claro a través de la red. Esto supone un grave problema, en todas aquellas situaciones en las que
queremos transferir entre máquinas información sensible, como pueda ser una cuenta de usuario (nombre de usuario y
contraseña), y no tengamos un control absoluto sobre la red, a fin de evitar que alguien pueda interceptar nuestra comunicación
por medio de la técnica del hombre en el medio (man in the middle), como es el caso de la Red de redes.
¿Qué es el tunneling?
El problema de los protocolos que envían sus datos en claro, es decir, sin cifrarlos, es que cualquier persona que tenga acceso
físico a la red en la que se sitúan nuestras máquinas puede ver dichos datos. Es tan simple como utilizar un sniffer, que
básicamente, es una herramienta que pone nuestra tarjeta de red en modo promiscuo (modo en el que las tarjetas de red operan
aceptando todos los paquetes que circulan por la red a la que se conectan, sean o no para esa tarjeta). De este modo, alguien que
conecte su máquina a una red y arranque un sniffer recibirá y podrá analizar por tanto todos los paquetes que circulen por dicha
red. Si alguno de esos paquetes pertenece a un protocolo que envía sus comunicaciones en claro, y contiene información sensible,
dicha información se verá comprometida. Si por el contrario, ciframos nuestras comunicaciones con un sistema que permita
entenderse sólo a las dos máquinas que queremos sean partícipes de la comunicación, cualquiera que intercepte desde una
tercera máquina nuestros paquetes, no podrá hacer nada con ellos, al no poder descifrar los datos. Una forma de evitar el
problema que nos atañe, sin dejar por ello de utilizar todos aquellos protocolos que carezcan de medios de cifrado, es usar una útil
técnica llamada tunneling. Básicamente, esta técnica consiste en abrir conexiones entre dos máquinas por medio de un protocolo
seguro, como puede ser SSH (Secure SHell), a través de las cuales realizaremos las transferencias inseguras, que pasarán de
este modo a ser seguras. De esta analogía viene el nombre de la técnica, siendo la conexión segura (en este caso de ssh) el túnel
por el cual enviamos nuestros datos para que nadie más aparte de los interlocutores que se sitúan a cada extremo del túnel, pueda
ver dichos datos. Ni que decir tiene, que este tipo de técnica requiere de forma imprescindible que tengamos una cuenta de acceso
seguro en la máquina con la que nos queremos comunicar.
VPN interna WLAN

Este esquema es el menos difundido pero uno de los más poderosos para utilizar dentro de la empresa. Es una variante del tipo
"acceso remoto" pero, en vez de utilizar Internet como medio de conexión, emplea la misma red de área local (LAN) de la empresa.
Sirve para aislar zonas y servicios de la red interna. Esta capacidad lo hace muy conveniente para mejorar las prestaciones de
seguridad de las redes inalámbricas (WiFi).
Un ejemplo muy clásico es un servidor con información sensible, como las nóminas de sueldos, ubicado detrás de un equipo VPN,
el cual provee autenticación adicional más el agregado del cifrado, haciendo posible que sólo el personal de RRHH habilitado
pueda acceder a la información.
¿Por qué VPN?
Coste
La principal motivación del uso y difusión de esta tecnología es la reducción de los costos de comunicaciones directos, tanto en
líneas dial-up como en vínculos WAN dedicados. Los costos se reducen drásticamente en estos casos:
• En el caso de accesos remotos, llamadas locales a los ISP (Internet Service Provider) en vez de llamadas de larga
distancia a los servidores de acceso remoto de la organización. O también mediante servicios de banda ancha.
• En el caso de conexiones punto a punto, utilizando servicios de banda ancha para acceder a Internet, y desde Internet
llegar al servidor VPN de la organización. Todo esto a un costo sensiblemente inferior al de los vínculos WAN dedicados.
Ancho de banda
Podemos encontrar otra motivación en el deseo de mejorar el ancho de banda utilizado en conexiones dial-up. Las conexiones
VPN de banda ancha mejoran notablemente la capacidad del vínculo, pero los costos son más altos.
Implementaciones
Todas las opciones disponibles en la actualidad caen en tres categorías básicas: soluciones de hardware, soluciones basadas en
cortafuegos y aplicaciones VPN por software.
El protocolo estándar de hecho es el IPSEC, pero también tenemos PPTP, L2F, L2TP, SSL/TLS, SSH, etc. Cada uno con sus ventajas y
desventajas en cuanto a seguridad, facilidad, mantenimiento y tipos de clientes soportados.
Actualmente hay una línea de productos en crecimiento relacionada con el protocolo SSL/TLS, que intenta hacer más amigable la
configuración y operación de estas soluciones.
• Las soluciones de hardware casi siempre ofrecen mayor rendimiento y facilidad de configuración, aunque no tienen la
OpenSourceCollege
Linux for SysAdmins
Página 329
Source Linux
flexibilidad de las versiones por software. Dentro de esta familia tenemos a los productos de Nortel, Cisco, Linksys,
Netscreen, Symantec, Nokia, US Robotics, D-link etc.
• En el caso basado en cortafuegos, se obtiene un nivel de seguridad alto por la protección que brinda el cortafuegos, pero se
pierde en rendimiento. Muchas veces se ofrece hardware adicional para procesar la carga VPN. Por ejemplo: Checkpoint
NG, Cisco Pix.
• Las aplicaciones VPN por software son las más configurables y son ideales cuando surgen problemas de interoperatividad en
los modelos anteriores. Obviamente el rendimiento es menor y la configuración más delicada, porque se suma el sistema
operativo y la seguridad del equipo en general. Aquí tenemos por ejemplo a las soluciones nativas de Windows, Linux y los
Unix en general. Por ejemplo productos de código abierto (Open Source) como OpenSSH, OpenVPN y FreeS/Wan.
Ventajas
• Una de sus ventajas más importantes es su integridad, confidencialidad y seguridad de datos.

• Las VPN´s reducen costos y son sencillas de usar.
• Su instalación es sencilla en cualquier PC.
• Su control de acceso esta basado en políticas de la organización.
• Los algoritmos de compresión que utiliza una VPN optimizan el tráfico del usuario.
• Las VPN´s evitan el alto costo de las actualizaciones y mantenimiento de PC's remotas.
• Las VPN´s ahorran en costos de comunicaciones y en costes operacionales.
• Los trabajadores, mediante el uso de las VPN´s, pueden acceder a los servicios de la compañía sin necesidad de llamadas.
• Una organización puede ofrecer servicios a sus socios mediante VPN´s, ya que éstas permiten acceso controlado y brindan
un canal seguro para compartir la información de las organizaciones..
Tipos de Conexión
Conexión de Acceso Remoto

Una conexión de acceso remoto es realizada por un cliente o un usuario de un computador que se conecta a una red privada, los
paquetes enviados a través de la conexión VPN son originados al cliente de acceso remoto, y este se autentica al servidor de
acceso remoto, y el servidor se autentica ante el cliente.
Conexión VPN Router a Router

Una conexión VPN router a router es realizada por un router, y este a su vez se conecta a una red privada. En este tipo de
conexión, los paquetes enviados desde cualquier router no se originan en los routers. El router que realiza la llamada se autentica
ante el router que responde y este a su vez se autentica ante el router que realiza la llamada.
Instalación de OpenVPN
OpenVPN puede por lo general puede ser instalado desde los repositorios de software que provee la distribución Linux usada.
En Red Hat / CentOS y derivados, se requiere que se tenga configurado el repositorio DAG (http://dag.wieers.com) y proceder como
sigue:
# yum install openvpn -y
En Debian y derivados, OpenVPN ya está incluido en los repositorios oficiales por lo que la instalación debe ser directa como sigue:
# apt-get install openvpn -y
Modo de funcionamiento
OpenVPN posee dos modos de funcionamiento: Enrutado y Puente, a los cuales los conoceremos como modo Routing y modo
Ethernet Bridging.
Puede entenderse un poco las diferencias entre ambos modos de funcionamiento con la siguiente comparativa:
Ventajas del modo Bridging:
• El tráfico broadcast a través de la VPN: esto permite el correcto funcionamiento de software que depende del tráfico
broadcast en redes LAN tal como la navegación a través de redes Microsoft conocido comúnmente como network
browsing.
• No es necesario configurar reglas de enrutamiento.
• Funciona con cualquier protocolo sobre Ethernet incluyendo IPv4, IPv6, Netware IPX, AppleTalk, etc.
• La configuración de road warriors es relativamente más sencilla.
Desventajas del modo Bridging:
• Menos eficiente que el modo Routing, y no es muy escalable.
OpenSourceCollege
Linux for SysAdmins
Página 330
Source Linux
Ventajas del modo Routing:
• Eficiencia y escalabilidad.
• Permite mejor afinamiento del MTU para mejorar la eficiencia.
Desventajas del modo Routing:
• Los clientes deben usar un servidor WINS para pemitir la resolución de nombres NetBIOS entre ordenadores que estén a
ambos extremos de los túneles VPN.
• Deben configurarse reglas de enrutamiento en cada subred.
• Software que dependa del tráfico broadcast no será capaz de encontrar a los hosts al otro lado de los túneles VPN.
• Funciona solamente con IPv4 en general, e IPv6 en casos donde los drivers TUN en ambos extremos de los túneles
soporten dicho protocolo de manera explícita.
Este documento cubre sólo la configuración de OpenVPN en modo Routing, el cual es uno de los modos más comunes para
configurar VPNs.
Numeración de redes
La IANA ha reservado los siguientes tres bloques de direcciones IP para ser usadas en redes privadas:
10.0.0.0 10.255.255.255.0 Prefijo 10/8

172.16.0.0 172.31.255.255 Prefijo 172.16/12
192.168.0.0 192.168.255.255 Prefijo 192.168/16
Mientras que las direcciones de estos bloques deberían normalmente ser usadas en las configuraciones de VPNs es importante
seleccionar direcciones que minimicen las posibilidades de conflictos con los rangos usados en las redes privadas. Los conflictos
que deben ser evitados son:
• Conflictos de diferentes sitios en la VPN usando la misma numeración de red que la LAN.
• Conexiones de acceso remoto desde sitios que usen la misma numeración de red que las subredes usadas por la VPN.
Por ejemplo suponga que Ud. usa la red 192.168.1.0/24 para su red LAN. Luego imagine que intenta conectarse a través de VPN
desde un cybercafé que está usando las mismas direcciones de 192.168.1.0/24 para su red Wi-Fi. Con esta situación se presentará
un conflicto porque un ordenador de su red privada no sabrá si 192.168.1.1 es el gateway de la red Wi-Fi del cybercafé o se trata
acaso de la IP asignada al servidor VPN.
La mejor solución para evitar estos conflictos es procurar no numerar sus redes con direcciones contenidas en el rango 10.0.0.0/24
ó 192.168.1.0/24.
Configuración de OpenVPN
Paso 1: Construcción de certificados

El primer paso para construir una configuración de OpenVPN basada en certificados es establecer un PKI (Public Key Infrastructure).
El PKI consiste de:
✔ Un certificado (conocido también como llave pública) y llave privada separado para cada cliente y el servidor.
✔ Un Certificado Autoridad maestro (CA, Certificate Authority) y su respectiva llave privada usada para firmar cada certificado
usado por los clientes y el servidor.
OpenVPN soporta autenticación bidireccional basada en certificados; es decir el cliente debe autenticarse al certificado del servidor y el
servidor debe autenticare al certificado del cliente, antes que una confianza mutua pueda ser establecida.
Tanto el servidor como el cliente se autenticarán el uno al otro primero verificando que el certificado presentado ha sido firmado por el
CA, y luego evaluando información en las cabeceras del certificado tal como el Common Name o el tipo del certificado (cliente o
servidor).
Este modelo de seguridad tiene un número de funcionalidades deseables desde la perspectiva VPN:
• El servidor solamente necesita su propio par certificado/llave. No necesita conocer los certificados individuales de cada
cliente que se va a conectar a él.
• El servidor solamente aceptará clientes cuyos certificados han sido firmados por el Certificado Autoridad maestro, CA (el cual
ahora generaremos). Y debido a que el servidor no necesita acceder a la llave privada del CA para verificar los certificados de
clientes es posible entonces que dicha llave privada pueda residir en otra máquina por razones de seguridad incluso sin
conexión a red.
• Si una llave privada es comprometida, puede ser deshabilitada simplemente agregando su certificado correspondiente a una
OpenSourceCollege
Linux for SysAdmins
Página 331
Source Linux
lista de revocación de certificados, CRL (Certificate Revocation List). El CRL permite que los ciertos certificados
comprometidos previamente seleccionados sean simplemente rechazados ante cualquier intento de conexión.
1.1. Generación del CA y su llave privada:

La distribución original en tarball de OpenVPN incluye un directorio de nombre 'easy-rsa' dentro del cual procederemos a
ejecutar los pasos que a continuación se explicarán.
En aquellos casos que se ha instalado OpenVPN desde binarios propios de la distribución Linux es común encontrar este directorio
dentro de la documentación del paquete, por lo general bajo /usr/share/doc/openvpn o /usr/share/doc/packages/openvpn.
Una vez dentro del directorio easy-rsa encontraremos un archivo de nombre vars el cual debemos editar y modificar algunos
valores como los que se aprecian a continuación:
export KEY_SIZE=1024
export KEY_COUNTRY=PE
export KEY_PROVINCE=LI
export KEY_CITY=Lima
export KEY_ORG="Consultorianet"
export KEY_EMAIL="soporte@consultorianet.com"
Si se observa con cuidado el contenido del archivo se puede comprender que se definen variables las cuales deben ser cargadas
para ser usadas posteriormente en la construcción del certificado pudiendo tener valores a gusto y criterio del administrador pero
recordando que ninguno de ellos debe ser dejado en blanco.
Entonces se procede a cargar las variables del archivo recién editado:
# source vars
Ahora se procederá a ejecutar el script clean-all dentro del mismo directorio. Este script se encargará de eliminar el directorio
$KEY_DIR si éste ya existiese y sino lo eliminará con todo su contenido actual para crearlo nuevamente.
Así que ejecutamos:
# ./clean-all
Si todo hasta ahora se ha ejecutado correctamente deberíamos poder constatar la existencia de un directorio con el nombre de la
variable KEY_DIR (Probar: echo $KEY_DIR).
Ahora es cuando ya se procederá a crear el CA ejecutando el script build-ca y nos hará algunas preguntas de las cuales algunas ya
tendrán los valores precargados del archivo de configuración vars previamente editado y pueden aceptarse como respuesta
presionando Enter, y otras opciones aún por rellenar con los valores apropiados como sigue:
# ./build-ca
.......++++++
..++++++
writing new private key to 'ca.key'
-----
-----
State or Province Name (full name) [LI]:[Enter]
Organization Name (eg, company) [Consultorianet]:[Enter]
Organizational Unit Name (eg, section) []:sistemas
Common Name (eg, your name or your server's hostname) []:www.consultorianet.com
Email Address [soporte@consultorianet.com]:[Enter]
Luego de esto puede verificarse dentro del directorio $KEY_DIR la existencia de los archivos ca.crt (el CA) y ca.key (la llave privada
del CA). Hasta este punto ya se ha creado correctamente el CA con su respectiva llave privada la misma que debe ser mantenida
en la más absoluta privacidad por razones de seguridad obvias.
1.2. Generación del archivo de parámetros Diffie Hellman:

El protocolo Diffie-Hellman permite el intercambio secreto de claves entre dos partes que no han tenido contacto previo, utilizando
OpenSourceCollege
Linux for SysAdmins
Página 332
Source Linux
un canal inseguro, y de manera anónima (no autenticada).
Se emplea generalmente como medio para acordar claves simétricas que serán empleadas para el cifrado de una sesión. Siendo
no autenticado, sin embargo provee las bases para varios protocolos autenticados.
Por lo tanto es necesario generar un archivo que contenga los parámetros correspondientes del protocolo desde el mismo
directorio de trabajo usado anteriormente para la generación de la CA.
Para ello debe ejecutarse el script build-dh como sigue:
# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
.....+........................................+.........................
+...................................................+........................+.....
+................................................................................................
............................................+...................
+..........................................................................................
+........+.....
+................................................................................................
.........+..................................................+...+.......
+..................................................................+......
+..........................
+................................................................................................
.......................+..........
+................................................................................................
....+...+.............................................................................
+.....................................................................................+.....
+..........................................+....................++*++*++*
Si todo ha funcionado correctamente debería haberse creado el archivo dh1024.pem (u otro número distinto de 1024 dependiendo
del valor de KEY_SIZE en el archivo vars).
1.3. Generación del certificado del servidor y su llave privada:

Ahora se requiere generar un certificado con su respectiva llave privada para el servidor ejecutando el script build-key-server
pasándole como parámetro un nombre representativo para el servidor VPN como se aprecia a continuación:
# ./build-key-server vpn-server
....................................++++++
.++++++
writing new private key to 'vpn-server.key'
-----
-----
Organization Name (eg, company) [Soporte Linux]:[Enter]
Common Name (eg, your name or your server's hostname) []:vpn-server

A challenge password []:[Enter]
Using configuration from /root/easy-rsa/openssl.cnf
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'PE'
stateOrProvinceName :PRINTABLE:'LI'
localityName :PRINTABLE:'Lima'
organizationName :PRINTABLE:'Soporte Linux'
organizationalUnitName:PRINTABLE:'sistemas'
commonName :PRINTABLE:'vpn-server'
emailAddress :IA5STRING:'soporte@consultorianet.com'
Certificate is to be certified until Aug 18 22:09:07 2017 GMT (3650 days)
OpenSourceCollege
Linux for SysAdmins
Página 333
Source Linux

Data Base Updated
Es indispensable que el valor del Common Name en la creación del certificado sea el mismo que el pasado como parámetro al
script.
Si todo ha funcionado como debe ser se habrán creado un par de archivos de extensión .crt y .key dentro del directorio $KEY_DIR
con el nombre especificado como parámetro al script, resultando en nuestro ejemplo vpn-server.crt y vpn-server.key
Observaciones:
 Hasta este punto ya se ha creado el CA, el certificado del servidor y el archivo de parámetros Diffie Hellman pero debe
considerarse que este proceso debe ser ejecutado solamente una única vez, por ello hay que ser cuidadosos de no
ejecutar nuevamente el script clean-all si antes no se ha hecho un respaldo del contenido del directorio $KEY_DIR.
 Si se desean generar certificados para los clientes en un futuro hay que considerar que deben cargarse las variables de
entorno desde el archivo vars usando el comando source.
1.4. Creación de certificados de clientes y sus llaves privadas:

La creación de los certificados de clientes puede hacerse en dos pasos de los cuales el primero consiste en crear una solicitud de
certificado y la segunda consiste en la firma de dicha solicitud para generar al fin el certificado del cliente.
Para ello debe usarse el script build-req ó build-req-pass. La diferencia de usar uno u otro consiste en que el segundo protegerá la
llave privada con una contraseña para mayor seguridad en caso de robo del certificado y su llave. De este modo tendríamos lo
siguiente:
# ./build-req-pass cliente0
..........++++++
..................................................................++++++
writing new private key to 'cliente0.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
-----
Organization Name (eg, company) [Soporte Linux]:[Enter]
Common Name (eg, your name or your server's hostname) []:cliente0

A challenge password []:[Enter]
Recordar que también el valor del Common Name debe ser el mismo que se pasó como parámetro al script. Si todo ha funcionado
como se espera entonces se debe haber creado un archivo de extensión .key y otro de extensión .csr dentro del directorio
$KEY_DIR con el nombre especificado para el cliente, mas no ninguno de extensión .crt todavía.
Es ahora cuando ya se puede proceder a firmar la solicitud de certificado del cliente ejecutando el script sign-req pasándole como
parámetro el nombre anteriormente dado al cliente. Veamos como sería según nuestra solicitud de cliente antes creada:
# ./sign-req cliente0
Using configuration from /root/easy-rsa/openssl.cnf
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'PE'
stateOrProvinceName :PRINTABLE:'LI'
localityName :PRINTABLE:'Lima'
OpenSourceCollege
Linux for SysAdmins
Página 334
Source Linux
organizationName :PRINTABLE:'Soporte Linux'
organizationalUnitName:PRINTABLE:'sistemas'
commonName :PRINTABLE:'cliente0'
emailAddress :IA5STRING:'soporte@consultorianet.com'
Certificate is to be certified until Aug 18 22:35:26 2017 GMT (3650 days)

Data Base Updated
Con esto ya deberíamos ahora sí tener un archivo de extensión .crt con el nombre del cliente dentro del directorio $KEY_DIR.
Es así que se concluye el proceso de creación de certificados y llaves para los clientes y/o el servidor. A continuación se procederá a
entrar ya en detalle de la sintaxis y directivas de los archivos de configuración de OpenVPN.
Observaciones:
 OpenVPN no tiene una configuración centralizada en un único archivo como sí sucede con Squid por ejemplo. En cambio
OpenVPN mantiene uno o más archivos de configuración independientes para cada instancia del servicio que puede
comportarse como cliente o como servidor dependiendo directamente de la naturaleza de sus directivas de configuración
dentro del archivo.
La manera de lanzar una instancia de OpenVPN con un archivo de configuración específico es como sigue:
# openvpn -–config <ARCHIVO>
Donde ARCHIVO es la ruta absoluta a un archivo de texto plano que contiene las directivas de configuración.
Si bien es esta una manera correcta de hacer las cosas no es la más cómoda debido a que ahora ya todas las distribuciones
Linux cuentan con un script de administración del servicio OpenVPN dentro del directorio /etc/init.d el cual por defecto tratará
de levantar tantas instancias del servicio como archivos de extensión .conf encuentre dentro de /etc/openvpn.
 Las directivas de configuración de OpenVPN tienen una sintaxis sencilla como se muestra a continuación:
directiva VALOR
 Como en muchos otros ficheros de configuración las líneas que contengan el símbolo # serán tratadas como comentarios e
ignoradas por OpenVPN como directivas de configuración así como también las líneas en blanco.
2. Directivas de configuración de OpenVPN
Configuración en modo servidor

OpenVPN en modo servidor requiere la definición de algunas directivas que pueden no estar presentes en una configuración en
modo cliente, y a la vez éstas diferir de otras configuraciones de OpenVPN en modo Bridging por ejemplo.
Se entiende entonces que las directivas explicadas a continuación son las necesarias para armar una configuración correcta de
OpenVPN en modo servidor basado en certificados digitales.
dev
Directiva que especifica el tipo y/o nombre del dispositivo usado para establecer las conexiones entre los túneles VPN. OpenVPN
en modo Routing usa los dispositivos TUN mientras que en modo Bridging usa los dispositivos TAP.
Puede indicarse simplemente un valor como tun o adicionarle un número al final para definir de manera explícita el orden del
dispositivo que usará dicha instancia de configuración.
Dos instancias de OpenVPN no pueden tener el mismo nombre de dispositivo (como por ejemplo ambas usando tun1), sino cada
una un dispositivo diferente tal como tun1 y tun2.
Si a cada instancia se le configura simplemente tun como nombre de dispositivo entonces OpenVPN asignará automáticamente
un número libre según los que se encuentren disponibles en el momento de la inicialización de cada instancia a fin de evitar
conflictos.
Sintaxis: dev dispositivo
Ejemplo:
dev tun
port
Puerto de escucha del servicio OpenVPN. Por defecto es 1194 en la versión 2.0 del software pero puede tener cualquier otro valor
OpenSourceCollege
Linux for SysAdmins
Página 335
Source Linux
distinto.
Sintaxis: port puerto
Ejemplo:
port 1194
proto
Naturaleza del protocolo a usar para las conexiones. Por defecto es UDP si no se especifica lo contrario. Sin embargo OpenVPN
fue diseñado para trabajar óptimamente sobre UDP pero el soporte para TCP existe para aquellas situaciones en las que por
razones diversas UDP no sea posible usarlo.
En modo TCP el servicio es menos eficiente y requerirá que la directiva contenga tcp-server o tcp-client como valor
dependiendo si se trata de una configuración para servidor o cliente respectivamente.
Sintaxis: proto udp|tcp-server|tcp-client
Ejemplo:
proto udp
user/group
Usuario y grupo bajo el cual correrá el servicio OpenVPN. Por defecto se inician con los privilegios de root para tener acceso de
lectura a ciertos archivos protegidos y también tener acceso de escritura a directorios del sistema; sin embargo una vez
completadas las labores que requieren estos privilegios durante la inicialización entonces automáticamente se degradarán hasta un
usuario/grupo corriente del sistema especificado en esta directiva.
Sintaxis: user usuario

Sintaxis: group grupo
Ejemplo:
user nobody
group nogroup
comp-lzo
Habilita la compresión del tráfico que pasa por el túnel.
Sintaxis: comp-lzo
verb
Nivel de registro en los logs. Puede tomar los siguientes valores:
0: Silencioso excepto errores fatales

1: Mayormente silencioso, pero muestra errores no fatales de red
3: Información moderada, bueno para un funcionamiento normal
9: Muy informativo, adecuado para depuración
Sintaxis: verb numero
Ejemplo:
verb 3
log/log-append
Ruta al archivo de registro del funcionamiento de OpenVPN. Ambas opciones son excluyentes pues mientras que la primera
directiva reescribirá un archivo de log ya existente en cada inicio del servicio OpenVPN, la segunda directiva escribirá al final de un
archivo de log ya existente. Si el archivo de log no existe en ambos casos lo creará antes de escribir en él.
Sintaxis: log ruta_archivo

Sintaxis: log-append ruta_archivo
OpenSourceCollege
Linux for SysAdmins
Página 336
Source Linux
Ejemplos excluyentes:
log /var/log/openvpn/vpn-server.log
log-append /var/log/openvpn/vpn-server.log
ping
Los firewalls basados en estado pueden bloquear las conexiones VPN si no detectan tráfico durante un lapso de tiempo. Por eso
esta directiva en momentos de inactividad mantendrá un refresco de la conexión cada cierta cantidad de segundos según se
especifique en su valor.
Sintaxis: ping numero
Ejemplo:
ping 15
ping-restart
Enviar la señal SIGUSR1 para reiniciar el servicio si no se ha recibido respuesta luego de una cantidad de segundos desde el
último ping. En modo servidor no se reinicia todo el servicio entero de OpenVPN sino solamente la instancia específica del cliente
con el cual se perdió la conexión.
Sintaxis: ping-restart numero
Ejemplo:
ping-restart 60
persist-tun
Esta directiva evita cerrar y volver a abrir los dispositivos TUN/TAP, o volver a ejecutar los scripts de las directivas up/down al
recibir la señal SIGUSR1 o luego de un reinicio de la directiva ping-restart.
Sintaxis: persist-tun
persist-key
Esta directiva evita volver a leer los archivos de llaves luego de recibir una señal SIGUSR1 o luego de un reinicio de la directiva
ping-restart. Opción útil si se cambian los privilegios del servicio con la directiva user/group y dicho usuario/grupo no tiene
los permisos suficientes de leer el archivo de llaves que en un principio fue leído con privilegios de root. El servicio no puede ser
reiniciado con SIGUSR1 y a la vez retomar privilegios de root.
Sintaxis: persist-key
cipher
Algoritmo usado para la encriptación de tráfico. El comando openvpn --show-ciphers muestra un listado de los algoritmos
disponibles.
Sintaxis: cipher algoritmo
En ejemplo siguiente se usa el algoritmo Blowfish:
cipher BF-CFC
ping-timer-rem
La verificación de conexiones activas de las dos directivas anteriores no tendría sentido si el servicio se inicia en modo servidor y
no existe ningún cliente iniciando conexiones. Para no gastar esfuerzos en reconexiones persistentes con clientes que aún no
existen es que debe incluirse esta directiva.
Sintaxis: ping-timer-rem
OpenSourceCollege
Linux for SysAdmins
Página 337
Source Linux
* Directiva no válida para conexiones en modo cliente.
tls-server
Asigna el papel de servidor a la instancia OpenVPN para las sesiones SSL/TLS.
Sintaxis: tls-server
dh
Define la ruta al archivo que contiene los parámetros Diffie Hellman.
Sintaxis: dh ruta_archivo
Ejemplo:
dh /etc/openvpn/keys/dh1024.pem
ca
Define la ruta del certificado maestro CA.
Sintaxis: ca ruta_archivo
Ejemplo:
ca /etc/openvpn/keys/ca.crt
cert
Define la ruta del certificado usado por el servidor.
Sintaxis: cert ruta_archivo
Ejemplo:
cert /etc/openvpn/keys/vpn-server.crt
key
Define la ruta de la llave privada correspondiente al certificado usado por el servidor.
Sintaxis: key ruta_archivo
Ejemplo:
key /etc/openvpn/keys/vpn-server.key
server
Configura el servicio OpenVPN en modo servidor y configura una subred para brindar direcciones IP virtuales a los extremos de los
túneles clientes. El servidor tomará por defecto la primera dirección disponible en el rango definido en la directiva y los clientes
tomarán el resto de direcciones restantes.
Sintaxis: server red mascara
Ejemplo:
server 10.255.255.0 255.255.255.0
OpenSourceCollege
Linux for SysAdmins
Página 338
Source Linux
push
Envía algunas opciones de configuración de OpenVPN al cliente que se conecte de modo que éste modifique la forma de
funcionamiento respecto a parámetros de red. Una opción bastante común a usar es --route que permite decirle a los clientes
qué ruta agregar a su tabla de enrutamiento para poder llegar a la LAN detrás del servidor VPN. Otras opciones posibles que se
pueden usar en esta directiva esta documentadas en openvpn(8).
Sintaxis: push "opciones"
En el ejemplo se tiene que la red 192.168.3.0/24 es la que está detrás del servidor OpenVPN y se le indica al cliente que agregue
la ruta correspondiente a su tabla de enrutamiento:
push "route 192.168.3.0 255.255.255.0"
ifconfig-pool-persist
Ruta a un archivo en el cual se mantendrá un pool de las direcciones IP virtuales asociadas a cada cliente para restaurarles las
mismas direcciones a los clientes en caso de que OpenVPN sea reiniciado.
Sintaxis: ifconfig-pool-persist ruta_archivo
Ejemplo:
ifconfig-pool-persist /etc/openvpn/ipp.txt
plugin
Ruta a un archivo en al cual OpenVPN invocará cada vez que un usuario remoto intente autenticarse con un usuario y password
para así autorizar la conexión dependiendo del éxito de la validación de credenciales.
Sintaxis: plugin ruta_archivo
Ejemplo:
plugin /usr/lib/openvpn/openvpn-auth-pam.so
Ahora pasamos a resumir nuestra configuración en un archivo modelo como el siguiente al cual se le han removido los
comentarios:
# /etc/openvpn/vpn-server.conf
dev tun
port 1194
proto udp
server 10.255.255.0 255.255.255.0
push "route 192.168.3.0 255.255.255.0"
ifconfig-pool-persist ipp.txt
cert /etc/openvpn/keys/vpn-server.crt
key /etc/openvpn/keys/vpn-server.key
cipher BF-CBC
tls-server
user nobody
group nogroup
comp-lzo
ping 15
ping-restart 60
ping-timer-rem
persist-tun
persist-key
verb 3
log-append /var/log/openvpn/vpn-server.log
OpenSourceCollege
Linux for SysAdmins
Página 339
Source Linux
Configuración en modo cliente
OpenVPN en modo cliente requiere la definición de algunas directivas que ya han sido estudiadas en una configuración en modo
servidor, restándole algunas y agregándole otras tantas.
Por lo tanto se procede a continuación a detallar las directivas antes no estudiadas y al final se presentará a modo de resumen una
configuración modelo de OpenVPN cliente donde podrá apreciarse qué directivas ya no están presentes respecto a la configuración
anterior.
remote
Esta directiva permite especificar el servidor y puerto al que OpenVPN se conectará. Si no se especifica el puerto se asumirá el
1194.
Sintaxis: remote servidor puerto
Ejemplo:
remote 190.41.41.92 1194
* Directiva no válida para conexiones en modo servidor.
pull
Esta directiva le dice a la instancia OpenVPN cliente que debe solicitar la entrega de parámetros de configuración por parte del
servidor en el otro extremo del túnel. De no usar esta directiva entonces no podrán agregarse automáticamente las rutas en el
sistema que permitirán encaminar paquetes hacia la red LAN detrás del servidor OpenVPN al cual se acaba de conectar.
Sintaxis: pull
tls-client
Asigna el papel de cliente a la instancia OpenVPN para las sesiones SSL/TLS.
Sintaxis: tls-client
cert/key
Estas directivas fueron ya estudiadas anteriormente pero se les menciona nuevamente para recalcar que ahora deben apuntar al
certificado del cliente firmado anteriormente por el CA y su llave privada respectiva.
Sintaxis: cert/key ruta_archivo
Ejemplo:
cert /etc/openvpn/keys/cliente0.crt
key /etc/openvpn/keys/cliente0.key
auth-user-pass
Estas directiva instruye a OpenVPN a solicitar credenciales de autenticación al usuario que se conecta para validar así la conexión
con el servidor.
Sintaxis: auth-user-pass
Ejemplo:
auth-user-pass
Ahora pasamos a resumir nuestra configuración en un archivo modelo como el siguiente al cual se le han removido los
comentarios:
# /etc/openvpn/cliente0.conf
dev tun
OpenSourceCollege
Linux for SysAdmins
Página 340
Source Linux
port 1194
proto udp
remote 190.41.41.92 1194
pull
tls-client
cert /etc/openvpn/keys/cliente0.crt
key /etc/openvpn/keys/cliente0.key
cipher BF-CBC
user nobody
group nogroup
comp-lzo
ping 15
ping-restart 60
persist-tun
persist-key
verb 3
log-append /var/log/openvpn/cliente0.log
Asumiendo que el cliente que se ha de conectar se conectará desde una plataforma Windows, el archivo de configuración debería
ser creado dentro del directorio C:\Archivos de programa\OpenVPN\config con una extensión .ovpn con un contenido muy similar como
el siguiente:
dev tun
port 1194
proto udp
remote 190.41.41.92 1194
pull
tls-client
cert cliente0.crt
key cliente0.key
cipher BF-CBC
user nobody
group nogroup
comp-lzo
ping 15
ping-restart 60
persist-tun
persist-key
verb 3
Observación:
• En una configuración de OpenVPN sobre plataforma Windows, la directiva log-append o log no deben ser utilizadas ya que
ésta son válidas solamente para plataformas Linux.
• Las directivas cert y key no especifican rutas absolutas de los archivos cliente0.crt y/o cliente0.key por lo que por defecto
OpenVPN asumirá que están ubicados en el mismo directorio que el archivo de configuración, es decir dentro de C:\Archivos
de programa\OpenVPN\config.
• Es recomendable que el archivo de configuración de OpenVPN para Windows sea creado dentro de esta misma plataforma
usando algún programa como notepad.exe o si se crea desde Linux se tenga en cuenta realizar la conversión de los saltos
de línea usando el comando unix2dos. Esto es debido a que el salto de línea usado en UNIX/Linux es el caracter LF y en
DOS/Windows es CR+LF.
Hasta aquí se cubre algunas de las directivas básicas más comunes para conseguir una correcta configuración de OpenVPN como
cliente y servidor usando certificados digitales. Sin embargo muchas otras opciones que pueden ser de interés para el lector pueden
ser encontradas en openvpn(8).
Se da por entendido que cada archivo de configuración debe ser instalado en diferentes ordenadores de modo tal que se lleve a la
práctica la relación cliente/servidor entre puntos remotos.
Arranque de OpenVPN
Una vez concluida la elaboración correcta de los archivos de configuración de OpenVPN debe iniciarse éste a través del script
correspondiente que se encuentre en /etc/init.d.
Dependiendo de la distribución Linux con la que se trabaje las siguientes podrían ser alternativas válidas para arrancar, detener y
reiniciar el servicio OpenVPN:
OpenSourceCollege
Linux for SysAdmins
Página 341
Source Linux
# service openvpn start|stop|restart
# invoke-rc.d openvpn start|stop|restart
Problemas comunes con OpenVPN

Es común cometer errores y la forma más directa de enterarnos de ellos es monitoreando los logs, tal como se puede apreciar en los
siguientes ejemplos aplicables a una instancia de servidor o cliente según sea el caso:
# tail -f /var/log/openvpn/vpn-server.log
# tail -f /var/log/openvpn/cliente0.log
¿Aún desea comprobar que todo camina correctamente? Entonces déle una mirada a sus interfaces de red: si todo funciona como
debe ser entonces debe haberse creado una interfaz de red adicional con el nombre tun0, tun1, tun2 o cualquier otra similar que
antes no existía en su sistema:
# ifconfig | tail -20

RX bytes:3369923186 (3.1 GiB) TX bytes:2054455736 (1.9 GiB)
Interrupt:185 Base address:0xb400
lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:465535 errors:0 dropped:0 overruns:0 frame:0
TX packets:465535 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:241668312 (230.4 MiB) TX bytes:241668312 (230.4 MiB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

inet addr:10.255.255.1 P-t-P:10.255.255.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Fíjese como ya se ha creado tun0 el cual posee la primera dirección IP virtual dentro del rango definido en nuestros ejemplos
(10.255.255.0/24) lo cual nos lleva a pensar que se trata de un listado de las interfaces de red de un host corriendo OpenVPN en modo
servidor.
¿Las cosas todavía van mal? Puede ser que algo no anda aún bien en la conexión, tal vez la sesión SSL/TLS no se ha establecido
correctamente y se aprecian errores en los logs que nunca tienen fin.
Desde la perspectiva de un host corriendo OpenVPN en modo cliente la forma más directa de comprobar que la conexión con el otro
extremo del túnel (el servidor) se ha establecido sin problemas es probando la conectividad con lP virtual del servidor, la cual siempre
es conocida.
Así se tiene que para nuestros ejemplos debemos comprobar la conectividad con 10.255.255.1 (la primera dirección IP del rango
configurando en la directiva server) con la herramienta ping:
# ping 10.255.255.1
PING 10.255.255.1 (10.255.255.1) 56(84) bytes of data.
64 bytes from 10.255.255.1: icmp_seq=1 ttl=128 time=0.719 ms
Si no se tiene respuesta entonces definitivamente algo no está bien. Hay consejos importantes a tener en cuenta que pueden ayudar a
llegar más rápido a la solución del problema y estos son:
✔ Asegurarse que el cliente está usando la configuración correcta del servidor y puerto al cual se intenta conectar.
✔ Si el servidor OpenVPN está corriendo como un host más en una LAN detrás de un firewall entonces es necesario
asegurarse que dicho firewall está haciendo la operación de NAT correcta que le permita reenviar las conexiones UDP al
puerto respectivo del servidor OpenVPN.
✔ Asegurarse también que no existan reglas de firewall que impidan el ingreso de conexiones UDP al puerto de escucha del
servidor OpenVPN.
✔ Tener cuidado con la hora y fecha de los sistemas operativos de modo tal que estén correctamente asignados. Si se generan
OpenSourceCollege
Linux for SysAdmins
Página 342
Source Linux
los certificados en un host que tiene una hora y fecha atrasada entonces al querer hacer uso de ellos en un servidor o cliente
que sí posean la hora correcta sucederá que la negociación SSL/TLS fallará debido a la desincronización de fecha y hora,
donde se pretenderá validar un certificado en una fecha futura ficticia.
✔ Si las conexiones las aprecia muy lentas o simplemente nunca llegan a establecerse pruebe cambiando los algoritmos de
cifrado en la directiva cipher. Por lo general BF-CBC no suele dar ningún problema en la mayoría de casos.
OpenVPN simplificado desde Webmin

configurar y generar reportes de OpenVPN siguiendo estos pasos:
5. Descargar el módulo de Webmin para OpenVPN desde http://freshmeat.net
6. Dentro de Webmin acceder a 'Webmin -> Webmin Configuration -> Webmin Modules' e instalar el módulo de OpenVPN
dando clic en el botón 'From uploaded file' y eligiendo al ruta donde se guardó el módulo de Webmin descargado
previamente.
7. Luego dar clic sobre el botón 'Install Module'.
8. Una vez instalado el módulo acceder a 'Servers -> OpenVPN + CA' y revisar las opciones de configuración del módulo de
OpenVPN a través de su interfaz gráfica amigable.
OpenSourceCollege
Linux for SysAdmins
Página 343
Source Linux
1. Implementar un servidor VPN con OpenVPN en la cual se pida a los usuarios autenticarse con un usuario y password, los
mismos que deben ser validados desde un controlador de dominios Active Directory.
Crear la configuración de servidor y cliente necesaria para llevar a cabo esta configuración de manera exitosa.
OpenSourceCollege
Linux for SysAdmins
Página 344
Source Linux
1. Implementar un servidor VPN con OpenVPN en la cual se pida a los usuarios autenticarse con un usuario y password, los
mismos que deben ser validados desde un controlador de dominios Active Directory.
Crear la configuración de servidor y cliente necesaria para llevar a cabo esta configuración de manera exitosa.
Configuración de servidor:
+ En un equipo corriendo un sistema operativo Linux, crear un archivo de configuración /etc/openvpn/server.conf con un
contenido como el siguiente:
dev tun0
port 1194
proto udp
server 10.30.25.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
ifconfig-pool-persist ipp.txt
cert /etc/openvpn/keys/vpnserver.crt
key /etc/openvpn/keys/vpnserver.key
cipher BF-CBC
tls-server
user nobody
group nogroup
comp-lzo
keepalive 15 60
ping-timer-rem
persist-tun
persist-key
verb 3
log-append /var/log/openvpn.log
status /etc/openvpn/openvpn-status.log
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so openvpn
+ Ubicamos el directorio easy-rsa (Ejm: /usr/share/doc/openvpn/easy-rsa) y copiamos su contenido al directorio /etc/openvpn para
desde ahí empezar a crear la CA, certificados de servidor y cliente:
# cd /usr/share/doc/openvpn
# cp -r easy-rsa /etc/openvpn
+ Creamos la CA:
# cd /etc/openvpn/easy-rsa
# chmod +x build-* clean-all sign-req
# source vars
# ./clean-all
# ./build-ca
+ Creamos el archivo Diffie Hellman:
# ./build-dh
+ Creamos el certificado para el servidor y cliente:
# ./build-req vpnserver
# ./build-req clientevpn1
+ Firmamos y creamos los certificados de servidor y cliente:
# ./sign-req vpnserver
# ./sign-req clientevpn1
OpenSourceCollege
Linux for SysAdmins
Página 345
Source Linux
+ Creamos el directorio de llaves que usará el servidor OpenVPN y copiamos dentro todos los archivos de certificados
necesarios recién creados:
# mkdir /etc/openvpn/keys
# cd /etc/openvpn/easy-rsa/keys
# cp -v ca.crt dh1024.pem vpnserver.crt vpnserver.key /etc/openvpn/keys
# chmod 600 /etc/openvpn/keys/*.key
+ Iniciamos OpenVPN y verificamos los logs en busca de algún posible error que hayamos cometido:
# service openvpn start

# tail -f /var/log/openvpn.log
Si todo está bien, entonces ya tendremos creada una interfaz de red tun0 con una dirección IP 10.30.25.1 y el puerto
UDP 1194 en estado de escucha, lo que se puede verificar como sigue:
# ifconfig
# ifconfig tun0
# netstat -unlp
+ De acuerdo a la directiva plugin del archivo /etc/openvpn/server.conf se tiene que la palabra 'openvpn' especificada a la
derecha de la ruta del archivo /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so especifica el nombre de la aplicación que será
usada para identificarse ante los módulos PAM del sistema.
De este modo entonces será necesario crear el archivo /etc/pam.d/openvpn que contenga la configuración de autenticación
contra Winbind realizada en capítulos anteriores.
El contenido del archivo /etc/pam.d/openvpn debería tener el siguiente contenido:

auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3

password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
Las directivas resaltada en negrita corresponden a las modificaciones hechas para integrar la autenticación contra
Winbind, mientras que las otras directivas restantes corresponden a las predeterminadas que trae el archivo de
configuración /etc/pam.d/system-auth (en RedHat / CentOS y derivados).
Configuración de cliente:
+ Los archivos ca.crt, clientevpn1.crt y clientevpn1.key previamente creados serán enviados por algún medio seguro al usuario
encargado de realizar la conexión cliente de OpenVPN a nuestro servidor.
+ En un equipo corriendo un sistema operativo Windows con OpenVPN instalado, crear un archivo de configuración
C:\Archivos de programa\OpenVPN\config\cliente.ovpn con un contenido como el siguiente:
dev tun
proto udp
remote vpn.miservidor.com
resolv-retry infinite
nobind
OpenSourceCollege
Linux for SysAdmins
Página 346
Source Linux
persist-key
persist-tun
pull
tls-client
ca ca.crt
cert clientevpn1.crt
key clientevpn1.key
cipher BF-CBC
comp-lzo
verb 3
ping 15
ping-restart 60
auth-user-pass
+ Proceder a iniciar OpenVPN en Windows con la configuración arriba creada y verificar cómo es que se pide al usuario
autenticarse. Ingresar un usuario y password válido del dominio Active Directory para comprobar luego cómo se establece la
conexión correctamente.
OpenSourceCollege
Linux for SysAdmins
Página 347
Source Linux
OpenSourceCollege
Linux for SysAdmins
Página 348
Source Linux
Unidad 17: Servidor de mensajería instantánea
17.1. Objetivos
✔ Conocer el protocolo Jabber y su función en los sistemas de mensajería instantánea.

✔ Saber implementar un servidor Jabber con Openfire usando MySQL como backend.
17.2. Servidor Jabber Open Source, "Openfire"

Conceptos básicos
Jabber es un protocolo abierto basado en el estándar XML para el intercambio en tiempo real de mensajes y presencia entre dos
puntos en Internet. La principal aplicación de la tecnología Jabber es una extensible plataforma de mensajería y una red de MI
(Mensajería Instantánea) que ofrece una funcionalidad similar a la de otros sistemas como AIM, ICQ, MSN Messenger y Yahoo.
Jabber destaca porque es distinto:
✔ Es abierto -- el protocolo de Jabber es gratuito, abierto, público y comprensible. Además, existen múltiples implementaciones
de código abierto para Servidores Jabber (consulta la lista de servidores públicos) como numerosos clientes y librerías de
desarrollo.
✔ Es extensible -- usando el potencial del lenguaje XML, cualquiera puede extender el protocolo de Jabber para una
funcionalidad personalizada. Claro que para mantener la interoperatibilidad, las extensiones comunes son controladas por la
Jabber Software Foundation.
✔ Es descentralizado -- cualquiera puede montar su propio servidor de Jabber, además está libre de patentes y no depende
de ninguna empresa de modo que se puede usar ahora y siempre con total libertad.
✔ Es seguro -- Cualquier servidor de Jabber puede ser aislado de la red pública Jabber, cualquier implementación del servidor
usa SSL para las comunicaciones cliente-servidor y numerosos clientes soportan PGP-GPG para encriptar las
comunicaciones de cliente a cliente. Además, está en desarrollo una seguridad más robusta gracias al uso de SASL y
contraseñas de sesión.
Jabber puede crear confusión en un principio respecto a otros sistemas de mensajería instantánea porque habitualmente, en otros IM,
se identifica el cliente con el protocolo. En el caso de Jabber esto no es así: existe un protocolo y cada uno de los clientes es una
implementación.
La red Jabber
Al nivel más básico, si dos contactos tienen cuentas creadas en el mismo servidor, podrán hablar entre ellos. Aquí se puede ver a dos
usuarios que se conectan a sus cuentas del servidor 'jabberes.org', y hablan entre ellos directamente:
Existe una gran red de servidores Jabber interconectados entre sí, a la vez que independientes los unos de los otros. La mayoría de
estos servidores son privados, en el sentido de que son mantenidos por personas o asociaciones particulares, aunque de acceso
público, por lo que cualquier usuario puede usar sus servicios sin ninguna restricción.
Así, usuarios de distintos servidores conectados a la red Jabber pueden hablar entre ellos sin ningún problema, ya que cada usuario
está conectado a su servidor, y los servidores de estos usuarios se intercambian los mensajes:
OpenSourceCollege
Linux for SysAdmins
Página 349
Source Linux
OpenSourceCollege
Linux for SysAdmins
Página 350
Source Linux
OpenSourceCollege
Linux for SysAdmins
Página 351
Source Linux
Podemos elegir entre muchos servidores, cada uno de ellos suele ofrecer diferentes servicios al usuario, y en nuestras manos está
escoger el servidor que más nos guste o convenga. Al fin y al cabo, independientemente del servidor que escojamos para acceder a la
red de Jabber, podremos conversar con contactos de otros servidores y añadirlos a nuestra lista de contactos.
En este gráfico se muestra a ocho usuarios Jabber, cada uno conectado al servidor que prefirió, incluso hay uno que está conectado a
dos servidores simultáneamente. Todos ellos pueden hablar entre sí, ya que sus servidores están integrados en la red Jabber:
En Jabber la dirección de cada usuario dependerá del servidor en el que tenga la cuenta, siguiendo el esquema siguiente:
nombre_de_usuario@nombre_de_servidor.
Por ejemplo, si nos conectamos a Jabber a través del servidor jabberes.org, nuestra cuenta será:
nombre_usuario@jabberes.org
Este mismo usuario puede crearse más cuentas en el mismo o en otros servidores, en cuyo caso sus direcciones serán del estilo:
nombre_usuario_de_incognito@jabber.org
nombre_usuario@jabberes.org
nombre_usuario@gmail.com
...
OpenSourceCollege
Linux for SysAdmins
Página 352
Source Linux
Clientes Jabber
La naturaleza abierta de este protocolo Jabber facilitan la creación de múltiples clientes los cuales pueden tener más o mejores
funcionalidades para el usuario final. Algunos de los clientes Jabber más comunes son:
• Coccinella
• Jabbim
• Jeti
• Pidgin
• Psi
• qutIM
• saje
• SIP Communicator
• Spark
• Tkabber
• Tlen
Existen muchos más clientes Jabber disponibles, pero los arriba mostrados son multiplataforma (Linux, Windows y MacOS).
Servidores Jabber
De manera similar a los clientes Jabber, existe una variedad de software de servidor de los cuales algunos se mencionan debajo:
• Citadel
• CommuniGate Pro
• djabberd
• ejabberd
• IceWarp
• iChat Server
• Indafon
• in.jabberd
• Isode M-Link
• jabberd 1.x
• jabberd 2.x
• Jabber XCP
• Jerry Messenger
• Kwickserver
• Openfire
• OpenIM
• Prosody
• psyced
• SoapBox Server
• Sun Java System Instant Messaging
• synapse
• Tigase
• Vysper
• Wokkel
En este documento nos centraremos en la administración y configuración de Openfire como servidor Jabber.
Instalación de Openfire
Openfire debe ser instalado desde su sitio Web oficial http://www.igniterealtime.org en la versión RPM o DEB según el sistema
operativo que utilicemos.
En Red Hat / CentOS y derivados procederíamos a instalar directamente el paquete RPM como sigue:
# rpm -ivh openfire-3.6.4-1.i386.rpm
En Debian y derivados procederíamos a instalar primero el JRE y luego el paquete DEB:
# apt-get install sun-java6-jre

# dpkg -i openfire-3.6.4_all.deb
Esta diferencia se debe a que el paquete de Openfire en formato RPM ya trae incluido el Java JRE, pero no la versión en formato DEB,
OpenSourceCollege
Linux for SysAdmins
Página 353
Source Linux
por lo que se tuvo que instalar aparte en un sistema Debian.
Configuración de Openfire
Openfire posee una excelente administración Web fácil de entender y de configurar. En este apartado configuraremos Openfire
utilizando MySQL como backend para el almacenamiento de información de usuarios.
Por ello procederemos con los siguientes pasos:
Paso 1: Configuración de MySQL

Es necesario instalar el software de servidor de MySQL:
# yum install mysql-server -y
# apt-get install mysql-server -y
Iniciamos MySQL y configuramos una base de datos para Openfire:
# service mysql start

# chkconfig mysql on
# mysql
mysql> CREATE DATABASE openfire;
mysql> GRANT ALL ON openfire.* TO openfire@localhost IDENTIFIED BY 'secret';
mysql> FLUSH PRIVILEGES;
mysql> exit
# cd /opt/openfire/resources/database
# cat openfire_mysql.sql | mysql openfire
Paso 2: Configuración de Openfire

Es necesario iniciar Openfire para empezar la configuración vía Web:
# service openfire start

# chkconfig openfire on
Una vez que se inicia el Openfire se habilita el puerto 9090 para la administración Web, a la cual nos conectaremos con un
navegador a una URL similar a http://localhost:9090 y una vez dentro seguiremos los pasos debajo descritos:
Paso 2.1: Welcome to Setup

Se debe elegir el idioma de la instalación. Elegir Español si esa es nuestra preferencia y dar clic en el botón Continue.
Paso 2.2: Configuración del servidor

Rellenar el formulario de acuerdo a:
• Dominio: Un dominio que utilicemos para nuestro servidor Jabber. Ejm: consultorianet.com
• Puerto de la Consola de Administración: Dejar por defecto en 9090.
• Puerto de la Consola de Administración Segura: Dejar por defecto en 9091
Luego dar clic en el botón Continuar.

.
Paso 2.3: Configuración de la fuente de datos

Elegir entre las opciones de configuración de la fuente de datos:
• Conexión Estándar: Utiliza un motor de base de datos externo como MySQL, PostgreSQL, Oracle u otros.
• Base de datos interna: Utiliza una base de datos interna de Openfire. Recomendado para instalaciones pequeñas.
Elegir por defecto Conexión Estándard y luego dar clic en el botón Continuar.
Paso 2.4: Configuración de la fuente de datos – Conexión Estándar

Configuraremos los parámetros del motor de base de datos de acuerdo a:
• Drivers Predefinidos: Elegir MySQL
OpenSourceCollege
Linux for SysAdmins
Página 354
Source Linux
• Clase del Driver JDBC: Dejar por defecto en 'com.mysql.jdbc.Driver'
• URL de la Base de Datos: Completar con 'jdbc:mysql://localhost:3306/openfire'
• Nombre de usuario: Completar con 'openfire'.
• Contraseña: Completar con 'secret' (según el password asignado en la setencia SQL GRANT)
• Minimum Connections: Dejar por defecto en 5.
• Maximum Connections: Dejar por defecto en 25.
Paso 2.5: Seteos de Perfil

Configuraremos la fuente de usuarios y grupos a utilizar en Openfire de acuerdo a las opciones:
• Por defecto: Almacena las cuentas de usuario en la base de datos de Openfire (MySQL)
• Servidor de Directorio: Permite integrar las cuentas de usuario desde un servidor OpenLDAP o Active Directory.
• Integración con Clearspace: Permite integrar los usuarios desde una instalación de Clearspace.
Elegir por defecto Por Defecto y luego dar clic en el botón Continuar.
Paso 2.6: Cuenta del Adminsitrador

Rellenar la configuración del administrador de acuerdo a:
• Email del Administrador: La dirección e-mail de contacto del administrador. Ejm: admin@consultorianet.com
• Nueva Contraseña: Asignar un password seguro.
• Confirme la Contraseña: Repetir el mismo password.
Paso 2.7: Acceder a la consola de administración

Una vez terminada la configuración es necesario reiniciar el Openfire:
# service openfire restart
... y luego conectarse a la consola de Openfire vía la URL http://localhost:9090 con las credenciales siguientes:
Usuario : admin
Password : **** (el asignado en el paso 2.6)
Terminado el asistente de configuración ya se puede utilizar las opciones de administración que ofrece Openfire a través de su interfaz
Web.
OpenSourceCollege
Linux for SysAdmins
Página 355
Source Linux
1. Implementar un servidor Openfire que integre las cuentas de usuario desde un dominio Active Directory.
OpenSourceCollege
Linux for SysAdmins
Página 356
Source Linux
1. Implementar un servidor Openfire que integre las cuentas de usuario desde un dominio Active Directory.
+ Instalar y configurar MySQL. Luego instalar y configurar Openfire de acuerdo a lo estudiado hasta el paso 2.4.
+ En la sección de configuración 'Seteos de Perfil' elegir la opción 'Servidor de Directorio (LDAP)', dando clic luego en
Continuar.
+ En la sección 'Seteos de Perfil: Seteos de Conexión' rellenar los campos del formulario como sigue:
• Tipo de Servidor: Elegir 'Active Directory'.

• Servidor: Escribir la dirección del servidor Active Directory. Ejm: 192.168.10.3
• DN Base: Escribir la base del DN de Active Directory. Ejm: dc=consultorianet,dc=com
• DN del Administrador: Escribir el DN del usuario Administrador del dominio. Ejm:
cn=Administrador,ou=Users,dc=consultorianet,dc=com
• Clave: Password del usuario administrador del dominio.
Luego dar clic en Salvar & Continuar.
+ En la sección 'Seteos de Perfil: Mapeos de Usuarios' todos los campos dejarlos por defecto con sus valores
predeterminados a menos que se tenga una razón específica para cambiar alguno de ellos.
+ En la sección 'Seteos de Perfil: Mapeos de Grupos' todos los campos dejarlos por defecto con sus valores
predeterminados a menos que se tenga una razón específica para cambiar alguno de ellos.
+ En la sección 'Cuenta del Administrador' agregar el nombre de usuario 'administrador' o algún otro que tenga los mismos
privilegios de administración en el Active Directory..
+ Proceder a reiniciar Openfire y conectarse a la consola de administración usando las credenciales de uno de los
administradores agregados en el paso anterior.
# service openfire restart
OpenSourceCollege
Linux for SysAdmins
Página 357
Source Linux
Unidad 18: Servicio de directorios LDAP
18.1. Objetivos
✔ Conocer el concepto de un servicio de directorios LDAP y sus propósitos.

✔ Conocer la sintaxis y terminología asociada a LDAP tales como entradas, atributos, clases de objeto, filtros, etc.
✔ Saber implementar OpenLDAP como un servidor de directorios básico.
18.2. Servidor LDAP Open Source, "OpenLDAP"

Conceptos básicos
¿Qué es un directorio?
Es una colección que almacena información sobre objetos que están organizados y relacionados entre sí de alguna forma.
¿Qué es un directorio de red?

Es una base de datos especializada, también llamada repositorio que posee información mucho más descriptiva y basada en
atributos.
Diferencias entre una base de datos y un directorio de red
Criterio Directorio Base de datos

Según el propósito de acceso Lectura y búsqueda Actualización o escritura de datos
Soportan altos volúmenes de solicitudes
Según su soporte de acceso Altas actualizaciones de volúmenes
de lectura
No es apropiada para almacenar cambios Apropiadas para cambios rápidos en la
Según su capacidad de operación
rápidos en la información información
No soportan ciertos tipos de
Según las transacciones Soportan transacciones complejas
transacciones
La información debe ser estricta y
Según la consistencia de la información No requiere una estricta consistencia
verídica en tiempo real
Según el lenguaje Protocolo de acceso: LDAP SQL
Clasificación de los directorios de red
Según el proceso
• Directorio cliente: quien efectúa la solicitud
• Servidor de directorio: procesos de búsqueda de información en el directorio.
Según la cantidad de servidores

• Centralizado: un único servidor provee acceso al directorio.
• Distribuido: hay más de un servidor que provee acceso al directorio, donde la información puede ser:
✔ Particionada, cada entrada de directorio es almacenada por uno y solo un servidor.

✔ Replicada, se almacena la información en mas de un servidor.
Según el tipo de clientes

• Locales
• Globales
Interacción del directorio cliente/servidor

Los directorios usualmente son accedidos usando el modelo de comunicación cliente/servidor. Una aplicación que quiere acceder a
leer o escribir en un directorio no accede al directorio directamente. En lugar de eso, esta llama a una función o Application
Programming Interface (API) que origina un mensaje para ser enviado a otro proceso. Este segundo proceso accede a la
información en el directorio por la solicitud enviada por la aplicación. Los resultados de leer o escribir son luego retornados a la
aplicación que los solicito.
OpenSourceCollege
Linux for SysAdmins
Página 358
Source Linux
Los servicios de directorio
Un servicio de directorio es la fuente de la información del directorio y los servicios que hacen que la información este disponible a
los usuarios. Un servicio de directorio proporciona los medios para organizar y simplificar el acceso a los recursos de un sistema de
computadoras de red. Un servicio de directorio identifica a los usuarios y a los recursos de manera única sobre una red y
proporciona una manera de organizar y acceder a otros usuarios y recursos.
Funciones para las que se puede utilizar un servicio de directorio:
✔ Identificación y autenticación.
✔ Seguridad para los objetos.
✔ Replicar un directorio.
✔ Dividir un directorio.
La estructura lógica de un servicio de directorio está conformada por:
• Objetos
• Atributos
• Clases
• Unidades de organización
• Dominios
• Árboles
Características de un servicio de directorio:
1. La información contenida se lee mucho más de lo que se escribe.

2. Limitados esquemas de transacción o reducción que comúnmente implementan las bases de datos.
3. Optimización al responder de forma rápida a operaciones de búsqueda o consultas.
4. Capacidad de replica de información de forma rápida y amplia entre distintos servidores de directorios
¿Para qué sirven los servicios de directorio?

El servicio ofrecido para personas es el de proporcionar una base de datos distribuida con datos de interés como pueden ser
direcciones e-mail, tipo de actividad, dónde se desempeña ésta e incluso fotos y documentos sonoros de los miembros.
Respecto al servicio para máquinas el más importante es el de utilizarse como repositorio de información de accounting (usuarios y
claves) permitiendo la implantación de una autenticación única y consistente para todos los servicios ofrecidos en una red.
¿Qué es la autenticación única?

El aumento del número de servicios a los que tenemos acceso nos lleva a tener que recordar múltiples usuarios y contraseñas para
acceder a cada uno de ellos. La autenticación única es el intento de unificar el acceso a todos esos servicios con un único usuario
y contraseña.
El camino por el que nos lleva esta filosofía es la de identificar a la persona y ofrecer los servicios a cada persona por su relación
con la organización en lugar de por el conocimiento de una clave.
El protocolo LDAP
¿Qué es LDAP?
LDAP, Lightweight Directory Access Protocol, Protocolo de Acceso Ligero a Directorios, es un protocolo de tipo cliente/servidor para
OpenSourceCollege
Linux for SysAdmins
Página 359
Source Linux
acceder a un servicio de directorio. Este se encuentra condensado en el estándar de Internet, el RFC 1777.
Entre sus características están:
✔ Corre sobre TCP/IP

✔ Simple
✔ Omite duplicados
✔ Usa cadenas que representan datos de complicada estructura de sintaxis ANS.1(Abstract Syntax Notation One)
¿Qué tipo de información se puede almacenar en un directorio?

El modelo de información de LDAP está basado en entradas. Una entrada es una colección de atributos que tienen un único y
global Nombre Distinguido (DN). El DN se utiliza para referirse a una entrada sin ambigüedades. Cada atributo de una entrada
posee un tipo y uno o más valores. Los tipos son normalmente palabras nemotécnicas, como cn para Common Name, o mail
para una dirección de correo. La sintaxis de los atributos depende del tipo de atributo. Por ejemplo, un atributo cn puede contener
el valor "Sergio González". Un atributo mail puede contener un valor "sergio@ejemplo.com". El atributo jpegPhoto ha de
contener una fotografía en formato JPEG.
¿Cómo se almacena la información en un servidor LDAP?

En LDAP, las entradas están organizadas en una estructura jerárquica en árbol. Tradicionalmente, esta estructura reflejaba los
límites geográficos y organizacionales. Las entradas que representan países aparecen en la parte superior del árbol. Debajo de
ellos, están las entradas que representan los estados y las organizaciones nacionales. Debajo de estás, pueden estar las entradas
que representan las unidades organizacionales, empleados, impresoras, documentos o todo aquello que pueda imaginarse. La
siguiente figura muestra un ejemplo de un árbol de directorio LDAP haciendo uso del nombramiento tradicional:
Fig. 1: Árbol del directorio LDAP (nombramiento tradicional)
El árbol también se puede organizar basándose en los nombres de dominio de Internet. Este tipo de nombramiento se está
volviendo muy popular, ya que permite localizar un servicio de directorio haciendo uso de los DNS. La siguiente figura muestra un
ejemplo de un directorio LDAP que hace uso de los nombres basados en dominios.
OpenSourceCollege
Linux for SysAdmins
Página 360
Source Linux
Fig. 2: Árbol del directorio LDAP (nombramiento de Internet)
¿Cómo es referenciada la información?

Una entrada es referenciada por su nombre distinguido, que es construido por el nombre de la propia entrada (llamado Nombre
Relativo Distinguido o RDN) y la concatenación de los nombres de las entradas que le anteceden. Por ejemplo, la entrada para
Nuno Gonçalves en el ejemplo del nombramiento de Internet anterior tiene el siguiente RDN: uid=nuno y su DN sería:
uid=nuno,ou=estig,dc=ipb,dc=pt.
¿Cómo se accede a la información?

LDAP define operaciones para interrogar y actualizar el directorio. Provee operaciones para añadir y borrar entradas del directorio,
modificar una entrada existente y cambiar el nombre de una entrada. La mayor parte del tiempo, sin embargo, LDAP se utiliza para
buscar información almacenada en el directorio. Las operaciones de búsqueda de LDAP permiten buscar entradas que concuerdan
con algún criterio especificado por un filtro de búsqueda. La información puede ser solicitada desde cada entrada que concuerda
con dicho criterio.
Por ejemplo, imagínese que quiere buscar en el subárbol del directorio que está por debajo de dc=ipb,dc=pt a personas con el
nombre Nuno Gonçalves, obteniendo la dirección de correo electrónico de cada entrada que concuerde. LDAP permite hacer esto
fácilmente. O tal vez prefiera buscar las organizaciones que posean la cadena IPB en su nombre, posean número de fax y estén
debajo de la entrada st=Bragança,c=PT. LDAP le permite hacer esto también.
¿Cómo se protege la información de los accesos no autorizados?

Algunos servicios de directorio no proveen protección, permitiendo a cualquier persona acceder a la información. LDAP provee un
mecanismo de autentificación para los clientes, o la confirmación de identidad en un servidor de directorio, facilitando el camino
para un control de acceso que proteja la información que el servidor posee. LDAP también soporta los servicios de privacidad e
OpenSourceCollege
Linux for SysAdmins
Página 361
Source Linux
integridad.
¿Cómo trabaja LDAP?

El servicio de directorio de LDAP está basado en el modelo cliente/servidor. Uno o más servidores LDAP contienen los datos que
conforman la información del árbol del directorio (DIT). El cliente se conecta a los servidores y les formula preguntas. Los
servidores responden con una respuesta o con un puntero donde el cliente puede obtener información adicional (normalmente otro
servidor LDAP). No importa a qué servidor LDAP se conecte un cliente, este siempre obtendrá la misma visión del directorio; un
nombre presentado por un servidor LDAP referencia la misma entrada que cualquier otro servidor LDAP. Esta es una característica
muy importante del servicio global de directorio, como LDAP.
¿Cuál es la diferencia entre LDAPv2 y LDAPv3?

LDAPv3 fue desarrollado en los años 90 para reemplazar a LDAPv2. LDAPv3 incorpora las siguientes características a LDAP:
• Autentificación fuerte haciendo uso de SASL

• Protección de integridad y confidencialidad haciendo uso de TLS (SSL)
• Internacionalización gracias al uso de Unicode
• Remisiones y continuaciones
• Descubrimiento de esquemas
• Extensibilidad (controles, operaciones extendidas y más)
LDAPv2 es histórico. Muchas implementaciones de LDAPv2 incluyendo slapd no se adaptan a las especificaciones técnicas de
LDAPv2, la interoperabilidad entre las distintas implementaciones de LDAPv2 es muy limitada. Como LDAPv2 difiere
significativamente de LDAPv3, la interactuación entre ambas versiones puede ser un poco problemática. LDAPv2 ha de evitarse,
por lo que en la implementación de OpenLDAP viene deshabilitado por defecto.
LDIF
LDAP Interchange Format (LDIF), es un formato de archivo estándar usado para almacenar configuraciones de información LDAP y
contenido de directorios. En su forma más básica un archivo LDIF es:
• Una colección de entradas separadas una de otra por líneas en blanco

• Una asociación de atributos y valores.
• Una colección de directivas que instruyen a un parser cómo procesar la información.
Los archivos LDIF por lo general son usados para importar nuevos datos al directorio LDAP o hacer cambios en él. Los datos en un
archivo LDIF deben obedecer las reglas de los esquemas del directorio LDAP. Puede imaginarse a un esquema como una definición de
datos para el directorio. Cada ítem que es agregado o modificado en el directorio es verficado contra los esquemas en busca de
errores y comprobación de la sintaxis correcta. Si un ítem del archivo LDIF no corresponde con las reglas de un esquema se produce
una violación de esquema.
El siguiente es un ejemplo válido de contenido de un archivo LDIF que representa las entradas de los dos primeros niveles del árbol
mostrado en la imagen de abajo.
dn: dc=plainjoe,dc=org
objectClass: domain
dc: plainjoe
dn: ou=devices,dc=plainjoe,dc=org
objectClass: organizationalUnit
ou: devices
dn: ou=people,dc=plainjoe,dc=org
ou: people
OpenSourceCollege
Linux for SysAdmins
Página 362
Source Linux
Atributos y esquemas
¿Qué es un atributo?
Los tipos de atributo y sus reglas de sintaxis asociadas son similares a las declaraciones de variables y tipos de dato en muchos
lenguajes de programación. Los atributos son usados para contener valores. Las variables en los programas realizan una función
similar: almacenar información.
Cuando una variable es declarada en un programa, es definida de un cierto tipo de dato. Este tipo de dato especifica qué tipo de
información puede ser almacenado en la variable, a lo largo de otras tantas reglas, tal como comparar el valor de la variable con el
dato almacenado en otra variable del mismo tipo. Por ejemplo declarar una variable entera de 16-bit y luego asignarle 1,000,000
como valor no tendría sentido (el valor máximo representado por una variable de ese tipo es 32,767). El tipo de dato de 16-bit
determina qué datos pueden ser almacenados. El tipo de dato también determina qué valores de que tipo pueden ser comparados.
¿Es 3 < 5? Sí, desde luego que sí. ¿Cómo se sabe? Pues porque existe una serie de reglas para comparar enteros con otros
enteros. La sintaxis de atributos LDAP realizan funciones similares como los tipos de dato en el ejemplo mencionado.
A diferencia de las variables sin embargo, los atributos LDAP pueden tener múltiples valores. La mayoría de lenguajes de
programación obligan a usar una semántica de "almacenar y reemplazar" en las variables, así cuando se asigna un valor a una
variable el valor antiguo es reemplazado. Como se verá más adelante esto no es cierto en LDAP, dado que se puede asignar un
nuevo valor a un atributo como adicional de los valores ya existentes. A continuación se muestra unas líneas LDIF de ejemplo para
la entrada ou=devices,dc=plainjoe,dc=org que demuestra cómo un atributo puede tener múltiples valores:
objectclass: organizationalUnit
ou: devices
telephoneNumber: +1 256 555-5446
description: Container for all network enabled
devices existing within the plainjoe.org domain
En el ejemplo se aprecia dos valores para el atributo telephoneNumber. En la vida real es común este caso para una entidad que
es accesible por más de un número telefónico.
Sin embargo hay que ser cuidadosos con el hecho que algunos atributos permiten sólo un único valor a la vez. Esto dependerá
directamente de la definición del atributo en el esquema del servidor.
¿Qué significa el valor del atributo objectClass?
OpenSourceCollege
Linux for SysAdmins
Página 363
Source Linux
Todas las entradas en un directorio LDAP deben tener un atributo objectClass, y este atributo debe tener al menos un valor
(aunque es posible y necesario a veces que tenga múltiples valores). Cada valor de objectClass actúa como una plantilla para
los datos que serán almacenados en la entrada. Permite definir una serie de atributos que deben obligatoriamente estar presentes
en la entrada así como también una serie de atributos opcionales que pueden o no estar presentes.
Regresando al ejemplo anterior la entrada ou=devices,dc=plainjoe,dc=org se tiene:
objectclass: organizationalUnit
ou: devices
description: Container for all network enabled
devices existing within the plainjoe.org domain
En este caso el valor del atributo objectClass es organizationalUnit. La definición de esquema de la imagen que se
muestra debajo permitirá comprender mejor esto:
Así es como debe entenderse la definición de objectClass:
i. Un objectClass posee un OID, tal como los tipos de atributos, sintaxis de codificación y reglas de comparación. La
palabra MUST denota una serie de atributos que deben estar presentes en cualquier instancia de este objeto. En este
caso el "estar presente" significa que el atributo debe tener al menos un valor.
ii. La palabra MAY define una serie de atributos cuya presencia es opcional dentro de una instancia del objeto.
iii. La palabra SUP especifica que el objeto padre del cual este objeto se ha derivado. Un objeto derivado posee todos los
requerimientos de tipo de atributo de su padre. Los atributos pueden ser derivados de otros atributos también, también
heredarán la sintaxis y reglas de comparación de su padre, aunque el último puede ser sobreescrito por el nuevo
atributo. Los objetos LDAP no soportan herencia múltiple, ellos tienen simplemente un único padre así como sucede con
los objetos de Java.
Tipos de objectClass
Tres tipos de definición de objectClass pueden ser usados en los servicios de directorio LDAP:
Clases de objeto estructurales

Representan un objeto del mundo real, tal como una persona (person), o unidad organizacional (organizationalUnit). Cada
entrada en un directorio LDAP debe tener exactamente un objeto estructural como valor del atributo objectClass. De acuerdo
OpenSourceCollege
Linux for SysAdmins
Página 364
Source Linux
con el modelo de datos LDAP, una vez que un objeto estructural de una entrada ha sido ingresado, no puede ser cambiado sin
eliminar y volver a crear la entrada completa.
Clases de objecto auxiliares

Agregan ciertas características a una clase estructural. Estas clases no pueden ser usadas por sí mismas, sino como un
complemento a un objeto estructural ya existente.
Clases de objeto abstractas

Actúan igual que sus similares en la programación orientada a objetos. Estas clases no pueden ser usadas directamente, sino sólo
como antecesores de clases derivadas. La clase abstracta más común que se usará en LDAP será el objeto top, el cual es el
padre o antecesor de todas las clases de objeto LDAP.
¿Qué es el atributo dc?

Retornando a nuestro ejemplo anterior de la entrada de más alto nivel (dc=plainjoe,dc=org) ahora ya podemos explicar el
significado del atributo dc. Aquí se muestra la entrada correspondiente antes vista:
dn: dc=plainjoe,dc=org
objectclass: domain
dc: plainjoe
Como antes ya estudiamos, existe el nombramiento basado en la ubicación geográfica y el nombramiento basado en nombres
DNS, siendo este último el recomendado.
Para soportar una asociación entre los nombres DNS y un espacio de nombres de un directorio LDAP, el RFC 2247 define dos
objetos para almacenar componentes mostrados en la figura:
dcObject es una clase auxiliar que sirve para complementar una entrada que contiene información organizacional (Ejm:
organizationalUnit). La clase dcObject actúa como un contenedor independiente para la información organizacional y el
componente de nombre de dominio (Ejm: el atributo dc). La clase de objeto organizationalUnit y los objetos de dominio
poseen atributos comunes.
Generar un DN (Nombre distinguido) LDAP para representar un nombre de dominio DNS es un proceso simple. Un DN vacío se
usa como punto de partida. Un RDN dc=domain es agregado como componente al DNS de cada porción del dominio. Por
ejemplo, el nombre de dominio plainjoe.org se asocia con el contexto de nombramiento dc=plainjoe,dc=org
¿Y donde está dc=org? Como veíamos dc=plainjoe,dc=org es el contexto de nombramiento del directorio. Si la entrada raíz
de nuestro directorio fuese dc=org con una entrada hijo como dc=plainjoe,dc=org entonces el contexto de nombramiento
sería dc=org. Esto tendría como consecuencia que nuestro servidor empiece a responder de manera innecesaria a consultas cuyo
DN termine en dc=org, aún si el servidor solamente contenga información debajo de dc=plainjoe,dc=org
Es así que que el diseño de un espacio de nombres es similar a una jerarquía DNS. Los servidores DNS para el dominio
plainjoe.org no necesitan atender consultas del dominio .org, dado que aquellas consultas deben ser redireccionadas a un servidor
OpenSourceCollege
Linux for SysAdmins
Página 365
Source Linux
que en realidad sí contenga dicha información.
Atributos comunes
Estos son una serie de los atributos más comunes que usaremos:
Nombre Valor único Descripción

cn Nombre común de una entidad
sn Apellido con el cual se conoce a una entidad
dc Componente único de un nombre de dominio
gidNumber Sí ID de grupo en UNIX
uidNumber Sí ID de usuario en UNIX
uid Nombre de usuario para una cuenta
mail Dirección e-mail que representa a un buzón
ou Unidad organizativa (organizationalUnit) a la cual pertenece esta entrada
telephoneNumber Número telefónico
userPassword Contraseña asociada con una entrada
Clases de objeto comunes

Estas son una serie de clases de objeto más comunes que usaremos:
account
Tipo: Estructural
Padre: top
Atributos obligatorios: uid
Atributos opcionales: description, seeAlso, localityName, organizationName, organizationalUnitName,
host
dcObject
Tipo: Auxiliar
Padre: top
Atributos obligatorios: dc
Atributos opcionales: (ninguno)
inetOrgPerson
Tipo: Estructural
Padre: organizationalPerson
Atributos obligatorios: (ninguno)
Atributos opcionales: audio, businessCategory, carLicense, departmentNumber, displayName,
employeeNumber, employeeType, givenName, homePhone, homePostalAddress, initials, jpegPhoto,
labeledURI, mail, manager, mobile, o, pager, photo, roomNumber, secretary, uid, userCertificate,
x500uniqueIdentifier, preferredLanguage, userSMIMECertificate, userPKCS12
organizationalPerson
Tipo: Estructural
Padre: person
Atributos obligatorios: (ninguno)
Atributos opcionales: title, x121Address, registeredAddress, destinationIndicator,
preferredDeliveryMethod, telexNumber, teletexTerminalIdentifier, telephoneNumber,
internationaliSDNNumber, facsimileTelephoneNumber, street, postOfficeBox, postalCode,
postalAddress, physicalDeliveryOfficeName, ou, st, l
organizationalUnit
Tipo: Estructural
Padre: top
Atributos obligatorios: ou
OpenSourceCollege
Linux for SysAdmins
Página 366
Source Linux
Atributos opcionales: userPassword, searchGuide, seeAlso, businessCategory, x121Address,
registeredAddress, destinationIndicator, preferredDeliveryMethod, telexNumber,
teletexTerminalIdentifier, telephoneNumber, internationaliSDNNumber, facsimileTelephoneNumber,
street, postOfficeBox, postalCode, postalAddress, physicalDeliveryOfficeName, st, l, description
person
Tipo: Estructural
Padre: top
Atributos obligatorios: cn, sn
Atributos opcionales: userPassword, telephoneNumber, seeAlso, description
posixAccount
Tipo: Auxiliar
Padre: top
Atributos obligatorios: cn, uid, uidNumber, gidNumber, homeDirectory
Atributos opcionales: userPassword, loginShell, gecos, description
posixGroup
Tipo: Estructural
Padre: top
Atributos obligatorios: cn, gidNumber
Atributos opcionales: userPassword, memberUid, description
shadowAccount
Tipo: Auxiliar
Padre: top
Atributos obligatorios: uid
Atributos opcionales: userPassword, shadowLastChange, shadowMin, shadowMax, shadowWarning,
shadowInactive, shadowExpire, shadowFlag, description
Esquemas comunes
Estas son una serie de esquemas más comunes que usaremos:
Software Archivos de esquema incluidos

core.schema
corba.schema
cosine.schema
inetorgperson.schema
OpenLDAP (http://www.openldap.org)
java.schema
misc.schema
nis.schema
openldap.schema
Bind 9 (http://www.venaas.no/ldap/bind-sdb) dnszone.schema
Samba (http://www.samba.org) samba.schema
Sendmail (http://www.sendmail.org) sendmail.schema
FreeRadius (http://www.freeradius.org) RADIUS-LDAPv3.schema
idpool.schema
LDAP System Administration
printer.schema
Courier (http://www.courier-mta.org/authlib/) authldap.schema
Autenticación en LDAP
¿Por qué se necesita autenticación en un directorio LDAP? Recuerde que LDAP es un protocolo basado en mensajes orientado a
la conexión. El proceso de autenticación es usado para establecer los privilegios de usuario para cada sesión. Todas las
búsquedas, consultas, etc, son controladas según el nivel de autorización del usuario autenticado.
La siguiente figura describe la clase de objeto person y nos brindará una idea de qué atributos están disponibles para la entrada
cn=gerald carter en entrada de ejemplo más abajo. En general necesitaremos definir un atributo userPassword para futuras
tareas de autenticación LDAP.
OpenSourceCollege www.opensourcecollege.com Linux for SysAdmins

Primer centro de capacitación Open Página 367
Source Linux
La representación LDIF para dicha entrada es:
dn: cn=gerald carter,ou=people,dc=plainjoe,dc=org

objectClass: person
cn: gerald carter
sn: carter
telephoneNumber: 555-1234
userPassword: {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ=
Hemos agregado un atributo userPassword. Este atributo almacena una reprentación de las credenciales necesarias para
autenticar a un usuario. El prefijo (en este caso {MD5}) describe cómo la credencial es codificada. El valor en este caso es
simplemente la codificación Base 64 del hash MD5 sobre la palabra "secret" (sin comillas).
Existen una serie de algoritmos de encriptación y algunos de los más comunes usados en LDAP son:
{CRYPT}
El hash de la clave debe ser generado usando la función local del sistema crypt( ), el cual es normalmente incluido en las
librerías del lenguaje C.
{MD5}
El hash de la clave es una codificación Base64 del digest MD5 sobre la contraseña del usuario.
{SHA} (Secure Hash Algorithm)

El hash de la clave es una codificación Base64 del hash SHA-1 de 160-bit MD5 sobre la contraseña del usuario.
{SSHA} (Salted Secure Hash Algorithm)

Esta es una versión modificada del anterior que hace uso de salts. Este es el esquema recomendado para almacenar información
de contraseñas de manera segura en un directorio LDAP.
Durante el proceso de autenticación en cualquier servicio (FTP, SSH, SMTP, POP, IMAP, etc) es común que el cliente brinde un
nombre de usuario y la respectiva contraseña. En LDAP la autenticación se lleva a cabo a través de un DN brindada por el cliente
que será interpretado como nombre de usuario (Ejm: cn=gerald carter,ou=people,dc=plainjoe,dc=org), y la contraseña
respectiva será leída del atributo userPassword de dicha entrada.
Filtros LDAP
Los filtros LDAP son una serie de patrones que tienen por objetivo limitar y especificar el alcance de las búsqueda dentro un directorio
LDAP. En su forma comúnmente usada un filtro LDAP tiene la siguiente sintaxis:
( atributo filtro_Operador valor )
El atributo es el nombre actual del tipo de atributo. El filtro_Operador es uno de los siguientes:
= : Para coincidencias exactas
~= : Para coincidencias aproximadas
<= : Comparaciones menor que
>= : Comparaciones mayor que
Si solamente tratamos con comparaciones de cadenas entonces puede ser que sólo se necesite el operador =.
El valor puede ser absoluto como 326-3872 (para un telephoneNumber por ejemplo) o un patrón usando el caracter * como
comodín. Por ejemplo (cn=*carter) buscaría todas las entradas cuyo atributo cn termina en "carter".
Puede combinarse filtros simples usando operadores lógicos como estos:
OpenSourceCollege
Linux for SysAdmins
Página 368
Source Linux
& : AND lógico
| : OR lógico
! : NOT lógico
Los filtros LDAP usan una notación prefija para unir condiciones. Por lo tanto para buscar usuarios con un apellido (sn) como "smith" o
"jones" podría construirse el siguiente filtro:
(|(sn=smith)(sn=jones))
Para buscar personas con un apellido como "smith" o "jones" y un nombre que empiece con "John", la búsqueda sería como sigue:
(&(|(sn=smith)(sn=jones))(cn=john*))
Instalación de OpenLDAP
OpenLDAP puede ser instalado directamente desde los repositorios de las distribuciones Linux como sigue:
# yum install openldap-servers openldap-clients -y
# apt-get install slapd ldap-utils -y
Observación:
• En Debian la instalación del paquete slapd (el servidor LDAP, OpenLDAP) nos consultará cuál es la contraseña que
deseamos asignar al administrador rootdn por defecto.
Configuración de OpenLDAP
El paquete OpenLDAP incluye herramientas clientes, servidores y librerías. La siguiente tabla muestra una descripción breve de la
función que cumple cada uno de los componentes dentro del paquete LDAP:
Nombre Descripción
libexec/slapd El servidor LDAP
libexec/slurpd El servidor de replicación LDAP
bin/ldapadd
bin/ldapmodify Herramientas de línea de comandos para agregar, modificar y eliminar entradas en un servidor LDAP. Estos
bin/ldapdelete comandos soportan LDAPv2 y LDAPv3.
bin/ldapmodrdn
bin/ldapsearch Herramientas de línea de comandos para buscar dentro de un servidor LDAP o realizar alguna operación de
bin/ldapcompare comparación en un atributo específico contenido en una entrada.
Una herramienta para cambiar el atributo password en las entradas LDAP. Es equivalente al comando
bin/ldappasswd
passwd del sistema.
sbin/ldapadd
sbin/ldapcat Herramientas para manipular la data almacenada del backend local usada por el demonio slapd.
sbin/ldapindex
sbin/slappasswd Una herramienta sencilla que sirve para generar hashes para las contraseñas de uso posterior en slapd.conf
El archivo de configuración slapd.conf

El archivo slapd.conf es el archivo en el que se centraliza la configuración del principal demonio de OpenLDAP (slapd), el demonio
de replicación (slurpd) y herramientas relacionadas como slapcat y slapadd.
Como regla general las herramientas clientes de OpenLDAP tales como ldapsearch y ldapmodify usan el archivo de configuración
ldap.conf para sus configuraciones por defecto.
Observaciones:
OpenSourceCollege
Linux for SysAdmins
Página 369
Source Linux
 Las líneas en blanco y aquellas que empiecen con el caracter # son ignoradas.
 Los parámetros y sus valores asociados son separados por espacios en blanco (espacios y/o tabulaciones).
 Una línea que contenga un espacio en blanco en la primera columna se considerará una continuación de la anterior. No se
requiere usar el caracter \ para continuar líneas más abajo.
El archivo de configuración slapd.conf suele separar su contenido en dos partes. La primera de ellas contiene todas las directivas
asociadas al funcionamiento general del servidor (por ejemplo el nivel de registro enviado a los logs). La segunda parte contiene las
directivas asociadas a la definición de los backends usados por el demonio slapd.
Este es un ejemplo de cómo se muestra el archivo de configuración slapd.conf:
# /etc/openldap/slapd.conf
# Seccion global
## Parametros globales removidos por brevedad, por ahora...
#######################################################
# Base de datos #1 - Berkeley DB
database bdb
## Parametros de la base de datos y directivas irian aqui
#######################################################
# Base de datos #2 - Berkeley DB
database bdb
## Parametros de la base de datos y directivas irian aqui
## Y asi sucesivamente...
Directivas de funcionamiento general

A continuación se irá mostrando una serie de directivas de configuración del archivo slapd.conf clasificadas según la función que
cumplen.
include
Esta directiva es la que permite incluir otros archivos dentro de slapd.conf, usualmente usado para especificar qué archivos de
esquema deben ser soportados por el servidor. Por defecto los archivos de esquema suelen ser ubicados en el directorio
/etc/openldap luego de la instalación.
Sintaxis: include ruta_archivo
El primer paso en configurar el servidor LDAP es decidir qué archivos de esquema el directorio debe soportar. No es una tarea fácil
responder a esta pregunta en unas pocas líneas.
OpenLDAP incluye algunos archivos de esquema populares para ser usados con discreción por el administrador. Las necesidades
de las aplicaciones que usarán el directorio determinarán qué esquema usar. Todas las definiciones de tipos de atributos y clases
de objeto requeridos por un servidor LDAP básico son incluidas en el archivo core.schema. Algunos de los tipos de atributos son:
• Atributos para almacenar la fecha y hora dela última modificación en una entrada
• Atributos para representar nombre, ubicación, etc.
• Objetos para representar una organización o persona
• Objetos para representar nombres de dominio DNS
• Entre otros...
Existen archivos de esquema incluidos con la instalación OpenLDAP como los siguientes:
corba.schema
Un esquema para almacenar objetos Corba en un directorio LDAP, como es descrito en el RFC 2714.
core.schema
El esquema más importante requerido por OpenLDAP. Este esquema define atributos básicos de
OpenSourceCollege
Linux for SysAdmins
Página 370
Source Linux
LDAPv3 y objetos descritos en los RFCs 2251-2256.
cosine.schema
Un esquema para soportar directorios piloto COSINE y X.500. Basado en el RFC 1274.
inetorgperson.schema
El esquema que define la clase de objeto inetOrgPerson y sus atributos asociados definidos en el
RFC 2798. Este objeto es frecuentemente usado para almacenar información de contacto de
personas.
java.schema
Un esquema definido en el RFC 2713 para almacenar distintos tipos de objeto de Java.
misc.schema
Un esquema que define un grupo pequeño de objetos y atributos misceláneos. Actualmente, este
archivo contiene el esquema necesario para implementar un sistema de correo basado en LDAP y
Sendmail 8.10+
nis.schema
Un esquema que define atributos y objetos necesarios para usar LDAP con Network Information
Service (NIS) tal como es descrito en el RFC 2307
openldap.schema
Objetos misceláneos usados por el proyecto OpenLDAP. Provisto por propósitos informativos
solamente.
Ejemplo:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
Las aplicaciones clientes que deseamos soportar pueden requerir archivos de esquema adicionales a core.schema. Es necesario
asegurarse de las dependencias entre archivos de esquema. Las dependencias son normalmente descritas al inicio del archivo.
Por ejemplo, muchas aplicaciones requieren que se incluya la clase de objeto inetOrgPerson, el cual es frecuentemente usado
para almacenar información de contacto. En el inicio del archivo inetorgperson.schema puede encontrarse una línea donde se indica
que también debe incluirse el archivo cosine.schema.
loglevel
Esta directiva define el nivel de registro a almacenarse durante el funcionamiento de OpenLDAP. Toma como valor un número de la
tabla mostrada debajo, y pueden sumarse varios de aquellos números para obtener un registro equivalente a todas sus categorías
correspondientes juntas. Los registros por defecto son enviados a syslog usando la facilidad LOG_LOCAL4.
Sintaxis: loglevel número
La lista de números válidos para esta directiva son:
Número Información registrada

-1 Toda la información completa posible
0 Nada de información en absoluto
1 Análisis de las llamadas a funciones
2 Información de depuración sobre el manejo de paquetes
4 Depuración bastante cargada
8 Administración de conexiones
16 Paquetes enviados y recibidos
32 Procesamiento de filtros de búsqueda
64 Procesamiento del archivo de configuración
128 Procesamiento de las ACLs
256 Estadísticas de conexión, operaciones y resultados
512 Estadísticas para resultados retornados a los clientes
OpenSourceCollege
Linux for SysAdmins
Página 371
Source Linux
1024 Comunicación con backends de shell
2048 Imprime información de depuración sobre el procesamiento de entradas
En el siguiente ejemplo se registrará información sobre el procesamiento de ACLs, los filtros de búsqueda y la administración de
conexiones (128 + 32 + 8):
loglevel 168
pidfile
Esta directiva define la ruta del archivo que contendrá el PID del demonio slapd.
Sintaxis: include ruta_archivo
Ejemplo:
pidfile /var/run/slapd.pid
argsfile
Esta directiva define la ruta del archivo que contendrá los parámetros de línea de comandos usados comúnmente por el demonio
slapd.
Sintaxis: argsfile ruta_archivo
Ejemplo:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
require
Esta directiva define ciertas exigencias por parte del cliente al momento de conectarse al servidor LDAP.
Sintaxis: require opciones
En el siguiente ejemplo se obliga a que los clientes se autentiquen (authc) antes de hacer cualquier operación, y lo hagan con la
versión 3 del protocolo LDAP (LDAPv3):
require authc LDAPv3
Directivas de backends
Luego de la sección global del archivo slapd.conf vendrán una o más secciones de las bases de datos, cada una de ellas constituida
de varias directivas las cuales se pasan a estudiar a continuación.
database
Una sección de base de datos empieza con la directiva database y continúa hasta la próxima ocurrencia de dicha directiva o
hasta el final del archivo. Esta directiva recibe como parámetro el backend que puede ser bdb o ldbm
Sintaxis: database backend
Ejemplo:
database bdb
suffix
Esta directiva permite definir el sufijo raíz del directorio que se servirá.
Sintaxis: suffix DN
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Página 372
Source Linux
suffix "dc=newdomains,dc=com"
rootdn
Esta directiva define un DN que representará el acceso de un usuario con todos los privilegios sobre el directorio servido, similar a
lo que sería root en un sistema UNIX. Este DN está autorizado a hacer todo, dado que las ACLs no le afectarán en absoluto.
Sintaxis: rootdn DN
Ejemplo:
rootdn "cn=Manager,dc=newdomains,dc=com"
rootpw
Esta directiva define la contraseña correspondiente para el DN definido en rootdn. El valor para esta contraseña debe ser
generada por la herramienta slappasswd.
Sintaxis: rootpw contraseña
En el primer ejemplo se usa una contraseña en texto plano y en el segundo el hash correspondiente a la misma clave pero
generada por el algoritmo SSHA:
rootpw clave123
rootpw {SSHA}3fsj+79Ta+G0Ehn789MJ3IYccmPajerT
lastmod
Esta directiva indica a OpenLDAP que debe mantener actualizados los atributos operacionales tales como modifiersName,
modifyTimestamp, creatorsName y createTimestamp para todas las entradas de core.schema. El comportamiento normal
es mantener actualizadas todas estos atributos dado que en el caso de deshabilitarlo no se podrá hacer uso de la caché por cliente
debido a que no se puede saber cuándo fue modificada por última vez una entrada.
Sintaxis: lastmod on|off
Ejemplo:
lastmod on
readonly
Esta directiva instuye a OpenLDAP para que la base de datos quede protegida de cualquier operación de modificación incluso por
el mismo rootdn.
Sintaxis: readonly on|off
Ejemplo:
readonly off
directory
Esta directiva define la ruta del directorio de la base de datos. Los archivos dentro de este directorio deberían ser de propiedad del
usuario bajo el cual es ejecutado slapd.
Sintaxis: directory ruta_directorio
Ejemplo:
directory /var/lib/ldap
mode
Esta directiva define los permisos UNIX que deben tener los archivos de la base de datos.
Sintaxis: mode permisos
OpenSourceCollege
Linux for SysAdmins
Página 373
Source Linux
Ejemplo:
mode 0600
index
Esta directiva define los atributos en los que OpenLDAP debe mantener índices los mismos que son usados para optimizar las
búsquedas.
Sintaxis: index atributo[,atributo][,atributo] tipo[,tipo][,tipo]...
Los tipos de índices que pueden mantenerse son los siguientes:
approx (approximate)
Indexa la información por una coincidencia aproximada o fonética del valor de un atributo
eq (equality)
Indexa la información necesaria para ejecutar una coincidencia exacta del valor de un atributo
pres (presence)
Indexa la información necesaria para determinar si un atributo tiene un valor o no. Si un
atributo no posee un valor entonces el atributo no está presente en la entrada del directorio
sub (substring)
Indexa la información necesaria para ejecutar una coincidencia simple de subcadena del valor de
los atributos
Ejemplo:
index objectClass eq
index cn,sn pres,eq
cachesize
Esta directiva define el número de entradas que deberían ser almacenadas en memoria caché. Por defecto se almacena 1,000
entradas en caché, pero si el número de entradas es menor a esta cantidad no es necesario modificar el valor de esta directiva.
Sintaxis: cachesize número
En el siguiente ejemplo se tiene un directorio de aproximadamente 1,000,000 entradas para el cual vendría bien un valor de
100,000:
cachesize 100000
Listas de control de acceso (ACL)

Las ACLs provistas por OpenLDAP son simples en su sintaxis pero bastante flexibles y poderosas en su implementación. La idea
básica es definir ¿Quién tiene Acceso a Qué? La forma más común de "Quién" incluye:
*
Coincide con cualquier usuario conectado incluso bajo conexiones anónimas
self
Representa el DN del usuario actualmente conectado, asumiendo que ha sido autenticado
exitosamente por un proceso de autenticación previo
anonymous
Conexiones anónimas no autenticadas
users
Conexiones de usuarios autenticados
Expresión regular
Coincide con un DN bajo una expresión regular
La siguiente tabla resume los varios privilegios de acceso que puede obtener un usuario. Los privilegios más altos implican tener
todas las capacidades de los privilegios anteriores. Por ejemplo tener el acceso search implicará que tiene acceso auth y
OpenSourceCollege
Linux for SysAdmins
Página 374
Source Linux
compare
Nivel de Permiso concedido

acceso
write Acceso a modificar atributos (Ejm: Cambiar un telephoneNumber a 326-3872)
read Acceso a leer los resultados de búsquedas (Ejm: Mostrar todas las entradas con un telephoneNumber como
326*)
search Acceso a aplicar filtros de búsqueda (Ejm: ¿Existe alguna entrada con un telephoneNumber como 326*)
compare Acceso a comparar atributos (Ejm: ¿Es tu telephoneNumber igual a 326-3872?)
auth Acceso a autenticarse. Requiere que el cliente envíe un usuario en forma de DN y sus credenciales para probar
su identidad
none Sin ningún tipo de acceso
Finalmente la definición de "¿A qué?" se tiene acceso define la entrada y sus atributos a los cuales la ACL debería aplicarse. Está
compuesta de 3 partes de las cuales todas son opcionales:
1) Un DN expresado bajo la sintaxis siguiente:
dn.estilo=patrón
Donde estilo puede tener los siguientes valores:
exact
Sinónimo de base. Indica una entrada cuya DN es exactamente igual a la expresada en patrón.
Se usa este estilo por defecto si se omite
one
Sinónimo de onelevel. Indica todas las entradas ubicadas inmediatamente debajo de la
entrada expresada en patrón
sub
Sinónimo de subtree. Indica todas las entradas existentes en el árbol de la entrada
expresada en patrón
children
Indica todas las entradas subordinadas a la entrada expresada en patrón
regex
Indica una entrada según la expresión regular representada en patrón
2) Un filtro LDAP conforme el RFC 2254, expresado como filter=FILTRO-LDAP
3) Una lista de atributos separados por coma (",") expresados como attrs=LISTA-ATRIBUTOS. Si no se especifica esta parte
entonces la ACL se aplica a todos los atributos de la entrada.
Si ninguna de estas 3 partes es especificada entonces un simple asterisco ("*") es usado en reemplazo para hacer referencia a
todo. De esta manera se define la siguiente directiva para slapd.conf:
access
Esta directiva define una ACL sobre "A qué" debe darse "Cuánto acceso" y "A quién". Es importante tener en cuenta que las ACLs
son jerárquicas, esto significa que importa mucho el orden vertical en el que deben ser declaradas en el archivo slapd.conf.
Sintaxis: access to <"A qué"> [ by <"A quién> ["Cuánto acceso"] ]
En el siguiente ejemplo se protege el atributo userPassword de modo que solamente el usuario administrador con DN
cn=admin,dc=newdomains,dc=com tenga permiso de escritura, los usuarios anónimos tengan sólo acceso a autenticarse, los
usuarios autenticados propietarios de su entrada puedan modificar tal atributo y al resto se le deniega todo el acceso. Además el
directorio entero se protege de ser leído por quienes no se hayan autenticado exitosamente:
access to dn.base=""
OpenSourceCollege
Linux for SysAdmins
Página 375
Source Linux
by * read
access to attrs=userPassword
by dn="cn=admin,dc=newdomains,dc=com" write
by anonymous auth
by self write
by * none
access to *
by dn="cn=admin,dc=newdomains,dc=com" write
by users read
by * none
Administración del servicio de directorios
Herramientas de manipulación del backend

OpenLDAP incluye herramientas para manipular de manera directa el contenido del servicio de directorios efectuando ciertas
operaciones sobre el backend en uso. A continuación se verán los procedimientos comunes para poner en marcha un servicio de
directorios desde cero.
1. Generación del contenido

El primero paso a seguir en la construcción de un servicio de directorios es armar el esquema básico que contenga las entradas
esenciales para poner en marcha OpenLDAP y en base a ello poder continuar el proceso de modificación de contenido.
Para ello debe generarse un archivo LDIF donde se definan al menos una entradas básica como la siguiente:
dn: dc=newdomains,dc=com
objectClass: dcObject
objectClass: organization
dc: newdomains
o: New Domains Technologies Inc.
Luego de guardar los cambios en el archivo ~/base.ldif se debe proceder a usar la herramienta slapadd para ingresar el contenido
al directorio siempre y cuando el demonio slapd esté detenido.
La forma básica de uso de esta herramienta es como sigue:
slapadd [opciones]
Opciones:
-b SUFIJO : Define el sufijo del directorio bajo el cual se agregarán las entradas
-c : Continúa agregando las entradas aún si en alguna de ellas encontrase algún error
-l : Especifica la ruta del archivo LDIF del cual agregar las entradas
-v : Modo verboso
Entonces ahora ya se procede a ingresar las entradas:
# slapadd -v -b "dc=newdomains,dc=com" -l base.ldif
2. Volcado de contenido
Una vez que el directorio ya se encuentra en funcionamiento es posible poder volcar su contenido -originalmente almacenado en el
backend respectivo- hacia una salida de texto con formato LDIF. Esto es posible con la herramienta slapcat cuya forma de uso es
la siguiente:
slapcat [opciones]
Opciones:
-b SUFIJO : Define el sufijo del directorio debajo del cual se mostrará su contenido
-a FILTRO : Solamente muestra las entradas que coincidan con el filtro especificado
-s DN : Permite mostrar el contenido del directorio que se encuentre sólo debajo de la DN especificada
-c : Continúa mostrando las entradas aún si sucediese algún error
-l : Especifica la ruta de un archivo al cual enviar el contenido del directorio en formato LDIF
-v : Modo verboso
OpenSourceCollege
Linux for SysAdmins
Página 376
Source Linux
En el siguiente ejemplo de hace un volcado del directorio cuyo sufijo es dc=newdomains,dc=com hacia el archivo dump.ldif:
# slapcat -b "dc=newdomains,dc=com" -l dump.ldif
3. Generación de contraseñas
En el transcurso del funcionamiento del directorio el administrador en más de una ocasión se encontrará en la necesidad de
generar contraseñas para diversas entradas de usuarios a fin que puedan autenticarse en el futuro valiéndose de la herramienta
slappasswd. Observe la forma de uso de esta herramienta:
slappasswd [opciones]
Opciones:
-e CLAVE : Genera un hash a partir de la clave brindada o se la pide al usuario si se omite parámetro
-h ESQUEMA : Define el esquema del hash generado. Valores: {SHA}, {MD5}, {CRYPT}, {SSHA}, {SMD5} y {CLEARTEXT}
-T ARCHIVO : Genera un hash a partir del contenido del archivo especificado
-v : Modo verboso
En el siguiente ejemplo se genera un hash MD5 para la contraseña que será especificada desde la entrada estándar por el
administrador:
# slappasswd -h {md5}
New password:
Re-enter new password:
{MD5}TRhjIcGn8PNUspfokUqyQA==
Herramientas de administración LDAP

Estas herramientas de administración permiten comunicarse con un servicio de directorios haciendo uso del protocolo LDAP a fin de
poder ejecutar tareas de consultas, búsquedas, autenticación, modificación, entre otras tareas.
A diferencia de las herramientas antes vistas -slapadd, slapcat- que son específicas para manipular el backend de OpenLDAP, las
que estudiaremos en esta sección permiten comunicarse con cualquier implementación de un servicio de directorios LDAP incluso
cualquiera distinto de OpenLDAP.
Es importante considerar que estas herramientas requieren necesariamente que el servicio de directorios LDAP se encuentre en
ejecución a diferencia de slapadd por ejemplo que exige tener el demonio slapd apagado.
Modificar contenido del directorio

Una operación de modificación sobre un directorio puede puede hacerse a través de la herramienta ldapmodify cuyos
parámetros son:
ldapmodify [opciones]
Opciones:
-a : Agrega entradas en lugar de modificarlas. Equivalente a usar ldapadd

-x : Utiliza autenticación simple en lugar de SASL
-c : Continúa trabajando aún si sucediese algún error
-D DN : Se autentica al servidor usando la DN especificada
-W : Pide en la entrada estándar la contraseña para el DN de autenticación especificado con -D
-w CLAVE : Usa la clave especificada para el DN autenticación especificado con -D
-y ARCHIVO : Usa el contenido del archivo especificado como clave para el DN autenticación especificado con -D
-f ARCHIVO : Usa el contenido del archivo especificado con formato LDIF para hacer los cambios al directorio
-H LDAP-URI : Realiza la operación en el host especificado en la URI con la forma "protocolo://host:puerto"
-P 2|3 : Define la versión del protocolo LDAP a usar
-v : Modo verboso
Las entradas pueden ser modificadas a través de un archivo de formato LDIF en el cual se indiquen las entradas a agregar o
modificar especificando qué atributos eliminar, agregar o modificar. Este archivo debe contener la palabra changetype que
permitirá especificar de qué tipo de cambio se trata el que está por efectuarse, siguiendo la forma descrita debajo:
add : Agrega la entrada al directorio

delete : Elimina la entrada al directorio
modify : Modifica los atributos de una entrada del directorio. Con esto se puede agregar y
eliminar atributos usando debajo las palabras "add" y "delete"
OpenSourceCollege
Linux for SysAdmins
Página 377
Source Linux
Así, en el siguiente ejemplo se crean dos entradas que son una unidad organizativa y un usuario dentro de ésta:
# /root/update.ldif
dn: ou=users,dc=newdomains,dc=com
ou: users
dn: uid=angel,ou=users,dc=newdomains,dc=com
objectClass: account
objectClass: posixAccount
uid: angel
cn: Angel Rengifo
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/angel
Luego el contenido de dicho archivo LDIF se agregará al directorio autenticado con el rootdn correspondiente:
# ldapmodify -x -a -D "cn=Manager,dc=newdomains,dc=com" -W -f ~/update.ldif -v
Lo anterior es equivalente a usar la herramienta ldapadd como sigue:
# ldapadd -x -D "cn=Manager,dc=newdomains,dc=com" -W -f ~/update.ldif -v
Ahora se generará un archivo donde se indique las modificaciones a hacer sobre el directorio:
✔ Agregar el atributo userPassword al DN "uid=angel,ou=users,dc=newdomains,dc=com"

✔ Agregar otra entrada de usuario al directorio
El contenido del archivo LDIF donde se ordene las operaciones a realizar es:
# /root/update.ldif
dn: uid=admin,ou=users,dc=newdomains,dc=com
changetype: add
objectClass: account
objectClass: posixAccount
uid: admin
cn: Administrator
uidNumber: 1001
gidNumber: 1001
homeDirectory: /home/admin
userPassword: {SSHA}fSR/7ya65y4LRfgDGdv1kO52WpTwj3L4
changetype: modify
add: userPassword
userPassword: {SSHA}a4bbXzy/ybSNWs5IOErixG9n3DnZ2F9X
El cambio solicitado se hará como sigue:
# ldapmodify -x -D "cn=Manager,dc=newdomains,dc=com" -W -f ~/update.ldif -v
Ahora podemos eliminar la entrada "uid=angel,ou=users,dc=newdomains,dc=com" generando el LDIF correspondiente:
# /root/update.ldif
changetype: delete
Luego lo hacemos efectivo con ldapmodify:
# ldapmodify -x -D "cn=Manager,dc=newdomains,dc=com" -W -f ~/update.ldif -v
Una forma equivalente de eliminar una entrada sería usar la herramienta ldapdelete de manera directa sin necesidad de generar
un archivo LDIF con las modificaciones. La forma de usarlo sería como sigue:
# ldapdelete -x -D "cn=Manager,dc=newdomains,dc=com" -W uid=angel,ou=users,dc=newdomains,dc=com
OpenSourceCollege
Linux for SysAdmins
Página 378
Source Linux
En caso se desee eliminar una entrada que tiene otras tantas subordinadas se requiere el parámetro -r como el siguiente ejemplo
donde se eliminará la entrada "ou=users,dc=newdomains,dc=com" y todos los usuarios que existan dentro:
# ldapdelete -x -D "cn=Manager,dc=newdomains,dc=com" -W -r ou=users,dc=newdomains,dc=com
Búsquedas en el directorio
Una operación de búsqueda sobre un directorio puede implicar algunos aspectos extras al sólo definir el patrón a buscar. Debe
considerarse que muchas veces será necesario autenticarse antes de intentar buscar algo, así como también puede ser necesario
limitar el ámbito de búsqueda, ser más específico con el uso de filtros LDAP, limitar el número de resultados, etc. Todos estos
aspectos entre otros son tratados por la herramienta ldapsearch cuya forma de uso es la siguiente:
ldapsearch [opciones] filtro atributos
Opciones:
-x : Utiliza autenticación simple en lugar de SASL

-D DN : Se autentica al servidor usando la DN especificada
-W : Pide en la entrada estándar la contraseña para el DN de autenticación especificado con -D
-w CLAVE : Usa la clave especificada para el DN autenticación especificado con -D
-y ARCHIVO : Usa el contenido del archivo especificado como clave para el DN autenticación especificado con -D
-A : Muestra solamente los atributos mas no los valores
-L : Muestra el resultado en formato LDIF. Una simple -L muestra la salida en formato LDIFv1, una segunda -L
suprime los comentarios y una tercera -L evita mostrar la versión de LDIF
-b SUFIJO : Define el sufijo del directorio debajo del cual se hará la búsqueda
-H LDAP-URI : Hace la consulta hacia el host especificado en la URI con la forma "protocolo://host:puerto"
-s AMBITO : Define el ámbito de búsqueda (base, one, sub o children) según el estilo especificado
-P 2|3 : Define la versión del protocolo LDAP a usar
-l TIEMPO : Limita cuánto tiempo (en segundos) podrá esperar a que termine la búsqueda. 0 es ilimitado
-z NUMERO : Limita al número especificado la cantidad de entradas devueltas. 0 es ilimitado
-v : Modo verboso
En el siguiente ejemplo buscamos todo lo existente dentro del sufijo de directorio "dc=newdomains,dc=com" autenticándonos
como rootdn bajo el DN "cn=Manager,dc=newdomains,dc=com":
# ldapsearch -xLLL -b "dc=newdomains,dc=com" -D "cn=Manager,dc=newdomains,dc=com" -W
Agregar un filtro a la búsqueda anterior para encontrar aquellos cuyo nombre contenga "juan" o en su apellido contenga "ruiz":
# ldapsearch -xLLL -b "dc=newdomains,dc=com" -D "cn=Manager,dc=newdomains,dc=com" \

> -W "(|(cn=*juan)(sn=*ruiz))"
OpenSourceCollege
Linux for SysAdmins
Página 379
Source Linux
1. Implementar una libreta de direcciones básica para ser consultada desde Outlook Express, Microsoft Outlook u otro cliente
de correo con soporte LDAP para libretas de contactos.
OpenSourceCollege
Linux for SysAdmins
Página 380
Source Linux
1. Implementar una libreta de direcciones básica para ser consultada desde Outlook Express, Microsoft Outlook u otro cliente
de correo con soporte LDAP para libretas de contactos.
+ En un sistema CentOS tras instalar OpenLDAP dejando intacto su archivo de configuración, editar el archivo
/etc/openldap/slapd.conf para agregar lo siguiente al final del mismo:
database bdb
suffix "dc=consultorianet,dc=com"
rootdn "cn=admin,dc=consultorianet,dc=com"
rootpw {SSHA}kJhc0B7zQW16lAaVv13cnE86V5zjew7I
directory /var/lib/ldap/consultorianet.com
mode 0770
index objectClass eq,pres

index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
+ El password especificado en la directiva rootpw debió ser creado como sigue:
# slappasswd -h {SSHA}
+ Crearemos el contenido base del directorio creando un archivo LDIF (Ejm: /root/base.ldif) con un contenido como el
siguiente:
dn: dc=consultorianet,dc=com
objectClass: dcObject
objectClass: organization
dc: consultorianet
o: Libreta de direcciones de Consultorianet
dn: ou=libreta,dc=consultorianet,dc=com
ou: libreta
dn: cn=Angel Rengifo,ou=libreta,dc=consultorianet,dc=com

objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Angel Rengifo
sn: Rengifo
mail: arengifo@consultorianet.com
telephoneNumber: 4583539
mobile: 997835382
homePhone: 4583033
dn: cn=Juan Perez Quispe,ou=libreta,dc=consultorianet,dc=com

cn: Juan Perez Quispe
sn: Perez Quispe
mail: jperez311@gmail.com
mobile: 980726134
dn: cn=Lizbeth Rosales,ou=libreta,dc=consultorianet,dc=com

cn: Lizbeth Rosales
sn: Rosales
mail: liz_beth31@hotmail.com
mobile: 992134511
homePhone: 4431311
dn: cn=Alexis Pacheco,ou=libreta,dc=consultorianet,dc=com

cn: Alexis Pacheco
sn: Pacheco
OpenSourceCollege
Linux for SysAdmins
Página 381
Source Linux
mail: apacheco1981@hotmail.com
+ Creamos el directorio de la base de datos LDAP según la configuración hecha en slapd.conf:
# mkdir /var/lib/ldap/consultorianet.com
+ Nos aseguramos que OpenLDAP no esté en ejecución e insertamos el contenido del archivo LDIF al directorio
perteneciente a dc=consultorianet,dc=com:
# service ldap stop

# slapadd -l base.ldif -b dc=consultorianet,dc=com -v
+ Si el paso anterior terminó correctamente entonces nos toca corregir los permisos de la base de datos OpenLDAP al
usuario con el cual corre el demonio slapd:
# chown -R ldap:ldap /var/lib/ldap
+ Verificamos la sintaxis del archivo de configuración y si no hay ningún error iniciamos OpenLDAP, verificando luego que
éste haya arrancado correctamente:
# slaptest -u
# service ldap start
# ps -ef | grep slapd
# netstat -tnlp | grep 389
+ Comprobamos el contenido del directorio haciendo una búsqueda básica a la base dc=consultorianet,dc=com:
# ldapsearch -xLLL -b dc=consultorianet,dc=com
+ Si lo anterior ya retorna el contenido completo del directorio, entonces este servidor OpenLDAP ya está listo para ser
consultado desde un cliente de correo indicando los siguientes datos de conexión:
1. Servidor LDAP: La dirección IP de nuestro servidor OpenLDAP

2. ¿Requiere autenticación?: No requiere, sin embargo se podría utilizar las credenciales de rootdn para autenticarse.
3. Base de búsqueda: Especificar el DN base dc=consultorianet,dc=com
4. Utiliza SSL: No.
OpenSourceCollege
Linux for SysAdmins
Página 382
Source Linux
Unidad 19: Servidor de Correo Electrónico
19.1. Objetivos
✔ Conocer los componentes de un sistema de correo electrónico y propósito de cada uno de ellos.
✔ Saber implementar los servicios básicos POP3, IMAP y SMTP con componentes Open Source.
✔ Integrar herramientas de filtrado de Spam y Virus sobre los servicios de correo existentes.
✔ Implementar una herramienta de monitoreo y control de cuarentena de los correos electrónicos.
✔ Realizar una instalación y configuración básica de un Webmail para los usuarios remotos.
19.2. Servidor de autenticación, POP3, IMAP y SMTP

19.2.1 Conceptos básicos
¿Qué es un servidor de correo?

Es una aplicación que nos permite enviar mensajes (correos) de unos usuarios a otros, con independencia de la red que dichos
usuarios estén utilizando.
Para lograrlo se definen una serie de protocolos, cada uno con una finalidad concreta:
• SMTP, Simple Mail Transfer Protocol

Es el protocolo que se utiliza para que dos servidores de correo intercambien mensajes.
• POP, Post Office Protocol

Se utiliza para obtener los mensajes guardados en el servidor y pasárselos al usuario.
• IMAP, Internet Message Access Protocol

Su finalidad es la misma que la de POP, pero el funcionamiento y las funcionalidades que ofrecen son diferentes.
Así pues, un servidor de correo consta en realidad de dos servidores: un servidor SMTP que será el encargado de enviar y recibir
mensajes, y un servidor POP/IMAP que será el que permita a los usuarios obtener sus mensajes.
Para obtener los mensajes del servidor, los usuarios se sirven de clientes, es decir, programas que implementan un protocolo
POP/IMAP. En algunas ocasiones el cliente se ejecuta en la máquina del usuario (como el caso de Mozilla Thunderbird, Evolution,
Microsoft Outlook). Sin embargo existe otra posibilidad: que el cliente de correo no se ejecute en la máquina del usuario; es el caso de
los clientes vía web, como GMail, Hotmail, OpenWebmail, SquirrelMail o Terra. En ellos la arquitectura del servicio es más compleja:
En una máquina (A) tenemos el servidor SMTP y el servidor POP/IMAP. En otra (B) tenemos un servidor web con una aplicación cliente
POP/IMAP. El usuario conecta vía WEB con (B) y entonces el cliente POP/IMAP establece una conexión POP/IMAP con el servidor de
la máquina A; éste servidor le devuelve a B los mensajes del usuario, y una vez recibidos, el cliente genera una página web con los
mensajes recibidos. La página web se pasa al servidor web que será el que la envíe al explorador web del usuario.
En cualquier caso, los protocolos SMTP/POP/IMAP son inseguros en cuanto a que los mensajes viajan en claro por la red, es decir, es
fácil obtener nuestros mensajes y contraseñas. Para ello se suele añadir una capa SSL, es decir, un método de cifrado que puedan
implementar tanto el servidor como el cliente. En el caso del correo vía web se pueden utilizar dos capas SSL: una entre A y B y otra
entre el servidor web de B y el navegador web del usuario.
Tecnologías usadas
Este documento le guiará a través de los pasos a seguir para instalar y configurar un sistema de correo completo que consta de
diversos componentes como los mencionados a continuación:
• Postfix
El MTA o servidor SMTP para el envío y recepción de correos
• Cyrus IMAP
El servidor POP/IMAP usado por los usuarios para la lectura de correos
• Cyrus SASL
El servicio encargado de la autenticación
• MailScanner
El filtro de contenidos para los correos que eliminará el Spam y Virus
• ClamAV
OpenSourceCollege
Linux for SysAdmins
Página 383
Source Linux
El antivirus
• SpamAssassin
La avanzada herramienta antispam
• Horde
El Webmail completo y funcional
• MailWatch
El administrador de tráfico de correo y cuarentenas
19.2.2. Cyrus IMAP y SASL
Consideraciones iniciales
SASL son las siglas de Simple Authentication and Security Layer, un método para añadir soporte para la autenticación a protocolos
basados en la conexión que ha sido estandarizado por la IETF (Internet Engineering Task Force). Se usa en servidores (en este
caso Cyrus IMAP) para manejar las peticiones de autenticación de los clientes. Para ello, el protocolo incluye un comando para
identificar y autenticar un usuario contra un servidor y para, opcionalmente, negociar la protección de las subsiguientes
interacciones del protocolo. Si se negocia su uso, una capa de seguridad es añadida entre el protocolo y la conexión.
La librería SASL de Cyrus también usa la librería OpenSSL para cifrar los datos. El lector encontrará más información en la página
web de Cyrus SASL.
Instalación de Cyrus IMAP y SASL
En Red Hat / CentOS y derivados instalamos los paquetes:
# yum install cyrus-sasl cyrus-imapd -y
En Debian y derivados instalamos los paquetes:
# apt-get install sasl2-bin libsasl2-modules cyrus-imapd-2.2 cyrus-pop3d-2.2 cyrus-clients-2.2

cyrus-admin-2.2 -y
Configuración de Cyrus SASL

La configuración de Cyrus SASL se centrará principalmente en modificar los parámetros con los que se ejecutará el demonio
saslauthd. Específicamente necesitaremos que este demonio use el mecanismo de autenticación PAM, para lo cual debemos
modificar algún fichero de configuración del servicio correspondiente en cada distribución Linux.
En Debian y derivados el archivo a editar es /etc/default/saslauthd y modificamos la líneas que se mencionan a continuación:
START=YES
MECHANISMS="pam"
En Red Hat / CentOS y derivados el archivo a editar es /etc/sysconfig/saslauthd y modificamos la líneas que se mencionan a
continuación:
MECH="pam"
Configuración de Cyrus IMAP

La configuración de Cyrus IMAP es bastante sencilla, en realidad no se requiere modificar nada del fichero de configuración por
defecto que traen las distribuciones Linux pero procederemos a explicar algunas de las directivas que pueden resultar de interés
para el lector.
configdirectory
Permite definir la ruta al directorio de la configuración IMAP del servicio. En este directorio se almacena información variada sobre
los buzones de los usuarios como por ejemplo la cuota, muchos de ellos presentados como archivos binarios indexados de la base
de datos Berkeley.
Sintaxis : configdirectory: archivo
Ejemplo:
configdirectory: /var/lib/imap
OpenSourceCollege
Linux for SysAdmins
Página 384
Source Linux
defaultpartition
Esta directiva permite definir la partición por defecto usada para la creación de nuevos buzones. El nombre que recibe es definido
en una directiva partition-NOMBRE. Es en esta partición donde se almacena el contenido de los buzones de todos los usuarios.
Sintaxis : defaultpartition: nombre
Ejemplo:
defaultpartition: default
partition-NOMBRE
Esta directiva permite definir un nombre de partición que apunta a una ruta de directorio dentro del sistema de archivos.
Sintaxis : partition-NOMBRE: ruta_directorio
Ejemplo:
partition-default: /var/spool/imap
unixhierarchysep
Esta directiva permite que los buzones de IMAP puedan tener el caracter punto "." como parte de su nombre. Esto es porque por
defecto Cyrus IMAP usa el punto "." como delimitador de buzones en sus diversos niveles de jerarquía y asignando el valor yes
a esta directiva evitará interpretaciones incorrectas respecto a dicho caracter especial.
Sintaxis : unixhierarchysep: yes|no
Ejemplo:
unixhierarchysep: yes
admins:
Esta directiva define una lista de usuarios del sistema que tendrán los mayores privilegios de administrador sobre todos los
servicios que ofrezca Cyrus IMAP.
Sintaxis : admins: usuario [usuario] [usuario] ...
Ejemplo:
admins: cyrus
allowplaintext
Esta directiva permite que las autenticaciones se puedan dar en texto plano pues es la única forma soportada por SASL PLAIN.
Sintaxis : allowplaintext: yes|no
Asignar su valor en yes para asegurar la compatibilidad con el valor de la siguiente directiva:
allowplaintext: yes
sasl_mech_list
Esta directiva especifica la lista de mecanismos SASL permitidos para que los usuarios puedan autenticarse.
Sintaxis : sasl_mech_list: mecanismo [mecanismo] [mecanismo] ...
Ejemplo:
sasl_mech_list: PLAIN
OpenSourceCollege
Linux for SysAdmins
Página 385
Source Linux
sasl_pwcheck_method
Esta directiva permite definir el método que se usará para realizar el proceso de autenticación. Algunos valores posibles son
auxprop y saslauthd pero se procederá a usar el primero de ellos. El segundo puede usarse cuando se tiene la necesidad de
usar mecanismos más seguros como el caso de CRAM-MD5 o DIGEST-MD5
Sintaxis : sasl_pwcheck_method: método
Ejemplo:
sasl_pwcheck_method: saslauthd
autocreatequota
Esta directiva define el valor en KB del tamaño de la cuota que será aplicado automáticamente a los buzones recién creados. Si
tiene un valor no positivo entonces se asumirá que la cuota es ilimitada.
Sintaxis : autocreatequota: numero
En el ejemplo se configura una cuota de 10 MB:
autocreatequota: 10240
quotawarn
Esta directiva define en qué porcentaje de la cuota de un buzón el sistema Cyrus IMAP empezará a generar advertencias.
Sintaxis : quotawarn: porcentaje
Ejemplo:
quotawarn: 90
tls_cert_file
Esta directiva la ruta del archivo de certificado global usado para todos los servicios (POP3, IMAP).
Sintaxis : tls_cert_file: archivo
Ejemplo:
tls_cert_file: /etc/cyrus-imapd/mail.newdomains.com-cert.pem
tls_key_file
Esta directiva la ruta de la llave privada que pertenece al certificado global usado para todos los servicios (POP3, IMAP).
Sintaxis : tls_key_file: archivo
Ejemplo:
tls_key_file: /etc/cyrus-imapd/mail.newdomains.com-key.pem
Importante:
Para que el soporte SSL/TLS de POP3 e IMAP sea activado, se requiere habilitar en el archivo /etc/cyrus.conf las líneas siguientes:
imaps cmd="imapd -s -U 30" listen="imaps" prefork=0 maxchild=100

pop3s cmd="pop3d -s -U 30" listen="pop3s" prefork=0 maxchild=50
Estas han sido algunas de las directivas que comúnmente requieren ser modificadas respecto a sus valores por defecto. La
documentación completa de todas las demás directivas se pueden encontrar en imapd.conf(5).
OpenSourceCollege
Linux for SysAdmins
Página 386
Source Linux
Iniciando los servicios
Una vez configurados ambos servicios de Cyrus procederemos a iniciarlos.
# service cyrus-imapd start
# invoke-rc.d cyrus2.2 start

Administrando Cyrus IMAP
Una vez configurado Cyrus IMAP e iniciado el servicio es necesario poder realizar una serie de operaciones administrativas como
por ejemplo crear buzones, eliminar buzones, cambiar la cuota, entre otros. Esto es posible a través de la herramienta cyradm la
cual debe ser invocada como sigue:
# cyradm --user cyrus localhost
En el ejemplo de arriba se especifica al usuario cyrus con el parámetro --user debido a que es esa la cuenta que se configuró
con permisos de administrador en el archivo /etc/imapd.conf. La ejecución de dicho comando nos preguntará una clave que es la
que tiene asignada dicho usuario en el sistema según /etc/passwd.
Una vez que nos autenticamos con la contraseña correspondiente se nos presentará una shell con un prompt en el cual podremos
consultar la ayuda de los comandos disponibles como sigue:
localhost> ?
authenticate, login, auth authenticate to server
chdir, cd change current directory
createmailbox, create, cm create mailbox
deleteaclmailbox, deleteacl, dam remove ACLs from mailbox
deletemailbox, delete, dm delete mailbox
disconnect, disc disconnect from current server
exit, quit exit cyradm
help, ? show commands
info display mailbox/server metadata
listacl, lam, listaclmailbox list ACLs on mailbox
listmailbox, lm list mailboxes
listquota, lq list quotas on specified root
listquotaroot, lqr, lqm show quota roots and quotas for mailbox
reconstruct reconstruct mailbox (if supported)
renamemailbox, rename, renm rename (and optionally relocate) mailbox
server, servername, connect show current server or connect to server
setaclmailbox, sam, setacl set ACLs on mailbox
setinfo set server metadata
setquota, sq set quota on mailbox or resource
version, ver display version info of current server
Algunos comandos los explicamos brevemente por ser los más usados:
lm [patron]
Hace un listado de los buzones que coincidan con un patrón opcional expresado como wildcars.
Ejemplo:
localhost> lm *rios*
lam <patron>
Muestra los permisos de los buzones que coincidan con un patrón opcional expresado como
wildcars. Ejemplo:
localhost> lam user.arios
sam <buzon> <usuario> <permisos>

Asigna permisos a un buzón determinado. Los permisos existentes son:
• l (lookup): el usuario puede ver que el buzón de correo existe

• r (read): el usuario puede leer el buzón de correo. El usuario puede seleccionar el
buzón, leer los datos contenidos, llevar a cabo búsquedas y copiar mensajes de ese buzón
• s (seen): mantiene el estado leído por usuario. Se preservan los flags Seen y Recent
OpenSourceCollege
Linux for SysAdmins
Página 387
Source Linux
para cada usuario
• w (write): el usuario puede modificar los flags excepto Seen y Deleted (los cuales son
controlados por otros permisos)
• i (insert): el usuario puede insertar mensajes en el buzón de correo
• p (post): el usuario puede mandar correo a la dirección de envío del buzón. Este permiso
difiere del permiso i en que el sistema de envío inserta información de seguimiento en
los mensajes envíados
• c (create): el usuario puede crear subcarpetas en el buzón
• d (delete): el usuario puede alterar el flag Deleted, expirar correos y borrar o
renombrar el buzón
• a (administer): el usuario puede cambiar la ACL del buzón
• all (todos): posee todos los permisos anteriores
Ejemplos:
localhost> sam user.arios cyrus all

localhost> sam user.nposada arengifo lrsdc
cm <buzón>
Crea un buzón de un usuario determinado. Especificar el separador "." si "unixhierarchysep: no"
o el separador "/" si se usa "unixhierarchysep: yes". Ejemplo:
localhost> cm user.amendoza
localhost> cm user/arengifo
dm <buzón>
Elimina un buzón. Su uso es similar al comando cm. Ejemplo:
localhost> dm user.amendoza
localhost> dm user/arengifo
lq <buzón>
Muestra el estado de la cuota de un buzón especifico. Ejemplo:
localhost> lq user.jchavez
sq <buzón> [numero]
Asigna una cuota en KB a un buzón específico. Si se omite el tamaño de la cuota se asigna
ilimitado. En el primer ejemplo se asigna 15 MB de cuota y en el segundo ejemplo se le da
una cuota ilimitada:
localhost> sq user.jchavez 15360

localhost> sq user.arengifo
19.2.3. El MTA Postfix
Consideraciones iniciales
El MTA (Mail Transportation Agent) Postfix pretende ser rápido, fácil de administrar y seguro, a la vez que suficientemente
compatible con Sendmail como para que los usuarios existentes no se asusten. Por lo tanto, externamente mantiene el estilo de
Sendmail, mientras que internamente es completamente diferente.
A diferencia de Sendmail, Postfix no es un programa monolítico, sino una combinación de pequeños programas, cada uno de los
cuales lleva a cabo una función especializada. En este documento, el lector encontrará la información necesaria para tener el
sistema funcionando junto a otros componentes que completan la instalación de un sistema de correo electrónico. Puede
encontrarse más información sobre Postfix en la documentación online de su website.
Instalación de Postfix
En Red Hat / CentOS y derivados instalamos los paquetes:
# yum install postfix -y
En Debian y derivados instalamos los paquetes:
# apt-get install postfix postfix-pcre -y
Configuración del MTA

La configuración de Postfix se centra básicamente en los archivos /etc/postfix/main.cf y /etc/postfix/master.cf de los cuales en el
OpenSourceCollege
Linux for SysAdmins
Página 388
Source Linux
primero nos centraremos en este documento.
El archivo /etc/postfix/main.cf contiene las directivas que afectan directamente a las funcionalidades de Postfix dentro de una red, tal
como el dominio de correo que atenderá, las opciones de relay, la autenticación de usuarios para el servicio SMTP, entre otros. Es
por ello que se mostrarán una serie de directivas que suelen ser de las más comunes a la hora de configurar un servidor de envío y
recepción de correos.
mydomain
Esta directiva el nombre de dominio asociado al servidor. Su valor puede ser invocado en otras secciones del archivo de
configuración.
Sintaxis : mydomain = dominio
Ejemplo:
mydomain = newdomains.com
myhostname
Esta directiva define el nombre del servidor usado para el funcionamiento normal en los diálogos SMTP.
Sintaxis : myhostname = nombre_DNS
Ejemplos:
myhostname = mail.newdomains.com
myhostname = mail.$mydomain
mydestination
Esta directiva define una lista de dominios que serán aceptados por el servidor como destino final válido
Sintaxis : mydestination = dominio [,dominio] [,dominio]
Ejemplo:
mydestination = $mydomain, $myhostname, localhost.$mydomain, newdomains.org, newdomains.net
myorigin
Esta directiva permite definir el dominio desde el cual se aparenta que se originan los correos enviados a través del servidor.
Sintaxis : myorigin = dominio
Ejemplo:
myorigin = newdomains.net
mynetworks
Esta directiva define las direcciones de red que se consideran de mayor confianza que otros clientes externos. Por lo general a los
clientes que coinciden con estas redes se les permite el relay a través del servidor.
Sintaxis : mynetworks = direccion [,dirección] [,dirección]
Ejemplo:
mynetworks = 127.0.0.0/8, 192.168.1.0/24
alias_maps
Esta directiva define la fuente de alias para los buzones de correo del servidor.
Sintaxis : alias_maps = origen
En el siguiente ejemplo se general un archivo indexado (hash) a partir de /etc/aliases:
OpenSourceCollege
Linux for SysAdmins
Página 389
Source Linux
alias_maps = hash:/etc/aliases
Otros tipos posibles de fuentes además de archivos indexados puede ser obtenida de la salida del comando postconf -m y el
uso de cada uno de esos tipos puede ser estudiado en postconf(1).
mailbox_transport
Esta directiva define un agente externo que se encargará de la entrega de los mensajes hacia el buzón correspondiente de los
usuarios.
Sintaxis : mailbox_transport = aplicación
En el siguiente ejemplo se indica la ruta del socket de Cyrus IMAP el mismo que se define en el archivo /etc/cyrus.conf debido a que
en este documento se asume la integración de Postfix con Cyrus IMAP:
mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp
smtpd_sasl_auth_enable
Esta directiva permite activar la autenticación SMTP para los usuarios a la hora de intentar enviar correos a través del servidor.
Sintaxis : smtpd_sasl_auth_enable = yes|no
Ejemplo:
smtpd_sasl_auth_enable = yes
header_checks
Esta directiva define la fuente desde la cual se leen una serie de condiciones y acciones a tomar sobre las cabeceras de los
mensajes de correo una vez que son recibidos por el servidor pero aún no enviados al buzón de los usuarios.
Sintaxis : header_checks = origen
En el siguiente ejemplo se le dice a Postfix que cualquier mensaje recibido (saliente o entrante) sea automáticamente enviado a la
cola hold del sistema de modo tal que se quede por así decirlo estancado para que luego MailScanner lo recoja, analice y envíe
según su destino ya definido.
header_checks = regexp:/etc/postfix/header_checks
Siendo el contenido del archivo /etc/postfix/header_checks el siguiente:
/^Received:/ HOLD
message_size_limit
Esta directiva establece el tamaño máximo en bytes que se Postfix permite recibir.
Sintaxis : message_size_limit = numero
En el ejemplo se define un tamaño límite de 20 MB:
message_size_limit 20971520
smtpd_helo_required
Esta directiva define si es obligatorio o no que los clientes realicen la fase HELO propia del diálogo SMTP. Muchos spammers
omiten este paso mientras que los servidores de correo legítimos casi nunca lo dejan de lado.
Sintaxis : smtpd_helo_required = yes|no
Ejemplo:
smtpd_helo_required = yes
OpenSourceCollege
Linux for SysAdmins
Página 390
Source Linux
smtpd_client_restrictions
Esta directiva define una serie de condiciones que debe cumplir un remitente en la fase cliente para poder decidir una acción a
tomar. La fase de cliente analiza la naturaleza del origen de su dirección de red (dirección IP, resolución inversa, etc.).
Las condiciones se pueden especificar en una única línea o en líneas distintas cada una empezando por al menos un espacio en
blanco. El orden de las condiciones según se especifican es importante pues tienen naturaleza jerárquica.
Sintaxis : smtpd_client_restrictions = condición [,condición] [,condición]
Algunas de las condiciones válidas para esta fase cliente son:
permit_mynetworks
Permite el paso a los clientes que coincidan con $mynetworks
permit_sasl_authenticated
Permite el paso a los clientes autenticados por SMTP
reject_unknown_client
Rechaza a los clientes que no cuenten con una resolución inversa consistente
reject_rbl_client RBL
Rechaza a los clientes que se encuentren en alguna de las listas negras especificadas
En el siguiente ejemplo se considera clientes de confianza a quienes estén definidos en la directiva $mynetworks o se hayan
autenticado con un usuario y contraseña válidos, mientras que se rechazará a quienes pertenezcan a alguna lista negra de las
indicadas debajo:
smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client list.dsbl.org
smtpd_helo_restrictions
Esta directiva define una serie de condiciones que debe cumplir un remitente en la fase HELO para poder decidir una acción a
tomar. En tal fase se analiza la conformidad de los parámetros usados en el comando HELO dentro del diálogo SMTP.
Sintaxis : smtpd_helo_restrictions = condición [,condición] [,condición]
permit_mynetworks
reject_non_fqdn_hostname
Rechaza a quienes usen un nombre no DNS en el HELO tal como: mail, server01, mailer u otros
que carezcan de la sección host.dominio correspondiente. En Postfix 2.3 en adelante la
condición es reject_non_fqdn_helo_hostname
reject_invalid_hostname
Rechaza a quienes usen un nombre DNS (host.dominio) pero con valores inválidos tales como:
1mail.domain.com, mail.new_domain.com, smtp.españa.com u otros que en general no califiquen
como un nombre DNS válido de Internet. En Postfix 2.3 en adelante la condición es
reject_invalid_helo_hostname
reject_unknown_hostname
Rechaza a quienes usen un nombre DNS válido pero inexistente en Internet. En Postfix 2.3 en
adelante la condición es reject_unknown_helo_hostname
En el siguiente ejemplo se considera clientes de confianza a quienes estén definidos en la directiva $mynetworks o se hayan
autenticado con un usuario y contraseña válidos o usen nombres DNS válidos en el HELO:
OpenSourceCollege
Linux for SysAdmins
Página 391
Source Linux
smtpd_helo_restrictions =
permit_mynetworks,
reject_non_fqdn_hostname,
reject_invalid_hostname
smtpd_sender_restrictions
Esta directiva define una serie de condiciones que debe cumplir un cliente en la fase remitente para poder decidir una acción a
tomar. En tal fase se analiza la conformidad de la dirección de correo usada como remitente en el diálogo SMTP.
Sintaxis : smtpd_sender_restrictions = condición [,condición] [,condición]
permit_mynetworks
reject_non_fqdn_sender
Rechaza a quienes usen una forma incorrecta de dirección e-mail como remitente que no cuente
con la sección usuario y dominio respectivo (usuario@dominio).
reject_unknown_sender_domain
Rechaza a quienes usen una dirección e-mail como remitente de un dominio inexistente.
En el siguiente ejemplo se rechazará en cambio a quienes no usen una dirección válida y en un dominio existente como e-mail
remitente:
smtpd_sender_restrictions =
reject_non_fqdn_sender,
reject_unknown_sender_domain
smtpd_recipient_restrictions
Esta directiva define una serie de condiciones que debe cumplir un cliente en la fase del destinatario para poder decidir una acción
a tomar. En tal fase se analiza la conformidad de la dirección de correo usada como destinatario en el diálogo SMTP.
Esta fase permite controlar el relay a los clientes ya que es la que define si finalmente el mensaje será enviado o no a su
destinatario final por lo que es donde nunca deberían faltar las restricciones mínimas.
Sintaxis : smtpd_recipient_restrictions = condición [,condición] [,condición]
permit_mynetworks
reject_non_fqdn_recipient
Rechaza a quienes usen una forma incorrecta de dirección e-mail como destinatario que no
cuente con la sección usuario y dominio respectivo (usuario@dominio)
reject_unknown_recipient_domain
Rechaza a quienes usen una dirección e-mail como destinatario de un dominio inexistente.
reject_unauth_destination
Rechaza a quienes intenten enviar correo a alguna dirección externa, es decir a un dominio no
OpenSourceCollege
Linux for SysAdmins
Página 392
Source Linux
servido por Postfix
En el siguiente ejemplo se rechazará en cambio a quienes no usen una dirección válida y en un dominio existente como e-mail
destinatario. Luego que se verifique lo primero el servidor será permisivo con los clientes que coincidan con $mynetworks o se
hayan autenticado por SMTP, y finalmente se protege de ser un relay abierto al rechazar a quienes intenten enviar correo a través
de nuestro servidor a un dominio externo no servido por Postfix a menos que no haya cumplido alguna de las reglas permisivas
anteriores.
smtpd_sender_restrictions =
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit_mynetworks,
reject_unauth_destination
smtpd_use_tls
Esta directiva habilita el soporte opcional de TLS/SSL para la comunicación con los clientes. Esto quiere decir que el usuario puede
elegir entre usar o no TLS/SSL para la comunicación entera con el servidor.
Sintaxis : smtpd_use_tls = yes|no
Ejemplo:
smtpd_use_tls = yes
smtpd_tls_auth_only
Cuando el soporte de TLS/SSL es opcional (ver directiva anterior) esta directiva permite controlar si se acepta o no la autenticación
en un canal inseguro, es decir no cifrado o sin SSL/TLS.
Sintaxis : smtpd_tls_auth_only = yes|no
Ejemplo:
smtpd_tls_auth_only = yes
smtpd_tls_cert_file
Esta directiva define la ruta del archivo de certificado en formato PEM que usará Postfix para conexiones TLS/SSL de los clientes.
Sintaxis : smtpd_tls_cert_file = archivo
Ejemplo:
smtpd_tls_cert_file = /etc/postfix/ssl/mail.newdomains.com-cert.pem
smtpd_tls_key_file
Esta directiva define la ruta de la llave privada del certificado que usará Postfix para conexiones TLS/SSL de los clientes.
Sintaxis : smtpd_tls_key_file = archivo
Ejemplo:
smtpd_tls_key_file = /etc/postfix/ssl/mail.newdomains.com-key.pem
Postfix y Cyrus SASL

Una vez editado el archivo de configuración /etc/postfix/main.cf debe generarse un archivo adicional de configuración el cual
asociará Postfix con el demonio saslauthd para las tareas de autenticación de los clientes en el momento de querer enviar
correos a través del servidor.
El archivo de nombre smtpd.conf por lo general debe ser creado en el directorio /usr/lib/sasl2 pero en algunas distribuciones como
Debian esto difiere siendo para este caso específico el directorio /etc/postfix/sasl. El contenido del archivo debe ser como sigue:
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
OpenSourceCollege
Linux for SysAdmins
Página 393
Source Linux
loglevel: 3
Estas líneas de configuración le dice a Postfix que los mecanismos válidos a aceptar de los clientes son PLAIN y LOGIN a través
del método saslauthd que representa al demonio del mismo nombre.
Definitivamente estas no son todas las directivas de configuración de Postfix ni mucho menos, pero la documentación sobre la gran
mayoría de ellas puede ser encontrada en postconf(5) a donde el lector debería dirigirse a fin de complementar el estudio de
algunas características específicas de su interés no cubiertas en este documento.
Administración de Postfix
A continuación se entrará en el estudio de algunas operaciones comunes de caracter administrativo que son importantes para dar
mantenimiento al servidor.
Una de estas operaciones implica el manipular el estado del MTA y verificar la correcta configuración una vez que se encuentra en
marcha. Para ello nos basaremos en el comando postfix el cual recibe algunos parámetros como los descritos a continuación:
check
Comprueba la conformidad de los permisos y propietarios de ciertos archivos/directorios así como también su
existencia
start
Inicia el MTA con un previo chequeo igual que el descrito arriba
stop
Detiene el MTA de manera correcta y ordenada
abort
Detiene el MTA de manera abrupta e inmediata
reload
Relee su archivo de configuración haciendo efectivo los cambios del mismo
flush
Intenta enviar todos los mensajes que han sido encolados por errores previos diversos puestos en la cola
deferred
Así el siguiente ejemplo hará un chequeo general a la consistencia de archivos/directorios respecto a sus permisos y luego hará
efectivo los cambios realizados al archivo de configuración:
# postfix check
# postfix reload
postfix/postfix-script: refreshing the Postfix mail system
Información adicional sobre este comando puede ser encontrado en postfix(1).
Si el estado del MTA es correcto respecto a su configuración y entorno de trabajo con archivos y directorios no está de más poder
verificar el estado de la cola de mensajes siendo esto posible con el comando mailq:
# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
A4EEC67D06B 16238 Sat Sep 1 05:06:13 sunilb@ajantapharma.com
(host mail.newdomains.com[/var/run/cyrus/socket/lmtp] said: 452 4.2.2 Over quota (in reply to
RCPT TO command))
info@newdomains.com
48F0A67D06C 1300 Sat Sep 1 07:54:00 giveitup39090@ingraham.org

RCPT TO command))
tcastro@newdomains.com
C105D67D066 1379 Sat Sep 1 02:52:43 ootakei@kmc-usa.com

RCPT TO command))
ellanos@newdomains.com
-- 20 Kbytes in 3 Requests.
OpenSourceCollege
Linux for SysAdmins
Página 394
Source Linux
En el ejemplo anterior se aprecia 3 mensajes encolados, aparentemente los buzones a los que se intentaba enviar mensajes en el
dominio newdomains.com se han excedido en su cuota. Para ello sería de utilidad aumentar la cuota de dichos buzones en Cyrus y
luego ejecutar postfix flush.
Entre otra de las operaciones administrativas podemos encontrar el mantenimiento de los alias del sistema de correo que
permitirán crear distintos nombres para uno o más buzones en particular así como crear grupos simples de distribución. Para ello
ha de modificarse el archivo /etc/aliases el cual tiene la siguiente forma:
alias: destino [,destino] [,destino] ...
La primera columna indica el nombre del alias, es decir el nombre del buzón al que originalmente estaba destinado un mensaje, y
los valores especificados a la derecha indican los destinos reales a los cuales se enviará el mensaje de correo.
En el siguiente ejemplo se crea una serie de alias imprescindibles los cuales son destinados finalmente al usuario root:
postmaster: root
abuse: root
mailer-daemon: root
hostmaster: root
webmaster: root
noc: root
En el ejemplo anterior se crean alias individuales destinados cada uno al usuario root solamente. Pero también es posible crear
grupos que se asemejen a listas de distribución en el cual un alias permitirá enviar una copia del mensaje a más de un usuario del
sistema tal como se aprecia debajo:
sistemas: achavez, rdavila, jchacon, ncespedes, postmaster

ventas: rhurtado, farismendi, juanperez, gerentelima
Una vez que se hayan realizado los cambios correspondientes en el archivo de alias se requiere regenerar a partir de éste una
versión indexada del mismo el cual será el que Postfix use en realidad por motivos de mejor desempeño. Este archivo indexado por
lo general será "/etc/aliases.db" y se actualiza con cualquiera de los dos comandos mostrados a continuación:
# postmap hash:/etc/aliases
# newaliases
Una vez que ha sido compilado y actualizado nuevamente el archivo de alias se necesita recargar Postfix como sigue:
# postfix reload
Finalmente como es normal en la administración de cualquier servicio el monitoreo de los logs es siempre una labor de gran
importancia. Para esto se tiene que el registro de actividad de Postfix suele ser almacenado en archivos como /var/log/maillog, /var/
log/mail.log, /var/log/mail u otro archivo similar dependiendo de la distribución Linux con la que se trabaje, el cual debe ser
constantemente vigilado como sigue:
# tail -f /var/log/mail.log
OpenSourceCollege
Linux for SysAdmins
Página 395
Source Linux
19.3. Filtro de contenidos, Antispam, Antivirus
Componentes necesarios
La configuración de un servidor de mensajería no sería completo si no cuenta con alguna herramienta de filtro de contenidos, la misma
que permita reducir en gran medida los correos no deseados tal como aquellos infectados por algún virus o los que contengan algún
tipo de publicidad no solicitada comúnmente conocido como Spam.
Es por ello que se requiere la instalación de un filtro de contenidos como MailScanner el cual se encargará de analizar cada correo
entrante y saliente bajo ciertas reglas que el administrador lo configure previamente.
MailScanner no es una herramienta que directamente analice y desinfecte virus, ni tampoco detecte Spam, sino son ClamAV y
SpamAssassin los que realizan dichas labores respectivamente.
Sin embargo MailScanner se encargará de tomar cada correo de la cola de Postfix y evaluarlo bajo una lista de condiciones y de ser
necesario invocará a SpamAssassin y/o ClamAV para completar su análisis, pudiendo luego opcionalmente tomar acciones como
eliminar el mensaje, enviarlo a una cuarentena o enviarlo al destinatario final.
Respecto a ClamAV podemos agregar nada más que nos basaremos en su configuración por defecto y debemos asegurarnos que su
demonio respectivo se encuentre iniciado.
19.3.1. Filtro de contenidos MailScanner
Instalación de MailScanner
MailScanner puede ser descargado desde su Web oficial:
http://www.mailscanner.info
En este en la sección Downloads existen paquetes para distribuciones Red Hat, SuSE y derivados. Todos estos paquetes son un
tarball el cual debe ser descomprimido y desde adentro ejecutar el script install.sh como sigue:
# tar zxf MailScanner-VERSION.tar.gz

# cd MailScanner-VERSION
# ./install.sh
Este script se encargará de hacer todo el trabajo de instalación y configuración predeterminada de MailScanner en el sistema,
colocando normalmente los binarios y otras librerías debajo de /usr y la configuración debajo de /etc/MailScanner.
Sin embargo si descargó el paquete MailScanner de la versión "Solaris / BSD / Other Linux / Other Unix" se tendrá que la
instalación de manera predeterminada se hará debajo del directorio /opt/MailScanner. Asimismo se debe contemplar el hecho de
crear uno mismo su script SySV en /etc/init.d para iniciar MailScanner desde su directorio de instalación.
Configurando MailScanner
El archivo de configuración por defecto suele ser ubicado en /etc/MailScanner/MailScanner.conf. A continuación la descripción de
directivas de MailScanner:
%org-name%
Esta directiva define simplemente un nombre de la organización la cual administra el servicio. No debe contener espacios en
blanco.
Sintaxis : %org-name% = nombre
Ejemplo:
%org-name% = NewDomains
%org-long-name%
Esta directiva define un nombre largo de la organización el mismo que aparecerá como parte de la firma en los reportes generados
por MailScanner. Puede contener espacios en blanco.
Sintaxis : %org-long-name% = nombres
Ejemplo:
%org-long-name% = New Domains Technologies Inc.
%web-site%
OpenSourceCollege
Linux for SysAdmins
Página 396
Source Linux
Esta directiva define el sitio Web de la organización, el mismo que se muestra junto con el nombre largo de la organización como
parte de la firma de algunos reportes.
Sintaxis : %web-site% = website
Ejemplo:
%web-site% = http://www.newdomains.com
%report-dir%
Esta directiva define la ruta del directorio que contiene los reportes de MailScanner. Por lo general existe un directorio por cada
idioma soportado y esta directiva pretende definir el idioma de los reportes.
Sintaxis : %report-dir% = ruta_directorio
Ejemplo:
%report-dir% = /etc/MailScanner/reports/es
Run As User
Run As Group
Estas directivas definen el usuario y grupo bajo el cual se ejecutará MailScanner.
Sintaxis : Run As User = usuario

Sintaxis : Run As Group = grupo
Ejemplo:
Run As User = postfix

Run As Group = mail
Incoming Queue Dir

Esta directiva define la ruta del directorio de donde MailScanner recogerá los correos para su posterior análisis. Considérese que
debe asignarse la ruta del directorio de la cola hold de Postfix dado que éste colocará ahí cada correo recibido según la
configuración anterior que se hizo en la directiva header_checks.
Sintaxis : Incoming Queue Dir = ruta_directorio
Ejemplo:
Incoming Queue Dir = /var/spool/postfix/hold
Outgoing Queue Dir

Esta directiva define la ruta del directorio donde MailScanner colocará los correos ya analizados. Considérese que debe asignarse
la ruta del directorio de la cola incoming de Postfix dado que éste recogerá de ahí cada correo que encuentre para su envío
correspondiente.
Sintaxis : Outgoing Queue Dir = ruta_directorio
Ejemplo:
Outgoing Queue Dir = /var/spool/postfix/incoming
Incoming Work Dir

Esta directiva define la ruta del directorio donde MailScanner temporalmente desempaqueterá los correos durante su proceso de
análisis.
Sintaxis : Incoming Work Dir = ruta_directorio
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Página 397
Source Linux
Incoming Work Dir = /var/spool/MailScanner/incoming
Quarantine Dir
Esta directiva define la ruta del directorio de la cuarentena de MailScanner.
Sintaxis : Quarantine Dir = ruta_directorio
Ejemplo:
Quarantine Dir = /var/spool/MailScanner/quarantine
MTA
Esta directiva define cuál es el MTA que se integrará con MailScanner. Su valor debe ser postfix, sendmail, exim o zmailer
Sintaxis : MTA = nombre
Ejemplo:
MTA = postfix
Incoming Work User

Incoming Work Group
Incoming Work Permissions
Esta directiva define los propietarios y permisos del directorio de trabajo de MailScanner definido en Incoming Work Dir.
Sintaxis : Incoming Work User = usuario

Sintaxis : Incoming Work Group = grupo
Sintaxis : Incoming Work Permissions = permisos
Ejemplo:
Incoming Work User = postfix

Incoming Work Group = mail
Incoming Work Permissions = 0660
Quarantine User
Quarantine Group
Quarantine Permissions
Esta directiva define los propietarios y permisos del directorio de la cuarentena de MailScanner definido en Quarantine Dir.
Sintaxis : Quarantine User = usuario

Sintaxis : Quarantine Group = grupo
Sintaxis : Quarantine Permissions = permisos
A fin de que más adelante MailWatch que es ejecutado a través de Apache sea capaz de modificar los archivos de la cuarentena se
asigna el grupo de ejecución al mismo del proceso Apache, y se configura al usuario postfix como miembro de ese grupo.
Quarantine User = postfix

Quarantine Group = www-data
Quarantine Permissions = 0660
Hacemos miembro del grupo de Apache al usuario postfix:
# usermod -G www-data,mail,sasl postfix
Virus Scanning
Esta directiva define si se analizarán o no los correos con un antivirus externo.
Sintaxis : Virus Scanning = yes|no
Ejemplo:
OpenSourceCollege
Linux for SysAdmins
Página 398
Source Linux
Virus Scanning = yes
Virus Scanners
Esta directiva define el antivirus externo a usar. Algunos valores posibles válidos son clamav, sophos, mcafee, etrust, panda,
trend antivir, entre otros.
Sintaxis : Virus Scanners = nombre
Ejemplo:
Virus Scanners = clamav
Allow Filenames
Deny Filenames
Esta directiva define qué tipos de archivos se permiten o se deniegan en los correos como adjuntos. Puede tomar como valor las
expresiones regulares que hagan coincidencia con un tipo de archivo.
Sintaxis : Allow Filenames = regexp

Sintaxis : Deny Filenames = regexp
Ejemplo:
Deny Filenames = \.exe \.pif \.bat \.scr
Filename Rules
Esta directiva define la ruta de un archivo donde se establecerán con mayor detalle cada uno de los tipos de archivos permitidos o
denegados de manera similar a las dos directivas anteriores.
Sintaxis : Filename Rules = ruta_archivo
Ejemplo:
Filename Rules = %etc-dir%/filename.rules.conf
El archivo al cual se hace referencia debe contener 4 campos de los cuales el primero es la acción a tomar (allow o deny), el
segundo una expresión regular que coincida con el archivo, el tercer campo un mensaje de log y el cuarto campo es un mensaje
que será enviado al destinatario como reporte. Los campos deben estar estrictamente separados por tabulaciones como en el
siguiente ejemplo:
deny pretty\s+park\.exe$ "Pretty Park" virus "Pretty Park" virus found in attachments
Quarantine Infections
Esta directiva decide si se enviarán a cuarentena o no los correos que contengan archivos infectados.
Sintaxis : Quarantine Infections = yes|no
Ejemplo:
Quarantine Infections = yes
Spam Checks
Esta directiva decide si se buscará o no Spam en los mensajes.
Sintaxis : Spam Checks = yes|no
Ejemplo:
Spam Checks = yes
OpenSourceCollege
Linux for SysAdmins
Página 399
Source Linux
Spam List
Esta directiva define una serie de listas negras de Internet a las cuales se consultará si pertenecen o no las direcciones IP de los
remitentes. Los nombres que se definen en esta directiva están definidos en el archivo /etc/MailScanner/spam.lists.conf.
Sintaxis : Spam List = nombre [nombre] [nombre] ...
Ejemplo:
Spam List = SBL+XBL spamhaus.org spamhaus-XBL SBL+XBL spamcop.net NJABL
Spam Domain List

Esta directiva define una serie de listas negras de Internet a las cuales se consultará si pertenecen o no los dominios de los
remitentes. Los nombres que se definen en esta directiva están definidos en el archivo /etc/MailScanner/spam.lists.conf.
Sintaxis : Spam Domain List = nombre [nombre] [nombre] ...
Ejemplo:
Spam Domain List = RFC-IGNORANT-DSN RFC-IGNORANT-POSTMASTER RFC-IGNORANT-ABUSE RFC-IGNORANT-

BOGUSMX
Spam Lists To Be Spam

Esta directiva define la cantidad de listas negras en las que debe estar presente un remitente para que su mensaje sea
considerado Spam de nivel moderado.
Sintaxis : Spam Lists To Be Spam = numero
Ejemplo:
Spam Lists To Be Spam = 2
Spam Lists To Reach High Score

Esta directiva define la cantidad de listas negras en las que debe estar presente un remitente para que su mensaje sea
considerado Spam de nivel alto.
Sintaxis : Spam Lists To Reach High Score = numero
Ejemplo:
Spam Lists To Be Spam = 3
Use SpamAssassin
Esta directiva define si se usará o no a SpamAssassin como herramienta de detección de Spam.
Sintaxis : Use SpamAssassin = yes|no
Ejemplo:
Use SpamAssassin = yes
Required SpamAssassin Score

Esta directiva define el puntaje mínimo que debe tener un mensaje según la calificación de SpamAssassin para que sea
considerado Spam de nivel moderado.
Sintaxis : Required SpamAssassin Score = numero
Ejemplo:
Required SpamAssassin Score = 5
OpenSourceCollege
Linux for SysAdmins
Página 400
Source Linux
High SpamAssassin Score
Esta directiva define el puntaje mínimo que debe tener un mensaje según la calificación de SpamAssassin para que sea
considerado Spam de nivel alto.
Sintaxis : High SpamAssassin Score = número
Ejemplo:
High SpamAssassin Score = 10
Max SpamAssassin Size

Max Spam Check Size
Estas directivas definen el tamaño máximo que debe tener un mensaje para que pueda ser analizado en busca de Spam por
SpamAssassin y MailScanner respectivamente.
Normalmente SpamAsassin no tiene un rendimiento nada óptimo analizando mensajes grandes, quizás más allá de los 300 KB de
tamaño. Muchos spammers han aprendido esto y saben que generando mensajes de gran tamaño (300 KB a más) lograrán que
éstos no sean analizados llegando así con más probabilidad a la bandeja de entrada del usuario.
Sin embargo MailScanner requerir analizar sólo parte de un mensaje para saber si es spam o no (Ejm: analizar sólo los primeros
200 KB) sin afectar el rendimiento de SpamAsassin. Por esta razón se recomienda que el límite de tamaño que puede analizar
MailScanner sea un valor alto, alrededor de 1 MB o más dependiendo del tamaño de los mensajes de spam que reciba
frecuentemente, mientras que el tamaño máximo de mensajes analizados por SpamAssassin se mantenga bajo o en sus valores
predeterminados.
Sintaxis : Max SpamAssassin Size = tamaño

Sintaxis : Max Spam Check Size = tamaño
Ejemplo:
Max SpamAssassin Size = 200k

Max Spam Check Size = 1000k
Spam Actions
Esta directiva define la acción a tomar cuando se detecte Spam moderado en un mensaje.
Sintaxis : Spam Actions = acción
Algunas de las posibles acciones a tomar son:
deliver
Entrega el mensaje a su destinatario de manera normal
delete
Elimina el mensaje
store
Almacena una copia del mensaje en la cuarentena
bounce
Envia un mensaje de rechazo al remitente
forward usuario@dominio
Reenvía una copia del mensaje a una cuenta de correo
header "nombre: valor"

Agrega una cabecera al mensaje donde "nombre" no debe contener espacios
Algunos ejemplos válidos son los siguientes:
Spam Actions = forward admin@newdomains.com

Spam Actions = deliver header "X-Spam-Status: Yes"
High Scoring Spam Actions

Esta directiva define la acción a tomar cuando se detecte Spam alto en un mensaje.
OpenSourceCollege
Linux for SysAdmins
Página 401
Source Linux
Sintaxis : High Scoring Spam Actions = accion
Las acciones son las mismas descritas en la directiva anterior. Ejemplo:
High Scoring Spam Actions = store
Hasta aquí con el estudio de directivas de MailScanner, que cuenta con un gran número de opciones disponibles para cambiar a
nuestro gusto pero todas las directivas se encuentran muy bien documentadas en su archivo de configuración por lo que resultará
bastante sencillo al lector entenderlas.
19.3.2. Analizador de Spam SpamAssassin
Instalación de SpamAssassin
SpamAssassin está incluido en los repositorios de las principales distribuciones Linux. El procedimiento de instalación es directo
como debajo se indica:
# yum install spamassassin -y
# apt-get install spamassassin -y
Ajustes básicos de SpamAssassin

Una vez configurado MailScanner sería importante hacer algunos ajustes a un archivo de configuración de SpamAssassin
identificado como /etc/MailScanner/spam.assassin.prefs.conf según las directivas que se mencionan a continuación:
ok_languages
ok_locales
Esta directiva define la codificación y el idioma preferentemente esperados en los contenidos de los mensajes de correo. Puede ser
útil si se recibe Spam en idiomas que no son los nuestros y sobre todo con codificación de caracteres que no son propios de
nuestra lengua.
Sintaxis : ok_languages código [código] [código] ...

Sintaxis : ok_locales código [código] [código] ...
Ejemplo:
ok_languages es en
ok_locales es en
use_bayes
Esta directiva permite activar el motor Bayesiano que en base a métodos estadísticos clasificará los mensajes como Spam.
Sintaxis : use_bayes 0|1
Ejemplo:
use_bayes 1
bayes_auto_learn
Esta directiva permite que SpamAssassin aprenda de manera automáticamente cuando un mensaje es o no Spam en base a las
estadísticas bayesianas.
Sintaxis : bayes_auto_learn 0|1
Ejemplo:
bayes_auto_learn 1
bayes_path
Esta directiva define el prefijo de los archivos de Bayes que se crearán durante el tiempo de funcionamiento.
Sintaxis : bayes_path ruta_directorio/prefijo
OpenSourceCollege
Linux for SysAdmins
Página 402
Source Linux
En el siguiente ejemplo se crearán los archivos de bayes con un prefijo de nombre "bayes" en el directorio /etc/MailScanner/bayes.
Tenga cuidado que /etc/MailScanner/bayes/bayes no es ni debe ser un directorio.
bayes_path /etc/MailScanner/bayes/bayes
bayes_file_mode
Esta directiva define los permisos de los archivos de Bayes.
Sintaxis : bayes_file_mode permisos
Ejemplo:
bayes_file_mode 0660
Plugins de SpamAssassin
SpamAssassin es capaz de extender la funcionalidad que por defecto incluye a través del uso de plugins, los mismos que pueden
ser activados (los que vienen por defecto con SpamAssassin) o descargados algún sitio Web publicado por terceros.
En la Web de SpamAssassin se puede encontrar una lista de plugins personalizados de diferentes licencias (gratuitos, licencia
Apache, comerciales de pago, etc), bajo la siguiente URL:
http://wiki.apache.org/spamassassin/CustomPlugins
Estos plugins tras ser descargados, deben ser colocados en el directorio /etc/mail/spamassassin. Los plugins por lo general serán
archivos de extensión .pm y sus directivas de configuración se guardan en archivos de extensión .cf.
Es recomendable habilitar algunos plugins:
• TextCat : Habilita la identificación de idiomas. Si se habilitan las directivas ok_languages y/o ok_locales en
/etc/MailScanner/spam.assassin.prefs.conf se requiere habilitar este plugin.
Para habilitarlo se debe descomentar la línea loadplugin Mail::SpamAssassin::Plugin::TextCat en el archivo
/etc/mail/spamassassin/v310.pre.
• SPF : Habilita la validación SPF de los dominios de los remitentes. Para habilitarlo se debe descomentar la línea
loadplugin Mail::SpamAssassin::Plugin::SPF en el archivo /etc/mail/spamassassin/init.pre.
• DCC : Habilita el análisis de mensajes en base a cálculos checksum (sumas de verificación) desde la base de datos
DCC. Para habilitarlo se debe descomentar la línea loadplugin Mail::SpamAssassin::Plugin::DCC en el
archivo /etc/mail/spamassassin/v310.pre.
DCC se puede obtener descargar desde http://www.rhyolite.com/dcc/ y tras ser compilado e instalado, se debe definir
en el archivo /etc/MailScanner/spam.assassin.prefs.conf la ruta del binario del comando dccproc como sigue:
ifplugin Mail::SpamAssassin::Plugin::DCC
dcc_path /usr/local/bin/dccproc
endif
• Razor2 : Habilita el análisis de mensajes en base a cálculos checksum (sumas de verificación) desde la base de datos
Razor. Para habilitarlo se debe descomentar la línea loadplugin Mail::SpamAssassin::Plugin::Razor2 en el
archivo /etc/mail/spamassassin/v310.pre.
Razor2 se puede obtener descargar desde http://razor.sourceforge.net/ y tras ser compilado e instalado, se debe
definir en el archivo /etc/MailScanner/spam.assassin.prefs.conf la ruta de configuración de razor como sigue:
use_razor2 1
razor_config /var/spool/MailScanner/spamassassin/razor/razor-agent.conf
Razor2 debe crear el archivo de configuración con el comando razor-admin como sigue:
# mkdir -p /var/spool/MailScanner/spamassassin/razor
# razor-admin -create -config /var/spool/MailScanner/spamassassin/razor/razor-agent.conf
# chown -R postfix:mail /var/spool/MailScanner/spamassassin
• Relayed By Dialup : Habilita el análisis de los remitentes de correo para evaluar si provienen desde direcciones IP
públicas fijas o dinámicas (conexiones caseras del tipo ADSL o Diaulp).
OpenSourceCollege
Linux for SysAdmins
Página 403
Source Linux
Este plugin debe ser descargado desde el sitio Web de Spamassassin donde se publican los plugins personalizados (link
líneas arriba mostrado).
Existen otros plugins que pueden ser instalador y habilitados a criterio del administrador. Entre ellos existen algunos que analizan
archivos PDF (plugin PDFassassin), análisis de spam en imágenes (plugin Fuzzy OCR), y otros.
Muchos de estos plugins tras ser habilitados puede que requieran cumplir algunas dependencias de paquetes antes de poder
funcionar correctamente. Para poder averiguar si existen dependencias incumplidas de los plugins de SpamAssassin se puede
ejecutar lo siguiente:
# spamassassin --lint -D 2>&1 | less
Este comando nos arroja una salida extensa de la cual requerimos filtrar el texto 'not installed' para identificar los módulos de Perl
no instalados y requeridos como dependencia:
[15810] dbg: diag: module installed: Net::SMTP, version 2.31

[15810] dbg: diag: module installed: Mail::SPF, version v2.005
[15810] dbg: diag: module not installed: Mail::SPF::Query ('require' failed)
[15810] dbg: diag: module not installed: IP::Country::Fast ('require' failed)
[15810] dbg: diag: module not installed: Net::Ident ('require' failed)
[15810] dbg: diag: module installed: IO::Socket::INET6, version 2.54
[15810] dbg: diag: module not installed: IO::Socket::SSL ('require' failed)
[15810] dbg: diag: module installed: Compress::Zlib, version 2.008
[15810] dbg: diag: module installed: Time::HiRes, version 1.9711
[15810] dbg: diag: module not installed: Mail::DomainKeys ('require' failed)
[15810] dbg: diag: module not installed: Mail::DKIM ('require' failed)
[15810] dbg: diag: module installed: DBI, version 1.607
En el ejemplo arriba mostrado se puede apreciar que los siguientes módulos no están instalados:
• Mail::SPF::Query
• IP::Country::Fast
• Net::Ident
• IO::Socket::SSL
• Mail::DomainKeys
• Mail::DKIM
Estos módulos pueden ser descargados desde:
http://search.cpan.org
Donde podremos utilizar el buscador para cada uno de los módulos con palabras clave como 'Mail SPF Query', 'IP Country Fast',
'Net Ident' y así con el resto.
Cada uno de estos módulos de Perl se encuentran publicados como tarballs los cuales deben ser instalados bajo un procedimiento
general como el siguiente:
# tar zxf modulo-perl-VERSION.tar.gz

# cd modulo-perl-VERSION
# perl Makefile.PL
# make
# make install
Es necesario observar con atención la salida del comando perl Makefile.PL ya que éste puede advertir de la ausencia de
otros módulos de Perl que son necesarios tener instalados antes de la compilación del módulo de nuestro interés.
19.3.3. Antivirus ClamAV

El antivirus puede ser instalado de algunas de las siguientes formas:
1. En Red Hat / CentOS y derivados : Se requiere tener configurado el repositorio de DAG (http://dag.wieers.com) y ejecutar
desde la línea de comandos lo siguiente:
# yum install clamav clamav-db clamd -y
2. En Debian y derivados : El repositorio Debian Volatile contiene las últimas versiones
# yum install clamav-daemon clamav-freshclam -y
3. Descargar desde el sitio oficial de ClamAV (http://www.clamav.net) los instaladores para la distribución Linux que tengamos e
OpenSourceCollege
Linux for SysAdmins
Página 404
Source Linux
instalar los paquetes de manera individual:
# rpm -ivh clam*.rpm
19.3.4. Pruebas de funcionamiento

Finalmente cuando ya se ha culminado con la configuración de los servicios Cyrus IMAP, Postfix y MailScanner es momento de realizar
las primeras pruebas de funcionamiento de todos los componentes integrados.
Para eso empezaremos verificando nuestras conexiones activas debiendo constatar de tener abiertos los puertos 143, 110, y 25
principalmente:
# netstat -tnlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:2000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
Luego empezaremos a probar un diálogo SMTP con el servidor para enviarle un mensaje sencillo desde comandos telnet:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.newdomains.com ESMTP
HELO gsmtp163.google.com
250 mail.newdomains.com
MAIL FROM: <angelrengifo@gmail.com>
250 2.1.0 Ok
RCPT TO: <postmaster@newdomains.com>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Mensaje de Prueba
.
250 2.0.0 Ok: queued as CD4A267D083
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
Luego de eso debería haber entrado un nuevo mensaje en la cola de Postfix y éste pasarlo luego a MailScanner. Veamos algunas
líneas de los logs:
Sep 2 18:38:01 localhost postfix/smtpd[17789]: 077FA67D087: client=localhost[127.0.0.1]

Sep 2 18:38:06 localhost postfix/cleanup[17792]: 077FA67D087: hold: header Received: from
gsmtp163.google.com (localhost [127.0.0.1])??by mail.newdomains.com (Postfix) with SMTP id
077FA67D087??for <postmaster@newdomains.com>; Sun, 2 Sep 2007 18:37:53 -0500 (PET) from
localhost[127.0.0.1]; from=<angelrengifo@gmail.com> to=<postmaster@newdomains.com> proto=SMTP
helo=<gsmtp163.google.com>
Sep 2 18:38:06 localhost postfix/cleanup[17792]: 077FA67D087: message-
id=<20070902233801.077FA67D087@mail.newdomains.com>
Sep 2 18:38:06 localhost MailScanner[16132]: New Batch: Scanning 1 messages, 947 bytes
Sep 2 18:38:06 localhost MailScanner[16132]: Spam Checks: Starting
Sep 2 18:38:06 localhost MailScanner[16132]: Whitelist refresh time reached
Sep 2 18:38:06 localhost MailScanner[16132]: Starting up SQL Whitelist
Sep 2 18:38:06 localhost MailScanner[16132]: Read 0 whitelist entries
Sep 2 18:38:06 localhost MailScanner[16132]: Blacklist refresh time reached
Sep 2 18:38:06 localhost MailScanner[16132]: Starting up SQL Blacklist
Sep 2 18:38:06 localhost MailScanner[16132]: Read 0 blacklist entries
Sep 2 18:38:07 localhost postfix/smtpd[17789]: disconnect from localhost[127.0.0.1]
Sep 2 18:38:10 localhost MailScanner[16132]: Virus and Content Scanning: Starting
Sep 2 18:38:10 localhost MailScanner[16132]: Requeue: 077FA67D087.0D0E9 to 0BD5867D088
Sep 2 18:38:10 localhost postfix/qmgr[8320]: 0BD5867D088: from=<angelrengifo@gmail.com>,
size=502, nrcpt=1 (queue active)
Sep 2 18:38:10 localhost MailScanner[16132]: Uninfected: Delivered 1 messages
Sep 2 18:38:10 localhost MailScanner[16132]: Logging message 077FA67D087.0D0E9 to SQL
Sep 2 18:38:10 localhost MailScanner[16132]: Config: calling custom end function SQLBlacklist
Sep 2 18:38:10 localhost MailScanner[16132]: Closing down by-domain spam blacklist
OpenSourceCollege
Linux for SysAdmins
Página 405
Source Linux
Sep 2 18:38:10 localhost MailScanner[16132]: Config: calling custom end function
MailWatchLogging
Sep 2 18:38:10 localhost MailScanner[16132]: Config: calling custom end function SQLWhitelist
Sep 2 18:38:10 localhost MailScanner[16132]: Closing down by-domain spam whitelist
Sep 2 18:38:10 localhost MailScanner[16132]: MailScanner child dying of old age
Sep 2 18:38:10 localhost cyrus/master[17799]: about to exec /usr/lib/cyrus/bin/lmtpd
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: executed
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: accepted connection
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: lmtp connection preauth'd as postman
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: duplicate_check:
<20070902233801.077FA67D087@mail.newdomains.com> user.root 0
Sep 2 18:38:10 localhost MailScanner[17800]: MailScanner E-Mail Virus Scanner version 4.55.10
starting...
Sep 2 18:38:10 localhost MailScanner[17800]: Read 748 hostnames from the phishing whitelist
Sep 2 18:38:10 localhost MailScanner[17800]: Config: calling custom init function SQLBlacklist
Sep 2 18:38:10 localhost MailScanner[17800]: Starting up SQL Blacklist
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: duplicate_check:
<20070902233801.077FA67D087@mail.newdomains.com> user.root 0
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: mystore: starting txn 2147485203
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: mystore: committing txn 2147485203
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: duplicate_mark:
<20070902233801.077FA67D087@mail.newdomains.com> user.root 1188776290 47597596182714
Sep 2 18:38:10 localhost MailScanner[17800]: Read 0 blacklist entries
Sep 2 18:38:10 localhost MailScanner[17800]: Config: calling custom init function
MailWatchLogging
Sep 2 18:38:10 localhost MailScanner[17800]: Started SQL Logging child
Sep 2 18:38:10 localhost MailScanner[17800]: Config: calling custom init function SQLWhitelist
Sep 2 18:38:10 localhost MailScanner[17800]: Starting up SQL Whitelist
Sep 2 18:38:10 localhost MailScanner[17800]: Read 0 whitelist entries
Sep 2 18:38:10 localhost MailScanner[17800]: Using SpamAssassin results cache
Sep 2 18:38:10 localhost MailScanner[17800]: Connected to SpamAssassin cache database
Sep 2 18:38:10 localhost cyrus/lmtpunix[17799]: Delivered:
<20070902233801.077FA67D087@mail.newdomains.com> to mailbox: user.root
Sep 2 18:38:10 localhost postfix/lmtp[17798]: 0BD5867D088: to=<root@newdomains.com>,
orig_to=<postmaster@newdomains.com>, relay=mail.newdomains.com[/var/run/cyrus/socket/lmtp],
delay=17, delays=16/0.01/0.02/0.39, dsn=2.1.5, status=sent (250 2.1.5 Ok)
Sep 2 18:38:10 localhost postfix/qmgr[8320]: 0BD5867D088: removed
Sep 2 18:38:10 localhost MailScanner[17800]: Enabling SpamAssassin auto-whitelist
functionality...
Sep 2 18:38:11 localhost MailScanner[17800]: Using locktype = flock
En medio de la gran cantidad de líneas puede apreciarse cual es el remitente (MAIL FROM) y el destinatario (RCPT TO), así como
también como MailScanner analiza su contenido y finalmente lo devuelve a Postfix para finalmente entregarlo a Cyrus IMAP.
Una forma alternativa de enviar un correo desde la línea de comandos con el mismo resultado que el anterior es como sigue:
# echo "Mensaje de prueba" | sendmail -f angelrengifo@gmail.com -t postmaster@consultorianet.com
Finalmente podemos probar el correcto funcionamiento de la autenticación y el servicio IMAP como sigue:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK proxy Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready
. LOGIN arengifo abc123
. OK User logged in
. LIST "" "*"
* LIST (\HasChildren) "." "INBOX"
* LIST (\HasNoChildren) "." "INBOX.Sent"
* LIST (\HasNoChildren) "." "INBOX.Trash"
. OK Completed (0.000 secs 4 calls)
. SELECT INBOX
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]
* 3 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1184871996]
* OK [UIDNEXT 87]
. OK [READ-WRITE] Completed
. FETCH 1:* (FLAGS)
* 1 FETCH (FLAGS (\Seen))
. OK Completed (0.000 sec)
. FETCH 3 body[text]
OpenSourceCollege
Linux for SysAdmins
Página 406
Source Linux
* 3 FETCH (BODY[TEXT] {6}
Hola
)
. OK Completed (0.000 sec)
w
* BYE LOGOUT received
. OK Completed
Connection closed by foreign host.
Con esto ya se tiene un sistema de correo con los servicios SMTP, POP e IMAP protegidos por un filtro de contenidos como
MailScanner trabajando en conjunto con SpamAssassin y ClamAV.
OpenSourceCollege
Linux for SysAdmins
Página 407
Source Linux
19.4. Webmail y monitoreo
19.4.1. Monitoreo con MailWatch
Requerimientos
MailWatch es una aplicación Web escrita sobre PHP capaz de generar gráficas estadísticas obtenidas desde una base de datos
MySQL. Como tal requerirá que se instale lo siguiente:
✔ Apache 2.x
✔ PHP 5
✔ La librería GD
✔ MySQL Server 5.0
La instalación de esos paquetes se haría como sigue:
# yum install httpd php php-gd mysql-server -y
# apt-get install apache2 libapache2-mod-php5 php5 php5-gd mysql-server -y
Una vez que se tengan instalados dichos componentes debe procederse a ajustar algunos parámetros de configuración de PHP en
el archivo php.ini (/etc/php.ini en Red Hat / CentOS y derivados, o /etc/php5/apache2/php.ini en Debian) correspondiente a cada
distribución Linux, como se muestra a continuación:
short_open_tag = On
safe_mode = Off
register_globals = Off
magic_quotes_gpc = On
magic_quotes_runtime = Off
session.auto_start = 0
Luego de ello haremos los cambios efectivos en el servicio Apache y nos aseguraremos que el servicio MySQL esté correctamente
iniciado también.
Instalación y configuración
La instalación de MailWatch es un proceso que consta de varios pasos bastante sencillos. Debemos primero obtener el tarball
correspondiente desde su sitio oficial en Internet:
http://mailwatch.sourceforge.net
Procedemos con la descarga y descompresión del paquete:
# wget http://ufpr.dl.sourceforge.net/sourceforge/mailwatch/mailwatch-x.y.z.tar.gz
# tar zxf mailwatch-x.y.z.tar.gz -C /tmp
# cd /tmp/mailwatch-x.y.z
Una vez dentro del directorio de la distribución de MailWatch crearemos la base de datos necesaria:
# mysql < create.sql
Luego debemos asignar los privilegios correspondientes para las operaciones en la base de datos a un usuario como se muestra
debajo:
# mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 36
Server version: 5.0.32-Debian_7etch1-log Debian etch distribution
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> use mysql;

Database changed;
mysql> GRANT ALL ON mailscanner.* TO mailwatch@localhost IDENTIFIED BY 'clave';
mysql> GRANT FILE ON *.* TO mailwatch@localhost IDENTIFIED BY 'clave';
mysql> FLUSH PRIVILEGES;
OpenSourceCollege
Linux for SysAdmins
Página 408
Source Linux
Es entonces que debemos hacer la primera modificación a la base de datos recién creada para crear así un usuario con privilegios
de Administración en la interfaz Web de MailWatch:
# mysql mailscanner -u mailwatch -p

Enter password:
mysql> INSERT INTO users VALUES('admin',md5('clave-mailwatch'),'MailWatch
Admin','A','0','0','0','0','0');
Luego dentro del directorio de la distribución de MailWatch se encontrarán los archivos MailWatch.pm y SQLBlackWhiteList.pm los
cuales tendremos que editar para cambiar los parámetros de conexión a la base de datos tal como el usuario (mailwatch) y
contraseña ('clave' en los ejemplos de arriba).
# MailWatch.pm
...
...
...
# Modify this as necessary for your configuration

my($db_name) = 'mailscanner';
my($db_host) = 'localhost';
my($db_user) = 'mailwatch';
my($db_pass) = 'clave';
# SQLBlackWhiteList.pm
...
...
...
sub CreateList {
my($type, $BlackWhite) = @_;
my($dbh, $sth, $sql, $to_address, $from_address, $count);
my($db_name) = 'mailscanner';
my($db_host) = 'localhost';
my($db_user) = 'mailwatch';
my($db_pass) = 'clave';
Estos archivos permiten integrar MailScanner con MailWatch. MailWatch.pm guarda un registro de cada mensaje de correo que
analiza MailScanner así como también la cuarentena, mientras que SQLBlackWhiteList.pm permite guardar listas blancas y negras
personalizadas.
Luego de editar ambos archivos los colocamos en el directorio /usr/lib/MailScanner/MailScanner/CustomFunctions o

/etc/MailScanner/CustomFunctions dependiendo donde lo mantenga cada distribución Linux:
# cp MailWatch.pm SQLBlackWhiteList.pm /etc/MailScanner/CustomFunctions
Dentro del directorio de la distribución de MailWatch se encuentra el directorio mailscanner/ el mismo que procederemos a colocar
en una ruta servida por Apache, y haremos algunos ajustes de permisos para que el usuario bajo el cual se ejecuta Apache sea
capaz de escribir a fin de cumplir con sus labores:
# cp -r mailscanner /var/www
# cd /var/www/mailscanner
# mkdir temp
# chown -R .www-data temp images
# chmod -R g+w temp images
# cp conf.php.example conf.php
Si se aprecia arriba se hizo una copia del archivo conf.php.example a conf.php siendo éste último el cual modificaremos como sigue:
# conf.php
...
...
...
define(DB_TYPE, 'mysql');
define(DB_USER, 'mailwatch');
define(DB_PASS, 'clave');
define(DB_HOST, 'localhost');
...
OpenSourceCollege
Linux for SysAdmins
Página 409
Source Linux
...
// Paths
define(MAILWATCH_HOME, '/var/www/mailscanner');
define(MS_CONFIG_DIR, '/etc/MailScanner/');
Finalmente debemos hacer algunos cambios en el archivo de configuración de MailScanner para culminar el proceso de instalación
de MailWatch, como se muestra a continuación:
Always Looked Up Last = &MailWatchLogging

Detailed Spam Report = yes
Quarantine Whole Message = yes
Quarantine Whole Message As Queue Files = no
Include Scores In SpamAssassin Report = yes
Quarantine Group = www-data
Quarantine Permissions = 0660
Is Definitely Not Spam = &SQLWhitelist
Is Definitely Spam = &SQLBlacklist
Además algunos ajustes adicionales sobre los archivos de Bayes:
# chmod -R .www-data /etc/MailScanner/bayes

# chmod -R g+rws /etc/MailScanner/bayes
Luego simplemente debemos reiniciar MailScanner para que los cambios se hagan efectivos y a través de un navegador acceder a
la URL del MailWatch que es la siguiente:
http://servidor/mailscanner
Al intentar ingresar a dicha URL se nos pedirá autenticación y debe ingresarse el usuario y clave insertados en la base de datos
anteriormente (usuario 'admin' y clave 'clave-mailwatch').
19.4.2. El Webmail Horde
Requerimientos
La instalación de Horde requiere básicamente un servidor MySQL y Apache con soporte PHP. Pero PHP en la mayoría de
distribuciones viene repartido en una serie de paquetes independientes que incluyen el soporte para la integración con diferentes
tecnologías como LDAP, IMAP, gd, gettext, MySQL, entre otros. Los siguientes son nombres de paquetes referenciales que se
consideran necesarios:
✔ mysql-server
✔ apache2
✔ php5
✔ php-pear
✔ php5-mysql
✔ php5-imap
✔ php5-gettext
✔ php5-gd
La instalación de esos paquetes se haría como sigue:
# yum install php-pear php-gettext php-imap -y
# apt-get install php-pear php5-imap php-gettext -y
El paquete php-pear a la vez incluye el soporte para ciertas funcionalidades que no están incluidas en su versión predeterminada
de las distribuciones Linux por lo que se requiere instalar lo faltante:
# pear install -o Log Mail Mail_Mime DB Date File Net_SMTP

# pear -d preferred_state=beta install -a Services_Weather
OpenSourceCollege
Linux for SysAdmins
Página 410
Source Linux
Luego ya se debe encontrar listo el sistema para iniciar la configuración de Horde.
Instalación y configuración
Horde es un Webmail completo y modular cuyo sitio oficial en Internet es:
http://www.horde.org
Horde actualmente posee una serie de módulos que agregan funcionalidades diversas siendo algunas de ellas las siguientes:
• horde: El framework
• imp: El cliente IMAP para leer los buzones de correo
• mimp: El cliente IMAP para leer los buzones de correo hecho para dispositivos móviles
• vacation: Las respuestas automáticas de fuera de oficina
• forward: La redirección de mensajes a otra cuenta de correo
• turba: La libreta de direcciones
• passwd: El módulo de cambio de contraseñas
• nag: Las tareas de usuario
• mnemo: Las notas personales
• kronolith: El calendario de actividades
• gollem: El disco duro virtual
• ingo: Los filtros personalizados de correos
Cada uno de estos módulos pueden ser directamente obtenidos desde:
http://ftp.horde.org/pub
El proceso de instalación de cada uno de los módulos es bastante sencillo. En este documento se cubrirá la instalación del
framework base Horde y el módulo IMP pero el lector puede seguir los mismos pasos para instalar cualquiera de los módulos
adicionales que le interese.
Procedemos a realizar la descarga de la última versión estable de Horde e IMP:
# wget http://ftp.horde.org/pub/horde/horde-x.y.z.tar.gz
# wget http://ftp.horde.org/pub/imp/imp-x.y.z.tar.gz
Ahora empezaremos a ubicarlos en una ruta servida por Apache:
# tar zxf horde-x.y.z.tar.gz -C /var/www

# mv /var/www/horde-x.y.z /var/www/horde
# tar zxf imp-x.y.z.tar.gz -C /var/www/horde
# mv /var/www/horde/imp-x.y.z /var/www/horde/imp
Dentro de cada módulo existe un directorio config/ en el cual centraremos nuestra atención para realizar los ajustes necesarios.
Empezamos por generar los archivos de configuración a partir de los archivos de ejemplo incluidos por defecto en la distribución de
los paquetes:
# cd /var/www/horde/config
# for i in *.dist; do cp $i $(basename $i .dist); done
# cd /var/www/horde/imp/config
# for i in *.dist; do cp $i $(basename $i .dist); done
Luego es necesario que se asignen ciertos permisos de escritura al usuario de Apache sobre los directorios config/:
# find /var/www/horde -type d -name config -exec chown -R .www-data {} \;

# find /var/www/horde -type d -name config -exec chmod -R g+w {} \;
De este modo ya sabemos que Apache será capaz de modificar los archivos que existan dentro de los directorios config/ así como
también poder crear otros tantos nuevos.
Es necesario ahora ajustar el archivo de configuración imp/config/servers.php para que el proceso de autenticación se realice hacia
el servidor adecuado:
$servers['_prompt'] = array(
'name' => _("Choose a mail server:")
);
OpenSourceCollege
Linux for SysAdmins
Página 411
Source Linux
/* Example configurations: */
$servers['cyrus'] = array(
'name' => 'Servidor IMAP',
'server' => 'mail.newdomains.com',
'hordeauth' => false,
'protocol' => 'imap/notls',
'port' => 143,
'maildomain' => 'newdomains.com',
'smtphost' => 'mail.newdomains.com',
'smtpport' => 25,
'realm' => '',
'preferred' => '',
'admin' => array(
'params' => array(
'login' => 'cyrus',
'password' => 'abc123',
// The 'userhierarchy' parameter defaults to 'user.'
// If you are using a nonstandard hierarchy for personal
// mailboxes, you will need to set it here.
'userhierarchy' => 'user.',
// Although these defaults are normally all that is required,
// you can modify the following parameters from their default
// values.
'protocol' => 'imap/notls',
'hostspec' => 'localhost',
'port' => 143
)
),
'quota' => array(
'driver' => 'cyrus',
'params' => array(),
),
'acl' => array(
'driver' => 'rfc2086',
),
);
En el recuadro de arriba se muestra un ejemplo de las primeras líneas de configuración del archivo imp/config/servers.php y Ud.
apreciará que existirán muchas instancias del tipo $server['nombre'] como por ejemplo $server['imap'],
$server['pop'], $server['exchange'], entre otros de donde Horde leerá la que se encuentre primera dentro del archivo
siendo en nuestro caso la sección $server['cyrus'].
Los valores que deben ser cambiados dentro de la sección $server['cyrus'] son los que están remarcados con negrita y algún
otro adicional que sea de interés del lector. Además se recalca que las líneas 'login' => 'cyrus' y 'password' =>
'abc123' representan los datos de inicio de sesión del usuario con privilegios de administrador en Cyrus IMAP (el usuario
especificado en la directiva admins:).
Es tiempo ahora de generar la base de datos para Horde como sigue:
# cd /var/www/horde/scripts/sql
# mysql < create.mysql.sql
Ahora es tiempo ya de acceder a la segunda parte de la configuración de Horde pero esta vez a través de la interfaz Web,
accediendo por la URL:
http://servidor/horde
Apenas se ingrese a la URL indicada apreciarán que ya han iniciado sesión y tienen acceso a un menú en la parte izquierda donde
una de las entradas lleva el nombre "Administration" y se empezará a proceder como indica los siguientes pasos:
Sobre IMP:
Ir a 'Administration -> Setup' y dar clic sobre el módulo 'Imp' en la parte derecha. Dentro de tal categoría se pueden
ajustar algunas características y valores predeterminados para todos los usuarios, para luego finalizar la configuración de IMP
dando clic en 'Generate Mail Configuration'.
Sobre Horde:
Ir a 'Administration -> Setup' y dar clic sobre el módulo 'Horde' en la parte derecha. Dentro de tal categoría se pueden
ajustar algunas características y valores predeterminados para todos los usuarios de las que se requiere mínimamente las
siguientes:
OpenSourceCollege
Linux for SysAdmins
Página 412
Source Linux
1. En la pestaña 'Authentication' completar como sigue los campos del formulario:
Which users should be treated as administrators (root, super-user) by Horde?: (rellenar con un usuario)
What backend should we use for authenticating users to Horde?: Let a Horde application handle authentication
The application which is providing authentication: imp
2. En la pestaña 'Preference System' completar como sigue:
What preferences driver should we use?: SQL Database

Driver configuration: Custom parameters
What database backend should we use?: MySQL
Username to connect to the database as: horde
Password to connect with: horde
How should we connect to the database?: TCP/IP
Database server/host: localhost
Los campos de los formularios que no son mencionados pueden ser tranquilamente dejados con los valores predeterminados.
Finalmente dar clic en 'Generate Horde Configuration', donde se apreciará que el sistema ya ha cerrado sesión y será
necesario que se se indique un nombre de usuario y contraseña correspondiente para poder acceder al sistema Horde.
OpenSourceCollege
Linux for SysAdmins
Página 413
Source Linux
Unidad 20: Virtualización Open Source
20.1. Objetivos
✔ Conocer los conceptos básicos de virtualización de sistemas operativos y las técnicas más comunes existentes.
✔ Instalación y configuración básica de Xen para implementar máquinas virtuales (guests).
✔ Conocer las tareas rutinarias de administración de máquinas virtuales con Xen.
20.2. Virtualización Open Source, "Xen"

20.2.1 Conceptos básicos
Virtualización
En informática, virtualización se refiere a la abstracción de los recursos de una computadora, llamada Hypervisor o VMM (Virtual
Machine Monitor) que crea una capa de la abstracción entre el hardware de la maquina física (host) y el sistema operativo de la
maquina virtual (virtual machine, guest)., siendo un medio para crear una versión virtual de un dispositivo o recurso, como un
servidor, un dispositivo de almacenamiento, una red o incluso un sistema operativo, donde se divide el recurso en uno o más
entornos de ejecución.
Esta capa de software (VMM) maneja, gestiona y arbitra los cuatro recursos principales de una computadora (CPU, Memoria, Red,
Almacenamiento) y así podrá repartir dinámicamente dichos recursos entre todas las maquinas virtuales definidas en el
computador central. De modo que nos permite tener varios ordenadores virtuales ejecutándose sobre el mismo ordenador físico.
Tal término es antiguo; se viene usando desde 1960, y ha sido aplicado a diferentes aspectos y ámbitos de la informática, desde
sistemas computacionales completos, hasta capacidades o componentes individuales. Lo mas importante en este tema de
virtualización es la de ocultar detalles técnicos a través de la encapsulación.
La virtualización se encarga de crear un interfaz externo que esconde una implementación subyacente mediante la combinación de
recursos en locaciones físicas diferentes, o por medio de la simplificación del sistema de control. Un avanzado desarrollo de
nuevas plataformas y tecnologías de virtualización han hecho que se vuelva a prestar atención a este importante concepto. De
modo similar al uso de términos como “abstracción” y “orientación a objetos”, virtualización es usado en muchos contextos
diferentes.
Este concepto que es realmente interesante y que se lleva desarrollando desde hace muchos años, parece que finalmente está
encontrando sus caminos productivos y de desarrollo para profesionales.
La maquina virtual en general es un sistema operativo completo que corre como si estuviera instalado en una plataforma de
hardware autónoma. Típicamente muchas máquinas virtuales son simuladas en un computador central. Para que el sistema
operativo “guest” funcione, la simulación debe ser lo suficientemente grande (siempre dependiendo del tipo de virtualización)
Diferencias entre virtualizar e instalar un sistema operativo

Virtualizar el sistema operativo es una opción interesante si no queremos instalar dos sistemas operativos en el mismo ordenador,
pero si por el contrario lo que hacemos es instalarlo, todos los sistemas operativos que tengamos instalados funcionaran de la
misma manera que si estuvieran instalados en distintos ordenadores.
El único y pequeño inconveniente es que necesitamos un gestor de arranque que al encender nuestro ordenador nos de la opción
de elegir que sistema operativo queremos utilizar, lo que conlleva a que si por ejemplo estamos en Windows y queremos cambiar a
Linux deberíamos reiniciar nuestro ordenador. La virtualización por el contrario permite cambiar de sistema operativo como si se
tratase de cualquier otro programa, sin embargo, esta agilidad tiene la desventaja de que un sistema operativo virtualizado no es
tan potente como uno que ya estuviera instalado.
Ventajas de la virtualización
• Rápida incorporación de nuevos recursos para los servidores virtualizados.

• Reducción de los costes de espacio y consumo necesario de forma proporcional al índice de consolidación logrado
(Estimación media 10:1).
• Administración global centralizada y simplificada.
• Nos permite gestionar nuestro CPD como un pool de recursos o agrupación de toda la capacidad de procesamiento,
memoria, red y almacenamiento disponible en nuestra infraestructura
• Mejora en los procesos de clonación y copia de sistemas: Mayor facilidad para la creación de entornos de test que
permiten poner en marcha nuevas aplicaciones sin impactar a la producción, agilizando el proceso de las pruebas.
• Aislamiento : un fallo general de sistema de una máquina virtual no afecta al resto de máquinas virtuales.
• Mejora de TCO y ROI
• No sólo aporta el beneficio directo en la reducción del hardware necesario, así como de sus costes asociados
OpenSourceCollege
Linux for SysAdmins
Página 414
Source Linux
• Reduce los tiempos de parada.
• Migración en caliente de máquinas virtuales (sin pérdida de servicio) de un servidor físico a otro, eliminando la necesidad
de paradas planificadas por mantenimiento de los servidores físicos.
• Balanceo dinámico de máquinas virtuales entre los servidores físicos que componen el pool de recursos, garantizando
que cada máquina virtual ejecute en el servidor físico más adecuado y proporcionando un consumo de recursos
homogéneo y óptimo en toda la infraestructura.
• Alto grado de satisfacción general
Definición de términos comunes

Los siguientes son términos comunes en el ámbito de la virtualización que serán encontrados en este y otros documentos de la
misma temática.
• Host : También conocido como anfitrión. Es el sistema que sirve de base para la ejecución de las máquinas virtuales.
• Guest : También definido como huésped. Se define así al sistema que es virtualizado (máquina virtual) sobre un host.
• Hypervisor : Un hipervisor (en inglés hypervisor) o monitor de máquina virtual (virtual machine monitor) es una
plataforma de virtualización que permite utilizar, al mismo tiempo, diferentes sistemas operativos (sin modificar o
modificados en el caso de paravirtualización) en una misma computadora. Es una extensión de un termino anterior,
“supervisor”, que se aplicaba a kernels de sistemas operativos.
Existen dos tipos de hypervisor:
Hypervisor de nivel 1
También denominado nativo, unhosted o sobre el metal desnudo (bare metal), es software que se ejecuta
directamente sobre el hardware, para ofrecer la funcionalidad descrita.
Hypervisor de nivel 2
También denominado hosted, es software que se ejecuta sobre un sistema operativo para ofrecer la funcionalidad
descrita.
OpenSourceCollege
Linux for SysAdmins
Página 415
Source Linux
20.2.2 Técnicas de virtualización
Las siguientes son las técnicas de virtualización más comunes que existen:
Virtualización de sistema operativo guest

Virtualización de sistema operativo es tal vez el concepto más fácil de entender. En este escenario el sistema físico (equipo host)
ejecuta un sistema operativo estándar sin modificar, como Windows, Linux, Unix o Mac OS X y sobre éste se ejecuta una
aplicación de virtualización que funciona en espacio de usuario, de igual manera como lo haría una hoja de cálculo o procesador
de textos.
Es dentro de esta aplicación de virtualización que una o más máquinas virtuales se crean para ejecutar los sistemas operativos
guest en el equipo host. La aplicación de virtualización es la responsable de iniciar, detener y administrar cada máquina virtual y,
esencialmente, controlar el acceso a los recursos de hardware físico en nombre de las máquinas virtuales individuales.
La también aplicación de virtualización también se involucra en un proceso conocido como traducción que implica el análisis de la
secuencia de instrucciones del sistema guest en ejecución reemplazando las instrucciones privilegiadas con emulaciones
seguridas de las mismas sobre el equipo host.
Esto genera el efecto de hacer creer al sistema guest que está corriendo directamente en el hardware en lugar de una máquina
virtual dentro de una aplicación.
Algunos ejemplos de tecnologías de virtualización de Sistema operativo guest incluyen VMware Server y VirtualBox.
La siguiente figura proporciona un ejemplo de sistema operativo invitado virtualización basada:
Como se muestra en la imagen superior, los sitemas guest trabajan en máquinas virtuales dentro de la aplicación de virtualización,
la cual corre sobre el sistema host como lo hace cualquier otra aplicación (Ejm: Mozilla Firefox, Microsoft Word, etc).
Estas múltiples capas de abstracción entre el sistema guest y el sistema host que hay debajo no conducen a buenos niveles de
rendimiento de las máquinas virtuales.
Sin embargo esta técnica tiene la ventaja que no hay requerimientos específicos que cumplir sobre el guest o host, ni tampoco se
necesitan características específicas del CPU (Ejm: soporte de virtualización en el procesador. Intel VT o AMD-V)
OpenSourceCollege
Linux for SysAdmins
Página 416
Source Linux
Virtualización con kernel compartido
Conocido también como virtualización a nivel de sistema operativo. Esta técnica toma ventaja del diseño estructural de los
sistemas UNIX y Linux. Para entender la virtualización con kernel compartido se requiere entender la función de dos componentes
principales de estos sistemas.
Uno de estos componentes es el kernel, que es el corazón de un sistema operativo. El kernel en términos simples se encarga de
manejar toda la interacción entre el sistema operativo y el hardware sobre el cual correo.
El otro componente es el sistema de archivos raíz, el cual contiene todas las librerías, archivos y utilitarios necesarios para que
funcone el sistema operativo.
En un esquema de virtualización con kernel compartido cada sistema guest tiene su propio sistema de archivos raíz pero
comparten el kernel que ejecuta el sistema host. La estructura de este modo de virtualización se muestra debajo:
Este tipo de virtualización es posible gracias a la habilidad del kernel de cambiar dinámicamente el sistema de archivos raíz actual
(concepto conocida como chroot) hacia otro sistema de archivos raíz diferente sin la necesidad de reiniciar el sistema entero. Es
así que la virtualización con kernel compartido es una extensión a esta capacidad.
Quizás el impacto adverso más grande que genera esta técnica de virtualización es el hecho que los sistemas guest deben ser
compatibles con la versión del kernel (del host) que están compartiendo. Es así que por ejemplo no es posible correr Microsoft
Windows como guest en un sistema Linux usando esta técnica de virtualización. Tampoco es posible ejecutar un sistema Linux
diseñado para un kernel de la rama 2.4.x correr sobre un Linux con kernel 2.6.x.
Sin embargo el beneficio que presenta esta técnica es que sea quizás la de mejor rendimiento sobre cualquier otra técnica de
virtualización existente.
Algunos ejemplos de tecnologías de virtualización con kernel compartido son Linux Vserver, Solaris Zones and Containers,
FreeVPS, OpenVZ, FreeBSD Jails, Paralells Virtuozzo Containers, entre otros.
Virtualización a nivel de kernel

En una virtualización a nivel de kernel el sistema host corre en un kernel especialmente modificado que contiene extensiones para
administrar y controlar múltiples máquinas virtuales cada una conteniendo un sistema operativo guest. A diferencia de la técnica
anterior de virtualización con kernel compartido, esta técnica permite que cada guest ejecute su propio kernel sin embargo
restricciones similares existen como el hecho que el sistema guest debe haber sido compilado para la misma arquitectura de
hardware sobre la cual corre el sistema host.
Ejemplos de tecnologías que usan esta técnica son UML (User Mode Linux) y KVM (Kernel-based Virtual Machine). El diagrama de
OpenSourceCollege
Linux for SysAdmins
Página 417
Source Linux
abajo muestra la forma como trabaja la virtualización con esta técnica:
Virtualización con Hypervisor

La familia de CPUs x86 proveen un rango de niveles de protección que son también conocidos como anillos en los cuales se
puede ejecutar código. El anillo 0 tiene el más alto nivel de privilegios y es en este nivel que se ejecuta el kernel de un sistema
operativo. El código que se ejecuta en este anillo se le conoce también como código ejecutado en espacio de sistema, modo kernel
o modo supervisor. Todo el resto de código tal como el perteneciente a aplicaciones corriendo en el sistema operativo se ejecutan
en anillos de menores privilegios, típicamente en el anillo 3.
En un entorno de virtualización dominado por esta técnica existe un programa conocido como hypervisor (conocido también como
VMM o Virtual Machine Monitor -Monitor de máquina virtual- de tipo 1) se ejecuta directamente en el hardware del sistema host en
el anillo 0. La tarea de este hypervisor es manejar la asignación de recursos y memoria para las máquinas virtuales además de
proveer interfaces para niveles más altos de administración y herramientas de monitoreo.
Claramente, con el hypervisor ocupando el anillo 0 de la CPU, los kernels de cualquier sistema operativo guest corriendo en el
sistema host deberían corren entonces en anillos menos privilegiados. Desafortunadamente, la mayoría de sistemas operativos
han sido creados para correr sobre el anillo 0 por la sencilla razón de que ellos necesitan realizar tareas que están disponibles sólo
en dicho anillo, tal como la habilidad de instrucciones privilegiadas de CPU y manipular la memoria directamente.
Para este problema se han desarrollado un número de soluciones en los últimos años, cada una de las cuales es descrita a
continuación:
1. Paravirtualización : En la paravirtualización el kernel del sistema operativo guest ha sido modificado especialmente para
correr sobre un hypervisor. Esto involucra reemplazar cualquier operación privilegiada -que normalmente corren en el
anillo 0- con llamadas al hypervisor (llamadas hypercalls o hyper llamadas). Es así que el hypervisor ejecuta entonces en
nombre del kernel guest la tarea privilegiada.
Esto limita el soporte de sistemas guest a sistemas operativos Open Source gracias a la posibilidad de ser libremente
modificables (por ejemplo Linux) y otros sistemas operativos propietarios cuyos fabricantes han accedido a hacer las
modificaciones de código necesarias para correr sobre un hypervisor específico.
Sin embargo la habilidad del kernel guest de comunicarse directamente con el hypervisor trae como resultado mayores
OpenSourceCollege
Linux for SysAdmins
Página 418
Source Linux
niveles de rendimiento con respecto a otras técnicas de virtualización.
2. Virtualización completa : Conocido también como Full Virtualización. Esta técnica provee soporte para sistemas
operativos sin modificar. Esto quiere decir que el kernel de los sistemas guest no han sido modificados o reescritos para
correr sobre un hypervisor y sin embargo aún ejecutan tareas privilegiadas como si se ejecutasen en el anillo 0 de la
CPU.
En este escenario el hypervisor provee emulación de CPU para manejar y modificar las operaciones protegidas y
privilegiadas invocadas por el kernel de los sistemas operativos guest (sin modificar).
Lamentablemente este proceso de emulación requiere tanto recursos de sistema y tiempo para funcionar resultando en
un rendimiento inferior comparado al ofrecido por la paravirtualización.
3. Virtualización por hardware : Conocida también como virtualización asistida por hardware. La virtualización por
hardware aprovecha las características de virtualización integradas en los CPU de última generación tanto de Intel como
de AMD. Estas tecnologías conocidas como Intel VT y AMD-V respectivamente, proveen extensiones necesarias para
correr sistemas guest sin modificar sin los impactos negativos inherentes a la emulación de CPU en virtualización
completa.
En términos muy simples, estos nuevos procesadores proveen un modo privilegiado adicional sobre el anillo 0 en el cual
el hypervisor puede ejecutarse casi dejando así el anillo 0 libre para los sistemas operativos guest sin modificar.
La siguiente imagen ilustra el modo de trabajo de la virtualización con hypervisor:
Como se muestra en la imagen de arriba, adicionalmente a las máquinas virtuales, un sistema operativo de
administrativo y/o una consola de administración también corren sobre el hypervisor permitiendo a las máquinas
virtuales ser controladas por un usuario administrador.
Entre las soluciones de virtualización con hypervisor existen Xen, Vmware ESX Server y Microsoft Hyper-V.
20.2.3 Acerca de Xen

Xen es una máquina virtual de código abierto desarrollada por la Universidad de Cambridge.
La meta del diseño es poder ejecutar instancias de sistemas operativos con todas sus características, de forma completamente
funcional en un equipo sencillo. Xen proporciona aislamiento seguro, control de recursos, garantías de calidad de servicio y migración
de máquinas virtuales en caliente. Los sistemas operativos pueden ser modificados explícitamente para correr Xen (aunque
manteniendo la compatibilidad con aplicaciones de usuario). Esto permite a Xen alcanzar virtualización de alto rendimiento sin un
soporte especial de hardware. Intel ha realizado diversas contribuciones a Xen que han permitido añadir soporte para sus extensiones
de arquitectura VT-X Vanderpool. Esta tecnología permite que sistemas operativos sin modificar actúen como hosts dentro de las
máquinas virtuales de Xen, siempre y cuando el servidor físico soporte las extensiones VT de Intel o Pacifica de AMD.
OpenSourceCollege
Linux for SysAdmins
Página 419
Source Linux
Xen utiliza una técnica llamada paravirtualización para alcanzar alto rendimiento (es decir, bajas penalizaciones del rendimiento,
típicamente alrededor del 2%, con los peores casos de rendimiento rondando el 8%; esto contrasta con las soluciones de emulación
que habitualmente sufren penalizaciones de un 20%).
Con la paravirtualización, se puede alcanzar alto rendimiento incluso en arquitecturas (x86) que no suelen conseguirse con técnicas
tradicionales de virtualización. A diferencia de las máquinas virtuales tradicionales, que proporcionan entornos basados en software
para simular hardware, Xen requiere portar los sistemas operativos para adaptarse al API de Xen. Hasta el momento hay ports para
NetBSD, Linux, FreeBSD y Plan 9.
En 2005, Novell muestra un port de NetWare para Xen. Un port de Windows XP fue creado durante el desarrollo inicial de Xen, pero las
licencias de Microsoft prohíben su lanzamiento público.
Intel ha realizado modificaciones a Xen para soportar su arquitectura de extensiones Vanderpool. Esta tecnología permite que sistemas
operativos sin modificaciones se ejecuten en máquinas virtuales Xen, si el sistema soporta las extensiones Vanderpool o Pacífica (de
Intel y AMD respectivamente, extensiones para soportar virtualización de forma nativa). Prácticamente, esto significa una mejora de
rendimiento, y que es posible virtualizar Windows sin tener que modificarlo.
El 15-08-2007 Citrix adquiere XenSource, por un valor de 500 millones de dólares estadounidenses. Esta empresa ha lanzado
recientemente XenServer 4.1, habiendo un producto gratuito, el XenServer Express Edition, aunque solo puede soportar cuatro
máquinas virtuales.
En la actualidad muchas distribuciones incluyen Xen entre su software soportado, estando esta versión basada en la publicación libre
del software liberada por XenSource, mientras que a la par se mantiene una versión comercial de mayores prestaciones.
Terminología Xen
• Domain : Término usado por Xen para designar a una máquina virtual o sistema guest.
• Domain-0 : Conocido también como Dom0. Es el dominio inicial con el cual arranca el sistema host, y a diferencia de
otros dominios éste es el único privilegiado para tener acceso a interfaces de control del hypervisor. Desde Dom0 se
puede administrar el resto de dominios.
• Domain-U : Conocido también como DomU. Es cualquier dominio distinto no privilegiado, y el hypervisor los mantiene
aislados del hardware y del resto de dominios.
• PV : Dominio paravirtualizado.
• HVM : Dominio completamente virtualizado por hardware.
Requerimientos
• Xen en la actualidad puede ser ejecutado sobre x86, x86-64, IA-64 y PowerPC.
• Para correr un PV con Xen se requiere que el CPU tenga soporte de PAE (Physical Address Extension)
• Para correr un HVM con Xen se requiere que el CPU tenga soporte de virtualización (El flag vmx en /proc/cpuinfo para
Intel VT, o el flag svm en /proc/cpuinfo para AMD-V).
Identificación de DomU
Cada DomU puede ser identificado de 3 formas:
• Por su nombre de dominio.

• Por su número ID (valor temporal mientras está en ejecución).
• Por su UUID (valor persistente).
20.2.4 Instalación de Xen

Xen y todos los paquetes necesarios pueden ser instalados desde los repositorios de las principales distribuciones Linux como se
muestra debajo:
# yum install kernel-xen xen virt-manager -y
OpenSourceCollege
Linux for SysAdmins
Página 420
Source Linux
# yum install xen-linux-system-2.6.26-2-xen-686 virt-manager -y
20.2.5. Configuración básica de Xen

Un DomU consta de dos componentes, un archivo de configuración que especifica cómo el dominio debe ser creado, y un dispositivo
virtual de bloques que simula ser el disco duro del dominio. Los archivos de configuración para los DomU están ubicados en /etc/xen
de Dom0.
Cada DomU tiene su propio archivo de configuración pero es posible prescindir de uno si se arranca el dominio usando directamente
una herramienta como xm.
Los archivos de configuración son creados automáticamente cuando se crean un nuevo dominio utilizando virt-manager, que es
una herramienta gráfica de administración de máquinas virtuales.
Un archivo de configuración de DomU puede tener un contenido similar al siguiente:
name = "linux1"
memory = "512"
disk = [ 'tap:aio:/var/lib/xen/images/linux1.img,xvda,w', ]
vif = ["type=vnc,vncunused=1"]
uuid = "eb675005-e347-4e47-8678-48ce3b676fe1"
bootloader = "/usr/bin/pygrub"
vcpus = 1
on_reboot = 'restart'
on_crash = 'restart'
Creación de DomU con virt-manager

virt-manager es una herramienta gráfica de gestión de máquinas virtuales, capaz de trabajar con Xen, QEMU, OpenVZ, KVM y
probablemente más. Puede ser invocado desde la línea de comandos ejecutando simplemente virt-manager y siguiendo los pasos
debajo descritos para crear una máquina virtual:
En la ventana principal de virt-manager debe aparecer un único hypervisor de nombre 'localhost'. Si debajo de él no se muestra
ningún dominio entonces es necesario conectarse a dicho hypervisor dando doble clic sobre su nombre (localhost).
1.Una vez conectado al hypervisor, seleccionar el nombre 'localhost' y dar clic al botón 'Nuevo' mostrado en la parte inferior.
2.En la primera pantalla de bienvenida que se abre, dar clic en 'Adelante'
3.En la siguiente pantalla definir el nombre que se asignará a la máquina virtual, luego dar clic en 'Adelante'.
4.En la siguiente pantalla escoger la técnica de virtualización: 'Paravirtualizado' o' 'Completamente virtualizado'. Asimismo elegir la
arquitectura de CPU que se pretende emular si se escoge la segunda técnica. Asumiendo que se eligió la opción 'Paravirtualizado' dar
clic en 'Adelante'.
5.En la siguiente pantalla elegir 'Linux' como tipo de sistema operativo y 'Red Hat Enterprise Linux 5' como variante de SO. Luego dar
clic en 'Adelante'.
6.En la siguiente pantalla se debe especificar una URL (HTTP, FTP) donde se publica el árbol de instalación del sistema operativo a
instalar (el contenido del DVD de instalación de RHEL 5). Si se planea usar Kickstart o modificar parámetros de arranque del kernel se
pueden especificar en los campos siguientes. Luego dar clic en el boton 'Adelante'.
7.En la siguiente pantalla se debe especificar el almacenamiento (disco duro) que usará el DomU. Se puede optar por elegir una
partición o Logical Volume existente, o crear un archivo de imagen de tamaño y ruta específicos. Tras elegir la segunda opción (crear
archivo de imagen) con un tamaño de 5000 MB promedio y marcando la opción 'Asignar el disco virtual ahora', dar clic en 'Adelante'.
8.En la siguiente pantalla se debe elegir el tipo de red que se asignará al DomU. La 'Red Virtual' crea una red propia separada y
'Dispositivo físico conectado' a través de la creación de un bridge sobre nuestra interfaz Ethernet permite al DomU acceder y ser
accedido por la red física real a la cual está conectada nuestro Dom0. Tras elegir la segunda opción de red (bridge) y dejar la dirección
MAC ser asignada automáticamente, dar clic en 'Adelante'.
9.En la siguiente pantalla se debe elegir la cantidad de memoria RAM y CPUs virtuales asignados al DomU. Luego dar clic en
'Adelante'
10.En la siguiente pantalla se muestra el resumen de la configuración hecha y se debe confirmar dando clic en 'Finalizar' para crear ya
el DomU, arrancarlo e iniciar la instalación según los parámetros configurados.
Administración de DomU desde línea de comandos

Existen dos tipos de herramientas disponibles para administrar los DomU:
OpenSourceCollege
Linux for SysAdmins
Página 421
Source Linux
•virt-manager y virsh : Herramientas creadas para soportar distintas tecnologías de virtualización (Xen, KVM, QEMU, etc) con una
interfaz comun al usuario.
•xm y xentop : Herramientas nativas de Xen para la gestión de los DomU.
A continuación estudiaremos algunas tareas rutinarias con los dominios utilizando para cada caso los dos tipos de herramientas
disponibles.
Iniciando dominios
Las formas de iniciar un dominio existente ya definido en /etc/xen son las siguientes:
# xm create <dominio>
# virsh start <dominio>
xm create permite aceptar parámetros adicionales que sobreescriban algunos de los ya definidos en el archivo de configuración.
Por ejemplo a continuación se inicia un dominio con una memoria distinta a la definida en su configuración:
# xm create <dominio1> memory="750"
Deteniendo y reiniciando dominios

Las formas de apagar un dominio son las siguientes:
# xm destroy <dominio>
# virsh destroy <dominio>
# xm shutdown <dominio>
# virsh shutdown <dominio>
Las formas de reiniciar un dominio son las siguientes:
# xm reboot <dominio>
# virsh reboot <dominio>
La diferencia entre las operaciones destroy y shutdown es que la primera lo hace de manera brusca e inmediate (como si un
corte de energía sucediese) y la segunda correctamente de acuerdo a las rutinas de apagado del sistema operativo.
Suspensión y resumen de dominios

Las formas posibles de suspender un dominio son las siguientes:
# xm pause <dominio>
# virsh suspend <dominio>
Las formas posibles de resumir o reactivar un dominio suspendido son las siguientes:
# xm unpause <dominio>
# virsh resume <dominio>
Salvar y restaurar dominios

Las formas posibles de salvar un dominio (similar a la hibernación de un equipo) son las siguientes:
# xm save <dominio> <ruta_archivo>

# virsh save <dominio> <ruta_archivo>
Las formas posibles de reanudar un dominio desde un archivo de estado son las siguientes:
# xm restore <ruta_archivo>
# virsh restore <ruta_archivo>
Listando dominios activos

Las formas de listar los dominios en ejecución son las siguientes:
# xm list
# virsh list
virsh list lista la información de todos los dominios activos, mientras que xm list puede aceptar el nombre de un dominio como
parámetro adicional para listar la información de aquel solamente.
xm list muestra un listado de información con campos como los debajo descritos:
Name Nombre dle dominio.
OpenSourceCollege
Linux for SysAdmins
Página 422
Source Linux
ID El número ID del dominio en ejecución.
Mem (MiB) La memoria en MB del dominio.
VCPUs El número de CPUs virtuales usados por el dominio.
State Existen seis estados:
r (running) : El dominio está corriendo.

b (blocked) : El dominio está bloqueado, esperando algún recurso o dormido en E/S
p (paused) : El dominio está suspendido, está en memoria pero no corriendo.
s (shutdown) : El dominio está en proceso de ser apagado correctamente, reiniciado o salvándose a disco.
c (crashed) : El dominio ha fallado y fue apagado.
d (dying) : El dominio está muriendo pero no ha terminado de apagarse completamente.
Time(s) El tiempo de CPU (en segundos) que ha sido usado por cada dominio.
Activación de DomU al arranque del sistema host

Para asegurarnos que uno o más DomU se inicien al arranque del sistema host (Dom0) se debe seguir estos pasos:
# chkconfig xendomains on
# ln -s /etc/xen/dominio /etc/xen/auto
Donde /etc/xen/dominio corresponde al archivo de configuración de un DomU.
20.2.6. Configuración de dominios paravirtualizados

A continuación se hará un análisis progresivo del archivo de configuración de un dominio paravirtualizado de acuerdo a las categorías
de recursos disponibles para ser ajustados tales como memoria, almacenamiento, CPU, entre otros.
Para ello asumiremos que se tiene ya un dominio de nombre linux1 con su respectivo archivo de configuración en /etc/xen/linux1.
CPUs virtuales
A cada dominio se le asigna un número de CPUs virtuales (VCPUs) cuando se crea el dominio. Los VCPUs son programados para
correr en CPUs reales enel sistema por el hypervisor (Dom0). Por defecto todos los dominios tienen igual acceso al CPU real.
La forma de definir la cantidad de CPUs virtuales para un dominio es a través de la directiva vcpus configurada como debajo se
muestra:
vcpus=4
Se puede asignar más CPUs virtuales de la cantidad de CPUs reales que existen en el sistema físico, sin embargo eso trae como
consecuencia un rendimiento negativo.
Se puede elegir en cuál de los CPU físicos del sistema se ejecutará un dominio como se muestran en los siguientes ejemplos:
cpus=2,4-6
cpus=2,3
Xen no diferencia entre CPUs físicos (sockets), núcleos (cores) en un mismo CPU o hyperthreads. Normalmente Xen buscará
CPUs en el orden siguiente: primero hyperthreads, luego núcleos en el mismo CPU y luego núcleos en CPUs distintos (otros
sockets de procesador).
El comando siguiente muestra información de un dominio respecto al uso de sus CPUs:
# virsh vcpuinfo <dominio>
Esto puede compararse con la información de hardware del sistema host o Dom0 como sigue:
# virsh nodeinfo
La cantidad de CPUs virtuales de un dominio se puede modificar dinámicamente a través de las siguientes formas:
# virsh setvcpus <dominio> <número>

# xm vcpu-set <dominio> <número>
El comando anterior sin embargo depende del máximo número de CPUs asignados inicialmente al arrancar el dominio (según la
definición en su archivo de configuración). Es así que sólo se puede cambiar la cantidad de CPUs virtuales a un valor igual o menor
al máximo soportado por el dominio durante su ejecución, no ser incrementado más allá de dicho límite.
OpenSourceCollege
Linux for SysAdmins
Página 423
Source Linux
Memoria
Por defecto el Dom0 al arrancar usa toda la memoria disponible en el sistema, y conforme van iniciando otros dominios va
asignándoles la memoria que requieren mientras esa misma cantidad decrece en la usada por Dom0.
La cantidad de memoria asignada a un domino se define con la siguiente directiva en su archivo de configuración:
memory="512"
La cantidad de memoria de un dominio puede ser dinámicamente modificada de alguna de las siguientes formas:
# virsh setmem <dominio> <memoria en KB>

# xm mem-set <dominio> <memoria en KB>
Al igual como sucede con los CPUs virtuales, la cantidad de memoria máxima es la asignada al arrancar el dominio y por encima
de este valor no podría incrementarse la memoria de un DomU.
Dispositivos virtuales de bloques
Los dispositivos de bloques virtuales simulan ser discos duros para los DomU, los cuales pueden ser utilizados como cualquier otro
dispositivo de bloques real para ser particionado, formateado con un sistema de archivos y montado.
Generalmente el primero de estos dispositivos de bloques virtuales se muestra al DomU como /dev/xvda, el segundo como /dev/xvdb
y así sucesivamente. También las particiones siguen el esquema tradicional de nomenclatura como /dev/xvda1, /dev/xvda2, etc.
El backend real de estos dispositivos virtuales de bloques se muestran como archivos de imágenes o dispositivos de bloques
reales en Dom0.
Los archivos de imágenes pueden ser creados como sigue:
# dd if=/dev/zero of=/var/lib/xen/images/linux1.img bs=1M count=5000
Y la configuración de este archivo de imagen se configura como un dispositivo virtual de bloques para un DomU en su archivo de
configuración como sigue:
disk = [ 'tap:aio:/var/lib/xen/images/linux1.img,xvda,w', ]
Como alternativa a los archivos de imágenes, se puede configurar un dispositivo de bloques real de Dom0 como dispositivo virtual
de bloques para un DomU con una configuración similar a alguno de los ejemplos:
# Asigna una partición de disco como dispositivo virtual de bloques

disk = [ 'phy:/dev/sda7,xvda,w', ]
# Asigna un Logical Volume como dispositivo virtual de bloques

disk = [ 'phy:/dev/VolGroup00/LogVol04,xvda,w', ]
Incluso se puede configurar múltiples dispositivos como sigue:
disk = [ 'phy:/dev/sda7,xvda,w', 'tap:aio:/var/lib/xen/images/linux1.img,xvdb,w', ]
Dispositivos de red
Cuando inicia Dom0, la interfaz de red eth0 que conectaba inicialmente a la red física es renombrada a peth0, y se crea luego un
dispositivo de red virtual de nombre eth0 que funciona conectado al dispositivo bridge xenbr0 para conectar a Dom0 con la
misma red física a la que se conecta peth0.
Es así que se pueden crear múltiples interfaces de red virtuales adheridas al bridge xenbr0 para cada uno de los DomU de modo
que éstos puedan acceder a la red física.
La manera de configurar los dispositivos virtuales en el archivo de configuración de DomU es como sigue:
vif = [ 'mac=00:16:3E:27:08:91, bridge=xenbr0', ]
Se recomienda asignar una dirección MAC dentro del rango 00:16:3E que es el código reservado para el fabricante Xen.
Consolas gráficas de administración

Xen ofrece la posibilidad de administrar de forma remota a través de VNC, para lo cual se configura por cada DomU lo siguiente:
vfb = [ "type=vnc,vncunused=1" ]
O si se desea ser más detallado con el control VNC algo como lo siguiente:
vfb = [ "type=vnc,vncdisplay=4,vnclisten=172.31.0.3,vncpasswd=abc123" ]
OpenSourceCollege
Linux for SysAdmins
Página 424
Source Linux
De estas configuraciones se puede explicar que:
vncunused=1
Permite elegir automáticamente un puerto de escucha libre para servir VNC. Por defecto es el 5900.
vncdisplay=N
Permite elegir el display (y así el puerto de escucha) del servicio VNC. El puerto usado se calcula de la suma de 5900 + N. El
comando virsh vncdisplay <dominio> permite averiguar el display asociado a un dominio.
vnclisten=DIRECCIÓN
Permite elegir la dirección de esucha del servicio VNC, ya que por defecto se limita a escuchar en localhost.
vncpasswd=PASSWORD
Permite definir un password de acceso al servicio VNC, ya que por defecto no trae ningún password asignado.
20.2.8. Instalación desde línea de comandos
Para hacer instalaciones de guests desde línea de comandos se hace uso de la herramienta virt-install cuya forma de uso se
muestra debajo:
virt-install [opciones]
Crea e instala nuevas dominios
Opciones:
-n NAME : Define el nombre del DomU.

-r MEM : Define la cantidad de memoria en MB para el DomU.
--vcpus N : Asigna N CPUs virtuales al DomU.
--os-type=TIPO : Define el tipo de sistema operativo a instalar: windows, linux, solaris, unix
--os-variant=VAR : Define la variante de sistema operativo a instalar. Consultar virt-install(1) para ver las variantes válidas.
--sound : Crea un dispositivo virtual de sonido al DomU HVM.
--noapic : Deshabilita el soporte APIC en el DomU HVM.
--noacpi : Deshabilitar el soporte ACPI en el DomU HVM.
--hvm : Crea un DomU completamente virtualizado (HVM).
--paravirt : Crea un DomU paravirtualizado (PV).
-c RUTA : Define la ruta del dispositivo CDROM o imagenISO desde la cual instalar un DomU HVM.
-l UBICACION : Define la ubicación de la fuente de instalación. Puede ser una ruta http://, ftp:// o nfs:host:/path
-w bridge:BR : Asigna el bridge al cual se adhiere la interfaz de red del DomU.
-m MAC : Define una dirección MAC específica para la interfaz de red del DomU.
--vnc : Activa el soporte VNC para el DomU.
--noautoconsole : Desactiva la ejecución de un visor VNC conectado al DomU tras invocar virt-install.
--disk OPCIONES : Define a través de OPCIONES los parámetros de almacenamiento del DomU.
Las OPCIONES pueden ser:
path=RUTA
Define la ruta del dispositivo de almacenamiento.
device=TIPO
Define el tipo de almacenamiento. Puede ser 'cdrom', 'floppy' o 'disk'.
size=TAMAÑO
Define el tamaño en GB que tendrá el dispositivo de almacenamiento cuando es de tipo 'disk'
sparse=true|false
Si es false, entonces al momento de crear la imagen del dispositivo de almacenamiento lo hará ocupando el tamaño máximo
completo. Si es true entonces la imagen de almacenamiento crecerá conforme se necesite espacio en el DomU.
El siguiente ejemplo crea un DomU paravirtualizado que será instalado desde una imagen ISO (el DVD de RHEL 5.4 x86_64). El
DomU tendrá 512 MB de RAM y un disco duro virtual de 10 GB de tamaño completo asignado desde el principio, y estará conectado a
la red física bajo el bridge xenbr0:
# virt-install -n RHEL5 --paravirt -r 512 -w bridge:xenbr0 -l /iso/rhel-server-5.4-i386-dvd.iso \

> --disk path=/var/lib/xen/images/rhel5.4.img,sparse=false,device=disk,size=10
El siguiente ejemplo crea un DomU completamente virtualizado que será instalado desde la lectora de CDROM/DVD (conteniendo un
disco de instalación de Windows XP). El DomU tendrá 1 GB de RAM y un disco duro virtual de 30 GB de tamaño completo asignado
desde el principio, y estará conectado a la red física bajo el bridge xenbr0:
# virt-install -n winxp --hvm -r 1024 -w bridge:xenbr0 -c /dev/cdrom \

> --disk path=/var/lib/xen/images/winxp.img,sparse=false,device=disk,size=30
OpenSourceCollege
Linux for SysAdmins
Página 425
Source Linux
OpenSourceCollege
Linux for SysAdmins
Página 426
Source Linux

Manual Ultra Secreto

Cargado por

Información del documento

Título original

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

Manual Ultra Secreto

Cargado por

Copyright:

Formatos disponibles

Linux for SysAdmins

OpenSourceCollege - 1ra. edición

Unidad 1: Introducción al mundo Linux

Entorno de línea de comandos

Unidad 2: Comandos GNU y Unix

Procesamiento simple de texto

El editor de archivos VIM

Unidad 3: Administración de sistemas de archivos

Unidad 4: Administración de usuarios

Gestión de usuarios y grupos

Unidad 5: Seguridad local

Unidad 6: Particionamiento avanzado

RAID por software

Logical Volume Management (LVM)

Instalación de Red Hat Enterprise Linux 5 / CentOS 5

Resolución de problemas comunes

Unidad 8: Administración de software

Sistema de paquetes RPM

Sistema de paquetes DEB

Instalación desde código fuente

Unidad 9: Otros tópicos de administración del sistema

El kernel y sus módulos

Arranque del sistema

Logs del sistema

Shell scripting básico

Unidad 10: Administración de red

Configuración de parámetros red

Aplicaciones gráficas remotas

Unidad 11: Servicios de infraestructura de red

Unidad 12: Servidor de archivos e impresión

Samba y CUPS para redes Microsoft

Compartición de archivos con NFS

Servidor FTP seguro

Reportes de tráfico FTP

Unidad 13: Servidor Web y OpenSSL

Servidor Web Apache

Reportes de tráfico Web

Unidad 14: Firewall seguro

Shoreline Firewall "Shorewall"

Unidad 15: Proxy de control de navegación Web

Squid como proxy caché

Reporte de tráfico de usuarios

Unidad 16: Túneles VPN

VPN Open Source, "OpenVPN"

Unidad 17: Servidor de mensajería instantánea

Servidor Jabber Open Source, "Openfire"

Unidad 18: Servicio de directorios LDAP

Servidor LDAP Open Source, "OpenLDAP"

Unidad 19: Servidor de Correo Electrónico

Servicios de autenticación, POP3, IMAP y SMTP

Filtro de contenidos, Antispam, Antivirus

Unidad 20: Virtualización Open Source

Virtualización Open Source, "Xen"

Tipo de fuente usada

ssh [-afg] <host>

ssh : Es el nombre del comando o aplicación a ejecutar

• ^ : Referencia abreviada a la tecla Control o Ctrl.

1. ^c y ^a significan Ctrl + c y Ctrl + a respectivamente

1.2. Conceptos básicos

¿Qué es entonces GNU/Linux?

Disponibilidad del software

1.3. Entorno gráfico

Debian GNU/Linux consultorianet tty1 CentOS Release 5.3 (Final)