¿RAID 5 o RAID 10? He ahi la cuestion ....

En el trabajo estamos por instalar un nuevo storage, y surge la sana discusión de que forma utilizarlo mejor. Una de las discusiones fue que versión de RAID era más adecuada a nuestras necesidades. De los múltiples niveles de RAID disponibles nuestra discusión se centro en las ventajas y contras de RAID 5 y RAID 10. 

Para el que quiere repasar o conocer sobre los distintos niveles de RAID está el articulo de wikipedia que enlace más arriba. O este otro, de Linux Magazine.

En equipos de escritorio (o servidores de gama baja) es habitual contar con Motherboards que soportan RAID 0, 1 y ocasionalmente RAID 10. Con las capacidades de los discos actuales vale la pena considerar utilizar discos en RAID 1 o RAID 10, quizás comparar con la opción de discos de estado solido. Si no se cuenta con soporte por hardware de RAID, se puede utilizar software RAID, soportado por muchos sistemas operativos.

Este Paper dió inicio a nuestra discusion. Conversando con colegas y quienes nos vendieron el equipo entro tambien en consideraciones RAID 6. la ventaja frente a RAID 5 esta en la posibilidad de seguir funcionando con dos discos degradados. No es raro que falle un disco e inmediatamente fallen otros discos del array. Y tengo en vistas varias fallas durante la reconstrucción de un array.

Nuevamente la wikipedia nos aporta un muy buen cuadro comparativo de los niveles de RAID. Para los RAIDs anidados (RAID 50, RAID 01 o RAID 10) tenemos esta otra tabla.

No hay una única respuesta  depende mucho de la aplicación. En nuestro caso, una instalación pequeña, optamos por algo bien distinto a lo que originalmente habíamos pensado. Un array en RAID 6 con un POOL de RAID 5.

Actualizar Zonas Horaria de uruguay 2015

Muy sobre la fecha llega esta entrada, espero sea de utilidad 

El pasado 29 de Junio de 2015 se resolvió en consejo de ministros no realizar el cambio a horario de verano en Uruguay a partir de Octubre de 2015. Muchos sistemas informaticos que soportan el cambio automatico a horario de verano es necesario actualizar la configuracion (o reglas) para que no se haga el cambio. Las actualizaciones deben aplicarse antes del 4 de Octubre, la fecha en que deberia realizarse el cambio de horario.

En MacOS X, Linux y la mayoria de los UNIX el cambio consiste en actulizar un archivo donde estan las reglas para el país o zona horaria afectada. La IANA mantiene el archivo de timezones. En Windows cada zona horaria es una entrada en la registry. En dispositivos moviles y sistemas embebidos es necesario consultar al fabricante.

Windows

Las versiones 2008R2, 2012, 7, 8 y 8.1 tienen parches que actualizan las reglas para Uruguay. Más información: https://support.microsoft.com/en-us/kb/3077715. El parche para 2008R2 podría funcionar en algunas versiones de Windows Vista. En las versiones de Windows no contempladas en el parche, o cuando no es posible aplicarlo hay varias soluciones. Una posible es pasar el equipo a la zona horaria de Argentina. Otra solución es destildar la opción "Ajustar el reloj al horario de Verano", en la configuracion de zona horaria (ventana de configuracion de fecha y hora).Una alternativa más trabajosa es actualizar los archivos de la registry, como describí en una entrada previa del blog. Este articulo da alguna idea de como se podría editar la zona para aplicar los cambios.

Linux

Las distribuciones que están siendo mantenidas sacaron todas parches, es necesario asegurarse que estén aplicados. Los paquetes tiene nombres como timezone2015f o tzdata2015f. Para equipos corriendo distribuciones que no tienen actualizaciones (o no se quiera/pueda aplicarlas) se puede bajar el archivo de la IANA. El archivo debe ser tzdata2015f.tar.gz o mas nuevo. Buscar en el archivo SouthAmerica la informacion referente a Uruguay y compilarlo con zic(8). El archivo viejo reemplazarlo por el archivo compilado. Los archivos suelen estar /usr/share/lib/zoneinfo.

Para probar el cambio utilizamos zdump. Las ultimas lineas de ejecutar  zdump -v America/Montevideo deberian ser similares a esto:
      America/Montevideo  Sun Mar  8 03:59:59 2015 UTC = Sun Mar  8 01:59:59 2015 UYST isdst=1
      America/Montevideo  Sun Mar  8 04:00:00 2015 UTC = Sun Mar  8 01:00:00 2015 UYT isdst=0

Otros UNIXes

En AIX me sugieren cambiar a la zona horaria de Argentina/BuenosAires. Compilar el archivo de timezone funciona en los equipos que usan "Olson Timezone", hasta la versión 5.2 AIX utilizó formato POSIX. En algunos equipos con AIX 6.1 pude actualizar con éxito la zona horaria, compilando el archivo y sustituyendo el viejo por el compilado. Seguramente escriba algo especifico de AIX

En Solaris, *BSD o MacOS X se compila la timezone y se remplazan los archivos.No tengo acceso a equipos corriendo esos sistemas operativos para probarlo. Esta discusion tiene algunas ideas de como se podria actualizar en MacOS X.

Dispositivos Moviles y sistemas embebidos

En la mayoria de los dispositivos moviles dependemos del fabricante, si este no proporciona actualizaciones hay poco que podamos hacer. Como medida de mitagacion algunos celulares permiten optar si se quiere aplicar el cambio en la zona horaria afectada. He visto pocos dispositivos embebidos que manejen cambio de hora, hay que verlo caso a caso. Si el fabricante da actualizaciones o un mecanismo para actualizar, estamos de parabienes. En otro caso nos queda pasar a una zona horaria que no tenga horario de verano.

Conclusiones

Esta entrada del blog describe muy someramente las alternativas frente a este problema. Este articulo de El Observador es interesante en la argumentacion que da, contraria al horario de verano. De todas formas no hay nada concluyente a favor o en contra de esta practica.

Calcular Sumas MD5 en AIX

Necesito verificar un archivo descargado en un equipo con AIX. Esto se hace con sumas MD5, en Linux esto lo hacemos con MD5SUM. En AIX no tenemos esta herramienta, pero tenemos csum que sirve para calcular sumas MD5. Ejemplo

        root@aix # csum -h MD5 /etc/passwd
        092f62e68ce4ba03dfd3d1e7f0de9d3b  /etc/passwd

Para archivos de más de 2 GB hay que tener aplicado un parche.

Zimbra y TLS: Correos de GMAIL no aceptados

Este problema lo encontré meses atrás, hay poco escrito sobre esto. Me avisan que no estaban llegando los correos que nos enviaban desde GMAIL. En los logs del correo encontré entradas como estas: 

Feb 28 12:26:43 srv-correo postfix/smtpd[12137]: setting up TLS connection from mail-ig0-f170.google.com[209.85.213.170]
Feb 28 12:26:43 srv-correo postfix/smtpd[12137]: mail-ig0-f170.google.com[209.85.213.170]: TLS cipher list "aNULL:-aNULL:ALL:+RC4:@STRENGTH:!aNULL:!MD5:!DES"
Feb 28 12:26:43 srv-correo postfix/smtpd[12137]: SSL_accept:before/accept initialization
Feb 28 12:26:44 srv-correo postfix/smtpd[12137]: SSL_accept:SSLv3 read client hello A
Feb 28 12:26:44 srv-correo postfix/smtpd[12137]: SSL_accept:SSLv3 write server hello A
Feb 28 12:26:44 srv-correo postfix/smtpd[12137]: SSL_accept:SSLv3 write certificate A
Feb 28 12:26:44 srv-correo postfix/smtpd[12137]: SSL_accept:SSLv3 write key exchange A
Feb 28 12:26:44 srv-correo postfix/smtpd[12137]: SSL_accept:SSLv3 write server done A
Feb 28 12:26:44 srv-correo postfix/smtpd[12137]: SSL_accept:SSLv3 flush data
Feb 28 12:26:44 srv-correo postfix/smtpd[12137]: SSL3 alert read:fatal:protocol version
Feb 28 12:26:44 srv-correo postfix/smtpd[12137]: SSL_accept:failed in SSLv3 read client certificate A
Feb 28 12:26:44 srv-correo postfix/smtpd[12137]: SSL_accept error from mail-ig0-f170.google.com[209.85.213.170]: 0
Feb 28 12:26:44 srv-correo postfix/smtpd[12137]: warning: TLS library problem: 12137:error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version:s3_pkt.c:1256:SSL alert number 70:

En el foro de zimbra hispano encontré una sola mención al problema. Intervine allí, y comente como lo resolví. En realidad lo que tengo es un paliativo, como el usuario zimbra ejecuté:

      postconf -e smtpd_tls_mandatory_protocols='!SSLv2,!SSLv3,!TLSv1.2'
      postconf -e smtpd_tls_protocols='!SSLv2,!SSLv3,!TLSv1.2'

La solución la encontré por ensayo y error, a partir de una discusión en serverfault.com . Acá esta el hilo, que a su vez hace referencia a otro hilo en los foros de FreeBSD. No he vuelto a tener problemas, en un próximo upgrade de Zimbra voy a probar esto con la configuración por defecto.