ر ز ×طض سز ث ×ط ر ×

Transcripción

ر ز ×طض سز ث ×ط ر ×

DEPARTAMENTO DE SISTEMAS INFORMATICOS
Y COMPUTACION
Administracion de Sistemas
RedHat Linux 6.2 y
Windows NT 4.0
Agust
n Espinosa Minguet
Andr
es M. Terrasa Barrena
Apuntes y Actividades Practicas de
las Asignaturas CSO (FI) y AUW (EUI)
Curso Academico 2000/2001
Valencia, 1 de febrero de 2001
Indice General
1 Introduccion
1
1.1 Profesorado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2 Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3 Evaluacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.4 Horarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.5 Pagina Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Los Discos Duros
5
2.1 Geometra del Disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2 Lmites a la Geometra de los Discos IDE . . . . . . . . . . . . . . . . . . .
6
2.3 Problemas Causados por Lmites a la Geometra de los Discos IDE . . . . .
7
2.4 Particiones del Disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.5 Utilizacion de las Particiones . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.5.1
DOS, Windows 95, 98 y NT . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.2
Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Utilizacion de los Discos en el Laboratorio de Practicas . . . . . . . . . . . 10
3 Usuarios y Proteccion en Linux
13
3.1 La Tabla de Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 La Extension de la Tabla de Usuarios . . . . . . . . . . . . . . . . . . . . . 14
3.3 La Tabla de Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
i
INDICE GENERAL
ii
3.4 Procedimientos para la Creacion de Grupos y Usuarios . . . . . . . . . . . . 15
3.5 Atributos de Proteccion de los Procesos . . . . . . . . . . . . . . . . . . . . 16
3.6 Atributos de Proteccion de los Ficheros . . . . . . . . . . . . . . . . . . . . 16
3.7 Las Reglas de Proteccion Basicas . . . . . . . . . . . . . . . . . . . . . . . . 18
3.8 Cambio de Atributos de Proteccion en Ficheros . . . . . . . . . . . . . . . . 18
3.9 Los Bits SETUID y SETGID en Ficheros Ejecutables . . . . . . . . . . . . 19
3.10 El bit SETGID en Directorios . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.11 La Mascara de Creacion de Ficheros . . . . . . . . . . . . . . . . . . . . . . 20
3.12 La Estrategia de los Grupos Privados . . . . . . . . . . . . . . . . . . . . . . 20
3.13 Sintaxis y Funcionamiento de los Mandatos Unix Relacionados . . . . . . . 21
4 Usuarios y Proteccion en Windows NT
25
4.1 Conceptos de Usuario y de Cuenta de Usuario . . . . . . . . . . . . . . . . . 25
4.2 Grupos de Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Permisos y Derechos (o Privilegios) . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Asignacion de Permisos a Archivos y Directorios . . . . . . . . . . . . . . . 30
4.5 Mandatos NT para la creacion de usuarios y grupos . . . . . . . . . . . . . 33
5 Dominios en Windows NT
35
5.1 Concepto de Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Usuarios y Grupos en un Domino . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Ordenadores Miembros de un Dominio . . . . . . . . . . . . . . . . . . . . . 39
5.4 Comparticion de Recursos entre Sistemas NT . . . . . . . . . . . . . . . . . 39
5.5 Conanzas entre Dominios NT . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.6 Mandatos NT para compartir recursos . . . . . . . . . . . . . . . . . . . . . 43
6 Niveles de ejecucion en Linux
45
6.1 Inicio y Detencion de un Sistema Linux . . . . . . . . . . . . . . . . . . . . 45
6.2 El Concepto de Nivel de Ejecucion . . . . . . . . . . . . . . . . . . . . . . . 45
6.3 Ficheros y Directorios de Conguracion de los Niveles de Ejecucion . . . . . 47
6.4 Secuencia de Arranque de un Sistema Linux . . . . . . . . . . . . . . . . . . 47
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
on de Sistemas, DSIC, UPV
INDICE GENERAL
iii
6.5 Secuencia de Entrada en un Nivel de Ejecucion . . . . . . . . . . . . . . . . 48
6.6 Conguracion de los Niveles de Ejecucion . . . . . . . . . . . . . . . . . . . 49
7 Montaje de Dispositivos en Linux
51
7.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.2 Utilizacion Basica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.3 La tabla de Montaje de Dispositivos . . . . . . . . . . . . . . . . . . . . . . 52
7.4 Montaje de directorios remotos va NFS . . . . . . . . . . . . . . . . . . . . 54
7.5 Otros mandatos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8 Dominios en Linux
55
8.1 Concepto de Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.2 Network Information System (NIS) . . . . . . . . . . . . . . . . . . . . . . . 55
8.2.1
Instalacion de los Componentes NIS Server . . . . . . . . . . . . . . 56
8.2.2
Conguracion del Servidor de NIS . . . . . . . . . . . . . . . . . . . 56
8.2.3
Conguracion del Cliente de NIS . . . . . . . . . . . . . . . . . . . . 57
8.3 Network File System (NFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
8.3.1
Como Funciona NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.3.2
Instalacion y Conguracion del Cliente NFS . . . . . . . . . . . . . . 59
8.3.3
Instalacion y Conguracion del Servidor NFS . . . . . . . . . . . . . 60
9 Conguracion de Samba
63
9.1 >Que es samba? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.2 Instalacion de Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.3 Conguracion de Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9.4 Instalacion y Conguracion de swat . . . . . . . . . . . . . . . . . . . . . . 66
9.5 Niveles de Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.6 Conguracion de Samba con el Nivel de Seguridad domain . . . . . . . . . . 68
9.7 Tratamiento de los Accesos como Invitado . . . . . . . . . . . . . . . . . . . 69
9.8 El Sistema de Ficheros SMB para Linux . . . . . . . . . . . . . . . . . . . . 70
9.9 Opciones del Servidor Samba . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
INDICE GENERAL
iv
9.10 Opciones del Recurso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
10 Servicio de Nombres de Internet de Windows
73
10.1 Descripcion Basica de WINS . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.2 Servidores de Duplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
10.3 El Proceso de Registro, Renovacion y Liberacion . . . . . . . . . . . . . . . 76
10.4 El Proceso de Resolucion de Nombres . . . . . . . . . . . . . . . . . . . . . 77
10.5 Instalacion del Servidor y de los Clientes WINS en NT . . . . . . . . . . . . 77
11 Servicio DHCP en Windows NT
79
11.1 Descripcion Basica de DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 79
11.2 Concepto de Ambito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
11.3 Instalacion del Servidor y de los Clientes DHCP en NT . . . . . . . . . . . 81
11.4 El Administrador DHCP de NT . . . . . . . . . . . . . . . . . . . . . . . . . 82
11.5 La Utilidad ipconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
ANEXOS
c Agust
n Espinosa, Andr
es Terrasa, 2001
85
Administraci
Indice de Figuras
5.1 Ejemplo de relacion de conanza entre dominios NT. . . . . . . . . . . . . . 42
6.1 Editor de niveles de ejecucion (panel de control) de RedHat linux. . . . . . 49
9.1 Fichero /etc/smb.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
10.1 Servidores de Insercion y Extraccion en WINS. . . . . . . . . . . . . . . . . 76
11.1 Ejemplo de la utilidad ipconfig. . . . . . . . . . . . . . . . . . . . . . . . . 83
v
Indice de Tablas
4.1 Derechos iniciales y habilidades preinstaladas de los gruos en NT . . . . . . 29
4.2 Permisos estandar sobre directorios en Windows NT . . . . . . . . . . . . . 31
4.3 Permisos estandar sobre archivos en Windows NT . . . . . . . . . . . . . . 32
5.1 Diferencias entre grupos globales y locales en Windows NT . . . . . . . . . 38
6.1 Niveles de ejecucion en RedHat Linux. . . . . . . . . . . . . . . . . . . . . . 46
7.1 Principales tipos de particiones utilizables desde Linux. . . . . . . . . . . . 52
7.2 Interpretacion del chero /etc/fstab. . . . . . . . . . . . . . . . . . . . . . 53
7.3 Opciones mas comunes en el montaje de dispositivos en Linux. . . . . . . . 54
8.1 Opciones mas usuales en la exportacion de directorios mediante NFS. . . . 61
9.1 Secciones globales en el chero /etc/smb.conf. . . . . . . . . . . . . . . . . 66
9.2 Principales opciones de la seccion [global] de Samba. . . . . . . . . . . . . 71
9.4 Principales opciones de recurso de Samba. . . . . . . . . . . . . . . . . . . . 72
vii
Cap
tulo 1
Introduccion
Indice General
1.1
1.2
1.3
1.4
1.5
Profesorado
Programa .
Evaluacion .
Horarios . .
Pagina Web
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1.1 Profesorado
Agustn Espinosa Minguet ([email protected])
Andres Terrasa Barrena ([email protected])
Alvaro Alvarez Rodrguez ([email protected])
1.2 Programa
1) Instalacion de RedHat Linux.
2) Instalacion de Windows NT.
3) Seguridad y Proteccion en RedHat Linux.
4) Seguridad y Proteccion en Windows NT.
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
3
2
Introduccion
5) Dominios y Sistemas de Archivos en Red en Unix.
6) Dominios y Sistemas de Archivos en Red en Windows NT.
7) Interoperatividad entre Unix y Windows NT (Samba).
8) Conguracion de la red en Windows NT (Enrutamiento, Wins, DHCP).
9) Conguracion de la red en RedHat Linux (Enrutamiento, DNS).
10) Servidores de correo.
1.3 Evaluacion
a) Convocatoria Ordinaria
Actividad de laboratorio 70%.
{ Cada no asistencia a practicas resta un 10% de la nota de practicas.
{ Cada practica es evaluada con calicacion al grupo de Suspenso, Notable
o Sobresaliente.
{ Deben aprobarse las practicas para aprobar la asignatura.
Examen escrito 30%
{ Debe aprobarse el examen escrito para aprobar la asignatura
b) Convocatoria Extraordinaria
Examen escrito 30%
Recupera el examen escrito de la convocatoria ordinaria.
S
olo pueden presentarse aquellos alumnos que hayan aprobado las practicas en
la convocatoria ordinaria.
1.4 Horarios
Teor
a CSO
Da
Hora
Aula
Profesor
Miercoles
Jueves
De 15 a 17
De 8:30 a 10:30
Aula 2.3 Facultad
Aula 2.3 Facultad
Andres Terrasa
Andres Terrasa
Martes
Viernes
Viernes
Viernes
De
De
De
De
Laboratorio CSO
15
10
10
15
a
a
a
a
17
12
12
17
c Agust
n Espinosa, Andr
es Terrasa, 2001
Laboratorio 4
Laboratorio 4
Laboratorio 4
Laboratorio 4
DSIC
DSIC
DSIC
DSIC
Andres Terrasa
Agustn Espinosa
Agustn Espinosa
Agustn Espinosa
Administraci
3
1.5 Pagina Web
Teor
a AUW
Da
Hora
Aula
Profesor
Lunes
Miercoles
De 10 a 12
De 12:30 a 14:30
Aula B-5 Escuela
Aula B-5 Escuela
Agustn Espinosa
Agustn Espinosa
Laboratorio AUW
Martes
Jueves
Viernes
Viernes
De
De
De
De
17 a 19
10:30 a 12:30
17 a 19
19 a 21
Laboratorio 4
Laboratorio 4
Laboratorio 4
Laboratorio 4
DSIC
DSIC
DSIC
DSIC
Andres Terrasa
Andres Terrasa
Alvaro Alvarez
Alvaro Alvarez
1.5 Pagina Web
http://www.dsic.upv.es/asignaturas/facultad/cso
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
Cap
tulo 2
Los Discos Duros
Indice General
2.1 Geometra del Disco . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Lmites a la Geometra de los Discos IDE . . . . . . . . . . . .
2.3 Problemas Causados por Lmites a la Geometra de los Discos
IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Particiones del Disco . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Utilizacion de las Particiones . . . . . . . . . . . . . . . . . . .
2.5.1
2.5.2
.
.
5
6
.
.
.
7
8
9
DOS, Windows 95, 98 y NT . . . . . . . . . . . . . . . . . . . . .
Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
10
2.6 Utilizacion de los Discos en el Laboratorio de Practicas . . . . 10
2.1 Geometra del Disco
Los discos duros son el medio de almacenamiento masivo y permanente por excelencia en
los ordenadores. Existen dos grandes grupos de discos en funcion de su interfaz con el
ordenador, IDE y SCSI. En esencia, ambos grupos son equivalentes, salvo en aspectos de
rendimiento, abilidad y precio. Dieren, eso s, en las limitaciones que el software de
sistemas ha impuesto de forma articial a los discos IDE en el mundo de los PCs.
Un disco almacena su informacion en uno o mas platos, disponiendo de una cabeza
lectora para cada una de las dos caras del plato (aunque en algunas ocasiones una cara no
es utilizada). Cada cara esta dividida en varios anillos concentricos, denominados pistas.
Esta division es debida a que el plato gira sobre su eje, y la cabeza lectora se desplaza
longitudinalmente hacia o desde el eje. A su vez, cada pista esta subdividida en sectores,
todos ellos de igual capacidad, 512 bytes en la gran mayora de los casos. Todos los platos
5
6
Los Discos Duros
de un disco estan unidos y tambien lo estan entre si las cabezas lectoras. El conjunto de
pistas que se encuentran bajo todas las cabezas lectoras recibe el nombre de cilindro.
Resumiendo, la capacidad de un disco puede describirse indicando su numero de cilindros, cabezales y sectores por pista. Por ejemplo, un disco con 4096 cilindros, 16 cabezales
y 63 sectores por pista alberga un total de:
4096 x 16 x 63 = 4.128.768 sectores de 512 bytes =
2.113.929.216 bytes =
2.064.384 Kbytes =
2.016 Mbytes =
1'96875 Gbytes.
Hay que tener en cuenta que el fabricante del disco dira que su disco tiene 211 Gbytes.
Los fabricantes de discos asumen que un Gbyte equivale a mil millones de bytes, no a 230
bytes. Por cierto, los nuevos estandares dan la razon a los fabricantes, y nos indican
que deberamos utilizar los nuevos terminos Kibytes, Mibytes, Gibytes para expresar las
correspondientes potencias de 2. Sin embargo, en este documento no vamos a utilizar este
estandar.
2.2 Lmites a la Geometra de los Discos IDE
Existen diferentes lmites a la geometra descrita que han sido impuestos (articialmente)
por el hardware o el software. Los mas importantes son los siguientes:
a) La especicacion ATA (127'5 Gbytes). Se calcula como:
65536 cilindros * 16 cabezales * 256 sectores por pista.
En el momento de escribir estas lneas, este lmite aun no se ha alcanzado, pero ya
estan a la venta discos IDE de mas de 30 Gbytes, as que no andamos muy lejos.
b) La limitacion de las rutinas de disco \clasicas" de la BIOS (7,84 Gbytes).
Se calcula como:
Esta es una seria limitacion para el software que requiere de la BIOS para acceder
al disco, como, por ejemplo, el ancestral sistema DOS y LILO, el cargador por
excelencia del sistema operativo Linux.
c) La limitacion conjunta de las dos anteriores (504 Mbytes). En este caso, su
calculo es de:
Es decir, como un disco no puede tener mas de 16, cabezales, la limitacion de la
BIOS se limita aun mas al pasar de 255 cabezales (BIOS) a 16 cabezales (ATA).
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
2.3 Problemas Causados por Lmites a la Geometra de los Discos IDE
7
La aparicion de discos de mas de 504 Mb, con mas de 1024 cilindros, causo serios
problemas, ya que millones de ordenadores con DOS instalado no podan utilizarlos directamente. Las BIOS fueron modicadas y se invento el truco de la traduccion de direcciones
conocida como LBA (o Logical Block Addressing). La BIOS informa al sistema que el disco
tiene menos de 1024 cilindros. Cuando el sistema accede al disco, la BIOS realiza la traduccion y accede al lugar correcto. Para llorar. Las BIOS incorporaron tambien nuevas
rutinas de acceso al disco distintas de las \clasicas" para acceder a los discos grandes, con
mas de 1024 cilindros en modo LBA. Un ejemplo de traduccion podra ser:
Disco real: 20.928 cilindros, 16 cabezales, 63 sectores por pista.
Disco con LBA: 1.313 cilindros, 255 cabezales, 63 sectores por pista.
2.3 Problemas Causados por Lmites a la Geometra de los
Discos IDE
Estas limitaciones en los discos tpicos para PC han ocasionado limitaciones en algunos
sistemas operativos. A continuacion se revisan los sistemas mas populares:
a) DOS, Windows 3.x, Windows 95, Windows NT 3.x. DOS utiliza las rutinas
\clasicas" de la BIOS para acceder al disco. Por tanto, DOS no puede utilizar mas
de 1024 cilindros. El modo LBA es imprescindible y el tama~no maximo de disco
soportado, tal como se ha explicado anteriormente, es de 7'84 Gbytes. Los sistemas
Windows que aparecieron a continuacion heredaron esta restriccion de DOS por
motivos de compatibilidad.
b) Windows 95 OSR2, Windows 98. No tienen ningun problema. No utilizan las
rutinas clasicas de la BIOS y por tanto pueden utilizar mas de 1024 cilindros.
c) Linux. A partir de los nucleos 2.0.34 y 2.2.* Linux puede acceder sin problemas a
discos con mas de 1024 cilindros LBA. Los nucleos anteriores no utilizaban la BIOS,
pero entendan que era un error que un disco informase mas de 1024 cilindros LBA.
No obstante, LILO, el cargador de Linux, utiliza las rutinas clasicas de la BIOS
(Linux aun no esta en funcionamiento), con lo cual LILO no puede funcionar si el
nucleo de Linux a cargar reside todo o en parte a partir de los 1024 cilindros.
La estrategia para que LILO no cause problemas es simple. Hay que hacer que el
chero que contiene el codigo del nucleo de Linux (/boot/vmlinuz generalmente)
resida completamente en cilindros anteriores al 1024. Esto puede conseguirse instalando la particion raz de Linux antes del cilindro 1024 o creando una particion
peque~na (unos 10 Mbytes es suciente) que contenga el directorio /boot, y haciendo
que sea esta la particion que resida antes de los 1024 cilindros.
d) Windows NT 4.0. Este sistema tiene soporte para discos grandes desde su aparicion. No obstante, el proceso de instalacion de NT esta basado en DOS, con lo cual,
la particion donde reside NT debe estar antes de la barrera de los 1024 cilindros.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
8
Los Discos Duros
En resumen, en nuestros das aun seguimos atados a las restricciones que impuso el
dise~no original de la BIOS. Es de esperar que LILO sea modicado y Windows 2000
(sucesor de Windows NT) disponga de un mecanismo de instalacion que no dependa de
DOS. Hasta entonces, el modo LBA debe seguir siendo utilizado salvo que en el ordenador
vaya a utilizarse tan solo Windows 98 (y, >quien quiere tener solo eso?).
2.4 Particiones del Disco
En el primer sector de un disco duro reside el denominado MBR (o Master Boot Record).
En estos 512 bytes residen el codigo inicial de carga del sistema operativo, la tabla de
particiones primarias y la rma del disco.
El codigo de carga mas frecuente es el que dene el sistema operativo DOS, el cual se
encarga de buscar la particion de arranque, cargar en memoria el primer sector de dicha
es el metodo utilizado por todos los sistemas operativos
particion y cederle el control. Este
de Microsoft. Este codigo de carga puede recuperarse (reinstalarse) con el mandato DOS
FDISK /MBR, el cual deja intacta la tabla de particiones.
Otro codigo de carga bastante utilizado es LILO (mejor dicho, la primera fase de dicho
cargador). Es mas complejo y exible que el codigo de carga de DOS, y utiliza la informacion que reside en el directorio /boot de Linux para determinar que sistema operativo debe
cargarse. Existen otros codigos de carga con funcionamientos muy diversos, pero hoy en
da son escasamente utilizados. Para restaurar (reinstalar) este codigo de arranque, basta con ejecutar el mandato Linux lilo, el cual utiliza el chero /etc/lilo.conf para
congurar el mecanismo de carga de LILO.
El codigo de carga se utiliza tan solo en el disco principal del sistema (es decir, el disco
maestro del interfaz IDE primario). Hay BIOS que permiten arrancar de otros discos
duros, pero generalmente aparecen numerosos problemas al utilizar esta opcion.
La tabla de particiones esta formada por cuatro entradas, donde cada una de ellas describe una potencial particion primaria. Los detalles de cada entrada son algo oscuros, y su
utilizacion vara sensiblemente de un sistema operativo a otro. No obstante, simplicando
un poco, cada entrada indica, para la particion que describe, la siguiente informacion:
El sector del disco donde comienza.
Su tama~
no.
Si es una partici
on de arranque (activa).
Su tipo.
DOS, Windows 3.x y Windows 95 representan el inicio de la particion utilizando la
tripleta <cilindro,cabezal,sector>, con lo cual el tama~no maximo de una particion
es de 7'84 Gbytes (debido a la limitacion de los 1024 cilindros). El resto de sistemas
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
9
2.5 Utilizacion de las Particiones
representan el inicio de la particion indicando cual es el sector logico donde comienza
(viendo al disco como un vector de sectores logicos). Estos sistemas utilizan una palabra
de 32 bits, lo que permite 232 sectores, equivalente a 2 Tbytes (2 x 1024 Gbytes). En este
caso, aun estamos algo lejos de disponer de discos de estas caractersticas.
El indicador de particion de arranque es utilizado tan solo por el codigo de carga de
DOS. Linux ignora por completo esta informacion.
Existen numerosos tipos de particiones, en funcion de su utilizacion o de su organizacion interna (establecida por el sistema operativo que la dena). Existe una convencion
que establece el identicador de cada tipo de particion como un numero concreto en hexadecimal. La siguiente tabla expone los tipos de particiones mas habituales:
Tipo
Uso
Limitacion
0
Particion vaca
{
5
Particion extendida
1024 cilindros (7'84 Gbytes)
6
DOS FAT 16
2 Gbytes
7
OS2 o NTFS
2 Tbytes
b
Windows 95 FAT 32
2 Tbytes
f
Extendida Windows 95
2 Tbytes
80
Old Minix
{
82
Linux swap
{
83
Linux native
2 Tbytes
Una particion extendida es un contenedor para otras particiones, a las cuales se les
denomina particiones logicas. Solo una de las particiones primarias puede declararse como
extendida. La representacion de las unidades logicas se realiza utilizando una lista enlazada
que reside dentro de la particion extendida, por lo que no hay lmite en cuanto al numero
de particiones logicas que se pueden crear. La particion extendida convencional ha tenido
que ser cambiada por la nueva particion extendida Windows 95, ya que la primera no
puede abarcar discos mayores de 7'84 Gbytes.
2.5 Utilizacion de las Particiones
A continuacion se muestra a que tipos de particiones pueden acceder los distintos sistemas
operativos.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
10
Los Discos Duros
2.5.1 DOS, Windows 95, 98 y NT
Todos estos sistemas requieren una particion primaria en el disco principal marcada como
de arranque para poder ser instalados. Ademas, presentan las siguientes caractersticas:
En el caso de la familia Windows, pueden emplearse conjuntamente a la anterior
particiones logicas ubicadas en cualquier disco o particiones primarias que residan
en un disco no principal.
Todos estos sistemas pueden acceder a particiones FAT16.
Windows NT no puede acceder a particiones FAT32. Una consecuencia importante
de esta restriccion es que Windows NT no puede ser instalado en un ordenador en
el cual la particion primaria de arranque sea de tipo FAT32.
DOS y Windows 95 no pueden acceder tampoco a particiones FAT32, las cuales s
olo
pueden ser utilizadas por Windows 95 OSR2 y Windows 98.
DOS y Windows 9x no pueden acceder a particiones NTFS.
2.5.2 Linux
Este sistema requiere al menos una particion de tipo Linux native para poder ser instalado.
Esta particion puede ser primaria o logica y residir en cualquier disco; en esta particion
residira el sistema de archivos raz (/). La particion de tipo Linux swap es necesaria si se
requiere area de intercambio en disco; en este caso, pueden emplearse varias, ser logicas
o primarias y residir en cualquier disco. La particion del sistema de archivos raz debe
estar ntegramente ubicada antes del cilindro 1024 si se va a utilizar LILO. De no ser
esto posible (o conveniente), puede crearse otra particion para que albergue al directorio
/boot, la cual basta que tenga 10 Mbytes, y crearla antes del cilindro 1024. Linux puede
acceder a particiones FAT16 y FAT32. El acceso a particiones NTFS es posible solo para
lectura.
2.6 Utilizacion de los Discos en el Laboratorio de Practicas
Los ordenadores del laboratorio de practicas disponen de dos discos, uno principal e interno
y otro secundario y extrable. En el disco principal residen los sistemas Windows 98 y
Linux utilizados en las practicas convencionales, siendo LILO el encargado de arrancar
ambos sistemas. El disco extrable se utiliza exclusivamente en esta asignatura, y en el,
tras las primeras sesiones de laboratorio, residiran varios sistemas Linux y Windows NT.
El disco extrable tiene 10 Gbytes, con un total de 1313 cilindros en modo LBA.
Esto supone algunos problemas para las instalaciones de NT y Linux, tal como se ha
expuesto anteriormente en este documento. Como solucion se ha optado por instalar NT
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
11
2.6 Utilizacion de los Discos en el Laboratorio de Practicas
en particiones ubicadas antes de los 1024 cilindros y utilizar la particion /boot para la
instalacion de Linux.
Cada grupo de laboratorio requiere cuatro particiones para instalar NT y Linux: FAT16
(NT), Linux swap, Linux native (raz) y otra Linux native (/boot). Dado que hasta siete
grupos pueden utilizar el mismo ordenador, se requieren en total 32 particiones en cada
disco extrable (o 25, si tenemos en cuenta que la particion Linux swap puede ser compartida). Aunque es factible crear tal numero de particiones en un disco, se ha observado
que la instalacion de Linux no esta preparada para esta cifra. En cualquier caso, tambien
resulta confusa la utilizacion de un disco particionado de este modo.
Para solventar este problema, se ha escogido otra estrategia, la cual consiste en crear
una tabla de particiones \a medida" cada vez que se inicia una sesion de practicas. Dicha
tabla de particiones contiene tan solo las cuatro particiones necesarias, todas ellas primarias. La utilidad activa-hdc, instalada en el sistema Linux del disco principal, se
encarga de crear esta tabla de forma que no se solapen particiones entre distintos turnos
de practicas.
Otro aspecto a destacar es relativo a la instalacion de Windows NT. Tal como se ha comentado, NT requiere utilizar la particion activa. En la particion activa de los ordenadores
del laboratorio reside el sistema Windows 98 utilizado por las practicas convencionales,
por lo cual no puede ser utilizada. Para poder instalar Windows NT es necesario \crear"
una particion activa diferente, para lo cual existe una particion oculta en el disco principal
(de tipo 80, Old Minix). Antes de la instalacion de NT, esta particion es convertida a FAT
16 y hecha activa, pasando la verdadera particion activa a ocultarse cambiando su tipo a
Old Minix.
Adicionalmente, la instalacion de Windows NT requiere el codigo de carga estandar
de DOS en el MBR, y, en cambio, el codigo de carga utilizado actualmente es LILO. Por
tanto, LILO debe ser sustituido antes de la instalacion de Window NT por el codigo de
carga estandar.
Una vez nalizada la instalacion de Windows NT debe recuperarse la situacion original,
tras lo que se pierde la posibilidad de arrancar Windows NT desde disco duro, por lo que
es necesario generar un disquete de arranque mientras se tiene acceso todava al sistema
Windows NT instalado. Los documentos de instalacion de NT detallan los procedimientos
a seguir para realizar estos cambios.
Por contra, la instalacion de Linux puede realizarse mas facilmente, ya que no se requiere de la particion activa y la propia instalacion puede generar un disquete de arranque.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
Cap
tulo 3
Usuarios y Proteccion en Linux
Indice General
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
La Tabla de Usuarios . . . . . . . . . . . . . . . . . . . . . . . . .
La Extension de la Tabla de Usuarios . . . . . . . . . . . . . . .
La Tabla de Grupos . . . . . . . . . . . . . . . . . . . . . . . . . .
Procedimientos para la Creacion de Grupos y Usuarios . . . .
Atributos de Proteccion de los Procesos . . . . . . . . . . . . . .
Atributos de Proteccion de los Ficheros . . . . . . . . . . . . . .
Las Reglas de Proteccion Basicas . . . . . . . . . . . . . . . . . .
Cambio de Atributos de Proteccion en Ficheros . . . . . . . . .
Los Bits SETUID y SETGID en Ficheros Ejecutables . . . . .
El bit SETGID en Directorios . . . . . . . . . . . . . . . . . . . .
La Mascara de Creacion de Ficheros . . . . . . . . . . . . . . . .
La Estrategia de los Grupos Privados . . . . . . . . . . . . . . .
Sintaxis y Funcionamiento de los Mandatos Unix Relacionados
13
14
15
15
16
16
18
18
19
19
20
20
21
3.1 La Tabla de Usuarios
Los usuarios de un sistema Unix son registrados en un chero denominado /etc/passwd.
Cada lnea corresponde a un usuario y describe los atributos del mismo. Los atributos son
separados por el caracter `:'. Por ejemplo, dada la siguiente lnea del chero /etc/passwd,
a continuacion se describe cada elemento de la misma:
usu1:$1$ZtoHwEykKW/eCLHzSUigg5KAEyxa51:1002:2000:Usuario 1:/home/usu1:
/bin/bash
13
14
Elemento
Signicado
usu1
$1$ZtoHwEykKW/eCLH
zSUigg5KAEyxa51
1002
2000
Nombre del usuario.
Contrase~na cifrada.
Usuario 1
/home/usu1
/bin/bash
Identicador del usuario (UID).
Indenticador del grupo primario al que pertenece el usuario
(GID).
Descripcion del usuario.
Directorio de conexion inicial del usuario.
Programa interprete de ordenes (shell).
3.2 La Extension de la Tabla de Usuarios
Ademas de la tabla de usuarios descrita en el apartado anterior, en la mayora de sistemas
Unix actuales se utiliza otra tabla, contenida en el chero /etc/shadow, en la que se
almacena informacion adicional para los usuarios. Cada lnea de dicho chero corresponde
a una lnea del chero /etc/passwd y la informacion que contiene es la siguiente (de
acuerdo con el ejemplo anterior):
usu1:$1$ZtoHwEykKW/eCLHzSUigg5KAEyxa51:10989:0:99999:7:-1:-1:134538436
Elemento
Signicado
usu1
$1$ZtoHwEykKW/eC
LHzSUigg5KAEyxa51
10989:0:99999:7:
-1:-1:134538436
Nombre del usuario.
Contrase~na cifrada.
Informacion de caducidad de la contrase~na.
Cuando el sistema emplea esta tabla, la contrase~na almacenada en el chero /etc/passwd
se sustituye por una `x'. Dado que el chero /etc/passwd es legible por todos los usuarios
mientras que /etc/shadow solo es legible por el administrador, mediante este cambio se
consigue que ningun usuario tenga acceso a las contrase~nas cifradas.
La informacion de caducidad de la contrase~na esta expresada en das, siendo su utilizacion e interpretacion compleja en algunos casos. Por este motivo, para modicar y consultar esta informacion no se recomienda en general trabajar directamente con el chero
/etc/shadow, sino utilizar herramientas administrativas especcas, ya sea en forma de
mandatos o mediante aplicaciones gracas.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
15
3.3 La Tabla de Grupos
3.3 La Tabla de Grupos
Los grupos de un sistema Unix son registrados en un chero denominado /etc/group.
Cada lnea corresponde a un grupo y describe los atributos del mismo. Los atributos son
separados por el caracter `:' y su signicado se describe mediante el siguiente ejemplo:
proy1::65534:usu1,usu2,usu3
Elemento
Signicado
proy1
Nombre del grupo.
Contrase~na cifrada (vaca en el ejemplo). Esta contrase~na
permite a un usuario cambiar de grupo primario si se conoce
esta contrase~na. Esta funcionalidad esta en desuso.
Identicador del grupo (GID).
Lista de usuarios que pertenecen a este grupo.
65534
usu1,usu2,usu3
Como se deduce del ejemplo, un usuario puede gurar en la lista de distintos grupos,
es decir, puede pertenecer a varios grupos. De todos esos grupos, aquel cuyo GID gura
en la entrada correspondiente al usuario en el chero /etc/passwd se considera el grupo
primario de dicho usuario. El resto de grupos se denominan grupos suplementarios.
3.4 Procedimientos para la Creacion de Grupos y Usuarios
En la mayora de sistemas Unix System V pueden emplearse los siguientes mandatos para
la gestion de usuarios y grupos:
Mandato
Uso
useradd
userdel
usermod
groupadd
groupdel
groupmod
passwd
chage
A~nadir un usuario.
Eliminar un usuario.
Modicar los atributos de un usuario.
A~nadir un grupo.
Eliminar un grupo.
Modicar los atributos de un grupo.
Cambiar la contrase~na de un usuario.
Gestionar la caducidad de la contrase~na.
Estos mandatos son especialmente utiles cuando la gestion de usuarios debe realizarse
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
16
desde scripts del shell, por ejemplo, cuando debe crearse una gran cantidad de usuarios
de forma automatica. La sintaxis y opciones mas usuales de estos mandatos se citan en
la Seccion 3.13, al nal de este captulo.
Adicionalmente, cada vez es mas frecuente la disponibilidad de herramientas gracas
que facilitan la labor del administrador. El programa linuxconf es el mas recomendable
en entornos Linux, dado el amplio abanico de actividades administrativas que cubre.
3.5 Atributos de Proteccion de los Procesos
Los atributos de un proceso que intervienen en el mecanismo de proteccion son:
a) Identicadores del usuario propietario del proceso (rUID, eUID). La version
real |rUID| corresponde al usuario que creo al proceso. La version efectiva |
eUID| corresponde al usuario bajo el cual se comporta el proceso y es el utilizado
en el mecanismo de proteccion. Ambos identicadores suelen ser iguales, salvo que
intervenga el denominado bit SETUID en el chero ejecutable que esta ejecutando el
proceso, tal como se describe mas adelante en este documento (ver Seccion 3.9).
b) Identicadores del grupo propietario del proceso (rGID,
eGID). La version
real {rGID| corresponde al grupo primario al que pertenece el usuario que creo el
proceso. La version efectiva |eGID| corresponde al grupo bajo el cual se comporta
el proceso y es el utilizado en el mecanismo de proteccion. Ambos identicadores
suelen ser iguales, salvo que intervenga el denominado bit SETGID en el chero
ejecutable que esta ejecutando el proceso, tal como se describe mas adelante en este
documento (ver Seccion 3.9).
c) Lista de grupos suplementarios. Es la lista formada por los grupos suplementarios del usuario que creo el proceso.
Estos atributos son asignados al proceso en el momento de su creacion, y heredados
de su proceso padre. Cada usuario conectado a un sistema Unix posee un proceso de
atencion denominado shell, el cual es el padre de todos los procesos que el usuario genera.
Este proceso shell recibe sus atributos no por herencia, sino en el momento en el que
un usuario se acredita al sistema mediante su nombre de usuario y contrase~na asociada.
Los atributos rUID y rGID se extraen de la tabla de usuarios /etc/passwd. La lista de
grupos suplementarios es confeccionada a partir de la tabla de grupos /etc/group. Los
atributos eUID y eGID son asignados a los valores respectivos de rUID y rGID. Un mandato
interesante al respecto es id, el cual muestra todos estos atibutos.
3.6 Atributos de Proteccion de los Ficheros
Los atributos de un chero que intervienen en el mecanismo de proteccion son:
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
17
3.6 Atributos de Proteccion de los Ficheros
OwnerUID. Identicador del usuario propietario del chero.
b) OwnerGID. Identicador del grupo propietario del chero.
a)
c) Bits de permiso. Un total de 12 bits que expresan las operaciones del chero que
son permitidas en funcion del proceso que acceda a este chero.
En la tabla a continuacion se muestra el signicado de cada bit de permiso.
Bit
Signicado
11
10
9
8
7
6
5
4
3
2
1
0
SETUID.
SETGID.
Sticky.
Lectura para el propietario.
Escritura para el propietario.
Ejecucion para el propietario.
Lectura para el grupo propietario.
Escritura para el grupo propietario.
Ejecucion para el grupo propietario.
Lectura para el resto de usuarios.
Escritura para el resto de usuarios.
Ejecucion para el resto de usuarios.
Los bits SETUID y SETGID son tratados en apartados posteriores.
El signicado de los bits de lectura, escritura y ejecucion es diferente en funcion del tipo
de archivo que los dena. Para cheros regulares, su signicado es el esperable (permiten
leer, modicar o ejecutar el chero). Evidentemente, el bit de ejecucion solo tiene sentido
si el chero es un ejecutable o contiene un shellscript. En un directorio, su signicado es
el siguiente:
a) Lectura. Puede listarse el contenido del directorio.
b) Escritura. Permite la creacion, eliminacion o renombrado de cheros o directorios
dentro del directorio al cual se aplica este bit.
c) Ejecucion. Permite la utilizacion del directorio al cual se aplica este bit para formar
parte de un nombre de ruta, es decir, puede utilizarse el directorio para nombrar un
chero.
De lo anteriormente expuesto, puede observarse que no existe un bit de permiso especco para el borrado de un chero/directorio. Dicho permiso es controlado realmente
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
18
desde el directorio donde reside el chero que quiere eliminarse. En algunos sistemas, el
bit sticky es utilizado para modicar la regla de eliminacion de cheros: si se activa en
un directorio, un usuario puede borrar un chero en el solo si es el propietario de dicho
chero.
El ownerUID puede modicarse con el mandato chown. El ownerGID puede modicarse
con el mandato chgrp. Los bits de permiso pueden modicarse con el mandato chmod.
Todos estos mandatos se describen en la Seccion 3.13.
3.7 Las Reglas de Proteccion Basicas
Las reglas de proteccion basicas se activan cuando un proceso notica al sistema que
desea utilizar un determinado chero. El proceso tambien notica al sistema que tipo de
operacion u operaciones quiere realizar: lectura, escritura o ejecucion.
Las reglas son:
Si el eUID del proceso es 0 se concede el permiso (estamos en el caso en el que el
proceso pertenece al superusuario). Si no. . .
Si el eUID del proceso es igual al ownerUID del chero, se autoriza la operacion si
esta permitida en el grupo de bits 6 al 8, los que corresponden al propietario. Si
no. . .
Si el eGID del proceso o alguno de los grupos suplementarios del proceso es igual al
ownerGID del chero, se autoriza la operacion si esta permitida en el grupo de bits
3 al 5, los que corresponden al grupo. Si no. . .
En cualquier otro caso, se autoriza la operacion si est
a permitida en el grupo de bits
0 al 2, los que corresponden al resto de usuarios.
Debe notarse que solo se aplica una regla, aquella que corresponde a la primera condicion que se cumple para los atributos del proceso. Es decir, el sistema determina primero
que grupo de tres bits debe aplicar y despues autoriza (o deniega) la operacion en funcion
del tipo de operacion requerida y del estado de dichos tres bits.
3.8 Cambio de Atributos de Proteccion en Ficheros
Unix establece unas reglas de proteccion especcas para controlar los cambios de cualquier
atributo de proteccion de un chero, dado que dichas modicaciones se consideran operaciones distintas de la de escritura, y por tanto no pueden ser concedidas/denegadas en
funcion de los bits de permiso del chero.
En concreto, las reglas establecidas al respecto son las siguientes:
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
19
3.9 Los Bits SETUID y SETGID en Ficheros Ejecutables
a) Cambio en los bits de permiso. Un proceso puede cambiar los bits de permiso
de un chero solo si:
el eUID del proceso es 0 (estamos en el caso en el que el proceso pertenece al
superusuario), o bien
el eUID del proceso es igual al ownerUID del chero.
Es decir, solo el superusuario o el popietario de un chero pueden modicar sus bits
de permiso.
b) Cambio en el propietario. El cambio de propietario de un chero puede realizarlo
tan solo el superusuario.
c) Cambio de grupo propietario. El cambio del grupo propietario de un chero
puede realizarse solo si:
lo realiza el superusuario, o bien
el nuevo grupo propietario del chero es igual a alguno de los grupos del usuario
que realiza el cambio de grupo y este usuario es el propietario del chero.
3.9 Los Bits SETUID y SETGID en Ficheros Ejecutables
Estos bits se emplean para permitir que un programa se ejecute bajo los privilegios de un
usuario distinto al que lanza la ejecucion del programa. Su funcionamiento es el siguiente:
Si el chero ejecutable tiene el bit SETUID activo, el eUID del proceso que ejecuta
el chero es hecho igual al ownerUID del chero.
Si el chero ejecutable tiene el bit SETGID activo, el eGID del proceso que ejecuta el
chero es hecho igual al ownerGID del chero.
Normalmente estos programas pertenecen al superusuario, y permiten a los usuarios
ejecutar tareas privilegiadas bajo ciertas condiciones. El cambio de la contrase~na de un
usuario es un ejemplo de esta tecnica.
La existencia de estos cheros en el sistema de archivos debe ser cuidadosamente
supervisada por el superusuario. Muchos de los ataques de seguridad a Unix utilizan estos
cheros para conseguir atentar contra la seguridad del sistema.
3.10 El bit SETGID en Directorios
La utilizacion de este bit esta orientada a facilitar el trabajo en grupo cuando varios
usuarios deben acceder a una coleccion comun de cheros y directorios. Su funcionamiento
es el siguiente: si un directorio, llamemosle D, tiene el bit SETGID activo, entonces:
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
20
si se crea un chero dentro de D, el ownerGID del nuevo chero es hecho igual al
ownerGID del directorio D.
si se crea un directorio dentro de D, el ownerGID del nuevo directorio es hecho igual
al ownerGID del directorio D y su bit SETGID es activado.
Puede observarse que se trata, en esencia, de un mecanismo de herencia. Cuando el
bit SETGID no esta activo, el ownerGID de un chero o directorio se toma del eGID del
proceso que lo crea.
Utilizando el SETGID, aunque varios usuarios creen cheros dentro de un directorio,
todos ellos perteneceran al menos al mismo grupo, con lo que una utilizacion adecuada
de los bits de permiso puede hacer que todos ellos puedan, por ejemplo, leer y modicar
dichos cheros.
3.11 La Mascara de Creacion de Ficheros
Las utilidades de Unix que crean cheros utilizan por defecto la palabra de proteccion
rw-rw-rw si se trata de cheros no ejecutables o rwxrwxrwx si se crea un directorio o un
ejecutable. Puede observarse, por tanto, que todos los permisos son activados.
Para modicar este funcionamiento, cada usuario puede especicar al sistema aquellos
bits que no desea que sean activados mediante la mascara de creacion de cheros. La
mascara se establece mediante el mandato umask. Cada bit activo en la mascara es un bit
que sera desactivado cuando se cree un chero. Por ejemplo, una mascara 022 desactivara
los bits de escritura para el grupo y el resto de usuarios.
El administrador debera velar porque exista una mascara de creacion de cheros
razonable por defecto para cualquier usuario. Esto puede conseguirse facilmente utilizando
el chero /etc/profile, el cual sirve para personalizar el entorno de un usuario en el
momento de su conexion.
3.12 La Estrategia de los Grupos Privados
Esta estrategia, empleada por defecto en Redhat Linux, esta orientada a racionalizar y
exibilizar la asignacion de usuarios a grupos. Las claves de esta estrategia son:
Crear un grupo para cada usuario (utilizando para ello el mismo nombre del usuario),
y hacer que este sea el grupo primario del usuario.
Utilizar exclusivamente grupos suplementarios para agrupar usuarios.
Utilizar el bit SETGID y un grupo suplementario en aquellos directorios donde varios
usuarios tengan que colaborar.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
3.13 Sintaxis y Funcionamiento de los Mandatos Unix Relacionados
21
Utilizar el grupo privado en el directorio de conexi
on de cada usuario.
Asignar como m
ascara por defecto para todos los usuarios 00X, es decir, todos los
permisos activos para el propietario y para el grupo y lo que se considere oportuno
para el resto de usuarios.
Se invita al lector a reexionar sobre las consecuencias de esta estrategia.
useradd
useradd [-u uid [-o]] [-g group] [-G group,...]
[-d home] [-s shell] [-c comment] [-m [-k template]]
[-f inactive] [-e expire mm/dd/yy] [-p passwd] [-n] [-r] name
useradd -D [-g group] [-b base] [-s shell] [-f inactive]
[-e expire mm/dd/yy]
Crea un usuario. Opciones:
-c
-d
-e
-f
Comentario sobre el usuario
Directorio de conexion del usario
Fecha en la cual la cuenta de usuario se desactiva
D
as que transcurrir
an desde la caducidad de la
contrase~na hasta la desactivaci
on de la cuenta
-g Nombre o numero del grupo primario
-G Lista de los grupos suplementarios del usuario
(separados por ,) (sin espacios)
-m Crea el directorio de conexion. Si no se especifica la opcion
-k, copia al directorio de conexion los ficheros del directorio
/etc/skel
-k Copia al directorio de conexion los ficheros del directorio
template
-p Asigna una contrase~
na cifrada al usuario
-r Crea una cuenta del sistema
-s Asigna el shell a utilizar por el usuario
-u Asigna un UID concreto al usuario
-o Permite crear un UID duplicado con la opcion -u
-D Se asignan valores por defecto para las opciones indicadas.
(No crea usuario)
--------------------------------------------------------------------------userdel
userdel [-r] name
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
22
Elimina un usuario. Opciones:
-r Elimina el directorio de conexi
on del usario
--------------------------------------------------------------------------usermod
usermod [-u uid [-o]] [-g group] [-G group,...]
[-d home [-m]] [-s shell] [-c comment] [-l new_name]
[-f inactive] [-e expire mm/dd/yy] [-p passwd] [-L|-U] name
Modifica atributos de un usuario. Opciones:
-c
-d
-e
-f
Comentario sobre el usuario
Directorio de conexion del usario
Fecha en la cual la cuenta de usuario se desactiva
D
as que transcurrir
an desde la caducidad de la contrase~
na
hasta la desactivaci
on de la cuenta
-g Nombre o numero del grupo primario
-G Lista de los grupos suplementarios del usuario
(separados por ,) (sin espacios)
-l Modifica el nombre de conexion del usuario
-L Bloquea la contrase~
na del usuario
-m Crea el directorio de conexion Si no se especifica la opci
on -k,
copia al directorio de conexion los ficheros del directorio
/etc/skel
-p Asigna una contrase~
na cifrada al usuario
-s Asigna el shell a utilizar por el usuario
-u Asigna un UID concreto al usuario
-o Permite crear un UID duplicado con la opcion -u
-U Desbloquea la contrase~
na del usuario
--------------------------------------------------------------------------groupadd
groupadd [-g gid [-o]] [-r] group
Crea un grupo de usuarios. Opciones:
-g Asigna un GID concreto al grupo
-o Permite crear un GID duplicado con la opcion -g
-r Crea una cuenta de grupo del sistema
--------------------------------------------------------------------------groupmod
groupmod [-g gid [-o]] [-n name] group
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
23
Modifica los atributos de un grupo de usuarios. Opciones:
-g Asigna un GID concreto al grupo
-o Permite crear un GID duplicado con la opcion -g
-n Cambia el nombre del grupo
--------------------------------------------------------------------------groupdel
groupdel group
Elimina un grupo de usuarios. No tiene opciones.
--------------------------------------------------------------------------passwd
passwd [-l] [-u [-f]] [-d] [-S] [ username ]
Modifica la contrase~na y el estado de la cuenta un usuario. Opciones:
-d
-f
-l
-S
-u
Elimina la contrase~na del usuario
Fuerza el desbloqueo
Bloquea la cuenta del usuario
Informa sobre el estado de la cuenta de un usuario
Desbloquea la cuenta del usuario
Sin argumentos modifica la contrase~na del usuario que lo invoca.
Si se especifica un nombre de usuario y no se especifican opciones,
modifica la contrase~na del usuario indicado
--------------------------------------------------------------------------chage
chage [ -l ] [ -m min_days ] [ -M max_days ] [ -W warn ]
[ -I inactive ] [ -E expire ] [ -d last_day ] user
Modifica la informaci
on de caducidad de la contrase~
na de un usuario.
Opciones:
-d
-E
-l
-I
Asigna la fecha del ultimo cambio de contrase~na
Asigna la fecha en la cual la cuenta de usuario ser
a desactivada
Muestra la informacion de caducidad
N
umero de d
as tras los cuales la cuenta sera desactivada si no
se realiza el cambio de contrase~na exigido
-m N
umero de d
as mnimo permitido entre cambios de contrase~na
-M N
umero de d
as maximo permitido entre cambios de contrase~na
-W N
umero de d
as previos al proximo cambio de contrase~
na exigido
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
24
--------------------------------------------------------------------------chown
chwon [ -R ] owner file
Modifica el usuario propietario de un fichero o directorio. Opciones:
-R Realiza la modificacion en todo el contenido del directorio
--------------------------------------------------------------------------chgrp
chgrp [ -R ] group file
Modifica el grupo propietario de un fichero o directorio. Opciones:
--------------------------------------------------------------------------chmod
chmod -R MODE[,MODE]... FILE...
chmod -R OCTAL_MODE FILE...
Modifica los bits de permiso de un fichero o directorio. Opciones:
MODE indica como deben modificarse los bits de permiso. Su sintaxis es:
[ugoa][+-=][rwxXstugo]
[ugoa]
u propietario
g grupo
o otros
[+-=]
+ a~nadir
- eliminar
= hacer igual
a todos
[rwxXstugo]
r lectura
w escritura
x ejecucion
X ejecucion si activo para el propietario
s SETUID o SETGID
t sticky
u igual al propietario
g igual al grupo
o igual a otros
---------------------------------------------------------------------------
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
Cap
tulo 4
Usuarios y Proteccion en Windows
NT
Indice General
4.1
4.2
4.3
4.4
4.5
Conceptos de Usuario y de Cuenta de Usuario . . . .
Grupos de Usuarios . . . . . . . . . . . . . . . . . . . .
Permisos y Derechos (o Privilegios) . . . . . . . . . .
Asignacion de Permisos a Archivos y Directorios . .
Mandatos NT para la creacion de usuarios y grupos
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
26
28
30
33
4.1 Conceptos de Usuario y de Cuenta de Usuario
Como muchos otros sistemas operativos, Windows NT permite tener un riguroso control
de que personas pueden entrar en el sistema para trabajar en el, y de que forma pueden
llevar a cabo dicho trabajo.
Windows NT denomina usuario a cada persona que puede entrar en el sistema, y
para poder controlar su entrada y sus acciones, utiliza basicamente el concepto de cuenta
de usuario (user account). Una cuenta de usuario almacena toda la informacion que el
sistema guarda acerca de cada usuario, es decir, es la imagen que el sistema tiene de el.
Cada usuario ha de tener necesariamente una cuenta, y as el sistema puede distinguir
unvocamente a dicho usuario del resto. En Windows NT son numerosos los datos que
el sistema almacena en cada cuenta de usuario, y entre ellos los mas importantes son los
siguientes:
25
26
Usuarios y Proteccion en Windows NT
a) Nombre de usuario. Es el nombre mediante el cual el usuario puede entrar en el
sistema. Cada usuario ha de tener un nombre de usuario distinto.
b) Nombre completo. Es el nombre completo del usuario.
c) Contrase~na. Palabra cifrada que permite autenticar el nombre de usuario. En
Windows NT la contrase~na distingue entre mayusculas y minusculas.
d) Directorio de conexion. Es el lugar donde (en principio) residiran los archivos
personales del usuario. El directorio de conexion de cada usuario es privado: ningun
otro usuario puede entrar en el, a menos que su propietario conceda los permisos
adecuados.
e) Horas de conexion. Se puede controlar a que horas un usuario puede conectarse
para trabajar en el sistema. Inclusive se puede especicar un horario distinto para
cada da de la semana.
f) Activada. Esta caracterstica permite inhabilitar temporalmente una cuenta. Una
cuenta desactivada sigue existiendo, pero no puede ser utilizada para acceder al
sistema, ni siquiera conociendo su contrase~na.
Existe un dato especial que se asocia a cada cuenta, pero que a diferencia de todos los
expuestos arriba, no puede ser especicado manualmente cuando se da de alta la cuenta.
Se trata del identicador seguro (Secure Identier, o SID). Este identicador es interno y
el sistema lo genera automaticamente cuando se crea una nueva cuenta. NT utiliza el
SID (y no el nombre de usuario) en cada accion realizada por el usuario, para controlar
si este tiene o no permisos sucientes para llevarla a cabo. Ningun usuario (ni siquiera
el administrador) puede conocer el SID de ninguna cuenta, y precisamente en este hecho
radica su utilidad: nadie puede obtener un mayor grado de privilegio intentando suplantar
la identidad de otro usuario.
Cuando en un equipo se instala Windows NT, existen de entrada las cuentas de dos
usuarios preinstalados (built-in users): el Administrador y el Invitado. El primero es un
usuario especial, el unico que en principio posee lo que se denominan derechos administrativos en el sistema. Es decir, tiene la potestad de administrar el sistema en todos
aquellos aspectos en que este es congurable: usuarios, grupos de usuarios, contrase~nas,
recursos, derechos, etc. La cuenta de Administrador no puede ser borrada ni desactivada.
Por su parte, la cuenta de Invitado es la que utilizan normalmente aquellas personas que
no tienen un usuario propio para acceder al sistema. Habitualmente esta cuenta no tiene
contrase~na asignada, puesto que se supone que el nivel de privilegios asociado a ella es
mnimo. En cualquier caso, el Administrador puede desactivarla si lo considera oportuno.
4.2 Grupos de Usuarios
La informacion de seguridad almacenada en una cuenta de usuario es suciente para
establecer el grado libertad (o de otro modo, las restricciones) que cada usuario debe
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
27
4.2 Grupos de Usuarios
poseer en el sistema. Sin embargo, resultara muchas veces tedioso para el administrador
determinar dichas restricciones usuario por usuario, especialmente en sistemas con un
elevado numero de ellos. El concepto de grupo de usuarios permite agrupar de forma
logica a los usuarios de un sistema, y establecer permisos y restricciones a todo el grupo
de una vez. Un usuario puede pertenecer a tantos grupos como sea necesario, poseyendo
implcitamente la suma de los permisos de todos ellos. Esta forma de administrar la
seguridad, que se detallara en el apartado 4.4, es mucho mas exible y potente que el
establecimiento de permisos en base a usuarios individuales.
Considerese, por ejemplo, que en una empresa un sistema es utilizado por empleados
de distinto rango, y que cada rango posee un distinto nivel de privilegios. Supongamos
que se desea cambiar de rango a un empleado, debido a un ascenso, por ejemplo. Si la
seguridad estuviera basada en usuarios individuales, cambiar los privilegios de este usuario
adecuadamente supondra modicar sus privilegios en cada lugar del sistema en que estos
debieran cambiar (con el consiguiente trabajo, y el riesgo de olvidar alguno). Por el
contrario, con la administracion de seguridad basada en grupos, esta operacion sera tan
sencilla como cambiar al usuario de un grupo a otro. Por ello:
En Windows NT, se recomienda que los permisos se asignen en base a grupos
locales, y no en base a usuarios individuales.
Al igual que existen cuentas preinstaladas, en todo sistema NT existen una serie de
grupos preinstalados (built-in groups): Administradores, Operadores de Copia, Usuarios
Avanzados, Usuarios, e Invitados. El grupo Administradores recoge a todos aquellos
usuarios que deban poseer derechos administrativos completos. Inicialmente posee un solo
usuario, el Administrador. De igual forma, el grupo Invitados posee al Invitado como
unico miembro. Los otros tres grupos estan vacos inicialmente. Su uso es el siguiente:
a) Usuarios. Son los usuarios normales del sistema. Tienen permisos para conectarse
al sistema interactivamente y a traves de la red.
b) Operadores de copia. Estos usuarios pueden hacer (y restaurar) una copia de
todo el sistema.
c) Usuarios avanzados. Son usuarios con una cierta capacidad administrativa. Se les
permite cambiar la hora del sistema, crear cuentas de usuario y grupos, compartir
cheros e impresoras, etc.
El Administrador, al ir creando las cuentas de los usuarios, puede hacer que cada una
pertenezca al grupo (o grupos) que estime conveniente. Asimismo, puede crear nuevos
grupos que renen esta estructura inicial, conforme a las necesidades particulares de la
organizacion donde se ubique el sistema.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
28
4.3 Permisos y Derechos (o Privilegios)
La seguridad en NT se estructura a dos grandes niveles: por una parte, debe establecerse
quien puede trabajar en el sistema, y para ello se utilizan los conceptos de cuenta de
usuario y de grupo de usuarios. Por otra parte, debe establecerse que puede hacer cada
usuario/grupo. Para esto ultimo existen, a su vez, dos conceptos complementarios: los
permisos y los derechos.
Un permiso (permission) es una caracterstica de cada objeto del sistema, que concede o
deniega el acceso al mismo a un usuario/grupo concreto. En este contexto se puede asimilar
el concepto de objeto al de recurso (normalmente, un archivo, directorio o impresora).
Cada recurso del sistema posee una lista en la que se establece que usuarios/grupos pueden
acceder a dicho recurso, y tambien que tipo de acceso puede hacer cada uno (lectura,
modicacion, ejecucion, borrado, etc.). En el apartado 4.4 se profundiza mas acerca de
los permisos que pueden asignarse a recursos en NT, concretamente a los archivos.
Por su parte, un derecho o privilegio de usuario (user right) es una regla de proteccion
establecida sobre una accion que afecta al sistema en su conjunto (y no a un objeto en
concreto). Existe un conjunto jo y predenido de derechos, no pudiendose denir mas.
Para determinar que usuarios poseen que derechos, cada derecho posee una lista donde se
especican los grupos/usuarios que tienen concedido este derecho. Es preferible que, por
los motivos que se exponen en el apartado anterior, los derechos sean concedidos a grupos
en vez de a usuarios concretos (pero esto ultimo es tambien posible si resulta necesario).
A continuacion se exponen algunos derechos existentes en NT que merecen una especial
atencion:
a) Inicio de sesion local. Permite a un usuario iniciar una sesion interactiva en el
sistema.
b) Acceder a este equipo desde la red. Un usuario con este derecho puede conec-
tarse al equipo desde otro equipo en la red, y observar que recursos comparte. Este
derecho no garantiza el poder utilizar dichos recursos, y debe complementarse con
los permisos asociados a dichos recursos.
c) Tomar posesion de cheros. Cuando un usuario posee este derecho, puede tomar
posesion de cualquier archivo en el sistema. Tomar posesion implica pasar a ser el
propietario, y por tanto, tener control total sobre el mismo.
d) Apagar el sistema. Permite a un usuario apagar el equipo.
La concesion de derechos a los grupos preinstalados, tal como existe al instalar NT,
puede verse en la Tabla 4.1. Por otra parte, los distintos grupos poseen una serie de
habilidades preinstaladas (built-in abilities), que junto con sus derechos constituyen su
nivel de privilegios. La Tabla 4.1 muestra tambien las habilidades que posee cada grupo.
Posteriormente, el administrador, a su criterio, puede conceder o denegar cada derecho a
un grupo (o usuario) concreto, simplemente a~nadiendolo o eliminandolo de la lista asociada
a ese derecho. Las habilidades asociadas a cada grupo no pueden modicarse.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
29
4.3 Permisos y Derechos (o Privilegios)
Derecho
Inicio de sesion local
Acceder a este equipo desde la red
Tomar posesion de cheros
Cambiar el tiempo del sistema
Apagar el sistema
Apagar el sistema desde la red
Hacer copias de seguridad
Restaurar copias de seguridad
Instalar manejadores de dispositivo
Habilidad Preinstalada
Crear y administrar cuentas de
usuario
Crear y administrar grupos locales
Asignar derechos de usuario
Bloquear la estacion
Desbloquear la estacion
Formatear el disco duro
Compartir (y dejar de compartir) directorios
Compartir (y dejar de compartir)
impresoras
Admin. Usu.Av. Usu. Inv. Op.Copia Todos
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
Admin. Usu.Av. Usu. Inv. Op.Copia Todos
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
Tabla 4.1: Derechos iniciales y habilidades preinstaladas de los distintos grupos en Windows NT. Las abreviaturas corresponden a los siguientes grupos: Admin.=Administradores,
Usu.Av.=Usuarios Avanzados, Usu.=Usuarios, Inv.=Invitados, y Op.Copia=Operadores de
copia.
Es importante hacer notar lo siguiente: cuando existe un conicto entre lo que concede
un permiso y lo que concede un derecho, este ultimo tiene prioridad. Por ejemplo: los
miembros del grupo Operadores de Copia poseen el derecho de realizar una copia de
seguridad de todos los archivos del sistema. Es posible (y muy probable) que existan
archivos sobre los que no tengan ningun tipo de permiso. Sin embargo, al ser el derecho
mas prioritario, podran realizar la copia sin problemas. De igual forma, el administrador
tiene el derecho de tomar posesion de cualquier archivo, inclusive de aquellos archivos
sobre los que no tenga ningun permiso. Es decir:
Los derechos o privilegios siempre prevalecen ante los permisos particulares de
un objeto, en caso de conicto.
Finalmente, existe en NT una serie de grupos especiales, cuyos (usuarios) miembros
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
30
no se establecen de forma manual, sino que son determinados de forma automatica por el
sistema. Estos grupos se utilizan normalmente para facilitar la labor de conceder permisos
y derechos. De entre estos grupos, destacan:
a) Usuarios Interactivos (Interactive). Este grupo representa a todos aquellos usuarios que tienen el derecho de iniciar una sesion local en la maquina.
b) Usuarios de Red (Network). Bajo este nombre se agrupa a todos aquellos usuarios
que tienen el derecho de acceder al equipo desde la red.
c) Todos (Everyone). Agrupa a todos los usuarios que el sistema conoce. Puede agrupar
a usuarios existentes localmente y de otros sistemas (conectados a traves de la red).
Esto se expondra de forma mas rigurosa cuando se vean los dominios de NT, en el
Captulo 5.
4.4 Asignacion de Permisos a Archivos y Directorios
En primer lugar, es importante resaltar que en un sistema NT solo es posible establecer
permisos a archivos y directorios que residan en una particion de tipo NTFS (NT File
System), y no en una particion de tipo FAT (File Allocation Table).
Los permisos que se pueden asignar a un archivo o directorio en una particion NTFS
son combinaciones sobre seis permisos individuales, que se presentan a continuacion:
1) Lectura (Read, R). Permite abrir un archivo o directorio para consultar su contenido.
2) Escritura (Write, W). En el caso de un archivo, permite modicar su contenido.
En el caso de un directorio, permite crear nuevos archivos (o directorios) dentro del
mismo.
3) Ejecucion (Execution, X). Permite la ejecucion de un archivo.
4) Borrado (Delete, D). Permite el borrado de un archivo o directorio.
5) Cambiar los permisos (Change Permissions, P). Permite la accion de cambiar los
permisos que actualmente posee un archivo o directorio.
6) Tomar posesion (Take Ownership, O). En NTFS, todo archivo o directorio tiene un
propietario. Si un usuario no es el propietario de un archivo o directorio, pero posee
este permiso sobre el, podra realizar una accion especial, denominada tomar posesion,
que lo convertira automaticamente en su (nuevo) propietario. Consecuentemente,
podra hacer con dicho archivo lo que desee, puesto que el propietario de un archivo
siempre puede cambiar sus permisos.
Normalmente, los permisos que se asignan a los archivos o directorios no son estos
permisos individuales. En vez de eso, existe tambien una serie de permisos estandar,
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
31
4.4 Asignacion de Permisos a Archivos y Directorios
que son combinaciones predenidas de estos permisos individuales, con un signicado
bien denido. A continuacion se muestran los permisos estandar para directorios y para
archivos.
Nombre
Permisos
Directorio
Permisos
Archivos
Signicado
Sin acceso
(Ninguno)
(Ninguno)
Lectura
(RX)
(RX)
A~nadir
(WX)
(Sin determinar)
A~nadir y leer
(RWX)
(RX)
Cambio
(RWXD)
(RWXD)
Control total
(Todos)
(Todos)
El usuario no puede acceder al directorio
de ninguna manera, aunque sea miembro
de un grupo que tenga algun tipo de acceso al mismo.
El usuario puede leer el contenido de
archivos y ejecutar archivos ejecutables
que haya en el directorio.
El usuario puede a~nadir archivos al directorio, pero no puede leer el contenido de
ningun archivo, ni siquiera del propio directorio.
El usuario puede a~nadir nuevos cheros
y leer el contenido de cualquier chero,
pero no puede modicarlos.
El usuario puede crear archivos nuevos,
y leer y modicar cualquier archivo del
directorio.
El usuario tiene control total sobre el directorio y sobre todos sus archivos, as
como los que se creen en el futuro.
Tabla 4.2: Permisos estandar sobre directorios en Windows NT
En la Tabla 4.2 guran los permisos estandar que se pueden establecer en los directorios. Cada la describe un permiso estandar, indicando su nombre y las dos listas de
permisos individuales que lo denen: la primera es la lista de los permisos del propio
directorio y la segunda es la lista de permisos iniciales con la que se crearan los nuevos
archivos en ese directorio. De esta forma, cuando en un directorio padre se crea un nuevo
archivo/directorio hijo, se aplican las siguientes reglas:
Si el hijo es un archivo regular (no directorio), este se crea con los permisos especi-
cados la segunda lista de permisos individuales del directorio padre. El permiso sin
determinar signica ausencia de permisos.
Si el hijo es un directorio, este se crea con las dos listas de permisos individuales del
padre.
En ambos casos, esta especie de herencia s
olo tiene lugar en el momento de la creacion
del archivo/directorio hijo (es decir, es una copia instantanea de permisos). A partir
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
32
de ese momento, los permisos de padre e hijo se gestionan de forma completamente
independiente.
Los permisos estandar que se pueden establecer sobre un archivo individual se muestran
en la Tabla 4.3. Por otra parte, cuando se desea establecer los permisos de un directorio
o archivo, NT muestra, ademas de las listas que guran en ambas tablas, una opcion
denominada Acceso Especial. Esta opcion permite denir la lista de permisos individuales
que se desea aplicar a un archivo, o las dos listas que se desea aplicar sobre un directorio.
De esta forma, se puede llegar a una granularidad na en las ocasiones que sea necesario.
Nombre
Permisos
Signicado
Sin acceso
(Ninguno)
Lectura
(RX)
Cambio
(RWXD)
Control Total
(Todos)
El usuario no puede acceder chero de ninguna manera,
aunque sea miembro de un grupo que tenga algun tipo
de acceso al mismo.
El usuario puede leer el contenido del chero, y ejecutarlo si es un archivo ejecutable. No puede modicarlo
ni borrarlo.
El usuario puede leer, ejecutar, modicar y borrar el
archivo.
El usuario tiene el control total sobre el archivo.
Tabla 4.3: Permisos estandar sobre archivos en Windows NT
Ademas de poder establecer los permisos citados sobre cualquier archivo o directorio
(sobre el que podamos hacerlo, evidentemente), es importante tener en mente las siguientes
reglas:
Los usuarios pueden acceder de una determinada manera a un archivo o directorio
solo si tienen concedido el permiso correspondiente, bien de forma individual, bien
perteneciendo a un grupo que posea dicho permiso.
Los permisos son acumulativos, es decir, si un usuario pertenece a varios grupos, que
tienen distintos permisos sobre algun archivo o directorio, dicho usuario obtendra la
suma de todos ellos. Sin embargo, si para algun grupo (o para el personalmente) se
establece el permiso Sin Acceso, este ultimo tiene prioridad, y no podra acceder de
ninguna manera al archivo. En otras palabras, el permiso Sin Acceso es un permiso
negativo, que tiene prioridad sobre el resto.
Todo nuevo archivo recibe como permisos iniciales los que en ese momento posea su
directorio padre. El archivo recibira una o dos listas de permisos en funcion de si es
un archivo regular o un directorio.
A partir del momento de la creacion de un archivo, la gestion de permisos del nue-
vo archivo y del directorio donde se ha creado se realiza de forma completamente
independiente.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
33
4.5 Mandatos NT para la creacion de usuarios y grupos
Cuando un usuario crea un archivo o directorio, se convierte en el propietario del
mismo. El propietario de un archivo siempre puede cambiar los permisos del archivo.
Un usuario puede tomar posesi
on de un archivo o directorio (que no sea suyo ya)
siempre que tenga Control Total sobre dicho archivo (o bien el permiso individual
O). Los miembros del grupo de Administradores tienen el derecho de tomar posesion
de cualquier archivo del sistema.
En realidad el concepto de objeto como entidad que posee permisos es mas amplio
(tambien son objetos los procesos, los semaforos, los hilos de ejecucion, etc.).
4.5 Mandatos NT para la creacion de usuarios y grupos
La creacion de usuarios y grupos en Windows NT puede realizarse utilizando los mandatos
net user y net group. La sintaxis de ambos mandatos es la siguiente:
Mandato net user
Agrega o modica cuentas de usuario o muestra informacion acerca de ellas.
net user [nombre_usuario [contrase~na | *] [opciones]] [/domain]
net user nombre_usuario {contrase~na | *} /add [opciones] [/domain]
net user nombre_usuario [/delete] [/domain]
opciones:
/active:{no | yes}
/comment:"texto"
/countrycode:nnn
/expires:{fecha | never}
/fullname:"nombre"
/homedir:ruta_acceso
/homedirreq:{yes | no}
/passwordchg:{yes | no}
/passwordreq:{yes | no}
/profilepath[:ruta_acceso]
/scriptpath:ruta_acceso
/times:{horas | all}
/usercomment:"texto"
/workstations:{nombre_equipo [,...] | *}
Mandato net group
Agrega, muestra o modica grupos.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
34
net group [nombre_grupo [/comment:"texto"]] [/domain]
net group nombre_grupo {/add [/comment:"texto"] | /delete} [/domain]
net group nombre_grupo nombre_usuario[...] {/add | /delete} [/domain]
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
Cap
tulo 5
Dominios en Windows NT
Indice General
5.1
5.2
5.3
5.4
5.5
5.6
Concepto de Dominio . . . . . . . . . . . . . . .
Usuarios y Grupos en un Domino . . . . . . .
Ordenadores Miembros de un Dominio . . . .
Comparticion de Recursos entre Sistemas NT
Conanzas entre Dominios NT . . . . . . . . .
Mandatos NT para compartir recursos . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
37
39
39
41
43
5.1 Concepto de Dominio
Hoy en da, los ordenadores existentes en cualquier organizacion se encuentran muy frecuentemente formando parte de redes de ordenadores. En una red, los ordenadores se
encuentran interconectados, de forma que pueden intercambiar informacion. No es necesario que un ordenador con Windows NT participe de una red. Sin embargo, si desea
hacerlo, tiene que ser de alguna de las dos formas siguientes:
a) En un grupo de trabajo (workgroup). Un grupo de trabajo es una agrupacion
logica de maquinas, sin ningun otro n. Los ordenadores que forman parte del mismo
grupo aparecen juntos cuando se explora el Entorno de Red. La administracion
de cada ordenador es local e independiente del resto. Para poder acceder a los
recursos que exporta un ordenador concreto, el usuario remoto tiene que disponer
necesariamente de una cuenta en dicho ordenador, y permisos sucientes sobre el
recurso que se comparte.
35
36
b) Formando parte de un dominio (domain). Es la forma en que se recomienda que
se dena una red de maquinas NT. En un dominio, la informacion administrativa se
encuentra centralizada, y por ello resulta mas facil y segura de gestionar. Todo este
tema se centrara en denir y exponer los conceptos relacionados con los dominios en
NT.
Mas formalmente:
Se puede denir dominio como una agrupacion logica de servidores de red y
otros ordenadores, que comparten informacion comun sobre cuentas (de usuarios, grupos, etc.) y seguridad.
Es importante matizar que el termino dominio no incluye ninguna informacion acerca
de la ubicacion de las maquinas. No es necesario que se encuentren fsicamente cercanas,
ni que esten interconectadas mediante una red de algun tipo especco. De hecho, las
maquinas que forman un dominio pueden estar conectadas a traves de una red de area
amplia o WAN (Wide Area Network), aunque lo mas normal es que formen una red de area
local o LAN (Local Area Network).
Precisamente en el ambito de las redes de sistemas NT cobra sentido el hecho de
que existan dos versiones de este sistema operativo: NT server y NT workstation. Habitualmente, un NT server (o servidor NT) tiene un papel especial en una red NT, y se
utiliza para proporcionar servicios centralizados de red en un dominio NT. Por su parte,
un NT workstation (o estacion NT) es una maquina que, aunque puede formar parte de
un dominio, no proporciona ningun servicio al resto de maquinas, siendo una estacion de
trabajo de proposito general.
Concretamente, en un domino NT:
Existe necesariamente un servidor NT con funciones de Controlador Principal de
Dominio (Primary Domain Controller, o PDC). Este servidor posee toda la informacion
centralizada sobre cuentas de usuarios y grupos del domino, as como la informacion
acerca de que maquinas pertenecen al mismo.
Pueden existir uno o varios servidores NT con funciones de Controladores de Copia
de Dominio (Backup Domain Controller, o BDC). Si existen, conservan una copia de la
informacion de cuentas y seguridad del PDC, y regularmente se reenvan copias actualizadas de las mismas. Cualquier peticion de informacion por parte de un ordenador
(cliente) puede ser contestada por el PDC o por uno de los BDCs indistintamente.
Por otra parte, si el PDC deja de estar disponible de forma permanente, cualquiera
de los BCDs puede promocionarse a PDC mediante una sencilla accion por parte del
administrador.
Pueden existir uno o varios servidores NT sin funciones especiales de administraci
on
dentro del dominio. A estos ordenadores se les llama servidores miembro (Member
Servers). Habitualmente estas maquinas s proporcionan algun servicio especco
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
37
5.2 Usuarios y Grupos en un Domino
dentro del dominio (servicios de impresion, servicios de acceso a datos, etc.), pero
no guardan ninguna informacion administrativa.
Pueden existir una o varias estaciones NT, que se utilizar
an para trabajo habitual.
Tanto los servidores miembro como las estaciones NT son clientes del PDC (y BDCs)
respecto a la informacion relativa a usuarios, grupos, contrase~nas y autenticacion, etc.
5.2 Usuarios y Grupos en un Domino
En el Captulo 4 se ha visto como en NT pueden crearse cuentas de usuarios y grupos, y
como se utilizan ambos para controlar el acceso de las personas a un sistema NT, y para
administrar los derechos y permisos que estas poseen en dicho sistema. Por lo tanto, si
una persona tiene que trabajar en varios sistemas, debe poseer una cuenta de usuario en
cada uno.
En un dominio, el servidor NT que actua de PDC puede crear usuarios y grupos
especiales, denominados usuarios globales y grupos globales. En este caso, el termino
global se interpreta como global al dominio. Esto quiere decir que un usuario global existe
en todos los ordenadores pertenecientes al dominio, poseyendo no una cuenta en cada
maquina, sino una cuenta unica para todas ellas, y por lo tanto un unico SID. Las cuentas
de los usuarios globales residen solo en el PDC, habiendo copias en todos los BDCs. Por
este motivo:
Cuando una persona se conecta a cualquier ordenador miembro de un dominio
utilizando para ello una cuenta de usuario global, dicho ordenador contacta
con el PDC (o BDCs) del domino para que este ultimo valide la cuenta y la
contrase~na. El resultado de esta validacion es enviado al ordenador miembro,
y de este al usuario (concediendo o rechazando la conexion).
Un ordenador miembro de un dominio (una estacion NT, por ejemplo), ademas de
poder ver a los usuarios globales del dominio, puede crear tambien sus propios usuarios
locales, que son unicamente visibles en dicho ordenador. Cuando una persona desea entrar
en el sistema utilizando una cuenta local, dicha cuenta se valida contra la base de datos
local de ese ordenador. Ademas, es importante notar que a dicho usuario local no se le
pueden asignar permisos sobre recursos que residan en otro sistema NT (puesto que all
no existe). Por el contrario, a un usuario global se le pueden conceder permisos sobre
cualquier recurso (archivo, directorio, impresora, etc.) de cualquier ordenador miembro
del dominio, puesto que es visible (y posee el mismo SID) en todos ellos.
De forma analoga a los usuarios globales, los grupos globales existentes en un PDC son
visibles en todos los miembros del dominio. Todo usuario global pertenece a (al menos)
un grupo global. Los mas importantes grupos globales preinstalados en un PDC son los
siguientes: Administradores, Operadores de Copia, Operadores de Cuentas, Operadores
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
38
de Impresion, Usuarios e Invitados. Inicialmente, el grupo de Administradores lo forma
la cuenta global Administrador (del dominio), as como el grupo de Invitados lo forma
la cuenta de Invitado. Los distintos grupos de Operadores pueden considerarse como
administradores con funciones mas especcas (quedando otras fuera de su alcance). La
cuenta de Usuarios (del dominio) es a la que pertenecen por defecto los nuevos usuarios
globales que se crean en un PDC.
En un ordenador miembro de un dominio tambien se pueden denir grupos locales. Existen importantes diferencias entre los grupos locales de un miembro y los grupos globales
de un dominio. La Tabla 5.1 recoge las principales diferencias.
Un grupo global. . .
Un grupo local. . .
Existe en todos los miembros de un dominio.
Existe en el ordenador donde ha sido creado.
Solo puede poseer usuarios globales.
Puede poseer usuarios y grupos globales, y
usuarios locales. No puede poseer otros grupos locales.
Puede utilizase para concederle (o denegarle) permisos sobre recursos (archivos) en
cualquier miembro del dominio
Puede utilizase para concederle (o denegarle)
permisos sobre recursos (archivos) solo en el
ordenador donde esta denido.
Se utiliza normalmente para a~nadir usuarios
al dominio, agrupandolos en funcion del trabajo que realizan.
Se utiliza normalmente para asignar a usuarios y grupos globales los derechos de cada
ordenador miembro, as como los permisos
sobre los recursos que residen en dicho ordenador.
Tabla 5.1: Diferencias entre grupos globales y locales en Windows NT
Tal como pone de maniesto la tabla anterior, en cada ordenador (miembro) se puede
seguir estableciendo la seguridad como se expona en el Captulo 4, es decir, en base
a grupos locales. De hecho, sigue siendo valida la recomendacion de que la concesion de
derechos y la asignacion de permisos sobre los objetos/recursos del sistema se haga en base
a grupos locales. La diferencia cuando existe un dominio es que en estos grupos locales,
el administrador puede incluir tanto usuarios locales como grupos y usuarios globales del
dominio.
En relacion con esto, es importante saber que cuando un ordenador pasa a ser miembro
de un dominio (existente), el grupo global Administradores se incluye automaticamente
en el grupo local Administradores de dicho ordenador. De igual forma, el grupo global
Usuarios se incluye dentro del grupo local Usuarios. De esta forma, los administradores
y usuarios normales del dominio tienen en cada miembro los mismos derechos y permisos
que los que tengan ya denidos los administradores y usuarios locales, respectivamente.
El administrador local puede, si lo desea, invalidar esta accion automatica, extrayendo
posteriormente los grupos globales de los locales.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
39
5.3 Ordenadores Miembros de un Dominio
5.3 Ordenadores Miembros de un Dominio
Como hemos visto, en el PDC se conserva toda la informacion relativa a cuentas de
usuarios y grupos globales. En concreto, esta informacion se guarda en la denominada
Security Account Manager (SAM) database, o base de datos del Gestor de Cuentas de
Seguridad. Esta misma base de datos recoge tambien una cuenta de ordenador por cada
uno de los ordenadores miembro de un dominio.
Entre otras informaciones, en cada una de estas cuentas se almacena el nombre del
ordenador, as como un identicador unico y privado que lo identica unvocamente. Este
identicador es analogo al SID de cada cuenta de usuario, y solo lo conocen el PDC y
el propio ordenador miembro. Es por tanto, un dato interno del sistema operativo, y ni
siquiera el administrador puede consultarlo.
Mediante este identicador privado a ambos se establece lo que se conoce como un
canal de comunicacion seguro (secure communication channel) cada vez que un ordenador
miembro y el PDC necesitan comunicarse. Un ejemplo de dicha comunicacion sera la autenticacion de una cuenta de usuario global que desea conectarse a un ordenador miembro.
Este canal se considera seguro puesto que se alcanza mediante una negociacion en la que
el ordenador miembro utiliza su identicador privado, con lo que no puede ser suplantado
por otra maquina.
Los canales de comunicacion seguros se utilizan para:
Administrar remotamente los recursos de un ordenador miembro desde cualquier
otro (incluso del PDC desde una estacion NT). Para ello, el usuario debe tener los
derechos y permisos sucientes en la maquina remota.
Autenticar usuarios, como se expone arriba.
Validar las relaciones de conanza entre dominios, que se explican mas adelante.
Y, en general, siempre que informaci
on relativa a aspectos de seguridad se intercam-
bia entre maquinas NT pertenecientes a algun dominio.
5.4 Comparticion de Recursos entre Sistemas NT
Cuando un sistema NT participa en una red de ordenadores (grupo de trabajo o dominio),
puede compartir sus recursos con el resto de ordenadores. En este contexto, solo vamos a
considerar como recurso a compartir los directorios que existen en un sistema NT1 .
Cualquier sistema NT puede compartir directorios, tanto si es un servidor como si
es una estacion de trabajo. Para poder compartir un directorio, basta con desplegar
su menu contextual desde una ventana o desde el explorador de archivos, y seleccionar
1
La comparticion de otros recursos (tales como impresoras, por ejemplo) queda fuera del ambito del
presente captulo.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
40
Compartir.... En la ventana asociada a esta opcion se determina el nombre que tendra
el recurso (que no tiene por que coincidir con el nombre del directorio), as como que
usuarios van a poder acceder al mismo. En relacion con esto, existe una gran diferencia
entre que el directorio resida en una particion FAT y que resida en una NTFS.
Si el directorio reside en una particion FAT, este ltro de acceso sera el unico que
determine los usuarios que van a poder acceder al contenido del directorio, puesto que no
es posible determinar permisos sobre el propio directorio o sus archivos. Es decir, el ltro
solo se establece para poder acceder al recurso. Si un usuario tiene permisos sucientes
para conectarse a un recurso, tendra acceso sobre todos los archivos y subdirectorios del
recurso. El tipo de acceso sobre todos ellos sera el que le permita el permiso sobre el
recurso (Lectura, Escritura, Control Total, etc.).
Por el contrario, si el directorio se encuentra en una particion NTFS, este tendra
unos permisos establecidos (as como sus subdirectorios y archivos), al margen de ser un
directorio compartido. En este ultimo caso tambien es posible establecer un ltro desde la
ventana de Compartir..., pero entonces solo los usuarios que puedan pasar ambos ltros
podran acceder al directorio compartido. En este caso se recomienda lo siguiente:
Cuando se comparte un directorio que reside en una particion NTFS, se recomienda dejar Control Total sobre Todos en los permisos asociados al recurso
(opcion por defecto), y controlar quien (y como) puede acceder al recurso y a su
contenido mediante los permisos asociados a dicho directorio y a sus archivos
y subdirectorios.
Esta recomendacion es muy util, si tenemos en cuenta que de esta forma para cada
directorio (y archivo) del sistema no utilizamos dos grupos de permisos sino uno solo,
independientemente de que el directorio sea o no compartido. Este forma de trabajar
obliga al administrador a asociar los permisos correctos a cada objeto del sistema (aunque
no este compartido), pero por otra parte se unica la vision de la seguridad de los archivos,
con lo que a la larga resulta mas segura y mas sencilla. Ademas, hay que tener en cuenta
lo siguiente:
Si un usuario ha iniciado una sesion interactiva en un ordenador NT denominado A, y desea conectarse a un recurso de red que exporta otro ordenador
NT denominado B, ademas de poseer los permisos sucientes sobre el recurso,
sobre el propio directorio y sobre su contenido, tiene que tener concedido en B
el derecho de acceder a este equipo desde la red.
Por ultimo, cuando un sistema NT forma parte de un dominio, al margen de los recursos
que el administrador desee compartir, se comparten por defecto otros recursos para usos
del propio sistema y administrativos. Estos recursos no deben modicarse ni prohibirse:
a) (letra de unidad)$. Por cada particion existente en un sistema NT (C:, D:, etc.)
se crea un recurso compartido denominado C$, D$, etc. Los administradores del
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
41
5.5 Conanzas entre Dominios NT
dominio, as como los operadores de copia del domino, pueden conectarse por defecto
a estas unidades.
b) ADMIN$. Es un recurso utilizado por el propio sistema durante la administracion
remota de un ordenador NT.
c) IPC$. Recurso que agrupa los tubos (colas de mensajes) utilizados por los programas
para comunicarse entre ellos. Se utiliza durante la administracion remota de un
ordenador NT, y cuando se observa los recursos que comparte.
d) NETLOGON. Recurso que exporta un servidor NT (normalmente un PDC) para proporcionar a los ordenadores miembros del dominio el servicio de validacion de cuentas
globales a traves de la red (Net Logon service).
En relacion con los nombres de estos recursos, es interesante saber que a~nadir el caracter
'$' al nal de cualquier nombre de recurso tiene un efecto especco: prohibe que dicho
recurso se visualice dentro de la lista de recursos que una maquina exporta al resto. Es
decir, convierte un recurso en \invisible" para al resto del mundo. En este caso, un
usuario remoto solo podra conectarse al recurso si conoce su nombre de antemano (y tiene
sucientes permisos, obviamente).
5.5 Conanzas entre Dominios NT
Una relacion de conanza (trust relationship) es una relacion que une a dos dominios NT,
mediante la cual los usuarios (y grupos) globales de uno de ellos pueden utilizar los recursos
que exporta el segundo. Mas formalmente:
Cuando se establece una relacion de conanza entre dos dominios NT, los
usuarios y grupos globales del dominio de conanza (trusted domain) son visibles en los ordenadores miembro del dominio que confa (trusting domain), y
por tanto se les puede conceder permisos sobre los recursos este ultimo.
En realidad, las relaciones de conanza entre dominios se establecen entre los PDCs
de ambos, de forma que el PDC del dominio que confa valida usuarios en el PDC del
dominio de conanza.
Cuando existe una relacion de conanza entre dos dominios, los usuarios del dominio
de conanza aparecen en las listas de usuarios conocidos en los ordenadores del dominio
que confa, y en particular cuando se trata de conceder algun derecho o algun permiso.
De acuerdo con esta vision, resulta evidente que siempre existe una relacion de conanza
implcita entre todo miembro de un domino NT y su PDC.
Las relaciones de conanza entre dominios son estables, siendo necesario establecerlas manualmente (mediante una contrase~na pactada entre los administradores de ambos
dominios) y siguen vigentes hasta que se rompen explcitamente (por un administrador).
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
42
Otro aspecto importante de las relaciones de conanza es que siempre se establecen entre
dos dominios, y por tanto no son relaciones recprocas ni transitivas. Si se desea que el
dominio A confe en el dominio B y que B confe en A, es necesario establecer dos relaciones
de conanza (recprocas). Y por otra parte, si A confa en B, y B confa en C, entonces no
es cierto que A confe en C.
Se va a ilustrar el concepto de conanzas mediante el ejemplo de la Figura 5.1. En el se
muestran dos dominios denominados DominioA y DominioB. Cada dominio tiene un PDC
y tres estaciones NT, con nombres ilustrativos. La relacion de conanza establecida entre
ambos se representa mediante una echa de color gris oscuro, indicando que DominioA
confa en DominioB (esta es la forma habitual de representar gracamente una relacion
de conanza). De forma analoga, se representan mediante echas de color gris claro las
relaciones de conanza implcitas entre cada estacion y su PDC.
PDC_B
PDC_A
DominioB
WksB1
DominioA
WksB2
WksB3
WksA1
WksA2
WksA3
Figura 5.1: Ejemplo de relacion de conanza entre dominios NT.
Siguiendo con el ejemplo, supongamos que en DominioA existe un usuario global denominado UsuA, y que en DominioB existe el usuario UsuB. Para evitar ambiguedades, NT
establece que cuando se nombra a un usuario global de otro dominio se antepone el nombre
del dicho dominio al del usuario, con lo que el usuario se denomina de la siguiente forma:
dominionusuario. Por tanto, supongamos que existen DominioAnUsuA y DominioBnUsuB.
En estas circunstancias, se van a plantear varias situaciones, indicando para cada una si
es posible o no, y en su caso, las circunstancias necesarias para que se produzca:
Si el usuario UsuB desea iniciar una sesi
on interactiva en WksA1, podra hacerlo siem-
pre que en dicho ordenador se le haya concedido el derecho de Inicio de sesion local
(a el o a algun grupo al que pertenezca). Para validar la cuenta y su contrase~na,
WksA1 preguntara a PDC A, y este, viendo que el usuario pertenece a DominioB (en
el cual se confa) preguntara a su vez a PDC B.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
43
5.6 Mandatos NT para compartir recursos
Si el usuario UsuB est
a trabajando en WksB1, e intenta conectarse al recurso de red
nnWksA2nProyectos, podr
a hacerlo siempre que tenga permisos sucientes sobre el
recurso (y sobre el directorio) en WksA2, y siempre que en dicho ordenador se le haya
concedido el derecho Acceder a este equipo desde la red.
Si el usuario UsuA desea iniciar una sesion interactiva en WksB1, no podr
a hacerlo,
ya que en este equipo no aparece como usuario.
De igual forma, si el usuario UsuA esta trabajando en WksA2, e intenta conectarse
al recurso de red nnWksB1nProyectos, no podra hacerlo, ya que no aparece como
usuario, y no se le pueden conceder derechos o permisos.
5.6 Mandatos NT para compartir recursos
La comparticion de recursos en Windows NT puede realizarse utilizando los mandatos net
share y net use. La sintaxis de ambos mandatos es la siguiente:
Mandato net share
Crea, elimina o muestra recursos compartidos.
net share
net share recurso_compartido
net share recurso_compartido=unidad:ruta_de_acceso
[/users:numero | /unlimited] [/remark:"texto"]
net share recurso_compartido [/users:numero | unlimited]
[/remark:"texto"]
net share {recurso_compartido | unidad:ruta_de_acceso} /delete
Mandato net use
Conecta o desconecta un equipo de un recurso compartido o muestra informacion
acerca de las conexiones del equipo. Tambien controla las conexiones de red persistentes.
net use [nombre_dispositivo]
[\\nombre_equipo\recurso_compartido[\volumen]]
[contrase~
na | *]] [/user:[nombre_dominio\]nombre_usuario]
[[/delete] | [/persistent:{yes | no}]]
net use nombre_dispositivo [/home[contrase~
na | *]] [/delete:{yes | no}]
net use [/persistent:{yes | no}]
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
Cap
tulo 6
Niveles de ejecucion en Linux
Indice General
6.1 Inicio y Detencion de un Sistema Linux . . . . . . . . . . . . .
6.2 El Concepto de Nivel de Ejecucion . . . . . . . . . . . . . . . .
6.3 Ficheros y Directorios de Conguracion de los Niveles de Ejecucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Secuencia de Arranque de un Sistema Linux . . . . . . . . . .
6.5 Secuencia de Entrada en un Nivel de Ejecucion . . . . . . . .
6.6 Conguracion de los Niveles de Ejecucion . . . . . . . . . . . .
. 45
. 45
.
.
.
.
47
47
48
49
6.1 Inicio y Detencion de un Sistema Linux
Un sistema Linux se inicia desde el cargador del sistema (habitualmente LILO) tecleando
una simple etiqueta. Un sistema Linux debe detenerse de forma correcta, nunca apagando
directamente el ordenador. Para ello se utiliza el mandato shutdown. Este mandato se
emplea habitualmente en dos situaciones:
a) shutdown -h now: detiene el sistema ahora.
b) shutdown -r now: reinicia el sistema ahora.
6.2 El Concepto de Nivel de Ejecucion
Linux esta programado para ejecutarse en un determinado nivel de ejecucion. El numero
de niveles y sus nombre estan predeterminados. En cambio, las acciones a realizar en
45
46
cada nivel son congurables por el superusuario tal como se explica mas tarde en este
documento. La conguracion de niveles en Redhat Linux se presenta en la Tabla 6.1 a
continuacion.
Nivel Nombre
Descripcion
0
halt
Este nivel detiene el sistema.
1
single user mode
Modo de administracion. El sistema crea un shell con
los privilegios del superusuario sin solicitar nombre de
usuario o contrase~na.
2
multiuser
Modo de funcionamiento normal sin algunos servicios
de red.
3
multiuser + network
Como el modo 2 pero con todos los servicios de red
activos, NFS por ejemplo.
4
No utilizado por Redhat.
5
X11
El servidor X se inicia desde el primer momento.
6
reboot
Se reinicia el sistema.
emergency single user
Igual al nivel 1 pero sin acceder a los cheros de conguracion de inicio.
s,S
Tabla 6.1: Niveles de ejecucion en RedHat Linux.
Bajo esta perspectiva, un sistema Linux no se arranca o detiene, simplemente se cambia
su nivel de ejecucion. Algunas consideraciones importantes sobre los niveles son:
Durante un arranque normal, el sistema se coloca en el nivel 3 (multiusuario con
red) o en el nivel 5 (analogo al 3 pero con el sistema de ventanas activo desde el
inicio).
shutdown -h now cambia el nivel actual al nivel 0, halt.
shutdown -r now cambia el nivel actual al nivel 6, reboot.
/sbin/telinit cambia al nivel especicado.
/sbin/runlevel indica el nivel de ejecuci
on previo y el actual
Desde LILO puede expresarse el nivel de ejecuci
on deseado tras la etiqueta del sis-
tema operativo (Linux) a cargar.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
6.3 Ficheros y Directorios de Conguracion de los Niveles de Ejecucion
47
6.3 Ficheros y Directorios de Conguracion de los Niveles de
Ejecucion
El administrador puede congurar las acciones que deben realizarse al entrar en un determinado nivel de ejecucion. Los directorios y cheros relevantes para esta conguracion
son:
Directorio /etc/rc.d.
En el residen todos los scripts de inicializacion.
Fichero /etc/inittab
Fichero base de conguracion del arranque de la maquina.
Fichero /etc/rc.d/rc.sysinit
Script de inicializacion del ordenador, independiente del nivel .
Directorios /etc/rc.d/rc?.d
Un directorio por cada nivel de ejecucion. Contiene enlaces simbolicos a los scripts
que conguran la entrada a este nivel.
Directoiro /etc/rc.d/init.d
Aqu residen los scripts que son ejecutados desde algun nivel de ejecucion.
6.4 Secuencia de Arranque de un Sistema Linux
Cuando arranca un sistema Linux se producen las acciones siguientes:
1. Se carga e inicializa el nucleo del sistema.
2. El nucleo crea el primer proceso del sistema, denominado init.
3. Init realiza las acciones especicadas en el chero /etc/inittab.
4. Init ejecuta el script /etc/rc.d/rc.sysinit.
5. Init hace que el sistema entre en el nivel especicado en /etc/initab.
No es normal tener que congurar esta secuencia de arranque, dictaminada por los
cheros /etc/inittab y /etc/rc.d/rc.sysinit. Estos cheros son congurados en origen por quien distribuye el sistema operativo. No obstante, pueden ser necesarios para
congurar sistemas Linux con requerimientos muy especcos.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
48
6.5 Secuencia de Entrada en un Nivel de Ejecucion
Cuando se entra en un determinado nivel de ejecucion, se realizan las siguientes acciones:
1. Se ejecutan, por orden de nombre, todos los scripts que comienzan por 'K' en el
directorio correspondie nte al nivel, utilizando como argumento para dicho script
stop.
2. Se ejecutan, por orden de nombre, todos los scripts que comienzan por 'S' en el
directorio correspondiente al nivel, utilizando como argumento para dicho script
start.
A ttulo de ejemplo, a continuacion se muestra un listado del directorio /etc/rc.d/rc3.d,
el cual corresponde al nivel multiusuario con red.
ls -l rc3.d/
total 0
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
lrwxrwxrwx
1
1
1
1
1
1
1
1
1
1
1
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
13
13
15
17
17
16
16
13
15
18
11
Apr
Apr
Apr
Apr
Apr
Apr
Apr
Apr
Apr
Apr
Apr
1
1
1
1
1
1
1
1
1
1
1
1998
1998
1998
1998
1998
1998
1998
1998
1998
1998
1998
K15gpm -> ../init.d/gpm
K60lpd -> ../init.d/lpd
K95nfsfs -> ../init.d/nfsfs
S01kerneld -> ../init.d/kerneld
S10network -> ../init.d/network
S20random -> ../init.d/random
S30syslog -> ../init.d/syslog
S40atd -> ../init.d/atd
S40crond -> ../init.d/crond
S75keytable -> ../init.d/keytable
S99local -> ../rc.local
Puede observarse como en este directorio tan solo existen enlaces simbolicos a los
verdaderos scripts que residen en el directorio /etc/rc.d/init.d. Cada uno de estos
scripts aceptan dos parametros, start y stop, en funcion del cual inician o detienen el
servicio. En este ejemplo, la secuencia de entrada al nivel 3 sera:
gpm stop
lpd stop
nfsfs stop
kerneld start
network start
random start
syslog start
atd start
crond start
keytable start
rc.local start
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
49
6.6 Conguracion de los Niveles de Ejecucion
6.6 Conguracion de los Niveles de Ejecucion
La conguracion mas usual de los niveles de ejecucion se limita a indicar que scripts deben
ejecutarse al entrar en cada nivel, bien para detener o para activar un determinado servicio.
Para ello, basta crear los enlaces simbolicos adecuados o, mejor todava, utilizar alguna
herramienta graca que simplique esta labor, tal como el editor de niveles de ejecucion
que se encuentra accesible en el panel de control de RedHat. La Figura 6.1 muestra el
aspecto de dicha herramienta.
Figura 6.1: Editor de niveles de ejecucion (panel de control) de RedHat linux.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
Cap
tulo 7
Montaje de Dispositivos en Linux
Indice General
7.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.2 Utilizacion Basica . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.3 La tabla de Montaje de Dispositivos . . . . . . . . . . . . . . . . 52
7.4 Montaje de directorios remotos va NFS . . . . . . . . . . . . . 54
7.5 Otros mandatos relacionados . . . . . . . . . . . . . . . . . . . . 54
7.1 Introduccion
Unix ofrece al usuario una vision jerarquica del sistema de archivos, donde los directorios
pueden ser creados en cualquier nivel para organizar as los cheros. A diferencia de otros
sistemas, Unix ofrece una sola jerarqua, es decir, un solo directorio raz.
En sistemas tipo MS-DOS o Windows, hay varias jerarquas, tantas como unidades
de almacenamiento (particiones, disquetes, cd-roms, unidades de red) tenga el ordenador.
Cada una de estas jerarquas es identicada por una letra de unidad seguida del caracter
':', por ejemplo, D:.
Unix, en cambio, encadena todos los dispositivos que contienen sistemas de archivos en
una unica jerarqua, siendo por tanto este acceso transparente al usuario. A esta tecnica
se le denomina montaje de dispositivos.
51
52
7.2 Utilizacion Basica
Para utilizar un dispositivo que contiene un sistema de archivos se utiliza el mandato
mount, el cual utiliza dos argumentos, un nombre de dispositivo y un nombre de directorio.
Por ejemplo:
mount /dev/hdb6 /mnt
En el ejemplo anterior, el directorio raz del sistema de archivos que reside en el dispositivo /dev/hdb6 (la segunda particion logica del disco duro primario esclavo) se monta
en el directorio /mnt. De esta forma, cualquier acceso que indique /mnt hace que Unix
acceda a la particion que ha sido montada.
Linux reconoce muchos tipos de sistemas de archivos, algunos nativos del propio Linux y otros propios de otros sistemas operativos o estandares internacionales. Los mas
relevantes son:
Tipo
Descripcion
ext2
swap
Sistema de archivos nativo Linux.
Area
de intercambio en disco de Linux.
proc
Jerarqua de informacion sobre el nucleo.
msdos
Sistema FAT 16 o FAT 31 con nombres cortos.
vfat
Sistema FAT 16 o FAT 32 con nombres largos.
nfs
Directorio remoto accesible va NFS.
Tabla 7.1: Principales tipos de particiones utilizables desde Linux.
Para indicar a mount el tipo del sistema de archivos, se utiliza la opcion -t . Adicionalmente puede utilizarse el tipo auto, el cual indica a mount que reconozca de forma
automatica el tipo del sistema de archivos, opcion que resulta especialmente util en el
chero /etc/fstab, el cual se describe a continuacion. Cuando se utiliza mount sin la
opcion -t, se asume la opcion -t auto.
Debe tenerse en cuenta que lo anteriormente expuesto incluye a todo tipo de dispositivos. Por tanto, el acceso a medios no jos como cd-rom o disquete se realiza igualmente
utilizando mount.
7.3 La tabla de Montaje de Dispositivos
Con el n de simplicar y unicar la gestion de los dispositivos montados, el administrador
puede establecer en el chero /etc/fstab aquellos dispositivos que son conocidos por el
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
53
7.3 La tabla de Montaje de Dispositivos
sistema, llegando incluso a indicar si algunos de ellos deben ser montados durante el
momento del arranque del ordenador. Un ejemplo de este chero es el siguiente:
/dev/hda3
/dev/hda2
none
/dev/hdb1
/dev/hdb2
/dev/fd0
/dev/fd0
/
swap
/proc
/e700l
/e700
/A
/B
ext2
swap
proc
ext2
msdos
msdos
ext2
defaults
defaults
defaults
noauto,user
noauto,user
noauto,user
noauto,user
1
0
0
0
0
0
0
1
0
0
0
0
0
0
Cada lnea de dicho chero establece un dispositivo a montar junto con sus opciones.
Por ejemplo, la Tabla 7.2 interpreta el signicado de los parametros de la primera lnea.
Parametro
Descripcion
/dev/hda3
Dispositivo a montar.
/
Directorio donde montarlo.
ext2
Tipo del sistema de archivos.
defaults
Opciones de montaje.
1
Volcado.
1
Orden de vericacion por fsck en el arranque del
sistema. Solo debe aplicarse a los dispositivos
locales que se montan durante el arranque.
Tabla 7.2: Interpretacion del chero /etc/fstab.
Existe una gran cantidad de opciones de montaje, algunas de las cuales son dependientes del tipo del sistema de archivos (consultese el mandato mount en el manual). Las
opciones mas comunes y su signicado se presentan en la Tabla 7.3.
Una de las ventajas de este chero es que simplica la utilizacion del mandato mount,
el cual puede utilizar un solo argumento, bien sea el nombre del dispositivo o, mejor aun,
el nombre del directorio. En estos casos, mount utiliza el tipo de sistema de archivos
especicado en el chero. Por ejemplo:
mount /A
mount /e700
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
54
Opcion
Descripcion
defaults
Opciones por defecto. Incluye montar el dispositivo durante
el arranque del ordenador
auto/noauto
Si/No montar el dispositivo durante el arranque
user/nouser
Si/No permitir a un usuario convencional montar este dispositivo
ro
Montar el dispositivo en modo de solo-lectura
rw
Montar el dispositivo en modo de lectura-escritura
dev/nodev
Si/No interpretar cheros especiales de dispositivo
suid/nosuid
Si/No permitir la ejecucion de cheros con bits SETUID o
SETGID activos
Tabla 7.3: Opciones mas comunes en el montaje de dispositivos en Linux.
7.4 Montaje de directorios remotos va NFS
El protocolo NFS permite utilizar un directorio de un ordenador remoto como si se tratase
de un dispositivo, lo cual permite por tanto su montaje en el ordenador local.
Puede utilizarse directamente el mandato mount o bien crear una entrada en el chero
/etc/fstab. La forma de nombrar el dispositivo remoto es:
nombre_de_ordenador:directorio_remoto
A continuacion se muestra un ejemplo de mandato mount y la entrada correspondiente
en /etc/fstab.
mount 158.42.54.224:/diremoto /dirlocal
158.42.54.224:/diremoto /dirlocal
nfs
defaults
0 0
7.5 Otros mandatos relacionados
mkfs Crea un sistema de archivos vaco en un dispositivo.
fsck Verica la consistencia de un sistema de archivos.
df Informa sobre el espacio libre y ocupado de un sistema de archivos
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
Cap
tulo 8
Dominios en Linux
Indice General
8.1 Concepto de Dominio . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.2 Network Information System (NIS) . . . . . . . . . . . . . . . . 55
8.2.1
8.2.2
8.2.3
Instalacion de los Componentes NIS Server . . . . . . . . . . . .
Conguracion del Servidor de NIS . . . . . . . . . . . . . . . . .
Conguracion del Cliente de NIS . . . . . . . . . . . . . . . . . .
56
56
57
8.3.1
8.3.2
8.3.3
Como Funciona NFS . . . . . . . . . . . . . . . . . . . . . . . . .
Instalacion y Conguracion del Cliente NFS . . . . . . . . . . . .
Instalacion y Conguracion del Servidor NFS . . . . . . . . . . .
59
59
60
8.3 Network File System (NFS) . . . . . . . . . . . . . . . . . . . . . 57
8.1 Concepto de Dominio
En el mundo Linux no existe un concepto de dominio tan elaborado como en el mundo
de Windows NT. Sin embargo, se consigue un efecto similar al activar un servicio en una
maquina Linux (que actuara como \servidor" de cuentas y grupos) y otro servicio que
permite la exportacion de directorios a maquinas remotas. En concreto, dichos servicios
se denominan NIS y NFS, respectivamente. Ambos son explicados a continuacion.
8.2 Network Information System (NIS)
NIS (desarrollado por SUN Microsystems) es un sistema de informacion basado en red que
permite centralizar en un solo ordenador datos administrativos que son comunes a toda
55
56
Dominios en Linux
una red de area local. Para que esto sea posible, debe denirse un nombre de dominio NIS
(no confundir con el dominio DNS), instalar el servidor de NIS en un ordenador de la red,
y congurar el resto de ordenadores como clientes NIS. De ser necesario, es posible instalar
servidores NIS adicionales (a los cuales se les denomina esclavos), los cuales actuan como
replicas del servidor principal (maestro).
En principio, NIS puede ofrecer a la red cualquier tipo de tabla de informacion. No
obstante, su funcionalidad principal es centralizar las tablas de usuarios y grupos en un solo
ordenador, facilitando as las tareas del administrador, el cual, si no utilizase NIS, debera
mantener sincronizados de forma manual estos cheros. Otra de las tablas importantes que
NIS ofrece a la red es el chero /etc/hosts, tabla que asocia direcciones IP a nombres
de ordenadores. Este
es el metodo preferido para crear una base de datos comun de
ordenadores cuando no se emplea el servicio DNS, el cual es mas comun aplicarlo cuando
la red local que se esta administrando esta conectada a Internet.
Los clientes NIS, por su parte, pueden congurarse para dar preferencia a sus tablas
locales o a las que el servidor NIS ofrece. Estas preferencias se establecen en el chero
/etc/nsswitch.conf.
8.2.1 Instalacion de los Componentes NIS Server
Para instalar el servicio NIS Server, se han de realizar los siguientes pasos (exclusivamente
en el servidor):
1. Iniciar el equipo que sera el servidor del dominio NIS.
2. Montar el directorio /home/ftp/pub de adserver en el directorio local /mnt.
3. Cambiar al directorio /mnt/Redhat62/RedHat/RPMS para iniciar la instalacion
4. Instalar los componentes que constituyen el NIS server:
rpm -ih ypserv-1.3.9-3.i386.rpm
8.2.2 Conguracion del Servidor de NIS
Una vez instalados los componentes, estos deben ser congurados. Esencialmente, esto
consiste en dar de alta los servicios de NIS Server y servicios de los que depende en el
arranque de la maquina, congurar el nombre del dominio NIS y construir las bases de
datos que seran exportadas desde el servidor de NIS.
1. Instalar los servicios:
(a) Iniciar el panel de control.
(b) Iniciar, desde el panel de control, el editor de niveles de ejecucion.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
57
8.3 Network File System (NFS)
(c) De ser necesario, incorporar los siguientes servicios para que se inicien en los
niveles 3 y 5: portmap, ypserv y yppasswd
2. Nombre del dominio. Utilizando linuxconf, dar de alta el dominio NIS escogido y
la direccion IP del propio servidor de NIS (un servidor NIS debe ser cliente de si
mismo).
3. Reiniciar la maquina en este punto.
4. Construir la base de datos:
/usr/lib/yp/ypinit -m
Esta utilidad solicitara nombres de servidores secundarios. No hay ninguno disponible.
5. Reiniciar la maquina.
A partir de este punto, siempre que se produzca algun cambio en los cheros que
gestiona NIS, deben reconstruirse las bases de datos. Para ello, ejecutar:
cd /var/yp make
8.2.3 Conguracion del Cliente de NIS
La conguracion de cualquier maquina Linux que tenga que ser cliente del servidor que se
ha congurado arriba se realiza de la siguiente forma:
1. Iniciar el panel de control.
2. Iniciar, desde el panel de control, el editor de niveles de ejecucion.
3. Incorporar, si es necesario, los siguientes servicios para que se inicien en los niveles
3 y 5: portmap, ypbind.
4. Utilice linuxconf para indicar al sistema el dominio NIS y el servidor asociado a
dicho dominio.
5. Reiniciar el equipo.
Tal como se explica en el documento \Montaje de dispositivos en Linux" (de esta misma
editorial :) un sistema Linux puede trabajar unicamente con una jerarqua de directorios,
de tal forma que si se desea acceder a distintos sistemas de archivos (particiones de discos,
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
58
Dominios en Linux
cd-roms, disquetes, etc.), todos ellos deben montarse primero en algun punto de dicha
jerarqua.
Siguiendo la misma losofa, Network File System (NFS) es un servicio de red que
permite a un ordenador cliente montar y acceder a un sistema de archivos (en concreto,
un directorio) remoto, exportado por otro ordenador servidor. Por ejemplo, supongase
que una maquina denominada faemino desea acceder al directorio /home/ftp/pub de la
maquina cansado. Para ello, debera invocarse el siguiente mandato (en faemino):
mount -t nfs cansado:/home/ftp/pub /mnt
Este mandato indica que el directorio /home/ftp/pub que es exportado por el ordenador cansado debe ser montado en el directorio local /mnt de faemino. Este directorio
local debe existir previamente. La opcion -t nfs indica a mount el tipo de sistema de
archivos que va a montar, aunque en este caso podra omitirse, ya que mount detecta por
el caracter `:' que se trata de un montaje remoto.
Una vez el montaje se ha realizado, cualquier acceso a archivos o directorios dentro de
/mnt (lectura, escritura, cambio de directorio, etc.) se traducen de forma transparente a
peticiones al ordenador servidor (cansado), que las resolvera y devolvera su respuesta al
cliente, todo a traves de la red. Es decir, el montaje de directorios mediante NFS permite
trabajar con archivos remotos exactamente igual que si fueran locales, aunque logicamente
con una menor velocidad de respuesta.
En general, NFS es muy exible, y admite diversos escenarios:
Un servidor NFS puede exportar m
as de un directorio y atender simultaneamente a
varios clientes.
Un cliente NFS puede montar directorios remotos exportados por diferentes servi-
dores.
Cualquier ordenador puede ser a la vez cliente y servidor NFS.
Teniendo esto en cuenta, existen dos usos tpicos de NFS donde este servicio muestra
su utilidad:
a) Directorios de conexion (home) centralizados. Cuando en una red local de
maquinas Linux se desea que los usuarios puedan trabajar indistintamente en cualquiera de ellas, es apropiado ubicar los directorios de conexion de todos ellos en una
misma maquina y hacer que las demas monten esos directorios mediante NFS.
b) Comparticion de directorios de uso comun. Si varios usuarios (desde distintas
maquinas) trabajan con los mismos archivos (de un proyecto comun, por ejemplo)
tambien resulta util compartir (exportar+montar) el/los directorio/s donde se ubican dichos archivos.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
59
8.3.1 Como Funciona NFS
El funcionamiento de NFS esta basado, por una parte, en dos servicios de red presentes
en el ordenador servidor (mountd y nfsd) y por otra en la capacidad del cliente de traducir
los accesos de las aplicaciones a un sistema de archivos en peticiones al servidor correspondiente a traves de la red. Esta funcionalidad del cliente se encuentra normalmente
programada en el nucleo de Linux, por lo que no necesita ningun tipo de conguracion.
Respecto al servidor, el servicio mountd se encarga de atender las peticiones remotas
de montaje, realizadas por la orden mount del cliente (como la del ejemplo anterior). Entre
otras cosas, este servicio se encarga de comprobar si la peticion de montaje es valida y
de controlar bajo que condiciones se va a acceder al directorio exportado (solo lectura,
lectura/escritura, etc.). Una peticion se considera valida cuando el directorio solicitado
ha sido explcitamente exportado y el cliente tiene permisos sucientes para montar dicho
directorio. Esto se detalla mas adelante en el documento. Una vez un directorio remoto
ha sido montado con exito, el servicio nfsd se dedica a atender y resolver las peticiones de
acceso del cliente a archivos situados en el directorio.
8.3.2 Instalacion y Conguracion del Cliente NFS
Como se ha expresado anteriormente, el cliente NFS no requiere ni instalacion ni conguracion. Los directorios remotos pueden importarse utilizando el mandato mount y el
chero asociado /etc/fstab, segun se muestra en el documento \Montaje de Dispositivos
en Linux".
Recuerdese que en cada invocacion al mandato mount (y/o en cada lnea de /etc/fstab)
se pueden establecer opciones de montaje. En ellas se particulariza el comportamiento que
tendra el sistema de archivos una vez se haya montado en el directorio correspondiente.
En el caso de NFS, las opciones mas importantes son las que gobiernan el modo de fallo
de las peticiones remotas, es decir, como se comporta el cliente cuando el servidor no
responde:
a) soft. Con esta opcion, cuando una peticion no tiene respuesta del servidor el cliente
devuelve un codigo de error al proceso que realizo la peticion. El problema es
que muy pocas aplicaciones esperan este comportamiento y ello puede provocar
situaciones en las que se pierda informacion. Por tanto, no es aconsejable.
b) hard. Mediante esta opcion, cuando el servidor no responde el proceso que realizo
la peticion en el cliente se queda suspendido indenidamente. Esta es la opcion que
se recomienda normalmente, por ser la que esperan las aplicaciones, y por tanto mas
segura desde el punto de vista de los datos.
Se puede combinar con la opcion intr, que permite matar el proceso mediante el
envo de una se~nal (de la forma tradicional en Linux).
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
60
Dominios en Linux
A continuacion se muestra un ejemplo, en el que se ve la lnea del archivo (/etc/fstab
de la maquina faemino) relacionada con el ejemplo de la seccion 8.3:
#device
mountpoint fs-type options
dump fsckorder
...
cansado:/home/ftp/pub /mnt
nfs
hard,intr 0
0
8.3.3 Instalacion y Conguracion del Servidor NFS
El servidor necesita, ademas de los dos servicios mountd y nfsd (ambos se aunan en el servicio comun demominado nfs, uno mas denominado portmap (del ingles portmapper), sobre
el cual ambos basan su funcionamiento. Por tanto, la conguracion de un servidor NFS
necesita unicamente tener disponibles dichos servicios e iniciarlos en el nivel de ejecucion
3 (o 5, o ambos) de la maquina (ver documento \Niveles de ejecucion en Linux").
Una vez activos los servicios NFS, el servidor tiene que indicar explcitamente que
directorios desea que se exporten, a que maquinas y con que opciones. Para ello existe un
chero de conguracion denominado /etc/exports. A continuacion se muestra uno de
ejemplo, sobre el que se explican las caractersticas mas relevantes:
# Directory
...
/tmp
/home/ftp/pub
/
/pub
/pub/nopublic
Clients and (options)
pc02??.dsic.upv.es(rw) *.disca.upv.es()
158.42.54.1(rw,root_squash)
mio.dsic.upv.es(rw,no_root_squash)
(rw,all_squash,anonuid=501,anongid=601)
(noaccess)
Es importante destacar que cada vez que se modica este chero, para que se activen
los cambios, el servidor NFS debe ser actualizado ejecutando el mandato exportfs -ra.
Cada lnea especica un directorio que se a exportar, junto con una lista de autorizaciones, es decir, que ordenadores podran montar dichos directorios y con que opciones
(desde el punto de vista del servidor). Cada elemento de la lista de ordenadores puede
especicar un solo ordenador (mediante nombre simbolico o direccion IP) o un grupo de
ordenadores (mediante el uso de caracteres comodn como `*' o `?'). Cuando el ordendor/rango no se especica (por ejemplo, en las ultimas dos lneas), esto signica que el
directorio correspondiente se exporta a todos los ordenadores del mundo (conectados a
Internet). Por su parte, de entre las posibles opciones de montaje que, entre parentesis,
pueden especicarse para cada ordenador/grupo, las mas importantes se resumen en la
tabla 8.1.
Una lista completa de las opciones de montaje y su signicado pueden encontrarse
en la pagina de manual exports (5) de Linux. La mayora de estas opciones establecen
como quien se comporta el proceso cliente cuando su peticion de acceso llega al servidor.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
61
Opcion
Signicado
()
ro
rw
root squash
Esta opcion establece las opciones que NFS asume por defecto.
Solo lectura.
Lectura/escritura.
Los accesos desde el cliente con UID=0 (root) se convierten en
el servidor en accesos con UID de un usuario anonimo (opcion
por defecto).
Se permite el acceso desde un UID = 0 sin conversion. Es
decir, los accesos de root en el cliente se convierten en accesos
de root en el servidor.
Todos los accesos se transforman en accesos de usuario
anonimo.
Cuando se activa la opcion root squash o all squash, los
accesos anonimos utilizan norlmalmente el usuario nobody, si
existe en el servidor (defecto). Estos dos parametros establecen que uid y gid tendra la cuenta anonima que el servidor
utilizara para acceder contenido del directorio.
Impide el acceso al directorio especicado. Esta opcion es util
para impedir que se acceda a un subdirectorio de un directorio
exportado.
no root squash
all squash
anonuid, anongid
noaccess
Tabla 8.1: Opciones mas usuales en la exportacion de directorios mediante NFS.
En principio, cada peticion lleva asociada el UID y GID del proceso cliente, es decir, se
comporta como s mismo. No obstante, si esta activa la opcion all squash (o bien el UID
es cero y root squash esta activado), entonces el UID/GID se convierten en los del usuario
anonimo. De todas formas, hay que tener en cuenta que los permisos sobre cada acceso
del cliente se evaluan mediante los UID/GID que nalmente son validos en el servidor (es
decir, los originales o los anonimos, segun el caso).
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
Cap
tulo 9
Conguracion de Samba
Indice General
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
9.10
>Que es samba? . . . . . . . . . . . . . . . . . . . . . . . . .
Instalacion de Samba . . . . . . . . . . . . . . . . . . . . . .
Conguracion de Samba . . . . . . . . . . . . . . . . . . . .
Instalacion y Conguracion de swat . . . . . . . . . . . . .
Niveles de Seguridad . . . . . . . . . . . . . . . . . . . . . .
Conguracion de Samba con el Nivel de Seguridad domain
Tratamiento de los Accesos como Invitado . . . . . . . . .
El Sistema de Ficheros SMB para Linux . . . . . . . . . .
Opciones del Servidor Samba . . . . . . . . . . . . . . . . .
Opciones del Recurso . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
64
65
66
67
68
69
70
70
70
9.1 >Que es samba?
Samba es un producto1 que se ejecuta en sistemas Unix, permitiendo al sistema Unix
conversar con sistemas Windows a traves de la red de forma nativa. De esta forma, el
sistema Unix aparece en el "Entorno de red", y clientes Windows pueden acceder a sus
recursos de red e impresoras compartidas como si de otro sistema Windows se tratase.
Para ello, Samba implementa los protocolos NetBIOS y SMB. NetBIOS es un protocolo
de nivel de sesion que permite establecer sesiones entre dos ordenadores. SMB (Server
Message Block), implementado sobre NetBIOS, es el protocolo que permite a los sistemas
Windows compartir cheros e impresoras.
1
Samba se distribuye gratuitamente para varios versiones de Unix, de acuerdo con los terminos de la
General Public License de GNU.
63
64
Esencialmente, Samba consiste en dos programas, denominados smbd y nmbd. Ambos
programas utilizan el protocolo NetBIOS para acceder a la red, con lo cual pueden conversar con ordenadores Windows. Haciendo uso de estos dos programas, Samba ofrece los
siguientes servicios, todos ellos iguales a los ofrecidos por los sistemas Windows:
Servicios de acceso remoto a cheros e impresoras.
Autenticaci
on y autorizacion.
Resoluci
on de nombres.
Anuncio de servicios.
El programa smbd se encarga de ofrecer los servicios de acceso remoto a cheros e
impresoras (implementando para ello el protocolo SMB), as como de autenticar y autorizar
usuarios. smbd ofrece los dos modos de comparticion de recursos existentes en Windows,
basado en usuarios o basado en recursos. En el modo basado en usuarios (propio de los
dominios NT) la autorizacion de acceso al recurso se realiza en funcion de nombres de
usuarios registrados en un dominio, mientras que en el modo basado en recursos (propio
de Windows 3.11/95) a cada recurso se le asigna una contrase~na, estando autorizado el
acceso en funcion del conocimiento de dicha contrase~na.
El programa nmbd permite que el sistema Unix participe en los mecanismos de resolucion de nombres propios de Windows, lo cual incluye el anuncio en el grupo de trabajo,
la gestion de la lista de ordenadores del grupo de trabajo, la contestacion a peticiones de
resolucion de nombres y el anuncio de los recursos compartidos. De esta forma, el sistema
Unix aparece en el "Entorno de Red", como cualquier otro sistema Windows, publicando
la lista de recursos que ofrece al resto de la red.
Adicionalmente a los dos programas anteriores, Samba ofrece varias utilidades. Algunas de las mas relevantes son las siguientes:
smbclient. Una interfaz similar a la utilidad ftp, que permite a un usuario de un
sistema Unix conectarse a recursos SMB y listar, transferir y enviar cheros.
swat (Samba Web Administration Tool). Esta utilidad permite congurar Samba
de forma local o remota utilizando un navegador de web.
Sistema de cheros SMB para Linux. Linux puede montar recursos SMB en su
jerarqua, al igual que sucede con directorios compartidos va NFS.
9.2 Instalacion de Samba
Los pasos que hay que seguir para instalar Samba en RedHat Linux son los siguientes:
1. Montar el directorio /home/ftp/pub de adserver en el directorio local /mnt.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
65
9.3 Conguracion de Samba
2. Cambiar al directorio /mnt/redhat62/RedHat/RPMS para iniciar la instalacion.
3. Instalar Samba:
rpm -ih Samba-2.0.6-9.i386.rpm
Una vez instalado Samba, hay que vericar que el servicio smb esta activo en el niveles
de ejecucion 3 y/o 5, y despues reiniciar el sistema.
9.3 Conguracion de Samba
La conguracion de Samba se realiza en el chero /etc/smb.conf. En este chero se
establecen las caractersticas del servidor Samba, as como los recursos que seran compartidos en la red. La utilizacion de este chero es bastante sencilla, ya que aunque existe
un gran numero de opciones, muchas de ellas pueden obviarse dado que siempre existe
una valor por defecto para cada opcion, que suele ser apropiado. A ttulo de ejemplo, en
la Figura 9.1 se muestra un chero de conguracion simple, que exporta el directorio de
conexion de cada usuario como un recurso de red distinto, y el directorio /espacio/pub
como el recurso de red pub.
[global]
...
[homes]
comment = Home Directories
...
[pub]
path = /espacio/pub
Figura 9.1: Fichero /etc/smb.conf
Como se ve en el ejemplo, el chero /etc/smb.conf se encuentra divido en secciones,
encabezad s por una palabra entre corchetes. Dentro de cada seccion guran opciones
de conguracion, de la forma etiqueta = valor, que determinan las caractersticas del
recurso exportado por la seccion. En los apartados 9.9 y 9.10 del presente documento se
citan las opciones mas importantes que se pueden establecer en cada seccion.
Existen tres secciones predenidas, denominadas global, homes y printers, y tantas
secciones adicionales como recursos extra se quieran compartir. El cometido de dichas
secciones predenidas se describe en la Tabla 9.1, a continuacion.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
66
Seccion
Cometido
[global]
Dene los parametros de Samba a nivel global del servidor, as
como los parametros que se estableceran por defecto en el resto
de las secciones.
Dene automaticamente un recurso de red por cada usuario
conocido por Samba. Este recurso, por defecto, esta asociado al directorio de conexion de cada usuario en el ordenador en
el que Samba esta instalado.
Dene un recurso compartido por cada nombre de i mpresora
conocida por Samba.
[homes]
[printers]
Tabla 9.1: Secciones globales en el chero /etc/smb.conf.
Para cualquier otro recurso (directorio o impresora) que se quiera compartir hay que
denir una seccion adicional en el chero de conguracion. El encabezamiento de dicha
seccion (pub en el ejemplo anterior) correspondera al nombre que el recurso tendra en la
red.
Por otra parte, Samba ofrece una interfaz de edicion de este chero basada en web
denominada swat. Esta herramienta permite congurar Samba utilizando un navegador
de red, tanto de forma local como remota.
9.4 Instalacion y Conguracion de swat
swat es un programa que atiende peticiones http en el puerto tcp 901. Para activar swat
es necesario seguir los pasos siguientes:
1. Instalar el servicio inetd.
rpm -ih inetd-0.16-4.i386.rpm
2. Declarar el servicio swat. Incluir o vericar que ya existe la siguiente lnea en el
chero /etc/services:
swat 901/tcp
3. Asociar el programa swat al nuevo servicio. Descomentar la siguiente lnea en el
chero /etc/inetd.conf:
#swat stream nowait.400 root /usr/sbin/swat swat
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
67
9.5 Niveles de Seguridad
4. Activar el servicio swat:
/etc/rc.d/init.d/inet start
A partir de este momento, la conguracion de Samba puede realizarse va Web. Para ello, basta con acceder a la direcion http://nombre de ordenador:901/ mediante cualquier
navegador.
9.5 Niveles de Seguridad
Una de las consideraciones mas importantes a la hora de congurar Samba es la seleccion
del nivel de seguridad.
Desde la perspectiva de un cliente, Samba ofrece dos modos de seguridad, denominados
share y user, al igual que sucede en los sistemas Windows:
a) Modo Share. En el modo share, cada vez que un cliente quiere utilizar un recurso
ofrecido por Samba, debe suministrar una contrase~na de acceso asociada a dicho
recurso.
b) Modo User. En el modo user, el cliente debe establecer en primer lugar una
sesion con el servidor Samba, para lo cual le suministra un nombre de usuario y
una contrase~na. Una vez Samba valida al usuario, el cliente obtiene permiso para
acceder a los recursos ofrecidos por Samba.
En cualquiera de ambos, Samba tiene que asociar un usuario del sistema Unix en el
que se ejecuta Samba con la conexion realizada por el cliente. Este usuario es el utilizado
a la hora de comprobar los permisos de acceso a los cheros y directorios que el sistema
Unix/Samba comparte en la red.
La seleccion del nivel de seguridad se realiza con la opcion security, la cual pertenece
a la seccion [global]. Sus alternativas son las siguientes:
security = share | user | server | domain
Desde la perspectiva del cliente, el nivel share corresponde al modo de seguridad share
y los niveles user, server y domain corresponden todos ellos al modo de seguridad user.
A continuacion se describen someramente los cuatro niveles.
El nivel share es utilizado normalmente en entornos en los cuales no existe un dominio
NT, dado que es complejo y costoso el mantenimiento de una tabla de usuarios global para
la red. En este caso, se asocia una contrase~na por cada recurso, que debe proporcionarse
correctamente desde el cliente cuando se pide la conexion.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
68
En el nivel user, el encargado de validar al usuario es el sistema Unix donde Samba
se ejecuta. La validacion es identica a la que se realizara si el usuario iniciase una sesion
local en el ordenador Unix. Para que este metodo sea aplicable, es necesario que existan
los mismos usuarios y con identicas contrase~nas en los sistemas Windows y en el sistema
Unix donde Samba se ejecuta.
Recientemente, la utilizacion de este nivel se ha vuelto complicada, ya que en Windows
98 y en Windows NT (Service Pack 3 y posteriores), las contrase~nas de los usuarios se
transmiten cifradas por la red. Puesto que el tipo de cifrado no es conocido por Samba,
el sistema Unix ya no pue de realizar la validacion. Existen dos metodos para resolver
este problema. El primero consiste en modicar el registro del sistema Windows para
permitir la transferencia de contrase~nas sin cifrar por la red. El segundo metodo obliga a
utilizar una tabla de contrase~nas adicional en el sistema Unix, en la cual se almacenan las
contrase~nas cifradas de los usuarios Windows.
En el nivel server, Samba delega la validacion del usuario en otro ordenador, normalmente un sistema Windows NT. Cuando un cliente intenta iniciar una sesion con Samba,
este ultimo intenta iniciar una sesion en el ordenador en el cual ha delegado la validacion
con la misma acreditacion (usuario+contrase~na) recibidos del cliente. Si la sesion realizada por Samba es satisfactoria, entonces la solicitud del cliente es aceptada. Este metodo
aporta la ventaja de no necesitar que las contrase~nas se mantengan sincronizadas entre
los sistemas Windows y Unix, ya que la contrase~na Unix no es utilizada en el proceso de
validacion. Adicionalmente, no hay inconveniente en utilizar contrase~nas cifradas, ya que
la validacion la realiza un sistema NT.
Por ultimo, existe la posibilidad de utilizar el nivel domain. Este nivel es similar al
nivel server, aunque en este caso el ordenador en el que se delega la validacion debe ser
un PDC (o un a lista de ordenadores PDC y BDC). La ventaja de este metodo estriba en
que el ordenador Samba pasa a ser un verdadero miembro del dominio NT, lo que implica,
por ejemplo, que puedan utilizarse las relaciones de conanza establecidas por el dominio.
Esto signica, en pocas palabras, que usuarios pertenecientes a otros dominios en los que
el PDC confa son conocidos por Samba. Por otra parte, como comentan los creadores
de Samba, este metodo permitira en un futuro cercano eliminar la necesidad de mantener
una tabla de usuarios en el sistema Unix sincronizada con la tabla de usuarios del dominio
NT. En n, tal como dicen ellos, watch for this code soon!.
Dadas las ventajas de el nivel domain, este documento se centra fundamentalmente en
este metodo. Para detalles especcos de los otros niveles, se recomienda la consulta de la
documentacion original de Samba.
9.6 Conguracion de Samba con el Nivel de Seguridad domain
Los pasos a seguir para congurar Samba con el nivel de seguridad domain son los siguientes:
1. Dar de alta en el PDC al sistema Unix donde se ejecuta Samba como miembro del
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
69
9.7 Tratamiento de los Accesos como Invitado
dominio. Esta accion se realiza desde el "Administrador de Servidores".
2. Detener el servidor Samba:
/etc/rc.d/init.d/smb stop
3. Agregar el sistema Unix al dominio.
smbpasswd -j DOMINIO -r PDC_DEL_DOMINIO
4. Congurar el nivel en el chero /etc/smb.conf. En la seccion [global] incorporar:
security = domain
workgroup = DOMINIO
encrypt passwords = yes
password server = PDC_DEL_DOMINIO
5. Iniciar el servidor Samba:
/etc/rc.d/init.d/smb start
9.7 Tratamiento de los Accesos como Invitado
Cuando se utiliza el nivel de seguridad domain, el tratamiento de los accesos como usuario
invitado requiere algunas consideraciones.
En primer lugar, Samba considera a un usuario como invitado solo cuando este usuario
esta dado de alta en el dominio NT al cual pertenece Samba pero no esta dado de alta en
el sistema Unix donde Samba se ejecuta. De esta forma, usuarios de otros dominios (en
los que no se confa) no pueden acceder a Samba, ni siquiera como invitados.
Para conseguir que usuarios ajenos al dominio NT se consideren invitados, es necesario
activar la siguiente opcion en la seccion [global]:
map to guest = Bad User
De esta forma, cualquier usuario no conocido sera tratado como invitado. Samba
considerara que los accesos al sistema de cheros Unix los realizara el usuario especicado
en la opcion global guest account. En cualquier caso, el acceso como invitado debe
permitirse expresamente para cada recurso con la opcion guest ok.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
70
9.8 El Sistema de Ficheros SMB para Linux
Linux dispone de soporte para el sistema de cheros SMB. De esta forma, Linux, al igual
que puede montar un directorio exportado va NFS en un directorio local, puede montar
un recurso SMB ofrecido por un servidor SMB (un sistema Windows o un servidor Samba,
por ejemplo).
No obstante, existe una diferencia signicativa entre NFS y SMB. En NFS no se
requiere autenticar al usuario que realiza la conexion; el servidor NFS utiliza el UID del
usuario del ordenador cliente para acceder a los cheros y directorios exportados. Un
servidor SMB, por contra, requiere autenticar al usuario, para lo que necesita un nombre
de usuario y una contrase~na. Por ello, para montar un recurso SMB se utiliza el mandato
mount indicandole un tipo de sistema de archivos especco, denominado smbfs:
mount -t smbfs -o username=NOMBRE_DE_USUARIO,passwd=CONTRASE~NA,workgroup=
GRUPO o DOMINIO //ORDENADOR/RECURSO DIRECTORIO\_LOCAL
Si se omite la opcion passwd, se solicita al usuario que introduzca una contrase~na. Si
el servidor SMB valida al usuario, a partir del directorio directorio local se consigue
el acceso al recurso //ordenador/recurso.
El recurso puede desmontarse utilizando el mandato umount, cuya utilizacion es la
siguiente:
umount directorio_local
9.9 Opciones del Servidor Samba
En la Tabla 9.2 a continuacion se describen algunas opciones del servidor Samba. Estas
opciones tan solo son aplicables a la seccion [global].
9.10 Opciones del Recurso
En la Tabla 9.4 al nal del captulo se describen algunas opciones aplicables a cada recurso
compartido. Pueden establecerse tambien en la seccion global, siendo en este caso utiliz
das como valores por defecto para cada recurso compartido.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
71
9.10 Opciones del Recurso
Opcion
Signicado
Valor por defecto
netbios name
Nombre NetBIOS del ordenador
Primer componente de su
nombre DNS
log level
Detalle en la auditora de Samba. Es un numero
que indica la cantidad de informacion a auditar.
A mayor valor, mas cantidad de informacion.
Se establece en el script que
inicia el servicio Samba.
log file
Nombre del chero donde se almacenan mensajes de auditora de Samba.
Se establece en el script que
inicia el servicio Samba.
wins server
Ordenador servidor de WINS. El sistema Samba
se convierte en cliente WINS.
nulo.
wins support
fyes/nog
El ordenador Samba se convierte en servidor
WINS (funcionalidad limitada).
no.
Tabla 9.2: Principales opciones de la seccion [global] de Samba.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
72
Opcion
Signicado
Valor por defecto
read only
fyes/nog
Recurso de solo lectura.
yes
browseable
fyes/nog
El servicio aparece en la lista de recursos compartidos.
yes
path
Directorio asociado al servicio.
|
comment
Descripcion del servicio.
|
guest ok
fyes/nog
Permitir los accesos en modo invitado.
no
guest account
Si un acceso se realiza como invitado (usuario
no conocido) se utiliza el usuario indicado para
representar la conexion.
nobody
guest only
Cualquier acceso se realiza en modo invitado.
no
copy
Duplica un servicio ya declarado
|
force user
Los accesos al recurso se realizan como si el
usuario que accede es el usuario indicado.
Se utiliza el mismo
usuario que ha realizado la
conexion.
force group
Los accesos al recurso se realizan como si el
usuario que accede pertenece al grupo indicado.
Se utiliza el grupo primario
del usuario que ha realizado
la conexion.
hosts allow
Lista ordenadores a los que se permite acceder.
lista vaca (i.e., todos los
ordenadores).
hosts deny
Lista ordenadores a los que no se les permite
acceder. En caso de conicto, prevalece lo indicado en hosts allow.
ningun ordenador.
valid users
Lista de usuarios que pueden acceder a este recurso.
lista vaca (i.e., todos los
usuarios).
follow
symlinks
fyes/nog
Permitir el seguimiento de los enlaces simbolicos.
yes
Tabla 9.4: Principales opciones de recurso de Samba.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
Cap
tulo 10
Servicio de Nombres de Internet de
Windows
Indice General
10.1
10.2
10.3
10.4
10.5
Descripcion Basica de WINS . . . . . . . . . . . . .
Servidores de Duplicacion . . . . . . . . . . . . . . .
El Proceso de Registro, Renovacion y Liberacion .
El Proceso de Resolucion de Nombres . . . . . . . .
Instalacion del Servidor y de los Clientes WINS en
...
...
...
...
NT
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
73
75
76
77
77
10.1 Descripcion Basica de WINS
El Servicio de Nombres de Internet de Windows o WINS (Windows Internet Naming Service)
es un servicio de red, especco de Windows NT Server, que proporciona una traduccion
de nombres (de equipo) NetBIOS a direcciones IP.
NetBIOS es un protocolo de sesion que utilizan los programas basados en Windows1
cuando se comunican con otros equipos a traves de la red. Por debajo, este protocolo
puede estar soportado por distintos protocolos de transporte, como por ejemplo NetBeui,
IPX o TCP/IP. En este ultimo caso, cuando NetBIOS se implementa encima de TCP/IP,
es necesario traducir de alguna manera los nombres simbolicos de maquinas en direcciones
IP, para que los mensajes lleguen a su destino.
Un equipo con Windows NT tiene cuatro alternativas para realizar esta traduccion:
1
Entiendase cualquier version de Windows (3.11, 95, 98, NT, etc.).
73
74
Servicio de Nombres de Internet de Windows
1) Difusion de direcciones IP (broadcast). Es decir, se emite un mensaje a toda
la red local, y la maquina cuyo nombre simbolico coincide con el que gura en el
mensaje, se comunica con el emisor, diciendole su IP.
2) Ficheros locales. Estos cheros cuentan con asociaciones estaticas del tipo nombre/direccion IP. En Windows NT, dichos cheros se denominan LMHOSTS y HOSTS.
3) Consultar a un servidor DNS (Domain Name Service). Estos servidores poseen
cheros estaticos de asociacion de nombres/direcciones IP, y son capaces de resolver
peticiones en este sentido. Estos cheros tienen que ser generados manualmente por
el administrador del servidor.
4) Consultar a un servidor WINS, tambien denominado servidor de nombres NetBIOS.
La alternativa de utilizar un servidor WINS para la resolucion de nombres tiene ventajas importantes respecto a las otras tres:
Las difusiones provocan un gran traco en la red, que sera mayor cuantos mas equipos
esten conectados a la misma. Este traco no lleva informacion de aplicacion, con lo
que el rendimiento del acceso a la red se degrada.
Los cheros est
aticos LMHOSTS y HOSTS son difciles de mantener, puesto que han de
ser editados manualmente, y ademas tienen que residir en cada equipo.
Los servidores DNS son una soluci
on aceptable cuando las asociaciones entre nombres
de equipo y direcciones IP son jas. Sin embargo, si hay frecuentes cambios en dichas
asociaciones es difcil mantener consistente la base de datos de asociaciones con la
situacion real en cada momento. Esto ocurre, por ejemplo, cuando esta activo el
servicio DHCP (ver captulo 11).
Frente a la solucion aportada por DNS, WINS plantea una aproximacion diferente:
Un servidor WINS posee una base de datos (de asociaciones) en donde se van registrando dinamicamente las maquinas Windows conforme van arrancando y conectandose a la
red. Cuando una de estas maquinas (o clientes WINS ) va a apagarse, lo comunica a su
servidor WINS, el cual lo elimina de la base de datos. De esta forma, la base de datos se
encuentra siempre actualizada con los nombres de los equipos (y sus IPs) conectados en
cada momento a la red. Cuando un cliente WINS desea averiguar la direccion IP de otro
equipo, simplemente se lo pregunta a su servidor WINS.
Esta forma de trabajar es la solucion mas natural en redes Windows, tanto si tenemos
activo el servicio DHCP como si no. El motivo de ello es que para WINS es indiferente la
forma en que un equipo haya recibido su direccion IP (manualmente o a traves de DHCP),
as como si esta direccion es siempre la misma, o cambia cada vez que arranca el equipo.
Ademas, este servicio resuelve otro grave problema de las redes NetBIOS: la duplicidad
de nombres de equipo en la red. Cuando en una misma red local existen dos equipos con
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
75
10.2 Servidores de Duplicacion
el mismo nombre, el conicto provoca habitualmente que las aplicaciones encuentren uno
u otro aleatoriamente (o incluso que no se encuentre ninguno de ambos). Al estar activo
WINS, cuando un equipo intenta registrarse con un nombre ya en uso, la operacion de
registro es rechazada, y el equipo no puede conectarse a la red.
10.2 Servidores de Duplicacion
Si se desea activar el servicio WINS en una red Windows, es necesario que al menos un NT
Server conectado a la misma ofrezca el servicio WINS al resto de equipos (NT Workstation
no puede ofrecer este servicio).
Sin embargo, en redes con un numero de equipos medio o alto es deseable tener mas
de un servidor WINS, puesto que de esta forma:
Se reparte entre todos los servidores la carga provocada por el registro de equipos y
la consulta de direcciones IP.
Se replica la informaci
on que cada servidor tiene, lo que produce una cierta tolerancia
a fallos en la resolucion de nombres en la red.
Adicionalmente los servidores WINS pueden utilizarse para la resolucion de nombres
NetBIOS entre ordenadores que pertenecen a redes fsicas diferentes. En estos casos, en
cada red se instala un servidor WINS, el cual registra los ordenadores de su red. A su vez,
se conguran todos los servidores WINS para que repliquen su informacion, consiguiendo
as que cada servidor WINS conozca tambien a los ordenadores que no forman parte de
su red, suministrando esta informacion a sus clientes.
Cuando en una red hay varios servidores WINS, todos ellos han de intercambiar la informacion que contienen sus bases de datos, para que la informacion acerca de los equipos
conectados sea completa y consistente, y para que sea accesible a cualquier cliente. Para
ello, cada servidor WINS tiene que congurarse como servidor de extraccion y como servidor de insercion de otro u otros servidores WINS. En concreto:
a) Servidor de Extraccion (Pull Partner). Si un servidor WINS A se congura como
servidor de extraccion de otro servidor B, entonces A le solicitara a B cada cierto
tiempo que le enve su base de datos (o en cualquier momento, a peticion del administrador). La Figura 10.1 muestra el sentido en que uira la informacion en el caso
de que el servidor WINS 2 actuara como servidor de extraccion del WINS 1.
b) Servidor de Insercion (Push Partner). Si un servidor WINS A se congura como
servidor de insercion de otro servidor B, entonces A le enviara a B su base de datos
cuando se produzca en ella un numero determinado de cambios (o en cualquier
momento, a peticion del administrador). La Figura 10.1 muestra el sentido en que
uira la informacion en el caso de que el servidor WINS 1 actuara como servidor de
insercion del WINS 2.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
76
WINS_1
WINS_2
Servidor de Insercion
Servidor de Extraccion
(Push Partner)
(Pull Partner)
Figura 10.1: Servidores de Insercion y Extraccion en WINS.
10.3 El Proceso de Registro, Renovacion y Liberacion
Cuando un cliente WINS se inicia, enva un mensaje directo a su servidor WINS principal,
informandole de (entre otros) su direccion IP y su nombre NetBIOS. Cuando es recibido
por el servidor, este busca en su base de datos y comprueba si dicho nombre de equipo
ya ha sido registrado. Si no hay conicto, registra el nombre e informa positivamente al
cliente, que puede entonces nalizar su arranque.
Por el contrario, si ya existe otro equipo registrado con el mismo nombre, el servidor
intenta contactar con el, para comprobar que se encuentra efectivamente conectado. Si
recibe respuesta del propietario actual del nombre, entonces enva un mensaje negativo al
aspirante, que no podra conectarse utilizando este nombre.
De forma similar a lo que ocurre con DHCP, un registro positivo se considera como
una concesion, teniendo un tiempo de validez denominado tiempo de vida o TTL (Time
To Live). Cuando la mitad de dicho tiempo de vida ha transcurrido, el cliente empieza a
enviar mensajes de renovacion del nombre al servidor WINS primario cada cierto tiempo,
hasta que este le contesta positivamente.
Por ultimo, cuando un cliente WINS es apagado correctamente, este enva un mensaje
de liberacion al servidor WINS. El servidor WINS comprueba si dicho cliente era el propietario del nombre, y en ese caso le devuelve un mensaje positivo. Si ocurre algun error,
el mensaje del servidor al cliente sera negativo. Sin embargo, el cliente no comprueba
el contenido del mensaje, y en cualquier caso continua con el proceso de detencion del
equipo.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
77
10.4 El Proceso de Resolucion de Nombres
10.4 El Proceso de Resolucion de Nombres
En el contexto de las redes TCP/IP, se denomina resolucion de nombres al proceso de
averiguar la direccion IP de un equipo, dado su nombre simbolico.
Los equipos Windows (en general) pueden caracterizarse en cuatro clases, en funcion
de como realizan la resolucion de nombres:
a) Clase b-node (broadcast node). Utiliza unicamente difusiones IP para averiguar la
direccion IP de un equipo.
b) Clase p-node (point-to-point node). Utiliza comunicacion directa (punto a punto)
con un servidor de nombres NetBIOS, es decir, un servidor WINS en redes NT.
c) Clase m-node (mix node). Utiliza una mezcla de las dos primeras, pero primero
intenta resolver el nombre mediante una difusion, y si no lo consigue, trata de contactar con un servidor WINS.
d) Clase h-node (hybrid node). Utiliza una combinacion hbrida de las dos primeras
para la resolucion de nombres, pero solo realiza una difusion cuando falla la solicitud
al servidor WINS (por ejemplo, si no esta disponible en ese momento). En concreto,
el orden que sigue un nodo hbrido para resolver un nombre es: contactar con servidor(es) WINS, difusion IP, chero LMHOSTS, chero HOSTS, y por ultimo, contactar
con servidor(es) DNS.
Cuando un sistema NT es congurado como cliente WINS, por defecto se establece
como nodo hbrido. Por otra parte, el tipo de nodo es uno de los parametros de conguracion que un servidor DHCP puede asociar a un cliente. Un equipo cualquiera puede
saber de que tipo es mediante el mandato ipconfig /all.
10.5 Instalacion del Servidor y de los Clientes WINS en NT
Para instalar este servicio, se debe ir al Panel de Control de Windows NT Server, y dentro
del mismo, abrir la conguracion de red. Entonces se nos presenta en pantalla un cuadro
con diversas pesta~nas (Identificacion, Servicios, Protocolos, etc.).
En la pesta~na Servicios se puede observar que servicios de red proporciona el sistema
actualmente. Entonces se debe pinchar en el boton Agregar..., y buscar en la lista el
Servicio de Nombres de Internet de Windows.
Una vez hecho esto, se nos pedira (como no) que reiniciemos el equipo. A partir de
ese momento se a~nade al menu Herramientas Administrativas (comun) la aplicacion
Adminstrador WINS, con la que podremos empezar a congurar el servicio.
Respecto a los clientes, lo unico que se debe hacer es ir a Panel de control/ Red/
Protocolos, seleccionar el protocolo TCP/IP, y pinchar en el boton Propiedades. En
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
78
el cuadro de dialogo que se muestra entonces hay que pinchar en la pesta~na Direccion
WINS, y all especicar la direccion IP del servidor WINS principal (y del secundario, si
existe).
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
Cap
tulo 11
Servicio DHCP en Windows NT
Indice General
11.1
11.2
11.3
11.4
11.5
Descripcion Basica de DHCP . . . . . . . . . . . . . . . .
Concepto de Ambito . . . . . . . . . . . . . . . . . . . . .
Instalacion del Servidor y de los Clientes DHCP en NT
El Administrador DHCP de NT . . . . . . . . . . . . . .
La Utilidad ipconfig . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
81
81
82
83
11.1 Descripcion Basica de DHCP
DHCP (Dynamic Host Conguration Protocol) o Protocolo Dinamico de Conguracion de
Equipos no es un protocolo especco de Windows NT, sino que se trata de un estandar
para cualquier tipo de sistema conectado a una red TCP/IP.
La funcion basica de este protocolo es evitar que el administrador tenga que congurar
manualmente las caractersticas propias del protocolo TCP/IP en cada equipo. Para ello,
existe en la red un sistema especial, denominado servidor DHCP, que es capaz de asignar
la conguracion TCP/IP al resto de maquinas presentes en la red, o clientes DHCP,
cuando estos arrancan. Entre los datos que mas habitualmente proporciona el servidor a
los clientes se incluyen:
Una direcci
on IP por cada tarjeta de red o NIC (Network Interface Card) que posea
el cliente.
La m
ascara de subred.
La puerta de enlace o gateway.
79
80
Otros parametros adicionales, como el sujo del dominio DNS (Domain Name Sys-
tem), o el propio servidor DNS.
En una red pueden convivir equipos que sean clientes DHCP con otros cuya conguracion se haya establecido manualmente1 . Aquellos que esten congurados como clientes
DHCP necesitaran encontrar en la red local un servidor DHCP para que les proporcione
sus parametros TCP/IP.
Cuando un cliente DHCP arranca por primera vez, lanza por la red un mensaje de
difusion2, solicitando una direccion IP. Si en la red existe un solo servidor DHCP, cuando
este reciba el mensaje contestara al cliente asociandole una direccion IP (junto con el resto
de parametros). En concreto, el servidor DHCP puede estar congurado para asignar al
cliente una direccion IP cualquiera de las que tenga disponibles, o bien para asignarle una
direccion en concreto (o direccion reservada), en funcion de la direccion fsica ethernet del
cliente. En cualquiera de ambos casos, una vez el cliente recibe el mensaje del servidor,
ya tiene una conguracion IP con la que poder acceder a la red de forma normal.
Si en la red hay mas de un servidor DHCP, es posible que dos o mas servidores escuchen la peticion, y le contesten. Entonces, el primer mensaje que recibe el cliente es
aceptado, y el resto son rechazados. Es muy importante resaltar que cuando hay varios
servidores DHCP en una misma red local, estos no se comunican entre ellos para saber
que direcciones IP debe asignar cada uno. Es responsabilidad de los administradores que
sus conguraciones sean independientes y consistentes. Es decir:
Cuando en una misma red TCP/IP existe mas de un servidor DHCP, es imprescindible que esten congurados de manera que no puedan asignar la misma
direccion IP a dos ordenadores distintos. Para ello basta que los rangos de direcciones IP que puedan proporcionar no tengan direcciones comunes, o, si las
tienen, que estas sean direcciones reservadas.
En cualquiera de los casos anteriores, desde el punto de vista del cliente los parametros
que ha recibido se consideran una concesion, es decir, son validos durante un cierto tiempo.
Cada vez que el cliente arranca, o bien cuando se alcanza el lmite de la concesion (lease
time) el cliente tiene que solicitar su renovacion. Cuando el servidor recibe este mensaje
de renovacion puede hacer dos cosas:
a) Renovar la concesion al cliente durante otro intervalo de tiempo, o bien
b) Denegar la concesion, con lo que la direccion IP del cliente pasa al conjunto de
direcciones disponibles del servidor, y el cliente es forzado a solicitar otra direccion,
de nuevo mediante una difusion.
1
Siempre que no haya repeticiones entre las IPs que reciben los clientes DHCP y las que poseen los
equipos congurados manualmente.
2
Una difusion (o broadcast) es un mensaje que se enva de una sola vez a todas las maquinas presentes
en la red local.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
81
11.2 Concepto de Ambito
A criterio del administrador, existe la posibilidad de que la concesion de ciertos equipos
(o de todos) se especique como \sin lmite", con lo que la direccion pasa a estar asociada
a la maquina (que la adquiera) para siempre.
El protocolo DHCP es especialmente util cuando el parque de equipos de una organizacion se distribuye en varias subredes fsicas, y ademas los equipos cambian de ubicacion
(de subred) con cierta frecuencia. En este caso, cambiar el equipo de sitio no supone nunca
recongurar manualmente sus parametros de red, sino simplemente conectarlo a la nueva
red y arrancarlo.
11.2 Concepto de Ambito
En el contexto de DHCP, un ambito (scope) se dene como una agrupacion administrativa
de direcciones IP que posee una serie de parametros de conguracion comunes y que se
utiliza para asignar direcciones IP a clientes DHCP situados en una misma red fsica.
Es decir, para que un servidor DHCP pueda asignar direcciones IP a sus potenciales
clientes, es necesario que dena al menos un ambito en cada red fsica en la que haya
clientes que atender. El administrador debe establecer para dicho ambito sus parametros
de conguracion, tales como el rango de direcciones IP que puede asignar, las direcciones
excluidas, la mascara de red3 , el lmite de tiempo que los equipos pueden disfrutar de la
concesion, etc.
En cualquier caso, para que un servidor DHCP pueda atender varias redes fsicas
distintas interconectadas, es necesario que este conectado a dichas redes, o bien que los
encaminadores utilizados tengan la capacidad de encaminar los mensajes del protocolo
DHCP entre dichas redes. De no ser as, es necesario utilizar un servidor DHCP distinto
en cada red.
En cada ambito solo se admite un rango consecutivo de direcciones IP. Si todas las
direcciones de dicho rango no deben ser asignadas, es posible tambien denir subrangos
(o direcciones individuales) que deban ser excluidos del rango.
11.3 Instalacion del Servidor y de los Clientes DHCP en NT
Para instalar este servicio, se debe ir al Panel de Control de Windows NT Server, y dentro
del mismo, abrir la conguracion de red. Entonces se nos presenta en pantalla un cuadro
con diversas pesta~nas (Identificacion, Servicios, Protocolos, etc.).
En la pesta~na Servicios se puede observar que servicios de red proporciona el sistema
actualmente. Entonces se debe pinchar en el boton Agregar..., y buscar en la lista el
servicio DHCP.
3
Puesto que cada ambito solo puede servir para congurar clientes situados en una misma red fsica, la
mascara de subred de cada ambito es unica.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
82
Una vez hecho esto, se nos pedira que reiniciemos el equipo. A partir de ese momento
se a~nade al menu Herramientas Administrativas (comun) la aplicacion Adminstrador
DHCP, con la que podremos empezar a congurar el servicio.
Respecto a los clientes, lo unico que se debe hacer es ir a Panel de control/ Red/
Protocolos, seleccionar el protocolo TCP/IP, y pinchar en el boton Propiedades. En
el cuadro de dialogo que se muestra entonces hay que especicar \obtener una direccion
IP de un servidor DHCP". Habra que eliminar entonces el resto de parametros de la
conguracion del protocolo, puesto que el cliente los adquirira del servidor.
11.4 El Administrador DHCP de NT
El administrador DHCP es la herramienta administrativa que permite congurar el servicio
DHCP en NT. Este servicio solo puede ser instalado en Windows NT Server.
El servicio DHCP en Windows NT permite examinar cada uno de los casi 70 parametros
relacionados con TCP/IP denidos en el protocolo, pero en realidad solo se pueden especicar (y proporcionar a los clientes) los siguientes ocho parametros:
1) Direccion IP.
2) Mascara de subred.
3) Puerta de enlace.
4) Servidor(es) DNS.
5) Nombre (sujo) del dominio DNS.
6) Tipo de nodo WINS/NBT (ver Captulo 10).
7) Servidor WINS (ver Captulo 10).
8) Tiempo de concesion (lease time), tiempo de renovacion (renewal time), y tiempo
de reconexion (rebinding time). Estos tiempos especican cuando un cliente debe
solicitar la renovacion de su concesion al servidor DHCP. Los dos ultimos tiempos
se calculan en funcion del primero.
La mayora de las opciones de DHCP anteriores pueden establecerse a nivel global, o
bien para un ambito en particular, o incluso para un equipo concreto. Es posible tambien
asignar una direccion IP ja a cada equipo, asociando dicha direccion a una direccion
fsica ethernet (asignada por el fabricante de la tarjeta, y que es por denicion distinta
para cada una).
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
83
11.5 La Utilidad ipconfig
11.5 La Utilidad ipconfig
Existe un mandato en Windows NT que permite observar la conguracion IP de un equipo:
ipconfig. Esta orden se ejecuta normalmente con la opcion /all, que permite ver todas
las caractersticas de la conguracion. La Figura 11.1 muestra un ejemplo de la ejecucion
de esta utilidad.
Figura 11.1: Ejemplo de la utilidad ipconfig.
En el caso de un cliente DHCP, mediante ipconfig tambien se puede solicitar manualmente la renovacion de la concesion, y la liberacion de la direccion actual (lo que provoca
una difusion para solicitar una nueva direccion IP). Para ello se utilizan las opciones
/renew y /release, respectivamente.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
Anexo I: Documentacion de DNS
Captulo 2
Cuestiones sobre redes TCP/IP
Vamos a entrar en los detalles que deben tenerse en cuenta cuando se conecta una maquina
Linux a una red TCP/IP. De este modo, hablaremos de direcciones IP, nombres y cuestiones
sobre el encaminamiento. Este captulo le ense~nara la base con la que podra entender los
pasos para su conguracion particular, pasos que son cubiertos exhaustivamente en otros
captulos.
2.1 Interfaces de Red
Para ocultar la diversidad de hardware que puede usarse en una red, TCP/IP dene una
interfaz a traves de la que accedemos al hardware. Esta interfaz ofrece un conjunto de operaciones identicas en cualquier tipo de hardware y que basicamente consisten en operaciones
para enviar y recibir paquetes.
Para cada dispositivo que quiera utilizarse para conectarse a la red, se mantendra en el
nucleo del sistema la correspondiente interfaz. Por ejemplo, las interfaces con Ethernet en
Linux son eth0 y eth1, mientras que las interfaces SLIP se llaman sl0, sl1, etcetera. Estos
nombres de interfaz se deben conocer durante la conguracion de la red, cuando queramos
referirnos a un dispositivo hardware concreto.
Para que podamos usarlo en una red TCP/IP, la interfaz debera tener asignada una
direccion IP que sirva como identicacion de esta ante los demas ordenadores de la red. Esta
direccion es diferente del nombre de interfaz considerado anteriormente; puede realizarse
la siguiente analoga: la interfaz sera la \puerta" de su sistema, mientras que la direccion
vendra a ser un numero enmarcado y colgado de la \puerta".
Por supuesto, hay otros parametros congurables para cada dispositivo, como el numero
maximo de datagramas que pueden ser procesados por el dispositivo, conocido como Unidad
19
2.2. Direcciones IP
20
de Transferencia Maxima o MTU1 . Otros parametros seran introducidos mas tarde.
2.2 Direcciones IP
Como se dijo en el captulo anterior, las direcciones utilizadas en el protocolo de red IP la
forman numeros de 32 bits, cada maquina debe tener una direccion propia. Si las maquinas
se encuentran en una red TCP/IP que no se conecta a otras redes, dichas direcciones podran
asignarse a las maquinas librememente. Sin embargo, si las maquinas se conectan a Internet,
las direcciones de los ordenadores seran asignadas por una autoridad principal, el NIC o
Centro de Informacion de la Red2 .
Para facilitar la lectura, las direcciones IP se dividen en cuatro numeros de 8 bits llamados octetos. Por ejemplo, si la maquina quark.physics.groucho.edu tiene una direccion IP 0x954C0C04, normalmente la escribiremos con la notacion de puntos divisorios,
que separa cada octeto, de esta forma: 149.76.12.4.
Otra razon para usar esta notacion es que las direcciones IP se pueden dividir en el
numero de red y el numero de nodo. Cuando pedimos al NIC un conjunto de direcciones,
este organismo nos concedera, no una direccion para nuestra maquina, sino un rango de
direcciones validas, que en realidad es un numero de red concreto (el numero de nodo lo
pondremos nosotros, contando con todos esos nodos disponibles).
Dependiendo del tama~no de la red, la parte de la direccion correspondiente al nodo puede
ser mas o menos grande. Para adaptarse a diferentes necesidades, se conceden diferentes
clases de redes, que denen diferentes maneras de dividir la direccion IP en parte de red y
parte del nodo.
Clase A
La clase A comprende redes desde 1.0.0.0 hasta 127.0.0.0. El numero de
red esta en el primer octeto, con lo que solo hay 127 redes de este tipo,
pero cada una tiene 24 bits disponibles para identicar a los nodos, lo que
se corresponde con poder distinguir en la red unos 1.6 millones de nodos
distintos.
Clase B
La clase B comprende redes desde 128.0.0.0 hasta 191.255.0.0; siendo el
numero de red de 16 bits (los dos primeros octetos. Esto permite 16320
redes de 65024 nodos cada una.
Clase C
Las redes de clase C tienen el rango de direcciones desde 192.0.0.0 hasta
MTU son las siglas de \Maximum Transfer Unix"
Frecuentemente, las direcciones IP le seran asignadas directamente por el proveedor que le conecte a
la red. No obstante, se puede contactar directamente con el NIC para obtener direcciones, escribiendo a
[email protected].
1
2
2.3. Resolucion de direcciones
21
223.255.255.0, contando con tres octetos para identicar la red. Por lo
tanto, hay cerca de 2 millones de redes de este tipo con un maximo de 254
nodos cada una.
Clases D, E, y F
Comprenden las direcciones entre 224.0.0.0 y 254.0.0.0, y estan reservadas
para uso futuro, o con nes experimentales. No especican, pues, ninguna
red de Internet.
Volviendo al ejemplo del captulo anterior, veremos que en la direccion 149.76.12.4 de
la maquina quark, 12.4 es el identicativo del nodo dentro de la red de clase B 149.76.0.0.
Se puede observar que en la lista anterior no se consideraban todas las posibilidades en
la parte que identica al nodo, concretamente, se excluan siempre el identicador 0 y el
255. Estos dos identicadores se reservan con proposito especial. Una direccion con los
bits del nodo a cero identica a la red, mientras que si tiene todos los bits a uno, identica
a todos los nodos de la red (lo que se conoce como direccion de broadcast, lo que indica
que un mensaje enviado a esa direccion sera interpretado por todos los nodos de la red).
As pues, en nuestro ejemplo la direccion de la red sera 149.76.0.0 y la de broadcast, la
149.76.255.255.
Ademas, otras dos direcciones de red estan reservadas: la 0.0.0.0 y la 127.0.0.0. La
primera se conoce como direccion de encaminamiento por defecto, y la segunda, como direccion de loopback. El encaminamiento por defecto se utiliza para saber a donde enviar los
datagramas por defecto, tema que abordaremos despues.
La red 127.0.0.0 se reserva para el traco local, dirigido al propio nodo. Normalmente,
se asigna la direccion 127.0.0.1 a un dispositivo de la maquina llamado interfaz de loopback
o de circuito cerrado. Cualquier paquete enviado a esa direccion sera recibido por el propio
nodo, esto permite probar aplicaciones de red con uno mismo, sin estar conectado a una red
\real". Otra aplicacion util es la de ejecutar aplicaciones de red que afectan solo al nodo
local, por ejemplo, muchos sistemas UUCP no tienen conexion IP pero ejecutan un sistema
de noticias INN. Para que esto funcione, INN utiliza la interfaz de loopback.
2.3 Resolucion de direcciones
Ahora que conocemos que son las direcciones IP, nos preguntamos como se utilizan en
una red Ethernet. Despues de todo, en una red de este tipo, el protocolo Ethernet usa
direcciones identicativas de seis octetos que no tienen que ver con los numeros IP.
En efecto, se necesita un mecanismo de traduccion de direcciones IP a direcciones Et-
2.4. Encaminamiento IP
22
hernet o fsicas. Esto se hace con el Protocolo de Resolucion de Direcciones o ARP3 . De
hecho, ARP no se limita a las redes Ethernet, sino que se extiende a otros tipos de redes
como las de radio paquetes. La idea es la misma que tendramos para localizar al se~nor X
entre 150 personas: preguntar por su nombre a todo el mundo; y el se~nor X nos respondera.
Cuando queremos localizar la direccion fsica correspondiente a una direccion IP, haremos uso de una caracterstica de la red Ethernet que es la posibilidad de enviar mensajes
a escuchar por todos los nodos, o mensajes broadcast. En el mensaje ARP, que es de este
tipo, se incluye la direccion IP cuyo propietario estamos buscando. El nodo que posea esa
direccion enviara una respuesta ARP al nodo llamante, con la direccion fsica suya.
Por supuesto, le preocupara saber como puede funcionar esto para localizar un nodo
entre millones de Ethernets conectadas en el mundo. Esto se trata en la proxima seccion:
se trata del encaminamiento.
Sigamos hablando, de momento, sobre ARP. Una vez que se conoce la direccion fsica
del nodo, el que hizo la peticion guardara la informacion obtenida en una cache ARP, para
as no preguntar por lo mismo cada vez que enve un paquete a ese nodo. Sin embargo, no
podemos guardar esa direccion para siempre ya que puede perder su validez (por ejemplo,
si cambiamos la tarjeta de red a los nodos por avera, sus nuevas direcciones fsicas seran
distintas). Por ello, cada cierto tiempo, lo que hay en la cache ARP pierde su validez,
obligando a realizar de nuevo la pregunta ARP.
A veces, un nodo necesita tambien conocer su direccion IP a partir de su direccion
fsica. Por ejemplo, en terminales X o PCs sin disco, que cuando arrancan solo saben
la direccion de su tarjeta pues esta grabada en memoria no volatil. Para ello, se usa el
protocolo de Resolucion Inversa de Direcciones o RARP4 : la peticion RARP la hace el nodo
cuando arranca, mediante mensaje broadcast, y es contestado por un servidor de direcciones
que, a partir de la direccion fsica, consulta su base de datos y conoce la direccion IP
correspondiente. Existe ademas otro protocolo, el BOOTP o protocolo de arranque, que
permite a las maquinas sin disco conocer como ponerse en marcha en la red.
2.4 Encaminamiento IP
2.4.1 Redes IP
3 Cuando escribimos una carta a alguien, normalmente incluimos la direccion completa en el
sobre: pas, provincia, codigo postal, etc. De este modo el servicio de correos podra llevar
la carta a su destino: un servicio la enviara al del pas que corresponda, y este ultimo la
3
4
Address Resolution Protocol
Reverse Address Resolution Protocol
23
entregara al de la provincia o ciudad de destino. La ventaja de este esquema jerarquico es
que el servicio postal del remitente apenas tiene que saber acerca del destino nal, sino solo
a que pas entregarla.
Las redes IP se organizan de manera similar. Internet consta de varias redes, conocidas
como sistemas autonomos y cada una realiza por su cuenta el encaminamiento interno
entre sus nodos miembro. Cuando un paquete tiene como destino un nodo de otra red, se
entregara al encaminador correspondiente, sin preocuparse del destino nal del paquete.
2.4.2 Subredes
La estructura de subredes se obtiene al dividir las direcciones IP en parte del nodo y parte
de la red, como ya hemos explicado. Por defecto, la red de destino se deriva de la parte de
red de la direccion IP. Es decir, los nodos con la misma direccion de red se encontraran en
la misma red TCP/IP5 .
Pero en una red puede interesar hacer una division en cientos de peque~nas redes, por
ejemplo segmentos de Ethernet. Para ello se subdivide la red en subredes.
Una subred tiene la responsabilidad de la entrega de los datagramas a un determinado
rango de direcciones IP de la red en la que se encuentra. Como sucede con las clases A,
B o C, se identica en la parte del numero IP correspondiente a la red. Sin embargo, esa
parte incluira ahora algunos bits de la parte del nodo. Los bits que se interpretan como
direccion de subred se obtienen con la llamada mascara de red. Es un numero de 32 bits
que especica una mascara para identicar los bits de la subred.
Parte de la Red
Parte del Nodo
149
76
12
4
149
76
12
4
Parte de la Red
Parte del Nodo
Figura 2.1: Division de una red clase B en subredes
La red del campus de la Universidad de Groucho Marx es un ejemplo de red de clase B,
poseedora de la red 149.76.0.0, con mascara 255.255.0.0.
Internamente, la red de la UGM se divide en peque~nas subredes, como las LAN de cada
5
Los sistemas autonomos son algo mas generales. Pueden tener mas de una red IP.
24
departamento. Concretamente se divide en 254 subredes, desde la 149.76.1.0 hasta la
149.76.254.0. Por ejemplo, el Departamento de Fsica Teorica tendra asignada la subred
149.76.12.0. La dorsal del campus es en s mismo una subred, la 149.76.1.0. Las subredes
comparten el msmo numero de red, pero se usa el tercer octeto de esta para distinguir las
distintas subredes. Por lo tanto, tendran una mascara de subred igual a 255.255.255.0.
En la gura 2.1 se muestra como el nodo quark (149.76.12.4) se ve de distinta forma
segun se vea desde el punto de vista de la red de clase B, o desde el punto de vista de las
subredes.
Debe notarse que la division en subredes es visible solo internamente a la red. Normalmente, las organiza el administrador de red para reejar diferentes ubicaciones geogracas,
distinguir segmentos de red, o bien por motivos administrativos (departamentos, redes de
alumnos, etc). Pero esta division es totalmente invisible desde fuera de la organizacion.
2.4.3 Pasarelas
La organizcion en subredes no solo se hace por motivos administrativos, tambien es consecuencia de cuestiones del hardware. Lo que ve un nodo en una red es limitado: solo ve los
nodos con los que directamente este conectado (por ejemplo, en la Ethernet), mientras que
a los demas los accede a traves de lo que se conoce como pasarela o gateway. Una pasarela
es un nodo conectado a dos o mas redes fsicas, congurado para pasar paquetes de una red
a otra.
Para reconocer si una direccion IP se encuentra en la red local fsica, cada LAN debe
tener una direccion de red IP diferente. Por ejemplo, las maquinas de la (sub)red 149.76.4.0
seran las que estan en la LAN del Departamento de Matematicas. Cuando se enva un
datagrama a la maquina quark, el software de red de erdos ve que su direccion de red
es otra (149.76.12.4) con lo que sabe que tiene que enviar los datagramas a traves de la
pasarela (sophus por defecto).
sophus se encuentra conectado a dos subredes: la del Departamento de Matematicas
y la de la dorsal del campus, accediendo a cada una a traves de una interfaz diferente,
respectivamente eth0 y fddi0. Nos preguntaremos entonces, que direccion IP debe tener la
pasarela, una de la subred de Matematicas o bien una de la dorsal.
Pues bien, la respuesta es ambas. Cuando la pasarela comunique con un nodo de la
LAN de Matematicas, usara la direccion 149.76.4.1, mientras que si lo hace con un nodo
de la dorsal, usara 149.76.1.4.
Es decir, la pasarela tiene tantas direcciones IP como conexiones a redes fsicas tenga.
En denitiva, este sera el esquema de interfaces, direcciones y mascara de sophus, nuestra
pasarela:
25
interfaz
direccion
mascara
eth0
149.76.4.1 255.255.255.0
fddi0
149.76.1.4 255.255.255.0
lo
127.0.0.1
255.0.0.0
La ultima entrada describe el dispositivo loopback, que se comento anteriormente.
En la gura 2.2 se muestra una parte de la topologa de la red de la Universidad de
Groucho Marx (UGM). Los nodos que estan en dos subredes tendran dos direcciones IP.
Departamento de Matematicas
4.23
gauss
Departamento de Fsica Teorica
4.17
4.0
12.4
12.0
erdos
4.1
sophus
1.4
Dorsal del Campus
quark
12.1
1.12
1.1
niels
gcc1
2.1
1.0
Centro de Calculo de la UGM
Figura 2.2: Vista parcial de la topologa de la red de la UGM.
2.4.4 Tablas de Encaminamiento
Vamos ahora a centrarnos en como se selecciona una pasarela para entregar un datagrama
a una red remota.
Hemos visto que erdos, cuando enva un datagrama para quark, comprueba que la
direccion destino no se encuentra en la red local, por lo que lo enva a la pasarela, sophus,
26
quien basicamente hace lo mismo: ve que quark no esta en una de las redes a las que
se conecta directamente y busca otra pasarela a quien entregarle el paquete. La eleccion
correcta es niels, la pasarela del Departamento de Fsicas. sophus necesita informacion
para poder tomar estas decisiones.
La informacion de encaminamiento que se usa en IP es basicamente una tabla donde se
relacionan (sub)redes y pasarelas. Ademas, debe incluirse una entrada de encaminamiento
por defecto, que se asocia en la tabla a la red 0.0.0.0. Todos los paquetes que van a una
red desconocida, se enviaran a la pasarela del encaminamiento por defecto. As pues, esta
sera la tabla para sophus:
Red
Pasarela
149.76.1.0 -
Interfaz
...
...
fddi0
149.76.2.0 149.76.1.2 fddi0
149.76.3.0 149.76.1.3 fddi0
149.76.4.0 eth0
149.76.5.0 149.76.1.5 fddi0
0.0.0.0
...
149.76.1.2 fddi0
Las rutas a una red a la que sophus este directamente conectado no necesitan pasarela,
sino que los datagramas se entregan directamente. Esto se indica en la tabla anterior cuando
en lugar de la pasarela aparece un \-".
Las tablas de encaminamiento pueden construirse de varias formas. Para redes peque~nas, sera mas eciente construirlas a mano usando el comando route del Linux (vease el
captulo 5). Para redes mas grandes, las tablas se mantienen y modican automaticamente
mediante los demonios de encaminamiento. E stos corren en nodos centrales e intercambian
informacion de encaminamiento entre ellos para tener en todo momento las rutas \optimas"
entre subredes.
Dependiendo del tama~no de la red, se utilizan distintos protocolos de encaminamiento. Dentro de los sistemas autonomos (como la Universidad Groucho Marx) se utilizan
los protocolos internos o IGP6 . El mas utilizado es RIP7 o protocolo de informacion de
encaminamiento, que implementa el demonio routed de BSD. Para encaminamiento entre
redes se usan protocolos EGP8 , como BGP. Se implementan en programas como gated de
la Universidad de Cornell.9.
Internal Gateway Protocol
Routing Information Protocol
8
External Gateway Protocol
9
gated tambien implementa RIP y en general se recomienda usarlo en lugar de routed
6
7
2.5. Protocolo de Mensajes de Control de Internet (ICMP)
27
2.4.5 Metricas de Encaminamiento
El encaminamiento dinamico basado en RIP elige la mejor ruta a un determinado nodo
o red a partir del numero de \saltos", es decir, las pasarelas que tiene que atravesar el
datagrama hasta llegar a su destino. La ruta mas corta sera la elegida, y si hay 16 o mas
saltos se descartara por exceso de distancia.
Para usar RIP tiene que ejecutar gated en todas las maquinas. Al arrancar, gated
comprueba cuantas interfaces estan activas. Si hay mas de una (sin contar la de loopback)
asumira que el nodo es una pasarela. Si no, entrara en modo pasivo, dedicandose a recibir
cualquier actualizacion RIP y cambiando sus tablas en consecuencia.
Para enviar a las demas pasarelas la informacion de su tabla local de rutas, gated cuenta
la longitud de cada una a partir de una metrica especca (que es decidida por el administrador del sistema y debe reejar el coste de esa ruta). As, la metrica de una ruta a
una subred con conexion directa sera siempre cero, mientras que una ruta que atraviese dos
pasarelas debera tener un coste de dos.
2.5 Protocolo de Mensajes de Control de Internet (ICMP)
IP tiene otro protocolo aun no mencionado. Es el protocolo de mensajes de control de
Internet o ICMP10 , y lo usa el software de gestion de red para comunicar mensajes de error
entre nodos. Por ejemplo, si estamos en la maquina erdos y hacemos un telnet al puerto
12345 del nodo quark y no hay procesos escuchando en ese puerto, recibira un mensaje
ICMP de \puerto inalcanzable".
Hay mas mensajes ICMP, muchos de ellos referidos a condiciones de error. Sin embargo,
hay uno interesante que es el de redireccion. Lo genera el modulo de encaminamiento al
detectar que otro nodo esta usandolo como pasarela, a pesar de existir una ruta mucho
mas corta. Por ejemplo, tras congurarse la tabla de encaminamiento de sophus, esta
puede estar incompleta, conteniendo rutas a traves del encaminador por defecto gcc1. Por
lo tanto, los paquetes enviados inicialmente a quark iran por gcc1 en lugar de niels.
En este caso gcc1 noticara a sophus que esta usando una ruta costosa y reenviara el
datagrama a niels, al mismo tiempo que devolvera un mensaje ICMP de redireccion a
sophus informandole de la nueva ruta.
Con lo visto, queda claro que se puede evitar tener que establecer las rutas a mano.
Sin embargo, usar solo esquemas de encaminamiento dinamico no es siempre una buena
idea. La redireccion de ICMP y el protocolo RIP no incluyen mecanismos de vericacion
de la autenticidad de los mensajes. Esto permite a los piratas corromper el traco de la
10
Internet Control Message Protocol
2.6. El sistema de nombres DNS
28
red mediante mensajes ICMP. Por ello, algunas versiones del codigo de Linux tratan los
mensajes de redireccion que afectan a rutas de red como si fueran redirecciones de rutas a
nodos.
2.6 El sistema de nombres DNS
2.6.1 Resolucion de nombres
3 Como se comento antes, el direccionamiento en TCP/IP se basa en numeros de 32 bits.
Evidentemente, esos numeros no son faciles de recordar, mientras que s lo es el nombre que
se le asigna a cada maquina, como gauss o strange. Existe una aplicacion que es capaz
de traducir nombres a direcciones IP, es conocida como sistema de resolucion de nombres
o DNS11 .
Una aplicacion que desee encontrar la direccion IP correspondiente a una maquina de
la que conoce su nombre, no tiene que incluir rutinas para ello, ya que en las libreras
estandares (libc ) existen ya rutinas preparadas, como gethostbyname(3) o gethostbyaddr(3).
En otros sistemas se encuentran en otras libreras distintas de la libc pero esto no sucede
en Linux. Al conjunto de rutinas que hacen estas tareas se les conoce como \sistema de
resolucion".
En una red peque~na no es difcil mantener una tabla /etc/hosts en cada maquina, y
modicarla al agregar, eliminar o modicar nodos. Aunque resulta complicado cuando hay
muchas maquinas ya que, en principio, cada una necesita una copia de /etc/hosts.
Una solucion a esto es compartir esta y otras bases de datos con el NIS, o sistema
de informacion de red 12 , desarrollado por Sun Microsystems y conocido tambien como
paginas amarillas. En este caso, las bases de datos como la de /etc/hosts se mantienen en
un servidor NIS central y los clientes accederan a ellas de forma transparente al usuario. En
todo caso, esta solucion solo es aconsejable para redes peque~nas o medianas, ya que implican
mantener un chero central /etc/hosts que puede crecer mucho, y luego distribuirlo entre
los servidores NIS.
En Internet, se comenzo almacenando la informacion en un chero similar al hosts,
mantenido por el NIC, y obtenido regularmente por los demas servidores. Cuando la red
crecio comenzaron los problemas de sobrecarga de servidores, ademas de que el NIC tena
que ocuparse de todos los nombres de los nodos de internet, y evitar la duplicidad de los
mismos.
11
12
Domain Name System
Network Information System
29
Por esto, en 1984 se dise~no y adopto ocialmente un nuevo sistema, el DNS o sistema
de nombres por dominios, dise~nado por Paul Mockapetris.
2.6.2 Introduccion al DNS
DNS organiza los nombres de los nodos en una jerarqua de dominios. Un dominio es una
coleccion de nodos relacionados de alguna manera, como estar en la misma red o pertenecer a
una misma organizacion o pas. Por ejemplo, las universidades norteamericanas se agrupan
en el dominio edu, y cada universidad mantiene un subdominio dentro de edu. Nuestro
ejemplo, la Universidad de Groucho Marx, mantendra el dominio gmu.edu y las maquinas
del departamento de Matematicas se encontraran dentro del dominio maths.gmu.edu.
De modo que el nombre completo de la maquina erdos sera erdos.maths.gmu.edu. El
nombre completo se conoce como nombre totalmente cualicado o FQDN13 , e identica a
ese nodo en todo el mundo.
.
com
edu
net
groucho
maths
gauss
erdos
physics
sophus
quark
theory
otto
collider
niels
up
down
strange
Figura 2.3: Parte del espacio de dominios
En la gura 2.3 se muestra una seccion del espacio de dominios. La entrada de la raz
del arbol, que se indica con un punto, se puede denominar dominio raz, y agrupa al resto
de los dominios. Para indicar que un nodo se expresa en notacion FQDN, se puede terminar
el nombre en un punto, indicando as que el nombre incluye al del dominio raz.
Dependiendo de su localizacion en la jerarqua, un dominio puede ser de primer, segundo
o tercer nivel. Pueden existir otros niveles pero no son frecuentes. Por ejemplo, algunos
dominios de primer nivel muy usuales son los siguientes:
13
Fully Qualied Domain Name
30
edu
Aqu se incluyen casi todas las universidades o centros de investigacion norteamericanos.
com
org
Compa~nas u organizaciones con nes comerciales.
net
mil
gov
uucp
Pasarelas y otros nodos administrativos de la red.
Organizaciones no comerciales. Las redes UUCP privadas se encuentran
aqu.
Nodos militares norteamericanos.
Nodos del gobierno norteamericano.
Ocialmente, todos los nombres de nodos UUCP sin dominio han sido movidos a este nuevo dominio .uucp.
En general, los dominios anteriores pertenecen a redes norteamericanas. Algo especialmente cierto con los dominios mil o gov.
Fuera de los Estados Unidos, existe un dominio de primer nivel para cada pas, de dos
letras segun se dene en la norma ISO-3166. Finlandia, por ejemplo, usa el dominio ;
el dominio de corresponde a Alemania y el dominio es corresponde a Espa~na. Cada pas
organiza por debajo del primer nivel, los dominios de segundo nivel, de manera parecida a los
americanos en algunos casos (por ejemplo, con dominios com.au o edu.au) o directamente
por organizaciones, como sucede en Espa~na (con dominios como upm.es para la Universidad
de Politecnica de Madrid).
Por supuesto, un nodo dentro del dominio de un pas puede no estar fsicamente en el.
El dominio unicamente identica al nodo como registrado en el NIC de ese pas. As, un
comerciante sueco puede tener una delegacion en Australia, y tener sus nodos australianos
registrados dentro del dominio de primer nivel sueco, se.
Esta organizacion por dominios soluciona el problema de la unicidad de nombres.
Ademas, los nombres totalmente cualicados no son difciles de recordar.
Pero DNS tiene otras ventajas: permite delegar la autoridad sobre un determinado
subdominio a sus administradores. Por ejemplo, los subdominios maths y physics de la
UGM son creados y mantenidos por el Centro de Calculo de dicha universidad. Y si el
mantenimiento del subdominio maths.gmu.edu fuese complicado (por numero elevado de
nodos, existencia de subdominios internos, etc), el Centro de Calculo de la UGM puede
delegar la autoridad sobre ese subdominio al departamento de Matematicas. La delegacion
de un subdominio implica el control total del mismo por parte de la organizacion en la
que se delego, con total libertad para crear nuevos subdominios internos, asociar nombres
31
a nodos, etc.
Para este n, el espacio de nombres se divide en zonas, cada una asociada a un dominio. Notese que existe una diferencia entre zona y dominio: el dominio groucho.edu
incluye todos los nodos de la UGM, mientras que la zona groucho.edu incluye solo los
nodos que mantiene directamente el Centro de Calculo, ya que los nodos del subdominio
physics.groucho.edu pertenecen a la zona controlada por el Departamento de Fsicas. En
la gura 2.3 se marca el inicio de una zona con un peque~no crculo a la derecha del nombre
del dominio.
2.6.3 Busquedas de nombres con DNS
Trataremos aqu el problema de como resolver el nombre de un determinado nodo.
DNS es una gigantesca base de datos distribuda. Se implementa a traves de los llamados
servidores de nombres. Cada uno de estos mantiene la informacion de uno o varios dominios.
Para cada zona hay al menos dos (o mas) servidores de nombres que mantienen informacion
autorizada sobre los nodos de esa zona. Para obtener la direccion IP del nodo erdos, lo
que hay que hacer es contactar con el servidor de nombres de la zona para groucho.edu y
este nos devolvera los datos pedidos.
Esto parece facil de decir pero difcil de implementar pues nos preguntaremos como
localizar al servidor de nombres de la UGM. Si su ordenador no implementa un adivino, le ayudara el DNS. Cuando su aplicacion desea encontrar informacion acerca de erdos, contactara en primer lugar con un servidor de nombres local, quien realizara una
busqueda por otros servidores. Empieza por preguntar a un servidor de nombres raz por
erdos.maths.groucho.edu. Al comprobar este ultimo que el no mantiene ese dominio,
contactara con los servidores del dominio edu y les preguntara las direcciones de los servidores de nombres, que retornara al servidor local. Ahora nuestro servidor preguntara a estos
ultimos y estos a su vez iran haciendo llegar a nuestro servidor hasta los que mantienen la
zona groucho.edu. Finalmente, se preguntara a uno de estos ultimos por el nodo erdos y
se enviara la respuesta al usuario.
Aparentemente esto provoca mucho traco, aunque en todo caso siempre sera menor que
preguntar siempre a los mismos servidores que mantenan el chero HOSTS.TXT antes de
que se dise~nara el DNS.
Sin embargo, aun se puede mejorar algo mas. La informacion obtenida en una busqueda
puede que se necesite despues. Por ello, el servidor de nombres local la guardara en una
cache local. As, cuando volvamos a preguntar por un nodo de groucho.edu, el servidor
local ya podra dirigirse directamente el servidor de nombres de esa zona sin pasar por los
servidores raz.
32
Por supuesto, el servidor de nombres no puede mantener la cache eternamente, sino
descartarla cada cierto tiempo. Este tiempo de expiracion se conoce como TTL14 o tiempo
de vida. En la base de datos del DNS queda especicado este parametro.
2.6.4 Servidores de Nombres
Cuando un servidor de nombres mantiene toda la informacion acerca de una zona se le
llama autorizado para esa zona. Cualquier peticion para esa zona sera enviada a uno de
esos servidores maestros.
Para tener una representacion coherente de la zona, sus servidores maestros deben estar
sincronizados. Para ello, a uno de ellos se le nombra servidor primario, que obtiene la
informacion de zona a partir de unos cheros locales, y a los demas se les nombra servidores
secundarios. Estos ultimos cargan la informacion de la zona pidiendosela al primario cada
cierto tiempo.
Las razones para que existan varios servidores autorizados por cada zona son dos: repartir la carga de trabajo y lograr tolerancia a fallos. As, si un servidor cae, todas las
peticiones se repartiran entre los demas servidores autorizados que haya. Por supuesto,
esto no protege contra fallos internos o bugs del propio software DNS.
Por supuesto, tambien es posible tener servidores de nombres que no mantengan informacion autorizada de ningun dominio15. Este tipo de servidores es util pues, al mantener
una cache con los nombres que resuelven disminuye la carga de la red y de otros servidores.
2.6.5 La Base de Datos DNS
En las bases de datos del DNS se mantiene mas informacion que la necesaria para traducir
nombres a direcciones IP. Dicho de otra forma, en DNS se mantienen distintos tipos de
registros.
Un elemento simple de informacion en el DNS se conoce como registro de recurso o RR.
Cada registro tiene un tipo asociado a el, describiendo que clase de datos contiene, y una
clase indicando el tipo de red al que se aplica. Se trata de acomodarse a diferentes esquemas
de red, aunque para direcciones IP se usa siempre la clase IN (INternet), pero hay otras
como las redes Hesiod (que se usan en el MIT16 ). El registro mas habitual es el de tipo A,
que relaciona un nombre totalmente cualicado con una direccion IP.
15
Time To Live
Aunque al menos debera tener informacion autorizada para el localhost y la resolucion inversa de
16
Instituto Tecnologico de Massachusets
14
127.0.0.1
33
Un nodo puede admitir mas de un nombre. Pero solo uno de ellos sera \ocial" o
canonico, mientras que los demas son alias del primero. La diferencia es que el canonico se
dene en un registro de tipo A, mientras que los alias se denen en registros CNAME que
apuntan al nombre canonico.
En un captulo posterior se trata todo esto en profundidad. Aqu nos vamos a limitar
a ver algunos ejemplos. En la gura 2.4 se muestra una parte de la base de datos para la
zona physics.groucho.edu.
;
; Informacion Autorizada de physics.groucho.edu
@
IN
SOA
(
niels.physics.groucho.edu.
hostmaster.niels.physics.groucho.edu.
1034
; serial no
360000
; refresh
3600
; retry
3600000
; expire
3600
; default ttl )
;
; Servidores de nombres autorizados
IN
NS
niels
IN
NS
gauss.maths.groucho.edu.
gauss.maths.groucho.edu. IN A
149.76.4.23
;
; Fisica Teorica (subred 12)
niels
IN
IN
A
A
149.76.12.1
149.76.1.12
nameserver
IN
CNAME
niels
otto
IN
A
149.76.12.2
quark
IN
A
149.76.12.4
down
IN
A
149.76.12.5
strange
IN
A
149.76.12.6
...
; Laboratorio Collider (subred 14)
boson
IN
A
149.76.14.1
muon
IN
A
149.76.14.7
bogon
IN
A
149.76.14.12
...
Figura 2.4: Extracto del chero named.hosts del departamento de Fsicas.
Ademas de los registros A y CNAME, se puede ver que hay un registro especial al
principio del chero, con varias lneas. Se trata del registro SOA o de inicio de autoridad,
que mantiene informacion general sobre el servidor de nombres. Por ejemplo, el tiempo de
34
vida por defecto de todos los registros que mantiene.
Notese que aquellos nombres que no nalicen en un punto seran interpretados como relativos al dominio en cuestion. El nombre especial \@" usado en el registro SOA representa
al dominio completo.
Hemos visto que los servidores para el dominio groucho.edu deben tener conocimiento
sobre los servidores de la zona physics para poder reenviarles las peticiones para esta. Esto
se suele incluir en los registros NS que incluyen el nombre de los servidores en notacion
FQDN, y un registro A que da la direccion IP para ese servidor. Vease, por ejemplo, la
gura 2.5.
;
; Datos de zona para groucho.edu.
@
IN
SOA
(
vax12.gcc.groucho.edu.
hostmaster.vax12.gcc.groucho.edu.
233
; serial no
360000
; refresh
3600
; retry
3600000
; expire
3600
; default ttl )
....
;
; Registros de la zona.
physics
IN
IN
NS
NS
niels.physics
IN
A
149.76.12.1
gauss.maths
IN
A
149.76.4.23
...
Figura 2.5: Extracto del chero named.hosts de la UGM.
2.6.6 Resolucion inversa
Ademas de la obtencion de una direccion IP a partir del nombre, a veces interesa lo contrario:
conocida la direccion, obtener el nombre canonico. Esto se conoce como traduccion inversa
y la utilizan algunas aplicaciones de red para vericar la identidad del llamante. Cuando
se usa un chero hosts, la resolucion inversa supone una simple busqueda en el mismo.
En cambio, para el DNS se ha creado un dominio especial, el in-addr.arpa, que contiene
direcciones de los nodos en notacion de puntos divisorios invertida. Por ejemplo, a la
direccion IP 149.76.12.4 le corresponde el nombre 4.12.76.149.in-addr.arpa. El tipo de
35
registro para estos datos se llama PTR.
Cuando se crea una zona de autoridad suele signicar que sus administradores tienen
control total sobre como asignan sus nombres. Pero a una subred se le puede delegar un
subdominio.
Esto sucede con la UGM, donde se delega la zona de Fsicas (subdominio physics) al
correspondiente Departamento. Las direcciones de resolucion inversa tambien se delegan.
En la gura 2.6 se muestra el contenido del chero de zona para el servidor de la subred
12. Los registros \importantes" de delegacion se muestran en la gura 2.7.
;
; Dominio 12.76.149.in-addr.arpa
@
IN
SOA
(
hostmaster.niels.physics.groucho.edu.
233 360000 3600 3600000 3600 )
2
IN
PTR
otto.physics.groucho.edu.
4
IN
PTR
quark.physics.groucho.edu.
5
IN
PTR
down.physics.groucho.edu.
6
IN
PTR
strange.physics.groucho.edu.
Figura 2.6: Extracto del chero named.rev de la subred 12.
Una importante consecuencia de esto es que las zonas solo pueden crearse como superconjuntos de redes IP, y ademas, las mascaras de red deberan redondearse a nivel de octeto.
Es decir, las subredes de la UGM tendran una mascara 255.255.255.0, y para cada subred
debera existir una zona in-addr.arpa. Sin embargo, si la mascara fuese 255.255.255.128,
la creacion de zonas para la subred 149.76.12.128 sera imposible ya que no hay forma
de decir en DNS que el dominio 12.76.149.in-addr.arpa ha sido dividido en dos zonas de
autoridad, con nombres de nodos desde el 1 al 127, y desde el 128 al 255, respectivamente.
36
;
; Dominio 76.149.in-addr.arpa domain
@
IN
SOA
(
vax12.gcc.groucho.edu.
hostmaster.vax12.gcc.groucho.edu.
233 360000 3600 3600000 3600 )
...
; subred 4: Departamento de Matematicas
1.4
IN
PTR
sophus.maths.groucho.edu.
17.4
IN
PTR
erdos.maths.groucho.edu.
23.4
IN
PTR
...
; subred 12: Departamento de fisicas, zona separada
12
IN
IN
NS
NS
niels.physics.groucho.edu. IN
gauss.maths.groucho.edu. IN
A 149.76.12.1
A
149.76.4.23
...
Figura 2.7: Extracto del chero named.rev de la red 149.76.
Legal Notice
UNIX is a trademark of Univel.
Linux is not a trademark, and has no connection to UNIXTM or Univel.
c 1994 Olaf Kirch
Copyright Kattreinstr. 38, 64295 Darmstadt, Germany
[email protected]
\The Linux Network Administrators' Guide" may be reproduced and distributed in whole
or in part, subject to the following conditions:
0. The copyright notice above and this permission notice must be preserved complete
on all complete or partial copies.
1. Any translation or derivative work of \The Linux Network Administrators' Guide"
must be approved by the author in writing before distribution.
2. If you distribute \The Linux Network Administrators' Guide" in part, instructions
for obtaining the complete version of \The Linux Network Administrators' Guide"
must be included, and a means for obtaining a complete version provided.
3. Small portions may be reproduced as illustrations for reviews or quotes in other
works without this permission notice if proper citation is given.
4. If you print and distribute \The Linux Network Administrators' Guide", you may
not refer to it as the \Ocial Printed Version".
5. The GNU General Public License referenced below may be reproduced under the
conditions given within it.
6. Several sections of this document are held under separate copyright. When these
sections are covered by a dierent copyright, the seperate copyright is noted. If
you distribute \The Linux Network Administrators' Guide" in part, and
that part is, in whole, covered under a seperate, noted copyright, the
conditions of that copyright apply.
Exceptions to these rules may be granted for academic purposes: Write to Olaf Kirch at
the above address, or email [email protected], and ask. These restrictions are here to
protect us as authors, not to restrict you as educators and learners.
All source code in \The Linux Network Administrators' Guide" is placed under the GNU
General Public License. See appendix C for a copy of the GNU \GPL."
The author is not liable for any damages, direct or indirect, resulting from the use of
information provided in this document.
Anexo II: Actividades de Laboratorio
DE SISTEMAS
ADMINISTRACION
ACTIVIDAD
Instalaci
on De Red Hat Linux
Requerimientos iniciales
Necesitamos inicialmente:
Servidor Unix, con sistema de cheros en red (NFS). Im
agenes de la instalacion de Red Hat
Linux y parches disponibles.
Disco de instalacion de Red Hat Linux.
Alumnos: dos disquetes en blanco formateados para MS-DOS por ordenador para crear dos
discos de arranque.
Activaci
on del disco extra
ble
1. Apague el ordenador.
2. Inserte el disco extrable y fjelo con la llave.
3. Inicie el ordenador con el sistema Linux del disco interno.
4. Acredtese con su usuario y contrase~na.
5. Ejecute el mandato activa-hdc turno, siendo turno el correspondiente a su sesion. NO SE
EQUIVOQUE. Ejecute este mandato sin argumentos para que muestre los turnos disponibles.
6. Recuerde que debe realizar esta activacion al principio de cada sesion de practicas.
Instalaci
on de RedHat Linux
1. Reiniciar el ordenador con el disco BOOTNET de RedHat.
2. El tipo de inicio (boot:) es text.
3. Seleccionar el idioma de la instalacion (al gusto).
4. Seleccionar el teclado es.
5. El metodo de instalacion es va NFS.
6. Congurar TCP/IP.
(a)
(b)
(c)
(d)
(e)
Direccion IP estatica.
Asignar la direccion IP correspondiente al ordenador (158.42.54.[60+no ordenador]).
Mascara: 255.255.128.0
Gateway: 158.42.1.10
Servidor de nombres (DNS): 158.42.49.82
1
2
Actividad: Instalacion De Red Hat Linux
7. Seleccion del servidor donde reside redhat.
(a) Nombre o Direccion IP: adserver.dsic.upv.es
(b) Directorio: /home/ftp/pub/redhat62
8. Tipo de instalacion: "Sistema personalizado".
9. Particiones y Sistema de Archivos.
(a) Utilizar DiskDruid.
(b) Editar la parcicion /dev/hdc1 indicando que su punto de montaje es '/boot'.
(c) Editar la parcicion /dev/hdc3 indicando que su punto de montaje es '/'.
10. Formatear particiones.
(a) Seleccionar hdc1 y hdc3.
(b) Vericar bloques (SI).
11. LILO.
(a) No necesita parametros adicionales. Activar la opcion lineal.
(b) Instalacion en el primer sector de la particion de arranque (/dev/hdc1).
(c) Asignar etiqueta solo a la particion hdc3(linux).
12. Nombre del ordenador: pc04XX.dsic.upv.es.
13. Conguracion del raton.
Generic mouse PS/2 de dos botones y seleccionar simular tres botones.
14. Zona horaria.
(a) Reloj no asignado a GMT.
(b) Europa / Madrid.
15. Contrase~na.
Seleccionar como contrase~na el nombre del ordenador: ejemplo pc0411.
16. A~nadir nuevos usuarios: ninguno.
17. Autenticacion.
Las opciones por defecto son correctas.
18. Seleccion de componentes. Solo:
X Window System, GNOME, KDE, Mail/WWW/News Tools, DOS/Windows Connectivity,
Networked Workstation, Emacs.
19. Tarjeta de vdeo.
Deteccion correcta de la tarjeta de vdeo (OK)
20. Esperar a que nalice la instalacion de paquetes.
21. Crear el disco de arranque.
Etiquete el disco con "Arranque RedHat 'kernel' Ordenador XX ".
22. Conguracion de X.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
3
Actividad: Instalaci
on De Red Hat Linux
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
Monitor CTX CPS-1760.
No probar la tarjeta de vdeo.
Memoria de vdeo, 8Mb.
No "clockchip setting".
Omitir la prueba de relojes.
Modo sugerido: 1024 x 768 con 24 bits.
Probar la conguracion iniciando el servidor X.
Aceptar la prueba (antes de 10 segundos).
Activar las X desde el inicio del sistema.
23. Cuando aparezca la ventana de nalizacion, OK.
24. Esperar a que el sistema se reinicie.
25. Entrar como root, vericar funcionamiento.
Creaci
on del disquete de arranque basado en LILO.
1. Introducir un disquete formateado (puede utilizar el disquete de arranque creado durante la
instalacion u otro disquete para mayor seguridad).
2. Editar el chero /etc/lilo.conf.
3. Modicar en la primera lnea hdc1 por fd0.
4. Ejecutar lilo
5. Etiquete el disco con "Arranque RedHat 'Lilo' Ordenador XX ".
6. Rearrancar la ordenador con el nuevo disco y probar que funciona.
Desactivaci
on del disco extra
ble
.
3. Ejecute el mandato desactiva-hdc.
4. Recuerde que debe realizar esta desactivacion al nal de cada sesion de practicas.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
DE SISTEMAS
ADMINISTRACION
ACTIVIDAD
Instalaci
on De Windows NT Workstation 4.0
ADVERTENCIA: La instalacion de NT Workstation se realiza en los ordenadores 2,4,6,8,10,13,15,17,19.
Servidor NT. Imagenes de la instalaci
on de NT Wks y Server.
En cada ordenador hace falta una partici
on disponible con tipo Old Minix de al menos 500Mb
en el disco primario.
1 disquete por ordenador a instalar, de arranque MS-DOS con soporte de red (+drivers). Ademas
debe tener: format, fdisk y xcopy.
1 disquete con formato MS-DOS para la generacion del disco de arranque.
Activaci
on del disco extra
ble
Antes de instalar
1. Arrancar con el sistema Linux del disco extrable.
2. Salvar el MBR:
dd if=/dev/hda of=/tmp/mbr bs=512 count=1
3. Cambiar los tipos de las particiones del DISCO FIJO (/dev/hda)
(a)
(b)
(c)
(d)
Iniciar fdisk: fdisk
Visualizar el estado actual de las particiones: p
Cambiar el tipo de la particion hda1 a "Old Minix": t 1 80
Cambiar el tipo de la particion hda2 a "FAT16": t 2 6
1
2
Actividad: Instalacion De Windows NT Workstation 4.0
(e) Activar la particion hda2: a 2
(f) Si es necesario, desactivar la particion hda1: a 1
(g) Visualizar el estado actual de las particiones y vericar que todo es correcto. La particion
hda2 debe ser ahora la activa y del tipo "FAT16". La particion had1 debe ser ahora del
tipo "Old Minix"y no tener la etiqueta de activa: p
(h) Guardar los cambios: w
Instalaci
on de MS-DOS
1. Reiniciar el ordenador y arrancar con el disco de instalacion de MS-DOS seleccionando la opcion
"SIN soporte para red"
2. Ejecutar FDISK para vericar el estado de las particiones de ambos discos. Deben haber dos
particiones, C: en el disco interno y D: en el extrable.
3. Formatear la particion C:
FORMAT C: /U /S
4. Eliminar LILO del MBR.
FDISK /MBR
5. Copiar el contenido del disquete en C:
XCOPY A:\*.* C:\ /S
** no sobreescribir COMMAND.COM
Instalaci
on de Windows NT
1. Rearrancar el ordenador desde el disco duro. En este caso debe elegirse la opcion "CON soporte
para red".
2. Usuario de red NT, contrase~na nt.
3. Conexion con el servidor donde residen los cheros necesarios para la instalacion.
NET USE Z: \\ADSERVER\SOFT
4. Con el n de acelerar el proceso de copia de archivos, debe activarse el subsistema MS-DOS
de cache de disco, el cual, por razones de espacio, no ha podido ser incluido en el disquete de
arranque.
C:
CD \
COPY z:\SMARTDRV.EXE C:\
SMARTDRV
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
3
5. Los manejadores de la tarjeta de red en la version original de NT no son adecuados. Por tanto, es
necesario disponer de los manejadores de dispositivo correctos durante el proceso de instalacion.
XCOPY Z:\3COM C:\3COM /s
** destino directorio
6. Iniciar la instalacion (Recuerda, est
as instalando NT Workstation)
Z:
CD NTWKS
WINNT /B
7. Descarga de archivos
(a) El directorio donde reside la distribucion de NT es el indicado
(b) Comienza la transferencia de cheros. Este proceso dura varios minutos.
(c) Terminada la descarga, el ordenador solicita reiniciar. Enter.
8. En la deteccion de adaptadores SCSI no hay ninguno.
9. Los componentes hardware detectados son correctos.
10. Seleccion de la particion donde se instalara NT: D:
11. La particion debe tener formato NTFS.
12. El directorio sugerido para NT es correcto.
13. Realice el reconocimiento exhaustivo del disco.
14. El ordenador rearrancara un par de veces.
15. Se inicia la parte de la instalacion basada en NT (modo graco).
(a)
(b)
(c)
(d)
(e)
(f)
Instalacion tpica.
Identicar nombre y organizacion (al gusto).
Identicar ordenador (pc04XX XX es el no del ordenador).
Contrase~na del administrador. El nombre del ordenador (Ej. pc0411).
NO crear disco de emergencia.
Componentes de Windows recomendados.
16. Instalacion de Red.
(a)
(b)
(c)
(d)
(e)
(f)
(g)
Seleccionar conectado a la red mediante adaptador de red de area local.
NO buscar adaptador.
Seleccionar de la lista, utilizar disco, indicar la ruta C:n3COM.
Solo protocolo TCP/IP
Resto de opciones por defecto.
No se utilizara DHCP.
En la cha de Direccion IP indicar la direccion IP del (158.42.54.[60+no ordenador] ), la
mascara de red (255.255.128.0) y el gateway 158.42.1.10
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
4
Actividad: Instalacion De Windows NT Workstation 4.0
(h) En la cha DNS, indicar: dominio dsic.upv.es, servidor de nombres 158.42.48.150
(i) En la cha Direccion Wins, indicar: Servidor principal de WINS: nada, servidor secundario
de WINS: nada
17. El ordenador formara parte de un WORKGROUP. Debe elegir un nombre de grupo de trabajo
igual al nombre de dominio elegido en el NT Server. Denomine este grupo de trabajo como
ADMON (el nombre de grupo elegido).
18. Para nalizar la instalacion.
(a) Zona horaria.
(b) Adaptador de vdeo. NT no detecta el tipo de adaptador, por lo que asume compatible
VGA.
19. El ordenador debe reiniciarse de nuevo.
Creaci
on del disquete de arranque
1. Formatear un disquete con Windows NT.
2. Copiar en dicho disquete los siguientes cheros, que se encuentran en el directorio C: (pueden
estar ocultos).
NTDETECT.COM
NTLDR
BOOT.INI
3. Etiquete el disco con "Arranque NT Workstation. Ordenador XX ".
4. Reinice el ordenador con este disquete y compruebe que se arranca el sistema Windows NT
instalado.
Recuperaci
on del MBR
2. Ejecutar
dd if=/tmp/mbr of=/dev/hda bs=512 count=1
Actividades adicionales
1. Instalar Service Pack 6. (disponible en nnadservernsoft)
2. Instalar el adaptador de video correcto. (disponible en el directorio nvidia de nnadservernsoft).
El modelo del adaptador es Nvidia Riva 128.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
5
Desactivaci
on del disco extra
ble
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
DE SISTEMAS
ADMINISTRACION
ACTIVIDAD
Instalaci
on De Windows NT Server 4.0
ADVERTENCIA: La instalacion de NT Server se realiza en los ordenadores 1,3,5,7,9,14,16,18,20.
Servidor NT. Imagenes de la instalaci
on de NT Wks y Server.
En cada ordenador hace falta una partici
on disponible con tipo Old Minix de al menos 500Mb
en el disco primario.
1 disquete por ordenador a instalar, de arranque MS-DOS con soporte de red (+drivers). Ademas
debe tener: format, fdisk y xcopy.
1 disquete con formato MS-DOS para la generacion del disco de arranque.
Activaci
on del disco extra
ble
Antes de instalar
2. Salvar el MBR:
dd if=/dev/hda of=/tmp/mbr bs=512 count=1
3. Cambiar los tipos de las particiones del DISCO FIJO (/dev/hda)
(a)
(b)
(c)
(d)
Iniciar fdisk: fdisk /dev/hda
Visualizar el estado actual de las particiones: p
Cambiar el tipo de la particion hda1 a "Old Minix": t 1 80
Cambiar el tipo de la particion hda2 a "FAT16": t 2 6
1
2
(e) Activar la particion hda2: a 2
(f) Si es necesario, desactivar la particion hda1: a 1
(g) Visualizar el estado actual de las particiones y vericar que todo es correcto. La particion
hda2 debe ser ahora la activa y del tipo "FAT16". La particion had1 debe ser ahora del
tipo "Old Minix"y no tener la etiqueta de activa: p
(h) Guardar los cambios: w
Instalaci
on de MS-DOS
1. Reiniciar el ordenador y arrancar con el disco de instalacion de MS-DOS seleccionando la opcion
"SIN soporte para red"
2. Ejecutar FDISK para vericar el estado de las particiones de ambos discos. Deben haber dos
particiones, C: en el disco interno y D: en el extrable.
3. Formatear la particion C:
FORMAT C: /U /S
4. Eliminar LILO del MBR.
FDISK /MBR
5. Copiar el contenido del disquete en C:
XCOPY A:\*.* C:\ /S
** no sobreescribir COMMAND.COM
Instalaci
on de Windows NT
1. Rearrancar el ordenador desde el disco duro. En este caso debe elegirse la opcion "CON soporte
para red".
2. Usuario de red NT, contrase~na nt.
3. Conexion con el servidor donde residen los cheros necesarios para la instalacion.
NET USE Z: \\ADSERVER\SOFT
4. Con el n de acelerar el proceso de copia de archivos, debe activarse el subsistema MS-DOS
de cache de disco, el cual, por razones de espacio, no ha podido ser incluido en el disquete de
arranque.
C:
CD \
COPY z:\SMARTDRV.EXE C:\
SMARTDRV
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
3
5. Los manejadores de la tarjeta de red en la version original de NT no son adecuados. Por tanto, es
necesario disponer de los manejadores de dispositivo correctos durante el proceso de instalacion.
XCOPY Z:\3COM C:\3COM /s
** destino directorio
6. Iniciar la instalacion (Recuerda, est
as instalando NT Server)
Z:
CD NTSERVER
WINNT /B
7. Descarga de archivos
(a) El directorio donde reside la distribucion de NT es el indicado
(b) Comienza la transferencia de cheros. Este proceso dura varios minutos.
(c) Terminada la descarga, el ordenador solicita reiniciar. Enter.
8. En la deteccion de adaptadores SCSI no hay ninguno.
9. Los componentes hardware detectados son correctos.
10. Seleccion de la particion donde se instalara NT: D:
11. La particion debe tener formato NTFS.
12. El directorio sugerido para NT es correcto.
13. Realice el reconocimiento exhaustivo del disco.
14. El ordenador rearrancara un par de veces.
15. Se inicia la parte de la instalacion basada en NT (modo graco).
(a)
(b)
(c)
(d)
(e)
(f)
(g)
Identicar nombre y organizacion (al gusto).
Licencias por puesto.
Identicar ordenador (pc04XX XX es el no del ordenador).
El ordenador sera un controlador principal de dominio.
Contrase~na del administrador. El nombre del ordenador (Ej. pc0411).
NO crear disco de emergencia.
Componentes de Windows recomendados.
16. Instalacion de Red.
(a)
(b)
(c)
(d)
(e)
(f)
(g)
Seleccionar conectado a la red mediante adaptador de red de area local.
No instale Internet Infomation System.
NO buscar adaptador.
Seleccionar de la lista, utilizar disco, indicar la ruta C:n3COM.
Solo protocolo TCP/IP
Resto de opciones por defecto.
No se utilizara DHCP.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
4
(h) En la cha de Direccion IP indicar la direccion IP del (158.42.54.[60+no ordenador] ), la
mascara de red (255.255.128.0) y el gateway 158.42.1.10
(i) En la cha DNS, indicar: dominio dsic.upv.es, servidor de nombres 158.42.48.150
(j) En la cha Direccion Wins, indicar: Servidor principal de WINS: nada, servidor secundario
de WINS: nada
17. Cuando se solicite el nombre del dominio, escoja el nombre del grupo de trabajo elegido para
la instalacion del sistema NT Workstation del otro ordenador. Denomine este dominio como
ADMON (el nombre de grupo elegido).
18. Para nalizar la instalacion.
(a) Zona horaria.
(b) Adaptador de vdeo. NT no detecta el tipo de adaptador, por lo que asume compatible
VGA.
19. El ordenador debe reiniciarse de nuevo.
Creaci
on del disquete de arranque
1. Formatear un disquete con Windows NT.
2. Copiar en dicho disquete los siguientes cheros, que se encuentran en el directorio C: (pueden
estar ocultos).
NTDETECT.COM
NTLDR
BOOT.INI
3. Etiquete el disco con "Arranque NT Server. Ordenador XX ".
4. Reinice el ordenador con este disquete y compruebe que se arranca el sistema Windows NT
instalado.
Recuperaci
on del MBR
2. Ejecutar
dd if=/tmp/mbr of=/dev/hda bs=512 count=1
Actividades adicionales
1. Instalar Service Pack 6. (disponible en nnadservernsoft)
2. Instalar el adaptador de video correcto. (disponible en el directorio nvidia de nnadservernsoft).
El modelo del adaptador es Nvidia Riva 128.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
5
Desactivaci
on del disco extra
ble
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
DE SISTEMAS
ADMINISTRACION
ACTIVIDAD
Usuarios y Proteccion en RedHat Linux
Introducci
on
El objeto de la practica consiste en adquirir habilidades relacionadas con la gestion de usuarios, con la
gestion de proteccion y con la gestion de sistemas de archivos en el sistema operativo RedHat Linux.
En particular, se abordaran los siguientes conceptos:
Usuarios y grupos primarios
Grupos suplementarios
Reglas de proteccion
Utilizacion de los bits SETUID y SETGID en ejecutables
Utilizacion del bit SETGID en directorios
Utilizacion de grupos privados
Reglas de Seguridad de la Organizaci
on
Una organizacion esta utilizando un sistema Linux como soporte informatico. Esta organizacion ha
dise~nado un plan de seguridad que cubre los siguientes aspectos:
a) Sobre las contrase~
nas.
A n de facilitar las pruebas sobre las actividades de laboratorio,
asgnese a cada cuenta la contrase~na hardy.
b) Sobre el directorio de cada usuario.
Se tiene que cumplir lo siguiente:
Todo usuario del sistema debe poseer un subdirectorio del directorio /lacasa cuyo nombre
debe coincidir con el de la cuenta del usuario.
En este directorio, el usuario debe poder crear y borrar cheros y directorios, pero no debe
poder modicar los permisos de su directorio de conexion.
Ning
un otro usuario del sistema debe poder acceder a dicho directorio y a su contenido.
c) Sobre los proyectos.
La organizacion tiene varios proyectos en curso de realizacion. Sobre
dichos proyectos, se tiene que cumplir lo siguiente:
Cada proyecto debe tener un directorio bajo el directorio /proyectos donde almacenar su
documentacion asociada.
Todos los usuarios que participan en un proyecto deben tener la posibilidad de leer, modicar, crear y borrar los archivos que forman parte del proyecto.
Cuando un usuario cree un archivo en el directorio del proyecto, por defecto, este debe
poder ser ledo, modicado o borrado por cualquier otro usuario del mismo proyecto.
Ning
un otro usuario debe poder acceder a estos directorios.
1
Actividad: Usuarios y Protecci
on en RedHat Linux
2
d) Sobre los ejecutivos.
En la empresa existen varios ejecutivos que tienen asignada la evaluacion
de algunos de los proyectos existentes. Sobre ellos, se tienen que cumplir:
Los ejecutivos no deben poder acceder directamente a los directorios de los proyectos.
Para que los ejecutivos puedan controlar el estado de cada proyecto, deben existir en el
directorio /usr/local/bin tantos programas como proyectos existan. Una copia de dichos
programas puede obtenerse en el directorio remoto /home/ftp/pub/varios del ordenador
adserver. Internamente, estos programas ejecutan el mandato ls -lR sobre el directorio
del proyecto correspondiente.
El programa que permite evaluar cada proyecto debera cumplir los siguientes dos requisitos:
Debe poder ser ejecutado unicamente por los ejecutivos asociados a dicho proyecto.
{ Para que pueda ser ejecutado satisfactoriamente, este programa debe tener los permisos
sucientes para poder ejecutar el mandato ls -lR sobre su directorio.
{
e) Sobre el resto de usuarios.
En la organizacion pueden existir otros usuarios no vinculados
a ningun proyecto, los cuales no deben tener ningun derecho de acceso a los directorios de los
proyectos.
Situaci
on Actual de la Organizaci
on
Actualmente, en la organizacion se tiene la siguiente situacion de usuarios y proyectos:
Existen tres proyectos, denominados proy1, proy2 y proy3.
Hay dos ejecutivos, cuyas cuentas se denominan ejec1 y ejec2.
Adicionalmente, existen dos usuarios, ajeno1 y ajeno2, que no est
an vinculados a ningun proyec-
to.
Los usuarios que participan en proyectos estan organizados seg
un se muestra en la tabla siguiente:
Usuario
usu1
usu2
usu3
usu4
usu5
Proyecto
proy1
proy2
p
p
p
p
p
p
p
p
proy3
usu6
p
p
La asociaci
on de ejecutivos a proyectos es la siguiente:
Ejecutivo
Proyecto
proy1
ejec1
ejec2
c Agust
n Espinosa, Andr
es Terrasa, 2001
p
p
proy2
p
proy3
p
Administraci
DE SISTEMAS
ADMINISTRACION
ACTIVIDAD
Usuarios y Protecci
on en Windows NT
Introducci
on
El objeto de la practica consiste en adquirir habilidades relacionadas con la gestion de usuarios y
con la gestion de proteccion en el sistema operativo Windows NT. En particular, se abordaran los
siguientes conceptos:
Usuarios y grupos locales
Grupos predenidos
Derechos de usuario
Plan de cuentas
Control de acceso a archivos y directorios
Reglas de proteccion
on
Una organizacion esta utilizando un sistema Windows NT como soporte informatico. Esta organizacion ha dise~nado un plan de seguridad que cubre los siguientes aspectos:
a) Sobre el sistema.
Cualquier usuario debe poder apagar el sistema.
b) Sobre las contrase~
nas.
siguientes normas:
Las contrase~nas de los usuarios del sistema tienen que cumplir las
Los usuarios deben cambiar su contrase~
na cada dos meses.
Los usuarios pueden cambiar su contrase~
na tras dos semanas del cambio anterior.
No se permiten contrase~
nas en blanco.
Una nueva contrase~
na debe ser siempre distinta de la anterior.
Si se detectan tres acreditaciones fallidas en un intervalo de cinco minutos a una cuenta
de usuario, esta debe quedar permanentemente bloqueada. Estos intentos fallidos deben
quedar registrados en la auditora del sistema.
A n de facilitar las pruebas sobre las actividades de laboratorio, asgnese a cada cuenta la
contrase~na master.
c) Sobre el directorio de cada usuario.
conexion, que debe cumplir lo siguiente:
Cada usuario debe poseer un directorio propio de
Todo usuario del sistema debe poseer un subdirectorio del directorio \lacasa cuyo nombre
En este directorio, el usuario debe tener control total sobre el mismo.
1
on en Windows NT
2
Ning
un otro usuario del sistema debe poder acceder a dicho directorio y a su contenido.
d) Sobre los proyectos.
ellos, se tiene que:
La organizacion tiene varios proyectos en curso de realizacion. Sobre
Cada proyecto debe tener un directorio bajo el directorio \proyectos donde almacenar su
Todos los usuarios que participan en un proyecto deben tener la posibilidad de leer y
modicar los archivos que forman parte del proyecto.
En cambio, no podr
an crear ni borrar archivos del proyecto. Esta funcion debera realizarla
el director del proyecto.
e) Sobre los directores de proyecto.
Cada proyecto posee uno o varios directores responsables
del mismo. Dichos directores tendran control total sobre los archivos del proyecto que dirigen.
Esto incluye poder modicar permisos y tomar posesion de cualquier archivo del proyecto.
f ) Sobre los ejecutivos.
En la organizacion existen una serie de ejecutivos, los cuales deben
poder acceder a cualquiera de los directorios donde se guarda informacion sobre los proyectos
en curso y poder leer dicha informacion. No obstante, no podran alterarla de ninguna forma.
g) Sobre el resto de usuarios.
En la organizacion pueden existir otros usuarios no vinculados
proyectos.
h) Sobre el administrador.
El administrador del sistema debe congurar los permisos iniciales
de cada proyecto de forma que:
Las restricciones anteriores se establezcan de forma automatica cada vez que se cree nueva
informacion asociada a un proyecto.
Las reglas de proteccion sean las mnimas necesarias para que se cumpla con todo lo ex-
puesto.
Situaci
on
Existen diez usuarios trabajando en los distintos proyectos. Dichos usuarios se denominan usu1,
usu2, . . . , usu10.
Hay tres ejecutivos en la organizacion, cuyas cuentas se denominan ejec1, ejec2 y ejec3.
Los usuarios ajeno1 y ajeno2 no estan vinculados a ning
un proyecto.
La siguiente tabla muestra la asignaci
on de usuarios a proyectos:
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
on en Windows NT
Usuario
usu1
proy1
Director Participante
p
usu2
usu3
usu4
usu5
usu6
p
usu7
usu8
usu9
usu10
Administraci
p
p
p
p
3
proy2
p
p
p
proy3
p
p
p
p
p
p
p
p
p
p
p
p
p
c Agust
n Espinosa, Andr
es Terrasa, 2001
DE SISTEMAS
ADMINISTRACION
ACTIVIDAD
Introducci
on
El objeto de la practica consiste en adquirir habilidades relacionadas con la gestion de usuarios y
con la gestion de proteccion en los dominios Windows NT. En particular, se abordaran los siguientes
conceptos:
Controladores principales de dominios
Incorporaci
on de estaciones a dominios
Usuarios y grupos globales
Relaciones de conanza
Comparticion de recursos
on
Una organizacion esta utilizando sistemas Windows NT como soporte informatico. Esta organizacion
esta formada por varios departamentos, cada uno de los cuales esta organizado como un dominio NT.
Para ello, cada departamento dispone de un servidor NT que actua como controlador principal
del dominio y de una estacion NT que actua como miembro de dicho dominio. Esta organizacion
ha dise~nado un plan de seguridad que cubre los siguientes aspectos.
Sobre los Sistemas
En cada departamento, los sistemas deben cumplir lo siguiente:
a) Estacion. Cualquier usuario local o del dominio al que pertenece la estacion debe poder:
Apagar el equipo.
Iniciar una sesi
on local.
Iniciar una sesi
on remota.
b) Servidor. Cualquier administrador del dominio debe poder:
Apagar el equipo.
Iniciar una sesi
on local.
Por otra parte, cualquier usuario global del dominio y usuarios globales de otros dominios (cuando esto sea necesario) deben poder iniciar una sesi
on remota.
Sobre las Contrase~nas
A n de facilitar las pruebas sobre las actividades de laboratorio, las cuentas no deben tener contrase~nas, a excepcion de la del administrador.
1
2
Actividad: Dominios en Windows NT
Sobre el Directorio de Cada Usuario
Todo usuario del dominio debe poseer un recurso de red en el controlador principal del dominio
cuyo nombre debe coincidir con el de su cuenta del usuario. Dicho recurso de red/directorio debe
cumplir las siguientes reglas:
El recurso de red debe ser asignado de forma autom
atica a la unidad logica Z: cuando el usuario
se conecta al servidor o a la estacion.
En dicho directorio, el usuario debe tener control total sobre el mismo.
Ning
un otro usuario del sistema debe poder acceder a dicho directorio ni a su contenido.
Sobre los Proyectos
Cada departamento tiene tres proyectos en curso de realizacion denominados proy1, proy2 y proy3.
Sobre los mismos, se tienen que cumplir las siguientes reglas:
Los proyectos proy1 y proy3 residen en subdirectorios del recurso de red denominado proyectos
que exporta el servidor del departamento.
En estos subdirectorios se almacena la documentacion asociada a cada proyecto. Los participantes de dichos proyectos pueden ser usuarios globales del dominio del departamento o de otros
dominios.
El proyecto proy2 reside en un subdirectorio del directorio nproyectos de la estaci
on del
departamento. Sus participantes pueden ser usuarios globales del dominio del departamento y
usuarios locales de la estacion.
Todos los usuarios que participan en un proyecto deben tener la posibilidad de leer y modicar
los archivos que forman parte del proyecto.
En cambio, no podr
an crear ni borrar archivos del proyecto. Esta funcion debera realizarla el
director del proyecto.
NOTA: La asignacion de permisos a proyectos se realizara exclusivamente en base a grupos locales.
Sobre los Directores de Proyecto
Cada proyecto posee uno o varios directores que son los responsables del mismo. La organizacion
establece que:
Los directores de un proyecto tendran control total sobre los archivos del proyecto que dirigen.
Esto incluye poder modicar permisos y tomar posesion de cualquier archivo del proyecto.
Uno de los directores del proyecto deber
a ser el propietario del directorio de cada proyecto. Dicho director esta etiquetado con el smbolo \*" en la tabla de asignacion de usuarios a proyectos,
al nal del documento.
Sobre los Ejecutivos
Los ejecutivos del departamento deben poder acceder y leer el contenido de cualquiera de los directorios
donde se guarda informacion sobre los proyectos en curso, bien sean proyectos que residen en el servidor
o en la estacion. No obstante, no podran alterar el contenido de los proyectos.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
3
Sobre los Administradores
La organizacion establece que los administradores de cada departamento deben poder administrar
el PDC de otro departamento. En concreto, el servidor de cada departamento debe poder ser
administrado por los administradores del departamento/dominio \D" (vease la Figura 1 al nal de
este documento).
Sin embargo, dichos administradores no podran administrar la estaci
on del departamento.
Sobre el Resto de Usuarios
En el departamento pueden existir otros usuarios no vinculados a ningun proyecto, los cuales no deben
tener ningun derecho de acceso a los directorios de los proyectos.
Situacion Actual de la Organizacion
Hay tres ejecutivos en el departamento. Sus cuentas son globales y se denominan ejec1, ejec2
y ejec3.
Los usuarios ajeno1 y ajeno2 son usuarios globales del dominio y no estan vinculados a ning
un
proyecto.
Los usuarios local1 y local2 solo existen en la estaci
on del departamento.
A continuacion se muestra una tabla que recoge la distribucion de usuarios a proyectos.
Usuario
usu1
proy1
p
p
usu2
usu3
usu4
p
p
*
local1
p
proy2
p
proy3
p
p
*
p
p
p
p
p
p
p
p
p
p
p
local2
Dnusu1
Dnusu2
*
En la tabla anterior, los usuarios usu1 a usu4 son usuarios globales del dominio del departamento.
Los usuarios Dnusu1 y Dnusu2 son usuarios globales del departamento/dominio \D". La Figura 1 al
nal del documento muestra, para cada dominio, cual es su dominio \D" segun la distribucion del
laboratorio.
NOTA IMPORTANTE: Se recomienda organizar en primer
lugar el proyecto proy1, luego el proy2 y por u
ltimo el proy3.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
4
la puerta
Figura 1: Las echas se~nalan cual es el dominio \D" para cada dominio en el laboratorio.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
DE SISTEMAS
ADMINISTRACION
ACTIVIDAD
Dominios en RedHat Linux
on
Una organizacion esta utilizando un sistema Linux como soporte informatico. Esta organizacion ha
dise~nado un plan de seguridad que cubre los siguientes aspectos:
a) Sobre los sistemas.
** Uno de los ordenadores de la organizaci
on debe actuar como servidor NIS y servidor
NFS (En nuestro laboratorio, los ordenadores 2, 4, 6, 8, 10, 13, 15, 17 y 19)
** Todas las cuentas de usuarios y grupos deben ser gestionadas desde este servidor.
b) Sobre las contrase~
nas. A n de facilitar las pruebas sobre las actividades de laboratorio,
asgnese a cada cuenta la contrase~na hardy.
c) Sobre el directorio de cada usuario. Se tiene que cumplir lo siguiente:
Todo usuario del sistema debe poseer un subdirectorio del directorio /lacasa cuyo nombre
** Este directorio debe residir fsicamente en el ordenador que actue como servidor NFS.
** Este directorio debe ser accesible desde cualquier ordenador de la organizacion utilizando
el mismo nombre de ruta ( /lacasa/usu1, por ejemplo).
** Solo los dos ordenadores de la organizacion podran acceder a este directorio.
En este directorio, el usuario debe poder crear y borrar cheros y directorios, pero no debe
poder modicar los permisos de su directorio de conexion.
Ningun otro usuario del sistema debe poder acceder a dicho directorio y a su contenido.
d) Sobre los proyectos. La organizacion tiene varios proyectos en curso de realizacion. Sobre
dichos proyectos, se tiene que cumplir lo siguiente:
Cada proyecto debe tener un directorio bajo el directorio /proyectos donde almacenar su
** Este directorio debe residir fsicamente en el ordenador que actue como servidor NFS.
** Este directorio debe ser accesible desde cualquier ordenador de la organizacion utilizando
el mismo nombre de ruta ( /proyectos).
** Solo los dos ordenadores de la organizacion podran acceder a este directorio.
Todos los usuarios que participan en un proyecto deben tener la posibilidad de leer, modicar, crear y borrar los archivos que forman parte del proyecto.
Cuando un usuario cree un archivo en el directorio del proyecto, por defecto, este debe
poder ser ledo, modicado o borrado por cualquier otro usuario del mismo proyecto.
Ningun otro usuario debe poder acceder a estos directorios.
e) Sobre los ejecutivos. En la empresa existen varios ejecutivos que tienen asignada la evaluacion
de algunos de los proyectos existentes. Sobre ellos, se tienen que cumplir:
1
2
Actividad: Dominios en RedHat Linux
Los ejecutivos no deben poder acceder directamente a los directorios de los proyectos.
Para que los ejecutivos puedan controlar el estado de cada proyecto, deben existir en el
directorio /usr/local/bin tantos programas como proyectos existan. Una copia de dichos
programas puede obtenerse en el directorio remoto /home/ftp/pub/varios del ordenador
adserver. Internamente, estos programas ejecutan el mandato ls -lR sobre el directorio
del proyecto correspondiente.
** Deben existir copias de estos programas en los dos ordenadores de la organizaci
on.
El programa que permite evaluar cada proyecto debera cumplir los siguientes dos requisitos:
{ Debe poder ser ejecutado unicamente por los ejecutivos asociados a dicho proyecto.
{ Para que pueda ser ejecutado satisfactoriamente, este programa debe tener los permisos
sucientes para poder ejecutar el mandato ls -lR sobre su directorio.
{ ** Debe funcionar satisfactoriamente en cualquiera de los dos ordenadores de la organizacion.
f) Sobre el resto de usuarios. En la organizacion pueden existir otros usuarios no vinculados
proyectos.
g) Directorio p
ublico. ** El servidor NFS de la organizacion debe ofrecer un directorio denominado /pub a cualquier ordenador o usuario que desee utilizarlo. Este directorio sera de solo
lectura y todos los accesos deberan ser considerados como anonimos.
Situaci
on
Hay dos ejecutivos, cuyas cuentas se denominan ejec1 y ejec2.
Adicionalmente, existen dos usuarios, ajeno1 y ajeno2, que no est
an vinculados a ningun proyec-
to.
Los usuarios que participan en proyectos estan organizados seg
un se muestra en la tabla siguiente:
Usuario
usu1
usu2
usu3
usu4
usu5
Proyecto
proy1
proy2
p
p
p
p
p
p
p
p
proy3
usu6
p
p
La asociaci
on de ejecutivos a proyectos es la siguiente:
Ejecutivo
Proyecto
proy1
ejec1
ejec2
c Agust
n Espinosa, Andr
es Terrasa, 2001
p
p
proy2
p
proy3
p
Administraci
DE SISTEMAS
ADMINISTRACION
ACTIVIDAD
Samba
Introducci
on
El objeto de esta practica consiste en adquirir habilidades relacionadas con la gestion del producto
denominado Samba, el cual permite que una maquina Unix implemente el protocolo SMB, haciendo
as posible que maquinas basadas en sistemas operativos de Microsoft utilicen a traves de la red
directorios de la maquina Unix.
Supuesto practico
Una organizacion esta utilizando sistemas Windows NT 4.0 y sistemas Unix (RedHat Linux) como
soporte informatico. En este momento, las maquinas Windows NT forman un dominio, as como
tambien las maquinas Linux. No obstante, no existe ningun tipo de interoperatividad entre ambos
tipos de sistemas, por lo que deciden utilizar Samba para conseguir una mayor integracion entre sus
sistemas. Los objetivos que persiguen son los siguientes:
a)
Unicacion de usuarios.
b)
En ambos tipos de sistemas, deben existir los mismos usuarios.
c)
No es necesario que las contrase~nas coincidan en ambos sistemas.
d)
Cuando un usuario se conecte en un sistema NT, debe recibir de forma automatica las siguientes
conexiones de red predeterminadas:
Z:
L:
P:
Q:
H:
e)
directorio del usuario en el sistema NT.
directorio del usuario en el servidor Linux.
directorio donde residen los subdirectorios de los proyectos en el servidor Linux.
directorio donde residen los subdirectorios de los proyectos en el sistema NT Server.
recurso soft de adserver.
Las siguientes conexiones deben poder realizarse de forma manual sobre el servidor Linux desde
los sistemas NT:
Recurso pub, accesible por cualquier usuario, aunque no se encuentre registrado, de solo
lectura.
Recurso almacen, accesible por cualquier usuario, aunque no se encuentre registrado, de
lectura-escritura. Todos los archivos y directorios que se creen dentro de este recurso
deberan pertenecer al mismo usuario y al mismo grupo, con independencia del usuario que
los creo.
f)
Sobre las restricciones de acceso
El acceso a los recursos de red con conexi
on automatica debe estar restringido a los orde-
nadores del grupo.
El acceso a los recursos de red adicionales debe estar permitido para cualquier ordenador.
1
DE SISTEMAS
ADMINISTRACION
ACTIVIDAD
Encaminamiento y DNS
Introduccion
Una organizacion desea disponer de varias redes de area local, una por cada departamento. Para
conseguir la interconexion de dichas redes, se dispone de otra red de area local, denominada troncal.
La red propia de cada departamento dispondra de un ordenador que realizara las funciones de encaminador, estando conectado cada encaminador conectado tanto a su red propia como a la red troncal.
En lo referente a la resolucion de nombres, se ha optado por utilizar el servicio DNS.
Conguracion de las Redes
Uno de los ordenadores de la red troncal (adserver) actuara como el servidor maestro del dominio
admon, y cada departamento utilizara y administrara un subdominio del dominio admon. La tabla
siguiente detalla las caractersticas de todos los ordenadores de la organizacion:
Grupo No IP en Red IP en Red Servidor DNS Encaminador
PC Troncal
Local
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
p
1
01
158.42.54.61
158.1.1.1
pc0201.grupo1.admon
158.1.1.2
pc0202.grupo1.admon
158.2.1.1
pc0203.grupo2.admon
158.2.1.2
pc0204.grupo2.admon
158.3.1.1
pc0205.grupo3.admon
158.3.1.2
pc0206.grupo3.admon
158.4.1.1
pc0207.grupo4.admon
158.4.1.2
pc0208.grupo4.admon
158.5.1.1
pc0209.grupo5.admon
10
158.5.1.2
pc0210.grupo5.admon
13
158.6.1.2
pc0213.grupo6.admon
158.6.1.1
pc0214.grupo6.admon
158.7.1.2
pc0215.grupo7.admon
158.6.1.1
pc0216.grupo7.admon
158.8.1.2
pc0217.grupo8.admon
158.8.1.1
pc0218.grupo8.admon
158.9.1.2
pc0219.grupo9.admon
158.9.1.1
pc0220.grupo9.admon
02
2
03
158.42.54.63
04
3
05
158.42.54.65
06
4
07
158.42.54.67
08
5
6
09
14
7
158.42.54.76
158.42.54.78
19
20
adserver
158.42.54.74
17
18
9
158.42.54.69
15
16
8
Nombre DNS
158.42.54.80
158.42.49.82
1
adserver.admon
2
Actividad: Encaminamiento y DNS
Primera Parte: Establecimiento de las Redes
Esta parte consiste en el establecimiento de las distintas redes fsicas de la organizacion. Para ello,
el servidor Linux de cada departamento va a ser desconectado de la red troncal, pasando ahora a
formar parte de la red propia. Este cambio va a provocar que algunos servicios, NIS, NFS y DNS
en particular, deban ser recongurados. A continuacion haremos referencia a los dos equipos de cada
grupo como \el encaminador" y \el servidor" (este ultimo, que ya es servidor de NIS y NFS, sera
tambien el servidor DNS). Los pasos a seguir son los siguientes:
1. En ambos sistemas, lo primero que hay que hacer es copiar todo el software necesario para
la practica. Dicho software puede recuperarase mediante el ftp de adserver, en el directorio
pub/dns. Copiar todo ese directorio a /tmp/dns (cuidado con los subdirectorios!).
2. Arrancar ambos ordenadores en el nivel de ejecuci
on 2. Al utilizar este nivel los servicios
NFS y NIS no se activan, lo cual es necesario porque ambos servicios van a dejar de funcionar
debido a los cambios realizados en la red.
3. Ahora hay que conseguir que DNS no interera con los cambios en la red que vamos a efectuar.
Para ello hay que hacer lo siguiente en ambos sistemas:
Desactivar la utilizacion de la resoluci
on de nombres DNS (mediante linuxconf).
Especicar de forma estatica las nuevas direcciones de los dos ordenadores del grupo. La
forma mas facil es incluir en el chero /etc/hosts las nuevas dos direcciones IP (de la red
local), cada una junto con el nombre de su ordenador.
En el chero /etc/nsswitch.conf, editar la lnea que empieza por hosts: de manera que
la primera opcion de la lista sea files y la segunda dns.
4. Conectamos el servidor a la nueva red. Para ello:
Desenchufar el cable de red de la roseta y conectar dicho cable y el cable amarillo entre s
con el conector.
Mediante linuxconf, cambiar la direccion IP de la tarjeta de red, seg
un la nueva conguracion de la tabla.
Reiniciar el servidor en el nivel 2.
5. En el encaminador debe darse de alta la segunda tarjeta de red (correspondiente a la red local).
Sus parametros son:
Enabled: S
Config mode: Manual
Primary name+domain: (ver tabla)
Aliases: ninguno
IP Address: (ver tabla)
Netmask: 255.255.0.0
Net device: eth1
Kernel module: rtl8139
Una vez hecho esto, reiniciar el encaminador en el nivel 2.
6. En ambos ordenadores, cambiar la direccion IP del servidor NIS (mediante linuxconf).
7. En el servidor NFS, reejar los cambios realizados en las direcciones IP y/o nombres de ordenadores en la tabla de exportacion de directorios va NFS.
8. En el cliente NFS, reejar los cambios realizados en las direcciones IP y/o nombres de ordenadores en la tabla de montaje de dispositivos.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
3
9. Reiniciar ambos ordenadores, en este caso en el nivel de arranque por defecto.
Una vez concluidos estos pasos, es conveniente comprobar mediante el mandato
ping -n, utilizando
exclusivamente direcciones IP, la conectividad que ambos ordenadores tienen a la red, es decir, qu
e
ordenadores son alcanzables mediante el
ping.
Segunda Parte: Interconexion de las Redes
El objetivo de esta segunda parte consiste en interconectar las distintas redes entre si, de tal forma que
todos los ordenadores puedan comunicarse entre ellos. Un metodo para conseguir esta conectividad
consiste en instalar el servicio de encaminamiento dinamico (gated) en cada uno de los ordenadores
que forman parte de la red troncal. Los pasos a seguir son los siguientes:
En el encaminador:
1.
2.
3.
4.
Instalar el paquete gated, disponible en /tmp/dns.
Congurar gated. Para ello basta copiar el gated.conf del directorio /tmp/dns al /etc.
Congurar el inicio de gated en los niveles de ejecucion 2, 3 y 5.
En el apartado de Gateways de linuxconf, eliminar la direccion IP del gateway y habilitar
el encaminamiento.
5. Debido a un error en RedHat 6.2, hay que incluir a mano la siguiente lnea en el chero
/etc/rc.d/init.d/gated (en la seccion start), antes de la lnea daemon gated):
echo ``1'' > /proc/sys/net/ipv4/ip_forward
6. Reiniciar.
En el servidor:
1. Indicar que su gateway por defecto es el encaminador de la red propia.
2. Reiniciar.
Volver a comprobar la conectividad de ambos ordenadores, de nuevo mediante
ping -n
y direc-
ciones IP, viendo qu
e ordenadores son ahora alcanzables.
Tercera Parte: Asignacion de Nombres
Para concluir la conguracion de la red es necesario establecer un mecanismo que permita que los
ordenadores puedan comunicarse entre si utilizando nombres (por ahora, tan solo pueden utilizarse
direcciones IP). El mecanismo escogido en este caso es el servicio DNS. El ordenador adserver actuara como el servidor principal de la organizacion, para lo cual administrara el dominio admon. No
obstante, cada departamento dispondra de un dominio propio, y sera cada departamento el encargado de administrarlo. Para ello, adserver delegara la autoridad de cada subdominio de admon en el
servidor DNS del departamento correspondiente. Los pasos a seguir son los siguientes:
En el servidor (DNS):
1.
2.
3.
4.
Instalar el paquete bind-8.2, disponible en /tmp/dns.
Congurar el inicio de named en los niveles de ejecucion 3 y 5.
Copiar el chero /tmp/dns/named.conf en /etc.
Copiar el directorio /tmp/dns/named en /var.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
4
5. Renombrar los cheros /var/named/Z.158.zona y /var/named/grupoZ.admon.zona, cambiando Z por el numero del grupo.
6. Editar los cheros /var/named/grupoZ.admon.zona, /var/named/Z.158.zona y
/etc/named.conf para adecuar sus contenidos. Las modicaciones a realizar consisten en
realizar las siguientes sustituciones:
Z: numero del grupo
XX: servidor DNS (n
umero de PC)
YY: encaminador (numero de PC)
7. Reiniciar el ordenador.
En ambos sistemas, especicar los par
ametros del servicio DNS:
{ Servidor: 158.Z.1.2
{ Orden de busqueda 1: grupoZ.admon.
(Nota: Es posible que, debido a un error de linuxconf, el servicio DNS
no pueda congurarse. Para solucionarlo, debe borrarse el contenido del
chero /etc/resolv.conf antes de utilizar linuxconf.)
Una vez concluidos estos pasos, debe observarse que todos los ordenadores de la organizaci
on son
accesibles por nombre, as
como que los servicios NFS y NIS funcionan correctamente.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
DE SISTEMAS
ADMINISTRACION
ACTIVIDAD
WINS y DHCP en Windows NT
Introducci
on
El objeto de la practica consiste en adquirir habilidades relacionadas con la instalacion y conguracion
del protocolo DHCP y del servicio de nombres NetBIOS sobre TCP/IP (WINS) en un entorno NT.
En particular, se abordaran los siguientes conceptos:
Instalacion y conguracion de servidores DHCP.
Conguracion de Windows NT como cliente DHCP.
Instalacion y conguracion de varios servidores WINS.
Conguracion de Windows NT como cliente WINS
La practica se realizara en el contexto de varias redes locales interconectadas por otra red de area
troncal, por lo que sera necesaria la conguracion del encaminamiento entre redes.
Nota: Esta practica debe realizarse con la red local del laboratorio aislada.
(adviertalo a su profesor, ya que suele ser muy despistado :-)
Supuesto Practico
Una organizacion posee sistemas Windows NT distribuidos en varios departamentos. Dicha organizacion desea que cada departamento posea su propia red fsica (interconectada con el resto de la
organizacion) y que ademas resulte facil cambiar un ordenador de departamento sin tener que recongurar manualmente sus parametros de red.
En concreto, se pretende conseguir una situacion descrita por los siguientes puntos:
Cada departamento posee una red fsica propia, denominada red local.
Para conseguir la interconexion de las redes de los departamentos, se dispone de otra red de area
local (denominada troncal ). La red local de cada departamento dispondra de un ordenador que
realizara las funciones de encaminador, estando conectado tanto a su red propia como a la red
troncal.
La organizacion ha decidido utilizar el servicio WINS para la resolucion de nombres NetBIOS.
En concreto, se pretende que cada departamento disponga de un servidor WINS propio, y que
todos los servidores WINS de la organizacion cooperaren entre s para permitir que la resolucion
de nombres NetBIOS funcione correctamente a nivel de toda la organizacion.
La organizaci
on no utiliza en absoluto el sistema de resolucion de nombres DNS.
Para facilitar la movilidad de los ordenadores, cada departamento asignara direcciones y propiedades
TCP/IP a sus ordenadores de forma dinamica, utilizando para ello un servidor DHCP (privado
en cada red local).
1
2
Actividad: WINS y DHCP en Windows NT
La tabla siguiente detalla las caractersticas de todos los ordenadores de la organizacion:
Grupo
1
No IP en Red
PC Troncal
IP en Red
Local
01
158.1.1.1
158.42.54.61
02
2
03
05
158.42.54.63
07
158.42.54.65
09
158.42.54.69
7
16
18
158.42.54.76
adserver
p
pc0204
p
p
pc0206
p
p
pc0208
158.3.1.1
158.4.1.1
158.5.1.1
158.6.1.1
158.7.1.1
158.8.1.2
158.42.54.78
19
20
p
158.2.1.1
158.7.1.2
17
9
pc0202
158.6.1.2
158.42.54.74
15
8
p
158.5.1.2
13
14
p
158.4.1.2
10
6
p
158.3.1.2
158.42.54.67
08
5
p
158.2.1.2
06
4
Encaminador
158.1.1.2
04
3
Serv. WINS-DHCP
158.8.1.1
158.9.1.2
158.42.54.80
158.9.1.1
158.42.49.82
Nombre
NetBIOS
pc0201
pc0203
pc0205
pc0207
pc0209
pc0210
p
p
pc0213
p
p
pc0215
p
p
pc0217
p
p
p
pc0219
pc0214
pc0216
pc0218
pc0220
adserver
Primera Parte: Encaminamiento
En cada grupo, la activacion del encaminamiento debe realizarse siguiendo los pasos expresados a
continuacion:
En el enrutador:
1. Dar de alta la segunda tarjeta de red. Esta tarjeta de red se utilizara para conectar con
el otro ordenador del grupo, formando as la red propia. El manejador para el modelo de
tarjeta utilizada esta disponible en el recurso de red nnadservern3com.
2. Reiniciar el ordenador en este punto.
3. Instalar el enrutamiento. Para ello, se debe agregar el servicio denominado Enrutador RIP
para el protocolo Internet (IP) en la pesta~na de Servicios, en la conguracion de
Red del Panel de Control.
4. Comprobar, en las propiedades del protocolo TCP/IP, que el \reenvo IP" este activo.
En el otro equipo: se debe modicar las propiedades TCP/IP de su u
nica tarjeta de red para
que reeje la nueva conguracion de la red (ahora forma parte de la red local).
Ambos sistemas deben conectarse entre s. Para ello, debe enchufarse el cable que conecta la
segunda tarjeta de red del enrutador con el cable de red del otro equipo.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci
3
Segunda Parte: Instalacion de WINS
En cada grupo, la instalacion del servicio WINS debe hacerse en el ordenador que ademas es el
enrutador, y que denominaremos genericamente \servidor". La instalacion/conguracion de dicho
servicio debe realizarse mediante los siguientes pasos:
1. Instalar el servicio WINS en el servidor. Para ello, agregar el servicio Servidor de nombres
de Internet para Windows en la pesta~na de Servicios en la conguracion de Red del Panel
de Control.
2. Tanto el servidor WINS como su cliente de cada grupo deben indicar en las propiedades del
protocolo TCP/IP la direccion IP del propio servidor WINS del grupo. Puesto que solo hay
un servidor WINS por grupo, debe indicarse el servidor WINS primario, no el secundario.
En este punto, comprobar que ordenadores de la organizacion se pueden encontrar (mediante
Inicio/Buscar Equipo) desde ambos ordenadores del grupo.
3. Establecer las relaciones entre los servidores WINS, tal como muestra la Figura 1. En una
primera fase, no establecer la duplicacion entre los servidores denominados A y B en la gura.
Comprobar que equipos se pueden encontrar ahora desde cada ordenador.
4. Finalmente, establecer las relaciones de duplicacion entre los servidores denominados A y B en
la gura. Comprobar si nalmente todos los ordendores de la organizacion se pueden encontrar
desde cada ordenador.
Tercera Parte: Instalacion de DHCP
En cada grupo, la instalacion del servicio DHCP debe hacerse en el servidor (servidor DHCP+servidor
WINS+enrutador). Para ello deben seguirse los siguientes pasos:
1. Instalar el servicio DHCP. Para ello se agrega el servicio denominado Servidor DHCP de Microsoft
en la pesta~na de Servicios en la conguracion de Red del Panel de Control.
2. Una vez instalado el servidor, se deben seguir los siguiente aspectos de conguracion:
Agregar un nuevo ambito:
{ Rango de direcciones IP a asignar: 158.Z.1.2 a 158.Z.1.20, donde Z representa el numero
del grupo.
{ Mascara de subred: 255.255.0.0
{ El ambito debe ser activado.
Opciones de conguraci
on del ambito:
{ Enrutador: 158.Z.1.1
{ WINS: Congurar el servidor WINS como el 158.Z.1.1 y el tipo de nodo a p-type.
3. Una vez instalado y congurado el servidor, se debe congurar tambien el cliente. Para ello, en
las opciones de conguracion del protocolo TCP/IP hay que seleccionar Obtener direccion IP
de un servidor DHCP. Aseg
urese de que el resto de opciones locales sean borradas: servidor
y domino DNS, puerta de enlace, y servidor(es) WINS. Una vez reinicie el cliente, este debera
obtener su direccion IP y el resto de opciones de un servidor DHCP.
Administraci
c Agust
n Espinosa, Andr
es Terrasa, 2001
4
WINS
WINS
WINS
WINS
WINS
WINS
WINS
B
WINS
WINS
A
adserver
la puerta
Servidor de Duplicacion
Figura 1:
Cliente WINS de ...
Relaciones de duplicaci
on entre servidores WINS.
Nota 1: Utilice el mandato ipconfig /all en el cliente para
vericar las propiedades TPC/IP asignadas al cliente.
Nota 2: Utilice los mandatos ipconfig /release e ipconfig
/renew para cancelar y renovar, respectivamente, la concesi
on
DHCP en el cliente, si lo considera necesario.
c Agust
n Espinosa, Andr
es Terrasa, 2001
Administraci

ر ز ×طض سز ث ×ط ر ×

Transcripción

Documentos relacionados

1 administracion y direccion

Sistema de análisis de la sismicidad sobre servidor Web System of

instructivo normativo para la asignación de la clave única de

Memoria y Balance Anual Ejercicio 2012-2013

Búsqueda en la Internet - Cetem

Completo manual de Informática - Tecnológico Superior Vida Nueva