| Aprendiendo a Aprender Linux: Guías para colegios con plataforma de referencia S-Helio 1.1 | ||
|---|---|---|
| Anterior | Capítulo 6. Administración de una red con Linux | Siguiente |
Indicadores de Logros
Puede configurar talk, finger, ftp y telnet en cada computador de la red.
Puede configurar un servidor DNS y usarlo en los clientes.
Puede distribuir utilización de discos duros usando NFS, de acuerdo a las sugerencias de la plataforma de referencia.
Puede instalar y configurar el servicios NIS en la plataforma de referencia S-Helio 1.1.
Configura el servicio de correo de acuerdo a la plataforma de referencia.
Configura el servicio de ssh de acuerdo a la plataforma de referencia.
Configura el servicio de CVS de acuerdo a la plataforma de referencia.
Configura el servicio de ftp de acuerdo a la plataforma de referencia.
Configura el servicio de web de acuerdo a la plataforma de referencia.
Configura una impresora en red.
Puede instalar y configurar el servidor Apache en la plataforma de referencia.
Cómo se presentó en la lectura de la sección Redes, protocolos e Internet cada servicio que su sistema ofrezca requiere un proceso daemon que esté pendiente de atender conexiones. Para disminuir el número de procesos que deberían estar activos esperando conexiones por cada servicio, el programa inetd que se inicia durante el arranque de su sistema (con /etc/init.d/inetd, ver Inicialización del sistema) espera conexiones en diversos puertos y cuando recibe una inicia el daemon apropiado.
Nombre que recibe un proceso que actua como servidor de un protocolo y espera conexiones de clientes.
Este programa atiende diversos puertos TCP/IP y ejecuta el daemon apropiado.
inetd se configura en el archivo /etc/inetd.conf que puede referenciar servicios por nombres si estos están listados en /etc/services o en /etc/rpc y protocolos listados en /etc/protocols. Debian inlcuye versiones de estos archivos listas para servir telnet, talk, finger, hora local y correo (smtp).
Archivo de configuración de inetd
Cada línea del archivo /etc/inetd.conf puede ser un comentario (si comienza con el caracter "#") o puede ser análoga a:
smtp stream tcp nowait mail /usr/sbin/exim exim -bsque indica que el servicio smtp, se maneja con conexiones[1] tipo stream del protocolo tcp, sin espera. Cada vez que haya una conexión para este servicio se iniciará el programa /usr/sbin/exim con argumentos[2] exim -bs desde la cuenta mail. Otras posibilidades para cada parte son:
El servicio es uno de los especificados en /etc/services o puede ser una dirección precedida por un puerto, o uno de los servicios RPC especificados en /etc/rpc.
stream, dgram para datagramas, raw para conexiones puras, rdm para reliable delivered messages o seqpacket para paquetes secuenciados.
Debe ser uno de los disponibles en el archivo /etc/protocols, por ejemplo tcp o udp.
Puede ser wait o nowait, indica si inetd debe esperar a que el proceso termine para recibir nuevas conexiones en el mismo puerto o no. Esto depende del tipo de servicio, la mayoría no requiere espera (porque emplean varios hilos [3] que emplean otro puerto por cada conexión), aunque son excepciones talkd, biff y tftp. Después de wait o nowait puede venir separado por un punto el máximo número de conexiones que inetd debe aceptar para el servicio en 1 minuto (por defecto 256).
Usuario a nombre del cual se iniciará el proceso.
| Aviso |
Por seguridad, es recomendable ejecutar daemons desde cuentas diferentes a root |
Ruta del programa que atenderá la conexión. Si se trata de un servicio interno se usa internal. Los servicios internos son echo que responde con los mensajes que recibe (útil para medir y probar como se especifica en el RFC 862); discard que descarta todo dato que recibe (también útil para probar y medir como se describe en el RFC 863); chargen definido en el RFC 864 responde generando caracteres hasta que la conexión sea cerrada; daytime que de acuerdo al RFC 867 informa fecha y hora en formato entendible para humanos time hora actual en formato para máquinas de acuerdo al RFC 868.
El archivo /etc/inetd.conf, en una LAN como la especificada en nuestra plataforma de referencia (sin conexión a Internet) incluye:
telnet stream tcp nowait telnetd.telnetd /usr/sbin/tcpd /usr/sbin/in.telnetd talk dgram udp wait nobody.tty /usr/sbin/tcpd /usr/sbin/in.talkd finger stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/in.fingerd smtp stream tcp nowait mail /usr/sbin/exim exim -bs
Después de modificar este archivo puede reiniciar inetd, tal como haría con otros servicios que se inician al arranque del sistema (ver Inicialización del sistema):
/etc/init.d/inetd restart
o envíando la señal SIGHUP al proceso. (ver Señales).
En este archivo se configuran las máquinas a las que tcpd no les da acceso.
Note que la ejecución de telnet, finger y talk se hace con el programa tcpd. Este programa puede manejar conexiones de diversos servicios, registrar las conexiones en la bitácora y agregar un mínimo de seguridad incluyendo listas de control configurables en los archivos hosts.allow y hosts.deny. En estos archivos se configuran con patrones los servicios, computadores y/o usuarios pueden iniciar conexiones, y los que no. Cuando recibe una solicitud de conexión tcpd primero lee los patrones de /etc/hosts.allow si ninguno concuerda con la conexión intenta con los de /etc/hosts.deny y si ninguno concuerda permite la conexión. Para permitir acceso a estos servicios sólo a computadores en la red privada /etc/hosts.deny podría ser:
ALL: ALL
y /etc/hosts.allow:
ALL: 192.168.0.0/255.255.0.0
Con este protocolo de soporte pueden asociarse a direcciones IP nombres dentro de un árbol de nombres.
DNS permite asociar nombres a direcciones IP, esto es importante para facilitarnos la identificación de computadores en una red.
Como se describe en el RFC 1034, DNS puede verse desde 3 puntos de vista:
Un usuario emplea nombres de dominios DNS al solicitar conexiones con máquinas cuyos nombres describen posiciones en un árbol de nombres. Por ejemplo structio.sourceforge.net.
Los programas emplean un resolvedor de nombres. Este resolvedor recibe nombres con la estructura antes descrita, busca en un depósito [4] de nombres, de requerirlo trata de conectarse con uno o más servidores de nombres que puedan responder la consulta, envia la consulta y analiza la respuesta.
Se trata de uno de los componentes del servicio DNS, que recibe consultas de programas y trata de resolverlas acudiendo a un deposito de nombres local o contactando servidores.
Un servidor de nombres, es un programa que además de atender solicitudes de resolvedores, mantiene tablas donde asocia nombres con direcciones IP de algunas zonas del árbol de nombres. También mantiene direcciones de otros servidores de nombres que puede emplear para actualizar las tablas de las zonas que mantiene y para obtener información de otras zonas.
Los nombres son independientes de las IPs, estos conforman un árbol dividido en zonas manejadas por diversos servidores de nombres distribuidos en todo el mundo y conectados a Internet [5], la raíz de este árbol se denota con el carácter '.'. Un nombre se compone de partes separadas por el caracter '.', cada parte se compone de letras mayúsculas o minúsculas sin distinción (preferiblemente menos de 12), eventualmente números y eventualmente guiones. Las partes del nombre indican la ruta entre el nodo y la raíz, de forma análoga a la ruta de un archivo del sistema de archivos, sólo que un nombre DNS completo comienza por la parte que corresponde a la hoja y termina en la parte que corresponde a un hijo de la raíz. Por ejemplo en la dirección structio.sourceforge.net la parte net es un nodo descendiente de la raíz del árbol de nombres. A la parte descendiente de la raiz se le llama dominio de nivel superior (TLD - Top Level Domain) y puede ser dos letras que identifiquen uno de los 244 paises registrados de acuerdo a ISO 3166 (por ejemplo .co en el caso de Colombia) o por ejemplo una de las siguientes:
Industria de transporte aéreo
Miscelánea
Comercial
Cooperativas
Educativo
Gubernamental de EUA
Información
Organizaciones internacionales
Militar de EUA
Museos
Individuos
Redes
Organizaciones
El resolvedor de nombre es un conjunto de funciones, que los diferentes programas emplean cuando requieren determinar la IP asociado con un nombre (resolución de nombres) o el nombre asociado con una IP (resolución inversa).
Puede emplear el resolvedor de nombres desde la línea de comandos, por ejemplo con el programa dig (incluido en el paquete dnsutils). Algunos de sus usos se ejemplifican a continuación:
Consulta todos los registros disponibles para el nombre structio.sourceforge.net usando el servidor configurado en /etc/resolv.conf
La misma consulta anterior pero en el servidor de nombres ns1.valinux.com (usa el resolvedor local para determinar la IP de ese servidor)
Busca sólo registros tipo T_TXT, es decir con texto arbitrario. Otras posibilidades son a (T_A) dirección; any (T_ANY) todo tipo de información; mx (T_MX) intercambiadores de correo; ns (T_NS) servidores de nombres; soa (T_SOA) zona de autoridad; hinfo (T_HINFO) información de la máquina; axfr (T_AXFR) zona de transferencia.
Para especificar resolución inversa. También podría emplearse dig 10.206.25.192.in-addr.arpa
En Internet puede consultarse información sobre el registro de un dominio (incluyendo datos de quien lo registro) empleando whois, o información sobre el nombre de máquina y dominio del computador que usa con hostname (ver Comandos y programas útiles al hacer scripts).
Archivo de configuración del resolvedor de nombres, donde pueden especificarse direcciones IP de servidores DNS.
El resolvedor de nombres incluido en Debian puede resolver nombres empleando el archivo /etc/hosts, servidores de nombres o NIS. Se configura en los archivos /etc/resolv.conf, /etc/host.conf y si se usa NIS también en /etc/nsswitch.conf. El primero ( /etc/resolv.conf) contiene direcciones de servidores de nombres y configuración para buscar en ellos. Por ejemplo en nuestra plataforma de referencia si el servidor tiene IP 192.168.1.1 y en este se configura un servidor de nombres, en todos los computadores de la red el archivo /etc/resolv.conf debe incluir:
search micolegio.edu.co nameserver 192.168.1.1
Si conectará su sistema a Internet podría incluir más servidores de nombres especificando cada uno con líneas iniciadas con la palabra nameserver (podría especificarlos a continuación de su propio servidor para que la información de su servidor tenga prelación dentro de la LAN). La línea search indica dominios con los cuales completar direcciones (por ejemplo purpura será completado como purpura.micolegio.edu.co). El archivo /etc/host.conf de todos los computadores puede ser:
order hosts,bind multi onque indica en la primera línea el orden para resolver nombres, en este caso como hosts está primero, resolverá nombres primero revisando el archivo /etc/hosts y en segundo lugar empleará los servidores de nombres configurados en /etc/resolv.conf (también podría especificarse nis en caso de que se resolvieran dominios usando NIS). La línea multi on indica que el resolvedor debe retornar todas las direcciones IP que pueda encontrar para un nombre en el archivo /etc/hosts y no sólo la primera (útil en una red multihomed con varios IPs para una misma máquina). Cómo en nuestra plataforma de referencia empleamos DNS para resolver nombres de dominios, el archivo de configuración de NIS (/etc/nsswitch.conf) debe incluir la línea (ver Servicio NIS):
hosts: files dns
que de forma análoga a las líneas en /etc/hosts.conf indica buscar primero en /etc/hosts y después usar los servidores de nombres DNS.
Los resultados de las consultas que un resolvedor de nombres hace a un servidor de nombres, son registros de recursos (RR del inglés Resource Records). Este mismo tipo de registros se usa para configurar un servidor de nombres. Un ejemplo es:
servidor.micolegio.edu.co. IN A 192.168.1.1
A 128.9.0.32
micolegio.edu.co. MX 10 servidor.micolegio.edu.co
que describe información de nombres Internet (indicado por la
sigla IN de la primera línea y asumida por
defecto en las demas). Las dos primeras líneas son tipo
dirección (el tipo A --de
Address-- lo indica), mientras
que la tercera identifica un intercambiador de correo para el
dominio micolegio.edu.co (tipo
MX --de Mail
Exchange). Los dos primeros registros
presentan información sobre servidor.micolegio.edu.co, la ausencia de otro nombre
al comienzo de la segunda línea indica que es una segunda
dirección para servidor.micolegio.edu.co. Los registros tipo dirección permiten
asociar una IP con un nombre, así en el
ejemplo anterior el nombre servidor.micolegio.edu.co se referirá a dos
direcciones IP. Los registros tipo
MX identifican computadores que pueden
resolver direcciones de correo para un dominio, cada uno con un
valor de preferencia (empleando para determinar que servidor se
emplea primero si hay varios intercambiadores de correo para un
mismo dominio). Note que los nombres de dominios completos
terminan con un punto, esto es un requerimiento propio de la
configuración como se explica más adelante.
Los registros DNS de este tipo permiten identificar computadores que pueden resolver direcciones de correo para un dominio (es la abreviación de Mail exchanger).
Otros tipos pueden ser: CNAME que identifica el nombre principal de un alias, HINFO que identifica CPU y sistema operativo de un computador, NS que marca un servidor de nombres autoritario para un dominio (autoritario quiere decir que su respuesta es la que se considera más acertada en caso de que otros servidores den otras respuestas); PTR para referenciar otra parte del espacio de nombres de dominio; SOA (start of authority) para marcar el comienzo de una zona de autoridad.
Los registros DNS de tipo PTR permiten hacer resolución inversa, toda dirección IP debe especificarse invertida y terminar con el postfijo ...
Además de asociar nombres a IPs, pueden asociarse IPs a nombres para permitir hacer resolución inversa (dada la IP encontrar el nombre). Para lograrlo se emplean registrros PTR, usando como nombre de máquina la IP tras invertir el orden de los 4 bytes que la conforman y seguida de IN-ADDR.ARPA. Por ejemplo:
1.2.168.192.IN-ADDR.ARPA. IN PTR servidor.micolegio.edu.co
Las consultas formuladas por los resolvedores de nombres que no pueden ser resueltas por el depósito local del resolvedor ni con otros mecanismos (e.g. /etc/hosts), pueden ser contestadas por uno de los servidores siguiendo el algoritmo descrito en el RFC 1034:
El resolvedor contacta a uno de los servidores configurados.
El servidor busca la zona que sea ancestro más cercano de la información buscada.
Si la información buscada está entre las zonas manejadas o referenciadas por el servidor, busca entre ellas hasta encontrar la información o hasta encontrar un registro que referencie otro servidor de nombres autoritario o en último caso reporta que el dominio no fue encontrado.
Si la información no está en las zonas manejadas por el servidor (o está en una subzona), busca en un deposito local.
Si no hay información en el deposito local y está en modo recursivo, empleando su resolvedor de nombres consulta al servidor encontrado en el paso 3 y retorna la respuesta además de almacenarla en el deposito. En modo iterativo sólo responde el nombre del servidor encontrado en el paso 3.
Una vez el resolvedor consigue la información, la almacena temporalmente en un depósito local.
Para distribuir la información en los servidores de nombres, el árbol de nombres se divide en zonas, cada una de las cuales puede ser atendida con registros autoritarios por un servidor primario. Para respaldar la información de servidores primarios, hay servidores secundarios que copian periódicamente la información y también proveen información autoritaria de la zona.
Para hacer consultas a servidores de nombres o para recibir respuestas, se emplean los puertos UDP 53 y TCP 53 (como puertos de entrada y de salida, aunque para la comunicación con algunos programas cliente pueden requerirse puertos no privilegiados (TCP 1024 y UDP 1024).
Archivo principal de configuración de bind
Entre los servidores DNS disponibles en Internet están djbdns y bind. Aunque djbdns es más seguro, bind (paquete bind, documentación en paquete bind-doc) es más popular y será el servidor que describimos en esta sección. La instalación por defecto de este paquete dejará una configuración sencilla que consta de:
Archivo de configuración principal que define zonas y opciones del servidor.
Que definen la zona localhost (interfaz loopback) y su zona inversa (i.e direcciones 127.*.*.*)
Que referencia los servidores de la raíz del árbol de nombres.
Que incluyen registros para hacer resolución inversa de direcciones de la forma 0.*.*.* (también localhost) y 255.*.*.* (broadcast).
Para configurar una zona para su red local, es preferible que emplee un nombre de dominio que no esté registrado en Internet (aún si no planea conectarse a Internet a corto plazo). Cree un archivo para su zona, digamos /etc/bind/db.micolegio.edu.co y otro para resolución inversa en su red, digamos /etc/bind/db.192.168.1 (que resolverá direcciones de la forma 192.168.1.*).
En el archivo de configuración principal (/etc/bind/named.conf), debe agregar entradas para la zona. Debe tener líneas como las siguientes, aunque quitando o agregando comentarios de ser necesario (son comentarios los textos iniciadas con // hasta final de línea o porciones encerradas entre /* y */ o líneas iniciadas con el caracter #).
options {
directory "/var/cache/bind";
forwarders {
//Remplazar por dirección del servidor DNS del proveedor si lo hay
// o comentar esta sección. Esta dirección será usada en caso
// de que este servidor no tenga un registro en una zona manejada
// por él o en el deposito.
1.2.3.4;
};
// Quitar comentarios si se hacen conexiones esporadicas a Internet
// con un modem para actualizar zonas
// dialup yes
}
logging {
category lame-servers { null; };
category cname { null; };
};
// Las siguientes líneas se comentan si la red no se conecta a
// Internet
zone "." {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
zone "micolegio.edu.co" {
type master;
file "/etc/bind/db.micolegio.edu.co";
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.1.168.192";
};
Note que se configuran las nuevas zonas como tipo master porque el servidor podrá dar respuestas autoritarias sobre estas.
Los archivos con registros de recursos de cada zona, pueden tener comentarios en líneas que comienzan con ';'. El archivo /etc/bind/db.local que define una zona para la interfaz loopback ---que siempre tiene dirección 127.0.0.1 y nombre localhost--- sería:
@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresco 86400 ; Reintento 2419200 ; Expiración 604800 ) ; TTL Mínimo @ IN NS localhost. @ IN A 127.0.0.1
Note que se define una zona sobre la que este servidor tiene autoridad usando un registro SOA; cómo el registro ocupa más de una línea se emplean paréntesis para delimitarlo. El signo '@' es una abreviación del nombre de dominio base, es decir el que proviene del archivo /etc/bind/named.conf (en este caso localhost).
El registro SOA tienen el nombre completo de la máquina que mantiene la información (terminada en punto), seguida de la dirección electrónica del administrador del servicio, pero remplazando el caracter '@' por '.' y terminando con '.' [6] Los registros tipo SOA incluyen: un número serial que los servidores secundarios usan para determinar cuando la información de la zona del primario a cambiado, el número de refresco indica cada cuantos segundos un servidor secundario revisará el primario para determinar si el número serial ha aumentado, un número de reintentos que un servidor secundario debería efectuar en caso de ausencia de respuesta. Expiración es el tiempo máximo en segundos que un servidor secundario debe esperar antes de declarar la información que tenga de una zona como válida en ausencia de respuesta del servidor primario. Mínimo TTL indica el tiempo mínimo que los registros pueden estar en el deposito de otros servidores de nombres. Es el dato más importante. Si no se planean hacer cambios puede dejarse en un valor grande (3 días), si se planea un cambio es mejor disminuir este valor con suficiente anticipación y volverlo a un valor grande después del cambio. Note que para este ejemplo como se trata de localhost, estos valores pueden ser arbitrarios (en este caso muy grandes).
La información de la zona raíz corresponde a las direcciones de los 13 servidores de la raíz, puede obtenerse con:
dig @a.root-servers.net. . ns
En el momento de este escrito es:
. 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129 L.ROOT-SERVERS.NET. 3600000 IN A 198.32.64.12 M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 B.ROOT-SERVERS.NET. 3600000 IN A 128.9.0.107 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30
Si en la zona micolegio.edu.co el servidor de nombres tiene IP 192.168.1.1 con nombre servidor y algunos clientes con otras direcciones de la forma 192.168.1.*, el archivo /etc/bind/db.micolegio.edu.co sería:
@ IN SOA servidor.micolegio.edu.co. root.localhost. (
1 ; Serial
10800 ; Refresco cada 3 horas
3600 ; Reintento cada hora
2419200 ; Expiracion después de un mes
259200 ) ; TTL 3 dias
@ NS servidor
servidor.micolegio.edu.co A 192.168.1.1
www A 192.168.1.1
mail A 192.168.1.1
bachillerato1 A 192.168.1.2
bachillerato2 A 192.168.1.3
bachillerato3 A 192.168.1.4
bachillerato4 A 192.168.1.5
secretaria A 192.168.1.100
profesores A 192.168.1.200
Note que además de indicar que el archivo tiene información autoritaria sobre la zona con un registro SOA (que tiene parámetros más apropiados para un servidor de nombres primario); este ejemplo tiene: un registro tipo NS que presenta a servidor como servidor de nombres. Los demás registros tipo A asocian nombres a direcciones en la red. Note que todos los nombres de máquinas excepto el del registro SOA como no terminan en punto serán completados con el nombre de la zona (micolegio.edu.co declarada en /etc/bind/named.conf y referenciable como la variable $ORIGIN).
En cuanto a las zonas inversas, /etc/bind/db.0 es
@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL @ IN NS localhost.La zona inversa para localhost (/etc/bind/db.127):
@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL @ IN NS localhost. 1.0.0 IN PTR localhost.para la zona de broadcast /etc/bind/db.255:
@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL @ IN NS localhost.y para la zona de su red (/etc/bind/db.1.168.192):
@ IN SOA servidor.micolegio.edu.co. root.localhost. ( 1 ; Serial 10800 ; Refresco cada 3 horas 3600 ; Reintento cada hora 2419200 ; Expiracion después de un mes 259200 ) ; TTL 3 dias @ IN NS servidor.micolegio.edu.co. 1 IN PTR servidor.micolegio.edu.co 1 IN PTR www.micolegio.edu.co. 1 IN PTR mail.micolegio.edu.co. 2 IN PTR bachillerato1.micolegio.edu.co. 3 IN PTR bachillerato2.micolegio.edu.co. 4 IN PTR bachillerato3.micolegio.edu.co. 5 IN PTR bachillerato4.micolegio.edu.co. 100 IN PTR secretaria.micolegio.edu.co. 200 IN PTR profesores.micolegio.edu.co.Después de hacer sus cambios puede reiniciar bind (lo cual limpiará el depósito y leerá de nuevo los archivos de configuración) con: /etc/init.d/bind restart (ver Inicialización del sistema).
Al editar zonas tenga en cuenta estas recomendaciones (de los RFC 1912 y 1034):
Todo registro de recursos tipo A, debería tener el correspondiente registro tipo PTR para resolución inversa.
No emplee en registros CNAME el mismo nombre con otros propósitos, ni emplee nombres de registros MX.
No referencie alias definidos con CNAME en registros tipo SOA, MX ni CNAME.
Si mantiene un servidor primario, cada vez que haga modificaciones a información de la zona que maneja, recuerde aumentar el número serial del registro SOA para que el o los servidores secundarios realicen la actualización.
Este servicio permite compartir directorios de un servidor en uno o más clientes.
Como se describe en el RFC 1813, el protocolo NFS [7] permite acceder de forma transparente sistemas de archivos compartidos que están en máquinas remotas. Hay muchas posibilidades para usar este servicio, nuestra plataforma de referencia lo aprovecha para distribuir información de usuarios (directorio /home del servidor), las colas de correo (/var/mail) y los programas y documentos disponibles en el servidor (directorio /usr). Así mismo permite aprovechar el espacio de sobra de cada cliente (directorio /aux).
Archivo de configuración de NFS en un servidor, donde se especifica que directorios son exportables.
Al igual que otros servicios, NFS cuenta con un cliente y un servidor. El servidor NFS permite exportar directorios del computador en el que corre a computadores donde se ejecute el cliente, mientras estos últimos tengan permiso para importar tales directorios. Los directorios que se exportan, así como las restricciones sobre los clientes que pueden importarlos se especifican en el archivo /etc/exports. Por ejemplo el siguiente es el archivo /etc/exports del servidor de nuestra plataforma de referencia:
/usr *.micolegio.edu.co(ro,no_root_squash) /home *.micolegio.edu.co(rw,no_root_squash) /var/mail *.micolegio.edu.co(rw,no_root_squash)
Este archivo especifica que pueden exportarse con permiso de lectura y escritura los directorios /home, /var/mail. Puede exportar con permiso de sólo lectura (ro) el directorio /usr. Todos estos directorios pueden ser importados por máquinas con nombres de la forma x.micolegio.edu.co. La opción no_root_squash indica que los archivos de usuario y grupo root exportados del servidor sean tratados como si fueran del usuario y grupo root en los clientes.
En nuestra plataforma de referencia tanto cliente NFS como servidor NFS deben instalarse en todos los computadores (porque los computadores clientes exportarán el espacio que resta de su partición aux al servidor). El archivo /etc/exports de cada cliente debe ser algo como:
/aux *.micolegio.edu.co(rw,no_root_squash)
Para instalar el servidor y el cliente NFS en Debian 2.2 basta que instale los paquetes nfs-common y nfs-server, siguiendo el procedimiento usual (ver Administración de programas). Como NFS depende de RPC, asegúrese también de dar acceso a las máquinas de su dominio con portmap y que esté operando. Dado que portmap es manejado con tcpd (ver Configuración de servicios básicos) este acceso se da o restringe modificando los archivos /etc/hosts.allow y /etc/hosts.deny. Por ejemplo el archivo /etc/hosts.allow debe tener una línea como:
portmap: .micolegio.edu.co
Puede comprobar que portmap está corriendo buscándolo entre los procesos (i.e ps ax | grep "[p]ortmap") o revisando los programas que están registrados para usar RPC con pmap_dump.
Una vez esté corriendo el servidor y el cliente NFS en todas las máquinas, puede montar (ver Montaje y desmontaje de sistemas de archivos) los directorios exportados por el servidor en cada cliente, por ejemplo con algo como:
mount -t nfs servidor.micolegio.edu.co:/usr /opt
para montar el directorio /usr del servidor como el directorio /opt de cada cliente. Mejor aún, puede editar el archivo /etc/fstab para que cada vez que cada máquina inicie monte automáticamente ese directorio. Por ejemplo podría agregar la siguiente línea al archivo /etc/fstab de un cliente [8]:
servidor.micolegio.edu.co:/usr /opt nfs ro 0 0
En el servidor puede agregar al archivo /etc/fstab, líneas de la forma "clienten:/aux /mnt/auxn nfs rw 0 0" para montar en /mnt/auxn el directorio /aux de cada cada cliente. Para comprobar los directorios que ha montado con NIS puede emplear mount.
Mientras no configure el servicio NIS (ver Servicio NIS), recomendamos no montar /home ni /var/mail del servidor en los clientes.
NIS [9] es un servicio para centralizar nombres de usuarios, claves, e información de grupos en el servidor facilitando la administración de usuarios. Si además de NIS se usa NFS para montar el directorio /home del servidor en cada cliente, puede centralizarse también la información de todos los usuarios en el servidor.
Con este servicios puede centralizarse información de usuarios y claves en el servidor
NIS de forma análoga a DNS opera sobre un grupo de computadores (dominio) y mantiene bases de datos (mapas) centralizadas en un servidor maestro, que pueden ser consultadas por los clientes. Para disminuir carga podrían ponerse servidores esclavos que repliquen la información del servidor maestro.
Para usar NIS debe escoger un nombre de dominio NIS (puede ser diferente al dominio DNS) y usarlo en los computadores clientes y en el servidor.
Puede comenzar instalando el paquete nis tanto en clientes como servidor, al instalarlo podrá dar el dominio NIS (o puede editarlo en /etc/defaultdomain). En todos los computadores debe modificar el archivo /etc/nsswitch para cambiar el orden de búsqueda de usuarios, grupos y shadow. También debe agregar algunas líneas al final de los archivos /etc/passwd, /etc/group y /etc/shadow, tarea que puede hacer con los siguientes comandos:
echo "+::::::" >> /etc/passwd echo "+:::" >> /etc/group echo "+::::::::" >> /etc/shadow
Que agregan líneas con un "+" y tantos ":" como separadores hay en los respectivos archivos. En el servidor los usuarios y grupos que estén después de estas marcas no serán compartidos por NIS.
En el servidor debe configurar NIS de la siguiente forma:
Edite /etc/init.d/nis, asegurándose de dejar NISSERVER=master.
Reinicie el servicio NIS con /etc/init.d/nis restart
Edite el archivo /var/yp/Makefile y cambie la regla all: para que incluya también shadow.
Ejecute /usr/lib/yp/ypinit -m.
Una vez NIS esté funcionando en clientes y servidor, puede agregar, eliminar o modificar usuarios y grupos con los comandos usuales (ver Administración de usuarios) y después de cada modificación, para que el cambio sea notado por NIS, debe pasar al directorio /var/yp/ y ejecutar make.
Para centralizar la información de todos los usuarios en el servidor puede usar NFS una vez NIS funcione bien. Para lograrlo se debe hacer la administración de usuario siempre en el servidor (por ejemplo agregar nuevos usuarios sólo desde el servidor) para que los directorios queden allí; por otra parte debe montar el directorio /home del servidor en todos los clientes. Para centralizar la cola de correo en el servidor debe montar el directorio /var/mail del servidor en los clientes. De esta forma el archivo /etc/fstab de cada cliente debe incluir:
servidor.micolegio.edu.co:/home /home nfs rw 0 0 servidor.micolegio.edu.co:/var/mail /var/mail nfs rw 0 0
y el archivo /etc/exports del servidor debe tener las líneas apropiadas para exportar /home y /var/mail. Ver Servicio NFS.
El protocolo ssh cuenta con dos versiones, un borrador de la segunda de estas está en proceso de desarrollo. OpenSSH es la implementación de cliente y servidor para estos protocolos, la versión disponible para Debian permite usar tanto ssh 1 como ssh 2.
Tal como se describe en uno de los borradores de la especificación temporal "SSH Protocol Architecture" (http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-13.txt) ssh es un protocolo para iniciar sesiones en máquinas remotas que ofrece autenticación, confidencialidad e integridad. Consta de tres componentes:
Protocolo de transporte. Que normalmente opera sobre TCP/IP dando autenticidad, confidencialidad e integridad.
Protocolo de autenticación de usuario. Que autentica al usuario ante el servidor.
Protocolo de conexión. Que multiplexa un canal encriptado en diversos canales lógicos.
Este protocolo requiere que los servidores tengan "llaves", las cuales son usadas por los clientes cada vez que se conectan a un servidor para verificar que no fue suplantado. Una llave es un número codificado y encriptado en un archivo. Para la encripción de llaves, OpenSSH ofrece los algoritmos RSA y DSA (de los cuales para la versión 2 recomendamos DSA).
Para instalar un servidor OpenSSH, que le permita conectarse a su sistema de forma segura, instale el paquete ssh preferiblemente tomando la versión más reciente del sitio de seguridad de Debian: http://security.debian.org o compile las fuentes más recientes que puede obtener en http://www.openssh.org. Cuando instale se generaran un par de "llaves" para su computador, una pública y una privada. Una vez instalado podrá afinar la configuración del servidor en el archivo /etc/ssh/sshd.conf que puede incluir líneas como las siguientes:
PermitRootLogin no RSAAuthentication yes PubkeyAuthentication yes RhostsAuthentication no hostsRSAAuthentication no HostbasedAuthentication no X11Forwarding yes
Archivo de configuración del servidor OpenSSH.
La última línea permitirá a los clientes que se conecten ejecutar aplicaciones de X-Window y transmitir la información gráfica sobre la conexión segura (ver la sección de nombre telnet y ssh en Capítulo 2).
Un usuario también puede crear un par de llaves que le faciliten su autenticación al emplear ssh o scp. Estos programas por defecto piden clave al usuario que se conecte a un servidor ssh. Si un usuario genera sus llaves pública y privada, puede saltarse esta autenticación pues se hará de forma automática con las llaves. Para lograrlo su llave pública debe estar en el computador al cual se conecta (en ~/.ssh/authorized_keys) y su llave privada en el computador desde el cual se conecta (normalmente en ~/.ssh/id_dsa).
Un usuario emplea este programa se usa para generar sus llaves ssh pública y privada.
La generación de llaves puede hacerse con:
ssh-keygen -t dsa
que por defecto dejará su llave pública en ~/.ssh/id_dsa.pub y su llave privada en ~/.ssh/id_dsa (que además quedará protegida por una palabra clave que usted especifica). Como el nombre lo índica la llave privada no debe compartirla, por el contrario la llave pública puede transmitirla y puede ser vista por cualquiera.
En el computador en el que desee conectarse, agregue en el archivo ~/.ssh/authorized_keys (o ~/.ssh/authorized_keys2 si usa DSA y una versión de OpenSSH anterior a la 3.1), su llave pública. Por ejemplo el usuario mario desde purpura.micolegio.edu.co puede configurar la entrada con autenticación automática a la cuenta pepe en amarillo.micolegio.edu.co con:
purpura> scp ~/.ssh/id_dsa.pub amarillo.micolegio.edu.co:/home/pepe/id_dsa_mario.pub purpura> ssh -l pepe amarillo.micolegio.edu.co ... amarillo> cat id_dsa_mario.pub >> ~/.ssh/authorized_keys
Para automitizar autenticación en una cuenta, en este archivo del directorio ~/.ssh un usuario puede mantener las llaves públicas que pueden conectarse.
Cuando mario se intente conectar desde purpura, a la cuenta pepe en amarillo ya no tendrá que dar la clave de pepe en ese computador sino la palabra clave con la que protegio su llave privada. Incluso esta palabra clave puede darse una sóla vez, aún cuando se realicen diversas conexiones con:
purpura> ssh-agent bash purpura> ssh-add mario
Tras lo cual mario tecleará una vez la palabra clave de su llave privada, y después en esa sesión de bash todo ingreso que haga a la cuenta pepe en amarillo, no solicitará clave alguna.
En esta sección se presenta configuración de un servidor CVS y creación de repositorios (el uso de un repositorio y un servidor ya configurado puede verse en la sección de nombre Uso de CVS en Capítulo 3).
Un servidor CVS puede emplearse sin conexión a una red, o bien en red con alguno de los protocolos rsh, ssh (ver Servicio ssh) o pserver. Los dos primeros requieren que el usuario que se conecta tenga cuenta (o una llave pública ssh entre las llaves autorizadas de una cuenta), mientras que pserver puede manejar su propio archivo de usuarios y claves. En todos los casos requiere instalar CVS y configurar un depósito. Si usa ssh debe instalar también el servidor sshd (ver Servicio ssh), si usa pserver debe agregar a su archivo /etc/inetd.conf (ver Configuración de servicios básicos) la línea:
cvspserver stream tcp nowait.400 root /usr/sbin/tcpd /usr/bin/cvs -b /usr/bin allow-root=/var/cvs pserver(cambiando /var/cvs por el directorio donde está el depósito) y debe configurar los repositorios que desee poder acceder con pserver en /etc/cvs-pserver.conf.
Para instalar CVS instale el paquete cvs (ver Paquetes en Debian), que le permitirá activar o no el protocolo pserver y de requerirse hará los cambios apropiados en /etc/inetd.conf. El programa de instalación también podrá inicializar un repositorio por usted (puede ser /var/cvs, directorio que usted debe crear antes o durante la instalación de cvs).
Este servicio permite a diversos usuarios trabajar simultanaemente en las fuentes de un proyecto, y controla versiones.
Es un protocolo de autenticación de cvs, que permite manejar un archivo de usuarios y claves independiente de los usuarios y claves en el sistema.
Una vez CVS (y eventualmente ssh) esté instalado, todo usuario de la misma máquina puede crear uno o más depósitos. Tales depósitos podrán ser accedidos por otros usuarios del mismo sistema o de otro con ssh o con rsh o con el protocolo pserver (ver Uso de CVS)
Un usuario pepe emplearía una secuencia de comandos como la siguiente para crear un repositorio en /home/pepe/cvs:
cd ~ mkdir cvs cd cvs export CVS_RSH="" export CVSROOT=/home/pepe/cvs cvs init
Pepe mismo o algún otro usuario del sistema que tenga permiso de escritura en ese directorio podrá leer (update) y escribir (commit) en el nuevo repositorio. Para eso basta que emplee:
export CVS_RSH="" export CVSROOT=/home/pepe/cvs
También puede usarlo vía ssh (por ejemplo desde otro computador de la misma red) con CVS_RSH="ssh". O si durante la instalación o reconfiguración de cvs el administrador activa el protocolo pserver puede emplearse CVSROOT=:pserver:pepe@purpura.micolegio.edu.co:/home/pepe/cvs, siendo pepe un usuario de la máquina donde está el repositorio con permisos para leer (o escribir) o un usuario para ese repositorio agregado en el archivo /home/pepe/cvs/CVSROOT/passwd[10]
Todo usuario con permiso de escritura en ese depósito podrá ingresar un módulo nuevo. Por ejemplo un usuario con permiso de escritura y las variables CVS_RSH y CVSROOT con los valores recién presentados, puede ingresar todo el contenido del directorio ~/quimica` como módulo laquimica:
cd ~/quimica cvs import laquimica start vendor
Tras lo cual el mismo usuario que importó el módulo, o cualquier otro con permiso de lectura, puede sacar una copia local con:
cvs co laquimica
y hacer otras operaciones usuales de CVS (ver Uso de CVS).
Aprovechando la capacidad de CVS de ejecutar un script cuando actualiza la bitácora y el script syncmail, es posible configurar CVS para que por cada actualización (commit) envíe un correo a una dirección electrónica. Para esto haga checkout del directorio CVSROOT de su repositorio :
cvs co CVSROOT
En ese directorio copie el archivo syncmail que podrá descargar de: http://cvs-syncmail.sourceforge.net y después ejecute:
chmod +x syncmail cvs add syncmail
Después agregue al archivo checkoutlist la línea:
syncmail
actualice:
cvs commit -m "Ahora usa syncmail"
y finalmente edite y actualice el archivo loginfo, agregando líneas como la siguiente:
^mimodulo $CVSROOT/CVSROOT/syncmail %{sVv} paz@micolegio.edu.co
que indican que toda actualización al módulo
mimodulo, debe generar un correo indicando el
cambio a paz@micolegio.edu.co. La primera
parte de la línea (^mimodulo) es una
expresión regular que se aplicará al módulo o puede ser
DEFAULT para indicar cualquier módulo.
Nombre del protocolo para transmisión de correo electrónico en Internet.
Sigla para el tipo de programas que pueden transmitir un correo (por ejemplo exim y sendmail).
Sigla para el tipo de programas que un usuario puede emplear para redactar y leer correos (por ejemplo mail y mutt).
El servicio de correo empleado en Internet y en una red TCP/IP se basa en el protocolo SMTP (Simple Mail Transfer Protocol) descrito especialmente en los RFCs 821 y 1123, funcionando sobre TCP/IP. En una situación típica en la que un usuario pepe@primaria2.micolegio.edu.co envía un mensaje al usuario paz@bachillerato3.micolegio.edu.co sin computadores intermediarios, se requiere:
Que haya conexión física y a nivel de TCP/IP entre ambos computadores.
Que ambos computadores tengan un programa que permita enviar y recibir correo usando el protocolo SMTP, como por ejemplo exim, sendmail o postfix (a tal programa se le llama MTA - Mail Transport Agent).
Que ambos usuarios tengan un programa con el que puedan leer y redactar correos, como por ejemplo mail, mutt, elm, balsa, pine, evolution (a ese programa se le llamará MUA - Mail User Agent[11]).
Si tanto Pepe como Paz emplean como MUA mail, y ambos computadores tiene como MTA exim, el proceso sería:
Pepe emplea mail en su computador primaria2 para redactar el mensaje cuyo destinatario es paz.
En primaria2, el programa mail ejecuta exim para enviar el mensaje. exim deja el mensaje en una cola de mensajes por enviar. Esa cola de mensajes es actualizada por exim a medida que envía o intenta enviar mensajes (si un mensaje no puede ser enviado exim puede reintentar el envio cierto número de veces, haciendo pausas entre un intento y otro).
Enviar un mensaje significa crear una conexión TCP con el MTA destino o con otro MTA que actúe de intermediario, típicamente en el puerto TCP 25, y transmitir el mensaje siguiendo las reglas del protocolo SMTP [12]. Para establecer el computador con el cual conectarse exim revisa con el resolvedor DNS, registros MX asociados con el dominio de la dirección, si los hay intenta enviar a cada uno en orden de prioridad --los registros MX con menor número tienen mayor prioridad (ver Servicio DNS).
En bachillerato3 debe estar corriendo un proceso que acepte la conexión en el puerto 25. Puede ser exim mismo o puede ser inetd que una vez realizada la conexión ejecuta a exim (ver Configuración de servicios básicos). Después exim recibirá el mensaje siguiendo el protocolo SMTP.
exim agrega el mensaje que recibe en el archivo tipo texto /var/mail/paz.
Archivo donde exim deja los correos destinados al usuario paz.
Cuando Paz lo desee, podrá emplear mail para leer los correos que se hayan acumulado en /var/mail/paz ---a medida que los lea saldrán de ese archivo para quedar en ~/mbox.
Este es el esquema básico, aunque hay muchas otras situaciones en las que se emplean otras posibilidades de SMTP, protocolos auxiliares y programas[13]. Como parte de nuestra plataforma de referencia, sugerimos este esquema:
Emplear un MUA que pueda leer directamente los correos que están en /var/mail o /var/spool/mail y configurarlo para esto, (en Debian el primero es el preferido, y /var/spool/mail es un enlace a /var/mail) y que emplee un MTA para enviar correos (ejemplos de MUAs con estás características son: mail, mutt, elm, balsa, evolution).
script para configurar el mta exim.
Emplear exim como MTA en todos los clientes. Una ventaja de exim sobre otros MTA (como sendmail) es la facilidad con la que se configura en el archivo /etc/exim/exim.conf o aún más sencillo en Debian para muchas situaciones con el script eximconfig. Los computadores clientes se configuran como MTA satélites con el servidor como compuerta de correo (o smart host) ---es decir se configura en los clientes sin capacidad de recibir correos sino sólo de enviar todo correo a un computador (al servidor). El MTA del servidor funciona como un MTA completo que pueda recibir y enviar correo usando SMTP.
Emplear NFS para compartir el directorio /var/mail del servidor en todos los clientes. De forma que exista un único sitio físico donde estén todos los correos, pero que desde todos los computadores cada usuario pueda acceder a su archivo de correos.
Para configurar este esquema se requiere:
Instalar en todos los computadores los MUAs que habrá disponibles (mínimo mail disponible en el paquete mailx).
Instalar en todos los computadores el MTA exim (paquete exim). En los clientes configurarlo como sistema satélite. Como nombre de sistema emplee el dominio de su institución, como computador del cual leerán los correos y como smart host use el servidor. Para hacer un cambio en la configuración después de instalar puede emplear eximconfig, o con más práctica /etc/exim.conf. Algunas líneas que ese archivo debe tener en el caso de clientes, para enviar siempre por el servidor son:
qualify_domain = micolegio.edu.co
local_domains = micolegio.edu.co:localhost
smart:
driver = smartuser
new_address = ${local_part}@servidor.micolegio.edu.co
end
smarthost:
driver = domainlist
transport = remote_smtp
route_list = "* servidor.micolegio.edu.co bydns_a"
end
También puede incluir reglas para reescribir direcciones de forma que parezcan provenir de servidor.micolegio.edu.co:
^(?i)(root|postmaster|mailer-daemon)@micolegio.edu.co ${1}@in.limbo Ffr
*@micolegio.edu.co ${1}@servidor.micolegio.edu.co Ffr
^(?i)(root|postmaster|mailer-daemon)@localhost ${1}@in.limbo Ffr
*@localhost ${1}@servidor.micolegio.edu.co Ffr
*@in.limbo root@servidor.micolegio.edu.co Ffr
y esta para agregar direcciones que deben cambiarse para ciertos usuarios en el archivo /etc/email-adresses [14]:
*@micolegio.edu.co ${lookup{$1}lsearch{/etc/email-addresses}\
{$value}fail} bcfrF
El servidor puede configurarlo como si fuera sitio de Internet usando eximconfig y agregando registros MX al servidor DNS. Configure como nombre del sistema el dominio de su institución, excluya de los controles de relaying su red interna (e.g 192.168.1.0/24). De editar manualmente /etc/exim/exim.conf, entre las líneas que eximconfig incluye están las siguientes que configuran procmail (ver mutt y procmail):
procmail:
driver = localuser
transport = procmail_pipe
require_files =
${local_part}:+${home}:+${home}/.procmailrc:+/usr/bin/procmail
no_verify
Con las siguientes permite redireccionamiento con el archivo .forward. Tenga en cuenta cambiar la configuración por defecto que deja eximconfig para esto (porque permite que .forward pueda ser escrito por el grupo):
userforward: driver = forwardfile file_transport = address_file pipe_transport = address_pipe reply_transport = address_reply no_verify check_ancestor file = .forward filter
Las siguientes indican emplear el sistema de correo local para usuarios locales, hacer consultas DNS antes de iniciar conexiones SMTP y emplear direcciones IP explícitas.
localuser:
driver = localuser
transport = local_delivery
lookuphost:
driver = lookuphost
transport = remote_smtp
literal:
driver = ipliteral
La configuración de DNS debería tener en cuenta emplear servidor.micolegio.edu.co como intercambiador de correo para el dominio micolegio.edu.co y también como intercambiador de correo para cada cliente (es decir que todo correo que vaya a uno de los clientes se redirija al servidor). Retomando el ejemplo de la zona de DNS (ver Servicio DNS), el archivo /etc/bind/db.micolegio.edu.co tendría dos nuevas líneas (con registros tipo MX):
@ IN SOA servidor.micolegio.edu.co. root.localhost. ( 1 ; Serial 10800 ; Refresco cada 3 horas 3600 ; Reintento cada hora 2419200 ; Expiracion después de un mes 259200 ) ; TTL 3 dias @ NS servidor servidor.micolegio.edu.co A 192.168.1.1 www A 192.168.1.1 mail A 192.168.1.1 micolegio.edu.co. MX 5 mail *.micolegio.edu.co. MX 5 mail bachillerato1 A 192.168.1.2 bachillerato2 A 192.168.1.3 bachillerato3 A 192.168.1.4 bachillerato4 A 192.168.1.5 secretaria A 192.168.1.100 profesores A 192.168.1.200
Una vez haga cambios a la configuración de exim podrá realizar algunas pruebas para verificar la forma de enrutamiento:
exim -bV
exim -v -bt root@localhost
exim -v -bt root@servidor.micolegio.edu.co
exim -v -bt root@purpura.micolegio.edu.co
En este modo de operación de FTP, el cliente espera del servidor la especificación de la dirección y el puerto del canal de datos.
El protocolo FTP (que se describe en los RFC 1123 y en el RFC 959) permite transmitir archivos de un computador a otro de forma robusta y eficiente. Este protocolo requiere una conexión por la que se transmiten comandos y respuestas a comandos (normalmente por el puerto 21) y otra por la que se transmiten datos (el puerto es escogido por el cliente o el servidor). Pueden realizarse conexiones en modo activo o pasivo, en el primero el cliente establece la dirección y el puerto para el canal de datos, en el segundo es el servidor el que los establece. Al conectarse desde una red con direcciones privadas a un servidor FTP fuera de la red privada es necesario usar modo pasivo.[15]
Sugerimos emplear FTP para establecer un servidor FTP anónimo, pero no para brindar transmisión de archivos a usuarios del sistema (que pueden hacerlo con scp de ssh).
| Aviso |
Las claves transmitidas en sesiones de FTP viajan por la red sin encripción alguna. |
Archivo de configuración de proftpd.
Como servidor FTP sugerimos proftp (paquete proftpd). La configuración por defecto queda en /etc/proftpd.conf que permite a todos los usuarios emplear ftp, permite ftp anónimo empleando los archivos del directorio /var/ftp. El directorio empleado puede tener una estructura arbitraria. proftpd deja errores y mensajes de error en /var/log/syslog.
Para limitar el servicio a ftp anónimo (los usuarios pueden emplear scp para realizar copias), puede agregar en la sección general del archivo de configuración limitación de acceso para todos los usuarios (con LimitLOGIN) y en la sección de ftp anónimo permitir acceso para todos los usuarios. El archivo /etc/proftpd.conf sería algo como:
ServerName "servidor"
ServerType standalone
DeferWelcome off
ShowSymlinks on
MultilineRFC2228 on
DefaultServer on
ShowSymlinks on
AllowOverwrite on
TimeoutNoTransfer 600
TimeoutStalled 600
TimeoutIdle 1200
DisplayLogin welcome.msg
DisplayFirstChdir .message
LsDefaultOptions "-l"
Port 21
Umask 022 022
MaxInstances 30
User nobody
Group nogroup
<Limit LOGIN>
DenyAll
</Limit>
<Directory /*>
AllowOverwrite on
</Directory>
<Anonymous ~ftp>
User ftp
Group nogroup
UserAlias anonymous ftp
RequireValidShell off
MaxClients 10
DisplayLogin welcome.msg
DisplayFirstChdir .message
<Limit LOGIN>
AllowAll
</Limit>
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
</Anonymous>
Nombre del protocolo en el que se basa el web.
El servicio web se basa en el protocolo HTTP (Hypertext Transfer Protocol), cuya versión 1.1 está definida en el RFC 2616. Este protocolo permite:
Transmitir hipertextos escritos en HTML con diversas codificaciones e idiomas, gráficas y otros tipos de información a partir de URLs solicitados por el navegador. Cada tipo de información solicitada por un cliente es transmitida por el servidor con una identificación MIME (Multipurpose Internet Mail Extensions) que permite al navegador desplegarlo apropiadamente (por ejemplo cargando otro programa o un plugin de ser necesario)[16]. La identificación MIME es de la forma tipo/subtipo, las identificaciones registradas pueden consultarse en: http://www.iana.org/assignments/media-types/index.html
Sirve como protocolo genérico para transmisión de otros tipos de protocolos (e.g FTP, SMTP, Gopher, NNTP).
Permite emplear intermediarios (proxys, compuertas y túneles), cada uno de los cuales puede tener un deposito. Normalmente HTTP emplea por defecto el puerto TCP 80 (si el servidor/proxy está en otro puerto, puede especificarse en un URL como http://servidor.micolegio.edu.co:8080/index.html).
Ejecutar CGIs (Common Gateway Interface) que respondan dinámicamente a información transmitida desde el cliente. Por ejemplo el siguiente URL incluye las variables nombre y apellido que son pasadas al CGI param.cgi con valores Pepe y Rojimes: http://structio.sourceforge.net/cgi-bin/param.cgi?nombre=Pepe&apellido=Rojimes Los CGIs son programas o scripts que reciben por entrada estándar y/o variables de ambiente, consultas hechas por un cliente y responden escribiendo en sálida estándar la respuesta que dará el servidor.
Como servidor web sugerimos Apache (paquete apache), que es el servidor más popular en Internet (puede consultar estadísticas en Netcraft) y para hacer más eficiente la conexión sugerimos emplear squid como proxy con depósito.
Servidor web sugerido en la plataforma de referencia S-Helio.
Apache se configura en el archivo /etc/apache/httpd.conf. La configuración por defecto supone que las páginas por servir están en /var/www y en los directorios public_html de cada usuario. Los errores y mensajes quedan en /var/log/apache/error.log y pueden dejarse CGIs en el directorio /usr/lib/cgi-bin (que es alias de /cgi-bin). Entre sus características están:
Archivo de configuración de Apache.
Excelente implementación de HTTP 1.1 y CGI 1.1.
Configuración sencilla (en /etc/apache/httpd.conf) y posibilidad de emplear archivos de confioguración por cada usuario ~/public_html/.htaccess.
Cuenta con módulos para soportar SSI (Server Side Includes) y PHP.
Soporta SSL (Secure Socket Layer) para trasmisión encriptada y autenticación básica para tener zonas restringidas con claves.
Soporta dominios virtuales (Virtual Host), para atender con un sólo servidor diversos dominios. Además de la configuración DNS que esto requiere (puede ser con registros CNAME), basta agregar una sección por cada dominio virtual, por ejemplo:
<VirtualHost *> ServerName estudiantes.micolegio.edu.co DocumentRoot /var/www/estudiantes </VirtualHost>
Archivo de configuración del proxy Squid.
En cuanto a proxy, puede instalar squid (paquete squid). Este programa permite definir listas de acceso y emplearlas para dar servicio sólo a las direcciones con permiso. La configuración por defecto del paquete deja listo squid para servir sólo al computador donde se instala, para servir otros computadores de su red debe (1) agregar un ACL que especifique todos los computadores de su red y (2) indicar que el ACL definido puede emplear el proxy de HTTP, se hace con líneas como éstas en las secciones apropiadas del archivo de configuración /etc/squid.conf:
acl red src 192.168.0.0/255.255.0.0y
http_access allow redTras hacer cambios en la configuración puede reiniciarlo con
/etc/init.d/squid restart
Puede comprobar que funciona o diagnosticar errores revisando las bitácoras del directorio /var/log/squid. Desde los clientes podrá configurar el navegador para que emplee este proxy que por defecto atiende el puerto 3128. Por ejemplo con w3m y lynx basta establecer el URL del proxy en la variable de ambiente http_proxy:
export http_proxy=http://servidor.micolegio.edu.co:3128
En el caso de mozilla, se configura
en después de elegir
en el menú principal.
Variable de ambiente empleada por algunos navegadores (como lynx y w3m) para determinar el proxy por usar.
El programa lpd es un servidor del protocolo LPD, mientras que lpr es un cliente. En esta sección se dan detalles mínimos para configurar una impresora en red, la configuración de una impresora local a un computador y la configuración básica de /etc/printcap puede consultarse en la sección la sección de nombre Impresora en Capítulo 5 y el uso de la impresora una vez configurada en la sección de nombre Impresión y formatos para impresión en Capítulo 3.
La impresora de la red debe conectarse a un computador y configurarse como local en ese computador. En el resto de computadores debe configurarse como impresora remota. Por ejemplo si el comptuador al que está conectado la impresora es rojo.micolegio.edu.co y allí se configura una impresora con nombre psprn, en los demás computadores en el archivo /etc/printcap debe haber líneas como:
psprn|rp|remote line printer:\ :lp=:rm=rojo.micolegio.edu.co:rp=psprn:sd=/var/spool/lpd/psprn: \ :lf=/var/log/lp-errs:
En el archivo de configuración de impresoras, este "campo" en el registro de una impresora indica que se trata de una impresora remota y permite especificar el nombre del computador al que está conectada.
El servidor lpd que debe ser iniciado durante el arranque de rojo, recibe conexiones sólo de las máquinas especificadas en /etc/hosts.equiv o /etc/hosts.lpd y podrá entonces imprimir trabajos iniciados por usuarios en tales máquinas (agregue a uno de esos archivos los computadores clientes que podrán imprimir). Para restringir acceso a una impresora de otra forma, en /etc/printcap puede emplearse rs en lugar de rm para indicar que tal impreso sólo imprimirá trabajos de usuarios que tengan una cuenta en el mismo computador.
Net-HOWTO. 5.8. Configuring your network servers and services. http://linuxdoc.org/HOWTO/Net-HOWTO/x619.html
El tema seguridad no es tratado en profundidad (es indispensable estudiarlo si se planea conectar a Internet). NET-3-HOWTO Sección 5.10. Network Security and access control.
Para conocer más sobre la configuración de inetd y tcpd, puede consultar las páginas man de inetd, tcpd y hosts_access.
Puede consultar sobre el protocolo Telnet en los RFC 854, 855 y 1123.
Sobre el protocolo de finger en el RFC 1288.
La versión 3 de este protocolo está descrita en el RFC 1813.
Páginas del manual de exports (man exports), de NFS y de portmap.
De Olaf Kirch y Terry Dawson: Linux Network Administrators Guide. The Network File System. http://www.linuxdoc.org/LDP/nag2/x-087-2-nfs.html
Puede consultar una exposición no técnica sobre DNS en http://www.internic.net/faqs/authoritative-dns.html
Puede consultar sobre DNS en el RFC 1034 y recomendaciones en el RFC 1912.
djbdns es otro servidor de nombre (no tan popular), en su página web puede consultarse información concisa sobre DNS http://cr.yp.to/djbdns.html
Una explicación corta para la configuración de DNS en una red LAN en este artículo de Linux Gazette: http://www.linuxgazette.com/issue44/pollman/dns.html
Una vez instale nis en Debian, en el directorio /usr/doc/nis encontrará un documento muy práctico y corto: nis.debian.howto. En Internet lo encuentra en: http://www.linux-nis.org/doc/nis.debian.howto
NIS puede configurarse de forma más segura de la presentada en esta guía, puede manejar sus propios archivos de claves y grupos, permite tener servidores maestros y esclavos y muchas otras posibilidades que se describen brevemente en ese archivo.
Una explicación sobre generalidades de NIS en: http://publib16.boulder.ibm.com/pseries/en_US/aixbman/nisplus/nis_intro.htm#a2b6a622144endr
Puede averiguar más sobre NIS y sus variantes en el NIS-HOWTO http://www.linuxdoc.org/HOWTO/NIS-HOWTO/index.html o en el capítulo "The Network Information System" de "Linux Network Administrators Guide" http://www.linuxdoc.org/LDP/nag2/x-087-2-nis.html.
Puede consultarse la arquitectura general de SSH 2 en http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-13.txt
CVS
Para saber más sobre CVS puede consultar la página man. En Internet puede consultar "CVS--Concurrent Versions System" http://www.cvshome.org/docs/manual/cvs.html o Open Source Development With CVS. En particular sobre la configuración de syncmail y CVS: http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1
Especificación de exim 3.3: http://www.exim.org/exim-html-3.30/doc/html/spec.html
Web
Puede consultar más sobre CGIs en la especificación: http://cgi-spec.golux.com/ y más sobre la configuración de Apache para usar CGIs en este tutorial: Dynamic Content with CGI y en la especificación propu.
1.1. Active el servicio interno daytime de inetd, después revise la respuesta que este da a una conexión empleando telnet. Describa los pasos que siguió.
A /etc/inetd.conf debe agregarse la línea:
daytime stream tcp nowait root internalDespués de reiniciar: /etc/init.d/inetd restart Y finalmente se examina la respuesta de este protocolo:
$ telnet localhost 13 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Wed Jan 1 19:26:31 2003 Connection closed by foreign host.
2.1. Desde el intérprete de comandos ¿Cómo puede determinar la IP de structio.sourceforge.net, los nombres DNS asociados a la IP 204.152.184.85 y la dirección de correo del contacto técnico de sourceforge.net? ¿Cuáles son esos datos?
ping structio.sourceforge.net whois sourceforge.net dig -x 204.152.184.85 1. 66.35.250.209 2. dns-tech@valinux.com 3. pubweb.isc.org, ns-ext.vix.com, ns1.gnac.com
3.1. En su máquina cree los directorios /aux y /mnt/tmp, ponga en el primero algún archivo. Después monte vía NFS el directorio /aux y móntelo en el directorio /mnt/tmp. Después de que funcione, desmóntelo.
Instalar cliente y servidor NFS. mkdir /aux; mkdir /mnt/tmp; cp /etc/hosts /aux Agregar a /etc/exports la línea:
/aux localhost(rw)y después mount -t nfs localhost:/aux /mnt/tmp
3.2. Monte el directorio /usr del servidor principal como /opt en otro computador de la red. ¿Qué debe hacer para que en ese computador se emplee la ruta /opt/bin para buscar archivos y /opt/lib para buscar bibliotecas compartidas?
En algún archivo de inicialización (preferiblemente /etc/security/pam_env.conf) agregar:
export PATH=$PATH:/opt/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/lib
4.1. Configure exim en un computador cliente para no recibir correos y enviar empleando el MTA del servidor. Compruebe que funciona enviando desde el cliente un correo a una cuenta en el servidor.
Ejecutar eximconfig y elegir configuración como sistema satélite como smart host usar servidor. Después mail -v root@servidor
4.2. Después de configurar NIS, empleando NFS comparta el directorio /var/mail del servidor en un cliente con la configuración del ejercicio anterior. Tras esto compruebe que cada usuario puede revisar su correo con el programa mail desde cualquier computador.
Editar el archivo /etc/exports del servidor, agregar:
/var/mail *.micolegio.edu.co(rw,no_root_squash)Reiniciar NFS. En el cliente agregar en /etc/fstab:
servidor.micolegio.edu.co:/var/mail /var/mail nfs rw 0 0y después mount -t nfs servidor.micolegio.edu.co:/var/mail /var/mail
| [1] | conexión del inglés sockets |
| [2] | El primer argumento corresponde al nombre del comando, es útil al emplear tcpd |
| [3] | Hilos del inglés threads. |
| [4] | Depósito es la traducción que empleamos para cache |
| [5] | Hay 13 servidores principales que manejan la raíz de este árbol. |
| [6] | Estos archivos de registros son preprocesados, y a todo nombre que no termine con el caracter '.' se le agrega la zona (definida en /etc/bind/named.conf) para convertirlo en un nombre completo (FQDN - Fully qualified domain name). |
| [7] | NFS es sigla de Network File System que en castellano es sistema de archivos en red. Anque en el momento de este escrito hay versión 4, en Debian está implementada la 3. |
| [8] | Después de montar /usr del servidor como /opt de cada cliente, podrá ejecutar algunos programas que están en el servidor, desde el directorio /opt (aún para más comodidad puede agregar las rutas /opt/bin a la variable de entorno PATH). |
| [9] | NIS es sigla de Network Information System que en castellano es sistema de información de la red |
| [10] | El archivo de claves para CVS tiene 2 o 3 campos, el primero es el nombre con el que se conectará el usuario, el segundo la clave encriptada con DES (ver Administración de usuarios) y el tercer opcional es el nombre del usuario local a nombre del cual modificará el repositorio. Este archivo puede administrarse con htpasswd, para crear el archivo con un primer usuario: htpasswd -c pepe y posteriormente para agregar otros usuarios htpasswd agustin |
| [11] | De acuerdo al RFC 1123 los nombre MUA y MTA son propios del protocolo X.400. |
| [12] | De acuerdo al protocolo SMTP, exim de primaria2 se conectaría por el puerto 25 a exim en bachillerato3 y enviaría el mensaje MAIL FROM: pepe@primaria2.micolegio.edu.co, después enviaría RCPT TO: paz@bachillerato3.micolegio.edu.co, después DATA y a continuación el cuerpo del correo comenzando con el encabezado de acuerdo al RFC 822, con un cuerpo de mensaje que emplee 7 bits y terminando con una línea que sólo tenga un punto. Por ejemplo From: pepe@primaria2.micolegio.edu.co To: paz@bachillerato3.micolegio.edu.co Subject: Saludo Un cortisimo saludo. . Si lo desea puede experimentar con este protocolo, empleando telnet y el MTA de su computador: telnet localhost 25. Claro resulta más transparente empleando directamente exim (que tiene como alias el script sendmail): sendmail -bm paz@bachillerato3.micolegio.edu.co -f pepe@primaria2.micolegio.edu.co(para emplear -f con exim debe ser usuario autorizado). |
| [13] | Otro caso típico que evita tener MTA en el computador del usuario, requiere otro computador que almacene los correos y el protocolo POP3 (RFC 1939). |
| [14] | Cada línea de /etc/email-adresses será análoga a la siguiente, que indica reescribir la dirección del usuario pepe como pepe2@micolegio.edu.co: pepe: pepe2@micolegio.edu.co |
| [15] | Puede observarse con telnet el comportamiento de este protocolo por ejemplo: telnet ftp.ibiblio.org 21 user anonymous pass email@ pwd pasv retr index.html Como resultado del comando pasv el servidor FTP envía dirección y puerto al que debe conectarse el cliente para recibir la información. Si la respuesta es por ejemplo: 227 Entering Passive Mode (152,2,210,81,230,214) el cliente debe abrir otra conexión para recibir los datos con la máquina con IP 152.2.210.81 (ftp.ibiblio.org) puerto 230*256+214 (59094). Al hacer: telnet 152.2.210.81 59094 la conexión abierta recibirá el contenido del archivo README. Este ejemplo emplea FTP en modo pasivo, podría también indicarse modo activo empleando port en lugar de pasv. El comando port indica al servidor que inice una conexión con cierta dirección y puerto para realizar la transmisión, por ejemplo si en el cliente con dirección 1.2.3.4 se espera una conexión en el puerto 8000:
port 1,2,3,4,31,64
(note que 31*256+64 es 8000). |
| [16] | Puede verse en funcionamiento este protocolo empleando telnet, por ejemplo:
telnet structio.sourceforge.net 80
GET http://structio.sourceforge.net/index.html
|