clonezilla y drbl en el mismo pendrive/disco duro

Habitualmente uso clonezilla para clonar equipos de forma individual en modo unicast y drbl cuando quiero clonar un conjunto de equipos a la vez en modo multicast.

Me es muy cómodo tener ambas herramientas en mi pendrive o en el disco duro externo. El problema que hay es que tanto clonezilla como drbl guardan sus archivos en el mismo directorio: live.

Para poder tener ambas herramientas en el mismo dispositivo usb, instalamos una de ellas, por ejemplo drbl, de forma normal. 

Luego, descargamos, clonezilla en formato zip y lo descomprimimos, por ejemplo en /mnt:

# unzip clonezilla-live-1.2.12-10-i486.zip -d /mnt


Al descomprimirlo tendremos todo estos archivos en el directorio /mnt:

/mnt
├── Clonezilla-Live-Version
├── COPYING
├── isolinux
│   ├── boot.cat
│   ├── chain.c32
│   ├── drblwp.png
│   ├── isolinux.bin
│   ├── isolinux.cfg
│   ├── memdisk
│   ├── menu.c32
│   ├── ocswp.png
│   └── vesamenu.c32
├── live
│   ├── eb.zli
│   ├── filesystem.packages
│   ├── filesystem.squashfs
│   ├── freedos.img
│   ├── gpxe.lkn
│   ├── initrd.img
│   ├── memtest
│   ├── parameters.txt
│   └── vmlinuz
├── syslinux
│   ├── chain.c32
│   ├── drblwp.png
│   ├── memdisk
│   ├── menu.c32
│   ├── ocswp.png
│   ├── syslinux.cfg
│   └── vesamenu.c32
└── utils
    ├── linux
    │   ├── makeboot.sh
    │   ├── syslinux
    │   └── VERSION.txt
    ├── mbr
    │   └── mbr.bin
    ├── README.txt
    └── win32
        ├── makeboot.bat
        ├── syslinux.exe
        └── VERSION.txt


Renombramos el directorio live:

# mv /mnt/live /mnt/live-hd

Una vez hecho ésto, copiamos el directorio live-hd a nuestro pendrive o disco duro usb. Imaginemos que tenemos montado nuestro disco usb en /media/usb. Para copiar el directorio live-hd al disco usb haríamos:

# cp /mnt/live-hd /media/usb

A continuación, añadimos el contenido del fichero /mnt/syslinux/syslinux.cfg al fichero syslinux.cfg de nuestro pendrive. Suponiendo que en el pendrive ya tenemos drbl y que el fichero syslinux de éste se encuentra montado en /media/usb/syslinux/syslinux.cfg, haríamos lo siguiente:

# cat /mnt/syslinux/syslinux.cfg >> /media/usb/syslinux/syslinux.cfg

Bien. Pues ahora, ya tendríamos en el pendrive un fichero syslinux.cfg con las entradas de drbl y clonezilla. 

Puesto que hemos cambiado la ubicación de los ficheros de clonezilla de live a live-hd, tan sólo nos quedaría modificar, en este fichero, las entradas de clonezilla para que se pueda iniciar. Veamos cómo modificar una, ya que el resto se harían del mismo modo. 

Tomemos la siguiente como ejemplo:

label Clonezilla live
  MENU DEFAULT
  # MENU HIDE
  MENU LABEL Clonezilla live (Default settings, VGA 800x600)
  # MENU PASSWD
  kernel /live/vmlinuz
  append initrd=/live/initrd.img boot=live     noswap nolocales edd=on nomodeset noprompt ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_keymap="" ocs_live_batch="no" ocs_lang="" vga=788 ip=frommedia  nosplash
  TEXT HELP
  * Clonezilla live version: 1.2.5-35-i686. (C) 2003-2010, NCHC, Taiwan
  * Disclaimer: Clonezilla comes with ABSOLUTE NO WARRANTY
  ENDTEXT

Cambiamos los valores resaltados en rojo por los que resalto a continuación en azul y añadimos el parámetro live-media-path=/live-hd, que he resaltado en color verde:

label Clonezilla live
  MENU DEFAULT
  # MENU HIDE
  MENU LABEL Clonezilla live (Default settings, VGA 800x600)
  # MENU PASSWD
  kernel /live-hd/vmlinuz
  append initrd=/live-hd/initrd.img boot=live  live-media-path=/live-hd   noswap nolocales edd=on nomodeset noprompt ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_keymap="" ocs_live_batch="no" ocs_lang="" vga=788 ip=frommedia  nosplash
  TEXT HELP
  * Clonezilla live version: 1.2.5-35-i686. (C) 2003-2010, NCHC, Taiwan
  * Disclaimer: Clonezilla comes with ABSOLUTE NO WARRANTY
  ENDTEXT


sendEmail: Enviar emails desde la línea de comandos

sendEmail es un programa, escrito en Perl, que nos permite enviar mensajes desde la línea de comandos.

sendEmail puede sernos tremendamente útil porque fue diseñado para ser usado en scripts bash, ficheros batch, programas perl y sitios web.

Además está publicado bajo licencia GPL y disponible para las siguientes plataformas: Linux, BSD, OS X, Windows 98, Windows NT, Windows 2000, y Windows XP.

Podemos instalarlo en Debian  desde los repositorios:

# apt-get install sendemail

Veamos un ejemplo en el que hacemos uso de una cuenta de gmail para enviar el correo:

# sendemail -f miusuario@gmail.com -t miusuario@gmail.com -xp mipassword -m "Informe de impresion" -s smtp.gmail.com:587 -o tls=yes -xu miusuario -u "Informe de impresion" -a /root/informe.txt

Veamos las opciones que hemos usado en el comando anterior:

-f miusuario@gmail.com nos permite indicar de dónde procede el mensaje (from)
-t miusuario@gmail.com nos permite indicar a quién va dirigido el mensa (to)

También podríamos enviar copias a otros destinatarios:

-cc otrousuario@gmail.com
-bcc otrousuariomas@gmail.com

Indicamos el password del usuario que envía el mensaje con el parámetro -xp mipassword:

-xp mipassword

Indicamos el asunto del mensaje con el parámetro -u Asunto:

-u "Informe de impresión"


Indicamos el mensaje con el parámetro -m Mensaje:

-m "Informe de impresión"


Y el servidor de correo que vamos a usar de "relay":

-s smtp.gmail.com:587

Indicamos los parámetros de autenticación:

-o tls=yes -xu miusuario

Y los archivos adjuntos:

-a /root/informe.txt




Crear metapaquetes en Debian

Un metapaquete es un paquete que tan sólo va a contener dependencias de otros paquetes, de tal forma que al instalar el metapaquete, se instalen los paquetes que hemos definido como dependencia.

Ésto puede sernos muy útil, por ejemplo, cuando queramos instalar una lista de paquetes de un plumazo. Crearíamos un metapaquete que contenga como dependencia los paquetes que queramos instalar y cuando instalemos el metapaquete se instalarán todos los demás.

En alguna ocasión he usado un metapaquete para instalar una versión más reciente de otro paquete que había en mi sistema y, que, por las restricciones que sea, no se permitía instalar.

Ejemplos de metapaquetes son el paquete gnome y kde, que instalan todo el software necesario para disponer de un entorno  gnome o un entorno kde.

Para crear nuestros metapaquetes en Debian, hacemos uso de una herramienta llamada equivs.

Como esta herramienta se encuentra disponible en los repositorios, instalarla será muy sencillo:

 # apt-get install equivs

Una vez instalada, dispondremos de dos utilidades:

• equivs-control
• equivs-build

equivs-control nos servirá para crear un esqueleto de archivo de configuración del metapaquete.

equivs-build creará el metapaquete a partir del archivo de configuración generado mediante equivs-control y modificado por nosotros.

Veamos cómo crear nuestro metapaquete paso a paso:

1) Creamos un archivo de configuración mediante equivs-control.
Para ello, tendremos que indicar cuál va a ser el nombre de nuestro paquete:

# equivs-control nombredelpaquete

2) Editamos el fichero de configuración creado:

# nano nombredelpaquete

Y tendremos algo como ésto:

### Commented entries have reasonable defaults.
### Uncomment to edit them.
Section: misc
Priority: optional
# Homepage:
Standards-Version: 3.6.2

Package:
Version:
Maintainer: Your Name
# Pre-Depends:
Depends:
# Recommends:
# Suggests:
# Provides:
# Replaces:
Architecture: all
# Copyright:
# Changelog:
# Readme:
# Extra-Files:
# Files:
# 
Description:
 long description and info .
 second paragraph  

En este archivo modificaremos, al menos, los valores que he indicado en negrita. Algunos de ellos no son obligatorios, pero proporcionan información acerca del paquete.

En la línea donde pone Package:  podríamos el nombre del paquete.

En la línea donde pone Version:  especificaríamos la versión del paquete.

En la línea Depends: especificaríamos la lista de paquetes que queremos que se instalen, separados por comas.

En la línea Architecture: especificaríamos la arquitectura para la que va el paquete.

El resto de campos darán información acerca de nuestro paquete.

Una observación: El apartado Files: nos permite añadir archivos, si queremos.

3) Creamos el metapaquete.

Una vez modificado el archivo de configuración y adaptado a nuestras necesidades, ejecutamos equivs-build seguido del nombre del fichero de configuración y se nos creará nuestro metapaquete.

# equivs-build nombredelpaquete

dsh: Dancer’s Shell / Distributed Shell

dsh es una herramienta muy interesante, que conocí gracias a Alfonso Pastor. Esta herramienta sirve para ejecutar comandos de forma remota en un conjunto de máquinas.

Instalarla es muy sencillo puesto que se encuentra en los repositorios de Debian:

# apt-get install dsh

En cuanto a la configuración de dsh, en Debian, se guarda en un conjunto de archivos que se encuentran dentro del directorio /etc/dsh:

recursos:/root# tree /etc/dsh
/etc/dsh
├── dsh.conf
├── group
│   └── all -> ../machines.list
└── machines.list 

Además, también puede guardarse la misma información en el home del usuario, dentro del directorio $HOME/.dsh

• El fichero dsh.conf contiene la configuración de dsh.
• El fichero machines.list contiene una lista de todas las máquinas sobre las que el comando actuará cuando especifiquemos la opción -a (una por línea).
• El directorio group contiene un enlace llamado all que apunta al fichero machines.list. Además, dentro de este directorio podremos crear grupos de máquinas en diferentes ficheros que contendrán una por línea, a los que podremos referirnos si utilizamos el comando con el parámetro --group.
• También podremos especificar una máquina en concreto o un fichero cualquiera que contenga una lista de máquinas.

En los ficheros de listas de máquinas podemos especificar la ip de cada máquina o el nombre de la máquina, si tenemos un servidor dns.

A la hora de ejecutar comandos, podremos elegir qué shell queremos usar: rsh", "remsh" o "ssh".

Además, podremos elegir si queremos que se ejecute un comando shell en cada máquina y que se espere a que la ejecución finalice antes de pasar a la siguiente máquina, mediante la opción: --wait-shell | -w

O, podemos hacer que la ejecución en diferentes máquinas se ejcute de forma concurrente mediante la opción: --concurrent-shell | -c

Por supuesto, para mayor comodidad a la hora de usar dsh, lo mejor que podemos hacer es transferir la clave pública de la máquina desde la que ejecutamos dsh a las máquinas en las que ejecutaremos los comandos. De este modo, no se nos pedirá la clave cada vez que se ejecute un comando en cada máquina.

Veamos algunos ejemplos de uso:

Imaginemos que tenemos un fichero machines.list dentro del directorio /etc/dsh que contiene la lista de todas nuestras máquinas y queremos conocer el kernel que está ejecutando cada una. Escribiríamos el siguiente comando:

# dsh -a uname -r

Si tan sólo quisiéramos averiguar el kernel de la máquina con la IP 192.168.0.128:

# dsh -m 192.168.0.128 uname -r

Y si quisiéramos averiguar el kernel de un grupo de máquinas llamado servidores en el que se encuentra la lista de nuestros servidores, ejecutaríamos:

# dsh -g servidores uname -r

El fichero servidores lo guardaríamos en /etc/dsh/group/

Si queremos que la ejecución se realice de forma concurrente, podemos especificar:

# dsh -c -g servidores uname -r

Y si queremos que la ejecución se realice en serie de forma que la ejecución en una máquina no comience hasta que no haya terminado la anterior:

# dsh -w -g servidores uname -r

Si queremos ver la lista de usuarios logueados en todos los equipos:

# dsh -a w

Si echamos un vistazo al fichero de configuración de dsh (/etc/dsh/dsh.conf), veremos que, por defecto, dsh usa rsh en lugar de ssh:

remoteshell = rsh
 
Si queremos cambiarlo, no tenemos más que modificar la línea anterior por:

remoteshell = ssh

Actualizar RubyGems

RubyGems es un gestor de paquetes para el lenguaje de programación Ruby.

Nuestro puppet master atiende a los clientes puppet usando un servidor apache , mediante passenger.

Al testear puppet (puppetd -t) me dí cuenta de que aparecía un warning:

WARNING:  Invalid .gemspec format in '/usr/lib/ruby/gems/1.8/specifications/rack-1.4.1.gemspec'

Así que actualicé RubyGems:

# gem update --system

Se me actualizó a la última versión estable:

Updating RubyGems to 1.8.18
Installing RubyGems 1.8.18
RubyGems 1.8.18 installed

== 1.8.18 / 2012-03-11

* 4 bug fixes:

  * Use Psych API to emit more compatible YAML
  * Download and write inside `gem fetch` directly. Fixes #289
  * Honor sysconfdir on 1.8. Fixes #291
  * Search everywhere for a spec for `gem spec`. Fixes #288
  * Fix Gem.all_load_path. Fixes #171

Y se solucionó el problema.

Cambiar el uuid de un disco virtual de VirtualBox

Si necesitamos clonar un disco de una máquina VirtualBox, lo más sencillo es usar VBoxManage con el parámetro clonehd. Por ejemplo:

# vboxmanage clonehd squeezedisk.vdi squeezediskcloned.vdi


El comando anterior clonaría el disco virtual squeeze disk.vdi en un nuevo disco virtual llamado squeezediskcloned.vdi

Pero, si simplemente hemos copiado el disco virtual:

# cp squeezedisk.vdi squeezediskcloned.vdi


y queremos usarlo en el mismo equipo, tendremos que cambiar el uuid. Esto es sencillo si hacemos uso de los comandos de VirtualBox:

# vboxmanage internalcommands sethduuid squeezediskcloned.vdi


El comando anterior, creará un nuevo uuid para el disco virtual squeezediskcloned.vdi

Convertir disco virtual de VirtualBox a VMWare

Una forma de convertir una máquina Virtual de VirtualBox en una máquina VMWare es clonar el disco duro virtual, pasándolo de formato .vdi a formato .vmdk con las herramientas de línea de comandos de VirtualBox.

Ejemplo:

# vboxmanage clonehd xpdisk.vdi xpdisk.vmdk -format VMDK -variant standard

El comando anterior clonaría el disco xpdisk.vdi (de VirtualBox) a un disco xpdisk.vmdk (de VMWare) que luego podríamos usar en una nueva máquina virtual creada en VMWare.