Hello, IT - Part 10

19 septiembre 2012

Llevar a background a un proceso running

Background
Si se ha ejecutado un proceso en una terminal Linux, y necesitamos retomar el control de la terminal sin interrumpir el proceso, podemos ejecutar «Ctrl+z» para parar el proceso, sin matarlo. De esta manera, volveremos a tener la terminal en primer plano.

Posteriormente podremos ejecutar «jobs» para ver el proceso recién detenido:

$ jobs
[1]+ Stopped ./test.sh

«Jobs» nos devolverá el número de la tarea correspondiente al proceso.

Si ejecutamos «bg», podremos reactivar el proceso y mandarlo a background, que es lo que deberíamos haber hecho originalmente, si hubiéramos sabido que el proceso se nos quedaría corriendo tanto tiempo en primer plano:

$ bg 1
[1]+ Running ./test.sh &

Flickr! Foto por Maggie-Me

28 agosto 2012

Rotar archivos de log con Logrotate

Logrotate es el proceso encargado de rotar, comprimir y enviar por mail los logs de sistema en Linux.

Cuando un paquete individual (como httpd, bacula, vsftpd, yum, etc.) se instala, éste añade en el directorio /etc/logrotate.d/ su fichero de configuración logrotate encargado de la gestión de los logs. Así por ejemplo, Apache añade un fichero similar al siguiente:

[root@server logrotate.d]# cat /etc/logrotate.d/httpd
/var/log/httpd/*log {
missingok
notifempty
sharedscripts
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}

Si se quieren añadir políticas de rotación de logs para logs que no estén definidos o que no estén en las rutas por defecto, se podrá tocar el fichero de configuración /etc/logrotate.conf

En este fichero (/etc/logrotate.conf), además, se configuran las políticas de rotación de logs comunes a todos los logs. En cada fichero de configuración dentro de /etc/logrotate.d, se pueden sobreescribir las políticas comunes, de forma local, redefiniendo el valor para la variable de configuración deseada. Así por ejemplo, se podría crear un fichero para rotar los logs del tipo /var/log/miapp.log que deja una aplicación concreta, tal y como sigue:

[root@server logrotate.d]# cat /etc/logrotate.d/miapp
/var/log/miapp.log {
weekly
copytruncate
rotate 4
compress
missingok
}

Con la definición anterior, estaríamos inficando:

weekly: los logs se rotarán semanalmente.
copytruncate: crea una copia del fichero de logs original y después trunca el fichero original a cero bytes, de esta manera «miapp» siempre apuntará al mismo fichero y evitaremos problemas.
rotate 4: mantendrá los últimos 5 ficheros (rotará 4 veces).
compress: comprime el fichero de log, una vez rotado.
missingok: si el fichero de log no existe, no devuelve error.

Logrotate no es un demonio que corre en la máquina. Así pues, tras realizar cualquier cambio en el fichero de configuración, no será necesario realizar ningún restart de ningún servicio. Símplemente, Logrotate usará la nueva configuración en la siguiente ejecución. Si se desea testear Logrotate tras algún cambio en su configuración, se puede ejecutar el comando siguiente:

logrotate -vf /etc/logrotate.conf

PD: Es posible que tras la ejecución del comando anterior, tarde unos segundos en empezar a escribir en el nuevo fichero de logs.

Útil y muy necesario para mantener controlado el espacio usado por los logs.

Fuentes:
http://www.thegeekstuff.com/2010/07/logrotate-examples/
http://www.linuxcommand.org/man_pages/logrotate8.html
http://www.linuxquestions.org/questions/linux-newbie-8/

22 agosto 2012

Copias de seguridad con Bacula

Bacula es probablemente, la solución OpenSource más conocida para la realización de copias de seguridad a nivel empresarial. Bacula se compone de varios elementos:

Director: dice cuando hacer backups/restores a los clientes de bacula (FD). Los backups que realizan los clientes de bacula se envían directamente al storage, sin pasar por el director.
Storage: recibe los datos de los clientes de bacula y los envía al lugar donde se almacenarán (disco, cinta, etc.). El demonio bacula-sd se configurará en un servidor que tenga montados los recursos de almacenamiento (se suele usar el propio servidor de bácula).
Catalog: base de datos (MySQL, PostgreSQL o SQLlite) con la información de los jobs. Además, guarda los nombres de todos los archivos de los backups realizados, lo cual servirá para hacer restores selectivos.
Cliente bácula (FD): agente que corre en las máquinas clientes que se quieren backupear.
Bconsole: programa que interactua con el director, por línea de comandos y permite administrar bacula. Por ejemplo, permite lanzar backups a mano, ver el estado de los jobs o listar los dispositivos de almacenamiento configurados.

Continuar leyendo «Copias de seguridad con Bacula»

21 agosto 2012

Añadir disco extra en Red Hat

Red Hat En entornos tanto físicos como virtuales, es común encontrarse con la necesidad de añadir un disco duro extra a un servidor tipo Red Hat. Éste proceso se puede hacer de diversas maneras, pero con cualquiera de ellas, se convierte en una tarea crítica, puesto que cualquier fallo nos puede provocar muchos problemas.

A continuación describo el proceso que a mi me funciona:

Identificar los discos, con

fdisk -l

Crear una partición primaria para el nuevo disco, en el ejemplo /dev/sda:

[root@USAFront2 dev]# fdisk /dev/sda
Orden (m para obtener ayuda): n
Acción de la orden
e Partición extendida
p Partición primaria (1-4)
p
Número de partición (1-4): 1
Primer cilindro (1-4865, valor predeterminado 1):
Se está utilizando el valor predeterminado 1
Last cilindro, +cilindros or +size{K,M,G} (1-4865, valor predeterminado 4865):
Se está utilizando el valor predeterminado 4865

Orden (m para obtener ayuda): w
¡Se ha modificado la tabla de particiones!

NOTA:
n Añade una nueva partición
w Escribe la tabla en el disco y sale

Continuar leyendo «Añadir disco extra en Red Hat»

21 agosto 2012

Modificar .profile en Linux

En las distribuciones tipo Red Hat, cada usuario de sistema puede modificar su fichero $HOME/.bash_profile, para por ejemplo, definir nuevos comandos, programas a ejecutar en el momento de acceder al sistema, o cambiar los valores de las variables de entorno como $PATH.

Cuando un usuario (excepto «root») se loguea, primero se ejecuta el fichero /etc/profile, que contiene las definiciones comunes para todos los usuarios, y posterioremente, se ejecutará el fichero .bash_profile correspondiente al usuario.

«When bash is invoked as an interactive login shell, or as a non-interactive shell with the –login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.»

Fuente: «man bash»

Si se quisiera realizar un cambio en una variable de entorno para todos los usuarios, se recomienda crear un fichero .sh en /etc/profile.d/ con el código correspondiente, en lugar de modificar directamente el fichero /etc/profile.

«It’s NOT a good idea to change this file unless you know what you are doing. It’s much better to create a custom.sh shell script in /etc/profile.d/ to make custom changes to your environment, as this will prevent the need for merging in future updates.»

Fuente: «head /etc/profile»

Fuente: http://www.troubleshooters.com/linux/prepostpath.htm

17 julio 2012

Optimización de Apache

Siguiendo con el último post sobre fine tuning de MySQL para mejorar el rendimiento, me lanzo con otro post recopilatorio con un resumen de algunas de las recomendaciones oficiales de Apache, completadas con otras fuentes listadas al final del post.

Hardware y SO

En la documentación oficial de Apache se comenta, que el factor más importante para el rendimiento de un servidor es la RAM, lo cual me recuerda a una frase que reproduzco casi literalmente, pero de la cual no consigo recordar la fuente:

«Aumentar la RAM es la manera más rápida, barata y eficaz de mejorar el rendimiento»

Además de la RAM, se deberá prestar atención a la i/o de los discos, CPU y finalmente a la velocidad de la tarjeta de red, que deberán ser suficientes (ésto se deberá determinar por experimentación).

Continuar leyendo «Optimización de Apache»

13 julio 2012

Nagios, añadir contacto/usuario

Apache HTTP En ocasiones, es posible que se quiera que un determinado usuario reciba notificaciones de una máquina determinada monitorizada por nagios. Para ello, se podrá crear un nuevo contacto, asociado a la máquina de la cual se quiere que dicho contacto reciba alertas.

En primer lugar, se deberá crear el nuevo contacto, siguiendo la plantilla de contactos, contacts.cfg:

define contact{
contact_name username
use generic-contact
alias Nuevo Usuario
email [email protected]
}

Continuar leyendo «Nagios, añadir contacto/usuario»

28 junio 2012

Crontab de todos los usuarios

He encontrado un script tan útil como sencillo, que quisiera compartir. Se trata de un script que muestra el crontab para todos los usuarios del sistema.

La idea es estar logueado como root al ejecutarlo, para que así, se puedan revisar todos los usuarios del sistema en /etc/password, ejecutando un «crontab -l -u» para cada uno de ellos.

El script es tan sencillo que bastará con ejecutarlo desde la misma línea de comandos.

for user in $(cut -f1 -d: /etc/passwd); do echo $user; crontab -u $user -l; done

Fuente: http://stackoverflow.com/questions/134906/how-do-i-list-all-cron-jobs-for-all-users

21 junio 2012

Optimización de mysql

Apache HTTP Este es un post difícil, y no pretende ni mucho menos, ser una guía definitiva de la optimización de MySQL, si no un mero resumen de lo que podrían ser algunas acciones encaminadas a mejorar el rendimiento de MySQL, basado sobre todo, en las directrices de la documentación oficial. Si tienes pensado aplicar alguna de estas medidas, te recomendaría probarla antes en un entorno de test. 😉

Identificar el cuello de botella

El cuello de botella suele venir por:

Búsquedas en el disco duro: actualmente los discos suelen tener una velocidad de búsqueda de menos de 10ms, pudiendo tener un máximo teórico de 100 búquedas por segundo. Distribuyendo los datos en diferentes discos se aumentará el rendimiento.
i/o: una vez el disco esté en posición (haya encontrado el segmento con los datos que buscamos) necesitaremos leer los datos. Actualmente un disco entrega información a razón de 10-20MB/s. Se puede montar un entorno en RAID para la lectura en paralelo de múltiples discos, o usar discos con mayor número de IOPS, como los discos SSD.
Ciclos de CPU: Se recomienda trabajar con tablas pequeñas para mejorar el rendimiento.

Continuar leyendo «Optimización de mysql»