02/12 ~ El mundo en bits

yum, retener versión de paquete

El otro día, hablando con un compañero me preguntó si sabía cómo hacer para retener un paquete en una versión exacta en RedHat/CentOS, yum. En aquel momento no lo sabía y como no me hacía falta, pues la verdad es que tampoco vi necesario aprender cómo hacerlo. Ahora que sí me hizo falta, pues hubo que buscar cómo poder hacerlo. yum, tiene un plugin, llamado versionlock que hace exactamente esa funcionalidad, retener un paquete en una versión específica e impedir que se actualice.
Como el resto de plugins, lo primero es instalarlo en el sistema en caso de que no esté.

shell> yum install yum-versionlock

Una vez esté presente en el sistema sólo habrá que indicar qué paquete, con nombre o comodín (*) se desea retener. En este caso, interesa retener el paquete puppet, para evitar que se actualice. La versión disponible en CentOS de puppet es más actual que el servidor de Debian (testing), por lo que no funciona muy bien. Así que mejor instalamos un paquete más antiguo e impedimos que se actualice. Para hacerlo, simplemente damos el nombre del paquete.

shell> rpm -qa |grep puppet
puppet-2.7.9-2.el6.noarch
shell> yum versionlock puppet
Loaded plugins: fastestmirror, versionlock
Adding versionlock on: 0:puppet-2.7.9-2.el6
versionlock added: 1

Como se puede observar, muy simple de usar y efectivo. Si ya nos interesa profundizar un poco más en cómo funciona, podemos ir a la carpeta en la que yum almacena los archivos de configuración de los plugins instalados, y ahí vemos que ya hay datos relativos a versionlock.

shell> cd /etc/yum/pluginconf.d
shell> cat versionlock.conf
[main]
enabled = 1
locklist = /etc/yum/pluginconf.d/versionlock.list

Si listamos los paquetes que están retenidos vemos que está el que acabamos de introducir.

shell> cat /etc/yum/pluginconf.d/versionlock.list

# Added locks on Wed Feb 29 16:40:46 2012
0:puppet-2.7.9-2.el6.*

Limitar ancho de banda en scp

Hace unos post's hablamos de trickle, un software que permite limitar el ancho de banda que consumen ciertas aplicaciones. Sin embargo, en GNU/Linux hay determinados comandos que ya traen como parámentro una opción que permite limitar el consumo de red que realiza, como es el caso de scp.

scp se suele usar para pasar archivos entre dos equipos vía ssh, por lo que la comunicación se considera segura. En entornos de producción, donde el ancho de banda consumido puede ser crítico, scp incluye la opción -l limit, con lo que se puede limitar el ancho de banda en Kbits/seg y así no dejar al resto de máquinas sin red.

shell> scp debian.iso javier@192.168.1.35:/home/javier
debian.iso          1%   56MB  11.0MB/s      05:19 ETA
shell> scp -l 200 debian.iso javier@192.168.1.35:/home/javier
debian.iso          0%  256KB  35.7KB/s   28:23:17 ETA

Obtener información de Apache

Apache2 es uno de los servidores más comúnmente usado en la mayoría de páginas web y como buen programa tiene ciertos métodos que permiten chequear su correcta configuración y obtener información de compilación y de funcionamiento del mismo. A continuación los que creo que son más interesantes.

Chequear sintaxis
```
shell> apache2 -t
Syntax OK
```

Versión de compilación

shell> apache2 -v
Server version: Apache/2.2.16 (Debian)
Server built:   Sep 25 2011 22:18:56

Versión más avanzada

shell> apache2 -V
Server version: Apache/2.2.16 (Debian)
Server built:   Sep 25 2011 22:18:56
Server's Module Magic Number: 20051115:24
Server loaded:  APR 1.4.2, APR-Util 1.3.9
Compiled using: APR 1.4.2, APR-Util 1.3.9
Architecture:   32-bit
Server MPM:     Prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 ...

Listado de módulos compilados

shell> apache2 -l
Compiled in modules:
  core.c
  mod_log_config.c
  ...

Listado de módulos cargados

shell> apache2 -M
Loaded Modules:
 core_module (static)
 log_config_module (static)
 logio_module (static)
 ...
Syntax OK

Listado de virtualhost's

shell> apache2 -S
VirtualHost configuration:
192.168.1.8:443 is a NameVirtualHost
 default server host1.es     (sites-enabled/host1:1)
 port 443 namevhost host1    (sites-enabled/host:1)
192.168.1.9:443 is a NameVirtualHost
 default server crm.com      (sites-enabled/crm:1)
 port 443 namevhost crm.com  (sites-enabled/crm:1)
192.168.1.7:443 is a NameVirtualHost
 default server extra.es     (sites-enabled/extra:3)
 port 443 namevhost extra.es (sites-enabled/extra:3)
wildcard NameVirtualHosts and _default_ servers:
*:80              is a NameVirtualHost
 default server server.es    (sites-enabled/000-default:1)
 port 80 namevhost server.es (sites-enabled/000-default:1)
 port 80 namevhost aw7.es    (sites-enabled/aw7:1)
 port 80 namevhost qaz.es    (sites-enabled/qaz:47)
Syntax OK

Número máximo de conexiones a MySQL

Hay veces que puede interesar saber el número máximo de conexiones que un determinado servidor de MySQL ha recibido. Para ello MySQL tiene una variable que indica dicho valor, que es el máximo desde el último arranque que se haya efectuado. Esta variable es Max_used_connections y para consultarla, únicamente hay que consultar el estado del servidor, tal como sigue.

mysql> show status like '%max_used%';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections |   219 | 
+----------------------+-------+
1 row in set (0.00 sec)

Esto en sí ya es una gran ayuda, pero hoy buscando cosas interesantes para MySQL, descubrí un parche muy útil y que ayuda a complementar esta información. Lo que hace es almacenar la hora a la que se ha producido el pico máximo de conexiones, una información más útil si interesa evaluar si el pico de conexiones pudo provocar un fallo o alguna alteración en el servicio.

Si se aplica el parche y se compila MySQL, el resultado que se obtendrá será el siguiente,

mysql> show status like 'Max_used%';
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| Max_used_connections    |        219 |
| Max_used_connections_ts | 1327591515 |
+-------------------------+------------+
2 rows in set (0.00 sec)

Pequeño truco de umount

Si recientemente hablé de un truco para mount, hoy toca hablar de un pequeño truco, nuevamente una opción, para umount. Hay veces que por diversos motivos, especialmente en puntos de monjate de NFS, éste se vuelve inaccesible y al intentar desmontarlo la consola deja de responder y no es posible efectuarlo. Para solucionar estos casos, existe la opción -f, que realiza un forzado para que se desmonte.

shell> umount -f /mnt/nfs

Recuperar una única tabla InnoDB del backup

Una de las ventajas de usar MySQL con los parches de percona es la gran cantidad de utilidades que han desarrollado entorno a él para que sea mucho más fácil el trabajo diario. Una de estas utilidades es xtrabackup, una utilidad que sirve para realizar backup's de las información de forma incremental y sin parar el servidor de base de datos. xtrabackup obtiene los datos y los prepara para ser importados, pero no lo hace como mysqldump, sino que se basa más en copia de ficheros directamente. Sin embargo, InnoDB almacena información importante de las tablas en otros ficheros por lo que una copia del directorio que contenga la base de datos no sirve como copia de respaldo y por lo tanto, tampoco sirve para recuperar una tabla de una base de datos.

Para explicar cómo hacer estos, partimos de una instalación del mysql de percona, con una base de datos llamada zabbix, de la que ya hablamos en otros comentarios, por ejemplo.

Para que todo funciona, la configuración del servidor tiene que ser algo especial y cumplir los siguientes puntos:

La variable innodb_file_per_table tiene que estar activada
La variable innodb_fast_shutdown tiene que estar a 0
Desde que se realice la copia no se puede realizar ningún cambio (drop, alter, truncate) en el schema de la tabla

Partiendo de estas premisas entonces, realizamos el backup o copia de los datos de nuestra base de datos. Para ello empleamos la utilidad innobackupex.

shell> innobackupex
       --defaults-file=/etc/my.cnf
       --export /var/backups/

Luego, aplicamos los log's, para tener una copia de seguridad coherente.

shell> innobackupex
       --defaults-file=/etc/my.cnf
       --apply-log
       --export /var/backups/2012-01-26_19-50-17/

Llegados a este punto, tenemos una copia de nuestras tablas InnoDB para poder restaurarlas en el punto de la copia, por lo tanto, vamos ahora a forzar el uso de dicha copia. Para ellos, comprobamos algunos valores de la tabla y los borramos, para tener algo que restaurar.

mysql> SELECT actionid,userid,sendto 
       FROM alerts 
       WHERE sendto='javier@example.com';
+----------+--------+--------------------+
| actionid | userid | sendto             |
+----------+--------+--------------------+
|        7 |     10 | javier@example.com |
|        7 |     10 | javier@example.com |
|        5 |     10 | javier@example.com |
+----------+--------+--------------------+
3 rows in set (0.01 sec)

mysql> DELETE FROM alerts WHERE sendto='javier@example.com';

Llegados aquí, la restauración de los datos ya es necesario, ya que los 'perdimos'. Como ahora interesa recuperarlos, tenemos que hacer lo siguiente.

Descartamos el tablespace de la tabla

mysql> ALTER TABLE alerts DISCARD TABLESPACE;

Copiamos el fichero alerts.ibd desde el backup

shell> cp /var/backups/2012-01-26_19-50-17/zabbix/alerts.ibd \
       /srv/mysql/zabbix/

Importamos el nuevo tablespace

mysql> ALTER TABLE alerts IMPORT TABLESPACE;

Comprobamos su correcto funcionamiento

mysql> SELECT actionid,userid,sendto
       FROM alerts
       WHERE sendto='javier@example.com';
+----------+--------+--------------------+
| actionid | userid | sendto             |
+----------+--------+--------------------+
|        7 |     10 | javier@example.com |
|        7 |     10 | javier@example.com |
|        5 |     10 | javier@example.com |
+----------+--------+--------------------+
3 rows in set (0.01 sec)

Con este pequeño truco, como se puede observar conseguimos de una forma muy simple tratar las tablas InnoDB como tablas MyISAM, aunque de forma un poco más compleja.

Más info en: MySQL Performance Blog

Chuleta SQL Injection

En blackploit han dejado una pequeña chuleta de SQL Injection que espero pueda ser interesante para alguien. Ahí la dejo también.

Comandos MySQL vs Postgres

El otro día haciendo un uso normal de metasploit decidí conectarlo a una base de datos. Sin saber exactamente el motivo por el que pasó, no tenía el driver para conectarlo con MySQL, por lo que decidí instalar Postgres como motor de base de datos, del que sí tenía conector y que además dicen que va perfectamente. Yo nunca había usado este nuevo motor de base de datos, por lo que lo más sencillo que me pasó fue instalarlo. Usando debian gnu/linux,

shell> apt-get install postgresql-8.4

Luego tocó meterle mano, crear una base de datos, listar las ya existentes, entrar en una, listar las tablas, etc. Todos esos pasos esenciales y básicos en MySQL que sin saber nada de Postgres, pues la cosa se complica, así que decidí dejar aquí una chuleta con la comparativa de los comandos de ambos motores y que espero os resulte de ayuda si algún día os hace falta.

MySQL                        Postgres
  SHOW DATABASES               \l
  USE DATABASE                 USE database
  SHOW TABLES                  \d
  SHOW TABLES                  \dt
  DESCRIBE table               \d table
  CREATE DATABASE database     CREATE DATABASE database WITH OWNER usuario;
  DROP DATABASE database       DROP DATABASE database

MySQL: i-am-a-dummy

Hay veces que MySQL todavía puede sorprendernos y ofrecernos un hueco de protección para aquellas personas que hacen actualizaciones (UPDATE) o borrados (DELETE) muy bruscos. Dicha opción safe-updates, o su alias, i-am-a-dummy. Como su propia traducción indica, al arrancar el prompt de mysql se entra en un modo especial para dummy's que limita las sentencias UPDATE y DELETE a usar una clausula WHERE sobre una columna con índice. Esto es especialmente útil para evitar aquellas consultas demasiado agresivas o peligrosas que puedan poner en peligro la integridad de los datos, eliminando por ejemplo el contenido de toda una tabla sin quererlo.

shell> mysql -u root --i-am-a-dummy -p
Enter password:

mysql> use test;
Database changed

mysql> CREATE TABLE `prueba` (
    ->   `id` int(11) DEFAULT NULL
    -> );

mysql> insert into prueba (id) values(1);
Query OK, 1 row affected (0.00 sec)

mysql> insert into prueba (id) values(2);
Query OK, 1 row affected (0.00 sec)

mysql> select * from prueba;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)

mysql> delete from prueba;
ERROR 1175 (HY000): You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column

mysql> delete from prueba where id=1;
ERROR 1175 (HY000): You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column

Como se puede observar, la columna id no tiene un índice, por lo que no se permite realizar un borrado de los datos.

A continuación, creamos el índice sobre dicha tabla y volvemos a ejecutar la sentencias de DELETE.

mysql> create index ids on prueba(id);
Query OK, 2 rows affected (0.04 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> delete from prueba;
ERROR 1175 (HY000): You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column

mysql> delete from prueba where id=1;
Query OK, 1 row affected (0.00 sec)

Como se puede observar, ahora al llevar la clausula WHERE sí que permite eliminar datos, sin la clausula restrictiva, no.

Internamente la opción i-am-a-dummy lo que realmente hace es establecer unos valores predeterminados a ciertas variables del servidor, las que se muestran a continuación.

mysql> show variables like '%sql_max_join_size%';
+-------------------+---------+
| Variable_name     | Value   |
+-------------------+---------+
| sql_max_join_size | 1000000 |
+-------------------+---------+
1 row in set (0.00 sec)

mysql> show variables like '%sql_select_limit%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| sql_select_limit | 1000  |
+------------------+-------+
1 row in set (0.00 sec)

mysql> show variables like '%sql_safe_updates%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| sql_safe_updates | ON    |
+------------------+-------+
1 row in set (0.00 sec)

El significado de estas son:

SQL_SELECT_LIMIT
Las sentencias a una sola tabla están limitadas a un máximo de 1000 filas, exceptuando que se use la cláusula LIMIT.
SQL_MAX_JOIN_SIZE
Las sentencias que afecten a varias tablas, están limitadas a un máximo de 1000000 de registros.
SQL_SAFE_UPDATES
Establece la limitación en las clausulas UPDATE y DELETE.

Etiquetando dispositivos extraibles

Algunas veces, cuando andamos con muchos pendrive's o discos externos se nos puede dar el caso de que no sabemos dónde hay que montarlos o cual es cual. Para solucionar este pequeño problemilla, existe el comando e2label, que no hace otra cosa que escribir una etiqueta a un disco/partición y luego devolverla.

Primero vamos a ver cómo funciona.

shell> dmesg
[1224834.074274] sd 5:0:0:0: [sdf] Write Protect is off
[1224834.074278] sd 5:0:0:0: [sdf] Mode Sense: 45 00 00 08
[1224834.074281] sd 5:0:0:0: [sdf] Assuming drive cache: write through
[1224834.075895] sd 5:0:0:0: [sdf] Assuming drive cache: write through
[1224834.075899]  sdf: sdf1
[1224834.078146] sd 5:0:0:0: [sdf] Assuming drive cache: write through
[1224834.078150] sd 5:0:0:0: [sdf] Attached SCSI removable disk

shell> e2label /dev/sdf1

shell> e2label /dev/sdf1 PEN_8G
shell> e2label /dev/sdf1
PEN_8G

Como se puede observar, se ha conectado un nuevo dispositivo al sistema, que fue asignado a /dev/sdf1. A continuación pedimos su etiqueta y vemos que no devuelve nada. Eso es que primeramente hay que establecerle una. Le asignamos PEN_8G. A partir de este momento ese dispositivo siempre será reconocido con ese nombre.

Ahora lo que interesa es poder usar ese nombre para montar dispositivos, para hacerlo, nos fijamos que el comando mount tiene una opción para tal efecto.

shell> man mount
...
-L label
   Mount the partition that has the specified label.
...

Probamos a realizar el montaje usando la etiqueta y vemos que es correcto!

shell> mount -L PEN_8G /mnt/nfs/
shell> mount
...
/dev/sdf1 on /mnt/nfs type ext4 (rw)

Si ahora nos interesa que siempre se monte en dicha carpeta, lo añadimos con la etiqueta al fstab y todo debería de funcionar perfectamente.

shell> vi /etc/fstab
...
LABEL=PEN_8G  /mnt/nfs  ext4  defaults  0  0
...

Espero que os gustase este pequeño truco de etiquetas.

yum, blacklist packages

Volvemos con otra entrada sobre una feature a destacar de yum para aquellos que no la conozcáis, esta es la posibilidad de bloquear paquetes, o añadir paquetes a una lista negra, para evitar que se instalen.

Se puede dar el caso de que en un sistema compartido a un usuario se le den permisos de sudo para que instale ciertos paquetes, pero no nos interesa que pueda instalar otros determinados paquetes. También puede suceder que no interese que ningún paquete de cierto tipo se instale en un sistema que estamos administrando. Para hacer esto, existen las blacklist, que aprenderemos cómo gestionarlas. Simplemente es añadir un exclude del o de los paquetes que no interesen en el repositorio que los provea.

shell> vi /etc/yum.repos.d/epel.repo
 [epel]
  name=Extra Packages for Enterprise Linux 6
  mirrorlist=https://mirrors.fedoraproject.org/...
  enabled=1
  gpgcheck=1
  gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
  exclude=httpd*

shell> yum install httpd.x86_64
Loaded plugins: rhnplugin
Setting up Install Process
Nothing to do

También se puede hacer lo mismo pero de forma directa en línea de comandos, para asegurarnos de que no se instalan dependencias de paquetes que no nos interesan, por ejemplo. En el siguiente ejemplo, vemos que no se instala nada, por que el paquete httpd se dice que no esté disponible para instalar.

shell> yum --exclude=httpd\* install httpd.x86_64
Loaded plugins: rhnplugin
Setting up Install Process
Nothing to do

yum reinstall package

yum, el gestor de paquetes por excelencia de Red Hat/Centos/Fedora tiene algunas curiosidades interesantes a la hora de trabajar y gestionar paquetes con él. En esta entrada vamos a enseñar cómo reinstalar un paquete previamente instalado en el sistema, pero que por algún motivo está fallando, por ejemplo, que borramos accidentalmente un fichero de configuración o alguna librería que necesita para funcionar.

Para hacerlo, yum incluye la opción reinstall, que permite justamente hacer lo mencionado anteriormente.

shell> yum reinstall gnutls

TAG a query en MySQL

Hay veces que poder identificar qué programa está accediendo a la base de datos y está realizando las consultas puede ser muy útil.

Imaginémonos una base de datos que es accedida por 4 frontends diferentes y 2 programas de acceso a la API. Sabemos que uno de ellos hace algo raro, pero no sabemos cual es que realiza las temidas slow query's. Para saber cual es que culpable de dichas consultas, existen varias formas, una de ellas es, por ejemplo, diferenciar las conexiones por usuario, algo que luego será fácil de filtrar, otra sería también por equipo origen de la conexión. La última, podría ser incluir un pequeño tag en la query que incluya el nombre de la aplicación y así saber el origen de la misma. Como se verá a continuación, esto es bastante simple de realizar.

mysql> SELECT /*ZBX WEB 3*/ * FROM hosts;

Si esta consulta, aunque simple provoca que sea lenta con la cantidad de datos que tiene, luego se podrá consultar en el fichero de las slow query's. Tal como se puede observar a continuación y por lo tanto, saber qué aplicación es la que ha provocado dicha consulta, es muy simple, ya que en la propia consulta está el programa que la ha generado.

shell> cat /var/log/mysql/slow.log
  # Time: 120130 13:52:59
  # User@Host: zabbix[zabbix] @ localhost []  Id:  1335
  # Query_time:7.0377 Lock_time:5.0140 Rows_sent:19402 Rows_examined:0
  use zabbix;
  SET timestamp=1327927979;
  SELECT /*ZBX WEB 3*/ * FROM hosts;

Usando LVM (VI): vgmerge

Siguiendo con los post's interesantes de LVM, tenemos una nueva entrega en la que vamos a comentar cómo poder unir dos grupos de volúmenes en uno único.

Los sistemas van evolucionando y puede darse el caso de donde antes era de interés dos grupos de volúmenes (vg0 y vg1) ahora es mejor tener todo el espacio unido en un único volumen. Para conseguir esto, LVM tiene las herramientas necesarias para realizar el merge de dichos vg.

Partimos por lo tanto del siguiente escenario.

shell> vgdisplay 
  --- Volume group ---
    VG Name               vg0
    System ID             
    Format                lvm2
    Metadata Areas        1
    Metadata Sequence No  684
    VG Access             read/write
    VG Status             resizable
    MAX LV                0
    Cur LV                30
    Open LV               15
    Max PV                0
    Cur PV                1
    Act PV                1
    VG Size               459,40 GiB
    PE Size               4,00 MiB
    Total PE              117606
    Alloc PE / Size       53888 / 210,50 GiB
    Free  PE / Size       63718 / 248,90 GiB
    VG UUID               XSNV2N-ACNL-TgLX-77D4-bYko-wUP6-bg3jPn
   
  --- Volume group ---
    VG Name               vg1
    System ID             
    Format                lvm2
    Metadata Areas        1
    Metadata Sequence No  11
    VG Access             read/write
    VG Status             resizable
    MAX LV                0
    Cur LV                2
    Open LV               0
    Max PV                0
    Cur PV                1
    Act PV                1
    VG Size               81,53 GiB
    PE Size               4,00 MiB
    Total PE              20871
    Alloc PE / Size       17408 / 68,00 GiB
    Free  PE / Size       3463 / 13,53 GiB
    VG UUID               6WA2Va-KNEq-7I9u-4G0G-Tsrc-6tTi-akrBbU

Para unir ambos grupos por lo tanto, usaremos el comando vgmerge, pasándole ambos como parámetro. El primero será el que "absorba" al segundo, quedando por lo tanto el primero como único.

shell> vgmerge vg0 vg1
  Logical volumes in "vg1" must be inactive

Si sale el anterior ~~fallo~~ mensaje, es debido a que el volumen origen de datos, vg1, está siendo usado y antes de continuar habrá de marcarlo como inactivo, para ello emplearemos el comando vgchange.

shell> vgchange -an vg1
  0 logical volume(s) in volume group "vg1" now active

Una vez deshabilitado, ya se puede realizar el merge.

shell> vgmerge vg0 vg1
  Volume group "vg1" successfully merged into "vg0"

Una vez finalizado, ya sólo existe el primer grupo.

shell> vgdisplay 
  --- Volume group ---
    VG Name               vg0
    System ID             
    Format                lvm2
    Metadata Areas        1
    Metadata Sequence No  684
    VG Access             read/write
    VG Status             resizable
    MAX LV                0
    Cur LV                30
    Open LV               15
    Max PV                0
    Cur PV                1
    Act PV                1
    VG Size               540,93 GiB
    PE Size               4,00 MiB
    Total PE              138477
    Alloc PE / Size       71296 / 278,50 GiB
    Free  PE / Size       67181 / 262,43 GiB
    VG UUID               XSNV2N-ACNL-TgLX-77D4-bYko-wUP6-bg3jPn

Si ahora vemos los volúmenes que hay, podremos observar que los todos pertenecen al vg0, pero sin embargo los que antes pertenecían al vg1, ahora su status es NOT available y por lo tanto no se podrán usar.

shell> lvdisplay
  --- Logical volume ---
    LV Name                /dev/vg0/ldap
    VG Name                vg0
    LV Status              available
    (...)

  --- Logical volume ---
    LV Name                /dev/vg0/puppet
    VG Name                vg0
    LV Status              NOT available
    (...)

Antes de usarlos, habrá que activarlos, para ello emplearemos el comando lvchange y los activamos, tal como sigue.

shell> lvchange -ay /dev/vg0/puppet

Explicación sencilla de cron

cron es uno de los daemon de GNU/Linux más importantes y habituales en el sistema. Se encarga de lanzar, en segundo plano, tareas programas en fechas concretas y permite por lo tanto realizar tareas repetitivas de forma automática. Dicha definición de tareas está en el fichero /etc/crontab.

Si no estás trabajando diariamente con cron, lo más probable es que la siguiente imagen te pueda ayudar.

A continuación os dejo una pequeña chuleta que la podéis colocar al principio de vuestro crontab y así acordaros siempre del funcionamiento.

# Ejemplo de definición de cron:
# .---------------- minuto (0 - 59) 
# |  .------------- hora (0 - 23) 
# |  |  .---------- dia del mes (1 - 31) 
# |  |  |  .------- mes (1 - 12) O jan,feb,mar,apr ... 
# |  |  |  |  .---- dia de la semana (0 - 6) (Sunday=0 or 7)
# |  |  |  |  |
# *  *  *  *  *   USER  COMMAND
MAILTO="cron@localhost"
SHELL=/bin/sh
...

metasploit, básico

Pues comenzamos esta pequeña aventura de escribir lo que sucedió en el #eseidojo de hace unos días. Tras la parte inicial y tener a la gente ya cómoda con sus máquinas virtuales y trabajando perfectamente con metasploit, comenzamos demostrando algunos ejemplos muy básicos del funcionamiento de metasploit. Este framework, aparte de realizar test de penetración, también hace muchas más cosas y sirve para revelar información interesante que posteriormente se podrá usar.

Primeramente arrancamos el framework

shell> msfconsole
       =[ metasploit v4.2.0-dev [core:4.2 api:1.0]
+ -- --=[ 798 exploits - 435 auxiliary - 133 post
+ -- --=[ 246 payloads - 27 encoders - 8 nops
       =[ svn r14702 updated today (2012.02.06)
msf>

Desde prompt de metasploit podemos averiguar la IP de nuestro equipo, por ejemplo. Esto resultará útil para saber sobre qué IP poner a la escucha cierto servicios posteriormente.

msf> ifconfig
ifconfig
[*] exec: ifconfig

eth0  Link encap:Ethernet HWaddr 00:e0:4c:66:98:20
      inet addr:192.168.1.33 Bcast:192.168.1.255  Mask:255.255.255.0
      inet6 addr: fe80::2e0:4cff:fe66:9820/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:3887195 errors:0 dropped:0 overruns:0 frame:0
      TX packets:4589508 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:3859825582 (3.5 GiB)  TX bytes:3945018125 (3.6 GiB)
      Interrupt:20 Base address:0x2000

También permite ejecutar nmap para escanear equipos o rangos completos. En general desde el prompt se podría ejecutar prácticamente cualquier comando que acepte la línea de comandos.

msf> nmap -A -T4 192.168.1.100
[*] exec: nmap -A -T4 192.168.1.100

Starting Nmap 5.00 ( http://nmap.org ) at 2012-02-07 19:46 CET
Interesting ports on example.test.com (192.168.1.100):
Not shown: 991 closed ports
PORT     STATE SERVICE    VERSION
21/tcp   open  ftp        ProFTPD 1.3.3a
22/tcp   open  ssh        OpenSSH 5.5p1 Debian 6+squeeze1 (protocol 2.0)
|  ssh-hostkey: 1024 96:c3... (DSA)
|_ 2048 0e:e4... (RSA)
25/tcp   open  smtp       Postfix smtpd
|_ smtp-commands: EHLO example.test.com, PIPELINING, SIZE 31457280, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN
80/tcp   open  http       Apache httpd 2.2.16
|  html-title: 301 Moved Permanently
|_ Did not follow redirect to http://www.test.com/
111/tcp  open  rpcbind
|  rpcinfo:  
|  100000  2    111/udp  rpcbind  
|_ 100000  2    111/tcp  rpcbind  
113/tcp  open  ident
443/tcp  open  ssl/http   Apache httpd 2.2.16
|_ html-title: Inicio
3306/tcp open  mysql      MySQL 5.1.49-3-log
|  mysql-info: Protocol: 10
|  Version: 5.1.49-3-log
|  Thread ID: 103040
|  Some Capabilities: Long Passwords, Connect with DB, Compress, ODBC, Transactions, Secure Connection
|  Status: Autocommit
9102/tcp open  jetdirect?

Network Distance: 1 hop
Service Info: Host:  example.test.com; OSs: Unix, Linux

TRACEROUTE (using port 53/tcp)
HOP RTT  ADDRESS
1   0.32 192.168.1.1
2   1.08 example.test.com (192.168.1.100)

Nmap done: 1 IP address (1 host up) scanned in 29.60 seconds

Y ya como ejemplo final, existe un pequeño módulo que consulta la resolución DNS, muy similar al comando dig y que permite saber información de un dominio, que por ejemplo posteriormente fuésemos a atacar. Durante el dojo, las máquinas no tenía salida a internet y por lo tanto no fue posible que los asistentes realizasen esta prueba.

Aquí queda la salida completa con un dominio de la ESEI y cómo se obtuvo.

msf> use auxiliary/gather/dns_enum
msf auxiliary(dns_enum) > show options

Module options (auxiliary/gather/dns_enum):

Name        Setting      Required  Description
----        -------      --------  -----------
DOMAIN                   yes       The target domain name...
ENUM_AXFR   true         yes       Initiate a zone Transfer...
ENUM_BRT    false        yes       Brute force subdomains...
ENUM_IP6    false        yes       Brute force hosts with...
ENUM_RVL    false        yes       Reverse lookup a range...
ENUM_SRV    true         yes       Enumerate the most common...
ENUM_STD    true         yes       Enumerate standard record...
ENUM_TLD    false        yes       Perform a top-level domain...
IPRANGE                  no        The target address range...
NS                       no        Specify the nameserver to use...
STOP_WLDCRD false        yes       Stops Brute Force Enumeration...
WORDLIST    namelist.txt no        Wordlist file for domain...

msf auxiliary(dns_enum) > set domain esei.uvigo.es
domain => esei.uvigo.es
msf auxiliary(dns_enum) > run

[*] Retrieving General DNS Records
[*] Domain: esei.uvigo.es IP Address: 193.147.87.10 Record: A
[*] Name: ALT1.ASPMX.L.GOOGLE.COM. Preference: 5 Record: MX
[*] Name: ALT2.ASPMX.L.GOOGLE.COM. Preference: 5 Record: MX
[*] Name: ASPMX2.GOOGLEMAIL.COM. Preference: 10 Record: MX
[*] Name: ASPMX3.GOOGLEMAIL.COM. Preference: 10 Record: MX
[*] Name: ASPMX.L.GOOGLE.COM. Preference: 1 Record: MX
[*] Performing Zone Transfer against all nameservers in esei.uvigo.es
[-] Could not resolve domain esei.uvigo.es
[*] Enumerating SRV Records for esei.uvigo.es
[*] Auxiliary module execution completed

La información es poder!

From ext3 to ext4

Con la no tan reciente aparición del sistema de ficheros ext4 y su incorporación al kernel de forma estable, muchas de las distribuciones ya lo han adoptado como sistema de ficheros por defecto para sus particiones, sin embargo aquellos equipos que están instalados de antes y todavía tienen el sistema de ficheros en ext3, actualizarlos a ext4 puede convertirse en una odisea.

No es tan complicado como pueda parecer y con unos pocos comandos se puede logar dicha actualización, y por lo tanto la mejora de rendimiento que ext4 ofrece sin perder datos ni tener que hacer odiseas para conseguirlo. A continuación se detalla cómo hacerlo.

shell> mount
/dev/vg0/home on /home type ext3 (rw)

shell> df -h
S.ficheros      Size  Used Avail Use% Montado en
/dev/vg0/home    15G  2,9G   12G  21%      /home

shell> umount /home

shell> fsck.ext3 -pf /dev/vg0/home  
/dev/vg0/home: 51/98040 ficheros (7.6% no contiguos), 80116/332160 bloques

shell> tune2fs -O extents,uninit_bg,dir_index /dev/vg0/home
tune2fs 1.41.12 (17-May-2010)

shell> fsck.ext4 -yfD /dev/vg0/home
e2fsck 1.41.12 (17-May-2010)
Paso 1: Verificando nodos-i, bloques y tamaños
Paso 2: Verificando la estructura de directorios
Paso 3: Revisando la conectividad de directorios
Paso 3A: Optimizando directorios
Paso 4: Revisando las cuentas de referencia
Paso 5: Revisando el resumen de información de grupos

/dev/vg0/home: ***** EL SISTEMA DE FICHEROS FUE MODIFICADO *****
/dev/vg0/home: 51/98040 ficheros (7.6% no contiguos), 80116/332160 bloques

shell> mount /dev/vg0/home /home

shell> mount
/dev/vg0/home on /home type ext4 (rw)

shell> df -h
S.ficheros      Size  Used Avail Use% Montado en
/dev/vg0/home    15G  2,9G   12G  21%      /home

Esta forma de hacerlo se podría clasificar cómo un método off-line, ya que la partición está desmontada y no hay riesgo alguno. En otro post explicaré como hacer lo mismo para el punto de montaje /, del que sí que no se puede prescindir. y por lo tanto el paso de ext3 a ext4 será "en caliente".

sudo te educa

Aunque no soy fan de usar sudo para realizar determinadas cosas que necesiten permisos, sí tengo que admitir que tiene sus ventajas y también sus puntos graciosos. En este caso, os quiero presentar la opción de compilación de sudo, insults, que no es más que una serie de insultos o faltas que intentan educar, a su manera, al usuario que se equivoca de contraseña a la hora de llamar al comando. Puede ser un método para educar y también un método para echarnos unas risas. Esta opción viene compilada prácticamente en todas las distribuciones y para habilitarlas, únicamente hay que añadir al fichero /etc/sudoers la línea "Defaults insults".

A continuación, al usar sudo, en caso de que la contraseña que pongamos sea incorrecta, obtendremos insultos aleatorios.

shell> sudo ls /boot
[sudo] password for javier: 
You can't come in. Our tiger has got flu
[sudo] password for javier: 
You'll starve!
[sudo] password for javier: 
Have a gorilla...
sudo: 3 incorrect password attempts

Espero que su uso resulte divertido ;-)

ESEI Coding Dojo, pentesting

El pasado viernes 3 he tenido la oportunidad de participar como oyente y ayudante en un Coding Dojo en la Escuela Superior de Ingeniería Informática de Ourense. El objetivo principal del Dojo era dar unas pequeñas nociones básicas sobre pentesting y metasploit, un framework que simplifica los test de intrusiones. La verdad es que se demostró una vez más que la explotación de vulnerabilidades es un tema que suele llamar bastante la atención, ya que el aula estaba llena y la gente bastante participativa (o eso parecía), aunque quizás faltó un poco más de preguntas respuestas.

El dojo comenzó con la la introducción teórica por Paula y Adam y algunos ejemplos de prácticas de explotación de vulnerabilidades en las máquinas virtuales.

Luego me dejaron participar a mi y en una serie de post's iré realizando una introducción a lo que dije de metasploit. No es nada del otro mundo, ya que los fallos a explotar eran sobradamente conocidos, pero puede que a alguien le interese este tema y por ello considero oportuno escribirlo y colaborar.

metasploit, básico
metasploit, login_access
metasploit, explotando un postgres mal configurado + ssh
metasploit, acceso remoto a windows
metasploit, creación de un backdoor
metasploit, pdf envenenado
metasploit, vlc exploit!
metasploit, y una vez dentro... ¿qué?
metasploit, jugando con android

Canonical no apuesta por Kubuntu

Según recientes noticias, Canonical dejará de dar soporte a Kubuntu (versión de ubuntu, pero con escritorio KDE). Desde luego una mala noticia para todos aquellos kubuntero's, que quedarán de la mano de la comunidad para que siga preparando los paquetes y creando la ISO de las nuevas versiones.

La noticia la dio a conocer Jonathan Riddell, líder del proyecto Kubuntu, que después de la versión 12.04 quedará en manos de la comunidad. Por cierto, que lo mismo sucede con Edubuntu, Lubuntu y Xubuntu.

Todo apunta a que Canonical se quiere centrar en Ubuntu únicamente y crear un producto más ¿usable? ¿comercial?

Las noticias oficiales aquí y aquí.

Comandos interesantes: ngrep

ngrep es uno de esos comandos poco conocidos, pero que en algunos casos puede ser de gran utilidad. En muchas ocasiones para saber lo que pasa por la tarjeta de red tenemos que usar tcpdump o programas similares, que aunque obtienen muchísima más información, según lo que nos interese es mucho más complicada de comprender. ngrep viene a simplificar esto, ya que une la facilidad y flexibilidad del comando grep, con la n de network.

La instalación en sistemas debian/ubuntu es muy sencilla, ya que está en los repositorios oficiales.

shell> apt-get install ngrep

Y una vez instalado, comenzamos a trabajar con él de forma muy simple, indicándole en qué interfaz de red se pone a escuchar (-d eth0) y luego si nos interesa tener algún filtro, por ejemplo un puerto concreto destino (port 80). La salida es mucho más comprensible que la ofrecida por tcpdump.

shell> ngrep -d eth2 port 80
interface: eth2 (192.168.1.0/255.255.255.0)
filter: (ip or ip6) and ( port 80 )
#######
T 192.168.1.2:53222 -> 209.85.148.99:80 [AP]
  GET / HTTP/1.1..Host: www.google.com..Connection:....
#
T 209.85.148.99:80 -> 192.168.1.2:53222 [AP]
  HTTP/1.1 302 Found..Location: https://www.google.com...
##
T 192.168.1.2:53222 -> 209.85.148.99:80 [AP]
  GET / HTTP/1.1..Host: www.google.com..Connection:...
#
T 209.85.148.99:80 -> 192.168.1.2:53222 [AP]
  HTTP/1.1 302 Found..Location: https://www.google.com...
###########################
T 192.168.1.2:36417 -> 192.168.1.51:80 [AP]
  POST /dashboard.php?output=html&sid=...
#
T 192.168.1.2:36417 -> 192.168.1.51:80 [AP]
  favobj=hat&favref=hat_webovr&action=refresh&_=...

La ventaja de la que hablamos de ngrep es que permitía usar la facilidad y comodidad de grep en entornos de red, y esta es su gran utilidad, podemos indicarle cualquier tipo de expresión que comprenda grep y, tal como se muestra a continuación, ngrep comenzará a filtrar los datos y resultados.

shell> ngrep -d eth2 "Apache/2.2.16" port 80
interface: eth2 (192.168.1.0/255.255.255.0)
filter: (ip or ip6) and ( port 80 )
match: Apache/2.2.16
####################
T 192.168.1.51:80 -> 192.168.1.2:36477 [A]
  HTTP/1.1 200 OK.. Server: Apache/2.2.16
##
T 192.168.1.51:80 -> 192.168.1.2:36477 [AP]
  HTTP/1.1 304 Not Modified.. Server: Apache/2.2.16
##
T 192.168.1.51:80 -> 192.168.1.2:36477 [AP]
  HTTP/1.1 404 Not Found.. Server: Apache/2.2.16
#########
T 192.168.1.51:80 -> 192.168.1.2:36478 [AP]
  HTTP/1.1 404 Not Found.. Server: Apache/2.2.16
##
T 192.168.1.51:80 -> 192.168.1.2:36477 [AP]
  HTTP/1.1 200 OK.. Server: Apache/2.2.16
##
45 received, 0 dropped

Los símbolos # identifican a todos aquellos paquetes que se han capturado y que no coinciden con la expresión regular con la que debe hacer match.

En su página man (man ngrep) hay muchas más opciones, pero una muy interesante es la opción -W byline, que muestra la salida línea a línea y deja el resultado mucho más comprensible.

shell> ngrep -W byline -d eth2 "Apache/2.2.16" port 80
interface: eth2 (192.168.1.0/255.255.255.0)
filter: (ip or ip6) and ( port 80 )
match: Apache/2.2.16
##########################
T 192.168.1.51:80 -> 192.168.1.2:36508 [A]
HTTP/1.1 200 OK.
Date: Mon, 14 Nov 2011 14:00:23 GMT.
Server: Apache/2.2.16 (Debian).
X-Powered-By: PHP/5.3.3-7+squeeze3.
Set-Cookie: zbx_sessionid=4a438cd920f3d0b7d380527db86722cf.
...

########
T 192.168.1.51:80 -> 192.168.1.2:36508 [AP]
HTTP/1.1 404 Not Found.
Date: Mon, 14 Nov 2011 14:00:23 GMT.
Server: Apache/2.2.16 (Debian).
Vary: Accept-Encoding.
...

###
T 192.168.1.51:80 -> 192.168.1.2:36508 [AP]
HTTP/1.1 404 Not Found.
Date: Mon, 14 Nov 2011 14:00:24 GMT.
Server: Apache/2.2.16 (Debian).
Vary: Accept-Encoding.
Content-Encoding: gzip.
...

##########
T 192.168.1.51:80 -> 192.168.1.2:36509 [AP]
HTTP/1.1 404 Not Found.
Date: Mon, 14 Nov 2011 14:00:24 GMT.
Server: Apache/2.2.16 (Debian).
Vary: Accept-Encoding.
...

##
T 192.168.1.51:80 -> 192.168.1.2:36508 [AP]
HTTP/1.1 200 OK.
Date: Mon, 14 Nov 2011 14:00:24 GMT.
Server: Apache/2.2.16 (Debian).
X-Powered-By: PHP/5.3.3-7+squeeze3.
Set-Cookie: zbx_sessionid=4a438cd920f3d0b7d380527db86722cf.
Content-Length: 365.
...

#
53 received, 0 dropped

Pequeño truco de mount

mount es un comando bastante complejo y que tiene muchas utilidades, pero hoy os quiero presentar un pequeño truco, realmente opción, que permite montar automáticamente todos las particiones listadas en el fichero /etc/fstab. La opción -a, que hará tras su ejecución que todos los puntos de montaje se monten en caso de que no lo estén.

shell> mount -a

xtrabackup de 5.1 a 5.5

Puede ser por falta de ganas de actualizar, porque tras una catástrofe en un servidor de base de datos el que encontramos nuevo tiene otra versión, o simplemente como forma de cambio de una versión a otra, pero si, con un backup de xtrabackup pasamos de una versión 5.1 a una 5.5, obtendremos un interesante fallo que no deja arrancar el servicio. Algo similar a esto:

120127 14:18:05 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist
120127 14:18:05 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
120127 14:18:05 InnoDB: The InnoDB memory heap is disabled
120127 14:18:05 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120127 14:18:05 InnoDB: Compressed tables use zlib 1.2.3
120127 14:18:05 InnoDB: Using Linux native AIO
120127 14:18:06 InnoDB: Initializing buffer pool, size = 3.0G
120127 14:18:06 InnoDB: Completed initialization of buffer pool
120127 14:18:06 InnoDB: highest supported file format is Barracuda.
InnoDB: 127 rollback segment(s) active.
120127 14:18:06  InnoDB: Waiting for the background threads to start
120127 14:18:07 Percona XtraDB (http://www.percona.com) 1.1.8-20.1 started; log sequence number 910610240524
120127 14:18:07 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist
120127 14:18:07 mysqld_safe mysqld from pid file /srv/mysql/mysql.pid ended

Este fallo viene originado por que la base de datos mysql no contiene las tablas que la versión espera y necesita al restaurarla del xtrabackup, como ya se explicó.

Para solucionar este fallo, simplemente hay que instalar el schema base del MySQL.

shell> mysql_install_db --user=mysql --ldata=/srv/mysql

Este proceso no sobrescribirá información importante de la importación, como las demás tablas creadas y sí permitirá crear las tablas que faltan en el MySQL. Tras finalizar su ejecución, se levanta el servicio nuevamente y se comprueba que todo está correcto.

shell> service mysql start
shell> mysql_upgrade -u root

Como nota importante cabe decir que los usuarios, y demás permisos que se almacenan en la base de datos mysql se han perdido, por lo que sí habría que volver a crearlos. No quedan afectados los datos de la base de datos restaurada, eso sí.

Backup de MySQL con xtrabackup

Percona tiene unas utilidades sorprendentes y de alguna ya hemos hablado alguna vez. Hoy toca resolver el problema de realizar un backup de una base de datos de forma que la restauración de la misma, en caso necesario sea rápida y simple.

Ante bases de datos pequeñas (MB's o Gb) la realización de un backup con mysqldump es lo habitual y más usado. Luego para restaurarlo, simplemente se ejecuta el proceso contrario y el backup está restaurado. El problema viene cuando nos enfrentamos a una base de datos de 140Gb, por ejemplo. Ahí la realización de un dump ya es un trabajo tedioso, pero luego el proceso contrario, se complica mucho más.

Tradicionalmente sería algo similar a esto

Backup

shell> mysqldump -u root -p --skip-extended-insert \
       | gzip > /var/backups/mysql.sql.gz

Restaurar

shell> zcat /var/backups/mysql.sql.gz | mysql -u root -p

Realizar esto con bases de datos grandes, la importación de los datos puede llevar días e incluso semanas, algo que en entornos de producción no tiene sentido alguno. Tener un servicio parado tanto tiempo puede traer graves consecuencias. Para solucionarlo, podemos usar la utilidad xtrabackup/innobackupex, para realizar un backup de la base de datos completa y posteriores versiones incrementales. Esta utilidad permite copiar "a pelo" los ficheros para luego, en caso necesario, poder restauralos mucho más rápido e incluso restaurar tablas aisladas, si ello fuese necesario. Por supuesto, esta utilidad sólo trabaja con tablas de tipo InnoDB, pero eso no es problema.

Para usarla y crear un backup completo de una base de datos, simplemente basta con ejecutar lo que sigue.

shell> innobackupex --user=root --password=YOUR_ROOT_PASSWD \
       --slave-info --defaults-file=/etc/my.cnf \
       --databases="DB_1 DB_2" --stream=tar ./ \
       | gzip -c -1  > /var/backups/mysql.tar.gz

En donde se indican las bases de datos de las que hacer backup, si se desea restringir, y se exporta a un fichero comprimido con gzip, para evitar que ocupe tanto en disco.

Otro ejemplo, este más claro y sin comprimir datos, lo cual facilitaría el uso de copias incrementales, sería,

shell> innobackupex --user=root --password=YOUR_ROOT_PASSWD \
       --defaults-file=/etc/my.cnf \
       --export /var/backups/

En otro post, explicaremos cómo poder restaurar la base de datos desde el fichero mysql.tar.gz.

Recuperar correos en cuarentena de Zimbra

El servidor de correo zimbra ejecuta varios procesos por defecto y uno de estos es un servidor antivirus que si detecta que un correo trae como adjunto un archivo malicioso lo mete en cuarentena y le envía al destinatario un mail informándole de dicho bloqueo. Como puede que la heurística algunas veces se equivoque, Zimbra incluye una forma de recuperar dichos correos desde su línea de comandos. Para saber cómo, seguir leyendo...


shell> su zimbra -
shell> zmlmtpinject -s 'sender@mail' \
/opt/zimbra/data/amavisd/quarantine/'file' -r 'recipient@mail'

Desde el interfaz web, como usuario administrador, también se puede acceder al buzón de cuarentena y recuperar el correo sin problema alguno, aunque más lento ;-)

Quizás también te pueda interesar saber cómo limpiar la carpeta de cuarentena de Zimbra.

Nuevo RFC aconseja sobre DNSBL

Recientemente se ha publicado y he leído en segu-info la existencia de un nuevo RFC, el RFC 6471 que aconseja sobre las mejores prácticas para el uso de las listas de DNS para el filtrado del correo electrónico. Dichas listas son las que se usan habitualmente en servidores DNS para saber si una dirección IP es proveedora de SPAM, por ejemplo.

Lo nota más destacable e importante de dicho RFC y por lo que merece este post es por que aconseja a los administradores no usar aquellas listas (DNSBL) que cobren por dar de baja una IP no proveedora de SPAM o que tarden mucho tiempo en realizar este proceso. La idea, sin duda, no es otra que dar credibilidad y rápida respuesta a dichas listas, algo especialmente importante y que facilite la detección de correo no deseado.

Comandos interesantes: pwgen

Numerosas veces es necesario la creación de contraseñas que sean seguras para determinados servicios, a mayores de las contraseñas de acceso a cosas personales (sesión, correo, blog,...). La forma de generarlas la verdad es que puede ser algo complicado, por que escoger un número de letras, números y símbolos que realmente sea aleatorio es complicado, por lo tanto, qué mejor que dejar esta tarea a pwgen.

pwgen es un pequeño programa que se encarga justo de eso, proveernos de claves aleatorias, pero con posibilidad de ser recordadas al mismo tiempo que seguras. Es altamente configurable y está disponible en prácticamente todas las distribuciones. En debian/ubuntu para instalarlo,

shell> apt-get install pwgen

Para poder usarlo, simplemente se llama al comando indicándole la longitud de la contraseña deseada y el número de éstas que se quiere.

shell> pwgen 12 3
     DahDo1queecu aiB9phiethi9 uTaf7oghahT4
shell> pwgen 15 1
     ieF7IH9Ieh6tohk
shell> pwgen -1Bncy 20 3
     voh-chah9eeth7KieDai
     Pha3quu(xoC^eewahn4o
     Ung$a&ka3woquiChohje

Según las opciones que se le pase al comando, la contraseña tendrá unas características u otras. Las principales y más destacables son:

-0 | --no-numerals
Sin números en las contraseñas.
-1
Una contraseña por línea.
-B | --ambiguous
Usa caracteres no ambiguos a la hora de generar contraseñas.
Por ejemplo, no está l y 1 en la misma contraseña.
-c | --capitalize
Incluye letras mayúsculas en la contraseña.
-n | --numerals
Incluye caracteres numéricos en la contraseña.
-s | --secure
Genera una contraseña completamente aleatoria y complicada de memorizar.
Especialmente ideal para servicios de los que no sea necesario recordar la contraseña habitualmente.
-y | --symbols
Incluye caracteres especiales en la contraseña.

Llenado del 'buffer pool' en InnoDB, Percona

Si estás trabajando con una arquitectura MASTER-SLAVE y necesitas un óptimo rendimiento, puede darse el caso de que cuando el servidor SLAVE entra en funcionamiento, todas las consultas que estaban ya en caché en el MASTER en éste no están y eso conlleva un gran problema, ya que las primeras consultas serán muy lentas y habrá que ir a buscar todos los datos a disco. Si trabajamos en un sistema de alto rendimiento y disponibilidad, esto puede tener consecuencias importantes, como parón en el servicio o carga muy alta en el servidor de base de datos.

para solucionar ésto, tradicionalmente se empleaba un método más rudimentario, que era lanzar cada X tiempo un script que realizase dichas consultas y por lo tanto, MySQL las pre-cachease. Esto no tenía mucho sentido, por lo que la gente de Percona optó por crear una forma más óptima de realizar este llenado del buffer de las tablas InnoDB y evitar así que en el arranque del SLAVE las consultas sean tan pesadas.

Para usar esta facility,

Crear un dump del buffer_pool

mysql> use information_schema;
mysql> select * from XTRADB_ADMIN_COMMAND /*!XTRA_LRU_DUMP*/;

Subir un dump a memoria

mysql> use information_schema;
mysql> select * from XTRADB_ADMIN_COMMAND /*!XTRA_LRU_RESTORE*/;

Programar un dump cada X segundos
```
mysql> set innodb_auto_lru_dump = 60;
```

Cargar automáticamente un dump tras reinicio

shell> vi /etc/my.cnf
  innodb_buffer_pool_restore_at_startup=1

Restaurar backup de xtrabackup

En un post anterior, se explicó como realizar un backup de MySQL con xtrabackup, ahora toca coger aquella copia del MySQL (mysql.tar.gz) y restaurala para poder trabajar con ella nuevamente.

Si hace falta recurrir a la copia de seguridad, es por que algo falló a nivel de base de datos, por lo tanto, restaurar el servicio en el menor tiempo posible es primordial.

Para hacerlo, hay que realizar los siguientes pasos.

Se para el servicio MySQL
```
shell> service mysql stop
```
Se realiza una copia del directorio de datos
```
shell> mv /srv/mysql /srv/mysql.bak
```

Se descomprime la copia de la base de datos

shell> mkdir /srv/mysql/
shell> cd /srv/mysql
shell> tar xvfi /var/backups/mysql.tar.gz

Se reindexa la base de datos y se establecen los permisos

shell> innobackupex --apply-log --ibbackup=xtrabackup_51 ./
shell> chown -R mysql:mysql /srv/mysql/

Se arranca el servicio MySQL
```
shell> service mysql start
```

Suscribirse a: Entradas ( Atom )