Académique Documents
Professionnel Documents
Culture Documents
Administración de
Compilado por:
Sandra Sauza Escoto
ÍNDICE
1. INICIAR UNA SESIÓN ................................................................................................ 1
1.1 Elementos básicos de la cuenta de un usuario ................................................................. 1
1.2 Inicio de una sesión de escritorio ...................................................................................... 2
1.3 Cambio de contraseña ...................................................................................................... 2
1.4 Para finalizar la sesión ...................................................................................................... 3
2. COMANDOS BÁSICOS............................................................................................... 4
2.1 Comandos, opciones y argumentos .................................................................................. 4
2.2 Comandos básicos ........................................................................................................... 4
2.2.1 pwd...................................................................................................................................................... 5
2.2.2 ls .......................................................................................................................................................... 5
2.2.3 comodines o metacaracteres ............................................................................................................ 5
2.2.4 cd......................................................................................................................................................... 6
2.2.5 cp......................................................................................................................................................... 6
2.2.6 mkdir ................................................................................................................................................... 6
2.2.7 rm, rmdir ............................................................................................................................................. 7
2.2.8 more .................................................................................................................................................... 7
2.2.9 cat........................................................................................................................................................ 8
2.2.10 date ................................................................................................................................................... 9
2.2.11 touch ............................................................................................................................................... 10
2.3 Entrecomillas y comodines ............................................................................................. 10
4. EDITOR VI................................................................................................................. 17
6. PROCESOS .............................................................................................................. 30
6.1 Definición ........................................................................................................................ 30
6.2 Listar procesos................................................................................................................ 30
6.3 Señales........................................................................................................................... 32
6.5 Procesos en 1ro y 2do plano........................................................................................... 33
BIBLIOGRAFÍA............................................................................................................ 148
Referencias ........................................................................................................................ 148
1
passwd
passwd [OPCIONES] [NOMBRE]
cambia la contraseña del usuario. El superusuario puede cambiar las contraseñas de otros
usuarios. En general, las contraseñas deben tener entre 6 y 8 caracteres, contener mayúsculas,
minúsculas, dígitos 0 a 9 o signos de puntuación; no se admiten contraseñas simples ni
parecidas al nombre del usuario. Si el superusuario asigna contraseñas poco seguras no hay
advertencia.
-x M máximo número de días de validez; luego pide cambiar
-n M mínimo número de días antes de poder cambiar
-n M número de días de advertencia antes de expirar
Passwd
permite cambiar la contraseña del usuario invocante
passwd cursosolaris10
(su) cambia la contraseña del usuario cursosolaris10
Administración de Sistemas Unix de Misión Crítica 3
2. COMANDOS BÁSICOS
Un comando se puede considerar como un programa del sistema operativo que realiza una
acción determinada, es decir, que hace algo. Los comandos pueden llevar opciones,
argumentos o no, y en caso de llevarlas han de ir separadas por espacios o tabuladores. UNIX
es un sistema operativo, a diferencia de DOS, en donde se diferencia entre mayúsculas y
minúsculas, y en donde por tanto habrá que prestar especial cuidado a la hora de introducir los
comandos. Por lo general los comandos suelen escribirse en minúsculas.
2.2.1 pwd
Imprime toda la ruta del directorio corriente; todos los componentes mostrados serán los
directorios reales, no enlaces simbólicos.
2.2.2 ls
ls [OPCIONES] [NOMBRE]
Para cada nombre de directorio, lista contenido de directorio; para cada nombre de archivo,
indica su nombre y datos. La salida está ordenada alfabéticamente por defecto. Sin nombre,
lista el directorio corriente. La opción l muestra, separados por espacios, los campos tipo
archivo y permisos, cantidad de enlaces o ligas duras (hard), dueño, grupo, tamaño, mes, día,
hora o año, nombre.
-1 un nombre de archivo por línea
-a todos los archivos, incluso no visibles comenzados por .
-c ordenar por fecha de estado de último cambio (ctime en inodo)
-C salida en columnas con ordenamiento por columnas
-d lista directorios como archivos, no su contenido
-F indica tipo: / directorio, * ejecutable, @ enlace simbólico
-i inodo, número de índice de cada archivo
-k tamaños en KB
-l listado en formato largo
-r invertir ordenamiento
-R listar recursivamente subdirectorios
-s tamaño en bloques de 1024 bytes
-t ordenar por fecha de última modificación (mtime en inodo)
-u ordenar por fecha de último acceso (atime en inodo)
-U no ordenar
-x salida en columnas con ordenamiento por filas
2.2.4 cd
cd [DIRECTORIO]
cambia directorio de trabajo; sin parámetros, cambia al directorio propio del usuario como
aparece en
cd /etc
cd
2.2.5 cp
2.2.6 mkdir
-p crea primero todos los directorios padre inexistentes, con el modo de umask modificado
con u+wx
--verbose informa sobre la creación de directorios
mkdir dir1 dir2
mkdir -p ltr/jd/jan
crea la estructura de directorios ltr/jd/jan.
rmdir
rmdir [OPCIONES] DIRECTORIO ...
elimina directorios vacíos.
-p elimina directorios padre si quedan vacíos
rmdir dir2
rmdir -p dir1/subdir11/subdir111
2.2.8 more
2.2.9 cat
2.2.10 date
2.2.11 touch
2 .3 Entrecomillas y comodines
comillas
‘ ....’ Impide que el shell interprete la cadena marcada.
“ ...” Impide que el shell interprete la cadena marcada excepto $, dobles y simples
comillas y \
comodines
*: generaliza un conjunto de caracteres.
- ?: sustituye a un único carácter.
- [ ]: sustituyen un único carácter por cualquiera del grupo o rango de caracteres que se
encuentren entre los corchetes.
Administración de Sistemas Unix de Misión Crítica 11
♦ Archivos de directorio:
Son archivos que contienen referencias a otros archivos o directorios. El primer directorio
es el raíz (root) que se representa por el símbolo “/”. De él cuelgan los directorios etc,
home, bin, lib, etc.
Para movernos por los directorios podemos usar el path absoluto o relativo. Cuando el
path es absoluto comenzaremos por el directorio raíz. Cuando es relativo, estamos
dando el camino referido a la posición donde se encuentra el usuario.
. referencia al directorio actual .. referencia al directorio padre
Nota: el path absoluto va precedido por la barra (/) y el relativo no.
♦ Archivos FIFO:
Se suelen utilizar por ciertos programas de aplicación como un fichero temporal en el
cual los datos de escriben por un lado y se leen por otro. Típicamente no suelen tener un
tamaño mayor que 0, ya que en cuanto los datos son leídos se eliminan del fichero.
♦ Archivos especiales:
Representan a dispositivos periféricos (ej: partición de disco, terminal, impresora,...).
Existen dos tipos:
- De tipo bloque: la comunicación se realiza mediante el buffer (bloque a bloque).
- De tipo carácter: la comunicación se realiza byte a byte.
Estos tipos de archivos no contienen información sino una referencia a las rutinas drivers
del Kernel que los maneja. Los archivos especiales se encuentran colgando del
directorio /dev.
♦ Archivos Sockets:
Los "sockets" o "enchufes" permiten la comunicación entre procesos, muchas veces a
través de la red. Los sockets de dominio son propios de una máquina; se los referencia
como objetos de un sistema de archivos y no como puertos de red. Los archivos "socket"
sólo pueden ser leídos o escritos por los procesos involucrados en la comunicación,
aunque son visibles como entradas de directorio. Los sockets de dominio se crean con la
llamada al sistema socket(); se eliminan con rm, o con la llamada al sistema unlink() si ya
no tienen usuarios.
Identificador para cada tipo de archivo:
d directorio
l enlace simbólico
- archivo normal
b archivo controlador de dispositivo orientado a bloques
c archivo control de dispositivo orientado a caracteres
p archivo tipo FIFO o entubamiento
s archivo tipo socket
ls [OPCIONES] [NOMBRE]
Para cada nombre de directorio, lista contenido de directorio; para cada nombre de archivo,
indica su nombre y datos. La salida está ordenada alfabéticamente por defecto. Sin nombre,
lista el directorio corriente. La opción l muestra, separados por espacios, los campos tipo
archivo y permisos, cantidad de enlaces o ligas duras (hard), dueño, grupo, tamaño, mes, día,
hora o año, nombre.
-1 un nombre de archivo por línea
-a todos los archivos, incluso no visibles comenzados por .
-c ordenar por fecha de estado de último cambio (ctime en inodo)
-C salida en columnas con ordenamiento por columnas
-d lista directorios como archivos, no su contenido
-F indica tipo: / directorio, * ejecutable, @ enlace simbólico
-i inodo, número de índice de cada archivo
-k tamaños en KB
-l listado en formato largo
Administración de Sistemas Unix de Misión Crítica 13
-r invertir ordenamiento
-R listar recursivamente subdirectorios
-s tamaño en bloques de 1024 bytes
-t ordenar por fecha de última modificación (mtime en inodo)
-u ordenar por fecha de último acceso (atime en inodo)
-U no ordenar
-x salida en columnas con ordenamiento por filas
3.3 chomod
Sirve para cambiar los permisos de escritura, lectura y ejecución de una archivo o directorio.
Solo el creador del archivo o directorio puede cambiar dichos permisos.
No cambia los permisos de los enlaces simbólicos.
Sintaxis:
chmod nuevo-modo [ archivos ] [ directorios ]
Compilado por: Sandra Sauza Escoto 14
Opciones:
-v verboso, describe acción sobre cada archivo.
-R recursivo, cambia permisos de subdirectorios y sus contenidos
Existen dos formas de especificar el nuevo modo:
1. en octal: chmod ooo archivo
2. en modo simbolico: chmod [ ugoa ] [ = -] [ rwx ] + donde
u permisos del usuario
g permisos del grupo
o permisos de los otros
a todos los permisos
Ejemplo
chmod -R 0755 documentos/visibles
chmod ug+rw-x,o+r-wx cap*.txt
3.4 chgrp
Permite cambiar el grupo al que pertenece el archivo o directorio
Sintaxis
chgrp nuevo-grupo [ archivos ] [ directorios ]
Opciones:
-R recursivo
Donde nuevo-grupo es el nombre del grupo o gid. Los usuarios que no pertenecen al grupo de
root o superuser deben pertenecer a ambos grupos, el actual y al que quieren cambiar.
Ejemplo:
chgrp dgsca notas
3.5 chow n
Sirve para cambiar el dueño de archivos y directorios
Sintaxis:
chown nuevo-dueño [ archivos ] [ directorios ]
Administración de Sistemas Unix de Misión Crítica 15
Opciones:
-R recursivo, cambia permisos de subdirectorios y sus contenidos
-h actua, sobre la liga y No sobre el archivo al que apunta.
Ejemplo
chown ssauza notas
4. EDITOR VI
El editor vi es un editor de texto de pantalla completa que maneja en memoria el texto entero de
un archivo. Es el editor clásico de UNIX; está en todas las versiones. Puede usarse en cualquier
tipo de terminal con un mínimo de teclas; esto lo hace difícil de usar hasta que uno se
acostumbra.
Existe un editor vi ampliado llamado vim que contiene facilidades adicionales, así como diversas
versiones del vi original. En todos los casos, el conjunto de comandos básicos es el mismo.
Existen en UNIX otros editores más potentes y versátiles, como emacs, que provee un
ambiente de trabajo completo; también versiones fáciles de manejar como jove o pico, o aún
mínimas e inmediatas como ae. En ambiente X-Windows hay muchos editores amigables,
fáciles de usar y con múltiples capacidades. No obstante, vi está en todos los UNIX, requiere
pocos recursos, se usa mucho en administración, para programar y en situaciones de
emergencia. En casos de roturas de discos, corrupción de sistemas de archivos, errores en el
arranque y otras catástrofes, puede ser el único editor disponible. Como la mayoría de las
configuraciones en UNIX se manejan editando archivos, disponer de esta capacidad es esencial
en la administración de un sistema.
Modos
Existen tres modos o estados en vi:
modo comando: las teclas ejecutan acciones que permiten desplazar el cursor, recorrer
el archivo, ejecutar comandos de manejo del texto y salir del editor. Es el modo inicial de
vi.
modo texto o modo inserción: las teclas ingresan caracteres en el texto.
modo última línea o ex: las teclas se usan para escribir comandos en la última línea al
final de la pantalla.
Con unos pocos comandos básicos se puede ya trabajar en vi editando y salvando un texto:
Invocación
Modo Edicion
comando a texto:
teclas de inserción i I a A o O, o
tecla de sobreescritura R.
texto a comando:
tecla ESC.
comando a última línea:
teclas : / ?
última línea a comando:
tecla ENTER (al finalizar el comando), o
Administración de Sistemas Unix de Misión Crítica 19
Modo Comando
El editor vi, al igual que todo UNIX, diferencia mayúsculas y minúsculas. Confundir un
comando en minúscula digitando uno en mayúscula suele tener consecuencias catastróficas.
Se aconseja evitar sistemáticamente el uso de la traba de mayúsculas; mantener el teclado en
minúsculas.
Números multiplicadores
Muchos comandos aceptan un número multiplicador antes del comando. La acción es idéntica a
invocar el comando tantas veces como indica el multiplicador. Ejemplos:
10j
en modo comando avanza 10 líneas;
5Y
copia 5 líneas y las retiene para luego pegar.
Ejemplos
Los siguientes ejemplos de manejo asumen que el editor se encuentra en modo comando.
$ fin de línea
0 principio de línea
M al medio de la pantalla
Control de pantalla
Borrar
Copiar y pegar
Y o yy copiar línea
yw copiar palabra
Búsqueda
La acción de f, F, t y T alcanza sólo a la línea actual; si el carácter buscado no está en esa línea
el cursor no se mueve.
Reemplazo
Estos comandos admiten multiplicadores: un número delante del comando. Al dar un comando
de reemplazo el editor coloca un símbolo $ en donde termina el pedido de reemplazo. El
usuario escribe normalmente, sobreescribiendo, hasta donde necesite, y sale con ESC. Estos
comandos admiten multiplicadores: 3cw abre un área de reemplazo para 3 palabras.
c reemplaza caracteres
cw reemplaza palabras
:w guardar cambios
Mover
:1 mueve a línea 1
Opciones
Reemplazo
La sintaxis del comando de búsqueda y reemplazo es la siguiente:
:<desde>,<hasta>s/<buscar>/<reemplazar>/g
<desde>, <hasta> indican líneas en el archivo; <buscar> y <reemplazar> son cadenas de
caracteres o expresiones regulares; / es un separador, s (sustituir) y g (global) son letras de
comando para el manejo de expresiones regulares.
:1,$s/Martes/martes/g
cambia Martes por martes en todo el archivo.
:.,5s/ayuda/&ndo/g
cambia ayuda por ayudando desde línea actual hasta la 5a. línea.
Administración de Sistemas Unix de Misión Crítica 25
5 .1 fi nger
$finger Más información sobre un usuario determinado, ya sea que estén o no
conectados al sistemas.
5.2 who
$who Nombre de usuario , fecha y hora de conexión y otra operaciones. (para saber
si esta abierta la comunicación )
5.3 w
Este comando informa quien se encuentra conectado en el sistema y trata de decirnos que esta
haciendo, es decir, que comando esta ejecutando.
5.4 tal k
Conectar dos terminales conectadas en el mismo equipo o en equipos remotos.
Sintaxis:
talk login tty
Salir CTRL + D
Compilado por: Sandra Sauza Escoto 26
5.5 w rite
$write permite comunicarse con otros usuarios que se encuentren conectados al
sistema.
Nota: solo en el mismo sistema.
Sintaxis:
$write login tty
5.6 FTP
FTP es el protocolo utilizado para la transferencia de ficheros entre nodos. El formato del
comando es:
ftp servidor
La siguiente tabla muestra los comandos más utilizados en este cliente básico para FTP (común
a todas las versiones de UNIX):
Si no se utiliza la opción -l, rlogin conectará al usuario a la máquina distante con el mismo
nombre que tiene en la máquina local. Los valores de las variables de ambiente USER y TERM
son pasadas al programa login de la computadora distante.
Las peticiones de rlogin pueden estar precedidas del carácter ~ (tilde) y solo son efectivas si
son el primer carácter de una línea, (después de un <RETURN>): 3directorio en el cual el
usuario es posicionado cuando entra por primera vez al sistema (conocido también como
directorio HOME).
_ ~. cierra la conexión
_ ~<crl><z> suspende la conexión
_ ~~ envía un ~
Este comando, como todos el resto de los comandos-r no funciona si alguna de las dos
máquinas no trabaja bajo el sistema Unix.
5 . 9 ssh
Permite la conexión segura de archivos entre equipos remotos, llega a sustituir a telnet en la
versión segura
Ejemplo
ssh ssauza@tequila.dgsca.unam.mx
5.10 scp
Permite la transferencia segura de archivos entre equipos remotos, llega a sustituir a ftp en la
versión segura
Ejemplo
Remoto a local
scp ssauza@tequila.dgsca.unam.mx:/ruta/del/directorio/remoto ruta/del/directorio/local
Local a remoto
scp archivo-local ssauza@tequila.dgsca.unam.mx:/ruta/del/directorio/remoto
Compilado por: Sandra Sauza Escoto 30
6 . PROCESOS
Envia una señal al proceso. Cuando se utiliza sin argumentos la orden kill envia la señal
15 al proceso (Terminación software).
Existen procesos exentos a esta señal, estos proceos se eliminan utilizando la señal –9
(Eliminación incondicional).
Eliminan todos los procesos creados creados durante una sesión.
$kill 0
Opciones de ps
-f Listado completo de procesos
UID
PID
PPID
C Indice de utilización de CPU.
STIME Tiempo desde el inicio de la ejecución.
TTY Terminal asociado.
TIME Tiempo acumulado de CPU.
COMMAND
-l Formato largo
Campo F Caracteristicas del proceso
Campo Estado de un proceso
O P. Ejecución.
S P. Durmiendo.
R Ej en cola
I Inactivo en creación.
Z zombie
6.3 Señales
Las señales de Unix son un mecanismo para anunciar a un proceso que ha sucedido cierto
evento que debe ser atendido.
La recepción de una señal en particular por parte de un proceso provoca que se ejecute una
subrutina encargada de atenderla. A esa rutina se le llama el "manejador" de la señal (signal
handler). Un proceso puede definir un manejador diferente para sus señales o dejar que el
kernel tome las acciones predeterminadas para cada señal.
Cuando un proceso define un manejador para cierta señal se dice que "captura" (catch) esa
señal. Si se desea evitar que determinada señal sea recibida por un proceso se puede solicitar
que dicha señal sea ignorada o bloqueada.
Una señal ignorada simplemente se descarta sin ningún efecto posterior. Cuando alguien envía
a cierto proceso una señal que está bloqueada la solicitud se mantiene encolada hasta que esa
señal es explícitamente desbloqueada para ese proceso.
Cuando la señal es desbloqueada la rutina de manejo de la señal es invocada una sola vez
aunque la señal haya sido recibida más de una vez mientras estaba bloqueada.
Si bien un proceso tiene ciertas libertades para configurar como reacciona frente a una señal
(capturando, bloqueando o ignorando la señal), el kernel se reserva ciertos derechos sobre
algunas señales.
Así, las señales llamadas KILL y STOP no pueden ser capturadas, ni bloqueadas, ni ignoradas
y la señal CONT no puede ser bloqueada.
La señal KILL provoca la terminación de un proceso.
La señal STOP provoca la detención del proceso que queda en el estado "stopped" hasta que
alguien le envíe la señal CONT.
Una señal puede enviarse desde un programa utilizando llamadas al sistema operativo, o desde
la línea de comandos de un shell utilizando el comando kill.
Al comando kill se le pasa como parámetro el número o nombre de la señal y el PID del
proceso. El uso más habitual del comando es para enviar una señal TERM o KILL para terminar
un proceso, de ahí su nombre.
La lista de posibles señales puede obtenerse para cada sistema a través del man del comando
kill o de la función kill() del sistema operativo. En la tabla se listan las utilizadas más a menudo
por un administrador.
Administración de Sistemas Unix de Misión Crítica 33
SIGCONT
SIGUSR Definidas por el usuario o más bien por quien programó el proceso
Ejemplo
$cat f1 f2 f3 > f4 & {Se indica que la tarea se va a realizar en background}
7 . GENERALIDADES DE S HELLS
7.1 Introducci ón
Cuando un usuario comienza una sesión de Unix se dice que ya entra en un shell o intérprete
de comandos el cual interpreta los comandos según su propia sintaxis. Después de que el shell
interpreta el comando, el UNIX lo llama y ejecuta. Una vez que un programa ha sido llamado y
ejecutado se dice que el proceso ha concluido.
csh
setenv VAR valor (define)
unsetenv VAR (elimina)
sh
set VAR=valor (define)
export VAR
unset VAR (elimina)
sh
set var=valor
unset var
csh
set vari=valor
unset var
Administración de Sistemas Unix de Misión Crítica 37
7 .6 Programas de S hell
SENTENCIAS DE PROGRAMACIÓN
Orden if
If orden
Then
Orden(es)
Fi
Else
Orden(es)
Fi
If orden
Then
Ordenes
Elif orden
Then
Ordenes
Ej
If mkdir –p $HOME/D1/D11
Then
Echo Creación correcta.
Else
Echo No se pudo crear directorios
Exit 1
Fi
Orden Test
Permite comparar ficheros, números o cadenas.
If test –w f1
Then
Rm f1
Else
Echo fichero protegido
Fi
Opciones de test:
A) Para ficheros:
-a Existe
-r Exist y perm lect
-w Exist y perm escritura.
-x Exist y perm ejecución
Compilado por: Sandra Sauza Escoto 40
orden(es)
done
La variable i puede ser cualquier nombre que se elija
Si se omite la parte in lista de la sentencia el bucle se ejecutará una vez para cada
parametro posicional.
Tambian se puede especificar la repetición un número determinado de veces
especificando este en la lista.
For i in 1 2 3 4 5
Do
Orden(es)
Done
Se pueden anidar bucles
For i
Do
For var
In 1 2
Do
Proof $i
Done
Done
Cuando se le indica un asterisco en la lista si hay variables definidas se utilizan como
entradas sichas variables y si no se utilizan las entradas del directorio actual.
Sentencias While y Until
While ordenes1
Do
Ordenes 2
Done
Until orden
Do
Orden(es)
done
Compilado por: Sandra Sauza Escoto 42
while true
do
done &
until false
do
done &
Ej.-
While true
Do
If [-n $MAIL]
Then
Echo You Have mail
Fi
Sleep 30
Done &
Sentencia Shift
$shift Rueda de partametros. Salta parametros a la derecha.
Sentencia Case
Case $var in
a) ordenes
;;
b) Ordenes
;;
*) Ordenes
;;
esac
En el patron se puede usar todo tipo de comodines.
Administración de Sistemas Unix de Misión Crítica 43
Sentencia Select
La orden slect visuliza una serie de elementos sobre el error estandar y espera entrada.
Si el usuario pulsa INTRO sin realizar seleccción la lista de elementos se visualiza de
nuevohasta que se le da una respuesta.
Orden especialmente apropiada para la realización de menus
A) Definir el prompt para el select
PS3 = “¿Qué opción desea?”
Select i | var in att cancept dec hp
do
case $var in
att) TERM=360
break
;;
concept) TERM=C108
break
;;
dec) TERM=vt100
break
;;
hp) TERM=hp2612
break
;;
esac
done
export TERM
Compilado por: Sandra Sauza Escoto 44
Sentencia Exit
Salida del programa al shellprincipal, independientemente del subshell en que se encuentre.
Sentencia Break
Sale de unnúmero determinado de shell’s. El numero de shell’s le es indicado con un parametro
entero.
Tambien hace salir del bucle que lo engloba inmediatamente o el numero de blucles que le
indiquemos con el parametro entero.
Break nn
Sentencia Continue
Salta iteraciones dentro de un bucle.
Slat el número de iteraciones que se le indique con el parametro entero y por defecto es
una.
Administración de Sistemas Unix de Misión Crítica 45
Dispositivos y medios.
Las causas de pérdida de datos generan los siguientes requisitos de respaldo:
uso de un medio removible, utilizable en otra máquina; los daños o fallas pueden afectar
varias partes de hardware al mismo tiempo, impidiendo la utilización de la máquina
original.
conservación de los respaldos en un lugar físico suficientemente apartado. Existen
actualmente empresas para realizar respaldos vía Internet, pero la mayoría de las
instituciones conservan sus respaldos localmente.
La inmensa mayoría de los dispositivos de respaldo son de tipo magnético. Esto los hace
vulnerables a la proximidad de elementos generadores de campos magnéticos. Los respaldos
deben mantenerse apartados de dispositivos tales como parlantes de audio, transformadores de
pared, acondicionadores de línea, unidades de potencia ininterrumpida (UPSs), unidades de
disco o disquetera no confinados en gabinetes metálicos, monitores aún apagados, detectores
de metales como los usados en los aeropuertos. El campo magnético terrestre termina, con el
tiempo, afectando los medios magnéticos de grabación; esto limita la duración efectiva de los
respaldos; para períodos largos, se aconseja usar medios ópticos o regrabar periódicamente.
Puede asumirse una duración de 3 años para los medios magnéticos.
Muchos fabricantes de unidades de respaldo proveen compresión incorporada, citando el
almacenamiento y la velocidad de transferencia en la presunción optimista de un 2 a 1. En
términos reales sólo puede asumirse la capacidad real en bytes de la cinta, y la velocidad de
transferencia de esa misma cantidad de bytes. En principio no puede asegurarse compresión
alguna sin conocimiento previo del tipo de datos.
Acceso
Medio Capacidad Reuso Comentarios
aleatorio
Acceso
Medio Capacidad Reuso Comentarios
aleatorio
Existen cintas de nueva tecnología, con mejoras en capacidad, precio, transferencia o duración:
Travan (varios fabricantes), ADR (OnStream), DLT (Quantum), AIT (Sony), Mammoth (Exabyte);
verificar soporte para el hardware en la versión de UNIX a utilizar. DAT y Exabyte son
soluciones baratas para la mayoría de las empresas chicas y medianas; DLT, AIT y Mammoth
están orientadas a grandes corporaciones o universidades.
Existen diversos tipos de equipo para cambio automático de volúmenes, de alto costo y con
software propio, en capacidades de terabytes. Una adecuada partición en sistemas de archivo,
un cronograma adecuado y un poco de paciencia permiten respaldar un sistema con razonable
esfuerzo.
Régimen de respaldo incremental.
Los comandos tradicionales de respaldo y recuperación son dump y restore. Según los
sistemas, pueden tener nombres similares (ufsdump, ufsrestore en Solaris). Otros comandos
también tradicionales son tar y cpio, con múltiples opciones de control adaptables a variadas
necesidades.
Respaldo de un sistema de archivos.
El comando dump recorre el sistema de archivos haciendo una lista de los archivos modificados
o nuevos desde una corrida anterior de dump; luego empaqueta todos esos archivos en uno
solo y lo vuelca en un dispositivo externo tal como una cinta. Exhibe estas características:
soporta multivolumen;
soporta todo tipo de archivo, incluso de dispositivos;
conserva permisos, dueños y fecha de modificación;
Administración de Sistemas Unix de Misión Crítica 49
crea un respaldo nivel 0 del sistema de archivos /usr usando el dispositivo de cinta con
rebobinado /dev/st0 (opción f) actualizando /etc/dumpdates (opción u).
#dump 3uf /dev/st0 /usr
crea un respaldo nivel 0 del sistema de archivos /usr usando el dispositivo de cinta no
rebobinado /dev/nrst0, para reiterar el comando y colocar varios respaldos en una misma cinta.
Los dispositivos de cinta suelen tener dos archivos de dispositivo, uno con rebobinado
automático (/dev/st0) y otro sin rebobinado (/dev/nst0); ambos se refieren al mismo dispositivo
físico.
El manejo de la unidad de cinta se hace con el comando mt.
# rdump 0uf pino:/dev/rtape /usr
crea un respaldo nivel 0 del sistema de archivos /usr usando el dispositivo remoto /dev/rtape en
la máquina pino. El acceso a la cinta remota es controlado por el archivo .rhosts de la máquina
remota.
Si no se confía en la privacidad de la red puede convenir más implementar un túnel seguro con
ssh.
Compilado por: Sandra Sauza Escoto 50
El respaldo en cinta requiere conocer su tamaño y características. El fin de cinta (EOT, End Of
Tape) es generalmente detectado, para habilitar los respaldos multivolumen. Un error en el
largo de cinta o en la elección de dispositivo rebobinado puede arruinar el respaldo.
# dump 5usdf 60000 6250 /dev/st0 /trabajos
indica un largo de cinta ficticio de 60000 pies (opción s, size), densidad de grabación 6250 dpi
(opción d, densidad), para engañar una versión dump incapaz de reconocer cintas de más de
1.5 GB (DAT DDS-1); como además se comprime, se confía en la capacidad de dump para
recibir la señal EOT en una cinta con capacidad en exceso.
#ufsdump 0uf /dev/rmt2 /dev/rdsk/c0t3d0s5
crea un respaldo nivel 0 con el comando ufsdump (Solaris), del sistema de archivos sobre el
dispositivo crudo /dev/rdsk/c0t3d0s5; algunas versiones no aceptan el punto de montaje.
Desgraciadamente, el comando dump en Solaris existe, pero su propósito es examinar archivos
objeto, lo cual induce a error a muchos administradores honestos.
Esquemas de respaldo.
Los niveles de respaldo pueden elegirse arbitrariamente; sólo tienen sentido respecto de un
respaldo de nivel menor. Un esquema de respaldo se define en función de
actividad de cada sistema de archivos;
capacidad del dispositivo de respaldo;
redundancia deseada;
cantidad de volúmenes;
complejidad operativa.
Si el sistema de archivos cabe en un volumen, puede hacerse un nivel 0 diario (o semanal), con
un grupo de cintas que se va reutilizando; cada N días, la cinta se conserva. Este esquema
presenta redundancia masiva y es fácil para restaurar
Un esquema más optimizado consiste en realizar un nivel 9 diario (7 cintas), un nivel 5 semanal
(5 cintas), un nivel 3 mensual (12 cintas), un nivel 0 cuando ya no alcanza un volumen o al
menos una vez al año.
El esquema clásico más completo de respaldo tiene conexión con el algoritmo matemático de
las Torres de Hanoi. Equilibra la aspiración de retener la mayor información posible por el mayor
tiempo posible con limitaciones prácticas como el número de cintas y el tiempo disponible.
Emplea los 9 niveles, el 0 se conserva, y reitera el ciclo cada 45 días. Este esquema suele ser
demasiado complicado aún para sistemas grandes, aunque provee excelente redundancia;
también es complicado restaurar.
>> 0 > 3 > 2 > 5 > 4 > 7 > 6 > 9 > 8
> 1A > 3 > 2 > 5 > 4 > 7 > 6 > 9 > 8
> 1B > 3 > 2 > 5 > 4 > 7 > 6 > 9 > 8
> 1C > 3 > 2 > 5 > 4 > 7 > 6 > 9 > 8
> 1D > 3 > 2 > 5 > 4 > 7 > 6 > 9 > 8
Administración de Sistemas Unix de Misión Crítica 51
Elección de un esquema.
Dado que una gran parte de los archivos no cambian, el esquema incremental más simple ya
elimina un gran volumen del respaldo diario. La inserción de niveles divide aún más finamente
en grupos los archivos activos. El respaldo incremental permite respaldos más frecuentes con
menos cintas, más alguna redundancia por repetición de archivos. El esquema de respaldo
elegido surge de evaluar estas condiciones.
Recomendaciones generales.
Las siguientes recomendaciones ayudan a tener un mejor control y organización sobre los
respaldos.
Respaldar todo desde la misma máquina: Es decir, en el mejor de los casos tener un
servidor de respaldos como primera opción y adicional respaldos en cintas, aunque es
más lento e implica más trabajo, nos puede sacar de serios
Etiquetar las cintas: fecha, hora, máquina, sistema de archivos que contiene la cinta.
Intervalo de respaldos razonable: el sistema de archivos de usuarios puede
respaldarse a diario en sistemas grandes, o semanalmente en sistemas chicos, tomando
en cuenta la frecuencia con que la información contenido en dichos sistemas de archivos
es cambiada; la frecuencia de respaldo para otros sistemas de archivos dependerán del
uso y la prioridad de los mismos..
Elegir sistemas de archivo: según el movimiento, cada sistema de archivos puede
tener un esquema diferente. Un grupo de archivos muy activo en un sistema de archivos
inactivo puede copiarse diariamente hacia otro sistema de archivos con respaldo diario.
Sistemas de archivos de noticias, o el sistema de archivos /tmp, no deben respaldarse.
Respaldos diarios en un solo volumen: buscar un esquema o un medio para que el
respaldo diario quepa en un solo volumen; es la única forma simple de realizar un
respaldo diario, cargando la cinta a última hora y ejecutando el respaldo en cron.
Recordar: el respaldo de varios sistemas de archivos en una cinta única requiere usar el
dispositivo no rebobinado y documentar bien las cintas.
Crear sistemas de archivo acordes con el tamaño del medio de respaldo: con las
capacidades actuales, es posible crear sistemas de archivo de tamaño razonable que
quepan en una cinta. Debe haber una buena razón para crear sistemas de archivo muy
grandes.
Mantener las cintas fuera del lugar: pero realmente en otro lugar, apartado del lugar
de la instalación; hay innumeras historias sobre pérdida de los respaldos conjuntamente
con el sistema. El volumen actual de medios es suficientemente reducido como para
trasladar un montón de información en un portafolios. Puede recurrirse a una institución
especializada en conservación de datos o llevar las cintas a casa del gerente.
Seguridad del respaldo: el robo de un respaldo equivale al robo de toda la información
vital de una organización. Las precauciones de seguridad con los respaldos debe ser
tanta como la dispensada al propio sistema, con el agravante de que es más fácil
llevarse unas cintas que la información en disco.
Compilado por: Sandra Sauza Escoto 52
Saludos,
El Administrador.
Envía correo al usuario avisando la recuperación.
# exit
$
Fin de la tarea.
restore admite la opción i, para uso interactivo: el comando lee el catálogo de la cinta; se
recorren los archivos como si se tratara de un árbol de directorios común, usando ls, cd y pwd;
se van seleccionando los archivos a restaurar con add; cuando se han seleccionado todos,
indicando extract se los recupera de la cinta.
Ejemplo de recuperación interactiva. El indicador de supervisor # cambia a restore> al operar
dentro del comando.
# rrestore if roble:/dev/nrst1
restore> ls
arnoldo/ beiro/ juanpe/ lost+found/ vega/
restore> cd juanpe
restore> ls
carta01.txt core docs/ mbox perdido.arch varios/
restore> add perdido.arch
El archivo se agrega a la lista de archivos a recuperar. Agregar un directorio agrega todo su
contenido.
restore> ls
carta01.txt core docs/ mbox perdido.arch* varios
El asterisco indica que está marcado para recuperar.
restore> extract
Muestra mensajes; si no se sabe en qué volumen está el archivo, debe comenzarse por el
último y proceder hacia el principio; aquí asumimos saber que está en el primer volumen.
Specify next volume #: 1
Se realiza la extracción; pregunta si el directorio raíz de la cinta debe intepretarse como
directorio corriente; se usa sólo al restaurar sistemas de archivo completos.
set owner mode for '.'? [yn] n
#
Sale de restore, fin de la tarea.
Administración de Sistemas Unix de Misión Crítica 55
offline saca de línea la unidad de cinta; en los modelos que lo permiten, eyecta el
casete.
status muestra información de la cinta.
fsf [cantidad] avanza la cinta la cantidad de archivos indicada, 1 por defecto.
bsf [cantidad] retrocede la cinta la cantidad de archivos indicada, 1 por defecto.
Campo
8.4 Documentació n
Manuales, información, software.
Es imprescindible disponer del conjunto completo de manuales e información propios de la
variedad y versión de UNIX instalada. Ninguna otra fuente puede sustituir la del propio
fabricante. También debe disponerse de los discos compactos (u otro soporte) con el software
del sistema operativo, para reinstalar o complementar la instalación.
El sistema tradicional de documentación en línea de UNIX son las "páginas man", una serie de
textos clasificados en secciones y accesibles por nombre mediante el comando man. Aunque
algunos proveedores han cambiado este sistema de documentación, en general escribir
man ls
es aceptado en la inmensa mayoría de los sistemas, desplegando páginas de información sobre
el comando ls u otro que se indique. En particular,
man man
da información sobre el propio comando man.
Algunos proveedores han sustituido completamente este sistema. Linux ha incorporado el
comando info, un sistema sofisticado con enlaces a otros textos, similar al de las páginas
Web; mantiene el comando man, pero la versión más actualizada debe buscarse en info. La
Compilado por: Sandra Sauza Escoto 60
El comando man
man [OPCIONES] [SECCION] NOMBRE
Da formato y muestra las páginas del manual en línea. Si no se indica sección, muestra solo la
primera que encuentre; si se indica sección como número 1-9, muestra la página que haya en la
sección indicada. Las páginas están organizadas en secciones, reconocidas por un dígito, y
eventualmente subsecciones indicadas por una o más letras.
-a muestra páginas en todas las secciones
-d muestra información de depuración propia de man
-f equivalente a whatis
-h muestra ayuda para man
-k equivalente to apropos
-w no imprime las páginas, sino las ubicaciones
6 6 Juegos y demostrativos
Ejemplos:
man -h
man man
man -a man
man 5 passwd
Las condiciones de un buen administrador son un tanto contradictorias: debe ser innovador en
la búsqueda de soluciones, pero cuidar de no arriesgar el sistema; debe ayudar a los usuarios
pero sin resentir la atención comunitaria; debe ser amable, pero firme en los momentos críticos.
En algunas organizaciones, los administradores de sistemas son vistos como gente capaz,
trabajadora, bien paga, orientada a brindar servicio. En otras, se los trata como peones
informáticos útiles para todo. Los administradores maltratados desarrollan una oposición no
formulada, una actitud de agresividad pasiva muy inconveniente para la organización.
Las tareas de administración crecen muy rápidamente: en cuanto los usuarios descubren a
alguien capaz de resolver problemas, los pedidos proliferan. Si la persona tiene otras tareas
asignadas, debe pensar a dónde le llevará su nuevo rol. Puede ser muy difícil convencer a la
gerencia sobre el tiempo, recursos y riesgos de la operación del sistema. Los registros escritos
de tareas y tiempos pueden ser una ayuda invalorable para solicitar recursos, colaboradores,
cambios de función... o un traslado a otra sección.
El trabajo de administración de sistemas implica más cambios de tarea, y con mayores
consecuencias, en un sólo día, de lo que muchos trabajos requieren en un año. No debe
sorprender que estas personas parezcan a veces distraídas o descorteses.
Compilado por: Sandra Sauza Escoto 64
sistema de archivos corrupto. Es preciso conocer bien el proceso de arranque para configurar el
arranque automático de los servicios requeridos o intervenir en caso de falla.
Pasos del proceso de arranque.
El proceso de arranque tiene varios pasos que en general son los siguientes:
Carga e inicialización del núcleo (kernel).
Detección y configuración de dispositivos.
Creación automática de procesos base.
(Intervención del administrador - solo en modo monousuario).
Ejecución de archivos de comandos de arranque (scripts rc).
Operación en multi-usuario.
El administrador tiene poco control de esta secuencia, pero sí puede alterar los scripts rc, donde
se arrancan los procesos capaces de brindar servicios a los usuarios.
Inicialización del núcleo (kernel).
El núcleo del UNIX es un programa, y como todo programa debe cargarse previamente en
memoria para poder ejecutarse. El núcleo reside en un archivo llamado unix, vmunix, vmlinuz o
similar. Al encender el equipo comienzan a ejecutarse instrucciones en ROM cuyo objeto es
transferir a memoria un pequeño programa de arranque (boot program) encargado de cargar el
kernel en memoria y comenzar a ejecutarlo. Esta primera parte del proceso, hasta alcanzar la
ejecución del kernel, la realiza el hardware de la máquina. Una vez iniciado, el kernel verifica la
cantidad de memoria, separa una parte para sí mismo e informa la cantidad de memoria total, lo
reservado para sí y lo disponible para procesos de usuario.
Configuración del hardware.
Al comenzar su ejecución el núcleo intenta localizar e inicializar los dispositivos que le hayan
sido asignados en su construcción. Prueba estos dispositivos uno por uno, intentando
determinar parámetros de funcionamiento no especificados interrogando al propio dispositivo.
Los dispositivos no hallados o que no responden son inhabilitados. Una vez completado este
proceso, el agregado de un nuevo dispositivo deberá esperar el próximo arranque del sistema
para ser reconocido. Los sistemas UNIX suelen venir con uno o más núcleos genéricos donde
están preconfigurados los dispositivos más comunes, pero es posible reconstruir el núcleo
optimizándolo estrictamente al hardware disponible. También es posible prever el agregado
dinámico de módulos complementarios del kernel, cargándolos en memoria solo al detectarse la
presencia del dispositivo físico o solicitarse su acceso.
Procesos del sistema.
Una vez completada la inicialización básica el núcleo crea algunos procesos espontáneos,
llamados así por no haber sido creados por fork, el mecanismo habitual en UNIX. Los procesos
espontáneos difieren entre sistemas; en BSD son:
Compilado por: Sandra Sauza Escoto 66
Swapper - Proceso 0
Init - Proceso 1
Pagedaemon - Proceso 2
Sched - Proceso 0
Init - Proceso 1
Init - Proceso 1
varios manejadores de memoria y procesos del núcleo (kflushd, kupdate, kpiod, kswapd).
De todos estos procesos solo inites un proceso de usuario; los restantes son partes del núcleo
enmascaradas como procesos a para agendar su ejecución (scheduling) o por razones de
arquitectura. Aquí finaliza el núcleo sus tareas de arranque; los restantes procesos del sistema
serán arrancados directa o indirectamente por init.
Intervención del operador (solo en arranque manual).
Si el sistema fue arrancado en modo monousuario el proceso inites invocado por el núcleo con
un parámetro indicativo, pidiendo la contraseña de superusuario y arrancando un intérprete de
comandos (shell); al finalizar la ejecución del intérprete initcontinúa con el proceso normal de
arranque. Digitando Ctrl-D en lugar de la contraseña del supervisor continúa el arranque sin
invocar el shell.
En el shell monousuario el supervisor puede trabajar como en cualquier sesión, pero solo
dispondrá de comandos existentes en la partición raíz, la única montada. Esta partición puede,
además, haber sido montada en solo lectura para ser verificada; si /tmp está en la partición raíz,
programas necesitados de archivos temporales como vi no funcionarán. Volver a montar la
partición raíz en modo lectura escritura puede diferir entre sistemas, pero en general mount /
leerá de nuevo /etc/fstab para montar / en el modo habitual. Otros sistemas de archivos, como
/usr, pueden ser montados a mano si es necesario. Una falla habitual de arranque son sistemas
de archivos con inconsistencias; en este caso, deberá correrse fsck en forma manual antes de
montar el recurso. En el modo automático los sistemas de archivos son verificados como parte
del proceso de arranque; no así en monousuario.
Administración de Sistemas Unix de Misión Crítica 67
El nivel 1 es el monousuario por excelencia; el S fue creado para pedir la contraseña del
supervisor. En Solaris S es el monousuario, pero en Linux se usa 1 como monousuario y S para
pedir la contraseña del supervisor.
Los niveles se definen en el archivo /etc/inittab. Aunque el formato varía, el propósito de este
archivo es definir los comandos a correr en cada nivel; uno de ellos define el nivel por defecto
que ha de alcanzar el sistema. Los scripts se ejecutan pasando ordenadamente por cada nivel,
creciendo en el arranque y decreciendo en la detención. Los scripts de cada nivel detienen los
servicios correspondientes a niveles superiores y arrancan los servicios correspondientes al
nivel propio. No suele ser necesario tocar el archivo /etc/inittab; el control puede realizarse
totalmente a través de los scripts rc correspondientes a cada nivel, confiando en el sistema para
la invocación ordenada de los scripts rc de cada nivel según el directorio en que se encuentran.
Los scripts colocados en /etc/init.d manejan cada uno un demonio, servicio o aspecto particular
del sistema. Todos los scripts deben entender al menos los parámetros start (arrancar), stop
(detener); muchos entienden también restart, un stop seguido de un start. Esto permite al
administrador gobernar un servicio manualmente con comandos tales como
/etc/init.d/sshd start
/etc/init.d/sshd stop
FreeBSD; Redhat usa un híbrido System V y BSD con algunas complicaciones de propia
cosecha.
Problemas de arranque.
Las dificultades de arranque pueden deberse a diferentes causas:
Problemas de hardware.
Problemas en el cargador del sistema operativo.
Problemas en el sistema de archivos.
Problemas de configuración del núcleo (kernel).
Errores en los scripts de arranque (scripts rc).
Problemas de hardware.
Antes de diagnosticar un problema de hardware es preciso descartar fehacientemente errores
en la configuración del software; muchos de esos errores sugieren fallas de hardware a los ojos
inexpertos. Un mensaje de error específico proveniente directamente de un dispositivo es un
buen indicador de falla de hardware (error de memoria, error de controlador de disco). Siempre
es conveniente verificar aspectos de instalación tales como
Alimentación de corriente para todas las partes del equipo: gabinete principal, gabinetes
externos con discos, cinta u otros periféricos.
Alimentación de dispositivos internos (discos, disqueteras, unidades de cinta, CDROM).
Conexiones entre diferentes dispositivos (cables de señal de discos, disqueteras,
puertos).
Conexiones de red, sobre todo si la máquina depende de recursos externos (estación sin
disco, sistemas de archivos montados de otro servidor de red).
Si existen, revisar e interpretar las luces indicadoras de estado de los dispositivos.
Si la máquina comienza el arranque, verificar la aparición de todos los dispositivos
conectados; cada uno emite un mensaje de una línea al ser reconocido. Un mensaje de
error o la falta de detección de un dispositivo conectado correctamente puede indicar una
falla de hardware en ese dispositivo, en su plaqueta controladora o en la plaqueta
principal.
Cuando sea posible, usar programas de diagnóstico; los hay para dispositivos,
independientes del sistema operativo. Las máquinas de hardware propietario disponen
de rutinas de diagnóstico de hardware en ROM. En los computadores personales la
BIOS ejecuta en el arranque una prueba de autoverificación llamada POST (Power On
Self Test) que prueba la memoria, presencia de discos y otros elementos básicos; los
periféricos suelen traer programas DOS para diagnóstico (tarjetas de red, de video,
impresoras).
Al detectarse una falla conviene dejar el equipo apagado unos 30 segundos y luego
arrancarlo, para asegurarse de llevar el hardware a un estado conocido.
Compilado por: Sandra Sauza Escoto 70
en Linux rearranca (-r) la máquina en forma inmediata (now). La opción -h detiene; la opción -f
no realiza verificación de discos en el siguiente arranque.
halt
El comando halt realiza las tareas esenciales mínimas para bajar el sistema ordenadamente:
registra la bajada, termina los procesos no esenciales, sincroniza los discos y termina la
ejecución. La opción -n no sincroniza discos; se usa cuando se ha hecho un fsck sobre la
partición raíz para impedir al kernel sobreescribir el superbloque reparado con el defectuoso
que retiene en memoria.
reboot
El comando reboot procede como al halt pero arranca de nuevo el sistema después de bajarlo.
Tiene también opción -n, como halt.
Enviar al proceso init la señal TERM.
Esta señal obliga al proceso init a terminar; según la variedad de UNIX puede causar la bajada
del sistema. Es un método crudo; no sincroniza discos. Como init tiene siempre PID 1, la
secuencia
sync; sync
kill -TERM 1
ejecuta la acción. Consultar la documentación antes de emplear este método.
Cambiar nivel de ejecución (System V).
El comando telinit permite avisarle al procesoinitque cambie a otro nivel de ejecución.
telinit S
pasa el sistema a modo monousuario en Solaris y HP-UX; en Linux
telinit 1
realiza la misma acción (S solo abriría un nuevo shell). No hay período de gracia ni
advertencias.
shutdown -i1
es una forma más elegante de pasar a monousuario. telinit es útil para probar cambios al
archivo /etc/inittab:
telinit -q
obliga a init a releer el archivo inittab.
Matar el proceso init.
El proceso init es esencial para el funcionamiento del sistema; matar este proceso rearranca el
sistema inmediatamente, pero en algunos sistemas el kernel entra en pánico. Es un método
salvaje; usar shutdown o reboot.
Administración de Sistemas Unix de Misión Crítica 73
El archivo /etc/passwd.
El archivo /etc/passwd contiene la lista de usuarios en el sistema, una línea por usuario. Es
consultado cuando el usuario ingresa al sistema para determinar su UID; en muchos casos,
contiene también la contraseña encriptada, aunque la tendencia actual es retener la contraseña
encriptada en otro archivo, /etc/shadow, con permisos de acceso más restringidos. En este
último caso, el proceso de login consulta ambos archivos, /etc/passwd y /etc/shadow.
Los campos de /etc/passwd y /etc/shadow están separados por ":", al igual que la mayoría de
los archivos de configuración en UNIX.
Ejemplo de entradas en /etc/passwd:
root:x:0:0::/root:/bin/bash
bin:x:1:1:bin:/bin:
ftp:x:404:1::/home/ftp:/bin/bash
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/adm:
lp:x:4:7:lp:/var/spool/lpd:
mail:x:8:12:mail:/var/spool/mail:
postmaster:x:14:12:postmaster:/var/spool/mail:/bin/bash
Compilado por: Sandra Sauza Escoto 74
news:x:9:13:news:/usr/lib/news:
uucp:x:10:14:uucp:/var/spool/uucppublic:
man:x:13:15:man:/usr/man:
guest:x:405:100:guest:/dev/null:/dev/null
nobody:x:65534:100:nobody:/dev/null:
jperez:x:1000:100:Juan PEREZ,,,:/home/jperez:/bin/bash
mmendez:x:1001:100:Mario MENDEZ,,,:/home/mmendez:/bin/bash
gmartin:x:1002:100:Gerardo MARTIN,,,:/home/mmendez:/bin/bash
En su versión clásica, el archivo /etc/passwd contiene los siguientes campos:
nombre de login: nombre único, no más de 8 caracteres, sin signos de puntuación;
generalmente en minúscula para compatibilidad con todos los agentes transporte de
correo. Evitar nombres totalmente en mayúsculas, porque: el sistema asumirá que el
terminal no soporta minúsculas y abrirá una sesión totalmente en mayúsculas. El nombre
de login es un dato público; deben elegirse nombres que favorezcan el reconocimiento
de los usuarios en la vida real. En el acceso a diferentes máquinas, es conveniente
asignar a un mismo usuario el mismo nombre de login. Conviene asimismo evitar el uso
del mismo nombre para usuarios diferentes en distintas máquinas; los agentes transporte
de correo y los usuarios pueden caer en confusión. También debe asegurarse no usar un
nombre de login que sea a la vez un alias de correo para otro usuario.
contraseña encriptada: la contraseña se encripta con un algoritmo llamado DES; debe
ser fijada por el comando passwd (o yppasswd si se usa NIS), o copiar una contraseña
ya encriptada de otra cuenta. Si este campo está en blanco, el acceso es sin contraseña;
esto es una gran brecha de seguridad. Si se coloca un asterisco en este campo, la
cuenta no puede accederse hasta que el supervisor asigne una contraseña (comando
passwd, o yppasswd si se usa NIS). En sistemas que usan /etc/shadow, la contraseña se
encuentra en este archivo y no en /etc/passwd. Los archivos /etc/passwd y /etc/shadow
deben mantenerse consistentes; existen comandos que atienden esta situación
específicamente.
número UID: número identificatorio del usuario, generalmente entre 0 y 32767 o 65535,
según se usen enteros con o sin signo. Muchos sistemas han pasado ya a números de
32 bits. Debe ser único en toda la red local. Los números de 0 a 99 se reservan para
usuarios no humanos; 0 para root, 1 para bin, 2 para daemon, etc. Debe evitarse la
reutilización de números de usuarios que han dejado la institución, para evitar
confusiones si han quedado archivos del usuario anterior en el sistema o al restaurar
desde respaldo; recordar que los usuarios en el sistema son reconocidos por número y
no por nombre.
número GID por defecto: número identificatorio de grupo, también entre 0 y 32767 o
65535. Los números bajos se reservan para grupos del sistema: 0 para el grupo root o
wheel, 1 para el grupo daemon. Los grupos se definen en el archivo /etc/group. El
número GID define el grupo de pertenencia de los archivos creados por el usuario, o de
procesos iniciados por él. La pertenencia a grupo de un nuevo archivo es la del directorio
donde se encuentra si éste directorio tiene fijado setgid. El uso de la opción grpid en el
Administración de Sistemas Unix de Misión Crítica 75
comando mount también obliga a los archivos nuevos a tomar como grupo el del
directorio donde son creados. El comando newgrp permite a un usuario cambiar su
grupo primario hacia otro al cual también pertenezca; el comando sg permite ejecutar un
comando como perteneciendo al grupo indicado en el propio comando.
información de usuario (campo "GECOS"): históricamente usado para transferir
trabajos en batch desde una máquina UNIX hacia un mainframe corriendo GECOS. Se
usa ahora, sin una sintaxis fija, para contener información del usuario. El comando
finger interpreta este campo como una lista separada por comas conteniendo: 1)
nombre en la vida real, 2) edificio y número de oficina, 3) teléfono interno, 4) teléfono
domiciliario. El comando chfn permite al usuario cambiar su información propia.
directorio propio (home): cuando el usuario ingresa al sistema, es colocado en su
directorio propio; si éste no existe, algunos sistemas impiden el ingreso; otros emiten un
mensaje de error, aceptan el ingreso y colocan al usuario en el directorio raíz. El
directorio propio del usuario suele tener su mismo nombre de login; se ubica (o se
monta) habitualmente bajo /home.
shell de login: al ingresar al sistema, el usuario dispone de un intérprete de comandos
por defecto, generalmente /bin/sh o /bin/csh; también pueden ser /bin/bash, /bin/ksh,
/bin/tcsh, u otros. El usuario puede cambiar su intérprete con el comando chsh, o a
veces simplemente invocando el nuevo shell; el archivo /etc/shells contiene los
intérpretes habilitados para elección de los usuarios con chsh. Al editar/etc/shells, en los
nombres de invocación de los shell debe figurar la vía completa.
El archivo /etc/shadow.
El archivo /etc/passwd las contraseñas encriptadas, una línea por usuario; solo es visible al
supervisor. Provee además información relativa a cambio de contraseñas y expiración de la
cuenta.
Ejemplo de entradas en /etc/shadow:
root:1eklLr8RdBuao:10461:0:::::
bin:*:9797:0:::::
ftp:*:9797:0:::::
daemon:*:9797:0:::::
adm:*:9797:0:::::
lp:*:9797:0:::::
mail:*:9797:0:::::
postmaster:*:9797:0:::::
news:*:9797:0:::::
uucp:*:9797:0:::::
man:*:9797:0:::::
guest:*:9797:0:::::
Compilado por: Sandra Sauza Escoto 76
nobody:*:9797:0:::::
jperez:Uq54ay2A4F6MY:10461:0:99999:7:::
mmendez:dp079LiquZhwo:10454:0:99999:7:::
gmartin:Gr989KumerAdf:10231:0:99999:7:::
Contiene los siguientes campos:
nombre de login: el mismo nombre que en /etc/passwd; este nombre conecta las
entradas en /etc/passwd y /etc/shadow.
contraseña encriptada: bajo las mismas condiciones que en /etc/passswd; la
contraseña encriptada es desplazada del /etc/passwd al /etc/shadow, dejando en
/etc/passwd una x en este campo.
fecha de último cambio de contraseña: registra la fecha en que el usuario cambió por
última vez su contraseña.
mínima cantidad de días entre cambios de contraseña: una vez cambiada una
contraseña, el usuario no puede volver a cambiarla hasta que haya transcurrido esta
cantidad de días como mínimo. No se recomienda fijar este valor; si ha habido una
violación de seguridad puede ser necesario cambiar la contraseña de inmediato, sin
tener que esperar.
máxima cantidad de días entre cambios de contraseña: obliga a los usuarios a
cambiar su contraseña periódicamente. En Linux, este valor se suma al campo de
inactividad antes de bloquear la cuenta.
cantidad de días de adelanto para avisar expiración de contraseña: avisa al usuario
de la necesidad del cambio de contraseña, a partir de esta cantidad de días antes de la
fecha límite.
cantidad de días de inactividad antes de expirar la cuenta: en Solaris, si pasa esta
cantidad de días sin login del usuario se bloquea la cuenta; en Linux, son días de gracia
después del máximo sin cambiar contraseña y antes de bloquear la cuenta.
fecha de expira de la contraseña: día contado a partir del 1-1-1970, en que la cuenta
expirará. Si el campo está en blanco, la cuenta no expira nunca. Si ha transcurrido esta
fecha, el campo debe ser repuesto por el administrador para rehabilitar la cuenta.
banderas: reservado para usos futuros.
El archivo /etc/group.
El archivo /etc/group contiene los nombres de los grupos UNIX definidos en el sistema y una
lista de sus miembros. Hay una línea por cada grupo. Los campos están separados por ":".
Ejemplo de entradas en /etc/group:
root::0:root
bin::1:root,bin,daemon
daemon::2:root,bin,daemon
Administración de Sistemas Unix de Misión Crítica 77
sys::3:root,bin,adm
adm::4:root,adm,daemon
tty::5:
disk::6:root,adm
lp::7:lp
mem::8:
kmem::9:
wheel::10:root
floppy::11:root
mail::12:mail
news::13:news
uucp::14:uucp
man::15:man
usuarios::100:jperez,mmendez,gmartin
nogroup::-2:
Cada línea contiene:
nombre del grupo: algunos sistemas piden 8 caracteres o menos.
contraseña encriptada: histórico, no se usa. El comando newgrp no cambia el grupo
por defecto de un usuario si su nombre no está listado en el grupo al que quiere cambiar,
aún cuando este campo esté en blanco (lo usual).
número GID: número único identificador del grupo. Para mantener coherencia en un
sistema heterogéneo es recomendable no usar como grupo por defecto de los usuarios
un grupo del sistema o del proveedor (por ejemplo, users, o staff), sino un grupo creado
por el administrador (por ejemplo, usuarios), ya que diferentes sistemas pueden asignar
diferente GID a los mismos grupos del sistema.
lista de integrantes: nombres de login de los integrantes del grupo separados por
comas, sin blancos.
Crear usuarios.
Antes de abrir una cuenta a un nuevo usuario, éste debe fechar y firmar su conformidad con el
documento descriptivo de política de uso del sistema local. La experiencia demuestra ser
mucho más difícil de conseguir una firma de conformidad después de haber sido abierta y
concedida la cuenta.
La creación de usuarios se realiza en tres fases: dos para establecer el ambiente del usuario y
una tercera para objetivos administrativos.
Compilado por: Sandra Sauza Escoto 78
Requeridos:
definir la cuenta del usuario, ingresándola en los archivos /etc/passwd y /etc/shadow;
fijar una contraseña inicial;
crear el directorio propio (home) del usuario.
En beneficio del usuario:
Para administración:
agregar el usuario al archivo /etc/group;
registrar información contable, si es necesario;
ingresar al usuario en la base de datos global del sistema;
ingresar información de contacto con el usuario (dirección, teléfono);
configurar cuotas de disco;
verificar el establecimiento correcto de la cuenta.
Edición de archivos.
Si estas herramientas existen en el sistema, la edición de /etc/passwd debe hacerse con vipw,
que bloquea el archivo para evitar interferencias si un usuario está cambiando su contraseña
simultáneamente. Con vipw -s se edita /etc/shadow. Se insiste en la necesidad absoluta de
mantener coordinados los archivos /etc/shadow y /etc/passwd. La edición de /etc/group se hace
con vigr. Con vigr -s se edita /etc/shadow-group o /etc/gshadow, en caso de que exista un
archivo shadow para grupos. Si el sistema provee scripts para crear, modificar o borrar
usuarios, éstos se ocupan de mantener la coherencia y bloquear los archivos antes de
modificarlos. El siguiente análisis de creación manual de un usuario muestra el procedimiento
subyacente en las herramientas habituales de administración.
csh .login fija tipo de terminal, variables de ambiente, opciones para biff y mesg
mailx .mailrc aliases personales para correo, opciones para el lector de correo
Forward
Es conveniente limitar la lectura de correo por parte de un usuario a una máquina única, aquella
en la cual habitualmente trabaja. Para ello, se crea en el archivo /etc/aliases una entrada que
dirige el correo del usuario hacia una máquina específica. Las líneas
jperez: jperez@alamo
juanperez: jperez
redirigen el correo de jperez hacia la máquina alamo y fijan juanperez como alias de jperez. En
ambientes de red suele resolverse este problema eligiendo una máquina como servidor de
correo y montando el directorio /var/spool/mail de esta máquina vía NFS en el /var/spool/mail de
las restantes máquinas.
Editar /etc/group.
/etc/group para incluir al usuario en grupos secundarios. Algunos sistemas requieren que el
usuario figure en el grupo wheel para poder hacer su.
Información contable.
Muchos sitios controlan o aún facturan servicios informáticos por uso. En estos casos, al crear
un usuario debe registrarse la información pertinente, tal como nombre, número de cuenta,
calendario de pago, dirección de cobro.
Es fácil crear una tabla de usuarios y números telefónicos extrayendo la información del campo
GECOS del archivo /etc/passwd, sobre todo si se tomaron en cuenta las recomendaciones para
uso de comas en este campo. Esta tabla puede luego interrogarse con un script simple tal
como:
#!/bin/sh
# telefono: devuelve línea con datos del usuario
grep $1 /usr/local/pub/telefonos
que se invoca simplemente como
telefono jperez
y devuelve una línea con los datos del usuario indicado en el parámetro.
Fijar cuotas.
Si en el sistema se utilizan cuotas para controlar el uso de disco, es preciso fijar la cuota para el
nuevo usuario con el comando edquota. Este comando admite diversos parámetros para fijar
límites en el uso de disco, pero en la creación de usuarios es más frecuente usarlo en modo
prototipo, copiando el perfil de cuota de algún usuario tomado como modelo:
edquota -p usuario-modelonuevo-usuario
Eliminar usuarios.
Inhabilitar cuentas.
Cuando una cuenta debe ser temporalmente inhabilitada, por ejemplo por ausencia del titular,
se solía colocar simplemente un asterisco en el lugar de la contraseña en /etc/passwd. En la era
de las redes, esto no es suficiente; entonces, se sustituye el intérprete de comandos de login
por un programa que imprime un mensaje indicando la inhabilitación de la cuenta.
Caducidad de contraseñas.
Los UNIX modernos disponen de una facilidad para obligar al usuario a cambiar su contraseña
periódicamente. Esta práctica está un tanto cuestionada, ya que el usuario obligado a disponer
de varias contraseñas se ve fácilmente tentado hacia elecciones menos seguras. Sí se insiste o
aún obliga a los usuarios a cambiar su contraseña cuando han habido violaciones de seguridad
o sospechas fundadas.
Pseudo logins.
useradd
comando con opciones para agregar usuarios; modifica los archivos passwd y shadow
coherentemente.
usermod
comando con opciones para modificar diversos ajustes de una cuenta de usuario.
userdel
comando con opciones para eliminar un usuario.
Adduser
es un script en Perl u otro lenguaje de scripting, ofrece opciones de menú para facilitar el
ingreso de datos y luego invoca el comando useradd con los parámetros ingresados.
groupadd, groupmod, groupdel
comandos con opciones para agregar, modificar o borrar un grupo del archivo de grupos;
análogos a sus contrapartidas para usuarios.
Aunque útiles, estos comandos y scripts rara vez implementan todas las políticas de uso
locales. Es aconsejable reescribir o adaptar los scripts adduser y rmuser para realizar vía
scripts todo el proceso de creación y remoción de usuarios.
Compilado por: Sandra Sauza Escoto 84
11.1.1 Preparación.
El espacio en disco parece siempre insuficiente. No es fácil lograr que los usuarios eliminen sus
archivos innecesarios, caducos o repetidos. La baja de precios en los discos ha disminuido la
presión del espacio en disco. Es una tarea frecuente en administración agregar discos al
sistema.
En las máquinas UNIX es tradicional la conexión de discos y otros periféricos mediante la
interfaz SCSI (Small Computer System Interface; se pronuncia "scasi"). En los computadores
personales es universal el uso de la interfaz IDE (Integrated Drive Electronics), aunque también
es posible disponer de interfaz SCSI, de mayores posibilidades.
Interfaces para discos.
Las intefaces para dispositivos comenzaron siendo diferentes y propietarias; actualmente, solo
se usan interfaces estándar, siendo las más comunes SCSI e IDE, y en menor grado las más
recientes Fibre Channel y USB (Universal Serial Bus).
SCSI. Varios discos sobre un mismo mazo de conductores (barra o "bus"). Existen
varias versiones con diferentes velocidades y formas de comunicación.
IDE. Surgió como una interfaz sencilla de bajo costo, para computadores personales.
Los discos IDE ofrecen velocidad media, gran capacidad y bajo costo, pero la interfaz
IDE soporta solamente 2 dispositivos.
Fibre Channel. Es una interfaz serial de gran ancho de banda capaz de soportar un
gran número de dispositivos; ofrece velocidades de 100 MB/s y más, soporta varios
protocolos incluidos SCSI e IP. Los dispositivos Fibre Channel se identifican con un
número fijado en hardware (World Wide Name) similar a la dirección Ethernet en
capa MAC. Usada en ambientes corporativos.
USB. Usada para conectar ratones y teclados, tiene ancho de banda para soportar
discos de baja velocidad como los removibles y los CDs. Usada en computadores
personales, facilita el transporte de una máquina a otra.
SCSI e IDE, por mucho, son las interfaces más comunes para conexión de discos.
La interfaz SCSI.
La interfaz SCSI define un canal genérico comunicación de datos utilizable por todo tipo de
periférico, usualmente discos, cintas, escaners e impresoras. Muchos fabricantes colocan
soporte SCSI directamente en la plaqueta principal o en la plaqueta de periféricos. La
especificación ha sufrido una larga evolución, comenzando con SCSI-1, siguiendo con SCSI-2 y
sus ampliaciones Fast SCSI-2 y Fast/wide SCSI-2. La versión actual, SCSI-3, está aún sin
terminar, pero varias de sus características han sido ya implementadas en el mercado bajo los
nombres Ultra SCSI, Wide Ultra SCSI, Wide Ultra2 SCSI y Wide Ultra3 SCSI.
En los dispositivos SCSI importan estos parámetros y características:
Velocidad. La velocidad de transferencia de datos. El término "fast" indica un aumento al
doble respecto al usual de la norma.
Ancho de bits. La cantidad de bits transferidos en paralelo, en principio 8. El término
"wide" indica un incremento a 16 o 32.
Administración de Sistemas Unix de Misión Crítica 87
diferencial,
Versión MHz bits MB/s m Otros nombres
m
SCSI-1 5 8 5 6 25 -
SCSI-2 5 8 5 6 25 -
Fast SCSI-2 10 8 10 3 25 -
Fast/wide SCSI-2 10 16 20 3 25 -
conectar, por lo que se requiere un conector terminador para el último y primer dispositivo. Los
terminadores pueden ser conectores colocados en un puerto, bancos de resistencias
enchufados en la plaqueta controladora SCSI, o aún estar ya incluida en el propio dispositivo.
Los dispositivos internos se conectan directamente sobre el cable chato a través de un puerto
único. El controlador SCSI, en el interior del gabinete del computador, suele incluir su propio
terminador. Es muy importante verificar la presencia de terminadores; la falta de alguno de ellos
suele producir errores intermitentes de difícil detección. La presencia de terminadores puede
ajustarse también por software o mediante "jumpers".
Cada dispositivo se identifica con una dirección SCSI, un número de 0 a 7 (SCSI común,
angosto) o 0 a 15 (SCSI wide, ancho). El controlador suele tener el número 7, tanto en ancho
como en angosto. En teoría este número coincide con la prioridad asignada al dispositivo, pero
tiene poca significación práctica. Algunos sistemas toman el disco con menor número como el
de arranque; en otros el disco de arranque debe tener número 0. Los números se asignan con
una perilla giratoria, llavecitas tipo DIP (DIP switches) o puentes (jumpers). SCSI soporta un
esquema de subdirecciones para cada número de dispositivo, llamado LUN (Logical Unit
Number), pero es raro verlo usado en la práctica.
La configuración de dispositivos SCSI no suele ser compleja, pero es preciso tener en cuenta
una serie de detalles.
Pueden existir dispositivos SCSI internos al computador; es preciso registrar sus
números para no repetir al momento de agregar otros.
Las técnicas de señalización de extremo único y diferencial son totalmente
incompatibles; todos los elementos deben ser de un tipo o de otro.
Verificar en el arranque la detección correcta de dispositivos y sus números. Dispositivos
SCSI con número repetido no se detectan; aparecen errores difíciles de rastrear.
Verificar la existencia de terminadores en ambos extremos y sólo en ambos extremos.
Algunos gabinetes de expansión para SCSI incluyen el terminador en el gabinete.
Algunas rueditas de fijación de números cambian el número pero no lo muestran.
Al calcular la longitud de cables, no olvidar los tramos internos a los gabinetes.
Recordar que la tarjeta controladora usa un número de dispositivo para sí.
Realizar una asignación ordenada de números; verificar exhaustivamente para no repetir.
La interfaz IDE.
La interfaz IDE, también llamada ATA (AT Attachment, por el modelo AT de los computadores
personales), fue concebida como una forma simple y barata de controlar discos. La versión
ATA-2 agregó una más rápida PIO (Programmed Input Output), modo DMA (Direct Memory
Access), y extendió las características de autodetección (Plug and Play). También incorporó
LBA (Logical Block Addressing) para superar la limitación de las BIOS (Basic Input Output
Services) de los computadores personales para acceder espacio más allá de los primeros 1024
cilindros, habilitando así el uso de discos mayores de 504 MB. En el hardware actual la LBA se
desentiende del manejo geométrico tradicional en cilindros, cabezas y sectores (CSH, Cylinder,
Sector, Head) en favor de un direccionamiento totalmente lineal.
ATA-3 agrega características; ATA-4, aún en desarrollo, intenta combinar ATA-3 con ATAPI
(ATA Packet Interface), usado para manejar unidades de CD y cinta desde la interfaz IDE. La
Administración de Sistemas Unix de Misión Crítica 89
variante Ultra-ATA intenta aumentar el ancho de banda básico de 16 MHz a 33 MHz (Ultra
DMA/33) o a 66 MHz (Ultra DMA/66).
Las unidades IDE son casi siempre internas, dada su escasa longitud máxima de cable (18
pulgadas = 45 cm). Un cable fuera de norma, más largo, puede explicar errores intermitentes.
Una interfaz IDE puede manejar solo dos dispositivos. En compensación, es usual incluir en las
plaquetas principales dos interfaces IDE (IDE0, IDE1), para un total de 4 dispositivos. La
interfaz IDE permite un solo dispositivo activo por vez; por ello, conviene colocar los dispositivos
rápidos (discos) sobre la misma interfaz, y los lentos sobre la otra (unidades CD, cintas). El
conector IDE tiene 40 pines; usa cable chato. El Ultra DMA/66 usa un cable diferente.
El esquema IDE exige definir un dispositivo como "maestro" y el otro como "esclavo",
usualmente a través de puentes (jumpers) en el propio dispositivo. Es preciso revisar esta
condición aún en los discos instalados; algunos tienen posiciones "maestro", "esclavo" y "disco
único". Debe recordarse también habilitar la detección de discos en la BIOS de la máquina.
Al instalar discos IDE debe recordarse:
Hay compatibilidad, en general, entre versiones anteriores y posteriores de discos y
controladores, funcionando con las prestaciones del más limitado.
La longitud de cable máxima es realmente poca; puede dificultar el agregado de un
disco. Un cable especial de mayor longitud implica un riesgo de mal funcionamiento.
Una BIOS vieja con la limitación de 500 MB para discos puede convertirse en una
pesadilla; cambiar la plaqueta principal puede ser la mejor solución o la única.
Las características de PIO y DMA hacen diferencia; comparar las diferentes ofertas.
¿SCSI o IDE?
SCSI es técnicamente mejor en todos los aspectos, pero es bastante más cara. Una estación
IDE con un solo disco provee el 85 % de la eficiencia SCSI a la mitad de precio. Se debe
colocar SCSI cuando
se trata de aplicaciones críticas, donde se requiere el mejor rendimiento posible. No solo
por la superioridad técnica de SCSI, sino porque los fabricantes rara vez ponen la última
tecnología de discos en interfaces IDE.
servidores y máquinas multiusuario. En máquinas cargadas, la diferencia de rendimiento
entre IDE y SCSI se hace notar.
si se deben colocar muchos dispositivos. SCSI está preparado para atender la demanda
concurrente; los dispositivos IDE compiten entre sí.
Instalación de discos.
La instalación de discos implica los siguientes pasos:
Conectar el disco al computador.
Instalar soporte en el kernel.
Crear archivo de dispositivo para acceder al disco.
Dar formato al disco.
Compilado por: Sandra Sauza Escoto 90
Dos fuentes de confusión usadas por los fabricantes de discos consisten en:
indicar la capacidad del disco sin formato; se requiere un 10% de espacio para marcar
las superficies y poder almacenar datos en ellas.
asumir el MB como 106 B (1.000.000), en lugar de 220 B (1.048.576), con un error de un
5%.
El proceso de formato escribe información de direcciones y marcas de temporización sobre la
superficie del disco, dividiéndolo en sectores. En este proceso se identifican también bloques
malos (bad blocks), imperfecciones de la capa magnética, eliminando sus direcciones de la lista
de accesos para evitar utilizarlas. SCSI maneja los bloques malos por sí solo. Este formato,
llamado de bajo nivel, viene hecho de fábrica en todos los discos; en caso de falla, es difícil
poder hacer un buen formato de bajo nivel: además del software necesario, insume unas
cuantas horas.
Administración de Sistemas Unix de Misión Crítica 91
Para poner en uso un sistema de archivos es preciso montarlo. El punto de montaje puede ser
cualquier directorio del sistema, de preferencia vacío; si hay algo en él, dejará de verse al
montar el nuevo sistema de archivos, pero no se perderá, haciéndose nuevamente visible al
desmontar.
Luego de crear un sistema de archivos es recomendable montarlo manualmente para
verificación.
mount /dev/sd1a /mnt
montará el dispositivo indicado sobre el directorio /mnt. El nombre de los dispositivos difiere
según las variantes UNIX. El comando
ls /mnt
sobre el sistema de archivos recién creado mostrará solo un directorio llamado lost+found; se
genera automáticamente al crear el sistema de archivos; lo usa el comando de reparación fsck
para almacenar archivos "desconectados". El comando
df /mnt
informa tamaño en bloques, espacio usado y disponible, porcentaje de ocupación y punto de
montaje para el sistema de archivos indicado, o todos si no se indica ninguno:
Filesystem 1024-blocks Used Avail Capacity Mounted on
/dev/wd0s2e 1986495 1659742 167834 91% /usr
Para montar los sistemas de archivos en el momento del arranque debe listarse en el archivo
/etc/fstab (vfstab en Solaris). El formato es similar a este:
# Device Mountpoint FStype Options Dump Pass#
/dev/wd0s2b none swap sw 0 0
/dev/wd0s1a / ufs rw 1 1
/dev/wd0s2e /usr ufs rw 2 2
/dev/acd0c /cdrom cd9660 ro,noauto 0 0
Proa /proa procfs rw 0 0
volta:/export /volta nfs rw 0 0
Son seis campos separados por espacios. Cada línea describe un sistema de archivos. Los
campos son:
nombre del dispositivo: puede ser el nombre de un dispositivo local o un sistema de
archivos remoto ubicado en otra máquina, montado vía NFS. La entrada proc no es un
sistema de archivos, sino información del kernel; swap es el espacio de intercambio para
memoria virtual.
punto de montaje: nombre de un directorio.
tipo de sistema de archivos: ufs (Solaris, FreeBSD), hfs o vxfs (HP-UX), ext2 (Linux).
Compilado por: Sandra Sauza Escoto 94
corre la verificación pidiendo confirmación antes de corregir. A no ser que se sea un experto en
la implementación de sistemas de archivos, conviene dejar proceder a fsck en la reparación.
Cuando fsck pide autorización para borrar un archivo, si es de interés, conviene primero intentar
copiarlo tal cual está; puede haber partes de información rescatable. Si se trata de un disco con
datos valiosos, una copia cruda con dd hacia otro dispositivo puede permitir rescatar algo,
recordando siempre que se trata de un sistema de archivos con errores, pasible de dar
problemas en el montaje o en el acceso. Obviamente fsck poco o nada puede hacer ante fallas
físicas en la superficie del disco.
El espacio en disco.
El abaratamiento de los discos ha reducido considerablemente la incidencia del espacio
ocupado por los usuarios. No obstante, los discos requieren administración: hay que instalarlos,
darles formato, montarlos en otras máquinas, respaldarlos, monitorearlos. Aunque el espacio en
disco sea suficiente, es preciso insistir ante los usuarios para hacer un uso racional del recurso.
Aspectos políticos.
Existe una natural, y en parte justificada, tendencia a "conservarlo todo" en materia de archivos:
es trabajoso seleccionar qué se debe guardar, todo puede servir algún día. En una máquina
personal, el usuario simplemente borra cuando se quedó sin espacio. En una red, siempre se
espera que sea otro quien lo haga. Las recomendaciones generales dan poco resultado. Para
un efectivo control del espacio en disco, es preciso determinar quienes son los usuarios más
consumidores y hacerles saber a ellos mismos que son fuente de problemas. Un script
automático puede recorrer los directorios personales, calcular el espacio consumido y publicar
los "top 10", los 10 usuarios con más espacio en disco ocupado. Enviar un correo automático a
los ofensores da resultado la primera vez, luego la novedad decae y los mensajes son borrados
sin leer. La publicación ante toda la comunidad de usuarios del espacio insumido por los
mayores consumidores tiene un efecto mucho mayor. Si esta "presión social" no da resultado,
es preciso enviar un cortés mensaje personal al usuario; esto tiene mucho mayor efecto que un
correo automático. Proveer un medio de almacenamiento fuera de línea (cinta, zip drives,
grabadoras de CD), fácilmente disponible, con instrucciones claras, es una buena ayuda para
usuarios y administradores.
Monitoreo del espacio en disco.
El comando quot informa sobre el espacio en disco consumido por los usuarios en cada
sistema de archivos:
quot -f /dev/hda2
da una lista de la cantidad de bloques y archivos a nombre de cada usuario. Este comando no
tiene nada que ver con el sistema de cuotas, analizado más adelante. No está disponible en
todas las versiones de UNIX.
El comando du da un resumen del uso de disco en una rama de directorios.
du -s /export/home/*
da el total para cada rama de subdirectorio bajo /export/home; esto no es efectivo para ver el
consumo total de cada usuario si los usuarios tienen archivos en otras partes del sistema.
Compilado por: Sandra Sauza Escoto 96
espacio en disco usando la persuasión y la presión social de de los pares, no se hallará método
mejor. Muchos administradores consideran obsoleto el control de espacio en disco por cuotas,
sobre todo por la baja de costo de los discos y la frecuencia de uso de discos locales en las
estaciones de trabajo de los usuarios. En las unidades compartidas, cuando la comunidad de
usuarios es propensa a consumos desmedidos o incontrolables, puede ser necesario
implementar cuotas de uso de disco para forzar a los usuarios a mantenerse dentro de límites
prefijados de uso.
El sistema de cuotas permite limitar tanto el número de inodos como la cantidad de bloques que
un usuario puede ocupar. La cantidad de inodos está directamente relacionada con la cantidad
de archivos; la cantidad de bloques, con el espacio ocupado. Cada uno de estos límites tiene
dos valores: un valor soft y un valor hard. Superar el valor soft origina una advertencia; el valor
hard impide ocupar más disco. Un lapso prolongado (más de 3 días, por ejemplo), superando el
valor soft, lo impone rígidamente, tal como el hard, hasta que el usuario borra, momento en que
se reinicia el conteo de tiempo. Muchas versiones implementan cuotas también sobre grupos,
permitiendo controlar el espacio que insume un proyecto o equipo de trabajo.
Un beneficio colateral de las cuotas es que impiden a los programas descontrolados llenar el
disco: se trancan en cuanto se supera la cuota correspondiente al usuario invocante.
Los inconvenientes esenciales de las cuotas son el mantenimiento administrativo y la carga que
imponen sobre el sistema: un sistema de archivos puede perder hasta un 30 % de rendimiento
al estar procesando cuotas. Como las cuotas se imponen por sistema de archivo, es preciso
tener una adecuada división en sistemas de archivo diferentes, para no poner cuotas sobre
aquellos donde los usuarios no tienen derechos, evitando así detrimentar su rendimiento.
Las cuotas se asignan por sistema de archivos, y dentro de un mismo sistema de archivos, por
usuario: un usuario habilitado a grabar en dos sistemas de archivo diferentes obliga a fijar su
cuota en ambos. Si no se fija cuota para un usuario, se entiende que no tiene límite. Lo mismo
vale para cuotas de grupo.
Funcionamiento de las cuotas.
La información de cuotas para un sistema de archivos se encuentra en el archivo quotas del
directorio raíz del sistema de archivos. Si se soportan cuotas para usuarios y grupos, los
archivos suelen ser dos: quota.user y quota.group. El kernel actualiza el archivo quotas toda vez
que una operación altera la cantidad de bloques ocupados por un usuario. Los comandos
usuales para el manejo de cuotas son los siguientes:
edquota: permite editar los archivos quota.* para fijar las cuotas.
quota, repquota: muestran información de cuotas y espacio insumido para usuarios y
grupos.
quotacheck: recorre todo el sistema de archivos bloque a bloque calculando el espacio
utilizado; luego actualiza el archivo quotas. Suele corrérselo en el arranque del sistema
con la opción -a para que verifique todos los sistemas de archivo montados que tengan
activado el sistema de cuotas. Con -v muestra una lista de usuarios y sus consumos. La
opción -p examina los sistemas de archivos en paralelo, a la manera de fsck.
Habilitación de cuotas.
Para habilitar el sistema de cuotas, esta opción debe estar compilada en el kernel. En muchas
versiones esto ya viene hecho; de no ser así, habrá que habilitar la opción y recompilar el kernel
Compilado por: Sandra Sauza Escoto 98
edquota.
El comando
edquota -u nombre_usuario
Administración de Sistemas Unix de Misión Crítica 99
permite editar el valor de cuota para el usuario indicado. El comando edquota suele correr una
versión de vi (o el editor especificado en la variable EDITOR) mostrando un formato base para
la edición, referenciando todos los sistemas de archivos en el cual el usuario tenga cuota
habilitada:
Quotas for user jperez
/dev/hda2: blocks in use: 2594, limits (soft = 5000, hard = 6500)
inodes in use: 356, limits (soft = 1000, hard = 1500)
Para grupos es análogo, usando el comando
edquota -g nombre_grupo
La forma de trabajo usual el definir algunos "usuarios prototipo", fijarles cuota individualmente
con el comando edquota, y luego asignar cuotas a los restantes usuarios conforme alguno de
los usuarios prototipo. El comando
edquota -p nombre_usuario_prototipo nombre_usuario
permite fijar la cuota de usuario al valor de cuota de un usuario prototipo.
Un esquema práctico es disponer de 3 usuarios prototipo: chico, medio y grande, para así fijar
fácilmente los valores de cuota de los usuarios reales según los de estos usuarios prototipo.
Para fijar cuotas a los grupos puede seguirse un esquema análogo, con el comando:
edquota -p nombre_grupo_prototipo nombre_grupo
Puede fijarse un tiempo de gracia durante el cual se permite al usuario mantener un consumo
por encima del límite soft antes de forzar su cumplimiento, mediante el comando
edquota -t usuario
que abre el editor con algo similar a esto:
Time units may be: days, hours, minutes or seconds
Grace period before enforcing soft limits for users:
/dev/hda2: block grace period: 0 days, file grace period: 0 days
donde es habitual cambiar el 0 por 7 para dar una semana de gracia a los usuarios.
quota, repquota.
quota nombre_usuario
informa al usuario sobre cuota en el sistema de archivos en que se encuentra; con -v informa
en todos los sistemas de archivos. Sólo el superusuario puede ver cuotas ajenas. login corre
quota cada vez que el usuario ingresa; esto puede producir retardos, sobre todo para sistemas
de archivos remotos.
repquota produce un informe similar al de quot o quotacheck -v; también informa de
cuotas para usuarios individuales.
Compilado por: Sandra Sauza Escoto 100
Los comandos lpq, lprm y lpc son los más usados en el manejo diario de las tareas de
impresión.
lpq, normalmente acompañado de la opción –Pimpresora u otra que restrinja la salida, muestra
los trabajos en la cola de impresión, en el orden de prioridad asignado, arriba el que será
impreso primero. Otros datos incluyen el dueño del trabajo, el número de trabajo (jobid), nombre
del archivo, tamaño; la opción -l da más detalles. El número de trabajo importa para el manejo
del mismo con lprm o lpc.
El comando lpq
Descripción: permite ver el estado de las colas de espera de impresión
Sintaxis:
lpq [ opcion ] [ usuario ]
Opciones:
-P dest para escoger la impresora
-l formato largo
Ejemplo:
ssauza@tequila:10> lpq
lp is ready and printing
Rank Owner Job File Total Size
active root 201 /etc/passwd 350 bytes
1st 202 abc 546 bytes
ssauza@tequila:11>
Administración de Sistemas Unix de Misión Crítica 101
Opciones:
-P dest para elegir la impresora
-# n para obtener n copias
Ejemplo:
ssauza@tequila:43> lpr abc
ssauza@armaganc:44> lpr -Pdocencia prog1.c results.txt
ssauza@tequila:45>
lprm, en su forma más común lprm nro_trabajo, elimina de la cola el trabajo de número
indicado; como lprm usuario elimina todos los trabajos enviados por ese usuario; lprm sin
opciones elimina el trabajo activo; lprm - elimina todos los del usuario invocante, o todos los
trabajos si el usuario es root.
El comando lprm (line printer remove)
Opciones:
-P dest para escoger la cola de espera
- suprime todos los archivos del usuario
job# borra el archivo que corresponde a ese número
Ejemplo:
ssauza@tequila:10> lprm 202
dfA202apache dequeued
cfA202apache dequeued
ssauza@tequila:11>
El éxito de la operación es denunciado con el aviso de la eliminación del trabajo indicado por su
número; curiosamente, no indica cuando falla. En algunos sistemas la remoción de un trabajo
puede producir confusión en un filtro, dejando la impresora bloqueada e impidiendo su uso;
identificar el proceso filtro con ps y eliminarlo desbloquea la impresora; rearrancando lpd se
soluciona este problema; en este caso, la manipulación con lpc es inútil. El rearranque del
Compilado por: Sandra Sauza Escoto 102
equipo también lleva la impresión a estado de sanía, pero una medida tan drástica no es
simpática para ningún administrador; antes de llegar a eso, detener lpd, eliminar a mano con
rm todos los trabajos en el directorio de spool y arrancar de nuevo lpd.
lpc: comando administrativo, usado para habilitar/deshabilitar la cola de impresión,
habilitar/deshabilitar la impresión en sí, eliminar todos los trabajos de la cola, mover un trabajo
hacia el principio de la cola, manipular el demonio lpd, obtener información de estado. No es
capaz de resolver problemas cuando hay filtros de por medio, no funciona a través de la red, ni
dice siempre la verdad: puede aparentar arreglar todo pero nada funciona. Se usa normalmente
en modo interactivo, disponiendo de diversos comandos:
La opción restart no desbloquea una impresora con un filtro corriendo; usar stop y luego start;
asegurarse de eliminar también el proceso filtro.
La falta de un demonio de impresión para una impresora determinada es normal cuando no hay
trabajos para imprimir: el demonio se activa para imprimir los trabajos y luego desaparece.
Administración de Sistemas Unix de Misión Crítica 103
Impresión System V.
System V no fue diseñado para redes; no ha escalado bien, los fabricantes lo han modificado
bastante, a veces sin razón. Solaris y HP-UX se basan en System V, con muchas
particularidades propias.
Proceso de impresión System V.
Un usuario usa el comando lp para imprimir, ya sea en forma directa o no; lp recibe la entrada
y la coloca en un archivo en el directorio de spool. El demonio lpsched determina cuando debe
imprimirse el archivo, ejecuta el programa de interfaz que da formato al archivo y lo envía hacia
la impresora correspondiente.
En System V se habla de "clases" y "destinos", nombres de hasta 14 caracteres alfanuméricos y
subrraya. Un destino es generalmente una impresora, pero podría ser otra cosa, por ejemplo un
archivo de texto donde todos los usuarios pudieran agregar trozos, resolviendo así el problema
de concurrencia originado en el acceso simultáneo. Una clase es un conjunto de destinos
sirviendo a un propósito común, por ejemplo todas las impresoras de una sección o un local; el
demonio lpsched puede dirigir un trabajo hacia una clase, asignando el destino más
conveniente según los trabajos en cola.
Comandos de impresión System V.
Los comandos más usuales en impresión System V son los siguientes:
lp: comando a nivel de usuario para enviar trabajos a la cola de impresión. El directorio
de spool para una impresora suele ser /var/spool/lp/request/destino, donde
destino es la impresora en cuestión o una clase de impresoras. La opción -ddestino
Compilado por: Sandra Sauza Escoto 104
permite direccionar hacia una impresora o una clase; si se omite, se consulta la variable
de ambiente LPDEST, o en su defecto el dispositivo de impresión por defecto, asignable
con lpadmin -d.
lpsched: demonio que toma los archivos en el directorio de spool, ordenadamente, y los
envía hacia el dispositivo de impresión, cuando esté disponible. Si el destino es una
clase, se dirige al primero que se encuentre disponible. Los errores suelen registrarse en
/usr/spool/lp/log, registrando identificador de trabajo (jobid), usuario, impresora
pedida, impresora asignada, hora de encolado.
lpshut: elimina lpsched, algo necesario para correr lpadmin. Pueden seguirse
enviando trabajos a la cola aunque lpsched no esté presente, pero no serán impresos.
Los trabajos interrumpidos se reimprimirán completos al restaurarse lpsched. Para
arrancar de nuevo correr lpsched.
lpadmin: define la configuración de impresión local. Permite asignar nombre a las
impresoras, crear clases, especificar impresora por defecto. Mantiene la configuración
creando archivos de texto en /usr/spool/lp, pero éstos no deben ser manejados
directamente, ya que son altamente sensibles a formato. La mayoría de los comandos de
lpadmin requieren que lpsched no esté actuando, por lo que es buena práctica
eliminar lpsched antes de usar lpadmin. Como ejemplo, para agregar una impresora,
se requiere un comando de este tipo:
/usr/sbin/lpadmin -pimpresora -vdispositivo
{ -eimpresora | -mmodelo | -iinterfaz }
[ -cclase ... ] [{ -l | -h}]
donde impresora es el nombre a asignar a la impresora, dispositivo el nombre de un archivo en
/dev. Las banderas -e (para impresora existente), -m (modelo del que se tiene interfaz), -i (ruta
al programa de interfaz), son diferentes formas de indicar el programa de interfaz encargado de
dar formato a los trabajos antes de imprimirlos. Para eliminar una impresora,
lpadmin -ximpresora
No debe tener trabajos en cola. Existen muchas otras banderas aceptadas por lpadmin.
lpstat: da información sobre el estado del sistema de impresión. Sin argumentos, da el estado
de todos los trabajos de impresión del usuario; -pimpresora los de una impresora, -r el
estado de lpsched. Hay muchas otras opciones.
LPRng.
Basado en BSD, es un nuevo servidor de impresión, incorpora también lo mejor de System V.
Todos los comandos BSD están disponibles, pero sustituidos por los de LPRng, más potentes y
confiables. Los más importantes comandos System V están implementados como enlaces a sus
versiones BSD; LPRng examina como fueron invocados, y se comportan según lo esperado.
LPRng prescinde de la necesidad de correr procesos como root e implementa muchas
precauciones de seguridad. Tiene buenas rutinas de diagnóstico, produce mensajes útiles y
claros en caso de error. Implementa redirección dinámica de colas de impresión, soporta varias
impresoras en una misma cola, balancea la carga entre varias impresoras y otras maravillas,
muchas de ellas inspiradas en System V.
En ambientes chicos de pocos usuarios y pocas impresoras puede no jusficarse el esfuerzo de
configuración, pero puede aún valer la pena colocar LPRng en el servidor: resuelve muchos de
los problemas tradicionales en los sistemas de impresión UNIX.
Compilado por: Sandra Sauza Escoto 106
Densidad Opcional
Compilado por: Sandra Sauza Escoto 108
l baja
m media
h alta
u ultra
c comprimido
Si no se especifica la densidad, una unidad de cinta magnética escribe en su densidad por
omisión o por default. La densidad por omisión por lo general es la densidad más alta que la
unidad de cinta magnética soporta. La mayor parte de dispositivos SCSI pueden
automáticamente detectar la densidad o formatear sobre la cinta y leerlo en consecuencia. Para
determinar diferentes densidades que son soportadas por una unidad, revisar el
subdirectorio/dev/rmt.
Este subdirectorio incluye los archivos de dispositivo de cinta que soportan diferentes
densidades de salida.
También, un controlador SCSI puede tener un máximo de siete unidades de cinta magnética
SCSI.
Especificando la opción de rebobinado cintas
Normalmente, usted especifica una unidad de cinta por su número de unidad lógico, que puede
ser desde 0 a n.
La tabla siguiente describe como especificar nombres de dispositivo de cinta con la opción
rebobinado o sin rebobinado.
Unidad de disco y valor de rebobinado usan esta opción
Primer unidad de disco, rebobinado /dev/rmt/0
Primer unidad de disco, no rebobinado /dev/rmt/0n
Segunda unidad de disco, rebobinado /dev/rmt/1
Segunda unidad de disco, no rebobinado /dev/rmt/1n
Especificar densidades diferentes para una unidad de cinta
Por omisión, la unidad escribe en la densidad preferida, que es generalmente la densidad más
alta que la unidad de cinta soporta, como ya se menciono con anterioridad. Si no especifica un
dispositivo de cinta, el comando escribe a la unidad numero 0 en la densidad soportada.
Transportar una cinta a un sistema cuya unidad de cinta soporta solamente cierta densidad,
especifica un nombre de dispositivo que escribe en la densidad deseada.
La tabla siguiente describe cómo especificar las densidades diferentes para una unidad de cinta
Unidad de disco, Densidad, y el valor de Rebobinado usan esta Opción Primero unidad,
densidad baja, rebobinan/dev/rmt/0l
Primero unidad, densidad baja, ningún rebobinado/dev/rmt/0ln
Administración de Sistemas Unix de Misión Crítica 109
Recomendaciones generales.
Las siguientes recomendaciones no son universales ni infalibles, pero surgen de la experiencia.
Respaldar todo desde la misma máquina: aunque es más lento, la facilidad de
administración y la posibilidad de verificar la corrección del respaldo en todas las
máquinas justifica su realización a través de la red. Se corre rdump en la máquina
remota a respaldar, vía rsh, dirigiendo la salida hacia la unidad de respaldo en la
máquina local. Al restaurar, deben tomarse en cuenta eventuales diferencias de sistema
Administración de Sistemas Unix de Misión Crítica 111
operativo; en algunos casos hay inversión de bytes, que pueden arreglarse con dd; esto
no resuelve diferencias entre versiones de rdump.
Etiquetar las cintas: fecha, hora, máquina, sistema de archivos, número serial
constituyen el mínimo absoluto. Una cinta no identificada sólo sirve para ser regrabada.
Los sistemas de archivos / y /usr deben poder restaurarse sin referencia alguna a scripts
o información en línea; la sintaxis exacta de los comandos, densidades, opciones y otros
valores deben figurar en la documentación de la cinta. Un registro más completo se hace
imprescindible cuando se respaldan muchos sistemas de archivos en un mismo
volumen.
Intervalo de respaldos razonable: el sistema de archivos de usuarios puede
respaldarse a diario en sistemas grandes, o semanalmente en sistemas chicos; la
frecuencia de respaldo para otros sistemas de archivos dependerán del uso y la
criticidad. El respaldo consume recursos y tiempo de operador; es responsabilidad del
administrador del sistema balancear costos y riesgos al definir frecuencias de respaldo
sobre cada sistema de archivos.
Elegir sistemas de archivo: según el movimiento, cada sistema de archivos puede
tener un esquema diferente. Un grupo de archivos muy activo en un sistema de archivos
inactivo puede copiarse diariamente hacia otro sistema de archivos con respaldo diario.
Sistemas de archivos de noticias, o el sistema de archivos /tmp, no deben respaldarse;
las noticias son efímeras, y /tmp no debe contener nada importante.
Respados diarios en un solo volumen: buscar un esquema o un medio para que el
respaldo diario quepa en un solo volumen; es la única forma simple de realizar un
respaldo diario, cargando la cinta a última hora y ejecutando el respaldo en cron.
Recordar: el respaldo de varios sistemas de archivos en una cinta única requiere usar el
dispositivo no rebobinado y documentar bien las cintas.
Crear sistemas de archivo acordes con el tamaño del medio de respaldo: con las
capacidades actuales, es posible crear sistemas de archivo de tamaño razonable que
quepan en una cinta. Debe haber una buena razón para crear sistemas de archivo muy
grandes.
Mantener las cintas fuera del lugar: pero realmente en otro lugar, apartado del lugar
de la instalación; hay innumeras historias sobre pérdida de los respaldos conjuntamente
con el sistema. El volumen actual de medios es suficientemente reducido como para
trasladar un montón de información en un portafolios. Puede recurrirse a una institución
especializada en conservación de datos o llevar las cintas a casa del gerente.
Seguridad del respaldo: el robo de un respaldo equivale al robo de toda la información
vital de una organización. Las precauciones de seguridad con los respaldos debe ser
tanta como la dispensada al propio sistema, con el agravante de que es más fácil
llevarse unas cintas que la información en disco.
Limitar la actividad durante dump: la actividad en los archivos mientras se ejecuta
dump puede ocasionar confusión en el momento de restaurar. Esto no es tan crítico en
niveles superiores, pero sí en el nivel 0. Puede hacerse el respaldo en horas de escasa
actividad, nocturnas o en fin de semana. Es preciso cuidar de no coincidir con los
programas del sistema que modifican el sistema de archivos; éste debe permanecer
estacionario mientras se realiza el respaldo. La solución más segura es hacer el respaldo
en monousuario. En ocasiones especiales, como al encarar una actualización del
Compilado por: Sandra Sauza Escoto 112
La historia ha demostrado que el TCP/IP nacido desde el UNIX es el protocolo de redes más
difundido en la actualidad y que ha superado otras estructuras como el clásico modelo OSI de
ISO.
Paquetes
El UNIX soporta variadas redes físicas, por ejemplo Ethernet, token ring y sistemas basados en
módems. Las variedades de hardware son manejadas dentro de la capa de Enlace de Datos en
el modelo TCP/IP y los protocolos de mayor nivel no se enteran de las características del
hardware subyacente.
Las conexiones con diferentes redes de una máquina UNIX se conocen como interfaces de
red.
Una máquina con más de una interfaz puede transferir paquetes que llegan por una de esas
interfaces y retransmitirla hacia otra interfaz, en ese caso se dice que la máquina actúa como
enrutador (o router). Los problemas más complejos de redes están asociados a problemas de
enrutamiento.
La información viaja por la red en forma de paquetes, los cuales tiene una carga y un
encabezado. El encabezado dice de donde viene, hacia donde va, que protocolo, etc. y la carga
son los datos útiles.
A diferentes niveles de la estructura de capas estas unidades se conocen normalmente con
diferentes nombres. A nivel de capa de enlace de datos se llaman tramas, a nivel de red se
llaman paquetes, a nivel de transporte se llaman segmentos y a nivel de aplicación se llaman
mensajes.
A medida que la información pasa por la estructura de capas cada una de ellas le agrega
información de cabecera e incluye la unidad de la capa superior dentro de la carga. Por ejemplo
un segmento UDP se transmite en un medio Ethernet:
El tamaño del paquete puede limitarse por causas de hardware o por convenciones del
protocolo. Por ejemplo la carga de una trama Ethernet no puede ser superior a 1500 bytes, el
largo máximo de un paquete IP es de 64 Kbytes pero en general hay limitaciones que no
permiten ese tamaño. La limitación de una red o protocolo en el tamaño del paquete se llama
MTU (Maximun Transfer Unit).
Administración de Sistemas Unix de Misión Crítica 115
La capa IP es la responsable de fragmentar los paquetes para adecuarse a la MTU de una red
en particular.
Direccionamiento de paquetes
Para que los paquetes lleguen a destino es necesario que contengan direcciones. Las
direcciones existen a varios niveles en la estructura de capas.
En el nivel de capa de enlace, existen direcciones Ethernet que son de 6 bytes, que están pre-
configuradas por el fabricante de la tarjeta y son únicas en el mundo. En Token Ring existen
también direcciones de capa de enlace y en enlaces PPP y SLIP como son conexiones punto a
punto no es necesario utilizar direcciones.
En el nivel IP, existen direcciones IP que son cuatro bytes asignados a la interfaz de red, únicas
en el mundo y no asociadas al dispositivo hardware. Son asignadas para permitir el
encaminamiento de los paquetes de una máquina origen a otra destino.
Son asignadas por InterNIC.
La correlación entre direcciones de capa de enlace y direcciones de capa de red es necesaria
en las redes de difusión y para hacer esta relación existe el protocolo arp. Este protocolo
permite implementar esta correlación en forma automática o sea sin la intervención del
administrador. Esto tiene importantes ventajas pues es posible cambiar la tarjeta de red a una
computadora sin necesidad de configurar a mano el cambio de dirección de capa de enlace.
Las direcciones IP se escriben por convención de la forma: 164.73.224.40 y claramente no son
fáciles de recordar y por eso los sistemas UNIX permiten asociar nombres a las direcciones
para poder referirse a máquinas por su nombre y no por su dirección. El UNIX posee varios
mecanismos de implementar esa conversión de nombres a números. La forma más básica es
mediante el archivo /etc/hosts que tiene esa relación y la más usada en Internet es a través del
servicio de Servidor de Nombres DNS.
Es de destacar que el software de red no conoce de nombres sin de direcciones y el servicio de
relación entre números y nombres es una aplicación de usuario y no parte del software de red.
Las direcciones IP identifican máquinas pero no servicios dentro de esas máquinas. Para
identificar servicios existe el concepto de PUERTOS que son las direcciones de capa de
transporte. Los números de puertos son de 2 bytes y hay un conjunto de puertos llamados
"bien-conocidos" ("well-known ports") que se han estandarizado para los diferentes servicios.
Por ejemplo el servidor de telnet atiende en el puerto 23, el servidor de correo electrónico en el
puerto 25, etc. La asignación de puertos puede verse en un archivo que relaciona números con
nombres de servicios y que se llama /etc/services.
Direcciones en Internet
Las direcciones Internet tienen cuatro bytes y se dividen en una parte de numeración de red y
otra de numeración de máquina.
En las decisiones de enrutamiento se utiliza esta división para saber si una máquina está en la
propia red o por qué camino debe encaminarse para llegar a destino.
Por convención se anotan en decimal separados por puntos entre los 4 bytes. Ejemplo
164.73.224.40
Compilado por: Sandra Sauza Escoto 116
Hay varias clases de direcciones IP. Difieren en como se asigna la frontera entre parte de red y
parte de máquina.
A 1-126 R.M.M.M
C 192-223 R.R.R.M
D 224-239 - Multicast
E 240-254 - Experimental
Si en los bits reservados para números de máquina de una red colocamos ceros, entonces nos
estaremos refiriendo a toda esa red. Es el nombre de la red y por lo tanto los ceros están
reservados a esta identificación. Si todos los bits de la parte de máquina son unos, entonces se
considera una dirección de broadcast dentro de esa red por lo que todas las máquinas de la red
deben escuchar esa dirección.
Si el primer byte de una dirección es el 127, se refiere a una red ficticia llamada "loopback" y
que no se refiere a una interfaz física. Tiene sentido dentro de una misma máquina y los
paquetes enviados a esa dirección no salen de la propia máquina, recorren la pila de protocolos
del TCP/IP y vuelven a la máquina como si hubieran sido recibidos por ésta a través de alguna
de las interfaces físicas.
Los paquetes IP se enrutan usando las direcciones IP, sin embargo, en redes de difusión
(particularmente Ethernet) es necesario tener una relación entre direcciones IP y direcciones de
capa de enlace de datos. Este relacionamiento se realiza mediante el protocolo ARP.
La idea es que si estoy en una red Ethernet y tengo que enviar un paquete IP a una máquina de
mi misma red, debo enviar ese paquete encapsulado en una trama Ethenet. Para saber a que
dirección de capa de enlace debo enviar dicha trama, tengo que averiguar cuál es la dirección
de capa de enlace que se corresponde con la dirección IP a la cual quiero enviar el paquete.
El ARP mantiene una tabla en memoria con la correspondencia entre direcciones de capa de
red y direcciones de capa de enlace de datos. Si ARP tiene en su tabla la dirección de capa de
enlace asociada a la dirección IP a la cual quiero referirme, se forma una trama Ethernet con
dicha dirección ethernet como destino.
Si ARP no posee en su tabla dicha correspondencia, es el encargado de averiguarlo. A estos
efectos genera una trama de difusión "Broadcast" de capa de enlace preguntando:
¿ Quién tiene la dirección IP 22.22.22.22 ?
Ese broadcast de capa de enlace es obviamente escuchado por todas las máquinas de la red
Ethernet y entonces aquella que tenga configurada esa dirección IP, responderá diciendo:
Administración de Sistemas Unix de Misión Crítica 117
Para ir a la red A (número de red y máscara), envíe los paquetes a la máquina B, con
un costo de 1 salto.
Asimismo existe una ruta por default donde se envían todos los paquetes destinados a redes
para las cuales no tenemos rutas explícitas.
La tabla de ruteo se recorre de lo más específico a lo más general. Si no hay ruta específica
para dirigirse a un destino y no hay ruta default, el sistema enviará un mensaje de "network
unreacheable". Esta especificidad se determina por el largo de la máscara. Cuanto más
cantidad de unos tenga la máscara, más específica será la ruta.
Desde el punto de vista del enrutamiento IP, toda la información necesaria se almacena en la
tabla de ruteo, el problema es determinar si la tabla tiene la información adecuada.
La tabla de ruteo de una máquina puede examinarse con el comando netstat. La opción -r del
mismo muestra la tabla de ruteo (la opción -n es para no convertir números en nombres).
En un FreeBSD, por ejemplo la salida resumida del comando netstat -rn sería
# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
Default 164.73.224.28 UGSc 33 36932 ed1
127.0.0.1 127.0.0.1 UH 16 45450 lo0
164.73.224/25 link#1 UC 0 0
164.73.224.1 8:0:2b:14:a1:21 UHLW 5 198078 ed1 1039
164.73.224.40 48:54:e8:26:db:69 UHLW 1 1908914 lo0
164.73.224.60 0:0:21:95:90:34 UHLW 4 0 ed1 840
164.73.224.128 164.73.224.60 UGHD 0 2 ed1
En un Linux RedHat, por ejemplo la salida del comando netstat -rn sería de la forma:
17 ludmilla ~ >netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
Las rutas pueden ser estáticas o dinámicas. Las rutas estáticas se establecen manualmente
con el comando route, por ejemplo:
route add -net 222.222.222.0 164.73.224.28 1
Las rutas estáticas son una solución confiable en redes pequeñas pero el administrador debe
conocer la topología de la red.
Dinámicamente las rutas pueden modificarse a través de un demonio que se comunican con
otros enrutadores intercambiándose información para actualizar las tablas.
En UNIX está disponible el routed en forma estándar y existe también el gated que tiene más
potencia.
Protocolos de enrutamiento
Los protocolos de enrutamiento son el lenguaje en que los demonios de ruteo intercambian
información acerca de la red.
Se clasifican en protocolos de enrutamiento exterior (IGP) y protocolos de enrutamiento exterior
(EGP). Los IGP se usan al interior de lo que se llaman sistemas autónomos que son un
conjunto de máquinas administradas por una autoridad común. Los EGP se usan entre
sistemas autónomos. La diferencia es que los IGP tratan de optimizar el enrutamiento entre una
red compleja con muchos caminos alternativos y los EGP tratan de optimizar el enrutamiento
teniendo en cuenta que los caminos son normalmente pocos porque los sistemas autónomos se
interconectan entre si con pocos enlaces.
Los diferentes protocolos utilizan distintas métricas para estimar el costo de cada ruta. Los
costos pueden medirse en saltos, retardo, etc. Los EGP en general no toman demasiado en
cuenta los costos porque normalmente no hay demasiadas rutas alternativas pero si tratan de
optimizar la posibilidad de alcanzar una determinada red.
Hay varios protocolos utilizados comúnmente. Algunos de ellos son:
RIP - Routing Information Protocol
OSPF - Open Shortest Path First
IGRP - Interior Gateway Routing Protocol
EGP - Exterior Gateway Protocol
BGP - Border Gateway Protocol
Compilado por: Sandra Sauza Escoto 120
RIP es el protocolo usado por el demonio routed estándar en UNIX. El costo de las rutas se
mide en saltos, donde cada salto es un enrutador por el cual pasan los paquetes. Hay dos
versiones: la 1 no tiene soporte para máscaras y la 2 sí.
OSPF funciona bien en redes grandes y es más difícil de configurar. IGRP es un protocolo
propietario de Cisco previo al OSPF.
El estándar actual de EGP es el protocolo BGP en su versión 4.
Redirecciones ICMP
Aunque IP no se encarga del manejo de la tabla de ruteo tiene algunas funciones para facilitar
la configuración de enrutamiento.
Si un enrutador envía un paquete a una máquina cuya dirección IP de origen es de la misma
red que el destino, es claro que algo no funciona muy bien, ya que la máquina origen podría
haber enviado directamente el paquete a la máquina destino sin pasar por el enrutador.
El enrutador puede concluir que las tablas de ruteo de la máquina origen no están muy
ajustadas. En este caso el enrutador puede notificar al originador de este problema mediante un
paquete ICMP del tipo redirect. Ese paquete dice: "Para dirigir paquetes a la máquina XX,
debería enviarlos a través a router YY"
Si el originador es bien comportado, debería introducir en sus tablas la información indicada,
para que los próximos paquetes dirigidos hacia XX sean enviados por YY, es decir por el
camino directo.
Este sistema permite configurar las máquinas con solamente una ruta por defecto y dejar que
por el mecanismo de los ICMP redirects vayan aprendiendo las rutas alternativas. Obviamente
no es muy eficiente porque hay un tráfico extra para transmitir la información de redirección.
Subredes
Las clases A y B permiten respectivamente redes de 16 millones y 64 mil máquinas
respectivamente, pero es muy raro que existan redes con esa cantidad de máquinas. Entonces
se utiliza un mecanismo para dividirlas que se llama "subnetting".
El método consiste en pedir prestados bits de la parte correspondiente a la numeración de
máquina para extender la parte de numeración de red. Para especificar hasta donde va la parte
de red y cual es la parte de máquina, se utiliza la máscara de subred. La máscara son 32 bits
que van en 1 los correspondientes a la parte de red y en 0 los de la parte de máquina.
La configuración de la máscara de red se utiliza en el momento de configurar la interfaz de red
mediante el comando ifconfig. Si no ponemos máscara el sistema la toma según las normas
para las clases A, B o C. Si se especifica la máscara, se sobreescribe el valor por defecto.
La ventaja es que para el resto de la red se sigue siendo por ejemplo una clase B y solamente
al interior de la organización es necesario conocer como se llega a las diferentes subredes.
CIDR: Classless Inter-Domain Routing
Con el crecimiento de Internet, se produce el fenómeno que las tablas de ruteo a nivel del
backbone, crecen mucho porque hay muchísimas clases C para cada una de las cuales se
requiere una entrada en la tabla.
Administración de Sistemas Unix de Misión Crítica 121
La idea del CIDR es extender el concepto de máscara para agrupar ahora varias redes clase C
por ejemplo en una sola entrada en la tabla de ruteo.
La idea es que si por ejemplo las redes 199.128.0, 199.128.1, 199.128.2 y 199.128.3 se
acceden por la misma salida, puedo poner una sola entrada para una red que tiene la primer
parte igual o sea con una máscara FFFFFC00.
Elección de una estrategia de enrutamiento
Hay en principio cuatro estrategias de enrutamiento:
Ninguno
Rutas estáticas
Rutas estáticas pero escuchando mensajes de RIP
Enrutamiento dinámico
La topología de la red tiene una influencia muy importante en la estrategia a tomar. Las
diferentes topologías tienen diferentes requerimientos.
Las siguientes reglas pueden ayudar a tomar la decisión de qué estrategia seguir.
Una red aislada no requiere reglas de enrutamiento
Si hay una sola salida de esa red al mundo, las máquinas pueden tener solamente una
ruta por defecto hacia el enrutador que comunica la red con el mundo.
Un enrutador con pocas redes hacia un lado y con una salida al mundo por otro, puede
configurarse con rutas estáticas, aunque si hay más de una alternativa sería deseable
que escuchara mensajes de enrutamiento dinámico.
Aunque se utilice RIP, tratar de que no envíe actualizaciones a intervalos muy cortos
para reducir el tráfico. El routed normalmente hace eso y es posible entonces utilizar
gated al cual puede configurársele que envíe información a determinados enrutadores y
no por difusión.
Para que los clientes escuchen información de ruteo en forma pasiva (sin informar de sus
rutas) puede usarse el routed con la opción -q. También puede configurarse el gated en
esa modalidad.
El routed cree todo lo que escucha, con lo cual es más confiable usar gated configurado
en forma más controlada.
El enrutamiento dinámico debe ser usado donde hay fronteras políticas o administrativas
de la red.
Configuración de una red
Para configurar una red se requieren los siguientes pasos:
Planificar la estructura física y lógica de la red
Asignación de direcciones IP
Instalación del hardware de red
Compilado por: Sandra Sauza Escoto 122
Configurar los equipos para que reconozcan y configuren las conexiones de red en
tiempo de arranque
Configurar las rutas estáticas necesarias o los demonios de enrutamiento
Se abarca la configuración en una red ethernet. Los aspectos de las conexiones punto a punto
quedan fuera de este tema.
Se supondrá que ya se tiene configurada la interfaz desde el punto de vista hardware y se hará
referencia a la configuración desde el punto de vista lógico del sistema.
Obtener y configurar las direcciones IP
Las direcciones IP deben ser únicas en Internet, por lo que son asignadas por un organismo
central llamado IANA (Internet Assigned Numbers Authority) normalmente a través de un
proveedor de servicio (ISP).
Hay que tener en cuenta que las direcciones IP no se asignan a máquinas sino a interfaces, por
lo que una máquina con varias interfaces requerirá varias direcciones IP.
Además de asignarle una dirección IP es recomendable asignar un nombre y configurarlo por lo
tanto en el DNS (Domain Name Server).
Configurar las interfaces de red: ifconfig
El comando ifconfig se utiliza para configurar las direcciones IP, máscaras y direcciones de
difusión de las interfaces de red.
Normalmente es ejecutado en tiempo de arranque pero puede ejecutarse a mano para hacer
cambios al vuelo de la configuración de las interfaces.
La sintaxis más común es:
Para configurar rutas estáticas se utiliza el comando route que permite agregar y borrar rutas.
Además de las rutas agregadas a mano en la tabla de ruteo, puede estar corriendo algún
demonio para mantener rutas dinámicas.
Normalmente hay una red que siempre hay que configurar a mano y es la ruta por defecto.
El comando route tiene la siguiente sintaxis simplificada:
El demonio routed es el estándar en UNIX como demonio de ruteo dinámico. Es muy simple
pero es consumidor de recursos. La tendencia debería ser a pasarse al gated pero no todos los
sistemas lo traen aunque está disponible en forma pública para la mayor parte de las
plataformas.
El routed solo sabe hablar RIP que es un protocolo simple que usa los saltos como métrica
para medir el costo de las diferentes rutas. Es un protocolo que funciona enviando paquetes de
difusión "broadcast" cada 30 segundos publicando las rutas que conoce. La información que
recibe de sus vecinos, la junta con las que posee y con las tablas de ruteo del kernel.
El routed puede funcionar en modo servidor (invocado con -s) o en modo "quiet" (invocado con
-q). En ambos modos escucha la información de RIP que le llega pero solo en modo servidor
informa de las rutas que posee hacia los demás enrutadores. Si la máquina tiene más de una
interfaz, por defecto funciona en modo servidor y si tiene una sola por defecto funciona en modo
"quiet".
El routed no requiere configuración y dinámicamente escucha RIP y actualiza las tablas de
ruteo. Si se tiene solo un camino para salir al mundo puede ejecutarse con la opción -g para
que propague la ruta hacia el mundo como ruta por defecto.
Compilado por: Sandra Sauza Escoto 124
Se puede usar el archivo /etc/gateways cuando se tiene más de una salida. El archivo tiene
líneas similares a comandos route.
En los sistemas más viejos, la configuración de la red se hacía directamente modificando los
archivos básicos de arranque (/etc./rc o /etc./rc.local), actualmente casi todos los sistemas
tienden a que no se modifiquen los scripts de arranque sino que se modifiquen algunos archivos
de los cuales los scripts de arranque toman variables.
En todos los sistemas se llaman diferente los archivos de configuración o los scripts donde se
encuentran las configuraciones de red.
Diagnóstico de fallas de red
Hay muchas herramientas para determinar problemas de red TCP/IP en UNIX. En general la
información que brindan es de bajo nivel por lo que es necesario saber como funciona el TCP/IP
y como se realiza el enrutamiento.
Ver si las máquinas están vivas: ping
El comando ping utiliza el mensaje ECHO_REQUEST del protocolo ICMP para pedir a una
máquina que responda con un mensaje ECHO_REPLY del mismo protocolo para verificar que
dicha máquina esta viva.
Esto es solo una función de bajo nivel que no requiere procesamiento en la máquina destino.
Sirve para probar:
Que la máquina este encendida
Que tenga configurado el protocolo TCP/IP
Que existan rutas para llegar desde la máquina origen a la destino y de la máquina
destino a la origen.
Si alguna de estas condiciones no se cumple el comando ping informará que la máquina no
responde.
A su vez, que el comando ping informe que una máquina está viva solamente indica que se
cumplen las condiciones establecidas pero no indica que funcionen o no otros protocolos de
nivel superior u otros servicios que esa máquina deba o pueda brindar.
Hay una versión más vieja del comando ping que solamente dice si la máquina está viva o no.
Las versiones más modernas, quedan en un loop infinito hasta que se presione Control-C. En
la versión vieja es posible que exista alguna opción para entregar una salida extendida modo
loop. Ejemplo ping -s (SunOS) o ping -l (Ultrix).
Las salidas de la vieja versión del ping (Ejemplo en SunOS) son del tipo:
• # ping ampere
ampere.iie.edu.uy is alive
#
Administración de Sistemas Unix de Misión Crítica 125
# ping acer
PING acer.iie.edu.uy (164.73.224.3): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
^C
--- acer.iie.edu.uy ping statistics ---
7 packets transmitted, 0 packets received, 100% packet loss
#
La salida detallada en caso de éxito, contiene la dirección IP de la máquina destino, la
secuencia de los paquetes ICMP y el tiempo de ida y vuelta de las respuestas.
Compilado por: Sandra Sauza Escoto 126
Además, luego del Control-C da las estadísticas de paquetes enviados y respuestas recibidas.
Es interesante notar que si bien el IP no garantiza entrega de paquetes, normalmente a menos
que la red esté muy cargada, todos los paquetes deberían llegar a destino. Si se pierden
paquetes puede ser por exceso de carga y es posible que los proto0colos de mayor nivel igual
funcionen aunque deberán utilizar retransmisiones haciendo que las cosas funcionen más
lentamente.
En caso de paquetes perdidos es importante tratar de detectar el motivo ya que puede deberse
a problemas físicos en la red y sería deseable poder solucionarlos.
# netstat
Active Internet connections
• Linux RedHat
• # netstat
• Active Internet connections (w/o servers)
• Proto Recv-Q Send-Q Local Address Foreign Address
State
• tcp 0 252 ludmilla.iie.edu.uy:ssh ampere.iie.edu.uy:3690 ESTABLISHED
• tcp 1 0 ludmilla.iie.edu.u:1431 ampere.iie.edu.uy:3128 CLOSE_WAIT
• tcp 1 0 ludmilla.iie.edu.u:1430 ampere.iie.edu.uy:3128 CLOSE_WAIT
• tcp 0 0 ludmilla.ii:netbios-ssn cachimba.iie.edu.u:1135 ESTABLISHED
Recv-Q y Send-Q son los tamaños de las colas para dicha conexión en la máquina local.
Deberían tender a 0.
El estado de la conexión solo tiene sentido para TCP puesto que UDP es un protocolo no
orientado a conexión. Los estados posibles son: ESTABLISHED (conexión establecida),
LISTENING (para servicios que están esperando por conexiones, normalmente no aparecen a
menos que usemos la bandera -a) o TIME_WAIT (para conexiones en proceso de cierre). Hay
otros estados posibles en caso de fallas, como por ejemplo SYN_SENT que significa que
estamos tratando de establecer una conexión con una máquina que seguramente no responde.
Configuración de las interfaces de red
Invocado con la opción -i el comando netstat muestra la información de las interfaces de red.
Ejemplos:
• FreeBSD
# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
• Linux RedHat
# netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
Las direcciones se brindan en formato simbólico (nombres) a menos que usemos la opción -n.
Las colisiones indican estado de carga de la red (deberían ser menores de un 3% de los
paquetes procesados en una red poco cargada). Los Ierrs y Oerrs se deben normalmente a
problemas de cables.
Las interfaces indicadas con un asterisco (*) después de su nombre indican que no están
configuradas.
Si se especifica un número luego del netstat -i número se brinda la estadística en el número de
segundos indicado de los paquetes entrantes, salientes, colisiones y errores.
Se puede hacer que la salida refiera solamente a una interfaz de red utilizando la bandera -I
interfaz.
Compilado por: Sandra Sauza Escoto 128
destination unreachable: 84
source quench: 1
routing redirect: 3
echo: 2
time exceeded: 3
address mask request: 3
2 message responses generated
igmp:
0 messages received
0 messages received with too few bytes
0 messages received with bad checksum
0 membership queries received
0 membership queries received with invalid field(s)
0 membership reports received
0 membership reports received with invalid field(s)
0 membership reports received for groups to which we belong
0 membership reports sent
tcp:
78664 packets sent
67591 data packets (20378697 bytes)
1005 data packets (1073929 bytes) retransmitted
8432 ack-only packets (8247 delayed)
0 URG only packets
3 window probe packets
1489 window update packets
144 control packets
76819 packets received
51806 acks (for 20382773 bytes)
2125 duplicate acks
0 acks for unsent data
55295 packets (7943243 bytes) received in-sequence
Administración de Sistemas Unix de Misión Crítica 131
♦ traceroute máquina
La máquina puede estar indicada mediante su número IP o su nombre. Es posible además
incorporar la opción -n en la línea de comando con la cual no se hace la correspondencia entre
nombres y números IP de las máquinas involucradas. Hay además otra cantidad de opciones
de uso menos frecuente.
La salida del traceroute es algo del estilo:
# traceroute seciu.edu.uy
traceroute to seciu.edu.uy (164.73.128.5), 30 hops max, 40 byte packets
1 IIE-FING-GW (164.73.224.28) 1.720 ms 1.812 ms 1.630 ms
2 FING-RAU-GW.fing.edu.uy (164.73.32.121) 3.643 ms 3.627 ms 3.726 ms
3 164.73.162.113 (164.73.162.113) 286.303 ms 111.015 ms 28.714 ms
4 seciu.uy (164.73.128.5) 33.604 ms 26.355 ms 33.572 ms
En la salida se observa por un lado los nombres y direcciones IP de los enrutadores por los que
pasa un paquete originado en la máquina que corre el tcpdump y el destino especificado en la
línea de comandos.
Además de nombres y direcciones IP, aparecen tres valores del tiempo de ida y vuelta (round-
trip time, RTT) para alcanzar los enrutadores de la lista.
El comando funciona enviando un paquete a destino con un tiempo de vida de 1 salto. Al llegar
al primer enrutador, este deberá descartarlo y enviar un mensaje ICMP al origen indicando que
este paquete fue descartado. De esta forma el originador obtiene la dirección IP del primer
salto. Ahora construye un paquete con tiempo de vida 2 que será descartado por el segundo
enrutador y así sucesivamente.
Para cada salto, el traceroute envia 3 paquetes y da el tiempo de ida y vuelta de cada uno (ver
ejemplo). Si algún enrutador no responde igual puede seguir al siguiente salto y pone
asteriscos. Si los 3 paquetes vuelven de diferentes enrutadores, se despliegan las direcciones
de cada uno de ellos.
Monitores de tráfico: tcpdump, snifit, snoop, etherfind, etherreal.
Estos programas son conocidos como espías de red y lo que hacen es mirar los paquetes que
pasan por una conexión IP. Se pueden establecer criterios de inspección basados en máquinas,
protocolos, servicios, etc.
Administración de Sistemas Unix de Misión Crítica 133
El tcpdump es una herramienta muy potente disponible en casi todas las variedades de
sistemas BSD y es distribuido dentro del sistema en varios UNIX.
El etherfind es un comando disponible en SunOS y la versión de solaris es el snoop. Ambos son
similares al tcpdump.
Como los espías deben poder ver los paquetes dirigidos a otras máquinas de la red el sistema
de base debe dar los mecanismos para que esto pueda realizarse. Para esto debe existir la
posibilidad que el hardware de red pueda ver todos los paquetes. Esto, en un medio de difusión
tipo Ethernet es posible.
Otro mecanismo adicional que debe proveer el sistema es el pasaje de los paquetes que no
están dirigidos a la máquina a las capas superiores de la red. Normalmente una máquina define
a nivel de hardware si los paquetes son para ella o no (contienen su dirección IP o son
broadcasts) y si no lo son los descarta. Para que el tcpdump pueda acceder a todos los
paquetes de la red, es necesario que la interfaz de red se configure en modo promiscuo lo
cual significa que pasará a las capas superiores los paquetes destinados a ella así como los
que no están destinados a ella de forma tal que el tcpdump pueda verlos.
Estas herramientas son muy útiles para detectar problemas en la red.
Inspección de tablas de ARP
El comando arp permite ver la tabla de correspondencia del kernel del protocolo ARP. Estas
tablas se actualizan automáticamente.
Opciones:
• arp -a permite ver la totalidad de la tabla.
arp -d máquina borra la entrada de una máquina.
arp -s máquina dirección agrega una entrada en la tabla.
arp -f archivo agrega entradas desde un archivo de configuración.
arp máquina muestra la entrada para esa máquina.
En general en una Ethernet no tiene demasiada utilidad para detectar problemas, pero si puede
ayudar en caso de tarjetas de red con problemas.
Compilado por: Sandra Sauza Escoto 134
El siguiente ejemplo muestra como crear un área de swap adicional de 100 Mb llamada
/archive/archivoswap
# mkdir /archivo
# mkfile 100m /archivo/archivoswap
# swap -a /archivo/archivoswap
# vi /etc/vfstab
Agregando la entrada al archive /etc/vfstab
Adding More Swap Space
(An entry is added for the swap file):
/archivo/archivoswap - - swap - no -
# swap -l
swapfile dev swaplo blocks free
/dev/dsk/c0t0d0s1 136,1 16 1638608 1600528
/archivo/archivoswap - 16 204784 204784
Para eliminar un archivo o dispositivo del pool de swap es necesario hacer uso de la opcion –d
del comando swap.
Ejemplo
Para eliminar /archivo/archivoswap y /dev/dsk/c1t1d2s1 del pool de swap:
# swap -d /archivo/archivoswap
# swap -d /dev/dsk/c1t1d2s1
También se debe eliminar o borrar la línea que se agrego en el archivo /etc/vfstab , sin olvidar
borrar el archivo /archivo/archivoswap para el caso del archivo, en el caso del dispositivo,
utilizarlo para otro propósito diferente al de paginación o swapping.
El comando /usr/sbin/swap es usado para manejar las áreas de swap.
La opción –l y la opción –s dan información respecto a los recursos de memoria swap
The /usr/sbin/swap command is used to manage swap areas. Two options, -l and -s, display
information about swap resources.
Compilado por: Sandra Sauza Escoto 136
Específicamente la opcion –l nos da el área de swap del sistema y el dispositivo o los archivos
donde se encuentra activada
# swap -l
swapfile dev swaplo blocks free
/dev/dsk/c0t0d0s1 136,1 16 1638608 1600528
Swap –s proporciona la información referente a los recursos actuales de swap en el sistema
# swap -s
total: 57416k bytes allocated + 10480k reserved = 67896k used,
833128k available
Administración de Sistemas Unix de Misión Crítica 137
14. ADMINISTRACIÓN D E
PROCESOS
Prioridad de ejecución y valor "nice"
Cuando hay más de un proceso en el estado "listo para ejecutar", el kernel le asigna el uso de
la CPU al de mayor prioridad en ese momento. En el caso de Unix esta prioridad varía
dinámicamente. Las diferentes versiones y sabores de Unix utilizan diferentes algoritmos de
planificación del uso de la CPU (algoritmos de scheduling), pero en todos los casos tienen
características similares:
procuran ser justos con los diferentes procesos.
procuran dar buena respuesta a programas interactivos.
Para eso los algoritmos consideran parámetros como cuanto uso de CPU ha hecho el proceso
recientemente, si pasa mucho tiempo dormido a la espera de un evento de teclado (sería un
proceso interactivo), etc.
El administrador del sistema o el usuario dueño de un proceso pueden influir en el algoritmo de
scheduling a través del llamado valor nice. Este es un número que se asigna a cada proceso e
indica que tan "nice" es el proceso para con los demás. Este valor es considerado por el
algoritmo de scheduling de manera que un proceso con valor nice alto estará en desventaja
frente a otro con valor nice menor a la hora de decidir a quien asignar la CPU. Como ejemplo
veamos el algoritmo utilizado por alguna versión de AIX:
P = min + nice + (0.5 x recent)
Donde P indica la prioridad dinámica (a menor P mayor prioridad) y recent es una medida de
cuanto ha recibido la CPU el proceso recientemente. Recent se calcula de la siguiente forma:
Inicialmente vale 0
Al final de cada time slice (aprox. 10 milisegundos) recent se incrementa en 1 para el
proceso que está usando la CPU
Una vez por segundo se divide por dos el valor recent para todos los procesos
Normalmente el valor nice se hereda del proceso padre. El dueño del proceso o el propio
proceso pueden elevar su valor nice (menor prioridad). El superusuario puede modificar el valor
nice de todos los procesos a gusto. En los sistemas "a la BSD" el valor del número nice puede
variar entre -20 y +20, siendo por defecto 0.
Compilado por: Sandra Sauza Escoto 138
En System V en cambio los valores posibles van de 0 a 39, siendo 20 el valor por defecto.
Se puede modificar el valor nice por defecto en el momento de lanzar un programa lanzándolo a
correr con el comando nice, o posteriormente utilizando el comando renice.
A menudo, por algún bug en el programa o por algún error de operación, los procesos no
terminan correctamente y es necesario terminarlos por algún método más violento. El
procedimiento usual en estos casos es obtener el PID del proceso con la ayuda de ps y luego
terminarlo con el comando kill. Enseñarle a los usuarios a hacer estas operaciones con sus
procesos colgados es una muy buena inversión de tiempo para un administrador de sistema.
También suele suceder que algún proceso quede fuera de control y comience a acaparar algún
recurso del sistema (memoria, disco o CPU). Esto puede suceder por un error de programación,
por un error de configuración, por intentar correr algún proceso que necesita más recursos que
los disponibles o directamente por mala intención. Sea cual sea el caso se hace necesario que
el dueño del proceso o el administrador del sistema tomen medidas para frenar o terminar a ese
proceso. En general el primer síntoma es "el sistema está muy pesado" (o el teléfono sonando
con reclamos de los usuarios). El primer paso será identificar a el o los procesos problemáticos
utilizando las herramientas ya vistas. Si la situación es tan grave que dificulta la operación del
administrador, puede ser recomendable lanzar un shell de root con prioridad alta utilizando el
comando nice.
Si no está claro por qué el proceso puede estar acaparando recursos se puede intentar
detenerlo con la señal STOP hasta ubicar al usuario dueño del proceso. Una vez ubicado al
usuario si se considera necesario que el proceso continúe se le puede bajar la prioridad de
ejecución con el comando renice. Las siguientes opciones son o bien pedirle al proceso que
tenga a bien terminar con la señal TERM (kill -15 PID) o bien terminarlo por la fuerza con la
señal KILL (kill -9 PID)
Administración de Sistemas Unix de Misión Crítica 139
#!/bin/sh
cd /var/log
rm logfile.3
mv logfile.2 logfile.3
...
mv logfile logfile.0
cat /dev/null > logfile
La mayoría de los sistemas Unix traen instalado alguna variante de un script como el de arriba
para ser ejecutados desde el cron. Como habitualmente se utilizan para rotar los registros de
eventos de syslog, el administrador de registros de eventos que estudiamos más adelante en
este documento, los scripts de este tipo suelen llevar por nombre newsyslog.
Una versión más compleja de este script es el comando newsyslog de FreeBSD o el comando
logrotate de algunas versiones de Linux. Se describe a continuación newsyslog, logrotate
tiene prestaciones similares.
Esta versión "potenciada" de newsyslog es lanzada periódicamente con cron y lee de un archivo
de configuración (/etc/newsyslog.conf) cuáles son los archivos que debe rotar. Para cada
familia de archivos se configura si la rotación se realiza cada un lapso fijo o cuando el archivo
de log alcanza un determinado tamaño.
Un archivo no termina de desaparecer hasta que se cierran todas las referencias a él desde los
procesos que están corriendo. Si un programa abre el archivo de log al inicio y luego lo
mantiene abierto, aunque borremos el archivo, la referencia que mantiene el programa sigue
apuntando al antiguo archivo que ya no existe.
Para instalar un nuevo logfile, dependiendo del programa, puede ser necesario enviarle algún
signal en particular o matar al programa y volverlo a arrancar para lograr que el programa
comience a escribir en el nuevo archivo de log (por ej. para syslogd es necesario hacer kill -1
pid). Algunos programas necesitan que el archivo al cual escriben esté previamente creado. El
comando newsyslog descrito anteriormente permite especificar un nombre de archivo del cual
tomar un Process ID para enviar un kill -1 a ese proceso para que reabra los archivos de log
luego de la rotación-
A menudo los archivos de log más antiguos son poco consultados por lo que pueden
comprimirse para ahorrar espacio en disco. Los programas de compresión más comúnmente
utilizados son compress y gzip. Un ejemplo típico puede ser rotar los archivos diariamente,
manteniendo los dos días anteriores sin comprimir y los siguientes comprimidos con gzip hasta
completar una semana.
Por motivos de auditoría o seguridad algunas organizaciones optan por no destruir la
información de los logs antiguos. En esos casos en general los archivos de cierta antigüedad se
almacenan en algún medio removible (cinta o CD) y se archivan por la eventualidad de que
sean requeridos más adelante.
Administración de Sistemas Unix de Misión Crítica 141
La ubicación de estos archivos varía de un sistema a otro. El archivo utmp habitualmente está
en el directorio /etc o /var/run, el archivo wtmp suele estar en /var/log o /var/adm.
Si bien tienen algunas similitudes con los archivos de log, debe evitarse manipular los archivos
utmp y lastlog. El archivo lastlog está indexado por UID. Si en la asignación de UIDs a los
usuarios del sistema se saltea algún intervalo, pueden quedar "huecos" en el archivo que nunca
son escritos y a los que nunca se les llega a asignar sectores del disco. Algunos programas (ls -
l) reportan el tamaño completo del archivo, otros comandos (du) reportan solamente el tamaño
efectivamente utilizado por clusters asignados. Un problema que puede aparecer es que al
copiar un archivo con huecos se le asigne lugar en disco para los registros correspondientes a
los UID que no existen. Esto puede hacer que el archivo destino de la copia sea mucho mayor
que lo esperado, eventualmente llenando el disco.
messages
Por lo general la mayoría de los mensajes procesados por el daemon syslog que se ve más
adelante se almacenan en un archivo llamado messages, de modo que este archivo es uno de
los primeros lugares a los que recurrir en busca de información cuando se ha detectado un
problema.
Syslog
El syslog es un sistema que procura centralizar (y en buena medida lo logra) el manejo de los
registros de eventos que generan los diversos programas que corren en una máquina Unix. Por
un lado facilita a los desarrolladores de aplicaciones la generación y el manejo de mensajes a
registrar, y por otro lado facilita a los administradores de sistema el manejo en forma
centralizada de los mensajes provenientes de diferentes aplicaciones. Permite, clasificando los
mensajes por origen e importancia, enviarlos a diferentes destinos como archivos, a la terminal
de un operador, o eventualmente a un comando que lo reenvíe a direcciones de correo
electrónico o pagers.
El syslog tiene además capacidad para manejar mensajes originados en diferentes
computadores en una red. Los componentes más importantes de syslog son:
syslogd: el daemon que recibe los mensajes y los almacena de acuerdo a la
configuración almacenada en el archivo /etc/syslog.conf
openlog(), syslog() y closelog(): rutinas de la biblioteca C estándar para comunicarse
con syslog desde un programa.
logger: comando de usuario para agregar un mensaje a un log
El daemon syslogd
El daemon syslogd es uno de los primeros que se lanza a correr en los scripts de arranque del
sistema. Una vez arrancado queda esperando recibir mensajes para procesarlos de acuerdo a
la configuración en /etc/syslog.conf.
Syslogd responde a la señal 1 (HUP) cerrando los logs, releyendo la configuración y reiniciando
la operación. Es por eso que si realizamos algún cambio en la configuración, o si rotamos o
movemos los archivos de log, es necesario enviarle una señal HUP a syslogd. Para facilitar esto
syslogd guarda al arrancar en un archivo de nombre predeterminado (/etc/syslog.pid) el PID que
le tocó en suerte, de manera que el siguiente comando rearranca a syslogd:
Administración de Sistemas Unix de Misión Crítica 143
mensaje junto con el timestamp, pero solamente se conserva por un salto. En el syslog
original el nombre de la máquina que generó el mensaje no interviene en el selector, de
manera que no es posible desencadenar diferentes acciones según la máquina que
originó el mensaje. Esto último se ha modificado en versiones más nuevas de syslog.
reenviar a la terminal de un usuario si es que está logueado. Se puede especificar una
lista de usuarios separados por el carácter coma (",") o un carácter "*" para especificar
todos los usuarios logueados.
en algunos sistemas es posible pasar el texto del mensaje como entrada estándar a un
comando, escribiendo el comando precedido por el carácter pipe ("|").
Los siguientes ejemplos tomados del man de syslogd.conf ilustran la mayoría de los casos.
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none /var/log/messages
# Everybody gets emergency messages, plus log them on another
# machine.
*.emerg *
*.emerg @arpa.berkeley.edu
El esquema descrito hasta ahora es estándar en la mayoría de los syslog y permite con un
esquema simple configurar el sistema para las necesidades de cada lugar. Para ello se utilizan
en general los valores local0-7 de facility. Estos valores deberán administrarse asignándolos a
las diferentes fuentes de mensajes que no están previstas en los daemons originales. Estos
programas por lo general permiten configurar el valor de facility con el que etiquetan sus
mensajes. Así por ejemplo en un sitio podría asignarse el valor local0 a los mensajes del popper
(consultas de casillas de correo electrónico con pop3) y el valor local1 para los mensajes de los
routers de la red, dispositivos que por lo general no tienen disco y permiten ser configurados
para enviar los mensajes al syslog de otra máquina.
En un sistema grande puede llegar a agotarse los valores disponibles de facilities localx. Esto
ha influido para que en nuevas versiones de syslog aparezcan extensiones que hagan más
flexible la especificación de los selectores. En ese sentido algunas versiones de syslog
identifican a la primera palabra en el texto del mensaje como el nombre del programa que lo
originó, y permiten utilizar ese nombre de programa para seleccionar la acción a aplicar sobre el
mensaje.
Para ello en el archivo syslog.conf se definen secciones especiales para cada programa que
comienzan con una línea de la forma #!programa o !programa. En los casos en que el
syslog del sistema acepta estas extensiones hay que ser cuidadoso al agregar líneas al archivo
syslog.conf para estar seguro que la línea insertada no queda dentro del bloque definido para
un programa en particular.
Otra mejora introducida en nuevas versiones de syslog es que es posible agregar el modificador
"=" al comienzo del nivel para especificar que el nivel de severidad sea igual estricto en lugar de
mayor o igual al nivel especificado. En forma similar pueden usarse los modificadores "!"
(diferente) y "-" (menor). Esto puede verse en el siguiente ejemplo:
Administración de Sistemas Unix de Misión Crítica 145
BIBLIOGRAFÍA
Unix System Administration Handbook. Evi Nemeth, Garth Snyder, Scott Seebass,
Trent R. Hein y colaboradores. Prentice Hall PTR - 3rd Edition 2001. ISBN: 0-13-020601-
6.
Unix System Administration Handbook. Evi Nemeth, Garth Snyder, Scott Seebass,
Trent R. Hein. Prentice Hall PTR - 2nd Edition 1995. ISBN: 0-13-151051-7.
Essential System Administration - Help for UNIX System Administration. Æleen
Frisch. O'Reilly - 2nd Edition 1995. ISBN: 1-56592-127-5.
Solaris 10 The Complete Reference- Dr. Paul A. Watters. McGraw-Hill/Osborne. 0-07-
222998-5
Referencias
Comando man de UNIX; comando info de GNU.