La paradoja del software "libre"

Este artículo se sale un poco de la temática de este blog puesto que no es técnico sino más bien una reflexión propia que me hago.

Antes de nada, me gustaría aclarar que en este artículo me refiero a una parte del movimiento software libre y no a todo. Hay muchas personas que ponen su esfuerzo y trabajo a nuestro alcance de una forma altruista y desinteresada intentando que el resultado sea útil a toda la sociedad, independientemente de su nivel de conocimiento tecnológico y de su nivel salarial. A todas esas personas, gracias.

Sin embargo, hay dos actitudes dentro del software libre que desvirtúan ese movimiento: aquellos que intentan que se convierta en propiedad o que esté bajo el mandato de una élite exclusiva de personas que discriminan cualquier iniciativa que no cumpla con sus reglas y aquellos que se aprovechan del movimiento para obtener beneficios económicos (no tengo nada en contra de aquellos que sin tapujos y con fines económicos distribuyen versiones de demo, prueba o sucedáneos). Sobre ellos va este artículo

Empecemos

Desde hace tiempo, vengo dándole vueltas a la expresión “software libre”, término asociado a múltiples programas, aplicaciones, sistemas operativos y demás que se distribuyen de manera libre y que son estandarte de un movimiento social a nivel tecnológico. Ejemplos de software libre serían, por ejemplo, Ubuntu como sistema operativo, Apache como servidor web, JBoss como servidor de aplicaciones, Java como lenguaje de programación (igual que .net de Microsoft), OpenOffice como entorno ofimático y múltiples aplicaciones más desarrolladas en Java o cualquier otra cosa que no sea Microsoft y sobre Linux (los que desarrollan en Java sobre Windows son menos “libres”).

Sin embargo, después de probar Ubuntu y Kubuntu (de Fedora no comento), haber montado un par de servidores Apache, unos cuantos JBoss, viendo como un compañero sudaba tinta china para montar un servidor Nagios, me di cuenta que el software libre es libre sólo para unos cuantos, para aquellos que saben de informática y que tienen tiempo de enfrascarse en foros, chats, blogs y demás utilidades de Internet. El software libre no está orientado para el usuario real de a pie para el que el ordenador no es un fin sino una herramienta. Pero, vayamos paso a paso y explicando:

Ubuntu (por poner un ejemplo)

Una persona normal con los conocimientos básicos de informática, es decir, encender, apagar el ordenador, ver el correo y navegar por Internet, decide cambiarse a Ubuntu porque le han comentado que está muy bien y que es gratuito. Esta persona se descarga la distribución del sitio web de Ubuntu, la monta en un CD y lo arranca. Hasta aquí todo muy bien, la instalación es muy fácil con unas instrucciones muy bien puestas. Una vez finalizada la instalación, arranca el ordenador y lo primero que se encuentra (si sabe…) es que tiene que actualizar los repositorios y modificarlos para acceder a los que de verdad tienen las aplicaciones. Empieza a entrar en foros (si sabe…) y empieza a leer que tiene que entrar en no se qué directorio, utilizar algo llamado vi y teclear una serie de instrucciones en la pantalla desde algo que se llama “shell” (qué será eso). A medio camino se le queda colgado el OpenOffice (muy común) y el ordenador se queda tostado (no sé como no sabría entrar en el “shell” y hacer un “kill” del proceso del OpenOffice, hay que ver). Finalmente, nuestro usuario desesperado desinstala el Ubuntu y sigue con su Windows que por lo menos todo viene mascado y sale en ventanas.

El Círculo Interno de los Ficheros

Tengo la certeza de que para que un software sea “libre” debe de tener un montón de ficheros de configuración, de definición, de variables, en el path de un sitio, en el path de otro, y por supuesto, ninguna ventana de administración (y ninguna ayuda). Yo creo que es porque en inglés ventana se dice Windows y a los del software libre les da yuyu. Por otro lado, el mantener los ficheros y no hacer aplicaciones orientadas al usuario final es porque debe existir un Consejo de malvados o Circulo Interno de los Ficheros que otorgan el título de software libre (o software que mola) que realmente no quieren que el usuario normal (es decir, el usuario no gurú ni friky de la informática ni programador de algo) tenga el conocimiento total, siempre se guardan esa sabiduría de cómo configurar una aplicación (porque es software libre).

La hipocresía del software social

Como todo en esta vida, el software libre no deja de ser una tapadera de una serie de personas que tienen fines lucrativos. Esta serie de malvados no quieren que los mortales sepan utilizar al 100% sus herramientas porque ofrecen sus servicios (cobrando por supuesto) para enseñar a utilizarlas. Para conseguir esto se hace lo siguiente:

1. Hágase una herramienta en Java. Por qué en Java? Porque funciona en Linux y en Windows (agggg he dicho la palabra prohibida) No mola lo mismo que sólo funcione en Linux que lo utilizan muy pocos y no tienen dinero, tiene que funcionar también en Windows (agggg, otra vez…)
2. La herramienta debe de tener un montón de ficheros de configuración que solamente tú sabes manejar. Por supuesto el código no debe estar comentado para que nadie te pille por donde va el tema.
3. Habla con un par de gurús de los foros para que digan que tu aplicación mola y que es muy libre y que tú vas contra sistema.
4. Deja unos meses que la gente utilice tu herramienta gratis dándoles asesoramiento y respondiendo a sus dudas.
5. Al pasar los meses, saca una versión Lite (que no vale un pimiento), saca una versión Professional (por la que cobras un dinerillo para sustentar la causa, siempre gusta) y empieza a cobrar por servicios y a cobrar por las respuestas.
6. Ya tienes montado tu negocio de software libre.

Fin del Discurso

El software libre es libre hasta que se mete el dinero por medio y pienso que el dinero lleva metido mucho tiempo provocando que los intereses de unos pocos manejen a muchos. Pero en fin, viva Microsoft y abajo el monopolio…. digo…viva Linux y arriba el monopolio…. en fin, ya no se lo que me digo.

Servicios de directorio. El caso de NIS

• Propósito general e introducción a los Sistemas de Directorio
  

El propósito general de los servicios de directorio es la compartición de información, muy necesaria en las redes de ordenadores.
Un ejemplo de un servicio sería el de la correspondencia nombre de máquina-dirección IP, que presta el servicio de DNS, y que se crea precisamente con el objetivo de resolver un problema de compartición de información muy grande que se planteó en la por aquel entonces incipiente Internet. El problema derivaba del sistema anterior empleado para asignar biunívocamente nombre de máquina y dirección IP, que consistía en un fichero "hosts.txt" (de ahí las raíces del fichero local de sistemas Linux /etc/hosts) que se ofrecía a través de la red al resto de equipos. Las máquinas conectadas a Internet se sincronizaban cada cierto periodo de tiempo con un servidor que servía este fichero "hosts.txt" con la nueva asignación de nombres-IPs. Como se puede imaginar, este sistema funcionaba a la perfección con una Internet poco poblada, pero era inviable para el futuro, sobre todo teniendo en cuenta el increíble aumento de hosts en internet (boom de las punto com...). La solución fue idear una base de datos jerarquizada y distribuída, creando dominios que contuvieran la información de las máquinas en su interior, y que supieran alcanzar a otras máquinas en caso de que la asignación máquina-IP solicitada no estuviese en sus manos.
El otro ejemplo, del que nos ocupamos un poco más aquí es el de NIS. Desarrollado por Sun Microsystems en los 80, se ideó con el fin de solucionar la gestión de nombres, usuarios y grupos en redes con gran número de nodos. La idea era crear un sistema cliente-servidor que permitiese almacenar determinada información de configuración en un servidor y que los clientes se pudiesen conectar a él para averiguarla. De esta manera se evitaba tener que hacer tantas actualizaciones como máquinas hubiese en una red después de cada cambio.
En sus primeras versiones se llamaba "Yellow Pages" (Páginas Amarillas), pero esto llevó a toda una serie de demandas por parte de British Telecom que tenía la propiedad de dicha marca, con lo cual después de algunos trajines entre tribunales, acabó por llamarse NIS (Network Information Service). Los restos de su antiguo nombre todavía pueden intuirse en el nombre de los diferentes demonios y scripts que NIS utiliza (ej: ypbind, ypserv...).
Con la evolución de las necesidades de este tipo de servicios, los nuevos requerimientos condujeron a la aparición de un NIS mejorado (NIS+) que permite la administración jerárquica (al estilo de DNS), soporte para un nivel de seguridad mayor (tipos de acceso diferentes en función de la confidencialidad de los datos), sistema de verificación del servidor para los clientes, mejora del proceso de actualización de datos...

• El Directorio Standard X.500

A la par que DNS y NIS se estaban definiendo se hizo un esfuerzo especial para estandarizar la estructura de directorios de información, resultando en X.500. Un ejemplo de cómo almacenaría X.500 un dominio n-idea.alcala.com sería
{ Country = ES, Organization = N-Idea. Nuevas Ideas, Organization Unit = Empresa, Location = Alcala la Real }.
El etiquetado de los diferentes niveles de jerarquía aporta la posibilidad de realizar búsquedas inteligentes de información en el servidor.

• El Protocolo LDAP

LDAP surge como solución a la adaptación de DAP a las redes TCP/IP.
Cuando se definió el estándar de X.500 se creó un protocolo, que se llamó DAP para permitir el acceso a la base de datos a los clientes, pero este protocolo se ideó asumiendo que acabaría reinando la distribución OSI de los niveles de transporte y red y que TCP/IP acabaría desapareciendo. La realidad demostró todo lo contrario, por lo que se hizo imprescindible la adaptación de DAP a los niveles TCP/IP.

• ¿Y cómo funciona NIS?

NIS basa su actividad en una estructura cliente-servidor. El servidor (que puede ser maestro o esclavo) contiene unos ficheros de datos (llamados mapas) que el cliente va a buscar. La versión última de la base de datos la posee el servidor maestro y la distribuye a los servidores esclavos de forma perfectamente configurable, tanto al iniciar como al producirse un cambio. Los servidores esclavos sirven información pero no permiten la modificación de ésta.

Un nodo NIS puede ser:
- Cliente: Para minimizar el trabajo de configuración y facilitar la administración del sistema, se procurará maximizar la información distribuída por NIS.
- Servidor: Tiene los mapas, responde a peticiones de clientes, pero su propia configuración local no la obtiene por NIS (Sólo es útil cuando el equipo es servidor únicamente de NIS).
- Cliente y Servidor: La misma máquina, además de responder a las peticiones de los clientes y funcionar como servidor, es cliente de sí mismo, de forma que el tiempo de configuración del servidor también se minimiza.

Como antes dijimos, NIS copió de DNS lo referente a la distribución en dominios, por lo que NIS define también dominios de NIS que permiten que no exista una única información a distribuir a todas las estaciones, sino que se puedan definir zonas para distribuir cada información. Así, un dominio se convierte en un conjunto de mapas de NIS, lo que obliga a un cliente a especificar tanto el dominio como mapa requeridos.

• Vale y eso...¿cómo **** se hace?

Aquí viene la parte divertida. Para instalar un servicio de NIS tendremos que hacer los siguiente:
- Del lado del servidor:

1. Instalar la aplicación NIS tanto maestro como esclavo en los servidores.
2. Crear la base de datos con los ficheros a distribuir.
3. Arrancar el demonio "ypserv" que procesará las peticiones de los clientes.
4. Añadir (si procede) los servidores esclavos.

- Del lado del cliente:

1. Instalar la aplicación cliente de NIS.
2. Modificar los ficheros de configuración para que las peticiones de información se hagan a través de NIS.
3. Arrancar el demonio "ypbind" que realizará las peticiones a los servidores.
   

---

Vamos a ponernos a la tarea del lado servidor.
Lo primero es elegir el servidor maestro. Lo que tenemos que tener en cuenta es que ha de ser un equipo con gran estabilidad, capacidad de cálculo y ancho de banda. Dado que distribuye información de configuración vital para los equipos, una parada larga del servidor maestro supondría la parada de toda la red...cosa que no es muy deseable, sobre todo si algún puesto de trabajo depende de ello :). Además, el servidor debe soportar accesos concurrentes a la base de datos.

Instalación del maestro

Primero nos aseguramos de estar corriendo el portmap de RPC (Remote Procedure Call), ya que NIS es un protocolo montado sobre RPC. Normalmente en /etc/init.d/portmap, que podremos hacer que se arranque automáticamente con el inicio del sistema estableciendo un link simbólico en el runlevel 3 de nuestro sistema. (cd /etc/rc3.d en Ubuntu o cd /etc/rc.d/rc3.d en Redhat y luego ln -s ../init.d/portmap S60portmap). Si la posición 60 estuviese ocupada se pueden utilizar las siguientes.
Definimos el dominio de NIS a utilizar mediante el comando domainname (man domainname para más ayuda), que se suele incluir entre los scripts de arranque (/etc/init.d en sistemas Debian). Si existen múltples dominios, se repite la operación para cada dominio.
A continuación instalamos el servidor con el comando ypinit -m (normalmente /usr/lib/yp/ypinit -m). ypinit funciona mediante la invocación a la aplicación make, y en el fichero /var/yp/Makefile se pueden definir y modificar las variables que parametrizan el funcionamiento del servidor maestro.
Una vez parametrizado nuestro servidor maestro, al hacer ypinit -m se nos preguntará por los servidores esclavos. No es necesario que estén configurados mientras instalamos el maestro así que se introducen sin miedo (serán almacenados en el fichero /var/yp/ypservers).
Una vez tenemos el servidor instalado como maestro tenemos que decirle que también sea cliente de sí mismo. Para ello, empezaremos modificando el fichero /etc/nsswitch.conf cambiando el orden en que se consultarán las fuentes dependiendo de qué ficheros queramos que se obtengan por NIS. Un ejemplo podría quedar más o menos así:

"...
passwd: files nis
group: files nis
shadow: files nis
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
.."

A continuación incluiremos en el fichero /etc/hosts las direcciones IP de todos los servidores esclavos para un funcionamiento robusto.
Bien, llegó el momento de arrancar nuestro servidor maestro.
Como queremos que el servidor se arranque siempre con la máquina sin necesidad de hacerlo manualmente, lo incluiremos en el runlevel 3 de la máquina (nótese que ypserv e yppasswdd ya se hallan en /etc/init.d). Lo único que tenemos que hacer es situarnos en la carpeta correspondiente al runlevel 3 (cd /etc/rc3.d en el caso de Ubuntu o cd /etc/rc.d/rc3.d en el caso de Redhat) y desde ahí establecer un link simbólico a los demonios ypserv e yppasswdd (ln -s ../init.d/ypserv S61ypserv y ln -s ../init.d/yppasswdd S62yppasswdd). Nótese que he usado los números 61 y 62, pero que en caso de estar ocupados por las llamadas a otros scripts pueden utilizarse los números siguientes.
La forma manual de arrancar estos demonios sería /etc/init.d/ypserv start y /etc/init.d/yppasswdd start.
Los demonios ypserv e yppasswdd se encargan respectivamente de atender las peticiones NIS de los clientes y de permitir el cambio de contraseña de los clientes NIS.

Instalación de los esclavos

Si el sistema lo requiere, y el número de clientes crece suficientemente o bien queremos repartir carga y evitar que cuando se caiga el maestro nuestra red esté "en bragas", instalaremos también al menos un servidor esclavo. Para hacerlo procederemos de forma similar a la seguida con el maestro.
Primero usamos el comando domainname para definir el dominio.
Hemos de tener claro que el servidor esclavo sólo procesa la información que le llega del maestro y en ningún caso incorpora su información local a los mapas que distribuye.
Lo siguiente a realizar es configurarlo como cliente de NIS (ver más adelante Instalación de los clientes).
A continuación instalamos el servidor como esclavo con el comando ypinit -s maestro siendo maestro el nombre del servidor maestro (normalmente la ruta será /usr/lib/yp/ypinit -s maestro).

Si llegado a este punto obtenemos un error tipo "Trying ypxfrd ... not running", es que no hemos arrancado en el maestro el demonio de transferencia de mapas de NIS (rpc.ypxfrd). Lo hacemos y punto. Es tan fácil como ir al Makefile del maestro, descomentar o poner directamente la siguiente línea NOPUSH="false" y luego ejecutar en el maestro cd /var/yp; make all (que reconstruirá los mapas de NIS)

Ahora, si queremos rizar el rizo sería una buena idea automatizar la tarea de solicitar al maestro que nos actualice los mapas de NIS mediante cron.
Hacemos que cron abra nuestro editor preferido con crontab -e en el servidor esclavo e introducimos las siguientes líneas:

30 *      * * *  /usr/lib/yp/ypxfr_1perhour
0 5      * * *  /usr/lib/yp/ypxfr_1perday
0 6,18   * * *  /usr/lib/yp/ypxfr_2perday

La configuración de este fichero de cron es bastante intuitiva (man crontab). Los dígitos significan por orden de izquierda a derecha: minutos, horas, día(s) del mes, mes(es), día(s) de la semana, orden a ejecutar.
De esta manera estaremos siempre seguros de que nuestros servidores esclavos están al día incluso si un esclavo estuviese caído durante el tiempo en que el maestro servía los mapas.

Instalación de los clientes

La instalación de un cliente de NIS es más fácil que la del servidor.
Primero nos aseguramos de que estamos corriendo el portmap de RPC y que tenemos instalados los paquetes de ypbind e yp-tools de nuestra distribución.
Ahora usaremos el comando domainname para definir el dominio de NIS que está sirviendo el servidor de NIS que hemos configurado previamente.
Acto seguido crearemos el fichero /var/yp en caso de que no exista.
Lo siguiente que tendremos que hacer es modificar el fichero /etc/nsswitch.conf para indicar el orden de las fuentes de las que se extraerán los distintos ficheros de configuración, para luego modificar el fichero /etc/yp.conf indicando los servidores del dominio NIS que se usarán.
Vamos a ver un ejemplo de cómo podría quedar el fichero /etc/yp.conf

# /etc/yp.conf - fichero de configuración de ypbind
#
domain nidea server maquinadelmanolo.n-idea.es
# Usa el servidor maquinadelmanolo.n-idea.es para el dominio nidea
#
domain nideacurreles broadcast
# Hace broadcast en la red local para el dominio nideacurreles
#

Finalmente, sólo nos quedará arrancar el demonio ypbind que realizará las funciones del cliente. Como ya hicimos con el portmap y con las funciones de los servidores, introduciremos la llamada a ypbind en el arranque del sistema (si lo que queremos por el momento es sólo probar, la orden para arrancarlo sería /etc/init.d/ypbind start en sistemas Debian o /etc/rc.d/init.d/ypbind start en sistemas Redhat). Para incluir el demonio en el arranque procedemos como siempre:
- cd /etc/rc3.d (Debian) o cd /etc/rc.d/rc3.d (Redhat).
- ln -s ../init.d/ypbind S61ypbind.

¡Y yastá coleguitas! Vamos a usar las yp-tools del cliente para comprobar que todo está way vaya a ser...que luego tó se sabe.

ypcat passwd (sería el equivalente a cat passwd solo que ypcat busca la información servida por NIS y no la local).

Si el resultado es el fichero passwd que sirve el servidor de NIS (siempre que en nsswitch.conf hayáis definido que el fichero passwd se obtiene por NIS con mayor prioridad que de ficheros locales), entonces ya podéis decir por ahí que sois los mejores administrando con 4 toqueteos de teclado la configuración de cuentas de usuarios, host, rutas, y todos estos tinglaos de toda la red de forma centralizada con un servicio de directorio montado sobre RPC. ¡Ale! ¡a chulear pues!

---

• Notas finales

A modo de pequeña reseña voy a enumerar los demonios y aplicaciones principales de NIS, así como algunas de las fundamentales yp-tools:

Demonios:
- ypbind -> demonio del cliente que atiende al servidor.
- ypserv -> demonio del servidor que atiende al cliente.
- yppasswd -> demonio del servidor que permite el cambio de contraseña del cliente.
- ypxfrd -> demonio del servidor maestro que sirve los mapas de NIS a los servidores esclavos.

Aplicaciones:
- ypxfr -> aplicación que ejecuta el servidor esclavo y que contacta con el servidor maestro para bajarse los mapas de NIS.
- yppush -> aplicación del servidor maestro que notifica a los servidores esclavos para que se descarguen los mapas.
- yptools -> herramientas de comunicación NIS de cliente.

yptools:
- ypdomainame -> selecciona el nombre de dominio compartido entre todos.
- yppaswd -> cambia la clave de un usuario (requiere de ypbind y portmapper).
- ypwhich -> muestra el servidor NIS al que está conectado el ypbind.
- ypset -> cambia el servidor NIS al que está conectado ypbind.
- yppoll -> devuelve la versión y servidor maestro de un mapa de NIS.
- yptest -> llama a varias funciones de NIS para comprobar si que configuración es correcta y el sistema funciona como se espera.

SMIL: HTML + TIME

En este artículo vamos a comentar brevemente la posibilidad de extender el HTML con líneas temporales, de forma que podamos definir acciones y movimientos dentro de una escala temporal. Esta técnica de programación permite una experiencia mucho más rica de nuestras aplicaciones o páginas web.

SMIL (Synchronized Multimedia Integration Language) es un lenguaje similar al HTML para implementar presentaciones audiovisuales. Empezó en 1997, estando actualmente en la versión 2.1 de su desarrollo. Es una recomendación del comité W3C aunque, inexplicablemente, no ha sido acogida por Firefox y si por Internet Explorer desde la versión 5.5.

¿Qué se puede hacer con SMIL?
Según W3C, las posibilidades de SMIL abarcan los siguientes items:

• Creación de presentaciones para internet e intranets.
• Creación de presentaciones tipo "slideshow"
• Se ha descrito SMIL como la respuesta a PowerPoint en internet
• Las presentaciones SMIL pueden mostrar múltiples tipos de ficheros (texto, video, audio,...)
• Las presentaciones pueden mostrar múltiples ficheros al mismo tiempo.
• Las presentaciones pueden mostrar ficheros de múltiples servidores web.
• Las presentaciones pueden contener enlaces a otras presentaciones
• Las presentaciones pueden tener botones de control (iniciar, parar, siguiente,...)
• Se pueden definir secuencias y duración de acciones en el tiempo
• Se puede definir la posición y visibilidad de los elementos

Realmente se pueden definir múltiples acciones de una manera fácil y sencilla mediante SMIL. El siguiente es un código de ejemplo de una acción sencilla realizada en SMIL:

Como se puede observar, el código está realizado en XML y es fácilmente entendible:

• Todo el código se mete dentro de la etiqueta "smil"
• Se le añade un "body" a la acción (como si fuera HTML)
• La etiqueta define una secuencia que se repetirá indefinidamente "seq" (repeatCount="indefinite")
• La secuencia se compone de dos imágenes que irán apareciendo, primero image1.jpg durante 3 segundos y después image2.jpg durante otros 3 segundos.

¿Cómo reproducir código SMIL?
El código SMIL se reproduce o ejecuta en visualizadores SMIL preparados para ello. Existen múltiples de ellos en internet, siendo los más destacados:

• Ambulant Player: reproductor open-source que soporta la versión 2.1
• RealOne: de RealNetworks
• Grins: de Oratrix
• Internet Explorer

Sin embargo, una de las posibilidades que más potencia nos da SMIL es la capacidad de integrarse con el HTML permitiendo definir líneas de tiempo para los elementos de las páginas.

HTML + TIME
Esta opción sólo está disponible para Internet Explorer puesto que es el único que sigue la recomendación del W3C. Al integrar el código SMIL junto con el HTML, podemos ampliar las propiedades de los elementos HTML con el tiempo. Al incluirles el factor del tiempo podemos realizar cambios en su visibilidad, movimiento, apariencia, comportamiento dependiendo del momento en el que nos encontremos.

Para habilitar esta función deberemos declarar lo siguiente:








Una vez importado el espacio de nombres, podremos incluirle la opción del tiempo a cualquier elemento que queramos en nuestra página. El siguiente código realiza una acción básica integrándose con HTML:








En este caso, definimos una secuencia temporal que se repetirá indefinidamente apareciendo una imagen y después otra. Es el mismo ejemplo que pusimos antes pero con HTML.

También podemos actuar sobre el inicio y el fin de las secuencias mediante la acción del usuario. En el siguiente ejemplo, la acción empezará 2 segundos después de que el usuario pulse sobre el botón "boton1" y terminará cuando el usuario pulse sobre el botón "boton2":

















En este código también se introduce la posibilidad de realizar acciones en paralelo. Ejecutamos la reproducción de un sonido en paralelo con la secuencia de dos imágenes.

Transiciones:
SMIL2.0 introduce la posibilidad de realizar transiciones entre elementos o en un elemento. De esta manera se introduce una mayor riqueza visual. Para incluir transiciones sólo tendremos que definirlas de esta manera:













Las transiciones posibles son:

• Fade
• barnDoorWipe
• barWipe
• clockWipe
• ellipseWipe
• fanWipe
• irisWipe
• pushWipe
• slideWipe
• snakeWipe
• starWipe

Elementos Audiovisuales:
Los tags que definen elementos audiovisuales que se pueden manejar mediante SMIL en HTML son:

• "animation"
• "audio"
• "brush"
• "img"
• "param"
• "ref"
• "text"
• "textstream"
• "video"

Conclusión:
SMIL nos ofrece una posibilidad muy buena de incluir animaciones y efectos en nuestras páginas web interactuando con los componentes HTML de una manera estándar.No necesitamos instalarnos ningún plugin ni herramienta de terceros y permite una interacción mayor con el usuario.

SmoothWall Express: Open Source Firewall

En este artículo vamos a ver cómo configurar el firewall SmoothWall Express 2.0 en nuestra oficina o casa. Al final del artículo obtendremos un entorno seguro con las siguientes ventajas:

• DMZ con nuestro servidor web publicado
• LAN segura con nuestro servidor de base de datos y los equipos clientes
• Web Proxy con control de quién sale a internet y quién no

Para realizar esta configuración nos vamos a basar en herramientas Open Source disponibles para todo el mundo y de manera gratuita. Éstas son:

• SmoothWall Express 2.0: será nuestro firewall.
• advproxy: extensión de SmoothWall que nos dará las funcionalidades avanzadas de Proxy.
  
• FileZilla: herramienta de transmisión de ficheros
• Putty: consola para acceder a servidores

Escenario de partida:
Nuestro escenario de partida es el siguiente:





















Tenemos nuestro router que nos da acceso a internet y nuestros clientes que acceden a los servidores de la LAN y a internet. No tenemos ningún control sobre quién accede a internet, anchos de banda utilizados, políticas de acceso y tampoco podemos publicar nuestro servidor web a internet por no tener una infraestructura de seguridad. Nuestro objetivo, por lo tanto, será montar dicha infraestructura de seguridad que nos de control sobre nuestra red y el tráfico que por ella se mueve.

Escenario Objetivo:
Nuestro objetivo será llegar a un escenario como este:























Tenemos tres zonas bien diferenciadas:

• DMZ: Zona DesMilitarizada, donde colocaremos el servidor o servidores que queramos publicar a internet. Todo el tráfico entrante desde internet (salvo que se definan reglas) se derivará hacia esta zona).
• LAN Segura: en esta zona estarán nuestros clientes y servidores seguros. Ningún tráfico de internet se dejará pasar a esta zona (salvo que se definan reglas). Sólamente el tráfico definido podrá pasar desde la DMZ hasta esta zona (típicamente para acceder al servidor de base de datos).
• Zona Insegura: esta es la zona por la que llegan las peticiones de internet y se realizan los bloqueos necesarios.

Como se observa, en el firewall se encuentra también el Advanced Web Proxy, el cual nos permitirá controlar el acceso a internet por parte de los clientes.

Configuración de SmoothWall Express 2.0:

Nos descargamos la versión desde su sitio y la guardamos en un CD. SmoothWall es un firewall montado sobre un linux precompilado. Es necesaria una máquina completa para él puesto que elimina todo el contenido existente en los discos duros. No se necesitan conocimientos previos de Linux, aunque si tener claro lo que se quiere conseguir. Lo primero que necesitaremos serán 3 tarjetas de red que pincharemos en nuestro equipo. Los requisitos del equipo son muy bajos: recomendado 64MB de RAM y unos cuantos gigas de disco para el proxy.

Los datos de configuración que tenemos que tener claros son:

• IP para la red LAN Segura
• IP para la red DMZ
• IP para la red Insegura
• Nombre del cortafuegos
• Si vamos a usar DHCP para la LAN Segura (trae uno incorporado)

En nuestro caso vamos a utilizar los siguientes datos:

• IP LAN Segura: 192.168.0.1 / 255.255.255.0
• IP DMZ: 192.168.1.1/ 255.255.255.0
• IP red Insegura: DHCP (Nuestro router nos da la IP automáticamente)
  
• Nombre: firewall
• ¿Usamos DHCP para la LAN?: Sí

Los manuales que acompañan a SmoothWall Express indican perfectamente pantalla a pantalla el proceso de instalación, por lo que no nos vamos a detener en el mismo. Una vez instalado el equipo, podremos acceder a la consola de administración web del firewall a través de la dirección:

http://nombre_del _firewall:81 o
https://nombre_del _firewall:441
















Desde las pestañas podremos acceder a todos los servicios que nos ofrece el firewall. Tendremos que actualizar todos los parches de seguridad para estar seguros nada más empezar. Esto lo haremos desde la pestaña "Maintenance-->Updates". Una vez actualizados, pasaremos a configurar el DHCP para que nuestro servidor de base de datos (que se encuentra en la LAN) tenga una dirección IP estática:

• Pulsaremos sobre la pestaña "Services" (nos pedirá autentificación para poder acceder)
• Entraremos en "dhcp"

Aquí podremos dar de alta una nueva regla a partir de la MAC del equipo para que le asigne una IP fija. En nuestro caso vamos a darle la IP 192.168.0.2, por lo que cambiaremos la configuración del servidor DHCP para que empiece a dar direcciones a partir de la dirección 192.168.0.3.
















Activaremos a continuación la detección de intrusos del firewall para darle una protección extra más y también el acceso remoto mediante SSH que utilizaremos más tarde para conectarnos al servidor.

En este punto tenemos configurado el firewall para evitar las entradas desde internet, pero nos faltan los siguientes puntos:

• Publicación del Servidor Web
• Control de Acceso a Internet por parte de los clientes

Publicación del Servidor Web:
Para poder publicar el servidor web necesitaremos tener los siguientes puntos resueltos:

• Haber obtenido una IP fija por parte de nuestro proveedor para nuestro router
• Tener los puertos del web abiertos en el router para permitir la entrada
• Darle una IP al servidor web (en nuestro caso 192.168.1.2, recordemos que la interfaz de la DMZ tiene la IP 192.168.1.1)
  

Una vez solucionado este tema, lo que tendremos que hacer será conectar nuestro servidor a la interfaz naranja del firewall y habilitar una nueva regla de entrada a la DMZ desde internet.












Configuramos la regla para que las peticiones al puerto 80 desde cualquier IP se redirijan a nuestro servidor web.

Una vez hecho esto, tenemos que habilitar la comunicación entre el servidor web y el de base de datos que se encuentra en la LAN segura. Para hacer esto, entraremos en la opción "dmz pinholes".













En este caso, configuramos una regla para acceder al puerto 3306 (el de MySQL) desde la IP 192.168.1.2 (servidor web) a 192.168.0.2 (servidor de base de datos).

Con esto tenemos configurada nuestra publicación del servidor web. Nos falta tener el control de acceso a internet por parte de los usuarios.

Advanced Web Proxy:
El Advanced Web Proxy es una extensión de SmoothWall Express para permitir una gestión mucho más potente del acceso a internet que la que trae por defecto el servidor. Las características principales que ofrece son:

• Autentificación de varios tipos (local, LDAP, RADIUS, Dominio de Windows, identd)
• Manejo de grupos de usuarios
• Bloqueo de browsers no permitidos
• Reglas de acceso a internet por horas
• Control del ancho de banda
• CRE Classroom Extension para la gestión de aulas por personas sin conocimiento técnico

Para la instalación necesitaremos los dos programas que se comentaron al principio FileZilla y Putty. Con el primero podremos copiar el fichero de la descarga a la carpeta del servidor correspondiente y con Putty podremos acceder al servidor mediante SSH e instalar el paquete. Las instrucciones que se proporcionan con advproxy son muy detalladas y no vamos a entrar en el proceso de instalación.

Lo que nos queda es configurar el advproxy para que todos los clientes tengan que pasar por él obligatoriamente. Para hacerlo tendremos que deshabilitar todo el tráfico saliente obligando a que pase por el proxy. Al hacer esto, tendremos control sobre quién puede y quién no puede salir a Internet:

• Mediante Putty nos conectamos al servidor e introducimos las credenciales de root
• Accedemos al directorio /etc/rc.d
• Abrimos con "vi" el fichero rc.firewall.up donde se guardan las políticas
• Introduciremos por cada puerto la siguiente línea (debajo de):
• /sbin/iptables -P INPUT DROP
  /sbin/iptables -P FORWARD DROP
  /sbin/iptables -P OUTPUT ACCEPT
  
• # Block direct web access from inside
  /sbin/iptables -A FORWARD -i $GREEN_DEV -o ppp0 -p TCP --dport 80 -j DROP
  

Los puertos a bloquear son: 80,81,443,3128,6588,8000,8080,8181. Una vez realizados estos cambios, guardaremos el fichero y volveremos a la interfaz web para habilitar el uso del proxy. Habrá aparecido una nueva pestaña llamada "Advanced Proxy" dentro de "Services". Dentro de ella tendremos todas las opciones para habilitar tráfico por horas, bloquear IPs, crear grupos mediante la extensión CRE, etc.

Conclusión:
Finalmente hemos conseguido montar nuestra infraestructura de seguridad para poder realizar las tres tareas que nos planteamos en un principio:

• Tener nuestro servidor web publicado
• Tener una red LAN segura
• Tener control sobre el acceso a internet por parte de los usuarios

El tiempo de configuración es muy corto y en uno o dos días podeis tener montado y configurado vuestro firewall. Existen múltiples extensiones para SmoothWall disponibles en Internet (control de contenidos, reglas avanzadas, etc.) así que podeis personalizar vuestra instalación tanto como queráis.

Espero que os haya gustado este artículo sobre la seguridad en nuestras instalaciones.

Administración Remota (Hamachi y UltraVNC)

Suele ser una problemática importante en el sector de la administración informática cuando aquellos equipos que se deben controlar se encuentran en ubicaciones de difícil acceso. Existen muchos negocios que disponen de diferentes sedes, oficinas o equipos geográficamente dispersos. En estos casos, la administración y control suele ser bastante incómoda, obligando a muchos desplazamientos o a arreglos temporales que se suelen convertir en definitivos en la mayoría de los casos.

Vamos a ver en este artículo cómo configurar varias VPNs para un negocio con varias oficinas de forma que al final tengamos todos los equipos en la misma LAN y podamos administrarlos. Para realizar esto nos basamos en dos productos gratuitos que nos ofrecen la funcionalidad que queremos: UltraVNC y Hamachi.

UltraVNC:

UltraVNC es un software gratuito que nos permite acceder remotamente al escritorio de cualquier ordenador. Podemos usar el teclado y el ratón remoto como si estuviéramos sentados frente al ordenador.

Para usar este software sólo tenemos que descargarnos la última versión y realizar una pequeña instalación. UltraVNC se compone básicamente de dos componentes, el visor y el servidor. A cada equipo que queramos monitorizar le tendremos que instalar el UltraVNC Server para que nos presente el escritorio. Aquellos equipos desde los que vayamos a monitorizar les instalaremos el UltraVNC Viewer. La instalación es muy sencilla y se compone de muy pocos pasos bien explicados en la página web.

Una vez instalado el UltraVNC Server, nos pedirá que pongamos una contraseña para evitar entradas no autorizadas. Cuando queramos conectarnos desde el visor, nos pedirá esta contraseña. Al introducirla, accederemos al escritorio real del equipo remoto.

Podemos tener monitorizados tantos equipos como queramos, sin límite. Únicamente tendremos que instalar el programa en ellos. Mediante esta herramienta podemos controlar aquellos equipos que tengamos en nuestra LAN o a los que tengamos acceso (modem, VPN). En nuestro caso vamos a configurar ahora las VPN para que podamos acceder a los equipos de las oficinas remotas.

Hamachi:

Hamachi es una aplicación para realizar VPN sin configuración técnica por parte del usuario. Permite la unión de múltiples equipos en una sola red segura como si estuvieran en la misma LAN.

Como se puede suponer, las posibilidades de Hamachi son muy grandes (monitorización, servidores web internos, juegos, compartición de archivos, música, etc...). Nos centraremos en el área de monitorización, aunque todo lo escrito aquí se puede aplicar a cualquier otro ámbito.

En primer lugar, partimos de la siguiente situación:



















Disponemos de una oficina principal y dos oficinas secundarias. El administrador se encuentra en la oficina principal. Cada oficina dispone de sus propios servidores para funcionar de manera autónoma.

Partiendo de esta situación, vamos a montar una infraestructura de VPNs que permita al administrador administrar los servidores y monitorizar a los usuarios, pudiendo realizar tareas preventivas y de apoyo a los mismos.

Lo primero que debemos hacer es descargarnos el software de Hamachi a nuestro equipo que será el administrador. La instalación es muy simple solamente marcaremos la opción de deshabilitar el acceso a los servicios vulnerables de Windows (compartición de archivos y servicios propensos a ataques). Hamachi instala una nueva interfaz de red que permitirá conectarnos a su servidor para montar la VPN.

Una vez instalado, nos conectaremos a la red de Hamachi que nos asignará una IP única para nuestra interfaz de red y nos dará un identificador único también. Una vez lo tengamos vamos a crear 4 redes nuevas:

• Red de Servidores: para albergar los servidores de todas las oficinas.
• Red de la Oficina Principal: equipos de usuario de esta oficina
  
• Red de la Oficina Secundaria 1: equipos de usuario
  
• Red de la Oficina Secundaria 2: equipos de usuario
  

Para cada red tendremos que dar un nombre identificador y una contraseña de acceso a la red. Hay que tener en cuenta que para la versión gratuita, el número máximo de equipos en una red virtual es de 16 incluyendo al propietario y que cada usuario puede pertenecer a 64 redes como máximo, por lo que si una oficina tiene más de 16 equipos, tendremos que crear varias redes.

Una vez dada la contraseña, habremos creado la red y seremos los propietarios de la misma. En este punto, tendremos que instalar el software de Hamachi en todos aquellos equipos que queramos que entren en alguna de las redes que hemos creado. Al configurarlos, en vez de crear una red, les diremos que se unan a la red correspondiente. Al arrancar los equipos, automáticamente se arranca el cliente de Hamachi, de forma que tendremos a todos nuestros equipos en las redes que queremos y de las que somos propietarios.



















Hamachi incluye un administrador web que nos permitirá ver el estado de nuestros clientes y echarlos de nuestras redes si queremos. Para acceder a la administración web deberemos crearnos una cuenta en MyHamachi.

Finalmente, lo que tenemos es lo que se refleja en el siguiente esquema:























El administrador podrá acceder a todos los equipos a través de las diferentes VPNs creadas como si estuviesen en su misma LAN.


Unión de UltraVNC y Hamachi:
Como habíamos instalado UltraVNC en todos los equipos, podremos administrar desde el ordenador del administrador todos los equipos de nuestra oficina de una manera fácil y eficiente. El administrador podrá acceder a los equipos desde cualquier ubicación que disponga de una conexión a internet.

Espero que os haya gustado este artículo y que le saquéis el máximo de provecho a estas herramientas.