Servicios de RED (Parte II)

Servicios de RED (Parte II)
Entrenamiento en Linux Clase #7 Servicios de RED (Parte II) Por: Javier García Salgado

Clase #7 Servicios de RED (Parte II) Sumario DNS Servicio WEB (Apache)
Correo Electrónico (Sendmail)

Sistema de Nombres de Dominio
El Sistema de Nombres de Dominio (Domain Name System) es un poderoso y complejo mecanismo que permite la traducción de nombres a direcciones IP (y viceversa), en las redes computacionales. Las direcciones IP identifican unívocamente a las máquinas de una red permitiendo la comunicación entre estas a través de diversos protocolos con el objetivo de acceder o brindar múltiples servicios. La implementación más difundida del protocolo IP identifica a los hosts a través de un número binario de 32 bits que en decimal se expresa utilizando cuatro números entre 0 y 255. Un ejemplo de número IP en notación decimal es: que en binario sería:

continuación... Evidentemente la primera forma es mucho más fácil de dominar y más aun si se tiene una red donde coincida la mayor parte del número en todos los hosts. No obstante se presentan dificultades cuando estamos ante redes de alcance global como Internet con miles de hosts y donde conocer la dirección IP de todas las máquinas con las que nos comunicamos normalmente para obtener algún servicio, es prácticamente imposible. Esta es la causa fundamental de que se utilice una forma más humana de identificar a las máquinas en las redes: los NOMBRES.

continuación... La primera forma que se utilizó fue el fichero host, que básicamente tenía la forma: deltha gloin odin nero En la medida que las redes fueron creciendo e interconectándose entre sí esta forma generaba demasiados inconvenientes ya que era muy difícil mantener este fichero. Posteriormente a esta forma primaria de resolver los nombres en la red, se creó y perfeccionó lo que se conoce actualmente como Sistema de Nombres de Dominio. Un servidor de nombres se encarga de almacenar la información asociada al segmento de la base de datos que controla, y de mantenerla accesible a los clientes, estos clientes se conocen como resolvers. Un resolver es una subrutina que genera consultas y las envía a través de la red hacia el servidor de nombres correspondiente.

continuación... El espacio de los nombres de dominio La estructura de la base de datos del DNS posee una forma jerárquica similar al sistema de ficheros de Linux. Esta es una especie de árbol invertido donde cada nodo representa un segmento o dominio. Los nodos a su vez pueden poseer varios subnodos hijos que constituyen subdominios en el DNS. Por último, los nodos que no poseen hijos pueden verse como los nombres de los hosts que pertenecen al dominio definido por el nodo padre.

continuación... Cada nodo se identifica utilizando una etiqueta cuyo tamaño no debe exceder los 63 caracteres. El nodo raíz tiene una etiqueta vacía (longitud cero). Para indicar el nombre de un host en el DNS se utilizan todas las etiquetas de los nodos desde este hacia la raíz según la jerarquía. Las etiquetas se separan utilizando el carácter ''.'' Un dominio agrupa un conjunto de hosts y/o subdominios que se relacionan de acuerdo a cierto criterio, ya sea geográfico u organizacional. En el DNS cada dominio es administrado por una organización o empresa determinada. Esta empresa puede decidir dividir el o los dominios que administra en subdominios, así como asignar la administración de estos a otras entidades. El DNS en la actualidad sigue ciertos patrones en cuanto a su organización. Esta se basa en niveles de acuerdo a la posición del dominio.

continuación... El nivel superior o primer nivel lo forman aquellos dominios descendientes del dominio raíz. Los fundamentales se listan a continuación: com : Agrupa a organizaciones comerciales. Ejemplos: ibm.com, yahoo.com, redhat.com, etc. edu : Reune a organizaciones de propósitos educacionales. Ejemplos: berkeley.edu, cornell.edu, etc. net : Agrupa a organizaciones dedicadas al desarrollo de las redes. Ejemplos rpmfind.net, nic.net, computing.net, etc. org : Reúne a organizaciones no comerciales. Ejemplos: linuxdoc.org, ibiblio.org, linux.org, insflug.org, etc. gov : Agrupa a organizaciones gubernamentales. Ejemplo: nasa.gov, nsf.gov, etc. Como parte del espacio de nombres de dominio también existen dominios de primer nivel que designan zonas geográficas. Sus nombres representan a todos los países a través de dos letras. Ejemplos: cu para Cuba, au para Australia, de para Alemania, etc.

continuación... Delegación Una de las ventajas fundamentales de la estructura distribuida del DNS es la descentralización de su administración. El mecanismo que permite resolver un nombre completamente es la delegación, o sea, la organización propietaria de un dominio puede dividir este en varios subdominios y delegar a su vez todo lo concerniente al mantenimiento de la información relacionada y su accesibilidad, a cada uno de estos subdominios. Por ejemplo: el dominio de primer nivel cu administrado por CENIAI se divide a su vez en múltiples subdominios, como colombus, uh, cubalse, minbas y otros. En cada uno de ellos CENIAI delega la responsabilidad del mantenimiento de su información y de responder a las consultas de sus dominios correspondientes. Estos dominios de segundo nivel se dividen también en otros subdominios continuando el mecanismo de delegación. En resumen el término delegación se refiere a que la organización encargada de un dominio determinado asigne la responsabilidad de sus subdominios a otras organizaciones.

continuación... Servidores de nombres de dominio Los programas encargados de agrupar y mantener disponible la información asociada a un espacio de nombres de dominio se conocen como servidores de nombres de dominio. Estos servidores usualmente rigen la información referente a una parte del dominio, la cual se conoce como zona. Entonces se dice que ese servidor tiene autoridad sobre la zona. Un mismo servidor puede estar autorizado para varias zonas. Los servidores de nombres se clasifican en dos tipos fundamentales: primarios y secundarios. Un servidor de nombres de dominio primario es aquel que toma los datos de las zonas para las que está autorizado, desde ficheros presentes en la máquina donde se ejecuta. En cambio el secundario lo hace desde otros servidores autorizados para la zona (primarios generalmente). El proceso de actualización de la información de una zona en los servidores secundarios se conoce como transferencia de zona.

continuación... La posibilidad de definir más de un servidor de nombres de dominio para una misma zona permite: tener redundancia de la información mayor tolerancia ante la falla de algún servidor y accesibilidad por parte de todos los hosts de la red. Todo esto se logra sin tener que actualizar los datos manualmente lo cual puede traer errores e inconsistencias en la información de la zona. Un servidor de nombres puede ser primario para unas zonas y secundario para otras. Los servidores de dominio primarios obtienen la información de las zonas que controlan a partir de ficheros de datos conocidos como ''db'' o ficheros de base de datos (database files). Los servidores secundarios algunas veces leen su información de ficheros también. Estos se crean a partir de la transferencia de las zonas presentes en los servidores primarios.

continuación... La ventaja de tener salvas de la información de las zonas en un servidor secundario es que permite que cuando este inicie pueda utilizar estas salvas en el caso de que el servidor primario no esté disponible para efectuar una transferencia. Existe un conjunto de servidores de nombres de dominio muy importante. Son aquellos que controlan el dominio raíz y conocen todos los servidores autorizados para los dominios de primer nivel. Estos servidores son claves en el proceso de resolución de nombres de dominio abordado más adelante. Actualmente existen trece servidores raíces distribuidos en su inmensa mayoría en el territorio de los Estados Unidos, los otros se encuentra en Japón, Suecia y Gran Bretaña.

continuación... Resolvers Los resolvers son los clientes que acceden a los servidores de nombres. Cualquier programa que necesite información de un espacio de nombres de dominio utiliza un resolver. Los resolvers realizan las siguientes funciones: Consultan a un servidor de nombres de dominio Interpretan la respuesta (esta puede ser válida o un error) Retornan la información al programa que la solicitó Los resolvers no son programas independientes, sino que son rutinas compiladas dentro de aquellos que las requieren. Por ejemplo: Los comandos ping, telnet, ftp, navegadores como el Netscape, el Konqueror, el Internet Explorer y otros.

continuación... Proceso de resolución de nombres Para satisfacer las solicitudes de los resolvers los servidores de nombres no solamente retornan información acerca de las zonas para la que están autorizados, también tienen que hacerlo de aquellas para las que no lo están. Este proceso se denomina resolución Gracias a que el espacio de nombres de dominio tiene estructura arbórea sólo es necesario por parte del servidor de nombres conocer un punto de este árbol: los nombres y los números IP de los servidores de nombre del dominio raíz (servidores raíces). De esta forma cualquier servidor de nombres para resolver un nombre determinado sólo necesitará conocer algún servidor raíz y consultarlo. Este referirá la dirección del servidor del subdominio correspondiente (dominio de primer nivel), el cual a su vez puede referir a otro servidor y así sucesivamente se va completando el proceso de resolución.

Proceso de resolución del nombre www.chips.ibm.com
Sistema de Nombres de Dominio continuación... Proceso de resolución del nombre

continuación... Hasta ahora puede concluirse que los servidores raíces reciben todas las consultas que se realizan cada instante en Internet. Otros servidores, no necesariamente los del dominio raíz, también pueden estar muy sobrecargados. Es por esto que las implementaciones del DNS proveen el mecanismo de caché. Esta facilidad se implementa utilizando un caché de las respuestas a las consultas más recientes. Por ejemplo, supongamos que se haya resuelto recientemente el nombre si a continuación se desea consultar cierta información acerca del nombre no será necesario interrogar a un servidor raíz para conocer los servidores del dominio com, ni tampoco a alguno de estos para el dominio ibm, gracias a que ya está ''cacheada'' la dirección de un servidor del dominio ibm y es a partir de este donde comenzará el proceso de resolución. Existen servidores de nombres que sólo realizan caché. Estos no son autoritarios de ninguna zona. Lo único que hacen es guardar en su caché las respuestas que le dan otros servidores cada vez que son consultados.

continuación... Los servidores de nombres no deben almacenar en sus cachés la información a la que acceden por un tiempo indefinido, ya que entonces sería imposible la actualización de esta información una vez sea cambiada en los servidores autorizados para ello. Es por eso que a cada dato de un dominio se le asocia por parte de su administrador un tiempo de vida o TTL, dado el cual cualquier servidor que tenga ese dominio almacenado en su caché debe volver a interrogar al servidor autorizado de la zona a la que pertenece el dato. Un TTL pequeño permitirá que la información sea consistente casi siempre, pues los datos expirarán rápidamente obligando a descargarlos del caché y a obtener los nuevos valores de los servidores autorizados. Esto producirá un mayor número de consultas y esto empeorará el rendimiento del servidor. La situación inversa, un TTL grande, mejorará el desenvolvimiento de los servidores y acortará el tiempo del proceso de resolución, pero puede provocar que la información se mantenga inconsistente durante mucho tiempo.

continuación... Traducción de direcciones a nombres El proceso de resolución en el DNS no sólo permite traducir nombres a direcciones IP, sino también se puede hacer el proceso inverso, o sea, dado un número IP determinar el nombre principal asociado a esta. Esta facilidad permite que los programas puedan producir su salida en un formato más humano, por ejemplo el subsistema de trazas en lugar de colocar los números IP de las máquinas en las salidas que genera puede utilizar sus nombres. Para realizar esta traducción es que se adiciona otra sección al DNS conocida como dominio in-addr.arpa. En arpa los nombres de dominio completos se expresan de forma invertida a como se hace en el otro caso.

continuación... Introducción a BIND La primera implementación del sistema de nombres de dominio se nombraba JEEVES, después surgió BIND escrito originalmente por Kevin Dunlap. Hoy día BIND es mantenido por Paul Vixie bajo el auspicio de la ISC (Internet Software Consortium). BIND es el servidor de DNS de más popularidad en la actualidad. Ha sido portado para múltiples plataformas basadas en Unix (incluyendo a Linux) así como para Windows NT y 2000. En el caso de la distribución Red Hat, el servidor BIND se empaqueta bajo el nombre bind. Existen además dos paquetes relacionados con el DNS: bind-utils y caching-nameserver. El primero consta de varias utilidades para consultar un servidor de DNS, tales como host, nslookup y dig descritas más adelante; y el segundo, caching-nameserver, agrupa los ficheros de la configuración mínima para un servidor de DNS que sólo consulte a otros servidores de dominio.

continuación... Una vez instalado BIND, el daemon encargado de brindar el servicio se nombra named. Este se puede manipular utilizando el script /etc/rc.d/init.d/named. Ejemplos: # service named start Starting named: [ OK ] # service named stop Shutting down named: [ OK ] # service named reload Reload initiated.

continuación... Configuración de BIND La configuración básica de BIND se encuentra en el fichero /etc/named.conf. Este fichero fundamentalmente describe las zonas de los dominios que controlorá BIND. Para cada una de estas zonas se indica, entre otras características, el nombre del fichero que almacena sus datos. Es en estos ficheros donde se colocan todos los records del DNS y como se mencionó anteriormente se conocen como ficheros ''db'' (database files). Por defecto se agrupan en el directorio /var/named. La información presente en un fichero db puede especificarse en letras mayúsculas o minúsculas indistintamente pues las consultas al DNS son case-insentive. Se pueden incluir además comentarios precedidos por el carácter '';'' y líneas en blanco.

continuación... Tipos de Records SOA (Start Of Authority) : Este record es el que indica que el servidor de nombres está autorizado para la zona correspondiente. Se ubica al comienzo de cada fichero db y contiene información acerca del funcionamiento del DNS. A (Address) : Es uno de los records más importante pues permite definir la correspondencia entre nombres y direcciones IP. CNAME (Canonical Name) : Se utiliza para definir alias para los nombres ya definidos. NS (Name Server) : Permite indicar cuales son los servidores de nombres de dominio de la zona correspondiente. PTR (Domain name Pointer) : Junto a los address records es uno de los más importantes pues define las correspondencias inversas: de direcciones IP a nombres.

continuación... MX (Mail Exchanger) : Permite indicar para un nombre de dominio determinado quien es el host que se encarga de manipular la mensajería dirijida a este. HINFO (Host Information) : Se emplea para almacenar dos características, procesador y sistema operativo, de un host del dominio. TXT (Text) : Permite guardar un comentario textual acerca de un host perteneciente al dominio.

continuación... Los records en un fichero db presentan la siguiente sintaxis: <dominio> [ttl] [clase] <tipo> <datos> Donde: dominio : puede ser el caracter ''.'' cuando se refiere al dominio para el origen actual, o un dominio estándar. Si el nombre del dominio no termina con un punto entonces se le adicionará el origen actual, de tener un punto al final se mantendrá invariable. ttl : indica el tiempo de vida del record. Si no se coloca se asume el especificado en la última directiva $TTL o el valor mínimo especificado en el record SOA. clase : se utiliza para definir la clase del record. Por defecto se asume la clase correspondiente a las redes tipo Internet basadas en TCP/IP, nombrada IN. tipo : indica el tipo de record descrito. Puede ser cualquiera de los especificados anteriormente: A, NS, CNAME, SOA, etc.

continuación... datos : constituye la información asociada al record y que es totalmente dependiente de este. A continuación se indica el formato de la información asociada a cada tipo de record: SOA record : <servidor de dominio> < > <número de serie> <intervalo de refrescamiento> <intervalo de reintento> <intervalo de expiración> <ttl mínimo> NS record : <servidor de dominio> A record : <dirección IP> CNAME record : <nombre canónico> PTR record : <nombre de dominio> MX record : <preferencia> <dominio> HINFO record : <tipo de CPU> <tipo de Sistema Operativo> TXT record : <texto> Si un record abarca varias líneas hay que emplear paréntesis. Los records que emplean en mayor medida esta posibilidad son el SOA y el WKS dada la cantidad de información que contienen.

continuación... Directivas Además de varios records, en un fichero db se pueden incluir algunas directivas (variables) que modifican la interpretación de los records que se definan posteriormente a su inclusión. Estas directivas son: INCLUDE, ORIGIN y TTL. Se indican precedidas por el signo $. A continuación se describe y ejemplifica la utilización de cada una: INCLUDE Permite incluir otro fichero db especificando su nombre y la zona que describe, opcionalmente. Sintaxis: $INCLUDE <fichero> [dominio] Ejemplo: $INCLUDE uucpminbas.zone uucp.minbas.cu ORIGIN Se utiliza para cambiar el origen por defecto de la zona. El origen inicial se corresponde con el nombre de la zona que describe el fichero. Sintaxis: $ORIGIN <dominio> Ejemplo: $ORIGIN uucp.minbas.cu

continuación... TTL Permite indicar el tiempo de vida por defecto de todos los records del fichero. El TTL se indica en segundos. Sintaxis: $TTL <ttl> Ejemplo: $TTL 3600

continuación... Configurando un dominio Se definirá el dominio minbas. Este será subdominio a su vez del dominio de primer nivel cu. Todo quedaría de la forma hostname.minbas.cu. Los hosts están distribuidos en la red Se configurará un servidor de DNS primario en el host chat ( ) y un secundario en el host zeus ( ). A continuación se mencionarán y describirá brevemente la funcionalidad de los ficheros db necesarios para el ejemplo: localhost.zone : Se instala a través del paquete caching-nameserver. Almacena la configuración de la zona correspondiente a la interfaz local nombrada localhost. named.local : Se instala a través del paquete caching-nameserver. Almacena la configuración de la zona correspondiente a la interfaz local o loopback para el dominio arpa nombrada in-addr.arpa.

continuación... named.ca : Se instala a través del paquete caching-nameserver. Almacena los datos de los servidores del dominio raíz. minbas.zone : Almacenará la información de la zona minbas.cu a definir. in-addr.arpa.zone : Guardará los datos de la zona especial arpa correspondiente al dominio nombrada in-addr.arpa. El fichero db minbas.zone toma la siguiente forma: $ORIGIN minbas.cu. minbas.cu. IN SOA ns.minbas.cu. admin.ns.minbas.cu.( H M 7D 24H) minbas.cu. IN NS ns.minbas.cu. minbas.cu. IN NS zeus.minbas.cu.

continuación... ns.minbas.cu. IN A zeus.minbas.cu. IN A IN A correo.minbas.cu. IN A mail2.minbas.cu. IN A chat.minbas.cu. IN CNAME ns.minbas.cu. Icq.minbas.cu. IN CNAME ns.minbas.cu. ftp.minbas.cu. IN CNAME ns.minbas.cu. minbas.cu. IN MX 2 correo.minbas.cu. minbas.cu. IN MX 10 mail2.minbas.cu. Hay que tener en cuenta: Siempre que se coloque un nombre de dominio completo, este debe finalizar con un punto pues de no ponerse su interpretación real será la concatenación con el origen. El origen por defecto se nombra igual que la zona descrita, en este caso minbas.cu. aunque puede variarse con la directiva ORIGIN.

continuación... El primer record definido es el SOA: minbas.cu. IN SOA ns.minbas.cu. admin.minbas.cu.( ; 3 horas ; 15 minutos ; 1 semana ) ; 1 día En este se puede observar primeramente el origen, el nombre del servidor primario del dominio y la dirección de correo del administrador del dominio. Para definir la dirección de correo del administrador hay que tener en cuenta que se debe poner un punto (.) en lugar Por último se definen entre paréntesis un grupo de valores: - Número de serie (Serial Number) : Es la versión de los datos de la zona que define el fichero. Se utiliza por los servidores secundarios para determinar si deben transferir o no, la zona correspondiente desde el servidor primario. Este número debe incrementarse cada vez que se haga un cambio en los datos de la zona.

continuación... Intervalo de refrescamiento (Refrech Time) : Indica el intervalo de tiempo dado el cual los servidores secundarios de la zona deben chequear si sus datos están actualizados, de no ser así deben realizar la transferencia de la zona correspondiente. Intervalo de reintento (Retry Time) : Frecuencia con que el servidor secundario reintentará conectarse al primario dado que falló al tratar de hacerlo cuando se alcanzó el intervalo de refrescamiento. Intervalo de expiración (Expire Time) : Intervalo de tiempo dado el cual el servidor secundario expira sus datos si no logra conectarse al servidor primario de la zona. Tiempo de vida mínimo (Minimal Time To Live) : Tiempo de vida por defecto de todos los records en el fichero db. Se asume si no se indica en el record a través de la directiva TTL.

continuación... Todos estos valores se pueden indicar en segundos o utilizando letras para representar a las unidades de tiempo. Por ejemplo para especificar un intervalo de tiempo de una semana, dos días, cinco horas y diez minutos se pondría 1W2D5H10M. En el caso del ejemplo anterior el record SOA se podría escribir de la forma: minbas.cu. IN SOA ns.minbas.cu. admin.minbas.cu. 1 3H 15M 1W 1D

continuación... Los records siguientes en el fichero db permiten definir los servidores de nombres asociados a esta zona. minbas.cu. IN NS ns.minbas.cu. minbas.cu. IN NS zeus.minbas.cu. Luego aparecen los records que indican las direcciones y los alias. El fichero que describe a la zona inversa in-addr.arpa nombrado in-addr.arpa.zone debe tener un aspecto similar al siguiente: in-addr.arpa. IN SOA ns.minbas.cu. admin.minbas.cu. (1 3H 15M W 1D) ; Servidores del dominio in-addr.arpa. IN NS ns.minbas.cu in-addr.arpa. IN NS zeus.minbas.cu. ; Records PTR in-addr.arpa. IN PTR ns.minbas.cu in-addr.arpa. IN PTR zeus.minbas.cu in-addr.arpa. IN PTR in-addr.arpa. IN PTR correo.minbas.cu in-addr.arpa. IN PTR mail2.minbas.cu.

continuación... Para el caso de la interfaz loopback los ficheros que describen sus dos zonas correspondientes, localhost y arpa, se instalan por defecto y se nombran localhost.zone y named.local respectivamente. Sus contenidos ajustados teniendo en cuenta las posibilidades explicadas hasta el momento, se muestran a continuación: ;localhost.zone localhost. IN SOA localhost. root.localhost. 1 8H 4H 1000H 1D localhost. IN NS localhost. localhost. IN A ;named.local in-addr.arpa. IN SOA localhost. root.localhost. 1 8H 4H 1000H 1D in-addr.arpa. IN NS localhost in-addr.arpa. IN PTR localhost.

continuación... Por último se muestra a continuación una versión del fichero named.ca NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET A NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET A NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET A … … NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET A NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET A

continuación... Se puede apreciar en este ejemplo que para cada record se expresa explícitamente el TTL (1000 horas=41 días) mientras que se omite la clase. Este fichero se debe actualizar cada cierto tiempo. Su última versión se encuentra bajo el nombre named.ca en el sitio FTP ftp.rs.internic.net/domain. Existen algunos scripts que permiten automatizar su actualización periódica

continuación... Abreviaturas Existen varias formas para abreviar o reducir el contenido de los ficheros db, las cuales se ejemplifican a continuación: Eliminación de los dominios : Los nombres de dominio se pueden omitir cuando se correspondan con el origen. Gracias a esto a partir de que el origen en el fichero minbas.zone es minbas.cu. la línea siguiente: correo.minbas.cu. IN A se puede poner como: correo IN A También a partir de que el origen en el fichero arpa.zone es in-addr.arpa la línea siguiente: in-addr.arpa. IN PTR correo.minbas.cu. se puede escribir como: 4 IN PTR correo.minbas.cu.

continuación... Si se olvida poner el punto al final del nombre en una línea de la forma: correo.minbas.cu IN A se entendería como el nombre correo.minbas.cu.minbas.cu Si un nombre de dominio es igual al origen se puede sustituir este por el Esta posibilidad es utilizada en los records SOA y NS. En el fichero minas.zone se pondría: @ IN SOA ns admin 1 3D 15 M 1W 1D @ IN NS ns @ IN NS zeus Dominio implícito Si se definen varios records consecutivos referentes al mismo nombre de dominio sólo es necesario especificar este en el primero de ellos, en los demás estará implícito. Por ejemplo en el fichero minbas.zone se podría poner: @ IN SOA ns admin 1 3D 15 M 1W 1D IN NS ns IN NS zeus

continuación... A continuación se muestran los ficheros db aplicando todas las abreviaturas posibles: El fichero minbas.zone: $ORIGIN SOA ns admin H 60M 7D 24H NS ns NS zeus ns A zeus A www A correo A mail2 A router A chat CNAME ns icq CNAME ns ftp CNAME ns @ MX 2 correo MX 10 mail2

continuación... El fichero in-addr.arpa.zone: $ORIGIN SOA ns.minbas.cu. admin.minbas.cu. 1 3H 15M 1W 1D NS ns.minbas.cu. NS zeus.minbas.cu. 9 PTR ns.minbas.cu. 5 PTR zeus.minbas.cu. 6 PTR 4 PTR correo.minbas.cu. 3 PTR mail2.minbas.cu. El fichero localhost.zone: $ORIGIN root 1 8H 4H 1000H 1D A El fichero named.local: $ORIGIN localhost. @ root 1 8H 4H 1000H 1D NS localhost. PTR localhost.

continuación... Fichero de configuración named.conf El fichero de configuración básico de BIND se nombra named.conf y por defecto se instala en el directorio /etc a través del paquete caching-nameserver. El fichero named.conf por defecto posee un contenido similar a este: options { directory "/var/named"; }; zone "." { type hint; file "named.ca"; }; zone "localhost" IN { type master; file "localhost.zone"; }; zone " in-addr.arpa" { type master; file "named.local"; };

continuación... El fichero de configuración está formado por un conjunto de sentencias y comentarios. Las sentencias se terminan con el carácter '';'' y pueden contener dentro de sí a otras sentencias, en estos casos el contenido de la sentencia va encerrado entre {}. Los comentarios pueden ser de varios estilos similares a los de los lenguajes de programación C, C++, Perl y Shell. Tipos de sentencias acl : es una sentencia que permite definir listas de direcciones IP. Su nombre significa Access Control List. Por defecto existen 4 acl definidas, any, none, localhost y localnets. Ejemplo (incluye las redes y y el ): acl danger { { /24; /16; ; }; };

continuación... options : esta sentencia controla toda la configuración del servidor y define las opciones por defecto de otras sentencias. Sólo debe aparecer una vez en el fichero de configuración. Ejemplo: options { directory /var/named; # indica el directorio de trabajo del # servidor. Toda referencia a # fichero relativa lo será a partir # de este directorio allow-query { /16;}; # indica que se permiten las # consultas de todos los hosts con # direcciones que comiencen con # blackhole { danger;}; # especifica que no se les # responda ninguna consulta a los # hosts de la lista danger };

continuación... zone : es una de las sentencias más importantes pues permite definir las zonas y describir sus respectivas configuraciones. Master zone : Es aquella donde el servidor tiene la copia primaria o principal de los datos de la zona. Slave zone : Es la zona cuyos datos son resultado de la réplica de la información de una zona master. Hint zone : Es la zona que contiene la información del conjunto inicial de servidores del dominio raíz. Stub zone : Es una zona igual a la de tipo slave excepto en que en esta sólo se replica la información de los servidores de la zona primaria y no el resto de la información. Forward zone : Es el tipo de zona donde las consultas acerca de sus datos se reenvían a otros servidores. En versiones anteriores de BIND las zonas master, slave y hint se conocían como primary, secondary y cache respectivamente.

continuación... A continuación se muestra a través del ejemplo descrito hasta el momento como se define la zona minbas.cu y in-addr.arpa. zone "minbas.cu" IN { type master; file "minbas.zone"; }; zone " in-addr.arpa" IN { type master; file " in-addr.arpa.zone"; }; Al caracterizar una zona se pueden definir los siguientes atributos: type : indica el tipo de zona. file : para el caso de las zonas cuya información se almacene localmente indica el nombre del fichero donde esta se encuentra. allow-update : indica los hosts autorizados a hacer actualizaciones dinámicas a la zona.

continuación... allow-transfer : indica los hosts autorizados a transferir la información de la zona. allow-query : indica los hosts autorizados a hacer consultas sobre la zona. forward : es un atributo aplicable sólo a las zonas de tipo forward. Puede tomar dos valores first u only, el primero (que es el por defecto) indica que primero se consulte a los hosts especificados en el atributo forwarders y si estos fallan entonces se busque la respuesta localmente, y el segundo sólo consulta a los hosts en forwarders. Ambos atributos se pueden especificar de forma global en la sentencia options.

continuación... Servidor de DNS secundario La configuración de un servidor DNS secundario es mucho más simple, pues implícitamente no se tienen que definir los datos de las zonas. Basta con indicar de donde se van a tomar los datos, o sea que sistema es el master de la zona a configurar. La transferencia de los datos de una zona desde un servidor primario a uno secundario es un proceso que ocurre periódicamente en dependencia de como se haya expresado en el record SOA de la zona. Es importante recalcar que la forma que utiliza un servidor secundario para conocer si necesita transferir una zona o no, dado que se alcanzó el intervalo de refrescamiento, es a través del número de serie. Es por ello que siempre que se realice una modificación en los datos de una zona se tiene que incrementar positivamente este entero si se desea que se propague la transformación a todos los servidores secundarios de la zona.

continuación... Para definir un servidor secundario en Red Hat se deben instalar los mismos paquetes que para el primario, o sea bind, bind-utils y caching-nameserver. Para los clientes del DNS no es relevante si un servidor es secundario o no y de hecho en su configuración se pueden colocar varios para una misma zona. El fichero named.conf del servidor secundario en el host zeus tendría el siguiente contenido: options { directory "/var/named"; }; zone "." { type hint; file "named.ca"; }; zone "localhost" IN { type master; file "localhost.zone"; }; zone " in-addr.arpa" { type master; file "named.local"; };

continuación... zone “minbas.cu" { type slave; file “minbas.zone"; master { ; }; }; zone " in-addr.arpa" { type slave; file “ in-addr.arpa.zone"; master { ; }; }; Como se pudo ver en las zonas de tipo slave se especificó también el atributo file. Esto es necesario ya que si no se tendrían que hacer transferencias continuas de las zonas siempre que no se encuentren las respuestas en la caché, lo cual evidentemente empeoraría el rendimiento y no se manifestarían las ventajas de tener un servidor secundario para estas zonas. También pudiera ocurrir que se reinicie el servidor secundario, lo cual implica necesariamente el vaciado de la caché, y no esté disponible el servidor primario de la zona para efectuar la transferencia.

continuación... Configuración del cliente Como ya se ha dicho anteriormente los clientes del servicio de DNS se denominan resolvers. Estos no constituyen programas independientes sino que son subrutinas integradas o enlazadas a otros programas que necesitan utilizarlas para consultar a un servidor de DNS. Estos deben dominar tres aspectos fundamentales: Los servidores DNS: son los hosts que ejecutan un servidor de DNS disponible para ser consultado El dominio local: es la parte del nombre de dominio del host donde se ejecuta el resolver. La lista de dominios donde buscar: son los dominios donde se buscarán los nombres que no posean dominio explícito. El resolver de Linux posee una configuración muy sencilla a través del fichero /etc/resolv.conf En caso de que este fichero falte o esté vacío se asumirá que el servidor de DNS es el que se ejecuta localmente.

continuación... El fichero resolv.conf consta básicamente de un conjunto de directivas o atributos que se expresan de la forma: <atributo> <valor1> <valor2> ... <valorN> Los atributos pueden ser: nameserver: permite indicar la dirección IP de los servidores de DNS, cada uno a través de una directiva diferente. Ejemplo: nameserver nameserver domain: permite indicar el dominio por defecto. Ejemplo: domain minbas.cu

continuación... search: especifica la lista de dominios donde se harán las consultas. Ejemplo: search minbas.cu ec.minbas.cu options: permite modificar el valor de algunos atributos internos del resolver. Ejemplo: options <opcion1> <opcion2> ... <opcionN> Nota: Entre estas opciones están las del tiempo que esperará el resolver por la respuesta del servidor (timeout:<n>) y el número de intentos que realiza el resolver con cada servidor para obtener un respuesta (attempts:<n>).

continuación... Herramientas para consultar un DNS Hasta la versión 9 de BIND, la herramienta principal para consultar a un servidor de nombres, ya sea para obtener información real o para chequear su configuración, era el programa nslookup desarrollado y distribuido junto a BIND. Nota: A pesar de sus reconocidas potencialidades nslookup se irá sustituyendo por otras dos herramientas nombradas dig y host que poseen propósitos similares. Los tres programas, vienen incluidos en el paquete bind-utils. El programa nslookup La forma más utilizada de invocar este programa es a través del comando nslookup. Una vez invocado la forma de interactuar con el es a través de los siguientes comandos: server <servidor> : cambia el servidor DNS por defecto. <nombre> [servidor] : retorna información acerca del nombre dado a través del servidor que se especifique.

continuación... set <opción>[=<valor>] : Permite modificar el comportamiento de las consultas subsiguientes. Ejemplos : set type=mx # Devuelve los datos de los servidores de correo minbas.cu # del dominio minbas.cu representados a través # de los registros MX

continuación... Ejemplo de uso de nslookup (pregunta a zeus sobre los servidores DNS de minbas.cu) $ nslookup Default Server: ns.minbas.cu Address: > server > set type=ns > minbas.cu Server: ns.minbas.cu Address: minbas.cu nameserver = ns.minbas.cu minbas.cu nameserver = zeus.minbas.cu ns.minbas.cu internet address = zeus.minbas.cu internet address = > exit

continuación... El comando host El comando host es un utilitario que permite hacer búsquedas en el DNS. Se utiliza básicamente para convertir nombres en direcciones IP y viceversa. Sintaxis: host [opciones] <dominio> [servidor] Algunas opciones: -t <tipo> : indica el tipo de record a devolver. Puede ser A, ANY, PTR, NS, etc. -R <n> : permite modificar el número de intentos que se hacen para obtener la respuesta ya que por defecto es uno. -l : lista toda la información del dominio

continuación... Ejemplos: $ host has address $ host -t NS minbas.cu minbas.cu. name server ns.minbas.cu. minbas.cu. name server zeus.minbas.cu. $ host -t PTR in-addr.arpa. domain name pointer mail2.minbas.cu.

Servicio Web (Apache) Actualmente uno de los servicios más difundidos y de gran utilidad en numerosos contextos es el Web. Este no es más que un amplio y diverso conjunto de documentos vinculados de múltiples formas. En los inicios del Web todas las páginas eran estáticas, o sea siempre se mostraban de la misma forma en todas las circunstancias posibles. En la actualidad existe una tendencia a definir estas de forma dinámica de acuerdo a diversas situaciones y necesidades. Debido a esto numerosas aplicaciones ya han adoptado una interfaz Web para interactuar con sus usuarios. La arquitectura del Web es del tipo cliente-servidor. Y es en el servidor donde se almacena la información estática y/o las aplicaciones que la generan. Los clientes por lo general son los programas conocidos como navegadores o browsers que se encargan de contactar a un servidor ante la solicitud de un usuario y visualizar el resultado de acuerdo a su implementación propia.

Servicio Web (Apache) continuación... El protocolo que emplean el servidor y el cliente para comunicarse es el HTTP (HyperText Transport Protocol) o protocolo para la transmisión de hipertexto. Por lo general los servidores Web escuchan las solicitudes de los clientes a través del puerto 80 y es a este a donde se van a dirigir los clientes por defecto para hacer sus solicitudes. La forma que tiene un usuario en el Web de acceder a una página u objeto de forma general es mediante el empleo de su URL la cual está formada fundamentalmente por dos aspectos: el nombre o dirección IP del servidor y el camino relativo del documento dentro del servidor. También pueden incluirse otros aspectos tales como: el puerto por el que se solicita el servicio (se asume por defecto el 80 para HTTP, el 21 para FTP, etc.), y login y password en documentos que requieran autenticación para ser accedidos. Ejemplos:

Servicio Web (Apache) Hospedaje virtual de Sitios Web
continuación... Hospedaje virtual de Sitios Web El mecanismo de hospedaje virtual de sitios Web (Web virtual hosting) consiste en la simulación de que existen varios hosts con sus respectivos sitios Web a través de un solo servidor Web. Cada uno de estos hosts virtuales se identifica con un nombre de dominio y de acuerdo a este son accedidos los documentos asociados al mismo y que en realidad son proporcionados por un único servidor Web. Existen dos variantes de este mecanismo: Aquella donde se asocia a cada host virtual una dirección IP diferente. Y la segunda es cuando se utiliza la misma dirección IP para todos los hosts. La última es la más elegante y conveniente sobre todo en los casos en que el número de hosts tienda a crecer.

Servicio Web (Apache) Hospedaje virtual basado en dirección IP
continuación... Hospedaje virtual basado en dirección IP Es la forma del mecanismo más antigua. En ella cada host virtual tiene su propia dirección IP. Esto puede traer consigo un gran derroche de direcciones IP cuando el número de hosts virtuales es grande. La configuración de esta forma consta de dos pasos: primeramente se debe adecuar al sistema para que acepte las direcciones IP necesarias y luego configurar el servidor Web para que sirva las solicitudes correspondientes a estos hosts virtuales. En Linux asociar más de una dirección IP a una misma interfaz de red no es más que definirle uno o varios alias. Los alias se nombran de acuerdo al nombre de la interfaz principal, por ejemplo para la interfaz eth0 serían: eth0:0, eth0:1, ..., eth0:N. Para crear los alias rápidamente se puede emplear el comando ifconfig. Ejemplo: ifconfig eth0: netmask ifconfig eth0: netmask

Servicio Web (Apache) continuación... Si se necesita definir muchos alias con direcciones consecutivas se puede emplear un lazo tipo for. Por ejemplo, para crear 10 alias numerados entre y para la interfaz eth0 se haría de la forma: # for (( i=0; i<10; i++ )) > do > ifconfig eth0:$i $[$i+20] netmask > done Para que estos alias prevalezcan aun si se reinicia el sistema es necesario, o bien añadir los comandos correspondientes a algún script de inicio (preferiblemente a /etc/rc.d/rc.local), o definirlos como las interfaces de red originales a través de los ficheros correspondientes. El ejemplo anterior definiéndolos a partir de los ficheros de configuración de las interfaces de red se pueden definir en el mismo fichero (ifcfg-eth0:0) cuyo nombre deberá coincidir con el del primer alias, eth0:0. El fichero se colocará en el directorio /etc/sysconfig/network-scripts/. IPADDR= NETMASK=

Servicio Web (Apache) continuación... El resto de los atributos tales como: BOOTPROTO, NETWORK, BROADCAST y ONBOOT, se asumen por defecto. Una vez definidos los alias para activarlos se debe emplear alguna forma conocida. Ejemplo: # service network restart Shutting down interface eth0: [ OK ] Setting network parameters: [ OK ] Bringing up interface lo: [ OK ] Bringing up interface eth0: [ OK ]

Servicio Web (Apache) continuación... Una vez configuradas las direcciones IP alias se debe adecuar el servidor de DNS. Por ejemplo: esib.minbas.cu. A tibs.minbas.cu. A biblioteca.minbas.cu. A in-addr.arpa. PTR esib.minbas.cu in-addr.arpa. PTR tibs.minbas.cu in-addr.arpa. PTR biblioteca.minbas.cu. Después de esto se debe configurar el servidor Web para que atienda y manipule todas las solicitudes de los clientes a los host virtuales (se explicara más adelante).

Servicio Web (Apache) Hospedaje virtual basado en nombres
continuación... Hospedaje virtual basado en nombres El hospedaje virtual basado en nombres utilizando una dirección IP compartida es la forma más novedosa del mecanismo. Se definió a partir de la versión 1.1 de HTTP. Aquí no es necesario configurar más de una dirección IP ya que se emplea la misma para todos los hosts virtuales, los cuales se distinguirán sólo a través del nombre de dominio. Por tanto sólo es necesario configurar el servidor de DNS, asociando todos los nombres de dominio correspondientes a la dirección IP del servidor Web a través de records de tipo address o cname. Por ejemplo: esib.minbas.cu. A tibs.minbas.cu. A biblioteca.minbas.cu. A Por supuesto también se debe configurar al servidor Web de la misma forma en que se hace para el mecanismo basado en varias direcciones IP y que se explicará más adelante.

Servicio Web (Apache) El servidor Web Apache en Linux
continuación... El servidor Web Apache en Linux Apache surgió a partir del servidor de HTTP más famoso y difundido en su época: NCSA. Desde entonces se convirtió en un poderoso rival de todos los servidores Unix utilizados hasta la fecha por su eficiencia, funcionalidad y rapidez. Es por ello que se conoce como el rey de los servidores Web. Se desarrolla de forma estable y segura gracias a la cooperación y los esfuerzos de un grupo de personas conocidas como grupo Apache (Apache Group), los cuales se comunican a través de Internet y del Web. Juntos se dedican a perfeccionar el servidor y su documentación regidos por la ASF (Apache Software Foundation). En la actualidad Apache es el servidor Web más utilizado en el mundo de acuerdo con las estadísticas de que lo colocan en más de 7 millones de servidores que sirven poco más de 18 millones de sitios Web, lo que significa más del 60% en todo el mundo.

Servicio Web (Apache) continuación... Entre las características principales del Apache se encuentran: Es un servidor Web potente, flexible y ajustado al HTTP/1.1 Es altamente configurable. Puede ser ajustado a través de la definición de módulos. Provee todo su código fuente de forma libre y se distribuye bajo una licencia no restrictiva. Se ejecuta en diversas plataformas operativas tales como: Windows 9x/NT, Macintosh, Novell NetWare, OS/2, Linux y la mayoría de los Unix existentes: IRIX, Solaris, HPUX, SCO, FreeBSD, NetBSD, AIX, Digital Unix, etc. Se desarrolla de forma acelerada estimulando la retroalimentación desde sus usuarios a través de nuevas ideas, reportes de errores y parches. Apache significa ''A PAtCHy sErver'', o sea se basa en un código y un conjunto de ficheros ''parches''. Otros desarrolladores relacionan su nombre con el de las tribus nativas americanas de Apaches.

Servicio Web (Apache) continuación... El paquete de la distribución Red Hat que contiene la implementación del servidor Apache para Linux se nombra apache. También se dispone de un manual del mismo en el paquete apache-manual. Y también existe una aplicación con interfaz gráfica en el paquete apacheconf que permite configurar al Apache con las limitaciones propias de dichas interfaces. El Apache en Red Hat se ejecuta a través de un daemon llamado httpd que se manipula utilizando el script de inicio del mismo nombre en /etc/rc.d/init.d/. Por tanto la forma más sencilla de iniciar, detener, conocer el estado o indicar que relea su configuración al daemon es como se muestra en los ejemplos: # service httpd start Starting httpd: [ OK ] # service httpd reload Reloading httpd: [ OK ]

Servicio Web (Apache) Configuración de Apache
continuación... Configuración de Apache Una vez instalado el paquete del Apache, el directorio de la configuración será /etc/httpd/conf/. Los ficheros de configuración agrupados en este directorio están formados por un conjunto de directivas que regulan el comportamiento del servidor. Además se pueden incluir comentarios precedidos por el caracter ''#'' como es tradicional. El fichero de configuración principal de Apache, y el único que se debe modificar de los existentes, se nombra httpd.conf En versiones anteriores se empleaban otros dos ficheros nombrados srm.conf y access.conf. Apache procesa estos ficheros en el orden en que se mencionaron. En las versiones actuales se recomienda escribir todas las directivas de configuración en httpd.conf y deshabilitar la lectura de los otros ficheros en la propia configuración.

Servicio Web (Apache) continuación... De los tres ficheros de configuración mencionados el más importante es httpd.conf. Este se divide en tres secciones con fines puramente organizativos: Sección 1: reúne los aspectos globales del servidor. Sección 2: agrupa las directivas que definen la forma de responder a todos los pedidos del servidor principal, o sea aquellos que no son para los hosts virtuales, de existir alguno definido. También reúne los aspectos por defecto de todos los hosts virtuales que se configuren más adelante. Sección 3: agrupa las directivas relacionadas con los hosts virtuales que se definan. Este fichero de configuración contiene una gran cantidad de directivas. A continuación vamos a ver las directivas más importantes y necesarias para que apache trabaje en su forma básica.

Servicio Web (Apache) Directivas en la sección 1
continuación... Directivas en la sección 1 ServerRoot <directorio> Permite indicar el directorio raíz del servidor. A partir de aquí se buscarán el resto de los ficheros de configuración, el directorio de logs, los módulos, etc. Por defecto es /etc/httpd Ejemplo: ServerRoot "/etc/httpd" Directivas en la sección 2 ServerAdmin <dirección de correo> Especifica la dirección de correo a la cual deben enviarse los errores en el servicio. Se coloca en algunas páginas de error generadas por el servidor. Por defecto es Ejemplo: ServerAdmin

Servicio Web (Apache) continuación... ServerName <nombre> Indica el nombre de dominio que identifica al servidor. Este debe ser un nombre válido en el servicio de nombres de dominio. En caso de que no se posea un nombre de dominio se podrá utilizar la dirección IP de la máquina. Ejemplo: ServerName DocumentRoot <directorio> Indica el directorio a partir del cual se localizarán todos los documentos provistos por el servidor. Por defecto es /var/www/html. Esto indica que si se realiza el pedido el documento devuelto será /var/www/html/manual/index.html. Ejemplo: DocumentRoot "/var/www/html" DirectoryIndex <ficheros> Indica los ficheros que se devolverán en caso de que se solicite un directorio, o sea cuando se haga un pedido del tipo se devolverá el primer fichero de los indicados en esta directiva que exista dentro del directorio manual/. Por defecto, los ficheros son: index.html, index.htm, index.shtml e index.cgi Ejemplo: DirectoryIndex index.html default.html index.cgi start.cgi

Correo Electrónico (Sendmail)
El correo electrónico es el servicio más utilizado de todos los que existen actualmente de arquitectura cliente-servidor. Los progamas servidores que permiten transportar el correo electrónico de una máquina a otra a través de la red son denominados MTAs (Mail Transport Agent). Como ejemplos de MTAs se pueden citar a Sendmail, Qmail, Postfix y otros. Todos hablan el mismo idioma, o sea utilizan un protocolo común para la comunicación: el SMTP (Simple Mail Transfer Protocol). Normalmente los servidores de correo utilizan el puerto 25 para comunicarse mediante el SMTP. Por otro lado se encuentran los MUAs (Mail User Agents) que son los programas clientes que posibilitan a los usuarios manipular su mensajería. Estos programas son ejecutados directamente por los usuarios y brindan facilidades para escribir los mensajes, enviarlos, descargar y leer los que llegan, etc. Ejemplos de MUAs en Linux son los progamas: pine, mail, mutt y elm.

continuación... Para enviar los mensajes, los MUAs se pueden conectar a un MTA determinado utilizando SMTP o escribir los mensajes directamente en el buzón si este es local. En cambio para descargar la mensajería un MUA puede hacerlo localmente o emplear alguna variante de dos protocolos fundamentales: POP o IMAP. Estos se diferencian en que el primero descarga la mensajería en la máquina local y el segundo permite manipularla directamente en el servidor y descargarla selectivamente. Para que un MTA permita descargar la mensajería desde un MUA utilizando uno de estos protocolos (POP o IMAP) debe ejecutarse también un programa servidor de POP o IMAP que brinde dicha funcionalidad. Actualmente en el caso de POP se emplea su versión 3 conocida como POP3.

Representación esquemática del servicio de correo electrónico
Correo Electrónico (Sendmail) continuación... Representación esquemática del servicio de correo electrónico

continuación... Servicio POP3 e IMAP En la distribución Red Hat ambos servicios se instalan a través del paquete nombrado imap. Por defecto constituyen servicios controlados por xinetd por lo que requieren de este daemon para que funcione. Los ficheros de configuración se estos protocolos se encuentran en el directorio /etc/xinetd.d/. Para el protocolo POP3 el fichero de configuración se llama ipop3. Para el protocolo IMAP el fichero de configuración se llama imap. Una vez instalado el servicio solo es necesario habilitar la variante que se desee brindar a los clientes.

continuación... Por defecto todas están deshabilitadas. Por ejemplo en el caso del POP3 se deberá poner a no o eliminar el atributo disable del fichero ipop3, y luego ejecutar: # service xinetd reload Reloading configuration: [ OK ] El servidor de POP3 por defecto escucha por el puerto 110, mientras que IMAP lo hace por el 143. Los mensajes de los usuarios del sistema se almacenan en el directorio /var/spool/mail y es aquí donde los servidores POP3 o IMAP realizan sus acciones.

continuación... El cliente mail El comando mail es un programa interactivo muy sencillo que permite utilizar el correo electrónico local en un sistema Unix o similar. Para enviar un mensaje es necesario invocar el comando pasandole como parámetro la dirección de correo del destinatario. Ejemplo: # mail Una vez hecho esto el sistema pedirá que se introduzca el asunto del mensaje, después se podrá introducir el texto completo del mensaje. Para indicarle al sistema que se terminó de teclear el texto del mensaje se debe presionar ctrl+d. Por ultimo se deberá teclear una dirección de correo de la persona a la que se le quiere enviar una copia de este mensaje o en su defecto teclear retorno para dejarlo en blanco.

continuación... El MTA Sendmail El Sendmail es el MTA de código abierto más conocido y utilizado actualmente en Internet. La distribución Red Hat 7.1 ofrece la versión de Sendmail en el paquete nombrado sendmail. También existe un paquete con la documentación oficial de Sendmail nombrado sendmail-doc y que instala dicha documentación en el directorio /usr/share/doc/sendmail El Sendmail una vez instalado, posee un script de inicio con su mismo nombre. Ejemplos de su utilización son los siguientes: # service sendmail start Starting sendmail: [ OK ] # service sendmail status sendmail (pid 961) is running... # service sendmail reload Shutting down sendmail: [ OK ] Starting sendmail: [ OK ]

continuación... Configuración del Sendmail El fichero de configuración fundamental del Sendmail es el /etc/sendmail.cf. Este posee una sintaxis tan compleja que lo hace casi inmanipulable por la mayoría de los que lo necesitan. Afortunadamente existe la posibilidad de configurar a Sendmail empleando un fichero menos engorroso y que se almacena bajo el nombre sendmail.mc en el directorio /etc/mail/. El mismo se procesa utilizando el programa m4 que genera el fichero principal. Este fichero se encuentra disponible una vez instalado el paquete sendmail-cf La forma de utilizar m4 para generar el fichero de configuración principal del Sendmail a partir del fichero sendmail.mc es la que se muestra a continuación: # m4 /etc/mail/sendmail.mc > /etc/sendmail.cf # service sendmail reload # para establecer la nueva configuración

continuación... El fichero sendmail.mc puede contener diversas macros, cada una de las cuales expresa los distintos aspectos de la configuración del Sendmail. Es común ver además en este fichero, al final de las líneas, la secuencia dnl. Esta significa que a partir de donde se encuentre, todos los caracteres incluyendo el próximo cambio de línea, serán borrados, y por ende no interpretados por el macroprocesador. Este es el aspecto más significativo que se debe conocer acerca del funcionamiento interno de m4: que el procesamiento no es basado en líneas sino en flujos. Es por ello que la forma de indicar un comentario (algo que no se interprete como parte de la configuración) en el fichero ''mc'', es colocándole una secuencia dnl en el inicio, y a partir de esta solo se interpretará lo que aparezca después del próximo cambio de línea.

continuación... Ejemplo: dnl This is the sendmail macro config file. If you make change of this file, dnl you need de sendmail-cf rpm intalled define(‘ALIAS_FILE’, ‘/etc/aliases’)dnl define(‘STATUS_FILE’, ‘/var/log/sendmail.st’)dnl

continuación... Existen dos macros muy empleadas en el fichero ''mc'': la macro define y la macro FEATURE. La primera tiene la forma define(A, B) lo cual significa que la macro ''A'' toma el valor ''B''. Ambos valores deben colocarse entre comillas simples opuestas (‘’) para evitar que sean expandidos a su vez como nuevas macros. Ejemplos: define(`SMART_HOST', `deltha.redhat.com')dnl define(`ALIAS_FILE', `/etc/aliases')dnl En el caso de FEATURE se emplea para habilitar una posibilidad o característica determinada. Puede contener uno o más argumentos. FEATURE(`mailertable', `hash -o /etc/mail/mailertable')dnl FEATURE(always_add_domain)dnl

continuación... En el directorio /etc/mail/ se agrupan además otros ficheros que son también importantes para sendmail. Estos ficheros tienen una estructura en forma de tablas pero sendmail no los entiende así y es por eso que se utiliza el comando makemap para generar otro fichero con extensión ''db'' que es el que entiende sendmail. Este comando (makemap) viene en el paquete sendmail. Al comando se le pasa como parámetro el formato (puede ser hash o btree) y el nombre del fichero a generar y posteriormente el fichero que contiene la información. Ejemplos: # makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable # cat /etc/mail/mailertable | makemap hash /etc/mail/mailertable.db Cuando se hacen cambios en las tablas no es necesario reiniciar sendmail. Solamente generar el respectivo fichero .db para que sendmail cuando lo vuelva leer se actualice.

continuación... A continuación se describen algunos ficheros que contienen estas tablas: access : especifica las reglas de acceso al servidor por otros sistemas, o sea, desde donde el servidor va a recibir mensajería, por defecto es solo desde localhost. domaintable : contiene una tabla con la traducción de algunos nombres de dominio a otros. mailertable : contiene las rutas de la mensajería que pasa a través del servidor. virtusertable : contiene un conjunto de alias a nivel de dominios, que permiten hospedar varios dominios virtuales en una máquina. aliases : contiene los alias para los usuarios. A diferencia de los anteriores se encuentra ubicado en el directorio /etc. Este fichero se puede generar utilizando cualquiera de los tres comandos siguientes: # makemap hash /etc/aliases.db < /etc/aliases # newaliases # sendmail -bi

continuación... Por defecto Sendmail una vez instalado en Red Hat 7.1, está configurado para transportar la mensajería a cualquier host alcanzable a través del protocolo SMTP. También es capaz de manipular la mensajería intercambiada entre los usuarios del sistema pero no escucha conexiones a través de ninguna interfaz de red externa, por lo que no se puede recibir correos provenientes de otros sistemas. Lo cual se logra a través de la configuración inicial del fichero access Ejemplo: localhost.localdomain RELAY localhost RELAY RELAY Para que todo funcione correctamente debe también existir el registro MX correspondiente en el servidor DNS. Por ejemplo si el dominio es minbas.cu y el servidor es mail2.minbas.cu debe aparecer la línea siguiente en el fichero de la zona minbas.cu. minbas.cu. IN MX 2 mail2.minbas.cu.

continuación... Como manipular la cola de mensajes Por defecto, la cola de los mensajes enviados se almacena en el directorio /var/spool/mqueue. En él existe un par de ficheros por cada mensaje, uno contiene información asociada al mensaje y otro el contenido de este propiamente. Para observar dicha cola en un formato más claro se puede emplear el comando mailq. La salida de este comando es en forma de tabla donde cada entrada muestra: El identificador del fichero que contiene al mensaje. El tamaño del mensaje en bytes. El momento en que llegó el mensaje a la cola. El que envía el mensaje. El recipiente a donde debe ser enviado el mensaje. Si el mensaje no ha podido ser entregado se muestra también la razón del fallo.

continuación... Ejemplo: # mailq -Queue ID- --Size Arrival Time Sender/Recipient E1324FDC Sat Jun 16 10:55: (Name service error for redhat.cu: Host not found, try again) B09DC24FE Sat Jun 16 11:15:22 -- 0 Kbytes in 2 Requests.

continuación... Rutas y formas de trasmisión de la mensajería Sendmail puede trasmitir la mensajería utilizando varias formas, conocidas como mailers. El mailer más empleado es el smtp, otros mailers son el local para la mensajería local y el uucp para la que se transmite utilizando UUCP (Unix to Unix Copy Program). Los mailers se pueden añadir utilizando la macro MAILER en sendmail.mc. Ejemplos: MAILER(local)dnl MAILER(smtp)dnl MAILER(uucp)dnl Otros mailers son procmail, usenet, etc. La definición de los mailers siempre debe aparecer al final del fichero sendmail.mc y se debe colocar el mailer smtp antes del uucp. Para definir las rutas de la mensajería que manipula un Sendmail se utiliza fundamentalmente la base de datos contenida en el fichero mailertable. En el se indica que lo que va para un lugar (dominio) se transmita hacia otro lugar y por que vía.

continuación... Para expresar el origen de la mensajería se puede indicar un dominio completo, poniendo el nombre precedido por un punto, o nombres de hosts específicos. En el segundo campo se especificará que mailer se emplea de los definidos separado por el caracter '':'' del nombre del host al cual estará dirigida esta mensajería. En el caso de que se emplee el mailer local se indicará en lugar de un nombre de host, el nombre de un usuario. También en lugar de un mailer se puede poner un código de error y un texto que se le enviará al origen.

continuación... Ejemplos: ec.minbas.cu smtp:antivirus.minbas.cu # toda la mensajería # dirigida a ec.minbas.cu se # trasmitirá a # antivirus.minbas.cu por # SMTP mail2.minbas.cu local:admin # todo lo dirigido a la # máquina mail2.minbas.cu # se enviará al usuario local # admin .minbas.cu local: # todo lo dirigido al dominio # minbas.cu se enviará al # usuario local del mismo # login que el del destino

continuación... Para trasmitir la mensajería cuyo origen no satisfaga ninguna de las reglas especificadas en mailertable se puede emplear un host cuyo nombre se indica a través de la macro define y la variable SMART_HOST en el fichero sendmail.mc. Ejemplo: define('SMART_HOST', 'smtp:mail2.minbas.cu')dnl Para transferir la mensajería local, o sea aquellos mensajes sin dominio especificado, se puede emplear la variable LOCAL_RELAY. define('LOCAL_RELAY', 'smtp:mail2.minbas.cu')dnl Para transferir toda la mensajería local (la que llega) pero debidamente cualificada a un host determinado se puede emplear la variable MAIL_HUB. define('MAIL_HUB', 'smtp:mail2.localdomain')dnl

continuación... Definir alias para los usuarios También se puede definir tanto un alias para un usuario como para un grupo de estos así como la posibilidad de asignarle a un usuario el nombre de otro con lo cual se logrará redireccionar la mensajería del primero al segundo. Todo esto se configura de forma muy sencilla mediante el fichero /etc/aliases. Cada línea en este fichero representa un alias y tiene la forma: <usuario | alias>: <usuario1 | alias1>, <usuario2 | alias2>, ... O sea, cada línea es una regla que está formada por dos partes: el alias o el nombre de un usuario seguido del carácter '':'', y el conjunto de usuarios o de otros alias separados por espacios. Siempre que se modifique el fichero de alias hay que actualizar el ''.db'' correspondiente. Por ejemplo: # newaliases /etc/aliases: 38 aliases, longest 10 bytes, 377 bytes total # makemap hash /etc/mail/aliases.db < /etc/mail/aliases

continuación... Definir alias para el servidor Al servidor se le pueden asignar varios nombres además del que tiene el sistema propiamente. De esta forma se logra que él acepte como suya la mensajería dirigida a esos nombres. Esto se hace a través del fichero /etc/mail/local-host-names en el cual se coloca un nombre por línea. Ejemplo: mail2.minbas.cu ec.minbas.cu Cuando se modifica este fichero es necesario reiniciar el Sendmail para que tengan efecto los cambios.

continuación... Limitar el tamaño de los correos Para limitar el tamaño de los correos enviados o recibidos se hace en correspondencia con los mailers activados en el fichero /etc/mail/sendmail.mc Para ello se utiliza la macro define con distintas variables. El tamaño se especifica en bytes. Ejemplos: define('LOCAL_MAILER_MAX', ' ')dnl define('SMTP_MAILER_MAX', '800000')dnl define('UUCP_MAILER_MAX', '300000')dnl Para indicar todos estos aspectos en una sola declaración se puede utilizar la variable confMAX_MESSAGE_SIZE.

continuación... Ejemplo: define(`confMAX_MESSAGE_SIZE', `900000')dnl El tamaño del header de los mensajes recibidos se puede restringir con confMAX_HEADERS_LENGTH. define(`confMAX_HEADERS_LENGTH', `65536')dnl

continuación... Limitar la cantidad de recipientes por correo Para restringir el número de recipientes al cual se puede enviar un correo desde el servidor o a través de él, se utiliza la variable confMAX_RCPTS_PER_MESSAGE. Ejemplo: define('confMAX_RCPTS_PER_MESSAGE', '100')dnl Por defecto son 256 recipientes para cada correo. Tiempo de retorno de los correos con problemas en su entrega Para indicar el tiempo dado el cual retorna un mensaje a su remitente debido a problemas en la entrega, se utilizan las siguientes variables: confTO_QUEUERETURN: para todos los mensajes. Por defecto son 5 días. confTO_QUEUERETURN_NORMAL: para los mensajes con prioridad normal. confTO_QUEUERETURN_URGENT: para los mensajes con prioridad alta. confTO_QUEUERETURN_NONURGENT: para los mensajes con prioridad baja.

continuación... Para indicar el tiempo dado el cual se le envía una advertencia al remitente de un mensaje, con el objetivo de avisarle de que la entrega del mismo ha sido retrasada se utilizan: confTO_QUEUEWARN: para todos los mensajes. Por defecto son 4 horas. confTO_QUEUEWARN_NORMAL: para los mensajes con prioridad normal. confTO_QUEUEWARN_URGENT: para los mensajes con prioridad alta. confTO_QUEUEWARN_NONURGENT: para los mensajes con prioridad baja Ejemplos: define(`confTO_QUEUERETURN', `3d')dnl define(`confTO_QUEUEWARN', `3h')dnl define(`confTO_QUEUERETURN_URGENT', `1d')dnl

continuación... Permitir el paso de correos hacia otros servidores (relaying) Actualmente la configuración por defecto del Sendmail indica que este no acepte el traspaso (relaying) de la mensajería proveniente de cualquier otro agente MTA diferente de él mismo. Para configurar dicho traspaso se utiliza el fichero /etc/mail/access. En este fichero el primer valor se corresponde con direcciones de usuarios, nombres de host o nombres de dominios en general. El segundo valor expresa la acción a realizar. Dichas acciones pueden ser: OK : se aceptan conexiones para enviar mensajes a direcciones locales al servidor, pero no se permiten transferencias a otros servidores. RELAY : se permite la transferencia de correo hacia otros servidores.

continuación... REJECT : se deniega el acceso totalmente retornando un mensaje de error. DISCARD : es igual a REJECT, o sea se niega todo acceso, pero se hace de forma silenciosa sin devolver los mensajes. Ejemplo: minbas.cu RELAY moa.minbas.cu RELAY mail2.minbas.cu RELAY FIN

Servicios de RED (Parte II)

Presentaciones similares

Presentación del tema: "Servicios de RED (Parte II)"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Servicios de RED (Parte II)

Presentaciones similares

Presentación del tema: "Servicios de RED (Parte II)"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback