Herramientas Web. Investigación en Internet 
Equipo Nº 2 - Tema: INTRANET 

 Página Original: http://www.unet.edu.ve/materias/electronica/ing_redes/C6/index.html

 

Capítulo 6: Servicios y Aplicaciones TCP/IP

Servicios de directorios.

Hasta esta parte del curso hemos discutido la plataforma básica de Internet. Los protocolos IP, UDP y TCP conforman el soporte de una gama bastante amplia de aplicaciones. Las aplicaciones son programas que prestan servicios a otros programas y a usuarios humanos. Comenzamos el recorrido con una aplicación que cumple en Internet (y en cualquier red TCP/IP) el mismo papel que cumple la guía telefónica en los sistemas públicos de comunicación. Esto es, una base de datos (con un manejador elemental) que permite obtener determinada información a partir de claves. Por ejemplo, así como en el sistema telefónico dado un nombre se puede averiguar un número telefónico, en el sistema de nombres de Internet, dado un nombre de un máquina se puede averiguar su dirección IP.

Claro está que, por tratarse de computadores (procesadores de información por excelencia) estos sistemas de directorio (que así se llaman en general las "guías telefónicas" de las redes), prestan servicios de apoyo mucho más complejos. De hecho, se construye una base de datos tal que, dado un atributo cualquiera de un objeto de la red, se pueden averiguar los demás, incluso la ruta de acceso hasta el objeto. El otro aspecto involucrado en los sistemas de directorio es un mecanismo para asignarle nombres a las cosas, indispensable si queremos referirnos a los objetos (y a los usuarios) de la red por nombres fáciles de comprender por los seres humanos. En esta parte vamos a cambiar un poco la estrategia del curso y en lugar de incluir ejercicios en el texto, se convertirá el texto en ejercicios de configuración para toda la sesión. Si su laboratorio cuenta con la plataforma adecuada, podrán realizar los ejercicios sobre el computador.

Servicios de directorios en OSI.

OSI también contempla ciertas "aplicaciones para usuarios" que pueden ser determinantes para el funcionamiento de las redes. Una de ellas es el sistema de directorio de nombres X.500, la especificación de una aplicación para gestión de identificadores en redes. X.500 es una propuesta de estandarización que no ha sido implantada todavía en forma global. No obstante, existen implantaciones piloto.

La función de X.500 es proveer un sistema de "revisión" o consulta de datos en la red, en cierto sentido equivalente a un directorio telefónico, pero mucho más detallado. Los objetos de la red son descritos como listas de atributos. Se dice que el éxito de el sistema de directorio X.500 es esencial para la consolidación del sistema de correo propuesto en OSI: X.400, un ambiente de intercambio de mensajes que, según los expertos, no es demasiado complicado lo que puede permitir que sea útil al común de los mortales.

FIGURA 83.

Internet Control Message Protocol (ICMP).

Ya se ha visto que, además de los protocolos principales de cada capa (como el IP), el sistema cuenta con otros protocolos auxiliares (ejem. ARP, RARP). ICMP es uno de esos, especialmente diseñado para intercambiar mensajes de control entre máquinas IP. ICMP usa IP, ya que los mensajes son encapsulados dentro de sus datagramas, pero no se le considera como un protocolo de capa superior.

Una restricción de ICMP es que los errores se reportan solo al origen de un datagrama, no a los puntos intermedios.

Algunos mensajes son:

* Estado de un nodo (ping)

* Destinatarios inalcanzables

* Error en el formato del datagrama

* Datagrama viejo

* Cambio de ruta

* Reducir demanda

Uno de los servicios fundamentales que presta ICMP es permitirle al administrador (o a un usuario cualquiera) de la red, determinar el estado de un nodo o anfitrión. Un programa especial permite enviar a través de la red un ICMP echo request a un máquina, la cual, si está conectada y activa, responde con un ICMP echo reply. Otros mensajes son: destination unreachable, source quench, etc.

Con el ejercicio sabrán del manejo de ese programa y del protocolo.

TCP/IP - 39: Packet InterNet Groper. (PING).

Ejecute el comando ping máquina. El instructor le indicará varios nombres de máquinas. Interprete los mensajes obtenidos.

Ejecute el comando ping -n 100 máquina. ¿Cuál es el efecto de esta variante del programa ping?.

FIGURA 84.

FIGURA 85.

El Network Information Service (NIS)

El NIS, originalmente llamado Yellow Pages (Páginas Amarillas, un nombre que tuvieron que reemplazar ante un reclamo de la compañía telefónica Inglesa con los derechos sobre el nombre) es un sistema de directorio creado por Sun para sus máquinas UNIX. A diferencia del DNS, el sistema estándar para resolver nombre contra direcciones en Internet, el NIS ofrece información más general y de más alto nivel.

Con el NIS se constituye un dominio, entidad administrativa que agrupa a un conjunto de máquinas servidoras y clientes en una red UNIX. El servicio global que presta el NIS es el de compartir los llamados mapas de páginas amarillas. Los mapas son bases de datos construidas a partir del los archivos /etc/hosts, /etc/group y /etc/passwd. Estos archivos son convertidos en mapas que son transmitidos a los restantes sistemas UNIX a través del NIS.

Esto simplifica la administración del NFS puesto que ahora, los usuarios y máquinas están registrados en una entidad que centraliza la administración. Cuando se agrega un usuario a un dominio NIS, por ejemplo, la línea correspondiente se coloca en el archivo /etc/passwd. Ese archivo debe hacerse corresponder, de alguna manera, con la tabla de password del NIS. Al reconstruir la tabla, alguien debería ejecutar el comando yppush con lo que estaría irradiando los cambios a los otros servidores. Entonces el nuevo usuario podría identificarse ante cualquiera de esas máquinas como en el servidor maestro.

Una observación importante acerca del uso del NIS es la siguiente. NIS permite aumentar el archivo /etc/passwd en cada máquina donde se instale. Los programas que consultan el /etc/passwd, si encuentran en él una línea que comienzan con + o -, consultarán el NIS (la tabla con los usuarios de todo el dominio). Esto no representa ningún problema, al contrario es muy ventajoso como se explicó. El problema puede surgir si todos los usuarios son registrados en esta tabla pública, incluyendo a los administradores. Esto implica que los password de los administradores viajan por la red, con el riesgo de que algún nodo furtivo los intercepte, traduzca y use. (Esto es válido para cualquier password en NIS, por supuesto que desencriptar un password no es tarea fácil, pero nadie asegura que no se puede). Por ello se aconseja que cada máquina (incluso el servidor maestro de NIS) mantenga su propias cuentas de administración (root, etc)

TCP/IP - 40. Network Information Service. (NIS). Revise el contenido de los archivos NIS. Revise en los archivos de arranque del sistema las líneas donde se invocan los comandos que activan el NIS (Ind. revise el rc.local y busque el comando ypinit o ypbind).

TCP/IP - 41. Más del NFS, RPC y NIS. Ejecute el comando rpcinfo.

FIGURA 86.

El Servicio de nombres en Internet (Domain Name Service).

El diseño del sistema X.500 sigue las pautas establecidas por el ampliamente conocido Internet Domain Name System (conocido también como BIND: Berkeley Internet Name Domain). Mientras que X.500 ordena los datos específicos de las personas (usuarios) en una jerarquía de vínculos geográficos-corporativos, DNS (como llamaremos en lo sucesivo al BIND) hace lo propio pero con los nombres de las máquinas.

Son especialmente importantes en los sistemas DNS, los registros MX para declarar a las "pasarelas de correo" (Mail eXchanger gateways). Un registro de este tipo permite que una máquina en la red, actúe como "gateway" para el correo dirigido a usuarios en otra máquina. En particular un anfitrión (host) BITNET, UUCP o DECNET puede parecer accesible para el sistema de correo Internet, aún cuando no esté realmente conectado. El "gateway" recoge todo el correo dirigido al otro computador y "reconoce" ese correo como un caso especial.

Veremos a continuación cuales son los pasos fundamentales al configurar sistemas DNS en ambiente Internet, pero antes, algunas explicaciones acerca del concepto global que se manipula. El DNS divide la red en una jerarquía de dominios, es decir los ámbitos administrativos-organizativos, están estructurados como un árbol invertido. Cada nodo del árbol tiene una etiqueta que lo identifica y el nombre de un dominio es "la concatenación de todas la etiquetas de nodos (dominios en los otros niveles) desde la raíz hasta el dominio que se quiere referir, listadas de izquierda a derecha y separada por puntos".

TCP/IP - 42: Domain Name Service. Revise el directorio /var/named y trate de indicar la jerarquía de nombre en su dominio.

FIGURA 87.

Configurando el in.named, una implementación de DNS.

El DNS es incorporado a algunos ambientes UNIX bajo la forma de un programa "demonio" denominado in.named, un programa del sistema que se ejecuta automáticamente al arrancar la máquina y permanece en ejecución atendiendo las solicitudes de transformación nombre máquina <-> dirección IP (resolución de nombres).

El in.named comienza a funcionar sólo si consigue el archivo /etc/named.boot y este contiene la información adecuada y correctamente dispuesta. A continuación presentamos un ejemplo del contenido y formato del archivo /etc/named.boot. Es posible agregar comentarios en este archivo colocando un punto y coma ";" en cada línea, justo antes del texto del comentario. Nos aprovechamos de esta capacidad para comentar cada uno de los parámetros y valores que pueden encontrarse en este archivo de configuración (*) Aconsejamos incluir estos comentarios en sus implantaciones reales del DNS, para guiar a los nuevos administradores.

; ; Aquí puede ir un comentario de encabezado ; ; Versión del archivo y fecha de la última modificación. ; directory /var/named ; ; Debe especificarse un directorio existente. Este será el directorio empleado por el in.named para ejecutarse. ; Es importante especificarlo, puesto que en caso de que el programa se estrelle (crash), ;el archivo de vaciado ; de memoria (core), para una eventual revisión "post mortem", se encontrará allí. ; forwarders 150.188.1.10 ; ; Direcciones de los hosts pertenecientes a un dominio superior que pueden ser consultados en caso :de que no se pueda hacer la transformación nombre <-> Dirección IP en la maquina local estas ;direcciones se separan con espacios en blanco. ; cache named.ca ; ; Nombre del archivo en donde se mantiene la información de los servidores del dominio raíz

(*) Solicite a su instructor los valores que deberá emplear en su ejercicio.

FIGURA 88.

Definiendo un dominio (servidores primarios).

Preparemos ahora a la estación para que se comporte como un servidor primario de su dominio (al cual Uds. asignarán nombre). Para ello, agreguen la siguientes líneas al archivo /etc/named.boot:

; primary ula.ve P/ve.ula ; ; Este parámetro le dice al in.named que sirva a ula.ve como servidor primario y use el ; archivo P/ve.ula como fuente de información acerca de ese dominio. ;

A continuación, debemos preparar los archivos establecidos en los parámetros 'cache' y 'primario' (estos dos y el archivo 'secondary' tienen la misma estructura pero este último no tenemos que modificarlo ¿Por qué?). La sintaxis de estos archivos es:

nombre [tiempo_de_vida] [familia] tipo_registro contenido

Nombre Identificación del host que funcionará como servidor

Tiempo_de_vida Tiempo que se mantiene la información en el servidor antes de ser renovada

Familia Tipo de red al cual se encuentra conectado el servidor

Tipo_registro Es un identificador que indica el tipo de registro, algunos de ellos son ´A´, ´SOA´, ´NS´, ´PTR´ y ´HINFO´

contenido Es el contenido del registro, este depende del tipo de registro

Los campos que aparecen entre corchetes ([ ]) son opcionales. por ejemplo:

merlin IN A 150.185.128.1

mapea el nombre de un "host", merlin, con la dirección 150.185.128.1 dentro de familia Internet (IN), por ser este un registro de tipo A (Name to Address mapping). El valor de tiempo_de_vida no se indica, así que lo tomará igual a aquel especificado en otro registro especial, el SOA Resource Record (Start Of Authority Resource Record).

Los archivos fuente de dominio (los que se indican en 'primary'), deben comenzar con un registro de recurso de comienzo de zona de autoridad (SOA RR).

FIGURA 89.

Un Archivo de configuración de un servidor primario puede ser:

; ; Archivo fuente para el dominio "ula.ve" ; @ IN SOA merlin.ula.ve. root.ula.ve.( 9211160 ; serial debe cambiarse este número ; cada vez que se modifique este archivo 86400 ; actualiza la información ;en los servidores secundarios cada día 3600 ; Reintentos cada hora 432000 ; expira los reintentos a los 5 día 86400) ; ttl (time to live) tiempo de vida del ;registro al ser capturado.

432000 ; expira los reintentos a los 5 día 86400) ; ttl (time to live) tiempo de vida del registro al ser capturado. El caracter @ indica que se está hablando del dominio actual y que está definido en el archivo /etc/named.boot. En este caso se trata de la cadena "ula.ve". En su caso debería ser algo como "midominio.ve".

; lista de los servidores de nombre ; (primarios y secundarios) que son responsables ; de este dominio. ; IN NS dino.conicit.ve. IN NS merlin.ula.ve. ;

Según la sintaxis establecida, si el campo nombre está vacío, se toma el valor correspondiente de la línea anterior. En este caso "ula.ve.". El registro NS indica que se trata de un servidor de nombres (Name Server). ; Uds. pueden definir también registros MX para su ; dominio aquí mismo. Note que nombre nuevamente no se ; indica, así que su valor sigue siendo el anterior. ; IN MX 10 merlin.ula.ve. ;

En este registro, mientras peor o menos funcional se considere que es el redireccionador de correo, más grande deberá ser el número antepuesto. Esta es una forma de priorizar el uso de uno u otro. (Puede Ud. tener muchos registros para cada destino o dominio.)

En el caso de la ULA, sería muy adecuado agregar a dino.conicit.ve como un registro más tipo MX. Esto, por cuanto el enlace de la ULA con el mundo exterior no es rápido y los mensajes de correo que se ven involucrados en una "caravana" desde la ULA, bien podrían ser devueltos simplemente porque es muy difícil llegar hasta allí. Así que agreguen la línea (realmente esa línea debería agregarla con el permiso del administrador de dino):

; IN MX 100 dino.conicit.ve. ;

y ahora incluya sus máquinas en este dominio (tantas como quiera o tenga):

; localhost IN A 127.0.0.1 ; dirección para el trafico interno del servidor merlin IN A 150.185.128.1 nostradamus IN A 150.185.128.11 ;

Pueden agregar también registros HINFO, que permitirán obtener una descripción de las máquinas:

; ; nostradamus IN HINFO "SPARC" "UNIX SUNOS 4.1.1" ;

En este caso, el ´HINFO´ nos indica que es un registro tipo información, donde, el primer campo describe el hardware y el segundo el software de la máquina. Observen también el uso de las comillas. Deben usarse, se sorprenderían de los resultados si no lo hacen.

También es posible asignar "aliases" a la máquinas para ello se utilizan registros tipo CNAME.

ftp IN CNAME merlin.ula.ve.

Con este registro Uds. están creando una nueva máquina llamada ftp, que realmente es el mismo merlin.ula.ve. Con esto es posible crear servicios que son independientes de una maquina en particular. Por ejemplo el servicio ´FTP´:

host% ftp ftp.ula.ve Conecta un usuario al servidor de ´FTP´ sin importar el nombre real de la máquina.

Servidores secundarios en el DNS.

Los servidores secundarios podrían llamarse servidores auxiliares (más no de respaldo como veremos). No mantienen por sí mismos una tabla de información, sino que la obtienen de un servidor primario. Su función es meramente capturar las solicitudes de los clientes y tratar de resolverlas con la información que hayan podido obtener del servidor primario. Como no necesita mayor estructura de archivos, es más fácil establecer un servidor secundario que uno primario (siempre que haya uno primario cerca). Por esta razón, vamos a completar el archivo /etc/named.boot con los parámetros necesarios para preparar a la máquina como un servidor secundario:

secondary in.ula.ve 150.185.146.1 S/ve.ula.ing ; ;Este parámetro le dice al in.named que "sirva" como "solucionador" al dominio 've'. ;en modo secundario. La información de ese dominio la obtendrá del hosts cuya ;dirección es 150.185.146.1 ; y la colocará en el archivo '/var/named/S/ve.ula.ing'. ; Atención: el directorio '/var/named/S' debe existir. ; ;La ventaja de usar un subdirectorio 'S' y otro 'P' (para el servidor primario), es que este esquema ; separa los archivos que Ud. modifica 'P', de los archivos que el in.named actualiza 'S'. ;(Lo que se toma de la red separado de lo que se ofrece a ella).

FIGURA 90.

Definiendo un dominio inverso (REVERSE DOMAIN).

Para tener todo el servicio DNS activo, debe definirse también lo que se conoce como "zona inversa" (reverse zone). La zona inversa consiste de un mapa que permitirá convertir los números IP de las máquinas en la red, a sus nombres asignados (al contrario de lo que veníamos haciendo). Esto se logra registrando los "servidores de zona inversa" en sus redes, con el [email protected]. Para activar el servicio, es preciso agregar (como en el caso del servicio no invertido) los servidores primarios y secundarios. El mapa de "inversión" comienza con un registro SOA.

; ; archivo fuente para 128.185.150.in-addr.arpa. ;

Observen especialmente la notación invertida de su número de red en la jerarquía de la zona inversa. Su red es 150.185.128.0 y acá se declara 128.185.150

@ IN SOA merlin.ula.ve. root.ula.ve.( 9211160 ; serial 86400 ; actualiza la información en los servidores secundarios cada día 3600 ; Reintentos cada hora 432000 ; expira los reintentos a los 5 días 86400) ; ttl (time to live) tiempo de vida del registro al ser capturado. ; ; y ahora la lista de servidores ; IN NS merlin.ula.ve. ; ; y a partir de este punto se coloca la verdadera información de zona. La información ; es proporcionada en forma de apuntadores PTR, registros que apuntan al espacio de los ;nombres. ; 1 IN PTR merlin 11 IN PTR nostradamus.ula.ve. ; ; Haciendo un alto en el recorrido, queremos destacar el uso de los puntos al final del nombre de las máquinas. Si se le omite el dominio actual (en este caso 128.185.150.in-addr.arpa) se agregará al final ; del nombre y entonces tendríamos algo como: nostradamus.ula.ve.128.185.150.in-addr.arpa.) ; En el mismo orden de ideas, noten que no hemos agregado el punto (.) a la maquina merlin, ; puesto que queremos que se le agregue el dominio por omisión, para formar la cadena deseada: ; merlin.128.185.150.in-addr.arpa. ;

Esto es todo, en las zonas inversas sólo coloquen registros SOA, NS y PTR. Esto es suficiente por ahora.Solo se pueden definir servidores de dominio para una clase completa, ya sea de tipo A, B, o C o en forma equivalente para grupos de máquinas de 256, 256*256 o 256*256*256.

TCP/IP - 43: A que se debe que solo se puedan definir dominios para determinados conjuntos de maquinas, que tiene que ver esto con el enmascaramiento visto en capítulos anteriores.

FIGURA 91.

Verificando el funcionamiento del DNS

Para verificar que el in.named esté en operación, envíele una señal SIGHUP:

host# kill -HUP 'cat /etc/named.pid'

En la instrucción anterior nos estamos aprovechando del hecho de que el in.named almacena su PID en el archivo /etc/named.pid al momento de arrancar. En unos 5 o 10 seg. pueden revisar el archivo /var/adm/messages para comprobar si el in.named tuvo problemas al arrancar.

host# tail /var/adm/messages

Un minuto después aproximadamente, pueden enviar una señal SIGINT,

host# kill -INT 'cat /etc/named.pid'

la cual debe provocar que el in.named vacíe su base de datos en el archivo /var/tmp/named_dump.db. Use cualquier editor para examinar este archivo.

FIGURA 92.

Configurando a los CLIENTES del DNS.

Ya hemos visto como configurar servidores de DNS. Los clientes del DNS no son tan complicados de configurar, a pesar de la gran variedad de realizaciones que existen. Algunas aplicaciones con propósitos específicos tienen interconstruídos los mecanismos de consulta a un servidor de nombres. Los programadores en ambiente UNIX 4.3BSD disponen de una biblioteca de rutinas (gethostbyname(), gethostbyaddr(), sethostent()). Algunas de ellas se encuentran integradas en una aplicación local (resolver), que se encarga de consultar al servidor cuando alguna de sus máquinas compañeras necesita una traducción.

En general, la información que necesita un sistema para contactar a un servidor de nombre es la siguiente(*):

domain ula.ve nameserver 150.185.128.1 nameserver 150.188.1.10

Esto se indica en el archivo /etc/resolv.conf de cada cliente.

El orden en el cual aparecen los nameserver le indica al cliente el orden en el cual deberá consultarlos, en caso de fallas de alguno de ellos. Cabe destacar que el primer servidor no necesariamente es el servidor primario del dominio.

TCP/IP - 43: Clientes del DNS.

(*). En la máquina UNIX, revise el archivo /etc/resolv.conf. Verifique que su contenido sea similar al mostrado antes.

Ejecute la aplicación nslookup, si está disponible en su sistema. Su instructor le dará indicaciones adicionales.

Si existen máquinas DOS/WINDOWS con sistemas TCP/IP en su laboratorio, averigue como se configura el cliente TCP/IP en ellas (Ind. Busque el archivo protocol.ini).

FIGURA 93.

Recapitulando sobre el Domain Name System.

Con el DNS se implanta un sistema de asignación de nombres a objetos de la red. En particular las direcciones IP pueden ser traducidas a nombres más simples en el lenguaje humano.

Cuando se implanta el DNS en una red dentro de Internet, se está creando (probablemente) un dominio administrativo. Para referirse, desde cualquier parte de Internet a los objetos de ese dominio, se usa una cadena identificadora con el siguiente formato:

objeto.dominio_local.dominio_superior ... dominio_superior. dominio_raiz.

Implantar un sistema DNS implica configurar los servidores y los clientes. Los servidores son máquinas con programas dedicados a gestionar el acceso a las bases de datos con la información (realmente el servidor es el programa). Se ha hablado de dos tipos de servidores: Maestros Primarios y Maestros Secundarios.

Para configurar un servidor Maestro de un nuevo dominio se deben crear y completar adecuadamente los siguientes archivos:

Boot file: Generalmente /etc/named.boot. Contiene los parámetros de arranque.

Cache: El archivo con la especificación de los servidores autorizados de todo Internet. (los servidores del domino raíz).

Archivos con datos de dominios: Contienen la especificación de cada objeto del dominio de acuerdo al Standard Resource Record Format: Suelen ser grupos de archivos: named.local, archivo con la dirección local 127.0.0.1; Archivos de todos los anfitriones de cada domino; Archivos con los anfitriones del domino inverso.

Para configurar un cliente del DNS, generalmente basta indicarle su dominio y dirección de los servidores que consultará.

TCP/IP - 44: Recapitulando con DNS.

Indique cuales son los archivos de datos y a que tipo pertenecen en su servidor de nombres.

FIGURA 94.

TELNET.

En el nivel de aplicaciones del modelo DOD (que como se dijo cubre en algunos casos las capas sesión, presentación y aplicación del modelo OSI) se definen los programas que prestan los servicios básicos de computación interactiva remota, transferencia de archivos y correo electrónico. También se definen en este nivel los servicios agregados en los últimos años a los ambientes de red: llamadas a procedimientos remotos y sistemas de archivos sobre la red.

Comenzamos la explicación con los tres primeros. Algunas veces se habla de protocolos de aplicación, puesto que no se especifica un programa que será ejecutado en una sola máquina, sino que se trata de un sistema distribuido en cierta medida. Es preciso concertar el trabajo de aplicaciones en máquinas distintas, así que debe existir un protocolo.

El primero que se discute es el servicio de computación interactiva remota. La posibilidad de abrir una sesión de trabajo en una máquina remota, desde una máquina local, para ejecutar cualquier aplicación en aquella es lo que se conoce como computación interactiva remota. También se le conoce como servicio de terminal sobre la red. Esto por cuanto la máquina local se comporta como un terminal de la otra, mientras están conectadas solamente a través de la red (y no con los esquemas tradicionales para terminales) (*)

En Internet (en TCP/IP) ese servicio se suministra a través del protocolo de aplicación TELNET. Como muestra la lámina, TELNET permite convertir (usando el cliente TELNET) a una máquina en terminal y conectarla vía TCP, con otra máquina que le sirve de anfitrión (usando el servidor TELNET).

La aplicación TELNET cliente captura cada tecla que es presionada por el usuario y las envía a la máquina remota. Esta las interpreta y las devuelve a la pantalla del "terminal". (**)

TCP/IP - 45: Telnet. (*) Indique una ventaja de la computación interactiva remota. (**) Usando la lámina explique el recorrido de un caracter, una vez que en el terminal se presiona la tecla correspondiente. ¿Qué ocurre con el tráfico de la red?.

Active la aplicación telnet en su máquina UNIX (sin parámetros). Su instructor lo guiará con los comandos internos para que convierta a su máquina en terminal de otra. Cuando su máquina sea un terminal de otra, presione la combinación de teclas CTRL ']'. ¿Qué ocurre?.

¿Qué parámetros requiere el programa telnet?

FIGURA 95.

RLOGIN.

El hecho de que cada caracter (o línea) deba viajar por la red antes de desplegarse en la pantalla del terminal, puede considerarse un desperdicio del ancho de banda .

Entre máquinas UNIX (es decir cuando la que se convierte en terminal también es una máquina UNIX) existe una alternativa a telnet, que resuelve el problema que se bosquejó. El procesamiento de la salida (eco en pantalla) es tramitado por la máquina local.

Dicho programa, denominado rlogin (remote login) puede configurarse para que las condiciones de trabajo de un usuario sean duplicadas, tanto como sea posible, en la máquina remota (la mismas variables y conchas de trabajo, el mismo identificador).

El programa rlogin es sólo el primero de una serie de herramientas UNIX creadas para facilitar el procesamiento remoto interactivo, inclusive sin tener que conectarse explícitamente al otro sistema, son los comandos "r", llamados así porque su sintaxis es similar a la de sus equivalentes locales, anteponiéndoles una r. La otra variante es que, cuando se requiere especificar un camino de directorios, se antepone a este el nombre de la máquina involucrada.

TCP/IP - 46: Comandos r.

Conecte su máquina UNIX a otra usando el comando rlogin. Desconéctela.

Ejecute el comando rsh máquina ps. Explíquelo.

Copie un archivo entre dos máquinas UNIX con el comando rcp. (Ind. consulte la sintaxis con man).

FIGURA 96.

File Transfer Protocol FTP.

Es el protocolo de aplicación por excelencia. Un programa diseñado específicamente para permitir el intercambio o transferencia de archivos entre máquinas en Internet. Funciona sobre la plataforma TCP lo que significa que la integridad de la data está resguardada. Fue creado originalmente para ser usado por otros programas (actualmente existe todo un sistema de intercambio de información de propósito general conocido como World Wide Web, creado en Europa (CERN) y que emplea FTP como soporte básico). A pesar de ello, sus comandos internos, mucho menos crípticos que los UNIX tradicionales, pueden ser usados por humanos e inclusive colocados en archivos (programas en shell).

Como muestra la lámina, FTP es también más complicado que TELNET (de hecho, usa el esquema TELNET para la conexión de control). Se usan dos conexiones TCP: una para control y otra para datos.

TCP/IP - 47: FTP

Ejecute el comando ftp (sin parámetros). Averigue cuales son los comandos internos disponibles (Ind. el "?" también es un comando).

Describa el efecto de los siguientes comandos internos del ftp: open, user, get. mget, put, mput, prompt, binary, ascii, close, quit, bye..

FIGURA 97.

Sistemas de Archivos Distribuidos.

La primera etapa en la implantación de Sistemas Distribuidos es la distribución de los datos. Quizás el paso fundamental para construir sistemas operativos de red es la adopción del mecanismo para compartir los datos desde otros computadores. Lo que parezca haber convertido a UNIX en un Sistema Operativo de Red es la inclusión en las nuevas versiones de mecanismos y estructuras con ese propósito. Se pueden mencionar tres de esos mecanismos, los dos primeros especialmente diseñados para UNIX. El último es, en sí mismo, un Sistema Operativo de Red que puede implantarse sobre UNIX.

Esos mecanismos para acceder a sistemas de archivos a través de las redes son:

RFS (Remote File System):

una extensión del sistema de archivos tradicional de UNIX construida sobre STREAMS, para permitir el acceso a través de las redes RFS 1.0 fue introducido por AT&T en el UNIX System V Release 3 en 1986. La idea general es convertir los sistemas de archivos en recursos que pueden ser montados desde/en otras máquinas.

NFS: (Network File System):

También es un esquema para permitir a máquinas montar sistemas de archivos UNIX remotos en su estructura local de archivos. NFS fue desarrollada por Sun Microsystem e introducida en 1984 al mercado. Fue construida con la plataforma RPC y su objetivo principal es permitir a computadores clientes NFS, montar los sistemas de archivo UNIX en su estructura local.

LAN MANAGER:

Es un sistema operativo de red, original de Microsoft, que emplea una estructura protocolar para prestar servicios que permiten compartir archivos a máquinas clientes enlazadas a ciertos recursos de disco.

En este curso la discusión se centrará en el NFS que se ha convertido en un estándar de facto en las redes UNIX. La lámina muestra de como el NFS extiende la interfaz habitual para manipular el sistema de archivo (llamadas al sistema) para que opere sobre una red.

Los tópicos calientes en los sistemas de archivos distribuidos son: transparencia en la ubicación, cacheing de datos, servidores que recuerden su estado, seguridad de los datos transmitidos y la creación de dominios administrativos.

FIGURA 98.

Network File System. Definición y Características

Revisión del sistema de archivo

Para poder explicar con claridad el funcionamiento del NFS es necesario precisar algunas ideas acerca del sistema de archivo UNIX.

La lámina muestra como el sistema de archivo UNIX implementa la llamada matriz de seguridad para controlar el acceso de los usuarios a la información.

La tabla inferior muestra las extensiones que NFS hace a ese esquema de permisología de acceso al sistema de archivo:

Modos Significado 0040000 Esto es un directorio 0020000 Esto es un archivo especial tipo caracter 0060000 Esto es un archivo especial tipo bloque 0100000 Esto es un archivo normal 0120000 Esto es un enlace simbólico 0140000 Esto es un socket con nombre 0004000 Establecer el userid para ejecutar 0002000 Establecer el groupid para ejecutar 0001000 Guardar el texto salvado después de uso

Observen que en ningún caso se incluyen previsiones especiales para el acceso concurrente a un archivo. Sin embargo NFS controla la exclusión mutua en el acceso a un archivo. El contenido de un archivo estará determinado por el último acceso de escritura que se haya realizado sobre él.

TCP/IP - 50: Revisión del sistema de archivos.

El Laboratorio deberá tener instalados algunos sistema de archivos a través de la red. Su instructor le guiará en un recorrido por un sistema de archivo UNIX conformado a partir de directorios locales y remotos. ¿Nota alguna diferencia en el acceso y en la permisología?.

FIGURA 99.

Sistemas de archivos virtuales

Sun MicroSystem modificó la estructura normal del UNIX para poder conservar la transparencia en el acceso a archivos remotos vía NFS, inclusive a nivel del programador.

La idea fundamental consiste en separar la interfaz con el sistema de archivo, del propio sistema de archivo. Esto le permite utilizar una interfaz genérica para manipular archivos sin importar su ubicación. La estructura tradicional de control de un archivo: el inodo, es reemplazada por otra: el VNODO.

Se sigue usando el INODO sólo cuando se refiere a una llamada al sistema local. en otros casos se emplean otras estructuras similares, pero con la información adecuada. Para el acceso a la red se usa el RNODO.

FIGURA 100.

Exportando sistemas de archivos

Demonios involucrados (nfsd, biod, rpc.lockd, rpc.statd, rpc.mountd)

Como era de esperarse en ambientes UNIX, existen un conjunto de demonios que definen al NFS, como servicio de redes. Estos demonios están organizados según una parte cliente y una parte servidor. Veamos:

nfsd [num. de sesiones concurrentes]:

Este demonio es el encargado de "atender" las solicitudes de servicio, generadas por los clientes. Debe señalarse que este demonio es el que realiza el servicio como tal. Los trámites de solicitud y generación de las conexiones, para asociar los directorios solicitados a la estructura de directorios del cliente, corren por cuenta de otro demonio. Similar al caso del inetd, en el que este se encargaba de procesar las solicitudes y pasar el trabajo a los demonios correspondientes, nfsd está limitado a ser precisamente el demonio encargado de prestar el servicio. A modo de referencia, el nfsd viene a ser similar a un demonio de servicio como el ftpd o el telnetd. Este demonio solo es ejecutado en el servidor

biod [num. de sesiones concurrentes]: Hemos planteado al NFS como una aplicación orientada a la filosofía cliente/servidor. El demonio nfsd, define el sector server de la aplicación y el demonio biod define a la parte cliente de la misma. Este programa es entonces el encargado de interactuar con el nfsd, cada vez que un usuario activa algún comando vinculado con el manejo del sistema de archivos, que ha sido lógicamente trasladado a su máquina. Este demonio es ejecutado en los clientes.

rpc.mountd

El rpc.mountd resulta funcionalmente similar al inetd. En otras palabras, este es el programa que procesa las solicitudes de servicio NFS y las "pasa" al demonio nfsd, para que entre en un proceso de comunicación directa con el programa cliente (biod). Este demonio es ejecutado en el servidor.

rpc.lockd

Este demonio es el encargado de administrara los bloqueos de archivos, solicitados por los clientes y es ejecutado tanto en clientes como en servidores

rpc.statd

Demonio dedicado al seguimiento de los servicios prestados durante sesiones NFS. Es ejecutado en ambos sectores de la aplicación.

FIGURA 101.

Comandos y archivos necesarios (exportfs, /etc/exports, /etc/xtab)

Los demonios listados en la página anterior, definen el conjunto de programas especiales que deben ser activados, para prestar y recibir servicios de archivos bajo red. Resta por definir cómo se da el proceso de activación de los mismos. Veamos los archivos y los comandos que deben ser utilizados, en tiempos de inicialización de los sistemas.

Archivo /etc/exports:

Este archivo define los directorios que el NFS debe exportar a los clientes.

Comando /etc/exporfs:

Este comando se encarga de informar al NFS el conjunto de directorios exportados. Previa lectura del archivo /etc/exports, el comando exporfs vacía, en un archivo especial, la información relativa al conjunto de directorios a facilitar a los clientes.

Archivo /etc/xtab:

Este es el archivo que el demonio nfsd lee para reconocer el listado de directorios exportados. Editando el archivo /etc/exports

Este archivo define, según se dijo, la información relevante para la definición de los directorios a exportar a la red. Además de lo anterior, el archivo define que máquinas pueden accesarlos y la permisología según la cual acceder a estos. Supongamos que deseamos exportar los directorios /bin, /var, /usr/man, del servidor Borges. En tal caso, las líneas de código a editar en el archivo deben ser similares a:

/var -ro /usr/man /bin -rw=Otero

Según puede observarse, el directorio /var puede ser montado por cualquier cliente con permiso de solo lectura. El directorio /usr/man puede ser montado por cualquier usuario y ser utilizado tal como si fuera un directorio local. En cuanto al directorio /bin, se observa que tiene permiso de lectura-escritura, pero solo es accesible al computador Otero.

FIGURA 102.

Dónde y cómo se activan los Demonios NFS

El uso de scripts es la pauta según la cual se activan los demonios NFS. Veamos algunas líneas modelo a insertar en el archivo /etc/rc.local:

Clientes:

# # Inicio de los demonios clientes (también se activan en el servidor) # if [ -f /usr/etc/biod -a -f /usr/etc/rpc.statd -a -f /usr/etc/rpc.lockd ]; then biod 8 rpc.statd & rpc.lockd & fi # # Servidores:

# # Inicio de los demonios servidores # if [ -f /etc/exports ]; then > /etc/xtab /etc/exports -a nfsd 8 & rpc.mountd & fi # #

Discuta con su instructor, el contenido de las líneas de código recien listadas.

FIGURA 103.

Enlazado persistente a sistemas de archivos

Sistemas de archivos disponibles (el comando showmount) Es posible indagar acerca de los directorios exportados en el servidor. Esto permite conocer con exactitud, cuáles directorios se pueden enlazar y cuáles permisologías están permitidas. El comando del UNIX que permite esto es el showmount.

Si ejecutamos el comando en Borges, del siguiente modo:

# showmount -e

El listado a recibir debería ser similar a:

export list for Borges: /var borges /usr/man (everyone) /bin -rw=Otero

Los comandos mount y umount

Los clientes requieren de comandos específicos, para activar y desactivar el montaje de los directorios compartidos por los servidores NFS. Estos comandos son el mount y el umount. Mediante éstos, los clientes generan las solicitudes de expansión de sus sistemas de archivos y definen los directorios a anexar, y la ubicación especifica en el sistema de archivos local donde deben ser montados los directorios remotos. De nuevo, veamos algunas líneas modelo:

Si deseamos enlazar el directorio de Borges, /usr/man, el comando a ejecutar es:

# mount borges:/usr/man /tmp /man

En este caso hemos solicitado el montaje del /usr/man de Borges, en el directorio local /tmp /man (este debe ser creado con anterioridad).

FIGURA 104.

El archivo /etc/fstab y el enlazado persistente a servidores NFS

Debido a que es práctico enlazar automáticamente aquellos directorios de uso común, existe un archivo que permite especificarle al mount, en los computadores clientes, cuáles directorios montar. Así basta ejecutar el comando mount en tiempos de inicialización (boot-time), especificándole la ubicación del archivo a leer para ejecutar el proceso. El archivo de especificación, puede ubicarse como, según sea la versión de UNIX, fstab, mntab o mtab, en directorio /etc/

La configuración de este archivo es sencilla, debido a que basta ejecutar el comando mount desde el shell, con la opción correspondiente para la creación del archivo /etc/fstab. Una vez creado, basta incluir el comando mount en los scripts del sistema, a fin de que se realice el enlazado persistente a los directorios especificados en el archivo /etc/fstab.

En nuestro caso, ya que tenemos los enlaces activados a Borges, basta solicitar al mount, que vacíe la información necesaria para el enlazado persistente, en el archivo ya mencionado. En este caso basta ejecutar el comando mount del siguiente modo:

# mount -p /etc/fstab

Si realizamos un listado del archivo /etc/fstab, su contenido debe ser:

# grep nfs /etc/fstab borges:/usr/man /tmp /man nfs rw 0 0 * Discuta con su instructor, el listado anterior.

FIGURA 105.

Recapitulando sobre el cómo trabaja NFS Son dos las tareas fundamentales en un ambiente NFS. Exportar los sistemas de archivos (para que otros los puedan usar) y montarlos (como parte de una estructura local).

Cuando una máquina servidor NFS arranca, debería ejecutarse automáticamente un programa llamado exportfs. Dicho programa pone a disposición de la red, los directorios listados en el archivo /etc/exports, con las restricciones indicadas. Igualmente se activan el demonio rcp.mountd (*) y varias instancias nfsd. Estos demonios se dedican a esperar las solicitudes de servicios NFS de los clientes.

Cuando el cliente arranca, el programa mount (que debe estar en los archivos de arranque) revisa el archivo /etc/fstab. El programa trata de establecer una conexión con el demonio mountd para montar los sistemas de archivos que estan listados en /etc/fstab. El demonio valida el acceso de ese cliente y si todo va bien, le devuelve un descriptor que el cliente recibe en el núcleo de su sistema operativo. Dicho descriptor es un número que no tiene sentido para el cliente (no debe tenerlo). El servidor NFS lo usa como dirección de un sistema de archivo, y copia el archivo particular.

Tan pronto como el cliente recibe al descriptor se lo entrega a su sistema de archivo virtual. Este crea un VNODE/RNODE que representará localmente a la estructura direccionada por el descriptor en el servidor. El servidor NFS toma después el control y continúa validando los derechos de acceso del usuario a los archivos y directorios.

TCP/IP - 52. Como trabaja NFS. (*) ¿Qué hace este demonio?.

FIGURA 106.

Correo Electrónico (SMTP).

Los creadores del Simple Mail Transfer Protocol (SMTP) proclaman que, además de ser uno de los protocolos de intercambio de correo más extendidos del mundo, es también un sistema de alta confiabilidad. La razón es que el SMTP (o mejor dicho los programas que lo implementan) es un sistema de entrega fin a fin (end to end delivery system). "Cada mensaje de correo permanece en la máquina desde donde se envía, hasta que sea copiado exitosamente en la máquina receptora". Esta máquina receptora debería ser el hogar del destinatario, aunque no siempre es así.

No siempre es así porque en ambiente Internet algunas veces se recurre a las pasarelas de correo (nombradas en la sección acerca de DNS) que sirven de intermediarios.

Es importante mencionar que el SMTP es sólo un protocolo. Un sistema de correo tiene otros componentes.

1.- El formato de direcciones: En Internet el formato de direcciones tiene la siguiente estructura:

buzon@dominio

Donde buzon es el nombre del recipiente del correo en ese dominio (vale decir, el nombre del usuario). En el dominio generalmente no se incluye el nombre de la máquina. Esto porque el SMTP consulta al DNS y obtiene de los registros MX, el nombre de aquellas máquinas que reciben el correo de ese dominio.

2.- El front-end. Es la aplicación que interactúa con el usuario. En UNIX se tienen varios programas. El más conocido (y uno de los más completos) es mail. Este programa le permite al usuario construir el mensaje y después lo coloca en un área temporal (directorio de spooling). Todo el procesamiento es controlado por el usuario a través de comandos internos que también permiten la revisión y edición de mensajes recibidos.

3.- El despachador (deliver). En UNIX tradicionalmente este programa es el sendmail, que se encarga de tomar el mensaje del área de spooling y de entregarlo en el sistema destino. Para ello debe tomar algunas decisiones de enrutamiento, especialmente afectadas por el formato de la dirección de correo. Dicho formato es procesado de acuerdo a ciertas reglas las cuales, junto con otros parámetros de configuración, son almacenadas en el archivo sendmail.cf.

TCP/IP - 53: Correo electrónico. Si el sistema en su laboratorio emplea el sendmail, su instructor le mostrará el archivo de configuración. Averigue si el sendmail está activo en su sistema. Si es así ejecute el sendmail en modo de rastreo o depuración (Ind. Consulte al instructor). Averigue a donde van los mensajes cuando mail los envía.

FIGURA 107.

Utilizar el sendmail como despachador de correo generalmente es cuestión de arrancarlo en forma de demonio, utilizando la configuración por omisión que se propone en el sendmail.cf. La situación se complica cuando se debe despachar correo a redes con formato de direccionamiento diferente (como UUCP, Internet y X.400).

Otro correo UNIX.

Precisamente para enfrentar el compromiso de distintos sistemas de correo, se ha propuesto un sistema alternativo al SENDMAIL para el despacho y recepción de mensajes. Se denomina Multichannel Memorandum Distribution Facility (MMDF).La interfaz de canal de MMDF cuenta con una especificación estándar a la que se someten ya varios productos comerciales. El SCO MMDF es uno de esos (SCO MMDF es el sistema de correo de ambientes SCO UNIX-OPEN DESKTOP sobre la plataforma INTEL).

En el MMDF un canal es una vía de acceso a un tipo de red (vale decir a un tipo de correo). Cada canal tiene sus propios archivos de configuración (llamados tablas) para especificar parámetros del canal (*.chn) y dominios sobre cada uno (*.dom). Tiene además sus propios programas para envío y recepción (uucp para en canal UUCP, smtpd para el canal SMTP).

El archivo que controla la configuración general del MMDF, define los canales a utilizar y especifica cada tabla (archivo) del sistema es el mmdftailor. Este archivo es mucho más amigable que el sendmail.cf.

Otra de las ventajas del MMDF sobre el esquema tradicional es la separación de los programas por canal. Esto permite que cada tipo de correo sea configurado, entonado y supervisado en forma separada. Incluso permite agregar nuevos sistemas de correo sin detener los que están funcionando.

Finalmente el MMDF permite definir aliases (también se puede con el sendmail) y administrar listas. Las lista son uno de los recursos de difusión de información más usados de Internet. Son el equivalente a una subscripción a un periódico o revista. Las láminas muestran como funciona el correo UNIX con el MMDF.

TCP/IP- 54. MMDF. Si su sistema es SCO UNIX, revise el directorio /usr/mmdf. Ejecute el comando deliver -w -ccanal. (Ind. Consulte al instructor).

FIGURA 108.

---