proteger ficheros en apache para su descarga

29 de julio de 2009

Muchas veces cuando programamos directamente sobre una carpeta del DocumentRoot dejamos sin querer todo tipo de archivos como backups de una carpeta, volcado sql de una tabla, backup de un archivo php generado por nuestro editor de texto, archivos de include, etc. Todos estos archivos quedan disponibles para la descarga.

La directiva <FilesMatch> de Apache evita que cualquier archivo no deseado con información sensible pueda ser descargada. Para ello simplemente tenemos que pasarle una expresión regular con los archivo que queremos denegar el acceso y el Apache devolverá un error 403 cada vez que se intente acceder a ellos:

<FilesMatch "\.(old|bak|tgz|sql|inc|tar\.gz|zip|rar)$">
   Order Deny,Allow
   Deny from All
</FilesMatch>

La ultima vez que utilicé esto era para proteger dumps de SQL que se generaban automáticamente (ddmmaaa-backup.sql.tgz) y que por narices debían de permanecer dentro del DocumentRoot de la aplicación.

Solo hace falta darse un a vuelta por la Google Hacking Database para encontrar todo tipo de ficheros como estos por Internet.

¿qué es ITIL? (ii de ii)

24 de julio de 2009

3. Transmisión del servicio

Consiste en preparar y dejar listo el servicio garantizando el menor impacto posible sobre los servicios en producción, las operaciones y la propia organización. Esta fase consta de tres procesos: gestión de cambios, gestión de la configuración y gestión de versiones.

La gestión de cambios tiene como objetivo emplear medios y procedimientos estandarizados para una tramitación eficaz y rápida de todos los cambios, a fin de reducir al mínimo el impacto sobre los servicios relacionados. Se define la figura del comité de cambios como un asesor que se reúne periódicamente para evaluar cambios y ayudar a priorizarlos.

La gestión de la configuración define y controla todos los componentes de una infraestructura IT y mantiene una base de datos con toda la información de las configuraciones (CMDB, Configuration Management Database).

Por último la gestión de versiones garantiza que existen planes de cambios y despliegues necesarios para mantener la alineación con los clientes y el negocio en los proyectos de cambios. Asegura que las versiones podrán crearse, instalarse, testearse y desplegarse exitosamente dentro de los plazos establecidos.

4. Operación del servicio

Consiste en coordinar y ejecutar las actividades, procedimientos y procesos necesarios para entregar y gestionar servicios con los niveles acordados. En esta fase se administra el servicio contratado por el cliente y se le da soporte.

Aparecen cinco procesos: gestión de incidencias, gestión de problemas, gestión de peticiones de servicio, gestión de accesos y gestión de eventos.

La gestión de incidencias tiene como objetivo restaurar la operación normal del servicio tan rápido como sea posible y minimizar el impacto negativo.

La gestión de problemas estudia más tarde y más detalladamente todas las incidencias producidas para evitar que se vuelvan a producir.

La gestión de peticiones define un único canal para que el cliente pueda recibir o solicitar servicios estándares (de nuestro catálogo) y aprobados.

El objetivo de la gestión de accesos es proporcionar a los usuarios autorizados el derecho a utilizar los servicios mientras se impide el acceso a otros. Se basa siempre sobre la gestión de disponibilidad y la gestión de seguridad de los puntos anteriores.

Por último la gestión de eventos proporciona la detección de fallos, proporcionando la capacidad en tiempo de real de comparar el rendimiento de nuestro servicio IT con lo contratado por el cliente en la SLA.

5. Mejora continua del servicio

Su objetivo es hacer recomendaciones sobre cualquier oportunidad de mejora durante toda la fase de vida del servicio. También intenta mejorar la rentabilidad de la prestación del servicio sin sacrificar la satisfacción del cliente.

¿qué es ITIL? (i de ii)

Últimamente están apareciendo en muchos centros una nueva certificación llamada ITIL Foundation. Yo en su día me tuve que preguntar que era esto de la ITIL...
ITIL son las siglas de Information Technology Infraestructure Library, y como en muchas certificación IT consta de muchos cursos, cada uno con su examen y su pasta para desembolsar.

El primer curso de ITIL es el que se conoce como la ITIL Foundation v3, que básicamente es la base que se debe conocer. El concepto de ITIL recoge un conjunto de las mejores prácticas para la gestión eficiente de una infraestructura de servicios IT. Fue escrita por la agencia de telecomunicaciones británica en los 80 y se ha demostrado con el tiempo su utilidad en cualquier empresa de cualquier tamaño.

La ITIL Foundation se estructura y se estudia según cinco libros (no necesariamente en este orden):

- 1. Estrategia del servicio
- 2. Diseño del servicio
- 3. Transmisión del servicio
- 4. Operación del servicio
- 5. Mejora continua de la calidad del servicio

Como veis se trata de un orden lógico en el diseño, implementación y puesta en marcha de un servicio.

En la ITIL Foundation se da una explicación muy detallada de cada una de estas fases y como se relacionan entre sí. Además proporciona todo un vocabulario muy extenso que debe aprenderse ya que se utiliza constantemente en todos las fases.

Explico que es cada una de estas fases:

1. Estrategia del servicio

El objetivo de esta fase es identificar a la competencia y hacer diferenciar nuestro producto o servicio. Debemos encontrar respuestas a ¿qué servicios ofreceremos y a quién?, ¿cómo nos diferenciaremos?, ¿cómo alcanzamos una calidad de servicio?... En esta fase ITIL distingue tres procesos llamados: gestión financiera, gestión de la demanda y gestión del portfolio.

En la gestión financiera debemos de cuantificar, a través de una análisis de inversión, el coste de cada uno de nuestros servicios IT a lo largo de todo su proceso de vida.

En el proceso de gestión de la demanda debemos calcular con precisión la demanda que puede suponer un servicio y de esta forma ajustar al máximo los recursos IT que poseemos.

Por último en la gestión del porfolio encontraremos todo lo que sabemos hacer. No todo está disponible, pero un buen porfolio nos permite anticipar nuestros servicios IT a la competencia.

2. Diseño del servicio

El objetivo de esta fase es diseñar el servicio IT siempre minimizando los riesgos, cumpliendo los objetivos marcados en la estrategia y ahorrando en tiempo y dinero. En el diseño del servicio se definen 5 procesos: gestión del catálogo, gestión del nivel del servicio, gestión de la disponibilidad, gestión de la continuidad, gestión de los proveedores, gestión de la seguridad y gestión de la capacidad.

La gestión del catálogo es proporcionar una única fuente de información de todos los productos que proporciona nuestra empresa. Se trata de un subconjunto de servicios disponibles en nuestro porfolio (definido en la estrategia del servicio). Nosotros ofrecemos nuestro catálogo de servicio al cliente y cualquier otra cosa que no se encuentre en nuestro catálogo, para ITIL no se puede ofrecer.

La gestión del nivel del servicio controla y mejora los niveles acordados al comprar un servicio. Se define el concepto de SLA (Service Level Agreemet) que se estipula en el contrato del cliente (tiempos de respuesta, tiempos de parada, horarios de atención al cliente, etc).

La gestión de la disponibilidad optimiza los recursos de nuestra IT para que todo funcione correctamente para cumplir la SLA firmada por el cliente.

La gestión de la continuidad del servicio se preocupa de que todo siga funcionando en caso de una fuerza mayor. Por ejemplo redundando lo servicios en otro lugar y siempre teniendo en cuenta que la continuidad de nuestro servicio debe cumplir la SLA.

La gestión de los proveedores negocia y acuerda todos los contratos con terceros. El mantenimiento de una política con nuestros proveedores debe asegurar como siempre los niveles de SLA. No podemos dejar de prestar un servicio porque nuestro proveedor nos ha fallado.

La gestión de la seguridad como este todas políticas de seguridad debe asegurar la confidencialidad, la integridad y la disponibilidad de toda la información que manipulamos. Además incluye políticas sobre control de contraseñas, acceso remoto y el uso correcto de todos los activos por parte de los trabajadores.

Por último la gestión de la capacidad es la encargada de que todos los servicios se vean respaldados por una capacidad de proceso y almacenamiento suficiente. Debemos estudiar que los recursos se aprovechen adecuadamente (ni más ni menos) para evitar inversiones innecesarias. O peor aun, que los recursos que tengamos se queden cortos y no nos permitan cumplir la SLA.

hackeando las pilas

un ordenador en la luna

21 de julio de 2009

No se que pasa que cada día en la tele estamos llegando a la luna. Cada día estamos celebrando que el hombre llegó a la luna. Yo soy de los que no se cree que llegara, al menos, en la fecha oficial.

Lo que si me ha hecho gracia y he perdido un poco el tiempo es en leer la publicación del diseñó interno del AGC (Apollo Guidance Computer) o para los mortales que veían Start Treck el ordenador de a bordo o TomTom. Viendo los diagramas del diseño y la reducción de puertas lógicas me parecía haber vuelto a la universidad cuando estudiaba la asignatura de estructura de computadores.

Resulta que el AGC puede considerarse el primer computador de circuito integrado empotrado y en tiempo real. Tenía un procesador de 1Mhz y 4Kb de memoria RAM. Además tenia un juego de 11 instrucciones. Este cacharro se utilizaba para realizar los cálculos para los aterrizajes y los acoplamientos. A lo largo de las diferentes misiones del Apollo se fue perfeccionando su funcionamiento ya que en su primera misión este cacharro fallo y los astronautas del Apollo 11 tuvieron que aterrizar de forma manual.

Aquí tenéis los planos del AGC por si queréis montaros uno en casa y subiros en un petardo para llegar a la luna. Son más de 1000 paginas de diseño con un coste de $3000 en componentes.

Ya me veo algún becario de arquitectura de computadores que le manden de proyecto final de carrera la implementación del AGC. A pelearse con los mapas de Karnaugh.



mira dentro de mí

15 de julio de 2009

Cuando enviamos un correo electrónico de una dirección a otra, toda esta información se envía en formato texto ASCII. Incluso cuando adjuntamos una imagen o un archivo PDF el correo resultante que viaja de un servidor a otro lo hace en formato texto.
Para ello se utilizan conceptos como los tipo MIME y la codificación en Base64. Hoy día es difícil ver correos que no este hechos en formato HTML con imágenes y a todo color.

Cuando enviamos un correo no solo estamos enviado el cuerpo del mensaje con su From/To, sino mucha más información como editor de correo donde se escribió el mensaje, cuales han sido los antivirus que han analizado el correo, por donde ha ido pasando el correo etc.
El analizar las cabeceras de un correo electrónico puede ser una manera de depurar errores y de comprender un poco más el funcionamiento del SMTP.

Aquí tenéis un ejemplo de un correo que utilizaré para explicar cada una de las partes que lo componen: example_mail.txt.
Se trata de un correo de publicidad de masters de la Universidad de La Salle (Barcelona) enviado a mí a través de una lista de distribución tal como veremos. Desde cualquier cliente de correo podéis acceder a las cabeceras de un correo electrónico.

Si abrimos este correo de ejemplo lo primero que miraremos es quien lo escribe y quien lo recibe:

From: "BES La Salle" <infosolicitud@lasalleonline.net>
To: <infosolicitud@lasalleonline.net>

Es curioso ver que el emisor y el receptor son la misma persona. ¿Cómo puede ser?. En este caso se trata de una lista de distribución. Para ello debemos fijarnos en:
Delivered-To: amperisblog@gmail.com
List-Unsubscribe: <http://columba.salleURL.edu/cgi-bin/mailman/options/infoalumnes>,
                <mailto:infoalumnes-request@columba.salleURL.edu?subject=unsubscribe>
X-Mailman-Approved-At: Fri, 10 Jul 2009 10:09:03 +0200

Nos da la posibilidad de borrarnos de la lista de distribución. Este tipo de casos también pude darse cuando se envia un mail con copia oculta. En el campo To: no aparece nuestro nombre. Esto es debido a que nos han puesto como copia oculta.

También tenemos el campo Date que indica la hora a la que se escribió el mensaje. No es la hora en la que se descargó el mensaje. Por este motivo si tenemos algún problema con nuestro servidor de correo y los correos llegan tarde, es normal que nos aparezcan en nuestra bandeja de entrada correos de fechas pasadas. Normalmente la bandeja de entrada está ordena por fecha.

Date: Fri, 10 Jul 2009 10:08:34 +0200

También podemos ver los diferentes servidores MX por los que ha ido pasando el correo y extraer mucha información de como una empresa tiene implementado sus servidores de correo. Para ello nos tenemos que fijar en los campos "Received":
Received: by 10.103.218.8 with SMTP id v8cs318399muq;
        Fri, 10 Jul 2009 01:10:31 -0700 (PDT)
Received: by 10.204.50.195 with SMTP id a3mr1643982bkg.123.1247213430935;
        Fri, 10 Jul 2009 01:10:30 -0700 (PDT)
Received: from relay1.salle.url.edu (relay1.salle.url.edu [84.88.232.246])
        by mx.google.com with ESMTP id 27si1340370fxm.114.2009.07.10.01.10.29;
        Fri, 10 Jul 2009 01:10:30 -0700 (PDT)
Received: from columba.salle.url.edu (columba.salleURL.edu [84.88.232.238])
 by relay1.salle.url.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6A8A2sH019065
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
 Fri, 10 Jul 2009 10:10:03 +0200
Received: from columba.salle.url.edu (localhost [127.0.0.1])
 by columba.salle.url.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6A894eQ014556;
 Fri, 10 Jul 2009 10:09:59 +0200
Received: from jordiribesi00cc (pcjribes.salle.url.edu [172.16.17.189])
 (authenticated bits=0)
 by columba.salle.url.edu (8.14.3/8.14.3/Debian-5) with ESMTP id
 n6A88ZMC014449; Fri, 10 Jul 2009 10:08:35 +0200

El primer Received que encontramos es directamente nuestro servidor donde está alojado el correo a la espera que nosotros lo leamos por POP/IMAP/Webmail. El último "Received" es el primer servidor SMTP que recibió el correo.
Podemos ver como el correo lo escribió una persona llamada jordiribesi00cc, que su ordenador tenia la IP 172.16.17.189 y que se lo envió a su servidor de correo llamado columba.salle.url.edu" que resulta ser un Sendmail versión 8.14.3 con un Debian v5.
Luego lo volvió a recibir la maquina columba.salle.url.edu en la IP 127.0.0.1. Esto es posible porque se lo pasó al antivirus alojado en su misma maquina. Posteriormente se lo envía a una maquina de relay de correo bajo el nombre de relay1.salle.url.edu a través de una sesión cifrada (cipher=DHE-RSA-AES256-SHA). Finalmente esta maquina sale de la empresa salle.url.edu y contacta con Google para entregarle el correo. La maquina relay1.salle.url.edu con IP pública 84.88.232.246 contacta con el servidor mx.google.com y le entrega el correo a las 01:10:30 hora verano del Pacifico Norte (PDT=UTC-7).
Para finalizar, el correo va pasando por dos máquina más de Google hasta que a las 01:10:31 hora verano del Pacifico Norte se almacena en el servidor con IP 10.103.218.8.

Notar que hay 7 saltos para hacer llegar el correo de un servidor a otro. ¿Son 7 o son más?. Realmente no lo podemos saber. Podría ser el caso que algún servidor interno, por ejemplo Google, no notificara en sus cabeceras por donde va pasando dicho correo.
Otra cosa interesante es saber la versión de Sendmail que está utilizando salle.url.edu. Deberíamos evitar que nuestros servidores dejaran información sobre versiones y sistemas operativos de los servidores de correo. Normalmente por cuestiones de seguridad y bugs que puedan ser explotados.

Se está trabajando en técnicas conocidas como "Reciprocation of SMTP Trace Record" para depurar por donde a ido pasando un correo electrónico. Incluso existe alguna Web que haces un copy-paste del tus Received y te dibuja en un mapa la ruta seguida por el correo al más puro estilo Neotrace.

Los antivirus y otros filtros también dejan su marca cada vez que escanean un correo:
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on relay1.salle.url.edu
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on columba.salle.url.edu
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on columba.salle.url.edu
X-Virus-Status: Clean
X-Scanned-By: MIMEDefang 2.64 on 84.88.232.246
X-Scanned-By: MIMEDefang 2.64 on 84.88.232.238
X-Scanned-By: MIMEDefang 2.64 on 84.88.232.238

Estamos en lo de simpre... evitar que aparezcan versiones y cualquier tipo de información.

Nota: Para evitar que nuestro Postfix/Sendmail anote sus direcciones IP internas o externas en la cabeceras hay que retocar el código fuente y recompilar.

Para debugear este correo cuando llega al primer servidor de correo se añade una marca de idetificación llamada Message-ID. Esta marca la podemos utilizar para tracear el mensaje dentro de nuestros logs de correo.
Message-ID: <000601ca0135$9f2ab0b0$dd801210$@net>

Finalmente llegamos a la parte del cuerpo del mensaje. Dado de que se trata de un correo con imágenes, en HTML y con archivos adjuntos este correo debe ser compuesto en formato MIME (Multipurpose Internet Mail Extension). El MIME son unas extensiones del protocolo SMTP que me permite intercambiar todo tipo de contenido (video, PDF, imágenes, Words, etc) de forma transparente para el usuario.

Lo primero que debemos encontrar son estas dos cabeceras:
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----=_NextPart_000_0007_01CA0146.62B380B0"
X-Mailer: Microsoft Office Outlook 12.0

Lo primero indica que estamos utilizando MIME v1 y el segundo nos indica que el mail está estructurado en varias partes (cuerpo, adjuntos, cuerpo en HTML, etc). En este caso cada parte podrá contener más objetos de tipo MIME. Para separar cada parte de los objetos MIME se utilizará la marca "----=_NextPart_000_0007_01CA0146.62B380B0". Vemos también que el cliente de correo que ha construido el mail en formato MIME a sido un Outlook 2007.

Dentro del objeto MIME con marca "----=_NextPart_000_0007_01CA0146.62B380B0" veremos que encontramos otros objetos MIME que lógicamente también contienen su marca. Por ejemplo "----=_NextPart_001_0008_01CA0146.62B380B0" o "----=_NextPart_002_0009_01CA0146.62B380B0".

Bajo la marca "----=_NextPart_002_0009_01CA0146.62B380B0" encontramos el cuerpo del mensaje en formato texto o "text/plain". Este tipo de objeto se añade por si el receptor no tiene un cliente de correo que acepte HTML.
Luego encontraremos bajo esta misma marca el mismo correo pero en formato HTML o "text/html". Este tipo de objeto se añade para los clientes que tienen un cliente de correo compatible con HTML.

Finalmente, los ficheros adjuntos también van dentro de su tipo MIME:
------=_NextPart_001_0008_01CA0146.62B380B0
Content-Type: image/jpeg;
 name="image001.jpg"
Content-Transfer-Encoding: base64
Content-ID: 

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7
Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAB8AoQDASI
...

En este caso, una de las imágenes a sido añadida como un tipo de fichero adjunto. Para ello le decimos que es de tipo MIME "image/jpeg", que la imagen se llama image001.jpg y que está codificada en Base64. La codificación siempre es necesaria ya que al tratarse de un formato binario este debe convertirse en un formato de texto ASCII para poder ser enviado por SMTP.

Hay otras muchas cabeceras que incluso no salen es este mail de ejemplo. Todas ellas esta explicadas en sus RFCs correspondientes: RFC2045 y RFC2821.

Más información:
- http://es.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions
- http://es.wikipedia.org/wiki/Base64

parando un DoS con nada

10 de julio de 2009

Hay situaciones en las que se produce un ataque de DoS y no tenemos nada para pararlo, o al menos, no tenemos el suficiente control sobre los servidores para detener el ataque. La manera más fácil de denegar las IPs de maquinas que nos atacan es utilizar una cosas que se llama null-route. Es decir, enviar los paquetes a una ruta sin salida.
He de suponer que no tenemos iptables, que no tenemos control sobre los firewall externos, que no tenemos control sobre apache o postfix... solo somos unos pobres admins que nos dedicamos a controlar el estado de la máquina.

Es fácil ver que algo está pasando con un "netstat". Sobre todo cuando tenemos decenas de IPs iguales (DoS) o diferentes (DDoS) conectadas, en un estado de estar pero sin estar: SYN o un SYN_RECV.

Para bannear una IP de estas con un null-route basta con enviar los paquetes de vuelta hacia esa IP por la interfaz de loopback. Supongamos que el ataque viene de 89.140.142.56:

# route add 89.140.142.56 lo

Y ya está. Sin reiniciar, sin iptables, sin tcpwrappers, sin tocar el pix, sin tocar el router... Más información:
- parando un DoS con iptables

mi receta para dom4j

9 de julio de 2009

Hace ya una semana que se publicó un parche para todas las versiones de Zimbra como solución a un bug grave. Lo normal para arreglar bugs era esperar a una nueva versión. Desde la versión 3 solo recuerdo haber añadido un parche de urgencia.

Llevo varios días con el parche instalado y la verdad es que todo funciona igual (es decir, de puta madre). Por lo que he podido ver en el desempaquetado del Jar, el problema debe ir por algún tipo de injección XPath, que tal como dice el descubridor, permite el acceso no autorizado a los archivos situados en el store del Zimbra.

Esta es mi receta de pasos para un Zimbra 5.0.16 bajo CentOS 5. Notar que hay dos archivos Jar para cambiar:

(creamos una carpeta de backup y paramos Zimbra)
# mkdir /backup
# su - zimbra
# zmcontrol stop
# exit
# cd /tmp

(descargamos el patch)
# wget http://files.zimbra.com/downloads/security/dom4j-1.5.jar

(dentro de Zimbra hay dos archivos dom4j-1.5.jar y comprobamos que sean el mismo)
# md5sum /opt/zimbra/lib/jars/dom4j-1.5.jar
# md5sum /opt/zimbra/jetty-6.1.5/common/lib/dom4j-1.5.jar

(hacemos un backup y los sustituimos)
# cp /opt/zimbra/lib/jars/dom4j-1.5.jar /backup
# cp /tmp/dom4j-1.5.jar /opt/zimbra/lib/jars/
# cp /tmp/dom4j-1.5.jar /opt/zimbra/jetty-6.1.5/common/lib/

(les ponemos permisos y arrancamos Zimbra)
# chown zimbra:zimbra /opt/zimbra/lib/jars/dom4j-1.5.jar
# chown zimbra:zimbra /opt/zimbra/jetty-6.1.5/common/lib/dom4j-1.5.jar
# su - zimbra
# zmcontrol start

Más información:
- Una nueva herramienta desde los mandriles

dónde está cada cosa

8 de julio de 2009

Tanto si elegimos una distribución de Zimbra en Ubuntu/Debian como en RedHat/Fedora, encontraremos dentro de la instalación una carpeta llamada /packages. En esta carpeta están todos los archivos necesarios para la instalación de Zimbra en formato binario .deb si bajamos un Ubuntu o .rpm si bajamos una RedHat. Es curioso como como por cada versión va y va creciendo el tamaño de estos paquetes.
¿Alguien ha mirado que hay dentro de cada paquete? ¿qué archivos instala cada paquete?

Esto es un resumen de lo que hay dentro de cada uno de los paquetes .rpm para una versión 5.0.16.

+ zimbra-apache...rpm: Solo encontramos los archivos de Apache HTTP 2.2.8 y sus archivos de configuración.

+ zimbra-core...rpm: Este es el paquete que más cosas instala. Instala los script bashrc y profile del usuario Zimbra, la carpeta bin, conf, CURL 7.18.1, Cyrus-SASL 2.1.22, docs, Heimdal 1.2, el JDK 1.5, la carpeta libexec, OpenLdap Libs 2.3.43, Openssl 0.9.8, Sleepycat 4.2.52, Tcmalloc 0.97 y Zimbramon.

+ zimbra-ldap...rpm: OpenLDAP 2.3.43

+ zimbra-logger...rpm: Instala el logger con un MySQL 5.0.67

+ zimbra-mta...rpm: Amavis-new 2.5.4, ClamAv 0.94.1 y Postfix 2.4.7

+ zimbra-proxy...rpm: memcache 1.2.5 y nginx 0.5.30

+ zimbra-snmp...rpm: net-snmp 5.4.1

+ zimbra-spell...rpm: aspell 0.60.6

+ zimbra-store...rpm: Jetty 6.1.5, MySQL 5.0.67, la wiki y los zimlets.

Como cosa curiosa ver que MySQL se instala dos veces: una para el store y otra para el logger. Una cosa es que tengamos dos instancias del mismo software corriendo, pero ¿instalar dos veces todos los binarios de MySQL?.

este finde estoy disponible (ii de ii)

6 de julio de 2009

Para maximizar la disponibilidad (hacerla tender a 100%) hay que minimizar el riesgo. Hay que tener bien claro cuales pueden ser los posibles fallos de mi sistema, cual es la probabilidad que esos fallos se produzcan y cuales son los impactos en mi sistema de cada uno de esos fallo.
El problema es la aparición de la palabra "probabilidad". ¿Como puedo formular una probabilidad de algo que aun no ha pasado?.

Esto es un pequeño ejemplo de un "calculo de riesgo (relativo)" en un servicio de correo electrónico. Naturalmente es solo una base, ya que dentro de un calculo de riesgo existen varios métodos predictivos e infinidad de variables de riesgo.

Supongamos que tenemos un sistema de correo en el cual, después de un estudio hemos llegado a la conclusión de que solo existen dos posibles fallos de riesgo (naturalmente son muchos más).
Una rotura de disco SCSI que hemos llegado a la conclusión de que es poco probable y por tanto tiene una probabilidad de 0,2. Otro posible fallo es la caída de la linea de Internet que esto es más frecuente con una probabilidad de 0,8.
Por otro lado hemos llegado a la conclusión que la rotura de disco tiene un impacto catastrófico ya que no tenemos RAID. Por tanto el impacto en una escala de 10 sería un 9. Para el caso de la caída de Internet, tenemos un impacto de 2 ya que tenemos una linea de Internet redundante y con un simple cambio volvemos a tener conexión.

                   Prob.    Impac.
rotura disco       0,2      9
caida de internet  0,8      2
Si realizamos este cálculo:
0,2 * 9 = 1,9 riesgo
0,8 * 2 = 1,6 riesgo
Viendo los resultados vemos que la rotura de disco me supone un mayor riesgo y por tanto debería reducir al máximo mi riesgo.
La probabilidad de que se produzca un fallo es de 0,2. Esta probabilidad es imposible cambiarla ya que es inherente al propio hardware, en este caso un disco SCSI. Lo que si puedo minimizar es el impacto si en vez de utilizar un disco SCSI, utilizo dos discos SCSI en RAID y por otro lado realizo copias de seguridad diarias. Si implantamos todo esto vemos que el impacto de la rotura de un disco pasa de 9 a 4. Si volvemos hacer nuestro análisis de riesgo tenemos que ahora (0,2*4=0,8) la caída de la linea de Internet tiene un riesgo mayor.

este finde estoy disponible (i de ii)

4 de julio de 2009

Uno de los parámetros que se pueden medir matemáticamente a la hora de montar nuestro servicio IT es la disponibilidad, la fiabilidad y la mantenibilidad. Todos ellos están relacionados con el tiempo de funcionamiento de nuestro servicio. Es decir, contra menos tiempo parado pase nuestro servicio, más disponible, más fiable y menos mantenible es.
Debemos distinguir entre el tiempo de parada debido a una incidencia (por ejemplo, una caída de Internet, un disco roto, una excepción de programación no controlada, etc) y el tiempo de parada debido a un mantenimiento (actualización mensual del software, un reboot programado, etc). Todo el tiempo de mantenimiento programado no debe contabilizarse desde de la disponibilidad, fiabilidad o mantenibilidad, ya que lo que queremos calcular es el tiempo de paradas no previstas y que por tanto, pueden afectar a la calidad del servicio por lo cual el cliente está pagando.

Una parada programada no afecta a la calidad del servicio ya que el cliente en su contrato ya sabe de la existencia de tantas paradas programadas al mes (por ejemplo el servicio de correo puede sufrir 1 una parada programada al mes de no más de 5 minutos).

Como hemos dicho tenemos tres valores para calcular:

+ Disponibilidad o availability: porcentaje de tiempo activo frente a tiempo inactivo.

+ Fialibilidad o reliability: lapso de tiempo entre fallos de servicio o componentes. Este valor nos lo da el MTBS (Mean Time Between Failures o Tiempo medio entre fallos).

+ Mantenibilidad o maintainability: lapso de tiempo para reparar el servicio o componente. Este valor nos lo da el MTRS (Mean Time to Restore Service o Tiempo medio de restauración del servicio).

Supongamos que tenemos un servicio de correo electrónico con un servidor Zimbra y que durante un año estos han sido los downtimes del servicio:

05/03/2008 -> 1h de caída del servicio
16/06/2008 -> 2h de caída del servicio
01/08/2008 -> 0,5h de caída del servicio
23/11/2008 -> 8h de caída del servicio
24/11/2008 -> 2h de caída del servicio

5 paradas de 13,5 horas de caída del servicio
Horas de un año: 365 dias * 24h = 8760h

Calculamos pues la disponibilidad, la fiabilidad y la mantenibilidad:

D = ( (8760-13,5)/8760 ) * 100% =  99,8% (disponibilidad)
MTBF = (8760-13,5)/5 =  1749h entre cada fallo (tiempo medio entre fallo)
MTRS = 13,5/5 = 2,7h de reparación (tiempo medio reparación)
Ahora la pregunta es: ¿esto es malo?, ¿el cliente podría quejarse?, ¿podría cancelar el servicio de correo electrónico?. La respuesta es depende. Depende lo que hayamos firmado. Es decir, dentro del contrato existen lo que se llaman las SLA (Service Level Agreement o Acuerdos del nivel del servicio). Si en la SLA firmada por el cliente dice que la disponibilidad del servicio no será menor de 99,0% pues el cliente no tiene base para poder realizar una queja ya que estamos en el nivel establecido.

file descriptors (ii de ii)

3 de julio de 2009

Hasta ahora no hemos hablado para nada de la salida estandard STDERR. Este tipo de salida es utilizada por los procesos para mostrar los errores o para trabajos de diagnóstico. Como mencioné en el primer post la STDIN y la STDERR se muestran por el terminal. La información "buena" del proceso y la información de error se entremezclan.

Supongamos que tenemos un proceso el cual es susceptible de producir errores. Supongamos también que se lanza cada día en un cron de la siguiente forma:

# miproceso > /var/log/miproceso.log

Aparentemente, el proceso cada día se ejecutará y almacena su resultado dentro de /var/log/miproceso.log. No es correcto del todo. Dentro del miproceso.log solo encontraremos el resultado de la STDOUT de miproceso, pero no los errores que se hayan producido. Es decir, el resultado legitimo del programa lo hemos redireccionado a un fichero, pero los errores se siguen mostrando por el terminal. Para solucionar esto, tenemos que redidireccionar la STDOUT y la STDERR con la siguiente sintaxis:
# miproceso > /var/log/miproceso.log 2>&1

Le estamos diciendo que la STDERR (o file descriptor 2) se redireccione al mismo sitio donde esta redireccionado la STDOUT (o file descriptor 1).

También es posible redireccionar cada salida a un archivo diferente. Es decir que los resultados vayan a un log y los errores a otro log:
# miproceso 1> /var/log/resultado.log
# miproceso 2> /var/log/errores.log

Veamos un ejemplo real de la existencia y del funcionamiento de STDERR. Supongamos que tenemos un archivo llamado "pepe.txt" que no existe. Si intentamos ver su contenido se producirá un mensaje de error. Este mensaje de error, aunque haya gente que cree lo contrario, lo vemos por pantalla pero no viene de la STDOUT. Viene de la STDERR. Redireccionemos los errores del comando cat a un fichero de log.
# cat pepe.txt
cat: pepe.txt: No existe el fichero ó directorio
# cat pepe.txt 2>error.log
# cat error.log
cat: pepe.txt: No existe el fichero ó directorio

Otro ejemplo muy utilizado de los redirectores es utilizarlo junto con el dispositivo null. El dispositivo /dev/null es un dispositivo que todo lo que enviemos se perderá en el infinito. Pensémoslo como un dispositivo papelera. Se utiliza mucho cuando queremos ejecutar un proceso y no queremos almacenar nada de su resultado. Es decir, no queremos que muestre nada por el terminal:
# miproceso > /dev/null 2>&1

Tanto la STDOUT como la STDERR las envio a la papelera.

Un comando muy utilizado junto con las pipe es el comando de Linux tee. Si utilizamos un redirector hacia un archivo, el problema que tenemos es que ya no veremos nada por el terminal. Si lo que queremos es redireccionar y al mismo tiempo ver por el terminal debemos utilizar un tee:
# cat /etc/passwd | grep root | tee resultado.txt | less
root:x:0:0:root:/root:/bin/bash
# cat resultado.txt 
root:x:0:0:root:/root:/bin/bash

El comando tee recibe por su STDIN unos datos que los almacena en resultado.txt y al mismo tiempo los manda por su STDOUT lo que posibilita que los veamos por el terminal.

No solo Linux/UNIX dispone de esta potencia en sus shells. Windows con la aparición de la Windows Power Shell también dispone de todas estas funciones.