lunes, 20 de abril de 2009

Centralizando Tareas - Cron

He estado dándole vueltas a la idea de centralizar las tareas programadas, ya que el número de máquinas aumenta de manera casi exponencial y al final esto se hace imposible de administrar.

He probado varias, aplicaciones para este propósito y la conclusión final es que me aportan más trabajo que beneficio, ya que todas ellas gestionan mas cosas de las que necesito y su puesta en marcha y curva de aprendizaje es demasiado costosa.

Por este motivo me he decidido a centralizarlo del modo mas simple, pero que se ajusta a mis propósitos.
Desde el propio cron con conexiones SSH, de este modo, puedo administrar o ver en que máquina se ejecuta que, y por quien, de un simple vistazo a su cron.

La idea es la siguiente, una máquina, hará la función de "maestro" y las demás serán "esclavas" de esta, de este modo solo habrá que revisar y actualizar el cron de la máquina "maestro", ya que esta lanzará mediante ssh con claves publicas /privadas, los scripts que se ejecutaran en las demas máquinas.

1.- Garantizar el acceso mediante ssh.
Hay que garantizar el acceso por ssh de la máquina maestro a las demás, para cada usuario. Esto esta explicado en un post anterior. Aquí

2.- Editar el cron de la máquina "maestro"

El cron queda de la manera siguiente:

###Maquina Pruebas 1


#user1


31 14 * * * /usr/bin/ssh user1@192.168.1.143 '/etc/local/script_pru1'


#Root


35 14 * * * /usr/bin/ssh root@192.168.1.143 '/etc/local/script_pru2'



Desglosamos mediante comentarios, la máquina "esclavo" afectada y para que usuario (Simplemente a nivel organizativo).
Tras esto editamos la linea de cron propiamente dicha, en la que definimos los patrones de tiempo que correspondan, y lanzamos el cliente ssh de nuestra máquina "maestro" con usuario y host destino ("esclavo"), y con ('') definimos el script remoto que vamos a ejecutar.




Desventaja - 1

Es evidente pensar que depender de una única máquina para gestionar las tareas programadas es un inconveniente, ya que tenemos un cuello de botella, en cuanto a alta disponivilidad se refiere.

Solución.

Una posible solución es esta:
Montando un cluster RH, podemos definir un servicio adicional "cron", el cual al bascular entre nodos, migre el demonio "crond" y ejecute un script que monte un directorio en almacenamiento compartido en /var/spool/cron, de este modo tendremos dos maquinas operativas para servir de gestor de crons. El orden seria , primero el montaje del directorio y luego levantar el servicio crond. Este proceso se puede realizar siguiendo el siguiente post. Aquí

Desventaja - 2

Otro problema es el coste de trabajo, que supone habilitar el acceso por ssh de la máquina "maestro" a las demas "esclavos"
Este problema no es "solucionable" pero el beneficio obtenido de centralizar los procesos es evidente ya que el tiempo invertido será recuperado con creces al aumentar la simplicidad de administración

miércoles, 8 de abril de 2009

REXEC sobre Centos4

Bueno aunque se que esto no es lo más recomendable por motivos evidentes de seguridad, en ocasiones nos encontramos con la necesidad de montar servicios "R" por especificaciones de fabricantes.
Aquí intento comentar un modo de hacerlo e intentar que sea un poco más seguro.

Instalacion de "rexecd"

Rexec forma parte de los servicios ofrecidos a través de "rsh-server"
yum install rsh-server.i386

Editar el fichero de configuración de Rexec

vi /etc/xinetd.d/rexec

En el cambiamos la opción de disable a "no", para habilitar el servicio bajo xinetd

# default: off

# description:

# Rexecd is the server for the rexec program. The server provides remote

# execution facilities with authentication based on user names and

# passwords.

service exec

{

socket_type = stream

wait = no

user = root

log_on_success += USERID

log_on_failure += USERID

server = /usr/sbin/in.rexecd

disable = "no"

}



una vez hecho esto, para permitir el uso a root debemos modificar el fichero
/etc/securetty

Y añadir al final la aplicación que queremos permitir en este caso, rexec

......

......

......

rexec


Tras esto rebotamos el servicio de xinetd y listo, el rexec con todos sus "problemas de seguridad" está operativo.

Para intentar securizar el servicio dentro de lo posible, podríamos entre otras cosas, implementar algo bajo iptables como lo que sigue.

#!/bin/bash

#

#Borramos todas las reglas existentes, comenzamos en un estado limpio

#

iptables -F

#

# Politicas por defecto INPUT, FORWARD y OUTPUT

#

iptables -P INPUT ACCEPT

iptables -P FORWARD ACCEPT

iptables -P OUTPUT ACCEPT

#

#Permitimos rexec desde la maquina autorizada

iptables -A INPUT -p tcp -s x.x.x.x/24 --dport 512 -i eth0 -j ACCEPT

#

#Denegamos el resto de accesos rexec para todas las maquinas

#

iptables -A INPUT -p tcp --dport 512 -i eth0 -j DROP

#

#Salvamos las politicas

#

/sbin/service iptables save

#

#Listamos las reglas cargadas

#

iptables -L -v



Solo me queda recomendar encarecidamente no usar este tipo de servicios a menos que no sea estrictamente necesario.

sábado, 4 de abril de 2009

HTTP - URL's "escapadas" - Alternativas

Este post es una nota mental para no olvidar algunas de las alternativas que he encontrado para evitar el problema de las URL's escapadas en Apache.
Este problema se produce cuando la URL recibida contiene caracteres especiales, que son interpretados y cambiados por su código ASCII, al realizar un "RewriteRule" la lista la podemos consultar por ejemplo en:


http://www.w3schools.com/TAGS/ref_urlencode.asp

Alternativa1
La primera alternativa para este problema, nos la proporciona el mismo "mod_rewrite", y es su flag [NE], el cual evita que estos caracteres sean "escapados"

Ejem.

RewriteRule /ejemplo/(.*) http://www.XXX.es/ejemplo2/$1 [NE]

En este ejemplo cualquier cosa que tenga un patrón de URL que comience por "/ejemplo" será traducido a "http://www.XXX.es/ejemplo2", pasando la ultima parte de la URL contenida en (.*) a la variable "$1"

El problema que presenta esta solución es que este flag está disponible desde la versión 1.3.20 de Apache y en maquinas muy antiguas esto es un inconveniente.

Alternativa2
La segunda alternativa, también es propia de "mod_rewrite", solo que está disponible desde mediados de la versión 1.2 y para todas las versiones 1.3.X y 2.X
La directiva "RewriteMap", es la que nos proporciona esta solución. Esta directiva tiene cuatro funciones internas, las cuales nos permiten saltar entre mayúsculas y minúsculas y escapes o unescapes, las URL's

Ejem.

RewriteMap fescape int:escape RewriteMap funescape int:unescape RewriteRule /ejemplo/(.*) http://www.XXX/ejemplo2/${escape:{unescape:$1}} [R]

ó

RewriteRule /ejemplo/(.*) http://www.XXX/ejemplo2/${unescape:$1} [R]

En este ejemplo, definimos las funciones "fescape" y "funescape" como funciones internas de escape y unescape, de "RewriteMap". Posteriormente, aplicamos estas funciones a nuestra variable "$1", dentro del "RewriteRule". Se pueden aplicar en el orden que se necesite, como se ve en las dos lineas de RewriteRule anteriores.

El problema de esta solución, es que según Apache, estas funciones son aplicadas a la URI, nunca a la sentencia de Query String, posterior a un "?"

Ejem. http://www.XXX.es/XXX?="QueryString"
Nota: Las comillas de este ejemplo no se verían afectadas.


Alternativa3
La siguiente alternativa, pasa por crear un pequeño script que nos genere la URL correcta, sin que esta sea "escapada"
Para este propósito basta con una directiva que apunte a nuestro script:

ScriptAlias /ejemplo /path/script_url

En nuestro script usaremos las variables:

PATH_INFO: Contiene la URI que recibe Apache antes de ser escapada QUERY_STRING: Contiene la Query String que recibe Apache antes de ser escapada

En perl:
my $url = "http://www.XXX.es"$ENV{PATH_INFO}."?".$ENV{QUERY_STRING};

Tras esto construimos una página mediante prints, con un meta que contenga como url la que hemos construido. Este Post es simplemente para ver que existen distintas formas para este proceso, y que cada una de ellas tienes sus diferencias, es cuestión de elegir ;)