mc990d en ubuntu 9.04

12 de mayo de 2009

El MC990D es el módem USB 3G que está dando telefónica a sus clientes. Te permite una velocidad máxima de bajada de 7,2Mbps y 2Mbps de subida. Lo llaman 3G Plus o técnicamente HSUPA. También incorpora una tarjeta micro-sd de 1Gb.

La mejor solución para "Linux-Modem Movistar" es utilizar el "escritorio movistar para Linux" que es un clónico del que se instala bajo Windows. Este escritorio movistar para Linux está bajo GPL pero aun no reconoce el modelo MC990D (la web dice que sí) y además no está soportado para Ubuntu 9x. Se puede bajar del Movil OpenForum.

Así que toca hacer funcionar el módem a mano.

Una vez conectado al puerto USB tiene que ser detectada por tú Ubuntu 9.04:

$ lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 1410:7001 Novatel Wireless 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0bda:0158 Realtek Semiconductor Corp. Mass Stroage Device

Una vez detectado el módem tenéis que cargar el modulo usbserial. En Ubuntu 9.04 este modulo no viene separado del Kernel, sino que ya viene compilado dentro, por tanto no tenemos que hacer un "modprobe usbserial vendor=XXXX product=YYYY". Lo que tenemos que hacer es arrancar el Kernel con los parámetros del usbserial. Para ello modificamos el /boot/grub/menu.lst y añadimos los paámetros a nuestro Kernel por defecto:
kernel  /boot/vmlinuz-2.6.28-11-generic root=UUID=0a31bb4b-cc96-47e5-b783-5b00957a141e 
   ro quiet splash usbserial.product=0x7001 usbserial.vendor=0x1410 

Una vez reiniciado ya podemos comenzar a configurar nuestra conexión Movistar 3G. Instalamos la utilidad wvdial que nos permite crear conexiones PPP (apt-get install wvdial).
Creamos el archivo /etc/wvdial.conf con el siguiente contenido:
[Dialer Defaults]
Dial Command = ATD
Stupid Mode = 1
Modem = /dev/ttyUSB0
Modem type = USB Modem

[Dialer pin]
Init1 = AT+CPIN=1234

[Dialer movistar]
ISDN = 0
Username = movistar
Password = movistar
Baud = 460800
Phone = *99***1#
Init2 = AT
Init3 = AT&F&D2&C1E0V1S0=0
Init4 = AT+IFC=2,2
Init5 = ATS0=0
Init6 = AT
Init7 = AT&F&D2&C1E0V1S0=0
Init8 = AT+IFC=2,2

Cambiar en "1234" dentro del "Dialer pin" por el PIN de vuestro SIM.

Ahora ya podemos arrancar el módem. Por defecto al conectar la llave se creará /dev/ttyUSB0. Por algún motivo que desconozco hasta que no haces un "extraer de forma segura" la unidad de disco que te crea al introducir el módem, no aparece el /dev/ttyUSB0.
Podéis verlo al consultar los mensajes del Kernel con el comando "dmesg".

Lo que haremos es un:
# eject /dev/sr0
# wvdial pin
# wvdial movistar

Tendréis que ver algo como:
# wvdial pin
--> WvDial: Internet dialer version 1.60
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: AT+CPIN=1234
AT+CPIN=1234
OK
--> Modem initialized.
--> Configuration does not specify a valid phone number.
--> Configuration does not specify a valid login name.
--> Configuration does not specify a valid password.

# wvdial movistar
--> WvDial: Internet dialer version 1.60
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: AT
AT
OK
--> Sending: AT&F&D2&C1E0V1S0=0
AT&F&D2&C1E0V1S0=0
OK
--> Sending: AT+IFC=2,2
OK
--> Sending: ATS0=0
OK
--> Sending: AT
OK
--> Sending: AT&F&D2&C1E0V1S0=0
OK
--> Sending: AT+IFC=2,2
OK
--> Modem initialized.
--> Sending: ATD*99***1#
--> Waiting for carrier.
CONNECT HSDPA 7.2
--> Carrier detected.  Starting PPP immediately.
--> Starting pppd at Tue May 12 22:34:15 2009
--> Pid of pppd: 3591
--> Using interface ppp0
--> local  IP address 213.99.235.106
--> remote IP address 10.64.64.64
--> primary   DNS address 194.179.1.100
--> secondary DNS address 194.179.1.101

Se puede automatizar todo con un script "movistar.sh":
#!/bin/bash

echo "Si no tienes conectado el modem, conectalo ahora !!!..."
sleep 30

echo "Desmontando unidad del modem..."
ID=$(dmesg | grep "Attached scsi CD-ROM" | tail -1 | awk "{print \$8;}")
#echo $ID
eject /dev/$ID
sleep 10

echo "Marcando PIN..."
wvdial pin
sleep 30

echo "Llamando a Movistar..."
wvdial movistar

Como veréis después de cada comando hago un sleep para dejar tiempo por ejemplo para que el módem detecte la red a conectarse.

Si te gustan las ventanas y lo colores puedes crear el dialing utilizando gnome-ppp o kppp. Los dos internamente llaman a wvdial.

una rallita para tu iphone

10 de mayo de 2009


slow postfix

7 de mayo de 2009

Por defecto la configuración de Postfix estándar no debería dar cuellos de botellas ni retardos en los correo.
Aun así un gran tráfico de spam, una secuencia de correos grandes que no deberían estar en la cola, un hardware lento o una mala configuración de nuestra red puede provocarnos muchos problemas.

Si este es el caso, tendremos que repasar estos puntos:

DNS
Una mala configuración de Postfix puede afectar de forma negativa a la velocidad del correo. Durante la entrada y salida del correo el DNS es un servicio muy usado y por tanto mientras el DNS no produzca una respuesta el correo no saldrá ni entrará.
Conviene revisar nuestros DNS dentro de /etc/resvolv.conf y verificar la velocidad de estos.

[root@mta ~]# dig -tmx google.com

; <<>> DiG 9.3.4-P1 <<>> -tmx google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29611
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;google.com.                    IN      MX

;; ANSWER SECTION:
google.com.             10731   IN      MX      10 smtp1.google.com.
google.com.             10731   IN      MX      10 smtp2.google.com.
google.com.             10731   IN      MX      10 smtp3.google.com.
google.com.             10731   IN      MX      10 smtp4.google.com.

;; ADDITIONAL SECTION:
smtp1.google.com.       3531    IN      A       209.85.237.25
smtp2.google.com.       3531    IN      A       64.233.165.25
smtp3.google.com.       3531    IN      A       209.85.137.25
smtp4.google.com.       3531    IN      A       72.14.221.25

;; Query time: 78 msec
;; SERVER: 10.1.2.13#53(10.1.2.13)
;; WHEN: Tue May  5 22:46:28 2009
;; MSG SIZE  rcvd: 180

Una respuesta adecuada no tendría que sobrepasar los 100 o 150ms. Para segundas consultas sobre el dominio el tiempo tendría que ser de 0ms ya que la respuesta queda cacheada por un periodo de tiempo.

Si aun así persisten los retardos en el DNS seria aconsejable pensar de colocar servidor DNS local a nuestra red (o en el propio servidor) que permita cachear todas las peticiones de DNS.

También es aconsejable comprobar si estamos utilizando los DNS proporcionados por nuestro propio ISP u otros ajenos a ellos.

Cortafuegos y uso de red
Otro aspecto a verificar son los firewalls, tanto de la propia maquina de correo como los que puedan haber durante salida hacia Internet. Debemos tener el máximo caudal posible hacia afuera para asegurarnos que los correos permanecen el mínimo de tiempo en la cola de salida.

Podrías hacer alguna vez un test de velocidad (http://www.adsl4ever.com/test/) y comprobar la velocidad de upload de tú servidor.

Open relay
Un open relay es una configuración especial de un MTA por la cual cualquiera que se conecte podrá utilizar nuestro servidor para enviar correo. Esta opción debería estar restringida solo para las maquinas de nuestra red. De lo contrario podría ser utilizada para el envió masivo de spam. Con el tiempo esto provocaría que fuéramos a parar a una lista de negra como Spamhaus, Sorbs, etc.

Para ello revisa el parametro "mynetworks" de Postfix (http://www.postfix.org/postconf.5.html#mynetworks).

# postconf | grep mynetworks
mynetworks = 127.0.0.0/8 192.168.2.0/24 10.5.0.0/16 10.6.0.0/16

En este caso solo las redes 192.168.2.0, 10.5.0.0 y 10.6.0.0 tienes derecho a enviar correo por este MTA.

Tambien puede revisar el parámetro "relay_domains":

myhostname = mxta.domain.com
mydomain = domain.com
mydestination = $myhostname, $mydomain
relay_domains = $mydestination
mynetworks = 127.0.0.0/8 192.168.1.0/24


Listas negras
Otra manera de reducir drásticamente el correo que entra (posible spam), el correo que rebota y tambien el correo que sale, es utilizar listas negras para filtrar el correo. Esto consiste en utilizar bases de datos de IPs de maquinas consideradas spammers.

Para configurar la utilizacion de listas negras se utiliza "smtpd_recipient_restrictions" y "reject_rbl_client".
En este caso utilizados tres bases de datos que contienen listas negras (Spamhaus, Sorbs y Spamcop).

Esto es una ejemplo de cómo utilizar el parámetro de configuración de Postfix dentro de main.cf:

smtpd_recipient_restrictions =
 reject_non_fqdn_recipient,
 permit_sasl_authenticated,
 permit_mynetworks,
 reject_unauth_destination,
 reject_unlisted_recipient,
 reject_invalid_hostname,  
 reject_non_fqdn_sender,
 reject_unknown_sender_domain,
 reject_rbl_client sbl-xbl.spamhaus.org,
 reject_rbl_client dnsbl.sorbs.net,
 reject_rbl_client bl.spamcop.net,
 permit


Teniendo en cuenta que actualmente el 80% del correo de Internet es spam, esto puede evitar la entrada de mucho correo en la cola. Yo, para unos 100 usuarios bloqueo unos 15.000 correos al día.

Otra buena opción es utilizar tambien un "reject_unknown_sender_domain" que rechaza el correo si el dominio del remitente no existe.

Cola deferred
En esta cola van a parar los mensajes que no se han podido enviar a alguno de los destinatarios y por tanto Postfix tiene que volver a reintentar el envío. Tanto las colas de incoming y deferred se miran periódicamente para ver si hay algún mensaje para enviar. Hay tres parámetros básicos en Postfix para controlar cada cuanto se miran estas colas y que afectan al rendimiento de postfix:
queue_run_delay, minimal_backoff_time y maximal_backoff_time.

El funcionamiento es el siguiente: cuando un mensaje llega este es procesado por el mta y enviado a la cola incoming. Por otro lado cuando se decide enviar un mensaje y Postfix se tiene que poner en contacto con otros mta, estos mensajes son enviados a la cola active. Si por cualquier motivo el mensaje no puede ser enviado a otro mta este pasará a la cola deferred hasta que pueda ser entregado más tarde o expire el tiempo de vida. El tiempo de vida de un mensaje en la cola deferred viene marcado por la variable $maximal_queue_lifetime. Si transcurrido este tiempo el mensaje no se pudo enviar este mensaje se devuelve al remitente pero solo en un tamaño concreto marcado por la variable bounce_size_limit. Si el remitente ha enviado un mail del 50Mb no tiene sentido devolverle otra vez el mail de 50Mb.

El escaneo de la cola de deferred para los reintentos sigue un algoritmo un poco complicado pero que básicamente es algo así: la cola deferred se escanea cada $queue_run_delay en busca de mensajes para enviar. Cuando un mensaje está en esta cola se le pone una marca de tiempo T. Si a los T segundos se hace el envío y este no tiene éxito, el siguiente envío se hace a los 2T y así sucesivamente.

Si quieres vaciar la cola de deferred más rápidamente, puedes modificar $maxima_queue_lifetime, que por defecto son 5 dias, para que los correos no permanezcan mucho tiempo en la cola.

Qshape
Una utilidad para controlar el estado de tú cola es qshape. Qshape te muestra la vejez de un correo dentro de la cola.

Si quieres saber más sobre qshape leete esto.
http://amperis.blogspot.com/2009/02/controlando-la-cola-con-qshape-parte-1.html< http://amperis.blogspot.com/2009/02/controlando-la-cola-con-qshape-parte-2.html

Denegando archivos
El denegar cierto tipo de archivos se puede considerar una manera de reducir ancho de banda para nuestro servidor y también tiempo de procesado de CPU en el caso que el correo se filtrara por un antivirus.

Es costumbre en los MTA finales restringir cierto tipo de archivos como: .exe, .pif, .reg, etc.
No estaría mal tampoco restringir archivos como mpge, mp3, avi, etc, siempre que podamos.
Hace como restringí los archivos wav de audio y no nos dimos cuenta de que la centralita telefónica necesitaba enviar mails con estos adjuntos para los mensajes de voz de los empleados.

Para denegar ciertas extensiones en un Postfix hay que utilizar el parámetro "$mime_header_checks". Aquí tines un ejemplo de como implementarlo: http://www.cyberciti.biz/tips/postfix-block-mime-attachment-files.html Para finalizar
Lo recomendable siempre es hecharle un vistazo a la documentacion de tuning del producto. Aquí está la documentacion ofical sobre tuning para Postfix: http://www.postfix.org/TUNING_README.html

¿sabes de algo más para repasar?

rastrear un log en tiempo real

28 de abril de 2009

Buscar dentro de un log de correo puede resultar una tarea bastante complicada si buscamos un mail muy concreto y no para de entrar y salir correo. Una manera de filtrar un log de correo es hacerlo en tiempo real y filtrando por la dirección de correo que estamos buscando. Para ello utilizamos dos comando básicos de Linux. Por un lado el comando "tail" que te permite, por defecto, ver las 10 ultimas lineas de un fichero. Por otro lado el comando "grep" que te permite filtrar.

Podemos utilizar estos comandos por ejemplo para filtrar el archivo de log de Zimbra y comprobar como se comporta una dirección de correo al ser recibida por nuestro servidor. En este ejemplo, queremos ver que está pasando con los correos que vienen de "amperisblog[@]gmail.com".

# tail -f /var/log/zimbra.log | grep "amperisblog[@]gmail.com" --color
El parámetro "-f" pone el tail en tiempo real y el comando "--color" nos colorea lo que estamos buscando.

Este es el resultado:



mysql machacado

20 de abril de 2009

Estoy un poco preocupado. Hoy se ha anunciado la compra de Sun por tarde Oracle, el de la bases de datos.
No solo ha comprado un entorno de arquitectura como Java, un montón de hardware en forma de servidores y un sistema operativo llamado Solaris que cada día tiene más agujeros que los calcetines de mi abuelo.

Estoy preocupado por MySql. No se si la gente lo sabe, pero resulta que fue comprada hace ya más de un año por Sun (en agosto del 2008), y ahora MySql es de Oracle. ¿Que puede pasar ahora?. Solo pueden pasar tres cosas: o el proyecto continua tal cual sin interferencia directa de Oracle, o Oracle inyecta más programadores aportando nuevo conocimiento al proyecto o finalmente queda desterrado al recuerdo de lo que pudo ser y no fue.

Que alegría me lleve el día que con el nuevo MySql 6 veríamos un nuevo engine llamado Falcon que decían que podría estar a la altura de Oracle. Sinceramente creo que el proyecto saldrá beneficiado con una nueva base de conocimiento y con el tiempo veremos un MySql con una cara nueva, manteniendo siempre una distribución libre.

Otro proyecto que corría por las manos de Sun era OpenOffice... a este si que le veo con más peligro. Hasta ahora el 80 o 90% de los programadores de OpenOffice estaban aportados por el propio Sun. Los otros que programaban líneas para OpenOffice era IBM, Google, RedHat, Novell... creo que IBM dejará de programar nada para OpenOffice después de que le quitaran el pastel. No veo a Oracle apostando nada nuevo por OpenOffice... creo que continuará pero cada vez irá a menos.

Oracle ha ganado más al comprar Sun que si hubiera sido IBM.

¿tendré que migrar a postgresql?... ¿tendremos que pagar las licencias de Office y quitarnos las piratas?.

¿soy un proxy?

14 de abril de 2009

Otra de las cosas extrañas (ver el caso del Dfind) que puedes encontrar dentro de cualquier log de un webserver, son peticiones web de urls que no existen dentro de tú servidor.

Peticiones como estas, encontradas en un log de Apache:

217.76.199.246 - - [08/Apr/2009:13:52:34 +0200] "GET http://www.cship.info/azenv.php HTTP/1.0" 404 207
87.118.124.104 - - [14/Apr/2009:23:06:41 +0200] "GET http://www.ip-adress.com/proxy_callback.php HTTP/1.0" 404 216
209.8.45.202 - - [14/Apr/2009:23:38:31 +0200] "POST http://www.trafflow.com/testpr/eng.php HTTP/1.0" 404 212
67.225.243.14 - - [15/Apr/2009:11:45:12 +0200] "GET http://www.secretipaddress.com/ip.php HTTP/1.1" 404 204
Se trata de peticiones (posiblemente de robots) que van en busca de direcciones IP que contengan algún tipo de proxy anónimo funcionando. El objetivo es que alguien pueda utilizar nuestra dirección para navegar anónimamente.. posiblemente lo consigan porque no hemos sido cuidadosos al montar nuestro server.

Mírate proxy4free si buscas proxys anónimos para utilizar en tus fechorias.

En el anterior ejemplo alguien en la dirección IP 67.225.243.14 ha intentado solicitar a mi servidor la url http://www.secretipaddress.com/ip.php y yo como no la tengo o no tengo ningún servicio de Proxy le he devuelto un error 404.
Vamos a simular esta petición haciendo un Telnet, o mejor aun, utilizando alguna tool de fetch. Yo utilizaré wfetch de Microsoft:



Como veis el servidor le contesta con un error 404 de “Request not found”.

Probamos ahora utilizando un Proxy anónimo. Por ejemplo 221.226.153.178:3128 que está en China:



Ahora sí que vemos cómo al solicitar una url a la IP 221.226.153.178, esta nos devuelve un resultado. El resultado de “ip.php” resulta ser la dirección IP del solicitante de la url. En este caso el solicitante no soy yo desde mi casa con la tool wfetch sino el Proxy anónimo que para eso es su función.

Si por cualquier motivo tú server está haciendo de Proxy y se te están colando para navegar de forma anónima (y pronto aparecerás en listas de proxys anónimos) o porque tienes un squid funcionando o porque tienes activada la opción de proxy en Apache. Muy posiblemente tengas en Apache activado el ProxyRequest.

Si ves peticiones de esta clase en tú log de Apache, no esta de más que te verifiques que no haces de Proxy. Aquí tienes una web donde puedes comprobar sí tú dirección IP hace de Proxy: http://www.ip-adress.com/Proxy_Checker/



Más información:
+ Montar un Proxy cache utilizando Apache
+ Fortificando un servidor Apache (¿el malo malote hablando de Apache?)

no more secrets

12 de abril de 2009

Una de las cosas que realmente me gustan es coleccionar fotos de CPDs. Quedé realmente impresionado cuando ví por primera vez el datacenter de Colt en Barcelona. Me acuerdo la primera vez que me dieron unos cubre zapatos como los que se ponen los médicos al entrar en el quirófano… Creía que estaban de cachondeo conmigo, pero realmente había que ponérselos para entrar.

Lo primero que ví fue a una mujer de la limpieza pasando el aspirador por debajo de de los racks. Resulta que todo el suelo es flotante de un par de metros. La mujer iba sacando baldosa por baldosa y se iba metiendo dentro para sacar el polvo. Creo que han pasado ya unos siete u ocho años de eso.

Realmente sabes como es un administrador dependiendo de lo limpio y ordenado que tenga su CPD.

Hace unas semanas Cnet publicó una entrevista desvelando como eran los datacenters de Google. Todo el mundo sabía que se los fabricaban ellos mismos y que utilizaban una especie de containers modulares en forma de rack.
Los videos y las fotografías me parecieron espectaculares. Como ya sabíamos todos se fabrican ellos mismos los servidores:

Este es uno de los servidores de Google:





Como veis en la foto utilizan una placa Gigabyte modelo GA-9IVDP con 8Gb de RAM y dos procesadores (Intel o AMD, les es indiferente). Además utilizan dos discos SATA de marca Hitachi. De fuete de alimentación utilizan una de la marca Magnetick de la cual salen unos cables hacia una batería (no hay fuentes redundantes ni nada esos). Todo esta montado sobre una base de hojalata especialmente cortada para alojar todos estos componentes. No hay tapa, no hay ventiladores y todo está atado por unas tiras de velcro. ¿Cuánto tiempo tardarías en cambiar una fuente o un disco a este servidor? En cuanto a la placa base no intentes comprarla porque no está disponible. Posiblemente hayan llegado a un acuerdo y sean placas especialmente creadas y diseñadas para Google.

Todo el mundo compra servidores a Dell, HP, IBM o Sun, pero Google se los fabrica. Si a esto le sumamos que utilizan versiones con Linux especialmente compilados por ellos, les sale el servidor por cuatro duros.

Pero realmente lo sorprendente de este diseño es la inclusión de una batería de 12V en cada servidor. Según ellos es un problema de costes respecto a un SAI que alimente a todos los servidores. Este modelo ya está patentado y seguro que veremos pronto servidores de Dell o HP que incluyan un batería en su interior. La obsesión de Google por el ahorro energético y la optimización ya venía de lejos con sus creadores. Larry y Sergey ya preveían la cantidad inmensa de energía que necesitarían para alimentar todos los servidores en los siguiente años con la expansión del buscador.

Otro ejemplo. Su fuente de alimentación especialmente creada por la empresa Magneteck suministra 12V a la placa y no 12V+5V como las convencionales. Si os fijais en la pegatina de la fuente de alimentación tiene hasta su propio “Google Part Number”… fuentes especiales para Google.

Ben Jai es el ingeniero de Google que lleva diseñando estos servidores desde el 2005 y ya se encuentran en su séptima generación de diseño.

Bueno ya tenemos el servidor, ahora hay que enrracarlo.

Google no pone servidores en su datacenter, sino que pone contenedores llenos de 1.160 servidores dentro. No es la única empresa que utiliza contenedores con servidores dentro, ya lo hace Sun o Rackable Systems con su IceCube Modular datacenter, pero sí fue el primero.

Utilizan un contenedor (como los de los barcos) de tamaño 1AAA y lo equipan con su puerta de entrada, su salida de emergencia, su sistema de refrigeración y todas las estanterías para meter todos los servidores como el que hemos visto. Una vez tienen un container montado es muy fácil llevarse todos estos de una lado a otro del planeta y montar un datacenter de Google en cualquier sitio.



Aquí tenéis los tres videos que hizo Google en su conferencia de 6 horas para presentar el modelo y diseño de sus datacenters:







¿Veremos en un futuro a Google como proveedor de datacenters?

Si alguien se ha quedado impresionado como yo aquí tenéis un video de todo. Vale más una imagen que mil palabras:



Fotografías originales de Cnet.

service zimbra start

9 de abril de 2009

Al instalar Zimbra bajo un RedHat o CentOS este te creará un servicio llamado zimbra dentro de tú /etc/init.d que te permitirá arrancar de formá más sencilla con un “service zimbra stop” o un “service zimbra start” sin necesidad de entrar como usuario zimbra y luego hacer un zmcontrol.
El problema es que este servicio montado de esta forma no da información de nada (excepto mirando el log).


Para evitar este comportamiento editamos /etc/init.d/zimbra y cambiamos la línea 31. Esta línea contiene algo como:

su - zimbra -c "zmcontrol $1  </dev/null >> /opt/zimbra/log/startup.log 2>&1"

Lo cambiaremos simplemente por:
su - zimbra -c "zmcontrol $1"

Reiniciamos el servidor y vemos la diferencia:



Lo probamos tambien a pelo:



el mejor paseo por mi pueblo

3 de abril de 2009


Mar y Montaña en Street View from Buceante Johnston on Vimeo.

Enlace original

generar certificado zimbra con microsoft certification authority

2 de abril de 2009

Supongamos que en nuestra empresa tenemos instalado un Microsoft Certification Authority en local que nos proporciona todos los certificados que necesitamos. Por ejemplo para nuestros sitios web ASP de IIS.

Voy a utilizar esta autoridad de certificación para generarme un certificado para Zimbra. De esta forma como todas mis maquinas de Windows de la empresa tienen instalado dentro de sus "autoridades de certificación de confianza" el certificado raiz de mi autoridad, cuando entren en Zimbra por SSL no tendrán ningún problema.

He de suponer que ya tienes instalado el Microsoft Certification Authority en tú server y que sabes más o menos como funciona. Si no lo tienes instalado haz "Inicio->Configuración->Panel de control->Añadir o quitar programas->Añadir o quitar componentes de Windows". Selecciona servicios de certificación e instálalo. Créate una autoridad de certificación por ejemplo con el nombre "miempresa_CA".


Una vez instalado tienes que tener la consola accesible desde las Herramientas Administrativas de tú Windows Server.

Comenzamos:

+ Primero tenemos que decirle a Zimbra que queremos hacer una petición de certificado a una autoridad de certificación externa. Ya sea comercial como Verisign o local como en nuestro caso.

Necesitamos generar un CSR (Certification Signing Request). Nos vamos a la consola de admin y buscamos Configuracion->Certificados->Instalar certificado.

Seleccionamos nuestro nombre de servidor. Por ejemplo misrvzimbra.miempresa.com. Luego le decimos que genere la función CSR.


Luego rellenamos los datos que nos piden para generar el certificado. El campo más importante es el "Nombre común". Este debe coincidir con el nombre de URL que utilizarás para acceder a tú webmail. Es decir, tú servidor se llama misrvzimbra.miempresa.com, pero cuando accedas vía Web lo harás con webmail.miempresa.com. Si no colocas este nombre correctamente el IE te dirá que estas accediendo a un sitio peligroso porque el certificado no es correcto.


Para finalizar debes descargarte el fichero .csr. Este es el archivo que tendrías que enviar a la autoridad de certificación.

+ Una vez tengamos nuestro .csr nos vamos a nuestra CA. Para ello cargamos la pagina web de nuestra autoridad de certificación de Microsoft. Accedemos a http://miserverwindows/certsrv y nos aparece algo como:


Lo primero que haremos es descargamos el certificado raíz de la CA. Para ello vamos a "Download CA certificate...". Seleccionamos Base64 y descargamos el certificado con "Download CA certificate". Este es el certificado que tendríamos que instalar en todas nuestras maquinas dentro de "Autoridades de certificación de confianza".


+ Ahora ya podemos generar nuestro certificado Zimbra con la ayuda del .csr. Nos vamos otra vez a http://miserverwindows/certsrv y le decimos "Request a certificate->Advanced certificate request". Seleccionamos la opción "Submit a certificate request by using a base-64...".

Abrimos con el notepad el .csr anterior y pegamos dentro de la web su contenido. Además tendremos que decirle que lo que estamos pidiendo es un certificado para un servicio web.


Una vez enviada la petición nos generará nuestro certificado. Seleccionamos base-64 y le decimos "Download certificate".


+ Ya tenemos los dos certificados. El de la autoridad de certificación y el que hemos pedido para Zimbra. Ahora como paso excepcional para Zimbra tenemos que hacer una pequeña modificación dentro de los dos archivos .cer. Esta modificación consiste en abrirlos con el notepad y dejar una linea en blanco después del "-----END CERTIFICATE----- ". Esto es debido a un bug de Zimbra que no es capaz de detectar el final del archivo.

+ Estamos listo para cargar el certificado dentro de Zimbra. Volvemos a la consola de administración de Zimbra y le volvemos a decir "Instalar certificado".

Esta vez no volvemos a generar la función CSR otra vez sino que le diremos "Instalar certificado firmado comercialmente".

Para finalizar le diremos el path donde se encuentra nuestro nuevo certificado para Zimbra como el propio certificado de la autoridad de certificación.


Una vez instalado y sin ningún error ya podemos reiniciar Zimbra y comprobar como nuestro webmail se carga por SSL con el nuevo certificado.

Si hay algún otro problema para instalar los certificados comerciales lo mejor es hacerlo desde la linea de comandos como root:

# zmcertmgr deploycrt comm /tmp/certnew.cer  /tmp/certificado_empresaCA.cer

Más información:
+ Conceptos básicos sobre SSL
+ Zimbra-grupo
+ Commercial certificates in Zimbra