sábado, 25 de octubre de 2014

Manjaro, su paquetería y un truco interesante

Situación: Manjaro me dice mediante su interfaz gráfica que tengo dos paquetes para actualizar. Pero ejecuto pacman -Syyuu y yaourt -Syyuu, y no aparece nada para actualizar.
Una paradoja, no? Pues bien, uno de los paquetes que tengo instalados por medio del yaourt tal parece que es una versión de desarrollo. Entonces, no la actualiza con el modelo nominal de comandos pacman y/o yaourt.
El comando que me salvó la vida fue el siguiente:

yaourt -Syyua --devel

Simple, sencillo, y al pie.

lunes, 1 de septiembre de 2014

Migración de ownCloud entre Ubuntu y Manjaro

Nuevamente, nos encontramos ante el dilema de tener que migrar los servicios de ownCloud que ya teníamos funcionando en Ubuntu, donde se instaló utilizando el backend SQLite, hacia Manjaro, donde se pretende que todo siga funcionando exáctamente igual que antes.
A nivel estructural, en Ubuntu el servicio pendía del mismo Apache, y su directorio era /var/www/owncloud.
En Manjaro los directorios del servidor web no penden de /var/www, sino de /srv/http, esto debe ser un punto a tener en cuenta.
Otro punto fundamental es que la versión de ownCloud de Ubuntu era la 6, mientras que en Manjaro cuando se implemente por medio de su gestor de paquetes (pacman) se implementará la 7.
Ahora bien, cuando pensamos en una migración debemos tener en cuenta que sus usuarios no deben notar la diferencia entre la anterior modalidad de trabajo y la nueva, por lo que hay que considerar lo siguiente:

  • Los usuarios y sus claves deben conservar tal y como estaban. Si estábamos utilizando un backend SQLite, tendremos que respetar su información. En el futuro veremos la forma, una vez migrado este producto, de pasar de una base de datos SQLite a una MySQL, pero por ahora, consideraremos que nuestras bases siempre estarán en SQLite.
  • Los espacios sincronizados deben ser los mismos.
  • La información de versionado debe conservarse.
  • La información de archivos borrados debe conservarse.
  • Los add-ons de ownCloud usados en la anterior versión deben estar presentes en la nueva. Esta parte puede ser complicada, ya que nada ni nadie nos asegurará que los mismos add-ons estén disponibles para una u otra versión de ownCloud.

El primer punto de todo esto será la instalación de Apache y PHP, cosa que si bien excede este artículo, es bien sencillo gracias al uso del mismo gestor de paquetes de Manjaro, antes mencionado.
Una vez que estos paquetes estén instalados, procederemos a la implementación del paquete de ownCloud en sí mismo, usando pacman:

pacman -S owncloud php-pear php-sqlite php-intl
pear install MDB2

En el proceso de implementación no se solicitará ningún tipo de confirmación de ninguna índole, por lo que el trabajo duro quedará todo de nuestro lado.
Un punto importante a tener en cuenta: Manjaro instala archivos de este paquete no en /srv/http, sino en /usr/share/webapps/owncloud.
Mucho cuidado a la hora de configurar espacios, ya que no olvidemos que la información de los usuarios de ownCloud es guardada en el subdirectorio data de este producto, así como la configuración se encontrará en el subdirectorio config. Si los datos de los usuarios son en extremos voluminosos, podemos agotar nuestro espacio en disco.
Así es que me dispuse a hacer un tar de los archivos existentes en data y config de mi vieja instalación de ownCloud sobre Ubuntu, para des-tarear todo en el nuevo espacio, /usr/share/webapps/owncloud, considerando que mi vieja instalación se encontraba montada en /viejo_disco:

cd /viejo_disco/var/www/owncloud
tar zcvf /usr/share/webapps/owncloud/dataconfig.tgz ./data ./config (remarco de nuevo el tema del espacio en disco!)
cd /etc/webapps/owncloud/config
cp config.sample.php config.sample.php.original
cd /usr/share/webapps/owncloud
tar zxvf dataconfig.tgz

Ahora, a configurar archivos, que tanto nos gusta:

cp /etc/webapps/owncloud/apache.example.conf /etc/httpd/conf/extra/owncloud.conf
vi /etc/httpd/conf/httpd.conf

agregar, al final del archivo, la entrada siguiente:

Include conf/extra/owncloud.conf

Cambiamos permisos:

chown -R http:http /usr/share/webapps/owncloud/

Cambiar un parámetro de la configuración:

vi /usr/share/webapps/owncloud/config/config.php

...y modificar la línea siguiente para que quede así:

'datadirectory' => '/usr/share/webapps/owncloud/data',

Entonces bajamos y subimos httpd:

systemctl stop httpd
systemctl start httpd

Listo!
Cuando ingresemos de nuevo a nuestro sitio de owncloud encontraremos una ventana que nos indica que debemos seguir adelante con la conversión de la aplicación a la nueva versión:




Obviamente, presionamos "Start update". Luego de unos minutos, tendremos listo nuestro ownCloud en Manjaro, casi sin dolor.

Felicidades, a vivir los nuevos niveles de performance!

domingo, 31 de agosto de 2014

Iluminando las redes con OpenDaylight

 

    Ya hace unos años que el proyecto Crossbow tuvo lugar y se implementó en plataformas tales como OpenSolaris, Illumos, y sus derivados. OpenIndiana es uno de sus actuales exponentes, y como es lógico, posee las caracteristicas de redes virtualizadas que su kernel posibilita.

    Esto se veía como una fantasía en entornos GNU/Linux no sólo por cuestiones de tecnología (sabemos que aunque no sean tan extensamente usados, kernels como los de Illumos, o las diferentes variantes de *BSD son mucho más avanzados que el Linux), sino también por estandarización.

    Para comenzar con este artículo, ingresemos en nuestro sistema dos términos: Software Defined Networking (SDN) y Network Functions Virtualization (NFV).

    OpenDaylight es un proyecto que intenta establecer un framework de código y blueprints que permitan acelerar la generación y adopción de SDNs. Y no es sólo para GNU/Linux, sino que tiene aires de grandeza, y apunta a estar disponible para muchos sistemas operativos.

Limitaciones de la infraestructura de red actual

    Hoy en día los usuarios de redes se están volviendo muy exquisitos. El uso de infinidad de dispositivos móviles, asi como el poder interconectarlos con los sistemas que los alimentan está llevando a la industria a complicarse cada día más, y no poder responder, en tiempo y forma, a sus demandas, con la consiguiente pérdida de valor en el mercado. Aparte, cuando se quiere proveer lo que se requiere, la inversión en infraestructura de red es suficientemente alta como para plantearse si conviene o no continuar en ese mercado, o sencillamente bajar las persianas, y dejar que otro, con más espalda financiera, o con mejor existencia de infraestructura, tome el lugar.

    Los protocolos de red tienden a ser definidos en forma aislada unos de otros, por lo que cada uno intenta resolver una problemática particular, para la cualha sido concebido. Claro esta, cuando los protocolos se desarrollan de esta forma, la complejidad derivada de su interacción puede escalar en forma geométrica con cada nuevo protocolo que se introduce. Inclusive, en algunos casos, la falta de flexibilidad de algunos fabricantes lleva a que sus productos sólo puedan “conversar” con un muy acotado conjunto de otros sistemas. A veces, inclusive del mismo fabricante.

    Eso lleva, también, a que las infraestructuras de red se vuelvan relativamente estáticas, ya que una regla de oro en este tipo de entornos es que “si algo ya está funcionando, no se debe modificar por nada del mundo”. Y si se requiere de agregar o modificar su esquema, se debe, previamente, analizar todos y cada uno de los elementos que en él existen para evitar hacer más ruido de lo normal, y generar más problemas que soluciones.

    Frente a esta política de lo estático en cuestiones de redes, tenemos la completamente opuesta referida a los servidores, donde la virtualización ha logrado que los usuarios ya no se preocupen por dónde estará su máquina, e inclusive en muchos casos ni siquiera sobre si es necesario o no contar con alguna. Lógicamente, esto también lleva a que la gente ya no esté muy interesada que digamos por el lugar físico donde estarán ubicados los sistemas, siempre y cuando sean alcanzables por las redes definidas, así como que cuenten con las necesidades de disponibilidad y calidad de servicio que se especifican en los contratos que se firman con los proveedores.

    Hace muchos años las aplicaciones se encontraban alojadas en una única máquina y le brindaban servicio a una serie de clientes preestablecidos. Hoy en día, un servicio puede estar conformado por otros tantos distribuidos en infinidd de máquinas virtuales que tienen extensas y complejísimas conversaciones de intercambio de información. Esa máquinas virtuales, en la mayor parte de los casos, son tan dinámicas como para moverse de equipo físico a equipo físico por el hecho de mejorar aspectos de disponibilidad, consumo de recursos, o sencillamente para rebalancearse entre diferentes sistemas. Con entornos de este estilo, una infraestructura estática de red está completamente fuera de tono, y no puede abastecer este tipo de necesidades. Es muy común ver entornos donde se debe manejar en forma manual todo el conjunto de modificaciones derivadas de esto.

    No pensemos en los casos en los que un vendedor de tecnología de red comienza a tener problemas financieros que lo llevan a tener que cerrar sus puertas, porque es ahí cuando la locura de los administradores de red puede verse bien desplegada. No se sabe, en el caso de cambiar una marca por otra, cuánto podrá o no interactuar con el resto del ecosistema, o si podrá realmente abastecer de este tipo de políticas a los servidores, tanto físicos como virtuales, que conforman un servicio. Pánico total.



Nacer del caos

    La importancia de un SDN es permitir a los usuarios de sistemas operativos que puedan programar las diferentes capas de red, separando el control de los datos o del forwarding de información. Cuenta con todas las bondades de la virtualización en el sentido más amplio del término, como ser la optimización de los recursos de red, mejorar los tiempos de implementación (siempre será mucho más sencillo pensar en la implementación de un vSwitch, o un swith virtual, que en la adquisición de uno físico, aprender su “idioma”, programarlo, probarlo, etc.), y sobre todo, permitir que otras porciones de software comanden la generación o modificación de redes según sea necesario.

    Si, por ejemplo, un usuario requiere acceso a una porción de la red, pero sólo a través de un programa, uno podría pensar en la capacidad de ese programa de rearmar la estructura de la red que lo conecta con algún otro sistema de forma tal de enlazar la del usuario con la de destino. Si se quisiera hacer eso desde el punto de vista físico, no habría otra opción más que desplegar cableados y programar equipos que, dada la necesidad de contar con inteligencia en las capas superiores del conjunto OSI, de seguro no serían nada económicos.

    Lo cierto es que cada vendedor de equipamiento que deseó implementar algo de este estilo lo hizo de forma bastante propietaria, inclusive algunas veces hasta privativa. En medio de este gran lío, nace un proyecto que apunta a estandarizar y entregar los elementos necesarios para que los desarrollos futuros estén basados en estos estándares, así como cumplan con los elementos necesarios para permitir la interoperabilidad tan deseada.

    Qué mejor en este caso (caso o caos, úsese indistintamente) que un proyecto aparecido con una licencia EPL (Eclipse Public License, la que se usa para los proyectos Java, que no es la que personalmente más me gusta, pero está aprobada como licencia de código libre, ergo la tengo que aguantar con una sonrisa) que establece las bases para lo que vendrá. Y encima de todo, el proyecto se aloja ni más ni menos que en la Linux Foundation, que cada día demuestra, al menos hasta ahora y esperando no tener que remendar esta opinión en el futuro, estar un poco más a la altura de las circunstancias.

Los casos de uso


    La Open Network Foundation (ONF) es una entidad dirigida por proveedores de equipamiento de red notables, desarrolladores de aplicaciones y software de redes, fabricantes de computadoras y de semiconductores. Casi se podría decir que en la ONF “toda la carne está en el asador” (expresión típica de las costas donde vivo, Argentina, donde el asador siempre debe estar bien lleno de alimentos deliciosos).

    La unión de estas figuras intenta fijar en un SDN funciones específicas que permitan la satisfacción de una variedad de necesidades.

    A nivel de campus que permitan la centralización de las facultades de aprovisionamiento, así como la convergencia de los modelos de datos, voz, y video, en cualquier tipo de dispositivos, ya se trate de aquellos interconectados por redes cableadas como inalámbricas. En este caso los SDNs deben soportar el aprovisionamiento y la gestión completamente automatizada de los recursos de red, los que a la vez estarán definidos por por los perfiles de sus usuarios y de las aplicaciones que ellos deben utlizar.

    A nivel de centro de cómputos, un SDN debe simplificar al máximo la virtualización de de la red, así como agilizar su escalabilidad a niveles utópicos, al menos al día de la fecha. Lógicamente, debe poder integrarse con los subsistemas de almacenamiento existentes, ya que los mismos también hacen uso extensivo de funciones de red, así como de virtualización.

    A nivel de nube ya se trate de una privada o una pública, o inclusive una hibrida, un SDN debe permitir que los recursos de red sean generados de una forma completamente flexible, permitiendo la modificación topológica, o el cambio de arquitectura, de una manera natural, sin terribles esfuerzos de reconfiguración, y sobre todo sin pánico sobre lo que haya por debajo de ellos.

    Obviamente, los proveedores de servicios se sentirán felices de utilizar este tipo de tecnologías, ya que las mismas permiten bajar drásticamente los costos de equipamiento, y ni que hablar de los esfuerzos de operación y administración de las redes.

Del caos puede nacer más caos, o no

    OpenDaylight supone el soporte para otros entornos anteriormente desarrollados, como ser OpenFlow, y promete ser suficientemente extensible como para hacerlo también con otros estándares abiertos del estilo de I2RS (Interface to the Routing System), VxLAN (Virtual Extensible LAN), o PCEP (Path Computation Element Protocol).

    OpenFlow aparece en este escenario como la primera interfaz de comunicaciones estandarizada definida entre las capas de control y de forwarding de una arquitectura de un SDN, permitiendo entonces la manipulación directa de sus reglas tanto a nivel físico como virtual. Esto incluye switches, routers, y demás.

    Con esto, que parece bastante trivial, se mueve el control de los switches y routers del interior de cada uno de ellos a una capa superior donde todos pueden ser manejados en una forma centralizada, y con un lenguaje estándar. Ergo, cualquier tarea de administración, incluyendo la automatización de la misma, pueden ser ejecutadas desde un único lugar, con un único método. El sueño del sysadmin, hecho realidad.

Hidrogenoterapia

    Así llegamos a Hydrogen, la primera versión de OpenDaylight, lista para bajar desde el sitio opendaylight.org en tres sabores: Base, Virtualization y Service Provider.

    La versión Base está pensada para los que queremos hacer pruebas, verificar su funcionamiento, tanto en ambientes físicos como virtuales. Dentro de sus módulos encontramos los siguientes:

  • Controller: Un SDN multiprotocolo altamente escalable y extensible basado en OSGi. OSGi son las siglas de Open Services Gateway initiative, y define especificaciones abiertas de software para permitir el diseño de plataformas multipropósito compatibles.

  • Plugin OpenFlow: Se incorpora un módulo de compatibilidad con las APIs de este módulo.

  • Bibliotecas de los protocolos de OpenFlow: Esto es una implementación de la versión 1.3 de la biblioteca de protocolos de Openflow, específicamente la correspondiente a la especificación de switches 1.3.3, que permite la interconexión de los puertos de OpenFlow contra los de los diferentes dispositivos físicos o virtuales de una infraestructura de red.

  • OVSDB: Una base de datos que permite la gestión y manipulación de vSwitches. También es un protocolo de gestión usado para manipular la configuración de los Open vSwitches, que ha logrado un buen nivel de éxito gracias a su adopción por parte de varios fabricantes de switches ethernet. Entre las tablas que dicha base de datos posee encontramos las siguientes:

  • Open_vSwitch: configuración de un switch virtual.
  • Bridge: configuración de un bridge.
  • Port: configuración de un puerto.
  • Interface: configuración de un dispositivo físico de un puerto.
  • Flow_Table: configuración de Openflow.
  • QoS: configuración de niveles de servicio.
  • Queue: cola de salida a nivel de QoS.
  • Mirror: espejado de puertos.
  • Controller: configuración de un controller OpenFlow.
  • Manager: conexiones de gestión de OVSDB.
  • NetFlow: configuración de NetFlow.
  • SSL: configuración SSL.
  • sFlow: configuración de sFlow.
  • IPFIX: configuración de IPFIX.
  • Flow_Sample_Collector_Set: configuración de Flow_Sample_Collector_Set.

Las relaciones entre estas tablas se puede ver a continuación:


  • YANG Tools: Para los proyectos basados en OpenDaylight, un set de herramientas basadas en Java para NETCONF y YANG.

Un diagrama esquemático de OpenDaylight versión Base se puede ver a continuación:



    La versión Virtualization agrega, a los elementos de la versión Base, los siguientes:

  • Affinity Metadata Service: un conjunto de APIs para representar las relaciones de carga de trabajo y los niveles de servicios esperados de una red de este estilo.
  • Defense4All: un framework para la detección y mitigación de los riesgos posibles ante un ataque del estilo DdoS (Distributed Denial of Service).
  • Open DOVE: un esquema de virtualización de redes multiusuario basado en overlays, incorporado a las capas de control y de vSwitches.
  • Virtual Tenant Network: una aplicación de virtualización multiusuario basada en OpenFlow.

    Nótense las secciones resaltadas en el siguiente diagrama esquemático:



    Finalmente, la versión para proveedores de servicio, o Service Providers, agrega aspectos necesarios tales como:

BGP-LS/PCEP: soporte para gestión de tráfico basado en BGP-LS, y PCEP. El primero no es más que el viejo y querido Border Gateway Protocol, y el segundo fue pensado originalmente considerando que su entrada podría ser una gráfica de red, y su salida podría ser un camino de red y configurado.

    Un diagrama esquemático puede ser el siguiente:




Conclusion

    De seguro en el próximo tiempo veremos más y más proveedores de sistemas tanto de datos puros como de infraestructura de red afianzarse y garantizar su futuro a través de la adopción de estos nuevos paradigmas.

    Como sea, no perdamos de vista a Illumos, y sus descendientes, ya que para cuando el tema comienza a formar parte de la mesa de diálogo y desarrollo por un lado, tenemos lo mismo pero ya desarrollado, y funcionando, desde hace más de un lustro en OpenIndiana y OpenSolaris.