jueves, 19 de noviembre de 2009

Inventariando

Ante la tarea de inventariar los equipos que tenemos así como sus características principales (fabricante, modelo, ram, cpu,...), se hace imprescindible contar con un script que capture todos estos valores y nos los presente de manera resumida.

Aquí van algunos comandos para capturar información valiosa:

1. Memoria RAM instalada:

# echo "Memoria RAM (MB): "`free -m | grep Mem | tr -s "  " " " | cut -d " " -f 2`

2. Unidades de almacenamiento (discos duros, memorias USB, etc):

# echo "Discos duros:" && fdisk -l | grep "Disco /dev/" | cut -d " " -f 3,4 | tr -d ","

3. Fabricante, modelo y número de serie:

# lshw | grep -e product -e vendor -e serial | head -n 3

4. Procesador/es:

# cat /proc/cpuinfo | grep "model name" | sed "s/model name\t/Procesador/"

5. Número total de cores:

# grep 'model name' /proc/cpuinfo | wc -l

6. Para los sistemas Ubuntu, la versión:

# cat /etc/lsb-release | grep "DESCRIPTION" | cut -d "=" -f 2 | tr -d "\""

En Linux existen como véis multitud de comandos para conocer cualquier información. Es cuestión de investigar un poco por nuestro sistema (y googlear) para saber cómo hacer algo.

viernes, 13 de noviembre de 2009

Problema con cron

Cuando se tienen máquinas viejas actuando como servidores, es probable que no mantengan adecuadamente la hora del sistema. Y aunque cambiar la pila de botón de la placa base suele solucionar el problema, en ocasiones no es así (evidencia deterioro de hardware).

Lo normal es configurar cron para que ejecute el comando ntpdate -u servidor_hora cada cierto tiempo (por ejemplo una vez el día) para mantener la hora del sistema:

# crontab -e

[...]
0 0 * * * ntpdate -u ip_o_nombre_servidor_hora
[...]

Pero... transcurridos unos días accedemos al servidor y vemos que la hora va mal. Para asegurarnos que el comando se ha ejecutado, chequeamos el fichero syslog:

$ grep ntpdate /var/log/syslog
[...]
Nov 11 00:00:01 mipc /USR/SBIN/CRON[360]: (root) CMD (ntpdate -u 192.168.1.1)
Nov 12 00:00:01 mipc /USR/SBIN/CRON[1066]: (root) CMD (ntpdate -u 192.168.1.1)
Nov 13 00:00:01 mipc /USR/SBIN/CRON[1697]: (root) CMD (ntpdate -u 192.168.1.1)
[...]

Entonces, ¿qué ocurre?

Ocurre que cron no ejecuta los comandos programados (en nuestro caso ntpdate) dentro de un bash, por lo que los directorios en los que busca cron el comando ntpdate para ejecutarlo puede que no lo contengan. Cron intentó ejecutar el comando a las 00:00 todos los días (syslog da fe) pero el comando no se encontró. Claro, nosotros hacemos pruebas y lo ejecutamos en nuestro shell bash, con un valor apropiado en nuestra variable $PATH, vemos que funciona y asumimos que tiene que funcionar con cron.

Una solución sencilla es indicar la ruta completa del comando ntpdate en el crontab:

# crontab -e

[...]
0 0 * * * /usr/sbin/ntpdate -u ip_o_nombre_servidor_hora
[...]

Así funcionará sin problemas.

miércoles, 11 de noviembre de 2009

Ejecución de sentencias SQL desde scripts

En alguna ocasión nos puede interesar que algún script realice una consulta o inserción contra una base de datos. Os voy a indicar una sencilla forma de hacerlo, siempre y cuando uséis PostgreSQL como SGBD.

Lo primero de todo, será tener instalado el cliente de Postgresql, que para la versión 9.10 de Ubuntu es el siguiente paquete:

# aptitude install postgresql-client-8.3 (ó 8.4)

Tras instalarlo, deberemos tener disponible el comando psql.

Desde un script, basta con ejecutar:

$ echo "INSERT INTO inventario_macs VALUES ('192.168.1.1', '00:60:08:63:f5:4f');" | psql -h 192.1681.100 -d bd_pruebas -U upruebas

Indicar varias cosas:
  • La opción -h especifica la IP o nombre del servidor que aloja la base de datos.
  • La opción -d especifica la base de datos a la que queremos conectarnos (el servidor puede alojar varias bases de datos).
  • La opción -U especifica el usuario con que nos vamos a conectar.
Hay que tener en cuenta que la base de datos puede estar configurada para que solicite contraseña ante un acceso (autenticación activada) o no. Si no está activa esta opción, el comando anterior funcionará sin problemas. Si estuviese activa, al ejecutar el comando psql se nos preguntará por la contraseña, por lo que no es viable para usarlo en scripts de ejecución automatizada.

Para establecer entre una máquina cliente y otra servidor un vínculo de confianza con el objetivo de que no nos pidan la contraseña por cada acceso que queramos hacer (como ocurre con ssh), realizar los siguientes pasos en la máquina cliente:

1. Crear un fichero con nombre .pgpass en el directorio home del usuario que accederá a la base de datos. Este fichero contendrá lineas con el siguiente formato: hostname:puerto:base_datos:nombre_usuario:password. En nuestro caso:

192.168.1.100:5432:bd_pruebas:upruebas:micarromelorobaron

2. Asignar los permisos adecuados al fichero:

$ chmod 0600 .pgpass

Tras ello, podremos lanzar el comando anterior pues no se volverá a preguntar el password de acceso a la base de datos.

Como añadido, indicar que es muy cómodo a la hora de crear tablas redactar en nuestro propio equipo un archivo de texto con las sentencias SQL correspondientes, y luego ejecutarlas en el servidor de la forma:

$ cat fichero.sql | psql -h 192.1681.100 -d bd_pruebas -U upruebas