Algo de Linux: mayo 2012

jueves, 31 de mayo de 2012

Puppet: Guía del lenguaje y Cheat sheets

Para los que trabajamos habitualmente con puppet, nos viene muy bien tener a mano la guía del lenguaje:

http://docs.puppetlabs.com/guides/language_guide.html

Y una chuleta -cheat sheet- que es recomendable imprimir:

http://docs.puppetlabs.com/puppet_core_types_cheatsheet.pdf

Instalar las X en un servidor Debian

A veces necesitamos un servidor gráfico para ciertas cosas que no podemos hacer desde un terminal, por ejemplo en una máquina que usamos de pasarela en la que nos es necesario poder realizar conexiones gráficas para manejar alguna herramienta, pero no queremos tener un escritorio completo.

La opción más sencilla es instalar un entorno gráfico mínimo y posteriormente añadirle tan sólo lo que vayamos necesitando.

Esto podemos hacerlo sencillamente instalando xorg y gnome-core:
 # apt-get install xorg gnome-core

Si en algún momento tuviéramos que iniciar una sesión gráfica en local, arrancaríamos el servidor con:

# startx

Y si tuviéramos que ejecutar por ejemplo el navegador web de nuestro equipo pasarela, de forma remota, podríamos hacer lo siguiente:

# ssh -p 2211 -X remoto@miservidor.dnsdynamic.com

Suponiendo que tenemos el servidor ssh escuchando en el puerto 2211 con un usuario de nombre "remoto" al que le está permitido el acceso a nuestra pasarela: miservidor.dnsdynamic.com

miércoles, 30 de mayo de 2012

lpstat: Controlar el estado de nuestras impresoras

lpstat es una herramienta que nos va a permitir obtener información del sistema de impresión cups: las impresoras, los trabajos, las clases definidas desde la línea de comandos.

Si ejecutamos lpstat sin parámetros veremos la lista de trabajos en cola de impresión del usuario actual. 

# lpstat

Ahora bien, si queremos obtener información completa acerca del servidor de impresión, podemos usar el parámetro -t:

# lpstat -t

La salida del comando nos mostrará si el planificador está corriendo o no, las impresoras instaladas y su estado, así como la impresora por defecto. Ejemplo:

el planificador de tareas se está ejecutando
destino predeterminado del sistema: HPLaserJet
tipo de conexión para CUPS-PDF: cups-pdf:/
tipo de conexión para DESKJET_840C: hp:/usb/DeskJet_840C?serial=CN09O1P1ZPKV
tipo de conexión para HPLaserJet: parallel:/dev/lp0
CUPS-PDF aceptando peticiones desde mié 30 jun 2010 16:57:37 CEST
DESKJET-840C aceptando peticiones desde mié 16 may 2012 16:11:21 CEST
HPLaserJet aceptando peticiones desde mié 30 may 2012 18:04:29 CEST
la impresora CUPS-PDF está inactiva.  activada desde mié 30 jun 2010 16:57:37 CEST
la impresora DESKJET-840C está inactiva.  activada desde mié 16 may 2012 16:11:21 CEST
la impresora HPLaserJet está inactiva.  activada desde mié 30 may 2012 18:04:29 CEST
    Lista para imprimir.

Si lo que queremos es obtener la lista de trabajos completados:

# lpstat -W completed 

Y si queremos obtener la lista de trabajos incompletos:

# lpstat -W not-completed 

miércoles, 23 de mayo de 2012

wakeonlan en un equipo con varias interfaces de red

wakeonlan es una herramienta que usamos para encender equipos de forma remota a través de la red. Esta utilidad envía paquetes especiales para levantar el equipo mediante el interfaz de red. Naturalmente esta función debe estar activada en nuestra bios y soportada por la tarjeta de red.

Cuando queremos encender un equipo de nuestra red mediante wakeonlan tan sólo tenemos que indicarle al comando la dirección MAC de la tarjeta de red del equipo:

# wakeonlan 01:02:03:04:05:06

Si queremos encender más de un equipo, indicamos todas las MAC's de los mismos:

# wakeonlan 01:02:03:04:05:06   01:02:03:07:08:07

Por otro lado, también podemos incluir las direcciones MAC en un archivo y ejecutar wakeonlan con el parámetro -f nombrearchivo para encender todos los equipos cuyas MAC estén almacenadas en el archivo:

# wakeonlan -f equipossalaprofesores

Además, cuando tenemos el equipo desde el que encendemos los demás conectado, por ejemplo, a dos redes diferentes, debemos indicarle también la dirección de broadcast de la red en cuestión. 

Por ejemplo: Suponiendo que tengo un equipo con dos interfaces de red. Una conectada a una red que tiene dos rangos 172.19.144.0-172.19.145.0 y otra conectada a otra red 192.168.2.0 y quiero encender una máquina que se encuentra en el rango 172.19.144.0-172.19.145.0, no tengo más que especificar, mediante el parámetro -i, la dirección de broadcast de esta red para encenderlos:

# wakeonlan -i 172.19.145.255 -f equipossalaprofesores

Cambiar el navegador por defecto en Debian Squeeze

Normalmente, cuando queremos cambiar el navegador por defecto, no tenemos más que ejecutar:

# update-alternatives --config x-www-browser

Y seleccionar el navegador que queremos usar por defecto.

Hoy me comentaba un compañero que, después de haber instalado google chrome, éste se le había quedado configurado como navegador por defecto para algunas cosas, como por ejemplo cuando abría un archivo html y precisamente, con chrome no se le abrían los recursos que necesitaba.

Personalmente, me había dado cuenta de que tras instalar google chrome, cuando hacía clic sobre un enlace a una web en el correo, éste se me abría con chrome, pero no me había importado mucho.

El caso es que a raíz de su problema, he revisado mi equipo y me he dado cuenta de que, además de la alternativa x-www-browser hay otra alternativa para el navegador: gnome-www-browser.

Si queremos que todo se abra con el mismo navegador, tendremos también que configurarla:

# update-alternatives --config gnome-www-browser

lunes, 21 de mayo de 2012

DNS dinámico con DNSdynamic

En ocasiones nos vemos obligados a usar un servicio de DNS dinámico para lograr acceder a máquinas remotas debido a que nuestro proveedor de acceso a internet nos ofrece IP dinámica. 

Muchas veces hemos recurrido a dyndns o no-ip para ello. Lo que sucede es que actualmente, dyndns tan sólo ofrece 14 días de prueba en el servicio dyndns pro y no-ip nos obliga a estar reactivando el servicio gratuito cada 30 días, si no recuerdo mal. Y claro, para un usuario doméstico puede que ninguna de estas dos opciones resulte interesante.

Pero no hay problema porque podemos recurrir a DNSdynamic, un servicio de dns dinámico gratuito, seguro e ilimitado en cuanto a número de registros de dns que podemos utilizar, que también nos ofrece acceso vpn.

Además, en la página de DNSdynamic nos aseguran que su servicio siempre será gratuito.


miércoles, 9 de mayo de 2012

Actualizar Debian Squeeze automáticamente mediante unattended-upgrades

Echando un vistazo a los últimos portátiles con Debian Squeeze que nos enviaron, me di cuenta de que tenían "ciento y pico" paquetes por actualizar y pensé que si conseguía actualizarlos con frecuencia de una manera automática, no se acumularían tantas actualizaciones y éstas se realizarían mejor y con un menor consumo de ancho de banda en la red.

unattended-upgrades, una aplicación para realizar instalaciones automáticas de actualizaciones de seguridad, es una herramienta ideal para resolver este problema.

Instalar unattended-upgrades es muy sencillo en Debian:

# apt-get install unattended-upgrades

Una vez instalado el paquete, creamos el fichero /etc/apt/apt.conf.d/10periodic con el siguiente contenido:

APT::Periodic::Enable "1"; 
APT::Periodic::Update-Package-Lists "1"; 
APT::Periodic::Download-Upgradeable-Packages "1"; APT::Periodic::AutocleanInterval "7"; 
APT::Periodic::Unattended-Upgrade "1"; 
APT::Periodic::RandomSleep "900";

Este fichero nos servirá para configurar las actualizaciones periódicas. Veamos lo que significa cada línea con un ejemplo:

  • APT::Periodic::Enable "1";  Activamos las actualizaciones automáticas poniendo el valor a 1 o las desactivamos poniendo el valor a 0.
  • APT::Periodic::Update-Package-Lists "1"; Hacemos un apt-get update. Si ponemos el valor a 0 lo desactivamos.
  • APT::Periodic::Download-Upgradeable-Packages "1"; Descargamos los paquetes actualizables. Si ponemos el valor a 0 lo desactivamos.
  • APT::Periodic::AutocleanInterval "7"; Hacemos un apt-get autoclean cada 7 días. Si ponemos el valor a 0 lo desactivamos.
  • APT::Periodic::RandomSleep "900"; El trabajo de actualización se iniciará de forma aleatoria entre 1 y 900 segundos.
  • APT::Periodic::Unattended-Upgrade "1"; Ejecutar el script"unattended-upgrade" cada día. Si ponemos el valor a 0 lo desactivamos.    
Una vez creado el fichero, modificamos el siguiente: /etc/apt/apt.conf.d/50unattended-upgrades, quitando el símbolo de comentario en las líneas del siguiente bloque que queramos:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id} stable";
        "${distro_id} ${distro_codename}-security";
        "${distro_id} ${distro_codename}-updates";
//      "${distro_id} ${distro_codename}-proposed-updates";
};

En el ejemplo anterior, permitimos que se actualicen los paquetes del sistema estable, security y updates.

Y listo. Si queremos, para asegurarnos podemos parar unattended-upgrades:

# /etc/init.d/unattended-upgrades stop

Y volver a iniciarlo:

# /etc/init.d/unattended-upgrades start

Por otra parte, podemos ejecutar el script unattended-upgrade manualmente:

# unattended-upgrade

Podemos ejecutar unattended-upgrade en modo debug:

# unattended-upgrade -d

O simular la ejecución de unattended-upgrade sin llegar a actualizar:

# unattended-upgrade --dry-run

lunes, 7 de mayo de 2012

Instalar tarjeta de red AR8151 en Proxmox VE 2.1

Proxmox es una plataforma de virtualización Open Source desarrollada y mantenida por Proxmox Server Solutions GmbH

Hace tiempo probamos la versión 1.9 de Proxmox y tuvimos problemas para instalar el módulo de la tarjeta de red de nuestros equipos: Una Gigabit Ethernet con chipset AR8151. Después de unos cuantos intentos, conseguí que la tarjeta de red funcionara instalando el kernel pve-kernel-2.6.35-2-pve.

Proxmox está basado en Debian y la versión 1.9 concretamente en Debian Lenny. Como Lenny ya no es estable en Debian, hemos decidido probar la versión 2.1 de Proxmox, que ya está basada en Squeeze. Y hemos vuelto a tropezar con el mismo problema: La tarjeta de red con chipset AR8151 tampoco funciona en nuestros equipos y para colmo, en los repositorios de Proxmox no aparecen el kernel pve-kernel-2.6.35-2-pve con el que habíamos resuelto el problema en la versión anterior.

Esta vez hemos optado por descargar el driver e instalarlo desde http://code.google.com/p/iats/downloads/detail?name=AR81Family-Linux-v1.0.1.9.tar.gz&can=2&q=

Obtenemos la lista de dispositivos pci de nuestro equipo:

# lspci

Y comprobamos en el listado que nuestra tarjeta de red está en 02:00.0 y tiene un chipset AR8151:

02:00.0 Atheros AR8151 v1.0

Ahora ejecutamos:

# lspci -n

para  comprobar exactamente el identificador pci de la tarjeta de red tenemos. Obtendremos una salida como la siguiente:

02:00.0 0200: 1969:1073 (rev 0c)

Con ésto podremos buscar el driver necesario para ella.

A continuación, instalamos las herramientas de compilación necesarias, si no las tenemos ya:

# apt- get install build-essential

Después instalamos las cabeceras del núcleo. Como el kernel instalado en proxmox es el 2.6.32-11-pve, instalamos el paquete pve-headers-2.6.32-11-pve:

# apt-get install pve-headers-2.6.32-11-pve

A continuación descargamos el driver:

# wget http://iats.googlecode.com/files/AR81Family-Linux-v1.0.1.9.tar.gz

Por lo que he visto, hay una versión más reciente (AR81Family-Linux-v1.0.1.14.tar.gz) pero no la he probado porque la versión 1.0.1.9 funcionaba perfectamente con nuestra tarjeta de red.

Una vez descargado el driver, lo descomprimimos:

# mkdir /usr/src/AR81Family
# tar xfvz AR81Family-linux-v1.0.1.14.tar.gz -C /usr/src/AR81Family/

Entramos en el directorio e instalamos:

# cd /usr/src/AR81Family
# make install

El instalador compilará el código fuente e instalará el driver atl1e.ko, sustituyendo el driver anterior de proxmox, que no funciona.

Por último comprobamos que el driver instalado es válido para nuestra tarjeta de red ejecutando modinfo:

# modinfo atl1e.ko

En la información que nos ofrece el comando modinfo debe aparecer la identificación de nuestra tarjeta: 1969:1073

domingo, 6 de mayo de 2012

Programación de tareas con anacron

cron es una herramienta tremendamente útil en máquinas que están encendidas permanentemente, como por ejemplo servidores. En cambio no nos es tan útil en equipos que no se encuentran encendidos durante todo el tiempo, como por ejemplo portátiles u ordenadores de escritorio. Para éstos tenemos anacron, una herramienta complementaria que nos va a permitir la ejecución de tareas de forma asíncrona.

Por poner un ejemplo, en mi centro tengo una máquina servidora que hace copia de seguridad de los servidores cada día a las 23:00 mediante una tarea programada con cron.

Por otra parte, tengo una tarea en los portátiles que hace copia de seguridad del home de los usuarios cuando se encuentran en el centro y ésta se ejecuta mediante anacron. Si la tuviera programada mediante cron, no se realizaría a menos que el portátil estuviera encendido en el momento programado.

Así como cron puede ser usado por cualquier usuario para programar sus propias tareas, anacron sólo puede ser usado por el administrador.

El principal fichero de configuración de anacron es /etc/anacrontab. Este fichero contiene básicamente lo siguiente:

miusuario@servidor:# cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# These replace cron's entries
1    5    cron.daily     nice run-parts --report /etc/cron.daily
7    10    cron.weekly     nice run-parts --report /etc/cron.weekly
@monthly    15    cron.monthly nice run-parts --report /etc/cron.monthly

Las tareas  que queramos ejecutar diariamente, se deben colocar en el directorio /etc/cron.daily.

Las tareas  que queramos ejecutar semanalmente, se deben colocar en el directorio /etc/cron.weekly.

Las tareas  que queramos ejecutar mensualmente, se deben colocar en el directorio /etc/cron.monthly.

Las tareas programadas en el fichero /etc/anacrontab deben tener los siguientes campos:

periodo  retraso  identificador-trabajo  comando

- El campo periodo contiene un valor numérico que indica el número de días que tienen que pasar como mínimo desde la última ejecución de la tarea antes de volver a lanzarla:
  •  1  -> diariamente
  •  7  -> semanalmente
  • 30 -> mensualmente
  • N  -> Cualquier otro valor numérico.
- El campo retraso indica el número de minutos que deben pasar antes de ejecutar el trabajo una vez que la máquina ha arrancado.

- El campo identificador-trabajo es el nombre para el fichero de timestamp de la tarea. Este identificador debe ser único para cada trabajo. Se guardará como un fichero en el directorio /var/spool/anacron y contendrá una sola línea que indica la última vez que el trabajo fue ejecutado.

- El campo comando es el comando o script que queremos ejecutar.

Si echamos un vistazo al directorio /var/spool/anacron veremos que contiene los ficheros indicados en /etc/anacrontab:

miusuario@servidor:~$ ls -l /var/spool/anacron/
total 12
-rw------- 1 root root 9 may  5 08:42 cron.daily
-rw------- 1 root root 9 abr 25 23:21 cron.monthly
-rw------- 1 root root 9 may  2 09:14 cron.weekly

anacron busca en /var/spool/anacron el fichero creado para cada tarea la última vez que se ejecutó. Si observa que ha transcurrido el tiempo entre ejecuciones, lanzará dicha tarea.

Si queremos forzar la ejecución de las tareas sin tener en cuenta la última vez que se ejecutaron podemos usar:

# anacron -f

Y si queremos ejecutar las tareas inmediatamente, sin esperar a que transcurra el tiempo indicado en /etc/anacrontab:

# anacron -n

sábado, 5 de mayo de 2012

Programación de tareas con cron

cron es un demonio que nos permite programar tareas con el fin de que se realicen automáticamente.

El principal fichero de configuración de cron es /etc/crontab:

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#


En él se define básicamente cuándo se ejecutarán y en qué directorio hay que colocar scripts para que se ejecuten cada hora (/etc/cron.hourly),  diariamente (/etc/cron.daily/), semanalmente (/etc/cron.weekly) o mensualmente (/etc/cron.monthly).

De este modo, si queremos que un script se ejecute cada día, lo colocaremos en el directorio /etc/cron.daily.

Si queremos recibir un e-mail cuando se produzca un error durante la ejecución de las tareas o cuando nuestro script genere cualquier salida, podemos indicar una dirección de correo en el fichero crontab:

MAILTO=usuario@gmail.com  

Para dejar de recibir emails, podemos quitar la dirección de correo en el fichero crontab:

MAILTO=""
 


Para definir una tarea en un fichero de cron, hay que indicar los siguientes campos:
  • m: minuto en el que se va a ejecutar la tarea (0-59).
  • h: hora (0-23).
  • dom: día del mes (1-31).
  • mon: número de mes (1-12).
  • dow: día de la semana (0-7) 0-> domingo, 1-> lunes ... 7->domingo.
  • user: usuario al que pertenece la tarea.
  • command: comando que vamos a ejecutar.
Un asterisco en uno de los campos representa cualquier valor. Por ejemplo, si tenemos un * en el dow significa que la tarea se ejecutará todos los días de la semana.

Cada usuario puede tener sus propias tareas.

Si un usuario quiere ver las tareas que tiene programadas, tan sólo tiene que ejecutar:

$ crontab -l

Si el usuario quisiera editar su lista de tareas, podría ejecutar:

$ crontab -e

Y si quisiera borrar su lista de tareas:

$ crontab -r

Por defecto, todos los usuarios tienen permiso para usar su propio crontab, aunque sólo root puede editar el crontab de cualquier usuario. Ejemplo:

# crontab -u pepe -e

Se puede permitir usar cron a usuarios concretos, añadiéndolos al fichero /etc/cron.allow
También se puede denegar el uso de cron a determinados usuarios, añadiéndolos al  fichero /etc/cron.deny

Cuando un usuario crea sus propias tareas programadas, éstas se almacenan en el directorio /var/spool/cron/crontabs dentro de un fichero que tiene como nombre su login.

Ejemplos de tareas:

Ejecutar el comando "comando" del usuario "usuario" cada día a las 23:00
0 23    * * *   usuario   comando

Ejecutar el comando del usuario cada 5 minutos:
*/5 *      * * *   usuario   comando

Ejecutar el comando del usuario cada 15 minutos cada domingo:
*/15 *    * * 7   usuario     comando

Ejecutar el comando del usuario los días 15, 20 y 25 de cada mes a las 12:00
0 12     15,20,25 * * usuario   comando

Ejecutar el comando del usuario los días 15,16,17,18,19 y 20 de cada mes a las 12:00
0 12     15-20 * * usuario   comando

Ejecutar el comando del usuario cada 12 horas
0 */12   * * *   usuario   comando

Ejecutar el comando del usuario el primer Sábado de cada mes:
0 0   1-7 * Sat   usuario    comando

Ejecutar el comando del usuario cada hora todos los domingos de enero
0 *   * Jan Sun   usuario   comando

ssh-keyscan: Recopilar claves públicas de equipos

Openssh (http://www.openssh.com/) es una suite de herramientas que mantienen nuestras comunicaciones seguras.

Esta suite reemplaza:
  • rlogin y telnet con un cliente ssh.
  • rcp con scp
  • ftp con sftp.
Además incluye una aplicación servidora: sshd, además de una serie de herramientas como ssh-add, ssh-agent, ssh-keysign, ssh-keyscan, ssh-keygen y sftp-server

Hoy tan sólo vamos a hablar de ssh-keyscan, una utilidad que he usado en  varias ocasiones para recopilar las claves públicas de uno o varios hosts.

Utilicé, por ejemplo, ssh-keyscan en un script que realicé para apagar los terminales de un servidor ltsp cuando el usuario apaga, reinicia el servidor o cierra sesión. Cuando realizamos una conexión ssh el sistema nos pregunta si queremos almacenar la clave pública de la máquina a la que nos queremos conectar. Si le decimos que sí, almacenará dicha clave en el fichero ~/.ssh/known_hosts y no volverá a preguntar. El problema es que necesitaba que el script se ejecutase de forma no interactiva, almacenando la clave pública sin necesidad de intervención por parte del usuario. Pude resolver el problema gracias a ssh-keyscan.

Otra ocasión en la que he usado ssh-keyscan ha sido en un script que hace copias de seguridad en una máquina remota. En este caso tenía el mismo problema: Tratar de evitar que el sistema me preguntara si quería almacenar la clave pública de la máquina remota.

Para obtener la clave pública de una máquina no tenemos más que ejecutar el comando ssh-keyscan indicando la ip o el nombre del host. Ejemplo:

# ssh-keyscan 172.19.144.16

El sistema nos devolverá en pantalla el nombre o ip de la máquina junto con su clave pública.

También podemos escanear una lista de máquinas almacenada en un fichero:

# ssh-keyscan -f  listamaquinas

Cuando el sistema nos pregunta si queremos almacenar la clave pública de una máquina a la que estamos conectando, y le respondemos que sí, guarda dicha clave pública dentro del home del usuario, en el fichero:

~/.ssh/known_hosts

 Si quisiéramos escanear la dirección de una máquina y almacenar su clave pública de forma automática, podríamos hacer lo siguiente:

# ssh-keyscan 172.19.144.16 >> ~/.ssh/known_hosts | sort -u -o ~/.ssh/known_hosts

Como podemos observar, la clave pública se almacena en el fichero known_hosts dentro del directorio .ssh del home del usuario. 

Si utilizáis dsh habitualmente, estaréis de acuerdo conmigo en que es tremendamente útil usar ssh-keyscan para recopilar las claves públicas de los equipos en los que ejecutamos comandos remotamente con dsh:

# ssh-keyscan -f /etc/dsh/machines.list >> ~/.ssh/known_hosts | sort -u -o ~/.ssh/known_hosts

Por último, si queremos almacenar la clave pública de forma que se encuentre disponible para todos los usuarios, en lugar de guardarla en ~/.ssh/known_hosts, podemos almacenarla en el fichero /etc/ssh/ssh_known_hosts.


# ssh-keyscan 172.19.144.16 >> /etc/ssh/ssh_known_hosts | sort -u -o /etc/ssh/ssh_known_hosts