Publicado el

Vaciar el error.log de MySQL

Un tema que me ha preocupado siempre, son los logs de MySQL, y más concretamente el error.log. En entornos de replicación, el error.log puede llegar a ser gigante cuando se usan sentencias que el sistema detecta como «advertencias». Por ejemplo:

[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. The statement is unsafe because it uses a LIMIT clause. This is unsafe because the set of rows included cannot be predicted.

¿Cómo podemos vaciar el error.log de forma segura, sin que tenga impacto en el servicio de MySQL? Pues vamos a verlo.

Continuar leyendo «Vaciar el error.log de MySQL»

Publicado el

Monitorizar upload FTP desde script

Upload FTP¿Cómo podríamos saber si un fichero que está siendo subido por FTP ha acabado o no de subirse? Hay algunas posibles soluciones en esta conversación de SuperUser.com, la última de las cuales, es la que he usado.

Para los testeos, he usado un servidor vsFTPd (configurado tal y como expliqué aquí) sobre un servidor CentOS 5.4. Como no tenía ficheros grandes para hacer el test, he creado uno de forma instantánea, con el siguiente comando:

[root@adripc]# fallocate -l 100M test.img
[root@adripc]# ls -lah test.img
-rw-r–r– 1 root root 100M Jul 18 10:20 test.img

La idea es usar lsof para saber el PID del proceso de vsFTPd que está siendo usado para subir el fichero destino, y entoces monitorizar ese PID.  El problema que me he encontrado, al menos con el entorno de test que he usado, es que ese PID de subida puede cambiar durante la subida. No sé bien bien porqué razón, pero en mi caso cambia. Si cambia el PID entonces ya no podremos monitorizar ese PID, ya que el PID habrá finalizado (o no) pero no así la subida, que estará usando otro PID diferente.

En este caso, la solución es más sencilla aun, ya que bastará con símplemente ir consultando mediante lsof y en caso de devolver vacío, nos indicará que no hay ningún proceso usando el fichero y que por tanto, la subida ha finalizado. Así, nos dará igual que el PID cambie. Lo único importante es que durante la subida del fichero, ese archivo tendrá un PID asociado, mientras que cuando haya acabado el upload, no tendrá ningún PID y por tanto lsof devolverá vacío.

Continuar leyendo «Monitorizar upload FTP desde script»

Publicado el

vsftpd con TLS explícito en CentOS

Seguridad

vsftpd es un servidor FTP que debería ser «Very Secure FTP», pero que por defecto es justo lo contrario. Con un poco de trabajo, podemos dejarlo bastante mejor, que es precisamente, lo que voy a mirar de describir a continuación.

Lo que queremos es forzar a los clientes a usar FTP+TLS Explícito, en lugar de FTP simple, para forzar comunicaciones cifradas. Además, usaremos FTP pasivo, enjaularemos a los usuarios y crearemos un listado de usuarios que puedan conectar, para tener controlados a los usuarios FTP.

Las pruebas se han realizado sobre un servidor CentOS 5.4 con vsFTPd 2.0.5.

En primer lugar, si no lo tenemos ya, podremos instalar vsftpd desde yum.

[root@MyServer]# yum install vsftpd

Certificado SSL

A continuación, generaremos el certificado para el SSL y le daremos los valores adecuados:

[root@MyServer]# openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout /etc/vsftpd/vsftpd.pem -out /etc/vsftpd/vsftpd.pem
Country Name (2 letter code) [GB]:ES
State or Province Name (full name) [Berkshire]:Spain
Locality Name (eg, city) [Newbury]:Barcelona
Organization Name (eg, company) [My Company Ltd]:Mi Empresa S.A.
Organizational Unit Name (eg, section) []: IT
Common Name (eg, your name or your server’s hostname) []:midominio.com
Email Address []:

Una vez generado, cambiaremos los permisos del fichero:

[root@MyServer]# chmod 600 /etc/vsftpd/vsftpd.pem

Continuar leyendo «vsftpd con TLS explícito en CentOS»

Publicado el

chmod recursivo diferenciando ficheros y directorios

En Linux, en más de una ocasión necesitamos cambiar los permisos de todo un árbol de directorios, por ejemplo, de un proyecto web que encontramos con demasiados permisos. Es habitual, para los directorios, dejar los permisos 755, mientras que para ficheros se suele usar 644.

Pero, ¿cómo modificar los permisos de forma recursiva, diferenciando ficheros de directorios? Unos comandos muy muy útiles (y que podemos encontrar en muchas webs, por ejemplo aquí) son los siguientes:

Modificar los permisos recursivamente únicamente de directorios, desde el punto en el que estamos situados:

find . -type d -exec chmod 755 {} \;

Modificar los permisos recursivamente únicamente de ficheros, también desde el punto en el que estamos situados:

find . -type f -exec chmod 644 {} \;

Con estos dos comandos, podremos cambiar los permisos de forma recursiva, aplicando diferentes permisos para los directorios y para los ficheros. Si se quiere profundizar más, el siguiente enlace explica cómo usar «find» para distinguir los tipos de ficheros.

Fuentes:

http://rainsoftletters.wordpress.com/2008/07/22/recursively-chmodi-only-directories-or-files/

Publicado el

Programar tareas con ‘at’ en Linux

Un comando que he de reconocer que no uso todo lo que debería, es «at». Esta herramienta nos permite programar tareas que se ejecutarán una única vez. Es realmente fácil de usar y funciona a las mil maravillas. No tiene sentido usar «cron» para este tipo de tareas, puesto que cron está pensado para programar tareas que se ejecutarán con cierta periodicidad.

La idea es primeramente escribir en qué momento se va a ejecutar la tarea. Por ejemplo, si estamos a jueves a las 16:00, y queremos ejecutar una tarea una única vez la madrugada del jueves al viernes, a las 06:00, podemos ejecutar:

[root@myserver]# at -v 06:00
Fri May 17 06:00:00 2013

Actualización: Si por el contrario, queremos programar la tarea para que se ejecute el próximo 18 de Mayo a las 03AM, bastará con ejecutar:

[root@myserver]# at -v 3am May 18
Sat May 18 03:00:00 2013

La opción «-v» nos devolverá la fecha en que se va a programar la tarea. Al ejecutar la sentencia, nos entrará en «at>», que es donde tendremos que introducir la tarea a ejecutar, que al igual que hacemos con cron, puede ser una instrucción o por ejemplo la ejecución de un script:

at> /home/adri/script.sh >> /tmp/out_script.log 2>&1

Una vez acabados de introducir los comandos a ejecutar, pulsaremos «Control+D» para salir de «at>» y finalizar así las instrucciones a ejecutar. Ésto nos mostrará el fin de la tarea, el job id y de nuevo la fecha y hora programados:

at> <EOT>
job 1 at 2013-05-17 06:00

Con «at -l» listaremos las tareas pendientes, donde el primer carácter corresponderá con el id del job:

[root@myserver]# at -l
1 2013-05-17 06:00 a root

Podremos ver los detalles de la tarea programada, con «at -c» seguido del id del job. Ésto nos mostrará todo lo que se ejecutará, incluído el entorno:

[root@myserver]# at -c 1

Finalmente, siempre podremos cancelar un job, antes de la fecha de ejecución, con la opción «-d»:

[root@myserver]# at -d 1

Fuente:

http://content.hccfl.edu/pollock/unix/atdemo.htm

Publicado el

Convertir un servidor a virtual con VMWare

clonYa me he encontrado en más de una ocasión, con algún antiguo servidor que corría en un viejo hardware, pero que resultaba ser muy crítico y con configuraciones muy específicas. Quizá se trate de un antiguo servidor con decenas proyectos, cada cual con sus módulos y configuraciones específicas.

En estos casos, una buena opción es preparar un nuevo hardware, un nuevo SO, e ir migrando uno a uno, cada proyecto. Si se tiene tiempo y paciencia, claro. Si no, otra solución es usar VMWare Converter, una solución gratuita de VMWare que permite hacer un clonado de una máquina física, a virtual. De esta manera, podemos dejar de sufrir por si el viejo hardware del servidor decide pasar de forma definitiva a mejor vida.

La idea es ejecutar desde una máquina remota, VMWare  Converter, para crear una imagen clónica de una máquina física, y poder así, empezar a usar la nueva imagen VMWare, que sustituirá a la máquina remota. Lo bueno es que efectivamente, se realiza un clonado de la máquina física, incluyendo todos los ficheros, servicios, tareas programas, configuraciones, etc, asegurándonos así de contar con el mismo entorno, pero virtualizado.

En este ejemplo, he usado el siguiente escenario:

  • Máquina a clonar: Server físico Windows 2000 Server SP4 con IIS
  • Destino: ESX Host 4.0 en un VMware vCenter Server 4.1.0
  • Máquina desde la que se ejecuta el Converter: Windows Server 2003 32 bits

NOTA: No me he lanzado a usar la última versión de VMWare Converter, ya que he leído en múltiples sitios que aunque en la documentación oficial únicamente se advierte de no correr el VMWare Converter en una máquina Windows 2000, no dice nada de que este SO no pueda usarse como source. En cualquier caso, y para evitar problemas, he usado la última versión compatible con Windows 2000, la 4.0.1.

Continuar leyendo «Convertir un servidor a virtual con VMWare»

Publicado el

System DNS Cache en Linux

cache DNSEste fin de semana casi nos cargamos a un pobre servidor DNS por un exceso de consultas al realizar un envío de varios miles de mails. En algunos servidores Linux, no hay una caché DNS a nivel de sistema operativo, y por tanto, cada envío de mail requiere de su correspondiente resolución DNS, a pesar de que se estén enviando 1.000.000 de mails todos al mismo dominio @miempresa.com. [fuente, otra fuente, y más fuentes].

Ésto  lo podemos comprobar, por ejemplo desde mi portátil con Fedora, monitorizando con tcpdump las peticiones DNS y ejecutando en paralelo un «ping google.com»:

[root@AdriPC sh]# tcpdump -vvv -s 0 -l port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:44:09.480324 IP (tos 0x0, ttl 64, id 14684, offset 0, flags [DF], proto UDP (17), length 59)
AdriIPC.36193 > google-public-dns-a.google.com.domain: [udp sum ok] 14321+ A? www.google.es. (31)
16:44:09.509206 IP (tos 0x0, ttl 64, id 14713, offset 0, flags [DF], proto UDP (17), length 66)
AdriIPC.51444 > google-public-dns-a.google.com.domain: [udp sum ok] 64003+ PTR? 8.8.8.8.in-addr.arpa. (38)
16:44:09.520190 IP (tos 0x0, ttl 48, id 61176, offset 0, flags [none], proto UDP (17), length 91)
google-public-dns-a.google.com.domain > AdriIPC.36193: [udp sum ok] 14321 q: A? www.google.es. 2/0/0 www.google.es. [3m28s] A 173.194.34.247, www.google.es. [3m28s] A 173.194.34.248 (63)
16:44:09.533873 IP (tos 0x0, ttl 64, id 14738, offset 0, flags [DF], proto UDP (17), length 73)
AdriIPC.50336 > google-public-dns-a.google.com.domain: [udp sum ok] 27187+ PTR? 247.34.194.173.in-addr.arpa. (45)

[…]

Si ejecutamos «ping google.com» una segunda vez, veremos como vuelve a capturarse la consulta DNS mediante tcpdump, confirmando así que no hay ningún tipo de caché DNS.

En la mayoría de escenarios, no necesitaremos una caché DNS, pero si tenemos un servidor que ofrece un servicio que hace un uso intensivo de resolución de nombres, seguramente nos merezca la pena buscar una solución.

Continuar leyendo «System DNS Cache en Linux»

Publicado el

Test de integridad de discos con S.M.A.R.T.

158829630_ad14f8265f_zHoy toca verificar el estado de los discos de un servidor CentOS 6 que en nuestro ejemplo, cuenta con un RAID 1 software con 2 discos SATA de 3TB cada uno. Para ello, lo primero que podemos hacer es asegurarnos de qué discos tiene nuestro servidor, con un simple df -h para ver las particiones y verificar como todas son del estilo «mdX» lo cual nos indica que se trata de un RAID software:

[root@myServer]# df -h
S.ficheros Size Used Avail Use% Montado en
/dev/md5 1,1T 81G 908G 9% /
[…]

Podemos verificar el estado del RAID con:

[root@myServer]# cat /proc/mdstat
Personalities : [raid1]
md5 : active raid1 sdb7[1] sda7[0]
[…]

Aquí observamos como por ejemplo, md5 está activo, y tiene un RAID1 entre sdb7 y sda7.

Con fdisk podemos ver si el servidor dispone de más discos, además de los que hemos observado a simple vista:

[root@myServer]# fdisk -l
Disco /dev/sdb: 3000.6 GB, 3000592982016 bytes
[…]
Disco /dev/sda: 3000.6 GB, 3000592982016 bytes
[…]

Además, el fdisk nos mostrará las particiones de cada disco, así como las particiones del tipo «mdX». En nuestro caso, fdisk confirma que únicamente contamos con 2 discos, sda y sdb.

Pasemos, pues, a analizar la integridad de ambos discos con SMART.

Continuar leyendo «Test de integridad de discos con S.M.A.R.T.»

Publicado el

Python 2.7 en CentOS 6 con mod_wsgi

python2En este post, veremos cómo instalar una nueva versión de Python (la 2.7.5) manteniendo la versión del sistema (2.6.6 en CentOS 6), forzando al mod_wsgi de Apache a usar la nueva versión en lugar de la de sistema. La idea es no tocar la versión de sistema, puesto que si cambiamos dicha versión, seguramente nos encontraremos más adelante con problema de dependencias en prácticamente cualquier actualización o instalación que queramos hacer con yum.

De esta manera, lo que haríamos sería hacer una segunda instalación de la nueva versión de Python, que no comprometiera la instalación original. En el ejemplo, estamos usando un servidor CentOS 6.4 que por defecto, viene con Python 2.6.6, con un servidor Apache con mod_wsgi 3.2. Lo que queremos, es instalar Python 2.7.5 sin comprometer el Python del sistema, instalar los módulos de Python necesarios para nuestra aplicación, pero únicamente para la nueva versión 2.7.5, y finalmente, reconfigurar mod_wsgi para usar la nueva versión.

Para ello, podríamos seguir los pasos descritos a continuación:

Entorno

Comprobamos los detalles del sistema operativo:

[root@MyServer]#cat /etc/redhat-release
CentOS release 6.4 (Final)

Verificamos la versión de python del sistema:

[root@MyServer]# python --version
Python 2.6.6

Continuar leyendo «Python 2.7 en CentOS 6 con mod_wsgi»

Publicado el

Instalar SO remotamente con IPMI

remoteLas interfaces IPMI de los servidores Supermicro, nos permiten gestionar remotamente un servidor aun cuando éste está apagado, o como en el caso que nos ocupa hoy, incluso nos permiten hacer instalaciones remotas de sistemas operativos.

La idea es simple: la interfaz IPMI tiene autonomia propia, independientemente del estado del propio servidor. Así pues, podemos conectar vía web con la interfaz IPMI del servidor, y configurar en Virtual Media > CD-ROM Image, la ruta donde almacenaremos la imagen ISO con el sistema operativo. Esta imagen, deberemos almacenarla en un segundo servidor al cual se pueda acceder desde la interfaz IPMI (típicamente un servidor ubicado en la misma red).

Las pruebas han sido realizadas con una interfaz IPMI con las siguientes características:

  • Firmware Revision: 02.15
  • Firmware Build Time: 2013-01-18

El servidor donde se ha alojado la imagen, ha sido un servidor CentOS sin samba préviamente instalado. Así pues, ha sido necesario instalar y configurar samba para permitir el acceso a la ISO desde la interfaz IPMI. Si se tuviera un servidor Windows, este apartado se haría de forma diferente.

Continuar leyendo «Instalar SO remotamente con IPMI»