administracion unix
TRANSCRIPT
Introducción al Shell
Crear dos archivos de prueba
Comandos en el sistema UNIX
Estructura de Comandos
Expansiones de la línea de comandos
Variables de ambiente
Entrecomillado de argumentos
PS1
Entrada estándar y salida estándar
Fin de flujo
Agregar la salida estándar a un archivo
Error estándar
Interconexión de comandos (entubamiento)
Filtros
Campos y delimitadores
Valores de retorno de los comandos
El operador grave
Secuencias de comandos
Redirección del shell
Fin
Bibliografía y Referencias
El intérprete de comandos o "shell" actúa entre el sistema operativo y el operador.
Provee al usuario una interfaz hacia el sistema operativo. El usuario dialoga con el
intérprete de comandos, y éste transfiere las órdenes al sistema operativo, que las
ejecuta sobre la máquina.
Crear dos archivos de prueba.
Con el comando cat puede crearse un archivo aceptando el teclado como entrada estándar y
direccionando la salida estándar hacia un archivo:
cat >nota
digitar las siguientes líneas, tal cual están, terminando cada línea dando <Enter>; finalizar con
<Ctrl-D>. Digitar con cuidado: una vez pasados al renglón siguiente, no puede volverse atrás
para corregir.
El shell es un intérprete de comandos.
Es también un lenguaje de programación.
Los programas escritos con el shell se llaman scripts.
Digitar <Ctrl-D> para finalizar el ingreso.
cat nota
muestra el contenido digitado.
Crear del mismo modo el archivo LEAME, haciendo
cat > LEAME
con este contenido:
Este es el archivo LEAME.
Recuerde que UNIX diferencia entre mayúsculas y minúsculas.
El archivo LEAME tendrá este contenido.
cat LEAME
para verificar el contenido.
Comandos en el sistema UNIX.
En UNIX, los comandos son programas ejecutables separados. El shell es un intérprete de
comandos: puede expandir y cambiar la manera en que actúan los comandos, admite el uso de
comodines y la interconexión o entubamiento de comandos.
Estructura de comandos.
La estructura general de un comando es la siguiente:
nombre opciones argumentos
nombre es el nombre del comando. Las opciones o banderas controlan la forma en que
actúa el comando; van precedidas por el signo - (menos). Los argumentos son comúnmente
nombres de archivos o nombres de login de usuarios.
pr -l23 nota
pr -l23 LEAME
da formato y muestra el archivo indicado en páginas de 23 líneas de largo para que quepa en la
pantalla.
pr -d -l23 LEAME
muestra el archivo LEAME a doble espacio, largo de página 23.
pr -d -o15 -l23 LEAME
doble espacio, margen izquierdo de 15 espacios, largo de página 23.
pr -l23 nota LEAME | more
muestra los dos archivos uno tras otro, pero los pagina separados.
cat nota LEAME
concatena los archivos; los presenta uno tras otro.
cat nota LEAME | pr -l23
concatena los archivos y luego les da formato a los dos juntos.
Expansiones de la línea de comando.
Los comodines son caracteres que sustituyen cadenas de caracteres.
* secuencia de caracteres cualesquiera, 0 o más.
? caracter cualquiera, uno y uno sólo; debe aparear un caracter.
[...] sustituye los caracteres indicados individualmente.
Variables de ambiente.
Las variables de ambiente son cadenas de caracteres de la forma
nombre=valor
nombre es cualquier cadena de caracteres que no incluya $ ni espacio (\b); valor es cualquier
cadena; puede incluir el espacio si el valor está entre comillas.
MUESTRA="hola chicos"
asigna "hola chicos" a la variable MUESTRA.
echo $MUESTRA
muestra en pantalla el contenido de la variable MUESTRA. Para exhibir el contenido de una
variable de ambiente se escribe echo $nombre-variable. En general, para hacer uso del
contenido de una variable, se escribe $nombre-variable.
Es una costumbre muy arraigada en UNIX usar mayúsculas para los nombres de variable, así
como es una regla usar minúsculas para los comandos. Las opciones pueden ser mayúsculas y
minúsculas; la opción -a no es lo mismo que -A.
Las variables de ambiente pueden ser usadas como nombres de comando o como argumentos
de un comando.
XYZ="cat nota"
$XYZ
la variable XYZ contiene un comando, y al ser invocado su contenido, el comando es ejecutado.
echo hola $MUESTRA chicos
la variable puede usarse en la formación de cadenas.
echo hola${MUESTRA}chicos
la variable puede embeberse en una cadena; las llaves delimitan el nombre de la variable.
env
muestra las variables de ambiente definidas. Muchas son fijadas en el ingreso del usuario al
sistema (variables de login); y otras son propias del shell (variables del shell).
echo $LOGNAME
muestra el nombre de login del usuario.
echo $HOSTNAME
muestra el nombre de la máquina.
echo $NOEXISTE
Las variables no definidas no muestran nada cuando son referenciadas.
Entrecomillado de argumentos en la línea de comandos.
Los espacios separan argumentos. El entrecomillado obliga a tratar una cadena con espacios
como si fuera un solo argumento. Cuando se usan comillas dobles (" ") el shell interpreta las
variables de ambiente incluídas, actuando según su contenido:
MUESTRA="Mi nombre de login es $LOGNAME"
echo $MUESTRA
Cuando se usan comillas simples (' ') el shell no interpreta las variables de ambiente,
tratando sus nombres como cadenas:
MUESTRA='La variable $LOGNAME contiene su nombre de login'
echo $MUESTRA
Las comillas simples permiten usar comillas dobles:
echo '"hola chicos"'
PS1.
Aunque generalmente los omitimos, en los ejemplos de esta sección mostraremos el indicador
de comandos y la salida de ejecución.
La variable símbolo de indicador de comandos nivel 1 PS1 (Prompt Symbol level 1) es
un valor de ambiente que puede no aparecer en la salida de env:
$ echo $PS1
$
responde con el indicador de comandos actual, $.
$ PS1=hola:
hola:
carga un nuevo indicador de comandos; el sistema responde con el nuevo indicador de
comandos, hola:.
hola: MUESTRA="ingrese comando:"
hola: PS1=$MUESTRA
ingrese comando: MUESTRA=hola
ingrese comando: echo $MUESTRA
hola
ingrese comando:
la variable MUESTRA cambió pero el indicador no cambió;
ingrese comando: PS1='$'
$
repone el indicador de comandos.
Entrada estándar y salida estándar.
Los comandos leen como entrada una secuencia de caracteres (flujo de entrada o "input
stream"), y escriben a la salida otra secuencia de caracteres (flujo de salida o "output stream").
Estas secuencias no tienen estructura interna alguna, y se les llama entrada estándar y salida
estándar.
cat nota > nota2
redirige la salida estándar a un archivo que crea o sobreescribe, en vez de a la pantalla.
mail juan < nota
toma la entrada estándar de un archivo en vez del teclado.
pr < nota > nueva.nota
el archivo nota es la entrada, el archivo nueva.nota es la salida.
cat nueva.nota
muestra el archivo donde se grabó la salida con formato.
Los símbolos < y > redirigen entrada y salida estándar:
< nombre_entrada redirige la entrada estándar
> nombre_salida redirige la salida estándar
MUESTRA=/etc/passwd
pr < $MUESTRA > lista.usuarios
more lista.usuarios
Los comandos y los archivos tienen una estructura orientada a caracter. En muchos comandos
se puede intercambiar teclado por archivos o dispositivos de hardware.
cat nota
cat < nota
son comandos equivalentes porque cat opera sobre un archivo y también sobre la entrada
estándar.
cat nota LEAME nueva.nota
cat nota - nueva.nota < LEAME
son comandos equivalentes. El signo menos (-) aislado equivale a tomar en ese punto la
entrada estándar, que usualmente está asignada al teclado.
Fin de flujo.
El ingreso de datos desde el teclado, así como el despliegue en pantalla, se manejan en UNIX
como "flujos de caracteres", una serie de caracteres uno tras otro. Para indicar en el teclado el
fin de un flujo de caracteres se usa Ctrl-D. Este símbolo no forma parte del ingreso;
simplemente indica el final del ingreso, que ya no se escribirá más. En UNIX no hay un caracter
especial para indicar fin de archivo; el sistema sabe cuando termina un archivo por medio de
contadores.
cat nota - nueva.nota > arch.salida
procesa el archivo nota, lee lo que se digite en el teclado hasta recibir un Ctrl-D, procesa
nueva.copia y escribe todo en el archivo arch.salida; se reúnen tres fuentes distintas en una
única salida.
cat arch.salida
muestra todo lo reunido.
Agregar la salida estándar a un archivo.
cat < nota > nota.copia
cat nota nota.copia > doble.nota
rm nota.copia
doble.nota contiene nota dos veces. Se logra lo mismo con
cat nota > dup.nota
cat nota >> dup.nota
El símbolo >> redirige la salida estándar a un archivo, pero agregando al final del mismo en
lugar de reemplazar su contenido.
Error estándar.
Además de los flujos de entrada y salida estándar, existe un tercer flujo de caracteres, el error
estándar, hacia donde se dirigen los mensajes de error. El error estándar está dirigido
habitualmente a la pantalla, pero mediante 2> o 2>> se redirige el error estándar hacia un
archivo de errores. Los flujos estándar se reconocen por los siguientes números:
0 la entrada estándar, usualmente el teclado;
1 la salida estándar, usualmente la pantalla;
2 el error estándar, usualmente la pantalla.
echo Archivo de errores > salida.error
cat noexiste 2>>salida.error
cat salida.error
el archivo salida.error contiene el mensaje inicial y el de error.
ls noexiste 2>>salida.error
rm noexiste 2>>salida.error
cat salida.error
reúne los mensajes de error en el archivo salida.error .
Interconexión de comandos (entubamiento).
El operador | hace que la salida del comando precedente sea la entrada del comando
siguiente, creando un entubamiento o interconexión de comandos.
cat nota LEAME | pr > salida
hace que la concatenacion de los archivos nota y LEAME sea servida al comando pr, cuya
salida está redirigida a un archivo.
cat - LEAME < nota | pr > salida
tiene el mismo efecto. Notar la posicion de redireccion <.
Los operadores < y > redirigen, | conecta comandos.
Filtros.
Muchos comandos están pensados para ser interconectados, pasando simplemente la entrada
hacia la salida, por lo que se les llama habitualmente filtros.
echo 'hola chicos' | tr l p
tr traduce caracteres y produce 'hopa chicos'.
echo 'hola chicos' | tr lo pa
produce 'hapa chicas'.
Campos y delimitadores.
Un campo es una cadena de caracteres separada por un caracter delimitador. El archivo
/etc/passwd tiene en cada línea una serie de campos separados por dos puntos (:) .
more /etc/passwd
muestra el contenido de /etc/passwd.
cut -f1 -d: < /etc/passwd
cut -f1,3,5 -d: < /etc/passwd
muestra los campos pedidos usando el delimitador : (dos puntos).
cut -c1-8 < /etc/passwd
muestra columnas 1 a 8.
ls -l | cut -c56-
corta el listado de archivos desde donde empieza el nombre al final.
sort < /etc/passwd | cut -f1 -d: | more
ordena las líneas, corta el primer campo y presenta los nombres de usuarios habilitados en el
sistema.
env | cut -f1 -d= | sort
muestra nombres de variables de ambiente ordenadas; el separador es =.
Valores de retorno de los comandos.
Los comandos devuelven un código de retorno 0 si el comando termina correctamente, o un
número entre 1 y 255 según la razón de falla. El código de retorno del último comando queda
en una variable llamada '?', que se interroga como $?.
cat noexiste
ERROR=$?
echo $?
echo $ERROR
guarda el código de error; la asignación termina bien, por lo que en $? queda 0, pero en ERROR
quedó el número de error de la operación fallida. $? es una 'variable de shell' mantenida
internamente por el propio intérprete. Otras variables de shell son:
# número de argumentos en el comando para la shell actual
$ número de proceso para el shell actual
Estas variables se interrogan como $# y $$.
El operador grave.
El acento grave (`) asigna a una variable de ambiente la salida estándar de un comando. El
largo de la variable es limitado, pero usualmente > 5120 en SVR4.
MUESTRA=`echo $LOGNAME`
echo $MUESTRA
escribe el nombre de login del usuario.
wc /etc/passw
cuenta líneas, palabras y caracteres.
El comando wc (word count) acepta opciones -l para líneas, -w para palabras y -c para
caracteres.
TOTALPALABRAS=`cat * | wc -w`
echo $TOTALPALABRAS
cuenta las palabras en todos los archivos del directorio. También
echo `cat * | wc -w`
echo Total de palabras en el directorio: `cat * | wc -w`
El acento grave permite ejecutar un comando dentro de otro, encerrando el comando anidado
entre acentos graves.
Secuencias de comandos.
El shell es también un lenguaje de programación. Pueden escribirse varios comandos en una
misma línea separándolos con ; (punto y coma).
date ; echo Hola ; echo $LOGNAME
MUESTRA=`date ; echo Hola ; echo $LOGNAME`;echo $MUESTRA
Redirección del shell.
El shell que atiende los comandos del usuario es el login shell; arranca cuando el usuario
ingresa al sistema y termina cuando sale. Escribir sh como comando invoca una segunda
instancia del shell, que puede terminarse con el comando exit o con <Ctrl-D>.
Puede crearse un archivo de comandos haciendo
cat > datos.usuario
y escribiendo las siguientes líneas. Pueden omitirse los comentarios (de # en adelante)
echo Salida del comando datos.usuario
echo Fecha: `date ` # fecha y hora
echo Usuario: $LOGNAME # nombre de login del usuario
ps # procesos corriendo del usuario
echo Shell actual: $$ # número de proceso para el shell actual
finalizar con <Ctrl-D>. Los # indican comentario.
Para convertir el archivo en ejecutable para el usuario, hacer
chmod u+x datos.usuario
Verificar con ls -l. Los comandos ingresados en el archivo pueden ejecutarse con
sh datos.usuario
Este comando invoca una nueva instancia de shell que no es la del ingreso al sistema.
Agregar una línea más haciendo
cat datos.usuario - >> masdatos.usuario
y escribiendo
cat noexiste # intenta mostrar un archivo inexistente
Finalizar con <Ctrl-D>.
echo "Archivo de errores del usuario" > errores.usuario
coloca una línea descriptiva en el archivo errores.usuario.
cat errores.usuario
verifica su contenido.
sh <masdatos.usuario >salida.usuario 2>>errores.usuario
lee los comandos del archivo masdatos.usuario en la entrada estándar, redirige la salida
estándar al archivo salida.usuario y redirige la salida del error estándar al archivo
errores.usuario.
cat salida.usuario
cat errores.usuario
Fin.
Borrar con el comando rm los archivos auxiliares; conservar para referencia los archivos nota,
LEAME, datos.usuario , masdatos.usuario y eventualmente otros que le interesen.
UNIX y C
El sistema operativo UNIX suele venir acompañado de un compilador para lenguaje C.
Escribiendo programas en lenguaje C es posible crear comandos indistinguibles de los
propios de UNIX. Como ejemplo, puede crearse el siguiente archivo, usando un editor
de texto sencillo como el ae, o el comando cat si se tiene fé en la propia digitación.
Contenido del archivo hola.c:
/* hola.c: programa de saludo */ #include <stdio.h> main() { printf("Hola, mundo\n"); }
Compilar el contenido de este archivo con el comando cc hola.c -o hola
Esto crea el archivo de salida hola, ejecutable en UNIX mediante el comando ./hola Imprime, como es de suponer, la frase "Hola mundo".
Un ejemplo más interesante, con uso de llamadas a la biblioteca del sistema, es el
ejemplo siguiente, una versión muy mínima del comando cat, que llamaremos cati.
Contenido del archivo cati.c:
/* cati: cat versión mínima */ # define LARGO 1024 /* define valor de variable LARGO */
main() { char bufer[LARGO]; /* declara un arreglo de caracteres */ int n; /* para contar caracteres leídos */
/* llamada al sistema para leer caracteres desde la entrada estándar (0), hacia el arreglo bufer, en cantidad igual al tamaño del arreglo bufer */ n = read(0, bufer, sizeof bufer); /* primera lectura */
/* repite mientras haya caracteres leídos, es decir, n>0 */ while (n > 0) { /* llamada al sistema para escribir caracteres en salida estándar (1), en cantidad n, extrayendo desde arreglo bufer */ write(1, bufer, n);
n = read(0, bufer, sizeof bufer); /* siguientes lecturas */ }
exit(0); /* sale devolviendo c¢digo de retorno 0 */ }
Los extensos comentarios explican el funcionamiento. Compilar este programa con el
comando cc cati.c -o cati
Esto crea el archivo de salida cati, ejecutable en UNIX. El comando ./cati <hola.c
muestra el contenido del programa hola.c. Esta versión mínima sólo funciona
redireccionando la entrada estándar. Puede probarse su funcionamiento ingresando
datos desde el teclado, finalizando con Ctrl-D. El programa puede interrumpirse con
Ctrl-C. ¿Qué diferencia hay?
Es un problema de programación algo más complejo asimilar un nombre de archivo
como parámetro y hacer que el programa despliegue el contenido de este archivo.
La razón por la que estos programa se invocan como ./hola y no simplemente hola es
que el directorio actual no está habitualmente en la vía de búsqueda de ejecutables
(variable PATH). Colocando las versiones ejecutables de los programas hola o cati en
un directorio como /bin los haría ejecutables directamente como cualquier comando de
UNIX.
Estos ejemplos muestran la versatilidad de UNIX como sistema operativo: puede uno
ampliarlo con comandos construídos por uno mismo que se integran perfectamente a los
comandos propios del sistema. En las distribuciones de UNIX de dominio público
suelen venir los fuentes en C de todos los comandos, lo cual permite, al usuario con
conocimento suficiente, modificar o corregir estos programas.
Sistema de Archivos Archivos
Directorios
Nombres de Archivo
Directorio Propio. Directorio Actual
Nombres de Directorio
Cambios de directorio
Estructura Interna de los Archivos
Propiedades de los archivos
Tipo y Permisos de achivos
El sistema de archivos en UNIX
Preguntas y Ejercicios
Bibliografía
El sistema UNIX funciona totalmente en base a archivos. Los programas, los datos, los
directorios y aún los controladores de dispositivos tales como discos, modems e
impresoras, son archivos.
El sistema de archivos de UNIX se organiza en una jerarquía de directorios que resulta
en una estructura arborescente.
Archivos.
Cada archivo tiene asociado un nombre, un contenido, un lugar de ubicación e información de
tipo administrativo, tal como dueño y tamaño. El contenido de un archivo puede ser texto,
programas fuente, programas ejecutables, imágenes, sonidos y otros.
Estructuralmente un archivo es una secuencia de bytes de datos que reside en forma
semipermanente en algún medio estable, como ser una cinta magnética o un disco.
Directorios.
Los archivos se agrupan en directorios. Un directorio es un archivo que contiene una lista de
nombres de archivo e información acerca de los mismos. Dentro del sistema de archivos, un
directorio es una localización capaz de contener otros directorios o archivos. Dos archivos que
se encuentren en distinto directorio pueden tener el mismo nombre sin confundirse.
El comando ls permite listar el contenido de un directorio:
ls /var
el argumento es un directorio; la salida son los nombres de archivos y subdirectorios en ese
directorio.
ls nota
el argumento es un archivo, la salida es el nombre del archivo.
ls -l /var
muestra los archivos y subdirectorios contenidos en /var en formato largo.
ls -ld /var
muestra características del directorio /var en lugar de los archivos y subdirectorios
contenidos en él.
Nombres de archivos.
Para el nombre de archivo se puede usar prácticamente cualquier caracter, incluso caracteres
no visibles. Los caracteres $ ; \ & ! * | causan confusión y no conviene usarlos. Se
aconseja usar solamente letras, números, punto, guión y subraya. UNIX diferencia mayúsculas
y minúsculas: el archivo NOTA.TXT es distinto del archivo nota.txt y también de Nota.txt.
No se distingue entre nombre de archivo y extensión: nota.nueva.txt es un nombre de
archivo válido, y LCK..modem también.
Un archivo que comienza por un punto no es visible:
touch .noseve
ls
ls -a
ls no lo muestra, pero sí ls -a.
rm .noseve
lo borra como a cualquier archivo.
Directorio propio. Directorio actual.
Al ingresar al sistema cada usuario entra en su directorio propio, un directorio privado que no
es tocado por el sistema ni por los otros usuarios. El directorio en el cual se encuentra
posicionado el usuario en un momento dado se denomina su directorio actual.
cd /usr/bin
pwd
cambia al directorio /usr/bin; el directorio actual es /usr/bin.
cd
pwd
devuelve al usuario a su directorio propio, que es ahora el directorio actual.
echo $HOME
nuestra el nombre del directorio propio. HOME es una variable de ambiente que contiene el
nombre del directorio propio del usuario.
cd $HOME
tiene el mismo efecto que cd.
Nombres de directorios.
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 /
pwd
el directorio actual es el directorio raíz.
cd
vuelve al directorio propio del usuario.
El caracter / 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, nota es el nombre del archivo. 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
El caracter / 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 para referenciar directorios y archivos:
cat /home/esteban/*/*
Cambios en la jerarquía de directorios.
mkdir nuevo.dir
crea un nuevo directorio.
rmdir nuevo.dir
borra un directorio existente; actúa sólo sobre directorios vacíos.
mkdir dir1
mkdir dir1/dir2
touch dir1/dir2/arch2 dir1/arch1
ls -lR
muestra todos los archivos y directorios creados;
rm -r dir1
borra el directorio y todos los archivos y subdirectorios que pueda contener.
Estructura interna de los archivos.
Un archivo es una secuencia de bytes. Un byte es equivalente a un caracter. El sistema no
impone estructura alguna a los archivos ni asigna significado a su contenido; el significado de
los bytes depende totalmente de los programas que interpretan el archivo.
En ningún caso hay ningún byte que no haya sido colocado por el usuario o un
programa. No hay caracter de fin de archivo. El núcleo del sistema UNIX se mantiene al
tanto del tamaño de los archivos sin introducir ningún caracter especial. El caracter
nuevalínea es interpretado por las terminales como nueva línea y retorno de carro (CR
LF, carriage-return y line-feed), necesario para desplegar correctamente los renglones
en la terminal. Al apretar la tecla Enter el núcleo transmite a la terminal CR LF, pero en
un archivo se guarda sólo LF.
¿Qué hay dentro de un archivo? El núcleo no puede decirnos nada del tipo de archivo:
no lo conoce. Todos los archivos tienen la misma estructura interna. El comando file
hace una conjetura: lee algunos bytes y busca indicios sobre el tipo de contenido. En los
sistemas UNIX hay sólo una clase de archivo. Lo único que se requiere para accederlo
es su nombre.
Propiedad de los archivos.
Cada usuario es dueño de los archivos creados por él, hasta que los borre o los ceda a otro
usuario. Cada usuario pertenece a un grupo, y puede compartir archivos con los usuarios de
ese grupo. Cada archivo está asignado a un grupo de usuarios, al cual debe pertenecer su
dueño. El comando ls -l muestra dueño y grupo de los archivos listados.
Tipo y permisos de archivos.
Cada archivo tienen un conjunto de permisos asociados con él que determinan qué puede
hacerse con el archivo y quién puede hacerlo.
Los permisos de un archivo se indican con 10 caracteres:
1 caracter para tipo de archivo,
3 caracteres [rwx] para permisos del dueño,
3 caracteres [rwx] para permisos del grupo,
3 caracteres [rwx] para permisos de otros.
Caracter para 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
Caracteres de permisos:
r acceso de lectura (read)
w acceso de escritura (write)
x acceso de ejecución (execute)
cuyo significado varía según se trate de archivos o directorios:
Permiso Archivos Directorios
r leer archivos ver contenido de directorios
w grabar en un archivo crear y borrar archivos
x ejecutar como programa ingresar a un directorio
- sin derechos sin derechos
El ingreso a un directorio (permiso x) permite ejecutar un archivo contenido dentro de
él, o trasladarse a ese directorio; para estas operaciones no es necesario poder ver los
nombres de los archivos contenidos (permiso r).
Un archivo se declara ejecutable dándole permiso de ejecución. Se ejecuta dando su
nombre. Los comandos de UNIX son archivos ejecutables.
Ejemplos de permisos de archivo:
rwxr--r--
rw-rw-r--
rw-------
El sistema de archivos en UNIX.
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.
Como referencia, la distribución Debian/GNU 2.1 viene con cerca de 2500 paquetes para
instalar. Una instalación normal puede insumir un 25% en herramientas de administración, y
un 10 % en herramientas de desarrollo. Borrar, alterar o cambiar permisos de archivos puede
conducir a resultados impredecibles.
$ ls -F /
es útil para recorrer el sistema de archivos, bajando luego a los subdirectorios.
Los requerimientos de las redes cambiaron la organización funcional del sistema de archivos.
En un lugar grande, la red se configura con un conjunto de máquinas heterogéneas, cada una
responsable del mantenimento y uso de cada archivo. Los archivos pueden ser específicos para
cierta máquina, compartidos por varias máquinas del mismo tipo, o accesibles a casi cualquier
tipo de máquina en la red. Enlaces simbólicos hacia la anterior localización de los archivos
ayudan al acceso. Un directorio puede ser real o un enlace simbólico a otro; usar /bin/pwd
para si se ha llegado al directorio directamente o a través de un enlace simbólico.
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
/proc 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
./include 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)
Manejo de Archivos Copia de Archivos
Mover, cambiar de nombre
Enlaces "hard"
Enlaces simbólicos
Opciones del comando ls
Cambio de dueño y grupo
Modos de permisos
Listado de permisos de los directorios
Cambio de permisos
basename, dirname
Archivos de dispositivos
El comando "mesg"
Otros dispositivos
Preguntas y Ejercicios
Bibliografía y Referencias
En los ejemplos siguientes se asume al usuario ubicado en su directorio personal, el cual
contiene los archivos nota y LEAME. El resultado de cada ejemplo debe comprobarse
mediante comandos tales como pwd,ls, cat o more.
Copia de archivos.
cp nota nota.copia
copia el archivo nota en nota.copia. Si el directorio propio del usuario es
/home/usuario1,
cp ./nota /home/usuario1/nota.copia
hace lo mismo indicando las rutas. Si el archivo destino existe lo sobreescribe y realiza la copia
sin comentario ni advertencia.
mkdir dir1
cp nota dir1
si el destino es un directorio, el archivo se copia en ese directorio.
cp nota LEAME dir1
pueden copiarse varios archivos hacia un directorio.
mkdir dir2
touch dir2/arch2 dir2/arch3
ls dir2
cp dir2/* .
copia todos los archivos en dir2 hacia el directorio actual.
Para copiar un directorio es preciso usar la opción -r, de "recursivo":
cp -r dir1 dir3
ls -l dir3
copia el directorio dir1 y todo el contenido en el dir3.
rmdir dir3
fracasa porque dir3 no está vacío.
rm -r dir3
con la opción -r, "recursivo", se puede borrar completamente un directorio y todo su
contenido, sean estos archivos o subdirectorios.
rm -r dir1/* dir2
borra todos los archivos bajo dir1 y dir2; borra también el directorio dir2 pero no el dir1.
rm arch? nota.copia
borra del directorio actual los archivos arch1, arch2, .., y nota.copia.
Mover, cambiar de nombre.
echo "Hola todos" > hola
cat hola
mv hola saludo
cat saludo
mv cambia el nombre del archivo hola por el de saludo.
mv saludo dir1/saludo.1
mueve hacia otro directorio cambiando el nombre.
mv dir1 dirnuevo
cambia de nombre archivos o directorios.
rm -r dirnuevo
elimina dirnuevo y todos sus archivos.
Enlaces "hard".
Un enlace "hard" (hard link) es una nueva referencia a un mismo archivo; consiste en una
nueva entrada de directorio que apunta a un archivo ya existente y apuntado desde otra
entrada de directorio. El contenido se encuentra en un solo lado, pero el archivo puede ser
accedido desde varios lugares, eventualmente con diferentes nombres.
echo 'Hola todos de nuevo!' > adios
ln adios adios.ln0
ln crea un segundo nombre referido al mismo archivo; no se hace copia, crea un enlace (link).
Verificar que
ls -l adios*
muestra un conteo de 2 en la columna de enlaces. Al crear el enlace con el comando ln,
observar que el archivo existente va en primer lugar, luego uno o más nombres de enlaces a
crear.
ln adios adios.ln1
ln adios adios.ln2
ls -l adios*
muestra el conteo de enlaces hard en estos archivos.
mkdir dir2
ln adios dir2/adios
hace aparecer en dir2 un enlace llamado adios hacia el archivo adios del directorio actual.
Un enlace hard puede hacer aparecer un mismo archivo en más de un directorio, con igual o
distinto nombre; el contenido está en un solo lado, no está repetido.
rm adios*
ls -l dir2/adios
Cuando se borra un archivo con varios enlaces, sólo se borra el enlace. El archivo es realmente
borrado sólo cuando desaparece el último enlace.
ln dir2 dir2ln
da error; no se puede crear un enlace hard para un directorio.
Enlaces simbólicos.
Un enlace simbólico (symbolic link) es un archivo que apunta a otro archivo o directorio. El
archivo de enlace simbólico contiene solamente la ruta del otro archivo o directorio.
ln -s nota nota.ls0
crea nota.ls0 como enlace simbólico.
ln -s dir2 dir2ls
crea dir2ls como enlace simbólico hacia un directorio.
ls -l
muestra la letra l en el tipo de archivo para indicar que es un enlace simbólico.
ls dir2
ls dir2ls
muestran el mismo contenido de archivos.
ls -l dir2ls
muestra que es un enlace simbólico e indica hacia donde apunta.
cd dir2ls
ls -l
muestra el contenido de dir2, enlazado desde dir2ls.
pwd
indica el directorio con nombre del enlace, pero
/bin/pwd
muestra el directorio verdadero, no el enlace simbólico; pwd indica la ruta por la que se llegó al
directorio, /bin/pwd indica la ruta de acceso al verdadero directorio. Conviene usar
/bin/pwd para evitar ser engañado por enlaces simbólicos a directorios. El comando pwd es
interno del shell, /bin/pwd es un programa aparte.
cd ..
mv dir2 DIR2
cambia el nombre del directorio real; el enlace simbólico sigue apuntando a dir2, por lo que
cd dir2ls
da error, ya que no existe el objeto real.
mv DIR2 dir2
repone el nombre original al que apunta el enlace.
rmdir dir2ls
da error porque no es un directorio sino un enlace.
rm dir2ls
borra el enlace. Un enlace simbólico se borra con rm, y no con rmdir, puesto que el enlace
simbólico es un archivo y no un directorio, aún cuando sea un enlace simbólico hacia un
directorio.
ls dir2
cuando se borra un enlace simbólico, sólo se borra un archivo puntero, y no el objeto real.
Opciones del comando ls.
ls -1
muestra un item por línea. Cuando ls se usa en interconexiones, la salida de ls presenta un
item por línea por defecto.
ls -C
fuerza el despliegue encolumnado.
ls -a
muestra todos los archivos, incluyendo los que comienzan con punto, normalmente no
mostrados. El directorio corriente . y el directorio padre .. son entidades reales.
ls -F /bin
ls -F
agrega sufijo que indica el tipo de archivo: / directorio, * ejecutable, @ enlace simbólico.
ls -R
muestra recursivamente todos los archivos, subdirectorios y archivos dentro de subdirectorios.
Para ver un listado más largo,
ls -CR /etc | more
ln -s dir2 dir2ls
ln nota nota.ln0
ls -l
listado largo, muestra atributos de los archivos: tipo de archivo (primer caracter), permisos (9
caracteres), enlaces hard (en archivos), dueño, grupo, tamaño en bytes, fecha y hora, nombre.
-rw-r--r-- 1 esteban other 138 Apr 5 19:34 LEAME
drwxr-xr-x 2 esteban other 138 Apr 5 19:34 dir2
lrw-r--r-- 1 esteban other 138 Apr 5 19:34 dir2ls ->./dir2
-rw-rw-rw- 1 esteban other 138 Apr 5 19:34 nota
El símbolo -> indica "apunta hacia" para enlaces simbólicos.
Cambio de dueño y grupo.
chown usuario1 nota
cambia el dueño del archivo nota adjudicándoselo a usuario1.
chown usuario1 arch1 arch2
cambia el dueño de la lista de archivos indicada. No puede revertirse, ya que el usuario actual
dejó de ser dueño de esos archivos. Si el archivo tiene permiso de lectura, es posible copiarlo
para disponer de una copia propia. El cambio de dueño no está permitido a usuarios comunes,
sino reservado al supervisor para evitar que a un usuario se le adjudiquen archivos sin su
consentimiento.
chgrp tecnicos nota
cambia de grupo el archivo notas, adjudicándoselo al grupo tecnicos. El dueño debe
pertenecer al grupo tecnicos.
chgrp tecnicos arch1 arch2
cambia el grupo de la lista de archivos.
Modos de permisos.
Los permisos de archivos y directorios se cambian con el comando chmod. Pueden expresarse
de dos maneras: simbólica y absoluta.
En la forma simbólica, se usa la siguiente sintaxis:
[ugoa...][[+-=][rwxstugo...]
+ agrega permiso a los existentes
- quita permiso de los existentes
= únicos permisos asignados al archivo
r lectura
w escritura
x ejecución, o acceso si es directorio
s usa el id del dueño o grupo del archivo al ejecutar
t fijar "sticky bit" a un directorio: sólo dueños pueden borrar
u usuario (dueño)
g grupo
o otros
a todos (dueño, grupo y otros)
Ejemplos de permisos en notación simbólica:
u+r g+w-r ug+r ugo+w-rx u+rwx,g+r-wx,o-rwx
chmod u+rwx,g+rw-x,o+r-wx arch1
chmod u=rwx,g=rw,o=r arch1
cambian los permisos de los archivos indicados.
En modo absoluto se usa un código de 4 dígitos octales 0..7, en la forma Nnnn.
N, primer dígito:
4 fijar ID del dueño al ejecutar 2 fijar ID del grupo al ejecutar
1 fijar "sticky bit" a un directorio
nnn, 3 dígitos: permisos del usuario, grupo y otros, con el código
4 lectura
2 escritura 1 ejecución, o acceso si es directorio
Ejemplos de permisos en notación absoluta:
0777 0755 0764 0640 0710
chmod 0764 arch1
cambia los permisos como en el ejemplo anterior.
Listado de permisos de los directorios.
ls -l
muestra los permisos y otros atributos.
Para obtener información del directorio dir1 ubicado en el directorio actual,
ls -l
lista todos los archivos, entre los que aparece dir1;
ls -l dir1
lista el contenido del directorio dir1.
ls -ld dir1
trata la entrada dir1 como archivo, sin listar su contenido, y dando sus atributos como
directorio.
ls -ld .
muestra atributos del directorio actual.
Cambio de permisos.
chmod u-w nota
quita permisos de escritura al dueño.
chmod u+w nota
concede permisos de escritura al dueño.
chmod u-w+x nota
chmod u-wx+r nota
cambian varios permisos del dueño al mismo tiempo.
chmod u+w nota
chmod g+w nota
chmod o+w nota
concede permiso de escritura solo al usuario, al grupo o a otros.
chmod u+rw-x,g+r-wx,o+r-wx nota
fija todos los permisos en una sola operación. Los permisos que no se mencionen quedan
como estén.
chmod 0644 nota
realiza lo mismo en notación absoluta.
El comando chmod admite las opciones
-v verboso, describe los permisos cambiados
-f no da error sobre permisos que no pueden cambiarse
-R recursivo, cambia permisos de directorios y sus archivos
chmod -v u+rwx,g+rw-x,o+r-wx arch1
chmod -v 764 arch1
chmod -v 444 arch1
chmod u=rw,go=r arch1
fija permisos en rw-r--r--.
chmod u=rwx,u+s arch1
ejecutará arch1 con permiso del dueño de arch1.
chmod -vR a+r dir1
da permiso de lectura a todos los directorios bajo dir1, anunciando en forma verbosa lo hecho.
chmod ugo+rwx dirtodos
chmod a+t dirtodos
fija "sticky bit": a pesar de tener el directorio permisos totales para todos, sólo pueden
borrarse los archivos propios del usuario, no los ajenos.
chmod 1777 dirtodos
realiza lo mismo.
Los permisos s (setuid, setgid) hacen que un archivo ejecutable ejecute con permisos del
usuario dueño o del grupo dueño del archivo, cualquiera sea el usuario y grupo de quien lo
invoca. El permiso setgid sobre un directorio hace que los archivos y subdirectorios creados en
él pertenezcan al grupo del directorio, y no al grupo primario del usuario, como es normal;
esto es útil para los grupos de trabajo. El permiso t (sticky bit) se aplica a directorios con
permisos totales; limita la operación de borrado al dueño del archivo o subdirectorio. Los
modos S y T, que pueden aparecer en ls -l, indican modos sin sentido: setuid o setgid sobre
archivos no ejecutables, sticky bit sobre directorio sin permisos para todos.
basename, dirname
echo $EDITOR
muestra la variable de ambiente que contiene el nombre del editor por defecto. Si no aparece
nada, inicializarla:
which vi
para obtener la vía hacia el editor vi.
EDITOR=/usr/bin/vi
echo $EDITOR
muestra el nombre del editor a usar por defecto.
MIEDITOR=`basename $EDITOR`
echo "Mi editor es $MIEDITOR"
muestra el nombre del archivo sin ruta; basename quita la ruta a un nombre de archivo
calificado con ruta.
DIREDITOR=`dirname $EDITOR`
dirname separa la ruta del nombre completo.
echo "Mi editor es $MIEDITOR en el directorio $DIREDITOR"
muestra el uso en comandos de variables de ambiente.
echo "Mi editor es "`basename $EDITOR`" en "`dirname $EDITOR`
muestra el uso del operador grave para ejecutar comandos dentro de otros comandos.
Archivos de dispositivos.
El sistema de archivos de UNIX provee una interface estándar entre los dispositivos de
hardware y el sistema operativo que actúa igual que un archivo común: todas las operaciones
de entrada y salida se hacen escribiendo y leyendo sobre un archivo. No se trata de un archivo
común en disco; actúa como una ruta hacia un canal de entrada/salida del hardware. Así como
se redirige la salida de un comando hacia un archivo, puede redirigirse también hacia un disco,
una cinta o un módem con sólo mencionar el nombre del dispositivo correspondiente.
tty
devuelve el nombre del dispositivo asociado al terminal, por ejemplo /dev/tty1. Tomando
ese mismo nombre
ls -l /dev/tty1
obtenemos un listado de atributos del "archivo" controlador de este dispositivo, algo así como
crw-rw-rw- 1 usuario1 otros .... /dev/tty1
El primer caracter indica el tipo de dispositivo: c si es orientado a caracteres, b si es orientado
a bloques. Terminales, impresoras y modems son orientados a caracter, discos y cintas son
orientados a bloque.
cat - < /dev/tty1
para escuchar en la propia sesión de terminal; escribir varias líneas y finalizar con Ctrl-D.
cat - < `tty`
produce el mismo efecto. Luego probar
$ cat - > `tty`
¿puede explicarse el comportamiento?
El comando mesg.
ls -l `tty`
Si otros usuarios pueden leer y escribir en este dispositivo, también pueden ver lo que se está
haciendo o aún escribir directamente en el terminal redirigiendo su salida. Esto se usa en los
comandos wall (write all, escribir a todos) y write (escribir mensajes entre usuarios).
mesg
muestra si está habilitada o no la recepción de mensajes.
mesg y
cambia permisos de grupo y otros en el dispositivo, aceptando mensajes.
mesg n
rechaza mensajes. Verificar con
ls -l `tty`
que muestra los permisos que regulan la terminal del usuario.
ls -l /dev/tty?
muestra los permisos de las terminales principales;
ls -l /dev/tty??
muestra una cantidad de tipos de terminal disponibles.
Otros dispositivos.
cat /etc/passwd
cat /etc/passwd > /dev/null
El dispositivo /dev/null actúa como una papelera de tamaño ilimitado que recibe la salida a
descartar. No guarda nada; lo que allí se envíe se pierde para siempre.
Todos los dispositivos de hardware del sistema tienen una representación en el directorio
/dev.
Expresiones Regulares Expresiones Regulares
Metacaracteres
Expresiones regulares básicas
Expresiones regulares de un sólo caracter
Construcción de expresiones regulares
Ejemplos de expresiones regulares básicas
Expresiones regulares extendidas
Ejemplos de expresiones regulares extendidas
Expresiones Regulares en GNU
Preguntas y Ejercicios
Bibliografía y Referencias
Expresiones Regulares.
La expresiones regulares (ER) son una forma de describir cadenas de caracteres. Se usan en
operaciones de apareamiento o comparación. Las expresiones regulares permiten realizar
búsquedas o sustituciones de gran complejidad.
Las búsquedas en el editor vi con los comandos / y ? aceptan expresiones regulares; esto hace
las búsquedas mucho más potentes y flexibles. Las expresiones regulares son aceptadas en
otros editores y en muchos comandos, si bien con algunas diferencias de sintaxis.
Una expresión regular es un patrón que describe un conjunto de cadenas de caracteres. Por
ejemplo, el patrón aba*.txt describe el conjunto de cadenas de caracteres que comienzan
con aba, contienen cualquier otro grupo de caracteres, luego un punto, y finalmente la cadena
txt. El símbolo * se interpreta como "0, 1 o más caracteres cualesquiera".
Las expresiones regulares se construyen como las expresiones aritméticas, usando operadores
para combinar expresiones más pequeñas. Analizaremos esos operadores y las reglas de
construcción de expresiones regulares, atendiendo siempre al conjunto de cadenas que
representa cada patrón.
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 caracter * no vale por sí mismo, como el
caracter asterisco, sino que indica un "conjunto de caracteres cualesquiera". Asimismo, el
caracter ? no se interpreta como el signo de interrogación sino que representa "un caracter
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 caracter ? representa "un caracter cualquiera"; si escribimos \?,
estamos representando el caracter ? tal cual, sin significado adicional.
Expresiones Regulares Básicas.
Una expresión regular determina un conjunto de cadenas de caracteres. Un miembro de este
conjunto de cadenas se dice que aparea, equipara o satisface la expresión regular.
ERs de un sólo caracter.
Las expresiones regulares se componen de expresiones regulares elementales que aparean
con un único caracter:
Exp.Reg. aparea con
c ER que aparea con el caracter ordinario c
. (punto) ER que aparea con un caracter cualquiera excepto nueva línea
[abc] ER de un caracter que aparea con a, b o c
[^abc] ER de un caracter que no sea a, b o c
[0-9][a-z][A-Z]
ERs de un caracter que aparean con cualquier caracter en el intervalo
indicado. El signo - indica un intervalo de caracteres consecutivos.
\e
ER que aparea con alguno de estos caracteres (en lugar de la e):
. * [ \ cuando no están dentro de [ ]
^ al principio de la ER, o al principio dentro de [ ]
$ al final de una ER
/ usado para delimitar una ER
Los paréntesis rectos [] delimitan listas de caracteres individuales. Muchos
metacaracteres pierden su significado si están dentro de listas: los caracteres especiales
. * [ \ valen por sí dentro de []. Para incluir un caracter ] en una lista, colocarlo al
principio; para incluir un ^ colocarlo en cualquier lugar menos al principio; para incluir
un - colocarlo al final.
Dentro de los conjuntos de caracteres individuales, se reconocen las siguientes
categorías:
[:alnum:] alfanuméricos [:alpha:] alfabéticos [:cntrl:] de control [:digit:] dígitos [:graph:] gráficos [:lower:] minúsculas [:print:] imprimibles [:punct:] de puntuación [:space:] espacios [:upper:] mayúsculas [:xdigit:] dígitos hexadecimales
Por ejemplo, [[:alnum:]] significa [0-9A-Za-z], pero esta última expresión depende
de la secuencia de codificación ASCII, en cambio la primera es portable, no pierde su
significado bajo distintas codificaciones. En los nombres de categorías, los paréntesis
rectos forman parte del nombre de la categoría, no pueden ser omitidos.
Construcción de Expresiones Regulares.
Una Expresión Regular se contruye con uno o más operadores que indican, cada uno, el
caracter a buscar. Los operadores más comunes y aceptados son los siguientes:
Operador Significado
c un caracter no especial concuerda consigo mismo
\c elimina significado especial de un caracter c; el \ escapa el significado especial
^ indica ubicado al comienzo de la línea (cadena nula al principio de línea)
$ indica ubicado al final de la línea (cadena nula al final de línea)
. (punto) un caracter individual cualquiera
[...] uno cualquiera de los caracteres ...; acepta intervalos del tipo a-z, 0-9, A-Z (lista)
[^...] un caracter distinto de ... ; acepta intervalos del tipo a-z, 0-9, A-Z
r* 0, 1 o más ocurrencias de la ER r (repetición)
r1r2 la ER r1 seguida de la ER r2 (concatenación)
Ejemplos de Expresiones Regulares Básicas.
Las expresiones regulares se aprenden mejor con los ejemplos y el uso.
Exp.Reg. aparea con
a.b axb aab abb aSb a#b ...
a..b axxb aaab abbb a4$b ...
[abc] a b c (cadenas de un caracter)
[aA] a A (cadenas de un caracter)
[aA][bB] ab Ab aB AB (cadenas de dos caracteres)
[0123456789] 0 1 2 3 4 5 6 7 8 9
[0-9] 0 1 2 3 4 5 6 7 8 9
[A-Za-z] A B C ... Z a b c ... z
[0-9][0-9][0-9] 000 001 .. 009 010 .. 019 100 .. 999
[0-9]* cadena_vacía 0 1 9 00 99 123 456 999 9999 ...
[0-9][0-9]* 0 1 9 00 99 123 456 999 9999 99999 99999999 ...
^.*$ cualquier línea completa
En el editor vi, las expresiones regulares permiten realizar búsquedas tales como:
/^Desde
busca líneas que empiecen con la cadena Desde
/final$
busca líneas que termine con la cadena final
/\$25
busca líneas que contengan $25; \ escapa el $
Expresiones Regulares Extendidas.
Algunos comandos, como egrep o grep -E, aceptan Expresiones Regulares Extendidas, que
comprenden las Expresiones Regulares Básicas más algunos operadores que permiten
construcciones más complejas. Los operadores incorporados son los siguientes:
Operador Significado
r+ 1 o más ocurrencias de la ER r
r? 0 o una ocurrencia de la ER r, y no más
r{n} n ocurrencias de la ER r
r{n,} n o más ocurrencias de la ER r
r{,m} 0 o a lo sumo m ocurrencias de la ER r
r{n,m} n o más ocurrencias de la ER r, pero a lo sumo m
r1|r2 la ER r1 o la ER r2 (alternativa)
(r) ER anidada
"r" evita que los caracteres de la ER r sean interpretados por el shell
La repetición tiene precedencia sobre la concatenación; la concatenación tiene
precedencia sobre la alternativa. Una expresión puede encerrarse entre paréntesis para
ser evaluada primero.
Ejemplos de Expresiones Regulares Extendidas:
Exp.Reg.Ext. aparea con
[0-9]+ 0 1 9 00 99 123 456 999 9999 99999 99999999 ..
[0-9]? cadena_vacía 0 1 2 .. 9
^a|b a b
(ab)* cadena_vacía ab abab ababab ...
^[0-9]?b b 0b 1b 2b .. 9b
([0-9]+ab)* cadena_vacía 1234ab 9ab9ab9ab 9876543210ab 99ab99ab ...
Expresiones regulares en GNU.
En GNU, no se distinguen expresiones regulares básicas de extendidas; los comandos aceptan
todas las expresiones regulares. En ese caso, como siempre se están usando extendidas, los
metacaracteres ?, +, {, |, (, y ) deben ser escapados cuando se quieren usar como caracteres
normales, escribiendo \?, \+, \{, \|, \(, y \).
Filtros. sort
grep
find
fgrep y egrep
tr
uniq
dd
Preguntas y Ejercicios
Bibliografía y Referencias
Se da el nombe de filtros a un grupo de comandos que leen alguna entrada, realizan una
transformación y escriben una salida. Además de los que veremos aquí, incluye comandos
tales como head, tail, wc, y cut.
sort
La comparación u ordenación puede ser por caracteres ASCII o por valor numérico. La
ordenación ASCII es la más parecida a la alfabética; sigue el orden del juego de caracteres
ASCII. En este ordenamiento, los caracteres idiomáticos (vocales acentuadas, ñ) no se
encuentran en el orden alfabético tradicional. En la ordenación numérica se respeta la
ordenación por valor numérico de la cadena de caracteres: 101 va después de 21; en
ordenamiento ASCII sería al revés.
sort arch1
ordena según el código ASCII.
sort -n arch2.num
ordena numéricamente.
Si no se indican campos de ordenación, la comparación se hace sobre toda la línea. Si se
indican campos, la comparación se hace considerando la cadena de caracteres iniciada en el
primer caracter del primer campo hasta el último caracter del último campo.
sort -t: -k1,3 arch1.txt
ordena por campos separados por ":", tomando en cuenta para la comparación los caracteres
desde el primero del campo 1 hasta el último del campo 3.
sort -t: -k1.3,3.5 arch1.txt
ordena por campos tomando en cuenta desde el 3er. caracter del campo 1 hasta el 5to.
caracter del campo 3.
sort -nr arch2.num
ordena en orden numérico descendente.
sort -k3 arch3.txt
ordena alfabéticamente, usando como cadena de comparación la comprendida desde el
primer caracter del 3er. campo hasta el fin de lína. Como no se indica separador, los campos se
definen por blancos (espacio o tabulador).
find
El comando find explora una rama de directorios buscando archivos que cumplan
determinados criterios. El comando find en GNU es extremadamente potente, permitiendo
criterios de búsqueda tales como:
el nombre contiene cierta cadena de caracteres o aparea con algún patrón: son enlaces a ciertos archivos; fueron usados por última vez en un cierto período de tiempo; tienen un tamaño comprendido dentro de cierto intervalo; son de cierto tipo (regular, directorio, enlace simbólico, etc.); pertenecen a cierto usuario o grupo; tienen ciertos permisos de acceso; contienen texto que aparea con cierto patrón.
Una vez ubicados los archivos, find puede realizar diversas acciones sobre ellos:
ver o editar; guardar sus nombres en otro archivo; eliminarlos o renombrarlos; cambiar sus permisos de acceso; clasificarlos por grupos.
find /var -name *.log -print
busca en el directorio /var los archivos terminados en .log, imprime sus nombres en la salida.
find /tmp -size +200k -print
busca archivos mayores de 200k. En los argumentos numéricos, +N es mayor que N, -N es
menor que N, N es exactamente igual a N.
find /var/spool/mail -atime +30 -print
busca archivos no accedidos hace más de 30 días. La opción -atime se refiere a tiempo
transcurrido desde última lectura, -mtime desde última modificación de estado o permisos, -
ctime de contenido.
find /var/tmp -empty -exec rm {} \;
busca archivos vacíos y los borra.
find /home -nouser -ls
busca archivos en los cuales en lugar del nombre de usuario dueño aparece un número (UID).
Esta situación se da cuando la cuenta de usuario ha sido borrada pero han permanecido los
archivos creados por ese usuario.
grep
El comando grep (Global Regular Expression and Print) permite buscar las líneas que
contienen una cadena de caracteres especificada mediante una expresión regular. Lee la
entrada estándar o una lista de archivos y muestra en la salida sólo aquellas líneas que
contienen la expresión indicada. La sintaxis es
grep patrón archivos
donde el patrón a buscar es una expresión regular.
Crear un archivo con los días de la semana, uno por línea; llamarle dias.
grep martes dias
grep tes dias
muestra las líneas del archivo dias que contienen la cadena "tes".
grep unix01 /etc/passwd
grep unix0[1-9] /etc/passwd
ls -l /usr | grep '^d'
lista sólo los subdirectorios del directorio /usr (la línea empieza con "d").
ls -l / | grep '.......rw'
lista sólo los archivos que otros pueden leer y escribir en el directorio principal.
grep '^[^:]*::' /etc/passwd
busca usuarios sin contraseña; caracteres al principio de línea que no sean ":", y luego "::" (el
segundo lugar, que es el de la contraseña, está vacío).
grep '^[^:]*:\*:' /etc/passwd
busca usuarios que no pueden entrar al sistema; tienen un * en el lugar de la contraseña; \
escapa el significado del segundo *, que vale como caracter a buscar.
Ninguna expresión regular de grep aparea con un caracter nueva línea; las expresiones
se aplican individualmente a cada línea.
Entre las opciones de grep se cuentan -i para evitar distinguir entre mayúsculas de
minúsculas, -n para mostrar el número de línea y -v para buscar líneas que no contengan
la expresión regular indicada.
fgrep y egrep
Hay dos versiones de grep que optimizan la búsqueda en casos particulares:
fgrep (fixed grep, o fast grep) acepta solamente una cadena de caracteres, y no una
expresión regular, aunque permite buscar varias de estas cadenas simultáneamente;
egrep (extended grep), que acepta expresiones regulares extendidas con los operadores
+ ? | y paréntesis.
fgrep no interpreta metacaracteres, pero puede buscar muy eficientemente muchas
palabras en paralelo, por lo que se usa mucho en búsquedas bibliográficas; egrep acepta
expresiones más complejas, pero es más lento; grep es un buen compromiso entre
ambos.
fgrep martes dias
busca la cadena martes en el archivo dias.
En fgrep y egrep puede indicarse la opción -f buscar.exp, donde buscar.exp es un
archivo que contiene la expresión a buscar: cadenas simples para fgrep, expresiones
regulares para egrep, separadas por nueva línea; las expresiones se buscan en paralelo, es
decir que la salida serán todas las líneas que contengan una cualquiera de las expresiones a
buscar.
Crear un archivo buscar.fgrep con las cadenas "tes" y "jue", una por línea. El comando
fgrep -f buscar.fgrep dias
extrae del archivo dias las líneas que contienen estas cadenas.
El comando grep soporta fgrep y egrep como opciones -F y -E, respectivamente.
grep -F -f buscar.fgrep dias
egrep "tes|jue" dias
grep -E "tes|jue" dias
obtienen el mismo efecto del comando anterior.
egrep "([0-9]+ab)*1234" archivo
busca cadenas comenzadas opcionalmente por un dígito y los caracteres ab, todo el paréntesis
0 o más veces, y hasta encontrar la cadena 1234.
Escribir grep -E es similar a egrep, aunque no idéntico; egrep es compatible con el
comando histórico egrep; grep -E acepta expresiones regulares extendidas y es la versión
moderna del comando en GNU. fgrep es idéntico a grep -F.
tr
El comando tr translitera los caracteres de la entrada: sustituye unos caracteres por otros. La
sustitución es caracter a caracter. Entre sus opciones se encuentran -d para borrar caracteres; -
c para sustituir complemento de los caracteres indicados, es decir, que no sean ésos; y -s para
comprimir caracteres repetidos en uno solo.
cat dias | tr a-z A-Z
convierte todo a mayúsculas.
cat dias | tr -d aeiou
borra todas las vocales del archivo dias.
Agregar al archivo dias líneas en blanco, varias seguidas, intercaladas entre los nombres de
los días.
cat dias
cat dias | tr -s "\n*"
convierte varios caracteres nueva línea seguidos en una solo; elimina renglones en blanco.
cat nota | tr -c "[a-zA-Z0-9]" "_"
transforma todos los caracteres que no sean letras o números en subrayas.
cat nota | tr -cs "[a-zA-Z0-9]" "[\n*]"
transforma todos los caracteres que no sean letras o números en nuevalínea, y comprime las
nuevalíneas repetidas en una sola; deja cada palabra sola en un renglón.
ls -l /usr | tr -s " " | cut -f3,4
comprime los blancos en la salida para poder cortar campos.
uniq
El comando uniq excluye todos los renglones adyacentes duplicados menos uno; es decir,
elimina renglones repetidos consecutivos. La opción -c escribe el número de ocurrencias al
comienzo del renglón.
El siguiente ejemplo muestra las 5 palabras más frecuentes en el conjunto de archivos:
cat *.txt | tr -sc A-Za-z '\012' | \
sort | uniq -c | sort -n | tail 5
cat lista todos los archivos, tr comprime el renglón eliminando blancos, sort los ordena,
uniq cuenta las ocurrencias y elimina repetidos, sort -n ordena por cantidad de ocurrencias
y tail muestra las 5 ocurrencias más frecuentes.
dd
El comando dd es un convertidor de datos: convierte de ASCII a EBCDIC y a la inversa, cambia
los tamaños de los bloques de registros, hace ajuste de blancos y otras transformaciones
usuales cuando se manejan transferencias entre sistemas operativos distintos o datos en
bruto, sin formato, como en los respaldos en cinta.
Comandos de Filtro Referencias
dd find grep, fgrep, egrep sort tr uniq
dd
dd OPCION ...
copia un archivo, de entrada estándar a salida estándar por defecto, opcionalmente
cambiando tamaño de bloques de entrada salida y realizando diversas conversiones.
if=ARCHIVO leer la entrada del archivo indicado.
of=ARCHIVO dirigir la salida al archivo indicado.
ibs=BYTES leer la entrada en bloques de BYTES bytes.
obs=BYTES grabar la salida en bloques de BYTES bytes.
bs=BYTES leer y grabar entrada y salida en bloques.
conv=CONVERSION[,CONVERSION]... convertir según argumentos.
Las opciones numéricas admiten los multiplicadores b para 512, k para 1024.
Los argumentos de conversión se separan por comas sin espacios; incluyen:
ascii convierte EBCDIC a ASCII.
ebcdic convierte ASCII a EBCDIC.
ibm convierte ASCII a EBCDIC alternativo.
block embloca cada línea de entrada en 'cbs' bytes, reemplaza
nueva línea por espacio, rellena con espacios.
unblock reemplaza espacios finales de cada bloque con nueva línea.
lcase convierte mayúsculas a minúsculas
ucase convierte minúsculas a mayúsculas.
notrunc no truncar el archivo de salida.
find
find [DIRECTORIO...] [EXPRESION]
Recorre una jerarquía de directorios buscando archivos seleccionados según cierta
expresión y muestra información sobre los encontrados.
Argumentos numéricos:
+N mayor que N
-N menor que N
N exactamente N.
Criterios de búsqueda:
-name PATRON el nombre aparea con PATRON;
-iname PATRON idem,insensible a mayúculas;
-path PATRON nombre con vía completa;
-ipath PATRON idem, insensible a mayústulas;
-regexp EXP nombre aparea con expresión regular EXP
-iregexp EXP idem, insensible a mayúsculas;
-lname PATRON archivo es un enlace simbólico;
-ilname PATRON idem, insensible a mayúsculas;
-atime N último acceso N*24 horas atrás
-ctime N último cambio de estado N*24 horas atrás
-mtime N última modificación N*24 horas atrás
-amin N último acceso N minutos atrás
-cmin N último cambio de estado N minutos horas atrás
-mmin N última modificación N minutos atrás
-daystart mide tiempos desde las 0 horas de hoy
-size N[bckw] tamaño de N bloques, caracteres, KB o palabras (2
bytes)
-empty archivo vacío, regular o directorio
-user UNAME archivo del usuario UNAME
-group GNAME archivo del grupo GNAME
-uid N archivo del usuario de número N
-gid N archivo del grupo de número N
-nouser archivo sin dueño asignado
-nogroup archivo sin grupo asignado
Acciones:
-print imprime la ruta completa de los archivos encontrados.
-ls lista los archivos encontrados en formato ls -dils
-exec COMANDO {} \; ejecuta COMANDO sobre los archivos encontrados
find /usr/local/doc -name '*.texi'
busca en el directorio indicado los archivos de nombre indicado.
find /usr/src -name '*.c' -size +100k -print
muestra nombres de archivos terminados en .c con tamaño mayor de 100 K.
find . -lname '*sysdep.c'
busca enlaces simbólicos del nombre indicado.
find /u/bill -amin +2 -amin -6
archivos que fueron leídos entre 2 y 6 minutos atrás.
La medición de tiempos se hace desde 24 horas atrás (1 día atrás); para medir tiempos desde
las 0 horas del día de hoy, usar la opción -daystart.
find ~ -daystart -type f -mtime 1
archivos que fueron modificados ayer.
find / -empty -exec rm -rf '{}' ';'
busca archivos o directorios vacíos y los elimina.
find . -name '*.h' -exec diff -u '{}' /tmp/master ';'
compara archivos de "header" (*.h) del directorio corriente contra el archivo /tmp/master.
grep, egrep, fgrep
grep [ -e PATRON | -f ARCHIVO | PATRON ] OPCIONES ARCHIVO ...
recorre los archivos indicados extrayendo las líneas que aparean con un patrón de
cadena de caracteres.
-G el patrón es una expresión regular básica; opción por defecto
-E el patrón es una expresión regular extendida
-F el patrón es una cadena fija
Existen dos variantes: egrep, similar a grep -E, y fgrep, igual a grep -F.
-c sólo muestra la cantidad de líneas
-e PATRON usa el patrón indicado; útil cuando el patrón empieza con -
-f ARCHIVO obtiene los patrones del archivo, uno por línea
-h suprime indicación de archivo cuando se busca en varios archivos
-i ignora mayúsculas y minúsculas en el patrón y en los archivos
-n indicar número de línea
-v muestra las líneas que no aparean con el patrón
-w aparea el patrón como una palabra
-x el patrón aparea con toda la línea
sort
sort [OPCIONES] [ARCHIVO...]
ordena, mezcla o compara todas las líneas de los archivos indicados o de la entrada estándar.
Tiene 3 modos de operación: ordenar, verificar orden, mezclar archivos.
-c verifica si los archivos ya están ordenados
-m mezcla archivos ordenados en uno solo, ordenado
-b ignora blancos adelante en la ordenación
-d ordena considerando sólo letras, números y blancos
-f ordena como si todas fueran mayúsculas
-i ignora caracteres no imprimibles (fuera de 040-0176 octal)
-n ordena como valores numéricos y no como ASCII
-r invertir el sentido de la ordenación
-o arch archivo de salida; puede ser el de entrada
-t usar el caracter indicado como separador de campos
-k POS1[,POS2] campos de ordenación, POS1 hasta POS2 inclusive;
o hasta el final si no hay POS2
Las posiciones POS1 y POS2 son de la forma F.C donde F es el número del campo y C es el
primer caracter desde el comienzo del campo (para POS1) o desde el final del campo (para
POS2); si se omite C se ordena tomando en cuenta el primer caracter del campo.
cat /etc/passwd | sort -t:
cat /etc/passwd | sort -t: +4 -f | cut -d: -f5
cat /etc/passwd | sort -t: +5 | cut -d: -f6
cat /etc/passwd | sort -t: -n -k3,5 | cut -d: -f4,5
tr
tr [OPCION]... CONJ1 [CONJ2]
copia entrada en salida traduciendo, comprimiendo o borrando caracteres. CONJ1 y
CONJ2 definen un conjunto ordenado de caracteres a transformar. La opción -c
reemplaza CONJ1 por su complemento, los caracteres no especificados en el conjunto.
-d elimina los caracteres de CONJ1.
-s comprime caracteres repetidos en CONJ1 en una sola ocurrencia.
-ds primero borra según CONJ1 y después comprime según CONJ2.
El formato de CONJ1 y CONJ2 se parece al de las expresiones regulares, pero son sólo
listas de caracteres. La mayoría de los caracteres se representan a sí mismos, pero
existen las siguientes abreviaturas:
\a Control-G,
\b Control-H,
\f Control-L,
\' Control-J,
\r Control-M,
\t Control-I,
\v Control-K,
\OOO caracter representado por dígitos octales
\\ barra inversa.
M-N intervalo de caracteres desde el M al N (M anterior al N)
0-9 equivale a 0123456789
La notación [:CLASE:] expande a los caracteres predefinidos en las clases:
alnum letras y números.
alpha letras.
blank espacio.
cntrl caracteres de control.
digit números.
graph caracteres imprimibles, excluído el espacio.
lower minúsculas
print caracteres imprimibles, incluído el espacio.
punct signos de puntuación.
space espacio
upper mayúsculas.
xdigit dígitos hexadecimales.
La traducción se realiza cambiando el primer caracter de CONJ1 por el primer caracter
de CONJ2, el 2o. de CON1 por el 2o. de CONJ2, etc. Los caracteres no indicados en
CONJ1 pasan incambiados.
tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ
tr a-z A-Z
tr '[:lower:]' '[:upper:]'
convierten minúsculas en mayúsculas.
tr -d '\000'
elimina caracteres nulos (octal 000).
tr -cs '[a-zA-Z0-9]' '[\n*]'
separa las palabras una por línea.
tr -s '\n'
comprime caracteres nueva línea en uno solo (elimina líneas en blanco).
uniq
uniq [OPCION]... [ENTRADA [SALIDA]]
muestra una única línea para una entrada ordenada, eliminando líneas repetidas
sucesivas. Opcionalmente, puede mostrar solo líneas que aparecen una vez, o sólo líneas
que aparecen varias veces. La entrada debe estar ya ordenada; si no lo está, puede usars
sort -u para lograr un efecto similar.
-f N saltear N campos antes de verificar unicidad.
-s N saltear N caracteres antes de verificar unicidad.
-c indicar junto a cada línea el número de veces que aparece.
-i ignorar mayúsculas y minúsculas al comparar.
-d mostrar sólo líneas repetidas.
-u mostrar sólo líneas únicas.
Los campos son cadenas de caracteres separadas por uno o más blancos (espacios o
tabuladores). Si se indican saltear campos y caracteres, los campos se saltean primero.
Programación del Shell Comandos multilínea
El archivo de comandos (script)
Comentarios en los scripts
Comandos de programación
true
false
if
for
case
while
until
exit
expr
test
read
Parámetros
Depuración
Preguntas y Ejercicios
Bibliografía y Referencias
El intérprete de comandos o "shell" de UNIX es también un lenguage de programación
completo. La programación de shell se usa mucho para realizar tareas repetidas con
frecuencia. Los diseñadores de sistemas suelen escribir aplicaciones en el lenguaje de
base del sistema operativo, C en el caso de UNIX, por razones de rapidez y eficiencia.
Sin embargo, el shell de UNIX tiene un excelente rendimiento en la ejecución de
"scripts" (guiones); ésta es la denominación aplicada a los programas escritos en el
lenguaje del shell. Se han creado aplicaciones completas usando solamente scripts.
Comandos multilínea.
Una línea de comando termina con un caracter nuevalínea. El caracter nuevalínea se ingresa
digitando la tecla ENTER. Varios comandos pueden escribirse en una misma línea usando el
separador ";" echo $LOGNAME; pwd; date
Si un comando no cabe en una línea, la mayoría de los intérpretes continúan la digitación en la
línea siguiente. Para establecer específicamente que un comando continúa en la línea
siguiente, hay dos formas, mutuamente excluyentes (se usa una u otra, pero no ambas al
mismo tiempo):
- terminar la primera línea con \ : $ echo $LOGNAME \ > $HOME
que muestra algo como
jperez /home/jperez
- dejar una comilla sin cerrar: $ echo "$LOGNAME > $HOME"
que produce el mismo resultado.
En los ejemplos anteriores hemos escrito los indicadores de comando. Al continuar el
comando en la segunda línea, el indicador de comandos cambia de $ a >, es decir, del
indicador de comando de primer nivel PS1 al indicador de comando de segundo nivel PS2. Si
no se quiere terminar el comando multilínea, puede interrumpirse el ingreso con Ctrl-C,
volviendo el indicador de comando a PS1 inmediatamente.
El archivo de comandos (script).
Es cómodo poder retener una lista larga de comandos en un archivo, y ejecutarlos todos de
una sola vez sólo invocando el nombre del archivo. Crear el archivo misdatos.sh con las
siguientes líneas: # misdatos.sh # muestra datos relativos al usuario que lo invoca # echo "MIS DATOS." echo " Nombre: "$LOGNAME echo "Directorio: "$HOME echo -n "Fecha: " date echo # fin misdatos.sh
El símbolo # indica comentario. Para poder ejecutar los comandos contenidos en este archivo,
es preciso dar al mismo permisos de ejecución: chmod ug+x misdatos.sh
La invocación (ejecución) del archivo puede realizarse dando el nombre de archivo como
argumento a bash bash misdatos.sh
o invocándolo directamente como un comando misdatos.sh
Puede requerirse indicar una vía absoluta o relativa, o referirse al directorio actual, ./misdatos.sh
si el directorio actual no está contenido en la variable PATH.
Comentarios en los scripts.
En un script todo lo que venga después del símbolo # y hasta el próximo caracter nuevalínea se
toma como comentario y no se ejecuta. echo Hola todos # comentario hasta fin de línea
sólo imprime "Hola todos". # cat /etc/passwd
no ejecuta nada, pues el símbolo # convierte toda la línea en comentario.
Los scripts suelen encabezarse con comentarios que indican el nombre de archivo y lo que
hace el script. Se colocan comentarios de documentación en diferentes partes del script para
mejorar la comprensión y facilitar el mantenimiento. Un caso especial es el uso de # en la
primera línea para indicar el intérprete con que se ejecutará el script. El script anterior con
comentarios quedaría así:
#!/bin/bash # misdatos.sh # # muestra datos propios del usuario que lo invoca # echo "MIS DATOS." echo " Nombre: "$LOGNAME echo "Directorio: "$HOME echo -n "Fecha: " date # muestra fecha y hora echo # línea en blanco para presentación # fin misdatos.sh
La primera línea indica que el script será ejecutado con el intérprete de comandos bash. Esta
indicación debe ser siempre la primera línea del script y no puede tener blancos.
Estructuras básicas de programación.
Las estructuras básicas de programación son sólo dos: la estructura repetitiva y la estructura
alternativa. Cada forma tiene sus variaciones, y la combinación de todas ellas generan múltples
posibilidades, pero detrás de cualquiera de ellas, por compleja que parezca, se encuentran
siempre repeticiones o alternativas.
Estructura repetitiva: se realiza una acción un cierto número de veces, o mientras dure
una condición.
mientras haya manzanas, pelarlas; desde i = 1 hasta i = 7 escribir dia_semana(i);
Esta escritura informal se denomina "pseudocódigo", por contraposición al término
"código", que sería la escritura formal en un lenguaje de programación. En el segundo
ejemplo, dia_semana(i) sería una función que devuelve el nombre del día de la
semana cuando se le da su número ordinal.
Estructura alternativa: en base a la comprobación de una condición, se decide una
acción diferente para cada caso.
si manzana está pelada, comerla, en otro caso, pelarla;
# oráculo caso $estado en soltero) escribir "El casamiento será su felicidad"; casado) escribir "El divorcio le devolverá la felicidad"; divorciado) escribir "Sólo será feliz si se vuelve a casar"; fin caso
Funciones: una tarea que se realiza repetidamente dentro del mismo programa puede
escribirse aparte e invocarse como una "función". Para definir una función es preciso
elegir un nombre y escribir un trozo de código asociado a ese nombre. La función suele
recibir algún valor como "parámetro" en base al cual realiza su tarea. Definida así la
función, para usarla basta escribir su nombre y colocar el valor del parámetro entre
paréntesis.
función area_cuadrado (lado) devolver lado * lado; función dia_semana(día_hoy) caso $dia_hoy en 1) devolver "Lunes";; 2) devolver "Martes";; 3) devolver "Miércoles";: 4) devolver "Jueves";; 5) devolver "Viernes;; 6) devolver "Sábado";; 7) devolver "Domingo";; fin caso;
Comandos de programación.
En esta sección veremos los comandos típicos de programación del shell. Obsérvese que el
shell toma la convención inversa de C para cierto y falso: cierto es 0, y falso es distinto de 0. El
shell adopta esta convención porque los comandos retornan 0 cuando no hubo error. Veremos
dos comandos, true y false, que retornan siempre estos valores; se usan en algunas
situaciones de programación para fijar una condición.
true
Este comando no hace nada, sólo devuelve siempre 0, el valor verdadero. La ejecución
correcta de un comando cualquiera devuelve 0. true echo $?
muestra el valor 0; la variable $? retiene el valor de retorno del último comando ejecutado.
false
Este comando tampoco hace nada sólo devuelve siempre 1; cualquier valor diferente de 0 se
toma como falso. Las diversas condiciones de error de ejecución de los comandos devuelven
valores diferentes de 0; su significado es propio de cada comando. false echo $?
muestra el valor 1.
if
El comando if implementa una estructura alternativa. Su sintaxis es if expresión ; then comandos1 ; [else comandos2 ;] fi
o también if expresión then comandos1 [else comandos2] fi
Si se usa la forma multilínea cuando se trabaja en la línea de comandos, el indicador cambia a
> hasta que termina el comando.
La expresión puede ser cualquier expresión lógica o comando que retorne un valor; si el valor
retornado es 0 (cierto) los comandos1 se ejecutan; si el valor retornado es distinto de 0 (falso)
los comandos1 no se ejecutan. Si se usó la forma opcional con else se ejecutan los
comandos2. if true; then echo Cierto ; else echo Falso ; fi
siempre imprime Cierto; no entra nunca en else. if false; then echo Cierto ; else echo Falso ; fi
siempre imprime Falso, no entra nunca en then.
Construcciones más complejas pueden hacerse usando elif para anidar alternativas. Escribir
en un archivo las líneas que siguen
# ciertofalso.sh: escribe cierto o falso según parámetro numérico # if [ $1 = "0" ] then echo "Cierto: el parámetro es 0." else echo "Falso: el parámetro no es 0." fi
Convertir el script en ejecutable. Invocar este script con ./ciertofalso.sh N
donde N es un número entero 0, 1, 2, etc. La variable $1 hace referencia a este parámetro de
invocación. Verificar el resultado.
Crear y ejecutar el siguiente script:
# trabajo.sh: dice si se trabaja según el día # invocar con parámetros: # domingo, feriado, u otro nombre cualquiera # if [ $1 = "domingo" ] then echo "no se trabaja" elif [ $1 = "feriado" ] then echo "en algunos se trabaja" else echo "se trabaja" fi
for
Este comando implementa una estructura repetitiva, en la cual una secuencia de comandos se
ejecuta una y otra vez. Su sintaxis es for variable in lista ; do comandos ; done
Se puede probar en la línea de comandos: for NUMERO in 1 2 3 4 ; do echo $NUMERO ; done for NOMBRE in alfa beta gamma ; do echo $NOMBRE ; done for ARCH in * ; do echo Nombre archivo $ARCH ; done
El caracter * es expandido por el shell colocando en su lugar todos los nombres de archivo del
directorio actual.
Crear y probar el siguiente script.
# listapal.sh: lista de palabras # muestra palabras de una lista interna # LISTA="silla mesa banco cuadro armario" for I in $LISTA do echo $I done # fin listapal.sh
En el siguiente script, el comando expr calcula expresiones aritméticas; notar su sintaxis.
# contarch.sh # muestra nombres y cuenta archivos en el directorio actual # CUENTA=0 for ARCH in * do echo $ARCH CUENTA=`expr $CUENTA + 1` # agrega 1 a CUENTA done
echo Hay $CUENTA archivos en el directorio `pwd` # fin contarch.sh
case
Este comando implementa alternativas o "casos"; elige entre múltiples secuencias de
comandos la secuencia a ejecutar. La elección se realiza encontrando el primer patrón con el
que aparea una cadena de caracteres. Su sintaxis es
case $CADENA in patrón1) comandos1;; patrón2) comandos2;; ... *) comandosN;; esac
El patrón * se coloca al final; aparea cualquier cadena, y permite ejecutar comandosN cuando
ninguna de las opciones anteriores fue satisfecha. Crear el siguiente script:
# diasemana.sh: nombres de los días de la semana # invocar con número del 0 al 6; 0 es domingo case $1 in 0) echo Domingo;; 1) echo Lunes;; 2) echo Martes;; 3) echo Miércoles;; 4) echo Jueves;; 5) echo Viernes;; 6) echo Sábado;; *) echo Debe indicar un número de 0 a 6;; esac
Invocarlo como diasemana.sh N
donde N es cualquier número de 0 a 6, otro número, o una cadena cualquiera. Verificar el
comportamiento.
Crear el archivo estacion.sh con estas líneas:
# estacion.sh # indica la estación del año aproximada según el mes # case $1 in diciembre|enero|febrero) echo Verano;; marzo|abril|mayo) echo Otoño;; junio|julio|agosto) echo Invierno;;
setiembre|octubre |noviembre) echo Primavera;; *) echo estacion.sh: debe invocarse como echo estacion.sh mes echo con el nombre del mes en minúscula;; esac # fin estacion.sh
El valor $1 es el parámetro recibido en la línea de comando. La opción *) aparea con cualquier
cadena, por lo que actúa como "en otro caso"; es útil para dar instrucciones sobre el uso del
comando. En las opciones, | actúa como OR; pueden usarse también comodines * y ?. Invocar
el script: bash estacion.sh octubre bash estacion.sh
¿Cómo podría modificarse el script anterior para que aceptara el mes en cualquier
combinación de mayúsculas y minúsculas?
while
Este comando implementa una estructura repetitiva en la cual el conjunto de comandos se
ejecuta mientras se mantenga válida una condición (while = mientras). La condición se
examina al principio y luego cada vez que se completa la secuencia de comandos. Si la
condición es falsa desde la primera vez, los comandos no se ejecutan nunca. Su sintaxis es while condición ; do comandos ; done
En el guión que sigue la expresión entre paréntesis rectos es una forma de invocar el comando
test, que realiza una prueba devolviendo cierto o falso. El operador -lt, "lower than",
significa "menor que". Observar su sintaxis, sobre todo la posición de los espacios en blanco,
obligatorios.
# crear1.sh # crea archivos arch1....arch9, los lista y luego borra VAL=1 while [ $VAL -lt 10 ] # mientras $VAL < 10 do echo creando archivo arch$VAL touch arch$VAL VAL=`expr $VAL + 1` done ls -l arch[0-9] rm arch[0-9] # fin crear1.sh
until
Este comando implementa una estructura repetitiva en la cual el conjunto de comando se
ejecuta hasta que se cumpla una condición. En cuanto la condición se cumple, dejan de
ejecutarse los comandos. La condición se examina al principio; si es verdadera, los comandos
no se ejecutan. Notar la diferencia con while. Su sintaxis es until condición ; do comandos ; done
Usando until, el script anterior se escribiría
# crear2.sh # crea archivos arch1....arch9, los lista y luego borra VAL=1 until [ $VAL -eq 10 ] # hasta que $VAL = 10 do echo creando archivo arch$VAL touch arch$VAL VAL=`expr $VAL + 1` done ls -l arch[0-9] rm arch[0-9] # fin crear2.sh
exit
Este comando se utiliza en programación de shell para terminar inmediatamente un script y
volver al shell original. exit
en un script, termina inmediatamente el script; en la línea de comando, termina la ejecución
del shell actual, y por lo tanto la sesión de UNIX. exit 6
termina el script devolviendo el número indicado, lo que puede usarse para determinar
condiciones de error. exit 0
termina el script devolviendo 0, para indicar la finalización exitosa de tareas. Escribir sólo exit
también devuelve código de error 0.
El siguiente script ofrece un ejemplo de uso.
#!/bin/bash # exitar.sh: prueba valores de retorno de exit # clear echo "Prueba de valores de retorno" echo " Invocar con parámetros " echo " bien, error1, error2, cualquier cosa o nada" echo " Verificar valor de retorno con" echo ' echo $?' echo VALOR=$1 case $VALOR in bien) echo " -> Terminación sin error." exit 0;; error1) echo " -> Terminación con error 1." ; exit 1;; error2) echo " -> Terminación con error 2." ; exit 2;; *)
echo " -> Terminación con error 3." echo " (invocado con parámetro no previsto o sin parámetro." exit 3;; esac
expr
Este comando recibe números y operadores aritméticos como argumentos, efectúa los
cálculos indicados y devuelve el resultado. Cada argumento debe estar separado por blancos.
Opera sólo con números enteros y realiza las operaciones suma (+), resta (-), multiplicación (*),
división entera (/), resto de división entera (%). Los símbolos * y / deben ser escapados
escribiendo \* y \/, al igual que los paréntesis, que deben escribirse \( y \).
El comando expr usa la convención de C para cierto y falso: 0 es falso, y distinto de 0
es cierto. No confundir con la convención que toma el shell en sus valores true y false,
que es la contraria. expr 4 + 5 devuelve 9 ( 4 + 5 = 9 ). expr 3 \* 4 + 6 \/2
devuelve 15 ( 3 * 4 + 6 /2 = 15 ). expr 3 \* \( 4 + 3 \) \/2 devuelve 10 ( 3 * (4 + 3) / 2 = 10 ).
expr también realiza operaciones lógicas de comparación, aceptando los operadores =,
!=, >, <, >= y <=. El operador != es "no igual"; el ! se usa para negar. Estos
caracteres también requieren ser escapados. echo `expr 6 \< 10`
devuelve 1, cierto para expr. echo `expr 6 \> 10`
devuelve 0, falso para expr. echo `expr abc \< abd`
devuelve 1, cierto para expr.
test
Este comando prueba condiciones y devuelve valor cierto (0) o falso (distinto de 0) según el
criterio de cierto y falso del shell; esto lo hace apto para usar en la condición de if. Tiene dos
formas equivalentes test expresión [ expresión ]
Los blancos entre la expresión y los paréntesis rectos son necesarios.
test devuelve cierto ante una cadena no vacía, y falso ante una cadena vacía: if test "cadena" ; then echo Cierto ; else echo Falso; fi if test "" ; then echo Cierto ; else echo Falso ; fi if [ cadena ] ; then echo Cierto ; else echo Falso; fi if [ ] ; then echo Cierto ; else echo Falso ; fi
test prueba una cantidad de condiciones y situaciones:
if [ -f archivo ]; then echo "Existe archivo"; \ else echo "No existe archivo"; fi
La condición [ -f archivo ] es cierta si archivo existe y es un archivo normal;
análogamente, -r comprueba si es legible, -w si puede escribirse, -x si es ejecutable, -d si es un
directorio, -s si tiene tamaño mayor que 0.
Las condiciones [ $DIR = $HOME ] [ $LOGNAME = "usuario1" ] [ $RESULTADO != "error" ]
comparan cadenas de caracteres; = para igualdad y != para desigualdad.
La condición [ "$VAR1" ]
devuelve falso si la variable no está definida. Las comillas dan la cadena nula cuando VAR1 no
está definida; sin comillas no habría cadena y daría error de sintaxis.
La condición [ expnum1 -eq expnum2 ]
compara igualdad de expresiones que resultan en un número. Pueden ser expresiones
numéricas o lógicas, ya que éstas también resultan en números. Los operadores numéricos
derivan sus letras del inglés, y son -eq (igualdad), -neq (no igual, desigualdad), -lt (menor), -gt
(mayor), -le (menor o igual), -ge (mayor o igual).
El comando test se usa mucho para determinar si un comando se completó con éxito, en
cuyo caso el valor de retorno es 0. El siguiente script crea un archivo si no existe.
# nvoarch.sh # recibe un nombre y crea un archivo de ese nombre; # si ya existe emite un mensaje if [ -f $1 ] then echo El archivo $1 ya existe else touch $1 echo Fue creado el archivo $1 fi echo # fin nvoarch.sh
Para comprobar su acción, bash nvoarch.sh nuevo1 ls -l nuevo1
crea el archivo; ls comprueba que existe; bash nvoarch.sh nuevo1
da mensaje indicando que el archivo ya existe.
Otros operadores aceptados por test son -a (AND) y -o (OR). # rwsi.sh # indica si un archivo tiene permiso de lectura y escritura ARCH=$1 if [ -r $ARCH -a -w $ARCH ] then
echo El archivo $ARCH se puede leer y escribir else echo Al archivo $ARCH le falta algún permiso fi ls -l $ARCH # fin rwsi.sh
read
Este comando tiene como propósito solicitar información al usuario. Su ejecución captura las
digitaciones del usuario, hasta obtener un caracter nueva línea (techa Enter). El ejemplo
siguiente obtiene datos del usuario, los repite en pantalla, solicita confirmación y emite un
mensaje en consecuencia.
# yo.sh: captura datos del usuario # clear echo "Datos del usuario." echo -n "Nombre y apellido: "; read NOMBRE echo -n "Cédula de identidad: "; read CEDULA echo echo "Ha ingresado los siguientes datos:" echo " Nombre y apellido: $NOMBRE" echo " Cédula de Identidad: $CEDULA" echo -n "¿Es correcto?(sN):"; read RESP if [ "$RESP" = "s" -o $RESP = "S" ] then echo "Fin de ingreso." else echo "Debe ingresar sus datos nuevamente." fi
Parámetros.
El siguiente programa muestra los parámetros que recibe al ser invocado:
# ecopars.sh # muestra los parámetros recibidos echo Cantidad de parámetros: $# for VAR in $* do echo $VAR done # fin ecopars.sh ecopars.sh Enero Febrero Marzo
muestra la cantidad y los parámetros recibidos. La variable $* contiene la lista de parámetros,
y $# la cantidad.
Dentro del script, los parámetros recibidos pueden referenciarse con $1, $2, $3, ..., $9, siendo
$0 el nombre del propio programa. Debido a que se los reconoce por su ubicación, se llaman
parámetros posicionales. El siguiente programa se invoca con tres parámetros y muestra sus
valores:
# mostrar3.sh # se invoca con 3 parámetros y los muestra echo nombre del programa: $0 echo parámetros recibidos: echo $1; echo $2; echo $3 echo # fin mostrar3.sh
¿Cómo se podría verificar la invocación con 3 parámetros, y emitir un mensaje de error en caso
contrario (cuando el usuario ingresa menos de 3 parámetros)?
Depuración.
Se llama depuración ("debug") de un programa al proceso de verificar su funcionamiento en
todos los casos posibles y corregir sus errores ("bugs", "pulgas"; del inglés, literalmente,
"chinche"; por extensión, insecto pequeño).
Cuando se está escribiendo un script, puede convenir invocarlo de forma especial para
generar información de comandos ejecutados y errores, para ayudar en la depuración.
Las salidas se imprimen en el error estándar, por lo que pueden direccionarse a un
archivo sin mezclarse con la salida del comando. bash -x ecopars.sh
imprime cada comando en la salida; bash -v ecopars.sh invoca el script obteniendo una salida verbosa con información sobre cada comando
ejecutado. bash -xv ecopars.sh 2>ecopars.err reúne las dos fuentes de información y direcciona el error estándar a un archivo.
Comandos de Usuario Ultima revisión: Set 2001
Propósito
Metalenguaje y convenciones
Referencias
Comandos: apropos banner cal cat cd chmod clear cmp cp cut date diff echo
env exit file head hostname id info less ln ls dir vdir mail man
mesg mkdir more mv passwd pr printenv ps pwd rm rmdir tail talk
touch umask wc whatis which who whoami
Propósito:
Esta guía resume la sintaxis, opciones más frecuentes y ejemplos de uso de los comandos UNIX
de más uso en la práctica. En descripción se presenta nombre del comando, sintaxis resumida,
acción principal, opciones más usuales, ejemplos y observaciones, si las hay.
Esta guía no puede ni pretende sustituir la consulta de las páginas man.
Metalenguaje y convenciones: ... repetición del último item [] item opcional, puede estar o no {A|B} item opcional obligatorio, debe tomarse A o B TAB tecla o caracter tabulador LF caracter nueva línea CR caracter retorno de carro ESPACIO caracter o tecla de barra espaciadora blanco caracter TAB o ESPACIO, delimita palabras UID identificador de usuario (número) GID identificador de grupo (número) (su) requiere permiso de supervisor
Los items en minúsculas van tal cual, los items en MAYUSCULAS deben ser sustituídos
por valores del usuario.
apropos
apropos [OPCIONES] PALABRA-CLAVE ...
busca entre las descripciones cortas de las páginas del manual la presencia de la palabra clave.
-r interpreta cada nombre como una expresión regular
-w interpreta cada nombre como conteniendo caracteres comodines
apropos man
apropos -w man*
banner
banner MENSAJE
Muestra el mensaje (cadena de caracteres) en letras grandes y girado 90°; para imprimir
carteles.
-wN en un ancho de N columnas
banner -w 40 Hola!
banner a
cal
cal [OPCIONES] [[MES]AÑO]
Sin parámetros, muestra calendario del mes actual; el año debe indicarse con centuria, 1-1999;
el mes en número 1 a 12.
-j día juliano, contado desde el 1 de enero
-y calendario del año en curso
cal
cal 1998
cal 11 1997
cal 9 1752
muestra el mes del año en que se saltearon 11 días para compensar años bisiestos.
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.
cd
cd [DIRECTORIO]
cambia directorio de trabajo; sin parámetros, cambia al directorio propio del usuario como
aparece en $HOME. En Linux, es un comando interno del shell; ver bash(1).
cd /etc
cd
chmod
chmod [OPCION] MODO ARCHIVO ...
cambia los permisos de acceso a los archivos indicados. No cambia los permisos de los enlaces
simbólicos.
-v verboso, describe acción sobre cada archivo.
-R recursivo, cambia permisos de subdirectorios y sus contenidos
chmod -R 0755 documentos/visibles
chmod ug+rw-x,o+r-wx cap*.txt
clear
clear
borra la pantalla del terminal.
cmp
cmp [OPCIONES] ARCH1 ARCH2 [SALTEAR1 [SALTEAR2]]
compara dos archivos. Si son iguales, no dice nada; si difieren, marca el byte y el número de
línea de la primera diferencia.
-l número de byte (decimal) y bytes diferentes (octal) para cada
diferencia.
-s devueve solamente un valor de retorno, sin escribir nada.
Los valores de retorno son 0 si los archivos son iguales, 1 si diferen, >1 si hubo un error. Los
valores decimales SALTEAR1 y SALTEAR2 indican la posición de byte donde comienza la
comparación en ARCH1 y ARCH2; puede expresarse en hexadecimal precediento el número
con 0x, o en octal precediendo con 0.
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
-v verboso, escribe el nombre de cada archivo que copia
cp arch1 /dir1/arch1
cp -vi arch1 arch2
cp -dpRv dir1 /dir2/subdir2 dirtodo
mejor forma de copiar exactamente una estructura de directorios, recursivamente,
conservando permisos y manteniendo enlaces simbólicos; verboso puede omitirse.
cut
cut -f CAMPOS [-d DELIM][ARCHIVO ...]
cut -c COLUMNAS [ARCHIVO ...]
extrae partes de cada línea de los archivos indicados o de la entrada estándar. Los campos y
columnas se indican con números 1, 2,... o con intervalos n-m. Intervalos incompletos: -n es 1-
n, m- es m hasta el último campo o columna.
-f campos numerados, por defecto separados por TAB
-c columnas, ubicación posicional de caracteres en la línea
-d fija el caracter delimitador de campos, TAB por defecto
-s con -f para no imprimir líneas que no contengan el delimitador
cat /etc/passwd | cut -d: -f1,3,5-6
cat /etc/passwd | cut -c1-15
ls -l | cut -c57-
corta sólo el nombre del archivo, al final (puede requerir ajuste en el valor de columna).
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....)
diff
diff ARCHIVO1 ARCHIVO2
muestra las diferencias existentes entre dos archivos.
diff nota1 nota2
echo
echo [OPCIONES] MENSAJE ...
escribe en la salida estándar los mensajes, separados con un espacio y con LF al final. Muchos
shells tienen un comando interno del mismo nombre; éste, fuera del shell, debe invocarse
como /bin/echo.
-n suprime LF al final
-e interpreta estos caracteres especiales, dentro de " "
\a campana
\b retroceso
\c suprime LF al final
\f cambio de página
\n nueva línea (LF)
\r retorno de carro (CR)
\t tabulador horizontal
\v tabulador vertical
\\ barra inversa
\nnn caracter ASCII nnn en octal
echo Hola Todos!
echo -n Hola Todos!
echo -e "\a"
echo -e "\101"
muestra la letra A, que es 101 en octal.
env
env [OPCIONES][NOMBRE=VALOR]...[COMANDO [ARGUMENTO ...]]
Sin argumentos, muestra valores de variables de ambiente; con argumentos, corre el comando
indicado con las variables de ambiente modificadas según se indique.
-i comenzar con un ambiente virgen, ignorando el actual
env
env DIR=/etc listadir1
lista el contenido del directorio /etc; listadir es un archivo ejecutable que contiene la línea
ls dir1, para listar contenido del directorio dir1.
echo Directorio $HOME
ls -l $HOME
muestra el directorio propio del usuario, guardado en la variable de ambiente HOME.
exit
exit [N]
produce la salida del shell con estado de terminación N (número); si no se indica retorna con 0.
file
file OPCIONES ARCHIVO
intenta determinar el tipo de archivo de que se trata: texto ASCII, código C, script en
diversos lenguajes, binario, otros.
-z examina archivos comprimidos
file cati.c
este archivo contiene código C. file adduser este archivo es un script en Perl. file /bin/cat
es un ejecutable binario.
head
head [OPCIONES] ARCHIVO ...
muestra la primera parte de un archivo, por defecto 10 líneas. Si son varios archivos muestra
un encabezado con el nombre de cada archivo.
-v verboso, imprime encabezamiento con nombre del archivo
-q silencioso, no imprime encabezado con nombre del archivo
-N imprime primeras N líneas, por defecto 10
-n N imprime primeras N líneas
head -24 /etc/inetd.conf
hostname
hostname [NOMBRE]
sin argumentos, da el nombre de la máquina; con NOMBRE, fija el nombre de la máquina (su).
-h ayuda
-f --fqdn nombre de máquina completo, con dominio DNS
-d --domain nombre de dominio DNS
-i --ip-address dirección (número IP)
-a --alias nombres de alias
-v verboso
id
id [OPCIONES] [NOMBRE_USUARIO]
muestra información sobre un usuario. Muestra nombre, UID, grupo, GID y grupos
suplementarios. Si el id real y el efectivo no corresponden muestra ambos. Las opciones
limitan el despliegue.
-g sólo el grupo primario
-G grupos suplementarios
-n nombre en lugar de número; requiere -u, -g, o -G
-r real en lugar de efectivo; requiere -u, -g o -G
-u sólo el número de usuario (UID)
id
id webmaster
muestra datos del usuario webmaster.
info
info [NOMBRE]
sistema de información de GNU sobre UNIX.
info info
muestra información sobre info, con tutorial para aprender a manejar info.
less
less [OPCIONES] [ARCHIVO]
programa de paginado y búsqueda similar a more, con más opciones y comandos. Permite
movimiento hacia adelante y atrás, pero no lee todo el archivo al principio, por lo que es más
rápido. Sus comandos están tomados de more y vi (ver more).
--help -? muestra ayuda sobre comandos internos
ln
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
ls, dir, vdir
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 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
dir
equivale al ls -C.
vdir
equivale a ls -l.
mail [OPCIONES] [DESTINO ...]
procesador de correo electrónico de UNIX. Sin argumentos, muestra lista de mensajes en la
casilla de entrada y permite manipularlos. Si hay un destino, lee de la entrada estándar hasta
un "." aislado en una línea y envía lo leído como mensaje a destino.
-v verboso, muestra detalles de entrega
-s TEMA especifica el tema (subject) del mensaje
-c LISTA envía copias a LISTA de usuarios, separados por coma
-b LISTA envía copia ciega a LISTA de usuarios
-f [ARCH] lee contenido de archivo propio mbox o el indicado
-u USUARIO equivale a mail -f /var/spool/mail/USUARIO
Comandos internos de mail:
& indicador de comandos de mail
? muestra lista de comandos para manejo de mensajes
d borra mensaje corriente, marcado con '>'
N muestra el mensaje número N
q sale del programa de correo
mail -s "Saludos para todos " -c pedro,[email protected] juan
envía un mensaje al usuario juan, tema "Saludos para todos", con copia a usuarios pedro y
mateo.
man
man [OPCIONES] [SECCION] NOMBRE ...
Da formato y muestra las páginas del manual en línea. Si no se indica sección, muestra sólo 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 a apropos
-w no imprime las páginas, sino las ubicaciones
Secciones del manual:
1 programas ejecutables y guiones (scripts)
2 llamadas al sistema (funciones del núcleo)
3 llamadas a biblioteca (funciones de biblioteca)
4 archivos especiales (generalmente en /dev)
5 formatos de archivos
6 juegos
7 paquetes de macros
8 comandos de administración (su)
man -h
man man
man -a man
mesg
mesg [y|n]
controla acceso de escritura a la terminal propia por otros usuarios, típicamente con
programas tales como talk y write. Sin parámetros, muestra el estado: is y si está
habilitada escritura, is n si no está habilitada escritura.
y permite a otros escribir mensajes en la terminal
n no permite a otros escribir mensajes en la terminal
mesg
mesg y
mesg n
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.
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 sale
mv
mv [OPCIONES] ARCH_ORIGNEN ARCH_DESTINO
mv [OPCIONES] ARCHIVO ... DIRECTORIO
cambia de nombre ARCH_ORIGEN, o mueve hacia ARCH_DESTINO si el archivo destino invoca
otro directorio; mueve ARCHIVO y los siguientes archivos hacia DIRECTORIO. Entre sistemas
de archivos sólo puede mover archivos normales.
-f forzoso, sobreescribe archivos destino si existen
-i avisa antes de sobreescribir archivos existentes
-v verboso, escribe el nombre de cada archivo que mueve
-u no mover si existe archivo destino más nuevo o de igual fecha
mv nota notanueva
mv -vi LEAME LEAME2
mv -v arch1 notanueva LEAME /dir2/subdir2
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 jperez
(su) cambia la contraseña del usuario jperez.
pr
pr [OPCIONES] ARCHIVO ...
escribe en salida estándar un texto con formato, paginado y opcionalmente en varias
columnas.
+P1[:P2] de página P1 a página P2
-C en C columnas
-a escribe las columnas a través y no hacia abajo
-d a doble espacio
-f separar páginas con salto de página
-h reemplazar encabezado con el indicado
-l largo de página en líneas; por defecto 66
-m escribir archivos en paralelo uno en cada columna
-o margen izquierdo; se suma al ancho indicado por -w
-w ancho de página en columnas; por defecto 72
pr -o8 -l23 -h "Lista de usuarios" /etc/passwd
pr -o2 -l22 -h "Lista de servicios" /etc/services | more
ls /etc | pr -2 -b -l23 | more
ls /etc | pr -3 -b -l23 -a | more
printenv
printenv [VARIABLE] ...
muestra el valor de todas las variables de ambiente; si se indica un nombre de variable,
puestra el valor de esa variable.
printenv TERM
ps
ps [OPCIONES] [PID] ...
informa sobre procesos en ejecución. Para las opciones, no debe usarse -, aunque es aceptado.
l formato largo
u formto usuario, muestra nombre, PID, hora inicio, estado
j formato trabajos, muestra PGID y SID
s formato señales
a mostrar también procesos de otros usuarios.
x mostrar también procesos sin terminal de control
w no truncar líneas para caber en un ancho de página;
agregar una w para cada línea más
h sin encabezado
r sólo procesos en ejecución
ps auxwww | more
muestra todos los procesos en ejecución, en formato usuario, aún los sin terminal, admitiendo
hasta 4 líneas por comando.
pwd
pwd
imprime toda la ruta del directorio corriente; todos los componentes mostrados serán los
directorios reales, no enlaces simbólicos. El shell tiene una versión interna de pwd, por lo que
para ejecutar ésta, que es externa, es preciso escribir
ls -l /var/spool/mail
muestra /var/spool/mail como enlace simbólico a /var/mail (Debian).
cd /var/spool/mail
pwd
versión interna del shell, muestra /var/spool/mail, el enlace simbólico.
/bin/pwd
versión externa, muestra /var/mail, el directorio real.
rm
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 -r *
elimina TODOS los archivos y subdirectorios; no avisa. ¡Cuidado!
rmdir
rmdir [OPCIONES] DIRECTORIO ...
elimina directorios vacíos.
-p elimina directorios padre si quedan vacíos
rmdir dir2
rmdir -p dir1/subdir11/subdir111
tail
tail [OPCIONES] ARCHIVO ...
muestra la última parte de un archivo, por defecto 10 líneas. Si son varios archivos muestra un
encabezado con el nombre de cada archivo.
-f continúa tratando de leer; para archivos en crecimiento
-v verboso, imprime encabezamiento con nombre del archivo
-q silencioso, no imprime encabezado con nombre del archivo
-N imprime últimas N líneas
-n N idem
talk
talk USUARIO [TTY]
conversar con otro usuario. Si está en la misma máquina, alcanza con el nombre de login del
usuario; si está en otra máquina, es preciso usar la forma usuario@maquina. Si el usuario
tiene varias sesiones a la vez, puede indicarse la terminal, usualmente en la forma ttyXX.
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
umask
umask [-S] [MODO]
fija la máscara para permisos de creación según modo. Si modo se indica con número, es en
octal; si no, es en modo simbólico. En general, los permisos de creación serán, para directorios,
0777 menos los bits de máscara; para archivos 0666 menos los bits de máscara. La máscara
vigente es la fijada por defecto o la que se fije con este comando. Sin parámetros, umask
muestra la máscara vigente. La máscara indica los permisos que se quitan al permiso fijado.
-S muestra la máscara, sin fijarla (por defecto, sin parámetros)
umask
muestra la máscara vigente.
umask 022
fija los permisos de creación de archivos en 0666 - 022, es decir, 0644; los de directorios en
2777 - 022, es decir, 2755 (Debian).
uname
uname [OPCIONES]
muestra información de la máquina y del sistema operativo:
-a toda la información
-m máquina, tipo de hardware
-n nombre de máquina en la red
-p tipo de procesador
-r edición (release) del sistema operativo
-s nombre del sistema operativo
-v versión del sistema operativo
wc
wc [OPCIONES] ARCHIVO ...
cuenta líneas, palabras y caracteres de los archivos indicados o de la entrada estándar. Si son
varios los archivos, imprime una línea por cada uno y un total.
-c sólo caracteres
-w sólo palabras
-l sólo líneas
man pwd | wc -l
wc /etc/passwd /etc/group
whatis
whatis [OPCIONES] NOMBRE ...
muestra una descripción corta de los comandos similares a nombre.
-r interpreta cada nombre como una expresión regular
-w interpreta cada nombre como conteniendo caracteres comodines
whatis man
whatis -w man*
which
which PROGRAMA ...
indica la ruta completa de PROGRAMA, si éste está accesible a través de la variable PATH..
who
who [OPCIONES] [am i]
Quién está en el sistema. Muestra nombre de login, línea de terminal, hora de ingreso, nombre
de máquina remota o display X.
am i máquina y nombre de login del usuario invocante
-H muestra encabezado de columnas
-u tiempo inactivo; "old" es >24 horas; "." activo reciente
-w si el usuario recibe (+) o no (-) mensajes
-m igual que 'who am i'
whoami
whoami
Muestra identificador del usuario efectivo actual. Si se ha usado su para adoptar otro usuario,
whoami muestra el nombre asociado con el usuario adoptado.
Tutorial Emulador de Terminal
Ingreso al sistema (login)
Directorios
Listado de archivos
Manual de UNIX
Contenido de un archivo
Crear y borrar un archivo
Correo electrónico de UNIX
Usuarios en el sistema
Talk
Cambio de contraseña
Fin de Sesión
Otros
Bibliografía y Referencias
Emulador de Terminal.
Para ingresar a un sistema UNIX remoto desde un PC se usa habitualmente un "emulador de
terminal". Este programa permite al PC comportarse como una terminal (teclado y pantalla, sin
procesador) conectada directamente a la máquina UNIX. En el emulador de terminal se deben
fijar los siguientes parámetros:
Nombre descriptivo de la conexión a establecer (arbitrario). Nombre en la red de la máquina a la que se quiere conectar. Tipo de terminal que se emulará (VT100 es el más conocido). Conexión vía TCP/IP, protocolo de comunicación en la red.
Ingreso al sistema (login).
login: id-usuario
password:
id-usuario es el nombre identificador del usuario para ingreso al sistema, proceso que se
denomina "login". Este nombre de usuario suele tener hasta 8 caracteres (letras, números y
algunos símbolos), debe comenzar con minúscula. UNIX distingue entre mayúsculas y
minúsculas. En el ingreso al sistema, no se permiten correcciones.
<mensaje del día>
se despliega siempre después del login, es puesto por el administrador del sistema para
información o bienvenida.
<noticias>
aviso de noticias nuevas. Las noticias se usan para informaciones generales de mayor tiempo
de validez. Las noticias no aparecen más después de haber sido leídas. Para leer las noticias
debe digitarse el comando news.
You have mail
indica que hay mensajes de otros usuarios, o del sistema. El correo electrónico permite a
cualquier usuario enviar y recibir mensajes.
$
es el indicador de comandos del sistema; indica que el sistema está listo y aguarda una orden
del operador, que debe ser escrita a continuación de $ y finalizada con la tecla <Enter>.
En los siguientes ejemplos debe escribirse el comando tal cual se muestra, digitando la tecla
<Enter> al final.
date
comando que muestra la fecha y hora.
who
muestra los nombres de usuarios conectados al sistema en este momento.
hostname
muestra el nombre de la máquina UNIX.
Directorios.
Cada usuario tiene un directorio propio, llamado a veces "directorio home". Cuando el usuario
ingresa al sistema ya está ubicado en su directorio propio. El comando
pwd
muestra el directorio actual.
cd /home
cambia hacia el directorio /home, lo que puede verificarse con el comando pwd.
cd
sin parámetros devuelve al usuario a su directorio propio, desde cualquier lugar donde esté.
Este comando es útil cuando se han hecho varios cambios de directorio y se quiere retornar a
una situación conocida, ubicándose en el directorio propio.
Listado de archivos.
Ensayemos el comando ls:
ls
lista archivos del directorio actual.
ls -l /bin
lista archivos en el directorio /bin; aquí se encuentran los archivos de comandos ejecutables
del sistema. No cambia de directorio; el directorio actual sigue siendo el mismo.
ls -l
lista archivos en formato largo, dando detalles. El -l se llama opción o bandera; se lee "menos
ele".
La salida obtenida consta de renglones parecidos a
-rw-rw-rw- 1 esteban users 138 Apr 5 19:34 leame
y se interpretan así:
-
indica el tipo de archivo de que se trata, con esta convención:
- archivo común,
d directorio,
l enlace o referencia a otro archivo.
rw-rw-rw
son los permisos del archivo;
r (read) permiso para leer el archivo
w (write) permiso para modificar o eliminar el archivo
x (execute) si se trata de un archivo, permiso para ejecutarlo como
programa; si se trata de un directorio, permiso para ingresar
en él y recorrerlo.
Los tres grupos de 3 caracteres indican permisos para el dueño del archivo (esteban), su grupo
(users) y el resto del mundo.
1
cantidad de enlaces, referencias a este archivo desde otros archivos ubicados en diferentes
lugares.
esteban
nombre del usuario dueño del archivo.
users
nombre del grupo al que pertenece el archivo
138
tamaño en bytes del archivo. Si se trata de un directorio, este número es de control del
sistema, sin interpretación inmediata para el usuario.
Apr 5 19:34
fecha y hora de última modificación. Si no aparece el año, se asume el año corriente.
leame
nombre del archivo. Notar que el nombre del archivo está siempre al final.
ls -a
muestra también archivos ocultos, normalmente no visibles en el listado. Los archivos cuyo
nombre empieza con un punto son ocultos, en este sentido. Las entradas . y ..
representan el directorio actual y el directorio padre, respectivamente.
ls -la
formato largo y archivos ocultos.
ls -la /var
listado de archivos visibles y ocultos en formato largo del directorio /var.
Manual de UNIX.
UNIX dispone de un manual en línea o "páginas man" con información sobre comandos,
archivos y otros elementos del sistema operativo. Aunque muy técnicas y a veces difíciles de
comprender, son una referencia obligada para operar con solvencia.
man ls
muestra la página man del comando ls, paginada para poder leer una pantalla por vez. Para
salir antes de terminar, digitar 'q'.
man man
muestra la página man del propio comando man.
man man > man.txt
redirecciona la salida y graba el contenido de la página man en el archivo man.txt, lo que se
puede verificar con ls.
Contenido de un archivo.
cat man.txt
muestra el contenido del archivo. El archivo man.txt, por provenir de una página man,
contiene muchos caracteres de control para regular su despliegue en pantalla. El comando cat
no intrepreta estos caracteres de control. El comando cat permite también concatenar
archivos, según se verá.
head man.txt
muestra las primeras 10 líneas de un archivo.
tail man.txt
muestra las 10 líneas finales de un archivo.
cat man.txt | more
lee una nota larga paginando; la salida de cat es tomada por more, que presenta la
información página por página. Para interrumpir el paginado de more, digitar 'q'. La tecla
espaciadora avanza una pantalla, la combinación de teclas Ctrl-B retrocede una pantalla.
more man.txt
presenta la información de man.txt ya paginada.
ls -l /etc | more
muestra el extenso contenido del directorio /etc paginando la salida.
Crear y borrar un archivo.
touch nota.vacia
crea el archivo nota.vacia, sin contenido alguno.
ls -l nota.vacia
muestra datos del archivo creado.
cat nota.vacia
no muestra nada, el archivo está vacío.
touch .archivo_oculto
crea un archivo vacío y oculto.
ls
no muestra el archivo oculto creado, pero
ls -a
sí lo muestra.
ls -la
muestra datos en formato largo del archivo oculto.
rm nota.vacia
borra el archivo nota.vacia. Como muchos comandos de UNIX, su nombre deriva de
palabras inglesas: rm proviene de "remove", eliminar o borrar.
rm -i man.txt
borrado interactivo, pide confirmación antes de actuar.
rm .archivo_oculto
ls -la
borra el archivo oculto y verifica listando los archivos del directorio.
echo Mensaje en pantalla
muestra en la pantalla la leyenda indicada.
echo Este es el archivo mensaje1 > mensaje1
direcciona la salida del comando echo y graba la leyenda en el archivo mensaje1.
ls -l mensaje1
cat mensaje1
muestra datos del archivo y verifica su contenido.
echo Esta línea es agregada >> mensaje1
echo Esta es otra línea agregada >> mensaje1
cat mensaje1
redirecciona la salida de echo para agregar dos líneas más al archivo ya existente mensaje1.
Verifica el contenido con cat.
Correo electrónico de UNIX.
Para leer el correo, digitar
Este comando ingresa al usuario en el sistema de correo electrónico de UNIX. Revisa la casilla
de entrada de mensajes mostrando la lista de recibidos. De ahora en adelante, sólo se aceptan
los comandos propios de mail. El indicador de comandos de mail es
&
Comandos disponibles dentro del sistema de correo:
d borra mensaje corriente, marcado con '>'
? muestra lista de comandos para manejo de mensajes
5 muestra el mensaje 5
h muestra la lista de mensajes
h 3 muestra la lista de mensajes comenzando en el 3
q sale del programa de correo
Para enviar un correo al usuario juan, desde la línea de comando de UNIX digitar
mail juan
Escribir entonces el texto del mensaje. Antes de llegar al fin de la pantalla, digitar <Enter> para
que cambie al otro renglón. El comando mail no es un editor: no arregla las líneas ni permite
corregir líneas anteriores. Al finalizar de escribir el mensaje, digitar
.
(un punto solo en una línea) y dar <Enter>. Un punto solo en la línea termina el mensaje y
devuelve al usuario a la línea de comandos de UNIX.
El usuario puede probar el correo enviándose un mensaje a sí mismo y luego leyéndolo.
mail juan esteban
envía mensaje al usuario juan y al usuario esteban.
mail -s "Mensaje de prueba" juan
envía un mensaje de prueba al usuario juan con el título "Mensaje de prueba". Es de cortesía
indicar siempre el tema del mensaje, para que el destinatario sepa inmediatamente de qué se
trata.
Existen en UNIX muchos programas para manejo de correo, más potentes y sofisticados; aquí
nos limitamos a mail como ejemplo de un comando de UNIX más bien artesanal, pero
siempre presente y útil para mensajería sencilla.
Usuarios en el sistema.
who
muestra los usuarios que están actualmente en el sistema. Indica identificador de usuario,
terminal en que está conectado, fecha y hora de ingreso al sistema.
who am i
da información sobre el usuario que está trabajando, indicando su máquina y nombre de
usuario, terminal, fecha y hora.
whoami
presenta sólo el nombre del usuario que está operando.
id
proporciona la identificación del usuario invocante, dando el nombre de usuario y su número
(UID), nombre de grupo primario y su número (GID), nombres de otros grupos a los cuales
pertenece (si los hay) y sus números.
id jperez
proporciona datos de identificación del usuario indicado (jperez).
finger
proporciona nombre del usuario en el sistema, nombre en la vida real y otros datos del usuario
invocante, indicando si está en este momento en el sistema, y si tiene correo por leer.
finger jperez
proporciona información sobre el usuario indicado.
Talk.
Talk es un programa que permite a dos usuarios en el sistema comunicarse escribiendo en el
teclado. Al invocar talk la pantalla se divide en dos partes, cada una correspondiente a uno
de los usuarios. Ambos pueden escribir simultáneamente, y ambos ven la salida en su parte
correspondiente de la pantalla.
talk usuario1
solicita apertura de una sesión de talk al usuario1, que debe responder con otro comando
similar cuando recibe el pedido.
Para terminar la sesión de talk, cualquiera de los usuarios puede digitar Ctrl-C.
El comando mesg permite regular si se desea recibir mensajes o no. Para evitar recibir
mensajes de talk es posible bloquear a otros usuarios el acceso a la terminal donde uno está
trabajando; quienes intenten iniciar una sesión recibirán un mensaje indicando que la terminal
destino no está habilitada para recibir mensajes.
mesg n
deshabilita recepción de mensajes,
mesg y
habilita recepción de mensajes.
mesg
muestra el estado: si responde "y" está habilitada la recepción, si responde "n" se rechazan los
pedidos de conexión.
Cambio de contraseña.
passwd
pide la vieja contraseña y luego la nueva; la nueva contraseña deberá ingresarse dos veces,
para evitar posibles errores de digitación. En sistemas con servicio de información de red (NIS),
el comando es
yppasswd
El administrador del sistema indicará cuál de estos comandos debe usar.
Fin de sesión.
exit
termina la sesión con UNIX, vuelve a presentar el mensaje inicial
login:
habilitando a un nuevo usuario a ingresar al sistema. Las teclas <Ctrl-D> también terminan la
sesión.
Otros.
Las teclas Ctrl-C interrumpen la ejecución de un comando. Las teclas Ctrl-D indican un fin
de ingreso; si se dan en el indicador de comandos, termina la sesión UNIX. En UNIX no hay un
caracter reservado para fin de archivo; Ctrl-D simplemente indica la terminación de un flujo
de datos.
En UNIX, la tecla <Enter> coloca un caracter nueva línea, que en ASCII es <Ctrl-J>;
con la tecla <Enter> DOS o MS-Windows colocan dos caracteres al final de una línea:
un nueva línea <Ctrl-J> y un retorno <Ctrl-M>. Al mirar un archivo creado en DOS o
MS-Windows con algunos programas UNIX se pueden llegar a ver caracteres '^M' al
final por esta razón.
Algunas terminales adminten un control instantáneo de la salida, con las teclas
<Ctrl-S> detiene despliegue.
<Ctrl-Q> continúa despliegue.
En las máquinas UNIX, el terminal de la propia máquina UNIX se denomina
"consola"; se usa preferentemente para administración del sistema. Todas las teclas de
control funcionan bien en la consola; el funcionamiento en los emuladores de terminal
depende de la construcción del programa de emulación.
ADMINISTRACION UNIX
Políticas, Procedimientos, Ética.
Políticas
Procedimientos
Etica y actitud
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 excluídos;
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.
El sistema de archivos
Concepto
Rutas y nombres
Montaje
Organización
Tipos de archivo
Permisos de un archivo
Propiedad de un archivo
Inodos
Ejercicios e Investigación.
Concepto. Es frecuente decir que en UNIX "todo es un archivo". Efectivamente, programadores y
desarrolladores han encontrado conveniente colocar en el espacio de nombres de
archivo entidades que no son propiamente archivos de datos: puertos seriales,
controladores de dispositivos, canales de comunicación entre procesos, porciones de
memoria compartida son vistos como archivos de datos, y en muchos casos manejados
con los mismos comandos. La ventaja de este enfoque reside, entre otras cosas, en la
posibilidad de usar llamadas al sistema uniformes cualquiera sea el dispositivo de
entrada salida referido. La redirección de entrada o salida de comandos es un ejemplo
de esta capacidad. Una extensión en otro sentido permite integrar a ese mismo espacio
de nombres unidades de almacenamiento masivo ubicadas en otras máquinas accesibles
a través de una red.
Tradicionalmente, el sistema de archivos es una abstracción usada por el kernel para
representar y organizar el almacenamiento de datos. Los dispositivos de
almacenamiento masivo de datos pueden ser de diferentes tipos: discos fijos, disquetes,
discos compactos. Los diferentes medios se integran en una estructura jerárquica única.
Esta estructura arranca en un directorio raíz designado con / y se extiende hacia abajo en
diversos niveles de subdirectorios. Las entidades no propiamente archivos se integran
en esta estructura jerárquica con naturalidad.
Un sistema de archivos comprende todas estas cosas:
un espacio de nombres: una forma de identificar entidades y organizarlas en una
estructura jerárquica;
una interfaz de programación de aplicaciones (API, Application Programming
Interface): un conjunto de llamadas al sistema para recorrer y manipular los
nodos de la estructura jerárquica. Una API es un conjunto de rutinas contenidas
en una biblioteca, un sistema operativo o un paquete de software, disponibles
para los programadores de aplicaciones a través de llamadas de función.
un modelo de seguridad: una forma de proteger, esconder, compartir
información con quienes deban disponer de ella, y solo con ellos.
una implementación: una forma de soportar el modelo lógico (los datos) sobre el
medio físico (los discos).
Los sistemas operativos actuales soportan diferentes formas de implementación de
sistemas de archivos, ya sea para leer y grabar en formatos propios de otros sistemas de
archivos (DOS, Windows, otros UNIX), como para acceder a diferentes medios (discos
compactos).
La expresión sistema de archivos puede referirse tanto a la estructura jerárquica
completa como a cada una de las partes de implementación homogénea que lo
componen. El árbol de directorios está formado por una o más de estas partes
homogéneas. En el caso de los discos, un sistema de archivos es una partición sobre la
cual se ha creado la estructura (el sistema de archivos) necesaria para contener los
archivos de datos.
Rutas y nombres.
La sucesión de directorios atravesados hasta alcanzar un nombre de archivo se
denomina ruta o vía (path). Ejemplo: /home/alberto/documentos/carta01.txt.
Una ruta es absoluta cuando arranca del directorio raíz: /bin/elvis. El directorio donde
está trabajando un usuario en el momento se denomina directorio actual. Una ruta es
relativa cuando arranca del directorio actual: documentos/carta01.txt.
No existen limitaciones para dar nombre a los archivos, salvo no usar el carácter / o
caracteres nulos. Para usar espacios en blanco, los nombres deben encerrarse entre
comillas, ya que el espacio en blanco actúa como separador en los comandos. touch "nuevo archivo"
crea un archivo del nombre indicado, con un espacio en blanco entre las dos palabras.
Para realizar cualquier operación sobre este archivo será necesario usar las comillas, o
escapar el carácter en blanco usando \: rm "nuevo archivo" rm nuevo\ archivo Ambos comandos borran el archivo.
Montaje.
Un sistema de archivos contiene un directorio principal, subdirectorios y archivos
soportados en un área de disco. Pueden adjuntarse otros sistemas de archivos al árbol de
directorios principal aplicando sobre un directorio del árbol principal el directorio
superior del sistema de archivos que se adjunta. El punto del árbol principal donde se
"cuelga" el sistema de archivos adjuntado se llama punto de montaje. Este artificio
permite disponer de un árbol único de directorios formado por partes en distintos
soportes locales o remotos. El comando mount habilita la operación de "colgar" un
sistema de archivos a un directorio del árbol principal.
mount /dev/sda0 /usuarios coloca el sistema de archivos almacenado en el disco /dev/sda0 bajo el directorio
/usuarios; para ver el contenido del sistema de archivos en disco, en lo sucesivo se hará ls /usuarios.
Un sistema de archivos se desvincula del árbol principal con el comando umount: umount /usuarios
desmonta el sistema de archivos anterior del directorio /usuarios, impidiendo el acceso a
los archivos contenidos en el disco. Para poder ejecutar umount no debe haber archivos
abiertos, ni usuarios en directorios de la rama a desmontar, ni procesos corriendo cuyos
ejecutables residan en él.
En la extensión semántica ya indicada, el término sistema de archivos se emplea así
para designar la totalidad del árbol de directorios, formado en realidad por partes de
diferente organización lógica y naturaleza física.
La lista de archivos montados en un sistema UNIX figura en el archivo /etc/fstab,
/etc/vfstab o /etc/checklist según la variedad de UNIX. Esto permite realizar tareas
sobre todos los sistemas de archivos, generalmente en el momento del arranque: fsck -p
verifica la integridad de todos los sistemas de archivos según figuran en /etc/fstab (o su
equivalente); mount -a monta todos los sistemas de archivos en /etc/fstab (o su equivalente).
Si el intento de desmontar un sistema de archivos fracasa por encontrarse éste ocupado,
el comando fuser indicará los números de proceso y los nombres de usuario que lo
ocupan. En FreeBSD, fstat hace algo similar.
Organización.
A través de las diferentes versiones de UNIX ha habido cierta confusión en cuanto a la
organización en directorios de los sistemas de archivos. No obstante, existen criterios
más o menos uniformes en cuanto a la ubicación de cada cosa. Es preferible respetar las
ubicaciones clásicas para evitar reconfigurar las aplicaciones.
Tipos de archivos.
Archivos comunes (regular files). Un archivo común es una secuencia de bytes. Su
contenido puede ser cualquiera: texto, imágenes, binarios ejecutables. UNIX no asigna
estructura alguna a los archivos comunes, aunque soporta acceso secuencial y aleatorio.
No hay caracter reservado para fin de archivo.
Directorios. Un directorio es un continente para nombres de archivos de cualquier tipo.
Las entradas . y .. designan el directorio actual y el directorio padre, respectivamente;
son visibles con ls -a. Un directorio se crea con mkdir; se borra con rmdir si está
vacío, y con rm -r si está lleno.
Un directorio puede contener dos nombres diferentes apuntando a la misma área de
datos, creando la ilusión de haber dos archivos cuando en realidad son solo uno con dos
entradas en el directorio. Este tipo de enlace se denomina enlace hard, enlace duro o
hard link, para distinguirlo del enlace simbólico explicado más adelante.
ln arch1 arch1.ln2 crea un segundo nombre arch1.ln2 dirigido a la misma área de datos del archivo arch1. rm arch1
borra la entrada de directorio arch1, pero no el área de datos. Esta permanece mientras
exista alguna entrada de directorio que la referencie. rm arch1.ln2 borra la entrada de directorio arch1.ln2 y el área de datos, ya que ésta era la última
referencia a ella.
Los "enlaces duros"solo actúan dentro de un mismo sistema de archivos. UNIX
mantiene un conteo de enlaces duros para no eliminar el archivo hasta que ha
desaparecido el último enlace a él. Este número es visible en la salida de ls -l,
después de los permisos.
Los enlaces hard no pueden hacerse sobre directorios, ni sobre otros sistemas de
archivos locales o remotos (no atraviesan "fronteras físicas").
Archivos de dispositivos de bloque y de caracter. UNIX se comunica con el hardware
y sus periféricos mediante módulos especializados en su manejo llamados controladores
de dispositivos (device drivers). Un controlador de dispositivo es visto en el sistema
como un archivo; esto provee una interfaz normalizada. Para dirigirse a un dispositivo
de hardware, el kernel solo debe referenciar el archivo controlador de dispositivo
correspondiente. Los controladores de dispositivos son de caracter cuando realizan por
sí mismos el manejo de emblocamiento (buffering). Los dispositivos de bloque manejan
porciones mayores de datos, dejando al kernel el manejo de emblocamiento. Los discos
y cintas pueden ser manejados por los dos tipos de controlador; un mismo dispositivo
físico puede tener así más de un controlador, operando de diferente forma según se lo
solicite a través de un controlador u otro.
Puede haber varias instancias de un mismo dispositivo. Los archivos de dispositivo se
definen a través de dos números un "mayor" para indicar el tipo de dispositivo, y un
"menor" para indicar la unidad física referida. Un terminal, por ejemplo, puede tener
mayor 12; entonces, ttya se describirá por 12 0, y ttyb por 12 1. Algunos dispositivos
usan el menor para indicar características del dispositivo. Un archivo de dispositivo se
crea con mknod y se elimina con rm. Suele existir un script llamado MAKEDEV,
usualmente en /dev, para crear los archivos de dispositivo correspondientes para
dispositivos comunes de hardware. Leer cuidadosamente este script antes de invocarlo;
no hacerlo si no se entiende bien como trabaja.
Sockets de dominio (BSD). 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.
Interconexiones nominadas ("Named pipes"). Al igual que los sockets de dominio,
las "interconexiones nominadas" ("named pipes") permiten la comunicación entre
procesos no relacionados corriendo en la misma máquina. Las interconexiones
nominadas se crean con mknod y se borran con rm.
Enlaces simbólicos. Los enlaces simbólicos ("symbolic links", "symlinks") es el
nombre de un puntero hacia un archivo. El enlace simbólico contiene la ruta hacia el
archivo; existe como tal, independiente del archivo al que apunta. Puede referenciar
archivos en otro sistema de archivos, o aún archivos inexistentes. Los enlaces
simbólicos pueden formar lazos, referenciándose mutuamente. Un enlace simbólico se
crea con ln -s y se borra con rm.
ln -s carta.txt /grupos/trabajos/carta12.txt crea en /grupos/trabajos un pequeño archivo llamado carta12.txt que solo apunta al
archivo carta.txt en el directorio actual. rm carta.txt
borra el archivo carta.txt; el enlace simbólico carta12.txt queda apuntando al vacío. rm /grupos/trabajos/carta12.txt borra el archivo enlace simbólico.
Pueden crearse enlaces simbólicos con rutas relativas; esto permite trasladar los
directorios superiores sin alteraciones: ln -s ../../ufs /usr/include/bsd/sys/ufs permite trasladar /usr/include sin afectar el enlace simbólico. Cuando se cambia a un
directorio que es un enlace simbólico, el comando pwd indica el nombre de directorio
del enlace, pero /bin/pwd indica el nombre del directorio real.
Los enlaces simbólicos pueden referirse a archivos en otros sistemas de archivos, o a
directorios.
Propiedad de archivos.
Todos los archivos están asignados a un dueño y un grupo. El dueño de un archivo es el
usuario que lo crea; el grupo de un archivo es el grupo primario al cual pertenece el
usuario que lo crea. El comando para modificar el dueño de un archivo es chown
(change owner). El comando para modificar el grupo asignado a un archivo es chgrp.
Permisos de archivo.
Los permisos de un archivo se refieren a la posibilidad de leer, escribir y ejecutar el
archivo. Existen 9 bits de permiso, más 3 que afectan el modo de operación de los
programas ejecutables. Este conjunto de 12 bits es el modo del archivo. El tipo de
archivo, fijado al momento de su creación, ocupa 4 bits más, completando una palabra
de 16 bits. Los bits de modo se modifican con chmod; los permisos se visualizan con ls
-l.
Setuid, setgid. Los valores octales 4000 y 2000 son los bits setuid y setgid. El bit setuid
permite ejecutar el programa con el dueño del archivo como propietario del proceso; el
bit setgid permite ejecutarlo con el grupo dueño del archivo como grupo propietario del
proceso. En algunos sistemas el bit setgid se usa en directorios para fijar el grupo dueño
igual al del directorio cuando se crea un nuevo archivo.
Sticky bit. El valor octal 1000 es el "sticky bit". Originalmente indicaba procesos que
debían permanecer en memoria; actualmente se usa en algunos sistemas para conferir a
los directorios compartidos la propiedad de impedir borrar archivos a otros que no sean
el dueño del directorio, el dueño del archivo o el superusuario.
Bits de permiso. Se agrupan en conjuntos de tres bits, representando permisos de
lectura, escritura y ejecución. Existen tres grupos de 3 bits, con los respectivos permisos
para el usuario, el grupo y otros. El significado de los permisos varía según se trate de
un archivo o un directorio:
Permiso Símbolo Binario Archivo Directorio
ninguno - 000 ninguno ninguno
lectura r 100 ver contenido ver nombres de archivos y
subdirectorios
escritura w 010 modificar contenido,
permisos
crear y eliminar archivos y
subdirectorios en el directorio
ejecución x 001 ejecutar el archivo
como programa
acceder al directorio (posicionarse en
él o invocar programas)
El uso del sistema octal permite codificar el grupo de permisos de 3 bits en un único
dígito octal para todas las combinaciones posibles de permisos:
Octal Binario Permisos
0 000 ---
1 001 --x
2 010 -w-
3 011 -wx
4 100 r--
5 101 r-x
6 110 rw-
7 111 rwx
Los permisos que recibe efectivamente un usuario se definen por uno de los tres
conjuntos de permisos: se verifica primero su condición de dueño (permisos de usuario,
primer conjunto de 3 bits): si el usuario es el dueño, recibe los permisos de dueño; si no
lo es, se examina su condición de integrante del grupo al que está asignado el archivo o
directorio (permisos de grupo, segundo conjunto de 3 bits); si el usuario pertenece al
grupo del archivo o directorio, recibe los permisos de grupo; si no es dueño ni pertenece
al grupo, recibe los permisos de otros (tercer conjunto de 3 bits).
El cambio de permisos se hace mediante el comando chmod. Este comando acepta tanto
la notación en octal como la notación simbólica mediante letras. Solo el dueño o el
superusuario pueden cambiar permisos.
Es posible fijar permisos por defecto para nuevos archivos o directorios al momento de
su creación, mediante el comando umask. Este comando acepta 3 dígitos octales que
representan los permisos a quitar. El valor por defecto suele ser 022: plenos permisos al
dueño, prohibe escritura a grupo y otros. No es posible imponer una umask a los
usuarios: éstos siempre pueden cambiarla. Es posible colocar una umask por defecto
inicial, en los archivos de inicialización del intérprete de comandos, por ejemplo .cshrc
o .profile.
Permisos recibidos por cada nuevo archivo o directorio según el valor de umask:
Octal Binario Permisos
0 000 rwx
1 001 rw-
2 010 r-x
3 011 r--
4 100 -wx
5 101 -w-
6 110 --x
7 111 ---
Inodos.
Parte
Indica
- tipo de archivo
rwxr-xr-x permisos de dueño, grupo y otros
1 cantidad de enlaces hard
root dueño
El núcleo mantiene la
información de archivos en
estructuras llamadas inodos.
La tabla de inodos se crea
cuando se crea el sistema de
archivos; su tamaño y
ubicación en el disco son fijos.
Los items de mayor interés contenidos en un inodo son cuenta de enlaces, dueño, grupo,
modo, tamaño, fecha de último acceso, fecha de última modificación, tipo de archivo.
Estos datos se hacen visibles con el comando ls -l. Una línea típica de salida para este
comando podría ser:
-rwxr-xr-x 1 root bin 279352 Mar 31 1997 /bin/bash
El primer caracter, para tipo de archivo, admite los siguientes significados:
Tipo de archivo Símbolo Creado por Eliminado por
archivo regular - editores, copia, comando touch rm
directorio d mkdir rmdir, rm -r
dispositivo de caracteres c mknod rm
dispositivo de bloques b mknod rm
socket s socket rm
interconexión nominada (named pipe) p mknod rm
enlace simbólico l ln -s rm
En los bits de permisos, si el setuid está puesto, la x del dueño aparece como s; si el
setgid está puesto, la x del grupo aparece como s; si el "sticky bit" está puesto, la x de
otros aparece como t; si en algún caso el permiso x está ausente, se muestran como S o
T, respectivamente, indicando la anomalía.
La salida del comando ls -l difiere cuando se trata de archivos de dispositivo; en este
caso se indican los números mayor y menor en lugar del tamaño: crw-rw-rw- 1 root tty 3, 176 May 20 1996 /dev/ttya0
La salida de ls -l para un enlace simbólico tiene este aspecto: lrwxrwxrwx 1 root root 279352 4 Aug 22 17:52 /bin/sh -> bash
El dueño se cambia con el comando chown, y el grupo con chgrp.
Manejo de discos.
UNIX maneja el espacio en disco en bloques; según los sistemas, un bloque tiene
típicamente 512 bytes o 1024 bytes. Un mismo disco puede contener varios sistemas de
archivos, incluso de distinto tipo, pero un mismo sistema de archivos no puede abarcar
varios discos. UNIX hace este hecho transparente al usuario: la jerarquía de directorios
bin grupo
279352 tamaño en bytes
Mar 31
1997 fecha
/bin/bash ruta y nombre
se ve como algo homogéneo. La confiabilidad del sistema aumenta si se definen
sistemas de archivos diferentes para /, /var, /usr, /home, /export:. el agotamiento de
espacio en un sistema de archivos diferente de / no produce un error fatal.
Especialmente /home y /var son propensos a llenarse. Es parte de las tareas rutinarias de
administración gestionar el espacio en disco.
El espacio libre en disco puede monitorarse por el comando df. Este comando muestra
el espacio utilizado y libre en cada sistema de archivos. Para determinar el espacio
utilizado por archivos o directorios, se dispone del comando du.
El siguiente comando permite encontrar los archivos mayores que 200 bloques: find / -size +200 -exec ls -l {} \;
La falla de un comando o aplicación genera un archivo denominado core. Estos archivos
pueden ser grandes. Denotan algún tipo de error en el sistema; su ubicación puede dar
una pista del origen, pero en general no son útiles para el usuario no especializado. El
siguiente comando lista los archivos core en el sistema: find / -name core -print
El comando siguiente los busca y borra sin preguntar nada: find / -name core -exe rm {} \;
Los archivos en /tmp pueden acumular espacio. Este directorio se reserva para archivos
temporales; un usuario o una aplicación no puede asumir la permanencia de estos
archivos. El administrador puede, en forma manual o automática, borrar los archivos
con más de cierta antigüedad. El siguiente comando encuentra los archivos de /tmp
modificados hace más de 10 días: find /tmp -mtime +10 -print
Ejercicios e Investigación.
1. Si su sistema dispone de algún programa de administración de archivos; explore con
él los primeros niveles del sistema de archivos. Los comandos ls y cd bastan a este
propósito.
2. Determine la situación de montajes en su sistema, usando mount.
3. Estudie los tipos de sistema de archivos que soporta su versión de UNIX, en
particular con soporte sobre disquete. Realice el montaje de un disquete sobre el punto
/mnt u otro; verifique que puede acceder a los archivos; luego desmonte el disquete.
4. Con el comando ln, experimente la creación de enlaces hard y simbólicos,
verificando con ls las características del enlace (ls -ld directorio) y su contenido
(ls -l directorio).
5. Experimente cambiar permisos con el comando chmod, tanto usando notación
numérica como simbólica.
6. Verifique el valor por defecto de umask. Cambie el valor de umask; verifique creando
archivos con touch.
7. Con los comandos ls y cd, explorar el directorio /dev o su equivalente, buscando
visualizar características de archivos de dispositivo.
8. Determine si su sistema soporta uso de sticky bit: cree un directorio, active el sticky
bit, verifique luego si otros usuarios pueden crear y borrar archivos en ese directorio.
9. Estudiar los comandos df y du, sus opciones y la forma en que dan la salida (bloques
o Kb).
10. Determine en qué archivo guarda sus sistema la lista de sistemas de archivos a
montar (/etc/fstab, /etc/vfstab, /etc/checklist, otro). Visualice el archivo con more.
Compare la situación de montajes con el contenido de ese archivo. ¿Puede interpretar
todos sus campos? Busque una página man sobre la estructura interna de este archivo.
Superusuario y usuarios especiales.
Control admnistrativo del sistema
Propiedad en UNIX
Propiedad de archivos
Propiedad de procesos
El Superusuario
Contraseña de root
Acceso a root
Usuarios especiales
Ejercicios e investigación
Control administrativo del sistema.
Salvo en los sistemas operativos para uso personal (MS-DOS, Windows, Macintosh), en todos
los sistemas operativos el control administrativo del sistema está fuera de las posibilidades de
acceso de los usuarios comunes. En los sistemas UNIX, una cuenta de usuario especial llamado
"superusuario" tiene los privilegios necesarios para realizar tareas tales como control de
procesos, creación de usuarios, agregado de dispositivos, fijar permisos de acceso a la
información y toda otra tarea que implique cambios en el sistema.
Propiedad en UNIX.
En UNIX, los procesos y archivos tienen asociado un usuario como dueño. El dueño de un
archivo es el usuario que lo crea. Un proceso es un programa en ejecución; el dueño del
proceso es el usuario que lo arranca. Los derechos del dueño sobre sus archivos y procesos
sólo pueden ser subrrogados por el superusuario. Tanto para archivos como para procesos
existe también un grupo al que ese proceso o archivo pertenece. Un grupo es un conjunto de
usuarios; un usuario puede pertenecer a varios grupos. Un archivo o proceso pertenece al
grupo primario o grupo principal del usuario que crea el archivo o arranca el proceso.
Propiedad de archivos.
Todo archivo tiene un usuario propietario y un grupo propietario. El propietario de un archivo
puede controlar los permisos de su archivo. Existe un juego de permisos de usuario para el
propietario de un archivo.
Todo archivo tiene también un grupo propietario. Existe un juego de permisos de grupo
para el grupo propietario de un archivo. Cualquier usuario miembro del grupo puede
realizar sobre el archivo las operaciones permitidas por los permisos de grupo asignados
a ese archivo.
Existe también un juego de permisos de otros para usuarios en general, que no sean
dueños del archivo ni pertenezcan al grupo del archivo.
El propietario y grupo de un archivo aparecen en la salida larga del comando ls: ls -l .
muestra dueño, grupo, permisos y otros datos de archivos en el directorio actual.
UNIX reconoce internamente a los usuarios y grupos mediante números. El número
idenfiticador de usuario se llama UID. La equivalencia entre UID y nombre de usuario
consta en el archivo /etc/passwd, donde figura también el grupo primario al que
pertenece el usuario. El grupo primario es el grupo al que se asigna al usuario en el
momento de su creación. El grupo primario es único para cada usuario.
El número identificador de grupo se llama GID. La equivalencia entre GID y nombre de
grupo consta en el archivo /etc/group, donde figuran también los integrantes de cada
grupo secundario. Los grupos secundarios son otros grupos a los que puede pertenecer
el usuario además de su grupo primario. Un usuario puede pertenecer a varios grupos
secundarios.
Propiedad de procesos.
El kernel (núcleo) de UNIX asocia a cada proceso cuatro números: UID real, UID efectivo, GID
real y GID efectivo. UID y GID reales se usan para fines contables; UID y GID efectivos para
determinar permisos de acceso. Generalmente los números reales y efectivos son los mismos.
No obstante, cuando un proceso ejecuta un nuevo programa haciendo uso de alguna de las
llamadas al sistema de la familia exec, el nuevo proceso generado puede correr con UID y GID
del archivo, eventualmente diferentes del UID y GID del usuario que invocó el proceso original.
Los bits setgid y setuid fijados en los archivos permiten correr procesos con los
permisos del dueño y grupo del archivo, y no de quien los invoca. Un ejemplo es el
comando passwd: para cambiar una contraseña se requiere permiso de superusuario: ls -l /usr/bin/passwd muestra los siguientes permisos -rwsr-xr-x 1 root root 28896 jul 17 1998 /usr/bin/passwd
Por tener fijado setuid, el proceso passwd correrá con permiso real del usuario que lo
invoca, pero con permiso efectivo de supervisor.
El Superusuario.
La administración del sistema requiere desconocer las medidas de protección de UNIX. Para
ello existe una cuenta especial con UID 0, por convención asociada a una cuenta de usuario de
nombre "root". El nombre puede ser cualquiera; lo decisivo es el UID 0.
El superusuario puede realizar cualquier operación posible sobre archivos y procesos;
muchas llamadas al sistema sólo pueden ser realizadas por el superusuario o tienen
opciones especiales para el superusuario no disponibles para los usuarios comunes. Las
llamadas al sistema son formas de solicitar servicios al kernel.
Ejemplos de operaciones restringidas al superusuario:
Montar y desmontar sistemas de archivos. Cambiar el directorio raíz de un proceso con chroot. Crear archivos de dispositivos. Fijar la hora del sistema Cambiar propiedad de archivos. Fijar límites al uso de recursos; fijar prioridades de procesos. Fijar el nombre propio de la máquina donde reside el sistema. Configurar interfaces de red. Cerrar el sistema.
Como ejemplo, el programa login, antes de recibir nombre y contraseña del usuario, corre
como root; una vez que el usuario es reconocido, el proceso cambia su UID y GID a los del
usuario y arranca el intérprete de comandos (shell) del usuario. Una vez que un proceso
adquiere UID y GID de usuario común no puede ya retornar a sus privilegios anteriores.
Contraseña de root.
En la contraseña de root reside toda la seguridad del sistema. Debe elegirse una contraseña
difícil de adivinar o descubrir. Una buena contraseña debe tener al menos 8 caracteres,
mezclar letras con números o símbolos, o combinar mayúsculas y minúsculas. Solía
recomendarse el uso de dos palabras al azar separadas por un símbolo como compromiso
entre la seguridad y la memorización; actualmente este esquema no ofrece seguridad. La
receta actual consiste en inventar una frase "de chocante sinsentido" fácil de recordar para el
usuario y armar la contraseña con las primeras letras de cada palabra. Agregar algún número o
carácter de puntuación aumenta mucho la seguridad de este tipo de contraseñas. Un ejemplo:
"No Pagar Software En 2001" genera la contraseña "npse2k1", muy difícil de violar, aunque la
frase no es chocante ni sinsentido. Estas "cualidades" se recomiendan para facilitar el recuerdo
de la frase.
La contraseña de root debe cambiarse:
al menos cada tres meses; cada vez que se retire alguien que la conoce; siempre que se sospeche una situación de inseguridad.
El olvido de la contraseña de root es un problema mayor: puede requerir ingresar al sistema
vía CD de instalación o disquete de arranque. Esto implica, obviamente, bajar el sistema.
Acceso a root.
La forma más inmediata de acceder a root es ingresar al sistema como el usuario root. Es
mejor usar el comando su, que permite asumir la identidad de root luego de pedir contraseña,
pero deja constancia del usuario que la asumió. Una buena medida de seguridad es
deshabilitar el acceso directo a root desde todas las terminales excepto la consola. La forma
segura de operar como root es ingresar al sistema como usuario común, hacer su solo para
realizar tareas administrativas, finalizando con exit enseguida de terminar, continuando la
sesión como usuario común. El comando su nombre_usuario permite asumir la identidad
de cualquier usuario si se conoce su contraseña; si ya se es root no pide contraseña. El uso de
su puede requerir pertenecer al grupo wheel, o estar limitado a ciertas terminales.
La sentencia sudo comando permite ejecutar el comando con privilegios de root, si el
nombre del usuario figura en el archivo /etc/sudoers. Este archivo lista nombres de
usuarios, comandos autorizados y máquinas donde pueden correrlos. Si estos datos
validan, se pide al usuario su contraseña y el comando ejecuta con privilegios de
supervisor.
# /etc/sudoers
#
# Alias para grupos de máquinas
Host_Alias LABSOFT=pino,aromo,ceibo,acacia
Host_Alias MEDIDAS=ombu,girasol,alamo
# Alias para comandos de respaldo
Cmd_Alias RESP=/usr/etc/dump, /usr/etc/restore
# usuario, máquinas, comandos permitidos
marcos LABSOFT=ALL,MEDIDAS=RESP
edgard LABSOFT=/usr/local/bin/tcpdump
mendez ALL=ALL
El archivo /etc/sudoers se modifica usando el comando visudo, capaz de validar la sintaxis
antes de grabar los cambios. Los comandos ejecutados con sudo se registran vía syslogd. Los
comandos a ejecutar vía sudo deben escribirse en /etc/sudoers con la ruta completa, para
evitar una posible sustitución fraudulenta.
Ventajas de sudo:
mejor contabilidad y registro; los operadores pueden trabajar sin privilegios ilimitados; la contraseña de root la conocen pocas personas; pueden revocarse privilegios sin cambiar contraseña de root;
es más rápido usar sudo que usar su o ingresar al sistema como root; existe una lista restringida de usuarios con privilegios; disminuye la probabilidad de dejar una sesión de root abierta; como depende de las máquinas, un sólo archivo sirve para controlar el acceso en toda
la red.
Riesgos:
la seguridad de un usuario puede comprometer la de root; sudo csh o sudo su evitan el registro de comandos; no deben habilitarse.
Usuarios especiales.
En UNIX existen cuentas de usuarios no humanos usadas por el sistema; suelen tener un
asterisco * en el campo de la contraseña en el archivo /etc/passwd o /etc/shadow, lo que
impide el ingreso por estas cuentas.
daemon: propietario de archivos y procesos propios del sistema operativo no
privilegiados, que sería inseguro conceder a root. Con el mismo propósito existe un
grupo daemon.
bin: propietario de directorios de comandos y de muchos de los propios archivos de
comandos. Actualmente existe la tendencia a dejar los archivos y directorios de
comandos propiedad de root.
sys: propietario de imágenes del kernel y la memoria, tales como /dev/kmem (espacio
de direcciones del kernel), /dev/mem (memoria física del sistema), /dev/drum o
/dev/swap (imagen del área de intercambio del sistema). Los programas que acceden
estos archivos lo hacen setuid a sys (corren con sys como dueño).
nobody: UID -1 o -2; -1 puede aparecer como 32767, lo que confunde a los programas
adduser cuando determinan el siguiente UID libre. En Linux la cuenta nobody tiene
UID 65534. Este usuario sin privilegios es útil para acceder archivos remotos vía red
usando NFS, el sistema de exportación de archivos de UNIX, así como para correr otros
comandos como finger donde sería riesgoso conceder privilegios aún de usuario común.
Usuarios habilitados a hacer uso de algún servicio del sistema sin estar registrados en él,
como en los servidores web, reciben la identidad nobody. La cuenta nobody no debe ser
propietaria de ningún archivo.
Creación de Usuarios
El archivo /etc/passwd
El archivo /etc/shadow
El archivo /etc/group
Crear usuarios
Edición de archivos.
Fijar contraseña inicial
Directorio propio del usuario
Copiar archivos de inicialización
Casilla de correo
Editar /etc/group
Información contable
Tabla de usuarios y guía telefónica
Fijar cuotas
Verificar la nueva cuenta
Eliminar usuarios
Inhabilitar cuentas.
Caducidad de contraseñas. Pseudo-logins.
Herramientas de administración de usuarios
Ejercicios e Investigación.
Bibliografía y referencias.
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 úlimo 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 adminstració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
.cshrc
fija alias de comandos, rutas de búsqueda, valor de umask, cdpath para
búsqueda de nombres de archivo; fija variables promtp, history, savehist
.logout imprime recordatorios, borra la pantalla
sh .profile
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 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
xrdb .Xdefaults fija configuración de X11 (sistema de ventanas): tipos de letra, colores, etc.
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 incluído en ".*"; éste es un
error común y peligroso.
Casilla de correo.
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.
Ejercicios e investigación.
1. Determine si su sistema dispone de herramientas de administración para la creación,
modificación y remoción de usuarios. Estudie la herramienta y pruébela críticamente en todas
sus posibilidades, asegurándose de su éxito o anotando sus fallas o carencias.
2. Determine si su sistema usa el archivo shadow. Verifique si existen las herramientas
vipw y vigr; estudie sus páginas man y pruébelas con sumo cuidado, asegurando
siempre el retorno a la situación original y la coherencia entre /etc/passwd y
/etc/shadow.
3. Construya un script para crear una lista de usuarios del sistema con sus datos
personales que pueda actuar como listín telefónico. Construya luego un script que reciba
como parámetro el nombre de usuario y responda con los datos personales
adecuadamente presentados o con un mensaje que indique la inexistencia de tal usuario.
Estudie la posibilidad de que esta lista se regenere automáticamente.
4. Determine si en su institución se respeta la "política de comas" para el campo
GECOS de /etc/passwd. Verifique el comportamiento del comando finger en esta
situación. Evalúe la conveniencia de respetar o imponer dicha política.
5. Cree un usuario de prueba. Construya un script que emita un mensaje o realice alguna
tarea sencilla. Asigne este script como shell por defecto en el usuario de prueba.
Verifique los resultados.
Bibliografía y Referencias.
Comandos: vi (editor), passwd, yppasswd, newgrp, sg, chsh, chfn, useradd, userdel, usermod,
adduser, groupadd, groupdel, groupmod, edquota, quot.
Archivos: /etc/passwd, /etc/shadow, /etc/group, /etc/shells.
Procesos.
Procesos Información almacenada por el kernel
o IDentificadores Process ID (PID) Parent Process ID (PPID) UID y EUID GID y EGID
o Información de ambiente Directorio actual Variables de ambiente globales. Variables de ambiente locales. Terminal de control.
o Información de E/S o Espacio de direcciones virtual o Estado de un proceso
Ciclo de vida de un proceso Threads Señales (signals) Prioridad de ejecución y valor "nice" Supervisión de procesos
o Averiguando qué pasa Comando ps (process status) Comando top Comando pstree Carga del sistema reportada por w o uptime Comando vmstat (virtual memory stats)
o Tomando acciones Ejercicios e investigación Bibliografía y Referencias
Procesos
Se le llama proceso en Unix a un programa en ejecución y al objeto abstracto que crea
el sistema operativo para manejar el acceso de ese programa a los recursos del sistema
(memoria, CPU, dispositivos de E/S). Pueden coexistir varias instancias de un mismo
programa ejecutando en forma simultánea. Cada una de ellas es un proceso diferente.
Unix es un sistema multiproceso por tiempo compartido. A los ojos de un usuario en un
momento dado hay múltiples programas en ejecución, cada uno de ellos avanzando en
su tarea. Sin embargo en una máquina con un solo procesador hay en cada instante
solamente un proceso ejecutando. Es el sistema operativo el que va rotando el uso del
procesador a intervalos breves (alguna decena de milisegundos) entre los procesos
definidos en el sistema de forma que se crea la ilusión que todos avanzan
simultáneamente.
El administrador del sistema dispone de herramientas para supervisar el estado de los
procesos y eventualmente tomar acciones para suspender o detener la ejecución de un
proceso o simplemente modificar su comportamiento.
Información almacenada por el kernel
Para cada proceso definido en el sistema, el kernel del sistema operativo almacena y
mantiene al día varios tipos de información sobre el proceso. Esta información podemos
ordenarla de la siguiente forma:
* Información general. Identificadores de proceso, usuario y grupo
* Ambiente (variables, directorio actual, etc.)
* Información de E/S
* Información de Estado
* Espacio de direcciones del proceso. Areas de trabajo (código ("text"), datos, stack)
IDentificadores
Process ID (PID)
Al crearse un nuevo proceso se le asigna un identificador de proceso único. Este número
debe utilizarse por el administrador para referirse a un proceso dado al ejecutar un
comando.
Los PID son asignados por el sistema a cada nuevo proceso en orden creciente
comenzando desde cero. Si antes de un reboot del sistema se llega al nro. máximo, se
vuelve a comenzar desde cero, salteando los procesos que aún estén activos.
Parent Process ID (PPID)
La creación de nuevos procesos en Unix se realiza por la vía de duplicar un proceso
existente invocando al comando fork(). Al proceso original se le llama "padre" y al
nuevo proceso "hijo". El PPID de un proceso es el PID de su proceso padre.
El mecanismo de creación de nuevos procesos en Unix con el comando fork() se ve con
más detalle en el apartado "Ciclo de vida de un proceso".
UID y EUID
Normalmente estos dos identificadores coinciden pero hay excepciones.
El User ID (UID) del proceso identifica al creador del proceso, esto es a la persona que
lo lanzó a correr. Este usuario y root son los únicos que pueden modificar al proceso. El
UID se utiliza con fines de tarificación o accounting. El sistema de accounting carga a la
cuenta del usuario identificado por el UID del proceso por los recursos del sistema que
el proceso utilice (tiempo de CPU, impresoras, terminales, etc.).
El Effective User ID (EUID) en cambio se utiliza para determinar si el proceso tiene
permiso para acceder a archivos y otros recursos del sistema.
La forma más habitual de hacer que el EUID de un proceso sea el de un usuario
diferente del que lanza a correr el programa es activando el flag setuid en el archivo del
programa. Un ejemplo de esto son los comandos que permiten a un usuario modificar su
password, en que se debe modificar el archivo passwd o equivalente del sistema sobre el
cual el usuario obviamente no tiene permiso de escritura. Habitualmente ese comando
es un archivo de root con setuid y el proceso corre con EUID de root.
GID y EGID
Es totalmente análogo a los identificadores de usuario pero para grupos de usuarios. El
GID se hereda del proceso padre. El EGID puede utilizarse igual que el EUID para
controlar el acceso del proceso a archivos.
En la mayoría de los sabores actuales de Unix el proceso puede estar en varios grupos y
se chequea contra toda la lista de grupos para definir si el proceso puede acceder o no a
un recurso.
Información de ambiente
Directorio actual
El proceso mantiene actualizado cual es su directorio de trabajo.
Variables de ambiente globales.
Son heredadas por los procesos hijos.
Variables de ambiente locales.
Solamente existen en el proceso que las define.
Terminal de control.
En general los procesos están asociados a una terminal de control. Esta terminal
determina el valor por defecto de los archivos stdin, stdout y stderr del proceso.
Una excepción a esto son los procesos llamados daemons, que una vez lanzados se
desvinculan de su terminal de control y siguen ejecutando inclusive después de cerrada
la sesión de usuario desde la cual se lanzaron a correr.
Información de E/S
El kernel mantiene descriptores de los archivos abiertos por el proceso.
Están siempre definidos los archivos de entrada, salida y error estándar (stdin, stdout y
stderr). Por defecto están asociados con el teclado y la pantalla del terminal de control
del proceso pero pueden ser redireccionados a un archivo cualquiera. Todos los shells
prevén un mecanismo para hacer este redireccionamiento en el momento de lanzar a
correr un programa.
Espacio de direcciones virtual
En la mayoría de los sistemas multiproceso como Unix, cada proceso tiene la ilusión de
disponer para si el espacio de direcciones completo del procesador. En realidad el
procesador ve un espacio de direcciones virtual. Este espacio está organizado en
secciones para el código (text), datos, stack y otras y generalmente está dividido en
páginas. En un instante dado una página puede estar residiendo en la memoria física del
procesador o puede estar almacenada en disco en un procedimiento llamado
"swapping". El sistema operativo, con el auxilio del hardware, mantiene al día una tabla
con el estado de cada página de memoria del proceso.
Estado de un proceso
Los estados básicos en los que puede estar un proceso son los siguientes:
* Durmiendo (asleep). En general a la espera de algún recurso compartido.
* Listo para ejecutar (runnable). A la espera que le toque el turno en el uso de la CPU.
* Ejecutando (running). Puede estar ejecutando en modo kernel o en modo usuario.
A su vez el proceso (o partes del espacio de memoria virtual del proceso) puede estar
cargado en memoria o "swapped" a disco.
Además de estos estados básicos un proceso puede estar detenido (stopped). En este
caso se le prohibe ejecutar al proceso. Hay mecanismos para detener y rearrancar un
proceso a través de las señales STOP y CONT que veremos más adelante.
El estado stopped es el estado en que queda un proceso lanzado a correr desde un
interprete de comandos (shell) cuando se presiona <Control-Z> o la tecla configurada
como "suspend" en el terminal que estemos utilizando.
Finalmente el otro estado en que a menudo un administrador encuentra a un proceso es
el estado zombie o exiting. Un proceso en este estado está en proceso de terminación.
Este caso se discute más en detalle en el apartado "Ciclo de vida de un proceso".
Ciclo de vida de un proceso
El mecanismo de creación de un proceso en Unix es un poco peculiar. Un proceso se
crea invocando a una función del sistema operativo llamada fork(). La función fork()
crea una copia idéntica del proceso que la invoca con excepción de:
* El nuevo proceso tiene un PID diferente
* El PPID del nuevo proceso es el PID del proceso original
* Se reinicia la información de tarificación del proceso (uso de CPU, etc.)
Al retorno de fork() se siguen ejecutando las siguientes sentencias del programa en
forma concurrente. Para distinguir entre los dos procesos la función fork() devuelve un
cero al proceso hijo y el PID del nuevo proceso al proceso padre. Normalmente el
proceso hijo lanza luego un nuevo programa ejecutando alguna variante de comando
exec(). En el recuadro puede verse un ejemplo del uso de fork.
kidpid = fork()
if (kidpid==0) {
/* soy el hijo, p. ej. lanzo un nuevo prog. */
exec(...)
}
else{
/* soy el padre */
...
wait() /* espero exit() del hijo */
}
Si este es el mecanismo para crear un proceso, entonces ¿quién lanza a correr el primer
proceso? Luego del boot del sistema el kernel instala y deja corriendo un proceso llamado init
con PID=1. Una de las funciones principales de init es lanzar mediante fork() intérpretes de
comandos que a su vez lanzarán los scripts de inicialización del sistema y los procesos de los
usuarios. Además de init el kernel lanza algunos procesos más cuyo nombre y función varía en
los diferentes sabores de Unix. A excepción de estos procesos lanzados por el kernel al inicio,
todos los demás son descendientes de init.
Normalmente un proceso termina invocando a la función exit() pasando como parámetro un
código de salida o exit code. El destinatario de ese código de salida es el proceso padre. El
proceso padre puede esperar la terminación de su proceso hijo invocando la función wait().
Esta función manda al padre a dormir hasta que el hijo ejecute su exit() y devuelve el exit code
del proceso hijo.
Cuando el proceso hijo termina antes que el padre, el kernel debe conservar el valor del exit
code para pasarlo al padre cuando ejecute wait(). En esta situación se dice que el proceso hijo
está en el estado zombie. El kernel devuelve todas las áreas de memoria solicitadas por el
proceso pero debe mantener alguna información sobre el proceso (al menos su PID y el exit
code).
Cuando el proceso padre termina primero el kernel encarga a init la tarea de ejecutar el wait()
necesario para terminar todo en forma ordenada. A menudo init falla en esta función y suelen
quedar procesos en estado zombie hasta un nuevo reboot. Dado que un proceso zombie no
consume recursos fuera de su PID, esto por lo general no provoca problemas.
Threads
Cambio de contexto entre procesos:
* código ("text")
* datos
* stack
* tablas varias
Varias secuencias de ejecución (threads) pueden agruparse en un proceso y compartir
algunos segmentos
Ventajas:
* simplifica cambio de contexto y comunicación
* facilita el uso de múltiples procesadores
Soportado por la mayoría de los SO actuales (Digital Unix, DEC OSF/1, Solaris 2, AIX,
HP-UX, SGI Irix, Linux)
Posix standard
Bibliotecas provistas por terceros
Señales (signals)
Las señales de Unix son un mecanismo para anunciar a un proceso que ha sucedido
cierto evento que debe ser atendido. La lista de posibles señales a comunicar a los
procesos está fija, con algunas variaciones de un sabor a otro de Unix.
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.
Para muchas de las señales la acción predeterminada consiste en terminar el proceso. En
algunos casos se genera además un core dump. Un core dump es un archivo con una
imagen del estado del sistema que permite al desarrollador de un programa diagnosticar
problemas con la ayuda de un debugger. Al usuario final de un programa esta imagen
rara vez le sirve de ayuda.
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
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.
Supervisión de procesos
Averiguando qué pasa
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
Tomando acciones
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)
Ejercicios e investigación
* Use el comando ps y analice la información obtenida. Experimente las diferentes
opciones de ps en su sistema.
* Experimente el comando kill. Ejecute comandos en background para tener "materia
prima" con qué jugar. Utilice ps junto con grep para averiguar el PID
* Consulte el man para saber como reacciona algún proceso daemon (p. Ej. named)
frente a diferentes signals
Bibliografía y Referencias
* man page de:
* ps, top, kill, nice, renice, vmstat
* Nemeth, "UNIX System Administration Handbook", cap 5. El libro rojo/violeta
* Frisch, "Essential Unix Administration", cap. 7. El libro "de la mulita"
Syslog y Archivos de registro de eventos.
Syslog y Archivos de registro de eventos o Rotación de archivos de log o ¿Dónde están los logfiles? o Algunos archivos importantes
wtmp y el comando who messages
o Syslog El daemon syslogd
Configuración de syslogd Limitaciones y depuración de errores
Ejercicios e Investigación Referencias y Bibliografía
Syslog y Archivos de registro de eventos
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 descripto 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 comunmente
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.
¿Dónde están los logfiles?
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 sisetma 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 reponde a la signal 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 descripto 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 bloquedo. Esto por lo general
produce el efecto de enlentecer violentamente el funcionamiento de la máquina,
situación que se revierte si desbloqueamos el terminal con <Control-Q>.
Ejercicios e Investigación Determine en su sistema donde están los diferentes archivos de registro de eventos
Averigüe quién y desde qué terminal trabajo en el sistema el día anterior
Identifique que política de rotación de archivos de tiene configurada su máquina
(identifique el script periódico que se encarga de eso, si utiliza algún comando especial
para eso (newsyslog p. ej.) lea el man de ese comando.
Modifique /etc/syslog.conf para hacer que determinados mensajes se escriban
también en la consola de su usuario. Pruébelo usando el comando logger. Retorne
luego a la configuración inicial!!!
Referencias y Bibliografía
Nemeth, Evi, "UNIX System Administration Handbook", cap. 12
Comandos: who, wtmp, utmp, newsyslog, compress, gzip, syslogd, syslog.conf, logger.
Arranque y Detención del Sistema.
Estudio de caso: Linux Debian/GNU
Arranque y detención "System V".
Niveles de arranque: /etc/inittab.
Algunos subdirectorios de /etc.
Plantilla para script rc.
Un script rc real: network.
Bibliografía y Referencias.
Arranque y detención "System V".
El esquema de arranque y detención del sistema en Linux Debian/GNU es del tipo
"system V". Todos los scripts que ejecutan tareas en el arranque o detención del sistema
se encuentran en el directorio /etc/init.d. Los directorios /etc/rcS.d, /etc/rc0.d, /etc/rc1.d,
/etc/rc2.d y /etc/rc6.d corresponden a cada uno de los posibles niveles o estados de
funcionamiento del sistema. Estos directorios sólo contiene enlaces simbólicos hacia los
scripts en /etc/init.d. Los nombres de estos enlaces simbólicos son significativos: la
primera letra es S o K, luego sigue un número de 2 cifras, y finalmente el nombre de un
script en /etc/init.d. Algunos ejemplos: K18netbase K20ppp K20exim S15netbase S20exim S25nfs-server
Dentro de un directorio, los scripts K se ejecutan primero. La K (de "kill", matar)
indica que el script correspondiente en /etc/init.d debe ejecutarse con la opción de
detención, "stop". Luego de ejecutados todos los scripts K, se ejecutan los scripts S. La
S (de "start", arrancar) indica que el script correspondiente en /etc/init.d debe ejecutarse
con la opción de arranque ("start").
El número de 2 dígitos regula el orden en que se ejecutan los distintos scripts; el número
puede estar repetido, cuando importa la precedencia.
Los distintos niveles en que puede funcionar el sistema se definen en el arthivo
/etc/inittab.
Niveles de arranque: /etc/inittab.
# /etc/inittab: init(8) configuration. # $Id: inittab,v 1.8 1998/05/10 10:37:50 miquels Exp $
# The default runlevel. id:2:initdefault:
# Boot-time system configuration/initialization script. # This is run first except when booting in emergency (-b) mode. si::sysinit:/etc/init.d/rcS
# What to do in single-user mode. ~~:S:wait:/sbin/sulogin
# /etc/init.d executes the S and K scripts upon change # of runlevel. # # Runlevel 0 is halt. # Runlevel 1 is single-user. # Runlevels 2-5 are multi-user. # Runlevel 6 is reboot.
l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 # Normally not reached, but fallthrough in case of emergency. z6:6:respawn:/sbin/sulogin
# What to do when CTRL-ALT-DEL is pressed. ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
# Action on special keypress (ALT-UpArrow). kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let
this work."
# What to do when the power fails/returns. pf::powerwait:/etc/init.d/powerfail start pn::powerfailnow:/etc/init.d/powerfail now po::powerokwait:/etc/init.d/powerfail stop
# /sbin/getty invocations for the runlevels. #
# The "id" field MUST be the same as the last # characters of the device (after "tty"). # # Format: # <id>:<runlevels>:<action>:<process> 1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 4:23:respawn:/sbin/getty 38400 tty4 5:23:respawn:/sbin/getty 38400 tty5 6:23:respawn:/sbin/getty 38400 tty6
# Example how to put a getty on a serial line (for a terminal) # #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100 #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
# Example how to put a getty on a modem line. # #T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3
Algunos subdirectorios de /etc.
init.d rc0.d rc2.d rc4.d rc6.d rc1.d rc3.d rc5.d rcS.d Contenido de /etc/rcS.d: README S20modutils S40network S55bootmisc.sh S05keymaps.sh S30checkfs.sh S45mountnfs.sh S55urandom S10checkroot.sh S35mountall.sh S50hwclock.sh S70nviboot S15isapnp S40hostname.sh Contenido de /etc/rc0.d: K01xdm K20gpm K20quota S20sendsigs K11cron K20isdnutils K25nfs-server S25hwclock.sh K12kerneld K20logoutd K30netstd_misc S30urandom K15netstd_init K20lprng K89atd S40umountfs K18netbase K20ppp K90sysklogd S90halt K20exim Contenido de /etc/rc1.d: K01xdm K20exim K20lprng K30netstd_misc K11cron K20gpm K20ppp K89atd K12kerneld K20isdnutils K20quota K90sysklogd K15netstd_init K20logoutd K25nfs-server S20single K18netbase Contenido de /etc/rc2.d: S10sysklogd S20gpm S20ppp S89atd S12kerneld S20isdnutils S20quota S89cron S15netstd_init S20logoutd S25nfs-server S99rmnologin S18netbase S20lprng S30netstd_misc S99xdm S20exim Contenido de /etc/rc6.d: K01xdm K20gpm K20quota S20sendsigs K11cron K20isdnutils K25nfs-server S25hwclock.sh K12kerneld K20logoutd K30netstd_misc S30urandom K15netstd_init K20lprng K89atd S40umountfs K18netbase K20ppp K90sysklogd S90reboot K20exim
Scripts en /etc/init.d: README hwclock.sh netbase reboot atd isapnp netstd_init rmnologin bootmisc.sh isdnutils netstd_misc sendsigs checkfs.sh kerneld network single checkroot.sh keymaps.sh nfs-server skeleton cron logoutd nviboot sysklogd exim lprng ppp umountfs gpm modutils quota urandom halt mountall.sh rc xdm hostname.sh mountnfs.sh rcS
Plantilla para script rc.
En la distribución Debian se exige que todos los paquetes de software tengan un script
rc con las opciones "start", "stop", "restart" y mensaje informativo de uso si no se dan
opciones. Se provee una plantilla modelo para la creación de estos scripts, a partir de la
cual el responsable de cada paquete estructura el script rc, que residirá en /etc/init.d, y
con el cual se gobierna el paquete.
#! /bin/sh # # skeleton example file to build /etc/init.d/ scripts. # This file should be used to construct scripts for
/etc/init.d. # # Written by Miquel van Smoorenburg <[email protected]>. # Modified for Debian GNU/Linux # by Ian Murdock <[email protected]>. # # Version: @(#)skeleton 1.8 03-Mar-1998 [email protected] #
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin DAEMON=/usr/sbin/daemon NAME=daemon DESC="some daemon"
test -f $DAEMON || exit 0
set -e
case "$1" in start) echo -n "Starting $DESC: " start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid \ --exec $DAEMON echo "$NAME." ;; stop) echo -n "Stopping $DESC: " start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \ --exec $DAEMON echo "$NAME." ;; #reload) #
# If the daemon can reload its config files on the fly # for example by sending it SIGHUP, do it here. # # If the daemon responds to changes in its config file # directly anyway, make this a do-nothing entry. # # echo "Reloading $DESC configuration files." # start-stop-daemon --stop --signal 1 --quiet --pidfile \ # /var/run/$NAME.pid --exec $DAEMON #;; restart|force-reload) # # If the "reload" option is implemented, move the "force-
reload" # option to the "reload" entry above. If not, "force-reload" is # just the same as "restart". # echo -n "Restarting $DESC: " start-stop-daemon --stop --quiet --pidfile \ /var/run/$NAME.pid --exec $DAEMON sleep 1 start-stop-daemon --start --quiet --pidfile \ /var/run/$NAME.pid --exec $DAEMON echo "$NAME." ;; *) N=/etc/init.d/$NAME # echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2 echo "Usage: $N {start|stop|restart|force-reload}" >&2 exit 1 ;; esac
exit 0
Un script rc real: network.
No todos los scripts rc requieren las opciones "start" y "stop"; algunos realizan tareas
siempre requeridas para el funcionamiento del sistema. El script rc "network" inicializa
la máquina para su entrada en la red
#! /bin/sh # # network Establish the network connection. # # Version: @(#)network 1.2 14-Nov-1996 [email protected] #
# Configure the loopback device. ifconfig lo 127.0.0.1 route add -net 127.0.0.0 dev lo
# Configure the ethernet device or start SLIP/PPP below. IPADDR="192.168.1.1" # Your IP address. NETMASK="255.255.255.0" # Your netmask. NETWORK="192.168.1.0" # Your network address. BROADCAST="192.168.1.255" # Your broadcast address (blank if
none). GATEWAY="" # Your gateway address.
/sbin/ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast
${BROADCAST} /sbin/route add -net ${NETWORK} [ ! -z "$GATEWAY" ] && /sbin/route add default gw ${GATEWAY}
Bibliografía y Referencias.
Sistema instalado Linux Debian/GNU 2.1.
Debian Policy Manual , http://www.debian.org/doc/debian-policy/
Páginas "Como" (HOWTO), en español, en el sitio web de Debian Argentina,
http://www.debian.org.ar/. Una excelente fuente de información para múltiples aspectos
de instalación y configuración, desde nivel elemental hasta nivel técnico muy
especializado.
Procesos Periódicos y Cron
Estilos de cron
Formato de archivos crontab
Precauciones y errores comunes
Aplicaciones más usuales
Limpieza de archivos (/tmp, core, otros)
Accounting
Manejo de archivos de registro de eventos (logs)
Chequeos periódicos de seguridad y de disponibilidad de recursos de red
Ejecución de procesos pesados fuera de horario más cargado
Otros comandos
Ejercicios e investigación
Comandos y archivos
Bibliografía y referencias.
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 1 a 7 o 0 a 6
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 dia 7, pero en algunos casos es el dia 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 un 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.
Aplicaciones más usuales
El grueso de las aplicaciones lanzadas desde cron tienen que ver la realización de tareas repetitivas de
administración. El agendar estas tareas para su realización automática minimiza la probabilidad de
errores y olvidos y automatiza a favor del administrador algunas de las tareas más tediosas. A
continuación se enumeran algunas de las aplicaciones más habituales de cron.
Limpieza de archivos (/tmp, core, otros)
En los sistemas Unix (y también en otros sistemas) suelen generarse archivos que son de poca o ninguna
utilidad para los usuarios y a menudo ocupan un área del disco no despreciable. El caso más notorio es
el de los "core dumps" que se generan cuando un programa falla. Un core dump es un archivo que se
guarda en el directorio actual del proceso que "hace crash" con el nombre de core, y contiene una copia
de la memoria y el estado del procesador en el momento del "crash". Con la ayuda de un debugger, el
archivo core permite al desarrollador del programa que falla reconstruir la situación en el momento de
la falla y detectar cual fue el problema. Para los usuarios finales sin embargo el archivo core solamente
significa malgastar espacio en disco. Se utiliza el comando find para recorrer el sistema de archivos y
borrar los archivos no deseados. En el siguiente ejemplo:
find / -xdev -name core -atime +7 -exec rm -f {} \;
se borran todos los archivos de nombre "core" que no han sido accedidos en los últimos 7 días. El
parámetro -xdev impide que la búsqueda se extienda más alla del sistema de archivos donde se inicia la
búsqueda.
Por diversos problemas las aplicaciones suelen dejar sin borrar archivos temporales. El administrador
debe estar atento a detectar situaciones de este tipo que se den en su sistema, identificar los nombres de
los archivos a borrar y agregar una línea similar en el crontab.
Otros archivos candidatos a ser borrados periódicamente por el administrador son el contenido de /tmp o
/var/tmp.
Accounting
Si se trabaja en un entorno en que se cobra a cada usuario por la utilización de los recursos, la
información de accounting debe resumirse y archivarse periódicamente. Incluso en sistemas donde no
se cobra por uso de recursos la información de accounting puede utilizarse para diagnosticar problemas
o hacer previsiones de necesidades de ampliaciones del sistema.
Manejo de archivos de registro de eventos (logs)
La mayoría de los servicios que corren en un sistema Unix dejan un registro de los eventos importantes
que van sucediendo en archivos de texto. El tamaño de estos archivos está siempre creciendo por lo que
se deben tomar acciones para borrar o archivar los datos más antiguos.
Chequeos periódicos de seguridad y de disponibilidad
de recursos de red
Dependiendo de la importancia que tenga para la organización la seguridad, suelen ejecutarse chequeos
diarios buscando posibles brechas en la seguridad del sistema. Así por ejemplo puede mantenerse una
lista de los archivos con setuid y en caso de detectar un cambio reportarlo vía e-mail al administrador.
Otro chequeo periódico puede hacerse para generar alarmas en caso de detectar que un recurso en la red
no está disponible. Así por ejemplo puede hacerse ping a intervalos de 15 minutos hacia los servidores
importantes de una organización y en caso de detectar una falla reportar una alarma a un pager.
Ejecución de procesos pesados fuera de horario más
cargado
Un ejemplo de esto es la realización de respaldos durante la madrugada, en horarios de baja actividad
del sistema de archivos. Otro ejemplo es agendar el download de algún archivo muy grande desde
Internet para ser ejecutado en horarios en que la utilización del ancho de banda de los enlaces sea
menor.
Otros comandos
Otros comandos que permiten lanzar un comando o programa automáticamente son el comando at y el
comando batch.
El comando at permite agendar la ejecución de una tarea para que sea realizada una única vez. En la línea
de comando debe pasarse la fecha y hora a la que debe ser ejecutada la tarea. El uso del comando at es
preferible frente al uso del cron cuando el comando se ejecutará solamente una vez. También puede
usarse at para poner a punto un comando que luego se va a incorporar al crontab para su ejecución
periódica.
Por medio del comando batch se puede encargar la ejecución de una tarea. En este caso no se especifica
fecha y hora de ejecución sino que la tarea será atendida cuando el sistema se encuentre suficientemente
descargado.
Ejercicios e investigación
Determinar que estilo de cron está instalado en su sistema. Examinar el man del comando crontab e incluir un comando (p. ej. un mail a sí mismo) para la
siguiente noche. Ponerlo a punto utilizando el comando at. No olvidar quitar el comando del crontab al día siguiente
Comandos y archivos
/etc/crontab y /var/cron/tabs comandos cron y crontab at, batch
Respaldo.
El respaldo de datos
Dispositivos y medios
Régimen de respaldo incremental
Respaldo de un sistema de archivos
Niveles de respaldo incremental
Esquema de respaldo
Elección de un esquema
Recomendaciones generales
Restaurar archivos
Restaurar sistemas de archivos
Otros comandos de respaldo
Amanda
Ejercicios e Investigación
Bibliografía y referencias.
El respaldo de datos.
En la inmensa mayoría de los sistema informáticos, 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:
Medio Capacidad Reuso Acceso
aleatorio Comentarios
Disquete 1.44/2.8
MB Sí Sí
muy común; poca capacidad, incómodo; poca
duración (2 años); útil para respaldo de archivos de
configuración o transferencia de archivos chicos; alto
costo por MB
Zip 100/250
MB Sí Sí
bastante común; varias interfaces de conexión; alto
costo por MB
CD-R 650 MB No Sí
muy común; varias interfaces de conexión; menor
duración que CDs pregrabados, mucho mayor 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
DVD-R 4.7 a 17
GB No Sí Aún poco común; U$S 5 el de 4.7GB.
Jaz, Orb ~2 GB Sí Sí discos removibles; buena velocidad de transferencia
Cinta 8 mm 7 GB Sí No cinta video formato chico; las unidades suelen ser
llamadas Exabyte
Cinta 4 mm
DAT/DDS 20 GB Sí No
DDS (Digital Data Storage) es similar al DAT (Digital
Audio Tape) para audio; original 2 GB, DDS-4 en 20
GB; buena velocidad de transferencia; tamaño
reducido
Disco fijo 40 GB Sí Sí muy común; excelente transferencia, bajo costo; 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 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 innúmeras 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 3 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.
Amanda.
Amanda (Advanced Maryland Automatic Network Disk Archive) es un software para respaldo
de red capaz de actuar en una LAN hacia una unidad de cinta ubicada en un servidor,
cumpliento todas las exigencias deseables para un administrador. Usa dump y restore como
comandos de base, pero también puede manejar tar de GNU y smbtar de Samba para
respaldar datos de máquinas Windows. Corre en muchas versiones de UNIX, soporta extensa
variedad de hardware, permite compresión sobre el cliente antes de la transferencia, graba
registros completos del respaldo en la cinta. Amanda es software libre, escala bien, es muy
configurable, evoluciona rápido; está siendo usado extensamente en todo el mundo.
Ejercicios e Investigación.
1. Imagine la peor contingencia posible para su organización: la destrucción total del lugar.
Considere su disponibilidad de respaldos: determine qué información puede recuperar, con
qué esfuerzo, y en cuánto tiempo podría tener el sistema de nuevo en marcha, incluyendo la
necesidad eventual de adquirir hardware. ¿Está satisfecho con las respuestas?
2. Estudie los comandos de respaldo disponibles en su sistema. Realice una prueba
sobre la unidad de respaldo de que disponga. Si se dispone de un sistema de archivos
separado para /var puede ser conveniente usarlo, sobre todo si no es muy grande.
Restaure sobre un directorio borrador, cuidando no alterar el original.
3. Estudiar los comandos tar y/o cpio disponibles en su sistema. Estos comandos
tienen muchas opciones, diferentes según los sistemas. Aún la misma opción puede
actuar diferente en distintos sistemas. Probar con un grupo de archivos pequeño. No se
requiere disponer de una unidad de cinta o específica de respaldo, ya que se pueden usar
archivos en disco o aún la unidad de disquete. Asegurarse de poder respaldar, listar los
archivos de un archivo de respaldo, recuperar todos o uno de los archivos contenidos en
el archivo de respaldo.
4. Estudiar el comando dd y sus opciones de conversión. Probarlo para copiar un
archivo, o para tranferirlo hacia una cinta o un disquete.
5. Diseñe una estrategia para implementar un esquema de respaldo incremental en base
a tar o cpio. Algunos sistemas no disponen de dump/restore; en esos casos, tar y/o
cpio ofrecen facilidades para implementar el respaldo incremental manualmente o a
través de scripts. Algunos sitios que disponen de dump/restore igualmente prefieren
usar tar o cpio por la mayor tolerancia a actividad en el sistema
TCP/IP y Enrutamiento
TCP/IP
Paquetes
Direccionamiento de paquetes
Direcciones en Internet
ARP, RARP, BootP, DHCP - Relación entre direcciones
Enrutamiento
Protocolos de enrutamiento
Redirecciones ICMP
Subredes
CIDR: Classless Inter-Domain Routing
Elección de una estrategia de enrutamiento
Configuración de una red
Obtener y configurar las direcciones IP
Configurar las interfaces de red: ifconfig
Configurar rutas estáticas: route
Configuración dinámica estándar: routed
Configuración para el arranque automático
Diagnóstico de fallas de red
Ver si las máquinas están vivas: ping
Estado de la red: netstat
Encaminamiento de paquetes: traceroute
Monitores de tráfico: tcpdump, snifit, snoop, etherfind.
Inspección de tablas de ARP
TCP/IP y Enrutamiento
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
Red Comunicación básica, direccionamiento y
enrutamiento IP, ICMP
Transporte Comunicación extremo a extremo entre
programas TCP, UDP
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 Header IP Header UDP Header Datos de la aplicación Ethernet 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
0.0.0.0 164.73.224.28 0.0.0.0 UG 0 0
0 eth0
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 comunmente. 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
64 bytes from 164.73.224.30: icmp_seq=1 ttl=255 time=0.568 ms
64 bytes from 164.73.224.30: icmp_seq=2 ttl=255 time=0.573 ms
64 bytes from 164.73.224.30: icmp_seq=3 ttl=255 time=0.570 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
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
^C
--- acer.iie.edu.uy ping statistics ---
7 packets transmitted, 0 packets received, 100% packet loss
#
La salida detallada en caso de éxito, contiene la dirección IP de la máquina destino, la
secuencia de los paquetes ICMP y el tiempo de ida y vuelta de las respuestas.
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 protocolos 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
Proto Recv-Q Send-Q Local Address Foreign
Address (state)
tcp 0 0 ampere.1946
obelix.unicamp.b.http ESTABLISHED
tcp 0 0 ampere.3128
plata.1116 ESTABLISHED
tcp 0 0 ampere.1945
obelix.unicamp.b.http ESTABLISHED
tcp 0 0 ampere.1944
obelix.unicamp.b.http ESTABLISHED
tcp 0 0 ampere.pop3
chui.1065 TIME_WAIT
....
....
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 ed1
....
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
protocols 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.
Distribución de archivos - NIS.
Administración de máquinas en red
Archivos de configuración
Distribución de archivos
rdist
rsync
expect
NIS, servicio de información de red
Netgroups
NIS y archivos locales
Ventajas y desventajas de NIS
Funcionamiento de NIS
Comandos y demonios de NIS
Implantación de un domino NIS
NIS+
LDAP
Ejercicios e Investigación
Bibliografía y referencias.
Administración de máquinas en red.
La configuración de una máquina UNIX depende de un cierto número de archivos de texto.
Mantener la configuración de un sistema formado por una red de máquinas UNIX equivale a
mantener coordinados los ajustes de estos archivos de configuración en todas las máquinas.
En cuanto el número de máquinas involucradas aumenta un poco la tarea empieza a hacerse
difícil. En organizciones medianas o grandes suele haber grupos de máquinas de configuración
similar, lo cual permite usar archivos de configuración similares entre máquinas del mismo
grupo.
Existen dos enfoques básicos para manener la configuración de máquinas en una red:
instalar una copia maestra de los archivos de configuración en una máquina y distribuírla hacia las otras por copia. Esto es simple y funciona en todos los sistemas, pero es preciso distribuir los archivos periódicamente o ante cada modificación.
prescindir de los archivos de configuración locales e implementar un servidor central de configuraciones al cual se referirán todas las máquinas. No es una solución simple, pero no hay problemas de actualización, ya que todas las máquinas toman su configuración del servidor central. En contrapartida, el mal funcionamiento del servidor central puede colgar toda la red.
Han habido múltiples intentos de crear bases de datos para la administración de máquinas en
una red. Ninguna es aún completamente satisfactoria: cuando son seguras y escalables
resultan difíciles de implementar; las soluciones simples no ofrecen buena seguridad y tienen
un alcance limitado.
Archivos de configuración.
De la multiplicidad de archivos de configuración existentes en una máquina UNIX, sólo pueden
ser compartidos entre diferentes máquinas algunos de ellos. Los archivos más comúnmente
compartidos son:
Archivo Función
/etc/passwd base de datos de información de cuentas de usuarios
/etc/shadow1 contraseñas encriptadas de usuarios, caducidad de contraseñas
/etc/group definición de grupos UNIX
/etc/hosts mapeo de nombres a direcciones IP de máquinas
/etc/networks1 asocia nombres en texto con direcciones de red IP
/etc/services lista los números de puerto para servicios de red bien conocidos
/etc/protocols mapeo de nombres en texto a números de protocolos
/etc/ethers1 mapeo entre direcciones Ethernet y nombres de máquinas
/etc/aliases nombres usados como alias para correo electrónico
/etc/rpc lista los números de identificación de servicios RPC (Remote Procedure
Control)
/etc/netgroup1 define colecciones de usuarios, máquinas y redes
/etc/printcap base de datos de información de impresoras
/etc/termcap base de datos de tipos de terminal
1. No usado en todos los sistemas.
El uso de estos archivos se implementa a través de funciones definidas en la biblioteca
estándar de C. El archivo /etc/passwd es accedido por las funciones getpwuid,
getpwnam, getpwent; estas funciones manejan el archivo /etc/passwd devolviendo al
programa de usuario la información solicitada. Para pasar de un sistema de consulta
directa de archivos a una base de datos compartida alcanza con modificar estas rutinas
de la biblioteca.
Distribución de archivos.
La solución de copiar los archivos de configuración a todas las máquinas puede no ser
elegante, pero es simple, funciona en todo tipo de máquinas, es fácil de implementar y
mantener, minimiza la interdependencia entre máquinas, se adapta bien a grupos de
máquinas de configuración similar (secciones, departamentos, institutos). Cuando un
problema puede resolverse de manera simple debe haber buenas razones para implementar
una solución compleja.
El procedimiento de distribución consiste en copiar periódicamente los archivos de
configuración desde un servidor maestro hacia todas las demás máquinas. Existen dos
esquemas posibles:
por empuje (push): el servidor maestro copia periódicamente los archivos modificados hacia las restantes máquinas, lo quieran éstas o no. Mantiene los archivos en un sólo lugar, permitiendo un buen control de su contenido. Las máquinas cliente deben permitir al servidor maestro el acceso; esto deja una brecha de seguridad.
por descarga (pull): las máquinas cliente se actualizan a voluntad desde el servidor maestro. Es menos centralizado, pero es más seguro y funciona aún a través de fronteras con diferentes políticas o autoridades administrativas.
rdist
El comando rdist funciona en base a un archivo de texto donde se establecen los archivos a
distribuir; la ejecución de rdist copia hacia los destinatarios los archivos desactualizados,
optimizando la transferencia y conservando los atributos. Permite incluso ejecutar comandos
en la máquina remota para activar los cambios incluídos en el archivo recientemente copiado.
rdist ofrece problemas de seguridad: corre sobre rsh, confiando en su esquema de
autenticación. Debe implementarse, al menos, un "TCP wrapper", para limitar el
contacto con rlogind a una lista de máquinas. rlogind es el servidor para rsh, rcp y
rlogin, necesario también para rdist. Correr rlogind abre las máquinas a diversos
tipos de ataque. En Linux es posible sustituir rsh por ssh, aunque corriendo sin
contraseña; no es lo mejor, pero ofrece dos ventajas: ssh usa criptografía de clave
pública para autenticar el anfitrión maestro, y encripta todo el intercambio realizado por
rdist, eliminando la posibilidad de espionaje sobre la transferencia.
Ejemplo de archivo de distribución:
# definición de variables ARCH_SIST = (/etc/passwd /etc/group /etc/mail/aliases) MAQS_TODO = (alamo pino baobab) MAQS_ALGO = (gingko arauca)
# máquinas que reciben todos los archivos todo: {$ARCH_SIST} -> ${MAQS_TODO} notify jperez; special /etc/mail/aliases "/usr/bin/newaliases";
# máquinas que reciben algunos archivos algo: {$ARCH_SIST} -> ${MAQS_ALGO} except /etc/mail/aliases notify mlopez@alamo;
Bajo el rótulo todo se indica copiar los archivos en ARCH_SIST hacia las máquinas
MAQS_TODO, notificando por correo electrónico a jperez en las máquinas destino, y
ejecutando luego el comando /usr/bin/newaliases. Bajo el rótulo algo se copian los
archivos en ARCH_SIST menos /etc/mail/aliases, y se notifica al usuario mlopez en la
máquina alamo.
rsync
rsync es una versión potenciada de rcp capaz de conservar enlaces, permisos y fechas de
modificación. Es más seguro que rdist: permite restringir acceso remoto a ciertos directorios,
y exigir al maestro una contraseña; puede correrse desde inetd, o también usando ssh. Por
ejemplo, el comando rsync -gopt --passwdord-file=/etc/rsync.pwd \ /etc/passwd gingko::/etc
transfiere el archivo /etc/passwd a la máquina gingko conservando permisos, dueño y fechas
de modificación (-gopt); el doble :: en gingko::/etc obliga a contactar a rsync en el
servidor remoto directamente en el puerto 873 en lugar de usar rsh; la conexión se autentica
por la contraseña contenida en el archivo /etc/rsync.pwd.
La configuración de rsync demanda varias tareas, tanto en servidores como en clientes.
En Linux viene con la distribución; los fuentes pueden bajarse de rsync.samba.org.
expect
Un sistema de actualización por parte del cliente puede implementarse colocando los archivos
en un directorio accesible vía ftp y empleando el comando expect para automatizar el
proceso. expect es un conjunto de extensiones para el lenguaje de scripts Tcl (Tool Command
Language), de sintaxis relativamente simple; no se requiere mucho conocimiento de Tcl para
usar expect.
Ejemplo de srcript Tcl para expect:
spawn /usr/bin/ftp servidor_red while 1 { expect {
"Name: " {send "cliente_red\r"}
"Password: " {send "cliente_contraseña\r"} "ftp> " {break} "failed" {send_user "Login rechazado.\r"; exit 1}
timeout {send_user "Tiempo inactivo.\r"; exit 2} }} send "lcd /etc\r" expect "ftp> " {send "cd pub/sisarchs\r"} expect "ftp> " {send "get passwd\r"} expect "ftp> " {send "quit\r"; send_user "\r"} exit 0
El script arranca un proceso ftp sobre el servidor de red, iniciando el login de un cliente
con contraseña; se capturan e informan errores de login e inactividad; finalmente, se
emiten comandos ftp uno a uno hasta cerrar la sesión.
Los fuentes de expect están disponibles en expect.nist.gov.
NIS, servicio de información de red.
NIS fue la primera base de datos administrativa para sistemas informáticos. Lanzado por Sun
en los '80 con el nombre de Yellow Pages (páginas amarillas, en análogo con las de la guía
telefónica), hubo de cambiar este nombre por ser marca registrada en Inglaterra, pero muchos
comandos siguen comenzando por yp. A comienzos de los '90 Sun implementó NIS+ como
sustituto de NIS, agregando mayor seguridad. No obstante la similitud de nombres, se trata de
dos sistemas totalmente diferentes, incompatibles entre sí. NIS+ puede dar servicio limitado a
clientes NIS si se le indica, aunque se pierde la seguridad intrínseca de NIS+. Linux y FreeBSD
no soportan NIS+; Solaris y HP-UX soportan NIS+; todos soportan NIS.
NIS proporciona el mismo nivel de control que la copia de archivos. Se designa una
máquina como servidor maestro NIS. Allí se mantienen como copias autoritativas los
archivos de configuración, en el mismo formato y lugar, editándolos con un editor de
texto como habitualmente.Un proceso servidor hace disponibles el contenido de estos
archivos hacia la red. El conjunto de un servidor maestro NIS y sus clientes se
denomina un "dominio NIS". No debe confundirse con el "dominio DNS", algo
totalmente distinto, y menos con el concepto de dominio en Windows NT/2000.
Para mejorar la eficiencia en las búsquedas, los mapas NIS son preprocesados por las
rutinas de "hashing" ndbm (gdbm en GNU): luego de editar los archivos en el servidor
maestro, NIS los convierte al formado ndbm; esto se hace invocando make en el
directorio de NIS, o un script llamado ypmake en algunos UNIX. El formato ndbm
admite sólo una clave para cada entrada, por lo que un archivo de sistema puede dar
lugar a varios mapas NIS: el archivo /etc/passwd genera los mapas passwd.byuid,
ordenada por uid, y passwd.byname, ordenada por nombre de usuario.
NIS permite replicar sus mapas en uno o más servidores esclavos. Esto aligera la tarea
del servidor maestro y mantiene la red en funcionamiento cuando el servidor maestro no
está disponible. Cuando se modifican los mapas en el servidor maestro, éstos son
empujados hacia los servidores esclavos. Para el cliente, un servidor esclavo es
indistinguible de un servidor maestro. Los clientes ubican los servidores NIS por
difusión. Debe haber un servidor NIS por cada subred. Si no hay servidor NIS activo en
una red, los clientes pueden quedar colgados. El comando ypset permite apuntar un
cliente hacia un servidor específico.
Grupos de red ("netgroups").
Los grupos de red, "netgroups" o "netgrupos" son una forma abreviada de designar un
conjunto de usuarios, máquinas y redes para su referencia en otros archivos del sistema. Se
definen en /etc/netgroup; son compartidos como un mapa NIS de prioridad global. El
formato de una entrada en /etc/netgroup es
nombre_grupo lista_miembros
La lista de miembros es un conjunto de tríadas (máquina, usuario, dominio) separadas por
espacios; la ausencia de máquina, usuario o dominio implica todos; un signo - indica ninguno.
La situación típica en la realidad es definir los grupos por máquinas:
oficina15 (valizas,,) (lantis2,,)
oficina17 (colorado,,)
servidores (ampere,,) (maxwell,,) (gauss,,) (ohm,,)
admins oficina15 oficina17
Los netgrupos pueden usarse en /etc/exports, /etc/hosts.equiv y .rhosts; en
/etc/passwd puede usarse incluyendo +@netgrupo en una línea aislada. Colocar + en
/etc/hosts.equiv es una enorme brecha de seguridad, como puede también serlo el uso
de netgrupos en este archivo y en .rhosts. El uso más frecuente es en /etc/exports, para
definir conjuntos de máquinas habilitadas para montar recursos vía NFS.
NIS y archivos locales.
En la mayoría de los sistemas NIS puede ser suplementado por la información local del cliente,
al menos para algunos archivos. El enfoque tradicional admite dos tipos de situación:
prioridad local: los archivos locales tienen precedencia sobre NIS; prioridad global: NIS tiene precedencia sobre los archivos locales.
Usualmente, sólo /etc/passwd y /etc/group tienen precedencia sobre NIS. En estos casos,
el contenido de los mapas NIS para usuarios y grupos debe ser incluídos en los archivos locales
a través de una convención: un signo + aislado en una línea de /etc/passwd o /etc/group
incorpora todo el mapa NIS a los usuarios o grupos locales; una línea con +@netgroup
incorpora solo ese netgroup; una línea con +nombre incorpora sólo ese nombre. El archivo
/etc/hosts es consultado en el arranque, cuando todavía no hay NIS activo. Los restantes
archivos locales son ignorados por NIS.
La tendencia actual es definir en un archivo centralizado, /etc/nsswitch.conf, las fuentes
de información para cada tipo de entidad, con entradas tales como passwd: files nis hosts: files dns group: files donde las fuentes se prueban en orden hasta la primera que valida el pedido. Según estas
líneas, un login de usuario se contrasta primero contra /etc/passwd y luego, si éstos no
contienen al usuario, contra el mapa NIS correspondiente; un nombre de máquina se
busca primero en /etc/hosts, y si este fracasa se interroga al servicio DNS. El archivo
nsswitch.conf permite configurar acciones en casos de falla: continuar buscando en la
siguiente fuente (continue) o retornar en falta (return) si la fuente presente no
responde en algunas de las opciones previstas: UNAVAIL (fuene no disponible o baja),
NOTFOUND (la fuente no reconoce el pedido), TRYAGAIN (fuente ocupada), SUCCESS (el
pedido fue contestado). Ejemplo: hosts: files dns [NOTFOUND=return] nisplus
busca en /etc/hosts, si éste falla busca en DNS, si éste falla vuelve sin reconocer el
pedido, ni buscar en NIS+. Este archivo es una forma segura y prolija de controlar las
fuentes de validación.
Ventajas y desventajas de NIS.
es entendible por humanos: se siguen editando los mismos viejos archivos, sólo hay que aprender unos comandos nuevos, no requiere conocer la estructura interna de los mapas.
no admite enlace de dominios: una red grande puede dividirse en dominios, pero cada uno debe ser administrado separadamente.
NIS consume un cierto ancho de banda: no tiene capacidad de cache, toda consulta debe realizarse a un servidor; los mapas modificados deben distribuírse.
un servidor esclavo fuera de servicio puede perder una actualización; debe implementarse una rutina de control de actualización; aún así, dos versiones diferentes de un mapa pueden estar siendo servidas al mismo tiempo, con los clientes viendo una u otra aleatoriamente.
NIS no es seguro: cualquier máquina puede manifestarse como servidor de un dominio, cualquier usuario puede leer los mapas NIS.
Funcionamiento de NIS.
Los mapas de NIS están contenidos habitualmente en /var/yp, donde se crea un directorio
con el nombre del dominio NIS para contener los archivos. Cada mapa NIS comprende dos
archivos, uno de extensión .dir y el otro de extensión .pag. En el dominio instituto los
archivos ndbm para /etc/passwd serían
/var/yp/instituto/passwd.byname.dir
/var/yp/instituto/passwd.byname.pag
/var/yp/instituto/passwd.byuid.dir
/var/yp/instituto/passwd.byuid.pag
Para crear estos archivos ndbm, generalmente basta con los comandos cd /var/yp make
que invoca un archivo Makefile. Los archivos ndbm contienen "agujeros"; pueden
expandirse significativamente al ser copiados.
Esquema de consulta NIS:
Comandos y demonios de NIS
M: servidor NIS maestro;
S: servidor NIS esclavo;
C: cliente NIS
Programa En Descripción
ypserv MS demonio servidor NIS, se activa en el arranque de la máquina; recibe y
contesta consultas de clientes
ypbind MSC
demonio cliente NIS, se activa en el arranque de la máquina; consultado
por la biblioteca C para ubicar un servidor NIS en el dominio; la bilioteca
contacta luego ypserv directamente; las máquinas se mantienen fieles al
primer servidor ubicado
domainname MSC fija el nombre de dominio NIS en que se encuentra la máquina; corre en el
arranque
ypxfr S baja mapa desde el servidor maestro; sólo si está desactualizado
ypxfrd M demonio en el servidor maestro que atiende ypxfr
yppush M avisa a los servidores esclavos que deben actualizarse ejecutando ypxfr
makedbm M crea mapa ndbm desde archivo llano; corrido por make
ypmake M reconstruye mapas ndbm de los archivos modificados; en otras versiones,
se debe invocar make en el directorio NIS
ypinit MS configura una máquina para ser servidor maestro o esclavo
ypset MSC hace que ypbind se conecte a un servidor NIS específico
ypwhich MSC determina qué servidor NIS está usando la máquina local
yppoll MS determina la versión de un mapa que está usando un servidor
ypcat MSC muestra valores contenidos en un mapa NIS
ypmatch MSC muestra entradas para una clave indicada en un mapa NIS
yppasswd MSC cambia la contraseña de usuario en el servidor maestro NIS
ypchfn MSC cambia información de usuario en el servidor maestro NIS
ypchsh MSC cambia shell de login de usuario en el servidor maestro NIS
yppasswdd MSC servidor para yppasswd, ypchfn, ypchsh
ypupdate MS servidor para actualizar mapas NIS, manejado por inetd
El mapa especial ypservers es construído automáticamente al implantarse el dominio;
sirve para conocer los servidores esclavos a los que deben distribuírse los mapas.
Implantación de un dominio NIS.
NIS debe iniciarse en el servidor maestro, luego en cada servidor esclavo. El nombre de
dominio NIS debe fijarse en todas las máquinas, así como ajustar el archivo nsswitch.conf para
consultar los mapas.
Configuración de servidor NIS.
Para configurar el servidor NIS, ejecutar los comandos cd /var/yp # directorio NIS domainname iie-nis # fija el nombre de dominio NIS ypinit -m # inicializa como servidor maestro ypserv # arranca servidor NIS
Al inicializar el servidor maestro con ypinit -m, ya pide la lista de servidores esclavos
que incluirá en el archivo ypservers.
Iniciar servidores esclavos.
En los servidores esclavos, ejecutar los comandos cd /var/yp # directorio NIS ypinit -s ampere # fija servidor maestro, obtiene mapas ypserv # arranca servidor esclavo NIS
En cada esclavo deben ingresarse entradas en crontab para obtener copias actualizadas
de los mapas del servidor maestro. Como no todos los mapas cambian con la misma
frecuencia, si se quiere preservar el ancho de banda, debe implementarse una agenda
diferencial. Este script trasfiere todos los mapas:
#!/bin/csh -f
set eldominio = `/usr/bin/domainname`
cd /var/yp/$eldominio
foreach map (`/bin/ls`)
/usr/lib/yp/ypxfr $map
end
Algunos sistemas proveen scripts tales como ypxfr_1perday, ypxfr_2perday,
ypxfr_1perhour para transferir mapas NIS a diferentes intervalos. Para permitir a los
usuarios cambiar sus contraseñas NIS con yppasswd debe correrse el demonio
yppasswd en el servidor maestro del dominio.
Configuración de Cliente NIS.
Los servidores de un dominio generalmente son también clientes; el dominio NIS se fija u
obtiene con el comando domainname. Todos los clientes deben disponer de una versión
mínima de los archivos passwd, group y hosts con los usuarios y grupos habituales; hosts debe
existir para el arranque, cuando aún no hay NIS ni DNS. Todos los clientes deben asimismo
tener una configuración adecuada en nsswitch.conf, para saber qué deben consultar al validar,
o en su defecto contener las entradas con + en passwd y group. El servidor maestro del
dominio no debe contener entradas con +.
El arranque manual de un cliente NIS puede hacerse con los comandos domainname iie-nis # fija el nombre de dominio NIS ypbind # arranca demonio cliente NIS
Para el arranque automático, las máquinas deben ser informadas que pertenecen a un
dominio NIS. Esto puede hacerse con el comando domainname o nisdomainname
corrido desde algún script de arranque. Algunas versiones verifican la existencia del
archivo /etc/defaultdomain; si existe toman el nombre de dominio desde él. La forma de
arranque de NIS varía entre sistemas. Las líneas siguientes proveen un ejemplo de
comandos a incluir en un script de arranque; el nombre del dominio ya fue fijado para
esta máquina; se obtiene con el comando domainname.
# verificar si esta máquina sirve el dominio if [ -f /usr/sbin/ypserv -a -d /var/yp/`domainname`]; then /usr/sbin/ypserv; (echo -n ' ypserv') > /dev/console fi # arrancar ypbind if [ -f /usr/sbin/ypbind ]; then /usr/sbin/ypbind; (echo -n ' ypbind') > /dev/console fi
NIS+.
NIS+ corrige algunas deficiencias de NIS y agrega otras propias. Está orientado a redes grandes,
implementa seguridad, maneja eficientemente las actualizaciones, permite administrar
diversos dominios desde cualquier punto de la red. Es una base de datos distribuída de alta
complejidad, difícil de administrar, soportada por algunos proveedores mayores; no ha
migrado hacia las versiones de dominio público. Aún organizaciones grandes evitan usarlo.
Características de NIS+:
emplea un sistema jerárquico de dominios y subdominios, permitiendo delegar autoridad administrativa. Una máquina pertenece a un dominio, pero puede obtener información de máquinas en otros dominios.
emplea "tablas" en lugar de "mapas", permitiendo búsquedas por diferentes campos; por cada archivo de sistema se genera sólo una tabla.
no emplea archivos llanos; una vez transferidos los archivos al formato NIS+, los cambios en los archivos llanos no tienen influencia; es preciso editar las tablas de NIS+ con comandos especiales.
maneja mejor los servidores esclavos, llamados réplicas; las réplicas son actualizadas en forma incremental, con un esquema autenticación similar al de login para entrar en contacto con el servidor maestro.
se basa en el RPC seguro de Sun: autentica en base al encriptado de claves públicas. Los objetos NIS+ pueden ser tablas, columnas o entradas; todos los objetos tienen dueño y grupo; los permisos se fijan para el dueño, el grupo, el mundo y la categoría especial "nobody" para quienes no pueden exhibir credenciales, como ser clientes NIS. Tanto los usuarios como las máquinas pueden ser "principales RPC", entidades capaces de exhibir credenciales. Al acceder a NIS+ como root, se usan las credenciales de la máquina en lugar de las personales.
Desde el punto de vista del cliente, NIS+ se comporta como es habitual en UNIX, sin
transparentar su complejidad. Aunque no es lo mismo, NIS+ se parece mucho a DNS, con quien
comparte la organización jerárquica en dominios. Los nombres de dominio NIS+ y DNS suelen
ser el mismo; esto aumenta la confusión entre ambos. Un dominio NIS+ es un directorio con
subdirectorios org_dir y groups_dir; en org_dir van las tablas administrativas y en
groups_dir las credenciales de los principales del dominio.
LDAP.
Además de los archivos del sistema existe otro tipo de información cuya distribución debe ser
amplia: guías telefónicas, direcciones de correo electrónico, información a compartir con el
mundo exterior. Estas necesidades pueden ser respondidas por un servicio general de
directorios; éste debe ser capaz de asimilar cualquier conjunto de datos con ciertas
características:
objetos de datos relativamente chicos; extensa replicación y almacenamiento en caché; información basada en atributos; lectura frecuente, modificación escasa;
la búsqueda como operación frecuente y preferente.
El procotolo LDAP (Lightweight Directory Access Protocol), otrora parte del conjunto de
protocolos de red de OSI, está siendo promovido como servicio de directorios. Actualmente
(año 2000) en su versión 3 experimental, está lejos aún de proveer universalidad suficiente.
Las aplicaciones reales son todavía escasas como para recomendar su instalación en
producción. No obstante, existe considerable trabajo de investigación y desarrollo en torno a
este tema; en el futuro puede llegar a sustituír con ventaja los modos tradicionales de
compartir archivos.
Ejercicios e investigación.
1. Analice la necesidad de compartir archivos de configuración en su red. ¿Cuántos servidores
tiene? ¿Los usuarios deben ingresar a todos? ¿Sería posible el mantenimento manual? ¿Qué
riesgos se corren?
2. Estudie y proponga un esquema de copia de archivos con comandos habituales de
UNIX, incluyendo una actualización periódica. Analícelo luego críticamente,
atendiendo especialmente a la posibilidad de mantener versiones desactualizadas,
complejidad de administración, consumo de ancho de banda.
3. Reconsidere la situación anterior estudiando las prestaciones ofrecidas por los
comandos rdist, rsync, expect o similares existentes en su sistema.
4. Estudie los scripts de arranque de su máquina. Es posible que encuentre en ellos,
comentadas, las sentencias para arrancar la máquina como servidor NIS y como cliente
NIS. Esto no es suficiente para implantar un dominio NIS. Determine las acciones
complementarias.
5. Suponga que implementa un dominio NIS en su sistema. ¿Qué información debe
hacer llegar a los usuarios para su mejor conocimiento y uso? ¿Qué precauciones de
seguridad tiene que tomar como administrador?
6. Si su sistema soporta NIS+, es posible que cuente con scripts para realizar la mayor
parte de las tareas de administración. Investigue la existencia de dichos scripts, su forma
de uso individual y el esquema de aplicación para la implantación de un dominio.
7. Si dispone de un programa administrador para la creación de usuarios, investigue si
actualiza automáticamente las tablas de NIS (NIS+). Si tiene su dominio NIS ( NIS+)
activo, verifíque la actualización de los mapas NIS (tablas NIS+) al crear usuarios. Si la
herramienta administrativa no contempla el servicio, defina los procedimientos
complementarios para actualizar las tablas o mapas.
8. Investigue la situación anterior para el caso de la incorporación de máquinas.
9. Estudie en su sistema la relación entre NIS (NIS+) y DNS. ¿Cuál tiene precedencia?
¿Es posible controlar esto? Recuerde que los dominios NIS y DNS son conceptualmente
distintos.
Bibliografía y Referencias.
Comandos: rdist, rsync, expect, ypserv, ypbind, domainname, ypinit, ypxfr, yppush, yppoll, ypset, ypcat, yppasswd, ypwhich, ypmatch,
ypchfn, ypchsh, ypupdate.
Network File System (Sistema de archivos de red)
Introducción
El "Sistema de Archivos de Red" (NFS) es un protocolo para compartir archivos a través de una
red TCP/IP. Este sistema, originalmente introducido por Sun Microsystems en 1985, es el
protocolo más utilizado por máquinas UNIX para la compartición de archivos, y practicamente
todos los sistemas modermos lo proveen.
NFS es casi transparente para los usuarios, y es un protocolo "sin estado", en el sentido que si
un servidor NFS se cuelga, no se pierde información. Los clientes pueden esperar a que el
servidor retorne y continuar trabajando como si nada hubiera sucedido.
NFS consta de varios componentes, incluyendo un protocolo de montaje y su correspondiente
servidor, un protocolo de "locking" de archivos y su correspondiente servidor, y daemons que
coordinan el servicio de archivos básico.
NFS utiliza los servicios RPC de Sun ("Remote Procedure Call", llamada a procedimientos
remotos)
NFS desde el lado del servidor
Bajo BSD, se dice que un servidor "exporta" un filesystem cuando lo hace disponible para su
uso por parte de otras máquinas. En ATT se dice que lo "comparte".
Un cliente NFS debe explicitamente "montar" un filesystem antes de utilizarlo. El servidor
examina el pedido para asegurarse que el cliente tiene la autorización correcta, y luego le da al
cliente una "magic cookie" (un número aleatorio) que el cliente deberá utilizar para obtener
acceso en el futuro.
El esquema de "magic cookies" permite que el servidor funcione "sin estado", ya que no
precisa mantener información de qué clientes han sido autorizados. Usualmente, desmontar y
volver a montar un filesystem cambia la cookie.
Como un caso especial, las cookies se mantienen en un reboot para que un servidor que se
cuelga pueda volver a su anterior estado (siempre y cuando no se haya pasado por single-user
y modificado los filesystems).
Una vez que un cliente tiene una "magic cookie", utiliza RPC para solicitar operaciones sobre el
filesystem como crear un archivo o leer un bloque de datos. Como el protocolo es sin estado,
el servidor no se preocupa de recordar qué operaciones realiza un cliente. Es responsabilidad
del cliente asegurarse que el servidor de su confirmación en las operaciones de escritura antes
de borrar su copia de los datos.
RPC y el proceso portmap: mapeo de servicios.
RPC de Sun es un conjunto de protocolos para ejecutar servicios remotamente. Los distintos
servicios disponibles se distinguen por un número de servicio y un número de versión.
Para evitar tener que asignar un puerto TCP o UDP fijo a cada servicio, se utiliza el programa
portmap (a veces rpc.portmap) para mapear los números de servicio a puertos en el servidor.
Esto permite que a cada servicio se le asigne un puerto arbitrario en el servidor (aunque
normalmente NFS utiliza el puerto 2049). Por supuesto, portmap requiere que se le asigne un
puerto bien conocido (sunrpc/111). Antes de contactar cualquier servicio RPC, los clientes
deben consultar al servicio portmap en qué puerto está escuchando el servicio dado.
Cuando arrancan los demás programas (nfsd, mountd, etc.), se registran con portmap para
poder ser accesibles desde la red.
En versiones nuevas de solaris, este proceso se llama rpcbind
El proceso mountd: respuesta a pedidos de montar filesystems.
Los pedidos para montar filesystems son atendidos por el demonio mountd (a veces llamado
rpc.mountd). En los sistemas BSD (y muchos que no lo son, por ejemplo Linux), mountd lee el
archivo /etc/exports para obtener información de las máquinas que tienen acceso a cada
filesystem, y las restricciones que puedan tener.
El archivo exports contiene una lista de los directorios exportados y sus correspondientes
opciones y atributos.
Cada línea en el archivo exports especifica un directorio exportado, los permisos para los
distintos clientes que puedan utilizar este filesystem, y la descripción de que máquinas pueden
usarlo.
P. Ej:
/discos/users -maproot=root maquina1.iie.edu.uy
/discos/man -ro maquinasunix_iie
Permite que /discos/users sea montado desde maquina1.iie.edu.uy, permitiendo el
acceso de root (por defecto, los accesos de root via NFS se realizan como si el usuario
que estuviera realizando el acceso fuera nobody), y el acceso de solo lectura a
/discos/man de las máquinas en el "netgroup" maquinasunix_iie (asumiendo que este es
un netgroup).
NFS se maneja con la vision lógica de los filesystems, no con la capa física. Se puede
exportar cualquier subdirectorio, aunque no sea la raiz de un filesystem. Sin embargo,
por razones de seguridad, NFS requiere que cada dispositivo sea exportado
independientemente, por ejemplo en una máquina con una particion montada como
/users, el directorio / se puede exportar sin que se brinde acceso a /users.
El formato y los atributos que pueden ser especificados en /etc/exports varian entre
sistemas. En la tabla se muestran los atributos para algunos sistemas.
-
access=lista
Lista los hosts que pueden montar el filesystem (dados como una lista de
máquinas y netgroups separados por :)
-ro Especifica que solo se debe permitir el acceso de lectura, no de escritura.
-rw (=lista) Lista especiffica los hosts que pueden montar el filesystem con permiso de
escritura, los demás solo lo pueden montar read-only
-root=lista lista de hosts a los que se les permite acceder al filesystem como root (para los
demas, el acceso como root se mapea al acceso del usuario nobody)
-anon=n Especifica el uid (número de usuario) que debe utilizarse para los pedidos
provenientes de un usuario desconocido. (Por defecto, es nobody)
Si no se especifica que hosts pueden montar el filesystem, TODAS las maquinas pueden
hacerlo. Esto puede ser un grave problema de seguridad, y debe evitarse en lo posible.
Después de modificar /etc/exports, se le debe decir al demonio mountd que lo relea.
Algunos sistemas proveen un comando llamado exportfs que cumple esta función (con
la flag -a, o la flag -r en algunas versiones de Linux), mientras que en otros hay que
enviarle la señal SIGHUP al demonio mountd (mediante kill).
En Linux, las opciones con las cuales se exporta un filesistem se especifican entre
paréntesis DESPUÉS de la especificación del equipo o equipos que pueden montar el
filesystem.
P. Ej.
# sample /etc/exports file
/ master(rw) trusty(rw,no_root_squash)
/projects proj*.local.domain(rw)
/usr *.local.domain(ro) @trusted(rw)
/home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
/pub (ro,insecure,all_squash)
Por el detalle de las distintas opciones, ver man exports.
Solaris
Solaris sustituyó el archivo /etc/exports con el archivo /etc/dfs/dfstab, el cual es un script de
shell que ejecuta el comando share para cada uno de los filesystems exportados.
Por ejemplo:
share -F nfs -o rw=maq:fing:ferrari,root=ferrari /export/home
comparte el directorio /export/home con las máquinas maq, fing y ferrari, permitiendo
acceso de root a la máquina ferrari.
Luego de editar el archivo dfstab, se deben ejecutar los comandos share nuevos o
modificados para que las modificaciones tomen efecto, o ejecutar el comando shareall.
Por mas información, consultar el man de share.
nfsd : Proceso que acepta los pedidos de los clientes
Una vez validado el pedido de montar un filesystem por parte de un cliente, se le permite
realizar una serie de operaciones sobre el filesystem. Los pedidos para realizar estas
operaciones son manejados por nfsd (o rpc.nfsd).
nfsd recibe un parámetro que indica la cantidad de copias de si mismo que iniciar (mediante
fork, o como threads independientes en sistemas más modernos). Esta cantidad puede afectar
la performance del servidor (tanto si son muy pocos como si son demasiados), y no existe una
regla general para determinar dicho número. El valor por defecto es 4 en la mayoría de los
casos, y se recomienda para servidores que no sean muy utilizados. Este es el número máximo
de pedidos que el servidor puede procesar simultaneamente.
(En versiones nuevas de solaris y algunos linux, en lugar de iniciar multiples copias de nfsd, se
utilizan distintos threads de ejecución, y la cantidad por defecto que inicia el sistema al
bootear es de 16 en solaris y 1 en Linux).
lockd y statd : locking remoto
Los demonios lockd y statd (rpc.lockd y rpc.statd) proveen locking (control de acceso a los
archivos) para los filesystems compartidos mediante NFS, y son necesarios para que muchos
programas sean capaces de arbitrar el acceso concurrente a un mismo archivo.
Versiones viejas de Linux y FreeBSD no proveen locking.
rquotad : quotas en filesystems remotos
El demonio rpc.rquotad en algunos sistemas permite que otros sistemas obtengan información
sobre los límites de uso de un filesystem por parte de un usuario remotamente.
NFS desde el lado del cliente.
Extensiones al comando mount.
En las máquinas que soportan NFS, el comando mount acepta la notación maquina:directorio
para referirse al directorio directorio en la máquina maquina.
Es decir, para montar el directorio /ext de la máquina servidor en el directorio local /mnt se
ejecuta el comando:
mount servidor:/ext /mnt
biod : demonio que provee cache del lado del cliente.
Para mejorar la performance de NFS, la mayoría de los sistemas proveen el demonio biod
(llamado a veces nfsiod o rpciod), que realiza tareas básicas de lectura anticipada (read ahead)
y escritura retardada (write-behind) sobre el filesystem. Este demonio es opcional, pero
altamente recomendado ya que provee una mejora apreciable en la performance de NFS. (No
en Solaris).
biod, al igual que nfsd, recibe como parámetro la cantidad de copias de si mismo que
debe arrancar.
Montando filesystems remotos.
Los filesystems remotos que se deban montar de forma permanente deben o listarse en
/etc/fstab (/etc/vfstab en Solaris) o ser manejados por un servicio de montaje automático
como ser automount o amd.
Ejemplo:
# Device Mountpoint FStype Options Dump Pass#
ohm:/discos/ext /ext nfs rw,bg,intr,hard 0 0
ampere:/discos/users /usr/users nfs ro,bg,intr,soft 0 0
Las opciones mas usuales para NFS son:
rw Montar el filesystem read-write (debe estar exportado read-write en el servidor)
ro Solo lectura
bg Si la operación de montaje falla (el servidor no responde), continuar reintentando
en background.
hard Si un servidor no responde, hacer que las operaciones que intenten accederlo se
bloqueen hasta que el servidor reviva
soft
Si un servidor cae, hacer que las operaciones que traten de accederlo fallen y
retornen un error. Eso evita que los procesos se "cuelguen" en filesystems "no
esenciales". Debe usarse con cuidado.
retrans=n Numeros de reintentos antes de devolver un error en un filesystem montado
"soft"
timeo=n timeout (en décimas de segundo) para los pedidos.
intr Permite que los usuarios interrumpan operaciones bloqueadas (retornando un
error)
rsize=n Cambiar el tamaño del buffer de recepción a n bytes
wsize=n Cambiar el tamaño del buffer de transmisión a n bytes
nosuid Ignorar el bit de suid en los ejecutables en esta partición
nfsv2/nfsv3 Utilizar la versión de NFS especificada
Los nombres específicos pueden variar de sistema en sistema
Los filesystems montados "hard" causan que los procesos que lo usan se bloqueen
cuando los servidores caen (retornando a la normalidad al volver los servidores),
mientras que esto no sucede si está montado "soft". Pese a ser más cómodo el
funcionamiento "soft", puede ocasionar que procesos de larga duración aborten por un
problema transitorio en la red, y también puede llegar a generar archivos corruptos si el
corte se produce durante operaciones de escritura. Por ello normalmente se recomienda
no utilizar esta opción.
La opción intr, junto con la hard, permite que las operaciones bloqueadas sean
interrumpidas (enviandole al proceso una señal de QUIT (mediante kill , o <CTRL> C
si es el proceso activo en la terminal)). Esto permite que sea el usuario el que decida si
se debe interrumpir el proceso o no.
La elección de estas opciones es un compromiso entre seguridad de la información y
comodidad de uso que debe resolverse en cada caso.
Algunas utilidades de montaje automático, como amd, proveen algunos remedios para
esta situación.
Las opciones rsize y wsize son muy útiles en algunas versiones de linux, que por
defecto utilizan buffers muy chicos (1024 bytes). En estas versiones, especificar valores
entre 4096 y 8192 puede mejorar sustancialmente la performance de NFS.
Convenciones administrativas para NFS.
Manejo de usuarios en NFS
En NFS, el acceso a los archivos desde una máquina cliente se autoriza o nó de acuerdo al
número de usuario (UID) con el cual la máquina cliente informa que se está intentando el
acceso. Esto impone algunas decisiones administrativas.
Cualquier usuario que quiera acceder a un archivo en la red debe tener una cuenta de usuario
en la máquina donde se encuentra el filesystem. No es necesario que el usuario pueda
loguearse en esa cuenta, pero debe existir en los sistemas de autentificación. Además, los
números de usuario y de grupo deben ser únicos a través de todas las máquinas que
comparten filesystems (preferiblemente en toda la red).
También es conveniente tener un esquema de nombres de filesystems común a toda la red,
para simplificar el mantenimiento.
Interacciones entre NFS y las redes
NFS tradicionalmente ha utilizado UDP como protocolo de transporte. Aunque NFS hace su
propio chequeo de errores y retransmisión de paquetes erroneos y perdidos, ni UDP ni NFS
proveen ningún protocolo de control de congestión. Esto hace que NFS sobre UDP sea una
mala elección para redes de area extensa (WAN). También puede ocasionar problemas en
redes de area local, dada la capacidad de los servidores actuales.
Varios sistemas modernos ofrecen versiones de NFS que funcionan sobre TCP, siendo
mucho más adecuados para redes de area extensa y redes locales muy utilizadas.
Servidores NFS dedicados.
NFS sufre algunos problemas de performance debido a su diseño "sin estado" (parte de estos
problemas son mitigados en las últimas versiones de NFS). En particular, como el cliente asume
que una operación de escritura se completa una vez que recibe el acuse de recibo del servidor,
el servidor debe asegurarse de escribir cada bloque a disco antes de responder, para evitar
discrepancias en el caso de una caida. Esto introduce un retardo significativo en el caso de
escrituras NFS. Esto está en vías de solución en las nuevas versiones de NFS (v4, parcialmente
v3).
Además, los filesystems NFS tienden a ser grandes, lo que los hace suceptibles a problemas de
confiabilidad y dificultades para el respaldo.
Existen soluciones comerciales para estos problemas, tanto desde el punto de vista de tarjetas
que se pueden agregar a sistemas existentes para mejorar su performance (por ejemplo,
grabando la información en RAM no volatil hasta que se tenga tiempo de grabar a disco), como
sistemas dedicados con software y hardware especializados que solucionan tanto los
problemas de performance como los de confiabilidad.
Montaje automático
Montar los filesystems uno por vez listándolos en el archivo /etc/fstab introduce serios
problemas en redes grandes.
Primero, el mantenimiento de /etc/fstab en un número considerable de equipos puede
convertirse rápidamente en una pesadilla, especialmente si no todos son idénticos.
En segundo lugar, si se depende fuertemente de filesystems remotos, especialmente si se
montan filesystems de varios hosts, se genera un gran problema cuando cualquiera de ellos
falla, ya que cualquier comando que utilice los filesystems no disponibles se bloqueará.
En tercer lugar, si un servidor importante no está disponible, los usuarios pueden ver sus
posibilidades de trabajar disminuidas al no estar disponibles particiones importantes. En esta
situación sería muy util si se pudiera montar una copia de la particion de un servidor de
backup.
Un demonio de montaje automático conecta filesystems cuando son accedidos y los
desconecta cuando ya no son necesarios. Esto minimiza la cantidad de puntos de
montaje activos y es mayormente transparente a los usuarios. En la mayoría de los
servidores de montaje automático es posible dar una lista de filesystems replicados que
utilizar si el servidor primario no funciona.
Para implementarlo, el programa de conexión automática aparece como un servidor
NFS, pero en lugar de compartir un filesystem hacia la red, "inventa" un filesystem de
acuerdo a las especificaciones en su archivo de configuración.
Cuando un usuario hace referencia a un directorio dentro del filesystem "fantasma"
creado por el automounter, este intercepta la referencia, monta el filesystem que el
usuario está tratando de utilizar y continúa con la operación. Usualmente hay un solo
directorio donde realmente se montan los filesystems, y la ilusión de que dichos
filesystems están en otras ramas del filesystem se crea utilizando links simbólicos.
La idea original de los programas de montaje automático es de Sun. Su implementación,
automount, se encuentra en casi todos los sistemas NFS derivados de Sun. Sin
embargo, automount tuvo varios bugs y defectos de diseño en varias de sus versiones
que han hecho muy popular a una de sus alternativas gratuitas, amd.
amd (Am-Utils) es el resultado de una tesis doctoral (de Jan-Simon Pendry del Colegio
Imperial, Londres), que expande la idea de Sun, corrige las fallas mas graves de
automount, y es más portable que este último.
El sistema autofs implementado en linux puede utilizarse con el mismo cometido.
AUTOMOUNT: el demonio de montaje automático de Sun
automount entiende tres tipos de archivos de configuración (llamados "mapas"): mapas
directos, mapas indirectos, y mapas maestros. Los mapas directos e indirectos dan información
acerca de los filesystems que deben ser montados automáticamente. Un mapa maestro es una
lista de mapas directos e indirectos que automount debe manejar. No es necesario tener un
mapa maestro para correr automount, ya que se pueden pasar los mapas directos e indirectos
en la línea de comando.
Mapas indirectos
Los mapas indirectos se utilizan para montar varios filesystems bajo un directorio común. El
path al directorio se especifica en el mapa maestro, no en el propio mapa indirecto. En el
siguiente ejemplo, la primera columna indica el subdirectorio donde cada filesystem debe ser
montado (relativo al directorio indicado en el mapa maestro), y las siguientes columnas
indican las opcionesde montaje y el directorio de origen del filesystem.
users chimchim:/chimchim/users
devel chimchim:/chimchim/devel
info -ro chimchim:/otros/info
Mapas directos
Los mapas directos listan filesystems que no tienen un prefijo común. automount conecta cada
filesystem en un directorio temporal, y crea un link simbólico en el punto de destino
Ejemplo:
/usr/man chimchim:/usr/man
/cs/tools anchor:/cs/tools
En este ejemplo, automount conectaría los filesystems chimchim:/usr/man y
anchor:/cs/tools en un directorio temporal (por defecto tmp_mnt) y crearía un link
simbólico de /usr/man y /cs/tools a los puntos de montaje correspondientes.
Mapas maestros
Un mapa maestro lista mapas directos e indirectos. Para cada mapa indirecto, también
especifica el directorio base utilizado por las conexiones definidas en el mapa.
Por defecto, automount utiliza el mapa maestro definido en la NIS (excepto en Solaris, que por
defecto utiliza /etc/auto_master y requiere una línea +auto_master en este archivo para usar
los datos de la NIS).
Por ejemplo:
#Directory Map
/chimchim /etc/auto.chim
/- /etc/auto.direct
La primer columna indica el directorio local para un mapa indirecto, o /- para un mapa
directo. La segunda indica el nombre del archivo en el cual se encuentra el mapa. Puede
haber varios mapas de cada tipo.
Automount se puede ejecutar de dos formas: utilizando un mapa maestro (ya sea el por
defecto auto.master de la NIS o uno dado en la línea de comandos), o listando los mapas
directos e indirectos en la línea de comando.
Ej: automount /- /etc/auto.direct /chimchim /etc/auto.chim &
Filesystems replicados utilizando automount
En algunos casos, un filesystem read-only como /usr/man puede ser idéntico en varios
servidores. En ese caso, se le puede decir a automount que elija el servidor que responda mas
rápido.
Algunas consideraciones:
- Los filesystems replicados DEBEN ser de solo lectura. El demonio de automount no puede
sincronizar escrituras en varios servidores.
- automount NO puede desmontar un filesystem activo y reemplazarlo con un respaldo
cuando un servidor se cuelga. Solo puede elegir un servidor que responda cuando se monta el
filesystem.
- No se puede indicar qué servidores son primarios y cuales backup. automount selecciona el
servidor basado en su idea de cercania.
- Los filesystems replicados DEBEN ser idénticos.
Por ejemplo, un mapa directo que define que /usr/man es un filesystem replicado puede
ser:
/usr/man chimchim,band:/usr/man
Nuevas versiones de automount permiten montar RW filesystems replicados.
Deteniendo automount
Como automount funciona como un servidor NFS, terminarlo con kill -9 puede dejar el sistema
bloqueado. Si se precisa matar o reiniciar automount, se debe asegurar de utilizar la señal
TERM (kill -15) para que automount pueda devolver el filesystem local a su estado original.
AMD (AM-UTILS)
amd es técnicamente superior al automount original de Sun. Algunas de sus ventajas:
- amd nunca se va a bloquear si un servidor remoto se cuelga.
- amd envía pedidos de "keep-alive" a los servidores remotos a intervalos regulares y
mantiene una lista de los servidores accesibles, que utiliza para montar, desmontar y
reemplazar filesystems. Si un servidor se cuelga, futuros accesos al filesystem devuelven el
error "operation would block" en lugar de bloquearse.
- amd no contiene código propietario y ha sido portado a muchas versiones de UNIX.
- amd soporta una cantidad de tipos de montaje no soportados por automount.
- los mapas de amd pueden ser guardados en varios formatos de base de datos, incluyendo
NIS, NIS+, Hesiod, ndbm y otros
- posee una herramienta de manipulación y consulta (amq) que permite su monitoreo y el
envio de comandos al servidor.
- La sintaxis de usu mapas es mas genérica que la de automount.
- amd está basado en el concepto de que cada servidor tiene uno o mas filesystems, con
cada filesystem conteniendo uno o mas volúmenes (un conjunto coherente de archivos). Esto
hace que el manejo de subdirectorios sea mas directo que con automount.
Mapas de AMD
El formato de los mapas de amd es extremadamente flexible, y permite que un mismo archivo
de configuración sea utilizado en varias máquinas. Cada filesystem listado en un mapa de amd
debe tener asociado un tipo de montaje. Los tipos mas comunes se muestran en la tabla.
nfs Acceso básico a un servidor NFS
ufs Acceso básico a un filesystem local
host Acceso a todo el arbol exportado por un servidor (se le pregunta al mountd en el
servidor cuales son sus filesystems exportados)
nfsx Acceso a un grupo de filesystems en un servidor NFS con una sola entrada en el
mapa.
program Corre un programa cada vez que se debe montar o desmontar el filesystem. Se utiliza
para tipos de montaje que amd no conozca.
link Crea un link simbólico que apunta a un punto de montaje físico (permite que
cualquier directorio se pueda acceder via amd).
auto Crea un nuevo punto de montaje debajo de uno existente, algunas veces utilizado
para replicar el árbol de montaje de un servidor.
direct Casi idéntico a los mapas directos de automount
union Permite que el contenido de varios directorios aparezca como un único directorio
Las entradas en los mapas pueden contener condicionales, que permiten que se activen
solo en contextos específicos (por ejemplo en un determinado host o tipo de máquina).
Los condicionales utilizan varias variables automáticamente asignadas con una serie de
información acerca del entorno en que amd está corriendo. Los selectores mas comunes
se muestran en la tabla.
arch Arquitectura de la máquina
autodir Directorio por defecto donde montar filesystems.
byte Orden de los bytes en la máquina (big- o little-endian)
cluster Nombre del cluster local de la máquina, por defecto domain
domain Dominio NIS local
host nombre de la máquina
hostd nombre de la máquina concatenado con el dominio
karch arquitectura del kernel (por defecto igual a arch)
key Nombre del volumen que se está resolviendo
map Nombre del mapa siendo utilizado
os Sistema Operativo
Wire Nombre de red de la interfase primaria de la máquina
Ejemplo:
/default opts:=rw,soft,timeo=10,retrans=5
usr/man host==chimchim;type:=ufs,dev:=/dev/sd1f
host!=chimchim;rhost=chimchim;rfs:=/${key};type=nfs;fs:=${autodir}/${key}
cs/tools host==anchor;type:=ufs;dev:=/dev/sd3c
host!=anchor;rhost=anchor;rfs:=/${key};type=nfs;fs:=${autodir}/${key}
Las entradas de la forma nombre:=valor definen varios atributos del montaje. Por
ejemplo, la primera línea fija las opciones por defecto en "rw,soft,timeo=10,retrans=5".
Los elementos de la forma nombre==valor o nombre!=valor son condicionales: los
siguientes elementos solo son utilizados si el condicional es verdadero (En el ejemplo
para /usr/man, se utilizan para tomar acciones distintas dependiendo de si estamos en
chimchim o no).. Notaciones como ${autodir} o ${key} insertan el valor del selector
adecuado.
Algunas opciones en los mapas de amd que indican filesystems remotos son:
rhost host remoto donde se encuentra el filesystem
rfs Nombre del filesystem remoto
type Tipo de montaje
fs Punto local de montaje.
Arrancando amd
amd se puede arrancar con un script como:
#!/bin/csh -f
cd /usr/local/etc/amd
exec /usr/local/bin/amd -x fatal,error,user -r -l syslog -a /tmp_mnt /amd
amd.master.map >& /dev/console.
Opción Descripción
-x Fija las opciones de error
-r "Adopta" los puntos de montaje ya existentes
-l Especifica el archivo de log o syslog para los mensajes de error
-a Especifica una ubicación alternativa para los puntos de montaje (por defecto,
/a)
/amd Especifica el nombre del directorio del mapa
amd.master.map Especifica el archivo conteniendo las opciones de montaje.
Cuando un usuario referencia un filesystem definido en el mapa de amd, amd monta el
filesystem y monitorea el uso del mismo. Después de haber estado inactivo por un
período de tiempo (usualmente 5-15 minutos), amd desmonta el filesystem hasta que
sea accedido nuevamente.
Filesystems replicados utilizando amd
amd permite que se listen varios servidores para un filesystem particular. A diferencia de
automount, en la mayoría de los casos es capaz de desconectar filesystems activos de
servidores caidos y montar sus reemplazos "on the fly"
Por ejemplo:
usr/man host==chimchim;type:=ufs;dev;=/dev/sd1f ||
host==band;type:=ufs;dev:=/dev/sd3c ||
rhost=chimchim rhost=band;rfs:=/${key};
type=nfs;fs:=${autodir}/${key}
Deteniendo amd
amd debe ser notificado de que debe irse para que tenga opción de retirarse de la estructura
del filesystem. Para ello hay que enviarle una señal SIGTERM.
NFS y la seguridad
NFS provee una forma conveniente de acceder a archivos a través de una red, pero es una
fuente importante de problemas de seguridad. Para un sitio "normal", una protección
adecuada se obtiene con un control estricto de /etc/exports (o /etc/dfs/dfstab), y un manejo
adecuado del archivo /etc/hosts.allow (en los sistemas que permiten limitar los servicios RPC
en este archivo). El mayor riezgo proviene de máquinas locales a las cuales se les permite
montar un filesystem (obviando los casos de fallas en la implementación de los protocolos, que
históricamente fueron comunes).
La seguridad de NFS se basa en la confianza entre máquinas. Una vez que el servidor le
permite a un equipo montar un filesystem, la seguridad de los archivos en el servidor depende
también de la seguridad en la máquina cliente. Es el cliente el que indica como qué usuario
debe realizarse cada operación (dando el número de usuario), por lo que es importante que
solo exportemos filesystems a máquinas "confiables", y que compartan la misma base de datos
de usuarios.
Si un usuario es capaz de obtener acceso de root en una máquina cliente, hay varios métodos
para acceder a archivos pertenecientes a otros usuarios, aun cuando en el /etc/exports no se
permita el acceso de root. Si alguien en quien no se confía tiene acceso de root en una
máquina cliente, no se debe exportar ningun filesystem a esa máquina.
Hubo intentos de hacer NFS mas seguro. Por ejemplo, a través de la utilización de Kerberos
para la validación, o de "secure RPC", un protocolo más seguro de invocación de procesos
remotos. Sin embargo, no es tanta la mejora de seguridad que se obtiene comparado con una
buena administración, y dichas extensiones no son mayormente utilizadas.
Monitoreo y "tunning" de NFS
La mayoría de los sistemas proveen un comando llamado nfsstat que despliega varias
estadísticas mantenidas por los sistemas NFS. nfsstat -s muestra estadísticas de los procesos
de servidor NFS, mientras que nfsstat -c muestra información de las operaciones como cliente.
Los principales parámetros a monitorear son los timeouts y los errores.
Bibliografía Adicional
http://www.linuxdoc.org/HOWTO/NFS-HOWTO/ http://www.am-utils.org/
http://www.am-utils.org/am-utils.html
http://www.linuxdoc.org/HOWTO/mini/Automount.html
http://www.linux-consulting.com/Amd_AutoFS/autofs-HOWTO.html
man de los comandos descriptos.
Samba Qué es Samba
Versiones, obtener Samba
Instalación
Arranque de los demonios
Configuración
Acceder directorio UNIX desde Windows
Acceder directorio Windows desde UNIX
Compartir una impresora UNIX
Compartir una impresora Windows
Protocolos SMB y CIFS
Protocolo SMB
Protocolo CIFS
Localización de recursos o "browsing"
Conceptos y objetivos de una red SMB/CIFS
Conceptos de red SMB/CIFS
Grupos de trabajo y Dominios
Localizadores maestros
Controlador de dominio
Seguridad de los servicios compartidos en Grupo de Trabajo
Modo de autenticación de servicios por Dominio
Esquemas de autenticación
Bibliografía y referencias.
Qué es Samba
Samba es un conjunto de programas que permite a sistemas cliente acceder archivos e
impresoras en un servidor usando el protocolo SMB (Server Message Block). El servidor puede
ser una máquina UNIX, Netware, OS/2 o VMS. Los clientes pueden ser Lan Manager, Windows
3.11/95/98/NT/2000, Linux, OS/2. Concretamente, Samba permite hacer uso de archivos e
impresoras ubicados en una máquina UNIX desde máquinas Windows; también desde
máquinas DOS con Lan Manager. Como parte del conjunto, viene un programa que permite a
una máquina UNIX actuar como cliente de otros servidores SMB.
Con Samba pueden realizarse las siguientes cosas:
compartir un directorio de UNIX hacia máquinas Windows; acceder un directorio Windows desde máquinas UNIX; compartir una impresora UNIX hacia máquinas Windows; acceder una impresora Windows desde máquinas UNIX.
El conjunto de programas contenidos en el paquete Samba comprende:
smbd, el servidor SMB; maneja las conexiones de los clientes, incluyendo permisos y
validación de usuarios.
nmbd, el servidor de nombres NetBIOS; permite a los clientes ubicar los servidores
mostrando una lista e incorporando aspectos de manejo de dominio.
smbclient, programa cliente UNIX; permite a UNIX actuar como cliente de otro servidor
SMB.
smbrun, permite al servidor correr aplicaciones en máquinas SMB.
testprns, para comprobar el acceso a impresoras.
testparms, para verificar la configuración de Samba.
smb.conf, el archivo de configuración de Samba.
smbprint, un script para que una máquina UNIX pueda usar smbclient para imprimir en un
servidor SMB.
documentación, abundante cantidad de información cuya lectura puede ahorrar mucho
tiempo y frustración.
El conjunto se entrega con todo el código, es de uso público, y se encuentra protegido bajo la
licencia GPL (General Public License) de GNU.
Versiones, obtener Samba.
Linux y FreeBSD incluyen Samba entre sus paquetes; para Solaris o HP-UX pueden bajarse los
fuentes, o aún versiones en binario, desde www.samba.org. Samba es considerado muy
estable y seguro, condiciones logradas en base a la política de abundar en versiones de
dominio público para favorecer la corrección del software. Las versiones alfa, que contienen la
palabra "alpha" en el nombre del paquete, están destinadas a detección de fallas; no se las
consideran estables como para el uso en producción. Al obtener una versión nueva, debe
buscarse el número más alto que no contenga la palabra "alpha".
Instalación.
Las siguientes son las ubicaciones habituales de comandos y archivos:
demonios smbd y nmbd en /sbin; comandos de usuario en /bin; archivo de configuración en /etc/smb.conf; archivo de registro en /var/log; los archivos smb y nmb retienen mensajes originados
por los demonios smbd y nmbd; pueden configurarse archivos de mensajes distintos por máquina cliente, por ejemplo en /var/log/samba/%m.log, donde %m es una variable que contiene el nombre de la máquina;
directorio para bloqueos en /var/lock/samba.
El archivo de configuración /etc/smb.conf es la parte crucial de la instalación. En la distribución
viene un ejemplo con abundantes comentarios. La página man smb.conf explica las muchas
opciones disponibles.
Arranque de los demonios.
Los demonios smbd y nmbd pueden ser corridos desde inetd o como procesos autónomos.
Para arrancarlos desde inetd, si se está configurando un servidor permanente, deben ser
configurados para arrancar de nuevo si mueren. El archivo /etc/inetd.conf debe
contener líneas similares a éstas: # servicios NetBIOS de Samba netbios-ssn stream tcp nowait root /usr/sbin/smb smbd netbios-ns dgram udp wait root /usr/sbin/nmbd nmbd
Después de editar el archivo, reinicializar inetd con
kill -1 id-proceso-inetd
para que la configuración tome efecto. El número de proceso de inetd puede obtenerse
con ps auxw | grep inetd
Para arrancar los demonios como procesos autónomos, incluir su invocación a través de
los scripts de arranque, como se muestra en el siguiente script /etc/rc.d/init.d/smb:
#!/bin/sh
#
# /etc/rc.d/init.d/smb - arranca y detiene servicios SMB.
#
# Establecer los siguientes enlaces simbólicos hacia este script
# para el arranque en el nivel 3 (red en multiusuario):
# /etc/rc.d/rc0.d/K35smb - destruye servicio SMB en shutdown
# /etc/rc.d/rc1.d/K35smb - destruye servicio SMB en monousuario
# /etc/rc.d/rc3.d/S91smb -arranca servicio SMB en multiusuario
# /etc/rc.d/rc6.d/K35smb -destruye servicio SMB en reboot
# parámetros de invocación.
case "$1" in
start)
echo -n "Iniciando servicios SMB: "
/sbin/smbd -D
/sbin/nmbd -D
echo
touch /var/lock/subsys/smb
;;
stop)
echo -n "Cerrando servicios SMB: "
killproc smbd
killproc nmbd
rm -f /var/lock/subsys/smb
echo
;;
*)
echo "Usage: smb {start|stop}"
exit 1
esac
En algunas distribuciones el arranque de Samba viene ya incluído en los scripts de
arranque, a veces comentado. Distribuciones como Debian traen ya su script
/etc/init.d/samba y crean los enlaces simbólicos al instalar el paquete.
Configuración.
La configuración de Samba se controla con un único archivo, /etc/smb.conf. Aquí se determina
qué recursos serán compartidos y bajo qué condiciones. El archivo está dividido en secciones,
cada una de las cuales comienza con un encabezado tal como global, homes, printers, etc. La
sección "global" define variables de acción global sobre todos los recursos compartidos. La
sección "printers" define la configuración general de impresoras reconocidas por ese servidor.
La sección "homes" permite a un usuario, y sólo a él, acceder su directorio propio en la
máquina UNIX. El ejemplo siguiente permitirá a usuarios Windows acceder sus directorios
propios en la máquina UNIX y usar libremente un directorio temporal en la máquina UNIX.
; /etc/smb.conf
;
[global]
guest account = guest
log file = /var/log/samba/%m.log
lock directory = /var/lock/samba
share modes = yes
[homes]
comment = Directorios propios
browseable = no
read only = no
create mode = 0755
[temporal]
comment = Espacio para archivos temporales
path = /tmp
read only = no
public = yes
Para compartir un directorio público con permisos de escritura:
[publico]
comment = Public Stuff
path = /home/public
public = yes
writable = yes
Para que este directorio sea legible por todo público pero solo modificable por
integrantes del grupo "tecnicos":
[tecnopub]
comment = Directorio Público del grupo Técnicos
path = /home/tecnopub
public = yes
writable = yes
printable = no
write list = @tecnicos
Acceder directorio UNIX desde Windows.
Una vez instalado y configurado Samba en la máquina UNIX, quedarán disponibles para los
clientes Windows los servicios compartidos. Esto es, será posible montar directorios de la
máquina UNIX en una máquina Windows. Para ello, se realiza la operación de montaje como
siempre: si se trata de Windows 95/98/NT/2000 puede usarse el Explorador, indicando en la
opción de montar unidad de red el nombre de la unidad de disco, y luego el nombre de la
máquina UNIX seguido del nombre del recurso compartido, en la notación habitual,
\\máquina_UNIX\nombre_recurso. También puede hacerse la operación desde una ventana de
comandos, indicando el nombre de la unidad: net use K: \\gingko\tecnopub
monta sobre la unidad K: el recurso llamado tecnopub compartido vía Samba en la máquina
UNIX llamada gingko.
Una vez asegurado el éxito de la operación, puede accederse desde la máquina cliente al
directorio de la máquina UNIX en la letra de unidad indicada. Si el recurso compartido
requiere autenticación del usuario, este debe poseer una cuenta en la máquina UNIX o
en otra máquina que haya sido designada para la autenticación de seguridad. En este
caso, el acceso sólo será concedido si el usuario es autenticado por quien tenga la
autoridad de hacerlo, y si dispone de los permisos adecuados. La autoridad para
autenticación de usuarios se designa en el archivo smb.conf de Samba.
Acceder directorio Windows desde máquinas UNIX con Samba.
Samba trae un programa cliente, smbclient, para que las máquinas UNIX puedan acceder
recursos compartidos vía SMB en máquinas Windows o en otras máquinas UNIX/Samba. Este
programa provee una interface similar a ftp, lo que permite transferir archivos desde y hacia
un recurso compartido desde una máquina Windows.
/usr/sbin/smbclient -L winntmaq
muestra los recursos compartidos en la máquina winntmaq, ya sean directorios o
impresoras, generalmente pidiendo una contraseña.
/usr/sbin/smbclient \\\\winntmaq\\g_tmp <contraseña> Aquí el caracter \ debe "escaparse" con otro \, escribiendo \\ para que tome \. Este
comando conecta al directorio g_tmp habilitando una línea de comandos de tipo ftp: Server time is Sat Aug 10 15:58:44 1996 Timezone is UTC+10.0 Domain=[WORKGROUP] OS=[Windows NT 3.51] Server=[NT LAN Manager 3.51] smb: \>
Para obtener la lista de comandos disponibles en smbclient:
smb: \> h
ls dir lcd cd pwd
get mget put mput rename
more mask del rm mkdir
md rmdir rd prompt recurse
translate lowercase print printmode queue
cancel stat quit q exit
newer archive tar blocksize tarmode
setmode help ? !
smb: \>
El programa smbclient es también útil para determinar el funcionamiento correcto de
Samba en una máquina UNIX, invocándolo desde ella misma o desde otra máquina
UNIX.
Compartir una impresora UNIX.
Como toda impresora en UNIX, la impresora a compartir debe tener una entrada en el archivo
/etc/printcap. Una vez seguros de que la impresora funciona bien en la máquina UNIX, para
compartirla hacia las máquinas Windows agregar en smb.conf algo similar a esto:
; parámetros globales para imprimir
[global]
printing = bsd
printcap name = /etc/printcap
load printers = yes
log file = /var/log/samba/%m.log
lock directory = /var/lock/samba
; parámetros para todas las impresoras
[printers]
comment = Todas las Impresoras
security = server
path = /var/spool/lpd/lp
browseable = no
printable = yes
public = yes
writable = no
create mode = 0700
; configuración de una impresora
[ljet]
comment = Impresora HP laserjet
security = server
path = /var/spool/lpd/lp
printer name = hpljet
writable = yes
public = yes
printable = yes
print command = lpr -r -h -P %p %s
Compartir una impresora Windows.
Para poder compartir una impresora en un servidor Windows remoto vía Samba, debe
disponerse de una entrada para ésta en el /etc/printcap de la máquina UNIX. Las convenciones
de printcap usadas significan:
cm - comentario
lp - nombre del dispositivo de impresión
sd - directorio de spool de la impresora, en la máquina local
af - archivo de contabilidad
mx - tamaño máximo de archivo; si se pone 0, no hay límite
if - nombre del filtro de entrada, si lo hay (un script)
Ejemplo de entrada en /etc/printcap.
# /etc/printcap
#
# \\winntmaq\imppost5 via smbprint
#
lpwin|immpost5:\
:cm=HP 5MP Postscript imppost5 en winntmaq:\
:lp=/dev/null:\
:sd=/var/spool/lpd/imppost5:\
:af=/var/spool/lpd/imppost5/acct:\
:mx#0:\
:if=/usr/bin/smbprint:
smbprint es un filtro de entrada para impresoras definidas en /etc/printcap. Usa el
programa smbclient para imprimir un archivo en una impresora servida por una
máquina basada en SMB. El nombre del servidor y la impresora se leen del archivo de
configuración /var/spool/lpd/nombre_impresora/.config; para el ejemplo anterior,
# /var/spool/lpd/imppost5/.config # # configuración para impresora imppost5 en servidor winntmaq server=winntmaq service=imppost5 password=""
El script imprime hacia el servicio de impresión en la máquina remota mediante un comando
similar a cat archivo.txt | /usr/bin/smbclient \\servidor\impresora \ contraseña -U servidor -N -P >> logfile
Protocolos CIFS y SMB.
En las secciones siguientes se resumen algunos conceptos útiles para comprender la
instalación de una red basada en máquinas UNIX/Samba sirviendo archivos e impresión a
máquinas Windows y NT. Cada nueva versión de Samba implementa más cercanamente el
esquema de red Microsoft, haciendo la máquina UNIX cada vez más indistinguible de un
servidor Microsoft en lo que a clientes se refiere.
Protocolo SMB.
SMB (Server Message Block, bloque de mensajes de servidor) es un protocolo para compartir
archivos, base de los sistemas de red LAN Manager y Microsoft Networking. SMB fue aplicado
por Microsoft a DOS como una extensión para dirigir entrada salida de disco hacia NetBIOS
(Network BIOS), un sistema diseñado por IBM y Sytec para actuar como interfaz cruda entre
red y aplicación. Modernamente, los paquetes SMB son transportados en una extensión de
NetBIOS denominada NBT, NetBIOS sobre TCP/IP.
Protocolo CIFS.
CIFS (Common Internet Filesystem, sistema de archivos común para Internet) es una tentativa
de implementar un protocolo de dominio público para transferencia de archivos en forma
simple y potente, ampliando las capacidades de SMB, en el cual se basa.
CIFS define un protocolo de acceso a sistemas de archivos remotos normalizado para
uso en redes, permitiendo a los grupos de usuarios trabajar juntos y compartir
documentos ya sea a través de Internet o dentro de sus intranets corporativas. Es una
tecnología multiplataforma, abierta, basada en los protocolos para compartir archivos de
MS Windows y otros sistemas operativos comunes, soportada por UNIX y otros
sistemas operativos. En su máxima expresión, CIFS permitiría a millones de usuarios
compartir sus archivos sin instalar nuevo software o cambiar su forma de trabajo
habitual.
Localización de recursos o "browsing".
La localización de recursos o "browswing" es la parte de los protocolos SMB/CIFS que permite
ubicar recursos en la red tal como se hace en la sección "Entorno de Red" para las máquinas de
un mismo grupo en el Explorador de Windows 95/98/NT/2000. Tocando con el ratón sobre el
nombre de una máquina, ésta muestra sus recursos compartidos (impresoras y directorios), a
los que puede hacerse conexión. CIFS aspira a realizar esto a través de la Internet.
Conceptos y objetivos de una Red SMB/CIFS.
Al instalar en una red LAN o WAN servicios de archivo e impresión las decisiones cruciales
implican:
Cómo y dónde se almacena la información de nombres de usuario, contraseñas y seguridad;
Qué método se usará para ubicar los recursos que los usuarios tienen habilitados;
Qué protocolos hablan (soportan) los clientes.
Las redes Netware, Windows NT o cualquier producto para servicio de archivos encierra al
usuario en el marco de las respuestas de ese producto a las preguntas anteriores. Esto es
inconveniente aún cuando se tiene una red homogénea, pero más cuando se tiene diversos
tipos de máquinas y sistemas operativos. Samba intenta superar estas restricciones
admitiendo la mayor combinación posible de clientes, servidores, sistemas operativos y
protocolos.
Conceptos de red SMB/CIFS.
Para la implementación de redes, Dominio y Grupo de Trabajo son exactamente lo mismo,
excepto por la secuencia de ingreso del cliente (logon). En los dominios, existe una base de
datos de autenticación distribuída; esto da mayor alcance y flexibilidad al concepto de
dominio. Para Samba, cuando un cliente se conecta a un servicio, lo hace presentando una
cadena de autenticación; si ésta es válida, el acceso le es permitido, sin importar cómo ha sido
generada esa cadena. En el caso de ingresar a un dominio, sin embargo, el cliente SMB espera
que todos los demás servidores del dominio acepten la misma información de autenticación.
En cuanto a la localización de recursos ("browsing"), no hay diferencia entre dominio y grupo
de trabajo. Windows 95/98 puede ser miembro tanto de un dominio como de un grupo de
trabajo; Windows NT no. Samba puede sólo ser miembro de un único grupo de trabajo o
dominio, aunque las nuevas versiones de Samba están ya dando soporte de dominio NT.
Grupos de Trabajo y Dominios.
El grupo de trabajo (Workgroup) designa un conjunto de máquinas que mantienen una base de
datos común para la localización de sus recursos compartidos. No necesariamente tienen en
común información de seguridad; si ésto acontece, estamos en presencia de un dominio. El
mantenimiento de la lista de servidores y recursos es dinámica: se altera toda vez que entra o
sale un servidor de la red, o que incorpora o elimina un recurso compartido. El término
"browsing" o localización se refiere al acceso a recursos por parte del usuario, usando una
interfaz cualquiera, tal como el Explorador de Windows. Los servidores SMB acuerdan entre
ellos cuales mantienen la base de datos de localización de recursos. Los grupos de trabajo
pueden estar en cualquier punto de una red interconectada TCP/IP, aún en diferentes
subredes o en la internet; esto es algo muy difícil de implementar para SMB.
Localizadores maestros.
Los localizadores maestros o "master browsers" son máquinas que tienen la base de datos
maestra de localización de recursos en un dominio o grupo de trabajo. Hay dos clases de
localizadores maestros:
Localizador Maestro de Dominio ("Domain Master Browser"): retiene la base de datos
maestra de localización de todo el dominio, eventualmente atravesando varias subredes
TCP/IP.
Localizador Maestro Local ("Local Master Browser"): retienen la base de datos maestra de
localización de la subred en la que se encuentran; se comunican con el localizador maestro de
dominio para obtener información de otras subredes.
Las subredes son un caso especial porque la localización de recursos se basa en difusión, y la
difusión no atraviesa los ruteadores. Los localizadores maestros, ya sean de dominio o locales,
son elegidos dinámicamente según un algoritmo que considera la habilidad de la máquina para
sostener la carga de localización. Samba puede configurarse para actuar siempre como
localizador maestro; esto equivale a ganar siempre la elección, incluso frente a sistemas
actuando como controladores primarios de dominio Windows NT, que aspiran ellos mismos a
ganar la elección.
Controlador de Dominio.
El término Controlador de Dominio (Domain Controller) está unido a la autenticación de
usuarios en un dominio. El método de autenticación de usuarios en un dominio usado por
Windows NT es el más difundido, pero no es el único.
Seguridad de los servicios compartidos en Grupo de Trabajo.
El ajuste de seguridad de Samba "security = SHARE", fue la implementación inicial de Samba,
en la cual en base a la contraseña asociada al recurso se infería el usuario, pudiendo incluso
hacerse que el usuario fuera "todos". Esto se considera mala práctica, pero en los orígenes
estaba ligado a grupos chicos, alrededor de los años '80, en los cuales las consideraciones de
seguridad no eran prioritarias. El criterio resucitó en 1992 con Windows for Workgroups.
Modo de autenticación de servicios por Dominio.
Con el ajuste de seguridad de Samba "security = USER" o "security = SERVER" todos los
accessos a los recursos son verificados por el par nombre de usuario / contraseña de modo
más riguroso. Para el cliente, esto emula el comportamiento de ingreso a un dominio
Microsoft. Para el cliente es indiferente si Samba consulta la base de datos de seguridad SAM
de Windows NT o autentica al usuario de algún otro modo, como ser consultando a la máquina
UNIX. Si los nombres de usuario existen en la máquina UNIX, conviene usar "security = user"; si
no, convendrá "security = share" para ambientes chicos donde la seguridad no es un problema;
con "security = server" las duplas nombre de usuario / contraseña son transferidas a otro
servidor SMB para su autenticación, como ser una máquina NT.
Esquemas de autenticación.
En el caso más simple, la información necesaria para la autenticación de un usuario
reside en uno o más archivos en un servidor único. Cuando el usuario debe acceder más
de un servidor, se requiere algún tipo de base de datos distribuída para evitar obligar al
usuario a tener una contraseña en cada contexto. Tal esquema debe ser capaz de
soportar cambios de contraseña y grupos de usuarios con permisos en un mismo nivel.
Por estas razones Samba implementa en muchos casos directamente el modelo de
dominio.
Existen diversos esquemas de autenticación posibles utilizables por Samba, tales como
NIS; para máquinas Windows 95/98 y muchos otros clientes Samba puede comportarse
como controlador maestro de dominio compartiendo la base de datos de autenticación
vía NIS en forma transparente para los clientes. El soporte de dominio para Windows
NT está ya disponible en las nuevas versiones. El soporte para perfiles de usuario es
soportado por Samba para clientes Windows 95/98/NT desde tiempo atrás.
Samba: ejemplo de archivo de configuración.
; ; =========================================== ; Archivo de configuración simple para Samba. ; =========================================== ; archivo: smb.conf ; ; Provee: ; - acceso a directorios propios de usuarios ; - acceso a todas las impresoras en /etc/printcap ; ; Verificar: ; 1: Ruta a printcap; en general, /etc/printcap (BSD). ; 2: Validez del comando "print", que debe aceptar un archivo %s ; para una impresora %p y luego eliminar el archivo. ; 3: Ajuste "printing =" para el sistema: sysv, bsd, aix ; 4: Validez del comando "lpq" para el sistema. ; 5: El usuario en la cuenta "guest" debe existir; "nobody" da
problemas ; en algunos sistemas; una opción es "ftp". ; 6: Ajustar la opción "security =": "share", "user", "server". ; 7: Limitar acceso con "hosts.allow", sobre todo en Internet. ; [global]
server string = Máquina %h con Samba %v printing = bsd printcap name = /etc/printcap load printers = yes guest account = pcguest hosts allow = 10.137.0.0 localhost ;Para tener un archivo de registro para cada cliente ; log file = /usr/local/samba/var/log.%m ;Para permitir acceso múltiple a los mismos archivos se requiere ;un directorio de bloqueos con permisos de lectura para todos ; lock directory = /usr/local/samba/var/locks ; share modes = yes ;Para autenticar contraseñas por una máquina NT ; security = server ; password server = <Servidor-NT> ;Para autenticar con esta máquina UNIX; ;no colocar en este caso "password server" security = user ;Para incluir configuraciones específicas para cada máquina ; include = /usr/local/samba/var/lib/smb.conf.%m ;En algunas situaciones, este ajuste aumenta el rendimiento ; socket options = TCP_NODELAY ;Si se tienen varias interfaces de red en esta máquina ; interfaces = 10.137.107.200/24 10.137.109.200/24 ;o alternativamente ; interfaces = 10.137.107.200/255.255.255.0 \ ; 10.137.109.200/255.255.255.0 ;Para que Samba se anuncie en subredes o redes remotas ; remote announce = 10.137.105.255 192.168.1.255/GR-SAMBA ;Localizador Maestro de Dominio para manejar listas de subredes; ;no debe haber ya un servidor NT haciendo esta tarea domain master = yes ;Para dar ventaja en elección inicial de localizador a Samba preferred master = yes ;Si se tiene un servidor NT como Primary Domain Controller, ; domain master = no ; preferred master = no ; domain controller = <Servidor-NT-PDC> ;Para configurar servicio WINS (única máquina) wins support = yes ;Si ya hay un servidor WINS, para referirse a él ; wins support = no ; wins server = 10.137.137.230 ;Para descargar y ejecutar un archivo de comandos .BAT en Win95 ;o .CMD en WinNT, por máquina %m o por usuario %U. ;Requiere servicio netlogon. ;El archivo de comandos debe estar escrito con cr/lf, estilo DOS. ; logon script = /usr/local/samba/lib/netlogon/%m.bat ;Directorios propios de usuarios, mapeo automático al conectar [homes]
comment = Directorios propios de Usuarios browseable = no read only = no create mode = 0750 ;Para logon a dominio, scripts de logon ;[netlogon] ; comment = Servicio Netlogon ; path = /usr/local/samba/lib/netlogon ; guest ok = yes ; writable = no ; share modes = no ;Todas las impresoras definidas en esta máquina [printers] comment = Todas las Impresoras path = /tmp browseable = no printable = yes public = no writable = no create mode = 0700 ;Directorio accesible a todos sin contraseña, sólo lectura [aplics] comment = Directorio Público sólo lectura path = /export/softaplic writable = no public = yes ;Impresora privada del usuario freddy, quien debe tener permiso de ;escritura sobre el directorio de spool. [fredimp] comment = Impresora de Freddy valid users = freddy path = /homes/freddy printer = fred_imp public = no writable = no printable = yes ;Directorio privado del usuario Fred, quien debe tener permiso de ;escritura sobre el directorio. [freddir] comment = Directorio de Freddy path = /export/privados/freddy valid users = freddy public = no writable = yes printable = no ;Directorio público sólo lectura excepto para el grupo "personal" [interno] comment = Directorio uso interno path = /export/publico/interno public = yes writable = no printable = no write list = @personal ;Un directorio diferente para cada máquina, con la variable %m;
;igual puede hacerse para cada usuario, con %u. [maquinas] comment = Directorios por máquina path = /usr/pc/%m public = no writeable = yes ;Directorio público, lectura escritura para todos; ;los archivos quedan en propiedad del dueño del directorio; ;todos pueden borrar archivos ajenos. [publico] path = /export/pub public = yes only guest = yes writable = yes printable = no
Configuración del kernel
El núcleo o "kernel"
Tipos de kernel
Cuándo configurar el kernel
Configurar kernel en Solaris
Configurar kernel en Linux
Bibliografía
El núcleo o "kernel".
En el sistema operativo UNIX se reconocen tres niveles de abstracción:
- el hardware;
- el núcleo del sistema operativo (kernel);
- los programas de usuario (aplicaciones).
El kernel presenta al usuario o los programas de aplicación una interfaz de
programación de alto nivel, implementando la mayoría de las facilidades requeridas por
éstos. Reúne el manejo de una serie de siguientes conceptos ligados al hardware de
nivel más bajo:
- procesos (tiempo compartido, espacios de direccionamiento protegidos);
- señales y semáforos;
- memoria virtual ("swapping", paginado);
- sistema de archivos;
- tubos ("pipes") y conexiones de red.
Una parte del kernel es independiente de los dispositivos presentes en el sistema, pero
otra contiene los controladores necesarios para manejar partes específicas del hardware.
El kernel intrepreta los pedidos de los programas y los traduce en secuencias de bits
que, presentadas a los registros de los controladores, operan sobre los dispositivos
físicos.
El kernel está escrito casi todo en C, salvo una pequeña parte en lenguaje ensamblador
para los procesos de bajo nivel. El tamaño puede ir desde unos 400 KB hasta más de 15
MB.
Tipos de kernel.
Todos los sistemas permiten indicar al kernel qué hardware encontrará, o cuál no debe
buscar; algunos kernels pueden explorar el sistema por sí solos.
Solaris usa un kernel totalmente modular, y puede cargar los controladores de
dispositivos al momento que se necesitan, gracias a la coherencia de la arquitectura
propietaria de Sun, mucho mayor que la de un computador personal. HP-UX también
puede determinar su hardware sin intervención del administrador. FreeBSD y los UNIX
BSD en general requieren indicación explícita del hardware del equipo; esto resulta a
veces difícil por la poca información técnica que los fabricantes de partes PC proveen a
los usuarios. Linux compila los controladores en el kernel como los BSD, pero también
maneja módulos a la manera de Solaris, aunque no tan limpiamente, debido a las
limitaciones de la arquitectura PC.
En la siguiente tabla se muestra el nombre del directorio donde se compila el kernel
(directorio de compilación), así como nombre y ubicación del kernel para algunos
sistemas ejemplo:
Sistema Directorio de compilación Kernel
Solaris (usa módulos) /kernel/unix
HP-UX /stand /stand/vmunix
Linux /usr/src/linux /vmlinux o /boot/vmlinuz
FreeBSD /usr/src/sys /kernel
Cuando configurar el kernel.
Para la instalación las distribuciones proveen uno o más kernels típicos, adaptados a
grandes grupos de hardware corriente, con muchos controladores y paquetes opcionales
que no se usarán en nuestro sistema particular. Aunque no interferirán con el uso del
sistema, un kernel adaptado a nuestro hardware será más chico, ocupará menos
memoria, y ejecutará más rápido. Si bien los kernels modernos pueden descartar en
parte los controladores innecesarios, sus opciones quedarán activadas. Reconfigurar el
kernel para el hardware específico tiende a optimizar el rendimiento del sistema.
Otras razones para reconfigurar el kernel son la actualización de versiones y el agregado
de nuevos dispositivos físicos. Incorporar un nuevo controlador requiere actualizar las
tablas y estructuras de datos del kernel. En muchas distribuciones esto implica
reconfigurar el kernel; en otras puede bastar correr un programa de inserción de
módulos cargables en tiempo de ejecución.
Configurar kernel en Solaris.
En el arranque el kernel de Solaris sondea los dispositivos e inicializa un controlador
por cada uno de los que encuentra. Mediante la técnica de módulos cargables incorpora
sólo el código correspondiente a los dispositivos físicamente presentes. No obstante, en
algunos casos este automatismo puede fallar, por errores o por no estar previsto ese
dispositivo en particular, haciendo necesaria la configuración manual.
Solaris maneja la siguiente estructura de directorios para la carga de módulos:
/kernel
módulos comunes a máquinas con el mismo conjunto de instrucciones.
/platform/nombre-plataforma/kernel
módulos específicos para un tipo de máquina (reconocido en nombre-
plataforma). Por ejemplo, "Ultra Enterprise". Puede determinarse con uname -i.
/platform/clase-hardware/kernel
módulos específicos para una clase de hardware (reconocido en clase-
hardware). Por ejemplo, sun4u. Puede determinarse con uname -m.
/usr/kernel
similar a /kernel.
Solaris busca el kernel en las vías /platform/nombre-plataforma/kernel:/kernel:/usr/kernel
El nombre del kernel buscado es "unix", y si no se encuentra, "genunix", un kernel más
genérico conteniendo sólo la parte independiente de dispositivos. Los directorios de la
vía contienen una serie de subdirectorios de clasificación de módulos, tales como drv,
misc, cpu, strmod, sparcv9, fs, exec, sched, sys, genunix, unix. Normalmente no es
preciso tocar ningún archivo de estos subdirectorios, a no ser que el fabricante de un
dispositivo lo establezca en forma específica.
El kernel de Solaris se configura en un archivo maestro de nombre /etc/system,
consistente en una serie de variables (fijadas con set) y directivas (palabras reservadas).
Manejar mal este archivo puede impedir el arranque. Con boot -a se intenta arrancar
desde una copia respaldo si se la ha creado previamente.
Un ejemplo de archivo /etc/system simple contendría algo así (excluyendo los
comentarios): rootfs:ufs
sistema de archivos tipo ufs. rootdev:/sbus/@1,f800000/esp@0,800000/sd@3,0:a
dispositivo de arranque sd3a; /dev/sd3a es un enlace al nombre largo usado aquí. moddir: /platform/SUNW/Ultra-Enterprise/kernel:/platform/sun4u/kernel: /kernel:/usr/kernel
vía de búsqueda para los módulos; va en una línea única. forceload: drv/superplotter
fuerza la carga del módulo indicado; exclude fuerza la exclusión de un módulo. set maxusers=64
dimensiona las tablas del kernel para atender un máximo de 64 usuarios
simultáneos.
Una serie de comandos ayudan a encontrar fallas de configuración: prtconf
imprime la configuración general de la máquina, incluyendo las dependencias
entre controladores. sysdef
descripción muy pormenorizada de la configuración de la máquina. Incluye todo
lo mostrado por prtconf. Un impreso de la salida de este comando debe formar
parte de la documentación de máquina. modinfo
informa sobre los módulos cargables dinámicamente; es normal hallar 50 o más.
Esta breve descripción no es suficiente para configurar un kernel Solaris. En la mayoría
de los casos la técnica de módulos cargados dinámicamente hace innecesario
reconfigurar el kernel Solaris, pero si debiera hacerse, leer cuidadosamente la
documentación antes de emprender la tarea.
Configurar kernel en Linux.
La configuración del kernel en Linux se basa en un archivo /usr/src/linux/.config de
críptico contenido. Existen no obstante interfaces más comprensibles basadas en el
comando make: make config
pide una respuesta para cada opción de configuración; no permite corrección;
poco flexible, conviene usar alguna de las otras. make menuconfig
presenta las opciones de configuración en forma de menú con interfaz gráfica en
terminal de caracteres, clasificadas por grupos y con ayuda explicativa sobre
cada una. Cada opción puede compilarse en el kernel (marcada con *) o cargarse
como módulo (marcada con M). Cuando la opción sólo puede tomarse
compilada la propia interfaz así lo hace. make xconfig
como make menuconfig pero en X-Windows. Requiere autorización para root
en el uso del ambiente gráfico.
Los pasos para una compilación de kernel en Linux incluyen: cd /usr/src/linux
trasladarse al directorio de compilación. Puede tener un nombre más específico,
como /usr/src/kernel-source-2.2.17, indicando la versión de kernel a que
corresponden los fuentes; /usr/src/linux suele ser un enlace simbólico al nombre
más específico. make menuconfig
corre la interfaz de configuración. Fijar las opciones deseadas, ya sea internas o
como módulos. La ayuda describe extensamente el significado de cada una,
sugiriendo en muchos casos el ajuste. make dep
resuelve las dependencias entre módulos de compilación en C (código objeto y
encabezados), a más de otras. make clean
asegura el inicio de la compilación en un ambiente limpio de rastros de
compilaciones anteriores (elimina archivos intermedios). Se usa cuando quiere
arrancarse una compilación desde cero, sin reutilizar el código objeto. make bzImage
compila un kernel comprimido de nombre bzImage. Puede crearse un kernel en
disquete sustituyendo este comando por make bzdisk, una opción segura para
probar un nuevo kernel. make modules
compila los módulos marcados en la configuración. make modules_install
instala los módulos compilados. cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz
copia el kernel generado hacia donde se espera encontrarlo en el arranque. Si se
creó en disquete bastará arrancar el equipo con el disquete. vi /etc/lilo.conf
LILO (LInux LOader) es el programa de carga del kernel. Se configura en el
archivo /etc/lilo.conf. Entre sus opciones mínimas debe encontrarse el
dispositivo de arranque (p.ej. /dev/hda3), la ruta y nombre del kernel a arrancar
(usualmente /boot/vmlinuz o /vmlinuz). /sbin/lilo
Instala LILO según la configuración de LILO recientemente ajustada.
Esta breve descripción no es suficiente para configurar un kernel Linux. Debe leerse la
documentación, especialmente el archivo README ubicado en el directorio de
compilación.
Es conveniente disponer de un modo alternativo de arrancar el sistema, por ejemplo en
disquete, antes de recompilar el kernel. Alternativamente, compilar el kernel en
disquete, probarlo y recién después de verificar el correcto funcionamiento de todos los
servicios copiar hacia la ubicación definitiva en disco. Un disquete de arranque se crea
simplemente haciendo cp /usr/src/linux/arch/i386/boot/bzImage /dev/fd0
Un disquete de arranque con el kernel actual se crea igualmente haciendo cp /boot/vmlinuz /dev/fd0
No confiar en estos disquetes hasta no probarlos.
Aún con error de LILO, si disponemos de un kernel sano puede indicarse a LILO su
ubicación, así como otros parámetros. Al aparecer el prompt LILO: escribir algo así
como
vmlinuz root=/dev/hda3 ether=0,0,eth0 ether=0,0,eth1 donde se indica el arranque del kernel vmlinuz ubicado en la partición /dev/hda3, e
intentar reconocer 2 tarjetas de red Ethernet.
Puede existir la opción make install para instalar el kernel en su ubicación definitiva
y correr LILO; esto deja la máquina lista para arrancar con el nuevo kernel. Debe
hacerse sólo después de haber probado el nuevo kernel compilado en disquete.
Impresión
Impresión en UNIX
Términos usuales en impresión
Tipos de impresoras
Impresoras seriales y paralelas
Impresoras de red
Sin PostScript
Impresión BSD
Proceso de impresión BSD
El archivo /etc/printcap
Variables de printcap
Control del ambiente de impresión
Impresión System V
Proceso de impresión System V
Comandos de impresión System V
Eliminar una impresora
Agregar una impresora (BSD)
LPRng
Las impresoras PostScript
Sugerencias
Bibliografía y referencias.
Impresión en UNIX.
En el estado actual de la tecnología las impresoras de matriz de puntos sólo sobreviven en
aplicaciones empresariales, sobre todo cuando son necesarias varias copias; las impresoras
láser, cada vez más accesibles, ofrecen velocidad a buena calidad como impresoras de red; la
impresión barata es chorro de tinta, aunque el alto precio de los cartuchos hace más rentable
la impresión láser cuando se trata de cantidad. El sistema de impresión UNIX, sin embargo, ha
permanecido casi constante frente a estos cambios: la mayoría de los sistemas siguen usando
el esquema típico BSD (lpd, lpc, lpr, ...) o System V (lpsched, lpadmin, lp, ...). Muchos
sistemas proveen comandos cruzados para el manejo de colas de impresión; la manera de
determinar el sistema de impresión es viendo qué demonio está presente: lpd para BSD,
lpsched para System V.
Términos usuales en impresión.
spooler o servidor de impresión: software que recibe los trabajos a imprimir, los almacena en
cola, les asigna prioridades y los envía secuencialmente hacia la impresora. Usa un directorio
de "spool" o almacenamiento intermedio donde se ubican en espera los trabajos a imprimir.
dpi (Dots Per Inch, puntos por pulgada): medida de la resolución o capacidad de
presentación de la impresora, expresada en la cantidad de puntos impresos por pulgada.
Cuanto más cantidad de puntos, mejor se ve el impreso. Suele expresarse como 360 x
720, indicando 360 dpi en la horizontal y 720 dpi en la vertical.
PDL (Page Description Language, lenguaje descriptor de página): lenguaje
comprendido por las impresoras usado para definir una imagen de la página a imprimir.
El PDL hace más eficiente la transmisión, facilita el trabajo de las aplicaciones, es
independiente de dispositivos y de la resolución en dpi. Los más conocidos son
PostScript y PCL.
bitmap: imagen gráfica expresada mediante un conjunto de datos que indican el color
de punto de la imagen. Todo PDL soporta al menos un tipo de bitmap. Los más
conocidos son JPEG, PNG, TIFF y GIF.
RIP (Raster Image Processor, procesador de imagen de barrido): sistema que convierte
PDL a bitmap, apropiado para un dispositivo de impresión en particular. El RIP suele
residir en la impresora.
filtros: programas intercalados en la secuencia del proceso de impresión para realizar
transformaciones en los datos: conversión de formatos de archivo, contabilidad,
comunicación con la impresora. La impresión de un trabajo en PostScript en una
impresora incapaz de interpretar PostScript requiere un filtro específico para la marca y
modelo de la impresora.
PostScript: el PDL más común en UNIX, original de Adobe Systems; muchas
impresoras aceptan PostScript directamente; todas las aplicaciones para diseño de
páginas y publicación generan PostScript . Es un lenguaje completo de programación;
su código puede ser visto con cualquier procesador de texto.
PCL (Printer Command Language): alternativa de Hewlett-Packard para PostScript,
usado en impresoras HP, común en computadores personales. UNIX no genera PCL;
requiere un filtro para convertir desde otros formatos.
roff: no es un PDL, sino un lenguaje para formato de textos, surgido en la época de los
terminales de caracteres. No se usa en documentos nuevos, pero existe mucho ya hecho,
en particular las páginas man de UNIX. GNU produce groff, una versión sin costo de
roff.
Tipos de impresoras.
Las impresoras se clasifican por el tipo de conexión (serie, paralelo, red) y por el formato de
datos que comprenden (texto, PostScript, PCL, otro).
Existen actualmente impresoras baratas con escasa o ninguna inteligencia limitadas para
su uso con Windows (WinPrinters). No convienen ni siquiera usando Windows: cargan
al computador con tareas propias de la impresora. Pasa lo mismo con los WinModem.
Impresoras seriales y paralelas.
Las impresoras seriales requieren intrincados detalles de configuración, como velocidad de
transferencia y otros; es preciso consultar la información de la impresora. La interfaz paralela
de los PCs requieren poca configuración y son más rápidas. La interfaz serial permite cables de
hasta 15 m; la paralela sólo hasta 6 m. USB, una tecnología serial nueva, está apareciendo ya
en las versiones estables de FreeBSD y Linux.
Impresoras de red.
Las impresoras de red disponen de una tarjeta y conexión completa a la red. Dirigir trabajos a
una impresora de red es más rápido que dirigirlos a una impresora local serie o paralela. Como
cualquier máquina puede mandar trabajos a la impresora de red, aparecen problemas de
contención. Conviene mantener el manejo de todas las impresoras bajo unos pocos servidores;
las máquinas restantes envían a los servidores. Hay impresoras láser de red con demonio lpd
incluído, capaces de manejar un spool como cualquier máquina UNIX. Hay impresoras de red
viejas que requieren enviar trabajos de impresión al puerto TCP 9100; ofrecen dificultades de
configuración con BSD y SysV, pero no con LPRng, un nuevo diseño de servidor de impresión
basado en BSD.
Sin PostScript.
Aunque todos los sistemas UNIX generan PostScript la mayoría de las impresoras de chorro de
tinta y las láser de poco precio no lo soportan. El paquete abierto GhostScript es capaz de
convertir PostScript al PDL propio de cientos de impresoras. Al especificar GhostScript como
filtro se debe indicar el nombre del filtro correspondiente a la impresora disponible; hay
documentación y ejemplos en el propio paquete.
Impresión BSD.
El sistema de impresión BSD ha escalado para soportar las impresoras y PDLs actuales,
incluyendo soporte para impresoras compartidas en redes heterogéneas. FreeBSD y Linux
soportan el sistema de impresión BSD.
El proceso de impresión.
En BSD, el acceso a las impresoras es controlado por el demonio lpd: recibe los trabajos
enviados por los usuarios u otros lpd remotos, los procesa y los transfiere a la impresora. lpd
lee la configuración de las impresoras en el archivo /etc/printcap.
Los usuarios envían trabajos de impresión usando el comando lpr. lpr y lpd se
comunican usando el enchufe (socket) /dev/printer. El usuario puede indicar la
impresora destino en el propio comando lpr con la opción -P impresora; si no se
indica, se usa la impresora indicada en la variable de ambiente PRINTER; si ésta no
existe, se usa la impresora por defecto configurada en el sistema (en /etc/printcap).
Una vez determinada la impresora, lpr busca en /etc/printcap la entrada
correspondiente a esa impresora, de la cual obtiene entre otros datos el directorio de
spool donde debe colocar el trabajo, usualmente /var/spool/lpd/nombre_impresora. lpr
crea por cada trabajo dos archivos, uno de control, de nombre cf seguido del número de
trabajo, con información de manejo, y otro con los datos a imprimir, de nombre df
seguido del mismo número. Una vez colocado el trabajo en el directorio de spool, lpr
notifica a lpd la llegada de un trabajo de impresión.
Ante un nuevo trabajo, lpd vuelve a leer /etc/printcap para saber si la impresora referida
es local o remota; si es local, verifica la existencia de un demonio para manejo de la
cola donde se encuentra el trabajo, y si no está lo crea como copia de sí mismo; si es
remota, abre una conexión al lpd de la máquina remota, le transfiere los archivos de
control y datos, y luego borra las copias locales de ambos archivos.
Los trabajos se procesan en orden de llegada. La prioridad puede ser cambiada con lpc
sobre un trabajo en particular; no hay manera de fijar prioridades por máquina origen o
usuario.
Cuando un trabajo está listo para imprimir, lpd crea una serie de tuberías (pipes) UNIX
entre el archivo en spool y el hardware de impresión por las cuales son transferidos los
datos, eventualmente pasando a través de un proceso de filtro capaz de dar formato o
implementar un protocolo específico de la impresora.
El archivo /etc/printcap.
El archivo /etc/printcap es la base de datos maestra del sistema de impresión. Una impresora
debe estar descrita aquí antes de poder recibir trabajos. El formato es el mismo de
/etc/termcap y /etc/remote: el primer item de entrada es una lista de nombres posibles para
la impresora, separados por "|"; luego siguen un conjunto de ajustes separados por ":" , cada
uno de los cuales es de la forma xx=cadena o xx#número, donde xx es un código de 2
caracteres. Los comentarios comienzan con #; una entrada puede abarcar varias líneas si se
usa \ como caracter de continuación.
# Impresora Laser remota en máquina roble en Ingeniería roble-lj4|lping|l-56|HP Laserjet 4 de Ingenieria: \ :lp=:/var/spool/lpd/roble-lj4/.null: \ :rw: \ :sd=/var/spool/lpd/roble-lj4: \ :rm=roble: \ :rp=roble-lj4: \ :lf=/var/adm/lpd-errs:
Los nombres de la primera línea reflejan la práctica de disponer de 3 nombres como
mínimo para cada impresora, con este criterio: un nombre corto para uso en la práctica
(lping); un nombre identificatorio de la máquina anfitrión y tipo de impresora (roble-
lj4); una descripción larga con información adicional (HP laserjet 4 de Ingenieria).
El nombre de impresora lp designa una impresora por defecto a la cual se dirigen todos
los trabajos sin indicación de impresora específica. No conviene usar lp como nombre
primario de una impresora; esto dificulta el cambio de impresora por defecto. En
ausencia de impresora llamada lp la primera en /etc/printcap será la impresora por
defecto si la variable de ambiente PRINTER no indica otra cosa.
Variables de printcap.
La descripción completa de las muchas variables de usadas en el archivo de control de
impresión /etc/printcap se encuentran en la página man printcap. Pueden agruparse en
estas categorías básicas:
especificaciones de archivos y directorios; información para acceso remoto; filtros de impresión; ajustes de comunicaciones; información de página.
sd: (spool directory), directorio de spool o almacenamiento intermedio. Cada impresora debe
tener su directorio de almacenamiento intermedio, aún si la impresora es remota; los trabajos
se almacenan localmente hasta ser transmitidos. El directorio de spool debe crearse a mano,
con permisos 755, dueño y grupo daemon. El directorio de spool contiene, además del trabajo
a imprimir, dos archivos de estado: status y lock. El archivo status contiene una descripción del
estado de la impresora; es mantenido por lpd y consultado por lpq. El archivo de lock existe
para evitar el arranque de más de un demonio lpd para atender la misma cola, y para
mantener información del trabajo en curso.
lf: (log file), archivo de registro de errores. Un archivo común para errores de impresión
basta para todas las impresoras; aún las remotas deben disponer de un archivo de
registro de errores, para registrar fallas de comunicación. Los procesos filtro dirigen sus
errores a otros archivos, según lo especificado en syslog, no en el indicado por este
parámetro.
rw: si la impresora es capaz de emitir información de estado a través de su archivo de
dispositivo, debe especificarse lectura escritura sobre él incluyendo este parámetro en su
descripción.
lp: nombre del dispositivo de impresión. Para impresoras locales debe especificarse el
archivo /dev correspondiente al puerto al que se encuentra conectada. Las impresoras de
red (diferentes de las remotas, se conectan a la LAN, no tienen máquina anfitrión) deben
apuntar a un archivo falso (dummy) para permitir a lpd el bloquear ese archivo como
indicación de que la impresora está en uso. Ejemplo: lp:/var/spool/lpd/roble-lj4/.null
af: (accounting file): la especificación de este archivo permite llevar contabilidad de los
trabajos de impresión, ya sea para cobrar o sólo para conocer la carga sobre el sistema
de impresión. El comando pac resume esta información contable; los números de
página son inciertos, salvo si el filtro es capaz de interrogar a la impresora por su
número de copias antes y después del trabajo, y la impresora es capaz de responder.
mx: tamaño máximo de archivo; no permite inferir nada para archivos PostScript o
PDL. Puede ser necesario colocar mx#0 para habilitar impresiones de tamaño ilimitado.
rm y rp: acceso remoto. rm indica la máquina a la que debe enviarse el trabajo, rp el
nombre de la impresora remota en la máquina donde está conectada. Aún una impresora
de red debe definirse con un único servidor habilitado para enviarle trabajo; un único
demonio lpd maneja la cola en forma más eficiente, evitando el problema de contención
cuando muchas máquinas envían hacia la misma impresora de red. Definir en la
máquina que contiene la impresora una entrada para "remota" que refiera a una entrada
"local" en la propia máquina, con directorios de spool diferentes, es un artificio para
poder usar siempre el nombre de la remota, ya sea en la máquina local o en otra
máquina cualquiera, simplificando la administración y la detección de fallas.
of, if, nf: filtros de impresión. Los filtros son usualmente scripts en lenguaje de shell
que invocan programas de traducción, aceptando el trabajo a la entrada, efectuando la
transformación y devolviéndolo en la salida. El filtro if se invoca una vez por cada
trabajo; es el más común. El filtro of recibe toda la cola de trabajos en una invocación
única; es útil para dispositivos lentos para conectar, actualmente escasos. La presencia
simultánea de ambos hace que of imprima una página de anuncio (banner) e if procese
el archivo. El siguiente ejemplo es un filtro if para imprimir PostScript en una impresora
Epson Stylus, de naturaleza "no PostScript", usando el convertidor de dominio público
ghostscript (gs) para intepretar el PostScript:
#!/usr/local/bin/bash # filtro de entrada para postscript en impresora común /usr/local/bin/gs -q -dNOPAUSE -sPAPERSIZE=a4 -sDEVICE=stccolor -sOutputFile=- -
stccolor es el nombre de controlador para una impresora Epson Stylus Color. Este otro
ejemplo es para una impresora PostScript:
#!/bin/csh -f /usr/local/bin/textps $* | /usr/local/bin/psreverse
El programa textps determina si el contenido a imprimir es PostScript, y si no lo es lo
convierte a PostScript, usando los filtros que se indiquen como parámetros, a través de
$*. Luego, psreverse invierte el orden de las páginas para entregar el trabajo ordenado.
Estos ejemplos son scripts; deben tener permiso de ejecución.
br: (baud rate), velocidad en bauds. Para impresoras seriales, indica la velocidad de la
puerta serial. Ejemplo: br#9600
fc, fs (flag bits), bits de bandera. Para impresoras seriales. Fijan paridad, control de
flujo, duplex, retardos. Funcionan combinados para fijar/quitar bits correspondientes a
cada ajuste; la información se encuentra en la página man tty sección 4. fc es "flag
clear" para apagar bits, fs es "flag set" para prender bits, y la suma octal de fs y fc da
como resultado los bits prendidos.
sh: (suppress header), suprime impresión de página de encabezado.
El archivo printcap admite extensiones: si son necesarias variables no previstas,
interpretadas por los controladores de la impresora, pueden colocarse en
/etc/printcap sin afectar el funcionamiento de lpd ni lpr. Variables no citadas en la
página man deben aparecer en la documentación del controlador de la impresora.
También es posible usar el sistema de impresión como spool para otros tipos de archivo:
Nemeth[2000] cita un caso de uso para música en MP3.
#
#/etc/printcap
#
lx810|lp|lp0|Impresora matriz de puntos LX-810:\
:lp=/dev/lpt1:\
:sd=/var/spool/lx810:\
:mx#0:\
:pl#72:\
:pw#80:\
:sh:\
:hl:\
:lf=/var/spool/lx810/lp-err:\
:af=/var/spool/lx810/lp-acct:
#
hplaser|Impresora HP Laserjet 4 texto:\
:lp=/dev/lpt0:\
:sd=/var/spool/hplaser:\
:mx#0:\
:pl#72:\
:pw#80:\
:sh:\
:sf:\
:lf=/var/spool/hplaser/lp-err:\
:tr=\033&l0H:\
:af=/var/spool/hplaser/lp-acct:
#
pslaser|ps|Impresora HP Laserjet 4 PostScript:\
:lp=/dev/lpt0:\
:sd=/var/spool/pslaser:\
:mx#0:\
:pl#72:\
:pw#80:\
:sh:\
:sf:\
:lf=/var/spool/pslaser/lp-err:\
:if=/var/spool/pslaser/ps_input_filter:\
:tr=\033&l0H:\
:af=/var/account/pslaser-acct:
#
hp550c|Impresora HP Deskjet 550C remota en máquina ohm:\
:lp=:\
:mx#0:\
:rm=ohm:\
:rp=hp550c:\
:sd=/var/spool/hp550c:
#
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 -Pimpresorau 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.
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 é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 adiministrador; 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. o crear la entrada en /etc/printcap; o crear el directorio de spool; fijar dueño, grupo permisos; o probar la impresora: arrancar la cola (lpc start), enviar un archivo corto (lpr),
mostrar la cola de impresión (lpq). Impresora remota.
o crear la entrada en /etc/printcap para impresora remota (rm, rp); o crear directorio de spool; fijar dueño, grupo, permisos; o habilitar en /etc/hosts.lpd del servidor la nueva máquina cliente.
Impresora de red. o fijar número IP de la impresora, según se indique en el manual de la
impresora. o verificar conectividad: la impresora debe responder a ping. o instalar la impresora en un servidor de impresión, como impresora remota. o 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 sustituídos 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 intefaz 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 reutlizació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.
Espacio en disco
El espacio en disco
Aspectos políticos
Monitoreo del espacio en disco
Compresión de datos
"Skulker scripts"
Cuotas de disco
Funcionamiento de las cuotas
Habilitación de cuotas
Fijar cuotas sobre un sistema de archivos
edquota
quota, repquota
Cuotas en NFS
Ejercicios e Investigación
Bibliografía y referencias.
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, monitorarlos. 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 Uniz, compresión menor que gzip, algo más rápido. Usa
codificacion 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 conocizo 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 ésto 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 ésto, 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 ésto:
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, advertiendo a los usuarios sobre uso de espacio en sistemas de archivos
montados vía NFS.
Ejercicios e Investigación.
1. Determine si su sistema dispone del comando quot, quota o alguna forma de determinar el
espacio en disco ocupado por cada usuario. Verifique su funcionamiento con y sin el sistema
de cuotas activado.
2. Investigue la asignación de derechos de sus usuarios en su sistema: si pueden escribir
en otros directorios además del propio, o en más de un sistema de archivos. No olvide
los archivos públicos, como suele ser /tmp, donde puede escribir todo el mundo. Evalúe,
según los resultados, la dificultad para determinar el espacio en disco ocupado por los
usuarios, sobre todo si no dispone de un comando similar a quot.
3. Investigue si su sistema provee algún tipo de "skulker script". Si es así, examine la
documentación o el código para determinar exactamente qué hace. ¿Qué información
debería publicar ante los usuarios antes de utilizar este script?
4. Si su sistema no dispone de "skulker script", ¿cuáles serían los lineamientos para
escribir uno? ¿Con qué privilegios y de qué forma debería correr? ¿Cuáles son sus
riesgos potenciales, ya sea por omisión (no borrar lo que se debiera) o por exceso
(borrar lo que no se debe)?
5. Investigue la disponibilidad de cuotas en su sistema. Estudie sus comandos y realice
una prueba, limitando el uso de disco de un usuario irreal. Verifique el funcionamiento,
si existen los límites soft y hard, el tiempo de permanencia por encima del límite soft.
6. Intente efectuar medidas de la influencia del sistema de cuotas sobre el rendimiento
en el servicio de archivos. A modo de sugerencia, puede escribirse un script que realice
una serie de operaciones de copia imprimiendo la hora al principio y al final, y luego
correrlo con y sin cuotas habilitadas. ¿Se obtiene algún resultado significativo? ¿Cómo
puede mejorarse la medida? ¿Qué factores pueden estar falseando los resultados?
7. ¿Dispone sus sistema de alguna facilidad para el almacenamiento de datos fuera de
línea? ¿Es accesible a todos los usuarios? ¿Es difícil de manejar? ¿Es complicado
recuperar datos? ¿Existe algún instructivo? ¿Los usuarios saben que existe? ¿Lo
utilizan? Determine si es posible mejorar las respuestas a estas preguntas.
Bibliografía y Referencias.
Páginas man: quot, df, du; gzip, compress, zip, bzip2; quota, edquota, repquota, quotacheck,
quotaon, quotaoff, rquotad.
Archivos: quota, quota.user, quota.group, /etc/fstab (BSD), etc/vfstab (system V).
Nociones de Seguridad
Introducción
Daremos una muy breve introducción a algunos de los temas que deben ser tomados en
cuenta para planificar la seguridad de nuestros sistemas. Debe quedar claro que, como
introducción que es, solo pretende motivar al lector sobre la necesidad de estudiar la
seguridad de nuestros sistemas.
El primer hecho a tener en cuenta es que el sistema operativo UNIX no fue diseñado pensando
en la seguridad, sino en la conveniencia y la facilidad de uso en un ambiente de confianza
relativa, y por ello es imposible hacerlo 100% seguro. Sin embargo, muchas cosas pueden
hacerse para hacer que nuestros sistemas sean más resistentes a los ataques.
Siempre existe un compromiso entre la seguridad que ofrece un sistema y la facilidad y
conveniencia de su uso.
En cada caso, es necesario evaluar cuál es el nivel de seguridad requerido y actuar en
consecuencia. No son iguales los requerimientos de seguridad de un sistema personal ubicado
en nuestro hogar, a los de un sistema militar, o a los de un equipo controlando procesos
industriales. En cada caso, es necesario plantear políticas de seguridad adecuadas tanto para
los administradores como para los usuarios del sistema.
Enfoque del problema
Lo primero que debe tener claro un administrador es qué es lo que debe ser protegido, y qué
se puede perder. Las pérdidas pueden ser tanto pérdidas monetarias (directas, como pérdida
del equipo, si este es robado o inutilizado completamente, o indirectas, por pérdida de
confiabilidad de la empresa, pérdida de negocios, etc.), pérdida de información (secretos de
empresa, información personal, etc.), o pérdida de "uso" (el costo de no poder brindar el
servicio). En cada caso las soluciones serán distintas.
También debemos pensar de quién lo debemos proteger, y las rutas de acceso existentes.
Podemos tener tanto amenazas externas (directas o a través de redes) como internas a
nuestra organización (tanto usuarios maliciosos, como usuarios inexpertos o herramientas con
bugs que causan daño inintencionalmente, como programas trojanos que dicen realizar una
tarea y en realidad realizan otras).
Una buena estrategia de seguridad es un conjunto de políticas que prevengan todas las
amenazas relevantes, en la medida que puedan ser prevenidas, y en la medida en que nuestra
organización y nuestros usuarios estén dispuestos a aceptar los inconvenientes que presenten
dichas medidas de seguridad; y que nos permita recuperarnos en el caso en que lo peor
suceda.
La seguridad debe verse como un proceso y no como algo que se puede instalar y olvidar.
Reglas de sentido común
No poner en nuestro sistema archivos que sean interesantes para hackers o usuarios entrometidos. En caso que sea necesario tenerlos disponibles, redoblar los esfuerzos de seguridad, de ser posible encriptando los datos o haciendolos inaccesibles o inutilizables externamente.
Eliminar los agujeros de seguridad que puedan ser utilizados para ganar acceso a nuestro sistema. Para ello, debemos estar al tanto de los boletines de seguridad correspondientes a nuestro sistema y otras fuentes de información.
No permitir sitios donde los hackers tengan acceso. Eso incluye cuentas públicas, directorios de ftp público con permiso de escritura, cuentas grupales, etc.
Poner "trampas" básicas en sitios accesibles (especialmente desde internet). Utilizar herramientas como tripwire, COPS, etc para ser capaces de detectar intrusiones en sus primeras fases.
Monitorear los reportes de estas herramientas. No confiar en "recetas mágicas". Aprender acerca de la seguridad en UNIX y no dejarse
atrapar por recetas mágicas de "consultores en seguridad" que muchas veces lo único que nos dejan es un falso sentimiento de seguridad. No es que todos los consultores nos vayan a engañar, pero debemos desconfiar si nos prometen que una única acción nos dejará protegidos "para siempre".
Minimizar los servicios que brinda nuestra máquina, no habilitando servicios innecesariamente, especialmente en los equipos expuestos a un ambiente hostil.
Ser "curioso", investigar toda actividad fuera de lo común en nuestro sistema, mensajes extraños en los logs, actividad de usuarios que se encuentran de vacaciones, etc.
Planear de antemano qué hacer en caso de un compromiso a la seguridad, y disponer de respaldos confiables del sistema en un estado conocido.
Líneas de defensa
Acceso físico a la computadora.
La primer línea de defensa es el acceso físico a la propia máquina. Esto puede variar desde
mínimas prevenciones para que no nos roben la máquina o la rompan, pasando por evitar el
acceso de personal no autorizado a la consola y la CPU (por ejemplo para evitar que se pueda
apagar y prender la máquina para reiniciarla en modo "single-user"), hasta aquellas
instalaciones en que el acceso a las computadoras está limitado por varios sistemas de
seguridad y guardias armados, como puede suceder en algunas instalaciones militares.
Aunque en la mayoría de las instalaciones no es necesaria tanta "paranoia", al menos es
necesario evitar que nos apaguen la máquina, y es conveniente que las consolas y terminales
esten "a la vista", para que los posibles "hackers" vean su accionar mas controlado.
Validación de usuarios y passwords.
La siguiente línea de defensa, una vez que se obtuvo acceso a la máquina (permitido o no) es la
validación de acceso a los usuarios. Esta validación tiene como objeto verificar que quien
pretende dar comandos a la máquina es un usuario autorizado para hacerlo.
Normalmente, esta validación se realiza solicitando al usuario un nombre de cuenta y una
contraseña, que son chequeadas contra las que el sistema tiene guardadas. Tradicionalmente
los datos del usuario (su cuenta y su contraseña encriptada) se guardaban en el archivo
/etc/passwd, donde son legibles por todos los usuarios (esto es necesario para el
funcionamiento de varias utilidades del sistema). El método de encriptación es "en un solo
sentido", es decir que no existe un algoritmo conocido que permita obtener la contraseña
original a partir de la encriptada (otro que probar hasta que se encuentre la correcta). Sin
embargo, hoy en día en que con computadoras de muy bajo costo se pueden probar varios
miles de encriptaciones por segundo, el hecho de que la password encriptada esté disponible
para cualquiera se presta a ataques mediante "metodos de fuerza bruta", encriptando
palabras de un diccionario y comparándolas con la password encriptada.
Para que estos ataques no sean exitosos, es necesario que las passwords de los usuarios sean
bien elegidas. Son malas elecciones las passwords muy cortas, aquellas que contienen palabras
que se encuentran en un diccionario, modificaciones triviales de estas, palabras que se
encuentran en los datos del usuario en el sistema, datos personales del usuario, y cualquier
otra información fácilmente relacionable con el usuario.
Para mitigar este problema, la mayoría de los sistemas modernos proveen el mecanismo de
"shadow passwords", en donde el archivo /etc/passwd contiene los datos del usuario EXCEPTO
la contraseña, y existe otro archivo, con permisos mucho mas restrictivos, donde se encuentra
la contraseña e información adicional del usuario. El único acceso a estas contraseñas es para
verificar la validez de una contraseña dada a través de funciones del sistema, las cuales son
artificialmente lentas para minimizar el riezgo de un ataque por la fuerza bruta.
Otro problema que puede presentarse es el de la existencia de cuentas colectivas (es decir
cuentas utilizadas por varias personas) y cuentas "públicas" (cuentas de usuario sin password
que supuestamente pueden realizar muy pocas cosas). Estas se deben evitar en la medida de
lo posible.
Otro tema importante a tener en cuenta es cómo se eligen las contraseñas, especialmente la
de root, y cada cuanto estas son cambiadas. Muchos sistemas proveen opciones para forzar a
los usuarios a no utilizar contraseñas triviales, a cambiarlas a intervalos de tiempo regulares
(password aging), y a no reutilizar contraseñas anteriores.
El sistema de validación debe ser monitoreado regularmente para verificar que no ha sido
modificado ilegalmente. Especialmente deben buscarse usuarios con UID 0 (superusuario,
independientemente de como se llame), usuarios sin contraseñas, etc.
Existen sistemas de validación avanzados para necesidades específicas, que se pueden agregar
a varios sistemas. Estos varían desde sistemas con multiples niveles de passwords, a sistemas
con acceso mediante tarjetas o reconocimiento biométrico. Muchos de estos sistemas,
extremadamente caros hace unos años, son cada día más accesibles económicamente.
Protegiendo archivos y el filesystem.
Una vez que se tiene acceso al sistema, la siguiente línea de defensa es la protección brindada
por los permisos en los archivos y filesystems. Esto es válido tanto para minimizar el daño que
pueda ocasionar alguien que logró acceder ilegalmente a nuestro sistema, como para
protegernos de nuestros propios usuarios.
En general, el objetivo de toda medida de seguridad en un sistema es evitar que la gente haga
cosas que no debería. Esto principalmente significa evitar acceso a la cuenta de root (directa o
indirectamente) y a los archivos del sistema.
En UNIX clásico, la seguridad es "ON/OFF". Existe un único usuario con permisos globales para
realizar cualquier tarea sobre el sistema (el usuario con UID 0, usualmente llamado root), y los
demás usuarios tienen solamente permisos correspondientes a las tareas específicas que
pueden realizar, otorgados mediante permisos en los archivos del filesystem. No es posible
fácilmente delegar tareas de administración puntuales (aunque existen utilidades como "sudo"
que nos permiten delegar ciertas tareas). Eso hace que el acceso a la cuenta de root deba ser
extremadamente controlado.
En algunas variedades de UNIX existen agregados que permiten dividir la responsabilidad con
una mejor granularidad, usualmente mediante permisos más granulares en el filesystem (Listas
de control de acceso, ACL's), y mediante la separación de los poderes "omnipotentes" de root
en un conjunto de "capabilities" que se pueden asignar independientemente.
Problemas con el path
Una forma de subvertir la seguridad del sistema es hacer que root u otros usuarios ejecuten
comandos inadvertidamente. Una forma de lograr esto es colocar programas con el mismo
nombre que algún comando del sistema en un directorio que se encuentre antes en el path
que el directorio del programa original (y que pueda ser escrito).
Por ello, es importante que en el path el directorio actual (".") y los directorios relativos no se
encuentren en el path, o que se encuentren al final del path.
Además, es importante que ninguno de los directorios en el path de root se pueda escribir por
alguien que no sea root, nuevamente para evitar que se pueda sustituir un comando estandard
por otro programa.
Permisos en los archivos del sistema
Los sistemas UNIX dependen de una cantidad de archivos para su correcto funcionamiento, y
los permisos en dichos archivos deben ser adecuados. Algunas áreas a ser tomadas en
consideración son:
Los archivos de arranque del sistema. En ellos se ejecutan todos los comandos necesarios para el funcionamiento normal multiusuario del sistema, y normalmente se arrancan los servicios que el equipo brinda. Estos archivos se ejecutan con permisos de root cada vez que se inicia el sistema, y por lo tanto deben ser de escritura solo para root (así como el directorio donde están contenidos) (en algunos sistemas el grupo system o similar puede tener permiso de escritura).
Los archivos de configuración de los distintos servicios que brinda el sistema. Cambiando la configuración de los programas que brindan determinados servicios (muchas veces corriendo como root) se los puede obligar a cambiar su comportamiento en forma no esperada, dar servicio a usuarios o máquinas en los que normalmente no se confía, o hacer que no funcionen.
Los archivos relativos a la validación de usuarios. Tanto el archivo de passwords (que debe ser solo de escritura para root) como los archivos adicionales de otros sistemas (como las "shadow passwords" que para cumplir su cometido no deben tener permisos de lectura para ningún usuario excepto root) deben tener los permisos adecuados. Recordemos que en casi todos los sistemas de validación alcanza con que un usuario tenga uid=0 para que tenga los mismos derechos de acceso total sobre el sistema que root.
Los archivos del directorio /dev. En el directorio /dev están representados todos los dispositivos del sistema, y el acceso a varios de ellos permite el acceso "directo" al hardware de la máquina. Por ejemplo, en muchos sistemas el archivo /dev/kmem o /dev/mem representa la memoria del sistema, es decir que el poder leer dicho dispositivo nos permite ver toda la información que el sistema tenga en la memoria (como por ejemplo la password que acabamos de teclear). Otros dispositivos que pueden darnos acceso a datos "sensitivos" son los correspondientes a los discos y particiones. Con el suficiente conocimiento teniendo acceso a dichos dispositivos se puede leer cualquier archivo del filesystem.
Otro grupo de archivos a ser tomado en especial consideración es el de los archivos setuid y
setgid, especialmente los programas setuid cuyo dueño sea root. El sistema setuid y setgid
permite, bien administrado, dar acceso limitado al sistema en forma temporal, comando por
comando (por ejemplo, el comando passwd, setuid a root, permite que el usuario modifique el
archivo de passwords, pero solo para cambiar su contraseña). Sin embargo, también pueden
representar un serio compromiso a la seguridad, tanto por problemas de diseño como por
problemas de programación. Los comandos suid no deben permitir realizar ninguna otra
operación además de la que fueron diseñados para realizar.
Esta lista no es en absoluto exhaustiva, se debe investigar cuales son los archivos
"importantes" en nuestro sistema.
Uno de los puntos importantes, en un sistema que deba ser seguro, es minimizar los
servicios y programas instalados, para disminuir la probabilidad de que se encuentre una
vulnerabilidad en un servicio que tengamos instalado.
Permisos en otros archivos
Muchos otros archivos deben tener permisos adecuados. En particular los archivos de
inicialización (.login y .cshrc o .profile) del shell que el usuario ejecute normalmente no debe
poderse escribir por otros usuarios (para evitar que se puedan agregar ahi comandos por parte
de otros usuarios).
Por supuesto, debe también ponerse cuidado en los permisos de los archivos sensibles que
podamos tener en nuestro sistema, y proteger la privacidad de nuestros usuarios. Por ejemplo,
los permisos en los mailboxes de los usuarios no deben poder ser leídos por ningún usuario
que no sea el dueño
Otras medidas
Existen algunas medidas para minimizar los daños en caso que la seguridad del sistema sea
violada.
Una forma de evitar que los datos que alguien nos pueda "robar" puedan ser utilizados
es mediante encriptación. Si se elige un algoritmo adecuado (y no se guardan las claves
en el sistema), se puede tener una razonable certeza que los datos robados no podrán ser
utilizados por otros. La mayoría de los sistemas proveen programas de encriptación
básicos, y existen múltiples programas de dominio público para implementar los
algoritmos mas conocidos de encriptación.
La otra medida importante en muchos casos para minimizar los daños es tener una
buena política de backup, que nos permita recuperar rápidamente los servicios perdidos
(y restaurar nuestro sistema a un estado conocido).
La Seguridad y las Redes
Cuando una máquina está conectada a una red, se agregan un conjunto de posibles problemas
a la seguridad, especialmente si no tenemos control sobre todas las partes de dicha red (como
es el caso en una red pública como puede ser Internet).
Hay diversas clases de ataques que pueden provenir de una red. Principalmente los podemos
dividir en aquellos en que se compromete la seguridad de los datos contenidos en el sistema o
el sistema en sí, y aquellos en lo que se compromete es el servicio que el equipo brinda (denial
of service attacks). Estos últimos se basan ya sea en explotar errores en los programas que
atienden dichos servicios, errores en el sistema en sí, o deficiencias en los protocolos que se
utilizan en la red, y no los trataremos aquí.
Relaciones de confianza y las utilidades r*
Todas las utilidades r* (rlogin, rexec, rsh, rcp) hoy en día se consideran inseguras, solamente
aptas para su utilización en redes locales no expuestas a amenazas de seguridad.
Por defecto, cuando un usuario desea acceder otros hosts en la red, se le solicita una
password. Esto es así tanto si se desea loguearse de forma remota (mediante rlogin)
como si se desea ejecutar comandos remotos mediante rsh. Además, no se puede utilizar
rcp, ya que este no sabe como pedir passwords.
Para permitir el acceso remoto sin passwords, existe un sistema de "equivalencia de
hosts" conectados mediante TCP/IP. El sistema determina el permiso para que un
usuario remoto se conecte mirando en dos archivos, /etc/hosts.equiv y el archivo .rhosts
en el directorio home del usuario. Dichos archivos deberán ser construidos de acuerdo a
la seguridad requerida del sistema.
Equivalencia entre máquinas: /etc/hosts.equiv
El primer nivel de equivalencia es a nivel de máquinas. Cada máquina tiene un archivo
/etc/hosts.equiv, el cual es simplemente una lista de máquinas, uno por línea, que
consideramos equivalentes a la nuestra en cuanto a los usuarios y su seguridad.
En este archivo se pueden poner todas las máquinas de nuestra red, ninguna, o aquellas que
nosotros queramos. Cuando un usuario de un equipo remoto intenta un acceso mediante
rlogin, rsh o rcp, el sistema verifica si la máquina pidiendo acceso se encuentra en el archivo
/etc/hosts.equiv. Si así es, y hay una cuenta de usuario en el sistema con el mismo nombre que
el usuario remoto, se permite el acceso sin solicitar contraseña. Esto funciona para todas las
cuentas EXCEPTO la de root.
Esta equivalencia efectivamente significa que las cuentas con el mismo nombre en el sistema
remoto que en el local son equivalentes. Por ello, solo se debe utilizar este sistema si los
usuarios son los mismos en ambos sistemas, y si podemos confiar plenamente en la seguridad
del sistema remoto.
Los sistemas de equivalencia entre máquinas, y en especial los servicios de rlogin, rsh y rcp,
están siendo paulatinamente sustituidos con servicios con mejores prestaciones de seguridad
(mayormente SSH), y solo se deben utilizar en redes locales en las que no tengamos equipos
potencialmente maliciosos (es decir, un ambiente de alta confianza).
Equivalencia entre cuentas: el archivo .rhosts
La equivalencia a nivel de cuentas se obtiene utilizando el archivo .rhosts en el directorio home
del usuario en el equipo destino. Cada línea de este archivo consiste de un nombre de host y,
opcionalmente, una lista de nombres de usuario.
maquina [usuario. . .]
Cada línea significa que usuario tiene permitido conectarse a esta cuenta desde máquina.
Si usuario no esta presente, solo el mismo nombre de usuario puede conectarse desde
máquina.
Si se intenta un acceso remoto, primeramente se verifica la equivalencia a nivel de
máquina, y de no pasar este acceso se intenta con el archivo .rhosts del directorio home
del usuario hacia el cual se está intentando el acceso.
Se recomienda NUNCA utilizar la equivalencia de cuentas para el superusuario.
Vale el mismo comentario anterior, sobre la paulatina desaparición de los comandos r*
Implicaciones de la confianza
Una relación de confianza entre máquinas siempre implica un riezgo. Sin embargo, en este
caso ese riezgo va más allá del equipo en el cual explícitamente estamos confiando. La
confianza actua en forma transitiva, ya que si máquina1 confía en máquina2, y esta a su vez
confia en máquina3, implícitamente máquina1 está confiando en máquina3, y transitivamente
en todos los hosts en que máquina3 confíe.
Esta es una razon por la cual las relaciones de confianza deben ser establecidas con mucho
cuidado.
Sustitución de los comandos r*
Hoy en día, la utilización de los comandos r* (rcp, rsh, rcp, etc.) se desaconseja en cualquier
servicio que se encuentre accesible desde una red no confiable.
Usualmente, se utilizan protocolos más seguros, como los utilizados por ssh, para mejorar la
seguridad de los sistemas. Los protocolos ssh (hoy en día, versión 2), proveen:
- Encriptación de los datos que circulan en la red. En ningún momento pasan en claro
por la red ni datos ni contraseñas.
- Validación de los equipos servidores mediante claves públicas.
- Validación de los usuarios ya sea por pares usuario/contraseña, como (opcionalmente),
mediante certificados de clave pública.
Además, este protocolo está diseñado teniendo en cuenta la seguridad desde el
principio, a diferencia de los comandos r*.
No es conveniente utilizar los protocolos SSN versión 1, ya que además de ser mas
débiles desde el punto de vista de la seguridad, existen ataques contra versiones viejas
de los servidores ssh de versión 1.
Seguridad y la NIS
NIS, por su propia naturaleza de servicio de información de facil acceso y por su
implementación, es un servicio inherentemente inseguro. Aun NIS+, que fue pensado como un
reemplazo para NIS con mayor seguridad (y otras mejoras), es también un servicio con
problemas de seguridad.
No debería permitirse el acceso a la NIS a máquinas de las cuales no confiemos en su seguridad
o máquinas donde tengamos usuarios no confiables.
Seguridad y NFS
NFS, como la mayoría de los servicios, requiere de una adecuada configuración para ser
seguro. Se debe prestar atención al archivo /etc/exports, donde se configura a qué máquinas
les permitimos acceder a nuestros discos (implícitamente, confiando en la seguridad de dichos
equipos).
En tiempos no tan lejanos, también ha habido algunos ataques a implementaciones de NFS con
bugs, y se debe verificar estar corriendo una versión que sea segura.
Seguridad y sendmail
Tradicionalmente, Sendmail ha sido blanco de muchos ataques, los cuales explotaban diversas
vulnerabilidades y bugs en el mismo. Las últimas versiones de Sendmail se consideran
relativamente seguras, pero hay que asegurarse de estar razonablemente actualizados.
Seguridad y DNS
Idem al sendmail, hay que mantenerse actualizados.
Firewalls.
Un firewall es una estructura de red pensada para minimizar los riezgos a los equipos de
nuestra red.
La estructura clásica de un firewall presenta 3 zonas con diferentes niveles de seguridad,
separadas por filtros a los paquetes IP:
- Una zona pública, accesible directamente desde las redes "no confiables". Idealmente
en esta zona se encuentran solamente los equipos que nos unen a otras redes.
- Una zona desmilitarizada, donde se encuentran aquellos equipos que precisan tener
comunicación con las redes "no confiables", por ejemplo los servicios que brindamos
hacia el exterior, y aquellos servidores que nos permiten obtener servicios desde las
redes "no confiables" (servicios proxy, servidores de correo, DNS, etc.)
- Una zona privada, donde se encuentran nuestras máquinas, las cuales (idealmente) no
tienen ningún contacto directo con las redes "no confiables", sino que obtienen todos
sus servicios a través de los servidores proxy.
Muchas veces, al armar un Firewall, se utilizan equipos UNIX para uno o varios de
estos equipos (tanto los filtros como los servicios en la zona desmilitarizada). Es
EXTREMADAMENTE IMPORTANTE maximizar los cuidados en la configuración de
estos equipos y en la configuración de los filtros.
Instalando una máquina UNIX
- Instalar solamente aquellas aplicaciones necesarias.
- Deshabilitar todos los servicios de red que no precisemos.
- Hacer uso de las utilidades de "hardening" que algunos sistemas proveen.
- Utilizar herramientas como Tripwire para poder detectar cambios maliciosos en nuestro
sistema.
- Si estamos expuestos a redes no confiables, utilizar las utilidades de filtrado de paquetes y
conexiones que provea nuestro sistema (packet filtering, tcp_wrappers, etc.)
- Familiarizarnos con el funcionamiento normal de nuestro sistema.
Ejercicio:
Ejecute "netstat -a" en un equipo unix que usted administre. ¿Puede usted describir qué
programa tiene abiertos cada uno de los puertos TCP y UDP habilitados sobre interfaces de red
(no loopback)?
Algunas herramientas para ayudarnos a administrar la seguridad.
COPS crack tcpd tcp_wrappers tripwire Kerberos Satan ssh
Monitoreo del sistema
Es necesario monitorear el sistema regularmente tanto para detectar intentos de
comprometer nuestra seguridad, como para minimizar los daños de una intrusión en curso.
No existen reglas absolutas acerca de qué se debe monitorear. Eso depende mucho de que
sistemas y servicios tenemos funcionando, y que es lo "normal" en nuestro sistema. La
principal recomendación es que debemos familiarizarnos con el funcionamiento normal de
nuestro sistema, y verificar cualquier actividad o cambio "sospechoso".
Algunas cosas a monitorear:
Cambios en los archivos del sistema Actividad extraña o en horarios extraños REVISAR LOS LOGS DEL SISTEMA Muchos reintentos para loguearse. Usuarios haciendo su. Saber que es normal y que no.
Manteniéndose informado.
Nuevos bugs y problemas cert advisories. (www.cert.org) ciac (www.ciac.org) bugtraq ([email protected]) sun-managers ([email protected]) http://www.ers.ibm.com/ (IBM) Otros
Arranque y detención
Arranque del sistema
Arranque automático y arranque manual
Pasos del proceso de arranque
Inicialización del núcleo (kernel)
Configuración del hardware
Procesos del sistema
Intervención del operador (solo en arranque manual)
Archivos de arranque (scripts rc)
Operación en multiusuario
Scripts rc
Scripts rc estilo System V
Problemas de arranque
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
Detención del sistema
Apagar la llave del equipo
shutdown
halt
reboot
Enviar al proceso init la señal TERM
Cambiar el nivel de ejecución (System V)
Matar el proceso init
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.
Arranque 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 proceos 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 procesoinites 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.
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.