calcular el tamaño de una instalación zimbra

31 de mayo de 2009

Este es un script para calcular el tamaño físico que debería tener tú instalación de Zimbra en función del numero de usuarios y del tamaño máximo de los buzones.
Naturalmente el resultado final es orientativo.


Más informacion:
+ Zimbrablog

estadísticas de un mailbox

29 de mayo de 2009

De la cantidad de script que hay dentro de /opt/zimbra/bin uno muy útil es el zmmailbox. Su utilización es muy parecida al zmprov. Este comando se utiliza para manejar los buzones. Lo podemos lanzar (al igual que zmprov) por línea de comandos o simplemente utilizar su consola.

[zimbra@zimbra ~]$ zmmailbox --help
zmmailbox [args] [cmd] [cmd-args ...]

  -h/--help                                display usage
  -f/--file                                use file as input stream
  -u/--url      http[s]://{host}[:{port}]  server hostname and optional port. must
                                           use admin port with -z/-a
  -a/--admin    {name}                     admin account name to auth as
  -z/--zadmin                              use zimbra admin name/password from
                                           localconfig for admin/password
  -y/--authtoken {authtoken}               use auth token string(has to be in JSON
                                           format) from command line
  -Y/--authtokenfile {authtoken file}      use auth token string(has to be in JSON
                                           format) from command line
  -m/--mailbox  {name}                     mailbox to open
  -p/--password {pass}                     password for admin account and/or mailbox
  -P/--passfile {file}                     read password from file
  -r/--protocol {proto|req-proto/response-proto} specify request/response protocol
                                                 [soap11,soap12,json]
  -v/--verbose                             verbose mode (dumps full exception stack 
                                           trace)
  -d/--debug                               debug mode (dumps SOAP messages)

 zmmailbox is used for mailbox management. Try:

     zmmailbox help admin           help on admin-related commands
     zmmailbox help account         help on account-related commands
     zmmailbox help appointment     help on appoint-related commands
     zmmailbox help commands        help on all commands
     zmmailbox help contact         help on contact-related commands
     zmmailbox help conversation    help on conversation-related commands
     zmmailbox help filter          help on filter-realted commnds
     zmmailbox help folder          help on folder-related commands
     zmmailbox help item            help on item-related commands
     zmmailbox help message         help on message-related commands
     zmmailbox help misc            help on misc commands
     zmmailbox help permission      help on permission commands
     zmmailbox help search          help on search-related commands
     zmmailbox help tag             help on tag-related commands

Este es un ejemplo de como obtener una estadística (tamaño, carpetas, correos leídos) de un buzón. En mi caso voy a sacar las estadísticas del buzón admin@dominio.com:
[zimbra@zimbra ~]$ zmmailbox
mbox> adminAuthenticate admin@dominio.com mipsw1234

mbox> selectMailbox admin@dominio.com
mailbox: admin@dominio.com, size: 7.01 MB, messages: 531, unread: 330

mbox admin@dominio.com> GetAllFolders
        Id  View      Unread   Msg Count  Path
----------  ----  ----------  ----------  ----------
         1  conv           0           0  /
        16  docu           0           0  /Briefcase
        10  appo           0           1  /Calendar
        14  mess           0           0  /Chats
         7  cont           0           0  /Contacts
         6  mess           0           0  /Drafts
        13  cont           0           1  /Emailed Contacts
         2  mess           0           6  /Inbox
      4818  mess           3           9  /Inbox/jupiter
      8509  mess           2          15  /Inbox/asterisk
      4817  mess           0           0  /Inbox
      5279  mess          91         111  /Inbox/antivirus
      6025  mess           0           1  /Inbox/backup
      5283  mess           1           1  /Inbox/mail report
      5280  mess           7          24  /Inbox/virus
      5281  mess           9          48  /Inbox/xtras
         4  mess          26          26  /Junk
        12  wiki           0           0  /Notebook
         5  mess           0           3  /Sent
        15  task           0           0  /Tasks
         3  conv         191         285  /Trash

También es posible sacar las estadísticas sin necesidad de entrar en la consola del comando:
zmmailbox -z -m user@domain.com gms -> Tamaño de un buzón
zmmailbox -z -m user@domain.com gaf -> Estadisticas de un buzón

Más información:
+ zmmailbox

bind para el correo (parte iii de iii)

26 de mayo de 2009

Por último vamos a securizar un poco nuestros dos servidores. Cuando un DNS quiere descargar la zona de otro servidor DNS, este realiza peticiones AXFR. Es decir si no tenemos correctamente configurado nuestro servidor de DNS es posible que alguien pueda descargarse nuestra base de datos de zona.

Aquí tenéis un ejemplo de un servidor DNS mal configurado que responde a las peticiones AXFR (actualmente el bug lo tienen arreglado):

amperis@akoya:~$ dig @ns2.microXXXX.net microXXXX.net axfr

; <<>> DiG 9.5.1-P2 <<>> @ns2.microXXXX.net microXXXX.net axfr
; (1 server found)
;; global options:  printcmd
microXXXX.net.          86400   IN      SOA     ns1.microXXXX.net. sysop.microXXXX.net.
2009051302 86400 7200 2419200 86400
microXXXX.net.          86400   IN      NS      ns1.microXXXX.net.
microXXXX.net.          86400   IN      NS      ns2.microXXXX.net.
microXXXX.net.          86400   IN      A       62.97.115.117
microXXXX.net.          3600    IN      MX      5 tauri.microXXXX.net.
microXXXX.net.          3600    IN      MX      10 dsl1.microXXXX.net.
microXXXX.net.          3600    IN      MX      20 mx.microXXXX.net.
abydos.microXXXX.net.   86400   IN      A       213.27.212.92
actuava.microXXXX.net.  86400   IN      CNAME   atlantis.microXXXX.net.
adminwww.microXXXX.net. 86400   IN      CNAME   asgar.microXXXX.net.
algerie.microXXXX.net.  86400   IN      CNAME   atlantis.microXXXX.net.
altas.microXXXX.net.    86400   IN      CNAME   asgar.microXXXX.net.
altes.microXXXX.net.    86400   IN      CNAME   asgar.microXXXX.net.
ambitogrupo.microXXXX.net. 86400 IN     CNAME   atlantis.microXXXX.net.
anubis.microXXXX.net.   86400   IN      CNAME   tauri.microXXXX.net.
arianconstruccion.microXXXX.net. 3600 IN CNAME  asgar.microXXXX.net.
asgar.microXXXX.net.    86400   IN      A       62.97.115.112
asuran.microXXXX.net.   86400   IN      A       213.27.212.32
atlantis.microXXXX.net. 86400   IN      A       213.27.212.72
baal.microXXXX.net.     86400   IN      A       62.97.115.62
... (la zona es mucho más larga)

Nota: el dominio real ha sido alterado por seguridad.

Si realizamos la misma consulta a nuestros servidores DNS obtenemos:

[root@dns2 var]# dig @192.168.1.8 amperisblog.com axfr

; <<>> DiG 9.3.4-P1 <<>> @192.168.1.8 amperisblog.com axfr
; (1 server found)
;; global options:  printcmd
amperisblog.com.        86400   IN      SOA     dns1.amperisblog.com. 
admindns.amperisblog.com. 20090522 21600 3600 604800 86400
amperisblog.com.        86400   IN      NS      dns1.amperisblog.com.
amperisblog.com.        86400   IN      NS      dns2.amperisblog.com.
amperisblog.com.        86400   IN      MX      10 mail1.amperisblog.com.
amperisblog.com.        86400   IN      MX      20 mail2.amperisblog.com.
amperisblog.com.        86400   IN      A       222.222.222.223
dns1.amperisblog.com.amperisblog.com. 86400 IN A 222.222.222.221
dns2.amperisblog.com.amperisblog.com. 86400 IN A 222.222.222.222
ftp.amperisblog.com.amperisblog.com. 86400 IN CNAME 
server1.amperisblog.com.amperisblog.com.
mail1.amperisblog.com.amperisblog.com. 86400 IN CNAME 
server1.amperisblog.com.amperisblog.com.
mail2.amperisblog.com.amperisblog.com. 86400 IN CNAME 
server2.amperisblog.com.amperisblog.com.
server1.amperisblog.com.amperisblog.com. 86400 IN A 222.222.222.224
server2.amperisblog.com.amperisblog.com. 86400 IN A 222.222.222.223
www.amperisblog.com.amperisblog.com. 86400 IN CNAME 
server2.amperisblog.com.amperisblog.com.
amperisblog.com.        86400   IN      SOA     dns1.amperisblog.com. 
admindns.amperisblog.com. 20090522 21600 3600 604800 86400
;; Query time: 10 msec
;; SERVER: 192.168.1.8#53(192.168.1.8)
;; WHEN: Sat May 23 18:01:22 2009
;; XFR size: 15 records (messages 1)

El objetivo es evitar que la transferencia de zona pueda realizarse desde Internet. Solo debe realizarse entre los dos servidores de DNS de confianzza.

Para ello en el servidor de DNS primario añadimos al named.conf la siguiente config:

options {
   allow-transfer { none; };
   ...
};


zone "amperisblog.com" in {
   allow-transfer { 192.168.1.9; };
   ...
};

Al DNS principal le decimos que solo puede transferir la zona al DNS secundario (192.168.1.9).

Por otro lado, el DNS secundario no tiene que transferir ninguna zona a nadie. Pondremos la siguiente config en el secundario:
options {
   allow-transfer { none; };
   ...
};


Para entornos en producción donde podemos tener muchos servidores de DNS existe la posibilidad de utilizar firmas para garantizar la autenticidad de una transferencia de zona. Aquí teneis un ejemplo de la utilización de firmas en Bind 9.

bind para el correo (parte ii de iii)

25 de mayo de 2009

Para el servidor de DNS secundario realizaremos los mismos pasos de instalación que con el DNS primario.
Una vez instalado todo el software de Bind editamos el /etc/named.conf con el siguiente contenido:

options {
   directory "/var/named/slaves";
};

logging{
  channel simple_log {
    file "/var/log/named.log" versions 3 size 5m;
    severity warnings;
    print-time yes;
    print-severity yes;
    print-category yes;
  };
  category default{
    simple_log;
  };
};

zone "amperisblog.com" in {
   type slave;
   file "amperisblog.com.zone";
   masters{ 192.168.1.8; };
};

Si reiniciamos Bind con un "sevice named restart" veremos como solo al arrancar se creará un archivo de backup de la zona en /var/named/slaves/amperisblog.com.zone.

Si observamos named.log del DNS secudario veremos como inicialmente la zona no existe y como se contacta con el servidor de DNS principal para descargar la zona:

23-May-2009 17:14:37.957 general: debug 1: zone amperisblog.com/IN: no database 
exists yet, requesting AXFR of initial version from 192.168.1.8#53
23-May-2009 17:14:37.960 xfer-in: info: transfer of 'amperisblog.com/IN' from 
192.168.1.8#53: connected using 192.168.1.9#58874
23-May-2009 17:14:37.964 general: debug 1: zone amperisblog.com/IN: zone transfer 
finished: success

Las direcciones 192.168.1.9 y 192.168.1.8 son las direcciones IP internas de los servidores de DNS que se encuentran dentro de la DMZ. Las direcciones 222.222.222.221 y 222.222.222.222 son las direcciones IP públicas de los servidores de DNS desde Internet.

bind para el correo (parte i de iii)

24 de mayo de 2009

Como todos sabéis el DNS es uno de los principales servicios que sustentan Internet y, por tanto, es fundamental para la distribución del correo (y otras cosas)... Quien no sepa como funciona el DNS que se vaya leyendo la Wikipedia.

El objetivo de estos tres post son:

+ Configuración de dos maquinas Linux (master+slave) servidoras de DNS por Bind.
+ Configuración de varias zonas de DNS en especial para su uso con el correo.
+ Replicación de zona de un servidor a otro (mensajes AXFR).
La distribución que utilizaré para los dos servidores será CentOS 5.2. Antes de empezar a instalar Bind necesitaremos las dos maquinas perfectamente configuradas (TCP/IP), parcheadas y conectadas a Internet.

Instalamos el soft necesario:

# yum search bind | grep ^bind
# yum install bind.i386

Como resultado tendremos instalado bind, bind-libs y bind utils.

Configuraremos el firewal de iptables para que cualquiera pueda realizar consultas DNS sobre esta maquina. Para ello abrimos el puerto 53/UDP.

Editamos /etc/sysconfig/iptables:

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT 

Reiniciamos iptables:

# service iptables restart

Intentamos iniciar Bind, pero debería fallar ya que aun no lo tenemos correctamente configurado:

# service named restart

Empezamos primero configurando el DNS principal y cuando este todo correcto montaremos el secundario.
El archivo de configuración de Bind se encuentra dentro de /etc/named.conf. Lo crearemos y colocaremos el siguiente contenido:

options {
   directory "/var/named/data";
};


zone "amperisblog.com" in {
   type master;
   file "amperisblog.com.zone";
   allow-update { none; };
};

zone "." {
   type hint;
   file "root.cache";
};

Nota: He creado una zona llamada "." que apunta a un fichero de configuración llamado "root.cache". Esto nos sirve por si queremos que nuestro DNS sepa resolver otros dominios. Es decir, que nuestro servidor de DNS haga a la vez de cache de DNS. Para ello hay que crear /var/named/data/root.cache y pegar el contenido de: http://www.tux.org/~mayer/linux/book/node155.html

El parámetro "directory" nos está diciendo dónde se encontrarán los archivos de configuración de nuestro dominio. En mi caso tenemos un archivo de configuración para mi dominio amperisblog.com que se encontrará dentro de /var/named/data/amperisblog.com.zone.
El parámetro "type" nos indica si ese dominio será master o slave. Para un DNS principal este campo será master.

Creamos ahora el archivo de configuración para la zona ampeisblog.com. En ella se encontraran todos los campos A, CNAME, MX, NS, etc. Creamos el archivo /var/named/data/amperisblog.com.zone con el siguiente contenido:

$TTL 86400
amperisblog.com.  IN     SOA    dns1.amperisblog.com.     admindns.amperisblog.com. (
                    20090522   ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day

      IN     NS     dns1.amperisblog.com.
      IN     NS     dns2.amperisblog.com.

      IN     MX     10     mail1.amperisblog.com.
      IN     MX     20     mail2.amperisblog.com.

             IN     A       222.222.222.223

server1      IN     A       222.222.222.224
server2      IN     A       222.222.222.223
dns1         IN     A       222.222.222.221
dns2         IN     A       222.222.222.222

ftp          IN     CNAME   server1
mail1        IN     CNAME   server1
mail2        IN     CNAME   server2
www          IN     CNAME   server2

Vamos a explicar la configuración de este archivo de zona. Lo primero que se especifica es el registro de SOA, donde aparece el nombre de nuestro dominio, el DNS primario (dns1.amperisblog) y la dirección de correo del administrador del DNS (admindns.amperisblog.com).

Otros datos que encontramos dentro de SOA son los tiempos de cacheo y refresco:

20090522: es un número de serie autoincremental que deberíamos incrementar cada vez que hagamos una modificación en la zona.
21600: indica al DNS esclavo cada cuando tiempo tiene que chequear la configuración del DNS maestro. En nuestro caso no tiene sentido porque este servidor es primario.
3600: si el refresco del esclavo falla, esto indica cada cuanto tiempo tiene que probar.
604800: si el refresco del esclavo sigue fallando, esto indica cuando el DNS esclavo debe dejar de funcionar.
86500: indica a un cache de DNS el tiempo de vida de la traducción DNS.
NS: indica los nombres de los dos servidores de DNS de nuestra zona.
MX: indica con peso 10 y peso 20 cuales son los servidores de correo que deben responder al dominio amperisblog.com.
A: indica las direcciones IP de todas las maquinas publicas en Internet. En este caso tenemos dos servidores de DNS (dns1, dns2) y dos servidores (server1, server2).
CNAME: indica los alias. Tenemos dos alias de mailX que apuntan a nuestros server1 y server2. Tenemos un alias de www para alojamiento Web que apunta a server2 y por ultimo tenemos un alias de ftp que apunta al server1.

Si todo ha ido bien ya podemos arrancar otra vez el DNS con un "service named restart" y comprobar el archivo de log para ver si todo a ido bien:

# cat /var/log/messages | grep named
May 23 15:33:29 dns1 named[13573]: starting BIND 9.3.4-P1 -u named
May 23 15:33:29 dns1 named[13573]: found 1 CPU, using 1 worker thread
May 23 15:33:29 dns1 named[13573]: loading configuration from '/etc/named.conf'
May 23 15:33:29 dns1 named[13573]: listening on IPv4 interface lo, 127.0.0.1#53
May 23 15:33:29 dns1 named[13573]: listening on IPv4 interface eth0, 192.168.1.8#53
May 23 15:33:29 dns1 named[13573]: command channel listening on 127.0.0.1#953
May 23 15:33:29 dns1 named[13573]: command channel listening on ::1#953
May 23 15:33:29 dns1 named[13573]: zone amperisblog.com/IN: loaded serial 20090522
May 23 15:33:29 dns1 named[13573]: running
May 23 15:33:29 dns1 named[13573]: zone amperisblog.com/IN: sending notifies (serial
20090522)

Ahora ya podemos realizar peticiones de consultas sobre nuestro nuevo servidor de DNS:

[root@dns1 data]# dig @localhost amperisblog.com

; <<>> DiG 9.3.4-P1 <<>> @localhost amperisblog.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14375
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;amperisblog.com.               IN      A

;; ANSWER SECTION:
amperisblog.com.        86400   IN      A       222.222.222.223

;; AUTHORITY SECTION:
amperisblog.com.        86400   IN      NS      dns1.amperisblog.com.
amperisblog.com.        86400   IN      NS      dns2.amperisblog.com.

;; Query time: 12 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat May 23 15:

Veamos también si es capaz de cachear/traducir otros dominios:

[root@dns1 data]# dig @localhost google.com

; <<>> DiG 9.3.4-P1 <<>> @localhost google.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38954
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

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

;; ANSWER SECTION:
google.com.             300     IN      A       74.125.45.100
google.com.             300     IN      A       74.125.67.100
google.com.             300     IN      A       209.85.171.100

;; AUTHORITY SECTION:
google.com.             345600  IN      NS      ns1.google.com.
google.com.             345600  IN      NS      ns2.google.com.
google.com.             345600  IN      NS      ns3.google.com.
google.com.             345600  IN      NS      ns4.google.com.

;; Query time: 699 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat May 23 15:38:55 2009
;; MSG SIZE  rcvd: 148

Si queremos controlar las peticiones podemos añadir un log dentro del /etc/named.conf:

logging{
  channel simple_log {
    file "/var/log/named.log" versions 3 size 5m;
    severity warning;
    print-time yes;
    print-severity yes;
    print-category yes;
  };
  category default{
    simple_log;
  };
};

Si estamos debugeando nuestro DNS cambiaremos "severity warning;" por un "severity debug;".

¿qué pasa cuando google street no llega?

23 de mayo de 2009



tamaño de los buzones en tiempo real

21 de mayo de 2009

Por defecto Zimbra almacena los mensajes recibidos dentro de /opt/zimbra/store. En algunas ocasiones como en pruebas de stress podéis utilizar esta linea de bash para ver como va creciendo y disminuyendo todo el correo que tenemos en los buzones. Irá creciendo mientras vayamos recibiendo correo por SMTP e irá disminuyendo conforme los usuarios accedan al correo vía POP o borren correo vía IMAP/Webmail.

# while [ true ]; do clear; du -bcs /opt/zimbra/store/ | grep total; sleep 5;  done


tagged address con tmda

17 de mayo de 2009

Cada día son más las técnicas que aparecen para saltarse los filtros antispam, pero afortunadamente también son más las técnicas que intentan evitarlo. TMDA son las siglas de "agente de entrega de mensajes por etiquetado". Se trata de un software libre que implementa varias técnicas antispam para QMail, Sendmail, Exim o Postfix.
Utiliza tres técnicas conocidas, más una nueva técnica desarrolladas por ellos y llamada "etiquetado de direcciones".

Las tres primeras técnicas las describiré rápidamente y me centraré en la última que es la más interesante:

+ listas negras: son listas de direcciones de correo, dominios o rangos de IPs de las cuales está totalmente prohibido recibir un correo. Cuando el MTA recibe un correo de un remitente que se encuentra en esta lista, el correo es eliminado.

+ listas blancas: son listas de direcciones de correo, dominio o rangos de IPs de las cuales se acepta el correo sin aplicar ningún otro tipo de filtrado. Cuando un MTA recibe un correo de un remitente que se encuentra en esta lista, este es aceptado inmediatamente sin realizar ningún otro filtrado.

+ lista gris (greylist) o de safio/respuesta: Consiste en denegar un mensaje a nivel SMTP, de forma que forzamos al MTA del remitente a que reenvíe el correo otra vez al cabo de un tiempo (minutos, horas, depende de la configuración del MTA del remitente). Si el otro MTA reenvía el correo, nuestro MTA lo acepta y mete al remitente es su lista blanca para que la segunda vez que envíe un correo no vuelva a repetir este proceso.
Es interesante observa que cuando utilizamos greylist el correo es rechazado la primera vez y vuelto a reintentar porque muchos spammers no implementan el reenvío. Los spammers envían miles de correos y no les importa si el correo se ha entregado o no.

La otra técnica interesante de TMDA es el "etiquetado de direcciones". Con esto podemos hacer:

+ etiquetado de la dirección from: con esto es posible reescribir todas las veces que quiera su dirección de correo "por un alias" y que esta dirección tenga un tiempo de vida finito. De esta forma, por ejemplo, podrás participar en una lista de distribución, grupo o mailing sin que tú dirección real sea comprometida por spmmers.
Por ejemplo si tú dirección real es alejandro-moreno@miempresa.com tú dirección "etiquetada" con un tiempo de vida de 5 días tendrá este aspecto:

alejandro-fecha-989108708.a17f80@miempresa.com

Notar que se utilizan técnicas de crifrado para generar esta dirección de correo y por tanto no es posible que un spammer genere una dirección "etiquetada" valida. Una vez expirada la dirección de correo, los mensajes enviados a esta dirección son rechazados.

+ etiquetado de direcciones del remitente: al igual que la dirección del "from" también es posible etiquetar la dirección del remitente con la misma técnica anterior.
Esto puede servir para que cuando un remitente esté suscrito a una foro, grupo o mailing su dirección no sea comprometida por un spammer. Solo podrá recibir correo a esta dirección "etiquetada" si proviene del dominio de foro o lista de distribución.
Los spammers utilizan el campo "Return-path" para determinar cual es la dirección real del remitente de la lista de distribución. Si cambiamos la dirección del "Return-path" por una dirección etiquetada (alejandro-sender-a751af@midominio.com) podremos decirle que solo acepte correo de lista@distribucion.com.

+ etiqueta de direcciones con palabras clave: también es posible etiquetar un dirección con una palabra clave o key. Algo como:

alejandro-palabra clave-.8w06e8@miempresa.com

Este tipo de etiquetado puede se útil para una cierta relación emisor-receptor como por ejemplo crear una cuenta ebay.com, suscribirse a un feed, etc.

Como véis todas estas opciones permiten crear tantos "alias" de nuestra dirección de correo como necesitemos con el objetivo de no dar a conocer nuestra dirección real de correo.

PD: Gracias a Arturo Jara por el enlace.

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?