Algo de Linux: marzo 2012

viernes, 23 de marzo de 2012

Convertir clave WEP ASCII <-> HEX

Convertir una clave WEP de formato ASCII a Hexadecimal y viceversa es una tarea sencilla si hacemos uso del comando xxd.

Por ejemplo, si queremos  convertir una clave WEP de formato ASCII a Hexadecimal:

# echo -n Z0001XFB5D346 | xxd -p

Y si queremos convertir una clave WEP de formato Hexadecimal a ASCII:

# echo -n 5a303030315846423544333436 | xxd -r -p

Dejo un script en box.net que hace la conversión en ambas direcciones pasando como parámetro la clave: convierteclavewifi.sh

Ejemplos de uso y salida:

enam0000@ldap:~/Desktop$ ./convierteclavewifi.sh Z0001XFB5D346 

Clave en formato ASCII: Z0001XFB5D346 
Clave en formato HEXADECIMAL: 5a303030315846423544333436 
 
enam0000@ldap:~/Desktop$ ./convierteclavewifi.sh 5a303030315846423544333436 
Clave en formato ASCII: Z0001XFB5D346 
Clave en formato HEXADECIMAL: 5a303030315846423544333436

Importar la clave pública de un repositorio de forma manual

En muchas ocasiones hemos visto un error como éste:

W: Error de GPG: http://ldap squeeze-backports Release: Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY 85A3D26506C4AE2A

Que significa que no tenemos la llave pública el repositorio o que la que tenemos está caducada.

Y sabemos que podemos descargar fácilmente la clave pública del repositorio en cuestión simplemente ejecutando:

# gpg --keyserver subkeys.pgp.net --recv 85A3D26506C4AE2A

Lo que descargará la clave pública de un servidor de claves; en este caso de  subkeys.pgp.net.

Ahora bien, algunas veces, las claves no se descargan, porque, por ejemplo, por algún motivo se rechaza la conexión. En este caso, si tenemos la clave pública del repositorio en otra máquina, podríamos exportar dicha clave en la máquina que sí la tiene, copiarla al equipo que no tiene dicha clave e importarla. ¿Cómo lo hacemos? Muy fácil:

Vemos si en otro equipo, la tenemos almacenada:

# gpg --fingerprint 06C4AE2A

El comando nos mostrará algo así:

pub   4096R/06C4AE2A 2010-11-20 [caduca: 2012-11-14]
      Huella de clave = 85F0 6FBC 75E0 67C3 F305  C3C9 85A3 D265 06C4 AE2A
uid                  Debian Mozilla team APT archive


Bien, pues como la tenemos, la exportamos y la almacenamos en un archivo:

# gpg --armor --output mozilla-team.asc --export 06C4AE2A

El comando anterior exportará la clave y la almacenará en un archivo, al que he llamado mozilla-team.asc

El siguiente paso sería copiar la clave a la máquina que no la tiene y donde la queremos importar. Copiamos el archivo a dicha máquina, por ejemplo, mediante ssh:

# scp mozilla-team.ash root@equipodestino:/root

Ahora nos vamos a la máquina que no tiene la clave pública del repositorio, abrimos un terminal y ejecutamos el comando:

# apt-key add mozilla-team.asc

Que leerá la clave pública del repositorio y se la añadirá al equipo.

miércoles, 21 de marzo de 2012

Instalar paquetes sin firmar de forma automática

El gestor de paquetes, cuando detecta un paquete sin firmar siempre nos avisa y pide confirmación antes de instalarlo.

En ocasiones, no queremos que nos pregunte y lo instale directamente, por ejemplo, en el caso de que hagamos la instalación desde un script. ¿Cómo lo hacemos? Simplemente haciendo uso de aptitude y el parámetro --allow-untrusted. Por supuesto, indicando también a aptitude que responda que sí automáticamente a las preguntas con el parámetro -y

# aptitude -y --allow-untrusted -t squeeze-backports install iceweasel iceweasel-l10n-es-es

Instalar iceweasel desde squeeze-backports en español

Por lo que he podido comprobar, ya se encuentra disponible el paquete de idioma español de iceweasel en los repositorios squeeze- backports.

Por lo tanto, teniendo los siguientes repositorios:

# Repositorio del Mozilla Debian Team
deb http://mozilla.debian.net/ squeeze-backports iceweasel-release

# Repositorio squeeze-backports
deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free

Es muy sencillo instalar iceweasel en español:

apt-get -t squeeze-backports install iceweasel iceweasel-l10n-es-es

martes, 20 de marzo de 2012

Crear un mirror de Debian squeeze-backports

Ahora que Debian Squeeze es la versión estable, en muchas ocasiones nos va a interesar instalar paquetes de backports en nuestras instalaciones. Y si tenemos muchas máquinas en nuestro centro, en lugar de usar cualquiera de los mirrors de backports, es posible que nos compense tener un mirror propio en alguno de nuestros servidores.

Hacer una réplica de un repositorio es muy sencillo utilizando debmirror. Así que, veamos, a modo de ejemplo, como crear un mirror de squeeze-backports, que en estos momentos, puede ser de gran utilidad para nosotros.

Lo primero de todo será instalar debmirror, si no lo tenemos instalado ya:

# apt-get install debmirror

Una vez instalado, para no tener que recordar todos los parámetros que podemos pasar a debmirror, lo mejor que podemos hacer es colocar el comando dentro de un script:

ldap:/var/www# cat mirror-squeeze-backports.sh
#!/bin/bash

## Debian Backports
debmirror --debug \
--progress \
--verbose \
--diff=none \
--host=ftp.uk.debian.org \
--root=debian-backports \
--method=rsync \
--dist=squeeze-backports \
--arch=i386,amd64 \
--nosource \
--section=main,contrib,non-free \

--getcontents \
--ignore-release-gpg \
--ignore-missing-release \
/var/www/debian-backports

Como podéis ver, el comando podríamos ejecutarlo en una sola línea, pero lo hemos partido para mayor claridad.

Veamos ahora los detalles que considero más importantes y que he marcado con colores:
  • --host=ftp.uk.debian.org: Con este parámetro, indicamos a debmirror qué servidor vamos a utilizar para crear nuestro mirror. Podemos elegir uno cualquiera entre todos los que hay en http://backports-master.debian.org/Mirrors/
  •  --root=debian-backports: Indicamos a debmirror cuál es la raiz del mirror. Está indicado también en http://backports-master.debian.org/Mirrors/
  • --method=rsync: Estamos diciendo a debmirror que use rsync como método de descarga. Podemos usar cualquiera de los siguientes métodos, siempre y cuando estén soportados por el servidor: ftp, hftp (ftp over http proxy), http o rsync. Podemos verlo también en http://backports-master.debian.org/Mirrors/
  • --dist=squeeze-backports: Indicamos cuál es la distribución de la que vamos a crear el mirror.
  • --arch=i386,amd64: Estamos diciendo a debmirror que queremos replicar paquetes i386 y amd64.
  • --section=main,contrib,non-free: Le decimos a debmirror que queremos replicar las tres secciones: main, contrib y non-free.
  • /var/www/debian-backports: Por último tenemos que decirle, dónde vamos a guardar los paquetes que descargue.
 Y eso es todo.

lunes, 19 de marzo de 2012

Autorestaurar imágenes de discos/particiones con clonezilla a través de la red

En el artículo anterior, vimos cómo restaurar una imagen de disco de forma automática, teniendo la imagen almacenada en un pendrive autoarrancable.

Otra cosa, bastante interesante, por cierto, que podemos hacer es crear entradas de autorestauración en el fichero syslinux.cfg que nos permitan tomar las imágenes desde un servidor vía sshfs.

Ésto es algo de lo que no hay mucha documentación y que me costó bastante hacer que funcionara, aunque si te lo encuentras explicado, la verdad es que resulta hasta sencillo.

Cuando queremos ejecutar un comando, se lo indicamos a clonezilla mediante el parámetro ocs_live_run. Por ejemplo:

ocs_live_run="ocs-sr -g auto -e1 auto -e2 -c -r -j2 -p true restoredisk portatil-profesor-20111004 sda"

Con el parámetro anterior le estoy diciendo básicamente que restaure el disco sda con la imagen portatil-profesor-20111004 y que espere mi respuesta cuando termine la restauración, entre otras opciones.

Para restaurar la imagen desde una máquina mediante sshfs, antes de poder hacer la restauración tenemos que haber montado la partición donde se encuentra la imagen, lo que requiere que antes se disponga de una IP, y, además, debemos de dar tiempo para que el comando sshfs nos pida la password del usuario con permisos para leer la imagen en el servidor. 

¿Y cómo hacemos todo ésto? Bueno, pues simplemente, haciendo uso de los parámetros ocs_prerun. Con ocs_prerun podemos ejecutar algo, antes de hacer el ocs_live_run. Además, podemos usar varios ocs_prerun, para establecer una secuencia de ejecución de comandos. El primero se llamará ocs_prerun, el segundo: ocs_prerun1, el tercero: ocs_prerun2, etc...

Fijémonos en la siguiente entrada, que he creado para restaurar la imagen de un portátil de profesor:

label Restaurar portatil profesor
  # MENU DEFAULT
  # MENU HIDE
  MENU LABEL Restaurar portatil profesor
  # MENU PASSWD
  kernel /live-hd/vmlinuz
  append initrd=/live-hd/initrd.img boot=live config live-media-path=/live-hd noswap nolocales edd=on nomodeset noprompt ocs_prerun="dhclient -v eth0" ocs_prerun1="sleep 2" ocs_prerun2="sshfs clonacion@172.19.144.16:/home/partimag /home/partimag" ocs_prerun3="sleep 2" ocs_live_run="ocs-sr -g auto -e1 auto -e2 -c -r -j2 -p true restoredisk portatil-profesor-20111004 sda"  ocs_live_keymap="NONE" ocs_live_batch="no" ocs_lang="es_ES.UTF-8" vga=788 ip=frommedia  nosplash
  TEXT HELP
  * Clonezilla live version: 1.2.9-19-i486. (C) 2003-2011, NCHC, Taiwan
  * Disclaimer: Clonezilla comes with ABSOLUTELY NO WARRANTY
  ENDTEXT


El primer ocs_prerun (ocs_prerun="dhclient -v eth0") pide una ip al servidor dhcp.

El segundo ocs_prerun (ocs_prerun1="sleep 2") hace que el comando espere 2 segundos antes de ejecutar el siguiente comando. Ésto nos sirve para dar tiempo a que el equipo reciba una IP antes de realizar el montaje de /home/partimag mediante sshfs.

El tercer ocs_prerun (ocs_prerun2="sshfs clonacion@172.19.144.16:/home/partimag /home/partimag") monta la partición /home/partimag del servidor de imágenes en /home/partimag.

El cuarto ocs_prerun (ocs_prerun3="sleep 2") hace que se esperen 2 segundos antes de ejecutar el siguiente comando. Ésto nos sirve para dar tiempo a que el usuario introduzca la password para realizar el montaje de /home/partimag mediante sshfs antes de restaurar.

Por último, se ejecutaría el comando definido en ocs_live_run, que realizaría la restauración.

domingo, 18 de marzo de 2012

Autorestaurar discos/particiones con clonezilla

En ocasiones, nos interesa tener entradas que nos permitan restaurar un disco o particiones con tan sólo seleccionar una opción en el menú de arranque de nuestro pendrive o disco duro usb.

En mi caso, tengo un pendrive con varias herramientas (clonezilla, drbl, system rescue cd, wifiway...) Como todas ellas usan isolinux/syslinux como sistema de arranque, he unido los ficheros de configuración en uno sólo con el fin de poder elegir cualquiera de estas herramientas en el inicio.

Además, he creado entradas que me permiten autorestaurar imágenes almacenadas en el pendrive.

Para explicar como preparar una entrada de autorestauración en el fichero de configuración syslinux.cfg, vamos a ver de forma detallada una de mis entradas:

label Restaurar workstation
  # MENU DEFAULT
  # MENU HIDE
  MENU LABEL Restaurar equipo Workstation general
  # MENU PASSWD
  kernel /live-hd/vmlinuz
  append initrd=/live-hd/initrd.img boot=live config live-media-path=/live-hd noswap nolocales edd=on nomodeset noprompt ocs_live_run="ocs-live-restore" ocs_live_extra_param="-g auto -e1 auto -e2 -c -r -j2 -p true restoredisk workstation-squeeze-ies-20120120 sda"  ocs_live_keymap="NONE" ocs_live_batch="yes" ocs_lang="es_ES.UTF-8" vga=788 ip=frommedia  nosplash
  TEXT HELP
  * Clonezilla live version: 1.2.9-19-i486. (C) 2003-2011, NCHC, Taiwan
  * Disclaimer: Clonezilla comes with ABSOLUTELY NO WARRANTY
  ENDTEXT
 

Con la opción MENU LABEL indicamos lo que se va a mostrar en el menú:

MENU LABEL Restaurar equipo Workstation general


Así, cuando arranque un equipo con mi pendrive usb, habrá una opción en el menú que diga "Restaurar equipo Workstation general".

Como podéis ver, por las opciones que he resaltado en color rojo, tengo el sistema de clonezilla dentro del directorio live-hd. Eso es tan sólo porque también tengo drbl en el mismo pendrive.

En cuanto a las opciones de autorestauración que he usado, son las siguientes:
  • ocs_live_run="ocs-live-restore"
  • ocs_live_extra_param=" -g auto -e1 auto -e2 -c -r -j2 -p true restoredisk workstation-squeeze-ies-20120120 sda"
  • ocs_live_batch="yes"

La opción por defecto de ocs_live_run es "ocs-live-general", que nos permite salvar o restaurar. Como queremos automatizar la restauración cambiamos esta opción por "ocs-live-restore".

La opción "ocs_live_extra_param" nos permite pasar parámetros al comando indicado en ocs_live_run. Estos parámetros le van a indicar a ocs-live-restore qué es lo que tiene que hacer:

ocs_live_extra_param=" -g auto -e1 auto -e2 -c -r -j2 -p true restoredisk workstation-squeeze-ies-20120120 sda"

Veamos de forma detallada para qué sirve cada opción:
  • -g auto: Reinstala grub en el MBR del disco cliente.
  • -e1 auto:  Automáticamente ajusta la geometría del sistema de ficheros de una partición con sistema de arranque NTFS, si existe.
  • -e2: Esta opción es para un cargador no-grub, por ejemplo, para el boot loader de windows. No tiene efecto si el cargador de arranque del disco de destino es grub.
  • -c: Sirve para que el cliente pida confirmación al usuario antes de clonar. Si no queremos que pida confirmación y clone directamente, omitimos esta opción.
  • -r: Intenta redimensionar el sistema de ficheros para adaptarlo a la partición.
  • -j2: Clona los datos ocultos entre el MBR y la primera partición.
  • -p true: Espera a que el usuario realice alguna acción una vez ha terminado el proceso de clonación. El parámetro -p tiene tres opciones:
    • -p true -> No hacer nada cuando termine la clonación.
    • -p reboot -> Reiniciar el cliente cuando termine la clonación.
    •  -p poweroff -> Apagar el cliente cuando termine la clonación.
Por último, la opción ocs_live_batch="yes" nos permite indicarle a clonezilla que haga la restauración en modo batch.

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

jueves, 15 de marzo de 2012

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


miércoles, 14 de marzo de 2012

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

Cuando ejecutamos dsh, en la información de pantalla no muestra el nombre de la máquina donde está corriendo el comando en ese momento. Si queréis que se muestre, tendréis que añadir el parámetro:  -M
Por ejemplo:

# dsh -aM 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

lunes, 12 de marzo de 2012

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.

sábado, 3 de marzo de 2012

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.


jueves, 1 de marzo de 2012

Flashear nuestro dispositivo Android con una nueva ROM

Otro artículo muy sencillo  de Sagrario Pedraza Labrador en el que se explica qué es flashear y, a modo de ejemplo, cómo "flashear" el smarphone Motorola Defy:

En el mundo de android, como en todo el mundo de las nuevas tecnologías, hay un vocabulario específico. Por eso, antes de nada, vamos a explicar una serie de conceptos básicos, empezando por el título: “Flashear nuestro dispositivo Android con una nueva ROM”.

El sistema operativo de nuestro dispositivo está formado básicamente por una serie de elementos como el kernel de linux, un conjunto de aplicaciones y un conjunto de datos. Este sistema se almacena en una memoria de tipo ROM programable, mediante un proceso al que llamamos “flasheo”.

¿Entonces qué es flashear? Pues simplemente, “grabar” el sistema en la memoria ROM de nuestro dispositivo.

¿Y a qué llamamos ROM? En Android una ROM es un archivo que contiene todo el sistema operativo preparado para ser transferido a la memoria flash del dispositivo.

¿Y por qué hablamos de dispositivo y no de teléfono o smartphone? Bien, pues porque hoy en día hay más dispositivos con sistemas Android que llevan su sistema operativo en una memoria rom y se pueden flashear, además de teléfonos, como por ejemplo, tablets.

Por supuesto, para flashear un dispositivo con Android, antes tenemos que haberlo rooteado. Y, ¿por qué? Porque para flashearlo, tendremos que tener instalado un bootloader, lo que requiere privilegios de root.

A modo de ejemplo, veamos cómo flashear nuestro Motorola Defy con una nueva ROM, partiendo de que ya lo tenemos rooteado.

0.- Antes de nada, recomiendo hacer un backup de aplicaciones, registro de llamadas y sms usando:
  • Titanium Backup, para el backup de las aplicaciones+datos que tenemos instaladas actualmente. La versión gratuita nos sirve perfectamente.
  • Call Logs Backup & Restore para el backup de los registros de llamadas.
  • SMS Backup & Restore para el backup de los sms que tengamos.
En principio, no sería necesario guardar un backup de nuestros contactos, ya que al volver a configurar el teléfono se sincronizarán desde nuestra cuenta de gmail, pero por si las moscas, os recomiendo instalar Contact2Sim, y como medida de seguridad, copiar los contactos del teléfono a la sim.

1.- Descargamos SndInitDefy.
Lo primero que debemos hacer es descargar la aplicación SndInitDefy en el ordenador o en el teléfono. La última versión a día de hoy es la 2.0 y se puede descargar desde aquí: http://depositfiles.com/files/3v38tur3s SndInitDefy es una aplicación android que nos permite instalar un bootloader (un cargador). Este cargador nos proporciona un menú de inicio que se pone en marcha justo antes de que el sistema Android arranque y nos da la posibilidad de hacer un backup de nuestra rom o cargar una nueva rom, instalar parches en la rom, entre otras cosas.
Es importante decir que ni la aplicación SndInitDefy ni el cargador en sí mismo, reemplazan el bootloader original del dispositivo.

2.- Instalamos SndInitDefy.
Bueno, pues una vez descargado el instalador SndInitDefy_2.0.apk, lo copiamos al teléfono, si lo hemos descargado en el ordenador. Una vez que la tenemos en el teléfono, abrimos el explorador de archivos y lo instalamos haciendo un doble clic.

3.- Instalamos el bootmenu.
Una vez instalado el instalador del bootmenu (valga la redundancia) lo buscamos entre las aplicaciones. Se llama “Defy 2ndInit”. Lo ejecutamos haciendo doble clic. Al ejecutarlo se nos muestra:
  • Un mensaje informativo que dice “2ndInit Recovery NOT currently installed.” informándonos de que el menú de inicio aún no ha sido instalado.
  • Un botón para instalarlo: “Install 2ndInit Recovery”
  • Otro botón para desinstalarlo: “Uninstall 2ndInit Recovery”


Hacemos un clic en el botón “Install 2ndInit Recovery” para instalarlo. Se nos pedirá que elijamos entre instalar la versión estable del bootmenu o la última versión.


Elegimos instalar la versión estable, sobre todo si vamos a instalar una rom basada en CyanogenMod, porque nos lo recomienda. El led del teléfono se volverá de color rojo mientras se descarga el bootmenu y se tornará verde cuando el bootmenu haya terminado de instalarse.

4.- Desactivamos el modo de Depuración USB en el teléfono. Menú Ajustes -> Aplicaciones -> Desarrollo -> Depuración USB.

5.- Reiniciamos el telefono.
Al volver a encenderse, justo cuando se muestra el logo (M) de Motorola en pantalla, notaremos que el led del teléfono se enciende en color azul y carga el BootMenu. Si no cargara el BootMenu, pulsamos la tecla Volumen - (la tecla de bajar el volumen) en el momento que se encienda. De este modo, entraremos en el menú de inicio.

6.- Manejando el BootMenu.
Para desplazarnos por las opciones del menú debemos usar las teclas de Volumen + y Volumen - Para seleccionar una opción, pulsaremos el boton de Encendido.
Si queremos que siempre que se inicie nuestro teléfono, se inicie el BootMenu, seleccionamos la opción “Boot”, luego elegimos “Set Default” y por último “2ND INIT”. Después elegimos “Go Back” para volver al menú principal.

7.- Hacer un backup del sistema actual antes de cambiarlo.
Es importante hacer un backup del sistema actual para restaurarlo en caso de que el nuevo sistema no nos guste, nos de problemas o tengamos que mandar el teléfono al SAT. Estando en el menú principal, seleccionamos la opción “Recovery”, y, en la pantalla siguiente: “Custom Recovery”. Una vez dentro de la aplicación de Recovery, elegimos “Backup and restore” y seguidamente “Backup”. Con ésto ya tendremos un backup completo del sistema actual.

8.- Limpiamos configuraciones.
Estando en el menú principal, seleccionamos la opción “Recovery”, y, en la pantalla siguiente: “Custom Recovery”.
Para hacer limpieza, elegimos primero la opción “Wipe Cache Partition”, y cuando finalice seleccionamos “Wipe Data/Factory reset”.
  •  La opción “wipe data/factory reset” borra todos los datos del usuario en el telefono, así como la memoria caché. Esto deja el teléfono en el estado como de fabrica.
  • La opción “wipe cache partition”  limpia la partición de memoria caché del telefono.
Otras dos opciones que podemos utilizar son:
  • Wipe Dalvik Cache: Limpia la memoria donde que guardan algunas configuraciones de aplicaciones.
  • Wipe Battery Stats: Limpia los estados parámetros de la bateria.
Estas dos últimas opciones se encuentran en el menú Advanced.

9.- Instalar la rom que queramos.
Una vez terminado el proceso anterior, ya no nos queda más que instalar la nueva rom.
Así que elegimos a la opción “Install zip from sdcard”. Se nos mostrará una nueva pantalla con varias opciones. Elegimos “Choose zip from sdcard”. Esto nos permitirá buscar la rom que queremos instalar en nuestra tarjeta SD.  La seleccionamos y comenzará el proceso de instalación.


Tardará un poquito, pero no demasiado.




Cuando finalice, elegimos la opción “Go Back” y, por último “Rebot System Now” para reiniciar.


Con ésto habremos finalizado la instalación de nuestra rom. No os preocupéis si la primera vez que arranca el sistema tras la instalación, tarda un poquito. Es normal.

10.- Restaurar aplicaciones, registro de llamadas y sms usando:
  • Titanium Backup, para restaurar las aplicaciones+datos.
  • Call Logs Backup & Restore para restaurar los registros de llamadas.
  • SMS Backup & Restore para restaurar los sms que tengamos.

Administración remota de cups

Aprovechando que un compañero me lo ha preguntado y sois ya unos cuantos los administradores que leéis mis entradas, aprovecho para publicarlo aquí y queda como chuleta.

Siempre que hemos querido administrar las impresoras de forma remota con cups, hemos añadido una directiva en el fichero /etc/cups/cupsd.conf del tipo:


Allow From "ipadministrador"; 

Dentro del siguiente bloque:


# Restrict access to the server...
<Location>
    Order allow,deny
    Deny From All
    Allow From 127.0.0.1
    Allow From 192.168.1.10

</Location>


En las versiones más recientes, cups viene configurado, además, para escuchar sólo en localhost. Si queremos  administrar las impresoras de forma remota, también tenemos que hacer que cups escuche en todas las interfaces. Para eso, no tenemos más que cambiar:

Listen localhost:631

por:

Listen *:631