Hola!

Hace unos meses me puse a instalar LXC para un cliente, y tenía la necesidad de que sus contenedores estuvieran en la misma red que sus servidores físicos. Por lo general LXC crea una red 10.0.3.0/24 y un puente con la ip 10.0.3.1 llamada “lxcbr0“, por tanto, lo que haremos será agregar otro puente usando la tarjeta de red activa, luego indicamos a LXC que cree los contenedores usando ese nuevo puente, estos son los pasos:

En nuestro /etc/network/interfaces (debian y ubuntu), generalmente tendremos esto:


auto eth0
iface eth0 inet static
       address 192.168.1.250
       netmask 255.255.255.0
       gateway 192.168.1.1
       dns-nameservers 8.8.8.8 8.8.4.4

Lo cambiamos a esto:


auto br0
iface br0 inet static
        bridge_ports eth0
        address 192.168.1.250
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 8.8.8.8 8.8.4.4

Con esto creamos nuestro nuevo puente “br0” ligado a eth0 (puede ser em1 ó enp5s0, etc)

Ahora toca indicarle a LXC que los nuevos contenedores usen este puente, editamos /etc/default/lxc-net y cambiamos USE_LXC_BRIDGE a: USE_LXC_BRIDGE="false"

Y en /etc/lxc/default.conf cambiamos lxc.network.link = lxcbr0 a lxc.network.link = br0

Y listo. Ahora dentro de los contenedores puedes usar configuración estática, o por dhcp.


auto eth0
iface eth0 inet dhcp

auto eth0
iface eth0 inet static
        address 192.168.1.10
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 8.8.8.8

.

Usar IP externa de una red diferente

Ahora, ¿porque me acordé de algo que hice algo meses?, porque lo reintenté para ponerle una IP pública a un servidor LXC en un dedicado que tengo, y ¡No funcionó!

El dedicado tiene una IP del tipo 199.xx.xx.105 al comprarle una IP extra (ó Failover IP) el proveedor me asignó la ip: 146.xx.xx.239 , al querer añadirla a un contenedor, éste se quedaba sin red y no se “veía” (ping) ni con el Host, por ahí ví un error “Network unreachable“, ¡claro! las dos IP’s son de dos redes diferentes y no hay nadie (un router) que les diga como comunicarse, así que la solución fue añadir una nueva ruta a la tabla de ruteo de linux. Estos son los pasos:

Teniendo ya el puente br0 configurado y funcionando, hay que indicarle a LXC que deseamos forzar una dirección IP, esto lo hacemos editando la configuración del contenedor en /var/lib/lxc/MICONTENEDOR/config:


lxc.network.ipv4=146.xx.xx.239
lxc.network.ipv4.gateway=199.xx.xx.105

Aquí hay que hacer notar que hemos puesto como gateway del contenedor la IP del Host. Esto es muy importante.

Y dentro del contenedor la siguiente configuración de red (/etc/network/interfaces) constará solamante de una sóla instrucción: “auto eth0” (dejando también la parte del loopback claro)

En este momento ya puedes levantar el contenedor con lxc-start, métete con lxc-attach y verás como tiene la IP que indicaste en su configuración, si ejecutas un route -n verás como su gateway es también lo indicado en la conf. Pero ¡NO TIENE RED!, déjalo “prendido” y de lado del Host ejecuta lo siguiente:

route add 146.xx.xx.239 br0

Tadá! Si haces un ping a la IP verás como ya responde, si te metes al contenedor verás como ya tiene red y puede responder a todos los servicios. Ahora, por supuesto estar agregando la ruta manualmente cada que iniciemos el contenedor está de hueva, vamos a automatizarlo.

Creamos dos scripts en /var/lib/lxc/MICONTENEDOR/ uno llamado iface-up.sh y otro iface-down.sh

iface-up.sh:


#!/bin/bash
route add 146.xx.xx.239 br0

iface-down.sh:


#!/bin/bash
route del 146.xx.xx.239 br0

No te olvides de darle permisos de ejecución a ambos scripts! Ej. chmod +x iface-up.sh

Y vamos a editar nuevamente la configuración del contenedor para añadir las siguientes dos líneas después de la parte donde añadimos los parámetros de red:

/var/lib/lxc/MICONTENEDOR/config:


...
lxc.network.ipv4=146.xx.xx.239
lxc.network.ipv4.gateway=199.xx.xx.105

lxc.network.script.up = /var/lib/lxc/MICONTENEDOR/iface-up.sh
lxc.network.script.down = /var/lib/lxc/MICONTENEDOR/iface-down.sh

Done. Ya con esto puedes probar parar e iniciar el contenedor varias veces, vigilando el estado de su red y de la IP y no debería tener problemas para acceder a Internet y viceversa.

Hola mundo,

Finalmente y después de tanta espera, Let’s Encrypt ha entrado en fase de Public Beta, es decir ya cualquiera que desee probarlo puede entrar y generar sus certificados.

Para quienes no conozcan que es Let’s Encrypt, es una nueva Autoridad de Certificación, abierta y gratis. Es administrado por la Internet Security Research Group (ISRG), y es patrocinado por las mas importantes Fundaciones de Internet, tales como la EFF, Mozilla, y también por grandes empresas como Cisco, Facebook, Ident Trust, Internet Society, entre otros.

La idea de Let’s Encrypt es que cualquiera tiene derecho de poder ofrecer seguridad a través de la encriptación (HTTPS) en sus sitios web, antes de la llegada de Let’s Encrypt, uno tenía que pagar a una Autoridad de certificación tales como Symantec, GoDaddy, DigiCert, Verizon, etc… cierta cantidad desde unos cientos y hasta los miles de USD dependiendo el nivel de certificación deseada.

Pero para la mayoría de usuarios un certificado de validación de nombre de dominio es mas que suficiente y esto es lo que ofrece Let’s Encrypt, que tus usuarios tengan plena seguridad de que los datos que viajan desde su máquina a tu servidor/sitio no puede ser leída por nadie mas, pues el certificado sólo puede provenir del servidor donde reside el dominio auténtico y no de un suplantador (ó de una agencia de espionaje cofcofNSAcofcof)

 

Instalación

Primero que nada, todo lo siguiente debes correrlo en el servidor en donde residen los dominios para los que quieres generar los certificados, pues Let’s Encrypt debe poder escribir ciertos archivos en su WebRoot (a.k.a. DocumentRoot) para poder validar efectivamente que eres el dueño del dominio y tienes control sobre él.

Paso 1, Debes tener Git instalado y clonar el depósito:

user@webserver:~$ git clone https://github.com/letsencrypt/letsencrypt.git

Paso 2, Córrelo una vez para que pueda instalar todas sus dependencias (la mayoría bibliotecas en python), por tanto debes tener privilegios de administrador ya sea acceso a root directo o por medio de sudo, posteriormente generará una nueva llave privada y con el email que le especifiques creará una nueva cuenta para ti en los servidores de Let’s Encrypt, todo esto es un proceso automático. NOTA: De momento no le especifiques ningún dominio.


root@webserver:~$ cd letsencrypt
root@webserver:~/letsencrypt$ ./letsencrypt-auto --email tudireccion@deemail.com --agree-tos

Paso 3, Let’s Encrypt tiene plugins para poder leer archivos de configuración de Apache, saber que dominios tienes, donde están y modificar estas configuraciones para añadir los certificados de manera automágica, pero esto es un grave problema para los que tenemos servidores web con algún tipo de panel de control que genera sus propias configuraciones y sobreescribirían los cambios hechos por Let’s Encrypt, otra opción es que dejes a Let’s encrypt levantar un web server standlone, pero esto implica que debes detener tu web server principal.

En mi caso estos 2 primeros métodos no son una opción, así que me fuí por la tercera, puedes darle a Let’s Encrypt el path al DocumentRoot de tu dominio para que realice la validación con unos archivos especiales que debe guardar allí. Aclarado esto, digamos que tienes tus dominios en /var/www/$dominio, por ejemplo /var/www/fulanito.com, correríamos lo siguiente:


root@webserver:~/letsencrypt$ ./letsencrypt-auto certonly --webroot -w /var/www/fulanito.com/ -d fulanito.com

¡Y listo!, generará automáticamente tu CSR (Certificate Signing Request), lo firmará, lo enviará a los servidores de Let’s Encrypt, estos validará que existan los archivos en fulanito.com/.well-known/acme-challenge/ y de ser así devolverá el certificado firmado. Se generarán 4 archivos en /etc/letsencrypt/live/fulanito.com/


root@webserver:~# ls /etc/letsencrypt/live/fulanito.com/
cert.pem  chain.pem  fullchain.pem  privkey.pem

Los cuales contienen:

  • cert.pem – contiene el certificado firmado
  • chain.pem – certificado “intermedio”
  • fullchain.pem – contiene ambos cert.pem y chain.pem, para los servicios que soporten este formato
  • privkey.pem – la llave privada del certificado

Configurar el webserver (Apache y NginX)

Esto sería lo único a añadir en tu virtualhost de Apache, (si antes no usabas SSL, asegúrate de activar los módulos y habilitar el virtualhost de SSL que contiene las entradas para el puerto 443)


<VirtualHost ww.xx.yy.zz:443>
        ...
        SSLEngine on
        SSLCertificateFile /etc/letsencrypt/live/fulanito.com/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/fulanito.com/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/fulanito.com/chain.pem
        ...
</VirtualHost>

Y para NginX, algo como lo siguiente:


server {
    listen      ww.xx.yy.zz:443;
    server_name fulanito.com www.fulanito.com;
    ssl         on;
    ssl_certificate      /etc/letsencrypt/live/fulanito.com/fullchain.pem;
    ssl_certificate_key  /etc/letsencrypt/live/fulanito.com/privkey.pem;
    ...

Y eso es todo, espero este artículo les sirva en algo y les ayude a brindar mas seguridad a sus sitios web. Como ven es bastante fácil utilizar Let’s Encrypt.

Sólo resta mencionar que quienes tienen su hosting/cloud server/dedicado con ideaslabs.com pueden solicitar su certificado gratis y se les será configurado casi al instante sin costo alguno ;)

Saludos!

motorolaA1200 cherokeeWhy should someone want to run a web server on his cellphone? Of course because he can =), just for the fun!

So, how to compile cherokee for Motorola A1200i:

First we need to build a “toolchain” a development environment that can compile binaries for the CPU architecture of the phone, in this case: ARM Linux

Such toolchain can be download from here: http://lsb.blogdns.com/ezx-crosstool

Pretty easy, just run ./build.sh you need build-essential (gcc and company), flex and bison, go for a cup of cofee and let the automagic work, this will compile a GCC compatible with your phone among some other utilities.

Now fetch last release of cherokee: http://www.cherokee-project.com/ , unpack and prepare yourself to compile it.

I based in this document: http://www.cherokee-project.com/doc/cookbook_embedding_cherokee.html after a few of  “try and fail” tests i end with this configuration:


export AR=/home/maop/ezx-crosstool-0.6/gcc-arm-iwmmxt/gcc-3.3.6-glibc-2.3.2/arm-linux/bin/arm-linux-ar
export LD=/home/maop/ezx-crosstool-0.6/gcc-arm-iwmmxt/gcc-3.3.6-glibc-2.3.2/arm-linux/bin/arm-linux-ld
export CC=/home/maop/ezx-crosstool-0.6/gcc-arm-iwmmxt/gcc-3.3.6-glibc-2.3.2/arm-linux/bin/arm-linux-gcc
ac_cv_func_shm_open=no ac_cv_lib_rt_shm_open=no ac_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes \
 ./configure --host=arm-linux--prefix=/mmc/mmca1/cherokee --enable-static --enable-shared=no --enable-static-module=all \
 --disable-tls --enable-beta --enable-trace --enable-nls=no --disable-largefile --disable-admin --disable-epoll --disable-ipv6 \
CC=/home/maop/ezx-crosstool-0.6/gcc-arm-iwmmxt/gcc-3.3.6-glibc-2.3.2/arm-linux/bin/arm-linux-gcc

As you can see i set –prefix to “/mmc/mmca1/cherokee” this mean that we’ll “install” cherokee on our memory stick this way we avoid to hack motorola’s linux system. Also this mean that you have to create that path on your development machine, try mkdir -p /mmc/mmca1/cherokee and chown youruser:yourgroup -R /mmc

Now type “make” so compile of cherokee begins.

After make is done, type “make install” and all files will copy to /mmc/mmca1/cherokee

Now just transfer the “cherokee” directory to your SD card with your favorite transfer method (bluetooth, ftp, ssh, smb, usb mount, etc), then open eKonsole (you have shell in your phone right?) or telnet or sshd into it, change to the right directory: cd /mmc/mmca1/cherokee and simply run cherokee by typing: sbin/cherokee

And that’s all, of course you have to configure your phone to “USB Network” in your “USB Mode” settings, then open a browser in your machine, and type the IP of the phone et voilá! cherokee serving web pages right from your cell phone.

Dude, i remember the times of my night sessions with my 80386 coding in GW-Basic. Now our cellphones have more power than those old machines.

You can see cherokee in action in this video (if you can’t see it come to my site and see it =):

Cherokee running on a Motorola A1200i


Next post: “how to get your unix powertools in your A1200” (vim, bash, sshd, strace, python, perl, ruby, php, vmstat, nano, etc)

Saludos!

¡Al fin!

Leo en osnews que el ultimo built de chromium ya es funcional en linux. Y gracias a la gente de PPa ya estan disponibles paquetes .deb’s. Hay que agregar a la lista de depositos los siguientes:

deb http://ppa.launchpad.net/chromium-daily/ppa/ubuntu intrepid main
deb-src http://ppa.launchpad.net/chromium-daily/ppa/ubuntu intrepid main

Luego un aptitude update;aptitude install chromium-browser.

Chromium en Linux

Chromium en Linux

Estoy haciendo este post desde Chromium y si tiene fallitas, a veces los “modal” del wysiwyg de wordpress no funcionan, el preview no funciona, no acepta acentos en el textarea del wysiwyg. Pero bueno… la beta de Chrome For Linux ya viene en camino tambien.

Mas informacion: http://www.osnews.com/story/21152/Google_Chrome_for_Linux_On_Its_Way_Take_It_for_a_Spin

Jamás he estado cómodo con los clientes de Mensajería de linux/unix, Simplemente nada supera a los viejos pero bonitos clientes de ICQ ó el veterano Trillian, pionero en clientes multiprotocolo, por citar algunos.

Los clientes de linux, o carecen de todas las características, ó son extremadamente FEOS y carentes de USABILIDAD, ó sus desarrolladores son unos malditos NAZIS de la UI tratando a sus usuarios  como estúpidos y simples esclavos de la monopolización, pues no hay nada mas mejorcito.

Y si lo hay tienes que tener un cliente con C, otro hecho en python, otro hecho en mono, otro en TCL/TK, corriendo al mismo tiempo, consumiendo toda tu memoria y recursos. Uno requiere gnash, otro swfdec, gstreamer… ¡DIOS! y es eso o tener un solo cliente sin todas las características que cubran tus necesidades, that just sucks.

En fin, tendremos que esperar y esperanzar, en que, en AMSN2 con la unión de la gente de AMSN+Emesene+PyMSN, lograrán hacer un buen trabajo.

AMSN. Una palabra lo describe, FEO, aunque ya han optimizado muchísimo su código, le han agregado parches para soportar fuentes “alisadas”, etc, pónganle lo que le pongan es feo. Poco usable. Pero hay que aceptarlo, es el que mas funciones soporta y es el único que tiene un soporte real y estable de webcam.

Pidgin. Los desarroladores son dueños de las decisiones sobre pidgin, hace caso absolutamente omiso de lo que piden los usuarios, incluso han existido varios forks en el transcurso de su vida por esta misma razón. fun pidgin, gaim-vv, por ejemplo. Y aún y con todas sus estúpidas reglas de UI, es una patada en los huevos la revoltura de contactos que hace cuando tienes varias cuentas, fue un PITA también cuando tardaron un año en poner emoticons o actualizar MSNP10. Es horrible cuando de la nada truena, cuando tiene problemas con los certificados de google… en fin, un caos.

Emesene. Uno de los más jóvenes, a mi parecer el mejor de los 3, totalmente de la comunidad, hecho con python. Buena colección de funciones. Tiene una versión mantenida por la comunidad “emesene crazy” donde ya tienen soporte webcam (muy inestable, pero cuando jala, jala bien)

Recomiendo instalar emesene-crazy,

bzr branch lp:~c10ud/emesene/emesene-crazy emesene-crazy
emesene con webcam

emesene con webcam

[UPDATE]: El Kmess se ve muy bien, también. http://kmess.org/screenshots/

Y, ¿ustedes que usan?, ¿conocen algún otro cliente?, ¿prefieren uno multiprotocolo ó de uno sólo, pero que realmente soporte las funciones?

Saludos!