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/

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

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»

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»

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.»

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»

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»

Entradas más vistas en 2012 y estadísticas

trofeosUn poco tarde, lo sé, pero he encontrado interesante hacer un listado de las entradas más visitadas de 2012. Por orden, a continuación las 10 entradas más visitadas del 1 de enero de 2012 al 1 de enero de 2013, según Google Analytics:

  1. Usuario ‘sa’ bloqueado [2009] Av.Time 06:44 min
  2. Teclado en Ubuntu Server 11 [2011] Av.Time 06:07 min
  3. Mod_wsgi en Apache [2011] Av.Time 09:47 min
  4. Nagios: añadir nuevo host [2011] Av.Time 06:36 min
  5. Integrar Magento con PayPal [2010] Av.Time 07:08 min
  6. Intel VPro, AMT, ME, MEBx [2011] Av.Time 06:51 min
  7. ITIL Fase 3: Transición [2012] Av.Time 01:51 min
  8. Magento: más configuraciones [2011] Av.Time 04:09 min
  9. Tomcat. Aplicación y puerto por defecto [2012] Av.Time 05:40 min
  10. ¿Cuándo reiniciar Apache? [2011] Av.Time 05:07 min

Un dato interesante es que la entrada más visitada durante 2012 corresponde a un post de 2009, sobre cómo solucionar el problema de encontrarse al usuario «sa» bloqueado en SQL Server. Post útil donde los haya, pero publicado en 2009.

Continuar leyendo «Entradas más vistas en 2012 y estadísticas»

Balanceador de carga MySQL con HAProxy

balanceadorHace unas semanas, vimos cómo configurar un balanceador de carga con la aplicación de balanceo en entornos Red Hat por antonomasia: LVS, (y Piranha). LVS es la aplicación nativa de balanceo, muy bien documentada en la documentación oficial de Red Hat, e incluso vendida como balanceador en forma de addons.

Este tipo de configuraciones, funcionan muy bien, pero tienen una serie de requisitos, pues se ha de reconfigurar la red de los servidores implicados para compartir una IP Virtual, o para cambiar el default gateway (en el caso de LVS-NAT). Ésto no siempre nos es posible hacerlo, puesto que quizá estemos trabajando con un proveedor de servidores dedicados, como en mi caso Hetzner, que no permite hacer cambios en las interfaces de red que vienen configuradas en el equipo, y que además parece que no lleva bien lo de las IPs compartidas.

En cualquier caso, hay otras soluciones de balanceo, como HA Proxy, que en el siguiente ejemplo usaré para balancear las peticiones MySQL entre dos servidores con IPs públicas situados bajo el mismo switch, en Hetzner. Todos los servidores son CentOS 6.3 x64.

Continuar leyendo «Balanceador de carga MySQL con HAProxy»

Duplicar un slave MySQL con Rsync

Fotor0427201142Ya hemos hablado de cómo crear un entorno con varios slaves mediante XtraBackup, pero también existe la posibildad (mucho más drástica) de copiar los datos de un slave a otro, mediante rsync. Normalmente, siempre usaremos la opción de XtraBackup, pues con XtraBackup se puede hacer un backup en caliente (sin necesidad de parar MySQL) y por tanto no se necesita ninguna interrupción en el servicio.

Sin embargo, también existe la opción de usar rsync, que en mi caso, he testeado bajo en siguiente entorno:

  • Slave1 (origen): CentOS 6.3 con Percona 5.5 Release rel29.3, Revision 388
  • Slave2 (destino): CentOS 6.3 con Percona 5.5 Release rel29.4, Revision 401

NOTA: Sí, he hecho el test con dos versiones ligeramente diferentes de Percona, ya que estoy en un entorno de test.

En mi caso, he seguido el siguiente proceso para realizar la copia:

Continuar leyendo «Duplicar un slave MySQL con Rsync»