viernes, 25 de diciembre de 2015

Moviendo el default progress indicator y hacerlo modal Vaadin

Algunas veces el progress indicador por defecto de vaadin no esta en la mejor posición y necesitamos centrarla y hacerla modal, para ello les comparto el siguiente código que es la solución para ese requerimiento :

.v-loading-indicator, .v-loading-indicator-delay, .v-loading-indicator-wait {
 position: absolute;
 z-index: 30000;
 width: 100% ;
 height: 100%;
 background: rgba(20,20,20, 0.6) url(../base/common/img/loading-indicator.gif) no-repeat 50% 50%;
}


lunes, 21 de diciembre de 2015

Implementación de red local con dos servidores web, un servidor DNS y dos clientes usando virtualbox

Configuración de la red:


La implementación de la red será entre máquinas virtuales usando VirtualBox, para lo cual elegiremos el modo red interna en la configuración de red de cada ordenador  virtual que se conectara a la red y le pondremos nombre “mired”. Como se puede ver en la siguiente imagen:


Nota: Es muy importante, que en todas las máquinas virtuales creadas, tengan el mismo nombre de red.

Usaremos la red 192.168.1.0 /24, las IP’s  de los ordenadores son los siguientes:
  •     Servidor web 1(finanzas): 192.168.1.5
  •         Servidor web2(tesorería):192.168.1.6
  •         Servidor DNS:192.168.1.8
  •         Cliente 1:192.168.1.13
  •     Cliente 2:192.168.1.14

Configuración del servidor web 1 (finanzas)

Para el servidor de finanzas usaremos Ubuntu 13.04 de 64 bits, xampp 5.6.12  (servidor web apache).


Luego de descargar xampp procedemos con la instalación, accedemos como súper usuario y le damos permiso de ejecución al instalador de xampp, finalmente ejecutamos el instalador.



Ahora asignaremos el número de IP, Mascara y Gateway al servidor:
Para lo cual modificaremos el archivo “etc/network/interfaces” usando cualquier editor de texto en este caso usaremos nano.



Luego de modificar el archivo presionamos ctrl + o para guardar los cambios y ctrl + x para salir del editor.
Ahora reiniciamos el servicio de red para que los cambios en la interfaz eth0 hagan efecto:


Ahora crearemos el archivo index.html para que sea el recurso por defecto del servidor de finanzas , este archivo se creara en el directorio raíz del servidor “op/lampp/htdocs/index.html” , para lo cual usaremos nano.



Finalmente iniciamos el servidor:


Ahora ya tenemos el servidor web de finanzas  listo para atender peticiones http.

Configuración del servidor web 2(tesorería)

Para la configuración de este servidor usaremos el mismo software que el que usamos en la configuración del servidor 1(finanzas) y realizaremos pasos parecidos.


Ahora asignaremos el número de IP, Mascara y Gateway al servidor:



Ahora reiniciamos el servicio de red


Ahora crearemos el archivo index.html para que sea el recurso por defecto del servidor de tesorería



Finalmente iniciamos el servidor:


Ahora ya tenemos el servidor web de tesorería listo para atender peticiones http.

Configurando el cliente 1

Para el cliente 1 usaremos Ubuntu 13.04 de 64 bits
En los clientes solo debemos asignar número de IP, Mascara, Gateway.




Reiniciamos el servicio de red:


Configurando el cliente 2

Para el cliente 2 usaremos Ubuntu 13.04 de 64 bits.



Reiniciamos el servicio de red


Ahora que ya tenemos configurados los servidores y los clientes, vamos a probar que todo funcione bien.


Configurando el servidor DNS

Antes de empezar con la configuración del servidor DNS veremos algunos conceptos que no serán útiles para la comprensión de los pasos siguientes:

Servidores DNS
Dentro de este apartado, contamos con dos tipos de servidores:
  • Servidor Maestro/Primario - Consulta los datos del dominio en la base de datos del propio servidor donde se aloja.
  • Servidor Esclavo/Secundario - Consulta los datos de una caché que rellena a partir de los datos de un servidor Primario. Dicho proceso se denomina Trasferencia de zona.
un servidor DNS puede hacer dos tipos de consultas:
  • Consultas Iterativas - El servidor DNS responde a la consulta del cliente desde los datos guardados en su base de datos o en las bases de los sistemas locales. Si dicha información no se encuentra disponible, la petición se reenviará hacia otros servidores, hasta encontrar la Zona de Autoridad válida que resuelva la petición. En principio, la carga de la consulta recae sobre el cliente.
  • Consultas Recursivas - El servidor DNS proporciona, si existe, la respuesta a la solicitud. Para ello, hará tantas consultas iterativas como sea necesario hasta dar con el dato solicitado. Las peticiones son transparentes a la máquina del cliente.
Zonas de Autoridad
Un servidor DNS Primario carga su información desde una Zona de Autoridad. Dicha zona abarca un nombre de dominio y, si los nombres de los subdominios no están delegados, también los incluirá. Toda la información se almacenará localmente en un fichero que contendrá alguno de estos tipos de registros:

A (Address) - Registro de dirección que resuelve un nombre de un anfitrión hacia una dirección IPv4 de 32 bits.
AAAA - Registro de dirección que resuelve un nombre de un anfitrión hacia una dirección IPv6 de 128 bits.
CNAME (Canonical Name) - Registro de nombre canónico que hace que un nombre sea alias de otro. Los dominios con alias obtiene los sub-dominios y registros DNS del dominio original.
MX (Mail Exchanger) - Registro de servidor de correo que sirve para definir una lista de servidores de correo para un dominio, así como la prioridad entre éstos.
PTR (Pointer) - Registro de apuntador que resuelve direcciones IPv4 hacia el nombre anfitriones. Es decir, hace lo contrario al registro A. Se utiliza en zonas de Resolución Inversa.
NS (Name Server) - Registro de servidor de nombres que sirve para definir una lista de servidores de nombres con autoridad para un dominio.
SOA (Start of Authority) - Registro de inicio de autoridad que especifica el Servidor DNS Maestro (o Primario) que proporcionará la información con autoridad acerca de un dominio de Internet, dirección de correo electrónico del administrador, número de serie del dominio y parámetros de tiempo para la zona.
SRV (Service) - Registro de servicios que especifica información acerca de servicios disponibles a través del dominio. Protocolos como SIP (Session Initiation Protocol) y XMPP (Extensible Messaging and Presence Protocol) suelen requerir registros SRV en la zona para proporcionar información a los clientes.
TXT (Text) - Registro de texto que permite al administrador insertar texto arbitrariamente en un registro DNS. Este tipo de registro es muy utilizado por los servidores de listas negras DNSBL (DNS-based Blackhole List) para la filtración de Spam. Otro ejemplo de uso son las VPN, donde suele requerirse un registro TXT para definir una llave que será utilizada por los clientes.

Las zonas a resolver serán las siguientes:
  • Zonas de Reenvío - Devuelven direcciones IP para búsquedas sobre nombres FQDN (Fully Qualified Domain Name). Es importante apuntar aquí que, en el caso de tratarse de dominios públicos, hay una responsabilidad por parte de la autoridad misma del dominio (el Registrar del WHOIS) para crear dicha zona de reenvío.
  • Zonas de Resolución Inversa - Devuelven nombres FQDN para búsquedas sobre direcciones IP. Como en el caso anterior, la responsabilidad de crear la Zona de Autoridad recae sobre la autoridad misma del segmento (si hacemos un WHOIS sobre una dirección IP, obtendremos a la autoridad de todo el segmento de direcciones).
Para el servidor de DNS usaremos Ubuntu server 14.04.3 de 64 bits y Bind 9.10.
Lo primero será asignar número de IP, Mascara y Gateway al servidor DNS:


Luego se instala bind, en este caso usaremos el comando “apt-get install bind9”:



Ahora procedemos con la configuración, sólo se podrá utilizar el servidor DNS en la red local, por ello en el fichero de configuración definiremos una lista de control de acceso (ACL) que estará compuesta por nuestra red local y el propio ordenador que hace de servidor.

Para poder resolver los nombres de los servidores de nuestra red local, deberemos crear 3 zonas: 2 para la resolución directa y otra para la resolución inversa. Nuestros servidores tendrán como nombre XXXXX.finanzas.com, y XXXXX.tesoreria.com por lo que la zonas se llamarán "finanzas.com" y “tesorería.com”. Y ya que se encuentran situados en el rango de IPs 192.168.1.x, la zona inversa deberá tener el nombre "1.168.192.in-addr.arpa". Añadiremos al fichero de configuración estas 3 zonas de la siguiente forma:
 “/etc/bind/named.conf.local”


En la sección de opciones (options) diremos que sólo permitiremos hacer consultas, transferencias y escuchar en la ACL definida anteriormente:
“/etc/bind/named.conf.options”


Creamos los archivos de configuración de zona,  usando el comando “pico db.finanzas.com”, “db.tesoreria.com” y el archivo de resolución inversa para la red 192.168.1.0 “rev.192.168.1”


Configuramos la resolución directa para el dominio www.finanzas.com(db.finanzas.com)

Configuramos la resolución directa para el dominio www.tesoreria.com(db.tesoreria.com)

Configurando la resolución inversa para la red 192.168.1.0


Los registros del fichero son los siguientes:
  • IN SOA - Información sobre el dominio:
sever.mydomain.name.: Servidor de nombres al cual pertenece la zona.
user.server.mydomain.name.: Indica el usuario responsable a administrar el servidor DNS. Además también hace referencia a su dirección de correo 
user@mydomain.name user@mydomain.name .
Nº Serie: Es el número de serie correspondiente a la última actualización. Este campo es utilizado por los servidores DNS secundarios, los cuales solamente actualizarán los datos de su zona si su número de serie es menor que el del primario.
Refresco: Tiempo en que el servidor secundario debe preguntar al primario si ha habido cambios.
Reintentos: Periodo de tiempo que ha de esperar un servidor secundario antes de reintentar la conexión con el servidor primario, suponiendo que el último intento haya fallado.
Expiración: Máximo tiempo que ofrece servicio el servidor secundario, en caso de no poder contactar con el primario.
TTL: Tiempo máximo que se mantienen los datos del dominio en un servidor de caché antes de volver ha hacer una consulta al servidor autorizado.
  • IN NS - Relaciona un nombre de subdominio con un servidor de nombres responsable de la zona. Podremos formar así una jerarquía de nombres DNS. Hay que poner el correspondiente registro A para traducir el nombre del servidor a una dirección IP si se usa este registro.
  • IN A - Traducción de máquina a dirección IP.
  • IN PTR - Traducción de dirección IP a máquina.       
Reiniciamos el servicio de DNS.


Ahora les asignamos el DNS  a nuestros clientes:
“/etc/resolv.conf”

Cliente 1


Cliente 2


Comprobamos que nuestro servidor DNS funcione correctamente para eso usamos el comando host

Cliente 1


Cliente 2


Como podemos observar en ambos clientes el DNS resuelve correctamente directa e inversamente, es decir si le pasamos el nombre del dominio nos devuelve la IP y si le pasamos la IP nos devuelve el nombre del dominio.

Ahora comprobamos que nuestros servidores web respondan correctamente haciendo uso de los dominios asignados.



lunes, 14 de diciembre de 2015

Agenda Personal Básica con Spring, hibernate y jsp

En esta oportunidad les comparto una aplicación para gestionar nuestros contactos utilizando para ello Maven, Spring MVC e Hibernate.

Hibernate es una herramienta de Mapeo objeto-relacional (ORM) para la plataforma Java que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación, mediante archivos declarativos (XML) o anotaciones en los beans de las entidades que permiten establecer estas relaciones.

Es decir, vamos a utilizar una clase java a la que llamaremos entidad que va a servir para interactuar con la base de datos, por lo que la aplicación quedará así:


Arquitectura de la aplicación
Para nuestra aplicación web vamos a tener una arquitectura por capas. Accederemos  a la base de datos a través de una capa (DAO), esta es la capa que utiliza Hibernate. Llamaremos a la capa DAO mediante una capa de servicios. Por ello vamos a tener una interfaz llamada ContactService.


La base de datos

Para este ejemplo vamos a utilizar Postgresql como Base de datos.

Lo primero de todo será crear una base de datos llamada “mydatabase” y en una primera aproximación vamos  crear una tabla llamada “CONTACTS” donde  guardaremos los contactos de nuestra agenda. Los datos que vamos a guardar como mínimo son: un id (clave primaria), firstname, lastname, telephone, mail y created:

CREATE TABLE CONTACTS
(   id           SERIAL PRIMARY KEY,
    firstname    VARCHAR(30),
    lastname    VARCHAR(30),
    telephone   VARCHAR(15),
    email        VARCHAR(30),
    created     TIMESTAMP DEFAULT NOW()
);