DHCP (Dynamic Host Configuration Protocol) I

        DHCP es un protocolo de red que permite a los clientes de una red IP obtener sus parámetros de configuración automáticamente. Se trata de un protocolo de
tipo cliente/servidor en el que generalmente un servidor posee una lista de direcciones IP dinámicas y las va asignando a los clientes conforme éstas van estando libres, sabiendo en todo momento quién ha estado en posesión de esa IP, cuánto tiempo la ha tenido y a quién se la ha asignado después.
      
       DHCP se deriva de del protocolo Bootstrap (BOOTP). BOOTP fue de los primeros métodos para asignar de forma dinámica, direcciones IP a otros equipos (ordenadores, impresoras, etc.). Al ser las redes cada vez más grandes, BOOTP ya no era tan adecuado y DHCP fue creado para cubrir las nuevas demandas.

       Objetivos de diseño

–DHCP debe ser un mecanismo más que una política. Debe permitirle a los administradores del sistema, donde se desee, tener control sobre los parámetros de configuración. Los administradores del sistema, deberían ser capaces de asegurar las políticas correspondientes a la cantidad y el acceso a los recursos locales donde sea deseado.

–Los clientes no deberían requerir ser configurados manualmente. Cada cliente
debería ser capaz de detectar los parámetros adecuados en la configuración local sin la intervención de los usuarios e incorporar dichos parámetros en su propia configuración.

–La red no debería requerir configuración manual para clientes individuales. Bajo circunstancias normales, el manager de la red, no tendría que introducir los parámetros de configuración por cliente.

–DHCP no debería requerir un servidor por cada subred. Para permitir tener
escalabilidad y por economía, DHCP debe trabajar a través de routers o agentes BOOTP.

–Un cliente DHCP debe estar preparado para recibir múltiples respuestas a un
pedido de parámetros de configuración. Algunas instalaciones pueden incluir múltiples servidores superponiéndose por confiabilidad y para aumentar la performance.

–DHCP debe coexistir con hosts estáticamente configurados y con implementaciones de protocolos de red existentes.

–DHCP debe interoperar con el comportamiento de los agentes BOOTP como esta descrito en las RFC 951 y RFC 1542.

–DHCP debe proveerle servicio a los clientes BOOTP existentes.



  Objetivos de diseño específicos para la capa de red. DHCP debe:

–Dar garantía de que una dirección de red especifica no va a estar en uso por mas de un cliente DHCP a la vez.

–Retener la configuración de un cliente DHCP durante un reboot del mismo. A un cliente DHCP debería, siempre que sea posible, serle asignados los mismos parámetros de configuración en respuesta a cada pedido.

–Retener la configuración de un cliente DHCP durante un reboot del servidor, y,
siempre que sea posible, a un cliente DHCP deberían serle asignados los mismos
parámetros de configuración a pesar de restarts en el mecanismo DHCP.

–Permitir la asignación automatizada de parámetros de configuración para nuevos clientes para evitar su configuración a mano.

–Soportar parámetros de configuración permanentes para clientes específicos.

Patrones de Diseño

Diseño de Software Orientado a Objetos

Patrones de diseño o más comúnmente conocidos como "Design Patterns". ¿Qué son los patrones de diseño? Son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan.
Es evidente que a lo largo de multitud de diseños de aplicaciones hay problemas que se repiten o que son análogos, es decir, que responden a un cierto patrón. Sería deseable tener una colección de dichos patrones con las soluciones más óptimas para cada caso. En este artículo presentamos una lista con los más comunes y conocidos.
Los patrones de diseño no son fáciles de entender, pero una vez entendido su funcionamiento, los diseños serán mucho más flexibles, modulares y reutilizables. Han revolucionado el diseño orientado a objetos y todo buen arquitecto de software debería conocerlos.
A continuación una lista con los patrones de diseño a objetos más habituales publicados en el libro "Design Patterns", escrito por los que comúnmente se conoce como GoF (gang of four, "pandilla de los cuatro").

Patrones de creación

• Abstract Factory. Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas.
• Builder. Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones.
• Factory Method. Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos.
• Prototype. Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo.
• Singleton. Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.
  

Patrones estructurales

• Adapter. Convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.
• Bridge. Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente.
• Composite. Combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.
• Decorator. Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.
• Facade. Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar.
• Flyweight. Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.
• Proxy. Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.
  

Patrones de comportamiento

• Chain of Responsibility. Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto.
• Command. Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones.
• Interpreter. Dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje.
• Iterator. Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.
• Mediator. Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente.
• Memento. Representa y externaliza el estado interno de un objeto sin violar la encapsulación, de forma que éste puede volver a dicho estado más tarde.
• Observer. Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.
• State. Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto.
• Strategy. Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan.
• Template Method. Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura.
• Visitor. Representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.
  

Postfix - Configuración y Puesta en Marcha III

DEL ARCHIVO DE CONFIGURACION

El formato general del archivo de configuración (main.cf) sigue el siguiente formato. (El siguiente texto es tomado textualmente de la documentación ofiicial de Postfix. http://www.postfix.org/postconf.5.html).

• Cada línea de configuración obedece al formato "parametro = value". Los espacios en blanco alrededor del signo "=" son ignorados, igualmente sucede con los espacios en blanco al final de cada línea.
• Líneas vacías y líneas que solo contengan espacios en blanco son ignoradas. Igualmente se ignoran todas las líneas que cuyo primer caracter no sea el espacio en blanco sino el caracter "#".
• Cada línea válida de configuración comienza con texto diferente de espacio en blanco. Sin embargo, una línea que comience con espacio en blanco, seguirá siendo una línea de configuración válida.
• El valor asignado a un parámetro puede hacer referencia a los valores de otros parámetros:
  

  • Las expresiones"$name", "${name}" o "$(name)" son recursivamente reemplazadas por el valor del parámetro al que están haciendo referencia.
  • La expresión "${name?value}" se extiende a "value" cuando "$name" no está vacía. Solo se soporta en versiones de Postfix 2.2 ó superiores.
  • La expresión "${name:value}" se extiende a "value" cuiando "$name" está vacía. Solo se soporta en versiones de Postfix 2.2 ó superiores.
• Cuando un mismo parámetro es definido varias veces, solo aplica a la configuración, la última instacia encontrada del mismo.
• En cualquier otro caso, el orden de los parámetros definidos en main.cf no es importante.

DEL RELAY

La verdad es que Postfix es tan bueno, que por defecto sin decirle nada es capaz de hacer Relay a todo el conjunto de clientes que se encuentren en la misma subred de cada interface de red que tengamos conectada al sistema. Por ejemplo, suponiendo que tenemos una máquina con tres interfaces de red así:

10.1.0.254  MASK 255.255.0.0
192.168.1.254          MASK 255.255.255.0
200.1.2.3  MASK 255.255.255.248

Suponiendo que la interface con la IP 200.1.2.3 es nuestra interface externa, Postfix es capaz de hacerle Relay por defecto a todos los clientes que se encuentren en la subred 10.1.0.0/255.255.0.0 y la subred 192.168.1.0/255.255.255.0. Postfix también sabe que la interface 200.1.2.3 es la externa y que a esa subred no se le debe hacer Relay. Sin embargo hay dos parámetros en el archivo de configuración de Postfix, que pueden sintonizar al gusto de ustedes el tema del Relay. Ambos parámetros son los siguientes:

mynetworks_style 
mynetworks
  

No voy a entrar a explicarlos, son sumamente simples y como Postfix le hace Relay por defecto a los clientes que se encuentran en la misma subred creo que no hace falta entrar ahora en esos detalles. Si se pasan por esta página http://www.postfix.org/BASIC_CONFIGURATION_README.html, se van a dar cuenta lo simples que son.
Entre otras cosas, ¿qué es el Relay?. Tomen esta explicación del concepto de Open Relay.
- http://es.wikipedia.org/wiki/Open_Relay

Postfix - Configuración y Puesta en Marcha II

Las directivas mínimas, para tener nuestro Postfix corriendo a las mil maravillas son las siguientes:

mydomain =

El nombre del dominio de Internet para este sistema de correo; por defecto se utiliza el valor de la variable $myhostname sin el primer componente del valor de la misma. El valor de la variable $mydomain se utiliza por defecto en muchos otros parámetros de la configuración de Postfix.

Ej:

mydomain = antel.com.uy

myhostname =

Especifique el nombre de Internet para este host. El valor de esta variable debe ser un nombre FQDN resoluble a través de consultas DNS.

Ej:

myhostname = mail.antel.com.uy

Ustedes saben que el servicio de correo va muy de la mano con el DNS, quizá en otro artículo haga más detalle sobre el DNS, pero por ahora solo puedo decirles lo que explico aquí. Por ejemplo, el valor de esta directiva aparece en el banner SMTP cuando se establece una sesión SMTP con nuestro servidor de correo Postfix, por ejemplo:

telnet 192.168.1.1 25
220 mail.antel.com.uy ESMTP Postfix

Aquí solo estoy ejemplificando el uso de esta variable, pero la verdad es que se utiliza para más parámetros de la configuración de Postfix.

myorigin =

Especifique el dominio de Internet con el que se originan los mensajes de correo salientes de este servidor de correo. Este es el dominio que aparece en el campo “From” de los mensajes de correo.

Ej:

myorigin = $mydomain

ó bien,

myorigin = antel.com.uy

En otras palabra, cuando ustedes envíen un mensaje de correo a través del servidor Postfix, el destinatario final verá en el campo "From:" ó en el campo "De:" (para los hispano hablantes) del mensaje de correo, algo como:

From: Juan Sosa 

En caso de que se coloque

myorigin = $myhostname

Entonces el destinatario final de nuestros correos vería algo como:

From: Juan Sosa 

mydestination =
Especifique los dominios de Internet que este sistema de correo atiende.
Ej:

mydestination = $mydomain localhost.localdomain localhost $myhostname

ó bien,

mydestination = antel.com.uy localhost.localdomain localhost mail.antel.com.uy

Es con este parámetro que le estamos diciendo a Postfix cuales dominios de Internet atiende para el correo. Si, como ya habrán sacado sus conclusiones, es con este parámetro que le decimos a Postfix que reciba el correo que va dirigido para antel.com.uy, localhost.localdomain, localhost y mail.antel.com.uy. ¿Oiste Juan, y porque tantos valores para este parámetro?. Pues porque la novia que tenemos en la empresa X y la novia que tenemos en la empresa Y no son las únicas que nos mandan correo a juan@antel.com.uy. Dentro del mismo servidor de correo hay aplicaciones que envían notificaciones vía correo electrónico a los administradores de las mismas (notificando algún evento particular), generalmente estas aplicaciones envían mensajes de correo de la siguiente manera: root@localhost ó root@localhost.localdomain ó juan@mail.antel.com.uy ó postmaster@localhost.localdomain. Por esta razón es que hay que decirle a Postfix que reciba el correo para todas estas denominaciones.

inet_interfaces =

Especifique las direcciones IP de las Interfaces por las cuales se desea que Postfix quede a la escucha del servicio SMTP. Si desea configurar el servicio en todas las interfaces, asigne a esta variable el valor all.
Ej:

inet_interfaces = all
inet_interfaces = loopback-only (Postfix 2.2 and later)
inet_interfaces = 127.0.0.1
inet_interfaces = 127.0.0.1, [::1] (Postfix 2.2 and later)
inet_interfaces = 192.168.1.2, 127.0.0.1
    

Como sabemos, el servicio de correo pone un Socket TCP en el puerto 25, con este parámetro le decimos a Postfix en que interface de red vamos a colocar el Socket TCP/25 a la escucha de las peticiones. Si lo que estamos configurando es un servicio que está disponible desde Internet, entonces deberíamos asignar el valor all a esta variable. Con el valor all ponemos un Socket TCP/25 en todas las interfaces de red que tengamos, es decir, si tenemos tres interfaces de red así:

127.0.0.1
192.168.1.1
200.1.2.3
 

Una petición dirigida a 127.0.0.1 puerto 25, será válida, lo mismo sucede con las peticiones hechas a 192.168.1.1 y 200.1.2.3.

• Ahora si, con la explicación anterior, agregamos al final del archivo main.cf, los parámetros explicados:

mydomain = antel.com.uy
myhostname = mail.antel.com.uy
myorigin = $mydomain
mydestination = $mydomain localhost.localdomain localhost $myhostname
inet_interfaces = all

• Hemos finalizado la configuración. Guardamos los cambios en el archivo main.cf e iniciamos nuestro servidor Postfix de la siguiente manera:

  /etc/init.d/postfix start

• Para hacer que nuestro servidor Postfix arranque cuando la máquina se encienda nuevamente, ejecutamos el siguiente comando:

chkconfig --level 345 postfix on

DE LAS VERIFICACIONES

Lo primero que deberíamos verificar es lo siguiente:

• Socket TCP con Puerto 25 disponible en todas las interfaces. Para esto, ejecutamos:
  

netstat -an | grep 25

deberíamos ver una salida similar a la siguiente:

.
.
.
tcp        0      0 10.100.0.253:53             0.0.0.0:*                   LISTEN
tcp        0      0 0.0.0.0:25                  0.0.0.0:*                   LISTEN
.
.
 

De especial interés la línea:

tcp        0      0 0.0.0.0:25                  0.0.0.0:*                   LISTEN

Con esto verificamos que el servicio está a la escucha en todas las interfaces. Recuerden que 0.0.0.0 significa todas las interfaces y el 25 significa el número de puerto que está a la escucha. El puerto No. 25 corresponde al protocolo SMTP. Otras salidas interesantes del comando netstat, son las siguientes (compruébelo usted mismo):

netstat -anp
netstat -pls (jejeje...está me la pille en pello.info)
netstat -ano  (juas!!!..microsoft.com no deja de impresionarme)
  

• Hablando SMTP.
   También es interesante aprender hablar LDAP, BGP-4, HTTP, entre otras cosas. Una prueba que usualmente se hace es hablar SMTP directamente con nuestro servidor de correo para verificar que todo está funcionando como esperamos (es decir, por lo menos es capaz de recibir correo). Para hablar SMTP con nuestro servidor de correo solo basta con hacer una sesión telnet dirigida al puerto 25 de cualquier dirección IP de nuestro servidor de correo.
  En el ejemplo que voy a ilustrar a continuación, supongo lo siguiente:
  La IP interna de mi servidor de correo es: 192.168.1.1
  Dentro del servidor de correo existe un buzón de correo para juan@antel.com.uy
  Voy a enviarle un mensaje de prueba a juan@antel.com.uy, diciendo que yo soy mrwolf@pulpfiction.com.
  

Pongo a continuación mi diálogo SMTP con mi servidor de correo a través de una sesión Telnet al puerto 25 de mi servidor de correo. Usted puede probar de acuerdo con sus configuraciones lo mismo (lo que yo escribí está en negrita y de color verde, lo demás son respuestas del servidor a los diferentes comandos SMTP):

telnet 192.168.1.1 25

220 mail.antel.com.uy ESMTP Postfix
HELO juanmuno.antel.com.uy
250 mail.antel.com.uy
MAIL FROM: mrwolf@pulpfiction.com
250 Ok
RCPT TO: juan@antel.com.uy
250 Ok
DATA
354 Please start mail input.
HI, MY NAME IS MR WOLF. I SOLVE PROBLEMS...
.
250 Mail queued for delivery.

QUIT
221 Closing connection. Good bye.


Connection to host lost.
  

Con lo anterior, a juan@antel.com.uy, le debió llegar un mensaje de correo de mrwolf@pulpfiction.com diciendo:
HI, MY NAME IS MR WOLF. I SOLVE PROBLEMS
Para aquellos novicios y curiosos, el protocolo SMTP está especificadoen el RFC 821 (http://www.faqs.org/rfcs/rfc821.html).