um install bind-chroot
chmod 755 /var/named/
chmod 775 /var/named/chroot/
chmod 775 /var/named/chroot/var/
chmod 775 /var/named/chroot/var/named/
chmod 775 /var/named/chroot/var/run/
chmod 777 /var/named/chroot/var/run/named/
cd /var/named/chroot/var/named/
ln -s ../../ chroot
cp /usr/share/doc/bind-9.3.4/sample/var/named/named.local /var/named/chroot/var/named/named.local
cp /usr/share/doc/bind-9.3.4/sample/var/named/named.root /var/named/chroot/var/named/named.root
touch /var/named/chroot/etc/named.conf
chkconfig –levels 235 named on
/etc/init.d/named start

/var/named/chroot/etc/named.conf
——————————–
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};

zone “localhost” IN {
type master;
file “localhost.zone”;
allow-update { none; };
};

zone “localdomain” IN {
type master;
file “/var/named/localdomain.zone”;
allow-update { none; };
};

zone “0.168.192.in-addr.arpa” IN {
type master;
file “/var/named/0.168.192.rev”;
allow-update { none; };
};

include “/etc/rndc.key”;
——————————

/var/named/chroot/var/named/localdomain.zone
——————————————–
$TTL            86400
@                 IN SOA            localdomain.  root.localdomain. (
100     ; serial
1H      ; refresh
1M      ; retry
1W      ; expiry
1D )    ; minimum
@                 IN NS                 ns1.localdomain.
@                 IN A                  192.168.0.50
ns1               IN A                  192.168.0.50
@                 IN MX        10       smtp.localdomain.
correo            IN A                  192.168.0.1
WWW             IN A                  192.168.0.50
pc1                CNAME                 ns1
pc2                IN A                  192.168.0.51
pepino            IN A                  192.168.0.2
————————————————–

/var/named/chroot/var/named/localhost
————————————
localhost.    SOA    ns1.localdomain. hostmaster.localdomain. (
1998092900      ; Serial number
86400      ; Refresh     1 day
7200      ; Retry       2 hours
3600000      ; Expire      41.67 days
172800 )    ; Minimum TTL 2 days

localhost.    NS    ns1.localdomain.

localhost.    A    127.0.0.1
——————————————-

1- Primero instalamos todas la depencias necesarias

yum install httpd gcc glibc glibc-common gd gd-devel libjpeg \
libjpeg-devel libpng libpng-devel mysql mysql-server libdbi libdbi-devel libdbi-drivers libdbi-dbd-mysql

2- Ahora creamos el usuairo que ejecutará el proceso en el servidor

/usr/sbin/useradd -m icinga
passwd icinga
/usr/sbin/groupadd icinga (en Centos de error porque ya esta creado, no pasa ná!)
/usr/sbin/groupadd icinga-cmd
/usr/sbin/usermod -a -G icinga-cmd icinga
/usr/sbin/usermod -a -G icinga-cmd apache

3- Ya que queremos Icinga 1.0, seguimos los siguientes pasos, ya que “yum install nagios” nos instala un Nagios 2.x

cd /usr/src
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
yum install git-all.i386
git clone git://git.icinga.org/icinga-core.git
cd /usr/src/icinga-core
./configure --with-command-group=icinga-cmd --enable-idoutils
make all
make install ; make install-init ; make install-config ; make install-commandmode ; make install-idoutils
ò
make fullinstall

4- Declaramos nuestros contactos

vi /usr/local/icinga/etc/objects/contacts.cfg

5- Valores de ido2db por defecto, para ello renombramos los samples. Esta funcionalidad es por si queremos almacenar en BBDD las alarmas detectadas por Nagios, esto viene determinado por las exigencias del guión. Otra opción muy chula es conectar Nagios con RT, de forma que una alerta nos cree un Ticket, y que éste se resuelva cuando el servicio vuelva a estado OK

cd /usr/local/icinga/etc/
mv idomod.cfg-sample idomod.cfg
mv ido2db.cfg-sample ido2db.cfg
vi /usr/local/icinga/etc/icinga.cfg
Descomentar esta linea
#broker_module=/usr/local/icinga/bin/idomod.o config_file=/usr/local/icinga/etc/idomod.cfg

7- Ahora creamos la base de datos para ido2db

mysql -u root -p
mysql> CREATE DATABASE icinga;
GRANT USAGE ON *.* TO 'icinga'@'localhost' IDENTIFIED BY 'icinga' WITH MAX_QUERIES_PER_HOUR 0 \
MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0;
GRANT SELECT , INSERT , UPDATE , DELETE ON icinga.* TO 'icinga'@'localhost';
FLUSH PRIVILEGES ;
quit
cd /usr/src/icinga-core/module/idoutils/db
mysql -u root -p icinga < mysql.sql
vi /usr/local/icinga/etc/ido2db.cfg
db_servertype=mysql
db_port=3306
db_user=icinga
db_pass=icinga

8- Instalamos el archivo de configuración para apache

make install-webconf
htpasswd -c /usr/local/icinga/etc/htpasswd.users icingaadmin
service httpd restart

9- Los plugins los podemos instalar de las fuentes, pero lo más fácil es instalar de los repositorios de la distribución de turno

Para instalar de las fuentes

plugins (http://www.nagios.org/download/plugins) --> nagios-plugins-1.4.14.tar.gz

cd /usr/src
tar xvzf nagios-plugins-1.4.14.tar.gz
cd nagios-plugins-1.4.14 
./configure --prefix=/usr/local/icinga --with-nagios-user=icinga
make
make install

Para instalar de los repositorios

si hacemos “yum install nagios-plugins”, esto nos creará un directorio tal que “/usr/lib64/nagios/plugins” con los binarios y script que componen el paquete básico de plugins, si necesitamos alguno más podemos mirar en nagios.exchange. Después solo nos quedará enlazar este directorio con el que representa el directorio de plugins de nuestra instalación, tipicamente “/usr/local/icinga/libexec”

ln -s /usr/lib/nagios/plugins/ /usr/local/icinga/libexec

10- Levantamos servicios

service ido2db start
chkconfig –add ido2db
chkconfig –levels 345 ido2db on
/usr/local/icinga/bin/icinga -v /usr/local/icinga/etc/icinga.cfg
service icinga start
chkconfig –add icinga
chkconfig –levels 345 icinga on

(debian -> update-rc.d icinga defaults)
11- Comprobamos

http://<IP>/icinga/
( <icingaadmin> / <password> )
(iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT)

12- NRPE
nrpe (http://www.nagios.org/download/addons/) –> nrpe-2.12.tar.gz)
NRPE nos permite ejecutar plugins remotamente a través de SSL. Necesitamos instalar el cliente en el servidor icinga y el servidor en todas las maquinas remotas que queramos monitorizar a través de NRPE. En cada uno de estos servidores deberemos abrir el 5556 por defecto, y declarar que comandos se podran ejecutar remotamente (y desde donde) en nrpe.conf

yum install openssl-devel
tar xzvf nrpe-2.12.tar.gz
cd nrpe-2.12
./configure --with-nrpe-user=icinga --with-nrpe-group=icinga --with-nagios-user=icinga  \
--with-nagios-group=icinga --enable-ssl --libexecdir=/usr/local/icinga/libexec/ --bindir=/usr/local/icinga/bin/
make all
make install-plugin

Ya hemos terminado, ya solo nos queda configurar correctamente todo los servicios que queramos monitorizar, estoy preparando un ejemplo al respecto!

Cada vez que hagamos un cambio es recomendable ejecutar

/usr/local/icinga/bin/icinga -v /usr/local/icinga/etc/icinga.cfg

Para comprobar sintaxis y todas las declaraciones! siempre nos dice donde esta el fallo
yum remove epel –> al final deshabilitamos el repositorio que hemos agregado!!!!

Vamos a instalar Alfresco en cluster, con dos nodos replicando indices y repositorio, atacando la misma BBDD, con sticky session y balanceado con Apache mod_proxy_balancer y mod_proxy_ajp. Esto nos permitirá no perder la sesión en caso de que un nodo se caiga. Esta configuración tiene algunas ventajas, el rendimiento vendrá determinado por el conjunto de los nodos, pero si apache se cae, se cae el cluster entero. Existen muchas opciones para resolver este problema, sin embargo se salen del proposito de este articulo.

Escenario

Como servidor Frontend tenemos un apache escuchando en el puerto 80, el FQDN vendrá determinado por el ServerName del VirtualHost que vamos a declarar. Luego a través de nuestros DNS dirigimos las peticiones a la maquina que contiene Apache, el hostname que conoce el usuario final. En nuestro ejemplo será:

www.localdomain

www     IN A    192.168.0.10

Siendo 192.168.0.10 la IP del servidor Apache. Bien, ya tenemos las peticiones en el balancerador. Ahora vamos a definir un virtualhost para gestonarlas.

NameVirtualHost *:80
<VirtualHost *:80>
ServerName www.localdomain
ServerAlias www.localdomain
DocumentRoot /var/www/html
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /balancer-manager !
ProxyPass / balancer://www.localdomain/ stickysession=JSESSIONID nofailover=Off
ProxyPassReverse / http://alf1.localdomain:8080
ProxyPassReverse / http://alf2.localdomain:8080
<Proxy balancer://www.localdomain>
BalancerMember ajp://alf1.localdomain:8009 route=jvm1
BalancerMember ajp://alf2.localdomain:8009 route=jvm2
ProxySet lbmethod=byrequests
</Proxy>
<Location /balancer-manager>
SetHandler balancer-manager
Order deny,allow
Allow from all
</Location>
</VirtualHost>

Este virtualhost (service httpd restart para que haga efecto) responde a cualquier IP que contenga la maquina y se guiará por el hostname especificado en la petición, dentro de la cabecera HTTP. Por lo tanto, tenga las IPs que tenga, si es llamado como www.localdomain estaremos llamando a nuestro VirtualHost. Este contendor tan solo tiene definido un proxy reverse con dos servidores en Backend. Además tiene definidos los proxypassreverse necesarios para esconder al usuario final la URL final de los servidores alf1.localdomain y alf2.localdomain, de modo que resulte todo transparente. El Virtualhost también define el balanceador y sus dos miembros, a los que se acederá por AJP. El método de balanceo es por solicitud, esto es, con preponderancia 1:1 Servirá primero de un nodo y luego del otro. La preponderancia se puede afinar si tenemos maquias capaces de gestionar muchas más peticiones que otras.

Con esto casi hemos terminado, ya tenemos las peticiones balanceadas, para comprobarlo podemos crear sendos ficheros dentro del contexto /alfresco tales como hola.jsp para poder comprobar como balacea nuestro proxy

<!– (c) JJ –>
<%@ page language=’java’ contentType=”text/html” %>
<%! int count=0; %>
<html>
<head><title>Hola</title></head>
<body bgcolor=”white”>
nodo: alf1.localdomain
</body></html>

En alf2 cambiamos la linea por “nodo: alf2.localdomain”
Ahora accedemos a http://www.localdomain/alfresco/hola.jsp y pulsamos “F5″ repetidas veces, debemos de ver
nodo: alf1.localdomain
nodo: alf2.localdomain
Alternativamente, esto es 1:1. Ahora tenmos un problema, la sesión.
Para replicarla tan solo nos falta comunicarle a todos los tomcat implicados que deben de publicarla por broadcasting, de esta forma la JSESSIONID es conocida por todos los nodos, apache puede redirigir la petición al mismo nodo durante la misma sesión.

Para ello buscamos la linea

<Engine name=”Catalina” defaultHost=”localhost”>

Y la dejamos así

<Engine name=”Catalina” defaultHost=”localhost” jmvRoute=”jmv1″> –> alf1.localdomain
<Engine name=”Catalina” defaultHost=”localhost” jmvRoute=”jmv2″> –> alf2.localdomain

Después descomentamos la sección <cluster> más abajo en el mismo fichero (para tomcat 6.x es una sola linea)

Instalamos

gnome-sensors-applet, hddtemp y cpufrequtils, con esto a través de “añadir al panel”, podemos controlar la temperatura de los componentes de nuestra maquina, así como el estado y el modo de funcionamiento de la CPU. El hhdtemp lógicamente mide la temperatura del disco duro.

Con el Monitor de Frecuencia de la CPU, con un solo click sobre el applet podemos establecer la frecuencia de trabajo dejarlo en Ondemand o meterle caña al taco en modo performance  (performance hace de nuestro portátil una nave espacial).

También podemos añadir al panel el Monitor de Recursos, que permite ver el estado de CPU, Memoria, Swapping, I/O y Uso de la NIC.

Con todo esto tenemos la maquina controlada de un solo vistazo ! espero que os sirva.

Este post trata de exponer como podemos analizar una traza de java para analizar qué es lo que esta pasando por debajo de ese chorraco de lineas…. a la vez que estoy aprendiendo cosas voy actualizandolo….. pos no me queda na!

Primero hay que detectar que proceso que esta consumiendo los recursos de la maquina, que es lo que esta fastidiando esa amena lectura mañanera del marca, única labor reconocida de un administrador de sistemas bueno, los malos nos pasamos el tiempo intentando mejorar…..

Primero de todo podemos usar el comando top para analizar el estado de cpu, memoria, carga y mucha información útil sobre cada proceso. Es interesante echarle un ojo a htop, una versión más amigable de top que nos permite hacer muchas cosas de forma simple.

Una versión amigable de top

Una vez tenemos el PID del proceso Java “problemático” podemos analizar todos sus LWP (procesos ligeros), lógicamente estos procesos tienen todos como PPID el PID del proceso padre. Ahora veamos como listar todos esos “threats” con su correspondiente porcentaje de uso de CPU

ps --pid PID u -L

Con esto obtenemos un listado como este (solo pongo algunas lineas)

USER       PID   LWP %CPU NLWP %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mikel    17949 17949  0.0  100 33.4 2113200 643700 pts/1  Sl+  11:00   0:00 /usr/java/jdk1.6.0_18/jre/bin/java -Djava.util.logging.config.fi
mikel    17949 17952 13.8  100 33.4 2113200 643700 pts/1  Sl+  11:00   1:10 /usr/java/jdk1.6.0_18/jre/bin/java -Djava.util.logging.config.fi
mikel    17949 17955  0.0  100 33.4 2113200 643700 pts/1  Sl+  11:00   0:00 /usr/java/jdk1.6.0_18/jre/bin/java -Djava.util.logging.config.fi
mikel    17949 17956  0.0  100 33.4 2113200 643700 pts/1  Sl+  11:00   0:00 /usr/java/jdk1.6.0_18/jre/bin/java -Djava.util.logging.config.fi
mikel    17949 17957  0.0  100 33.4 2113200 643700 pts/1  Sl+  11:00   0:00 /usr/java/jdk1.6.0_18/jre/bin/java -Djava.util.logging.config.fi
mikel    17949 17959  9.6  100 33.4 2113200 643700 pts/1  Sl+  11:00   0:49 /usr/java/jdk1.6.0_18/jre/bin/java -Djava.util.logging.config.fi
mikel    17949 17960  0.0  100 33.4 2113200 643700 pts/1  Sl+  11:00   0:00 /usr/java/jdk1.6.0_18/jre/bin/java -Djava.util.logging.config.fi
mikel    17949 17961  0.0  100 33.4 2113200 643700 pts/1  Sl+  11:00   0:00 /usr/java/jdk1.6.0_18/jre/bin/java -Djava.util.logging.config.fi
mikel    17949 17962  0.0  100 33.4 2113200 643700 pts/1  Sl+  11:00   0:00 /usr/java/jdk1.6.0_18/jre/bin/java -Djava.util.logging.config.fi
mikel    17949 17963  0.0  100 33.4 2113200 643700 pts/1  Sl+  11:00   0:00 /usr/java/jdk1.6.0_18/jre/bin/java -Djava.util.logging.config.fi
mikel    17949 17964 29.2  100 33.4 2113200 643700 pts/1  Sl+  11:00   2:29 /usr/java/jdk1.6.0_18/jre/bin/java -Djava.util.logging.config.fi
mikel    17949 17965 27.4  100 33.4 2113200 643700 pts/1  Sl+  11:00   2:20 /usr/java/jdk1.6.0_18/jre/bin/java -Djava.util.logging.config.fi

Como podemos observar tenemos 3 procesos consumiendo el total del los recursos que nos mostraba top, ya estamos desgranado el tema… pero como saber que esta haciendo ese hilo? Fácil repuesta

kill -3 PID

Ale! Acabamos de volcar la memoria de proceso de Java para analizarlo poco a poco, esto es como hacerle una foto a todo lo que esta haciendo realmente el proceso.

Veamos un ejemplo

"RMI TCP Accept-50500" daemon prio=10 tid=0x00007f5e648f9800 nid=0x468a runnable [0x00007f5e5865c000]
   java.lang.Thread.State: RUNNABLE
    at java.net.PlainSocketImpl.socketAccept(Native Method)
    at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:390)
    - locked <0x00007f5e34a94a58> (a java.net.SocksSocketImpl)
    at java.net.ServerSocket.implAccept(ServerSocket.java:453)
    at java.net.ServerSocket.accept(ServerSocket.java:421)
    at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:369)
    at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:341)
    at java.lang.Thread.run(Thread.java:619)

Esto es solo uno de los LWP volcados en mi catalina.out (log principal de proceso Catalina de tomcat), como podemos observar, esta “runable” y se trata de un TCP Transport del protocolo RMI. Ahora eso nos da igual, volvamos a nuestro ps. El LWP del proceso que se come el 27.4 % de la CPU es 17965, como sabemos a cual corresponde? Por el nid de Java, que corresponde con el LWP en hexadecimal, oesa 462D, ya podemos buscarlo con el siguiente patrón

nid=0×462d

"CompilerThread0" daemon prio=10 tid=0x00007f5e64128800 nid=0x462d waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

Otras herramientas que tenemos a mano

JMAP JCONSOLE JINFO

1.Instalación de paquetes:

 yum install sendmail sendmail-cf spamassasssin

2.Configuración:

Configuración de Sendmail

Editamos el archivo /etc/mail/sendmail.mc  y cambiamos la siguiente linea:

 DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

La dejamos así (ya se que lo habías imaginado :P)

 DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl

Reconstruimos la configuración de sendmail

 m4 /etc/mail/sendmail.mc > /etc/mail/sendmail

Editamos el archivo /etc/mail/local-hosts-name y a ñadimos la siguiente linea:

 mydomain.com

Donde  “mydomain.com” es el dominio para el que vamos a configurar Sedmail

Ahora editamos el fichero /etc/mail/access (este fichero puede hacer de tu MTA una sala de bienvenida al SPAM)

Incluimos las siguientes lineas al final, respetando las otras si concuerdan con nuestro direccionamiento privado (si no cambialas gañan!)

 192.168.1   RELAY
 192.168.3   RELAY
 mydomain.com  RELAY

Por último

 service sendmail restart

¿Fácil no? Ya tenemos un mx capaz de enviar y recibir correo para nuestro dominio. Ahora tenemos que configurar SpamAssassin

Configuración de SpamAssassin

Vamos a crear un usuario y configurar el sistema para que todo el correo entrante sea comprobado a través de él

 useradd spamtest
 vi /etc/passwd

Establecemos los parámetros de acuerdo con la seguridad requerida (/sbin/nologin para el bash por ejemplo)

 su – spamtest
 cd ~
 mkdir .spamassassin
 cd .spamassassin
 cp -p /usr/share/spamassassin/user_prefs.template user_prefs
 cat <<EOF >>user_prefs
 rewrite_subject 1
 report_header 1
 use_terse_report 1
 defang_mime 0
 report_safe 0
 use_bayes 1
 auto_learn 1
 ok_locales es
 EOF

Como usuario spamtest lanzamos estos comandos

 spamc -R </usr/share/doc/spamassassin-3.2.4/sample-nonspam.txt
 spamc -R </usr/share/doc/spamassassin-3.2.4/sample-spam.txt

Explicación ejemplos

1-Cuando el sample nonspam llega a spamc, este trata el texto enviandoselo a spamd para calcular la puntuación spam del correo. Como no tiene características spam su valor será 0 pero sin embargo nos muestra un -6.3 por ser un correo firmado con PGP. Como la puntuación necesaria por defecto para considerarse Spam es de 5.0, el correo es tratado como ‘Ham’.

2- El segundo mensaje tiene varias características spam, ninguna de ellas es suficiente para llegar a 5.0 pero sumadas llegan a 8.4

Si todo esta correctamente deberíamos tener un resultado como este

1er ejemlo:

 -6.3/5.0
 * -6.3 -- Contains a PGP-signed message

2º ejemplo:

 8.4/5.0
 * 0.7 -- From: does not include a real name
 * 0.6 -- Invalid Date: header (not RFC 2822)
 * 1.4 -- Valid-looking To "undisclosed-recipients"
 * 1.5 -- BODY: Information on how to work at home (2)
 * 1.5 -- BODY: Drastically Reduced
 * 0.8 -- BODY: List removal information
 * 0.7 -- BODY: Once in a lifetime, apparently
 * 0.2 -- Date: is 12 to 24 hours before Received: date
 * 0.6 -- RBL: Received via a relay in relays.osirusoft.com
 [RBL check: found 142.249.10.63.relays.osirusoft.com., type: </nowiki> 127.0.0.3]
 * 0.4 -- Message-Id is not valid, according to RFC 2822

Configuración del usuario “filtra-mensajes”

Ya sabemos que spamc esta identificando los correos adecuadamente, ahora tenemos que configurar el usuario spamtest para que filtre realmente todo el correo entrante hacia la maquina.

 cd ~
 mkdir .procmail
 touch .procmail/proclog
 mkdir mail
 touch mail/mbox

Si el usuario va a recibir el correo de esta maquina a través de IMAP o POP

 SHELL=/bin/sh
 PATH=/bin:/usr/bin
 PMDIR=$HOME/.procmail
 LOGABSTRACT=all
 MAILDIR=$HOME/mail       #asegurate de que existe
 LOGFILE=$PMDIR/proclog   #recomendado
 VERBOSE=off

 #Spamassassin start
 :0fw: spamassassin.loc
 | /usr/bin/spamc
 #Spamassassin end

Así procmail envía el mensaje a spamc para la valoración spam y el cambio en las cabeceras, después el mensaje es devuelto a su destino original, normalmente (/var/spool/mail/spamtest). Esta es la carpeta IMAP INBOX para el usuario spamtest.

Si el usuario va a recibir el correo directamente en esta maquina

 SHELL=/bin/sh
 PATH=/bin:/usr/bin
 PMDIR=$HOME/.procmail
 LOGABSTRACT=all
 MAILDIR=$HOME/mail       #asegurate de que existe
 LOGFILE=$PMDIR/proclog   #recomendado
 VERBOSE=off
 DEFAULT=$MAILDIR/mbox

 #Spamassassin start
 :0fw: spamassassin.lock
 | /usr/bin/spamc

 :0:
 * ^X-Spam-Level: \*\*\*\*\*
 spam5

 :0:
 * ^X-Spam-Status: Yes
 spamassassin-spam

 #Spamassassin end

1. Antes de nada leer un poquito antes de pasar a la acción

Read the rest of this entry »

Configuracion de Postfix con Spamassassin y Postgrey
1.Configuracion inicial de Postfix

Archivo de configuracion main.cf para el dominio ejemplo.com, suponiendo que la entrada mx del domino apunta a correo.ejemplo.com

 queue_directory = /var/spool/postfix
 command_directory = /usr/sbin
 daemon_directory = /usr/libexec/postfix
 mail_owner = postfix
 myhostname = correo.ejemplo.com
 mydomain = ejemplo.com
 inet_interfaces = all
 unknown_local_recipient_reject_code = 550
 smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination
 check_policy_service inet:127.0.0.1:60000  smtpd_helo_required = yes
 relay_domains = $mydestination, ejemplo.com
 alias_maps = hash:/etc/aliases
 alias_database = hash:/etc/aliases
 debug_peer_level = 2
 debugger_command =
 PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
 xxgdb $daemon_directory/$process_name $process_id & sleep 5
 sendmail_path = /usr/sbin/sendmail.postfix
 newaliases_path = /usr/bin/newaliases.postfix
 mailq_path = /usr/bin/mailq.postfix
 setgid_group = postdrop
 html_directory = no  manpage_directory = /usr/share/man
 sample_directory = /usr/share/doc/postfix-2.3.3/samples
 readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES

¿Como funciona Postgrey y para que sirve?

La directiva ”’check_policy_service inet:127.0.0.1:60000”’  hace saber a Postfix que debe dejar que  Postgrey procese cada correo entrante. Postgrey mira las cabeceras SMTP para determinar

SERVIDOR SMTP ORIGEN - FROM - TO

El servicio Postgrey mantiene una tabla con estas tripletas y rechaza cualquiera “no conocida” con un error temporal. Esto hace que los verdaderos MTA reenvien el correo pasado cierto tiempo y Postgrey lo deje pasar, siempre que hayan pasado 5 minutos (por defecto) desde la primera vez que llegó. A partir de entonces esa tripleta será conocida para el sistema (hasta que pasen 20 días sin que la aparezca por nuestro MTA, entonces vuelta a empezar).La idea principal es que los spambots, etc, no reenvian correos, simplemente se dedican a enviar a “cascoporro” sin preocuparse si llegaron o no.

2.Ahora Instalamos Postgrey y Spamassassin

 yum install -y postgrey spamassassin

El archivo de configuracion principal de Spamassassin es /etc/mail/spamassassin/local.cf,

3.Configuracion de Postgrey y Spamassassin

Para terminar de tener Postgrey funcionando lo añadimos a los runlevels deseados y editamos el script de incio

 chkconfig –levels 345 postgrey on
 vi /etc/init.d/postgrey

Buscamos la linea

 OPTIONS="--unix=$SOCKET"

Y la cambiamos por

 OPTIONS="--inet=localhost:60000 -d"

Y por último

 service postgrey start

Ya tenemos el greylisting implementado para Postfix funcionando, solo nos queda hacer lo mismo con Spamassassin. Para ello editamos el archivo /etc/postfix/master.cf y buscamos la siguiente linea:

 smtp inet n - n - - smtpd

y la dejamos asi

 smtp inet n - n - - smtpd -o content_filter=spamassassin

Y en la sección non-Postfix añadimos la siguiente linea:

 spamassassin unix -n n - - pipe user=nobody argv=/usr/bin/spamc -e /usr/sbin/sendmail.postfix -oi -f ${sender} ${recipient}

Lo suyo es leer la página de sintaxis para master.cf (man 5 master.cf !!!)

Ahora creamos el usuario con el que se ejecutará Spamassassin, podriamos levantarlo como root, pero existen algunas vulnerabilidades de las que nos queremos porteger.

 groupadd -g 501 spamd
 useradd -u 501 -g 501 -s /sbin/nologin -d /home/spamd spamd

Y en script de inicio cambiamos las variables SPAMDOPTIONS Y SPAMD_PID a estos valores

 SPAMDOPTIONS="-d --username=spamd -c -m5 -H"
 SPAMD_PID=/home/spmad/spamd.pid

Ya podemos arrancar el servicio

 service spamassassin start
 chkconfig --levels 345 spamassassin on

Por último algunas cosas que deberiamos cambiar en el /etc/mail/spamassassin/local.cf

#Score requerido para marcar el mensaje con el texto “rewrite_subject”

 required_hits     5.0

# Texto con el que marcamos el spam

 rewrite_header Subject [*****SPAM*****]

# Encapsular el spam en un adjunto por seguridad

 report_safe    1

# Habilitar el sistema Bayesiano

 use_bayes    1

# Habilitar el auto-aprendizaje del sitema Bayesiano

 bayes_auto_learn    1
 bayes_path         /home/spamd/bayes
 bayes_file_mode    0666

# Controlar el funcionamiento de los componentes más comunes (fuera del alcance de este articulo)

 skip_rbl_checks    0
 use_razor2         0
 use_dcc            0
 use_pyzor          0

# Dependiendo de la politica de la empresa podemos especificar uno o varios lenguajes, los demás #ganaran score en el filtrado

 ok_languages    all
 ok_locales      all

#Crea Whitelist para los dominios importantes desde los que recibas correo.

 whitelist_from         *@micliente.com

Instalación de RT en CentOS

(Se presupone la instalación y correcta configuración de Sendmail para la recepción y el envío de correo desde y hacia el Host. (Cuidado con los open relays, no queremos que nuestro dominio acabe bloqueado por listas negras)

1.Primero instalamos algunos paquetes necesarios

yum install -y  httpd perl mysql mysql-server mod_perl  graphviz graphviz-devel graphviz-doc graphviz-gd graphviz-perl perl-GraphViz.noarch  gd gd-devel

2.Ahora instalamos RT

wget http://download.bestpractical.com/pub/rt/release/rt-3.8.7.tar.gz
tar xzvf rt-3.8.7.tar.gz ; cd rt-3.8.7
./configure –with-web-user=apache –with-web-group=apache –with-web-handler=modperl2 –with-db-type=mysql –prefix=/opt/rt3 –enable-graphviz –enable-gd –enable-gpg
make testdeps

”’Configuración de CPAN”’
nota: Dependencias no obligatorias pero recomendables ->  ncftp y links, las podemos descargar de rpmfind.net

Para configurar CPAN ejecutamos

/usr/bin/perl -MCPAN -e shell

Le damos a todos los valores por defecto menos la codificación (UTF8), luego de los mirrors elegimos Europa, luego Finlandia y luego todas las opciones que de (adoro a los Finlandeses, sus redes simplemente vuelan, los “debianeros” saben de que hablo

OTRA NOTA:
Las dependencias de RT son muchas así que paciencia, dale que si que si a las dependencias hasta que termine. Si configuras CPAN para que procese las dependencias sin preguntar, preparate, yo una vez lo tuve 2 días hay rulando,

Ahora ya podemos ejecutar

make fixdeps

Si termina en fallo, (posiblemente lo haga) habrá soltado en pantalla los que falta, entonces toca ir a /root/.cpan/build y revisar los paquetes, la rutina normal para instalar un modulo de Perl es

(make clean)
perl Makefile.PL
make
make install

Aunque siempre es bueno usar el –help. Para instalar un modulo de los repositorios de CPAN configurados también podemos hacer

cpan -i RT::Extenison::CommandByMail

EJEMPLO DE TODO ESTE PUTEO: Un caso común en la 3.8.4

Módulo XML::RSS -> RT busca la versión 1.05, CPAN instala la 1.43, se pueden descargar las fuentes de http://search.cpan.org e instalar la versión adecuada.

Una vez resueltas todas las dependencias de Perl, podemos terminar la instalación

make install ; make initialize-database

Esto nos crea la base de datos con las credenciales rt_user / rt_pass, lo podemos cambiar en el RT_Config.pm antes de ejecutar make initialize-database o asignar los permisos a mano… up to you.
Ahora creamos el archivo de configuración de apache

vi /etc/httpd/conf.d/rt3.conf

Alias /helpdesk “/opt/rt3/share/html/”
PerlRequire /opt/rt3/bin/webmux.pl
<Directory “/opt/rt3/share/html/”>
AllowOverride All
Options ExecCGI FollowSymLinks
RewriteEngine On
RedirectMatch permanent (.*)/$ $1/index.html
AddDefaultCharset UTF-8
SetHandler perl-script
PerlHandler RT::Mason
</Directory>

Ahora editamos el /etc/aliases e incluimos los aliases que necesitemos al final del archivo

#ALIAS RT
ejemplo: “|rt-mailgate –queue ejemplo –action correspond –url http://www.ejemplo.com/helpdesk/”
ejemplo-com: “|rt-mailgate –queue ejemplo –action comment –url http://www.ejemplo.com/helpdesk/”

Ahora nos aseguramos de que todo va a funcionar automatizado, y que reiniciamos los cambios realizados:

ln -s /opt/rt3/bin/rt-mailgate /etc/smrsh/
newaliases
service sendmail restart
chkconfig sendmail on
chkconfig httpd on
chkconfig mysqld on
service httpd restart

Y listo! Para acceder

http://www.ejemplo.com/helpdesk
root
password

Montar unidades remotamente a través de ssh es muy seguro, ya que utiliza el protocolo de cifrado RSA, pero tiene un inconveniente, la velocidad. Sin embargo también tiene cosas buenas, a mi particularmente NFS me parece un poco engorroso, editar el etc/export no es el problema, la cantidad de puertos que mantiene abiertos si, por eso para algunos entornos pequeños es una solución que tan sólo usa el puerto 22.

Ahora vamos a instalar los paquetes necesarios para el sistema.

yum install fuse fuse-sshfs

Damos permiso al usuario que montará el recurso compartido

usermod -G fuse my_yuser

Creamos un directorio en donde montaremos el directorio remoto:

mkdir /home/my_user/my_dir

Finalmente montamos la unidad

sshfs my_remote_user@remote_server:/remote_dir /home/myuser/my_dir

Listo!