Algo de Linux

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

noreply@blogger.com (Esteban M. Navas) — Fri, 13 Nov 2009 08:44:00 +0000

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/*

KolourPaint: El Paint de Linux

noreply@blogger.com (Esteban M. Navas) — Wed, 04 Nov 2009 16:52:00 +0000

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.

Analizar los logs de access.log de squid

noreply@blogger.com (Esteban M. Navas) — Tue, 27 Oct 2009 20:05:00 +0000

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:

Mensajes que comienzan con "TCP_": Se refieren a peticiones que nos llegan por el puerto HTTP.
Mensajes que comienzan con "UDP_": Se refieren a peticiones que llegan por el puerto ICP.

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:

UDP_HIT: Nos informa de que tenemos una copia válida del objeto solicitado en la cache.

UDP_MISS: Indica que el objeto que ha sido solicitado no está en nuestra cache.

Además, veremos también códigos de resultado de la fuente de la página:

FIRST_UP_PARENT: El objeto ha sido pedido al padre que aparece disponible el primero en nuestra lista. Esto tiene lugar cuando utilizamos una jerarquía de cachés.

SIBLING_HIT: El objeto ha sido pedido a uno de nuestros proxies hermanos que responde con un UDP_HIT.

DIRECT: El objeto solicitado ha sido servido directamente por el servidor original.

NONE: El objeto solicitado no es servido por ningún compañero.

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.

Problemas con splash en grub

noreply@blogger.com (Esteban M. Navas) — Mon, 28 Sep 2009 09:29:00 +0000

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.

mkisofs: Crear iso

noreply@blogger.com (Esteban M. Navas) — Thu, 24 Sep 2009 20:58:00 +0000

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

noreply@blogger.com (Esteban M. Navas) — Thu, 24 Sep 2009 20:48:00 +0000

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.

Cambiar IP pública del router Comtrend en JDownloader

noreply@blogger.com (Esteban M. Navas) — Mon, 06 Jul 2009 12:39:00 +0000

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]]]

Actualizar BIOS del EEEPC 701

noreply@blogger.com (Esteban M. Navas) — Sat, 04 Jul 2009 08:49:00 +0000

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.

sshfs: Montar directorios remotos de forma segura

noreply@blogger.com (Esteban M. Navas) — Sun, 21 Jun 2009 15:13:00 +0000

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

killall en Lenny

noreply@blogger.com (Esteban M. Navas) — Mon, 15 Jun 2009 09:44:00 +0000

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.

Administración centralizada de equipos mediante PUPPET

noreply@blogger.com (Esteban M. Navas) — Wed, 10 Jun 2009 15:37:00 +0000

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

WBFS: Wii Backup File System

noreply@blogger.com (Esteban M. Navas) — Fri, 05 Jun 2009 16:27:00 +0000

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:
# wget http://www.speedyshare.com/data/790517126/16340244/92166603/wiithon%20v0.98%20r6.tar.gz

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/?9amueyatlvn

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

Montar un servidor de terminales con LTSP

noreply@blogger.com (Esteban M. Navas) — Wed, 01 Apr 2009 15:41:00 +0000

Ú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.

Usar teclado numérico como sustituto del ratón

noreply@blogger.com (Esteban M. Navas) — Thu, 26 Mar 2009 17:33:00 +0000

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 añadir una línea como la siguiente al archivo:

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

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

noreply@blogger.com (Esteban M. Navas) — Wed, 25 Mar 2009 23:20:00 +0000

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

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

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

noreply@blogger.com (Esteban M. Navas) — Fri, 20 Feb 2009 23:06:00 +0000

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

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.

Ahorrar recursos en el servidor NFS con autofs

noreply@blogger.com (Esteban M. Navas) — Fri, 13 Feb 2009 17:20:00 +0000

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}

unalz: Una herramienta linux para descomprimir ficheros .alz

noreply@blogger.com (Esteban M. Navas) — Thu, 12 Feb 2009 20:48:00 +0000

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.

Dalle: Una herramienta multiplataforma para partir/unir archivos

noreply@blogger.com (Esteban M. Navas) — Wed, 11 Feb 2009 20:27:00 +0000

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

noreply@blogger.com (Esteban M. Navas) — Wed, 11 Feb 2009 10:55:00 +0000

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.

Ampliar la RAM del eeePC 701 a 2GB

noreply@blogger.com (Esteban M. Navas) — Fri, 30 Jan 2009 11:47:00 +0000

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.

Discos de arranque con Freedos

noreply@blogger.com (Esteban M. Navas) — Sat, 20 Dec 2008 20:56:00 +0000

A veces necesitamos un floppy autoarrancable con formato DOS, para actualizar, por ejemplo, la BIOS de nuestro equipo, o para arrancar alguna aplicación DOS que haga algo en el proceso de inicio de nuestra máquina.

Como no uso windows, no puedo crear un disco de inicio, así que recurro a FreeDOS, un sistema operativo compatible DOS, que me permite disponer de un floppy bootable sin la necesidad de recurrir a versiones propietarias de DOS. Todo lo que necesitamos es una imagen de disquete con el kernel FreeDOS. En http://www.fdos.org/bootdisks/ encontraremos varias imágenes que se adaptarán a nuestras necesidades.
Desde allí podemos bajar una imagen de floppy con el sistema operativo FreeDOS completo, o una imagen OEM que tan sólo contiene el kernel y el command.com, y que nos deja más espacio para añadir todo lo que necesitemos al floppy, como por ejemplo, una utilidad para flashear nuestra BIOS.

Las imágenes de disquete de esta página se encuentran disponibles en dos formatos:

En formato .imz, comprimidas con pkzip, que podemos descomprimir con unzip, winzip, u otra herramienta similar.
En formato .gz, comprimidas con gzip y que podemos descomprimir usando gzip -d, winzip, u otra herramienta similar.

Podéis descargar una imagen OEM de la siguiente manera:
# wget http://www.fdos.org/bootdisks/autogen/FDOEM.144.imz

Y descomprimirla con unzip:
# unzip FDOEM.144.imz

Una vez descargada, obtendremos un archivo llamado: FDSTD.144
Si queremos personalizarlo, para añadir cosas al disquete, creamos una carpeta temporal:
# mkdir /mnt/floppy
# mount -o loop FDSTD.144 /mnt/floppy

Y copiamos al directorio lo que necesitemos para personalizar el disquete.

Una vez copiado lo que sea, desmontamos el disco y listo. Ya tendremos nuestra imagen de disquete personalizado.

Si no tenemos floppy, podemos crear una iso del floppy y grabarlo en un CD:
# mkisofs -o bootcd.iso -b FDOEM.144 FDOEM.144

ms-sys: Una herramienta para crear registros de arranque compatibles con Microsoft

noreply@blogger.com (Esteban M. Navas) — Fri, 19 Dec 2008 20:27:00 +0000

ms-sys es una de esas herramientas que no usamos habitualmente, pero que nos viene muy bien tener a mano a aquellos que trabajamos con sistemas Linux. Por ejemplo, cuando tenemos que crear un floppy de arranque para actualizar la bios del equipo.

Podemos usar ms-sys para crear sectores de arranque Microsoft.

Para que os hagáis una idea, esta utilidad es capaz de hacer lo mismo que el comando
"fdisk /mbr" en windows. Así que, con esta utilidad puedo reestablecer el MBR de una máquina windows sin necesidad de usar windows.

También es capaz de establecer el sector de arranque a un floppy para convertirlo en un disquete de arranque. O a una partición FAT para que ésta sea arrancable. Lo que no hace es conpiar ningún sistema de ficheros. Tan sólo escribe el sector de arranque. Con lo que, si queremos que el disquete arranque, tendremos que copiarle los ficheros de sistema.

Modo de uso:
ms-sys [opciones] [dispositivo]

Pego a continuación la lista de opciones que podemos utilizar con ms-sys (sacada de la ayuda):

-1, --fat12 Write a FAT12 floppy boot record to device
-2, --fat32nt Write a FAT32 partition NT boot record to device
-3, --fat32 Write a FAT32 partition DOS boot record to device
-4, --fat32free Write a FAT32 partition FreeDOS boot record to device
-5, --fat16free Write a FAT16 partition FreeDOS boot record to device
-6, --fat16 Write a FAT16 partition DOS boot record to device
-l, --wipelabel Reset partition disk label in boot record
-p, --partition Write partition info (hidden sectors, heads and drive id) to boot record
-m, --mbr Write a Windows 2000/XP/2003 MBR to device
-9, --mbr95b Write a Windows 95B/98/98SE/ME MBR to device
-d, --mbrdos Write a DOS/Windows NT MBR to device
-s, --mbrsyslinux Write a public domain syslinux MBR to device
-z, --mbrzero Write an empty (zeroed) MBR to device
-f, --force Force writing of boot record
-h, --help Display this help and exit
-v, --version Show program version
-w, --write Write automatically selected boot record to device

Default Inspect current boot record

Podemos descargar ms-sys desde el siguiente enlace: http://ms-sys.sourceforge.net/

Instalarlo es sencillo: Primero descargamos el código fuente de la aplicación. Una vez descargado, lo extraemos:

# tar xfv ms-sys*.tgz

(En las instrucciones dice que hay que descomprimir usando tar -xzvf, pero debe ser una errata porque no está comprimido con gzip. Al menos el fichero que yo he descargado)

Una vez extraído el código fuente, entramos dentro del directorio que se nos ha creado al extraer:

# cd ms-sys

Compilamos:

# make

E instalamos:

# make install

Ejemplos de uso:

Si queremos escribir el MBR de un disquete, no tenemos más que hacer:
# ms-sys -w /dev/fd0

Si lo que queremos es escribir el MBR de un disco duro:
# ms-sys -w /dev/hda

Si lo que queremos es hacer arrancable una partición FAT:
# ms-sys -w /dev/hdaX

donde X será el número de partición.

Compartir archivos entre máquinas Linux vía NFS

noreply@blogger.com (Esteban M. Navas) — Tue, 16 Dec 2008 17:45:00 +0000

¿Qué es NFS?

NFS (Network File Sistem o Sistema de Ficheros de Red) es una solución ofrecida por los sistemas operativos UNIX/Linux para compartir archivos en redes TCP/IP. Fue desarrollado por SUN Microsystems bajo licencia GPL, lo que facilitó que se convirtiera en un estándar a la hora de convertir archivos en red.

NFS nos permite montar una partición de una máquina remota en un directorio de nuestra máquina como si fuera una partición local.

Veamos qué necesitamos instalar.

Si queremos que nuestra máquina pueda utilizar recursos compartidos por un servidor nfs, instalaremos los paquetes nfs-common y portmap.
Y si lo que queremos es que nuestra máquina pueda realizar ambas funciones: compartir sus recursos y conectarse a otros compartidos, instalaremos los paquetes: nfs-kernel-server y portmap. En este caso, también necesitamos el paquete nfs-common, pero como es una dependencia del paquete nfs-kernel-server, al instalar nfs-kernel-server se instalará también nfs-common.

Lo primero: El portmap.

Como en todos los casos necesitamos portmap, lo primero que hacemos es comprobar si está corriendo.

Sin entrar en muchos detalles, podemos decir que portmap es el mapeador de puertos de linux. Este mapeador se encarga de gestionar la asignación entre aplicaciones y puertos.
Lo normal es que el portmap se encuentre ya instalado.

Para saber si tenemos el portmap instalado y corriendo, no tenemos más que hacer un:

# ps aux | grep portmap

Si está corriendo, la salida del comando anterior será más o menos como la siguiente:

daemon 4204 0.0 0.0 1912 528 ? Ss 16:31 0:00 /sbin/portmap

Si no está corriendo, a lo mejor es porque no está instalado. Así podemos comprobar si está instalado:

# dpkg -l | grep portmap

Si el comando anterior no nos devuelve nada, es porque no está instalado. En ese caso, lo instalamos:

# apt-get install portmap

Si queremos que nuestro equipo pueda compartir recursos. Servidor NFS.

1.- Instalamos nfs-kernel-server.
Una vez que tengamos portmap funcionando, lo que haremos será instalar el paquete nfs-kernel-server. Como ya comentamos antes, al instalarlo, también se instalará el nfs-common:

# apt-get install nfs-kernel-server

Una vez instalado, podemos comprobar si NFS está en marcha haciendo una consulta al portmap, pidiéndole que nos indique qué servicios tiene en marcha:

# rpcinfo -p

El comando nos mostrará todos los servicios que están en marcha, entre ellos el nfs. Como la salida es bastante extensa, os muestro tan sólo las líneas correspondientes al nfs que está corriendo en mi máquina:

100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs

Si no aparece, debemos comprobar si hay algún problema con los paquetes instalados.

2.- Compartimos directorios
Una vez tenemos los servicios en marcha únicamente nos falta determinar qué queremos compartir. Imaginemos que queremos compartir un directorio llamado backup que se encuentra en el directorio var y en el que almacenaremos las copias de seguridad de una máquina remota:

Para compartir un directorio, debemos editar el archivo /etc/exports e introducir una línea con datos referentes al directorio que queremos compartir, con qué máquinas lo vamos a compartir y las opciones de compartición. Cada línea del /etc/exports tendrá la forma:

directorioacompartir maquinasconlasquecompartir(opcionesdeexportación)

- En directorioacompartir especificamos la ruta absoluta del directorio a compartir.

- En máquinasconlasquecompartir podemos especificar:

Un * para compartir con todo el mundo.
Una dirección IP para compartir con una máquina concreta.
Un rango de direcciones IP con las que compartir, especificando la ip de red y la máscara.
Un wildcard con el que compartiremos con las máquinas de un dominio.

- En opcionesdeexportación podemos usar muchas opciones:

ro para compartir el directorio en modo sólo lectura.
rw para compartir el directorio en modo lectura/escritura.
root_squash para conseguir que un usuario root del cliente no pueda escribir con permisos de root en el directorio compartido.
no_root_squash hace que se permita que un usuario root del cliente pueda escribir con permisos de root en el directorio compartido.
sync hace que el servidor no atienda peticiones antes de que los cambios hechos por una petición de escritura sean escritos en disco.
async hace que el servidor atienda peticiones sin comprobar si los cambios hechos por una petición de escritura se han escrito en disco. Es la opción por defecto, si no se especifica nada.
subtree_check si se exporta un subdirectorio (no un sistema de ficheros completo) al producirse una petición de un fichero, el servidor comprueba que el fichero solicitado esté en el árbol de directorios exportado.
no_subtree_check desactiva la comprobación de subtree_check.

Veamos algunos ejemplos de líneas que podemos incluir en /etc/exports:

/usr/local 192.168.1.0/255.255.255.0(rw,subtree_check)
/var/software 192.168.1.0/24(ro)
/backup 172.19.123.2(rw,no_root_squash,sync)
/tftpboot/boot-image *(rw,no_root_squash,snyc)

3.- Aumentando un poco la seguridad
La única vez que NFS lleva a cabo la autentificación es cuando el cliente intenta montar un recurso compartido NFS. Para limitar el acceso al servicio NFS y aumentar un poco la seguridad, se utilizan los TCP wrappers.

Los TCP wrappers leen los archivos /etc/hosts.allow y /etc/hosts.deny para determinar si a un cliente particular o red tiene acceso o no al servicio NFS.

Lo primero que se comprueba es si el cliente tiene acceso mediante los TCP wrappers. Una vez que al cliente se le permite acceso gracias a un TCP wrapper, el servidor NFS recurre a su archivo de configuración (/etc/exports), para determinar si el cliente tiene suficientes privilegios para acceder a los sistemas de archivos exportados.

Una vez otorgado el acceso, todas las operaciones de archivos y de directorios están disponibles para el usuario.

Podemos establecer un poco más de seguridad usando /etc/hosts.allow y /etc/hosts.deny para especificar qué ordenadores de la red pueden usar los servicios del servidor nfs.

Por ejemplo:

/etc/hosts.deny
portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

/etc/hosts.allow
portmap:192.168.1.0/255.255.255.0
lockd:192.168.1.0/255.255.255.0
mountd:192.168.1.0/255.255.255.0
rquotad:192.168.1.0/255.255.255.0
statd:192.168.1.0/255.255.255.0

Suponiendo que nuestra red local es la 192.168.1.0, de este modo, denegamos el acceso a todo el mundo, y luego permitimos el acceso tan sólo a las máquinas de nuestra red.

4.- Activar la compartición de archivos
Cada vez que hagamos cambios en el fichero /etc/exports, debemos hacer que nfs vuelva a cargarlo, con el fin de que se apliquen las restricciones que hay en él. Para ello no tenemos más que ejecutar el siguiente comando:

# exportfs -ra

Y listo. Ya tenemos nuestro servidor nfs funcionando.

Si queremos que nuestro equipo pueda usar recursos nfs de otras máquinas. Cliente NFS.

1.- Instalamos nfs-common
Para poder conectarnos a los recursos nfs de servidores, lo que haremos es configurar el equipo como cliente NFS. Para ello, recordemos que debíamos instalar portmap y nfs-common.

Así que, siguiendo las instrucciones del comienzo, comprobamos que tenemos funcionando portmap en el equipo cliente. Una vez comprobado, instalamos nfs-common:

# apt-get install nfs-common

Y ya podemos conectarnos a los recursos de otras máquinas desde un equipo cliente.

2.- Ver qué recursos compartidos en una máquina
Si queremos ver qué directorios tiene compartidos una máquina vía NFS, ejecutamos el comando showmount en la máquina cliente con el parámetro -e:

# showmount -e IPSERVIDOR

Por ejemplo, si tenemos un servidor NFS cuya IP es 192.168.1.2 y queremos ver, desde nuestra máquina cliente, qué directorios tiene exportados, ejecutaremos el comando:

$ showmount -e 192.168.1.2

3.- Conectarse a un recurso compartido de un servidor NFS
Podemos conectarnos a un directorio compartido en una máquina remota, usando el comando mount:

# mount IPServidorNFS:/DirectorioCompartido PuntodeMontaje

Ejemplo: Imaginemos que tenemos un servidor NFS con la siguiente dirección IP: 192.168.1.2 y un directorio compartido: /var/descargas. Supongamos también que en la máquina cliente tenemos un directorio llamado /mnt/nfs donde vamos a montar el directorio de la máquina remota. Montaremos el directorio compartido de la siguiente manera:

# mount 192.168.1.2:/var/descargas /mnt/nfs

Si hacemos un ls /mnt/nfs veremos que el directorio del servidor se encuentra montado.

4.- Conectarse a un recurso compartido cada vez que se inicie la máquina cliente
Si queremos que el directorio compartido vía NFS sea montado en la máquina cliente cada vez que ésta arranque, debemos añadir una entrada en el fichero /etc/fstab.

Imaginemos que tenemos el directorio home compartido en un servidor nfs y queremos montarlo en los clientes. Añadiríamos una línea al fichero fstab de la máquina cliente para montarlo en cada inicio:

192.168.1.2:/home /home nfs rw,hard,intr 0 0

update-rc.d: Actualizando el arranque/parada de servicios

noreply@blogger.com (Esteban M. Navas) — Fri, 12 Dec 2008 00:16:00 +0000

El comando update-rc.d nos permite automatizar el proceso de creación y borrado de enlaces a los scripts de inicio, con en fin de iniciar/parar servicios.

Eliminar servicios del proceso de arranque:

Si queremos eliminar servicios del proceso de arranque, no tenemos más que ejecutar el siguiente comando como root:

# update-rc.d -f nombre_proceso remove

Veamos un ejemplo. Supongamos que tenemos el proceso squid y queremos eliminarlo para que no arranque, ejecutaremos el siguiente comando:

# update-rc.d -f squid remove

Iniciar nuevos servicios en el proceso de arranque:

Si queremos crear enlaces usando parámetros por defecto, ejecutaremos:

# update-rc.d nombre_proceso defaults

Al usar la opción defaults, update-rc.d creará enlaces para arrancar los servicios en los niveles de ejecución 2345 y parar los servicios en los niveles de ejecución 016. Por defecto, todos los enlaces tendrán el código de secuencia 20.

Ejemplo. Si ejecutamos:

# update-rc.d ssh defaults

Se crearán enlaces para arrancar el servicio ssh en los niveles 2345 y pararlo en los niveles 016.
Lo que sería equivalente a ejecutar:

# update-rc.d ssh start 20 2 3 4 5 . stop 20 0 1 6 .

O, si así lo preferimos, podemos especificar los niveles en que arranca un proceso, los niveles en los que para, así como la prioridad.

Ejemplo:

# update-rc.d xdm start 20 2 5 . stop 20 0 1 2 6 .