Algo de Linux: 2009

lunes, 21 de diciembre de 2009

unrar: Descomprimir archivos .rar

Muchas veces tenemos que descomprimir archivos .rar en linux y nos encontramos con que no podemos hacerlo porque, por defecto, no tenemos soporte para ello. ¿Por qué? Simplemente porque en linux se utilizan habitualmente otros formatos como .tar.gz, .zip...

Si queremos tener la posibilidad de extraer archivos .rar en consola, nos aseguramos de tener habilitada la sección non-free de nuestros repositorios en el fichero /etc/apt/sources.list.

Luego, actualizamos nuestros índices:

# aptitude update

Y después, instalamos los paquetes rar y unrar:

# aptitude install rar unrar

Se instalarán los paquetes rar, unrar y todas sus dependencias.

Y listo. Ya podremos descomprimir archivos rar en la línea de comandos.

Si quisiéramos poder descomprimir en modo gráfico, instalaremos también file-roller o xarchiver. El que más nos guste. Nunca está de más tenerlos, por comodidad, pero a mí me interesa más la posiblidad de descomprimir en línea de comandos para aquellas ocasiones en que no se dispone de servidor gráfico.

Una cuestión importante es que podemos descomprimir archivos divididos en varias partes.

Uso básico de unrar.-

Si tengo un archivo rar y quiero ver su contenido sin extraerlo, no tengo más que hacer un:

# unrar l ficherocomprimido.rar

Si tengo un archivo rar y quiero extraerlo al directorio actual:

# unrar e ficherocomprimido.rar

Otra opción para descomprimir es extraer el archivo con el path completo:

# unrar x ficherocomprimido.rar

Si lo que tenemos es un archivo dividido en varias partes, lo único que tenemos que hacer es ejecutar unrar con el primer archivo y el comando ya se encargará de hacer la extracción completa:

# unrar x ficherocomprimido.part01.rar

Para más info, consultar el man del comando:

# man unrar

lunes, 14 de diciembre de 2009

FireGPG: Utilizando GPG desde Firefox

Si utilizáis un sistema de clave pública/clave privada para cifrar, firmar vuestros mensajes, etc, encontraréis que FireGPG es una extensión de Firefox bastante interesante.

Esta extensión se encuentra bajo licencia GPL y nos ofrece una forma de encriptar, desencriptar, firmar y verificar la firma de un texto mediante firefox. Además se integra perfectamente con gmail, con lo que podremos firmar nuestros correos además de encriptarlos.

FireGPG nos proporciona una interfaz para usar GPG, pero no instala GPG en nuestro equipo. Por tanto, si queremos usar FireGPG, tendremos que tener instalado GPG y disponer de clave pública y privada para usarlo.

Los usuarios de windows, deberán instalar además cygwin para poder utilizarlo. Cygwin se encuentra disponible en su web: http://www.cygwin.com/setup.exe

miércoles, 9 de diciembre de 2009

Hacer una copia de seguridad de nuestra B.D. de ldap

Si trabajamos con un servidor de ldap, es bueno hacer copia de seguridad de la base de datos de ldap de vez en cuando, con el fin de recuperar el servicio lo antes posible si hubiera cualquier problema.

Hacer copia de seguridad de nuestra BD de ldap es tan sencillo como ejecutar el comando slapcat y redirigir la salida del mismo a un archivo. Eso sí. Es conveniente parar el servidor antes de hacer la copia:

# /etc/init.d/slapd stop; slapcat > backup-ldap.ldif; /etc/init.d/slapd start

Restaurar la copia de seguridad también es sencillo:

# /etc/init.d/slapd stop
# slapadd -l backup-ldap.ldif
# slapindex -vf /etc/ldap/slapd.conf
# /etc/init.d/slapd start

Como podemos ver, restauramos los datos con slapadd y, una vez restaurados, reindexamos la BD mediante slapindex.

martes, 1 de diciembre de 2009

RecordMyDesktop: Videotutoriales screencasts

Hoy tenía que enviar un screencast para explicar cómo se aplicaban estilos en un procesador de textos y no me funcionaba wink. Así que instalé recordmydesktop, lo probé y me gustó como trabaja.

RecordMyDesktop es un software libre de grabación de screencasts diseñado para GNU/Linux.

Un screencast es una grabación digital de la salida por pantalla del ordenador que, además, puede contener una narración en audio.

Es una aplicación fácil de usar, a la vez que eficiente en su trabajo.

El programa viene separado en dos partes:
  • Una herramienta de línea de comandos (recordMyDesktop), escrita en C, que realiza las tareas básicas de captura y codificación.
  • Una interfaz gráfica que facilita su uso. En cuanto a la interfaz gráfica podemos elegir entre dos opciones, ambas realizadas en python:
    • gtk-recordMyDesktop
    • qt-recordMyDesktop
recordMyDesktop usa sólo formatos abiertos para producir los videos, concretamente:
  • theora para el video.
  • vorbis para el audio.
Los videos son guardados en ogg utilizando los formatos mencionados.

Los que trabajamos con gnome instalamos los paquetes: recordmydesktop y gtk-recordmydesktop. Los que tengan kde pueden instalar recordmydesktop y qt-recordmydesktop.

Podemos instalarlo directamente desde los repositorios de ubuntu o debian, vía apt-get:

# apt-get install recordmydesktop gtk-recordmydesktop

O desde el código fuente, que se encuentra en:
http://sourceforge.net/projects/recordmydesktop/

gpdftk: Un Front-End de pdftk hecho en gambas

pdftk es una herramienta muy potente y muy útil para el tratamiento de archivos PDF que se maneja desde la línea de comandos.

Es una herramienta que se puede usar para combinar documentos PDF, separar las páginas PDF en un documento nuevo, descomponer un documento PDF en páginas sueltas, descomprimir y volver a comprimir páginas, descifrar un documento (si sabemos la contraseña), cifrar el documento resultante; y hasta intentar reparar un PDF corrupto...

En el año 2007 publiqué una versión de gpdftk, un front-end de pdftk que hice en gambas. Como gambas ha cambiado mucho desde entonces, resulta que no funcionaba en gambas2. Así que lo he compilado en gambas2 para funcionar en Debian Lenny.

Para utilizar esta aplicación es necesario tener instalado los paquetes:

* gambas2-runtime (>= 1.9.48 y <<>= 1.9.48 y << 2.90) * gambas2-gb-gtk (>= 1.9.48 y <<>= 1.9.48 y << 2.90) * pdftk Como es un front-end que utiliza pdftk, tiene como dependencia pdftk. Puesto que no tendría sentido instalar gpdftk sin pdftk. Aquí tenéis el enlace para descargarlo: http://forjamari.linex.org/frs/download.php/1192/gpdftk_0.0.36-1_all.deb

Una vez descargado, lo instalamos con dpkg:

# dpkg -i gpdftk_0.0-36-1_all.deb

viernes, 13 de noviembre de 2009

El shell de linux: Comando rename - Renombrado masivo de archivos

Cuando se trabaja fundamentalmente en terminales de línea de comandos nos viene muy bien conocer herramientas como rename.

rename es un comando que nos permite renombrar archivos de forma masiva desde la shell de Linux, es decir, que no tenemos más que ejecutar un comando para renombrar una lista de archivos con un patrón común.

La sintaxis del comando rename es muy sencilla:

rename perlexpr [ archivos ]

Dónde:
  • perlexpr es una expresión regular en lenguaje Perl.
  • y [archivos] es la lista de archivos a los que afectará el comando.
Quizás lo más complicado sea hacer las expresiones regulares.

Veamos un ejemplo sencillo: Imaginemos que queremos cambiar la extensión de los archivos .txt del directorio actual por .csv . No tendremos más que ejecutar el comando rename de la siguiente manera:

# rename 's/\.txt/\.csv/' *.txt
  • 's/\.txt/\.csv/' es la expresión regular que dice "cambia .txt por .csv".
  • * .txt es la lista de archivos a los que hay que aplicarles el cambio.
Otro ejemplo: Supongamos que queremos convertir a minúsculas todos los caracteres del conjunto de archivos contenidos en el directorio actual:

# rename 'y/A-Z/a-z/' *
  • 'y/A-Z/a-z/' es la expresión regular que dice "cambia los caracteres mayúsculas por minúsculas".
  • * le dice al comando que lo haga en todos los archivos.
Otro ejemplo: Imaginemos que queremos eliminar la extensión de todos los archivos que tengan extensión .bak en el directorio actual:

# rename 's/\.bak$//' *.bak
  • 's/\.bak$//' le dice al comando que renombre los archivos terminados en .bak por el nombre del archivo sin .bak, es decir, que elimine el .bak.
  • *.bak le dice al comando que actúe sólo en los archivos con extensión .bak del directorio actual.
En estos ejemplos hemos trabajado sólo en el directorio actual, pero se puede especificar un directorio cualquiera. Por ejemplo:

# rename 's/gestor/profesor/' /home/profesor/archivos/*

Una cuestión importante: Si estoy trabajando en un script bash y quiero utilizar una variable del script en la expresión regular de perl, tengo que exportarla para convertirla en una variable de entorno:

export USUARIO

Una vez exportada, ya puedo usarla en la expresión regular haciendo referencia a ella de la siguiente manera: $ENV{'USUARIO'} Viéndolo en el ejemplo:

# rename 's/gestor/$ENV{'USUARIO'}/' /home/profesor/$USUARIO/.nautilus/metafiles/*

miércoles, 4 de noviembre de 2009

KolourPaint: El Paint de Linux

A veces uso capturas de pantalla para explicar alguna cuestión sobre un cuadro de diálogo de una aplicación o una ventana y me gusta marcar y escribir sobre la imagen para añadir comentarios. Hoy necesitaba una aplicación sencilla para hacer ésto, no tenía ninguna a mano y no iba a utilizar gimp para una cosa tan simple.

Buscando un poco en google, encontré justo lo que necesitaba: KolourPaint, una aplicación similar al Paint de Windows, pero con mayor funcionalidad y la posibilidad de abrir gran cantidad de tipos de archivos de imagen.


Lo tenemos tanto en los repositorios de Debian como en los de Ubuntu. Así que podemos instalarlo mediante synaptic o directamente desde un terminal con:

# apt-get install kolourpaint

Una vez instalado, se añadirá una entrada al menú Gráficos.

Actualización 15/10/2011:
El nombre del paquete en Debian Squeeze es kolourpaint4:

# apt-get install kolourpaint4

martes, 27 de octubre de 2009

Analizar los logs de access.log de squid

Me he dado cuenta, viendo los reports de sarg, que el mayor consumo de ancho de banda de mi centro se lo llevan las actualizaciones de windows update de los ciclos. Así que, me he puesto a trabajar en intentar reducir ese consumo mediante el proxy-caché squid.

No voy a entrar en detalles de cómo configurar squid porque lo que ahora me interesa es terminar de configurarlo para que cachee lo máximo posible. Aunque intentaré hacerlo en otro artículo, más que nada para recordar cómo monté el proxy, por si necesito hacerlo en otro momento.

Para hacer pruebas, he necesitado analizar los logs del archivo access.log, en el que hay un montón de líneas que al principio pueden parecernos complicadas, pero que cuando nos familiarizamos con ellas entenderemos cómo funciona el cacheo de archivos.

Lo primero que he hecho es hacer pasar el tráfico de una máquina por el proxy. Esto es fácil si tenemos un servidor dhcp en el que hacemos que la puerta de enlace asignada sea la ip del proxy.

Luego, en el proxy he ejecutado el comando tail para que me vaya mostrando lo que se va almacenando en el access.log:

# tail -f /var/log/squid/access.log

Y he comenzado a realizar actualizaciones en la máquina cliente para ver cómo trabaja el proxy.

Al ejecutar el comando, tail -f /var/log/squid/access.log veremos circular por la pantalla una serie de mensajes.

Básicamente, hay 2 tipos de mensajes:
Veamos los mensajes TCP, que son los que nos interesan para estudiar las peticiones que nos llegan por el puerto HTTP y realizar el cacheo:

TCP_ HIT: Hay una copia válida del objeto solicitado en la caché. Por tanto, se servirá el objeto desde la caché.

TCP_MISS: El objeto solicitado no se encontraba en la caché. Por tanto, squid tendrá que descargarlo desde internet.

TCP_REFRESH_HIT: El objeto solicitado estaba en la caché, pero es viejo. Se hace una petición de traer un archivo más nuevo.

TCP_REF_FAIL_HIT: El ojeto solicitado estaba en la caché, pero era viejo. La petición de validación del objeto falló. Por lo tanto se servirá el objeto de la caché.

TCP_REFRESH_MISS: El objeto solicitado estaba en la caché, pero era viejo. Se hizo una petición de trajer un objeto más nuevo y se trajo.

TCP_CLIENT_REFRESH: Este mensaje nos indica que el cliente abre una página que tiene orden de obtener siempre un archivo nuevo.

TCP_CLIENT_REFRESH_MISS: El cliente solicita el refresco de una web determinada, pidiendo una nueva versión.

TCP_IMS_HIT: El cliente ha solicitado una nueva versión de un objeto que estaba cacheado, pero se encuentra que el objeto de la caché aún no estaba caducado, es decir, que ya era lo más nuevo posible.

TCP_IMS_MISS: El cliente solicita nueva copia acerca de un objeto viejo.

TCP_SWAPFAIL: Se cree que el objeto se encuentra en la caché, pero por alguna razón no se puede acceder.

TCP_DENIED: Se deniega el acceso a dicha petición. Veamos las posibles denegaciones:
  • TCP_DENIED/400 indica que la petición tenía una mala sintaxis. El usuario (o un link a una página web) hizo algo mal.
  • TCP_DENIED/401 indica que la página requiere autorización.
  • TCP_DENIED/403 lo más probable es que sea un sitio bloqueado por una de las listas de control de acceso del Squid.
  • TCP_DENIED/407 indica que el proxy está configurado para usar alguna forma de autenticación y esta autenticación está fallando.
Mensajes UDP con los que podemos encontrarnos:Además, veremos también códigos de resultado de la fuente de la página:
Por otra parte, es interesante también observar los mensajes del archivo /var/log/squid/store.log. Si al descargar un archivo por primera vez, hacemos un:

# tail -f /var/log/squid/store.log

Veremos un mensaje con un GET por el que nos damos cuenta de que el archivo va a ser descargado, y cuando el archivo termine de descargarse, veremos un mensaje con un SWAPOUT, que nos indica que el archivo ha sido sacado de la caché para ofrecérselo al cliente.

Si volvemos a descargar el mismo archivo y no hay una versión más nueva en internet, ya no veremos un GET, sino que encontraremos un mensaje de SWAPOUT.

Si queremos ver estadísticas de resultados, recomiendo instalar Calamaris, un generador de informes de la actividad de caché que nos permitirá obtener datos estadísticos de uso de la caché de squid en formato ASCII o HTML.

lunes, 28 de septiembre de 2009

Problemas con splash en grub

Siempre he tenido una imagen de fondo en grub, pero de un tiempo a esta parte, con las actualizaciones, dejó de aparecer. Me he puesto a buscar algo de información y he encontrado cuál es el problema.

La entrada que cargaba la imagen de grub es la siguiente:
splashimage=(hd0,3)/boot/grub/splashimages/calavera.xpm.gz

Por lo visto, ahora, para que se cargue la imagen de splash, dicha imagen tiene que llamarse splash.xpm.gz.

Lo que he hecho es crear en /boot/grub/ un enlace a la imagen del directorio /boot/grub/splashimages/ que quiero cargar, llamándola splash.xpm.gz. Por ejemplo:
ln -s /boot/grub/splashimages/calavera.xpm.gz /boot/grub/splash.xpm.gz

Después he cambiado la entrada que carga el splash en grub por:
splashimage=(hd0,3)/boot/grub/splash.xpm.gz

Y listo. Vuelvo a tener imagen de splash en grub.

jueves, 24 de septiembre de 2009

mkisofs: Crear iso

Podemos crear un iso de un directorio utilizando el programa mkisofs.
de la siguiente manera:

# mkisofs -o archivo.iso /directorio

Y si queremos crear el iso de un directorio que arranque con grub, añadiremos un directorio /boot al directorio de la imagen con un grub y el fichero stage2_eltorito dentro de boot/grub/.

Si tenemos debian y un kernel de 64 bits, encontraremos el fichero stage2_eltorito en el directorio:

/usr/lib/grub/x86_64-pc/

Y si nuestro kernel es de 32 bits, el fichero estará en:

/usr/lib/grub/i386-pc/

Una vez listo el directorio del que vayamos a crear el fichero iso, ejecutaremos el comando mkisofs.

Veamos un ejemplo: Imaginemos que tenemos un directorio llamado cd, a partir del que vamos a crear un iso llamado cd_boot.iso con una etiqueta de disco: etiqueta:

# mkisofs -V etiqueta -no-iso-translate -U -nobak -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o cd_boot.iso cd

Para rematar, una vez creado el archivo iso, podemos crear su hash md5. De este modo, si alguien quiere descargarlo, podrá comprobar que la descarga es correcta y el archivo no ha sido manipulado:

# md5sum archivo.iso > archivo.iso.md5

Una vez creado el hash md5 y almacenado en un archivo, podemos comprobar

md5sum -c archivo.iso.md5 si el hash md5 del archivo coincide con el del fichero descargado de la siguiente manera:

# md5sum -c cd_boot.iso.md5

Si al ejecutar este comando, obtenemos un mensaje como el siguiente, sabemos que hemos descargado el archivo perfectamente:

cd_boot.iso: La suma coincide

Error al ejecutar Trinity Rescue Kit: trk not found on cd

Hace mucho tiempo que no escribo nada en el blog por falta de tiempo. Pero aprovechando que me preguntaron por este error al ejecutar Trinity Rescue Kit, lo escribo en este artículo ahora que recuerdo a qué se debía cuando me sucedió a mí.

El problema de que nos aparezca el siguiente error: trk not found on cd en Trinity Rescue Kit v3 está habitualmente en que el disco debe tener como etiqueta: TRK_3.3.

Y si tenemos montado TRK en una partición de un disco externo, por ejemplo, tendremos que etiquetar la partición como TRK_3.3. Además de que la partición sea la cuarta del disco.

lunes, 6 de julio de 2009

Cambiar IP pública del router Comtrend en JDownloader

JDownloader es una aplicación multiplataforma hecha en java que sirve para descargar desde sitios tipo rapidshare, megaupload, etc...

Para los que usen JDownloader y tengan un router Comtrend, es posible renovar automáticamente la IP pública de nuestro router, escribiendo el siguiente conjunto de instrucciones en el apartado de configuración que se muestra en la imagen:

[[[HSRC]]]
[[[STEP]]]
[[[REQUEST]]]
GET /rebootinfo.cgi HTTP/1.1
Host: %%%routerip%%%
Authorization: Basic %%%basicauth%%%
[[[/REQUEST]]]
[[[/STEP]]]
[[[/HSRC]]]


sábado, 4 de julio de 2009

Actualizar BIOS del EEEPC 701

Es posible actualizar de una forma sencilla la BIOS de nuestro eeepc utilizando un pendrive formateado en FAT16.

Para actualizar la bios, lo primero que haremos será buscar en la web de soporte de Asus la última versión disponible y descargarla:
http://support.asus.com/download/download.aspx?SLanguage=es-ES

Imaginemos que hemos descargado la última versión disponible: 701-ASUS-1302.zip

Descomprimimos el fichero:

# unzip 701-ASUS.1302.zip

Al descomprimirlo, tendremos el fichero con la nueva BIOS. En el ejemplo:

701-ASUS-1302.ROM

Lo renombramos para que tenga el nombre 701.ROM:

# mv 701-ASUS-1302.ROM 701.ROM

Y lo copiamos al pendrive. Es importante que el pendrive esté formateado en FAT16. Al menos a mí no me ha funcionado teniéndolo formateado en FAT32.

Una vez que tenemos el fichero 701.ROM en el pendrive, apagaremos nuestro EEEPC 701, conectaremos el pendrive y lo encenderemos. Cuando comience a encenderse, pulsaremos Alt+F2 para iniciar la herramienta de actualización de la BIOS. Ésta herramienta buscará el fichero 701.ROM en el pendrive y actualizará su bios.
Importante: No interrumpir el proceso y asegurarse de que el portátil tiene la batería cargada. Lo mejor es tener carga en la batería y al mismo tiempo mantenerlo conectado a la red eléctrica, por si acaso.

domingo, 21 de junio de 2009

sshfs: Montar directorios remotos de forma segura

sshfs es una herramienta muy útil para todos aquellos que administramos sistemas linux.

Es bastante interesante porque nos permite montar directorios remotos usando ssh y trabajar con sistemas de archivos remotos como si fueran locales, con el añadido de que al utilizar ssh, la comunicación es segura.

Lógicamente, para montar un directorio remoto vía sshfs, el servidor tendrá que tener un servidor ssh.

Instalar sshfs en la máquina cliente.-
En cuanto al cliente, deberá disponer de soporte FUSE (Filesystem in User Space) en el kernel, algo seguro si la versión del kernel es igual o posterior a la versión 2.6.14.

Podemos comprobar si tenemos cargado el módulo fuse de la siguiente manera:

# lsmod | grep fuse

Si obtenemos una línea parecida a la siguiente, es que está cargado:

fuse 60956 3

Si no estuviera, cargado, lo cargamos:

# modprobe fuse
# depmod -A

Una vez que tenemos cargado el módulo fuse, instalaremos sshfs:

# apt-get install sshfs

Y ya podremos montar directorios remotos vía ssh.

Montar directorios remotos usando sshfs.-
Cuando queramos montar un directorio de una máquina remota vía sshfs, no tendremos más que ejecutar:

# sshfs usuarioremoto@servidor:dir_remoto dir_local

Por ejemplo, si queremos montar el directorio /backup que tenemos en una máquina remota llamada recursos, como root, en el directorio local /mnt/backup, ejecutaremos el siguiente comando:

# sshfs root@recursos:/backup /mnt/backup

Una vez hecho ésto, si entramos dentro del directorio /mnt/backup, veremos el contenido del directorio /backup de la máquina recursos.

Desmontar un directorio remoto montado vía sshfs.-
Cuando queramos desmontar un directorio de una máquina remota vía sshfs, no tendremos más que ejecutar:

# fusermount -u dir_local

Siguiendo con el ejemplo anterior: Si queremos desmontar el directorio que teníamos montado en /mnt/backup, ejecutaremos:

# fusermount -u /mnt/backup

lunes, 15 de junio de 2009

killall en Lenny

He instalado un Debian Lenny mínimo sin entorno gráfico para un servidor y me he dado cuenta de que no tenía el comando killall. Como lo necesitaba, he estado buscando y he encontrado que esta utilidad está disponible al instalar el paquete psmisc.

miércoles, 10 de junio de 2009

Administración centralizada de equipos mediante PUPPET

PUPPET es una herramienta que facilita el trabajo de un administrador de sistemas permitiéndole hacer instalaciones, actualizaciones, cambios de configuraciones, etc... en equipos remotos. Lo que evita tener que desplazar un técnico para realizar dichas modificaciones.

Puppet se compone de varios elementos:
  • Un servidor -> puppetmaster.
  • Un servicio para los clientes -> puppetd.
  • Un lenguaje declarativo para definir lo que se quiere hacer en los clientes.
  • Un sistema para obtener datos de los clientes -> facter.
Un detalle importante para entender puppet es tener en cuenta que el servidor define, mediante el lenguaje declarativo de puppet, los estados que se desea tener en los clientes. Y no es necesario definir las instrucciones que hay que ejecutar para lograr esos estados.

Por ejemplo: Supongamos que queremos que en nuestros clientes debe estar instalado el paquete sshfs. Para garantizar que esté instalado tan sólo tendremos que escribir una regla como la siguiente en el servidor:

package { "sshfs":
ensure => installed
}

Y puppet se encargará de que se instale si el paquete no está instalado aún, sin tener que preocuparnos de hacer ningún procedimiento para instalarlo.

Además hay un principio fundamental en puppet: el principio de idempotencia. No importa el número de veces que se ejecute una regla. El efecto debe ser como si sólo se hubiera ejecutado una vez. Además, puppet se encargará de no ejecutar una regla si el objetivo final se ha conseguido.

Comunicación entre el cliente y el servidor puppet.
La comunicación entre el cliente y el servidor es cifrada mediante SSL.
Para garantizar que esta comunicación sea cifrada, el servidor puppet tiene una pequeña autoridad certificada que maneja certificados X509.

Instalación de puppet.
Para instalar puppet, tendremos que hacer varias cosas:
  • Instalar un servidor puppet.
  • Configurar el servidor puppet.
  • Instalar el cliente puppet en todas las máquinas que queramos administrar.
  • Configurar el cliente puppet.
Instalar un servidor puppet.
Instalar un servidor puppet es tan sencillo como instalar el paquete puppetmaster:

# apt-get install puppetmaster

Se resolverán todas las dependencias y se instalarán todos los paquetes necesarios.

Configurar el servidor puppet.

Primer paso.- Configurar el servidor de ficheros.

Para poder servir ficheros a los clientes puppet, lo primero que tenemos que hacer es modificar el fichero /etc/puppet/fileserver.conf. En este fichero especificaremos a qué rango de máquinas de la red queremos servirles ficheros. Ésto se hace en la sección [files] de dicho fichero. Por ejemplo, si mi red es la 192.168.1.0 y quiero servir ficheros de puppet a todas las máquinas de esta red, añadiré una línea allow:

[files]
path /etc/puppet/files
allow 192.168.1.0/24

En este fichero también se puede usar deny para denegar el acceso a ciertas máquinas. Y da igual el orden que coloquemos el allow y el deny. El allow prevalece sobre el deny.
Además, tanto en el allow como en el deny, se puede especificar tanto un rango de red como un nombre de dominio. Ejemplo: allow *.valledeljerte3

Segundo paso.- Modificar el el fichero /etc/puppet/puppet.conf
Por defecto, este fichero contiene la localización de los directorios de logs, de datos, de certificados ssl, etc. Como los valores por defecto nos sirven para hacer una configuración básica, tan sólo le añadimos las dos líneas que he resaltado en negrita:

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginsync=true

[puppetmasterd]
templatedir=/var/lib/puppet/templates
certname=puppetdptos
autosign=false

En la primera línea añadida (certname=puppetdptos) estamos indicando que el servidor de certificación se llama puppetdptos (es el nombre de la máquina en la que hemos instalado puppetmaster).

En la segunda (autosign=false) estamos indicando al servidor que no debe firmar las peticiones de certificados que le lleguen de forma automática. Si quisiéramos que el servidor firmase todas las peticiones de certificados que le llegasen, pondríamos autosign=true. La opción por defecto es autosign=false, con lo que no sería necesario especificar esta opción. La pongo más que nada por si en algún momento quiero que el servidor firme de forma automática los certificados.

Tercer paso.- Crear el esqueleto manifests.
Si no estuviera creado el directorio de clases y/o el directorio manifests, lo creamos:

# mkdir -p /etc/puppet/manifests/classes

Cuarto
paso.- Crear el fichero site.pp
Este es un fichero de control fundamental del servidor puppet. Podríamos crearlo con:

# touch /etc/puppet/manifests/site.pp

Supongamos que en el directorio /etc/puppet/manifests/classes/ hemos creado un fichero llamado test_class.pp con el siguiente contenido:

class test_class {
file {"/tmp/fichero.test":
ensure => present,
mode => 744,
owner => root,
group => root
}
}

En este archivo hemos definido la clase test_class, que contiene una definición del tipo file que se puede leer de la siguiente forma: Debe existir el archivo /tmp/fichero.test con permisos 744 y debe pertenecer al usuario root y al grupo root.

Existen otros tipos de definición que podemos utilizar y que son particularmente útiles. Por ejemplo:

  • package, para el manejo de de software.
  • exec, para ejecutar comandos en el sistema del cliente.
  • cron, para programar tareas en el sistema del cliente.
  • Existen muchos más tipos de definiciones. Podemos verlas en el Type Reference de Puppet.
Podemos añadir un contenido básico al fichero site.pp, y utilizar en él la clase test_class creada en anteriormente:

# Importamos todas las clases del directorio classes
import "classes/*.pp"

# En node default incluimos las tareas para todos los nodos
node default {
include test_class
}

# Definimos un nodo de pruebas
node "a25-pro" inherits default {
# include clase_a_probar
}

Crearemos las tareas en el directorio /etc/puppet/manifests/classes y las llamaremos con include en el nodo de pruebas. Las ejecutaremos. Y si todo va bien, pasaremos la tarea al nodo default para que se ejecute en todos los clientes.

Una vez terminada la configuración del servidor puppet, si no está iniciado, lo iniciamos:

# /etc/init.d/puppetmaster start

No es necesario reiniciarlo después de hacer cambios en los ficheros de configuración. El servidor está monitoreando los archivos de configuración y los reelerá a los pocos segundos de ser modificados.

Instalar un cliente puppet.
Instalar un cliente puppet es tan sencillo como instalar el paquete puppet:

# apt-get install puppet

Se resolverán todas las dependencias y se instalarán todos los paquetes necesarios.

Configurar el cliente puppet.
Configurar el cliente puppet es más sencillo aún. Lo único que tendremos que hacer es editar el fichero /etc/puppet/puppet.conf y añadir una línea server=servidorpuppet.
En la línea server=XXXXXXXXXXXXX podemos indicar:
  • La dirección ip del servidor puppet.
  • O el nombre de dicho servidor, si tenemos un servidor de dns en la red.
El contenido básico del fichero /etc/puppet/puppet.conf en el cliente podría ser el siguiente:

[main]
server=puppetdptos
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
# pluginsync=true

Funcionamiento de puppet y comprobaciones.
No olvidemos que para que el sistema funcione, deben estar iniciados puppetmaster en el servidor y puppet en el cliente. Si no lo están, los iniciamos:

# /etc/init.d/puppetmaster start (en el servidor)

# /etc/init.d/puppet start (en el cliente)

Si hubiera algún problema en el funcionamiento, lo mejor es echar un vistazo a los logs, que se encuentran almacenados en /var/log/puppet

El tiempo predeterminado de contacto del cliente con el servidor es de 30 minutos, cosa que podemos cambiar (Se define en segundos).

Para probar si una tarea se ejecuta correctamente en un cliente, paramos puppet y ejecutamos puppetd -t:

# /etc/init.d/puppet stop

# puppetd -t

Una vez comprobado que las tareas se han ejecutado, volvemos a iniciar el servicio:

# /etc/init.d/puppet start

No es necesario reiniciar puppet ni puppetmaster después de hacer cambios en los ficheros de configuración. El servidor está monitoreando los archivos de configuración y los reelerá a los pocos segundos de ser modificados.

Gestión de certificados en el servidor.
Cuando un cliente intenta comunicarse con el puppetmaster, el servidor se encargará de comprobar si sus certificados son válidos.

Si tenemos configurado nuestro servidor con autosign=false (opción por defecto), podemos comprobar si hay peticiones de certificados pendientes de firmar, ejecutando:

# puppetca --list

Por otra parte, si al ejecutar el comando anterior, vemos que la máquina a24-pro.valledeljerte3 ha hecho una petición y su certificado no ha sido firmado aún, podemos firmárselo con:

# puppetca --sign a24-pro.valledeljerte3

Si quisiéramos revocar el certificado concedido a esta máquina, haríamos lo siguiente:

# puppetca --revoke a24-pro.valledeljerte3

Y si quisiéramos limpiar los ficheros relacionados con la petición de certificación de un host para que se vuelva a hacer una petición de certificado:

# puppetca --clean a24-pro.valledeljerte3

viernes, 5 de junio de 2009

WBFS: Wii Backup File System

WBFS (Wii Backup File System) es un sistema de ficheros que sirve para almacenar backups de juegos wii, de forma eficiente en un disco duro. Lo más interesante es que no sólo podemos almacenarlos, sino que, además, podemos jugar directamente con ellos utilizando un USB Loader.

Este sistema puede ser útil para tener copia de nuestros juegos originales Wii en un disco duro USB y jugar con ellos utilizando un USB Loader. De este modos, conservaremos en mejor estado los discos originales.

Algo que hay que mencionar es que cada juego Wii se almacena en un DVD de al menos 4,7GB que no se aprovecha totalmente.
El sistema de ficheros WBFS es eficiente porque conoce el sistema de ficheros de los discos wii y copia a las particiones WBFS tan sólo la parte que es realmente necesaria, eliminando información "basura".
Esta idea no es nueva. La herramienta WiiScrubber también saca partido de ello.

Suponiendo que tengamos instalado un USB Loader en la Wii, vamos a ver cómo sacar partido de WBFS en linux.

Si tenemos un disco duro USB dedicado exclusivamente para este propósito, tan sólo tendremos que eliminar las particiones que tenga y crear una única partición que pasaremos a formato wbfs.
Otra posibilidad es que tengamos un disco duro multimedia cerca de nuestra consola. Reducimos el tamaño de la partición que tenga para crear una nueva partición en formato wbfs.
Es importante que la partición a usar para los backups sea wbfs. No vale tener un USB con una partición FAT o NTFS o EXT3.

Lo primero: Instalar las herramientas en linux:
Para crear y activar particiones wbfs necesitaremos:
  • Un gestor de particiones, como por ejemplo: gparted.
  • wbfs.
  • Un gui para manejar nuestros backups de forma cómoda. Recomiendo wiithon, una herramienta hecha en python. Se puede manejar de forma sencilla en la línea de comandos y tiene unos scripts nautilus para trabajar desde gnome. Además incorpora wbfs.
Instalar gparted es tan sencillo como tirar de repositorios:
# apt-get update; apt-get install gparted

Para instalar wiithon, primero lo descargamos desde aquí, por ejemplo:
http://www.mediafire.com/?onzhkj5tzjt

La última versión a día de hoy es la 0.98.

Lo que descargamos es el código fuente. Para instalarlo lo primero será descomprimirlo:
# tar xfvz wiithon v0.98 r6.tar.gz

Una vez descomprimido, tendremos un directorio con el código fuente: wiithon. Nos introducimos en él:
# cd wiithon

Si tenemos instalada una versión y queremos actualizarla, el autor nos recomienda desinstalar la anterior e instalar la nueva.

Para desinstalar la versión anterior hacemos:
# make uninstall

Después, instalamos la nueva versión:
# make install

Y listo. Si todo ha ido bien, ya tendremos wiithon instalado y podremos manejarlo mediante comandos.

Manejar wiithon desde la línea de comandos (sacado de la ayuda):

* Ver la ayuda:
wiithon ayuda

* Listar juegos:
wiithon

* Añadir ISO's especificando una lista:
wiithon “juego1.iso” “juego2.iso″ ...

* Añadir ISO's usando comodines (La expresión solo afecta al directorio actual, no es recursivo):
wiithon *.iso

* Buscar y Añadir ISO’s recursivamente. Busca todos las imagenes isos RECURSIVAMENTE, incluso tambien busca dentro de RAR, a falta de implementar zip), tal vez necesites sudo apt-get install rar:
wiithon buscar

* Borrar juegos. Especificando el juego mediante un menú.:
wiithon borrar

* Borrar juegos. Podemos borrar con el IDGAME.:
wiithon borrar IDJUEGO

* Borrar juegos. Podemos borrar con el IDGAME obtenido a partir de un ISO local. El archivo ISO local NO es borrado:
wiithon borrar “./wii/mario.iso”

* Renombrar juegos. Especificando el juego mediante un menú.:
wiithon renombrar

* Renombrar juegos, puedes cambiar el nombre de los juegos ya metidos en HD, útil para que nos enteremos cuando estemos con el USB Loader:
wiithon renombrar IDGAME “Mario Kart Wii”

* Extraer juegos a un archivo ISO. Podemos extraer un juego de la partición wbfs y almacenarlo en un archivo iso. El juego es especificado mediante un menú: wiithon extraer

* Extraer juegos a un archivo ISO. OJO! : El archivo ISO de salida pertenecerá al usuario root:
wiithon extraer IDJUEGO

* Descargar todas las caratulas automaticamente a 160×225. Ojo puede que el servidor te banee, si te ocurre intentalo 5 minutos más tarde:
wiithon caratulas

*Descargar la caratulas de un juego especificado por su IDGAME, la imagen es bajada a 160×225. El comando es un singular, es “caratula” ya que “caratulas” descarga todo:
wiithon caratula IDGAME

Descargar la caratulas de un juego especificado por menú, la imagen es bajada a 160×225. El comando es un singular, es “caratula” ya que “caratulas” descarga todo:
wiithon caratula

Comprobar Integridad de los juegos. Muchos de nuestros juegos pueden estar corruptos sin aún saberlo debido a el bug de borrado de las primeras versiones de WBFS:
wiithon comprobar

Instar juegos desde el DVD, al estilo del usb loader, pero algo más lento porque dumpea a ISO y cuando termina mete la ISO:
wiithon instalar

Por otra parte, tendremos que instalar una serie de herramientas que necesitaremos también:
  • nautilus-actions
  • imagemagick
  • rar
Las instalamos:
#apt-get install nautilus-actions imagemagick rar

Es sencillo de instalar, pero por si a alguien le parece complicado, puede descargar un paquete debian desde la siguiente dirección e instalarlo con dpkg:
http://www.mediafire.com/download.php?kyzfywyyftn


Si ahora queremos tener la posibilidad de usar wiithon mediante nautilus, tendremos que instalar los scripts de nautilus que el autor nos proporciona y que encontraremos en el directorio wiithon:
  • wiithon1.schemas
  • wiithon2.schemas
  • wiithon3.schemas
  • wiithon4.schemas
  • wiithon5.schemas
  • wiithon6.schemas
  • wiithon7.schemas
  • wiithon8.schemas
Para instalarlos, en gnome, abrimos el menú Sistema -> Preferencias -> Configuración de acciones de Nautilus.

Se nos mostrará una pantalla similar a la siguiente:

Si tenemos acciones de wiithon de versiones anteriores, el autor nos recomienda borrarlas porque seguramente hayan sido actualizadas.
Una vez borradas las acciones, si las teníamos instaladas, hacemos clic en el botón: Importar/Exportar.












Al hacer clic en Importar/Exportar se nos abrirá una ventana similar a la siguiente:

En tipo de configuración: ponemos automático.
Y pulsamos en el botón de los puntos suspensivos para seleccionar el esquema a importar.
Tendremos que importar los 8 ficheros, uno a uno:
1. wiithon1.schemas
2. wiithon2.schemas
3. wiithon3.schemas
4. wiithon4.schemas
5. wiithon5.schemas
6. wiithon6.schemas
7. wiithon7.schemas
8. wiithon8.schemas
Una vez importados, tendremos que reiniciar nautilus para que estas opciones se nos muestren en los menús de contexto:
# killall nautilus
Segundo: Crear las particiones:
Como ya hemos dicho anteriormente, no vale tener un USB con una partición EXT3, FAT o NTFS. Para almacenar los backups y que sean jugables, se necesita tener una partición en formato wbfs creada exclusivamente para ésto.

Para crear las particiones mediante gparted, lo primero es abrir gparted. Podemos abrirlo ejecutando en un terminal:
# gparted

O desde el menú: Sistema->Administración->Editor de particiones.

Una vez abierto gparted, en la parte superior derecha nos aparecerá un dispositivo seleccionado. Hacemos clic para seleccionar el disco USB que queramos particionar (también podemos seleccionar el disco USB en el menú, GParted->Dispositivos).

Como el disco es USB, debería ser un dispositivo del tipo /dev/sdx donde x es la letra que identifica el disco duro: sda, sdb ... El disco duro de nuestro ordenador será probablemente sda, así que el disco usb externo será sdb. Tened cuidado de no equivocaros para no cargaros el disco duro de vuestro ordenador.

Una vez seleccionado el disco USB, veréis las particiones que tiene. Debemos desmontar las que aparecen montadas. Podemos desmontarlas con click derecho->desmontar.

Ahora tenemos dos opciones:
  • BORRAR TODO Y CREAR UNA SOLA PARTICION: Si queremos usar el disco usb tan sólo para almacenar los backups de juegos (no podremos usar el disco para nada más, puesto que el formato wbfs es tan sólo para wii). Haremos click derecho sobre las particiones que queremos borrar, y luego en el menú Editar->Aplicar todas las operaciones. Se borrarán las particiones del disco. Una vez borradas crearemos una partición haciendo click derecho ->Nuevo en el espacio sin asignar, pondremos la nueva partición como partición primaria y en sistema de archivos pondremos sin formatear.
  • REDIMENSIONAR UNA PARTICIÓN PARA HACER ESPACIO PARA OTRA NUEVA: Si tenemos datos y no queremos perderlos, podemos redimensionar una de las particiones que tengamos para encogerla y dejar espacio libre. Haremos Click derecho ->Redimensionar / Mover sobre la partición a redimensionar. Indicaremos el nuevo tamaño de disco que queremos tener en la partición a reducir y nos dirá el espacio que nos quedará libre para la nueva partición de backups. Hacemos click en Redimensionar / Mover y aplicamos los cambios con Editar->Aplicar todas las operaciones. Una vez se ha redimensionado la partición (tardará un tiempo), nos habrá quedado un espacio en el disco USB sin asignar. Hacemos click con el botón derecho en el espacio sin asignar->Nuevo y ponemos la nueva partición como partición primaria. En sistema de archivos indicamos sin formatear.
Una vez que tengamos la partición para backups creada, tendremos que inicializarla para que podamos usarla con WBFS.

Tercero: Inicializar la partición wbfs.
Para inicializar la partición utilizamos la aplicación wbfs de la siguiente manera:
# wbfs -p /dev/sdXY init
  • sustituyendo X por la letra de unidad del dispositivo USB.
  • sustituyendo Y por el número de partición.
Por ejemplo, si hemos creado una partición sdb2 en el dispositivo USB para usar con wbfs, ejecutaremos el comando wbfs de la siguiente manera:
# wbfs -p /dev/sdb2 init

Una vez hecho ésto, habremos inicializado el sistema de archivos en la partición creada. Ahora tan sólo tendremos que usar wiithon o nautilus para añadir, borrar, renombrar, extraer... juegos en la partición.

Por último, tan sólo me queda mencionar que wiithon nos facilita la tarea de trabajar con wbfs. No obstante, también podríamos añadir isos usando directamente wbfs. Por ejemplo, si quisiéramos añadir un backup de un juego llamado "backuporiginal.iso" a la partición wbfs sdb2, haríamos lo siguiente:
# wbfs -p /dev/sdb2 add /home/backups/backuporiginal.iso

miércoles, 1 de abril de 2009

Montar un servidor de terminales con LTSP

Últimamente he tenido que montar un par de servidores de terminales. Así que, por si se me olvida lo que he hecho, que se me olvidará... voy a escribir este artículo, y si tengo que volver a hacerlo ya tengo un punto de partida.
No voy a entrar, de momento, en detalles sobre como instalar un servidor dhcp, que es necesario para dar ip a los terminales. Ya lo haré cuando tenga un poco más de tiempo.

LTSP (Linux Terminal Server Project) es un proyecto que nos proporciona un conjunto aplicaciones que nos permitirán conectar muchos equipos con pocos recursos a un servidor Linux. Estos equipos serán clientes ligeros del servidor.

Las aplicaciones que ejecutemos en los clientes correrán directamente en el servidor, que aceptará entradas y mostrará su salida en las pantallas de los clientes ligeros. No obstante, LTSP, en su versión 5, dispone de una herramienta experimental, llamada localapps que nos permite hacer que algunas aplicaciones se ejecuten en el cliente.

Para montar un servidor de terminales, tendremos que instalar los siguientes paquetes, como mínimo:
  • ltsp-server
  • Un servidor tftp, como por ejemplo: atftp.
  • Un servidor dhcp: como dhcp3-server o dnsmasq. En nuestros centros usamos dhcp3-server-ldap porque usamos ldap como backend para almacenar los datos.
Si usamos nfs para servir la imagen a nuestros terminales, instalaremos además:
  • nfs-kernel-server
Y si nuestros terminales reciben la imagen via nbd, instalaremos el paquete:
  • nbd-server
Se necesitan algunos paquetes más, pero como son dependencias, al instalar los paquetes que hemos dicho, se instalarán todos los demás que son necesarios.

Un paquete necesario, que se me olvidaba mencionar, es openssh-server, dado que el tráfico entre el servidor y los clientes viaja encriptado. Pero bueno, es un paquete que se suele tener instalado.

En cualquier caso, si no queremos instalar uno a uno los paquetes mencionados, siempre podemos instalar el paquete ltsp-server-standalone y se instalará todo lo necesario para montar un servidor de terminales:

# apt-get install ltsp-server-standalone

En nuestros centros las imágenes se sirven mediante nbd. Yo tengo instalados tanto nfs-kernel-server como nbd-server. Y con unos pequeños cambios puedo usar un sistema u otro. Por defecto, se usa nfs, así que, luego veremos cómo cambiar a nbd.

ltsp se instala en /opt. Por lo que, al terminar la instalación, tendremos el siguiente directorio: /opt/ltsp
En este directorio se guardará tanto el sistema que compartimos por nfs como las imágenes que servimos vía nbd.
Cuando creemos las imágenes para los clientes, tendremos un subdirectorio por cada tipo de imagen que sirvamos a los terminales. Por ejemplo, si vamos a servir imágenes i386, en /opt/ltsp tendremos un directorio /opt/ltsp/i386. En cuanto a las imágenes a servir por nbd, se almacenarán en /opt/ltsp/images.

Una vez instalados los paquetes, si usamos nfs, tendremos que compartir el directorio /opt/ltsp. Ésto lo haremos añadiendo la siguiente línea al directorio /etc/exports del servidor de terminales:

/opt/ltsp *(ro,no_root_squash,async)

Una vez añadida, hacemos que el servidor nfs relea el archivo /etc/exports ejecuntando en un terminal el comando:

# exportfs -ra

El siguiente paso, será configurar el servidor dhcp que hayamos instalado. De momento, como he dicho anteriormente, no voy entrar en detalles, y, cuando tenga más tiempo, por si a alguien le interesa, publicaré un artículo más detallado explicando cómo configurar dhcp3-server o dnsmasq. En cualquier caso, podemos ver ejemplos sobre cómo configurar dhcp en /usr/share/doc/ltsp-server/examples/dhcpd.conf o /etc/ltsp/dhcpd.conf y adaptarlos a nuestra red.

El siguiente paso, será crear el S.O. para los clientes. Como mis clientes son de arquitectura i386, ejecutamos la herramienta ltsp-build-client, que creará el entorno necesario para los clientes en /opt/ltsp/i386:

# ltsp-build-client --arch i386

Eso sí. Tendremos que tener un buen ancho de banda, porque se bajará un montón de paquetes para crear el entorno chroot. Si no disponemos de un buen ancho de banda, siempre podemos tirar de un mirror local. Yo tengo un mirror local en un disco duro externo y es lo que uso para crear el chroot.

Hay dos archivos en el chroot que nos permiten personalizar el cliente:
  • /etc/lts.conf
  • /etc/default/ltsp-client-setup.
Podemos ver ejemplos de configuración en /usr/share/doc/ltsp-client

Si quisiéramos actualizar los paquetes del entorno chroot para los clientes, primero hacemos el chroot:

# chroot /opt/ltsp/i386

Ahora que estamos en el entorno chroot de los terminales, ejecutamos:

# mount -t proc proc /proc

Actualizamos la lista de paquetes:

# apt-get update

Y actualizamos los paquetes:

# apt-get upgrade

Una vez terminada la actualización del chroot, desmontamos /proc:

# umount /proc

Y tecleamos el comando exit para salir del chroot.

Si nuestro kernel ha sido actualizado, tendremos que ejecutar el comando ltsp-update-kernels para asegurarnos de que nuestro chroot use la última versión:

# ltsp-update-kernels

Todos nuestros clientes usarán el último kernel la próxima vez que se reinicien.

Por último, si estamos usando nbd, ejecutaremos ltsp-update-image para que se cree una versión actualizada de la imagen que se servirá a los terminales:

# ltsp-update-image --arch i386

La primera vez que montemos el servidor de terminales, ejecutaremos:

# ltsp-update-sshkeys

Como el servidor de terminales se comunica con los clientes mediante un canal encriptado, la primera vez es necesario que se creen los certificados SSL. Sin la ejecución de este comando ningún cliente podrá hacer login en el servidor.

También tendremos que ejecutar ltsp-update-sshkeys cuando en el cliente intentemos hacer login y recibamos un error diciéndonos algo así como que "Este esquipo no está autorizado para conectarse al servidor".

Eso sí. Es importante que cuando tengamos que hacer un ltsp-update-sshkeys, primero ejecutemos un ltsp-update-sshkeys y seguidamente hagamos un ltsp-update-image. Y no al revés. También habrá que hacerlo cuando, por lo que sea, cambiemos la IP del servidor de terminales.


Qué usar: ¿nfs o nbd?
En Debian, por defecto, se usa nfs para servir el sistema a los terminales.
La ventaja que tiene usar nfs es que no es necesario crear una imagen. Se usa directamente el sistema montado en /opt/ltsp/i386.
Como desventaja, podemos decir que a mayor número de usuarios el sistema se ralentiza.

Si usamos nbd para servir el sistema a los terminales, la desventaja es que es necesario hacer una imagen comprimida (ltsp-update-image).
La ventaja está en que a mayor número de usuarios el sistema no se hace más lento, si no que se mantiene igual.

¿Cómo cambiar de nfs a nbd?
Primero.- Para usar nbd, lo primero que tenemos que hacer es instalar dos módulos en el chroot:
  • squashfs
  • aufs
Para ello, hacemos el chroot:

# chroot /opt/ltsp/i386

Ahora que estamos en el entorno chroot de los terminales, ejecutamos:

# mount -t proc proc /proc

Actualizamos la lista de paquetes:

# apt-get update

E instalamos los paquetes que nos instalan los módulos squashfs y aufs:

# apt-get install squashfs-modules-2.6.26-1-686 aufs-modules-2.6.26-1-686

Ojo. En el ejemplo tenemos instalado el kernel 2.6.26-1-686, por lo que instalamos los paquetes squashfs y aufs para ese módulo.

Una vez instalados, actualizamos el initrd:

# update-initramfs

Una vez terminado, desmontamos /proc:

# umount /proc

Y tecleamos el comando exit para salir del chroot.

Segundo.- Vamos a modificar dos ficheros:
  • /opt/ltsp/i386/boot/pxelinux.cfg/default
  • /opt/ltsp/i386/etc/default/ltsp-client-setup
En el fichero /opt/ltsp/i386/boot/pxelinux.cfg/default viene una línea como la siguiente: DEFAULT vmlinuz ro initrd=initrd.img quiet root=/dev/nfs ip=dhcp boot=nfs
Para que no se use nfs, la comentamos y ponemos una como la siguiente:
DEFAULT vmlinuz ro initrd=initrd.img quiet

Para no tener que acordarme, así es como tengo el fichero /opt/ltsp/i386/boot/pxelinux.cfg/default:

# Para usar nfs
#DEFAULT vmlinuz ro initrd=initrd.img quiet root=/dev/nfs ip=dhcp boot=nfs

# Para usar nbd
DEFAULT vmlinuz ro initrd=initrd.img quiet

Cuando quiero usar nbd comento la línea nfs y cuando quiero usar nfs comento la línea nbd

Una vez modificado el primer fichero, tenemos que modificar /opt/ltsp/i386/etc/default/ltsp-client-setup
En este segundo fichero lo único que tenemos que cambiar es el parámetro root-write-method=" " por root-write-method="aufs"

Una vez modificados los dos ficheros, como el primero afecta al kernel, ejecutamos un ltsp-update-kernels:

# ltsp-update-kernels

Y como usamos nbd, una vez hecho el ltsp-update-kernels haremos el ltsp-update-image:

# ltsp-update-image --arch i386

Si queremos volver a usar nfs, lo único que tendremos que hacer es modificar los dos ficheros anteriores. No tenemos que volver a crear la imagen, puesto que, mediante nfs, no se usan imágenes.

jueves, 26 de marzo de 2009

Usar teclado numérico como sustituto del ratón

En ocasiones, necesitamos usar el ratón y éste no funciona porque alguien se lo ha cargado y muchas veces los usuarios son tan destructivos que incluso lo rompen a propósito. Para evitar tener que estar reponiendo ratones continuamente, podemos configurar el teclado numérico como sustituto del ratón, de manera que los números 1,2,3,4,6,7,8 y 9 nos servirán para desplazar el puntero y, el número 5 nos hará de botón izquierdo.

En Debian y distribuciones derivadas podemos añadir un fichero al directorio /usr/share/gconf/defaults/ donde especificaremos nuestras preferencias de inicio, como por ejemplo, activar el uso del teclado numérico como sustituto del ratón. ¿Y cómo lo hacemos? Pues muy fácil: Creamos un fichero llamado 25_mispreferencias dentro del directorio anterior:

# touch /usr/share/gconf/defaults/25_mispreferencias

Ahora, para activar la posibilidad de usar el teclado numérico como sustituto del ratón, no tendremos más que ejecutar en el terminal:

# echo "/desktop/gnome/accesibility/keyboard/mousekeys_enable true" >> /usr/share/gconf/defaults/25_mispreferencias

Ésto añadirá una línea al fichero 25_mispreferencias. En lugar de ejecutar el comando, también podríamos editar el fichero y escribir directamente en él la línea que establece la preferencia.

Ahora, cada vez que el usuario desee usar el teclado numérico como sustituto del ratón, no tendrá más que activar dicha posibilidad pulsando las teclas Ctrl+Shift+Bloq.Num
Para desactivarlo, no tenemos más que volver a pulsar la misma combinación de teclas.

Pero si queremos que esta posibilidad se encuentre activada siempre al inicio, añadiremos otra línea más al fichero de preferencias:

# echo "/desktop/gnome/accesibility/keyboard/enable true" >> /usr/share/gconf/defaults/25_mispreferencias

Una vez configuradas las opciones por defecto para gconf, ejecutaremos el comando:

# update-gconf-defaults

Y listo. Una cosa tremendamente útil en lugares donde se rompen demasiados ratones.

Una última cosa: Usando este método definimos las opciones por defecto de gconf. Pero, si el usuario modifica su configuración particular, por ejemplo mediante gconf-editor, prevalecerá la configuración del usuario sobre la configuración por defecto.

update-alternatives: Configurar alternativas en Debian

Se nota que últimamente tengo bastante parado el blog. Bueno, la verdad es que es porque estoy hasta arriba de trabajo y no me queda mucho tiempo libre para escribir nuevos posts. Pero, como me interesa tener ésto anotado en algún sitio, aprovecho y lo publico en el blog.

A veces tenemos diferentes programas o incluso dos paquetes que nos proporcionan dos versiones diferentes de un programa con más o menos la misma funcionalidad; update-alternatives es un script escrito en Perl que nos proporciona una manera de asegurarnos de cuál será la aplicación a usar por defecto de entre varias instaladas para el mismo propósito.

Por ejemplo: Nos han proporcionado un cd de instalación de debian con dos entornos de escritorio: gnome y lxde, con la intención de que podamos instalar el mismo sistema en una máquina independientemente de que tenga muchos o pocos recursos, y se ha establecido que, por defecto se use lxde.
Pues bien, si queremos instalar el sistema con una máquina que tiene recursos de sobra, podemos hacer que se use gnome por defecto, mediante update-alternatives. Para ello, abrimos un terminal y ejecutamos:

# update-alternatives --config x-session-manager

Se nos mostrará la lista de alternativas que provee x-session-manager y podremos elegir la que queremos usar por defecto.

Del mismo modo, podemos cambiar cuál es el editor que se debe usar por defecto en nuestro sistema, con tan sólo ejecutar en un terminal:

# update-alternatives --config editor

Por ejemplo: Si tenemos openjdk y sun-java, podemos elegir la alternativa a usar ejecutando:


# update-alternatives --config java

Y así podremos configurar una larga lista de aplicaciones por defecto. En el directorio /etc/alternatives las encontraremos.

Si queremos configurar todas las posibles alternativas, una tras otra, ejecutaremos:

# update-alternatives --all

Nos irá preguntando una por una. Y en el caso de que sólo haya una opción, nos informará de ello.

Por otra parte, también podremos crear nuestra propia alternativa:

# update-alternatives --install nombre_genérico enlace programa prioridad

Imaginemos que tan sólo tenemos instalado gnome. Pero instalamos lxde y queremos que ésta sea la opción a usar por defecto:

# update-alternatives --install /usr/bin/lxde x-session-manager /usr/bin/startlxde 1

También podemos borrar una alternativa:

# update-alternatives --remove x-session-manager /usr/bin/lxde

sábado, 21 de febrero de 2009

Acceso a máquinas remotas vía ssh sin contraseña

A veces, trabajando como administrador, resulta un poco tedioso tener que teclear la contraseña cada vez que nos conectamos a una máquina remota en la que tenemos que trabajar, más aún si tenemos muchos equipos que controlar.

Para conseguir conectarnos vía ssh a estas máquinas, sin que se nos pida la contraseña, podemos crear una clave pública y otra privada con ssh-keygen. Una vez creadas, no tendremos más que añadir la clave pública al fichero authorized_keys del usuario con el que nos conectamos a la máquina remota.

Veamos paso a paso cómo hacerlo:

Primero, generamos en nuestra máquina un par de claves (privada y pública) mediante ssh-keygen:

# ssh-keygen -t rsa

En el directorio .ssh de nuestro home se creará la clave privada (id_rsa) y la pública (id_rsa.pub). Por ejemplo, si mi usuario es adrian, la clave privada se encontrará almacenada en /home/adrian/.ssh/id_rsa y la clave pública en /home/adrian/.ssh/id_rsa.pub

ssh-keygen nos pedirá una frase de paso. La dejaremos en blanco para que no nos la pida al conectarnos al equipo remoto.

Una vez que hemos generado nuestra clave pública y privada, añadimos nuestra clave pública al fichero ~/.ssh/authorized_keys del usuario que va a tener acceso sin clave en la máquina remota.

Para hacerlo, primero copiamos el fichero id_rsa.pub al home del usuario remoto con el que queremos acceder sin contraseña. Por ejemplo:
# scp /home/adrian/.ssh/id_rsa.pub usuario@servidor:~/

Después nos conectamos a la máquina remota:
# ssh usuario@servidor

Y añadimos el contenido del fichero id_rsa.pub al fichero authorized_keys del usuario con el que accedemos en la máquina remota:
# cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

Por cierto. Este proceso de copia de nuestra clave pública, podemos hacerlo de un plumazo mediante el comando ssh-copy-id:

# ssh-copy-id -i /home/adrian/.ssh/id_rsa.pub usuario@servidor

Y ya está. A partir de ahora, cada vez que nos conectemos a la máquina remota, tendremos acceso sin tener que teclear la password.

Por cierto, si tenemos muchas máquinas que administrar, podemos usar una máquina de pasarela.

viernes, 13 de febrero de 2009

Ahorrar recursos en el servidor NFS con autofs

Un buen cambio que se ha hecho en nuestros centros, entre otras muchas cosas, ha sido montar autofs en los clientes NFS, con lo que se va a reducir de una manera importante la carga de trabajo del servidor.

Si tenemos un servidor NFS y montamos el home de los usuarios en el archivo fstab, estaremos estableciendo una conexión por máquina con el servidor, cada vez que la máquina cliente arranque. Si tenemos pocos usuarios en el sistema no hay problemas, pero si tenemos muchos, el servidor nfs tendrá una carga mayor de trabajo cuanto mayor sea el número de máquinas encendidas.

Para mejorar el rendimiento de nuestro sistema y hacer que las conexiones nfs de los clientes se establezcan tan sólo cuando un usuario las necesite, podemos contar con una utilidad llamada automount que se encargará de montar y desmontar sistemas de archivos nfs automáticamente, ahorrando recursos.

Podemos ejecutar el comando automount para especificar los montajes. No obstante, es más recomendable especificar los montajes que deben hacerse en una serie de ficheros que usa autofs.

Para instalar autofs no tenemos más que hacer un:
# apt-get install autofs

Al instalarlo, se crearán los siguientes archivos de configuración:
  • /etc/auto.master
  • /etc/auto.misc
  • /etc/auto.net
  • /etc/auto.smb
  • /etc/default/autofs
Se arrancará automounter, cargando asó el módulo del kernel que se encargará de los montajes: autofs4

El archivo /etc/auto.master es el principal fichero de automount. Contiene una serie de líneas que se refieren a cada punto de montaje, con una estructura como la siguiente:

Si nos fijamos en el fichero auto.master nada más instalar autofs, veremos que aparecen unas líneas comentadas. Por ejemplo:
/misc /etc/auto.misc --timeout=60

La línea anterior no se va a ejecutar puesto que está comentada, pero quiere decir: Todo lo que está en auto.misc hay que montarlo en /misc y desmontarlo si no se usa cuando lleve sin usarse 60 segundos.

Otro ejemplo típico e interesante: Podemos querer que el directorio home se automonte para los usuarios. Entonces, añadiremos una línea como la siguiente al fichero /etc/auto.master:
/home /etc/auto.home

Luego, crearemos el fichero /etc/auto.home con la cadena de montaje. Por ejemplo:

* -fstype=nfs4,intr,rsize=0192,wsize=8192 servidor:/home

Esta línea hace que si cualquier usuario intenta acceder bajo el directorio local /home se produzca un montaje del servidor servidor:/home en /home.

Por cierto, se me olvidaba: Como autofs se instala como demonio, podemos iniciarlo, pararlo, reiniciarlo... con:
# /etc/init.d/autofs {start|stop|restart|reload|status|getmounts|active}

jueves, 12 de febrero de 2009

unalz: Una herramienta linux para descomprimir ficheros .alz

ALZip es una herramienta que mucha gente ha usado en windows durante tiempo para comprimir/descomprimir archivos. Esta herramienta ha sido gratuita, excepto para uso comercial hasta antes del 1 de Diciembre de 2008. Pero, para nuevas versiones a partir del 1 de Diciembre de 2008, la empresa cambió la licencia, dejando de ser gratuita y pasando a ser una herramienta de pago para todo uso, ya sea personal o comercial.

Para los que usamos linux, hay una utilidad que nos permite descomprimir los archivos .alz: unalz. Por cierto, es una herramienta de línea de comando que tendremos que usar desde un terminal.

A mí me ha sido muy útil cuando me han enviado algún fichero comprimido en este formato.

Veamos algunos ejemplos de uso:

Si queremos descomprimir un archivo, el comando a ejecutar será algo así:
# unalz ficherocomprimido.alz

Si el fichero a comprimir tiene password, ejecutaremos el comando de la siguiente manera:
# unalz -pwd passworddelarchivo ficherocomprimido.alz

Si tan sólo queremos listar los ficheros que contiene el fichero comprimido:
# unalz -l ficherocomprimido.alz

Y si queremos especificar un directorio destino:
# unalz -d directoriodestino ficherocomprimido.alz

Éstas son las opciones más comunes. No obstante, hay algunas opciones más que podéis consultar con man.

miércoles, 11 de febrero de 2009

Dalle: Una herramienta multiplataforma para partir/unir archivos

Ayer necesitaba unir una serie de archivos y no me servía el hacha de linux (hoz). Buscando un poco por ahí, encontré Dalle, una herramienta multiplataforma compatible con los siguientes formatos:
  • Astrotite
  • Axman 3
  • Easy File Splitter
  • File Splitter
  • Genérico
  • Hacha (1, 2 y Pro)
  • KamaleoN (1 y 2)
  • MaxSplitter
  • SplitFile
  • Zip
La página del proyecto es: http://dalle.sourceforge.net

Para descargarlo: http://sourceforge.net/project/showfiles.php?group_id=95720

Como no es algo que use habitualmente, no necesito instalarlo. Así que descargué la versión ejecutable desde aquí: http://downloads.sourceforge.net/dalle/dalle-bin-0.7.8.zip?modtime=1206388293&big_mirror=0

Descomprimí el archivo:
# unzip dalle-bin-0.7.8.zip

Entré en el directorio que se crea al descomprimir:
# cd dalle-bin-0.7.8

Y ejecuté dalle-gtk:
# ./dalle-gtk.exe

Por cierto, este conjunto de aplicaciones están escritas en C. Para ejecutarlas deberemos tener instalado mono.

minicom: Acceso a switches, routers... por el puerto de consola

minicom es una herramienta muy útil que nos permite conectarnos por el puerto serie/usb a un switch, un router, etc... para configurar el dispositivo a través del puerto de consola.

El caso es que, hoy en día, la mayoría de dispositivos ya incorporan un interfaz accesible vía web, pero, en ocasiones, por las circunstancias que sean, no tenemos más remedio que acudir a la consola. Por ejemplo: Hoy mismo estaba haciendo pruebas de configuración de uno de los switches 3com que tengo que preparar, y como me llaman muchas veces, al volver, había reiniciado el switch y no recordaba la configuración de red que le había puesto, por lo que ya no podía acceder vía web. Para poder volver a entrar he usado minicom y he restaurado la configuración de red a través del puerto de consola.

Una cosa a tener en cuenta para usar el puerto de consola, es que la mayoría de cables son serie y, si queremos utilizar un portátil para configurar el dispositivo, como los portátiles ya no suelen tener puerto serie, tendremos que usar un adaptador usb-serial.

Por cierto, si vamos a usar el cable usb-serial, podemos comprobar si se ha cargado el módulo necesario con el comando: lsusb.

Para instalar minicom, no tenemos más que hacer un:

# apt-get install minicom

Una vez instalado, lo lanzamos directamente desde un terminal:

# minicom

Al ejecutarlo nos aparecerá una salida como la siguiente:

Welcome to minicom 2.3

OPCIONES: I18n
Compilado en Feb 24 2008, 16:35:15.
Port /dev/ttyS0

Presione CTRL-A Z para obtener ayuda sobre teclas especiales

Pulsamos Enter y nos pedirá login.

Introducimos el login y nos pedirá el password.

Introducimos el password y ya veremos el menú de configuración del dispositivo.

Ahora bien, como tendremos que configurar puerto, verlocidad, paridad, control de flujo..., lo mejor es que la primera vez lo lancemos con el parámetro -s (de setup):

# minicom -s

Nos aparecerá un menú de configuración de minicom. Vamos a "Configuración de la puerta Serial", indicamos la configuración que deseamos para conectar. Por ejemplo: En los switches que estoy configurando, me indica que debo configurar la aplicación de emulación de terminal con los siguientes valores: 38,400 baud, 8 data bits, no parity and 1 stop bit. Flow control should be disabled. Pues nada, vamos pulsando las letras de las opciones y vamos configurando los valores. Al final, veremos que nos queda algo así:

A - Dispositivo Serial : /dev/ttyS0
B - Localización del Archivo de Bloqueo : /var/lock
C - Programa de Acceso :
D - Programa de Salida :
E - Bps/Paridad/Bits : 38400 8N1
F - Control de Flujo por Hardware: No
G - Control de Flujo por Software: No

Una vez configurado, guardamos los ajustes y en sucesivas ocasiones lo lanzamos sin -s.

Por cierto, si usamos un puerto usb, lanzamos minicom especificando el puerto:

minicom -o /dev/ttyUSB0

Al ejecutarlo nos aparecerá una salida como la siguiente:

Welcome to minicom 2.3

OPCIONES: I18n
Compilado en Feb 24 2008, 16:35:15.
Port /dev/ttyUSB0

Presione CTRL-A Z para obtener ayuda sobre teclas especiales

Y ya podremos instroducir login y password para acceder.

Una última cuestión sobre combinación de teclas. Pulsando:
- Ctrl+A, Z accedemos a la ayuda. (Ctrl+A,soltamos,Z)
- Ctrl+A, Q salimos. (Ctrl+A,soltamos,Q)

Ah, se me olvidaba: A los administradores nos encanta trabajar desde terminales, sobre todo, porque en muchos casos no hay más remedio y es preferible estar acostumbrado.
Para aquellos que prefieran usar una aplicación de emulación de terminal en modo gráfico (tipo Hyperterminal) pueden instalar gtkterm o cutecom.

viernes, 30 de enero de 2009

Ampliar la RAM del eeePC 701 a 2GB

El eeePC 701 viene de serie con un módulo RAM de 512 MB (por lo que he podido probar, más que suficiente para el sistema operativo tan ligero que tiene) y un SO linux llamado Xandros, que está basado en Debian.

Pues bien, en la serie 700 del eeePC, el kernel del Xandros está compilado con un restricción que no nos permite instalar más de 1GB de memoria. Es decir, que si le queremos ampliar la RAM, y queremos montar más de 1GB, no nos reconocerá más que 1GB.

Por cierto, tan sólo tiene una ranura para la memoria RAM (lógico, porque con lo pequeño que es...), con lo que, si queréis ampliar la memoria, tendréis que quitar el módulo y colocar otro de mayor tamaño en su lugar.

Yo le he instalado los 2GB de RAM y la verdad es que no he notado un gran cambio. Va igual de bien que cuando tenía sólo 512MB. Y, a lo mejor, con 1GB hubiera tenido más que suficiente. Claro, que tampoco he usado más que las aplicaciones que venían instaladas.

Para que nos reconozca la memoria y conservar el Xandros, tenemos dos opciones:
  • Recompilar el kernel y eliminar dicha restricción.
  • O bajarnos un kernel ya precompilado por alguien que ya la ha eliminado.
La opción más entretenida es recompilar el kernel, pero, para no complicarse, lo más fácil es bajárselo. Un enlace para descargarlo: http://www.mediafire.com/?rz3jjey7x30

Para montarlo, debemos saber que el eeePC contiene 4 particiones en su disco SDD:
  • La primera partición (/dev/sda1) es de tipo ext2 y contiene el sistema operativo montado como sólo lectura.
  • La segunda partición (/dev/sda2) se monta sobre la primera mediante unionfs/aufs (unionfs en los equipos de la serie 700 y aufs en equipos posteriores como los de la serie 900).
  • Las particiones tercera (/dev/sda3) y cuarta (/dev/sda4) son de tipo FAT y no se usan.
El hecho de montar la primera partición como sólo lectura y la segunda sobre ella, sirve para permitir tener un sistema recuperable. Los cambios se guardan sobre la segunda partición, de tal manera que, en cualquier momento, podremos restaurar el sistema operativo como venía de fábrica. La desventaja: Que se ocupa más espacio. Si tenemos una aplicación que viene de fábrica, y la actualizamos, en la primera partición se encontrará la copia que viene de fábrica y la más reciente quedará en la segunda partición. Con lo que tenemos redundancia de software ocupando espacio. Ésto está hecho para que el usuario pueda recuperar fácilmente su sistema ante un fallo.

Para cambiar el kernel yo he usado un system rescue cd que tengo montado en un pendrive.
Cómo lo hice: Conecté el pendrive antes de encender el eeePC y lo encendí, pulsando ESC después de encenderlo para que me permitiera elegir el disposivo de arranque. Una vez elegido el arranque desde USB, se inició el system rescue.

Una vez arrancado el system rescue, monté la partición /dev/sda1 en /mnt/custom:
# mount /dev/sda1 /mnt/custom

Después, cambié al directorio /mnt/custom/boot/grub:
# cd /mnt/custom/boot/grub

Hice una copia de seguridad del menu.lst, por si acaso:
# cp /mnt/custom/boot/grub/menu.lst /mnt/custom/boot/grub/menu.lst.original

Copié el kernel, que, antes había pasado al pendrive, en el directorio /mnt/custom/boot/

Modifiqué el fichero /mnt/custom/boot/grub/menu.lst, añadiendo una entrada nueva para arrancar el nuevo kernel:

title Xandros 2GB kernel
root (hd0,0)
kernel /boot/vmlinuz-2.6.21.4-eeepc-2GB quiet rw vga=785 irqpoll i8042.noloop=1 root=/dev/sda1
initrd /boot/initramfs-eeepc.img


Una vez añadida la entrada, guardamos el menu.lst, desmontamos el pendrive, reiniciamos y listo.