Servidor de la Biblioteca de Ingeniería. Universidad …bibing.us.es/proyectos/abreproy/12038/fichero/07.pdfPFC – SME del CdC 22 Correo electrónico: instalación básica Se va

5. Implementación

17

5. Implementación

Solución software escogida

Después de haber hecho un análisis sobre las distintas alternativas software, se ha decidido usar Zimbra como servidor de correo electrónico para implementar el sistema de mensajería del centro de cálculo. Las alternativas evaluadas han sido:

Soluciones modulares: ◦ Exim + ClamAV + SpamAssasin + Dovecot + STARTTLS + SMTP AUTH + Mailman: Esta

solución está basada en los módulos más conocidos.

Soluciones integradas: ◦ iRedMail: Utiliza Postfix como MTA. Es de código abierto. Es una solución integrada y se

anuncia como libre. Sin embargo, la parte gratuita es la integración ya realizada de todos los paquetes, prácticamente los mismos que en la solución modular mencionada anteriormente. Una vez integrados todos los paquetes, desde iRedMail se vende una interfaz de configuración y administración que aporta numerosas ventajas y posibilidades.

◦ Zimbra: Utiliza Postfix como MTA. Es un software colaborativo. Incluye varias funciones además del correo electrónico. Tiene una versión de código abierto que incluye una versión completa del sistema. Presenta una serie de limitaciones pero ninguna en la prestación del servicio. Algunas de ellas: no se pueden eliminar los logotipos de Zimbra, no incluye funciones avanzadas (por ejemplo, configuraciones de cluster), etc.

◦ Horde: Utiliza Postfix como MTA. Al igual que Zimbra, se trata de un software colaborativo de código abierto. Está distribuido en módulos propios, facilitando una instalación modular sus distintos componentes.

Soluciones cloud: no han sido evaluadas ya que no son compatibles con los requisitos de coste requeridos.

Antes de tomar una decisión definitiva, se redujo la lista de candidatos a dos: iRedMail y Zimbra. El descarte de la solución modular se debe a que Postfix y Exim tienen un rendimiento similar, con lo cual, la solución modular e iRedMail son prácticamente la misma, con el inconveniente de que en la solución modular es necesaria la instalación e integración de los paquetes uno a uno. Por tanto se descarta la solución modular frente a iRedMail. Horde se desecha al compararlo con Zimbra. Zimbra tiene una comunidad inmensa, donde los desarrolladores participan activamente, resolviendo dudas concretas, haciendo seguimiento de errores conocidos y facilitando soluciones a cualquier tipo de configuración que no esté englobada en las versiones de pago de Zimbra. Sin embargo, la información relativa a Horde es más escasa y aunque también cuenta con una comunidad, no es tan completa. La información y la diversidad son fundamentales desde el punto de vista del desarrollo de una solución concreta, como la que nos ocupa. Por tanto, de entre estas dos soluciones integradas, se prefiere Zimbra. Tras realizar las instalaciones y configuraciones básicas de iRedMail y Zimbra, finalmente se

PFC – SME del CdC

18

opta por Zimbra (http://www.zimbra.com). A continuación se puede ver una tabla comparativa de ambos en cuantos a los requisitos

del proyecto:

Requisitos iRedMail Zimbra

Autenticación en envío

Accesibilidad completa WEBMAIL y cliente

Filtros antispam, correo basura, virus

Integración de servicios (webdav)

Sistema de buzones por mails

Cuotas de usuario y carpetas

Monitorización y estadísticas

Listas de distribución automantenidas (mailman)

(mailman)

Virtualización

Tabla 1: Comparativa entre iRedmail y Zimbra

Los motivos que condujeron a la decisión final de elegir Zimbra son los siguientes:

Integración perfecta entre los distintos módulos, ya que han sido ajustados por Zimbra para que encajen adecuadamente.

Amplia comunidad de consulta.

Wiki propia con instrucciones, configuraciones, métodos de importación y casi cualquier problema ya resuelto.

Todo integrado: Correo electrónico, calendario, contactos, tareas, almacenamiento.

Interfaz web muy potente, elaborada con AJAX (Asynchronous JavaScript And XML). Permite una multitud de funciones tales como: arrastrar y soltar, menú en el botón derecho, versión móvil, versión ligera (html), etc. Además, la interfaz web integra todas las aplicaciones con una gran interoperabilidad entre todas ellas.

Rendimiento probado en numerosos escenarios, siendo la versión básica, instalada en un único servidor, capaz de dar servicio a varios miles de usuarios.

Galería de extensiones (Zimlets) de instalación trivial, con actualizaciones constantes.

Instalación sencilla.

Numerosos casos de éxito.

Todos los requisitos satisfechos.

La versión elegida es ZCS (Zimbra Collaboration Server) Open Source Edition 7.1.4, la más reciente.

http://www.zimbra.com/

5. Implementación

19

Zimbra

La empresa Zimbra (http://www.zimbra.com) fue comprada por Yahoo! (http://www.yahoo.com) en 2007. Poco después de mejorar su propio correo electrónico y dejarlo muy parecido al de Zimbra, en 2010 Yahoo! vendió Zimbra a VMWare (http://www.vmware.com).

La versión de código abierto se ofrece bajo la licencia ZPL (Zimbra Public License), derivada de CPL (Common Public License) y MPL (Mozilla Public License). La versión de código abierto hace uso de los siguientes proyectos también de código abierto:

Postfix

MySQL

OpenLDAP

Jetty

Lucene

ClamAV

SpamAssasin

Amavisd y Amavisd-new

DSPAM

Aspell

James

Sieve

nginx

Ilustración 13: Logo Zimbra

Ilustración 14: Zimbra Collaboration Server Open Source Edition


http://www.yahoo.com/

http://www.vmware.com/

PFC – SME del CdC

20

Mailman

Para cumplir adecuadamente con los requisitos, se hace necesaria la utilización de Mailman (http://www.gnu.org/software/mailman/index.html) integrado con Zimbra. Mailman es un gestor de listas de distribución con licencia GNU GPL. La ventaja de este sistema frente al que incluye Zimbra de forma integrada, es la posibilidad de que distintos usuarios gestionen distintas listas. Así, en Zimbra, si se desea añadir una persona a una lista de distribución, deberá ser el administrador quien se encargue de hacerlo. Mientras que Mailman cuenta con una interfaz de gestión web preparada para definir múltiples administradores de las distintas listas de distribución y un único administrador del sistema (el encargado de crear y eliminar listas), de forma tal que se pueden considerar listas de distribución automantenidas (requisito del proyecto). La instalación dependerá de si se va a realizar sobre una instalación básica de Zimbra o si se va a instalar sobre una instalación multiservidor.

Ilustración 15: Logo Mailman (antiguo) Ilustración 16: Logo Mailman

http://www.gnu.org/software/mailman/index.html

5. Implementación

21

Z-Push

La versión de código abierto de Zimbra no incluye el servicio de sincronización de contactos, tareas y correo electrónico, conocido como Exchange, para dispositivos móviles. Aunque sí permitiría esta sincronización haciendo uso de IMAP, CalDav (para la agenda) y CardDav (para los contactos), es difícil encontrar aplicaciones gratuitas que lo permitan. Z-Push (http://z-push.sourceforge.net/soswp/) es un proyecto de código abierto que implementa un Exchange usando Microsoft ActiveSync. El funcionamiento de Z-Push, está basado en módulos (conocidos como backends) que implementan la interacción con los distintos sistemas comerciales existentes.

Z-Push Zimbra Backend (http://sourceforge.net/projects/zimbrabackend/) es una implementación de código abierto de un backend mediante el cual puede usarse Z-Push sobre Zimbra. La instalación se debe realizar en un servidor distinto a Zimbra, ya que z-push necesita apache y apache es incompatible con Zimbra (debido a que Zimbra utiliza su propio apache). No obstante, puede configurarse la instalación de Zimbra para que coexista con apache, aunque no es recomendable. Debido a que la instalación definitiva que se va a emplear de Zimbra será multiservidor, como se comentará más adelante, el servidor MTA de Zimbra será el escenario perfecto para instalar Z-Push, ya que en él Zimbra no estará usando apache y, por tanto, no habrá incompatibilidad.

Ilustración 17: Logo Z-Push

Ilustración 18: Logo Zimbra backend

http://z-push.sourceforge.net/soswp/

http://sourceforge.net/projects/zimbrabackend/

PFC – SME del CdC

22

Correo electrónico: instalación básica

Se va a analizar cómo se realiza la instalación de ZCS OS 7.1.4 (Zimbra a partir de ahora) para un único servidor. Se implementará esta instalación sobre Ubuntu Server 10.04.3 LTS para 64 bits (http://www.ubuntu.com/). La decisión de utilizar este sistema operativo está fundamentada en que el centro de cálculo utiliza habitualmente Debian. ZCS OS 7.1.4 no está recomendado sobre Debian y Ubuntu es la alternativa con mayor afinidad a Debian. En primer lugar, se debe descargar la instalación de la página web de Zimbra (www.zimbra.com), para ello:

Posteriormente, se descomprime:

Es necesario instalar, como root, los siguientes paquetes:

Una vez instalados, ya es posible instalar Zimbra. No obstante, la instalación hace una comprobación sobre el nombre del equipo (hostname). Dicho nombre debe ser de tipo FQDN (Fully Qualified Domain Name), es decir, de la forma nombrepropio.subdominio.dominio. Es un requisito indispensable para continuar la instalación. La motivación de esto es evitar errores derivados de que el equipo no esté correctamente identificado. Además, es muy recomendable que se haga uso de un nombre asociado a un DNS. La instalación hará una petición DNS para comprobarlo y permitirá continuar si no es así aunque no sea lo ideal. Para satisfacer esto, habría que ajustar los siguientes ficheros del sistema operativo:

/etc/hostname

/etc/hosts

Ahora:

Aceptamos la licencia e instalamos todos los paquetes con [Y] por defecto: ldap, logger, mta, snmp, store, apache y spell.

wget http://files2.zimbra.com/downloads/7.1.4_GA/\ zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz

tar xvfz zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz

apt-get install sysstat sqlite3

- nombre_no_FDQN #se elimina esta línea + nombrepropio.subdominio.dominio #se añade esta línea

+ IP_del_equipo nombrepropio.subdominio.dominio nombrepropio

cd zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803 ./install.sh

http://www.ubuntu.com/


5. Implementación

23

Autorizamos que se modifique el sistema y llegamos a la pantalla de configuración de la instalación:

(continúa en la siguiente página)

Checking for installable packages

Found zimbra-core Found zimbra-ldap Found zimbra-logger Found zimbra-mta Found zimbra-snmp Found zimbra-store Found zimbra-apache Found zimbra-spell

Select the packages to install

Install zimbra-ldap [Y] y Install zimbra-logger [Y] y Install zimbra-mta [Y] y Install zimbra-snmp [Y] y Install zimbra-store [Y] y Install zimbra-apache [Y] y Install zimbra-spell [Y] y Checking required space for zimbra-core checking space for zimbra-store

Installing: zimbra-core zimbra-ldap zimbra-logger zimbra-mta zimbra-snmp zimbra-store zimbra-apache zimbra-spell

Main menu

1) Common Configuration:

+Hostname: mailhost.example.com +Ldap master host: mailhost.example.com +Ldap port: 389 +Ldap Admin password: set +Secure interprocess communications: yes +TimeZone: America/Los_Angeles

2) zimbra-ldap: Enabled +Status Enabled +Create Domain: yes +Domain to create: mailhost.example.com +Ldap root password: set +Ldap replication password: set +Ldap postfix password: set +Ldap amavis password: set +Ldap nginx password: set

PFC – SME del CdC

24

Las líneas marcadas con **** al inicio indican que necesitan ser revisadas para completar la configuración. Para el correcto funcionamiento del sistema, tan sólo habría que definir la contraseña de administrador, en zimbra-store (3) => admin password (4). No obstante, sería adecuado configurar las contraseñas de administración de LDAP y los demás servicios del menú zimbra-ldap (2). Para ello configuramos adecuadamente las opciones:

ldap root password (4)

ldap replication password (5)

ldap postfix password (6)

ldap amavis password (7)

ldap nginx password (8) Podemos definir la zona horaria en common configuration (1) => timezone (6), aunque

3) zimbra-store: Enabled +Status Enabled +Create Admin User: yes +Admin user to create: [email protected] ******* +Admin Password UNSET +Anti-virus quarantine user: [email protected] +Enable automated spam training: yes +Spam training user [email protected] +Non-spam(Ham) training user: [email protected] +SMTP host: mailhost.example.com +Web server HTTP port: 80 +Web server HTTPS port: 443 +Web server mode: http +IMAP server port: 143 +IMAP server SSL port: 993 +POP server port: 110 +POP server SSL port: 995 +Use spell check server: yes +Spell server URL: http://mailhost.example.com:7780/aspell.php +Configure for use with mail proxy: FALSE +Configure for use with web proxy: FALSE +Enable version update checks: TRUE +Enable version update notifications: TRUE +Version update notification email: [email protected] +Version update source email: [email protected]

4) zimbra-mta: Enabled 5) zimbra-snmp: Enabled 6) zimbra-logger: Enabled 7) zimbra-spell: Enabled 8) zimbra-convertd: Enabled 9) Default Class of Service Configuration: 10) Enable default backup schedule: yes c) Collapse menu r) Start servers after configuration: yes s) Save config to file q) Quit

5. Implementación

25

también se puede ajustar posteriormente. Finalmente, en zimbra-ldap (2) => domain to create (3) tenemos el nombre de dominio que se va a crear. Al acabar, pulsamos la opción apply (letra a), que solo aparecerá cuando no haya líneas marcadas con ****. Al concluir la instalación, estaría instalado y funcionando el servidor de correo electrónico de Zimbra. La información básica para poder gestionarlo:

Estado del servicio. Ejecutando:

Parar el servicio. Ejecutando:

Iniciar el servicio. Ejecutando:

Reiniciar el servicio. Ejecutando:

Interfaz de usuario:

Consola de administración:

service zimbra status

service zimbra stop

service zimbra start

service zimbra restart

http://mailhost.example.com/

https://mailhost.example.com:7071/zimbraAdmin/

PFC – SME del CdC

26

Instalación e integración de mailman

Como se ha comentado en el diseño de la solución, se va a integrar mailman con Zimbra. Para ello, será necesario tener el siguiente script:

/root/mailman.sh (permisos 777)


#!/bin/sh # Script para la instalacion de mailman con zimbra if [ $# -gt "1" ]; then echo "USO: instalacionmailman.sh" echo "ejemplo: instalacionmailman.sh (para un unico servidor en el sistema)" echo "USO: instalacionmailman.sh nombre_servidor" echo "ejemplo: instalacionmailman.sh servidor.dominio.com" else #******************* Nombre del servidor ********************* if [ $# -eq "0" ]; then SERVIDOR=$(sudo -u zimbra /opt/zimbra/bin/zmprov gad) echo "Mailman se instalara para el siguiente servidor:" echo $SERVIDOR echo "si es correcto pulse ENTER, si no CONTROL-C" echo "y ejecute: instalacionmailman.sh nombre_servidor" read variable else SERVIDOR=$1 fi echo $SERVIDOR #************************************************************* apt-get update apt-get install python-dev make chkconfig adduser --no-create-home --disabled-login mailman #***************** Instalacion de mailman ******************* cd /usr/local/ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.14-1.tgz #procede si el tamano de la instalacion de mailman es correcto if [ $(ls -l mailman-2.1.14-1.tgz | awk '{print $5-8201307}') -eq "1" ]; then mkdir mailman chgrp mailman mailman chmod a+rx,g+ws mailman tar xvfz mailman-2.1.14-1.tgz cd mailman-2.1.14-1 ./configure --with-cgi-gid=zimbra make install cd / rm /usr/local/mailman-2.1.14-1.tgz rm -r /usr/local/mailman-2.1.14-1 #*************************************************************** cd /usr/local/mailman/archives chown zimbra private chmod o-x private /usr/local/mailman/bin/check_perms -f /usr/local/mailman/bin/check_perms -f cp /opt/zimbra/conf/httpd.conf /opt/zimbra/conf/httpd.confBK #*************** Modificacion de httpd.conf ******************** echo "ServerName ${SERVIDOR}" >> /etc/apache2/httpd.conf echo >> /opt/zimbra/conf/httpd.conf echo "ScriptAlias /mailman/ /usr/local/mailman/cgi-bin/" >> /opt/zimbra/conf/httpd.conf

5. Implementación

27


echo >> /opt/zimbra/conf/httpd.conf echo "<Directory /mailman/>" >> /opt/zimbra/conf/httpd.conf echo "AllowOverride None" >> /opt/zimbra/conf/httpd.conf echo "Options ExecCGI" >> /opt/zimbra/conf/httpd.conf echo "Order allow,deny" >> /opt/zimbra/conf/httpd.conf echo "Allow from all" >> /opt/zimbra/conf/httpd.conf echo "</Directory>" >> /opt/zimbra/conf/httpd.conf echo >> /opt/zimbra/conf/httpd.conf echo "Alias /pipermail/ /usr/local/mailman/archives/public/" >> /opt/zimbra/conf/httpd.conf echo >> /opt/zimbra/conf/httpd.conf echo "<Directory /pipermail/>" >> /opt/zimbra/conf/httpd.conf echo "Options Indexes MultiViews FollowSymLinks" >> /opt/zimbra/conf/httpd.conf echo "AllowOverride None" >> /opt/zimbra/conf/httpd.conf echo "Order allow,deny" >> /opt/zimbra/conf/httpd.conf echo "Allow from all" >> /opt/zimbra/conf/httpd.conf echo "</Directory>" >> /opt/zimbra/conf/httpd.conf echo >> /opt/zimbra/conf/httpd.conf echo "RedirectMatch ^/mailman[/]*$ http://${SERVIDOR}:7780/mailman/listinfo" >> /opt/zimbra/conf/httpd.conf echo >> /opt/zimbra/conf/httpd.conf chown zimbra:zimbra /opt/zimbra/conf/httpd.conf chmod 444 /opt/zimbra/conf/httpd.conf #************************************************************** cd /opt/zimbra/httpd/htdocs mkdir mmimages cp /usr/local/mailman/icons/* mmimages/ sudo -u zimbra /opt/zimbra/bin/zmapachectl stop sudo -u zimbra /opt/zimbra/bin/zmapachectl start cp /opt/zimbra/postfix/conf/main.cf /opt/zimbra/postfix/conf/main.cfBK #***************** Modificacion de main.cf ******************** cat /opt/zimbra/postfix/conf/main.cf | awk '{if($1=="virtual_alias_maps"){ print "virtual_alias_maps = ldap:/opt/zimbra/conf/ldap-vam.cf"} else{ print $0}}' > prueba.txt mv prueba.txt /opt/zimbra/postfix/conf/main.cf cat /opt/zimbra/postfix/conf/main.cf | awk '{if($1=="alias_maps"){ print "alias_maps = hash:/etc/aliases,hash:/usr/local/mailman/data/aliases"} else{ print $0}}' > prueba.txt mv prueba.txt /opt/zimbra/postfix/conf/main.cf chown zimbra:zimbra /opt/zimbra/postfix/conf/main.cf chmod 644 /opt/zimbra/postfix/conf/main.cf #************************************************************** echo >> /usr/local/mailman/Mailman/mm_cfg.py echo "MTA = 'Postfix'" >> /usr/local/mailman/Mailman/mm_cfg.py echo "POSTFIX_ALIAS_CMD = '/opt/zimbra/postfix/sbin/postalias'" >> /usr/local/mailman/Mailman/mm_cfg.py echo "POSTFIX_MAP_CMD = '/opt/zimbra/postfix/sbin/postmap'" >> /usr/local/mailman/Mailman/mm_cfg.py echo "IMAGE_LOGOS = '/mmimages/'" >> /usr/local/mailman/Mailman/mm_cfg.py echo "DEFAULT_URL_PATTERN = 'http://%s:7780/mailman/'" >> /usr/local/mailman/Mailman/mm_cfg.py /usr/local/mailman/bin/newlist mailman /usr/local/mailman/bin/config_list -i /usr/local/mailman/data/sitelist.cfg mailman /usr/local/mailman/bin/genaliases /opt/zimbra/postfix-2.7.4.2z/sbin/newaliases

PFC – SME del CdC

28

Basta con ejecutarlo y seguir las instrucciones para la correcta instalación de mailman y su integración con Zimbra.

chown mailman:mailman /usr/local/mailman/data/aliases* chown mailman:mailman /usr/local/mailman/data/virtual-mailman* cd /usr/local/mailman/cron crontab -u mailman crontab.in cp /usr/local/mailman/scripts/mailman /etc/init.d chkconfig --add mailman cp /opt/zimbra/conf/zmmta.cf /opt/zimbra/conf/zmmta.cfBK #***************** Modificacion de zmmta.cf ******************** cat /opt/zimbra/conf/zmmta.cf | awk '{if($0=="\t\tPOSTCONF mydestination VAR zimbraMtaMyDestination"){ print "\t\tPOSTCONF mydestination LOCAL postfix_mydestination"} else{ print $0}}' > prueba.txt mv prueba.txt /opt/zimbra/conf/zmmta.cf cat /opt/zimbra/conf/zmmta.cf | awk '{if($1=="POSTCONF" && $2=="alias_maps"){ print "#"$0} else{ print $0}}' > prueba.txt mv prueba.txt /opt/zimbra/conf/zmmta.cf chown zimbra:zimbra /opt/zimbra/conf/zmmta.cf chmod 444 /opt/zimbra/conf/zmmta.cf #************************************************************** /etc/init.d/mailman stop; /etc/init.d/mailman start /etc/init.d/zimbra stop; /etc/init.d/zimbra start echo "sudo -u zimbra /opt/zimbra/bin/zmlocalconfig -e postfix_mydestination='localhost ${SERVIDOR}'" > /1.txt sh /1.txt rm /1.txt else echo "Error en la descarga" fi clear echo "Instalacion correcta" echo "Puede comprobar el correcto funcionamiento del servicio en la url:" echo "http://${SERVIDOR}:7780/mailman/listinfo" fi

5. Implementación

29

Instalación de Z-Push

Como se ha comentado en el diseño de la solución, se va a hacer uso de Z-Push para el intercambio con dispositivos móviles. En una instalación básica de Zimbra, Z-Push deberá ser instalado en otro servidor distinto al de Zimbra. Para la instalación, puede hacerse uso del siguiente script, teniendo apache2 ya instalado:

/root/z-push.sh (permisos 777)


#!/bin/sh cd /root/; mkdir zpushTempinstall; cd zpushTempinstall apt-get install -y subversion php5-curl mkdir /var/www/z-push svn checkout svn://svn.berlios.de/z-push/branches/as12.1 /var/www/z-push mkdir /var/www/z-push/zimbra svn checkout https://zimbrabackend.svn.sourceforge.net/svnroot/zimbrabackend/zimbra-backend/branches/as12.1 /var/www/z-push/zimbra mkdir /var/www/z-push/backend-old mv /var/www/z-push/backend/* /var/www/z-push/backend-old mv /var/www/z-push/backend-old/backend.php /var/www/z-push/backend/ mv /var/www/z-push/backend-old/diffbackend.php /var/www/z-push/backend/ mv /var/www/z-push/zimbra/zimbra.php /var/www/z-push/backend/ chgrp www-data /var/www/z-push/state chmod g+w /var/www/z-push/state touch /var/www/z-push/debug.txt chmod 777 /var/www/z-push/debug.txt #ajusta configuracion de z-push para usar el backend de zimbra fechaunica1=`date +%s` sleep 1 fechaunica2=`date +%s` touch $fechaunica1 touch $fechaunica2 cat /var/www/z-push/config.php | awk '{if($1!="$BACKEND_PROVIDER"){print $0}else{print "\t$BACKEND_PROVIDER = \"BackendZimbra\";"}}' > $fechaunica1 cat $fechaunica1 | sed 's/Europe\/Berlin/Europe\/Madrid/g' > $fechaunica2 cat $fechaunica2 | awk -F \' '{if($2!="PROVISIONING"){print $0}else{print $1"\x27"$2"\x27, false);"}}' > $fechaunica1 cat $fechaunica1 | awk '{if($1!="?>"){print $0}else{}}' > $fechaunica2 echo "define('ZIMBRA_DEBUG',true);" >> $fechaunica2 echo "define('ZIMBRA_URL', 'https://mbxetsi.us.es');" >> $fechaunica2 echo "define('ZIMBRA_USER_DIR', 'zimbra');" >> $fechaunica2 echo "define('ZIMBRA_SYNC_CONTACT_PICTURES', true);" >> $fechaunica2 echo "define('ZIMBRA_VIRTUAL_CONTACTS',true);" >> $fechaunica2 echo "define('ZIMBRA_VIRTUAL_APPOINTMENTS',true);" >> $fechaunica2 echo "define('ZIMBRA_VIRTUAL_TASKS',true);" >> $fechaunica2 echo "define('ZIMBRA_IGNORE_EMAILED_CONTACTS',true);" >> $fechaunica2 echo "define('ZIMBRA_HTML',true);" >> $fechaunica2 echo >> $fechaunica2 echo "?>" >> $fechaunica2 cat $fechaunica2 > /var/www/z-push/config.php rm $fechaunica1; rm $fechaunica2 #sitio disponible z-push con puerto 80 echo "<VirtualHost *:80>" > /etc/apache2/sites-available/z-push echo "ServerAdmin [email protected]" >> /etc/apache2/sites-available/z-push echo "ServerName etsi.us.es" >> /etc/apache2/sites-available/z-push echo >> /etc/apache2/sites-available/z-push echo "DirectoryIndex index.php" >> /etc/apache2/sites-available/z-push echo "DocumentRoot /var/www/z-sync/" >> /etc/apache2/sites-available/z-push echo "Alias /Microsoft-Server-ActiveSync /var/www/z-sync/index.php" >> /etc/apache2/sites-available/z-push

PFC – SME del CdC

30


echo >> /etc/apache2/sites-available/z-push echo "<Directory />" >> /etc/apache2/sites-available/z-push echo "AllowOverride All" >> /etc/apache2/sites-available/z-push echo "</Directory>" >> /etc/apache2/sites-available/z-push echo >> /etc/apache2/sites-available/z-push echo "php_flag magic_quotes_gpc off" >> /etc/apache2/sites-available/z-push echo "php_flag register_globals off" >> /etc/apache2/sites-available/z-push echo "php_flag magic_quotes_runtime off" >> /etc/apache2/sites-available/z-push echo "php_flag short_open_tag on" >> /etc/apache2/sites-available/z-push echo >> /etc/apache2/sites-available/z-push echo "ErrorLog /var/log/apache2/z-sync/error.log" >> /etc/apache2/sites-available/z-push echo "CustomLog /var/log/apache2/z-sync/access.log combined" >> /etc/apache2/sites-available/z-push echo "</VirtualHost>" >> /etc/apache2/sites-available/z-push #sitio disponible z-push con SSL y puerto 443 echo "<IfModule mod_ssl.c>" > /etc/apache2/sites-available/z-push_ssl echo "<VirtualHost _default_:443>" >> /etc/apache2/sites-available/z-push_ssl echo "ServerAdmin [email protected]" >> /etc/apache2/sites-available/z-push_ssl echo "ServerName etsi.us.es" >> /etc/apache2/sites-available/z-push_ssl echo "DirectoryIndex index.php" >> /etc/apache2/sites-available/z-push_ssl echo "DocumentRoot /var/www/z-push/" >> /etc/apache2/sites-available/z-push_ssl echo "Alias /Microsoft-Server-ActiveSync /var/www/z-push/index.php" >> /etc/apache2/sites-available/z-push_ssl echo "" >> /etc/apache2/sites-available/z-push_ssl echo "<Directory />" >> /etc/apache2/sites-available/z-push_ssl echo "AllowOverride None" >> /etc/apache2/sites-available/z-push_ssl echo "</Directory>" >> /etc/apache2/sites-available/z-push_ssl echo "" >> /etc/apache2/sites-available/z-push_ssl echo "php_flag magic_quotes_gpc off" >> /etc/apache2/sites-available/z-push_ssl echo "php_flag register_globals off" >> /etc/apache2/sites-available/z-push_ssl echo "php_flag magic_quotes_runtime off" >> /etc/apache2/sites-available/z-push_ssl echo "php_flag short_open_tag on" >> /etc/apache2/sites-available/z-push_ssl echo "" >> /etc/apache2/sites-available/z-push_ssl echo "ErrorLog /var/log/apache2/z-push/error.log" >> /etc/apache2/sites-available/z-push_ssl echo "CustomLog /var/log/apache2/z-push/access.log combined" >> /etc/apache2/sites-available/z-push_ssl echo "" >> /etc/apache2/sites-available/z-push_ssl echo "SSLEngine on" >> /etc/apache2/sites-available/z-push_ssl echo "SSLCertificateFile /etc/apache2/ssl/web.crt" >> /etc/apache2/sites-available/z-push_ssl echo "SSLCertificateKeyFile /etc/apache2/ssl/server.key" >> /etc/apache2/sites-available/z-push_ssl echo "SSLCertificateChainFile /etc/apache2/ssl/ca.crt" >> /etc/apache2/sites-available/z-push_ssl echo "" >> /etc/apache2/sites-available/z-push_ssl echo "SSLCACertificateFile /etc/apache2/ssl/ca.crt" >> /etc/apache2/sites-available/z-push_ssl echo "" >> /etc/apache2/sites-available/z-push_ssl echo "</VirtualHost>" >> /etc/apache2/sites-available/z-push_ssl echo "</IfModule>" >> /etc/apache2/sites-available/z-push_ssl echo "" >> /etc/apache2/sites-available/z-push_ssl #activa por defecto el seguro y pasa a generar los certificados cd /etc/apache2/sites-enabled ln -s ../sites-available/z-push_ssl z-push_ssl #activa el modulo ssl y php cd /etc/apache2/mods-enabled ln -s ../mods-available/ssl.conf ssl.conf ln -s ../mods-available/ssl.load ssl.load if [ -e /etc/apache2/mods-available/php5.conf ]; then echo > /dev/null else

5. Implementación

31


echo "<IfModule mod_php5.c>" > /etc/apache2/mods-available/php5.conf echo " AddType application/x-httpd-php .php .phtml .php3" >> /etc/apache2/mods-available/php5.conf echo " AddType application/x-httpd-php-source .phps" >> /etc/apache2/mods-available/php5.conf echo "</IfModule>" >> /etc/apache2/mods-available/php5.conf fi if [ -e /etc/apache2/mods-available/php5.load ]; then echo > /dev/null else echo "LoadModule php5_module /usr/lib/apache2/modules/libphp5.so" > /etc/apache2/mods-available/php5.load fi ln -s ../mods-available/php5.conf php5.conf ln -s ../mods-available/php5.load php5.load rm /etc/apache2/sites-available/default-ssl echo "La instalacion de z-push ha finalizado correctamente para el puerto 443, mediante SSL" echo "Si desea generar los certificados autofirmados para poder usar apache con SSL pulse cualquier tecla" echo "En caso contrario, pulse CONTROL+C para salir." read variable #generacion de certificados mkdir /root/ssl cd /root/ssl echo "Generamos la clave de CA:"; echo "Se debe introducir una clave cuando se solicite"; echo openssl genrsa -des3 -out ca.key 2048 echo; echo "Proceso de generación de clave de CA finalizado. Pulse para continuar..." read variable clear echo "Generamos el certificado de CA:"; echo "Se debe introducir la clave anterior cuando se solicite"; echo openssl req -new -x509 -days 3650 -key ca.key -out ca.crt echo; echo "Proceso de generación de certificado de CA finalizado. Pulse para continuar..." read variable clear echo "Generamos la clave de servidor:"; echo "Se debe introducir una clave cuando se solicite"; echo openssl genrsa -des3 -out server.key 1024 echo; echo "Proceso de generación de clave de servidor finalizado. Pulse para continuar..." read variable clear echo "Generamos la peticion de certificado de servidor:"; echo "IMPORTANTE: "Common name" debe ser el nombre FQDN del servidor"; echo openssl req -new -key server.key -out web.csr echo; echo "Proceso de generación de peticion de certificado de servidor finalizado. Pulse para continuar..." read variable clear echo "Generamos el certificado de servidor:"; echo "Se debe introducir la clave anterior cuando se solicite"; echo openssl x509 -req -in web.csr -out web.crt -sha1 -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650 echo; echo "Proceso de generación de certificado de servidor finalizado. Pulse para continuar..." read variable; clear mv server.key server.key.secure echo "Reducimos la seguridad de la clave para poder cargar el servicio sin interaccion humana:"; echo "Se debe introducir la clave anterior cuando se solicite"; echo

PFC – SME del CdC

32

openssl rsa -in server.key.secure -out server.key echo; echo "Proceso finalizado. Pulse para continuar..." read variable chmod 0400 *.key mkdir /etc/apache2/ssl cp web.crt /etc/apache2/ssl/web.crt cp ca.crt /etc/apache2/ssl/ca.crt cp server.key /etc/apache2/ssl/server.key service apache2 restart clear echo "Proceso completado."

5. Implementación

33

Tamaño de la instalación

Zimbra nos facilita el cálculo del espacio requerido por una instalación para la cual se haya fijado el tamaño de buzón por usuario y el número de usuarios. Así, suponiendo 200 usuarios y buzones de 0,5 GB, se necesitarían aproximadamente:

Concepto Cálculo Resultado Datos de usuario Número de usuarios × tamaño de

buzón 100 GB

Datos necesarios por MySQL

5% del tamaño de datos de usuario 5 GB

Instalación de Zimbra Tamaño fijo 10 GB Registros de Zimbra (logs) Tamaño fijo 20 GB Índices de Zimbra 25% del tamaño de datos de usuario 25 GB TOTAL 160 GB

Tabla 2: Tamaño necesario para la instalación de Zimbra

PFC – SME del CdC

34

Virtualización

Para la virtualización se ha recurrido a VMware (http://www.vmware.com), y en concreto al producto ESXi 4.1 que es gratuito y no presenta limitaciones importantes para el objetivo perseguido frente a otras versiones (ESX, por ejemplo). Existe una versión superior, la 5.0, pero incluye una limitación de uso de la memoria RAM del hipervisor de 8 GB, lo cual no resulta adecuado ya que los equipos que van a ser utilizados cuentan con 24 GB de RAM. La decisión de emplear VMware frente a otras técnicas de virtualización (como Xen o Hyper-V) no está fundamentada en que Zimbra sea propiedad de VMware. En el Centro de Cálculo ya se había usado VMware con éxito y es por ello por lo que se prefiere seguir con su utilización. Para la instalación de ESXi 4.1 en un equipo, es necesario seguir los siguientes pasos:

1. Registrarse en la página de VMware. 2. Acceder al producto (ESXi 4.1). 3. Solicitar el uso de este producto para nuestra cuenta. Nos facilitará un número de serie que

nos permitirá activar el producto de manera gratuita y para su uso indefinido. 4. Descargar la instalación de VMware en un archivo ISO. 5. Grabación del archivo ISO en un CD (o memoria USB) e instalación en el equipo (a partir de

ahora hipervisor). 6. Una vez instalado siguiendo los pasos indicados en la instalación es necesario definirle una

contraseña de administrador. 7. Posteriormente, se puede descargar el cliente vSphere Client 4.1 desde la interfaz web que

presenta el hipervisor instalado. Para acceder a ella basta con acceder a https://iphipervisor/, donde iphipervisor será la IP que se le haya asignado al hipervisor en la instalación. Al acceder, se mostrará lo siguiente:

Ilustración 19: Logo VMWare

http://www.vmware.com/

https://iphipervisor/

5. Implementación

35

vSphere Cliente permitirá gestionar completamente el hipervisor. Podrán crearse nuevas máquinas virtuales, arrancarlas o detenerlas, reiniciarlas, cambiar su hardware asociado, etc. Además facilitará la gestión del hipervisor: cómo se distribuye su espacio de almacenamiento, cómo mapea la red y las distintas máquinas virtuales, etc. También es interesante, desde el equipo físico, acceder a la consola de comandos, pulsando ALT + F1. Para activar esta opción hay que acceder como root en ALT + F2, ir a Troubleshooting options:

y pulsar sobre Enable Local Tech Support:

Ahora, en ALT + F1, es necesario autenticarse (como root, por ejemplo). Una vez aquí, se

Ilustración 20: Página web mostrada al acceder a: https://iphipervisor/

Ilustración 21: Página principal de configuración del hipervisor

Ilustración 22: Habilitación de la consola de comandos del hipervisor

PFC – SME del CdC

36

puede activar el servidor de SSH para un determinado puerto de la siguiente manera:

1. Acceder al archivo de configuración de red.

2. Editar (presionar INSERTAR) las líneas 5 y 6 eliminando # del principio.

/etc/inetd.conf

3. Guardar y salir (presionar ESC, luego :wq e INTRO). 4. Acceder al archivo de los servicios y puertos.

5. Editar las líneas 45 y 46 cambiando el número de puerto por el deseado.

/etc/services

6. Guardar y salir. 7. Reiniciar la red en el hipervisor con:

Este proceso nos permitirá acceder al hipervisor por SSH y ejecutar ciertos comandos, sin necesidad de hacer uso de vSphere Client que únicamente está disponible para Windows.

vi /etc/inetd.conf

-# ssh stream tcp nowait root /sbin/dropbearmulti \ - dropbear ++min=0,swap,group=shell -w -i -K60 + ssh stream tcp nowait root /sbin/dropbearmulti \ + dropbear ++min=0,swap,group=shell -w -i -K60 -# ssh stream tcp nowait urp /sbin/dropbearmulti \ - dropbear ++min=0,swap,group=shell -i -K60 + ssh stream tcp nowait urp /sbin/dropbearmulti \ + dropbear ++min=0,swap,group=shell -i -K60

vi /etc/services

- ssh 22/tcp # SSH Remote Login Protocol + ssh 55443/tcp # SSH Remote Login Protocol - ssh 22/udp # SSH Remote Login Protocol + ssh 55443/udp # SSH Remote Login Protocol

kill -HUP `ps | grep inetd | awk '{print $1}'`

5. Implementación

37

Alta disponibilidad

Introducción

La alta disponibilidad, como se explica en el marco teórico, hace uso de dos recursos compartidos, un sistema de ficheros común y una IP de servicio. Ambos, deben estar disponibles a ambos equipos y deben conmutar en caso de fallo de uno de los equipos.

Para la conmutación y para la IP del servicio se ha decidido usar HEARTBEAT, que cumple a la perfección con las exigencias del escenario y los requisitos demandados.

Para el sistema de ficheros común se ha decidido usar DRBD + GFS2. DRBD se ajusta al funcionamiento necesitado por sí solo. Su utilización en conjunto con GFS2 está muy por encima en prestaciones demandadas. Aún así, se emplea con esta configuración para garantizar, sin coste adicional, que, antes cualquier situación posible, no se producirá corrupción en el sistema de ficheros.

En lo que sigue, se va a analizar la configuración de alta disponibilidad diseñada para este sistema de mensajería electrónica. Siempre se consideran dos equipos que va a compartir recursos (IP de servicio y datos necesarios para la prestación del servicio). Lo visto en este apartado será usado como pieza clave en la constitución del sistema final.

PFC – SME del CdC

38

Heartbeat

Para conseguir la conmutación de recursos, necesaria en la alta disponibilidad, se ha hecho uso de la aplicación heartbeat (http://linux-ha.org/wiki/Heartbeat), parte del proyecto Linux-HA, con licencia GNU GPL. Para instalar heartbeat para Ubuntu, basta con ejecutar como root:

que realiza la instalación de los siguientes paquetes: cluster-agents, cluster-glue, gawk,

heartbeat, libcluster-glue, libcorosync4, libesmtp5, libheartbeat2, libnet1, libopenhpi2, libopenipmi0,

openhpid y pacemaker.

Una vez instalado, la configuración de heartbeat se controla con los siguientes ficheros:

/etc/ha.d/authkeys: Almacena la información que intercambiarán los equipos para garantizar una comunicación segura entre ellos y evitar la suplantación de identidad por parte de un tercero. Este fichero deberá ser idéntico en ambos equipos. La configuración mínima de seguridad será la siguiente:

/etc/ha.d/authkeys

/etc/ha.d/ha.cf: Contiene los parámetros de configuración del funcionamiento de heartbeat; direcciones IP, interfaces, tiempos de espera, etc. Este fichero será distinto en los dos equipos. Para la prestación del servicio en el escenario en el que nos encontramos, se ha optado por la siguiente configuración:

vm1:/etc/ha.d/ha.cf

Ilustración 23: Logo Heartbeat

apt-get install heartbeat

auth 1 1 crc 2 sha1 HI! 3 md5 Hello!

debugfile /var/log/ha-debug #nombre del log debug logfile /var/log/ha-log #nombre del log de heartbeat logfacility local0 #configuración para el log del sistema keepalive 2 #tiempo del latido en segundos deadtime 12 #tiempo en declarar al otro muerto initdead 18 #tiempo antes de emprender acciones udpport 694 #puerto udp para la comunicación ucast eth0 192.168.137.2 #interfaz local e ip del nodo opuesto auto_failback on #cederá su puesto si el primario está node vm1 #nombre del primer equipo = hostname node vm3 #nombre del segundo equipo = hostname

http://linux-ha.org/wiki/Heartbeat

5. Implementación

39

Para el otro equipo, el fichero sería el siguiente:

vm2:/etc/ha.d/ha.cf

/etc/ha.d/haresources: Contiene información sobre los recursos compartidos (IPs, sistema de ficheros, scripts contenidos en /etc/init.d que se ejecutarán con start o stop, etc.) y qué equipo será el que los ejecutará por defecto (primario). Este fichero deberá ser idéntico en ambos equipos. En nuestro escenario, este fichero contendrá la siguiente información:

/etc/ha.d/haresources

Con esta configuración el funcionamiento sería el siguiente:

Si ambos equipos están activos y: ◦ vm2 se vuelve indisponible: No ocurre nada, ya que está como primario el equipo vm1.

Perderíamos la redundancia que nos aporta el segundo equipo, pero el servicio no se vería afectado. ▪ Después, el equipo vm2 vuelve a estar disponible: Tampoco sucede nada de cara al

servicio, aunque volveríamos a tener la protección del segundo equipo. ◦ vm1 se vuelve indisponible: vm2 lo detecta y asume el control del servicio.

▪ vm1 ejecutará, si puede: 1. /etc/init.d/zimbra stop, parando el servicio Zimbra. 2. Desvincula la IP 172.16.1.201/22 de su interfaz eth1. 3. Desmonta el sistema de ficheros /dev/drbd0 del directorio /opt. 4. Cambia el equipo a secundario en el servicio drbd.

▪ vm3 ejecutará: 1. Cambia el equipo a primario en el servicio drbd. 2. Monta el sistema de ficheros /dev/drbd0 en el directorio /opt. 3. Vincula la IP 172.16.1.201/22 a su interfaz eth1. 4. /etc/init.d/zimbra start, iniciando el servicio Zimbra.

debugfile /var/log/ha-debug #nombre del log debug logfile /var/log/ha-log #nombre del log de heartbeat logfacility local0 #configuración para el log del sistema keepalive 2 #tiempo del latido en segundos deadtime 12 #tiempo en declarar al otro muerto initdead 18 #tiempo antes de emprender acciones udpport 694 #puerto udp para la comunicación ucast eth0 192.168.137.1 #interfaz local e ip del nodo opuesto auto_failback on #cederá su puesto si el primario está node vm1 #nombre del primer equipo = hostname node vm3 #nombre del segundo equipo = hostname

vm1 drbddisk::all Filesystem::/dev/drbd0::/opt::gfs2::rw \ IPaddr::172.16.1.201/22/eth1 zimbra #parámetros en orden, separados por espacios: #nombre del equipo primario #recursos compartidos ordenados, donde a la hora de: # + tomar el servicio se ejecutarían de izquierda a derecha # (los scripts con start) # + abandonar el servicio, se ejecutarían de derecha a izquierda # (los scripts con stop) #para sistemas de ficheros: #drbddisk::nombre_recurso_drbd (o all para todos) #Filesystem::nombre_fisico::punto_de_montaje::tipo::tipo_de_montaje #para IPs: #Ipaddr::valor_IP/mascara/interfaz_fisica

PFC – SME del CdC

40

Si vm3 funciona y es quién controla el servicio: y ◦ vm1 se vuelve disponible: vm1 recupera el control

▪ vm3 parará los scripts con stop y abandonará la IP y el sistema de ficheros en favor de vm1 debido a la cláusula “auto_failback on” de su fichero /etc/ha.d/ha.cf.

▪ vm1 tomará los recursos y arrancará los scripts con start. De esta forma, el paso del testigo del servicio y de la inicialización de todos los recursos necesarios para ejecutar el servicio corren a cuenta de heartbeat.

5. Implementación

41

Watchdog

Watchdog (http://watchdog.sourceforge.net/) es una herramienta software que

monitoriza recursos, y en caso de que alguno de ellos falle, reinicia el equipo. Debidamente utilizado, es el complemento perfecto de heartbeat. Así, heartbeat fija el rol al equipo que esté activo y watchdog reestablece el equipo que deje de estar activo por un fallo en algún servicio monitorizado. En conjunto, mantendrán:

1. El servicio activo siempre (excepto el tiempo de cambio entre máquinas, aproximadamente

3 o 4 minutos). 2. Los equipos, el mayor tiempo posible activos y listos para prestar el servicio.

Para instalar watchdog para Ubuntu, basta con ejecutar como root:

Posteriormente, será necesario ejecutar lo siguiente:

Finalmente, se podrán configurar todos los recursos susceptibles de ser monitorizados,

en /etc/watchdog.conf. Un ejemplo de esto será tratado más adelante, en la instalación completa del sistema.

apt-get install watchdog

echo "file = /var/log/messages" >> /etc/watchdog.conf echo "watchdog-device = /dev/watchdog" >> /etc/watchdog.conf /sbin/modprobe softdog echo 'softdog' >> /etc/modules

http://watchdog.sourceforge.net/

PFC – SME del CdC

42

DRBD (Distributed Replicated Block Device)

Para conseguir un sistema de ficheros compartido, se ha hecho uso de la aplicación DRBD (http://www.drbd.org/), de LINBIT, con licencia GNU GPL. DRBD mantiene sincronizadas dos particiones del mismo tamaño en equipos distintos unidos por sus interfaces de red, como se muestra en la siguiente figura:

En el marco teórico, se analizó que la situación básica para un sistema de alta disponibilidad con un sistema de ficheros compartido, debía responder a la siguiente estructura:

Ilustración 24: Logo DRBD

Ilustración 26: Esquema fundamental de alta disponibilidad

Ilustración 25: Esquema de funcionamiento de DRBD

http://www.drbd.org/

5. Implementación

43

Este modelo puede ser satisfecho, empleando DRBD, de la siguiente manera:

Es decir, un sistema de ficheros externo de común acceso a ambos se sustituye por una partición local a cada equipo, sincronizadas mediante DRBD y montada sólo para el equipo que esté prestando el servicio. Este método tiene numerosas ventajas:

DRBD es un sistema estable, muy probado y con una documentación muy extensa.

Disminuye el tiempo de acceso con respecto a cualquier recurso remoto, ya sea para escritura o lectura, debido a que los accesos realizan de forma local.

Hace uso de roles (primario y secundario) facilitando que un sistema configurado con un rol pueda cambiarlo y actuar con otro.

En la configuración de este sistema en concreto, es totalmente transparente al servicio. Debido a que sólo uno de los dos equipos estará como activo, el transvase de información será en un solo sentido, hacia el pasivo. Este equipo no estará esperando los datos del otro, por lo que no habrá bloqueo. Este hecho implica que cualquier posible retardo introducido por la red será inocuo ya que se producirá sobre el equipo pasivo.

Permite tener dos equipos completamente autónomos en caso de fallo irrecuperable de uno de ellos.

Permite una copia de seguridad del sistema. Para ello sólo habría que parar y aislar el equipo que no da el servicio y realizar una copia completa de todo el sistema mientras el otro sigue prestando el servicio.

Para instalar DRBD en Ubuntu, hay que instalar una serie de paquetes necesarios y para ello hay que ejecutar como root:

apt-get install ethstats dpatch patchutils cogito git-core sp apt-get install docbook-utils docbook build-essential flex dpkg-dev apt-get install fakeroot module-assistant apt-get install drbd8-utils

Ilustración 27: Solución que aporta DRBD a la alta disponibilidad

PFC – SME del CdC

44

Una vez instalado, la configuración de DRBD se encuentra en el siguiente fichero:

/etc/drbd.conf: Contiene toda la información que necesita DRBD para el funcionamiento del servicio:

/etc/drbd.conf

Una vez instalado y configurado DRBD necesita ejecutar una serie de comandos. Para ello, en primer lugar, hay que formatear la partición que se ha indicado en el fichero anterior. Aunque en principio cualquier sistema de ficheros (por ejemplo, EXT3) hubiera sido bastante, se ha decidido implementar GFS2 sobre DRBD.

global { usage-count no; } common { protocol C; syncer { rate 1000M; } #sincronización en función de disponibilidad } resource r0 { handlers { pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f"; pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f"; local-io-error "echo o > /proc/sysrq-trigger ; halt -f"; } startup { wfc-timeout 60; #tiempo de espera al inicio en segs degr-wfc-timeout 120; #tiempo de espera complementario } disk { on-io-error detach; } net { after-sb-0pri discard-zero-changes; after-sb-1pri discard-secondary; after-sb-2pri disconnect; rr-conflict disconnect; allow-two-primaries; #útil para el uso de gfs2 } syncer { rate 1000M; } on vm1 { device /dev/drbd0; #dispositivo creado disk /dev/sdb1; #dispositivo físico Address 192.168.137.1:7788; #dirección IP del equipo meta-disk internal; } on vm3 { device /dev/drbd0; #dispositivo creado disk /dev/sdb1; #dispositivo físico Address 192.168.137.2:7788; #dirección IP del equipo meta-disk internal; } }

5. Implementación

45

Actualización de DRBD

Se dispone de un repositorio con una versión de DRBD más actualizada (8.3.11 frente a

8.3.7) y con nuevas funciones, adecuada a la versión de linux que nos ocupa: Ubuntu Server 10.04.3 LTS. Para actualizar DRBD una vez instalado, basta con ejecutar el siguiente script:

/root/actualizadrbd8311.sh

Debido a la utilización de particiones de más de 16 TB (como se comentará más adelante), será necesario llevar a cabo esta actualización en nuestro sistema.

#!/bin/sh service drbd stop apt-get -y remove drbd8-utils apt-get -y install python-software-properties add-apt-repository ppa:numerigraphe/ppa apt-get update apt-get -y install drbd8-utils

PFC – SME del CdC

46

GFS2 (Global File System 2)

GFS2 es un sistema de ficheros, propiedad de Red Hat (http://www.redhat.com/gfs/), ideado para sistemas en cluster y acceso concurrente, distribuido bajo licencia GNU. La principal propiedad de este sistema de ficheros es que bloquea el acceso a un fichero mientras un equipo lo está escribiendo, evitando así que otro sistema escriba a la misma vez y los ficheros se corrompan. Para instalar GFS2 en Ubuntu, basta con ejecutar como root:

que realiza la instalación de los siguientes paquetes: cman, corosync, libccs3, libcman3,

libcorosync4, libdlm3, libdlmcontrol3, libfence4, liblogthread3, libnet-snmp-perl, libnet-telnet-perl,

libopenais3, libopenipmi0, libvirt0, libxen3, openais, openipmi, sg3-utils, libcrypt-des-perl, libdigest-hmac-

perl, libio-socket-inet6-perl y lvm2.

Una vez instalado, la configuración de GFS2 se encuentra en los siguientes ficheros (propios de cman y corosync):

/etc/cluster/cluster.conf: Este fichero de configuración es leído por cman al iniciarse. Por su parte, cman se encarga de iniciar el resto de demonios necesarios para el cluster, dándole así esta configuración a corosync:

/etc/cluster/cluster.conf

/etc/corosync/corosync.conf: Si corosync se inicia usando cman, como se ha comentado anteriormente, no es necesario configurar este fichero. No obstante, se indica aquí su configuración para nuestro escenario por si fuera necesario iniciarlo por separado:

Ilustración 28: Logo redhat

apt-get install gfs2-tools

<?xml version="1.0"?> <cluster name="clustermta" config_version="1"> <totem consensus="6000" token="3000"/> <clusternodes> <clusternode name="vm1" nodeid="1"> <fence></fence> </clusternode> <clusternode name="vm2" nodeid="2"> <fence></fence> </clusternode> </clusternodes> <cman expected_votes="1" two_node="1"/> <fencedevices> </fencedevices> <rm> </rm> </cluster>

http://www.redhat.com/gfs/

5. Implementación

47

/etc/corosync/corosync.conf

Se debe iniciar cman en ambos equipos:

Para hacer uso de GFS2 en el escenario que nos ocupa, se debe usar en combinación con DRBD.

totem { version: 2 token: 3000 token_retransmits_before_loss_const: 10 join: 60 consensus: 5000 vsftype: none max_messages: 20 clear_node_high_bit: yes secauth: off threads: 0 rrp_mode: none interface { ringnumber: 0 bindnetaddr: 192.168.137.1 mcastaddr: 192.168.137.3 mcastport: 5405 } } amf { mode: disabled } service { ver: 0 name: pacemaker } aisexec { user: root group: root } logging { fileline: off to_stderr: yes to_logfile: no to_syslog: yes syslog_facility: daemon debug: off timestamp: on logger_subsys { subsys: AMF debug: off tags: enter|leave|trace1|trace2|trace3|trace4|trace6 } }

/etc/init.d/cman start

PFC – SME del CdC

48

DRBD + GFS2

La conjunción de GFS2 con DRBD da como resultado una estructura muy robusta. Con ella se tiene acceso a una serie de características que no podrían conseguirse de otra forma. La más importante es que con esta configuración se puede crear un sistema de ficheros compartido por dos equipos permitiendo que ambos actúen como equipos primarios y compartan en tiempo real la información de dicho sistema. Este es el principal motivo por el que se ha elegido implementar GFS2 sobre DRBD en lugar de otro sistema de ficheros, aunque en nuestro escenario no se vaya a hacer uso de esta configuración. Al estar automatizados los procesos que implican cambio de roles en DRBD y montaje y desmontaje de particiones, es posible que en una situación inesperada ambos sistemas asuman el rol de primario. Si esto ocurriera sin estar haciendo uso de GFS2 se produciría corrupción en los datos con toda seguridad. Otro motivo para usar GFS2 es que ni EXT3 ni EXT4 son compatibles con particiones de más de 16 TB (como veremos que son las que aquí nos ocupan), sin embargo, GFS2 soporta hasta 100 TB en su última versión. Para instalar GFS2 sobre una partición sincronizada con DRBD hay que seguir los siguientes pasos:

1. En primer lugar, la partición elegida para el recurso de DRBD debe ser formateada en EXT3, por ejemplo. En los ficheros de configuración de DRBD se ve que esta partición es /dev/sdb1. Por tanto, en ambos equipos:

2. Posteriormente, hay que crear el recurso definido en DRBD, en ambos equipos, mediante:

3. Aunque se haya fijado el mismo tamaño en la partición de cada equipo, al ejecutar el

comando anterior, éste devolverá un error. Habrá que leer el valor sugerido en la línea:

y usarlo para ejecutar la siguiente instrucción, en ambos equipos, donde hay que substituir yyyyyyyy por el valor adecuado:

4. Una vez hecho esto, se podrá volver a ejecutar sin error, en ambos equipos, el comando:

5. Se debe iniciar drbd, en ambos equipos, mediante:

6. El estado inicial del recurso en ambos equipos será el de inconsistencia. Habrá que

establecer uno de los dos como primario. Así pues, en uno de los equipos únicamente:

Si al ejecutar este comando se obtuviera un error, podría usarse este otro alternativamente:

mkfs.ext3 /dev/sdb1

drbdadm create-md r0

... yyyyyyyy kB left usable by current configuration ...

e2fsck -f /dev/sdb1 && resize2fs /dev/sdb1 yyyyyyyyK

drbdadm create-md r0

/etc/init.d/drbd start

drbdadm primary r0

5. Implementación

49

7. Es necesario esperar a que se complete el paso anterior. Se puede visualizar el progreso y el

estado ejecutando en cualquiera de los dos equipos:

8. Una vez que ha aparecido UpToDate/UpToDate al ejecutar el comando anterior, se debe

formatear la partición al formato GFS2. Para ello, en el equipo establecido como primario:

donde cluster es el nombre asignado al cluster en el fichero de configuración cluster.conf, nombre es el nombre que tendrá esta partición dentro de ese cluster y el número a continuación de la opción -j indica cuántos equipos van a concurrir en el recurso, dos en este caso.

Al finalizar el paso anterior ya se encuentra disponible la estructura DRBD+GFS2. Para hacer uso de ella, se puede establecer un equipo como primario (o los dos) y montar el sistema de ficheros donde se desee. Sólo un sistema que esté establecido como primario en DRBD podrá efectuar el montaje de GFS2 y acceder a los ficheros. Para realizar el montaje, por ejemplo en /tmp, habrá que ejecutar el siguiente comando, siendo primario en DRBD:

Al llegar aquí, se tiene ya el elemento necesario para el diseño realizado del sistema final.

drbdadm -- --overwrite-data-of-peer primary all

cat /proc/drbd

mkfs.gfs2 -t cluster:nombre -p lock_dlm -j 2 /dev/drbd0

mount -t gfs2 /dev/drbd0 /tmp

PFC – SME del CdC

50

Configuración multiservidor

Se va a analizar cómo se realiza la instalación de ZCS OS 7.1.4 (Zimbra a partir de ahora) para varios servidores. Antes, es necesario evaluar la utilidad de hacer uso de una configuración multiservidor. Al utilizar la alta disponibilidad, se hace necesario emplear al menos dos equipos para permitir que uno sea redundante del otro. Pero si una máquina alberga todos los servicios, la otra permanece inactiva desaprovechando todos sus recursos. La mejor alternativa a este problema es dividir el servicio ofrecido, consiguiendo que ambos equipos ofrezcan el servicio en conjunción. La alta disponibilidad entonces, se consigue empleando la virtualización sobre los equipos para tener en cada uno dos máquinas virtuales. Así, en un equipo permanece una máquina virtual activa que forma parte del servicio y otra en espera, que sirve de redundancia a la máquina virtual activa del otro equipo. Para que todo esto sea una posibilidad real, es necesario poder desagrupar el servicio ofrecido en muchos otros que puedan ser repartidos en varios equipos. Zimbra permite repartir los distintos módulos que lo integran en varios servidores, con una configuración determinada, e incluye los mecanismos necesarios para comunicar los distintos servidores que conformen el servicio. Se implementará esta instalación sobre Ubuntu Server 10.04.3 LTS para 64 bits (http://www.ubuntu.com/). La configuración multiservidor que Zimbra permite, consta de tres equipos servidores con los siguientes servicios:

LDAP: Se trata del servidor principal. En él se almacenan todos los datos relativos a usuarios de Zimbra.

MAILBOX: Destinado a almacenar los buzones de los usuarios y la interfaz web.

MTA: Destinado a las funciones de envío y recepción de correo.

Según los casos de éxito y pruebas de rendimiento de Zimbra un servidor LDAP, un MAILBOX y otro MTA serían suficientes para atender a unos 5000 usuarios. En cualquier caso, se puede ampliar el número de servidores para atender a una gran cantidad de usuarios. Por ejemplo, se pueden añadir réplicas LDAP (otros servidores LDAP esclavos del primero), distintos MAILBOX donde los buzones de los usuarios se irían repartiendo equitativamente y varios MTA para permitir varios flujos simultáneos de envío y recepción. En este proyecto, donde el número de usuarios no excede de 600, se decide agrupar el servidor LDAP con el MAILBOX en un equipo (máquina virtual) y el MTA en otro. Los pasos necesarios para instalación serían los siguientes: En primer lugar, se debe descargar la instalación de la página web de Zimbra (www.zimbra.com), para ello, en ambos servidores:

Posteriormente, se descomprime, en ambos servidores:

wget http://files2.zimbra.com/downloads/7.1.4_GA/\ zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz

http://www.ubuntu.com/


http://files2.zimbra.com/downloads/

5. Implementación

51

Es necesario instalar, como root, los siguientes paquetes, en ambos servidores:

Una vez instalados, ya es posible instalar Zimbra. No obstante, la instalación hace una comprobación sobre el nombre del equipo (hostname). Dicho nombre debe ser de tipo FQDN (Fully Qualified Domain Name), es decir, de la forma nombrepropio.subdominio.dominio. Es un requisito indispensable para continuar la instalación. La motivación de esto es evitar errores derivados de que el equipo no esté correctamente identificado. Además, es muy recomendable que se haga uso de un nombre asociado a un DNS. La instalación hará una petición DNS para comprobarlo y permitirá continuar si no es así aunque no sea lo ideal. Para satisfacer esto, habría que ajustar los siguientes ficheros del sistema operativo, en ambos servidores:

/etc/hostname

/etc/hosts

tar xvfz zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz

apt-get install sysstat sqlite3 libperl5.10

- nombre_no_FDQN #se elimina esta línea + nombrepropio.subdominio.dominio #se añade esta línea

+ IP_del_equipo nombrepropio.subdominio.dominio nombrepropio

PFC – SME del CdC

52

LDAP + MAILBOX

Ahora, en el servidor LDAP + MAILBOX:

Aceptamos la licencia e instalamos los siguientes paquetes: ldap, logger, store, apache y spell. Si se desea utilizar SNMP, sería necesario instalarlo en todos los servidores.

Autorizamos que se modifique el sistema y llegamos a la pantalla de configuración de la instalación:


Checking for installable packages

Found zimbra-core Found zimbra-ldap Found zimbra-logger Found zimbra-mta Found zimbra-snmp Found zimbra-store Found zimbra-apache Found zimbra-spell Found zimbra-proxy Found zimbra-memcached

Select the packages to install

Install zimbra-ldap [Y] y Install zimbra-logger [Y] y Install zimbra-mta [Y] n Install zimbra-snmp [Y] n Install zimbra-store [Y] y Install zimbra-apache [Y] y Install zimbra-spell [Y] y Install zimbra-proxy [N] n Install zimbra-memcached [N] n Checking required space for zimbra-core checking space for zimbra-store

Installing: zimbra-core zimbra-ldap zimbra-logger zimbra-store zimbra-apache zimbra-spell

5. Implementación

53

Las líneas marcadas con **** al inicio indican que necesitan ser revisadas para completar la configuración.

Main menu

1) Common Configuration: +Hostname: mailhost.example.com +Ldap master host: mailhost.example.com +Ldap port: 389 +Ldap Admin password: set +Secure interprocess communications: yes +TimeZone: America/Los_Angeles

2) zimbra-ldap: Enabled +Status Enabled +Create Domain: yes +Domain to create: mailhost.example.com +Ldap root password: set +Ldap replication password: set +Ldap postfix password: set +Ldap amavis password: set +Ldap nginx password: set

3) zimbra-store: Enabled +Status Enabled +Create Admin User: yes +Admin user to create: [email protected] ******* +Admin Password UNSET +Anti-virus quarantine user: [email protected] +Enable automated spam training: yes +Spam training user [email protected] +Non-spam(Ham) training user: [email protected] +SMTP host: mailhost.example.com +Web server HTTP port: 80 +Web server HTTPS port: 443 +Web server mode: http +IMAP server port: 143 +IMAP server SSL port: 993 +POP server port: 110 +POP server SSL port: 995 +Use spell check server: yes +Spell server URL: http://mailhost.example.com:7780/aspell.php +Configure for use with mail proxy: FALSE +Configure for use with web proxy: FALSE +Enable version update checks: TRUE +Enable version update notifications: TRUE +Version update notification email: [email protected] +Version update source email: [email protected] 4) zimbra-logger: Enabled 5) zimbra-spell: Enabled 6) zimbra-convertd: Enabled 7) Default Class of Service Configuration: 8) Enable default backup schedule: yes c) Collapse menu r) Start servers after configuration yes s) Save config to file q) Quit

PFC – SME del CdC

54

Para el correcto funcionamiento del sistema, tan sólo habría que definir la contraseña de administrador, en zimbra-store (3) => admin password (4) y la contraseñas del menú zimbra-ldap (2). Para ello fijamos las contraseñas que se deseen usar:

ldap root password (4), siendo esta la contraseña principal

ldap replication password (5)

ldap postfix password (6)

ldap amavis password (7)

ldap nginx password (8) Debemos definir la zona horaria en common configuration (1) => timezone (6), aunque también se pueda ajustar posteriormente, porque nos servirá para comprobar que la comunicación de los demás servidores (MTA en este caso), es correcta. Finalmente, en zimbra-ldap (2) => domain to create (3) tenemos el nombre de dominio que se va a crear. Al acabar, pulsamos la opción apply (letra a), que solo aparecerá cuando no haya líneas marcadas con ****. Es importante comprobar en los distintos menús que las direcciones de correo electrónico que vayan a crearse o asociarse a algo tengan el dominio asignado al realizar esta operación y no el nombre de la máquina en la que estamos realizando la instalación. Es posible que no se haya cambiado automáticamente en todos los casos al elegir el dominio al crear. Al concluir la instalación, estaría instalado y funcionando el servidor LDAP + MAILBOX de Zimbra. La información básica para poder gestionarlo:

Estado del servicio. Ejecutando:

Parar el servicio. Ejecutando:

Iniciar el servicio. Ejecutando:

Reiniciar el servicio. Ejecutando:

Interfaz de usuario:

Consola de administración:

service zimbra status

service zimbra stop

service zimbra start

service zimbra restart

http://mailhost.example.com/

https://mailhost.example.com:7071/zimbraAdmin/

5. Implementación

55

MTA

Ahora, en el servidor MTA:

Aceptamos la licencia e instalamos el siguiente paquete: mta. Si se desea utilizar SNMP, sería necesario instalarlo en todos los servidores.

Autorizamos que se modifique el sistema y configuramos la instalación:


Checking for installable packages Found zimbra-core Found zimbra-ldap Found zimbra-logger Found zimbra-mta Found zimbra-snmp Found zimbra-store Found zimbra-apache Found zimbra-spell Found zimbra-proxy Select the packages to install Install zimbra-ldap [Y] n Install zimbra-logger [Y] n Install zimbra-mta [Y] y Install zimbra-snmp [Y] n Install zimbra-store [Y] n Install zimbra-apache [Y] n Install zimbra-spell [Y] n Install zimbra-proxy [N] n Checking required space for zimbra-core Installing: zimbra-core zimbra-mta

Main menu 1) Common Configuration: +Hostname: mta-1.example.com ******* +Ldap master host: UNSET +Ldap port: 389 ******* +Ldap Admin password: UNSET +Secure interprocess communications: yes +TimeZone: (GMT-08.00) Pacific Time (US & Canada) 2) zimbra-mta: Enabled ******* +MTA Auth host: mta-1.example.com +Enable Spamassassin: yes +Enable Clam AV: yes +Notification address for AV alerts: [email protected] +Bind password for postfix ldap user: UNSET +Bind password for amavis ldap user: UNSET 3) Enable default backup schedule: yes r) Start servers after configuration yes s) Save config to file x) Expand menu q) Quit

PFC – SME del CdC

56

Las líneas marcadas con **** al inicio indican que necesitan ser revisadas para completar la configuración. Para el correcto funcionamiento del sistema, es necesario conectar este servidor MTA con el servidor LDAP maestro. Para ello, tan sólo habría que definirlo en el menú common configuration (1), en el campo ldap master host (2) y la contraseña de administrador en ldap admin password (4). Una vez introducido el nombre del equipo LDAP maestro y la contraseña, el configurador de la instalación conectará con el servidor LDAP y recuperará su timezone (6). Si no se ha podido establecer la comunicación, el servidor MTA no podrá finalizar la instalación. Posteriormente, habrá que completar, en el menú zimbra-mta (2), el campo MTA auth host (2) con el nombre del equipo servidor MAILBOX (en este caso, el mismo que LDAP). Finalmente, habrá que introducir las contraseñas almacenadas en el servidor LDAP maestro dentro de este mismo menú, en los campos: ldap replication password, ldap postfix password, ldap amavis password y ldap nginx password. Es importante comprobar en los distintos menús que las direcciones de correo electrónico que vayan a crearse o asociarse a algo tengan el dominio asignado al realizar esta operación y no el nombre de la máquina en la que estamos realizando la instalación. Es posible que no se haya cambiado automáticamente en todos los casos al elegir el dominio al crear. Al concluir la instalación, estaría instalado y funcionando el servidor MTA de Zimbra y vinculado al MAILBOX + LDAP, por lo que tendríamos el servicio completo. No obstante, será necesario realizar unos últimos pasos para completar la configuración.

5. Implementación

57

Configuración final

Es necesario completar la instalación para que ambos servidores se comuniquen correctamente. En primer lugar, hay que ajustar la configuración de ssh en el servidor MTA:

A continuación, para generar las claves y actualizarlas, en ambos servidores:

Posteriormente, es necesario habilitar los registros, para ello, en ambos servidores y como usuario root:

En en servidor MBX + LDAP hay que permitir la recepción de registros quitando los comentarios de /etc/rsyslog.conf de las siguientes líneas:

/etc/rsyslog.conf

Finalmente, hay que modificar /etc/rsyslog.d/60-zimbra.conf. Será distinto en ambos servidores:

/etc/rsyslog.d/60-zimbra.conf en MBX + LDAP:

/etc/rsyslog.d/60-zimbra.conf en MTA:

En el último fichero, mailhost.example.com representa el servidor en el que el paquete logger fue instalado, LDAP + MBX en este caso. Finalmente, en ambos servidores:

echo AllowUsers admin zimbra root >> /etc/ssh/sshd_config service ssh restart

sudo -u zimbra /opt/zimbra/bin/zmsshkeygen sudo -u zimbra /opt/zimbra/bin/zmupdateauthkeys

/opt/zimbra/libexec/zmsyslogsetup

- #$modload imudp + $modload imudp - #$UDPServerRun 514 + $UDPServerRun 514

local0.* -/var/log/zimbra.log local1.* -/var/log/zimbra-stats.log auth.* -/var/log/zimbra.log mail.* -/var/log/zimbra.log

local0.* @mailhost.example.com local1.* @mailhost.example.com auth.* @mailhost.example.com local0.* -/var/log/zimbra.log local1.* -/var/log/zimbra-stats.log auth.* -/var/log/zimbra.log mail.* @mailhost.example.com mail.* -/var/log/zimbra.log

service rsyslog restart service zimbra restart

PFC – SME del CdC

58

Instalación e integración de mailman (multiservidor)

Como se ha comentado en el diseño de la solución, se va a integrar mailman con Zimbra. En el script de instalación e integración de mailman y Zimbra para un único servidor, la instalación de mailman hacía uso tanto de la MTA (para enviar y recibir correos electrónicos) como del servidor web apache de Zimbra para mostrar su interfaz de gestión y utilización. No obstante, al instalar e integrar mailman con Zimbra en esta configuración multiservidor, la instalación debe efectuarse en el servidor MTA (para que pueda hacer uso adecuadamente del intercambiador de correo). Es decir, ya no puede beneficiarse del servidor apache utilizado por Zimbra. Por tanto, el script que sigue a continuación realiza una instalación y configuración de mailman basada en apache (www-data) y posteriormente lo asocia con la MTA (Postfix) de Zimbra.

/root/mailmanMTASSL.sh (permisos 777)


#!/bin/sh # Script para la instalacion de mailman con zimbra if [ $# -gt "1" ]; then echo "USO: mailmanMTA.sh" echo "ejemplo: mailmanMTA.sh (para un unico servidor en el sistema)" echo "USO: mailmanMTA.sh nombre_servidor" echo "ejemplo: mailmanMTA.sh servidor.dominio.com" else #******************* Nombre del servidor ********************* if [ $# -eq "0" ]; then SERVIDOR=$(sudo -u zimbra /opt/zimbra/bin/zmprov gad) echo "Mailman se instalara para el siguiente servidor:" echo $SERVIDOR echo "si es correcto pulse ENTER, si no CONTROL-C" echo "y ejecute: mailmanMTA.sh nombre_servidor" read variable else SERVIDOR=$1 fi echo $SERVIDOR #************************************************************* apt-get update apt-get install -y apache2 openssl apt-get install -y python-dev make chkconfig adduser --no-create-home --disabled-login mailman #***************** Instalacion de mailman ******************* cd /usr/local/ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.14-1.tgz #procede si el tamano de la instalacion de mailman es correcto if [ $(ls -l mailman-2.1.14-1.tgz | awk '{print $5-8201307}') -eq "1" ]; then mkdir mailman chgrp mailman mailman chmod a+rx,g+ws mailman tar xvfz mailman-2.1.14-1.tgz cd mailman-2.1.14-1 ./configure --with-cgi-gid=www-data make install cd /usr/local/mailman/archives rm /usr/local/mailman-2.1.14-1.tgz rm -r /usr/local/mailman-2.1.14-1 chown www-data private

5. Implementación

59


chmod o-x private /usr/local/mailman/bin/check_perms -f /usr/local/mailman/bin/check_perms -f echo "ServerName ${SERVIDOR}" >> /etc/apache2/httpd.conf #*************** Creacion de sites-available/mailmanssl ******************** echo "<IfModule mod_ssl.c>" >> /etc/apache2/sites-available/mailmanssl echo "<VirtualHost _default_:7780>" >> /etc/apache2/sites-available/mailmanssl echo "ServerAdmin admin@${SERVIDOR}" >> /etc/apache2/sites-available/mailmanssl echo "ServerName ${SERVIDOR}" >> /etc/apache2/sites-available/mailmanssl echo >> /etc/apache2/sites-available/mailmanssl echo "ScriptAlias /mailman/ /usr/local/mailman/cgi-bin/" >> /etc/apache2/sites-available/mailmanssl echo >> /etc/apache2/sites-available/mailmanssl echo "<Directory /mailman/>" >> /etc/apache2/sites-available/mailmanssl echo "AllowOverride None" >> /etc/apache2/sites-available/mailmanssl echo "Options ExecCGI" >> /etc/apache2/sites-available/mailmanssl echo "Order allow,deny" >> /etc/apache2/sites-available/mailmanssl echo "Allow from all" >> /etc/apache2/sites-available/mailmanssl echo "</Directory>" >> /etc/apache2/sites-available/mailmanssl echo >> /etc/apache2/sites-available/mailmanssl echo "Alias /mmimages/ /usr/local/mailman/icons/" >> /etc/apache2/sites-available/mailmanssl echo "Alias /pipermail/ /usr/local/mailman/archives/public/" >> /etc/apache2/sites-available/mailmanssl echo >> /etc/apache2/sites-available/mailmanssl echo "<Directory /pipermail/>" >> /etc/apache2/sites-available/mailmanssl echo "Options Indexes MultiViews FollowSymLinks" >> /etc/apache2/sites-available/mailmanssl echo "AllowOverride None" >> /etc/apache2/sites-available/mailmanssl echo "Order allow,deny" >> /etc/apache2/sites-available/mailmanssl echo "Allow from all" >> /etc/apache2/sites-available/mailmanssl echo "</Directory>" >> /etc/apache2/sites-available/mailmanssl echo >> /etc/apache2/sites-available/mailmanssl echo "RedirectMatch ^/mailman[/]*$ https://${SERVIDOR}:7780/mailman/listinfo" >> /etc/apache2/sites-available/mailmanssl echo >> /etc/apache2/sites-available/mailmanssl echo "SSLEngine on" >> /etc/apache2/sites-available/mailmanssl echo "SSLCertificateFile /etc/apache2/ssl/web.crt" >> /etc/apache2/sites-available/mailmanssl echo "SSLCertificateKeyFile /etc/apache2/ssl/server.key" >> /etc/apache2/sites-available/mailmanssl echo "SSLCertificateChainFile /etc/apache2/ssl/ca.crt" >> /etc/apache2/sites-available/mailmanssl echo "SSLCACertificateFile /etc/apache2/ssl/ca.crt" >> /etc/apache2/sites-available/mailmanssl echo "</VirtualHost>" >> /etc/apache2/sites-available/mailmanssl echo "</IfModule>" >> /etc/apache2/sites-available/mailmanssl #***************** Modificacion de ports.conf ***************** cp /etc/apache2/ports.conf /etc/apache2/ports.confBK cat /etc/apache2/ports.conf | awk '{if($0=="Listen 80"){print "Listen 7780"}else{print $0}}' > mailmanMTAtemporal.txt cat mailmanMTAtemporal.txt > /etc/apache2/ports.conf rm mailmanMTAtemporal.txt #************************************************************** rm /etc/apache2/sites-enabled/* cd /etc/apache2/sites-enabled/ ln -s ../sites-available/mailmanssl mailmanssl cd /etc/apache2/mods-enabled/ ln -s ../mods-available/ssl.conf ssl.conf

PFC – SME del CdC

60


ln -s ../mods-available/ssl.load ssl.load #************************************************************** cp /opt/zimbra/postfix/conf/main.cf /opt/zimbra/postfix/conf/main.cfBK #***************** Modificacion de main.cf ******************** cat /opt/zimbra/postfix/conf/main.cf | awk '{if($1=="virtual_alias_maps"){ print "virtual_alias_maps = ldap:/opt/zimbra/conf/ldap-vam.cf"} else{ print $0}}' > prueba.txt mv prueba.txt /opt/zimbra/postfix/conf/main.cf cat /opt/zimbra/postfix/conf/main.cf | awk '{if($1=="alias_maps"){ print "alias_maps = hash:/etc/aliases,hash:/usr/local/mailman/data/aliases"} else{ print $0}}' > prueba.txt mv prueba.txt /opt/zimbra/postfix/conf/main.cf chown zimbra:zimbra /opt/zimbra/postfix/conf/main.cf chmod 644 /opt/zimbra/postfix/conf/main.cf #************************************************************** echo >> /usr/local/mailman/Mailman/mm_cfg.py echo "MTA = 'Postfix'" >> /usr/local/mailman/Mailman/mm_cfg.py echo "POSTFIX_ALIAS_CMD = '/opt/zimbra/postfix/sbin/postalias'" >> /usr/local/mailman/Mailman/mm_cfg.py echo "POSTFIX_MAP_CMD = '/opt/zimbra/postfix/sbin/postmap'" >> /usr/local/mailman/Mailman/mm_cfg.py echo "IMAGE_LOGOS = '/mmimages/'" >> /usr/local/mailman/Mailman/mm_cfg.py echo "DEFAULT_URL_PATTERN = 'https://%s:7780/mailman/'" >> /usr/local/mailman/Mailman/mm_cfg.py echo "PUBLIC_ARCHIVE_URL = 'https://%s:7780/pipermail/%(listname)s'" >> /usr/local/mailman/Mailman/mm_cfg.py echo "DEFAULT_SERVER_LANGUAGE = 'es'" >> /usr/local/mailman/Mailman/mm_cfg.py cp /usr/local/mailman/Mailman/Defaults.py /usr/local/mailman/Mailman/Defaults.pyBK echo "BEGIN{servidor = \"$SERVIDOR\"" > temp.awk echo "}{if(\$1==\"DEFAULT_EMAIL_HOST\"){print \$1\" = '\"servidor\"'\";" >> temp.awk echo "getline; print \$1\" = '\"servidor\"'\";}else{print \$0}" >> temp.awk echo "if(\$1==\"DEFAULT_URL_HOST\"){print \$1\" = '\"servidor\"'\";" >> temp.awk echo "getline; print \$1\" = '\"servidor\"'\";}else{print \$0}}END{}" >> temp.awk cat /usr/local/mailman/Mailman/Defaults.py | awk -f temp.awk > temporalinstmailman.temp cat temporalinstmailman.temp > /usr/local/mailman/Mailman/Defaults.py rm temporalinstmailman.temp; rm temp.awk /usr/local/mailman/bin/mmsitepass -c /usr/local/mailman/bin/newlist mailman /usr/local/mailman/bin/config_list -i /usr/local/mailman/data/sitelist.cfg mailman /usr/local/mailman/bin/genaliases /opt/zimbra/postfix-2.7.7.3z/sbin/newaliases chown mailman:mailman /usr/local/mailman/data/aliases* chown mailman:mailman /usr/local/mailman/data/virtual-mailman* cd /usr/local/mailman/cron crontab -u mailman crontab.in cp /usr/local/mailman/scripts/mailman /etc/init.d chkconfig --add mailman cp /opt/zimbra/conf/zmmta.cf /opt/zimbra/conf/zmmta.cfBK #***************** Modificacion de zmmta.cf ******************** cat /opt/zimbra/conf/zmmta.cf | awk '{if($0=="\t\tPOSTCONF mydestination VAR zimbraMtaMyDestination"){print "\t\tPOSTCONF mydestination LOCAL postfix_mydestination"}else{print $0}}' > prueba.txt mv prueba.txt /opt/zimbra/conf/zmmta.cf cat /opt/zimbra/conf/zmmta.cf | awk '{if($1=="POSTCONF" && $2=="alias_maps"){}else{print $0}}' > prueba.txt

5. Implementación

61


mv prueba.txt /opt/zimbra/conf/zmmta.cf chown zimbra:zimbra /opt/zimbra/conf/zmmta.cf chmod 444 /opt/zimbra/conf/zmmta.cf #************************************************************** /usr/local/mailman/bin/check_perms -f /usr/local/mailman/bin/check_perms -f echo "sudo -u zimbra /opt/zimbra/bin/zmlocalconfig -e postfix_mydestination='localhost ${SERVIDOR}'" > ./1.txt; sh ./1.txt; rm ./1.txt; /etc/init.d/mailman stop 2>/dev/null /etc/init.d/mailman start /etc/init.d/zimbra restart clear echo "La instalacion realizada de mailman necesita de certificados SSL" echo "En concreto," echo " /etc/apache2/ssl/ca.crt <- Certificado de la CA" echo " /etc/apache2/ssl/ca.crt <- Certificado del servidor" echo " /etc/apache2/ssl/ca.crt <- Llave privada del servidor" echo "Si desea generar unos certificados autofirmados pulse ENTER para continuar" echo "Si por el contrario, ya dispone de ellos, pulse CONTROL+C para salir" echo "y no olvide colocarlos en el lugar indicado." read variable; clear #****************** generacion de certificados ***************** mkdir /root/ssl; cd /root/ssl echo "Generamos la clave de CA:"; echo "Se debe introducir una clave cuando se solicite"; echo openssl genrsa -des3 -out ca.key 2048 echo; echo "Proceso de generacin de clave de CA finalizado. Pulse para continuar..." read variable; clear echo "Generamos el certificado de CA:"; echo "Se debe introducir la clave anterior cuando se solicite"; echo openssl req -new -x509 -days 3650 -key ca.key -out ca.crt echo; echo "Proceso de generacin de certificado de CA finalizado. Pulse para continuar..." read variable; clear echo "Generamos la clave de servidor:"; echo "Se debe introducir una clave cuando se solicite"; echo openssl genrsa -des3 -out server.key 1024 echo; echo "Proceso de generacin de clave de servidor finalizado. Pulse para continuar..." read variable; clear echo "Generamos la peticion de certificado de servidor:"; echo "IMPORTANTE: "Common name" debe ser el nombre FQDN del servidor"; echo openssl req -new -key server.key -out web.csr echo; echo "Proceso de generacin de peticion de certificado de servidor finalizado. Pulse para continuar..." read variable; clear echo "Generamos el certificado de servidor:"; echo "Se debe introducir la clave anterior cuando se solicite"; echo openssl x509 -req -in web.csr -out web.crt -sha1 -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650 echo; echo "Proceso de generacin de certificado de servidor finalizado. Pulse para continuar..." read variable; clear mv server.key server.key.secure echo "Reducimos la seguridad de la clave para poder cargar el servicio sin interaccion humana:"; echo "Se debe introducir la clave anterior cuando se solicite"; echo openssl rsa -in server.key.secure -out server.key

PFC – SME del CdC

62

echo; echo "Proceso finalizado. Pulse para continuar.."; read variable chmod 0400 *.key mkdir /etc/apache2/ssl cp web.crt /etc/apache2/ssl/web.crt cp ca.crt /etc/apache2/ssl/ca.crt cp server.key /etc/apache2/ssl/server.key service apache2 restart clear echo "Proceso completado." echo "Puede comprobar el correcto funcionamiento del servicio en la url:" echo "https://${SERVIDOR}:7780/mailman/listinfo" else echo "Error en la descarga" fi fi

5. Implementación

63

Instalación de Z-Push (multiservidor)

La instalación de Z-Push en una configuración multiservidor hace uso del mismo script comentado anteriormente, z-push.sh. Además, no será necesario realizar la instalación de Z-Push en un servidor distinto al de Zimbra. Puede hacerse uso del servidor MTA, con apache2 previamente instalado para mailman.

PFC – SME del CdC

64

Sistema final

Arquitectura general

La estructura general del sistema será la siguiente:

El servicio se ofrece manteniendo activas dos máquinas virtuales, una de cada tipo. Los dos servidores estarán a cargo de dos máquinas virtuales, una de cada tipo también. Así pues, serán autónomos, pero la configuración por defecto estará orientada a repartir la carga, manteniendo pues sólo una máquina virtual activa en cada servidor (en negrita en la figura).

Las máquinas con el intercambiador de correo y sus datos estarán contenidos íntegramente en el almacenamiento físico de los hipervisores. Estos datos están destinados a almacenar los correos de forma temporal antes de ser entregados a otros servidores o volcados en los buzones de los usuarios. El tiempo que un correo pasa en este espacio es de 60 segundos (parámetro configurable). Por ello, se ha realizado el diseño dejando 100GB de datos de MTA.

En cuanto al almacenamiento disponible para los usuarios, los servidores en los que se ha

decidido implementar el servicio presentan una limitación importante. Cada HP Proliant DL360 G6 cuenta con 8 bahías de discos duros SAS y los discos duros disponibles tienen una capacidad de 146 GB, lo que da una capacidad total de 1,14TB. Podría haberse optado por adquirir nuevos discos duros SAS de mayor capacidad, pero existen otros recursos más adecuados y de menor coste.

Para la mejora de la capacidad de almacenamiento en los buzones de los usuarios se ha

decidido hacer uso de dos NAS de 36 TB cada uno (12 discos duros SATA de 3TB). Para mantener un buen rendimiento, se ha optado por usar iSCSI (Internet SCSI, Internet Small Computer System Interface).

Ilustración 29: Arquitectura completa del sistema final

5. Implementación

65

Este protocolo simula un disco duro conectado físicamente al equipo mediante una interfaz SCSI (Small Computer System Interface) a través de una conexión remota, usando TCP/IP. El almacenamiento usado mediante este protocolo se organiza en unidades lógicas, llamadas LUN (Logical Unit Number).

En este caso, se ha hecho uso de una única LUN con la capacidad completa del QNAP TS-EC1279U-RP TURBO NAS. No obstante, para no comprometer la estructura del sistema, se ha decidido emplear RAID 5 como mecanismo de protección ante posibles fallos en los discos duros. La capacidad final utilizable, considerando ya DRBD y GFS2, queda reducida a 29,70TB.

Por tanto, la instalación de Zimbra correspondiente a los buzones (LDAP + MAILBOX) y los

datos referidos a los usuarios irán en dicha partición y se replicarán al otro QNAP TURBO NAS mediante DRBD y GFS2 que es usado por la otra máquina virtual con LDAP + MAILBOX.

PFC – SME del CdC

66

Recursos

Los recursos necesarios serán:

Dos servidores HP Proliant DL 360 G6, con 24GB de RAM y un procesador Intel Xeon.

Dos NAS QNAP TS-EC1279U-RP Turbo NAS con 12 HDD SATA de 3TB cada uno.

Un registro A de DNS para la interfaz web del servicio y una IP pública.

Un registro MX de DNS para el intercambiador de correo (MTA) y una IP pública.

Cuatro IPs públicas, una por cada máquina virtual, requisito de la configuración de VLANs de los conmutadores.

Tamaño de la instalación

En cuanto a los NAS destinados a albergar los buzones de los usuarios y la instalación del servidor MAILBOX + LDAP, se calcula el tamaño necesario mediante el número de usuarios y la capacidad asignada a cada uno de ellos de ellos. Así pues, con 600 usuarios y buzones de 20 GB, se necesitarían aproximadamente:

Concepto Cálculo Resultado Datos de usuario Número de usuarios × Tamaño de

buzón 12000 GB

Datos necesarios por MySQL

5% del tamaño de datos de usuario 600 GB

Instalación de Zimbra Tamaño fijo 10 GB Registros de Zimbra (logs) Tamaño fijo 20 GB Índices de Zimbra 25% del tamaño de datos de usuario 3000 GB TOTAL 15630 GB

Tabla 3: Tamaño necesario para la instalación de Zimbra

Se disponen de 30400 GB, que permiten un crecimiento de hasta 1150 usuarios

aproximadamente. Por otra parte, el almacenamiento utilizado en cada hipervisor se ha distribuido según el siguiente diseño:

https://cdc-sap.us.es:10080/dokuwiki/doku.php?id=documentacion:equipamiento_informatico:qnap

5. Implementación

67

Espacio necesario en cada hipervisor Espacio Máquina virtual con S.O. del servidor LDAP + MAILBOX 20 GB Espacio libre necesario (24 GB RAM) 24 GB Máquina virtual con S.O. del servidor MTA 20 GB Espacio libre necesario (24 GB RAM) 24 GB Instalación del servidor MTA y espacio libre para el intercambio temporal

100 GB

Instalación de mailman con registros y listas 50 GB TOTAL 238 GB

Tabla 4: Organización del almacenamiento del hipervisor

Para ello, se han usado tres discos duros SAS de 146 GB en configuración RAID 5,

permitiendo redundancia en el fallo de uno de ellos, y con una capacidad libre total de 268.5 GB con el hipervisor de VMWare ya instalado.

PFC – SME del CdC

68

Planificación de direcciones

2 registros DNS:

A: MX: equipo: mbxetsi.us.es MAC: 18:A9:05:47:96:28 IP: 193.147.160.201 Masc.: 255.255.255.128

equipo: etsi.us.es MAC: 00:25:B3:AB:B7:70 IP: 193.147.160.200 Masc.: 255.255.255.128

Tabla 5: Configuración de los registros DNS necesarios

2 equipos físicos con hipervisor ESXi 4.1 de VMware (actualizados a VMware 5.0):

Hipervisor 1: Hipervisor 2: equipo: hiper1sme eth0: 00:26:55:FF:39:E4 IP: 193.147.160.238 eth1: 00:26:55:FF:39:E6 IP: 192.168.160.238 Masc.: 255.255.252.0

equipo: hiper2sme eth0: 00:25:B3:AB:B7:70 IP: 193.147.160.202 eth1: 00:25:B3:AB:B7:72 IP: 192.168.160.202 Masc.: 255.255.252.0

Tabla 6: Direccionamiento de los equipos físicos

2 NAS QNAP TS-EC1279U-RP:

QNAP 1: QNAP 2: equipo: qnap1 eth0: 00:08:9B:CC:51:28 IP: - eth1: 00:08:9B: CC:51:29 IP: 192.168.161.11 Masc.: 255.255.252.0

equipo: qnap2 eth0: 00:08:9B:CC:53:76 IP: - eth1: 00:08:9B:CC:53:77 IP: 192.168.161.12 Masc.: 255.255.252.0

Tabla 7: Direccionamiento de los servidores de almacenamiento

4 máquinas virtuales con Ubuntu 10.04.3 LTS:

MBX1: MBX2: Hostname: mbx1sme eth0: 00:50:56:3F:00:01 IP: 193.147.160.203 Masc.: 255.255.255.128 eth1: 00:50:56:3F:16:81 IP: 192.168.160.203 Masc.: 255.255.252.0

Hostname: mbx2sme eth0: 00:50:56:3F:00:02 IP: 193.147.160.204 Masc.: 255.255.255.128 eth1: 00:50:56:3F:16:82 IP: 192.168.160.204 Masc.: 255.255.252.0

MTA1: MTA2: Hostname: mta1sme Hostname: mta2sme

5. Implementación

69

eth0: 00:50:56:3F:00:03 IP: 193.147.160.205 Masc.: 255.255.255.128 eth1: 00:50:56:3F:16:83 IP: 192.168.160.205 Masc.: 255.255.255.0

eth0: 00:50:56:3F:00:04 IP: 193.147.160.206 Masc.: 255.255.255.128 eth1: 00:50:56:3F:16:84 IP: 192.168.160.206 Masc.: 255.255.255.0

Tabla 8: Direccionamiento de las máquinas virtuales

PFC – SME del CdC

70

Presupuesto

Recurso Precio unitario Cantidad Coste HP Proliant DL360 G6 24GB RAM 3.160,64 € 2 6.321,28 € QNAP TS-EC1279U-RP Turbo NAS 3118,44 € 2 6.236,88 €

Disco duro Seagate Barracuda 131,36 € 24 3.152,64 €

TOTAL (IVA no incluido) 15.710,80 € IVA (18%) 2.827,92 €

TOTAL (IVA incluido) 18.538,74 €

Tabla 9: Presupuesto del sistema final

5. Implementación

71

Instalación

Para la instalación final se han seguido los siguientes pasos:

Creación y configuración de las máquinas virtuales

Instalación de los dos hipervisores de VMWare y configuración. ◦ Asociación de las interfaces de red a la correspondiente subred. En vSphere Cliente,

sobre el nombre del hipervisor, solapa CONFIGURATION → NETWORKING. Mediante “Add Networking...” se ajusta la configuración de red para tener: ▪ 2 Virtual Machine Port Group (1 por cada interfaz física). ▪ 2 VMKernel Port (1 por cada interfaz física, con las IPs de las interfaces).

Creación de las máquinas virtuales mbx1sme y mta2sme en el hipervisor hiper1sme y de las máquinas virtuales mta1sme y mbx2sme en el hipervisor 2. ◦ Botón derecho sobre el nombre del hipervisor en vSphere Client → New Virtual

Machine → Typical → Nombre de la máquina virtual → Seleccionar datastore → Linux, Ubuntu → Linux 64 → 20 GB → Next → Finish.

En las cuatro máquinas virtuales, dos interfaces de red: ◦ Botón derecho sobre la máquina virtual (en vSphere Client) → Edit Settings →

Hardware → Add → Ethernet Adapter → Next → Ajuste de las interfaces de red, Next → Finish.

En mta1sme y mta2sme, un disco duro adicional para Zimbra: ◦ Botón derecho sobre la máquina virtual (en vSphere Client) → Edit Settings →

Hardware → Add → Hard Disk → Create a new device disk → Next → Disk size: 100 GB, Store with the virtual machine, Next → Independent, Persistent, Next → Finish.

Almacenamiento de la imagen de Ubuntu en el espacio de almacenamiento (datastore) de los hipervisores. ◦ Sobre el nombre del hipervisor, en vSphere Client, Configuration → Storage → Botón

derecho sobre el datastore, Browse Datastore → Upload files to this datastore.

PFC – SME del CdC

72

Instalación del sistema operativo en las máquinas virtuales

Para la instalación del sistema operativo en las cuatro máquinas virtuales: ◦ Botón derecho sobre la máquina virtual (en vSphere Client) → Edit Settings →

Hardware → CD/DVD Drive 1 → Datastore ISO File → Browse → Seleccionar el nombre de la imagen de ubuntu → Connect at power on → OK.

◦ Botón derecho sobre la máquina virtual (en vSphere Client) → Edit Settings → Options → Boot options → The next time the virtual machine boots, force entry into de BIOS setup screen → Arranque de la máquina virtual y configuración de arranque desde el CD.

◦ Instalación normal de ubuntu en las cuatro máquinas virtuales, por parejas, primero mbx1sme y mta1sme y luego, más tarde, mbx2sme y mta2sme de la misma forma. ▪ mbx1sme con hostname: mbxetsi.us.es e IP: 193.147.160.201. ▪ mta1sme con hostname: etsi.us.es e IP: 193.147.160.200.

5. Implementación

73

Instalación de Zimbra en la primera pareja

Instalación de Zimbra en la primera pareja pero válida para todo el sistema: ◦ Como usuario root:

▪ En mbx1sme:

▪ En mta1sme (al acabar con mbx1sme):

Una vez apagada, será necesario ampliar la capacidad del disco para crear una nueva partición, destinada a albergar mailman. Para ello, entramos en “Edit settings” de la máquina virtual y cambiamos el tamaño del disco a 150 GB. Posteriormente, volvemos a arrancar la

echo >> /etc/bash.bashrc;echo "PATH=\$PATH:./" >> /etc/bash.bashrc PATH=$PATH:./ apt-get install -y sshd drbd8-utils cman gfs2-tools heartbeat apt-get install -y gcc sysstat sqlite3 libperl5.10 watchdog /root/vmware-tools-distrib/vmware-install.pl -default wget http://files2.zimbra.com/downloads/7.1.4_GA/\ zcs7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz tar xvfz zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz rm zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz apt-get install -y open-iscsi iscsiadm -m discovery -t sendtargets -p 192.168.161.11 \ | awk '{print $2}' | tail -1 > nombre.txt iscsiadm -m node --targetname $(cat nombre.txt) -p 192.168.161.11 \ -o update -n node.conn[0].startup -v automatic iscsiadm -m node --targetname $(cat nombre.txt) -p 192.168.161.11 -l iscsiadm -m node --op delete --targetname $(cat nombre.txt) --> ERROR(OK) parted /dev/sdb mktable gpt mkpart [sin nombre] ext3 0 32.7TB Ignore quit mkfs.ext3 /dev/sdb1; drbdadm create-md r0 -> FALLO (leer valor left usable para la siguiente línea, sustituyendo las xxxxxxxxxx) e2fsck -f /dev/sdb1 && resize2fs /dev/sdb1 xxxxxxxxxxK cd zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz/ install.sh

echo >> /etc/bash.bashrc;echo "PATH=\$PATH:./" >> /etc/bash.bashrc PATH=\$PATH:./ apt-get install -y sshd drbd8-utils cman gfs2-tools heartbeat apt-get install -y gcc sysstat sqlite3 libperl5.10 watchdog /root/vmware-tools-distrib/vmware-install.pl -default wget http://files2.zimbra.com/downloads/7.1.4_GA/\ zcs7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz tar xvfz zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz rm zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz apt-get install -y open-iscsi fdisk /dev/sdb -> 1 tabla de particiones (c u o w), 1 particion 100GB (c u p 1 INTRO INTRO w) init 0

PFC – SME del CdC

74

máquina virtual:

Siendo mailmanMTA.sh el script, anteriormente comentado, para la integración de mailman con Zimbra y siendo z-push.sh el script, también mencionado antes, para instalar Z-Push con el backend necesario para interactuar con Zimbra. En ambos equipos será necesario evitar que Zimbra se arranque al iniciar el equipo. Para ello, se ejecuta el siguiente script en ambos:

soloconfzimbramailmanMTA.sh

También, en ambos, habrá que instalar watchdog, para lo cual se debe usar este script que

incluye su configuración:

fdisk /dev/sdb -> 1 particion 100GB (c u p 2 INTRO INTRO w) mkfs.ext3 /dev/sdb1; mkfs.ext3 /dev/sdb2 drbdadm create-md r0 -> FALLO (leer valor left usable para la siguiente línea, sustituyendo las xxxxxxxxxx) e2fsck -f /dev/sdb1 && resize2fs /dev/sdb1 xxxxxxxxxx K drbdadm create-md r0 drbdadm create-md r1 -> FALLO (leer valor left usable para la siguiente línea, sustituyendo las xxxxxxxxxx) e2fsck -f /dev/sdb2 && resize2fs /dev/sdb2 xxxxxxxxxx K drbdadm create-md r1 mkdir /usr/local/mailman cd zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz/ install.sh mailmanMTA.sh z-push.sh

#!/bin/sh rm /etc/rc6.d/S89zimbra rm /etc/rc6.d/K01zimbra rm /etc/rc1.d/K01zimbra rm /etc/rc4.d/S99zimbra rm /etc/rc4.d/K01zimbra rm /etc/rc0.d/S89zimbra rm /etc/rc0.d/K01zimbra rm /etc/rc5.d/S99zimbra rm /etc/rc5.d/K01zimbra rm /etc/rc3.d/S99zimbra rm /etc/rc3.d/K01zimbra rm /etc/rc2.d/S99zimbra rm /etc/rc2.d/K01zimbra

5. Implementación

75

instalawatchdog.sh

#!/bin/sh apt-get install watchdog rm /etc/rc4.d/S09wd_keepalive rm /etc/rc5.d/S09wd_keepalive rm /etc/rc3.d/S09wd_keepalive rm /etc/rc2.d/S09wd_keepalive rm /etc/rc6.d/K11watchdog rm /etc/rc1.d/K11watchdog rm /etc/rc4.d/S89watchdog rm /etc/rc0.d/K11watchdog rm /etc/rc5.d/S89watchdog rm /etc/rc3.d/S89watchdog rm /etc/rc2.d/S89watchdog echo "#!/bin/sh" > /usr/sbin/accionwatchdog.sh echo "service heartbeat stop" >> /usr/sbin/accionwatchdog.sh echo "init 6" >> /usr/sbin/accionwatchdog.sh chmod 777 /usr/sbin/accionwatchdog.sh /sbin/modprobe softdog echo 'softdog' >> /etc/modules echo "file = /var/log/messages" >> /etc/watchdog.conf echo "watchdog-device = /dev/watchdog" >> /etc/watchdog.conf echo "repair-bin = /usr/sbin/accionwatchdog.sh" HN=`hostname` cd /opt/zimbra if [ $HN = "mta1sme" ]; then find -name *.pid | sed 's/\./\/opt\/zimbra/1' | grep -v freshclam | grep -v zmstat | awk 'BEGIN{print "pidfile\t\t\t= /var/run/heartbeat.pid";print "pidfile\t\t\t= /var/run/cdcrpc.pid";print "pidfile\t\t\t= /var/run/apache2.pid";print "pidfile\t\t\t= /usr/local/mailman/data/master-qrunner.pid"}{print "pidfile\t\t\t= "$0}' >> /etc/watchdog.conf else if [ $HN = "mta2sme" ]; then find -name *.pid | sed 's/\./\/opt\/zimbra/1' | grep -v freshclam | grep -v zmstat | awk 'BEGIN{print "pidfile\t\t\t= /var/run/heartbeat.pid";print "pidfile\t\t\t= /var/run/cdcrpc.pid";print "pidfile\t\t\t= /var/run/apache2.pid";print "pidfile\t\t\t= /usr/local/mailman/data/master-qrunner.pid"}{print "pidfile\t\t\t= "$0}' >> /etc/watchdog.conf else find -name *.pid | sed 's/\./\/opt\/zimbra/1' | grep -v freshclam | grep -v zmstat | awk 'BEGIN{print "pidfile\t\t\t= /var/run/heartbeat.pid";print "pidfile\t\t\t= /var/run/cdcrpc.pid"}{print "pidfile\t\t\t= "$0}' >> /etc/watchdog.conf fi fi cd service watchdog start

PFC – SME del CdC

76

Configuración final de la primera pareja

Una vez que Zimbra ha quedado instalado (incluyendo la post-instalación), será necesario seguir una serie de pasos que nos permitan alcanzar la configuración final de la primera pareja (mbx1sme y mta1sme): Paramos el servicio de Zimbra y salvaguardamos la instalación, en ambos:

En mta1sme, además:

Ya que se hará uso de esta instalación con un nombre de host distinto, habrá que realizar una pequeña modificación de /etc/init.d/zimbra en mta1sme y mta2sme debido a comprobaciones de DNS internas por parte de Postfix. El nuevo contenido será:

/etc/init.d/zimbra (permisos 777)


service watchdog stop; service zimbra stop mkdir /tmp/zimbra/ rsync -a /opt/zimbra/ /tmp/zimbra/ rm -r /opt/zimbra/

service mailman stop mkdir /tmp/mailman/ rsync -a /usr/local/mailman/ /tmp/mailman/ rm –r /usr/local/mailman/*

#!/bin/bash # # ***** BEGIN LICENSE BLOCK ***** # Zimbra Collaboration Suite Server # Copyright (C) 2005, 2006, 2007, 2009, 2010, 2011 VMware, Inc. # # The contents of this file are subject to the Zimbra Public License # Version 1.3 ("License"); you may not use this file except in # compliance with the License. You may obtain a copy of the License at # http://www.zimbra.com/license. # # Software distributed under the License is distributed on an "AS IS" # basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. # ***** END LICENSE BLOCK ***** # # # Init file for zimbra mail # # chkconfig: 345 99 01 # description: Zimbra mail service # ### BEGIN INIT INFO # Provides: zimbra # Required-Start: $network $remote_fs $syslog $time nscd cron # Required-Stop: $network $remote_fs $syslog $time # Default-Start: 3 5 # Description: Zimbra mail service ### END INIT INFO

5. Implementación

77

Ahora, sólo queda configurar los servicios necesarios para la alta disponibilidad. Para ello, habrá que ajustar los archivos de configuración como sigue a continuación.

command() { if [ -f /opt/zimbra/redolog/redo.log ]; then chown -f zimbra:zimbra /opt/zimbra/redolog/redo.log fi # su - zimbra -c "zmcontrol $1 </dev/null >>/opt/zimbra/log/startup.log 2>&1" # bug 45842 su - zimbra -c "zmcontrol $1 </dev/null" }

case "$1" in restart) kill `cat /opt/zimbra/data/postfix/data/master.lock` kill `ps aux | grep saslauthd | awk '{print $2}'` command shutdown command startup RETVAL=0 if [ -d /var/lock/subsys -a $RETVAL -eq 0 ]; then touch /var/lock/subsys/zimbra fi ;; start) command startup RETVAL=$? if [ -d /var/lock/subsys -a $RETVAL -eq 0 ]; then touch /var/lock/subsys/zimbra fi ;; stop) kill `cat /opt/zimbra/data/postfix/data/master.lock` kill `ps aux | grep saslauthd | awk '{print $2}'` command shutdown RETVAL=0 if [ -d /var/lock/subsys -a $RETVAL -eq 0 ]; then rm -f /var/lock/subsys/zimbra fi ;; reload|status) command $1 RETVAL=$? ;; *) echo $"Usage: $0 {start|stop|restart|reload|status}" RETVAL=1 esac exit $RETVAL

PFC – SME del CdC

78

mbx1sme

/etc/hostname

/etc/network/interfaces

/etc/hosts


mbx1sme

auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 193.147.160.203 netmask 255.255.255.128 network 193.147.160.128 broadcast 193.147.160.255 gateway 193.147.160.129 dns-nameservers 150.214.186.69 150.214.130.15 auto eth1 iface eth1 inet static address 192.168.160.203 netmask 255.255.254.0 network 192.168.160.0 broadcast 192.168.161.255

127.0.0.1 localhost 193.147.160.200 etsi.us.es etsi 193.147.160.201 mbxetsi.us.es mbxetsi 193.147.160.203 mbx1sme 193.147.160.204 mbx2sme 193.147.160.205 mta1sme 193.147.160.206 mta2sme

# The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters

<?xml version="1.0"?> <cluster name="clustermbx" config_version="1"> <totem consensus="6000" token="3000"/> <clusternodes> <clusternode name="mbx1sme" nodeid="1"> <fence></fence> </clusternode> <clusternode name="mbx2sme" nodeid="2"> <fence></fence> </clusternode> </clusternodes> <cman expected_votes="1" two_node="1"/> <fencedevices> </fencedevices> <rm></rm> </cluster>

5. Implementación

79


/etc/ha.d/authkeys (permisos 600)

totem { version: 2 token: 3000 token_retransmits_before_loss_const: 10 join: 60 consensus: 5000 vsftype: none max_messages: 20 clear_node_high_bit: yes secauth: off threads: 0 rrp_mode: none

interface { ringnumber: 0 bindnetaddr: 192.168.160.203 mcastaddr: 192.168.160.255 mcastport: 5405 } }

amf { mode: disabled }

service { ver: 0 name: pacemaker }

aisexec { user: root group: root }

logging { fileline: off to_stderr: yes to_logfile: no to_syslog: yes syslog_facility: daemon debug: off timestamp: on logger_subsys { subsys: AMF debug: off tags: enter|leave|trace1|trace2|trace3|trace4|trace6 } }

auth 2 1 crc 2 sha1 clave1 3 md5 clave2

PFC – SME del CdC

80

/etc/drbd.conf


/etc/ha.d/ha.cf

global { usage-count no; } common { protocol C; syncer { rate 100M; } } resource r0 { handlers { pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f"; pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f"; local-io-error "echo o > /proc/sysrq-trigger ; halt -f"; } startup { wfc-timeout 60; # 1 minute. degr-wfc-timeout 120; # 2 minutes. } disk { on-io-error detach; } net { after-sb-0pri discard-zero-changes; after-sb-1pri discard-secondary; after-sb-2pri disconnect; rr-conflict disconnect; } syncer { rate 100M; } on mbx1sme { device /dev/drbd0; disk /dev/sdb1; address 192.168.160.203:7788; meta-disk internal; } on mbx2sme { device /dev/drbd0; disk /dev/sdb1; address 192.168.160.204:7788; meta-disk internal; } }

mbx1sme drbddisk::all Filesystem::/dev/drbd0::/opt::gfs2::rw getipmbx zimbra \ mtarestart delayedwatchdog

debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 12 initdead 18 udpport 694 ucast eth1 192.168.160.204 auto_failback on node mbx1sme node mbx2sme

5. Implementación

81

Finalmente, será necesario incluir como scripts de servicio, los siguientes:

mtarestart: Script de python basado en xmlrpc que permite la comunicación de cualquiera de los dos servidores LDAP + MBX con cualquiera del servidores MTA. Es necesaria esta comunicación, ya que si falla el equipo que está ejecutando el servidor LDAP de Zimbra y tenía un servidor Zimbra MTA contectado, al arrancar el nuevo servidor LDAP el servidor MTA necesita reconectarse. Mediante este script, se fuerza el reinicio del servicio para efectuar esta reconexión.

/etc/init.d/mtarestart (permisos 777)

delayedwatchdog: Script que retrasa el arranque de watchdog el tiempo necesario para que se consoliden los recursos que monitoriza.

/etc/init.d/delayedwatchdog (permisos 777)

manualfenceack: En la utilización de CMAN (cluster manager), necesario para GFS2, este script elimina la protección adicional de la barrera de protección (fence). Esta protección se basa en equipos especiales (por ejemplo, fuentes de alimentación) que realizan acciones sobre los equipos que constituyen la barrera, permitiendo, por ejemplo, apagar/reiniciar un equipo que ha perdido la conexión con la agrupación (cluster) pero que no se ha apagado/reiniciado. Al no disponer de ningún mecanismo sobre el que implementar esta barrera de protección se ha decidido no hacer uso de ella. Tampoco resulta necesario ya que watchdog se encarga de ello. Para el uso de este script, no invocado por heartbeat, es necesario añadir la siguiente entrada en /etc/crontab:

#!/usr/bin/python # -*- coding: iso-8859-15 -*- import xmlrpclib, sys, socket url="http://etsi.us.es:6667/" codificacion='iso-8859-15' if len(sys.argv) == 1: print "Ejecute: mtarestart start|estado" else: if sys.argv[1]=="start": try: s = xmlrpclib.ServerProxy(url, encoding=codificacion) print s.reiniciamta() except socket.error: print "Error en la comunicación. if sys.argv[1]=="estado": s = xmlrpclib.ServerProxy(url, encoding=codificacion) try: print s.estadomta() except socket.error: print "Error en la comunicación.

#!/bin/sh if [ $1 = "start" ]; then sleep 10; service watchdog start else service watchdog $1 fi

PFC – SME del CdC

82

/etc/init.d/manualfenceack (permisos 777)

getipmbx: Otorga la IP del servicio haciendo uso de las herramientas de heartbeat.

/etc/init.d/getipmbx (permisos 777)


* * * * * root sh /etc/init.d/manualfenceack

#!/bin/sh MUERTO=`tail -5 /var/log/syslog | awk 'BEGIN{bandera=0}{if($6=="fencing"&&$7=="node"){getline;if($8=="dev"&&$9=="0.0"&&$10=="agent"){getline;if($6=="fence"&&$8=="failed"){bandera=1}}}}END{print bandera}'` if [ $MUERTO -eq "1" ]; then echo "El otro nodo ha muerto, se toman medidas" >> /var/log/syslog echo "*"; echo "*"; echo "*"; echo "*"; >> /var/log/syslog # equivalente a fence_ack_manual while ! [ -e /var/run/cluster/fenced_override ]; do sleep 1 done echo `cat /etc/drbd.conf | grep " on " | grep -v $(hostname) | awk '{print $2}'` > /var/run/cluster/fenced_override sleep 1 # fin fence_ack_manual echo -n "Asentimiento sobreescrito para: " >> /var/log/syslog echo `cat /etc/drbd.conf | grep " on " | grep -v $(hostname) | awk '{print $2}'` >> /var/log/syslog fi

#!/bin/sh if [ $# -eq "1" ]; then if [ $1 = "start" ]; then ifconfig eth0 193.147.160.201 netmask 255.255.255.128 broadcast 193.147.160.255 route add -net 0.0.0.0 gw 193.147.160.129 netmask 0.0.0.0 metric 100 dev eth0 if [ `hostname` = "mbx1sme" ]; then /etc/ha.d/resource.d/IPaddr 193.147.160.203/25/eth0 start fi if [ `hostname` = "mbx2sme" ]; then /etc/ha.d/resource.d/IPaddr 193.147.160.204/25/eth0 start fi fi if [ $1 = "stop" ]; then if [ `hostname` = "mbx1sme" ]; then ifconfig eth0 193.147.160.203 netmask 255.255.255.128 broadcast 193.147.160.255 route add -net 0.0.0.0 gw 193.147.160.129 netmask 0.0.0.0 metric 100 dev eth0 /etc/ha.d/resource.d/IPaddr 193.147.160.203/25/eth0 stop fi if [ `hostname` = "mbx2sme" ]; then ifconfig eth0 193.147.160.204 netmask 255.255.255.128 broadcast 193.147.160.255 route add -net 0.0.0.0 gw 193.147.160.129 netmask 0.0.0.0 metric 100 dev eth0

5. Implementación

83

/etc/ha.d/resource.d/IPaddr 193.147.160.204/25/eth0 stop fi fi else echo "Uso: /etc/init.d/getipmbx {start|stop}" fi

PFC – SME del CdC

84

mta1sme

/etc/hostname


/etc/hosts:

Igual que en mbx1sme.


mta1sme


<?xml version="1.0"?> <cluster name="clustermta" config_version="1"> <totem consensus="6000" token="3000"/> <clusternodes> <clusternode name="mta1sme" nodeid="1"> <fence> </fence> </clusternode> <clusternode name="mta2sme" nodeid="2"> <fence> </fence> </clusternode> </clusternodes> <cman expected_votes="1" two_node="1"/> <fencedevices> </fencedevices> <rm> </rm> </cluster>

5. Implementación

85








PFC – SME del CdC

86

/etc/drbd.conf


global { usage-count no; } common { protocol C; syncer { rate 100M; } } resource r0 { handlers { pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f"; pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f"; local-io-error "echo o > /proc/sysrq-trigger ; halt -f"; } startup { wfc-timeout 60; # 1 minute. degr-wfc-timeout 120; # 2 minutes. } disk { on-io-error detach; } net { after-sb-0pri discard-zero-changes; after-sb-1pri discard-secondary; after-sb-2pri disconnect; rr-conflict disconnect; } syncer { rate 100M; } on mta1sme { device /dev/drbd0; disk /dev/sdb1; address 192.168.160.205:7788; meta-disk internal; } on mta2sme { device /dev/drbd0; disk /dev/sdb1; address 192.168.160.206:7788; meta-disk internal; } } resource r1 { handlers { pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f"; pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f"; local-io-error "echo o > /proc/sysrq-trigger ; halt -f"; } startup { wfc-timeout 60; # 1 minute. degr-wfc-timeout 120; # 2 minutes. } disk { on-io-error detach; }

5. Implementación

87



/etc/ha.d/ha.cf

Finalmente, será necesario incluir como scripts de servicio, los siguientes:

manualfenceack: Al igual que en mbx1sme, es necesario añadir la siguiente entrada en /etc/crontab:

net { after-sb-0pri discard-zero-changes; after-sb-1pri discard-secondary; after-sb-2pri disconnect; rr-conflict disconnect; } syncer { rate 100M; } on mta1sme { device /dev/drbd1; disk /dev/sdb2; address 192.168.160.205:7789; meta-disk internal; } on mta2sme { device /dev/drbd1; disk /dev/sdb2; address 192.168.160.206:7789; meta-disk internal; } }

auth 2 1 crc 2 sha1 clave1 3 md5 clave2

mta1sme drbddisk::all Filesystem::/dev/drbd1::/usr/local/mailman::gfs2::rw \ Filesystem::/dev/drbd0::/opt::gfs2::rw mounttmpfs getipetsi \ zimbra cdcrpc apache2 mailman delayedwatchdog

debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 12 initdead 18 udpport 694 ucast eth1 192.168.160.206 auto_failback on node mta1sme node mta2sme

PFC – SME del CdC

88

/etc/init.d/manualfenceack (permisos 777)


delayedwatchdog: Al igual que en mbx1sme, es necesario el siguiente script de servicio:

/etc/init.d/delayedwatchdog (permisos 777)


getipetsi: Otorga la IP del servicio haciendo uso de las herramientas de heartbeat.

/etc/init.d/getipetsi (permisos 777)

mounttmpfs: Monta el directorio temporal de amavisd como un sistema de ficheros tmpfs, que se aloja en la memoria RAM y que mejora el rendimiento. Los detalles sobre esta mejora se comentan en las peculiaridades de la instalación de @etsi.us.es.

* * * * * root sh /etc/init.d/manualfenceack

#!/bin/sh if [ $# -eq "1" ]; then if [ $1 = "start" ]; then ifconfig eth0 193.147.160.200 netmask 255.255.255.128 broadcast 193.147.160.255 route add -net 0.0.0.0 gw 193.147.160.129 netmask 0.0.0.0 metric 100 dev eth0 if [ `hostname` = "mta1sme" ]; then /etc/ha.d/resource.d/IPaddr 193.147.160.205/25/eth0 start fi if [ `hostname` = "mta2sme" ]; then /etc/ha.d/resource.d/IPaddr 193.147.160.206/25/eth0 start fi fi if [ $1 = "stop" ]; then if [ `hostname` = "mta1sme" ]; then ifconfig eth0 193.147.160.205 netmask 255.255.255.128 broadcast 193.147.160.255 route add -net 0.0.0.0 gw 193.147.160.129 netmask 0.0.0.0 metric 100 dev eth0 /etc/ha.d/resource.d/IPaddr 193.147.160.205/25/eth0 stop fi if [ `hostname` = "mta2sme" ]; then ifconfig eth0 193.147.160.206 netmask 255.255.255.128 broadcast 193.147.160.255 route add -net 0.0.0.0 gw 193.147.160.129 netmask 0.0.0.0 metric 100 dev eth0 /etc/ha.d/resource.d/IPaddr 193.147.160.206/25/eth0 stop fi fi else echo "Uso: /etc/init.d/getipetsi {start|stop}" fi

5. Implementación

89

/etc/init.d/mounttmpfs (permisos 777)

El cálculo de la zona de RAM reservada para este directorio responde al siguiente criterio, con parámetro principal el tamaño máximo de un correo electrónico:

n * (1 + max(expansionfactor)) * $zimbraMtaMaxMessageSize

Tabla 10: Fórmula para el cálculo del espacio temporal necesario para amavisd

Parámetro Valor por defecto

Descripción

n 10

Opción max_servers configurada en /opt/zimbra/conf/amavisd.conf. Responde al número de procesos simultáneos de amavisd

que pueden ejecutarse.

max(expansionfactor) 1,6 Factor de expansión de archivos comprimidos.

Puede tomarse 1.6 como valor estándar.

zimbraMtaMaxMessageSize 10240 kB Es un parámetro de configuración de Zimbra.

Responde al tamaño máximo de un correo electrónico.

Tabla 11: Parámetros de la fórmula para el cálculo del espacio temporal de amavisd

#!/bin/sh if [ $# -ne "1" ]; then echo "USO: mounttmpfs {start|stop}" else if [ $1 = "start" ]; then if [ `df | grep amavisd | wc -l` = "0" ]; then mount -t tmpfs -o defaults,noexec,nodev,nosuid,size=260m,mode=750,uid=zimbra,gid=zimbra /dev/shm/ /opt/zimbra/data/amavisd/tmp/ fi fi if [ $1 = "stop" ]; then if [ `df | grep amavisd | wc -l` = "1" ]; then umount /opt/zimbra/data/amavisd/tmp/ fi fi fi

PFC – SME del CdC

90

Puesta en marcha de la primera pareja

Una vez que las máquinas mbx1sme y mta1sme han sido debidamente configuradas, ya podemos hacer uso de todos los recursos. Además, debemos incluir en ellos la instalación de Zimbra que hicimos anteriormente, para ello:

En mbx1sme:

En mta1sme:

Con esto ya quedaría completamente funcional la primera pareja de equipos que ofrecen el servicio deseado de forma autónoma. Para verificar el funcionamiento, deben ser reiniciados los equipos y esperar a que arranquen todos los procesos necesarios. Para monitorizar que todo se inicia adecuadamente, es conveniente ir comprobando las últimas líneas del registro /var/log/ha-log mientras se van iniciando los distintos servicios.

service drbd restart drbdadm -- --overwrite-data-of-peer primary all mkfs.gfs2 -t clustermbx:zimbra -p lock_dlm -j 2 /dev/drbd0 mount -t gfs2 /dev/drbd0 /opt/ mkdir /opt/zimbra/ rsync -a /tmp/zimbra/ /opt/zimbra/

service drbd restart drbdadm -- --overwrite-data-of-peer primary all mkfs.gfs2 -t clustermta:zimbra -p lock_dlm -j 2 /dev/drbd0 mkfs.gfs2 -t clustermta:mailman -p lock_dlm -j 2 /dev/drbd1 mount -t gfs2 /dev/drbd0 /opt/ mkdir /opt/zimbra/ rsync -a /tmp/zimbra/ /opt/zimbra/ mount -t gfs2 /dev/drbd1 /usr/local/mailman/ rsync -a /tmp/mailman/ /usr/local/mailman/

5. Implementación

91

Preparación de la segunda pareja

Con mbx1sme y mta1sme apagados, se realiza una instalación normal de ubuntu en mbx2sme y mta2sme de la misma forma.

mbx2sme con hostname: mbxetsi.us.es e IP: 193.147.160.201.

mta2sme con hostname: etsi.us.es e IP: 193.147.160.200.

Instalación de Zimbra en la segunda pareja

En mbx2sme:

En mta2sme (al acabar con mbx2sme):

echo >> /etc/bash.bashrc;echo "PATH=\$PATH:./" >> /etc/bash.bashrc PATH=$PATH:./ apt-get install -y sshd drbd8-utils cman gfs2-tools heartbeat apt-get install -y gcc sysstat sqlite3 libperl5.10 watchdog /root/vmware-tools-distrib/vmware-install.pl -default wget http://files2.zimbra.com/downloads/7.1.4_GA/\ zcs7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz tar xvfz zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz rm zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz apt-get install -y open-iscsi iscsiadm -m discovery -t sendtargets -p 192.168.161.12 \ | awk '{print $2}' | tail -1 > nombre.txt iscsiadm -m node --targetname $(cat nombre.txt) -p 192.168.161.12 \ -o update -n node.conn[0].startup -v automatic iscsiadm -m node --targetname $(cat nombre.txt) -p 192.168.161.12 -l iscsiadm -m node --op delete --targetname $(cat nombre.txt) --> ERROR(OK) parted /dev/sdb mktable gpt mkpart [sin nombre] ext3 0 32.7TB Ignore quit mkfs.ext3 /dev/sdb1; drbdadm create-md r0 -> FALLO (leer valor left usable para la siguiente línea, sustituyendo las xxxxxxxxxx) e2fsck -f /dev/sdb1 && resize2fs /dev/sdb1 xxxxxxxxxxK cd zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz/ install.sh

PFC – SME del CdC

92

Una vez apagada, será necesario ampliar la capacidad del disco para crear una nueva partición, destinada a albergar mailman. Para ello, entramos en “Edit settings” de la máquina virtual y cambiamos el tamaño del disco a 150 GB. Posteriormente, volvemos a arrancar la máquina virtual:

echo >> /etc/bash.bashrc;echo "PATH=\$PATH:./" >> /etc/bash.bashrc PATH=\$PATH:./ apt-get install -y sshd drbd8-utils cman gfs2-tools heartbeat apt-get install -y gcc sysstat sqlite3 libperl5.10 /root/vmware-tools-distrib/vmware-install.pl -default wget http://files2.zimbra.com/downloads/7.1.4_GA/\ zcs7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz tar xvfz zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz rm zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz apt-get install -y open-iscsi fdisk /dev/sdb -> 1 tabla de particiones (c u o w), 1 particion 100GB (c u p 1 INTRO INTRO w) init 0

fdisk /dev/sdb -> 1 particion 100GB (c u p 2 INTRO INTRO w) mkfs.ext3 /dev/sdb1; mkfs.ext3 /dev/sdb2 drbdadm create-md r0 -> FALLO (leer valor left usable para la siguiente línea, sustituyendo las xxxxxxxxxx) e2fsck -f /dev/sdb1 && resize2fs /dev/sdb1 104853340K drbdadm create-md r0 drbdadm create-md r1 -> FALLO (leer valor left usable para la siguiente línea, sustituyendo las xxxxxxxxxx) e2fsck -f /dev/sdb2 && resize2fs /dev/sdb2 10485404K drbdadm create-md r1 mkdir /usr/local/mailman cd zcs-7.1.4_GA_2555.UBUNTU10_64.20120105094803.tgz/ install.sh mailmanMTA.sh z-push.sh

5. Implementación

93

Configuración final de la segunda pareja

Una vez que Zimbra ha quedado instalado (incluyendo la post-instalación), será necesario seguir una serie de pasos que nos permitan alcanzar la configuración final de la segunda pareja (mbx2sme y mta2sme): Paramos el servicio de Zimbra y borramos la instalación, en ambos:

En mta2sme, además:

Ahora, sólo queda configurar los servicios necesarios para la alta disponibilidad. Para ello, habrá que ajustar los archivos de configuración como sigue a continuación.

service zimbra stop rm -r /opt/zimbra/

service mailman stop cd /usr/local/mailman/; rm -r *

PFC – SME del CdC

94

mbx2sme

/etc/hostname


/etc/hosts




/etc/drbd.conf






/etc/ha.d/ha.cf

mbx2sme


debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 12 initdead 18 udpport 694 ucast eth1 192.168.160.204 auto_failback on node mbx1sme node mbx2sme

5. Implementación

95


Finalmente, será necesario incluir como scripts de servicio los mismos que para mbx1sme.







PFC – SME del CdC

96

mta2sme

/etc/hostname


/etc/hosts:



Igual que en mta1sme.

/etc/drbd.conf





Igual que mta1sme.

mta2sme


5. Implementación

97


totem { version: 2 token: 3000 token_retransmits_before_loss_const: 10 join: 60 consensus: 5000 vsftype: none max_messages: 20 clear_node_high_bit: yes secauth: off threads: 0 rrp_mode: none interface { ringnumber: 1 bindnetaddr: 192.168.160.206 mcastaddr: 192.168.160.255 mcastport: 5405 } } amf { mode: disabled } service { ver: 0 name: pacemaker } aisexec { user: root group: root } logging { fileline: off to_stderr: yes to_logfile: no to_syslog: yes syslog_facility: daemon debug: off timestamp: on logger_subsys { subsys: AMF debug: off tags: enter|leave|trace1|trace2|trace3|trace4|trace6 } }

PFC – SME del CdC

98

/etc/ha.d/ha.cf

Finalmente, será necesario incluir como scripts de servicio los mismos que para mta1sme.

debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 12 initdead 18 udpport 694 ucast eth1 192.168.160.205 auto_failback on node mta1sme node mta2sme

5. Implementación

99

Puesta en marcha de la segunda pareja

Una vez que las máquinas mbx2sme y mta2sme han sido debidamente configuradas, ya podemos hacer uso de todos los recursos de esta pareja. Para ello, en ambos:

Con esto ya quedaría completamente funcional la segunda pareja de equipos que ofrecen el servicio deseado de forma autónoma. Para verificar el funcionamiento se debe esperar a que se sincronicen las particiones drbd. Para monitorizar el estado de la sincronización, es conveniente ir comprobando el fichero /proc/drbd hasta que el estado sea UpToDate en ambos equipos.

init 6

PFC – SME del CdC

100

Instalación de @etsi.us.es

Además de todo lo visto anteriormente, la instalación correspondiente al dominio @etsi.us.es debe cumplir una serie de particularidades que se enuncian a continuación:

Autenticación externa mediante LDAPS frente al servicio ofrecido por la Universidad de Sevilla.

Autenticación en la entrega de correo del servidor mediante SMTP Auth frente al intercambiador principal de la Universidad de Sevilla (mail.us.es).

Mejora en el rendimiento inicial de amavisd-new.

Desactivación de la GAL (Global Address List) de Zimbra.

Utilización de XMLRPC (XML Remote Procedure Control).

LDAPS

La autenticación LDAP (Lightweight Directory Access Protocol) se hará frente al servidor atenea.us.es. Para que Zimbra permita el uso de LDAPS (LDAP seguro) frente a cualquier servidor, debe tener almacenado su certificado. Para obtener este certificado de atenea.us.es e instalarlo en el servidor LDAP + MAILBOX, puede hacerse uso del siguiente script:

/root/instalacertificadoatenea.sh (permisos 777)

Puede resultar útil permitir la autenticación local para alguna cuenta con la que no se pueda usar el servidor LDAP externo, como la cuenta de administración. Para ello habrá que ejecutar en el mismo servidor:

Es recomendable que aquellas cuentas en las que se desee utilizar autenticación local tengan definido un dominio de consulta externa no válido, para evitar realizar peticiones innecesarias, así por ejemplo, el campo “Cuenta LDAP externa para autenticación” deberá tener el valor – (guión simple), por ejemplo. Además, en la interfaz de administración de Zimbra (https://mbxetsi.us.es:7071/zimbraAdmin), debe configurarse el dominio para la autenticación externa. Para ello, en DOMINIOS → ETSI.US.ES → Configurar autenticación, debe introducirse los

openssl s_client -connect 193.147.160.148:636 | awk \ '{if($1=="-----BEGIN"){while($1!="-----END"){print $0 >> \ "./certificado.crt"; getline;}print $0 >> "./certificado.crt"}}\' sudo /opt/zimbra/java/bin/keytool -import -alias EXTERNAL-LDAP \ -keystore /opt/zimbra/java/jre/lib/security/cacerts -storepass \ changeit -file ./certificado.crt rm ./certificado.crt service zimbra restart

su – zimbra zmprov md etsi.us.es zimbraAuthFallbackToLocal TRUE

https://mbxetsi.us.es:7071/zimbraAdmin

5. Implementación

101

siguientes parámetros:

URL de LDAP: https://atenea.us.es, Puerto: 636, UTILIZAR SSL activado.

Filtro LDAP: uid=%u (el uid para autenticar es el nombre de la cuenta, todo lo que vaya antes de la @ de la dirección de correo).

Base de búsqueda de LDAP: o=us.es,dc=us,dc=es.

Utilizar el DN/ la contraseña para asociar al servidor externo activado.

DN de enlace: uid=consultaesi,ou=people,dc=us,dc=es.

Contraseña de enlace y confirmar la contraseña.

SMTP Auth

Al pertenecer ETSI.US.ES al dominio de la Universidad de Sevilla (US.ES), se debe ajustar la configuración de acuerdo a su política. En concreto, debe definirse como intercambiador principal mail.us.es. Este servidor sólo acepta el correo mediante SMTP autenticado (SMTP Auth) al puerto 25. Para ello, será necesario una cuenta LDAP especial de la US ([email protected]) y la siguiente configuración, en el servidor MTA, y como usuario zimbra:

Donde sólo hay que completar con la contraseña de la cuenta en el lugar indicado.

Mejora del rendimiento de amavisd-new

Zimbra hace uso de amavisd-new para recoger el correo y que el antivirus (ClamAv) y el antispam (SpamAssassin) puedan examinarlo. Posteriormente, amavisd-new devuelve el correo a su cadena de proceso habitual. Esta aplicación puede ver reducido su tiempo de tránsito mediante las siguientes dos actuaciones:

Creación de un espacio temporal en la RAM para almacenar los correos mientras son procesados. Esta mejora ya ha sido contemplada en la instalación mediante el uso del script /init.d/mounttmpfs usado por /etc/ha.cf/haresources.

Activación de una base de datos MySQL para mejorar la búsqueda durante el escaneo del antispam. Para ello, debe ejecutarse lo siguiente, en el servidor MTA y como usuario zimbra:

zmprov ms etsi.us.es zimbraMtaRelayHost mail.us.es echo mail.us.es [email protected]:AQUICONTRASEÑA \ > /opt/zimbra/conf/relay_password postmap hash:/opt/zimbra/conf/relay_password postmap -q mail.us.es /opt/zimbra/conf/relay_password postconf -e smtp_sasl_password_maps=hash:/opt/zimbra/conf/relay_password postconf -e smtp_sasl_auth_enable=yes postconf -e smtp_cname_overrides_servername=no postconf -e smtp_use_tls=yes postconf -e smtp_sasl_security_options=noanonymous exit service zimbra restart

https://atenea.us.es/

mailto:[email protected]

PFC – SME del CdC

102

Se ha comprobado que el uso de estas técnicas mejora el rendimiento de amavisd-new en un 60%.

Desactivación de GAL

La agenda global GAL (Global Address List) está pensada para un entorno más colaborativo del que aquí se aborda. Por tanto, por privacidad, conviene desactivarla. Para ello, debe introducirse el siguiente comando, como usuario zimbra en el servidor LDAP + MAILBOX del sistema:

Utilización de XMLRPC

Existe una situación en la que se hace necesario que un equipo servidor MAILBOX + LDAP necesita dar una orden ajena a Zimbra al equipo servidor MTA que esté prestando el servicio. La situación es la siguiente: funcionando el servicio, si el servidor MAILBOX + LDAP activo cambia por el otro, el servidor MTA debe reiniciarse. La solución que se ha adoptado es la siguiente:

El servidor MTA, una vez que recoge el testigo de heartbeat, arranca CDCRPC (implementación de XMLRPC hecha en el Centro de Cálculo) y se queda escuchando la orden de reiniciarse.

Una vez que un servidor MAILBOX + LDAP se inicia, envía la orden de reiniciarse al servidor MTA activo en ese momento.

Con esta configuración queda solucionado el problema.

zmlocalconfig -e antispam_mysql_enabled=TRUE zmantispamctl restart

zmprov mc default zimbraFeatureGalEnable FALSE

5. Implementación

103

Verificación de la instalación

Para verificar que el sistema se ha instalado y configurado correctamente pueden realizarse las siguientes comprobaciones:

Zimbra está corriendo: ◦ En las cuatro máquinas virtuales ejecutamos: service zimbra status

▪ En mbx1sme: Todos los servicios deben aparecer “Running” ▪ En mbx2sme: Error, ruta no encontrada.

Verificamos con df que no existe nada montado en /opt/. ▪ En mta1sme: Todos los servicios deben aparecer “Running” ▪ En mta2sme: Error, ruta no encontrada.

Verificamos con df que no existe nada montado en /opt/.

Funciona la autenticación externa: ◦ https://mbxetsi.us.es/: Identificación con UVUS/contraseña de PAS o PDI.

Funciona la autenticación interna para las cuentas que así lo tengan definido: ◦ https://mbxetsi.us.es/: Identificación con usuario/contraseña predefinido.

Se envía y recibe correo electrónico correctamente: ◦ Desde la interfaz de usuario de Zimbra, se envía contra un dominio externo, por

ejemplo, @gmail.com. ◦ Si se recibe, desde @gmail.com se responde y se comprueba que llega la respuesta.

Funciona mailman. ◦ https://etsi.us.es:7780/mailman: muestra correctamente las listas creadas. ◦ Se envía correo a una lista (desde una cuenta autorizada) y se comprueba que se

entrega a alguien suscrito a esa lista.

Funciona la mejora de rendimiento de amavisd-new. ◦ Desde la interfaz de usuario, se envía un correo a una cuenta local, con nivel de carga

baja en el servidor. ◦ Se accede a la cuenta de destino y se ve el mensaje completo (Ver original). ◦ Se mira el tiempo que lo tuvo amavisd-new. Para ello se mira la fecha y hora de entrada

al servidor 127.0.0.1:10024 y la fecha y hora de entrada al siguiente salto. ◦ Si el tiempo es inferior a 3 segundos, funciona correctamente.

Funciona Z-Push. ◦ En Android 2.3.6, por ejemplo, AJUSTES → CUENTAS Y SINCRONIZACIÓN →

CORPORATIVO: ▪ Nombre de usuario: UVUS ▪ Contraseña. ▪ Servidor Exchange: etsi.us.es ▪ Usar SSL: Activado. ▪ Aceptar todos los certificados: Activado. ▪ Desactivar “Sync SMS” después de que el servidor haya aceptado la conexión y

muestre datos para la sincronización.

Funciona la alta disponibilidad. ◦ Con las cuatro máquinas virtuales encendidas.

▪ Se ejecuta init 0 en mbx1sme y se comprueba en mbx2sme en el fichero /var/log/ha-log que asume los recursos de mbx1sme. Posteriormente (tarda un

https://mbxetsi.us.es/


https://etsi.us.es:7780/mailman

PFC – SME del CdC

104

tiempo en arrancar todos los servicios, en especial Zimbra), se ejecuta service zimbra status. Debe aparecer todo “Running”. A continuación, se enciende la máquina virtual mbx1sme y se comprueba que después de arrancar recuperá el servicio ya que está definida como principal en el caso de que estén las dos mbx activas.

▪ Igual con mta1sme y mta2sme. ▪ Se corta la corriente de mbx1sme (“Power off” en el vSphere Client de VMWare), y

se comprueba desde mbx2sme que se detecta y se asume el servicio. ▪ Igual desde mta2sme con mta1sme. ▪ Se corta la corriente de mbx2sme (mientras mbx1sme funciona y presta el servicio),

y se comprueba desde mbx1sme que no sucede nada extraño. Posteriormente se enciende mbx2sme monitorizando en mbx1sme que todo se inicia correctamente, mirando los ficheros /var/log/ha-log y /proc/drbd.

▪ Igual con mta2sme y mta1sme.

5. Implementación

105

Servicios y recursos ofrecidos

Esta instalación proporciona los siguientes recursos y servicios:

https://mbxetsi.us.es/: Interfaz de usuario. Tres versiones: ◦ AJAX (la más completa) ◦ HTML ◦ Móvil

https://etsi.us.es:7780/mailman/: Listas de distribución.

Acceso IMAP SSL. Configuración: ◦ Servidor: mbxetsi.us.es ◦ SSL: Activado ◦ Puerto: 993

Acceso POP3 SSL. Configuración: ◦ Servidor: mbxetsi.us.es ◦ SSL: Activado ◦ Puerto: 995

Acceso SMTP TLS. Configuración: ◦ Servidor: etsi.us.es ◦ TLS: Activado ◦ Puerto: 587

Acceso WebDAV. Configuración: ◦ https://mbxetsi.us.es/dav/[email protected]/Briefcase (se puede sustituir Briefcase

por el nombre de otro maletín creado por el usuario)

Acceso CalDAV. Configuración: ◦ https://mbxetsi.us.es/dav/[email protected]/Calendar

Acceso CardDAV. Configuración: ◦ https://mbxetsi.us.es/dav/[email protected]/Contacts

Servidor Exchange para dispositivos móviles. Configuración: ◦ Servidor: etsi.us.es

▪ Acceso SSL ▪ Aceptar todos los certificados ▪ “Sync SMS” desactivado (cuando aparezca)

https://mbxetsi.us.es:7071/zimbraAdmin/: Interfaz de administración


https://etsi.us.es:7780/mailman/

https://mbxetsi.us.es/dav/[email protected]/Briefcase

https://mbxetsi.us.es/dav/[email protected]/Calendar

https://mbxetsi.us.es/dav/[email protected]/Contacts

https://mbxetsi.us.es:7071/zimbraAdmin/

PFC – SME del CdC

106

Entrega del sistema

Es interesante mencionar cómo se hace la entrega del sistema al usuario final (el Centro de

Cálculo de la ETSI) una vez finalizados su diseño, implementación y puesta en producción. Además de toda la información ofrecida en este documento, falta por añadir la siguiente

información de carácter sensible:

Contraseña de los hipervisores: Los hipervisores cuenta con una contraseña de administración a través de la cual se tiene acceso a su supervisión, gestión y mantenimiento.

Contraseña del usuario root de las cuatro máquinas virtuales (así como de otros usuarios que hayan sido creados): Con ella se tiene acceso completo al sistema operativo completo y a la instalación de Zimbra mediante la consola de comandos que soporta cualquier operación sobre el servicio. También a las instalaciones de Mailman y Z-Push.

Contraseña de administración de Zimbra: Con ella se tiene acceso a la cuenta del administrador de Zimbra y a la interfaz web de administración.

Contraseña de administración de Mailman: Cuya principal funcionalidad es la de crear una lista de distribución desde el interfaz web, pero no es necesaria su utilización si se tiene acceso a la consola de comandos del sistema operatvo en el que está instalado Mailman.

Contraseñas internas para el funcionamiento de Zimbra (necesarias para configurar otros servidores Zimbra distintos del MAILBOX + LDAP principal a la hora de ser instalados):

o Contraseña del servidor LDAP principal. o Contraseña para las réplicas de LDAP. o Contraseña de postfix en LDAP. o Contraseña de amavis en LDAP. o Contraseña de nginx en LDAP.

Contraseñas internas de funcionamiento de las aplicaciones (heartbeat, iscsi, etc.): No resulta necesario entregarlas si se tiene acceso completo al sistema, ya que figuran en los ficheros de configuración y su uso es interno a las distintas aplicaciones, es decir, no controlan el acceso a su gestión.

Y un par de contraseñas externas:

Contraseña para la entrega externa autenticada frente a mail.us.es (SMTP Auth), proporcionada bajo demanda por la Universidad de Sevilla.

Contraseña para la base de búsqueda de LDAP en el servidor externo ldap.us.es, también proporcionada por la Universidad de Sevilla bajo petición.

Documents

Servidor de la Biblioteca de Ingeniería. Universidad …bibing.us.es/proyectos/abreproy/12038/fichero/07.pdfPFC – SME del CdC 22 Correo electrónico: instalación básica Se va