Temas Portafolio PDF
Temas Portafolio PDF
básicas para
el administrador
Josep Jorba Esteve
P07/M2103/02282
© FUOC • P07/M2103/02282 2 Herramientas básicas para el administrador
© FUOC • P07/M2103/02282 Herramientas básicas para el administrador
Índice
Introducción .............................................................................................. 5
Actividades ................................................................................................. 41
Introducción
Nota
Será la combinación de las herramientas básicas, cada una con una tarea
GNU/Linux posee un conjunto
muy definida, la que nos dará la posibilidad de solucionar un problema muy amplio de herramientas
o tarea de administración. con funcionalidades básicas,
cuya potencia está en su com-
binación.
Las tareas habituales del administrador GNU/Linux pueden pasar por trabajar
con diferentes distribuciones (por ejemplo, las que comentaremos Fedora
[Fed] o Debian [Debb], o cualquier otra), o incluso trabajar con variantes co-
merciales de otros UNIX. Esto conlleva que tengamos que establecer una cierta
manera de trabajar que nos permita hacer de forma uniforme las tareas en los
diferentes sistemas.
Por esta razón, a lo largo de los diferentes módulos intentaremos destacar to-
dos aquellos aspectos más comunes, y las técnicas de administración serán
realizadas en su mayor parte a bajo nivel, mediante una línea de comandos y/
o con edición de ficheros de configuración asociados.
a) Estas herramientas son una interfaz más o menos elaborada de las herra-
mientas básicas de línea de comandos y los correspondientes ficheros de con-
figuración.
h) Por ultimo, los administradores suelen querer personalizar sus tareas utili-
zando las herramientas que consideran más cómodas y fáciles de adaptar. En
este aspecto, suele ser habitual la utilización de las herramientas básicas de
bajo nivel, y la utilización de shell scripts (veremos los fundamentos en esta
unidad) para combinarlas de modo que formen una tarea.
Tenemos que saber valorar estas herramientas extra según la valía que tengan
para nuestras tareas.
2. Documentos de estándares
Nota
En GNU/Linux podemos encontrarnos con estándares como el FHS
Ver FHS en:
(filesystem hierarchy standard) [Linb], que nos explica qué podemos en- www.pathname.com/fhs
contrarnos (o dónde buscarlo) en la estructura del sistema de ficheros
de nuestro sistema. O el LSB (Linux standard base), que nos comenta di-
ferentes componentes que solemos encontrar en los sistemas [Linc].
los directorios y los principales ficheros que contendrán. Este estándar es usa- El estándar FHS es una herra-
mienta básica para el conoci-
do en mayor o menor medida también para los UNIX comerciales, en los cua- miento de una distribución,
que nos permite conocer la es-
les al principio hubo muchas diferencias que hicieron que cada fabricante tructura y funcionalidad del sis-
cambiara la estructura a su gusto. El estándar pensado en origen para GNU/ tema de archivos principal del
sistema.
Linux se hizo para normalizar esta situación y evitar cambios drásticos. Aun
así, el estándar es seguido con diferentes grados, la mayoría de distribuciones
siguen en un alto porcentaje el FHS, realizando cambios menores o aportando
ficheros o directorios que no existían en el estándar.
• /home: contiene las cuentas de los usuarios, es decir, los directorios perso-
nales de cada usuario.
• /lib: las bibliotecas del sistema, compartidas por los programas de usuario,
ya sean estáticas (extensión .a) o dinámicas (extensión .so). Por ejemplo, la
biblioteca C estándar, en ficheros libc.so o libc.a. También en particular
suelen encontrarse los módulos dinámicos del kernel Linux, en /lib/modu-
les.
• /sbin: utilidades de base del sistema. Suelen ser comandos reservados al ad-
ministrador (root). Por ejemplo: /sbin/fsck para verificar el estado de los sis-
temas de ficheros.
Éstos son algunos de los directorios definidos en el FHS para el sistema raíz,
luego se especifican por ejemplo algunas subdivisiones, como el contenido de
los /usr y /var, y los ficheros de datos y/o ejecutables típicos que se esperan en-
contrar como mínimo en los directorios (ver las referencias a los documentos
FHS).
Otro estándar en proceso es el LSB (Linux standard base) [Linc]. La idea de éste
es definir unos niveles de compatibilidad entre las aplicaciones, bibliotecas y Nota
utilidades, de manera que sea posible la portabilidad de las aplicaciones entre http://www.linuxbase.org/
spec/
distribuciones sin demasiados problemas. Además del estándar, proporcionan
conjuntos de prueba (tests) para verificar el nivel de compatibilidad. LSB en sí
mismo es un recopilatorio de varios estándares aplicados a GNU/Linux.
© FUOC • P07/M2103/02282 12 Herramientas básicas para el administrador
Uno de los aspectos más importantes para nuestras tareas de administración será
disponer de la documentación correcta para nuestro sistema y el software instala-
do. Hay muchas fuentes de información, pero destacaremos las siguientes:
man comando
man n comando
d) Sistemas propios de las distribuciones. Red Hat suele venir con unos CD de
manuales de consulta que son instalables en el sistema y tienen formatos
HTML o PDF. Fedora dispone de un proyecto de documentación en su web.
Debian trae los manuales como un paquete de software más y suelen instalarse
en /usr/doc. Por otra parte, dispone de herramientas que clasifican la docu-
mentación presente en el sistema, y la organizan por menús para su visualiza-
ción, como dwww o dhelp, las cuales presentan interfaces web para examinar
la documentación del sistema.
4. Shells y Scripts
El shell es lo que los usuarios ven del sistema. El resto del sistema operativo
permanece esencialmente oculto a sus ojos. El shell está escrito de la misma
forma que un proceso (programa) de usuario; no está integrado en el kernel,
sino que se ejecuta como un programa más del usuario.
En los modos de arranque gráfico, la interfaz está compuesta por algún admi-
nistrador de acceso que gestiona el proceso de login del usuario desde una “ca-
rátula” gráfica, en la que se le pide la información de entrada correspondiente:
su identificador como usuario y su palabra de paso (o passsword). En GNU/Li-
nux suelen ser habituales los gestores de acceso: xdm (propio de X Window),
gdm (Gnome) y kdm (KDE), así como algún otro asociado a diferentes gestores
de ventanas (window managers). Una vez validado nuestro acceso, nos encon-
traremos dentro de la interfaz gráfica de X Window con algún gestor de ven-
tanas, como Gnome o KDE. Para interactuar desde un shell interactivo, sólo
tendremos que abrir alguno de los programas de emulación de terminal dis-
ponibles.
Si nuestro acceso es por modo consola (en texto), una vez validados obtendre-
mos el acceso directo al shell interactivo.
Los shell scripts son ficheros de texto que contienen secuencias de co-
mandos de sistema, más una serie de comandos propios internos del
shell interactivo, más las estructuras de control necesarias para procesar
el flujo del programa (tipo while, for, etc. ).
Los ficheros script son directamente ejecutables por el sistema bajo el nombre
que se haya dado al fichero. Para ejecutarlos, se invoca el shell junto con el
nombre del fichero, o bien se dan permisos de ejecución al shell script.
En cierta manera, podemos ver el shell script como código de un lenguaje in-
terpretado que se ejecuta sobre el shell interactivo correspondiente. Para el ad-
ministrador, los shell scripts son muy importantes básicamente por dos
razones:
Todos los programas invocados mediante un shell poseen tres ficheros prede-
finidos, especificados por los correspondientes descriptores de ficheros (file
handles). Por defecto, estos ficheros son:
Esto nos indica que cualquier programa ejecutado desde el shell tendrá por de-
fecto la entrada asociada al teclado del terminal, su salida hacia la pantalla y,
en el caso de producirse errores, también los envía a la pantalla.
Ejemplo
veamos
comando op fichero
© FUOC • P07/M2103/02282 18 Herramientas básicas para el administrador
• >> : indica que se añada la salida (por defecto, con > se crea de nuevo el fichero).
La independencia del shell respecto al kernel del operativo (el shell es sólo una
capa de interfaz), nos permite disponer de varios de ellos en el sistema [Qui01].
Algunos de los más comunes son:
b) El shell Bourne (sh). Éste ha sido desde siempre el shell estándar UNIX, y el que
todos los UNIX poseen en alguna versión. Normalmente, es el shell por defecto
del administrador (root). En GNU/Linux suele ser el anterior Bash, una versión
mejorada del Bourne. El sh fue creado por Stephen Bourne en AT&T a finales de
los setenta. El indicador (o prompt) por defecto suele ser un ’$’ (en root un ’#’).
El shell Bash (Bourne again shell) [Bas] [Coo] ha adquirido importancia desde su
inclusión en los sistemas GNU/Linux como shell por defecto. Este shell forma
parte del software del proyecto GNU. Es un intento de combinar los tres shell
anteriores (Bourne, C y Korn), manteniendo la sintaxis del shell Bourne origi-
nal. Es en el que nos vamos a fijar para desarrollar ejemplos posteriores.
Una forma rápida de conocer bajo qué shell nos encontramos como usuarios es
mediante la variable $SHELL, desde una línea de comandos con la instrucción:
echo $SHELL
• Todos permiten la escritura de shell scripts, que son luego interpretados eje-
cutándolos bien por el nombre (si el fichero tiene permiso de ejecución) o
bien pasándolo como parámetro al comando del shell.
• Los usuarios del sistema tienen un shell por defecto asociado a ellos. Esta infor-
mación se proporciona al crear las cuentas de los usuarios. El administrador
asigna un shell a cada usuario, o bien si no se asigna el shell por defecto (bash
en GNU/Linux). Esta información se guarda en el fichero de passwords en /etc/
passwd, y puede cambiarse con la orden chsh, esta misma orden con opción -l
nos lista los shells disponibles en el sistema (o ver también /etc/shells).
rie de comandos UNIX muy utilizados en los scripts, como por ejemplo los Para la programación shell es
recomendable tener un buen
cut, sort, cat, more, echo, grep, wc, awk, sed, mv, ls, cp... conocimiento de estos coman-
dos UNIX, y sus diferentes op-
ciones.
• Si como usuarios estamos utilizando un shell determinado, nada impide
arrancar una copia nueva de shell (lo llamamos subshell), ya sea el mis-
mo u otro diferente. Sencillamente, lo invocamos por el nombre del eje-
cutable, ya sea el sh, bash, csh o ksh. También cuando ejecutamos un
shell script se lanza un subshell con el shell que corresponda para ejecutar
el script pedido.
b) Ficheros de arranque: sh, ksh tienen .profile (en la cuenta del usuario, y
se ejecuta en el login del usuario) y también ksh suele tener un .kshrc que
se ejecuta a continuación, csh utiliza .login (se ejecuta al iniciarse el login
del usuario una sola vez), .logout (antes de la salida de la sesión del usuario)
y .cshrc (parecido al .profile, en cada subshell C que se inicia). Y Bash utiliza
el .bashrc y el .bash_profile. Además, el administrador puede colocar varia-
bles y caminos comunes en el fichero /etc/profile que se ejecutará antes que
los ficheros que tenga cada usuario. Los ficheros de inicialización de los
shell se ponen en la cuenta del usuario al crearla (normalmente se copian
del directorio /etc/skel), donde el administrador puede dejar unos esquele-
tos de los ficheros preparados.
Las diferentes variables del entorno pueden verse con el comando env. Por
ejemplo:
$ env
SSH_AGENT_PID = 598
MM_CHARSET = ISO-8859-15
TERM = xterm
DESKTOP_STARTUP_ID =
SHELL = /bin/bash
WINDOWID = 20975847
LC_ALL = es_ES@euro
USER = juan
LS_COLORS = no = 00:fi = 00:di = 01;34:ln = 01;
SSH_AUTH_SOCK = /tmp/ssh-wJzVY570/agent.570
SESSION_MANAGER = local/aopcjj:/tmp/.ICE-unix/570
USERNAME = juan
PATH=/soft/jdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/
X11:/usr/games
MAIL = /var/mail/juan
PWD = /etc/skel
JAVA_HOME = /soft/jdk
LANG = es_ES@euro
GDMSESSION = Gnome
JDK_HOME = /soft/jdk
SHLVL = 1
HOME = /home/juan
GNOME_DESKTOP_SESSION_ID = Default
LOGNAME = juan
DISPLAY = :0.0
© FUOC • P07/M2103/02282 22 Herramientas básicas para el administrador
COLORTERM = gnome-terminal
XAUTHORITY = /home/juan/.Xauthority
_ = /usr/bin/env
OLDPWD = /etc
Aquí veremos algunos conceptos básicos de los shell scripts en Bash, se reco-
mienda ampliar en [Bas] [Coo].
#!/bin/bash
Esta línea le indica al shell usado por el usuario, el que tengamos activo en
el momento, con qué shell hay que ejecutar el script que aparezca a conti-
nuación.
1) Por ejecución directa desde la línea de comandos, siempre que tenga per-
miso de ejecución. Si no se da el caso, ponemos el permiso con: chmod +x
script.
Hay que tener en cuenta que, sea cuál sea el método de ejecución, siempre es-
tamos creando un subshell donde se va a ejecutar nuestro script.
variable = valor
echo $variable
var = valor
export var
• Exportar en la asignación:
• $: Guarda todos los parámetros, pero con comillas dobles (“ “) en cada uno
de ellos.
• Las “dobles” permiten que sea considerado todo como una unidad.
• Las ‘simples’ son parecidas, pero se ignoran los caracteres especiales que se
encuentren dentro.
4.4.2. Comparaciones
Para las condiciones se suele utilizar la orden test expresión o directamente [ex-
presión]. Podemos agrupar las condiciones disponibles en:
• Comparación numérica: -eq, -ge, -gt, -le, -lt, -ne, correspondiendo a: igual
que, más grande o igual que (ge), más grande que, menor o igual que (le),
menor que, distinto que.
© FUOC • P07/M2103/02282 24 Herramientas básicas para el administrador
• Comparación de ficheros: -d, -f -r, -s, -w, -x. El fichero es: un directorio, un
fichero ordinario, es leíble, es no vacío, es escribible, es ejecutable.
Respecto a la programación interna del script, hay que pensar que nos vamos
a encontrar básicamente con:
if [ expresion ]
then
commands
fi
if [ expresion ]
then
commands1
else
commands2
fi
if [ expresion ]
then
commands
elif [ expresion2 ]
then
commands
© FUOC • P07/M2103/02282 25 Herramientas básicas para el administrador
else
commands
fi
while [ expresion ]
do
commands
done
until [ expresion ]
do
commands
done
h) Declaración de funciones:
fname() {
commands
}
fname2(arg1,arg2...argN) {
commands
}
En cualquier distribución, los paquetes son el elemento básico para tratar las
tareas de instalación de nuevo software, actualización del existente o elimina-
ción del no utilizado.
Los paquetes TGZ son quizás los de utilización más antigua. Las primeras
Nota
distribuciones de GNU/Linux los utilizaban para instalar el software, y aún
varias distribuciones los usan (por ejemplo, Slackware) y algunos UNIX co- Los paquetes TGZ son una he-
rramienta básica a la hora de
merciales. Son una combinación de ficheros unidos por el comando tar en instalar software no organiza-
do. Además, son una herra-
un único fichero .tar, que luego ha sido comprimido por la utilidad gzip, mienta útil para realizar
procesos de backup y restaura-
suele aparecer con la extensión .tgz o bien .tar.gz. Asimismo, hoy en día es ción de archivos.
común encontrar los tar.bz2 que utilizan en lugar de gzip otra utilidad lla-
mada bzip2, que en algunos casos consigue mayor compresión del archivo.
Si se trata de formato binario, tendremos que tener en cuenta que sea ade-
cuado para nuestro sistema, por ejemplo, suele ser común alguna denomi-
nación como la que sigue (en este caso, la versión 1.4 del navegador web
Mozilla):
mozilla-i686-pc-linux-gnu-1.4-installer.tar.gz
mozilla-source-1.4.tar.gz
De otro modo, habría diferentes códigos para cada sistema operativo o fuente:
GNU/Linux, Solaris, Irix, bsd...
gunzip fichero.tar.gz
2) Una vez tenemos descomprimido el tgz, tendremos los ficheros que conte-
nía, normalmente el software debe incluir algún fichero de tipo readme o ins-
tall, donde nos especificarán las opciones de instalación paso a paso, y
también posibles dependencias del software.
En primer lugar habrá que verificar las dependencias por si disponemos del
software adecuado, y si no, buscarlo e instalarlo.
• ./configure: se trata de un script que configura el código para poder ser com-
pilado en nuestra máquina, verifica que existan las herramientas adecua-
das. La opción --prefix = directorio permite especificar dónde se instalará el
software.
Éste es un proceso general, pero depende del software que lo siga o no, hay
casos bastante peores donde todo el proceso se tiene que realizar a mano, re-
tocando ficheros de configuración, o el mismo makefile, y/o compilando uno
a uno los ficheros, pero esto, por suerte, es cada vez menos habitual.
Los paquetes tgz son bastante habituales como mecanismo de backup en tareas de
administración, por ejemplo, para guardar copias de datos importantes, hacer
backups de cuentas de usuario, o guardar copias antiguas de datos que no sabemos
si volveremos a necesitar. Suele utilizarse el siguiente proceso: supongamos que
queremos guardar copia del directorio “dir” tar -cvf dir.tar dir (c: compactar dir en
el fichero dir.tar) gzip dir.tar (comprimir) o bien en una sola instrucción como:
El resultado será un fichero dir.tgz. Hay que ser cuidadoso si nos interesa con-
servar los atributos de los ficheros, y permisos de usuario, así como posible-
mente ficheros de enlace (links) que pudieran existir (deberemos examinar las
opciones de tar para que se ajuste a las opciones de backup deseadas).
El sistema de paquetes RPM [Bai03] creado por Red Hat supone un paso
adelante, ya que incluye la gestión de dependencias y tareas de configu-
ración del software. Además, el sistema guarda una pequeña base de da-
tos con los paquetes ya instalados, que puede consultarse y se actualiza
con las nuevas instalaciones.
© FUOC • P07/M2103/02282 30 Herramientas básicas para el administrador
paquete-version-rev.arq.rpm
• Eliminación: borrar el paquete del sistema RPM (-e o --erase); si hay depen-
dencias, puede ser necesario eliminar otros previamente.
Ejemplo
rpm -i ftp://sitio/directorio/paquete.rpm
nos permitiría descargar el paquete desde el sitio ftp o web proporcionado, con
su localización de directorios, y proceder en este caso a la instalación del pa-
quete.
Hay que vigilar con la procedencia de los paquetes, y sólo utilizar fuentes
de paquetes conocidas y fiables, ya sea del propio fabricante de la distribu- Nota
ción, o sitios en los que confiemos. Normalmente se nos ofrece, junto con Ver el sitio: www.rpmfind.net.
los paquetes, alguna “firma” digital de éstos para que podamos comprobar
su autenticidad. Suelen utilizarse las sumas md5 para comprobar que el pa-
quete no se ha alterado, y otros sistemas como GPG (versión Gnu de PGP)
para comprobar la autenticidad del emisor del paquete. Asimismo, pode-
mos encontrar en Internet diferentes almacenes de paquetes RPM, donde
están disponibles para diferentes distribuciones que usen o permitan el for-
mato RPM.
$ rpm -K <paquete.rpm>
Debemos ser cuidadosos en importar sólo aquellas claves de los sitios en los
que confiemos. Cuando RPM encuentre paquetes con firma que no tengamos
en nuestro sistema, o el paquete no esté firmado, nos avisará, y la acción ya
dependerá de nuestra actuación.
En el caso de Fedora (Red Hat y derivados) se utiliza el sistema YUM, que per-
mite como herramienta de más alto nivel la instalación y gestión de paquetes Nota
en sistemas rpm, así como la gestión de automática de dependencias entre los YUM en: http://
linux.duke.edu/projects/yum
paquetes. Permite acceder a múltiples repositorios diferentes, centraliza su
configuración en un fichero (/etc/yum.conf habitualmente), y tiene una inter-
faz de comandos simple.
Orden Descripción
Para finalizar, Fedora también ofrece un par de utilidades gráficas para YUM,
pup para controlar las actualizaciones recientes disponibles, y pirut como pa-
quete de gestión de software. También existen algunas otras como yumex, con
mayor control de la configuración interna de yum.
Donde hay recopiladas varias de las fuentes “oficiales” para una Debian (etch
en este caso, suponiendo ésta como stable), desde donde se pueden obtener los
paquetes de software, así como las actualizaciones que estén disponibles. Bá-
sicamente, se especifica el tipo de fuente (web/ftp en este caso), el sitio, la ver-
sión de la distribución (stable o etch en este ejemplo), y categorías del software
que se buscará (libre, o contribuciones de terceros o de licencia no libre o co-
mercial).
• Borrado de un paquete:
apt-get update
apt-get update
apt-get upgrade
apt-get dist-upgrade
# apt-key list
Las claves gpg de los sitios oficiales de Debian son distribuidas mediante un
paquete, las instalamos de este modo:
se instalen por defecto al iniciar el sistema. Para otros sitios no oficiales (que
no proporcionen la clave en paquete), pero que consideremos confiables, po-
demos importar su clave, obteniéndola desde el repositorio (tendremos que
consultar dónde tienen la clave disponible, no hay un estándar definido, aun-
que suele estar en la página web inicial del repositorio). Utilizándose apt-key
add con el fichero, para añadir la clave, o también:
Ejemplo
dpkg -L paquete
dpkg -l
dpkg -S fichero
© FUOC • P07/M2103/02282 37 Herramientas básicas para el administrador
Por último, cabe mencionar también algunas herramientas gráficas para Apt
como synaptic, gnome-apt para gnome, y kpackage o adept para KDE. O las
textuales ya mencionadas como aptitude o dselect.
Conclusión, cabe destacar que el sistema de gestión APT (en combinación con
el base dpkg) es muy flexible y potente a la hora de gestionar las actualizacio-
nes, y es el sistema de gestión de paquetes que se usa en Debian y sus distribu-
ciones derivadas como Ubuntu, Kubuntu, Knoppix, Linex, etc.
© FUOC • P07/M2103/02282 38 Herramientas básicas para el administrador
Por otra parte, en los entornos de escritorio de Gnome y KDE suelen disponer
del concepto de “Panel de control”, que permite gestionar tanto el aspecto vi-
sual de las interfaces gráficas, como tratar algunos parámetros de los disposi-
tivos del sistema.
presora, red, seguridad, usuarios, paquetes, etc. Podemos ver en la figura algu-
nas de ellas:
7. Otras herramientas
• Los múltiples comandos UNIX básicos: grep, awk, sed, find, diff, gzip,
bzip2, cut, sort, df, du, cat, more, file, which...
de efectuar pequeños cambios en los ficheros. Vim es el editor compatible Ver material asociado a curso
de introducción a GNU/ Linux,
Vi, que suele traer GNU/Linux; permite sintaxis coloreada en varios len- o las páginas man de los co-
mandos, o una referencia de
guajes. Emacs, editor muy completo, adaptado a diferentes lenguajes de herramientas como [Stu01].
programación (sintaxis y modos de edición); dispone de un entorno muy
completo y de una versión X denominada Xemacs. Joe, editor compatible
con Wordstar. Y muchos otros...
• Lenguajes de tipo script, útiles para administración, como: Perl, muy útil
para tratamiento de expresiones regulares, y análisis de ficheros (filtrado,
ordenación, etc.). PHP, lenguaje muy utilizado en entornos web. Python,
otro lenguaje que permite hacer prototipos rápidos de aplicaciones...
Actividades
1) Hacer una lectura rápida del estándar FHS, que nos servirá para tener una buena guía a la
hora de buscar archivos por nuestra distribución.
2) Para repasar y ampliar conceptos y programación de shell scripts en bash, ver: [Bas] [Coo].
3) Para los paquetes RPM, ¿cómo haríamos algunas de las siguientes tareas?:
• Conocer qué paquete instaló un determinado comando.
• Obtener la descripción del paquete que instaló un comando.
• Borrar un paquete cuyo nombre completo no conocemos.
• Mostrar todos los archivos que estaban en el mismo paquete que un determinado archivo.
4) Efectuar las mismas tareas que en la actividad anterior, pero para paquetes Debian, usando
herramientas APT.
[Deb02][Bai03] ofrecen una amplia visión de los sistemas de paquetes de software de las dis-
tribuciones Debian y Fedora/Red Hat.
P07/M2103/02283
© FUOC • P07/M2103/02283 El kernel
Índice
Introducción .............................................................................................. 5
Actividades ................................................................................................. 45
Introducción
de manera que es una herramienta perfecta para la educación en temas de sis- El kernel Linux se remonta al
año 1991, cuando Linus Tor-
temas operativos. valds lo puso a disposición de
la comunidad. Es de los pocos
operativos que, siendo amplia-
La otra ventaja principal es que, al disponer de las fuentes, podemos recompi- mente usado, se puede dispo-
ner de su código fuente.
larlas para adaptarlas mejor a nuestro sistema, y podemos, asimismo, configu-
rar sus parámetros para dar un mejor rendimiento al sistema.
• Gestión de procesos: qué tareas se van a ejecutar y en qué orden y con qué
prioridad. Un aspecto importante es la planificación de CPU: ¿cómo se op-
timiza el tiempo de la CPU para ejecutar las tareas con el mayor rendimien-
to o interactividad posible con los usuarios?
En los sistemas propietarios, el kernel está perfectamente “oculto” bajo las ca-
pas del software del sistema operativo, y el usuario final no tiene una perspec-
tiva clara de qué es el kernel, y no tiene ninguna posibilidad de cambiarlo u
optimizarlo, si no es por el uso de esotéricos editores de “registros” internos,
© FUOC • P07/M2103/02283 8 El kernel
En este caso, el kernel Linux ofrece una solución de código abierto, con los con-
secuentes permisos de modificación, corrección, posibilidad de generación de
nuevas versiones y actualizaciones de forma rápida, por parte de cualquiera
que quiera y tenga los conocimientos adecuados para realizarlo.
Esto permite a los usuarios críticos controlar mejor sus aplicaciones y el propio
sistema, y poder montar sistemas con el propio operativo “a la carta”, perso-
nalizado al gusto de cada uno. Y disponer a su vez de un operativo con código
abierto, desarrollado por una comunidad de programadores coordinados des-
de Internet, accesible ya sea para educación por disponer del código fuente y
abundante documentación, o para la producción final de los sistemas GNU/
Linux adaptados a necesidades individuales o de un determinado colectivo.
bajo se lo permitía, y a medida que el kernel maduraba (y crecía), se ha visto El kernel tiene sus orígenes en
el sistema MINIX, desarrollado
ayudado a mantener las diferentes versiones estables del kernel por diferentes por Andrew Tanenbaum,
como un clon de UNIX para
colaboradores, mientras Linus continuaba (en la medida de lo posible) desa- PC.
rrollando y recopilando aportaciones para la última versión de desarrollo del
kernel. Los colaboradores principales en estas versiones han sido [lkm]:
Para ver un poco la complejidad del kernel de Linux, veamos una tabla con un
poco de su historia resumida en las diferentes versiones y su tamaño respecti-
vo del código fuente. En la tabla se indican las versiones de producción única-
mente; el tamaño (aproximado) está especificado en miles de líneas (K) de
código fuente:
0.01 09-1991 10
Como podemos comprobar, hemos pasado de unas diez mil líneas a seis mi-
llones.
fecto (algunas todavía incluyen algunas 2.4.x, pero 2.6.x suele ser una opción El kernel hoy en día ha alcanza-
do un grado de madurez y
en la instalación); aunque cierto conocimiento de las anteriores versiones es complejidad significativo.
imprescindible, ya que con facilidad podemos encontrar máquinas con distri-
buciones antiguas que no se hayan actualizado, a las que es posible que deba-
© FUOC • P07/M2103/02283 10 El kernel
mantienen Linux 2.6) se incorporaron (durante 2003) a OSDL (Open Source The Linux Foundation:
www.linux-foundation.org
Developement Laboratory) [OSDa], un consorcio de empresas con el fin de
promocionar el uso Open Source y GNU/Linux en la empresa (en el consorcio
se encuentran entre otras muchas empresas con intereses en GNU/Linux: HP,
IBM, Sun, Intel, Fujitsu, Hitachi, Toshiba, Red Hat, Suse, Transmeta...). En esos
momentos se dio una situación interesante, ya que el consorcio OSDL hizo de
patrocinador de los trabajos, tanto al mantenedor de la versión estable del ker-
nel (Andrew) como la de desarrollo (Linus), trabajando a tiempo completo en
las versiones, y en los temas relacionados. Linus se mantiene independiente,
trabajando en el kernel, mientras Andrew se fue a trabajar a Google, donde
continuaba a tiempo completo sus desarrollos, realizando parches con dife-
rentes aportaciones al kernel. Recientemente, OSDL se reconvirtió en la funda-
ción The Linux Foundation.
Hay que tener en cuenta que con las versiones actuales del kernel, se ha alcan-
zado ya un alto grado de desarrollo y madurez, lo que hará que cada vez se am-
plíe más el tiempo entre la publicación de las versiones (no así de las revisiones
parciales).
Además, cabe tener en cuenta que la mayoría sólo tienen unos conocimien-
tos parciales del kernel, y ni todos trabajan simultáneamente, ni su aporta-
ción es igual de relevante (algunas de ellas sólo corrigen errores sencillos);
mientras que son unas pocas (como los mantenedores) las que disponen de
un conocimiento total del kernel. Esto supone que se puedan alargar los desa-
rrollos, y que las aportaciones se tengan que depurar, para ver que no entren
en conflicto entre ellas, o decidir entre posibles alternativas de prestaciones
para escoger.
a) Hasta la rama del kernel 2.6.x, las versiones del kernel Linux se regían por
una división en dos series: una era la denominada “experimental” (la nume-
rada impar en la segunda cifra, como 1.3.xx, 2.1.x o 2.5.x) y la otra es la de
producción (serie par, como 1.2.xx, 2.0.xx, 2.2.x, 2.4.x y más). La serie expe-
© FUOC • P07/M2103/02283 11 El kernel
Los kernels de producción (serie par) o estables eran kernels con un conjunto
de prestaciones bien definido, con un número bajo de errores conocidos y
controladores de dispositivos probados. Se publicaban con menos frecuencia
que los experimentales, y existían variedad de versiones, unas más buenas que
otras. Los sistemas GNU/Linux se suelen basar en un determinado kernel esta-
ble elegido, no necesariamente el último kernel de producción publicado.
c) Para obtener el último kernel publicado, hay que acudir al archivo de kernels
Linux (en http://www.kernel.org) o al mirror local (en España http://
www.es.kernel.org). También podrán encontrarse algunos parches al kernel ori-
ginal, que corrijan errores detectados a posteriori de la publicación del kernel.
© FUOC • P07/M2103/02283 12 El kernel
Algunas de las características técnicas ([DBo][Arc]) del kernel Linux que podría-
mos destacar son:
e) Alta calidad: los sistemas GNU/Linux son muy estables, bajo ratio de fallos,
y reducen el tiempo dedicado a mantener los sistemas.
g) Linux es compatible con una gran parte de los sistemas operativos, puede
leer ficheros de prácticamente cualquier sistema de ficheros y puede comuni-
carse por red para ofrecer/recibir servicios de cualquiera de estos sistemas. Ade-
más, también con ciertas bibliotecas puede ejecutar programas de otros
sistemas (como msdos, Windows, BSD, Xenix, etc.) en la arquitectura x86.
h) Linux está ampliamente soportado: no hay ningún otro sistema que tenga
la rapidez y cantidad de parches y actualizaciones que Linux, ni en los siste-
mas propietarios. Para un problema determinado, hay infinidad de listas de
correo y foros, que en pocas horas pueden permitir solucionar cualquier pro-
blema. El único problema está en los controladores de hardware reciente, que
muchos fabricantes todavía se resisten a proporcionar si no es para sistemas
propietarios. Pero esto está cambiando poco a poco, y varios de los fabricantes
más importantes de sectores como tarjetas de vídeo (NVIDIA, ATI) e impreso-
ras (Epson, HP,) comienzan ya a proporcionar los controladores para sus dis-
positivos.
© FUOC • P07/M2103/02283 15 El kernel
Otra opción de instalación suele ser la versión del kernel. Normalmente las dis-
tribuciones usan una instalación que consideran lo suficientemente estable y
probada como para que no cause problemas a los usuarios. Por ejemplo, a día
de hoy muchas distribuciones vienen con versiones 2.6.x del kernel por defec-
to, ya que se considera la versión más estable del momento (en que salió la dis-
tribución). En algunos casos en el momento de la instalación puede ofrecerse
la posibilidad de usar como alternativa, versiones más modernas, con mejor
soporte para dispositivos más modernos (de última generación), pero quizás
no tan probadas, en el momento que se publica la distribución.
en el momento de las pruebas. Otra técnica bastante común en las comerciales La posibilidad de actualizar y
personalizar el kernel a medida
es deshabilitar prestaciones problemáticas, que pueden causar fallos a los ofrece buena adaptación a
cualquier sistema, permitiendo
usuarios, o necesitan una configuración especifica de la máquina, o bien una una optimización y sintoniza-
determinada prestación no se considera lo suficientemente estable para in- ción al mismo.
cluirla activada.
Esto nos lleva a considerar que, por muy bien que un distribuidor haga el tra-
bajo de adaptar el kernel a su distribución, siempre nos podemos encontrar con
una serie de problemas:
• Los controladores que nos ofrece un fabricante necesitan una nueva ver-
sión del kernel o modificaciones.
• A la inversa, el kernel es demasiado moderno, tenemos hardware antiguo
que ya no tiene soporte en los kernels modernos.
• El kernel, tal como está, no obtiene las máximas prestaciones de nuestros
dispositivos.
• Algunas aplicaciones que queremos usar requieren soporte de un kernel
nuevo o de algunas de sus prestaciones.
• Queremos estar a la última, nos arriesgamos, instalando últimas versiones
del kernel Linux.
• Nos gusta investigar o probar los nuevos avances del kernel o bien quere-
mos tocar o modificar el kernel.
• Queremos programar un controlador para un dispositivo no soportado.
• ...
Por éstos y otros motivos podemos no estar contentos con el kernel que tene-
mos; se nos plantean entonces dos posibilidades: actualizar el kernel binario de
la distribución o bien personalizarlo a partir de las fuentes.
Vamos a ver algunas cuestiones relacionadas con las diferentes opciones y qué
suponen:
También aquí podemos encontrarnos con dos opciones más, o bien por defec-
to obtenemos la versión “oficial” del kernel (kernel.org), o bien podemos acudir
a las fuentes proporcionadas por la propia distribución. Hay que tener en
cuenta que distribuciones como Debian y Fedora hacen un trabajo importante
de adecuación del kernel, y corrección de errores del kernel que afectan a su dis-
tribución, con lo cual podemos, en algunos casos, disponer de correcciones
adicionales al código original del kernel. Otra vez más las fuentes ofrecidas por
la distribución no tienen por qué corresponder a la última versión publicada.
Sin ánimo de exagerar, casi nunca aparecen problemas si se siguen los pasos
adecuadamente, se tiene conciencia de lo que se está haciendo y se toman al-
gunas precauciones.
Si las fuentes venían en un fichero gz, reemplazamos bzip2 por gzip. Al des-
comprimir las fuentes, se habrá generado un directorio linux-version_kernel,
donde entraremos para establecer la configuración del kernel.
Para el proceso de configuración del kernel [Vasb], tenemos varios métodos al-
ternativos, que nos presentan interfaces diferentes para ajustar los múltiples
© FUOC • P07/M2103/02283 20 El kernel
• make config: desde la línea de comandos se nos pregunta por cada opción, y
se nos pide confirmación (y/n) –si deseamos o no, la opción o se nos piden los
valores necesarios. O bien la configuración larga, en la que se nos piden mu-
chas respuestas, y dependiendo de la versión, igual tenemos que responder a
casi un centenar de preguntas (o más dependiendo de la versión).
Figura 2. Configuración del kernel (make xconfig) desde interfaz gráfica en X Window
© FUOC • P07/M2103/02283 21 El kernel
Una vez se haya hecho el proceso de configuración, hay que guardar el fichero
(.config), ya que la configuración consume un tiempo importante. Además,
puede ser de utilidad disponer de la configuración realizada si está planeado
hacerla en varias máquinas parecidas o idénticas.
• Otro caso que suele aparecer (aunque no es muy común) es cuando nece-
sitamos dos dispositivos que son incompatibles entre sí, o está funcionan-
do uno o el otro (esto puede pasar, por ejemplo, con la impresora con cable
paralelo y hardware que se conecta al puerto paralelo). Por lo tanto, en este
caso tenemos que colocar como módulos los controladores y cargar o des-
cargar el que sea necesario.
ellos, por ejemplo ext2 o ext3 (propios de Linux), vfat (de los Windows 95/
98/ME), y los daremos de alta en la configuración del kernel. Si en otro mo-
mento tuviéramos que leer otro tipo no esperado, por ejemplo, datos guar-
dados en un disco o partición de sistema NTFS de Windows NT/XP, no
podríamos: el kernel no sabría o no tendría soporte para hacerlo. Si tenemos
previsto que en algún momento (pero no habitualmente) se tenga que ac-
ceder a estos sistemas, podemos dejar los demás filesystems como módulos.
make dep
make bzImage
Cuando este proceso acabe, tenemos la parte integrada del kernel; nos faltan
las partes que hayamos puesto como módulos:
make modules
2) Instalación
make modules_install
cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.0
cp System.map /boot/System.map-2.4.0
En este punto también hay que tener en cuenta que en el arranque el kernel
puede necesitar la creación de ficheros tipo initrd, que sirve de imagen com-
puesta de algunos drivers básicos y se utiliza durante la carga del sistema, como
primera fase, si el sistema necesita de esos drivers antes de proceder al arranque
de algunos componentes. En algunos casos es imprescindible, debido a que,
para poder cargar el resto del sistema, son necesarios controladores que debe-
rán cargarse en una primera fase; un ejemplo de ello serían controladores es-
pecíficos de disco como controladores RAID o de volúmenes, que serían
necesarios para después, en una segunda fase, acceder al disco para cargar el
resto del sistema.
El kernel puede generarse con o sin imagen initrd, dependerá de las necesida-
des del hardware o sistema concreto. En algunos casos la distribución impone
la necesidad de usar imagen initrd, en otros casos dependerá de nuestro hard-
ware. También se suele utilizar para vigilar el tamaño del kernel, de manera que
puede cargarse lo básico de éste a través de la imagen initrd, y posteriormente
cargar el resto en forma de módulos en una segunda fase. En el caso de nece-
sitar la imagen initrd, se crearía con la utilidad mkinitrd (ver man, o taller del
capítulo), dentro del directorio /boot.
3) El siguiente paso es decirle al sistema con qué kernel tiene que arrancar,
aunque esto depende del sistema de arranque de Linux:
a) Desde arranque con lilo [Zan][Skoa], ya sea en el MBR (master boot record) o
desde partición propia, hay que añadir al fichero de configuración (en: /etc/
lilo.conf), por ejemplo las líneas:
image = /boot/vmlinuz-2.4.0
label = 2.4.0
donde image es el kernel que se va arrancar, y label será el nombre con el que
aparecerá la opción en el arranque. Podemos añadir estas líneas o modificar
las que hubiera del kernel antiguo. Se recomienda añadirlas y dejar el kernel
antiguo, por si aparecen problemas, poder recuperar el antiguo. En el fichero
/etc/lilo.conf puede haber una o más configuraciones de arranque, tanto de Li-
nux como de otros sistemas (como Windows).
[Gor]. Si el sistema utiliza, initrd, también habrá que indicar cuál es el fi-
chero (que también estará localizado en /boot/initrd-versiónkernel), con la
opción “initrd=”. Después de cambiar la configuración del lilo, hay que es-
cribirla para que arranque:
/sbin/lilo -v
• Algunos de los módulos del kernel han cambiado de nombre, y algunos han
podido desaparecer, hay que comprobar la situación de los módulos diná-
micos que se cargan (por ejemplo, examinar /etc/modules y/o /etc/modu-
les.conf), y editarlos para reflejar los cambios.
• En Debian a partir de ciertas versiones del 2.6.x, para las imágenes binarias
de kernels, headers y código fuente cambia el nombre de los paquetes de ker-
nel-images/source/headers a linux-image/source/headers.
• Respecto a las arquitecturas que soporta el kernel, hay que tener en cuenta
que con los kernel 2.6.x, en las diferentes revisiones, se han ido incremen-
tando las arquitecturas soportadas, lo que nos permitirá disponer de imáge-
nes binarias del kernel en las distribuciones (o las opciones de compilación
del kernel) más adecuadas para el soporte de nuestros procesadores. En con-
creto podemos encontrarnos con arquitecturas como i386 (para intel y
AMD): soportando la compatibilidad de Intel en 32 bits para toda la familia
de procesadores (en algunas distribuciones es usada 486 como arquitectura
general), en algunas distribuciones se integran versiones diferenciadas para
i686 (Intel a partir de pentium pro en adelante), para k7 (AMD Athlon en
adelante), y las específicas de 64 bits, para AMD 64 bits, e Intel con exten-
siones em64t de 64 bits como los Xeon, y Multicores. Por otra parte, tam-
bién existe la arquitectura IA64 para los modelos 64bits Intel Itanium. En
la mayoría de los casos, las arquitecturas disponen de las capacidades SMP
activadas en la imagen del kernel (a no ser que la distribución soporte ver-
siones con SMP o sin, creadas independientemente, en este caso, suele aña-
dirse el sufijo -smp a la imagen que lo soporta).
© FUOC • P07/M2103/02283 26 El kernel
Una vez descargado el kernel 2.6.x (sea x el número de revisión del kernel, o el
par de números) en el directorio que se usará para la compilación, y compro-
badas las versiones necesarias de las utilidades básicas, se procede al proceso
de compilación, y limpieza de anteriores compilaciones:
# make menuconfig
# make dep
# make bzImage
# make modules
# make modules_install
# cp arch/i386/boot/bzimage /boot/vmlinuz-2.6.x.img
# make install
pero hay que tener en cuenta que realiza todo el proceso, y actualizará los boot-
loaders, quitando antiguas configuraciones o alterándolas; asimismo, pueden al-
terarse los enlaces por defecto en el directorio /boot. Hay que tenerlo en cuenta
a la hora de pensar en las configuraciones pasadas que queremos guardar.
# update-initramfs -c -k 'version'
Para el proceso nos serán necesarias una serie de utilidades (instalar los paque-
tes, o similares): kernel-package, ncurses-dev, fakeroot, wget, bzip2.
En el primer caso, pasamos por obtener la versión de las fuentes del kernel que
nos proporciona la distribución (sea x la revisión del kernel 2.6): Nota
donde obtenemos las fuentes y las descomprimimos (el paquete deja el archi-
vo en /usr/src).
$ cd linux-source-2.6.x
$ fakeroot debian/rules binary
$ make menuconfig
construcción final del kernel dependiendo de initrd o no, sin initrd disponible
(hay que tener cuidado con la versión utilizada; a partir de cierta versión del
kernel, puede ser obligatorio el uso de imagen initrd):
$ make-kpkg clean
$ fakeroot make-kpkg --revision=custom.1.0 kernel_image
$ make-kpkg clean
$ fakeroot make-kpkg --initrd --revision=custom.1.0 kernel_image
El proceso finalizará con la obtención del paquete asociado a la imagen del ker-
nel, que podremos finalmente instalar:
# dpkg -i ../linux-image-2.6.x_custom.1.0_i386.deb
© FUOC • P07/M2103/02283 29 El kernel
# m-a prepare
# m-a auto-install nombre_modulo
Lo cual prepara el sistema para posibles dependencias, descarga fuentes del mó-
dulo, compila y, si no hay problemas, instala para el presente kernel. El nombre
del módulo podemos observarlo de la lista interactiva de module-assistant.
© FUOC • P07/M2103/02283 30 El kernel
4. Parchear el kernel
patchxxxx-2.6.21-pversion.bz2
donde xxxx suele ser algún mensaje sobre el tipo o finalidad del parche. 2.6.21
sería la versión del kernel al cual se le va a aplicar el parche, y pversion haría
referencia a la versión del parche, del que también pueden existir varias. Hay
que tener en cuenta que estamos hablando de aplicar parches a las fuentes del
kernel (normalmente instaladas, como vimos, en /usr/src/linux o directorio si-
milar).
Una vez dispongamos del parche, tendremos que aplicarlo, veremos el proceso
a seguir en algún fichero readme que acompañe al parche, pero generalmente
el proceso sigue los pasos (una vez comprobados los requisitos previos) de des-
comprimir el parche en el directorio de los ficheros fuente y aplicarlo sobre las
fuentes del kernel, como por ejemplo:
bunzip2 patch-xxxxx-2.6.21-version.bz2
patch -p1 < patch-xxxxx-2.6.21-version
mismos, y sistemas para actualizarlos (algunos incluso de forma automática, En sistemas que se quieran te-
ner actualizados, por razones
como en el caso de Fedora/Red Hat y Debian). Normalmente, en sistemas de de test o de necesidad de las
últimas prestaciones, siempre
producción es más recomendable seguir las actualizaciones del fabricante, se puede acudir a www.
aunque éste no ofrecerá necesariamente el último kernel publicado, sino el que kernel.org y obtener el kernel
más moderno publicado.
crea más estable para su distribución, bajo pena de perder prestaciones de úl-
tima generación, o alguna novedad en las técnicas incluidas en el kernel.
© FUOC • P07/M2103/02283 32 El kernel
A continuación se busca en
/lib/modules/version_kernel/modules.dep
para saber si hay dependencias con otros módulos. Finalmente, con el coman-
do insmod se carga el módulo desde /lib/modules/version_kernel/ (el directo-
rio estándar para los módulos), la version_kernel es la versión del kernel actual,
se utiliza el comando uname -r para determinarla. Por lo tanto, los módulos
en forma binaria están relacionados con una versión concreta del kernel, y sue-
len colocarse en /lib/modules/version-kernel.
Si hay que compilarlos, se tiene que disponer de las fuentes y/o headers de la
versión del núcleo al cual está destinado. Nota
Ejemplo
Ya sea por el mismo kernel, o por el usuario manualmente con insmod, nor-
malmente para la carga se especificará el nombre del módulo, y opcionalmen-
te determinados parámetros. Por ejemplo, en el caso de que sean dispositivos,
suele ser habitual especificar las direcciones de los puertos de E/S o bien los re-
cursos de IRQ o DMA. Por ejemplo:
• Cumplimiento de los estándares IEEE POSIX, esto permite que muchos de los
programas existentes de UNIX pueden recompilarse y ejecutarse en Linux.
En serie actual, la rama del kernel 2.6.x [Pra], dispuso de importantes avances
respecto a la anterior (con las diferentes revisiones .x de la rama 2.6):
• Sistemas de ficheros con journal: JFS, JFS2 (IBM), y XFS (Silicon Graphics).
• UML, User Mode Linux, una especie de máquina virtual de Linux sobre Li-
nux que permite ver un Linux (en modo usuario) ejecutándose sobre una
máquina virtual. Esto es ideal para la propia depuración, ya que se puede
desarrollar y testear una versión de Linux sobre otro sistema, esto es útil
tanto para el propio desarrollo del kernel, como para un análisis de seguri-
dad del mismo.
POSIX:
www.UNIX-systems.org/
• La mejora de sistemas de ficheros para clustering, y sistemas distribuidos.
También, aunque se aparta de los sistemas Linux, la FSF (Free Software Founda-
tion) y su proyecto GNU siguen trabajando en su proyecto de acabar un sistema Nota
operativo completo. Cabe recordar que el proyecto GNU tenía como principal ob- El proyecto GNU:
http://www.gnu.org/gnu/
jetivo conseguir un clon UNIX de software libre, y las utilidades GNU sólo son el thegnuproject.html
software de sistema necesario. A partir de 1991, cuando Linus consigue conjuntar
su kernel con algunas utilidades GNU, se dio un primer paso que ha acabado en
los sistemas GNU/Linux actuales. Pero el proyecto GNU sigue trabajando en su
idea de terminar el sistema completo. En este momento disponen ya de un núcleo
en el que pueden correr sus utilidades GNU. A este núcleo se le denomina Hurd;
y a un sistema construido con él se le conoce como GNU/Hurd. Ya existen algu-
nas distribuciones de prueba, en concreto, una Debian GNU/Hurd.
Hurd fue pensado como el núcleo para el sistema GNU sobre 1990 cuando co-
menzó su desarrollo, ya que entonces la mayor parte del software GNU estaba Nota
desarrollado, y sólo faltaba el kernel. Fue en 1991 cuando Linus combinó GNU GNU y Linux, por Richard
Stallman:
con su kernel Linux y creó así el inicio de los sistemas GNU/Linux. Pero Hurd http://www.gnu.org/gnu/
linux-and-gnu.html
sigue desarrollándose. Las ideas de desarrollo en Hurd son más complejas, ya
que Linux podría considerarse un diseño “conservador”, que partía de ideas
ya conocidas e implantadas.
# apt-get update
4) Comprobar, para la versión elegida, que existan los módulos accesorios extras
(con el mismo número de versión). Con apt-cache buscamos si existen otros mó-
dulos dinámicos que puedan ser interesantes para nuestro hardware, según la ver-
sión del kernel a instalar. Recordar que, como vimos en la “Debian way”, también
existe la utilidad module-assistant, que nos permite automatizar este proceso des-
pués de la compilación del kernel. Si los módulos necesarios no fueran soportados,
esto nos podría impedir actualizar el kernel si consideramos que el funcionamien-
to del hardware problemático es vital para el sistema.
5) Buscar, si queremos disponer también del código fuente del kernel, los Linux-
source-version (sólo el 2.6.21, o sea, los números principales), y los kernel-headers
correspondientes, por si más tarde queremos hacer un kernel personalizado: en
este caso, el kernel genérico correspondiente parcheado por Debian.
una vez hecha esta configuración, tendríamos que tener un lilo del modo
(fragmento), suponiendo que initrd.img y vmlinuz sean enlaces a la posición
de los ficheros del nuevo kernel:
default = Linux
image = /vmlinuz
label = Linux
initrd = /initrd.img
# restricted
# alias = 1
© FUOC • P07/M2103/02283 40 El kernel
image = /vmlinuz.old
label = LinuxOLD
initrd = /initrd.img.old
# restricted
# alias = 2
Tenemos la primera imagen por defecto, la otra es el kernel antiguo. Así, desde
el menú lilo podremos pedir una u otra, o simplemente cambiando el default
recuperar la antigua. Siempre que realicemos cambios en /etc/lilo.conf no de-
bemos olvidarnos de reescribirlos en el sector correspondiente con el coman-
do /sbin/lilo o /sbin/lilo -v.
Por ejemplo, en la figura 10, observamos que una vez puesto en ejecución nos
ha detectado una nueva versión del kernel disponible y podemos seleccionarla
para que nos la descargue:
Figura 3. El servicio de actualización de Red Hat (Red Hat Network up2date) muestra la actualiza-
ción del kernel disponible y sus fuentes.
© FUOC • P07/M2103/02283 41 El kernel
#fichero grub.conf
default = 1
timeout = 10
splashimage = (hd0,1)/boot/grub/splash.xpm.gz
Vamos a ver el caso general de instalación de un kernel a partir de sus fuentes. Su-
pongamos que tenemos unas fuentes ya instaladas en /usr/src (o el prefijo corres-
pondiente). Normalmente, tendremos un directorio linux, o linux-version o
sencillamente el número version; éste será el árbol de las fuentes del kernel.
make dep
6) Ahora compilamos los módulos con make modules. Hasta este momento no
hemos modificado nada en nuestro sistema. Ahora tendremos que proceder a
la instalación.
cd /lib/modules
tar -cvzf old_modules.tgz versionkernel-antigua/
Así, tenemos una versión en .tgz que podríamos recuperar después en caso de
problemas. Y, finalmente, instalamos los módulos con:
# cd /usr/src/directorio-Fuentes/arch/i386/boot
# cp bzImage /boot/vmlinuz-versionkernel
# cp System.map /boot/System.map-versionkernel
# ln -s /boot/vmlinuz-versionkernel /boot/vmlinuz
# ln -s /boot/System.map-versionkernel /boot/System.map
10) Reiniciar la máquina y observar los resultados (si todo ha ido bien).
© FUOC • P07/M2103/02283 45 El kernel
Actividades
1) Determinar la versión actual del kernel Linux incorporada en nuestra distribución. Com-
probar las actualizaciones disponibles de forma automática, ya sea en Debian (apt) o en Fe-
dora/Red Hat (vía yum o up2date).
3) Para nuestra rama del kernel, determinar la última versión disponible (consultar www.ker-
nel.org), y realizar una instalación manual con los pasos examinados en la unidad. La insta-
lación final puede dejarse opcional, o bien poner una entrada dentro del bootloader para las
pruebas del nuevo kernel.
4) En el caso de la distribución Debian, además de los pasos manuales, existe como vimos
una forma especial (recomendada) de instalar el kernel a partir de sus fuentes mediante el pa-
quete kernel-package.
[Kera] [lkm] Sitios web que recogen una parte de la comunidad del kernel de Linux. Dispone
de varios recursos de documentación y listas de correo de la evolución del kernel, su estabili-
dad y las nuevas prestaciones que se desarrollan.
[DBo] Libro sobre el kernel de Linux 2.4, que detalla los diferentes componentes y su imple-
mentación y diseño. Existe una primera edición sobre el kernel 2.2 y una nueva actualización
al kernel 2.6.
[Pra] Artículo que describe algunas de las principales novedades de la nueva serie 2.6 del ker-
nel Linux.
[Ker] [Mur] Proyectos de documentación del kernel, incompletos pero con material útil.
[Bac86] [Vah96] [Tan87] Algunos textos sobre los conceptos, diseño e implementación de los
kernels de diferentes versiones UNIX.
[Skoa][Zan01][Kan][Pro] Para tener más información sobre los cargadores lilo y grub.
© FUOC • P07/M2103/02283 46 El kernel
Administración
local
Josep Jorba Esteve
P07/M2103/02284
© FUOC • P07/M2103/02284 Administración local
Índice
Introducción............................................................................................... 5
Actividades ................................................................................................. 65
Introducción
Una de las primeras tareas con la que tendrá que enfrentarse el administrador
será la gestión de los recursos locales presentes en la máquina. En el curso de
introducción a GNU/Linux, se cubrieron algunos de estos aspectos de forma
básica. En el presente, veremos algunas de estas tareas de administración de
forma más profunda, y algunos de los aspectos de personalización y rendi-
miento de los recursos.
A continuación aprenderemos cómo obtener una visión general del estado ac-
tual del sistema por medio de los diferentes procedimientos y comandos de Nota
que se dispone para evaluar las diversas partes del sistema; de este modo po- La administración local englo-
ba muchas tareas variadas, que
dremos tomar decisiones de administración si detectamos algún fallo o defi- quizás sean las más utilizadas
por el administrador en su tra-
ciencia de rendimiento, o la falta de algún recurso. bajo diario.
1. Distribuciones: particularidades
Intentamos destacar ahora algunas diferencias técnicas menores (que cada vez
se reducen más) en las distribuciones (Fedora/Red Hat y Debian) utilizadas
[Mor03], que iremos viendo con más detalle a lo largo de las unidades, a me-
dida que vayan apareciendo.
• Uso del gestor de arranque grub (una utilidad GNU), a diferencia de pasa-
Nota
das versiones de la mayoría de distribuciones que suelen usar lilo, Fedora
utiliza grub. GRUB (grand unified bootloader) tiene una configuración en Es importante conocer los de-
talles de una distribución, ya
modo texto (normalmente en /boot/grub/grub.conf) bastante sencilla, y que pueden ser básicos para
resolver una tarea o acelerar su
que puede modificarse en el arranque. Es quizás más flexible que lilo. Últi- solución (por ejemplo, si dis-
pone de herramientas pro-
mamente las distribuciones tienden al uso de grub, Debian también lo in- pias).
cluye como opcional.
En el caso de Debian:
dpkg-reconfigure gdm
dpkg-reconfigure X-Window-system
Finaliza servicios y programas activos, así como desmonta filesystems activos y para la
0 Parada
CPU.
2 Multiusuario sin red No se inician servicios de red, permitiendo sólo entradas locales en el sistema.
3 Multiusuario Inicia todos los servicios excepto los gráficos asociados a X Window.
5 Multiusuario X Igual que el 3, pero con soporte X para la entrada de usuarios (login gráfico).
Por contra cabe señalar que Debian usa un modelo, en el que los niveles 2-5
son prácticamente equivalentes, realizando exactamente la misma función
(aunque podría ocurrir que en alguna versión esto fuera a cambiar para coin-
cidir con el estándar LSB).
En el caso del modelo runlevel de SystemV, cuando el proceso init arranca, uti-
liza un fichero de configuración llamado /etc/inittab para decidir el modo de
ejecución en el que va a entrar. En este fichero se define el runlevel por defecto
(initdefault) en arranque (por instalación en Fedora el 5, en Debian el 2), y una
serie de servicios de terminal por activar para atender la entrada del usuario.
Cada script posee un nombre relacionado con el servicio, una S o K inicial que
indica si es el script para iniciar (S) o matar (K) el servicio, y un número que
refleja el orden en que se ejecutarán los servicios.
Una serie de comandos de sistema sirven de ayuda para manejar los niveles de
ejecución, cabe mencionar:
• Los scripts, que ya hemos visto, en /etc/init.d/ nos permiten arrancar, parar
o reiniciar servicios individuales.
• telinit, nos permite cambiar de nivel de ejecución, sólo tenemos que indicar
el número. Por ejemplo, necesitamos hacer una tarea crítica en root; sin usua-
rios trabajando, podemos hacer un telinit 1 (también puede usarse S) para
pasar a runlevel monousuario, y después de la tarea un telinit 3 para volver a
multiusuario. También puede utilizarse el comando init para la misma tarea,
© FUOC • P07/M2103/02284 11 Administración local
aunque telinit aporta algún parámetro extra. Por ejemplo, el reinicio típico
de un sistema UNIX se hacía con sync; sync; sync; init 6, el comando
sync fuerza el vaciado de los buffers del sistema de archivos, y luego rei-
niciamos en runlevel 6.
El arranque real de los servicios se hace por medio de los guiones almace-
nados en /etc/rc.d/init.d. Hay también un enlace desde /etc/init.d. Ade-
más, Fedora proporciona unos scripts de utilidad para manejar servicios:
/sbin/service para parar o iniciar un servicio por el nombre; y /sbin/chkconfig,
para añadir enlaces a los ficheros S y K necesarios para un servicio, o la ob-
tención de información sobre los servicios.
Una de las principales tareas del administrador (root) en su día a día, será veri-
ficar el correcto funcionamiento del sistema y vigilar la existencia de posibles
errores o de saturación de los recursos de la máquina (memoria, discos, etc.).
Pasaremos a detallar en los siguientes subapartados los métodos básicos para
examinar el estado del sistema en un determinado momento y llevar a cabo
las acciones necesarias para evitar problemas posteriores.
• Fichero /var/log/messages: log general del sistema, que contiene los men-
sajes generados por el kernel y otros daemons (puede haber multitud de ar-
chivos diferentes de log, normalmente en /var/log, y dependiendo de la
configuración del servicio syslog).
• Comando uptime: indica cuánto tiempo hace que el sistema está activo.
• Sistema /proc: pseudo sistema de ficheros (procfs) que utiliza el kernel para
almacenar la información de procesos y de sistema.
• Sistema /sys: pseudo sistema de ficheros (sysfs) que apareció con la rama
2.6.x del kernel, con objetivo de proporcionar una forma más coherente de
acceder a la información de los dispositivos y sus controladores (drivers).
© FUOC • P07/M2103/02284 14 Administración local
Hay que tener en cuenta que al ser /proc fuertemente dependiente del kernel,
propicia que su estructura dependa del kernel de que dispone el sistema y la
estructura y los ficheros incluidos pueden cambiar.
que el kernel maneja acerca de ellos. Cada proceso del sistema se puede encon- El directorio /proc es un recur-
so extraordinario para obtener
trar en el directorio /proc/<pidproceso>, donde hay un directorio con ficheros información de bajo nivel so-
bre el funcionamiento del sis-
que representan su estado. Esta información es básica para programas de de- tema, muchos comandos de
sistema se apoyan en él para
puración, o bien para los propios comandos del sistema como ps o top, que sus tareas.
pueden utilizarla para ver el estado de los procesos. En general muchas de las
utilidades del sistema consultan la información dinámica del sistema desde
/proc (en especial algunas utilidades proporcionadas en el paquete procps).
Por otra parte, en /proc podemos encontrar otros ficheros de estado global del
sistema. Comentamos brevemente algunos ficheros que podremos examinar
para obtener información importante:
Fichero Descripción
Dentro del concepto de sys existe una estructura de datos en árbol de los dis-
positivos y controladores (digamos el modelo conceptual fijo), y cómo des-
pués se accede a él a través del sistema de ficheros sysfs (la estructura del cual
puede cambiar entre versiones).
3.4. Procesos
• ps: el comando estándar, lista los procesos con sus datos de usuario, tiem-
po, identificador de proceso y línea de comandos usada. Una de las opcio-
nes más utilizada es ps -ef (o -ax), pero hay muchas opciones disponibles
(ver man).
• top: una versión que nos da una lista actualizada a intervalos, monitorizan-
do dinámicamente los cambios. Y nos permite ordenar el listado de proce-
sos, por diferentes ítems, como gasto de memoria, de uso CPU, con
propósito de obtener un ranking de los procesos que acaparan los recursos.
Muy útil para dar indicios en situaciones extremas de saturación de uso de
recursos, de la posible fuente de problemas.
• kill: nos permite eliminar procesos del sistema mediante el envío de señales
al proceso como, por ejemplo, la de terminación kill -9 pid_del_proceso (9
corresponde a SIGKILL), donde indicamos el identificador del proceso. Útil
para procesos con comportamiento inestable o programas interactivos que
han dejado de responder. Podemos ver una lista de las señales validas en el
sistema con man 7 signal
Tanto el kernel como muchos de los daemons de servicios, así como diferentes
aplicaciones o subsistemas de GNU/Linux, pueden generar mensajes que va-
yan a parar a ficheros log, ya sea para tener una traza de su funcionamiento, o
bien para detectar errores o advertencias de malfuncionamiento o situaciones
críticas. Este tipo de logs son imprescindibles en muchos casos para las tareas
de administración y se suele emplear bastante tiempo de administración en el
procesamiento y análisis de sus contenidos.
© FUOC • P07/M2103/02284 17 Administración local
tail -f /var/log/messages
• uptime: tiempo que hace que el sistema está activo. Útil para comprobar
que no hay existido algún rearranque del sistema inesperado.
3.6. Memoria
Respecto a la memoria del sistema, tendremos que tener en cuenta que dispo-
nemos: a) de la memoria física de la propia máquina, b) memoria virtual, que
puede ser direccionada por los procesos. Normalmente (a no ser que estemos
tratando con servidores empresariales), no dispondremos de cantidades dema-
siado grandes, de modo que la memoria física será menor que el tamaño de
memoria virtual necesario (4GB en sistemas de 32bits). Esto obligará a utilizar
una zona de intercambio (swap) sobre disco, para implementar los procesos
asociados a memoria virtual.
• Comando ps: permite conocer qué procesos tenemos, y con las opciones
de porcentaje y memoria usada.
• Algunos paquetes como dstat permite recoger datos de los diferentes paráme-
tros (memoria, swap, y otros) a intervalos de tiempo (de forma parecida a top).
Respecto a este ultimo comando df -k, una de nuestras tareas básicas de admi-
nistración de la máquina es controlar los recursos de la máquina, y en este
caso el espacio disponible en los filesystems utilizados. Estos tamaños hay que
monitorizarlos con cierta frecuencia para evitar la caída del sistema; nunca
tendría que dejarse un filesystem (y más si es el /) por debajo de un 10 o 15%,
ya que hay muchos procesos daemons que están escribiendo normalmente in-
formación temporal o logs, que pueden generar gran información; un caso
particular lo forman los ficheros core, ya comentados, que pueden suponer
(dependiendo del proceso) tamaños muy grandes de archivo. Normalmente,
habrá que tener algunas precauciones de “limpieza del sistema” si se detectan
situaciones de saturación del filesystem:
• Hay otros puntos del sistema que suelen crecer mucho, como pueden ser:
a) ficheros core de los usuarios: podemos eliminarlos periódicamente o eli-
minar su generación; b) el sistema de correo electrónico: almacena todos
los correos enviados y recibidos, podemos pedir a los usuarios que hagan
© FUOC • P07/M2103/02284 21 Administración local
limpieza periódica, o bien poner sistemas de cuotas; c) las cachés de los na-
vegadores u otras aplicaciones: también suelen tener tamaños grandes, otra
limpieza que habrá que hacer periódicamente; d) las cuentas de los propios
usuarios: pueden tener cuotas para no exceder los tamaños prefijados, etc.
© FUOC • P07/M2103/02284 22 Administración local
4. Sistema de ficheros
resante compartir datos con estos sistemas, ya sea para leer sus ficheros o mo-
dificarlos. A diferencia de otros sistemas (que sólo tienen en cuenta sus
propios datos y sistemas de ficheros, y en los cuales en algunas versiones no
se soportan algunos de sus propios sistemas de ficheros), GNU/Linux es capaz
de tratar, como hemos visto, con una cantidad enorme de sistemas de ficheros
de diferentes operativos y poder compartir la información.
Ejemplo
Para que se puedan leer o escribir los datos, la partición tiene que estar dispo-
nible dentro de nuestro sistema de ficheros raíz (/). Por lo tanto, hay que llevar
a cabo un proceso de “montaje” del sistema de ficheros en algún punto de
nuestro árbol de directorios. Se seguirá el mismo proceso si se trata de un dis-
positivo de almacenamiento, ya sea disquete o floppy.
tandard FHS, /mnt se debería usar para montajes temporales de sistemas de ar-
chivo, mientras /media se utilizaría para montar dispositivos removibles.
El tipo de filesystem puede ser: msdos (fat), vfat (fat32), ntfs (ntfs lectura),
iso9660 (para cdrom)... (de los posibles).
montaría el CD-ROM (si es el IDE que está en el segundo IDE de forma máster)
en el punto /mnt/cdrom.
montaría el CD-ROM; /dev/cdrom se usa como sinónimo (es un link) del dis-
positivo donde está conectado.
montaría la segunda partición del primer dispositivo IDE (la C:), de tipo NTFS
(por ejemplo un Windows XP).
Por ejemplo, esta configuración incluye algunos de los sistemas estándar, como la
raíz en /dev/hda2, la partición de swap que está en hdb3, el sistema proc (que uti-
liza el kernel para guardar su información). Y el disquete, el CD-ROM, y en este
caso un disco USB de tipo Flash (que se detecta como un dispositivo SCSI). En al-
gunos casos, se especifica auto como tipo de filesystem. Esto permite que se auto-
detecte el sistema de ficheros. Si se conoce, es mejor indicarlo en la configuración,
y por otra parte, el noauto en las opciones permite que no sea montado de forma
automática siempre, sino bajo petición (o acceso).
mount /mnt/cdrom
mount /dev/fd0
umount /mnt/cdrom
umount /dev/fd0
eject /dev/cdrom
eject
Los comandos mount y umount montan o desmontan todos los sistemas dis-
ponibles. En el fichero /etc/mtab se mantiene una lista de los sistemas monta-
dos en un momento concreto, que se puede consultar, o ejecutar mount sin
parámetros para obtener esta información.
© FUOC • P07/M2103/02284 27 Administración local
4.2. Permisos
Otro tema que habrá que controlar en el caso de los ficheros y directorios es el
de los permisos que queremos establecer en cada uno de ellos, recordando que
cada fichero puede disponer de la serie de permisos: rwxrwxrwx donde se co-
rresponden con rwx del propietario, rwx del grupo al que el usuario pertenece,
y rwx para otros usuarios. En cada uno se puede establecer el permiso de lec-
tura (r), escritura (w) o ejecución (x). En el caso de un directorio, x denota el
permiso para poder entrar en ese directorio (con el comando cd, por ejemplo).
Para modificar los derechos sobre un directorio o fichero, existen los co-
mandos:
5. Usuarios y grupos
• La del administrador, con identificador root, que sólo es (o debería ser) utiliza-
da para las operaciones de administración. El usuario root es el que dispone de
más permisos y acceso completo a la máquina y a los archivos de configura-
ción. Por lo tanto, también es el que más daño puede causar por errores u omi-
siones. Es mejor evitar usar la cuenta de root como si fuese un usuario más, por
lo que se recomienda dejarla sólo para operaciones de administración.
La información de los usuarios del sistema está incluida en los siguientes ar-
chivos:
/etc/passwd
/etc/shadow
/etc/group
/etc/gshadow
juan:x:1000:1000:Juan Garcia,,,:/home/juan:/bin/bash
root:x:0:0:root:/root:/bin/bash
© FUOC • P07/M2103/02284 29 Administración local
• x: palabra de paso del usuario codificada, si hay una “x” es que se encuen-
tra en el fichero /etc/shadow.
• 1000: código del usuario, lo usa el sistema como código de identidad del
usuario.
• 1000: código del grupo principal al que pertenece, la información del gru-
po en /etc/group.
Para evitar esto, hoy en día ya no se colocan las palabras de paso en este archi-
vo, sólo una “x” que indica que se encuentran en otro fichero, que es sólo de
lectura para el usuario root, /etc/shadow, cuyo contenido podría ser algo pare-
cido a lo siguiente:
juan:a1gNcs82ICst8CjVJS7ZFCVnu0N2pBcn/:12208:0:99999:7:::
• Días desde 1 de enero de 1970 en que la palabra de paso se cambió por úl-
tima vez.
• Y un campo reservado.
Además, las claves de encriptación pueden ser más difíciles, ya que ahora pue-
de utilizarse un sistema denominado md5 (suele aparecer como opción a la
hora de instalar el sistema) para proteger las palabras de paso de los usuarios.
Veremos más detalles al respecto en la unidad dedicada a la seguridad.
jose:x:1000:
donde tenemos:
nombre-grupo:contraseña-grupo:identificador-del-
grupo:lista-usuarios
La lista de usuarios del grupo puede estar presente o no, ya que la información ya
está en /etc/passwd, no suele ponerse en /etc/group. Si se pone, suele aparecer
como una lista de usuarios separada por comas. Los grupos también pueden po-
seer una contraseña asociada (aunque no suele ser tan común), como en el caso
de los de usuario, también existe un fichero de tipo shadow: /etc/gshadow.
Otros ficheros interesantes son los del directorio /etc/skel, donde se hallan los
ficheros que se incluyen en cada cuenta de usuario al crearla. Recordar que,
como vimos con los shell interactivos, podíamos tener unos scripts de configu-
ración que se ejecutaban al entrar o salir de la cuenta. En el directorio skel se
guardan los “esqueletos” que se copian en cada usuario al crearlo. Suele ser res-
ponsabilidad del administrador crear unos ficheros adecuados para los usua-
rios, poniendo los path necesarios de ejecución, inicialización de variables de
sistema, variables que se necesiten para el software, etc.
A continuación vamos a ver una serie de comandos útiles para esta adminis-
tración de usuarios (mencionamos su funcionalidad y en el taller haremos al-
gunas pruebas):
6. Servidores de impresión
Para la situación actual, el sistema LPD se combina con otro software común,
como el sistema Ghostscript, que ofrece salida de tipo postscript para un rango Nota
muy amplio de impresoras para las que posee controladores. Además, se suele Los sistemas UNIX disponen,
quizás, de los sistemas de im-
combinar con algún software de filtraje, que según el tipo de documento a im- presión más potentes y com-
plejos, que aportan una gran
primir, selecciona filtros adecuados. Así, normalmente el proceso que se sigue flexibilidad a los entornos de
es (básicamente): impresión.
Además del sistema de impresión LPD (con origen en los BSD UNIX), también
existe el denominado sistema System V (de origen en la otra rama UNIX de
System V). Normalmente, por compatibilidad, la mayor parte de UNIX inte-
gran actualmente ambos sistemas, de manera que o bien uno u otro es el prin-
cipal, y el otro se simula sobre el principal. En el caso de GNU/Linux, pasa algo
parecido, según la instalación que hagamos, podemos tener sólo los coman-
dos LPD de sistema de impresión, pero también será habitual disponer de los
© FUOC • P07/M2103/02284 34 Administración local
comandos System V. Una forma sencilla de identificar los dos sistemas (BSD o
System V), es con el comando principal de impresión (el que envía los trabajos
al sistema), en BSD es lpr, y en System V es lp.
bilidad y una mayor disposición de controladores para las impresoras. Los dos LPRng: http://www.lprng.org
CUPS: http://www.cups.org
principales sistemas son CUPS, y en menor grado LPRng. Siendo, de hecho, úl-
timamente CUPS el estándar de facto para GNU/Linux, aunque los otros siste-
mas han de ser soportados por compatibilidad con sistemas UNIX existentes.
Los dos (tanto CUPS como LPRng) son una especie de sistemas de más alto ni-
vel, pero que no se diferencian en mucho de cara al usuario respecto a los BSD
y System V estándar, por ejemplo, se utilizan los mismos comandos clientes
(o compatibles en opciones) para imprimir. Para el administrador sí que su-
pondrá diferencias, ya que los sistemas de configuración son diferentes. En
cierto modo podemos considerar a LPRng y CUPS como nuevas arquitecturas
de sistemas de impresión, que son compatibles de cara al usuario con los co-
mandos antiguos.
• LPRng: se diseñó básicamente para ser un reemplazo del BSD, por lo tanto,
la mayor parte de la configuración es parecida y únicamente difiere en al-
gunos ficheros de configuración.
o de los fabricantes (por ejemplo HP y Epson los proporcionan); Gimp, el Se puede encontrar informa-
ción de las impresoras más
programa de retoque de imágenes también posee controladores optimiza- adecuadas y de los controlado-
res en:
dos para la impresión de imágenes; Foomatic es un sistema de gestión de http://www.linuxprinting.org/
controladores que funciona con la mayoría de sistemas (CUPS, LPD, foomatic.html
LPRng, y otros); los controladores de Ghostscript, etc. En casi todas las im-
presoras tienen uno o más controladores de estos conjuntos.
Respecto a la parte cliente del sistema, los comandos básicos son iguales para
los diferentes sistemas, y éstos son los comandos del sistema BSD (cada siste-
ma soporta emulación de estos comandos:
rrespondiente, y asigna un número de trabajo, que será usado con los otros
comandos. Normalmente, la impresora por defecto estaría indicada por
una variable de sistema PRINTER, o se utilizará la primera que exista defi-
nida, o en algunos sistemas se utiliza la cola lp (como nombre por defecto).
Ejemplo
Ejemplo de lpr:
Esta instrucción mandaría el fichero datos.txt a la cola de impresión asociada a una im-
presora que hemos definido como “epson”.
Ejemplo
Ejemplo
# lpq -P epson
Rank Owner Job Files Total Size
1st juan 15 datos.txt 74578 bytes
2nd marta 16 fpppp.F 12394 bytes
Este comando nos muestra los trabajos en cola, con el orden y tamaños de éstos;
los ficheros pueden aparecer con nombres diferentes, ya que depende de si los
hemos enviado con lpr, o con otra aplicación que puede cambiarlos de nom-
bre al enviarlos, o si han tenido que pasar por algún filtro al convertirlos.
Ejemplo
lprm -Pepson 15
Cabe mencionar asimismo que, para el caso de System V, los comandos de im-
presión suelen también estar disponibles, normalmente simulados sobre los
de BSD. En el caso cliente, los comandos son: lp, lpstat, cancel y para temas de
administración: lpadmin, accept, reject, lpmove, enable, disable, lpshut.
En el caso del servidor BSD LPD, hay dos ficheros principales para examinar,
por una parte, la definición de las impresoras en /etc/printcap, y por otra, los
permisos de acceso por red en /etc/hosts.lpd.
Respecto al tema de los permisos, por defecto BSD LPD sólo deja acceso local a la
impresora, y por lo tanto, hay que habilitarlo expresamente en /etc/hosts.lpd.
Ejemplo
#fichero hosts.lpd
second
first.the.com
192.168.1.7
+@groupnis
-three.the.com
que indicaría que está permitida la impresión a una serie de máquinas, listadas
bien por su nombre DNS o por la dirección IP. Se pueden añadir grupos de má-
quinas que pertenezcan a un servidor NIS (como en el ejemplo groupnis) o bien
no permitir acceso a determinadas máquinas indicándolo con un guión “-”.
Veamos un ejemplo:
6.2. LPRng
En el caso del sistema LPRng, ya que éste se hizo para mantener la compatibi-
lidad con BSD, y entre otros mejorar aspectos de acceso, el sistema es compa-
tible a nivel de configuración de colas, y se lleva a cabo a través del mismo
formato de fichero de /etc/printcap, con algunos añadidos propios.
DEFAULT ACCEPT
DEFAULT REJECT
ACCEPT [ key = value[,value]* ]*
REJECT [ key = value[,value]* ]*
donde los dos primeros nos permiten establecer el valor por defecto, de aceptar
todo, o rechazar todo, y los dos siguientes, aceptar o rechazar una configuración
concreta especificada en la línea. Se pueden aceptar (o rechazar) peticiones de un
host, usuario, o puertos IP específicos. Asimismo, se puede configurar qué tipo de
servicio se proporcionará al elemento: X (puede conectarse), P (impresión de tra-
bajos), Q (examinar cola con lpq), M (borrar trabajos de la cola, lprm), C (control
de impresoras, comando lpc), entre otros, así en el fichero:
Con esta configuración hay que tener especial cuidado, porque en algunas dis-
tribuciones, los servicios LPRng están por defecto abiertos. Puede limitarse la
conexión por ejemplo con:
Hay varios paquetes de software relacionados con LPRng, por ejemplo en una
Debian encontramos:
6.3. CUPS
llamado IPP (basado en http), pero sólo disponible cuando cliente y servidor son
de tipo CUPS. Además, utiliza un tipo de drivers denominados PPD que identi-
fican las capacidades de la impresora, CUPS ya trae algunos de estos controlado-
res, y algunos fabricantes también los ofrecen (caso HP y Epson).
Destacar que CUPS en principio está pensado para que tanto clientes, como el
servidor funcionen bajo el mismo sistema, si los clientes utilizan LPD o LPRng,
hay que instalar un daemon de compatibilidad llamado cups-lpd (normalmen-
te en paquetes como cupsys-bsd). En este caso, CUPS acepta trabajos que pro-
vengan de un sistema LPD o LPRng, pero no controla los accesos (cupsd.conf
sólo sirve para el propio sistema CUPS), por lo tanto, habrá que implementar
alguna estrategia de control de acceso, tipo firewall por ejemplo (ver unidad de
seguridad).
Respecto a los paquetes software relacionados con CUPS, en una Debian en-
contramos (entre otros):
• IDE: dispositivos
Con los discos y los sistemas de ficheros (filesystems) asociados, los procesos
básicos que podemos realizar los englobamos en:
Figura 3
• RAID 1: Se crea una copia exacta (mirror) en un conjunto de dos o más discos
(denominado array RAID). En este caso resulta útil para el rendimiento de lec-
tura (que puede llegar a incrementarse de forma lineal con el número de dis-
cos), y en especial por disponer de tolerancia al fallo de uno de los discos, ya
que (por ejemplo, con dos discos) se dispone de la misma información. RAID
1, suele ser adecuado para alta disponibilidad, como entornos de 24x7, donde
debemos disponer críticamente de los recursos. Esta configuración nos permi-
te también (si el hardware lo soporta) el intercambio en caliente de los discos.
Si detectamos el fallo en uno de ellos, podemos sustituirlo sin apagar el siste-
ma, por un disco nuevo.
Figura 4
© FUOC • P07/M2103/02284 46 Administración local
Figura 5
Figura 6
• RAID mejora el uptime del sistema, ya que algunos de los niveles permiten
que haya discos que fallan y el sistema siga siendo consistente, y depen-
diendo del hardware; incluso puede cambiarse el hardware problemático
en caliente sin necesidad de parar el sistema, cuestión especialmente im-
portante en sistema críticos.
GNU/Linux dispone en kernel del llamado Multiple Device (md), que podemos
considerarlo como el soporte mediante driver del kernel para RAID. Mediante este
driver podemos implementar niveles de RAID generalmente 0,1,4,5 y anidados
(por ejemplo, RAID 10) sobre diferentes dispositivos de bloque como discos IDE
o SCSI. También dispone del nivel linear como nivel donde se produce una com-
binación lineal de los discos disponibles (donde no importa que sean de diferen-
tes tamaños), de manera que se escribe consecutivamente en los discos.
Para la utilización del RAID software en Linux, debemos disponer del soporte
RAID en el kernel, y en su caso los modulos md activos (además de algunos drivers
específicos según el caso (ver drivers disponibles asociados a RAID, por ejemplo
en Debian con modconf). El método preferido para la implementación de
arrays de discos RAID, mediante el software RAID ofrecido por Linux, es me-
diante (o bien durante la instalación) o bien mediante la utilidad mdadm. Esta
utilidad nos permite crear los arrays y gestionarlos.
© FUOC • P07/M2103/02284 49 Administración local
# mkfs.ext2fs /dev/md0
# mount /dev/md0 /media/discoRAID
Por otra parte surge la necesidad de abstraerse del sistema físico de discos, y su
configuración, y numero de dispositivos, para que el sistema (operativo) se en-
cargue de este trabajo, y no nos tengamos que preocupar de estos parámetros
directamente. En este sentido, puede verse al sistema de volúmenes lógicos
como una capa de virtualización del almacenamiento permitiendo una visión
más simple que facilite la utilización fluida y sencilla.
En el kernel Linux se dispone de LVM (logical volume manager), que se basá a partir
de ideas desarrolladas de gestores de volúmenes de almacenamiento usados en
© FUOC • P07/M2103/02284 50 Administración local
HP-UX (una versión UNIX propietaria de HP). Actualmente existen dos versiones,
siendo la LVM2 la más utilizada por una serie de prestaciones añadidas.
# mkfs.reiserfs /dev/grupo_discos/volumen_logico
mkdir /mnt/backup
mount -t reiserfs /dev/grupo_discos/volumen_logico /mnt/backup
8. Software: actualización
• Tar, o bien los tgz (también tar.gz): son puramente paquetes de ficheros
unidos y comprimidos mediante comandos estándar como tar, y gzip (se
usan éstos para la descompresión). Estos paquetes no contienen informa-
ción de dependencias y normalmente pueden instalarse en diferentes luga-
res, si no es que llevan información de ruta (path) absoluta.
dora, o servicios de suscripción (de pago o con facilidades básicas) como el Red
Hat Network de las versiones Red Hat comerciales.
4) Por el propio creador o distribuidor del software, que ofrece una serie de
paquetes de instalación de su software. Podemos no encontrar el tipo de pa-
quetes necesario para nuestra distribución.
9. Trabajos no interactivos
Para realizar este tipo de trabajos “fuera de horas”, como servicios periódicos
o programados, hay diversos sistemas que nos permiten construir un tipo de
agenda de tareas (planificación de ejecución de tareas):
• nohup es quizás el caso más simple utilizado por los usuarios, les permite
la ejecución de una tarea no interactiva una vez hayan salido de su cuenta.
Normalmente, al salir de la cuenta, el usuario pierde sus procesos; nohup
permite dejarlos en ejecución, a pesar de que el usuario se desconecte.
• at nos permite lanzar una acción para más tarde, programando un deter-
minado instante en el que va a iniciarse, especificándose la hora (hh:mm)
y fecha, o bien si se hará hoy (today) o mañana (tomorrow). Ejemplos:
at 10pm tarea
• cron: permite establecer una lista de trabajos por realizar con su programa-
ción; esta configuración se guarda en /etc/crontab; concretamente, en cada
entrada de este fichero tenemos: minutos y hora en que se va a efectuar la
tarea, qué día del mes, qué mes, qué día de la semana, junto con qué (ya
sea una tarea, o bien un directorio donde estarán las tareas a ejecutar). Por
ejemplo, de forma estándar el contenido es parecido a:
donde se está programando que una serie de tareas van a hacerse: cada día (“*”
indica ‘cualquiera’), semanalmente (el 7.º día de la semana), o mensualmente
(el 1.º de cada mes). Normalmente, los trabajos serían ejecutados por el co-
mando crontab, pero el sistema cron supone que la máquina está siempre en-
© FUOC • P07/M2103/02284 56 Administración local
# uptime
17:38:22 up 2:46, 5 users, load average: 0.05, 0.03, 0.04
Este comando nos da el tiempo que lleva el sistema “levantado” desde que se
arrancó la última vez, 2 horas 46 minutos, en nuestro caso tenemos cinco
usuarios. Éstos no tienen por qué ser cinco usuarios diferentes, sino que nor-
malmente serán las sesiones de usuario abiertas (por ejemplo, mediante un
terminal). El comando who permite listar estos usuarios. El load average es la
carga media del sistema en los últimos 1, 5 y 15 minutos.
Veamos el log del arranque del sistema (comando dmesg), las líneas que se
iban generando en la carga del sistema (se han suprimido diferentes líneas por
claridad):
Estas primeras líneas ya nos indican varios datos interesantes: la versión del
kernel Linux es la 2.6.20-1-686, una versión 2.6 revisión 20 a revisión 1 de De-
© FUOC • P07/M2103/02284 58 Administración local
bian, y para máquinas 686 (arquitectura Intel 32bits). Indica también que es-
tamos arrancando un sistema Debian, con este kernel que fue compilado con
un compilador GNU gcc versión 4.1.2 y la fecha. A continuación, existe un
mapa de zonas de memoria usadas (reservadas) por la BIOS, y a continuación
el total de memoria detectada en la máquina: 759 MB, a las que habría que su-
mar el primer 1 MB, total de 760 MB.
Aquí nos refiere cómo ha sido el arranque de la máquina, qué línea de coman-
dos se le ha pasado al kernel (pueden pasarse diferentes opciones, por ejemplo
desde el lilo o grub). Y estamos arrancando en modo consola de 80 x 25 carac-
teres (esto se puede cambiar). Los BogoMIPS son una medida interna del kernel
de la velocidad de la CPU. Hay arquitecturas donde es difícil detectar con
cuántos MHz funciona la CPU, y por eso se utiliza esta medida de velocidad.
Después nos da más datos de la memoria principal, y para qué se está usando
en este momento del arranque.
Más detección de dispositivos, USB en este caso (y los módulos que correspon-
den), ha detectado dos dispositivos hub (con un total de 8 USB ports).
Toda esta información que hemos visto mediante el comando dmesg, también la
podemos encontrar volcada en el log principal del sistema /var/log/messages. En
este log, entre otros, encontraremos los mensajes del kernel y de los daemons, y
errores de red o dispositivos, los cuales comunican sus mensajes a un daemon es-
pecial llamado syslogd, que es el encargado de escribir los mensajes en este fiche-
ro. Si hemos arrancado la máquina recientemente, observaremos que las últimas
líneas contienen exactamente la misma información que el comando dmesg,
por ejemplo, si nos quedamos con la parte final del fichero (suele ser muy
grande):
exiting on signal 15
syslogd 1.4.1#20: restart.
tema... Al principio del arranque nuevo, se activa el daemon Syslogd que gene-
ra el log, y comienza la carga del sistema, que nos dice que el kernel comenzará
a escribir información en su sistema, /proc; vemos las primeras líneas de
dmesg de mención de la versión que se está cargando de kernel, y luego encon-
traremos lo que hemos visto con dmesg.
En este punto, otro comando útil para saber cómo se ha producido la carga es
ismod, que nos permitirá saber qué módulos se han cargado en el kernel (ver-
sión resumida):
# lsmod
Module Size Used by
nfs 219468 0
nfsd 202192 17
exportfs 5632 1 nfsd
lockd 58216 3 nfs,nfsd
nfs_acl 3616 2 nfs,nfsd
sunrpc 148380 13 nfs,nfsd,lockd,nfs_acl
ppdev 8740 0
lp 11044 0
button 7856 0
ac 5220 0
battery 9924 0
md_mod 71860 1
dm_snapshot 16580 0
dm_mirror 20340 0
dm_mod 52812 2 dm_snapshot,dm_mirror
i810fb 30268 0
vgastate 8512 1 i810fb
eeprom 7184 0
thermal 13928 0
processor 30536 1 thermal
fan 4772 0
udf 75876 0
ntfs 205364 0
usb_storage 75552 0
hid 22784 0
usbkbd 6752 0
eth1394 18468 0
e100 32648 0
eepro100 30096 0
ohci1394 32656 0
ieee1394 89208 2 eth1394,ohci1394
snd_intel8x0 31420 1
snd_ac97_codec 89412 1 snd_intel8x0
ac97_bus 2432 1 snd_ac97_codec
parport_pc 32772 1
snd 48196 6 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
ehci_hcd 29132 0
ide_cd 36672 0
cdrom 32960 1 ide_cd
soundcore 7616 1 snd
psmouse 35208 0
uhci_hcd 22160 0
parport 33672 3 ppdev,lp,parport_pc
intelfb 34596 0
serio_raw 6724 0
pcspkr 3264 0
pci_hotplug 29312 1 shpchp
usbcore 122312 6 dvb_usb,usb_storage,usbkbd,ehci_hcd,uhci_hcd
intel_agp 22748 1
agpgart 30504 5 i810fb,drm,intelfb,intel_agp
ext3 121032 1
jbd 55368 1 ext3
ide_disk 15744 3
ata_generic 7876 0
© FUOC • P07/M2103/02284 62 Administración local
ata_piix 15044 0
libata 100052 2 ata_generic,ata_piix
scsi_mod 133100 2 usb_storage,libata
generic 4932 0 [permanent]
piix 9540 0 [permanent]
ide_core 114728 5 usb_storage,ide_cd,ide_disk,generic,piix
Vemos que básicamente tenemos los controladores para el hardware que he-
mos detectado, y otros relacionados o necesarios por dependencias.
# ps -ef
UID PID PPID C STIME TTY TIME CMD
Información de los procesos, UID usuario que ha lanzado el proceso (o con qué
identificador se ha lanzado), PID, código del proceso asignado por el sistema, son
consecutivos a medida que se lanzan los procesos, el primero siempre es el 0, que
corresponde al proceso de init. PPID es el id del proceso padre del actual. STIME,
tiempo en que fue arrancado el proceso, TTY, terminal asignado al proceso (si tie-
ne alguno), CMD, línea de comando con que fue lanzado.
Tenemos dhclient, esto indica que esta máquina es cliente de un servidor DHCP,
para obtener su IP. Syslogd, un daemon que envía mensajes al log. El daemon de
cups, como vimos, relacionado con el sistema de impresión. E inetd, que, como
© FUOC • P07/M2103/02284 63 Administración local
También está sshd, servidor de acceso remoto seguro (una versión mejorada que
permite servicios compatibles con telnet y ftp). xfs es el servidor de fuentes (tipos
de letra) de X Window. Los comandos atd y cron sirven para manejar tareas pro-
gramadas en un momento determinado. Apache es el servidor web, que puede te-
ner varios hilos activos (threads) para atender diferentes peticiones.
Gdm es el login gráfico del sistema de escritorio Gnome (la entrada que nos
pide el login y contraseña), los procesos getty son los que gestionan los ter-
minales virtuales de texto (los que podemos ver con las teclas Alt+Fx (o
Ctrl+Alt+Fx si estamos en modo gráfico). X es el proceso de servidor gráfico
de X Window System, imprescindible para que se ejecute cualquier entor-
no de escritorio por encima de él. Un shell abierto (bash), y finalmente el
proceso que hemos generado al pedir este ps desde la línea de comandos.
Otros comandos útiles para uso de recursos son free y vmstat, que nos dan in-
Nota
formación sobre la memoria utilizada y el sistema de memoria virtual:
Ver man de los comandos para
interpretar las salidas.
# free
total used free shared buffers cached
Mem: 767736 745232 22504 0 89564 457612
-/+ buffers/cache: 198056 569680
Swap: 618492 1732 616760
# vmstat
procs -----------memory---------- ---swap-- -----io-- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 1732 22444 89584 457640 0 0 68 137 291 418 7 1 85 7
© FUOC • P07/M2103/02284 64 Administración local
Actividades
1) El espacio de swap permite complementar la memoria física para disponer de mayor me-
moria virtual. Dependiendo de los tamaños de memoria física y swap, ¿puede llegar a ago-
tarse la memoria? ¿Podemos solucionarlo de otro modo, que no sea añadiendo más memoria
física?
2) Supongamos que tenemos un sistema con dos particiones Linux, una / y la otra de swap.
¿Cómo solucionaríamos el caso de que las cuentas de los usuarios agotasen el espacio de dis-
co? Y en el caso de tener una partición /home aislada que se estuviera agotando, ¿cómo lo
solucionaríamos?
3) Instalad el sistema de impresión CUPS, definir nuestra impresora para que funcione con
CUPS y probar la administración vía interfaz web. Tal como está el sistema, ¿sería recomen-
dable modificar de algún modo la configuración que trae por defecto CUPS? ¿Por qué?
5) Reproducid el análisis del taller (más los otros apartados de la unidad) sobre la máquina
que se disponga, ¿se observan en el sistema algunos errores o situaciones anómalas? En tal
caso, ¿cómo las corregimos?
P07/M2103/02285
© FUOC • P07/M2103/02285 2 Administración de red
© FUOC • P07/M2103/02285 Administración de red
Índice
Introducción .............................................................................................. 5
6. IP aliasing ............................................................................................. 36
7. IP Masquerade ...................................................................................... 37
Actividades ................................................................................................. 53
Introducción
de ficheros remotos (network file system NFS) o su transferencia (file transfer pro- Utilización típica de TCP/IP
remote login: telnet
tocol FTP, hipertext markup protocol, HTTP). localhost Debian GNU/
Linux 4.0 login:
• eMail: este servicio permite enviar mensajes a los usuarios de otros ordena-
dores. Este modo de comunicación se ha transformado en un elemento vi-
tal en la vida de los usuarios y permite que los e-mails (correos electrónicos)
sean enviados a un servidor central para que después puedan ser recupera-
dos por medio de programas específicos (clientes) o leídos a través de una
conexión web.
Por un lado, TCP (transmission control protocol), define las reglas de co-
municación para que un ordenador (host) pueda ‘hablar’ con otro (si se
toma como referencia el modelo de comunicaciones OSI/ISO describe
la capa 4, ver tabla siguiente).
Por otro lado, IP (Internet protocol), define el protocolo que permite identi-
ficar las redes y establecer los caminos entre los diferentes ordenadores.
Es decir, encamina los datos entre dos ordenadores a través de las redes. Co-
rresponde a la capa 3 del modelo OSI/ISO y es un protocolo sin conexión (ver
tabla siguiente). [Com01, Rid00, Dra99]
Existe otro protocolo alternativo llamado ICMP (Internet control message proto-
col). ICMP se utiliza para mensajes de error o control. Por ejemplo, si uno in-
© FUOC • P07/M2103/02285 10 Administración de red
En resumen, TCP/IP es una familia de protocolos (que incluyen IP, TCP, UDP),
que proveen un conjunto de funciones a bajo nivel utilizadas por la mayoría
de las aplicaciones. [KD00, Dra99].
Algunos de los protocolos que utilizan los servicios mencionados han sido di-
señados por Berkeley, Sun u otras organizaciones. Ellos no forman oficialmen-
te parte de Internet protocol suite (IPS). Sin embargo, son implementados
utilizando TCP/IP y por lo tanto considerados como parte formal de IPS. Una
descripción de los protocolos disponibles en Internet puede consultarse en la
RFC 1011 (ver referencias sobre RFC [IET]), que lista todos los protocolos dis-
ponibles. Existe actualmente una nueva versión del protocolo IPv6, también
llamado IPng (IP next generation) que reemplaza al IPv4. Este protocolo mejora
notablemente el anterior en temas tales como mayor número de nodos, con-
trol de tráfico, seguridad o mejoras en aspectos de routing.
Desde el punto de vista físico (capa 1 del modelo OSI), el hardware más utili-
zado para LAN es conocido como Ethernet (o FastEthernet o GigaEthernet).
Sus ventajas son su bajo coste, velocidades aceptables (10, 100, o 1.000 mega-
bits por segundo) y facilidad en su instalación.
© FUOC • P07/M2103/02285 11 Administración de red
Las dos primeras están obsoletas (utilizan cable coaxial), mientras que la últi-
ma se realiza a través de cables (pares) trenzados y conectores similares a los
telefónicos (se conocen como RJ45). La conexión par trenzado es conocida
como 10baseT o 100baseT (según la velocidad) y utiliza repetidores llamados
hubs como puntos de interconexión. La tecnología Ethernet utiliza elementos
intermedios de comunicación (hubs, switchs, routers) para configurar múltiples
segmentos de red y dividir el tráfico para mejorar las prestaciones de transfe-
rencia de información. Normalmente, en las grandes instituciones estas LAN
Ethernet están interconectadas a través de fibra óptica utilizando tecnología
FDDI (fiber distributed data interface) que es mucho más cara y compleja de insta-
lar, pero se pueden obtener velocidades de transmisión equivalentes a Ethernet
y no tienen la limitación de la distancia de ésta (FDDI admite distancias de
hasta 200 km). Su coste se justifica para enlaces entre edificios o entre segmen-
tos de red muy congestionados.[Rid00, KD00].
Existe además otro tipo de hardware menos común, pero no menos interesan-
te, como es ATM (asynchronous transfer mode). Este hardware permite montar
LAN con una calidad de servicio elevada y es una buena opción cuando deben
montarse redes de alta velocidad y baja latencia, como por ejemplo aquellas
que involucren distribución de vídeo en tiempo real.
Ejemplo
Ethernet en GNU/Linux se llaman con ethx (donde en todas, 0 indica un número de or-
den comenzando por 0), la interfaz a líneas series (módems) se llaman por pppx (para
PPP) o slx (para SLIP), para FDDI son fddix. Estos nombres son utilizados por los coman-
dos para configurarlas y asignarles el número de identificación que posteriormente per-
mitirá comunicarse con otros dispositivos en la red.
© FUOC • P07/M2103/02285 12 Administración de red
En GNU/Linux puede significar tener que incluir los módulos adecuados para
el dispositivo (network interface card NIC) adecuado (en el kernel o como módu- Nota
los), esto significa compilar el kernel después de haber escogido con, por ejem- Cómo ver las interfaces de red
disponibles?
plo, make menuconfig el NIC adecuado, indicándole como interno o como
ifconfig -a
módulo (en este último caso se deberá compilar el módulo adecuado también). Este comando muestra todas
las interfaces/parámetros por
defecto de cada una.
Los dispositivos de red se pueden mirar en el directorio /dev que es donde exis-
te un archivo (especial, ya sea de bloque o de caracteres según su transferen-
cia), que representa a cada dispositivo hardware.[KD00, Dra99].
© FUOC • P07/M2103/02285 13 Administración de red
2. Conceptos en TCP/IP
• Nodo: se denomina nodo (host) a una máquina que se conecta a la red (en
un sentido amplio un nodo puede ser un ordenador, una impresora, una
torre (rack) de CD, etc.), es decir, un elemento activo y diferenciable en la
red que reclama o presta algún servicio y/o comparte información.
0100 0000 0111 0011 1010 1011 1111 1111 –en binario–) que se encuentra Nombre de la máquina:
more /etc/hostname
en el dispositivo físico (hardware) del controlador (NIC) de red Ethernet y
es grabado por el fabricante del mismo (este número debe ser único en el
mundo, por lo que cada fabricante de NIC tiene un rango preasignado).
• Host name: cada nodo debe tener además un único nombre en la red. Ellos
pueden ser sólo nombres o bien utilizar un esquema de nombres jerárquico Nota
basado en dominios (hierarchical domain naming scheme). Los nombres de Dirección IP de la máquina:
more /etc/hosts
los nodos deben ser únicos, lo cual resulta fácil en pequeñas redes, más
dificultoso en redes extensas e imposible en Internet si no se realiza al-
gún control. Los nombres deben ser de un máximo de 32 caracteres entre
a-zA-Z0-9.-, y que no contengan espacios o # comenzando por un carácter
alfabético.
do universalmente para identificar los ordenadores sobre una red o Inter- Puertos preasignados en UNIX:
more /etc/services
net. La traslación de nombres en direcciones IP es realizada por un servidor
Este comando muestra los
DNS (domain name system) que transforma los nombres de nodo (legibles puertos predefinidos por or-
den y según soporten TCP
por humanos) en direcciones IP (este servicio es realizado por una aplica- o UDP.
ción denominada named).
dentro de este nodo (por ejemplo, dos máquinas que se comuniquen por Visualización de la configura-
ción del routing:
telnet lo harán por el puerto 23, pero las dos mismas máquinas pueden te- netstat -r
ner una comunicación ftp por el puerto 21). Se pueden tener diferentes
© FUOC • P07/M2103/02285 14 Administración de red
• ARP, RARP: en algunas redes (como por ejemplo IEEE 802 LAN que es
el estándar para Ethernet), las direcciones IP son descubiertas automáti-
camente a través de dos protocolos miembros de Internet protocol suite:
address resolution protocol (ARP) y reverse address resolution protocol
(RARP). ARP utiliza mensajes (broadcast messages) para determinar la di-
rección Ethernet (especificación MAC de la capa 3 del modelo OSI) co-
rrespondiente a una dirección de red particular (IP). RARP utiliza
mensajes de tipo broadcast (mensaje que llega a todos los nodos) para
determinar la dirección de red asociada con una dirección hardware en
particular. RARP es especialmente importante en máquinas sin disco, en
las cuales la dirección de red generalmente no se conoce en el momento
del inicio (boot).
Existen algunas restricciones: 0 (por ejemplo, 0.0.0.0) en el campo de red está re-
servado para el routing por defecto y 127 (por ejemplo, 127.0.0.1) está reservado
para la autorreferencia (local loopback o local host), 0 en la parte de nodo se refiere
a esta red (por ejemplo, 192.168.0.0) y 255 está reservado para paquetes de envío
a todas las máquinas (broadcast) (por ejemplo, 198.162.255.255). En las diferentes
asignaciones se puede tener diferentes tipos de redes o direcciones:
La dirección de broadcast es especial, ya que cada nodo en una red escucha to-
dos los mensajes (además de su propia dirección). Esta dirección permite que
© FUOC • P07/M2103/02285 17 Administración de red
Para encaminar los mensajes entre los ordenadores de las tres redes, se necesi-
tarán tres gateways que tendrán cada uno dos interfaces de red para cambiar
entre Ethernet y FFDI. Éstas serán:
IP utiliza una tabla para hacer el routing de los paquetes entre las diferentes re-
des y en la cual existe un routing por defecto asociado a la red 0.0.0.0. Todas
las direcciones que coinciden con ésta, ya que ninguno de los 32 bits son ne-
cesarios, son enviadas por el gateway por defecto (default gateway) hacia la red
indicada. Sobre comprasGW, por ejemplo, la tabla podría ser:
Para instalar una máquina sobre una red existente, es necesario, por lo
tanto, disponer de la siguiente información obtenida del proveedor de
red o de su administrador: dirección IP del nodo, dirección de la red IP,
dirección de broadcast, dirección de máscara de red, dirección de router,
dirección del DNS.
Si se construye una red que nunca tendrá conexión a Internet, se pueden es-
coger las direcciones que se prefieran, pero es recomendable mantener un or-
den adecuado en función del tamaño de red que se desee tener y para evitar
problemas de administración dentro de dicha red. A continuación, se verá
cómo se define la red y el nodo para una red privada (hay que ser cuidadoso,
ya que si se tiene la máquina conectada a la red, se podría perjudicar a otro
usuario que tuviera asignada esta dirección): dirección de nodo
192.168.110.23, máscara de red 255.255.255.0, parte de red 192.168.110., par-
te de nodo .23, dirección de red 192.168.110.0, dirección de broadcast
192.168.110.255.
© FUOC • P07/M2103/02285 20 Administración de red
Una vez cargado el kernel de GNU/Linux, éste ejecuta el comando init que a su
vez lee el archivo de configuración /etc/inittab y comienza el proceso de ini-
cialización. Generalmente, el inittab tiene secuencias tales como: si::sysinit:
/etc/init.d/boot, que representa el nombre del archivo de comandos (script)
que controla las secuencias de inicialización. Generalmente este script llama a
otros scripts, entre los cuales se encuentra la inicialización de la red.
Ejemplo
Para modificar los parámetros de red de la interfaz eth0 se puede hacer (consultar
man interfaces en la sección 5 del manual de Unix incluido con el sistema opera-
tivo para más información del formato):
Supongamos que desea configurar sobre Debian una interfaz eth0 que tiene
una dirección IP fija 192.168.0.123. y con 192.168.0.1 como puerta de
enlace (gateway). Se debe editat /etc/network/interfaces de modo que incluya
una sección como:
gateway 192.168.0.1
dns-search remix.org
dns-nameservers 195.238.2.21 195.238.2.22
NETWORKING=yes
HOSTNAME=my-hostname Nombre del host definido por el cmd hostname
FORWARD_IPV4=true True para NAT firewall gateways y routers.
False para cualquier otro caso
GATEWAY="XXX.XXX.XXX.YYY" Puerta de salida a Internet
Para configuración por DHCP se debe quitar la línea de GATEWAY, ya que será
asignada por el servidor. Y en caso de incorporar NIS debe agregarse una línea
con el servidor de dominio: NISDOMAIN=NISProject1
/etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE=eth0
BOOTPROTO=static
BROADCAST=XXX.XXX.XXX.255
IPADDR=XXX.XXX.XXX.XXX
NETMASK=255.255.255.0
NETWORK=XXX.XXX.XXX.0
ONBOOT=yes Activará la red en el boot.
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
Para cambiar el nombre del host, se deben seguir estos tres pasos:
Supongamos que queremos configurar una tarjeta de red inalámbrica Intel Pro/Wire-
less 2200BG (muy común en una gran cantidad de portátiles -p. ej. Dell, HP...-). Nor-
malmente el software que controla las tarjetas se divide en dos partes: el módulo
software que se cargará en el kernel a través del comando modprobe y el firmware que
es el código que se cargará en la tarjeta y que nos da el fabricante (consultar la página
de Intel para este modelo). Como estamos hablando de módulos, es interesante utili-
zar el paquete de debian module-assistant que nos permite crear e instalar fácilmente
un módulo (otra opción sería instalar las fuentes y crear el módulo correspondiente).
El software (lo encontramos en la página del fabricante y lo denomina ipw2200) lo
compilaremos e instalaremos con el comando m-a del paquete module-assistant.
http://ipw2200.sourceforge.net/firmware.php
La líneas pre-up ejecuta el comando iwconfig antes de activar la interfaz. Esta configura-
ción se hace si se quiere utilizar un servicio en modo DHCP (asignación automática de
IP, se verá más adelante). Se debe utilizar en vez de dhcp la palabra static y además poner
las siguientes líneas por ejemplo (como en una tarjeta de cable):
address 192.168.1.132
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.1.1
A continuación se puede poner en marcha la red con ifup eth1 y nos dará información
sobre la conexión y nos indicará su estado y calidad de recepción. Para buscar (scan) las
redes WiFi disponibles (puntos de acceso) podemos utilizar iwlist scan, lo que nos
mostrará información de las redes disponibles, y si nos queremos conectar a una diferen-
te, se puede utilizar el comando iwconfig para cambiar de red o punto de acceso (Access
Point).
El siguiente paso es configurar el name resolver que convierte nombres tales como
pirulo.remix.com en 192.168.110.23. El archivo /etc/resolv.conf es el utilizado
para tal fin. Su formato es muy simple (una línea de texto por sentencia). Existen
tres palabras clave para tal fin: domain (dominio local), search (lista de dominios
alternativos) y name server (la dirección IP del domain name server).
Ejemplo de /etc/resolv.conf
domain remix.com
search remix.com piru.com
name server 192.168.110.1
name server 192.168.110.65
Esta lista de servidores de nombre a menudo dependen del entorno de red, que
puede cambiar dependiendo de dónde esté o se conecte la máquina. Los progra-
mas de conexión a líneas telefónicas (pppd) o obtención de direcciones IP auto-
© FUOC • P07/M2103/02285 25 Administración de red
http://packages.debian.org/unstable/net/resolvconf
Ejemplo de /etc/host.conf
order hosts,bind
multi on
La consulta es mucho más rápida, pero tiene la desventaja de que si el nodo cam-
bia, la dirección será incorrecta. En un sistema correctamente configurado, sólo
deberán aparecer el nodo local y una entrada para la interfaz loopback.
Ejemplo de /etc/hosts
Para el nombre de una máquina pueden utilizarse alias, que significa que esa má-
quina puede llamarse de diferentes maneras para la misma dirección IP. En refe-
rencia a la interfaz loopback, éste es un tipo especial de interfaz que permite
realizar a nodo conexiones consigo misma (por ejemplo, para verificar que el sub-
sistema de red funciona sin acceder a la red). Por defecto, la dirección IP 127.0.0.1
ha sido asignada específicamente al loopback (un comando telnet 127.0.0.1
conectará con la misma máquina). Su configuración es muy fácil (la efectúan ge-
neralmente los script de inicialización de red).
ifconfig lo 127.0.0.1
route add host 127.0.0.1 lo
© FUOC • P07/M2103/02285 26 Administración de red
Esto indica que cuando se realice la consulta al DNS, si no existe un registro Ejemplo de nsswitch.conf: ...
hosts: dns files
para esta consulta, retorne al programa que la hizo con un cero. Puede utili-
...
zarse el ‘!’ para negar la acción, por ejemplo: networks: files
Otro aspecto que hay que configurar es el routing. Si bien existe el tópico sobre
su dificultad, generalmente se necesitan unos requisitos de routing muy sim- Nota
ples. En un nodo con múltiples conexiones, el routing consiste en decidir dón- Consulta de tablas de routing:
route -n
de hay que enviar y qué se recibe. Un nodo simple (una sola conexión de red)
o también
también necesita routing, ya que todos los nodos disponen de un loopback y netstat -r
una conexión de red (por ejemplo, Ethernet, PPP, SLIP...). Como se explicó an-
teriormente, existe una tabla llamada routing table que contiene filas con di-
versos campos, pero con tres campos sumamente importantes: dirección de
destino, interfaz por donde saldrá el mensaje, y dirección IP, que efectuará el
siguiente paso en la red (gateway).
El comando route permite modificar esta tabla para realizar las tareas de
routing adecuadas. Cuando llega un mensaje, se mira su dirección desti-
no, se compara con las entradas en la tabla y se envía por la interfaz
cuya dirección coincide mejor con el destino del paquete. Si un gateway
es especificado, se envía a la interfaz adecuada.
© FUOC • P07/M2103/02285 27 Administración de red
Consideremos, por ejemplo, que nuestro nodo está en una red clase C con di-
rección 192.168.110.0 y tiene una dirección 192.168.110.23; y el router con
conexión a Internet es 192.168.110.3. La configuración será:
• Primero la interfaz:
• Más adelante, indicar que todos los datagramas para nodo con direcciones
192.168.0.* deben ser enviados al dispositivo de red:
El -net indica que es una ruta de red pero también puede utilizarse -host
192.168.110.3. Esta configuración permitirá conectarse a todos los nodos den-
tro del segmento de red (192.1), pero ¿qué pasará si se desea conectar con otro
nodo fuera de este segmento? Sería muy difícil tener todas las entradas ade-
cuadas para todas las máquinas a las cuales se quiere conectar. Para simplificar
esta tarea, existe el default route, que es utilizado cuando la dirección destino
no coincide en la tabla con ninguna de las entradas. Una posibilidad de con-
figuración sería:
ifconfig
eth0 Link encap:Ethernet HWaddr 08:00:46:7A:02:B0
inet addr:192.168.0.111 Bcast: 192.168.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
...
© FUOC • P07/M2103/02285 28 Administración de red
# 24 - private
smtp 25/tcp mail
...
...
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd
# fsp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.fspd
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
# exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd...
...
Ejemplo de /etc/protocols
El archivo /etc/networks tiene una función similar a /etc/hosts, pero con res-
pecto a las redes, indica nombres de red en relación con su dirección IP (el co-
mando route mostrará el nombre de la red y no su dirección en este caso).
Ejemplo de /etc/networks
loopnet 127.0.0.0
localnet 192.168.0.0
amprnet 44.0.0.0 ...
© FUOC • P07/M2103/02285 31 Administración de red
El archivo /etc/hosts.equiv permite el acceso a esta máquina sin tener que in-
troducir una clave de acceso (password). Se recomienda no utilizar este meca-
nismo y aconsejar a los usuarios no utilizar el equivalente desde la cuenta de
usuario a través del archivo .rhosts.
Ejemplo de access.conf
+:u1 u2 g1 .remix.com:ALL
Ejemplo
Los más utilizados son: ip_forward utilizado para el routing entre interfaces o
con IP Masquerading; ip_default_ttl, que es el tiempo de vida para un paquete
IP (64 milisegundos por defecto) ip_bootp_agent variable lógica (BOOLEAN)
que acepta paquetes (o no) con dirección origen del tipo 0.b.c.d y destino de
este nodo, broadcast o multicast.
ifconfig
cat /proc/pci
cat /proc/interrupts
dmesg | more
# Ejemplo de /etc/dhcpd.conf:
default-lease-time 1200;
max-lease-time 9200;
option domain-name “remix.com”;
deny unknown-clients;
deny bootp;
option broadcast-address 192.168.11.255;
option routers 192.168.11.254;
option domain-name-servers 192.168.11.1, 192.168.168.11.2;
subnet 192.168.11.0 netmask 255.255.255.0
{ not authoritative;
range 192.168.11.1 192.168.11.254
host marte {
hardware ethernet 00:00:95:C7:06:4C;
fixed address 192.168.11.146;
option host-name “marte”;
}
host saturno {
hardware ethernet 00:00:95:C7:06:44;
fixed address 192.168.11.147;
option host-name “saturno”;
}
}
© FUOC • P07/M2103/02285 35 Administración de red
6. IP aliasing
Consideremos que tenemos una red Ethernet que soporta dos diferentes su-
bredes IP simultáneamente y que nuestra máquina desea tener acceso directo
a ellas. Un ejemplo de configuración sería:
Un caso típico es que se desee configurar una única tarjeta Ethernet para que
sea la interfaz de distintas subredes IP. Por ejemplo, supongamos que se tiene
una máquina que se encuentra en una red LAN 192.168.0.x/24. Y se desea co-
nectar la máquina a Internet usando una dirección IP pública proporcionada
con DHCP usando su tarjeta Ethernet existente. Por ejemplo, se puede hacer
como en el ejemplo anterior o también editar el archivo /etc/network/interfaces
de modo que incluya una sección similar al siguiente:
7. IP Masquerade
Esto significa que algunos servicios no funcionan (por ejemplo, talk) y otros de-
ben ser configurados en modo PASV (pasivo) para que funcionen (por ejemplo,
FTP). Sin embargo, WWW, telnet o irc funcionan adecuadamente. El kernel debe
estar configurado con las siguientes opciones: Network firewalls, TCP/IP networ-
king, IP:forwarding/gatewaying, IP: masquerading. Normalmente, la configura-
ción más común es disponer de una máquina con una conexión SLIP o PPP y
tener otro dispositivo de red (por ejemplo, una tarjeta Ethernet) con una direc-
ción de red reservada. Como vimos, y de acuerdo a la RFC 1918, se pueden utilizar
como IP privadas los siguientes rangos de direcciones (IP/Mask): 10.0.0.0/
255.0.0.0, 172.16.0.0/255.240.0.0, 192.168.0.0/255.255.0.0. Los nodos que de-
ben ser ocultados (masqueraded) estarán dentro de esta segunda red. Cada una de
estas máquinas debería tener la dirección de la máquina que realiza el masquerade
como default gateway o router. Sobre dicha máquina podemos configurar:
El IP network address translation NAT es el reemplazo que deja obsoleto las pres-
taciones de GNU/Linux IP Másquerade y que aporta nuevas prestaciones al
servicio. Dentro de las mejoras introducidas en la pila de TCP/IP del núcleo
2.2 de GNU/Linux, una es que el NAT forma parte del kernel. Para utilizarlo, es
necesario que el kernel se compile con:
CONFIG_IP_ADVANCED_ROUTER, CONFIG_IP_MULTIPLE_TABLES y
CONFIG_IP_ROUTE_NAT.
Y si se necesita control exhaustivo de las reglas NAT (por ejemplo, para activar
el cortafuegos firewalling) debe estar también
CONFIG_IP_FIREWALL y CONFIG_IP_ROUTE_FWMARK.
Esto hará que un paquete de entrada destinado a ext-addr (la dirección visible
desde fuera de Internet) se transcribe su dirección destino a int-addr (la direc-
ción de su red interna por medio de su gateway/firewall). El paquete se encami-
na de acuerdo a la tabla local de route. Se pueden trasladar direcciones simples
o bloques. Por ejemplo:
Configurar una conexión dial-up sobre PPP en GNU/Linux es muy simple. PPP
(point to point protocol) que permite realizar IP-Links entre dos ordenadores con
un módem (considerar que debe ser un módem soportado por GNU/Linux, ya
que no todos, especialmente los internos o los conocidos como Winmodems,
se pueden configurar, puesto que muchos de ellos necesitan software adicio-
nal para establecer la comunicación). [Vas00, Law07, Sec00].
Además, necesitará los datos del ISP: identificación de conexión (login name),
clave (password) y número de teléfono. Direcciones de DNS serían aconseja-
bles, pero es opcional en las versiones actuales de pppd. Verificar además que
su módem está correctamente conectado. Con un módem externo se debe eje-
cutar echo > /dev/ttyS0 y mirar las luces del módem por si tienen actividad. En
caso contrario, intentar con ttyS1 por si el módem está conectado al 2.º puerto
serie. Con un módem interno, consultar el manual de hardware soportado
para ver si este módem puede ser reconocido por GNU/Linux, y en caso afir-
mativo, podría tener que reconfigurar el kernel para utilizarlo. También puede
utilizar cat /proc/pci por si se encuentra en el bus PCI. [PPP00]
La forma más fácil de configurar ahora el módem es a través del paquete kppp
(debe instalar los paquetes kdenetwork-ppp* y ppp*). Sobre una terminal, eje-
cútese /usr/bin/kppp. Sobre la ventana, complétense las opciones siguientes:
Una vez configurado PPP para que funcione por ejemplo con mi_isp, se debe
editar /etc/network/interfaces de modo que incluya una sección como la si-
guiente (los comandos ifup, ifdown utilizan los comandos pon y poff para
configurar interfaces PPP):
pon mi_isp
ifup eth0=hotplug
A menos que haya añadido una interfaz lógica llamada hotplug en /etc/network/
interfaces, este comando no hará nada. Para que este comando configure eth0,
añadir las siguientes líneas al /etc/network/interfaces:
mapping hotplug
script echo
Si sólo desea que eth0 se active en caliente y no otras interfaces, utilizar grep
en vez de echo como se muestra a continuación:
mapping hotplug
script grep
map eth0
Para asociar una tarjeta Wi-Fi con un punto de acceso, puede que necesite pro-
gramarla con una clave de cifrado WEP adecuada. Si está utilizando ifplugd
para controlar ifup como se explicó anteriormente, entonces evidentemente
no podrá configurar la clave de cifrado usando ifup, ya que éste sólo es llama-
© FUOC • P07/M2103/02285 42 Administración de red
Una VPN (virtual private network) es una red que utiliza como transporte
de datos Internet, pero impide que los datos puedan ser accedidos por
miembros externos a ella.
Esto significa tener una red con VPN nodos unidos a través de un túnel por
donde viaja el tráfico y donde nadie puede interactuar con él. Es utilizada
cuando se tienen usuarios remotos que acceden a una red corporativa para
mantener la seguridad y privacidad de los datos. Para configurar una VPN, se
pueden utilizar diversos métodos SSH (SSL), CIPE, IPSec, PPTP, que pueden
consultarse en la bibliografía (se recomienda consultar VPN PPP-SSH HOWTO,
por Scott Bronson, VPN-HOWTO de Matthew D. Wilson). [Bro01, Wil02].
Ejemplo simple
Después se debe copiar el archivo static.key en el otro peer sobre un canal se-
guro (por ejemplo, utilizando ssh o scp). El archivo de configuración del ser-
vidor openVPN_server por ejemplo:
dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key
remote myremote.mydomain
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret static.key
Para verificar la OpenVPN entre dos máquinas, deberéis cambiar las IP por las
reales y el dominio por el que tenga, y luego ejecutar del lado servidor
Para verificar que funciona, podríais hacer ping 10.8.0.2 desde el server y ping
10.8.0.1 desde el cliente. Para más información, consultar http://openvpn.net/
howto.html.
© FUOC • P07/M2103/02285 45 Administración de red
Para agregar compresión sobre el link, debe añadirse la siguiente línea a los dos
archivos de configuración:
comp-lzo
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
Para ejecutarse como daemon con los privilegios de user/group nobody, agre-
gar a los archivos de configuración:
user nobody
group nobody
daemon
© FUOC • P07/M2103/02285 46 Administración de red
/etc/init.d/networking restart
net.ipv4.icmp_echo_ignore_all = 1
• No responde paquetes ICMP como por ejemplo el comando ping que po-
dría significar un ataque DoS (denial-of-service).
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
© FUOC • P07/M2103/02285 47 Administración de red
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
• Permite rechazar un ataque DoS por paquetes SYNC, que consumiría todos
los recursos del sistema forzando a hacer un reboot de la máquina.
net.ipv4.conf.lo.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
• Útil para evitar ataques con CMP redirect acceptance (estos paquetes son utili-
zados cuando el routing no tiene una ruta adecuada) en todas las interfaces.
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.lo.log_martians = 1
net.ipv4.conf.eth0.log_martians = 1
net.ipv4.conf.default.log_martians = 1
Generará log sobre todos los spoofed packets, source routed packets y redirect
packets.
Para importar una clave pública de otro usuario, se puede usar gpg --im-
port filename, y para firmar una clave (significa indicarle al sistema que
se está de acuerdo en que la clave firmada es de quien dice ser), se puede
utilizar gpg --sign-key UID. Para verificar una clave, se puede utilizar
gpg --verify file/data y para encriptar/desencriptar gpg -sear UID
file g, gpg -d file, respectivamente. [Gnu]
# xinetd.conf
# Las opciones de configuración por defecto que se aplican a todos los
# servidores pueden modificarse para cada servicio
defaults
{
instances = 10
log_type = FILE /var/log/service.log
log_on_success = HOST PID
log_on_failure = HOST RECORD
}
# El nombre del servicio debe encontrarse en /etc/services para obtener
# el puerto correcto
# Si se trata de un servidor/puerto no estándar, usa "port = X"
© FUOC • P07/M2103/02285 50 Administración de red
service ftp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/proftpd
}
#service telnet
#{
# socket_type = stream
# protocol = tcp
# wait = no
# user = root
# no_access = 0.0.0.0
# only_from = 127.0.0.1
# banner_fail = /etc/telnet_fail
# server = /usr/sbin/in.telnetd
#}
service ssh
{
socket_type = stream
protocol = tcp
wait = no
user = root
port = 22
server = /usr/sbin/sshd
server_args = -i
}
service http
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/local/apache/bin/httpd
}
#service finger
#{
# socket_type = stream
# protocol = tcp
# wait = no
# user = root
# no_access = 0.0.0.0
# only_from = 127.0.0.1
# banner_fail = /etc/finger_fail
# server = /usr/sbin/in.fingerd
# server_args = -l
#}
# Fin de /etc/xinetd.conf
default {
instances = 20
log_type = SYSLOG
authpriv log_on_success = HOST
log_on_failure = HOST
only_from = 192.168.0.0/16
per_source = 3
enabled = imaps
}
© FUOC • P07/M2103/02285 51 Administración de red
service imapd {
socket_type = stream
wait = no
user = root
server = /usr/sbin/imapd
only_from = 0.0.0.0/0 #allows every client
no_access = 192.168.0.1
instances = 30
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 2
redirect = 192.168.1.1 993 #Permite redireccionar el tráfico del port 993
hacia el nodo 192.168.1.1
bind = 192.168.10.4
#Permite indicar a cual interfaz está asociado el servicio para evitar problemas de suplan-
tación de servicio.
}
auto lo
iface lo inet loopback
Actividades
Para visualizar los servicios que se están ejecutando, podemos utilizar /sbin/
chkconfig –list y para gestionarlos podemos utilizar system-config-services
en modo gráfico o ntsysv en la línea de comandos. Para habilitar servicios indivi-
duales, podemos utilizar chkconfig, por ejemplo el siguiente comando habilita el
servicio crond para los niveles 3 y 5: /sbin/chkconfig --level 35 crond on.
Independientemente de cómo se hayan puesto en marcha los servicios se puede
utilizar /sbin/service –status-all o individualmente /sbin/service crond status para
saber cómo está cada servicio. Y también gestionarlo (start, stop, status, reload,
restart), por ejemplo service crond stop para pararlo o service crond restart para
reiniciarlo.
bluetooth, hcid, hidd, sdpd, dund, pand: Bluetooth red inalámbrica es para
dispositivos portátiles (no es wifi,802.11). Por ejemplo, teclados, mouse, telé-
fonos, altavoces/auriculares, etc.
nfs, nfslock: son los daemon estándar para compartir sistemas de archivos a
través de la red en sistemas operativos estilo Unix/Linux/BSD.
sendmail: este servicio permite gestionar los mails (MTA) o dar soporte a ser-
vicios como IMAP o POP3.
P07/M2103/02286
© FUOC • P07/M2103/02286 2 Administración de servidores
© FUOC • P07/M2103/02286 Administración de servidores
Índex
Introducció ............................................................................................... 5
Actividades .............................................................................................. 49
Introducción
Ejemplo
options {
directory “/var/cache/bind”;
// query-source address * port 53;
// forwarders {
// 0.0.0.0;
//
© FUOC • P07/M2103/02286 8 Administración de servidores
};
auth-nxdomain no; # conform to RFC1035
};
// prime the server with knowledge of the root servers}
zone “.” {
type hint;
file “/etc/bind/db.root”; };
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
}
zone “localhost” {
type master;
file “/etc/bind/db.local”;
};
zone “127.in-addr.arpa” {
type master;
file “/etc/bind/db.127”;
};
zone “0.in-addr.arpa” {
type master;
file “/etc/bind/db.0”;
};
zone “255.in-addr.arpa” {
type master;
file “/etc/bind/db.255”;
};
// add entries for other zones below here
}
...
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;
; formerly C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
...
Este archivo describe los root name servers en el mundo. Estos servidores cam-
bian, por lo que se debe actualizar periódicamente el archivo. Las siguientes
secciones son las zone; las zones localhost y 127.in-addr.arpa, que se vincu-
lan a los ficheros al archivo etc/bind/db.local y /etc/bind/db.127, se refie-
ren a la resolución directa e inversa para la interfaz local. Las zones
siguientes son para las zonas de difusión (según RFC 1912) y al final se de-
berían agregar las propias. Por ejemplo, el archivo db.local podría ser (‘;’
significa ’comentario’):
© FUOC • P07/M2103/02286 9 Administración de servidores
Aquí se indica el arranque del servidor y los mensajes de errores (si los hay), los
cuales se deberán corregir y volver a empezar. Ahora se puede verificar la configu-
ración con comandos como nslookup (original, fácil pero obsoleto según algunos
autores), host o dig (recomendado). La salida de dig -x 127.0.0.1 será algo
como:
# dig -x 127.0.0.1
;; <<>> DiG 9.2.1 <<>> -x 127.0.0.1
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31245
© FUOC • P07/M2103/02286 10 Administración de servidores
Esta línea (si no existe se debe agregar) indica que quien necesite un nombre
de una máquina o una IP consulte primero en /etc/hosts y luego en DNS de
acuerdo a los dominios indicados en /etc/resolv.conf.
1.2. Forwarders
DNS posee una estructura en árbol y el origen es conocido como ‘.’ (ver
/etc/bind/db.root). Bajo el ‘.’ existen los TLD (top level domains) como org,
com, edu, net, etc. Cuando se busca en un servidor, si éste no conoce la res-
© FUOC • P07/M2103/02286 11 Administración de servidores
zone “remix.bogus” {
type master;
notify no;
file “/etc/bind/remix.bogus”;
};
Se debe recordar que en el named.conf los dominios van sin el ‘.’ final. En el
archivo remix.bogus se pondrán los hosts de los cuales seremos responsables:
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ NS ns ; Inet Address of name server
MX 10 mail.remix.bogus. ; Primary Mail Exchanger
localhost A 127.0.0.1
ns A 192.168.1.2
mail A 192.168.1.4
TXT “Mail Server”
ftp A 192.168.1.5
MX 10 mail
www CNAME ftp
El último paso es configurar la zona inversa, es decir, para que pueda convertir
direcciones IP en nombres, por ejemplo, agregando una nueva zona:
zone “192.168.1.in-addr.arpa” {
type master;
notify no;
file “/etc/bind/192.168.1”;
};
$TTL 604800
@ IN SOA ns.remix.bogus. root.remix.bogus. (
199802151 ; serial, todays date + todays serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
@ NS ns.remix.bogus.
2 PTR ns.remix.bogus
4 PTR mail.remix.bogus
5 PTR ftp.remix.bogus
Una vez creado un máster server, debe crearse un slave server por seguridad, que
es idéntico al máster, excepto que la zona en lugar de type master deberá tener
slave y la IP del master. Por ejemplo:
zone “remix.bogus” {
type slave;
notify no;
masters {192.168.1.2; }
};
© FUOC • P07/M2103/02286 14 Administración de servidores
2. NIS (YP)
– /etc/init.d/portmap start
– /etc/init.d/nis stop
y luego:
– /etc/init.d/nis start
• A partir de este momento, el cliente NIS estará funcionando (se puede con-
firmar con rpcinfo -u localhost ypbind, que mostrará las dos versio-
nes del protocolo activo) o se puede utilizar el comando ypcat mapname
(por ejemplo, ypcat passwd, que mostrará los usuarios NIS definidos en el
servidor) donde la relación mapnames a tablas de la base de datos NIS están
definidos en /var/yp/nicknames.
dan acceder a la información del servidor. En este caso, se debe orientar la con-
sulta del login a las bases de datos adecuadas haciendo:
passwd: compat
group: compat
shadow: compat ...
netgroup: nis
Ver man nsswitch.conf para la sintaxis de este archivo.
Si este archivo no existe, cread uno vacío con touch /etc/networks. Tam-
bién se puede hacer que sobre el servidor se ejecute el cliente ypbind; así, todos
los usuarios entran por NIS, como se indicó anteriormente, modificando el fi-
chero /etc/passwd donde todas las entradas normales antes de la línea +::::::
serán ignoradas por el NIS (sólo podrán acceder localmente), mientras que las
posteriores podrán acceder por el NIS desde cualquier cliente. [Miq01]
© FUOC • P07/M2103/02286 18 Administración de servidores
Considerad que a partir de este momento los comandos para cambiar el pas-
swd o información de los usuarios como passwd, chfn, adduser no son válidos.
En su lugar, se deberán utilizar comandos tales como yppasswd, ypchsh e
ypchfn. Si se cambian los usuarios o se modifican los archivos mencionados,
habrá que reconstruir las tablas de NIS ejecutando el comando make en el di-
rectorio /var/yp para actualizar las tablas.
Tener en cuenta que Libc5 no soporta shadow passwd, por lo cual no se debe
utilizar shadow con NIS si se tienen aplicaciones con Libc5. No habrá ningún
problema si se tiene Libc6 que acepta NIS con soporte shadow.
/usr/lib/yp/ypinit -m
y entrando los nombres de los slave servers. Esto reconstruirá los mapas, pero
no enviará los archivos a los slaves. Para ello, sobre el slave, ejecutar:
/etc/init.d/nis stop
/etc/init.d/nis start
y, por último:
/usr/lib/yp/ypinit -s nombre_master_server.
Con lo cual, se asegurará de que todos los cambios del master serán transferi-
dos al servidor NIS slave.
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
}
3.2.1. ssh
Por ejemplo:
3.2.2. sshd
El sshd es el servidor (daemon) para el ssh (se puede instalar si no lo están con
apt-get install ssh lo cual instala el servidor y el cliente). Juntos reem-
plazan al rlogin, telnet, rsh y proveen una comunicación segura y encriptada
en dos hosts inseguros en la red.
Este comando pedirá el password para el usuario-id sobre host, y una vez conec-
tado se habrá creado el túnel. Cada paquete que se envíe a la máquina local
sobre el puerto 1100 será enviado a la máquina remota localhost sobre el puer-
to 110, que es donde escucha el servicio POP3 (la opción -C comprime el trá-
fico por el túnel).
Hacer túneles sobre otros puertos es muy fácil. Por ejemplo, supongamos que
sólo tengamos acceso a un remote proxy server desde una máquina remota
(remote login) –no desde la máquina local–, se puede hacer un túnel para co-
nectar el navegador a través del túnel en la máquina local. Consideremos
que tenemos login sobre una maquina gateway, la cual puede acceder a
la máquina llamada proxy, que ejecuta el Squid proxy server sobre el
puerto 3128. Ejecutamos:
Un cliente ftp permite acceder a servidores FTP y hay una gran cantidad de
clientes disponibles. La utilización del ftp es sumamente simple, desde la línea
de comando, ejecutar:
otro, se debe ejecutar el comando ascii o binary. Comandos útiles del cliente
ftp son el ls (navegación en el directorio remoto), get nombre_del_fichero (pa-
ra descargar ficheros) o mget (que admite *), put nombre_del_fichero (para en-
viar ficheros al servidor) o mput (que admite *); en estos dos últimos se debe
tener permiso de escritura sobre el directorio del servidor. Se pueden ejecutar
comandos locales si antes del comando se inserta un ‘!’. Por ejemplo !cd /tmp
significará que los archivos que bajen a la máquina local se descargarán en
/tmp. Para poder ver el estado y el funcionamiento de la transferencia, el clien-
te puede imprimir marcas, o ticks, que se activan con los comandos hash y
tick. Existen otros comandos que se pueden consultar en la hoja del manual
(man ftp) o haciendo help dentro del cliente.
Contamos con numerosas alternativas para los clientes, por ejemplo en modo
texto: ncftp, lukemftp, lftp, cftp, yafc Yafc, o en modo gráfico: gFTP, WXftp,
LLNL XFTP, guiftp. [Bor00]
Es importante tener en cuenta que los usuarios que sólo estén habilitados para
utilizar el servicio ftp no dispongan de un shell a la entrada correspondiente
de dicho usuario en /etc/passwd para impedir que este usuario tenga co-
nexión, por ejemplo, por ssh o telnet. Para ello, cuando se cree el usuario, ha-
brá que indicar, por ejemplo:
Y luego:
passwd nteum
Lo cual indicará que el usuario nteum no tendrá shell para una conexión in-
teractiva (si el usuario ya existe, se puede editar el fichero /etc/passwd y cam-
biar el último campo por /bin/false). Luego se debe agregar como última
línea /bin/false en /ect/shells. En [Mou01] se describe paso a paso cómo crear
tanto un servidor ftp seguro con usuarios registrados como un servidor ftp
anonymous para usuarios no registrados. Dos de los servidores no estánda-
res más comunes son el WUFTPD (http://www.wuftpd.org) y el ProFTPD
(http://www.proftpd.org). [Bor00, Mou01]
Para instalar el Proftpd sobre Debian ejecutar: apt-get install proftpd. Des-
pués de descargado, debconf le preguntará si lo quiere ejecutar por inetd o en
modo manual (es recomendable elegir la última). Si se quiere parar el servicio (pa-
ra cambiar la configuración por ejemplo), /etc/init.d/proftpd stop, y para
modificar el fichero, /etc/proftpd.conf.
exim postmaster@SuDominio
From: user@dominio
To: postmaster@SuDominio
Subject: Test Exim
Mensaje de prueba
^D
© FUOC • P07/M2103/02286 29 Administración de servidores
La última versión de Exim es Exim4 (se puede instalar con apt-get install
exim4-daemon-heavy (y también instalar exim4-config que servirá para con-
figurar exim4) –tener en cuenta que hay diferentes paquetes con diferentes posi-
bilidades pero exim4-daemon-heavy es la más completa). Es recomendable leer /
usr/share/doc/exim/README.Debian.gz and update-exim4.conf(8). Para más
información se puede consultar el HowTo http://www.exim.org/docs.html.
Unas pequeñas diferencias a tener en cuenta en la configuración es que en lu-
gar de tener una única configuración exim.conf (que es lo que tendrá si se ins-
tala exim desde los fuentes) el paquete exim4-config (es conveniente
instalarlo para configurar exim4) utiliza pequeños archivos de configuración
en lugar de uno único y que estarán en /etc/exim4/conf.d/* y serán concate-
nados todos en un único archivo (/var/lib/exim4/config.autogenerated por
defecto) por update-exim4.conf.
Primero se debe instalar Exim + Imap y comprobar que funcionan. Se debe te-
ner en cuenta que si se instala courier-imap (que según algunos autores es me-
jor que uw-imapd) éste funciona sobre un formato de mail llamado Maildir,
que se debería configurar Exim para que también funcione sobre maildir con
© FUOC • P07/M2103/02286 31 Administración de servidores
Para recoger los mails de diferentes cuentas se utilizará fetchmail, (que se instala
con apt-get install fetchmail). Se debe a continuación crear el fichero
.fetchmailrc en nuestro $HOME (también se puede utilizar la herramienta fe-
tchmailconf) que deberá tener ser algo así como:
poll mail.domain2.com
user 'user5' there with password 'secret2' is 'pirulo' here
user 'user7' there with password 'secret3' is 'pirulo' here
La acción set indica a Fetchmail que esta línea contiene una opción global (en-
vío de errores, borrar los mail de los servidores...). A continuación, se especifican
dos servidores de correo: uno para que compruebe si hay correo con el protocolo
POP3 y otro para que pruebe a usar varios protocolos para encontrar uno que
funcione. Se comprueba el correo de dos usuarios con la segunda opción de ser-
vidor, pero todo el correo que se encuentre se envía al spool de correo del pirulo.
Esto permite comprobar varios buzones de diversos servidores como si se tratara
de un único buzón MUA. La información específica de cada usuario comien-
za con la acción user. EL fetchmail se puede poner en el cron (por ejemplo
en /var/spool/cron/crontabs/pirulo agregando 1 * * * * /usr/bin/fetchmail -s),
para que se ejecute automáticamente o ejecutarlos en modo daemon (poner set
daemon 60 en .fetchmailrc y ejecutarlo una vez por ejemplo en Autostart de
Gnome/KDE o en el .bashrc -se ejecutará cada 60 segundos).
VERBOSE=no
© FUOC • P07/M2103/02286 32 Administración de servidores
MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/
– Directorio para almacenar los ficheros
PMDIR=$HOME/.procmail
– Comentar si no queremos log de Procmail
LOGFILE=$PMDIR/log
– filtro de Smap
INCLUDERC=$PMDIR/spam.rc
:0:
* ^X-Spam-Status: Yes
spam-folder
Esto generará un tag X-Spam-Status: Yes en la cabecera del mensaje si cree que
el mensaje es Spam. Luego se deberán filtrar éstos y ponerlos en otra carpeta
o borrarlos directamente. Se puede utilizar el procmail para filtrar mails de
dominios, usuarios etc. Para más información consultar http://www.debian-
administration.org/articles/242. Por último se puede instalar un cliente
de correo y configurar los filtros para que seleccione todos los correos con
X-Spam-Status: Yes y los borre o los envíe a un directorio que luego verifica-
remos los falsos positivos (correos identificados como basura pero que no lo
son). Un aspecto complementario en esta instalación es si se desea tener un
servidor de correo a través de webmail (es decir, poder consultar los correos del
servidor a través de una navegador sin tener que instalar un cliente ni confi-
gurarlo –igual que consultar una cuenta de gmail o hotmail) es posible instalar
Squirrelmail (apt-get install squirrelmail) para dar este servicio. Para
Debian consultar http://www.debian-administration.org/articles/200.
5.3. News
Las news o grupos de discusión son soportados a través del protocolo NNTP. Ins-
talar un servidor de news es necesario cuando se desea leer news fuera de línea,
cuando se quiere tener un repetidor de los servidores centrales o se quiere un
propio servidor master de news. Los servidores más comunes son INN o CNEWS,
pero son paquetes complejos y destinados a grandes servidores. Leafnode es un
paquete USENET que implementa servidor TNP, especialmente indicado para
sitios con grupos reducidos de usuarios, pero donde se desea acceder a gran
cantidad de grupos de noticias. Este servidor se instala en la configuración bá-
sica de Debian y se puede reconfigurar con dpkg-reconfigure leafnode,
todos parámetros como los servidores centrales, el tipo de conexión, etc. Este
daemon se pone en marcha desde inetd en forma similar al imap (o con xi-
netd). Leafnode soporta filtros a través de expresiones regulares indicadas (del
tipo ^Newsgroups:. * [,] alt.flame$) en /etc/news/leafnode/filters, donde para
cada mensaje se compara la cabecera con la expresión regular y, si existe coin-
cidencia, el mensaje es rechazado.
El archivo por defecto que se lee de cada directorio es index.html. Una vez ins-
talados los paquetes apache y apache-common, Debian configura básicamente
el servidor y lo pone en marcha. Se puede comprobar que funciona abrien-
do un browser (por ejemplo, el Konqueror, y poniendo en la barra de URL
http://localhost, lo cual cargará la página /var/www/index.html).
Group www-data
ServerAdmin [email protected] Dirección de usuario que atenderá los erro-
res
a) Descarga de los ficheros necesarios (por ejemplo dentro del directorio /root ->
cd /root):
b) Utilidades: bzip2 libssl-dev openssl gcc g++ cpp make (verificar que no se tienen
instaladas o si no, hacer apt-get install bzip2 libssl-dev openssl gcc g++ cpp make.
c) Apache:
cd /root
tar jxvf httpd-2.2.4.tar.bz2
cd httpd-2.2.4
User www-data
Group www-data
Servidor apache instalado. Para iniciarlo (para pararlo cambiar start por stop):
/usr/local/apache2/bin/apachectl start
d) SSL:
Se generan los ficheros con las claves para el servidor seguro, en /root hacemos
(adecuar las versiones a las que se hayan descargado) –el primer comando
openssl es una línea entera y acaba con 1024:
Reiniciamos el servidor...
/usr/local/apache2/bin/apachectl restart
groupadd mysql
useradd -g mysql mysql
Iniciamos el servidor
/etc/rcS.d/S99mysql.server start
Dentro hacemos:
USE mysql
Utilidades necesarias:
apt-get install libxml2-dev curl libcurl3-dev libjpeg-mmx-dev zlib1g-dev \
libpng12-dev
Con prefix se puede indicar dónde se quiere instalar (todo en una línea):
./configure --prefix=/usr/local/php5 --enable-mbstring --with-apxs2=/
usr/local/apache2/bin/apxs --with-mysql=/usr/local/mysql --with-curl=/
usr/include/curl --with-jpeg-dir=/usr/include --with-zlib-dir=/usr/
include --with-gd --with-xml --enable-ftp --enable-bcmath
make
make install
cp php.ini-dist /usr/local/php5/lib/php.ini
Y también:
Reiniciamos el servidor.
g) PHPAdmin
cd /usr/local/apache2/
Quito el usuario y password del usuario por defecto dos (') seguidas:
$cfg['Servers'][$i]['controluser'] = '';
$cfg['Servers'][$i]['controlpass'] = '';
Squid es uno de los principales PS, ya que es OpenSource, acepta ICP (ca-
racterísticas que le permiten intercambiar hints con otros PS), SSL (para co-
nexiones seguras entre proxies) y soporta objetos FTP, Gopher, HTTP y
HTTPS (seguro). Su funcionamiento es simple, almacena los objetos más
solicitados en memoria RAM y los menos en una base de datos en el disco.
Los servidores Squid, además, pueden configurarse de forma jerárquica
para formar un árbol de proxies dependiendo de las necesidades. Existen
dos configuraciones posibles:
En el primer modo, actúa como proxy inverso, es decir, acepta una petición
del cliente, sirve el objeto si lo tiene y si no, lo solicita y se lo pasa al cliente
cuando lo tiene, almacenándolo para la vez siguiente. En la segunda opción
se puede utilizar como control y para restringir los sitios donde se puede co-
nectar en Internet o autorizar el acceso a determinadas horas del día. Una vez
instalado (paquete squid en Debian, también se puede instalar squid-cgi,
squidguard o squidtaild) se generan tres archivos: /etc/squid.conf (configura-
ción), /etc/init.d/squid (inicialización) y /etc/logrotate.d/squid (de control
de los logs).
hierarchy_stoplist cgi-bin \?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
cache_mem 100 MB Memoria para objetos en curso
redirect_rewrites_host_header off
cache_replacement_policy lru
memory_replacement_policy lru
cache_dir ufs /var/spool/squid 100 16 256 Tipo y lugar donde está la Base de Datos de ca-
ché de disco
emulate_httpd_log on
acl all src 0.0.0.0/0.0.0.0 Acceso para todos
http_access allow all Y a todo
cache_mgr root Mail responsable
cache_effective_user proxy UID
cache_effective_group proxy GID
httpd_accel_host 192.168.1.1 Servidor real de Web
httpd_accel_port 81 Puerto
logfile_rotate 0
log_icp_queries off
buffered_logs on
La gran diferencia con el otro modo son las líneas acl, en cuyo caso se permitirá
a los clientes de la clase C 192.168.1.0 acceder al PS, también el localhost IP y
otros puertos que podrán acceder a Internet 80(http), 443(https), 210(whais),
70(gopher), and 21(ftp), además, se niega el método connect para evitar que desde
fuera se puedan conectar al PS y luego se niegan todos los IP y puertos sobre
el PS. [Mou01] Más información en http://www.squid-cache.org/ y para un
transparent-proxy en http://tldp.org/HOWTO/TransparentProxy-1.html.
© FUOC • P07/M2103/02286 42 Administración de servidores
7. OpenLdap (Ldap)
dn: o = UOC, c = SP
o: UOC
objectclass: organization
dn: cn = Pirulo Nteum, o = UOC, c = SP
cn: Pirulo Nteum
sn: Nteum
mail: [email protected]
objectclass: person
Todos los datos son representados como un par atributo = valor donde atributo
es descriptivo de la información que contiene, por ejemplo, el atributo utili-
zado para almacenar el nombre de una persona es commonName, o cn, es de-
cir, para una persona llamada Pirulo Nteum, será representado por cn: Pirulo
Nteum y llevará asociado otros atributos de la clase persona como givenname:
Pirulo surname: Nteum mail: [email protected]. En las clases existen atributos
obligatorios y optativos y cada atributo tiene una sintaxis asociada que indica
qué tipo de información contiene el atributo, por ejemplo, bin (binary), ces
(case exact string, debe buscarse igual), cis (case ignore string, puede ignorarse M-
m durante la búsqueda), tel (telephone number string, se ignoran espacios y ‘-‘),
dn (distinguished name). Un ejemplo de un archivo en formato LDIF podría ser:
Las líneas largas pueden ser continuadas debajo comenzando por un espacio
o un tab (formato LDIF). En este caso, se ha definido la base DN para la insti-
tución dc = UOC, dc = com, la cual contiene dos subunidades: people y groups.
Luego se ha descrito un usuario que pertenece a people y a group. Una vez pre-
© FUOC • P07/M2103/02286 44 Administración de servidores
parado el archivo con los datos, debe ser importado al servidor para que esté
disponible para los clientes LDAP. Existen herramientas para transferir datos
de diferentes bases de datos a formato LDIF. [Mal07]
El sistema durante la instalación habrá creado los enlaces adecuados para eje-
cutarlo después del inicio.
Existen dos métodos para insertar datos en la base de datos de LDAP. El prime-
ro es fácil y adecuado para pequeñas cantidades de datos, es interactivo y se
deben utilizar herramientas tales como ldapadd (o cualquier otra como Ldap
Browser http://www.iit.edu/~gawojar/ldap/) para insertar nuevas entradas. El
segundo se debe trabajar fuera de línea, es el adecuado para grandes BD y se
utiliza el comando slapadd incluido con slapd. Por ser más general, describi-
remos sintéticamente el segundo método, donde primero se debe verificar que
contiene los siguientes atributos en slapd.conf: suffix (top del directorio, por
ejemplo, suffix “o = UOC, c = SP”); directory /var/lib/ldap (directorio donde se
crearán los índices y que pueda escribir slapd). Se debe además verificar que la
base de datos contiene las definiciones de los índices que se desean:
index cn,sn,uid
index objectClass pres,eq
© FUOC • P07/M2103/02286 45 Administración de servidores
Existen otros comandos con slapd tales como slapindex, que permite regenerar
los índices, y slapcat, que permite volcar la BD a un archivo en formato LDIF.
© FUOC • P07/M2103/02286 46 Administración de servidores
Esta sentencia indica que se montará el directorio /usr/local del host pirulo.re-
mix.com en el directorio local /pub. Los parámetros rsize, wzise son los tama-
ños de bloques de lectura y escritura, timeo es el timeout de RPC (si no se
especifican estos tres valores, se toman los que incluye por defecto).
# Ejemplo de /etc/exports
/ /master(rw) trusty(rw,no_root_squash)
/projects proj*.local.domain(rw)
/usr *.local.domain(ro) @trusted(rw)
/pub (ro,insecure,all_squash)
/home 195.12.32.2(rw,no_root_squash) www.first.com(ro)
/user 195.12.32.2/24(ro,insecure)
Un (o una) wiki (del hawaiano wiki wiki, “rápido”) es un sitio web colabo-
rativo que puede ser editado por varios usuarios que pueden crear, editar,
borrar o modificar el contenido de una página web, de una forma interac-
tiva, fácil y rápida; dichas facilidades hacen de una wiki una herramienta
efectiva para la escritura colaborativa. La tecnología wiki permite que páginas
web alojadas en un servidor público (las páginas wiki) sean escritas de forma co-
laborativa a través de un navegador, utilizando una notación sencilla para dar
formato, crear enlaces, etc, conservando un historial de cambios que permite re-
cuperar de manera sencilla cualquier estado anterior de la página. Cuando al-
guien edita una página wiki, sus cambios aparecen inmediatamente en la
web, sin pasar por ningún tipo de revisión previa.Wiki también se puede
referir a una colección de páginas hipertexto, que pueden ser visitadas y
editadas por cualquier persona (definición de Wikipedia). Debian tiene su
wiki en http://wiki.debian.org/ y FC en http://fedoraproject.org/wiki/ y
ambas están basadas en Moin Moin (http://moinmoin.wikiwikiweb.de/).
MoinMoin es una Python WikiClone que permite rápidamente inicializar su pro-
pia wikiy solo se necesita un servidor de web y el lenguaje Python instalado.
En http://moinmoin.wikiwikiweb.de/MoinMoinPackages/DebianLinux se
encuentran las instrucciones detalladas para instalar Moin Moin sobre De-
© FUOC • P07/M2103/02286 48 Administración de servidores
<Location /mywiki>
SetHandler python-program
PythonPath "['/var/www/mywiki','/etc/moin/']+sys.path"
PythonHandler MoinMoin.request::RequestModPy.run
PythonDebug On
</Location>
• Reiniciar apache2:
/etc/init.d/apache2 reload
cp /etc/moin/moinmaster.py /etc/moin/mywiki.py
Actividades
2) Configurar un servidor/cliente NIS con dos máquinas exportando los directorios de usua-
rio del servidor por NFS.
3) Configurar un servidor SSH para acceder desde otra máquina sin passwd.
4) Configurar un servidor Apache+ SSL+ PHP+ MySQL+ PHPAdmin para visualizar las hojas
personales de los usuarios.
http://tldp.org/HOWTO/DNS-HOWTO-7.html
http://tldp.org/HOWTO/NIS-HOWTO/verification.html
Proftpd: http://www.debian-administration.org/articles/228
PureFtpd: http://www.debian-administration.org/articles/383
Exim: http://www.exim.org/docs.html
Mutt: http://www.mutt.org
ProcMail: http://www.debian-administration.org/articles/242
LWP:http://www.lawebdelprogramador.com/temas/tema_stablephpapachemysql.php
http://moinmoin.wikiwikiweb.de/MoinMoinPackages/DebianLinux
P07/M2103/02287
© FUOC • P07/M2103/02287 2 Administración de datos
© FUOC • P07/M2103/02287 Administración de datos
Índex
Introducció ............................................................................................... 5
1. PostgreSQL .......................................................................................... 7
1.1. ¿Cómo se debe crear una DB? ........................................................ 7
1.2. ¿Cómo se puede acceder a una DB? ................................................ 8
1.3. El lenguaje SQL ............................................................................... 8
1.4. Instalación PostgreSQL ................................................................... 10
1.4.1. Postinstalación .................................................................... 11
1.4.2. Usuarios de DB .................................................................... 12
1.5. Mantenimiento ............................................................................... 14
1.6. Pgaccess ........................................................................................... 15
2. Mysql .................................................................................................... 17
2.1. Instalación ...................................................................................... 17
2.2. Postinstalación y verificación ......................................................... 18
2.3. El programa monitor (cliente) mysql ............................................. 19
2.4. Administración ............................................................................... 20
2.5. Interfaces gráficas ........................................................................... 21
4. Subversion ........................................................................................... 31
Actividades................................................................................................ 35
Introducció
Una base de datos es un conjunto estructurado de datos que pueden ser orga-
nizados de manera simple y eficiente por un manejador de dicha base. Las ba-
ses de datos actuales se denominan relacionales, ya que los datos pueden ser
almacenados en diferentes tablas que facilitan su gestión y administración.
Para ello y con el fin de estandarizar el acceso a las bases de datos se utiliza un
lenguaje denominado SQL (structured query language), que permite una interac-
ción flexible, rápida e independiente de las aplicaciones a las bases de datos.
El control de versiones se realiza para controlar las distintas versiones del có-
digo fuente. Sin embargo, los mismos conceptos son aplicables a otros ámbi-
tos y no sólo para código fuente sino para documentos, imágenes, etcétera.
Aunque un sistema de control de versiones puede realizarse de forma manual,
es muy aconsejable disponer de herramientas que faciliten esta gestión (CVS,
Subversion, SourceSafe, Clear Case, Darcs, Plastic SCM, RCS, etc.).
En este capítulo veremos CVS (control version system) y Subversion para contro-
lar y administrar múltiples revisiones de archivos, automatizando el almace-
namiento, lectura, identificación y mezclado de diferentes revisiones. Estos
programas son útiles cuando un texto es revisado frecuentemente e incluye
© FUOC • P07/M2103/02287 6 Administración de datos
1. PostgreSQL
• La aplicación del cliente (frontend) es la que solicita las operaciones que hay
que realizar en la DB y que pueden ser de lo más variadas; por ejemplo: he-
rramientas en modo texto, gráficas, servidores de web, etc.
createdb nteumdb
Por simplicidad utilizaremos psql para acceder a la DB, por lo que se deberá
introducir psql nteumdb: saldrán unos mensajes con la versión e informa-
ción y un prompt similar a nteumdb =>. Se pueden ejecutar algunos de los co-
mandos SQL siguientes:
SELECT version();
o también
psql también tienen comandos que no son SQL y comienzan por ‘\’ por ejem-
plo \h (lista todos los comandos disponibles) o \q para terminar.
Ejemplo
Acceder a la DB nteumdb:
psql nteumdb [enter]
nteumdb =>
Ejemplo
Ejemplos
• Unión de tablas:
• Funciones anidadas:
• Modificación selectiva:
gunzip postgresql-x.x.x.tar.gz
tar xf postgresql-7.3.tar
1.4.1. Postinstalación
LD_LIBRARY_PATH = /usr/local/pgsql/lib;
PATH = /usr/local/pgsql/bin:$PATH;
export LD_LIBRARY_PATH PATH;
o bien, en csh:
MANPATH = /usr/local/pgsql/man:$MANPATH;
export MANPATH
Una vez instalada la DB, se deberá crear un usuario que manejará las bases de
datos (es conveniente crear un usuario diferente del root para que no tenga co-
nexión con otros servicios de la máquina), por ejemplo, el usuario postgres
utilizando el comando useradd, por ejemplo.
crear el directorio primero y luego indicarle a la DB cuál es; como root, hay que
hacer, por ejemplo:
mkdir /usr/local/pgsql/data
chown postgres /usr/local/pgsql/data su postgres
initdb -D /usr/local/pgsql/data
postmaster -D /usr/local/pgsql/data
Las redirecciones se hacen para almacenar los errores del servidor. El paquete
también incluye un script (pg_ctl) para no tener que conocer toda la sintaxis
de postmaster para ejecutarlo:
Para abortar la ejecución del servidor, se puede hacer de diferentes formas, con
el pg-ctl, por ejemplo, o bien directamente con:
1.4.2. Usuarios de DB
Nota
• Creador de DB: tiene permiso para crear DB. Para crear un usuario de estas
características, utilizar el comando:
O para borrar:
Ejemplo
Cuando se crea una DB, los privilegios son para el usuario que la crea (y para
el superuser). Para permitir que otro usuario utilice esta DB o parte de ella, se le
deben conceder privilegios. Hay diferentes tipos de privilegios como SELECT,
INSERT, UPDATE, DELETE, RULE, REFERENCES, TRIGGER, CREATE, TEMPO-
RARY, EXECUTE, USAGE, y ALL PRIVILEGES (consultad las referencias para
ver su significado). Para asignar los privilegios, se puede utilizar:
donde usuario deberá ser un usuario válido de PostgerSQL y objeto, una tabla,
por ejemplo. Este comando lo deberá ejecutar el superusuario o el dueño de la
© FUOC • P07/M2103/02287 14 Administración de datos
tabla. El usuario PUBLIC puede ser utilizado como sinónimo de todos los usua-
rios y ALL, como sinónimo de todos los privilegios. Por ejemplo, para quitar
todos los privilegios a todos los usuarios de objeto, se puede ejecutar:
1.5. Mantenimiento
3) Cambio de archivos log: se debe evitar que los archivos de log sean de ta-
maño muy grande y difíciles de manejar. Se puede hacer fácilmente cuando se
inicia el servidor con:
Otra estrategia es salvar los archivos de las bases de datos a nivel del sistema
operativo, por ejemplo con:
Existen dos restricciones que pueden hacer este método poco práctico:
• Deben conocerse muy bien todas las implicaciones a nivel archivo don-
de están todas las tablas, transacciones y demás, ya que si no, una DB
puede quedar inútil. Además (generalmente), el tamaño que se salvará
será mayor que el efectuado con los métodos anteriores, ya que por
ejemplo, con el pg_dumb no se salvan los índices, sino el comando para
recrearlos.
./configure
gmake
su
gmake install
adduser postgres
mkdir /usr/local/pgsql/data
chown postgres /usr/local/pgsql/data
su - postgres
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data >logfile 2>&1 &
/usr/local/pgsql/bin/createdb test
/usr/local/pgsql/bin/psql test
1.6. Pgaccess
Figura 1. PgAccess
© FUOC • P07/M2103/02287 16 Administración de datos
2. Mysql
MySQL [Mys] es (según sus autores) la base de datos (DB) SQL abierta, es decir,
software libre (Open Source) más popular, y es desarrollada y distribuida por
MySQL AB (compañía comercial que obtiene sus beneficios de los servicios
que provee sobre la DB). MySQL es un DBMS (database management system).
Un DBMS es el que puede añadir y procesar los datos almacenados dentro de
la DB. Al igual que PostgreSQL, MySQL es una base de datos relacional, lo que
significa que almacena los datos en tablas en lugar de una única ubicación, lo
cual permite mayor velocidad y flexibilidad. Al ser software libre, cualquiera
puede obtener el código, estudiarlo y modificarlo de acuerdo a sus necesidades
sin pago alguno, ya que MySQL utiliza licencia GPL. MySQL provee en su pá-
gina web un conjunto de estadísticas y prestaciones en comparación con otras
DB para mostrar al usuario cuán rápida, fiable y fácil es de usar. La decisión de
elegir una DB se debe hacer cuidadosamente en función de las necesidades de
los usuarios y del entorno donde se utilizará esta DB.
2.1. Instalación
/etc/init.d/mysql start|stop
groupadd mysql
useradd -g mysql mysql
cd /usr/local
gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
ln -s full-path-to-mysql-VERSION-OS mysql
cd mysql
scripts/mysql_install_db --user=mysql
chown -R root .
chown -R mysql data
chgrp -R mysql .
bin/mysqld_safe --user=mysql &
© FUOC • P07/M2103/02287 18 Administración de datos
groupadd mysql
useradd -g mysql mysql
gunzip < mysql-VERSION.tar.gz | tar -xvf -
cd mysql-VERSION
./configure --prefix=/usr/local/mysql
make
make install
cp support-files/my-medium.cnf /etc/my.cnf
cd /usr/local/mysql
bin/mysql_install_db --user=mysql
chown -R root .
chown -R mysql var
chgrp -R mysql .
bin/mysqld_safe --user=mysql &
Una vez instalada (ya sea de los binarios o del código fuente), se deberá verifi-
car si el servidor funciona correctamente. En Debian se puede hacer directa-
mente:
./scripts/mysql_install_db
cd DirectorioInstalacionMysql
./bin/mysqld_safe --user = mysql &
cd DirectorioInstalacionMysql
./scripts/mysql_install_db
./bin/mysqld_safe user = mysql &
© FUOC • P07/M2103/02287 19 Administración de datos
de ejecutar mysql --help. Podremos realizar una conexión (local o remota) con Para más información, podéis
consultar la documentación,
el comando mysql, por ejemplo, para una conexión por la interfaz de red pero comandos y opciones.
desde la misma máquina: [Mys07]
http://dev.mysql.com/doc
/refman/5.0/es/
mysql -h localhost -u mysql -p NombreDB
Una vez dentro, el mysql pondrá un prompt (mysql>) y esperará a que le in-
troduzcamos algún comando (propio y SQL), por ejemplo help. A continua-
ción, daremos una serie de comandos para probar el servidor (recordar poner
siempre el ‘;’ para terminar el comando):
mysql> SELECT
-> USER()
-> ,
-> CURRENT_DATE;
O en múltiples líneas.
Cambia la DB.
Carga datos desde pet.txt en pet. El archivo pet.txt debe tener un registro por
línea separado por tabs de los datos de acuerdo a la definición de la tabla (fe-
cha en formato AAAA-MM-DD)
Muestra selectiva.
Muestra ordenada.
2.4. Administración
1) No dar a nadie (excepto al usuario root de mysql) acceso a la tabla user den-
tro de la DB mysql, ya que aquí se encuentran las contraseñas de los usuarios
que podrían ser utilizados con otros fines.
o también:
Asimismo, se pueden copiar los archivos *.frm’, *.MYD’, y *.MYI con el servi-
dor parado. Para recuperar, ejecutad:
lo cual funcionará en el 99% de las veces. En caso contrario, podría copiar los
archivos salvados y arrancar el servidor. Existen otros métodos alternativos en
función de lo que se quiera recuperar, como la posibilidad de salvar/recuperar
parte de la DB (consultar punto 4.4 de la documentación). [Mys]
2.5.Interfaces gráficas
Para Mysql hay gran cantidad de interfaces gráficas, entre las que destaca-
mos Mysql Administrator (se puede obtener desde http://www.mysql.com/
products/tools/administrator/). También pueden servir como herramientas
Mysql-Navigator (http://sourceforge.net/projects/mysqlnavigator/), o Webmin
con el módulo para trabajar con Mysql (paquetes webmin-core y webmin-mysql)
si bien este último ya no se incluye con algunas distribuciones. En forma
© FUOC • P07/M2103/02287 22 Administración de datos
análoga a PostgreSQL, webmin permite también trabajar con Mysql (es ne-
cesario instalar los paquetes webmin-mysql además del webmin-core). Du-
rante la instalación, el webmin dará un aviso de que el usuario principal
será el root y utilizará la misma contraseña que el root del sistema operati-
vo. Para conectarse, se podrá hacer, por ejemplo, desde un navegador:
https://localhost:10000, el cual solicitará aceptar (o denegar) la utilización
del certificado para la comunicación SSL y a continuación mostrará todos
los servicios que puede administrar, entre ellos Mysql Data Base Server.
• Se envían sólo las diferencias en ambas direcciones (en CVS siempre se en-
vían al servidor archivos completos).
Ya que CVS se basa en RCS y en algunos sistemas todavía se utiliza, se darán unas
breves explicaciones al respecto. El RCS está formado por un conjunto de progra-
mas para las diferentes actividades del RCS: rcs (programa que controla los atribu-
tos de los archivos bajo RCS), ci y co (verifican la entrada y la salida de los archivos
bajo el control de RCS), ident (busca en el RCS los archivos por palabras claves/
atributos), rcsclean (limpia archivos no utilizados o que no han cambiado), rcsdiff
(ejecuta el comando diff para comparar versiones), rcsmerge (une dos ramas (ar-
chivos) en un único archivo), y rlog (imprime los mensajes de log).
El formato de los archivos almacenados por RCS puede ser texto u otro formato,
como por ejemplo binario. Un archivo RCS consiste en un archivo de revisión
inicial llamado 1.1 y una serie de archivos de cambios, uno por cada revisión.
Cada vez que se realiza una copia del repositorio hacia el directorio de trabajo
con el comando co (obtiene una revisión de cada archivo RCS y lo pone en el
archivo de trabajo) o se utiliza ci (almacena nuevas revisiones en el RCS), el nú-
mero de versión se incrementa (por ejemplo, 1.2, 1.3,...). Los archivos (general-
mente) están en el directorio /RCS y es necesario que el sistema operativo tenga
instalados los comandos diff y diff3 para que funcione adecuadamente. En De-
bian no es necesario compilarlo ya que se incluye en la distribución.
Se puede utilizar el * y siempre tener una copia de resguardo para evitar proble-
mas. Esto creará las versiones de los archivos con nombre ./RCS/
nombre_archivo y solicitará un texto para describir el archivo. Luego, con
co RCS/nombre_archivo, obtendremos una copia de trabajo desde el reposi-
torio. Se puede bloquear o desbloquear este archivo para evitar modificacio-
nes, respectivamente, con:
rcs -L nombre_archivo_de_trabajo
rcs -U nombre_archivo_de_trabajo
En primer lugar se debe instalar el concurrent versions system (CVS) desde la dis-
tribución teniendo en cuenta que debemos tener instalado RCS y que debere-
mos instalar también OpenSSH si se le quiere utilizar conjuntamente con CVS
para acceso remoto. Las variables de entorno EDITOR CVSROOT deben estar
inicializadas por ejemplo en /etc/profile (o en .bash profile):
usermod -G cvs,nteum
Ahora el usuario nteum deberá introducir sus archivos en el directorio del re-
positorio (/usr/local/cvsroot en nuestro caso) hacer:
rm -r dir_org
Borra los originales (realizar una copia de resguardo siempre
por seguridad y para tener una referencia de dónde se inició
el trabajo con el CVS).
Figura 3
© FUOC • P07/M2103/02287 27 Administración de datos
El hecho de borrar los originales no es siempre una buena idea; sólo en este
caso, después de que se haya verificado que están en repositorio, para que por
descuido no se trabaje sobre ellos y los cambios no queden reflejados sobre el
CVS. Sobre máquinas donde los usuarios quieren acceder (por ssh) a un servi-
dor CVS remoto, se deberá hacer:
El comando inicial cvs checkout crea su copia privada del código fuente
para luego trabajar con ella sin interferir en el trabajo de otros usuarios (como
mínimo se crea un subdirectorio donde estarán los archivos).
• cvs update se debe ejecutar del árbol privado cuando hay que actualizar
sus copias de archivos fuentes con los cambios que otros programadores
han hecho sobre los archivos del repositorio.
• cvs add file... es un comando necesario cuando hay que agregar nue-
vos archivos en su directorio de trabajo sobre un módulo donde ya se ha
hecho un checkout previamente. Estos archivos serán enviados al reposi-
torio CVS cuando se ejecute el comando cvs commit.
• cvs remove file... este comando se utilizará para borrar archivos del
repositorio (una vez que se hayan borrado éstos del archivo privado). Este
comando debe ir acompañado de un cvs commit para que los cambios sean
efectivos, ya que se trata del comando que transforma todas las peticiones
de los usuarios sobre el repositorio.
• cvs diff file... se puede utilizar sin que afecte a ninguno de los ar-
chivos implicados si se necesita verificar las diferencias entre repositorio y
directorio de trabajo o entre dos versiones.
Una característica interesante del CVS es poder aislar cambios de los archivos
aislados en una línea de trabajo separada llamada ramificación (branch). Cuan-
do se cambia un archivo sobre una rama, estos cambios no aparecen sobre los
© FUOC • P07/M2103/02287 28 Administración de datos
archivos principales o sobre otras ramas. Más tarde, estos cambios se pueden
incorporar a otras ramas o al archivo principal (merging). Para crear una nueva
rama, utilizar cvs tag -b rel-1-0-patches dentro del directorio de traba-
jo, lo cual asignará a la rama el nombre de rel-1-0-patches. La unión de ramas
con el directorio de trabajo significa utilizar el comando cvs update -j.
Consultar las referencias para mezclar o acceder a diferentes ramas.
En primer lugar, se debe obtener una copia de los archivos del repositorio a
nuestra copia privada con:
que creará un nuevo directorio llamado gccrep con los archivos fuente. Si se
ejecuta cd gccrep y ls, se verá por ejemplo CVS makefile a.c b.c c.c, donde
existe un directorio CVS que se crea para el control de la copia privada que
normalmente no es necesario tocar.
Cuando se decide que se tiene una versión nueva con todos los cambios intro-
ducidos en a.c (o en los archivos que sea necesario), es momento de hacer una
nueva versión almacenando a.c (o todos los que se han tocado) en el reposi-
torio y hacer esta versión disponible al resto de usuarios: cvs commit a.c.
4. Subversion
Figura 5. gCVS
mkdir -p /usr/local/svn
addgroup svgroup
chown -R root.svgroup /usr/local/svn
chmod 2775 /usr/local/svn
© FUOC • P07/M2103/02287 32 Administración de datos
mkdir $HOME/svm-work
cd $HOME/svn-work
svn checkout file:///home/svuser/svndir/pruebas
cd /home/kikov/svn-work/pruebas
echo Segundo Archivo Svn `date` > file2.txt
svn add file2.txt
svn commit -m"Nuevo archivo"
Este comando nos marcará cuáles son las diferencias entre el archivo local
y los del repositorio. Si lo cargamos con svn commit -m"Nueva línea2"
(que generará otra versión) luego el svn diff no nos dará diferencias.
creamos el repositorio
ls -s /subversion
-rw-r--r-- 1 www-data www-data 376 May 11 20:27 README.txt
drwxr-xr-x 2 www-data www-data 4096 May 11 20:27 conf
drwxr-xr-x 2 www-data www-data 4096 May 11 20:27 dav
© FUOC • P07/M2103/02287 34 Administración de datos
Actividades
1) Definir en PostgreSQL una DB que tenga al menos 3 tablas con 5 columnas (de las cuales
3 deben ser numéricas) en cada tabla.
Generar un listado ordenado por cada tabla/columna. Generar un listado ordenado por
el mayor valor de la columna X de todas las tablas. Cambiar el valor numérico de la co-
lumna Y con el valor numérico de la columna Z + valor de la columna W/2.
3) Configurar el CVS para hacer tres revisiones de un directorio donde hay 4 archivos .c y
un makefile. Hacer una ramificación (branch) de un archivo y luego mezclarlo con el princi-
pal.
5) El mismo ejercicio anterior, pero uno de los usuarios debe conectarse desde otra máquina
al repositorio.
6) Ídem 3, 4 y 5 en Subversion.
PgAccess: http://www.pgaccess.org/
WebMin: http://www.webmin.com/
Mysql Administrator
http://www.mysql.com/products/tools/administrator/
O en la wiki de CVS:
http://ximbiot.com/cvs/wiki/index.php?title=CVS_Clients
Subversion: http://subversion.tigris.org
P07/M2103/02288
© FUOC • P07/M2103/02288 2 Administración de seguridad
© FUOC • P07/M2103/02288 Administración de seguridad
Índex
Introducció ............................................................................................... 5
4. SELinux ................................................................................................ 29
4.1. Arquitectura .................................................................................... 32
4.2. Crítica ............................................................................................. 35
Actividades .............................................................................................. 59
Introducció
El salto tecnológico de los sistemas de escritorio aislados, hasta los sistemas ac-
tuales integrados en redes locales e Internet, ha traído una nueva dificultad a las
tareas habituales del administrador: el control de la seguridad de los sistemas.
Los ataques pueden provenir de muchas fuentes y afectar desde a una aplicación
o servicio hasta a algún usuario, o a todos, o al sistema informático entero.
Una idea clara que hay que tener en mente es que es imposible poder
conseguir una seguridad al 100%.
Las técnicas de seguridad son un arma de doble filo, que fácilmente pueden
darnos una falsa impresión de control del problema. La seguridad actual es un
problema amplio, complejo, y lo que es más importante, dinámico. Nunca po-
demos esperar o decir que la seguridad está garantizada, sino que con bastante
probabilidad será una de las áreas a la cual el administrador tendrá que dedicar
más tiempo y mantener actualizados sus conocimientos sobre el tema.
En esta unidad examinaremos algunos tipos de ataques con los que podemos
encontrarnos, cómo podemos verificar y prevenir partes de la seguridad local,
y también en entornos de red. Asimismo, examinaremos técnicas de detección
de intrusos y algunas herramientas básicas que nos pueden ayudar en el con-
trol de la seguridad.
También es preciso mencionar que en esta unidad sólo podemos hacer una
mera introducción a algunos de los aspectos que intervienen en la seguridad
de hoy en día. Para cualquier aprendizaje real con más detalle, se recomienda
consultar la bibliografía disponible, así como los manuales asociados a los pro-
ductos o herramientas comentados.
© FUOC • P07/M2103/02288 6 Administración de seguridad
© FUOC • P07/M2103/02288 7 Administración de seguridad
Con respecto a los intrusos, hay que establecer algunas diferencias, que no
suelen estar muy claras en los términos coloquiales. Normalmente nos referi-
mos a hacker [Him01], como aquella persona con grandes conocimientos en
informática, más o menos apasionada por los temas de programación y segu-
ridad informática, y que, normalmente sin finalidad malévola, utiliza sus co-
nocimientos para protegerse a sí mismo, o a terceros, introducirse en redes
para demostrar sus fallos de seguridad, y, en algunos casos, como reconoci-
miento de sus habilidades.
Un ejemplo sería la propia comunidad GNU/Linux, que debe mucho a sus hac-
kers, ya que hay que entender el término hacker como experto en unos temas
(más que como intruso en la seguridad).
Por otro lado encontraríamos a los crackers. Aquí es cuando se utiliza el térmi-
no de manera más o menos despectiva, hacia aquellos que utilizan sus habili-
dades para corromper (o destrozar) sistemas, ya sea sólo por fama propia, por
motivos económicos, por ganas de causar daño o simplemente por molestar;
por motivos de espionaje tecnológico, actos de ciberterrorismo, etc. Asimis-
mo, se habla de hacking o cracking, cuando nos referimos a técnicas de estudio,
detección y protección de la seguridad, o por el contrario, a técnicas destina-
das a causar daño rompiendo la seguridad de los sistemas.
© FUOC • P07/M2103/02288 8 Administración de seguridad
Los posibles ataques son una amenaza constante a nuestros sistemas y pueden
Nota
comprometer su funcionamiento, así como los datos que manejamos; ante
Las amenazas afectan a la con-
todo lo cual, siempre tenemos que definir una cierta política de requisitos de fidencialidad, integridad o ac-
cesibilidad de nuestros
seguridad sobre nuestros sistemas y datos. Las amenazas que podemos sufrir sistemas.
podrían afectar a los aspectos siguientes:
• Integridad: la información sólo podrá ser modificada por aquellos que es-
tén autorizados: ¿qué se podrá hacer con ella?
Los métodos utilizados y las técnicas precisas pueden variar mucho (es más,
cada día se crean novedades), y nos obligan, como administradores, a estar en
contacto permanente con el campo de la seguridad para conocer a qué nos po-
demos enfrentar diariamente.
Respecto a dónde se produzca el ataque, hemos de tener claro qué puede ha-
Nota
cerse o cuál será el objetivo de los métodos:
Los ataques pueden tener fina-
lidades destructivas, inhabilita-
• Hardware: a este respecto, la amenaza está directamente sobre la accesibi- doras o de espionaje, de
nuestros componentes, ya sea
lidad, ¿qué podrá hacer alguien que tenga acceso al hardware? En este caso hardware, software o sistemas
de comunicación.
normalmente necesitaremos medidas “físicas”, como controles de seguri-
dad para acceder a los locales donde estén las máquinas para evitar proble-
mas de robo o rotura del equipo con el fin de eliminar su servicio. También
puede comprometerse la confidencialidad y la integridad si el acceso físico
a las máquinas permite utilizar algunos de sus dispositivos como las dis-
queteras, o el arranque de las máquinas, o el acceso a cuentas de usuario
que podrían estar abiertas.
• Canal de comunicación (en la red, por ejemplo): para los métodos que
afecten a la accesibilidad, nos puede provocar destrucción o eliminación de
mensajes, e impedir el acceso a la red. En confidencialidad, lectura y obser-
vación del tráfico de mensajes, desde o hacia la máquina. Y respecto a la
integridad, cualquier modificación, retardo, reordenación, duplicación o
falsificación de los mensajes entrantes y/o salientes.
Los sistemas GNU/Linux están protegidos casi totalmente contra estos me-
canismos por varias razones: en los programas ejecutables, tienen un acce-
so muy limitado al sistema, en particular a la cuenta del usuario. Con
excepción del usuario root, con el que hay que tener mucho cuidado con
lo que ejecuta. El correo no suele utilizar lenguajes de macros no verifica-
dos (como en el caso de Outlook y Visual Basic Script en Windows, que es
un agujero de entrada de virus), y en el caso de los documentos, estamos
en condiciones parecidas, ya que no soportan lenguajes de macros no ve-
rificados (como el VBA en Microsoft Office).
En todo caso, habrá que prestar atención a lo que pueda pasar en un futuro,
ya que podrían surgir algunos virus específicos para GNU/Linux aprove-
chando algunos bugs o exploits. Un punto que sí que hay que tener en cuen-
ta es el de los sistemas de correo, ya que si bien nosotros no generaremos
virus, sí que podemos llegar a transmitirlos; por ejemplo, si nuestro sistema
funciona como router de correo, podrían llegar mensajes con virus que po-
drían ser enviados a otros. Aquí se puede implementar alguna política de
detección y filtrado de virus. Otra forma de azote de plagas que podría en-
trar dentro de la categoría de virus son los mensajes de spam, que si bien
no suelen ser utilizados como elementos atacantes, sí que podemos consi-
derarlos como problemas por su “virulencia” de aparición, y el coste eco-
nómico que pueden causar (pérdidas de tiempo y recursos).
• Scanner (escaneo de puertos): más que un ataque, sería un paso previo, que
consistiría en la recolección de posibles objetivos. Básicamente, consiste en
utilizar herramientas que permitan examinar la red en busca de máquinas
con puertos abiertos, sean TCP, UDP u otros protocolos, los cuales indican
la presencia de algunos servicios. Por ejemplo, escanear máquinas buscan-
do el puerto 80 TCP, indica la presencia de servidores web, de los cuales po-
demos obtener información sobre el servidor y la versión que utilizan para
aprovecharnos de vulnerabilidades conocidas.
• Denial of Service (‘ataque DoS’): este tipo de ataque provoca que la máqui-
na caiga o que se sobrecarguen uno o más servicios, de manera que no sean
utilizables. Otra técnica es la DDoS (Distributed DoS), que se basa en utili-
zar un conjunto de máquinas distribuidas para que produzcan el ataque o
sobrecarga de servicio. Este tipo de ataques se suelen solucionar con actua-
lizaciones del software, ya que normalmente se ven afectados aquellos ser-
vicios que no fueron pensados para una carga de trabajo determinada y no
se controla la saturación. Los ataques DoS y DDoS son bastante utilizados
en ataques a sitios web, o servidores DNS, que se ven afectados por vulne-
rabilidades de los servidores, por ejemplo, de versiones concretas de Apa-
che o BIND. Otro aspecto que cabe tener en cuenta es que nuestro sistema
también podría ser usado para ataques de tipo DDoS, mediante control, ya
sea de un backdoor o un troyano.
por ejemplo php o perl) son utilizados directamente para construir las consul-
tas (en SQL), que atacarán una determinada base de datos (a la que en princi-
pio no se tiene acceso directo). Normalmente, si existen las vulnerabilidades y
poco control de los formularios, se puede inyectar código SQL en el formula-
rio, de manera que se construyan consultas SQL que proporcionen la informa-
ción buscada. En casos drásticos podría obtenerse la información de seguridad
(usuarios y contraseñas de la base de datos), o incluso tablas o la base de datos
entera, cuando no podrían producirse pérdidas de información, o borrados in-
tencionados de datos. En particular esta técnica en ambientes web puede ser
grave, debido a las leyes que protegen la privacidad de datos personales que un
ataque de este tipo puede provocar. En este caso, más que una cuestión de se-
guridad de sistema, supone un problema de programación y control con tipa-
do fuerte de los datos esperados en la aplicación, además del adecuado control
de conocimiento de vulnerabilidades presentes del software usado (base de da-
tos, servidor web, API como php, perl...).
• Controlar un factor problemático: los usuarios. Uno de los factores que puede
afectar más a la seguridad es la confidencialidad de las contraseñas, y ésta se
ve afectada por el comportamiento de los usuarios; esto facilita a posibles ata-
© FUOC • P07/M2103/02288 16 Administración de seguridad
cantes las acciones desde dentro del propio sistema. La mayoría de los ataques
suelen venir de dentro del sistema, o sea, una vez el atacante ha ganado acceso
al sistema.
• Entre los usuarios, está aquel que es un poco olvidadizo (o indiscreto), que
bien olvida la contraseña cada dos por tres, la menciona en conversaciones, la
escribe en un papel que olvida, o que está junto (o pegado) al ordenador o so-
bre la mesa de trabajo, o que simplemente la presta a otros usuarios o co-
nocidos. Otro tipo es el que coloca contraseñas muy predecibles, ya sea su
mismo id de usuario, su nombre, su DNI, el nombre de su novia, el de su
madre, el de su perro, etc., cosas que con un mínimo de información pue-
den encontrarse fácilmente. Otro caso son los usuarios normales con un
cierto conocimiento, que colocan contraseñas válidas, pero siempre hay
que tener en cuenta que hay mecanismos que pueden encontrarlas (crac-
king de passwords, sniffing, spoofing...). Hay que establecer una cierta “cultu-
ra” de seguridad entre los usuarios, y mediante técnicas obligarles a que
cambien las contraseñas, no utilicen palabras típicas, las contraseñas de-
ben ser largas (tener más de 2 o 3 caracteres), etc. Últimamente, en muchas
empresas e instituciones se está implantando la técnica de hacer firmar un
contrato al usuario de manera que se le obliga a no divulgar la contraseña
o cometer actos de vandalismo o ataques desde su cuenta (claro que esto
no impide que otros lo hagan por él).
Estas medidas pueden ser poco productivas, pero si no hemos asegurado el sis-
tema, no podemos tener ningún control sobre lo que puede pasar, y aun así,
© FUOC • P07/M2103/02288 17 Administración de seguridad
nadie asegura que no se pueda colar algún programa malicioso que burle la se-
guridad si lo ejecutamos con los permisos adecuados. O sea, que en general he-
mos de tener mucho cuidado con todo este tipo de actividades que supongan
accesos y ejecución de tareas de formas más o menos privilegiadas.
1.2. Contramedidas
Respecto a las medidas que se pueden tomar sobre los tipos de ataques presen-
tados, podemos encontrar algunas preventivas, y de detección de lo que suce-
de en nuestros sistemas.
Veamos algunos tipos de medidas que podríamos tomar en los ámbitos de pre-
vención y detección de intrusos (se mencionan herramientas útiles, algunas
las examinaremos más adelante):
Aunque la contraseña esté bien elegida, ésta puede ser insegura si se utiliza
en servicios no seguros. Por lo tanto, se recomienda reforzar los servicios
mediante técnicas de encriptación que protejan las contraseñas y los men-
sajes. Y por el contrario, evitar (o no utilizar) todos aquellos servicios que
no soporten encriptación, y consecuentemente, susceptibles de ser ataca-
dos con métodos, por ejemplo de sniffers; entre éstos podríamos incluir ser-
vicios telnet, ftp, rsh, rlogin (entre otros).
• Backdoor (o trap door, puerta trasera): hay que obtener de los proveedores
o vendedores del software la certificación de que éste no contiene ningún
tipo de backdoor escondido no documentado, y por supuesto aceptar el
software proveniente sólo de sitios que ofrezcan garantías. Cuando el soft-
ware sea de terceros, o de fuentes que podrían haber modificado el software
original, muchos fabricantes (o distribuidores) integran algún tipo de veri-
ficación de software basado en códigos de suma o firmas digitales (tipo
md5 o gpg) [Hatd]. Siempre que éstas estén disponibles, sería útil verificar-
las antes de proceder a la instalación del software. También puede probarse
el sistema intensivamente, antes de colocarlo como sistema de producción.
• Bombas lógicas: en este caso suelen ocultarse tras activaciones por tiempo
o por acciones del usuario. Podemos verificar que no existan en el sistema
trabajos no interactivos introducidos de tipo crontab, at, y otros procesos
(por ejemplo, de tipo nohup), que dispongan de ejecución periódica, o es-
tén en ejecución en segundo plano desde hace mucho tiempo (comandos
w, jobs). En todo caso, podrían utilizarse medidas preventivas que impidie-
ran trabajos no interactivos a los usuarios, o que solamente los permitiesen
a aquellos que lo necesitasen.
© FUOC • P07/M2103/02288 19 Administración de seguridad
• Escáner (escaneo de puertos): los escaners suelen lanzar sobre uno o más
Nota
sistemas bucles de escaneo de puertos conocidos para detectar los que que-
La herramienta chrootkit pue-
dan abiertos y aquellos servicios que están funcionando (y obtener infor- de encontrarse en: http://
www.chrootkit.org
mación de las versiones de los servicios) y que podrían ser susceptibles de
ataques.
• Buffer overflows: suelen ser comunes como bugs o agujeros del sistema, suelen
solucionarse por actualización del software. En todo caso, pueden observarse
por logs situaciones extrañas de caída de servicios que deberían estar funcio-
nando. También pueden maximizarse los controles de procesos y accesos a re-
cursos para aislar el problema cuando se produzca en entornos de acceso
controlado, como el que ofrece SELinux ver más adelante en el módulo.
• Denial of Service (‘ataque DoS’), y otros como SYN flood, o correos bom-
bing tomar medidas de bloqueo de tráfico innecesario en nuestra red (por
ejemplo, por medio de firewalls). En aquellos servicios que se pueda, habrá
que controlar tamaños de buffer, número de clientes por atender, timeouts
de cierre de conexiones, capacidades del servicio, etc.
Para la prevención local, hay que examinar los diferentes mecanismos de au-
tentificación y permisos de accesos a los recursos para definirlos correctamente
y poder garantizar la confidencialidad y la integridad de nuestra información.
En este caso, nos estaremos protegiendo de atacantes que hayan obtenido ac-
ceso a nuestro sistema, o bien de usuarios hostiles que quieran saltarse las
restricciones impuestas en el sistema.
Respecto a la seguridad en red, tenemos que garantizar que los recursos que
ofrecemos (si proporcionamos unos determinados servicios) tienen los pará-
metros de confidencialidad necesarios y que los servicios no pueden ser usa-
dos por terceros no deseados, de modo que, un primer paso será controlar que
los servicios ofrecidos sean los que realmente queremos, y que no estamos
ofreciendo además otros servicios que no tenemos controlados. En el caso de
servicios de los que nosotros somos clientes, también habrá que asegurar los
mecanismos de autentificación, en el sentido de que accedemos a los servido-
res correctos y no existen casos de suplantación de servicios o servidores (nor-
malmente bastante difíciles de detectar).
3. Seguridad local
3.1. Bootloaders
El siguiente paso es proteger el bootloader, ya sea lilo o grub, para que el ata-
cante no pueda modificar las opciones de arranque del kernel o modificar di-
rectamente el arranque (caso de grub). Cualquiera de los dos puede protegerse
también por contraseñas.
password = contraseña
image = /boot/vmlinuz-version
password = contraseña
restricted
© FUOC • P07/M2103/02288 23 Administración de seguridad
En este caso restricted indica además que no se podrán cambiar los paráme-
tros pasados al kernel desde línea de comandos. Hay que tener cuidado de
poner el fichero /etc/lilo.conf protegido a sólo lectura/escritura desde el
root (chmod 600).
user:sndb565sadsd:...
Pero el problema está en que este fichero es legible por cualquier usuario, con
lo que un atacante podía obtener el fichero y utilizar un ataque de fuerza bru-
ta, hasta que desencriptase los passwords contenidos en el fichero, o bien me-
diante ataques de fuerza bruta por medio de diccionarios.
Una cuestión que debe tenerse en cuenta siempre es hacer estas pruebas sobre
nuestros sistemas. No hay que olvidar que los administradores de otros siste-
mas (o el proveedor de acceso o ISP) tendrán sistemas de detección de intrusos
habilitados y podemos ser objeto de denuncia por intentos de intrusión, ya sea
ante las autoridades competentes (unidades de delitos informáticos) o en
nuestro ISP para que se nos cierre el acceso. Hay que tener mucho cuidado con
el uso de herramientas de seguridad, que están siempre al filo de la navaja en-
tre ser de seguridad o de intrusión.
Otro problema importante son algunos permisos especiales que son utilizados
sobre ficheros o script.
bit se coloca mediante chmod +s, ya sea aplicándolo al propietario (se llama
entonces suid) o al grupo (se llama bit sgid); puede quitarse con -s. En el caso
de visualizar con ls, el fichero aparecerá con -rwSrw-rw (fijaos en la S), si es sólo
suid, en sgid la S aparecería tras la segunda w.
En caso de utilizar chmod con notación octal, se usan cuatro cifras, donde las
tres últimas son los permisos clásicos rwxrwxrwx (recordad que hay que sumar
en la cifra 4 para r, 2 w, y 1 para x), y la primera tiene un valor para cada permiso
especial que se quiera (que se suman): 4 (para suid), 2 (sgid), y 1 (para sticky).
servicios como ssh, de login gráfico de X Window System, como xdm, gdm,
kdm, xscreensaver... o, por ejemplo, del login del sistema (la entrada por iden-
tificador de usuario y contraseña). En las antiguas versiones de PAM, se utili-
zaba un archivo (típicamente en /etc/pam.conf), que era donde se leía la
configuración PAM si el directorio /etc/pam.d no existía.
La línea típica de estos ficheros (en /etc/pam.d) tendría este formato (si se uti-
liza /etc/pam.conf habría que añadir el servicio a que pertenece como primer
campo):
donde se especifica:
@include servicio
© FUOC • P07/M2103/02288 27 Administración de seguridad
Un pequeño ejemplo del uso de módulos PAM (en una distribución Debian),
puede ser su uso en el proceso de login (se han listado también las líneas in-
cluidas provenientes de otros servicios):
Otros controlan su sesión para ver cuándo ha entrado por última vez, o guar-
dan cuándo entra y sale (para el comando lastlog), también hay un módulo
que se encarga de verificar si el usuario tiene correo por leer (también hay que
autentificarse), y otro que controla que cambie la contraseña (si está obligado
a hacerlo en el primer login que haga) y que tenga de 4 a 8 letras, y puede uti-
lizarse md5 para la encriptación.
Un caso típico es la posibilidad de forzar el root para que ejecute comandos fal-
sos de sistema; por ejemplo, si el root incluyese el “.” en su variable de PATH,
esto permitiría la ejecución de comandos desde su directorio actual, lo que ha-
bilitaría para colocar archivos que sustituyesen comandos del sistema y que se-
rían ejecutados en primer término antes que los de sistema. El mismo proceso
© FUOC • P07/M2103/02288 28 Administración de seguridad
puede hacerse con un usuario, aunque por ser más limitados sus permisos,
puede no afectar tanto al sistema, cuanto más a la propia seguridad del usua-
rio. Otro caso típico es el de las pantallas de login falsas, pudiéndose sustituir
el típico proceso de login, passwd, por un programa falso que almacene las
contraseñas introducidas.
4. SELinux
Por otro lado las técnicas MAC (mandatory access control), desarrollan políticas
de seguridad (definidas por el administrador) donde el sistema tiene control
completo sobre los derechos de acceso que se conceden sobre cada recurso. Por
ejemplo, con permisos (de tipo Unix) podemos dar acceso a ficheros, pero me-
diante políticas MAC tenemos control extra para determinar a qué ficheros ex-
plícitamente se permite acceso por parte de un proceso, y qué nivel de acceso
queremos conceder. Se fijan contextos, en los cuales se indican en qué situa-
ciones un objeto puede acceder a otro objeto.
NOTA
SELinux fue desarrollado por la agencia US NSA, con aportaciones de diversas com-
pañías para sistemas UNIX y libres, como Linux y BSD. Se liberó en el año 2000 y Algunos recursos sobre
SELinux:
desde entonces se ha ido integrando en diferentes distribuciones GNU/Linux. http://www.redhat.com/docs/
manuals/enterprise/
RHEL-4-Manual/selinux-guide/
Disponemos en SELinux de un modelo de dominio-tipo, donde cada proceso co-
http://www.nsa.gov/selinux/
rre en un denominado contexto de seguridad, y cualquier recurso (fichero, direc- http://fedora.redhat.com/
torio, socket, etc.) tiene un tipo asociado con él. Hay un conjunto de reglas que docs/selinux-faq/
http://selinux.sourceforge.net/
indican qué acciones pueden efectuarse en cada contexto sobre cada tipo. Una
© FUOC • P07/M2103/02288 30 Administración de seguridad
ventaja de este modelo contexto-tipo es que las políticas que se definan pueden
ser analizadas (existen herramientas) para determinar qué flujos de información
están permitidos, por ejemplo, para detectar posibles vías de ataque, o si la políti-
ca es lo suficientemente completa para cubrir todos los accesos posibles.
root:sysadm_r:sysadm_t
Por ejemplo, en una máquina con SELinux activado (una Fedora en este caso)
podemos ver con la opción -Z del ps los contextos asociados a los procesos:
# ps ax –Z
LABEL PID TTY STAT TIME COMMAND
system_u:system_r:init_t 1 ? Ss 0:00 init
system_u:system_r:kernel_t 2 ? S 0:00 [migration/0]
system_u:system_r:kernel_t 3 ? S 0:00 [ksoftirqd/0]
system_u:system_r:kernel_t 4 ? S 0:00 [watchdog/0]
system_u:system_r:kernel_t 5 ? S 0:00 [migration/1]
system_u:system_r:kernel_t 6 ? SN 0:00 [ksoftirqd/1]
system_u:system_r:kernel_t 7 ? S 0:00 [watchdog/1]
system_u:system_r:syslogd_t 2564 ? Ss 0:00 syslogd -m 0
system_u:system_r:klogd_t 2567 ? Ss 0:00 klogd -x
system_u:system_r:irqbalance_t 2579 ? Ss 0:00 irqbalance
system_u:system_r:portmap_t 2608 ? Ss 0:00 portmap
system_u:system_r:rpcd_t 2629 ? Ss 0:00 rpc.statd
user_u:system_r:unconfined_t 4812 ? Ss 0:00 /usr/libexec/gconfd-2 5
user_u:system_r:unconfined_t 4858 ? Sl 0:00 gnome-terminal
user_u:system_r:unconfined_t 4861 ? S 0:00 gnome-pty-helper
user_u:system_r:unconfined_t 4862 pts/0 Ss 0:00 bash
user_u:system_r:unconfined_t 4920 pts/0 S 0:01 gedit
system_u:system_r:rpcd_t 4984 ? Ss 0:00 rpc.idmapd
system_u:system_r:gpm_t 5029 ? Ss 0:00 gpm -m /dev/input/mice -t exps2
user_u:system_r:unconfined_t 5184 pts/0 R+ 0:00 ps ax -Z
user_u:system_r:unconfined_t 5185 pts/0 D+ 0:00 Bash
© FUOC • P07/M2103/02288 31 Administración de seguridad
y con ls con la opcion -Z podemos ver los contextos asociados a ficheros y di-
rectorios:
# ls -Z
drwxr-xr-x josep josep user_u:object_r:user_home_t Desktop
drwxrwxr-x josep josep user_u:object_r:user_home_t proves
-rw-r--r-- josep josep user_u:object_r:user_home_t yum.conf
$ id -Z
user_u:system_r:unconfined_t
Con respecto a la política usada, SELinux soporta dos tipos diferentes: targered
y strict. En targered la mayoría de procesos operan sin restricciones, y solo ser-
vicios (ciertos daemons) específicos son puestos en diferentes contextos de se-
guridad que son confinados a la política de seguridad. En strict todos los
procesos son asignados a contextos de seguridad, y confinados a políticas de-
finidas, de manera que cualquier acción es controlada por las políticas defini-
das. En principio éstos son los dos tipos de políticas definidas generalmente,
pero la especificación está abierta a incluir más.
4.1. Arquitectura
• Herramientas
– Y ficheros que sirven para etiquetar los contextos de los ficheros y di-
rectorios durante la carga, o en determinados momentos.
Veamos de este último apartado las herramientas típicas de que solemos disponer:
Nombre Utilización
– cron: Modificado para incluir los contextos para los trabajos en ejecución
por cron.
– login: Modificado para que coloque el contexto de seguridad inicial para el
usuario cuando entra en el sistema.
– logrotate: Modificado para preservar el contexto de los logs cuando estén
recopilados.
– pam: Modificado para colocar el contexto inicial del usuario y para usar la
API SELinux y obtener acceso privilegiado a la información de passwords.
– ssh: Modificado para colocar el contexto inicial del usuario cuando éste entra
en el sistema.
– Y varios programas adicionales que modifiquen /etc/passwd o /etc/shadow.
4.2. Crítica
5. Seguridad en red
La configuración de los servicios de red [Mou01], tal como hemos visto, se rea-
liza desde varios lugares [Ano99][Hat01][Peñ]:
Otros ficheros de apoyo (con información útil) son: /etc/services, que está for-
mado por una lista de servicios locales o de red conocidos, junto con el nom-
bre del protocolo (tcp, udp u otros), que se utiliza en el servicio, y el puerto
que utiliza; /etc/protocols es una lista de protocolos conocidos; y /etc/rpc es
una lista de servidores RPC, junto con los puertos usados. Estos ficheros vie-
nen con la distribución y son una especie de base de datos que utilizan los co-
mandos y herramientas de red para determinar los nombres de servicios,
protocolos, o rpc y sus puertos asociados. Cabe destacar que son ficheros más
o menos históricos, que no tienen por qué contener todas las definiciones de
protocolos y servicios, pueden asimismo buscarse diferentes listas en Internet
de puertos conocidos.
b) rsh, rexec, rcp además presentan el problema de que bajo algunas condi-
ciones ni siquiera necesitan contraseñas (por ejemplo, si se hace desde sitios
validados en fichero .rhosts), con lo cual vuelven a ser inseguros, y dejan gran-
des puertas abiertas.
Respecto a SSH, también hay que tener la precaución de usar ssh version 2. La
primera versión tiene algunos exploits conocidos; hay que tener cuidado al ins-
talar OpenSSH, y si no necesitamos la primera versión, instalar sólo soporte
para ssh2 (ver opción Protocol en fichero de configuración /etc/ssh/
ssh_config).
6. Detección de intrusiones
Con los sistemas de detección de intrusos [Hat01] (IDS) se quiere dar un paso
Nota
más adelante. Una vez hayamos podido configurar más o menos correctamen-
Los sistemas IDS nos permiten
te nuestra seguridad, el paso siguiente consistirá en una detección y preven- la detección a tiempo
ción activa de las intrusiones. de intrusos, usando nuestros
recursos o explorando
nuestros sistemas en busca
de fallos de seguridad.
Los sistemas IDS crean procedimientos de escucha y generación de alertas al
detectar situaciones sospechosas, o sea, buscamos síntomas de posibles acci-
dentes de seguridad.
Los hay desde sistemas basados en la información local, por ejemplo, recopi-
lan información de los log del sistema, vigilan cambios en los ficheros de sis-
tema o bien en las configuraciones de los servicios típicos. Otros sistemas
están basados en red e intentan verificar que no se produzcan comportamien-
tos extraños, como por ejemplo los casos de spoofing, donde hay falsificaciones
de direcciones conocidas; controlar tráfico sospechoso, posibles ataques de de-
negación de servicio, detectando tráfico excesivo hacia determinados servi-
cios, controlando que no hay interfaces de red en modo promiscuo (síntoma
de sniffers o capturadores de paquetes).
Ejemplos
Los TCP wrappers [Mou01] son un software que actúa de intermediario entre
las peticiones del usuario de servicio y los daemons de los servidores que ofre-
cen el servicio. Muchas de las distribuciones vienen ya con los wrappers acti-
vados y podemos configurar los niveles de acceso. Los wrappers se suelen
utilizar en combinación con inetd o xinetd, de manera que protejan los servi-
cios que ofrecen.
de manera que, cuando llegue una petición, será tratada por el daemon tcpd que
se encargará de verificar el acceso (para más detalles, ver página man tcpd).
servicio y un posible cliente (usuario, y/o host), y nos dice qué haría el sis-
tema ante esta situación.
7.1. Firewalls
Este tipo de firewall suele combinarse con un router para enlazar los paquetes
de las diferentes redes. Otra configuración típica es la de firewall hacia Inter-
net, por ejemplo con dos tarjetas de red: en una obtenemos/proporcionamos
trafico a Internet y en la otra enviamos o proporcionamos el tráfico a nuestra
red interna, pudiendo así eliminar el tráfico que no va destinado a nosotros, y
también controlar el tráfico que se mueve hacia Internet, por si no queremos
que se tenga acceso a algunos protocolos, o bien sospechamos que hay posibi-
lidades de fugas de información por algunos ataques. Una tercera posibilidad
es la máquina individual conectada con una única tarjeta de red hacia Inter-
net, directa o bien a través de un proveedor. En este caso, sólo queremos pro-
teger nuestra máquina de ataques de intrusos, de tráfico no deseado o de que
se vea comprometida al robo de datos.
La interfaz del comando IPtables permite realizar las diferentes tareas de con-
Nota
figuración de las reglas que afectan al sistema de filtrado: ya sea generación de
IPTables aporta diferentes ele-
logs, acciones de pre y post routing de paquetes, NAT, y forwarding (reenvío) de mentos como las tablas,
chains, y las propias reglas.
puertos.
El comando iptables -L lista las reglas activas en ese momento en cada una de
las cadenas (chains). Si no se han configurado previamente, suelen ser por de-
fecto aceptar todos los paquetes de las cadenas (o chains) de input (entrada),
output (salida) y forward (reenvío).
El sistema de IPTables tiene como nivel superior las tablas. Cada una contiene
diferentes cadenas, que a su vez contienen diferentes reglas. Las tres tablas que
existen son: Filter, NAT y Mangled. La primera sirve para las propias normas
© FUOC • P07/M2103/02288 43 Administración de seguridad
Al poner la regla, también puede usarse la opción -I (insertar) para indicar una
posición, por ejemplo:
que nos dice que se coloque la regla en la cadena input en tercera posición; y
se van a aceptar paquetes (-j) que provengan (con fuente, o source, -s) de la su-
bred 10.0.0.0 con netmask 255.0.0.0. Con -D de forma parecida podemos bo-
rrar o un número de regla, o la regla exacta, como se especifica a continuación,
borrando la primera regla de la cadena o la regla que mencionamos:
iptables -D INPUT 1
iptables -D INPUT -s 10.0.0.0/8 -j ACCEPT
También hay reglas que permiten definir una “política” por defecto de los pa-
quetes (opción -P); se va a hacer con todos los paquetes lo mismo. Por ejem-
plo, se suele decir que se pierdan todos los paquetes por defecto, y se habilitan
luego los que interesan, y muchas veces también se evita que haya forwarding
de paquetes si no es necesario (si no actuamos de router), esto podría ponerse:
Todo lo cual establece unas políticas por defecto que consisten en denegar la
entrada de paquetes, no permitir salir y no reenviar paquetes. Ahora se podrán
añadir las reglas que conciernen a los paquetes que deseemos utilizar, dicien-
do qué protocolos, puertos y orígenes o destinos queremos permitir o evitar.
Esto puede ser difícil, ya que tenemos que conocer todos los puertos y proto-
colos que utilicen nuestro software o servicios. Otra táctica sería dejar sólo ac-
tivos aquellos servicios que sean imprescindibles y habilitar con el firewall el
acceso de los servicios a las máquinas deseadas.
Donde:
2) Rechazamos los paquetes tcp con destino al puerto 113, emitiendo una res-
puesta de tipo tcp-reset.
© FUOC • P07/M2103/02288 45 Administración de seguridad
/etc/init.d/iptables save
Y se guardan en:
/etc/sysconfig/iptables
Con (/etc/init.d/iptables load) podemos cargar las reglas (en Debian hay que
dar el nombre del fichero de reglas), aunque Debian soporta unos nombres por
defecto de ficheros, que son active para las reglas normales (las que se usarán
en un start del servicio) e inactive para las que quedarán cuando se desactive el
servicio (se haga un stop). Otra aproximación comúnmente usada es la de co-
locar las reglas en un fichero script con las llamadas iptables que se necesiten
y llamarlas por ejemplo colocándolas en el runlevel necesario, o con enlace ha-
cia el script en /etc/init.d.
vicios que se ven afectados y podemos dejar, o no, pasar al servicio cam-
biando la configuración por defecto. El mecanismo utilizado por debajo
es iptables. Puede verse la configuración final de reglas que realiza /etc/
sysconfig/iptables que, a su vez, es leído por el servicio iptables, que se car-
ga en arranque, o bien por parada o arranque mediante /etc/init.d/iptables
con las opciones start o stop. En Debian también es posible instalarlo,
pero deja la configuración de las reglas en /etc/defaults/lokkit-l, y un
script en /etc/init.d/lokkit-l. También existe una versión gráfica llamada gno-
me-lokkit.
• fwbuilder: una herramienta que permite construir las reglas del firewall de
Nota
forma gráfica. Se puede utilizar en varios operativos (GNU/Linux tanto
Ver:
Fedora como Debian, OpenBSD, MacOS), con diferentes tipos de firewalls http://www.fwbuilder.org/
(iptables incluido).
• Los códigos móviles por web (ActiveX, Java, y JavaScript), cruzan los firewalls,
y por lo tanto es difícil proteger los sistemas si éstos son vulnerables a los
ataques contra agujeros descubiertos.
Así, aunque los firewalls son una muy buena solución a la mayor parte de la
seguridad, siempre pueden tener vulnerabilidades y dejar pasar tráfico que se
considere válido, pero que incluya otras fuentes posibles de ataques o vulne-
rabilidades. En seguridad nunca hay que considerar (y confiar en) una única
solución, y esperar que nos proteja absolutamente; hay que examinar los di-
versos problemas, plantear soluciones que los detecten a tiempo y políticas de
prevención que nos curen en salud, por lo que pueda pasar.
© FUOC • P07/M2103/02288 48 Administración de seguridad
8. Herramientas de seguridad
Puede servir como sistema IDS preventivo. Nos sirve para “tomar” una foto
del sistema, poder comparar después cualquier modificación introducida y
comprobar que éste no haya sido corrompido por un atacante. El objetivo
aquí es proteger los archivos de la propia máquina, evitar que se produzcan
cambios como, por ejemplo, los que podría haber provocado un rootkit.
Así, cuando volvamos a ejecutar la herramienta, podemos comprobar los
cambios respecto a la ejecución anterior. Hay que elegir un subconjunto de
archivos que sean importantes en el sistema, o fuentes de posibles ataques.
TripWire es propietario, pero hay una herramienta libre equivalente llama-
da AIDE.
9. Análisis logs
Observando los ficheros de log [Ano99][Fri02], podemos hacernos una idea rá-
pida del estado global del sistema, así como de las últimas ocurrencias, y de-
tectar accesos (o intentos) indebidos. Pero también cabe tener presente que los
logs, si ha sucedido una intrusión real, pueden haber sido limpiados o falsea-
dos. La mayoría de archivos de log residen en el directorio /var/log.
Muchos de los servicios pueden poseer logs propios, que normalmente se esta-
blecen en la configuración (mediante el correspondiente fichero de configura-
ción). La mayoría suelen utilizar las facilidades de log incorporadas en el
sistema Sys log, mediante el demonio Syslogd. Su configuración reside en /etc/
syslog.conf. Esta configuración suele establecerse por niveles de mensajes:
existen diferentes tipos de mensajes según su importancia. Normalmente sue-
len aparecer niveles debug, info, err, notice, warning, err, crit, alert, emerg, en
que más o menos ésta sería la ordenación de importancia de los mensajes (de
menor a mayor). Normalmente, la mayoría de los mensajes se dirigen al log
/var/log/messages, pero puede definirse que cada tipo vaya a ficheros diferen-
tes y también se puede identificar quién los ha originado; típicamente el ker-
nel, correo, news, el sistema de autentificación, etc.
Comentamos en los siguientes puntos algunos ficheros de log que habría que
tener en cuenta (quizás los más utilizados):
está dentro del sistema. El comando who utiliza este fichero para propor-
cionar esta información.
En el sistema de logs, otra cosa que habría que asegurar es que el directorio de
logs /var/ log, pueda ser sólo escribible por el root (o deamons asociados a servi-
cios). De otro modo, cualquier atacante podría falsificar la información de los
logs. Aun así, si el atacante consigue acceso a root, puede, y suele, borrar las pis-
ta de sus accesos.
© FUOC • P07/M2103/02288 53 Administración de seguridad
Primero examinaremos qué ofrece nuestra máquina a la red. Para ello, utiliza-
remos la herramienta nmap como escaneador de puertos. Con el comando
(desde root):
obtenemos:
(The 3079 ports scanned but not shown below are in state: closed)
Ahora tenemos que reiniciar inetd para que vuelva a leer la configuración que
hemos cambiado: /etc/init.d/inetd restart.
Volvemos a nmap:
De lo que nos queda, tenemos el servicio ssh, que queremos dejar, y el servidor
de web, que lo pararemos de momento:
/etc/init.d/apache stop
Los servicios RPC que se ofrecen se pueden ver con el comando rpcinfo:
root@maquina:˜# rpcinfo -p
donde observamos los servicios RPC con algunos de los puertos que ya se ha-
bían detectado. Otro comando que puede resultar útil es lsof, que, entre otras
funciones, permite relacionar puertos con los servicios que los han abierto
(por ejemplo: lsof -i | grep 731).
© FUOC • P07/M2103/02288 56 Administración de seguridad
/etc/init.d/nfs-common
/etc/init.d/nfs-kernel-server
/etc/init.d/portmap
dándoles el parámetro stop para parar los servicios RPC (en este caso NFS).
sshd: 1.2.3.4
nos dice que sería concedido el acceso. Un detalle es que nos dice que sshd no
está en el inetd.conf, y si lo verificamos, vemos que así es: no se activa por el
servidor inetd, sino por daemon en el runlevel que estemos. Además (en De-
bian), éste es un caso de demonio que está compilado con las bibliotecas de
wrappers incluidas (y, por lo tanto, no necesita tcpd para funcionar). En De-
bian hay varios daemons así: ssh, portmap, in.talk, rpc.statd, rpc.mountd, en-
tre otros. Esto permite asegurar estos daemons mediante wrappers.
Otra cuestión por verificar son las conexiones actuales existentes. Con el co-
mando netstat -utp, podemos listar las conexiones tcp, udp establecidas con
el exterior, ya sean entrantes o salientes; así, en cualquier momento podemos
detectar los clientes conectados y a quién estamos conectados. Otro comando
importante (de múltiples funciones) es lsof, que puede relacionar ficheros
abiertos con procesos o conexiones por red establecidas mediante lsof -i, pu-
diéndose así detectar accesos indebidos a ficheros.
root@aopcjj:˜# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
En este punto, podríamos añadir un firewall que nos permitiese una gestión
más adecuada de paquetes que recibimos y enviamos, y que sería un control
previo para mejorar la seguridad. Dependiendo de nuestras necesidades, esta-
bleceríamos las reglas necesarias de modo parecido a las que comentamos en
los ejemplos de firewalls de la unidad.
Actividades
1) Supongamos que colocamos en nuestra máquina un sitio web, por ejemplo con Apache.
Nuestro sitio está pensado para diez usuarios internos, pero no controlamos este número.
Más adelante nos planteamos poner en Internet este sistema, ya que creemos que puede ser
útil para los clientes, y lo único que hacemos es poner el sistema con una IP pública en In-
ternet. ¿Qué tipo de ataques podría sufrir este sistema?
2) ¿Cómo podemos detectar los ficheros con suid en nuestro sistema? ¿Qué comandos serán
necesarios? ¿Y los directorios con SUID o SGID? ¿Por qué es necesario, por ejemplo, que /usr/
bin/passwd tenga bit de SUID?
3) Los ficheros .rhosts, como hemos visto, son un peligro importante para la seguridad. ¿Po-
dríamos utilizar algún método automático que comprobase su existencia periódicamente?
¿Cómo?
4) Supongamos que queremos deshabilitar un servicio del cual sabemos que tiene el
script /etc/init.d/servicio que lo controla: queremos desactivarlo en todos los runlevels en los
que se presenta. ¿Cómo encontramos los runlevels en los que está? (por ejemplo, buscando
enlaces al script).
5) Examinar los servicios en activo en vuestra máquina. ¿Son todos necesarios? ¿Cómo ha-
bría que protegerlos o desactivarlos?
6) Practicar el uso de algunas de las herramientas de seguridad descritas (nmap, nessus, etc.).
7) ¿Qué reglas IPtables serían necesarias para una máquina en la que sólo queremos acceso
por SSH desde una dirección concreta?
[Peñ] Imprescindible para Debian, muy buena descripción para seguir paso a paso la confi-
guración de seguridad, [Hatb] sería equivalente para Fedora/Red Hat.
[Mou01] Excelente referencia de seguridad para Red Hat (aplicable también para Debian).
[Sei] Guía paso a paso identificando los puntos clave que hay que verificar y los problemas
que puedan surgir.
[Proa] [Sno] [Insb] [Nes] Algunas de las herramientas de seguridad más usadas.
[NSAb] Versión de Linux con miras a la seguridad, producida por la NSA. Referencia para SE-
Linux.
P07/M2103/02289
© FUOC • P07/M2103/02289 2 Configuración, sintonización y optimización
© FUOC • P07/M2103/02289 Configuración, sintonización y optimización
Índex
Introducció ............................................................................................... 5
Actividades .............................................................................................. 31
Introducción
1. Aspectos básicos
b) Ley de Amdahl: según esta ley, “hay un límite de cuánto puede uno me-
jorar en velocidad una cosa si sólo se optimiza una parte de ella”; es decir,
si se tiene un programa que utiliza el 10% de CPU y se optimiza reduciendo
la utilización en un factor de 2, el programa mejorará sus prestaciones
(speedup) en un 5%, lo cual puede significar un tremendo esfuerzo no com-
pensado con los resultados.
/proc/1: un directorio con la información del proceso 1 (el número del directorio
es el PID del proceso)
/proc/kmsg: mensajes generados por el kernel que luego son enviados a syslog.
Se debe tener en cuenta que estos archivos son visibles (texto) pero algunas ve-
ces los datos están en “crudo” y son necesarios comandos para interpretarlos,
que serán los que veremos a continuación.
Los sistemas compatibles UNIX SV utilizan los comandos sar y sadc para ob-
tener estadísticas del sistema (en FC incluidos dentro del paquete sysstat que
incluye además iostat u mpstat). Su equivalente en GNU/Linux Debian es atsar
(y atsadc), que es totalmente equivalente a los que hemos mencionado. El co-
mando atsar lee contadores y estadísticas del fichero /proc y las muestra por
la salida estándar. La primera forma de llamar al comando es:
donde muestra la actividad en n veces cada t segundos con una cabecera mos-
trando los contadores de actividad (el valor por defecto de n es 1). La segunda
forma de llamarlo es:
El comando extrae datos del archivo especificado por -f (por defecto /var/
log/atsar/atsarxx, con xx el día del mes) y que fueron previamente guardados
por atsadc (se utiliza para recoger los datos, salvarlos y procesarlos y en Debian
está en /usr/lib/atsar). El parámetro -n puede ser utilizado para indicar el día del
mes y -s, -e la hora de inicio-final, respectivamente. Para activar atsadc, por ejem-
plo, se podría incluir en /etc/cron.d/atsar una línea como la siguiente:
La 1.ª crea el archivo después de un reinicio. La 2.ª guarda los datos cada 10
minutos con el shell script atsa1, que llama al atsadc.
En atsar (o sar), las opciones se utilizan para indicar qué contadores hay que
mostrar; algunos de ellos son:
© FUOC • P07/M2103/02289 10 Configuración, sintonización y optimización
w Estadísticas de conexiones IP
t Estadísticas de TCP
U Estadísticas de UDP
m Estadísticas de ICMP
N Estadísticas de NFS
Entre atsar y sar sólo existen algunas diferencias en cuanto a cómo muestran
los datos y sar incluye unas cuantas opciones más (o diferentes). A continua-
ción se verán algunos ejemplos de utilización del sar (exactamente igual que
con atsar, sólo puede haber alguna diferencia en la visualización de los datos)
y el significado de la información que genera:
1) Utilización de CPU
sar -u 4 5
• nice, lo mismo, pero con procesos de usuario con nice > 0 (menor prioridad
que la media).
• idle indica el tiempo no utilizado de CPU por los procesos en estado de es-
pera (no incluye espera de disco).
• iowait es el tiempo que la CPU ha estado libre cuando el sistema estaba ha-
ciendo entrada o salida de disco.
En este caso idle=100, lo cual significa que la CPU está ociosa por lo que no
hay procesos por ejecutar y la carga es baja; si idle=10 y el número de proce-
sos es elevado, debería pensarse en optimizar la CPU, ya que podría ser el cue-
llo de botella del sistema.
sar -I 4 5
3) Memoria y swap
sar -r 4 5
08:24:20 kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad
a parar al swap, donde debe haber sitio. Esto se debe contrastar con la utiliza-
ción de CPU. También se debe controlar que el tamaño de los buffers sea ade-
cuado y esté en relación con los procesos que están realizando operaciones de
entrada/salida.
Es también interesante el comando free (fc) que permite ver la cantidad de me-
moria en una visión simplificada:
Esto indica que de 1Gb casi ¾ de la memoria está ocupada y que casi ½ son
de caché. Además nos indica que el swap no se está utilizando para nada,
por lo que podemos concluir que el sistema está bien. Si quisiéramos más
detalles, deberíamos utilizar el comando vmstat (o sar -r) para analizar qué
es lo que está causando problemas o quién está consumiendo tanta memo-
ria. A continuación se muestra una salida de vmstat 1 10:
sar -v 4 5
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
Memory:
Luego se deberá comparar con la memoria física y analizar si el sistema está limi-
tado por la memoria (se verá con atsar -r y -p mucha actividad de paginación).
tener todas las variables de configuración del kernel que pueden ser analizadas
y, en cierto caso, ‘ajustadas’, para lograr prestaciones diferentes o mejores.
Para ello, se debe utilizar el comando systune dump > /tmp/sysfile para ob-
tener todas las variables y sus valores en el archivo /tmp/sysfile (en otras distribu-
ciones se puede hacer con sysctl). Este archivo se puede editar, cambiar la variable
correspondiente y luego utilizar el comando systune -c /tmp/sysfile para
cargarlas nuevamente en el /proc. El comando systune también lee por defec-
to si no tiene la opción -c de /etc/systune.conf. En este caso, por ejemplo, se
podría modificar (procédase con cuidado, porque el kernel puede quedar fuera
de servicio) las variables de la categoría /proc/sys/vm (memoria virtual) o /proc/
sys/kernel (configuración del core del kernel).
Se debe tener en cuenta que una alta actividad de interrupciones puede afectar
a las prestaciones de la CPU con relación a los procesos que ejecuta. Mediante
monitorización (atsar -I) se puede mirar cuál es la relación de interrupciones
por segundo y tomar decisiones con respecto a los dispositivos que las causan.
Por ejemplo, cambiar de módem por otro más inteligente o cambiar la estruc-
tura de comunicaciones si detectamos una actividad elevada sobre el puerto
serie donde se encuentra conectado.
vado (por ejemplo, > 30 entrada/salida/s) utilizando atsar -u y atsar -d. Las so-
luciones pasan por:
f) Obviamente, el cambio del disco por uno de mayor velocidad (RPM) siem-
pre tendrá un impacto positivo en un sistema limitado por entrada/salida de
disco. [Maj96]
b) Planificar dónde estarán los servidores para reducir el tráfico hacia ellos y
los tiempos de acceso.
© FUOC • P07/M2103/02289 18 Configuración, sintonización y optimización
Existen una serie de optimizaciones de índole general que pueden mejorar las
prestaciones del sistema:
a) Impedir que se pueda arrancar otro sistema operativo: si alguien tiene ac-
ceso físico a la máquina, podría arrancar con otro sistema operativo preconfi-
gurado y modificar el actual, por lo que se debe inhibir desde el BIOS del
ordenador el boot por floppy o CD-ROM y poner un password de acceso (recor-
dar el password del BIOS, ya que, de otro modo, podría causar problemas cuan-
do se quisiera cambiar la configuración).
Formato:
También se debería por ejemplo configurar los grupos para controlar qué y
cómo y también los límites máximos (limits.conf) para establecer los tiempos
máximos de utilización de CPU, E/S, etc. para evitar por ejemplo DoS.
e) No acceder al sistema como root: crear una cuenta como sysadm y trabajar
con ella. Si se accede remotamente, habrá siempre que utilizar shh para conectar-
se al sysadm y, en caso de ser necesario, realizar un su - para trabajar como root.
k) Conexión del root: modificar el archivo /etc/securetty que contiene las TTY
y VC (virtual console) en que se puede conectar el root dejando sólo una de cada,
por ejemplo, tty1 y vc/1, y si es necesario conectarse como sysadm y hacer un su.
Se debe proceder con cuidado respecto a los archivos que quita el SUID- GUID
porque el comando podría quedar inútil.
o si no
1.5. Monitorización
servidor (load average, memory usage, CPU usage, MySQL throughput, eth0
traffic, etc.) sin excesivas configuraciones, mientras que monit verifica la dis-
ponibilidad de servicios tales como Apache, MySQL, Postfix, y toma diferentes
acciones como por ejemplo reactivarlo si el servicio no está presente. La com-
binación da gráficos importantes para reconocer dónde y qué está generando
problemas.
dbdir /var/lib/munin
htmldir /var/www/www.pirulo.org/web/monitoring
logdir /var/log/munin
rundir /var/run/munin
tmpldir /etc/munin/templates
[pirulo.org]
address 127.0.0.1
use_node_name yes
mkdir -p /var/www/pirulo.org/web/monitoring
chown munin:munin /var/www/pirulo.org/web/monitoring
/etc/init.d/munin-node restart
Figura 1
© FUOC • P07/M2103/02289 24 Configuración, sintonización y optimización
Figura 2
AuthType Basic
AuthName "Members Only"
AuthUserFile /var/www/pirulo.org/.htpasswd
<limit GET PUT POST>
require valid-user
</limit>
set daemon 60
set logfile syslog facility log_daemon
set mailserver localhost
set mail-format { from: [email protected] }
set alert root@localhost
set httpd port 3333 and
allow admin:test
© FUOC • P07/M2103/02289 25 Configuración, sintonización y optimización
Figura 3
WorkDir: /var/www/mrtg
Target[average]: `/usr/local/bin/cpu-load/average`
MaxBytes[average]: 1000
Options[average]: gauge, nopercent, growright, integer
YLegend[average]: Load average
kMG[average]: ,,
ShortLegend[average]:
Legend1[average]: Load average x 100
LegendI[average]: load:
LegendO[average]:
Title[average]: Load average x 100 for pirulo.org
PageTop[average]: <H1>Load average x 100 for pirulo.org</H1>
<TABLE>
<TR><TD>System:</TD>
<TD>pirulo.org</TD></TR>
<TR><TD>Maintainer:</TD> <TD>[email protected]</TD></TR>
<TR><TD>Max used:</TD> <TD>1000</TD></TR>
</TABLE>
Para generar los datos con atsar (o sar) creamos un script en /usr/local/bin/
cpu-load/average (que tenga permisos de ejecución para todos) que pasará los
datos a mrtg:
#!/bin/sh
load=`/usr/bin/atsar -u 1 | tail -n 1 | awk -F" " '{print $10}'`
echo "$load * 100" | bc | awk -F"." '{print $1}'
© FUOC • P07/M2103/02289 27 Configuración, sintonización y optimización
Deberemos crear y cambiar los permisos del directorio /var/www/mrtg. Por de-
fecto, mrtg se ejecuta en el cron, pero si después queremos ejecutarlo, pode-
mos hacer mrtg /etc/mrtg.cfg y esto generará las gráficas en /var/www/mrtg/
average.html que podremos visualizar con un navegador desde http://
www.pirulo.org/mrtg/averange.html.
Figura 4
• atsar, ac, sac, sysstat, isag: herramientas de auditoría tales como ac, last,
accton, sa, atsar o isag (Interactive System Activity Grapher) para la audi-
toría de recursos hw y sw.
• gps, gtop, tkps, lavaps (de más a menos amigable): monitores de procesos
de varios tipos (generalmente utilizan información de /proc) y permiten
ver recursos, sockets, archivos, entorno y otra información que éstos utili-
zan, así como administrar sus recursos/estados.
La figura siguiente muestra las interfaces de ksensors, gkrellm y xosview, que pre-
sentan los resultados de la monitorización en tiempo real que están realizando.
Figura 5
© FUOC • P07/M2103/02289 29 Configuración, sintonización y optimización
Figura 6
© FUOC • P07/M2103/02289 31 Configuración, sintonización y optimización
Actividades
1) Realizar una monitorización completa del sistema con las herramientas que consideréis
adecuadas y hacer un diagnóstico de la utilización de recursos y cuello de botella que podrían
existir en el sistema. Simular la carga en el sistema del código de sumdis.c dado en la unidad
que trata acerca de los clusters. Por ejemplo, utilizar:
sumdis 1 2000000
2) Cambiar los parámetros del kernel y del compilador y ejecutar el código mencionado en
el punto anterior (sumdis.c) con, por ejemplo:
[Debc, Ibi]
Munin: http://munin.projects.linpro.no/
Monit: http://www.tildeslash.com/monit/
MRTG: http://oss.oetiker.ch/mrtg/
Frysk: http://sources.redhat.com/frysk/
Cacti: http://cacti.net/
Clustering
Remo Suppi Boldrito
P07/M2103/02290
© FUOC • P07/M2103/02290 2 Clustering
© FUOC • P07/M2103/02290 Clustering
Índex
Introducció ............................................................................................... 5
2. OpenMosix ........................................................................................... 22
Actividades ............................................................................................... 31
Bibliografía .............................................................................................. 32
Introducció
1. Introducción al HPC
La historia de los sistemas informáticos es muy reciente (se puede decir que
comienza en la década de los sesenta). En un principio eran sistemas grandes,
pesados, caros, de pocos usuarios expertos, no accesibles, lentos. En la década
de los setenta, la evolución permitió mejoras sustanciales llevadas a cabo por
tareas interactivas (interactive jobs), tiempo compartido (time sharing), termina-
les y con una considerable reducción del tamaño. La década de los ochenta se
caracteriza por un aumento notable de las prestaciones (hasta hoy en día) y
una reducción del tamaño en los llamados microcomputers. Su evolución ha
sido a través de las estaciones de trabajo (workstations) y los avances en redes
(LAN de 10 Mbits/s y WAN de 56 Kbytes/s en 1973 a LAN de 1Gbit/s y WAN
con ATM, asynchronous transfer mode de 1.2 Gbits/s en la actualidad), que es
un factor fundamental en las aplicaciones multimedia actuales y de un futuro
próximo. Los sistemas distribuidos, por su parte, comenzaron su historia en la
década de los setenta (sistemas de 4 u 8 ordenadores) y su salto a la populari-
dad lo hicieron en la década de los noventa.
1.1. Beowulf
Beowulf [Rad, Beo] es una arquitectura multiordenador que puede ser utilizada
para aplicaciones paralelas/distribuidas (APD). El sistema consiste básicamen-
te en un servidor y uno o más clientes conectados (generalmente) a través de
Ethernet y sin la utilización de ningún hardware específico. Para explotar esta
capacidad de cómputo, es necesario que los programadores tengan un modelo
de programación distribuido que, si bien a través de UNIX es posible (socket,
rpc), puede significar un esfuerzo considerable, ya que son modelos de progra-
mación a nivel de systems calls y lenguaje C, por ejemplo; pero este modo de
trabajo puede ser considerado de bajo nivel.
La capa de software aportada por sistemas tales como parallel virtual machine
Nota
(PVM) y message passing interface (MPI) facilita notablemente la abstracción del
Varias opciones:
sistema y permite programar APD de modo sencillo y simple. La forma básica
• Beowulf
de trabajo es maestro-trabajadores (master-workers), en que existe un servidor • OpenMosix
que distribuye la tarea que realizarán los trabajadores. En grandes sistemas (por • Grid (Globus)
Primero se debe modificar de (cada nodo) el /etc/hosts para que la línea de lo-
calhost sólo tenga el 127.0.0.1 y no incluya ningún nombre de la máquina,
por ejemplo:
127.0.0.1 localhost
Y añadir las IP de los nodos (y para todos los nodos), por ejemplo:
192.168.0.1 pirulo1
192.168.0.2 pirulo2
...
Se debe crear un usuario (nteum) en todos los nodos, crear un grupo y añadir
este usuario al grupo:
groupadd beowulf
adduser nteum beowulf
echo umask 007 >> /home/nteum/.bash_profile
Así, cualquier archivo creado por el usuario nteum o cualquiera dentro del
grupo será modificable por el grupo beowulf.
Se debe crear un servidor de NFS (y los demás nodos serán clientes de este
NFS). Sobre el servidor hacemos:
mkdir /mnt/nteum
chmod 770 /mnt/nteum
chown -R nteum:beowulf /mnt/nteum
Debemos tener en cuenta que nuestra red será 192.168.0.xxx y es una red pri-
vada, es decir, el cluster no se verá desde Internet y deberemos ajustar las con-
figuraciones para que todos los nodos se vean entre todos (desde los firewalls).
Para trabajar de manera segura es importante trabajar con ssh en lugar de rsh,
por lo cual deberíamos generar las llaves para interconectar de modo seguro
las máquinas-usuario nteum sin passwd. Para eso modificamos (quitamos el
comentario #), de /etc/ssh/sshd_config en las siguientes líneas:
RSAAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
¿Dónde están los beneficios del cómputo paralelo? Lo veremos con un ejemplo
[Rad]. Sea un programa para sumar números (por ejemplo, 4 + 5 + 6...) llamado
sumdis.c y escrito en C:
© FUOC • P07/M2103/02290 11 Clustering
#include <stdio.h>
if (argc < 2) {
printf (“Uso: %s N.º inicial N.º final\n”,argv[0]);
exit(1);
}
else {
inicial = atol (argv[1]);
final = atol (argv[2]);
resultado = 0.0;
}
for (tmp = inicial; tmp <= final; tmp++){
resultado + = tmp; }
printf(“%f\n”, resultado)
return 0;
}
se podrá observar que el tiempo en una máquina Debian 2.4.18 con AMD
athjon 1.400 MHz 256 Mb RAM es (aproximadamente) real = 0,013 y user = 0,010
es decir, 13 ms en total y 10 ms en zona de usuario. Si, en cambio, hacemos:
send(destino,msg)
recv(origen,msg)
Las API más comunes hoy en día son PVM y MPI y además no limitan la po-
sibilidad de utilizar threads (aunque a nivel local) y tener concurrencia entre
procesamiento y entrada/salida. En cambio, en una máquina de memoria
compartida (SHM, shared memory) sólo es posible utilizar threads y tiene el pro-
blema grave de la escalabilidad, ya que todos los procesadores utilizan la mis-
ma memoria y el número de procesadores en el sistema está limitado por el
ancho de banda de la memoria.
PVM [Proe] es una API que permite generar, desde el punto de vista de la apli-
cación, una colección dinámica de ordenadores, que constituyen una máqui-
na virtual (VM). Las tareas pueden ser creadas dinámicamente (spawned) y/o
eliminadas (killed) y cualquier tarea PVM puede enviar un mensaje a otra. No
existe un límite en el tamaño o número de mensajes (según las especificacio-
nes, aunque pueden existir combinaciones hardware/sistema operativo que
den como resultado limitaciones en el tamaño del mensaje) y el modelo so-
porta: tolerancia a fallos, control de recursos, control de procesos, heteroge-
neidad en las redes y en los hosts.
PVM dispone de una consola (pvm) que permite poner en marcha el daemon,
crear la VM, ejecutar aplicaciones, etc. Es recomendable instalar el software
desde la distribución, ya que su compilación requiere cierta ‘dedicación’. Para
instalar PVM sobre Debian, por ejemplo, se deben incluir dos paquetes (míni-
mo): pvm y pvm-dev (en el primero está la consola pvm y utilidades y en el
segundo librerías, header y el resto de las herramientas para compilar). Si sólo
© FUOC • P07/M2103/02290 14 Clustering
Esta ley implica que una aplicación secuencial f = 0 y el speedup = 1, con todo
Nota
el código paralelo f = 1 y speedup = infinito(!), con valores posibles, 90% del
Ley de Amdahl:
código paralelo significa un speedup = 10 pero con f = 0,99 el speedup = 100.
speedup = 1/(1-f)
Esta limitación se puede evitar con algoritmos escalables y diferentes modelos f es la fracción código paralelo
de aplicación:
2) Single process multiple data (SPMD): mismo programa que se ejecuta con di-
ferentes conjuntos de datos.
#include <stdio.h>
#include “pvm3.h”
#define SLAVENAME “/home/nteum/pvm3/cliente”
main() {
int mytid, tids[20], n, nproc, numt, i, who, msgtype, loops;
float data[10]; int n_veces;
/*Ha podido?*/
if( numt < nproc ){
printf(“Error creando los hijos. Código de error:\n”);
for( i = numt ; i<nproc ; i++ ) {
printf(“Tid %d %d\n”,i,tids[i]); }
for( i = 0 ; i<numt ; i++ ){
pvm_kill( tids[i] ); } /*Mata los procesos con id en tids*/
pvm_exit();
exit(); /*Termina*/
}
#include <stdio.h>
#include “pvm3.h”
main() {
int mytid;/*Mi task id*/
int tids[20];/*Task ids*/
int n, me, i, nproc, master, msgtype, loops; float data[10];
long result[4]; float work();
mytid = pvm_mytid(); msgtype = 0;
i = me - 1;
if (me == 0 ) i = nproc-1;
pvm_recv( tids[i], 22 );
pvm_upkfloat( &psum, 1, 1 );
}
}
El programador cuenta con la gran ayuda de una interfaz gráfica (ver figura si-
guiente) que actúa como consola y monitor de PVM llamada xpvm (en Debian
XPVM, instalar paquete xpvm), que permite configurar la VM, ejecutar procesos,
visualizar la interacción entre tareas (comunicaciones), estados, información, etc.
Figura 1
La definición de la API de MPI [Prob, Proc] ha sido el trabajo resultante del MPI
Fourum (MPIF), que es un consorcio de más de 40 organizaciones. MPI tiene
influencias de diferentes arquitecturas, lenguajes y trabajos en el mundo del
paralelismo como son: WRC (Ibm), Intel NX/2, Express, nCUBE, Vertex, p4,
Parmac y contribuciones de ZipCode, Chimp, PVM, Chamaleon, PICL. El
principal objetivo de MPIF fue diseñar una API, sin relación particular con
ningún compilador ni biblioteca, de modo que permitiera la comunicación
eficiente (memory-to-memory copy), cómputo y comunicación concurrente y
descarga de comunicación, siempre y cuando exista un coprocesador de co-
municaciones. Además, que soportara el desarrollo en ambientes heterogé-
neos, con interfaz C y F77 (incluyendo C++, F90), donde la comunicación
fuera fiable y los fallos resueltos por el sistema. La API también debía tener in-
terfaz para diferentes entornos (PVM, NX, Express, p4...), disponer una imple-
mentación adaptable a diferentes plataformas con cambios insignificantes y
que no interfiera con el sistema operativo (thread-safety). Esta API fue diseñada
especialmente para programadores que utilizaran el message passing paradigm
(MPP) en C y F77 para aprovechar la característica más relevante: la portabili-
dad. El MPP se puede ejecutar sobre máquinas multiprocesadores, redes de WS
e incluso sobre máquinas de memoria compartida. La versión MPI1 (la versión
© FUOC • P07/M2103/02290 18 Clustering
más extendida) no soporta creación (spawn) dinámica de tareas, pero MPI2 (en
creciente evolución) sí que lo hace.
Muchos aspectos han sido diseñados para aprovechar las ventajas del hard-
ware de comunicaciones sobre SPC (scalable parallel computers) y el estándar ha
sido aceptado mayoritariamente por los fabricantes de hardware paralelo y
distribuido (SGI, SUN, Cray, HPConvex, IBM, Parsystec...). Existen versiones
freeware (por ejemplo, mpich) (que son totalmente compatibles con las imple-
mentaciones comerciales realizadas por los fabricantes de hardware) e inclu-
yen comunicaciones punto a punto, operaciones colectivas y grupos de
procesos, contexto de comunicaciones y topología, soporte para F77 y C y un
entorno de control, administración y profiling. Pero existen también algunos
puntos no resueltos como son: operaciones SHM, ejecución remota, herra-
mientas de construcción de programas, depuración, control de threads, admi-
nistración de tareas, funciones de entrada/salida concurrentes (la mayor parte
de estos problemas de falta de herramientas están resueltos en la versión 2 de
la API MPI2). El funcionamiento en MPI1, al no tener creación dinámica de
procesos, es muy simple, ya que de tantos procesos como tareas existan, autó-
nomos y ejecutando su propio código estilo MIMD (multiple instruction multi-
ple data) y comunicándose vía llamadas MPI. El código puede ser secuencial o
multithread (concurrentes) y MPI funciona en modo threadsafe, es decir, se
pueden utilizar llamadas a MPI en threads concurrentes, ya que las llamadas
son reentrantes.
na por línea, por defecto aparece localhost). Además, el usuario deberá tener
como shell por defecto el Csh.
El daemon lamboot ha sido diseñado para que los usuarios puedan ejecutar
programas distribuidos sin tener permisos de root (también permite ejecutar
programas en una VM sin llamadas a MPI). Por ello, para ejecutar el mpirun
se deberá hacer como un usuario diferente de root y ejecutar antes lamboot. El
lamboot utiliza un archivo de configuración en /etc/lam para la definición por
defecto de los nodos (ver bhost*) y consultar la documentación para mayor in-
formación (http://www.lam-mpi.org/). [Lam]
o bien:
#include “mpi.h”
#include <stdio.h>
#define BUFLEN 512
int main(int argc, char *argv[]) {
int myid, numprocs, next, namelen;
char buffer[BUFLEN], processor_name[MPI_MAX_PROCESSOR_NAME]; MPI_Status status;
MPI_Init(&argc,&argv);
/* Debe ponerse antes de otras llamadas MPI, siempre */
MPI_Comm_size(MPI_COMM_WORLD,&numprocs); MPI_Comm_rank(MPI_COMM_WORLD,&myid);
/*Integra el proceso en un grupo de comunicaciones*/
MPI_Get_processor_name(processor_name,&namelen);
/*Obtiene el nombre del procesador*/
fprintf(stderr,”Proceso %d sobre %s\n”, myid, processor_name); strcpy(buffer,”Hola Pueblo”);
if (myid ==numprocs1) next = 0;
else next = myid+1;
if (myid ==0) {/*Si es el inicial, envía string de buffer*/.
printf(“%d Envío ‘%s’ \n”,myid,buffer);
MPI_Send(buffer, strlen(buffer)+1, MPI_CHAR, next, 99,
MPI_COMM_WORLD);
/*Blocking Send, 1 o :buffer, 2 o :size, 3 o :tipo, 4 o :destino, 5
o :tag, 6 o :contexto*/
/*MPI_Send(buffer, strlen(buffer)+1, MPI_CHAR,
MPI_PROC_NULL, 299,MPI_COMM_WORLD);*/
printf(“%d recibiendo \n”,myid);
/* Blocking Recv, 1 o :buffer, 2 o :size, 3 o :tipo, 4 o :fuente, 5
o :tag, 6 o :contexto, 7 o :status*/
MPI_Recv(buffer, BUFLEN, MPI_CHAR, MPI_ANY_SOURCE, 99,
MPI_COMM_WORLD,&status); printf(“%d recibió ‘%s’ \n”,myid,buffer) }
else {
printf(“%d recibiendo \n”,myid);
MPI_Recv(buffer, BUFLEN, MPI_CHAR, MPI_ANY_SOURCE, 99,
MPI_COMM_WORLD,status);
/*MPI_Recv(buffer, BUFLEN, MPI_CHAR, MPI_PROC_NULL, 299,MPI_COMM_WORLD,&status);*/
printf(“%d recibió ‘%s’ \n”,myid,buffer);
MPI_Send(buffer, strlen(buffer)+1, MPI_CHAR, next, 99,
MPI_COMM_WORLD);
printf(“%d envió ‘%s’ \n”,myid,buffer);}
MPI_Barrier(MPI_COMM_WORLD); /*Sincroniza todos los procesos*/
MPI_Finalize(); /*Libera los recursos y termina*/ return (0);
}
© FUOC • P07/M2103/02290 21 Clustering
#include “mpi.h”
#include <stdio.h>
#include <math.h>
double f( double );
double f( double a) { return (4.0 / (1.0 + a*a)); }
MPI_Init(&argc,&argv);
MPI_Comm_size(MPI_COMM_WORLD,&numprocs);
/*Indica el número de procesos en el grupo*/
MPI_Comm_rank(MPI_COMM_WORLD,&myid); /*Id del proceso*/
MPI_Get_processor_name(processor_name,&namelen);
/*Nombre del proceso*/
fprintf(stderr,”Proceso %d sobre %s\n”, myid, processor_name);
n = 0;
while (!done) {
if (myid ==0) { /*Si es el primero...*/
if (n ==0) n = 100; else n = 0;
startwtime = MPI_Wtime();} /* Time Clock */
MPI_Bcast(&n, 1, MPI_INT, 0, MPI_COMM_WORLD); /*Broadcast al resto*/ /*Envía desde el 4.º
arg. a todos
los procesos del grupo Los restantes que no son 0
copiarán el buffer desde 4 o arg -proceso 0-*/ /*1.º:buffer,
2.º :size, 3.º :tipo, 5.º :grupo */
if (n == 0) done = 1; else {
h = 1.0 / (double) n;
sum = 0.0;
for (i = myid + 1; i <= n; i + = numprocs) {
x = h * ((double)i - 0.5); sum + = f(x); }
mypi = h * sum;
MPI_Reduce(&mypi, &pi, 1, MPI_DOUBLE, MPI_SUM, 0,
MPI_COMM_WORLD);
/* Combina los elementos del Send Buffer de cada proceso del
grupo usando la operación MPI_SUM y retorna el resultado en
el Recv Buffer. Debe ser llamada por todos los procesos del
grupo usando los mismos argumentos*/ /*1.º :sendbuffer, 2.º
:recvbuffer, 3.º :size, 4.º :tipo, 5.º :oper, 6.º :root, 7.º
:contexto*/
if (myid == 0){ /*Sólo el P0 imprime el resultado*/
printf(“Pi es aproximadamente %.16f, el error es %.16f\n”, pi, fabs(pi - PI25DT));
endwtime = MPI_Wtime();
printf(“Tiempo de ejecución = %f\n”, endwtime-startwtime); }
}
}
MPI_Finalize(); /*Libera recursos y termina*/
return 0;
}
Al igual que en PVM existe XPVM, en MPI existe una aplicación análoga (más
sofisticada) llamada XMPI (en Debian xmpi). También es posible instalar una
biblioteca, libxmpi3, que implementa el protocolo XMPI para analizar gráfi-
camente programas MPI con más detalles que los ofrecidos por xmpi. La figura
siguiente muestra unas de las posibles gráficas de xmpi.
© FUOC • P07/M2103/02290 22 Clustering
2. OpenMosix
Figura 2. XMPI
Un ejemplo sería:
1 node1 1
2 node2 1
3 node3 1
4 192.168.1.1 1
5 192.168.1.2 1
© FUOC • P07/M2103/02290 23 Clustering
setpe -w -f /etc/openmosix.map
Todos los UIDs (User IDs) y GIDs (Group IDs) del FS sobre cada nodo
del cluster deberán ser iguales (podría utilizarse OpenLdap para este fin).
Para montar el oMFS, se deberá modificar /etc/fstab con una entrada como:
mfs_mnt /mfs mfs dfsa = 1 0 0 y para habilitarlo o para inhibirlo: mfs_mnt /mfs
mfs dfsa = 0 0 0.
Los requisitos de cómputo necesarios para ciertas aplicaciones son tan grandes
que requieren miles de horas para poder ejecutarse en entornos de clusters. Ta-
les aplicaciones han promovido la generación de ordenadores virtuales en red,
metacomputers o grid computers. Esta tecnología ha permitido conectar entor-
nos de ejecución, redes de alta velocidad, bases de datos, instrumentos, etc.,
distribuidos geográficamente. Esto permite obtener una potencia de procesa-
miento que no sería económicamente posible de otra manera y con excelentes
resultados. Ejemplos de su aplicación son experimentos como el I-WAY net-
working (el cual conecta superordenadores de 17 sitios diferentes) en América
del Norte, o DataGrid, CrossGrid en Europa o IrisGrid en España. Estos meta-
computers o grid computers tienen mucho en común con los sistemas paralelos
y distribuidos (SPD), pero también difieren en aspectos importantes. Si bien
están conectados por redes, éstas pueden ser de diferentes características, no
se puede asegurar el servicio y están localizadas en dominios diferentes. El mo-
delo de programación y las interfaces deben ser radicalmente diferentes (con
respecto a la de los sistemas distribuidos) y adecuadas para el cómputo de altas
prestaciones. Al igual que en SPD, las aplicaciones de metacomputing requieren
una planificación de las comunicaciones para lograr las prestaciones deseadas;
pero dada su naturaleza dinámica, son necesarias nuevas herramientas y téc-
nicas. Es decir, mientras que el metacomputing puede formarse con la base de
los SPD, para éstos es necesario la creación de nuevas herramientas, mecanis-
mos y técnicas. [Fos]
Por lo tanto, grid computing es una nueva tecnología emergente, cuyo objetivo
es compartir recursos en Internet de manera uniforme, transparente, segura,
eficiente y fiable. Esta tecnología es complementaria a las anteriores, ya que
permite interconectar recursos en diferentes dominios de administración res-
petando sus políticas internas de seguridad y su software de gestión de recur-
sos en la intranet. Según unos de sus precursores, Ian Foster, en su artículo
“What is the Grid? A Three Point Checklist” (2002), un grid es un sistema que:
Entre los beneficios que presenta esta nueva tecnología, se pueden destacar el
alquiler de recursos, la amortización de recursos propios, gran potencia sin ne-
cesidad de invertir en recursos e instalaciones, colaboración/compartición en-
tre instituciones y organizaciones virtuales, etc.
© FUOC • P07/M2103/02290 27 Clustering
Figura 3
3.2. Globus
El proyecto Globus [Gloa, Glob] es uno de los más representativos en este sen-
tido, ya que es el precursor en el desarrollo de un toolkit para el metacomputing
o grid computing y que proporciona avances considerables en el área de la co-
municación, información, localización y planificación de recursos, autentifi-
cación y acceso a los datos. Es decir, Globus permite compartir recursos
localizados en diferentes dominios de administración, con diferentes políticas
de seguridad y gestión de recursos y está formado por un paquete software
(middleware), que incluye un conjunto de bibliotecas, servicios y API.
Figura 4
© FUOC • P07/M2103/02290 29 Clustering
El primer paso para tener Globus operativo es obtener el software (en este mo-
mento es Globus Toolkit 4), llamado GT4. Este software implementa los servi-
cios con una combinación entre C y Java (los componentes C sólo se pueden
ejecutar en plataformas UNIX GNU/ Linux generalmente) y es por ello por lo
que el software se divide por los servicios que ofrece. En función del sistema
que se quiera instalar se deberán obtener unos paquetes u otros.
http://www.globus.org/toolkit/docs/4.0/admin/docbook/
© FUOC • P07/M2103/02290 30 Clustering
© FUOC • P07/M2103/02290 31 Clustering
Actividades
1) Instalar PVM sobre un nodo y ejecutar el programa master.c y cliente.c dados como
ejemplos y observar su comportamiento a través de xpmv.
Lam-mpi: http://www.lam-mpi.org/
OpenMosix: http://openmosix.sourceforge.net/
Globus4: http://www.globus.org/toolkit/docs/4.0/
Bibliografía
[Aiv02] Tigran Aivazian (2002). “Linux Kernel 2.4 Internals”. The Linux Documentation Pro-
ject (guías).
[Ar01] Jonathan Corbet; Alessandro Rubini. Linux Device Drivers 2nd Editon. O’Reilly, 2001.
[Bac86] Maurice J. Bach (1986). The Design of the UNIX Operating System. Prentice Hall.
[Ban] Tobby Banerjee. “Linux Installation Strategies HOWTO”. The Linux Documentation
Project.
[Bas] Mike G. “BASH Programming - Introduction HOWTO”. The Linux Documentation Project.
[Bro] Scott Bronson (2001). “ VPN PPP-SSH”. The Linux Documentation Project.
[Bur02] Hal Burgiss (2002). “Security QuickStart HOWTO for Linux”. The Linux Documentation
Project.
[Com01] Douglas Comer (2001). TCP/IP Principios básicos, protocolos y arquitectura. Prentice
Hall.
[Coo] Mendel Cooper (2006). “Advanced bashScripting Guide”. The Linux Documentation
Project (guías).
[DBo] Marco Cesati; Daniel Bovet (2006). Understanding the Linux Kernel (3.ª ed.). O’Reilly.
[Dieb] Hank Dietz (2004). “Linux Parallel Processing”. The Linux Documentation Project.
[Dra] Joshua Drake (1999). “Linux Networking”. The Linux Documentation Project.
[Buy] Kris Buytaert y otros (2002). “The OpenMosix”. The Linux Documentation
Project.
[Fen02] Kevin Fenzi. “Linux security HOWTO”. The Linux Documentation Project.
[Fos] Ian Foster; Carl Kesselmany (2003). “Globus: A Metacomputing Infrastructure Tool-
kit”.
<http://www.globus.org>
[Gt] Dirk Allaert Grant Taylor. “The Linux Printing HOWTO”. The Linux Documentation Pro-
ject.
[Gon] Guido Gonzato. “From DOS/Windows to Linux HOWTO”. The Linux Documentation
Project.
[Gor] Paul Gortmaker (2003). “The Linux BootPrompt HOWTO”. The Linux Documentation Pro-
ject.
[Gre] Mark Grennan. “Firewall and Proxy Server HOWTO”. The Linux Documentation Project.
[Hen03] Bryan Henderson. “Linux Loadable Kernel Module HOWTO”. The Linux Docu-
mentation Project.
[Him01] Pekka Himanen (2001). La ética del hacker y el espíritu de la era de la información. Des-
tino.
[IET] IETF. “Repositorio de Request For Comment desarrollados por Internet Engineering
Task Force (IETF) en el Network Information Center (NIC)”.
<http://www.cis.ohio-state.edu/rfc/>
[Log] LogCheck.
<http://logcheck.org/>
[Joh98] Michael K. Johnson (1998). “Linux Information Sheet”. The Linux Documentation
Project.
[Kan] Ivan Kanis. “Multiboot with GRUB Mini-HOWTO”. The Linux Documentation Project.
[Kat] Jonathan Katz. “Linux + Windows HOWTO”. The Linux Documentation Project.
[KD00] Olaf Kirch; Terry Dawson. Linux Network Administrator’s Guide. O’Reilly Associates.
Y como e-book (free) en Free Software Foundation, Inc., 2000.
<http://www.tldp.org/guides.html>
[Kie] Robert Kiesling (1997). “The RCS (Revision Control System)”. The Linux Documentation Pro-
ject.
[Koe] Kristian Koehntopp. “Linux Partition HOWTO”. The Linux Documentation Project.
[Kuk] Thorsten Kukuk (2003). “The Linux NIS(YP)/NYS/NIS+”. The Linux Documentation Pro-
ject.
[Law07] David Lawyer (2007). “Linux Módem”. The Linux Documentation Project.
[Lan] Nicolai Langfeldt; Jamie Norrish (2001). “DNS”. The Linux Documentation Project.
[Maj96] Amir Majidimehr (1996). Optimizing UNIX for Performance. Prentice Hall.
[Mal07] Luiz Ernesto Pinheiro Malère (2007). “Ldap”. The Linux Documentation
Project.
[Mon] Monit.
<http://www.tildeslash.com/monit/>
[Mou01] Gerhard Mourani (2001). Securing and Optimizing Linux: The Ultimate Solution.
Open Network Architecture, Inc.
[Mun] Munin.
<http://munin.projects.linpro.no/>
[MRTG] MRTG.
<http://oss.oetiker.ch/mrtg/>
[Oke] Greg O’Keefe. “From Power Up To bash Prompt HOWTO”. The Linux Documentation
Project.
[OpenM] OpenMosix.
<http://openmosix.sourceforge.net/>
[PPP] Linux PPP (2000). “Corwin Williams, Joshua Drake and Robert Hart”. The Linux
Documentation Project.
[Pri] Steven Pritchard. “Linux Hardware HOWTO”. The Linux Documentation Project.
© FUOC • P07/M2103/02290 38 Clustering
[Proc] ProcMail.
<http://www.debian-administration.org/articles/242>
[ProX]Proxy Cache.
<http://www.squid-cache.org/>
[PS02] Ricardo Enríquez Pio Sierra (2002). Open Source. Anaya Multimedia.
[Ran] David Ranch (2005). “Linux IP Masquerade” y John Tapsell. Masquerading Made Sim-
ple. The Linux Documentation Project.
[Ray02a] Eric Raymond (2002). “UNIX and Internet Fundamentals”. The LinuxDocumentation
Project.
[Rayb] Eric Steven Raymond. “The Linux Installation HOWTO”. The Linux Documentation
Project.
[Rad] Jacek Radajewski; Douglas Eadline (2002). “Beowulf: Installation and Administra-
tion”. En: Kurt Swendson. Beowulf HOWTO (tlpd).
<http://www.sci.usq.edu.au/staff/jacek/beowulf>
[Rid] Daniel Lopez Ridruejo (2000). “The Linux Networking Overview”. The Linux Doc-
umentation Project.
[SM02] Michael Schwartz y otros (2002). Multitool Linux - Practical Uses for Open Source Soft-
ware. Addison Wesley.
© FUOC • P07/M2103/02290 39 Clustering
[Sal94] Peter H. Salus (1994). “25 aniversario de UNIX” (núm.1, noviembre). Byte España.
[Samb] Samba Guide (Chapter Adding Domain member Servers and Clients).
<http://samba.org/samba/docs/man/Samba-Guide/unixclients.html>
[Sta02] Richard Stallman (2002). “Discusión por Richard Stallman sobre la relación de GNU
y Linux”.
<http://www.gnu.org/gnu/linux-and-gnu.html>
[Stu] Michael Stutz. “The Linux Cookbook: Tips and Techniques for Everyday Use”. The Li-
nux Documentation Project (guías).
[Stei] Tony Steidler-Dennison (2005). Your Linux Server and Network. Sams.
[Sub] Subversion.
<http://subversion.tigris.org>
*[Sun02] Rahul Sundaram (2002). “The dosemu HOWTO”. The Linux Documentation Project.
[Tan06] Andrew Tanenbaum; Albert S. Woodhull (2006). The Minix Book: Operating Systems
Design and Implementation (3.ª ed.). Prentice Hall.
© FUOC • P07/M2103/02290 40 Clustering
[Tum02] Enkh Tumenbayar (2002). “Linux SMP HOWTO”. The Linux Documentation Project.
[USA] Dep. Justicia USA. “Division del Departamento de justicia de USA para el cibercrimen”.
<http://www.usdoj.gov/criminal/cybercrime/>
[Vah96] Uresh Vahalia (1996). UNIX Internals: The New Frontiers. Prentice Hall.
[Vasa] Alavoor Vasudevan (2003). “CVS-RCS (Source Code Control System)”. The Linux Do-
cumentation Project.
[Vasb] Alavoor Vasudevan. “The Linux Kernel HOWTO”. The Linux Documentation Project.
[Wm02] Matt Welsh y otros (2002). Running Linux 4th edition. O’Reilly.
[War] Ian Ward. “Debian and Windows Shared Printing mini-HOWTO”. The Linux Doc-
umentation Project.
[Zan] Renzo Zanelli. Win95 + WinNT + Linux multiboot using LILOmini-HOWTO. The Linux
Documentation Project.
© FUOC • P07/M2103/02290 41 Clustering
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330,
Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but
changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful
document “free” in the sense of freedom: to assure everyone the effective freedom to copy
and redistribute it, with or without modifying it, either commercially or noncommercially.
Secondarily, this License preserves for the author and publisher a way to get credit for their
work, while not being considered responsible for modifications made by others.
This License is a kind of “copyleft”, which means that derivative works of the document
must themselves be free in the same sense. It complements the GNU General Public License,
which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free
software needs free documentation: a free program should come with manuals providing the
same freedoms that the software does. But this License is not limited to software manuals; it
can be used for any textual work, regardless of subject matter or whether it is published as a
printed book. We recommend this License principally for works whose purpose is instruc-
tion or reference.
This License applies to any manual or other work, in any medium, that contains a notice
placed by the copyright holder saying it can be distributed under the terms of this License.
Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that
work under the conditions stated herein. The “Document”, below, refers to any such manual or
work. Any member of the public is a licensee, and is addressed as “you”. You accept the license
if you copy, modify or distribute the work in a way requiring permission under copyright law.
A “Modified Version” of the Document means any work containing the Document or a portion
of it, either copied verbatim, or with modifications and/or translated into another language.
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being
those of Invariant Sections, in the notice that says that the Document is released under this
License. If a section does not fit the above definition of Secondary then it is not allowed to
be designated as Invariant. The Document may contain zero Invariant Sections. If the Doc-
ument does not identify any Invariant Sections then there are none.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or
Back-Cover Texts, in the notice that says that the Document is released under this License.
A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
An image format is not Transparent if used for any substantial amount of text. A copy that
is not “Transparent” is called “Opaque”.
Examples of suitable formats for Transparent copies include plain ASCII without markup,
Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD,
and standard- conforming simple HTML, PostScript or PDF designed for human modifica-
tion. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats in-
clude proprietary formats that can be read and edited only by proprietary word processors,
SGML or XML for which the DTD and/or processing tools are not generally available, and
the machine-generated HTML, PostScript or PDF produced by some word processors for out-
put purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following pages as
are needed to hold, legibly, the material this License requires to appear in the title page. For
works in formats which do not have any title page as such, “Title Page” means the text near
the most prominent appearance of the work's title, preceding the beginning of the body of
the text.
A section “Entitled XYZ” means a named subunit of the Document whose title either is pre-
cisely XYZ or contains XYZ in parentheses following text that translates XYZ in another lan-
guage. (Here XYZ stands for a specific section name mentioned below, such as
“Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title”
of such a section when you modify the Document means that it remains a section “Entitled
XYZ” according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this
License applies to the Document. These Warranty Disclaimers are considered to be included
by reference in this License, but only as regards disclaiming warranties: any other implica-
tion that these Warranty Disclaimers may have is void and has no effect on the meaning of
this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or non-
commercially, provided that this License, the copyright notices, and the license notice say-
ing this License applies to the Document are reproduced in all copies, and that you add no
other conditions whatsoever to those of this License. You may not use technical measures to
obstruct or control the reading or further copying of the copies you make or distribute. How-
ever, you may accept compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly
display copies.
3. COPYING IN QUANTITY
have printed covers) of the Document, numbering more than 100, and the Document's li-
cense notice requires Cover Texts, you must enclose the copies in covers that carry, clearly
and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover
Texts on the back cover. Both covers must also clearly and legibly identify you as the pub-
lisher of these copies. The front cover must present the full title with all words of the title
equally prominent and visible. You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve the title of the Docu-
ment and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first
ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adja-
cent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you
must either include a machine- readable Transparent copy along with each Opaque copy, or
state in or with each Opaque copy a computer-network location from which the general net-
work-using public has access to download using public-standard network protocols a com-
plete Transparent copy of the Document, free of added material.
If you use the latter option, you must take reasonably prudent steps, when you begin distri-
bution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus
© FUOC • P07/M2103/02290 43 Clustering
accessible at the stated location until at least one year after the last time you distribute an
Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before
redistributing any large number of copies, to give them a chance to provide you with an up-
dated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of
sections 2 and 3 above, provided that you release the Modified Version under precisely this
License, with the Modified Version filling the role of the Document, thus licensing distribu-
tion and modification of the Modified Version to whoever possesses a copy of it. In addition,
you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document,
and from those of previous versions (which should, if there were any, be listed in the History
section of the Document). You may use the same title as a previous version if the original
publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for author-
ship of the modifications in the Modified Version, together with at least five of the principal
authors of the Document (all of its principal authors, if it has fewer than five), unless they
release you from this requirement.
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
E. Add an appropriate copyright notice for your modifications adjacent to the other copy-
right notices.
F. Include, immediately after the copyright notices, a license notice giving the public permis-
sion to use the Modified Version under the terms of this License, in the form shown in the
Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts
given in the Document's license notice.
I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at
least the title, year, new authors, and publisher of the Modified Version as given on the Title
Page. If there is no section Entitled “History” in the Document, create one stating the title,
year, authors, and publisher of the Document as given on its Title Page,
then add an item describing the Modified Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Trans-
parent copy of the Document, and likewise the network locations given in the Document for
previous versions it was based on. These may be placed in the “History” section. You may
omit a network location for a work that was published at least four years before the Docu-
ment itself, or if the original publisher of the version it refers to gives permission.
K. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the
section, and preserve in the section all the substance and tone of each of the contributor ac-
knowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their
titles. Section numbers or the equivalent are not considered part of the section titles.
M. Delete any section Entitled “Endorsements”. Such a section may not be included in the
Modified Version.
If the Modified Version includes new front-matter sections or appendices that qualify as Sec-
ondary Sections and contain no material copied from the Document, you may at your op-
© FUOC • P07/M2103/02290 44 Clustering
tion designate some or all of these sections as invariant. To do this, add their titles to the list
of Invariant Sections in the Modified Version's license notice. These titles must be distinct
from any other section titles.
You may add a section Entitled “Endorsements”, provided it contains nothing but endorse-
ments of your Modified Version by various parties--for example, statements of peer review
or that the text has been approved by an organization as the authoritative definition of a
standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25
words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version.
Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or
through arrangements made by) any one entity. If the Document already includes a cover
text for the same cover, previously added by you or by arrangement made by the same entity
you are acting on behalf of, you may not add another; but you may replace the old one, on
explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to
use their names for publicity for or to assert or imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under
the terms defined in section 4 above for modified versions, provided that you include in the
combination all of the Invariant Sections of all of the original documents, unmodified,
and list them all as Invariant Sections of your combined work in its license notice, and that
you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical In-
variant Sections may be replaced with a single copy. If there are multiple Invariant Sections
with the same name but different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original author or publisher of that
section if known, or else a unique number.
Make the same adjustment to the section titles in the list of Invariant Sections in the license
notice of the combined work.
In the combination, you must combine any sections Entitled “History” in the various origi-
nal documents, forming one section Entitled “History”; likewise combine any sections Enti-
tled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all
sections Entitled “Endorsements”.
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under
this License, and replace the individual copies of this License in the various documents with
a single copy that is included in the collection, provided that you follow the rules of this Li-
cense for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually un-
der this License, provided you insert a copy of this License into the extracted document, and
follow this License in all other respects regarding verbatim copying of that document.
A compilation of the Document or its derivatives with other separate and independent doc-
uments or works, in or on a volume of a storage or distribution medium, is called an “aggre-
gate” if the copyright resulting from the compilation is not used to limit the legal rights of
the compilation's users beyond what the individual works permit.
When the Document is included in an aggregate, this License does not apply to the other
works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document,
then if the Document is less than one half of the entire aggregate, the Document's Cover
Texts may be placed on covers that bracket the Document within the aggregate, or the elec-
tronic equivalent of covers if the Document is in electronic form.
Otherwise they must appear on printed covers that bracket the whole aggregate.
© FUOC • P07/M2103/02290 45 Clustering
8. TRANSLATION
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly pro-
vided for under this License. Any other attempt to copy, modify, sublicense or distribute the
Document is void, and will automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this License will not have their
licenses terminated so long as such parties remain in full compliance.
the GNU Free Documentation License from time to time. Such new versions will be similar
in spirit to the present version, but may differ in detail to address new problems or concerns.
See http:// www.gnu.org/copyleft/.
If the Document specifies that a particular numbered version of this License “or any later ver-
sion” applies to it, you have the option of following the terms and conditions either of that
specified version or
of any later version that has been published (not as a draft) by the
Free Software Foundation. If the Document does not specify a version number of this Li-
cense, you may choose any version ever published (not as a draft) by the Free Software Foun-
dation.
To use this License in a document you have written, include a copy of the License in the doc-
ument and put the following copyright and license notices just after the title page:
Permission is granted to copy, distribute and/or modify this document under the terms of
the GNU Free Documentation License, Version 1.2 or any later version published by the Free
Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts.
A copy of the license is included in the section entitled “GNU Free Documentation License”.
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the
“with...Texts.” line with this:
with the Invariant Sections being LIST THEIR TITLES, with the Front- Cover Texts being LIST,
and with the Back-Cover Texts being LIST.
If you have Invariant Sections without Cover Texts, or some other combination of the three,
merge those two alternatives to suit the situation.