martes, 31 de agosto de 2010

"Adelgazando" los discos de VirtualBox

Siempre que tengo un ratito para investigar , uso Virtualbox como plataforma de virtualización de prueba. Hace poco me quedé repentinamente sin lugar en el disco de mi maquina y cuando empezé a buscar los "culpables" me encontré con archivos .VDI enormes.
Los discos que creo con VirtualBox son de expansión dinamica y no con tamaño predefinido de manera que van creciendo a medida que instalamos. El problema d esto es que si usamos el mismo "disco" para realizar varias instalaciones , nos vamos a encontrar que el tamaño sigue aumentando ya que los datos anteriores , si bien no estan tampoco se borran. Bueno pasemos a darle una dieta!

Virtualbox trae un comando para compactar los discos pero ejecutado de una , hizo el proceso pero nunca se achicó el disco. En este caso lo voy a hacer para una instalación de Windows.
Buscandó por ahi encontré una utilidad de Windows llamada sDelete de Microsoft , que se puede descargar desde acá la cual nos permite escribir todos zeros en las partes libres del disco.

Yo intenté hacerlo desde la misma instalación pero se me colgó y se terminó rompiendo la instalación, por ende la segunda vez que lo hize , usé un LiveCD llamado Hiren que contiene un LiveXP, bajé la utilidad sDelete y ejecuté

sdelete -c C: (ahí va la unidad que quieren achicar)

Después de llegar al 100% apagué la maquina y ahí si ejecuté el siguiente comando que trae VirtualBox

VBoxManage.exe modifyhd "disco.vdi" --compact


El comando VBoxManage está dentro de la carpeta de instalación de VirtualBox y se ejecuta desde la linea de comandos.

Antes de empezar este trabajo el disco tenía un tamaño de 12.1 Gb y después de realizar estos 2 procesos quedó de 5,2Gb menos que la mitad!

Apenas tenga un rato anexo la forma de hacer lo mismo en Linux

jueves, 26 de agosto de 2010

DynDns y Ez-Ipupdate detrás de un Firewall

Hace un tiempito que estoy probando como firewall un dispositivo Mikrotik y la verdad que si bien no exploré al 100% estoy muy conforme con su funcionamiento. En Mikrotik existe una forma de ejecutar script con la cual se puede actualizar DynDns y otros , pero en mi caso quería saber como hacer funcionar Ez-ipupdate detrás de un firewall. Vengo usando hace tiempo Ez-ipupdate y al momento de instalarlo nos pregunta que interfase vamos a "escuchar", en este caso la IP publica la va a tener el Mikrotik por ende no funcionaría. Googleando un poco encontré este script echo el cual voy a copiar obviando algunas partes para que sea más cortito y visible. Como primera cosa tenemos que hacer un apt-get install ez-ipupdate y en la parte de configuración lo ponemos manualmente.
Creamos nuestro script en el path que queremos en mi caso vim /usr/local/bin/DynDnsUpdate

#!/bin/bash

## *** version 0.01 *** Works as designed :-)
## *** Usage ***
#add to crontab 5 * * * * /bin/sh /path-to-script/DynDnsUpdate.sh

##### Config Section
## Valid service types: null ezip pgpow dhs dyndns dyndns-static dyndns-custom ods tzo easydns easydns-partner gnudip justlinux dyns hn zoneedit heipv6tb
SERVICETYPE=dyndns

## Users name used to login to your Dyndns provider.
USER=NombreUsuario

## The users password
PASSWD=Contraseña

## The Dyndns host name you have defined on your Dyndns provider server.
DYNHOSTNAME=host.dyn-dns.com

## The directory where we will write a pid file.
PIDDIR=/tmp

## The name of our pid file.
PIDFILE=ez-ipupdate.pid

## The directory where we want to write a cache file
CACHEDIR=/tmp

## The file used for caching the ipaddress. If you are going to run more instances of this
## script on the same box, then change the cache file name below to be unique for each instance of the script.
CACHEFILE=ez-ipupdate.cache
##Log directory
LOGDIR=/tmp

## Log file
LOGFILE=dyndns-up-2-date.log

##### End Config Section

##### Best you don't mess with this line if you don't know what you are changing
IP=`wget --quiet -O - http://checkip.dyndns.org/ | awk '{print $6}' | cut -d"<" -f1`

##### the magic happens in this lines that follow... don't change anything if you don't know what you are changing.
echo >> $LOGDIR/$LOGFILE
ez-ipupdate -S $SERVICETYPE \
-u $USER:$PASSWD \
-a $IP -h $DYNHOSTNAME \
-b $CACHEDIR/$CACHEFILE \
-F $PIDDIR/$PIDFILE 2>> $LOGDIR/$LOGFILE
echo “last update done at: `/bin/date`” >> $LOGDIR/$LOGFILE
#####################################################################################

Como dice en el encabezado del script con crontab -e lo podemos ejecutar cada 5 minutos

5 * * * * /bin/sh /path-to-script/DynDnsUpdate.sh

Los meritos del script son de esta pagina: http://www.osoffice.de/

PD= También tienen un script de backup para el Zimbra que lo voy a revisar

martes, 24 de agosto de 2010

Instalando snv_134 y actualizar a onnv_142

Después del post de ayer me puse a bajar la versión de Opensolaris snv_134 desde www.genuinix.com el archivo que bajé es osol-dev-134-x86.iso. En la instalación no hay nada distinto a la versión anterior , así que paso directamente a hacer un copy & paste del articulo de Hernan Saltiel , donde nos muestra paso a paso como updatear.

a) Creamos un nuevo boot environment (en mi caso, se llama "new134"):
1) pfexec beadm create new134
2) pfexec beadm activate new134

b) Reiniciamos nuestro Solaris para arrancar con new134

c) Bajamos dos archivos:
1) cd /opt
2) wget http://www.genunix.org/dist/richlowe/on-nightly-142.i386.tar.bz2
3)wget http://www.opensolaris.org/sc/src/onnv/onnv-gate/usr/src/tools/scripts/onu.sh

d) Creamos un directorio donde tengamos por lo menos 500 MB de espacio libre:
1) pfexec mkdir -p /export/repo

e) Descomprimimos uno de los archivos en este directorio:
1) cd /export/repo
2) pfexec tar jxvf /opt/on-nightly-142.i386.tar.bz2

f) Por si algún permiso hubiera quedado mal, se lo otorgamos:
1) pfexec chown -R root:root /export/repo/*

g) Levantamos un repositorio local de paquetes apuntando a ese directorio, desde una terminal que no cerraremos, en el puerto 13000:
1) pfexec /usr/lib/pkg.depotd -d /export/repo/on-nightly-142.i386 -p 13000

h) Abrimos otra terminal y ejecutamos
1) pfexec chmod +x /opt/onu.sh
2) pfexec /opt/onu.sh -Ot on-nightly-142.i386 -u http://localhost:13000

i) Cuando termine de instalar los paquetes necesarios desde nuestro repositorio local en el puerto 13000, podremos hacer poweroff, y bootear nuestra máquina de nuevo. Ya tendremos el sistema en onnv_142.

GRACIAS HERNAN!

lunes, 23 de agosto de 2010

Y ahora que hacemos con OpenSolaris???

Después de un par de semanas sin escribir, y llegando al fin de la novela de Oracle/OpenSolaris , salió está nota de Hernan Saltiel en infosertec , donde nos cuenta la "Cronica anunciada de una muerte (OpenSolaris)". Al final de la nota le hice un comentario de como seguir y voy a copiar su respuesta.

Nikitux:
Cómo estás?
Creo que en este momento el camino a seguir, desde el lado de los seguidores de OpenSolaris, es continuar con snv_134 (la última versión de desarrollo que se puede descargar desde http://genunix.org), y luego ir agregándole los cambios que estamos armando para ustedes.
Rich Lowe generó un repositorio portátil con la versión onnv_142 (8 versiones por arriba de la última publicada), y yo estoy trabajando en dos cosas:
a) La distro onnv_145
b) Una ditro con los bits de illumOS, que no es mi más ni menos que OpenSolaris despojado de todo elemento que no sea estrictamente de código abierto.
Ahora bien, tenemos aparte otro tema, que es el derivado de los demás productos que ahora están en manos de Oracle.
Son ESOS los que me preocupan, dado que desde el lado de OpenSolaris ya tenemos nuestro intento por armar un fork, pero no veo algo parecido desde el lado de OpenOffice y/o VirtualBox, por ejemplo.
También veo con excelentes ojos lo que se está haciendo con MariaDB, que es un MySQL super-power, y con binarios precompilados para OpenSolaris, por ejemplo.
Ese tipo de acciones son los que me encantan, porque demuestran de qué pasta está hecha la comunidad: de la mejor.
Te mando un fuerte abrazo!
HeCSa.

Después de esto se vienen nuevos post de OpenSolaris , almenos voy a instalar la versión snv_134 y la voy a updatear.