Entre otros muchos usos de Virtualbox, lo usamos como entorno de desarrollo que sean replicas de los de producción y que nos sirven para desarrollo offline para desarrolladores. Con el tiempo hemos ido optimizándolas de modo que mantenemos los archivos y repositorios, configuraciones, logs, etc en carpetas “locales” del host que se montan y sirven desde la maquina virtual. Es una estupenda alternativa a usos de cualquier versión de xAMP ya sea en Windows o Mac sobretodo porque emula a la perfección el entorno real de desarrollo, nos permite usar los mismos archivos de configuración de servidores, formato de rutas, etc. En otro post entraremos en detalles, pero lo configuramos con dos interfaces de red, una poder referirnos a ellos siempre en la misma dirección local y otro para enrutar el tráfico de salida.
Virtualbox requiere* (el asterisco es porque en realidad no pero hay servicios vitales como el de hora que de otro modo no funcionan bien) instalar unas “guest-additions” especificas del entorno virtualizado. El problema surge de que muchas distribuciones (como Debían en nuestro caso) incluyen una versión de las mismas que generalmente suelen estar obsoletas respecto a las que podemos instalar desde la última versión de Virtualbox y pero, acaban interfiriendo en su correcto funcionamiento si se instalan por duplicado.
No entraremos en detalles de como hacerlo, al haber numerosos post al respecto pero por nuestra experiencia recomendamos:
- no instalar las versiones de los repositorios de Debian (o seguramente ninguna distribución)
- si ya lo has hecho desintalalas… apt-get remove vbox-additions***. Las instaladas desde el CD se pueden desinstalar con el mismo instalador (ver comentario posterior) con “sh ./VBoxLinuxAdditions.run uninstall”
- en nuestro caso nos molestamos ademas en hacer un “blacklist” a esos paquetes para evitar que se instalen por error:
echo "virtualbox-guest-utils hold" | dpkg --set-selections echo "virtualbox-guest-x11 hold" | dpkg --set-selections echo "virtualbox-guest-dkms hold" | dpkg --set-selections
- una vez eliminados desde el menu de la maquina en VirtualBox “Insert Guest Additions”
- montar el cdrom si fuera necesario. Según el entorno “mount /dev/cdrom /mnt/cdrom”
- antes de instalar tal vez tengas que comprobar e instalar algunos paquetes (DKMS, etc). Puedes ver info por distribución en //www.virtualbox.org/manual/ch04.html#idp55231856
Como nuestras VMs son servidores que procuramos sean los más compactos posibles para distribución y carga en la maquina que los ejecuta, no nos convencía que las guest-additions instalar numerosas librerias para la X e investigando un poco averiguamos finalmente una opción poco documentada de usar un flag –nox11 al instalar. Así una vez en el directorio con los scripts del cdrom virtual ejecutar:
sh ./VBoxLinuxAdditions.run --nox11
Que debería terminar con el mensaje:
...Could not find the X.Org or XFree86 Window System, skipping.
Ha sido una de estas pequeñas cosas en la administración de sistemas que nos ha traído de cabeza durante algún tiempo, así que nos ha parecido interesante documentarla en nuestro blog.
En Linux, es una máxima que dado que “/tmp” es un directorio con permisos de escritura muy flexibles (=inseguros) debería montarse siempre con el flags “nosuid,noexec” para impedir cambios de usuario y ejecución de binarios en ese directorio, práctica habitual de muchos exploits de PHP y otros lenguajes. En realidad los expertos dicen que no es en absoluto suficiente con eso, pero al menos es una primera práctica de “buenas costumbres” de seguridad.
El problema surge cuando algunas partes del sistema si que quieren ejecutar desde esas particiones. El caso más obvio es el de aptitude en Debian que al instalar ejecuta por ejemplo, scripts de configuración. Buscando la solución más habitual es la de hacer un remount de tmp para que durante “un rato” permita execs añadiendo un archivo a “/etc/apt/apt.conf.d/” con algo como:
DPkg::Pre-Invoke
{
"mount -o remount,exec /tmp";
"mount -o remount,exec /var/tmp";
};
DPkg::Post-Invoke
{
"mount -o remount /tmp";
"mount -o remount /var/tmp";
};
Bien, en sistemas virtualizados de contenedores Linux como los que usamos nosotros y en OpenVZ sobre Debian en particular, el sistema de particiones se complica un poco al realizarse desde la maquina host como scripts que se ejecutan durante el arranque de la maquina. Hasta hace poco hacíamos lo que se conoce como un “bind” mount (algo así como un mount virtual de otra ruta) al /tmp de la maquina limitando esos permisos (noexec,nosuid) o en otros casos montando el /tmp en memoria creando una entrada tmpfs en el script de la maquina XXX.mount
El problema, en ambos casos, es que eso impide hacer remount una vez dentro de la maquina virtual, pues recibiremos un “Permission denied” al intentarlo dado que en realidad es el host quien monto la partición y esta “por encima” del ámbito del sistema virtual.
Para resolverlo hasta ahora hemos encontrado dos soluciones que estamos poniendo a prueba. La primera sirve si el /tmp lo estás montando a una partición en tmpfs (memoria) y consiste simplemente en crear la entrada dentro del /etc/fstab virtualizado (en los contenedores es normal que esté vacío pues su sistema de archivos se genera “fuera”), en este caso algo como :
tmpfs /tmp tmpfs noexec,nosuid 0 0
De este modo la solución anterior de remontarlo funciona correctamente y puede servir.
La segunda solución, que en realidad ya hemos implantado siempre pero que es necesaria cuando queremos seguir montando desde el host y/o a una unidad no desmontable es cambiar la ruta desde la que el apt crea esos temporales (ver //wrightsolutions.wordpress.com/2010/01/11/securing-tmp-and-noexec-apt-considerations/).
APT
{
ExtractTemplates
{
TempDir "/ruta/a/otro/tmp";
};
};
Esa nueva ruta, como no tiene que existir y residir en alguna partición con permisos de ejecución. Esta es la solución que hemos implantando en nuestro caso en todas las maquinas.