Tutorial: Comenzando con Openshift Online

En un post anterior hicimos un review completo de Openshift Online, la plataforma como servicio hospedada (hosted PaaS) de Red Hat que nos trae de manera gratuita una alternativa fuerte a opciones como Heroku o Google App Engine, pudiendo incluso competir (en varios casos) con un VPS o servidor dedicado. Como explicaba yo ayer, Openshift Online me gusta mucho porque nos trae lo mejor de 2 mundos: La nube administrada y los VPS.

El día de hoy haremos un tutorial completo sobre cómo iniciarse con OpenShift Online, para aquellos que se quedaron "picados" tras conocer sus bondades... Sin nada más que agregar al respecto, acompáñenme a continuación:

NOTA: Este tutorial se va a basar en Fedora Linux como sistema operativo base. Puedes seguirlo sin importar en cuál plataforma o distribución estés ya que las herramientas de Openshift son "platform agnostic" generalmente, pero si instalo un programa con el gestor de paquetes de fedora o hago algo específico de mi sistema, recuerda cambiar los comandos de manera acorde según tu distribución y/o plataforma.

1) Preparando el entorno

Necesitarás tener listo un entorno ruby/rubygems en tu computadora primero. Checa este tutorial para dicho fin. También necesitarás tener Git instalado y configurado, acá otro tutorial al respecto. Una vez que estos requerimientos se cumplan puedes proseguir.

2) Crea tu cuenta

Ahora necesitarás crear tu cuenta en Openshift Online, esto se hace acá.

3) Instalando herramientas (y configuración)

Una vez creada tu cuenta, ya podrás instalar y configurar las herramientas necesarias para trabajar con Openshift:

# sudo gem install rhc
$ rhc setup

El segundo comando te pedirá hacer algunas confirmaciones y después te pedirá hacer login:

Login to openshift.redhat.com: user@example.com
Password: password

Luego se te pedirá generar un token en tu directorio personal. Si accedes (recomendado), se generará y cuando éste expire se te pedirá tu contraseña de nuevo para hacer login desde la consola en Openshift Online:

OpenShift can create and store a token on disk which allows to you to access the server without using your password. The key is stored in your home directory and should be kept secret. You can delete the key at any time by running 'rhc logout.

Generate a token now? (yes|no) yes

Generating an authorization token for this client ... lasts about 1 day

Más tarde el asistente revisará si tienes claves ssh en tu directorio personal y de ser así, te pedirá elegir una para subir a openshift. De no encontrar lo que busca generará una nueva y te preguntará si quieres subirla como tu clave ssh predeterminada. Generalmente yo en este paso opto por el no (debido a que mantengo mis claves ssh en otro directorio) y subo la indicada más tarde, pero si a ti no te molesta tenerlas en ~/.ssh como es habitual accede al prompt por defecto y listo:

No SSH keys were found. We will generate a pair of keys for you.

Created: ~/.ssh/id_rsa.pub

Your public ssh key must be uploaded to the OpenShift server to access code.

Upload now? (yes|no) yes

Since you do not have any keys associated with your OpenShift account, your new key will be uploaded as the 'default' key

Uploading key 'default' from ~/.ssh/id_rsa.pub... done

Si quieres subir una clave SSH propia que se encuentre en otro directorio, dile que no al prompt por default, termina los demás pasos en el asistente y al finalizar, utiliza el comando:

rhc sshkey add -i key-name -k pubKey-path

Recuerda que de hacer esto, cada que inicies sesión debes añadir dicha clave al agente SSH con:

ssh-add privKey-path

Para poder trabajar con la consola de Openshift... (Aunque también puedes hacer un script que corra al inicio de sesión para automatizar esto).

Más tarde se te pedirá ingresar un subdominio personalizado para tus aplicaciones:

Checking for a domain ... none

Your domain is unique to your account and is the suffix of the public URLs we assign to your applications. You may configure your domain here or leave it blank and use 'rhc domain create' to create a domain later. You will not be able to create applications without first creating a domain.

Please enter a domain (letters and numbers only) ||: mydomain

Your domain name 'mydomain' has been successfully created

Una vez que terminas el asistente, ya puedes crear aplicaciones en tu cuenta.

4) Creando nuestra primera app

Hacemos login en Openshift Online y damos click en "Create your first application now", esto nos llevará a una página con los tipos de aplicaciones que podemos crear:



Debido a que Openshift nos hizo instalar un entorno de desarrollo ruby, no veo porqué no hacer una ruby app como muestra para comenzar. Seleccionamos Ruby 2.0.0 en la lista de arriba y tendremos que configurar nuestra aplicación a continuación. Les recomiendo permitir que escale con el tráfico para aprovechar al máximo los recursos gratuitos disponibles y tener load balancing y high availability habilitados por defecto:


Después de crear mi aplicación (quizá tome unos minutos), tendré la siguiente pantalla delante de mi:


Procedo a clonar la aplicación a mi equipo con el comando que me listan y al hacer cd al nuevo directorio en la consola, puedo ver que tengo una app "esqueleto" lista para empezar a trabajar:


Si abro el README.md (en este caso con el comando cat) veré que me apunta a la documentación para empezar a trabajar con el "cartucho ruby" en Openshift...

Regreso a mi dashboard online y ahora ya puedo dar click en "Continue to the application overview page" para añadir una base de datos.

5) Base de datos y cartuchos

En la ventana de overview de aplicación, podemos ver que nos dan la opción de añadir una base de datos o ver qué otros "cartuchos" podemos agregar. Los cartuchos son "piezas" para tu aplicación (base de datos, cron, jenkins, etc.) que puedes necesitar para ir armando tu app:


En este caso sólo añadiré MongoDB 2.4 (que es la única versión de esta DB que soportan de momento oficialmente) para mi aplicación de ejemplo:


y tras añadirla, tendré un mensaje de confirmación con una URI, un usuario, una contraseña y un nombre de DB para usar MongoDB en mi aplicación de manera segura:


6) Deployment

En este punto ya puedo empezar a armar mi aplicación de manera local y subir los cambios mediante Git. Supongamos que en este caso quiero trabajar con bundler y unas cuántas ruby gems... Sigo este tutorial para integrar Bundler en mi aplicación Ruby y añado mis gemas al Gemfile... En este caso voy a hacer unos scripts rápidamente para probar la integración con MongoDB de mi app:

NOTA: Para hacer esto, puedo checar las variables de entorno que Openshift tiene para MongoDB por acá (así funciona para la mayoría de cartuchos) de manera que no tenga que preocuparme por meter los datos de manera "hard coded".


Ya que modifiqué un poco el código necesito subirlo a Openshift; Esto es tan sencillo como hacer:

$ git add .
$ git commit -m "mongoid test"
$ git push

7) Manejo por consola

Una vez arriba el código, necesito probarlo. Para acceder a la consola de Openshift, basta con hacer uso de la liga ssh que ellos me proveen, (asegurándome de haber agregado mi clave ssh como se requiere):


Una vez accedo, puedo probar el código que subí con:

$ cd app-root/repo
$ ruby main.rb

Pero oh snap! Hay un bug fatal (referencia 1, referencia 2, referencia 3) que me impide usar MongoDB como yo quiero en este caso dentro de Openshift v2 al parecer:


Bueno, entonces tendré que...

8) Eliminar un cartucho

MongoDB no funcionó, así que la eliminaré y mejor utilizaré SQLite3 (que ya viene por defecto activ@ en OpenShift); Para eliminar un cartucho, corremos el comando:

rhc cartridge remove -a {appName} -c {cartridgeName}

Este comando nos pedirá confirmación y procederá a eliminar el cartucho de nuestra aplicación.

9) Marketplace


Antes de mostrar el código modificado, hay una cosa más que debemos revisar: El marketplace. Openshift tiene este marketplace al que puedes acceder para dotar a tus aplicaciones de servicios extras. ¿Necesitas envío de correos? Puedes activar Sendgrid Free para tener 25,000 correos gratuitos cada mes o pagar por cualquiera de sus mejores planes:


Todos estos goodies se pueden activar con un solo click desde el mismo marketplace, sin mayor problema. Cabe destacar que si es de tu interés, puedes crear add-ons y subirlos al marketplace para que otros puedan hacer uso de ellos.

10) Port forwarding

Si quiero trabajar de manera local en el entorno de producción (ya habiéndolo subido a Openshift) lo que puedo hacer es correr el siguiente comando:

rhc port-forward -a {appName}

Que se encargará de redireccionar puertos locales a los puertos de la aplicación de Openshift en modo de producción:


En este caso si visito el puerto local asignado a httpd, debería ver la index.html pública de mi app en vivo.

Finalizando...

Ahora sólo me queda cambiar el código de mi app y subirlo de nuevo para hacer uso de SQLite en lugar de MongoDB como prometí. He aquí el cambio:


Cabe destacar que elminé mongoid.yml y Gemfile.lock, después corrí:

$ bundle install

Accedí por ssh a la consola de mi aplicación y dentro de la misma ejecuté:

$ cd app-root/repo
$ bundle install
$ ruby main.rb

Lo que me entregó el siguiente resultado:


Mismo que indica que todo funciona a la perfección.

Extras

Las aplicaciones en el plan Free cuentan con algo que se llama "idling", So básicamente si tu app no recibe requests en 24 horas, ésta se "pausa" un momento hasta que otra request llega. Si quieres evitar esto, puedes hacer upgrade al plan bronze (que igual es gratis pero requiere tus datos de billing ya que te permite consumir recursos pagados), o bien crear un scrapBot con algo como CasperJS para simular hits en tu aplicación de manera continua. Hacer upgrade al plan bronze en un país no oficialmente soportado requiere que te pongas en contacto con Openshift para expresar tu interés personal y así poder hacer dicho cambio.

Algunos enlaces relevantes:


Openshift de Red Hat: ¿Mejor que un VPS? (Review)


¿Qué es Openshift?


OpenShift es una plataforma como servicio (PaaS) que Red Hat provee para montar aplicaciones en una infraestructura operada por ellos. En resumen, se trata de una alternativa a los ya famosos Heroku o Google App Engine pero que además de correr de manera "Hosted" también puedes operar tu mismo en tu infraestructura si eso es lo que deseas (Como ocurre con OpenStack exceptuando el hecho de que éstos últimos no ofrecen una opción hospedada) ya que cuenta también con una versión enterprise e incluso una opensource (origin) que puedes probar directo en tu Fedora Linux (por solo dar un ejemplo) desde hace algunas releases... Cabe destacar que (contrario a las alternativas hosted mencionadas), Openshift es un ecosistema bastante libre que podríamos declarar como un híbrido entre lo que es la nube administrada y otras opciones como los VPS y/o los servidores dedicados.

En este review nos centraremos en la versión hosted de Openshift (mejor conocida como Openshift Online) ya que es lo más sencillo para iniciarse con Openshift y (al menos en mi opinión) ofrece lo mejor de 2 mundos: El VPS y la Nube Administrada.

Ventajas de Openshift Online

Openshift Online tiene un muy buen plan gratuito que te ofrece 3 "gears" (más adelante veremos qué es eso) conjuntando en total:

  • 3GB de storage total 
  • 1.5GB de RAM
  • Todas las horas de CPU necesarias (1-3 cores en parallel programming)
  • Toda la banda ancha que requieras

Digo que es "lo mejor de 2 mundos" porque cuenta con las características que nos encantan de las nubes administradas junto con aquellas que nos hacen sentir "en control" dentro de un VPS, algunas de las cuales podrían ser:


  • No tiene plazos forzosos (es pay-as-you-go)
  • No cobran por los snapshots
  • Las apps tienen un subdominio personalizado  y puedes usar tu TLD
  • Ofrece SSL en todos sus planes
  • Tiene acceso SSH a la consola de la aplicación
  • El código se porta y maneja mediante Git


Entre otras...

Lo mejor es que cosas como la integración del acceso SSH o Git se hacen en cuestión de segundos con 1 o 2 comandos, a diferencia de un VPS donde tendríamos que hacer un setup inicial completo que nos podría llevar varios minutos o incluso hasta unas horas... Al ser una nube administrada, en OpenShift Online no te tienes que preocupar por el sistema operativo, el rendimiento del CPU, la optimización del almacenamiento, la seguridad general del deployment u otras cosas similares. Red Hat se encarga de los servidores mientras tu solo te encargas de desarrollar y subir.

Pregunta: ¿Me conviene migrar?

Hasta aquí puede sonar bastante bueno (y lo es) pero ¿es un reemplazo para tu VPS? Depende. Según la aplicación/sitio puede resultar mejor pasarse a Openshift debido a que


  • A) No cobran por ancho de banda utilizado (transferencia) ni horas de CPU
  • B) Es una nube administrada
  • C) Las aplicaciones son auto-escalables por instancias (gears)


Lo que importa considerar es si tu aplicación necesita más CPU/RAM y ancho de banda que almacenamiento o más almacenamiento que cualquier otra cosa y actuar acorde a tus circunstancias porque... ¿Recuerdas los "gears"? veamos qué son:

Gears are secure containers for your code. Each gear is allocated CPU, memory, disk, and network bandwidth. You can use a single gear to create an entire web application complete with a private database instance. Use multiple gears to create multiple applications or configure your applications to automatically scale in response to web traffic.

So, los gears son containers con CPU, Memoria, Almacenamiento y Ancho de banda. 1 gear small (de los que vienen 3 por default en el plan gratuito) tiene:


  • CPU ilimitado (1 core, ajuste variable)
  • 512MB de RAM
  • 1GB de almacenamiento
  • Ancho de banda ilimitado


Cada aplicación que creas en Openshift Online te ocupa 1 gear de manera predeterminada. Puedes "aislarla" a ese gear, (lo que significará que siempre tendrá a la mano sólo los recursos de dicho gear) o bien, permitir que escale con el tráfico/uso, utilizando tantos gears como tengas disponibles o sólo tantos como tu quieras (haciendo que una sola use el total de recursos gratuitos o bien, los compartan entre todas las que tengas de manera conjunta o individual); Además, Openshift tiene un marketplace donde puedes adquirir interesantes "addons" para tu aplicación como pueden ser Statica, un servicio para dotar tus apps de una IP pública estática (como si fueran un VPS) o New Relic para monitoreo entre otras cosas, muchas de éstas completamente gratis o con precios y planes muy accesibles e integraciones "easy as pie". Cabe destacar que uno puede desarrollar sus propios addons para el marketplace también... Gracias a este ecosistema no hay manera de que otro hosted PaaS (heroku/app engine, etc.) te ofrezca mejores prestaciones gratuitas que Openshift Online (al menos como yo lo veo).

Pero, ¿y mi proveedor de VPS? bueno, difícilmente va a superar el total de recursos gratuitos en precio considerando cómo funcionan los gears (hablando del total de RAM, CPU y banda ancha que puedes utilizar en una o varias aplicaciones sin pagar o si quiera introducir una tarjeta de crédito); Sin embargo en el apartado de almacenamiento, si ocupas bastante, los 3GB totales del plan gratuito se te van a quedar cortos y el almacenamiento puede resultar caro ya que directamente sólo tienes de 2 sopas:


  • Activar el plan silver ($20 USD/mo) y recibir 18GB de almacenamiento por default
  • Pagar $1 USD/GB al mes por almacenamiento extra a partir del plan bronze (Gratuito)


Aunque también podrías delegar tu almacenamiento a un VPS, un proveedor de base de datos como servicio (DaaS) o bien, a algún storage como Google Cloud Storage o Amazon S3 si estás manejando archivos estáticos para pagar menos, pero a la larga tienes que decidir en base a tu deployment y caso de uso... He aquí un poco más de información sobre los Gears y tipos de planes de Openshift Online:



NOTA: Cabe destacar que cuentan con planes de apoyo para startups, instituciones educativas, non-profits y proyectos opensource.

¿Dónde está el truco?

Claro que no todo es color de rosa, y por ejemplo de usar Openshift Online, tendrás que adaptarte casi al 100% a las versiones que soportan de los lenguajes de programación, bases de datos y plataformas que manejan si quieres aprovechar las ventajas de la nube administrada (aunque si quieres, puedes usar la opción "custom" y probar suerte haciendo funcionar algún lenguaje/framework o versión no oficialmente soportados); Además, el soporte técnico en las opciones no pagadas es 100% comunitario. También es importante destacar que OpenShift Online sólo ofrece como locaciones Estados Unidos y Europa para tus aplicaciones. Por otro lado, he notado que al alocar los 3 gears gratuitos a una sola aplicación, éstos se van dividiendo por "cartucho" (los cartuchos son "piezas" de tu aplicación) So, aunque la aplicación a nivel general goza de toda la RAM según los gears que haya escalado, todos los cores de CPU, y ancho de banda ilimitado en cualquier caso, en el caso del almacenamiento éste generalmente se divide en 1GB para el código y 1GB para la DB. Asumo que al llenarse uno u otro se asigna el GB adicional al espacio que lo requiera:


Así mismo como si añado otro cartucho que requiera almacenamiento (u otro gear) el GB adicional se añadirá a éste... De no permitir que la aplicación escale automáticamente, (asumiendo que le asignemos 1 solo gear por ejemplo) tanto la base de datos como el código compartirían el mismo GB... Es importante tomar esto en cuenta debido a que las diferentes bases de datos soportadas (SQLite, MongoDB, MySQL y PostgreSQL según he visto) tienen una footprint de almacenamiento por default distinta, al igual que los distintos tipos de proyectos según el lenguaje/framework que elijas.

Veredicto

Usa Openshift Online si:

  • Tu deployment se beneficiaría del total de recursos gratuitos compartidos
  • Tu aplicación usa banda ancha o CPU de manera intensiva
  • Tu deployment se beneficiaría de tener capacidades de paralell computing
  • Tu deployment se beneficiaría de tener load balancing/high availability habilitados por defecto 
  • Estás prototipando un proyecto y no quieres gastar en lo que validas tu modelo de negocio
  • Tienes una app que se beneficiaría de alguna de las ofertas/addons del marketplace
  • Tu sitio web ha subsistido bastante bien con 512MB - 1.5GB de RAM a lo largo de su vida
  • Tus costos de operación se reducen migrando a OpenShift Online en cualquiera de sus planes

No uses Openshift Online si:

  • Tu aplicación requiere una IP pública estática que de hecho vaya a tener muchísimos hits directos (ejemplo: un API sin Cloudflare)
  • Requieres múltiples aplicaciones y pagar por gears extra te sale más caro que rentar 1 VPS para ponerlas todas ahí o bien, usar App Engine (por ejemplo) donde se te permiten bastantes de forma gratuita.
  • Tu plan de storage sale más barato si haces deployment en App Engine y le pagas a Google sin preocuparte por hacer los bindings aparte (por ejemplo)
  • Requieres usar 1 versión específica de un lenguaje de programación, base de datos o plataforma no soportada de manera administrada por openshift directamente (en ese caso mejor opta por 1 VPS)
  • Necesitas una ubicación geográfica diferente a Estados Unidos o Europa para hospedar tu aplicación
  • Necesitas un entorno demasiado personalizado, casi casi "otra computadora" en la nube
Finalizando...

En el caso de las hosted PaaS, a menos que ocupes demasiadas aplicaciones y te salga más caro pagar por los gears extra, no hay manera (a como yo lo veo) de que otra plataforma como servicio hospedada te salga mejor que Openshift Online en cuanto a recursos gratuitos generales. La escalabilidad en almacenamiento es una situación completamente diferente ya que de usar Google App Engine (por ejemplo) a la larga te podría salir mejor quedarte en su ecosistema si tu app no suele sobrepasar las cuotas gratuitas de otra cosa que no sea almacenamiento (ya que sólo les pagarías por dicho almacenamiento extra). Hablando de un VPS, depende mucho del tipo de deployment que tengas, pero en muchos casos me parece que OpenShift Online puede recortar (incluso a $0) tus gastos de operación bajo diferentes escenarios. En un post futuro haré un tutorial sobre cómo iniciar con Openshift, pero mientras puedes aprender más sobre la plataforma en:



Compartir portapapeles entre 2 o más servidores gráficos en Linux



Supongamos que tengo 2 servidores gráficos corriendo en mi máquina, uno para el escritorio normal y uno para un Sandbox de SELinux. Si quiero compartir el portapapeles entre estos 2 servidores X entonces lo que tengo que hacer es instalar el paquete xclip en mi sistema principal y correr en el mismo este pequeño script:


(Después de descargarlo y marcarlo como ejecutable) en una consola para lograr el efecto deseado. Con él, estaré compartiendo de manera predeterminada los clipboards del servidor gráfico :0 y :1 de manera bidireccional, pero podemos ajustar el script para trabajar con otro set de displays o incluso más de 2 servidores X.

Cómo instalar Evernote (oficial) en GNU/Linux


Evernote es una aplicación para computadora, móviles y web que gracias a la nube nos permite mantener toda una biblioteca de libretas personales que contienen notas hechas por nosotros con texto, imágenes, audio etc. sincronizada entre todos nuestros dispositivos... Evernote es gratuito (aunque hay una versión plus y una premium) y sus ventajas son innumerables: Desde estudiar, hasta organizar tu día con día o bien, ayudarte a alcanzar tus metas... ¡Reemplaza el papel en tu vida y usa Evernote hoy mismo! Crea una cuenta acá; (El enlace es para referidos, si creas tu cuenta desde él, obtendrás 1 mes de Evernote Premium completamente gratis).

En GNU/Linux existen varios clientes nativos para administrar nuestro Evernote, siendo los más conocidos Everpad y Nixnote (el segundo es lo más cercano al cliente oficial); SIN EMBARGO la verdad es que a mi en Fedora Linux nunca me han funcionado bien ni uno ni otro, así que opté por la siguiente solución obvia que era ejecutar el cliente oficial para Windows usando Wine en la distribución; Contrario a lo que algunas personas decían sobre versiones pasadas en la web, a partir de Wine 1.7.xx es posible ejecutar prácticamente cualquier versión de Evernote Windows en GNU/Linux.

NOTA: En este tutorial usaré a Fedora Linux como distribución de referencia, cambiar los comandos de instalación de paquetes por los indicados según tu distro.

1) Instalar Wine y Winetricks

# dnf -y install wine cabextract
# wget http://winetricks.org/winetricks -O /usr/local/bin/winetricks && chmod +x /usr/local/bin/winetricks

NOTA: Otras distros quizá prefieran usar /usr/bin en lugar de /usr/local/bin para winetricks.

2) Instalando Evernote

Necesitaremos descargar Evernote para Windows desde este enlace si queremos la versión más reciente que esté disponible. Necesitaremos cambiar nuestro user agent con alguna extensión, para Google Chrome yo recomiendo usar ésta; En mis pruebas a partir de la 5.7.x he notado pequeños glitches (como stacks duplicados por ejemplo); Entonces yo de momento uso la 5.6.x que pueden descargar por acá. Es cosa de que hagan la prueba con la versión más reciente y si todo les funciona bien, la usen. Si no les recomiendo la 5.6.x que para mi ha sido más que estable y funcional (ojo: ésta versión antigua no tiene algunas funcionalidades como workchat por ejemplo). Una vez descargado Evernote, corremos en consola:

$ WINEPREFIX=$HOME/.wine-evernote/ winecfg

En este paso nos aseguramos que la versión a imitar en Wine sea Windows 7 y establecemos otras preferencias que nos parezcan apropiadas para nuestro WINEPREFIX:


Aplicamos los cambios y luego corremos:

$ WINEPREFIX=$HOME/.wine-evernote/ winetricks corefonts
$ wget http://files.polosatus.ru/winefontssmoothing_en.sh
$ chmod +x winefontssmoothing_en.sh
$ WINEPREFIX=$HOME/.wine-evernote/ sh winefontssmoothing_en.sh

Aplicamos la configuración de suavizado de fuentes RGB:


Y finalmente corremos:

$ WINEPREFIX=$HOME/.wine-evernote/ wine ruta/instalador/evernote.exe

Seguimos las instrucciones de instalación habituales y listo:


3) Tweaks finales

Abrimos Evernote y accedemos con la cuenta que nos creamos previamente:


Ya como Tweaks extra, establecemos nuestras preferencias personales en las pestañas del menú de Herramientas>Opciones y finalmente disfrutamos de Evernote:


Eso sería todo, Evernote Oficial instalado en GNU/Linux sin mayores complicaciones. Cabe destacar que usando este método nuestro evernote es compatible con las actualizaciones habituales de la aplicación y prácticamente todas las funcionalidades en ella.

Extras

10+ usos para Evernote & Cuentas Premium GRATIS para todos

Cómo instalar Lightworks video editor en Fedora Linux


Yo, (como muchos) he usado Kdenlive como el editor de video por excelencia en GNU/Linux desde que tengo memoria. El problema es que a cada rato tiene uno u otro problema con MLT en mi distribución (Fedora) y por ésto me es imposible usarlo de manera continua.

La verdad es que la situación actual de la edición de video en Linux es deplorable. Las librerías para encode/decode no tienen un estándar (ffmpeg, mencoder, melt) y por lo tanto la manera programática de hacer las cosas cambia aceleradamente, dejando poco tiempo a los creadores de los editores de video para adaptarse a los rápidos cambios de las mismas (dejándonos a nosotros, los usuarios con software "paralítico"); Esto lo digo en base a mi última experiencia con los editores de video en Linux:

Kdenlive: No renderiza/procesa el proyecto (bug reportado acá) y parece que los devs sólo están esperando a que mágicamente melt se arregle por sí solo en las distribuciones con una nueva versión.

OpenShot: La calidad de lo procesado es pésima si se quiere hacer algo para youtube/web y las opciones avanzadas no parecen hacer mucho al respecto. Por otro lado, el renderizado tiene otros errores extraños como audio que no se escucha con auriculares y la interfaz deja mucho que desear, no es posible trabajar cómodamente con clips largos (¡no se les encuentra el final!).

Pitivi: Se traba y cierra al trabajar, no es confiable.

No me hagan hablar de Lives (que ni siquiera es usable) o de Flowblade que no pudo renderizar a otra cosa que no fuera .mpg en mis pruebas.

Conoce a Lightworks


Finalmente tenemos a Lightworks, una herramienta profesional de pago (modelo freemium pero curiosamente el editor es opensource) que al igual que las demás, deja mucho que desear en varios apartados, pero por lo menos lo intenta y cumple de cierta manera, integrando en el proceso varias features profesionales que el usuario de a pie agradecerá. Lightworks es un software extraño y al usarlo se siente claramente como algo en estado alpha ya que hacen un "bundle" de todas las utilidades (códecs y demás) en estado frozen para tener más control sobre el entorno. Esto obviamente lleva a que en lightworks no puedas importar cualquier tipo de formato (en mi experiencia sólo acepta codificación libx264/libx264rgb con pixel format yuv420p y un framerate predefinido sin importar el contenedor hablando de vídeo y audios mp3/mp4 cuando hablamos de sonido); conllevando también la limitante de que para poder exportar tus proyectos a otros formatos que NO sean Youtube 720p (MP4/H264) tengas que comprar la versión PRO. Esto último no sería una grosería de no ser porque la calidad que ofrece el único formato de exportación gratuito no es la mejor allá afuera y así grabes en FullHD (un screencast por ejemplo) originalmente recibirás algo de menor calidad al finalizar tu renderizado, no importando a qué lo puedas convertir después con ffmpeg/mencoder porque "el daño ya está hecho".

Instalar Lightworks en Fedora

Como ya expliqué, lightworks no será la octava maravilla del mundo pero al menos renderiza, sus resultados son aceptables aunque no óptimos (en la versión gratuita) y no se anda cerrando y/o cayendo a cada rato. Si quieres instalar Ligthworks en tu Fedora Linux esto es lo que has de hacer:

1) Añadir repositorios RPMFusion

# dnf install --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm && dnf -y update

2) Instalar códecs y utilidades

# dnf -y install gstreamer1-libav gstreamer1-plugins-bad-free-extras gstreamer1-plugins-bad-freeworld gstreamer1-plugins-good-extras gstreamer1-plugins-ugly gstreamer-ffmpeg xine-lib-extras xine-lib-extras-freeworld k3b-extras-freeworld gstreamer-plugins-bad gstreamer-plugins-bad-free-extras gstreamer-plugins-bad-nonfree gstreamer-plugins-ugly gstreamer-ffmpeg mencoder

# dnf -y install mediainfo vlc audacity-freeworld soundconverter

3) Descargar e instalar Lightworks

Descargar Ahora
dnf -y install ruta/rpm/lightworks

4) Crearte una cuenta

Crear cuenta ahora

Verificamos nuestra cuenta por e-mail como nos indican y proseguimos.

5) Configurar Lightworks

Abrimos Lightworks desde nuestro menú de aplicaciones, regresamos a la terminal (con Alt+Tab si fuese necesario), cerramos lightworks (lléndonos a la parte superior derecha de la "ventana" que aparecerá al abrirlo con el mouse y dando un click al tener un pointer) para después correr:

$ nano ~/Lightworks/UserSettings.txt

En el archivo que se nos abrirá, buscamos y modificamos las siguientes variables en el bloque de [EditorPreferences] para que nos queden así:

Lightworks window maximised=false
Lightworks window titlebar=1


Una vez hecho esto abrimos Lightworks desde nuestro menú de aplicaciones de nuevo y si se nos glitchea como en esta captura:


Simplemente arrastramos la ventana desde su barra de título forzándola a que se "redibuje", haciendo que lightworks abra como debe. En el caso de una nueva instalación se nos pedirá hacer login (una única vez) con los datos de la cuenta que registramos y después ya podremos utilizar el editor como es debido:


Lightworks es un editor de vídeo profesional donde se han editado películas como Pulp Fiction, King's Speech, Hugo y varias otras más, ¡incluso ha ganado premios! En mi opinión es lo más cercano a un Kdenlive estable (y usable) que encontrarás en GNU/Linux, tiene bastantes features muy poderosas, incluso un editor de sonido profesional built-in, efectos profesionales y muchísimas cosas más... Aunque aún le hace falta trabajar muchísimos detalles vale la pena echarle un ojo.

Para conocer más sobre Lightworks, visita su web oficial.

Cómo añadir los repositorios de RussianFedora a tu sistema


Para los que no lo sepan, la comunidad de Fedora Rusia tiene un repositorio propio parecido a RPMFusion donde hay un montón de software extra bastante útil (Chromium, Skype, Opera, paquetes para mejorar el renderizado de fuentes en Fedora, firmware, temas y un largo etcétera); Para conocer qué paquetes tienen basta con revisar su repositorio en Github:

https://github.com/RussianFedora

Y si quieren añadirlo a sus sistemas fedora basta con ejecutar:

# dnf install --nogpgcheck http://mirror.yandex.ru/fedora/russianfedora/russianfedora/free/fedora/russianfedora-free-release-stable.noarch.rpm http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/russianfedora-nonfree-release-stable.noarch.rpm http://mirror.yandex.ru/fedora/russianfedora/russianfedora/fixes/fedora/russianfedora-fixes-release-stable.noarch.rpm && dnf -y update

Más información: http://ru.fedoracommunity.org/

Mejorar el renderizado de tipografías en Fedora Linux


So, tengo este amigo de Internet, +Jamin Fernandez que se la pasa quejándose del renderizado de fuentes en Fedora Linux... Hoy finalmente encontré una manera de hacer que el renderizado de fuentes en Fedora sea por demás bello (¡y lo digo yo que casi no me fijo en esas cosas dentro del S.O.!) así que voy  a compartir el procedimiento acá para los que les interese.

NOTA: Si hiciste algún cambio manual a tu configuración de fuentes (archivo ~/.fonts.conf, o los que están en /etc/fonts); deshazlo y usa únicamente este procedimiento.

1) Añadir repositorios RPMFusion

# dnf install --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm && dnf -y update

2) Añadir repositorios RussianFedora

# dnf install --nogpgcheck http://mirror.yandex.ru/fedora/russianfedora/russianfedora/free/fedora/russianfedora-free-release-stable.noarch.rpm http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/russianfedora-nonfree-release-stable.noarch.rpm http://mirror.yandex.ru/fedora/russianfedora/russianfedora/fixes/fedora/russianfedora-fixes-release-stable.noarch.rpm && dnf -y update

3) Instalar utilidades

# dnf -y install gnome-tweak-tool freetype-freeworld fontconfig-infinality

4) Suavizado

Abrimos nuestra Gnome Tweak Tool y nos vamos al área de Tipografías (en otros escritorios debe haber alguna herramienta similar) para seleccionar full hinting, alisado RGBA y 1.00 como factor de escalado:


5) Antes y Después

Cerramos nuestra sesión y la volvemos a abrir. Noten esta imagen del ANTES (a pesar de que en general todo el renderizado de fuentes a nivel sistema mejoró, los elementos marcados con rojo en esta captura son aquellos que considero tuvieron una mejora bastante más notable en el después):


Ahora, tengan en cuenta los elementos marcados con rojo arriba y compárenlos con sus contrapartes en el DESPUÉS:


Sobra decir que la mejora es por demás notoria. Elementos como el texto del código en Gedit o los menús de la terminal definitivamente son "más nítidos" pero a mi parecer la mayor ganancia la tuvimos en Google Chrome y los elementos de las interfaces del sistema (menú de Gnome shell, textos de la ventana de Gedit, etc.); So... ¿Qué les parece?

Extra: Wine Apps

#QuickTip: Bellas apps Wine bajo GNU/Linux

Cómo montar un entorno aislado usando SELinux Sandbox


En algunas ocasiones (investigaciones de informática forense por ejemplo) necesitarás tener a la mano un entorno sandbox aislado para poder ver cómo se comportan ciertas aplicaciones/scripts y/o procesos sospechosos. Una máquina virtual y/o linux container pueden parecer útiles en estos casos (y muchas veces lo son) pero... ¿No sería mejor si pudiéramos tener un asistente que nos mostrara los comportamientos inesperados de las aplicaciones aisladas según se presenten? Si bien existen alternativas para tener un entorno sandbox funcional en Linux (como Glimpse según nos comentan los chicos de +Usemos Linux) Esto del sandboxing se puede lograr mediante SELinux también en sistemas que lo tengan disponible (Fedora, CentOS, RHEL y/o derivadas); sin necesidad de instalar ningún software adicional (más que paquetes propios de SELinux) en nuestros sistemas.

Relevante:
TUTORIAL: ¿Cómo c*rajo se usa SELinux?


NOTA: En este tutorial me basaré en Fedora Linux como distro de referencia, cambiar los comandos de instalación por los pertinentes según sea el caso.

Nos aseguramos de que SELinux esté activado en nuestro sistema con el comando getenforce (que nos debería regresar Enforcing); y después proseguimos...

1) Instalando utilidades

# dnf -y install selinux-policy-sandbox policycoreutils-sandbox xterm firefox

2) Creando árbol de directorios

Luego crearemos la estructura de directorios necesaria para nuestro sandbox con el siguiente comando:

$ mkdir -p ~/sandbox/home && mkdir -p ~/sandbox/tmp

3) Inicializando el sandbox


Limpiamos todas las alertas en el Asistente de alertas de SELinux (como se ve en la imagen de arriba) y después corremos:

$ cd ~/sandbox
$ sandbox -X -W gnome-session-classic -w 1024x768 -H home -T tmp -t sandbox_web_t xterm

Las cosas como siguen:

  • -X: Especifica que queremos un sandbox con capacidades de display gráfico.
  • -W: Establece el gestor de ventanas a usar
  • -w: Establece el tamaño de la ventana del sandbox 
  • -H: Establece el directorio home a usar para el sandbox
  • -T: Establece el directorio tmp a usar para el sandbox
  • -t: Establece el tipo de sandbox a usar
  • xterm: es el comando a lanzar

Para conocer más acerca del uso del comando sandbox, usa el comando:

$ man sandbox

3.1) Explicación

La razón por la que inicializo mi sandbox así es por que por medio de xterm puedo lanzar otros programas, y gracias a la sesión clásica de gnome (usa mutter en el backend me parece) puedo manipular las ventanas hasta cierto punto. Uso el tipo de sandbox sandbox_web_t para poder usar firefox y otros programas que naveguen la web, pero hasta ahí. El resto de acceso a Internet está prohibido.

Según sea el caso puedo inicializar el sandbox de un modo u otro, pero este es mi favorito porque me permite tener lo más cercano a una máquina virtual dentro de un contexto aislado que está siendo constantemente monitoreado por SELinux. De esta manera puedo revisar código malicioso, ejecutarlo e investigar en internet sobre él sin problemas.

4) Configurar Sandbox


Tras inicializar tu sandbox de esta manera no pasará nada, pero empezarán a saltar alertas en el asistente de alertas de SELinux, mismo que deberás monitorear para saber qué debes permitir de manera que puedas lanzar un sandbox lo más limitado (pero útil) posible, tal y como veremos a continuación:


En este caso la primera alerta se refiere al display gráfico que usan los sandboxes (Xephyr), así que tenemos que permitirle realizar su trabajo con:

# grep Xephyr /var/log/audit/audit.log | audit2allow -M xephyr
# semodule -i xephyr.pp

Nótese cómo hice exactamente lo mismo que el asistente de alertas me recomendó, sólo cambié el nombre de la póliza para diferenciarla de otras que vamos a habilitar más adelante.

Si volvemos a tratar de inicializar nuestro sandbox con el comando:

$ sandbox -X -W gnome-session-classic -w 1024x768 -H home -T tmp -t sandbox_web_t xterm

veremos que esta vez sí arranca:


Aquí yo tengo ZSH configurado so xterm me está pidiendo un curso de acción para la nueva inicialización, elijo 0 y tengo un entorno de terminal funcional desde donde puedo ahora correr el comando:

$ nohup firefox >/dev/null 2>&1&

Lo que me lanzará una ventana de firefox, en la que (sin importar los errores de conexión), debo abrir 2 páginas, una http y una https respectivamente, por ejemplo:



Esto hará saltar alertas de SELinux porque firefox intentó conectarse a la web por medio de HTTP y HTTPS respectivamente y ahora tenemos la información necesaria para permitirle dicho comportamiento dentro de un sandbox  (si no, ¿qué utilidad tiene?):


Ese número que ven ahí es el "nombre" de firefox para SELinux, no me pregunten porqué... Tengo 1 alerta para el puerto 80 (HTTP) y una para el 443 (HTTPS); so ahora puedo hacer:

# grep 536F636B657420546872656164 /var/log/audit/audit.log | audit2allow -M firefox
# semodule -i firefox.pp

NOTA: Esta política sólo el permitirá el acceso a la web a firefox y a ningún otro programa en el sandbox.

Y entonces Firefox:


Es muy importante el no añadir excepciones y/o generar políticas para aplicaciones y/o procesos que no son absolutamente necesarios o que no sabemos con certeza porqué lo están pidiendo, de otra manera el sandboxing pierde sentido.

5) Utilizando el Sandbox

Al momento de realizar una investigación, el Asistente de alertas de SELinux será nuestro mejor amigo explicándonos paso a paso las cosas sospechosas que suceden dentro del sandbox diseccionando un@ por un@ cada petición o movimiento que hagan los procesos y/o aplicaciones, impidiendo incluso varios comportamientos por defecto permitidos (como ya vimos en el caso de firefox y el acceso a la web) ya que el entorno está sumamente controlado:


Si quisiera utilizar/analizar archivos sospechosos sin poner en riesgo mi equipo enterándome a cada paso de lo que hacen al ejecutarlos o algo similar, simplemente los copio a la carpeta home de mi sandbox y si lanzo nautilus (por ejemplo) con:

$ nohup nautilus >/dev/null 2>&1&

Los podré ver ahí:


Listo, con esto concluimos el tutorial de SELinux Sandbox. Espero les haya resultado útil y si es así, ahí arriba (Justo debajo del título del post) hay un botón de ChangeTip para que nos envíen una propina Bitcoin ;) Muchas gracias por leernos.

TUTORIAL: ¿Cómo c*rajo se usa SELinux?



NOTA: El título se debe a que comúnmente cuando una persona cambia de una distribución que no usa un MAC (o al menos no uno tan "involucrado" como SELinux) a una que sí lo hace, generalmente de primera instancia se empieza a "dar de topes" tratando de saber porqué X o Y no funcionan en su setup habitual, para al final desactivar SELinux y ver que ése era el problema desde un inicio. Dicho título es entonces una alusión a lo incomprendida que está esta herramienta de seguridad por aquellos que no están acostumbrados a usarla.

So... Todos los que usamos Fedora, CentOS, RHEL y/o derivados, conocemos a SELinuxSecurity-Enhanced Linux, que básicamente se trata de un módulo de seguridad para el Kernel mismo que trabaja por medio de pólizas. En términos sencillos, SELinux es un programa similar a un híbrido de antivirus/firewall y protege al sistema de comportamientos inesperados por medio de una implementación MAC (Mandatory Access Control); Piensa algo así como la ventana esta molesta de Windows (¿user account control creo que se llama su implementación?):


Pero de hecho útil, poco molesto, programable y con muchísimas más funcionalidades añadidas. Cabe destacar que no voy a hablar de SELinux a fondo aquí (¡Lo creó la NSA! y sus políticas de seguridad son avaladas y aprobadas por el departamento de defensa de EEUU, so se trata de un software revisado a fondo que se usa día a día en equipos de misión crítica); solo haré un pequeño tutorial de cómo manejarlo a nivel básico en tus equipos y/o servidores.


Hasta ahora ya entendimos que básicamente SELinux impide que un programa/proceso se comporte de manera "extraña" (haga cosas que se consideran potencialmente inseguras o que comúnmente no debería de hacer) tal y como se muestra en la imagen de arriba: Sin un MAC presente, el perro podría fácilmente comerse la comida del gato sin problemas y aunque esto no se considera un escenario "inseguro" per sé (debido a que las probabilidades de que dicha comida le haga daño son mínimas); esto no es algo que debería estar pasando en primer lugar... El perro tiene su propia comida disponible:


Imágenes del SELinux coloring book

Entonces bien, cada que pasa algo que "no se supone debería pasar" recibimos una alerta de SELinux que notaremos en las notificaciones del sistema (identificándola con el ícono distintivo de la herramienta) estas alertas, ya cuando las abrimos se ven así:


En el caso de la alerta de arriba, el problema está en que tengo configurado NGINX para servir una aplicación que está escuchando en el puerto 3000, pero NGINX no tiene permiso por defecto para ver lo que está sucediendo en ese puerto con el fin de llevar a cabo su trabajo tal y como yo se lo indiqué. Esto resulta en lo siguiente cuando alguien visita dicha aplicación:


Si expandimos la alerta, El asistente de alertas de SELinux nos mostrará las posibles soluciones, (una temporal y una permanente):


En este caso la que nos importa es la permanente (la de abajo) y si hacemos lo que nos indica:

# grep nginx /var/log/audit/audit.log | audit2allow -M nginx
# semodule -i nginx.pp

Nótese cómo cambié mypol por nginx en el comando recomendado, así es como debes permitir nuevas políticas, con un nombre distintivo para cada excepción.

Veremos que pasa lo siguiente en nuestra consola:


Y más tarde, ya podremos visitar la aplicación deseada normalmente:


Para los que estén trabajando en un servidor/equipo sin GUI, generar un reporte legible de las alertas se hace con el siguiente comando:

# echo "Time: $(date)" >> /var/log/selinux-alerts.log && sealert -a /var/log/audit/audit.log > /var/log/selinux-alerts.log

Después podemos leer dicho archivo en la CLI con:

# cat /var/log/selinux-alerts.log

Ahora bien, si queremos listar las políticas que tenemos activas actualmente en el sistema (llamémosles excepciones), podemos correr:

# semodule -l

para saber si tenemos una política y/o excepción específica habilitada, usamos:

# semodule -l | grep mypol

Cambiando mypol por el nombre de la política/excepción que estemos buscando.

Para desactivar/eliminar estas excepciones/políticas, corremos:

# semodule -r mypol nginx

Reemplazando nginx y mypol por los nombres de las excepciones y/o políticas que queramos deshabilitar respectivamente.

Otro caso interesante sería si quisiéramos permitir el acceso a un puerto no predeterminado en nuestro sistema (conexiones SSH entrantes a otro puerto que no sea el 22 por ejemplo), esto en el caso de SSH (después de abrir el puerto deseado en el firewall previamente) lo haríamos así:

# semanage port -a -t ssh_port_t -p tcp puerto

Reemplazando puerto por el número de puerto deseado.

Para conocer la lista de puertos permitidos (y los nombres adecuados para modificarlos) ejecutamos:

# semanage port -l

Y pues bueno, eso es todo... Así es como se usa SELinux a nivel básico. Ya no tienen porqué desactivarlo o ponerlo en modo permisivo cuando les cause problemas, simplemente era cosa de entenderlo.

Extra: SELinux Sandbox

Cómo montar un entorno aislado usando SELinux Sandbox

P.D. Si quieren conocer más a fondo SELinux y cómo utilizarlo (¡es todo un estuche de monerías!) les recomiendo el libro The SELinux Notebook que nos mencionan en la wiki del proyecto.