Todos los sistemas operativos tienen algún tipo de algoritmo de planificación más o menos eficiente que permite a todos los procesos del sistema y del usuario poder hacer uso de la CPU. Un buen algoritmo de planificación debe ser capaz de controlar todos estos parámetros:
+ equitatividad: cada proceso debe recibir su parte justa de CPU y recursos.
+ eficiencia: la CPU debe ser usada todo el tiempo. No desaprovecharla.
+ throughput: producir el mayor numero de trabajos terminados por hora.
+ respuesta: minimizar el tiempo de respuesta en las aplicaciones interactivas.
Manejar todos estos parámetros es muy difícil ya que dentro de un sistema podemos encontrar diferentes tipos de procesos y tareas cada una con sus propias características y necesidades. Por ejemplo, tenemos procesos que utilizan intensamente la CPU y otros que estarían todo el día parados esperando E/S. Por tanto, cuando Linux empieza a ejecutar un proceso, no sabe 100% cuanto tiempo necesitará ese proceso la CPU.
Durante el diseño de sistemas de compartición y scheluding han ido surgiendo diferentes tipos de algoritmos de palanificación:
+ planificación por round-robin: quizás el más conocido y que se estudia más durante la carrera informática. Es uno de los más antiguos y tal vez el más sencillo de implementar y justo. Se basa en mantener una cola o lista de procesos, asignándoles un tiempo de ejecución a cada proceso. Pasado ese tiempo le quitamos al proceso la CPU y se la damoss a otro. Lo más difícil de calcular es el ¿cuanto tiempo?. Si ponemos poco tiempo haremos mucho swaping entre procesos y eso puede ser malo porque podemos perder mucho tiempo en cambiar de contexto. Si decidimos poner mucho tiempo, podemos perjudicar a otros procesos que son muy interactivos con el usuario.
+ planificación por prioridades: consiste en dar una prioridad al proceso. Contra más prioridad tenga un proceso antes utilizará la CPU. Dentro de este tipo de planificación podemos encontrar que las prioridades se pueden asignar estática o dinámicamente.
+ planificación por colas: consiste en tener varias colas donde los procesos alojados en una cola utilizan la CPU X ms., los alojadas en la segunda cola la utilizan 2X ms., y así sucesivamente. Una vez los procesos utilizan todo su tiempo van rotando por las diferentes colas.
+ planificación en tiempo real: quizás estos algoritmos son los más complicados ya que deben asegurar respuestas a posibles eventos. Por ejemplo, un sistema que controle la altura de un vuelo. Si salta la alarma de altura, el proceso que controla este evento tiene que estar dentro de la CPU para poder tomar el control. Una respuesta correcta pero tarde, puede ser peor que no obtener respuesta.
+ otros planificadores: planificación por lotería, planificación garantizada, planificación en varios niveles, etc.
En Linux tenemos una mezcla de varios de los planificadores que he explicado, pero básicamente sería algo como un round-robin con prioridades. En realidad podemos planificar cada proceso con una política diferente. Estas son las políticas de Linux:
+ SCHED_OTHER: en Unix es la planificación clásica. No es aplicable en tiempo real. Examina las prioridades dinámicas (calculadas como combinación de las especificadas por el usuario y las calculadas por el sistema). Los procesos que llevan más tiempo en el sistema van perdiendo prioridad.
+ SCHED_FIFO: El primero en entrar en la cola es el primero en ser servido. Los procesos esperan en cola y se ejecutan secuencialmente. Se sigue calculando un cuanto de tiempo para el proceso, aunque normalmente no se use porque con esta planificación no se fuerza al proceso a abandonar la CPU. Se usa en procesos de tiempo real.
+ SCHED_RR: round-robin. Funciona como el FIFO pero ahora cuando un proceso acaba su cuanto de tiempo (time slice) se le desaloja. El siguiente proceso se escoge de la lista de procesos con SCHED_RR o de la lista SCHED_FIFO. Son procesos en tiempo real.
+ SCHED_YIELD: No es una política de planificación, sino un modificador que afecta a las tres políticas anteriores. El proceso cede la CPU a cualquier otro que esté listo.
Más información:
- Understanding the Linux 2.6.8.1 CPU Scheduler
prioridades en linux (i de ii)
23 de junio de 2009si quieres estos botones bajate miaddthis
por
amperis
a las
12:34 p. m.
0
comentarios
enviar por correo
suscribirse
url
ver reacciones
Etiquetas: linux
envio de sms en linux
11 de junio de 2009
Una de las cosas chulas de Nagios es que puedes ir creando servicios de notificación para enviar mensajes por diferentes medios cuando un servicio cae. Lo normal es hacer que Nagios te envíe un mail cuando un disco se llene, cuando una impresora deje de funcionar o cuando el ancho de banda de un router esté al 80%.
Otra forma curiosa de enviar notificaciones es enviar todas estas a Twitter. Simplemente echando un vistazo a tú Twitter puedes ver que está pasando con tus servidores... ¿arriesgado?.
Lo más efectivo es el envio de SMS a tú móvil en caso de que un servicio importante deje de funcionar. El uso de la notificación por correo (o el Twitter) solo funciona si tú conexión a Internet está funcionando. ¿Que pasa si monitorizas tú conexión a Internet y esta ha caído?.
Para ello he rebuscado y rebuscado entre todos lo móviles de la empresa hasta encontrar uno con conexión USB y sobre todo que sea capaz de cargarse la batería también por el mismo cable USB... al final encontré uno muy chulo: un Motorola V3.
Lo primero que tenemos que hacer es verificar si es capaz de detectar el móvil. Para ello lanzamos un lsusb (todos los resultados están bajo un Fedora 7):
[root@server ~]# lsusb Bus 001 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 003 Device 007: ID 22b8:4902 Motorola PCS E398 GSM Phone Bus 003 Device 001: ID 0000:0000
Como resultado también obtendremos un nuevo dispositivo mapeado en /dev/ttyACM0. Un dispositivo ttyACM identifica a un módem USB, y como tal módem es capaz de ser atacado vía comandos AT. Los comandos AT son cadenas de texto que nos permiten interactuar con cualquier módem para inicializarlo, marcar un número, transferir un fichero o colgar una llamada. Los móviles son modems GSM y, por tanto, también acepta comandos AT.
Los comandos AT que debemos enviar para que el móvil envie un SMS son los siguientes:
AT+CMGF=1 (le dice al módem que enviamos los SMS en formato texto). AT+CSCA="+34607003110" (le decimos que el número del centro de mensajes es el +34607003110) AT+CMGS="696342572" (le decimos el número donde debe enviar el SMS) > Hola caracola <Ctrl+Z> (escribimos el mensaje y lanzamos un Ctrl+Z).
Lo único que necesitamos saber es el número del centro de mensajes SMS de nuestra operadora. En mi caso el SIM de la tarjeta es Vodafone y el centro de mensajes es el +34607003110. Esta información la puedes encontrar dentro de la configuración del móvil o te la puede dar la operadora.
Una vez sabemos como funciona todo, podemos crear un script en Perl que nos permita hacer todo esto en una simple línea de comandos.
#!/usr/bin/perl $_SMS_CM="+34607003110"; $_SMS_MODEM="/dev/ttyACM0"; if ($#ARGV != 1 ) { print "sendsms.pl v0.1b, por amperis[@]gmail.com\n\n"; print "Uso:\n"; print " ./sendsms.php <numero destino> \"<mensaje>\"\n\n"; exit; } use Device::Modem; my $modem = new Device::Modem( port => $_SMS_MODEM ); if ( $modem->connect( baudrate => 115200 ) ) { $modem->echo(1); $modem->verbose(1); $modem->atsend( 'AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0'.Device::Modem::CR); print $modem->answer()."\n"; $modem->atsend( 'AT+CMGF=1'.Device::Modem::CR); print $modem->answer()."\n"; $modem->atsend( 'AT+CSCA="' . $_SMS_CM. '"'.Device::Modem::CR); print $modem->answer()."\n"; $modem->atsend( 'AT+CMGS="' .$ARGV[0]. '"'.Device::Modem::CR); print $modem->answer()."\n"; $modem->atsend( $ARGV[1].chr(26)); print $ARGV[1]."\n\n"; print "\nFin de la conexion.\n\n"; } else { print "ERROR: No encuentro el modem.\n"; }
Nota: Tenemos que tener instalado en Perl el paquete Device::Modem. Para instalar paquetes en Perl hacemos un "perl -e shell -MCPAN" y luego haremos un ">install Device:Modem".
Ahora solo queda dar permisos de ejecución al script (chmod +x sendsms.pl) y ejecutarlo:
# ./sendsms.pl 696342572 "Error a las 19:35h. Router Cisco 877 sin conexión"
Más información:
+ Using AT commands to Send and Receive SMS
si quieres estos botones bajate miaddthis
por
amperis
a las
10:34 p. m.
5
comentarios
enviar por correo
suscribirse
url
ver reacciones
Etiquetas: administración, linux
calcular el tamaño de una instalación zimbra
31 de mayo de 2009Este 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
si quieres estos botones bajate miaddthis
por
amperis
a las
11:11 p. m.
0
comentarios
enviar por correo
suscribirse
url
ver reacciones
Etiquetas: administración, zimbra
estadísticas de un mailbox
29 de mayo de 2009De 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
si quieres estos botones bajate miaddthis
por
amperis
a las
10:19 a. m.
0
comentarios
enviar por correo
suscribirse
url
ver reacciones
Etiquetas: zimbra
bind para el correo (parte iii de iii)
26 de mayo de 2009Por ú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.
si quieres estos botones bajate miaddthis
por
amperis
a las
6:57 p. m.
0
comentarios
enviar por correo
suscribirse
url
ver reacciones
bind para el correo (parte ii de iii)
25 de mayo de 2009Para 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.
si quieres estos botones bajate miaddthis
por
amperis
a las
9:00 a. m.
0
comentarios
enviar por correo
suscribirse
url
ver reacciones
bind para el correo (parte i de iii)
24 de mayo de 2009Como 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;".
si quieres estos botones bajate miaddthis
por
amperis
a las
9:20 a. m.
1 comentarios
enviar por correo
suscribirse
url
ver reacciones
¿qué pasa cuando google street no llega?
23 de mayo de 2009si quieres estos botones bajate miaddthis
por
amperis
a las
2:26 p. m.
0
comentarios
enviar por correo
suscribirse
url
ver reacciones
Etiquetas: google
tamaño de los buzones en tiempo real
21 de mayo de 2009Por 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
si quieres estos botones bajate miaddthis
por
amperis
a las
12:19 p. m.
0
comentarios
enviar por correo
suscribirse
url
ver reacciones
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.
si quieres estos botones bajate miaddthis
por
amperis
a las
3:46 p. m.
0
comentarios
enviar por correo
suscribirse
url
ver reacciones
Etiquetas: postfix, seguridad, zimbra

suscribirse
para perder un rato
lo que leo
etiquetas
- administración (65)
- zimbra (61)
- linux (56)
- seguridad (56)
- networking (41)
- internet (35)
- postfix (24)
- tecnología (19)
- informatica (16)
- tonterias (16)
- php (15)
- google (14)
- cisco (13)
- mysql (12)
- windows (11)
- asterisk (9)
- general (7)
- apache (6)
- squid (5)
- bind (4)
- hacking (4)
- itil (4)
- oracle (4)
- ajax (3)
- sap (3)
- ubuntu (3)
- flickr (2)
- fotografía (2)
- blackberry (1)
- castelldefels (1)
- fonera (1)
- kirai (1)
- metadatos (1)
- samba (1)
- scp (1)
- seo (1)