Categorías
Android KVM Smartphone Vritualización Windows

Marshmallow en Galaxy S6 Edge

Marshmallow
Marshmallow

Por fin Marshmallow para tu S6 Edge si sigues este tutorial

Quieres Marshmallow Android 6.0.1 para tu galaxy S6 Edge? Estás harto de esperar que Samsung actualice a Android 6.0?

Aquí tienes un link para descargar Android 6.0.1 Marshmallow para tu SM-G925F

 

ATENCIÓN: Fail hidden.img with Odin, Fail Sammobile hidden.img con Odin
ATENCIÓN!!! Para no hacer un soft-brick al teléfono seguir las instrucciones siguientes:

  • Descargar este toolkit.
  • Una vez instalado el toolkit seguir los pasos siguientes
    • Descomprimimos el fichero de Android 6.0.1 que nos hemos descargado, pero lo hacemos dos veces, primero el fichro comprimido y luego la imagen que contiene ese fichero comprimido, que es una imagen .tar.
    • Para descomprimir la imágen tar lo hacemos con 7-zip.
    • Ponemos todos los ficheros que descomprimimos en la carpeta INPUT del toolkit (c:\carpetatoolkit\INPUT)
    • Borramos el fichero hidden.img (Este fichero bloquea la instalacion y hace un soft-brick)
    • Ahora iniciamos el toolkit
    • Opción 27 para el Galaxy S6 Edge (Si es nuestro caso)
    • Pulsa cualquier tecla para continuar (Changelog)
    • Opción 01 para la variante G925F internacional, del teléfono
    • Opción 11 para Android 5.0.2 (Es para poder acceder a la opción que realmente interesa)
    • Opción 18
    • Opción 2
    • Ahora nos advierte de los ficheros con los que generará de nuevo el fichero TAR que quemaremos con ODIN en nuestro smartphone. RECORDAD que la imágen nueva sin hidden.img se ha generado en la carpeta OUTPUT de la aplicación.
  • Y listo, con el Odin ya podemos quemar nuestro Android 6.0.1 a nuestro S6 Edge.

Si tienes cualquier problema para quemar el firmware no dudes en ponerte en contacto conmigo y veremos que podemos hacer, aun así, quiero recordar que quemar un firmware no es una tarea para cualquiera y que las consecuencias pueden ser graves.

Tengo que decir que la imágen española y la imágen del Reino Unido son exactamente la misma, tal y como se puede ver ahí.

Actualización 03/02/16: Parece que hay una nueva imágen para España, esta imágen también me ha fallado al instalarla, ya que bloquea la instalación el fichero hidden.img.
Algunos os preguntareis si es seguro eliminar dicho fichero, pues es una buena práctica, ya que en él hay aplicaciones que las compañías instalan en los terminales, así que borrándolo salimos ganando.

[email protected]:~/Fitxers$ md5sum G925FXXU3DPB8_G925FVFG3DPB8_VOD.zip 
c49086bee16a42c268646494db93d992  G925FXXU3DPB8_G925FVFG3DPB8_VOD.zip
[email protected]:~/Fitxers$ md5sum G925FXXU3DPB8_G925FVFG3DPB8_ATL.zip 
c49086bee16a42c268646494db93d992  G925FXXU3DPB8_G925FVFG3DPB8_ATL.zip
[email protected]:~/Fitxers$ 
Categorías
Blog GNU/Linux Informática Linux Containers Seguridad Inormática Sistemas Operativos Vritualización

LxC Anexo I (Script actualización Containers)

 Saludos!

Para finalizar la primera entrega de los artículos sobre LxC, os voy a poner aquí un script que he creado yo mismo para mantener los containers actualizados!

Recordemos que las entradas sobre containers son las siguientes:

Linux Containers I
Linux Containers II
Linux Containers III

Vamos al grano! El script que sigue, se trata de un script de actualización de una máquina con Arch con varios containers, con este script conseguimos actualizar la máquina anfitrion y todos sus containers con un solo comando, pudiendo mantener actualizado nuestro sistema con una sola linea.

Lo único que tendremos que hacer antes de usar por primera vez el script, es crear un enlace simbólico llamado upgrade.conf en /etc/rc.d/ y que apunte a /etc/rc.d/lxc.conf, para que actualice los contenedores que están especificados en este fichero.
Como nota, decir que podemos crear un fichero nuevo con una configuración distinta al lxc.conf, si queremos actualizar distintos containers a los que se inicia automáticamente.

Creamos el enlace con el siguiente comando:

sudo ln -s /etc/rc.d/lxc.conf /etc/rc.d/upgrade.conf

Ahora vamos a crear el script, que lo podeis copiar de ahí abajo o descargarlo desde este enlace.

#!/bin/bash
#
# Aquest script serveix per mantenir actualitzada una màquina amb diferents containers
# Si tens algún problema amb aquest script, envia una notificació al seu administrador
# El correu és [email protected]
#
# Copyright 2011 (c) crashbit's blog
# This is free script under GNU GPL version 2.0 or above.
# Tested os:
# * Archlinux 2011
# -------------------------------------------------------------------------
# Aquest script forma part d'un article publicat al Blog de Crashbit
# Visit http://crashbit.homelinux.com for more information.
# -------------------------------------------------------------------------
. /etc/rc.conf
. /etc/rc.d/functions

[ -f /etc/conf.d/upgrade.conf ] && source /etc/conf.d/upgrade.conf

case "$1" in
 full-upgrade)
 echo -e "\33[40m\33[1;34m::\33[40m\33[1;37m Actualizando equipo anfitrion:\33[0m"
 /usr/bin/pacman -Syu --noconfirm
 for container in "${CONTAINERS[@]}"; do
 if [ "${container}" = "${container#!}" ]; then
 echo -e "\33[40m\33[1;34m::\33[40m\33[1;37m Actualizando container:\33[0m "${container}
 /usr/sbin/mkarchroot -u /srv/containers/${container}
 fi
 done
 ;;
safe-upgrade)
for container in "${CONTAINERS[@]}"; do
if [ "${container}" = "${container#!}" ]; then
echo -e "\33[40m\33[1;34m::\33[40m\33[1;37m Actualizando container:\33[0m "${container}
/usr/sbin/mkarchroot -u /srv/containers/${container}
fi
done
;;

*)

echo "usage: $0 {full-upgrade|safe-upgrade}"

esac

Así que esto es todo, un pequeño script para automatizar tareas y hacer que nos podamos dedicar a lo que realmente importa.

Decir que para lanzar el script haremos lo siguiente:

sudo /etc/rc.d/upgrade full-upgrade --------> Para actualizar máquina anfitrion y containers.
sudo /etc/rc.d/upgrade safe-upgrade ------> Para actualizar solo los containers.

Saludos! Crashbit

Categorías
Blog GNU/Linux Informática Linux Containers Seguridad Inormática Sistemas Operativos Vritualización

Linux Containers en Archlinux III (Crear servidor web de respaldo)

Saludos!

Este artículo es la continuación de la trilogía sobre Linux Containers, LxC para los amigos. Recordemos que anteriormente he creado estas dos entradas sobre containers. Concretamente Linux Containers servidor de respaldo.

En estas dos entradas se han comentado los conceptos básicos de como crear, modificar y destruir un container, así que ahora toca administrar este container, hacer que haga algo realmente últil, como por ejemplo de servidor de backup de un servidor web, para luego, en la segunda serie de la trilogía, empezar a hablar de control de container.

Así pues, repasemos un poco lo aprendido hasta ahora:

  1. Preparar la máquina:
    Crear directorio /cgroup y hacer que se monte automáticamente en el fstab
    /etc/fstab → none /cgroup cgroup defaults 0 0
    Instalar el paquete bridge-utils y configurar /etc/conf.d/bridges
    /etc/conf.d/bridges →

    bridge_br0="eth0"
    config_br0="brctl setfd br0 0"
    BRIDGE_INTERFACES=(br0)

    Configurar el /etc/rc.conf para que monte los interfaces de red de la máquina anfitrion
    /etc/rc.conf →

    eth0="eth0 up"
    br0="dhcp"
    INTERFACES=(eth0 br0)

    Tener instalado base-devel, yaourt y el paquete lxc
    Poblar el directorio /dev/ del container
    Crear el fichero de configuración del container donde queramos, por ejemplo /etc/lxc.backup
    /etc/lxc.backup →

    lxc.utsname = backup
    lxc.mount = /srv/containers/backup/etc/fstab
    lxc.rootfs = /srv/containers/backup
    lxc.network.type = veth
    lxc.network.flags = up
    lxc.network.link = br0
    lxc.network.hwaddr = 10:14:85:0F:C5:B9
    lxc.network.ipv4 = 0.0.0.0
    lxc.network.name = eth0.backup
    lxc.tty = 1

    Creamos el fichero /etc/fstab dentro del container, es decir el /srv/containers/backup/etc/fstab
    /srv/containers/backup/etc/fstab →

    none /srv/containers/backup/dev/pts devpts defaults 0 0
    none /srv/containers/backup/proc proc defaults 0 0
    none /srv/containers/backup/sys sysfs defaults 0 0
    none /srv/containers/backup/dev/shm tmpfs defaults 0 0

    Dentro del container vamos a crear un dispositivo de carácteres
    Dispositivo → 

    sudo mknod -m 666 /srv/containers/backup/dev/tty1 c 4 1

2. Configurar el Container para un arranque correcto:
Modificamos el fichero /etc/rc.sysinit del container para un arranque básico de la siguiente forma:

#!/bin/bash
# Whatever is needed to clearn out old daemon/service pids from your container
rm -f $(find /var/run -name '*pid')
rm -f /var/lock/subsys/*
rm -f /var/run/daemons/*

# Initally we don't have any container originated mounts

 #rm -f /etc/mtab
 #touch /etc/mtab
if ! /bin/mountpoint -q /proc; then
/bin/mount -n -t proc none /proc
fi
if ! /bin/mountpoint -q /sys; then
/bin/mount -n -t sysfs none /sys
fi
if ! /bin/mountpoint -q /dev/shm; then
/bin/mount -n -t tmpfs none /dev/shm
fi
if ! /bin/mountpoint -q /dev/pts; then
/bin/mount -n -t devpts none /dev/pts
fi

Una vez creado este script, nuestra máquina debería iniciarse correctamente
Recordemos crear el container con el siguiente comando:

lxc-create -f /etc/lxc.backup -n backup

A continuación instalamos openssh, apache, mysql y php, que son los ficheros necesarios para tener un servidor de backup y respaldo, por si se nos cae el nuestro, así poder encender rápidamente este otro.

Ahora vamos a por la siguiente parte, vamos a aprender a gestionar nuestro containers desde la máquina anfitrion, y lo haremos con un script muy util al que llamaremos lxc:

#!/bin/bash
. /etc/rc.conf
. /etc/rc.d/functions

[ -f /etc/conf.d/lxc.conf ] && source /etc/conf.d/lxc.conf

case "$1" in
start)
for container in "${CONTAINERS[@]}"; do
if [ "${container}" = "${container#!}" ]; then
stat_busy "Starting Linux container: ${container}"
/usr/bin/screen -dmS init-${container} /usr/bin/lxc-start -n ${container}
lxc-wait --name=${container} --state=RUNNING
if [ $? -gt 0 ]; then
stat_fail
else
stat_done
fi
fi
done
add_daemon lxc
;;

stop)
for container in "${CONTAINERS[@]}"; do
if [ "${container}" = "${container#!}" ]; then
stat_busy "Stopping Linux container: ${container}"
/usr/bin/lxc-stop -n ${container}
if [ $? -gt 0 ]; then
stat_fail
else
stat_done
fi
fi
done
rm_daemon lxc
;;

restart)
$0 stop
sleep 1
$0 start
;;

*)
echo "usage: $0 {start|stop|restart}"

esac

Luego damos a este script, permisos de ejecución y lo metemos en /etc/rc.d , de esta forma lo podremos iniciar con un comando, tecleando sudo /etc/rc.d/lxc start.
Este script requiere de unos ficheros básicos de configuración, que están en /etc/conf.d y este fichero se llamará lxc.conf, el qual tendrá el siguiente contenido:

CONTAINERS=(backup)

# use the ! prefix to disable starting/stopping a container

Con esta configuración, haciendo un lxc start, iniciareos el container backup, pero no el container virtual, y si ponemos en el apartado DAEMONS del rc.conf de la máquina anfitrion, lxc, conseguiremos que se carguen los containers al iniciar el sistema. Pues bien, ahora supondré que ya tenemos el conatiner funcionando, que apache corre perfectamente, que mysql y php tambien y que vamos a hacer un backup de una máquina con DEBIAN que tiene corriendo un blog en drupal, uno igual que este.

Primeros pasos:
1) Crear la bbdd mysql correspondiente dentro del container, esto lo podemos hacer manualmente o bien usando un gestor como webmin
2) Crear los usuarios de la bbdd y darle los permisos adecuados, deben ser los mismos que los del equipo que vamos a respaldar, almenos para no tener problemas.
3) Copiamos todo el directorio donde está nuestro drupal, dentro del container, esto yo lo hago por ssh, ya que tengo ssh corriendo en el container.
4) Nos aseguramos que todo está funcionando a la perfección y que ahora mismo tenemos un duplicado del blog, yo he configurado el apache de la máquina backup, para que responda al puerto 81. Bien, podemos ver que tenemos una copia del blog, pero ahora toca la mejor tarea, la sincronización, es decir, que se mantenga actualizado, ya que ahora mismo, si modificamos algo del blog del servidor DEBIAN, no se modifica en el servidor que hay dentro del container.

Automatizar la sincronización:
1) Para ellos vamos a usar una herramienta principalmente, esta se llama rsync. No voy a ponerme a hablar sobre ella, ya que podemos encontrar mucha información en la red, por ejemplo aquí.
2) Tambien tendremos que configurar nuestras dos máquinas para que se puedan comunicar por ssh, sin necesidad de meter contraseña y de forma segura, información sobre ello, la podemos encontrar ahí.
3) Y para finalizar, tendremos que usar mysqldump para crear copias de la base de datos de mysql. Estos pasos, son los tres necesarios para poder mantener un backup al día. Así pues, vamos primero de todo a configurar nuestras máquinas para que puedan comunicarse por ssh sin pedir password.

CONFIGURACIÓN SSH CLAVES GPG:
Primero vamos a la máquina DEBIAN, y creamos un par de llaves, esto lo podemos hacer así:

ssh-keygen -t rsa

Esto creará un par de llaves en la carpeta .ssh/ del usuario que intentará conectar con la máquina backup, una pública y otra privada, llamada id_rsa.pub y id_rsa A continuación vamos a copiar la clave pública, la id_rsa.pub, a la máquina Archlinux que va a ser el servidor de backups, en mi caso, la máquina se llama arch-backup.homelinux.com y el servidor openssh está escuchando en el puerto 662, por lo que el comando para transferir la llave sería el siguiente:

scp -P 662 ./ssh/id_rsa.pub [email protected]:/home/crashbit/

Bien, ahora vamos  a la máquina backup y renombramos este fichero del siguiente modo:

mv id_rsa.pub .ssh/authorized_keys
chmod 700 .ssh/

Solo falta modificar el demonio openssh para que permita llaves públicas, mirando al configuración /etc/ssh/sshd_config

#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Ahora ya nos podemos conectar al servidor backup sin poner contraseña, claro, siempre y cuando, cuando en el momento de crear la llave no le hayamos puesto palabra de paso. Jeje.

CONFIGURACIÓN RSYNC:Vamos a crear varias lineas en el cron, para que se ejecuten automáticamnete a las 12 y a las 12:10 de la noche, en la primera haremos una copia de seguridad de la bbdd mysql en la máquina local, en el servidor debian y a las 12:10, vamos a transferir todos los ficheros de drupal, incluida la copia de seguridad de la bbdd a la máquina backup, aunque mas que transferir, debería decir sincronizar.Luego, ya a posteriori, en la máquina backup, a las 12:30, vamos a restaurar la copia de seguridad de la bbdd que ha recibido en la última sincronización.

Los pasos en el servidor DEBIAN son los siguientes:

crontab -e
00 0 * * * crashbit mysqldump --opt -uUSUARIO -pCONTRASEÑA drupal6 > /home/crashbit/www/drupal-6.10/drupal6-backup.sql
10 0 * * * crashbit rsync -az --delete --no-whole-file -e "ssh -p 662" /home/crashbit/www/drupal-6.10 [email protected]:/srv/http/

Aquí lo que hacemos es con la primera linea crear el backup de la bbdd drupal6 y decirle que lo guarde en el directorio donde está el servidor, para que luego, en la segunda linea, sincronizamos el directorio del servidor DEBIAN con el directorio del servidor BACKUP. No debemos dar cuenta que usa ssh por el puerto 662  y sincroniza el directorio /home/crashbit/www/drupal-6.10/ con /srv/http, donde hay el directorio drupal-6.10 tambien.

Pasos en el servidor BACKUP:Ahí vamos a decirle que restaure la bbdd a las 12:30, lo haremos poniendo una tarea en el crontab:

30 0 * * * mysql -uUSUARIO -pCONTRASEÑA drupal6 < /srv/http/drupal-6.10/drupal6-backup.sql

Con todo eso ya tenemos sincronizado nuestro servidor DEBIAN con el container BACKUP, consiguiendo así un container que nos hace de respaldo del servidor LAMP que tenemos en Debain. Saludos!

 

Categorías
Blog GNU/Linux Informática Linux Containers Seguridad Inormática Sistemas Operativos Vritualización

Linux Containers en ArchLinux II (Configuración del servidor web)

 Saludos!

Esta és la segunda entrada sobre Linux Containers, de los que ya hablamos en el anterior enlace. En la pasada entrada, hablé de los conceptos generales, de como crear un container, de los requisitos, de como funcionan, de como acceder a un container con lxc-console -n CONTAINER y algunas otras cosas. Pero falta lo realmente interesante, que es el uso del container como jaula para nuestros servidores, sean OpenSSH o un servidor web con Apache o Cherokee.

Vamos a continuar con la configuración de los containers, primeramente recordar unos conceptos básicos, cuando se modifica el /etc/fstab del CONTAINER o el fichero de configuración que usamos para la creación del container, el container en si, no se modifica, por lo que la mejor opción es eliminar el container y volverlo a crear con la nueva configuración. Hacer esto es muy rápido, tal y como recordaremos:

[[email protected] ~]$ sudo lxc-destroy -n CONTAINER
[[email protected] ~]$ sudo vim /mnt/CONTAINER/etc/lxc.CONTAINER o fstab
[[email protected] ~]$ sudo lxc-create -f /mnt/CONTAINER/etc/lxc.CONTAINER -n CONTAINER

De esta forma podemos hacer las modificaciones adecuadas a nuestros containers, así que pues, pongámonos manos a la obra en lo que nos interesa.
Parte I (Puntos de montaje)

Primero de todo, supongo que os habeis dado cuenta al acceder al container por lxc-console, de que no tenemos nada montado, ni /proc , ni /sys , ni /dev/shm y tampoco /dev/pts. Creereis que se trata de un error, ya que hemos definido nuestro fichero /etc/fstab dentro del container y tambien le hemos pasado la ruta de este fichero en la configuración de creación del container, tal como lxc.mount = /mnt/CONTAINER/etc/fstab.
Así pues … ¿ a que se debe que no monte nada de lo que se le especifica en nuestro fstab ?
– La respuesta es simple, es el fichero rc.sysinit el que debe leer lo que hay en el fstab y montarlo si procede.

Así pues deberemos modificar nuestro fichero /mnt/CONTAINER/etc/rc.sysinit (si estamos dentro del container por lxc-console, la ruta es /etc/rc.sysinit) y dejarlo como el siguiente ejemplo, que nos montará /proc, /sys, /dev/pts y /dev/shm.


#!/bin/bash
# Whatever is needed to clearn out old daemon/service pids from your container
rm -f $(find /var/run -name '*pid')
rm -f /var/lock/subsys/*

# Initally we don't have any container originated mounts
#rm -f /etc/mtab
#touch /etc/mtab

if ! /bin/mountpoint -q /proc; then
/bin/mount -n -t proc none /proc
fi
if ! /bin/mountpoint -q /sys; then
/bin/mount -n -t sysfs none /sys
fi
if ! /bin/mountpoint -q /dev/shm; then
/bin/mount -n -t tmpfs none /dev/shm
fi
if ! /bin/mountpoint -q /dev/pts; then
/bin/mount -n -t devpts none /dev/pts
fi

Es importante dijarse en las sentencias if, ya que ahí lo que hace es mirar si existe punto de montaje para distintos sistemas de ficheros y de ser afirmativo, los monta. Así pues, una vez modificado este script, ya podemos relanzar el container con el lxc-start -n CONTAINER
Parte II (Servicio OpenSSH)

Ahora vamos a entrar en el container si no lo hemos hecho ya, para ello tecleamos lo siguiente:

[[email protected] ~]$ sudo lxc-start -n CONTAINER
[[email protected] ~]$ sudo lxc-console -n CONTAINER


Pues bien, ahora entramos como root o si hemos creado una cuenta con permisos para usar sudo, entramos con esta cuenta y podremos ver que estamos dentro de la máquina virtual.

Así que vamos a instalar y configurar el servidor ssh:

CONTAINER:
[[email protected] ~]$ sudo pacman -S openssh
[[email protected] ~]$ sudo vim /etc/ssh/sshd_config

De este fichero modificamos el puerto por defecto que usa el servidor ssh y le decimos que no permita accesos a root (siempre y cuando hayamos creado un usuario cualquiera para poder acceder a la máquina sin ser root), estas dos opciones de configuración son las siguientes:

Port 777
PermitRootLogin no

Así pues, ya tenemos el servidor configurado, ahora solo falta decirle a nuestra Arch dentro del container, que permita conexiones en el /etc/hosts.allow, quedando así:

sshd:172.26.0.0/255.255.255.240
httpd:ALL

Ahí vemos que hacemos que nuestro servicio ssh sea accesible solo desde la red local, en nuestro caso 172.26.0.X (el tuyo quizas 192.168.1.X) y tambien aprovechamos para decirle que el servidor httpd será accesible desde cualquier sitio de internet.

Ahora ya solo falta iniciar el servidor OpenSSH en nuestro container, y decirle que lo carge siempre en el inicio añadiendo ssh en la sección DAEMONS de nuestro rc.conf, lo haremos del siguiente modo:

[[email protected] ~]$ sudo /etc/rc.d/sshd start
[[email protected] ~]$ sudo vim /etc/rc.conf
DAEMONS = (network sshd)

Parte III (Servidor web Cherokee)

Ahí es donde vamos a configurar nuestro servidor web basado en Cherokee, esta vez no hablo de apache, si no de cherokee, un servidor web realmente muy ligero y rápido.
Recordemos que estamos siempre dentro de nuestro conatiner y que lo que estamos instalado lo hacemos dentro del container, así pues, no lo hacemos en la máquina REAL.
Vamos a instalar nuestro cherokee, para hacerlo deberemos usar pacman e instalarlo dentro del container, así que nos aseguramos de estar dentro de él y luego hacemos lo siguiente:

[[email protected] ~]$ sudo pacman -S cherokee python2 ffmpeg rrdtool

Una vez instalado cherokee, vemos que instalamos python, en su versión 2, ya que la 3 da porblemas con el configurador de cherokee, el llamdo cherokee-admin.

Ahora vamos a configurar cherokee, lo haremos usando cherokee-admin, del siguiente modo:

[[email protected] ~]$ sudo cherokee-admin -b IP_MAQUINA_REAL -u

Luego, desde la máquina real, nos conectamos a la IP del container, al puerto 9090, así pues, desde allí podremos acceder al configurador de cherokee.

Parte FINAL:

Bien, ya hemos configurado nuestro container con un servidor OpenSSH y uno WEB con Cherokee, hemos entrado en el servidor por ssh, con la típica ssh -p puerto [email protected]_container. Vamos, que ya nos movemos por los containers como si fueran solo otras máquinas, así que vamos a mostrar un poco la potencia de estos containers, que la mostraré en un próximo artículo.

Actualizar el container desde el exterior: sudo mkarchroot -u /mnt/CONTAINER
Actualizar el container desde el interior: sudo pacman -Syu
Insertar el script de cherokee dentro de DAEMONS para que se inicie al arrancar el sistema.

Posibles errores:
Al acceder por SSH, PTY Allocation request failed on channel 0: Se trata de un error frecuente si no se ha montado /dev/pts.
Al hacer un «w» dentro del conatiner me dice que no hay proc, queda claro! Hay que asegurarse porque no se monta /proc y si lo hacen el resto, si no es así, el problema probablemente será del rc.sysinit del container.

Categorías
Blog GNU/Linux Informática Linux Containers Seguridad Inormática Sistemas Operativos Vritualización

Linux Containers (LxC, zonas/jaulas) en ArchLinux

Datacenter Saludos!

En esta entrada voy a hablar sobre Linux Containers, algunos os preguntareis de que se trata, otros, que habreis trabajado con Solaris, ya se imaginarán que hablamos de zonas y otros, que han trabajado con OpenVZ, tambien tendrán una idea de lo que estamos hablando.

Pero ¿porque usamos Linux Containers, de ahora en adelante LxC, y no usamos otras alternativas como las zonas de Solaris o OpenVZ, para servidores virtuales? La respuesta es que LxC está incluido en el kernel de linux desde hace ya unas cuantas versiones y además, no vamos a usar zonas de solaris, porque tenemos el servidor con linux, no con Solaris.

Sigamos, ¿Que queremos hacer para usar LxC ?
Pues bien, para responder a esta pregunta, primero debemos saber exactamente que es la virtualización y que son las jaulas o zonas.

VIRTUALIZACIÓN:
Vamos a definir la Virtualizació, por lo que la definción de la wikipedia nos va de lujo:

En informática, virtualización se refiere a la abstracción de los recursos de una computadora, llamada Hypervisor o VMM (Virtual Machine Monitor) que crea una capa de abstracción entre el hardware de la máquina física (host) y el sistema operativo de la máquina virtual (virtual machine, guest), siendo un medio para crear una versión virtual de un dispositivo o recurso, como un servidor, un dispositivo de almacenamiento, una red o incluso un sistema operativo, donde se divide el recurso en uno o más entornos de ejecución.
Esta capa de software (VMM) maneja, gestiona y arbitra los cuatro recursos principales de una computadora (CPU, Memoria, Red, Almacenamiento) y así podrá repartir dinámicamente dichos recursos entre todas las máquinas virtuales definidas en el computador central. De modo que nos permite tener varios ordenadores virtuales ejecutándose sobre el mismo ordenador físico.

Bien, ya vemos las posibilidades de la virtualización, usar una máquina dentro de otra, esto si, tiene una pega, habitualmente consume muchos recursos del sistema, pero las máquinas están totalmente blindadas unas de otras.

JAULAS:
Las jaulas, es el ya conocido chroot, es decir, cambiar el directorio raíz del sistema y conseguir así, que a partir de un proceso, el resto se ejecuten con un directorio raíz diferente al del sistema.

Con esto, conseguimos que las aplicaciones enjauladas dentro de un chroot, no tengan acceso al resto del sistema que está fuera del entorno enjaulado.
Es decir, imaginemos que no podemos acceder a nuestro sistema linux, arrancamos desde un live-cd, porque queremos arreglar el grub, pero claro, al intentar reinstalar el grub, no se reinstalará en el sistema, si no que se reinstalará en el CD y esto es imposible. Así, que lo que hacemos, es crear un directorio dentro del cual montaremos todo nuestro disco duro, para poder acceder al grub. Pero esto no es todo, luego necesitaremos que grub crea que hemos arrancado desde nuestro disco duro, así que lo que haremos será hacer un chroot al directorio donde montamos nuestro disco duro, así el sistema verá que la raíz ya no es el CD-ROM, si no que es el directorio donde montamos el disco duro, por ejemplo /mnt/disco-duro.

También existen muchas otras aplicaciones, como enjaular el ssh, así, si un usuario accede por ssh en nuestro equipo y lo enjaulamos en el directorio /home, para él, este será el directorio raíz, no pudiendo moverse mas hacia atrás en la estructura de directorios.

¿Problemas?
Pues sí, realmente no es muy difícil para un usuario avanzado saltarse las protecciones, además de ser dificil de administrar, ya que el usuario enjaulado, no tendrá muchas de las librerías necesarias, y deberán ser duplicadas una por una, en cada jaula.

CONTAINERS:
Los containers son un sistema de virtualización de nivel del sistema, para ejecutar diferentes sistemas separados dentro de un mismo host (sistema principal). LxC no proporciona una máquina virtual, si no un entorno virtual, que tiene sus procesos y entornos de red. Es un entorno similar a una jaula, pero ofrece mucho mas aislamiento.
LxC está integrado en el kernel de linux, de la versión 2.6.29 en adelante y permite el aislamiento y la configuración miediante cgroups.

CGROUPS:
Se trata de una funcionalidad del kernel linux, que permite limitar y separar cuentas en cuanto a uso de memoria, CPU, disco, E/S y además priorizar.

A método de resumen, sabemos que LxC, nos permite gestionar una zona (contenedor) y hacerlo muy detalladamente con el uso de cgroups.

Así pues, sigamos y veamos que se necesita para poder crear un contenedor con LxC.
Primero de todo decir que vamos a configurarlo desde una distribución de linux llamada ArchLinux, no lo voy a hacer con Ubuntu, ya que pienso que con Archlinux puede ser mucho mas didáctico, así no nos liamos con scripts raros y vamos viendo paso a paso, como se configuran los containers.

CONOCIMIENTO DEL SISTEMA:
Para administrar cualquir sistema operativo gnu/linux, es imprescindible conocerlo bien, así pues, debemos de saber algunas cosas importantes sobre la distribución Archlinux, que la hacen distinta a una debian based, como con las que estamos acostumbrados a trabajar en este blog.
Así pues veamos los ficheros principales de configuración del sistema:

/etc/rc.conf #Fichero de configuración de inicio del sistema, se define la red, las locales, módulos, demonios …
/etc/rc.d/ #En este directorio es donde suelen encontrarse los scripts de inicio, sería el equivalente al /etc/init.d de Debian.
/etc/rc.sysinit #Este fichero inicializa los primeros dispositivos del ordenador, tales como la memoria swap, los discos, …
/etc/conf.d/bridges #En este fichero se definen las interficies de red tipo «puente» bridge.

Por el resto, los ficheros de configuración son los mismos que un sistema debian based, en el directorio /etc podemos encontrar el fstab y otros muchos fichero de configuración.
Un ejemplo para reiniciar la red, sería el siguiente:

[[email protected] ~]$ sudo /etc/rc.d/network restart

Vease en este ejemplo que he instalado y configurado el sudo, ya que la instalación por defecto de Arch, usa la cuenta root y la mantiene activada.
Así pues, ahora que hemos dado unas pinzeladas del sistema al que nos enfrontamos, vamos ya a configurar un container de Linux.

PRIMEROS PASOS PARA LOS LxC:
Debemos asegurarnos ante todo, que nuestro kernel, tiene soporte para LxC, desde la versión 2.6.29, que llevan soporte y en la versión 2.6.35, aun no existía soporte para dispositivos udev, con lo que deberemos poblar manualmente el directorio /dev, de la máquina que hay dentro del container.
Para no liarnos entre la máquina anfitrión y la máquina virtualizada/enjaulada, voy a llamar máquina HOST, a la máquina real y máquina CONTAINER a la máquina enjaulada.
Para ver si tenemos este soporte en el kernel, lo que haremos es descomprimir el fichero «.config» con la configuración del kernel de Arch, en una instalació por defecto.

[[email protected] ~]$ zcat /proc/config.gz .config

Este comando, descomprimirá y creará un fichero en el directorio donde lo ejecutemos, con las opciones del kernel, que vienen activadas en la instalación por defecto, es decir, las nuestras. Debemos asegurarnos de que están estas:

CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_CGROUP_SCHED=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_MM_OWNER=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_NET_CLS_CGROUP=y
CONFIG_SECURITY_FILE_CAPABILITIES=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y

Puede ser, si usamos un kernel no del todo nuevo, que la última no esté, pero no pasa nada, ya que vamos a poblar el /dev de CONTAINER, manualmente.

Bien, ahora toca montar el «control group filesystem» o cgroup, para ello lo haremos manualmente y luego lo añadiremos al fstab, para que lo cargue en cada inicio de la máquina.

HOST:
[[email protected] ~]$ sudo mkdir /cgroup
[[email protected] ~]$ sudo mount -t cgroup none /cgroup

Y en el /etc/fstab

HOST:
none /cgroup cgroup defaults 0 0

Ya tenemos el control group montado, si entramos en el directorio /cgroup, deberemos ver un montón de ficheros con muchas características del sistema que luego, nos pueden servir para parametizar nuestro servidor CONTAINER.

Recordatorio: Cuando digo servidor CONTAINER, me refiero a la máquina enjaulada, ya que será dentro de ella, donde vamos a correr nuestro servidor web, openssh, ftp o lo que sea.

Sigamos, ahora vamos a configurar la red, concretamente vamos a crear un puente con el que se comuniquen la interfaz eth0, tanto de la máquina CONTAINER, como de la máquina HOST.
Lo primero que debemos asegurarnos, es de tener el fichero bridge-utils instalado, si no es el caso, lo instalamos con el siguiente comando:

HOST:
[[email protected] ~]$ sudo pacman -S bridge-utils

Valga decir, que antes de instalar este paquete, nos tenemos de asegurar de no haber modificado el fichero /etc/bridge.conf, ya que si no fallará la instalación del paquete, así que si existe, lo borramos.

Ahora una vez instalado el paquete bridge-utils, toca editar el fichero /etc/bridge.conf de la siguiente forma:

HOST:
bridge_br0="eth0"
config_br0="brctl setfd br0 0"
BRIDGE_INTERFACES=(br0)

Es importante destacar que br0 será el interfaz puente y que eth0 es nuestro interfaz habitual de acceso a la red, que con el brctl setdf br0 0, nos aseguramos de que podamos usar DHCP e intentaremos que no nos devuelva un "time out" de espera de dirección IP.

Ahora modifiquemos el fichero /etc/rc.conf para añadir nuestra interfaz puente

HOST:
eth0="eth0 up"
br0="dhcp"
INTERFACES=(eth0 br0)

Con esto lo que hacemos es levantar la interfaz eth0, asiganar dirección mediante DHCP a br0, que saldrá por eth0, ya que en realidad es un puente.

Quiero destacar que la parte de la configuración de la red, es algo complicada para una persona que no haya trasteado mucho con dispositivos de red, no así si soys usuarios de aparatejos tipo fonera y demás 🙂
Tambien quiero que la gente que no usa DHCP, entienda que la forma de configurarla es algo distinta, pero si entienden el concepto de un dispositivo puente, no deben de tener problemas a la hora de adaptarlo a sus necesidades.

FIN DE LA PRIMERA FASE:
Llegados ya a este punto y ya que no estamos probando todo esto, en nuestro servidor de producción, sería bueno reiniciar la máquina y asegurarse que la red funciona correctamente, que no existen errores y que todo se aplica correctamente.
Así que si todo ha salido bien, debeis de tener estos dispositivos en la salida del ifconfig:

HOST:
[[email protected] ~]$ ifconfig
br0 Link encap:Ethernet HWaddr 00:04:75:FF:B5:A9
inet addr:172.26.0.11 Bcast:172.26.0.15 Mask:255.255.255.240
inet6 addr: fe80::204:75ff:feff:b5a9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:138356 errors:0 dropped:0 overruns:0 frame:0
TX packets:63751 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:101692273 (96.9 Mb) TX bytes:9558753 (9.1 Mb)

eth0 Link encap:Ethernet HWaddr 00:04:75:FF:B5:A9
inet6 addr: fe80::204:75ff:feff:b5a9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:151098 errors:0 dropped:0 overruns:1 frame:0
TX packets:73193 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:121303206 (115.6 Mb) TX bytes:10622420 (10.1 Mb)
Interrupt:22 Base address:0x2800
[[email protected] ~]$ ping www.google.com
PING www.l.google.com (74.125.230.84) 56(84) bytes of data.
64 bytes from 74.125.230.84: icmp_seq=1 ttl=54 time=22.9 ms

Vamos a ver algunas cosas:

  1. La dirección IP no la coge eth0, si no br0
  2. Las direcciones MAC de los dispositivos son los mismos
  3. Responde perfectamente los pings a google
  4. Si el paso 3 da errores, debemos de hacer las modificaciones necesarias en los ficheros /etc/rc.conf y /etc/bridges.conf
  5. Para aplicar los cambios, basta con hacer un sudo /etc/rc.d/network restart.
  6. Si aun así, no cogemos dirección IP, podemos probar a cogerla manualmente mediante el comando «sudo dhcpd br0»
  7. Luego, probamos que vaya y volvemos a reiniciar.

Estos son los pasos para asegurarnos del correcto funcionamiento, algunos de ellos como veremos mas adelante, los podremos aprovechar para la máquina CONTAINER.

En caso de que no consigamos que nos devuelva una IP la interfaz br0 y nos hayamos asegurado de que lo hemos hecho correctamente, puede deberse a este bug, del fichero /etc/rc.d/network.

FASE DOS:
Bien, ya tenemos todo preparado para empezar … sí sí, para empezar, ah! no advertí que sería un toston, bueno, era para mejorar el tiempo en mi página (broma) xD.

Primero de todo vamos a instalar las utilidades lxc que nos tiene Arch. Bueno, en realidad ella no las tiene, las tienen los usuarios de Arch, es decir, que no están el los repos oficiales.
Esto no es ningún inconveniente, ya que en Arch, tenemos lo que llamaríamos repositorios de terceros, los llamados AUR (Archlinux User Repository), los cuales se pueden manejar, entre otras muchas herramientas con yaourt.
Así que vamos a ello, primero nos aseguramos que tenemos instaladas las herramientas de desarrollo, lo podemos hacer con pacman de la siguiente forma:

HOST:
[[email protected] ~]$ sudo pacman -S base-devel

Luego, vamos a modificar los repositorios de pacman, para añadir uno con el paquete «yaourt», así que editamos el fichero /etc/pacman.conf y añadimos esto:

HOST:
[archlinuxfr]
Server = http://repo.archlinux.fr/i686

No hace falta decir que cambiaremos i686 por lo que sea, dependiendo de nuestra arquitectura.

Luego instalamos yaourt de la siguiente forma:

HOST:
[[email protected] ~]$ sudo pacman -S yaourt

Ya tenemos yaourt instalado, así que ahora ya podemos usar este administrador de repositorios de usuarios, el qual usa las mismas opciones que pacman, e instalar las utilidades LxC, de la siguiente forma:

HOST:
[[email protected] ~]$ sudo yaourt -S lxc

Esto nos va a instalar las utilidades de lxc, esto sí, compilando el paquete, cosas de la magnífica Arch .

FASE 2.1:  (mkarchroot)
Esta fase es muy importante, ya que en ella vamos a empezar a hablar de máquina CONTAINER, de lo que queremos hacer con ella y de su configuración.

Bien, ahora lo que queremos hacer, es crear una máquina virtual, una zona o un contenedor, como lo querais llamar, pero ¿ que significa esto ?
Significa que vamos a copiar dentro de un directorio, un sistema mínimo completo.


En esta imágen puede verse una jaula, y que dentro existe otra estructura, como se de otra máquina se tratase.

Bueno, manos a la obra, como metemos toda una máquina dentro de otra ?
Existen varias opciones o scripts, nosotras vamos a usar uno llamado mkarchroot. Este script, lo que hace es instalar dentro del directorio que le digamos, una copia de una actualización base de Archlinux, a través de pacman.
Yo, la primera vez que lo leí pensé, no puede ser, pero sí y funciona a la perfeccción, así que llegado a este punto vayamos a probarlo.

Primero nos aseguramos de tener mkarchroot instalado, si no lo está, lo instalamos, este script, está en el paquete devtools, así que si tenemos base-devel, lo deberíamos tener instalado, si no es así, lo instalamos.

Ahora, toca crear un directorio donde tendremos nuestra máquina virtualizada, la llamada CONTAINER, así que vamos a crearlo y luego le diremos que instale el sistema allí, de esta forma:

HOST:
[[email protected] ~]$ cd /mnt
[[email protected] ~]$ sudo mkdir CONTAINER
[[email protected] ~]$ sudo mkarchroot /mnt/CONTAINER/ base base-devel

Con esto, veremos como empieza a instalase un sistema base completo en nuestro directorio e incluso si queremos, le podemos decir de donde va a coger la configuración del pacman.

Una vez finalizado, podemos realizar varias cosas, pero no estaría de mas, hacer un chroot y comprobar que la red funciona, que seguro que no, así que vamos a hacerlo y solucionarlo del siguiente modo:

HOST:
[[email protected] ~]$ cd /mnt
[[email protected] mnt]$ sudo chroot CONTAINER/
HEMOS ENTRADO EN CHROOT:
[[email protected] /]# sudo dhcpd eth0
[[email protected] /]# ping www.google.com
[[email protected] /]# ping 74.125.230.80
[[email protected] /]# exit
[[email protected] mnt]$ sudo cp /etc/resolv.conf /mnt/CONTAINER/etc/resolv.conf
[[email protected] mnt]$ sudo cp /etc/pacman.conf /mnt/CONTAINER/etc/pacman.conf
[[email protected] mnt]$ sudo cp /etc/pacman.d/mirrorlist /mnt/CONTAINER/etc/pacman.d/mirrorlist
[[email protected] mnt]$ sudo chroot CONTAINER/
[[email protected] /]# sudo dhcpd eth0
[[email protected] /]# ping www.google.com
[[email protected] /]# exit

Si hacemos o no esto, no es importante, solo sirve para que si luego falla, una vez usemos los LxC, sepamos a que puede deberse, que son los DNS, el DHCP y si falla el PACMAN, a sus repos o lista de mirrors.

Ahora, para completar la jaula, debemos poblar el directorio /dev, ya que no se puede usar UDEV, así que vamos a copiar el script de a continuación en el directorio /mnt/CONTAINER.

HOST:
#!/bin/bash
ROOT=$(pwd)
DEV=${ROOT}/dev
mv ${DEV} ${DEV}.old
mkdir -p ${DEV}
mknod -m 666 ${DEV}/null c 1 3
mknod -m 666 ${DEV}/zero c 1 5
mknod -m 666 ${DEV}/random c 1 8
mknod -m 666 ${DEV}/urandom c 1 9
mkdir -m 755 ${DEV}/pts
mkdir -m 1777 ${DEV}/shm
mknod -m 666 ${DEV}/tty c 5 0
mknod -m 600 ${DEV}/console c 5 1
mknod -m 666 ${DEV}/tty0 c 4 0
mknod -m 666 ${DEV}/full c 1 7
mknod -m 600 ${DEV}/initctl p
mknod -m 666 ${DEV}/ptmx c 5 2
[[email protected] /mnt/CONTAINER/]$ chmod u+x script.sh
[[email protected] /mnt/CONTAINER/]$ sudo ./script.sh

Bueno, ya hemos configurado un poco nuestra máquina CONTAINER, pero en realidad, no hemos configurado el container, si no simplemente el contenido, he aquí la diferencia entre usar jaulas (chroot) y LxC, que nos abre un mundo de opciones de configuración.

FASE 3 (Configuración de los Containers):
Aquí vamos a explicar como configurar nuestro container para tener un mínimo control sobre él, como CREAR el container y como jugar un poco con él.
Primero de todo, quiero advertir, que el orden a seguir es el siguiente:

  1. Primero se crea la configuración de un container.
  2. Luego se crea un container
  3. En este momento podemos cambiar la configuración de la máquina que hay dentro del container, pero NUNCA, cambiar la configuración del Container.
  4. Si queremos cambiar la configuración, es una buena idea eliminar el container, modificar la configuración y volverlo a crear.

Todo esto puede resultar confuso, pero ya veremos que no es lo que parece y que administrar containers es realmente muy simple, incluso mas de lo que nos ha costado llegar a este punto de esta explicación.

Vamos a crear el fichero de configuración del container, este fichero lo podemos nombrar como nos interese y ponerlo donde mas rabia nos de, por ejemplo
/etc/lxc.container1
/etc/lxc.container2
hasta …
/mnt/CONTAINER/etc/lxc.container
/mnt/CONTAINER2/etc/lxc.container

Yo me decantaré por esta última opción, ya que como solo usuaremos un container, pues no será muy difícil de administrar.
Así que vayamos al grano y creamos un fichero llamado /mnt/CONTAINER/etc/lxc.CONTAINER, con el siguinete contenido:

lxc.utsname = CONTAINER
lxc.mount = /mnt/CONTAINER/etc/fstab
lxc.rootfs = /mnt/CONTAINER/
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.hwaddr = 10:14:85:0F:C5:B9
lxc.network.ipv4 = 0.0.0.0
lxc.network.name = eth0
lxc.tty = 1

Vamos a explicar este fichero linea por linia:

  1. lxc.utsname, es le nombre que le damos a la zona/container/jaula.
  2. lxc.mount, será la ruta al fichero fstab, donde se montarán los sistemas de ficheros dentro del container.
  3. lxc.rootfs, es la dirección del directorio raíz del container.
  4. .network.type / .network.flags / .network.link, son las configuraciones de la red
  5. .network.hwaddr, es importante poner una MAC cualquiera al dispositivo de red, sobretodo si usamos DHCP.
  6. .network.ipv4, deberemos ponerlo a 0, si usamos DHCP, para que se inicie mas tarde.
  7. .network.name, es el nombre del dispositivo de red, debido a las configuraciones del bridge, debe ser eth0.
  8. lxc.tty, dice el número de ttys, es decir, de «Local Virtual Consoles», para poder acceder luego desde fuera, sin usar la red, por si esta no se monta o no tenemos servidor ssh.

Creo que ha quedado mas o menos bien explicado, recuerdo que la parte de la red, depende mucho de vuestra configuración y que el fstab, definido en lxc.mount, aun está por configurar, así que manos a la obra y configuremos el fstab.
Para ellos ediatmos este fichero en la máquina CONTAINER, que está en /mnt/CONTAINER/etc/fstab:

CONTAINER
none /mnt/virtual/dev/pts devpts defaults 0 0
none /mnt/virtual/proc proc defaults 0 0
none /mnt/virtual/sys sysfs defaults 0 0
none /mnt/virtual/dev/shm tmpfs defaults 0 0

Aquí podemos ver que la máquina CONTAINER, montará el FS /dev/pts, /proc, /sys y /dev/shm.

Ahora nos pondremos en el directorio /mnt/CONTAINER/dev y crearemos un diposistivo de carácteres, para la TTY que hemos dicho que usaría el container:

CONTAINER:
[[email protected] /mnt/CONTAINER/dev]$ sudo mknod -m 666 /dev/tty1 c 4 1

Vamos bien, de momento ....

Pues sí, la cosa ya empieza a avanzar, ¿Que nos falta? – Pues bien, falta asegurarse que la máquina que tenemos en la jaula puede arrancar virtualizada dentro de un container, así que vamos a vaciarla de «mierda» o dicho de otra forma, de scripts que no vamos a usar para nada y que solo pueden hacer que nuestra máquina se bloquee.
Vamos a modificar el script de inicio de la máquina container, que podemos encontrar en /mnt/CONATINER/etc/rc.sysinit, para que quede de este modo.

CONTAINER:
#!/bin/bash
# Whatever is needed to clean out old daemon/service pids from your container
rm -f $(find /var/run -name '*pid')
rm -f /var/lock/subsys/*
# Configure network settings
## You can either use dhcp here, manually configure your
## interfaces or try to get the rc.d/network script working.
## There have been reports that network failed in this
## environment.
route add default gw 192.168.10.1
echo > /etc/resolv.conf search your-domain
echo >> /etc/resolv.conf nameserver 192.168.10.1
rm -f /etc/mtab
touch /etc/mtab

De este script, solo debemos modificar la ruta del gateway, que yo uso la 172.26.0.2, pero vosotros seguramente usareis alguna del estilo 192.168.1.1 o 192.168.0.1.
Como podemos ver, se trata de un script muy simple, que nos evitará muchos dolores de cabeza, luego, poco a poco, ya podreis ir añadiendo lineas.

Ahora toca modificar el fichero /mnt/CONTAINER/etc/rc.conf y asegurarse de que están estas lineas, las otras, se pueden dejar igual, en principio:

CONTAINER:
MODULES=()
eth0="dhcp"
INTERFACES=(eth0)
DAEMONS=(network)

Así pues, ahora ya si que lo tenemos todo, o casi todo preparado, como mucho, podemos modificar el fichero inittab de la máquina CONTAINER, para que quede igual, o parecido al siguiente:

CONTAINER:
id:3:initdefault:
rc::sysinit:/etc/rc.sysinit
rs:S1:wait:/etc/rc.single
rm:2345:wait:/etc/rc.multi
rh:06:wait:/etc/rc.shutdown
su:S:wait:/sbin/sulogin -p
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux

Pues ya está todo listo, así que entremos en la siguiente fase.

ULTIMA FASE:
Bueno, por fin, ya lo tenemos todo a punto y los hemos repasado, así que vamos a crear nuestros LxC, usando las utilidades de lxc que hemos instalado con yaourt.

Crear Container:
lxc-create -f /mnt/CONTAINER/etc/lxc.CONTAINER -n CONTAINER
Ahí veremos que se ha creado una máquina llamada CONTAINER

Iniciar Container:
lxc-start -n CONTAINER
Ahí tenemos que ver como inicia la máquina CONTAINER, debe de ser rápido, ya los scripts de inicio que tenemos son muy pobres. En este paso nos puede dar algún problema la red, que no se inicie.

Parar Container:
lxc-stop -n CONTAINER
Ahí veremos como se para el container, podemos ver los container con top o htop para verlo mas gráfico.

Entrar en TTY de un Container:
lxc-console -n CONTAINER
Ahí debe pedir LOGIN y PASS del container, puede que la pass de root esté en blanco, si no la tenemos, siempre podemos parar la máquina virtual, hacer un chroot a la jaula y cambiar la password del root, para luego iniciar la máquina y entrar por TTY.

Eliminar un Container:
lxc-destroy -n CONTAINER
Esto elimina el container, con lo que deberemos volverlo a crear con lxc-create.

Con esto finalizo esta primera parte de la creación de LxC, en esta primera entrega, solo hemos creado un container, y este, no es nada mas que una máquina virtual, pero imaginad la potencia, cuando a través de un lxc-console, entre en esta máquina, instale el servidor web cherokee, lo configure y tenga un servidor web, corriendo dentro del container, donde puede administrar los recursos que le doy, memoria, disco, prioridad …. y además, con la seguridad de que no es un sistema real y que un desbordamiento de buffer, por ejemplo, no conseguiría root en nuestro equipo, solo en la máquina virtual.

Problemas:
Podemos tener varios problemas, aquí voy a ir poniéndolos, a medida que me vayais contando vuestras dudas en los comentarios

Problemas con la RED: Es frecuente, tener problemas de configuración de la red, algunas veces, deberemos iniciar el conatiner y veremos que no tenemos acceso a la red, que se levanta la interfaz, pero no coge IP, esto es debido al bug que anteriormente dije, y se puede evitar aumentando el time out del cliente DHCPD, así pues, quizas la primera vez que iniciemos la máquina, debemos conecatar con lxc-console -n CONTAINER y lanzar a mano un dhcpd eth0.