Instalar Phonegap en Ubuntu 14.04 y derivados


1) Dependencias

sudo apt-get install build-essential nodejs nodejs-legacy npm ant python-software-properties python g++ make openjdk-7-jdk openjdk-7-jre icedtea-7-plugin

2) Phonegap

sudo npm install -g phonegap

3) SDK's y Paths

Suponiendo que vayas a desarrollar por ejemplo para Android, necesitarás descargar el SDK y las herramientas de desarrollo para tu plataforma (en este caso Linux de 32 y/o 64 bits según corresponda) añadiendo al PATH del sistema su ruta con la siguiente línea dentro de tu .bashrc o .zshrc:

export PATH=${PATH}:/ruta/a/adt-bundle/sdk/platform-tools:/ruta/a/adt-bundle/sdk/tools/

Nótense los : entre las rutas. Después cerramos y abrimos la terminal para hacer válidos los cambios en el PATH y proseguimos.

Finalmente...

Hacemos un proyecto de ejemplo para asegurarnos que todo funciona con:

phonegap create my-app
cd my-app
phonegap run android

...teniendo en cuenta que el último comando nos podría devolver un error parecido a este:


Sin embargo, la solución nos la da el mismo output. Lo que está sucediendo aquí es que Phonegap trabaja con el API estable y actualmente digamos... "comercializada de manera oficial" de Android, pero ésta no siempre es la última disponible (pues por ejemplo al momento que escribo esto la versión más nueva comercial de este S.O. móvil es KitKat, mientras que Android L es la más nueva realmente y tiene relativamente poco de ser lanzada, prácticamente ningún terminal "insignia" la tiene aún, mientras que varios otros están dando apenas el salto a KitKat). Entonces en pocas palabras para quitarnos de encima este error necesitaremos ejecutar el comando:

android

como nos explica el output anterior y ésto nos devolverá la siguiente ventana (a.k.a. Android SDK Manager):


Donde hemos de clickear "Deselect All" para desmarcar las actualizaciones de la versión más reciente no soportada/comercializada y acto seguido deberemos contraer todo (ordenando por API Level) para marcar el árbol del número de versión que phonegap nos pidió anteriormente (en mi caso la versión 19 al momento que escribo ésto):


Aceptamos las licencias, descargamos los paquetes y una vez finalizado el proceso ya podremos cerrar el Android SDK Manager para volver a la consola y crearnos un emulador donde correr nuestra Phonegap App con:

android create avd --name phonegapEMU --target android-19 --abi default/armeabi-v7a

(Recuerda que el target debe ser la versión de android que acabas de descargar, misma que es la compatible con Phonegap) y más adelante podremos ejecutar:

phonegap run android

para ver nuestra app de ejemplo en acción:


Claro que hay varias cosas que puedes cambiar en tu emulador/app etc. Pero todo eso va más allá del propósito de este tutorial.

Cómo instalar Hearthstone en Linux



Hearthstone es un adictivo juego para PC creado por Blizzard (los creadores de World of Warcraft y StarCraft) que además es gratuito y fácil de instalar en Linux. Veamos cómo hacerlo:

NOTA: Para este tutorial usaré como distro referencia a Ubuntu 14.04 (y derivados) pero las mismas instrucciones deben servir para cualquier otra distro mientras instales las dependencias necesarias. Recuerda que de preferencia has de tener una tarjeta NVIDIA o ATI con los drivers privativos correspondientes instalados previamente en tu equipo.

1) Wine de 32 bits y PlayOnLinux

Es importante instalar Wine de 32 Bits (aunque tengamos sistema de 64) y PlayOnLinux. Para esto corremos en consola:

1. sudo apt-get install wine1.7 wine:i386 (el último sólo en 64 bits)
2. wget -q "http://deb.playonlinux.com/public.gpg" -O- | sudo apt-key add -
3. sudo wget http://deb.playonlinux.com/playonlinux_trusty.list -O /etc/apt/sources.list.d/playonlinux.list
4. sudo apt-get update
5. sudo apt-get install playonlinux

2) Instalando Hearthstone

Y una vez instalado PlayOnLinux simplemente buscamos Hearthstone en su lista de programas para instalar:


Le damos a instalar y seguimos las instrucciones/recomendaciones del asistente que se abrirá... Recuerden activar las actualizaciones automáticas de Flash Player cuando se los pidan.

3) ¡A jugar!

Crean su cuenta de Battle.net y después ya podrán jugar Hearthstone sin problemas en su sistema GNU/Linux (abriéndolo directamente desde PlayOnLinux):


Cómo instalar NodeJS en Ubuntu 14.04 y derivados


Esto es tan fácil como correr en consola:

sudo apt-get install nodejs nodejs-legacy npm

y listo... Hago post porque si sólo se instala uno de estos paquetes se pueden llegar a tener varios errores que pueden llegar a confundir a más de uno, provocando que incluso algunos usen PPA's poco confiables. Esta es la manera más efectiva de hacerlo.

Cómo instalar Java en Ubuntu 14.04 y derivados


Esto es muy fácil, basta con correr en consola:

sudo apt-get install openjdk-7-jdk openjdk-7-jre icedtea-7-plugin

y listo... Hago post porque en versiones anteriores se instalaba de jalón junto con los restricted-extras (en su versión privativa de Sun/Oracle) pero ahora ya no es así y ¡qué mejor! pues ahora podemos usar la versión libre, más actualizada y binariamente compatible OpenJDK directamente.

Cómo instalar OS X en Virtualbox


Introducción

Suponiendo que tengas que usar un entorno OS X virtualizado para trabajar (por cuestiones de desarrollo de software por ejemplo) siempre puedes optar por usar Virtualbox, el famoso software de virtualización de Oracle. Cabe destacar que aunque este tutorial funciona en prácticamente cualquier computadora que cumpla con ciertas características, legalmente sólo puedes correr máquinas virtuales OS X en hardware Apple que ya esté corriendo como host O.S. la versión del sistema operativo que quieras virtualizar en algún momento dado, y en dicho caso sólo podrás crear hasta 2 máquinas virtuales usando una misma Copia/ISO de OS X (obtenida por alguno de los canales que ellos mismos proveen para ello) como bien lo dicta la licencia:


Cualquier otro escenario (como virtualizar OS X en una computadora con algún host O.S. como Linux y/o Windows) podrá recaer en un incumplimento de la licencia de Apple, mismo que podría terminar en ellos no haciéndose responsables de cualquier mal funcionamiento del software y/o bien contigo cayendo responsable de algún cargo legal (y es aquí porqué siempre has de desmarcar "Enviar datos de uso" en todos lados si ése es tu caso jajajaja)... Dejando los malos chistes a un lado, quedan avisados.

Ahora bien, debido a esta cuestión de la licencia, VirtualBox no puede ofrecer soporte completo real a OS X, así que no esperes que todo funcione de maravilla o que vayas a tener las VirtualBox guest additions disponibles (aunque como veremos más adelante se pueden suplir y el entorno es hasta eso fluido y útil incluso bajo las condiciones mínimas) pero es importante tener esto en cuenta también. Una vez aclarado lo que necesitaba explicación, comencemos:

1) ¿Qué necesitamos?

Un equipo host Mac y/o (bajo tu propio riesgo), una PC con un procesador Intel compatible con la tecnología de virtualización directa VT-x, una tarjeta de video con al menos 256MB en VRAM disponibles, capacidad para delegar al menos 2GB de RAM a la máquina virtual y de preferencia un setup de hardware lo más parecido a una Mac (aunque lo único obligatorio es la parte del procesador y la tarjeta de video). También necesitaremos una imagen ISO pura (para instalación) de OS X en la versión que lo queramos. Dicha imagen se obtiene gratuitamente usando tu equipo Mac como se describe acá (ahí en el mismo hilo viene el troubleshooting para hacerlo booteable en caso de que nuestra VM no arranque desde éste) y por si se lo preguntaban los ISO's "mod" para Hackintosh también funcionan, sin embargo lo ideal es NO piratear software ya que de por sí es compleja la situación legal de OS X en máquinas virtuales y además varios de esos ISO's pueden contener malware escondido (como keyloggers/troyanos y otros). De cualquier manera, necesitarás también la última versión de Virtualbox instalada en tu sistema operativo host con todo y su extension pack previamente habilitado.

Nos aseguramos de que la tecnología de virtualización de nuestro procesador esté habilitada en la BIOS del equipo host y proseguimos.

2) Settings en Virtualbox


Creamos una nueva máquina virtual de Mac OS X (64 bits) sin especificar la versión, le damos un rango de 2GB a 8GB en RAM y un disco duro de mínimo 60GB en formato VMDK reservado dinámicamente.

Tras hacer esto, nos vamos a Configuración (tras seleccionar nuestra nueva máquina virtual en la lista de Virtualbox) y en la parte de Sistema>Placa base deshabilitamos disquette, red, y EFI:


Acto seguido, en la pestaña de Procesador le damos a la máquina virtual la mitad del total de núcleos de nuestro procesador en el equipo host con un límite de ejecución del 100% y PAE/NX habilitado (por ejemplo en el caso de un equipo host con procesador Dual-Core a la máquina virtual sólo se le debería permitir el uso de 1 sólo núcleo al 100%):


En la pestaña de Aceleración, deshabilitamos la paginación anidada y habilitamos VT-x/AMD-v:


Más adelante, en el apartado de Pantalla>Video le daremos a nuestra máquina virtual 128MB de VRAM para uso deshabilitando la aceleración 3D y 2D:


Después, en el apartado de Almacenamiento seleccionaremos como unidad óptica nuestro ISO de OS X:


3) Instalación

Guardamos los cambios e iniciamos nuestra máquina virtual... Seguimos las instrucciones del instalador de OS X y al llegar a la parte de la selección de disco destino para la instalación, veremos que nuestro disco duro de Virtualbox no es reconocido. Nos vamos entonces a Utilidades>Utilidad de discos, seleccionamos nuestro disco incompatible y nos vamos a la pestaña de Borrar, seleccionando Mac OS Plus (con registro) como formato y dándole un nombre descriprivo:



Cerramos la utilidad de discos y volvemos al instalador, donde ya podremos seleccionar el disco duro previamente "inexistente":


Tras finalizar el proceso de instalación, rellenamos los datos requeridos en el asistente de primera configuración. Recomiendo no bloquear la pantalla del sistema virtual con una contraseña (aunque sí deberán elegir una para su usuario) con el fin de acelerar el proceso de booteo.

3.1) Guest additions

Como dije, no existe tal cosa como las guest additions para OS X oficialmente. Sin embargo podemos reemplazarlas de la siguiente manera:

Pantalla completa

Cambien la máquina a modo ajustado con Ctrl derecho + C y apáguenla. Luego, corran el siguiente comando (en la consola de su sistema host):

VBoxManage setextradata "OS X (VM)" "CustomVideoMode1" "1920x1080x32"

Reemplazando OS X (VM) por el nombre de su máquina virtual (dejando las comillas) y 1920x1080 por el tamaño/resolución de su pantalla. La tasa de refresco se ha de quedar siempre en los 32 Hz. Apaguen la máquina virtual, cierren Virtualbox y a continuación vuelvan a abrir el programa para ejecutar la máquina virtual de nuevo; Ésta debería iniciar en el modo ajustado automáticamente, mismo que al maximizarlo debería tener la resolución total de su monitor como ventana.

Compartición de archivos

Para esto tendrán que hacer uso de alguna tecnología como Btsync, poniendo previamente en la configuración de su VM al adaptador de red en modo de "Adaptador Puente" para que se pueda comunicar con su equipo host vía LAN:


Dispositivos USB

Éstos son reconocidos de manera automática por la VM gracias al extension pack de Virtualbox. Sólo tienes que conectarlos al host antes de iniciar tu máquina virtual y añadirlos a los filtros en el apartado de USB dentro de la configuración.

4) Post-instalación

Tras terminar la instalación (y configuración básica) de OS X, es recomendable correr una reparación de permisos con el siguiente comando en terminal (también se puede gráficamente desde la utilidad de discos):

sudo diskutil repairPermissions /

Y hacer algunos tweaks para acelerar el sistema como quitar apps al inicio, reducir animaciones, desactivar el Dashboard etc. Una buena app para hacer varios de éstos cambios es TinkerTool junto con las preferencias del sistema. Si por alguna razón decidiste/tuviste que usar un ISO hackintosh en lugar del original para seguir este proceso no te olvides también de hacer un chequeo completo de tu sistema con alguna herramienta como Avast! antivirus para Mac antes de ingresar (por ejemplo) tus credenciales de Apple para la App Store o algo así.

4) Creando un snapshot

Ya que hayas terminado de mejorar tu instalación de OS X es recomendable reiniciar tu máquina virtual y crear un snapshot del estado fresco de la misma, antes de empezar a trabajar en ella y/o hacerle otras cosas. Esto se logra dentro del mismo Virtualbox presionando el botón de Instantáneas tras seleccionar la máquina virtual en la lista:


Como medida preventiva adicional, crea una copia de la imagen VMDK de la instalación fresca de la VM en algún lado que no sea utilizado por Virtualbox. De esta manera si la máquina se llegase a corromper, bien puedes usar esa imagen de disco limpia para arrancar la VM en otra instalación de Virtualbox y/o incluso en otro software de virtualización (como VMware Player) sin tener que repetir los pasos ya seguidos previamente.

Recomendaciones finales

Inicio rápido

Es una buena idea cerrar todas las apps en ejecución, cerrar la sesión de usuario después y guardar el estado actual de una máquina virtual al terminar de usarla en lugar de directamente apagarla y/o enviarle la señal de apagado ACPI, ya que esto hará que inicie más rápido cuando la necesitemos.

Actualizaciones del sistema

También recuerda que al tratarse de hardware virtual, lo más recomendable para actualizar el S.O. de tu VM es a través de las combo updates de Apple (reparando los permisos antes y después de aplicar alguna ya sea mayor o menor) en lugar de directamente desde la App Store para tener un mayor control de lo que sucede.

Cómo instalar League of Legends en Ubuntu 14.04 (y derivados)


Es sorprendente cómo han cambiado las cosas de un tiempo para acá cuando instalar juegos para Windows en Linux era todo un martirio con diferentes workarounds y similares. Hoy en día es bastante sencillo, gracias a la evolución sólida de cosas como PlayOnLinux.

NOTAS: Recuerda que debes tener una tarjeta de video dedicada NVIDIA o ATI con los controladores privativos instalados en el sistema previamente de preferencia. También recuerda registrarte para obtener una cuenta de LoL si no lo has hecho (el juego es gratuito).

1) Dependencias

Para empezar necesitamos instalar:

1. sudo apt-get install wine1.7 mesa-utils mono-complete
2. sudo apt-get install wine:i386 (Sólo 64 bits)

2) PlayOnLinux

Ahora necesitamos instalar PlayOnLinux, la herramienta por excelencia para instalar juegos y otros programas Windows en Linux:

1. wget -q "http://deb.playonlinux.com/public.gpg" -O- | sudo apt-key add -
2. sudo wget http://deb.playonlinux.com/playonlinux_trusty.list -O /etc/apt/sources.list.d/playonlinux.list
3. sudo apt-get update
4. sudo apt-get install playonlinux

3) ¡A instalar se ha dicho!

Ahora sólo necesitas buscar el juego en la lista de programas de PlayOnLinux y seguir las instrucciones de instalación adecuadas... Recuerda NO marcar la opción de ejecutar después de instalar al finalizar con tu instalación.


Seleccionamos Descargar el programa cuando se nos pregunte y a partir de aquí todo básicamente es un Next>Next>Next hasta tenerlo instalado... PlayOnLinux te mostrará algunas advertencias que deberás atender (como la de no marcar ejecutar tras instalar) y se encargará de instalar/obtener los archivos/programas y librerías/parches faltantes para una instalación exitosa del juego en tu sistema dentro de un entorno Wine isolado... La descarga del tarball inicial puede tardar bastante, en mi caso falló 1 vez y tuve que volver a iniciar el proceso (que empezó desde donde se quedó) pero sí fue un poco tardado... Una vez que terminamos con la parte de POL, el instalador normal se abrirá y deberemos seguir sus indicaciones, recordando las recomendaciones de PlayOnLinux:


4) Creando nuestra cuenta

Después de terminada la instalación, el updater del juego debería iniciar (es un proceso que tarda un poco) y veremos algo como esto:


En lo que esto hace su trabajo, crearemos nuestra cuenta dando click aquí y seleccionando la mejor región según nuestra ubicación o dónde jueguen nuestros amigos. Siéntete libre de cambiar tu región de manera acorde en el updater según la hayas seleccionado en tu registro.

5) ¡A jugar!

Tras descargados y aplicados los parches adecuados, podrás presionar el botón de Play para empezar a jugar:


Introduce tus datos de login y listo! ya tendrás League of Legends instalado en tu sistema Ubuntu Linux:


Notas Finales...

A veces el lanzador del juego no inicia el juego a la primera ejecución, por lo que deberás lanzarlo de nuevo y Wine te mostrará una advertencia de error que deberás aceptar para que el juego inicie:


Desterrrado de GNOME Shell... Mi triste historia u.u


Me gusta mi computadora principal. No es la gran cosa, una HP Pavilion Slimline s5120la con algunas modificaciones y (claro cómo no) Fedora Linux instalado. A lo largo de su vida le he hecho diferentes modificaciones según he necesitado: Mayormente a nivel Software, poco a poco con el paso de los años me ha tocado meterle mano al hardware también. Empecé con una nueva PSU y una nueva tarjeta gráfica. Compré también (aún no llega pero está en camino) un nuevo procesador compatible, el "tope de gama" que la motherboard acepta. Un SSD para mi partición raíz también es prioridad y pienso adquirirlo en la misma tienda que el procesador si todo resulta bien con el primer envío.

¿El problema? La RAM.

La computadora trae por defecto 4GB de RAM, de los cuales (tras reemplazar la gráfica integrada de fábrica por la dedicada que le puse) el sistema tiene acceso a un total de 3.9 (antes del cambio eran 3.4 aprox). Obviamente conforme avanza la tecnología los entornos de escritorio y los programas van necesitando más y más recursos, siendo la RAM el más solicitado. Mi plan era (tras revisar mis consumos actuales de RAM) hacer el upgrade a 8GB cuando de pronto me di cuenta de algo espantoso: La motherboard no admite más de 4GB de RAM aún con un sistema de 64 Bits instalado. Esto es un problema porque para el uso cotidiano que le doy a GNOME Shell 4GB se me van viendo cortos y además si compré el nuevo procesador es porque tengo intenciones de virtualizar sistemas pesados a 64 bits dentro de la misma máquina...

De querer hacer esto último, el usar GNOME Shell queda totalmente descartado del panorama puesto que en sí dicho escritorio en fedora 20 de 64 bits (la versión más actual al momento que escribo esto) consume de 600 a 700 MB (base) y conforme pasa el tiempo debido a procesos como el tracker (lo que permite que encuentres archivos y apps en un chasquido desde su dash) termina operando regularmente en algo bastante próximo a los 2GB con cargas de trabajo medias, dejando la posibilidad de virtualizar totalmente fuera de la ecuación.

Más allá de todo esto (pues si estudiamos mi problema con una mirada objetiva nada que no sea un gestor de ventanas simple me va a dejar virtualizar tranquilamente) Esta computadora ha caído víctima de la obsolencia programada y para "rescatarla" sin tener que volverla servidor y/o cambiar completamente la motherboard, de momento lo único que queda es migrar a un entorno de escritorio ligero y quedarse ahí, cosa que efectivamente hice migrando a XFCE:


Bien pude haber migrado a una distro más ligera (Antergos por ejemplo tiene un gnome-shell que presume de estar en el rango de los 200MB de RAM base) en lugar de seguir usando fedora pero de momento no tengo ni el tiempo ni las ganas de hacer dicha maniobra, ya que en ese caso mejor compro otro equipo o le actualizo la motherboard a este e instalo fedora con GNOME Shell en cualquiera de los casos, así que prefiero confiar en que XFCE se mantendrá ligero el suficiente tiempo como para dejarme usar esta computadora (que de verdad me agrada) sin batallar con los recursos. De momento en mis pruebas sí he notado un cambio en el consumo de recursos que es notable. A lo largo de los días XFCE se ha comportado bastante bien en cargas altas de trabajo y la gestión de recursos es bastante buena. Incluso pude virtualizar un ubuntu con 2GB de RAM asignados y cambiar entre el host y el guest sin mayor problema, mientras los recursos se consumían de manera periódica y no "de jalón" en la máquina virtual.

Lo que sí tengo que destacar es que hay una que otra cosa que me molesta de XFCE en fedora: Para empezar, aunque hice todo el proceso de instalación de mi iOS device como es debido, Thunar no lo monta y tampoco lo hace ningún gestor de archivos, a la fecha no sé porqué (pero sí se que algo tiene que ver con gvfs). Cosas tan simples como cambiar la foto del usuario para el login manager se vuelven algo complejo (al no tener GUI para ello como en otros escritorios o bien, como en otras distros con XFCE como Xubuntu 14.04) y a veces el equipo simplemente no apaga. Por otro lado, aunque tengo deshabilitado el "recordar la sesión" por alguna razón XFCE la recuerda a veces, (contrario a lo que yo he solicitado) abriendo los programas que tenía previamente abiertos al iniciar una nueva sesión en blanco. El sonido fue otro de los problemas que tuve que solucionar ya que a veces no sonaban las bocinas y a veces no sonaban los audífonos, pero deshabilitando el sonido HDMI por el análogo estándar fue todo lo que se necesitaba al final... Las apps predeterminadas del menú de aplicaciones funcionan todas, excepto la de navegador web, que no permite hacer un setting permanente al que esté usando en turno si éste no es Midori.

Fuera de estos glitches, XFCE es un buen entorno de escritorio (aunque en fedora esté demasiado "vanilla") y con un poco de personalización y paciencia se puede lograr tener un workflow muy eficiente, digno de cualquier otro escritorio (de eso no me cabe duda); Lo que sí me entristece un poco es que el XFCE 4.10 de fedora no esté a la altura de digamos, el de xubuntu en el apartado de funcionalidad (dejando del lado el aspecto gráfico que es lo que menos importa) cuando se trata del mismo escritorio. Eeeen fin, veremos lo que el destino nos depara de ahora en adelante usando XFCE y si éste, (en algún momento) se vuelve relevante como alternativa para la comunidad fedoriana de manera que "le echen más ganas" en mejorar la experiencia de usuario en futuras versiones.

¿Qué hacer después de instalar CentOS/RHEL 7.x?


Atención: ¿Quieres probar esta guía en CentOS 7.x x86_64 dentro de un servidor real? Haz click aquí y utiliza los cupones ALLSSD10 y/o DODROPLET al crear tu cuenta en DigitalOcean para conseguir $10 USD de regalo que te servirán para montar un VPS por hasta 2 meses completamente gratis (con costo de $5 USD/mo después si te lo decides quedar).

CentOS es el clon libre del famoso Red Hat Enterprise Linux, un excelente sistema operativo para servidores. Contrario a fedora, (una derivada de RHEL para uso general) CentOS es un sistema más enfocado al uso empresarial con pocos cambios bruscos de versión en versión y soporte por largos periodos de tiempo, además de un kernel especializado para uso en servidores.

En la versión 7.x RHEL (y por lo tanto CentOS) vienen cargados de interesantes novedades entre las que destacan el kernel 3.10.x de serie, XFS como sistema de archivos por defecto, el completo abandono a la arquitectura individual de los 32 bits, Docker, SystemD, MariaDB (en lugar de MySQL por defecto) GNOME 3.8, Firewalld y muchas otras cosas más que pueden resultar bastante interesantes para todos los que manejamos servidores físicos, VPS o de cualquier tipo.

¿Conviene actualizar a CentOS 7.x?

Esta pregunta es algo subjetiva y la respuesta es depende. Depende de varias cosas: ¿Te generará downtime? ¿Es VITAL para ti alguna de las nuevas características? ¿Tienes hardware de 32 bits? Responder a estas preguntas te permitirá darte una idea de si debes o no actualizar a la nueva versión.

Guía de post instalación

Si decidiste instalar CentOS 7.x en tu servidor aquí hay algunas cosas que te podría interesar hacer justo después:

NOTA: Estas instrucciones también son válidas para deployments de Red Hat Enterprise Linux 7.x

1) Instalar nano y wget

Personalmente me hallo más con éstos 2 que con vi y curl; Si también es tu caso, ejecuta:

1. su -
2. yum -y install nano wget

2) Repositorios Extra (Necesarios)

EPEL & Remi:

1. su -
2. wget http://dl.fedoraproject.org/pub/epel/beta/7/x86_64/epel-release-7-0.2.noarch.rpm
3. wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
4. sudo rpm -Uvh remi-release-7*.rpm epel-release-7*.rpm

ElRepo:

1. su -
2. rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
3. rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm

Habilitando Remi:

1. su -
2. nano /etc/yum.repos.d/remi.repo


3) Actualizar

Para actualizar todo tu sistema, corre:

su -c 'yum -y update'

4) Configurar Firewall

Primero necesitamos obtener la(s) zona(s) activas:

su -c 'firewall-cmd --get-active-zones'

Este comando nos devolverá el nombre de la(s) zona(s) activa(s) (ej. public) y las interfaces de red que están ligadas a ella(s) como podrían ser eth0, p16p1, wlan0 etc.

Es recomendable también listar los puertos y servicios permitidos en la(s) zona(s) activas para hacer personalizaciones, esto se hace con:

su -c 'firewall-cmd --zone=myzone --list-all'

Obviamente usando el nombre de la zona indicada en lugar de myzone.

Luego para abrir y cerrar puertos podemos usar:

1. su -c 'firewall-cmd --zone=public --add-port=xxxx/tcp'
2. su -c 'firewall-cmd --zone=public --remove-port=xxxx/udp'

Respectivamente, cambiando xxxx por el número de puerto deseado y especificando el protocolo (tcp/udp) según corresponda.

5) Tweaks para rendimiento

Habilitar Tuned:

1. su -
2. yum -y install tuned
3. tuned-adm profile selected_profile

Más información sobre los perfiles disponibles acá: http://red.ht/1ppyozF

Habilitar ZRAM:

1. su -
2. yum -y install bc
3. wget https://spideroak.com/share/PBSW433EMVZXS43UMVWXG/78656e6f6465/srv/CDN/xenodecdn/zram -O /etc/init.d/zram
4. chmod 755 /etc/init.d/zram
5. chkconfig --add zram && chkconfig zram on

Reiniciamos y luego podremos checar que zRAM está corriendo con:

su -c 'service zram status'

Puedes checar más tips para mejora de rendimiento en: http://bit.ly/1hoo5XR

Habilitar Ksplice:

Ksplice es un gestor de paquetes de seguridad del que ya hablamos anteriormente y básicamente permite instalar actualizaciones de seguridad en tu servidor sin necesidad de reiniciar. La versión para RHEL se puede probar por 30 días (con una acces key de trial) y luego se requiere pagar aprox 4 USD/mo por usar el producto (con hasta 20 servidores, a partir de 20 en adelante el costo reduce a 3 USD/mo).

1. su -
2. wget https://www.ksplice.com/yum/uptrack/centos/ksplice-uptrack.repo -O /etc/yum.repos.d/ksplice-uptrack.repo
3. sudo yum -y install uptrack ksplice-uptrack-release
4. nano /etc/uptrack/uptrack.conf

En el archivo del comando #4, requeriremos insertar nuestra clave de acceso como nos lo pide:


Configurar IP Virtual única:

Si esto te interesa, acá nuestro tutorial

SELinux Permisivo:

SELinux es una buena utilidad de seguridad para sistemas CentOS/RHEL, sin embargo su activación puede traer problemas al momento de implementar ciertas cosas en tu servidor. Es por esto que, (al menos en algunos CentOS 7.x de VPS) SELinux viene deshabilitado por defecto y en instalaciones normales viene activado. Personalmente prefiero "algo en medio" y suelo ponerlo en modo "permisivo" esto quiere decir que seguirá funcionando sin conflictuar con otras cosas y en lugar de proteger como tal únicamente nos mostrará advertencias relevantes para que nosotros nos encarguemos de la situación. Poner entonces a SELinux en modo permisivo se hace con:

1. su -
2. nano /etc/selinux/config

Y en el archivo que abrirá cambiamos el status de disabled y/o enforcing a permissive. Guardamos los cambios, reiniciamos y listo.

¿Qué hacer después de instalar CentOS/RHEL 6.x?


Atención: ¿Quieres probar esta guía en CentOS 6.x dentro de un servidor real? Haz click aquí y utiliza los cupones ALLSSD10 y/o DODROPLET al crear tu cuenta en DigitalOcean para conseguir $10 USD de regalo que te servirán para montar un VPS por hasta 2 meses completamente gratis (con costo de $5 USD/mo después si te lo decides quedar).

CentOS 6.5 es el clon libre del famoso Red Hat Enterprise Linux, un excelente sistema operativo para servidores. Contrario a fedora, (una derivada de RHEL para uso general) CentOS es un sistema más enfocado al uso empresarial con pocos cambios bruscos de versión en versión y soporte por largos periodos de tiempo, además de un kernel especializado para uso en servidores.

Si decidiste instalar CentOS en tu servidor aquí hay algunas cosas que te podría interesar hacer justo después:

NOTA: Estas instrucciones también son válidas para deployments de Red Hat Enterprise Linux

1) Instalar nano y wget

Personalmente me hallo más con éstos 2 que con vi y curl; Si también es tu caso, ejecuta:

1. su -
2. yum -y install nano wget

2) Repositorios Extra (Necesarios)

EPEL & Remi:

1. su -
2. wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
3. wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
4. sudo rpm -Uvh remi-release-6*.rpm epel-release-6*.rpm

RPMForge:

32 Bits:

1. su -
2. wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.i686.rpm
3. rpm -Uvh rpmforge-release-0.5.2-2.el6.rf.i686.rpm

64 Bits:

1. su -
2. wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
3. rpm -Uvh rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

Habilitando Remi:

1. su -
2. nano /etc/yum.repos.d/remi.repo


3) Actualizar

Para actualizar todo tu sistema, corre:

su -c 'yum -y update'

4) Configurar Firewall

NOTA: El comando #5 se debe repetir tantas veces como puertos quieras abiertos, reemplazando xx por el número de puerto que quieres abierto y xxx por "tcp" o bien, "udp" según corresponda.

1. su -
2. iptables -F
3. iptables -L -n
4. iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
5. iptables -A INPUT -p xxx --dport xx -j ACCEPT
6. iptables -A INPUT -j DROP
7. iptables -I INPUT 1 -i lo -j ACCEPT
8. service iptables save

5) Tweaks para rendimiento

Habilitar Tuned:

1. su -
2. yum -y install tuned
3. tuned-adm profile selected_profile

Más información sobre los perfiles disponibles acá: http://red.ht/1ppyozF

Habilitar ZRAM:

1. su -
2. yum -y install bc
3. wget https://spideroak.com/share/PBSW433EMVZXS43UMVWXG/78656e6f6465/srv/CDN/xenodecdn/zram -O /etc/init.d/zram
4. chmod 755 /etc/init.d/zram
5. chkconfig --add zram && chkconfig zram on

Reiniciamos y luego podremos checar que zRAM está corriendo con:

su -c 'service zram status'

Puedes checar más tips para mejora de rendimiento en: http://bit.ly/1hoo5XR

Habilitar Ksplice:

Ksplice es un gestor de paquetes de seguridad del que ya hablamos anteriormente y básicamente permite instalar actualizaciones de seguridad en tu servidor sin necesidad de reiniciar. La versión para RHEL se puede probar por 30 días (con una acces key de trial) y luego se requiere pagar aprox 4 USD/mo por usar el producto (con hasta 20 servidores, a partir de 20 en adelante el costo reduce a 3 USD/mo).

1. su -
2. wget https://www.ksplice.com/yum/uptrack/centos/ksplice-uptrack.repo -O /etc/yum.repos.d/ksplice-uptrack.repo
3. sudo yum -y install uptrack ksplice-uptrack-release
4. nano /etc/uptrack/uptrack.conf

En el archivo del comando #4, requeriremos insertar nuestra clave de acceso como nos lo pide:


Configurar IP Virtual única:

Si esto te interesa, acá nuestro tutorial

SELinux Permisivo:

SELinux es una buena utilidad de seguridad para sistemas CentOS/RHEL, sin embargo su activación puede traer problemas al momento de implementar ciertas cosas en tu servidor. Es por esto que, (al menos en CentOS 6.x de VPS) SELinux viene deshabilitado por defecto y en instalaciones normales viene activado. Personalmente prefiero "algo en medio" y suelo ponerlo en modo "permisivo" esto quiere decir que seguirá funcionando sin conflictuar con otras cosas y en lugar de proteger como tal únicamente nos mostrará advertencias relevantes para que nosotros nos encarguemos de la situación. Poner entonces a SELinux en modo permisivo se hace con:

1. su -
2. nano /etc/selinux/config

Y en el archivo que abrirá cambiamos el status de disabled a permissive. Guardamos los cambios, reiniciamos y listo.

Proteger acceso SSH con Google Authenticator en Linux


Hace tiempo en mi artículo sobre los 6 pasos fundamentales para montar un VPS  les hablaba de la autenticación SSH sin contraseña vía llave RSA como método de seguridad para nuestros servidores. Aunque esta suele ser una muy buena medida de seguridad en contra de atacantes externos y otras amenazas, he aquí una más que les puede resultar interesante para combinarla con la ya antes mencionada: Autenticación SSH a 2 pasos con el Google Authenticator.

El otro día les hablé ya del Google Authenticator y cómo implementarlo en su sitio web y/o app. Básicamente se trata de una aplicación móvil OpenSource que nos facilita la implementación de autenticación a 2 pasos (two factor auth) en una variedad de appliances que queramos lanzar. Para implementarla en nuestro servidor SSH entonces, necesitaremos:


  • Un smartphone: Android, iOS y/o Blackberry
  • El Google Authenticator instalado en dicho smartphone (está en las app stores)
  • libpam-google-authenticator en el servidor


El proceso de autenticación y/o generación de claves (totp tokens) se mantiene en sandbox privado entre tu teléfono y tu servidor sin pasar por servidores externos o algo parecido. Es por esto que a continuación veremos cómo libpam-google-authenticator nos proveerá incluso códigos de rescate en caso de perder acceso a nuestro teléfono para acceder a nuestro servidor.

NOTA: Para este tutorial, usaré Fedora/CentOS/RHEL y Ubuntu como distro(s) de referencia. Para cualquier otra distro el proceso debería ser el mismo mientras se instalen los paquetes equivalentes con el gestor de paquetes correcto según el caso. Los comandos que verán a continuación se deben ejecutar (obviamente) en el servidor deseado.

1) Instalando dependencias

Fedora/CentOS/RHEL

sudo yum install pam-devel make gcc-c++ wget

Ubuntu y Derivados

sudo apt-get install libpam0g-dev make gcc-c++ wget

2) Instalar el Módulo PAM para Google Authenticator

1. cd ~
2. wget https://google-authenticator.googlecode.com/files/libpam-google-authenticator-1.0-source.tar.bz2
3. tar -xvf libpam-google-authenticator-1.0-source.tar.bz2
4. cd libpam-google-authenticator-1.0
5. make
6. sudo make install

3) Configuración TOTP

Esta es la parte un tanto más compleja de la situación porque debe hacerse en base a cómo esté configurado tu servidor SSH (más que nada con qué usuario piensas acceder). En mi tutorial de los 6 tips fundamentales para lanzar un VPS les enseñé que el acceso SSH de root siempre debe mantenerse deshabilitado y únicamente debemos permitir el acceso remoto a un usuario estándar específico. Siguiendo esa lógica de seguridad, nos basaremos en la idea de que ese usuario se llama user en nuestro ejemplo para continuar con este paso... Corremos entonces:

su - 'user' -c '/usr/local/bin/google-authenticator'

Este comando nos pedirá una contraseña (la del usuario en cuestión), preguntará si queremos que los tokens se basen en tiempo (respondemos que sí), nos mostrará un QR o bien, un enlace HTTPS a un QR (que debemos escanear con el Google Authenticator para añadir la computadora) dándonos también acceso a una serie de códigos de rescate que debemos anotar (preferentemente en papel) y almacenar en algún lugar seguro. Finalmente hará varias preguntas de seguridad importantes... Responder a todas ellas con un y (Sí) nos dejará el setup más confiable posible:


4) Configuración SSH

Ahora necesitamos que la computadora haga uso de nuestro módulo PAM para autorizar/verificar el acceso SSH. Para habilitar dicho comportamiento corremos:

sudo nano /etc/pam.d/sshd

Y en el archivo que nos saldrá añadimos la siguiente línea como primer parámetro:

auth       required     pam_google_authenticator.so

He aquí un ejemplo:


Guardamos con Ctrl+O y luego Ctrl+X para después correr:

sudo nano /etc/ssh/sshd_config

Y en el archivo que nos saldrá, cambiamos la variable ChallengeResponseAuthentication de no a yes. Ejemplo:


Guardamos, salimos y finalmente reiniciamos nuestro servicio de SSH con:

sudo service sshd restart y/o sudo /etc/init.d/sshd restart

Y a partir de hoy cada que queramos loguearnos vía SSH a esta máquina, se nos pedirá nuestro token generado por el Google Authenticator (aparte de cualquier otro elemento de autorización que hayamos establecido previamente):


Habilitar el Google Authenticator (two-factor auth) en tu sitio web


El Google authenticator es una aplicación móvil disponible para iOS, Android y al parecer hasta Blackberry que nos auxilia en la implementación de autenticación a 2 pasos en nuestros sitios web. Varios sitios/apps como Evernote, Outlook y Dropbox (por sólo citar algunos ejemplos) lo tienen implementado para permitirle a sus usuarios proteger con una capa extra de seguridad sus preciadas cuentas. La preguna es: ¿Cómo implementarlo en nuestros propios sitios y apps? Sencillo:

1) Generar user_tokens

El Google Authenticator requiere que tengamos a la mano (por cada usuario en nuestro sitio/app) un token individual único. Este token deberá ser generado a partir de una entropía de 10 bits digeridos en formato hexadecimal y después codificados bajo base32, de dicho proceso lo que nos importa es retornar una string de 16 caracteres que podamos almacenar y utilizar como token perteneciente al usuario. Dicha string deberá ser presentada al usuario en formato de código QR después de generada para que pueda "activar" el enlace entre su cuenta en nuestro sitio y el Google Authenticator utilizando su teléfono. Si tenemos por ejemplo una app/sitio MEAN, dicho requerimiento se puede lograr con el siguiente código:


Nótese que este código está hecho para correr en consola únicamente y en una implementación real querríamos asociar el token con algún usuario de nuestro sitio a nivel base de datos (asegurándonos de que el token generado sea único con respecto al de otros usuarios) y mostrarle el QR con la URL generada en alguna vista para que lo pudiera escanear con el Google Authenticator. Si corremos este código en una consola (después de instalar vía npm los módulos crypto y thirty-two en caso de que no los tengamos), veremos que nos devuelve algo como lo siguiente:


El primer parámetro devuelto es el token del usuario y el segundo es la URL del QR que le mostraremos para que lo escanee con su Google Authenticator. Tomamos nota del token y visitamos la URL generada, abrimos Google Authenticator y añadimos un nuevo sitio mediante QR (lo que nos pedirá escanear el código de la URL), una vez hecho esto el resultado será el siguiente (en el móvil):


El totp_token generado (código de 6 dígitos) expirará cada 30 segundos y se seguirá generando uno nuevo para el usuario mientras tenga la aplicación abierta.

2) Validar accesos

Ahora necesitamos una manera de obtener dicho número a partir del token de usuario que nosotros tenemos para después poder implementar algún tipo de validación de acceso en base al google authenticator... Hacer esto es muy sencillo, sólo necesitamos instalar el módulo notp vía npm y nuestro código resultante (de pruebas) se vería así:


Que al ejecutarlo tras proveer el user_token correcto sacado del output del primer script (teniendo el Google Authenticator abierto para verificar), nos debería soltar un output como este:


Donde el código mostrado debería ser mismo en la pantalla del Google Authenticator en dicho momento.

LiveStream de tu webcam con AngularJS

Preámbulo

El otro día fui al banco a activar la banca electrónica para la nueva cuenta que recientemente abrí. Cuando uno hace eso en el banco en el que tengo mi cuenta actualmente (Banorte) se le provee con un token ya sea físico o en el celular (smartphone app) para tener un método de autenticación a 2 pasos y así asegurar (reforzar la seguridad de) el acceso electrónico a las cuentas y su manejo.

El único beneficio real (al menos a mi manera de ver) del token en el celular vs el físico es la posibilidad de tener acceso a tu banca electrónica desde donde sea mientras traigas el móvil contigo. Sin embargo usar el token celular conlleva uno que otro problema de los que no hablaré para no alargar esto... El punto es que terminé pidiendo un token físico para la nueva cuenta y para tener el beneficio de la obicuidad del token celular en mi token físico sin moverlo del escritorio se me ocurrió montar una tokenCam que pudiera revisar desde donde sea cuando así lo necesitara. Hay varias maneras de hacer esto, (transmitir una webcam en vivo de forma semi-privada) de las más conocidas:

El método con VLC es la elección por excelencia de muchos, pero requiere una computadora razonablemente potente con un sistema operativo razonablemente nuevo (Lo que significa que mi servidor CentOS 6 de 32 bits desde donde quiero servir la LiveCam queda descartado por ejemplo).

El método con FFmpeg es más amigable con el hardware usado, pero al necesitar una cantidad fija de banda ancha por cliente, termina consumiendo todo el Internet disponible con pocas conexiones a la LiveCam rápidamente, no es escalable ni rentable por lo tanto.

El método con HTML5 Websockets funciona muy bien en localhost, pero al exponerlo al Internet, el consumo de banda ancha vuelve a ser un problema haciendo que haya una mala experiencia de uso generalmente al tratar de ver el streaming desde un cliente externo.

El software especializado para cámaras IP (como podrían ser motion o bien, zoneminder por ejemplo) resultó ser por demás complejo de configurar y abarcaba muchas más cosas aparte del objetivo que quería cumplir, además de proveer de resultados malos (pésima calidad de streaming, con bastante lag encima).

Intentar con WebRTC era otra opción, pero implementar algo con dicha tecnología quedó fuera de mis opciones al ver que (al menos de momento) sigue muy verde del lado de los móviles. En mi caso específico es importante poder acceder la tokenCam desde mi iPhone sin mayor problema.

Entonces, ¿Cómo haremos nuestro streaming?

Para empezar, necesito que todos estemos en la misma página: Hacer un Livestreaming directo es "carísimo" (hablando de banda ancha e incluso recursos de hardware) es por esto que las plataformas y/o servicios que ofrecen esta funcionalidad delegan la carga de la transcodificación y el streaming como tal por medio de plugins propietarios del lado del cliente (Flash, Silverlight, Complemento de Google Hangouts) evitando gastar demás en recursos propios y/o del servidor. Para mi implementación no quise depender de un plugin externo con la finalidad de asegurar la máxima compatibilidad multiplataforma del lado de los clientes; Sin embargo los problemas de recursos seguían siendo los mismos: Para que se hagan una idea, un streaming de baja resolución (VGA) a 320Kbps (por ejemplo) representa un gasto de banda ancha de más o menos 3GB diarios en transferencia sin que nadie lo vea. Cada 24 horas de alguien viéndolo (incluso si es únicamente un solo cliente atendiendo al streaming sin parar) añade otros 3GB de banda ancha en transferencia a los previos tres ¡Demasiado! La solución con la que ataqué este problema fue muy sencilla y creo que a más de un lector le va a parecer incluso gracioso... Continúa leyendo para conocer los detalles.

NOTA: Para este tutorial usaré Fedora Linux como sistema operativo de referencia, pero estas mismas instrucciones aplican para otras distros linux e incluso otras plataformas (como Windows u OS X) mientras instales los programas/dependencias utilizados según el método correcto para tu sistema con algunas pequeñas modificaciones en los pasos citados según corresponda.

Primero: Instalar dependencias

1. sudo yum -y install python ffmpeg git git-core

Segundo: El servidor y la webapp

Ahora necesitarás descargar la aplicación de AjaxCam (que yo hice) desde Github con la finalidad de ahorrarte varios pasos extra:

1. cd ~
2. git clone https://github.com/Jmlevick/ajaxcam.git
3. cd ajaxcam
4. python pythonserverGzip.py 9229

Esto debería iniciar la interfaz web de nuestra livecam en el puerto 9229 de nuestro localhost, ahora sólo nos falta el streaming para transmitir:



Tercero: Comenzar Streaming

¿Recuerdan la solución de la que les hablaba? Se trata de lo siguiente: Tomaremos una fotografía de 1 a 15 fotogramas según nuestro setup (sí, por raro que esto suene) cada segundo con nuestra cámara web vía ffmpeg y la imagen resultante de la captura será guardada a 1 solo contenedor JPEG que refrescaremos en tiempo real sobreescribiéndolo. Luego vía ajax (gracias a AngularJS en este caso) lo que hace la interfaz que descargaste y estás corriendo en tu localhost en estos momentos es refrescar la imagen en vivo cada segundo también, dando la ilusión de estar emitiendo un "feed de video en vivo" o bien, Livefeed. Lo mejor de este enfoque es que no sólo es "amigable con el hardware" al no consumir demasiados recursos sino que también es amistoso con tu banda ancha, al no consumirla a menos que un cliente accese al streaming per sé, en cuyo caso consumirá (según el peso de tus imágenes) alrededor de 3+ veces menos (gracias al setup montado y al servidor Python con compresión Gzip que utilizaremos) que un livefeed real (con calidad equivalente) asumiendo 24 horas continuas de estar enganchado al stream. La única "pega" que podría encontrarle a este enfoque es que tiene un poco de lag sí o sí, pero a final de cuentas todos los métodos de streaming directo lo tienen en mayor o menor cantidad. En cuanto al audio, si es algo que te interesa no es difícil de implementar y si lo necesitas estás más que invitado a implementarlo y hacer una pull request al proyecto en Github de la AjaxCam (yo no lo he implementado porque no lo necesito en mi setup para la tokenCam).

Una vez explicado esto, prosigamos:

Posiciona tu cámara donde la vayas a dejar haciendo streaming. Puedes "calibrar" la posición con cualquier app de cámara que tengas a la mano, (en Linux está Cheese por ejemplo) y después correremos los siguientes comandos en otra pestaña de nuestra consola:

1. cd ~/ajaxcam
2. ffmpeg -y -f v4l2 -s 320x240 -i /dev/video0 -update 1 -r 15 -threads 0 -qscale:v 2 output.jpeg

Del segundo comando lo que nos importa en parámetros es lo siguiente:

  • -s 320x240: De qué tamaño queremos las imágenes
  • -i /dev/video0: El dispositivo de captura. En Linux todas las webcam se "localizan" como /dev/videoX si sólo tienes una conectada y/o disponible, es la 0 (como en mi caso), la segunda sería la 1 y así.
  • -r 15: Número de fotogramas por segundo. Si el lag es un problema, déjalo en un rango de los 15 a los 30 para evitar lo más posible la latencia (o intenta incrementarlo incluso) Si la disponibilidad se ve afectada (que la imagen desaparezca de pronto y/o muy seguido) reduce este número. Puedes dejarlo hasta en 1 para obtener la mayor disponibilidad a costa de unos segundos extra de latencia. En equipos poco potentes es recomendable dejar este parámetro en 15.

NOTA: El comando de ffmpeg para otras plataformas puede variar un poco, te recomiendo pedir asesoría en sus listas de correo o en sus foros para hallar el comando correcto de captura según tu caso... Los parámetros sin embargo, deberían ser los mismos en todos los casos.

En mi caso tengo una (algo antigua) cámara VGA que usaré para mi setup, so el comando que se ve arriba es perfecto para mi situación específica (además cada segundo cuenta cuando hablamos de un token, estos parámetros garantizan también poco lag). Ahora nos vamos a http://lvh.me:9229 o bien http://localhost:9229 y deberíamos ver nuestra LiveCam activa en la interfaz web. Si esto no es así, trata cortando el streaming de ffmpeg y reiniciándolo o bien, cambiando el parámetro de los FPS (de 15 a 25 por ejemplo) y volviéndolo a iniciar.

Finalizando: ¡A transmitir!

Todo esto está muy bien, pero ¿cómo podemos (por ejemplo) acceder este live feed desde nuestro móvil o bien darle acceso a otros? Sencillo. Suponiendo que no tengamos una IP pública/fija, utilizaremos ngrok (clic en el enlace para conocer más y hacer el setup si no lo tienes en tu sistema); Iniciar un servidor accesible al público para nuestra LiveCam con esta herramienta es tan sencillo como correr:

ngrok 9229

Eso nos soltará una URL en la consola del tipo:

http://234ab123.ngrok.com

Que podemos utilizar/visitar desde cualquier cliente externo para revisar nuestra LiveCam cuando queramos. Cabe destacar que ngrok puede bajar (de manera notable) el rendimiento de nuestro streaming por razones totalmente ajenas a nuestra AjaxCam. Si realmente piensas servir esta LiveCam, no olvides añadir al inicio del sistema los siguientes comandos (que deben correr como tu usuario desde tu Home); Puedes establecer este comportamiento de muchas maneras: con autostart (aplicaciones al inicio del escritorio) un cronjob o bien, desde tu rc.local:

1. cd ajaxcam
2. nohup ffmpeg -y -f v4l2 -s 320x240 -i /dev/video0 -update 1 -r 15 -threads 0 -qscale:v 2 output.jpeg >/dev/null 2>&1 &
3. nohup python pythonserverGzip.py 9229 >/dev/null 2>&1 &
4. ngrok start mycam

NOTA: Como explicamos en nuestro tutorial de Ngrok, es posible personalizar la URL de nuestro túnel para evitar que ésta cambie aleatoriamente con el paso de los días, en este caso estoy iniciando el túnel mycam previamente establecido en la configuración de Ngrok directamente.

Y pues bueno, esto es todo... Si te gustó el post, no olvides compartirlo, darle like, recomendar este blog y demás; Cabe destacar que esto es sólo una implementación básica y cada quien puede "extenderla" según sus necesidades (control de acceso para mayor seguridad por ejemplo). Eeen fin, eso ya depende de cada uno.

Nos leemos en los comentarios.

Programación multi-hilo en NodeJS: ¡Castiga a ese procesador!


Ok, me emocioné... jaja

Para todos aquellos que no lo sepan, (en muchos casos) por defecto NodeJS sólo utiliza 1 sólo núcleo (y proceso) aún en una computadora con multi-cores disponibles. Esto quiere decir que (en algunos casos) si corres un programa/aplicación NodeJS en una computadora con 2 o más núcleos en procesador (o en un clúster con varios a la mano pues) NodeJS no aprovechará por defecto toda la capacidad de cómputo que tenga disponible.

Para la mayoría de aplicaciones e implementaciones esto no suele ser relevante, (sobretodo si hablamos de scripting donde en muchos casos aunque NodeJS inicie un sólo proceso éste puede llegar a usar todos los cores dependiendo de para qué esté diseñado el script en cuestión).

Sin embargo, si vas a procesar grandes cantidades de datos a través de un script/app de NodeJS, deberías considerar hacer programación multi-hilo (que aproveche todos los núcleos disponibles y lance diferentes procesos por núcleo) en dicho caso... Lo mismo si el rendimiento es importante para ti y ves que tu aplicación está corriendo actualmente a un sólo núcleo (como es común en servidores HTTP creados con NodeJS y respectivamente en web frameworks como ExpressJS por ejemplo).

Y a todo esto, ¿Cómo se hace?

Sencillo. Se utiliza el módulo cluster de NodeJS:

npm install cluster

Y su uso es bastante sencillo, veamos el ejemplo:

monocore.coffee

Este script funciona únicamente con un sólo núcleo, y el resultado de ejecutarlo es el siguiente:


Para hacerlo multi-hilo, tenemos que adaptarlo así:

multicore.coffee

Y el resultado de ejecutar la nueva versión sería:


Como verán, el primer script llena un sólo núcleo de nuestro procesador con la tarea a realizar mientras el otro se mantiene libre de presión alguna. En cuanto clusterizamos nuestro script el proceso se hace multi-hilo y entonces empezamos a usar todos los cores disponibles en la máquina (en el caso de mi ejemplo 2), abriendo un proceso nuevo de node por c/u también (más aparte uno extra que corresponde al proceso del clústering):