Administración de Sistemas Unix

N OTA S PA R A E L C U R S O
Administración de
Sist emas UNIX

de Misión Crítica
Compilado por:
Sandra Sauza Escoto
Dirección General de Servicios de Cómputo Académico

Dirección de Cómputo para la Docencia
Administración de Sistemas Unix de Misión Crítica 149
Í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
3. ATRIBUTOS DE LOS ARCHIVOS ............................................................................ 11

3.1 Tipos de archivos............................................................................................................ 11
3.2 Comandos para conocer y cambiar sus atributos............................................................ 12
3.2.1 ls y sus opciones.............................................................................................................................. 12
3.2.2 ln y sus opciones.............................................................................................................................. 13
3.3 chomod ........................................................................................................................... 13
3.4 chgrp............................................................................................................................... 14
3.5 chown ............................................................................................................................. 14
3.4 Rutas absolutas y rutas relativas .................................................................................... 15
Compilado por: Sandra Sauza Escoto 150
4. EDITOR VI................................................................................................................. 17
5. COMANDOS BÁSICOS DE RED .............................................................................. 25

5.1 finger............................................................................................................................... 25
5.2 who ................................................................................................................................. 25
5.3 w ..................................................................................................................................... 25
5.4 talk .................................................................................................................................. 25
5.5 write ................................................................................................................................ 26
5.6 FTP................................................................................................................................. 26
5.7 telnet............................................................................................................................... 27
5.8 Los comandos r .............................................................................................................. 27
5.9 ssh .................................................................................................................................. 29
5.10 scp ................................................................................................................................ 29
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
7. GENERALIDADES DE SHELLS ............................................................................... 35

7.1 Introducción .................................................................................................................... 35
7.2 Propósitos de Shell ......................................................................................................... 35
7.3 Variables de ambiente. ................................................................................................... 36
7.4 Tipos de Shell ................................................................................................................. 37
7.5 Características comunes................................................................................................. 38
7.6 Programas de Shell ........................................................................................................ 38
8. PERFIL Y ACTIVIDADES DEL ADMINISTRADOR ................................................... 45

8.1 Planeación de las actividades. ........................................................................................ 45
8.2 Creación de copias de seguridad. ................................................................................... 46
8.3 Utilerías básicas del sistema (find, cron, etc) .................................................................. 57
8.4 Documentación ............................................................................................................... 59
8.5 Establecimiento de políticas de uso y de administración ................................................. 61
9. ALTA Y BAJA DEL SISTEMA.................................................................................... 64

9.1 Inicio del sistema ............................................................................................................ 64
9.2 Detención del sistema..................................................................................................... 71
10. MANTENIMIENTO DE CLAVES DE USUARIOS .................................................... 73
11. INSTALACIÓN Y MANTENIMIENTO DE DISPOSITIVOS ....................................... 84

11.1 Sistema de archivos...................................................................................................... 84
11.1.1 Preparación. ................................................................................................................................... 86
11.1.2 Dar formato al disco....................................................................................................................... 90
11.1.3 Particionar el disco......................................................................................................................... 91
11.1.4 Crear sistemas de archivos........................................................................................................... 92
11.1.5 Montaje automático. ...................................................................................................................... 93
11.1.6 Mantenimiento de sistemas de archivo (cuotas, du, df).............................................................. 95
11.2 Sistema de impresión.................................................................................................. 100
11.3 Unidades de cinta ....................................................................................................... 107
11.3.1 Políticas de respaldo. .................................................................................................................. 110
12. CONFIGURACIÓN Y MANTENIMIENTO DEL USO DE LA RED ......................... 113

TCP/IP y Enrutamiento ....................................................................................................... 113
13. ADMINISTRACIÓN DEL ÁREA DE SWAP ........................................................... 134
14. ADMINISTRACIÓN DE PROCESOS .................................................................... 137
15. MONITOREO DEL SISTEMA................................................................................ 139

15.1 Bitácoras del administrador......................................................................................... 139
15.2 Bitácoras del sistema .................................................................................................. 141
15.3 Carga del sistema ....................................................................................................... 146
BIBLIOGRAFÍA............................................................................................................ 148
Referencias ........................................................................................................................ 148
1
1. INICIAR UNA SESIÓ N
1.1 Elementos básicos de la cuenta de un usuario

Para acceder al sistema hay que introducir una identidad de un usuario (en él definido) o login,
y una clave secreta o password.
El login de usuario es único dentro de un sistema y tiene asociado un número llamado identidad
de usuario, es decir, no pueden existir 2 usuarios con el mismo login. Por el contrario, dos
usuarios diferentes pueden tener la misma clave secreta o password (por lo general ellos lo
ignorarán). Cuando se escribe el login, para acceder a un sistema, este es visible en la pantalla,
en cambio cuando se escribe el password no se muestra nada (como si no se escribiera), con el
fin de que no pueda ser visualizado por nadie (al mostrar asteriscos, podría dar pistas sobre el
número de caracteres de esta clave, por lo cual no es un buen m método). La clave de un
usuario solo podrá ser cambiada por el propio usuario, y dentro de unas restricciones
existentes, y por root, que es el superusuario y carece de restricciones.
El login y la clave o password pueden contener letras, números y algunos caracteres de
puntuación, etc., y en ocasiones tienen limitado su tamaño entre un mínimo y un máximo
(normalmente entre 6 y 8 mínimo y más de 8 como máximo).
Cada usuario tiene asignado un directorio de trabajo. Varios usuarios pueden tener asignado el
mismo directorio de trabajo, aunque no es lo común.
Así mismo cada usuario tiene asignado un tipo de shell o interprete de comandos. Entre los
tipos de shell más conocidos tenemos ksh, csh, sh, bash, rsh, tcsh, etc.. La diferencia entre
ellas estriba en las utilidades que aportan al usuario, como recuperación de comandos,
variables de entorno, etc.. Si un usuario, en lugar de un interprete de comandos tuviera
asignado un programa, cada vez que accediera al sistema, solo podría ejecutar ese programa o
aplicación, y abandonaría el sistema cada vez que finalizara dicho programa.
Al introducir el login y la password, el sistema verifica que son correctos, anotándolo en un
archivo log. En sistemas de alta seguridad, los accesos incorrectos también pueden ser
almacenados en un archivo y al cabo de varios intentos fallidos, puede bloquearse la cuenta. Si
se introduce un usuario inexistente o una clave o password incorrecta el sistema denegará el
acceso, pudiendo llegar a bloquear una cuenta al cabo de varios intentos fallidos.
1.2 Ini cio de una sesión de escritori o

Una sesión de escritorio comprende el período de tiempo desde el momento en que se inicia la
sesión y el momento en que se finaliza.
La pantalla de entrada al sistema, que muestra el Gestor de inicio, es la puerta de acceso del
usuario al escritorio. Proporciona un espacio para que el usuario escriba su nombre de inicio de
sesión y contraseña.
Para iniciar una sesión de escritorio:
1. Escriba su nombre de inicio de sesión y pulse Intro o haga clic en Aceptar.
2. Escriba su contraseña y pulse Intro o haga clic en Aceptar.
Si el Gestor de inicio no reconoce su nombre o contraseña, haga clic en Iniciar y comience de
nuevo el proceso de inicio de sesión.
Una vez se haya conectado al sistema, el Gestor de sesiones inicia una sesión:
 Si es la primera vez que inicia una sesión, obtendrá una sesión nueva.
 Si ha iniciado una sesión antes, se restaurará la sesión anterior.
1.3 Cambi o de contraseña

Para cambiar la contraseña hacemos uso del siguiente comando con las opciones
correspondientes
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
1.4 Para fi nalizar la sesión

 Haga clic en el control Exit del Panel frontal.
 O bien, elija Finalizar sesión en el Menú del área de trabajo.
Cuando finaliza una sesión de escritorio normal, el Gestor de sesiones guarda información
sobre la sesión para que se pueda restaurar la próxima vez que inicie una sesión. No se puede
guardar información sobre aplicaciones que no sean de escritorio.
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.1 Comandos, opciones y argumentos

Las opciones son modificadores del comando, que pueden hacer que solo presente una
información determinada o que la presente de una u otra forma. El prefijo utilizado en UNIX para
las opciones, generalmente, es el "-", aunque también se pueden encontrar casos con "+". En
DOS el prefijo usado para las opciones es "/". No debe existir espacio entre el prefijo y la
opción. Un prefijo puede ser válido para varias opciones simultáneamente.
Los argumentos indican al comando sobre qué se debe ejecutar la acción, por ejemplo el
nombre de archivo, usuario, etc. Los argumentos no llevan prefijo lo cual sirve para
diferenciarlos de las opciones.
Así pues, la sintaxis general a emplear a la hora de usar un comando será:
Comando ±Opciones Argumentos
En general, se podrán usar varias opciones simultáneamente, al igual que varios argumentos, si
bien será necesario consultar la documentación o la ayuda de cada comando, para conocer las
opciones y argumentos posibles.
2.2 Comandos bási cos

Se pueden ejecutar varios comandos desde una misma línea de comandos, para ello habrá
que separarlos mediante el carácter punto y coma ";".
comando1 argumentos ; comando2 argumentos ; comando3 argumentos

Ejecutará los comandos 1, 2 y 3 secuencialmente, es decir, cuando finalice el comando 1, se
ejecutará el 2, y cuando finalice el 2 se ejecutará el 3. Los resultados de un comando no tienen
por que ser necesarios para el siguiente.
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.3 comodines o metacaracteres
La construcción de expresiones regulares depende de la asignación de significado especial a

algunos caracteres. En el patrón aba*.txt el carácter* no vale por sí mismo, como el carácter
asterisco, sino que indica un "conjunto de caracteres cualesquiera". Asimismo, el carácter? no
se interpreta como el signo de interrogación sino que representa "un carácter cualquiera y uno
solo". Estos caracteres a los que se asigna significado especial se denominan
"metacaracteres".
El conjunto de metacaracteres para expresiones regulares es el siguiente:

\ ^ $ . [ ] { } | ( ) * + ?
Estos caracteres, en una expresión regular, son interpretados en su significado especial y no
como los caracteres que normalmente representan. Una búsqueda que implique alguno de
estos caracteres obligará a "escaparlo" de la interpretación mediante \, como se hace para
evitar la interpretación por el shell de los metacaracteres del shell. En una expresión regular, el
carácter? representa "un carácter cualquiera"; si escribimos \?, estamos representando el
carácter? tal cual, sin significado adicional.
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
cp [OPCIONES] ARCH_ORIGEN ARCH_DESTINO

cp [OPCIONES] ARCHIVO ... DIRECTORIO
copia ARCH_ORIGEN hacia ARCH_DESTINO; copia los archivos indicados hacia DIRECTORIO.
Por defecto no copia directorios.
-d copia enlaces simbólicos como tales
-f forzoso, sobreescribe archivos destino si existen
-i avisa antes de sobreescribir archivos existentes
-l crea enlaces hard en lugar de copiar los archivos
-p preserva dueño, grupo, permiso y fecha
-s crea enlaces simbólicos en lugar de copiar los archivos
-R recursivo, copia directorios y sus archivos
2.2.6 mkdir
mkdir [OPCIONES] [-m MODO] DIRECTORIO ...

crea los directorios indicados. Por defecto, el modo es 0777 menos los bits de umask.
-m MODO permite fijar el modo para el nuevo directorio; el modo es simbólico y usa el modo
por defecto como partida.
-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.
2.2.7 rm, rmdir
rm [OPCIONES] NOMBRE ...

elimina los archivos indicados; por defecto no elimina directorios.
-f ignora archivos inexistentes y nunca pide confirmación
-i interactivo, pregunta antes de eliminar cada archivo.
-r, -R recursivo, borra directorios y su contenido
-v verboso, muestra nombre de cada archivo eliminado
rm arch1 arch2 dir1/arch3
rm -riv dir1/subdir1
rm –rf *
elimina TODOS los archivos y subdirectorios!
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
more [OPCIONES][-N][+/CADENA[-N] [ARCHIVO ...]

pagina el texto dividiéndolo en pantallas, presentando una por vez.
-N fija tamaño de pantalla en N líneas
-d muestra mensajes de ayuda
-s comprime en una varias líneas en blanco seguidas
-u suprime subrayados
+/cadena busca la cadena antes de mostrar

+N comienza a mostrar a partir de la línea N
Durante el despliegue, reconoce los comandos siguientes, algunos de los cuales pueden ir
precedidos de un número multiplicador:
h muestra resumen de estos comandos
ESPACIO avanza una pantalla
ENTER muestra siguiente línea
f avanza una pantalla; ^F
b retrocede una pantalla; también ^B
^L (Ctrl-L) redibuja la pantalla
= muestra número de línea actual
/PATRON busca hacia adelante la expresión regular PATRON
?/PATRON busca hacia atrás la expresión regular PATRON
n repetir última búsqueda
. repetir el comando anterior
´ ir a lugar de comienzo de última búsqueda
q, Q salir
2.2.9 cat
cat [OPCIONES] [ARCHIVO ...]

Concatena los archivos indicados y los muestra en la salida estándar. Sin argumentos, recibe
de la entrada estándar.
-A equivalente a -vET
-b numera las líneas que no están en blanco
-E muestra $ al final de cada línea
-n numera las líneas
-s reemplaza varias líneas en blanco por una sola
-t equivale a -vT
-v muestra caracteres no imprimibles excepto LF y TAB
-T muestra TAB como ^I
cat /etc/group
cat cap1 cap2 cap3
muestra sucesivamente los archivos cap1, cap2 y cap3.

cat cap1 cap2 cap3 > libro
reúne los archivos cap1, cap2 y cap3 en el archivo libro.
cat arch1 arch2 > arch1
hace perder los datos originales en arch1.
2.2.10 date
date [OPCION] [+FORMATO]

muestra fecha y hora. Con +FORMATO la presenta según el patrón indicado.
date [-u|--utc|--universal] [ MMDDHHmm [[CC]YY][.SS] ]
fija (su) fecha y hora.
-u --utc --universal hora universal (GMT)
Formato para fijar la hora:
MM mes (01-12)
DD día (01-31)
HH hora (00-23)
mm mminuto (00-59)
CC centuria
YY año
SS segundos (00-59)
Formato para presentar la fecha y la hora (+FORMATO):
'%H' hora (00-23)
'%M' minuto (00-59)
'%S' segundos (00-59)
'%T' hora en 24 horas (hh:mm:ss)
'%X' hora en representación local (%H:%M:S)
'%a' nombre local abreviado del día
'%A' nombre local completo del día
'%b' nombre local abreviado del mes
'%B' nombre local completo del mes
'%c' fecha y hora locales
'%d' día del mes (01-31)

'%m' mes (01-12)
'%w' día de la semana (0-6), 0 es Domingo
'%x' fecha local
'%y' 2 dígitos del año (00-99)
'%Y' 4 dígitos del año (1970....)
2.2.11 touch
touch [OPCIONES] ARCHIVO ...

cambia fecha, hora de acceso y/o modificación de los archivos indicados; les pone la fecha y
hora actuales. Si los archivos no existen los crea vacíos.
-a cambia sólo fecha de acceso
-c no crea el archivo si no existe
-m cambiar sólo fecha de modificación
-r arch_ref fija la fecha según fecha del archivo arch_ref
-t MMDDhhmm[[CC]YY][.ss]
fija la fecha indicando mes MM, día DD, hora hh y minuto mm;
puede agregarse también centuria CC y año YY y segundos ss.
touch 01011200 dia1enero.h1
touch ahora.arc
touch -r antes.arch arch1 arch2
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.
3. ATRIBUTOS DE LOS ARC HIVOS
3.1 Ti pos de archi vos

♦ Regulares u ordinarios:
Son los que consisten en una secuencia de bytes. Se pueden incluir dentro de los
archivos regulares los archivos de texto, programas, archivos encriptados, archivos de
datos, etc.
♦ 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 de enlace simbólico:

Son archivos que contienen el path absoluto de otro fichero.
♦ 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
3.2 Comandos para conocer y cambiar sus atributos
3.2.1 ls y sus opciones
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
3.2.2 ln y sus opciones
ln [OPCIONES] ORIGEN [DESTINO]

ln [OPCIONES] ORIGEN ... DIRECTORIO
si el último argumento es un directorio, ln crea en ese directorio enlaces a todos los archivos
origen con el mismo nombre; si sólo se indica un nombre de archivo, crea un enlace hacia ese
archivo en el directorio actual; si se indican dos archivos, crea un enlace con el primer nombre
(archivo real) hacia el segundo (enlace). Por defecto, crea enlaces hard y no elimina archivos
existentes.
-f forzoso, elimina archivos destino existentes
-i interactivo, pide confirmación para eliminar archivos
-s simbólico, crea enlaces simbólicos en lugar de hard
-v verboso, da el nombre de cada enlace creado
ln nota nota.ln
ln -s /etc/passwd
ln -s datos.usuario datos.usu.ln
ln -sv datos.usuario LEAME dir2
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 ]
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 ]
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
3.4 Ru tas absolutas y rutas rel ativas

Un directorio puede contener otros directorios así como archivos ordinarios, lo que genera una
jerarquía o árbol de directorios. El directorio superior o directorio raíz se denomina /.
cd /
el directorio actual es el directorio raíz.
cd
vuelve al directorio propio del usuario.
El carácter/ se usa también para separar los componentes de un nombre de archivo completo:
/export/home/usuario1/nota.
La porción /export/home/usuario es la ruta, así como el nombre completo del
dicho archvo. Si se omite la ruta, se asume que el archivo se encuentra en el directorio
actual. Un nombre tal como textos/libro/capitulo.1 indica que su ruta comienza a partir
del directorio actual.
Sería lo mismo escribir ./textos/libro/capitulo.1 ya que el punto designa el directorio
actual. Dos puntos seguidos designan el directorio de nivel superior al actual. Si el directorio
actual es /home/usuario1
ls ../usuario2
muestra el contenido de los archivos en /home/usuario2
Entonces
. significa el directorio actual o de trabajo y
.. significa el directorio padre o un directorio arriba en el árbol de directorios.
Por lo tanto una ruta absoluto o nombre completo de un archivo es aquella que va inicia con /
/home/usuario2
Y una ruta relativa o nombre corto es aquella que inicia con . indicando que indicaremos el
nombre apartir de la ubicación actual.
El carácter/ separa directorios incluídos como parte de un nombre de archivo o directorio.

ls dir1
es un direccionamiento relativo;
ls /home/esteban/dir1
es un direccionamiento absoluto.
Pueden usarse comodines (también conocidos como metacarateres) para referenciar
directorios y archivos:
cat /home/esteban/*/*
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:
vi arch1 arranca en modo comando editando el archivo arch1
i inserta texto a la izquierda del cursor
a agrega texto a la derecha del cursor
ESC vuelve a modo comando

x borra el carácter bajo el cursor
dd borra una línea
h o flecha izquierda mueve el cursor un carácter a la izquierda
j o flecha abajo mueve el cursor una línea hacia abajo
k o flecha arriba mueve el cursor una línea hacia arriba
l o flecha derecha mueve el cursor un carácter a la derecha
:w salva el archivo (graba en disco)
:q sale del editor (debe salvarse primero)
Invocación
vi abre la ventana de edición sin abrir ningún archivo.
vi arch1 edita el archivo arch1 si existe; si no, lo crea.
vi arch1 arch2 edita sucesivamente los archivos arch1 y luego arch2.
vi +45 arch1 edita el archivo arch1 posicionando el cursor en la línea 45.
vi +$ arch1 edita el archivo arch1 posicionando el cursor al final del archivo.
vi +/Habia arch1 edita el archivo arch1 en la primera ocurrencia de la palabra

"Habia".
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
tecla ESC (interrumpe el comando).

Confundir un modo con otro la de mayor dificultades para el manejo de vi. Puede activarse un
indicador de modo escribiendo
:set showmode
Esto hace aparecer una leyenda que indica si se está en modo comando o inserción.
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.
flechas mueven el cursor (si el terminal lo permite)
h j k l mueven el cursor (igual que las flechas)
itextoESC inserta la palabra "texto" y vuelve a comando
x borra el carácter sobre el cursor
dw borra una palabra
dd borra una línea
3dd borra las 3 líneas siguientes
u deshace último cambio
ZZ graba cambios y sale de vi
:q!ENTER sale de vi sin grabar cambios

/expresiónENTER busca la expresión indicada
3Y copia 3 líneas para luego pegar
:6r arch3 inserta debajo de la líne 6 el archivo arch3
Movimiento del cursor:
flechas mover en distintas direcciones
h o BS una posición hacia la izquierda
l o SP una posición hacia la derecha
k o - una línea hacia arriba
j o + una línea hacia abajo
$ fin de línea
0 principio de línea
1G comienzo del archivo
G fin del archivo
18G línea número 18
Ctrl-G mostrar número de línea actual
w comienzo de la palabra siguiente
e fin de la palabra siguiente
E fin de la palabra siguiente antes de espacio
b principio de la palabra anterior
^ primera palabra de la línea
% hasta el paréntesis que aparea
H parte superior de la pantalla
L parte inferior de la pantalla

M al medio de la pantalla
23| cursor a la columna 23
Control de pantalla
Ctrl-f una pantalla adelante
Ctrl-b una pantalla atrás
Ctrl-l redibujar la pantalla
Ctrl-d media pantalla adelante
Ctrl-u media pantalla atrás
Ingreso en modo texto:
i insertar antes del cursor
I insertar al principio de la línea
a insertar después del cursor
A insertar al final de la línea
o abrir línea debajo de la actual
O abrir línea encima de la actual
R sobreescribir (cambiar) texto
Borrar
x borrar carácter bajo el cursor
dd borrar línea, queda guardada
D borrar desde cursor a fin de línea
dw borrar desde cursor a fin de palabra
d$ borrar desde cursor a fin de línea
d0 borrar desde cursor a principio de línea

BS borrar carácter hacia la izquierda
Copiar y pegar
Y o yy copiar línea
P pegar antes del cursor
p pegar después del cursor
yw copiar palabra
y$ copiar de cursor a fin de línea
"ayy o "aY copiar línea en buffer llamado 'a'
'a' "ayw copiar palabra en buffer llamado
"ap pegar desde buffer 'a', a la derecha del cursor
"aP pegar desde buffer 'a', a la izquierda del cursor
"bdd borrar línea y guardar en buffer 'b'
"bdw borrar palabra y guardar en buffer 'b'
Búsqueda
/str buscar hacia adelante cadena de caracteres 'str'
?str buscar hacia atrás cadena de caracteres 'str'
n repetir último comando / o ?
N repetir último comando / o ? para el otro lado
fc buscar el siguiente carácter 'c' en la línea
Fc buscar el anterior carácter 'c' en la línea
tc ir al carácter anterior al siguiente 'c'
Tc ir al carácter posterior al precedente 'c'
; repetir el último comando f, F, t, o T

, último comando f, F, t, o T para el otro lado La cadena a buscar en / o ?

puede ser una expresión regular.
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
C o c$ reemplaza hasta el fin de línea
c0 reemplaza desde el comienzo de línea
J unir dos líneas en una
ZZ grabar cambios si los hubo y salir
u deshacer última acción
U deshacer todos los cambios en una línea
ESC para entrar a modo comando
Modo ex o última línea
:q salir si no hubo cambios
:q! salir sin guardar cambios
:w guardar cambios
:w arch1 guardar cambios en archivo arch1
:wq guardar cambios y salir
:r arch2 insertar un archivo
:e arch2 editar un nuevo archivo

:e! arch2 idem sin salvar anterior
:r! comando insertar salida de comando
:shell salir al shell (vuelve con exit)
Mover
:1 mueve a línea 1
:15 mueve a línea 15
:$ mueve a última línea
Opciones
:set cambio de opciones
:set nu mostrar números de línea
:set nonu no mostrar números de línea
:set showmode mostrar modo actual de vi
:set noshowmode no mostrar modo actual de vi
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.
5 . COMANDOS BÁSICOS D E RED

Los comandos de red son realmente importantes, ya que estos permiten el acceso a otra
computadora de una red. Esta red puede ser una casera o la red del trabajo, pero también una
red tan amplia como la gigantesca internet. Esto significa que los comandos que se verán a
continuación se utilizaráns cuando la computadora sea parte de una red con salida a internet o
una intranet.
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
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):
open Abre la conexión al nodo.
close Finaliza la sesión FTP sin salir del programa.
bye Finaliza la sesión FTP y sale del programa.
help Ayuda interactiva del ftp.
get/mget Copia fichero/s del nodo remoto en la unidad local.
put/mput Copia fichero/s locales en el nodo remoto.
cd Cambio de directorio en el nodo remoto.
lcd Cambio de directorio en la unidad local.
dir Muestra el contenido del directorio remoto.

5.7 tel net

El protocolo telnet permite conectarse a otro sistema (no necesariamente Unix ) y dialogar con
ese sistema como si tuviéramos una terminal conectada directamente a el.
La sintaxis del protocolo es:
telnet [ host ]
Una vez conectados, y después de presionar las teclas <crtl> <]> , se pasa al modo comandos
de telnet. Este modo permite enviar caracteres especiales al sistema distante, de cerrar la
conexión, de abrir una nueva, o de salirse de telnet.
Los principales comandos bajo este modo son:
 lista los comandos de telnet:
 open abre una conexión
 close cierra la conexión en curso
 quit sale de telnet, cerrando la connexion
 send car envía un carácter especial al sitio distante
 send ? lista los caracteres especiales y su efecto
5.8 Los comandos r

Este es un conjunto de comandos que permiten realizar cierto tipo de operaciones remotas
entre dos maquinas que estén ejecutando un sistema operativo Unix. Con el _n de protegerse
de posibles ejecuciones no deseadas, si el usuario curso de la máquina A desea ejecutar un
comando en la maquina B se deben cumplir las siguientes condiciones:
 El usuario curso debe de tener una cuenta en la máquina B. Normalmente se tiene el
mismo nombre de cuenta en ambas máquinas (curso)
 El archivo /etc/host.equiv de la máquina B debe tener una entrada para A o en su defecto
el directorio hogar3 de curso debe contener un archivo llamada .rhosts que contenga una
entrada para tequila.
En muchos sistemas el archivo .rhosts es creado con una sola entrada, un carácter + lo cual le
otorga permiso a todo mundo de hacer lo que sea en la máquina. Se recomienda eliminar dicho
archivo o revisar periódicamente su contenido para evitar otorgarle permisos innecesarios a
personas desconocidas o no deseadas.
Existen varios comandos que funcionan bajo este contexto, a continuación se explicarán los
más importantes de ellos.
EL rlogin (remote login)
Permite conectarse a otro sistema Unix, de la misma forma que telnet . Su sintaxis es:
rlogin [ -l nombre ] host
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.
El rsh (remote shell)

Permite ejecutar un comando sobre otra máquina Unix. Los archivos de entrada/salida estándar
están asociados a la terminal, sin embargo no se aconseja utilizar rsh para ejecutar comandos
interactivos distantes.
Su sintaxis es:
rsh host [ -l usuario ] [ comando ]
Si no se especifica el comando, entonces el usuario se conectará al sistema distante como si
hubiera tecleado un rlogin.
Hay que tener cuidado con las redirecciones:
ssauza@cognac>rsh doc ls > res.txt crea un archivo res.txt local
ssauza@cognac>rsh doc "ls > res.txt" crea un archvio en la maquina doc
Si el usuario no tiene el archivo .rhosts entonces se le pedirá su password. Lo mismo ocurre si
en ese archivo no se le otorga la autorización de conexión a la máquina desde la cual se está
ejecutando el rsh.
El rcp (remote copy)

Permite copiar archivos de una máquina a otra. Es imperativamente necesario tener un archivo
.rhosts en la máquina distante que autorice al usuario a conectarse La sintaxis del copiado
remoto es:
rcp arch1 arch2
rcp [ -r ] archivo [ archivos ] directorio
donde arch1 y arch2 pueden tomar la forma maquina:pathname. Esta forma significa que el
archivo se encuentra en el camino de acceso pathname, de la maquina. Lo mismo se aplica
para los argumentos directorio y archivo en la segunda sintaxis. La opción -r permite especificar
un directorio y de copiar recursivamente toda la sub-jerarquía que se encuentra en ese
directorio.
Algunos ejemplos de este comando se presentan a continuación:

ssauza@tequila>rcp doc: .login
ssauza@tequila>rcp notas:bin/arch1 tequila:bin
ssauza@tequila>rcp notas:bin/arch1 curso:bin/arch2
ssauza@tequila>rcp -r src mezcal:src
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
6 . PROCESOS
6.1 Defi nici ón

Un proceso puede ser uno o más de un programa en ejecución.
El termino proceso fue utilizado por primera vez por los diseñadores del sistema MULTICS
(Antecedente del UNIX).
Siempre que se crea un proceso en UNIX se utiliza la orden FORK para bifurcar un proceso en
proceso padre e hijo (Independiente).
Los procesos son entidades con vida propia.
6.2 Li star procesos

ps (process status).
Lista todos los procesos activos en ejecución en la máquina.
$ps  Información referente a los proceos asociados con un terminal.
Los ID de los procesos se asignan de forma consecutiva a partir de :
 El proceso 0 es un proceso del sistema que se crea al principio cuando se crea el
sistema UNIX.
 El proceso 1 (INIT) es el responsable de la generación de los restantes procesos.
Hasta el rango de los numeros enteros pos y cuando se terminan se asignan los PID de los
procesos liberados.
 Generación de los procesos en arranque.
 Cuando se inicia o arranca el sistema UNIXm el nucleo (/unix) se carga eb memoria y se
ejecuta.
 El nucleo inicia las interfaces hardware y las estructuras de datos internas y crea un
proceos de sistema (proceso 0  swapper). El proceos 0 se bifurca (FORK) y crea el
primer proceos de usuario (proceso 1  INIT)
$kill {ID del proceso}
 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
T  P detenido y en modo de traza.
X  P a la espera de más memoria.
Campo PRI  Prioridad de procesos .

Campo NI  Valor de NICE
ADDR  Dirección inicial en memoria.

SZ  Tamño en paginas.
-e  Visualización de todos los proceos del sistema.
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.
ID Nombre Uso habitual
1 SIGHUP Usualmente para releer configuración
9 SIGKILL El kernel destruye el proceso
15 SIGTERM Terminación "elegante", en general termina enviándose un KILLL a sí mismo
SIGSTOP El kernel pasa el proceso a stopped
SIGCONT
SIGUSR Definidas por el usuario o más bien por quien programó el proceso
6.5 Procesos en 1ro y 2do plano

Los procesos pueden trabajar en 1er y 2do plano
1. Los procesos en primer plano se caracterizan por:
 no permiten la ejecución de otro proceso hasta que el proceso actual termine
 no devuelve el indicador (prompt).
 Se encuentran asociados a la terminal en la cual se esta ejecutando dicho proceso
2. Los procesos en segundo plano se caracterizan por:
 Regresa inmediatamente el indicador
 Permite la ejecución de otro procesos sin esperar a que termine el anterior
 No se encuentra asociado a la terminal
Para ejecutar un programa en background o 2do plano, basta con poner el signo ampersand (&)
al término de la línea de comandos. Por ejemplo, si se quisiera copiar el directorio /usr/src/linux
al directorio /tmp:
#cp -r /usr/src/linux /tmp &
#
Cuando ha terminado la ejecución del programa, el sistema lo reporta mediante un mensaje:
#
[Done] cp -r /usr/src/linux /tmp
#
Si se hubiese ejecutado el programa y no se hubiese puesto el ampersand, se podría pasarlo a
background de la siguiente manera:
1. Se suspende la ejecución del programa, pulsando Ctrl+Z.

2. Se ejecutamos la siguiente orden: bg
Ejemplo
$cat f1 f2 f3 > f4 & {Se indica que la tarea se va a realizar en background}
Devuelve el numero de identificador de tarea.

 Cuando se sale de la sesión se realiza la orden KILL a todos los procesos.
 Existe la posibilidad de que se siga ejecutando una tarea en background una vez se ha
desconectado la sesión.  $nohup
$nohup  Hace que el comando lanzado ignore la señal de colgar que se emite al
desconectar la sesión. La salida del comando se redirecciona al fichero nohup.out
(colocado generalmente en el directorio raiz).
$nohup comando [comando-argumentos]
$nohup cat f1 f2 f3 |sort > f4
$kill  Envia una señal especifica al proceso especificado. La señal se indica con un
entero y el proceso con un PID. (Señales son dependientes de la implementación y
normalmente se indican el fichero /usr/include/signal.h) Podemos encontrar un PID con
el comando ps.
$kill 0  Indica la señal de terminación a todo el grupo de procesos en ejecución
(excepto el shell que es inmune a la señal terminar) /Normalmente matara a los procesos
ejecutados en background/
9  SIGKILL  Terminar (No se puede ignorar)
15  SIGTERM  Terminar de software (Señal de terminar software)
Las ordenes de control de trabajos del shell le permiten terminar un trabajo en modo
subordinado(matarlo), suspenderlo sin terminar(pararlo) reanudar un trabajo suspendido en
modo subordinado, mover un trabajo de modo subordinado a principal.
^Z  Permite suspender el trabajo en modo principal. Esto finaliza el programa y
devuelve el control al shell
$jobs  Visualizar la lista de los trabajos actuales. La salida muestra los trbajos
actuales en modo principal y subordinado, los suspendidos o parados.
$kill  Se puede terminar con cualquiera de estos trabajos.
 Se utiliza el carácter % como indicador de trabajo.
$fg  Permite reanudar un trabajo en modo suspendido y devolverlo al modo principal.
$fg %2
$bg  Reanudar un trabajo suspendido en modo subordinado.
$stop  Para la ejecución de un trabajo en modo subordinado, pero no lo finaliza.
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.
7.2 Propósitos de Shell

El shell es un Intérprete de comandos
- las abreviaturas de nombres e archivos
- redireccionamiento de entrada-salida
- personalización del entorno
 concatenado de ordenes con ;
 Direccionamiento:
> Direccionamiento de salida (vacia de contenido el fichero destino).
< Direccionamiento de entrada.
>> Doble direccionamiento de salida
<< Doble direccionamiento de entrada
$mail pepe << “!”  Permite realizar una entrada hasta una clave
determinada.
| Pipe  Permite introducir como entrada de una orden la salida de otra
orden.
 Descriptores:
0  Entrada standar.
1  Salida standar.
2  Salida standar de errores.
$cat f1 f2 f3 > f4 2>ferror

{Concatena f1+f2+f3  f4 | La salida estándar de error  ferror.
$cat f1 f2 f3 > f4 2&1 [2 va a 1]
7 .3 Vari abl es de ambiente.

Las variables de ambiente son aquellas que se definen en el shell y que permanecen en
nuestra sesión.
Se declaran de la siguiente forma
csh
setenv VAR valor (define)
unsetenv VAR (elimina)
sh
set VAR=valor (define)
export VAR
unset VAR (elimina)
Variables del shell

Las variables de shell se asocian con el shell que las crea
sh
set var=valor
unset var
csh
set vari=valor
unset var
Ejemplos de variables de ambiente.

HOME  Dir de conexión del usuario.
PATH  Establecer caminos de acceso (separador de caminos ‘:’)
CDPATH  Caminos de directorios.
PS1  Prompt primario.
PS2  Prompt secundario.
LOGNAME  Nombre usuario.
MAIL  Directorio de acceso al correo.
MAILFILE  Especificación del fichero de correo.
SHELL  Shell por defecto.
TERM  Definición del terminal.
TZ  Zono horaria.
MAILCHECK  Chequea el buzon de correo cada x tiempo
GROUP  Nombres de usuarios para grupo activo.
MAILRC  Fichero de configuración del correo.
MBOX  Fichero donde va a parar correo que se lee o no direcciona.
LPDEST  Impresora por defecto.
 Solo tienen valor en el shell de definición.
 Para que tengan valor en otros shell’s se tienen que exportar:
$export  Exporta a todos los niveles de shell la variable especificada.
7.4 Ti pos de Shell

UNIX ofrece tres tipos de shell o modos de interpretación de comandos:
Bourne Shell(sh); Korn Shell(ksh); C Shell(csh).
El Bourne shell es el más antiguo y tuvo gran popularidad en su lanzamiento, es el shell por
defecto del UNIX.
El C shell reensambla la programación en lenguaje C y por tanto es más completo que el
anterior.
El Korn Shell es el más moderno de los tres y el más desconocido.
7 .5 Caracterí sticas comun es

Cada shell tiene sus características propias. La principal diferencia que existe entre los distintos
tipos de shell radica en la sintaxis de la línea de comandos. No es necesario aprender a
programar con todos los tipos de shell ya que sabiendo uno los conocemos todos, así que es
mucho más sencillo de lo que parece
7 .6 Programas de S hell
SENTENCIAS DE PROGRAMACIÓN
Orden if
If orden
Then
Orden(es)
Fi
Else
Orden(es)
Fi
 La condición puede ser una orden o sentencia test.

$if orden ; then ordenes; ...{; ...;} ; else orden; ...; fi
 Se puden anidar.
 La combinación else if  elif
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
-f  Exist y fich ordinario.

-d  directorio
-h  Simbolico.
-p  pipe
-s  Si existe y tamaño mayor que cero.
-c  Disp orient. a carácter.
-b  disp orient a bloque
B) Para números:
N1 –eq N2
N1 –ne N2
N1 –gt N2
N1 –ge N2
N1 –lt N2
N1 –le N2
C) Cadenas
Cadena1 = Cadena1
Cadena != Cadena2
-z  Existe y longitud es 0
-n  Existe y long es distinta de 0
cadena  Si existe.
D) Combinaciones:
-o  OR LOGICO.
-a  AND LOGICO
Ej
If [ -w f1 ]  Sustituye a test.
 En Ksh
[[n1 >= n2]]  Se pueden usar caracteres de comparación.
Bucle For
For i
in lista
do
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
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.
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
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.
8. PERFIL Y ACTIVIDA DES DEL

ADMINISTRADOR
8.1 Planeaci ón de l as activi dades.

Agregar y quitar usuarios.
Administración de las cuentas de los usuarios del sistema. Los procesos de agregado y
eliminación de cuentas de usuario pueden ser en parte automatizados mediante scripts
(programas en UNIX u otro lenguaje a nivel de sistema operativo) al crear una cuenta de
usuario es preciso determinar la pertenencia a grupos de trabajo, lugar del directorio de trabajo
del usuario, accesos remotos a otros equipos, alias de correo electrónico. Al eliminar una
cuenta de usuario los archivos creados por ese usuario deben ser eliminados, respaldados en
cinta o transferidos a sistemas de archivos estipulados para este uso, conservando la
información de interés y la responsabilidad individual sobre la misma, así como los recursos del
sistema.
Agregar y quitar hardware.
Al adquirir o transferir de un equipo a otro una parte de hardware puede ser preciso actuar
sobre el sistema para asegurar el reconocimiento y uso del equipo. La tarea puede consistir en
enchufar una impresora, abrir la máquina para instalar un disco, una tarjeta controladora u otro
dispositivo, correr un script para reconocer o inicializar el nuevo hardware, o editar complejos
archivos de configuración.
Realizar respaldos de información.
Es responsabilidad del administrador llevar a cabo respaldos periódicos de sus sistemas de
archivos en donde tenga información de difícil recuperación, es decir, información de los
usuarios o información de configuración de servicios locales, verificar que dichos respaldos
concluyan de manera correcta, guardar un periodo recomendado en base a la frecuencia de los
cambios que sufre la información de los sistemas de archivos y validar la eficacia de la posibles
restauraciones de dicha información.
Instalación de nuevo software.
El software nuevo debe ser instalado, configurado y comprobado su funcionamiento. Luego, los
usuarios deben ser informados de su existencia, ubicación y particularidades de uso. El
software no perteneciente al sistema operativo debe instalarse en un lugar aparte, para
asegurar que las actualizaciones del sistema operativo puedan dañar su desempeño.
Monitoreo del sistema.

Incluye verificar funcionamiento de correo, servidor Web y de todos los servicios y servidores
que se tengan publicados, básicamente es revisar los archivos de registro de eventos y errores
(log) para detectar o anticipar fallas, asegurar acceso a todas las subredes, controlar recursos
del sistema tales como espacio en disco, procesador, memoria swap y memoria física
Detección y reparación de fallas.
El administrador del sistema es responsable de diagnosticar fallas de hardware o software, así
como de contactar el servicio técnico, realizar la reparación por sí mismo o delegar en su
personal, supervisando en todos los casos la tarea.
Mantenimiento de documentación local (bitácora)
Llevar un registro de los cambios hechos al sistema respecto a la instalación primaria. Todos los
aspectos en los que el sistema vaya siendo alterado o ampliado deben quedar documentados,
mediante bitácora La bitácora debe abarcar particularidades de configuración del sistema
operativo, paquetes de software incorporados, tendido de cables, registros de mantenimiento
del hardware, estado de respaldos, procedimientos y políticas de administración.
Seguridad.
Es responsabilidad del administrador del sistema implementar políticas de seguridad en base a
los servicios y los usuarios a los que atiende, verificar periódicamente que dichas políticas sean
respetadas y de ser necesario modificarlas, verificar que la seguridad de sus sistemas siempre
sea confiable, mediante pruebas de auto-intrusión. Dichas políticas pueden ir desde restricción
de accesos hasta elaborados procedimientos de captura y auditoría
Ayuda a los usuarios.
Aunque esta es una actividad poco reconocida muchas, es una de las más frecuentes entre las
tareas del administrador de sistema, el apoyo a usuarios le consume mucho tiempo. Es
conveniente disponer de procedimientos y ayudas escritos para poner límite al tiempo destinado
a estas tareas.
8.2 Creaci ón de copias de seguridad.

El respaldo de datos.
En la inmensa mayoría de los sistemas de información, los datos almacenados en el sistema
tienen mucho mayor costo y son mucho más difíciles de recuperar que el sistema en sí. Entre
los riegos de pérdida de datos se cuentan los errores en el software, la falla de equipos, el error
humano, el daño intencional, las catástrofes naturales. El respaldo de datos es la generación de
una copia, en un momento determinado, de los datos del sistema, con vistas a su eventual
reposición en caso de pérdida. Todos los sistemas informáticos deben respaldarse
cuidadosamente, en momentos predeterminados, siguiendo un cronograma preestablecido.
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.
Características de los principales medios de respaldo, en orden de capacidades

crecientes:
Acceso
Medio Capacidad Reuso Comentarios
aleatorio
muy común; poca capacidad, incómodo; poca

duración (2 años); útil para respaldo de archivos
Disquete 1.44/2.8 MB Sí Sí
de configuración o transferencia de archivos
chicos; alto costo por MB
bastante común; varias interfaces de conexión;

Zip 100/250 MB Sí Sí
alto costo por MB
muy común; varias interfaces de conexión; menor

duración que CDs pregrabados, mucho mayor
CD-R 650 MB No Sí
que los medios magnéticos; buenos para datos
permanentes, incómodo para respaldos regulares
CD-RW 650 MB Sí Sí ventajas del CD-R; limitado en capacidad

Acceso
Medio Capacidad Reuso Comentarios
aleatorio
DVD-R 4.7 a 17 GB No Sí Aún poco común; U$S 5 el de 4.7GB.
discos removibles; buena velocidad de

Jaz, Orb ~2 GB Sí Sí
transferencia
cinta video formato chico; las unidades suelen

Cinta 8 mm 7 GB Sí No
ser llamadas Exabyte
DDS (Digital Data Storage) es similar al DAT

Cinta 4 mm (Digital Audio Tape) para audio; original 2 GB,
20 GB Sí No
DAT/DDS DDS-4 en 20 GB; buena velocidad de
transferencia; tamaño reducido
muy común; excelente transferencia, bajo costo;

Disco fijo 40 GB Sí Sí apto para crear espejos de discos; menor
transportabilidad
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;
 maneja nombres largos y rutas de anidamiento profundo;

 maneja bien los archivos con huecos (bloques sin datos) producidos por algunos
programas (bdm, nbdm); en una copia común estos archivos se agrandan
desmesuradamente;
 admite respaldo incremental.
dump maneja el sistema de archivos en crudo, leyendo la tabla de inodos para decidir qué
archivos deben respaldarse. Esto aumenta su eficiencia, pero obliga a manejar cada sistema de
archivos en forma independiente, e impide el respaldo de sistemas de archivos remotos tipo
NFS. No obstante, es posible respaldar un sistema de archivos sobre una unidad de respaldo
remota usando rdump.
Niveles de respaldo incremental.
El respaldo incremental se implementa asignando un nivel a cada respaldo, de 0 a 9. Un
respaldo nivel 0 copia todos los archivos; un respaldo nivel 1 copia sólo los archivos
modificados luego de la fecha del último respaldo nivel 0; un respaldo nivel 7 copia sólo los
archivos modificados luego del último respaldo nivel 6. La recuperación de un sistema de
archivos requiere reponer primero el respaldo nivel 0 y luego sucesivamente el último nivel 1, el
último de nivel 2, y siguientes. Los números de niveles pueden no ser contiguos: se toma el
nivel anterior más próximo existente como referencia. La información de dump se guarda en el
archivo /etc/dumpdates; en caso necesario, este archivo puede ser editado manualmente.
#dump 0uf /dev/st0 /usr
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
análogo para un nivel 3.

#dump 0uf /dev/nst0 /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.
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
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.
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
sistema operativo, deberá uno armarse de paciencia, bajar la máquina a monousuario y
respaldar el sistema en nivel 0. Existen programas especiales (archivadores o "filers")
capaces de tomar un registro periódico del estado del sistema y resincronizar el
respaldo. Debe considerarse esta posibilidad cuando no sea posible reducir la actividad
del sistema en ningún momento.
Verificar el respaldo: hay también historias de respaldos tomados cuidadosamente que
nunca pudieron restaurarse. Releer la cinta con restore para generar la tabla de
contenido es una prueba razonable; probar recuperar un archivo en particular obliga a
recorrer partes más alejadas de la cinta, ofreciendo una comprobación más sólida. Debe
verificarse también que es posible restaurar desde varias cintas, que se pueden leer
cintas grabadas tiempo atrás, y que es posible leer en otras unidades además de la
habitual.
Vida útil de las cintas: como todo en el mundo, las cintas tienen una vida limitada,
indicada por los fabricantes en cantidad de pasadas. Un respaldo, una restauración o un
salto de archivos representan, cada uno, una pasada.
Crecimiento del sistema: el bajo precio de discos tiende a generar un aumento
desordenado de la capacidad de almacenamiento. Imponer un criterio ordenado de
crecimiento, con calificación de datos por criticidad y actividad, su separación racional en
distintos sistemas de archivos, la concentración de información vital en un servidor
confiable, son algunas medidas coactivas para alcanzar un respaldo confiable y
humanamente posible.
Restaurar archivos.
En este apartado se trata la restauración de un archivo o un grupo de archivos, en
contraposición a la restauración de un sistema de archivos completo.
1. Determinar en qué cinta se encuentran los archivos a restaurar. Los usuarios
generalmente buscan la última versión del archivo, pero no siempre es así. La existencia
y ubicación del archivo dependen del esquema de respaldo empleado. Si se conservan
catálogos (listas con todos los archivos respaldados en una fecha), la búsqueda se
simplifica: basta con verificar si el archivo buscado se encuentra en el catálogo. Si no es
así, se deberán revisar las cintas más probables según la fecha indicada por el usuario,
o recorrer todo el conjunto desde el respaldo nivel 0 inmediato anterior.
2. Crear un directorio donde recuperar los archivos. Muchas versiones de restore
requieren reponer la ruta entera de directorios para recuperar el archivo. No usar /tmp;
su contenido será borrado en un rearranque imprevisto.
3. Si se han colocado varios archivos de respaldo en una misma cinta, se deberá
consultar la documentación de ubicación de cada uno, determinar el lugar en que se
encuentra el de interés, y usar el comando mt para ubicar el comienzo del archivo de
respaldo.
4. Restaurar el archivo. Usar el comando complementario del respaldo: si se usó dump

para respaldar, usar restore; si se usó rdump, usar rrestore.
5. Entregar el archivo al usuario. Se puede copiar el archivo hacia el directorio del usuario,
verificando que no exista ya un archivo con ese nombre. En ningún caso debe
sobreescribirse un archivo de otro usuario. Otra alternativa es dejarlo en el lugar de
recuperación para que el usuario lo copie. En este caso, será preciso limpiar
regularmente el directorio de recuperación.
6. Notificar al usuario.
Ejemplo completo de recuperación del archivo perdido.arch del usuario juanpe, con la cinta en
la máquina roble:
Montar la cinta en la unidad de la máquina roble.
$ su
ingresa como supervisor, pide contraseña.
# cd /var/tmp
la recuperación se hará en el directorio /var/tmp.
# rsh roble mt -f /dev/nrst1 fsf 3
salta hasta el 4o. archivo de respaldo en la cinta.
# rrestore xf roble:/dev/nrst1
> /usr/users/juanpe/docs/perdido.arch
ejecuta el comando e imprime mensajes; observar continuación del comando en la segunda
línea.
# ls /var/tmp/usr/users/juanpe/docs
perdido.arch
muestra la presencia del archivo recuperado.
# ls /usr/users/juanpe/docs
otro1.arch otro2.arch
verifica que el archivo recuperado no existe en el directorio propio del usuario, para no
reescribirlo.
# cp -p /var/tmp/usr/users/juanpe/docs/perdido.arch
/usr/users/juanpe/docs
copia el archivo recuperado hacia el directorio propio del usuario.
# mail -s "Archivo recuperado" juanpe
Su archivo perdido.arch fue recuperado.
Se encuentra en su directorio, bajo docs.
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.
Restaurar sistemas de archivos.

Antes de restaurar un sistema de archivos completo, se debe estar seguro de haber eliminado
las causas que provocaron su destrucción.
1. Crear un sistema de archivos en la partición donde se va a restaurar; montarlo.
2. Cambiar al directorio raíz (punto de montaje) del nuevo sistema de archivos. Montar la
primera cinta del último respaldo nivel 0. Arrancar la restauración con restore r. El comando
pedirá las cintas sucesivas.
3. Al terminar de restaurar el nivel 0, continuar con los diferentes niveles en el mismo orden
del esquema de respaldos empleado.
Ejemplo de restauración de un sistema de archivos a partir de un respaldo de 3 niveles.
# newfs /dev/dsk/c201d6s0 QUANTUM_PD1050S
# mount /dev/dsk/c201d6s0 /home
# cd /home
Crea el sistema de archivos, lo monta y se posiciona en él. Montar ahora la cinta 1 del último
respaldo nivel 0 de /home.
# restore r
Montar las restantes cintas del respaldo nivel 0. Montar luego la primer cinta del respaldo nivel 1
siguiente.
# restore r
Montar las siguientes cintas del respaldo nivel 1. Montar luego la primer cinta del respaldo nivel
2 siguiente.
# restore r
Montar las siguientes cintas del respaldo nivel 2. Montar luego la primer cinta del respaldo nivel
siguiente.
# restore r
Esta secuencia repone el sistema de archivos a su estado original más cercano al momento de
pérdida. En el esquema de respaldos empleado, la única diferencia es la mágica aparición de
los archivos que fueron borrados. Hay versiones de restore que llevan registro de los archivos
borrados.
En una actualización del sistema operativo, debe hacerse un respaldo nivel 0 antes de la
actualización, efectuar luego la actualización cuidando de reponer los archivos de configuración
necesarios en los sistemas de archivos afectados por la actualización. Una vez que todo esté
funcionando, realizar inmediatamente un nuevo respaldo nivel 0. Esto es imprescindible para
asegurar la coherencia de los siguientes niveles, ya que la actualización puede haber
modificado fechas de archivos preexistentes.
Otros comandos de respaldo.

Los clásicos comandos tar (BSD) y cpio (System V) sirven para respaldar archivos, directorios y
grupos diversos de archivos y directorios. Se usan frecuentemente para trasladar información,
distribuir software o aún copiar árboles de directorios dentro de un mismo sistema, sobre todo
por su capacidad de conservar dueños, permisos y fechas, no siempre posible con cp.
Copia de un árbol de directorios usando tar:
tar cf - dir_origen | ( cd dir_destino ; tar xfp - )
Copia de un árbol de directorios usando cpio:
find dir_origen -depth -print | cpio -pdm dir_destino
Este comando es poco usado, habiendo cedido lugar a tar.
Al usar estos comandos verificar estas posibles limitaciones: soporte multivolumen, nombres de
ruta largos, recuperación de errores, fijación de factor de bloqueo (20 por defecto). Muchas han
sido levantadas, en particular en las versiones de GNU, pero conviene verificar en la
documentación y comprobar en la práctica.
Cuando es preciso realizar transformaciones de datos es útil el comando dd (data duplicator).
Sin parámetros, este comando sólo copia entrada en salida. Admite un cierto número de
opciones que permiten cambiar formato de los datos o transferir entre distintos medios.
Copia de una cinta entre dos unidades:
dd if=/dev/rmt8 of =/dev/rmt9 cbs=16b
Copia de una cinta en una sola unidad:
dd if=/dev/rmt8 of =/tmp/cinta.archdev cbs=16b
cambiar la cinta;
dd if=/tmp/cinta.arch of =/dev/rmt8 cbs=16b
Conversión desde cinta con diferente orden de byte:
dd if=/dev/rst8 conv=swab | tar xf -
volcopy permite realizar una copia exacta de un sistema de archivos completo hacia otro
dispositivo, eventualmente con cambio en el bloqueo. Está disponible en Solaris, HP-UX y
Linux.
Para el control de la unidad de cinta, se usa el comando mt, especialmente útil cuando se graba
más de un archivo en la misma cinta. Su sintaxis básica es
mt [-f dispositivo_cinta] comando [cantidad]
Los comandos de respaldo en cinta graban una señal de fin de archivo (EOF, End Of File) al
terminar de ejecutar; esto permite ubicar un respaldo en particular desplazándose en la cinta.
Entre los comandos admitidos por mt se destacan:
rew rebobinado de la cinta
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.
8.3 Utilerías básicas del si stema ( fi nd, cron , etc)

Procesos periódicos y cron
El "daemon" cron en Unix permite lanzar comandos de sh con un calendario predeterminado y
es la herramienta estándar para el manejo de tareas periódicas. cron usualmente se lanza
como un daemon en algún script de arranque del sistema.
Para determinar qué comandos debe ejecutar y en que momento hacerlo, cron lee uno o varios
archivos de configuración denominados crontabs (de "cron table").
Estilos de cron
Existen dos estilos de implementar el cron originados en los dos "sabores" principales de Unix.
En un cron "a la BSD" existe un crontab único para todo el sistema, usualmente en
/etc/crontab o en /usr/lib/crontab. Dado que el archivo es único para todo el sistema debe ser
administrado por el usuario root editando el archivo crontab con un editor de texto. En este
caso cada renglón del crontab, además de indicar qué comando ejecutar y cuándo hacerlo debe
especificar a nombre de qué usuario debe ejecutarse el comando.
Los cron "a la ATT" brindan una flexibilidad mayor al permitir que exista un archivo crontab
diferente para cada usuario del sistema. De esta manera cada usuario puede configurar sus
propias tareas repetitivas sin intervención del administrador. Este puede todavía controlar
cuales usuarios pueden utilizar el cron a través de dos archivos de configuración adicionales:
cron.allow y cron.deny.
Normalmente los archivos crontab se encuentran bajo un directorio común, y cada uno lleva
como nombre de archivo el nombre del usuario. Para manejar estos archivos habitualmente se
utiliza el comando crontab, que permite crear, examinar y editar el archivo de configuración del
usuario que lo invoca.
La mayoría de los Unix modernos, inclusive los de origen BSD, tienen un cron "a la AT&T".
Algunos inclusive pueden manejar archivos crontab de los dos tipos simultáneamente como es
el caso del "vixie cron", un paquete independiente que puede instalarse en varias plataformas.
Formato de archivos crontab
Los archivos crontab son archivos de texto en que se lista una tarea repetitiva por cada renglón.
Salvo pequeñas diferencias como la necesidad o no de especificar el nombre de usuario, el
formato es el mismo en todos los sistemas con los siguientes 7 campos:
minuto hora día mes día_de_la_semana [usuario] comando
Campo
Minuto Minuto de la hora 0 a 59
Hora Hora del día 0 a 23
Día Día del mes 1 a 31
Mes Mes en el año 1 a 12
Dia_de_la_semana Día de la semana 1a7o0a6
Atención!! con el campo día_de_la_semana no todos los cron se comportan igual:

 lunes siempre es el día 1
 el domingo casi siempre es el día 7, pero en algunos casos es el día 0 (RTFM)
 algunos cron modernos (vixie cron) aceptan los dos valores (0 y 7) para especificar
domingo
En todos los campos se puede especificar, además de un valor exacto, rangos (separando con
un guión '-'), listas (separando con una coma ',') y un comodín con el carácter '*'.
Por ejemplo, en la siguiente línea:
30 07 * * 1-5 comando
Se indica que se ejecute 'comando' de lunes a viernes a las 7:30hs
Si en una línea se especifica tanto el campo día como el campo día_de_la_semana, entonces
es suficiente con que se satisfaga una sola de las dos condiciones. Para mayor claridad, en el
ejemplo:
0,15,30,45 * 13 * 2 comando
se está especificando la ejecución cada cuarto de hora en todos los días 13 y en todos los días
martes.
En los rangos y comodines también se puede especificar el paso de incremento, como en los
siguientes ejemplos.
# cada 15 minutos
*/15 * * * * comando1
# cada 2 horas entre las 8 y las 12, idem 8,10,12
* 8-12/2 * * * comando2
Precauciones y errores comunes

Un comando o script puesto a ejecutar automáticamente por cron puede comportarse de
manera diferente que cuando ejecutamos el mismo script desde una sesión interactiva de
usuario. Hay que tener en cuenta varios aspectos:
 El comando va a ser lanzado por cron utilizando sh como interpretador de comandos.
Debemos tener en cuenta esto si utilizamos habitualmente otro shell (csh, ksh, bash,
tcsh) ya que presentan diferencias de sintaxis, variables de ambiente, etc..
 No se ejecutan los scripts de inicialización del shell (.login, .profile, .cshrc por ejemplo)
que normalmente se ejecutan al iniciarse una sesión de usuario, por lo que no estarán
inicializadas ciertas variables de ambiente. El caso más común de esto es la variable
PATH: o bien debe inicializarse explícitamente o bien escribirse el camino completo en el
sistema de archivos de cada comando que se utilice.
 Dado que un comando lanzado por cron no corre en una terminal, toda la salida estándar
y la salida de error del comando se envía por e-mail al usuario. Es práctica usual
redireccionar la salida a /dev/null una vez que han sido depurados los scripts utilizados.
Un error habitual tiene que ver con que en las líneas del crontab no se especifica el año. Es
común que se agende un comando para ejecutarse una sola vez pero luego se olvide borrar el
comando del crontab. En esos casos el olvido suele notarse un año más tarde cuando vuelve a
ejecutarse el comando. Otra opción para agendar trabajos por una única vez es utilizar el
comando at.
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
proliferación y posibilidades ofrecidas por los navegadores han acentuado la tendencia a

presentar la información en lenguaje HTML, el de las páginas Web.
Además de las páginas man prácticamente todas las variedades de UNIX disponen de otros
tipos de documentación en forma de libros, manuales operativos, tutoriales y material
complementario cubriendo un amplio espectro de necesidades y auditorio, desde tutoriales para
principiantes hasta intrincados detalles técnicos destinados a los especialistas.
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
Solaris HP-UX Linux Contenido

FreeBSD
1 1 Comandos de usuario, aplicaciones
2 2 Llamadas al sistema, códigos de error del núcleo
3 3 Llamadas a funciones de biblioteca
4 5 Formatos de archivos estándares
5 7 Archivos y documentos varios
6 6 Juegos y demostrativos
7 4 Controladores de dispositivos y protocolos de red
1m 8 comandos de administración del sistema
9 9 Especificaciones del núcleo e interfaces

Ejemplos:
man -h
man man
man -a man
man 5 passwd
8.5 Establecimiento de políticas de uso y de admi nistración

Políticas.
En la administración de sistemas, la inmensa mayoría de los especialistas aconsejan disponer
de una política administrativa escrita y firmada. En muchos casos, las instituciones legales y
sociales se encuentran muy atrasadas respecto a las implicancias de las nuevas tecnologías de
comunicación, dejando vacíos en aspectos tales como privacidad, derechos de autor,
propagación de mensajes obscenos u ofensivos, etc. Las políticas y procedimientos de una
institución deben consignarse por escrito, someterse a la aprobación de la dirección y a la
verificación del departamento legal.
Las políticas definen los criterios por los que se rige la institución. La documentación de
políticas debe incluir:
 servicios de administración brindados o excluidos;
 derechos y responsabilidades de los usuarios;
 derechos y responsabilidades de los administradores (usuarios con privilegios);
 acceso a personas invitadas.
Procedimientos.
Los procedimientos describen, en forma de lista o receta, la forma en que se realizan las
diferentes tareas. Son útiles tanto para los administradores nuevos como para los experientes.
Entre sus múltiples ventajas, se destacan:
 las tareas se realizan siempre del mismo modo;
 se reducen las probabilidades de error;
 es más rápido trabajar siguiendo una receta;
 los cambios quedan documentados en el propio procedimiento;
 existe un estándar de correctitud definido.
Las redes basadas en UNIX han ido sustituyendo los mainframe (computadoras de gran porte)
para aplicaciones de misión crítica en el mundo corporativo, alcanzando proporciones
considerables. En estos lugares los procedimientos son creados por un nivel de administración
por encima de quienes los ejecutan; se organizan en un libro que se mantiene impreso y en
línea. Deben existir procedimientos para las siguientes tareas:
 agregar, eliminar, bloquear una cuenta de usuario;
 agregar una máquina;
 localizar una máquina;

 instalar "TCP wrappers" para registro y control de accesos vía TCP (telnet, ftp, finger);
 instalar respaldos para una máquina nueva;
 configurar la seguridad de una máquina nueva;
 prever el rearranque de piezas complejas de software;
 revivir un sitio Web que no responde o no sirve las páginas;
 destrabar y rearrancar una impresora;
 actualizar el sistema operativo;
 instalar un paquete de software;
 instalar software desde la red;
 actualizar paquetes críticos de software (sendmail, gcc, named, etc.);
 respaldar y restaurar archivos;
 definir condiciones y alcance en bajadas de emergencia.
Algunas políticas surgen de manera forzosa por el entorno; otras deben manejarse en forma
centralizada, como ser los números IP, nombres de máquinas, UIDs, GIDs, nombres de grupos
y de usuarios.
Las cuentas compartidas son un inconveniente para el cumplimiento de las políticas, ya que las
responsabilidades se diluyen. Es preferible disponer de un esquema de asignación de cuentas
más liberal, limitando en horario, tiempo de conexión u otros. Otros aspectos, que pueden
trascender del grupo local de administradores, incluyen:
 manejo de las violaciones de seguridad;
 control de exportación de sistemas de archivos;
 criterios de selección de contraseñas;
 bloqueo de cuentas por incumplimientos;
 uso de material protegido por derechos de autor (MP3s, DVDs);
 piratería de software.
En un lugar grande, la comunicación y coordinación entre los distintos grupos de
administradores es esencial.
Etica y actitud.
El administrador de sistemas es una persona con poder: dispone de la contraseña de
supervisor, puede leer el correo de los usuarios, borrar o alterar sus archivos, distorsionar
intencional o accidentalmente el sistema hasta dejarlo inutilizable, producir pérdida de datos,
trabajo y respeto por los individuos y la institución. La persona elegida para administrar un
sistema debe tener firmes convicciones éticas. Alguien con tendencia a presumir de su
condición privilegiada debe ser invitado prontamente a cambiar de ocupación.
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.
9. A LTA Y BAJ A DEL S ISTEMA

El sistema operativo UNIX es un sistema complejo; los procesos de arranque y detención de
una máquina UNIX implican muchas tareas; deben realizarse correctamente si se desea
mantener la sanía del sistema. No basta con prender o apagar un interruptor. La pluralidad de
configuraciones introducidas por el advenimiento de los computadores personales al mundo
UNIX ha extendido los alcances y complicaciones de estos procesos.
Aunque lo dicho aquí es aplicable en general, los procesos de arranque y detención son
dependientes de hardware: puede haber diferencias para un equipo en particular.
9.1 Ini cio del sistema

El arranque del sistema suele llamarse "booting" o "booteo" en la jerga informática, propensa a
castellanizaciones crueles.
Durante el arranque no están disponibles las facilidades del sistema; éste debe levantarse a sí
mismo iniciando todos sus servicios (bootstrapping). Cuando una máquina se enciende, ejecuta
un programa de carga cuyas instrucciones se encuentran almacenadas en ROM. Este
programita determina como cargar en memoria el núcleo del sistema operativo (kernel) y
comenzar a ejecutarlo. El kernel examina el hardware probando todos los dispositivos
conectados, e inicia un proceso llamado init, siempre con identificador de proceso PID 1. Se
verifican los sistemas de archivos, se montan, se arrancan los demonios del sistema, siguiendo
los dictados de una serie de scripts en lenguaje de shell llamados archivos o scripts rc (rc = run
command). El contenido y estructura de los scripts rc determinan la situación final del sistema.
Arranque automático y arranque manual.
La mayoría de los sistemas operativos tienen un modo de arranque manual y otro automático.
En modo automático, el sistema operativo realiza las tareas correspondientes al proceso de
arranque en forma autónoma, sin necesidad de intervención del administrador, ejecutando
todos los scripts de arranque e iniciando todos los procesos necesarios para brindar los
servicios habituales a los usuarios.
En modo manual el sistema operativo ejecuta una primera parte del proceso de arranque pero
casi enseguida transfiere el control al administrador. Se ejecutaron sólo unos pocos scripts, hay
pocos procesos corriendo, sólo el superusuario puede acceder al sistema: se está ejecutando
en modo monousuario (single-user mode).
En la operativa diaria el sistema arranca en modo automático con sólo encender el equipo.
Algunas fallas pueden obligar al arranque en monousuario: una falla en una tarjeta de red o un
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:
Swapper - Proceso 0
Init - Proceso 1
Pagedaemon - Proceso 2
En los descendientes de System V son:
Sched - Proceso 0
Init - Proceso 1
varios manejadores de memoria y procesos del núcleo

En Linux no hay un proceso visible con PID 0, sino varios procesos de manejo además de init,
diferentes según la versión del kernel:
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.
Archivos de arranque (scripts rc).

Al momento de correr los scripts rc el sistema ya es un UNIX típico, con pocos servicios pero sin
magias de arranque; todos los pasos posteriores se gobiernan mediante los propios scripts rc.
La ubicación exacta y la organización de esos archivos depende del sistema.
Operación en multiusuario.
Una vez ejecutados los scripts de arranque el sistema se encuentra operativo, pero para
aceptar el ingreso de usuarios (login)initdebe arrancar un procesos getty de escucha en cada
una de las líneas de conexión de terminales. Esto completa el proceso de arranque. En los
sistemas configurados para usar login en ambiente gráfico init arranca estos servicios (xdm,
gdm, dtlogin u otro).
El proceso init sigue desempeñando un rol importante durante todo el período de
funcionamiento del sistema, arrancando procesos y recibiendo en herencia procesos sin padre.
En BSD init tiene solo dos estados, monousuario y multiusuario; en System V existen diferentes
estados mono y multiusuario (run levels), cada uno con diferente espectro de recursos y
servicios.
Scripts rc.
En BSD, los scripts rc se ubican bajo /etc, con nombres comenzados por "rc"; pueden invocarse
unos a otros. En System V los scripts se guardan bajo /etc/init.d, con enlaces hacia ellos en
directorios /etc/rc0.d, /etc/rc1.d, ..., correspondientes cada uno a un nivel de arranque.
Usualmente los scripts rc realizan, entre otras, las siguientes tareas:
 Fijar el nombre de la máquina.
 Fijar la zona horaria.
 Verificar los discos con fsck (en arranque automático).
 Montar los discos del sistema.
 Eliminar archivos del directorio /tmp.
 Configurar las interfaces de red.
 Arrancar los demonios del sistema y los servicios de red.
Scripts rc estilo System V.
El estilo System V es el más usado actualmente. Se definen en él 7 niveles de arranque (run
levels), cada uno con un conjunto de servicios particular:
Nivel 0: sistema bajo, no hay nada corriendo.
Nivel 1 o S: monousuario.
Niveles 2 a 5: diversos (o idénticos) niveles multiusuario.
Nivel 6: rearranque (reboot), el sistema se detiene y vuelve a arrancar.
Como nivel multiusuario se usa únicamente el nivel 2, o el 2 y el 3 para configuración sin y con
red, por ejemplo; los niveles 4 y 5 no suelen ser usados. Los niveles 1 y S difieren según los
sistemas. Los niveles 0 y 6 no son en realidad estados de funcionamiento, sino transitorios.
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
El conjunto de servicios a detener y arrancar en cada nivel se controla disponiendo de un

directorio para cada nivel y estableciendo en él enlaces hacia los scripts en init.d, según la
siguiente convención de nombres:
[K|S][0-9][0-9]nombre_script
nombre de enlace iniciado en K invoca el script en init.d con parámetro "stop";
nombre de enlace iniciado en S invoca el script en init.d con parámetro "start";
el número de 2 cifras que sigue a K o S indica el orden de ejecución;
sigue el nombre del script en init.d.
Ejemplos: S34named, K29bind.
Los directorios para cada nivel siguen la convención de nombres rcN.d, donde N es el número
de nivel. Ejemplos: rc0.d, rc2.d, rcS.d. Cuando el sistema está subiendo, se ejecutan los scripts
S; cuando está bajando se ejecutan los scripts K, siempre en el orden definido por los números
en los nombres de sus enlaces simbólicos. Los comandos
ln -s /etc/init.d/sshd /etc/rc2.d/S99sshd
ln -s /etc/init.d/sshd /etc/rc2.d/K25sshd
ln -s /etc/init.d/sshd /etc/rc6.d/K13sshd
crean los enlaces simbólicos necesarios para arrancar y detener el servicio sshd en el nivel
multiusuario 2. La colocación del enlace en el nivel 6, reboot, es un reaseguro para la detención
del servicio en el rearranque, si el sistema no recorre por sí en forma ordenada los niveles de
detención.
Las distribuciones de Linux usan distintos esquemas de scripts rc: Debian sigue el esquema
System V descrito, en forma similar a Solaris y HP-UX; Slackware usa el esquema BSD, como
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.
Problemas en el cargador del sistema operativo.

En las máquinas de arquitectura propietaria existe un programa de carga del sistema operativo
almacenado en ROM. Una falla común es la alteración o borrado de una variable de ambiente
almacenada en memoria no volátil. En este y otros casos es preciso seguir las indicaciones del
fabricante para reponer el arranque.
Los sistemas UNIX para computadores personales vienen programas de carga tales como LILO
para Linux o BootEasy para FreeBSD. Estos cargadores permiten arrancar electivamente Linux
u otros sistemas operativos instalados en diferentes particiones de un mismo disco. Una falla,
alteración o borrado del programa cargador obliga a arrancar el sistema con un medio
alternativo (disquete, CD), y reinstalar el programa de carga o corregir y reponer su
configuración correcta.
Las fallas de carga pueden darse en un sistema operativo instalado correctamente; la
reposición del esquema de arranque recupera el sistema completamente.
Problemas en el sistema de archivos.
Un sistema de archivos puede fallar por razones físicas (superficie dañada, disco roto), o
lógicas (inconsistencias en las estructuras de almacenamiento). En caso de falla física habrá
que cambiar el disco o al menos realizar una detección de bloques defectuosos para evitar su
uso, crear nuevamente el sistema de archivos y reponer desde respaldos. Una falla lógica
puede ser reparable con fsck, eventualmente con alguna pérdida; de no ser así, será preciso
recrear el sistema de archivos y reponer desde respaldo. La verificación deberá realizarse
arrancando en modo monousuario, con el sistema de archivos en falta desmontado y sobre el
dispositivo, ejecutando fsck reiteradamente en modo forzoso hasta no obtener errores.
Si la falla es en el sistema de archivos raíz el sistema no podrá arrancar. Si se dispone de una
partición de arranque alternativa, puede levantarse el sistema desde ella y reponer el servicio
rápidamente. Según los sistemas, esto puede hacerse con comandos de ROM o del programa
de carga; es preciso tener muy clara esta secuencia, y haber probado el arranque al crear la
partición alternativa, así como mantener permanentemente sincronizadas (idénticas) ambas
particiones de arranque, mediante copia cruda con dd. Estas particiones deben estar en discos
distintos para obtener una confiabilidad razonable. En ausencia de partición de arranque
alternativa será preciso reinstalar el sistema operativo, eventualmente reponiendo desde
respaldo los archivos de datos.
Una falla lógica en el sistema de archivos raíz puede intentar repararse arrancando el sistema
desde un medio alternativo (CD, disquete de rescate o disquete de instalación) y correr fsck
sobre el sistema de archivos raíz, no montado por el arranque desde medio alternativo.
Problemas de configuración del núcleo (kernel).
Cuando se genera un nuevo núcleo debe mantenerse siempre un respaldo del núcleo anterior,
y saber como levantar el sistema con él; un núcleo recientemente generado puede muy bien no
funcionar. En Linux es posible generar el nuevo núcleo en disquete, para fines de prueba, y
recién después copiar la nueva versión sobre la anterior en disco.
Errores en los scripts de arranque.
Los errores en los scripts de arranque son la causa más frecuente de falla en el arranque; son
también las de más fácil solución: basta arrancar el sistema en monousuario, editar los scripts
rc, corregir los errores y continuar con el arranque normal. Es preciso verificar qué editor hay
disponible en modalidad monousuario y saber manejarlo; algunos sistemas requieren montar

/usr para disponer de vi. El editor ed, poco amigable, suele estar disponible en todos los UNIX.
En Linux, el disquete de rescate ofrecido por las distintas distribuciones suele tener un conjunto
de herramientas razonables para lidiar con estas dificultades; puede dar mejores resultados
recurrir al disquete de rescate que intentar el arranque monousuario.
9.2 Detención del sistema

En otros sistemas operativos es práctica común arrancar de nuevo el sistema operativo como
primer intento para resolver cualquier problema. Los sistemas UNIX suelen realizar tareas
críticas, atender múltiples usuarios o soportar redes de datos; no puede pensarse en arrancar
de nuevo el sistema así sin más; es imprescindible pensar primero e intentar solucionar los
problemas sin bajar la máquina. Esto no es una aspiración quimérica; es posible en muchos
casos. Es normal para una máquina UNIX pasar meses sin detenerse. Solo en casos de
agregar un dispositivo, sufrir una falla de hardware, un estado de confusión del sistema o la
imposibilidad de acceder, puede pensarse en rearrancar. En suma, cuando realmente no hay
otra solución.
Si se han hecho cambios en los scripts de arranque conviene rearrancar el sistema para
verificar el funcionamiento correcto de los cambios efectuados sin esperar el próximo arranque,
que puede darse en un momento donde el autor de los cambios no esté presente o ya no
recuerde lo hecho.
Hay diferentes formas de bajar un sistema o arrancarlo de nuevo:
 Apagar la llave del equipo.
 Usar el comando shutdown.
 Usar el comando halt y reboot (BSD, Linux).
 Enviar al proceso init la señal TERM.
 Usar telinit para cambiar el nivel de ejecución del proceso init (System V).
 Matar el proceso init.
Apagar la llave del equipo.
Ni siquiera en sistemas UNIX personales es aceptable bajar el equipo apagando la llave:
pueden perderse datos o corromperse lógicamente los sistemas de archivos. Apagar la llave
puede ser inevitable en caso de catástrofe natural o de bloqueo total del sistema.
shutdown
El comando shutdown es el método más prolijo, seguro y completo de bajar un sistema UNIX.
Dispone de una variedad de opciones, variables según los UNIX, pero en general permite fijar
anticipadamente el momento de la bajada, enviar avisos a los usuarios, decidir si será un
apagado, un rearranque o una bajada a monousuario. Procede enviando señales de
terminación a todos los procesos en forma ordenada, sincroniza y desmonta los sistemas de
archivos, avisa cuando terminó ("System halted", "Power down", o similar).
shutdown -r now
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.
10. MANTENIMIENTO DE CL A VES

DE USUARIOS
La creación y remoción de usuarios es una tarea de rutina en la administración de sistemas.
Suele ser realizada a través de programas asistentes de administración, usualmente de
interface gráfica, o a través de scripts o guiones de comandos. Aquí se describen las tareas
paso a paso en su realización manual. Finalmente se hace referencia a comandos existentes en
algunos sistemas para facilitar y asegurar la ejecución de estos procesos. El mantenimiento de
usuarios es un tema de importancia para la seguridad del sistema; las cuentas poco usadas, o
de contraseña trivial, son el blanco preferido de los violadores de sistemas.
Existen servicios especiales para el manejo de cuentas a nivel de red, simplificando la
administración y permitiendo el ingreso del usuario en cualquier máquina de la red. Estas
facilidades tienen sus propios problemas de seguridad; son un tema aparte; no se tratan aquí.
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
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
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:::::
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
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.
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:
• copiar hacia el directorio personal del usuario archivos de inicialización;

• fijar la casilla de correos del usuario y establecer alias de correo.
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.
Fijar contraseña inicial.
El superusuario puede cambiar en cualquier momento la contraseña de cualquier usuario

mediante el comando
passwd nombre_usuario.
Un usuario común puede cambiar su propia contraseña digitando solamente passwd. El
comando passwd suele exigir un mínimo de largo o uso de caracteres de puntuación, números,
mezcla de mayúsculas y minúsculas, para alcanzar un cierto nivel de inviolabilidad. No debe
dejarse nunca una cuenta sin contraseña, especialmente en ambientes de red o con acceso a
Internet.
Crear directorio propio del usuario.
La siguiente secuencia de comandos crea un directorio para el usuario jperez:

mkdir /export/home/jperez
chown jperez /export/home/jperez
chgrp usuarios /export/home/jperez
chmod 700 /export/home/jperez
En ambientes menos restrictivos, los permisos de los directorios propios pueden ser 755, lo que
permite a todos los usuarios del sistema ver los directorios personales. Los usuarios siempre
pueden limitar el acceso sobre los subdirectorios contenidos en su directorio personal.
Copiar archivos de inicialización.
Algunos comandos y utilitarios admiten personalización colocando archivos en el directorio

propio del usuario. Estos archivos generalmente empiezan con punto, lo que los hace
normalmente ocultos, y terminan con rc, por "run command". Siguen algunos ejemplos
comunes:
Comando Archivo Usos
csh .login fija tipo de terminal, variables de ambiente, opciones para biff y mesg
fija alias de comandos, rutas de búsqueda, valor de umask, cdpath para

.cshrc búsqueda de nombres de archivo; fija variables promtp, history,
savehist
.logout imprime recordatorios, borra la pantalla
fija tipo de terminal, variables de ambiente, opciones para biff y mesg;

sh .profile fija alias de comandos, rutas de búsqueda, valor de umask, cdpath para
búsqueda de nombres de archivo, etc.
vi .exrc opciones para el editor vi
emacs .emacs_pro Opciones y asignación de teclas para el editor emacs
mailx .mailrc aliases personales para correo, opciones para el lector de correo
tin .newsrc especifica grupos de interés para noticias
fija configuración de X11 (sistema de ventanas): tipos de letra, colores,

xrdb .Xdefaults
etc.
Comando Archivo Usos
startx .xinitrc fija ambiente inicial para X11
xdm .xsession fija ambiente inicial para X11
Suele haber un conjunto ya preparado de archivos de inicialización, usualmente en /erc/skel;

también pueden crearse, en /etc/skel o en /usr/local/lib/skel, editándolos para reflejar
configuraciones útiles al usuario corriente. Se debe proveer un ambiente razonable para
usuarios no calificados, sin "sobreprotección": evitar cosas tales como crear alias de comandos
para emular DOS, u obligar a uso interactivo en el borrado.
La siguiente secuencia de comandos instala los archivos de inicialización en el directorio propio
del usuario:
cp /usr/local/lib/skel/.[a-zA-Z]* /export/home/jperez
chmod 644 /export/home/.[a-zA-Z]*
chown jperez /export/home/.[a-zA-Z]*
chgrp usuarios /export/home/.[a-zA-Z]*
No es posible usar el comando
chown jperez /export/home/.*
ya que ello cambiaría la propiedad del directorio padre, /export/home, dándosela al usuario
jperez, debido a que el directorio padre ".. " queda incluido en ".*"; éste es un error común y
peligroso.
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.
Si bien no es necesario asignar el usuario a su grupo por defecto en /etc/group, conviene

igualmente hacerlo para tener actualizada la lista de integrantes del grupo. Sí debe editarse
/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.
Tabla de usuarios y guía telefónica.
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
Verificar la nueva cuenta.

Para verificar la validez de la nueva cuenta, ingresar al sistema como el nuevo usuario y
ejecutar los comandos
pwd
ls –la
para verificar la ubicación inicial en el directorio propio y la existencia de los archivos de
inicialización.
El usuario debe ser notificado por algún medio seguro de su nombre de login y contraseña. Este
momento es oportuno para entregarle documentación descriptiva del sistema. Ya debe haber
firmado su conformidad con el documento de recomendaciones de uso y comportamiento
esperado; solo resta recordarle la necesidad de cambiar su contraseña en cuanto ingrese al
sistema.
Eliminar usuarios.
Cuando un usuario abandona la institución, su cuenta debe ser inmediatamente bloqueada. Se

procederá luego a eliminar la cuenta de los archivos de contraseñas y grupos, la casilla de
correo, las referencias en la tabla de usuarios, listados telefónicos y otros, conservando los
datos históricos que la institución especifique. Los archivos podrán transferirse en propiedad a
otro usuario o ser eliminados. En definitiva, todo rastro del nombre de login debe ser eliminado,
pero debe recordarse la recomendación de no reutilizar los números UID.
Una lista de control incluiría:
 Fijar cuotas del usuario en 0, si se está usando cuotas;
 Eliminar al usuario de guías telefónicas, bases de datos o listas;
 Eliminar al usuario del archivo de aliases, o redirigir su correo a otra dirección;
 Eliminar el archivo de procesos diferidos (crontab) y trabajos pendientes con at.
 Eliminar procesos del usuario que se hallen aún corriendo.
 Eliminar archivos temporales del usuario en /tmp y /var/tmp.
 Eliminar al usuario de los archivos passwd, shadow, group.
 Eliminar el directorio propio del usuario.
 Eliminar el archivo de distribución de correo del usuario en /var/spool/mail.
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.
Son cuentas de usuario que no corresponden a personas. Es el caso de bin y daemon. Es

posible crear otras cuentas de pseudo login, como shutdown, halt, who; estas cuentas tienen
como shell un programa que sólo ejecuta el comando indicado.
Herramientas de administración de usuarios.
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.
11. INSTALACIÓN Y MA NTENIMIENTO

DE DISPOSITIVOS
11.1 Sistema de arch ivos

Un sistema de archivos en UNIX puede contener miles de archivos, cientos de directorios y
cientos de enlaces simbólicos, dependiendo de la distribución y de lo que se haya instalado.
Convenciones en nombres de archivos y directorios.
/bin archivos ejecutables, comandos de usuario

/boot archivos de arranque
/cdrom punto de montaje para la uniad de CD-ROM
/dev archivos especiales de dispositivos [subdirectorios propios de System V]
./dsk dispositivos de disco
./fd dispositivos descriptores de archivo
./kd dispositivos de teclado y despliegue
./kmem memoria
./null dispositivo para descarte de salidas
./osm mensajes de error del núcleo
./pts pseudo ttys; igual que /dev/pts*
./rdsk dispositivos crudos de disco
./term terminales; igual que /dev/tty*
./xt pseudo ttys; para capas DMD
/dosc punto de montaje para la partición DOS
/etc configuración de paquetes, configuración de sistema
./init.d scripts de arranque y detención de programas
./rc?.d enlaces a scripts, con K o S (Kill o Start), y número de secuencia para
controlar el arranque
./skel archivos de inicialización para nuevos usuarios
/export directorios de usuarios en sistemas grandes

/floppy para montar una unidad de disquete
/home objetos relacionados con los usuarios
/lib bibliotecas de desarrollo y material de apoyo
/lost+found archivos perdidos
/mnt punto de montaje de dispositivos externos
/proa archivos de control de procesos
/root directorio propio para el supervisor (root)
/sbin archivos ejecutables de administración
/tmp archivos temporales
/usr ejecutables, documentación, referencia
./X11R6 sistema X-Windows
./bin más ejecutables
./doc documentos de paquetes de software
./incluye encabezados .h de bibliotecas en C
./info archivos de info, información de UNIX (GNU)
./lib más bibliotecas en C
./local ejecutables instalados por el administrador
./man subdirectorios de páginas del manual
./sbin más archivos ejecutables de administración
./share compartidos
./src (source) código fuente del kernel
/var archivos de log, auxiliares, archivos que crecen
./backup respaldo de algunos archivos del sistema
./catman páginas man ya formateadas
./lib información propia de programas
./lock control de bloqueos
./log archivos de registro de mensajes (log) del sistema
./spool colas de impresión, intermedios de correo y otros
./run información de procesos (PIDs)
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.
Cantidad de dispositivos conectados. El SCSI angosto soporta 8, el SCSI ancho

(wide) hasta 16.
Largo de cable. Limitado a 6 m en SCSI-1, a 3 m en SCSI-2. En Ultra SCSI el largo
máximo es 1.5 m si se usan 8 dispositivos, pero 3 m si se conectan solo 4. La
introducción de un sistema de señalización diferencial ("differencial SCSI") aumenta el
largo a 25 m en SCSI-2 y a 12 m para Ultra SCSI, pero el modo diferencial es totalmente
incompatible con el convencional de extremo único ("single-ended"); todas las partes
involucradas deben ser de modo diferencial.
La tabla siguiente da una idea de la complejidad de esta familia
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 -
Ultra SCSI 20 8 20 1.5 25 -
Wide Ultra SCSI 20 16 40 1.5 25 Fast-20 wide SCSI
Wide Ultra2 SCSI 40 16 80 - 12 Fast-40 wide SCSI
SIde Ultra3 SCSI 80 16 160 - 12 Ultra-160
Se emplean diversidad de conectores. Los siguientes ejemplos se ofrecen a modo ilustrativo.

 Centronics de 50 pines, para SCSI-1 y SCSI-2, dispositivos externos.
 Conectores para cable chato de 50 pines, para SCSI-1 y SCSI-2, dispositivos internos.
 Mini-micro, denominación HD50, 50 pines, para SCSI-2, dispositivos externos.
 Wide mini-micro, denominación HD68, 68 pines, para SCSI-2 o SCSI-3, dispositivos
internos o externos.
 SCA-2 (Single Connector Attachment), de 80 pines, para SCSI-3, dispositivos internos.
Incluye alimentación, datos y configuración SCSI; provee todo en un solo conector, útil
para dispositivos transportables.
El esquema de conexión SCSI es "en salto", un dispositivo tras otro, por lo cual cada dispositivo
tiene 2 puertos SCSI, idénticos e intercambiables. Ningún puerto de la cadena puede quedar sin
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
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.
 Etiquetar y particionar el disco.

 Crear los sistemas de archivos UNIX en las particiones.
 Verificar la integridad de los sistemas de archivos creados .
 Fijar el montaje automático de los sistemas de archivos creados.
 Fijar áreas de intercambio (swap) para memoria virtual.
Conectar el disco al computador.
Instalar físicamente el disco realizando las verficaciones propias de cada interfaz.
Instalar soporte en el kernel.
Según el sistema, será preciso asegurarse de disponer en el kernel de soporte para la interfaz.
Esto puede lograrse cambiando algunas líneas en los archivos de configuración del kernel y
recompilando, o más frecuentemente, habilitando módulos cargables para soporte de la interfaz
pedida. En Linux, el soporte IDE viene casi siempre, pero puede ser necesario habilitar un
módulo para soporte SCSI. Esto puede hacerse durante el proceso de instalación, mediante
utilitario de instalación propio de la distribución o editando el archivo /etc/modules, previo
estudio de los nombres de módulos disponibles y sus prestaciones.
Crear dispositivos controladores.
El acceso a los dispositivos se realiza a través de archivos de dispositivo en el directorio /dev.
Para acceder a un nuevo disco se precisan dos dispositivos, uno de bloque para el montaje y
uso habituales y otro de caracter para respaldo y verificación. Actualmente los sistemas UNIX
vienen con cantidad de dispositivos ya creados, siendo raro el caso de verse obligado a crear
uno. El procedimiento de creación hace uso de un script en /dev llamado MAKEDEV; este script
ejecuta el comando mknod con el nombre del dispositivo a crear y los parámetros adecuados
para cada tipo de dispositivo.
11.1.2 Dar formato al disco
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.
11.1.3 Particionar el disco
Particionar un disco es dividir su espacio total en secciones manejables independientemente.

Sólo el controlador conoce la forma de este particionado; el software de nivel superior ve cada
partición como independiente. Un buen particionado separa las áreas de datos del sistema de
las de los usuarios, evitando interferencias; el llenado de una partición por usuarios o
programas desbocados no anula el disco ni bloquea el sistema; mejora el rendimiento, facilita
los respaldos. El esquema de particiones suele guardarse como una "etiqueta" (label) en los
primeros sectores del disco; el formato es variable, pero el objetivo es lograr el arranque
correcto del sistema con disponibilidad de todas las particiones.
Actualmente se tiende a crear menos particiones. Deben existir al menos estas:
 Partición raíz (root). Lo básico necesario para arrancar el sistema en monousuario.
 Partición de intercambio (swap). Almacena las páginas de memoria que no caben
en la memoria física del sistema.
 Partición de usuarios. Espacio para datos de los usuarios del sistema, bibliotecas y
aplicaciones.
Siguen algunas recomendaciones sobre el particionado.
 Si el sistema comprende varios discos, copiar en uno de ellos el sistema de archivos raíz,
y asegurase de poder arrancar el sistema desde allí.
 Al agregar memoria física, agregar también área de swap; debe haber al menos tanto
swap como memoria física; el doble de swap si la memoria física es poca (64 MB o
menos).
 Repartir el área de swap en discos distintos mejora el rendimiento.
 Una partición a respaldar no debería exceder la capacidad del medio de respaldo, para
evitar el multivolumen.
 Puede convenir crear una partición para el directorio /tmp, de libre acceso; si se halla en
la partición raíz, al llenarse bloquea el sistema.
 También puede convenir crear una partición para /var, donde se ubican los archivos de
registro de eventos del sistema, que tienden al crecimiento, por idéntica razón.
Volúmenes lógicos.
Existen diversos esquemas de manejo de volúmenes lógicos, en los cuales varios discos o
particiones pueden configurarse como un único disco virtual. Hay varias maneras de realizar la
concatenación, con diferentes consideraciones de eficiencia. Algunos soportan RAID5
(Redundant Array of Inexpensive Disks) con capacidad de recuperación de datos en el volumen
lógico en caso de falla de alguno de los discos. Los manejadores de volúmenes lógicos proveen
también "mirorring", discos espejo idénticos siempre sincronizados; al fallar uno, el otro toma la
posta sin interrupción del servicio. Al reponerse el disco dañado es preciso resincronizar con el
activo.
Linux tiene soporte RAID en el kernel y un manejador de volúmenes llamado Linux LVM.
11.1.4 Crear sistemas de archivos.
El sistema de archivos UNIX es el conjunto de estructuras necesarias para almacenar y

recuperar datos. Se debe crear un sistema de archivos en cada partición formateada. Un
sistema de archivos se crea con el comando newfs y el nombre de la partición. Por ejemplo,
newfs /dev/hda3
El comando newfs es una interfaz amigable para el comando mkfs, capaz de aceptar múltiples
opciones.
La estructura de sistema de archivos 4.2BSD, usada en los sistemas modernos, se compone
de:
 Un conjunto de celdas para alojamiento de inodos.
 Un conjunto de super-bloques distribuidos.
 Un mapa de los bloques en el sistema de archivos.
 Un resumen del uso de bloques.
 Un conjunto de bloques de datos.
Un inodo es una entrada de largo fijo con información sobre un archivo. No puede haber más
archivos que inodos. Muchos archivos chicos requerirán muchos inodos, pocos archivos
grandes requerirán pocos inodos. Si bien la cantidad de bytes correspondientes a un inodo
puede asignarse en el momento de creación del sistema de archivos, el valor por defecto de
4096 suele ser una buena elección para el caso general.
Un superbloque es un registro descriptivo de las características del sistema de archivos: largo
de los bloques, tamaño y ubicación de las tablas de inodos, el mapa de bloques y el resumen
de uso de bloques, tamaño de los grupos de cilindros para optimización de acceso y otros
parámetros. Se mantienen superbloques de respaldo en diferentes lugares del disco. Es posible
indicar al comando de reparación fsck el uso de un superbloque alternativo en caso de daño del
superbloque principal; hay uno en el bloque 32; el comando newfs -N muestra la ubicación de
los superbloques de respaldo al momento de crear el sistema de archivos.
UNIX mantiene en memoria una copia del superbloque para cada sistema de archivos montado,
además de varias copias en disco. El comando sync pasa a disco esa información, coordinando
todas las copias y asegurando el pasaje a disco de todos los datos. El sistema realiza por sí
mismo esta sincronización cada 30 segundos para minimizar pérdidas en caso de falla. Si se
debiera realizar la sincronización manualmente, antes de un comando halt, por ejemplo, se
recomienda ejecutarlo dos veces: el comando puede devolver el control al operador antes de
finalizar la escritura, pero un segundo sync no se ejecuta hasta terminar el primero.
El mapa de bloques del disco es una tabla de bloques libres; al grabar un nuevo archivo se
examina esta tabla para elegir bloques libres con la disposición de almacenamiento más
eficiente.
El resumen de uso de bloques retiene información sobre los bloques que ya están siendo
usados.
11.1.5 Montaje automático.
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).
 opciones de montaje: rw (read-write, lectura escritura), ro (read-only, solo lectura), u otros

parámetros de control.
 frecuencia de respaldo (dump); poco usado.
 orden de verificación para fsck. Si tienen el mismo número y están en diferentes discos
físicos se verifican en paralelo (simultáneamente). Colocar el mismo número para
particiones en un mismo disco obliga a continuos movimientos de las cabezas
degradando significativamente el rendimiento.
La información del fstab la utilizan los comandos mount, umount, swapon y fsck; la información
contenida en este archivo es vital, y debe ser la correcta.
mount /usr
umount /usr
permiten montar y desmontar el dispositivo físico refiriéndose al directorio; consultan /etc/fstab
para obtener el nombre del dispositivo y las opciones de montaje.
mount -a
monta toda la lista de sistemas de archivos registrada en el /etc/fstab, y
mount -a -t ufs
monta todos los de tipo ufs.
No es posible desmontar un sistema de archivos sobre el cual se está posicionado, ni un
sistema de archivos con archivos abiertos o en uso por un proceso.
Verificar y reparar sistemas de archivos.
Aunque el sistema de archivos de UNIX es muy sólido, y capaz de resistir bien aún ante
algunas fallas de hardware, diferentes condiciones de uso tienden a producir inconsistencias. El
comando fsck (filesystem check) es la herramienta de verificación y reparación de sistemas de
archivos.
Como el superbloque se mantiene en memoria y se graba en disco periódicamente, fenómenos
como caídas del núcleo (kernel panic, algo raro pero posible), o interrupciones en la
alimentación resultan en falta de coherencia entre la versión del superbloque en memoria y en
disco; en el siguiente arranque, la versión del disco no refleja fielmente el estado del sistema de
archivos. El sistema por sí mismo es capaz de conocer esta situación, y correr el programa de
verificación cuando el sistema no ha sido desmontado correctamente al apagar, o
periódicamente luego de un cierto tiempo sin verificación o cuando la cantidad de montajes
(arranques) excede un cierto valor. La opción -p de fsck es usada en el arranque; el archivo
/etc/fstab provee información sobre los sistemas de archivos y la secuencia de ejecución. Con
esta opción, fsck corrige por sí solo una serie de fallas sin consultar al operador. Invocado sin
parámetros, pide confirmación antes de realizar las correcciones.
fsck -p /dev/rsd0g
corre la verificación sobre el dispositivo indicado, con corrección automática, como se hace en
el arranque.
fsck /dev/rsd0g
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.
11.1.6 Mantenimiento de sistemas de archivo (cuotas, du, df)
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.
El comando df da un resumen del uso del espacio a nivel de todo el sistema:

df
muestra el espacio utilizado en cada sistema de archivos, incluso a veces en los que están
montados vía NFS. Si se indica uno en particular, da el espacio utilizado en ese sistema de
archivos:
df /dev/hda2
Estos comandos informan el espacio en "bloques"; los bloques tienen diferente tamaño según
las versiones de UNIX, generalmente 512 b o 1 KB (1024 B); suele haber opciones para
controlar la salida.
Compresión de datos.
Los sistemas UNIX suelen proveer al menos un conjunto de herramientas de compresión de
archivos. El conjunto comprende, mínimamente: un programa para comprimir, un programa
para descomprimir y un programa para visualizar comprimidos (u opciones de un mismo
programa).
compress: tradicional en Unix, compresión menor que gzip, algo más rápido. Usa
codificación Lempel-Ziv adaptativa. Comandos: compress, uncompress, zcat.
gzip: la mejor compresión, más lento, alguna incompatibilidad entre versiones distintas
de gzip. Esencial para descomprimir paquetes bajados por Internet. Algoritmo de
compresión Lempel-Ziv (LZ77). Comandos: gzip, gunzip, zcat.
zip: versión Unix del conocido PKZIP de MS-DOS y Windows; análogo a la acción
combinada de los comandos tar y gzip. PKZIP (MS-DOS) y zip (Unix) crean archivos
compatibles en tanto las versiones en uno y otro sistema operativo se correspondan.
Comandos: zip, unzip.
bzip2: comprime archivos con el algoritmo de compresión por reordenamiento de
bloques de Burrows-Wheeler y codificación Huffman. Obtiene generalmente mejor
compresión que los programas basados en algoritmos LZ77/LZ78. Comandos: bzip2,
bunzip2, bzcat, bzip2recover.
Puede esperarse una reducción de un 50% a un 75% en archivos de texto o binarios; los
archivos encriptados no comprimen, o aún se agrandan: sus datos son aleatorios, de
distribución uniforme; los programas de compresión no encuentran brechas para actuar. Lo
mismo pasa al intentar comprimir archivos ya comprimidos.
"Skulker scripts".
Este nombre se aplica a los scripts que recorren el sistema buscando archivos innecesarios
para borrar: temporales viejos, archivos "core", archivos "dead_letter", respaldos de edición, etc.
Los nombres de los archivos a borrar dependerán de cada sistema; deben ser publicados, para
hacer saber a los usuarios que no deben emplear estos nombres, ni sorprenderse cuando sus
archivos desaparezcan. Los scripts "skulker" suelen correrse semanalmente, por root, vía cron.
Cuotas de disco.
Ante una falta de espacio en disco, la primera pregunta que cabe hacerse hoy día es si no será
necesario agregar discos. Si esto no es posible, mientras se logre mantener bajo control el
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
o activar el módulo cargable. Además de esto, es preciso habilitar explícitamente el sistema de

cuotas al arrancar el sistema y después de montados los sistemas de archivos; esto se hará
desde un script rc o desde inittab, según la versión de UNIX. Una secuencia típica de comandos
de arranque puede ser:
/sbin/mount -a
echo -n 'verificando cuotas...'
/sbin/quotacheck -avug
echo ' hecho.'
/sbin/quotaon -avug
donde las opciones significan: a recorrer todos los sistemas de archivos registrados en
/etc/fstab, v mensajes verbosos, u habilitar cuotas para usuarios, g habilitar cuotas para grupos.
La habilitación de cuotas debe hacerse siempre después que los sistemas de archivos han sido
montados; de otro modo, no funcionará.
Fijar cuotas sobre un sistema de archivos.
Requiere crear y configurar el o los archivos de cuotas, y declarar el uso de cuotas en el
sistema de archivos en la tabla de sistemas de archivos.
cd /usuarios # directorio raíz de la partición
touch quota.user
touch quota.group
chmod 600 quota.user quota.group
Operando como root, estos comandos crean un archivos de cuotas vacíos para usuarios y
grupos en el sistema de archivos montado sobre /usuarios.
Para activar las cuotas, en el archivo /etc/fstab (BSD), se agrega a la línea de montaje del
sistema de archivos las opciones userquota y groupquota; otros sistemas sustituyen la opción
rw en este archivo por rq, lectura-escritura con cuotas.
# /etc/fstab con cuotas
/dev/hda1 / ext2 defaults 1 1
/dev/hda2 /usuarios ext2 defaults,usrquota,grpquota 1 2
Este ejemplo habilita cuotas para grupos y usuarios sobre la partición montada sobre el
directorio /usuarios.
Luego de fijar las cuotas para cada usuario, con el comando edquota, estos archivos se
poblarán corriendo el comando quotacheck sobre la partición en cuestión.
edquota.
El comando
edquota -u nombre_usuario
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.
Cuotas sobre NFS.

La implementación de cuotas es local al sistema de archivos; los sistemas cliente no hacen
verificación de cuota, pero los límites son verificados en el servidor en todas las operaciones
que afectan el consumo de disco, por lo que la limitación es efectiva. Muchos sistemas proveen
rquotad para responder información de cuota a través de la red mediante el comando
quota, advirtiendo a los usuarios sobre uso de espacio en sistemas de archivos montados vía
NFS.
11.2 Sistema de i mpresi ón

Una de las actividades mas comunes que realiza un usuario es la impresión de documentos. Es
posible enviar a imprimir un documento directamente de la aplicación o utilizando algunos de los
comandos que Unix proporciona para ello. Los siguientes comandos sirven para el control de
las impresiones.
Control del ambiente de impresión.
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>
El comando lpr (line printer)Descripción: el principal comando de impresión. Crea un trabajo de

impresora en un área de spooling para una impresión subsecuente (un trabajo de impresión se
divide en un archivo de control y otro de datos)
Sintaxis:
lpr [ opciones ] [ archivos ]
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)
Descripción: permite suprimir los archivos en espera de ser impresos.

Sintaxis:
lprm [ opciones ] [ #job] [usuarios]
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
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:
help muestra una lista de comandos internos de lpc
help comando muestra ayuda del comando interno indicado
enable impresora habilita puesta en cola de trabajos
disable impresora deshabilita puesta en cola de trabajos
start impresora habilita impresión en la impresora indicada
stop impresora deshabilita impresión, permite puesta en cola
abort impresora detiene impresión, aún del trabajo en curso
down impresora mensaje coloca la impresora fuera de servicio, muestra mensaje
up impresora vuelve la impresora al servicio
clean impresora elimina todos los trabajos de la cola
topq impresora id_trabajo mueve un trabajo hacia el principio de la cola
topq impresora usuario aumenta prioridad de trabajos de usuario
restart impresora rearranca demonio de impresión; la falta de lpd la indica

lpq
status impresora indica estado de cola, impresión, demonio y entradas en cola
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.
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:
Accept comienza a aceptar trabajos para un dispositivo
Cancel cancela un trabajo en cola o en ejecución
Disable deshabilita la impresión en un dispositivo
Enable habilita la impresión en un dispositivo
Lp coloca trabajos en cola para imprimir
Lpadmin configura el sistema de impresión
Lpmove mueve trabajos de un dispositivo de impresión a otro
Lpsched demonio que maneja la agenda de trabajos de impresión
Lpshut deshabilita lpsched
Lpstat muestra estado del sistema
Reject detiene la aceptación de trabajos para un dispositivo
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
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.
Eliminar una impresora.

A veces, intentar configurar o reconfigurar una impresora puede dejar el sistema de impresión
en estado de confusión irrecuperable, al punto de que el proceso de eliminación de la impresora
con lpadmin no funcione. Los siguientes comandos eliminan una impresora por la fuerza:
lpshut
lpadmin -xdestino
find /usr/spool/lp -name destino rm -rf {} \;
lpsched
lpstat -t
Se eliminan por la fuerza los archivos de configuración de la impresora destino. Si se trata de

una clase, se estará eliminando toda la clase! El comando final, lpstat -t, muestra el estado
completo, para verificar que se han eliminado todas las referencias a la impresora destino.
Obviamente, esta receta será utilizada sólo cuando los procedimientos normales hayan fallado.
Agregar una impresora (BSD).
Resumimos los pasos para agregar una impresora en forma manual. En muchas distribuciones
existen utilitarios para realizar esta tarea.
 Impresora local.
 crear la entrada en /etc/printcap;
 crear el directorio de spool; fijar dueño, grupo permisos;
 probar la impresora: arrancar la cola (lpc start), enviar un archivo corto (lpr), mostrar
la cola de impresión (lpq).
 Impresora remota.
 crear la entrada en /etc/printcap para impresora remota (rm, rp);
 crear directorio de spool; fijar dueño, grupo, permisos;
 habilitar en /etc/hosts.lpd del servidor la nueva máquina cliente.
 Impresora de red.
 fijar número IP de la impresora, según se indique en el manual de la impresora.
 verificar conectividad: la impresora debe responder a ping.
 instalar la impresora en un servidor de impresión, como impresora remota.

 crear el archivo falso, ajustar su dueño, grupo y permisos.
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.
Las impresoras PostScript.

Algunos detalles relativos a las impresoras PostScript:
 Las impresoras PostScript contiene una CPU. La velocidad de impresión depende no
sólo de la parte mecánica sino de la CPU, que puede no estar usando al máximo la
capacidad mecánica de impresión al procesar imágenes complicadas.
 Conectar las impresoras PostScript a interfaces bidireccionales, para permitir al software
controlador de la impresora informar errores.
 Los intérpretes PostScript requieren mucha memoria, que puede agotarse al imprimir
archivos PostScript complejos.
 Las impresoras PostScript tienen tipos de letra nativos; otros pueden ser cargados en
memoria. Si el trabajo a imprimir contiene un tipo de letra no disponible en la impresora ni
en la memoria, el trabajo se imprimirá en Courier (generalmente).
 Una interfaz serial puede no ser eficiente para una impresora color o para imprimir
bitmaps.
 Si un trabajo PostScript no imprime, usar una aplicación tal como GhostView para
visualizarlo en pantalla, como forma de asegurar la integridad del archivo.
 Algunas aplicaciones generan ocasionalmente comandos PostScript inválidos; los
mensajes de error pueden ser diferentes ante un mismo tipo de error según el intérprete
PostScript.
Sugerencias.
 Usar contabilidad de impresión, aunque no se cobre por el uso. No penaliza mucho el
sistema, permite conocer la carga sobre la impresora, el origen de los trabajos, quiénes
la usan. Todo esto ayuda cuando es preciso decidir tipo, características y ubicación de
una nueva impresora.
 No usar páginas de encabezado (banner) si no es imprescindible.
 Proveer facilidades para la reutilización del papel, o su reciclado.
 Proveer a los usuarios visualizadores en pantalla para disminuir las impresiones
"borrador". Un buen uso de la contabilidad es detectar trabajos impresos repetidamente.
 No gastar en impresoras "caras": la tecnología de impresión es madura; considerar
calidad de impresión realmente requerida, producción (páginas promedio por minuto),
costo de insumos, fortaleza mecánica. Una impresora de 10 páginas por minuto es
suficiente para al menos 5 escritores a tiempo completo.
 Mantener en stock cartuchos de tinta o toner; los cartuchos siempre se terminan cuando
uno está imprimiendo :-). Una sacudida amable puede redistribuir el toner de un cartucho
de impresora láser "gastado" y obtener unas 100 páginas más.
 Asegurar la impresora de red: al ser accesibles vía telnet para cambiar su configuración,
las impresoras de red proveen control por contraseña; fijarla.
11.3 U nidades de cinta

Escoger qué medios usar
Los medios de respaldo típicos son los siguientes:
1/2 – pulgada de cinta
1/4 – pulgada de cinta de cartucho de transmisión continua
8 - mm cinta de cartucho
4 - mm cinta de cartucho (DAT cinta digital de audio)
Los medios a escoger dependen de la disponibilidad del equipo que lo soporta y de los medios
(por lo general la cinta) donde se acostumbre almacenar los archivos
La siguiente tabla muestra los dispositivos de cinta comúnmente usados para respaldar
sistemas de archivos.
La capacidad de almacenamiento para cada dispositivo depende del tipo de de unidad de disco
y los datos a escribir a la cinta.
Capacidad de Almacenamiento de los Medios de respaldo
1/2 – pulgada de cinta 140 megabytes (6250 bpi)
1/2-pulgada cinta graba 140 megabytes (6250 bpi)
14-Gbyte 8 mm cinta graba 14 Gbytes
DLT 7000 1/2-pulgadas cinta graba 35-70 Gbytes
Nombres de dispositivos de respaldo
Se debe especificar una cinta o disquete para la copia de seguridad proporcionando un nombre
de dispositivo lógico. Este nombre señala al subdirectorio que contiene el archivo de dispositivo
"Crudo" e incluye el número de unidad lógica de la unidad de disco.
Nombre del tipo de dispositivo
Cinta /dev/rmt/n
Disquete /vol/dev/rdiskette0/unlabeled En general, usted especifica un dispositivo de cinta como

se muestra a continuación:
Directorio de dispositivos
Numero de controlador (0-n)
Compatibilidad de Berkeley
Directorio para el dispositivo crudo de cinta magnética
/dev/rmt/XAbn
Densidad Opcional
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
Segunda unidad, densidad media, rebobina /dev/rmt/1m

Segunda unidad /dev/rmt/1m, densidad media, no rebobina /dev/rmt/1mn
Manejo de los dispositivos de cinta (tareas)
Tu puedes usar la opción status con el comando mt para obtener información acerca de las
cintas. El comando mt reporta información acerca de cualquier dispositivo de cinta que esta
descrito en el archivo /kernel/drv/st.conf
Mostrar el estado de una cinta.
#mt -f /dev/rmt/n status
El siguiente ejemplo muestra el estado para una unida de cinta QIC-150 (/dev/rmt/0):
$ mt -f /dev/rmt/0 status
Archive QIC-150 tape drive:
sense key(0x0)= No Additional Sense residual= 0 retries= 0
file no= 0 block no= 0
El siguiente ejemplo muestra el estado para una cinta Exabyte (/dev/rmt/1):

$ mt -f /dev/rmt/1 status
Exabyte EXB-8200 8mm tape drive:
sense key(0x0)= NO Additional Sense residual= 0 retries= 0
El siguiente ejemplo muestra una manera rápida de sondear un sistema y localizar todas sus
unidades de cinta:
$ for drive in 0 1 2 3 4 5 6 7
> do
> mt -f /dev/rmt/$drive status
> done
Archive QIC-150 tape drive:
sense key(0x0)= No Additional Sense residual= 0 retries= 0
/dev/rmt/1: No such file or directory
1
2
3
Manejo de Cartuchos de Cinta Magnéticas

Si los errores ocurren cuando una cinta está siendo leída, se puede rebobinar y tensar la cinta,
limpiar la unidad de cinta magnética, y luego intentar otra vez.
Para Rebobinar y tensar la cinta se utiliza el siguiente comando:

$ mt -f /dev/rmt/1 retension
Nota: no ocupar la opción retension para non-QIC.
Rebobinando un cartucho de cinta magnética
Para rebobinar un cartucho de cinta magnética, usar el comando mt.
Por ejemplo:
$ mt -f /dev/rmt/1 rewind
Un respaldo de cinta que no puede ser leído es inútil. Así que, de vez en cuando se deben
limpiar y comprobar las unidades de cinta magnética para asegurar la operación correcta.
Revisar los manuales de hardware para instrucciones sobre procedimientos para limpiar una
unidad de cinta magnética, solo en caso de ser necesario.
Se puede verificar el hardware de cinta como se indica a continuación:
 Copiar algunos archivos a la cinta, volver a leer los archivos, y luego comparar los
archivos originales con los archivos copiados.
 Usar el opción de -v del comando de ufsdump para verificar los contenidos de los medios
con sistema de archivos fuente. El sistema de archivos debe ser desmontado o
completamente en desuso para que la opción –v sea eficaz sea eficaz.
Se debe estar consciente que el hardware puede fallar sin que el sistema lo reporte.
Siempre etiquete sus cintas después de un respaldo. Esta etiqueta nunca debe de ser
cambiada. Cada vez que usted hace un respaldo, haga otra etiqueta que contenga la siguiente
información:
 Día del respaldo
 Nombre de la maquina y archivo del sistema que fue respaldado.
 Nivel del respaldo
 Numero de la cinta (de 1 a n, si el respaldo necesita varios volúmenes).
 Cualquier información especifica de su sitio.
Se debe crear y mantener actualizada una bitácora de los medios de respaldo y la ubicación de
cada archivo respaldado.
11.3.1 Políticas de respaldo.
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
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
sistema operativo, deberá uno armarse de paciencia, bajar la máquina a monousuario y

respaldar el sistema en nivel 0. Existen programas especiales (archivadores o "filers")
capaces de tomar un registro periódico del estado del sistema y resincronizar el
respaldo. Debe considerarse esta posibilidad cuando no sea posible reducir la actividad
del sistema en ningún momento.
Verificar el respaldo: hay también historias de respaldos tomados cuidadosamente que
nunca pudieron restaurarse. Releer la cinta con restore para generar la tabla de
contenido es una prueba razonable; probar recuperar un archivo en particular obliga a
recorrer partes más alejadas de la cinta, ofreciendo una comprobación más sólida. Debe
verificarse también que es posible restaurar desde varias cintas, que se pueden leer
cintas grabadas tiempo atrás, y que es posible leer en otras unidades además de la
habitual.
Vida útil de las cintas: como todo en el mundo, las cintas tienen una vida limitada,
indicada por los fabricantes en cantidad de pasadas. Un respaldo, una restauración o un
salto de archivos representan, cada uno, una pasada.
Crecimiento del sistema: el bajo precio de discos tiende a generar un aumento
desordenado de la capacidad de almacenamiento. Imponer un criterio ordenado de
crecimiento, con calificación de datos por criticidad y actividad, su separación racional en
distintos sistemas de archivos, la concentración de información vital en un servidor
confiable, son algunas medidas coactivas para alcanzar un respaldo confiable y
humanamente posible.
12. CONFIGURACIÓN Y MANTENI -

MIENTO DEL USO DE LA RED
TCP/IP y Enrutami ento

El TCP/IP es el software básico de red utilizado en Internet y fue desarrollado en los primeros
sistemas UNIX. Incluye básicamente los siguientes componentes:
 Internet Protocol (IP). Es el protocolo de capa de red (capa 3) y se encarga de
transportar paquetes crudos de una máquina a otra.
 Internet Control Message Protocol (ICMP). Proporciona funciones de soporte de bajo
nivel a IP, por ejemplo mensajes de error.
 Address Resolution Protocol (ARP). Relaciona direcciones de capa 2 y capa 3 en una
LAN.
 User Datagram Protocol (UDP) y Transmission Control Protocol (TCP). Se usan para
enviar datos desde un programa a otro utilizando IP. UDP es un servicio no confiable y
sin conexión y TCP es un servicio confiable y orientado a conexión. Ambos son
protocolos de capa de transporte (capa 4)
El TCP/IP provee un ambiente de programación independiente del sistema que permite
intercambiar información entre diferentes sistemas (UNIX y no UNIX).
El conjunto de protocolos llamados TCP/IP corresponde con un modelo de capas como se
indica en la siguiente tabla:
Capa Función Ejemplos
Enlace de datos Hardware de red y dispositivos de red ARP, PPP, SLIP
Comunicación básica, direccionamiento y

Red IP, ICMP
enrutamiento
Comunicación extremo a extremo entre

Transporte TCP, UDP
programas
Aplicación Aplicaciones de usuario Telnet, ftp, nfs, dns

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:
------------------------- Segmento UDP (108 bytes) --------------
----------- Paquete IP (128 bytes) -----------
Ethernet IP UDP Datos de la Ethernet

Header Header Header aplicación Trailer
14 Bytes 20 Bytes 8 Bytes 100 Bytes 4 Bytes
Trama Ethernet (146 bytes)
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).
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
Hay varias clases de direcciones IP. Difieren en como se asigna la frontera entre parte de red y
parte de máquina.
Clase Primer byte Formato Comentario
A 1-126 R.M.M.M
B 128-191 R.R.M.M Normalmente con subredes
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.
ARP- Relación entre direcciones
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:
 Yo tengo esa dirección IP y mi dirección de capa de enlace es: 8:0:20:0:fb:6a

Ahora entonces la máquina que hizo la consulta ARP tiene la información de correspondencia
para la dirección IP deseada y la puede agregar en su tabla y así generar la trama ethernet
dirigida a la máquina deseada.
A su vez, la máquina que recibió la consulta original, tiene la correspondencia de la máquina
origen y también la incluye en su tabla pues es altamente probable que deba dirigirse
próximamente (para enviar una respuesta) a la máquina origen.
La trama de broadcast con la pregunta original incluye la dirección de capa de enlace de la
máquina origen, así como su dirección IP, por lo que terceras máquinas que no participen del
diálogo, podrían aprender de la pregunta la correspondencia de direcciones correspondiente a
la máquina origen. En realidad solamente tienen en cuenta ese dato aquellas máquinas que ya
tenían una entrada en su tabla referente a la máquina origen y lo que hacen es actualizarla con
la nueva información.
Esto es así para que las máquinas no agranden demasiado su tabla con información de
máquinas con las cuales quizá no tengan que hablar.
Las tablas además tienen tiempo de expiración con lo cual entradas no usadas van liberando
espacio en la tabla.
Existe en UNIX un comando arp que permite manejar el cache del protocolo ARP para
debugging.
RARP, BootP, DHCP
A veces existe la necesidad de conocer a partir de una dirección ethernet la dirección IP

asignada. Esto se utiliza en máquinas sin disco que arrancan cargando lo necesario de un
servidor. Para que todas las máquinas en este modo puedan cargar la misma imagen del
sistema operativo y no tener necesidad de disponer de una imagen por máquina, se utiliza el
protocolo RARP que consulta un servidor al cual se le pregunta:
¿ Que dirección IP corresponde a la dirección ethenet 8:0:20:0:fb:6a ?0
El servidor tiene una tabla de las direcciones IP asociadas a las diferentes máquinas según su
dirección de capa de enlace de datos y la máquina sin disco configura la imagen con la
dirección IP brindada por el servidor.
El protocolo RARP ha quedado obsoleto con el advenimiento del protocolo BOOTP (Boot
Protocol) que brinda más datos de configuración además de la dirección IP.
En la actualidad el DHCP (Dynamic Host Configuration Protocol) permite a una máquina
obtener toda la configuración a partir de un servidor en su red de área local.
Enrutamiento
Enrutamiento es el proceso de dirigir un paquete a través de la red desde una máquina origen a
otra destino.
La idea es enviar los paquetes a algún sitio donde pueden tener más información de cómo
llegar al destino deseado.
La información de enrutamiento se construye en una tabla de reglas del tipo:
 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
164.73.224.130 164.73.224.60 UGHD 0 801 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
164.73.224.76 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
164.73.224.0 0.0.0.0 255.255.255.128 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
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
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.
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
 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:
♦ ifconfig interfaz [familia] direccion_ip opciones

por ejemplo:
♦ ifconfig en0 128.138.240.1 netmask 255.255.255.0 broadcast 128.138.240.255

interfaz indica el nombre del driver asignado por el sistema operativo a la interfaz de red.
Para determinar las interfaces presentes (detectadas) en una máquina puede utilizarse el
comando netstat -i.
familia indica el tipo de protocolo de red que queremos asociar a la interfaz. En general
lo que nos interesa es el tipo IP por lo que se especifica inet como opción. La mayoría
de los UNIX toman inet por defecto por lo que es común no poner nada en el campo de
familia.
direccion_ip es la dirección IP asociada. Puede ser un nombre o una dirección en la
notación de puntos de Internet (Ejemplo: 128.138.240.1). Se recomienda poner las
direcciones como número para evitar que la máquina no arranque por no poder averiguar
la correspondencia entre nombre y número.
opciones más comunes:
 netmask Para especificar la máscara de la red. Puede ser notación decimal o
hexadecimal.
broadcast Para indicar la dirección IP de difusión, normalmente el default es todos 1 en la parte

de máquina de la dirección IP de acuerdo a la máscara. Puede ser notación decimal o
hexadecimal.
ifconfig interfaz Presenta la configuración actual de la interfaz. En muchos sistemas también
ifconfig -amuestra la configuración de todas las interfaces.
Configurar rutas estáticas: route
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:
♦ route operación [tipo] destino enrutador saltos

El argumento operación dice que estamos haciendo (add, delete), el destino es el número de
una red o una máquina o la palabra default. El enrutador es la máquina a la que hay que
enviarle los paquetes dirigidos a esa red o máquina destino. Los saltos es la cantidad de saltos
necesarios para llegar al destino.
El tipo es para decir que tipo es el destino. Puede ser una red o una máquina. En algunas
máquinas el tipo se indica con las palabras clave net o host y en otras con -net y -host.
Hay otra opción que es para borrar la tabla de ruteo que según el sistema puede ser route -f o
route flush.
La configuración actual de la tabla de ruteo puede verse con el comando netstat -rn.
Configuración dinámica estándar: routed
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.
Se puede usar el archivo /etc/gateways cuando se tiene más de una salida. El archivo tiene
líneas similares a comandos route.
Configuración para el arranque automático
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
#
En la versión moderna del ping, las salidas son del tipo:

• # ping maxwell
PING maxwell.iie.edu.uy (164.73.224.30): 56 data bytes
64 bytes from 164.73.224.30: icmp_seq=0 ttl=255 time=0.614 ms
^C
--- maxwell.iie.edu.uy ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.568/0.581/0.614/0.019 ms
#
Cuando la máquina destino no responde, el reporte de las dos versiones del ping se pueden ver
en los siguientes ejemplos
• # ping acer
no answer from acer.iie.edu.uy
#
# ping acer
PING acer.iie.edu.uy (164.73.224.3): 56 data bytes
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.
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.
Estado de la red: netstat
El comando netstat despliega informaciones varias sobre el estado de la red. En realidad de

acuerdo a las opciones con que se invoque brinda información de diferentes aspectos de la red.
Veremos los cuatro usos más frecuentes del netstat.
 Estado de las conexiones de red
 Configuración de las interfaces de red
 Estado de la tabla de ruteo
 Estadísticas de los diferentes protocolos de red
Estado de las conexiones de red
Sin argumentos el comando netstat despliega el estado de los puertos TCP y UDP activos (Con
la opción -a) despliega además los inactivos.
La salida es algo del estilo:
• FreeBSD
# 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
Las direcciones son indicadas en la modalidad máquina:puerto. Los nombres de máquinas se

obtienen a partir del Servidor de Nombres (DNS) y los nombres de puertos a partir del archivo
/etc/services. Si se especifica al netstat la opción -n no se hace la traducción de números a
nombres ni de las máquinas ni de los puertos.
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
ed1 1500 <Link> 48.54.e8.26.db.69 9665343 525 8972011 2 269894
ed1 1500 164.73.224/25 ampere 9665343 525 8972011 2 269894
lp0* 1500 <Link> 0 0 0 0 0
tun0* 1500 <Link> 0 0 0 0 0
sl0* 552 <Link> 0 0 0 0 0
ppp0* 1500 <Link> 155934 1719 159304 0 0
lo0 16384 <Link> 3857677 0 3857677 0 0
lo0 16384 your-net localhost 3857677 0 3857677 0 0
• 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
eth0 1500 0 2450985 0 0 0 1969656 0 0 0 BRU
lo 3924 0 148 0 0 0 148 0 0 0 LRU
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.
Estado de la tabla de ruteo

El comando netstat -r brinda información de la tabla de ruteo del kernel.
El siguiente ejemplo muestra la salida en un FreeBSD, ejecutado con la opción -n para que
brinde la salida en forma numérica.
# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 164.73.224.28 UGSc 19 29342 ed1

127.0.0.1 127.0.0.1 UH 13 9712 lo0
164.73.224/25 link#1 UC 0 0
164.73.224.28 0:40:95:15:89:d UHLW 20 33 ed1 864
164.73.224.29 link#1 UHLW 1 3081
164.73.224.30 8:0:2b:bc:f2:2a UHLW 4 32305 ed1 1121
164.73.224.40 48:54:e8:26:db:69 UHLW 1 2164094 lo0
164.73.224.60 0:0:21:95:90:34 UHLW 2 0 ed1 952
164.73.224.127 ff:ff:ff:ff:ff:ff UHLWb 1 3291 ed1
164.73.224.130 164.73.224.60 UGHD 0 524 ed1
164.73.224.255 164.73.224.60 UGHD 1 2009 d1
Los destinos (destination) y enrutadores (gateway) se indican en números IP o nombres

según se utilice la opción -n o no.
Las banderas (Flags) caracterizan la ruta y sus significados son:
U - (Up) Activa
G - (Gateway) El destino es un enrutador
H - (Host) El destino es una máquina.
D - Resultado de un ICMP Redirect
G y H juntas significa que es una ruta a una máquina pasando por un enrutador.
El campo Refs es el número de conexiones TCP que están usando esa ruta.
El campo Use es el número de paquetes enviados por esa conexión.
El campo Netif o If es la interfaz usada para esa ruta.
En la implementación del FreeBSD pueden observarse entradas asociadas con direcciones de

capa de enlace de datos. Esto es porque el sistema usa la misma tabla para almacenar la
información de ruteo y la tabla de ARP.
Estadísticas de los diferentes protocolos de red
El comando netstat -s muestra estadísticas de diferentes protocolos IP, ICMP, TCP y UDP
desplegando los valores de algunos contadores existentes en el código de los protocolos de
red.
Ejemplo OSF/1 3.2c:
# netstat -s
ip:
152480 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
1356 fragments received
0 fragments dropped (dup or out of space)
4 fragments dropped after timeout
0 packets forwarded
722 packets not forwardable
0 redirects sent
icmp:
11 calls to icmp_error
0 errors not generated 'cuz old message was icmp
Output histogram:
echo reply: 2
destination unreachable: 11
0 messages with bad code fields
0 messages < minimum length
0 bad checksums
0 messages with bad length
Input histogram:
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
92 completely duplicate packets (4815 bytes)

56 packets with some dup. data (249 bytes duped)
172 out-of-order packets (22545 bytes)
0 packets (0 bytes) of data after window
0 window probes
618 window update packets
3 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
29 connection requests
91 connection accepts
120 connections established (including accepts)
131 connections closed (including 13 drops)
3 embryonic connections dropped
48215 segments updated rtt (of 49036 attempts)
484 retransmit timeouts
0 connections dropped by rexmit timeout
2 persist timeouts
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive
udp:
61324 packets sent
73826 packets received
0 incomplete headers
0 bad data length fields
0 bad checksums
0 full sockets
5082 for no port (5071 broadcasts, 0 multicasts)
Encaminamiento de paquetes: traceroute

El comando traceroute permite ver la secuencia de enrutadores por los que pasa un paquete IP
para alcanzar un determinado destino.
Hay muchas máquinas que lo brindan como herramienta en el sistema operativo (IRIX, OSF/1,
BSDi, FreeBSD) pero existen fuentes disponibles para muchos sistemas. La instalación puede
requerir una modificación del núcleo.
La sintaxis es:
♦ 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.
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.
13. ADMINISTRACIÓN DEL

ÁREA DE S WAP
La memoria virtual consiste en disponer de espacio en disco para transferir trozos de memoria
hacia disco y viceversa; se compensa la falta de memoria haciendo actuar una porción de disco
como memoria adicional lenta. Esta operación de intercambio entre memoria y disco se
denomina paginado de memoria o "swapping", y "swap" el área de disco utilizada a este fin. El
proceso optimiza el pasaje de páginas a disco enviando las menos solicitadas. El área de
intercambio no tiene estructura de sistema de archivos; el kernel mantiene su propia lista de
equivalencia entre páginas de memoria y bloques de disco, en aras de la velocidad. El comando
swap (o swapon) habilita el uso de áreas de swap registradas en el /etc/fstab. Alguno de estos
comandos se ejecuta normalmente en la secuencia de arranque para habilitar el uso de
memoria virtual.
Con los privilegios de root
Es posible crear un archive de swap sin contra con los privilegios de root, pero pueden
presentarse problemas de sobreescritura, por lo que se recomienda que root sea el dueño de el
archivo de swap
Crea un directorio para el archivo de swap, en caso de ser necesario
Crea el archivo de swap.
# mkfile nnn[k|b|m] nombre del archive
Activar el archivo de swap.
# /usr/sbin/swap -a /ruta/nombre_de_archivo
Se recomienda utilizar rutas absolutas para el nombre del archivo.
El espacio de swap que ha sido adicionado y activado estará ahora disponible en el sistema a
menos que éste sea desmontado, es sistema sea reiniciado o el archivo de swap que
acabamos de crea sea removido. Tener presente que no se puede desmontar un sistema de
archivos mientras exista algún proceso o programa utilizando el espacio de swap asignado
Agregar una entrada en el archive de configuración /etc/vfstab donde se especifica la ruta
completa y el nombre del archivo designado para espacio de swap sin olvidar indicar que será
identificado como sistema de archivos tipo swap.
/ruta-completa/nombre-archivo - - swap - no -
Verificar que efectivamente se haya creado dicha área de swap

$ /usr/sbin/swap –l
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.
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
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.
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)
15. MONITOREO DEL SISTEM A
15.1 Bitácoras del admi nistrador

Syslog y Archivos log´s
Tanto el propio kernel del sistema operativo como los servicios de red o aplicaciones que están
corriendo en forma permanente en un sistema Unix mantienen archivos de registro de eventos
(logfiles) para reportar sucesos relevantes. Estos registros son de gran utilidad para determinar
a posteriori qué ha sucedido en un sistema en caso de un malfuncionamiento y para detectar en
forma temprana eventuales fallas en el sistema. Forma parte de las tareas del administrador
revisar periódicamente estos logs.
Una particularidad común a todos los archivos de registro de eventos es que crecen, lo que
obliga a definir alguna política para el manejo de estos archivos para evitar que llenen el
espacio en disco. La política a seguir puede variar de acuerdo al esfuerzo de administración y la
importancia que la organización preste a temas como la seguridad. Las políticas más comunes
son:
 No almacenar
 Resetearlos periódicamente
 Rotarlos, manteniendo datos por un período fijo de tiempo hacia atrás
 Archivar en cinta u otro medio de respaldo toda la historia
El primer método no es para nada recomendable dado que los logs son una de las principales
herramientas para determinar la causa de un malfuncionamiento y para detectar algún acceso
no autorizado al sistema. La política de borrar los archivos de log cada vez que toman un
tamaño que los hace molestos, si bien en la mayoría de los casos nos permite disponer de
información, no nos garantiza disponer de los registros de un tiempo hacia atrás. Por otra parte
si el tamaño de los logs crece excesivamente puede hacerse inmanejable extraer de ellos
información o incluso pueden llegar a llenar el disco.
Rotación de archivos de log
La práctica más usual consiste en ir "rotando" los nombres de archivo diariamente o

semanalmente, de manera de ir descartando los archivos más antiguos y mantener información
de una cantidad fija de días anteriores. Un ejemplo elemental de un script que se podría lanzar
desde cron para realizar esto es el que sigue:
#!/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.
15.2 Bitácoras del sistema

Dado que no existe un lugar fijo en el cual se creen los archivos de log, enfrentados a un
sistema Unix que no conocemos no siempre es sencillo encontrarlos. Se enumeran a
continuación las situaciones más frecuentes.
Una buena parte de los programas manejan sus logs utilizando syslogd.
A otros programas se les especifica con parámetros en la línea de comando donde dejar los
logs que generen durante su funcionamiento. En otros casos esto es una opción de
compilación.
Algunos sistemas como OSF/1 y AIX almacenan los errores del sistema en archivos binarios y
proveen alguna herramienta para listarlos (comando uerf en OSF/1). En general estos
comandos aceptan alguna opción para filtrar u ordenar los mensajes con algún criterio.
¿Cómo averiguar dónde están los logs entonces?
en el archivo /etc/syslog.conf para ver donde se almacenan los mensajes reportados a
syslogd.
en los scripts de arranque para ver cómo son invocados los daemons que almacenan
directamente los mensajes en archivos propios.
en el man de los programas para ver donde almacenan los logs cuando no es esto una
opción de línea de comando.
Algunos de los lugares más usuales son:
/var/log
/var/adm o /usr/adm
/var/<nombre_de_daemon>/log
/var/spool/<nombre_de_daemon>/log
Algunos archivos importantes
wtmp y el comando who

Para cada usuario del sistema Unix mantiene un registro en los archivos utmp y lastlog que
indica entre otra información si está logueado en el sistema o no, y en caso afirmativo en cuál
terminal y desde que fecha/hora. Estos archivos son actualizados en cada login y logout y
consultados por ejemplo por los comandos w, who y lastlog.
En cada login y logout además de actualizarse el registro del usuario en el archivo utmp, se
hace un append del mismo en un archivo llamado wtmp. Este archivo entonces es un registro
histórico de los login y logout al sistema. Va creciendo con cada login y logout por lo que debe
ser administrado con alguna de las políticas vistas.
El archivo está en formato binario, pero puede observarse con el comando who. Este comando
por defecto despliega los usuarios logueados al sistema consultando al archivo utmp, pero se le
puede pasar como parámetro el nombre del archivo wtmp y en ese caso nos va a listar la
secuencia de login y logout.
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:
kill -1 `/bin/cat /etc/syslog.pid`

Configuración de syslogd
La configuración de syslogd se hace a través del archivo de texto /etc/syslogd.conf. A través de
este archivo se especifica hacia dónde se deben enrutar los diferentes mensajes. Se pueden
dejar líneas en blanco o comentar líneas enteras con el carácter "#" como primer carácter no
blanco. Cada línea tiene el siguiente formato:
selector <Tab> action
La acción especificada se aplicará a todos los mensajes que verifiquen las condiciones que se
especifican con el selector. En algunos sistemas solamente puede utilizarse tabuladores como
separador entre el selector y la acción, generándose un error muy difícil de descubrir si al editar
el archivo syslog.conf se insertan espacios en lugar de tabuladores.
El selector se especifica como un par facility.level. Cuando un programa envía un mensaje al
syslog, lo hace especificando un valor de "facility" y un valor de "level".
El campo facility procura identificar al programa que originó el mensaje, mientras que el campo
level busca clasificar el nivel de importancia o severidad del mismo.
Los valores posibles de facility están prefijados en cada sistema. Básicamente permiten
identificar mensajes del kernel, de varios de los deaemons y servicios de mayor prosapia en
Unix (mail, daemon, lpr, news, uucp, cron, syslog, ftp), mensajes que tienen que ver con
seguridad y autenticación de usuarios y una serie de valores que pueden ser usados con cierta
libertad para diferentes aplicaciones (local0 a local7, user).
Los valores posibles de level son en general 8 y van en orden de severidad creciente desde
DEBUG hasta EMERG. La acción especificada se aplica a todos los mensajes del nivel
especificado o mayor.
Se puede combinar varios selectores en una línea separándolos por el carácter punto y coma
(";").
Se pueden especificar varias facilities para un mismo nivel separándolas con el carácter coma
(",").
La clave especial "*" puede utilizarse para especificar todos los niveles o todas las facilities
(excepto la facility "mark").
La clave especial "none" en el campo level puede especificarse para excluir todos los niveles de
una cierta facility al combinar varios selectores.
La facility "mark" recibe mensajes a intervalos de 20 minutos. Esto permite, en caso que el
sistema se "cuelgue", determinar de manera bastante precisa la hora a la que sucedió el
problema aunque esto haya sido a una hora de baja actividad en el syslog.
La acción puede ser una de las siguientes:
guardar en un archivo. Es la acción más habitual. El archivo debe estar creado de
antemano. Se especifica simplemente escribiendo el nombre del archivo con su path
completo.
reenviar hacia el syslogd de otra máquina. Se especifica escribiendo @<nombre de
máquina o dirección IP>. El nombre de la máquina origen se agrega al comienzo del
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:
# Log daemon messages at debug level only

daemon.=debug /var/log/daemon.debug
Limitaciones y depuración de errores
Luego de realizar alguna modificación en el archivo syslog.conf y de enviar una señal HUP a
syslogd para que relea la configuración, debe testearse el funcionamiento enviando mensajes
de test con el comando logger.
Un error común es olvidar enviar la señal HUP. Otro error bastante común cuando la acción es
guardar los mensajes en un archivo es no crear el archivo previamente. Si el archivo destino no
está creado syslogd no lo crea.
En la mayoría de las implementaciones de sylog solamente se aceptan tabuladores como
separador entre el selector y la acción. Algunas versiones más nuevas permiten indistintamente
espacios y tabuladores.
Algunas versiones de syslog tienen limitado la cantidad de acciones a especificar en syslog.conf
a un valor constante fijo NLOGS que usualmente era 20. En otras versiones hay una limitación
en la cantidad de usuarios a los que es posible reenviar los mensajes a la consola.
Una herramienta bastante potente para depurar errores en la configuración de syslog es
ejecutarlo en modo debug con el flag -d (syslog -d). Ejecutado de este modo syslog despliega
una tabla con una columna por cada facility y un renglón por cada acción. Los números en la
tabla indican a partir de cual nivel se aplica la acción para cada facility. En el ejemplo se
muestran 4 acciones diferentes (desplegar en la consola, almacenar en el archivo /var/cron/log,
reenviar a la máquina de nombre ohm, desplegar en el terminal en que esté logueado el usuario
root). En los sistemas que tienen limitado a NLOGS la cantidad de acciones, la tabla tiene
NLOGS renglones y aparecen los últimos con la acción UNUSED.
7 3 2 3 5 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 X X CONSOLE: /dev/console
X X X X X X X X X 8 X X X X X X X X X X X X X X X FILE: /var/cron/log
X X X X X X X X X X X X X X X X X X X X X X X 8 X FORW: ohm
3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 X USERS: root,
Cuando se ejecuta en modo debug syslogd no libera el terminal. Después de desplegar la tabla
con el resumen de acciones queda desplegando en pantalla cada mensaje que recibe y las
acciones que se le aplican.Una precaución a tener cuando se envían mensajes a la consola es
que si alguien presiona la tecla de pausa del terminal (habitualmente <Control-S>), entonces
cada intento de syslog de sacar un mensaje en consola queda bloqueado. Esto por lo general
produce el efecto de alentar violentamente el funcionamiento de la máquina, situación que se
revierte si desbloqueamos el terminal con <Control-Q>.
15 .3 Carga del sistema

Comando ps (process status)
La herramienta básica para diagnosticar problemas relacionados con procesos es el comando
ps. Este comando genera un reporte de un renglón por cada proceso, brindando abundante
información sobre cada uno.
El comando ps en los dos sabores básicos de Unix (BSD y System V) difiere en el nombre y
función de los parámetros, en la información que brindan sobre cada proceso y en los criterios
de ordenación de los procesos.
En ambos casos si ejecuto ps sin parámetros solamente se listará información básica sobre los
procesos que pertenecen a mi usuario. A través del uso de parámetros adecuados puedo
agregar más columnas (más información sobre cada proceso) o más filas (más procesos) al
reporte. Un conjunto de parámetros que permite ver todos los procesos con un grado de detalle
que en general es adecuado es:
ps -uax (BSD)
ps -elf (System V)
Los campos de información más importantes desplegados por ps para cada proceso son:
 Usuario (USER)
 * Identificadores de proceso (PID, PPID)
 * Uso de recursos reciente y acumulado (%CPU, %MEM, TIME)
 * Estado del proceso (STAT, S)
 * comando invocado (COMMAND)
Comando top
El comando top actualiza un reporte similar al generado por ps a intervalos periódicos.
Normalmente top ordena los procesos por uso de CPU en forma decreciente. Permite además
de manera amigable invocar los comandos kill y renice sobre el proceso.
Comando pstree
En algunos sistemas está disponible el comando pstree, que lista los procesos y sus
descendientes en forma de árbol. Esto permite visualizar rápidamente los procesos que están
corriendo en el sistema.
Carga del sistema reportada por w o uptime
Los comandos w (who) y uptime reportan tres números que indican la carga promedio del
sistema en un intervalo de 1, 5 y 15 minutos respectivamente. Más precisamente el parámetro
reportado es el promedio de la cantidad de procesos listos para correr. Este valor es un
indicador rápido de la actividad del sistema y suele vigilarse para detectar sobrecargas en el
mismo, o registrarse periódicamente para un análisis posterior en caso de problemas. La
relación entre este número y que tan "pesado" se vuelve el sistema para los usuarios varía
fuertemente dependiendo de las características del sistema (de la cantidad de procesadores p.

ej.) y de los procesos que se están ejecutando.
Comando vmstat (virtual memory stats)
El comando vmstat reporta varias estadísticas que mantiene el kernel sobre los procesos, la
memoria y otros recursos del sistema. Se puede tomar una instantánea de esas estadísticas o
repetirlo cierta cantidad de veces a intervalos de algunos segundos.
Alguna de la información reportada por vmstat es la siguiente:
 Cantidad de procesos en diferentes estados (listo para correr, bloqueado, "swapeado" a
disco.
* Valores totales de memoria asignada a procesos y libre.
 Estadísticas sobre paginado de memoria (page faults, paginas llevadas o traídas a disco,
páginas liberadas)
 Operaciones de disco
 Uso de CPU reciente clasificado en inactivo, ejecutando en modo usuario y ejecutando
en modo kernel
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
 Brian W Kernighan & Rob Pike. El entorno de programación UNIX.

Prentice Hal Hispanoamericana, México, 1987
 Aeleen FRISCO. Essential System Administration.

O’Reilly & Associates, Inc., USA, 1995
 Janice Winsor. SOLARIS Operating System Administrator’s Guide. Cuarta edición,

SUN Microsystems Press, USA 2003
Referencias
 Comando man de UNIX; comando info de GNU.
 Manuales de Operación y Administración de las diferentes variedades de UNIX.

 http://iie.fing.edu.uy/ense/asign/admunix/espdisco.htm

Administración de Sistemas Unix

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Administración de Sistemas Unix

Enviado por

Direitos autorais:

Formatos disponíveis

N OTA S PA R A E L C U R S O

Sist emas UNIX

Dirección General de Servicios de Cómputo Académico

3. ATRIBUTOS DE LOS ARCHIVOS ............................................................................ 11

5. COMANDOS BÁSICOS DE RED .............................................................................. 25

7. GENERALIDADES DE SHELLS ............................................................................... 35

8. PERFIL Y ACTIVIDADES DEL ADMINISTRADOR ................................................... 45

9. ALTA Y BAJA DEL SISTEMA.................................................................................... 64

10. MANTENIMIENTO DE CLAVES DE USUARIOS .................................................... 73

11. INSTALACIÓN Y MANTENIMIENTO DE DISPOSITIVOS ....................................... 84

12. CONFIGURACIÓN Y MANTENIMIENTO DEL USO DE LA RED ......................... 113

13. ADMINISTRACIÓN DEL ÁREA DE SWAP ........................................................... 134

14. ADMINISTRACIÓN DE PROCESOS .................................................................... 137

15. MONITOREO DEL SISTEMA................................................................................ 139

1. INICIAR UNA SESIÓ N

1.1 Elementos básicos de la cuenta de un usuario

1.2 Ini cio de una sesión de escritori o

1.3 Cambi o de contraseña

1.4 Para fi nalizar la sesión

2.1 Comandos, opciones y argumentos

2.2 Comandos bási cos

comando1 argumentos ; comando2 argumentos ; comando3 argumentos

2.2.3 comodines o metacaracteres

La construcción de expresiones regulares depende de la asignación de significado especial a

El conjunto de metacaracteres para expresiones regulares es el siguiente:

cp [OPCIONES] ARCH_ORIGEN ARCH_DESTINO

mkdir [OPCIONES] [-m MODO] DIRECTORIO ...

2.2.7 rm, rmdir

rm [OPCIONES] NOMBRE ...

more [OPCIONES][-N][+/CADENA[-N] [ARCHIVO ...]

+/cadena busca la cadena antes de mostrar

cat [OPCIONES] [ARCHIVO ...]

muestra sucesivamente los archivos cap1, cap2 y cap3.

date [OPCION] [+FORMATO]

'%d' día del mes (01-31)

touch [OPCIONES] ARCHIVO ...

3. ATRIBUTOS DE LOS ARC HIVOS

3.1 Ti pos de archi vos

♦ Archivos de enlace simbólico:

3.2 Comandos para conocer y cambiar sus atributos

3.2.1 ls y sus opciones

3.2.2 ln y sus opciones

ln [OPCIONES] ORIGEN [DESTINO]

3.4 Ru tas absolutas y rutas rel ativas

El carácter/ separa directorios incluídos como parte de un nombre de archivo o directorio.

vi arch1 arranca en modo comando editando el archivo arch1

i inserta texto a la izquierda del cursor

a agrega texto a la derecha del cursor

ESC vuelve a modo comando

x borra el carácter bajo el cursor

dd borra una línea

h o flecha izquierda mueve el cursor un carácter a la izquierda

j o flecha abajo mueve el cursor una línea hacia abajo

k o flecha arriba mueve el cursor una línea hacia arriba

l o flecha derecha mueve el cursor un carácter a la derecha

:w salva el archivo (graba en disco)

:q sale del editor (debe salvarse primero)

vi abre la ventana de edición sin abrir ningún archivo.

vi arch1 edita el archivo arch1 si existe; si no, lo crea.

vi arch1 arch2 edita sucesivamente los archivos arch1 y luego arch2.

vi +45 arch1 edita el archivo arch1 posicionando el cursor en la línea 45.

vi +$ arch1 edita el archivo arch1 posicionando el cursor al final del archivo.